LoginSignup
1
0

More than 1 year has passed since last update.

@y_matsuo_(Yusei Matsuo)inみずほリサーチ＆テクノロジーズ株式会社　先端技術研究部

S3周辺ポリシーの事例をAWSセキュリティモデルと比べたら、想像以上に『データ境界』だった

Posted at

はじめに

2021年11月11日に Security JAWS【第23回】で「閉域要件におけるS3周辺ポリシーの組み合わせ方」を発表しました。

発表当時は資料未公開でしたが、2022年8月にSpeaker Deckで資料を公開したため、発表内容の要約を本記事で紹介します。記事の後半では、AWS環境のセキュリティモデル『データ境界』を紹介し、当社のポリシー事例と比較します。

1年以上前の発表内容ではありますが、直近で関わっている閉域要件の案件でも本思想をベースにしているため、お役になれば幸いです。

資料

資料の全量は以下から参照可能です。

動画

YouTubeに発表当時の動画が掲載されています。当社の発表は1:37:40～です。

当社事例の要約

発表スライドの総枚数は88枚もあるため、ダイジェストとして3枚のスライドをピックアップします。

① まとめ

まとめ

本発表では、S3周りで気を付けたい点を3つ紹介しました。上記のデータ流出リスクについては、以下スライドをご覧ください。

② データ流出のリスク

データ流出のリスク

悪意を持った内部犯行により、VPCエンドポイントを経由して、社外へデータ流出するリスクがあります。動画では、アカウントC（社外）のクレデンシャルが運用者に持ち込まれるパターンを解説しています。

上記のデータ流出リスクをどのように対策するかは、以下でまとめています。

③ S3周辺ポリシーの組み合わせ方

S3周辺ポリシーの組み合わせ方

データ流出のリスクについては、IAMのグローバル条件キーを組み合わせることで、対策可能な旨を示しました。具体的なポリシー例については、本記事の後半で紹介します。

データ境界

AWS Security Roadshow Japan 2021のラストセッションで、以下講演がありました。
AWS 環境で重要データを保護するセキュリティモデル：データ境界 (DATA PERIMETER) を学ぶ

恥ずかしながら、私は以下ツイートのやりとりで本講演を知りました。

後日アーカイブを視聴したところ、確かに同様の考え方が紹介されており、驚きました。

以下では、上記講演のスライドを引用して、データ境界の概要を紹介します。

概要

データ境界の概要
データ境界というガードレールの紹介が、本講演のメインテーマでした。上記のキーワードレベルでも、当社事例と近しい雰囲気を感じます。

次に、データ境界を適用したいシナリオを確認してみます。

データ境界を適用したいシナリオ

データ境界を適用したいシナリオ
当社がデータ流出のリスクで紹介した内容と同じく、社外アカウントへの流出リスクを想定しています。

本リスクに対するデータ境界の設定観点は以下の通りです。

データ境界の設定観点

データ境界の対策観点
列挙されている設定場所が、S3周辺ポリシーの組み合わせ方で紹介した当社例と一致しています。図らずも当社ではデータ境界を取り入れていました。

上記スライドの後に、具体的なポリシーの設定内容も解説されているため、一部を以下で紹介します。

ポリシーの比較

ここからは、以下3種のポリシー例を比較します。細かな差異はありますが、基本的な考え方は同じです。

データ境界では、S3とSQSの例が紹介されていますが、当社例ではS3関連のポリシーのみを紹介しています。Action句やResource句など細かい差はありますが、比較する上であまり影響がないため、各例は講演スライドから転記しています。

IAMポリシー

IAMポリシーの具体例は以下です。

  • データ境界のIAMポリシー例
    リソース境界 on アイデンティティポリシー
  • 当社のIAMポリシー例
{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": "arn:aws:s3:::bucket-*"
    },
    {
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "s3:ResourceAccount": "{アカウントA-ID}"
        }
      }
    }
  ]
}
当社例の補足スライド

IAMポリシー例

SQSとS3のリソース差異により、ポリシー記載方法が異なっていますが、本質的には殆ど同じです。S3バケットではARNにアカウントIDを含まないため、当社例では"s3:ResourceAccount"を使用して、アクセス先のアカウントを制限しています。

S3アクセスポイントを使用する場合は、ARNにアカウントIDを含むため、データ境界例と同様にResource句でアカウント制限が可能です。アクセスポイント利用時のIAMポリシー例は、以下をご参照ください。
VPC に制限された S3 アクセスポイントを使用して、別のアカウントのバケットにアクセスする方法を教えてください。

VPCエンドポイントポリシー

