EC2→S3で学ぶクロスアカウント権限設計の勘所

で学ぶクロスアカウント権限設計の勘所須永響

@gravitas580 須永響 Hibiki Sunaga CTC(伊藤忠テクノソリューションズ株式会社 ) 新卒３年目業務：AWSインフラ基盤の設計・構築好きなAWS技術：マルチアカウント、NW
:@gravitas580 About Me

アジェンダ @gravitas580 01 02 03 04 05 本日のテーマとゴールネットワーク接続経路の設計パターンポリシーの種類と使い方
クロスアカウントアクセスの権限設計パターンまとめ

@gravitas580 クロスアカウントの権限設計自信もってできますか？

@gravitas580 クロスアカウント接続での困りごとクロスアカウントでの権限の挙動がわからないそもそそも IAMポリシーの種類や仕組みよくわからなってないかも最小権限にしたいけど、どのアカウントにどの制限をかければ、、、

@gravitas580 本日のゴール EC2 → S3 というシンプルな構成でクロスアカウントでの権限の勘所を押さえる

@gravitas580 話すこと ➢ バケットポリシーの修正 ➢ AssumeRole利用 ➢ アクセスキー利用 IAMポリシーの種類と仕組み ➢
アイデンティティベースポリシー ➢ リソースベースポリシークロスアカウント接続の権限設計パターン

@gravitas580 本日検討する構成システムアカウントのEC2から、ログアカウントのS3にファイルをアップロードしたい

@gravitas580 クロスアカウントの接続で検討することネットワーク接続経路設計 NW どうやってEC2とS3をつなぐか権限設計 IAM 誰がどの権限でアクセスするのか

@gravitas580 クロスアカウントの接続で検討すること本日はIAMスペシャル！ ⇒ を中心に、もサクッと紹介ネットワーク接続経路設計 NW どうやってEC2とS3をつなぐか権限設計
IAM 誰がどの権限でアクセスするのか IAM NW

@gravitas580 接続パターン A) Gateway型VPCエンドポイント経由 B) TGW(or VPCピアリング)＆Interface型VPCエンドポイント経由 C) Internet Gateway経由

@gravitas580 接続パターン A) Gateway型VPCエンドポイント経由 ※STSエンドポイント、SSMエンドポイントは記載なし

@gravitas580 接続パターン B) TGW(or VPCピアリング)＆Interface型VPCエンドポイント経由 ※STSエンドポイント、SSMエンドポイントは記載なし

@gravitas580 接続パターン C) Internet Gateway経由 ※STSエンドポイント、SSMエンドポイントは記載なし

@gravitas580 接続パターン A) Gateway型VPCエンドポイント経由 B) TGW(or VPCピアリング)＆Interface型VPCエンドポイント経由 C) Internet Gateway経由
どのパターンで構築しても、権限設計には影響なし NW要件に応じて設計しましょうおすすめ

@gravitas580 同一アカウント内アクセスの場合どんなポリシーを付与すればよいか？

@gravitas580 同一アカウント内のEC2→S3なら簡単 ⚫ EC2のIAMロールにS3アクション許可ポリシーを付与

@gravitas580 クロスアカウントの場合同一アカウントのときと同じように「EC2のIAMロールにS3アクション許可ポリシーを付与」するだけではダメ

@gravitas580 IAMポリシーの種類 ✓ アイデンティティベースポリシー ✓ リソースベースポリシー他には、Permission Boundary, SCP, RCP,
ACL, セッションポリシーがある AWS Identity and Access Management でのポリシーとアクセス許可 - AWS Identity and Access Management

@gravitas580 アイデンティティベースポリシー ✓ IAMロール、IAMユーザー、IAMグループに付与するポリシー ✓ 「何をできるか/できないか」の権限を与えるポリシー EC2のIAMロールにつけていたS3アクション許可ポリシーが該当

@gravitas580 リソースベースポリシーとは？ ✓ リソースに設定するポリシー ✓ 「誰からのアクセスを許可/拒否するか」を設定するポリシー例： ➢ S3のバケットポリシー：誰が
S3バケットにアクセスできるか ➢ IAMロールの信頼ポリシー：誰が IAMロールを使用できるか

@gravitas580 EC2→S3のアクセスが可能なのは ✓ アイデンティティベースポリシーで許可 ✓ リソースベースポリシーで許可 ⇒両方揃えばアクセス可能

@gravitas580 実は同一アカウントの場合でも... 同一アカウントでも両方の許可が必要 ➢ EC2：IAMポリシー「 S3アクションを許可」 ➢ S3：バケットポリシー「EC2用IAMロールからのアクセスを許可」ただし、バケットポリシーはデフォルトで同一アカウントからのアクセスが許可されている
⇒ EC2へIAMポリシーを付与するだけでよい

