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

Security-JAWS第23回での登壇資料です。
イベントURL：https://s-jaws.doorkeeper.jp/events/127684
登壇動画URL：https://youtu.be/Q-dKRmVgpRA?t=5860

Transcript

1. 閉域要件における S3周辺ポリシーの組み合わせ方 2021.11.11 Security-JAWS 第23回 Copyright (c) Mizuho Research & Technologies, Ltd. All Rights Reserved. （免責事項） 当資料は情報提供のみを目的として作成されたものであり、商品の勧誘を目的としたものではありません。 本資料は、当社が信頼できると判断した各種データに基づき作成されておりますが、その正確性、確実性を 保証するものではありません。また、本資料に記載された内容は予告なしに変更されることもあります。
2. 自己紹介  氏名：松尾 優成（まつお ゆうせい）  所属：先端技術研究部 兼 プロジェクト推進部  役割：  AWS社内案件の設計・構築サポート  みずほコミュニティ ERG ”コクリエ” の運営
3. みずほのAWS利用経緯  2018年：AWS上にグループ共通基盤を構築、CCoE設立  2019年：AWS人材育成施策開始  2020年：みずほ内でAWS開発案件数が拡大 https://www.nikkeibp.co.jp/atclpubmkt/book/21/S70150/
4. 本日話すこと  閉域要件で、S3のデータ流出を防ぐための予防的統制観点  各ポリシーをどのように組み合わせてS3のデータ流出を防ぐか  IAMポリシー  VPCエンドポイントポリシー  S3バケットポリシー
5. 本日話さないこと  データが流出した場合の発見的統制観点  S3 ACLやKMS周りの詳細な設定  S3以外のデータを保有するサービスに対する対策  オンプレミス側のデータ流出対策
6. みずほのAWS利用状況  重要情報を扱うシステムの場合、閉域網とすることが主流  AWS と自社設備のハイブリッド・クラウド構成となることが多い  重要情報を扱う閉域用端末と、マネコン用のインターネット端末2種で運用  ベストプラクティスに沿って、マルチアカウント構成が主流
7. アカウントA 構成概要  オンプレミスからS3に格納したユーザー情報を、EC2 で分析して還元するシステム。 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) 閉域用 bucket-b S3 ・ ・ ・ EC2 運用者
8. アカウントA 構成概要  オンプレミスからS3に格納したユーザー情報を、EC2 で分析して還元するシステム。 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) 閉域用 bucket-b S3 ・ ・ ・ EC2 運用者 ①オンプレミスにある ユーザー情報を・・・
9. アカウントA 構成概要  オンプレミスからS3に格納したユーザー情報を、EC2 で分析して還元するシステム。 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) 閉域用 bucket-b S3 ・ ・ ・ EC2 運用者 ②S3にアップロード
10. アカウントA 構成概要  オンプレミスからS3に格納したユーザー情報を、EC2 で分析して還元するシステム。 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) 閉域用 bucket-b S3 ・ ・ ・ EC2 運用者 ③S3のデータをEC2でETL処理
11. アカウントA 構成概要  オンプレミスからS3に格納したユーザー情報を、EC2 で分析して還元するシステム。 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) 閉域用 bucket-b S3 ・ ・ ・ EC2 運用者 ④EC2から再度S3に アップロードし・・・
12. アカウントA 構成概要  オンプレミスからS3に格納したユーザー情報を、EC2 で分析して還元するシステム。 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) 閉域用 bucket-b S3 ・ ・ ・ EC2 運用者 ⑤オンプレミスに処理済みの ユーザー情報を還元
13. アカウントA 構成概要（補足）  ユーザーごとに専用のS3バケットがあり、ユーザー増加に応じてS3バケットも増加。  バッチ処理のみで、インターネットアクセスなし。 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) 閉域用 bucket-b S3 ・ ・ ・ EC2 運用者
14. 閉域網だからといって、きちんと対策しないと・・・ VPC Corporate data center Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 運用者 アカウントA bucket-a bucket-b S3 ・ ・ ・
15. 閉域網だからといって、きちんと対策しないと・・・ VPC Corporate data center Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 運用者 アカウントC（社外） アカウントA bucket-z 流出！ C C データ流出リスクがある！→ C
16. データ流出観点で着目するポリシーは3つ VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 bucket-b S3 ・ ・ ・ 運用者 アカウントA Ⅰ. IAMポリシー Ⅱ. VPCエンドポイントポリシー Ⅲ. バケットポリシー Ⅰ Ⅰ Ⅲ Ⅱ
17. データを保有するコンポーネントから データ流出の対策を考えてみる
18. アカウントA 重要データを保持するのは3箇所 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) 閉域用 bucket-b S3 ・ ・ ・ EC2 ① 閉域用端末 ② EC2 ③ S3バケット 運用者 ←これらに置かれたデータが流出するのを防ぎたい・・・！ ① ② ③
19. VPCエンドポイントを利用するアクセス者側で考えてみる
20. VPCe利用者のアクセス権限 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 bucket-b S3 ・ ・ ・ 運用者 アカウントA ① ② ③
21. VPCe利用者のアクセス権限 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 bucket-b S3 ・ ・ ・ 運用者 アカウントA ① 閉域用端末 ② EC2 ③ S3バケット ←①と②に焦点を絞ってみる ① ② ③
22. 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-*“ }
23. 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-*“ } IAMポリシーのAction句は最小権限を前提。
24. 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-*“ } 最小権限を厳密にするならば、Resource句で bucket-a, bucket-b のように書くべきだが・・・
25. 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-*“ } S3バケット増加に伴うポリシー更新体力を 抑えるため、ワイルドカードを使いたい
26. もし、ワイルドカードを使わなかったら・・・？
27. 開発者 権限管理者 S3バケットが増加したので、IAMロールに 権限を追加してもらえますか？ 11/1(月)
28. 開発者 権限管理者 S3バケットが増加したので、IAMロールに 権限を追加してもらえますか？ 5営業日で対応します！ 11/1(月)
29. 開発者 権限管理者 S3バケットが増加したので、IAMロールに 権限を追加してもらえますか？ 5営業日で対応します！ S3バケットのArnを間違えたので、依頼内容を 修正したいのですが・・・ 11/1(月) 11/4(木)
30. 開発者 権限管理者 S3バケットが増加したので、IAMロールに 権限を追加してもらえますか？ 5営業日で対応します！ 別途、5営業日で対応します！ 11/1(月) 11/4(木) S3バケットのArnを間違えたので、依頼内容を 修正したいのですが・・・
31. 開発者 権限管理者 S3バケットが増加したので、IAMロールに 権限を追加してもらえますか？ 5営業日で対応します！ 別途、5営業日で対応します！ S3バケットが更に増加し・・・(ry 11/1(月) 11/4(木) 11/8(月) S3バケットのArnを間違えたので、依頼内容を 修正したいのですが・・・
32. 開発者 権限管理者 S3バケットが増加したので、IAMロールに 権限を追加してもらえますか？ 5営業日で対応します！ 別途、5営業日で対応します！ S3バケットが更に増加し・・・(ry 11/1(月) 11/4(木) 11/8(月) S3バケットのArnを間違えたので、依頼内容を 修正したいのですが・・・ ※Permissions Boundaryは 本題から逸れるので考慮外
33. 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-*“ } というわけで、やはりワイルドカードを使いたい！
34. 社外アカウントに同様の命名規則で S3バケットを作られたら・・・？ "arn:aws:s3:::bucket-a“ "arn:aws:s3:::bucket-b“ "arn:aws:s3:::bucket-*“
35. 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に作成
36. 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-*“ }
37. 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-*“ }
38. 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/*" } 流出！
39. IAMポリシーでワイルドカードを使いつつ、 アクセス先のS3バケットを自社アカウントに制限したい
40. 2020年末にこんなアップデートが・・・
41. https://aws.amazon.com/jp/about-aws/whats-new/2020/12/
42. https://aws.amazon.com/jp/about-aws/whats-new/2020/12/
43. https://aws.amazon.com/jp/about-aws/whats-new/2020/12/
44. 条件キー s3:ResourceAccount で解決できそう！ https://aws.amazon.com/jp/about-aws/whats-new/2020/12/
45. ここでは、IAM側で記述してみる https://aws.amazon.com/jp/about-aws/whats-new/2020/12/
46. 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-*" }
47. 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/
48. 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-*" }
49. でも、社外アカウントのクレデンシャルを持ち込まれたら・・・？
50. クレデンシャル持ち込みパターン Corporate data center アカウントC（社外） アカウントA bucket-z アカウントC で bucket-zに アクセスできるロールを追加 C
51. クレデンシャル持ち込みパターン VPC Corporate data center Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 運用者 アカウントC（社外） アカウントA bucket-z アクセス者側で アカウントCの クレデンシャルを利用 C C C
52. クレデンシャル持ち込みパターン VPC Corporate data center Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 運用者 アカウントC（社外） アカウントA bucket-z 流出！ C C C
53. クレデンシャル持ち込みパターン VPC Corporate data center Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 運用者 アカウントC（社外） アカウントA bucket-z 流出！ C C 社外のクレデンシャルを持ち込まれると、 S3 データイベントの CloudTrail ログが アカウントAで記録されないため、要注意。 C
54. クレデンシャル持ち込みによる他アカウントへの流出対策も s3:ResourceAccount ※ を VPCエンドポイントポリシーで使用すれば大丈夫 VPC VPCe (I/F型) VPCe (G/W型) ※アクセスポイントを使っている場合、 s3:DataAccessPointArnも有用。 アカウントC（社外） bucket-z
55. せっかくなので、VPCエンドポイントポリシーで 持ち込まれたクレデンシャルを拒否する手法も紹介 VPC VPCe (I/F型) VPCe (G/W型) アカウントC（社外） C C C
56. KMS開発者ガイド：https://docs.aws.amazon.com/ja_jp/kms/latest/ developerguide/kms-vpc-endpoint.html#vpce-policy 左記はKMS開発者ガイドの VPCエンドポイントポリシー例
57. KMS開発者ガイド：https://docs.aws.amazon.com/ja_jp/kms/latest/ developerguide/kms-vpc-endpoint.html#vpce-policy aws:PrincipalAccount で クレデンシャル持ち込みの対策可能。 S3 でも同様の考えで制限できるはず・・・
58. KMS開発者ガイド：https://docs.aws.amazon.com/ja_jp/kms/latest/ developerguide/kms-vpc-endpoint.html#vpce-policy しかし、この記載をそのまま使うと、 全ての Principal でアクセス不可・・・。 以下 Statement も追加で必要。 { "Action": "*", "Effect": "Allow", "Resource": "*“, “Principal": "*“ }
59. { "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
60. { "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
61. { "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 リポジトリ
62. { "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 リポジトリ
63. 重要データを保持するのは3箇所 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 bucket-b S3 ・ ・ ・ 運用者 アカウントA ① 閉域用端末 ② EC2 ③ S3バケット ←①と②は前述の対策で大丈夫そう ① ② ③
64. 重要データを保持するのは3箇所 VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 bucket-b S3 ・ ・ ・ 運用者 アカウントA ① 閉域用端末 ② EC2 ③ S3バケット ←次に③S3バケットへの正常・不正経路を考えてみる ① ② ③
65. アカウント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制限
66. 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
67. 不正経路は色々あるので 正常経路以外を全て拒否したい アカウントA VPCe (I/F型) VPCe (G/W型) Read Only Role S3 CloudFormation S3 Replication ① ② ③ ④ ⑤ bucket-a
68. バケットポリシー・アクセスポイントポリシーで 前述の経路を制限できそう
69. バケットポリシーだけで制御する例を考えてみる
70. "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 ① ② ③ ④ ⑤ ① ② ③ ④ ⑤
71. 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
72. "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}:*" ] } リクエスト元のVPCエンドポイントIDを検査。 S3バケットポリシー例 ※色々書き方はあるのでご参考程度に・・・ アカウントA VPCe (I/F型) VPCe (G/W型) ① ② ① ② bucket-a S3
73. 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を検査。
74. "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
75. 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 でも記述可。
76. 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ユーザー以外で バケットを全く触れなくなるので要注意。
77. バケットポリシーだけだと、煩雑になりがち・・・
78. アクセスポイントも利用する方が バケットポリシーの内容を分割できておすすめ！ アカウントA VPCe (I/F型) VPCe (G/W型) Read Only Role S3 CloudFormation S3 Replication bucket-a Access point Access point VPC access point
79. アカウント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。
80. アカウントA VPCe (I/F型) VPCe (G/W型) Read Only Role S3 CloudFormation S3 Replication Access point Access point VPC access point S3アクセスポイントポリシーのざっくり説明 ※詳細は割愛 アクセスポイントポリシー: 各アクセスポイントで設定。特定経路以外をDeny。
81. （余談）S3アクセスポイントを使いたかったけど 使えなかった話のご紹介
82. アクセスポイントの利用はArn形式のみ（だった） → アプリケーション・ミドルウェアで未対応のケースあり・・・ arn:aws:s3:{リージョン名}:{アカウントID}:accesspoint/ {S3アクセスポイント名}/{オブジェクト名}
83. アップデートでバケット名と同様のエイリアスに対応したので、 今なら心置きなく使えそう？ https://aws.amazon.com/jp/about-aws/whats-new/2021/07
84. 脱線しましたが、S3バケットもバケットポリシーで 特定経路以外をDenyすれば、大丈夫そう VPC Corporate data center bucket-a Direct Connect VPCe (I/F型) VPCe (G/W型) EC2 閉域用 bucket-b S3 ・ ・ ・ 運用者 アカウントA ① ② ③ ① 閉域用端末 ② EC2 ③ S3バケット
85. ポリシー関連をまとめてみる 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 ※アクセスポイント利用がおすすめ Ⅰ Ⅰ Ⅲ Ⅱ
86. S3バケット周りの設定補足  パブリックアクセスブロック → アカウント単位で有効化  S3バケット・オブジェクトのACL → 不要なアクセス許可を付与しない  カスタマー管理CMK → 重要データをもつS3バケットは、カスタマー管理CMKで暗号化
87. （余談）発見的統制も相応の体力・・・  CSPM(Cloud Security Posture Management)の製品を導入 →多数の様々なルールから、適用対象・カスタマイズ対象を制定  Security HubのCISベンチマークを順守 →ConfigやCloudWatchアラーム周りの通知をポチポチ実装
88. まとめ  N/W的に閉域構成だとしても、データ流出のリスクはあり、安心できない  閉域要件のS3周りで気を付けたい点は・・・ • 社外バケットへのアクセスを防いでいるか • クレデンシャルの持込を対策できているか • 機微情報を扱うバケットはアクセス経路を限定しているか  （課題？）境界防御からの脱却を夢見る