AWS の基本的なセキュリティのベストプラクティスコントロール - AWS Security Hub
[ACM.1] インポートされた ACM 証明書は、指定された期間後に更新する必要があります[APIGateway.1] API Gateway RESTとWebSocket APIロギングを有効にする必要があります[Apigateway.2] バックエンド認証にSSL証明書を使用するようにAPI Gateway REST APIステージを設定する必要があります[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 ontディストリビューションには、デフォルトのルートオブジェクトが設定されている必要があります[CloudFront.2] CloudFront ontディストリビューションでは、オリジンアクセスアイデンティティを有効にする必要があります[CloudFront.3] CloudFront ontディストリビューションは、転送中に暗号化を要求する必要があります[CloudFront.4] CloudFront ontディストリビューションでは、オリジンフェイルオーバーが設定されている必要があります。[CloudFront.5] CloudFront ontディストリビューションでロギングが有効になっている必要があります[CloudFront.6] CloudFront ontディストリビューションには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アクセラレータ (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 エンドポイントを使用するように設定する必要があります[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] Amazon EFS は、を使用して保管中のファイルデータを暗号化するように設定する必要があります。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] Elastic Search ドメインは 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 関数ポリシーはパブリックアクセスを禁止する必要があります[Lambda.2] Lambda 関数は、サポートされているランタイムを使用する必要があります[Lambda.4] Lambda da関数にはデッドレターキューが設定されている必要があります(リタイリング)[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 バケットでは、セキュアなソケットレイヤーを使用するためのリクエストが必要です[S3.6] 他のAWSバケットポリシー内のアカウントは制限する必要があります[S3.8] S3 ブロックパブリックアクセス設定は、バケットレベルで有効にする必要があります[SageMaker.1] SageMaker erノートブックインスタンスは、直接インターネットにアクセスすることはできません[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 証明書は、指定された期間後に更新する必要があります

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

重大度: ミディアム

[リソースタイプ] ACM 証明書

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

パラメータ:

  • daysToExpiration: 30

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

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

ACM 証明書のマネージド型更新の詳細については、」ACM 証明書の管理された書き換えAWS Certificate Managerユーザーガイド

注記

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

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

  • 中国 (北京)

  • 中国 (寧夏)

  • ヨーロッパ (ミラノ)

Remediation

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

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

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

詳細については、「」を参照してください。電子メールで検証されたドメインの更新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] バックエンド認証にSSL証明書を使用するようにAPI Gateway REST APIステージを設定する必要があります

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

重大度: ミディアム

[リソースタイプ] 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-RayAmazon 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 WAFWeb ACL が REST API Gateway ステージにアタッチされていません。

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

注記

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

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

  • 中国 (北京)

  • 中国 (寧夏)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

API Gateway コンソールを使用して、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. ステージリストで、キャッシュを追加するステージを選択します。

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

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

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

  8. [Save Changes] を選択します。

[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. [Edit] を選択します。

  5. []ヘルスチェック, 用ヘルスチェックタイプ] で、[ELB

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

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

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

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

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

重大度: 非常事態

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

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

パラメータ: なし

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

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

注記

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

  • 米国東部 (オハイオ)

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

  • 米国西部 (オレゴン)

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

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

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

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

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

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

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

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

  • カナダ (中部)

  • 中国 (北京)

  • 中国 (寧夏)

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

  • 欧州 (アイルランド)

  • 欧州 (ロンドン)

  • ヨーロッパ (ミラノ)

  • 欧州 (パリ)

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

  • 中東 (バーレーン)

  • 南米 (サンパウロ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

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

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

カテゴリ: 保護-リソースポリシーの設定

重大度: ミディアム

[リソースタイプ] 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 ontディストリビューションは、転送中に暗号化を要求する必要があります

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

重大度: ミディアム

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

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

パラメータ: なし

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

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

注記

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

  • 米国東部 (オハイオ)

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

  • 米国西部 (オレゴン)

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

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

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

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

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

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

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

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

  • カナダ (中部)

  • 中国 (北京)

  • 中国 (寧夏)

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

  • 欧州 (アイルランド)

  • 欧州 (ロンドン)

  • ヨーロッパ (ミラノ)

  • 欧州 (パリ)

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

  • 中東 (バーレーン)

  • 南米 (サンパウロ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

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

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

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

重大度:

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

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

パラメータ: なし

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

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

注記

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

  • 米国東部 (オハイオ)

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

  • 米国西部 (オレゴン)

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

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

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

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

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

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

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

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

  • カナダ (中部)

  • 中国 (北京)

  • 中国 (寧夏)

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

  • 欧州 (アイルランド)

  • 欧州 (ロンドン)

  • ヨーロッパ (ミラノ)

  • 欧州 (パリ)

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

  • 中東 (バーレーン)

  • 南米 (サンパウロ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

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

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

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

重大度: ミディアム

[リソースタイプ] 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 ontディストリビューションにはAWS WAFenabled

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

重大度: ミディアム

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

AWS Config ルール: cloudfront_associated_with_waf

パラメータ:

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

このコントロールは、CloudFront ディストリビューションがAWS WAFまたはAWS WAFv2 Web ACL。ディストリビューションが Web ACL に関連付けられていない場合、コントロールは失敗します。

AWS WAF は、ウェブアプリケーションと API を攻撃から保護するウェブアプリケーションファイアウォールです。これにより、お客様が定義するカスタマイズ可能なウェブセキュリティルールと条件に基づいて、ウェブリクエストを許可、ブロック、またはカウントする一連のルール (ウェブアクセスコントロールリストまたはウェブ ACL と呼ばれます) を設定できます。CloudFront ディストリビューションがAWS WAFWeb 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 コールです。これには、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 を使用したことがない場合は、[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 バケットと同じリージョンに作成されます。

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

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

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

    CloudTrail が KMS キーと正常にやり取りするためには、ポリシーを変更する必要がある場合があります。詳細については、「」を参照してください。を使用した 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. [Save changes] (変更の保存) をクリックします。

詳細については、「」を参照してください。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 は、CloudTrail ログを CloudWatch Logs に送信することをお勧めします。この推奨事項は、アカウントアクティビティのキャプチャ、監視、および適切なアラームの発生を保証することを目的としています。CloudWatch Logs を使用して、AWSのサービス。この推奨事項は、別のソリューションの使用を妨げるものではありません。

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

Remediation

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

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

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

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

  3. 値を持たないトレイルを選択します。CloudWatch Logs ロググループ

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

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

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

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

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

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

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

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

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

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

  8. [Save changes] (変更の保存) をクリックします。

詳細については、「」を参照してください。コンソールを使用した 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

OAuthを使用するようにCodeBuild プロジェクトを更新することができます。

基本認証/ (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 Config AWS 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 Notification Service 入門ガイド

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

  6. リポジトリの []AWS Configルールページで [] を選択します。

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

の使用方法の詳細については、「」を参照してください。AWS ConfigからのAWS CLI「」を参照してください。の有効化AWS Config AWS 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 が設定されたオンデマンド容量モードまたはプロビジョニングされたモードのいずれかを使用する場合にパスします。容量を需要に応じて拡張することで、制限例外を回避し、アプリケーションの可用性を維持できます。

オンデマンド容量モードの DynamoDB テーブルは、DynamoDB スループットのデフォルトテーブルクォータによってのみ制限されます。これらのクォータを増やすには、サポートチケットをAWS Support

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

注記

このコントロールは、AWSGovCloud (米国東部) またはAWSGovCloud (米国西部)

Remediation

容量モードで既存のテーブルで DynamoDB 自動スケーリングを有効にする手順の詳細については、既存のテーブルでの DynamoDB Auto Scaling の有効化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アクセラレータ (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、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

このコントロールは、VPC に対して Amazon 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 Dashboard (EC2 ダッシュボード)] を選択します。

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

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

  5. [有効化] を選択します。あなたは、 AWS マネージドキー ()alias/aws/ebsデフォルトの暗号化キーとしてユーザーの代わりに作成するか、対称カスタマー管理キーを選択します。

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

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

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

重大度:

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

AWS Config ルール: ec2-imdsv2-check

パラメータ: なし

このコントロールは、EC2 インスタンスのメタデータバージョンがインスタンスメタデータサービスバージョン 2 (IMDSv2) で設定されているかどうかを確認します。コントロールは、HttpTokensは IMDSv2 で必須に設定されています。コントロールは、HttpTokensは、 に設定されます。optional

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

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

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

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

  • サーバー側要求フォージェリ (SSRF) の脆弱性

  • オープンなレイヤ 3 ファイアウォールとネットワークアドレス変換 (NAT)

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

注記

このコントロールはアフリカ (ケープタウン) または 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

デフォルト以外の VPC を使用すると、デフォルトでパブリック IP アドレスが割り当てられません。

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

自動的に割り当てられたパブリック IP アドレスを EC2 インスタンスから手動で割り当てたり、EC2 インスタンスから割り当て解除することはできません。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 エンドポイントを使用するように設定する必要があります

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

重大度: ミディアム

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

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

パラメータ:

  • serviceName: ec2

このコントロールは、Amazon EC2 のサービスエンドポイントが各 VPC に対して作成されるかどうかをチェックします。VPC に Amazon EC2 サービス用に作成された 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. を使用する場合サービスのカテゴリ] で、[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 Adapters( このコントロールは、単一のネットワークアダプタが使用されている場合に渡されます。コントロールには、許可された ENI を識別するためのオプションのパラメータリストが含まれています。

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

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

注記

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

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

  • 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。セキュリティグループルールは、最小特権アクセスのプリンシパルに従う必要があります。無制限のアクセス(接尾辞が /0 の IP アドレス)は、ハッキング、サービス拒否攻撃、データ損失などの悪意のあるアクティビティの機会を増やします。

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

注記

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

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であり、このパラメータリストでは指定されていません。

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

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

注記

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

Remediation

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

[EFS.1] Amazon EFS は、を使用して保管中のファイルデータを暗号化するように設定する必要があります。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. リポジトリの []ファイルシステムページで、自動バックアップを有効にするファイルシステムを選択します。

    -[File systemページが表示されます。

  3. []全般] で、[編集

  4. 自動バックアップを有効にするには、[] を選択します。自動バックアップの有効化

  5. [Save changes] (変更の保存) をクリックします。

詳細については、「」を参照してください。を使用するAWS BackupAmazon EFSAmazon 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 Balancer が接続ドレインが有効になっているかどうかをチェックします。

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 アドレスは、PublicIpNetworkInterfaces設定を変更します。このコントロール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 Service の保管中のデータの暗号化Amazon OpenSearch Service 開発者ガイド

注記

特定のインスタンスタイプ (t.smallおよびt.mediumは、保管時のデータの暗号化をサポートしていません。詳細については、「」を参照してください。サポートされるインスタンスタイプAmazon OpenSearch Service 開発者ガイド

Remediation

デフォルトでは、ドメインの保管時のデータは暗号化されず、既存のドメインでこの機能を使用するように設定することはできません。

この機能を有効にするには、別のドメインを作成してデータを移行する必要があります。ドメインの作成については、「」を参照してください。Amazon OpenSearch Service 開発者ガイド

保管時のデータの暗号化には OpenSearch Service 5.1 以降が必要です。OpenSearch Service 用の保管時のデータの暗号化の詳細については、Amazon OpenSearch Service 開発者ガイド

[ES.2] Elastic Search ドメインは 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 ドメインは、プライベートAWS公共のインターネットを横断する必要なく、ネットワーク、。この設定では、転送中のデータへのアクセスを制限することにより、セキュリティポスチャが増加します。VPC には、ネットワーク ACL やセキュリティグループなど、Elasticsearch ドメインへのアクセスを保護するためのさまざまなネットワークコントロールが用意されています。Security Hub では、パブリック Elasticsearch ドメインを VPC に移行して、これらのコントロールを利用することをお勧めします。

Remediation

パブリックエンドポイントを使用してドメインを作成する場合、後で VPC 内にドメインを配置することはできません。代わりに、新規のドメインを作成して、データを移行する必要があります。逆の場合も同様です。VPC 内にドメインを作成する場合、パブリックエンドポイントを持つことはできません。代わりに、別のドメインを作成するか、このコントロールを無効にする必要があります。

「」を参照してください。パブリックアクセスから VPC アクセスに移行する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 ドメインで監査ログが有効になっていない場合、このコントロールは失敗します。

監査ログは高度にカスタマイズ可能です。これにより、認証の成功と失敗、OpenSearch へのリクエスト、インデックスの変更、受信検索クエリなど、Elasticsearch クラスターでのユーザーアクティビティを追跡できます。

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 サービスコンソール () を開きます。https://console.aws.amazon.com/es/

  2. []マイドメインで、編集するドメインの名前を選択します。

  3. [Edit domain (ドメインの編集)] を選択します。

  4. []データノードノード数を 3 以上の数値に設定します。

    3 つのアベイラビリティーゾーン展開では、アベイラビリティーゾーン間で均等に分散されるように、を 3 の倍数に設定します。

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

[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 サービスコンソール () を開きます。https://console.aws.amazon.com/es/

  2. []マイドメインで、編集するドメインの名前を選択します。

  3. [Edit domain (ドメインの編集)] を選択します。

  4. []専用マスターノードインスタンスタイプを必要なインスタンスタイプに設定します。

  5. 設定マスターノード数3以上に等しい。

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

[ES.8] Elasticsearchドメインへの接続は、TLS 1.2を使用して暗号化する必要があります

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

重大度: ミディアム

[リソースタイプ] AWS::Elasticsearch::Domain

AWS Config ルール: elasticsearch-https-required (Security Hub によって開発されたカスタムルール)

パラメータ: なし

このコントロールは、TLS 1.2 を使用するために Elasticsearch ドメインへの接続が必要かどうかをチェックします。Elasticsearchドメインの場合、チェックは失敗しますTLSSecurityPolicyPolicy-Min-TLS-1-2-2019-07 ではありません。

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

Remediation

TLS 暗号化を有効にするには、UpdateElasticsearchDomainConfigAPI 操作を使用して、DomainEndpointOptionsを設定するために、TLSSecurityPolicy。詳細については、「」を参照してください。Amazon OpenSearch Service 開発者ガイド

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

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

重大度:

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

AWS Config ルール: guardduty-enabled-centralized

パラメータ: なし

このコントロールは、GuardDuty アカウントおよびリージョンで Amazon ガードデューティが有効になっているかどうかを確認します。

GuardDuty を有効にすることが強く推奨されています。AWSリージョン。このように設定することで、お客様が能動的に使用していないリージョンでも、GuardDuty は、許可されていないアクティビティや異常なアクティビティに関する検索結果をで生成できます。また、GuardDuty は、グローバルな CloudTrail イベントをモニタリングできます。AWSサービス(IAM など)。

注記

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

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

  • 中国 (北京)

  • 中国 (寧夏)

  • ヨーロッパ (ミラノ)

  • 中東 (バーレーン)

  • 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 ポリシーのデフォルトバージョン (カスタマー管理ポリシーとも呼ばれます) に、「効果」のステートメントを含む管理者アクセス権があるかどうかをチェックします。「Allow」:「Resource」:「Allow」:「Resource」:「*」。

コントロールは、作成したカスタマー管理ポリシーのみをチェックします。インラインチェックは行わず、AWS管理ポリシーを設定します。

IAM ポリシーは、ユーザー、グループ、またはロールに付与される権限のセットを定義します。標準的なセキュリティアドバイスに従って、AWS は最小限の特権を付与することをお勧めします。これは、タスクの実行に必要なアクセス許可のみを付与することを意味します。ユーザーが必要とする最小限のアクセス許可セットではなく、完全な管理権限を提供すると、リソースを望ましくない可能性のあるアクションに公開します。

完全な管理権限を許可するのではなく、ユーザーが何をする必要があるのかを決定し、ユーザーが、それらのタスクのみを実行できるポリシーを作成します。最小限のアクセス許可から開始し、必要に応じて追加のアクセス許可を付与します。あまりにも寛大なアクセス許可から始めて、後でそれらを強化しようとしないでください。

ステートメントを含む IAM ポリシーは、削除する必要があります。"Effect": "Allow" "Action": "*"[]"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、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多要素認証 (MFA) は、コンソールパスワードを使用するすべての IAM ユーザーに対して有効です。

多要素認証 (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. ルートユーザーの認証情報を使用してアカウントにログインします。

  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 Consoleの場合、IAM ユーザーはパスワードが必要です。ベストプラクティスとして、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 ID ベースのポリシーに、* ワイルドカードを使用して、任意のサービスに対するすべてのアクションに対するアクセス許可を付与する Allow ステートメントがあるかどうかをチェックします。ポリシーステートメントに"Effect": "Allow""Action": "Service:*"

たとえば、ポリシーで次のステートメントを実行すると、検索が失敗します。。

"Statement": [ { "Sid": "EC2-Wildcard", "Effect": "Allow", "Action": "ec2:*", "Resource": "*" }

このコントロールは、カスタマー管理の 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 ナビゲーションペインで、[IAM] を選択します。ポリシー

  3. 変更するポリシーの横にある矢印を選択します。

  4. [Edit policy (ポリシーの編集)] を選択します。

  5. [JSON] タブを選択します。

  6. での変更点“Resource”値を、許可する 1 つまたは複数のキーに設定します。

  7. ポリシーを変更したら、[] を選択します。ポリシーの確認

  8. [Save changes] (変更の保存) をクリックします。

詳細については、「」を参照してください。での 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では、最小権限を許可することを推奨します。別の言い方をすると、タスクの実行に必要なアクセス許可のみを付与する必要があります。そうしないと、ユーザーはデータに適さないキーを使用する可能性があります。

すべてのキーに対してアクセス許可を付与する代わりに、ユーザーが暗号化されたデータにアクセスするために必要なキーの最小セットを決定します。次に、ユーザーがこれらのキーのみを使用できるようにするポリシーを設計します。たとえば、許可しないkms:Decryptアクセス許可をすべての KMS キーに付与します。代わりに、アカウントの特定のリージョンのキーでのみ許可します。最小特権という原則を採用することで、意図しないデータ漏洩のリスクを軽減できます。

Remediation

この問題を修復するには、キーへのアクセスを制限するようにインラインポリシーを変更します。

IAM インラインポリシーを変更するには

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

  2. IAM ナビゲーションペインで、[IAM] を選択します。ユーザー,Groups, またはロール

  3. IAM インラインポリシーを変更するユーザー、グループ、またはロールの名前を選択します。

  4. 変更するポリシーの横にある矢印を選択します。

  5. [Edit policy (ポリシーの編集)] を選択します。

  6. [JSON] タブを選択します。

  7. での変更点"Resource"値を許可する特定のキーに設定します。

  8. ポリシーを変更したら、[] を選択します。ポリシーの確認

  9. [Save changes] (変更の保存) をクリックします。

詳細については、「」を参照してください。での 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 関数ポリシーはパブリックアクセスを禁止する必要があります

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

重大度: 非常事態

[リソースタイプ] 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 CLIを使用して Lambda 関数からアクセス許可を削除するには、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, nodejs10.x, python3.9, python3.8, python3.7, python3.6, ruby2.7, ruby2.5, java11, java8, java8.al2, go1.x, dotnetcore3.1, dotnetcore2.1

このコントロールは、ランタイムの Lambda 関数設定が、各言語のサポートされているランタイムに設定されている期待値と一致することを確認します。このコントロールは、次のランタイムをチェックします。nodejs14.x,nodejs12.x,nodejs10.x,python3.9,python3.8,python3.7,python3.6,ruby2.7,ruby2.5,java11,java8,java8.al2,go1.x,dotnetcore3.1,dotnetcore2.1

Lambda ランタイムメンテナンスとセキュリティの更新の対象となるオペレーティングシステム、プログラミング言語、およびソフトウェアライブラリの組み合わせを中心に構築されています。ランタイムコンポーネントがセキュリティアップデートでサポート対象外となった場合、Lambda はそのランタイムを廃止します。非推奨のランタイムを使用する関数を作成することはできませんが、この関数は呼び出しイベントの処理に使用できます。Lambda 関数が最新であり、古いランタイム環境を使用していないことを確認してください。

このコントロールがサポートされている言語をチェックするサポートされているランタイムの詳細については、」AWS LambdaランタイムAWS Lambdaデベロッパーガイド

注記

中国 (北京) または中国 (寧夏) リージョンでは、このコントロールはサポートされていません。

Remediation

サポートされているランタイムと非推奨スケジュールの詳細については、ランタイムサポートポリシーの セクションAWS Lambdaデベロッパーガイド。ランタイムを最新バージョンに移行するときは、言語の発行元からの構文とガイダンスに従ってください。

[Lambda.4] Lambda da関数にはデッドレターキューが設定されている必要があります(リタイリング)

注記

Security Hub はこのコントロールを廃止しています。コントロールが廃止されると、コンソールに表示されなくなります。Security Hub は、そのコントロールの結果を生成しなくなりました。既存の調査結果は、3日後に自動的にアーカイブされます。

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

重大度: ミディアム

[リソースタイプ] AWS::Lambda::Function

AWS Config ルール: lambda-dlq-check

パラメータ:

  • dlqArns(オプション) — Lambda 関数のデッドレターキューターゲットとして設定する必要がある Amazon SQS および Amazon SNS ARN のカンマ区切りリスト。

このコントロールは、Lambda 関数にデッドレターキューが設定されているかどうかを確認します。Lambda 関数にデッドレターキューが設定されていない場合、コントロールは失敗します。

障害発生時の送信先に代わる方法として、配信不能キューを使用して関数を設定し、破棄されたイベントを保存してさらに処理できます。配信不能キューは、障害発生時の送信先と同じように動作します。イベントがすべての処理試行に失敗するか、処理されずに期限切れになった場合に使用されます。

デッドレターキューを使用すると、Lambda 関数へのエラーまたは失敗したリクエストを振り返り、異常な動作をデバッグまたは特定できます。

セキュリティの観点からは、関数が失敗した理由を理解し、関数がデータを削除したりデータのセキュリティを侵害したりしないようにすることが重要です。たとえば、関数が基盤となるリソースと通信できない場合、ネットワークの他の場所にあるサービス拒否 (DoS) 攻撃の症状である可能性があります。

注記

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

Remediation

デッドレターキューは、AWS Lambdaconsole.

デッドレターキューを設定するには

  1. https://console.aws.amazon.com/lambda/ で、AWS Lambda コンソールを開きます。

  2. ナビゲーションペインで、[Functions] (関数) を選択します。

  3. 関数を選択します。

  4. [設定]、[Asynchronous invocation (非同期呼び出し)] の順に選択します。

  5. [Asynchronous invocation (非同期呼び出し)] で、[Edit (編集)] を選択します。

  6. 設定DLQ リソースを Amazon SQS または Amazon SNS に送信します。

  7. ターゲットとなるキューまたはトピックを選択します。

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

[RDS.1] RDS スナップショットはプライベートである必要があります

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

重大度: 非常事態

[リソースタイプ] Amazon RDS DB スナップショット

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 User Guide

注記

このコントロールはアフリカ (ケープタウン) または 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

パラメータ: なし

このコントロールは、Amazon RDS インスタンスがパブリックにアクセスできるかどうかをチェックします。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 User Guide

[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 User Guide

Remediation

Amazon RDS での DB インスタンスの暗号化の詳細については、「」を参照してください。Amazon RDS リソースの暗号化Amazon RDS User Guide

[RDS.4] RDS クラスターのスナップショットとデータベーススナップショットは保存時に暗号化する必要があります

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

重大度: ミディアム

[リソースタイプ] Amazon RDS DB クラスタースナップショット、Amazon RDS DB スナップショット

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 User Guide

  7. 確認ページで、変更内容を確認します。正しい場合は、[Modify DB Instance (DB インスタンスを変更)] を選択して変更を保存します。

[RDS.6] RDS DB インスタンスおよびクラスターに対して拡張モニタリングを設定する必要がある

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

重大度:

[リソースタイプ] AWS::RDS::DBInstance

AWS Config ルール: rds-enhanced-monitoring-enabled

パラメータ: なし

このコントロールは、RDS DB インスタンスに対して拡張モニタリングが有効になっているかどうかを確認します。

Amazon RDS では、拡張モニタリングにより、基盤となるインフラストラクチャのパフォーマンスの変化に対して、より迅速に対応できます。これらのパフォーマンスの変更により、データの可用性が失われる可能性があります。拡張モニタリングは、RDS DB インスタンスが実行されているオペレーティングシステムのリアルタイムメトリクスを提供します。インスタンスにエージェントがインストールされています。エージェントは、ハイパーバイザー層から可能よりも正確にメトリックスを取得できます。

拡張モニタリングのメトリクスが便利なのは、DB インスタンス上のさまざまなプロセスやスレッドがどのように CPU を使用しているかを表示するときです。詳細については、「」を参照してください。拡張モニタリングAmazon RDS User Guide

Remediation

DB インスタンスに対して拡張モニタリングを有効にする方法の詳細については、「」を参照してください。拡張モニタリングの設定と有効化Amazon RDS User Guide

[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: (監査、エラー、一般、スロークエリ)

  • MariaDB (監査、エラー、一般、スロークエリ)

  • SQL Server: (エラー、エージェント)

  • Aurora: (監査、エラー、一般、スロークエリ)

  • オーロラ-MySQL: (監査、エラー、一般、スロークエリ)

  • オーロラ-PostgreSQL: (Postgresql、アップグレード)。

RDS データベースでは、関連するログを有効にする必要があります。データベースログは、RDS に対して行われた要求の詳細な記録を提供します。データベースログは、セキュリティとアクセスの監査を支援し、可用性の問題を診断するのに役立ちます。

注記

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

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

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

中国 (寧夏)

ヨーロッパ (ミラノ)

Remediation

ロギングオプションは、RDS DB クラスターまたはインスタンスに関連付けられた DB パラメータグループに含まれています。データベースエンジンのデフォルトパラメータグループが使用されているときにロギングを有効にするには、必要なパラメータ値を持つ新しい DB パラメータグループを作成する必要があります。その後、カスタマー DB パラメータグループを DB クラスターまたはインスタンスに関連付けます。

MariaDB、MySQL、または PostgreSQL ログを有効にして 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 User Guide

  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. クラスターの場合は、DB インスタンスの変更

[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 User Guide

    確認ページで、変更内容を確認します。正しい場合は、[] を選択します。DB インスタンスの変更

[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 User Guide

[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 User Guide

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 User Guide

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 User Guide

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 User Guide

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. クラスターの場合は、クラスターの変更。インスタンスの場合は、DB インスタンスの変更

[Redshift.1] Amazon Redshift クラスターはパブリックアクセスを禁止する必要があります

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

重大度: 非常事態

[リソースタイプ] AWS::Redshift::Cluster

AWS Config ルール: redshift-cluster-public-access-check

パラメータ: なし

このコントロールは、Amazon Redshift クラスターがパブリックにアクセスできるかどうかをチェックします。評価するPubliclyAccessibleフィールドをクリックします。

-PubliclyAccessible属性は、Amazon 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 の影響を理解するには、この機能を使用してアプリケーションをテストする必要があります。

注記

このコントロールは、欧州 (ミラノ) ではサポートされていません。

Remediation

この問題を修復するには、暗号化を要求するようにパラメータグループを更新します。

パラメータグループを変更するには

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

  2. ナビゲーションメニューで、[設定[] の順に選択します。ワークロード管理を表示するにはワークロード管理ページで.

  3. 変更するパラメータグループを選択します。

  4. 選択パラメータ

  5. 選択パラメータの編集SELECT。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. [Edit] を選択します。

  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 (Amazon Redshiftmodify-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

パラメータ:

  • ignorePublicAcls: true

  • blockPublicPolicy: true

  • blockPublicAcls: true

  • restrictPublicBuckets: true

このコントロールは、次の Amazon S3 パブリックアクセスブロック設定がアカウントレベルで設定されているかどうかをチェックします。

  • ignorePublicAcls: true

  • blockPublicPolicy: true

  • blockPublicAcls: true

  • restrictPublicBuckets: true

すべてのパブリックアクセスブロック設定がtrue

設定のいずれかが設定されている場合、コントロールは失敗します。falseに設定されていない場合、または設定のいずれかが設定されていない場合。設定に値がない場合、AWS Configルールは評価を完了できません。

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. [Edit] を選択します。

  4. Selectブロックすべてパブリックアクセス

  5. [Save changes] (変更の保存) をクリックします。

詳細については、「」を参照してください。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. [Edit] を選択します。

  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. [Edit] を選択します。

  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-256Amazon 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 Container

[S3.5] S3 バケットでは、セキュアなソケットレイヤーを使用するためのリクエストが必要です

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

重大度: ミディアム

[リソースタイプ] 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 バケットポリシーに準拠するには、どの S3 バケットポリシーを使用すればよろしいですかAWS Configルールs3-bucket-ssl-requestsonly

[S3.6] 他の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 erノートブックインスタンスは、直接インターネットにアクセスすることはできません

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

重大度:

リソースタイプ: AWS::SageMaker::NotebookInstance

AWS Config ルール: sagemaker-notebook-no-direct-internet-access

パラメータ: なし

このコントロールは、SageMaker ノートブックインスタンスで直接インターネットアクセスが無効になっているかどうかをチェックします。これを行うために、それはかどうかをチェックしますDirectInternetAccessフィールドは、ノートブックインスタンスでは無効になっています。

VPC を使用せずに SageMaker インスタンスを設定すると、デフォルトでは、インスタンスで直接インターネットアクセスが有効になります。VPC を使用してインスタンスを設定し、デフォルト設定を無効にする — 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. [Network] セクションを展開し、VPC、サブネット、およびセキュリティグループを選択します。[]ダイレクトインターネットアクセス] で、[無効にする — 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 は、シークレットを回転させることができます。ローテーションを使用して、長期のシークレットを短期のシークレッに置き換えることができます。シークレットをローテーションすると、権限のないユーザーが侵害されたシークレットを使用できる期間が制限されます。このため、シークレットは頻繁にローテーションする必要があります。回転の詳細については、「」を参照してください。あなたのローテーション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 は、シークレットを回転させることができます。ローテーションを使用して、長期のシークレットを短期のシークレッに置き換えることができます。シークレットをローテーションすると、権限のないユーザーが侵害されたシークレットを使用できる期間が制限されます。このため、シークレットは頻繁にローテーションする必要があります。

自動的にローテーションするようにシークレットを設定することに加えて、ローテーションスケジュールに基づいてこれらのシークレットが正常にローテーションされるようにする必要があります。

回転の詳細については、「」を参照してください。あなたのローテーションAWS Secrets ManagerシークレットAWS Secrets Managerユーザーガイド

Remediation

自動ローテーションが失敗した場合、Secrets Manager の設定でエラーが発生した可能性があります。

シークレットマネージャーでシークレットを更新するには、シークレットを所有するデータベースまたはサービスとやりとりする方法を定義する Lambda 関数を使用します。

シークレットローテーションに関連する一般的なエラーを診断して修正する方法については、」のトラブルシューティングAWS Secrets Manager秘密の回転AWS Secrets Managerユーザーガイド

[SecretsManager.3] 未使用のSecrets Manager シークレットを削除する

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

重大度: ミディアム

リソースタイプ: AWS::SecretsManager::Secret

AWS Config ルール: secretsmanager_secret_unused

パラメータ: なし

このコントロールは、シークレットを指定された日数以内にアクセスしたかどうかを確認します。デフォルト値は 90 日です。定義された日数以内にシークレットにアクセスされなかった場合、このコントロールは失敗します。

未使用の秘密を削除することは、秘密を回転させることと同じくらい重要です。未使用のシークレットは、これらのシークレットにアクセスする必要がなくなった元のユーザーによって悪用される可能性があります。また、より多くのユーザーがシークレットにアクセスすると、誰かが操作を誤り、権限のないエンティティに漏洩している可能性があります。これにより、悪用のリスクが高くなります。未使用のシークレットを削除すると、不要になったユーザーからのシークレットアクセスを取り消すことができます。また、Secrets 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. [Next (次へ)] を選択します。

  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. [Edit] を選択します。

  5. []Encryption] で、[暗号を有効化

  6. トピックの暗号化に使用する KMS キーを選択します。

  7. [Save changes] (変更の保存) をクリックします。

[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 インスタンスは、パッチ適用要件に準拠している必要があります

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

重大度:

リソースタイプ: SSM パッチコンプライアンス

AWS Config ルール: ec2-managedinstance-patch-compliance-status-check

パラメータ: なし

このコントロールは、Amazon EC2 Systems Manager パッチコンプライアンスのコンプライアンスステータスがCOMPLIANTまたはNON_COMPLIANTインスタンスにパッチをインストールした後。システムマネージャーのパッチマネージャーによって管理されているインスタンスのみがチェックされます。

組織の要求に応じて EC2 インスタンスに完全にパッチを適用すると、AWS アカウントの攻撃対象が軽減されます。

注記

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

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

  • ヨーロッパ (ミラノ)

  • 中東 (バーレーン)

Remediation

この問題を修復するには、準拠していないインスタンスに必要なパッチをインストールします。

非準拠のパッチを修正するには

  1. AWS Systems Manager コンソール (https://console.aws.amazon.com/systems-manager/) を開きます。

  2. []ノード管理] で、[Run Command[] を選択してから、Run Command

  3. [] の横にあるボタンを選択します。AWS-RunPatchBaseline

  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

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

重大度:

リソースタイプ: SSM の関連付けのコンプライアンス

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

State Manager アソシエーションコンプライアンスの詳細については、「」を参照してください。ステートマネージャーの関連付けコンプライアンスについてAWS Systems Managerユーザーガイド

注記

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

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. 問題を特定したら、失敗した関連付けを編集して問題を修正します。関連付けを編集する方法については、「」を参照してください。関連付けを編集する

ステートマネージャーの関連付けの作成と編集の詳細については、Systems Manager の関連付けの使用AWS Systems Managerユーザーガイド

[WAF.1]AWS WAF従来のグローバル Web ACL ロギングをイネーブルにする必要があります

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

重大度: ミディアム

リソースタイプ: AWS::WAF::WebACL

AWS Config ルール: waf-classic-logging-enabled

パラメータ: なし

このコントロールは、ログ記録が有効になっているかどうかをチェックしますAWS WAFグローバル Web ACL。Web ACL でログ記録が有効でない場合、このコントロールは失敗します。

ログ記録は、信頼性、可用性、パフォーマンスを維持する上で重要な部分です。AWS WAFグローバルに. これは、多くの組織におけるビジネス要件とコンプライアンスの要件であり、アプリケーションの動作をトラブルシューティングできます。また、接続された Web ACL によって分析されるトラフィックに関する詳細情報も提供します。AWS WAF。

注意

注記

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

  • 米国東部 (オハイオ)

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

  • 米国西部 (オレゴン)

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

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

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

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

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

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

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

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

  • カナダ (中部)

  • 中国 (北京)

  • 中国 (寧夏)

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

  • 欧州 (アイルランド)

  • 欧州 (ロンドン)

  • ヨーロッパ (ミラノ)

  • 欧州 (パリ)

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

  • 中東 (バーレーン)

  • 南米 (サンパウロ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

Remediation

Web ACL のロギングは、Kinesis Data Firehose コンソールから有効にできます。

ウェブ 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. [ログの有効化] を選択します。