Illumio MCP Server

Illumio MCP サーバー

📚 ドキュメントサイト — インストール、使い始め方、ワークフロー、全ツールのリファレンス、集中デプロイについて説明しています。

Illumio PCE（Policy Compute Engine）とやり取りするためのインターフェースを提供する、Model Context Protocol（MCP）サーバーです。このサーバーを使うと、Illumio のワークロード管理、ラベル操作、トラフィックフロー分析、自動リングフェンシング、インフラストラクチャサービスの識別にプログラムからアクセスできます。

できること

会話型 AI を使って PCE とやり取りできます。

• ワークロード、ラベル、IP リスト、サービス、ルールセットに対する完全な CRUD 操作
• ウィンドウ全体にわたるトラフィック分析 — サマリーは PCE が返す最初の 500 件だけでなく、すべてのフローを集計し、存在する件数と表示する件数を報告します
• 任意のラベルで集計 — デフォルトでは app／env、またはビジネスユニット、コンプライアンススコープ、ロール＋ロケーションなど、PCE で定義されたディメンションを使用できます
• シャドー AI／送信先の検出 — どのプロセスがどのプロバイダーと通信するかを特定します。RDAP とベンダー公開の範囲情報による属性付けは、CI で毎週更新されます
• プロセスを指定したポリシー — Windows の送信サービスとルール内のサービス参照を使い、「このバイナリだけがそのアプリにアクセスできる」ようにします
• 自動リングフェンシング — トラフィックを分析し、1 つのコマンドでアプリ間のセグメンテーションポリシーを作成します
• 選択的な適用 — 設定可能なコンシューマーフレーバーを使い、選択モードのアプリに拒否ルールを追加します
• インフラストラクチャサービスの識別 — グラフ中心性分析を使ってインフラストラクチャサービスであるアプリを特定し、どれを最初にポリシー化すべきかを把握できます
• 拒否ルールの管理 — 拒否ルールの作成、更新、削除（緊急時のオーバーライド拒否を含む）
• ルールをその場で編集 — ルールセットを再構築せずに update-sec-rule／delete-sec-rule を使用できます
• イベント監視 — 重大度とタイプで絞り込んで PCE イベントをクエリできます
• PCE のヘルスチェック — 接続と認証情報を確認できます
• 変更内容を通知 — get-server-changelog は、キャッシュされたツールリストが古いセッションに動作の変更を報告します

前提条件

• Python 3.12 または 3.13（pyproject.toml の requires-python を参照）
• Illumio PCE インスタンスへのアクセス
• PCE 用の有効な API 認証情報

インストール

1. リポジトリをクローンします。

git clone https://github.com/alexgoller/illumio-mcp-server.git
cd illumio-mcp-server

2. 依存関係をインストールします。

uv sync

設定

環境変数を渡しやすく、バックグラウンドで実行できる uv コマンドを使って実行してください。

uv と Claude Desktop の使用

MacOS の場合：~/Library/Application\ Support/Claude/claude_desktop_config.json Windows の場合：%APPDATA%/Claude/claude_desktop_config.json

custom_settings セクションに以下を追加します。

"mcpServers": {
    "illumio-mcp": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/illumio-mcp-server",
        "run",
        "illumio-mcp"
      ],
      "env": {
        "PCE_HOST": "your-pce-host",
        "PCE_PORT": "your-pce-port",
        "PCE_ORG_ID": "1",
        "API_KEY": "api_key",
        "API_SECRET": "api_secret"
      }
    }
  }
}

OAuth リソースサーバーを使用した HTTP トランスポート（Phase 3a）

サーバーは MCP Streamable HTTP トランスポート（仕様の改訂版 2025-03-26）を使用して HTTP 経由で実行され、IdP が発行した OAuth 2.1 ベアラートークンを検証します。これは Phase 3a です。ID は適用されますが、ユーザーごとの PCE キーは Phase 3b で導入されます。

認証ありでの実行（本番環境を想定）

export MCP_PUBLIC_URL=https://mcp.illumio.example
export MCP_OAUTH_ISSUER=https://login.microsoftonline.com/<tenant-id>/v2.0
export MCP_OAUTH_JWKS_URL=https://login.microsoftonline.com/<tenant-id>/discovery/v2.0/keys
export MCP_OAUTH_AUDIENCE=https://mcp.illumio.example
export MCP_OAUTH_REQUIRED_SCOPE=illumio-mcp.use   # default; override if needed
illumio-mcp-http --host 127.0.0.1 --port 8080

