2026年10月27日整理／企業・学校・団体などの組織内ネットワークとクラウド向け
注：技術の適用範囲・料金は変更されます。本稿の設計は無条件の安全性を保証するものではありません。
なぜ「仕組み」で守るのか
新技術を禁止するだけでは、利用状況が把握できず、事故時の説明も難しくなります。必要なのは、誰が何を許可し、どんな条件で停止し、どう復旧したかを技術的な証拠で示す仕組みです。
ホールディングスの場合、共通の最低統制基準・監督・報告と、各子会社の運用・法的責任を分けて定義します。経営層が確認すべき項目は、資産台帳、リスク、承認、遮断能力、監査、継続更新、活用効果の7つです。
1. 全体像：6層の強制点
以下は異なる製品や技術を組み合わせた提案構成です。
重要な違い：Cedar/OPAが判断する部分はPDP（Policy Decision Point）、APIやMCPで実際に遮断する部分はPEP（Policy Enforcement Point）です。PDPが正しくてもPEPを迂回されたら守れません。
2. 各技術は何をする？ 導入方法・コスト・メリデメ
① 経営・管理統制
- 仕組み：承認されたAI、モデル、MCP、データ、接続先、責任者、例外、有効期限を一元管理。
- 導入：資産棚卸し → データ分類 → リスク評価 → 承認フロー → 期限切れの自動再審査。
- コスト：台帳・ワークフロー製品、運用人員、教育、監査。既存ITSMの活用で低減可能。
- 利点：経営・顧客への説明が可能。限界：規程だけでは操作を止められない。
② IAM・SSO・PAM：本人とAIの身元確認
- 仕組み：OIDC等による認証、MFA、多数のサービスへのSSO、管理者の一時的権限（JIT）、短命トークン。
- 導入：既存IDプロバイダーと統合 → Agent/サービスの身元識別 → 長期鍵の削減 → 管理者の特権操作を監査。
- コスト：ユーザー数や特権ID数によるライセンス、構築費、監査保存。
- 利点：安全性とログインの利便性を両立。限界：正規IDが乗っ取られれば追加の行動制御が必要。
③ Cedar / Amazon Verified Permissions / OPA：操作ごとの認可
Cedar は「誰（principal）が、どの操作（action）を、どの資源（resource）に、どんな条件（context）で実行できるか」を定義する認可言語。Amazon Verified Permissions はCedarを使うマネージドサービスです。
OPA（Open Policy Agent）はRegoでルールを記述し、API・クラウド・CIなどで評価するOSSです。
- 導入：操作一覧を作成 → ポリシーを定義 → 権限漏れのテスト → API/MCPの実行直前に必ず照会 → エラー時に拒否。
- コスト：Cedar/OPAのOSSライセンス費は基本的に不要。ただし連携開発、ポリシー管理、ログ、可用性、保守費は必要。Verified Permissionsは従量課金。
- 公開料金例：AWS公式の単一承認API料金が US$0.000005/件 の場合、500万件は US$25/月（認可APIのみ。実際の適用区分と最新料金を確認）。
- 利点：権限ルールをサービス横断で統制。限界：直接DB接続などの迂回経路、取得済みデータの外部送信は別対策が必要。
④ IFC・DLP：情報フローと持ち出し制御
「閲覧を許可する」と「外部へ送信する」を別々に審査します。
- 仕組み：機密度ラベルをデータに付与し、AIが利用するツール間のデータ移動を追跡。送信前に内容・宛先・目的を照合。
- 導入：データ分類 → ラベル付与 → メール・HTTP・MCPの出口へ検査を集約 → ダミー機密データで遮断を試験。
- コスト：分類と運用、DLPのライセンス、検査量、誤検知の確認工数。
- 利点：正しく閲覧した情報でも不正な外部送信を抑えられる。限界：未把握の通信経路、暗号化データ、ラベル消失などが難題。
⑤ Sandbox・Egress Proxy・テナント分離
- 仕組み：AIが実行できるファイル・プロセス・ネットワークを限定。顧客Aの侵害から顧客Bや管理基盤への横展開を防ぐ。
- 導入：独立した実行環境 → 秘密情報の非マウント → 出口プロキシ → ネットワークのデフォルト拒否 → 境界を突破する試験。
- コスト：VM/コンテナ、プロキシ、EDR、ネットワーク、監視と運用。
- 利点：侵入後の被害を局所化。限界：ホストや管理基盤そのものの侵害、許可済み送信先への情報流出は残る。
参照：Anthropic Sandbox Runtime・NIST Zero Trust
⑥ SIEM・SOAR・SOC・復旧
- 仕組み：認証主体、AI Agent、ツール実行、ポリシー版、許可理由などを保護対象と独立したログへ保存。異常時に認証失効・環境隔離・バックアップ復旧。
- 導入：監査イベントの定義 → ログ収集 → 検知条件の設定 → 停止演習 → 不変バックアップから別環境へ復旧。
- コスト：ログGB、保存年数、SOC人員、EDR端末数、復旧インフラ、演習費用。
- 利点：インシデント後の説明と早期復旧。限界：誤検知・検知漏れ・アラート過多・復旧の未検証。
3. Nyxisと類似技術の比較
| 技術 | 位置づけ | 強み | 注意点 |
|---|---|---|---|
| Nyxis | Lean 4による認可安全性の形式検証 | 特定の安全条件を証明する設計 | 無条件の情報漏洩防止ではない |
| Cedar / Verified Permissions | 認可ルールとマネージドPDP | 共通ポリシー管理 | 実際の強制はアプリ側のPEP |
| OPA / Rego | 汎用Policy as Code | クラウド横断の柔軟性 | 保守・ポリシー配布の設計が必要 |
| Microsoft Agent Governance Toolkit | Agent/MCPツール実行統制 | ツール呼出し前の制御 | すべての実行経路を統制するとは限らない |
| IBM SAMOS | Agent情報フローの研究 | 操作をまたぐ漏洩対策への着眼 | 研究と商用の成熟度を分けて評価 |
| Google Agent Gateway系 | AIの登録・認証・ツール接続統制 | 管理サービス連携 | サービスごとに価格・提供状況を確認 |
| Anthropic Sandbox Runtime | AIコードの隔離実行 | OS側で動作範囲を縮小 | 許可されたAPIへの漏洩は別対策 |
Nyxisの数学的証明が正しくても、JWT処理、DB、外部通信、環境設定など証明対象外の前提が残ります。「どこまで証明しているか」と「何を信頼しているか」を分けて読むことが重要です。
4. GMO型の攻撃を想定した合格テスト
GMO事案の具体的な侵入経路を断定するものではありません。同種の顧客環境侵害を想定した評価表です。
| 攻撃・事故 | 必須の防御 | 合格を示す証拠 |
|---|---|---|
| 顧客VMへマルウェア侵入 | VM・テナント・管理面の分離、EDR | 別テナントへの横展開阻止試験 |
| 保存済み認証情報の窃取 | 保管分離、MFA、短命鍵、即時失効 | 漏洩時の影響・失効時間の測定 |
| 不正な外部送信 | Egress Proxy、DLP、内容分類 | ダミー機密情報の送信遮断 |
| 管理者アカウント侵害 | PAM・JIT・多者承認・管理面分離 | 不正な権限昇格の阻止試験 |
| ランサムウェア | 不変バックアップ・独立復旧 | 目標RPO/RTOの復旧演習 |
| 広域サービス停止 | セル/テナント単位の隔離 | 非対象への影響を抑えた停止・復旧試験 |
DBのロールバックだけでは、送信済みメールや外部APIへの副作用は取り消せません。 Transactional Outbox、冪等性、重要送信の承認も必要です。
5. 90日間の導入ロードマップ
技術の合格基準は、許されない操作を本当に止められること、すべての経路で統制されること、原因を追跡できること、侵入後も復旧できること。単に製品を導入したという報告では足りません。
6. コストの見積り方
| 項目 | 算出に必要な数値 |
|---|---|
| 認可API | 月間認可件数、API種別、単価 |
| ID管理 | 人数、管理対象、特権ID数 |
| 情報流出対策 | データ量、送信検査数、ライセンス |
| 実行隔離 | VM/コンテナ、プロキシ帯域、EDR |
| 監査 | ログ量、保存期間、SOC監視工数 |
| 復旧 | バックアップ容量、待機設備、復旧演習 |
| 運用改善 | 審査・テスト・教育・ポリシー更新工数 |
初期導入費だけでなく、顧客損失の可能性、被害範囲、事業停止時間、信用への影響、業務の利便性を一緒に評価します。
用語集
| 略語 | 意味 |
|---|---|
| MCP | AIと外部ツールをつなぐ接続仕様 |
| PDP / PEP | 認可の判断点 / その判断を実際に強制する点 |
| IAM / PAM | ID・アクセス管理 / 特権アクセス管理 |
| SSO / OIDC / MFA | 共通ログイン / 認証規格 / 多要素認証 |
| IFC / DLP | 情報フロー制御 / 情報持ち出し防止 |
| Egress | 外向き通信 |
| EDR | PC・サーバー上の不審挙動の検知と対処 |
| SIEM / SOAR / SOC | ログ統合分析 / 対応自動化 / 監視組織 |
| RPO / RTO | 許容データ損失時点 / 目標復旧時間 |
| PoC | 小規模な実証検証 |
結論
単一製品が「穴のない安全」を提供するのではありません。 経営の判断を現場の実行制御へ反映し、情報の移動・攻撃の横展開を抑え、事故時には監査と復旧で説明できること。その状態を継続して改善することが、組織の信用・信頼を積み上げる手段です。