ServiceNow Discovery Credentialの設計｜種類・Affinity・認証失敗の判断ガイド

ServiceNow Discovery Credentialは、対象機器へログインするためのユーザー名・パスワードを保存するだけの設定ではありません。対象OS・プロトコルに合う種類、使用できるMID Server、Credential Alias、試行順、Credential Affinityを組み合わせて、必要な対象へ必要最小限の権限で接続させます。この記事では、認証失敗を到達性 → Credential種類 → 適用範囲 → 選択順 → 実行権限の順で切り分けます。

Discovery Credentialの役割

DiscoveryではMID Serverが対象へ接続し、OSや機器、アプリケーションの情報を取得します。その際にSSH、Windows、SNMP、VMware、JDBCなど対象に合うCredentialが必要です。公式ドキュメントは、Discovery、Service Mapping、Cloud Management、OrchestrationがハードウェアやソフトウェアへアクセスするためにConnectionとCredentialを利用すると説明しています。

認証失敗を「パスワード間違い」と決めつけると遠回りします。対象IPへ到達できない、Windows対象にSSH Credentialを用意している、Credentialが別MIDだけに限定されている、Aliasで候補から除外されている、ログインはできてもコマンド権限が足りない、という異なる原因があります。

対象に合うCredential種類を選ぶ

Applicative CredentialはホストへログインするCredentialとは別です。たとえば対象アプリケーションの情報を取るために、SSHやWindowsのホストCredentialに加えて、アプリ固有Credentialを必要とする場合があります。公式のDiscovery要件に記載がなければ、むやみに追加しません。

Applies toとAliasで利用範囲を絞る

Applies toでMID Serverを制限する

CredentialをAll MID Serversへ配る必要がなければ、Specific MID Serversへ限定します。対象ネットワークへ到達できるMIDだけに利用権を与えることで、不要な秘密情報の露出と誤試行を減らせます。公式のCredential作成手順も、セキュリティ向上のため特定MID ServerまたはScheduleへ範囲を限定するよう案内しています。

Credential AliasでScheduleの候補を制御する

Aliasを使わないScheduleは、インスタンスで定義された利用可能なCredentialを広く候補にする場合があります。Discovery用Credential AliasをScheduleへ設定すると、そのAliasに含まれるCredentialだけを使わせられます。高権限Credentialを無関係なScheduleが試行するのを防ぎ、環境・管理ドメインごとの分離を明確にできます。

Credential Affinityは成功した組み合わせを再利用する

初回Discoveryでは、利用可能なCredentialを試し、対象へ接続できるものを探します。成功すると対象デバイスとCredentialの間にAffinityが作られ、次回以降はその組み合わせが優先的に利用されます。公式ドキュメントでは、AffinityはCredentialとネットワーク上のデバイスの関連として説明され、Credential変更時には再び候補を試して新しいAffinityを作ります。

Affinityは「永久に固定される手動割当」ではありません。資格情報のローテーション、Alias変更、対象再構築後に認証が失敗したときは、古いAffinityの影響と新しい候補の選択を確認します。また、AliasをScheduleへ指定した場合は、既存AffinityよりAliasの制約が優先される条件があります。

認証失敗を5層で切り分ける

「認証エラー」と「コマンド実行エラー」を分けることが重要です。Credential Testが通っても、Patternが必要とするコマンドを実行できるとは限りません。公式のCommand Validation Toolは、PatternコマンドをMID Serverから実行し、到達性・Credential・実行権限を検証するために利用できます。

Credential Orderとロックアウトを考える

複数Credentialを試す場合、順序が不適切だと無効なアカウントを先に繰り返し試し、対象側でロックアウトを起こす可能性があります。Applicative Credential等にはOrderがあり、小さい値が先に試されます。すべて同じOrderまたは未設定の場合、試行順が予測しづらくなる場合があります。

ただし、Orderへ番号を振るだけで候補数の問題は解決しません。Alias、Applies to、Affinityで候補を狭め、Orderは同じ候補群の優先を表すために使います。資格情報をローテーションするときは、新CredentialのTest、適用範囲、Affinityの切替、旧Credentialの無効化を変更管理の対象として計画します。

外部Vaultを使うときの考え方