@gravitas580 (再掲)EC2→S3のアクセスが可能なのは ✓ アイデンティティベースポリシーで許可 ✓ リソースベースポリシーで許可 ⇒両方揃えばアクセス可能

@gravitas580 実装パターン 3つ ① バケットポリシーの修正 ② AssumeRole ③ アクセスキー

@gravitas580 パターン1: バケットポリシーの修正 ⚫ EC2のIAMロールでログアカウントS3へのアクセスを許可 ⚫ S3のバケットポリシーではEC2のIAMロールからのアクセスを許可

@gravitas580 IAMポリシーのCondtion条件で aws:ResourceAccount、aws:ResourceOrgID を指定することで、特定のアカウント/Organizations配下アカウントに制限可能パターン1: ポリシー設定内容 EC2 IAMポリシー { "Effect":
"Allow", "Action": [ "s3:PutObject", "s3:GetObject" ], "Resource": "arn:aws:s3:::my-bucket/*" } S3 バケットポリシー { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:role/EC2Role" }, "Action": ["s3:PutObject", "s3:GetObject"], "Resource": "arn:aws:s3:::my-bucket/*" } Tips

@gravitas580 パターン１：まとめ ✓ どのアカウントの権限でアクセスしている？ ⇒システムアカウントの権限 ✓ バケットポリシーはデフォルトで同一アカウントからの権限のみ許可 ⇒バケットポリシーを修正

@gravitas580 パターン2: AssumeRole ⚫ ログアカウント内にAssumeRole用のIAMロールを作成 ⚫ EC2はログアカウントの権限に切り替えてS3にアクセス

@gravitas580 パターン2:必要なポリシー 3つのポリシーの設定が必要 1. EC2用 IAMポリシー → AssumeRoleの実行を許可 2. ログアカウントIAMロール用
アイデンティティベースポリシー → S3へアクセスを許可 3. ログアカウントIAMロール用信頼ポリシー → EC2ロールからのAssumeRoleを許可 S3目線では、同じアカウントからのアクセスのためバケットポリシーの修正は不要

@gravitas580 (補足)AssumeRoleの復習 AssumeRole ✓ sts:AssumeRoleというアクションを実行 ✓ 他のロールを借りる際に使用 ✓ 一時的な認証情報を取得 ➢
アクセスキー、シークレットアクセスキー、セッショントークン ※スイッチロール：マネコン上でAssumeRoleをする機能

@gravitas580 パターン2:ポリシー設定内容 EC2 IAMポリシー { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource":
"arn:aws:iam::999999999999:role/S3AccessRole" } ログアカウントIAMロールアイデンティティベースポリシー { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject" ], "Resource": "arn:aws:s3:::my-bucket/*" } ログアカウントIAMロール信頼ポリシー { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:role/EC2Role" }, "Action": "sts:AssumeRole" }

@gravitas580 パターン2:まとめ ✓ どのアカウントの権限でアクセスしている？ ⇒AssumeRoleすることで、ログアカウントの権限でアクセス ✓ バケットポリシーはデフォルトで同一アカウントからの権限のみ許可 ⇒(S3から見ると)同一アカウントの権限からのアクセスのためバケットポリシーは修正不要

@gravitas580 パターン3: アクセスキー（非推奨） ⚫ ログアカウントにS3アクションを許可したIAMユーザーを作成 ⚫ EC2内にIAMユーザーのアクセスキーをハードコード

@gravitas580 パターン３:まとめ ✓ どのアカウントの権限でアクセスしている？

@gravitas580 パターン３:まとめ ✓ どのアカウントの権限でアクセスしている？ ⇒アクセスキーを使用することで、ログアカウントの権限でアクセス ✓ バケットポリシーはデフォルトで同一アカウントからの権限のみ許可 ⇒(S3から見ると)同一アカウントの権限からのアクセスのためバケットポリシーは修正不要

@gravitas580 アクセスする権限の違いバケットポリシーの修正では、システムアカウントの権限でアクセス AssumeRoleでは、ログアカウントの権限でアクセス

@gravitas580 アクセスする権限の違い権限を一元管理するという点からも、AssumeRole推奨

@gravitas580 まとめ ⚫ クロスアカウントでのアクセスは、疎通性や権限に要注意 ⚫ クロスアカウントでの接続時にはどのアカウントの権限を使用しているのか意識するとSCP等の設計も組みやすくなる ➢ IAM Identity
Centerはログイン先アカウントのIAMロールを使用している ⚫ 実際はSCP, RCP, Permisson Boundary, ACLなども影響してくるのでまだまだ奥は深い ➢ 気になる方は「ポリシー評価ロジックフローチャート」などで検索

EC2→S3で学ぶクロスアカウント権限設計の勘所

EC2→S3で学ぶクロスアカウント権限設計の勘所

More Decks by Hibiki

Featured

Transcript