翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # リソースベースのポリシーとリソースコントロールポリシーによるコンソールアクセスの制御 **重要** コンソールのサインインアクセスはデフォルトで有効になっています。 AWS サインインでは、最初は無制限のコンソールアクセスが許可されます。制限を追加するには、アカウントまたは組織のコンソール認可設定を有効にします。作成したリソース許可ステートメントは、コンソール認可を有効にするまで効果がありません。「[リソースポリシーを使用したコンソールアクセスコントロールの開始方法](#console-access-control-getting-started)」を参照してください。 AWS サインインは、 AWS サインインへのアクセスを制御するためのリソースベースのポリシーとリソースコントロールポリシー (RCPs) をサポートします。これらのポリシーを使用して、認証前、認証中、認証後の AWS マネジメントコンソール アクセス全体でユーザー ID とネットワークの場所を検証します。ルートユーザーの場合、これらのポリシーは、認証情報収集を開始する前にネットワークの場所とユーザー ID を検証します。認証情報は、アクセスが予想されるネットワークから発信された場合にのみ入力できます。 AWS サインインリソースベースのポリシー: + を個々の AWS アカウントに適用します。 + アカウント管理者が、ネットワークパラメータとプリンシパル ID に基づいてコンソールへのアクセスを制限できるようにします。 リソースコントロールポリシー (RCPs): + AWS Organizations を通じて組織全体に適用します。 + すべてのメンバーアカウントを一元管理します。 どちらのポリシータイプも、認証前にアクセスを検証します。これにより、プリンシパルが予期しないネットワークからサインインページにアクセスできなくなります。 これらのポリシーは、引き続き適用される IAM アイデンティティベースのポリシーを置き換えるものではありません。 **注記** 組織レベルの設定と管理を含むリソースコントロールポリシーの完全なドキュメントについては、*AWS Organizations ユーザーガイド*の[「リソースコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)」を参照してください。このセクションでは、主に AWS サインインリソースベースのポリシーに焦点を当てます。 AWS サインインリソースベースのポリシーと RCPsは、次の認証方法に適用されます。 + **AWS マネジメントコンソール** – コンソールのログインページを使用した直接サインイン。 + **AWS IAM アイデンティティセンター** – IAM アイデンティティセンターを使用したコンソールサインイン。 + **フェデレーティッド ID プロバイダー** – SAML または OIDC フェデレーションを使用してサインインします。 + ** AWS サインインと統合されたアプリケーション** – Amazon Connect、Amazon QuickSight、 AWS Health Dashboard、Amazon AppStream、Amazon Lightsail、AWS IQ。 これらのコントロールは、アクセスキー (AWS SDKsまたは SigV4 で署名された API コール) を使用したプログラムによるアクセスには適用されません。 ## AWS サインインがリソースベースのポリシーを評価する方法 AWS サインインは、認証前 (認証前フェーズ) と認証成功後 (認証後フェーズ) の 2 つの時点で、該当するリソースベースのポリシーまたはリソースコントロールポリシー (RCPs) を評価します。各評価は、ポリシーで定義されている条件キーをチェックします。使用できるキーは、フェーズとアクションによって異なります。詳細については、「[サポートされている条件キー](#console-access-control-condition-keys)」を参照してください。 **注記** ルートユーザーのサインインの場合、パスワードプロンプトが表示される前に、予期しないネットワークからのアクセス試行がブロックされます。これにより、予期しないネットワークからの認証情報の送信が防止されます。 認証後、評価ではプリンシパルのアイデンティティベースのポリシーも考慮されます。関連するサインインアクションを拒否する IAM ポリシーは、ネットワーク条件が満たされた場合でも、コンソールセッションの付与を妨げる可能性があります。 ## サポートされているアクション AWS サインインリソースポリシー (リソースベースのポリシーと RCPs) では、次のアクションがサポートされています。 `signin:Authenticate` これは、サインインリクエストが受信されたときに評価される評価専用 (呼び出し不可) アクションです。これは認証前チェックであり、プリンシパルがサインインページ (ルートユーザー、IAM ユーザー) に認証情報を入力するか、ID プロバイダーまたは AWS STS (フェデレーティッドユーザー、ロール) の認証情報を使用してコンソールサインインを開始すると発生します。 **サポートされている条件キー:** `aws:SourceIp`、`aws:SourceVpc`、、`aws:SourceVpce`、`aws:VpcSourceIp``aws:RequestedRegion`、`signin:PrincipalArn`。 ユーザーの ID がまだ確認されていないため、プリンシパルベースのグローバル条件キー (`aws:PrincipalArn`、`aws:PrincipalAccount`) はこのアクションでは使用できません。 `signin:AuthorizeOAuth2Access` OAuth 認可コードの生成に使用されます。認証が成功すると、システムが OAuth 認可コードを生成すると、このアクションがトリガーされます。この時点で、ユーザーは認証され、プリンシパルベースの条件キーを使用できます。 **サポートされている条件キー:** `aws:SourceIp`、`aws:SourceVpc`、、`aws:SourceVpce`、`aws:VpcSourceIp`、`aws:RequestedRegion``aws:PrincipalArn`、`aws:PrincipalAccount`。 `signin:CreateOAuth2Token` この認証後アクションは、OAuth トークンの作成と交換に使用されます。このアクションは、アクセストークンの認可コードの引き換え、トークンの更新、トークン交換オペレーションの実行時にトリガーされます。このフェーズでは、プリンシパルベースの条件キーを使用できます。 **サポートされている条件キー:** `aws:SourceIp`、`aws:SourceVpc`、、`aws:SourceVpce`、`aws:VpcSourceIp`、`aws:RequestedRegion``aws:PrincipalArn`、`aws:PrincipalAccount`。 **重要** AWS サインインポリシー (リソースベースのポリシーまたは RCPs) を作成するときは、認証前ステートメント`signin:AuthorizeOAuth2Access`と認証`signin:CreateOAuth2Token`後ステートメント`signin:Authenticate`の 3 つのアクションすべてをポリシー全体でカバーします。コンソールのサインインでは、OAuth 2.0 を使用します。OAuth 2.0 は、3 つのアクションすべてを順番に流れます。ポリシーが アクションを省略した場合、対応するフェーズは保護されません。を含む VPC エンドポイントポリシーアクションについては`signin:CreateAccount`、[「AWS マネジメントコンソールのプライベートアクセス](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/console-private-access.html)」を参照してください。 ## サポートされている条件キー AWS サインインは、リソースベースのポリシーとリソースコントロールポリシー (RCPs) で次の条件キーをサポートします。これらのキーを使用して、ネットワークの場所とプリンシパル ID に基づいてコンソールへのアクセスを制御します。 + **ネットワークベース (すべてのアクション):** `aws:SourceIp`、`aws:SourceVpc`、`aws:SourceVpce`、`aws:VpcSourceIp`、`aws:RequestedRegion`。 + **ID ベース (認証後アクション):** `aws:PrincipalArn`、`aws:PrincipalAccount`。 + **サービス固有 (事前認証のみ):** `signin:PrincipalArn`。 詳細な使用ルール、オペレータの互換性、組み合わせの制限、アクション別の可用性マトリックスについては、「」を参照してください[AWS サインイン条件キーリファレンス](reference-signin-condition-keys.md)。 ## リソースポリシーを使用したコンソールアクセスコントロールの開始方法 **前提条件** + AWS CLI がインストールされ、設定されています。 + 適切な IAM アクセス許可 (「」を参照[AWS マネージドポリシー: AWSSignInResourcePolicyManagement](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSSignInResourcePolicyManagement))。 + 識別されたネットワーク境界 (IP 範囲、VPCs、または VPC エンドポイント）。 + アクセスを保持するために指定された除外されたプリンシパル (推奨されますが、オプション）。 + ネットワークで出力フィルタリングを使用している場合は、 AWS サインインコントロールプレーンエンドポイントを許可リストに登録します (「」を参照[AWS 許可リストへのサインイン管理ドメイン](allowlist-domains.md#allowlist-domains-admin))。 **重要** 本番環境でコンソール認可を有効にする前に、緊急復旧アクセスを維持するために、少なくとも 1 つの除外されたプリンシパルを設定する AWS ことをお勧めします。ルートユーザーを含むすべてのプリンシパルは、明示的に除外されない限り、ポリシーの対象となります。除外されたプリンシパルはオプションですが、除外すると、ネットワーク条件が予期せず変化した場合にアカウントがロックアウトされるリスクが高まります。 AWS サインインポリシーのすべての書き込みオペレーション`--region us-east-1`に を指定します。 はこのリージョンからグローバルにポリシーを AWS レプリケートします。読み取りオペレーションは任意のリージョンをターゲットにできます。 ### ステップ 1: リソースアクセス許可ステートメントを作成する アクセスコントロールを定義するアクセス許可ステートメントを作成します。すべての書き込みオペレーションには が必要です `--region us-east-1` ( AWS サインインサービスは、このリージョンでのみポリシーの変更を受け入れます）。残りのパラメータ (`--source-vpc`、`--source-ip`、`--requested-region`、`--excluded-principal`) は、ポリシーの条件を定義します。たとえば、 は、us-west-2 リージョンのサインインエンドポイントへのサインインを制限する条件`--requested-region us-west-2`を追加します。 **例 – 企業 VPC へのアクセスを制限する:** ``` aws signin put-resource-permission-statement \ --source-vpc vpc-0abc123def456789 \ --requested-region us-west-2 \ --excluded-principal "arn:aws:iam::123456789012:user/EmergencyAdmin" \ --client-token unique-request-id-12345 \ --region us-east-1 ``` **例 – 特定の IP 範囲へのアクセスを制限します。** ``` aws signin put-resource-permission-statement \ --source-ip "{{IP_ADDRESS}}" \ --excluded-principal "arn:aws:iam::123456789012:role/BreakGlassRole" \ --region us-east-1 ``` **注記** `--excluded-principal` パラメータは、ネットワーク制限をバイパスする除外されたプリンシパルを指定し、ネットワーク条件が変化しても緊急アクセスを維持します。 ### ステップ 2: コンソール認可設定を有効にする 次の手順では、アカウントまたは組織のコンソールサインインプロセスのポリシーの適用を有効にします。リソース許可ステートメントはいつでも作成できますが、コンソール認可が有効になるまで評価されません。 **警告** コンソール認可を有効にすると、ネットワーク条件が正しく設定されていない場合、または既存のサービスコントロールポリシー (SCP) またはリソースコントロールポリシー (RCP) が AWS サインインアクションを拒否した場合、プリンシパルがロックアウトされる可能性があります。コンソール認可を有効にする前に、アクセス許可ステートメントが正しいことを確認し、`signin:Authenticate`、、または を拒否する SCP または RCP を削除`signin:AuthorizeOAuth2Access`または調整します`signin:CreateOAuth2Token`。 スタンドアロンアカウントの場合: ``` aws signin put-console-authorization-configuration \ --target-id \ --region us-east-1 ``` AWS Organizations の場合: ``` aws signin put-console-authorization-configuration \ --target-id \ --region us-east-1 ``` 設定の検証: ``` aws signin get-console-authorization-configuration \ --target-id \ --region ``` コンソール認可設定を削除します。 ``` aws signin delete-console-authorization-configuration \ --target-id \ --region us-east-1 ``` ### ステップ 3: ポリシーを検証する すべてのアクセス許可ステートメントを一覧表示します。 ``` aws signin list-resource-permission-statements \ --max-results 50 \ --region ``` 完全な統合ポリシーを取得します。 ``` aws signin get-resource-policy \ --region ``` `get-resource-policy` コマンドは、すべてのアクセス許可ステートメントで構成される完全なリソースベースのポリシーを返します。コンソールアクセスをテストする前に、このポリシーを確認して、意図したアクセスコントロールを反映していることを確認します。 ### リージョン別の可用性 コンソール認可 APIsは、すべての AWS 商用リージョンで使用できます。これらの APIs は、運用している任意のリージョンから呼び出すことができます。 **重要** 書き込みオペレーション (`put-console-authorization-configuration`、`put-resource-permission-statement`、`delete-console-authorization-configuration`、`delete-resource-permission-statement`) は、 `us-east-1`リージョンで実行する必要があります。で作成されたポリシー`us-east-1`は、グローバルに自動的にレプリケートされます。読み取りオペレーション (`get-console-authorization-configuration`、`list-resource-permission-statements`、`get-resource-policy`) は任意のリージョンから実行できます。 ### ポリシー構造を理解する AWS サインインポリシーには、コンソールのサインインフローのさまざまなフェーズを保護する 2 つのステートメントが含まれています。 + **認証前ステートメント (アクション: `signin:Authenticate`):** サインインリクエストが受信されたときに、認証が完了する前に評価されます。プリンシパルの ID `aws:PrincipalArn`が未確認であるため、グローバルキーはこのフェーズでは使用できません。このフェーズ`signin:PrincipalArn`では、特定のプリンシパルをネットワーク制限から除外できます。ネットワークベースの条件キーは、このフェーズで評価できます。 + **認証後ステートメント (アクション: `signin:AuthorizeOAuth2Access`、`signin:CreateOAuth2Token`):** 認証後、OAuth トークン交換中に評価されます。特定のプリンシパルを除外`aws:PrincipalArn`するために使用します。このフェーズでは、すべてのネットワークベースおよびアイデンティティベースの条件キーを評価できます。 コンソールのサインインでは OAuth 2.0 が使用されるため、両方のステートメントが必要です。OAuth 2.0 は 3 つのアクションすべてを順番に流れます。ステートメントが 1 つしかないポリシーでは、他のフェーズは保護されません。 `signin:PrincipalArn`はルートユーザー、IAM ユーザー、ロールのプリンシパルタイプをサポートします。 はすべてのプリンシパルタイプ (ルートユーザー、IAM ユーザー、フェデレーティッドユーザー、ロール) `aws:PrincipalArn`をサポートします。 ## ポリシーの例 ### 例 1: ネットワーク境界と除外されたプリンシパルを持つ RCP 次のリソースコントロールポリシー (RCP) は、組織内のすべてのアカウントで、企業ネットワークの外部からの AWS マネジメントコンソール サインインを拒否します。指定された除外されたプリンシパルは緊急アクセスの対象外です。VPC IDs はリージョン内でのみ一意であるため、ポリシーには、予想されるリージョンへの VPC ベースのアクセスをピン留めする 3 番目のステートメントが含まれます。 `EnforceNetworkPerimeterPreAuth` ステートメントは、 `signin:PrincipalArn`を使用して、事前認証フェーズ中に除外されたプリンシパルを除外します。`EnforceNetworkPerimeterPostAuth` ステートメントは を使用して`aws:PrincipalArn`、認証後に除外されたプリンシパルを除外します。`EnforceSourceVPCRegion` ステートメントは、リクエストリージョンが VPC リージョンと一致することを確認し、指定された VPC の予想されるリージョンへのアクセスを制限します。 ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "EnforceNetworkPerimeterPreAuth", "Effect": "Deny", "Principal": "*", "Action": ["signin:Authenticate"], "Resource": "*", "Condition": { "ArnNotEquals": { "signin:PrincipalArn": [ "arn:aws:iam::111122223333:root", "arn:aws:iam::444455556666:root", "arn:aws:iam::777788889999:user/EmergencyUser", "arn:aws:iam::777788889999:role/OrgBreakGlassRole" ] }, "NotIpAddressIfExists": { "aws:SourceIp": "" }, "StringNotEquals": { "aws:SourceVpc": "" } } }, { "Sid": "EnforceNetworkPerimeterPostAuth", "Effect": "Deny", "Principal": "*", "Action": ["signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access"], "Resource": "*", "Condition": { "ArnNotEquals": { "aws:PrincipalArn": [ "arn:aws:iam::111122223333:root", "arn:aws:iam::444455556666:root", "arn:aws:iam::777788889999:user/EmergencyUser", "arn:aws:iam::777788889999:role/OrgBreakGlassRole" ] }, "NotIpAddressIfExists": { "aws:SourceIp": "" }, "StringNotEquals": { "aws:SourceVpc": "" } } }, { "Sid": "EnforceSourceVPCRegion", "Effect": "Deny", "Principal": "*", "Action": [ "signin:Authenticate", "signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access" ], "Resource": "*", "Condition": { "StringEquals": { "aws:SourceVpc": "" }, "StringNotEqualsIfExists": { "aws:RequestedRegion": "" } } } ] } ``` このポリシー: + リクエストが企業 IP 範囲または企業 VPC から発信されない限り、サインインページへのアクセスを拒否します。除外されたルートアカウントと IAM ユーザーは、 `signin:PrincipalArn` (事前認証) によって除外されます。 + 企業の IP 範囲または VPC からの場合を除き、OAuth トークン交換を拒否します。除外されたルートアカウント、IAM ユーザー、ロールは、 `aws:PrincipalArn` (認証後グローバルキー) を介して除外されます。 + リクエストが指定された VPC から送信され、リージョンが一致しない場合、アクセスは拒否されます。 AWS VPC IDsはリージョン内で一意であり、同じ VPC ID は異なるリージョンに存在する可能性があります。 + RCP として設定されている場合、AWS Organization 全体にグローバルに適用されます。 ### 例 2: 除外されたプリンシパルを持つ IP ベースのアクセスのリソースベースのポリシー 次のリソースベースのポリシーは、指定された IP 範囲外からリクエストを行うすべてのプリンシパルへのコンソールアクセスを拒否します。除外されたプリンシパルは除外されます。このポリシーには、サービス固有の`signin:PrincipalArn`キーを使用する認証前ステートメントと、グローバル`aws:PrincipalArn`キーを使用する認証後ステートメントの 2 つのステートメントが含まれています。 ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": ["signin:Authenticate"], "Resource": "*", "Condition": { "ArnNotEquals": { "signin:PrincipalArn": "" }, "NotIpAddress": { "aws:SourceIp": "" }, "StringEquals": { "aws:ResourceAccount": "" } } }, { "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": ["signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access"], "Resource": "*", "Condition": { "ArnNotEquals": { "aws:PrincipalArn": "" }, "NotIpAddress": { "aws:SourceIp": "" }, "StringEquals": { "aws:ResourceAccount": "" } } } ] } ``` このポリシー: + IP 範囲 から接続しない限り、すべてのプリンシパルへのアクセスを拒否します``。 + (事前認証) と `signin:PrincipalArn` (事後認証) を使用して、除外されたプリンシパルをネットワーク制限から除外`aws:PrincipalArn`します。 + リソースベースのポリシーが設定されている ( によって識別される) 特定のアカウントにのみ適用されます``。 ## ベストプラクティス ### 緊急復旧アクセスのために除外されたプリンシパルを設定する AWS では、本番環境でコンソール認可ポリシーを適用する前に、少なくとも 1 人の除外ユーザーを設定することをお勧めします。認証前段階では、`signin:PrincipalArn`条件キーはルートユーザー、IAM ユーザー、ロールプリンシパルを除外します。認証後段階では、`aws:PrincipalArn`条件キーはすべてのプリンシパルタイプ (ルートユーザー、IAM ユーザー、フェデレーティッドユーザー、ロール) を除外します。 除外されたプリンシパルはオプションですが、除外すると、ネットワーク条件が予期せず変化したり、ポリシーの設定が間違っていたりした場合に、アカウントがロックアウトされるリスクが高まります。 推奨される除外プリンシパル設定ステップ: 1. 除外された IAM ロールを作成します (例: `BreakGlassRole`)。 1. 除外されたロールの場合、ロールの信頼ポリシーに MFA が必要です。 1. 緊急復旧に必要な最小限のアクセス許可のみを、除外された ID に付与します。 1. 認証前 (`signin:PrincipalArn`) ポリシーステートメントと認証後 (`aws:PrincipalArn`) ポリシーステートメントの両方に、除外されたプリンシパル ARN を含めます。 1. 復旧手順を文書化し、 の外部に安全に保存します AWS。 1. 除外されたプリンシパルアクセスを定期的にテストして、必要に応じて機能することを確認します。 ### 復旧アクセスパスを維持する 上記の除外されたプリンシパルに加えて、コンソール認可ポリシーが予期せずサインインをブロックした場合に、代替のアクセス方法が利用可能であることを確認します。 + **ロールベースのプログラムによるアクセス:** コンソール認可ポリシーは、インタラクティブコンソールのサインインにのみ適用されます。SigV4 で署名された API リクエストには適用されません。プログラムによるアクセス (既存のアクセスキー、クロスアカウントロールなど) がある場合は、それを使用して を呼び出し`signin:DeleteConsoleAuthorizationConfiguration`、制限ポリシーを削除します。認証情報には アクセス`signin:DeleteConsoleAuthorizationConfiguration`許可を含める必要があります ( `AWSSignInResourcePolicyManagement`管理ポリシーに含まれています）。 は、長期的な IAM ユーザーアクセスキーよりも一時的な認証情報 AWS を推奨します。メンバーアカウントの場合、管理アカウント管理者はメンバーアカウント (`aws sts assume-role`) `OrganizationAccountAccessRole` で引き受けて、これらの一時的な認証情報を取得できます。 + **AWS サポートリカバリ:** ルートユーザーアカウントの E メールと電話番号を最新の状態に保ちます。除外されたプリンシパルアクセスとプログラムによるアクセスの両方が利用できない場合、 AWS サポートは ID 検証後に復旧ポータルリンクを提供できます。完全な復旧プロセス[コンソール認可を有効にした後、アカウントからロックアウトされている](#console-access-control-ts-lockout)については、「」を参照してください。 ### 本番デプロイ前のテスト AWS では、ポリシーがアカウントに与える影響を徹底的にテストすることなく、制限付き RCPs を組織のルートにアタッチしないことをお勧めします。代わりに、一度に 1 つずつ、または少なくとも少数でアカウントを移動できる OU を作成して、キーアカウントからユーザーを誤ってロックしないようにします。 テストワークフロー: 1. プライマリネットワークの制限を使用して 1 つのアクセス許可ステートメントを作成します。 1. 非本番稼働用アカウントでコンソール認可を有効にします。 1. 許可されたネットワークと拒否されたネットワークの両方からのコンソールアクセスをテストします。 1. Amazon CloudTrail ログを確認して、ポリシー評価の動作を確認します。 1. 除外されたプリンシパルを使用してアクセスをテストします。 1. 追加のネットワークとアカウントに徐々に拡張します。 1. 本番稼働用アカウントを強制する前にモニタリングします。 ### defense-in-depthを使用した設計 AWS サインインリソースベースのポリシーとリソースコントロールポリシーを、より広範なセキュリティ戦略内の 1 つのレイヤーとして使用します。 AWS サインインポリシーは、ネットワークの場所とプリンシパル ID に基づいてコンソールへのアクセスを制限します。これらを他のポリシータイプと組み合わせて、包括的なアクセスコントロールを作成します。 + **AWS サインインポリシー (リソースベースのポリシーと RCPs):** 認証前、認証中、認証後のネットワークの場所とプリンシパルアイデンティティに基づいてコンソールへのアクセスを制限します。 + **IAM ポリシー:** サインイン後にユーザーが実行できるアクションを制御します。 + **サービスコントロールポリシー (SCPs):** 組織全体のアクセス許可ガードレールをすべてのプリンシパルに適用します。 + **VPC エンドポイントポリシー:** VPC エンドポイントを介してアクセスできるサービスとアカウントを制御します。 ### 継続的なモニタリングと監査 AWS CloudTrail は、すべての AWS サインインポリシーの評価と設定変更を自動的に記録します。これらのイベントを CloudTrail イベント履歴で最大 90 日間表示します。保持期間を長くするには、証跡を作成して Amazon S3 にイベントを配信します ([「証跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)」を参照）。リアルタイムアラートの場合は、 AWS サインインイベントに一致する Amazon EventBridge ルールを作成するか、メトリクスフィルターベースのアラームの CloudWatch Logs ロググループに配信するように証跡を設定するか、既存の SIEM ソリューションにイベントを転送します。 ## ユースケース ネットワーク境界の適用 社内 VPCs。個々のアカウントにはリソースベースのポリシーを使用し、組織全体の強制にはリソースコントロールポリシー (RCPs) を使用して、ユーザーが信頼できるネットワークロケーションからのみサインインできるようにし、パブリックネットワークまたは信頼されていないネットワークからの不正アクセスを防止します。 **シナリオ例:** 企業は、自社のネットワークまたは承認された AWS VPCs からすべてのコンソールにアクセスする必要があります。緊急管理者の緊急復旧アクセスを維持しながら、他のすべてのネットワークからのアクセスを拒否する 1 つのアカウントまたは組織全体の RCP にリソースベースのポリシーを設定します。 コンプライアンス要件 ネットワークベースのアクセスコントロールの規制要件を満たします。多くのコンプライアンスフレームワークでは、組織はネットワークの場所に基づいて機密システムへのアクセスを制限する必要があります。 AWS サインインポリシーは、これらの要件への準拠を示す監査可能で強制可能なコントロールを提供します。 **シナリオ例:** 金融サービス企業は、承認されたネットワークからのコンソールアクセスのみを要求する規制に準拠する必要があります。RCPsのネットワーク制限を適用し、コンプライアンスの証拠として AWS CloudTrail ログを維持します。 マルチアカウントガバナンス AWS Organizations 全体で一貫したコンソールアクセスポリシーを実装します。RCPsを使用して、すべてのメンバーアカウントに標準のネットワーク制限を適用し、個々のアカウントレベルの設定を必要とせずに一貫したセキュリティ体制を確保します。 **シナリオ例:** 100 以上の AWS アカウントを持つ企業はRCPs を使用して、すべてのコンソールアクセスが組織内の VPC エンドポイントから発信されることを要求するポリシーを適用し、すべてのアカウントで一貫したネットワークコントロールを確認します。 サードパーティーのアクセスコントロール 特定のネットワークからパートナーまたは請負業者に一時的なコンソールアクセスを付与します。組織は、全体的なセキュリティ体制を損なうことなく、外部関係者の時間制限付きネットワーク制限付きコンソールアクセスを作成できます。 **シナリオ例:** 企業はコンサルティング会社に一時的なコンソールアクセスを許可する必要があります。コンサルティング会社の既知の IP 範囲からのみ、およびコンサルタントに割り当てられた IAM ロールに対してのみアクセスを許可するリソースベースのポリシーを作成します。 コンソールへのアクセスを特定のプリンシパルに制限する ネットワークの場所に関係なく AWS マネジメントコンソール、定義された一連のプリンシパルのみに へのサインインを許可し、他のすべてのプリンシパルを拒否します。これは、VPC エンドポイントを使用しておらず、アイデンティティベースのコンソールの制限が必要なお客様に役立ちます。コンソールへのサインインが拒否されたプリンシパルは、プログラムによるアクセスを保持します。 AWS サインインポリシーはコンソールへのサインインのみをゲートし、除外したプリンシパルのみがサインインできます。 **シナリオ例:** ある会社では、管理者のみが コンソールを使用できるようにしています。これらは、管理者プリンシパル ARNsを設定します。有効な認証情報を持つ Amazon EC2 インスタンスロールは、プログラムによるアクセス許可を保持していても、除外されたプリンシパルではないため、コンソールにサインインできません。これは、コンソールのサインインに使用されるインスタンスロール認証情報の一般的なケースに対処します。 ## コンソールのアクセスコントロールのトラブルシューティング ### サインインリソースベースのポリシーのネットワーク条件によりサインインできない AWS サインインポリシーによってアクセスが拒否されると、次のいずれかのエラーメッセージが表示されることがあります。 + 「認証情報が正しくありません。もう一度試してください。」 (リソースベースのポリシーによる事前認証の拒否) + 「認証に失敗しました 無効なリクエスト」 (RCP による事前認証拒否) + 「認証に失敗しました: このアカウントにアクセスするには、別のネットワークからサインインするか、管理者に連絡して詳細を確認してください」（認証後拒否) これらのエラーのいずれかが表示され、アクセスを許可する必要があると思われる場合は、 AWS 管理者にお問い合わせください。CloudTrail ログで、`errorMessage`「リソースベースのポリシーにより承認が拒否されました」または「リソースコントロールポリシーにより承認が拒否されました」の`ConsoleLogin`イベントを確認し、どのポリシーステートメントがアクセスを拒否したかを特定できます。 **考えられる原因:** + ソース IP アドレスが許可された CIDR 範囲内にありません。 + 必要な VPC または VPC エンドポイントに接続されていません。 + ポリシーで想定されるリージョンと一致しないリージョンのサインインエンドポイントにアクセスしています。 + プリンシパル ARN がポリシーの除外されたプリンシパルに正しくリストされていません。 + ポリシーは最近更新され、変更はまだグローバルにレプリケートされていません。 **解決策**: + 社内ネットワークまたは VPN に接続していることを確認します。 + VPC エンドポイントベースの制限が設定されている場合は、正しい VPC エンドポイントを介して にアクセスしていることを確認します。 + AWS 管理者に連絡してポリシー設定を確認し、どのネットワークが承認されているかを確認してください。 + 除外されたプリンシパルとして設定されている場合は、除外されたプリンシパルリストでプリンシパル ARN が正しく設定されていることを確認します。 + ポリシーが最近変更された場合は、グローバルレプリケーションが完了するまで数分待ちます。 **管理者がこの問題の診断を行う場合:** + ポリシー評価イベントの AWS CloudTrail ログを確認して、アクセスを拒否したポリシーステートメントを特定します。 + `aws signin get-resource-policy` を使用して、現在のポリシー設定を確認します。 + ユーザーのネットワークロケーションがポリシーの条件と一致していることを確認します。 + ユーザーをネットワーク制限から除外する必要がある場合は、除外されたプリンシパルが正しく設定されていることを確認します。 ### コンソール認可を有効にした後、アカウントからロックアウトされている コンソール認可を設定し、アカウントにアクセスできなくなった場合、ポリシーを適用する前に除外されたプリンシパルを設定していない可能性があります。 アカウントタイプと使用可能な認証情報に応じて、アクセスを回復するためのパスが複数あります。 **オプション 1: プログラムによるアクセスを使用する (AWS CLI または SDK)** コンソール認可ポリシーは、インタラクティブコンソールのサインインにのみ適用されます。SigV4 で署名された API リクエストには適用されません。プログラムによるアクセス (既存のアクセスキー、クロスアカウントロールなど) がある場合は、それを使用して を呼び出し`signin:DeleteConsoleAuthorizationConfiguration`、制限ポリシーを削除します。使用する認証情報には、 を呼び出すアクセス許可が必要です`signin:DeleteConsoleAuthorizationConfiguration`。`AWSSignInResourcePolicyManagement` 管理ポリシーには、この permission. AWS recommends temporary credentials over long-term IAM user access keys が含まれています。メンバーアカウントの場合、管理アカウント管理者はメンバーアカウント`OrganizationAccountAccessRole`で引き受けて一時的な認証情報を取得できます。このロールは、組織に招待されたアカウントでは自動的に作成されません。 ``` aws signin delete-console-authorization-configuration \ --target-id \ --region us-east-1 ``` または、特定のアクセス許可ステートメントを削除します。 ``` # First, list statements to get the statement ID aws signin list-resource-permission-statements \ --region us-east-1 # Then delete the problematic statement aws signin delete-resource-permission-statement \ --statement-id \ --region us-east-1 ``` **オプション 2: AWS サポートに問い合わせる** プログラムによるアクセスがなく、アカウントアクセス`OrganizationAccountAccessRole`に を使用できない場合は、 AWS サポートに連絡してロックアウト復旧プロセスを開始してください。 復旧プロセスは次のように機能します。 1. 上記のオプションを使用して問題を解決できない場合は、 サポートセンターで AWS サポートケースを開きます。 AWS サポートは、アカウントを調べる前に ID を検証します。検証方法には、ルートユーザーアカウントの E メールアドレスの確認、電話検証コールへの応答、アカウントのセキュリティ質問への応答などがあります。 1. AWS サポートは、コンソールアクセスの問題がリソースベースのポリシーのロックアウトによって引き起こされることを確認します。 1. AWS サポートは復旧ポータルリンクを共有します。このリンクを使用して、 アクセス`signin:DeleteConsoleAuthorizationConfiguration`許可を持つアカウントの IAM プリンシパルでサインインします。このアクセス許可により、プリンシパルはロックアウトの原因となるコンソール認可設定を削除できます。 **重要** リカバリポータルは、すべてのリソース許可ステートメントを含む、アカウントのコンソール認可設定全体を削除します。リカバリポータルでは、 AWS サインインリソースベースのポリシーの再設定は許可されません。 復旧ポータルリンクは、 AWS サポートが共有してから 72 時間後に期限切れになります。その期間内に復旧を完了しない場合は、 AWS サポートに連絡してプロセスを再起動してください。 **アクセスを回復した後:** + リソース許可ステートメントを確認して更新し、適切に設定された除外されたプリンシパルを含めます。 + コンソール認可を再度有効にする前に、予想されるネットワークからのコンソールアクセスをテストします。 + 今後の参照用に復旧手順を文書化します。 ### 行った変更がすぐに表示されないことがある ポリシーの変更はグローバルにレプリケートされますが、レプリケーションには数分かかる場合があります。 **解決策**: + グローバルレプリケーションが完了するまで、ポリシーを変更してから数分待ちます。 + `get-resource-policy` コマンドを使用して変更を確認します。 ``` aws signin get-resource-policy --region ``` + ポリシー評価イベントの AWS CloudTrail ログをチェックして、新しいポリシーが評価されていることを確認します。 + オペレーションに正しいリージョンを使用していることを確認します (書き込みオペレーションでは を使用する必要があります`us-east-1`)。 + VPC エンドポイントベースの条件を使用する場合は、VPC エンドポイントポリシーも正しく設定されていることを確認します。 **一般的なポリシーレプリケーションの問題:** + **キャッシュされたサインインページ:** ブラウザはサインインページをキャッシュする場合があります。ブラウザキャッシュをクリアするか、シークレットウィンドウを使用してポリシーの変更をテストします。 + **競合するステートメント:** 複数のアクセス許可ステートメントがある場合は、相互に競合していないことを確認します。`get-resource-policy` 統合ポリシーを確認するには、 を使用します。 + **VPC エンドポイントポリシー:** AWS サインインポリシーは、VPC エンドポイントポリシーと連動します。どちらも必要なアクセスを許可する必要があります。