MCP_DEV_INSECURE=1 を指定しない限り、サーバーはこれらの環境変数が設定されていないと起動しません。

MCP クライアントは、標準の RFC 9728 エンドポイントを介して AS を検出します。

GET /.well-known/oauth-protected-resource

/mcp への未認証リクエストは、WWW-Authenticate: Bearer resource_metadata="<URL>" を含む 401 を返します。仕様に準拠した MCP クライアント（Claude Desktop、ChatGPT、MCP Inspector）はこれに従い、設定済みの AS に対して PKCE 認可コードフローを自動的に実行します。

認証なしでの実行（開発専用）

MCP_DEV_INSECURE=1 illumio-mcp-http

サーバーは目立つ警告をログに記録します。本番環境では使用しないでください。

ヘルスエンドポイント（常に認証不要）

• GET /healthz — 稼働状態
• GET /readyz — 準備状態（Phase 3a では healthz と同じ内容を返します。Phase 3b/c では PCE と JWKS への到達性が追加されます）

2 つの PCE モード（Phase 3b と Phase 3e）

HTTP サーバーでは、PCE 認証情報の取得方法として 3 つのモードをサポートしています。MCP_PCE_MODE で選択します。

モード	MCP_PCE_MODE	PCE 認証情報	オンボーディング	PCE 側の監査
ユーザーごと（デフォルト）	per_user	認証済みユーザーごとに 1 つの PCE API キーをキーストアに暗号化して保存	ユーザーは /setup ページまたは register-pce-credentials ツールで登録します	PCE のログには、ユーザーごとの API キーを通じて実際の人間が記録されます
共有	shared	環境変数から取得する PCE サービスアカウントキー 1 つ（stdio と同じ）	なし — 認証済みユーザーなら誰でもすぐに利用できます	PCE のログにはサービスアカウントが記録されます。「誰が何をしたか」の正確な記録は MCP 監査ログです
ハイブリッド	hybrid	ユーザーが登録済みの場合はユーザーごとのキー、それ以外の場合は共有サービスアカウント	任意 — すぐに利用できます。/setup でユーザーは記録の対象になることを選べます	意図的に混在：登録済みのユーザーは人間、それ以外はサービスアカウントです。どちらが適用されたか判別できるよう、すべての MCP 監査行に effective_pce_mode が記録されます

ユーザーごとのモードを選ぶ場合：

• PCE 側の監査で実際の人間を特定したい場合
• ユーザーが自分の PCE API キーを一度提供することに同意する場合
• ユーザーごとに PCE キーが増えることを許容できる場合（PCE には上限があります）

共有モードを選ぶ場合：

• PCE のユーザーごとの API キー数の上限が、ユーザーごとのモードには低すぎる場合
• オンボーディングの手間をなくしたい場合（/setup の手順なし）
• 人間レベルの記録は MCP 監査ログだけに頼ってもよい場合
• PCE サービスアカウントを自分で管理し、定期的にローテーションする場合

ハイブリッドモードを選ぶ場合：

• 共有モードで運用を開始し、段階的にユーザーごとのモードへ移行したい場合
• 全員にオンボーディングを強制せず、一部のユーザーについて PCE 側で名前を特定できる監査がコンプライアンス上必要な場合
• PCE 監査ログに異なるモードが混在することを受け入れ、MCP 監査ログの effective_pce_mode を確認する場合

ハイブリッドモードでは、共有環境変数（PCE_*、API_*）と MCP_KEK の両方が必要です。どちらかがない場合、起動を拒否します。check-pce-credentials-status は、呼び出し元ユーザーにこのリクエストで適用されるモードを報告します。保存済みのキーが存在するものの使用できず、サービスアカウントとして呼び出しが実行された場合も含みます。

共有モードでは、/setup はマウントされず、認証情報管理ツール（register-pce-credentials、delete-pce-credentials）はわかりやすいエラーを返して処理を拒否します。また、MCP_KEK は不要です。SSO、JWT、ロールベースの認可、監査ログ、確認トークンはすべて、引き続き同じように適用されます。

