閉域要件におけるS3周辺ポリシーの組み合わせ方

Slide 1

Slide 1 text

閉域要件における S3周辺ポリシーの組み合わせ方 2021.11.11 Security-JAWS 第23回 Copyright (c) Mizuho Research & Technologies, Ltd. All Rights Reserved. （免責事項）当資料は情報提供のみを目的として作成されたものであり、商品の勧誘を目的としたものではありません。本資料は、当社が信頼できると判断した各種データに基づき作成されておりますが、その正確性、確実性を保証するものではありません。また、本資料に記載された内容は予告なしに変更されることもあります。

Slide 2

Slide 2 text

自己紹介  氏名：松尾優成（まつおゆうせい）  所属：先端技術研究部兼プロジェクト推進部  役割：  AWS社内案件の設計・構築サポート  みずほコミュニティ ERG ”コクリエ” の運営

Slide 3

Slide 3 text

みずほのAWS利用経緯  2018年：AWS上にグループ共通基盤を構築、CCoE設立  2019年：AWS人材育成施策開始  2020年：みずほ内でAWS開発案件数が拡大 https://www.nikkeibp.co.jp/atclpubmkt/book/21/S70150/

Slide 4

Slide 4 text

本日話すこと  閉域要件で、S3のデータ流出を防ぐための予防的統制観点  各ポリシーをどのように組み合わせてS3のデータ流出を防ぐか  IAMポリシー  VPCエンドポイントポリシー  S3バケットポリシー

Slide 5

Slide 5 text

本日話さないこと  データが流出した場合の発見的統制観点  S3 ACLやKMS周りの詳細な設定  S3以外のデータを保有するサービスに対する対策  オンプレミス側のデータ流出対策

Slide 6

Slide 6 text

みずほのAWS利用状況  重要情報を扱うシステムの場合、閉域網とすることが主流  AWS と自社設備のハイブリッド・クラウド構成となることが多い  重要情報を扱う閉域用端末と、マネコン用のインターネット端末2種で運用  ベストプラクティスに沿って、マルチアカウント構成が主流

Slide 7

Slide 7 text

アカウントA 構成概要  オンプレミスからS3に格納したユーザー情報を、EC2 で分析して還元するシステム。 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) 閉域用 bucket-b S3 ・・・ EC2 運用者

Slide 8

Slide 8 text

アカウントA 構成概要  オンプレミスからS3に格納したユーザー情報を、EC2 で分析して還元するシステム。 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) 閉域用 bucket-b S3 ・・・ EC2 運用者 ①オンプレミスにあるユーザー情報を・・・

Slide 9

Slide 9 text

アカウントA 構成概要  オンプレミスからS3に格納したユーザー情報を、EC2 で分析して還元するシステム。 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) 閉域用 bucket-b S3 ・・・ EC2 運用者 ②S3にアップロード

Slide 10

Slide 10 text

アカウントA 構成概要  オンプレミスからS3に格納したユーザー情報を、EC2 で分析して還元するシステム。 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) 閉域用 bucket-b S3 ・・・ EC2 運用者 ③S3のデータをEC2でETL処理

Slide 11

Slide 11 text

アカウントA 構成概要  オンプレミスからS3に格納したユーザー情報を、EC2 で分析して還元するシステム。 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) 閉域用 bucket-b S3 ・・・ EC2 運用者 ④EC2から再度S3にアップロードし・・・

Slide 12

Slide 12 text

アカウントA 構成概要  オンプレミスからS3に格納したユーザー情報を、EC2 で分析して還元するシステム。 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) 閉域用 bucket-b S3 ・・・ EC2 運用者 ⑤オンプレミスに処理済みのユーザー情報を還元

Slide 13

Slide 13 text

アカウントA 構成概要（補足）  ユーザーごとに専用のS3バケットがあり、ユーザー増加に応じてS3バケットも増加。  バッチ処理のみで、インターネットアクセスなし。 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) 閉域用 bucket-b S3 ・・・ EC2 運用者

