データ境界の設計 VPCエンドポイントポリシー・SCP・aws:PrincipalOrgIDで組織外への流出を防ぐ

SCS-C02では、認証情報が漏えいしても「組織外のプリンシパルが自社データに触れない」「自社の認証情報で外部のバケットへ持ち出せない」という多層防御、いわゆるデータ境界(データペリメーター)の設計が問われます。3種類のポリシーを組み合わせて境界を作る考え方を整理します。

覚え方は「信頼できるID・信頼できるリソース・想定ネットワーク」の3つ

データ境界は、信頼できるID＝自社の組織に属するプリンシパルだけがアクセスできる、信頼できるリソース＝自社のプリンシパルは自社のリソースにしかアクセスできない、想定ネットワーク＝自社VPCやオンプレミスからのアクセスに限る、の3つの目標に分けて設計します。それぞれを実現する主なポリシーが異なる点が試験の核心です。

信頼できるIDだけを通す：リソースポリシーとaws:PrincipalOrgID

S3バケットポリシーやKMSキーポリシー、SQSキューポリシーなどのリソースポリシーに aws:PrincipalOrgID の条件を付けると、組織外のプリンシパルからのアクセスを一括で拒否できます。「共有バケットへのアクセスを組織内に限定したいが、アカウントの増減でポリシーを直したくない」という要件が典型で、OU単位ならaws:PrincipalOrgPathsを使います。VPCエンドポイントポリシーにも同じ条件を入れれば、自社ネットワークを通る通信を組織のプリンシパルに限定できます。

信頼できるリソースだけに向かわせる：SCPとaws:ResourceOrgID

盗まれた認証情報や内部の不正で、自社のプリンシパルが外部アカウントのS3バケットへデータをコピーする持ち出しを防ぐには、SCPで aws:ResourceOrgID が自社組織IDと一致しないリクエストを拒否します。VPCエンドポイントポリシーにも同じ条件を入れると、ネットワーク経路でも二重に防げます。ただしAWSが所有するサービス用バケット(パッチ配布など)へのアクセスを誤って遮断しないよう例外を設ける点が実務のポイントです。

想定ネットワークからだけ通す：aws:SourceVpcとaws:SourceIp

リソースポリシーで aws:SourceVpce や aws:SourceVpc を条件にすると、特定のVPCエンドポイント経由以外のアクセスを拒否できます。オンプレミスからのアクセスにはaws:SourceIpを使い、AWSサービスが代理で行うアクセスはaws:PrincipalIsAWSServiceやaws:ViaAWSServiceで例外にします。

チェックリスト

• ARRAY(0xa002a37c0)

まとめ

データ境界は「誰が・どこへ・どこから」の3つを、リソースポリシー・SCP・VPCエンドポイントポリシーで多層に囲む設計です。主語を意識して条件キーを選びましょう。 理解度の確認にはクイズが便利です。試験範囲や申し込みの最新情報はAWS認定 公式ページもあわせて確認してください。