# Shared mode — same env that stdio uses today, plus auth/role config
export MCP_PCE_MODE=shared
export PCE_HOST=https://your-pce.example.com
export PCE_PORT=8443
export PCE_ORG_ID=1
export API_KEY=your_pce_api_key_name
export API_SECRET=your_pce_api_key_secret
# (other auth/role env vars from earlier sections still apply)
illumio-mcp-http

ユーザーごとの PCE キー（Phase 3b）

認証済みの各ユーザーは、暗号化された SQLite キーストアに保存された専用の PCE API キー／シークレットを持ちます。PCE 側の監査ログでは各ユーザーが正しく記録され、ユーザーのアクセス権はツールを 1 回呼び出すだけで取り消せます。

認証を有効にして実行する場合に必要な追加の環境変数：

export MCP_KEK=$(python -c 'import os, base64; print(base64.b64encode(os.urandom(32)).decode())')
export MCP_KEYSTORE_PATH=/var/lib/illumio-mcp/keys.db   # default: ./data/keys.db

KEK はデータベースの隣に保存されることはありません。KEK を失うと、保存された認証情報はすべて失われます（意図的なフェイルクローズ動作です）。本番環境では、オペレーターのシェルではなく、KMS または Vault から MCP_KEK を取得してください。

オンボーディングの方法（どちらでも利用できます）：

1. ブラウザー — 認証後に /setup にアクセスし、フォームに認証情報を貼り付けます。
2. MCP クライアント — register-pce-credentials ツールを呼び出します。このツールは、認証情報が登録される前に利用できる唯一のツールです。

その他の認証情報ツール：

• check-pce-credentials-status — このユーザーの認証情報が登録されているか確認します。
• delete-pce-credentials — このユーザーの認証情報を削除します。

ロールベースの認可（Phase 3c）

サーバーは各ユーザーの IdP グループを、内部ロールの 3 種類（reader、operator、admin）のいずれかに割り当てます。ツールごとの認可は、各 ToolSpec の roles メタデータを使用してディスパッチャーが適用します。

グループからロールへのマッピングは、環境変数で設定します（カンマ区切り）：

# A user matching ANY of these groups gets that role; highest role wins.
export MCP_ROLE_GROUPS_ADMIN=sg-illumio-mcp-admin
export MCP_ROLE_GROUPS_OPERATOR=sg-illumio-mcp-operator,sg-illumio-mcp-admin
export MCP_ROLE_GROUPS_READER=sg-illumio-mcp-readonly,sg-illumio-mcp-operator,sg-illumio-mcp-admin

# Optional: fallback role when no group matches. Leave unset to refuse.
# export MCP_ROLE_DEFAULT=reader

ツールごとのデフォルト設定：

ツールのカテゴリ	許可されるロール	例
読み取り	reader, operator, admin	get-labels、get-workloads、get-traffic-flows
書き込み	operator, admin	create-*、update-*、delete-*
プロビジョニングおよび一括処理	admin	provision-policy、ringfence-batch

該当するロールがなく、MCP_ROLE_DEFAULT も設定されていないユーザーには、構造化された forbidden_no_role エラーが返されます。

監査ログ（Phase 3c）

ディスパッチャーによるすべての判断（許可／拒否／エラー）は、SQLite 監査データベースに書き込まれます。スキーマと保存場所：

# Defaults to <keystore_dir>/audit.db
export MCP_AUDIT_LOG_PATH=/var/lib/illumio-mcp/audit.db

監査行には (ts, sub, iss, tool, decision, reason, role, request_id) が含まれます。ツールの引数は記録されません。request_id はレスポンスヘッダー X-Request-Id と一致するため、外部のトレースと関連付けられます。

クエリの例：

-- Recent denied calls per user
SELECT ts, sub, tool, reason FROM audit_log
WHERE decision='denied'
ORDER BY ts DESC LIMIT 20;

-- Tool-call volume by user
SELECT sub, COUNT(*) FROM audit_log
WHERE ts > date('now', '-7 days')
GROUP BY sub ORDER BY 2 DESC;

変更を伴うツールの確認トークン（Phase 3d）