Slide 14

Slide 14 text

閉域網だからといって、きちんと対策しないと・・・ VPC Corporate data center Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用運用者アカウントA bucket-a bucket-b S3 ・・・

Slide 15

Slide 15 text

閉域網だからといって、きちんと対策しないと・・・ VPC Corporate data center Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用運用者アカウントC（社外）アカウントA bucket-z 流出！ C C データ流出リスクがある！→ C

Slide 16

Slide 16 text

データ流出観点で着目するポリシーは3つ VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 bucket-b S3 ・・・運用者アカウントA Ⅰ. IAMポリシー Ⅱ. VPCエンドポイントポリシー Ⅲ. バケットポリシー Ⅰ Ⅰ Ⅲ Ⅱ

Slide 17

Slide 17 text

データを保有するコンポーネントからデータ流出の対策を考えてみる

Slide 18

Slide 18 text

アカウントA 重要データを保持するのは3箇所 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) 閉域用 bucket-b S3 ・・・ EC2 ① 閉域用端末 ② EC2 ③ S3バケット運用者 ←これらに置かれたデータが流出するのを防ぎたい・・・！ ① ② ③

Slide 19

Slide 19 text

VPCエンドポイントを利用するアクセス者側で考えてみる

Slide 20

Slide 20 text

VPCe利用者のアクセス権限 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 bucket-b S3 ・・・運用者アカウントA ① ② ③

Slide 21

Slide 21 text

VPCe利用者のアクセス権限 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 bucket-b S3 ・・・運用者アカウントA ① 閉域用端末 ② EC2 ③ S3バケット ←①と②に焦点を絞ってみる ① ② ③

Slide 22

Slide 22 text

VPCe利用者のアクセス権限 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 bucket-b S3 ・・・運用者アカウントA ・IAMポリシー例 { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucket" ], "Resource": "arn:aws:s3:::bucket-*“ }

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

もし、ワイルドカードを使わなかったら・・・？

Slide 27

Slide 27 text

開発者権限管理者 S3バケットが増加したので、IAMロールに権限を追加してもらえますか？ 11/1(月)

Slide 28

Slide 28 text

開発者権限管理者 S3バケットが増加したので、IAMロールに権限を追加してもらえますか？ 5営業日で対応します！ 11/1(月)

Slide 29

Slide 29 text

開発者権限管理者 S3バケットが増加したので、IAMロールに権限を追加してもらえますか？ 5営業日で対応します！ S3バケットのArnを間違えたので、依頼内容を修正したいのですが・・・ 11/1(月) 11/4(木)

Slide 30

Slide 30 text

開発者権限管理者 S3バケットが増加したので、IAMロールに権限を追加してもらえますか？ 5営業日で対応します！別途、5営業日で対応します！ 11/1(月) 11/4(木) S3バケットのArnを間違えたので、依頼内容を修正したいのですが・・・

Slide 31

Slide 31 text

