CIS AWS Foundations Benchmark v1.3.0の日本語訳

CIS AWS Foundations Benchmark v1.3.0の日本語訳

仕事で見る機会があり、日本語訳が欲しくて探したが見つからなかったので自分用にメモとして残しておく。

機械翻訳のため間違いが多々あると思うがご愛敬。

www.DeepL.com/Translator(無料版)で翻訳し、必要に応じて修正。

CISのサイト

Advertisement

目次

1 Identity and Access Management

1 アイデンティティ&アクセスマネジメント

このセクションでは、IDおよびアクセス管理関連のオプションを構成するための推奨事項を説明します。
関連のオプションを設定するための推奨事項が記載されています。

1.1 Maintain current contact details (Manual)

1.1 現在の連絡先を維持する。

【説明】
AWSアカウントの電子メールおよび電話の連絡先が最新であり、組織内の複数の個人に対応していることを確認してください。
AWSアカウントは複数の連絡先情報をサポートしており、AWSはこれらを使用して以下の連絡を行います。
AWSは、利用規定に違反している、またはセキュリティ侵害の可能性を示す活動が観察された場合、これらを使用してアカウント所有者に連絡します。
AWSは、AWS Abuseチームによって、利用規定違反またはセキュリティ侵害の可能性を示す活動が観察された場合、アカウント所有者に連絡するためにこれらを使用します。連絡先の詳細は以下の通りです。
その個人が利用できない状況が発生する可能性があるため、連絡先詳細は単一の個人のためのものであってはなりません。
利用できません。電子メールの連絡先は、組織内の複数の個人に電子メールを転送するメールエイリアスを示すべきです。
電話の連絡先は、可能であれば、PABXハントグループを指定してください。
電話の連絡先は、可能であればPABXのハントグループまたはその他のコールフォワーディングシステムを指すようにする。

【根拠】
AWSアカウントが禁止された、または疑わしい行動をとっていることが確認された場合に
AWSは記載されている連絡先を使用して、電子メールおよび電話でアカウント所有者に連絡することを試みます。
これがうまくいかず、アカウントの挙動を早急に緩和する必要がある場合は、積極的な措置が取られることがあります。
疑わしい挙動を示しているアカウントとAWS APIエンドポイントおよびインターネット間のトラフィックのスロットルを含む、積極的な措置が取られる場合があります。これにより、以下が発生します。
問題のあるアカウントとの間のサービスに障害が発生するため、お客様とAWSの双方にとって
速やかに連絡が取れるようにすることが、お客様にとってもAWSにとっても最大の利益となります。これは、次のように設定することで実現できます。
AWSアカウントの連絡先は、複数の個人を受信者とするリソースを指すように設定するのが最適です。
AWSアカウントの連絡先を、電子メールのエイリアスやPABXのハントグループなど、複数の個人を受信者とするリソースに設定するのが最適です。

1.2 Ensure security contact information is registered (Manual)

1.2 セキュリティ連絡先を確実に登録する。

【説明】
AWSでは、お客様がアカウントのセキュリティチームの連絡先を指定できるオプションを提供しています。
アカウントのセキュリティチームの連絡先を指定することができます。この情報を提供することをお勧めします。

【根拠】
セキュリティに特化した連絡先を指定することで、AWSから送られてきたセキュリティ勧告を、対応するのに最も適した組織内のチームに確実に届けることができます。

1.3 Ensure security questions are registered in the AWS account (Manual)

1.3 AWSアカウントにセキュリティ質問が登録されていることを確認する。

【説明】
AWSサポートポータルでは、アカウント所有者がセキュリティ質問を設定することができます。
アカウント所有者は、AWS カスタマーサポートに電話で問い合わせる個人を認証するために使用できるセキュリティ質問を設定できます。
セキュリティ質問を設定することをお勧めします。

【根拠】
新しいAWSアカウントを作成すると、デフォルトのスーパーユーザーが自動的に作成されます。
このアカウントは「root user」アカウントと呼ばれています。
このアカウントの使用は制限され、高度に制御されることが推奨されます。
ルートのパスワードにアクセスできなくなった場合や、ルートに関連付けられたMFAトークンが紛失/破壊された場合、秘密の質問とそれに関連する回答を使った認証により、ルートユーザーのログインアクセスを回復することができます。

1.4 Ensure no root user account access key exists (Automated)

1.4 ルートユーザーアカウントのアクセスキーが存在しないことを確認する。

【説明】
rootユーザーアカウントは、AWSアカウントの中で最も権限のあるユーザーです。
AWSアクセスキーは、特定のAWSアカウントへのプログラムによるアクセスを提供します。
ルートユーザーアカウントに関連するすべてのアクセスキーを削除することをお勧めします。

【根拠】
ルートユーザーアカウントに関連するアクセスキーを削除すると、そのアカウントが侵害されるベクターが制限されます。
アカウントが侵害される可能性があります。さらに、ルートのアクセスキーを削除することで、特権の少ないロールベースのアカウントの作成と使用が促進されます。

1.5 Ensure MFA is enabled for the “root user” account (Automated)

1.5 「root user」アカウントでMFAが有効になっていることを確認する。

【説明】
rootユーザーアカウントは、AWSアカウントの中で最も権限のあるユーザーです。
マルチファクタ MFA(Multi-factor Authentication)は、ユーザー名とパスワードに加えて、さらに保護の層を追加します。パスワードの上にさらに保護層を追加します。
MFAを有効にすると、ユーザーがAWSのウェブサイトにサインインする際に ユーザー名とパスワード、およびAWS MFAデバイスからの認証コードの入力が求められます。
AWS MFAデバイスからの認証コードの入力が求められます。

注:仮想MFAをルートアカウントに使用する場合、使用するデバイスは個人のデバイスではなく、AWS MFAデバイスを使用することをお勧めします。
個人のデバイスではなく、専用のモバイルデバイス(タブレットや電話)を使用することを推奨します。
個人所有のデバイスとは別に、充電とセキュリティの確保が管理された専用のモバイルデバイス(タブレットや携帯電話)を使用することを推奨します。
これにより、以下の理由でMFAへのアクセスができなくなるリスクを軽減できます。これにより、デバイスの紛失、デバイスの下取り、デバイスを所有していた個人が会社に在籍しなくなった場合などに リスクを軽減することができます。

【根拠】
MFAを有効にすることで、コンソールへのアクセスのセキュリティが向上します。
これは、認証を行うプリンシパルがタイムセンシティブなキーを発するデバイスを所有し、クレデンシャルを知っている必要があるためです。

