翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
と の AWS Shield 連携方法 IAM
IAM を使用して Shield へのアクセスを管理する前に、Shield で使用できるIAM機能を確認してください。
IAM で使用できる の機能 AWS Shield | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
IAM 機能 | Shield のサポート | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
あり |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
なし |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
あり |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
はい |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
あり |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
なし |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
部分的 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
あり |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
あり |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
あり |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
あり |
Shield およびその他の AWS のサービスがほとんどの IAM 機能と連携する方法の概要を把握するには、「 IAMユーザーガイド」のAWS 「 と連携する のサービスIAM」を参照してください。
Shield のアイデンティティベースのポリシー
アイデンティティベースのポリシーのサポート: あり
ID ベースのポリシーは、IAMユーザー、ユーザーのグループ、ロールなどの ID にアタッチできるJSONアクセス許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件をコントロールします。アイデンティティベースのポリシーを作成する方法については、「 ユーザーガイド」のIAM「ポリシーの作成IAM」を参照してください。
IAM アイデンティティベースのポリシーでは、許可または拒否されたアクションとリソース、およびアクションが許可または拒否される条件を指定できます。プリンシパルは、それが添付されているユーザーまたはロールに適用されるため、アイデンティティベースのポリシーでは指定できません。JSON ポリシーで使用できるすべての要素については、「 ユーザーガイド」の「 IAMJSONポリシー要素リファレンスIAM」を参照してください。
Shield アイデンティティベースのポリシーの例を表示するには、「AWS Shieldのアイデンティティベースのポリシーの例」を参照してください。
Shield 内のリソースベースのポリシー
リソースベースのポリシーのサポート: なし
リソースベースのポリシーは、リソースにアタッチするJSONポリシードキュメントです。リソースベースのポリシーの例としては、IAMロールの信頼ポリシー や Amazon S3 バケットポリシー などがあります。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスをコントロールできます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーでは、プリンシパルを指定する必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーティッドユーザー、または を含めることができます AWS サービス。
クロスアカウントアクセスを有効にするには、リソースベースのポリシーのプリンシパルとして、アカウント全体または別のアカウントのIAMエンティティを指定できます。リソースベースのポリシーにクロスアカウントのプリンシパルを追加しても、信頼関係は半分しか確立されない点に注意してください。プリンシパルとリソースが異なる にある場合 AWS アカウント、信頼されたアカウントのIAM管理者は、プリンシパルエンティティ (ユーザーまたはロール) にリソースへのアクセス許可も付与する必要があります。IAM 管理者は、アイデンティティベースのポリシーをエンティティにアタッチすることで権限を付与します。ただし、リソースベースのポリシーで、同じアカウントのプリンシパルへのアクセス権が付与されている場合は、アイデンティティベースのポリシーをさらに付与する必要はありません。詳細については、「 ユーザーガイド」の「 でのクロスアカウントリソースアクセスIAMIAM」を参照してください。
Shield のポリシーアクション
ポリシーアクションのサポート: あり
管理者はポリシーを使用して AWS JSON、誰が何にアクセスできるかを指定できます。つまり、どのプリンシパルがどのリソースに対してどのような条件下でアクションを実行できるかということです。
JSON ポリシーの Action
要素は、ポリシーでアクセスを許可または拒否するために使用できるアクションを記述します。ポリシーアクションの名前は通常、関連する AWS APIオペレーションと同じです。一致するAPIオペレーションがないアクセス許可のみのアクションなど、いくつかの例外があります。また、ポリシーに複数のアクションが必要なオペレーションもあります。これらの追加アクションは、依存アクションと呼ばれます。
このアクションは、関連付けられたオペレーションを実行するための権限を付与するポリシーで使用されます。
Shield アクションのリストを確認するには、「サービス認証リファレンス」の「AWS Shieldで定義されるアクション」を参照してください。
Shield のポリシーアクションは、アクションの前に以下のプレフィックス を使用します。
shield
単一のステートメントで複数のアクションを指定するには、アクションをカンマで区切ります。
"Action": [ "shield:
action1
", "shield:action2
" ]
ワイルドカード (*) を使用すると、複数のアクションを指定することができます。たとえば、Shield で List
で始まるすべてのアクションを指定するには、次のアクションを含めます。
"Action": "shield:List*"
Shield アイデンティティベースのポリシーの例を表示するには、「AWS Shieldのアイデンティティベースのポリシーの例」を参照してください。
Shield のポリシーリソース
ポリシーリソースのサポート: あり
管理者はポリシーを使用して AWS JSON、誰が何にアクセスできるかを指定できます。つまり、どのプリンシパルがどのリソースに対してどのような条件下でアクションを実行できるかということです。
Policy Resource
JSON要素は、アクションが適用されるオブジェクトを指定します。ステートメントには、Resource
または NotResource
要素を含める必要があります。ベストプラクティスとして、Amazon リソースネーム (ARN) を使用してリソースを指定します。これは、リソースレベルの許可と呼ばれる特定のリソースタイプをサポートするアクションに対して実行できます。
オペレーションのリスト化など、リソースレベルの権限をサポートしないアクションの場合は、ステートメントがすべてのリソースに適用されることを示すために、ワイルドカード (*) を使用します。
"Resource": "*"
Shield リソースタイプとその のリストを確認するにはARNs、「サービス認証リファレンス」の「 で定義されるリソース AWS Shield」を参照してください。各リソースARNの を指定できるアクションについては、「 で定義されるアクション AWS Shield」を参照してください。Shield リソースのサブセットへのアクセスを許可または拒否するには、ポリシーARNの resource
要素にリソースの を含めます。
では AWS Shield、リソースは保護と攻撃です。これらのリソースには、次の表に示すように、一意の Amazon リソースネーム (ARNs) が関連付けられています。
AWS Shield コンソールの名前 | AWS Shield SDK/ の名前CLI | ARN 形式 |
---|---|---|
イベントまたは攻撃 | AttackDetail |
|
保護 | Protection |
|
Shield リソースのサブセットへのアクセスを許可または拒否するには、ポリシーARNの resource
要素にリソースの を含めます。ARNs for Shield の形式は次のとおりです。
arn:
partition
:shield::account
:resource
/ID
を置き換える account
, resource
および ID
有効な値を持つ 変数。有効な値は次のとおりです。
-
account
: の ID AWS アカウント。値を指定する必要があります。 -
resource
: Shield リソースのタイプ。attack
または のいずれかprotection
。 -
ID
: Shield リソースの ID、またはワイルドカード (*
)。指定した に関連付けられている指定したタイプのすべてのリソースを示します AWS アカウント。
例えば、以下ARNでは、アカウント のすべての保護を指定します111122223333
。
arn:aws:shield::111122223333:protection/*
Shield リソースARNsの の形式は次のとおりです。
arn:
partition
:shield:region
:account-id
:scope
/resource-type
/resource-name
/resource-id
ARN 仕様の一般的な情報については、「」の「Amazon リソースネーム (ARNs)」を参照してください Amazon Web Services 全般のリファレンス。
wafv2
リソースARNsの に固有の要件を以下に示します。
-
region
: Amazon CloudFront ディストリビューションの保護に使用する Shield リソースの場合は、これを に設定しますus-east-1
。それ以外の場合は、保護されたリージョンリソースで使用している領域を設定します。 -
scope
: スコープを に設定して、Amazon CloudFront ディストリビューションで使用するかglobal
、 が AWS WAF サポートするリージョンリソースのいずれかregional
で使用します。リージョンリソースは、Amazon API Gateway REST API、Application Load Balancer 、 AWS AppSync GraphQL API、Amazon Cognito ユーザープール、 AWS App Runner サービス、および AWS Verified Access インスタンスです。 -
resource-type
: イベントまたは攻撃attack
の場合は 、保護protection
の場合は のいずれかの値を指定します。 -
resource-name
: Shield リソースに付けた名前を指定するか、ワイルドカード (*
) を指定して、 の他の仕様を満たすすべてのリソースを示しますARN。リソース名とリソース ID のどちらかを指定するか、両方にワイルドカードを指定する必要があります。 -
resource-id
: Shield リソースの ID を指定するか、ワイルドカード (*
) を指定して、 の他の仕様を満たすすべてのリソースを指定しますARN。リソース名とリソース ID のどちらかを指定するか、両方にワイルドカードを指定する必要があります。
例えば、次の例では、リージョン 111122223333
のアカウントのリージョンスコープACLsを持つすべてのウェブARNを指定しますus-west-1
。
arn:aws:wafv2:us-west-1:111122223333:regional/webacl/*/*
以下は、リージョン 111122223333
のアカウントのグローバルスコープMyIPManagementRuleGroup
を持つ という名前のルールグループARNを指定しますus-east-1
。
arn:aws:wafv2:us-east-1:111122223333:global/rulegroup/MyIPManagementRuleGroup/1111aaaa-bbbb-cccc-dddd-example-id
Shield アイデンティティベースのポリシーの例を表示するには、「AWS Shieldのアイデンティティベースのポリシーの例」を参照してください。
Shield のポリシー条件キー
サービス固有のポリシー条件キーのサポート: あり
管理者はポリシーを使用して AWS JSON、誰が何にアクセスできるかを指定できます。つまり、どのプリンシパルが、どのリソースに対してどのような条件下でアクションを実行できるかということです。
Condition
要素 (または Condition
ブロック) を使用すると、ステートメントが有効な条件を指定できます。Condition
要素はオプションです。イコールや未満などの 条件演算子 を使用して条件式を作成することで、ポリシーの条件とリクエスト内の値を一致させることができます。
1 つのステートメントに複数の Condition
要素を指定する場合、または 1 つの Condition
要素に複数のキーを指定する場合、 AWS では AND
論理演算子を使用してそれらを評価します。1 つの条件キーに複数の値を指定すると、 は論理OR
オペレーションを使用して条件 AWS を評価します。ステートメントの権限が付与される前にすべての条件が満たされる必要があります。
条件を指定する際にプレースホルダー変数も使用できます。例えば、IAMユーザー名でタグ付けされている場合にのみ、リソースにアクセスするアクセス許可をIAMユーザーに付与できます。詳細については、「 ユーザーガイド」のIAM「ポリシー要素: 変数とタグIAM」を参照してください。
AWS は、グローバル条件キーとサービス固有の条件キーをサポートします。すべての AWS グローバル条件キーを確認するには、「 ユーザーガイド」のAWS 「 グローバル条件コンテキストキーIAM」を参照してください。
Shield の条件キーのリストを確認するには、「サービス認証リファレンス」の「AWS Shieldの条件キー」を参照してください。条件キーを使用できるアクションとリソースについては、「 で定義されるアクション AWS Shield」を参照してください。
Shield アイデンティティベースのポリシーの例を表示するには、「AWS Shieldのアイデンティティベースのポリシーの例」を参照してください。
ACLs Shield の
をサポートACLs: いいえ
アクセスコントロールリスト (ACLs) は、リソースへのアクセス許可を持つプリンシパル (アカウントメンバー、ユーザー、またはロール) を制御します。ACLs はリソースベースのポリシーに似ていますが、JSONポリシードキュメント形式を使用しません。
ABAC Shield を使用する
サポート ABAC (ポリシー内のタグ): 部分的
属性ベースのアクセスコントロール (ABAC) は、属性に基づいてアクセス許可を定義する認可戦略です。では AWS、これらの属性はタグ と呼ばれます。タグは、IAMエンティティ (ユーザーまたはロール) および多くの AWS リソースにアタッチできます。エンティティとリソースのタグ付けは、 の最初のステップですABAC。次に、プリンシパルのタグがアクセスしようとしているリソースのタグと一致する場合に、オペレーションを許可するABACポリシーを設計します。
ABAC は、急速に成長している環境や、ポリシー管理が煩雑になる状況に役立ちます。
タグに基づいてアクセスを管理するには、aws:ResourceTag/
、key-name
aws:RequestTag/
、または key-name
aws:TagKeys
の条件キーを使用して、ポリシーの 条件要素でタグ情報を提供します。
サービスがすべてのリソースタイプに対して 3 つの条件キーすべてをサポートする場合、そのサービスの値はありです。サービスが一部のリソースタイプに対してのみ 3 つの条件キーのすべてをサポートする場合、値は「部分的」になります。
の詳細についてはABAC、「 ユーザーガイド」の「 とはABACIAM」を参照してください。のセットアップ手順を含むチュートリアルを表示するにはABAC、「 ユーザーガイド」の「属性ベースのアクセスコントロール (ABAC) を使用するIAM」を参照してください。
Shield での一時的な認証情報の使用
一時的な認証情報のサポート: あり
一部の は、一時的な認証情報を使用してサインインすると機能 AWS サービス しません。一時的な認証情報 AWS サービス を使用する などの詳細については、「 ユーザーガイド」のAWS サービス 「 と連携IAMする IAM 」を参照してください。
ユーザー名とパスワード以外の AWS Management Console 方法で にサインインする場合、一時的な認証情報を使用します。例えば、会社のシングルサインオン (SSO) リンク AWS を使用して にアクセスすると、そのプロセスによって一時的な認証情報が自動的に作成されます。また、ユーザーとしてコンソールにサインインしてからロールを切り替える場合も、一時的な認証情報が自動的に作成されます。ロールの切り替えの詳細については、「 IAMユーザーガイド」の「ロールへの切り替え (コンソール)」を参照してください。
一時的な認証情報は、 AWS CLI または を使用して手動で作成できます AWS API。その後、これらの一時的な認証情報を使用して . AWS recommends にアクセスできます AWS。これは、長期的なアクセスキーを使用する代わりに、一時的な認証情報を動的に生成することを推奨しています。詳細については、「」の「一時的なセキュリティ認証情報IAM」を参照してください。
Shield の転送アクセスセッション
転送アクセスセッションをサポート (FAS): はい
IAM ユーザーまたはロールを使用して でアクションを実行すると AWS、プリンシパルと見なされます。一部のサービスを使用する際に、アクションを実行することで、別のサービスの別のアクションがトリガーされることがあります。FAS は、 を呼び出すプリンシパルのアクセス許可を AWS サービス、ダウンストリームサービス AWS サービス へのリクエストのリクエストと組み合わせて使用します。FAS リクエストは、サービスが他の AWS サービス またはリソースとのやり取りを完了する必要があるリクエストを受け取った場合にのみ行われます。この場合、両方のアクションを実行するための権限が必要です。FAS リクエストを行う際のポリシーの詳細については、「転送アクセスセッション」を参照してください。
Shield のサービスロール
サービスロールのサポート: あり
サービスロールは、ユーザーに代わってアクションを実行するためにサービスが引き受ける IAM ロールです。IAM 管理者は、 内からサービスロールを作成、変更、削除できますIAM。詳細については、「 ユーザーガイド」の「 にアクセス許可を委任するロールの作成 AWS サービスIAM」を参照してください。
警告
サービスロールの許可を変更すると、Shield の機能が破損する可能性があります。Shield が指示する場合以外は、サービスロールを編集しないでください。
Shield のサービスリンクロール
サービスリンクロールのサポート: あり
サービスにリンクされたロールは、 にリンクされたサービスロールの一種です AWS サービス。サービスは、ユーザーに代わってアクションを実行するロールを引き受けることができます。サービスにリンクされたロールは に表示され AWS アカウント 、サービスによって所有されます。IAM 管理者は、サービスにリンクされたロールのアクセス許可を表示できますが、編集することはできません。
Shield サービスにリンクされたロールの作成または管理の詳細については、「Shield Advanced のサービスにリンクされたロールの使用」を参照してください。