翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
CIS 運用のベストプラクティス AWS 基礎ベンチマーク v1.4 レベル 1
コンフォーマンスパックは、マネージドルールやカスタム AWS Config ルールと AWS Config 修復アクションを使用して、セキュリティ、運用、コスト最適化のガバナンスチェックを作成できるように設計された汎用コンプライアンスフレームワークを提供します。サンプルテンプレートとしてのコンフォーマンスパックは、特定のガバナンスまたはコンプライアンス基準を準拠するようには設計されていません。お客様は、本サービスの利用が該当する法的要件および規制要件を満たしているかどうかについて、お客様自身で評価する責任を負います。
以下に、Center for Internet Security (CIS) の「Amazon Web Services Foundation v1.4 Level 1」と、AWS マネージド Config ルール/AWS Config プロセスチェック間のマッピングの例を示します。各 Config ルールが特定の AWS リソースに適用され、1 つ以上の CIS の「Amazon Web Services Foundation v1.4 Level 1 によるコントロールに関連付けられます。CIS の「Amazon Web Services Foundation v1.4 Level 1」によるコントロールを、複数の Config ルールに関連付けることができます。これらのマッピングに関する詳細およびガイダンスについては、以下の表を参照してください。
プロセスチェックの詳細については、「process-checks」を参照してください。
| コントロール ID | コントロールの概要 | AWS Config ルール | ガイダンス |
|---|---|---|---|
| 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.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 パスワードポリシーに基づいて発行、管理、検証されます。これらの ID と認証情報は、NIST SP 800-63 および AWS の基本的なセキュリティのベストプラクティス標準で規定されているパスワード強度の要件を満たしています。このルールでは、必要に応じて RequireUppercaseCharacters (AWS の基本的なセキュリティのベストプラクティスの値: true)、RequireLowercaseCharacters (AWS の基本的なセキュリティのベストプラクティスの値: true)、RequireSymbols (AWS の基本的なセキュリティのベストプラクティスの値: true)、RequireNumbers (AWS の基本的なセキュリティのベストプラクティスの値: true)、MinimumPasswordLength (AWS の基本的なセキュリティのベストプラクティスの値: 14)、PasswordReusePrevention (AWS の基本的なセキュリティのベストプラクティスの値: 24)、および MaxPasswordAge (AWS の基本的なセキュリティのベストプラクティスの値: 90) を、IAM パスワードポリシーに設定できます。実際の値には、組織のポリシーを反映する必要があります。 | |
| 1.9 | IAM パスワードポリシーはパスワードの再使用を禁止しています | ID と認証情報は、組織の IAM パスワードポリシーに基づいて発行、管理、検証されます。これらの ID と認証情報は、NIST SP 800-63 および AWS の基本的なセキュリティのベストプラクティス標準で規定されているパスワード強度の要件を満たしています。このルールでは、必要に応じて RequireUppercaseCharacters (AWS の基本的なセキュリティのベストプラクティスの値: true)、RequireLowercaseCharacters (AWS の基本的なセキュリティのベストプラクティスの値: true)、RequireSymbols (AWS の基本的なセキュリティのベストプラクティスの値: true)、RequireNumbers (AWS の基本的なセキュリティのベストプラクティスの値: true)、MinimumPasswordLength (AWS の基本的なセキュリティのベストプラクティスの値: 14)、PasswordReusePrevention (AWS の基本的なセキュリティのベストプラクティスの値: 24)、および MaxPasswordAge (AWS の基本的なセキュリティのベストプラクティスの値: 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 (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) によって、ポリシーで「Resource」:「*」に対して「Action」:「*」が「Effect」:「Allow」にならないよう制限し、アクセス許可や認可に最小特権と職務分離の原則を組み込むことができます。タスク完了のために必要以上の権限をユーザーに付与することは、最小特権と職務の分離の原則に反する可能性があります。 | |
| 1.17 | AWS サポートでインシデントを管理するためのサポートロールが作成されていることを確認します。 | AWS Identity and Access Management (IAM) は、IAM ポリシーが適切なユーザー、ロール、またはグループに割り当てられるようにすることで、アクセス許可と認可を管理するのに役立ちます。これらのポリシーを制限することは、最小特権と職務分離の原則も組み込まれています。このルールでは、AWS Support でのインシデント管理のために、policyARN を arn:aws:iam::aws:policy/AWSSupportAccess に設定することが要求されます。 | |
| 1.19 | AWS IAM に保存されている期限切れの SSL/TLS 証明書が、すべて削除されていることを確認します。 | iam-expired-certificates (Process Check) | 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 (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」のドキュメントを参照してください。 |
| 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.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 データを含めることで、お客様の AWS アカウント 内の API コールのアクティビティの詳細を提供します。 | |
| 3.6 | S3 バケットアクセスログ記録が CloudTrail S3 バケットで有効になっていることを確認します | Amazon Simple Storage Service (Amazon S3) サーバーアクセスのログ記録によって、ネットワークをモニタリングし、潜在的なサイバーセキュリティイベントに対応することができます。Amazon S3 バケットに対して行われたリクエストの詳細な記録をキャプチャすることで、イベントをモニタリングします。各アクセスのログレコードから、1 つのアクセスリクエストについての詳細情報を取得できます。詳細情報には、リクエスタ、バケット名、リクエスト時刻、リクエストアクション、レスポンスのステータス、エラーコード (該当する場合) などの情報が含まれます。 | |
| 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.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.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 Cloud (Amazon EC2) セキュリティグループの共通ポートに制限をかけることにより、AWS クラウド上のリソースへのアクセスを管理します。ポートへのアクセスを信頼できるソースに制限しなければ、システムの可用性、完全性、機密性に対する脅威を招く可能性があります。このルールでは、blockedPort1～blockedPort5 パラメータ (CIS標準値: 3389) を任意に設定することができます。実際の値には、組織のポリシーを反映する必要があります。 |
テンプレート
テンプレートは、GitHub の「Operational Best Practices for CIS AWS Foundations Benchmark v1.4 Level 1
