CIS 運用のベストプラクティス AWS 基礎ベンチマーク v1.4 レベル 1 - AWS Config

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 ルールに関連付けることができます。これらのマッピングに関する詳細およびガイダンスについては、以下の表を参照してください。

プロセスチェックの詳細については、「コンフォーマンスパック内の AWS Config プロセスチェック」を参照してください。

AWS リージョン:中東 (バーレーン) を除く、サポートされているすべての AWS リージョン

コントロール 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 マネジメントコンソールの [My Account] (マイアカウント) セクションで、[Security] (セキュリティ) セクションに正しい情報が指定されていることを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください
1.3 セキュリティの質問は、AWS アカウントに登録されていることを確認します account-security-questions-configured (Process Check) AWS のカスタマーサービスにサポートを依頼する個人を認証するために使用される、セキュリティの質問が設定されていることを確認します。AWS マネジメントコンソールの [My Account] (マイアカウント) セクションで、3 つのセキュリティチャレンジの質問が設定されていることを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください
1.4 ルートアカウントキーが存在しないことを確認します

iam-root-access-key-check

ルートユーザーに AWS Identity and Access Management (IAM) ロールにアタッチされたアクセスキーが割り当てられていないことを確認することで、システムとアセットへのアクセスをコントロールできます。root アクセスキーが削除されていることを確認します。代わりに、ロールベースの AWS アカウントを作成して使用し、最小限の機能の原則を組み込みます。
1.5 「ルート」ユーザーアカウントで MFA を有効にします

root-account-mfa-enabled

ルートユーザーに対して 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 文字以上の長さが必要になります。

iam-password-policy

ID と認証情報は、組織の IAM パスワードポリシーに基づいて発行、管理、検証されます。これらの ID と認証情報は、NIST SP 800-63 および AWS の基本的なセキュリティのベストプラクティス標準で規定されているパスワード強度の要件を満たしています。このルールでは、必要に応じて RequireUppercaseCharacters (AWS の基本的なセキュリティのベストプラクティスの値: true)、RequireLowercaseCharacters (AWS Foundational セキュリティのベストプラクティスの値: true)、RequireSymbols (AWS の基本的なセキュリティのベストプラクティスの値: true)、RequireNumbers (AWS の基本的なセキュリティのベストプラクティスの値: true)、MinimumPasswordLength (AWS の基本的なセキュリティのベストプラクティスの値: 14)、PasswordReusePrevention (AWS の基本的なセキュリティのベストプラクティスの値: 24)、および MaxPasswordAge (AWS の基本的なセキュリティのベストプラクティスの値: 90) を、IAM パスワードポリシーに設定します。実際の値には、組織のポリシーを反映する必要があります。
1.9 IAM パスワードポリシーはパスワードの再使用を禁止しています

iam-password-policy

ID と認証情報は、組織の IAM パスワードポリシーに基づいて発行、管理、検証されます。これらの ID と認証情報は、NIST SP 800-63 および AWS の基本的なセキュリティのベストプラクティス標準で規定されているパスワード強度の要件を満たしています。このルールでは、必要に応じて RequireUppercaseCharacters (AWS の基本的なセキュリティのベストプラクティスの値: true)、RequireLowercaseCharacters (AWS Foundational セキュリティのベストプラクティスの値: true)、RequireSymbols (AWS の基本的なセキュリティのベストプラクティスの値: true)、RequireNumbers (AWS の基本的なセキュリティのベストプラクティスの値: true)、MinimumPasswordLength (AWS の基本的なセキュリティのベストプラクティスの値: 14)、PasswordReusePrevention (AWS の基本的なセキュリティのベストプラクティスの値: 24)、および MaxPasswordAge (AWS の基本的なセキュリティのベストプラクティスの値: 90) を、IAM パスワードポリシーに設定します。実際の値には、組織のポリシーを反映する必要があります。
1.10 コンソールパスワードを持っているすべての IAM ユーザーについて多要素認証 (MFA) が有効にします。

mfa-enabled-for-iam-console-access

コンソールのパスワードを所有するすべての AWS Identity and Access Management (IAM) ユーザーに対して MFA が有効になっていることを確認することで、AWS クラウド内のリソースへのアクセスを管理します。MFA は、ユーザー名とパスワードに更なる保護手段を追加します。IAM ユーザーに MFA を要求することで、アカウントが侵害されるインシデントを減らし、権限のないユーザーが機密データにアクセスできないようにすることができます。
1.11 コンソールパスワードを持つすべての IAM ユーザーの初期ユーザー集合アップ中にアクセスキーを集合アップしないでください iam-user-console-and-api-access-at-creation (Process Check) コンソールのパスワードを持つすべての IAM ユーザーの初期設定時に、アクセスキーが設定されないようにします。コンソールにアクセスできるすべての IAM ユーザーについて、ユーザーの「作成時刻」とアクセスキーの「作成日」を比較します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください
1.12 45 日間以上使用されていない認証情報は無効にします。

iam-user-unused-credentials-check