開発者権限管理者 S3バケットが増加したので、IAMロールに権限を追加してもらえますか？ 5営業日で対応します！別途、5営業日で対応します！ S3バケットが更に増加し・・・(ry 11/1(月) 11/4(木) 11/8(月) S3バケットのArnを間違えたので、依頼内容を修正したいのですが・・・

Slide 32

Slide 32 text

開発者権限管理者 S3バケットが増加したので、IAMロールに権限を追加してもらえますか？ 5営業日で対応します！別途、5営業日で対応します！ S3バケットが更に増加し・・・(ry 11/1(月) 11/4(木) 11/8(月) S3バケットのArnを間違えたので、依頼内容を修正したいのですが・・・ ※Permissions Boundaryは本題から逸れるので考慮外

Slide 33

Slide 33 text

Slide 34

Slide 34 text

社外アカウントに同様の命名規則で S3バケットを作られたら・・・？ "arn:aws:s3:::bucket-a“ "arn:aws:s3:::bucket-b“ "arn:aws:s3:::bucket-*“

Slide 35

Slide 35 text

VPCe利用者：不正経路 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 bucket-b S3 ・・・運用者アカウントC（社外）アカウントA bucket-z bucket-zをアカウントCに作成

Slide 36

Slide 36 text

Slide 37

Slide 37 text

VPCe利用者：不正経路 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 bucket-b S3 ・・・運用者アカウントC（社外）アカウントA bucket-z 社外のS3バケットポリシーに以下を設定 { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::{アカウントA-ID}:root" }, "Action": "s3:*", "Resource”: "arn:aws:s3:::bucket-z/*" } IAMポリシーにワイルドカードを利用 { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucket" ], "Resource": "arn:aws:s3:::bucket-*“ }

Slide 38

Slide 38 text

VPCe利用者：不正経路 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 bucket-b S3 ・・・運用者アカウントC（社外）アカウントA bucket-z IAMポリシーにワイルドカードを利用 { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucket" ], "Resource": "arn:aws:s3:::bucket-*“ } 社外のS3バケットポリシーに以下を設定 { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::{アカウントA-ID}:root" }, "Action": "s3:*", "Resource”: "arn:aws:s3:::bucket-z/*" } 流出！

Slide 39

Slide 39 text

IAMポリシーでワイルドカードを使いつつ、アクセス先のS3バケットを自社アカウントに制限したい

Slide 40

Slide 40 text

2020年末にこんなアップデートが・・・

Slide 41

Slide 41 text

https://aws.amazon.com/jp/about-aws/whats-new/2020/12/

Slide 42

Slide 42 text

https://aws.amazon.com/jp/about-aws/whats-new/2020/12/

Slide 43

Slide 43 text

https://aws.amazon.com/jp/about-aws/whats-new/2020/12/

Slide 44

Slide 44 text

条件キー s3:ResourceAccount で解決できそう！ https://aws.amazon.com/jp/about-aws/whats-new/2020/12/

Slide 45

Slide 45 text

ここでは、IAM側で記述してみる https://aws.amazon.com/jp/about-aws/whats-new/2020/12/

Slide 46

Slide 46 text

VPCe利用者：不正経路 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 bucket-b S3 ・・・運用者アカウントC（社外）アカウントA bucket-z 流出！・IAMポリシー例 { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucket" ], "Resource": "arn:aws:s3:::bucket-*" }

Slide 47

Slide 47 text

IAMロール：S3アカウント制限を追加 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 bucket-b S3 ・・・運用者アカウントC（社外）アカウントA bucket-z ・IAMポリシー例 { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucket" ], "Resource": "arn:aws:s3:::bucket-*" } ・追加IAMポリシー例 { "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "StringNotEquals": { "s3:ResourceAccount": "アカウントA-ID" } } 参考) https://dev.classmethod.jp/articles/iam-condition-keys-amazon-s3-resource-account/

Slide 48

Slide 48 text

IAMロール：S3アカウント制限を追加 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 bucket-b S3 ・・・運用者アカウントC（社外）アカウントA bucket-z ・追加IAMポリシー例 { "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "StringNotEquals": { "s3:ResourceAccount": "アカウントA-ID" } } 制限可能! 参考) https://dev.classmethod.jp/articles/iam-condition-keys-amazon-s3-resource-account/ ・IAMポリシー例 { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucket" ], "Resource": "arn:aws:s3:::bucket-*" }

Slide 49

Slide 49 text

でも、社外アカウントのクレデンシャルを持ち込まれたら・・・？

Slide 50

Slide 50 text

クレデンシャル持ち込みパターン Corporate data center アカウントC（社外）アカウントA bucket-z アカウントC で bucket-zにアクセスできるロールを追加 C

Slide 51

Slide 51 text

クレデンシャル持ち込みパターン VPC Corporate data center Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用運用者アカウントC（社外）アカウントA bucket-z アクセス者側でアカウントCのクレデンシャルを利用 C C C

Slide 52

Slide 52 text

クレデンシャル持ち込みパターン VPC Corporate data center Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用運用者アカウントC（社外）アカウントA bucket-z 流出！ C C C

Slide 53

Slide 53 text

クレデンシャル持ち込みパターン VPC Corporate data center Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用運用者アカウントC（社外）アカウントA bucket-z 流出！ C C 社外のクレデンシャルを持ち込まれると、 S3 データイベントの CloudTrail ログがアカウントAで記録されないため、要注意。 C

Slide 54

Slide 54 text

クレデンシャル持ち込みによる他アカウントへの流出対策も s3:ResourceAccount ※ を VPCエンドポイントポリシーで使用すれば大丈夫 VPC VPCe (I/F型) VPCe (G/W型) ※アクセスポイントを使っている場合、 s3:DataAccessPointArnも有用。アカウントC（社外） bucket-z

Slide 55

Slide 55 text

せっかくなので、VPCエンドポイントポリシーで持ち込まれたクレデンシャルを拒否する手法も紹介 VPC VPCe (I/F型) VPCe (G/W型) アカウントC（社外） C C C

Slide 56

Slide 56 text

KMS開発者ガイド：https://docs.aws.amazon.com/ja_jp/kms/latest/ developerguide/kms-vpc-endpoint.html#vpce-policy 左記はKMS開発者ガイドの VPCエンドポイントポリシー例

Slide 57

Slide 57 text

KMS開発者ガイド：https://docs.aws.amazon.com/ja_jp/kms/latest/ developerguide/kms-vpc-endpoint.html#vpce-policy aws:PrincipalAccount でクレデンシャル持ち込みの対策可能。 S3 でも同様の考えで制限できるはず・・・

Slide 58

Slide 58 text

KMS開発者ガイド：https://docs.aws.amazon.com/ja_jp/kms/latest/ developerguide/kms-vpc-endpoint.html#vpce-policy しかし、この記載をそのまま使うと、全ての Principal でアクセス不可・・・。以下 Statement も追加で必要。 { "Action": "*", "Effect": "Allow", "Resource": "*“, “Principal": "*“ }

Slide 59

Slide 59 text

{ "Statement": [ { "Effect": "Deny", "Principal": {"AWS": "*"}, "Action": "*", "Resource": "*", "Condition": { "StringNotEquals": { "aws:PrincipalAccount": "アカウントA-ID" } } }, { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*" } ] } 本ポリシーでクレデンシャルの持ち込み利用を制限可能。 ※s3:ResourceAccountの記載は割愛。 VPCエンドポイントポリシー例 VPC VPCe (I/F型) VPCe (G/W型) アカウントA

Slide 60

Slide 60 text

{ "Statement": [ { "Effect": "Deny", "Principal": {"AWS": "*"}, "Action": "*", "Resource": "*", "Condition": { "StringNotEquals": { "aws:PrincipalAccount": "アカウントA-ID" } } }, { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*" } ] } ただし、EC2でAmazon Linuxのリポジトリを利用している場合は要注意。 VPCエンドポイントポリシー例 VPC VPCe (I/F型) VPCe (G/W型) EC2 アカウントA

Slide 61

Slide 61 text

{ "Statement": [ { "Effect": "Deny", "Principal": {"AWS": "*"}, "Action": "*", "Resource": "*", "Condition": { "StringNotEquals": { "aws:PrincipalAccount": "アカウントA-ID" } } }, { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*" } ] } yum updateのリクエストではアカウントAのprincipal情報をもたないため、アクセス拒否されてしまう。 VPCエンドポイントポリシー例 VPC VPCe (I/F型) VPCe (G/W型) EC2 アカウントA AWS管理 amazonlinux リポジトリ

Slide 62

Slide 62 text

{ "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": "*" } ] } アカウントA EC2が使用するVPCeのエンドポイントポリシーでは NotResource句を使って以下を指定すれば、 AmazonLinuxリポジトリにアクセス可。 VPCエンドポイントポリシー例 VPC VPCe (I/F型) VPCe (G/W型) EC2 AWS管理 amazonlinux リポジトリ

Slide 63

Slide 63 text

重要データを保持するのは3箇所 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 bucket-b S3 ・・・運用者アカウントA ① 閉域用端末 ② EC2 ③ S3バケット ←①と②は前述の対策で大丈夫そう ① ② ③

Slide 64

Slide 64 text

重要データを保持するのは3箇所 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 bucket-b S3 ・・・運用者アカウントA ① 閉域用端末 ② EC2 ③ S3バケット ←次に③S3バケットへの正常・不正経路を考えてみる ① ② ③

Slide 65

Slide 65 text

アカウントA S3バケット：正常経路の洗い出し VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 Management Console アカウントB（ユーザー管理） IAM User 閉域用インターネット用 Read Only Role bucket-b S3 ・・・ CloudFormation S3 Replication 運用者 ① ② ③ ④ ⑤ IP制限

Slide 66

Slide 66 text

S3バケット：不正経路の洗い出し VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用インターネット用 bucket-b S3 ・・・ AWS Services 運用者 ③ ① ② アカウントC（社外）アカウントA Public Access AWS Services

Slide 67

Slide 67 text

不正経路は色々あるので正常経路以外を全て拒否したいアカウントA VPCe (I/F型) VPCe (G/W型) Read Only Role S3 CloudFormation S3 Replication ① ② ③ ④ ⑤ bucket-a

Slide 68

Slide 68 text

バケットポリシー・アクセスポイントポリシーで前述の経路を制限できそう

Slide 69

Slide 69 text

バケットポリシーだけで制御する例を考えてみる

Slide 70

Slide 70 text

"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}:*" ] } ①~⑤のいずれかに一致しない場合 Denyする例。 S3バケットポリシー例 ※色々書き方はあるのでご参考程度に・・・アカウントA bucket-a VPCe (I/F型) VPCe (G/W型) Read Only Role S3 CloudFormation S3 Replication ① ② ③ ④ ⑤ ① ② ③ ④ ⑤

Slide 71

Slide 71 text

S3 "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}:*" ] } 逆に言うと、①～⑤のいずれかに一致すればアクセス可能。 S3バケットポリシー例 ※色々書き方はあるのでご参考程度に・・・アカウントA VPCe (I/F型) VPCe (G/W型) Read Only Role CloudFormation S3 Replication ① ② ③ ④ ⑤ ① ② ③ ④ ⑤ bucket-a

Slide 72

Slide 72 text

Slide 73

Slide 73 text

S3 "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}:*" ] } S3バケットポリシー例 ※色々書き方はあるのでご参考程度に・・・アカウントA Read Only Role CloudFormation S3 Replication ③ ④ ⑤ ③ ④ ⑤ bucket-a リクエスト元の IAM ロールIDを検査。

Slide 74

Slide 74 text

"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}:*" ] } (注意点) ③のスイッチロール時はランダムにセッション名が発行されるが、Principal 句でワイルドカード利用不可。 aws:userId を使用して制御する。参考) https://dev.classmethod.jp/articles/s3-bucket-acces-to-a-specific-role/ S3バケットポリシー例 ※色々書き方はあるのでご参考程度に・・・アカウントA Read Only Role ③ ③ bucket-a アカウントB (ユーザー管理) IAM User AWS STS S3

