CISAWS基礎ベンチマークコントロール - AWS Security Hub
1.1 —「ルート」アカウントの使用を避ける1.2 — コンソールパスワードを持つすべての IAM ユーザーに対して多要素認証 (MFA) が有効になっていることを確認します 1.3 — 90 日間以上使用されていない認証情報は無効にします。1.4 — アクセスキーは 90 日ごとに更新します。1.5 — IAM パスワードポリシーには少なくとも 1 つの大文字が必要です1.6 — IAM パスワードポリシーには少なくとも 1 つの小文字が必要です1.7 — IAM パスワードポリシーには少なくとも 1 つの記号が必要です1.8 — IAM パスワードポリシーには少なくとも 1 つの数字が必要です1.9 — IAM パスワードポリシーでは 14 文字以上の長さが必要です1.10 — IAM パスワードポリシーがパスワードの再使用を禁止しています1.11 — IAM パスワードポリシーでは、パスワードが 90 日以内に有効期限が切れます1.12 — ルートアカウントのアクセスキーが存在しないことを確認します1.13 —「ルート」アカウントで MFA を有効にします 1.14 —「ルート」アカウントでハードウェア MFA を有効にします。1.16 — IAM ポリシーがグループまたはロールにのみアタッチされます。1.20 - AWS でインシデントを管理するためのサポートロールが作成されていることを確認します。1.22 — 完全な「*: *」管理権限を許可する IAM ポリシーが作成されていないことを確認します 2.1 — CloudTrail がすべてのリージョンで有効になっていることを確認します2.2. — CloudTrail ログファイルの検証が有効になっていることを確認します 2.3 — CloudTrail ログに記録する S3 バケットがパブリックアクセスできないことを確認します2.4 — CloudTrail トレイルが Amazon CloudWatch Logs と統合されていることを確認する2.5 — 確認AWS Configが有効である2.6 — CloudTrail S3 バケットで S3 バケットアクセスログ記録が有効になっていることを確認します 2.7 — CloudTrail ログが保管時に、を使用して暗号化されていることを確認しますAWS KMS keys2.8 — カスタマー作成の KMS キーのローテーションが有効になっていることを確認します2.9 — すべての VPC で VPC フローログ記録が有効になっていることを確認します 3.1 — 不正な API 呼び出しに対してログメトリクスフィルターとアラームが存在することを確認します 3.2 — ログメトリクスフィルターとアラームが存在することを確認します。AWS Management ConsoleMFA なしでサインイン 3.3 —「ルート」アカウントの使用に対するメトリクスフィルターとアラームが存在することを確認します 3.4 — IAM ポリシーの変更に対してログメトリクスフィルターとアラームが存在することを確認します 3.5 — CloudTrail の設定の変更に対してログメトリクスフィルターとアラームが存在することを確認します 3.6 — ログメトリクスフィルターとアラームが存在することを確認しますAWS Management Console認証の失敗 3.7 — カスタマー管理キーの無効化またはスケジュールされた削除に対してログメトリクスフィルタとアラームが存在することを確認します 3.8 — S3 バケットの変更に対するメトリクスフィルターとアラームが存在することを確認します3.9 — ログメトリクスフィルターとアラームが存在することを確認しますAWS Config設定変更 3.10 — セキュリティグループの変更に対するメトリクスフィルターとアラームが存在することを確認します 3.11 — ネットワークアクセスコントロールリスト (NACL) への変更に対するログメトリクスとアラームが存在することを確認します3.12 — ネットワークゲートウェイへの変更に対するログメトリクスフィルターとアラームが存在することを確認します 3.13 — ルートテーブルの変更に対してログメトリクスフィルターとアラームが存在することを確認します 3.14 — VPC の変更に対してログメトリクスフィルターとアラームが存在することを確認します 4.1 — どのセキュリティグループでも 0.0.0.0/0 からポート 22 への入力を許可しないようにします 4.2 — どのセキュリティグループでも 0.0.0.0/0 からポート 3389 への入力を許可しないようにします 4.3 — すべての VPC のデフォルトセキュリティグループがすべてのトラフィックを制限するようにします

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

CISAWS基礎ベンチマークコントロール

CIS の場合AWSFoundations Standard、Security Hub は次のコントロールをサポートしています。各コントロールについて、必要な AWS Config ルールと修復手順が情報に含まれます。

1.1 —「ルート」アカウントの使用を避ける

緊急度:

AWS Configルール: なし

ルートアカウントは、AWS アカウントのすべてのリソースに無制限にアクセスできます。このアカウントを使用しないことを強くお勧めします。ルートアカウントは、最も権限があるアカウントです。このアカウントの使用を最低限にし、アクセス管理の最小権限の原則を採用することで権限の高い認証情報の意図しない変更や偶発的な開示のリスクが軽減されます。

ベストプラクティスとしては、ルート認証情報を使用して、アカウントおよびサービス管理タスクを実行します。IAM ポリシーをグループとロールに直接適用しますが、ユーザーには直接適用しません。日常使用のために管理者を設定する方法のチュートリアルについては、を参照してください。最初の IAM 管理者のユーザーおよびグループの作成IAM ユーザーガイド

このチェックを実行するために、Security Hub はカスタムロジックを使用して、のコントロール 3.3 に規定された正確な監査手順を実行します。CISAWS基礎ベンチマーク v1.2。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

注記

Security Hub がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡が検索されます。これらの証跡は、別のアカウントに属する組織の証跡である可能性があります。マルチリージョンの証跡は、別のリージョンに基づいている場合もあります。

チェックの結果はFAILED以下の場合における知見。

  • トレイルは設定されていません。

  • 現在のリージョンにあり、現在のアカウントが所有している利用可能な証跡は、管理要件を満たしていません。

チェックの結果、制御ステータスはNO_DATA以下の場合は、

  • マルチリージョンの証跡は、別のリージョンに基づいています。Security Hub は、証跡のベースとなるリージョンでのみ結果を生成できます。

  • マルチリージョンの証跡は、別のアカウントに属しています。Security Hub は、証跡を所有するアカウントの調査結果のみを生成できます。

アラームの場合、現在のアカウントが参照されている Amazon SNS トピックを所有しているか、listSubscriptionAmazon SNS トピックへのアクセス。それ以外の場合は、Security HubWARNINGコントロールの所見。

Remediation

この問題を修正するためのステップには、Amazon SNS トピック、CloudTrail 証跡、メトリクスフィルター、およびメトリクスフィルターのアラームの設定が含まれます。

Amazon SNS トピックを作成する

  1. Amazon SNS コンソール(https://console.aws.amazon.com/sns/v3/home)を開きます。

  2. すべての CIS アラームを受信する Amazon SNS トピックを作成します。

    トピックに少なくとも 1 人の受信者を作成します。詳細については、「」を参照してください。Amazon SNS の開始方法Amazon Simple Notification Service デベロッパーガイド

次に、すべてのリージョンに適用されるアクティブなCloudTrail をセットアップします。これを行うには、2.1 — CloudTrail がすべてのリージョンで有効になっていることを確認します の修正手順に従います。

CloudTrail 証跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。そのロググループのメトリックスフィルタを作成します。

最後に、メトリクスフィルターとアラームを作成します。

メトリクスフィルターとアラームを作成するには

  1. CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。

  2. ナビゲーションペインで、[Log groups] (ロググループ) を選択します。

  3. 作成した CloudTrail 証跡に関連付けられている CloudWatch Logs ロググループのチェックボックスをオンにします。

  4. 送信元アクションで、メトリクスフィルターの作成

  5. []パターンを定義する] で、次の作業を行います。

    1. 次のパターンをコピーして、[Filter Pattern (フィルターパターン)] フィールドに貼り付けます。

      {$.userIdentity.type="Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType !="AwsServiceEvent"}
    2. [次へ] を選択します。

  6. []メトリクスの割り当て] で、次の作業を行います。

    1. Eclipseフィルタ名で、メトリクスフィルタの名前を入力します。

    2. を使用する場合メトリクス名前空間「」と入力します。LogMetrics

      すべての CIS ログメトリックフィルタに同じ名前空間を使用する場合、すべての CIS Benchmark メトリックがグループ化されます。

    3. を使用する場合メトリクス名で、メトリックスの名前を入力します。メトリクスの名前を覚えておいてください。アラームの作成時にメトリクスを選択する必要があります。

    4. [メトリクス値] に「1」と入力します。

    5. [次へ] を選択します。

  7. []確認と作成で、新しいメトリックフィルタに入力した情報を確認します。次に [] を選択します。メトリクスフィルターの作成

  8. ナビゲーションペインで、[Alarms] を選択します。

  9. [Create Alarm (アラーム作成)] を選択します。

  10. []メトリックと条件の指定] で、次の作業を行います。

    1. [メトリクスの選択] を選択します。

    2. リポジトリの []メトリクスの選択パネル、すべてのメトリクス[] タブで、[]LogMetrics名前空間. 検索バーを使用して検索できます。

    3. [範囲の定められていないメトリクス] を選択します。

    4. 作成したメトリクスのチェックボックスをオンにします。次に [メトリクスの選択] を選択します。

    5. []メトリクスで、値をデフォルトのままにしておきます。

    6. []条件、に対してThresholdで、静的

    7. を使用する場合アラーム条件を定義します。で、以上

    8. を使用する場合しきい値を定義します。「」と入力します。1

    9. [次へ] を選択します。

  11. []アクションの設定] で、次の作業を行います。

    1. []アラームの状態で、のアラーム

    2. [SNS トピックの選択] で、[既存の SNS トピックの選択] を選択します。

    3. を使用する場合通知の送信先で、前の手順で作成した SNS トピックの名前を入力します。

    4. [次へ] を選択します。

  12. [][Name (名前)] と「」と入力します。名前および説明アラームの場合、などCIS-1.1-RootAccountUsage。続いて、[次へ] を選択します。

  13. []プレビューと作成で、アラーム設定を確認します。次に [アラームの作成] を選択します。

1.2 — コンソールパスワードを持つすべての IAM ユーザーに対して多要素認証 (MFA) が有効になっていることを確認します

緊急度: ミディアム

AWS Config ルール: mfa-enabled-for-iam-console-access

多要素認証 (MFA) はユーザー名とパスワードの上に、もう 1 つの保護レイヤーを追加します。MFA が有効な場合、AWS ウェブサイトにサインインするときに、ユーザー名とパスワード、および AWS MFA デバイスからの認証コードを求められます。

CIS は、コンソールパスワードを持つすべてのアカウントの MFA を有効にすることをお勧めします。MFA は、コンソールアクセスのセキュリティを強化します。認証プリンシパルは、時間に依存するキーを発行し、認証情報に関する知識を持っているデバイスを所有する必要があります。

重要

このチェックに使用される AWS Config ルールは、MFA の結果を正確にレポートするために最大 4 時間かかる場合があります。CIS セキュリティチェックが有効になった後の最初の 4 時間以内に生成された検出結果は正確ではない可能性があります。チェックのこの問題を修正してから渡すまで、最大 4 時間かかる場合があります。

Remediation

ユーザーの MFA を設定するには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [ユーザー] を選択します。

  3. MFA を設定するユーザーの [ユーザー名] を選択します。

  4. 選択セキュリティ認証情報[] を選択して [] を選択します管理の隣にあります。MFA デバイスの割り当て

  5. [Manage MFA Device (MFA デバイスの管理)] ウィザードに従って、ご利用の環境に応じたデバイスのタイプを割り当てます。

ユーザーに MFA セットアップを委任する方法については、「」を参照してください。多要素認証の管理をに委任する方法AWSIAM ユーザーでAWSセキュリティブログ。

1.3 — 90 日間以上使用されていない認証情報は無効にします。

緊急度: ミディアム

AWS Config ルール: iam-user-unused-credentials-check

IAM ユーザーはアクセスできるAWSパスワードやアクセスキーなど、さまざまなタイプの認証情報を使用するリソース。

CISS は、90 日以上使用されていないすべての認証情報を削除または非アクティブ化することをお勧めします。不要な認証情報を無効化または削除することにより、認証情報が漏洩したり、放棄されたアカウントが使用される機会が少なくなります。

このコントロールの AWS Config ルールでは、GetCredentialReport および GenerateCredentialReport API オペレーションを使用します。API オペレーションは 4 時間ごとに更新されます。IAM ユーザーへの変更がこのコントロールに表示されるまでに最大 4 時間かかる場合があります。

Remediation

日付付きの認証情報のアカウントを監視するために必要な一部の情報を取得するには、IAM コンソールを使用します。たとえば、アカウントのユーザーを表示する場合、[Access key age (アクセスキーの古さ)]、[Password age (パスワードの古さ)]、および [Last activity (最後のアクティビティ)] の列が表示されます。これらの列の値が 90 日より大きい場合は、それらのユーザーの認証情報を無効にします。

認証情報レポートを使用してユーザーアカウントを監視し、90 日以上アクティビティのないアカウントを特定することもできます。IAM コンソールから認証情報レポートを .csv 形式でダウンロードできます。認証情報レポートの詳細については、「AWS アカウントの認証情報レポートの取得」を参照してください。

非アクティブなアカウントや使用されていない認証情報を識別したら、次のステップを使用してそれらを無効にします。

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [ユーザー] を選択します。

  3. 90 日を超えた認証情報を持つユーザーの名前を選択します。

  4. [Security credentials (セキュリティ認証情報)] を選択し、次に 90 日以上使用されていないすべてのサインイン認証情報とアクセスキーに対して [Make inactive (非アクティブにする)] を選択します。

1.4 — アクセスキーは 90 日ごとに更新します。

緊急度: ミディアム

AWS Config ルール: access-keys-rotated

アクセスキーはアクセスキー ID とシークレットアクセスキーから成り、に対するプログラムによるリクエストに署名するときに使用されますAWS。AWSユーザーがプログラムで「」を呼び出すには、独自のアクセスキーが必要です。AWSからのAWS Command Line Interface(AWS CLI)、Tools for Windows PowerShell、AWSSDK、または個々の API を使用した直接 HTTP 呼び出しAWSのサービス。

アクセスキーを定期的に更新すると、侵害されたアカウントや終了したアカウントに関連付けられているアクセスキーが使用される可能性が低くなります。アクセスキーを更新して、紛失、解読、または盗難にあった可能性のある古いキーを使用してデータにアクセスできないようにします。

注記

このコントロールは、アフリカ (ケープタウン) または EU (ミラノ) ではサポートされていません。

Remediation

アクセスキーを 90 日間以上使用しないようにするには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [ユーザー] を選択します。

  3. 90 日間を超える [Access key age (アクセスキーの古さ)] を示す各ユーザーで、[ユーザー名] を選択してそのユーザーの設定を開きます。

  4. [セキュリティ認証情報] を選択します。

  5. ユーザーの新しいキーを作成するには:

    1. [アクセスキーの作成] を選択します。

    2. キーコンテンツを保存するには、シークレットアクセスキーをダウンロードするか、[表示] を選択してページからコピーします。

    3. ユーザーに提供する安全な場所にキーを格納します。

    4. [閉じる] を選択します。

  6. 以前のキーを使用していたすべてのアプリケーションを更新し、新しいキーを使用するようにします。

  7. 以前のキーでは、[Make inactive (非アクティブにする)] を選択してアクセスキーを非アクティブにします。これで、ユーザーがそのキーを使用してリクエストを行うことはできません。

  8. すべてのアプリケーションが新しいキーで想定どおりに機能することを確認します。

  9. すべてのアプリケーションが新しいキーで想定どおりに機能することを確認したら、以前のキーを削除します。削除した後でアクセスキーを復元することはできません。

    前のキーを削除するには、行の末尾にある [X] を選択し、[削除] を選択します。

1.5 — IAM パスワードポリシーには少なくとも 1 つの大文字が必要です

緊急度: ミディアム

AWS Config ルール: iam-password-policy

パスワードポリシーは、部分的に、パスワードの複雑さの要件を適用します。IAM パスワードポリシーを使用してパスワードが別の文字セットを使用するようにします。

CIS では、パスワードポリシーでは少なくとも 1 つの大文字が必要です。パスワードの複雑さに関するポリシーを設定すると、ブルートフォースのログイン試行に対するアカウントの耐障害性が高まります。

Remediation

パスワードポリシーを変更するには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [Account settings (アカウント設定)] を選択します。

  3. [Requires at least one uppercase letter (少なくとも 1 つの大文字が必要です)] を選択し、[Apply password policy (パスワードポリシーを適用する)] を選択します。

1.6 — IAM パスワードポリシーには少なくとも 1 つの小文字が必要です

緊急度: ミディアム

AWS Config ルール: iam-password-policy

パスワードポリシーは、部分的に、パスワードの複雑さの要件を適用します。IAM パスワードポリシーを使用してパスワードが別の文字セットを使用するようにします。CIS では、パスワードポリシーでは少なくとも 1 つの小文字が必要です。パスワードの複雑さに関するポリシーを設定すると、ブルートフォースのログイン試行に対するアカウントの耐障害性が高まります。