requires_confirm=True に設定されたツール（現在は provision-policy、ringfence-batch、register-pce-credentials、delete-pce-credentials）を HTTP 経由で呼び出す場合、サーバーが発行する 1 回限りの確認トークンを params._meta.confirm_token に指定する必要があります。Stdio モードには影響しません。プロセスを起動したオペレーターは、変更を伴うツールを直接呼び出せます。

認証モードで必要な環境変数：

export MCP_CONFIRM_HMAC_KEY=$(python -c 'import os, base64; print(base64.b64encode(os.urandom(32)).decode())')
# Optional:
# export MCP_CONFIRM_TTL_SECONDS=120
# export MCP_CONFIRM_JTI_PATH=/var/lib/illumio-mcp/jti.db
# export MCP_CONFIRM_FRESH_AUTH_SECONDS=300   # require JWT auth_time within 5 min

クライアントでの使用方法

1. トークンなしで変更を伴うツールを呼び出すと、サーバーから次の内容が返されます：

   {"error": "confirm_required", "params_hash": "<sha256>", "message": "..."}
   

2. JWT と params_hash を指定して POST /confirm を呼び出します：

   curl -X POST https://mcp.illumio.example/confirm \
     -H "Authorization: Bearer $JWT" \
     -H "Content-Type: application/json" \
     -d '{"tool":"provision-policy","params_hash":"<sha256>"}'
   # → {"confirm_token": "...", "expires_in": 120}
   

3. params._meta.confirm_token にトークンを指定して、ツールを再度呼び出します。

トークンは1 回限りで（再使用すると confirm_token_replay が返されます）、(sub, tool, params_hash) にスコープが限定されます。いずれかのフィールドを改ざんすると、トークンは無効になります。

ステップアップ認証（任意、本番環境では推奨）

MCP_CONFIRM_FRESH_AUTH_SECONDS=300 を設定すると、JWT の auth_time クレームが過去 5 分以内であることを必須にできます。トークンを発行する前にユーザーの再認証を強制します。これは、インタラクティブなセッションモデルなしで実現できる最も強力なプロンプトインジェクション対策です。IdP が auth_time を発行する必要があります（Entra と Okta はどちらも OIDC サインインフローで発行します）。

ツール

ワークロード管理

• get-workloads — 名前、ホスト名、IP、ラベルによる任意の絞り込みと最大件数の指定を使って、ワークロードを取得します。
• create-workload — 名前、IP アドレス、ラベルを指定して、管理対象外のワークロードを作成します。
• update-workload — 既存のワークロードのプロパティを更新します。
• delete-workload — PCE からワークロードを削除します。

ラベル操作

• get-labels — キー、値による任意の絞り込みと最大件数の指定を使って、ラベルを取得します。
• create-label — キーと値のペアを指定して、新しいラベルを作成します。
• update-label — 既存のラベルを更新します。
• delete-label — ラベルを削除します。

ルールセットとルールの管理

• get-rulesets — 名前、説明、有効状態で任意にフィルタリングしてルールセットを取得します
• create-ruleset — スコープを指定して新しいルールセットを作成します
• update-ruleset — ルールセットのプロパティを更新します
• delete-ruleset — ルールセットを削除します
• create-deny-rule — ルールセットに拒否ルール（通常またはオーバーライド拒否）を作成します
• update-deny-rule — 既存の拒否ルールを更新します
• delete-deny-rule — 拒否ルールを削除します

IP リストの管理

• get-iplists — 構造化された ip_ranges と fqdns、pversion の draft|active、Any リストの is_default、およびアドレスを対象にサーバー側で正確に「どのリストがこのアドレスをカバーしているか」を検索する contains_ip を含む IP リストを取得します
• create-iplist — 新しい IP リストを作成します
• update-iplist — 既存の IP リストを更新します
• delete-iplist — IP リストを削除します

サービスの管理

• get-services — 名前、ポート、プロトコル、最大結果数で任意にフィルタリングしてサービスを取得します
• create-service — 新しいサービス定義を作成します
• update-service — 既存のサービスを更新します
• delete-service — サービスを削除します

トラフィック分析

• get-traffic-flows — 日付範囲、送信元／宛先、サービス、ポリシーの判定などでフィルタリングして、詳細なトラフィックフローデータを取得します
• get-traffic-flows-summary — アプリ、環境、ポート、プロトコル別にグループ化された、集計済みのトラフィック概要を取得します