1.6 Ensure hardware MFA is enabled for the “root user” account (Automated)

1.6 「root user」アカウントでハードウェアMFAが有効になっていること。

【説明】
rootユーザーアカウントは、AWSアカウントの中で最も権限のあるユーザーです。
MFAは、ユーザー名とパスワードの上にさらに保護層を追加します。MFAを有効にすると、ユーザーがAWSのWebサイトにサインインする際に、ユーザー名とパスワード、およびAWS MFAデバイスからの認証コードの入力が求められます。
また、AWS MFAデバイスからの認証コードの入力も求められます。レベル2では、ルートユーザーアカウントをハードウェアMFAで保護することが推奨されます。

1.7 Eliminate use of the root user for administrative and daily tasks (Automated)

1.7 管理業務や日常業務でのrootユーザーの使用をなくす。

【説明】
AWSアカウントを作成すると、無効化や削除ができないルートユーザーが作成されます。
このユーザーは、AWSアカウント内のすべてのリソースに無制限にアクセスし、制御することができます。
このアカウントの使用は、日常業務では避けることを強くお勧めします。
【根拠】
ルートユーザーは、すべてのアカウントリソースへの無制限のアクセスと制御が可能です。
これを使用することは、最小特権と職務分離の原則に反し、エラーやアカウントの侵害による不必要な損害を招く可能性があります。

1.8 Ensure IAM password policy requires minimum length of 14 or greater (Automated)

1.8 IAMのpasswrdポリシーで最低14以上の長さを要求していること。

【説明】
パスワードポリシーは、一部、パスワードの複雑さの要件を強制するために使用されています。
IAMのパスワードポリシーは、パスワードが少なくとも所定の長さであることを保証するために使用することができます。
パスワードポリシーでは、最小のパスワード長14を要求することが推奨されます。

【根拠】
パスワードの複雑性に関するポリシーを設定することで、ブルートフォースによるログイン試行に対するアカウントの回復力を高めることができます。

1.9 Ensure IAM password policy prevents password reuse (Automated)

1.9 IAMパスワードポリシーがパスワードの再利用を確実に防止する。

【説明】
IAMのパスワードポリシーでは、同じユーザーによる所定のパスワードの再利用を防ぐことができます。
パスワードポリシーでは、パスワードの再利用を防ぐことをお勧めします。

【根拠】
パスワードの再利用を防ぐことで、ブルートフォースによるログイン試行に対するアカウントの回復力を高めることができます。

1.10 Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password (Automated)

1.10 コンソールパスワードを持つすべてのIAMユーザーに対して多要素認証(MFA)が有効であることを確認する。

【説明】
多要素認証(MFA)は、従来の認証情報に加えて、さらに認証保証のレイヤーを追加します。
MFAを有効にすると、ユーザーがAWSコンソールにサインインする際に、ユーザー名とパスワードに加えて、物理的または仮想のMFAトークンからの認証コードの入力が求められます。
コンソールのパスワードを持つすべてのアカウントでMFAを有効にすることをお勧めします。

【根拠】
MFAを有効にすると、コンソールへのアクセスのセキュリティが強化されます。
これは、認証を行うプリンシパルがタイムセンシティブなキーを表示するデバイスを所有し、クレデンシャルを知っている必要があるためです。

1.11 Do not setup access keys during initial user setup for all IAM users that have a console password (Manual)

1.11 コンソールパスワードを持つすべてのIAMユーザーの初期ユーザー設定時に、アクセスキーを設定しない。

【説明】
AWSコンソールのデフォルトでは、新しいIAMユーザーの作成時にチェックボックスが選択されていません。
IAMユーザーのクレデンシャルを認証する際には、どのようなタイプのアクセスが必要かを判断する必要があります。
プログラム的なアクセス。IAMユーザーは、APIコールを行ったり、AWS CLIを使用したり、Windows PowerShell用のツールを使用する必要があるかもしれません。その場合には
は、そのユーザーのためにアクセスキー(アクセスキーIDと秘密のアクセスキー)を作成します。
AWSマネジメントコンソールへのアクセス。そのユーザーがAWSマネジメントコンソールにアクセスする必要がある場合は、そのユーザーのパスワードを作成します。

【根拠】
プロファイル作成後にプログラムアクセスのための追加手順をユーザーに要求することで、アクセスキーが[a]業務に必要であること、[b]アクセスキーがアカウントに設定されると、そのキーが組織内のどこかで使用される可能性があることを、より強く意思表示することができます。
注:ユーザーがアクセスキーを必要とすることがわかっている場合でも、ユーザー自身がキーを作成することを要求するか、ユーザー作成とは別のステップでキーを作成するようにサポートチケットを提出してください。
または、ユーザー作成とは別の手順でアクセスキーを作成するようサポートチケットを提出してください。の作成とは別の手順で作成するようにサポートチケットを提出してください。

1.12 Ensure credentials unused for 90 days or greater are disabled (Automated)

1.12 90日以上使用されていない認証情報を確実に無効化する。

【説明】
AWS IAMユーザーは、パスワードやアクセスキーなど、さまざまな種類のクレデンシャルを使用してAWSリソースにアクセスできます。
90日以上使用されていないクレデンシャルは、すべて無効化または削除することを推奨します。

【根拠】
不要な認証情報を無効にしたり削除したりすることで、侵害されたアカウントや放棄されたアカウントに関連する認証情報が使用される機会を減らすことができます。

1.13 Ensure there is only one active access key available for any single IAM user (Automated)

1.13 1人のIAMユーザーが利用できるアクティブなアクセスキーは1つだけであることを保証する。

【説明】
アクセスキーは、IAMユーザーまたはAWSアカウントのルートユーザーの長期的な認証情報です。
アクセスキーを使用して、AWS CLIまたはAWS API(直接またはAWS SDKを使用)へのプログラム要求に署名することができます。

【根拠】
アクセスキーは、IAMユーザーまたはAWSアカウントのルートユーザーの長期的な認証情報です。
アクセスキーを使って、AWS CLIやAWS APIへのプログラム的なリクエストに署名することができます。
アカウントを保護する最良の方法の1つは、ユーザーに複数のアクセスキーを持たせないことです。

1.14 Ensure access keys are rotated every 90 days or less (Automated)

1.14 アクセスキーが90日以内に確実にローテーションされる。