Remediation

パスワードポリシーを変更するには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [Account settings (アカウント設定)] を選択します。

  3. [Requires at least one lowercase letter (少なくとも 1 つの小文字が必要です)] を選択し、[Apply password policy (パスワードポリシーを適用する)] を選択します。

1.7 — IAM パスワードポリシーには少なくとも 1 つの記号が必要です

緊急度: ミディアム

AWS Config ルール: iam-password-policy

パスワードポリシーは、部分的に、パスワードの複雑さの要件を適用します。IAM パスワードポリシーを使用してパスワードが別の文字セットを使用するようにします。

CIS では、パスワードポリシーでは少なくとも 1 つの記号が必要です。パスワードの複雑さに関するポリシーを設定すると、ブルートフォースのログイン試行に対するアカウントの耐障害性が高まります。

Remediation

パスワードポリシーを変更するには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [Account settings (アカウント設定)] を選択します。

  3. [Requires at least one non-alphanumeric character (少なくとも 1 つのアルファベット以外の文字が必要です)] を選択し、[Apply password policy (パスワードポリシーを適用する)] を選択します。

1.8 — IAM パスワードポリシーには少なくとも 1 つの数字が必要です

緊急度: ミディアム

AWS Config ルール: iam-password-policy

パスワードポリシーは、部分的に、パスワードの複雑さの要件を適用します。IAM パスワードポリシーを使用してパスワードが別の文字セットを使用するようにします。

CIS では、パスワードポリシーでは少なくとも 1 つの数字が必要です。パスワードの複雑さに関するポリシーを設定すると、ブルートフォースのログイン試行に対するアカウントの耐障害性が高まります。

Remediation

パスワードポリシーを変更するには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [Account settings (アカウント設定)] を選択します。

  3. [Requires at least one number (少なくとも 1 つの数字が必要です)] を選択し、[Apply password policy (パスワードポリシーを適用する)] を選択します。

1.9 — IAM パスワードポリシーでは 14 文字以上の長さが必要です

緊急度: ミディアム

AWS Config ルール: iam-password-policy

パスワードポリシーは、部分的に、パスワードの複雑さの要件を適用します。IAM パスワードポリシーを使用してパスワードが指定された最低限の長さになるようにします。

パスワードポリシーは 14 文字以上の長さが必要です。パスワードの複雑さに関するポリシーを設定すると、ブルートフォースのログイン試行に対するアカウントの耐障害性が高まります。

Remediation

パスワードポリシーを変更するには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [Account settings (アカウント設定)] を選択します。

  3. [Minimum password length (パスワードの最小長)] フィールドに、「14」と入力し、[Apply password policy (パスワードポリシーの適用)] を選択します。

1.10 — IAM パスワードポリシーがパスワードの再使用を禁止しています

緊急度:

AWS Config ルール: iam-password-policy

このコントロールは、記憶するパスワードの数が 24 に設定されているかどうかをチェックします。値が 24 でない場合、コントロールは失敗します。

IAM パスワードポリシーにより、同じユーザーによる特定のパスワードの再使用を防ぐことができます。

CIS は、パスワードポリシーでパスワードの再使用を禁止しています。パスワードの再使用を禁止すると、ブルートフォースのログイン試行に対するアカウントの耐障害性が高まります。

Remediation

パスワードポリシーを変更するには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [Account settings (アカウント設定)] を選択します。

  3. Selectパスワードの再利用を禁止[] に [] と入力します24for記憶するパスワードの数

  4. [Apply Password Policy (パスワードポリシーの適用)] をクリックします。

1.11 — IAM パスワードポリシーでは、パスワードが 90 日以内に有効期限が切れます

緊急度:

AWS Config ルール: iam-password-policy

IAM パスワードポリシーでは、パスワードを指定された日数後に更新または期限切れにすることを要求できます。

パスワードポリシーでは、パスワードは 90 日以内に期限切れになります。パスワードの有効期間を短くすると、ブルートフォースのログイン試行に対するアカウントの耐障害性が高まります。定期的にパスワードを変更することも以下のシナリオで役立ちます。

  • パスワードはユーザーが知らない間に盗まれたり漏洩する可能性があります。これは、システムの侵害、ソフトウェアの脆弱性、または内部の脅威によって発生する可能性があります。

  • 特定の企業および政府ウェブフィルターまたはプロキシサーバーは、暗号化された場合でもトラフィックを傍受し記録できます。

  • 多くの人々が仕事、E メール、個人用など多くのシステムで同じパスワードを使用しています。

  • 侵害されているエンドユーザーのワークステーションはキーストロークロガーがある可能性があります。

Remediation

パスワードポリシーを変更するには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [Account settings (アカウント設定)] を選択します。

  3. Selectパスワードの失効を許可[] に [] と入力します90forパスワードの有効期限 (日数))

  4. [Apply Password Policy (パスワードポリシーの適用)] をクリックします。

1.12 — ルートアカウントのアクセスキーが存在しないことを確認します

緊急度: 非常事態

AWS Config ルール: iam-root-access-key-check

ルートアカウントは、で最も権限があるユーザーです。AWSアカウント.AWS アクセスキーを使用すると、プログラムから指定されたアカウントにアクセスできます。

CIS では、ルートアカウントに関連付けられたすべてのアクセスキーを削除します。ルートアカウントに関連付けられたアクセスキーを削除すると、アカウントを侵害する可能性のあるベクトルを制限します。ルートアクセスキーを削除することでも、最も権限の低いロールベースのアカウントの作成と使用が促進されます。

注記

このコントロールは、アフリカ (ケープタウン) またはアジアパシフィック (大阪) ではサポートされていません。

Remediation

アクセスキーを削除するには

  1. ルート認証情報を使用してアカウントにログインします。

  2. ページの右上隅近くにあるアカウント名を選択し、[My Security Credentials (セキュリティの認証情報)] を選択します。

  3. ポップアップ警告で、[Continue to Security Credentials (セキュリティ認証情報に進む)] を選択します。

  4. [アクセスキー (アクセスキー ID とシークレットアクセスキー)] を選択します。

  5. 完全にキーを削除するには、[Delete (削除)] を選択し、次に [Yes (はい)] を選択します。削除したキーを復元することはできません。

  6. ルートユーザアクセスキーが複数ある場合は、各キーに対して手順 4 と 5 を繰り返します。

1.13 —「ルート」アカウントで MFA を有効にします

緊急度: 非常事態

AWS Config ルール: root-account-mfa-enabled

ルートアカウントは、アカウントで最も権限があるユーザーです。MFA はユーザー名とパスワードの上に、もう 1 つの保護レイヤーを追加します。MFA が有効な場合、AWS ウェブサイトにサインインするときに、ユーザー名とパスワード、および AWS MFA デバイスからの認証コードを求められます。

ルートアカウントの仮想 MFA を使用する場合、CIS は、使用するデバイスをないパーソナルデバイス。代わりに、個々の個人用デバイスからは独立して課金およびセキュリティ保護を維持できるように管理している専用のモバイルデバイス (タブレットまたは電話) を使用してください。これにより、デバイスの紛失、デバイスの下取り、またはデバイスを所有する個人が会社で採用されなくなったために MFA へのアクセスが失われるリスクが軽減されます。

注記

このコントロールは、次のリージョンではサポートされていません。

  • 中国 (北京)

  • 中国 (寧夏)

  • AWS GovCloud (米国東部)

  • AWSGovCloud (米国西部)。

Remediation

ルートアカウントの MFA を有効にするには

  1. ルート認証情報を使用してアカウントにログインします。

  2. ページの右上隅近くにあるアカウント名を選択し、[My Security Credentials (セキュリティの認証情報)] を選択します。

  3. ポップアップ警告で、[Continue to Security Credentials (セキュリティ認証情報に進む)] を選択します。

  4. [多要素認証 (MFA)] を選択します。

  5. [MFA の有効化] を選択します。

  6. MFA で使用するデバイスのタイプを選択し、[続行] を選択します。

  7. 選択に応じて適切なデバイスタイプを設定するステップを完了します。

    チェックに合格するのに最良の結果を得るためには、ハードウェアベースの認証メカニズムを選択します1.14 —「ルート」アカウントでハードウェア MFA を有効にします。

1.14 —「ルート」アカウントでハードウェア MFA を有効にします。

緊急度: 非常事態

AWS Config ルール: root-account-hardware-mfa-enabled

ルートアカウントは、アカウントで最も権限があるユーザーです。MFA はユーザー名とパスワードの上に、もう 1 つの保護レイヤーを追加します。MFA が有効な場合、AWS ウェブサイトにサインインするときに、ユーザー名とパスワード、および AWS MFA デバイスからの認証コードを求められます。

レベル 2 の場合、CIS では、ハードウェア MFA を使用してルートアカウントを保護することをお勧めします。ハードウェア MFA は 仮想 MFA よりも攻撃対象領域が小さくなっています。たとえば、ハードウェア MFAは、仮想 MFA が置かれているモバイルスマートフォンによってもたらされる攻撃対象領域はありません。

多くのアカウントでハードウェア MFA を使用すると、物流デバイス管理の問題が発生する可能性があります。このような場合は、このレベル 2 の推奨事項を最も高いセキュリティアカウントに対して選択的に実装することを検討してください。その後、レベル 1 の推奨事項を残りのアカウントに適用できます。

注記

このコントロールは、次のリージョンではサポートされていません。

  • 中国 (北京)

  • 中国 (寧夏)

  • AWS GovCloud (米国東部)

  • AWSGovCloud (米国西部)。

Remediation

ルートアカウントのハードウェアベースの MFA を有効にするには

  1. ルート認証情報を使用してアカウントにログインします。

  2. ページの右上隅近くにあるアカウント名を選択し、[My Security Credentials (セキュリティの認証情報)] を選択します。

  3. ポップアップ警告で、[Continue to Security Credentials (セキュリティ認証情報に進む)] を選択します。

  4. [多要素認証 (MFA)] を選択します。

  5. [MFA の有効化] を選択します。

  6. MFA で使用するハードウェアベース (仮想ではない) のデバイスを選択し、 [続行] を選択します。

  7. 選択に応じて適切なデバイスタイプを設定するステップを完了します。

1.16 — IAM ポリシーがグループまたはロールにのみアタッチされます。

緊急度:

AWS Config ルール: iam-user-no-policies-check

デフォルトでは、IAM ユーザー、グループ、ロールにアクセスできません。AWSリソースの使用料金を見積もることができます。IAM ポリシーは、ユーザー、グループ、またはロールに権限を付与する方法です。

CIS は、IAM ポリシーをグループとロールには直接適用しますが、ユーザーには直接適用しません。グループレベルまたはロールレベルで権限を割り当てると、ユーザー数が増えるにつれてアクセス管理の複雑さが軽減されます。アクセス管理の複雑さを軽減することで、プリンシパルが誤って過剰な権限を受け取ったり保持したりする機会を減らすことができます。

Remediation

この問題を解決するには、IAM グループを作成し、そのグループにポリシーを割り当て、ユーザーをグループに追加します。ポリシーは、グループ内の各ユーザーに適用されます。

IAM グループを作成するには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [グループ] を選択し、[Create New Group (新しいグループの作成)] を選択します。

  3. 作成するグループの名前を入力し、[次のステップ] を選択します。

  4. グループに割り当てる各ポリシーを選択し、[次のステップ] を選択します。

    選択したポリシーには、現在ユーザーアカウントに直接アタッチされているすべてのポリシーが含まれている必要があります。失敗したチェックを解決するための次のステップは、ユーザーをグループに追加してから、そのグループにポリシーを割り当てることです。グループ内の各ユーザーには、そのグループに割り当てられたポリシーが割り当てられます。

  5. [確認] ページで詳細を確認し、[グループの作成] を選択します。

グループ作成の詳細については、「」を参照してください。IAM グループの作成IAM ユーザーガイド

IAM グループにユーザーを追加するには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [グループ] を選択します。

  3. [Group Actions (グループアクション)] で、[Add Users to Group (ユーザーをグループに追加)] を選択します。

  4. グループに追加するユーザーを選択し、[Add Users (ユーザーを追加)] を選択します。

グループへのユーザーの追加については、「」を参照してください。IAM グループ内のユーザーの追加と削除

ユーザーに直接アタッチされているポリシーを削除するには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [ユーザー] を選択します。

  3. ポリシーをデタッチするユーザーの User name 列から名前を選択します。

  4. [Attached directly (直接アタッチ)] に一覧表示されている各ポリシーで、ページの右側にある [X] を選択してユーザーからポリシーを削除し、[削除] を選択します。

  5. 想定した通りにユーザーが AWS サービスを利用できることを確認します。

1.20 - AWS でインシデントを管理するためのサポートロールが作成されていることを確認します。

緊急度:

AWS Config ルール: iam-policy-in-use

AWS は、インシデントの通知とレスポンス、およびテクニカルサポートとカスタマーサービスに使用できるサポートセンターを提供しています。

IAM ロールを作成して、承認済みユーザーがでインシデントを管理できるようにします。AWSSupport。アクセス制御のための最小権限を実装することで、IAM ロールでは、でインシデントの管理のためにサポートセンターへのアクセスを許可する適切な IAM ポリシーが必要になります。AWSSupport。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アフリカ (ケープタウン)

  • アジアパシフィック (大阪)

  • ヨーロッパ (ミラノ)

Remediation

この問題を修正するには、承認済みユーザーに AWS サポートインシデントの管理を許可するロールを作成します。

AWS サポートへのアクセスに使用するロールを作成するには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [IAM] ナビゲーションペインで、[] を選択します。ロール[]、[]ロールの作成

  3. を使用する場合ロールのタイプで、もう 1 つAWSアカウント

  4. [Account ID (アカウント ID)] に、リソースへのアクセスを許可する AWS アカウントの AWS アカウント ID を入力します。

    このロールを引き受けるユーザーまたはグループが同じアカウントに属している場合は、ローカルアカウント番号を入力します。

    注記

    指定したアカウントの管理者は、そのアカウントのすべての IAM ユーザーに、このロールを引き受けるアクセス許可を付与できます。そのためには、管理者から sts:AssumeRole アクションのアクセス許可を付与するユーザーまたはグループにポリシーをアタッチします。そのポリシーで、リソースはロール ARN であることが必要です。

  5. [Next: (次へ:)] を選択します アクセス許可.

  6. マネージドポリシー AWSSupportAccess を検索します。

  7. AWSSupportAccess マネージドポリシーのチェックボックスをオンにします。

  8. [Next: (次へ:)] を選択します タグ

  9. (オプション) ロールにメタデータを追加するには、キーと値のペアとしてタグをアタッチします。

    IAM におけるタグの使用の詳細については、「」を参照してください。IAM ユーザーとロールのタグ付けIAM ユーザーガイド

  10. [Next: (次へ:)] を選択します 確認.

  11. [ロール名] に、ロールの名前を入力します。

    ロール名は AWS アカウント内で一意でなければなりません。大文字と小文字は区別されません。

  12. (オプション) [Role description] に、新しいロールの説明を入力します。

  13. ロールを確認し、[ロールの作成] を選択します。

1.22 — 完全な「*: *」管理権限を許可する IAM ポリシーが作成されていないことを確認します

緊急度:

AWS Config ルール: iam-policy-no-statements-with-admin-access

IAM ポリシーは、ユーザー、グループ、またはロールに付与される権限のセットを定義します。最小限の特権、つまりタスクを実行するために必要なアクセス許可のみを付与することが標準的なセキュリティアドバイスとして推奨され、考慮されています。完全な管理権限を許可するのではなく、ユーザーが何をする必要があるのかを決定し、ユーザーが、それらのタスクのみを実行できるポリシーを作成します。

最初は最小限のアクセス許可から開始し、必要な場合には追加のアクセス許可を認める方が、最初にあまりにも寛大にアクセス許可を許し、後に規制を厳しくしようとするより安全です。ユーザーが実行する必要がある最小限のアクセス許可セットに制限するのではなく、完全な管理特権を提供すると、リソースが望ましくない可能性のあるアクションにさらされます。

を使用したのステートメントを含む IAM ポリシーは、削除する必要があります。"Effect": "Allow""Action": "*" OVER"Resource": "*"

Remediation

IAM ポリシーを変更するには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [ポリシー] を選択します。

  3. 削除するポリシーの横にあるラジオボタンを選択します。

  4. [Policy Actions (ポリシーアクション)] ドロップダウンメニューから [デタッチ] を選択します。

  5. [Detach policy (ポリシーのデタッチ)] ページで、ポリシーをデタッチする各ユーザーの横にあるラジオボタンを選択して、[Detach policy (ポリシーのデタッチ)] を選択します。

