はじめに
AWS DOPの勉強で頻繁に権限の問題が出てきてややこしいので整理してみる
評価フロー
アカウントA の EC2インスタンスが、アカウントB の S3バケットへアクセスするみたいなのを想定
AI解説
クロスアカウントアクセスは、大きく分けて2つのフェーズで評価されます。
フェーズ1: アカウントAのEC2インスタンスが、アカウントBのIAM Role Bの認証情報を取得する (AssumeRole)
これは、EC2インスタンスが、アカウントBのリソースにアクセスするための「身分証明書」を借りるプロセスです。
-
EC2インスタンスが
IAM Role Aの認証情報を取得:-
EC2インスタンスにアタッチされたインスタンスプロファイルを介して、
IAM Role Aの一時的なセキュリティ認証情報を取得しようとします。 -
この時、
IAM Role Aの信頼ポリシーが、ec2.amazonaws.comサービスプリンシパルからのsts:AssumeRoleを許可しているか評価されます。 -
許可されていなければ、ここで処理は停止します。
-
-
アカウントAの
IAM Role AがIAM Role BをAssumeRoleしようと要求:-
IAM Role Aの認証情報を持ったEC2インスタンスが、sts:AssumeRoleAPIを呼び出し、ターゲットとしてアカウントBのIAM Role Bを指定します。
-
-
アカウントAのSCPによる評価:
-
アカウントAに適用されているSCP Aが、
sts:AssumeRoleアクションを拒否していないか評価されます。 -
拒否されていれば、処理は停止します。
-
-
IAM Role AのIAMポリシーによる評価:-
IAM Role AにアタッチされているIAMポリシーが、アカウントBのIAM Role Bへのsts:AssumeRoleアクションを許可しているか評価されます。 -
拒否されていれば、処理は停止します。
-
-
アカウントBのSCPによる評価:
-
アカウントBに適用されているSCP Bが、アカウントAからの
sts:AssumeRoleアクションを拒否していないか評価されます。 -
拒否されていれば、処理は停止します。
-
-
IAM Role Bの信頼ポリシーによる評価:-
アカウントBの
IAM Role Bにアタッチされている信頼ポリシーが、アカウントAのIAM Role Aからのsts:AssumeRoleアクションを許可しているか評価されます。 -
拒否されていれば、処理は停止します。
-
-
IAM Role Bのパーミッションバウンダリーによる評価:-
もし
IAM Role Bにパーミッションバウンダリーが設定されていれば、sts:AssumeRoleアクションがその境界内で許可されているか評価されます。 -
拒否されていれば、処理は停止します。
-
→ これら全ての条件が「許可」であった場合、アカウントAのEC2インスタンスは、アカウントBのIAM Role Bの一時的な認証情報を取得します。
フェーズ2: アカウントAのEC2インスタンスが、取得したIAM Role Bの権限を使ってアカウントBのS3にアクセスする
EC2インスタンスは、IAM Role Bの認証情報を使用して、S3へのAPIリクエスト（例: s3:GetObject）を発行します。
-
アカウントBのSCPによる評価:
-
アカウントBに適用されているSCP Bが、
s3:GetObjectアクションを拒否していないか評価されます。 -
拒否されていれば、処理は停止します。
-
-
IAM Role BのIAMポリシーによる評価:-
IAM Role BにアタッチされているIAMポリシーが、ターゲットのS3バケットに対するs3:GetObjectアクションを許可しているか評価されます。 -
拒否されていれば、処理は停止します。
-
-
S3バケットのリソースベースポリシーによる評価:
-
ターゲットのS3バケットにアタッチされているバケットポリシーが、
IAM Role Bからのs3:GetObjectアクションを許可しているか評価されます。 -
拒否されていれば、処理は停止します。
-
-
IAM Role Bのパーミッションバウンダリーによる評価:-
もし
IAM Role Bにパーミッションバウンダリーが設定されていれば、s3:GetObjectアクションがその境界内で許可されているか評価されます。 -
拒否されていれば、処理は停止します。
-
→ これら全ての条件が「許可」であった場合のみ、アカウントAのEC2インスタンスはアカウントBのS3バケットにアクセスできます。