mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-31 23:15:48 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA
This commit is contained in:
Translator
@@ -10,7 +10,7 @@
|
||||
|
||||
AWSには**ルートアカウント**があり、これは**組織内のすべてのアカウントの親コンテナ**です。しかし、そのアカウントを使用してリソースをデプロイする必要はなく、**異なるAWS**インフラストラクチャを分離するために**他のアカウントを作成することができます**。
|
||||
|
||||
これは**セキュリティ**の観点から非常に興味深いことであり、**1つのアカウントは他のアカウントのリソースにアクセスできません**（特別にブリッジが作成されない限り）。このようにして、デプロイメント間に境界を作成できます。
|
||||
これは**セキュリティ**の観点から非常に興味深いことであり、**1つのアカウントは他のアカウントのリソースにアクセスできません**（特別にブリッジが作成されていない限り）。このようにして、デプロイメント間に境界を作成できます。
|
||||
|
||||
したがって、**組織内には2種類のアカウントがあります**（AWSアカウントについて話しており、ユーザーアカウントではありません）：管理アカウントとして指定された単一のアカウントと、1つ以上のメンバーアカウントです。
|
||||
|
||||
@@ -21,57 +21,57 @@ AWSには**ルートアカウント**があり、これは**組織内のすべ
|
||||
- 組織からアカウントを削除する
|
||||
- 招待を管理する
|
||||
- 組織内のエンティティ（ルート、OU、またはアカウント）にポリシーを適用する
|
||||
- 組織内のすべてのアカウントにわたってサービス機能を提供するために、サポートされているAWSサービスとの統合を有効にする。
|
||||
- 組織内のすべてのアカウントにサービス機能を提供するために、サポートされている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の例:
|
||||
|
||||
- ルートアカウントを完全に拒否
|
||||
- 特定のリージョンのみを許可
|
||||
- ホワイトリストに登録されたサービスのみを許可
|
||||
- GuardDuty、CloudTrail、およびS3パブリックブロックアクセスの無効化を拒否
|
||||
- GuardDuty、CloudTrail、およびS3のパブリックブロックアクセスを無効にすることを拒否
|
||||
|
||||
- セキュリティ/インシデントレスポンスロールの削除または
|
||||
|
||||
変更を拒否。
|
||||
|
||||
- バックアップの削除を拒否。
|
||||
- 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)で見つけてください。
|
||||
|
||||
### ARN
|
||||
|
||||
**Amazonリソース名**は、AWS内のすべてのリソースが持つ**ユニークな名前**で、次のように構成されています：
|
||||
**Amazon Resource Name**は、AWS内のすべてのリソースが持つ**一意の名前**で、次のように構成されています:
|
||||
```
|
||||
arn:partition:service:region:account-id:resource-type/resource-id
|
||||
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env
|
||||
```
|
||||
AWSには4つのパーティションがありますが、それを呼び出す方法は3つだけです：
|
||||
注意：AWSには4つのパーティションがありますが、それを呼び出す方法は3つだけです：
|
||||
|
||||
- AWS Standard: `aws`
|
||||
- AWS China: `aws-cn`
|
||||
@@ -80,10 +80,10 @@ AWSには4つのパーティションがありますが、それを呼び出す
|
||||
|
||||
## IAM - アイデンティティとアクセス管理
|
||||
|
||||
IAMは、AWSアカウント内で**認証**、**承認**、および**アクセス制御**を管理することを可能にするサービスです。
|
||||
IAMは、AWSアカウント内で**認証**、**承認**、および**アクセス制御**を管理するためのサービスです。
|
||||
|
||||
- **認証** - アイデンティティを定義し、そのアイデンティティを検証するプロセス。このプロセスは、識別と検証に分けることができます。
|
||||
- **承認** - アイデンティティがシステム内でアクセスできるものを決定します。これは認証された後のことです。
|
||||
- **承認** - アイデンティティがシステム内でアクセスできるものを決定します。
|
||||
- **アクセス制御** - セキュアなリソースへのアクセスがどのように付与されるかの方法とプロセス
|
||||
|
||||
IAMは、AWSアカウント内のリソースに対するアイデンティティの認証、承認、およびアクセス制御メカニズムを管理、制御、統治する能力によって定義されます。
|
||||
@@ -106,37 +106,35 @@ IAMユーザーを作成すると、適切な権限ポリシーが添付され
|
||||
|
||||
#### CLI
|
||||
|
||||
- **アクセスキーID**: 20のランダムな大文字の英数字の文字列（例: AKHDNAPO86BSHKDIRYT）
|
||||
- **シークレットアクセスキーID**: 40のランダムな大文字と小文字の文字列（例: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU）（失われたシークレットアクセスキーIDを取得することはできません）。
|
||||
- **アクセスキーID**: 20のランダムな大文字の英数字の文字列（例：AKHDNAPO86BSHKDIRYT）
|
||||
- **シークレットアクセスキーID**: 40のランダムな大文字と小文字の文字列（例：S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU）（失われたシークレットアクセスキーIDを取得することはできません）。
|
||||
|
||||
**アクセスキーを変更する必要がある場合**は、次のプロセスに従う必要があります：\
|
||||
&#xNAN;_Create a new access key -> Apply the new key to system/application -> mark original one as inactive -> Test and verify new access key is working -> Delete old access key_
|
||||
_新しいアクセスキーを作成 -> 新しいキーをシステム/アプリケーションに適用 -> 元のキーを非アクティブとしてマーク -> 新しいアクセスキーが機能しているかテストして確認 -> 古いアクセスキーを削除_
|
||||
|
||||
### MFA - 多要素認証
|
||||
|
||||
これは、既存の方法（パスワードなど）に加えて**認証のための追加の要素を作成する**ために使用され、したがって多要素の認証レベルを作成します。\
|
||||
**無料の仮想アプリケーションまたは物理デバイス**を使用できます。Google認証などのアプリを無料で使用してAWSでMFAを有効にできます。
|
||||
**無料の仮想アプリケーションまたは物理デバイス**を使用できます。Google認証などのアプリを使用して、AWSでMFAを無料で有効にできます。
|
||||
|
||||
MFA条件を持つポリシーは、以下に添付できます：
|
||||
MFA条件を持つポリシーは、次のものに添付できます：
|
||||
|
||||
- IAMユーザーまたはグループ
|
||||
- Amazon S3バケット、Amazon SQSキュー、またはAmazon SNSトピックなどのリソース
|
||||
- ユーザーによって引き受けられるIAMロールの信頼ポリシー
|
||||
|
||||
**CLIを介して**MFAを**チェックする**リソースにアクセスしたい場合は、**`GetSessionToken`**を呼び出す必要があります。これにより、MFAに関する情報を含むトークンが得られます。\
|
||||
**`AssumeRole`の資格情報にはこの情報は含まれていない**ことに注意してください。
|
||||
**MFAをチェックする**リソースに**CLI経由でアクセスしたい場合**は、**`GetSessionToken`**を呼び出す必要があります。これにより、MFAに関する情報を含むトークンが得られます。\
|
||||
**`AssumeRole`の資格情報にはこの情報が含まれていない**ことに注意してください。
|
||||
```bash
|
||||
aws sts get-session-token --serial-number <arn_device> --token-code <code>
|
||||
```
|
||||
以下の内容は、AWSにおけるMFAの使用に関する情報です。
|
||||
|
||||
As [**stated here**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)、**MFAを使用できない**さまざまなケースがあります。
|
||||
以下の内容は、AWSにおけるMFAの使用ができないさまざまなケースについて説明しています。
|
||||
|
||||
### [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)は、**複数のユーザーにポリシーを一度にアタッチする**方法であり、これによりそれらのユーザーの権限を管理しやすくなります。**ロールとグループはグループの一部にはなれません**。
|
||||
|
||||
**ユーザーグループにアイデンティティベースのポリシーをアタッチ**することで、ユーザーグループ内のすべての**ユーザー**が**ポリシーの権限を受け取ります**。**ユーザーグループ**を**ポリシー**（リソースベースのポリシーなど）内の**`Principal`**として特定することは**できません**。なぜなら、グループは権限に関連し、認証には関連しないため、プリンシパルは認証されたIAMエンティティだからです。
|
||||
**ユーザーグループにアイデンティティベースのポリシーをアタッチする**ことで、ユーザーグループ内のすべての**ユーザー**が**ポリシーの権限を受け取ります**。**ユーザーグループ**を**ポリシー**（リソースベースのポリシーなど）内の**`Principal`**として特定することは**できません**。なぜなら、グループは権限に関連し、認証には関連しないため、プリンシパルは認証されたIAMエンティティだからです。
|
||||
|
||||
ユーザーグループの重要な特徴は以下の通りです：
|
||||
|
||||
@@ -147,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種類のポリシー**で構成されています：**信頼ポリシー**（空であってはならず、**誰がロールを引き受けることができるかを定義**）と、**権限ポリシー**（空であってはならず、**何にアクセスできるかを定義**）。
|
||||
|
||||
@@ -166,10 +164,10 @@ AWSセキュリティトークンサービス（STS）は、**一時的で制限
|
||||
権限を割り当てるために使用されます。2種類あります：
|
||||
|
||||
- AWS管理ポリシー（AWSによって事前設定されたもの）
|
||||
- カスタマー管理ポリシー：あなたが設定したもの。AWS管理ポリシーに基づいてポリシーを作成できます（そのうちの1つを修正して自分のものを作成する）、ポリシージェネレーターを使用する（権限を付与および拒否するのを助けるGUIビュー）または自分で書くことができます。
|
||||
- カスタマー管理ポリシー：あなたが設定したもの。AWS管理ポリシーに基づいてポリシーを作成できます（そのうちの1つを修正して独自のものを作成する）、ポリシージェネレーターを使用する（権限を付与および拒否するのを助けるGUIビュー）または独自に作成することができます。
|
||||
|
||||
**デフォルトのアクセスは** **拒否**され、明示的なロールが指定された場合にのみアクセスが許可されます。\
|
||||
**単一の「拒否」が存在する場合、それは「許可」を上書きします**。ただし、AWSアカウントのルートセキュリティ資格情報を使用するリクエスト（デフォルトで許可されている）は除きます。
|
||||
**単一の「拒否」が存在する場合、それは「許可」を上書きします**。ただし、AWSアカウントのルートセキュリティ資格情報を使用するリクエストは（デフォルトで許可されます）。
|
||||
```javascript
|
||||
{
|
||||
"Version": "2012-10-17", //Version of the policy
|
||||
@@ -192,31 +190,31 @@ 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バウンダリー
|
||||
|
||||
IAMバウンダリーは、**ユーザーまたはロールがアクセスできる権限を制限するために使用できます**。このように、異なるポリシーによってユーザーに異なる権限が付与されても、操作は**失敗**します。
|
||||
IAMバウンダリーは、**ユーザーまたはロールがアクセスできる権限を制限するために使用できます**。このように、異なるポリシーによってユーザーに異なる権限が付与されても、使用しようとすると操作は**失敗**します。
|
||||
|
||||
バウンダリーは、ユーザーに添付されたポリシーであり、**ユーザーまたはロールが持つことができる最大の権限レベルを示します**。したがって、**ユーザーが管理者アクセスを持っていても**、バウンダリーが彼がS·バケットを読むことしかできないと示している場合、それが彼ができる最大のことです。
|
||||
|
||||
**これ**、**SCP**および**最小特権の原則に従うこと**は、ユーザーが必要な権限以上の権限を持たないように制御する方法です。
|
||||
**これ**、**SCP**、および**最小特権の原則に従うこと**は、ユーザーが必要以上の権限を持たないように制御する方法です。
|
||||
|
||||
### セッションポリシー
|
||||
|
||||
セッションポリシーは、**ロールが引き受けられたときに設定されるポリシー**です。これは、そのセッションの**IAMバウンダリーのようなもの**です：これは、セッションポリシーが権限を付与するのではなく、**ポリシーに示された権限に制限することを意味します**（最大の権限はロールが持つものです）。
|
||||
セッションポリシーは、**ロールが引き受けられたときに設定されるポリシー**です。これは、そのセッションのための**IAMバウンダリーのようなものです**：これは、セッションポリシーが権限を付与するのではなく、**ポリシーに示された権限に制限することを意味します**（最大権限はロールが持つものです）。
|
||||
|
||||
これは**セキュリティ対策**に役立ちます：管理者が非常に特権のあるロールを引き受ける場合、セッションが侵害された場合に備えて、セッションポリシーに示された権限のみを制限することができます。
|
||||
```bash
|
||||
@@ -226,18 +224,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)では、デフォルトで（強化された認証を使用して）、AWSは**セッションポリシーを持つセッション資格情報**を生成し、そのセッションがアクセスできるサービスを[**次のリストに制限します**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services)。
|
||||
|
||||
したがって、ある時点で「...セッションポリシーが許可していないため...」というエラーに直面した場合、ロールがアクションを実行するアクセス権を持っていても、**それを妨げるセッションポリシーが存在する**ということです。
|
||||
したがって、ある時点で「...セッションポリシーが許可していないため...」というエラーに直面した場合、ロールがアクションを実行するアクセス権を持っていても、**それを妨げるセッションポリシーが存在するためです**。
|
||||
|
||||
### アイデンティティフェデレーション
|
||||
|
||||
アイデンティティフェデレーションは、**AWSに外部のアイデンティティプロバイダーからのユーザー**がAWSリソースに安全にアクセスできるようにします。これにより、正当なIAMユーザーアカウントからAWSユーザー資格情報を提供する必要がなくなります。\
|
||||
アイデンティティフェデレーションは、**AWSに外部のアイデンティティプロバイダーからのユーザーが**、有効なIAMユーザーアカウントのAWSユーザー資格情報を提供することなく、AWSリソースに安全にアクセスできるようにします。\
|
||||
アイデンティティプロバイダーの例としては、独自の企業の**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>
|
||||
|
||||
@@ -255,24 +253,24 @@ 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
|
||||
|
||||
サポートされていないもの：
|
||||
サポートされていない：
|
||||
|
||||
- 信頼関係
|
||||
- AD管理センター
|
||||
@@ -288,17 +286,19 @@ AWS IAMアイデンティティセンター（AWSシングルサインオンの
|
||||
|
||||
### その他のIAMオプション
|
||||
|
||||
- **パスワードポリシー設定**を設定することができます。最小長やパスワード要件などのオプションがあります。
|
||||
- **「資格情報レポート」をダウンロード**することができ、現在の資格情報に関する情報（ユーザー作成時間、パスワードが有効かどうかなど）を取得できます。資格情報レポートは、最長で**4時間ごと**に生成できます。
|
||||
- **パスワードポリシー設定**を設定することができ、最小長やパスワード要件などのオプションがあります。
|
||||
- **"Credential Report"をダウンロード**して、現在の資格情報に関する情報（ユーザー作成時間、パスワードが有効かどうかなど）を取得できます。資格情報レポートは、最長で**4時間ごとに生成**できます。
|
||||
|
||||
AWSアイデンティティおよびアクセス管理（IAM）は、AWS全体で**細かいアクセス制御**を提供します。IAMを使用すると、**誰がどのサービスやリソースにアクセスできるか**、およびどの条件下でアクセスできるかを指定できます。IAMポリシーを使用して、労働力やシステムへの権限を管理し、**最小権限の権限を確保**します。
|
||||
AWSアイデンティティおよびアクセス管理（IAM）は、AWS全体での**きめ細かいアクセス制御**を提供します。IAMを使用すると、**誰がどのサービスやリソースにアクセスできるか、どの条件下でアクセスできるかを指定できます**。IAMポリシーを使用して、労働力やシステムへの権限を管理し、**最小権限の権限を確保します**。
|
||||
|
||||
### IAM IDプレフィックス
|
||||
|
||||
[**このページ**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids)では、キーの性質に応じた**IAM IDプレフィックス**を見つけることができます：
|
||||
|
||||
| ABIA | [AWS STSサービスベアラートークン](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
|
||||
| Identifier Code | Description |
|
||||
| ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| ABIA | [AWS STSサービスベアラートークン](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
|
||||
|
||||
| ACCA | コンテキスト固有の資格情報 |
|
||||
| AGPA | ユーザーグループ |
|
||||
| AIDA | IAMユーザー |
|
||||
@@ -329,7 +329,7 @@ AWSアイデンティティおよびアクセス管理（IAM）は、AWS全体
|
||||
### CLI認証
|
||||
|
||||
通常のユーザーがCLIを介してAWSに認証するためには、**ローカル資格情報**が必要です。デフォルトでは、`~/.aws/credentials`に**手動で**設定するか、**`aws configure`を実行することで**構成できます。\
|
||||
そのファイルには、1つ以上のプロファイルを持つことができ、**プロファイル**が指定されていない場合、**`[default]`**と呼ばれるものがそのファイルで使用されます。\
|
||||
そのファイルには、1つ以上のプロファイルを持つことができ、**プロファイル**が指定されていない場合、**そのファイルの`[default]`**と呼ばれるものが使用されます。\
|
||||
複数のプロファイルを持つ資格情報ファイルの例：
|
||||
```
|
||||
[default]
|
||||
@@ -343,7 +343,7 @@ region = eu-west-2
|
||||
```
|
||||
異なる **AWS アカウント** にアクセスする必要があり、あなたのプロファイルが **それらのアカウント内でロールを引き受ける** アクセスを与えられている場合、毎回手動で STS を呼び出す必要はありません (`aws sts assume-role --role-arn <role-arn> --role-session-name sessname`) と資格情報を設定する必要はありません。
|
||||
|
||||
`~/.aws/config` ファイルを使用して[ **引き受けるロールを指定する**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html)ことができ、その後は通常通り `--profile` パラメータを使用できます（`assume-role` はユーザーにとって透過的に実行されます）。\
|
||||
`~/.aws/config` ファイルを使用して[ **引き受けるロールを指定**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html)し、その後は通常通り `--profile` パラメータを使用できます（`assume-role` はユーザーにとって透過的に実行されます）。\
|
||||
設定ファイルの例:
|
||||
```
|
||||
[profile acc2]
|
||||
@@ -353,11 +353,11 @@ 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)をチェックしてください。
|
||||
|
||||
## 参考文献
|
||||
|
||||
|
||||
@@ -4,62 +4,62 @@
|
||||
|
||||
## **CloudTrail**
|
||||
|
||||
AWS CloudTrail **は、AWS環境内の活動を記録および監視します**。それは、誰が何を、いつ、どこから行ったかを含む詳細な**イベントログ**をキャプチャします。これにより、変更やアクションの監査証跡が提供され、セキュリティ分析、コンプライアンス監査、およびリソース変更の追跡に役立ちます。CloudTrailは、ユーザーとリソースの行動を理解し、セキュリティ姿勢を強化し、規制遵守を確保するために不可欠です。
|
||||
AWS CloudTrail **は、AWS 環境内のアクティビティを記録および監視します**。それは、誰が何を、いつ、どこから行ったかを含む詳細な **イベントログ** をキャプチャします。これにより、変更やアクションの監査証跡が提供され、セキュリティ分析、コンプライアンス監査、およびリソース変更の追跡に役立ちます。CloudTrail は、ユーザーおよびリソースの動作を理解し、セキュリティ姿勢を強化し、規制遵守を確保するために不可欠です。
|
||||
|
||||
各ログされたイベントには以下が含まれます：
|
||||
|
||||
- 呼び出されたAPIの名前: `eventName`
|
||||
- 呼び出された API の名前: `eventName`
|
||||
- 呼び出されたサービス: `eventSource`
|
||||
- 時間: `eventTime`
|
||||
- IPアドレス: `SourceIPAddress`
|
||||
- IP アドレス: `SourceIPAddress`
|
||||
- エージェントメソッド: `userAgent`。例：
|
||||
- Signing.amazonaws.com - AWS Management Consoleから
|
||||
- Signing.amazonaws.com - AWS Management Console から
|
||||
- console.amazonaws.com - アカウントのルートユーザー
|
||||
- lambda.amazonaws.com - AWS Lambda
|
||||
- リクエストパラメータ: `requestParameters`
|
||||
- レスポンス要素: `responseElements`
|
||||
|
||||
イベントは**約5分ごとにJSONファイルに新しいログファイルとして書き込まれ**、CloudTrailによって保持され、最終的にログファイルは**約15分後にS3に配信されます**。\
|
||||
CloudTrailのログは**アカウント間およびリージョン間で集約できます**。\
|
||||
CloudTrailは、**ログファイルの整合性を使用して、CloudTrailが提供した後にログファイルが変更されていないことを確認できるようにします**。これは、ダイジェストファイル内のログのSHA-256ハッシュを作成します。新しいログのsha-256ハッシュは毎時作成されます。\
|
||||
トレイルを作成する際、イベントセレクターを使用して、ログするトレイルを示すことができます：管理、データ、またはインサイトイベント。
|
||||
イベントは **約 5 分ごとに JSON ファイルに新しいログファイルとして書き込まれ**、CloudTrail に保持され、最終的にログファイルは **約 15 分後に S3 に配信されます**。\
|
||||
CloudTrail のログは **アカウント間およびリージョン間で集約できます。**\
|
||||
CloudTrail は **ログファイルの整合性を使用して、ログファイルが CloudTrail によって配信されて以来変更されていないことを確認できるようにします**。これは、ダイジェストファイル内のログの SHA-256 ハッシュを作成します。新しいログの SHA-256 ハッシュは毎時作成されます。\
|
||||
トレイルを作成する際、イベントセレクタを使用してログするトレイルを示すことができます：管理、データ、またはインサイトイベント。
|
||||
|
||||
ログはS3バケットに保存されます。デフォルトではサーバーサイド暗号化（SSE-S3）が使用されるため、AWSはアクセス権を持つ人々のためにコンテンツを復号化しますが、追加のセキュリティのためにSSEをKMSおよび独自のキーと共に使用することができます。
|
||||
ログは S3 バケットに保存されます。デフォルトではサーバーサイド暗号化 (SSE-S3) が使用されるため、AWS はアクセス権を持つ人々のためにコンテンツを復号化しますが、追加のセキュリティのために SSE を KMS と独自のキーで使用することもできます。
|
||||
|
||||
ログは**この名前形式のS3バケットに保存されます**：
|
||||
ログは **この名前形式の S3 バケットに保存されます**：
|
||||
|
||||
- **`BucketName/AWSLogs/AccountID/CloudTrail/RegionName/YYY/MM/DD`**
|
||||
- バケット名は：**`aws-cloudtrail-logs-<accountid>-<random>`**
|
||||
- 例：**`aws-cloudtrail-logs-947247140022-ffb95fe7/AWSLogs/947247140022/CloudTrail/ap-south-1/2023/02/22/`**
|
||||
- バケット名は: **`aws-cloudtrail-logs-<accountid>-<random>`**
|
||||
- 例: **`aws-cloudtrail-logs-947247140022-ffb95fe7/AWSLogs/947247140022/CloudTrail/ap-south-1/2023/02/22/`**
|
||||
|
||||
各フォルダ内の各ログは、**この形式に従った名前を持ちます**：**`AccountID_CloudTrail_RegionName_YYYYMMDDTHHMMZ_Random.json.gz`**
|
||||
各フォルダ内の各ログは **この形式に従った名前を持ちます**: **`AccountID_CloudTrail_RegionName_YYYYMMDDTHHMMZ_Random.json.gz`**
|
||||
|
||||
ログファイル命名規則
|
||||
|
||||
.png>)
|
||||
|
||||
さらに、**ファイル整合性を確認するためのダイジェストファイル**は、**同じバケット内にあります**：
|
||||
さらに、**ファイル整合性を確認するためのダイジェストファイル**は **同じバケット内にあります**：
|
||||
|
||||
.png>)
|
||||
|
||||
### 複数アカウントからのログの集約
|
||||
|
||||
- ログファイルを配信するAWSアカウントでトレイルを作成します
|
||||
- CloudTrailのためにクロスアカウントアクセスを許可するように、宛先S3バケットに権限を適用し、アクセスが必要な各AWSアカウントを許可します
|
||||
- 他のAWSアカウントで新しいトレイルを作成し、ステップ1で作成したバケットを使用するように選択します
|
||||
- ログファイルを配信する AWS アカウントでトレイルを作成します
|
||||
- CloudTrail のためにクロスアカウントアクセスを許可するように、宛先 S3 バケットに権限を適用し、アクセスが必要な各 AWS アカウントを許可します
|
||||
- 他の AWS アカウントで新しいトレイルを作成し、ステップ 1 で作成したバケットを使用するように選択します
|
||||
|
||||
ただし、すべてのログを同じS3バケットに保存できるとしても、複数のアカウントからのCloudTrailログを単一のAWSアカウントに属するCloudWatch Logsに集約することはできません。
|
||||
ただし、すべてのログを同じ S3 バケットに保存できるとしても、複数のアカウントからの CloudTrail ログを単一の AWS アカウントに属する CloudWatch Logs に集約することはできません。
|
||||
|
||||
> [!CAUTION]
|
||||
> アカウントには、**異なるトレイル**がCloudTrail **で有効**になっており、異なるバケットに同じ（または異なる）ログを保存できることを忘れないでください。
|
||||
> アカウントには、**異なるトレイル**が CloudTrail **で有効**になっており、異なるバケットに同じ（または異なる）ログを保存できることを忘れないでください。
|
||||
|
||||
### すべての組織アカウントから1つのCloudTrailへ
|
||||
### すべての組織アカウントから 1 つの CloudTrail へ
|
||||
|
||||
CloudTrailを作成する際、組織内のすべてのアカウントに対してCloudTrailを有効にし、ログを1つのバケットに取得するように指示することが可能です：
|
||||
CloudTrail を作成する際、組織内のすべてのアカウントに対して CloudTrail を有効にし、ログを 1 つのバケットに集約するように指示することが可能です：
|
||||
|
||||
<figure><img src="../../../../images/image (200).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
この方法で、すべてのアカウントのすべてのリージョンでCloudTrailを簡単に構成し、1つのアカウントにログを集中させることができます（そのアカウントは保護する必要があります）。
|
||||
この方法で、すべてのアカウントのすべてのリージョンで CloudTrail を簡単に構成し、1 つのアカウントにログを集中させることができます（そのアカウントは保護する必要があります）。
|
||||
|
||||
### ログファイルの確認
|
||||
|
||||
@@ -83,23 +83,23 @@ CloudTrail Event Historyでは、記録されたログをテーブルで確認
|
||||
|
||||
### Insights
|
||||
|
||||
**CloudTrail Insights**は自動的に**分析**し、CloudTrailトレイルからの書き込み管理イベントを**警告**し、**異常な活動**を通知します。例えば、`TerminateInstance`イベントの増加が確立されたベースラインと異なる場合、それはInsightイベントとして表示されます。これらのイベントは、**異常なAPI活動を見つけて対応することをこれまで以上に容易にします**。
|
||||
**CloudTrail Insights**は自動的に**管理イベントの書き込みを分析**し、**異常な活動**を**警告**します。例えば、`TerminateInstance`イベントの増加が確立されたベースラインと異なる場合、それはInsightイベントとして表示されます。これらのイベントは、**異常なAPI活動を見つけて対応することをこれまで以上に容易にします**。
|
||||
|
||||
インサイトはCloudTrailログと同じバケットに保存されます：`BucketName/AWSLogs/AccountID/CloudTrail-Insight`
|
||||
|
||||
### Security
|
||||
|
||||
| CloudTrail Log File Integrity | <ul><li>ログが改ざんされていないか（変更または削除）を検証</li><li><p>ダイジェストファイルを使用（各ファイルのハッシュを作成）</p><ul><li>SHA-256ハッシュ</li><li>デジタル署名のためのSHA-256とRSA</li><li>Amazonが所有する秘密鍵</li></ul></li><li>ダイジェストファイルの作成には1時間かかる（毎時行われる）</li></ul> |
|
||||
| Control Name | Implementation Details |
|
||||
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| Stop unauthorized access | <ul><li><p>IAMポリシーとS3バケットポリシーを使用</p><ul><li>セキュリティチーム —> 管理者アクセス</li><li>監査人 —> 読み取り専用アクセス</li></ul></li><li>SSE-S3/SSE-KMSを使用してログを暗号化</li></ul> |
|
||||
| Prevent log files from being deleted | <ul><li>IAMおよびバケットポリシーで削除アクセスを制限</li><li>S3 MFA削除を構成</li><li>ログファイル検証で検証</li></ul> |
|
||||
| CloudTrail Log File Integrity | <ul><li>ログが改ざんされていないか（変更または削除）を検証します</li><li><p>ダイジェストファイルを使用します（各ファイルのハッシュを作成）</p><ul><li>SHA-256ハッシュ</li><li>デジタル署名のためのSHA-256とRSA</li><li>Amazonが所有する秘密鍵</li></ul></li><li>ダイジェストファイルを作成するのに1時間かかります（毎時行われます）</li></ul> |
|
||||
| Stop unauthorized access | <ul><li><p>IAMポリシーとS3バケットポリシーを使用します</p><ul><li>セキュリティチーム —> 管理者アクセス</li><li>監査人 —> 読み取り専用アクセス</li></ul></li><li>ログを暗号化するためにSSE-S3/SSE-KMSを使用します</li></ul> |
|
||||
| Prevent log files from being deleted | <ul><li>IAMおよびバケットポリシーで削除アクセスを制限します</li><li>S3 MFA削除を構成します</li><li>ログファイル検証で検証します</li></ul> |
|
||||
|
||||
## Access Advisor
|
||||
|
||||
AWS Access Advisorは、過去400日間のAWS **CloudTrailログを利用してインサイトを収集します**。CloudTrailは、AWSアカウント内で行われたAWS APIコールと関連イベントの履歴をキャプチャします。Access Advisorはこのデータを利用して**サービスが最後にアクセスされた時期を表示します**。CloudTrailログを分析することで、Access AdvisorはIAMユーザーまたはロールがどのAWSサービスにアクセスしたか、そしてそのアクセスがいつ行われたかを特定できます。これにより、AWS管理者は**権限の精緻化**に関する情報に基づいた意思決定を行うことができ、長期間アクセスされていないサービスを特定し、実際の使用パターンに基づいて過度に広範な権限を削減することができます。
|
||||
AWS Access Advisorは、最後の400日間のAWS **CloudTrailログを利用してインサイトを収集します**。CloudTrailは、AWSアカウント内で行われたAWS APIコールと関連イベントの履歴をキャプチャします。Access Advisorはこのデータを利用して、**サービスが最後にアクセスされた時期を表示します**。CloudTrailログを分析することで、Access AdvisorはIAMユーザーまたはロールがどのAWSサービスにアクセスしたか、そしてそのアクセスがいつ行われたかを特定できます。これにより、AWS管理者は**権限の精緻化**に関する情報に基づいた意思決定を行うことができ、長期間アクセスされていないサービスを特定し、実際の使用パターンに基づいて過度に広範な権限を削減することができます。
|
||||
|
||||
> [!TIP]
|
||||
> したがって、Access Advisorは**ユーザーに与えられている不必要な権限について通知し**、管理者がそれらを削除できるようにします
|
||||
> したがって、Access Advisorは**ユーザーに与えられている不必要な権限**について通知し、管理者がそれらを削除できるようにします
|
||||
|
||||
<figure><img src="../../../../images/image (78).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -136,7 +136,7 @@ S3BucketName="random"
|
||||
)
|
||||
print(response)
|
||||
```
|
||||
より詳しい情報はCSVインジェクションについては、ページを確認してください：
|
||||
より詳しい情報はCSVインジェクションについては、以下のページを確認してください：
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/pentesting-web/formula-csv-doc-latex-ghostscript-injection.html
|
||||
@@ -154,7 +154,7 @@ Honeytokensは**機密情報の流出を検出するために作成されます*
|
||||
|
||||
[**Pacu**](https://github.com/RhinoSecurityLabs/pacu/blob/79cd7d58f7bff5693c6ae73b30a8455df6136cca/pacu/modules/iam__detect_honeytokens/main.py#L57)には、キーが[**Canarytokens**](https://canarytokens.org/generate)**、** [**SpaceCrab**](https://bitbucket.org/asecurityteam/spacecrab/issues?status=new&status=open)**、** [**SpaceSiren**](https://github.com/spacesiren/spacesiren)**に属するかどうかを検出するためのいくつかのルールがあります：**
|
||||
|
||||
- **`canarytokens.org`**がロール名に表示されるか、アカウントID **`534261010715`**がエラーメッセージに表示される場合。
|
||||
- **`canarytokens.org`**がロール名に表示される場合、またはエラーメッセージにアカウントID **`534261010715`**が表示される場合。
|
||||
- 最近テストしたところ、彼らはアカウント**`717712589309`**を使用しており、名前に**`canarytokens.com`**の文字列がまだ含まれています。
|
||||
- エラーメッセージのロール名に**`SpaceCrab`**が表示される場合。
|
||||
- **SpaceSiren**はユーザー名を生成するために**uuids**を使用します：`[a-f0-9]{8}-[a-f0-9]{4}-4[a-f0-9]{3}-[89aAbB][a-f0-9]{3}-[a-f0-9]{12}`
|
||||
@@ -162,7 +162,7 @@ Honeytokensは**機密情報の流出を検出するために作成されます*
|
||||
|
||||
#### キーIDからアカウントIDを取得する
|
||||
|
||||
**アクセスキー**内に**エンコードされた**アカウントIDを取得することができ、[**ここで説明されているように**](https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489)そのアカウントIDをHoneytokens AWSアカウントのリストと照合してください：
|
||||
**アクセスキー**内の**エンコードされた**情報から**アカウントID**を取得でき、[**ここで説明されているように**](https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489)そのアカウントIDをHoneytokens AWSアカウントのリストと照合できます：
|
||||
```python
|
||||
import base64
|
||||
import binascii
|
||||
@@ -181,34 +181,34 @@ return (e)
|
||||
|
||||
print("account id:" + "{:012d}".format(AWSAccount_from_AWSKeyID("ASIAQNZGKIQY56JQ7WML")))
|
||||
```
|
||||
Check more information in the [**orginal research**](https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489).
|
||||
[**元の研究**](https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489)で詳細情報を確認してください。
|
||||
|
||||
#### ログを生成しない
|
||||
|
||||
最も効果的な手法は実際にはシンプルなものです。見つけたキーを使用して、自分の攻撃者アカウント内のサービスにアクセスします。これにより、**CloudTrailはあなた自身のAWSアカウント内にログを生成し、被害者のアカウント内には生成しません**。
|
||||
このための最も効果的な手法は実際にはシンプルです。見つけたキーを使用して、自分の攻撃者アカウント内のサービスにアクセスします。これにより、**CloudTrailはあなた自身のAWSアカウント内にログを生成し、被害者のアカウント内には生成しません**。
|
||||
|
||||
出力には、アカウントIDとアカウント名を示すエラーが表示されるため、**それがHoneytokenであるかどうかを確認できます**。
|
||||
問題は、出力にアカウントIDとアカウント名を示すエラーが表示されるため、**それがハニートークンであるかどうかを確認できることです**。
|
||||
|
||||
#### ログなしのAWSサービス
|
||||
|
||||
過去には、**CloudTrailにログを送信しないAWSサービスがいくつかありました**（ここに[リストを見つけてください](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-unsupported-aws-services.html)）。これらのサービスのいくつかは、無許可の者（ハニートークンキー）がアクセスしようとすると、**キー役割のARNを含む**エラーで**応答**します。
|
||||
過去には、**CloudTrailにログを送信しないAWSサービスがいくつかありました**（[こちらにリストがあります](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-unsupported-aws-services.html)）。これらのサービスのいくつかは、無許可の者（ハニートークンキー）がアクセスしようとすると、**キー役割のARNを含む**エラーで**応答**します。
|
||||
|
||||
この方法で、**攻撃者はログをトリガーすることなくキーのARNを取得できます**。ARNには**AWSアカウントIDと名前**が表示されるため、ハニートークンの企業アカウントIDと名前を知るのは簡単で、攻撃者はトークンがハニートークンであるかどうかを特定できます。
|
||||
この方法で、**攻撃者はログをトリガーすることなくキーのARNを取得できます**。ARNには**AWSアカウントIDと名前**が表示されるため、ハニートークンの企業アカウントIDと名前を知るのは簡単です。このようにして、攻撃者はトークンがハニートークンであるかどうかを特定できます。
|
||||
|
||||
.png>)
|
||||
|
||||
> [!CAUTION]
|
||||
> CloudTrailログを生成しないことが発見されたすべての公開APIは現在修正されているため、自分で見つける必要があるかもしれません...
|
||||
>
|
||||
> 詳細については、[**original research**](https://rhinosecuritylabs.com/aws/aws-iam-enumeration-2-0-bypassing-cloudtrail-logging/)を確認してください。
|
||||
> 詳細情報は[**元の研究**](https://rhinosecuritylabs.com/aws/aws-iam-enumeration-2-0-bypassing-cloudtrail-logging/)を確認してください。
|
||||
|
||||
### 第三者インフラへのアクセス
|
||||
|
||||
特定のAWSサービスは、**データベース**や**Kubernetes**クラスター（EKS）などの**インフラを生成します**。ユーザーがこれらのサービス（Kubernetes APIなど）に直接話しかける場合、**AWS APIを使用しないため**、CloudTrailはこの通信を確認できません。
|
||||
特定のAWSサービスは、**データベース**や**Kubernetes**クラスター（EKS）などの**インフラを生成します**。ユーザーがこれらのサービス（Kubernetes APIなど）に**直接話しかける**場合、**AWS APIを使用しないため**、CloudTrailはこの通信を確認できません。
|
||||
|
||||
したがって、EKSにアクセスできるユーザーがEKS APIのURLを発見した場合、ローカルでトークンを生成し、**CloudTrailに検出されることなくAPIサービスに直接話しかけることができます**。
|
||||
|
||||
詳細は以下に：
|
||||
詳細情報は以下にあります：
|
||||
|
||||
{{#ref}}
|
||||
../../aws-post-exploitation/aws-eks-post-exploitation.md
|
||||
|
||||
@@ -15,7 +15,7 @@ CloudWatch Log Event には、**各ログ行のサイズ制限が256KB** があ
|
||||
- IAM および S3 内のセキュリティポリシーの変更
|
||||
- AWS Management Console へのログイン試行の失敗
|
||||
- 認証に失敗した API コール
|
||||
- CloudWatch での検索フィルター: [https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html)
|
||||
- CloudWatch で検索するためのフィルター: [https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html)
|
||||
|
||||
## Key concepts
|
||||
|
||||
@@ -47,7 +47,7 @@ CloudWatch Log Event には、**各ログ行のサイズ制限が256KB** があ
|
||||
|
||||
単位は、メトリクスに関連付けられた測定タイプです。単位は、メトリクスデータにコンテキストと意味を提供するのに役立ちます。一般的な単位には、パーセント、バイト、秒、カウントが含まれます。
|
||||
|
||||
- **例**: CPUUtilization はパーセントで測定される場合があり、NetworkIn はバイトで測定される場合があります。
|
||||
- **例**: CPUUtilization はパーセントで測定される場合がありますが、NetworkIn はバイトで測定される場合があります。
|
||||
|
||||
## CloudWatch Features
|
||||
|
||||
@@ -68,33 +68,33 @@ CloudWatch Log Event には、**各ログ行のサイズ制限が256KB** があ
|
||||
|
||||
AWS CloudWatch の **Metric Streams** は、CloudWatch メトリクスを選択した宛先にほぼリアルタイムで継続的にストリーミングすることを可能にします。これは、AWS の外部ツールを使用した高度な監視、分析、およびカスタムダッシュボードに特に便利です。
|
||||
|
||||
**Metric Streams 内のメトリクスデータ** は、ストリーミングされている実際の測定値またはデータポイントを指します。これらのデータポイントは、AWS リソースの CPU 利用率、メモリ使用量など、さまざまなメトリクスを表します。
|
||||
**Metric Data** は、Metric Streams 内の実際の測定値またはデータポイントを指します。これらのデータポイントは、AWS リソースの CPU 利用率、メモリ使用量など、さまざまなメトリクスを表します。
|
||||
|
||||
**例の使用ケース**:
|
||||
|
||||
- 高度な分析のために、リアルタイムメトリクスをサードパーティの監視サービスに送信する。
|
||||
- 長期保存およびコンプライアンスのために、Amazon S3 バケットにメトリクスをアーカイブする。
|
||||
- 長期保存とコンプライアンスのために、Amazon S3 バケットにメトリクスをアーカイブする。
|
||||
|
||||
### Alarm
|
||||
|
||||
**CloudWatch Alarms** は、メトリクスを監視し、事前に定義された閾値に基づいてアクションを実行します。メトリクスが閾値を超えると、アラームは SNS 経由で通知を送信したり、オートスケーリングポリシーをトリガーしたり、AWS Lambda 関数を実行したりするなど、1 つ以上のアクションを実行できます。
|
||||
|
||||
**主要コンポーネント**:
|
||||
**主なコンポーネント**:
|
||||
|
||||
- **閾値**: アラームがトリガーされる値。
|
||||
- **評価期間**: データが評価される期間の数。
|
||||
- **アラームに必要なデータポイント**: アラームをトリガーするために到達した閾値のある期間の数。
|
||||
- **アクション**: アラーム状態がトリガーされたときに何が起こるか（例: SNS 経由で通知）。
|
||||
- **アラームに必要なデータポイント**: アラームをトリガーするために必要な閾値に達した期間の数。
|
||||
- **アクション**: アラーム状態がトリガーされたときに何が起こるか（例：SNS 経由で通知）。
|
||||
|
||||
**例の使用ケース**:
|
||||
|
||||
- EC2 インスタンスの CPU 利用率を監視し、5 分間連続して 80% を超えた場合に SNS 経由で通知を送信する。
|
||||
- EC2 インスタンスの CPU 利用率を監視し、5 分間 80% を超えた場合に SNS 経由で通知を送信する。
|
||||
|
||||
### Anomaly Detectors
|
||||
|
||||
**Anomaly Detectors** は、機械学習を使用してメトリクスの異常を自動的に検出します。異常検出を任意の CloudWatch メトリクスに適用して、問題を示す可能性のある通常のパターンからの逸脱を特定できます。
|
||||
|
||||
**主要コンポーネント**:
|
||||
**主なコンポーネント**:
|
||||
|
||||
- **モデルのトレーニング**: CloudWatch は、過去のデータを使用してモデルをトレーニングし、正常な動作がどのようなものかを確立します。
|
||||
- **異常検出バンド**: メトリクスの期待される値の範囲を視覚的に表現したもの。
|
||||
@@ -105,28 +105,28 @@ AWS CloudWatch の **Metric Streams** は、CloudWatch メトリクスを選択
|
||||
|
||||
### Insight Rules and Managed Insight Rules
|
||||
|
||||
**Insight Rules** は、メトリクスデータ内のトレンドを特定し、スパイクやその他の興味深いパターンを検出するために、**強力な数学的表現**を使用してアクションを実行すべき条件を定義します。これらのルールは、リソースのパフォーマンスや利用状況における異常や異常な動作を特定するのに役立ちます。
|
||||
**Insight Rules** は、**強力な数学的表現**を使用してメトリクスデータ内のトレンド、スパイク、またはその他の興味深いパターンを特定することを可能にします。これらのルールは、リソースのパフォーマンスと利用状況における異常や異常な動作を特定するのに役立ちます。
|
||||
|
||||
**Managed Insight Rules** は、AWS によって提供される事前構成された **インサイトルール** です。特定の AWS サービスや一般的な使用ケースを監視するように設計されており、詳細な構成なしで有効にできます。
|
||||
|
||||
**例の使用ケース**:
|
||||
|
||||
- RDS パフォーマンスの監視: CPU 利用率、メモリ使用量、ディスク I/O などの主要なパフォーマンス指標を監視する Amazon RDS 用の管理インサイトルールを有効にします。これらのメトリクスのいずれかが安全な運用閾値を超えた場合、ルールはアラートや自動的な緩和アクションをトリガーできます。
|
||||
- RDS パフォーマンスの監視: CPU 利用率、メモリ使用量、ディスク I/O などの主要なパフォーマンス指標を監視する Amazon RDS の管理インサイトルールを有効にします。これらのメトリクスのいずれかが安全な運用閾値を超えた場合、ルールはアラートまたは自動緩和アクションをトリガーできます。
|
||||
|
||||
### CloudWatch Logs <a href="#cloudwatch-logs" id="cloudwatch-logs"></a>
|
||||
|
||||
アプリケーションやシステムからの **ログを集約および監視** することを可能にし、**AWSサービス**（CloudTrail を含む）や **アプリ/システム** からのログを集約します（**CloudWatch Agent** をホストにインストールできます）。ログは **無期限に保存** でき（ロググループの設定に依存）、エクスポートできます。
|
||||
アプリケーションやシステムからの **ログを集約および監視** することを可能にします。**AWSサービス**（CloudTrail を含む）および **アプリ/システム** からのログ（**CloudWatch Agent** をホストにインストールできます）。ログは **無期限に保存** でき（ロググループの設定に依存）、エクスポートできます。
|
||||
|
||||
**要素**:
|
||||
|
||||
| **ロググループ** | 同じ保持、監視、およびアクセス制御設定を共有する **ログストリームのコレクション** |
|
||||
| 用語 | 定義 |
|
||||
| ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **ログストリーム** | **同じソース**を共有する **ログイベント** のシーケンス |
|
||||
| **サブスクリプションフィルター** | 特定のロググループ内のイベントに一致する **フィルターパターンを定義し**、それらを Kinesis Data Firehose ストリーム、Kinesis ストリーム、または Lambda 関数に送信します |
|
||||
| **ロググループ** | 同じ保持、監視、およびアクセス制御設定を共有する **ログストリームのコレクション** |
|
||||
| **ログストリーム** | **同じソース**を共有する **ログイベントのシーケンス** |
|
||||
| **サブスクリプションフィルター** | 特定のロググループ内のイベントに一致する **フィルターパターンを定義し**、それらを Kinesis Data Firehose ストリーム、Kinesis ストリーム、または Lambda 関数に送信します。 |
|
||||
|
||||
### CloudWatch Monitoring & Events
|
||||
|
||||
CloudWatch の **基本** は、データを **5 分ごと** に集約します（**詳細** は **1 分ごと** に集約します）。集約後、アラームの閾値を **チェック** し、トリガーする必要があるかどうかを確認します。\
|
||||
CloudWatch の **基本** は、データを **5 分ごとに集約** します（**詳細** は **1 分ごとに** 行います）。集約後、アラームの閾値を **チェック** し、トリガーが必要かどうかを確認します。\
|
||||
その場合、CloudWatch はイベントを送信し、自動アクション（AWS Lambda 関数、SNS トピック、SQS キュー、Kinesis ストリーム）を実行する準備ができます。
|
||||
|
||||
### Agent Installation
|
||||
@@ -134,7 +134,7 @@ CloudWatch の **基本** は、データを **5 分ごと** に集約します
|
||||
マシン/コンテナ内にエージェントをインストールして、ログを自動的に CloudWatch に送信できます。
|
||||
|
||||
- **ロールを作成**し、**インスタンスに添付**して、CloudWatch がインスタンスからデータを収集し、AWS Systems Manager SSM と対話できるようにする権限を付与します（CloudWatchAgentAdminPolicy & AmazonEC2RoleforSSM）。
|
||||
- **エージェントをダウンロード**し、**EC2 インスタンスにインストール**します ([https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip](https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip))。EC2 内からダウンロードするか、AWS Systems Manager を使用して自動的にインストールできます。パッケージ AWS-ConfigureAWSPackage を選択します。
|
||||
- **エージェントをダウンロード**し、**EC2 インスタンスにインストール**します ([https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip](https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip))。EC2 内からダウンロードするか、AWS Systems Manager を使用して自動的にインストールすることができます。パッケージ AWS-ConfigureAWSPackage を選択します。
|
||||
- **CloudWatch Agent を構成**し、**起動**します。
|
||||
|
||||
ロググループには多くのストリームがあります。ストリームには多くのイベントがあります。そして、各ストリーム内のイベントは順序が保証されています。
|
||||
@@ -212,13 +212,13 @@ aws events describe-event-source --name <name>aws events list-replays
|
||||
aws events list-api-destinations
|
||||
aws events list-event-buses
|
||||
```
|
||||
## ポストエクスプロイテーション / バイパス
|
||||
## Post-Exploitation / Bypass
|
||||
|
||||
### **`cloudwatch:DeleteAlarms`,`cloudwatch:PutMetricAlarm` , `cloudwatch:PutCompositeAlarm`**
|
||||
|
||||
この権限を持つ攻撃者は、組織の監視およびアラートインフラストラクチャを大幅に損なう可能性があります。既存のアラームを削除することで、攻撃者は管理者に重要なパフォーマンスの問題、セキュリティ侵害、または運用の失敗を通知する重要なアラートを無効にすることができます。さらに、メトリックアラームを作成または変更することで、攻撃者は誤ったアラートで管理者を誤導したり、正当なアラームを無効にしたりすることができ、悪意のある活動を隠蔽し、実際のインシデントに対する迅速な対応を妨げることができます。
|
||||
|
||||
さらに、**`cloudwatch:PutCompositeAlarm`** 権限を持つ攻撃者は、コンポジットアラームAがコンポジットアラームBに依存し、コンポジットアラームBもコンポジットアラームAに依存するようなコンポジットアラームのループまたはサイクルを作成することができます。このシナリオでは、サイクルの一部であるコンポジットアラームを削除することは不可能です。なぜなら、削除したいアラームに依存するコンポジットアラームが常に存在するからです。
|
||||
さらに、**`cloudwatch:PutCompositeAlarm`** 権限を持つ攻撃者は、複合アラームAが複合アラームBに依存し、複合アラームBも複合アラームAに依存するような複合アラームのループまたはサイクルを作成することができます。このシナリオでは、サイクルの一部である複合アラームを削除することは不可能です。なぜなら、削除したいアラームに依存する複合アラームが常に存在するからです。
|
||||
```bash
|
||||
aws cloudwatch put-metric-alarm --cli-input-json <value> | --alarm-name <value> --comparison-operator <value> --evaluation-periods <value> [--datapoints-to-alarm <value>] [--threshold <value>] [--alarm-description <value>] [--alarm-actions <value>] [--metric-name <value>] [--namespace <value>] [--statistic <value>] [--dimensions <value>] [--period <value>]
|
||||
aws cloudwatch delete-alarms --alarm-names <value>
|
||||
@@ -227,7 +227,7 @@ aws cloudwatch put-composite-alarm --alarm-name <value> --alarm-rule <value> [--
|
||||
次の例は、メトリックアラームを無効にする方法を示しています：
|
||||
|
||||
- このメトリックアラームは、特定のEC2インスタンスの平均CPU使用率を監視し、300秒ごとにメトリックを評価し、6つの評価期間（合計30分）を必要とします。平均CPU使用率がこれらの期間のうち少なくとも4つで60%を超えると、アラームがトリガーされ、指定されたSNSトピックに通知が送信されます。
|
||||
- 閾値を99%を超えるように変更し、期間を10秒に設定し、評価期間を8640（8640期間の10秒は1日に相当）に設定し、アラームのデータポイントも8640に設定すると、CPU使用率が24時間全体で10秒ごとに99%を超える必要があり、アラームがトリガーされます。
|
||||
- 閾値を99%を超えるように変更し、期間を10秒に設定し、評価期間を8640（8640期間の10秒は1日に相当）に設定し、アラームのデータポイントも8640に設定すると、アラームをトリガーするには、CPU使用率が24時間全体で10秒ごとに99%を超える必要があります。
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Original Metric Alarm" }}
|
||||
@@ -254,7 +254,7 @@ aws cloudwatch put-composite-alarm --alarm-name <value> --alarm-rule <value> [--
|
||||
```
|
||||
{{#endtab }}
|
||||
|
||||
{{#tab name="修正されたメトリックアラーム" }}
|
||||
{{#tab name="Modified Metric Alarm" }}
|
||||
```json
|
||||
{
|
||||
"Namespace": "AWS/EC2",
|
||||
@@ -279,13 +279,13 @@ aws cloudwatch put-composite-alarm --alarm-name <value> --alarm-rule <value> [--
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**潜在的な影響**: 重要なイベントの通知がない、潜在的な未検出の問題、誤警報、正当な警報の抑制、実際のインシデントの検出を見逃す可能性。
|
||||
**潜在的な影響**: 重要なイベントに対する通知の欠如、潜在的な未検出の問題、誤警報、正当な警報の抑制、そして実際のインシデントの検出を見逃す可能性。
|
||||
|
||||
### **`cloudwatch:DeleteAlarmActions`, `cloudwatch:EnableAlarmActions` , `cloudwatch:SetAlarmState`**
|
||||
|
||||
アラームアクションを削除することで、攻撃者はアラーム状態に達したときに管理者への通知や自動スケーリング活動のトリガーなど、重要な警報や自動応答が発動するのを防ぐことができます。不適切にアラームアクションを有効化または再有効化することも、以前に無効化されたアクションを再活性化したり、どのアクションがトリガーされるかを変更したりすることで、予期しない動作を引き起こし、インシデント対応において混乱や誤方向を招く可能性があります。
|
||||
アラームアクションを削除することで、攻撃者はアラーム状態に達したときに管理者への通知や自動スケーリング活動のトリガーなど、重要な警告や自動応答が発動するのを防ぐことができます。不適切にアラームアクションを有効化または再有効化することも、以前に無効化されたアクションを再活性化したり、どのアクションがトリガーされるかを変更したりすることで、予期しない動作を引き起こし、インシデント対応において混乱や誤方向を招く可能性があります。
|
||||
|
||||
さらに、権限を持つ攻撃者はアラーム状態を操作し、管理者を混乱させるために偽のアラームを作成したり、進行中の悪意のある活動や重大なシステム障害を隠すために正当なアラームを無効にしたりすることができます。
|
||||
さらに、権限を持つ攻撃者はアラーム状態を操作し、管理者を気を散らせたり混乱させたりするために偽のアラームを作成したり、進行中の悪意のある活動や重大なシステム障害を隠すために正当なアラームを無効にしたりすることができます。
|
||||
|
||||
- **`SetAlarmState`** をコンポジットアラームで使用すると、コンポジットアラームが実際の状態に戻ることは保証されません。子アラームのいずれかが状態を変更したときにのみ、実際の状態に戻ります。また、設定を更新すると再評価されます。
|
||||
```bash
|
||||
@@ -323,7 +323,7 @@ aws cloudwatch put-anomaly-detector [--cli-input-json <value> | --namespace <val
|
||||
```
|
||||
{{#endtab }}
|
||||
|
||||
{{#tab name="修正されたメトリック異常検出器" }}
|
||||
{{#tab name="Modified Metric Anomaly Detector" }}
|
||||
```json
|
||||
{
|
||||
"SingleMetricAnomalyDetector": {
|
||||
@@ -360,7 +360,7 @@ aws cloudwatch put-anomaly-detector [--cli-input-json <value> | --namespace <val
|
||||
aws cloudwatch delete-dashboards --dashboard-names <value>
|
||||
aws cloudwatch put-dashboard --dashboard-name <value> --dashboard-body <value>
|
||||
```
|
||||
**潜在的影響**: 監視の可視性の喪失と誤解を招く情報。
|
||||
**潜在的な影響**: 監視の可視性の喪失と誤解を招く情報。
|
||||
|
||||
### **`cloudwatch:DeleteInsightRules`, `cloudwatch:PutInsightRule` ,`cloudwatch:PutManagedInsightRule`**
|
||||
|
||||
@@ -370,7 +370,7 @@ aws cloudwatch delete-insight-rules --rule-names <value>
|
||||
aws cloudwatch put-insight-rule --rule-name <value> --rule-definition <value> [--rule-state <value>]
|
||||
aws cloudwatch put-managed-insight-rules --managed-rules <value>
|
||||
```
|
||||
**潜在的影響**: パフォーマンスの問題や異常を検出し対応するのが難しくなり、誤った意思決定を引き起こし、悪意のある活動やシステムの障害を隠す可能性があります。
|
||||
**潜在的な影響**: パフォーマンスの問題や異常を検出し対応するのが難しくなり、誤った意思決定を引き起こし、悪意のある活動やシステムの障害を隠す可能性があります。
|
||||
|
||||
### **`cloudwatch:DisableInsightRules`, `cloudwatch:EnableInsightRules`**
|
||||
|
||||
@@ -383,11 +383,11 @@ aws cloudwatch enable-insight-rules --rule-names <value>
|
||||
|
||||
### **`cloudwatch:DeleteMetricStream` , `cloudwatch:PutMetricStream` , `cloudwatch:PutMetricData`**
|
||||
|
||||
**`cloudwatch:DeleteMetricStream`** 、 **`cloudwatch:PutMetricStream`** の権限を持つ攻撃者は、メトリックデータストリームを作成および削除でき、セキュリティ、監視、データの整合性が損なわれる可能性があります：
|
||||
**`cloudwatch:DeleteMetricStream`** 、**`cloudwatch:PutMetricStream`** の権限を持つ攻撃者は、メトリックデータストリームを作成および削除でき、セキュリティ、監視、データの整合性が損なわれる可能性があります：
|
||||
|
||||
- **悪意のあるストリームの作成**: 機密データを不正な宛先に送信するメトリックストリームを作成する。
|
||||
- **リソースの操作**: 過剰なデータを持つ新しいメトリックストリームの作成は、多くのノイズを生み出し、誤ったアラートを引き起こし、真の問題を隠す可能性があります。
|
||||
- **監視の中断**: メトリックストリームを削除することで、攻撃者は監視データの継続的な流れを中断させます。このようにして、彼らの悪意のある活動は効果的に隠されます。
|
||||
- **リソースの操作**: 過剰なデータを持つ新しいメトリックストリームの作成は、多くのノイズを生じさせ、誤ったアラートを引き起こし、真の問題を隠す可能性があります。
|
||||
- **監視の中断**: メトリックストリームを削除することで、攻撃者は監視データの継続的な流れを妨害します。このようにして、彼らの悪意のある活動は効果的に隠されます。
|
||||
|
||||
同様に、**`cloudwatch:PutMetricData`** の権限を持つことで、メトリックストリームにデータを追加することが可能になります。これにより、不適切なデータの量が原因でDoSが発生し、完全に無用になる可能性があります。
|
||||
```bash
|
||||
@@ -395,11 +395,11 @@ aws cloudwatch delete-metric-stream --name <value>
|
||||
aws cloudwatch put-metric-stream --name <value> [--include-filters <value>] [--exclude-filters <value>] --firehose-arn <value> --role-arn <value> --output-format <value>
|
||||
aws cloudwatch put-metric-data --namespace <value> [--metric-data <value>] [--metric-name <value>] [--timestamp <value>] [--unit <value>] [--value <value>] [--dimensions <value>]
|
||||
```
|
||||
特定のEC2インスタンスに対するCPU使用率の70%に対応するデータを追加する例:
|
||||
EC2インスタンスのCPU使用率が70%に相当するデータを追加する例:
|
||||
```bash
|
||||
aws cloudwatch put-metric-data --namespace "AWS/EC2" --metric-name "CPUUtilization" --value 70 --unit "Percent" --dimensions "InstanceId=i-0123456789abcdefg"
|
||||
```
|
||||
**潜在的影響**: 監視データの流れの中断、異常やインシデントの検出への影響、リソースの操作、過剰なメトリックストリームの作成によるコストの増加。
|
||||
**潜在的な影響**: 監視データの流れの中断により、異常やインシデントの検出、リソースの操作、過剰なメトリックストリームの作成によるコストの増加に影響を与える。
|
||||
|
||||
### **`cloudwatch:StopMetricStreams`, `cloudwatch:StartMetricStreams`**
|
||||
|
||||
|
||||
Reference in New Issue
Block a user