ServiceNow

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インスタンス

セットアップ

1. 外部認証情報ストレージ (管理者ロールが必要)

外部認証情報ストレージプラグインが有効である必要があります。
外部認証情報ストレージのディスカバリープロパティが有効である必要があります。

システムプロパティ

「Enable External Credential Storage (外部認証情報ストレージを有効にする) com.snc.use_external_credentialsというプロパティは、外部認証情報ストレージプラグインを有効化または無効化するための設定項目です。

外部認証情報ストレージプラグインをアクティブ化した後、「Enable External Credential Storage」 (外部認証情報ストレージを有効にする、[com.snc.use_external_credentials]) というプロパティで外部認証情報ストレージ有効にしたり無効にしたりします。このプロパティは、[Discovery Definition] > [Properties and Orchestration] > [MID Server Properties] にあり、プラグインをアクティブ化した後に有効になります。

システムプロパティを使用して外部認証情報ストレージを無効にすると、システムはインスタンス内のすべての外部認証情報を自動的に非アクティブに設定します。このプロパティの機能を再度有効にした場合、システムは外部認証情報記録をアクティブにリセットすることはありません。各認証情報記録を手動でアクティブ化し直す必要があります。

2. Keeper Credential Resolverのインストール

Keeper Credential ResolverのダウンロードこちらのGithubウェブサイトからKeeper Credential Resolver (JARファイル) の最新バージョンをダウンロードします。
JARファイルをServiceNowにアップロード
1. ServiceNowで [MID server] > [JAR files] > [New] に移動します。
2. Manage Attachments (添付ファイルの管理) で、Keeper Credential Resolver JARファイルをアップロードします。
3. 必要に応じて名前、バージョンなどを入力します。
4. [Submit] をクリックします。
MIDサーバーのプロパティ設定
1. [MID server - Properties] > [New]へ移動します。
2. 以下のプロパティを設定します
  1. Name: ext.cred.keeper.ksm_config
  2. Value: 対応するKeeperシークレットマネージャー (KSM) アプリケーションの構成をBase64エンコードした文字列
3. (任意) ext.cred.keeper.ksm_label_prefixのプロパティを目的の接頭辞に設定します (デフォルトではresolverはラベル接頭辞としてmid_を使用)
4. (任意): ext.cred.keeper.use_ksm_cacheのプロパティを"true"に設定してキャッシュを有効にします (10秒あたり少なくとも数千のリクエストが予想される場合に使用します)
5. または、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" オプションを使用してください。値を暗号化するには、必ずサーバーを再起動する必要があります。

3. ディスカバリー認証情報の構成

MIDサーバーから Keeperボルトの認証情報を使用するには、以下の手順を行います。

Keeperボルトにシークレットを作成し、対応するKSMアプリケーションと共有します。
そのシークレットを使用するようにリゾルバを構成します。

Keeperボルトにシークレットを作成し、フィールドをマッピングする

Keeperのレコードタイプは動的かつカスタマイズが容易であり、ServiceNowの特定の認証情報タイプに対応するような固定のレコードタイプは存在しません。

Keeper External Credential Resolverは、カスタムフィールドのラベルを使用して、レコードデータとMID Serverのテーブル列 (discovery_credential テーブル) をマッピングします。指定された認証情報タイプに対応するすべての必要なカスタムフィールドに、該当するテーブル列と一致するラベルを付け、そのラベルに「mid_」というプレフィックスを付けてください (カスタムプレフィックスの設定方法は後述)。

ユーザー名/パスワードが必要な認証情報タイプでは、「Login」タイプのレコードを使用し、必要なカスタムフィールドを追加してください (例: type=hidden, label="mid_pkey")。

ユーザー名/パスワードが不要なその他のタイプについては、標準フィールドを持たない「File」または「Photo」タイプのレコードを使用するのが最適です。これにより、カスタムフィールドの管理が容易になります。

カスタムフィールドラベルのプレフィックスを変更するには、以下のパラメータを含めて MID Server の config.xml を編集し、MID Serverを再起動してください。

<parameter name="ext.cred.keeper.ksm_label_prefix" value="mid_"/>