ポリシーをデタッチしたユーザーが、想定どおりに AWS サービスおよびリソースには引き続きアクセスできることを確認します。

2.1 — CloudTrail がすべてのリージョンで有効になっていることを確認します

緊急度: 非常事態

AWS Config ルール: multi-region-cloudtrail-enabled

CloudTrail は記録するサービスですAWSAPI はお客様のアカウントを呼び出し、ログファイルをお客様に送信します。記録される情報には、API 呼び出し元の ID、API 呼び出しの時刻、API 呼び出し元のソース IP アドレス、リクエストパラメータおよび AWS サービスから返された応答のアイデンティティが含まれます。CloudTrail はの履歴を提供しますAWSアカウントの API コール。これには、で実行された API コールが含まれます。AWS Management Console,AWSSDK、コマンドラインツール、および上位レベルAWSサービス (など)AWS CloudFormation).

-AWSCloudTrail によって生成される API の呼び出し履歴を利用して、セキュリティ分析、リソース変更の追跡、およびコンプライアンスの監査を行うことができます。また、

  • マルチリージョンの証跡が存在することを確認することで、他の未使用のリージョンで発生した予期しないアクティビティが確実に検出されます

  • マルチリージョンの証跡が存在することを確認することで、AWS グローバルサービスで生成されたイベントの記録をキャプチャするために、グローバルサービスログ記録がデフォルトで証跡に対して有効になります

  • マルチリージョンの証跡の場合、すべての種類の読み取り/書き込みに対して設定された管理イベントによって、AWS アカウントのすべてのリソースに対して実行された管理オペレーションが確実に記録されます

デフォルトでは、CloudTrail 証跡は、AWS Management Consoleマルチリージョンのトレイルです。

Remediation

CloudTrail に新しい証跡を作成するには

  1. にサインインします。AWS Management Consoleで CloudTrail コンソールを開きます。https://console.aws.amazon.com/cloudtrail/

  2. CloudTrail を初めて使用する場合は、[] を選択します。今すぐ始める

  3. [Trails (証跡)] を選択し、[Create trail (証跡の作成)] を選択します。

  4. 証跡の名前を入力します。

  5. [Storage location (ストレージのロケーション)] で、次のいずれかの操作を行います。

    • CloudTrail ログ用の新しい S3 バケットを作成するには、新しい S3 バケットの作成[] をクリックし、バケットの名前を入力します。

    • 選択既存の S3 バケットを使用する次に、使用するバケットを選択します。

  6. 選択追加設定と、のためにログファイルの検証で、[Enabled (有効)]パスする2.2. — CloudTrail ログファイルの検証が有効になっていることを確認します

  7. パスするには2.4 — CloudTrail トレイルが Amazon CloudWatch Logs と統合されていることを確認するでは、CloudWatch Logs を有効にする必要があります。

    1. [CloudWatch Logs] で、[] を選択します。[Enabled (有効)]] チェックボックスをオンにします。

    2. を使用する場合ロググループ[] で、次のいずれかを実行します。

      • 既存のロググループを使用するには、[] を選択します。EXistingをクリックし、使用するロググループの名前を入力します。

      • 新しいロググループを作成するには、[] を選択します。新規をクリックし、作成するロググループの名前を入力します。

    3. [IAM role (IAM ロール)] で、次のいずれかを実行します。

      • 既存のロールを使用するには、EXistingを選択し、ドロップダウンリストからロールを選択します。

      • 新しいロールを作成するには、新規次に、作成するロールの名前を入力します。新しいロールには、必要なアクセス許可を付与するポリシーが割り当てられます。

        ロールに付与された権限を表示するには、ポリシードキュメント

  8. [作成] を選択します。

CloudTrail の既存の証跡を更新するには

  1. にサインインします。AWS Management Consoleで CloudTrail コンソールを開きます。https://console.aws.amazon.com/cloudtrail/

  2. [証跡] を選択します。

  3. [名前] 列で証跡の名前を選択します。

  4. 必要に応じて、証跡の設定を更新します。

    特定のセクションの設定を更新するには、次の手順を実行します。

    1. 選択編集そのセクションの場合。

    2. 構成に必要な更新を行います。

    3. [変更を保存] を選択します。

2.2. — CloudTrail ログファイルの検証が有効になっていることを確認します

緊急度: ミディアム

AWS Config ルール: cloud-trail-log-file-validation-enabled

CloudTrail ログファイルの検証は、CloudTrail が S3 に書き込むそれぞれのログのハッシュを含むデジタル署名されたダイジェストファイルを作成します。CloudTrail がログを配信した後で、これらのダイジェストファイルを使用して、ログファイルが変更、削除、または変更されなかったかどうかを判断できます。

CIS では、すべての証跡でファイルの検証を有効にすることをお勧めします。ログファイルの検証を有効にすると、CloudTrail ログの追加の整合性チェックが提供されます。

Remediation