VPCエンドポイントポリシーの具体例は以下です。

  • データ境界のVPCエンドポイントポリシー例
    アイデンティティ境界 on ネットワークポリシー
  • 当社のVPCエンドポイントポリシー例
{
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": {
        "AWS": "*"
      },
      "Action": "*",
      "NotResource": "arn:aws:s3:::amazonlinux.{region}.amazonaws.com/*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalAccount": "{アカウントA-ID}"
        }
      }
    },
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "*",
      "Resource": "*"
    }
  ]
}
当社例の補足スライド

VPCエンドポイントポリシー例

  • ポリシーの主な差異
比較観点 データ境界例 当社例
アクセス元Identityの制限 "aws:PrincipalOrgID"で組織単位の制限 "aws:PrincipalAccount"でアカウント単位の制限
アクセス制限の例外 なし NotResource句で例外のS3バケットを指定

VPCエンドポイントポリシーもほぼ同じ方針です。当時、諸事情によりAWS Organizationsを導入していなかったため、当社では"aws:PrincipalAccount"でアクセス元のアカウントを制限しています。

S3のVPCエンドポイントでは、自社アカウント外のAmazonLinuxリポジトリ（S3バケット）にアクセスしたいケースもあるため、NotResource句で例外指定しています。

VPCeでリソースレベルの制限

データ境界では、VPCエンドポイントでアクセス先リソースを制限する例として、以下も紹介されています。
リソース境界 on ネットワークポリシー
上記では、Resource句でアカウントIDを指定することにより、アクセス先のアカウントを制限しています。一方、S3バケットではARNにアカウントIDを含まないため、Resource句のみでアクセス先のアカウントを制限することはできません。

バケット名をグローバルで一意にしなければならないS3において、Resoruce句のみで社外流出の対策をするには、ARNを完全一致で指定する必要があります1。アクセス先のS3バケットが増減しない状況であれば、シンプルにResource句でARNをフル指定するパターンも良いと思います。

IAMポリシー例と同様に、S3アクセスポイントを使用する場合はアカウント制限が可能です。アクセスポイント利用時のVPCエンドポイントポリシー例は以下をご参照ください。
Managing Amazon S3 access with VPC endpoints and S3 Access Points

バケットポリシー

バケットポリシーの具体例は以下です。

  • データ境界のバケットポリシー例
    ネットワーク境界 on リソースポリシー
  • 当社のバケットポリシー例
{
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::bucket-a",
        "arn:aws:s3:::bucket-a/*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpce": [
            "{S3VPCe(I/F型)のID}",
            "{S3VPCe(G/W型)のID}"
          ]
        },
        "StringNotLike": {
          "aws:userId": [
            "{ReadOnlyRoleID}:*",
            "{CFnRoleID}:*",
            "{S3ReplicationRoleID}:*"
          ]
        }
      }
    }
  ]
}
当社例の補足スライド

アクセス経路

  • ポリシーの主な差異
比較観点 データ境界例 当社例
アクセス元N/Wの制限 "aws:SourceVpc"でVPC単位の制限 "aws:sourceVpce"でVPCエンドポイント単位の制限
アクセス制限の例外2 "aws:CalledVia"で例外サービスを指定 "aws:userId"で例外のIAMロールIDを指定

バケットポリシーについては、当社例の方が厳しく制限している印象です。当社例では、Condition句でVPCエンドポイントやIAMロールを指定することにより、事前に承認・作成されたAWSリソースのみアクセスを許可しています。

データ境界例の方が、ロール変更などの影響を受けにくいため、保守・運用しやすいイメージがあります。細かな差異はありますが、基本の考え方はやはり同じだと感じました。

おわりに

閉域要件におけるS3周辺ポリシーの当社設計事例を、AWSの『データ境界』と比較しました。細かな差異はありますが、基本的な考え方は同じでした。

AWSのポリシーは種類が多く複雑ですが、その分自由度も高いです。本記事がどなたかのお役に立てれば幸いです。

付録

当社事例には続きがあり、Security JAWS【第25回】で発表しています。本発表でも「データ境界」に近い設計事例を紹介しているので、ご参考下さい。

Security JAWS【第25回】の動画 YouTubeに発表当時の動画が掲載されています。当社の発表は2:06:36～です。

Security-JAWS【第25回】 勉強会

  1. Condition句なし、且つResource句でS3バケットのARNを完全一致で指定していない場合、社外アカウントへのデータ流出リスクがあります。詳細は、発表スライドのp.34～p.38をご参照ください。 ↩

  2. ポリシーのCondition句では、"aws:CalledVia"と"aws:userId"がVPC関連のN/W制限キーと同列で定義されているため、例外という表現は不適切かもしれません。しかし、比較対象のデータ境界では「ネットワーク境界 on リソースポリシー」として本ポリシーが紹介されているため、ここでは"aws:CalledVia"と"aws:userId"をN/W制限の例外として位置づけました。 ↩

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0