翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
サービス間での不分別な代理処理の防止
「混乱した代理」問題は、アクションを実行するためのアクセス許可を持たないエンティティが、より特権のあるエンティティにアクションの実行を強制できてしまう場合に生じる、セキュリティ上の問題です。では AWS、サービス間のなりすましにより、混乱した代理問題が発生する可能性があります。サービス間でのなりすましは、あるサービス (呼び出し元サービス) が、別のサービス (呼び出し対象サービス) を呼び出すときに発生する可能性があります。呼び出し元サービスが操作され、それ自身のアクセス許可を使用して、本来アクセス許可が付与されるべきではない方法で別の顧客のリソースに対して働きかけることがあります。これを防ぐため、 AWS では、アカウント内のリソースへのアクセス許可が付与されたサービスプリンシパルですべてのサービスのデータを保護するために役立つツールを提供しています。
が別のサービス AWS IoT に付与するアクセス許可をリソースに制限するには、リソースポリシーで aws:SourceArn
および aws:SourceAccount
グローバル条件コンテキストキーを使用することをお勧めします。両方のグローバル条件コンテキストキーを同じポリシーステートメントで使用する場合は、aws:SourceAccount
値と、aws:SourceArn
値に含まれるアカウントが、同じアカウント ID を示している必要があります。
混乱した代理問題から保護する最も効果的な方法は、リソースの完全な Amazon リソースネーム (ARN) で aws:SourceArn
グローバル条件コンテキストキーを使用することです。の場合 AWS IoT、 aws:SourceArn
はリソース固有のアクセス許可arn:
の場合は または の形式に従う必要がありますaws
:iot:region
:account-id
:resource-type/resource-id
arn:
。resource-id は、許可されたリソースの名前または ID、または許可されたリソース のワイルドカードステートメントにすることができますIDs。がお客様の AWS IoT リージョンaws
:iot:region
:account-id
:*
region
と一致し、 がお客様のアカウント ID account-id
と一致していることを確認します。
次の例は、 AWS IoT ロール信頼ポリシーで aws:SourceArn
および aws:SourceAccount
グローバル条件コンテキストキーを使用して、混乱した代理問題を防ぐ方法を示しています。その他の例については、「混乱した代理の防止の詳細な例」を参照してください。
{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Principal":{ "Service":"iot.amazonaws.com" }, "Action":"sts:AssumeRole", "Condition":{ "StringEquals":{ "aws:SourceAccount":"
123456789012
" }, "ArnLike":{ "aws:SourceArn":"arn:aws
:iot:us-east-1
:123456789012
:*
" } } } ] }
注記
アクセス拒否エラーが発生した場合は、Security Token Service (STS) と AWS のサービス統合が aws:SourceArn
および aws:SourceAccount
コンテキストキーをサポートしていない可能性があります。
混乱した代理の防止の詳細な例
このセクションでは、 AWS IoT ロール信頼ポリシーで aws:SourceArnおよび aws:SourceAccount グローバル条件コンテキストキーを使用して、混乱した代理問題を防止する方法の詳細な例を示します。
フリートプロビジョニング
プロビジョニングテンプレートリソースを使用してフリートプロビジョニングを設定できます。プロビジョニングテンプレートがプロビジョニングロールを参照する場合、そのロールの信頼ポリシーに aws:SourceArn
および aws:SourceAccount
条件キーを含めることができます。これらのキーは、設定が sts:AssumeRole
リクエストを呼び出すことができるリソースを制限します。
次の信頼ポリシーを持つロールは、SourceArn
で指定されたプロビジョニングテンプレートの IoT プリンシパル (iot.amazonaws.com
) によってのみ引き受けることができます。
{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Principal":{ "Service":"iot.amazonaws.com" }, "Action":"sts:AssumeRole", "Condition":{ "StringEquals":{ "aws:SourceAccount":"
123456789012
" }, "ArnLike":{ "aws:SourceArn":"arn:aws
:iot:us-east-1
:123456789012
:provisioningtemplate/example_template
" } } } ] }
JITP
just-in-time (JITP) のプロビジョニングでは、プロビジョニングテンプレートを CA とは別のリソースとして使用するか、CA 証明書設定の一部としてテンプレート本文とロールを定義できます。 AWS IoT ロール信頼ポリシーaws:SourceArn
の の値は、プロビジョニングテンプレートの定義方法によって異なります。
プロビジョニングテンプレートを別のリソースとして定義した場合、aws:SourceArn
の値は "arn:aws:iot:
になります。フリートプロビジョニング では同じポリシーの例を利用できます。region
:account-id
:provisioningtemplate/example_template
"
CA 証明書リソース内でプロビジョニングテンプレートを定義した場合、aws:SourceArn
の値は "arn:aws:iot:
または region
:account-id
:cacert/cert_id
""arn:aws:iot:
になります。CA 証明書の ID などのリソース識別子が作成時に不明な場合は、ワイルドカードを使用できます。region
:account-id
:cacert/*
"
次の信頼ポリシーを持つロールは、SourceArn
で指定された CA 証明書の IoT プリンシパル (iot.amazonaws.com
) によってのみ引き受けることができます。
{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Principal":{ "Service":"iot.amazonaws.com" }, "Action":"sts:AssumeRole", "Condition":{ "StringEquals":{ "aws:SourceAccount":"
123456789012
" }, "ArnLike":{ "aws:SourceArn":"arn:aws
:iot:us-east-1
:123456789012
:cacert/8ecde6884f3d87b1125ba31ac3fcb13d7016de7f57cc904fe1cb97c6ae98196e
" } } } ] }
CA 証明書を作成するときは、登録設定でプロビジョニングロールを参照できます。プロビジョニングロールの信頼ポリシーは、ロールを引き受けることができるリソースを制限するために aws:SourceArn
を使用できます。ただし、CA 証明書を登録するための最初の RegisterCACertificate 呼び出しでは、aws:SourceArn
条件に指定する CA 証明書ARNの はありません。
この問題を回避するには、つまり、 に登録されている特定の CA 証明書にプロビジョニングロールの信頼ポリシーを指定するには AWS IoT Core、次の操作を行います。
-
まず、
RegistrationConfig
パラメータを指定せずに RegisterCACertificate を呼び出します。 -
CA 証明書が に登録されたら AWS IoT Core、その証明書で UpdateCACertificate を呼び出します。
U pdateCACertificate 呼び出しで、プロビジョニングロールの信頼ポリシーを含む を、新しく登録
RegistrationConfig
された CA 証明書ARNのaws:SourceArn
に設定します。
認証情報プロバイダー
AWS IoT Core 認証情報プロバイダーの場合は、 でロールエイリアスを作成 AWS アカウント するために使用するのと同じ を使用しaws:SourceAccount
、 でARNロールエイリアスリソースタイプのリソースと一致するステートメントを指定しますaws:SourceArn
。 AWS IoT Core 認証情報プロバイダーで使用する IAMロールを作成するときは、ARNsロールを引き受ける必要があるロールエイリアスの をaws:SourceArn
条件に含めて、クロスサービスsts:AssumeRole
リクエストを承認する必要があります。
次の信頼ポリシーを持つロールは、 で roleAlias 指定された の AWS IoT Core 認証情報プロバイダー (credentials.iot.amazonaws.com
) のプリンシパルのみが引き受けることができますSourceArn
。プリンシパルが、 aws:SourceArn
条件に指定されているもの以外のロールエイリアスの認証情報を取得しようとすると、他のロールエイリアスが同じIAMロールを参照している場合でも、リクエストは拒否されます。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "credentials.iot.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "
123456789012
" }, "ArnLike": { "aws:SourceArn": "arn:aws
:iot:us-east-1
:123456789012
:rolealias/example_rolealias
" } } } ] }