💡 【検証環境・個人研究（PoC）に関する注記】
本記事は、筆者個人の自宅検証環境（ホームラボ／仮想環境）において、公開情報およびOSS（オープンソースソフトウェア）を用いて独自に構築・検証した個人研究（PoC）の記録です。特定の企業・団体の実環境や業務上の非公開情報とは一切関係ありません。
はじめに：当たり前だった「エージェント常駐」の常識が揺らいだ日
情シスやセキュリティ担当者にとって、長年「端末管理・脆弱性診断といえばエージェントソフトを全台にインストールするのが当たり前」でした。
- 「常駐ソフトがCPUやメモリの情報を収集して中央にプッシュ送信する」
- 「カーネルレベルで挙動を常時監視してセキュリティを守る」
しかし、2024年に世界中で発生した CrowdStrikeの大規模ブルースクリーン（BSOD）障害 は、すべてのインフラエンジニアに大きな衝撃を与えました。
「安全を守るための特権エージェントが、定義ファイルやアップデートの不具合によって大規模なシステム停止を引き起こし得る」という現実が浮き彫りになったからです。
さらに、エージェントソフト自体の脆弱性を突かれたサプライチェーン攻撃も後を絶ちません。
そこで改めて注目されているのが、「端末側にはサードパーティ製エージェントを入れず、OS標準機能（WinRM / SSH）を使って外部から必要な時だけ診断するエージェントレス型（ゲートウェイ型）」 です。
本記事では、両者のメリット・デメリットを現場目線で比較し、エージェントレス型を採用する際に避けて通れない**「マスターキー漏洩リスク（単一障害点）」をどう抑止・局所化するか**の設計論を解説します。
1. 現場目線での徹底比較マトリクス
カタログスペックではなく、運用現場で実際に起こるトラブルをベースに比較した表が以下です。
| 比較項目 | エージェント型（常駐型） | ゲートウェイ型（エージェントレス） |
|---|---|---|
| 端末への影響・負荷 | △ 高リスク: 常駐ソフトのバグや競合で高負荷になったり、カーネルドライバ不具合でOSがクラッシュする危険がある | ◎ 低リスク: サードパーティ製の常駐プロセスはゼロ。診断時のみOS標準機能が動くため、エージェント起因の障害リスクを大幅に低減できる |
| 導入・更新の手間 | △ 煩雑: 何百台ものPCにインストールが必要。バージョンアップやアンインストール失敗時の個別対応も負担が大きい | ◎ 容易: 端末側への独自ソフト配布は不要。OS標準のWinRM/SSHを有効化するだけで開始可能 |
| 対象機器の範囲 | △ 制限大: エージェントを入れられないアプライアンス、ルーター、古いレガシーOSは管理できない | ◎ 幅広い: 標準プロトコルで接続できれば、Linux、Windows、macOS、ルーター、NASまで幅広く管理可能 |
| ネットワーク要件 | ◎ 容易: 端末から外向き（HTTPS等）に出られればOK | △ 要設計: ゲートウェイから端末へのインバウンド（SSH 22番 / WinRM 5985・5986番）を許可する設計が必要 |
| 最大の弱点・リスク |
🚨 サプライチェーン攻撃 / 特権エージェント障害 エージェントの脆弱性悪用や更新不具合で多数のPCが一斉に停止するリスク |
🚨 マスターキーの漏洩（単一障害点） ゲートウェイが対象PCの認証情報（パスワード・秘密鍵）を扱うため、侵害されると横展開されるリスク |
2. エージェントレス最大の弱点「マスターキー漏洩」をどう防ぐか？
エージェントレス型には「端末側にサードパーティ製エージェントを常駐させないため、エージェント起因の障害リスクを大幅に低減でき、導入も容易」という大きな利点がある一方で、セキュリティ担当者が最も警戒するのが**「診断サーバーが侵入されたら、全PCの管理者パスワードが盗まれて全端末に侵入されるのではないか？」**という懸念です。
この課題を抑止・局所化するために、本システムで設計した**「マスターキー防衛の3原則」**を紹介します。
① ドメイン管理者（Domain Admin）権限を使わない
Active Directoryの最強権限であるDomain Adminsのアカウントをスキャナーに登録してはいけません。
必ず**「ローカルの診断専用アカウント（例: AssetScanUser）」**を作成し、端末ごとにパスワードを分離するか、Windows LAPS（Local Administrator Password Solution）と連携させます（通信経路も検証環境ではWinRM 5985/NTLMで動作確認し、本番環境では5986/TLS＋Kerberosまたは証明書認証を推奨します）。万が一スキャナーの1台分の認証情報が漏れても、ドメイン全体への横展開（Lateral Movement）を防止できます。
② Linux/macOS端末は「公開鍵認証のみ ＋ sudoersコマンド限定 ＋ 送信元IP固定」
SSH接続を行うLinux/macOS端末に対しては、パスワード認証を禁止し、送信元IP制限（authorized_keys の from=）付きの公開鍵認証のみを許可します。
さらに、診断専用ユーザー（assetscan）が特権（sudo）で実行できるコマンドを sudoers（NOEXEC 併用）で読み取り専用の情報収集コマンドのみに厳密に絞り込みます（※Linuxでは dpkg/rpm 等、macOSでは softwareupdate/system_profiler 等を指定）。
これにより、仮に診断サーバーから秘密鍵が流出してSSHログインされたとしても、実行可能な操作は assetscan ユーザー権限に限定されるため、root権限を用いたシステム設定改ざんやデータ消去といった特権破壊操作は制限されます。
③ 認証付き暗号による保管とオンメモリ復号（本番推奨：AES-256-GCM ／ 実装例：Fernet）
サーバーのデータベース内にパスワードを平文で保存するのは厳禁です。
認証付き暗号（本番推奨：AES-256-GCM、PoC実装例：Fernet［AES-128-CBC + HMAC-SHA256］）で暗号化して保管し、復号鍵は環境変数やHSM/KMSで分離管理します。スキャン実行時のみメモリ上で復号してセッションを張り、利用完了後に参照を破棄（del）して平文認証情報の寿命を最小化します（※Pythonランタイム上では del による参照削除だけでは物理メモリの完全なゼロ化は保証されないため、高機密環境ではHSM/KMSや短命証明書との連携を推奨します）。
アーキテクチャ詳細、処理フロー図、中核ロジックのコード抜粋（PoC）、およびパラメータ解説・トラブルシューティング手順は、GitHubリポジトリ（詳細技術リファレンス）にて管理・随時アップデートしています。
設計の全体像や要点スニペットの確認は以下のリンクをご参照ください。
👉 GitHubで詳細技術リファレンス・処理フローを見る (QIITA_ARTICLE_DETAIL_8.md)
まとめ：適材適所で「ハイブリッド」に守る時代
エージェント型とエージェントレス型、どちらか一方がすべての環境で唯一の正解というわけではありません。
- クラウド上の動的なコンテナやVM ➔ 外向き通信で自律報告する「エージェント型」が便利
- オフィスの社内PC、ファイルサーバー、NAS、ネットワーク機器 ➔ エージェント起因の障害リスクを大幅に低減でき、ブラックボックス常駐を排除できる「エージェントレス型」が適している
「エージェントを入れておけば安心」という盲信を捨て、「常駐させるリスク」と「認証情報を集中管理するリスク」を天秤にかけ、適切な鍵防御・権限最小化を施したエージェントレス管理を組み合わせることこそが、2020年代後半の堅牢なインフラ設計のスタンダードです。
📚 さらに詳しい本番実装・トラブルシューティングについて
本記事は現場運用のエッセンスを凝縮したサマリー版です。
本番導入に向けた 「深層メカニズム解説」「完全パラメータ表」「現場アンチパターン」「トラブルシューティング対応表」「運用チェックリスト」 は、以下のGitHub完全技術リファレンスにて全網羅して公開しています。
⭐ 全14層・200パターンの自立型インフラ＆オンプレAIリファレンスを順次公開予定です。役に立った・面白かったと感じていただけましたら、ぜひリポジトリへの Star (★) をお願いいたします！
👉 GitHub リポジトリ: ojisan-arsenal