翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
CIS AWS Foundations Benchmark v1.4 Level 2 の運用上のベストプラクティス
コンフォーマンスパックは、 マネージドルールまたはカスタム AWS Config ルールと AWS Config 修復アクションを使用して、セキュリティ、運用、またはコスト最適化のガバナンスチェックを作成できるように設計された汎用コンプライアンスフレームワークを提供します。サンプルテンプレートとしてのコンフォーマンスパックは、特定のガバナンスまたはコンプライアンス基準を準拠するようには設計されていません。お客様は、本サービスの利用が該当する法的要件および規制要件を満たしているかどうかについて、お客様自身で評価する責任を負います。
以下に、Center for Internet Security (CIS) Amazon Web Services Foundation v1.4 Level 2 と AWS マネージド Config ルール/AWS Config プロセスチェック間のマッピングの例を示します。各 Config ルールは特定の AWS リソースに適用され、1 つ以上の CIS Amazon Web Services Foundation v1.4 Level 2 コントロールに関連付けられます。CIS の「Amazon Web Services Foundation v1.4 Level 2」によるコントロールを、複数の Config ルールに関連付けることができます。これらのマッピングに関する詳細およびガイダンスについては、以下の表を参照してください。
プロセスチェックの詳細については、「process-checks」を参照してください。
| コントロール ID | コントロールの概要 | AWS 設定ルール | ガイダンス |
|---|---|---|---|
| 1.1 | 現在の連絡先情報を維持します | account-contact-details-configured (Process Check) | AWS アカウントの連絡先の E メールと電話番号が最新のものであり、組織内の 1 人以上の個人にマッピングされていることを確認します。コンソールの [My Account] (マイアカウント) セクションで、[Contact Information] (連絡先情報) セクションに正しい情報が指定されていることを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 1.2 | セキュリティの連絡先情報が登録されていることを確認します。 | account-security-contact-configured (Process Check) | 組織のセキュリティチームの連絡先の E メールと電話番号が最新のものであることを確認します。 AWS マネジメントコンソールのマイアカウントセクションで、セキュリティセクションに正しい情報が指定されていることを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 1.4 | 「ルート」ユーザーのアクセスキーが存在しないことを確認する | ルートユーザーに AWS Identity and Access Management (IAM) ロールにアタッチされたアクセスキーがないことを確認することで、システムとアセットへのアクセスを制御できます。root アクセスキーが削除されていることを確認します。代わりに、最小機能の原則を組み込むのに役立つ AWS アカウント ロールベースの を作成して使用します。 | |
| 1.5 | MFA が「ルート」ユーザーで有効になっていることを確認する | ルートユーザーに対して MFA が有効になっていることを確認して、 AWS クラウド内のリソースへのアクセスを管理します。ルートユーザーは、最も権限のある AWS アカウントのユーザーです。MFA は、ユーザー名とパスワードに 1 つの保護レイヤーを追加します。ルートユーザーに MFA を要求することで、侵害されるインシデントを減らすことができます AWS アカウント。 | |
| 1.6 | 「ルート」ユーザーアカウントでハードウェア MFA を有効にします | ルートユーザーに対してハードウェア MFA が有効になっていることを確認して、 AWS クラウド内のリソースへのアクセスを管理します。ルートユーザーは、最も権限のある AWS アカウントのユーザーです。MFA は、サインイン認証情報に更なる保護手段を追加します。ルートユーザーに MFA を要求することで、侵害されるインシデントを減らすことができます AWS アカウント。 | |
| 1.7 | 管理および日常のタスクでの「root」ユーザーの使用を排除します | root-account-regular-use (Process Check) | 日常的なタスクで、ルートアカウントを使用しないようにしてください。IAM で認証情報レポートを実行し、ルートユーザーが最後に使用された時期を調べます。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 1.8 | IAM パスワードポリシーにおいて 14 文字以上の長さが必要になります。 | ID と認証情報は、組織の IAM パスワードポリシーに基づいて発行、管理、検証されます。これらは、NIST SP 800-63 およびパスワード強度に関する AWS Foundational Security Best Practices 標準に記載されている要件を満たしています。このルールでは、オプションで RequireUppercaseCharacters (AWS Foundational Security Best Practices 値： true)、 RequireLowercaseCharacters (AWS 基本的なセキュリティのベストプラクティス値： true)、 RequireSymbols (AWS 基礎セキュリティのベストプラクティス値： true)、 RequireNumbers (AWS 基礎セキュリティのベストプラクティス値： true)、 MinimumPasswordLength (AWS 基本的なセキュリティのベストプラクティス値： 14)、 PasswordReusePrevention (AWS 基本的なセキュリティのベストプラクティス値： 24)、 および MaxPasswordAge (AWS 基礎セキュリティのベストプラクティス値： 90)。実際の値には、組織のポリシーを反映する必要があります。 | |
| 1.9 | IAM パスワードポリシーはパスワードの再使用を禁止しています | ID と認証情報は、組織の IAM パスワードポリシーに基づいて発行、管理、検証されます。これらは、NIST SP 800-63 およびパスワード強度に関する AWS Foundational Security Best Practices 標準に記載されている要件を満たしています。このルールでは、オプションで RequireUppercaseCharacters (AWS Foundational Security Best Practices 値： true)、 RequireLowercaseCharacters (AWS 基本的なセキュリティのベストプラクティス値： true)、 RequireSymbols (AWS 基礎セキュリティのベストプラクティス値： true)、 RequireNumbers (AWS 基礎セキュリティのベストプラクティス値： true)、 MinimumPasswordLength (AWS 基本的なセキュリティのベストプラクティス値： 14)、 PasswordReusePrevention (AWS 基本的なセキュリティのベストプラクティス値： 24)、 および MaxPasswordAge (AWS 基礎セキュリティのベストプラクティス値： 90)。実際の値には、組織のポリシーを反映する必要があります。 | |
| 1.10 | コンソールパスワードを持っているすべてのユーザーについて多要素認証 (MFA) が有効であることを確認します。 | コンソールパスワードを持つすべての AWS Identity and Access Management (IAM) ユーザーに対して MFA が有効になっていることを確認して、 AWS クラウド内のリソースへのアクセスを管理します。MFA は、サインイン認証情報に加えて更なる保護手段を追加します。ユーザーに MFA を要求することで、アカウントが侵害されるインシデントを減らし、権限のないユーザーが機密データにアクセスできないようにすることができます。 | |
| 1.11 | コンソールパスワードを持つすべてのユーザーの初期ユーザー集合アップ中にアクセスキーを集合アップしないでください | iam-user-console-and-api-access-at-creation (Process Check) | コンソールのパスワードを持つすべてのユーザーの初期設定時に、アクセスキーが設定されないようにします。コンソールにアクセスできるすべてのユーザーについて、ユーザーの「作成時刻」とアクセスキーの「作成日」を比較します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 1.12 | 45 日間以上使用されていない認証情報は無効にします。 | AWS Identity and Access Management (IAM) は、指定された期間に使用されていない IAM パスワードとアクセスキーをチェックすることで、アクセス許可と認可に役立ちます。これらの未使用の認証情報が特定された場合は、最小特権の原則に反する可能性があるため、その認証情報を無効にするか、削除する必要があります。このルールでは、maxCredentialUsageAge の値を設定する必要があります (CIS スタンダード値デフォルト: 45)。実際の値には、組織のポリシーを反映する必要があります。 | |
| 1.13 | 1 人のユーザーが使用できるアクティブなアクセスキーが 1 つのみであることを確認します。 | iam-user-single-access-key (Process Check) | 1 人のユーザーが使用できるアクティブなアクセスキーが 1 つのみであることを確認します。すべてのユーザーについて、[Security Credentials] (認証情報) タブで IAM の各ユーザーに使用されているアクティブなキーが 1 つのみであることを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 1.14 | アクセスキーは 90 日ごとに更新します。 | 組織のポリシーが指定した通り IAM アクセスキーがローテーションされるようにすることで、認可されたデバイス、ユーザー、プロセスについての認証情報が監査されます。アクセスキーを定期的に変更することが、セキュリティのベストプラクティスです。これにより、アクセスキーがアクティブになっている期間が短縮され、キーが侵害された場合のビジネスへの影響を軽減できます。このルールでは、アクセスキーの更新の値が必要です (Config デフォルト: 90)。実際の値には、組織のポリシーを反映する必要があります。 | |
| 1.15 | ユーザーがグループを通してのみアクセス権を受け取るようにします。 | このルールにより、 AWS Identity and Access Management (IAM) ポリシーは、システムおよびアセットへのアクセスを制御するために、グループまたはロールにのみアタッチされます。グループレベルまたはロールレベルで特権を割り当てると、ID が過剰な特権を受け取ったり保持したりする機会を減らすことができます。 | |
| 1.15 | ユーザーがグループを通してのみアクセス権を受け取るようにします。 | AWS Identity and Access Management (IAM) ユーザー、IAM ロール、または IAM グループに、システムおよびアセットへのアクセスを制御するインラインポリシーがないことを確認します。 AWS では、インラインポリシーの代わりに 管理ポリシーを使用することをお勧めします。管理ポリシーにより、再利用性、バージョニング、ロールバック、権限管理の委任が可能になります。 | |
| 1.15 | ユーザーがグループを通してのみアクセス権を受け取るようにします。 | AWS Identity and Access Management (IAM) は、ユーザーが少なくとも 1 つのグループのメンバーであることを確認することで、アクセス許可と認可を制限するのに役立ちます。タスク完了のために必要以上の権限をユーザーに許可することは、最小特権と職務の分離の原則に反する可能性があります。 | |
| 1.16 | 完全な「*:*」管理権限を許可する IAM ポリシーは作成されません。 | AWS Identity and Access Management (IAM) は、最小特権と職務分離の原則をアクセス許可と認可に組み込み、ポリシーに「リソース」：「*」ではなく「アクション」：「*」の「効果」：「許可」を含めることを制限するのに役立ちます。タスク完了のために必要以上の権限をユーザーに付与することは、最小特権と職務の分離の原則に反する可能性があります。 | |
| 1.17 | サポートでインシデントを管理するための AWS サポートロールが作成されていることを確認します。 | AWS Identity and Access Management (IAM) は、IAM ポリシーが適切なユーザー、ロール、またはグループに割り当てられるようにすることで、アクセス許可と認可を管理するのに役立ちます。これらのポリシーを制限することは、最小特権と職務分離の原則も組み込まれています。このルールでは、 AWS Support でのインシデント管理のために、policyARN を arn:aws:iam::aws:policy/AWSSupportAccess に設定することが要求されます。 | |
| 1.18 | インスタンスからの AWS リソースアクセスに IAM インスタンスロールが使用されていることを確認する | EC2 インスタンスプロファイルによって、IAM ロールが EC2 インスタンスに渡されます。インスタンスプロファイルをインスタンスにアタッチすることで、最小特権とアクセス許可を管理できます。 | |
| 1.19 | AWS IAM に保存されている期限切れの SSL/TLS 証明書が、すべて削除されていることを確認します。 | iam-expired-certificates (Process Check) | IAM に保存されている期限切れの SSL/TLS 証明書が、すべて削除されていることを確認します。CLI AWS がインストールされているコマンドラインからAWS 「iam list-server-certificates」コマンドを実行し、期限切れのサーバー証明書があるかどうかを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 1.20 | IAM Access Analyzer AWS が有効になっていることを確認する | iam-access-analyzer-enabled (Process Check) | IAM Access Analyzer が有効になっていることを確認します。コンソールの [IAM] セクションで、[Access Analyzer] (アクセスアナライザー) を選択し、[STATUS] が [Active] (有効) に設定されていることを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください。 |
| 1.21 | マルチアカウント環境の ID フェデレーションまたは AWS Organizations からユーザーが一元管理されていることを確認します。 | account-part-of-organizations | Organizations AWS アカウント 内の AWS の一元管理は、アカウントが確実に準拠するようにするのに役立ちます。アカウントの管理が一元化されていないと、アカウントの設定に一貫性がなくなり、リソースや機密データが流出する可能性があります。 |
| 2.1.1 | すべての S3 バケットが encryption-at-rest を採用していることを確認します。 | 保管中のデータを保護するため、Amazon Simple Storage Service (Amazon S3) バケットで暗号化が有効になっていることを確認します。Amazon S3 バケットには機密データが含まれている可能性があるため、暗号化を有効にしてデータを保護します。 | |
| 2.1.2 | S3 Bucket Policy が HTTP リクエストを拒否するように設定されていることを確認します。 | 転送中のデータを保護するため、Amazon Simple Storage Service (Amazon S3) バケットで、Secure Sockets Layer (SSL) を使用するためのリクエストが必要かどうかを確認します。機密データが含まれている可能性があるため、転送中の暗号化を有効にしてデータを保護します。 | |
| 2.1.3 | S3 バケットで MFA Delete が有効であることを確認する。 | Amazon Simple Storage Service (Amazon S3) バケットのバージョニングは、同じ Amazon S3 バケットでオブジェクトの複数のバリアントを保持するのに役立ちます。S3バケットに多要素認証 (MFA) 削除を追加すると、バケットのバージョン状態を変更したり、オブジェクトのバージョンを削除したりするために、追加の認証要素が必要になります。MFA 削除により、万が一、セキュリティ認証が漏洩したり、不正なアクセスが行われた場合でも、セキュリティのレイヤーを追加することができます。 | |
| 2.1.5 | S3バケットに「パブリックアクセスをブロックする (バケット設定) 」が設定されていることを確認する | Amazon Simple Storage Service (Amazon S3) バケットにパブリックにアクセスできないようにすることで、 AWS クラウド内のリソースへのアクセスを管理します。このルールは、パブリックアクセスを防止することで、権限のないリモートユーザーから機密データを保護するのに役立ちます。このルールでは、ignorePublicAcls (Config デフォルト: True)、blockPublicPolicy (Config デフォルト: True)、blockPublicAcls (Config デフォルト: True)、および restrictPublicBuckets (Config デフォルト: True) の各パラメータを必要に応じて設定できます。実際の値には、組織のポリシーを反映する必要があります。 | |
| 2.1.5 | S3バケットに「パブリックアクセスをブロックする (バケット設定) 」が設定されていることを確認する | Amazon Simple Storage Service (Amazon S3) バケットにパブリックにアクセスできないようにすることで、 AWS クラウド内のリソースへのアクセスを管理します。このルールでは、バケットレベルでのパブリックアクセスを防止することで、権限のないリモートユーザーから機密データを保護します。 | |
| 2.2.1 | EBSボリュームの暗号化が有効であることを確認します | 機密データが含まれている可能性があるため、保管中のデータを保護するために Amazon Elastic Block Store (Amazon EBS) ボリュームで暗号化が有効になっていることを確認します。 | |
| 2.2.1 | EBSボリュームの暗号化が有効であることを確認します | 保管中のデータを保護するため、Amazon Elastic Block Store (Amazon EBS) ボリュームで暗号化が有効になっていることを確認します。これらのボリュームには機密データが含まれている可能性があるため、保管時の暗号化を有効にしてデータを保護します。 | |
| 2.3.1 | RDSインスタンスで暗号化が有効であることを確認します | Amazon Relational Database Service (Amazon RDS) スナップショットで、暗号化が有効になっていることを確認します。機密データが含まれている可能性があるため、保管時の暗号化を有効にしてデータを保護します。 | |
| 2.3.1 | RDSインスタンスで暗号化が有効であることを確認します | 保管中のデータを保護するため、Amazon Relational Database Service (Amazon RDS) インスタンスで暗号化が有効になっていることを確認します。Amazon RDS インスタンスには機密データが含まれている可能性があるため、保管時の暗号化を有効にしてデータを保護します。 | |
| 3.1 | CloudTrail はすべてのリージョンで有効になっていることを確認します | AWS CloudTrail は、 AWS マネジメントコンソールのアクションと API コールを記録します。が呼び出したユーザーとアカウント AWS、呼び出し元のソース IP アドレス、および呼び出しの発生日時を特定できます。MULTI_REGION_CLOUD_TRAIL_ENABLED が有効になっている場合、CloudTrail はすべての AWS リージョンから S3 バケットにログファイルを配信します。さらに、 が新しいリージョン AWS を起動すると、CloudTrail は新しいリージョンに同じ証跡を作成します。その結果、アクションを実行しなくても、新しいリージョンの API アクティビティを含むログファイルを受け取ることができるようになります。 | |
| 3.2 | CloudTrailのログファイル検証が有効であることを確認する | AWS CloudTrail ログファイルの検証を使用して、CloudTrail ログの整合性をチェックします。ログファイルの検証は、CloudTrail がログファイルを配信した後に変更されたか、削除されたか、変更されていないかを判断するのに役立ちます。この機能は、業界標準のアルゴリズムを使用して構築されています。ハッシュ用の SHA-256 とデジタル署名用の RSA を備えた SHA-256。これにより、CloudTrail ログファイルを検出せずに変更、削除、または偽造することは計算上実行不可能になります。 | |
| 3.3 | CloudTrail ログの保存に使用されるS3 バケットが一般公開されていないことを確認します | Amazon Simple Storage Service (Amazon S3) バケットへのアクセスを許可されたユーザー、プロセス、デバイスのみに許可することで、 AWS クラウド内のリソースへのアクセスを管理します。アクセスの管理は、データの分類と一致している必要があります。 | |
| 3.3 | CloudTrail ログの保存に使用されるS3 バケットが一般公開されていないことを確認します | Amazon Simple Storage Service (Amazon S3) バケットへのアクセスを許可されたユーザー、プロセス、デバイスのみに許可することで、 AWS クラウド内のリソースへのアクセスを管理します。アクセスの管理は、データの分類と一致している必要があります。 | |
| 3.3 | CloudTrail ログの保存に使用されるS3 バケットが一般公開されていないことを確認します | Amazon Simple Storage Service (Amazon S3) バケットにパブリックにアクセスできないようにすることで、 AWS クラウド内のリソースへのアクセスを管理します。このルールでは、バケットレベルでのパブリックアクセスを防止することで、権限のないリモートユーザーから機密データを保護します。 | |
| 3.4 | CloudTrailトレイルが CloudWatchLogs と統合されていることを確認します。 | Amazon CloudWatch を使用して、イベントのアクティビティログを一元的に収集および管理します。 AWS CloudTrail データを含めると、 内の API コールアクティビティの詳細が提供されます AWS アカウント。 | |
| 3.5 | Config AWS がすべてのリージョンで有効になっていることを確認する | config-enabled-all-regions (Process Check) | Config AWS がすべての AWS リージョンで有効になっていることを確認します。コンソールの AWS Config セクション内で、有効なリージョンごとに AWS Config レコーダーが正しく設定されていることを確認します。グローバル AWS リソースのレコードが、少なくとも 1 つのリージョンで有効になっていることを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 3.6 | S3 バケットアクセスログ記録が CloudTrail S3 バケットで有効になっていることを確認します | Amazon Simple Storage Service (Amazon S3) サーバーアクセスのログ記録によって、ネットワークをモニタリングし、潜在的なサイバーセキュリティイベントに対応することができます。Amazon S3 バケットに対して行われたリクエストの詳細な記録をキャプチャすることで、イベントをモニタリングします。各アクセスのログレコードから、1 つのアクセスリクエストについての詳細情報を取得できます。詳細情報には、リクエスタ、バケット名、リクエスト時刻、リクエストアクション、レスポンスのステータス、エラーコード (該当する場合) などの情報が含まれます。 | |
| 37 | CloudTrail ログは保管時に KMS CMKs を使用して暗号化されていることを確認します | 機密データが存在する可能性があるため、保管中のデータを保護するために、 AWS CloudTrail 証跡で暗号化が有効になっていることを確認してください。 | |
| 3.8 | カスタマー作成の CMK のローテーションが有効になっていることを確認します | キーのローテーションを有効にして、暗号化期間の最後に到達したときにキーがローテーションされるようにします。 | |
| 3.9 | すべての VPCs で VPC フローログ記録が有効になっていることを確認します | VPC フローログでは、Amazon Virtual Private Cloud (Amazon VPC) 内のネットワークインターフェイス間で送受信される IP トラフィックに関する情報の詳細な記録を提供します。フローログレコードには、送信元、送信先、プロトコルなど、IP フローのさまざまなコンポーネントの値がデフォルトで含まれています。 | |
| 3.10 | S3 バケットで書き込みイベントのオブジェクトレベルのログが有効になっていることを確認します | Simple Storage Service (Amazon S3) のデータイベントを収集することで、異常性の高いアクティビティを検出できます。詳細には、Amazon S3 バケットにアクセスした AWS アカウントの情報、IP アドレス、イベント発生時刻が含まれます。 | |
| 3.11 | S3 バケットで書き込みイベントのオブジェクトレベルのログが有効になっていることを確認します | Simple Storage Service (Amazon S3) のデータイベントを収集することで、異常性の高いアクティビティを検出できます。詳細には、Amazon S3 バケットにアクセスした AWS アカウントの情報、IP アドレス、イベント発生時刻が含まれます。 | |
| 4.1 | 不正な API 呼び出しに対してログメトリクスフィルターとアラームが存在することを確認します | alarm-unauthorized-api-calls (Process Check) | 不正な API コールに対するログメトリクスフィルターとアラームが存在することを確認します このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.2 | MFA を使用しないマネジメントコンソールサインインに対してログメトリクスフィルターとアラームが存在することを確認します | alarm-sign-in-without-mfa (Process Check) | 多要素認証 (MFA) を使用しない AWS マネジメントコンソールのサインインに対するログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.3 | 「ルート」アカウントに対してログメトリクスフィルターとアラームが存在することを確認します | alarm-root-account-use (Process Check) | ルートアカウントに対するログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.4 | MFA なしの IAM ポリシーの変更に対してログメトリクスフィルターとアラームが存在することを確認します。 | alarm-iam-policy-change (Process Check) | IAM ポリシーの変更に対するログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.5 | CloudTrail の設定の変更に対するログメトリクスフィルターとアラームが存在することを確認します。 | alarm-cloudtrail-config-change (Process Check) | AWS CloudTrail 設定の変更に対するログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.6 | AWS マネジメントコンソールでの認証の失敗に対するログメトリクスフィルターとアラームが存在するようにする | alarm-console-auth-failures (Process Check) | AWS マネジメントコンソールでの認証の失敗に対するログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.7 | カスタマー作成の CMK の無効化またはスケジュールされた削除に対してログメトリクスフィルターとアラームが存在することを確認します | alarm-kms-disable-or-delete-cmk (Process Check) | 顧客によって作成される CMK の無効化またはスケジュールされた削除に対するログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.8 | S3 バケットの変更に対してログメトリクスフィルターとアラームが存在することを確認します | alarm-s3-bucket-policy-change (Process Check) | Amazon S3 バケットのポリシーの変更に対するログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.9 | Config AWS 設定の変更に対してログメトリクスフィルターとアラームが存在することを確認する | alarm-aws-config-change (Process Check) | AWS Config の変更に対してログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.10 | セキュリティグループの変更に対するメトリクスフィルターとアラームが存在することを確認します | alarm-vpc-secrity-group-change (Process Check) | セキュリティグループの変更に対するログメトリクスフィルターとアラームが存在することを確認します このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.11 | ネットワークアクセスコントロールリスト (NACL) への変更に対するログメトリクスとアラームが存在することを確認します | alarm-vpc-nacl-change (Process Check) | ネットワークアクセスコントロールリスト (NACL) への変更に対するログメトリクスフィルターとアラームが存在することを確認します このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.12 | ネットワークゲートウェイへの変更に対するログメトリクスとアラームが存在することを確認します | alarm-vpc-network-gateway-change (Process Check) | ネットワークゲートウェイへの変更に対するログメトリクスとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.13 | ルートテーブルの変更に対してログメトリクスフィルターとアラームが存在することを確認します | alarm-vpc-route-table-change (Process Check) | ルートテーブルの変更に対するログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.14 | VPC の変更に対してログメトリクスフィルターとアラームが存在することを確認します | alarm-vpc-change (Process Check) | Amazon Virtual Private Cloud (Amazon VPC) の変更に対するログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.15 | AWS Organizations の変更に対するログメトリクスフィルターとアラームが存在することを確認する | alarm-organizations-change (Process Check) | AWS Organizations の変更に対するログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 5.1 | ネットワーク ACL が 0.0.0.0/0 からリモートサーバー管理ポートへの侵入を許可していないことを確認します | ネットワーク ACL で、リモートサーバーの管理ポートへのパブリック Ingress が許可されていないことを確認します。コンソールの [VPC] セクションで、ソースが「0.0.0.0/0」のネットワーク ACL があり、リモートサーバーの管理者ポートを含むポートまたはポート範囲が許可されていることを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください | |
| 5.2 | ネットワーク ACL が 0.0.0.0/0 からリモートサーバー管理ポートへの侵入を許可していないことを確認します。 | Amazon Elastic Compute Cloud (Amazon EC2) セキュリティグループは、 AWS リソースへの送受信ネットワークトラフィックをステートフルにフィルタリングすることで、ネットワークアクセスの管理に役立ちます。リソースで 0.0.0.0/0 からポート 22 への入力 (またはリモート) トラフィックを許可しないようにすることで、リモートアクセスを制限できます。 | |
| 5.2 | ネットワーク ACL が 0.0.0.0/0 からリモートサーバー管理ポートへの侵入を許可していないことを確認します。 | Amazon Elastic Compute AWS Cloud (Amazon EC2) セキュリティグループで共通ポートが制限されるようにすることで、 クラウド内のリソースへのアクセスを管理します。ポートへのアクセスを信頼できるソースに制限しなければ、システムの可用性、完全性、機密性に対する脅威を招く可能性があります。このルールでは、blockedPort1～blockedPort5 パラメータ (CIS標準値: 3389) を任意に設定することができます。実際の値には、組織のポリシーを反映する必要があります。 | |
| 5.3 | すべての VPC のデフォルトセキュリティグループがすべてのトラフィックを制限するようにします | Amazon Elastic Compute Cloud (Amazon EC2) セキュリティグループは、 AWS リソースへの送受信ネットワークトラフィックをステートフルにフィルタリングすることで、ネットワークアクセスの管理に役立ちます。デフォルトのセキュリティグループ上のすべてのトラフィックを制限すると、 AWS リソースへのリモートアクセスを制限するのに役立ちます。 | |
| 5.4 | VPC ピアリングのルーティングテーブルが「アクセスが最も少ない」ことを確認します | vpc-peering-least-access (Process Check) | VPC ピアリングのルーティングテーブルが「最小限のアクセス」になっていることを確認します コンソールの [VPC] セクションで、ルートテーブルのエントリを確認し、ピアリングの目的を達成するために必要な最小限のサブネットまたはホストがルーティング可能であることを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
テンプレート
テンプレートは、GitHub の「Operational Best Practices for CIS AWS Foundations Benchmark v1.4 Level 2