自動リングフェンシング

• create-ringfence — アプリ間のセグメンテーションポリシーを自動作成します。 トラフィックフローを分析して、対象アプリと通信しているリモートアプリを特定し、次のルールを含むルールセットを作成します。
  • スコープ内許可ルール — アプリ内のすべてのワークロードが自由に通信できるようにします
  • スコープ外許可ルール — 特定された各リモートアプリに対し、All Services の許可ルールを作成します
  • 選択的適用モード（selective=true）— 既知のアプリに対する許可ルールを先に処理し、すべてのインバウンド通信をブロックする拒否ルールを追加します。全面適用モードよりも早く適用を開始できます。
  • 拒否コンシューマーの種類（deny_consumer パラメーター）：
    • any（デフォルト）— コンシューマーとして IP リスト Any（0.0.0.0/0）を使用し、宛先でのみ拒否します。最も安全です。
    • ams — コンシューマーとして All Workloads を使用し、管理対象のすべてのワークロードに拒否ルールを適用します。より広範囲に適用されます。
    • ams_and_any — 両方を使用します。最大限の範囲をカバーします。
  • ポリシーの適用範囲の認識 — 各ルールには、already_allowed（既存のポリシーでトラフィックがカバーされており、ドキュメント化のために作成）または newly_allowed（ポリシーの不足を補完）という注釈が付きます。概要には、すでにカバーされているリモートアプリと、新しいルールが必要なリモートアプリの数が表示されます。
  • skip_allowed パラメーター — true に設定すると、既存のポリシーでまだカバーされていないトラフィックに対するルールのみを作成し、不足分だけを補う最小限のルールセットを生成します
  • マージに安全 — 既存のルールセットとルールを検出し、重複を作成しません
  • ドライランに対応 — 変更を加えずに、作成される内容をプレビューできます

インフラストラクチャサービスの特定

• identify-infrastructure-services — トラフィックパターンを分析して、インフラストラクチャサービスであるアプリを特定します。アプリ間の通信グラフを作成し、2種類のパターンに基づくスコアリングを用いてインフラストラクチャを認識します。

  プロバイダーインフラ（AD、DNS、共有 DB）— 多数のアプリから利用され、入次数が高く、出次数が低いサービスです。 コンシューマーインフラ（監視、バックアップ、ログ転送）— 多数のアプリへ接続し、出次数が高く、入次数が低いサービスです。

  アプリごとに2種類のスコアを算出し、高い方を採用します。

  スコア	次数指標（40%）	方向性（30%）	媒介中心性（25%）	トラフィック量（5%）
  プロバイダー	入次数	コンシューマー比率（入次数/合計）	媒介中心性	接続量
  コンシューマー	出次数	プロデューサー比率（出次数/合計）	媒介中心性	接続量

  混合トラフィックの減点： score *= 1 / (1 + min(in_degree, out_degree) * 0.3) — インバウンド接続とアウトバウンド接続がどちらも多いアプリは、インフラストラクチャではなくビジネスアプリです。方向性が明確なアプリ（すべてがインバウンド、またはすべてがアウトバウンド）には減点されません。

  非本番環境（ステージング、開発など）は、インフラストラクチャサービスが通常本番環境で稼働するため、スコアが50%減点されます。

  アプリは次の階層に分類されます。

  • コアインフラストラクチャ（スコア >= 75）— 監視、AD、SIEM、DNS。最初にポリシーを適用してください。
  • 共有サービス（スコア >= 50）— 共有データベース、メッセージキュー。次にポリシーを適用してください。
  • 標準アプリケーション（スコア < 50）— 通常のビジネスアプリです。

  各結果には dominant_pattern フィールド（"provider" または "consumer"）が含まれ、アプリがどちらの種類のインフラストラクチャに近いかを示します。

  この機能が重要な理由： インフラストラクチャサービスは、多数のアプリから利用されるか、多数のアプリへ接続します。インフラストラクチャサービスを先に許可せずにアプリをリングフェンスすると、依存関係が壊れます。このツールを使うと、どれを先にポリシー適用すべきかが分かります。

ポリシーのライフサイクル