ServiceNowは、Discovery等が使う秘密情報を外部Credential Repositoryへ保存する構成をサポートしています。公式ドキュメントではCyberArkまたはBeyondTrustを用いる外部保存が示されています。この場合、インスタンスはCredential ID、種類、Affinity等を管理し、MID Server側の連携コンポーネントが実際の秘密を解決します。

外部Vaultを使えば権限設計が不要になるわけではありません。Vault側のアクセス、MID Serverの実行権限、IDの対応、障害時の切り分け、ローテーション手順まで一続きで設計します。

実務で起きる失敗を4ビートで覚える

全CredentialをAll MID Serversへ配ったケース

事故：無関係な拠点のMIDが高権限Credentialを試します。放置：秘密情報の露出範囲と監査対象が広がります。設定：Specific MID ServersとAliasで利用経路を限定します。改善：対象・Schedule・MID・Credentialの責任境界が明確になります。

Password変更後もAffinityが古いケース

事故：以前成功した対象だけ認証失敗します。放置：対象側のロックアウトを繰り返します。設定：新CredentialをTestし、Alias/Order/Affinityの選択を確認して旧Credentialを無効化します。改善：ローテーションが監査可能な手順になります。

Credential Testは成功、Patternは失敗するケース

事故：担当者はServiceNow側の不具合だと判断します。放置：必要なCI属性が取れません。設定：Command ValidationでPatternが使うコマンドと権限を検証します。改善：ログイン権限と実行権限を分けて説明できます。

Credential運用のベストプラクティス

• 最小権限の専用アカウントを使う：個人管理者や共用の万能アカウントを使いません。
• 説明的なNameを付ける：環境、用途、対象を識別でき、秘密値を名前に入れない命名にします。
• 範囲を限定する：Specific MID、Alias、Tag等で不要な候補を減らします。
• 保存前・変更前にTestする：対象とMIDを指定して実際の経路で検証します。
• 失敗回数とLockoutを監視する：大量試行を性能問題だけでなくセキュリティ事故として扱います。
• ローテーションを変更管理の対象にする：新旧の並行期間、切替、Affinity、戻し方を記録します。
• 秘密を記事・チケットへ貼らない：スクリーンショット、ログ、Exportにも秘密が残らないよう確認します。

CIS-Discovery試験での判断軸

理解確認

特定のDiscovery Scheduleだけに本番ネットワーク用Credentialを使わせ、他のScheduleから候補にしたくありません。最も適切な仕組みはどれですか。

1. Credential AliasをScheduleへ設定し、対象CredentialをそのAliasへ関連付ける
2. CredentialのApplies toを特定MIDへ限定するだけで、Schedule側の候補は制限しない
3. Credential Orderを最小値にして、すべてのScheduleで最初に試行させる
4. 過去に成功したCredential Affinityだけに依存し、Scheduleには制約を設定しない

正解：A。AliasはScheduleが利用できるCredential候補を限定します。AffinityやOrderとは役割が異なります。

よくある質問

PasswordはServiceNowの画面から確認できますか

保存済みの秘密値を確認・共有する前提にしません。必要なら組織の承認手順でローテーションし、External Credential Storeを使う場合はVault側の管理手順に従います。

Credential Testが成功すればDiscoveryも成功しますか

必ずではありません。ログインが成功しても、Patternのコマンド実行権限、対象範囲、MID選択、IRE処理で失敗する可能性があります。Discovery StatusとCommand Validationを確認します。

Credential AffinityとCredential Aliasの違いは何ですか

Affinityは対象と過去に成功したCredentialの関連です。AliasはSchedule等が利用できるCredential候補を管理者が制限する仕組みです。

WindowsとLinuxで同じCredentialを使えますか

通常は対象の認証方式に合うTypeを使い分けます。同じユーザー名文字列でも、Windows CredentialとSSH Credentialは別の種類・要件です。

まとめ

Discovery Credentialは、種類、秘密情報、MID適用範囲、Alias・Order、Affinityを持つ認証設計です。認証失敗ではPasswordだけを疑わず、到達性、種類、候補範囲、秘密、コマンド権限の5層で切り分けてください。最小権限と範囲限定を守り、ローテーションを変更管理の対象として運用することで、探索成功率とセキュリティを両立できます。

探索範囲と実行時間はDiscovery Schedule・IP Rangeの記事、MIDの接続状態はMID Server切り分け、全体フローはDiscoveryの仕組みで確認してください。理解確認にはCIS-Discovery無料模試、学習順はCIS-Discovery対策ハブを利用できます。