翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Okta でダイレクト IAM フェデレーションアプリケーションの 1 回限りの設定を行う 1. 管理者アクセス権限を持つユーザーとしてご自身のOktaアカウントにサインインします。 1. Okta 管理コンソールの **[アプリケーション]** で、**[アプリケーション]** を選択します。 1. **[アプリカタログを参照]** を選択します。**[AWS アカウントフェデレーション]** を検索して選択します。それから**[統合の追加]** を選択します。 1. アカウントフェデレーションに SAML AWS 2.0 を設定する手順に従って、 で直接 IAM フェデレーションを設定します。 [AWS](https://saml-doc.okta.com/SAML_Docs/How-to-Configure-SAML-2.0-for-Amazon-Web-Service.html)リージョンの障害シナリオに対処するには、サインインエンドポイントを設定するときに、フェデレーションの耐障害性を向上させるために、運用しているすべてのリージョンで非リージョンエンドポイントと複数のリージョンエンドポイントの両方を有効にすることをお勧めします。この緊急アクセス用に ACS URL を設定するときは、IAM Identity Center がデプロイされているリージョンとは異なるリージョンのリージョンエンドポイントを使用することをお勧めします。リージョンエンドポイントのリストについては、*AWS 「 全般のリファレンス*」の[https://docs.aws.amazon.com/general/latest/gr/signin-service.html](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)「サインインエンドポイント」を参照してください。 1. **[サインオンオプション]** タブで [SAML 2.0] を選択し、**[グループフィルター]** と **[ロール値パターン]** の設定を入力します。ユーザーディレクトリのグループ名は、設定するフィルターによって異なります。 ![\[2 つのオプション: グループフィルターまたはロール値パターンのアカウント ID とロール。\]](http://docs.aws.amazon.com/ja_jp/singlesignon/latest/userguide/images/emergency-access-group-filter-role-value-pattern.png) 上の図では、`role` 変数は緊急アクセスアカウントの緊急運用のロール用です。たとえば、 で`EmergencyAccess_Role1_RO`ロール (マッピングテーブルで説明) を作成し AWS アカウント `123456789012`、グループフィルター設定が上の図に示すように設定されている場合、グループ名は になります`aws#EmergencyAccess_Role1_RO#123456789012`。 1. ディレクトリ (Active Directory 内のディレクトリなど) に緊急アクセスグループを作成し、ディレクトリの名前 (例:`aws#EmergencyAccess_Role1_RO#123456789012`) を指定します。既存のプロビジョニングメカニズムを使用して、ユーザーをこのグループに割り当てます。 1. 緊急アクセスアカウントで、中断中に緊急アクセスの役割を引き受けるのに必要なアクセス許可を提供する[カスタム信頼ポリシーを設定](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html)します。`EmergencyAccess_Role1_RO` ロールに添付されているカスタム **信頼ポリシー** のステートメントの例を以下に示します。図については、[緊急時のロール、アカウント、グループのマッピングを設計する方法](emergency-access-mapping-design.md) の図の緊急アカウントを参照してください。サンプルの SAML プロバイダー ARN を、緊急アクセスアカウントで作成した正しいものに置き換えます。例のリージョンエンドポイントを、選択したリージョンに置き換えます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect":"Allow", "Principal":{ "Federated":"arn:aws:iam::123456789012:saml-provider/[SAML PROVIDER NAME]" }, "Action":[ "sts:AssumeRoleWithSAML", "sts:TagSession" ], "Condition":{ "StringEquals":{ "SAML:aud": [ "https://signin.aws.amazon.com/saml", "https://us-west-2.signin.aws.amazon.com/saml", "https://us-west-1.signin.aws.amazon.com/saml", "https://us-east-2.signin.aws.amazon.com/saml" ] } } }, { "Effect":"Allow", "Principal":{ "Federated":"arn:aws:iam::123456789012:saml-provider/Okta" }, "Action":"sts:SetSourceIdentity" } ] } ``` ------ 1. 以下は、`EmergencyAccess_Role1_RO`ロールに適用されているアクセス **権限ポリシー** のステートメントの例です。図については、[緊急時のロール、アカウント、グループのマッピングを設計する方法](emergency-access-mapping-design.md) の図の緊急アカウントを参照してください。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::111122223333:role/EmergencyAccess_RO", "arn:aws:iam::444455556666:role/EmergencyAccess_RO" ] } ] } ``` ------ 1. ワークロードアカウントで、カスタム信頼ポリシーを設定します。`EmergencyAccess_RO` ロールに添付されている **信頼ポリシー** のステートメントの例を以下に示します。この例では、アカウント `123456789012` は緊急アクセスアカウントです。図については、[緊急時のロール、アカウント、グループのマッピングを設計する方法](emergency-access-mapping-design.md)の図の「ワークロードアカウント」を参照してください。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Principal":{ "AWS":"arn:aws:iam::123456789012:root" }, "Action":"sts:AssumeRole" } ] } ``` ------ **注記** ほとんどの IdPs では、必要になるまでアプリケーション統合を無効にしておくことができます。緊急アクセスが必要となるまで、IdP のダイレクト IAM フェデレーションアプリケーションを無効にしたままにしておくことをお勧めします。