はじめに
2021年11月11日に Security JAWS【第23回】で「閉域要件におけるS3周辺ポリシーの組み合わせ方」を発表しました。
発表当時は資料未公開でしたが、2022年8月にSpeaker Deckで資料を公開したため、発表内容の要約を本記事で紹介します。記事の後半では、AWS環境のセキュリティモデル『データ境界』を紹介し、当社のポリシー事例と比較します。
1年以上前の発表内容ではありますが、直近で関わっている閉域要件の案件でも本思想をベースにしているため、お役になれば幸いです。
資料
資料の全量は以下から参照可能です。
動画
YouTubeに発表当時の動画が掲載されています。当社の発表は1:37:40～です。
当社事例の要約
発表スライドの総枚数は88枚もあるため、ダイジェストとして3枚のスライドをピックアップします。
① まとめ
本発表では、S3周りで気を付けたい点を3つ紹介しました。上記のデータ流出リスクについては、以下スライドをご覧ください。
② データ流出のリスク
悪意を持った内部犯行により、VPCエンドポイントを経由して、社外へデータ流出するリスクがあります。動画では、アカウントC（社外）のクレデンシャルが運用者に持ち込まれるパターンを解説しています。
上記のデータ流出リスクをどのように対策するかは、以下でまとめています。
③ S3周辺ポリシーの組み合わせ方
データ流出のリスクについては、IAMのグローバル条件キーを組み合わせることで、対策可能な旨を示しました。具体的なポリシー例については、本記事の後半で紹介します。
データ境界
AWS Security Roadshow Japan 2021のラストセッションで、以下講演がありました。
AWS 環境で重要データを保護するセキュリティモデル：データ境界 (DATA PERIMETER) を学ぶ
恥ずかしながら、私は以下ツイートのやりとりで本講演を知りました。
(私も昨日、松尾さんのセッション聞いていてそう思っていました)
— hkiriyam (@hkiriyam1) November 12, 2021
後日アーカイブを視聴したところ、確かに同様の考え方が紹介されており、驚きました。
以下では、上記講演のスライドを引用して、データ境界の概要を紹介します。
概要
データ境界というガードレールの紹介が、本講演のメインテーマでした。上記のキーワードレベルでも、当社事例と近しい雰囲気を感じます。
次に、データ境界を適用したいシナリオを確認してみます。
データ境界を適用したいシナリオ
当社がデータ流出のリスクで紹介した内容と同じく、社外アカウントへの流出リスクを想定しています。
本リスクに対するデータ境界の設定観点は以下の通りです。
データ境界の設定観点
列挙されている設定場所が、S3周辺ポリシーの組み合わせ方で紹介した当社例と一致しています。図らずも当社ではデータ境界を取り入れていました。
上記スライドの後に、具体的なポリシーの設定内容も解説されているため、一部を以下で紹介します。
ポリシーの比較
ここからは、以下3種のポリシー例を比較します。細かな差異はありますが、基本的な考え方は同じです。
データ境界では、S3とSQSの例が紹介されていますが、当社例ではS3関連のポリシーのみを紹介しています。Action句やResource句など細かい差はありますが、比較する上であまり影響がないため、各例は講演スライドから転記しています。
IAMポリシー
IAMポリシーの具体例は以下です。
- データ境界のIAMポリシー例
- 当社の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}"
}
}
}
]
}
当社例の補足スライド
SQSとS3のリソース差異により、ポリシー記載方法が異なっていますが、本質的には殆ど同じです。S3バケットではARNにアカウントIDを含まないため、当社例では"s3:ResourceAccount"を使用して、アクセス先のアカウントを制限しています。
S3アクセスポイントを使用する場合は、ARNにアカウントIDを含むため、データ境界例と同様にResource句でアカウント制限が可能です。アクセスポイント利用時のIAMポリシー例は、以下をご参照ください。
VPC に制限された S3 アクセスポイントを使用して、別のアカウントのバケットにアクセスする方法を教えてください。
VPCエンドポイントポリシー
VPCエンドポイントポリシーの具体例は以下です。
- データ境界のVPCエンドポイントポリシー例
- 当社の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": "*"
}
]
}
当社例の補足スライド
- ポリシーの主な差異
| 比較観点 | データ境界例 | 当社例 |
|---|---|---|
| アクセス元Identityの制限 | "aws:PrincipalOrgID"で組織単位の制限 | "aws:PrincipalAccount"でアカウント単位の制限 |
| アクセス制限の例外 | なし | NotResource句で例外のS3バケットを指定 |
VPCエンドポイントポリシーもほぼ同じ方針です。当時、諸事情によりAWS Organizationsを導入していなかったため、当社では"aws:PrincipalAccount"でアクセス元のアカウントを制限しています。
S3のVPCエンドポイントでは、自社アカウント外のAmazonLinuxリポジトリ（S3バケット）にアクセスしたいケースもあるため、NotResource句で例外指定しています。
VPCeでリソースレベルの制限
データ境界では、VPCエンドポイントでアクセス先リソースを制限する例として、以下も紹介されています。
上記では、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
バケットポリシー
バケットポリシーの具体例は以下です。
- データ境界のバケットポリシー例
- 当社のバケットポリシー例
{
"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～です。-
Condition句なし、且つResource句でS3バケットのARNを完全一致で指定していない場合、社外アカウントへのデータ流出リスクがあります。詳細は、発表スライドのp.34～p.38をご参照ください。 ↩
-
ポリシーのCondition句では、"aws:CalledVia"と"aws:userId"がVPC関連のN/W制限キーと同列で定義されているため、例外という表現は不適切かもしれません。しかし、比較対象のデータ境界では「ネットワーク境界 on リソースポリシー」として本ポリシーが紹介されているため、ここでは"aws:CalledVia"と"aws:userId"をN/W制限の例外として位置づけました。 ↩