@@ -8,11 +8,11 @@
### アカウント
AWS には **ルートアカウント ** があり、これは **組織内のすべてのアカウントの親コンテナ ** です。しかし、そのアカウントを使用してリソースをデプロイする必要はなく、**異なる AWS** インフラストラクチャを分離するために **他のアカウントを作成する ** ことが できます。
AWS には **ルートアカウント ** があり、これは **組織内のすべてのアカウントの親コンテナ ** です。しかし、そのアカウントを使用してリソースをデプロイする必要はなく、**異なる AWS** インフラストラクチャを分離するために **他のアカウントを作成 ** できます。
これは **セキュリティ ** の観点から非常に興味深いことであり、**1つのアカウントは他のアカウントのリソースにアクセスできません**（特別にブリッジが作成されている場合を除く ）。このようにして、デプロイメント間に境界を作成できます。
これは **セキュリティ ** の観点から非常に興味深いことであり、**1つのアカウントは他のアカウントのリソースにアクセスできません**（特別にブリッジが作成されていない限り ）。このようにして、デプロイメント間に境界を作成できます。
したがって、** 組織内には2種類のアカウントがあります** （ ） ：
したがって、組織内には ** 2種類のアカウント** があります（ ） ：
- **管理アカウント（ルートアカウント）** は、組織を作成するために使用するアカウントです。組織の管理アカウントから、次のことができます：
@@ -22,12 +22,12 @@ AWS には **ルートアカウント** があり、これは **組織内のす
- 招待状を管理する
- 組織内のエンティティ（ ）
- 組織内のすべてのアカウントにサービス機能を提供するために、サポートされている AWS サービスとの統合を有効にする。
- このルートアカウント/組織を作成するために使用され たメールアドレスとパスワードを使用して、ルートユーザーとしてログインすることが可能です。
- このルートアカウント/組織を作成するために使用し たメールアドレスとパスワードを使用して、ルートユーザーとしてログインすることが可能です。
管理アカウントは **支払いアカウントの責任 ** を持ち、メンバーアカウントによって発生したすべての料金を支払う責任があります。組織の管理アカウントを変更することはできません。
- **メンバーアカウント** は、組織内の残りのすべてのアカウントを構成します。アカウントは、一度に1つの組織のメンバーであることができます。アカウントにポリシーを添付して、そのアカウントのみに制御を適用することが できます。
- メンバーアカウントは **有効なメールアドレスを使用する必要があります ** そして を持つことができます。一般的に、請求を管理することはできません（ただし、アクセスが与えられる場合があります）。
- **メンバーアカウント** は、組織内の残りのすべてのアカウントを構成します。アカウントは、一度に1つの組織のメンバーであることができます。アカウントにポリシーを添付して、そのアカウントのみに制御を適用できます。
- メンバーアカウントは **有効なメールアドレスを使用する必要があり ** 、 **名前** を持つことができます。一般的に、請求を管理することはできません（ただし、アクセスが与えられる場合があります）。
```
```
@@ -42,11 +42,11 @@ aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
**サービスコントロールポリシー (SCP) ** は、SCPが影響を与えるアカウント内でユーザーとロールが使用できるサービスとアクションを指定するポリシーです。SCPは**IAM**権限ポリシーに似ていますが、**権限を付与することはありません**。代わりに、SCPは組織、組織単位 (OU)、またはアカウントの**最大権限**を指定します。SCPを組織のルートまたはOUにアタッチすると、**メンバーアカウント内のエンティティの権限が制限されます**。
これは**ルートユーザーでさえ何かを行う のを止める唯一の方法**です。たと えば、CloudTrailを無効にしたり、バックアップを削除したりするのを防ぐ ために使用できます。\
これは**ルートユーザーでさえ何かをする のを止める唯一の方法**です。例 えば、CloudTrailを無効にしたり、バックアップを削除したりするのを止める ために使用できます。\
これを回避する唯一の方法は、SCPを設定する**マスターアカウント**も侵害することです（マスターアカウントはブロックできません）。
> [!WARNING]
> **SCPはアカウント内のプリンシパルのみを制限する** ため、他のアカウントには影響しません。これは、SCPが` s3:GetObject`を拒否しても、あなたのアカウント内の**公開S3バケットにアクセスする人々 を止めることはない**ことを意味します。
> **SCPはアカウント内のプリンシパルのみを制限** するため、他のアカウントには影響しません。これは、SCPが`s3:GetObject`を拒否しても、あなたのアカウント内の**公開S3バケットにアクセスする人を止めることはでき ない**ことを意味します。
SCPの例：
@@ -60,18 +60,18 @@ SCPの例：
変更を拒否。
- バックアップの削除を拒否。
- IAMユーザーとアクセスキーの作成を拒否
- IAMユーザーとアクセスキーの作成を拒否。
**JSONの例**は[https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html ](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html )で見つけてください。
### Resource Control Policy (RCP)
**リソースコントロールポリシー (RCP) ** は、**AWS組織内のリソースに対する最大権限を定義するポリシー**です。RCPは構文が IAMポリシーに似ていますが、**権限を付与しません**—他のポリシーによってリソースに適用できる権限を制限するだけです。RCPを組織のルート、組織単位 (OU)、またはアカウントにアタッチすると、RCPは影響を受ける範囲内のすべてのリソースに対するリソース権限を制限します。
**リソースコントロールポリシー (RCP) ** は、**AWS組織内のリソースに対する最大権限を定義するポリシー**です。RCPは構文において IAMポリシーに似ていますが、**権限を付与しません**—他のポリシーによってリソースに適用できる権限を制限するだけです。RCPを組織のルート、組織単位 (OU)、またはアカウントにアタッチすると、RCPは影響を受ける範囲内のすべてのリソースに対するリソース権限を制限します。
これは**リソースが事前定義されたアクセスレベルを超えないことを保証する唯一の方法**です—たとえ アイデンティティベースまたはリソースベースのポリシーが過剰に許可されていて も。これらの制限を回避する唯一の方法は、組織の管理アカウントによって設定されたRCPを変更することです。
これは**リソースが事前定義されたアクセスレベルを超えないことを保証する唯一の方法**です—アイデンティティベースまたはリソースベースのポリシーが過剰に許可されている場合で も。これらの制限を回避する唯一の方法は、組織の管理アカウントによって設定されたRCPを変更することです。
> [!WARNING]
> RCPはリソースが持つことができる権限のみを制限します。プリンシパルが何をできるかを直接制御するわけではありません。たと えば、RCPがS3バケットへの外部アクセスを拒否する場合、それはバケットの権限が設定された制限を超えるアクションを許可しないことを保証します—たとえ リソースベースのポリシーが誤って設定されていても。
> RCPはリソースが持つことができる権限のみを制限します。プリンシパルが何をできるかを直接制御するわけではありません。例 えば、RCPがS3バケットへの外部アクセスを拒否する場合、それはバケットの権限が設定された制限を超えるアクションを許可しないことを保証します—リソースベースのポリシーが誤って設定されていても。
RCPの例：
@@ -98,17 +98,17 @@ arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env
## IAM - アイデンティティとアクセス管理
IAMは、AWSアカウント内で**認証**、**認可 **、および**アクセス制御**を管理することを可能にするサービスです。
IAMは、AWSアカウント内で**認証**、**承 認**、および**アクセス制御**を管理することを可能にするサービスです。
- **認証** - アイデンティティを定義し、そのアイデンティティを検証するプロセス。このプロセスは、識別と検証に細分化できます。
- **認可 ** - アイデンティティがシステム内でアクセスできるものを決定します。
- **承 認** - アイデンティティがシステム内でアクセスできるものを決定します。
- **アクセス制御** - セキュアなリソースへのアクセスがどのように付与されるかの方法とプロセス
IAMは、AWSアカウント内のリソースに対するアイデンティティの認証、認可 、およびアクセス制御メカニズムを管理、制御、統治する能力によって定義されます。
IAMは、AWSアカウント内のリソースに対するアイデンティティの認証、承 認、およびアクセス制御メカニズムを管理、制御、統治する能力によって定義されます。
### [AWSアカウントのルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) <a href="#id_root" id="id_root"></a>
Amazon Web Services (AWS) アカウントを最初に作成すると、** すべての** AWSサービスとリソースに**完全にアクセスできる**単一のサインインアイデンティティが与えられます。これがAWSアカウントの_**ルートユーザー**_であり、**アカウントを作成する際に使用したメールアドレスとパスワードでサインインすることでアクセスします**。
Amazon Web Services (AWS) アカウントを最初に作成すると、アカウント内の すべてのAWSサービスとリソースに**完全にアクセスできる**単一のサインインアイデンティティが与えられます。これがAWSアカウントの_**ルートユーザー**_であり、**アカウントを作成する際に使用したメールアドレスとパスワードでサインインすることでアクセスします**。
新しい**管理者ユーザー**は**ルートユーザーよりも権限が少ない**ことに注意してください。
@@ -116,11 +116,11 @@ Amazon Web Services (AWS) アカウントを最初に作成すると、**すべ
### [IAMユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
IAM _ユーザー_ は、AWS内で**その 人またはアプリケーション**を**AWSと対話させるために使用する** エンティティです。AWSのユーザーは、名前と資格情報（ ）
IAM _ ユーザー _ を表す**ために作成する エンティティです。AWSのユーザーは、名前と資格情報（ ）
IAMユーザーを作成すると、適切な権限ポリシーが添付された**ユーザーグループのメンバー**にすることで**権限**を付与するか、**ポリシーを直接ユーザーに添付**し ます。
IAMユーザーを作成すると、適切な権限ポリシーが添付された**ユーザーグループのメンバー**にすることで**権限**を付与するか、**ポリシーを直接ユーザーに添付**することができ ます。
ユーザーは、コンソールを通じて**MFAを有効にしてログイン**できます。MFAが有効なユーザーのAPIトークンはMFAによって保護されていません。**MFAを使用して ユーザーのAPIキーのアクセスを制限** したい場合は、特定のアクションを実行するためにMFAが必要であることをポリシーに示す必要があります（ ： **こちら** ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html )）。
ユーザーは、コンソールを通じて**MFAを有効にしてログイン**できます。MFAが有効なユーザーのAPIトークンはMFAによって保護されていません。ユーザーのAPIキーのアクセスをMFAを使用して** 制限したい場合** は、特定のアクションを実行するためにMFAが必要であることをポリシーに示す必要があります（ [**こちら** ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html )）。
#### CLI
@@ -135,7 +135,7 @@ _新しいアクセスキーを作成 -> 新しいキーをシステム/アプ
これは、既存の方法（パスワードなど）に加えて**認証のための追加の要素を作成する**ために使用され、マルチファクターレベルの認証を作成します。\
**無料の仮想アプリケーションまたは物理デバイス**を使用できます。Google認証などのアプリを無料で使用してAWSでMFAを有効にできます。
MFA条件を持つポリシーは、以下 に添付できます：
MFA条件を持つポリシーは、次のもの に添付できます：
- IAMユーザーまたはグループ
- Amazon S3バケット、Amazon SQSキュー、またはAmazon SNSトピックなどのリソース
@@ -150,7 +150,7 @@ aws sts get-session-token --serial-number <arn_device> --token-code <code>
### [IAMユーザーグループ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
IAM [ユーザーグループ ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html )は、**複数のユーザーにポリシーを一度に適用する**方法であり、これによりそれらの ユーザーの権限を管理しやすくなります。**ロールとグループはグループの一部にはなれません**。
IAM [ユーザーグループ ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html )は、**複数のユーザーにポリシーを一度に適用する**方法であり、これによりユーザーの権限を管理しやすくなります。**ロールとグループはグループの一部にはなれません**。
**ユーザーグループにアイデンティティベースのポリシーを適用する**ことで、ユーザーグループ内のすべての**ユーザー**が**ポリシーの権限を受け取る**ことができます。**ユーザーグループ**を**ポリシー ** （リソースベースのポリシーなど）内の**`Principal` **として特定することは**できません**。なぜなら、グループは権限に関連し、認証には関連しないため、プリンシパルは認証されたIAMエンティティだからです。
@@ -158,12 +158,12 @@ IAM [ユーザーグループ](https://docs.aws.amazon.com/IAM/latest/UserGuide/
- ユーザー**グループ**は**多くのユーザーを含むことができ**、**ユーザー**は**複数のグループに属することができ**ます。
- **ユーザーグループはネストできません**。ユーザーのみを含むことができ、他のユーザーグループは含められません。
- **AWSアカウント内のすべてのユーザーを自動的に含むデフォルトのユーザーグループはあり ません**。そのようなユーザーグループを持ち たい場合は、自分で作成し、新しいユーザーをそれに割り当てる必要があります。
- **AWSアカウント内のすべてのユーザーを自動的に含むデフォルトのユーザーグループは存在し ません**。そのようなユーザーグループを作成し たい場合は、自分で作成し、新しいユーザーをそれに割り当てる必要があります。
- AWSアカウント内のIAMリソースの数とサイズ（ ） IAMおよびAWS STSのクォータ ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html )を参照してください。
### [IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
IAM **ロール**は**ユーザー**に 非常に**似ており ** 、AWS内で**何ができるかを決定する権限ポリシーを持つアイデンティティ**です。しかし、ロールには**関連付けられた資格情報**（パスワードやアクセスキー）が **ありません**。ロールは特定の人に一意に関連付けられるのではなく、**必要な人が誰でも引き受けられることを意図しています（十分な権限がある場合）**。IAMユーザーは、特定のタスクのために異なる権限を一時的に取得するためにロールを**引き受け ることができます** 。ロールは、IAMではなく外部アイデンティティプロバイダーを使用してサインインする[**フェデレーテッドユーザー** ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html )に**割り当てることができます**。
IAM **ロール**は、 **ユーザー**と 非常に**似ており ** 、AWS内で**何ができるかを決定する権限ポリシーを持つアイデンティティ**です。しかし、ロールには**関連付けられた資格情報**（パスワードやアクセスキー）は **ありません**。ロールは特定の人に一意に関連付けられるのではなく、**必要な人が誰でも引き受けられることを意図しています（十分な権限がある場合）**。** IAMユーザーはロールを引き受けて、一時的に**特定のタスクのために異なる権限を取得す ることができます。ロールは、IAMではなく外部アイデンティティプロバイダーを使用してサインインする[**フェデレーテッドユーザー** ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html )に**割り当てることができます**。
IAMロールは、**2種類のポリシー**で構成されています：**信頼ポリシー**（空であってはならず、**誰がロールを引き受けることができるかを定義**）と、**権限ポリシー**（空であってはならず、**何にアクセスできるかを定義**）。
@@ -173,7 +173,7 @@ AWSセキュリティトークンサービス（ ）
### [IAMにおける一時的な資格情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
**一時的な資格情報は主にIAMロールと共に使用されます**が、他の用途もあります。標準のIAMユーザーよりも制限された権限セット を持つ一時的な資格情報をリクエストできます。これにより、**制限された資格情報によって許可されていないタスクを誤って実行することを防ぎます ** 。一時的な資格情報の利点は、設定された期間が経過すると自動的に期限切れになることです。資格情報が有効な期間を制御できます。
**一時的な資格情報は主にIAMロールと共に使用されます**が、他の用途もあります。標準のIAMユーザーよりも制限された権限を持つ一時的な資格情報をリクエストできます。これにより、**制限された資格情報によって許可されていないタスクを誤って実行することを防ぎます ** 。一時的な資格情報の利点は、設定された期間が経過すると自動的に期限切れになることです。資格情報が有効な期間を制御できます。
### ポリシー
@@ -182,9 +182,9 @@ AWSセキュリティトークンサービス（ ）
権限を割り当てるために使用されます。2種類あります：
- AWS管理ポリシー（ ）
- カスタマー管理ポリシー： （ 分 のものを作成する） （ ） 書く ことができます。
- カスタマー管理ポリシー： （ 独 自のものを作成する） （ ） 作成する ことができます。
**デフォルトのアクセスは ** されます ** 。
**デフォルトのアクセスは ** **拒否**され、 明示的なロールが指定された場合にのみアクセスが許可されます。\
**単一の「拒否」が存在する場合、それは「許可」を上書きします ** 。AWSアカウントのルートセキュリティ資格情報を使用するリクエスト（ ）
``` javascript
{
@@ -213,20 +213,20 @@ AWSセキュリティトークンサービス（ ）
#### インラインポリシー
この種のポリシーは、**ユーザー、グループ、またはロールに直接割り当てられます**。そのため、他の誰かが 使用できるようにポリシーリストには表示されません。\
この種のポリシーは、**ユーザー、グループ、またはロールに直接割り当てられます**。そのため、他の誰も 使用できるようには ポリシーリストには表示されません。\
インラインポリシーは、**ポリシーと適用されるアイデンティティとの間に厳密な1対1の関係を維持したい場合**に便利です。たとえば、ポリシー内の権限が意図されたアイデンティティ以外に誤って割り当てられないことを確認したい場合です。インラインポリシーを使用すると、ポリシー内の権限が誤って間違ったアイデンティティに添付されることはありません。さらに、AWS Management Consoleを使用してそのアイデンティティを削除すると、アイデンティティに埋め込まれたポリシーも削除されます。これは、それらが主エンティティの一部であるためです。
#### リソースバケットポリシー
これらは、**リソース内で 定義できるポリシー**です。**すべてのAWSリソースがそれをサポートしているわけではありません**。
これらは、**リソース**に 定義できる** ポリシー**です。**すべてのAWSリソースがそれをサポートしているわけではありません**。
もしプリンシパルがそれに対して明示的な拒否を持っておらず、リソースポリシーがアクセスを許可している場合、彼らは許可されます。
### IAMバウンダリー
IAMバウンダリーは、**ユーザーまたはロールがアクセスすべき権限を制限するために使用できます**。このように、異なるポリシーによってユーザーに異なる権限が付与されても、操作は**失敗**します。
IAMバウンダリーは、**ユーザーまたはロールがアクセスすべき権限を制限するために使用できます**。このように、異なるポリシーによってユーザーに異なる権限が付与されても、使用しようとすると 操作は**失敗**します。
バウンダリーは、ユーザーに添付されたポリシーであり、**ユーザーまたはロールが持つことができる最大の権限レベルを示します**。したがって、**ユーザーが管理者アクセスを持っていても**、バウンダリーが彼が S·バケットを読むことしかできないと 示している場合、それが彼ができる最大のことです。
バウンダリーは、ユーザーに添付されたポリシーであり、**ユーザーまたはロールが持つことができる最大の権限レベルを示します**。したがって、**ユーザーが管理者アクセスを持っていても**、バウンダリーが彼に S·バケットのみを読み取ることを 示している場合、それが彼ができる最大のことです。
**これ ** 、**SCP**、および**最小特権の原則に従うこと**は、ユーザーが必要以上の権限を持たないように制御する方法です。
@@ -242,18 +242,18 @@ aws sts assume-role \
[ --policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[ --policy <file://policy.json>]
```
注意すべきは、デフォルトで**AWSはセッションの生成 にセッションポリシーを追加する可能性がある**ということです。例えば、[認証されていないCognitoの仮定ロール ](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles )では、デフォルト（強化された認証を使用）で 、AWSは**セッションポリシーを持つセッション資格情報**を生成し、そのセッションがアクセスできるサービスを[**以下 のリストに制限します** ](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services )。
注意すべきは、デフォルトで**AWSはセッションにセッションポリシーを追加する可能性がある**ということです。これは、第三者の理由によって生成されるセッションに対してです。 例えば、[認証されていないCognitoの仮定された ロール ](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles )では、デフォルトで （強化された認証を使用して ） **次 のリストに制限します** ](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services )。
したがって、ある時点で「...セッションポリシーが許可していないため... 」という エラーに直面した場合、ロールがアクションを実行するアクセス権を持っていても、**それを妨げるセッションポリシーが存在する**ためです。
したがって、ある時点で「...セッションポリシーが...を 許可していないため」といった エラーに直面した場合、ロールがその アクションを実行するアクセス権を持っていても、**それを妨げるセッションポリシーが存在する**ためです。
### アイデンティティフェデレーション
アイデンティティフェデレーションは、**AWSに外部のアイデンティティプロバイダーからのユーザーが**AWSリソースに安全にアクセスできるようにし、AWSユーザーアカウントの 有効なIAMユーザー資格情報を 提供する必要がありません。\
アイデンティティフェデレーションは、**AWSに外部のアイデンティティプロバイダーからのユーザーが**AWSリソースに安全にアクセスできるようにし、AWSユーザー資格情報を 有効なIAMユーザーアカウントから 提供する必要がありません。\
アイデンティティプロバイダーの例としては、独自の企業の**Microsoft Active Directory**（ ）
この信頼を構成するために、**他のプラットフォームを信頼する IAMアイデンティティプロバイダー（ ） ます**。次に 、少なくとも1つの**IAMロールがアイデンティティプロバイダーに（ ）
この信頼を構成するために、**IAMアイデンティティプロバイダー（ ） **、**他のプラットフォームを信頼する**ことになります。そして 、少なくとも1つの**IAMロールがアイデンティティプロバイダーに（ ）
ただし、通常は**サードパーティプラットフォームのユーザーのグループに応じて異なるロールを与えたい**と思うでしょう。そのため、複数の**IAMロールがサードパーティのアイデンティティプロバイダーを信頼し、サードパーティプラットフォームがユーザーにどちら のロールを引き受けるかを許可します** 。
ただし、通常は**サードパーティプラットフォームのユーザーのグループに応じて異なるロールを与えたい**と思うでしょう。そのため、複数の**IAMロールがサードパーティのアイデンティティプロバイダーを信頼し** 、サードパーティプラットフォームがユーザーにどのロールを引き受けるかを許可します。
<figure><img src="../../../images/image (247).png" alt=""><figcaption></figcaption></figure>
@@ -271,20 +271,20 @@ AWS IAMアイデンティティセンター（
<figure><img src="../../../images/image (279).png" alt=""><figcaption></figcaption></figure>
アイデンティティセンターディレクトリの最も単純なケースでは、**アイデンティティセンターはユーザーとグループのリストを持ち**、それらに**ポリシーを割り当てることができます**。 **組織の任意のアカウント**に対して。
アイデンティティセンターディレクトリの最も単純なケースでは、**アイデンティティセンターはユーザーとグループのリストを持ち**、それらに**ポリシーを割り当てる** ことができ、 **組織の任意のアカウント**に対して行います 。
アイデンティティセンターのユーザー/グループにアカウントへのアクセスを与えるために、**アイデンティティセンターを信頼するSAMLアイデンティティプロバイダーが作成され**、**指定されたポリシーを持つアイデンティティプロバイダーを信頼するロールが宛先アカウントに作成されます**。
#### AwsSSOInlinePolicy
**IAMアイデンティティセンターを介して作成されたロールにインラインポリシーを介し て権限を与えることが可能です ** 。AWSアイデンティティセンターでインラインポリシーを持つアカウントで作成されたロールは、**`AwsSSOInlinePolicy` **というインラインポリシーにこれらの権限を持ちます。
**IAMアイデンティティセンターを介して作成されたロールにインラインポリシーを通じ て権限を与えることが可能です ** 。AWSアイデンティティセンターでインラインポリシーを持つアカウントで作成されたロールは、**`AwsSSOInlinePolicy` **というインラインポリシーにこれらの権限を持ちます。
したがって、**`AwsSSOInlinePolicy` **というインラインポリシーを持つ2つのロールが表示され ても、**同じ権限を持っているわけではありません**。
したがって、**`AwsSSOInlinePolicy` **というインラインポリシーを持つ2つのロールがあっ ても、**同じ権限を持っているわけではありません**。
### クロスアカウントの信頼とロール
**ユーザー ** （信頼する側）は、いくつかのポリシーを持つクロスアカウントロールを作成し、**別のユーザー**（信頼される側）に**自分のアカウントにアクセスを許可する**が、**新しいロールポリシーで示されたアクセスのみを持つ**ことができ ます。これを作成するには、新しいロールを作成し、クロスアカウントロールを選択します。クロスアカウントアクセス用のロールは2つのオプションを提供します。所有するAWSアカウント間でのアクセスを提供することと、所有するアカウントとサードパーティのAWSアカウント間でのアクセスを提供することです。\
信頼されるユーザーを**特定し、一般的なものを指定しないことをお勧めします**。そうしないと、フェデレーテッドユーザーなど の他の認証されたユーザーもこの信頼を悪用できる可能性があります。
**ユーザー ** （信頼する側）は、いくつかのポリシーを持つクロスアカウントロールを作成し、**別のユーザー**（信頼される側）に**自分のアカウントにアクセスを許可する**ことができます が、**新しいロールポリシーで示されたアクセスのみを持つ**ことになり ます。これを作成するには、新しいロールを作成し、クロスアカウントロールを選択します。クロスアカウントアクセス用のロールは2つのオプションを提供します。所有するAWSアカウント間でのアクセスを提供することと、所有するアカウントとサードパーティのAWSアカウント間でのアクセスを提供することです。\
信頼されるユーザーを**特定し、一般的なものを指定しないことをお勧めします**。そうしないと、フェデレーテッドユーザーのような 他の認証されたユーザーもこの信頼を悪用できる可能性があります。
### AWS Simple AD
@@ -307,7 +307,7 @@ AWS IAMアイデンティティセンター（
- **パスワードポリシー設定**を設定することができ、最小長やパスワード要件などのオプションがあります。
- **「資格情報レポート」をダウンロード**して、現在の資格情報に関する情報（ユーザー作成時間、パスワードが有効かどうかなど）を取得できます。資格情報レポートは、最長で**4時間ごと**に生成できます。
AWSアイデンティティおよびアクセス管理（ ）
AWSアイデンティティおよびアクセス管理（ ） そして どの条件下でアクセスできるかを指定できます**。IAMポリシーを使用して、労働力やシステムへの権限を管理し、**最小権限の権限を確保します**。
### IAM IDプレフィックス
@@ -346,8 +346,8 @@ AWSアイデンティティおよびアクセス管理（ ）
### CLI認証
通常のユーザーがCLIを介してAWSに認証するためには、**ローカル資格情報**が必要です。デフォルトでは、`~/.aws/credentials` に**手動で**設定するか、**`aws configure` を実行することで **構成できます。\
そのファイルには、1つ以上のプロファイルを持つことができ、**プロファイル**が指定されていない場合、**そのファイルの `[default]` **と呼ばれるものが使用されます。\
通常のユーザーがCLIを介してAWSに認証するためには、**ローカル資格情報**が必要です。デフォルトでは、`~/.aws/credentials` に**手動で**設定するか、**`aws configure` を実行することによって **構成できます。\
そのファイルには、1つ以上のプロファイルを持つことができ、**プロファイル**が指定されていない場合、**aws cli**を使用すると、 そのファイル内の** `[default]` **と呼ばれるものが使用されます。\
複数のプロファイルを持つ資格情報ファイルの例：
```
@@ -371,7 +371,7 @@ role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional
```
この設定ファイルを使用すると、aws cliを次のように 使用できます:
この設定ファイルを使用すると、次のように aws cliを使用できます:
```
```
@@ -384,7 +384,7 @@ aws --profile acc2 ...
[ victim ]
credential_process = curl -d 'PAYLOAD' https : / / some-site . com
```
注意してください、資格情報は次の形式でSTDOUTに返される必要があります：
注意してください、資格情報は次の形式でSTDOUTに返されなければなりません:
``` json
{
"Version" : 1 ,
Translator