AWS の基本的なセキュリティのベストプラクティスコントロール - AWS Security Hub
[ACM.1] インポートされた ACM 証明書は、指定された期間後に更新する必要があります[APIGateway.1] API Gateway REST および WebSocket API ロギングを有効にする必要があります[Apigateway.2] API Gateway REST API ステージは、バックエンド認証に SSL 証明書を使用するように設定する必要があります[Apigateway.3] API Gateway REST API ステージには、AWS X-Rayイネーブルトレース[Apigateway.4] API Gateway は、AWS WAFウェブ ACL[Apigateway.5] API Gateway REST API キャッシュデータは保存時に暗号化する必要があります[Autoscaling.1] ロードバランサーに関連付けられた Auto Scaling グループは、ロードバランサーのヘルスチェックを使用します[CloudFront.1] CloudFront ディストリビューションにはデフォルトのルートオブジェクトが設定されている必要があります[CloudFront.2] CloudFront ディストリビューションでは、オリジンアクセスアイデンティティを有効にする必要があります[CloudFront.3] CloudFront ディストリビューションでは、転送中に暗号化が必要になるはずです[CloudFront.4] CloudFront ディストリビューションにはオリジンフェールオーバーが設定されている必要があります[CloudFront.5] CloudFront ディストリビューションでロギングを有効にする必要があります[CloudFront.6] CloudFront ディストリビューションには以下が必要ですAWS WAFenabled[CloudTrail.1] CloudTrail を有効にし、少なくとも 1 つのマルチリージョンの証跡で設定する必要があります。[CloudTrail.2] CloudTrail では、保管時の暗号化が有効になっている必要があります。[CloudTrail.4] CloudTrail ログファイルの検証が有効になっているかどうかを確認します[CloudTrail.5] CloudTrail トレイルが Amazon CloudWatch Logs と統合されていることを確認する[CodeBuild.1] CodeBuild GitHub または Bitbucket のソースリポジトリの URL は、OAuth を使用する必要があります[CodeBuild.2] CodeBuild プロジェクト環境変数にクリアテキストの認証情報を含めることはできません[Config.1] AWS Config を有効にする必要があります[DMS.1]AWS Database Migration Serviceレプリケーションインスタンスはパブリックであってはならない[DynamoDB.1] DynamoDB テーブルは需要に応じて自動的に容量をスケーリングする必要があります[DynamoDB.2] DynamoDB テーブルでは、ポイントインタイムリカバリを有効にする必要があります[DynamoDB.3] DynamoDB Accelerator (DAX) クラスターは保管時に暗号化する必要があります[EC2.1] Amazon EBS スナップショットは、パブリックであってはなりません。これは誰でも復元できるかどうかによって判断されます[EC2.2] VPC のデフォルトのセキュリティグループでは、インバウンドトラフィックとアウトバウンドトラフィックが禁止されます [EC2.3] アタッチされた EBS ボリュームは保管時に暗号化する必要があります[EC2.4] 停止した EC2 インスタンスは、指定された期間後に削除する必要があります[EC2.6] すべての VPC で VPC フローロギングを有効にする必要があります [EC2.7] EBS のデフォルト暗号化を有効にする必要があります[EC2.8] EC2 インスタンスは IMDSv2 を使用する必要があります[EC2.9] EC2 インスタンスはパブリック IP アドレスを持つべきではありません[EC2.10] Amazon EC2 サービス用に作成された VPC エンドポイントを使用するようにAmazon EC2 を設定する必要があります。[EC2.15] EC2 サブネットはパブリック IP アドレスを自動的に割り当てるべきではありません[EC2.16] 未使用のネットワークアクセスコントロールリストを削除する必要があります[EC2.17] EC2 インスタンスは複数の ENI を使用すべきではない[EC2.18] セキュリティグループでは、許可されたポートに対して制限のない着信トラフィックのみを許可する必要があります[EC2.19] セキュリティグループは、リスクの高いポートへの無制限アクセスを許可すべきではない[ECS.1] Amazon ECS タスク定義には、安全なネットワークモードとユーザー定義が必要です[ECS.2] Amazon ECS サービスにはパブリック IP アドレスを自動的に割り当てるべきではありません[EFS.1] を使用して、保管中のファイルデータを暗号化するように設定する必要がありますAWS KMS[EFS.2] Amazon EFS ボリュームはバックアッププラン内にある必要があります[ElasticBeanStalk.1] Elastic Beanstalk 環境では、拡張ヘルスレポートを有効にする必要があります[ElasticBeanStalk.2] Elastic Beanstalk マネージドプラットフォームのアップデートを有効にする必要があります[ELB.3] Classic Load Balancer のリスナーは HTTPS または TLS ターミネーションで設定する必要があります[ELB.4] HTTP ヘッダーを削除するようにアプリケーションロードバランサーを設定する必要があります[ELB.5] アプリケーションおよびクラシックロードバランサーのロギングを有効にする必要があります[ELB.6] Application Load Balancer 削除に対する保護を有効にする必要があります[ELB.7] クラシックロードバランサは接続ドレインを有効にする必要があります[ELBv2.1] Application Load Balancer は、すべての HTTP リクエストを HTTPS にリダイレクトするように設定する必要があります[EMR.1] Amazon EMR クラスターマスターノードはパブリック IP アドレスを持つべきではありません[ES.1] Elasticsearch ドメインは保存時の暗号化を有効にする必要があります[ES.2] Elasticsearch ドメインは VPC 内に存在する必要があります[ES.3] Elasticsearch ドメインはノード間で送信されるデータを暗号化する必要があります[ES.4] CloudWatch Logs への Elasticsearch ドメインエラーログを有効にする必要があります[ES.5] Elasticsearch ドメインで監査ログが有効になっている必要があります[ES.6] Elasticsearch ドメインには少なくとも 3 つのデータノードが必要です[ES.7] Elasticsearch ドメインは、少なくとも 3 つの専用マスターノードで構成する必要があります[ES.8] Elasticsearch ドメインへの接続は TLS 1.2 を使用して暗号化する必要があります[GuardDuty.1] GuardDuty を有効にする必要があります[IAM.1] IAM ポリシーでは、完全な「*」管理権限を許可しないでください[IAM.2] IAM ユーザーには IAM ポリシーをアタッチしないでください[IAM.3] IAM ユーザーのアクセスキーは 90 日ごとに更新する必要があります[IAM.4] IAM ルートユーザーアクセスキーが存在してはいけません[IAM.5] コンソールパスワードを持つすべての IAM ユーザーに対して MFA を有効にする必要があります[IAM.6] ルートユーザーに対してハードウェア MFA を有効にする必要があります[IAM.7] IAM ユーザーのパスワードポリシーには強力な設定が必要です[IAM.8] 未使用の IAM ユーザー認証情報は削除する必要があります[IAM.21] 作成する IAM カスタマー管理ポリシーは、サービスのワイルドカードアクションを許可しないでください。[KMS.1] IAM カスタマー管理ポリシーでは、すべての KMS キーで復号化アクションを許可しないでください。[KMS.2] IAM プリンシパルは、すべての KMS キーで復号化アクションを許可する IAM インラインポリシーを持つべきではありません。[KMS.3]AWS KMSキーを意図せずに削除すべきではない[Lambda.1] Lambda a関数ポリシーではパブリックアクセスを禁止する必要があります[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります[Lambda.4] Lambda 関数にはデッドレターキューが設定されている必要があります (リタイア)[RDS.1] RDS スナップショットはプライベートである必要があります[RDS.2] RDS DB インスタンスは、パブリックアクセスを禁止する必要があります。これは PubliclyAccessible 設定によって判断されます。[RDS.3] RDS DB インスタンスでは、保管時の暗号化が有効になっている必要があります。[RDS.4] RDS クラスタースナップショットとデータベーススナップショットは保存時に暗号化する必要があります[RDS.5] RDS DB インスタンスは、複数のアベイラビリティーゾーンで構成する必要があります[RDS.6] RDS DB インスタンスとクラスターの拡張モニタリングを構成する必要があります[RDS.7] RDS クラスターで削除保護を有効にする必要があります[RDS.8] RDS DB インスタンスでは、削除保護が有効になっている必要があります。[RDS.9] データベースロギングを有効にする必要があります[RDS.10] IAM 認証は RDS インスタンス用に設定する必要があります[RDS.12] IAM 認証は RDS クラスター用に設定する必要があります[RDS.13] RDS 自動マイナーバージョンアップグレードを有効にする必要があります[RDS.14] Amazon Aurora クラスターはバックトラッキングを有効にする必要があります[RDS.15] RDS DB クラスターを複数のアベイラビリティーゾーン用に設定する必要があります[RDS.16] タグをスナップショットにコピーするように RDS DB クラスターを構成する必要があります[RDS.17] RDS DB インスタンスは、タグをスナップショットにコピーするように設定する必要があります[RDS.18] RDS インスタンスは VPC にデプロイする必要があります[RDS.19] 重要なクラスターイベントに対して RDS イベント通知サブスクリプションを構成する必要があります[RDS.20] 重要なデータベースインスタンスイベントに対して RDS イベント通知サブスクリプションを構成する必要があります[RDS.21] 重要なデータベースパラメータグループイベントに対して RDS イベント通知サブスクリプションを構成する必要があります[RDS.22] 重要なデータベースセキュリティグループイベントに対して RDS イベント通知サブスクリプションを構成する必要があります[RDS.23] RDS データベースとクラスターはデータベースエンジンのデフォルトポートを使用すべきではない[Redshift.1] Amazon Redshift クラスターはパブリックアクセスを禁止する必要があります[Redshift.2] Amazon Redshift クラスターへの接続は転送中に暗号化する必要があります[Redshift.3] Amazon Redshift クラスターで自動スナップショットが有効になっている必要があります[Redshift.4] Amazon Redshift クラスターで監査ログが有効になっている必要があります[Redshift.6] Amazon Redshift でメジャーバージョンへの自動アップグレードが有効になっている必要があります[Redshift.7] Amazon Redshift クラスターは拡張 VPC ルーティングを使用する必要があります[S3.1] S3 ブロックパブリックアクセス設定を有効にする必要があります[S3.2] S3 バケットではパブリック読み取りアクセスを禁止する必要があります[S3.3] S3 バケットはパブリック書き込みアクセスを禁止する必要があります[S3.4] S3 バケットでは、サーバー側の暗号化を有効にする必要があります[S3.5] S3 バケットは、Secure Socket Layer を使用するためのリクエストが必要です[S3.6] 他のユーザーに付与された Amazon S3 のアクセス許可AWSバケットポリシーのアカウントは制限する必要があります[S3.8] バケットレベルで S3 ブロックパブリックアクセス設定を有効にする必要があります[SageMaker.1] SageMaker ノートブックインスタンスは、インターネットに直接アクセスしてはいけません[SecretsManager.1] Secrets Manager のシークレットは、自動ローテーションを有効にする必要があります[SecretsManager.2] 自動ローテーションで構成されたSecrets Manager のシークレットは正常にローテーションする必要があります[SecretsManager.3] 未使用のSecrets Manager のシークレットを削除する[SecretsManager.4] Secrets Manager のシークレットは、指定された日数内にローテーションする必要があります[SNS.1] SNS トピックは、保存時に暗号化する必要があります。AWS KMS[SQS.1] Amazon SQS キューは保管時に暗号化する必要があります[SSM.1] EC2 インスタンスは、によって管理される必要がありますAWS Systems Manager[SSM.2] Systems Manager によって管理されるすべての EC2 インスタンスは、パッチ適用要件に準拠している必要があります。[SSM.3] Systems Manager によって管理されるインスタンスは、アソシエーションコンプライアンスステータスがCOMPLIANT[WAF.1]AWS WAFクラシックグローバル Web ACL ロギングをイネーブルにする必要があります

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

AWS の基本的なセキュリティのベストプラクティスコントロール

AWS の基本的なセキュリティのベストプラクティス標準には、次のコントロールが含まれています。各コントロールについて、情報には次の情報が含まれます。

  • コントロールが適用されるカテゴリ。カテゴリの説明については、「」を参照してください。コントロールのカテゴリ

  • 重要度

  • 該当するリソース

  • 必要な AWS Config ルール、および AWS Security Hub によって設定される特定のパラメータ値

  • 修復ステップ

コントロール番号のギャップは、まだ解放されていないコントロールを示しています。

[ACM.1] インポートされた ACM 証明書は、指定された期間後に更新する必要があります

カテゴリ: 保護-転送中のデータの暗号化

緊急度: ミディアム

リソースタイプ: AWS::ACM::Certificate

AWS Config ルール: acm-certificate-expiration-check

パラメータ:

  • daysToExpiration: 30

このコントロールは、アカウントの ACM 証明書が 30 日以内に有効期限切れとしてマークされているかどうかを確認します。インポートされた証明書と AWS Certificate Manager によって提供される証明書の両方がチェックされます。

ACM は DNS 検証を使用する証明書を自動的に更新できます。E メール検証を使用する証明書の場合は、ドメイン検証 E メールに応答する必要があります。また、ACM では、ユーザーがインポートする証明書は自動的に更新されません。インポートした証明書を手動で更新する必要があります。

ACM 証明書のマネージド型更新の詳細については、「」を参照してください。ACM 証明書のマネージド更新AWS Certificate Managerユーザーガイド

注記

このコントロールは、次のリージョンではサポートされていません。

  • アフリカ (ケープタウン)

  • 中国 (北京)

  • 中国 (寧夏)

  • ヨーロッパ (ミラノ)

Remediation

ACM は、Amazon 発行の SSL/TLS 証明書の更新の管理方法について説明します。つまり、ACM は証明書を自動的に更新するか(DNS 検証を使用する場合)、証明書の有効期限が近づくと電子メール通知を送信します。これらのサービスは、パブリック ACM 証明書とプライベート ACM 証明書の両方に対して提供されます。

電子メールで検証されたドメインの場合

証明書が有効期限の 45 日前になると、ACM はドメイン所有者にドメイン所有者に電子メールを送信します。ドメインを検証して更新を完了するには、電子メール通知に応答する必要があります。

詳細については、「」を参照してください。電子メールで検証されたドメインの更新AWS Certificate Managerユーザーガイド

DNS によって検証されたドメインの場合

ACM は DNS 検証を使用する証明書を自動的に更新します。有効期限の 60 日前に、ACM は証明書を更新できることを確認します。

ドメイン名を検証できない場合、ACM は手動検証が必要であるという通知を送信します。これらの通知は、有効期限の 45 日、30 日、7 日、1 日前に送信します。

詳細については、「」を参照してください。DNS によって検証されたドメインの更新AWS Certificate Managerユーザーガイド

[APIGateway.1] API Gateway REST および WebSocket API ロギングを有効にする必要があります

カテゴリ: 識別-ログ記録

緊急度: ミディアム

リソースタイプ: AWS::ApiGateway::Stage,AWS::ApiGatewayV2::Stage

AWS Config ルール: api-gw-execution-logging-enabled

パラメータ: なし

このコントロールは、Amazon API Gateway REST または WebSocket API のすべてのステージでログが有効になっているかどうかをチェックします。ステージのすべてのメソッドでロギングが有効になっていないか、次の場合にコントロールは失敗します。loggingLevelどちらでもないERRORnorINFO

API Gateway REST または WebSocket API ステージでは、関連するログを有効にする必要があります。API Gateway REST および WebSocket API 実行ログは、API Gateway REST および WebSocket API ステージに対して行われたリクエストの詳細な記録を提供します。ステージには、API 統合バックエンドレスポンス、Lambda オーソライザーレスポンス、requestIdforAWS統合エンドポイント。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アフリカ (ケープタウン)

  • ヨーロッパ (ミラノ)

Remediation

REST および WebSocket API オペレーションのロギングを有効にするには、を参照してください。API Gateway コンソールを使用した CloudWatch による API のログの設定API Gateway 開発者ガイド

[Apigateway.2] API Gateway REST API ステージは、バックエンド認証に SSL 証明書を使用するように設定する必要があります

カテゴリ: [保護] > [データ保護

緊急度: ミディアム

リソースタイプ: AWS::ApiGateway::Stage

AWS Config ルール: api_gw_ssl_enabled

パラメータ: なし

このコントロールは、Amazon API Gateway REST API ステージに SSL 証明書が設定されているかどうかをチェックします。バックエンドシステムは、これらの証明書を使用して、受信リクエストが API Gateway からのものであることを認証します。

API Gateway REST API ステージは、API Gateway からのリクエストをバックエンドシステムが認証できるようにするには、SSL 証明書で構成する必要があります。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アジアパシフィック (大阪)

  • 中国 (北京)

  • 中国 (寧夏)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

API Gateway REST API SSL 証明書を生成して設定する方法の詳細については、「」バックエンド認証用 SSL 証明書の生成と設定API Gateway 開発者ガイド

[Apigateway.3] API Gateway REST API ステージには、AWS X-Rayイネーブルトレース

カテゴリ: 検出-検出サービス

緊急度:

リソースタイプ: AWS::ApiGateway::Stage

AWS Config ルール: api-gw-xray-enabled

パラメータ: なし

このコントロールは、かどうかを確認します。AWS X-Rayアクティブなトレースは、Amazon API Gateway REST API ステージで有効になっています。

X-Ray アクティブトレースを使用すると、基盤となるインフラストラクチャのパフォーマンスの変化に対してより迅速に対応できます。パフォーマンスの変化により、API の可用性が低下する可能性があります。X-Ray アクティブトレースは、API Gateway REST API オペレーションと接続サービスを介して流れるユーザーリクエストのリアルタイムメトリックスを提供します。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アジアパシフィック (大阪)

  • 中国 (北京)

  • 中国 (寧夏)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

API Gateway REST API オペレーションの X-Ray アクティブトレースを有効にする方法の詳細については、を参照してください。のAmazon API Gateway のアクティブトレースサポートAWS X-RayAWS X-Rayデベロッパーガイド

[Apigateway.4] API Gateway は、AWS WAFウェブ ACL

カテゴリ: 保護-保護サービス

緊急度: ミディアム

リソースタイプ: AWS::ApiGateway::Stage

AWS Config ルール: api_gw_associated_with_waf

パラメータ: なし

このコントロールは、API Gateway ステージがAWS WAFWeb アクセスコントロールリスト (ACL)。このコントロールは、AWS WAFウェブ ACL は REST API Gateway ステージにアタッチされません。

AWS WAF は、ウェブアプリケーションと API を攻撃から保護するウェブアプリケーションファイアウォールです。これにより、お客様が定義するカスタマイズ可能なウェブセキュリティルールと条件に基づいて、ウェブリクエストを許可、ブロック、またはカウントする一連のルールです。API Gateway ステージがAWS WAFウェブ ACL は、悪意のある攻撃から保護するのに役立ちます。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アジアパシフィック (大阪)

  • 中国 (北京)

  • 中国 (寧夏)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

API Gateway コンソールを使用してAWS WAF既存の API Gateway API ステージを持つリージョンウェブ ACL については、「」を参照してください。を使用するAWS WAFAPI を保護するAPI Gateway 開発者ガイド

[Apigateway.5] API Gateway REST API キャッシュデータは保存時に暗号化する必要があります

カテゴリ: 保護-データ保護-保管中のデータの暗号化

緊急度: ミディアム

リソースタイプ: AWS::ApiGateway::Stage

AWS Config ルール:api-gw-cache-encrypted (Security Hub が開発したカスタムルール)

パラメータ: なし

このコントロールは、キャッシュが有効になっている API Gateway REST API ステージ内のすべてのメソッドが暗号化されているかどうかをチェックします。API Gateway REST API ステージのいずれかのメソッドがキャッシュするように設定されており、キャッシュが暗号化されていない場合、コントロールは失敗します。

保管中のデータを暗号化すると、ディスクに保存されているデータが、認証されていないユーザーによってアクセスされるリスクが軽減されます。AWS。これにより、権限のないユーザーによるデータへのアクセスを制限するために、別のアクセス制御が追加されています。たとえば、データを読み取る前にデータを復号化するには、API 権限が必要です。

API Gateway REST API キャッシュは、セキュリティ層を追加するために、保存時に暗号化する必要があります。

Remediation

このコントロールを修正するには、キャッシュデータを暗号化するようにステージを構成します。

特定のステージの API キャッシュを設定するには

  1. API Gateway (https://console.aws.amazon.com/apigateway) コンソールを開きます。

  2. API を選択します。

  3. [ステージ] を選択します。

  4. ステージAPI のリストで、キャッシュを追加するステージを選択します。

  5. [設定] を選択します。

  6. [API キャッシュを有効化] を選択します。

  7. 目的の設定を更新し、キャッシュデータの暗号化

  8. [変更を保存] を選択します。

[Autoscaling.1] ロードバランサーに関連付けられた Auto Scaling グループは、ロードバランサーのヘルスチェックを使用します

カテゴリ: 識別-インベントリ

緊急度:

リソースタイプ: AWS::AutoScaling::AutoScalingGroup

AWS Config ルール: autoscaling-group-elb-healthcheck-required

パラメータ: なし

コントロールは、ロードバランサーに関連付けられた Auto Scaling グループが、Elastic Load Balancing のヘルスチェックを使用しているかどうかを確認します。

これにより、ロードバランサーによって提供される追加のテストに基づいて、グループはインスタンスのヘルスを判断できるようになります。Elastic Load Balancing ヘルスチェックを使用すると、EC2 Auto Scaling グループを使用するアプリケーションの可用性をサポートできます。

Remediation

この問題を解決するには、Elastic Load Balancing ヘルスチェックを使用するように Auto Scaling グループを更新します。

Elastic Load Balancing ヘルスチェックを有効にするには

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

  2. ナビゲーションペインの [] で、[] をクリックします。Auto Scalingで、Auto Scaling グループ

  3. グループのチェックボックスを選択します。

  4. [編集] を選択します。

  5. []ヘルスチェック、に対してヘルスチェックタイプで、ELB

  6. [Health Check Grace Period (ヘルスチェックの猶予期間)] で、300 を入力します。

  7. ページの最下部にある [Update] を選択します。

Auto Scaling グループでのロードバランサーの使用の詳細については、「」を参照してくださいAWS Auto Scalingユーザーガイド

[CloudFront.1] CloudFront ディストリビューションにはデフォルトのルートオブジェクトが設定されている必要があります

カテゴリ: 保護-セキュアなアクセス管理 > パブリックにアクセスできないリソース

緊急度: 非常事態

リソースタイプ: AWS::CloudFront::Distribution

AWS Config ルール: cloudfront-default-root-object-configured

パラメータ: なし

このコントロールは、Amazon CloudFront ディストリビューションがデフォルトのルートオブジェクトである特定のオブジェクトを返すように設定されているかどうかをチェックします。CloudFront ディストリビューションにデフォルトのルートオブジェクトが設定されていない場合、コントロールは失敗します。

ユーザーは、ディストリビューション内のオブジェクトではなく、ディストリビューションのルート URL を要求することがあります。この場合、デフォルトのルートオブジェクトを指定すると、ウェブディストリビューションのコンテンツが公開されなくなります。

注記

このコントロールは、米国東部 (バージニア北部) でのみサポートされています。次のリージョンではサポートされていません。

  • 米国東部 (オハイオ)

  • 米国西部 (北カリフォルニア)

  • 米国西部 (オレゴン)

  • アフリカ (ケープタウン)

  • アジアパシフィック (香港)

  • アジアパシフィック (ムンバイ)

  • アジアパシフィック (大阪)

  • アジアパシフィック (ソウル)

  • アジアパシフィック (シンガポール)

  • アジアパシフィック (シドニー)

  • アジアパシフィック (東京)

  • カナダ (中部)

  • 中国 (北京)

  • 中国 (寧夏)

  • 欧州 (フランクフルト)

  • 欧州 (アイルランド)

  • 欧州 (ロンドン)

  • ヨーロッパ (ミラノ)

  • 欧州 (パリ)

  • 欧州 (ストックホルム)

  • 中東 (バーレーン)

  • 南米 (サンパウロ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

ディストリビューションのデフォルトルートオブジェクトを指定する方法の詳細については、「」を参照してください。デフォルトルートオブジェクトの指定方法Amazon CloudFront 開発者ガイド

[CloudFront.2] CloudFront ディストリビューションでは、オリジンアクセスアイデンティティを有効にする必要があります

カテゴリ: 保護-セキュアなアクセス管理-リソースポリシーの設定

緊急度: ミディアム

リソースタイプ: AWS::CloudFront::Distribution

AWS Config ルール: cloudfront-origin-access-identity-enabled

パラメータ: なし

このコントロールは、Amazon S3 オリジンタイプを持つ Amazon CloudFront ディストリビューションにオリジンアクセスアイデンティティ (OAI) が設定されているかどうかをチェックします。OAI が設定されていない場合、コントロールは失敗します。

CloudFront OAI は、ユーザーが S3 バケットコンテンツに直接アクセスできないようにします。ユーザーが S3 バケットに直接アクセスすると、CloudFront ディストリビューションと、基盤となる S3 バケットコンテンツに適用されるすべてのアクセス権限を効果的にバイパスします。

注記

このコントロールは、米国東部 (バージニア北部) でのみサポートされています。次のリージョンではサポートされていません。

  • 米国東部 (オハイオ)

  • 米国西部 (北カリフォルニア)

  • 米国西部 (オレゴン)

  • アフリカ (ケープタウン)

  • アジアパシフィック (香港)

  • アジアパシフィック (ムンバイ)

  • アジアパシフィック (大阪)

  • アジアパシフィック (ソウル)

  • アジアパシフィック (シンガポール)

  • アジアパシフィック (シドニー)

  • アジアパシフィック (東京)

  • カナダ (中部)

  • 中国 (北京)

  • 中国 (寧夏)

  • 欧州 (フランクフルト)

  • 欧州 (アイルランド)

  • 欧州 (ロンドン)

  • ヨーロッパ (ミラノ)

  • 欧州 (パリ)

  • 欧州 (ストックホルム)

  • 中東 (バーレーン)

  • 南米 (サンパウロ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

詳細な修復手順については、「」を参照してください。CloudFront OAI を作成してディストリビューションに追加するAmazon CloudFront 開発者ガイド

[CloudFront.3] CloudFront ディストリビューションでは、転送中に暗号化が必要になるはずです

カテゴリ: 保護-転送中のデータの暗号化

緊急度: ミディアム

リソースタイプ: AWS::CloudFront::Distribution

AWS Config ルール: cloudfront-viewer-policy-https

パラメータ: なし

このコントロールは、Amazon CloudFront ディストリビューションでビューアが HTTPS を直接使用する必要があるかどうか、またはリダイレクトを使用するかどうかをチェックします。コントロールは、次の場合に失敗しますViewerProtocolPolicyは、 に設定されます。allow-allfordefaultCacheBehaviorまたはcacheBehaviors

HTTPS (TLS) を使用すると、潜在的な攻撃者が中間者攻撃または同様の攻撃を使用してネットワークトラフィックを盗聴または操作することを防止できます。HTTPS (TLS) 経由の暗号化された接続のみを許可する必要があります。転送中のデータの暗号化は、パフォーマンスに影響する可能性があります。TLS のパフォーマンスプロファイルと TLS の影響を理解するには、この機能を使用してアプリケーションをテストする必要があります。

注記

このコントロールは、米国東部 (バージニア北部) でのみサポートされています。次のリージョンではサポートされていません。

  • 米国東部 (オハイオ)

  • 米国西部 (北カリフォルニア)

  • 米国西部 (オレゴン)

  • アフリカ (ケープタウン)

  • アジアパシフィック (香港)

  • アジアパシフィック (ムンバイ)

  • アジアパシフィック (大阪)

  • アジアパシフィック (ソウル)

  • アジアパシフィック (シンガポール)

  • アジアパシフィック (シドニー)

  • アジアパシフィック (東京)

  • カナダ (中部)

  • 中国 (北京)

  • 中国 (寧夏)

  • 欧州 (フランクフルト)

  • 欧州 (アイルランド)

  • 欧州 (ロンドン)

  • ヨーロッパ (ミラノ)

  • 欧州 (パリ)

  • 欧州 (ストックホルム)

  • 中東 (バーレーン)

  • 南米 (サンパウロ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

詳細な修復手順については、「」を参照してください。ビューワーと CloudFront 間の通信で HTTPS を必須にするAmazon CloudFront 開発者ガイド

[CloudFront.4] CloudFront ディストリビューションにはオリジンフェールオーバーが設定されている必要があります

カテゴリ: リカバリ > レジリエンス > 高可用性

緊急度:

リソースタイプ: AWS::CloudFront::Distribution

AWS Config ルール: cloudfront-origin-failover-enabled

パラメータ: なし

このコントロールは、Amazon CloudFront ディストリビューションが 2 つ以上のオリジンを持つオリジングループで構成されているかどうかをチェックします。

CloudFront オリジンのフェイルオーバーにより、可用性が向上します。オリジンフェールオーバーは、プライマリオリジンが使用できない場合、または特定の HTTP レスポンスステータスコードを返す場合、トラフィックを自動的にセカンダリオリジンにリダイレクトします。

注記

このコントロールは、米国東部 (バージニア北部) でのみサポートされています。次のリージョンではサポートされていません。

  • 米国東部 (オハイオ)

  • 米国西部 (北カリフォルニア)

  • 米国西部 (オレゴン)

  • アフリカ (ケープタウン)

  • アジアパシフィック (香港)

  • アジアパシフィック (ムンバイ)

  • アジアパシフィック (大阪)

  • アジアパシフィック (ソウル)

  • アジアパシフィック (シンガポール)

  • アジアパシフィック (シドニー)

  • アジアパシフィック (東京)

  • カナダ (中部)

  • 中国 (北京)

  • 中国 (寧夏)

  • 欧州 (フランクフルト)

  • 欧州 (アイルランド)

  • 欧州 (ロンドン)

  • ヨーロッパ (ミラノ)

  • 欧州 (パリ)

  • 欧州 (ストックホルム)

  • 中東 (バーレーン)

  • 南米 (サンパウロ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

詳細な修復手順については、「」を参照してください。オリジングループの作成Amazon CloudFront 開発者ガイド

[CloudFront.5] CloudFront ディストリビューションでロギングを有効にする必要があります

カテゴリ: 識別-ログ記録

緊急度: ミディアム

リソースタイプ: AWS::CloudFront::Distribution

AWS Config ルール: cloudfront_accesslogs_enabled

パラメータ:

  • S3BucketName(オプション) — ログの送信先の S3 バケット

このコントロールは、CloudFront ディストリビューションでサーバーアクセスログが有効になっているかどうかをチェックします。ディストリビューションでアクセスログが有効になっていないと、コントロールは失敗します。

CloudFront アクセスログは、CloudFront が受信するすべてのユーザーリクエストの詳細を提供します。各ログには、リクエストが受信された日時、リクエストを行ったビューアの IP アドレス、リクエストのソース、ビューアからのリクエストのポート番号などの情報が含まれます。

これらのログは、セキュリティ、アクセスの監査、フォレンジックの調査などのアプリケーションに役立ちます。アクセスログの分析方法に関する追加のガイダンスについては、を参照してください。Amazon CloudFront ログのクエリAmazon Athena ユーザーガイド

注記

このコントロールは、米国東部 (バージニア北部) でのみサポートされています。次のリージョンではサポートされていません。

  • 米国東部 (オハイオ)

  • 米国西部 (北カリフォルニア)

  • 米国西部 (オレゴン)

  • アフリカ (ケープタウン)

  • アジアパシフィック (香港)

  • アジアパシフィック (ムンバイ)

  • アジアパシフィック (大阪)

  • アジアパシフィック (ソウル)

  • アジアパシフィック (シンガポール)

  • アジアパシフィック (シドニー)

  • アジアパシフィック (東京)

  • カナダ (中部)

  • 中国 (北京)

  • 中国 (寧夏)

  • 欧州 (フランクフルト)

  • 欧州 (アイルランド)

  • 欧州 (ロンドン)

  • ヨーロッパ (ミラノ)

  • 欧州 (パリ)

  • 欧州 (ストックホルム)

  • 中東 (バーレーン)

  • 南米 (サンパウロ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

CloudFront ディストリビューションのアクセスログの設定方法の詳細については、「」標準ログ (アクセスログ) の設定および使用Amazon CloudFront 開発者ガイド

[CloudFront.6] CloudFront ディストリビューションには以下が必要ですAWS WAFenabled

カテゴリ: 保護-保護サービス

緊急度: ミディアム

リソースタイプ: AWS::CloudFront::Distribution

AWS Config ルール: cloudfront_associated_with_waf

パラメータ:

  • wafWebAclIds(オプション)-ウェブ ACL ID のカンマ区切りリスト(用AWS WAF) またはウェブ ACL ARN (の場合)AWS WAFv2)。

このコントロールは、CloudFront ディストリビューションがどちらにも関連付けられているかどうかをチェックします。AWS WAFまたはAWS WAFv2 ウェブ ACL。ディストリビューションがウェブ ACL に関連付けられていない場合、コントロールは失敗します。

AWS WAF は、ウェブアプリケーションと API を攻撃から保護するウェブアプリケーションファイアウォールです。これにより、お客様が定義するカスタマイズ可能なウェブセキュリティルールと条件に基づいて、ウェブリクエストを許可、ブロック、またはカウントする一連のルール (ウェブアクセスコントロールリストまたはウェブ ACL と呼ばれます) を設定することができます。CloudFront ディストリビューションがAWS WAFウェブ ACL は、悪意のある攻撃から保護するのに役立ちます。

注記

このコントロールは、米国東部 (バージニア北部) でのみサポートされています。以下のリージョンではサポートされていません。

  • 米国東部 (オハイオ)

  • 米国西部 (北カリフォルニア)

  • 米国西部 (オレゴン)

  • アフリカ (ケープタウン)

  • アジアパシフィック (香港)

  • アジアパシフィック (ムンバイ)

  • アジアパシフィック (大阪)

  • アジアパシフィック (ソウル)

  • アジアパシフィック (シンガポール)

  • アジアパシフィック (シドニー)

  • アジアパシフィック (東京)

  • カナダ (中部)

  • 中国 (北京)

  • 中国 (寧夏)

  • 欧州 (フランクフルト)

  • 欧州 (アイルランド)

  • 欧州 (ロンドン)

  • ヨーロッパ (ミラノ)

  • 欧州 (パリ)

  • 欧州 (ストックホルム)

  • 中東 (バーレーン)

  • 南米 (サンパウロ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

ウェブ ACL と CloudFront ディストリビューションを関連付ける方法については、「」を参照してください。を使用するAWS WAFコンテンツへのアクセスを管理するAmazon CloudFront 開発者ガイド

[CloudTrail.1] CloudTrail を有効にし、少なくとも 1 つのマルチリージョンの証跡で設定する必要があります。

カテゴリ: 識別-ログ記録

緊急度:

リソースタイプ: AWSアカウント

AWS Config ルール: multi-region-cloudtrail-enabled

パラメータ:

  • readWriteType: ALL

このコントロールは、マルチリージョン CloudTrail 証跡が少なくとも 1 つあることを確認します。

AWS CloudTrail はお客様のアカウントの AWS API コールを記録し、ログファイルをお客様に送信します。記録された情報には、以下の情報が含まれます。

  • API 発信者の ID

  • API コールの時刻

  • API 発信者の送信元 IP アドレス

  • パラメータのリクエスト

  • AWS のサービスによって返されるレスポンス要素。

CloudTrail はの履歴を提供しますAWSアカウントの API コール(から実行された API コールを含む)AWS Management Console,AWSSDK、コマンドラインツール。履歴には、AWS CloudFormation などの上位レベルの AWS サービスからの API コールも含まれます。

-AWSCloudTrail によって生成される API の呼び出し履歴を利用して、セキュリティ分析、リソース変更の追跡、およびコンプライアンスの監査を行うことができます。マルチリージョンの証跡には、次の利点もあります。

  • マルチリージョンの証跡により、使用されていないリージョンで発生する予期しないアクティビティを検出できます。

  • マルチリージョンの証跡では、証跡のグローバルサービスイベントのログ記録がデフォルトで有効になります。グローバルサービスイベントのログ記録では、AWS グローバルサービスによって生成されたイベントが記録されます。

  • マルチリージョンの証跡では、すべての読み取りオペレーションと書き込みオペレーションの管理イベントによって、CloudTrail は、AWSアカウントのリソース。

デフォルトでは、CloudTrail 証跡は、AWS Management Consoleマルチリージョンのトレイルです。

Remediation

この問題を解決するには、CloudTrail で新しいマルチリージョンの証跡を作成します。

CloudTrail に新しい証跡を作成するには

  1. CloudTrail コンソール (https://console.aws.amazon.com/cloudtrail/) を開きます。

  2. CloudTrail を初めて使用する場合は、[] を選択します。今すぐ始める

  3. [Trails (証跡)] を選択し、[Create trail (証跡の作成)] を選択します。

  4. 証跡の名前を入力します。

  5. [Storage location (ストレージのロケーション)] で、次のいずれかの操作を行います。

    1. CloudTrail ログ用の新しい S3 バケットを作成するには、新しい S3 バケットを作成するで、はいをクリックし、新しい S3 バケットの名前を入力します。

    2. 既存の S3 バケットを使用するには、[Create a new S3 bucket (新しい S3 バケットを作成する)] で [いいえ] を選択し、使用する S3 バケットを選択します。

  6. []追加設定で、アドバンスト。を使用する場合ログファイルの検証を有効にするを選択します。[Enabled (有効)]

  7. [作成] を選択します。

CloudTrail の既存の証跡を更新するには

  1. CloudTrail コンソール (https://console.aws.amazon.com/cloudtrail/) を開きます。

  2. [証跡] を選択します。

  3. [名前] 列で、証跡の名前を選択します。

  4. を使用する場合管理イベントで、編集

  5. を使用する場合読み取り/書き込みイベントを選択します。管理イベント

  6. []API アクティビティを選択します。Readおよび書き込み

[CloudTrail.2] CloudTrail では、保管時の暗号化が有効になっている必要があります。

カテゴリ: 保護-データ保護-保管中のデータの暗号化

緊急度: ミディアム

リソースタイプ: AWS::CloudTrail::Trail

AWS Config ルール: cloud-trail-encryption-enabled

パラメータ: なし

このコントロールは、CloudTrail がサーバー側の暗号化 (SSE) を使用するよう設定されているかどうかを確認します。AWS KMS key暗号化を使用して保存されます。KmsKeyId が定義されている場合、チェックは合格します。

機密な CloudTrail ログファイルのセキュリティを強化するには、でのサーバー側の暗号化AWS KMS— マネージドキー (SSE-KMS)保管時の暗号化のための CloudTrail ログファイルの場合。デフォルトでは、CloudTrail によってバケットに配信されるログファイルは、Amazon S3 で管理された暗号化キーを使用した Amazon サーバー側の暗号化 (SSE-S3)

Remediation

この問題を解決するには、証跡を更新して、ログファイルに対して SSE-KMS 暗号化を有効にします。

CloudTrail ログの暗号化を有効にするには

  1. CloudTrail コンソール (https://console.aws.amazon.com/cloudtrail/) を開きます。

  2. [証跡] を選択します。

  3. 更新する証跡を選択します。

  4. []一般的な詳細で、編集

  5. を使用する場合ログファイル SSE-KMS 暗号化を選択します。[Enabled (有効)]

  6. [Create a new KMS key (新しい KMS キーを作成する)] で、次のいずれかの操作を行います。

    • キーを作成するには、新規。それならでAWS KMSaliasで、キーのエイリアスを入力します。キーは、S3 バケットと同じリージョンに作成されます。

    • 既存のキーを使用するには、[EXisting、次に、からAWS KMSalias[] を選択してから、キーを選択します。

      AWS KMS キーおよび S3 バケットは同じリージョンにある必要があります。

  7. [Save] を選択します。

    KMS キーと正常にやり取りするためには、CloudTrail のポリシーを変更する必要がある場合があります。詳細については、「」を参照してください。を使用して CloudTrail ログファイルを暗号化するAWS KMS— マネージドキー (SSE-KMS)AWS CloudTrailユーザーガイド

[CloudTrail.4] CloudTrail ログファイルの検証が有効になっているかどうかを確認します

カテゴリ: データ保護 > データの整合性

緊急度:

リソースタイプ: AWS::CloudTrail::Trail

AWS Config ルール: cloud-trail-log-file-validation-enabled

パラメータ: なし

このコントロールは、CloudTrail 証跡でログファイルの整合性検証が有効になっているかどうかを確認します。

CloudTrail ログファイルの検証は、CloudTrail が Amazon S3 に書き込むそれぞれのログのハッシュを含むデジタル署名されたダイジェストファイルを作成します。CloudTrail がログを配信した後で、これらのダイジェストファイルを使用して、ログファイルが変更、削除、または変更されなかったかどうかを判断できます。

Security Hub では、すべての証跡でファイルの検証を有効にすることをお勧めします。ログファイルの検証は、CloudTrail ログの追加の整合性チェックを提供します。

詳細については、「」を参照してください。ファイルの検証と検証の有効化AWS CloudTrailユーザーガイド

Remediation

この問題を解決するには、CloudTrail 証跡を更新して、ログファイルの検証を有効にします。

CloudTrail のログファイルの検証を有効にするには

  1. CloudTrail コンソール (https://console.aws.amazon.com/cloudtrail/) を開きます。

  2. [証跡] を選択します。

  3. []名前[] で、編集する証跡の名前を選択します。

  4. []一般的な詳細で、編集

  5. []追加設定、に対してログファイルの検証で、[Enabled (有効)]

  6. [変更を保存] を選択します。

詳細については、「」を参照してください。CloudTrail のログファイルの整合性の検証AWS CloudTrailユーザーガイド

[CloudTrail.5] CloudTrail トレイルが Amazon CloudWatch Logs と統合されていることを確認する

カテゴリ: 識別-ログ記録

緊急度:

リソースタイプ: AWS::CloudTrail::Trail

AWS Config ルール: cloud-trail-cloud-watch-logs-enabled

パラメータ: なし

このコントロールは、CloudWatch Logs にログを送信するように CloudTrail 証跡が設定されているかどうかを確認します。コントロールは、CloudWatchLogsLogGroupArn証跡のプロパティが空です。

CloudTrail レコードAWS指定されたアカウントで実行される API コール。記録された情報には、以下が含まれます。

  • API 発信者の ID

  • API コールの時刻

  • API 呼び出し元の送信元 IP アドレス

  • リクエストパラメータ

  • によって返されるレスポンス要素。AWSのサービス

CloudTrail は、Amazon S3 を使用してログファイルの保存と配信を行います。長期分析のために、指定された S3 バケットの CloudTrail ログをキャプチャできます。リアルタイム分析を実行するには、CloudWatch Logs にログを送信するように CloudTrail を設定できます。

アカウント内のすべてのリージョンで有効になっている証跡では、CloudTrail は、これらのすべてのリージョンから CloudWatch Logs ロググループ宛てのものだけにログファイルを送信します。

Security Hub は、CloudWatch Logs に CloudTrail ログを送信することをお勧めします。この推奨事項は、アカウントアクティビティがキャプチャされ、監視され、適切なアラームがあることを確認することを目的としています。CloudWatch Logs を使用して、AWSのサービス。この推奨事項は、別のソリューションの使用を排除するものではありません。

CloudTrail ログを CloudWatch Logs に送信すると、ユーザー、API、リソース、および IP アドレスに基づいてリアルタイムおよび過去のアクティビティのログ記録が容易になります。この方法を使用して、異常または機密性の高いアカウントアクティビティのアラームと通知を確立できます。

Remediation

コンソールを使用して CloudWatch Logs と CloudTrail の統合を有効にすることができます。

CloudWatch Logs と CloudTrail 統合を有効にするには

  1. CloudTrail コンソール (https://console.aws.amazon.com/cloudtrail/) を開きます。

  2. [証跡] を選択します。

  3. の値のない証跡を選択してくださいCloudWatch Logs ロググループ

  4. [][CloudWatch Logs]で、編集

  5. [Enabled] を選択します。

  6. を使用する場合ロググループ[] で、次のいずれかを実行します。

    • デフォルトのロググループを使用するには、名前はそのままにします。

    • 既存のロググループを使用するには、[] を選択します。EXistingをクリックし、使用するロググループの名前を入力します。

    • 新しいロググループを作成するには、[] を選択します。新規をクリックし、作成するロググループの名前を入力します。

  7. [IAM role (IAM ロール)] で、次のいずれかを実行します。

    • 既存のロールを使用するには、EXistingを選択し、ドロップダウンリストからロールを選択します。

    • 新しいロールを作成するには、新規次に、作成するロールの名前を入力します。新しいロールには、必要なアクセス許可を付与するポリシーが割り当てられます。

    ロールに付与された権限を表示するには、ポリシードキュメント

  8. [変更を保存] を選択します。

詳細については、「」を参照してください。コンソールを使用した CloudWatch Logs モニタリングの設定AWS CloudTrailユーザーガイド

[CodeBuild.1] CodeBuild GitHub または Bitbucket のソースリポジトリの URL は、OAuth を使用する必要があります

カテゴリ: 保護-セキュア開発

緊急度: 非常事態

リソースタイプ: AWS::CodeBuild::Project

AWS Config ルール: codebuild-project-source-repo-url-check

パラメータ: なし

このコントロールは、GitHub または Bitbucket のソースレポジトリの URL に、個人用のアクセストークンまたはユーザー名とパスワードが含まれているかどうか確認します。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アフリカ (ケープタウン)

  • ヨーロッパ (ミラノ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

認証情報は、クリアテキストで保存または送信したり、リポジトリ URL に表示しないでください。GitHub または Bitbucket リポジトリへのアクセス認可を付与するには、個人のアクセストークンまたはユーザー名とパスワードではなく OAuth を使用する必要があります。個人用アクセストークンまたはユーザー名やパスワードを使用すると、認証情報が意図しないデータ漏えいや不正アクセスにさらされる可能性があります。

Remediation

CodeBuild プロジェクトを更新して OAuth を使用できます。

基本認証/ (GitHub) 個人用のアクセストークンをCodeBuild プロジェクトソースから削除するには

  1. CodeBuild コンソール () を開きます。https://console.aws.amazon.com/codebuild/

  2. 個人用のアクセストークンまたはユーザー名とパスワードを含むビルドプロジェクトを選択する

  3. [Edit (編集)] から [Source (ソース)] を選択します。

  4. [Disconnect from GitHub / Bitbucket (GitHub/Bitbucket から切断)] を選択します。

  5. [Connect using OAuth (OAuth を使用して接続)] を選択し、[Connect to GitHub / Bitbucket (GitHub/Bitbucket に接続)] を選択します。

  6. プロンプトが表示されたら、[as appropriate (必要に応じて承認)] を選択します。

  7. 必要に応じて、[Repository URL (リポジトリ URL)] と [additional configuration (追加の設定)] 設定を再設定します。

  8. [Update source (ソースの更新)] を選択します。

詳細については、を参照してください。CodeBuild ユースケースベースのサンプルAWS CodeBuildユーザーガイド

[CodeBuild.2] CodeBuild プロジェクト環境変数にクリアテキストの認証情報を含めることはできません

カテゴリ: 保護-セキュア開発

緊急度: 非常事態

リソースタイプ: AWS::CodeBuild::Project

AWS Config ルール: codebuild-project-envvar-awscred-check

パラメータ: なし

このコントロールは、プロジェクトに環境変数 AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEY が含まれているかどうかをチェックします。

認証情報 AWS_ACCESS_KEY_ID および AWS_SECRET_ACCESS_KEY はクリアテキストで保存しないでください。これは、意図しないデータ漏えいや不正アクセスにつながる可能性があるためです。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アフリカ (ケープタウン)

  • ヨーロッパ (ミラノ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

この問題を解決するには、CodeBuild プロジェクトを更新して環境変数を削除します。

CodeBuild プロジェクトから環境変数を削除するには

  1. CodeBuild コンソール () を開きます。https://console.aws.amazon.com/codebuild/

  2. [Build (構築)] を展開します。

  3. [Build project (ビルドプロジェクト)] を選択して、プレーンテキストの認証情報を含むビルドプロジェクトを選択します。

  4. [編集] から [環境] を選択します。

  5. [Additional configuration (追加設定)] を展開します。

  6. 環境変数の横にある [Remove (削除)] を選択します。

  7. [Update environment (環境の更新)] を選択します。

機密値は Amazon EC2 Systems Manager パラメータストアに保存後、ビルド仕様から取得するには

  1. CodeBuild コンソール () を開きます。https://console.aws.amazon.com/codebuild/

  2. [Build (構築)] を展開します。

  3. [Build project (ビルドプロジェクト)] を選択して、プレーンテキストの認証情報を含むビルドプロジェクトを選択します。

  4. [編集] から [環境] を選択します。

  5. [Additional configuration (追加の設定)] を展開し、[Environment variables (環境変数)] までスクロールします。

  6. フォローこのチュートリアルをクリックして、機密データを含むSystems Manager パラメータを作成します。

  7. パラメータを作成したら、パラメータ名をコピーします。

  8. CodeBuild コンソールに戻り、[] を選択します。環境変数を作成する

  9. ビルド仕様に表示される変数の名前を入力します。

  10. [value (値)] には、パラメータの名前を貼り付けます。

  11. [タイプ] で [Parameter (パラメータ)] を選択します。

  12. プレーンテキストの認証情報を含む非準拠の環境変数を削除するには、[Remove (削除)] を選択します。

  13. [Update environment (環境の更新)] を選択します。

詳細については、「」を参照してください。ビルド環境の環境変数AWS CodeBuildユーザーガイド

[Config.1] AWS Config を有効にする必要があります

カテゴリ: 識別-インベントリ

緊急度: ミディアム

リソースタイプ: AWSアカウント

AWS Configルール: なし

パラメータ: なし

このコントロールは、ローカルリージョンのアカウントで AWS Config が有効になっているかどうか、およびすべてのリソースを記録しているかどうかをチェックします。

AWS Config は、アカウントでサポートされている AWS リソースの設定管理を実行し、ログファイルを配信するウェブサービスです。記録される情報には、設定項目 (AWS リソース)、設定項目間の関係、およびリソース間の設定変更が含まれます。

Security Hub では、有効にすることを推奨します。AWS Configは、すべてのリージョンで使用できます。AWS Config がキャプチャする AWS 設定項目の履歴により、セキュリティ分析、リソース変更の追跡、およびコンプライアンスの監査を行うことができます。

注記

Security Hub はリージョナルサービスであるため、このコントロールに対して実行されるチェックでは、アカウントの現在のリージョンのみが確認されます。すべてのリージョンが確認されるわけではありません。

またグローバルリソースに対するセキュリティチェックを各リージョンで許可するには、グローバルリソースを記録する必要があります。グローバルリソースを 1 つのリージョンにのみ記録する場合は、グローバルリソースを記録するリージョン以外のすべてのリージョンでこのコントロールを無効にすることができます。

詳細については、次を参照してください。の開始方法AWS ConfigAWS Configデベロッパーガイド

Remediation

有効にした後AWS Configで、すべてのリソースを記録するように設定します。

AWS Config 設定を構成するには

  1. AWS Config コンソール(https://console.aws.amazon.com/config/)を開きます。

  2. AWS Config を設定するリージョンを選択します。

  3. (これまでに AWS Config を使用したことがない場合は、[Get started (今すぐ始める)] を選択します。)

  4. [Settings (設定)] ページで、以下の操作を行います。

    1. []記録するリソースタイプで、このリージョンでサポートされるすべてのリソースを記録するおよびグローバルリソースを含める (例:AWSIAM リソース)

    2. []AWS Configロールで、どちらかを選んでください作成AWS Configサービスにリンクされたロールまたはアカウントからロールを選択次に、使用するロールを選択します。

    3. [Amazon S3 bucket (Amazon S3 バケット)] で、バケットを使用するか、バケットを作成し、必要に応じてプレフィックスを含めます。

    4. []Amazon SNS トピックで、アカウントから Amazon SNS トピックを選択するか、トピックを作成します。Amazon SNS の詳細については、「」を参照してください。Amazon Simple Notication Service 入門ガイド

  5. [次へ] を選択します。

  6. リポジトリの []AWS Configルール[] ページで、[]

  7. [Confirm] を選択します。

の使用方法の詳細については、「」を参照AWS ConfigからのAWS CLI「」を参照してください。の有効化AWS ConfigAWS Configデベロッパーガイド

AWS CloudFormation テンプレートを使用してこのプロセスを自動化することもできます。詳細については、「」を参照してください。AWS CloudFormationStackSets サンプルテンプレートAWS CloudFormationユーザーガイド

[DMS.1]AWS Database Migration Serviceレプリケーションインスタンスはパブリックであってはならない

カテゴリ: 保護-セキュアなネットワーク設定

緊急度: 非常事態

リソースタイプ: AWS::DMS::ReplicationInstance

AWS Config ルール: dms-replication-not-public

パラメータ: なし

このコントロールは、かどうかを確認します。AWS DMSレプリケーションインスタンスはパブリックです。そのためには、その値を調べます。PubliclyAccessibleフィールド。

プライベートレプリケーションインスタンスには、レプリケーションネットワーク外からアクセスできないるプライベート IP アドレスがあります。ソースデータベースとターゲットデータベースが同じネットワーク内にある場合、レプリケーションインスタンスにはプライベート IP アドレスが必要です。また、ネットワークは VPN を使用してレプリケーションインスタンスの VPC に接続する必要があります。AWS Direct Connect、または VPC ピア接続を指定します。パブリックおよびプライベートレプリケーションインスタンスの詳細については、「」を参照してください。パブリックおよびプライベートレプリケーションインスタンスAWS Database Migration Serviceユーザーガイド

また、AWS DMSインスタンス構成は、承認されたユーザーのみに制限されます。これを行うには、ユーザーの IAM アクセス許可を変更するように制限します。AWS DMS設定とリソース。

注記

このコントロールは、アフリカ (ケープタウン) または EU (ミラノ) ではサポートされていません。

Remediation

レプリケーションインスタンスの作成後は、パブリックアクセス設定を変更できないことに注意してください。削除して再作成する必要があります。

を設定するにはAWS DMSパブリックアクセスをブロックするレプリケーションインスタンス設定

  1. AWS Database Migration Service コンソール (https://console.aws.amazon.com/dms/) を開きます。

  2. に移動します。レプリケーションインスタンスをクリックし、パブリックインスタンスを削除します。インスタンスを選択し、以下を選択します。アクション[]、[]delete

  3. [Create replication instance] を選択します。設定の詳細を入力します。

  4. パブリックアクセスを無効にするには、パブリックアクセス可能が選択されていません。

  5. [作成] を選択します。

詳細については、「」の「」セクションを参照してください。レプリケーションインスタンスの作成AWS Database Migration Serviceユーザーガイド

[DynamoDB.1] DynamoDB テーブルは需要に応じて自動的に容量をスケーリングする必要があります

カテゴリ: リカバリ > レジリエンス > 高可用性

緊急度: ミディアム

リソースタイプ: AWS::DynamoDB::Table

AWS Config ルール: dynamodb-autoscaling-enabled

パラメータ: なし

このコントロールは、Amazon DynamoDB テーブルが必要に応じて読み取りおよび書き込み容量をスケーリングできるかどうかをチェックします。テーブルで Auto Scaling が設定されたオンデマンドキャパシティモードまたは Provisioned モードを使用する場合に、このコントロールは通過します。需要に応じて容量をスケーリングすると、例外のスロットリングを回避し、アプリケーションの可用性を維持するのに役立ちます。

オンデマンドキャパシティモードの DynamoDB テーブルは、DynamoDB スループットのデフォルトテーブルクォータによってのみ制限されます。これらのクォータを引き上げるには、次の方法でサポートチケットを提出してください。AWS Support

Auto Scaling を使用したプロビジョニングモードの DynamoDB テーブルは、トラフィックパターンに応じてプロビジョニングされたスループット容量を動的に調整します。DynamoDB リクエストのスロットリングの詳細については、「」を参照してください。スロットリングおよびバースト容量を要求するAmazon DynamoDB 開発者ガイド

注記

このコントロールは、ではサポートされていません。AWSGovCloud (米国東部) またはAWSGovCloud (米国西部)。

Remediation

容量モードで既存のテーブルで DynamoDB 自動スケーリングを有効にする手順については、を参照してください。既存のテーブルで DynamoDB 自動スケーリングを有効にするAmazon DynamoDB 開発者ガイド

[DynamoDB.2] DynamoDB テーブルでは、ポイントインタイムリカバリを有効にする必要があります

カテゴリ: リカバリ > レジリエンス > バックアップの有効化

緊急度: ミディアム

リソースタイプ: AWS::DynamoDB::Table

AWS Config ルール: dynamodb-pitr-enabled

パラメータ: なし

このコントロールは、Amazon DynamoDB テーブルでポイントインタイムリカバリ (PITR) が有効になっているかどうかを確認します。

バックアップは、セキュリティインシデントからより迅速にリカバリするのに役立ちます。また、システムの復元力を強化します。DynamoDB ポイントインタイムリカバリは、DynamoDB テーブルのバックアップを自動化します。これにより、誤って削除または書き込み操作からリカバリする時間が短縮されます。PITR が有効になっている DynamoDB テーブルは、過去 35 日間の任意の時点に復元できます。

Remediation

この問題を修復するには、DynamoDB テーブルにポイントインタイムリカバリを追加します。

既存のテーブルの DynamoDB ポイントインタイムリカバリを有効にするには

  1. https://console.aws.amazon.com/dynamodb/ で DynamoDB コンソールを開きます。

  2. 使用するテーブルを選択し、[バックアップ

  3. ポイントインタイムリカバリセクション、ステータスで、の有効化

  4. 選択の有効化もう一度変更を確認します。

[DynamoDB.3] DynamoDB Accelerator (DAX) クラスターは保管時に暗号化する必要があります

カテゴリ: 保護-データ保護-保管中のデータの暗号化

緊急度: ミディアム

リソースタイプ: AWS::DAX::Cluster

AWS Config ルール: dax_encryption_enabled

パラメータ: なし

このコントロールは、保管時に DAX クラスターが暗号化されているかどうかを確認します。

保管中のデータを暗号化すると、ディスクに保存されているデータが、認証されていないユーザーによってアクセスされるリスクが軽減されます。AWS。暗号化により、権限のないユーザーがデータにアクセスする能力を制限するために、別のアクセス制御セットが追加されます。たとえば、データを読み取る前にデータを復号化するには、API 権限が必要です。

Remediation

クラスターが作成された後は、保管時の暗号化を有効または無効にすることはできません。保管時に暗号化するにはクラスターを再作成する必要があります。保存時の暗号化を有効にした DAX クラスターを作成する方法の詳細については、「」を参照してください。を使用して保管時の暗号化の有効化AWS Management ConsoleAmazon DynamoDB 開発者ガイド

[EC2.1] Amazon EBS スナップショットは、パブリックであってはなりません。これは誰でも復元できるかどうかによって判断されます

カテゴリ: 保護-セキュアなネットワーク設定

緊急度: 非常事態

リソースタイプ: AWSアカウント

AWS Config ルール: ebs-snapshot-public-restorable-check

パラメータ: なし

このコントロールは、Amazon Elastic Block Store のスナップショットが公開されていないことをチェックします。これは、誰でも復元できるかどうかによって判断されます。

EBS スナップショットは、特定の時点の EBS ボリュームのデータを Amazon S3 にバックアップするために使用されます。スナップショットを使用して、EBS ボリュームの以前の状態を復元できます。スナップショットをパブリックに共有することはほとんど受け入れられません。一般的に、スナップショットをパブリックに共有するという決定は、誤って、またはその影響を完全に理解することなく行われました。このチェックは、そのような共有がすべて完全に計画され、意図的であったことを確認するのに役立ちます。

注記

このコントロールは、アフリカ (ケープタウン) または EU (ミラノ) ではサポートされていません。

Remediation

この問題を修復するには、EBS スナップショットを更新して、パブリックではなくプライベートにします。

パブリック EBS スナップショットをプライベートにするには

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

  2. ナビゲーションペインの [] で、[] をクリックします。Elastic Block Storeで、スナップショット[] メニューを選択し、パブリックスナップショットを選択します。

  3. [Actions (アクション)] から、[Modify permissions (アクセス許可の変更)] を選択します。

  4. [プライベート] を選択します。

  5. (オプション) を追加します。AWSスナップショットを共有し、選択するための許可されたアカウントのアカウント番号アクセス許可の追加

  6. [Save] を選択します。

[EC2.2] VPC のデフォルトのセキュリティグループでは、インバウンドトラフィックとアウトバウンドトラフィックが禁止されます

カテゴリ: 保護-セキュアなネットワーク設定

緊急度:

リソースタイプ: AWS::EC2::SecurityGroup

AWS Config ルール: vpc-default-security-group-closed

パラメータ: なし

このコントロールは、VPC のデフォルトのセキュリティグループがインバウンドとアウトバウンドのいずれのトラフィックも許可しないことを確認します。

デフォルトのセキュリティグループのルールでは、同じセキュリティグループに割り当てられているネットワークインターフェイス (および関連するインスタンス) からのすべてのアウトバウンドトラフィックとインバウンドトラフィックを許可します。

デフォルトのセキュリティグループを使用することはお勧めしません。デフォルトのセキュリティグループは削除できないため、デフォルトのセキュリティグループルール設定を変更して、インバウンドトラフィックとアウトバウンドトラフィックを制限する必要があります。これにより、デフォルトのセキュリティグループが EC2 インスタンスなどのリソースに対して誤って設定されている場合に、意図しないトラフィックが防止されます。

Remediation

この問題を解決するには、新しいセキュリティグループを作成し、それらのセキュリティグループをリソースに割り当てます。デフォルトのセキュリティグループが使用されないようにするには、インバウンドルールとアウトバウンドルールを削除します。

新しいセキュリティグループを作成してリソースに割り当てるには

  1. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。

  2. ナビゲーションペインで、[Security groups (セキュリティグループ)] を選択します。デフォルトセキュリティグループの詳細を表示して、それらに割り当てられているリソースを表示します。

  3. リソースに対して最小権限のセキュリティグループのセットを作成します。セキュリティグループを作成する方法については、「」を参照してください。セキュリティグループを作成するAmazon VPC User Guide

  4. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

  5. Amazon EC2 コンソールで、デフォルトのセキュリティグループを使用しているリソースのセキュリティグループを、作成した最小権限のセキュリティグループに変更します。「」を参照してください。インスタンスのセキュリティグループを変更するAmazon VPC User Guide

新しいセキュリティグループをリソースに割り当てた後、デフォルトのセキュリティグループからインバウンドルールとアウトバウンドルールを削除します。これにより、デフォルトのセキュリティグループが使用されなくなります。

デフォルトのセキュリティグループからルールを削除するには

  1. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。

  2. ナビゲーションペインで、[Security groups (セキュリティグループ)] を選択します。

  3. デフォルトのセキュリティグループを選択し、インバウンドルールタブ。選択インバウンドのルールの編集。次に、インバウンドルールをすべて削除します。[Save Rules (ルールの保存)] を選択します。

  4. 各デフォルトセキュリティグループに対して、前のステップを繰り返します。

  5. デフォルトのセキュリティグループを選択し、アウトバウンドルールタブ。選択アウトバウンドルールの編集。次に、すべてのアウトバウンドルールを削除します。[Save Rules (ルールの保存)] を選択します。

  6. 各デフォルトセキュリティグループに対して、前のステップを繰り返します。

詳細については、「」を参照してください。セキュリティグループを操作するAmazon VPC User Guide

[EC2.3] アタッチされた EBS ボリュームは保管時に暗号化する必要があります

カテゴリ: 保護-データ保護-保管中のデータの暗号化

緊急度: ミディアム

リソースタイプ: AWS::EC2::Volume

AWS Config ルール: encrypted-volumes

パラメータ: なし

このコントロールは、アタッチ済みの EBS ボリュームが暗号化されているかどうかを確認します。このチェックに合格するには、EBS ボリュームが使用中であり、暗号化されている必要があります。EBS ボリュームがアタッチされていない場合、このチェックの対象外です。

EBS ボリュームの機密データのセキュリティを強化するには、保管時の EBS 暗号化を有効にする必要があります。Amazon EBS 暗号化は、EBS リソースのために、独自のキー管理インフラストラクチャの構築、保守、および保護を必要としない、簡単な暗号化ソリューションを提供します。暗号化されたボリュームとスナップショットを作成するときに、KMS キーが使用されます。

Amazon EBS 暗号化の詳細については、「」を参照してください。Amazon EBS 暗号化Linux インスタンス用 Amazon EC2 ユーザーガイド

注記

このコントロールは、アフリカ (ケープタウン) または EU (ミラノ) ではサポートされていません。

Remediation

既存の暗号化されていないボリュームまたはスナップショットを暗号化する直接的な方法はありません。新しいボリュームまたはスナップショットは、作成時にのみ暗号化できます。

暗号化をデフォルトで有効にした場合、Amazon EBS は Amazon EBS 暗号化のデフォルトキーを使用して、作成された新しいボリュームまたはスナップショットを暗号化します。デフォルトで暗号化を有効にしていない場合でも、個々のボリュームまたはスナップショットを作成するときに暗号化を有効にすることができます。どちらの場合も、Amazon EBS 暗号化のデフォルトキーを上書きし、対称カスタマー管理キーを選択できます。

詳細については、「」を参照してください。Amazon EBS ボリュームの作成およびAmazon EBS スナップショットのコピーLinux インスタンス用 Amazon EC2 ユーザーガイド

[EC2.4] 停止した EC2 インスタンスは、指定された期間後に削除する必要があります

カテゴリ: 識別-インベントリ

緊急度: ミディアム

リソースタイプ: AWS::EC2::Instance

AWS Config ルール: ec2-stopped-instance

パラメータ:

  • allowedDays: 30

このコントロールは、許可されている日数よりも長く停止しているすべての EC2 インスタンスがあるかどうかを確認します。EC2 インスタンスは、デフォルトで 30 日である最大許容期間よりも長く停止した場合、このチェックに失敗します。

失敗した結果は、EC2 インスタンスが長期間実行されていないことを示します。これにより、EC2 インスタンスがアクティブに保守(分析、パッチ適用、更新)されていないため、セキュリティリスクが発生します。後で起動すると、適切なメンテナンスの欠如により、予期しない問題が発生する可能性があります。AWS環境。EC2 インスタンスを非実行状態で長期間安全に維持するには、メンテナンスのために定期的に起動し、メンテナンス後に停止します。理想的には、これは自動化されたプロセスです。

注記

このコントロールは、アフリカ (ケープタウン) または EU (ミラノ) ではサポートされていません。

Remediation

コンソールまたはコマンドラインを使用して EC2 インスタンスを終了できます。

EC2 インスタンスを終了する前に、データが失われないことを確認します。

  • Amazon EBS ボリュームが終了しても削除されないことを確認してください。

  • 必要なデータを EC2 インスタンスストアボリュームから Amazon EBS または Amazon S3 にコピーします。

EC2 インスタンスを削除するには (コンソール)

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

  2. ナビゲーションペインで、[Instances] の下にある [Instances] を選択します。

  3. インスタンスを選択してから、[] を選択します。アクション,インスタンスの状態,終了

  4. 確認を求めるメッセージが表示されたら、[Yes, Terminate] を選択します。

EC2 インスタンスを削除するには (AWS CLI、Tools for Windows PowerShell)

以下のいずれかのコマンドを使用します。コマンドラインインターフェイスの詳細については、「」を参照してください。Amazon EC2 へのアクセスLinux インスタンス用 Amazon EC2 ユーザーガイド

インスタンスの終了の詳細については、「」を参照してください。インスタンスを終了したLinux インスタンス用 Amazon EC2 ユーザーガイド

[EC2.6] すべての VPC で VPC フローロギングを有効にする必要があります

カテゴリ: 識別-ログ記録

緊急度: ミディアム

リソースタイプ: AWS::EC2::VPC

AWS Config ルール: vpc-flow-logs-enabled

パラメータ:

  • trafficType: REJECT

このコントロールは、Amazon VPC フローログが見つかり、VPC に対して有効になっているかどうかをチェックします。トラフィックタイプはReject

VPC フローログ機能を使用すると、VPC のネットワークインターフェイスとの間で行き来する IP アドレストラフィックに関する情報をキャプチャできます。フローログを作成した後、CloudWatch Logs でそのデータを表示して取得できます。コストを削減するために、フローログを Amazon S3 に送信することもできます。

Security Hub では、VPC のパケット拒否のフローログ記録を有効にすることをお勧めします。フローログは、VPC を通過するネットワークトラフィックを確認可能にし、異常なトラフィックを検出したり、セキュリティワークフロー中に洞察を提供したりできます。

デフォルトでは、送信元、送信先、プロトコルなど、レコードには IP アドレスフローのさまざまなコンポーネントの値が含まれています。ログフィールドの詳細と説明については、を参照してください。VPC フローログAmazon VPC User Guide

Remediation

この問題を解決するには、VPC フローログを有効にします。

VPC フローログ記録を有効にするには

  1. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。

  2. []Virtual Private Cloudで、VPC

  3. 更新する VPC を選択します。

  4. ページの最下部で、[] を選択します。フローログ

  5. [フローログの作成] を選択します。

  6. [フィルター] で、[拒否] を選択します。

  7. を使用する場合送信先ロググループで、使用するロググループを選択します。

  8. を使用する場合IAM ロールで、使用する IAM ロールを選択します。

  9. [作成] を選択します。

[EC2.7] EBS のデフォルト暗号化を有効にする必要があります

カテゴリ: 保護-データ保護-保管中のデータの暗号化

緊急度: ミディアム

リソースタイプ: AWSアカウント

AWS Config ルール: ec2-ebs-encryption-by-default

パラメータ: なし

このコントロールは、Amazon Elastic Block Store (Amazon EBS) のアカウントレベルの暗号化がデフォルトで有効になっているかどうかをチェックします。アカウントレベルの暗号化が有効になっていないと、コントロールは失敗します。

アカウントで暗号化が有効になっている場合、Amazon EBS ボリュームとスナップショットコピーは保存時に暗号化されます。これにより、データの保護レイヤーが追加されます。詳細については、「」を参照してください。デフォルトでの暗号化Linux インスタンス用 Amazon EC2 ユーザーガイド

次のインスタンスタイプは、暗号化をサポートしていません。R1、C1、M1。

Remediation

Amazon EC2 コンソールを使用して、Amazon EBS ボリュームのデフォルトの暗号化を有効にできます。

リージョンの Amazon EBS 暗号化用にデフォルト暗号化を設定するには

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

  2. ナビゲーションペインの [EC2 ダッシュボード] を選択します。

  3. ページの右上で、[] を選択します。アカウント属性、EBS 暗号化

  4. [管理] をクリックします。

  5. [有効化] を選択します。おれは維持できるAWS マネージドキーエイリアスalias/aws/ebsデフォルトの暗号化キーとしてユーザーの代わりに作成されるか、対称カスタマー管理キーを選択します。

  6. [EBS 暗号化の更新] をクリックします。

[EC2.8] EC2 インスタンスは IMDSv2 を使用する必要があります

カテゴリ: 保護 > ネットワークセキュリティ

緊急度:

リソースタイプ: AWS::EC2::Instance

AWS Config ルール: ec2-imdsv2-check

パラメータ: なし

このコントロールは、EC2 インスタンスメタデータバージョンがインスタンスメタデータサービスバージョン 2 (IMDSv2) で設定されているかどうかをチェックします。コントロールは次の場合に渡されます。HttpTokensIMDSv2 で必須に設定されています。コントロールは、次の場合に失敗しますHttpTokensは、 に設定されます。optional

インスタンスメタデータを使用して、実行中のインスタンスを設定または管理します。IMDS は、一時的で頻繁にローテーションされる資格情報へのアクセスを提供します。これらの認証情報を使用すると、機密認証情報を手動でまたはプログラムでインスタンスにハードコーディングしたり、配布したりする必要がなくなります。IMDS は、すべての EC2 インスタンスにローカルにアタッチされます。これは、169.254.169.254.169.254 の「リンクローカル」IP アドレスで実行されます。この IP アドレスは、インスタンスで実行されるソフトウェアによってのみアクセスできます。

IMDS のバージョン 2 では、次の種類の脆弱性に対する新しい保護が追加されています。これらの脆弱性は、IMDS へのアクセス試行に使用されます。

  • Web サイトアプリケーションのファイアウォールを開く

  • リバースプロキシを開く

  • サーバー側リクエストフォージェリ (SSRF) の脆弱性

  • レイヤ 3 ファイアウォールおよびネットワークアドレス変換 (NAT) を開きます。

Security Hub では、EC2 インスタンスを IMDSv2 で設定することをお勧めします。

注記

このコントロールは、アフリカ (ケープタウン) または EU (ミラノ) ではサポートされていません。

Remediation

IMDSv2 で設定されていない EC2 インスタンスを修復するには、IMDSv2 の使用を要求できます。

既存のインスタンスで IMDSv2 を要求するには、インスタンスメタデータをリクエストするときに、Amazon EC2 メタデータオプションを変更します。「」の指示に従って、既存インスタンスのインスタンスメタデータオプションの設定Linux インスタンス用 Amazon EC2 ユーザーガイド

インスタンスの起動時に IMDSv2 の使用を要求するには、「」の手順に従います。新規インスタンスのインスタンスメタデータオプションの設定Linux インスタンス用 Amazon EC2 ユーザーガイド

コンソールから IMDSv2 を使用して新しい EC2 インスタンスを設定するには

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

  2. 選択インスタンスを起動する[] を選択して [] を選択しますインスタンスを起動する

  3. インスタンスの詳細の設定ステップ、の下詳細情報、に対してメタデータのバージョンで、V2 (トークンが必要)

  4. [Review and Launch] を選択します。

お使いのソフトウェアで IMDSv1 が使用されている場合、IMDSv2 を使用するようソフトウェアを再構成することができます。詳細については、「」を参照してください。インスタンスメタデータサービスバージョン 2 の使用への移行Linux インスタンス用 Amazon EC2 ユーザーガイド

[EC2.9] EC2 インスタンスはパブリック IP アドレスを持つべきではありません

カテゴリ: 保護 > セキュアなネットワーク構成 > パブリック IP アドレス

緊急度:

リソースタイプ: AWS::EC2::Instance

AWS Config ルール: ec2-instance-no-public-ip

パラメータ: なし

このコントロールは、EC2 インスタンスでパブリック IP アドレスがあるかどうかを確認します。コントロールは、publicIpフィールドが EC2 インスタンスの設定項目にあります。このコントロールは、IPv4 アドレスにのみ適用されます。

パブリック IPv4 アドレスは、インターネットから到達可能な IP アドレスです。パブリック IP アドレスを使用してインスタンスを起動すると、EC2 インスタンスにインターネットから到達可能です。プライベート IPv4 アドレスは、インターネットから到達できない IP アドレスです。プライベート IPv4 アドレスは、同じ VPC 内または接続されたプライベートネットワーク内の EC2 インスタンス間の通信に使用できます。

IPv6 アドレスはグローバルに一意であるため、インターネットから到達できます。ただし、デフォルトでは、すべてのサブネットで IPv6 アドレス属性が false に設定されています。IPv6 の詳細については、「」を参照してください。VPC の IP アドレス指定Amazon VPC User Guide

パブリック IP アドレスで EC2 インスタンスを維持する正当なユースケースがある場合は、このコントロールの結果を抑制できます。フロントエンドアーキテクチャのオプションの詳細については、「」を参照してください。AWSアーキテクチャブログまたはこれは私の建築シリーズです

Remediation

デフォルトでパブリック IP アドレスがインスタンスに割り当てられないように、デフォルト以外の VPC を使用します。

EC2 インスタンスをデフォルトの VPC で起動すると、パブリック IP アドレスが割り当てられます。EC2 インスタンスをデフォルト以外の VPC で起動する場合、サブネット設定によって、パブリック IP アドレスを受信するかどうかを判断します。サブネットには、サブネット内の新しい EC2 インスタンスがパブリック IPv4 アドレスプールからパブリック IP アドレスを受信するかどうかを判断する属性が、サブネットにあります。

EC2 インスタンスから自動的に割り当てられたパブリック IP アドレスの関連付けと関連付け解除は手動で実行できません。EC2 インスタンスがパブリック IP アドレスを割り当てられるかどうかを制御するには、以下のいずれかを実行します。

詳細については、Linux インスタンス用の Amazon EC2 ユーザーガイドの「パブリック IPv4 アドレスと外部 DNS ホスト名」を参照してください。

EC2 インスタンスが Elastic IP アドレスに関連付けられている場合、EC2 インスタンスにインターネットからアクセスできます。インスタンスまたはネットワークインターフェイスから Elastic IP アドレスの関連付けをいつでも解除できます。

Elastic IP アドレスの関連付けを解除するには

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

  2. ナビゲーションペインで [Elastic IP] を選択します。

  3. 関連付けを解除する Elastic IP アドレスを選択します。

  4. 送信元アクションで、Elastic IP アドレスの関連付けを解除する

  5. [関連付け解除] を選択します。

[EC2.10] Amazon EC2 サービス用に作成された VPC エンドポイントを使用するようにAmazon EC2 を設定する必要があります。

カテゴリ: 保護-セキュアなネットワーク設定 > API プライベートアクセス

緊急度: ミディアム

リソースタイプ: AWS::EC2::VPC

AWS Config ルール: service-vpc-endpoint-enabled

パラメータ:

  • serviceName: ec2

このコントロールは、Amazon EC2 のサービスエンドポイントが各 VPC に対して作成されているかどうかをチェックします。Amazon EC2 サービス用に作成された VPC エンドポイントが VPC に作成されていない場合、コントロールは失敗します。

VPC のセキュリティ体制を強化するために、インターフェイス VPC エンドポイントを使用するように Amazon EC2 を設定できます。インターフェイスエンドポイントはAWS PrivateLinkを使用します。これは、Amazon EC2 API オペレーションにプライベートにアクセスすることを可能にするテクノロジーです。VPC および Amazon EC2 間のすべてのネットワークトラフィックを Amazon ネットワークに限定します。エンドポイントは同じリージョン内でのみサポートされるため、別のリージョンで VPC とサービス間のエンドポイントを作成することはできません。これにより、他のリージョンへの意図しない Amazon EC2 API 呼び出しを防ぐことができます。

Amazon EC2 の VPC エンドポイントの作成の詳細については、「」を参照してください。Amazon EC2 とインターフェイス VPC エンドポイントLinux インスタンス用 Amazon EC2 ユーザーガイド

Remediation

この問題を解決するには、Amazon EC2 へのインターフェイス VPC エンドポイントを作成します。

Amazon VPC コンソールから Amazon EC2 へのインターフェイスエンドポイントを作成するには

  1. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。

  2. ナビゲーションペインで、[エンドポイント] を選択します。

  3. [Create endpoint] (エンドポイントの作成) を選択します。

  4. [Service category] (サービスカテゴリ) で、[AWS services] (AWS のサービス) を選択します。

  5. を使用する場合サービス名で、com.amazonaws. <region>ec2

  6. を使用する場合タイプで、インターフェイス

  7. 以下の情報を入力します。

    1. [VPC] で、エンドポイントを作成する先の VPC を選択します。

    2. [Subnets] で、エンドポイントネットワークインターフェイスを作成する先のサブネット (アベイラビリティーゾーン) を選択します。一部のアベイラビリティーゾーンですべてのアベイラビリティーゾーンでサポートされていない場合があります。AWSのサービス。

    3. インターフェイスエンドポイントのプライベート DNS を有効にするには、のチェックボックスを選択します。DNS 名を有効化。デフォルトでは、このオプションは有効になっています。

      プライベート DNS を使用するには、VPC の次の属性を true に設定する必要があります。

      • enableDnsHostnames

      • enableDnsSupport

      詳細については、Amazon VPC ユーザーガイドの「VPC の DNS サポートを表示および更新する」を参照してください。

    4. [Security group] で、エンドポイントネットワークインターフェイスに関連付けるセキュリティグループを選択します。

    5. (オプション) タグを追加または削除します。タグを追加するには、[] を選択します。タグの追加[] を選択し、次の作業を行います。

      • を使用する場合キー] で、タグ名を入力します。

      • を使用する場合] で、タグ値を入力します。

    6. タグを削除するには、削除ボタンを選択します (x) をタグの右側にキーおよび

  8. [Create endpoint (エンドポイントの作成)] を選択します。

インターフェイス VPC エンドポイントポリシーを作成するには

Amazon EC2 API へのアクセスをコントロールするために VPC エンドポイントにポリシーをアタッチすることができます。このポリシーでは、以下を指定します。

  • アクションを実行できるプリンシパル

  • 実行可能なアクション

  • このアクションを実行できるリソース

VPC エンドポイントポリシーの作成の詳細については、「」を参照してください。Amazon EC2 とインターフェイス VPC エンドポイントLinux インスタンス用 Amazon EC2 ユーザーガイド

[EC2.15] EC2 サブネットはパブリック IP アドレスを自動的に割り当てるべきではありません

カテゴリ: 保護 > ネットワークセキュリティ

緊急度: ミディアム

リソースタイプ: AWS::EC2::Subnet

AWS Config ルール: subnet_auto_assign_public_ip_disabled

パラメータ: なし

このコントロールは、Amazon Virtual Private Cloud (Amazon VPC) サブネットのパブリック IP の割り当てに、MapPublicIpOnLaunchに設定します。FALSE。フラグがに設定されている場合、コントロールが通過します。FALSE

サブネットで作成されたネットワークインターフェイスがパブリック IPv4 アドレスを自動的に受信するかどうかを判断する属性が、すべてのサブネットにあります。この属性が有効になっているサブネットで起動されるインスタンスには、プライマリアネットワークインターフェイスに割り当てられるパブリック IP アドレスが割り当てられます。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アジアパシフィック (大阪)

  • 中国 (北京)

  • 中国 (寧夏)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

Amazon VPC コンソールからサブネットを設定できます。

パブリック IP アドレスを割り当てないようにサブネットを構成するには

  1. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。

  2. ナビゲーションペインで、[Subnets (サブネット)] を選択します。

  3. サブネットを選択し、[] を選択します。サブネットアクション,自動割り当て IP 設定の変更

  4. をクリアするパブリック IPv4 アドレスの自動割り当てを有効にするチェックボックスをオンにして、保存

[EC2.16] 未使用のネットワークアクセスコントロールリストを削除する必要があります

カテゴリ: 防止する > ネットワークセキュリティ

緊急度:

リソースタイプ: AWS::EC2::NetworkAcl

AWS Config ルール: vpc_network_acl_unused_check

パラメータ: なし

このコントロールは、未使用のネットワークアクセスコントロールリスト (ACL) があるかどうかを確認します。

コントロールは、リソースのアイテム構成をチェックします。AWS::EC2::NetworkAclおよびネットワーク ACL の関係を決定します。

ネットワーク ACL の VPC のみのリレーションシップの場合、コントロールは失敗します。

他のリレーションシップがリストされている場合、コントロールは通過します。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アジアパシフィック (大阪)

  • 中国 (北京)

  • 中国 (寧夏)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

未使用のネットワーク ACL を削除する方法については、「」を参照してください。ネットワーク ACL の削除Amazon VPC User Guide

[EC2.17] EC2 インスタンスは複数の ENI を使用すべきではない

カテゴリ: ネットワークセキュリティ

緊急度:

リソースタイプ: AWS::EC2::Instance

AWS Config ルール: ec2_instance_multiple_eni_check

パラメータ:

  • Adapterids(オプション) — EC2 インスタンスにアタッチされているネットワークインターフェイス ID のリスト

このコントロールは、EC2 インスタンスが複数のElastic Network Interfaces(ENI)またはElastic Fabric Adapter(EFA)を使用しているかどうかをチェックします。このコントロールは、単一のネットワークアダプタが使用されている場合に渡されます。コントロールには、許可される ENI を識別するためのオプションのパラメータリストが含まれています。

複数の ENI がデュアルホームインスタンスを引き起こす可能性があります。つまり、複数のサブネットを持つインスタンス。これにより、ネットワークセキュリティの複雑性が増し、意図しないネットワークパスとアクセスが発生する可能性があります。

このコントロールは、Amazon EKS クラスターに属する Amazon EKS クラスターに複数の ENI がある場合にも失敗します。複数の ENI を持つ EC2 インスタンスを Amazon EKS クラスターの一部として使用する必要がある場合は、それらの結果を抑制できます。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アジアパシフィック (大阪)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

この問題を解決するには、追加の ENI をデタッチします。

ネットワークインターフェイスをデタッチするには

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

  2. [ネットワークとセキュリティ] で、[ネットワークインターフェイス] を選択します。

  3. 非準拠インスタンス ID でリストをフィルタリングして、関連付けられた ENI を表示します。

  4. 削除する ENI を選択します。

  5. からのアクション[] メニューで、[]Detach

  6. プロンプトが表示された場合次のネットワークインターフェイスをデタッチしてもよろしいですか?で、Detach

[EC2.18] セキュリティグループでは、許可されたポートに対して制限のない着信トラフィックのみを許可する必要があります

カテゴリ: 保護-セキュアなネットワーク設定 > セキュリティグループの設定

緊急度:

リソースタイプ: AWS::EC2::SecurityGroup

AWS Config ルール: vpc_sg_open_only_to_authorized_ports

パラメータ:

  • authorizedTcpPorts(オプション):無制限のアクセスを許可するポートのカンマ区切りリスト。例: '80, 443'。 このルールでは、のデフォルト値authorizedTcpPortsは80と443です。

このコントロールは、使用中のセキュリティグループが、無制限の着信トラフィックを許可するかどうかを確認します。オプションで、ルールは、ポート番号がauthorizedTcpPortsパラメータ。

  • セキュリティグループルールポート番号で無制限の着信トラフィックが許可されているが、ポート番号がで指定されている場合authorizedTcpPortsとすると、コントロールは通過します。authorizedTcpPorts のデフォルト値は 80, 443 です。

  • セキュリティグループルールポート番号で無制限の着信トラフィックが許可されているが、ポート番号がで指定されていない場合authorizedTcpPortsパラメータを入力すると、コントロールは失敗します。

  • パラメータを使用しない場合、制限のないインバウンドルールを持つセキュリティグループに対して制御が失敗します。

セキュリティグループは、への入力および出力ネットワークトラフィックのステートフルフィルタリングを提供しますAWS。セキュリティグループのルールは、最小特権アクセスのプリンシパルに従う必要があります。無制限アクセス(IP アドレスに /0 サフィックス)を使用すると、ハッキング、サービス拒否攻撃、データ損失などの悪意のあるアクティビティの可能性が高まります。

ポートが特に許可されていない限り、ポートは制限のないアクセスを拒否する必要があります。

注記

このコントロールは、アジアパシフィック (大阪) ではサポートされていません。

Remediation

セキュリティグループを変更する方法については、「」を参照してください。ルールの追加、削除、更新Amazon VPC User Guide

[EC2.19] セキュリティグループは、リスクの高いポートへの無制限アクセスを許可すべきではない

カテゴリ: 保護 > 制限付きネットワークアクセス

緊急度:

リソースタイプ: AWS::EC2::SecurityGroup

AWS Config ルール: vpc-sg-restricted-common-ports (Security Hub が開発したカスタムルール)

パラメータ: なし

このコントロールは、最も高いリスクを持つ指定されたポートに対して、セキュリティグループの無制限着信トラフィックがアクセス可能かどうかを確認します。セキュリティグループのどのルールでも、これらのポートに対して 0.0.0.0/0 からの入力トラフィックを許可しない場合、このコントロールは通過します。

無制限アクセス (0.0.0.0/0) により、ハッキング、サービス拒否攻撃、データ損失などの悪意のあるアクティビティの可能性が高まります。

セキュリティグループは、AWS リソースへの入力および出力ネットワークトラフィックのステートフルフィルタリングを提供します。セキュリティグループでは、次のポートへの無制限の入力を許可しません。

  • 3389 (RDP)

  • 20, 21 (FTP)

  • 22 (SSH)

  • 23 (テルネット)

  • 110 (POP3)

  • 143 (イマップ)

  • 3306 (MySQL)

  • 8080 (プロキシ)

  • 1433年、1434 (MSSQL)

  • 9200か9300 (OpenSearch)

  • 5601 (オープンサーチダッシュボード)

  • 25 (SMTP)

  • 445 (CIFS)

  • 135 (RPC)

  • 4333 (ahsp)

  • 5432 (postgreSQL)

  • 5500 (fcp-addr-srvr1)

Remediation

セキュリティグループからルールを削除する方法の詳細については、「」を参照してください。セキュリティグループからのルールの削除Linux インスタンス用 Amazon EC2 ユーザーガイド

[ECS.1] Amazon ECS タスク定義には、安全なネットワークモードとユーザー定義が必要です

カテゴリ: 保護-セキュアなアクセス管理

緊急度:

リソースタイプ: AWS::ECS::TaskDefinition

AWS Config ルール: ecs-task-definition-user-for-host-mode-check

パラメータ:

  • SkipInactiveTaskDefinitions: true

このコントロールは、ホストネットワーキングモードを持つアクティブな Amazon ECS タスク定義にもprivilegedまたはuserコンテナの定義。ホストネットワークモードとコンテナ定義を持つタスク定義では、コントロールが失敗します。privileged=falseまたは空でuser=rootが空です。

タスク定義に昇格された権限がある場合、お客様がその構成に特にオプトインしているためです。このコントロールは、タスク定義でホストネットワークが有効になっていても、お客様が昇格された特権を選択していない場合に、予期しない特権の昇格をチェックします。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アジアパシフィック (大阪)

  • 中国 (北京)

  • 中国 (寧夏)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

タスク定義を更新する方法については、「」を参照してください。タスク定義の更新Amazon Elastic Container Service デ

タスク定義を更新しても、前のタスク定義から起動された実行中のタスクは更新されません。実行中のタスクを更新するには、新しいタスク定義を使用してタスクを再デプロイする必要があります。

[ECS.2] Amazon ECS サービスにはパブリック IP アドレスを自動的に割り当てるべきではありません

カテゴリ: 保護-セキュアなネットワーク構成 > リソースはパブリックアクセスできません

緊急度:

リソースタイプ: AWS::ECS::Service

AWS Configルール: ecs-service-assign-public-ip-disabled (Security Hub が開発したカスタムルール)

パラメータ:

  • exemptEcsServiceArns (オプション). Security Hub はこのパラメータを設定しません。このルールから除外する Amazon ECS サービスの ARN のカンマ区切りリスト。

    このルールはCOMPLIANTAmazon ECS サービスがAssignPublicIPに設定します。ENABLEDおよびは、このパラメータリストで指定します。

    このルールはNON_COMPLIANTAmazon ECS サービスがAssignPublicIPに設定します。ENABLEDおよびは、このパラメータリストでは指定されていません。

このコントロールは、パブリック IP アドレスを自動的に割り当てるように設定されているかどうかをチェックします。このコントロールは次の場合に失敗します。AssignPublicIPENABLED。このコントロールは次の場合に渡されます。AssignPublicIPDISABLED

パブリック IP アドレスは、インターネットから到達可能な IP アドレスです。パブリック IP アドレスを使用して Amazon ECS インスタンスを起動すると、Amazon ECS インスタンスはインターネットから到達可能です。Amazon ECS サービスは、コンテナアプリケーションサーバーへの意図しないアクセスを可能にする可能性があるため、パブリックにアクセスすることはできません。

注記

このコントロールは、アジアパシフィック (大阪) リージョンではサポートされていません。

Remediation

パブリック IP の自動割り当てを無効にするには、を参照してください。VPC とセキュリティグループ設定をサービスに設定するにはAmazon Elastic Container Service デ

[EFS.1] を使用して、保管中のファイルデータを暗号化するように設定する必要がありますAWS KMS

カテゴリ: 保護-データ保護-保管中のデータの暗号化

緊急度: ミディアム

リソースタイプ: AWS::EFS::FileSystem

AWS Config ルール: efs-encrypted-check

パラメータ: なし

このコントロールは、Amazon Elastic File System が、を使用してファイルデータを暗号化するように設定されているかどうかを確認します。AWS KMS。次の場合、チェックは失敗します。

このコントロールでは、KmsKeyIdのパラメータefs-encrypted-checkEncrypted の値のみをチェックします。

Amazon EFS の機密データのセキュリティを強化するには、暗号化されたファイルシステムを作成する必要があります。Amazon EFS は、保管時のファイルシステムの暗号化をサポートしています。Amazon EFS ファイルシステムを作成する場合、保管時のデータの暗号化を有効にすることができます。Amazon EFS 暗号化の詳細については、「」を参照してください。Amazon EFS でのデータ暗号化Amazon Elastic File System ユーザーガイド

注記

このコントロールは、アフリカ (ケープタウン) または EU (ミラノ) ではサポートされていません。

Remediation

新しい Amazon EFS ファイルシステムを暗号化する方法の詳細については、「」を参照してください。保管時のデータの暗号化Amazon Elastic File System ユーザーガイド

[EFS.2] Amazon EFS ボリュームはバックアッププラン内にある必要があります

カテゴリ: リカバリ > レジリエンス > Backup

緊急度: ミディアム

リソースタイプ: AWS::EFS::FileSystem

AWS Config ルール: efs_in_backup_plan

パラメータ: なし

このコントロールは、Amazon Elastic File System (Amazon EFS) ファイルシステムがのバックアッププランに追加されているかどうかを確認します。AWS Backup。Amazon EFS ファイルシステムがバックアッププランに含まれていない場合、コントロールは失敗します。

バックアッププランに EFS ファイルシステムを組み込むと、データの削除やデータの損失からデータを保護できます。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アフリカ (ケープタウン)

  • ヨーロッパ (ミラノ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

この問題を解決するには、ファイルシステムを更新して自動バックアップを有効にします。

既存のファイルシステムの自動バックアップを有効にするには

  1. Amazon Elastic File System コンソール (https://console.aws.amazon.com/efs/) を開きます。

  2. リポジトリの []ファイルシステムページで、自動バックアップを有効にするファイルシステムを選択します。

    -ファイルシステムの詳細[] ページが表示されます。

  3. []全般で、編集

  4. 自動バックアップの有効化自動バックアップの有効化

  5. [変更を保存] を選択します。

詳細については、「」を参照してください。を使用するAWS BackupAmazon EFS でAmazon Elastic File System ユーザーガイド

[ElasticBeanStalk.1] Elastic Beanstalk 環境では、拡張ヘルスレポートを有効にする必要があります

カテゴリ: 検出-検出サービス-アプリケーション監視

緊急度:

リソースタイプ: AWS::ElasticBeanstalk::Environment

AWS Config ルール: beanstalk_enhanced_health_reporting_enabled

パラメータ: なし

このコントロールは、で拡張ヘルスレポートが有効になっているかどうかを確認しますAWS Elastic Beanstalk環境。

Elastic Beanstalk 拡張ヘルスレポートにより、基盤となるインフラストラクチャの健全性の変化に対するより迅速な対応が可能になります。これらの変更により、アプリケーションの可用性が失われる可能性があります。

Elastic Beanstalk 拡張ヘルスレポートは、特定された問題の重大度を測定し、調査すべき考えられる原因を特定するためのステータス記述子を提供します。サポートされている Amazon マシンイメージ(AMI)に含まれる Elastic Beanstalk ヘルスエージェントは、環境 EC2 インスタンスのログとメトリックスを評価します。

詳細については、「」を参照してください。拡張状態ヘルスレポートおよびモニタリングAWS Elastic Beanstalkデベロッパーガイド

注記

このコントロールは、次のリージョンではサポートされていません。

  • アジアパシフィック (大阪)

  • 中国 (北京)

  • 中国 (寧夏)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

拡張ヘルスレポートを有効にする手順については、「」を参照してください。Elastic Beanstalk コンソールを使用した拡張ヘルスレポートの有効化AWS Elastic Beanstalkデベロッパーガイド

[ElasticBeanStalk.2] Elastic Beanstalk マネージドプラットフォームのアップデートを有効にする必要があります

カテゴリ: 検出 > 脆弱性、パッチ、バージョン管理

緊急度:

リソースタイプ: AWS::ElasticBeanstalk::Environment

AWS Config ルール: elastic_beanstalk_managed_updates_enabled

パラメータ: なし

このコントロールは、Elastic Beanstalk 環境でマネージドプラットフォームの更新が有効になっているかどうかをチェックします。

マネージドプラットフォーム更新を有効にすると、環境で使用可能な最新のプラットフォームの修正、更新、および機能がインストールされます。パッチのインストールを最新の状態に保つことは、システムを保護する上で重要なステップです。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アジアパシフィック (大阪)

  • 中国 (北京)

  • 中国 (寧夏)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

マネージドプラットフォームの更新を有効にする手順については、「」を参照してください。[マネージドプラットフォームの更新] で、マネージドプラットフォームの更新を設定するにはAWS Elastic Beanstalkデベロッパーガイド

[ELB.3] Classic Load Balancer のリスナーは HTTPS または TLS ターミネーションで設定する必要があります

カテゴリ: 保護-転送中のデータの暗号化

緊急度: ミディアム

リソースタイプ: AWS::ElasticLoadBalancing::LoadBalancer

AWS Config ルール: elb_tls_https_listeners_only

パラメータ: なし

このコントロールは、Classic Load Balancer リスナーが、フロントエンド (クライアントからロードバランサー) 接続用に HTTPS または TLS プロトコルを使用して設定されているかどうかを確認します。このコントロールは、Classic Load Balancer にリスナーがある場合に適用されます。Classic Load Balancer にリスナーが設定されていない場合、コントロールは結果を報告しません。

Classic Load Balancer リスナーがフロントエンド接続の TLS または HTTPS で構成されている場合、コントロールは通過します。

リスナーがフロントエンド接続の TLS または HTTPS で構成されていない場合、コントロールは失敗します。

ロードバランサーの使用を開始する前に、1 つ以上のリスナーを追加する必要があります。リスナーとは、設定したプロトコルとポートを使用して接続リクエストをチェックするプロセスです。リスナーは、HTTP プロトコルと HTTPS/TLS プロトコルの両方をサポートします。ロードバランサーが転送中に暗号化と復号化を行うように、常に HTTPS または TLS リスナーを使用する必要があります。

Remediation

この問題を解決するには、TLS または HTTPS プロトコルを使用するようにリスナーを更新します。

すべての非準拠リスナーを TLS/HTTPS リスナーに変更するには

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

  2. ナビゲーションペインで、[Load Balancers] を選択します。次に、Classic Load Balancer を選択します。

  3. [リスナー[] タブをクリックし、[] を選択します。編集

  4. Load Balancer プロトコルが HTTPS または SSL に設定されていないすべてのリスナーについて、設定を HTTPS または SSL に変更します。

  5. 変更されたすべてのリスナーについては、SSL 証明書で、変更

  6. 変更されたすべてのリスナーに対して、ACM から証明書を選択する

  7. から証明書を選択します。証明書選択します。次に、[Save ] を選択します。

  8. すべてのリスナーを更新したら、保存

[ELB.4] HTTP ヘッダーを削除するようにアプリケーションロードバランサーを設定する必要があります

カテゴリ: 保護 > ネットワークセキュリティ

緊急度: ミディアム

リソースタイプ: AWS::ElasticLoadBalancing::LoadBalancer

AWS Config ルール: alb_http_drop_invalid_header_enabled

パラメータ: なし

このコントロールは評価しますAWSアプリケーションロードバランサ(ALB)は、無効な HTTP ヘッダーを削除するように構成されていることを確認します。値がの場合、コントロールは失敗します。routing.http.drop_invalid_header_fields.enabledは、 に設定されます。false

デフォルトでは、ALB は無効な HTTP ヘッダー値をドロップするように設定されていません。これらのヘッダー値を削除すると、HTTP desync 攻撃を防ぐことができます。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アフリカ (ケープタウン)

  • アジアパシフィック (大阪)

  • ヨーロッパ (ミラノ)

Remediation

この問題を解決するには、無効なヘッダーフィールドを削除するようにロードバランサーを構成します。

無効なヘッダーフィールドを削除するようにロードバランサーを設定するには

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

  2. ナビゲーションペインで、[Load Balancers (ロードバランサー)] を選択します。

  3. Application Load Balancer を選択します

  4. 送信元アクションで、属性を編集する

  5. []無効なヘッダーフィールドの削除で、の有効化

  6. [Save] を選択します。

[ELB.5] アプリケーションおよびクラシックロードバランサーのロギングを有効にする必要があります

カテゴリ: ログ記録

緊急度: ミディアム

リソースタイプ: AWS::ElasticLoadBalancing::LoadBalancer

AWS Config ルール: elb-logging-enabled

パラメータ: なし

このコントロールは、Application Load Balancer とClassic Load Balancer サでログが有効になっているかどうかをチェックします。コントロールは、次の場合に失敗しますaccess_logs.s3.enabledfalse

Elastic Load Balancing は、ロードバランサーに送信されるリクエストについての詳細情報をキャプチャしたアクセスログを提供します。各ログには、リクエストを受け取った時刻、クライアントの IP アドレス、レイテンシー、リクエストのパス、サーバーレスポンスなどの情報が含まれます。これらのアクセスログを使用して、トラフィックパターンの分析や、問題のトラブルシューティングを行うことができます。

詳細については、次を参照してください。Classic Load Balancer のアクセスログClassic Load Balancer のユーザーガイド

Remediation

この問題を解決するには、ロードバランサーを更新してログを有効にします。

アクセスログを有効にするには

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

  2. ナビゲーションペインで、[Load Balancers (ロードバランサー)] を選択します。

  3. Application Load Balancer を選択します

  4. 送信元アクションで、属性を編集する

  5. []アクセスログで、の有効化

  6. S3 の場所を入力します。この場所は存在することも、作成することもできます。プレフィックスを指定しない場合、アクセスログは S3 バケットのルートに保存されます。

  7. [Save] を選択します。

[ELB.6] Application Load Balancer 削除に対する保護を有効にする必要があります

カテゴリ: リカバリ > レジリエンス > 高可用性

緊急度: ミディアム

リソースタイプ: AWS::ElasticLoadBalancingV2::LoadBalancer

AWS Config ルール: elb-deletion-protection-enabled

パラメータ: なし

このコントロールは、Application Load Balancer で削除保護が有効になっているかどうかを確認します。削除保護が設定されていない場合、コントロールは失敗します。

削除保護を有効にして、Application Load Balancer を削除から保護します。

Remediation

ロードバランサーが誤って削除されるのを防ぐため、削除保護を有効にできます。デフォルトでは、ロードバランサーで削除保護が無効になっています。

ロードバランサーの削除保護を有効にした場合、ロードバランサーを削除する前に削除保護を無効にする必要があります。

コンソールから削除保護を有効にするには

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

  2. ナビゲーションペインの [LOAD BALANCING] で [ロードバランサー] を選択します。

  3. ロードバランサーを選択します。

  4. [Description] タブで、[Edit attributes] を選択します。

  5. リポジトリの []ロードバランサーの属性の編集[] ページで、[]削除保護を有効にする[] を選択してから、保存

  6. [Save] を選択します。

詳細については、次を参照してください。削除保護Application Load Balancer のユーザーガイド

[ELB.7] クラシックロードバランサは接続ドレインを有効にする必要があります

カテゴリ: リカバリ-レジリエンス

緊急度: ミディアム

リソースタイプ: AWS::ElasticLoadBalancing::LoadBalancer

AWS Config ルール: elb-connection-draining-enabled (Security Hub が開発したカスタムルール)

パラメータ: なし

このコントロールは、クラシックロードバランサが接続ドレインが有効になっているかどうかをチェックします。

Classic Load Balancers でコネクションドレインを有効にすると、ロードバランサーは、登録解除中のインスタンスまたは異常の発生したインスタンスへのリクエストの送信を停止します。既存の接続を開いたままにします。これは、Auto Scaling グループのインスタンスで、接続が突然切断されないようにするために特に便利です。

Remediation

クラシックロードバランサで接続のドレインを有効にするには、の手順に従います。Classic Load Balancer の Connection Draining の設定Classic Load Balancer のユーザーガイド

[ELBv2.1] Application Load Balancer は、すべての HTTP リクエストを HTTPS にリダイレクトするように設定する必要があります

カテゴリ: 保護-転送中のデータの暗号化

緊急度: ミディアム

リソースタイプ: AWS::ElasticLoadBalancingV2::LoadBalancer

AWS Config ルール: alb-http-to-https-redirection-check

パラメータ: なし

このコントロールは、HTTP から HTTPS へのリダイレクトがアプリケーションロードバランサーのすべての HTTP リスナーで設定されているかどうかを確認します。アプリケーションロードバランサの 1 つまたは複数の HTTP リスナーに HTTP から HTTPS へのリダイレクトが設定されていない場合、チェックは失敗します。

Application Load Balancer の使用を開始する前に、1 つまたは複数のリスナーを追加する必要があります。リスナーとは、設定したプロトコルとポートを使用して接続リクエストをチェックするプロセスです。リスナーは、HTTP プロトコルと HTTPS プロトコルの両方をサポートします。HTTPS リスナーを使用して、暗号化と復号化の作業をApplication Load Balancer にオフロードできます。Application Load Balancer でリダイレクトアクションを使用して、クライアント HTTP リクエストをポート 443 の HTTPS リクエストにリダイレクトし、転送中の暗号化を適用する必要があります。

詳細については、次を参照してください。Application Load Balancer のリスナーApplication Load Balancer のユーザーガイド

注記

このコントロールは、アフリカ (ケープタウン) または EU (ミラノ) ではサポートされていません。

Remediation

この問題を解決するには、ロードバランサーを更新して HTTP リクエストをリダイレクトします。

HTTP 要求をApplication Load Balancer で HTTPS にリダイレクトするには

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

  2. ナビゲーションペインで、[Load Balancers (ロードバランサー)] を選択します。

  3. Application Load Balancer を選択します

  4. [リスナー] タブを選択します。

  5. HTTP リスナー (ポート 80 TCP) を選択し、[編集] を選択します。

  6. 既存のルールがある場合は、それを削除する必要があります。それ以外の場合は、[Add action (アクションを追加)] を選択し、[Redirect to... (... にリダイレクト)] を選択します。

  7. [HTTPS] を選択し、「443」と入力します。

  8. 円記号のチェックマークを選択し、[更新] を選択します。

[EMR.1] Amazon EMR クラスターマスターノードはパブリック IP アドレスを持つべきではありません

カテゴリ: 保護-セキュアなネットワーク設定

緊急度:

リソースタイプ: AWS::EMR::Cluster

AWS Config ルール: emr-master-no-public-ip

パラメータ: なし

このコントロールは、Amazon EMR クラスターのマスターノードにパブリック IP アドレスがあるかどうかをチェックします。

マスターノードにインスタンスのいずれかに関連付けられたパブリック IP アドレスがある場合、コントロールは失敗します。パブリック IP アドレスは、PublicIpのフィールドNetworkInterfacesインスタンスの設定。このコントロールEMR、RUNNINGまたはWAITING状態。

注記

このコントロールは、アフリカ (ケープタウン) または EU (ミラノ) ではサポートされていません。

Remediation

起動中に、デフォルトサブネットまたはデフォルト以外のサブネット内のインスタンスがパブリック IPv4 アドレスを割り当てられるかどうかを制御できます。

デフォルトで、この属性はデフォルトで設定されています。true。デフォルト以外のサブネットでは IPv4 パブリックアドレッシング属性がに設定されています。falseは、Amazon EC2 インスタンス起動ウィザードによって作成された場合を除きます。この場合、ウィザードは属性をtrue

IPv4 パブリックアドレッシング属性がに設定されているプライベートサブネットを持つ VPC でクラスターを起動する必要があります。false

起動後に、手動でパブリック IPv4 アドレスの割り当てをインスタンスから解除することはできません。

この結果を修正するには、VPC プライベートサブネットに新しいクラスターを作成する必要があります。VPC プライベートサブネットでクラスターを起動する方法については、「」を参照してください。VPC でクラスターを起動するAmazon EMR 管理ガイド

[ES.1] Elasticsearch ドメインは保存時の暗号化を有効にする必要があります

カテゴリ: 保護-データ保護-保管中のデータの暗号化

緊急度: ミディアム

リソースタイプ: AWS::Elasticsearch::Domain

AWS Config ルール: elasticsearch-encrypted-at-rest

パラメータ: なし

このコントロールは、Elasticsearch ドメインで保管時の暗号化設定が有効になっているかどうかを確認します。保存時の暗号化が有効になっていない場合、チェックは失敗します。

で機密データのセキュリティレイヤを追加する場合OpenSearchでは、OpenSearchの保管時に暗号化されます。Elasticsearch ドメインは、保管時のデータの暗号化を提供します。この機能によって、AWS KMS を使用して、暗号化キーが保存および管理されます。暗号化を実行するには、256 ビットキー (AES-256) を使用した高度な暗号化標準アルゴリズムを使用します。

詳細を確認するトピックOpenSearch保管時の暗号化 (を参照)の保管時のデータの暗号化Amazon OpenSearch ServiceAmazon OpenSearch Serviceデベロッパーガイド

注記

特定のインスタンスタイプ (など)t.smallおよびt.mediumでは、保管時のデータの暗号化をサポートしていません。詳細については、「」を参照してください。サポートされるインスタンスタイプAmazon OpenSearch Serviceデベロッパーガイド

Remediation

デフォルトでは、ドメインの保管時のデータは暗号化されず、既存のドメインでこの機能を使用するように設定することはできません。

この機能を有効にするには、別のドメインを作成してデータを移行する必要があります。ドメインの作成については、「」を参照してください。Amazon OpenSearch Serviceデベロッパーガイド

保管時のデータの暗号化には OpenSearch Service 5.1 以降が必要です。の保管中のデータの暗号化の詳細については、「」を参照してください。OpenSearch Service「」を参照してください。Amazon OpenSearch Serviceデベロッパーガイド

[ES.2] Elasticsearch ドメインは VPC 内に存在する必要があります

カテゴリ: 保護-セキュアなネットワーク構成 > VPC 内のリソース

緊急度: 非常事態

リソースタイプ: AWS::Elasticsearch::Domain

AWS Config ルール: elasticsearch-in-vpc-only

パラメータ: なし

このコントロールは、Elasticsearch ドメインが VPC 内にあるかどうかをチェックします。パブリックアクセスを決定するための VPC サブネットルーティング設定を評価しません。Elasticsearch ドメインがパブリックサブネットにアタッチされていないことを確認する必要があります。「」を参照してください。リソースベースのポリシーAmazon OpenSearch Serviceデベロッパーガイド。また、推奨されるベストプラクティスに従って VPC が設定されていることを確認する必要があります。「」を参照してください。VPC のセキュリティのベストプラクティスAmazon VPC User Guide

VPC 内にデプロイされた Elasticsearch ドメインは、プライベート経由で VPC リソースと通信できます。AWSネットワーク、パブリックインターネットを横断する必要はありません。この設定では、送信中のデータへのアクセスを制限することにより、セキュリティポスチャが向上します。VPC は、ネットワーク ACL やセキュリティグループを含む Elasticsearch ドメインへのアクセスを保護するための多数のネットワークコントロールを提供します。Security Hub では、これらのコントロールを利用するために、パブリック Elasticsearch ドメインを VPC に移行することをお勧めします。

Remediation

パブリックエンドポイントを使用してドメインを作成する場合、後で VPC 内にドメインを配置することはできません。代わりに、新規のドメインを作成して、データを移行する必要があります。逆の場合も同様です。VPC 内にドメインを作成する場合、パブリックエンドポイントを持つことはできません。代わりに、別のドメインを作成するか、このコントロールを無効にする必要があります。

「」を参照してください。を起動するAmazon OpenSearch ServiceVPC 内のドメインAmazon OpenSearch Serviceデベロッパーガイド

[ES.3] Elasticsearch ドメインはノード間で送信されるデータを暗号化する必要があります

カテゴリ: 保護-転送中のデータの暗号化

緊急度: ミディアム

リソースタイプ: AWS::Elasticsearch::Domain

AWS Config ルール: elasticsearch-node-to-node-encryption-check

パラメータ: なし

このコントロールは、Elasticsearch ドメインでノード間の暗号化が有効になっているかどうかを確認します。

HTTPS (TLS) を使用すると、潜在的な攻撃者が中間者攻撃または同様の攻撃を使用してネットワークトラフィックを盗聴または操作することを防止できます。HTTPS (TLS) 経由の暗号化された接続のみを許可する必要があります。Elasticsearch ドメインに対してノード間の暗号化を有効にすると、クラスター内通信が確実に転送中に暗号化されます。

この設定には、パフォーマンス上のペナルティが発生する可能性があります。このオプションを有効にする前に、パフォーマンスのトレードオフを認識してテストする必要があります。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アフリカ (ケープタウン)

  • 中国 (北京)

  • 中国 (寧夏)

  • ヨーロッパ (ミラノ)

Remediation

ノード間の暗号化は、新しいドメインでのみ有効にできます。この結果を修正するには、まず新しいドメインを作成するノード間の暗号化チェックボックスがオンになっています。次に、フォロースナップショットを使用してデータを移行するをクリックして、データを新しいドメインに移行します。

[ES.4] CloudWatch Logs への Elasticsearch ドメインエラーログを有効にする必要があります

カテゴリ: 識別-ログ記録

緊急度: ミディアム

リソースタイプ: AWS::Elasticsearch::Domain

AWS Config ルール: elasticsearch_logs_to_cloudwatch

パラメータ:

  • logtype = 'error'

このコントロールは、CloudWatch Logs にエラーログを送信するように Elasticsearch ドメインが設定されているかどうかをチェックします。

Elasticsearch ドメインのエラーログを有効にし、保持と応答のためにそれらのログを CloudWatch Logs に送信する必要があります。ドメインエラーログは、セキュリティとアクセス監査に役立ち、可用性の問題を診断するのに役立ちます。

注記

このコントロールは、次のリージョンではサポートされていません。

  • 中国 (北京)

  • 中国 (寧夏)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

ログの発行を有効にする方法については、「」を参照してください。ログ公開の有効化 (コンソール)Amazon OpenSearch Serviceデベロッパーガイド

[ES.5] Elasticsearch ドメインで監査ログが有効になっている必要があります

カテゴリ: 識別-ログ記録

緊急度: ミディアム

リソースタイプ: AWS::Elasticsearch::Domain

AWS Config ルール: elasticsearch-audit-logging-enabled (Security Hub が開発したカスタムルール)

パラメータ:

  • cloudWatchLogsLogGroupArnList (オプション). Security Hub はこのパラメータを設定しません。監査ログ用に設定する必要がある CloudWatch Logs ロググループのカンマ区切りリスト。

    このルールはNON_COMPLIANTElasticsearch ドメインの CloudWatch Logs ロググループがこのパラメーターリストで指定されていない場合。

このコントロールは、Elasticsearch ドメインで監査ログが有効になっているかどうかをチェックします。Elasticsearch ドメインで監査ログが有効になっていない場合、このコントロールは失敗します。

監査ログは高度にカスタマイズ可能です。これにより、認証の成功と失敗、リクエストなど、Elasticsearch クラスターでのユーザーアクティビティを追跡できます。OpenSearch、インデックスの変更、および受信検索クエリ。

Remediation

監査ログを有効にする方法については、「」を参照してください。監査ログの有効化Amazon OpenSearch Serviceデベロッパーガイド

[ES.6] Elasticsearch ドメインには少なくとも 3 つのデータノードが必要です

カテゴリ: リカバリ > レジリエンス > 高可用性

緊急度: ミディアム

リソースタイプ: AWS::Elasticsearch::Domain

AWS Config ルール: elasticsearch-data-node-fault-tolerance (Security Hub が開発したカスタムルール)

パラメータ: なし

このコントロールは、Elasticsearch ドメインが少なくとも 3 つのデータノードで構成されているかどうかをチェックします。zoneAwarenessEnabledtrue

Elasticsearch ドメインでは、高可用性とフォールトトレランスのために少なくとも 3 つのデータノードが必要です。少なくとも 3 つのデータノードを持つ Elasticsearch ドメインをデプロイすると、ノードに障害が発生した場合のクラスター操作が保証されます。

Remediation

Elasticsearch ドメイン内のデータノードの数を変更するには

  1. を開くAmazon OpenSearch Serviceでのコンソールhttps://console.aws.amazon.com/es/

  2. []マイドメインで、編集するドメインの名前を選択します。

  3. [Edit domain (ドメインの編集)] を選択します。

  4. []データノード, セットノード数を 3 以上の数値に設定します。

    3 つのアベイラビリティーゾーン展開では、3 つの倍数に設定して、アベイラビリティーゾーン間で均等に分散されるようにします。

  5. [送信] を選択します。

[ES.7] Elasticsearch ドメインは、少なくとも 3 つの専用マスターノードで構成する必要があります

カテゴリ: リカバリ > レジリエンス > 高可用性

緊急度: ミディアム

リソースタイプ: AWS::Elasticsearch::Domain

AWS Config ルール: elasticsearch-primary-node-fault-tolerance (Security Hub が開発したカスタムルール)

パラメータ: なし

このコントロールは、Elasticsearch ドメインが少なくとも 3 つの専用マスターノードで構成されているかどうかをチェックします。ドメインが専用マスターノードを使用しない場合、この制御は失敗します。Elasticsearch ドメインに 5 つの専用マスターノードがある場合、このコントロールは通過します。ただし、3 つ以上のマスターノードを使用することは、可用性リスクを軽減するために不要な場合があり、追加コストが発生します。

Elasticsearch ドメインでは、高可用性と耐障害性を実現するために、少なくとも 3 つの専用マスターノードが必要です。専用マスターノードのリソースは、データノードのブルー/グリーンのデプロイ中に管理すべきノードが追加されるため、負荷がかかることがあります。少なくとも 3 つの専用マスターノードを持つ Elasticsearch ドメインをデプロイすると、ノードに障害が発生した場合に十分なマスターノードのリソース容量とクラスターオペレーションが確保されます。

Remediation

内の専用マスターノードの数を変更するにはOpenSearchドメイン

  1. を開くAmazon OpenSearch Serviceでのコンソールhttps://console.aws.amazon.com/es/

  2. []マイドメインで、編集するドメインの名前を選択します。

  3. [Edit domain (ドメインの編集)] を選択します。

  4. []専用マスターノード, セットインスタンスタイプ目的のインスタンスタイプにします。

  5. 設定マスターノードの数3 以上に等しい。

  6. [送信] を選択します。

[ES.8] Elasticsearch ドメインへの接続は TLS 1.2 を使用して暗号化する必要があります

カテゴリ: 保護-転送中のデータの暗号化

緊急度: ミディアム

リソースタイプ: AWS::Elasticsearch::Domain

AWS Config ルール: elasticsearch-https-required (Security Hub が開発したカスタムルール)

パラメータ: なし

このコントロールは、TLS 1.2 を使用するために Elasticsearch ドメインへの接続が必要かどうかをチェックします。Elasticsearch ドメインの場合、チェックは失敗しますTLSSecurityPolicyはPolicy-min-TLS-1-2-2019-07ではありません。

HTTPS (TLS) を使用すると、潜在的な攻撃者が中間者攻撃または同様の攻撃を使用してネットワークトラフィックを盗聴または操作することを防止できます。HTTPS (TLS) 経由の暗号化された接続のみを許可する必要があります。転送中のデータの暗号化は、パフォーマンスに影響する可能性があります。TLS のパフォーマンスプロファイルと TLS の影響を理解するには、この機能を使用してアプリケーションをテストする必要があります。TLS 1.2 は、TLS の以前のバージョンよりもいくつかのセキュリティ強化を提供します。

Remediation

TLS 暗号化を有効にするには、UpdateDomainConfigAPI オペレーションを構成するDomainEndpointOptionsを設定するためにTLSSecurityPolicy。詳細については、「Amazon OpenSearch Service デベロッパーガイド」を参照してください。

[GuardDuty.1] GuardDuty を有効にする必要があります

カテゴリ: 検出-検出サービス

緊急度:

リソースタイプ: AWSアカウント

AWS Config ルール: guardduty-enabled-centralized

パラメータ: なし

このコントロールは、Amazon GuardDuty アカウントおよびリージョンで Amazon GuardDuty が有効になっているかどうかを確認します。

GuardDuty は、サポートされているすべての GuardDuty を有効にすることが強く推奨されています。AWS地域。このように設定することで、お客様が能動的に使用していないリージョンでも、GuardDuty は、許可されていないアクティビティや異常なアクティビティに関する検索結果をで生成できます。また、GuardDuty は CloudTrail イベントをグローバルに監視することもできます。AWSIAM などのサービス。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アフリカ (ケープタウン)

  • 中国 (北京)

  • 中国 (寧夏)

  • ヨーロッパ (ミラノ)

  • 中東 (バーレーン)

  • AWS GovCloud (米国東部)

Remediation

この問題を修復するには、GuardDuty を有効にします。

GuardDuty を有効にする方法の詳細については、使用方法を含むAWS Organizations複数のアカウントを管理するには、「」を参照してください。GuardDuty の開始方法Amazon GuardDuty ユーザーガイド

[IAM.1] IAM ポリシーでは、完全な「*」管理権限を許可しないでください

カテゴリ: 保護-セキュアなアクセス管理

緊急度:

リソースタイプ: AWS::IAM::Policy

AWS Config ルール: iam-policy-no-statements-with-admin-access

パラメータ: なし

このコントロールは、IAM ポリシーのデフォルトバージョン (カスタマー管理ポリシーとも呼ばれます) に、「効果」のステートメントを含む管理者アクセス権を持っているかどうかをチェックします。「Action」:「Resource」:「Resource」:「Resource」:「Action」:「Resource」

コントロールは、作成したカスタマー管理ポリシーのみをチェックします。インラインチェックは行われず、AWS管理ポリシー。

IAM ポリシーは、ユーザー、グループ、またはロールに付与される権限のセットを定義します。標準的なセキュリティアドバイスに従って、AWS は最小限の特権を付与することをお勧めします。これは、タスクの実行に必要なアクセス許可のみを付与することを意味します。ユーザーが必要とする最小限のアクセス許可セットではなく、完全な管理権限を提供すると、リソースを望ましくない可能性のあるアクションに公開します。

完全な管理権限を許可するのではなく、ユーザーが何をする必要があるのかを決定し、ユーザーが、それらのタスクのみを実行できるポリシーを作成します。最小限のアクセス許可から開始し、必要に応じて追加のアクセス許可を付与します。あまりにも寛大なアクセス許可から始めて、後でそれらを強化しようとしないでください。

を使用したのステートメントを含む IAM ポリシーは、削除する必要があります。"Effect": "Allow" "Action": "*"OVER"Resource": "*"

Remediation

この問題を解決するには、IAM ポリシーを更新して、完全な「*」管理権限を許可しません。

IAM ポリシーを変更するには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [ポリシー] を選択します。

  3. 削除するポリシーの横にあるボタンを選択します。

  4. [Policy actions (ポリシーアクション)] から [Detach (デタッチ)] を選択します。

  5. ポリシーをデタッチする各ユーザーで、ユーザーの横にあるボタンを選択して、[Detach policy (ポリシーのデタッチ)] を選択します。

ポリシーをデタッチしたユーザーが、想定どおりに AWS サービスおよびリソースには引き続きアクセスできることを確認します。

[IAM.2] IAM ユーザーには IAM ポリシーをアタッチしないでください

カテゴリ: 保護-セキュアなアクセス管理

緊急度:

リソースタイプ: AWS::IAM::User

AWS Config ルール: iam-user-no-policies-check

パラメータ: なし

このコントロールは、いずれの IAM ユーザーにもポリシーがアタッチされていないことを確認します。代わりに、IAM ユーザーは IAM グループまたはロールからアクセス権限を継承する必要があります。

デフォルトでは、IAM ユーザー、グループ、ロールにアクセスできません。AWSリソースの使用料金を見積もることができます。IAM ポリシーは、ユーザー、グループ、またはロールに権限を付与します。IAM ポリシーはグループとロールには直接適用しますが、ユーザーには直接適用しません。グループレベルまたはロールレベルで権限を割り当てると、ユーザー数が増えるにつれてアクセス管理の複雑さが軽減されます。アクセス管理の複雑さを軽減することで、プリンシパルが誤って過剰な権限を受け取ったり保持したりする機会を減らすことができます。

このコントロールは、Amazon Simple Email Service (Amazon SES) によって作成された IAM ユーザーに対して失敗した検出結果をで生成します。Amazon SES は、インラインポリシーがアタッチされたユーザーを生成します。これらの調査結果を抑制できます。

Remediation

この問題を解決するには、IAM グループを作成し、そのグループにポリシーを割り当て、ユーザーをグループに追加します。ポリシーは、グループ内の各ユーザーに適用されます。

IAM グループを作成するには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [グループ] を選択し、[Create New Group (新しいグループの作成)] を選択します。

  3. 作成するグループの名前を入力し、[次のステップ] を選択します。

  4. グループに割り当てる各ポリシーを選択し、[次のステップ] を選択します。選択したポリシーには、現在ユーザーアカウントに直接アタッチされているすべてのポリシーが含まれている必要があります。

  5. ユーザーをグループに追加し、そのグループにポリシーを割り当てます。グループ内の各ユーザーには、グループに割り当てられたポリシーが割り当てられます。

  6. [確認] ページで詳細を確認し、[グループの作成] を選択します。

グループ作成の詳細については、「」を参照してください。IAM グループの作成IAM ユーザーガイド

IAM グループにユーザーを追加するには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [グループ] を選択します。

  3. [Group Actions (グループアクション)] で、[Add Users to Group (ユーザーをグループに追加)] を選択します。

  4. グループに追加するユーザーを選択し、[Add Users (ユーザーを追加)] を選択します。

グループへのユーザーの追加方法の詳細については、「」を参照してください。IAM グループ内のユーザーの追加と削除IAM ユーザーガイド

ユーザーに直接アタッチされているポリシーを削除するには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [ユーザー] を選択します。

  3. ポリシーをデタッチするユーザーの User name 列から名前を選択します。

  4. [Attached directly (直接アタッチ)] に一覧表示されている各ポリシーで、ページの右側にある [X] を選択してユーザーからポリシーを削除し、[削除] を選択します。

  5. 想定した通りにユーザーが AWS サービスを利用できることを確認します。

[IAM.3] IAM ユーザーのアクセスキーは 90 日ごとに更新する必要があります

カテゴリ: 保護-セキュアなアクセス管理

緊急度: ミディアム

リソースタイプ: AWS::IAM::User

AWS Config ルール: access-keys-rotated

パラメータ:

  • maxAccessKeyAge: 90

このコントロールは、アクティブなアクセスキーが 90 日以内に更新されているかどうかをチェックします。

アカウントのすべてのアクセスキーを生成したり削除したりしないことを強くお勧めします。代わりに、1 つ以上の IAM ロールを作成するか、フェデレーション。これらの方法を使用すると、ユーザーが既存の企業認証情報を使用して AWS Management Console および AWS CLI にログインできます。

各アプローチにはユースケースがあります。フェデレーションは、既存の中央ディレクトリを持っている企業や、現在の制限を超える IAM ユーザーを必要とする予定の企業にとって一般的に適しています。の外部で実行されるアプリケーションAWS環境では、へのプログラムによるアクセスキーが必要ですAWSリソースの使用料金を見積もることができます。

ただし、プログラムによるアクセスを必要とするリソースが AWS 内部で実行される場合、ベストプラクティスは IAM ロールを使用することです。ロールを使用すると、アクセスキー ID とシークレットアクセスキーを設定にハードコーディングすることなく、リソースへのアクセスを許可できます。

アクセスキーとアカウントの保護の詳細については、「」を参照してください。管理のベストプラクティスAWSアクセスキーAWS全般のリファレンス。また、ブログ記事「プログラムによるアクセス使用中に AWS アカウントを保護するためのガイドライン」も参照してください。

アクセスキーがすでにある場合、Security Hub は 90 日ごとにアクセスキーをローテーションすることをお勧めします。アクセスキーを更新することにより、侵害されたアカウントや終了したアカウントに関連付けられているアクセスキーが使用される可能性が低くなります。また、紛失したり、ひび割れたり、盗まれたりした古いキーでデータにアクセスできないようにします。アクセスキーを更新したら、必ずアプリケーションを更新してください。

AWS アクセスキーは、アクセスキー ID とシークレットアクセスキーで構成されます。これらは、プログラムによるリクエストの署名に使用されます。AWS。AWSユーザーがプログラムで呼び出すには、独自のアクセスキーが必要ですAWSからのAWS CLI、Tools for Windows PowerShell、AWSSDK、または個々の API オペレーションを使用した直接 HTTP 呼び出しAWSのサービス。

組織で AWS Single Sign-On (AWS SSO) を使用している場合、ユーザーは Active Directory、組み込み AWS SSO ディレクトリ、または AWS SSO に接続された別の ID プロバイダー (IdP) にサインインできます。次に、実行できる IAM ロールにマッピングできます。AWS CLIコマンドまたはコールAWSIAM ユーザーアクセスキーを必要としない API オペレーション。詳細については、次を参照してください。設定:AWS CLIを使用するを使用するAWS Single Sign-OnAWS Command Line Interfaceユーザーガイド

注記

このコントロールは、アフリカ (ケープタウン) または EU (ミラノ) ではサポートされていません。

Remediation

この問題を解決するには、90 日より古いキーをすべて置き換えます。

アクセスキーを 90 日間以上使用しないようにするには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [ユーザー] を選択します。

  3. 90 日間を超える [Access key age (アクセスキーの古さ)] を示す各ユーザーで、[ユーザー名] を選択してそのユーザーの設定を開きます。

  4. [セキュリティ認証情報] を選択します。

  5. ユーザーの新しいキーを作成するには:

    1. [アクセスキーの作成] を選択します。

    2. キーコンテンツを保存するには、シークレットアクセスキーをダウンロードするか、[表示] を選択してページからコピーします。

    3. ユーザーに提供する安全な場所にキーを格納します。

    4. [閉じる] を選択します。

  6. 以前のキーを使用していたすべてのアプリケーションを更新し、新しいキーを使用するようにします。

  7. 以前のキーでは、[Make inactive (非アクティブにする)] を選択してアクセスキーを非アクティブにします。これで、ユーザーはそのキーを使用してリクエストを行うことができなくなります。

  8. すべてのアプリケーションが新しいキーで想定どおりに機能することを確認します。

  9. すべてのアプリケーションが新しいキーで想定どおりに機能することを確認したら、以前のキーを削除します。削除した後でアクセスキーを復元することはできません。

    前のキーを削除するには、行の末尾にある [X] を選択し、[削除] を選択します。

[IAM.4] IAM ルートユーザーアクセスキーが存在してはいけません

カテゴリ: 保護-セキュアなアクセス管理

緊急度: 非常事態

リソースタイプ: AWSアカウント

AWS Config ルール: iam-root-access-key-check

パラメータ: なし

このコントロールは、ルートユーザーアクセスキーがあるかどうかをチェックします。

ルートアカウントは、AWS アカウントで最も権限があるユーザーです。AWS アクセスキーは、プログラムから指定されたアカウントにアクセスできます。

Security Hub では、ルートアカウントに関連付けられているすべてのアクセスキーを削除することをお勧めします。これにより、アカウントを侵害するために使用できるベクターが制限されます。また、最も権限の低いロールベースのアカウントの作成と使用が促進されます。

注記

このコントロールは、アフリカ (ケープタウン) ではサポートされていません。

Remediation

この問題を修正するには、ルートユーザーアクセスキーを削除します。

アクセスキーを削除するには

  1. [] を使用してアカウントにログインします。AWS アカウントルートユーザーの認証情報。

  2. ページの右上隅近くにあるアカウント名を選択し、[My Security Credentials (セキュリティの認証情報)] を選択します。

  3. ポップアップ警告で、[Continue to Security Credentials (セキュリティ認証情報に進む)] を選択します。

  4. [アクセスキー (アクセスキー ID とシークレットアクセスキー)] を選択します。

  5. 完全にキーを削除するには、[Delete (削除)] を選択し、次に [Yes (はい)] を選択します。削除したキーを復元することはできません。

  6. ルートユーザアクセスキーが複数ある場合は、各キーに対して手順 4 と 5 を繰り返します。

[IAM.5] コンソールパスワードを持つすべての IAM ユーザーに対して MFA を有効にする必要があります

カテゴリ: 保護-セキュアなアクセス管理

緊急度: ミディアム

リソースタイプ: AWS::IAM::User

AWS Config ルール: mfa-enabled-for-iam-console-access

パラメータ: なし

このコントロールは、かどうかを確認します。AWSコンソールパスワードを使用するすべての IAM ユーザーについて Multi-Factor Authentication (MFA) が有効になります。

多要素認証 (MFA) はユーザー名とパスワードの上に、もう 1 つの保護レイヤーを追加します。MFA が有効な場合、ユーザーが AWS ウェブサイトにサインインすると、ユーザー名とパスワードの入力を求められます。さらに、AWS MFA デバイスからの認証コードの入力が求められます。

コンソールパスワードを持つすべてのアカウントの MFA を有効にすることをお勧めします。MFA は、コンソールアクセスのセキュリティを強化するように設計されています。認証プリンシパルは、時間に依存するキーを発行するデバイスを所有し、認証情報に関する知識を持っている必要があります。

Remediation

この問題を修復するには、MFA をまだ持っていないユーザーに追加します。

ユーザーの MFA を設定するには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [ユーザー] を選択します。

  3. MFA を設定するユーザーの [ユーザー名] を選択します。

  4. [セキュリティ認証情報] を選択します。

  5. [Assigned MFA Device (割り当て済み MFA デバイス)] の横で、[管理] を選択します。

  6. [Manage MFA Device (MFA デバイスの管理)] ウィザードに従って、ご利用の環境に応じたデバイスのタイプを割り当てます。

ユーザーに MFA セットアップを委任する方法については、ブログ記事を参照してください。多要素認証の管理をに委任する方法AWSIAM ユーザー

[IAM.6] ルートユーザーに対してハードウェア MFA を有効にする必要があります

カテゴリ: 保護-セキュアなアクセス管理

緊急度: 非常事態

リソースタイプ: AWSアカウント

AWS Config ルール: root-account-hardware-mfa-enabled

パラメータ: なし

このコントロールは、AWSアカウントのユーザーで、ルートのユーザー認証情報を使用してサインインする際に Multi-Factor Authentication (MFA) デバイスを使用できます。

仮想 MFA はハードウェア MFA デバイスと同じレベルのセキュリティを提供しない可能性があります。ハードウェアの購入承認の待機中、またはハードウェアの到着を待つ間にのみ、仮想 MFA デバイスを使用することをお勧めします。詳細については、次を参照してください。仮想 Multi-Factor Authentication (MFA) デバイスの有効化 (コンソール)IAM ユーザーガイド

注記

このコントロールは、次のリージョンではサポートされていません。

  • 中国 (北京)

  • 中国 (寧夏)

  • AWS GovCloud (米国東部)

  • AWSGovCloud (米国西部)。

Remediation

この問題を解決するには、ルートアカウントにハードウェアベースの MFA を追加します。

ルートアカウントのハードウェアベースの MFA を有効にするには

  1. root ユーザーの認証情報を使用してアカウントにログインします。

  2. ページの右上隅近くにあるアカウント名を選択し、[My Security Credentials (セキュリティの認証情報)] を選択します。

  3. ポップアップ警告で、[Continue to Security Credentials (セキュリティ認証情報に進む)] を選択します。

  4. [Multi-Factor Authentication (MFA) (多要素認証 (MFA))] を選択します。

  5. [MFA の有効化] を選択します。

  6. MFA で使用するハードウェアベース (仮想ではない) のデバイスを選択し、 [続行] を選択します。

  7. 選択に応じて適切なデバイスタイプを設定するステップを完了します。

[IAM.7] IAM ユーザーのパスワードポリシーには強力な設定が必要です

カテゴリ: 保護-セキュアなアクセス管理

緊急度: ミディアム

リソースタイプ: AWSアカウント

AWS Config ルール: iam-password-policy

パラメータ:

  • RequireUppercaseCharacters: true

  • RequireLowercaseCharacters: true

  • RequireSymbols: true

  • RequireNumbers: true

  • MinimumPasswordLength: 8

このコントロールは、IAM ユーザーのアカウントパスワードポリシーが次の推奨設定を使用しているかどうかを確認します。

  • RequireUppercaseCharacters: true

  • RequireLowercaseCharacters: true

  • RequireSymbols: true

  • RequireNumbers: true

  • MinimumPasswordLength: 8

にアクセスするにはAWS Management ConsoleIAM ユーザーにはパスワードが必要です。ベストプラクティスとして、Security Hub では IAM ユーザーを作成する代わりに、フェデレーションを使用することを強くお勧めします。フェデレーションにより、ユーザは既存の企業認証情報を使用して、AWS Management Console。を使用するAWS Single Sign-On(AWS SSO) をクリックしてユーザーを作成またはフェデレートし、IAM ロールをアカウントに引き受けます。

ID プロバイダーおよびフェデレーションの詳細については、「」を参照してください。ID プロバイダーとフェデレーションIAM ユーザーガイド。AWS SSO の詳細については、「AWS Single Sign-On ユーザーガイド」を参照してください。

IAM ユーザーを使用する必要がある場合は、Security Hub では、強力なユーザーパスワードの作成を強制することをお勧めします。パスワードポリシーは、AWSアカウントで、パスワードの複雑な要件と必須のローテーション期間を指定します。パスワードポリシーを作成または変更する場合、パスワードポリシーの設定の多くは、ユーザーが次回パスワードを変更するときに適用されます。一部の設定はすぐに適用されます。詳細については、次を参照してください。IAM ユーザー用のアカウントパスワードポリシーの設定IAM ユーザーガイド

Remediation

この問題を解決するには、推奨される構成を使用するようにパスワードポリシーを更新します。

パスワードポリシーを変更するには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [Account settings (アカウント設定)] を選択します。

  3. [Requires at least one uppercase letter (少なくとも 1 つの大文字が必要)] を選択します。

  4. [Requires at least one lowercase letter (少なくとも 1 つの小文字が必要)] を選択します。

  5. [Requires at least one non-alphanumeric character (少なくとも 1 つの英数字以外の文字が必要)] を選択します。

  6. [Requires at least one number (少なくとも 1 つの番号が必要です)] を選択します。

  7. [Minimum password length (パスワードの最小長)] に「8」と入力します。

  8. [Apply Password Policy (パスワードポリシーの適用)] をクリックします。

[IAM.8] 未使用の IAM ユーザー認証情報は削除する必要があります

カテゴリ: 保護-セキュアなアクセス管理

緊急度: ミディアム

リソースタイプ: AWS::IAM::User

AWS Config ルール: iam-user-unused-credentials-check

パラメータ:

  • maxCredentialUsageAge: 90

このコントロールは、IAM ユーザーが 90 日間使用されていないパスワードまたはアクティブなアクセスキーを持っているかどうかを確認します。

IAM ユーザーはアクセスできるAWSパスワードやアクセスキーなど、さまざまなタイプの認証情報を使用するリソース。

Security Hub は、90 日以上使用されていないすべての認証情報を削除または非アクティブ化することをお勧めします。不要な認証情報を無効化または削除することにより、認証情報が漏洩したり、放棄されたアカウントが使用される機会が少なくなります。

Remediation

日付付きの認証情報のアカウントを監視するために必要な一部の情報を取得するには、IAM コンソールを使用します。たとえば、アカウントのユーザーを表示する場合、[Access key age (アクセスキーの古さ)]、[Password age (パスワードの古さ)]、および [Last activity (最後のアクティビティ)] の列が表示されます。これらの列の値が 90 日より大きい場合は、それらのユーザーの認証情報を無効にします。

認証情報レポートを使用してユーザーアカウントを監視し、90 日以上アクティビティのないアカウントを特定することもできます。認証情報レポートは、でダウンロードできます。.csvIAM コンソールからフォーマットします。認証情報レポートの詳細については、「」を参照してください。の認証情報レポートの取得AWSアカウントIAM ユーザーガイド

非アクティブなアカウントや使用されていない認証情報を識別したら、次のステップを使用してそれらを無効にします。

非アクティブなアカウントの認証情報を無効にするには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [ユーザー] を選択します。

  3. 90 日を超えた認証情報を持つユーザーの名前を選択します。

  4. [セキュリティ認証情報] を選択します。

  5. 90 日以上使用されていないサインイン資格情報とアクセスキーごとに、非アクティブにする

[IAM.21] 作成する IAM カスタマー管理ポリシーは、サービスのワイルドカードアクションを許可しないでください。

カテゴリ: 検出-セキュアなアクセス管理

緊急度:

リソースタイプ: AWS::IAM::Policy

AWS Config ルール: iam-policy-no-statements-with-full-access

パラメータ: なし

このコントロールは、作成した IAM アイデンティティベースのポリシーに、* ワイルドカードを使用して、任意のサービスに対するすべてのアクションに対するアクセス権限を付与する Allow ステートメントがあるかどうかをチェックします。ポリシーステートメントに含まれるポリシーステートメントがある場合、コントロールは失敗します。"Effect": "Allow""Action": "Service:*"

たとえば、ポリシー内の次のステートメントは、検索に失敗します。。

"Statement": [ { "Sid": "EC2-Wildcard", "Effect": "Allow", "Action": "ec2:*", "Resource": "*" }

を使用すると、コントロールも失敗します。"Effect": "Allow""NotAction": "service:*"。その場合、NotAction要素は、内のすべてのアクションにアクセスできます。AWSサービス(で指定されたアクションを除く)NotAction

このコントロールは、カスタマー管理の IAM ポリシーにのみ適用されます。によって管理される IAM ポリシーには適用されません。AWS。

パーミッションをに割り当てるときAWSサービスでは、IAM ポリシーで許可される IAM アクションの範囲をスコープすることが重要です。IAM アクションは、必要なアクションのみに制限する必要があります。これにより、最小権限の権限のプロビジョニングに役立ちます。ポリシーがアクセス権限を必要としない IAM プリンシパルにアタッチされている場合、過度に許可されたポリシーによって特権のエスカレーションが発生する可能性があります。

場合によっては、次のようなプレフィックスを持つ IAM アクションを許可する場合があります。DescribeFlowLogsおよびDescribeAvailabilityZones。これらの許可されたケースでは、共通プレフィクスに接尾辞付きワイルドカードを追加できます。例えば、ec2:Describe* と指定します。

このコントロールは、接頭辞が付いた IAM アクションにワイルドカードが付いた場合に渡されます。たとえば、ポリシー内の次のステートメントでは、結果が渡されます。。

"Statement": [ { "Sid": "EC2-Wildcard", "Effect": "Allow", "Action": "ec2:Describe*", "Resource": "*" }

この方法で関連する IAM アクションをグループ化すると、IAM ポリシーのサイズ制限を超えないようにすることもできます。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アジアパシフィック (大阪)

  • 中国 (北京)

  • 中国 (寧夏)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

この問題を解決するには、IAM ポリシーを更新して、完全な「*」管理権限を許可しません。

IAM ポリシーを編集する方法の詳細については、「」を参照してください。IAM ポリシーの編集IAM ユーザーガイド

[KMS.1] IAM カスタマー管理ポリシーでは、すべての KMS キーで復号化アクションを許可しないでください。

カテゴリ: 保護-セキュアなアクセス管理

緊急度: ミディアム

リソースタイプ: AWS::IAM::Policy

AWS Config ルール: iam_customer_policy_blocked_kms_actions

パラメータ:

  • kms:ReEncryptFrom, kms:Decrypt

IAM カスタマー管理ポリシーのデフォルトバージョンでプリンシパルがAWS KMSすべてのリソースに対する復号化アクション。このコントロールはケヤキ自動化された推論エンジンで、シークレットへの幅広いアクセスを許可する可能性のあるポリシーについて検証および警告します。AWSアカウント。

このコントロールは、kms:Decryptまたはkms:ReEncryptFromアクションは、すべての KMS キーで許可されます。このコントロールは、アタッチされたカスタマー管理ポリシーとアタッチされていないカスタマー管理ポリシーの両方を評価します。インラインポリシーはチェックされません。またはAWS管理ポリシー。

とAWS KMSでは、KMS キーを使用して暗号化されたデータにアクセスできるユーザーを制御できます。IAM ポリシーは、ID(ユーザー、グループ、またはロール)がどのリソースに対して実行できるアクションを定義します。セキュリティのベストプラクティスの適用AWSでは、最小権限を許可することをお勧めします。つまり、アイデンティティにはkms:Decryptまたはkms:ReEncryptFromアクセス許可と、タスクの実行に必要なキーに対してのみ。そうしないと、ユーザーはデータに適さないキーを使用する可能性があります。

すべてのキーに対するアクセス許可を付与する代わりに、ユーザーが暗号化されたデータにアクセスするために必要な最小キーのセットを決定します。次に、ユーザーがそれらのキーのみを使用できるようにするポリシーを設計します。たとえば、許可しないkms:Decryptすべての KMS キーに対する権限。代わりに、許可します。kms:Decryptアカウントの特定のリージョンのキーでのみ使用できます。最小権限の原則を採用することで、意図しないデータ漏洩のリスクを減らすことができます。

Remediation

この問題を解決するには、IAM カスタマー管理ポリシーを変更して、キーへのアクセスを制限します。

IAM カスタマー管理ポリシーを変更するには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [IAM] ナビゲーションペインで、[] を選択します。ポリシー

  3. 変更するポリシーの横にある矢印を選択します。

  4. [Edit policy (ポリシーの編集)] を選択します。

  5. [JSON] タブを選択します。

  6. を変更“Resource”の値を指定します。許可する特定のキーを指定します。

  7. ポリシーを変更したら、[] を選択します。ポリシーの確認

  8. [変更を保存] を選択します。

詳細については、「」を参照してください。での IAM ポリシーの使用AWS KMSAWS Key Management Serviceデベロッパーガイド

[KMS.2] IAM プリンシパルは、すべての KMS キーで復号化アクションを許可する IAM インラインポリシーを持つべきではありません。

カテゴリ: 保護-セキュアなアクセス管理

緊急度: ミディアム

リソースタイプ:

  • AWS::IAM::Role

  • AWS::IAM::User

  • AWS::IAM::Group

AWS Config ルール: iam_inline_policy_blocked_kms_actions

パラメータ:

  • kms:ReEncryptFrom, kms:Decrypt

IAM ID(ロール、ユーザー、またはグループ)に埋め込まれたインラインポリシーで、AWS KMSすべての KMS キーに対する復号化アクション。このコントロールはケヤキ自動化された推論エンジンで、シークレットへの幅広いアクセスを許可する可能性のあるポリシーについて検証および警告します。AWSアカウント。

このコントロールは次の場合に失敗します。kms:Decryptまたはkms:ReEncryptFromアクションは、インラインポリシー内のすべての KMS キーで許可されます。

とAWS KMSでは、KMS キーを使用して暗号化されたデータにアクセスできるユーザーを制御できます。IAM ポリシーは、ID(ユーザー、グループ、またはロール)がどのリソースに対して実行できるアクションを定義します。セキュリティのベストプラクティスの適用AWSでは、最小権限を許可することをお勧めします。つまり、ID には必要なアクセス許可のみを付与し、タスクの実行に必要なアクセス許可のみを付与する必要があります。そうしないと、ユーザーはデータに適さないキーを使用する可能性があります。

すべてのキーに対するアクセス許可を付与する代わりに、ユーザーが暗号化されたデータにアクセスするために必要な最小キーのセットを決定します。次に、ユーザーがそれらのキーのみを使用できるようにするポリシーを設計します。たとえば、許可しないkms:Decryptすべての KMS キーに対する権限。代わりに、アカウントの特定のリージョンのキーに対してのみ許可してください。最小権限の原則を採用することで、意図しないデータ漏洩のリスクを減らすことができます。

Remediation

この問題を解決するには、インラインポリシーを変更して、キーへのアクセスを制限します。

IAM インラインポリシーを変更するには

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. [IAM] ナビゲーションペインで、[] を選択します。ユーザー,Groups, またはロール

  3. IAM インラインポリシーを変更するユーザー、グループ、またはロールの名前を選択します。

  4. 変更するポリシーの横にある矢印を選択します。

  5. [Edit policy (ポリシーの編集)] を選択します。

  6. [JSON] タブを選択します。

  7. を変更"Resource"値を許可する特定のキーを指定します。

  8. ポリシーを変更したら、[] を選択します。ポリシーの確認

  9. [変更を保存] を選択します。

詳細については、「」を参照してください。での IAM ポリシーの使用AWS KMSAWS Key Management Serviceデベロッパーガイド

[KMS.3]AWS KMSキーを意図せずに削除すべきではない

カテゴリ: 保護-データ保護-データ削除保護

緊急度: 非常事態

リソースタイプ: AWS::KMS::Key

AWS Config ルール: kms-cmk-not-scheduled-for-deletion

パラメータ: なし

このコントロールは、KMS キーの削除がスケジュールされているかどうかをチェックします。KMS キーの削除がスケジュールされている場合、コントロールは失敗します。

KMS キーは、一度削除すると復元できません。KMS キーで暗号化されたデータも、KMS キーが削除された場合は永久に回復できません。意味のあるデータが削除予定の KMS キーで暗号化されている場合は、意図的に実行していない限り、データを復号化するか、新しい KMS キーでデータを再暗号化することを検討してください。暗号化消去

KMS キーの削除がスケジュールされている場合、エラーでスケジュールされていた場合は、削除を元に戻す時間を許可するために必須の待機期間が適用されます。デフォルトの待機期間は 30 日間ですが、KMS キーの削除がスケジュールされている場合は 7 日以内に短縮できます。待機期間中、スケジュールされた削除はキャンセルでき、KMS キーは削除されません。

KMS キーの削除の詳細については、を参照してください。KMS キーの削除AWS Key Management Serviceデベロッパーガイド

注記

このコントロールは、アジアパシフィック (大阪) リージョンおよびヨーロッパ (ミラノ) リージョンではサポートされていません。

Remediation

スケジュールされた KMS キーの削除をキャンセルする修復手順の詳細については、を参照してください。キーの削除をキャンセルするには[]キー削除のスケジュールとキャンセル (コンソール)のAWS Key Management Service開発者ガイド の最初のリリースです。

[Lambda.1] Lambda a関数ポリシーではパブリックアクセスを禁止する必要があります

カテゴリ: 保護-セキュアなネットワーク設定

緊急度: 非常事態

リソースタイプ: AWS::Lambda::Function

AWS Config ルール: lambda-function-public-access-prohibited

パラメータ: なし

このコントロールは、Lambda 関数リソースベースのポリシーがパブリックアクセスを禁止しているかどうかをチェックします。

Lambda 関数が Amazon S3 から呼び出され、ポリシーに条件が含まれていない場合、コントロールは失敗します。AWS:SourceAccount

Lambda 関数は、関数に保存されているコードへの意図しないアクセスを可能にする可能性があるため、パブリックにアクセスすることはできません。

注記

中国 (北京) または中国 (寧夏) リージョンでは、このコントロールはサポートされていません。

Remediation

Lambda 関数がこのコントロールに失敗した場合、Lambda 関数のリソースベースのポリシーステートメントがパブリックアクセスを許可していることを示します。

この問題を解決するには、ポリシーを更新してアクセス権限を削除するか、AWS:SourceAccount条件。リソースベースのポリシーを更新できるのは、Lambda API からのみです。

次の手順では、コンソールを使用してポリシーを確認し、AWS Command Line Interfaceをクリックして、パーミッションを削除します。

Lambda 関数のリソースベースのポリシーを表示するには

  1. https://console.aws.amazon.com/lambda/ で、AWS Lambda コンソールを開きます。

  2. ナビゲーションペインで、[Functions] (関数) を選択します。

  3. 関数を選択します。

  4. [Permissions] (アクセス許可) をクリックします。リソースベースのポリシーには、別のアカウントまたは AWS のサービスが関数にアクセスしようとしたときに適用されるアクセス許可が表示されます。

  5. リソースベースのポリシーを確認します。次のポリシーステートメントを特定します。Principalポリシーを公開するフィールド値。たとえば、許可する"*"または{ "AWS": "*" }

    コンソールからポリシーを編集することはできません。関数からアクセス許可を削除するには、remove-permission[] からコマンドを実行するAWS CLI。

    ステートメント ID の値をメモします (Sid) を削除するステートメントを指定します。

♪AWS CLILambda 関数からアクセス権限を削除するには、remove-permissionコマンド。

$ aws lambda remove-permission --function-name <function-name> --statement-id <statement-id>

置換<function-name>は Lambda 関数の名前で、<statement-id>削除するステートメントのステートメント ID を指定します。

アクセス許可が更新されていることを確認するには

  1. https://console.aws.amazon.com/lambda/ で、AWS Lambda コンソールを開きます。

  2. ナビゲーションペインで、[Functions] (関数) を選択します。

  3. 更新した関数を選択します。

  4. [Permissions] (アクセス許可) をクリックします。

    リソースベースのポリシーを更新する必要があります。ポリシーにステートメントが 1 つしかない場合、ポリシーは空です。

詳細については、「」を参照してください。のリソースベースのポリシーを使用するAWS LambdaAWS Lambdaデベロッパーガイド

[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります

カテゴリ: 保護-セキュア開発

緊急度: ミディアム

リソースタイプ: AWS::Lambda::Function

AWS Config ルール: lambda-function-settings-check

パラメータ:

  • runtime: nodejs14.x, nodejs12.x, python3.9, python3.8, python3.7, python3.6, ruby2.7, java11, java8, java8.al2, go1.x, dotnetcore3.1

このコントロールは、ランタイムの Lambda 関数設定が、サポートされているランタイムに設定されている期待値と一致することを確認します。このコントロールは、次のランタイムをチェックします。nodejs14.x,nodejs12.x,python3.9,python3.8,python3.7,python3.6,ruby2.7,java11,java8,java8.al2,go1.x,dotnetcore3.1

-AWS Configルールは、パッケージタイプがの関数を無視します。Image

Lambda ランタイムは、メンテナンスとセキュリティの更新の対象となるオペレーティングシステム、プログラミング言語、およびソフトウェアライブラリの組み合わせを中心に構築されています。ランタイムコンポーネントがセキュリティアップデートでサポート対象外となった場合、Lambda はこのランタイムを廃止します。非推奨のランタイムを使用する関数を作成することはできませんが、この関数は呼び出しイベントの処理に使用できます。Lambda 関数が最新であり、古いランタイム環境を使用していないことを確認してください。

このコントロールがサポートされている言語をチェックするサポートされているランタイムの詳細については、を参照してください。AWS LambdaランタイムAWS Lambdaデベロッパーガイド

注記

中国 (北京) または中国 (寧夏) リージョンでは、このコントロールはサポートされていません。

Remediation

サポートされているランタイムと非推奨スケジュールの詳細については、「」を参照してください。ランタイムサポートポリシーの セクションAWS Lambdaデベロッパーガイド。ランタイムを最新バージョンに移行するときは、言語の発行元からの構文とガイダンスに従ってください。

[Lambda.4] Lambda 関数にはデッドレターキューが設定されている必要があります (リタイア)

このコントロールは終了します。

[RDS.1] RDS スナップショットはプライベートである必要があります

カテゴリ: 保護-セキュアなネットワーク設定

緊急度: 非常事態

リソースタイプ: AWS::RDS::DBSnapshot

AWS Config ルール: rds-snapshots-public-prohibited

パラメータ: なし

このコントロールは、Amazon RDS スナップショットがパブリックかどうかをチェックします。

このコントロールは RDS インスタンスを対象としています。また、Aurora DB インスタンス、Neptune DB インスタンス、および Amazon DocumentDB クラスターのスナップショットの結果を返すこともできます。ただし、パブリックアクセシビリティは評価されません。これらの知見が役に立たない場合は、抑制できます。

RDS スナップショットは、特定の時点の RDS インスタンスのデータをバックアップするために使用されます。RDS インスタンスの以前の状態を復元するために使用できます。

RDS スナップショットは、意図しない限りパブリックにすることはできません。暗号化されていない手動スナップショットをパブリックとして共有すると、このスナップショットをすべてが使用できるようになります。AWSアカウント。これにより、RDS インスタンスの意図しないデータ漏えいが発生する可能性があります。

パブリックアクセスを許可するように構成を変更した場合、AWS Config ルールは最大 12 時間変更を検出できない場合があります。AWS Config ルールが変更を検出するまで、設定がルールに違反していてもチェックは成功します。

DB スナップショットの共有に関する詳細は、「」を参照してください。DB スナップショットの共有Amazon RDS ユーザーガイド

注記

このコントロールは、アフリカ (ケープタウン) または EU (ミラノ) ではサポートされていません。

Remediation

この問題を解決するには、RDS スナップショットを更新してパブリックアクセスを削除します。

RDS スナップショットのパブリックアクセスを削除するには

  1. Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. [Snapshots (スナップショット)] に移動し、変更するパブリックスナップショットを選択します。

  3. [アクション] から、[スナップショットの共有] を選択します。

  4. [DB snapshot visibility (DB スナップショットの可視性)] から、[Private (プライベート)] を選択します。

  5. [DB snapshot visibility (DB スナップショットの可視性)] から、[all (すべて)] を選択します。

  6. [Save] を選択します。

[RDS.2] RDS DB インスタンスは、パブリックアクセスを禁止する必要があります。これは PubliclyAccessible 設定によって判断されます。

カテゴリ: 保護-セキュアなネットワーク設定

緊急度: 非常事態

リソースタイプ: AWS::RDS::DBInstance

AWS Config ルール: rds-instance-public-access-check

パラメータ: なし

このコントロールは、PubliclyAccessibleインスタンス設定項目の [] フィールド。

Neptune DB インスタンスと Amazon DocumentDB クラスターには、PubliclyAccessibleフラグを付けて、評価できません。ただし、このコントロールでは、これらのリソースに関する結果を生成できます。これらの調査結果を抑制できます。

RDS インスタンス設定 の PubliclyAccessible 値は、DB インスタンスがパブリックにアクセスできるかどうかを示します。DB インスタンスが PubliclyAccessible で設定されている場合、パブリックに解決可能な DNS 名を持つインターネット向けインスタンスであり、パブリック IP アドレスに解決されます。DB インスタンスはパブリックにアクセスできない場合、プライベート IP アドレスに解決される DNS 名を持つ内部インスタンスです。

RDS インスタンスがパブリックにアクセスできるようにする予定がない限り、RDS インスタンスを [] で設定しないでください。PubliclyAccessible値. そうすることで、データベースインスタンスへの不要なトラフィックが発生する可能性があります。

Remediation

この問題を解決するには、RDS DB インスタンスを更新してパブリックアクセスを削除します。

RDS DB インスタンスからパブリックアクセスを削除するには

  1. Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. [Databases (データベース)] に移動し、パブリックデータベースを選択します

  3. [Modify] を選択します。

  4. []接続を展開します。その他の接続設定

  5. []パブリックアクセスで、パブリックにアクセス可能ではない

  6. [Continue] を選択します。

  7. []変更のスケジュールで、すぐに適用

  8. [DB インスタンスの変更] を選択します。

詳細については、「」を参照してください。VPC 内の DB インスタンスの使用Amazon RDS ユーザーガイド

[RDS.3] RDS DB インスタンスでは、保管時の暗号化が有効になっている必要があります。

カテゴリ: 保護-データ保護-保管中のデータの暗号化

緊急度: ミディアム

リソースタイプ: AWS::RDS::DBInstance

AWS Config ルール: rds-storage-encrypted

パラメータ: なし

このコントロールは、Amazon RDS DB インスタンスに対してストレージの暗号化が有効になっているかどうかを確認します。

このコントロールは RDS DB インスタンスを対象としています。ただし、Aurora DB インスタンス、Neptune DB インスタンス、および Amazon DocumentDB クラスターの検出結果を生成することもできます。これらの知見が役に立たない場合は、それらを抑制できます。

RDS DB インスタンスの機密データのセキュリティを強化するには、RDS DB インスタンスを保管時に暗号化するように設定する必要があります。保管中の Amazon RDS DB インスタンスとスナップショットを暗号化するには、RDS DB インスタンスの暗号化オプションを有効にします。保管時に暗号化されるデータには、DB インスタンス、自動バックアップ、リードレプリカ、スナップショットの基本的なストレージが含まれます。

RDS の暗号化された DB インスタンスでは、RDS DB インスタンスをホストしているサーバーでデータを暗号化するために、業界標準の AES-256 暗号化アルゴリズムを使用します。データが暗号化されると、Amazon RDS はパフォーマンスの影響を最小限に抑えながら、データへのアクセスと復号の認証を透過的に処理します。暗号化を使用するために、データベースのクライアントアプリケーションを変更する必要はありません。

Amazon RDS 暗号化は、現在すべてのデータベースエンジンおよびストレージタイプに使用できます。Amazon RDS 暗号化は、ほとんどの DB インスタンスクラスで使用できます。Amazon RDS 暗号化をサポートしていない DB インスタンスクラスの詳細については、「」を参照してください。Amazon RDS リソースの暗号化Amazon RDS ユーザーガイド

Remediation

Amazon RDS での DB インスタンスの暗号化の詳細については、「」を参照してください。Amazon RDS リソースの暗号化Amazon RDS ユーザーガイド

[RDS.4] RDS クラスタースナップショットとデータベーススナップショットは保存時に暗号化する必要があります

カテゴリ: 保護-データ保護-保管中のデータの暗号化

緊急度: ミディアム

リソースタイプ: AWS::RDS::DBClusterSnapshot, AWS::RDS::DBSnapshot

AWS Config ルール: rds-snapshots-encrypted

パラメータ: なし

このコントロールは、RDS DB スナップショットが暗号化されているかどうかを確認します。

このコントロールは RDS DB インスタンスを対象としています。ただし、Aurora DB インスタンス、Neptune DB インスタンス、および Amazon DocumentDB クラスターのスナップショットに関する検索結果をで生成することもできます。これらの知見が役に立たない場合は、それらを抑制できます。

保管中のデータを暗号化すると、認証されていないユーザーがディスクに保存されているデータにアクセスするリスクが軽減されます。RDS スナップショットのデータは、セキュリティ層を追加するために、保存時に暗号化する必要があります。

Remediation

Amazon RDS コンソールを使用して、この問題を修復できます。

暗号化されていない RDS スナップショットを暗号化するには

  1. Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[Snapshots] を選択します。

  3. 暗号化するスナップショットを検索する手動またはシステム

  4. 暗号化するスナップショットの横にあるチェックボックスをオンにします。

  5. 選択アクション[]、[]スナップショットのコピー

  6. []新しい DB スナップショット識別子に、新しいスナップショットの名前を入力します。

  7. []Encryptionを選択し、暗号を有効化

  8. スナップショットの暗号化に使用する KMS キーを選択します。

  9. [Copy Snapshot] を選択します。

  10. 新しいスナップショットが作成されたら、元のスナップショットを削除します。

  11. を使用する場合バックアップの保存期間で、ゼロ以外の正の値を選択します。たとえば、30 日間です。

[RDS.5] RDS DB インスタンスは、複数のアベイラビリティーゾーンで構成する必要があります

カテゴリ: リカバリ > レジリエンス > 高可用性

緊急度: ミディアム

リソースタイプ: AWS::RDS::DBInstance

AWS Config ルール: rds-multi-az-support

パラメータ: なし

このコントロールは、RDS DB インスタンスに対して高可用性が有効になっているかどうかを確認します。

RDS DB インスタンスは、複数のアベイラビリティーゾーン (AZ) に対して構成する必要があります。これにより、保存されたデータの可用性が保証されます。マルチ AZ 配置では、アベイラビリティーゾーンの可用性に問題がある場合、および定期的な RDS メンテナンス中に自動フェイルオーバーを実行できます。

Remediation

この問題を解決するには、DB インスタンスを更新して、複数のアベイラビリティーゾーンを有効にします。

DB インスタンスの複数のアベイラビリティーゾーンを有効にするには

  1. Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[データベース] を選択し、変更する DB インスタンスを選択します。

  3. [Modify] を選択します。[Modify DB Instance] ページが表示されます。

  4. []インスタンス仕様, セットマルチ AZ 配置はい

  5. 選択続行そして、変更の概要を確認します。

  6. (省略可能) 変更をすぐに適用するには、[すぐに適用] を選択します。このオプションを選択すると、停止状態になる場合があります。詳細については、「」を参照してください。[すぐに適用] 設定を使用するAmazon RDS ユーザーガイド

  7. 確認ページで、変更内容を確認します。正しい場合は、[Modify DB Instance (DB インスタンスを変更)] を選択して変更を保存します。

[RDS.6] RDS DB インスタンスとクラスターの拡張モニタリングを構成する必要があります

カテゴリ: 検出-検出サービス

緊急度:

リソースタイプ: AWS::RDS::DBInstance

AWS Config ルール: rds-enhanced-monitoring-enabled

パラメータ: なし

このコントロールは、RDS DB インスタンスに対して拡張モニタリングが有効かどうかを確認します。

Amazon RDS では、拡張モニタリングにより、基盤となるインフラストラクチャのパフォーマンスの変化に対してより迅速に対応できます。これらのパフォーマンスの変更により、データの可用性が低下する可能性があります。[Enhanced Monitoring] を選択すると、RDS DB インスタンスが実行されているオペレーティングシステムのリアルタイムメトリクスが提供されます。インスタンスにはエージェントがインストールされています。エージェントは、ハイパーバイザー層から得られるよりも正確にメトリックを取得できます。

拡張モニタリングのメトリクスが便利なのは、DB インスタンス上のさまざまなプロセスやスレッドがどのように CPU を使用しているかを表示するときです。詳細については、「」を参照してください。拡張モニタリングAmazon RDS ユーザーガイド

Remediation

DB インスタンスに対して拡張モニタリングを有効にする方法の詳細については、「」拡張モニタリングの設定と有効化Amazon RDS ユーザーガイド

[RDS.7] RDS クラスターで削除保護を有効にする必要があります

カテゴリ: 保護-データ保護-データ削除保護

緊急度:

リソースタイプ: AWS::RDS::DBCluster

AWS Config ルール: rds-cluster-deletion-protection-enabled

パラメータ: なし

このコントロールは、RDS クラスターで削除に対する保護が有効になっているかどうかを確認します。

このコントロールは RDS DB インスタンスを対象としています。ただし、Aurora DB インスタンス、Neptune DB インスタンス、および Amazon DocumentDB クラスターの検出結果を生成することもできます。これらの知見が役に立たない場合は、それらを抑制できます。

クラスター削除保護を有効にすることは、不正なエンティティによるデータベースの偶発的な削除や削除に対する追加の保護レイヤーです。

削除保護が有効になっている場合、RDS クラスターを削除することはできません。削除リクエストが成功するには、削除保護を無効にする必要があります。

注記

このコントロールは、次のリージョンではサポートされていません。

  • 中国 (北京)

  • 中国 (寧夏)

  • 中東 (バーレーン)

  • 南米 (サンパウロ)。

Remediation

この問題を解決するには、RDS DB クラスターを更新して削除保護を有効にします。

RDS DB クラスターの削除保護を有効にするには

  1. Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[データベースを選択し、変更する DB クラスターを選択します。

  3. [Modify] を選択します。

  4. []削除保護で、削除保護の有効化

  5. [Continue] を選択します。

  6. []変更のスケジュールで、修正を適用するタイミングを選択します。オプションは次のとおりです。Apply during the next scheduled maintenance window (次に予定されているメンテナンス期間中に適用)またはすぐに適用

  7. [クラスターの変更] をクリックします。

[RDS.8] RDS DB インスタンスでは、削除保護が有効になっている必要があります。

カテゴリ:保護-データ保護-データ削除保護

緊急度:

リソースタイプ: AWS::RDS::DBInstance

AWS Config ルール: rds-instance-deletion-protection-enabled

パラメータ:

  • databaseEngines: mariadb,mysql,oracle-ee,oracle-se2,oracle-se1,oracle-se,postgres,sqlserver-ee,sqlserver-se,sqlserver-ex,sqlserver-web

このコントロールは、リストされているデータベースエンジンのいずれかを使用する RDS DB インスタンスで削除保護が有効になっているかどうかをチェックします。

インスタンス削除保護の有効化は、不正なエンティティによるデータベースの偶発的な削除や削除に対する追加の保護レイヤーです。

削除保護が有効になっている間は、RDS DB インスタンスを削除できません。削除リクエストが成功するには、削除保護を無効にする必要があります。

Remediation

この問題を解決するには、RDS DB インスタンスを更新して削除保護を有効にします。

RDS DB インスタンスの削除保護を有効にするには

  1. Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[データベースをクリックし、変更する DB インスタンスを選択します。

  3. [Modify] を選択します。

  4. []削除保護で、削除保護の有効化

  5. [Continue] を選択します。

  6. []変更のスケジュールで、修正を適用するタイミングを選択します。オプションは次のとおりです。Apply during the next scheduled maintenance window (次に予定されているメンテナンス期間中に適用)またはすぐに適用

  7. [DB インスタンスの変更] を選択します。

[RDS.9] データベースロギングを有効にする必要があります

カテゴリ: 識別-ログ記録

緊急度: ミディアム

リソースタイプ: AWS::RDS::DBInstance

AWS Config ルール: rds_logging_enabled

パラメータ: なし

このコントロールは、Amazon RDS の次のログが有効で CloudWatch Logs に送信されているかどうかをチェックします。

  • Oracle: (アラート、監査、トレース、リスナー)

  • PostgreSQL: (Postgresql、アップグレード)

  • MySQL: (監査、エラー、一般、SlowQuery)

  • MariaDB: (監査、エラー、一般、SlowQuery)

  • SQL Server: (エラー、エージェント)

  • Aurora: (監査、エラー、一般、SlowQuery)

  • オーロラ-MySQL: (監査、エラー、一般、SlowQuery)

  • オーロラ-PostgreSQL: (Postgresql、アップグレード)。

RDS データベースでは、関連するログを有効にする必要があります。データベースロギングは、RDS に対して行われたリクエストの詳細な記録を提供します。データベースログは、セキュリティとアクセス監査に役立ち、可用性の問題を診断するのに役立ちます。

注記

このコントロールは、次のリージョンではサポートされていません。

アフリカ (ケープタウン)

アジアパシフィック (大阪)

中国 (寧夏)

ヨーロッパ (ミラノ)

Remediation

ログオプションは、RDS DB クラスターまたはインスタンスに関連付けられた DB パラメータグループに含まれています。データベースエンジンのデフォルトパラメータグループが使用されるときにロギングを有効にするには、必要なパラメータ値を持つ新しい DB パラメータグループを作成する必要があります。次に、顧客 DB パラメータグループを DB クラスターまたはインスタンスに関連付ける必要があります。

から CloudWatch Logs に MariaDB、MySQL、または PostgreSQL のログを有効にし、公開するにはAWS Management Consoleで、カスタム DB パラメータグループで次のパラメータを設定します。

データベースエンジン

パラメータ

MariaDB

general_log=1

slow_query_log=1

log_output = FILE

MariaDB には、以下で説明するカスタムオプショングループも必要です。

MySQL

general_log=1

slow_query_log=1

log_output = FILE

PostgreSQL

log_statement=all

log_min_duration_statement=minimum query duration (ms) to log

カスタム DB パラメータグループを作成するには

  1. Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[パラメータグループ] を選択します。

  3. [Create parameter group] を選択します。[パラメータグループの作成] ウィンドウが表示されます。

  4. パラメータグループファミリーリストで、DB パラメータグループファミリーを選択します。

  5. タイプ[]、[] リストDB パラメータグループ

  6. Eclipseグループ名に、新しい DB パラメータグループの名前を入力します。

  7. Eclipse説明で、新しい DB パラメータグループの説明を入力します。

  8. [作成] を選択します。

コンソールを使用して MariaDB ロギング用の新しいオプショングループを作成するには

  1. Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[オプショングループ] を選択します。

  3. [Create group (グループの作成)] を選択します。

  4. [Create subnet group(オプショングループの作成)] ウィンドウで以下を行います。

    1. [Name] には、AWS アカウント内で一意であるオプショングループの名前を入力します。名前には、英字、数字、ハイフンのみを使用できます。

    2. [Description] には、オプショングループの簡単な説明を入力します。この説明は表示用に使用されます。

    3. [Engine] で、使用する DB エンジンを選択します。

    4. [Major Engine Version(メジャーエンジンバージョン)] で、必要な DB エンジンのメジャーバージョンを選択します。

  5. 続行するには、[Yes, Create(はい、作成する)] を選択します。

  6. 作成したオプショングループを選択します。

  7. [オプションの追加] を選択します。

  8. 選択MARIADB_AUDIT_PLUGINからのオプション名リスト。

  9. SERVER_AUDIT_EVENTSCONNECT, QUERY, TABLE, QUERY_DDL, QUERY_DML, QUERY_DCL に設定します。

  10. [オプションの追加] を選択します。

から CloudWatch Logs に SQL Server DB、Oracle DB、または PostgreSQL ログを発行するにはAWS Management Console

  1. Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[データベース] を選択します。

  3. 変更する DB インスタンスを選択します。

  4. [Modify] を選択します。

  5. []ログのエクスポートで、すべてのログファイルを選択して CloudWatch Logs への公開を開始します。

    ログのエクスポートは、CloudWatch Logs への発行をサポートするデータベースエンジンのバージョンでのみ使用できます。

  6. [Continue] を選択します。次に、[概要] ページでを選択します。DB インスタンスの変更

新しい DB パラメータグループまたは DB オプショングループを RDS DB インスタンスに適用するには

  1. Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[データベース] を選択します。

  3. 変更する DB インスタンスを選択します。

  4. [Modify] を選択します。[Modify DB Instance] ページが表示されます。

  5. []データベースの選択肢で、必要に応じて DB パラメータグループと DB オプショングループを変更します。

  6. 変更が完了したら、[] を選択します。続行。変更の概要を確認します。

  7. (省略可能) 変更をすぐに適用するには、[すぐに適用] を選択します。このオプションを選択すると、停止状態になる場合があります。詳細については、「」を参照してください。[すぐに適用] 設定を使用するAmazon RDS ユーザーガイド

  8. [DB インスタンスの変更] を選択して、変更を保存します。

[RDS.10] IAM 認証は RDS インスタンス用に設定する必要があります

カテゴリ: 保護-セキュアなアクセス管理-パスワードレス認証

緊急度: ミディアム

リソースタイプ: AWS::RDS::DBInstance

AWS Config ルール: rds-instance-iam-authentication-enabled

パラメータ: なし

このコントロールは、RDS DB インスタンスで IAM データベース認証が有効になっているかどうかをチェックします。

IAM データベース認証では、パスワードではなく認証トークンを使用してデータベースインスタンスへの認証を許可します。データベースに出入りするネットワークトラフィックは、SSL を使用して暗号化されます。詳細については、「」を参照してください。IAM データベース認証Amazon Aurora ユーザーガイド

注記

このコントロールは、次のリージョンではサポートされていません。

アフリカ (ケープタウン)

アジアパシフィック (香港)

アジアパシフィック (大阪)

中国 (北京)

中国 (寧夏)

Remediation

この問題を解決するには、DB インスタンスを更新して IAM 認証を有効にします。

既存の DB インスタンスに対して IAM 認証を有効にするには

  1. Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. [データベース] をクリックします。

  3. 変更する DB インスタンスを選択します。

  4. [Modify] を選択します。

  5. []データベースの選択肢で、IAM DB 認証を有効にする

  6. [Continue] を選択します。

  7. []変更のスケジュールで、修正を適用するタイミングを選択します。オプションは次のとおりです。Apply during the next scheduled maintenance window (次に予定されているメンテナンス期間中に適用)またはすぐに適用

  8. クラスタの場合は、Modify DB Instance

[RDS.12] IAM 認証は RDS クラスター用に設定する必要があります

カテゴリ: 保護-セキュアなアクセス管理-パスワードレス認証

緊急度: ミディアム

リソースタイプ: AWS::RDS::DBCluster,AWS::RDS::DBInstance

AWS Config ルール: rds_cluster_iam_authentication_enabled

パラメータ: なし

このコントロールは、RDS DB クラスターで IAM データベース認証が有効になっているかどうかをチェックします。

IAM データベース認証では、データベースインスタンスへのパスワードなしの認証が可能です。認証は、認証トークンを使用します。データベースとの間で送受信されるネットワークトラフィックは、SSL を使用して暗号化されます。詳細については、「」を参照してください。IAM データベース認証Amazon Aurora ユーザーガイド

注記

このコントロールは、次のリージョンではサポートされていません。

  • アジアパシフィック (大阪)

  • 中国 (北京)

  • 中国 (寧夏)

  • 中東 (バーレーン)

  • 南米 (サンパウロ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

DB クラスターの IAM 認証は、Amazon RDS コンソールから有効にできます。

既存の DB クラスターに対して IAM 認証を有効にするには

  1. Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. [データベース] をクリックします。

  3. 変更する DB クラスターを選択します。

  4. [Modify] を選択します。

  5. []データベースの選択肢を選択し、IAM DB 認証を有効にする

  6. [Continue] を選択します。

  7. []変更のスケジュールで、修正を適用するタイミングを選択します。Apply during the next scheduled maintenance window (次に予定されているメンテナンス期間中に適用)またはすぐに適用

  8. [Modify cluster] (クラスターの変更) を選択します。

[RDS.13] RDS 自動マイナーバージョンアップグレードを有効にする必要があります

カテゴリ: 検出 > 脆弱性およびパッチ管理

緊急度:

リソースタイプ: AWS::RDS::DBInstance

AWS Config ルール: rds_automatic_minor_version_upgrade_enabled

パラメータ: なし

このコントロールは、RDS データベースインスタンスでマイナーバージョンの自動アップグレードが有効になっているかどうかをチェックします。

マイナーバージョンの自動アップグレードを有効にすると、リレーショナルデータベース管理システム (RDBMS) に対する最新のマイナーバージョンの更新がインストールされます。これらのアップグレードには、セキュリティパッチとバグ修正が含まれる場合があります。パッチのインストールを最新の状態に保つことは、システムを保護する上で重要なステップです。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アジアパシフィック (大阪)

  • 中国 (北京)

  • 中国 (寧夏)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

DB インスタンスのマイナーバージョンのアップグレードは、Amazon RDS コンソールから有効にできます。

既存の DB インスタンスのマイナーバージョン自動アップグレードを有効にするには

  1. Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. [データベース] をクリックします。

  3. 変更する DB インスタンスを選択します。

  4. [Modify] を選択します。

  5. []メンテナンスを選択し、はいforマイナーバージョン自動アップグレード

  6. [Continue] を選択します。

  7. []変更のスケジュールで、修正を適用するタイミングを選択します。Apply during the next scheduled maintenance window (次に予定されているメンテナンス期間中に適用)またはすぐに適用

  8. [DB インスタンスの変更] を選択します。

[RDS.14] Amazon Aurora クラスターはバックトラッキングを有効にする必要があります

カテゴリ: リカバリ > レジリエンス > バックアップの有効化

緊急度: ミディアム

リソースタイプ: AWS::RDS::DBCluster

AWS Config ルール: aurora-mysql-backtracking-enabled

パラメータ: なし

このコントロールは、Amazon Aurora クラスターがバックトラッキングが有効になっているかどうかをチェックします。

バックアップは、セキュリティインシデントからより迅速にリカバリするのに役立ちます。また、システムの復元力を強化します。Aurora バックトラッキングにより、データベースを特定の時点にリカバリする時間が短縮されます。そのためには、データベースの復元は必要ありません。

Aurora でのバックトラックの詳細については、「」を参照してください。Aurora DB クラスターのバックトラックAmazon Aurora ユーザーガイド

注記

このコントロールは、次のリージョンではサポートされていません。

  • アフリカ (ケープタウン)

  • アジアパシフィック (香港)

  • アジアパシフィック (大阪)

  • 中国 (北京)

  • 中国 (寧夏)

  • ヨーロッパ (ミラノ)

  • 欧州 (ストックホルム)

  • 中東 (バーレーン)

  • 南米 (サンパウロ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

Aurora バックトラッキングを有効にする方法の詳細については、「」を参照してください。バックトラックの設定Amazon Aurora ユーザーガイド

既存のクラスターではバックトラッキングを有効にできないことに注意してください。代わりに、バックトラッキングが有効になっているクローンを作成できます。Aurora バックトラッキングの制限の詳細については、「」の制限事項の一覧を参照してください。バックトラックの概要

バックトラッキングの料金については、Aurora の価格ページ

[RDS.15] RDS DB クラスターを複数のアベイラビリティーゾーン用に設定する必要があります

カテゴリ: リカバリ > レジリエンス > 高可用性

緊急度: ミディアム

リソースタイプ: AWS::RDS::DBCluster

AWS Config ルール: rds-cluster-multi-az-enabled

パラメータ: なし

このコントロールは、RDS DB クラスターに対して高可用性が有効になっているかどうかを確認します。

RDS DB クラスターは、格納されるデータの可用性を確保するために、複数のアベイラビリティーゾーン用に設定する必要があります。複数のアベイラビリティーゾーンにデプロイすると、アベイラビリティーゾーンの可用性の問題が発生した場合や、通常の RDS メンテナンスイベント中に自動フェイルオーバーが可能になります。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アジアパシフィック (大阪)

  • 中国 (北京)

  • 中国 (寧夏)

  • 中東 (バーレーン)

  • 南米 (サンパウロ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

このコントロールを修正するには、DB クラスターを複数のアベイラビリティーゾーン用に設定します。

DB クラスターでマルチ AZ を有効にするには

  1. Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[データベースをクリックし、変更する DB インスタンスを選択します。

  3. [Modify] を選択します。[Modify DB Instance] ページが表示されます。

  4. []インスタンス仕様, セットマルチ AZ 配置はい

  5. [Continue] を選択して、変更の概要を確認します。

  6. (省略可能) 変更をすぐに適用するには、[すぐに適用] を選択します。このオプションを選択すると、停止状態になる場合があります。詳細については、「」を参照してください。[すぐに適用] 設定を使用するAmazon RDS ユーザーガイド

    確認ページで、変更内容を確認します。正しい場合は、以下を選択します。Modify DB Instance

[RDS.16] タグをスナップショットにコピーするように RDS DB クラスターを構成する必要があります

カテゴリ: 識別-インベントリ

緊急度:

リソースタイプ: AWS::RDS::DBCluster

AWS Config ルール: rds-cluster-copy-tags-to-snapshots-enabled (Security Hub が開発したカスタムルール)

パラメータ: なし

このコントロールは、スナップショットの作成時にすべてのタグをスナップショットにコピーするように RDS DB クラスターが設定されているかどうかをチェックします。

IT アセットの特定とインベントリは、ガバナンスとセキュリティの重要な側面です。セキュリティの状態を評価し、潜在的な弱点に対処するには、すべての RDS DB クラスターが見えていなければなりません。スナップショットは、親 RDS データベースクラスターと同じ方法でタグ付けする必要があります。この設定を有効にすると、スナップショットが親データベースクラスターのタグを継承します。

注記

このコントロールは、次のリージョンではサポートされていません。

  • 中国 (北京)

  • 中東 (バーレーン)

  • 南米 (サンパウロ)

Remediation

DB クラスターのスナップショットへの自動タグコピーを有効にするには

  1. Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. [データベース] をクリックします。

  3. 変更する DB クラスターを選択します。

  4. [Modify] を選択します。

  5. []バックアップを選択し、Copy tags to snapshots

  6. [Continue] を選択します。

  7. []変更のスケジュールで、修正を適用するタイミングを選択します。次のいずれかを選択できます。Apply during the next scheduled maintenance window (次に予定されているメンテナンス期間中に適用)またはすぐに適用

[RDS.17] RDS DB インスタンスは、タグをスナップショットにコピーするように設定する必要があります

カテゴリ: 識別-インベントリ

緊急度:

リソースタイプ: AWS::RDS::DBInstance

AWS Config ルール: rds-instance-copy-tags-to-snapshots-enabled (Security Hub が開発したカスタムルール)

パラメータ: なし

このコントロールは、スナップショットの作成時にすべてのタグをスナップショットにコピーするように RDS DB インスタンスが構成されているかどうかをチェックします。

IT アセットの特定とインベントリは、ガバナンスとセキュリティの重要な側面です。セキュリティの状態を評価し、潜在的な弱点に対処するには、すべての RDS DB インスタンスを可視化する必要があります。スナップショットは、親の RDS データベースインスタンスと同じ方法でタグ付けする必要があります。この設定を有効にすると、スナップショットが親データベースインスタンスのタグを継承します。

Remediation

DB インスタンスのスナップショットへの自動タグコピーを有効にするには

  1. Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. [データベース] をクリックします。

  3. 変更する DB インスタンスを選択します。

  4. [Modify] を選択します。

  5. []バックアップを選択し、Copy tags to snapshots

  6. [Continue] を選択します。

  7. []変更のスケジュールで、修正を適用するタイミングを選択します。次のいずれかを選択できます。Apply during the next scheduled maintenance window (次に予定されているメンテナンス期間中に適用)またはすぐに適用

[RDS.18] RDS インスタンスは VPC にデプロイする必要があります

カテゴリ: 保護-セキュアなネットワーク構成 > VPC 内のリソース

緊急度:

リソースタイプ: AWS::RDS::DBInstance

AWS Config ルール: rds-deployed-in-vpc (Security Hub が開発したカスタムルール)

パラメータ: なし

このコントロールは、RDS インスタンスが VPC (EC2-VPC) にデプロイされているかどうかをチェックします。

VPC は、RDS リソースへのアクセスを保護するための多数のネットワーク制御を提供します。これらのコントロールには、VPC エンドポイント、ネットワーク ACL、セキュリティグループが含まれます。これらのコントロールを利用するには、EC2-Classic RDS インスタンスを EC2-VPC に移動することをお勧めします。

Remediation

RDS インスタンスを VPC に移動する方法の詳細については、「」を参照してください。DB インスタンスの VPC の更新Amazon RDS ユーザーガイド

[RDS.19] 重要なクラスターイベントに対して RDS イベント通知サブスクリプションを構成する必要があります

カテゴリ: 検出-検出サービス-アプリケーション監視

緊急度:

リソースタイプ: AWS::RDS::EventSubscription

AWS Config ルール: rds-cluster-event-notifications-configured (Security Hub が開発したカスタムルール)

パラメータ: なし

このコントロールは、次のソースタイプ、イベントカテゴリのキーと値のペアに対して通知が有効になっている Amazon RDS イベントサブスクリプションが存在するかどうかをチェックします。

DBCluster: ["maintenance","failure"]

RDS イベント通知は Amazon SNS を使用して、RDS リソースの可用性または構成の変更を認識させます。これらの通知により、迅速な対応が可能になります。RDS イベント通知の詳細については、「」を参照してください。Amazon RDS イベント通知の使用Amazon RDS ユーザーガイド

Remediation

RDS クラスターイベント通知にサブスクライブするには

  1. Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[イベントサブスクリプション] を選択します。

  3. []イベントサブスクリプションで、イベントサブスクリプションを作成

  4. イベントサブスクリプションを作成] ダイアログで、次の操作を行います。

    1. [名前] に、イベント通知サブスクリプションの名前を入力します。

    2. を使用する場合通知の送信先で、SNS トピックに対して既存の Amazon SNS ARN を選択します。新しいトピックを使用するには、トピックの作成をクリックしてトピックの名前と受取人のリストを入力します。

    3. を使用する場合Source タイプで、クラスター

    4. []含めるインスタンスを選択し、すべてのクラスタ

    5. []含めるイベントカテゴリを選択し、特定のイベントカテゴリ。選択した場合も、コントロールは通過します。すべてのイベントカテゴリ

    6. Selectメンテナンスおよびfailure

    7. [作成] を選択します。

[RDS.20] 重要なデータベースインスタンスイベントに対して RDS イベント通知サブスクリプションを構成する必要があります

カテゴリ: 検出-検出サービス-アプリケーション監視

緊急度:

リソースタイプ: AWS::RDS::EventSubscription

AWS Config ルール: rds-instance-event-notifications-configured (Security Hub が開発したカスタムルール)

パラメータ: なし

このコントロールは、次のソースタイプ、イベントカテゴリのキーと値のペアに対して通知が有効になっている Amazon RDS イベントサブスクリプションが存在するかどうかをチェックします。

DBInstance: ["maintenance","configuration change","failure"]

RDS イベント通知は Amazon SNS を使用して、RDS リソースの可用性または構成の変更を認識させます。これらの通知により、迅速な対応が可能になります。RDS イベント通知の詳細については、「」を参照してください。Amazon RDS イベント通知の使用Amazon RDS ユーザーガイド

Remediation

RDS インスタンスイベント通知にサブスクライブするには

  1. Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[イベントサブスクリプション] を選択します。

  3. []イベントサブスクリプションで、イベントサブスクリプションを作成

  4. イベントサブスクリプションを作成] ダイアログで、次の操作を行います。

    1. [名前] に、イベント通知サブスクリプションの名前を入力します。

    2. を使用する場合通知の送信先で、SNS トピックに対して既存の Amazon SNS ARN を選択します。新しいトピックを使用するには、トピックの作成をクリックしてトピックの名前と受取人のリストを入力します。

    3. を使用する場合Source タイプで、インスタンス

    4. []含めるインスタンスを選択し、すべてのインスタンス

    5. []含めるイベントカテゴリを選択し、特定のイベントカテゴリ。選択した場合も、コントロールは通過します。すべてのイベントカテゴリ

    6. Selectメンテナンス,設定変更, およびfailure

    7. [作成] を選択します。

[RDS.21] 重要なデータベースパラメータグループイベントに対して RDS イベント通知サブスクリプションを構成する必要があります

カテゴリ: 検出-検出サービス-アプリケーション監視

緊急度:

リソースタイプ: AWS::RDS::EventSubscription

AWS Config ルール: rds-pg-event-notifications-configured (Security Hub が開発したカスタムルール)

パラメータ: なし

このコントロールは、次のソースタイプ、イベントカテゴリのキーと値のペアに対して通知が有効になっている Amazon RDS イベントサブスクリプションが存在するかどうかをチェックします。

DBParameterGroup: ["configuration change"]

RDS イベント通知は Amazon SNS を使用して、RDS リソースの可用性または構成の変更を認識させます。これらの通知により、迅速な対応が可能になります。RDS イベント通知の詳細については、「」を参照してください。Amazon RDS イベント通知の使用Amazon RDS ユーザーガイド

Remediation

RDS データベースパラメータグループイベント通知にサブスクライブするには

  1. Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[イベントサブスクリプション] を選択します。

  3. []イベントサブスクリプションで、イベントサブスクリプションを作成

  4. イベントサブスクリプションを作成] ダイアログで、次の操作を行います。

    1. [名前] に、イベント通知サブスクリプションの名前を入力します。

    2. を使用する場合通知の送信先で、SNS トピックに対して既存の Amazon SNS ARN を選択します。新しいトピックを使用するには、トピックの作成をクリックしてトピックの名前と受取人のリストを入力します。

    3. を使用する場合Source タイプで、パラメータグループ

    4. []含めるインスタンスを選択し、すべてのパラメータグループ

    5. []含めるイベントカテゴリを選択し、特定のイベントカテゴリ。選択した場合も、コントロールは通過します。すべてのイベントカテゴリ

    6. Select設定変更

    7. [作成] を選択します。

[RDS.22] 重要なデータベースセキュリティグループイベントに対して RDS イベント通知サブスクリプションを構成する必要があります

カテゴリ: 検出 > 検出サービス > アプリケーション監視

緊急度:

リソースタイプ: AWS::RDS::EventSubscription

AWS Config ルール: rds-sg-event-notifications-configured (Security Hub が開発したカスタムルール)

パラメータ: なし

このコントロールは、次のソースタイプ、イベントカテゴリのキーと値のペアに対して通知が有効になっている Amazon RDS イベントサブスクリプションが存在するかどうかをチェックします。

DBSecurityGroup: ["configuration change","failure"]

RDS イベント通知は Amazon SNS を使用して、RDS リソースの可用性または構成の変更を認識させます。これらの通知により、迅速な対応が可能になります。RDS イベント通知の詳細については、「」を参照してください。Amazon RDS イベント通知の使用Amazon RDS ユーザーガイド

Remediation

RDS データベースセキュリティグループのイベント通知をサブスクライブするには

  1. Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[イベントサブスクリプション] を選択します。

  3. []イベントサブスクリプションで、イベントサブスクリプションを作成

  4. イベントサブスクリプションを作成] ダイアログで、次の操作を行います。

    1. [名前] に、イベント通知サブスクリプションの名前を入力します。

    2. を使用する場合通知の送信先で、SNS トピックに対して既存の Amazon SNS ARN を選択します。新しいトピックを使用するには、トピックの作成をクリックしてトピックの名前と受取人のリストを入力します。

    3. を使用する場合Source タイプで、セキュリティグループ

    4. []含めるインスタンスを選択し、すべてのセキュリティグループ

    5. []含めるイベントカテゴリを選択し、特定のイベントカテゴリ。選択した場合も、コントロールは通過します。すべてのイベントカテゴリ

    6. Select設定変更およびfailure

    7. [作成] を選択します。

[RDS.23] RDS データベースとクラスターはデータベースエンジンのデフォルトポートを使用すべきではない

カテゴリ: 保護-セキュアなネットワーク設定

緊急度:

リソースタイプ: AWS::RDS::DBInstance

AWS Config ルール: rds-no-default-ports (Security Hub が開発したカスタムルール)

パラメータ: なし

このコントロールは、RDS クラスターまたはインスタンスがデータベースエンジンのデフォルトポート以外のポートを使用しているかどうかをチェックします。

既知のポートを使用して RDS クラスターまたはインスタンスをデプロイすると、攻撃者はクラスターまたはインスタンスに関する情報を推測する可能性があります。攻撃者は、この情報を他の情報と組み合わせて RDS クラスターまたはインスタンスに接続したり、アプリケーションに関する追加情報を取得したりできます。

ポートを変更するときは、古いポートへの接続に使用された既存の接続文字列も更新する必要があります。また、DB インスタンスのセキュリティグループをチェックして、新しいポートでの接続を許可するイングレスルールが含まれていることを確認する必要があります。

Remediation

既存の DB インスタンスのデフォルトポートを変更するには

  1. Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. [データベース] をクリックします。

  3. 変更する DB インスタンスを選択します。

  4. [Modify] を選択します。

  5. []データベースの選択肢の変更点データベースポートをデフォルト以外の値に設定します。

  6. [Continue] を選択します。

  7. []変更のスケジュールで、修正を適用するタイミングを選択します。次のいずれかを選択できます。Apply during the next scheduled maintenance window (次に予定されているメンテナンス期間中に適用)またはすぐに適用

  8. クラスタの場合は、クラスターの変更。インスタンスについては、Modify DB Instance

[Redshift.1] Amazon Redshift クラスターはパブリックアクセスを禁止する必要があります

カテゴリ: 保護-セキュアなネットワーク構成 > リソースはパブリックアクセスできません

緊急度: 非常事態

リソースタイプ: AWS::Redshift::Cluster

AWS Config ルール: redshift-cluster-public-access-check

パラメータ: なし

このコントロールは、Amazon Redshift クラスターがパブリックにアクセス可能かどうかをチェックします。それは評価しますPubliclyAccessibleクラスタ構成項目の [] フィールド。

-PubliclyAccessibleAmazon Redshift クラスター設定の属性は、クラスターがパブリックにアクセスできるかどうかを示します。クラスタがで構成されている場合PubliclyAccessibleに設定します。trueは、パブリック IP アドレスに解決されるパブリックに解決可能な DNS 名を持つインターネットに直接接続するインスタンスです。

クラスターがパブリックにアクセスできない場合、プライベート IP アドレスを解決する DNS 名をともなう内部インスタンスです。クラスターがパブリックにアクセスできるようにする予定がない限り、クラスターはPubliclyAccessibleに設定します。true

Remediation

この問題を解決するには、Amazon Redshift クラスターを更新して、パブリックアクセスを無効にします。

Amazon Redshift クラスターへのパブリックアクセスを無効にするには

  1. Amazon Redshift コンソール (https://console.aws.amazon.com/redshift/) を開きます。

  2. ナビゲーションメニューで、[クラスターを選択し、変更するセキュリティグループを含むクラスターの名前を選択します。

  3. 選択アクション[]、[]パブリックにアクセス可能かどうかの変更

  4. []VPC 外のインスタンスとデバイスがクラスターエンドポイントを介してデータベースに接続することを許可するで、なし

  5. [Confirm] を選択します。

[Redshift.2] Amazon Redshift クラスターへの接続は転送中に暗号化する必要があります

カテゴリ: 保護-転送中のデータの暗号化

緊急度: ミディアム

リソースタイプ: AWS::Redshift::Cluster

AWS Config ルール: redshift-require-tls-ssl

パラメータ: なし

このコントロールは、転送中に暗号化を使用するために Amazon Redshift クラスターへの接続が必要かどうかをチェックします。Amazon Redshift クラスターパラメーターの場合、チェックは失敗しますrequire_SSLが 1 に設定されていません。

TLS を使用すると、潜在的な攻撃者が中間者攻撃または同様の攻撃を使用してネットワークトラフィックを盗聴または操作することを防止できます。TLS 経由の暗号化された接続のみを許可する必要があります。転送中のデータの暗号化は、パフォーマンスに影響する可能性があります。TLS のパフォーマンスプロファイルと TLS の影響を理解するには、この機能を使用してアプリケーションをテストする必要があります。

注記

このコントロールは、欧州 (ミラノ) ではサポートされていません。

Remediation

この問題を解決するには、暗号化を要求するようにパラメータグループを更新します。

パラメータグループを変更するには

  1. Amazon Redshift コンソール (https://console.aws.amazon.com/redshift/) を開きます。

  2. ナビゲーションメニューで、[設定[]、[]ワークロード管理を表示するにはワークロード管理ページで.

  3. 変更するパラメータグループを選択します。

  4. 選択パラメータ

  5. 選択パラメータの編集で設定します。require_ssl[1.

  6. 変更を入力して、[] を選択します。保存

[Redshift.3] Amazon Redshift クラスターで自動スナップショットが有効になっている必要があります

カテゴリ: リカバリ > レジリエンス > バックアップの有効化

緊急度: ミディアム

リソースタイプ: AWS::Redshift::Cluster

AWS Config ルール: redshift-backup-enabled

パラメータ:

  • MinRetentionPeriod = 7

このコントロールは、Amazon Redshift クラスターで自動スナップショットが有効になっているかどうかをチェックします。また、スナップショットの保存期間が 7 以上であるかどうかを確認します。

バックアップは、セキュリティインシデントからより迅速にリカバリするのに役立ちます。これにより、システムのレジリエンスが強化されます。Amazon Redshift は、デフォルトで定期的にスナップショットを作成します。このコントロールは、自動スナップショットが有効になっていて 7 日間以上保存されているかどうかを確認します。Amazon Redshift 自動スナップショットの詳細については、「」を参照してください。自動スナップショットAmazon Redshift クラスター管理ガイド

注記

このコントロールは、次のリージョンではサポートされていません。

  • アフリカ (ケープタウン)

  • アジアパシフィック (大阪)

  • アジアパシフィック (シドニー)

  • 中国 (寧夏)

  • ヨーロッパ (ミラノ)

Remediation

この問題を修復するには、スナップショットの保存期間を少なくとも 7 に更新します。

スナップショットの保持期間を変更するには

  1. Amazon Redshift コンソール (https://console.aws.amazon.com/redshift/) を開きます。

  2. ナビゲーションメニューで、[クラスターを選択し、変更するクラスターの名前を選択します。

  3. [編集] を選択します。

  4. []バックアップ, セットスナップショット保持期限を 7 以上の値にします。

  5. [クラスターの変更] をクリックします。

[Redshift.4] Amazon Redshift クラスターで監査ログが有効になっている必要があります

カテゴリ: 識別-ログ記録

緊急度: ミディアム

リソースタイプ: AWS::Redshift::Cluster

AWS Config ルール: redshift-cluster-audit-logging-enabled (Security Hub が開発したカスタムルール)

パラメータ:

  • loggingEnabled = true

このコントロールは、Amazon Redshift クラスターで監査ログが有効になっているかどうかをチェックします。

Amazon Redshift 監査ログは、クラスター内の接続とユーザーアクティビティに関する追加情報を提供します。このデータは Amazon S3 に保存および保護することができ、セキュリティ監査や調査に役立ちます。詳細については、「」を参照してください。データベース監査ログ作成Amazon Redshift クラスター管理ガイド

Remediation

クラスター監査ログを有効にするには

  1. Amazon Redshift コンソール (https://console.aws.amazon.com/redshift/) を開きます。

  2. ナビゲーションメニューで、[クラスターを選択し、変更するクラスターの名前を選択します。

  3. 選択メンテナンスと監視

  4. []監査ログで、編集

  5. 設定監査ログ作成を有効にするyesをクリックし、ログの宛先バケットの詳細を入力します。

  6. [Confirm] を選択します。

[Redshift.6] Amazon Redshift でメジャーバージョンへの自動アップグレードが有効になっている必要があります

カテゴリ: 検出 > 脆弱性およびパッチ管理

緊急度: ミディアム

リソースタイプ: AWS::Redshift::Cluster

AWS Config ルール: redshift-cluster-maintenancesettings-check

パラメータ:

  • allowVersionUpgrade = true

このコントロールは、Amazon Redshift クラスターでメジャーバージョンの自動アップグレードが有効になっているかどうかをチェックします。

自動メジャーバージョンアップグレードを有効にすると、メンテナンス期間中に Amazon Redshift クラスターの最新のメジャーバージョンの更新がインストールされます。これらのアップデートには、セキュリティパッチやバグ修正が含まれる場合があります。パッチのインストールを最新の状態に保つことは、システムを保護する上で重要なステップです。

注記

このコントロールは、中東 (バーレーン) ではサポートされていません。

Remediation

この問題を修正するにはAWS CLIで、Amazon Redshift を使うmodify-clusterコマンドを設定して--allow-version-upgrade属性。

aws redshift modify-cluster --cluster-identifier clustername --allow-version-upgrade

各パラメータの意味は次のとおりです。clusternameは Amazon Redshift クラスターの名前です。

[Redshift.7] Amazon Redshift クラスターは拡張 VPC ルーティングを使用する必要があります

カテゴリ: 保護 > セキュアなネットワーク構成 > API プライベートアクセス

緊急度:

リソースタイプ: AWS::Redshift::Cluster

AWS Config ルール: redshift_enhanced_vpc_routing_enabled

パラメータ: なし

このコントロールは Amazon Redshift クラスターが持っているかどうかをチェックします。EnhancedVpcRouting有効.

拡張 VPC のルーティングCOPYおよびUNLOADVPC を通過するためのクラスターとデータリポジトリ間のトラフィック。その後、セキュリティグループやネットワークアクセスコントロールリストなどの VPC 機能を使用して、ネットワークトラフィックを保護できます。VPC フローログを使用して、ネットワークトラフィックを監視することもできます。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アジアパシフィック (大阪)

  • 中国 (北京)

  • 中国 (寧夏)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

詳細な修復手順については、「」を参照してください。拡張された VPC ルーティングの有効化Amazon Redshift クラスター管理ガイド

[S3.1] S3 ブロックパブリックアクセス設定を有効にする必要があります

カテゴリ: 保護-セキュアなネットワーク設定

緊急度: ミディアム

リソースタイプ: AWSアカウント

AWS Config ルール: s3-account-level-public-access-blocks-periodic

パラメータ:

  • ignorePublicAcls: true

  • blockPublicPolicy: true

  • blockPublicAcls: true

  • restrictPublicBuckets: true

このコントロールは、次の Amazon S3 パブリックアクセスブロック設定がアカウントレベルで設定されているかどうかをチェックします。

  • ignorePublicAcls: true

  • blockPublicPolicy: true

  • blockPublicAcls: true

  • restrictPublicBuckets: true

パブリックアクセスブロックの設定がすべてに設定されている場合、コントロールは渡されます。true

いずれかの設定が [] に設定されていると、コントロールは失敗します。false、または設定のいずれかが構成されていない場合。

Amazon S3 パブリックアクセスブロックは、全体にわたってコントロールを提供するように設計されていますAWSアカウントまたは個々の S3 バケットレベルで、オブジェクトがパブリックアクセスを決して持たないようにします。パブリックアクセスは、アクセスコントロールリスト (ACL)、バケットポリシー、またはその両方からバケットおよびオブジェクトに付与されます。

S3 バケットをパブリックにアクセスできるようにする場合を除き、アカウントレベルの Amazon S3 ブロックパブリックアクセス機能を設定する必要があります。

詳細については、次を参照してください。Amazon S3 の使用パブリックアクセスブロックAmazon Simple Storage Service ユーザーガイド

注記

このコントロールは、次のリージョンではサポートされていません。

  • アフリカ (ケープタウン)

  • ヨーロッパ (ミラノ)

  • 中東 (バーレーン)

Remediation

この問題を解決するには、[Amazon S3 パブリックアクセスのブロック] を有効にします。

Amazon S3 パブリックアクセスブロックを有効にするには

  1. https://console.aws.amazon.com/s3/ で Amazon S3 コンソールを開きます。

  2. [Block public access (account settings) (ブロックパブリックアクセス (アカウント設定))] を選択します。

  3. [編集] を選択します。

  4. Selectブロックすべてパブリックアクセス

  5. [変更を保存] を選択します。

詳細については、「」を参照してください。Amazon S3 のパブリックアクセスブロックの使用Amazon Simple Storage Service ユーザーガイド

[S3.2] S3 バケットではパブリック読み取りアクセスを禁止する必要があります

カテゴリ: 保護-セキュアなネットワーク設定

緊急度: 非常事態

リソースタイプ: AWS::S3::Bucket

AWS Config ルール: s3-bucket-public-read-prohibited

パラメータ: なし

このコントロールは、S3 バケットがパブリック読み取りアクセスを許可するかどうかをチェックします。これにより、ブロックパブリックアクセス設定、バケットポリシー、およびバケットアクセスコントロールリスト (ACL) を確認します。

ユースケースによっては、インターネット上の全員が S3 バケットから読み取れる必要があります。しかし、そのような状況はまれです。データの整合性とセキュリティを確保するために、S3 バケットをパブリックに読み取り可能にしないでください。

Remediation

この問題を解決するには、S3 バケットを更新してパブリックアクセスを削除します。

S3 バケットからパブリックアクセスを削除するには

  1. https://console.aws.amazon.com/s3/ で Amazon S3 コンソールを開きます。

  2. 左のナビゲーションペインで、[] を選択します。バケット

  3. 更新する S3 バケットの名前を選択します。

  4. 選択アクセス許可[] を選択して [] を選択しますパブリックアクセスのブロック

  5. [編集] を選択します。

  6. Selectブロックすべてパブリックアクセス。次に、[Save ] を選択します。

  7. プロンプトが表示されたら、confirm を入力し、[確認] を選択します。

[S3.3] S3 バケットはパブリック書き込みアクセスを禁止する必要があります

カテゴリ: 保護-セキュアなネットワーク設定

緊急度: 非常事態

リソースタイプ: AWS::S3::Bucket

AWS Config ルール: s3-bucket-public-write-prohibited

パラメータ: なし

このコントロールは、S3 バケットがパブリック書き込みアクセスを許可するかどうかをチェックします。これにより、ブロックパブリックアクセス設定、バケットポリシー、およびバケットアクセスコントロールリスト (ACL) を確認します。

ユースケースによっては、インターネット上の全員が S3 バケットに書き込むことができる必要があります。しかし、そのような状況はまれです。データの整合性とセキュリティを確保するため、S3 バケットはパブリックに書き込み可能にしないでください。

Remediation

この問題を解決するには、S3 バケットを更新してパブリックアクセスを削除します。

S3 バケットに対するパブリックアクセスを削除するには

  1. https://console.aws.amazon.com/s3/ で Amazon S3 コンソールを開きます。

  2. 左のナビゲーションペインで、[] を選択します。バケット

  3. 更新する S3 バケットの名前を選択します。

  4. 選択アクセス許可[] を選択して [] を選択しますパブリックアクセスのブロック

  5. [編集] を選択します。

  6. Selectブロックすべてパブリックアクセス。次に、[Save ] を選択します。

  7. プロンプトが表示されたら、confirm を入力し、[確認] を選択します。

[S3.4] S3 バケットでは、サーバー側の暗号化を有効にする必要があります

カテゴリ: 保護-データ保護-保管中のデータの暗号化

緊急度: ミディアム

リソースタイプ: AWS::S3::Bucket

AWS Config ルール: s3-bucket-server-side-encryption-enabled

パラメータ: なし

このコントロールは、S3 バケットでの Amazon S3 デフォルトの暗号化が有効になっていること、または S3 バケットポリシーでサーバー側の暗号化なしの put-object リクエストを明示的に拒否することを確認します。

S3 バケット内の機密データのセキュリティを強化するには、サーバー側の暗号化を使用してバケットを設定し、保管中のデータを保護する必要があります。各オブジェクトは一意なキーで暗号化されます。さらにセキュリティを強化するために、キー自体が、定期的に更新されるマスターキーで暗号化されます。Amazon S3 のサーバー側の暗号化では、データを暗号化するための最強のブロック暗号の一つである、256 ビットの高度暗号化規格 (AES-256) を使用します。

詳細については、次を参照してください。Amazon S3 が管理する暗号化キーによるサーバー側の暗号化 (SSE-S3) を使用したデータの保護Amazon Simple Storage Service ユーザーガイド

Remediation

この問題を解決するには、S3 バケットを更新して、デフォルトの暗号化を有効にします。

S3 バケットのデフォルト暗号化を有効にする

  1. https://console.aws.amazon.com/s3/ で Amazon S3 コンソールを開きます。

  2. 左のナビゲーションペインで、[] を選択します。バケット

  3. リストから S3 バケットを選択します。

  4. [プロパティ] を選択します。

  5. [Default encryption (デフォルト暗号化)] を選択します。

  6. 暗号化には、[] のいずれかを選択します。AES-256またはAWS-KMS

    • 選択AES-256は、Amazon S3 によって管理されるキーをデフォルトの暗号化に使用します。Amazon S3 のサーバー側の暗号化を使用してデータを暗号化する方法の詳細については、「」を参照してください。Amazon Simple Storage Service ユーザーガイド

    • 選択AWS-KMSによって管理されるキーを使用するにはAWS KMSデフォルト暗号化の場合。次に、作成したマスターキーのリストから AWS KMS マスターキーを選択します。

      使用する AWS KMS キーの Amazon リソースネーム (ARN) を入力します。の ARN は、AWS KMSIAM コンソールの [] のキー、[] の [暗号化キー。または、ドロップダウンリストからキー名を選択します。

      重要

      デフォルト暗号化設定に AWS KMS オプションを使用する場合、AWS KMS の RPS (1 秒あたりのリクエスト) のクォータが適用されます。の詳細AWS KMSクォータとクォータの引き上げをリクエストする方法については、「」を参照してください。AWS Key Management Serviceデベロッパーガイド

      の作成の詳細については、「」を参照してください。AWS KMSキー、「」を参照してください。AWS Key Management Serviceデベロッパーガイド

      の使用方法の詳細については、「」を参照AWS KMSAmazon S3 では、を参照してください。Amazon Simple Storage Service ユーザーガイド

    デフォルト暗号化を有効にする際、バケットポリシーの更新が必要な場合があります。バケットポリシーからデフォルトの暗号化への移行の詳細については、「」Amazon Simple Storage Service ユーザーガイド

  7. [Save] を選択します。

デフォルトの S3 バケット暗号化の詳細については、「」を参照してください。Amazon Simple Storage Service ユーザーガイド

[S3.5] S3 バケットは、Secure Socket Layer を使用するためのリクエストが必要です

カテゴリ: 保護-セキュアなアクセス管理

緊急度: ミディアム

[リソースタイプ]: AWS::S3::Bucket

AWS Config ルール: s3-bucket-ssl-requests-only

パラメータ: なし

このコントロールは、S3 バケットのポリシーで、Secure Socket Layer (SSL) を使用するためのリクエストが必須とされているかどうかを確認します。

S3 バケットには、すべてのリクエストを必要とするポリシーが必要です (Action: S3:*) は、条件キーで示される S3 リソースポリシーの HTTPS 経由のデータ送信のみを受け入れます。aws:SecureTransport

Remediation

この問題を解決するには、S3 バケットのアクセス権限ポリシーを更新します。

非セキュアなトランスポートを拒否するように S3 バケットを設定するには

  1. https://console.aws.amazon.com/s3/ で Amazon S3 コンソールを開きます。

  2. 非準拠のバケットに移動し、バケット名を選択します。

  3. [Permissions (アクセス許可)] を選択し、[Bucket Policy (バケットポリシー)] を選択します。

  4. 以下のポリシーで、同様のポリシーステートメントを追加します。置換awsexamplebucket変更しているバケットの名前を入力します。

    { "Id": "ExamplePolicy", "Version": "2012-10-17", "Statement": [ { "Sid": "AllowSSLRequestsOnly", "Action": "s3:*", "Effect": "Deny", "Resource": [ "arn:aws:s3:::awsexamplebucket", "arn:aws:s3:::awsexamplebucket/*" ], "Condition": { "Bool": { "aws:SecureTransport": "false" } }, "Principal": "*" } ] }
  5. [Save] を選択します。

詳細については、ナレッジセンターの記事を参照してください。に準拠するには、どの S3 バケットポリシーを使用すればよいですか。AWS Configルールs3-bucket-ssl-requests-only?

[S3.6] 他のユーザーに付与された Amazon S3 のアクセス許可AWSバケットポリシーのアカウントは制限する必要があります

カテゴリ: 保護-セキュアなアクセス管理 > 機密な API オペレーションのアクションが制限されています

緊急度:

[リソースタイプ]: AWS::S3::Bucket

AWS Config ルール:s3-bucket-blacklisted-actions-prohibited

パラメータ:

  • blacklistedactionpatterns: s3:DeleteBucketPolicy, s3:PutBucketAcl, s3:PutBucketPolicy, s3:PutEncryptionConfiguration, s3:PutObjectAcl

このコントロールは、S3 バケットポリシーがプリンシパルを他からのプリンシパルを妨げるかどうかをチェックします。AWSアカウントが S3 バケット内のリソースに対して拒否されたアクションを実行できません。S3 バケットポリシーで、別のプリンシパル内のプリンシパルに対して次のいずれかのアクションが許可されている場合、コントロールは失敗します。AWSアカウント:

  • s3:DeleteBucketPolicy

  • s3:PutBucketAcl

  • s3:PutBucketPolicy

  • s3:PutEncryptionConfiguration

  • s3:PutObjectAcl

最小権限アクセスを実装することは、セキュリティリスクとエラーや悪意のあるインテントの影響を軽減するための基本となります。S3 バケットポリシーが外部アカウントからのアクセスを許可すると、内部者の脅威または攻撃者によってデータが漏洩する可能性があります。

-blacklistedactionpatternsパラメータを使用すると、S3 バケットのルールを正常に評価できます。パラメーターは、外部アカウントに、アクションパターンに含まれていないアクセス権を付与します。blacklistedactionpatternsリスト。

Remediation

この問題を解決するには、S3 バケットポリシーを編集してアクセス権限を削除します。

S3 バケットポリシーを編集するには

  1. https://console.aws.amazon.com/s3/ で Amazon S3 コンソールを開きます。

  2. バケット名 リストで、ポリシーを編集する S3 バケットの名前を選択します。

  3. [Permissions (アクセス許可)] を選択し、[Bucket Policy (バケットポリシー)] を選択します。

  4. バケットポリシーエディタテキストボックスで、次のいずれかの操作を行います。

    • 拒否されたアクションへのアクセスを他の人に付与するステートメントを削除するAWSアカウント

    • 許可された拒否されたアクションをステートメントから削除する

  5. [Save] を選択します。

[S3.8] バケットレベルで S3 ブロックパブリックアクセス設定を有効にする必要があります

カテゴリ: 保護-セキュアなアクセス管理-アクセス制御

緊急度:

[リソースタイプ]: AWS::S3::Bucket

AWS Config ルール: s3_bucket_level_public_access_prohibited

パラメータ:

  • excludedPublicBuckets(オプション) — 許可されている既知のパブリック S3 バケット名のカンマ区切りリスト。

このコントロールは S3 バケットにバケットレベルのパブリックアクセスブロックが適用されているかどうかを確認します。このコントロールが失敗するのは、次の設定のいずれかがに設定されている場合です。false:

  • ignorePublicAcls

  • blockPublicPolicy

  • blockPublicAcls

  • restrictPublicBuckets

S3 バケットレベルでパブリックアクセスをブロックすると、オブジェクトがパブリックアクセスを決して持たないようにコントロールが提供されます。パブリックアクセスは、アクセスコントロールリスト (ACL)、バケットポリシー、またはその両方からバケットおよびオブジェクトに付与されます。

S3 バケットをパブリックにアクセスできるようにする場合を除き、バケットレベルの Amazon S3 ブロックパブリックアクセス機能を設定する必要があります。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アジアパシフィック (大阪)

  • 中国 (北京)

  • 中国 (寧夏)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

バケットレベルでパブリックアクセスを削除する方法については、「」を参照してください。Amazon S3 ストレージへのパブリックアクセスのブロックAmazon S3 ユーザーガイド

[SageMaker.1] SageMaker ノートブックインスタンスは、インターネットに直接アクセスしてはいけません

カテゴリ: 保護-セキュアなネットワーク設定

緊急度:

[リソースタイプ]: AWS::SageMaker::NotebookInstance

AWS Config ルール: sagemaker-notebook-no-direct-internet-access

パラメータ: なし

このコントロールは、SageMaker ノートブックインスタンスで直接インターネットアクセスが無効になっているかどうかを確認します。これを行うために、この関数では、DirectInternetAccessノートブックインスタンスではフィールドが無効になっています。

VPC なしで SageMaker インスタンスを設定すると、デフォルトでインスタンスで直接インターネットアクセスが有効になります。VPC を使用してインスタンスを設定し、デフォルト設定をに変更する必要があります。Disable — VPC 経由でインターネットにアクセスする

ノートブックからモデルをトレーニングまたはホストするには、インターネットアクセスが必要です。インターネットアクセスを有効にするには、VPC に NAT ゲートウェイがあり、セキュリティグループにアウトバウンド接続が許可されていることを確認します。VPC 内のリソースにノートブックインスタンスを接続する方法の詳細については、「」を参照してください。ノートブックインスタンスを VPC 内のリソースConnect するAmazon SageMaker 開発者ガイド

また、SageMaker 設定へのアクセスが、許可されたユーザーのみに制限されていることを確認する必要があります。SageMaker の設定とリソースを変更するようにユーザーの IAM 権限を制限します。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アフリカ (ケープタウン)

  • 中国 (北京)

  • 中国 (寧夏)

  • ヨーロッパ (ミラノ)

  • AWS GovCloud (米国東部)

Remediation

ノートブックインスタンスの作成後は、インターネットアクセス設定を変更できないことに注意してください。停止、削除、再作成する必要があります。

直接インターネットアクセスを拒否するように SageMaker ノートブックインスタンスを構成するには

  1. で SageMaker コンソールを開きます。https://console.aws.amazon.com/sagemaker/

  2. に移動します。ノートブックインスタンス

  3. 直接インターネットアクセスが有効になっているインスタンスを削除します。インスタンスを選択し、以下を選択します。アクションを選択し、[停止] を選択します。

    インスタンスを停止したら、アクション[] の順に選択します。delete

  4. ノートブックインスタンスの作成を選択します。設定の詳細を入力します。

  5. [ネットワーク] セクションを展開し、[VPC]、[サブネット]、および [セキュリティグループ] を選択します。[]ダイレクトインターネットアクセスで、Disable — VPC 経由でインターネットにアクセスする

  6. ノートブックインスタンスの作成を選択します。

詳細については、「」を参照してください。ノートブックインスタンスを VPC 内のリソースConnect するAmazon SageMaker 開発者ガイド

[SecretsManager.1] Secrets Manager のシークレットは、自動ローテーションを有効にする必要があります

カテゴリ: 保護-セキュア開発

緊急度: ミディアム

[リソースタイプ]: AWS::SecretsManager::Secret

AWS Config ルール: secretsmanager-rotation-enabled-check

パラメータ: なし

このコントロールは、シークレットがに保存されているかどうかをチェックしますAWS Secrets Managerは自動回転で設定されます。

Secrets Manager は、組織のセキュリティ体制を改善するのに役立ちます。シークレットには、データベース認証情報、パスワード、サードパーティーの API キーが含まれます。Secrets Manager を使用すると、シークレットを一元的に保存したり、シークレットを自動的に暗号化したり、シークレットへのアクセスを制御したり、シークレットを安全かつ自動的にローテーションしたりできます。

Secrets Manager はシークレットをローテーションできます。ローテーションを使用して、長期のシークレットを短期のシークレットに置き換えることができます。シークレットをローテーションすると、不正なユーザーが侵害されたシークレットを使用できる期間が制限されます。このため、シークレットは頻繁にローテーションする必要があります。回転の詳細については、「」を参照してください。ローテーションAWS Secrets ManagerシークレットAWS Secrets Managerユーザーガイド

Remediation

この問題を修復するには、シークレットの自動ローテーションを有効にします。

シークレットの自動ローテーションを有効にするには

  1. Secrets Manager のコンソール (https://console.aws.amazon.com/secretsmanager/) を開きます。

  2. ローテーションが必要なシークレットを見つけるには、検索フィールドにシークレット名を入力します。

  3. ローテーションするシークレットを選択すると、シークレットの詳細ページが表示されます。

  4. []ローテーション構成で、回転の編集

  5. 送信元回転設定の編集で、自動回転を有効にする

  6. を使用する場合回転間隔を選択で、回転間隔を選択します。

  7. ローテーションの Lambda 関数を選択します。Lambda ローテーション関数のカスタマイズの詳細については、「」を参照してください。Lambda ローテーション関数の理解とカスタマイズAWS Secrets Managerユーザーガイド

  8. ローテーションのシークレットを設定するには、

Secrets Manager ローテーションの詳細については、「」を参照してください。ローテーションAWS Secrets ManagerシークレットAWS Secrets Managerユーザーガイド

[SecretsManager.2] 自動ローテーションで構成されたSecrets Manager のシークレットは正常にローテーションする必要があります

カテゴリ: 保護-セキュア開発

緊急度: ミディアム

[リソースタイプ]: AWS::SecretsManager::Secret

AWS Config ルール: secretsmanager-scheduled-rotation-success-check

パラメータ: なし

このコントロールは、AWS Secrets Managerシークレットはローテーションスケジュールに基づいて正常にローテーションされました。コントロールは、次の場合に失敗しますRotationOccurringAsScheduledfalse。コントロールは、ローテーションが設定されていないシークレットを評価しません。

Secrets Manager は、組織のセキュリティ体制を改善するのに役立ちます。シークレットには、データベース認証情報、パスワード、サードパーティーの API キーが含まれます。Secrets Manager を使用すると、シークレットを一元的に保存したり、シークレットを自動的に暗号化したり、シークレットへのアクセスを制御したり、シークレットを安全かつ自動的にローテーションしたりできます。

Secrets Manager はシークレットをローテーションできます。ローテーションを使用して、長期のシークレットを短期のシークレットに置き換えることができます。シークレットをローテーションすると、不正なユーザーが侵害されたシークレットを使用できる期間が制限されます。このため、シークレットは頻繁にローテーションする必要があります。

シークレットが自動的にローテーションされるように設定することに加えて、これらのシークレットがローテーションスケジュールに基づいて正常にローテーションされるようにする必要があります。

回転の詳細については、「」を参照してください。ローテーションAWS Secrets ManagerシークレットAWS Secrets Managerユーザーガイド

Remediation

自動ローテーションが失敗した場合、Secrets Manager の設定でエラーが発生している可能性があります。

Secrets Manager のシークレットの更新では、シークレットを所有するデータベースまたはサービスとやりとりする方法を定義する Lambda 関数を使用します。

シークレットのローテーションに関連する一般的なエラーの診断と修正方法については、を参照してください。のトラブルシューティングAWS Secrets Manager秘密の回転AWS Secrets Managerユーザーガイド

[SecretsManager.3] 未使用のSecrets Manager のシークレットを削除する

カテゴリ: 保護-セキュアなアクセス管理

緊急度: ミディアム

[リソースタイプ]: AWS::SecretsManager::Secret

AWS Config ルール: secretsmanager_secret_unused

パラメータ: なし

このコントロールは、指定した日数以内にシークレットにアクセスされているかどうかを確認します。デフォルト値は 90 日です。指定された日数内にシークレットにアクセスされなかった場合、このコントロールは失敗します。

未使用のシークレットを削除することは、シークレットをローテーションするのと同じくらい重要です。未使用のシークレットは、これらのシークレットにアクセスする必要のない以前のユーザーによって悪用される可能性があります。また、より多くのユーザーがシークレットにアクセスすると、誰かが操作を誤り、権限のないエンティティに漏洩している可能性があります。これにより、悪用のリスクが高くなります。未使用のシークレットを削除すると、不要になったユーザーからのシークレットアクセスを取り消すことができます。また、Secret Manager を使用するコストを削減するのに役立ちます。したがって、未使用のシークレットを定期的に削除することが不可欠です。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アジアパシフィック (大阪)

  • 中国 (北京)

  • 中国 (寧夏)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

Secrets Manager コンソールから、非アクティブシークレットを削除できます。

非アクティブシークレットを削除するには

  1. Secrets Manager のコンソール (https://console.aws.amazon.com/secretsmanager/) を開きます。

  2. シークレットを検索するには、検索ボックスにシークレットの名前を入力します。

  3. 削除するシークレットを選択します。

  4. []秘密の詳細「」からアクションで、シークレットの削除

  5. []シークレットの削除をスケジュールするで、シークレットが削除されるまでの待機日数を入力します。

  6. [Schedule deletion] を選択します。

[SecretsManager.4] Secrets Manager のシークレットは、指定された日数内にローテーションする必要があります

カテゴリ: 保護-セキュアなアクセス管理

緊急度: ミディアム

[リソースタイプ]: AWS::SecretsManager::Secret

AWS Config ルール: secretsmanager_secret_periodic_rotation

パラメータ:

  • ローテーション期間:デフォルトで 90 日間

このコントロールは、シークレットが 90 日以内に少なくとも 1 回ローテーションされているかどうかを確認します。

シークレットを回転させることは、あなたの秘密を不正に使用するリスクを減らすのに役立ちますAWSアカウント. 例としては、データベース認証情報、パスワード、サードパーティーの API キーなどの任意のテキストが含まれます。シークレットを長期間変更しないと、シークレットが侵害される可能性があります。

より多くのユーザーがシークレットにアクセスすると、誰かが操作を誤り、権限のないエンティティに漏洩する可能性が高くなります。シークレットは、ログとキャッシュデータを介して漏洩する可能性があります。これらはデバッグ目的で共有でき、デバッグ完了後に変更または取り消されることはありません。これらすべての理由から、シークレットは頻繁にローテーションする必要があります。

でシークレットを自動ローテーションするように設定できます。AWS Secrets Manager。自動ローテーションでは、長期のシークレットを短期のシークレットに置き換えることが可能となり、侵害されるリスクを大幅に減少させるのに役立ちます。

Security Hub では、Secrets Manager のシークレットのローテーションを有効にすることをお勧めします。回転の詳細については、「」を参照してください。ローテーションAWS Secrets ManagerシークレットAWS Secrets Managerユーザーガイド

注記

このコントロールは、次のリージョンではサポートされていません。

  • アジアパシフィック (大阪)

  • 中国 (北京)

  • 中国 (寧夏)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

Secrets Manager コンソールで自動シークレットローテーションを有効にできます。

シークレットローテーションを有効にするには

  1. Secrets Manager のコンソール (https://console.aws.amazon.com/secretsmanager/) を開きます。

  2. シークレットを検索するには、検索ボックスにシークレットの名前を入力します。

  3. 表示するシークレットを選択します。

  4. []ローテーション構成で、回転の編集

  5. 送信元回転設定の編集で、自動回転を有効にする

  6. 送信元回転間隔を選択で、回転間隔を選択します。

  7. ローテーションに使用する Lambda 関数を選択します。

  8. [次へ] を選択します。

  9. 自動ローテーションのシークレットを設定したら、回転設定で、シークレットをすぐにローテーションする

[SNS.1] SNS トピックは、保存時に暗号化する必要があります。AWS KMS

カテゴリ: 保護-データ保護-保管中のデータの暗号化

緊急度: ミディアム

[リソースタイプ]: AWS::SNS::Topic

AWS Config ルール: sns-encrypted-kms

パラメータ: なし

このコントロールは、を使用して SNS トピックが保存時に暗号化されているかどうかをチェックします。AWS KMS。

保管中のデータを暗号化すると、ディスクに保存されているデータが、認証されていないユーザーによってアクセスされるリスクが軽減されます。AWS。また、権限のないユーザーがデータにアクセスする能力を制限するためのアクセス制御セットも追加されています。たとえば、データを読み取る前にデータを復号化するには、API 権限が必要です。SNS トピックは、セキュリティ層を追加するために保存時に暗号化する必要があります。詳細については、「」を参照してください。保管時の暗号化Amazon Simple Notification Service デベロッパーガイド

Remediation

この問題を解決するには、SNS トピックを更新して暗号化を有効にします。

暗号化されていない SNS トピックを暗号化するには

  1. Amazon SNS コンソール(https://console.aws.amazon.com/sns/v3/home)を開きます。

  2. ナビゲーションペインで、[トピック] を選択します。

  3. 暗号化するトピックの名前を選択します。

  4. [編集] を選択します。

  5. []Encryptionで、暗号を有効化

  6. トピックの暗号化に使用する KMS キーを選択します。

  7. [変更を保存] を選択します。

[SQS.1] Amazon SQS キューは保管時に暗号化する必要があります

カテゴリ: 保護-データ保護-保管中のデータの暗号化

緊急度: ミディアム

[リソースタイプ]: AWS::SQS::Queue

AWS Config ルール: sqs-queue-encrypted (Security Hub が開発したカスタムルール)

パラメータ:

  • KmsKeyAliasList (オプション). Security Hub はこのパラメータを設定しません。カスタマー管理のカンマ区切りリストAWS KMSキューの暗号化に使用されるキーエイリアス。

    例:」alias/myKey「。

    このルールはNON_COMPLIANTキューの暗号化に使用されるキーがこのパラメータリストで指定されていない場合。

このコントロールは、Amazon SQS キューが保管時に暗号化されているかどうかをチェックします。

サーバー側の暗号化 (SSE) では、機密データを暗号化されたキューで送信できます。キュー内のメッセージの内容を保護するために、SSE はで管理されているキーを使用します。AWS KMS。詳細については、「」を参照してください。保管時の暗号化Amazon Simple Queue Service 開発者ガイド

Remediation

を使用して SSE を管理する方法の詳細については、AWS Management Console「」を参照してください。キューのサーバー側の暗号化 (SSE) の構成 (コンソール)Amazon Simple Queue Service 開発者ガイド

[SSM.1] EC2 インスタンスは、によって管理される必要がありますAWS Systems Manager

カテゴリ: 識別-インベントリ

緊急度: ミディアム

[リソースタイプ]: AWS::EC2::Instance

AWS Config ルール: ec2-instance-managed-by-systems-manager

パラメータ: なし

このコントロールは、アカウント内の停止および実行中の EC2 インスタンスがAWS Systems Manager。Systems Manager はAWSは、を表示および制御するために使用できるのサービスです。AWSインフラストラクチャー。

セキュリティとコンプライアンスを維持するために、Systems Manager は停止したマネージドインスタンスと実行中のマネージドインスタンスをスキャンします。マネージドインスタンスとは、Systems Manager 用に設定されたマシンです。次に、Systems Manager が検出したポリシー違反について報告または是正措置を講じます。Systems Manager は、マネージドインスタンスを設定して維持するのにも役立ちます。

詳細については、次を参照してください。AWS Systems Managerユーザーガイド

Remediation

Systems Manager コンソールを使用して、この問題を修復できます。

EC2 インスタンスがSystems Manager で管理されるようにするには

  1. AWS Systems Manager コンソール (https://console.aws.amazon.com/systems-manager/) を開きます。

  2. ナビゲーションメニューで、[高速セットアップ

  3. [作成] を選択します。

  4. []設定タイプで、ホスト管理[] の順に選択します。

  5. 設定画面では、デフォルトのオプションを維持できます。

    必要に応じて、以下の変更を行うことができます。

    1. CloudWatch を使用して EC2 インスタンスを監視する場合は、CloudWatch エージェントをインストールして設定するおよびCloudWatch エージェントを 30 日に 1 回更新する

    2. []ターゲットで、管理スコープを選択して、この設定が適用されるアカウントとリージョンを決定します。

    3. []インスタンスプロファイルオプションを選択し、インスタンスにアタッチされた既存のインスタンスプロファイルに必要な IAM ポリシーを追加する

  6. [作成] を選択します。

インスタンスが Systems Manager の関連付けをサポートしていることを確認するには、「」を参照してください。Systems Manager の前提条件AWS Systems Managerユーザーガイド

[SSM.2] Systems Manager によって管理されるすべての EC2 インスタンスは、パッチ適用要件に準拠している必要があります。

カテゴリ: 検出-検出サービス

緊急度:

[リソースタイプ]: AWS::SSM::PatchCompliance

AWS Config ルール: ec2-managedinstance-patch-compliance-status-check

パラメータ: なし

このコントロールは、Amazon EC2 Systems Manager パッチコンプライアンスのコンプライアンスステータスがCOMPLIANTまたはNON_COMPLIANTインスタンスへのパッチのインストール後。Systems Manager パッチマネージャーによって管理されているインスタンスのみがチェックされます。

組織の要求に応じて EC2 インスタンスに完全にパッチを適用すると、AWS アカウントの攻撃対象が軽減されます。

注記

このコントロールは、次のリージョンではサポートされていません。

  • アフリカ (ケープタウン)

  • ヨーロッパ (ミラノ)

  • 中東 (バーレーン)

Remediation

この問題を解決するには、準拠していないインスタンスに必要なパッチをインストールします。

非準拠のパッチを修正するには

  1. AWS Systems Manager コンソール (https://console.aws.amazon.com/systems-manager/) を開きます。

  2. []ノード管理で、Run Command[] を選択して [] を選択しますRun Command

  3. [] の横にあるボタンを選択します。AWS-PatchBaseline の実行

  4. [Operation (オペレーション)] を [Install (インストール)] に変更します。

  5. [Choose instances manually (インスタンスを手動で選択)] を選択し、非準拠のインスタンスを選択します。

  6. ページの最下部で [Run (実行)] を選択します。

  7. コマンドが完了したら、パッチを適用したインスタンスの新しいコンプライアンスステータスをモニタリングするには、ナビゲーションペインで [Compliance (コンプライアンス)] を選択します。

Systems Manager のドキュメントを使用してマネージドインスタンスにパッチを適用する方法の詳細については、「」を参照してください。インスタンスにパッチを適用する SSM ドキュメントについておよびSystems Manager Run Command を使用してコマンドを実行するAWS Systems Managerユーザーガイド

[SSM.3] Systems Manager によって管理されるインスタンスは、アソシエーションコンプライアンスステータスがCOMPLIANT

カテゴリ: 検出-検出サービス

緊急度:

[リソースタイプ]: AWS::SSM::AssociationCompliance

AWS Config ルール: ec2-managedinstance-association-compliance-status-check

パラメータ: なし

このコントロールは、のステータスかどうかをチェックしますAWS Systems Manager関連付けのコンプライアンスはCOMPLIANTまたはNON_COMPLIANTインスタンスで関連付けを実行した後。アソシエーションのコンプライアンスステータスが次の場合、コントロールは通過します。COMPLIANT

ステートマネージャーの関連付けは、マネージドインスタンスに割り当てられた設定です。この設定では、インスタンスで管理する状態を定義します。たとえば、関連付けでは、アンチウイルスソフトウェアをインスタンスにインストールして実行する必要があること、または特定のポートを閉じる必要があることを指定できます。

ステートマネージャーの関連付けを 1 つまたは複数作成すると、コンプライアンスステータス情報をすぐに表示できるようになります。コンプライアンスステータスは、コンソールで、またはAWS CLIコマンドまたは対応するSystems Manager API アクション。関連付けに対して、設定コンプライアンスにはコンプライアンスステータスが表示されます (CompliantまたはNon-compliant). また、関連付けに割り当てられた重大度レベルも表示されます。CriticalまたはMedium

ステートマネージャーの協会コンプライアンスの詳細については、「」を参照してください。ステートマネージャーの関連付けコンプライアンスについてAWS Systems Managerユーザーガイド

注記

このコントロールは、アフリカ (ケープタウン) または EU (ミラノ) ではサポートされていません。

Remediation

失敗した関連付けは、ターゲットや SSM ドキュメント名など、さまざまなものに関連している可能性があります。この問題を修復するには、まず関連付けを特定して調査する必要があります。その後、関連付けを更新して、特定の問題を修正できます。

関連付けを編集して新しい名前、スケジュール、重要度レベル、またはターゲットを指定できます。関連付けを編集した後、AWS Systems Manager で新しいバージョンが作成されます。

失敗した関連付けを調査して更新するには

  1. AWS Systems Manager コンソール (https://console.aws.amazon.com/systems-manager/) を開きます。

  2. ナビゲーションペインで、[] の [] の [ノード管理で、Fleet Manager

  3. あるインスタンス ID を選択します。アソシエーションステータスFailed

  4. [View details] (詳細を表示する) をクリックします。

  5. 選択関連付け

  6. の関連付けの名前を書き留めておきます。アソシエーションステータスFailed。これはあなたが調査する必要がある協会です。関連付けの名前は、次の手順で使用する必要があります。

  7. ナビゲーションペインで、[] の [] の [ノード管理で、ステートマネージャー。関連付け名を検索し、関連付けを選択します。

  8. 問題を特定したら、失敗した関連付けを編集して問題を修正します。関連付けを編集する方法については、「」を参照してください。関連付けを編集する

State Manager 関連付けの作成と編集の詳細については、「」を参照してください。Systems Manager の関連付けの使用AWS Systems Managerユーザーガイド

[WAF.1]AWS WAFクラシックグローバル Web ACL ロギングをイネーブルにする必要があります

カテゴリ: 識別-ログ記録

緊急度: ミディアム

[リソースタイプ]: AWS::WAF::WebACL

AWS Config ルール: waf-classic-logging-enabled

パラメータ: なし

このコントロールは、ログ記録が有効になっているかどうかをチェックします。AWS WAFグローバルウェブ ACL。ウェブ ACL のロギングが有効になっていない場合、このコントロールは失敗します。

ログは、の信頼性、可用性、およびパフォーマンスを維持する上で重要な部分です。AWS WAFグローバルに. これは、多くの組織でビジネスおよびコンプライアンス要件であり、アプリケーションの動作をトラブルシューティングできます。また、接続されているウェブ ACL によって分析されるトラフィックに関する詳細情報も提供します。AWS WAF。

注意

注記

このコントロールは、次のリージョンではサポートされていません。

  • 米国東部 (オハイオ)

  • 米国西部 (北カリフォルニア)

  • 米国西部 (オレゴン)

  • アフリカ (ケープタウン)

  • アジアパシフィック (香港)

  • アジアパシフィック (ムンバイ)

  • アジアパシフィック (大阪)

  • アジアパシフィック (ソウル)

  • アジアパシフィック (シンガポール)

  • アジアパシフィック (シドニー)

  • アジアパシフィック (東京)

  • カナダ (中部)

  • 中国 (北京)

  • 中国 (寧夏)

  • 欧州 (フランクフルト)

  • 欧州 (アイルランド)

  • 欧州 (ロンドン)

  • ヨーロッパ (ミラノ)

  • 欧州 (パリ)

  • 欧州 (ストックホルム)

  • 中東 (バーレーン)

  • 南米 (サンパウロ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

Kinesis Data Firehose コンソールからウェブ ACL のロギングを有効にできます。

ウェブ ACL でログ記録を有効にするには

  1. で Kinesis Data Firehose コンソールを開きます。https://console.aws.amazon.com/firehose/

  2. Kinesis Data Firehose 配信ストリームを作成します。

    名前の先頭には、接頭辞を付ける必要があります。aws-waf-logs-。例えば、aws-waf-logs-us-east-2-analytics と指定します。

    Kinesis Data Firehose 配信ストリームを作成します。PUTソースとオペレーションのリージョン内。Amazon CloudFront のログをキャプチャする場合は、米国東部 (バージニア北部) に配信ストリームを作成します。詳細については、「」を参照してください。Amazon Kinesis Data Firehose 配信ストリームの作成Amazon Kinesis Data Firehose 開発者ガイド

  3. 送信元サービスで、WAF & Shield。次に [] を選択します。[] に切り替えるAWS WAFClassic

  4. 送信元フィルタで、グローバル (CloudFront)

  5. ログ記録を有効にするウェブ ACL を選択します。

  6. []ログ記録で、ログ作成の有効化

  7. 前に作成した Kinesis Data Firehose 配信ストリームを選択します。で始まる名前のデリバリーストリームを選択する必要がありますaws-waf-logs-。

  8. [ログの有効化] を選択します。