【説明】
アクセスキーは、アクセスキーIDとシークレットアクセスキーで構成されており、ユーザーがAWSに対して行うプログラム要求に署名するために使用されます。
AWSユーザーは、AWSコマンドラインインターフェイス(AWS CLI)からAWSにプログラム的な呼び出しを行うために、自分のアクセスキーが必要です。
Windows PowerShell、AWS SDK、または個々のAWSサービスのAPIを使用した直接のHTTPコールから、AWSへのプログラムコールを行うために自分のアクセスキーが必要です。すべてのアクセスキーを定期的にローテーションすることをお勧めします。

【根拠】
アクセスキーをローテーションすることで、漏洩したアカウントや解約されたアカウントに関連付けられたアクセスキーが使用される機会を減らすことができます。
アクセスキーは、紛失、クラック、盗難などの可能性がある古いキーでデータにアクセスできないように、ローテーションする必要があります。

1.15 Ensure IAM Users Receive Permissions Only Through Groups(Automated)

1.15 IAMユーザーがグループを通じてのみ許可を受けられるようにする。

【説明】
IAMユーザーは、IAMポリシーによって、サービス、機能、データへのアクセスを許可されます。ユーザーのポリシーを定義するには3つの方法があります。
1) ユーザーポリシーを直接編集する、つまりインラインポリシー(ユーザーポリシー)。
2) ポリシーをユーザーに直接アタッチする。
3) ポリシーが添付されているIAMグループにユーザーを追加する。
3番目の実装のみが推奨されます。

【根拠】
グループを通じてのみIAMポリシーを割り当てることで、パーミッション管理を組織の機能的役割と一致する単一の柔軟なレイヤーに統一します。
権限管理を一元化することで、過剰な権限が発生する可能性が低くなります。

1.16 Ensure IAM policies that allow full “*:*” administrative privileges are not attached (Automated)

1.16 「*:*」の管理者権限を完全に許可するIAMポリシーが添付されていないことを確認する。

【設定】
IAMポリシーは、ユーザー、グループ、またはロールに権限を付与するための手段です。
タスクを実行するのに必要な権限のみを付与する「最小権限」を付与することが推奨され、標準的なセキュリティアドバイスとされています。
ユーザーが何をする必要があるかを判断し、完全な管理者権限を与えるのではなく、ユーザーがそれらのタスクのみを実行できるように、ユーザーのためのポリシーを作成します。

【根拠】
最小限の権限でスタートし、必要に応じて追加の権限を付与する方が、甘すぎる権限でスタートして後から厳しくするよりも安全です。
ユーザーが必要とする最小限の権限に制限する代わりに、完全な管理者権限を与えると、リソースが潜在的に望ましくない行動にさらされることになります。

1.17 Ensure a support role has been created to manage incidents with AWS Support (Automated)

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

【説明】
AWSは、インシデントの通知や対応、技術サポートやカスタマーサービスに利用できるサポートセンターを提供しています。
許可されたユーザーがAWSサポートでインシデントを管理できるように、IAM Roleを作成します。

【根拠】
アクセス制御に最小特権を実装することで、IAMロールは、AWSサポートでインシデントを管理するために、サポートセンターへのアクセスを許可する適切なIAMポリシーを必要とします。

1.18 Ensure IAM instance roles are used for AWS resource access from instances (Manual)

1.18 インスタンスからのAWSリソースへのアクセスにIAMインスタンスロールが使用されていること。

【説明】
AWSインスタンス内からのAWSアクセスは、AWSキーをAWS APIコールにエンコードするか、必要なアクセスに対して適切なパーミッションポリシーを持つロールにインスタンスを割り当てることで行うことができます。
“AWSアクセス “とは、AWSリソースにアクセスするため、またはAWSアカウントリソースを管理するために、AWSのAPIにアクセスすることを意味します。

【根拠】
AWS IAMロールは、AWS自体の外で使用可能なクレデンシャルの共有やローテーションに伴うリスクを低減します。クレデンシャルが侵害された場合、アクセス権を与えたAWSアカウント以外から使用することができます。対照的に、ロールパーミッションを利用するためには、攻撃者は特定のインスタンスへのアクセスを獲得し、維持する必要があります。
そのインスタンスに関連する権限を使用するためには、攻撃者は特定のインスタンスへのアクセスを獲得し、維持する必要があります。

さらに、認証情報がコンパイルされたアプリケーションやその他の変更困難なメカニズムにエンコードされている場合、サービス停止のリスクがあるため、適切なローテーションが行われる可能性はさらに低くなります。時間が経つにつれて、ローテーションされないクレデンシャルは、クレデンシャルを所有する組織ではもはや働いていない、より多くの個人によって知られる可能性が高くなります。

1.19 Ensure that all the expired SSL/TLS certificates stored in AWS IAM are removed (Automated)

1.19 AWS IAMに保存されている期限切れのSSL/TLS証明書がすべて削除されていることを確認する。

【説明】
AWSでウェブサイトやアプリケーションへのHTTPS接続を可能にするためには、SSL/TLS のサーバー証明書が必要です。サーバー証明書の保存とデプロイには、ACMまたはIAMを使用できます。
IAM 証明書マネージャとしてIAMを使用するのは、ACMでサポートされていない地域でHTTPS接続をサポートする必要がある場合のみです。ACMでサポートされていない地域でHTTPS接続をサポートする必要がある場合のみ、証明書マネージャーとしてIAMを使用します。IAMは、秘密鍵を安全に暗号化し、暗号化されたバージョンをIAM SSL証明書ストレージに保存します。バージョンをIAM SSL証明書ストレージに保存します。
IAMは、すべての地域でのサーバー証明書の展開をサポートしています。IAMはすべてのリージョンでのサーバー証明書の展開をサポートしていますが、AWSで使用するためには外部のプロバイダーから証明書を取得する必要があります。

ACMの証明書をIAMにアップロードすることはできません。また、IAMコンソールから証明書を管理することはできません。証明書をIAMコンソールから管理することはできません。

【根拠】
期限切れのSSL/TLS証明書を削除することで、無効な証明書が誤ってAWS Elastic Load Balancer(ELB)などのリソースに展開され、ELBの背後にあるアプリケーション/ウェブサイトの信頼性が損なわれるリスクを排除することができます。
ベストプラクティスとして、期限切れの証明書を削除することをお勧めします。

1.20 Ensure that S3 Buckets are configured with ‘Block public access (bucket settings)’ (Automated)

1.20 S3バケットに「Block public access (bucket settings)」が設定されていることを確認する。