CloudTrail のログファイルの検証を有効にするには

  1. CloudTrail コンソール (https://console.aws.amazon.com/cloudtrail/) を開きます。

  2. [証跡] を選択します。

  3. [名前] 列で編集する証跡の名前を選択します。

  4. []一般的な詳細で、編集

  5. []追加設定、に対してログファイルの検証を選択します。[Enabled (有効)]

  6. [Save] を選択します。

2.3 — CloudTrail ログに記録する S3 バケットがパブリックアクセスできないことを確認します

緊急度: 非常事態

AWS Config ルール: s3-bucket-public-read-prohibiteds3-bucket-public-write-prohibited

CloudTrail は、アカウント内で実行された API 呼び出しをすべて記録します。これらのログファイルは S3 バケットに保存されます。CIS は、CloudTrail ログへのパブリックアクセスを禁止するために、CloudTrail がログを記録する S3 バケットに適用することを推奨しています。CloudTrail ログコンテンツへのパブリックアクセスを許可すると、影響を受けるアカウントの使用または設定において敵対者が弱点を特定する手助けとなる可能性があります。

このチェックを実行するために、Security Hub は最初にカスタムロジックを使用して、CloudTrail ログが保存されている S3 バケットを探します。次に、AWS Config マネージドルールを使用して、バケットがパブリックにアクセス可能であることを確認します。

1 つの集中管理された S3 バケットにログを集約する場合、Security Hub は集中管理された S3 バケットがあるアカウントとリージョンに対してのみチェックを実行します。他のアカウントとリージョンの場合、コントロールステータスはデータなし

バケットがパブリックにアクセス可能な場合、チェックにより検出の失敗が生成されます。

Remediation

Amazon S3 バケットに対するパブリックアクセスを削除するには

  1. https://console.aws.amazon.com/s3/ で Amazon S3 コンソールを開きます。

  2. CloudTrail が保存されているバケットの名前を選択します。

  3. [アクセス許可] を選択し、[Public access settings (パブリックアクセス設定)] を選択します。

  4. [編集] を選択し、4 つのオプションを選択して、次に [保存] を選択します。

  5. プロンプトが表示されたら、confirm を入力し、[確認] を選択します。

2.4 — CloudTrail トレイルが Amazon CloudWatch Logs と統合されていることを確認する

緊急度:

AWS Config ルール: cloud-trail-cloud-watch-logs-enabled

CloudTrail は、記録するウェブサービスです。AWS指定されたアカウントで実行される API 呼び出し。記録される情報には、API 呼び出し元の ID、API 呼び出しの時刻、API 呼び出し元のソース IP アドレス、リクエストパラメータおよび AWS サービスから返された応答のアイデンティティが含まれます。

CloudTrail は、ログファイルの保存と配信に Amazon S3 を使用するため、ログファイルは永続的に保存されます。長期分析のために指定された Amazon S3 バケット内の CloudTrail ログをキャプチャするだけでなく、CloudWatch Logs にログを送信するように CloudTrail を設定することで、リアルタイム分析を実行できます。

アカウント内のすべてのリージョンで有効になっている証跡については、CloudTrail はそれらすべてのリージョンからログファイルを CloudWatch Logs ロググループに送信します。

CIS では、CloudTrail ログを CloudWatch Logs に送信することをお勧めします。

注記

この推奨事項の目的は、アカウントのアクティビティが確実にキャプチャされ、モニタリングされ、適切に警告されるようにすることです。CloudWatch Logs は、を使用してこれを達成するためのネイティブな方法です。AWSサービスですが、代替ソリューションの使用を排除するものではありません。

CloudTrail ログを CloudWatch Logs に送信すると、ユーザー、API、リソース、および IP アドレスに基づいてリアルタイムおよび過去のアクティビティのログ記録が容易になります。異常または機密性の高いアカウントのアクティビティに対してアラームと通知を確立する機会を提供します。

Remediation

CloudTrail 証跡が CloudWatch Logs に統合されていることを確認するには

  1. CloudTrail コンソール (https://console.aws.amazon.com/cloudtrail/) を開きます。

  2. [証跡] を選択します。

  3. [CloudWatch Logs Log group (CloudWatch Logs ロググループ)] 列に値のない証跡を選択します。

  4. [] まで下にスクロールします。[CloudWatch Logs]セクションを選択し、編集

  5. [有効] チェックボックスをオンにします。

  6. を使用する場合ロググループ[] で、次のいずれかを実行します。

    • 既存のロググループを使用するには、[] を選択します。EXistingをクリックし、使用するロググループの名前を入力します。

    • 新しいロググループを作成するには、[] を選択します。新規をクリックし、作成するロググループの名前を入力します。

  7. [IAM role (IAM ロール)] で、次のいずれかを実行します。

    • 既存のロールを使用するには、EXistingを選択し、ドロップダウンリストからロールを選択します。

    • 新しいロールを作成するには、新規次に、作成するロールの名前を入力します。新しいロールには、必要なアクセス許可を付与するポリシーが割り当てられます。

      ロールに付与された権限を表示するには、ポリシードキュメント

  8. [変更を保存] を選択します。

詳細については、「」を参照してください。コンソールを使用した CloudWatch Logs モニタリングの設定AWS CloudTrailユーザーガイド

2.5 — 確認AWS Configが有効である

緊急度: ミディアム

AWS Configルール: なし

AWS Config は、アカウントでサポートされている AWS リソースの設定管理を実行し、ログファイルを配信するウェブサービスです。記録される情報には、設定アイテム (AWS リソース)、設定アイテム間の関係 (AWS リソース)、およびリソース間の設定変更が含まれます。

CIS では、を有効にすることを推奨しています。AWS Configは、すべてのリージョンで使用できます。AWS Config がキャプチャする AWS 設定項目の履歴により、セキュリティ分析、リソース変更の追跡、およびコンプライアンスの監査を行うことができます。

注記

CIS 2.5 では、AWS Configは、Security Hub を使用するすべてのリージョンで有効になっています。

Security Hub はリージョナルサービスであるため、このコントロールに対して実行されるチェックでは、アカウントの現在のリージョンのみが確認されます。すべてのリージョンが確認されるわけではありません。

また、グローバルリソースに対するセキュリティチェックを各リージョンで確認できるように、グローバルリソースを記録する必要もあります。グローバルリソースを 1 つのリージョンにのみ記録する場合は、グローバルリソースを記録するリージョン以外のすべてのリージョンでこのコントロールを無効にすることができます。

このチェックを実行するには、Security Hub はカスタムロジックを実行して、に規定された監査ステップを実行しますCISAWS基礎ベンチマーク v1.2。また、Security Hub はリージョンのサービスであり、リージョンごとにセキュリティチェックを実行するため、Security Hub では各リージョンにグローバルリソースが記録される必要もあります。

Remediation

AWS Config 設定を構成するには

  1. AWS Config コンソール(https://console.aws.amazon.com/config/)を開きます。

  2. AWS Config を設定するリージョンを選択します。

  3. 以前に AWS Config を使用したことがない場合は、[Get started (始めに)] を選択します。

  4. [Settings (設定)] ページで、以下の操作を行います。

    • []記録するリソースタイプを選択し、このリージョンでサポートされるすべてのリソースを記録するおよびグローバルリソースを含める (例:AWSIAM リソース)

    • [Amazon S3 bucket (Amazon S3 バケット)] で、バケットを使用するか、バケットを作成し、必要に応じてプレフィックスを含めます。

    • []Amazon SNS トピックで、アカウントから Amazon SNS トピックを選択するか、トピックを作成します。Amazon SNS の詳細については、「」を参照してください。Amazon Simple Notication Service 入門ガイド

    • []AWS Configロールで、どちらかを選んでください作成 AWS Config サービスにリンクされたロールまたはアカウントからロールを選択[] を選択し、使用するロールを選択します。

  5. [次へ] を選択します。

  6. [ AWS Config ] ルールページで、[Skip (スキップ)] を選択します。

  7. [Confirm] を選択します。

の使用方法の詳細については、「」を参照 AWS Config からのAWS Command Line Interface「」を参照してください。の有効化 AWS Config AWS Config デベロッパーガイド

AWS CloudFormation テンプレートを使用してこのプロセスを自動化することもできます。詳細については、「」を参照してください。AWS CloudFormationStackSets サンプルテンプレートAWS CloudFormationユーザーガイド

2.6 — CloudTrail S3 バケットで S3 バケットアクセスログ記録が有効になっていることを確認します

緊急度:

AWS Config ルール: s3-bucket-logging-enabled

Amazon S3 バケットアクセスログ記録は、S3 バケットに対して行われたリクエストごとにアクセスレコードを含むログを生成します。アクセスログには、リクエストのタイプ、リクエストに指定されたリソース、リクエストが処理された日時など、リクエストの詳細が記録されます。

CIS は、CloudTrail S3 バケットでログ記録バケットアクセスを有効にすることをお勧めします。

ターゲット S3 バケットで S3 バケットのログ記録を有効にすることで、ターゲットバケット内のオブジェクトに影響を与える可能性のあるすべてのイベントをキャプチャできます。ログを別のバケットに配置するように設定すると、ログ情報にアクセスできるようになり、セキュリティおよびインシデント対応のワークフローで役立ちます。

このチェックを実行するため、Security Hub は最初にカスタムロジックを使用して、CloudTrail ログが保存されているバケットを探してから、AWS Configロギングが有効かどうかをチェックする管理ルール。

1 つの集中管理された S3 バケットにログを集約する場合、Security Hub は集中管理された S3 バケットがあるアカウントとリージョンに対してのみチェックを実行します。他のアカウントとリージョンの場合、コントロールステータスはデータなし

バケットがパブリックにアクセス可能な場合、チェックにより検出の失敗が生成されます。

Remediation

S3 バケットのアクセスログ記録を有効にするには

  1. https://console.aws.amazon.com/s3/ で Amazon S3 コンソールを開きます。

  2. CloudTrail に使用するバケットを選択します。

  3. [プロパティ] を選択します。

  4. [Server access logging (サーバーアクセスのログ記録)] を選択し、[Enable logging (ログ記録を有効にする)] を選択します。

  5. [Target bucket (ターゲットバケット)] リストからバケットを選択し、必要に応じてプレフィックスを入力します。

  6. [Save] を選択します。

2.7 — CloudTrail ログが保管時に、を使用して暗号化されていることを確認しますAWS KMS keys

緊急度: ミディアム

AWS Config ルール: cloud-trail-encryption-enabled

CloudTrail は、記録するウェブサービスです。AWSAPI はアカウントを呼び出し、IAM ポリシーに従ってユーザーとリソースでそれらのログを利用できるようにします。AWS Key Management Service(AWS KMS) は、アカウントデータの暗号化に使用される暗号化キーの作成と管理を支援するマネージドサービスであり、ハードウェアセキュリティモジュール (HSM) を使用して暗号化キーのセキュリティを保護します。

CloudTrail ログを設定して、サーバーサイド暗号化 (SSE) と KMS キーを活用して CloudTrail ログをさらに保護することができます。

SSE-KMS を使用するように CloudTrail を設定することをお勧めします。

特定のユーザーには対応するログバケットに対する S3 読み取り権限が必要であり、KMS キーポリシーで復号化アクセス許可を付与する必要があるため、CloudTrail が SSE-KMS を使用するように設定すると、ログデータに対する追加の機密性管理が提供されます。

Remediation

CloudTrail ログの暗号化を有効にするには

  1. CloudTrail コンソール (https://console.aws.amazon.com/cloudtrail/) を開きます。

  2. [証跡] を選択します。

  3. 更新する証跡を選択します。

  4. [Storage location (ストレージロケーション)] で、鉛筆アイコンを選択して設定を編集します。

  5. [Encrypt log files with SSE-KMS (SSE-KMS でログファイルを暗号化する)] で、[はい] を選択します。

  6. [Create a new KMS key (新しい KMS キーを作成する)] で、次のいずれかの操作を行います。

    • キーを作成するには、[Yes] を選択し、[KMS キー] フィールドのキーのエイリアスを入力します。キーは、バケットと同じリージョンに作成されます。

    • 既存のキーを使用するには、[いいえ] を選択し、 [KMS キー] リストからキーを選択します。

    注記

    AWS KMS キーおよび S3 バケットは同じリージョンにある必要があります。

  7. [Save] を選択します。

KMS キーと正常にやり取りするためには、CloudTrail のポリシーを変更する必要がある場合があります。詳細については、「」を参照してください。を使用して CloudTrail ログファイルを暗号化するAWS KMS— マネージドキー (SSE-KMS)AWS CloudTrailユーザーガイド

2.8 — カスタマー作成の KMS キーのローテーションが有効になっていることを確認します

緊急度: ミディアム

AWS Config ルール: cmk-backing-key-rotation-enabled

AWS KMSお客様がバッキングキーを回転させることができます。バッキングキーは、保管されているキー素材です。AWS KMSは、KMS キーのキー ID に関連付けられています。暗号化や復号などの暗号化オペレーションを実行するために使用されるのは、バッキングキーです。現在、自動化されたキー更新では以前のすべてのバッキングキーが保持されるため、暗号化したデータの復号は透過的に実行できます。

CISでは、KMS キーキーのローテーションを有効にすることをお勧めします。新しいキーで暗号化されたデータは、公開された可能性がある以前のキーではアクセスできないため、暗号化キーをローテーションすることで、侵害されたキーによる潜在的な影響を減らすことができます。

Remediation

KMS キーローテーションを有効にするには

  1. AWS KMS コンソール (https://console.aws.amazon.com/kms) を開きます。

  2. AWS リージョンを変更するには、ページの右上隅にあるリージョンセレクターを使用します。

  3. [Customer managed keys (カスタマーマネージドキー)] を選択します。

  4. キーのエイリアスを選択して、[エイリアス] 列で更新します。

  5. [キーローテーション] を選択します。

  6. Select毎年この KMS キーを自動的に回転させる[] を選択して [] を選択します保存

2.9 — すべての VPC で VPC フローログ記録が有効になっていることを確認します

緊急度: ミディアム

AWS Config ルール: vpc-flow-logs-enabled

VPC フローログは、VPC のネットワークインターフェイスとの間で行き来する IP トラフィックに関する情報をキャプチャできるようにする機能です。フローログを作成すると、CloudWatch Logs でそのデータを表示し、取得できます。

CIS は、VPC のパケット拒否に対してフローログ記録を有効にすることをお勧めします。フローログは、VPC を通過するネットワークトラフィックを確認可能にし、セキュリティワークフロー中に異常なトラフィックや洞察を検出できます。

Remediation

VPC フローログ記録を有効にするには

  1. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。

  2. [VPC] を選択します。

  3. 更新する VPC を選択します。

  4. ページの下部に表示される [フローログ] タブを選択します。

  5. [フローログの作成] を選択します。

  6. [フィルター] で、[拒否] を選択します。

  7. [Destination log group (送信先ロググループ)] で、使用するグループのログを選択します。

  8. を使用する場合IAM ロールで、使用する IAM ロールを選択します。

  9. [作成] を選択します。

3.1 — 不正な API 呼び出しに対してログメトリクスフィルターとアラームが存在することを確認します

緊急度:

AWS Configルール: なし

CloudWatch Logs を CloudTrail ログに転送し、対応するメトリクスフィルターとアラームを確立することで、API 呼び出しのリアルタイムモニタリングを実行できます。

CIS では、メトリクスフィルターを作成し、不正な API コールを警告します。不正な API 呼び出しをモニタリングすることでアプリケーションエラーを明らかにし、悪意のあるアクティビティを検出する時間を短縮することができます。

このチェックを実行するために、Security Hub はカスタムロジックを使用して、のコントロール 3.1 に規定された正確な監査手順を実行します。CISAWS基礎ベンチマーク v1.2。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

注記

Security Hub がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡が検索されます。これらの証跡は、別のアカウントに属する組織の証跡である可能性があります。マルチリージョンの証跡は、別のリージョンに基づいている場合もあります。

チェックの結果はFAILED以下の場合における知見。

  • トレイルは設定されていません。

  • 現在のリージョンにあり、現在のアカウントが所有している利用可能な証跡は、管理要件を満たしていません。

チェックの結果、制御ステータスはNO_DATA以下の場合は、

  • マルチリージョンの証跡は、別のリージョンに基づいています。Security Hub は、証跡のベースとなるリージョンでのみ結果を生成できます。

  • マルチリージョンの証跡は、別のアカウントに属しています。Security Hub は、証跡を所有するアカウントの調査結果のみを生成できます。

アラームの場合、現在のアカウントが参照されている Amazon SNS トピックを所有しているか、listSubscriptionAmazon SNS トピックへのアクセス。それ以外の場合は、Security HubWARNINGコントロールの所見。

Remediation

この問題を修正するためのステップには、Amazon SNS トピック、CloudTrail 証跡、メトリクスフィルター、およびメトリクスフィルターのアラームの設定が含まれます。

Amazon SNS トピックを作成する

  1. Amazon SNS コンソール(https://console.aws.amazon.com/sns/v3/home)を開きます。

  2. すべての CIS アラームを受信する Amazon SNS トピックを作成します。

    トピックに少なくとも 1 人の受信者を作成します。詳細については、「」を参照してください。Amazon SNS の開始方法Amazon Simple Notification Service デベロッパーガイド

次に、すべてのリージョンに適用されるアクティブなCloudTrail をセットアップします。これを行うには、2.1 — CloudTrail がすべてのリージョンで有効になっていることを確認します の修正手順に従います。

CloudTrail 証跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。そのロググループのメトリックスフィルタを作成します。

最後に、メトリクスフィルターとアラームを作成します。

メトリクスフィルターとアラームを作成するには

  1. CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。

  2. ナビゲーションペインで、[Log groups] (ロググループ) を選択します。

  3. 作成した CloudTrail 証跡に関連付けられている CloudWatch Logs ロググループのチェックボックスをオンにします。

  4. 送信元アクションで、メトリクスフィルターの作成

  5. []パターンを定義する] で、次の作業を行います。

    1. 次のパターンをコピーして、[Filter Pattern (フィルターパターン)] フィールドに貼り付けます。

      {($.errorCode="*UnauthorizedOperation") || ($.errorCode="AccessDenied*")}
    2. [次へ] を選択します。

  6. []メトリクスの割り当て] で、次の作業を行います。

    1. Eclipseフィルタ名で、メトリクスフィルタの名前を入力します。

    2. を使用する場合メトリクス名前空間「」と入力します。LogMetrics

      すべての CIS ログメトリックフィルタに同じ名前空間を使用する場合、すべての CIS Benchmark メトリックがグループ化されます。

    3. を使用する場合メトリクス名で、メトリックスの名前を入力します。メトリクスの名前を覚えておいてください。アラームの作成時にメトリクスを選択する必要があります。

    4. [メトリクス値] に「1」と入力します。

    5. [次へ] を選択します。

  7. []確認と作成で、新しいメトリックフィルタに入力した情報を確認します。次に [] を選択します。メトリクスフィルターの作成

  8. [メトリクスフィルタータブを選択し、作成したメトリックフィルタを選択します。

    メトリクスフィルタを選択するには、右上のチェックボックスを選択します。

  9. [Create Alarm] を選択します。

  10. []メトリックと条件の指定] で、次の作業を行います。

    1. []メトリクス、に対してStatisticで、平均。使用できる統計の詳細については、「」を参照してください。統計Amazon CloudWatch ユーザーガイド

    2. []条件、に対してThresholdで、静的

    3. を使用する場合アラーム条件を定義します。で、以上

    4. を使用する場合しきい値を定義します。「」と入力します。1

    5. [次へ] を選択します。

  11. []アクションの設定] で、次の作業を行います。

    1. []アラームの状態で、のアラーム

    2. [SNS トピックの選択] で、[既存の SNS トピックの選択] を選択します。

    3. を使用する場合通知の送信先で、前の手順で作成した SNS トピックの名前を入力します。

    4. [次へ] を選択します。

  12. [][Name (名前)] と「」と入力します。名前および説明アラームのために。例えば、CIS-3.1-UnauthorizedAPICalls と指定します。続いて、[次へ] を選択します。

  13. []プレビューと作成で、アラーム設定を確認します。次に [アラームの作成] を選択します。

3.2 — ログメトリクスフィルターとアラームが存在することを確認します。AWS Management ConsoleMFA なしでサインイン

緊急度:

AWS Configルール: なし

CloudWatch Logs を CloudTrail ログに転送し、対応するメトリクスフィルターとアラームを確立することで、API 呼び出しのリアルタイムモニタリングを実行できます。

CIS は、MFA で保護されていないメトリクスフィルターとアラームコンソールログインを作成します。単一要素のコンソールログインをモニタリングすると、MFA によって保護されていないアカウントへの可視性が向上します。

このチェックを実行するために、Security Hub はカスタムロジックを使用して、のコントロール 3.2 に規定された正確な監査手順を実行します。CISAWS基礎ベンチマーク v1.2。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

注記

Security Hub がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡が検索されます。これらの証跡は、別のアカウントに属する組織の証跡である可能性があります。マルチリージョンの証跡は、別のリージョンに基づいている場合もあります。

チェックの結果はFAILED以下の場合における知見。

  • トレイルは設定されていません。

  • 現在のリージョンにあり、現在のアカウントが所有している利用可能な証跡は、管理要件を満たしていません。

チェックの結果、制御ステータスはNO_DATA以下の場合は、

  • マルチリージョンの証跡は、別のリージョンに基づいています。Security Hub は、証跡のベースとなるリージョンでのみ結果を生成できます。

  • マルチリージョンの証跡は、別のアカウントに属しています。Security Hub は、証跡を所有するアカウントの調査結果のみを生成できます。

アラームの場合、現在のアカウントが参照されている Amazon SNS トピックを所有しているか、listSubscriptionAmazon SNS トピックへのアクセス。それ以外の場合は、Security HubWARNINGコントロールの所見。

Remediation

この問題を修正するためのステップには、Amazon SNS トピック、CloudTrail 証跡、メトリクスフィルター、およびメトリクスフィルターのアラームの設定が含まれます。

Amazon SNS トピックを作成する

  1. Amazon SNS コンソール(https://console.aws.amazon.com/sns/v3/home)を開きます。

  2. すべての CIS アラームを受信する Amazon SNS トピックを作成します。

    トピックに少なくとも 1 人の受信者を作成します。詳細については、「」を参照してください。Amazon SNS の開始方法Amazon Simple Notification Service デベロッパーガイド

次に、すべてのリージョンに適用されるアクティブなCloudTrail をセットアップします。これを行うには、2.1 — CloudTrail がすべてのリージョンで有効になっていることを確認します の修正手順に従います。

CloudTrail 証跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。そのロググループのメトリックスフィルタを作成します。

最後に、メトリクスフィルターとアラームを作成します。

メトリクスフィルターとアラームを作成するには

  1. CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。

  2. ナビゲーションペインで、[Log groups] (ロググループ) を選択します。

  3. 作成した CloudTrail 証跡に関連付けられている CloudWatch Logs ロググループのチェックボックスをオンにします。

  4. 送信元アクションで、メトリクスフィルターの作成

  5. []パターンを定義する] で、次の作業を行います。

    1. 次のパターンをコピーして、[Filter Pattern (フィルターパターン)] フィールドに貼り付けます。

      {($.eventName="ConsoleLogin") && ($.additionalEventData.MFAUsed !="Yes")}
    2. [次へ] を選択します。

  6. []メトリクスの割り当て] で、次の作業を行います。

    1. Eclipseフィルタ名で、メトリクスフィルタの名前を入力します。

    2. を使用する場合メトリクス名前空間「」と入力します。LogMetrics

      すべての CIS ログメトリックフィルタに同じ名前空間を使用する場合、すべての CIS Benchmark メトリックがグループ化されます。

    3. を使用する場合メトリクス名で、メトリックスの名前を入力します。メトリクスの名前を覚えておいてください。アラームの作成時にメトリクスを選択する必要があります。

    4. [メトリクス値] に「1」と入力します。

    5. [次へ] を選択します。

  7. []確認と作成で、新しいメトリックフィルタに入力した情報を確認します。次に [] を選択します。メトリクスフィルターの作成

  8. [メトリクスフィルタータブを選択し、作成したメトリックフィルタを選択します。

    メトリクスフィルタを選択するには、右上のチェックボックスを選択します。

  9. [Create Alarm] を選択します。

  10. []メトリックと条件の指定] で、次の作業を行います。

    1. []メトリクスで、値をデフォルトのままにしておきます。使用できる統計の詳細については、「」を参照してください。統計Amazon CloudWatch ユーザーガイド

    2. []条件、に対してThresholdで、静的

    3. を使用する場合アラーム条件を定義します。で、以上

    4. を使用する場合しきい値を定義します。「」と入力します。1

    5. [次へ] を選択します。

  11. []アクションの設定] で、次の作業を行います。

    1. []アラームの状態で、のアラーム

    2. [SNS トピックの選択] で、[既存の SNS トピックの選択] を選択します。

    3. を使用する場合通知の送信先で、前の手順で作成した SNS トピックの名前を入力します。

    4. [次へ] を選択します。

  12. [][Name (名前)] と「」と入力します。名前および説明アラームのために。例えば、CIS-3.2-ConsoleSigninWithoutMFA と指定します。続いて、[次へ] を選択します。

  13. []プレビューと作成で、アラーム設定を確認します。次に [アラームの作成] を選択します。

3.3 —「ルート」アカウントの使用に対するメトリクスフィルターとアラームが存在することを確認します

緊急度:

AWS Configルール: なし

CloudTrail ログをに転送し、対応するメトリクスフィルターとアラームを確立することで、API 呼び出しのリアルタイムモニタリングを実行できます。

CIS では、ルートログインの試行に対するメトリクスフィルターとアラームを作成することをお勧めします。ルートアカウントのログインをモニタリングすることで、完全に特権が付与されたアカウントの使用状況に可視性を提供し、その使用を削減する機会を提供します。

このチェックを実行するために、Security Hub はカスタムロジックを使用して、のコントロール 3.3 に規定された正確な監査手順を実行します。CISAWS基礎ベンチマーク v1.2。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

注記

Security Hub がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡が検索されます。これらの証跡は、別のアカウントに属する組織の証跡である可能性があります。マルチリージョンの証跡は、別のリージョンに基づいている場合もあります。

チェックの結果はFAILED以下の場合における知見。

  • トレイルは設定されていません。

  • 現在のリージョンにあり、現在のアカウントが所有している利用可能な証跡は、管理要件を満たしていません。

チェックの結果、制御ステータスはNO_DATA以下の場合は、

  • マルチリージョンの証跡は、別のリージョンに基づいています。Security Hub は、証跡のベースとなるリージョンでのみ結果を生成できます。

  • マルチリージョンの証跡は、別のアカウントに属しています。Security Hub は、証跡を所有するアカウントの調査結果のみを生成できます。

アラームの場合、現在のアカウントが参照されている Amazon SNS トピックを所有しているか、listSubscriptionAmazon SNS トピックへのアクセス。それ以外の場合は、Security HubWARNINGコントロールの所見。

Remediation

この問題を修正するためのステップには、Amazon SNS トピック、CloudTrail 証跡、メトリクスフィルター、およびメトリクスフィルターのアラームの設定が含まれます。

Amazon SNS トピックを作成する

  1. Amazon SNS コンソール(https://console.aws.amazon.com/sns/v3/home)を開きます。

  2. すべての CIS アラームを受信する Amazon SNS トピックを作成します。

    トピックに少なくとも 1 人の受信者を作成します。詳細については、「」を参照してください。Amazon SNS の開始方法Amazon Simple Notification Service デベロッパーガイド

次に、すべてのリージョンに適用されるアクティブなCloudTrail をセットアップします。これを行うには、2.1 — CloudTrail がすべてのリージョンで有効になっていることを確認します の修正手順に従います。

CloudTrail 証跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。そのロググループのメトリックスフィルタを作成します。

最後に、メトリクスフィルターとアラームを作成します。

メトリクスフィルターとアラームを作成するには

  1. CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。

  2. ナビゲーションペインで、[Log groups] (ロググループ) を選択します。

  3. 作成した CloudTrail 証跡に関連付けられている CloudWatch Logs ロググループのチェックボックスをオンにします。

  4. 送信元アクションで、メトリクスフィルターの作成

  5. []パターンを定義する] で、次の作業を行います。

    1. 次のパターンをコピーして、[Filter Pattern (フィルターパターン)] フィールドに貼り付けます。

      {$.userIdentity.type="Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType !="AwsServiceEvent"}
    2. [次へ] を選択します。

  6. []メトリクスの割り当て] で、次の作業を行います。

    1. Eclipseフィルタ名で、メトリクスフィルタの名前を入力します。

    2. を使用する場合メトリクス名前空間「」と入力します。LogMetrics

      すべての CIS ログメトリックフィルタに同じ名前空間を使用する場合、すべての CIS Benchmark メトリックがグループ化されます。

    3. を使用する場合メトリクス名で、メトリックスの名前を入力します。メトリクスの名前を覚えておいてください。アラームの作成時にメトリクスを選択する必要があります。

    4. [メトリクス値] に「1」と入力します。

    5. [次へ] を選択します。

  7. []確認と作成で、新しいメトリックフィルタに入力した情報を確認します。次に [] を選択します。メトリクスフィルターの作成

  8. [メトリクスフィルタータブを選択し、作成したメトリックフィルタを選択します。

    メトリクスフィルタを選択するには、右上のチェックボックスを選択します。

  9. [Create Alarm] を選択します。

  10. []メトリックと条件の指定] で、次の作業を行います。

    1. []メトリクスで、値をデフォルトのままにしておきます。使用できる統計の詳細については、「」を参照してください。統計Amazon CloudWatch ユーザーガイド

    2. []条件、に対してThresholdで、静的

    3. を使用する場合アラーム条件を定義します。で、以上

    4. を使用する場合しきい値を定義します。「」と入力します。1

    5. [次へ] を選択します。

  11. []アクションの設定] で、次の作業を行います。

    1. []アラームの状態で、のアラーム

    2. [SNS トピックの選択] で、[既存の SNS トピックの選択] を選択します。

    3. を使用する場合通知の送信先で、前の手順で作成した SNS トピックの名前を入力します。

    4. [次へ] を選択します。

  12. [][Name (名前)] と「」と入力します。名前および説明アラームのために。例えば、RootAccountUsage と指定します。続いて、[次へ] を選択します。

  13. []プレビューと作成で、アラーム設定を確認します。次に [アラームの作成] を選択します。

