Bedrock/SageMaker時代のガバナンス・ギャップ — IAMとSTSから紐解く予防的セキュリティ

登壇者の背景

• セキュリティベンダーのセキュリティエンジニア
• 複数のインフラ・クラウド関連企業を経て現職
• 専門: DevSecOps、Kubernetes、コンテナ、Terraform、GitOps

AIリスクレポートの数字（2026年）

→ 攻撃者はAIモデル自体ではなく、AIに付与された「権限」を狙う。

リスク1: 過剰権限（最大の脅威）

典型シナリオ

Bedrockエージェント
  → Lambda実行ロール
    → AmazonBedrockFullAccess（過剰）
    → AmazonS3FullAccess（過剰）

プロンプトインジェクション（直接 or RAG経由の間接）で:

• 「S3バケット内容を全部教えて」と誘導
• 過剰権限があるため機密データ露出
• モデル設定の書き換えまで可能

対策

利用状況を継続分析 → 未使用/過剰権限を検知 → 最小権限を自動推奨・修正。 例: S3読み取りのみ必要なのに書き込み権限がある場合、自動削除を提案。

リスク2: STSセッション有効期限

問題

• デフォルト: 1時間
• 設定により最大12時間まで延長可能
• 未使用のまま放置 → 攻撃者の長期アクセス手段化

Blast Radius（爆発的権限昇格）

• Principal条件のない設定 → 誰からでもAssumeRole可能
• 実際のアクセス経路が不明確
• 最新LLMを使うと数分でSTS悪用が完了

対策: Access Graph

STSの全経路を可視化。ロール設定 + Trust Relation + Policyを組み合わせた実質到達可能性を表示。STS悪用時の最悪到達先を一目で把握。

リスク3: 認証情報管理ミス

3パターン

1. SystemPromptにAWSアクセスキーをハードコード

   • プロンプトインジェクション時に漏洩

2. .envファイルをGitHubにコミット

   • AI時代は影響範囲が格段に広い

3. RAG処理での情報漏洩（見落とされがち）

   • 社内ドキュメントのベクトルDB化時にアクセス権限設定ミス
   • DB接続情報・認証トークンが一般ユーザーのAI回答に混入
   • サイレント情報漏洩（気付かない）

対策

• ストレージの秘密情報スキャン
• CIパイプラインでコミット段階にて秘密検知・ブロック

リスク4: AIサプライチェーン脅威

• HuggingFace等の公開モデル・LoRAアダプターにバックドア
• OSS AIライブラリの脆弱性増加
• ファインチューニングの汚染データ → 特定入力で異常動作
• 複雑な依存関係で把握困難

対策: AI SBOM

AI Software Bill of Materialsで依存関係を完全可視化。コンテナイメージの脆弱性スキャン。悪意あるパッケージ検知。

CloudTrailとAIエージェントの問題

• CloudTrailはプリンシパル（IAMロール）を記録
• AIの名前は記録されない
• 人間用ロールをAIに渡すと: AIがやったのに人間がやったように見える

→ AI専用ロールの分離が必須

アラート優先度の3層フィルター

1. Network Context: 実際のネットワークからのアクセスか？
2. Identity Context: 誰が・どのロールで？
3. Business Context: 資産価値（事前に人が判定）

3層を通して対応すべきアラートを絞る。

持ち帰り3点

1. AIエージェントは過剰権限を持つ自律的アクターとして扱う
2. IAMとSTSのミスはAI起動時に武器化する
3. 攻撃経路のContextで優先順位をつける

初心者向け補足

STSとは

一時的なセキュリティ認証情報を発行するAWSサービス。AssumeRoleで特定ロールの権限を一定時間借りる仕組み。「一時的」のはずが長期間有効のまま放置されるとリスクに。

なぜ80%が「周辺インフラ」を狙うのか

AIモデル自体をハッキングするのは難しい。しかしモデルに付与されたIAM権限を悪用すれば、S3のデータ取得やLambda実行が可能。攻撃者にとっては「モデルを騙す」方が「モデルを壊す」より遥かに簡単。

AI SBOMとは

AIシステムの全構成要素（モデル、ライブラリ、データセット）の一覧表。「何がどこで動いているか」を把握することがセキュリティの第一歩。