【説明】
Amazon S3では、Amazon S3リソースへのパブリックアクセスを管理するために、Block public access(バケット設定)とBlock public access(アカウント設定)が用意されています。デフォルトでは、S3バケットとオブジェクトはパブリックアクセスを無効にして作成されます。しかし、十分なS3パーミッションを持つIAM原則は、バケットおよび/またはオブジェクトレベルでパブリックアクセスを有効にすることができます。
パブリックアクセスをブロック(バケット設定)」を有効にすると、個々のバケットとその中に含まれるオブジェクトがパブリックアクセスされるのを防ぐことができます。同様に、「パブリックアクセスをブロック(アカウント設定)」は、アカウント全体で、すべてのバケットとそれに含まれるオブジェクトがパブリックにアクセス可能になることを防ぎます。

【根拠】
Amazon S3 Block public access (bucket settings) は、それぞれのバケットに含まれるデータの偶発的または悪意のある公開を防止します。
Amazon S3 Block public access (account settings) は、それぞれのAWSアカウントのすべてのバケット内に含まれるデータの偶発的または悪意のある公開を防止します。
すべてのバケットまたは一部のバケットへのパブリックアクセスをブロックするかどうかは、データの感度、最小特権、およびユースケースに基づいて組織的に決定する必要があります。

1.21 Ensure that IAM Access analyzer is enabled (Automated)

1.21 IAMアクセスアナライザーが有効になっていることを確認する。

【説明】
すべてのリソースに関するIAMポリシーについて、IAM Access Analyzerを有効にします。
IAM Access Analyzerは、AWS reinvent 2019で紹介された技術です。IAMでアナライザを有効にすると、アクセス可能なリソースを示すスキャン結果がコンソールに表示されます。
スキャンでは、KMSキーやIAMロールなど、他のアカウントや連携ユーザーがアクセスできるリソースが表示される。
そのため、この結果から意図しないユーザーが許可されているかどうかを判断することができ、管理者は最小権限のアクセスを簡単に監視することができます。

【根拠】
AWS IAM Access Analyzerは、外部のエンティティと共有されている組織内のリソースや アカウント(Amazon S3バケットやIAMロールなど)を外部のエンティティと共有することができます。
これにより、リソースやデータへの意図しないアクセスを特定することができます。アクセスアナライザ ロジックベースの推論を用いて、外部のプリンシパルと共有されているリソースを特定します。お客様のAWS環境のリソースベースのポリシーを分析します。
IAMアクセスアナライザ S3バケット、IAMロール、KMS(Key Management Service)キー、AWS Lambda関数、S3バケットのすべてのポリシーを継続的に監視します。キー、AWS Lambda関数、Amazon SQS(Simple Queue Service)キューのすべてのポリシーを継続的に監視します。

1.22 Ensure IAM users are managed centrally via identity federation or AWS Organizations for multi-account environments (Manual)

1.22 マルチアカウント環境のために、IDフェデレーションまたはAWS Organizationsを介してIAMユーザーを確実に一元管理する。

【説明】
マルチアカウント環境では、IAMユーザーの集中管理により、ユーザーのコントロールが容易になります。
最初のアカウント以外のユーザーアクセスは、役割の仮定によって提供されます。ユーザーの一元化は、外部のIDプロバイダーとのフェデレーションや、AWS Organizationsの利用によって実現できます。

【根拠】
IAMのユーザー管理を単一のIDストアに集中させることで、複雑さが軽減され、その結果、アクセス管理のエラーが発生しやすくなります。

2 Storage

2 ストレージ

2.1 Simple Storage Service (S3)

2.1 S3(Simple Storage Service)について。

2.1.1 Ensure all S3 buckets employ encryption-at-rest (Manual)

2.1.1 すべてのS3バケットにEncryption-at-restを採用する。

【説明】
Amazon S3では、保管中のデータを保護するために、無料または低コストのさまざまな暗号化オプションを提供しています。

【根拠】
休止状態のデータを暗号化することで、意図せずにデータが漏洩する可能性を低減し、暗号化が解除されない場合には漏洩の影響を無効にすることができます。

2.1.2 Ensure S3 Bucket Policy allows HTTPS requests (Manual)

2.1.2 S3バケットポリシーがHTTPSリクエストを許可していることを確認する。

【説明】
Amazon S3のバケットレベルでは、バケットポリシーにより、HTTPSでのみオブジェクトにアクセスできるようなパーミッションを設定することができます。

【根拠】
デフォルトでは、Amazon S3はHTTPとHTTPSの両方のリクエストを許可します。
HTTPSによるAmazon S3オブジェクトへのアクセスのみを許可するためには、HTTPリクエストへのアクセスを明示的に拒否する必要があります。
HTTPリクエストを明示的に拒否せずにHTTPSリクエストを許可するバケットポリシーは、この推奨事項に準拠しません。

2.2 Elastic Compute Cloud (EC2)

2.2 Elastic Compute Cloud (EC2)について。

2.2.1 Ensure EBS volume encryption is enabled (Manual)

2.2.1 EBSボリュームの暗号化が有効であること。

【説明】
Elastic Compute Cloud(EC2)では、EBS(Elastic Block Store)サービスを使用する際に、静止時の暗号化がサポートされています。
デフォルトでは無効ですが、EBSボリュームの作成時に暗号化を強制することができます。

【根拠】
休止状態のデータを暗号化することで、意図せずにデータが漏洩する可能性を低減し、暗号化が解除されない場合には漏洩の影響を無効にすることができます。

3 Logging

このセクションでは、AWSのアカウントロギング機能を設定するための推奨事項を説明します。

3.1 Ensure CloudTrail is enabled in all regions (Automated)

3.1 すべての地域でCloudTrailが有効であることを確認する。

【説明】
AWS CloudTrailは、お客様のアカウントに対するAWS APIコールを記録し、ログファイルを配信するウェブサービスです。ログファイルを配信します。
記録される情報には、API呼び出し元のID、API呼び出しの時間、API呼び出し元のソースIPアドレス、リクエストパラメーター、およびお客様のリクエストが含まれます。記録される情報には、API呼び出し元のID、API呼び出しの時刻、API呼び出し元のソースIPアドレス、リクエストパラメータ、およびAWSサービスが返したレスポンスエレメントが含まれます。AWSサービスから返されたレスポンスエレメントが含まれます。
CloudTrailは、アカウントのAWS APIコールの履歴を提供します。呼び出しの履歴を提供します。これには、マネジメントコンソール、SDK、コマンド ラインツール、および上位のAWSサービス(CloudFormationなど)を介して行われたAPIコールを含む、アカウントのAWS APIコールの履歴を提供します。

【根拠】
CloudTrailが生成するAWS APIコール履歴は、セキュリティ分析、リソース変更の追跡、コンプライアンス監査を可能にします。

