mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-29 06:03:26 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA
This commit is contained in:
Translator
@@ -12,14 +12,14 @@ AWS には **ルートアカウント** があり、これは **組織内のす
|
||||
|
||||
これは **セキュリティ** の観点から非常に興味深いことであり、**1つのアカウントは他のアカウントのリソースにアクセスできません**（特別にブリッジが作成されている場合を除く）。このようにして、デプロイメント間に境界を作成できます。
|
||||
|
||||
したがって、組織内には **2種類のアカウント** があります（AWS アカウントについて話しており、ユーザーアカウントではありません）：管理アカウントとして指定された単一のアカウントと、1つ以上のメンバーアカウントです。
|
||||
したがって、**組織内には2種類のアカウントがあります**（AWS アカウントについて話しており、ユーザーアカウントではありません）：管理アカウントとして指定された単一のアカウントと、1つ以上のメンバーアカウントです。
|
||||
|
||||
- **管理アカウント（ルートアカウント）** は、組織を作成するために使用するアカウントです。組織の管理アカウントから、次のことができます：
|
||||
|
||||
- 組織内にアカウントを作成する
|
||||
- 他の既存のアカウントを組織に招待する
|
||||
- 組織からアカウントを削除する
|
||||
- 招待を管理する
|
||||
- 招待状を管理する
|
||||
- 組織内のエンティティ（ルート、OU、またはアカウント）にポリシーを適用する
|
||||
- 組織内のすべてのアカウントにサービス機能を提供するために、サポートされている AWS サービスとの統合を有効にする。
|
||||
- このルートアカウント/組織を作成するために使用されたメールアドレスとパスワードを使用して、ルートユーザーとしてログインすることが可能です。
|
||||
@@ -40,13 +40,13 @@ aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
|
||||
```
|
||||
### Service Control Policy (SCP)
|
||||
|
||||
**サービスコントロールポリシー (SCP)** は、SCPが影響を与えるアカウント内でユーザーとロールが使用できるサービスとアクションを指定するポリシーです。SCPは**IAM**権限ポリシーに**似ていますが、権限を付与することはありません**。代わりに、SCPは組織、組織単位 (OU)、またはアカウントの**最大権限**を指定します。SCPを組織のルートまたはOUにアタッチすると、**メンバーアカウント内のエンティティの権限が制限されます**。
|
||||
**サービスコントロールポリシー (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を変更することです。
|
||||
|
||||
> [!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,18 +116,18 @@ 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のユーザーは、名前と資格情報（パスワードと最大2つのアクセスキー）で構成されます。
|
||||
IAM _ユーザー_は、AWS内で**その人またはアプリケーション**を**AWSと対話させるために使用する**エンティティです。AWSのユーザーは、名前と資格情報（パスワードと最大2つのアクセスキー）で構成されます。
|
||||
|
||||
IAMユーザーを作成すると、適切な権限ポリシーが添付された**ユーザーグループのメンバー**にすることで**権限**を付与するか、**ポリシーをユーザーに直接添付**することができます。
|
||||
IAMユーザーを作成すると、適切な権限ポリシーが添付された**ユーザーグループのメンバー**にすることで**権限**を付与するか、**ポリシーを直接ユーザーに添付**します。
|
||||
|
||||
ユーザーは、コンソールを通じて**MFAを有効にしてログイン**できます。MFAが有効なユーザーのAPIトークンはMFAによって保護されていません。ユーザーのAPIキーのアクセスをMFAを使用して**制限したい場合**は、特定のアクションを実行するためにMFAが必要であることをポリシーに示す必要があります（例 [**こちら**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)）。
|
||||
ユーザーは、コンソールを通じて**MFAを有効にしてログイン**できます。MFAが有効なユーザーのAPIトークンはMFAによって保護されていません。**MFAを使用してユーザーのAPIキーのアクセスを制限**したい場合は、特定のアクションを実行するためにMFAが必要であることをポリシーに示す必要があります（例：[**こちら**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)）。
|
||||
|
||||
#### CLI
|
||||
|
||||
- **アクセスキーID**: 20のランダムな大文字の英数字の文字列（例：AKHDNAPO86BSHKDIRYT）
|
||||
- **シークレットアクセスキーID**: 40のランダムな大文字と小文字の文字列（例：S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU）（失われたシークレットアクセスキーIDを取得することはできません）。
|
||||
|
||||
**アクセスキーを変更する必要がある場合**は、次のプロセスに従ってください：\
|
||||
**アクセスキーを変更する必要がある場合**は、次のプロセスに従う必要があります：\
|
||||
_新しいアクセスキーを作成 -> 新しいキーをシステム/アプリケーションに適用 -> 元のキーを非アクティブとしてマーク -> 新しいアクセスキーが機能していることをテストおよび確認 -> 古いアクセスキーを削除_
|
||||
|
||||
### MFA - 多要素認証
|
||||
@@ -142,7 +142,7 @@ MFA条件を持つポリシーは、以下に添付できます：
|
||||
- ユーザーによって引き受けられるIAMロールの信頼ポリシー
|
||||
|
||||
**CLIを介して**MFAを**チェックする**リソースにアクセスしたい場合は、**`GetSessionToken`**を呼び出す必要があります。これにより、MFAに関する情報を含むトークンが得られます。\
|
||||
**`AssumeRole`の資格情報にはこの情報は含まれていない**ことに注意してください。
|
||||
**`AssumeRole`の資格情報にはこの情報が含まれていない**ことに注意してください。
|
||||
```bash
|
||||
aws sts get-session-token --serial-number <arn_device> --token-code <code>
|
||||
```
|
||||
@@ -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,8 +158,8 @@ IAM [ユーザーグループ](https://docs.aws.amazon.com/IAM/latest/UserGuide/
|
||||
|
||||
- ユーザー**グループ**は**多くのユーザーを含むことができ**、**ユーザー**は**複数のグループに属することができ**ます。
|
||||
- **ユーザーグループはネストできません**。ユーザーのみを含むことができ、他のユーザーグループは含められません。
|
||||
- **AWSアカウント内のすべてのユーザーを自動的に含むデフォルトのユーザーグループは存在しません**。そのようなユーザーグループを作成したい場合は、自分で作成し、新しいユーザーをそれに割り当てる必要があります。
|
||||
- AWSアカウント内のIAMリソースの数とサイズ（グループの数やユーザーがメンバーになれるグループの数など）は制限されています。詳細については、[IAMおよびAWS STSのクォータ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html)を参照してください。
|
||||
- **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>
|
||||
|
||||
@@ -182,10 +182,10 @@ AWSセキュリティトークンサービス（STS）は、**一時的で制限
|
||||
権限を割り当てるために使用されます。2種類あります：
|
||||
|
||||
- AWS管理ポリシー（AWSによって事前設定されたもの）
|
||||
- カスタマー管理ポリシー：あなたが設定したもの。AWS管理ポリシーに基づいてポリシーを作成できます（そのうちの1つを修正して独自のものを作成する）、ポリシージェネレーターを使用する（権限を付与および拒否するのを助けるGUIビュー）または自分で書くことができます。
|
||||
- カスタマー管理ポリシー：あなたが設定したもの。AWS管理ポリシーに基づいてポリシーを作成できます（そのうちの1つを修正して自分のものを作成する）、ポリシージェネレーターを使用する（権限を付与および拒否するのを助けるGUIビュー）または自分で書くことができます。
|
||||
|
||||
**デフォルトのアクセスは** **拒否**され、明示的なロールが指定された場合にのみアクセスが許可されます。\
|
||||
**単一の「拒否」が存在する場合、それは「許可」を上書きします**。ただし、AWSアカウントのルートセキュリティ資格情報を使用するリクエストは（デフォルトで許可されます）。
|
||||
**デフォルトのアクセスは** **拒否されます**。明示的なロールが指定された場合にのみアクセスが許可されます。\
|
||||
**単一の「拒否」が存在する場合、それは「許可」を上書きします**。AWSアカウントのルートセキュリティ資格情報を使用するリクエスト（デフォルトで許可されている）は除きます。
|
||||
```javascript
|
||||
{
|
||||
"Version": "2012-10-17", //Version of the policy
|
||||
@@ -208,17 +208,17 @@ AWSセキュリティトークンサービス（STS）は、**一時的で制限
|
||||
]
|
||||
}
|
||||
```
|
||||
[グローバルフィールドは、任意のサービスで条件に使用できるものがここに文書化されています](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount)。\
|
||||
[サービスごとに条件に使用できる特定のフィールドはここに文書化されています](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html)。
|
||||
[グローバルフィールドは、任意のサービスで条件に使用できることが文書化されています](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount)。\
|
||||
[特定のフィールドは、サービスごとに条件に使用できることが文書化されています](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html)。
|
||||
|
||||
#### インラインポリシー
|
||||
|
||||
この種のポリシーは**ユーザー、グループ、またはロールに直接割り当てられます**。そのため、他の誰も使用できるようにはポリシーリストに表示されません。\
|
||||
この種のポリシーは、**ユーザー、グループ、またはロールに直接割り当てられます**。そのため、他の誰かが使用できるようにポリシーリストには表示されません。\
|
||||
インラインポリシーは、**ポリシーと適用されるアイデンティティとの間に厳密な1対1の関係を維持したい場合**に便利です。たとえば、ポリシー内の権限が意図されたアイデンティティ以外に誤って割り当てられないことを確認したい場合です。インラインポリシーを使用すると、ポリシー内の権限が誤って間違ったアイデンティティに添付されることはありません。さらに、AWS Management Consoleを使用してそのアイデンティティを削除すると、アイデンティティに埋め込まれたポリシーも削除されます。これは、それらが主エンティティの一部であるためです。
|
||||
|
||||
#### リソースバケットポリシー
|
||||
|
||||
これらは**リソースに定義できるポリシー**です。**すべてのAWSリソースがそれをサポートしているわけではありません**。
|
||||
これらは、**リソース内で定義できるポリシー**です。**すべてのAWSリソースがそれをサポートしているわけではありません**。
|
||||
|
||||
もしプリンシパルがそれに対して明示的な拒否を持っておらず、リソースポリシーがアクセスを許可している場合、彼らは許可されます。
|
||||
|
||||
@@ -226,15 +226,15 @@ AWSセキュリティトークンサービス（STS）は、**一時的で制限
|
||||
|
||||
IAMバウンダリーは、**ユーザーまたはロールがアクセスすべき権限を制限するために使用できます**。このように、異なるポリシーによってユーザーに異なる権限が付与されても、操作は**失敗**します。
|
||||
|
||||
バウンダリーは、ユーザーに添付されたポリシーであり、**ユーザーまたはロールが持つことができる最大の権限レベルを示します**。したがって、**ユーザーが管理者アクセスを持っていても**、バウンダリーが彼にS·バケットのみを読み取ることを示している場合、それが彼ができる最大のことです。
|
||||
バウンダリーは、ユーザーに添付されたポリシーであり、**ユーザーまたはロールが持つことができる最大の権限レベルを示します**。したがって、**ユーザーが管理者アクセスを持っていても**、バウンダリーが彼がS·バケットを読むことしかできないと示している場合、それが彼ができる最大のことです。
|
||||
|
||||
**これ**、**SCP**および**最小特権の原則に従うこと**は、ユーザーが必要以上の権限を持たないように制御する方法です。
|
||||
**これ**、**SCP**、および**最小特権の原則に従うこと**は、ユーザーが必要以上の権限を持たないように制御する方法です。
|
||||
|
||||
### セッションポリシー
|
||||
|
||||
セッションポリシーは、**ロールが引き受けられたときに設定されるポリシー**です。これは、そのセッションの**IAMバウンダリーのようなもの**になります：これは、セッションポリシーが権限を付与するのではなく、**ポリシーに示された権限に制限することを意味します**（最大の権限はロールが持つものです）。
|
||||
|
||||
これは**セキュリティ対策**に役立ちます：管理者が非常に特権のあるロールを引き受ける際、セッションが侵害された場合に備えて、セッションポリシーに示された権限のみを制限することができます。
|
||||
これは**セキュリティ対策**に役立ちます：管理者が非常に特権のあるロールを引き受ける場合、セッションが侵害された場合に備えて、セッションポリシーに示された権限のみを制限することができます。
|
||||
```bash
|
||||
aws sts assume-role \
|
||||
--role-arn <value> \
|
||||
@@ -242,7 +242,7 @@ 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)では、デフォルト（強化された認証を使用）で、AWSは**セッションポリシーを持つセッション資格情報**を生成し、そのセッションがアクセスできるサービスを[**以下のリストに制限します**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services)。
|
||||
|
||||
したがって、ある時点で「...セッションポリシーが許可していないため...」というエラーに直面した場合、ロールがアクションを実行するアクセス権を持っていても、**それを妨げるセッションポリシーが存在する**ためです。
|
||||
|
||||
@@ -251,9 +251,9 @@ aws sts assume-role \
|
||||
アイデンティティフェデレーションは、**AWSに外部のアイデンティティプロバイダーからのユーザーが**AWSリソースに安全にアクセスできるようにし、AWSユーザーアカウントの有効なIAMユーザー資格情報を提供する必要がありません。\
|
||||
アイデンティティプロバイダーの例としては、独自の企業の**Microsoft Active Directory**（**SAML**経由）や**OpenID**サービス（**Google**など）があります。フェデレーテッドアクセスにより、その中のユーザーがAWSにアクセスできるようになります。
|
||||
|
||||
この信頼を構成するために、**IAMアイデンティティプロバイダー（SAMLまたはOAuth）が生成され**、**他のプラットフォームを信頼する**ことになります。そして、少なくとも1つの**IAMロールがアイデンティティプロバイダーに（信頼される）割り当てられます**。信頼されたプラットフォームのユーザーがAWSにアクセスすると、前述のロールとしてアクセスします。
|
||||
この信頼を構成するために、**他のプラットフォームを信頼するIAMアイデンティティプロバイダー（SAMLまたはOAuth）が生成されます**。次に、少なくとも1つの**IAMロールがアイデンティティプロバイダーに（信頼される）割り当てられます**。信頼されたプラットフォームのユーザーがAWSにアクセスすると、前述のロールとしてアクセスします。
|
||||
|
||||
ただし、通常は**サードパーティプラットフォームのユーザーのグループに応じて異なるロールを与えたい**と思うでしょう。そのため、複数の**IAMロールがサードパーティのアイデンティティプロバイダーを信頼し**、サードパーティプラットフォームがユーザーにどのロールを引き受けるかを許可します。
|
||||
ただし、通常は**サードパーティプラットフォームのユーザーのグループに応じて異なるロールを与えたい**と思うでしょう。そのため、複数の**IAMロールがサードパーティのアイデンティティプロバイダーを信頼し、サードパーティプラットフォームがユーザーにどちらのロールを引き受けるかを許可します**。
|
||||
|
||||
<figure><img src="../../../images/image (247).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -263,28 +263,28 @@ AWS IAMアイデンティティセンター（AWSシングルサインオンの
|
||||
|
||||
ログインドメインは、`<user_input>.awsapps.com`のようになります。
|
||||
|
||||
ユーザーをログインさせるために、使用できるアイデンティティソースは3つあります：
|
||||
ユーザーをログインさせるために、使用できる3つのアイデンティティソースがあります：
|
||||
|
||||
- アイデンティティセンターディレクトリ：通常のAWSユーザー
|
||||
- アクティブディレクトリ：異なるコネクタをサポート
|
||||
- Active Directory：異なるコネクタをサポート
|
||||
- 外部アイデンティティプロバイダー：すべてのユーザーとグループは外部アイデンティティプロバイダー（IdP）から来ます
|
||||
|
||||
<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
|
||||
|
||||
@@ -346,8 +346,8 @@ AWSアイデンティティおよびアクセス管理（IAM）は、AWS全体
|
||||
|
||||
### CLI認証
|
||||
|
||||
通常のユーザーがCLIを介してAWSに認証するためには、**ローカル資格情報**が必要です。デフォルトでは、`~/.aws/credentials`に**手動で**設定するか、**`aws configure`を実行することによって**構成できます。\
|
||||
そのファイルには、1つ以上のプロファイルを持つことができ、**プロファイル**が指定されていない場合、**aws cli**を使用すると、そのファイル内の**`[default]`**と呼ばれるものが使用されます。\
|
||||
通常のユーザーがCLIを介してAWSに認証するためには、**ローカル資格情報**が必要です。デフォルトでは、`~/.aws/credentials`に**手動で**設定するか、**`aws configure`を実行することで**構成できます。\
|
||||
そのファイルには、1つ以上のプロファイルを持つことができ、**プロファイル**が指定されていない場合、**そのファイルの`[default]`**と呼ばれるものが使用されます。\
|
||||
複数のプロファイルを持つ資格情報ファイルの例：
|
||||
```
|
||||
[default]
|
||||
@@ -371,12 +371,29 @@ role_session_name = <session_name>
|
||||
source_profile = <profile_with_assume_role>
|
||||
sts_regional_endpoints = regional
|
||||
```
|
||||
この設定ファイルを使用すると、次のようにaws cliを使用できます:
|
||||
この設定ファイルを使用すると、aws cliを次のように使用できます:
|
||||
```
|
||||
aws --profile acc2 ...
|
||||
```
|
||||
もしこれに**似た**ものを**ブラウザ**用に探しているなら、**拡張機能** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en) をチェックしてください。
|
||||
もしこれに**似た**ものを**ブラウザ**用に探しているなら、**拡張機能** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en)をチェックできます。
|
||||
|
||||
#### 一時的な資格情報の自動化
|
||||
|
||||
一時的な資格情報を生成するアプリケーションを悪用している場合、資格情報が期限切れになるたびにターミナルでそれらを更新するのは面倒です。これは、設定ファイルに`credential_process`ディレクティブを使用することで解決できます。たとえば、脆弱なウェブアプリがある場合、次のようにできます:
|
||||
```toml
|
||||
[victim]
|
||||
credential_process = curl -d 'PAYLOAD' https://some-site.com
|
||||
```
|
||||
注意してください、資格情報は次の形式でSTDOUTに返される必要があります：
|
||||
```json
|
||||
{
|
||||
"Version": 1,
|
||||
"AccessKeyId": "an AWS access key",
|
||||
"SecretAccessKey": "your AWS secret access key",
|
||||
"SessionToken": "the AWS session token for temporary credentials",
|
||||
"Expiration": "ISO8601 timestamp when the credentials expire"
|
||||
}
|
||||
```
|
||||
## 参考文献
|
||||
|
||||
- [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)
|
||||
|
||||
Reference in New Issue
Block a user