3.4 — IAM ポリシーの変更に対してログメトリクスフィルターとアラームが存在することを確認します

緊急度:

AWS Configルール: なし

CloudWatch Logs を CloudTrail ログに転送し、対応するメトリクスフィルターとアラームを確立することで、API 呼び出しのリアルタイムモニタリングを実行できます。

IAM ポリシーに加えられた変更に対するメトリクスフィルターとアラームを作成します。これらの変更をモニタリングすることで、認証と承認の管理が損なわれないようにすることができます。

このチェックを実行するために、Security Hub はカスタムロジックを使用して、のコントロール 3.4 に規定された正確な監査手順を実行します。CISAWS基礎ベンチマーク v1.2。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

注記

Security Hub がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡が検索されます。これらの証跡は、別のアカウントに属する組織の証跡である可能性があります。マルチリージョンの証跡は、別のリージョンに基づいている場合もあります。

チェックの結果はFAILED以下の場合における知見。

  • トレイルは設定されていません。

  • 現在のリージョンにあり、現在のアカウントが所有している利用可能な証跡は、管理要件を満たしていません。

チェックの結果、制御ステータスはNO_DATA以下の場合は、

  • マルチリージョンの証跡は、別のリージョンに基づいています。Security Hub は、証跡のベースとなるリージョンでのみ結果を生成できます。

  • マルチリージョンの証跡は、別のアカウントに属しています。Security Hub は、証跡を所有するアカウントの調査結果のみを生成できます。

アラームの場合、現在のアカウントが参照されている Amazon SNS トピックを所有しているか、listSubscriptionAmazon SNS トピックへのアクセス。それ以外の場合は、Security HubWARNINGコントロールの所見。

Remediation

この問題を修正するためのステップには、Amazon SNS トピック、CloudTrail 証跡、メトリクスフィルター、およびメトリクスフィルターのアラームの設定が含まれます。

アラームは、特定の API オペレーションを名前でチェックすることに注意してください。これらの操作の 1 つは次のとおりです。DeletePolicy。アラームは、コールが IAM から発行されたかどうかをチェックしません。このため、Auto Scaling を呼び出したときにもアラームがトリガーされます。DeletePolicy

Amazon SNS トピックを作成する

  1. Amazon SNS コンソール(https://console.aws.amazon.com/sns/v3/home)を開きます。

  2. すべての CIS アラームを受信する Amazon SNS トピックを作成します。

    トピックに少なくとも 1 人の受信者を作成します。詳細については、「」を参照してください。Amazon SNS の開始方法Amazon Simple Notification Service デベロッパーガイド

次に、すべてのリージョンに適用されるアクティブなCloudTrail をセットアップします。これを行うには、2.1 — CloudTrail がすべてのリージョンで有効になっていることを確認します の修正手順に従います。

CloudTrail 証跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。そのロググループのメトリックスフィルタを作成します。

最後に、メトリクスフィルターとアラームを作成します。

メトリクスフィルターとアラームを作成するには

  1. CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。

  2. ナビゲーションペインで、[Log groups] (ロググループ) を選択します。

  3. 作成した CloudTrail 証跡に関連付けられている CloudWatch Logs ロググループのチェックボックスをオンにします。

  4. 送信元アクションで、メトリクスフィルターの作成

  5. []パターンを定義する] で、次の作業を行います。

    1. 次のパターンをコピーして、[Filter Pattern (フィルターパターン)] フィールドに貼り付けます。

      {($.eventName=DeleteGroupPolicy) || ($.eventName=DeleteRolePolicy) || ($.eventName=DeleteUserPolicy) || ($.eventName=PutGroupPolicy) || ($.eventName=PutRolePolicy) || ($.eventName=PutUserPolicy) || ($.eventName=CreatePolicy) || ($.eventName=DeletePolicy) || ($.eventName=CreatePolicyVersion) || ($.eventName=DeletePolicyVersion) || ($.eventName=AttachRolePolicy) || ($.eventName=DetachRolePolicy) || ($.eventName=AttachUserPolicy) || ($.eventName=DetachUserPolicy) || ($.eventName=AttachGroupPolicy) || ($.eventName=DetachGroupPolicy)}
    2. [次へ] を選択します。

  6. []メトリクスの割り当て] で、次の作業を行います。

    1. Eclipseフィルタ名で、メトリクスフィルタの名前を入力します。

    2. を使用する場合メトリクス名前空間「」と入力します。LogMetrics

      すべての CIS ログメトリックフィルタに同じ名前空間を使用する場合、すべての CIS Benchmark メトリックがグループ化されます。

    3. を使用する場合メトリクス名で、メトリックスの名前を入力します。メトリクスの名前を覚えておいてください。アラームの作成時にメトリクスを選択する必要があります。

    4. [メトリクス値] に「1」と入力します。

    5. [次へ] を選択します。

  7. []確認と作成で、新しいメトリックフィルタに入力した情報を確認します。次に [] を選択します。メトリクスフィルターの作成

  8. [メトリクスフィルタータブを選択し、作成したメトリックフィルタを選択します。

    メトリクスフィルタを選択するには、右上のチェックボックスを選択します。

  9. [Create Alarm] を選択します。

  10. []メトリックと条件の指定] で、次の作業を行います。

    1. []メトリクス、に対してStatisticで、平均。使用できる統計の詳細については、「」を参照してください。統計Amazon CloudWatch ユーザーガイド

    2. []条件、に対してThresholdで、静的

    3. を使用する場合アラーム条件を定義します。で、以上

    4. を使用する場合しきい値を定義します。「」と入力します。1

    5. [次へ] を選択します。

  11. []アクションの設定] で、次の作業を行います。

    1. []アラームの状態で、のアラーム

    2. [SNS トピックの選択] で、[既存の SNS トピックの選択] を選択します。

    3. を使用する場合通知の送信先で、前の手順で作成した SNS トピックの名前を入力します。

    4. [次へ] を選択します。

  12. [][Name (名前)] と「」と入力します。名前および説明アラームのために。例えば、CIS-3.4-IAMPolicyChanges と指定します。続いて、[次へ] を選択します。

  13. []プレビューと作成で、アラーム設定を確認します。次に [アラームの作成] を選択します。

3.5 — CloudTrail の設定の変更に対してログメトリクスフィルターとアラームが存在することを確認します

緊急度:

AWS Configルール: なし

CloudWatch Logs を CloudTrail ログに転送し、対応するメトリクスフィルターとアラームを確立することで、API 呼び出しのリアルタイムモニタリングを実行できます。

CIS は、CloudTrail 設定の変更に対するメトリクスフィルターとアラームを作成します。これらの変更をモニタリングすることで、アカウント内のアクティビティに対する継続的な可視性を確保できます。

このチェックを実行するために、Security Hub はカスタムロジックを使用して、のコントロール 3.5 に規定された正確な監査手順を実行します。CISAWS基礎ベンチマーク v1.2。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

注記

Security Hub がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡が検索されます。これらの証跡は、別のアカウントに属する組織の証跡である可能性があります。マルチリージョンの証跡は、別のリージョンに基づいている場合もあります。

チェックの結果はFAILED以下の場合における知見。

  • トレイルは設定されていません。

  • 現在のリージョンにあり、現在のアカウントが所有している利用可能な証跡は、管理要件を満たしていません。

チェックの結果、制御ステータスはNO_DATA以下の場合は、

  • マルチリージョンの証跡は、別のリージョンに基づいています。Security Hub は、証跡のベースとなるリージョンでのみ結果を生成できます。

  • マルチリージョンの証跡は、別のアカウントに属しています。Security Hub は、証跡を所有するアカウントの調査結果のみを生成できます。

アラームの場合、現在のアカウントが参照されている Amazon SNS トピックを所有しているか、listSubscriptionAmazon SNS トピックへのアクセス。それ以外の場合は、Security HubWARNINGコントロールの所見。

Remediation

この問題を修正するためのステップには、Amazon SNS トピック、CloudTrail 証跡、メトリクスフィルター、およびメトリクスフィルターのアラームの設定が含まれます。

Amazon SNS トピックを作成する

  1. Amazon SNS コンソール(https://console.aws.amazon.com/sns/v3/home)を開きます。

  2. すべての CIS アラームを受信する Amazon SNS トピックを作成します。

    トピックに少なくとも 1 人の受信者を作成します。詳細については、「」を参照してください。Amazon SNS の開始方法Amazon Simple Notification Service デベロッパーガイド

次に、すべてのリージョンに適用されるアクティブなCloudTrail をセットアップします。これを行うには、2.1 — CloudTrail がすべてのリージョンで有効になっていることを確認します の修正手順に従います。

CloudTrail 証跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。そのロググループのメトリックスフィルタを作成します。

最後に、メトリクスフィルターとアラームを作成します。

メトリクスフィルターとアラームを作成するには

  1. CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。

  2. ナビゲーションペインで、[Log groups] (ロググループ) を選択します。

  3. 作成した CloudTrail 証跡に関連付けられている CloudWatch Logs ロググループのチェックボックスをオンにします。

  4. 送信元アクションで、メトリクスフィルターの作成

  5. []パターンを定義する] で、次の作業を行います。

    1. 次のパターンをコピーして、[Filter Pattern (フィルターパターン)] フィールドに貼り付けます。

      {($.eventName=CreateTrail) || ($.eventName=UpdateTrail) || ($.eventName=DeleteTrail) || ($.eventName=StartLogging) || ($.eventName=StopLogging)}
    2. [次へ] を選択します。

  6. []メトリクスの割り当て] で、次の作業を行います。

    1. Eclipseフィルタ名で、メトリクスフィルタの名前を入力します。

    2. を使用する場合メトリクス名前空間「」と入力します。LogMetrics

      すべての CIS ログメトリックフィルタに同じ名前空間を使用する場合、すべての CIS Benchmark メトリックがグループ化されます。

    3. を使用する場合メトリクス名で、メトリックスの名前を入力します。メトリクスの名前を覚えておいてください。アラームの作成時にメトリクスを選択する必要があります。

    4. [メトリクス値] に「1」と入力します。

    5. [次へ] を選択します。

  7. []確認と作成で、新しいメトリックフィルタに入力した情報を確認します。次に [] を選択します。メトリクスフィルターの作成

  8. [メトリクスフィルタータブを選択し、作成したメトリックフィルタを選択します。

    メトリクスフィルタを選択するには、右上のチェックボックスを選択します。

  9. [Create Alarm] を選択します。

  10. []メトリックと条件の指定] で、次の作業を行います。

    1. []メトリクスで、値をデフォルトのままにしておきます。使用できる統計の詳細については、「」を参照してください。統計Amazon CloudWatch ユーザーガイド

    2. []条件、に対してThresholdで、静的

    3. を使用する場合アラーム条件を定義します。で、以上

    4. を使用する場合しきい値を定義します。「」と入力します。1

    5. [次へ] を選択します。

  11. []アクションの設定] で、次の作業を行います。

    1. []アラームの状態で、のアラーム

    2. [SNS トピックの選択] で、[既存の SNS トピックの選択] を選択します。

    3. を使用する場合通知の送信先で、前の手順で作成した SNS トピックの名前を入力します。

    4. [次へ] を選択します。

  12. [][Name (名前)] と「」と入力します。名前および説明アラームのために。例えば、CIS-3.5-CloudTrailChanges と指定します。続いて、[次へ] を選択します。

  13. []プレビューと作成で、アラーム設定を確認します。次に [アラームの作成] を選択します。

3.6 — ログメトリクスフィルターとアラームが存在することを確認しますAWS Management Console認証の失敗

緊急度:

AWS Configルール: なし

CloudWatch Logs を CloudTrail ログに転送し、対応するメトリクスフィルターとアラームを確立することで、API 呼び出しのリアルタイムモニタリングを実行できます。

CIS は、メトリクスフィルターと失敗したコンソール認証試行に対するアラームを作成することをお勧めします。失敗したコンソールログインをモニタリングすると、認証情報をブルートフォースする試みを検出するためのリードタイムが短縮される可能性があります。これにより、ソース IPなど、相関性のある他のイベントで使用できるインジケータが提供される場合があります。

このチェックを実行するために、Security Hub はカスタムロジックを使用して、のコントロール 3.6 に規定された正確な監査手順を実行します。CISAWS基礎ベンチマーク v1.2。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

注記

Security Hub がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡が検索されます。これらの証跡は、別のアカウントに属する組織の証跡である可能性があります。マルチリージョンの証跡は、別のリージョンに基づいている場合もあります。

チェックの結果はFAILED以下の場合における知見。

  • トレイルは設定されていません。

  • 現在のリージョンにあり、現在のアカウントが所有している利用可能な証跡は、管理要件を満たしていません。

チェックの結果、制御ステータスはNO_DATA以下の場合は、

  • マルチリージョンの証跡は、別のリージョンに基づいています。Security Hub は、証跡のベースとなるリージョンでのみ結果を生成できます。

  • マルチリージョンの証跡は、別のアカウントに属しています。Security Hub は、証跡を所有するアカウントの調査結果のみを生成できます。

アラームの場合、現在のアカウントが参照されている Amazon SNS トピックを所有しているか、listSubscriptionAmazon SNS トピックへのアクセス。それ以外の場合は、Security HubWARNINGコントロールの所見。

Remediation

この問題を修正するためのステップには、Amazon SNS トピック、CloudTrail 証跡、メトリクスフィルター、およびメトリクスフィルターのアラームの設定が含まれます。

Amazon SNS トピックを作成する

  1. Amazon SNS コンソール(https://console.aws.amazon.com/sns/v3/home)を開きます。

  2. すべての CIS アラームを受信する Amazon SNS トピックを作成します。

    トピックに少なくとも 1 人の受信者を作成します。詳細については、「」を参照してください。Amazon SNS の開始方法Amazon Simple Notification Service デベロッパーガイド

次に、すべてのリージョンに適用されるアクティブなCloudTrail をセットアップします。これを行うには、2.1 — CloudTrail がすべてのリージョンで有効になっていることを確認します の修正手順に従います。

CloudTrail 証跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。そのロググループのメトリックスフィルタを作成します。

最後に、メトリクスフィルターとアラームを作成します。

メトリクスフィルターとアラームを作成するには

  1. CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。

  2. ナビゲーションペインで、[Log groups] (ロググループ) を選択します。

  3. 作成した CloudTrail 証跡に関連付けられている CloudWatch Logs ロググループのチェックボックスをオンにします。

  4. 送信元アクションで、メトリクスフィルターの作成

  5. []パターンを定義する] で、次の作業を行います。

    1. 次のパターンをコピーして、[Filter Pattern (フィルターパターン)] フィールドに貼り付けます。

      {($.eventName=ConsoleLogin) && ($.errorMessage="Failed authentication")}
    2. [次へ] を選択します。

  6. []メトリクスの割り当て] で、次の作業を行います。

    1. Eclipseフィルタ名で、メトリクスフィルタの名前を入力します。

    2. を使用する場合メトリクス名前空間「」と入力します。LogMetrics

      すべての CIS ログメトリックフィルタに同じ名前空間を使用する場合、すべての CIS Benchmark メトリックがグループ化されます。

    3. を使用する場合メトリクス名で、メトリックスの名前を入力します。メトリクスの名前を覚えておいてください。アラームの作成時にメトリクスを選択する必要があります。

    4. [メトリクス値] に「1」と入力します。

    5. [次へ] を選択します。

  7. []確認と作成で、新しいメトリックフィルタに入力した情報を確認します。次に [] を選択します。メトリクスフィルターの作成

  8. [メトリクスフィルタータブを選択し、作成したメトリクスフィルターを選択します。

    メトリクスフィルタを選択するには、右上のチェックボックスを選択します。

  9. [Create Alarm] を選択します。

  10. []メトリックと条件の指定] で、次の作業を行います。

    1. []メトリクスで、値をデフォルトのままにしておきます。使用できる統計の詳細については、「」を参照してください。統計Amazon CloudWatch ユーザーガイド

    2. []条件、に対してThresholdで、静的

    3. を使用する場合アラーム条件を定義します。で、以上

    4. を使用する場合しきい値を定義します。「」と入力します。1

    5. [次へ] を選択します。

  11. []アクションの設定] で、次の作業を行います。

    1. []アラームの状態で、のアラーム

    2. [SNS トピックの選択] で、[既存の SNS トピックの選択] を選択します。

    3. を使用する場合通知の送信先で、前の手順で作成した SNS トピックの名前を入力します。

    4. [次へ] を選択します。

  12. [][Name (名前)] と「」と入力します。名前および説明アラームのために。例えば、CIS-3.6-ConsoleAuthenticationFailure と指定します。続いて、[次へ] を選択します。

  13. []プレビューと作成で、アラーム設定を確認します。次に [アラームの作成] を選択します。