マルチ・リージョン・トレイルが存在することで、使用されていないリージョンで発生した予期せぬアクティビティを確実に検出することができます。
マルチリージョンの証跡では、AWSグローバルサービス上で発生したイベントの記録を取得するために、証跡に対してグローバルサービスロギングがデフォルトで有効になっていることを確認します。
マルチリージョントレイルでは、管理イベントがすべてのタイプのRead/Writesに設定されていることで、AWSアカウント内のすべてのリソースで実行される管理操作の記録が保証されます。

3.2 Ensure CloudTrail log file validation is enabled (Automated)

3.2 CloudTrailのログファイル検証が有効になっていることを確認する。

【説明】
CloudTrailのログファイル検証では、CloudTrailがS3に書き込んだ各ログのハッシュを含むデジタル署名付きのダイジェストファイルを作成します。
これらのダイジェストファイルは、CloudTrailがログを配信した後にログファイルが変更されたか、削除されたか、または変更されていないかを判断するために使用することができます。
すべてのCloudTrailでファイル検証を有効にすることを推奨します。

【根拠】
ログファイルの検証を有効にすると、CloudTrailログの整合性チェックが追加されます。

3.3 Ensure the S3 bucket used to store CloudTrail logs is not publicly accessible (Automated)

3.3 CloudTrailのログを保存するためのS3バケットが一般にアクセスできないようにする。

【説明】
CloudTrailは、お客様のAWSアカウントで行われたすべてのAPIコールの記録をログに記録します。これらのログファイルはS3バケットに保存されます。
CloudTrailがログを記録するS3バケットには、CloudTrailのログへの一般ユーザーのアクセスを防ぐために、バケットポリシーまたはアクセスコントロールリスト(ACL)を適用することが推奨されます。

【根拠】
CloudTrailのログコンテンツの公開を許可すると、敵対者が影響を受けたアカウントの使用や設定の弱点を特定するのに役立つ可能性があります。

3.4 Ensure CloudTrail trails are integrated with CloudWatch Logs (Automated)

3.4 CloudTrailの証跡がCloudWatch Logsと統合されるようにする。

【説明】
AWS CloudTrailは、指定されたAWSアカウントで行われたAWS APIコールを記録するウェブサービスです。
記録される情報には、API呼び出し元のID、API呼び出しの時間、API呼び出し元のソースIPアドレス、リクエストパラメーター、レスポンスエレメントが含まれます。記録される情報には、API呼び出し元のID、API呼び出しの時刻、API呼び出し元のソースIPアドレス、リクエストパラメータ、AWSサービスから返されたレスポンスエレメントが含まれます。
AWSサービスから返されたレスポンスエレメントが含まれます。CloudTrailは、ログファイルの保存と配信にAmazon S3を使用しています。
そのため、ログファイルは永続的に保存されます。CloudTrailのログは、指定したS3 バケットに保存するだけでなく、CloudTrailがCloudWatch Logにログを送信するように設定することで、リアルタイムでの分析が可能です。がCloudWatch Logsにログを送信するように設定します。アカウント内のすべてのリージョンで有効になっているトレイルの場合。CloudTrailはそれらすべてのリージョンからのログファイルをCloudWatch Logsのロググループに送信します。これは CloudTrailのログをCloudWatch Logsに送信することを推奨します。

注:この推奨の意図は、AWSアカウントのアクティビティが確実に捕捉され、監視され、適切にアラームされるようにすることです。
捉え、監視し、適切にアラームをかけることを保証するためです。CloudWatch Logsは、AWSサービスを使用してこれを達成するためのネイティブな方法です。
AWSサービスを使用してこれを達成するためのネイティブな方法ですが、他のソリューションの使用を排除するものではありません。

【根拠】
CloudTrailのログをCloudWatch Logsに送信することで、ユーザー、API、リソース、IPアドレスに基づくリアルタイムおよび履歴のアクティビティのロギングが容易になり、アカウントの異常なアクティビティや感度の高いアクティビティに対するアラームや通知を設定することができます。

3.5 Ensure AWS Config is enabled in all regions (Automated)

3.5 すべてのリージョンでAWS Configが有効であることを確認する。

【説明】
AWS Configは、お客様のアカウント内でサポートされているAWSリソースの設定管理を行い、お客様にログファイルを配信するWebサービスです。
記録される情報は、設定項目(AWSリソース)、設定項目(AWSリソース)間の関係、リソース間の設定変更などです。
AWS Configはすべてのリージョンで有効にすることを推奨します。

【根拠】
AWS Configによって取得されたAWS構成アイテムの履歴は、セキュリティ分析、リソース変更の追跡、コンプライアンス監査を可能にします。

3.6 Ensure S3 bucket access logging is enabled on the CloudTrail S3 bucket (Automated)

3.6 CloudTrailのS3バケットでS3バケットのアクセスログが有効になっていることを確認する。

【説明】
S3バケットアクセスロギングは、S3バケットに行われた各リクエストのアクセスレコードを含むログを生成します。
アクセスログの記録には、リクエストタイプ、リクエストで指定されたリソース、リクエストが処理された日時など、リクエストに関する詳細が含まれます。
CloudTrailのS3バケットでは、バケットアクセスログを有効にすることを推奨します。

【根拠】
対象となるS3バケットでS3バケットロギングを有効にすることで、任意の対象バケット内のオブジェクトに影響を与える可能性のあるすべてのイベントを捕捉することが可能になります。
また、ログを別のバケットに保存するように設定すると、セキュリティやインシデント対応のワークフローに役立つログ情報にアクセスできるようになります。

3.7 Ensure CloudTrail logs are encrypted at rest using KMS CMKs (Automated)

3.7 KMS CMKを使用してCloudTrailログが静止状態で確実に暗号化されること。

【説明】
AWS CloudTrailは、アカウントのAWS APIコールを記録し、そのログをIAMポリシーに従ってユーザーやリソースに公開するウェブサービスです。ログをIAMポリシーに基づいてユーザーやリソースに提供するウェブサービスです。
AWSキー AWS Key Management Service (KMS)は、アカウントデータの暗号化に使用する暗号鍵の作成と管理を支援するマネージドサービスです。AWS Key Management Service (KMS)は、アカウントのデータを暗号化するための暗号化キーの作成と管理、およびハードウェア・セキュリティ・モジュール HSM)を使用して暗号化キーのセキュリティを保護するマネージドサービスです。
CloudTrailのログは以下のように設定できます。SSE(Server Side Encryption)およびKMS(Customer Created Master Key)を利用して CloudTrailログをさらに保護します。
CloudTrailは、SSE-KMSを利用するように設定することを推奨します。