Slide 75

Slide 75 text

S3 "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}:*" ] } S3バケットポリシー例 ※色々書き方はあるのでご参考程度に・・・アカウントA CloudFormation S3 Replication ④ ⑤ ③ ④ ⑤ bucket-a AWSサービスの場合は、Principal句や aws:PrincipalServiceName でも記述可。

Slide 76

Slide 76 text

S3 "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}:*" ] } S3バケットポリシー例 ※色々書き方はあるのでご参考程度に・・・アカウントA bucket-a バケット自体のArnをResource句に指定すると Condition句の設定ミス時にrootユーザー以外でバケットを全く触れなくなるので要注意。

Slide 77

Slide 77 text

バケットポリシーだけだと、煩雑になりがち・・・

Slide 78

Slide 78 text

アクセスポイントも利用する方がバケットポリシーの内容を分割できておすすめ！アカウントA VPCe (I/F型) VPCe (G/W型) Read Only Role S3 CloudFormation S3 Replication bucket-a Access point Access point VPC access point

Slide 79

Slide 79 text

アカウントA VPCe (I/F型) VPCe (G/W型) Read Only Role S3 CloudFormation S3 Replication bucket-a Access point Access point VPC access point S3アクセスポイントポリシーのざっくり説明 ※詳細は割愛バケットポリシー: 特定のアクセスポイントからのリクエスト以外をDeny。

