サービス間での混乱した代理問題の防止
「混乱した代理」問題は、アクションを実行するためのアクセス許可を持たないエンティティが、より特権のあるエンティティにアクションの実行を強制できてしまう場合に生じる、セキュリティ上の問題です。AWS では、サービス間でのなりすましが、混乱した代理問題を生じさせることがあります。
サービス間でのなりすましは、1 つのサービス (呼び出し元サービス) が、別のサービス (呼び出し対象サービス) を呼び出すときに発生する可能性があります。呼び出し元サービスが操作され、それ自身のアクセス許可を使用して、本来アクセス許可が付与されるべきではない方法で別の顧客のリソースに対して働きかけることがあります。これを防ぐために AWS では、お客様のすべてのサービスのデータを保護するのに役立つツールを提供しています。これらのツールでは、アカウントのリソースへのアクセス権が付与されたサービスプリンシパルを使用します。詳細については、IAM ユーザーガイド の 混乱した代理問題 を参照してください。
特定のリソースへのアクセスについて、Amazon RDS が別のサービスに付与する許可を制限する場合は、リソースポリシー内で aws:SourceArn
および aws:SourceAccount
のグローバル条件コンテキストキーを使用することをお勧めします。
例えば、Amazon S3 バケットの Amazon リソースネーム (ARN) を使用する場合など、aws:SourceArn
値にアカウント ID が含まれていないことがあります。このような場合は、前出のグローバル条件コンテキストキーの両方を使用して、パーミッションを制限する必要があります。場合によっては、両方のグローバル条件コンテキストキーと、アカウント ID を含む aws:SourceArn
値を併用します。これらを同じポリシーステートメントで使用する場合は、aws:SourceAccount
の値には、aws:SourceArn
内のアカウントと同じアカウント ID を使用します。クロスサービスのアクセスにリソースを 1 つだけ関連付けたい場合は、aws:SourceArn
を使用します。クロスサービスによる使用のために、AWS アカウント内の任意のリソースを関連づけたい場合は、aws:SourceAccount
を使用します。
aws:SourceArn
の値には、Amazon RDS リソースタイプの ARN を指定する必要があります。詳細については、「Amazon RDS の Amazon リソースネーム (ARN)」を参照してください。
混乱した代理問題から保護するための最も効果的な方法は、リソースの完全な ARN を指定しながら、aws:SourceArn
グローバル条件コンテキストキーを使用することです。この時、リソースの完全な ARN が分からない場合や、複数のリソースを指定しているという場合があり得ます。このような場合、ARN の未知の部分については、ワイルドカード (*
) を指定しながら aws:SourceArn
グローバルコンテキスト条件キーを使用します。例は arn:aws:rds:*:
です。123456789012
:*
次の例では、Amazon RDS で aws:SourceArn
および aws:SourceAccount
グローバル条件コンテキストキーを使用して、「混乱した代理」問題を回避する方法を示します。
{ "Version": "2012-10-17", "Statement": { "Sid": "ConfusedDeputyPreventionExamplePolicy", "Effect": "Allow", "Principal": { "Service": "rds.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:rds:
us-east-1
:123456789012
:db:mydbinstance
" }, "StringEquals": { "aws:SourceAccount": "123456789012
" } } } }
グローバル条件コンテキストキーの aws:SourceArn
と aws:SourceAccount
を使用する他のポリシー例については、以下の各セクションを参照してください。
-
Amazon S3 バケットへのアクセスを設定する (PostgreSQL のインポート)
-
Amazon S3 バケットへのアクセスを設定する (PostgreSQL エクスポート)