【根拠】
SSE-KMSを使用するようにCloudTrailを設定すると、指定されたユーザーが対応するログバケットに対するS3読み取りパーミッションを持っていなければならず、CMKポリシーによって復号化パーミッションが付与されていなければならないため、ログデータに対する追加の機密性制御が可能になります。

3.8 Ensure rotation for customer created CMKs is enabled (Automated)

3.8 顧客が作成したCMKのローテーションが有効であることを確認する。

【説明】
AWS Key Management Service(KMS)では、顧客が作成した顧客マスターキー(CMK)のキーIDに紐付けられたKMS内に保管されている鍵素材であるバッキングキーを回転させることができます。
これは、暗号化や復号化などの暗号化操作を行うために使用されるバッキングキーです。
現在、自動化されたキーローテーションでは、暗号化されたデータの復号が透過的に行われるように、以前のすべてのバッキングキーが保持されます。
CMKのキーローテーションを有効にすることをお勧めします。

【根拠】
暗号化キーをローテーションすることで、新しいキーで暗号化されたデータは、漏洩した可能性のある以前のキーではアクセスできないため、キーが漏洩した場合の潜在的な影響を軽減することができます。

3.9 Ensure VPC flow logging is enabled in all VPCs (Automated)

3.9 すべてのVPCでVPCフローロギングが有効になっていること。

【説明】
VPCフローログは、VPC内のネットワークインターフェースを行き来するIPトラフィックの情報を取得することができる機能です。
フローログを作成した後は、Amazon CloudWatch Logsでそのデータを閲覧・取得することができます。
VPCのフローログは、VPCのパケット「拒否」に対して有効にすることが推奨されています。

【根拠】
VPCフローログは、VPCを通過するネットワークトラフィックを可視化するもので、セキュリティワークフロー中の異常なトラフィックやインサイトの検出に利用できます。

3.10 Ensure that Object-level logging for write events is enabled for S3 bucket (Automated)

3.10 S3バケットで書き込みイベントのオブジェクトレベルロギングが有効になっていることを確認する。

【説明】
GetObject、DeleteObject、PutObjectなどのS3オブジェクトレベルのAPI操作はデータイベントと呼ばれます。
デフォルトではCloudTrailのトレイルはデータイベントのログを取らないため、S3バケットのオブジェクトレベルのロギングを有効にすることが推奨されます。

【根拠】
オブジェクトレベルのロギングを有効にすることで、組織内のデータコンプライアンス要件を満たしたり、包括的なセキュリティ分析を行ったり、AWSアカウント内のユーザー行動の特定のパターンを監視したり、Amazon CloudWatch Eventsを使用してS3バケット内のオブジェクトレベルのAPIアクティビティに即座に対処したりすることができます。

3.11 Ensure that Object-level logging for read events is enabled for S3 bucket (Automated)

3.11 S3バケットで読み取りイベントのオブジェクトレベルロギングが有効になっていることを確認する。

【説明】
GetObject、DeleteObject、PutObjectなどのS3オブジェクトレベルのAPI操作はデータイベントと呼ばれます。
デフォルトではCloudTrailのトレイルはデータイベントのログを取らないため、S3バケットのオブジェクトレベルのロギングを有効にすることが推奨されます。

【根拠】
オブジェクトレベルのロギングを有効にすることで、組織内のデータコンプライアンス要件を満たしたり、包括的なセキュリティ分析を行ったり、AWSアカウント内のユーザー行動の特定のパターンを監視したり、Amazon CloudWatch Eventsを使用してオブジェクトレベルのAPIアクティビティに対して直ちにアクションを起こしたりすることができます。

4 Monitoring

4 モニタリング

推奨されるメトリック・フィルターとアラームの有効性と適用範囲について。
セクション3の推奨事項は、マルチリージョンのCloudTrailに実装されるべきです。
すべてのリージョンでCloudTrailが有効であることを確認するで 更新された概要は次のようになります。
このセクションでは、アカウントアクティビティの監視と対応を支援するためのAWSの設定に関する推奨事項が記載されています。
アカウントの活動を監視し、対応するためのAWSの設定に関する推奨事項を記載しています。このセクションのメトリックフィルタ関連の推奨事項は
このセクションのメトリックフィルタ関連の推奨事項は、「すべてのリージョンで確実にCloudTrailを有効にする」および「確実に CloudTrail trails are integrated with CloudWatch Logs」の推奨事項に依存します。”Logging “セクションの推奨事項に依存します。
さらに、同じ推奨事項の改善手順のステップ3では 勧告では、電子メールベースのサブスクリプションを確立するためのガイダンス(プロトコルの電子メール)を提供しています。
これは例示であり、他のプロトコルの価値が低いことを示唆するものではありません。

4.1 Ensure a log metric filter and alarm exist for unauthorized API calls (Automated)

4.1 未承認のAPIコールに対するログメトリックフィルタとアラームの存在を確認する。

【説明】
APIコールのリアルタイム監視は、CloudTrail LogsをCloudWatch Logsに誘導し、対応するメトリックフィルタとアラームを設定することで実現できます。
許可されていないAPIコールについては、メトリックフィルターとアラームを設定することをお勧めします。

【根拠】
未承認のAPIコールを監視することで、アプリケーションのエラーが明らかになり、悪意のある行為を検出するまでの時間を短縮できる可能性があります。

4.2 Ensure a log metric filter and alarm exist for Management Console sign-in without MFA (Automated)

4.2 MFA を使用しないマネジメントコンソールのサインインに対するログメトリックフィルタとアラームの存在を確認する。

【説明】
APIコールのリアルタイム監視は、CloudTrail LogsをCloudWatch Logsに誘導し、対応するメトリックフィルタとアラームを設定することで実現できます。
多要素認証(MFA)で保護されていないコンソールログインに対してメトリックフィルタとアラームを設定することを推奨します。

【根拠】
シングルファクタのコンソールログインを監視することで、MFAで保護されていないアカウントの可視性を高めることができます。

4.3 Ensure a log metric filter and alarm exist for usage of “root” account (Automated)

4.3 “root “アカウントの使用に関するログメトリックフィルタとアラームの存在を確認する。

【説明】
APIコールのリアルタイム監視は、CloudTrail LogsをCloudWatch Logsに誘導し、対応するメトリックフィルタとアラームを設定することで実現できます。
ルート・ログイン試行に対してメトリック・フィルターとアラームを設定することを推奨します。