• provision-policy — 保留中のドラフト変更をプロビジョニングして、ドラフト状態からアクティブ状態へ移行します。すべての保留中の変更、または href を指定した個別の項目をプロビジョニングできます。監査証跡用の変更説明も含まれます。
• compare-draft-active — ドラフトポリシーとアクティブポリシーを比較し、プロビジョニング時に何が変更されるかを事前確認できます。作成、更新、削除されるルールセット、ルール、IP リスト、サービスが表示されます。

適用準備状況

• enforcement-readiness — アプリが適用可能な状態かどうかを評価します。トラフィックフロー、既存のポリシー適用範囲、適用モード、リングフェンスの状態を分析します。実行可能な推奨事項とともに、準備状況スコア（0～100）を返します。
  • ポリシー適用範囲（40ポイント）— ルールでカバーされるトラフィックの割合
  • リングフェンスの存在（20ポイント）— リングフェンスのルールセットが作成されているか
  • 適用モード（20ポイント）— ワークロードが full/selective/visibility_only のいずれかに設定されているか
  • ブロックされたトラフィックがないこと（10ポイント）— 意図しないブロックがないか
  • すべてのリモートアプリがカバーされていること（10ポイント）— カバーされていないリモートアプリのトラフィックがないか

一括操作

• ringfence-batch — 複数のアプリを一度にリングフェンスします。必要に応じて identify-infrastructure-services を使い、インフラストラクチャスコアに基づいてアプリの順序を自動設定できます（インフラストラクチャを先に、その後に標準アプリ）。変更を適用する前にすべて確認できるドライランモードに対応しています。

ワークロードの適用状況

• get-workload-enforcement-status — ワークロード全体の適用モードの状態を取得し、アプリと環境ごとにグループ化して表示します。モード別（idle、visibility_only、selective、full）の件数を示し、ロールアウト中によく発生する、適用状態が混在しているアプリを特定します。

ポリシーのカバレッジ

• get-policy-coverage-report — アプリのポリシーカバレッジレポートを生成し、既存のルールでカバーされるトラフィックとブロックされるトラフィックを表示します。インバウンド／アウトバウンド別に内訳を示し、カバーされていないサービスやリモートアプリを特定して、全体のカバレッジ率を提示します。
• find-unmanaged-traffic — 管理対象外のワークロードまたは IP アドレスが関与するトラフィックを検出します。これらはアプリ／環境ラベルのない送信元／宛先であり、ポリシーの盲点となります。方向（インバウンド／アウトバウンド／両方）と接続数でフィルタリングできます。

セキュリティ分析

• detect-lateral-movement-paths — アプリ間のトラフィックパターンを分析して、ラテラルムーブメントの潜在的な経路を検出します。侵害されると、通常は接続されていないアプリグループへのアクセスを可能にする関節点（ブリッジノード）を特定します。任意の開始アプリからの到達可能性を計算し、設定可能な深さまで複数ホップの経路を追跡します。
• compliance-check — フレームワーク（PCI-DSS、DORA、NIS2、NIST 800-53、CIS Controls、ISO 27001、SWIFT CSP、HIPAA、または一般的なベストプラクティス）に照らして、ポリシーの状態をまず確認します。ドラフトポリシーと最近のトラフィックに対するキーワードベースのヒューリスティックを用い、各チェックの結果（PASS/FAIL/WARNING）を含むスコアとして要約します。監査証拠ではありません。
• collect-compliance-evidence — アプリ／環境のスコープペアごとに、セグメンテーション制御の監査証拠を、アクティブなポリシーと観測されたトラフィックから収集します。対象には、インベントリ、適用状況、VEN の健全性、管理対象外のワークロード、説明された提供ルール、広範なコンシューマーが存在しないこと、承認済みリストと照合した許可サービス、ブロックされたフローのタイムラインを含むインバウンド／アウトバウンドの境界越え、ドラフトとアクティブの差異、ウィンドウ内のイベントとフローが含まれます。テストとペアごとに、ルール、測定値、該当行とともに PASS/FAIL/EXCEPTION/NOT_TESTED を示します。取得件数に上限がある場合、合格とはなりません。フレームワークのマッピングは illumio://compliance/* リソースにあります。

イベント監視