3.7 — カスタマー管理キーの無効化またはスケジュールされた削除に対してログメトリクスフィルタとアラームが存在することを確認します

緊急度:

AWS Configルール: なし

CloudWatch Logs を CloudTrail ログに転送し、対応するメトリクスフィルターとアラームを確立することで、API 呼び出しのリアルタイムモニタリングを実行できます。

CISは、状態を無効またはスケジュールされた削除に変更したカスタマー管理キーに対して、メトリクスフィルタとアラームを作成します。無効になっているか、削除されたキーで暗号化されたデータにはアクセスできなくなります。

このチェックを実行するために、Security Hub はカスタムロジックを使用して、のコントロール 3.7 に規定された正確な監査手順を実行します。CISAWS基礎ベンチマーク v1.2。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

注記

Security Hub がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡が検索されます。これらの証跡は、別のアカウントに属する組織の証跡である可能性があります。マルチリージョンの証跡は、別のリージョンに基づいている場合もあります。

チェックの結果はFAILED以下の場合における知見。

  • トレイルは設定されていません。

  • 現在のリージョンにあり、現在のアカウントが所有している利用可能な証跡は、管理要件を満たしていません。

チェックの結果、制御ステータスはNO_DATA以下の場合は、

  • マルチリージョンの証跡は、別のリージョンに基づいています。Security Hub は、証跡のベースとなるリージョンでのみ結果を生成できます。

  • マルチリージョンの証跡は、別のアカウントに属しています。Security Hub は、証跡を所有するアカウントの調査結果のみを生成できます。

アラームの場合、現在のアカウントが参照されている Amazon SNS トピックを所有しているか、listSubscriptionAmazon SNS トピックへのアクセス。それ以外の場合は、Security HubWARNINGコントロールの所見。

Remediation

この問題を修正するためのステップには、Amazon SNS トピック、CloudTrail 証跡、メトリクスフィルター、およびメトリクスフィルターのアラームの設定が含まれます。

Amazon SNS トピックを作成する

  1. Amazon SNS コンソール(https://console.aws.amazon.com/sns/v3/home)を開きます。

  2. すべての CIS アラームを受信する Amazon SNS トピックを作成します。

    トピックに少なくとも 1 人の受信者を作成します。詳細については、「」を参照してください。Amazon SNS の開始方法Amazon Simple Notification Service デベロッパーガイド

次に、すべてのリージョンに適用されるアクティブなCloudTrail をセットアップします。これを行うには、2.1 — CloudTrail がすべてのリージョンで有効になっていることを確認します の修正手順に従います。

CloudTrail 証跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。そのロググループのメトリックスフィルタを作成します。

最後に、メトリクスフィルターとアラームを作成します。

メトリクスフィルターとアラームを作成するには

  1. CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。

  2. ナビゲーションペインで、[Log groups] (ロググループ) を選択します。

  3. 作成した CloudTrail 証跡に関連付けられている CloudWatch Logs ロググループのチェックボックスをオンにします。

  4. 送信元アクションで、メトリクスフィルターの作成

  5. []パターンを定義する] で、次の作業を行います。

    1. 次のパターンをコピーして、[Filter Pattern (フィルターパターン)] フィールドに貼り付けます。

      {($.eventSource=kms.amazonaws.com) && (($.eventName=DisableKey) || ($.eventName=ScheduleKeyDeletion))}
    2. [次へ] を選択します。

  6. []メトリクスの割り当て] で、次の作業を行います。

    1. Eclipseフィルタ名で、メトリクスフィルタの名前を入力します。

    2. を使用する場合メトリクス名前空間「」と入力します。LogMetrics

      すべての CIS ログメトリックフィルタに同じ名前空間を使用する場合、すべての CIS Benchmark メトリックがグループ化されます。

    3. を使用する場合メトリクス名に、メトリックスの名前を入力します。メトリクスの名前を覚えておいてください。アラームの作成時にメトリクスを選択する必要があります。

    4. [メトリクス値] に「1」と入力します。

    5. [次へ] を選択します。

  7. []確認と作成で、新しいメトリックフィルタに入力した情報を確認します。次に [] を選択します。メトリクスフィルターの作成

  8. [メトリクスフィルタータブを選択し、作成したメトリクスフィルターを選択します。

    メトリクスフィルタを選択するには、右上のチェックボックスを選択します。

  9. [Create Alarm] を選択します。

  10. []メトリックと条件の指定] で、次の作業を行います。

    1. []メトリクスで、値をデフォルトのままにしておきます。使用できる統計の詳細については、「」を参照してください。統計Amazon CloudWatch ユーザーガイド

    2. []条件、に対してThresholdで、静的

    3. を使用する場合アラーム条件を定義します。で、以上

    4. を使用する場合しきい値を定義します。「」と入力します。1

    5. [次へ] を選択します。

  11. []アクションの設定] で、次の作業を行います。

    1. []アラームの状態で、のアラーム

    2. [SNS トピックの選択] で、[既存の SNS トピックの選択] を選択します。

    3. を使用する場合通知の送信先で、前の手順で作成した SNS トピックの名前を入力します。

    4. [次へ] を選択します。

  12. [][Name (名前)] と「」と入力します。名前および説明アラームのために。例えば、CIS-3.7-DisableOrDeleteCMK と指定します。続いて、[次へ] を選択します。

  13. []プレビューと作成で、アラーム設定を確認します。次に [アラームの作成] を選択します。

3.8 — S3 バケットの変更に対するメトリクスフィルターとアラームが存在することを確認します

緊急度:

AWS Configルール: なし

CloudTrail ログを CloudWatch Logs に転送し、対応するメトリクスフィルターとアラームを確立することで、API 呼び出しのリアルタイムモニタリングを実行できます。

S3 バケットポリシーへの変更に対するメトリクスフィルターとアラームを作成します。これらの変更をモニタリングすることで、機密性の高い S3 バケットで許容ポリシーを検出して修正する時間を短縮できます。

このチェックを実行するために、Security Hub はカスタムロジックを使用して、のコントロール 3.8 に規定された正確な監査手順を実行します。CISAWS基礎ベンチマーク v1.2。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

注記

Security Hub がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡が検索されます。これらの証跡は、別のアカウントに属する組織の証跡である可能性があります。マルチリージョンの証跡は、別のリージョンに基づいている場合もあります。

チェックの結果はFAILED以下の場合における知見。

  • トレイルは設定されていません。

  • 現在のリージョンにあり、現在のアカウントが所有している利用可能な証跡は、管理要件を満たしていません。

チェックの結果、制御ステータスはNO_DATA以下の場合は、

  • マルチリージョンの証跡は、別のリージョンに基づいています。Security Hub は、証跡のベースとなるリージョンでのみ結果を生成できます。

  • マルチリージョンの証跡は、別のアカウントに属しています。Security Hub は、証跡を所有するアカウントの調査結果のみを生成できます。

アラームの場合、現在のアカウントが参照されている Amazon SNS トピックを所有しているか、listSubscriptionAmazon SNS トピックへのアクセス。それ以外の場合は、Security HubWARNINGコントロールの所見。

Remediation

この問題を修正するためのステップには、Amazon SNS トピック、CloudTrail 証跡、メトリクスフィルター、およびメトリクスフィルターのアラームの設定が含まれます。

Amazon SNS トピックを作成する

  1. Amazon SNS コンソール(https://console.aws.amazon.com/sns/v3/home)を開きます。

  2. すべての CIS アラームを受信する Amazon SNS トピックを作成します。

    トピックに少なくとも 1 人の受信者を作成します。詳細については、「」を参照してください。Amazon SNS の開始方法Amazon Simple Notification Service デベロッパーガイド

次に、すべてのリージョンに適用されるアクティブなCloudTrail をセットアップします。これを行うには、2.1 — CloudTrail がすべてのリージョンで有効になっていることを確認します の修正手順に従います。

CloudTrail 証跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。そのロググループのメトリックスフィルタを作成します。

最後に、メトリクスフィルターとアラームを作成します。

メトリクスフィルターとアラームを作成するには

  1. CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。

  2. ナビゲーションペインで、[Log groups] (ロググループ) を選択します。

  3. 作成した CloudTrail 証跡に関連付けられている CloudWatch Logs ロググループのチェックボックスをオンにします。

  4. 送信元アクションで、メトリクスフィルターの作成

  5. []パターンを定義する] で、次の作業を行います。

    1. 次のパターンをコピーして、[Filter Pattern (フィルターパターン)] フィールドに貼り付けます。

      {($.eventSource=s3.amazonaws.com) && (($.eventName=PutBucketAcl) || ($.eventName=PutBucketPolicy) || ($.eventName=PutBucketCors) || ($.eventName=PutBucketLifecycle) || ($.eventName=PutBucketReplication) || ($.eventName=DeleteBucketPolicy) || ($.eventName=DeleteBucketCors) || ($.eventName=DeleteBucketLifecycle) || ($.eventName=DeleteBucketReplication))}
    2. [次へ] を選択します。

  6. []メトリクスの割り当て] で、次の作業を行います。

    1. Eclipseフィルタ名で、メトリクスフィルタの名前を入力します。

    2. を使用する場合メトリクス名前空間「」と入力します。LogMetrics

      すべての CIS ログメトリックフィルタに同じ名前空間を使用する場合、すべての CIS Benchmark メトリックがグループ化されます。

    3. を使用する場合メトリクス名に、メトリックスの名前を入力します。メトリクスの名前を覚えておいてください。アラームの作成時にメトリクスを選択する必要があります。

    4. [メトリクス値] に「1」と入力します。

    5. [次へ] を選択します。

  7. []確認と作成で、新しいメトリックフィルタに入力した情報を確認します。次に [] を選択します。メトリクスフィルターの作成

  8. [メトリクスフィルタータブを選択し、作成したメトリクスフィルターを選択します。

    メトリクスフィルタを選択するには、右上のチェックボックスを選択します。

  9. [Create Alarm] を選択します。

  10. []メトリックと条件の指定] で、次の作業を行います。

    1. []メトリクス、に対してStatisticで、平均。使用できる統計の詳細については、「」を参照してください。統計Amazon CloudWatch ユーザーガイド

    2. []条件、に対してThresholdで、静的

    3. を使用する場合アラーム条件を定義します。で、以上

    4. を使用する場合しきい値を定義します。「」と入力します。1

    5. [次へ] を選択します。

  11. []アクションの設定] で、次の作業を行います。

    1. []アラームの状態で、のアラーム

    2. [SNS トピックの選択] で、[既存の SNS トピックの選択] を選択します。

    3. を使用する場合通知の送信先で、前の手順で作成した SNS トピックの名前を入力します。

    4. [次へ] を選択します。

  12. [][Name (名前)] と「」と入力します。名前および説明アラームのために。例えば、CIS-3.8-S3BucketPolicyChanges と指定します。続いて、[次へ] を選択します。

  13. []プレビューと作成で、アラーム設定を確認します。次に [アラームの作成] を選択します。

3.9 — ログメトリクスフィルターとアラームが存在することを確認しますAWS Config設定変更

緊急度:

AWS Configルール: なし

CloudTrail ログを CloudWatch Logs に転送し、対応するメトリクスフィルターとアラームを確立することで、API 呼び出しのリアルタイムモニタリングを実行できます。

CIS は、への変更に対するメトリクスフィルターとアラームを作成します。AWS Config構成設定。これらの変更をモニタリングすることで、アカウント内の設定アイテムに対する継続的な可視性を確保できます。

このチェックを実行するために、Security Hub はカスタムロジックを使用して、のコントロール 3.9 に規定された正確な監査手順を実行します。CISAWS基礎ベンチマーク v1.2。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

注記

Security Hub がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡が検索されます。これらの証跡は、別のアカウントに属する組織の証跡である可能性があります。マルチリージョンの証跡は、別のリージョンに基づいている場合もあります。

チェックの結果はFAILED以下の場合における知見。

  • トレイルは設定されていません。

  • 現在のリージョンにあり、現在のアカウントが所有している利用可能な証跡は、管理要件を満たしていません。

チェックの結果、制御ステータスはNO_DATA以下の場合は、

  • マルチリージョンの証跡は、別のリージョンに基づいています。Security Hub は、証跡のベースとなるリージョンでのみ結果を生成できます。

  • マルチリージョンの証跡は、別のアカウントに属しています。Security Hub は、証跡を所有するアカウントの調査結果のみを生成できます。

アラームの場合、現在のアカウントが参照されている Amazon SNS トピックを所有しているか、listSubscriptionAmazon SNS トピックへのアクセス。それ以外の場合は、Security HubWARNINGコントロールの所見。

Remediation

この問題を修正するためのステップには、Amazon SNS トピック、CloudTrail 証跡、メトリクスフィルター、およびメトリクスフィルターのアラームの設定が含まれます。

Amazon SNS トピックを作成する

  1. Amazon SNS コンソール(https://console.aws.amazon.com/sns/v3/home)を開きます。

  2. すべての CIS アラームを受信する Amazon SNS トピックを作成します。

    トピックに少なくとも 1 人の受信者を作成します。詳細については、「」を参照してください。Amazon SNS の開始方法Amazon Simple Notification Service デベロッパーガイド

次に、すべてのリージョンに適用されるアクティブなCloudTrail をセットアップします。これを行うには、2.1 — CloudTrail がすべてのリージョンで有効になっていることを確認します の修正手順に従います。

CloudTrail 証跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。そのロググループのメトリックスフィルタを作成します。

最後に、メトリクスフィルターとアラームを作成します。

メトリクスフィルターとアラームを作成するには

  1. CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。

  2. ナビゲーションペインで、[Log groups] (ロググループ) を選択します。

  3. 作成した CloudTrail 証跡に関連付けられている CloudWatch Logs ロググループのチェックボックスをオンにします。

  4. 送信元アクションで、メトリクスフィルターの作成

  5. []パターンを定義する] で、次の作業を行います。

    1. 次のパターンをコピーして、[Filter Pattern (フィルターパターン)] フィールドに貼り付けます。

      {($.eventSource=config.amazonaws.com) && (($.eventName=StopConfigurationRecorder) || ($.eventName=DeleteDeliveryChannel) || ($.eventName=PutDeliveryChannel) || ($.eventName=PutConfigurationRecorder))}
    2. [次へ] を選択します。

  6. []メトリクスの割り当て] で、次の作業を行います。

    1. Eclipseフィルタ名で、メトリクスフィルタの名前を入力します。

    2. を使用する場合メトリクス名前空間「」と入力します。LogMetrics

      すべての CIS ログメトリックフィルタに同じ名前空間を使用する場合、すべての CIS Benchmark メトリックがグループ化されます。

    3. を使用する場合メトリクス名に、メトリックスの名前を入力します。メトリクスの名前を覚えておいてください。アラームの作成時にメトリクスを選択する必要があります。

    4. [メトリクス値] に「1」と入力します。

    5. [次へ] を選択します。

  7. []確認と作成で、新しいメトリックフィルタに入力した情報を確認します。次に [] を選択します。メトリクスフィルターの作成

  8. [メトリクスフィルタータブを選択し、作成したメトリクスフィルターを選択します。

    メトリクスフィルタを選択するには、右上のチェックボックスを選択します。

  9. [Create Alarm] を選択します。

  10. []メトリックと条件の指定] で、次の作業を行います。

    1. []メトリクスで、値をデフォルトのままにしておきます。使用できる統計の詳細については、「」を参照してください。統計Amazon CloudWatch ユーザーガイド

    2. []条件、に対してThresholdで、静的

    3. を使用する場合アラーム条件を定義します。で、以上

    4. を使用する場合しきい値を定義します。「」と入力します。1

    5. [次へ] を選択します。

  11. []アクションの設定] で、次の作業を行います。

    1. []アラームの状態で、のアラーム

    2. [SNS トピックの選択] で、[既存の SNS トピックの選択] を選択します。

    3. を使用する場合通知の送信先で、前の手順で作成した SNS トピックの名前を入力します。

    4. [次へ] を選択します。

  12. [][Name (名前)] と「」と入力します。名前および説明アラームのために。例えば、CIS-3.9-AWSConfigChanges と指定します。続いて、[次へ] を選択します。

  13. []プレビューと作成で、アラーム設定を確認します。次に [アラームの作成] を選択します。

