ServiceNowのLinux Discoveryを理解するときは、「ネットワークが通る」「SSHで認証できる」「必要な情報を取得できる」「CMDBに反映される」を分けると整理しやすくなります。MID Serverは、その間で指示を受け取り、対象へアクセスして結果を返す役割を担います。
この記事では、SSHを用いたLinuxのDiscoveryを題材に、通信・認証・権限のつながりを説明します。ServiceNowとLinuxの初学者から、仕組みを整理し直したい運用担当者を想定しています。個別環境の構築手順や検証レポートではありません。
資料確認日：2026-10-07。 ServiceNowはAustralia版の公式資料を参照しています。利用環境のリリース、Discovery Patternの版、MID ServerのOS、対象Linuxのディストリビューションは別途確認してください。本文・図は一般仕様に基づく説明で、実機での動作確認は行っていません。
用語の早見表
| 用語 | この記事での意味 |
|---|---|
| OS | Operating System。WindowsやLinuxなどの基本ソフトウェア |
| SSH | Secure Shell。暗号化された通信路でリモート接続する仕組み |
| Credential | 対象への接続に使う資格情報の設定 |
| sudo | ポリシーで許可された範囲で、別ユーザーの権限によりコマンドを実行する仕組み |
| DNS | Domain Name System。名前とアドレスなどの情報を対応付ける仕組み |
| IPアドレス | Internet Protocolで通信相手を指定するアドレス |
| TCP | Transmission Control Protocol。SSH等が利用する通信の仕組み |
| HTTPS | HTTPによる通信を暗号化して行う方式 |
| CMDB / CI | 構成管理データベース／その中で管理する構成アイテム |
1. まず三つの役割を分ける
| 登場するもの | 主な役割 |
|---|---|
| ServiceNowインスタンス | Discoveryの設定・実行管理、返された情報の処理、CMDBの管理 |
| MID Serverホスト | MID Serverソフトウェアが動くコンピューター。インスタンスと通信し、対象にアクセスする |
| 対象Linux | 情報を調べる相手。SSHサービスやOS上のコマンドが調査に使われる |
MIDはManagement, Instrumentation, and Discoveryの略です。MID Serverはインスタンスと組織内の対象をつなぐ実行コンポーネントであり、対象Linuxそのものを意味しません。MID ServerホストがWindowsで、調査対象がLinuxという構成もあります。対象OSとMID Serverの対応OSは、利用リリースのサポート条件で確認します。T01 T10 T13
CMDB（Configuration Management Database）は構成情報を管理するデータベースです。サーバーなどを表す一つひとつの記録をCI（Configuration Item、構成アイテム）と呼びます。「通信が成功した」と「期待するCIが正しく更新された」は、異なる到達点です。T07
2. 指示の向きと接続開始の向きは異なる
図1 青い実線はMIDからインスタンスとLinuxへの接続開始。オレンジの破線はインスタンスからMIDへのoutputと、その逆のinput
図1の青い実線は接続開始方向、オレンジの破線は論理的なメッセージの向きです。応答データは開始済みの通信を使って戻るため、破線が逆向きでも「インスタンスからMID Serverへ新しい着信接続を開く」という意味ではありません。DNS、プロキシ、その他の必要な通信は省略しています。
標準的な構成では、MID ServerがServiceNowインスタンスへHTTPS（通常TCP 443）で通信を開始します。対象LinuxへのSSH通信もMID Server側から開始します。SSHの既定ポートはTCP 22ですが、実際の接続先ポートは対象の設定とDiscovery側の設定に合わせます。T01 T14 T20 T21
インスタンスとMID Serverのメッセージ交換には、ECC Queue（External Communication Channel Queue）が関わります。方向の名称はインスタンスを基準に読みます。T02 T03
- output：インスタンスからMID Serverへ渡す処理指示
- input：MID Serverからインスタンスへ戻る結果や状態
大まかな流れは、インスタンスが処理を用意し、MID Serverが受け取り、対象Linuxへアクセスし、結果を返す、というものです。ECC Queueに指示があることだけで、対象への認証や情報収集まで成功したとは判断できません。
3. Discoveryの正式なフェーズと理解用の段階
ServiceNowの水平Discovery（Horizontal Discovery）は、ネットワーク上の機器やアプリケーションを検出し、構成情報を収集します。公式にはScanning、Classification、Identification、Explorationのフェーズが説明されています。パターン方式では、識別・詳細収集にPatternが使われます。Patternは、対象の特徴や情報を調べるための処理手順です。T04 T05 T06
一方、Linux側の仕組みを理解するには、次の五段階が便利です。
図2 到達性、認証、実行権限、情報取得、CMDB反映の五段階。前の成功は次の成功を保証しない
図2はこの記事独自の理解用の整理です。公式のDiscoveryフェーズ名や、内部処理の厳密な実行順序を置き換えるものではありません。
| 段階 | 成功すると分かること | まだ分からないこと |
|---|---|---|
| 到達性 | 必要な宛先・ポートまで通信できる | 正しいユーザーで認証できるか |
| 認証 | 対象が接続ユーザーを認めた | 調査に必要な権限があるか |
| コマンド実行権限 | 必要な操作が許可される | 想定する値を収集できるか |
| 情報取得 | 必要なコマンドやPatternから情報を得た | CIの識別・更新条件を満たすか |
| 反映 | 対象CIに期待する属性が反映された | 継続的な情報品質や次回の成功 |
たとえばSSHログインができても、特定のハードウェア情報にアクセスするコマンドだけが権限不足になることがあります。この場合、接続先の確認を最初からやり直すより、どのコマンドで止まったかを調べる方が有効です。
4. SSHで何をしているのか
SSH（Secure Shell）は、暗号化された通信路でリモートのシステムへ接続する仕組みです。この記事で扱うDiscoveryでは、MID Serverが対象LinuxへSSHで接続し、認証されたユーザーとしてコマンドを実行して情報を集めます。すべてのDiscovery対象や機能がSSHを使う、という意味ではありません。T08 T20 T21
SSHでは少なくとも二つの確認を区別します。
- 接続先サーバーが正しいかを、サーバーのホスト鍵で確認する
- 接続しようとするユーザーを、パスワードや公開鍵などで認証する
公開鍵認証では、公開鍵と秘密鍵の組を利用します。接続先側の認証設定と、接続元側の鍵の扱いが対応している必要があります。秘密鍵は本人性の証明に使う情報なので、記事、チャット、調査票に貼り付けません。ホスト鍵とユーザー認証用の鍵も、用途が異なります。T20 T21
ServiceNowのCredentialは、接続に使う資格情報の設定です。対象Linuxで使うアカウント名や認証方式と対応させます。鍵形式・利用可能な方式・必要な権限には製品上の条件があるため、OpenSSHクライアントで使えた設定が、そのままMID Serverでも使えるとは限りません。T08
5. アカウントの役割を混同しない
| 実行主体 | どこで使われるか | 混同しやすい点 |
|---|---|---|
| ServiceNowを操作するユーザー | インスタンスの画面 | 画面の操作権限とLinuxへのログイン権限は別 |
| MID Serverがインスタンスに接続するためのアカウント | インスタンス側 | MIDホストのOSアカウントや対象Linuxの接続ユーザーとは、認証先と役割が異なる |
| MID Serverサービスの実行ユーザー | MID Serverホスト | このアカウントがそのまま対象Linuxの接続ユーザーになるとは限らない |
| Credentialで指定した接続ユーザー | 対象Linux | Linux上で何が読めて何が実行できるかは、このユーザーの権限にも左右される |
インスタンスを操作する人のアカウントと、MID Serverがインスタンスに接続するためのアカウントも分けて考えます。T01 T10
Linuxでは、ユーザーID、グループ、ファイルのアクセス権、ACL（Access Control List、アクセス制御リスト）などが操作の可否に関わります。さらに、サービスやセキュリティ機構の制約もあります。SSHで認証できるという事実から、すべてのファイルやプロセスの情報が読めるとは言えません。
説明用の例では、対象名を linux01.example.com、IPアドレスを 192.0.2.10、接続ユーザーを discovery_user とします。いずれも架空値で、実際の接続先ではありません。ユーザーの実環境・担当実績を示すものではありません。
6. sudoは必要な操作だけを許可するために考える
sudoは、許可されたユーザーが、ポリシーに従って別のユーザーの権限でコマンドを実行するための仕組みです。SSH認証とsudoによる権限昇格は、異なる確認です。T22 T23
Discoveryで取得する情報によっては、通常ユーザーより強い権限が必要になります。ServiceNowは特権が必要なコマンドと設定上の考慮点を説明しています。ただし、必要なコマンドはOS、収集対象、Patternやプローブの実装によって変わります。資料の一覧をそのまま全環境へ適用するのではなく、実際の処理と照合します。T09
管理者と相談するときは、次の三点をそろえると判断しやすくなります。
- どの情報を取得するため、どのコマンドを使うのか
- 実行ファイルのパス、引数、実行先ユーザーは何か
- 自動処理で必要な認証・非対話実行の条件は何か
この記事では汎用のsudoers設定を提示しません。全コマンドへの無制限な権限を与えると、資格情報が漏れた場合の影響も大きくなります。必要性を確認し、最小限の範囲で設計・承認・検証することが重要です。
7. DNSとIPアドレスとポートを分ける
DNS（Domain Name System）は、名前とアドレスなどの情報を対応付ける仕組みです。ホスト名を接続に使う場合、MID Server側で想定どおりのアドレスを得られるかが重要になります。
Linuxの名前解決は、DNSだけで完結するとは限りません。NSS（Name Service Switch）などの設定により、ローカルのhostsファイルやほかの情報源も利用されます。たとえば getent による確認は、システムの名前解決経路を調べるのに使えます。DNSサーバーへの問い合わせ結果と、OSが返す結果を混同しないようにします。T24 T25
また、同じ名前でも、管理者のPCとMID Serverでは参照先や通信経路が異なる可能性があります。管理者のPCから接続できたことは、MID Serverからも接続できる証明にはなりません。IPアドレスを指定した通信でも、経路と宛先ポートの確認は必要です。
Discoveryの対象指定がIPアドレスである構成もあります。すべての処理にDNS成功を必須条件として当てはめず、どの処理がどの名前を使っているかを確認します。
8. 収集できた情報はどうCMDBへつながるか
結果がインスタンスへ返ると、Discovery側の処理で情報を解釈し、対象CIを識別して作成・更新します。IRE（Identification and Reconciliation Engine、識別と調整のエンジン）は、CIの識別や更新元の制御に関わる仕組みです。T07
必要な属性が足りない、想定したPatternと対象が合わない、識別・更新側でエラーがある、といった場合には、SSHが成功していても期待する反映に至らないことがあります。この部分はSSHの再設定だけでは説明できません。
調査では、Discoveryの実行結果、収集処理、識別・更新結果をたどります。どの属性が取得されるか、どのCIクラスへ反映されるか、識別ルールがどう適用されるかは、対象リリースと設定で確認してください。
9. 仕組みを説明できるか確認する
| 確認する問い | 押さえる点 |
|---|---|
| 対象へ接続するのはどのコンピューターか | 通常は選択されたMID Serverホスト |
| ECCのoutputとinputはどちら向きか | インスタンス基準。TCPの接続開始方向とは別 |
| SSHログイン後に権限エラーになるのはなぜか | 認証とコマンド実行権限が別だから |
| 手元のPCで名前解決できれば十分か | MID Server側の経路・名前解決も確認する |
| SSHに成功すればCIは必ず更新されるか | 情報取得、識別、反映をさらに確認する |
仕組みを把握したら、次は「最後に成功した段階」を記録すると切り分けにつながります。切り分け編「ServiceNow Linux Discoveryが失敗したときのSSH・sudo・DNS・ログの切り分け方」では、SSH・sudo・名前解決・ログを、実行場所と確認できる範囲をそろえて見ていきます。
参考資料
本文の参照番号に対応する公式資料です。確認日はすべて2026-10-07。参照先の更新や利用環境との差異に注意してください。
ServiceNowのリリース省略URLは表示版が変わり得るため、参照したAustralia版の公式GitHub資料へリンクしています。これらはブランチ固定で、将来の更新まで不変ではありません。OS系の資料は下記の参照版であり、導入版の動作を保証しません。
- T01 — Prepare network connections for MID Servers（ServiceNow Australia）
- T02 — The ECC queue for Discovery（ServiceNow Australia）
- T03 — MID Server ECC Queue（ServiceNow Australia）
- T04 — Horizontal discovery process flow with probes and sensors（ServiceNow Australia）
- T05 — Patterns and horizontal discovery（ServiceNow Australia）
- T06 — Horizontal discovery process flow with patterns（ServiceNow Australia）
- T07 — Exploring CMDB Identification and Reconciliation（ServiceNow Australia）
- T08 — SSH credentials（ServiceNow Australia）
- T09 — MID Server privileged commands（ServiceNow Australia）
- T10 — Install a MID Server on Linux（ServiceNow Australia）
- T13 — MID Server system requirements（ServiceNow Australia）
- T14 — Port probes（ServiceNow Australia）
- T20 — ssh(1)（OpenBSD-current）
- T21 — ssh_config(5)（OpenBSD-current）
- T22 — sudo(8)（sudo 1.9.17p2・公式ソース）
- T23 — sudoers(5)（sudo 1.9.17p2・公式ソース）
- T24 — getent(1)（Linux man-pages 6.19）
- T25 — NSS Configuration File（GNU libc 2.43）