• get-events — イベントタイプ、重大度、ステータス、および結果の上限を指定してフィルタリングし、PCE イベントを取得します。

接続テスト

• check-pce-connection — PCE の接続と認証情報を確認します。

テスト

このプロジェクトには、MCP プロトコルを使用して実際の PCE に対して実行する、包括的な統合テストスイートが含まれています。

# Set up credentials in .env
cat > .env << EOF
PCE_HOST=your-pce-host
PCE_PORT=8443
PCE_ORG_ID=1
API_KEY=your-api-key
API_SECRET=your-api-secret
EOF

# Run all tests
uv run pytest tests/ -v

テストスイートでは、以下を確認します。

• ツールの一覧表示とスキーマの検証
• ワークロード、ラベル、IP リスト、サービス、ルールセット、拒否ルールの CRUD ライフサイクル全体
• トラフィックフローのクエリと要約
• リングフェンスの作成（標準、選択的、コンシューマー拒否の各方式、マージの冪等性）
• インフラストラクチャサービスの特定（スコアリング、並べ替え、階層分類）
• リソースが見つからない場合のエラー処理

Illumio のルール処理順序

リングフェンスを設定するうえで、ルールの処理順序を理解することが重要です。

1. 必須ルール — 組み込みルールであり、変更できません
2. オーバーライド拒否ルール — すべての許可ルールに優先してトラフィックをブロックします（緊急時に使用）
3. 許可ルール — トラフィックを許可します（リングフェンスのリモートアプリルールはここに配置します）
4. 拒否ルール — 特定のトラフィックをブロックします（リングフェンスのインバウンド全拒否ルールはここに配置します）
5. デフォルトアクション — 選択的モードではすべて許可、完全適用ではすべて拒否

選択的適用ではデフォルトがすべて許可のため、リングフェンスを有効にするには拒否ルールが必要です。既知のリモートアプリには許可ルール（ステップ 3）が設定され、拒否ルール（ステップ 4）より先に処理されます。

ビジュアル例

以下の例はすべて、Claude Desktop がこの MCP サーバーを通じて取得したデータを使って生成したものです。

アプリケーション分析

アプリケーションの通信パターンと依存関係の詳細ビュー

異なるアプリケーション階層間のトラフィックパターンの分析

インフラストラクチャの分析

主要なインフラストラクチャの指標とステータスを表示する概要ダッシュボード

インフラストラクチャサービス間の通信に関する詳細な分析

セキュリティ評価

包括的なセキュリティ分析レポート

高リスクの脆弱性に関するセキュリティ評価の検出結果

PCI コンプライアンス評価の検出結果

SWIFT コンプライアンス評価の検出結果

修復計画

セキュリティ修復計画の概要

セキュリティ修復を実施するための詳細な手順

ポリシー管理

IP リストの管理インターフェース

ルールセットのカテゴリと構成の概要

アプリケーションルールセットの順序の設定

ワークロード管理

ワークロードの詳細な分析と指標

ワークロードのトラフィックパターンの特定と分析

ラベル管理

タイプとカテゴリ別に整理された PCE ラベル

サービス分析

トラフィックパターンに基づくサービスロールの自動推定

上位 5 件のトラフィック送信元と宛先の分析

プロジェクト計画

プロジェクトの実施スケジュールとマイルストーン

利用可能なプロンプト

アプリケーションのリングフェンス化

ringfence-application プロンプトは、インバウンドおよびアウトバウンドのトラフィックを制御してアプリケーションを隔離・保護するセキュリティポリシーの作成を支援します。

必須引数：

• application_name：リングフェンス化するアプリケーションの名前
• application_environment：リングフェンス化するアプリケーションの環境

機能：

• アプリケーション内の各ティア間の通信に関するルールを作成します
• トラフィックフローを使用して、必要な外部接続を特定します
• 送信元アプリケーションに基づいてインバウンドトラフィックを制限します
• 必要な外部通信のためのアウトバウンドトラフィックルールを作成します
• スコープ内（同じアプリ／環境）とスコープ外（外部）の接続を両方処理します
• リモートアプリケーション接続用に個別のルールセットを作成します

アプリケーショントラフィックの分析

analyze-application-traffic プロンプトは、アプリケーションのトラフィックパターンと接続性を詳細に分析します。