【根拠】
ルートアカウントのログインを監視することで、完全に特権的なアカウントの使用を可視化し、その使用を減らす機会を提供します。

4.4 Ensure a log metric filter and alarm exist for IAM policy changes (Automated)

4.4 IAMポリシー変更のためのログメトリックフィルタとアラームの存在を確認する。

【説明】
APIコールのリアルタイム監視は、CloudTrail LogsをCloudWatch Logsに誘導し、対応するメトリックフィルタとアラームを設定することで実現できます。
IAM(Identity and Access Management)ポリシーの変更には、メトリックフィルターとアラームを設定することが推奨されます。

【根拠】
IAMポリシーの変更を監視することで、認証と認可のコントロールが損なわれないようにすることができます。

4.5 Ensure a log metric filter and alarm exist for CloudTrail configuration changes (Automated)

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

【説明】
APIコールのリアルタイム監視は、CloudTrail LogsをCloudWatch Logsに誘導し、対応するメトリックフィルターとアラームを設定することで実現できます。
CloudTrailの設定の変更を検知するために、メトリックフィルターとアラームを設定することを推奨します。

【根拠】
CloudTrailの設定変更を監視することで、AWSアカウントで実行されるアクティビティを持続的に可視化することができます。

4.6 Ensure a log metric filter and alarm exist for AWS Management Console authentication failures (Automated)

4.6 AWSマネジメントコンソールの認証失敗に対するログメトリックフィルタとアラームが存在すること。

【説明】
APIコールのリアルタイム監視は、CloudTrail LogsをCloudWatch Logsに誘導し、対応するメトリックフィルタとアラームを設定することで実現できます。
コンソール認証の失敗に対してメトリックフィルターとアラームを設定することを推奨します。

【根拠】
失敗したコンソールログインを監視することで、ブルートフォースによる認証の試みを検出するまでの時間が短縮され、他のイベントの相関関係に使用できるソースIPなどの指標が得られる可能性があります。

4.7 Ensure a log metric filter and alarm exist for disabling or scheduled deletion of customer created CMKs (Automated)

4.7 顧客が作成した CMK の無効化または予定された削除のために、ログメトリックフィルタおよびアラームが存在することを確認する。

【説明】
APIコールのリアルタイム監視は、CloudTrail LogsをCloudWatch Logsに誘導し、対応するメトリックフィルタとアラームを設定することで実現できます。
お客様が作成したCMKのうち、状態が無効または削除予定に変更されたものについては、メトリックフィルタとアラームを設定することを推奨します。

【根拠】
無効化されたキーまたは削除されたキーで暗号化されたデータは、もはやアクセスできません。

4.8 Ensure a log metric filter and alarm exist for S3 bucket policy changes (Automated)

4.8 S3バケットのポリシー変更に対するログメトリックフィルタとアラームの存在を確認する。

【説明】
APIコールのリアルタイム監視は、CloudTrail LogsをCloudWatch Logsに誘導し、対応するメトリックフィルタとアラームを設定することで実現できます。
S3バケットポリシーの変更に対してメトリックフィルターとアラームを設定することを推奨します。

【根拠】
S3バケットのポリシーの変更を監視することで、機密性の高いS3バケットの寛容なポリシーを検出して修正する時間を短縮できる可能性があります。

4.9 Ensure a log metric filter and alarm exist for AWS Config configuration changes (Automated)

4.9 AWS Configの設定変更に対するログメトリックフィルタとアラームの存在を確認する。

【説明】
APIコールのリアルタイム監視は、CloudTrail LogsをCloudWatch Logsに誘導し、対応するメトリックフィルターとアラームを設定することで実現できます。
CloudTrailの設定の変更を検知するために、メトリックフィルターとアラームを設定することを推奨します。

【根拠】
AWS Config構成の変更を監視することで、AWSアカウント内の構成項目の可視性を持続させることができます。

4.10 Ensure a log metric filter and alarm exist for security group changes (Automated)

4.10 セキュリティグループの変更に対するログメトリックフィルタとアラームの存在を確認する。

【説明】
APIコールのリアルタイム監視は、CloudTrail LogsをCloudWatch Logsに誘導し、対応するメトリックフィルタとアラームを設定することで実現できます。
Security Groupsは、VPC内のトラフィックの入退出を制御するステートフルなパケットフィルターです。
Security Groupsの変更を検出するために、メトリックフィルタとアラームを設定することを推奨します。

【根拠】
セキュリティグループの変更を監視することで、リソースやサービスが意図せずに公開されないようにすることができます。

4.11 Ensure a log metric filter and alarm exist for changes to Network Access Control Lists (NACL) (Automated)

4.11 ネットワーク・アクセス・コントロール・リスト(NACL)の変更について、ログ・メトリック・フィルターとアラームが存在することを確認する。

【説明】
APIコールのリアルタイム監視は、CloudTrail LogsをCloudWatch Logsに誘導し、対応するメトリックフィルタとアラームを確立することで実現できます。
NACLは、VPC内のサブネットの入退出トラフィックを制御するステートレスなパケットフィルターとして使用されます。
NACLに加えられた変更については、メトリックフィルターとアラームを設定することを推奨します。

【根拠】
NACLの変更を監視することで、AWSのリソースやサービスが意図せずに公開されないようにすることができます。

4.12 Ensure a log metric filter and alarm exist for changes to network gateways (Automated)

4.12 ネットワークゲートウェイへの変更に対するログメトリックフィルタとアラームの存在を確認する。

【説明】
APIコールのリアルタイム監視は、CloudTrail LogsをCloudWatch Logsに誘導し、対応するメトリックフィルタとアラームを設定することで実現できます。
VPC外の宛先にトラフィックを送受信するには、ネットワークゲートウェイが必要です。
ネットワークゲートウェイの変更については、メトリックフィルタとアラームを設定することを推奨します。

【根拠】
ネットワーク ゲートウェイの変更を監視することで、すべてのイングレス/エグレス トラフィックが制御されたパスを経由して VPC ボーダーを通過するようになります。

4.13 Ensure a log metric filter and alarm exist for route table changes (Automated)

4.13 ルートテーブルの変更について、ログメトリックフィルタとアラームが確実に存在すること。

【説明】
APIコールのリアルタイムモニタリングは、CloudTrail LogsをCloudWatch Logsに誘導し、対応するメトリックフィルタやアラームを設定することで実現できます。
ルーティングテーブルは、サブネット間やネットワークゲートウェイへのネットワークトラフィックのルーティングに使用されます。
ルーティングテーブルの変更には、メトリックフィルタとアラームを設定することをお勧めします。