カスタムフィールドのタイプには、text、multiline、hiddenを使用できます。Keeperボルト内での可視性に応じて選択してください。
「ログイン情報」レコードタイプが使用されている場合、ユーザー名/パスワード用のカスタムフィールド (たとえ正しくmid_user、mid_pswdとラベル付けされていても) は無視されます。これらの値は常にログイン情報レコードの標準フィールド (ログイン/パスワード) から取得されます。
「External credential store」オプションと併用する場合、resolveメソッドから返されるマップキーは、snc-automation-api.jarのIExternalCredentialインターフェースに準拠している必要があります (値にはVAL_接頭辞が付きます)。
- 現在のバージョン (Utah) でサポートされているキー値は以下の通りです。これらに対応するKeeperレコードのフィールドラベルには、mid_の接頭辞を付ける必要があります。そうすることで適切に抽出およびマッピングされます。
  - user
  - pswd
  - passphrase
  - pkey
  - authprotocol
  - authkey
  - privprotocol
  - privkey
  - secret_key
  - client_id
  - tenant_id
  - email
KeeperをCustom External Credential Resolverとして使用する場合、Keeperボルト内のカスタムフィールドをServiceNow側にマッピングすることができますが、Keeperボルト内で正しく接頭辞が設定され、フィールドが対応するServiceNow認証情報タイプに存在する必要があります。この場合、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) を手動で追加します。

Keeperボルトで認証情報を見つける

MID ServerからCredential Resolverに渡される認証情報IDは、有効なレコードUID (22文字の英数字、「-」および「_」を含む) であるか、type:titleの形式である必要があります。

type:title形式では、レコードタイプやタイトル、またはその両方で検索できますが、:を複数含む形式は無効です。

この形式を使用する場合は、一致するレコードが1件のみであるようにしてください。複数のレコードが一致するとエラーになります。

確実に1件のレコードと一致させるため、レコードUIDでの指定を推奨します。また、Keeperボルトのゼロ知識構造の特性上、type:title検索はローカルで行う必要があるため、毎回すべてのレコードをダウンロードして検索する非効率を避ける意味でも、UIDの使用が推奨されます。

例: (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]、カスタムの外部認証情報ストレージボルトのいずれかを選択できます。
  1. カスタムの外部認証情報ストレージボルトを使用するには、ServiceNowインスタンスの [Vault Configurations] ([vault_configuration.list]) に移動します。
  2. インポートしたJARファイルに関連付けられた名前を使用して、カスタム認証情報リゾルバ用の新しいレコードを作成します。
- (任意): [Test credential] ボタンをクリックし、MIDサーバーとテスト対象を選択して、すべてが機能しているかどうかを検証します。

リクエストのキャッシュとスロットリング

短時間に過剰なリクエストがKeeperに送信された場合、スロットルエラーが返されます。プラグインはデフォルトでこの「スロットル」エラーを解決しようとし、ランダムな遅延を挿入して再試行します。この方法は、10秒間に最大1000〜3000件のリクエストに対して有効です (300〜600件/10秒を超えるとスロットルが発生し始めます)。

10秒以内に5000件以上のリクエストが発生する可能性がある場合は、config.xmlにパラメータext.cred.keeper.use_ksm_cacheを"true"に設定し、MID Serverを再起動してキャッシュ機能を有効にすることを推奨します。キャッシュされたデータは、MID Serverの作業フォルダ内にある暗号化ファイルksm_cache.datに保存されます。キャッシュは、最長でも5分に1回、または次のリクエスト時に更新されます。

トラブルシューティング

ログを確認する

エージェントのインストールフォルダ内のlogs/内のログファイルでログとエラーを確認します。リゾルバーは、正常にクエリされた認証情報IDごとに1 行のログを記録し、認証情報が抽出されたフィールドもログに記録します。

特定の認証情報IDが期待通りに機能しない場合は、ログ内でそのIDを検索し、正常にクエリが実行されて認証情報が予期したフィールドから抽出されたことを確認します。

また、レコードの検索エラーやフィールドの検索エラー、Keeperボルトとの通信で問題が発生した場合など、プロセス中に発生した例外やエラーも記録されています。

Test credential (認証情報のテスト) 機能を使用する

ServiceNow UIで認証情報を作成または構成する場合、[Test credential] ボタンをクリックして、対象を絞った簡単なテストを実行できます。Keeperのボルトを照会するMIDサーバーを選択し、認証情報を問い合わせる対象を選択して、すべてが期待どおりに機能することを確認します。期待どおりに機能しない場合は、前述のようにログのエラーとデバッグ情報をご確認ください。

前へPowerShellプラグイン次へTeamCity

最終更新 7 日前