Slide 80

Slide 80 text

アカウントA VPCe (I/F型) VPCe (G/W型) Read Only Role S3 CloudFormation S3 Replication Access point Access point VPC access point S3アクセスポイントポリシーのざっくり説明 ※詳細は割愛アクセスポイントポリシー: 各アクセスポイントで設定。特定経路以外をDeny。

Slide 81

Slide 81 text

（余談）S3アクセスポイントを使いたかったけど使えなかった話のご紹介

Slide 82

Slide 82 text

アクセスポイントの利用はArn形式のみ（だった） → アプリケーション・ミドルウェアで未対応のケースあり・・・ arn:aws:s3:{リージョン名}:{アカウントID}:accesspoint/ {S3アクセスポイント名}/{オブジェクト名}

Slide 83

Slide 83 text

アップデートでバケット名と同様のエイリアスに対応したので、今なら心置きなく使えそう？ https://aws.amazon.com/jp/about-aws/whats-new/2021/07

Slide 84

Slide 84 text

脱線しましたが、S3バケットもバケットポリシーで特定経路以外をDenyすれば、大丈夫そう VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 bucket-b S3 ・・・運用者アカウントA ① ② ③ ① 閉域用端末 ② EC2 ③ S3バケット

Slide 85

Slide 85 text

ポリシー関連をまとめてみる VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 bucket-b S3 ・・・運用者アカウントA Ⅰ. IAMポリシー： s3:ResourceAccountで社外バケットへのアクセスをDeny ※S3に触れる全IAMロールに適用推奨 Ⅱ.VPCeポリシー： aws:PrincipalAccount でクレデンシャルの持込をDeny ※ResourceAccountの併用もあり Ⅲ.バケットポリシー： aws:sourceVpceなどで特定経路以外をDeny ※アクセスポイント利用がおすすめ Ⅰ Ⅰ Ⅲ Ⅱ

Slide 86

Slide 86 text

S3バケット周りの設定補足  パブリックアクセスブロック → アカウント単位で有効化  S3バケット・オブジェクトのACL → 不要なアクセス許可を付与しない  カスタマー管理CMK → 重要データをもつS3バケットは、カスタマー管理CMKで暗号化

Slide 87

Slide 87 text

（余談）発見的統制も相応の体力・・・  CSPM(Cloud Security Posture Management)の製品を導入 →多数の様々なルールから、適用対象・カスタマイズ対象を制定  Security HubのCISベンチマークを順守 →ConfigやCloudWatchアラーム周りの通知をポチポチ実装

Slide 88

Slide 88 text

まとめ  N/W的に閉域構成だとしても、データ流出のリスクはあり、安心できない  閉域要件のS3周りで気を付けたい点は・・・ • 社外バケットへのアクセスを防いでいるか • クレデンシャルの持込を対策できているか • 機微情報を扱うバケットはアクセス経路を限定しているか  （課題？）境界防御からの脱却を夢見る