mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-30 22:50:43 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA
This commit is contained in:
@@ -10,7 +10,7 @@
|
||||
|
||||
AWSには**ルートアカウント**があり、これは**組織内のすべてのアカウントの親コンテナ**です。しかし、そのアカウントを使用してリソースをデプロイする必要はなく、**異なるAWS**インフラストラクチャを分離するために**他のアカウントを作成することができます**。
|
||||
|
||||
これは**セキュリティ**の観点から非常に興味深いことであり、**1つのアカウントは他のアカウントのリソースにアクセスできません**(特別にブリッジが作成されていない限り)。このようにして、デプロイメント間に境界を作成できます。
|
||||
これは**セキュリティ**の観点から非常に興味深いことであり、**1つのアカウントは他のアカウントのリソースにアクセスできません**(特別にブリッジが作成されない限り)。このようにして、デプロイメント間に境界を作成できます。
|
||||
|
||||
したがって、**組織内には2種類のアカウントがあります**(AWSアカウントについて話しており、ユーザーアカウントではありません):管理アカウントとして指定された単一のアカウントと、1つ以上のメンバーアカウントです。
|
||||
|
||||
@@ -27,33 +27,33 @@ AWSには**ルートアカウント**があり、これは**組織内のすべ
|
||||
管理アカウントは**支払いアカウントの責任**を持ち、メンバーアカウントによって発生したすべての料金を支払う責任があります。組織の管理アカウントを変更することはできません。
|
||||
|
||||
- **メンバーアカウント**は、組織内の残りのすべてのアカウントを構成します。アカウントは、一度に1つの組織のメンバーであることができます。アカウントにポリシーを添付して、そのアカウントのみに制御を適用することができます。
|
||||
- メンバーアカウントは**有効なメールアドレスを使用する必要があり**、**名前**を持つことができます。一般的に、請求を管理することはできませんが、アクセスが与えられることがあります。
|
||||
- メンバーアカウントは**有効なメールアドレスを使用する必要があり**、**名前**を持つことができます。一般的に、請求を管理することはできませんが、アクセスが与えられる場合があります。
|
||||
```
|
||||
aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com
|
||||
```
|
||||
### **組織単位**
|
||||
|
||||
アカウントは**組織単位 (OU)**にグループ化できます。このようにして、組織単位に対して**ポリシー**を作成し、それが**すべての子アカウントに適用される**ようにできます。OUは他のOUを子として持つことができることに注意してください。
|
||||
アカウントは**組織単位 (OU)**にグループ化できます。この方法で、組織単位に対して**ポリシー**を作成し、それが**すべての子アカウントに適用される**ようにできます。OUは他のOUを子として持つことができることに注意してください。
|
||||
```bash
|
||||
# You can get the root id from aws organizations list-roots
|
||||
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
|
||||
```
|
||||
### サービスコントロールポリシー (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の例:
|
||||
|
||||
- ルートアカウントを完全に拒否
|
||||
- 特定のリージョンのみを許可
|
||||
- ホワイトリストに登録されたサービスのみを許可
|
||||
- GuardDuty、CloudTrail、およびS3のパブリックブロックアクセスを無効にすることを拒否
|
||||
- GuardDuty、CloudTrail、およびS3パブリックブロックアクセスの無効化を拒否
|
||||
|
||||
- セキュリティ/インシデントレスポンスロールの削除または
|
||||
|
||||
@@ -66,7 +66,7 @@ SCPの例:
|
||||
|
||||
### ARN
|
||||
|
||||
**Amazon Resource Name**は、AWS内のすべてのリソースが持つ**一意の名前**で、次のように構成されています:
|
||||
**Amazonリソース名**は、AWS内のすべてのリソースが持つ**ユニークな名前**で、次のように構成されています:
|
||||
```
|
||||
arn:partition:service:region:account-id:resource-type/resource-id
|
||||
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env
|
||||
@@ -80,10 +80,10 @@ arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env
|
||||
|
||||
## IAM - アイデンティティとアクセス管理
|
||||
|
||||
IAMは、AWSアカウント内で**認証**、**承認**、および**アクセス制御**を管理するためのサービスです。
|
||||
IAMは、AWSアカウント内での**認証**、**承認**、および**アクセス制御**を管理するためのサービスです。
|
||||
|
||||
- **認証** - アイデンティティを定義し、そのアイデンティティを検証するプロセス。このプロセスは、識別と検証に分けることができます。
|
||||
- **承認** - アイデンティティがシステム内でアクセスできるものを決定します。
|
||||
- **承認** - 認証された後に、システム内でアイデンティティがアクセスできるものを決定します。
|
||||
- **アクセス制御** - セキュアなリソースへのアクセスがどのように付与されるかの方法とプロセス
|
||||
|
||||
IAMは、AWSアカウント内のリソースに対するアイデンティティの認証、承認、およびアクセス制御メカニズムを管理、制御、統治する能力によって定義されます。
|
||||
@@ -98,26 +98,26 @@ 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ユーザーを作成すると、適切な権限ポリシーが添付された**ユーザーグループのメンバー**にすることで**権限**を付与するか、**ポリシーを直接ユーザーに添付**することができます(推奨)。
|
||||
|
||||
ユーザーは、コンソールを通じて**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によって保護されていません。ユーザーのAPIキーのアクセスをMFAを使用して**制限したい場合**は、特定のアクションを実行するために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を取得することはできません)。
|
||||
- **アクセスキーID**: 20のランダムな大文字アルファベットと数字の組み合わせ(例:AKHDNAPO86BSHKDIRYT)
|
||||
- **シークレットアクセスキーID**: 40のランダムな大文字と小文字の文字(例:S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU)(失われたシークレットアクセスキーIDを取得することはできません)。
|
||||
|
||||
**アクセスキーを変更する必要がある場合**は、次のプロセスに従う必要があります:\
|
||||
_新しいアクセスキーを作成 -> 新しいキーをシステム/アプリケーションに適用 -> 元のキーを非アクティブとしてマーク -> 新しいアクセスキーが機能しているかテストして確認 -> 古いアクセスキーを削除_
|
||||
|
||||
### MFA - 多要素認証
|
||||
|
||||
これは、既存の方法(パスワードなど)に加えて**認証のための追加の要素を作成する**ために使用され、したがって多要素の認証レベルを作成します。\
|
||||
**無料の仮想アプリケーションまたは物理デバイス**を使用できます。Google認証などのアプリを使用して、AWSでMFAを無料で有効にできます。
|
||||
これは、既存の方法(パスワードなど)に加えて**認証のための追加の要素を作成する**ために使用され、マルチファクターレベルの認証を作成します。\
|
||||
無料の仮想アプリケーションや物理デバイスを使用できます。Google認証などのアプリを使用して、AWSでMFAを無料で有効にできます。
|
||||
|
||||
MFA条件を持つポリシーは、次のものに添付できます:
|
||||
MFA条件を持つポリシーは、以下に添付できます:
|
||||
|
||||
- IAMユーザーまたはグループ
|
||||
- Amazon S3バケット、Amazon SQSキュー、またはAmazon SNSトピックなどのリソース
|
||||
@@ -134,7 +134,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)は、**複数のユーザーにポリシーを一度にアタッチする**方法であり、これによりそれらのユーザーの権限を管理しやすくなります。**ロールとグループはグループの一部にはなれません**。
|
||||
|
||||
**ユーザーグループにアイデンティティベースのポリシーをアタッチする**ことで、ユーザーグループ内のすべての**ユーザー**が**ポリシーの権限を受け取ります**。**ユーザーグループ**を**ポリシー**(リソースベースのポリシーなど)内の**`Principal`**として特定することは**できません**。なぜなら、グループは権限に関連し、認証には関連しないため、プリンシパルは認証されたIAMエンティティだからです。
|
||||
**ユーザーグループにアイデンティティベースのポリシーをアタッチ**することで、ユーザーグループ内のすべての**ユーザー**が**ポリシーの権限を受け取ります**。**ユーザーグループ**を**ポリシー**(リソースベースのポリシーなど)内の**`Principal`**として特定することは**できません**。なぜなら、グループは権限に関連し、認証には関連しないため、プリンシパルは認証されたIAMエンティティだからです。
|
||||
|
||||
ユーザーグループの重要な特徴は以下の通りです:
|
||||
|
||||
@@ -145,7 +145,7 @@ IAM [ユーザーグループ](https://docs.aws.amazon.com/IAM/latest/UserGuide/
|
||||
|
||||
### [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種類のポリシー**で構成されています:**信頼ポリシー**(空であってはならず、**誰がロールを引き受けることができるかを定義**)と、**権限ポリシー**(空であってはならず、**何にアクセスできるかを定義**)。
|
||||
|
||||
@@ -164,7 +164,7 @@ AWSセキュリティトークンサービス(STS)は、**一時的で制限
|
||||
権限を割り当てるために使用されます。2種類あります:
|
||||
|
||||
- AWS管理ポリシー(AWSによって事前設定されたもの)
|
||||
- カスタマー管理ポリシー:あなたが設定したもの。AWS管理ポリシーに基づいてポリシーを作成できます(そのうちの1つを修正して独自のものを作成する)、ポリシージェネレーターを使用する(権限を付与および拒否するのを助けるGUIビュー)または独自に作成することができます。
|
||||
- カスタマー管理ポリシー:あなたが設定したもの。AWS管理ポリシーに基づいてポリシーを作成できます(そのうちの1つを修正して独自のものを作成する)、ポリシージェネレーターを使用する(権限を付与および拒否するのを助けるGUIビュー)または自分で書くことができます。
|
||||
|
||||
**デフォルトのアクセスは** **拒否**され、明示的なロールが指定された場合にのみアクセスが許可されます。\
|
||||
**単一の「拒否」が存在する場合、それは「許可」を上書きします**。ただし、AWSアカウントのルートセキュリティ資格情報を使用するリクエストは(デフォルトで許可されます)。
|
||||
@@ -190,19 +190,19 @@ 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を使用してそのアイデンティティを削除すると、アイデンティティに埋め込まれたポリシーも削除されます。これは、それらが主エンティティの一部であるためです。
|
||||
この種のポリシーは**ユーザー、グループ、またはロールに直接割り当てられます**。そのため、他の誰も使用できるようにはポリシーリストに表示されません。\
|
||||
インラインポリシーは、**ポリシーと適用されるアイデンティティとの間に厳密な1対1の関係を維持したい場合**に便利です。たとえば、ポリシー内の権限が意図されたアイデンティティ以外に誤って割り当てられないことを確認したい場合です。インラインポリシーを使用すると、ポリシー内の権限が誤って間違ったアイデンティティに添付されることはありません。さらに、AWS Management Consoleを使用してそのアイデンティティを削除すると、アイデンティティに埋め込まれたポリシーも削除されます。これは、それらが主エンティティの一部であるためです。
|
||||
|
||||
#### リソースバケットポリシー
|
||||
|
||||
これらは**リソース内で定義できるポリシー**です。**すべてのAWSリソースがそれをサポートしているわけではありません**。
|
||||
これらは**リソースに定義できるポリシー**です。**すべてのAWSリソースがそれをサポートしているわけではありません**。
|
||||
|
||||
もしプリンシパルがそれに対して明示的な拒否を持っておらず、リソースポリシーがアクセスを許可している場合、アクセスが許可されます。
|
||||
もしプリンシパルがそれに対して明示的な拒否を持っておらず、リソースポリシーがアクセスを許可している場合、彼らは許可されます。
|
||||
|
||||
### IAMバウンダリー
|
||||
|
||||
@@ -210,11 +210,11 @@ IAMバウンダリーは、**ユーザーまたはロールがアクセスでき
|
||||
|
||||
バウンダリーは、ユーザーに添付されたポリシーであり、**ユーザーまたはロールが持つことができる最大の権限レベルを示します**。したがって、**ユーザーが管理者アクセスを持っていても**、バウンダリーが彼がS·バケットを読むことしかできないと示している場合、それが彼ができる最大のことです。
|
||||
|
||||
**これ**、**SCP**、および**最小特権の原則に従うこと**は、ユーザーが必要以上の権限を持たないように制御する方法です。
|
||||
**これ**、**SCP**および**最小権限の原則に従うこと**は、ユーザーが必要以上の権限を持たないように制御する方法です。
|
||||
|
||||
### セッションポリシー
|
||||
|
||||
セッションポリシーは、**ロールが引き受けられたときに設定されるポリシー**です。これは、そのセッションのための**IAMバウンダリーのようなものです**:これは、セッションポリシーが権限を付与するのではなく、**ポリシーに示された権限に制限することを意味します**(最大権限はロールが持つものです)。
|
||||
セッションポリシーは、**ロールが引き受けられたときに設定されるポリシー**です。これは、そのセッションの**IAMバウンダリーのようなもの**になります:これは、セッションポリシーが権限を付与するのではなく、**ポリシーに示された権限に制限することを意味します**(最大権限はロールが持つものです)。
|
||||
|
||||
これは**セキュリティ対策**に役立ちます:管理者が非常に特権のあるロールを引き受ける場合、セッションが侵害された場合に備えて、セッションポリシーに示された権限のみを制限することができます。
|
||||
```bash
|
||||
@@ -224,9 +224,9 @@ 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)。
|
||||
|
||||
したがって、ある時点で「...セッションポリシーが許可していないため...」というエラーに直面した場合、ロールがアクションを実行するアクセス権を持っていても、**それを妨げるセッションポリシーが存在するためです**。
|
||||
したがって、ある時点で「...セッションポリシーが許可していないため...」というエラーに直面した場合、ロールがアクションを実行するアクセス権を持っていても、**それを妨げるセッションポリシーが存在する**ということです。
|
||||
|
||||
### アイデンティティフェデレーション
|
||||
|
||||
@@ -253,19 +253,19 @@ AWS IAMアイデンティティセンター(AWSシングルサインオンの
|
||||
|
||||
<figure><img src="../../../images/image (279).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
アイデンティティセンターディレクトリの最も単純なケースでは、**アイデンティティセンターはユーザーとグループのリストを持ち**、それらに**ポリシーを割り当てることができます**。**組織の任意のアカウント**に対して。
|
||||
アイデンティティセンターディレクトリの最も単純なケースでは、**アイデンティティセンターはユーザーとグループのリストを持ち**、それらに**ポリシーを割り当てる**ことができ、**組織の任意のアカウント**に対して行います。
|
||||
|
||||
アイデンティティセンターのユーザー/グループにアカウントへのアクセスを与えるために、**アイデンティティセンターを信頼するSAMLアイデンティティプロバイダーが作成され**、**指定されたポリシーを持つアイデンティティプロバイダーを信頼するロールが宛先アカウントに作成されます**。
|
||||
|
||||
#### AwsSSOInlinePolicy
|
||||
|
||||
**IAMアイデンティティセンターを介して作成されたロールにインラインポリシーを介して権限を与えることが可能です**。AWSアイデンティティセンターで**インラインポリシーを持つアカウントに作成されたロール**は、**`AwsSSOInlinePolicy`**というインラインポリシーでこれらの権限を持ちます。
|
||||
**IAMアイデンティティセンターを介して作成されたロールにインラインポリシーを介して権限を与えることが可能です**。AWSアイデンティティセンターでインラインポリシーを持つアカウントで作成されたロールは、**`AwsSSOInlinePolicy`**というインラインポリシーでこれらの権限を持ちます。
|
||||
|
||||
したがって、**`AwsSSOInlinePolicy`**というインラインポリシーを持つ2つのロールが表示されても、**同じ権限を持っているわけではありません**。
|
||||
|
||||
### クロスアカウントの信頼とロール
|
||||
|
||||
**ユーザー**(信頼する側)は、いくつかのポリシーを持つクロスアカウントロールを作成し、**別のユーザー**(信頼される側)に**自分のアカウントにアクセスを許可することができますが、**新しいロールポリシーで示されたアクセスのみを持つことができます**。これを作成するには、新しいロールを作成し、クロスアカウントロールを選択します。クロスアカウントアクセス用のロールは2つのオプションを提供します。所有するAWSアカウント間でのアクセスを提供することと、所有するアカウントとサードパーティのAWSアカウント間でのアクセスを提供することです。\
|
||||
**ユーザー**(信頼する側)は、いくつかのポリシーを持つクロスアカウントロールを作成し、**別のユーザー**(信頼される側)に**自分のアカウントにアクセスを許可する**が、**新しいロールポリシーで示されたアクセスのみを持つ**ことができます。これを作成するには、新しいロールを作成し、クロスアカウントロールを選択します。クロスアカウントアクセス用のロールは2つのオプションを提供します。所有するAWSアカウント間でのアクセスを提供することと、所有するアカウントとサードパーティのAWSアカウント間でのアクセスを提供することです。\
|
||||
信頼されるユーザーを**特定し、一般的なものを指定しないことをお勧めします**。そうしないと、フェデレーテッドユーザーなどの他の認証されたユーザーもこの信頼を悪用できる可能性があります。
|
||||
|
||||
### AWS Simple AD
|
||||
@@ -282,14 +282,14 @@ AWS IAMアイデンティティセンター(AWSシングルサインオンの
|
||||
|
||||
#### WebフェデレーションまたはOpenID認証
|
||||
|
||||
アプリはAssumeRoleWithWebIdentityを使用して一時的な資格情報を作成します。ただし、これによりAWSコンソールへのアクセスは付与されず、AWS内のリソースへのアクセスのみが許可されます。
|
||||
アプリはAssumeRoleWithWebIdentityを使用して一時的な資格情報を作成します。ただし、これによりAWSコンソールへのアクセスは付与されず、AWS内のリソースへのアクセスのみが付与されます。
|
||||
|
||||
### その他のIAMオプション
|
||||
|
||||
- **パスワードポリシー設定**を設定することができ、最小長やパスワード要件などのオプションがあります。
|
||||
- **"Credential Report"をダウンロード**して、現在の資格情報に関する情報(ユーザー作成時間、パスワードが有効かどうかなど)を取得できます。資格情報レポートは、最長で**4時間ごとに生成**できます。
|
||||
- **"Credential Report"をダウンロード**して、現在の資格情報に関する情報(ユーザー作成時間、パスワードが有効かどうかなど)を取得できます。資格情報レポートは、最長で**4時間ごと**に生成できます。
|
||||
|
||||
AWSアイデンティティおよびアクセス管理(IAM)は、AWS全体での**きめ細かいアクセス制御**を提供します。IAMを使用すると、**誰がどのサービスやリソースにアクセスできるか、どの条件下でアクセスできるかを指定できます**。IAMポリシーを使用して、労働力やシステムへの権限を管理し、**最小権限の権限を確保します**。
|
||||
AWSアイデンティティおよびアクセス管理(IAM)は、AWS全体での**きめ細かいアクセス制御**を提供します。IAMを使用すると、**誰がどのサービスやリソースにアクセスできるか、そしてどの条件下でアクセスできるかを指定できます**。IAMポリシーを使用して、労働力やシステムへの権限を管理し、**最小権限の権限を確保します**。
|
||||
|
||||
### IAM IDプレフィックス
|
||||
|
||||
|
||||
Reference in New Issue
Block a user