【根拠】
ルートテーブルの変更を監視することで、すべてのVPCトラフィックが期待通りの経路で流れるようになります。

4.14 Ensure a log metric filter and alarm exist for VPC changes (Automated)

4.14 VPC変更時にログメトリックフィルターとアラームが存在することを確認する。

【説明】
APIコールのリアルタイム監視は、CloudTrailログをCloudWatchログに誘導し、対応するメトリックフィルタとアラームを設定することで実現できます。
1つのアカウント内に複数のVPCを持つことができ、さらに2つのVPC間にピア接続を作成してVPC間のネットワークトラフィックのルーティングを可能にすることもできます。
VPCに加えられた変更については、メトリックフィルタとアラームを設定することをお勧めします。

【根拠】
VPCへの変更を監視することで、VPCのトラフィックフローが影響を受けないようにすることができます。

4.15 Ensure a log metric filter and alarm exists for AWS Organizations changes (Automated)

4.15 AWS Organizationsの変更に対するログメトリックフィルタとアラームの存在を確認する。

【説明】
APIコールのリアルタイム監視は、CloudTrail LogsをCloudWatch Logsに誘導し、対応するメトリックフィルタとアラームを設定することで実現できます。
マスターAWSアカウントで行われたAWS Organizationsの変更に対して、メトリックフィルターとアラームを設定することを推奨します。

【根拠】
AWS Organizationsの変更を監視することで、不正アクセスやその他のセキュリティ侵害につながるような、望ましくない、偶発的または意図的な変更を防ぐことができます。
この監視技術は、AWS Organizations内で実行された予期せぬ変更を調査し、不要な変更をロールバックすることを可能にします。

5 Networking

5 ネットワーク

このセクションでは、デフォルトの仮想プライベートクラウド(VPC)のセキュリティ関連の設定に関する推奨事項を説明します。

5.1 Ensure no Network ACLs allow ingress from 0.0.0.0/0 to remote server administration ports (Automated)

5.1 ネットワークACLが0.0.0.0/0からリモートサーバー管理ポートへの侵入を許可していないことを確認する。

【説明】
ネットワーク・アクセス・コントロール・リスト(NACL)機能は、AWSリソースへの入退室のネットワーク・トラフィックをステートレスにフィルタリングする機能です。NACLは、22番ポートへのSSHや3389番ポートへのRDPなど、リモートサーバーの管理ポートへの無制限のアクセスを許可しないことを推奨します。

【根拠】
22や3389などのリモートサーバー管理ポートへの一般アクセスは、リソースの攻撃対象を増やし、リソース侵害のリスクを不必要に高めることになります。

5.2 Ensure no security groups allow ingress from 0.0.0.0/0 to remote server administration ports (Automated)

5.2 0.0.0.0/0からリモートサーバー管理ポートへの侵入を許可するセキュリティグループがないことを確認する。

【説明】
セキュリティグループは、AWSリソースへのネットワークトラフィックの入退出をステートフルにフィルタリングします。
22番ポートへのSSHや3389番ポートへのRDPなど、リモートサーバー管理ポートへの無制限のイングレスアクセスを許可するセキュリティグループを設けないことを推奨します。

【根拠】
22や3389などのリモートサーバー管理ポートへの一般アクセスは、リソースの攻撃対象を増やし、リソース侵害のリスクを不必要に高めることになります。

5.3 Ensure the default security group of every VPC restricts all traffic Automated)

5.3 すべての VPC のデフォルトのセキュリティグループがすべてのトラフィックを制限するようにする。

【説明】
VPCにはデフォルトのセキュリティグループが設定されており、初期設定ではすべてのインバウンドトラフィックを拒否します。すべてのインバウンドトラフィックを拒否し、すべてのアウトバウンドトラフィックを許可し、そのセキュリティグループに割り当てられたインスタンス間のすべてのトラフィックを許可します。セキュリティグループに割り当てられたインスタンス間のすべてのトラフィックを許可します。
インスタンスの起動時にセキュリティグループを指定しなかった場合、そのインスタンスは自動的にこのデフォルトのセキュリティグループに割り当てられます。このデフォルトのセキュリティグループに自動的に割り当てられます。
セキュリティグループは フィルタリングを行うことができます。
デフォルトのセキュリティグループでは、すべてのトラフィックを制限することをお勧めします。デフォルトのセキュリティグループは、すべてのトラフィックを制限することをお勧めします。
すべてのリージョンのデフォルトVPCは、デフォルトのセキュリティグループをそれに合わせて更新する必要があります。
新規に作成されたVPCには、デフォルトのセキュリティグループが自動的に含まれます。この推奨事項に準拠するように修正する必要があります。
注:この推奨事項を実施する際には、VPCフローのロギングが非常に有効です。VPCフローロギングは、システムが正常に動作するために必要な最小限の特権のポートアクセスを決定する上で非常に有効です。現在のセキュリティ・グループの下で発生したすべてのパケットの受け入れと拒否を記録することができるからです。
これにより、最小特権エンジニアリングの主要な障壁である、システムに必要な最小限のポートの発見が劇的に減少します。環境でシステムが必要とする最小限のポートを発見することです。
このベンチマークで推奨されているVPCフローロギングが採用されなかったとしても このベンチマークで推奨されているVPCフローロギングは、恒久的なセキュリティ対策として採用されないとしても このベンチマークで推奨されているVPCフローロギングが恒久的なセキュリティ対策として採用されなくても、最小特権のセキュリティグループの発見とエンジニアリングの期間中は使用されるべきです。グループを使用することができます。

【根拠】
すべてのVPCのデフォルト・セキュリティ・グループをすべてのトラフィックを制限するように設定することで、最小特権のセキュリティ・グループの開発と、セキュリティ・グループへのAWSリソースの慎重な配置が促進され、結果的にそれらのリソースの露出を減らすことができます。

5.4 Ensure routing tables for VPC peering are “least access” (Manual)

5.4 VPCピアリングのルーティングテーブルが「最小のアクセス」であること。

【説明】
VPC ピアリング接続が確立されると、ルーティング テーブルを更新して、ピアリングされた VPC 間の接続を確立する必要があります。
これらのルートは必要に応じて特定することができ、VPCを接続の反対側にある単一のホストのみにピアリングすることも可能です。

【根拠】
ピアリングされたVPCでは、これらのルートの外側にあるリソースにはアクセスできないため、ピアリングのルーティングテーブルを高度に選択することは、侵害の影響を最小限に抑える非常に効果的な方法です。

セキュリティカテゴリの最新記事