必須引数：

• application_name：分析するアプリケーションの名前
• application_environment：分析するアプリケーションの環境

分析機能：

• トラフィックをインバウンドおよびアウトバウンドのフロー別に並べ替えます
• アプリケーション／環境／ロールの組み合わせごとにグループ化します
• 関連するラベルタイプとパターンを特定します
• React コンポーネント形式で結果を表示します
• プロトコルとポートの情報を表示します
• 既知のサービスパターン（例：ポート 5666 の Nagios）の特定を試みます
• トラフィックをインフラストラクチャタイプとアプリケーションタイプに分類します
• インターネットへの公開状況を判定します
• Illumio のロール、アプリケーション、環境のラベルを表示します

MCP プロンプトの使用方法

Step1：インターフェースの「Attach from MCP」ボタンをクリックします

Step 2：インストール済みの MCP サーバーから選択します

Step 3：必須のプロンプト引数を入力します：

Step 4：「Submit」をクリックして、設定したプロンプトを送信します

プロンプトの仕組み

• MCP サーバーが設定したプロンプトを Claude に送信します
• Claude は Model Context Protocol を通じてコンテキストを受け取ります
• Illumio 固有のタスクを専門的に処理できます

このワークフローにより、アプリケーショントラフィックの分析やリングフェンシングのタスクにおいて、Illumio システムと Claude の間でコンテキストを自動的に共有できます。

Docker

このアプリケーションは、GitHub Container Registry から Docker コンテナとして利用できます。

コンテナを取得する

docker pull ghcr.io/alexgoller/illumio-mcp-server:latest

latest をバージョン番号に置き換えて、特定のバージョンを使用することもできます：

docker pull ghcr.io/alexgoller/illumio-mcp-server:1.0.0

Claude Desktop で実行する

コンテナを Claude Desktop で使用するには、次の手順が必要です：

1. PCE の認証情報を含む環境ファイル（例：~/.illumio-mcp.env）を作成します：

PCE_HOST=your-pce-host
PCE_PORT=your-pce-port
PCE_ORG_ID=1
API_KEY=your-api-key
API_SECRET=your-api-secret

2. 次の設定を Claude Desktop の設定ファイルに追加します：

MacOS の場合（~/Library/Application Support/Claude/claude_desktop_config.json）：

{
    "mcpServers": {
        "illumio-mcp-docker": {
            "command": "docker",
            "args": [
                "run",
                "-i",
                "--init",
                "--rm",
                "-v",
                "/Users/YOUR_USERNAME/tmp:/var/log/illumio-mcp",
                "-e",
                "DOCKER_CONTAINER=true",
                "-e",
                "PYTHONWARNINGS=ignore",
                "--env-file",
                "/Users/YOUR_USERNAME/.illumio-mcp.env",
                "illumio-mcp:latest"
            ]
        }
    }
}

以下を確認してください：

• YOUR_USERNAME を実際のユーザー名に置き換える
• ログディレクトリ（例：~/tmp）を作成する
• システムに合わせてパスを調整する

単独で実行する

コンテナを直接実行することもできます：

docker run -i --init --rm \
  -v /path/to/logs:/var/log/illumio-mcp \
  -e DOCKER_CONTAINER=true \
  -e PYTHONWARNINGS=ignore \
  --env-file ~/.illumio-mcp.env \
  ghcr.io/alexgoller/illumio-mcp-server:latest

Docker Compose

開発またはテストには、Docker Compose を使用できます：

version: '3'
services:
  illumio-mcp:
    image: ghcr.io/alexgoller/illumio-mcp-server:latest
    init: true
    volumes:
      - ./logs:/var/log/illumio-mcp
    environment:
      - DOCKER_CONTAINER=true
      - PYTHONWARNINGS=ignore
    env_file:
      - ~/.illumio-mcp.env

次に、以下を実行します：

docker-compose up

コントリビュート

1. リポジトリをフォークします
2. 機能ブランチを作成します
3. 変更をコミットします
4. ブランチにプッシュします
5. プルリクエストを作成します

ライセンス

このプロジェクトは GPL-3.0 ライセンスの下でライセンスされています。詳細については、LICENSE ファイルを参照してください。

サポート

サポートが必要な場合は、issue を作成してください。