翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
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」を参照してください。
AWS リージョン： (米国東部）、（ AWS GovCloud 米国西部）、中東 AWS GovCloud （バーレーン) を除く、 AWS リージョン コンフォーマンスパックがサポートされているすべての (リージョンサポート )
| コントロール ID | コントロールの概要 | AWS Config ルール | ガイダンス |
|---|---|---|---|
| 1.1 | 現在の連絡先情報を維持します | account-contact-details-configured （プロセスチェック） | 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 （プロセスチェック） | 組織のセキュリティチームの連絡先の 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 （プロセスチェック） | 日常的なタスクで、ルートアカウントを使用しないようにしてください。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 Foundational Security Best Practices 値: true) RequireSymbols 、（AWS Foundational Security Best Practices 値: true) RequireNumbers 、(AWS Foundational Security Best Practices 値: true) MinimumPasswordLength 、（AWS Foundational Security Best Practices 値: 14) PasswordReusePrevention、 (AWS Foundational Security Best Practices 値: 24)、および MaxPasswordAge (AWS Foundational Security Best Practices 値: 90) を IAM パスワードポリシーに設定することができます。実際の値には、組織のポリシーを反映する必要があります。 | |
| 1.9 | IAM パスワードポリシーはパスワードの再使用を禁止しています | ID と認証情報は、組織の IAM パスワードポリシーに基づいて発行、管理、検証されます。これらは、NIST SP 800-63 およびパスワード強度に関する AWS Foundational Security Best Practices 標準で規定されている要件を満たしています。このルールでは、オプションで RequireUppercaseCharacters （AWS Foundational Security Best Practices 値: true)、 RequireLowercaseCharacters （AWS Foundational Security Best Practices 値: true) RequireSymbols 、（AWS Foundational Security Best Practices 値: true) RequireNumbers 、(AWS Foundational Security Best Practices 値: true) MinimumPasswordLength 、（AWS Foundational Security Best Practices 値: 14) PasswordReusePrevention、 (AWS Foundational Security Best Practices 値: 24)、および MaxPasswordAge (AWS Foundational Security Best Practices 値: 90) を IAM パスワードポリシーに設定することができます。実際の値には、組織のポリシーを反映する必要があります。 | |
| 1.10 | コンソールパスワードを持っているすべてのユーザーについて多要素認証 (MFA) が有効であることを確認します。 | コンソールパスワードを持つすべての AWS Identity and Access Management (IAM) ユーザーに対して MFA が有効になっていることを確認して、 AWS クラウド内のリソースへのアクセスを管理します。MFA は、サインイン認証情報に加えて更なる保護手段を追加します。ユーザーに MFA を要求することで、アカウントが侵害されるインシデントを減らし、権限のないユーザーが機密データにアクセスできないようにすることができます。 | |
| 1.11 | コンソールパスワードを持つすべてのユーザーの初期ユーザー集合アップ中にアクセスキーを集合アップしないでください | iam-user-console-and- api-access-at-creation （プロセスチェック） | コンソールのパスワードを持つすべてのユーザーの初期設定時に、アクセスキーが設定されないようにします。コンソールにアクセスできるすべてのユーザーについて、ユーザーの「作成時刻」とアクセスキーの「作成日」を比較します。このコントロールの監査の詳細については、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 (プロセスチェック） | 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 ポリシーが適切なユーザー、ロール、またはグループに割り当てられるようにすることで、アクセス許可と認可を管理するのに役立ちます。これらのポリシーを制限することは、最小特権と職務分離の原則も組み込まれています。このルールでは、 Support による AWS インシデント管理のために AWSSupportAccesspolicyARN を arn:aws:iam::aws:policy/ に設定する必要があります。 | |
| 1.18 | インスタンスからの AWS リソースアクセスに IAM インスタンスロールが使用されていることを確認する | EC2 インスタンスプロファイルによって、IAM ロールが EC2 インスタンスに渡されます。インスタンスプロファイルをインスタンスにアタッチすることで、最小特権とアクセス許可を管理できます。 | |
| 1.19 | AWS IAM に保存されている期限切れの SSL/TLS 証明書が、すべて削除されていることを確認します。 | iam-expired-certificates （プロセスチェック） | IAM に保存されている期限切れの SSL/TLS 証明書が、すべて削除されていることを確認します。 AWS CLI がインストールされているコマンドラインから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 | AWS IAM Access Analyzer が有効になっていることを確認する | iam-access-analyzer-enabled （プロセスチェック） | 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 Default: True)、 blockPublicPolicy (Config Default: True)、 blockPublicAcls (Config Default: True)、および restrictPublicBuckets パラメータ (Config Default: 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 アドレス、呼び出しが発生した日時を特定できます。 CloudTrail MULTI_REGION_CLOUD_TRAIL_ENABLED が有効になっている場合、 はすべての 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 証跡が ログと CloudWatch統合されていることを確認する | Amazon CloudWatch を使用して、ログイベントアクティビティを一元的に収集および管理します。データを含めると AWS CloudTrail 、 内の API コールアクティビティの詳細が表示されます AWS アカウント。 | |
| 3.5 | AWS Config がすべてのリージョンで有効になっていることを確認する | config-enabled-all-regions （プロセスチェック） | AWS Config がすべての 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 （プロセスチェック） | 不正な 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 (プロセスチェック） | 多要素認証 (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 （プロセスチェック） | ルートアカウントに対するログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、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 （プロセスチェック） | 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 （プロセスチェック） | CloudTrail 設定変更の AWS ログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、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 （プロセスチェック） | 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 (プロセスチェック） | 顧客によって作成される 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 （プロセスチェック） | Amazon S3 バケットのポリシーの変更に対するログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.9 | AWS Config 設定の変更に対してログメトリクスフィルターとアラームが存在することを確認する | alarm-aws-config-change （プロセスチェック） | 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 (プロセスチェック） | セキュリティグループの変更に対するログメトリクスフィルターとアラームが存在することを確認します このコントロールの監査の詳細については、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 （プロセスチェック） | ネットワークアクセスコントロールリスト (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 (プロセスチェック） | ネットワークゲートウェイへの変更に対するログメトリクスとアラームが存在することを確認します。このコントロールの監査の詳細については、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 (プロセスチェック） | ルートテーブルの変更に対するログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.14 | VPC の変更に対してログメトリクスフィルターとアラームが存在することを確認します | alarm-vpc-change （プロセスチェック） | 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 （プロセスチェック） | 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 （プロセスチェック） | VPC ピアリングのルーティングテーブルが「最小限のアクセス」になっていることを確認します コンソールの [VPC] セクションで、ルートテーブルのエントリを確認し、ピアリングの目的を達成するために必要な最小限のサブネットまたはホストがルーティング可能であることを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
テンプレート
テンプレートは、 GitHub: CIS AWS Foundations Benchmark v1.4 Level 2 の「Operational Best Practices for CIS Foundations Benchmark v1.4 Level 2