3.10 — セキュリティグループの変更に対するメトリクスフィルターとアラームが存在することを確認します

緊急度:

AWS Configルール: なし

CloudTrail ログを CloudWatch Logs に転送し、対応するメトリクスフィルターとアラームを確立することで、API 呼び出しのリアルタイムモニタリングを実行できます。セキュリティグループは、VPC の入力トラフィックと出力トラフィックを制御するステートフルパケットフィルターです。

CIS は、セキュリティグループへの変更に対するメトリクスフィルターとアラームを作成します。これらの変更をモニタリングすることにより、 リソースやサービスが意図せずに公開されないようにすることができます。

このチェックを実行するために、Security Hub はカスタムロジックを使用して、のコントロール 3.10 に規定された正確な監査手順を実行します。CISAWS基礎ベンチマーク v1.2。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

注記

Security Hub がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡が検索されます。これらの証跡は、別のアカウントに属する組織の証跡である可能性があります。マルチリージョンの証跡は、別のリージョンに基づいている場合もあります。

チェックの結果はFAILED以下の場合における知見。

  • トレイルは設定されていません。

  • 現在のリージョンにあり、現在のアカウントが所有している利用可能な証跡は、管理要件を満たしていません。

チェックの結果、制御ステータスはNO_DATA以下の場合は、

  • マルチリージョンの証跡は、別のリージョンに基づいています。Security Hub は、証跡のベースとなるリージョンでのみ結果を生成できます。

  • マルチリージョンの証跡は、別のアカウントに属しています。Security Hub は、証跡を所有するアカウントの調査結果のみを生成できます。

アラームの場合、現在のアカウントが参照されている Amazon SNS トピックを所有しているか、listSubscriptionAmazon SNS トピックへのアクセス。それ以外の場合は、Security HubWARNINGコントロールの所見。

Remediation

この問題を修正するためのステップには、Amazon SNS トピック、CloudTrail 証跡、メトリクスフィルター、およびメトリクスフィルターのアラームの設定が含まれます。

Amazon SNS トピックを作成する

  1. Amazon SNS コンソール(https://console.aws.amazon.com/sns/v3/home)を開きます。

  2. すべての CIS アラームを受信する Amazon SNS トピックを作成します。

    トピックに少なくとも 1 人の受信者を作成します。詳細については、「」を参照してください。Amazon SNS の開始方法Amazon Simple Notification Service デベロッパーガイド

次に、すべてのリージョンに適用されるアクティブなCloudTrail をセットアップします。これを行うには、2.1 — CloudTrail がすべてのリージョンで有効になっていることを確認します の修正手順に従います。

CloudTrail 証跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。そのロググループのメトリックスフィルタを作成します。

最後に、メトリクスフィルターとアラームを作成します。

メトリクスフィルターとアラームを作成するには

  1. CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。

  2. ナビゲーションペインで、[Log groups] (ロググループ) を選択します。

  3. 作成した CloudTrail 証跡に関連付けられている CloudWatch Logs ロググループのチェックボックスをオンにします。

  4. 送信元アクションで、メトリクスフィルターの作成

  5. []パターンを定義する] で、次の作業を行います。

    1. 次のパターンをコピーして、[Filter Pattern (フィルターパターン)] フィールドに貼り付けます。

      {($.eventName=AuthorizeSecurityGroupIngress) || ($.eventName=AuthorizeSecurityGroupEgress) || ($.eventName=RevokeSecurityGroupIngress) || ($.eventName=RevokeSecurityGroupEgress) || ($.eventName=CreateSecurityGroup) || ($.eventName=DeleteSecurityGroup)}
    2. [次へ] を選択します。

  6. []メトリクスの割り当て] で、次の作業を行います。

    1. Eclipseフィルタ名で、メトリクスフィルタの名前を入力します。

    2. を使用する場合メトリクス名前空間「」と入力します。LogMetrics

      すべての CIS ログメトリックフィルタに同じ名前空間を使用する場合、すべての CIS Benchmark メトリックがグループ化されます。

    3. を使用する場合メトリクス名に、メトリックスの名前を入力します。メトリクスの名前を覚えておいてください。アラームの作成時にメトリクスを選択する必要があります。

    4. [メトリクス値] に「1」と入力します。

    5. [次へ] を選択します。

  7. []確認と作成で、新しいメトリックフィルタに入力した情報を確認します。次に [] を選択します。メトリクスフィルターの作成

  8. [メトリクスフィルタータブを選択し、作成したメトリクスフィルターを選択します。

    メトリクスフィルタを選択するには、右上のチェックボックスを選択します。

  9. [Create Alarm] を選択します。

  10. []メトリックと条件の指定] で、次の作業を行います。

    1. []メトリクスで、値をデフォルトのままにしておきます。使用できる統計の詳細については、「」を参照してください。統計Amazon CloudWatch ユーザーガイド

    2. []条件、に対してThresholdで、静的

    3. を使用する場合アラーム条件を定義します。で、以上

    4. を使用する場合しきい値を定義します。「」と入力します。1

    5. [次へ] を選択します。

  11. []アクションの設定] で、次の作業を行います。

    1. []アラームの状態で、のアラーム

    2. [SNS トピックの選択] で、[既存の SNS トピックの選択] を選択します。

    3. を使用する場合通知の送信先で、前の手順で作成した SNS トピックの名前を入力します。

    4. [次へ] を選択します。

  12. [][Name (名前)] と「」と入力します。名前および説明アラームのために。例えば、CIS-3.10-SecurityGroupChanges と指定します。続いて、[次へ] を選択します。

  13. []プレビューと作成で、アラーム設定を確認します。次に [アラームの作成] を選択します。

3.11 — ネットワークアクセスコントロールリスト (NACL) への変更に対するログメトリクスとアラームが存在することを確認します

緊急度:

AWS Configルール: なし

CloudTrail ログを CloudWatch Logs に転送し、対応するメトリクスフィルターとアラームを確立することで、API 呼び出しのリアルタイムモニタリングを実行できます。NACL は、VPC 内のサブネットの入力トラフィックと出力トラフィックを制御するためのステートレスパケットフィルターとして使用されます。

NACL への変更に対するメトリクスフィルターとアラームを作成します。これらの変更をモニタリングすることにより、AWS リソースやサービスが意図せずに公開されないようにすることができます。

このチェックを実行するために、Security Hub はカスタムロジックを使用して、のコントロール 3.11 に規定された正確な監査手順を実行します。CISAWS基礎ベンチマーク v1.2。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

注記

Security Hub がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡が検索されます。これらの証跡は、別のアカウントに属する組織の証跡である可能性があります。マルチリージョンの証跡は、別のリージョンに基づいている場合もあります。

チェックの結果はFAILED以下の場合における知見。

  • トレイルは設定されていません。

  • 現在のリージョンにあり、現在のアカウントが所有している利用可能な証跡は、管理要件を満たしていません。

チェックの結果、制御ステータスはNO_DATA以下の場合は、

  • マルチリージョンの証跡は、別のリージョンに基づいています。Security Hub は、証跡のベースとなるリージョンでのみ結果を生成できます。

  • マルチリージョンの証跡は、別のアカウントに属しています。Security Hub は、証跡を所有するアカウントの調査結果のみを生成できます。

アラームの場合、現在のアカウントが参照されている Amazon SNS トピックを所有しているか、listSubscriptionAmazon SNS トピックへのアクセス。それ以外の場合は、Security HubWARNINGコントロールの所見。

Remediation

この問題を修正するためのステップには、Amazon SNS トピック、CloudTrail 証跡、メトリクスフィルター、およびメトリクスフィルターのアラームの設定が含まれます。

Amazon SNS トピックを作成する

  1. Amazon SNS コンソール(https://console.aws.amazon.com/sns/v3/home)を開きます。

  2. すべての CIS アラームを受信する Amazon SNS トピックを作成します。

    トピックに少なくとも 1 人の受信者を作成します。詳細については、「」を参照してください。Amazon SNS の開始方法Amazon Simple Notification Service デベロッパーガイド

次に、すべてのリージョンに適用されるアクティブなCloudTrail をセットアップします。これを行うには、2.1 — CloudTrail がすべてのリージョンで有効になっていることを確認します の修正手順に従います。

CloudTrail 証跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。そのロググループのメトリックスフィルタを作成します。

最後に、メトリクスフィルターとアラームを作成します。

メトリクスフィルターとアラームを作成するには

  1. CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。

  2. ナビゲーションペインで、[Log groups] (ロググループ) を選択します。

  3. 作成した CloudTrail 証跡に関連付けられている CloudWatch Logs ロググループのチェックボックスをオンにします。

  4. 送信元アクションで、メトリックフィルタの作成

  5. []パターンを定義する] で、次の作業を行います。

    1. 次のパターンをコピーして、[Filter Pattern (フィルターパターン)] フィールドに貼り付けます。

      {($.eventName=CreateNetworkAcl) || ($.eventName=CreateNetworkAclEntry) || ($.eventName=DeleteNetworkAcl) || ($.eventName=DeleteNetworkAclEntry) || ($.eventName=ReplaceNetworkAclEntry) || ($.eventName=ReplaceNetworkAclAssociation)}
    2. [次へ] を選択します。

  6. []メトリクスの割り当て] で、次の作業を行います。

    1. Eclipseフィルタ名で、メトリクスフィルタの名前を入力します。

    2. を使用する場合メトリクス名前空間「」と入力します。LogMetrics

      すべての CIS ログメトリックフィルタに同じ名前空間を使用する場合、すべての CIS Benchmark メトリックがグループ化されます。

    3. を使用する場合メトリクス名に、メトリックスの名前を入力します。メトリクスの名前を覚えておいてください。アラームの作成時にメトリクスを選択する必要があります。

    4. [メトリクス値] に「1」と入力します。

    5. [次へ] を選択します。

  7. []確認と作成で、新しいメトリックフィルタに入力した情報を確認します。次に [] を選択します。メトリクスフィルターの作成

  8. [メトリクスフィルタータブを選択し、作成したメトリクスフィルターを選択します。

    メトリクスフィルタを選択するには、右上のチェックボックスを選択します。

  9. [Create Alarm] を選択します。

  10. []メトリックと条件の指定] で、次の作業を行います。

    1. []メトリクスで、値をデフォルトのままにしておきます。使用できる統計の詳細については、「」を参照してください。統計Amazon CloudWatch ユーザーガイド

    2. []条件、に対してThresholdで、静的

    3. を使用する場合アラーム条件を定義します。で、以上

    4. を使用する場合しきい値を定義します。「」と入力します。1

    5. [次へ] を選択します。

  11. []アクションの設定] で、次の作業を行います。

    1. []アラームの状態で、のアラーム

    2. [SNS トピックの選択] で、[既存の SNS トピックの選択] を選択します。

    3. を使用する場合通知の送信先で、前の手順で作成した SNS トピックの名前を入力します。

    4. [次へ] を選択します。

  12. [][Name (名前)] とに、a と入力します。名前および説明アラームのために。例えば、CIS-3.11-NetworkACLChanges と指定します。続いて、[次へ] を選択します。

  13. []プレビューと作成で、アラーム設定を確認します。次に [アラームの作成] を選択します。

3.12 — ネットワークゲートウェイへの変更に対するログメトリクスフィルターとアラームが存在することを確認します

緊急度:

AWS Configルール: なし

CloudTrail ログを CloudWatch Logs に転送し、対応するメトリクスフィルターとアラームを確立することで、API 呼び出しのリアルタイムモニタリングを実行できます。ネットワークゲートウェイは VPC の外部送信先にトラフィックを送受信する必要があります。

CIS は、ネットワークゲートウェイへの変更に対するメトリクスフィルターとアラームを作成します。これらの変更をモニタリングすることで、すべての入力トラフィックと出力トラフィックが制御パスを介して VPC ボーダーを通過するようになります。

このチェックを実行するために、Security Hub はカスタムロジックを使用して、のコントロール 3.12 に規定された正確な監査手順を実行します。CISAWS基礎ベンチマーク v1.2。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

注記

Security Hub がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡が検索されます。これらの証跡は、別のアカウントに属する組織の証跡である可能性があります。マルチリージョンの証跡は、別のリージョンに基づいている場合もあります。

チェックの結果FAILED以下の場合における知見。

  • トレイルは設定されていません。

  • 現在のリージョンにあり、現在のアカウントが所有している利用可能な証跡は、管理要件を満たしていません。

チェックの結果、制御ステータスはNO_DATA以下の場合は、

  • マルチリージョンの証跡は、別のリージョンに基づいています。Security Hub は、証跡のベースとなるリージョンでのみ結果を生成できます。

  • マルチリージョンの証跡は、別のアカウントに属しています。Security Hub は、証跡を所有するアカウントの調査結果のみを生成できます。

アラームの場合、現在のアカウントが参照されている Amazon SNS トピックを所有しているか、listSubscriptionAmazon SNS トピックへのアクセス。それ以外の場合は、Security HubWARNINGコントロールの所見。

Remediation

この問題を修正するためのステップには、Amazon SNS トピック、CloudTrail 証跡、メトリクスフィルター、およびメトリクスフィルターのアラームの設定が含まれます。

Amazon SNS トピックを作成する

  1. Amazon SNS コンソール(https://console.aws.amazon.com/sns/v3/home)を開きます。

  2. すべての CIS アラームを受信する Amazon SNS トピックを作成します。

    トピックに少なくとも 1 人の受信者を作成します。詳細については、「」を参照してください。Amazon SNS の開始方法Amazon Simple Notification Service デベロッパーガイド

次に、すべてのリージョンに適用されるアクティブなCloudTrail をセットアップします。これを行うには、2.1 — CloudTrail がすべてのリージョンで有効になっていることを確認します の修正手順に従います。

CloudTrail 証跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。そのロググループのメトリックスフィルタを作成します。

最後に、メトリクスフィルターとアラームを作成します。

メトリクスフィルターとアラームを作成するには

  1. CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。

  2. ナビゲーションペインで、[Log groups] (ロググループ) を選択します。

  3. 作成した CloudTrail 証跡に関連付けられている CloudWatch Logs ロググループのチェックボックスをオンにします。

  4. 送信元アクションで、メトリックフィルタの作成

  5. []パターンを定義する] で、次の作業を行います。

    1. 次のパターンをコピーして、[Filter Pattern (フィルターパターン)] フィールドに貼り付けます。

      {($.eventName=CreateCustomerGateway) || ($.eventName=DeleteCustomerGateway) || ($.eventName=AttachInternetGateway) || ($.eventName=CreateInternetGateway) || ($.eventName=DeleteInternetGateway) || ($.eventName=DetachInternetGateway)}
    2. [次へ] を選択します。

  6. []メトリクスの割り当て] で、次の作業を行います。

    1. Eclipseフィルタ名で、メトリクスフィルタの名前を入力します。

    2. を使用する場合メトリクス名前空間「」と入力します。LogMetrics

      すべての CIS ログメトリックフィルタに同じ名前空間を使用する場合、すべての CIS Benchmark メトリックがグループ化されます。

    3. を使用する場合メトリクス名に、メトリックスの名前を入力します。メトリクスの名前を覚えておいてください。アラームの作成時にメトリクスを選択する必要があります。

    4. [メトリクス値] に「1」と入力します。

    5. [次へ] を選択します。

  7. []確認と作成で、新しいメトリックフィルタに入力した情報を確認します。次に [] を選択します。メトリクスフィルターの作成

  8. [メトリクスフィルタータブを選択し、作成したメトリクスフィルターを選択します。

    メトリクスフィルタを選択するには、右上のチェックボックスを選択します。

  9. [Create Alarm] を選択します。

  10. []メトリックと条件の指定] で、次の作業を行います。

    1. []メトリクスで、値をデフォルトのままにしておきます。使用できる統計の詳細については、「」を参照してください。統計Amazon CloudWatch ユーザーガイド

    2. []条件、に対してThresholdで、静的

    3. を使用する場合アラーム条件を定義します。で、以上

    4. を使用する場合しきい値を定義します。「」と入力します。1

    5. [次へ] を選択します。

  11. []アクションの設定] で、次の作業を行います。

    1. []アラーム状態トリガーで、のアラーム

    2. [SNS トピックの選択] で、[既存の SNS トピックの選択] を選択します。

    3. を使用する場合通知の送信先で、前の手順で作成した SNS トピックの名前を入力します。

    4. [次へ] を選択します。

  12. [][Name (名前)] とに、a と入力します。名前および説明アラームのために。例えば、CIS-3.12-NetworkGatewayChanges と指定します。続いて、[次へ] を選択します。

  13. []プレビューと作成で、アラーム設定を確認します。次に [アラームの作成] を選択します。