AWS Identity and Access Management (IAM) では、指定した期間に使用されていない IAM パスワードとアクセスキーをチェックすることで、アクセスの許可と認可を行うことができます。これらの未使用の認証情報が特定された場合は、最小特権の原則に反する可能性があるため、その認証情報を無効にするか、削除する必要があります。このルールでは、maxCredentialUsageAge の値を設定する必要があります (CIS スタンダード値デフォルト: 45)。実際の値には、組織のポリシーを反映する必要があります。
1.13 1 人の IAM ユーザーが使用できるアクティブなアクセスキーが 1 つのみであることを確認します。 iam-user-single-access-key (Process Check) 1 人の IAM ユーザーが使用できるアクティブなアクセスキーが 1 つのみであることを確認します。すべての IAM ユーザーについて、[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 日ごとに更新します。

access-keys-rotated

組織のポリシーに従って IAM アクセスキーがローテーションされるようにすることで、認可されたデバイス、ユーザー、プロセスについての認証情報が監査されます。アクセスキーを定期的に変更することが、セキュリティのベストプラクティスです。これにより、アクセスキーがアクティブになっている期間が短縮され、キーが侵害された場合のビジネスへの影響を軽減できます。このルールでは、アクセスキーの更新の値が必要です (Config デフォルト: 90)。実際の値には、組織のポリシーを反映する必要があります。
1.15 IAM ユーザーがグループを通してのみアクセス権を受け取るようにします。

iam-user-no-policies-check

このルールにより、AWS Identity and Access Management (IAM) ポリシーがグループまたはロールのみにアタッチされ、システムとアセットへのアクセスがコントロールされるようになります。グループレベルまたはロールレベルで特権を割り当てると、ID が過剰な特権を受け取ったり保持したりする機会を減らすことができます。
1.15 IAM ユーザーがグループを通してのみアクセス権を受け取るようにします。

iam-no-inline-policy-check

AWS Identity and Access Management (IAM) ユーザー、IAM ロール、または IAM グループに、システムやアセットへのアクセスを管理するインラインポリシーがないことを確認します。AWS では、インラインポリシーではなく管理ポリシーポリシーを使用することを推奨しています。管理ポリシーにより、再利用性、バージョニング、ロールバック、権限管理の委任が可能になります。
1.15 IAM ユーザーがグループを通してのみアクセス権を受け取るようにします。

iam-user-group-membership-check

AWS Identity and Access Management (IAM) は、IAM ユーザーが少なくとも 1 つのグループのメンバーであることを確認することで、アクセス許可と認可をコントロールします。タスク完了のために必要以上の権限をユーザーに許可することは、最小特権と職務の分離の原則に反する可能性があります。
1.16 完全な「*:*」管理権限を許可する IAM ポリシーは作成されません。

iam-policy-no-statements-with-admin-access

AWS Identity and Access Management (IAM) によって、ポリシーで「Resource」: 「*」に対して「Action」: 「*」が「Effect」: 「Allow」にならないように制限し、アクセス許可や認可に最小特権と職務分離の原則を組み込むことができます。タスク完了のために必要以上の権限をユーザーに付与することは、最小特権と職務の分離の原則に反する可能性があります。
1.17 AWS Support で、インシデントを管理するためのサポートロールが作成されていることを確認します。

iam-policy-in-use

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 が有効であることを確認する。

s3-bucket-versioning-enabled

Amazon Simple Storage Service (Amazon S3) バケットのバージョニングは、同じ Amazon S3 バケットでオブジェクトの複数のバリアントを保持するのに役立ちます。S3バケットに多要素認証 (MFA) 削除を追加すると、バケットのバージョン状態を変更したり、オブジェクトのバージョンを削除したりするために、追加の認証要素が必要になります。MFA 削除により、万が一、セキュリティ認証が漏洩したり、不正なアクセスが行われた場合でも、セキュリティのレイヤーを追加することができます。
2.1.5 S3バケットに「パブリックアクセスをブロックする (バケット設定) 」が設定されていることを確認する

s3-account-level-public-access-blocks-periodic

Amazon Simple Storage Service (Amazon S3) バケットにパブリックにアクセスできないようにすることで、AWS クラウドのリソースへのアクセスを管理します。このルールは、パブリックアクセスを防止することで、権限のないリモートユーザーから機密データを保護するのに役立ちます。このルールでは、ignorePublicAcls (Config デフォルト: True)、blockPublicPolicy (Config デフォルト: True)、blockPublicAcls (Config デフォルト: True)、および restrictPublicBuckets (Config デフォルト: True) の各パラメータを必要に応じて設定できます。実際の値には、組織のポリシーを反映する必要があります。
2.1.5 S3バケットに「パブリックアクセスをブロックする (バケット設定) 」が設定されていることを確認する

s3-bucket-level-public-access-prohibited

Amazon Simple Storage Service (Amazon S3) バケットにパブリックにアクセスできないようにすることで、AWS クラウドのリソースへのアクセスを管理します。このルールでは、バケットレベルでのパブリックアクセスを防止することで、権限のないリモートユーザーから機密データを保護します。
2.2.1 EBSボリュームの暗号化が有効であることを確認します

encrypted-volumes

機密データが含まれている可能性があるため、保管中のデータを保護するために Amazon Elastic Block Store (Amazon EBS) ボリュームで暗号化が有効になっていることを確認します。
2.2.1 EBSボリュームの暗号化が有効であることを確認します

ec2-ebs-encryption-by-default

保管中のデータを保護するため、Amazon Elastic Block Store (Amazon EBS) ボリュームで暗号化が有効になっていることを確認します。これらのボリュームには機密データが含まれている可能性があるため、保管時の暗号化を有効にしてデータを保護します。
2.3.1 RDSインスタンスで暗号化が有効であることを確認します

rds-snapshot-encrypted

Amazon Relational Database Service (Amazon RDS) スナップショットで、暗号化が有効になっていることを確認します。機密データが含まれている可能性があるため、保管時の暗号化を有効にしてデータを保護します。
2.3.1 RDSインスタンスで暗号化が有効であることを確認します

rds-storage-encrypted

保管中のデータを保護するため、Amazon Relational Database Service (Amazon RDS) インスタンスで暗号化が有効になっていることを確認します。Amazon RDS インスタンスには機密データが含まれている可能性があるため、保管時の暗号化を有効にしてデータを保護します。
3.1 CloudTrail はすべてのリージョンで有効になっていることを確認します

multi-region-cloudtrail-enabled

AWS CloudTrail は、AWS マネジメントコンソールのアクションと API コールを記録します。AWS を呼び出したユーザーとアカウント、呼び出し元 IP アドレス、および呼び出し日時を特定できます。MULTI_REGION_CLOUD_TRAIL_ENABLED が有効になっている場合、CloudTrail はすべての AWS リージョンから S3 バケットにログファイルを配信します。さらに、AWS が新しいリージョンを作成すると、CloudTrail はそのリージョンに同じ証跡を作成します。その結果、アクションを実行しなくても、新しいリージョンの API アクティビティを含むログファイルを受け取ることができるようになります。
3.3 CloudTrail ログの保存に使用されるS3 バケットが一般公開されていないことを確認します

s3-bucket-public-read-prohibited

権限のあるユーザー、プロセス、デバイスに Amazon Simple Storage Service (Amazon S3) バケットへのアクセスのみを許可することで、AWS クラウド内のリソースへのアクセスを管理します。アクセスの管理は、データの分類と一致している必要があります。
3.3 CloudTrail ログの保存に使用されるS3 バケットが一般公開されていないことを確認します

s3-bucket-public-write-prohibited

権限のあるユーザー、プロセス、デバイスに Amazon Simple Storage Service (Amazon S3) バケットへのアクセスのみを許可することで、AWS クラウド内のリソースへのアクセスを管理します。アクセスの管理は、データの分類と一致している必要があります。
3.3 CloudTrail ログの保存に使用されるS3 バケットが一般公開されていないことを確認します

s3-bucket-level-public-access-prohibited

Amazon Simple Storage Service (Amazon S3) バケットにパブリックにアクセスできないようにすることで、AWS クラウドのリソースへのアクセスを管理します。このルールでは、バケットレベルでのパブリックアクセスを防止することで、権限のないリモートユーザーから機密データを保護します。
3.4 CloudTrailトレイルが CloudWatchLogs と統合されていることを確認します。

cloud-trail-cloud-watch-logs-enabled

Amazon CloudWatch を使用して、イベントのアクティビティログを一元的に収集および管理します。AWS CloudTrail データを含めることで、お客様の AWS アカウント内の API コールのアクティビティの詳細を提供します。
3.6 S3 バケットアクセスログ記録が CloudTrail S3 バケットで有効になっていることを確認します

s3-bucket-logging-enabled

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 からリモートサーバー管理ポートへの侵入を許可していないことを確認します。

restricted-ssh

Amazon Elastic Compute Cloud (Amazon EC2) のセキュリティグループは、AWS リソースへの出入口ネットワークトラフィックをステートフルにフィルタリングすることで、ネットワークアクセスの管理を支援することができます。リソースで 0.0.0.0/0 からポート 22 への入力 (またはリモート) トラフィックを許可しないようにすることで、リモートアクセスを制限できます。
5.2 ネットワーク ACL が 0.0.0.0/0 からリモートサーバー管理ポートへの侵入を許可していないことを確認します。

restricted-common-ports

Amazon Elastic Compute Cloud (Amazon EC2) セキュリティグループの共通ポートに制限をかけることで、AWS クラウド上のリソースへのアクセスを管理します。ポートへのアクセスを信頼できるソースに制限しなければ、システムの可用性、完全性、機密性に対する脅威を招く可能性があります。このルールでは、blockedPort1〜blockedPort5 パラメータ (CIS標準値: 3389) を任意に設定することができます。実際の値には、組織のポリシーを反映する必要があります。

テンプレート

テンプレートは、GitHub の「Operational Best Practices for CIS AWS Foundations Benchmark v1.4 Level 1」で入手できます。