ServiceNow
ServiceNowとKeeper認証情報ストレージの統合
最終更新
ServiceNowとKeeper認証情報ストレージの統合
最終更新
管理、計測、検出 (MID) サーバーとKeeperボルトの統合により、ServiceNow Orchestration、ServiceNowディスカバリー、ServiceNowサービスマッピングにおいてServiceNowインスタンスに認証情報を保存せず、Keeperボルトから資格情報を動的に取得できるようになります。
ServiceNowインスタンスでは、各認証情報向けに固有の識別子だけでなく、その認証情報の種類 (SSH、SNMP、Windowsなど) と関連する資格情報の親和性も保持されます。MIDサーバーは、ServiceNowインスタンスから認証情報識別子、認証情報の種類、IPアドレスを取得し、Keeperボルトを使用して利用可能な認証情報に変換します。
ServiceNow Orchestration、ディスカバリー、サービスマッピングの認証情報としてKeeperボルトのシークレットを使用
ディスカバリーとOrchestration用の外部認証情報ストレージに対応
カスタム認証プロバイダとしての使用
トリガー: ServiceNowの管理者が、新しく追加されたインフラストラクチャの検出プロセスを開始します。
アクション: ServiceNowは検出を開始するためにMID サーバーに要求を送信します。
MIDサーバー: Keeperボルトから必要な認証情報 (SSH、SNMPなど) を取得し、検出を実行します。
結果: 検出されたアセットがServiceNow構成管理データベース (CMDB) に追加します。
トリガー: ServiceNowでインシデントが作成され、特定のサーバーで即時のアクションが必要となります。
アクション: ServiceNowは、MIDサーバーを含むオーケストレーションワークフローを発動します。
MIDサーバー: 影響を受けるサーバーにログインし、事前定義された修復手順を実行するために、Keeperボルトから必要な認証情報を取得します。
結果: インシデントが解決され、実行されたアクションがServiceNowに記録されます。
トリガー: ServiceNowと統合されたカスタムアプリケーションを操作するには、特定の認証情報が必要となります。
アクション: アプリケーションは、必要な認証情報をServiceNowに照会します。
MIDサーバー: リクエストを傍受し、Keeperボルトから認証情報を取得して、カスタムアプリケーションに渡します。
結果: カスタムアプリケーションは、Keeperボルトから安全に取得した認証情報を使用して操作を続行できます。
Keeperシークレットマネージャーへのアクセス (詳細についてはクイックスタートガイドのページをご参照ください)
Keeperアカウントでシークレットマネージャーのアドオンが有効である
シークレットマネージャー強制適用ポリシーが有効になっているロールのメンバーシップ
シークレットが共有されたKeeperシークレットマネージャーアプリケーション
アプリケーションの作成手順については、クイックスタートガイドをご参照ください。
外部認証情報ストレージプラグインが有効になっているServiceNowインスタンス
外部認証情報ストレージプラグインが有効である必要があります。
外部認証情報ストレージのディスカバリープロパティが有効である必要があります。
外部認証情報ストレージプラグインをアクティブ化した後、「Enable External Credential Storage」 (外部認証情報ストレージを有効にする、[com.snc.use_external_credentials]
) というプロパティで有効にしたり無効にしたりします。このプロパティは、[Discovery Definition] > [Properties and Orchestration] > [MID Server Properties]にあり、プラグインをアクティブ化した後に有効になります。
システムプロパティを使用して外部認証情報ストレージを無効にすると、システムはインスタンス内のすべての外部認証情報を自動的に非アクティブに設定します。このプロパティの機能を再度有効にした場合、システムは外部認証情報記録をアクティブにリセットすることはありません。各認証情報記録を手動でアクティブ化し直す必要があります。
Keeper Credential Resolverのダウンロード
こちらのGithubウェブサイトからKeeper Credential Resolver (JARファイル) の最新バージョンをダウンロードします。
JARファイルをServiceNowにアップロード
ServiceNowで[MID server] > [JAR files] > [New]に移動します。
Manage Attachments (添付ファイルの管理) で、Keeper Credential Resolver JARファイルをアップロードします。
必要に応じて名前、バージョンなどを入力します。
[Submit]をクリックします。
MIDサーバーのプロパティ設定
[MID server - Properties] > [New]へ移動します。
以下のプロパティを設定します
Name: ext.cred.keeper.ksm_config
Value: 対応するKeeperシークレットマネージャー (KSM) アプリケーションの構成をBase64エンコードした文字列
(任意) ext.cred.keeper.ksm_label_prefix
のプロパティを目的の接頭辞に設定します (デフォルトではresolverはラベル接頭辞としてmid_
を使用)
(任意): ext.cred.keeper.use_ksm_cache
のプロパティを"true"
に設定してキャッシュを有効にします (10秒あたり少なくとも数千のリクエストが予想される場合に使用します)
config.xml
直接編集することもできます (デフォルトでは /opt/servicenow/mid/agent/
にあります)。
キーを追加してサーバーを再起動します (ラベル接頭辞の設定は任意です。デフォルトの接頭辞は以下の通りです)。
<parameter name="ext.cred.keeper.ksm_config" secure="true" value="[KSM_CONFIG_BASE64_STRING]"/>
<!-- optional -->
<parameter name="ext.cred.keeper.ksm_label_prefix" value="mid_"/>
<!-- optional -->
<parameter name="ext.cred.keeper.use_ksm_cache" value="true"/>
すべての機密パラメータにはsecure="true"を使用し、サーバーを再起動して値を暗号化することを忘れないでください。
MIDサーバーから Keeperボルトの認証情報を使用するには、以下の手順を行います。
Keeperボルトにシークレットを作成し、対応するKSMアプリケーションと共有します。
そのシークレットを使用するようにリゾルバを構成します。
KeeperにはServiceNowで対応する認証情報タイプに一致する記録タイプはありませんが、記録タイプは簡単にカスタマイズできます。Keeper Credential Resolverは、カスタムフィールドラベルを使用して記録データをMIDサーバーのテーブル列 (discovery_credential
テーブル) とマッチさせます。具体的には、必要なすべてのカスタムフィールドに、特定の認証情報タイプのテーブル列と一致するようにラベルを付け、そのラベルの先頭に「mid_」を付けます(カスタム接頭辞の構成方法については、以下をご参照ください)。
ユーザー名/パスワードを必要とする認証情報タイプ
記録タイプ: ログイン情報
設定: 必要に応じてカスタムフィールドを追加します。
例: type=hidden、label="mid_pkey"
ユーザー名/パスワードがない可能性のあるその他のタイプ
記録タイプ: 「ファイル」または「写真」
これらの記録タイプには標準のフィールドがなく、カスタムフィールドを設定するのが簡単です。
カスタムフィールドラベルの接頭辞を変更
設定ファイルの更新
ファイル: config.xml (MIDサーバーの設定ファイル)
パラメータ: <parameter name="ext.cred.keeper.ksm_label_prefix" value="mid_"/>
MIDサーバーを再起動
設定を反映させるために、MIDサーバーを再起動します。
Keeperボルトで必要な可視性に応じてtext
、multiline、hidden
タイプのカスタムフィールドを使用します。
ログイン記録タイプを使用する際、ユーザー名/パスワード用のカスタムフィールドは無視されます (適切にmid_user、mid_pswdとラベル付けされている場合を含む)。これらの値は常にログイン記録タイプの標準フィールド (ログイン/パスワード) から取得されるためです。
Keeper Credential Resolverで「External credential store」オプションで使用する際には、resolveメソッドから返されるマップキーは、snc-automation-api.jar
(値はVAL_接頭辞で始まります) からのIExternalCredentialインターフェースに準拠している必要があります。現在のバージョン (Utah) でサポートされているキー値は、user、pswd、passphrase、pkey、authprotocol、authkey、privprotocol、privkey、secret_key、client_id、tenant_id、emailで、Keeper記録内の対応するフィールドラベルには、適切に抽出およびマッピングされるようにmid_
という接頭辞を付ける必要があります。
Keeper Credential ResolverをCustom External Credential Resolverとして使用する際には、 Keeperボルトでカスタムフィールドに適切な接頭辞が付いていて、対応する認証情報タイプに存在する場合は、任意のカスタム フィールドをマップできます。resolveメソッドから返される認証情報マップには、discovery_credentialテーブルの列名とマッチするキー (例: sn_cfg_ansible、sn_disco_certmgmt_certificate_ca、cfg_chef_credentialsなど) が含まれている必要があります。
例:
認証情報タイプjdbc
: Keeper記録タイプのLogin
にマッピングします (標準のログイン/パスワードフィールドを使用し、追加の設定は不要)
認証情報タイプapi_key
: Keeper 記録タイプのLogin
にマッピングし、 mid_ssh_private_key
およびmid_ssh_passphrase
のラベルを持つhidden
のタイプのカスタムフィールドを手動で追加します (オプション) 。
認証情報タイプgcp
: Keeper記録タイプのFile Attachment
かPhoto
にマッピングし、必要なカスタムフィールドのmid_email
(text) とmid_secret_key
(hidden) を手動で追加します。
MIDサーバーから認証情報リゾルバーに渡される認証情報IDは、有効な記録UID (ハイフン「 - 」とアンダースコア「 _ 」を含む22文字の英数字) か、type:title
の形式である必要があります。2つ目の形式では、記録タイプのみ、またはタイトルのみ (または両方) による検索も可能です (ただし、単一のコロン「 : 」を使用する組み合わせは無効となります)。
認証情報にtype:title
の形式を使用する際は、マッチする記録が1件しかないことを確かにしてください。一致する記録が複数あるとエラーが発生します。
記録UIDを使用することで、単一の記録がマッチすることが保証されます。また、type:title
でローカル検索を行うごとに記録が全てダウンロードされてしまうことから、記録UIDの使用が推奨されます (Keeperボルトのゼロ知識の性質により、検索はローカルでなければなりません)。
例 (0件または2件以上のマッチはエラーになります)
記録UIDで検索 - 認証情報ID:ABCDABCDABCDABCDABCDAB
タイプとタイトルで検索 - 認証情報ID:login:MyLogin
タイトルで検索 - 認証情報ID::MyLogin
タイプで検索 - 認証情報ID:login:
ServiceNowのUIでの設定
[Discovery - Credentials] > [New]へ移動します。
リストから認証情報の種類を選択します。
「External credential store」のボックスをチェックします。ユーザー名とパスワードのフィールドが消え、認証情報IDフィールドと「Credential Storage Vault」 (認証情報ストレージボルト) メニューが表示されます。
名前を入力します。
「Credential ID」をシークレットの記録のUIDに設定するか、type:title
または:title
の形式で検索文字列を入力し、1件の記録が見つかることを確認します。
「Credential Storage Vault」メニューから、[None]、[Keeper vault]、カスタムの外部認証情報ストレージボルトのいずれかを選択できます。
カスタムの外部認証情報ストレージボルトを使用するには、ServiceNowインスタンスの[Vault Configurations] ([vault_configuration.list]
) に移動します。
インポートしたJARファイルに関連付けられた名前を使用して、カスタム認証情報リゾルバ用の新しい記録を作成します。
(任意): [Test credential]ボタンをクリックし、MIDサーバーとテスト対象を選択して、すべてが機能しているかどうかを検証します。
プラグインは、デフォルトでランダムな遅延を追加して後で再試行することでスロットルエラーを解消しようとします。この方法で、10秒あたり最大1000~3000件のリクエストに対して対処できます (スロットルは10秒あたり300~600件のリクエスト後に開始します)。10秒未満で5000件以上のリクエストが予想される場合は、config.xmlでext.cred.keeper.use_ksm_cache
パラメータを"true"
に設定してMIDサーバーを再起動し、キャッシュを有効にすることをお勧めします。キャッシュされたデータは、MIDサーバーの作業フォルダ内の暗号化されたksm_cache.dat
ファイルに保存されます。キャッシュは、最大5分ごとに1回、または次のリクエストで更新されます。
エージェントのインストールフォルダ内のlogs/
内のログファイルでログとエラーを確認します。リゾルバーは、正常にクエリされた認証情報IDごとに1 行のログを記録し、認証情報が抽出されたフィールドもログに記録します。
特定の認証情報IDが期待通りに機能しない場合は、ログ内でそのIDを検索し、正常にクエリが実行されて認証情報が予期したフィールドから抽出されたことを確認します。
また、記録の検索エラーやフィールドの検索エラー、Keeperボルトとの通信で問題が発生した場合など、プロセス中に発生した例外やエラーも記録されています。
ServiceNow UIで認証情報を作成または構成する場合、[Test credential]ボタンをクリックして、対象を絞った簡単なテストを実行できます。Keeperのボルトを照会するMIDサーバーを選択し、認証情報を問い合わせる対象を選択して、すべてが期待どおりに機能することを確認します。期待どおりに機能しない場合は、前述のようにログのエラーとデバッグ情報をご確認ください。