3.13 — ルートテーブルの変更に対してログメトリクスフィルターとアラームが存在することを確認します

緊急度:

AWS Configルール: なし

CloudTrail ログを CloudWatch Logs に転送し、対応するメトリクスフィルターとアラームを確立することで、API 呼び出しのリアルタイムモニタリングを実行できます。ルーティングテーブルは、サブネット間およびネットワークゲートウェイへのネットワークトラフィックをルーティングします。

CIS は、ルートテーブルへの変更に対するメトリクスフィルターとアラームを作成します。これらの変更をモニタリングすることで、すべての VPC トラフィックが予定されたパスを通過するようになります。

このチェックを実行するために、Security Hub はカスタムロジックを使用して、のコントロール 3.13 に規定された正確な監査手順を実行します。CISAWS基礎ベンチマーク v1.2。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

注記

Security Hub がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡が検索されます。これらの証跡は、別のアカウントに属する組織の証跡である可能性があります。マルチリージョンの証跡は、別のリージョンに基づいている場合もあります。

チェックの結果FAILED以下の場合における所見:

  • トレイルは設定されていません。

  • 現在のリージョンにあり、現在のアカウントが所有している利用可能な証跡は、管理要件を満たしていません。

チェックの結果、制御ステータスはNO_DATA以下の場合は、

  • マルチリージョンの証跡は、別のリージョンに基づいています。Security Hub は、証跡のベースとなるリージョンでのみ結果を生成できます。

  • マルチリージョンの証跡は、別のアカウントに属しています。Security Hub は、証跡を所有するアカウントの調査結果のみを生成できます。

アラームの場合、現在のアカウントが参照されている Amazon SNS トピックを所有しているか、listSubscriptionAmazon SNS トピックへのアクセス。それ以外の場合は、Security HubWARNINGコントロールの所見。

Remediation

この問題を修正するためのステップには、Amazon SNS トピック、CloudTrail 証跡、メトリクスフィルター、およびメトリクスフィルターのアラームの設定が含まれます。

Amazon SNS トピックを作成する

  1. Amazon SNS コンソール(https://console.aws.amazon.com/sns/v3/home)を開きます。

  2. すべての CIS アラームを受信する Amazon SNS トピックを作成します。

    トピックに少なくとも 1 人の受信者を作成します。詳細については、「」を参照してください。Amazon SNS の開始方法Amazon Simple Notification Service デベロッパーガイド

次に、すべてのリージョンに適用されるアクティブなCloudTrail をセットアップします。これを行うには、2.1 — CloudTrail がすべてのリージョンで有効になっていることを確認します の修正手順に従います。

CloudTrail 証跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。そのロググループのメトリックスフィルタを作成します。

最後に、メトリクスフィルターとアラームを作成します。

メトリクスフィルターとアラームを作成するには

  1. CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。

  2. ナビゲーションペインで、[Log groups] (ロググループ) を選択します。

  3. 作成した CloudTrail 証跡に関連付けられている CloudWatch Logs ロググループのチェックボックスをオンにします。

  4. 送信元アクションで、メトリックフィルタの作成

  5. []パターンを定義する] で、次の作業を行います。

    1. 次のパターンをコピーして、[Filter Pattern (フィルターパターン)] フィールドに貼り付けます。

      {($.eventName=CreateRoute) || ($.eventName=CreateRouteTable) || ($.eventName=ReplaceRoute) || ($.eventName=ReplaceRouteTableAssociation) || ($.eventName=DeleteRouteTable) || ($.eventName=DeleteRoute) || ($.eventName=DisassociateRouteTable)}
    2. [次へ] を選択します。

  6. []メトリクスの割り当て] で、次の作業を行います。

    1. Eclipseフィルタ名で、メトリクスフィルタの名前を入力します。

    2. を使用する場合メトリクス名前空間「」と入力します。LogMetrics

      すべての CIS ログメトリックフィルタに同じ名前空間を使用する場合、すべての CIS Benchmark メトリックがグループ化されます。

    3. を使用する場合メトリクス名に、メトリックスの名前を入力します。メトリクスの名前を覚えておいてください。アラームの作成時にメトリクスを選択する必要があります。

    4. [メトリクス値] に「1」と入力します。

    5. [次へ] を選択します。

  7. []確認と作成で、新しいメトリックフィルタに入力した情報を確認します。次に [] を選択します。メトリクスフィルターの作成

  8. [メトリクスフィルタータブを選択し、作成したメトリクスフィルターを選択します。

    メトリクスフィルタを選択するには、右上のチェックボックスを選択します。

  9. [Create Alarm] を選択します。

  10. []メトリックと条件の指定] で、次の作業を行います。

    1. []メトリクス、に対してStatisticで、平均。使用できる統計の詳細については、「」を参照してください。統計Amazon CloudWatch ユーザーガイド

    2. []条件、に対してThresholdで、静的

    3. を使用する場合アラーム条件を定義します。で、以上

    4. を使用する場合しきい値を定義します。「」と入力します。1

    5. [次へ] を選択します。

  11. []アクションの設定] で、次の作業を行います。

    1. []アラーム状態トリガーで、のアラーム

    2. [SNS トピックの選択] で、[既存の SNS トピックの選択] を選択します。

    3. を使用する場合通知の送信先で、前の手順で作成した SNS トピックの名前を入力します。

    4. [次へ] を選択します。

  12. [][Name (名前)] とに、a と入力します。名前および説明アラームのために。例えば、CIS-3.13-RouteTableChanges と指定します。続いて、[次へ] を選択します。

  13. []プレビューと作成で、アラーム設定を確認します。次に [アラームの作成] を選択します。

3.14 — VPC の変更に対してログメトリクスフィルターとアラームが存在することを確認します

緊急度:

AWS Configルール: なし

CloudTrail ログを CloudWatch Logs に転送し、対応するメトリクスフィルターとアラームを確立することで、API 呼び出しのリアルタイムモニタリングを実行できます。1 つのアカウントに複数の VPC を含めることができ、2 つの VPC 間にピア接続を作成して、ネットワークトラフィックが VPC 間をルーティングできるようにすることができます。

CIS では、VPC への変更に対するメトリクスフィルターとアラームを作成します。これらの変更をモニタリングすることで、認証と承認の管理が損なわれないようにすることができます。

このチェックを実行するために、Security Hub はカスタムロジックを使用して、のコントロール 3.14 に規定された正確な監査手順を実行します。CISAWS基礎ベンチマーク v1.2。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

注記

Security Hub がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡が検索されます。これらの証跡は、別のアカウントに属する組織の証跡である可能性があります。マルチリージョンの証跡は、別のリージョンに基づいている場合もあります。

チェックの結果FAILED以下の場合における所見:

  • トレイルは設定されていません。

  • 現在のリージョンにあり、現在のアカウントが所有している利用可能な証跡は、管理要件を満たしていません。

チェックの結果、制御ステータスはNO_DATA以下の場合は、

  • マルチリージョンの証跡は、別のリージョンに基づいています。Security Hub は、証跡のベースとなるリージョンでのみ結果を生成できます。

  • マルチリージョンの証跡は、別のアカウントに属しています。Security Hub は、証跡を所有するアカウントの調査結果のみを生成できます。

アラームの場合、現在のアカウントが参照されている Amazon SNS トピックを所有しているか、listSubscriptionAmazon SNS トピックへのアクセス。それ以外の場合は、Security HubWARNINGコントロールの所見。

Remediation

この問題を修正するためのステップには、Amazon SNS トピック、CloudTrail 証跡、メトリクスフィルター、およびメトリクスフィルターのアラームの設定が含まれます。

Amazon SNS トピックを作成する

  1. Amazon SNS コンソール(https://console.aws.amazon.com/sns/v3/home)を開きます。

  2. すべての CIS アラームを受信する Amazon SNS トピックを作成します。

    トピックに少なくとも 1 人の受信者を作成します。詳細については、「」を参照してください。Amazon SNS の開始方法Amazon Simple Notification Service デベロッパーガイド

次に、すべてのリージョンに適用されるアクティブなCloudTrail をセットアップします。これを行うには、2.1 — CloudTrail がすべてのリージョンで有効になっていることを確認します の修正手順に従います。

CloudTrail 証跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。そのロググループのメトリックスフィルタを作成します。

最後に、メトリクスフィルターとアラームを作成します。

メトリクスフィルターとアラームを作成するには

  1. CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。

  2. ナビゲーションペインで、[Log groups] (ロググループ) を選択します。

  3. 作成した CloudTrail 証跡に関連付けられている CloudWatch Logs ロググループのチェックボックスをオンにします。

  4. 送信元アクションで、メトリックフィルタの作成

  5. []パターンを定義する] で、次の作業を行います。

    1. 次のパターンをコピーして、[Filter Pattern (フィルターパターン)] フィールドに貼り付けます。

      {($.eventName=CreateVpc) || ($.eventName=DeleteVpc) || ($.eventName=ModifyVpcAttribute) || ($.eventName=AcceptVpcPeeringConnection) || ($.eventName=CreateVpcPeeringConnection) || ($.eventName=DeleteVpcPeeringConnection) || ($.eventName=RejectVpcPeeringConnection) || ($.eventName=AttachClassicLinkVpc) || ($.eventName=DetachClassicLinkVpc) || ($.eventName=DisableVpcClassicLink) || ($.eventName=EnableVpcClassicLink)}
    2. [次へ] を選択します。

  6. []メトリクスの割り当て] で、次の作業を行います。

    1. Eclipseフィルタ名で、メトリクスフィルタの名前を入力します。

    2. を使用する場合メトリクス名前空間「」と入力します。LogMetrics

      すべての CIS ログメトリックフィルタに同じ名前空間を使用する場合、すべての CIS Benchmark メトリックがグループ化されます。

    3. を使用する場合メトリクス名に、メトリックスの名前を入力します。メトリクスの名前を覚えておいてください。アラームの作成時にメトリクスを選択する必要があります。

    4. [メトリクス値] に「1」と入力します。

    5. [次へ] を選択します。

  7. []確認と作成で、新しいメトリックフィルタに入力した情報を確認します。次に [] を選択します。メトリクスフィルターの作成

  8. [メトリクスフィルタータブを選択し、作成したメトリクスフィルターを選択します。

    メトリクスフィルタを選択するには、右上のチェックボックスを選択します。

  9. [Create Alarm] を選択します。

  10. []メトリックと条件の指定] で、次の作業を行います。

    1. []メトリクス、に対してStatisticで、平均。使用できる統計の詳細については、「」を参照してください。統計Amazon CloudWatch ユーザーガイド

    2. []条件、に対してThresholdで、静的

    3. を使用する場合アラーム条件を定義します。で、以上

    4. を使用する場合しきい値を定義します。「」と入力します。1

    5. [次へ] を選択します。

  11. []アクションの設定] で、次の作業を行います。

    1. []アラーム状態トリガーで、のアラーム

    2. [SNS トピックの選択] で、[既存の SNS トピックの選択] を選択します。

    3. を使用する場合通知の送信先で、前の手順で作成した SNS トピックの名前を入力します。

    4. [次へ] を選択します。

  12. [][Name (名前)] とに、a と入力します。名前および説明アラームのために。例えば、CIS-3.14-VPCChanges と指定します。続いて、[次へ] を選択します。

  13. []プレビューと作成で、アラーム設定を確認します。次に [アラームの作成] を選択します。

4.1 — どのセキュリティグループでも 0.0.0.0/0 からポート 22 への入力を許可しないようにします

緊急度:

AWS Config ルール: restricted-ssh

セキュリティグループは、AWS リソースへの入力および出力ネットワークトラフィックのステートフルフィルタリングを提供します。

セキュリティグループはポート 22 への無制限の入力を許可しません。SSH などのリモートコンソールサービスへの自由な接続性を排除することで、サーバーがリスクにさらされることを軽減できます。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アフリカ (ケープタウン)

  • アジアパシフィック (大阪)

  • ヨーロッパ (ミラノ)

Remediation

VPC に関連付けられている各セキュリティグループに対して次のステップを実行します。

  1. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。

  2. 左側のペインで、[セキュリティグループ] を選択します。

  3. セキュリティグループを選択します。

  4. ページ下部のセクションで、[インバウンドルール] タブを選択します。

  5. [ルールの編集] を選択します。

  6. ポート 22 を介したアクセスを許可するルールを特定し、[X] 選択してそれを削除します。

  7. [Save Rules (ルールの保存)] を選択します。

4.2 — どのセキュリティグループでも 0.0.0.0/0 からポート 3389 への入力を許可しないようにします

緊急度:

AWS Config ルール: restricted-common-ports

関連するの名前AWS Configマネージドルールが restricted-common-ports。ただし、作成されるルールには、この名前が使用されます。restricted-rdp

セキュリティグループは、AWS リソースへの入力および出力ネットワークトラフィックのステートフルフィルタリングを提供します。

セキュリティグループはポート 3389 への無制限の入力を許可しません。RDP などのリモートコンソールサービスへの自由な接続性を排除することで、サーバーがリスクにさらされることを軽減できます。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アフリカ (ケープタウン)

  • アジアパシフィック (大阪)

  • ヨーロッパ (ミラノ)

Remediation

VPC に関連付けられている各セキュリティグループに対して次のステップを実行します。

  1. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。

  2. 左側のペインで、[セキュリティグループ] を選択します。

  3. セキュリティグループを選択します。

  4. ページ下部のセクションで、[インバウンドルール] タブを選択します。

  5. [ルールの編集] を選択します。

  6. ポート 3389 を介したアクセスを許可するルールを特定し、[X] 選択してそれを削除します。

  7. [Save Rules (ルールの保存)] を選択します。

4.3 — すべての VPC のデフォルトセキュリティグループがすべてのトラフィックを制限するようにします

緊急度:

AWS Config ルール: vpc-default-security-group-closed

VPC に用意されているデフォルトのセキュリティグループの初期設定では、すべてのインバウンドトラフィックが拒否され、すべてのアウトバウンドトラフィックと、セキュリティグループに割り当てられているインスタンス間のすべてのトラフィックが許可されます。インスタンスを起動するときにセキュリティグループを指定しないと、そのインスタンスはデフォルトのセキュリティグループに自動的に割り当てられます。セキュリティグループは、AWS リソースへの入力および出力ネットワークトラフィックのステートフルフィルタリングを提供します。

CIS では、デフォルトのセキュリティグループはすべてのトラフィックを制限します。

準拠するように、各リージョンのデフォルトの VPC のデフォルトのセキュリティグループを更新します。すべての新しい VPC には、この推奨事項に準拠するために修正が必要なデフォルトセキュリティグループが自動的に含まれます。

注記

このレコメンデーションを実装する際には、以下で有効な VPC フローロギングを使用できます。2.9 — すべての VPC で VPC フローログ記録が有効になっていることを確認します の順にクリックして、システムが正常に動作するために必要な最小権限のポートアクセスを特定します。VPC フローロギングは、現在のセキュリティグループで発生したすべてのパケットの受け入れと拒否をログに記録できます。

すべてのトラフィックを制限するようにすべての VPC デフォルトセキュリティグループを設定すると、最小権限のセキュリティグループの開発と、の慎重な配置が促進されます。AWSリソースをセキュリティグループにまとめます。これにより、これらのリソースの露出が減少します。

Remediation

すべてのアクセスを制限するために、デフォルトのセキュリティグループを更新するには

  1. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。

  2. デフォルトセキュリティグループの詳細を表示して、それらに割り当てられているリソースを表示します。

  3. リソースに対して最小権限のセキュリティグループのセットを作成します。

  4. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

  5. Amazon EC2 コンソールで、デフォルトのセキュリティグループを使用しているリソースのセキュリティグループを、作成した最小権限のセキュリティグループに変更します。

  6. デフォルトのセキュリティグループごとに、[インバウンド] タブを選択し、すべてのインバウンドルールを削除します。

  7. デフォルトのセキュリティグループごとに、[アウトバウンド] タブを選択し、すべてのアウトバウンドルールを削除します。

詳細については、「」を参照してください。セキュリティグループを操作するAmazon VPC User Guide