AWS Foundational Security Best Practices コントロール

AWS Foundational Security Best Practices 標準には、次のコントロールが含まれています。各コントロールの情報には次の情報が含まれます。

コントロールが適用されるカテゴリ。カテゴリの説明については、「コントロールのカテゴリ」を参照してください。
コントロールの重要度は、コントロールと統制結果の重要性を定義します。
コントロールが評価するアプリケーションリソースコントロールの依存リソースも一覧表示されます。変更トリガー型コントロールの場合、コントロールを機能させるには、リソースを AWS Config に記録する必要があります。詳細については、「AWS Foundational Security Best Practices コントロールに必要な AWS Config リソース」を参照してください。
必要な AWS Config ルール、および AWS Security Hub によって設定された特定のパラメータ値です。
コントロールの検出に失敗した場合の解決方法を説明する修復手順。

注記

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

サービス別に分類されたコントロール

AWS アカウント

AWS Certificate Manager

Amazon API Gateway

Amazon EC2 Auto Scaling

AWS Database Migration Service

AWS Elastic Beanstalk

Elastic Load Balancing

Amazon EMR

Amazon ES

Amazon GuardDuty

AWS Identity and Access Management

Amazon Kinesis

AWS Key Management Service

AWS Lambda

AWS Network Firewall

Amazon OpenSearch Service

Amazon Relational Database Service

Amazon Redshift

Amazon Simple Storage Service

Amazon SageMaker

AWS Secrets Manager

Amazon Simple Notification Service

Amazon Simple Queue Service

AWS Systems Manager

AWS WAF

[Account.1] AWS アカウントについて、セキュリティの連絡先情報を提供する必要があります

カテゴリ: 識別 > リソース設定

重要度: 中

リソースタイプ : AWS::::Account

AWS Config ルール : security-account-information-provided

スケジュールタイプ: 定期的

パラメータ : なし

このコントロールは、Amazon Web Services (AWS) アカウントにセキュリティの連絡先情報があるかどうかを確認します。アカウントにセキュリティの連絡先情報が提供されていない場合、コントロールは失敗します。

セキュリティの代替連絡先により、AWS はお客様のアカウントに関する問題を、お客様が不在の場合は別のお客様に連絡することができます。通知は AWS Support からの場合も、AWS アカウントの使用状況に関するセキュリティ関連のトピックに関する、他の AWS のサービスサービスチームからのものである場合もあります。

注記

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

中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

AWS アカウントのセキュリティの連絡先として代替連絡先を追加するには、「AWS 請求とコスト管理ユーザーガイド」の「代替の連絡先の追加、変更、または削除」を参照してください。

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

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

重要度: 中

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

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

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

daysToExpiration: 30

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

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

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

注記

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

アフリカ (ケープタウン)
中国 (北京)
中国 (寧夏)
ヨーロッパ (ミラノ)

修正

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

E メールで検証されたドメイン

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

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

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

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

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

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

[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 が ERROR と INFO のどちらでもない場合にコントロールは失敗します。

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

注記

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

アフリカ (ケープタウン)
ヨーロッパ (ミラノ)
中東 (アラブ首長国連邦)

修正

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

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

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

重要度: 中

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

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

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

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

注記

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

アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

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

[APIGateway.3] API Gateway REST API ステージでは、AWS X-Ray トレースを有効にする必要があります

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

重要度: 低

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

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

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

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

注記

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

アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

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

[APIGateway.4] API Gateway は、AWS WAF ウェブ ACL に関連付けられている必要があります

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

重要度: 中

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

AWS Config ルール : api-gw-associated-with-waf

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、API Gateway ステージが AWS WAF Web アクセスコントロールリスト (ACL) を使用しているかどうかをチェックします。このコントロールは、AWS WAF ウェブ ACL が REST API Gateway ステージに添付済みでない場合は失敗します。

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

注記

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

アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

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

[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 キャッシュは、セキュリティを強化するために、保管中に暗号化する必要があります。

修正

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

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

API Gateway コンソール (https://console.aws.amazon.com/apigateway) を開きます。
[API] を選択します。
[Stages] (ステージ) を選択します。
API の [Stages] (ステージ) リストで、キャッシュを追加するステージを選択します。
[Settings] (設定) を選択します。
[Enable API cache] (API キャッシュを有効化) を選択します。
目的の設定を更新し、[Encrypt cache data] (キャッシュデータを暗号化する) を選択します。
[Save changes] (変更の保存) をクリックします。

[APIGateway.8] API Gateway ルートには認証タイプを指定する必要があります

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

重要度: 中

リソースタイプ : AWS::ApiGatewayV2::Route

AWS Config ルール: api-gwv2-authorization-type-configured

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon API Gateway ルートに認証タイプが設定されているかどうかを確認します。API Gateway ルートで認証タイプが指定されていない場合、コントロールは失敗します。

API Gateway は API へのアクセスを制御し管理する複数のメカニズムをサポートしています。認証タイプを指定することで、API へのアクセスを許可されたユーザーまたはプロセスのみに制限できます。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

HTTP API の認証タイプを設定するには、「API Gateway デベロッパーガイド」の「API Gateway での HTTP API へのアクセスの制御と管理」を参照してください。WebSocket API の認証タイプを設定するには、「API Gateway デベロッパーガイド」の「API Gateway での WebSocket API へのアクセスの制御と管理」を参照してください。

[APIGateway.9] API Gateway V2 ステージにアクセスロギングを設定する必要があります

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

重要度: 中

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

AWS Config ルール: api-gwv2-access-logs-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon API Gateway V2 ステージのアクセスログが設定されているかどうかをチェックします。アクセスログ設定が定義されていない場合、このコントロールは失敗します。

API Gateway アクセスログは、誰が API にアクセスしたかや、発信者が API にアクセスした方法に関する詳細情報を提供します。これらのログは、セキュリティ監査やアクセス監査、証拠調査などのアプリケーションに役立ちます。トラフィックパターンの分析や問題のトラブルシューティングを行うには、これらのアクセスログを有効にします。

その他のベストプラクティスについては、「API Gateway デベロッパーガイド」の「REST API のモニタリング」を参照してください。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

アクセスログ記録を設定するには、「API Gateway デベロッパーガイド」の「API Gateway コンソールを使用した CloudWatch による API のログの設定」を参照してください。

[AutoScaling.1] Classic Load Balancer に関連付けられた Auto Scaling グループは、ロードバランサーのヘルスチェックを使用する必要があります

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

重要度: 低

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

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

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

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

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

この問題を修正するには、Elastic Load Balancing ヘルスチェックを使用可能にするために、Auto Scaling グループを更新します。

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

Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
ナビゲーションペインの Auto Scaling で、[Auto Scaling Groups] (Auto Scaling グループ) を選択します。
ユーザーグループのチェックボックスを選択します。
[Edit] (編集) を選択します。
[Health checks] (ヘルスチェック) の [Health check type] (ヘルスチェックのタイプ) で、ELB を選択します。
[Health Check Grace Period] (ヘルスチェックの猶予期間) で、300 を入力します。
ページの最下部にある [Update] (更新) を選択します。

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

[AutoScaling.2] Amazon EC2 Auto Scaling グループは、複数のアベイラビリティーゾーンをカバーする必要があります

カテゴリ: リカバリ > 耐障害性 > 高可用性

重要度: 中

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

AWS Config ルール : autoscaling-multiple-az

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Auto Scaling グループが複数のアベイラビリティーゾーンにまたがっているかどうかをチェックします。Auto Scaling グループが複数のアベイラビリティーゾーンにまたがっていない場合、コントロールは失敗します。

Amazon EC2 Auto Scaling で、複数のアベイラビリティーゾーンを使用可能に設定できます。バッチジョブや AZ 内の転送コストを最小限に抑える必要がある場合など、一部のユースケースでは、単一のアベイラビリティーゾーンを持つ Auto Scaling グループが推奨されます。ただし、複数のアベイラビリティーゾーンにまたがらない Auto Scaling グループは、構成された単一のアベイラビリティーゾーンが使用できなくなった場合、補うために別のアベイラビリティーゾーンではインスタンスを起動しません。

修正

既存の Auto Scaling グループにアベイラビリティーゾーンを追加する方法については、「Amazon EC2 Auto Scaling ユーザーガイド」の「アベイラビリティーゾーン」を参照してください。

[AutoScaling.3] Auto Scaling グループは、EC2 インスタンスを、Instance Metadata Service Version 2 (IMDSv2) を必要とするように設定する必要があります

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

重要度: 高

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

AWS Config ルール : autoscaling-launchconfig-requires-imdsv2

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon EC2 Auto Scaling グループが起動するすべてのインスタンスで IMDSv2 が有効になっているかどうかをチェックします。インスタンスメタデータサービス (IMDS) のバージョンが起動設定に含まれていない場合、または IMDSv1 と IMDSv2 の両方が有効になっている場合、コントロールは失敗します。

IMDS は、インスタンスに関するデータで、実行中のインスタンスを設定または管理するために使用します。

IMDS のバージョン 2 では、EC2 インスタンスの保護を強化するために、IMDSv1 では利用できなかった新しい保護が追加されています。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

Auto Scaling グループは、一度に 1 つの起動設定に関連付けられます。起動設定は、作成後に変更することはできません。Auto Scaling グループの起動設定を変更するには、新しい起動設定のベースとして、既存の起動設定を IMDSv2 を有効にした上で使用します。詳細については、「Amazon EC2 Linux インスタンス用ユーザーガイド」の「新規インスタンスのインスタンスメタデータオプションの設定」を参照してください。

[AutoScaling.4] Auto Scaling グループの起動設定では、メタデータ応答ホップ制限が `1` を越えることはできません

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

重要度: 高

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

AWS Config ルール : autoscaling-launch-config-hop-limit

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

これにより、メタデータトークンが移動できる、ネットワークホップの数をチェックします。メタデータの応答ホップ制限が 1 を越えるとコントロールは失敗します。

Instance Metadata Service (IMDS) は、Amazon EC2 インスタンスに関するメタデータ情報を提供するものであり、アプリケーションの設定に役立ちます。メタデータサービスの HTTP PUT 応答を EC2 インスタンスのみに制限することで、IMDS を不正使用から保護します。

IP パケットの Time To Live (TTL) フィールドは、ホップごとに 1 ずつ削減されます。この削減により、パケットを EC2 外に移動させないようにすることができます。IMDSv2 は、オープンルーター、レイヤー 3 ファイアウォール、VPN、トンネル、または NAT デバイスとして誤って構成された可能性のある EC2 インスタンスを保護し、権限のないユーザーがメタデータを取得できないようにします。IMDSv2 では、デフォルトのメタデータ応答ホップ制限が 1 に設定されているため、シークレットトークンを含む PUT 応答は、インスタンスの外に移動することができません。ただし、この値が 1 より大きい場合、トークンは EC2 インスタンスから移動することができます。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

既存の起動設定のメタデータ応答ホップ制限を変更する方法の詳細については、「Amazon EC2 Linux インスタンス用ユーザーガイド」の「既存インスタンスのインスタンスメタデータオプションの変更」を参照してください。

[Autoscaling.5] Auto Scaling グループの起動設定を使用して起動した Amazon EC2 インスタンスは、パブリック IP アドレスを含みません

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

重要度: 高

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

AWS Config ルール : autoscaling-launch-config-public-ip-disabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Auto Scaling グループに関連付けられた起動設定が、グループのインスタンスにパブリック IP アドレスを割り当てるかどうかをチェックします。関連付けられた起動設定が、パブリック IP アドレスを割り当てている場合に、このコントロールは失敗します。

Auto Scaling グループの起動設定の Amazon EC2 インスタンスには、限定されたエッジケースを除き、パブリック IP アドレスを関連付けないでください。Amazon EC2 インスタンスは、インターネットに直接公開されるのではなく、ロードバランサーを介した場合のみアクセスできるようにする必要があります。

注記

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

アジアパシフィック (ジャカルタ)
アジアパシフィック (大阪)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

Auto Scaling グループは、一度に 1 つの起動設定に関連付けられます。起動設定は、作成後に変更できません。Auto Scaling グループの起動設定を変更するには、新しい起動設定のベースとして既存の起動設定を使用します。次に、以下の手順に記述しているように、新しい起動設定を使用するように Auto Scaling グループを更新します。

Auto Scaling グループの起動設定を変更すると、以後、新しいインスタンスは新しい設定オプションを使用して起動されます。既存のインスタンスは影響を受けません。既存のインスタンスを更新するには、これらのインスタンスを終了して Auto Scaling グループに置き換えるか、オートスケーリングによって終了ポリシーに基づいて古いインスタンスを新しいインスタンスに徐々に置き換えるようにします。

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

Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
ナビゲーションペインの Auto Scaling で、[Launch Configurations] (起動設定) を選択します。
起動設定を選択し、[Actions] (アクション)、[Copy launch configuration] (起動設定のコピー) の順に選択します。これにより、新しい起動設定は元の設定と同じオプションで設定されますが、名前に「コピー」が追加されます。
[Create Launch Configuration] (起動設定の作成) ページの、[Additional configuration - optional] (追加設定 - オプション) で、[Advanced details] (高度な詳細) を展開します。
[IP address type] (IP アドレスタイプ) で、[Do not assign a public IP address to any instances] (インスタンスにパブリック IP アドレスを割り当てない) を選択します。
完了したら、[Create launch configuration] (起動設定の作成) を選択します。
ナビゲーションペインの Auto Scaling で、[Auto Scaling Groups] (Auto Scaling グループ) を選択します。
Auto Scaling グループの横にあるチェックボックスを選択します。
ページ下部に分割ウィンドウが開き、選択したグループの情報が表示されます。
[Details] (詳細) タブで、[Launch configuration] (起動設定)、[Edit] (編集) の順に選択します。
[Launch Configuration] (起動設定) で、新しい起動設定を選択します。
起動設定の変更が完了したら、[Update] (更新) を選択します。

[AutoScaling.6] Auto Scaling グループは、複数のアベイラビリティーゾーンで複数のインスタンスタイプを使用する必要があります

カテゴリ: リカバリ > 耐障害性 > 高可用性

重要度: 中

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

AWS Config ルール : autoscaling-multiple-instance-types

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon EC2 Auto Scaling グループが複数のインスタンスタイプを使用しているかどうかをチェックします。Auto Scaling グループで 1 つのインスタンスタイプしか定義されていない場合、そのコントロールは失敗します。

複数のアベイラビリティーゾーンで実行されている複数のインスタンスタイプ間でアプリケーションをデプロイすることで、可用性を向上させることができます。Security Hub では、選択したアベイラビリティーゾーンに十分なインスタンス容量がない場合に Auto Scaling グループが別のインスタンスタイプを起動できるよう、複数のインスタンスタイプを使用することが推奨されます。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

複数のインスタンスタイプを使用して Auto Scaling グループを作成する手順については、「Amazon EC2 Auto Scaling ユーザーガイド」の「複数のインスタンスタイプと購入オプションを使用する Auto Scaling グループ」を参照してください。

[Auto Scaling.9] EC2 Auto Scaling グループは EC2 起動テンプレートを使用する必要があります

カテゴリ: 識別 > リソース設定

重要度: 中

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

AWS Config ルール : autoscaling-launch-template

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon EC2 Auto Scaling グループが、EC2 起動テンプレートから作成されたものかどうかを確認します。Amazon EC2 Auto Scaling グループが起動テンプレートを使用して作成されていない場合、または混合インスタンスポリシーで起動テンプレートが指定されていない場合、このコントロールは失敗します。

EC2 Auto Scaling グループは、EC2 起動テンプレートまたは起動設定のいずれかから作成できます。ただし、起動テンプレートを使用して Auto Scaling グループを作成することで、最新の機能や改善点に確実にアクセスできます。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

EC2 起動テンプレートを使用して Auto Scaling グループを作成するには、「Amazon EC2 Auto Scalingユーザーガイド」の「起動テンプレートを使用して Auto Scaling グループを作成する」を参照してください。起動設定を起動テンプレートに置き換える方法については、「Windows インスタンス用 Amazon EC2 ユーザーガイド」の「起動設定を起動テンプレートに置き換える」を参照してください。

[CloudFormation.1] CloudFormation スタックは、Simple Notification Service (SNS) と統合させる必要があります

カテゴリ: 検出 > 検出サービス > アプリケーションモニタリング

重要度: 低

リソースタイプ : AWS::CloudFormation::Stack

AWS Config ルール : cloudformation-stack-notification-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

SNSTopic1: 30
SNSTopic2: 30
SNSTopic3: 30
SNSTopic4: 30
SNSTopic5: 30
(Optional): SNS topic ARN: 30

このコントロールは、Amazon Simple Notification Service の通知が CloudFormation スタックに統合されているかどうかをチェックします。CloudFormation スタックに関連付けられた SNS 通知がない場合、そのコントロールは失敗します。

SNS 通知を、CloudFormation スタックを使って設定すると、スタックで発生したイベントや変更を、ステークホルダーにすぐに通知することができます。

注記

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

アフリカ (ケープタウン)
アジアパシフィック (香港)
アジアパシフィック (ジャカルタ)
アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
ヨーロッパ (ミラノ)
ヨーロッパ (パリ)
ヨーロッパ (ストックホルム)
中東 (バーレーン)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

CloudFormation スタックを更新する方法の詳細については、AWS CloudFormation ユーザーガイドの「AWS CloudFormation スタックの更新」を参照してください。

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

カテゴリ: 保護 > セキュアなアクセス管理 > パブリックアクセスが不可能なリソース

重要度: 非常事態

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

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

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

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

注記

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

修正

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

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

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

重要度: 中

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

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

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

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

注記

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

修正

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

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

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

重要度: 中

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

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

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

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

注記

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

修正

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

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

カテゴリ: リカバリ > 耐障害性 > 高可用性

重要度: 低

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

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

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

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

注記

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

修正

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

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

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

重要度: 中

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

AWS Config ルール : cloudfront-accesslogs-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

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

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

注記

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

修正

CloudFront ディストリビューションのアクセスログ記録の設定方法については、「Amazon CloudFront 開発者ガイド」の「標準ログ (アクセスログ) の設定および使用」を参照してください。

[CloudFront.6] CloudFront ディストリビューションでは、AWS WAF を有効にする必要があります

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

重要度: 中

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

AWS Config ルール : cloudfront-associated-with-waf

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

AWS WAF は、ウェブアプリケーションと API を攻撃から保護するウェブアプリケーションファイアウォールです。これで、ウェブアクセスコントロールリスト (ウェブ ACL) と呼ばれる一連のルールを設定することができます。このルールは、ユーザーが定義するカスタマイズ可能なウェブセキュリティルールと条件に基づいて、ウェブリクエストを許可、ブロック、またはカウントします。CloudFront ディストリビューションを悪意のある攻撃から保護するために、AWS WAF ウェブ ACL に確実に関連付けられていることを確認しください。

注記

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

修正

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

[CloudFront.7] CloudFront ディストリビューションでは、カスタム SSL/TLS 証明書を使用する必要があります

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

重要度: 中

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

AWS Config ルール : cloudfront-custom-ssl-certificate

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、CloudFront ディストリビューションで、CloudFront が提供するデフォルトの SSL/TLS 証明書を使用しているかどうかをチェックします。CloudFront ディストリビューションで、カスタム SSL/TLS 証明書が使用されている場合に、このコントロールは成功します。CloudFront ディストリビューションで、デフォルト SSL/TLS 証明書が使用されている場合に、このコントロールは失敗します。

カスタム SSL/TLS を使用すると、ユーザーは代替ドメイン名を使用してコンテンツにアクセスできます。カスタム証明書は AWS Certificate Manager (推奨)、または IAM で保存できます。

注記

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

修正

CloudFront ディストリビューション用のカスタム SSL/TLS 証明書を使用して代替ドメイン名を追加する場合、「Amazon CloudFront 開発者ガイド」の「代替ドメイン名の追加」を参照してください。

[CloudFront.8] CloudFront ディストリビューションでは、SNI を使用して HTTPS リクエストを処理する必要があります

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

重要度: 低

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

AWS Config ルール : cloudfront-sni-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon CloudFront ディストリビューションでカスタム SSL/TLS 証明書が使用されていて、SNI を使用して HTTPS リクエストを処理するように設定されているかチェックします。カスタム SSL/TLS 証明書が関連付けられているものの、SSL/TLS サポートメソッドが専用 IP アドレスである場合、このコントロールは失敗します。

Server Name Indication (SNI) は、2010 年以降にリリースされたブラウザとクライアントでサポートされている TLS プロトコルを拡張したものです。SNI を使用して HTTPS リクエストに対応するように CloudFront を設定した場合、CloudFront は代替ドメイン名を各エッジロケーションの IP アドレスと関連付けます。ビューワーがコンテンツに対して HTTPS リクエストを送信すると、DNS は、正しいエッジロケーションの IP アドレスにリクエストをルーティングします。ドメイン名の IP アドレスが SSL/TLS ハンドシェイクネゴシエーション中に決定されます。IP アドレスはディストリビューション専用にはなりません。

注記

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

修正

SNI を使用して HTTPS リクエストを処理するように CloudFront ディストリビューションを設定するには、「CloudFront 開発者ガイド」の「SNI を使用した HTTPS リクエストの処理 (ほとんどのクライアントで動作)」を参照してください。

[CloudFront.9] CloudFront ディストリビューションでは、カスタムオリジンへのトラフィックを暗号化する必要があります

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

重要度: 中

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

AWS Config ルール : cloudfront-traffic-to-origin-encrypted

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon CloudFront ディストリビューションがカスタムオリジンへのトラフィックを暗号化しているかチェックします。このコントロールは、オリジンプロトコルポリシーが「http-only」を許可されている CloudFront ディストリビューションでは失敗します。ディストリビューションのオリジンプロトコルポリシーが「match-viewer」で、ビューワープロトコルポリシーが「allow-all」である場合にも、このコントロールは失敗します。

HTTPS (TLS) は、ネットワークトラフィックの傍受や操作を防止するために使用できます。HTTPS (TLS) 経由の暗号化された接続のみを許可する必要があります。

注記

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

修正

CloudFront 接続の暗号化を要求するようにオリジンプロトコルポリシーを更新するには、「Amazon CloudFront 開発者ガイド」の「CloudFront とカスタムオリジン間の通信で HTTPS を必須にする」を参照してください。

[CloudFront.10] CloudFront ディストリビューションは、エッジロケーションとカスタムオリジン間に非推奨の SSL プロトコルを使用しないでください

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

重要度: 中

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

AWS Config ルール : cloudfront-no-deprecated-ssl-protocols

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon CloudFront ディストリビューションが、CloudFront エッジロケーションとカスタムオリジン間の HTTPS 通信に、非推奨の SSL プロトコルを使用しているかどうかをチェックします。CloudFront ディストリビューションに、OriginSslProtocols が SSLv3 を含む CustomOriginConfig が使用されていると、このコントロールは失敗します。

2015 年、Internet Engineering Task Force (IETF) は、SSL 3.0 はプロトコルの安全性が不十分であることから廃止すべきであると、正式に発表しました。カスタムオリジンへの HTTPS 通信には、TLSv1.2 以降を使用することが推奨されます。

注記

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

修正

CloudFront ディストリビューションのオリジン SSL プロトコルを更新する方法については、「Amazon CloudFront デベロッパーガイド」の「CloudFront とカスタムオリジン間の通信で HTTPS を必須にする」を参照してください。

[CloudFront.12] CloudFront ディストリビューションは、存在しない S3 オリジンをポイントしない必要があります。

カテゴリ: 識別 > リソース設定

重要度: 高

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

AWS Config ルール : cloudfront-s3-origin-non-existent-bucket

スケジュールタイプ: 定期的

パラメータ : なし

このコントロールは、Amazon CloudFront ディストリビューションが存在しない Amazon S3 オリジンをポイントしていないかどうかを確認します。存在しないバケットをポイントするようにオリジンが設定されている場合、CloudFront ディストリビューション用のコントロールは失敗します。このコントロールは、静的ウェブサイトホスティングのない S3 バケットが S3 オリジンである CloudFront ディストリビューションのみに適用されます。

アカウントの CloudFront ディストリビューションが、存在しないバケットをポイントする設定になっている場合、悪意のある第三者が参照先のバケットを作成し、ディストリビューションを通して独自のコンテンツを供給してくる恐れがあります。ルーティング動作に関係なくすべてのオリジンをチェックして、ディストリビューションが適切なオリジンをポイントしていることを確認することをお勧めします。

注記

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

修正

CloudFront ディストリビューションを変更して新しいオリジンをポイントさせるには、「Amazon CloudFront デベロッパーガイド」の「ディストリビューションの更新」を参照してください。

[CloudTrail.1] CloudTrail を有効にして、少なくとも 1 つのマルチリージョンの追跡で、読み取りと書き込みの管理イベントを含めた設定をする必要があります。

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

重要度: 高

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

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

スケジュールタイプ: 定期的

パラメータ:

readWriteType: ALL

このコントロールは、マルチリージョンの CloudTrail 追跡が少なくとも 1 つあることをチェックします。また、ExcludeManagementEventSources パラメータは少なくとも 1 つの軌跡に対して空です。

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

API 発信者の ID
API コールの時刻
API 発信者の送信元 IP アドレス
パラメータのリクエスト
AWS のサービスによって返されるレスポンス要素

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

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

マルチリージョン追跡により、使用していないリージョンで発生する予期しないアクティビティを検出できます。
マルチリージョン追跡では、グローバルサービスイベントのログ記録がデフォルトで追跡に対して確実に有効になっています。グローバルサービスイベントのログ記録では、AWS グローバルサービスによって生成されたイベントが記録されます。
マルチリージョン追跡では、すべての読み取りオペレーションと書き込みオペレーションの管理イベントによって、CloudTrail がすべての AWS アカウントのリソースに対する管理オペレーションを確実に記録します。

デフォルトでは、AWS Management Console を使用して作成される CloudTrail 追跡はマルチリージョン追跡です。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

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

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

CloudTrail コンソール (https://console.aws.amazon.com/cloudtrail/) を開きます。
これまでに CloudTrail を使用したことがない場合は、[Get Started Now] (今すぐ始める) を選択します。
[Trails] (追跡) を選択し、[Create trail] (追跡の作成) を選択します。
追跡の名前を入力します。
[Storage location] (ストレージのロケーション) で、次のいずれかの操作を行います。
1. CloudTrail ログ用に新しい S3 バケットを作成するには、[Create a new S3 bucket] (新しい S3 バケットを作成) で、[Yes] (はい) を選択し、新しい S3 バケットの名前を入力します。
2. 既存の S3 バケットを使用するには、[Create a new S3 bucket] (新しい S3 バケットを作成) で [No] (いいえ) を選択し、使用する S3 バケットを選択します。
[Additional settings] (その他の設定) で、[Advanced] (詳細設定) を選択します。[Enable log file validation] (ログファイルの検証を有効化) で、[Enabled] (有効) を選択します。
[Create] (作成) を選択します。

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

CloudTrail コンソール (https://console.aws.amazon.com/cloudtrail/) を開きます。
[Trails] (追跡) を選択します。
[Name] (名前) 列で、追跡の名前を選択します。
[Management events] (管理イベント) で、[Edit] (編集) を選択します。
[Read/Write events] (読み取り/書き込みイベント) で、[Management events] (管理イベント) を選択します。
[API Activity] (API アクティビティ) で、[Read] (読み取り) と [Write] (書き込み) を選択します。

[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)」によって暗号化されることに注意してください。

修正

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

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

CloudTrail コンソール (https://console.aws.amazon.com/cloudtrail/) を開きます。
[Trails] (追跡) を選択します。
更新する追跡を選択します。
[General details] (一般的な詳細) で、[Edit] (編集) を選択します。
[Log file SSE-KMS encryption] (ログファイルの SSE-KMS 暗号化) を使用する場合、[Enabled] (有効) を選択してください。
[Create a new KMS key] (新規の KMS キーの作成) で、次のいずれかの操作を行います。
- [Create a new tag key] (新規のタグキーの作成) を選択します。次に、[AWS KMS alias] (KMS エイリアス) に、キーのエイリアスを入力します。キーは、S3 バケットと同じリージョンに作成されます。
- 既存のキーを使用するには、[Existing] (既存) を選択し、[AWS KMS alias] (KMS エイリアス) からキーを選択します。
  
  AWS KMS キーおよび S3 バケットは同じリージョンにある必要があります。
[Save] (保存) を選択します。

KMS キーと正常にやり取りするためには、CloudTrail のポリシーを変更する必要がある場合があります。詳細については、「AWS CloudTrail ユーザーガイド」の「AWS KMS マネージドキー (SSE-KMS) による 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 ユーザーガイド」の「バリデーションの有効化とファイルの検証」を参照してください。

修正

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

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

CloudTrail コンソール (https://console.aws.amazon.com/cloudtrail/) を開きます。
[Trails] (追跡) を選択します。
[Name] (名前) で、編集する追跡の名前を選択します。
[General details] (一般的な詳細) で、[Edit] (編集) を選択します。
[Additional settings] (その他の設定) で、[Log file validation] (ログファイルの検証) に対して、[Enabled] (有効) を選択します。
[Save changes] (変更の保存) を選択します。

詳細については、「AWS CloudTrail ユーザーガイド」の「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 発信者のアイデンティティ
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 アドレスに基づいてリアルタイムおよび過去のアクティビティを簡単にログに記録できます。この方法を使用して、異常または機密性の高いアカウントアクティビティに対してアラームと通知を確立できます。

修正

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

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

CloudTrail コンソール (https://console.aws.amazon.com/cloudtrail/) を開きます。
[Trails] (追跡) を選択します。
[CloudWatch Logs Log group] (CloudWatch Logs ログのグループ) の値のない追跡を選択してください。
[CloudWatch Logs] で、[Edit] (編集) を選択します。
[Enabled] (有効) を選択します。
[Log group] (ロググループ) で、次のいずれかの操作を行います。
- デフォルトのロググループを使用するには、名前を変更しないでください。
- 既存のロググループを使用するには、[Existing] (既存) を選択し、使用するロググループの名前を入力します。
- 新しいロググループを作成するには、[New] (新規) を選択し、作成するロググループの名前を入力します。
[IAM role] (IAM ロール) で、次のいずれかを実行します。
- 既存のロールを使用する場合は、[Existing] (既存) を選択し、次にドロップダウンリストからロールを選択します。
- 新しいロールを作成する場合は、[New] (新規) を選択し、作成するロールの名前を入力します。新しいロールには、必要な許可を付与するポリシーが割り当てられます。
ロールに付与された許可を表示するには、[Policy document] (ポリシードキュメント) を展開します。
[Save changes] (変更の保存) を選択します。

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

[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 を使用します。個人用アクセストークンまたはユーザー名とパスワードを使用すると、意図しないデータ漏えいや不正アクセスに認証情報が公開される可能性があります。

修正

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

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

CodeBuild コンソール (https://console.aws.amazon.com/codebuild/) を開きます。
個人用のアクセストークンまたはユーザー名とパスワードを含むビルドプロジェクトを選択します。
[Edit] (編集) から、[Source] (ソース) を選択します。
[Disconnect from GitHub / Bitbucket] (GitHub/Bitbucket から切断) を選択します。
[Connect using OAuth] (OAuth を使用して接続する) を選択し、[Connect to GitHub / Bitbucket] (GitHub/Bitbucket に接続する) を選択します。
プロンプトが表示されたら、[authorize as appropriate] (必要に応じて認可)を選択します。
必要に応じて、[Repository URL] (リポジトリ URL) と [additional configuration] (追加の設定) を再設定します。
[Update source] (ソースの更新) を選択します。

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

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

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

重要度: 非常事態

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

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

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

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

注記

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

アフリカ (ケープタウン)
ヨーロッパ (ミラノ)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

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

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

CodeBuild コンソール (https://console.aws.amazon.com/codebuild/) を開きます。
[Build] (ビルド) を展開します。
[Build project] (ビルドプロジェクト) を選択して、プレーンテキストの認証情報を含むビルドプロジェクトを選択します。
[Edit] (編集) から [Environment] (環境) を選択します。
[Additional configuration] (追加設定) を展開します。
環境変数の横にある [Remove] (削除) を選択します。
[Update environment] (環境の更新) を選択します。

重要な値は AWS Systems Manager パラメータストアに保存後、ビルド仕様から取得するには

CodeBuild コンソール (https://console.aws.amazon.com/codebuild/) を開きます。
[Build] (ビルド) を展開します。
[Build project] (ビルドプロジェクト) を選択して、プレーンテキストの認証情報を含むビルドプロジェクトを選択します。
[Edit] (編集) から [Environment] (環境) を選択します。
[Additional configuration] (追加設定) を展開し、[Environment variables] (環境変数) までスクロールします。
「このチュートリアル」に従って、機密データを含む Systems Manager パラメータを作成します。
パラメータを作成したら、パラメータ名をコピーします。
CodeBuild コンソールに戻り、[Create environmental variable] (環境変数の作成) を選択します。
ビルド仕様に表示される変数の名前を入力します。
[Value] (値) には、パラメータの名前を貼り付けます。
[Type] (タイプ) で [Parameter] (パラメータ) を選択します。
プレーンテキストの認証情報を含む非準拠の環境変数を削除するには、[Remove] (削除) を選択します。
[Update environment] (環境の更新) を選択します。

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

[CodeBuild.3] CodeBuild S3 ログは暗号化する必要があります

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

重要度: 低

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

AWS Config ルール : codebuild-project-s3-logs-encrypted

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、AWS CodeBuild プロジェクトの Amazon S3 ログが暗号化されているかどうかを確認します。CodeBuild プロジェクトの S3 ログの暗号化が無効になっていると、コントロールは失敗します。

保管中のデータの暗号化は、データ周辺にアクセス管理のレイヤーを追加するために推奨されるベストプラクティスです。保管中のログを暗号化すると、AWS に認証されていないユーザーがディスクに保存されているデータにアクセスすることのリスクが軽減されます。権限のないユーザーがデータにアクセスできる能力を制限するための一連のアクセスコントロールが追加されます。

注記

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

アジアパシフィック (ジャカルタ)
アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

CodeBuild プロジェクトの S3 ログの暗号化設定を変更するには、「AWS CodeBuild ユーザーガイド」の「AWS CodeBuild でのビルドプロジェクトの設定の変更」を参照してください。

[CodeBuild.4] CodeBuild プロジェクト環境にはログ記録の設定が必要です

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

重要度: 中

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

AWS Config ルール : codebuild-project-logging-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、CodeBuild プロジェクト環境で S3 または CloudWatch ログが有効になっているログオプションが、少なくとも 1 つあるかどうかをチェックします。CodeBuild プロジェクト環境で少なくとも 1 つのログオプションが有効になっていない場合は、このコントロールは失敗します。

セキュリティの観点から、ログ記録はセキュリティインシデントが発生した場合に、将来的に証拠の取り組みを可能にするために重要な機能です。CodeBuild プロジェクトの異常を脅威検出と関連付けることで、これらの脅威検出の精度に対する信頼性を高めることができます。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

CodeBuild プロジェクトログの設定方法の詳細については、「CodeBuild ユーザーガイド」の「ビルドプロジェクトの作成 (コンソール)」を参照してください。

[CodeBuild.5] CodeBuild プロジェクト環境では特権モードを有効にしないでください

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

重要度: 高

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

AWS Config ルール : codebuild-project-environment-privileged-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、AWS CodeBuild CodeBuild プロジェクト環境で特権モードが有効にかどうかをチェックします。このコントロールは、AWS CodeBuild CodeBuild プロジェクト環境で特権モードが有効な場合は失敗します。

デフォルトでは、Docker コンテナはどのデバイスにもアクセスを許可できません。権限モードは、ビルドプロジェクトの Docker コンテナにすべてのデバイスへのアクセスを許可します。Docker コンテナ内で Docker デーモンを実行するには、privilegedMode を値 true で設定します。Docker デーモンは、Docker API リクエストをリッスンし、イメージ、コンテナ、ネットワーク、ボリュームなどの Docker オブジェクトを管理します。このパラメータは、ビルドプロジェクトを使用して Docker イメージをビルドする場合にのみ、true に設定する必要があります。それ以外の場合は、Docker API およびコンテナの基盤となるハードウェアへの意図しないアクセスを防ぐため、この設定を無効にする必要があります。これは、privilegedMode への意図しないアクセスが悪意のある改ざんや重要なリソースの削除においてリスクを伴う可能性があります。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

CodeBuild プロジェクト環境設定の設定方法の詳細については、「CodeBuild ユーザーガイド」の「ビルドプロジェクトの作成 (コンソール)」を参照してください。

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

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

重要度: 中

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

AWS Config ルール: なし

スケジュールタイプ: 定期的

パラメータ : なし

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

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

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

注記

Config.1 では、Security Hub を使用するすべてのリージョンで AWS Config を有効にすることが要求されています。

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

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

グローバルリソース記録が有効になっていないリージョンでは、IAM.1、IAM.2、IAM.3、IAM.5、IAM.8、IAM.21 を無効にすることも検討してください。IAM はグローバルサービスであるため、IAM リソースはグローバルリソース記録が有効になっているリージョンでのみ記録されます。

詳細については、「AWS Config 開発者ガイド」の「AWS Config の使用開始」を参照してください。

修正

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

AWS Config 設定を構成するには

AWS Config コンソール (https://console.aws.amazon.com/config/) を開きます。
AWS Config を設定するリージョンを選択します。
AWS Config をこれまでに使用したことがない場合は、「AWS Config デベロッパーガイド」の「使用の開始」を参照してください。
メニューから [Settings] (設定) ページに進み、次を実行します。
- [Edit] (編集) を選択します。
- [Resource types to record] (記録するリソースタイプ) で、[Record all resources supported in this region] (このリージョンでサポートされているすべてのリソースを記録します) および [Include global resources (e.g., AWS IAM resources)] (グローバルリソースを含める(例: IAM リソース)) を選択します。
- [Data retention period] (データ保持期間) で、AWS Config データのデフォルトの保持期間を選択するか、個別に保持期間を指定します。
- [AWS Config role] (ロール) で、[Create AWS Config service-linked role] (サービスにリンクされたロールの作成) を選択するか、[Choose a role from your account] (アカウントからロールを選択) を選択し、使用するロールを選択します。
- [Amazon S3 bucket] (Amazon S3 バケット) で、バケットを使用するか、バケットを作成し、必要に応じてプレフィックスを含めます。
- [Amazon SNS topic] (Amazon SNS トピック) で、アカウントから Amazon SNS トピックを選択するか、トピックを作成します。Amazon SNS の詳細については、「Amazon Simple Notification Service の使用開始ガイド」を参照してください。
[Save] (保存) を選択します。

AWS CLI から AWS Config を使用する方法の詳細については、「AWS Config 開発者ガイド」の「AWS Config の有効化」を参照してください。

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

[DMS.1] AWS Database Migration Service レプリケーションインスタンスは、パブリックでない必要があります

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

重要度: 非常事態

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

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

スケジュールタイプ: 定期的

パラメータ : なし

このコントロールは、AWS DMS レプリケーションインスタンスがパブリックかどうかをチェックします。これを行うために、PubliclyAccessible フィールドの値を調査します。

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

また、AWS DMS インスタンス設定へのアクセスが認可されたユーザーのみに制限されていることも確認する必要があります。これを行うには、ユーザーの IAM 許可を AWS DMS 設定とリソースの変更に制限します。

注記

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

アフリカ (ケープタウン)
ヨーロッパ (ミラノ)
中東 (アラブ首長国連邦)

修正

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

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

AWS Database Migration Service コンソール (https://console.aws.amazon.com/dms/) を開きます。
[Replication instances] (レプリケーションインスタンス) に移動し、パブリックインスタンスを削除します。インスタンスを選択し、[Actions] (アクション)、[Delete] (削除) の順に選択します。
[Create replication instance] (レプリケーションインスタンスの作成) を選択します。設定の詳細を入力します。
パブリックアクセスを無効にするには、[Publicly accessible] (パブリックアクセス可能) が選択されていないことを確認します。
[Create] (作成) を選択します。

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

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

カテゴリ: リカバリ > 耐障害性 > 高可用性

重要度: 中

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

AWS Config ルール : dynamodb-autoscaling-enabled

スケジュールタイプ: 定期的

パラメータ : なし

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

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

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

注記

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

修正

キャパシティモードで既存テーブルの DynamoDB オートスケーリングを有効にする詳細な手順については、「Amazon DynamoDB 開発者ガイド」の「既存のテーブルでの DynamoDB Auto Scaling の有効化」を参照してください。

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

カテゴリ: リカバリ > 耐障害性 > バックアップの有効化

重要度: 中

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

AWS Config ルール : dynamodb-pitr-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

バックアップは、セキュリティインシデントからより迅速に復元するために役立ちます。また、システムの耐障害性を強化します。DynamoDB のポイントインタイムリカバリでは、DynamoDB テーブルのバックアップがオートメーションされます。偶発的な削除や書き込み操作から回復する時間が短縮されます。PITR を有効にした DynamoDB テーブルは、過去 35 日間の任意の時点に復元できます。

修正

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

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

DynamoDB コンソールを (https://console.aws.amazon.com/dynamodb/) で開きます。
使用するテーブルを選択してから、[Backups] (バックアップ) を選択します。
[Point-in-time Recovery] (ポイントインタイムリカバリ) セクションの [Status] (ステータス) で、[Enable] (有効) を選択します。
[Enable] (有効) をもう一度選択し、変更を確認します。

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

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

重要度: 中

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

AWS Config ルール : dax-encryption-enabled

スケジュールタイプ: 定期的

パラメータ : なし

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

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

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

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

[EC2.1] Amazon EBS スナップショットはパブリックにしないでください。これは、誰でも復元可能であるかどうかを基に判断されます。

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

重要度: 非常事態

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

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

スケジュールタイプ: 定期的

パラメータ : なし

このコントロールは、Amazon Elastic Block Store スナップショットがパブリックではないかどうかをチェックします。Amazon EBS スナップショットを誰でも復元できる場合、コントロールは失敗します。

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

注記

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

アフリカ (ケープタウン)
ヨーロッパ (ミラノ)
中東 (アラブ首長国連邦)

修正

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

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

Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
ナビゲーションペインで Elastic Block Store の [Snapshots] (スナップショット) メニューを選択し、パブリックスナップショットを選択します。
[Actions] (アクション) から、[Modify permissions] (許可を変更する) を選択します。
[Private] (プライベート) を選択します。
(オプション) スナップショットの共有を許可されたアカウントの AWS アカウント番号を追加し、[Add Permission] (許可の追加) を選択します。
[Save] (保存) を選択します。

[EC2.2] VPC のデフォルトのセキュリティグループでは、インバウンドトラフィックとアウトバウンドトラフィックを許可しないようにする必要があります

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

重要度: 高

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

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

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

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

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

修正

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

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

Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。
ナビゲーションペインで、[Security groups] (セキュリティグループ) を選択します。デフォルトのセキュリティグループの詳細を表示して、それらに割り当てられているリソースを確認します。
リソースに対して最小特権のセキュリティグループのセットを作成します。セキュリティグループの作成方法の詳細については、「Amazon VPC ユーザーガイド」の「セキュリティグループの作成」を参照してください。
Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
Amazon EC2 コンソールで、デフォルトのセキュリティグループを使用しているリソースのセキュリティグループを、作成した最小特権のセキュリティグループに変更します。詳細については、「Amazon VPC ユーザーガイド」の「インスタンスのセキュリティグループを変更する」を参照してください。

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

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

Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。
ナビゲーションペインで、[Security groups] (セキュリティグループ) を選択します。
デフォルトのセキュリティグループを選択し、[Inbound rules] (インバウンドルール) タブを選択します。[Edit inbound rules] (インバウンドルールの編集) を選択します。次に、すべてのインバウンドルールを削除します。[Save Rules] (ルールの保存) を選択します。
各デフォルトセキュリティグループに対して、前のステップを繰り返します。
デフォルトのセキュリティグループを選択し、[Outbound rule] (アウトバウンドルール) タブを選択します。[Edit outbound rules] (アウトバウンドルールの編集) を選択します。次に、すべてのアウトバウンドルールを削除します。[Save Rules] (ルールの保存) を選択します。
各デフォルトセキュリティグループに対して、前のステップを繰り返します。

詳細については、「Amazon VPC ユーザーガイド」の「セキュリティグループの操作」を参照してください。

[EC2.3] 添付済みの EBS ボリュームは、保管中に暗号化する必要があります

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

重要度: 中

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

AWS Config ルール : encrypted-volumes

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

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

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

注記

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

アフリカ (ケープタウン)
ヨーロッパ (ミラノ)
中東 (アラブ首長国連邦)

修正

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

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

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

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

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

重要度: 中

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

AWS Config ルール : ec2-stopped-instance

スケジュールタイプ: 定期的

パラメータ:

allowedDays: 30

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

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

注記

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

アフリカ (ケープタウン)
ヨーロッパ (ミラノ)
中東 (アラブ首長国連邦)

修正

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

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

終了しても Amazon EBS ボリュームが削除されないことをチェックしてください。
必要なデータを EC2 インスタンスストアボリュームから Amazon EBS または Amazon S3 にコピーします。

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

Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
ナビゲーションペインの [Instances] (インスタンス) で、[Instances] (インスタンス) を選択します。
インスタンスを選択し、[Actions] (アクション)、[Instance State] (インスタンスの状態)、[Terminate] (終了) の順に選択します。
確認を求めるメッセージが表示されたら、[Yes, Terminate] (はい、終了する) を選択します。

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

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

AWS CLI から terminate-instances を使用します
Tools for Windows PowerShell から Stop-EC2Instance を使用します。

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

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

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

重要度: 中

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

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

スケジュールタイプ: 定期的

パラメータ:

trafficType: REJECT

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

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

Security Hub では、VPC のパケット拒否のフローログ記録を有効にすることを推奨します。フローログは、VPC を通過するネットワークトラフィックを可視化し、セキュリティワークフロー中の異常なトラフィックを検出したりインサイトを提供できます。

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

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

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

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

Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。
[Virtual Private Cloud] (仮想プライベートクラウド) で、VPC を選択します。
更新する VPC を選択します。
ページの最下部で、[Flow Logs] (フローログ) を選択します。
[Create flow log] (フローログの作成) を選択します。
[Filter] (フィルター) で、[Reject] (拒否) を選択します。
[Destination log group] (送信先ロググループ) で、使用するロググループを選択します。
[IAM role] (IAM ロール) で、使用する IAM ロールを選択します。
[Create] (作成) を選択します。

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

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

重要度: 中

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

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

スケジュールタイプ: 定期的

パラメータ : なし

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

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

次のインスタンスタイプでは暗号化がサポートされないことに注意してください: R1、C1、および M1。

注記

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

アジアパシフィック (ジャカルタ)
アジアパシフィック (大阪)
中東 (アラブ首長国連邦)

修正

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

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

Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
ナビゲーションペインの [EC2 Dashboard] (EC2 ダッシュボード) を選択します。
ページの右上で、[Account Attributes, EBS encryption] (アカウントの属性、EBS 暗号化) を選択します。
[Manage] (管理) を選択します。
[Enable] (有効化) を選択します。デフォルトの暗号化キーとして、ユーザーの代わりに作成したエイリアス alias/aws/ebs をデフォルトの暗号化キーとして AWS マネージドキーを保持するか、対称カスタマーマネージドキーを選択できます。
[Update EBS encryption] (EBS 暗号化を更新する) を選択します。

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

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

重要度: 高

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

AWS Config ルール : ec2-imdsv2-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

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

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

ウェブサイトアプリケーションのファイアウォールを開く
リバースプロキシを開く
サーバー側リクエスト偽造 (SSRF) の脆弱性
レイヤー 3 ファイアウォールおよびネットワークアドレス変換 (NAT) を開く

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

注記

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

アフリカ (ケープタウン)
ヨーロッパ (ミラノ)
中東 (アラブ首長国連邦)

修正

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

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

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

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

Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
[Launch instance] (インスタンスを起動) を選択し、[Launch instance] (インスタンスを起動) を選択します。
[Advanced details] (高度な詳細) の下の [Metadata version] (メタデータバージョン) には、[V2 only (token required)] (V2 のみ (トークンが必要)) を選択します。
[Summary] (概要) パネルで変更内容を確認し、[Launch instance] (インスタンスを起動) を選択します。

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

[EC2.9] EC2 インスタンスは、パブリック IP アドレスが設定されていない必要があります

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

重要度: 高

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

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

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

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

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

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

修正

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

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

EC2 インスタンスから自動で割り当てられたパブリック IP アドレスを手動でインスタンスに関連付ける、または、関連付け解除することはできません。EC2 インスタンスがパブリック IP アドレスを受信するかどうかをコントロールするには、以下のいずれかのの方法を使用します。

サブネットのパブリック IP アドレス指定属性を変更する。詳細については、「Amazon VPC ユーザーガイド」の「サブネットのパブリック IPv4 アドレス指定属性の変更」を参照してください。
起動時にパブリック IP アドレス指定属性機能を有効または無効にします。これにより、サブネットのパブリック IP アドレス指定属性が上書きされます。詳細については、「Amazon EC2 Linux インスタンス用ユーザーガイド」の「インスタンス起動時のパブリック IPv4 アドレスの割り当て」を参照してください。

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

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

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

Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
ナビゲーションペインで Elastic IP を選択します。
関連付けを解除する Elastic IP アドレスを選択します。
[Actions] (アクション) で、[Disassociate Elastic IP address] (Elastic IP アドレスの関連付け解除) を選択します。
[Disassociate] (関連付け解除) を選択します。

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

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

重要度: 中

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

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

スケジュールタイプ: 定期的

パラメータ:

serviceName: ec2

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

このコントロールは、単一のアカウントのリソースを評価します。アカウント外のリソースは記述できません。これは AWS Config と Security Hub ではクロスアカウントチェックを行わないため、アカウント間で共有済みの VPC に関する FAILED 結果が表示されます。Security Hub では、これらの FAILED 結果を抑制することを推奨します。

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

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

修正

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

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

Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。
ナビゲーションペインで、[Endpoints] (エンドポイント) を選択します。
[エンドポイントの作成] を選択します。
[Service category] (サービスカテゴリ) で、AWS のサービス を選択します。
[Service Name] (サービス名) で com.amazonaws.<region>.ec2 を選択します。
[Type] (タイプ) で、[Interface] (インターフェイス) を選択します。
以下の情報を入力します。
1. VPC で、エンドポイントを作成する先の VPC を選択します。
2. [Subnets] (サブネット) で、エンドポイントネットワークインターフェイスを作成する先のサブネット (アベイラビリティーゾーン) を選択します。すべての AWS のサービスで、すべてのアベイラビリティーゾーンがサポートされているわけではありません。
3. インターフェイスエンドポイントのプライベート DNS を有効にするには、[Enable DNS Name] (DNS 名を有効にする) でチェックボックスを選択します。デフォルトでは、このオプションは有効になっています。
  
  オプションとしてプライベート DNS を使用するには、次の VPC 属性を true に設定する必要があります。
  - enableDnsHostnames
  - enableDnsSupport
  詳細については、「Amazon VPC ユーザーガイド」の「VPC の DNS 属性の表示と更新」を参照してください。
4. [Security group] (セキュリティグループ) で、エンドポイントネットワークインターフェイスに関連付けるセキュリティグループを選択します。
5. (オプション) タグを追加または削除します。タグを追加するには、[Add tag] (タグの追加) を選択して、次の操作を実行します。
  - [Key] (キー) にタグ名を入力します。
  - [Value] (値) に、タグの値を入力します。
6. タグを削除するには、タグの [Key] (キー) と [Value] (値) の右側にある [delete] (削除) ボタン (x) を選択にします。
[Create endpoint] (エンドポイントの作成) を選択します。

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

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

アクションを実行できるプリンシパル
実行可能なアクション
アクションが実行できるリソース

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

[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 (米国西部)

修正

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

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

Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。
ナビゲーションペインで、[Subnets] (サブネット) を選択します。
サブネットを選択し、[Subnet Actions] (サブネットアクション)、[Modify auto-assign IP settings] (自動割り当て IP 設定の変更) の順に選択します。
[Enable auto-assign public IPv4 address] (パブリック IPv4 アドレスの自動割り当てを有効にする) チェックボックスからチェックを外し、[Save] (保存) を選択します。

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

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

重要度: 低

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

AWS Config ルール : vpc-network-acl-unused-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

コントロールは、リソース AWS::EC2::NetworkAcl の項目設定をチェックして、ネットワーク ACL の関係を判断します。

ネットワーク ACL の VPC のみの関係の場合、コントロールは失敗します。

他の関係がリスト済みの場合、コントロールは成功します。

注記

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

アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

未使用のネットワーク ACL を削除する方法については、「Amazon VPC ユーザーガイド」の「ネットワーク ACL の削除」を参照してください。デフォルトのネットワーク ACL またはサブネットに関連付けられた ACL は削除できません。

[EC2.17] EC2 インスタンスは複数の ENI を使用しないでください

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

重要度: 低

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

AWS Config ルール : ec2-instance-multiple-eni-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

Adapterids (オプション) - EC2 インスタンスに添付済みのネットワークインターフェイス ID のリスト

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

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

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

注記

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

アジアパシフィック (大阪)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

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

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

Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
[Network & Security] (ネットワークとセキュリティ) で、[Network Interfaces] (ネットワークインターフェイス) を選択します。
非準拠インスタンス ID でリストをフィルタリングして、関連付けられた ENI を表示します。
削除する ENI を選択します。
[Actions] (アクション) メニューから、[Detach] (デタッチ) を選択します。
[Are you sure that you want to detach the following network interface?] (次のネットワークインターフェイスをデタッチしてもよろしいですか?) プロンプトが表示された場合、[Detach] (デタッチ) を選択します。

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

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

重要度: 高

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

AWS Config ルール : vpc-sg-open-only-to-authorized-ports

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

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

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

セキュリティグループルールポート番号で無制限の着信トラフィックが許可されているが、ポート番号が authorizedTcpPorts で指定されている場合、コントロールは成功します。authorizedTcpPorts のデフォルト値は 80, 443 です。
セキュリティグループルールポート番号で無制限の着信トラフィックが許可されているが、ポート番号が authorizedTcpPorts 入力パラメータで指定されていない場合、コントロールは失敗します。
パラメータを使用しない場合、無制限のインバウンドルールを持つセキュリティグループに対してコントロールが失敗します。

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

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

注記

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

修正

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

[EC2.19] セキュリティグループは、リスクの高いポートへの無制限アクセスを許可してはいけません

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

重要度: 非常事態

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

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

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、指定した高リスクのポートにセキュリティグループの受信 SSH トラフィックがアクセス可能かどうかをチェックします。セキュリティグループ内のルールがこれらのポートへの 0.0.0.0/0 からの入力トラフィックを許可しない場合、このコントロールは成功します。

無制限のアクセス (0.0.0.0/0) では、ハッキング、サービス拒否攻撃、データ損失などの悪意のあるアクティビティの機会が増えます。

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

20、21 (FTP)
22 (SSH)
23 (Telnet)
25 (SMTP)
110 (POP3)
135 (RPC)
143 (IMAP)
445 (CIFS)
1433、1434 (MSSQL)
3000 (Go、Node.js、および Ruby のウェブ開発フレームワーク)
3306 (mySQL)
3389 (RDP)
4333 (ahsp)
5000 (Python ウェブ開発フレームワーク)
5432 (postgresql)
5500 (fcp-addr-srvr1)
5601 (OpenSearch Dashboards)
8080 (proxy)
8088 (レガシー HTTP ポート)
8888 (代替 HTTP ポート)
9200 または 9300 (OpenSearch)

修正

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

[EC2.20] AWS Site-to-Site VPN 接続用の VPN トンネルは、両方とも起動している必要があります。

カテゴリ: 耐障害性 > リカバリ > 高可用性

重要度: 中

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

AWS Config ルール : vpc-vpn-2-tunnels-up

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

VPN トンネルは暗号化されたリンクで、AWS Site-to-Site VPN 接続内で、ユーザーのネットワークと AWS の間でデータをやり取りできます。各 VPN 接続には、高可用性のために同時に使用できる 2 つの VPN トンネルが含まれています。VPN 接続をするために両方の VPN トンネルが確実に稼働していることは、AWS VPC とリモートネットワーク間の安全で可用性の高い接続を確認するために重要です。

このコントロールは、AWS Site-to-Site VPN が提供する両方の VPN トンネルが UP ステータスであることをチェックします。一方または両方のトンネルのステータスが DOWN の場合、コントロールは失敗します。

注記

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

アジアパシフィック (ジャカルタ)
アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
中東 (バーレーン)

修正

VPN トンネルオプションを変更するには、「AWS Site-to-Site VPN ユーザーガイド」の「Site-to-Site VPN トンネルオプションの変更」を参照してください。

[EC2.21] ネットワーク ACL は、0.0.0.0/0 からポート 22、またはポート 3389 への侵入をを許可しないようにする必要があります

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

重要度: 中

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

AWS Config ルール : nacl-no-unrestricted-ssh-rdp

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、ネットワークアクセスコントロールリスト (NACL) が、 SSH/RDP 侵入トラフィックのデフォルト TCP ポートへのアクセスを無制限に許可しているかどうかをチェックします。NACL インバウンドエントリが TCP ポート 22 または 3389 に対して「0.0.0.0/0」または「::/0」の送信元 CIDR ブロックを許可する場合、ルールは失敗します。

ポート 22 (SSH) やポート 3389 (RDP) などのリモートサーバー管理ポートへのアクセスは、VPC 内のリソースへの意図しないアクセスを許可する可能性があるため、パブリックにアクセスできないようにする必要があります。

注記

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

中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

NACL の詳細については、「VPC ユーザーガイド」の「ネットワーク ACL」を参照してください。

[EC2.22] 未使用の EC2 セキュリティグループを削除する必要があります

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

重要度: 中

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

AWS Config ルール : ec2-security-group-attached-to-eni-periodic

スケジュールタイプ: 定期的

パラメータ : なし

この AWS コントロールは、セキュリティグループが Amazon Elastic Compute Cloud (Amazon EC2) インスタンスまたは Elastic Network Interface に添付済みであることをチェックします。セキュリティグループが Amazon EC2 インスタンスまたは Elastic Network Interface に関連付けられていない場合、コントロールは失敗します。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

セキュリティグループを作成、割り当て、削除するには、「Amazon EC2 ユーザーガイド」の「セキュリティグループ」を参照してください。

[EC2.23] EC2 Transit Gateway は VPC アタッチメントリクエストを自動的に受け付けるべきではありません

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

重要度: 高

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

AWS Config ルール : ec2-transit-gateway-auto-vpc-attach-disabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、EC2 Transit Gateway が共有 VPC アタッチメントを自動的に受け入れているかどうかをチェックします。Transit Gateway が共有 VPC アタッチメントリクエストを自動的に受け入れていると、このコントロールは失敗します。

AutoAcceptSharedAttachments をオンにすると、Transit Gateway は、リクエストまたはアタッチメントの発信元であるアカウントを確認せずに、クロスアカウント VPC アタッチメントリクエストを自動的に受け入れるように設定されます。認可および認証のベストプラクティスに従うため、この機能はオフにして、認証された VPC アタッチメントリクエストのみを受け入れることが推奨されます。

注記

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

アジアパシフィック (香港)
アジアパシフィック (ムンバイ)
アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
中東 (バーレーン)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

Transit Gateway の変更方法の詳細については、「Amazon VPC デベロッパーガイド」の「Modify a transit gateway」(Transit Gateway の変更) を参照してください。

[EC2.24] 準仮想化 EC2 インスタンスタイプは使用しないでください

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

重要度: 中

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

AWS Config ルール : ec2-paravirtual-instance-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、EC2 インスタンスの仮想化タイプが準仮想化かどうかをチェックします。EC2 インスタンスの virtualizationType が paravirtual に設定されている場合、このコントロールは失敗します。

Linux Amazon マシンイメージ (AMI)では、2 つの仮想化タイプ、準仮想化 (PV) とハードウェア仮想化 (HVM) のうち、いずれかを使用します。PV AMI と HVM AMI の主な違いは、起動の方法と、パフォーマンス向上のための特別なハードウェア拡張機能 (CPU、ネットワーク、ストレージ) を利用できるかどうかという点です。

従来、PV のゲストは HVM のゲストよりも多くの場合にパフォーマンスが向上しました。ただし、HVM 仮想化の機能強化や HVM AMI で PV ドライバが利用可能になったことにより、このようなパフォーマンスの向上はなくなりました。詳細については、「Amazon EC2 Linux インスタンス用ユーザーガイド」の「Linux AMI 仮想化タイプ」を参照してください。

注記

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

米国東部 (オハイオ)
アフリカ (ケープタウン)
アジアパシフィック (香港)
アジアパシフィック (ジャカルタ)
アジアパシフィック (ムンバイ)
アジアパシフィック (大阪)
アジアパシフィック (ソウル)
カナダ (中部)
中国 (北京)
中国 (寧夏)
欧州 (ロンドン)
ヨーロッパ (ミラノ)
ヨーロッパ (パリ)
ヨーロッパ (ストックホルム)
中東 (バーレーン)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

EC2 インスタンスを新しいインスタンスタイプに更新する方法については、「Amazon EC2 Linux インスタンス用ユーザーガイド」の「インスタンスタイプを変更する」を参照してください。

[EC2.25] EC2 起動テンプレートはパブリック IP をネットワークインターフェースに割り当ててはなりません

カテゴリ: 保護 > セキュアなネットワーク設定 > パブリックアクセス不可のリソース

重要度: 高

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

AWS Config ルール : ec2-launch-template-public-ip-disabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon EC2 起動テンプレートが起動の際にネットワークインターフェイスにパブリック IP アドレスを割り当てる設定になっていないかをチェックします。EC2 起動テンプレートがネットワークインターフェイスにパブリック IP アドレスを割り当てる設定になっている場合、またはパブリック IP アドレスを持つネットワークインターフェイスが 1 つ以上ある場合、コントロールは失敗します。

パブリック IP アドレスは、インターネットから到達可能な IP アドレスです。パブリック IP アドレスを使用してネットワークインターフェイスを設定すると、それらのネットワークインターフェイスに関連付けられたリソースは、インターネットからアクセスできる可能性があります。EC2 リソースへのパブリックアクセスを可能にすべきではありません。ワークロードへの意図しないアクセスが可能になる可能性があるためです。

注記

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

中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

EC2 起動テンプレートを更新するには、「Amazon EC2 Auto Scaling ユーザーガイド」の「デフォルトのネットワークインターフェイス設定を変更する」を参照してください。

[ECR.1] ECR プライベートリポジトリでは、イメージスキャニングが設定されている必要があります

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

重要度: 高

リソースタイプ : AWS::ECR::Repository

AWS Config ルール : ecr-private-image-scanning-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、プライベート ECR リポジトリでイメージスキャニングが設定されているかどうかをチェックします。プライベート ECR リポジトリでイメージスキャニングが設定されていないと、このコントロールは失敗します。各リポジトリがこのコントロールを渡すようにプッシュ時にスキャンを設定する必要もあることに注意してください。

ECR イメージスキャニングは、コンテナイメージ内のソフトウェアの脆弱性を特定するのに役立ちます。ECR は、オープンソースの Clair プロジェクトの共通脆弱性識別子 (CVE) データベースを使用し、スキャン結果のリストを表示します。ECR リポジトリでイメージスキャンを有効にすると、保存されているイメージの整合性と安全性を検証するレイヤーが追加されます。

注記

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

アジアパシフィック (ジャカルタ)
アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

ECR リポジトリのイメージスキャニングを設定する方法については、「Amazon Elastic Container Registry User Guide」(Amazon Elastic Container Registry ユーザーガイド) の「Image scanning」(イメージスキャニング) を参照してください。

[ECR.2] ECR プライベートリポジトリでは、タグのイミュータビリティが設定されている必要があります

カテゴリ: 識別 > インベントリ > タグ付け

重要度: 中

リソースタイプ : AWS::ECR::Repository

AWS Config ルール : ecr-private-tag-immutability-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、プライベート ECR リポジトリでタグのイミュータビリティが有効になっているかどうかをチェックします。プライベート ECR リポジトリでタグのイミュータビリティが無効になっていると、このコントロールは失敗します。このルールは、タグのイミュータビリティが有効で、かつ値が IMMUTABLE に設定されていると成功します。

Amazon ECR のタグのイミュータビリティにより、ユーザーは、イメージの説明タグを信頼性の高いメカニズムとして使用し、イメージを追跡して一意に識別することができます。イミュータブルなタグは静的です。つまり、各タグは一意のイメージを参照します。静的タグを使用すると、常に同じイメージがデプロイされるので、信頼性とスケーラビリティが向上します。設定すると、タグのイミュータビリティにより、タグが上書きされなくなり、アタックサーフェスが減少します。

注記

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

アジアパシフィック (ジャカルタ)
アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

イミュータブル (変更不可能) なタグが設定されたリポジトリを作成する場合、または既存のリポジトリのイメージタグのイミュータビリティ (変更不可能性) を更新するには、Amazon Elastic Container Registry ユーザーガイドの「イメージタグの変更可能性」を参照してください。

[ECR.3] ECR リポジトリには、少なくとも 1 つのライフサイクルポリシーが設定されている必要があります

カテゴリ: 識別 > リソース設定

重要度: 中

リソースタイプ : AWS::ECR::Repository

AWS Config ルール : ecr-private-lifecycle-policy-configured

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon ECR リポジトリに少なくとも 1 つのライフサイクルポリシーが設定されているかどうかをチェックします。ECR リポジトリにライフサイクルポリシーが設定されていない場合、このコントロールは失敗します。

Amazon ECR ライフサイクルポリシーを使用すると、リポジトリ内のイメージのライフサイクル管理を有効にすることができます。ライフサイクルポリシーを設定することで、未使用イメージのクリーンアップと、年数またはカウントに基づいたイメージの有効期限を自動化することができます。これらのタスクを自動化することで、リポジトリで古いイメージを意図せずに使用することを回避できます。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

ライフサイクルポリシーを設定するには、「Amazon Elastic Container Registry ユーザーガイド」の「ライフサイクルポリシーのプレビューを作成する」を参照してください。

[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 が空の場合、コントロールが失敗します。このコントロールは、Amazon ECS タスク定義の最新のアクティブなリビジョンのみを評価します。

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

注記

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

アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

タスク定義を更新する方法については、「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 カンマ区切りリスト。

Amazon ECS サービスで AssignPublicIP が ENABLED に設定されていて、このパラメータリストで指定されている場合、このルールは COMPLIANT が使用されます。

Amazon ECS サービスで AssignPublicIP が ENABLED に設定されていて、このパラメータリストで指定されていない場合、このルールは NON_COMPLIANT が使用されます。

このコントロールは、Amazon ECS サービスがパブリック IP アドレスの自動割り当てが設定されているかどうかをチェックします。AssignPublicIP が ENABLED の場合、このコントロールは失敗します。AssignPublicIP が DISABLED の場合、このコントロールは成功です。

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

注記

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

修正

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

[ECS.3] ECS タスクの定義では、ホストのプロセス名前空間を共有しないでください

カテゴリ: 識別 > リソース設定

重要度: 高

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

AWS Config ルール: ecs-task-definition-pid-mode-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon ECS のタスク定義が、ホストのプロセス名前空間をそのコンテナと共有するように設定されているかどうかをチェックします。タスク定義が、ホストのプロセス名前空間を、そこで実行されているコンテナと共有している場合、このコントロールは失敗します。このコントロールは、Amazon ECS タスク定義の最新のアクティブなリビジョンのみを評価します。

プロセス ID (PID) 名前空間は、プロセス間を分離します。これにより、システムプロセスが可視化されることを防ぎ、PID 1 を含む PID の再利用が可能になります。ホストの PID 名前空間がコンテナと共有されている場合、コンテナは、ホストシステム上のすべてのプロセスを参照できるようになります。これにより、ホストとコンテナ間をプロセスレベルで分離するメリットが減ります。このような状況は、ホストそれ自体で行われているプロセスへの、不正アクセス (プロセスの操作や終了など) につながる可能性があります。ユーザーは、ホストのプロセス名前空間を、そこで実行されているコンテナと共有すべきではありません。

修正

タスク定義上で pidMode を設定する方法については、「Amazon Elastic Container Service デベロッパーガイド」の「タスク定義パラメータ」を参照してください。

[ECS.4] ECS コンテナは、非特権として実行する必要があります

カテゴリ: 保護 > セキュアなアクセス管理 > ルートユーザーのアクセス制限

重要度: 高

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

AWS Config ルール: ecs-containers-nonprivileged

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon ECS のタスク定義の、コンテナ定義の privileged パラメータが true に設定されているかどうかをチェックします。このパラメータの値が true である場合、このコントロールは失敗します。このコントロールは、Amazon ECS タスク定義の最新のアクティブなリビジョンのみを評価します。

昇格された特権を、ECS タスク定義から削除することが推奨されます。この特権パラメータが true の場合、このコンテナには、ホストコンテナインスタンスに対する昇格された特権が付与されます (ルートユーザーと同様)。

注記

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

アジアパシフィック (ジャカルタ)
アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

タスク定義上で privileged を設定する方法については、「Amazon Elastic Container Service デベロッパーガイド」の「詳細コンテナ定義パラメータ」を参照してください。

[ECS.5] ECS コンテナは、ルートファイルシステムへの読み取り専用アクセスに制限する必要があります。

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

重要度: 高

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

AWS Config ルール: ecs-containers-readonly-access

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon ECS コンテナが、マウントされたルートファイルシステムへの読み取り専用アクセスに制限されているかどうかをチェックします。Amazon ECS のタスク定義の、コンテナ定義における ReadonlyRootFilesystem パラメータが false に設定されている場合、このコントロールは失敗します。このコントロールは、Amazon ECS タスク定義の最新のアクティブなリビジョンのみを評価します。

このオプションを有効にすると、ファイルシステムフォルダとディレクトリに対する明示的な読み取り/書き込み権限がない限り、コンテナインスタンスのファイルシステムへの改ざんや書き込みができないため、セキュリティ攻撃ベクトルを減らすことができます。このコントロールは、最小特権の原則にも準拠しています。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

コンテナ定義をルート filesystems (クラシック Amazon ECS コンソール) への読み取り専用アクセスに制限するには

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

クラシック Amazon ECS コンソールを使用
ナビゲーションペインで、[Task Definitions] (タスク定義) をクリックします。
更新の必要なコンテナ定義を含む各タスク定義で、次の操作を行います。
- 更新の必要なコンテナ定義を選択します。
- [Edit Container] (コンテナを編集) を選択します。[Storage and Logging] (ストレージとログ記録) で、[Read only root file system] (読み取り専用ルートファイルシステム) を選択します。
- [Edit Container] (コンテナを編集) タブの下にある [Update] (更新) をクリックします。
- [Create] (作成) を選択します。

[ECS.8] シークレットは、コンテナ環境の変数として渡さないでください

カテゴリ: 保護 > セキュアな開発 > 認証情報がハードコーディングされていない

重要度: 高

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

AWS Config ルール: ecs-no-environment-secrets

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

secretKeys = AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、ECS_ENGINE_AUTH_DATA

このコントロールは、コンテナ定義の environment パラメータにある、任意の変数のキー値に、AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、ECS_ENGINE_AUTH_DATA のいずれかが含まれているかどうかをチェックします。任意のコンテナ定義内の単一の環境変数が、AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、ECS_ENGINE_AUTH_DATA のいずれかである場合、このコントロールは失敗します。このコントロールは、Amazon S3 など、他のロケーションから渡される環境変数は対象としません。このコントロールは、Amazon ECS タスク定義の最新のアクティブなリビジョンのみを評価します。

AWS Systems Manager Parameter Store を使用すると、組織のセキュリティ体制の改善に役立ちます。シークレットと認証情報は、コンテナインスタンスに渡したり、コードにハードコーディングしたりするのではなく、Parameter Store を使用して保存することが推奨されます。

注記

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

アジアパシフィック (ジャカルタ)
アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

SSM を使用してパラメータを作成する方法については、「AWS Systems Manager ユーザーガイド」の「Systems Manager パラメータを作成する」を参照してください。シークレットを指定するタスク定義の作成に関する詳細は、「Amazon Elastic Container Service デベロッパーガイド」の「Secrets Manager を使用した機密データの指定」を参照してください。

[ECS.10] Fargate サービスは、Fargate プラットフォームの最新バージョンで実行する必要があります。

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

重要度: 中

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

AWS Config ルール : ecs-fargate-latest-platform-version

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon ECS Fargate サービスが最新バージョンの Fargate プラットフォームで実行されているかどうかをチェックします。プラットフォームが最新バージョンでない場合、このコントロールは失敗します。

AWS Fargate プラットフォームのバージョンとは、カーネルとコンテナランタイムのバージョンの組み合わせである、Fargate タスクのインフラストラクチャの特定のランタイム環境を指します。新しいプラットフォームのバージョンは、ランタイム環境の進化に伴ってリリースされます。例えば、新しいバージョンは、カーネルやオペレーティングシステムの更新、新機能、バグ修正、セキュリティ更新があったときなどにリリースされます。セキュリティの更新やパッチは、Fargateのタスクに自動的にデプロイされます。プラットフォームのバージョンに影響を与えるセキュリティ上の問題が見つかった場合、AWS はそのプラットフォームバージョンにパッチを適用します。

注記

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

アジアパシフィック (ジャカルタ)
アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

プラットフォームバージョンを含む既存サービスの更新方法については、「Amazon Elastic Container Service デベロッパーガイド」の「サービスの更新」を参照してください。

[ECS.12] ECS クラスターでは、Container Insights を有効にする必要があります

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

重要度: 中

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

AWS Config ルール : ecs-container-insights-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、ECS クラスターが Container Insights を使用しているかどうかをチェックします。クラスターで Container Insights がセットアップされていない場合、このコントロールは失敗します。

モニタリングは、Amazon ECS クラスターの信頼性、可用性、パフォーマンスを維持する上で欠かせない要素です。CloudWatch Container Insights を使用して、コンテナ化されたアプリケーションとマイクロサービスのメトリクスとログを収集、集計、要約します。CloudWatch は、CPU やメモリ、ディスク、ネットワークなど、多数のリソースのメトリクスを自動的に収集します。Container Insights では、問題の迅速な特定と解決に役立つ、コンテナの再起動失敗などの診断情報も提供されます。また、Container Insights が収集するメトリクスには CloudWatch アラームを設定できます。

注記

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

アジアパシフィック (ジャカルタ)
アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
ヨーロッパ (ミラノ)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

Container Insights の使用方法については、「Amazon CloudWatch ユーザーガイド」の「サービスの更新」を参照してください。

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

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

重要度: 中

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

AWS Config ルール : efs-encrypted-check

スケジュールタイプ: 定期的

パラメータ : なし

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

DescribeFileSystems レスポンスで Encrypted は、false に設定されている。
DescribeFileSystems レスポンスの KmsKeyId キーが efs-encrypted-check の KmsKeyId パラメータと一致しない。

このコントロールでは、efs-encrypted-check の KmsKeyId パラメータを使用しないことに注意してください。Encrypted の値のみをチェックします。

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

注記

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

アフリカ (ケープタウン)
ヨーロッパ (ミラノ)
中東 (アラブ首長国連邦)

修正

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

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

カテゴリ: リカバリ > 耐障害性 > バックアップ

重要度: 中

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

AWS Config ルール : efs-in-backup-plan

スケジュールタイプ: 定期的

パラメータ : なし

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

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

注記

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

アフリカ (ケープタウン)
ヨーロッパ (ミラノ)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

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

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

Amazon Elastic File System コンソール (https://console.aws.amazon.com/efs/) を開きます。
[File systems] (ファイルシステム) ページで、自動バックアップを有効にするファイルシステムを選択します。

[File system details] (ファイルシステムの詳細) ページが表示されます。
[General] (全般) で、[Edit] (編集) を選択します。
自動バックアップを有効にするには、[Enable automatic backups] (自動バックアップを有効化) を選択します。
[Save changes] (変更の保存) を選択します。

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

[EFS.3] EFS アクセスポイントは、ルートディレクトリを適用する必要があります

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

重要度: 中

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

AWS Config ルール : efs-access-point-enforce-root-directory

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon EFS アクセスポイントが、ルートディレクトリを適用するように設定されているかどうかをチェックします。Path の値が / (ファイルシステムのデフォルトのルートディレクトリ) に設定されていると、このコントロールは失敗します。

ルートディレクトリを適用すると、アクセスポイントを使用する NFS クライアントは、ファイルシステムのルートディレクトリではなく、アクセスポイントに設定されているルートディレクトリを使用します。アクセスポイントのルートディレクトリを適用すると、アクセスポイントのユーザーを、指定されたサブディレクトリのファイルにのみアクセスさせ、データアクセスを制限することができます。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

EFS アクセスポイントのルートディレクトリを適用する方法については、Amazon Elastic File System ユーザーガイドの「アクセスポイントでルートディレクトリを適用する」を参照してください。

[EFS.4] EFS アクセスポイントは、ユーザー ID を適用する必要があります

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

重要度: 中

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

AWS Config ルール : efs-access-point-enforce-user-identity

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon EFS アクセスポイントが、ユーザーアイデンティティを適用するように設定されているかどうかをチェックします。EFS アクセスポイントの作成中に POSIX ユーザー ID が定義されていない場合、このコントロールは失敗します。

Amazon EFS アクセスポイントは、EFS ファイルシステムへのアプリケーション固有のエントリポイントです。これにより、共有データセットへのアプリケーションアクセスが管理しやすくなります。アクセスポイントを使用すると、アクセスポイントを介したすべてのファイルシステム要求に対してユーザーアイデンティティ (ユーザーの POSIX グループなど) を適用できます。また、ファイルシステムに対して別のルートディレクトリを適用し、このディレクトリまたはそのサブディレクトリ内のデータに対してのみ、クライアントにアクセスを許可することもできます。

注記

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

アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

Amazon EFS アクセスポイントのユーザーアイデンティティを適用する方法については、Amazon Elastic File System ユーザーガイドの「アクセスポイントを使用したユーザ ID の適用」を参照してください。

[EKS.2] EKS クラスターは、サポートされている Kubernetes バージョンで実行する必要があります。

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

重要度: 高

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

AWS Config ルール : eks-cluster-supported-version

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

eks:oldestVersionSupported (現在サポートされている最も古いバージョンは 1.22)

このコントロールは、Amazon EKS クラスターが、サポートされている Kubernetes バージョンで実行されているかどうかをチェックします。EKS クラスターがサポートされていないバージョンで実行されている場合、このコントロールは失敗します。Kubernetes バージョン 1.21 は 2023 年 2 月 15 日に廃止されるため、このコントロールはクラスターがバージョン 1.22 以降で実行されているかどうかを確認します。詳細については、「Amazon EKS ユーザーガイド」の「Amazon EKS Kubernetes リリースカレンダー」を参照してください。

アプリケーションが Kubernetes の特定のバージョンを必要としない場合は、EKS がクラスター用にサポートしている、Kubernetes の使用可能な最新バージョンを使用することが推奨されます。Amazon EKS でサポートされている Kubernetes バージョンの詳細については、「Amazon EKS ユーザーガイド」の「Amazon EKS Kubernetes リリースカレンダー」および「Amazon EKS バージョンのサポートとよくある質問」を参照してください。

注記

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

アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

EKS クラスターの更新方法については、「Amazon EKS ユーザーガイド」の「Amazon EKS クラスターの Kubernetes バージョンの更新」を参照してください。

[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 (米国西部)

修正

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

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

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

重要度: 高

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

AWS Config ルール : elastic-beanstalk-managed-updates-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

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

注記

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

アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

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

[ELB.2] HTTPS/SSL リスナーを使用する Classic Load Balancers は、AWS Certificate Manager によって提供される証明書を使用する必要があります。

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

重要度: 中

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

AWS Config ルール : elb-acm-certificate-required

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

Classic Load Balancer が AWS Certificate Manager (ACM) によって提供される HTTPS/SSL 証明書を使用しているかどうかをチェックします。HTTPS/SSL リスナーで構成された Classic Load Balancer が ACM によって提供される証明書を使用しない場合、コントロールは失敗します。

証明書の作成には、ACM または SSL や TLS プロトコルをサポートする OpenSSL などのツールを使用できます。Security Hub では、ACM を使用して､ロードバランサーの証明書を作成またはインポートすることを推奨します。

ACM は Classic Load Balancer と統合して、ロードバランサーに証明書をデプロイできます。また、これらの証明書は自動的に更新する必要があります。

注記

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

アフリカ (ケープタウン)
アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
ヨーロッパ (ミラノ)
AWS GovCloud (米国東部)

修正

ACM SSL/TLS 証明書を Classic Load Balancer に関連付ける方法については、ナレッジセンターの記事「AWS ACM SSL/TLS 証明書を Classic Load Balancer、Application Load Balancer、または Network Load Balancer と関連付ける方法を教えてください」を参照してください。

[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 リスナーを使用する必要があります。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

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

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

Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
ナビゲーションペインで、[Load Balancers] (ロードバランサー) を選択します。[Classic Load Balancer] を選択します。
[Listeners] (リスナー) タブを選択し、[Edit] (編集) を選択します。
すべてのリスナーについて、[Load Balancer Protocol] (ロードバランサーのプロトコル) が HTTPS または SSL に設定されていない場合は、設定を HTTPS または SSL に変更します。
変更されたすべてのリスナーに対して、[SSL Certificate] (SSL 証明書) で、[Change] (変更) を選択します。
変更されたすべてのリスナーに対して、[Choose a certificate from ACM] (ACM から証明書を選択する) を選択します。
[Certificate] (証明書) ドロップダウンリストから証明書を選択します。次に、[Save] (保存) を選択します。
すべてのリスナーを更新したら、[Save] (保存) を選択します。

[ELB.4] Application Load Balancer は、HTTP ヘッダーを削除するように設定する必要があります

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

重要度: 中

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

AWS Config ルール : alb-http-drop-invalid-header-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、AWS Application Load Balancer が無効な HTTP ヘッダーを確実に削除するように設定されているかを評価します。routing.http.drop_invalid_header_fields.enabled の値が false に設定されている場合、コントロールは失敗します。

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

ELB.12 が有効になっている場合、このコントロールを無効にできます。

注記

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

アフリカ (ケープタウン)
アジアパシフィック (大阪)
ヨーロッパ (ミラノ)

修正

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

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

Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
ナビゲーションペインで、[Load Balancers] (ロードバランサー) を選択します。
Application Load Balancer を選択します。
[Actions] (アクション) で、[Edit attributes] (属性の編集) を選択します。
[Drop Invalid Header Fields] (無効なヘッダーフィールドを削除) で、[Enable] (有効) を選択します。
[Save] (保存) を選択します。

[ELB.5] アプリケーションおよび Classic Load Balancer のログ記録を有効にする必要があります

カテゴリ: ログ記録

重要度: 中

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

AWS Config ルール : elb-logging-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

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

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

修正

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

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

Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
ナビゲーションペインで、[Load Balancers] (ロードバランサー) を選択します。
[Application Load Balancer] または [Classic Load Balancer] を選択します。
[Actions] (アクション) で、[Edit attributes] (属性の編集) を選択します。
[Access logs] (アクセスログ) で、[Enable] (有効) を選択します
S3 のロケーションを入力します。このロケーションは既存のものを使用するか、作成することもできます。プレフィックスを指定しない場合、アクセスログは S3 バケットのルートに保存されます。
[Save] (保存) を選択します。

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

カテゴリ: リカバリ > 耐障害性 > 高可用性

重要度: 中

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

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

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

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

修正

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

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

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

Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
ナビゲーションペインの [LOAD BALANCING] (ロードバランシング) で [Load Balancers] (ロードバランサー) を選択します。
ロードバランサーを選択します。
[Description] (説明) タブで、[Edit attributes] (属性の編集) を選択します。
[Edit load balancer attributes] (ロードバランサー属性の編集) ページで、[Enable for Delete Protection] (削除保護を有効にする) を選択し、[Save] (保存) を選択します。
[Save] (保存) を選択します。

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

[ELB.7] Classic Load Balancers は、Connection Draining を有効にする必要があります

カテゴリ: リカバリ > 耐障害性

重要度: 中

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

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

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Classic Load Balancers で Connection Draining が有効になっているかどうかをチェックします。

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

修正

Classic Load Balancers で Connection Draining を有効にするには、「Classic Load Balancer ユーザーガイド」の「Configure connection draining for your Classic Load Balancer (Classic Load Balancer の Connection Draining を設定する)」のステップに従ってください。

[ELB.8] HTTPS/SSL リスナーを使用する Classic Load Balancers は、強力な設定を持つ事前定義されたセキュリティポリシーを使用する必要があります

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

重要度: 中

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

AWS Config ルール : elb-predefined-security-policy-ssl-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

predefinedPolicyName: ELBSecurityPolicy-TLS-1-2-2017-01

このコントロールは、Classic Load Balancer の HTTPS/SSL リスナーが事前定義されたポリシー ELBSecurityPolicy-TLS-1-2-2017-01 を使用しているかどうかをチェックします。Classic Load Balancer の HTTPS/SSL リスナーが ELBSecurityPolicy-TLS-1-2-2017-01 を使用しない場合、コントロールは失敗します。

セキュリティポリシーは、SSL プロトコル、暗号、およびサーバーの優先順位オプションを組み合わせたものです。事前定義されたポリシーは、クライアントとロードバランサー間の SSL ネゴシエーションでサポートする暗号、プロトコル、および優先順位をコントロールします。

ELBSecurityPolicy-TLS-1-2-2017-01 を使用すると、SSL および TLS の特定のバージョンを無効にする必要があるコンプライアンスとセキュリティ標準に準拠することに役立ちます。詳細については、「Classic Load Balancer ユーザーガイド」の「Classic Load Balancer の事前定義された SSL セキュリティポリシー」を参照してください。

注記

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

アフリカ (ケープタウン)
アジアパシフィック (大阪)
ヨーロッパ (ミラノ)
AWS GovCloud (米国東部)

修正

Classic Load Balancer で定義済みのセキュリティポリシー ELBSecurityPolicy-TLS-1-2-2017-01 を使用する方法については、「Classic Load Balancer ユーザーガイド」の「セキュリティ設定の構成」を参照してください。

[ELB.9] Classic Load Balancer では、クロスゾーンロードバランシングが有効になっている必要があります

カテゴリ: リカバリ > 耐障害性 > 高可用性

重要度: 中

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

AWS Config ルール : elb-cross-zone-load-balancing-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

predefinedPolicyName: ELBSecurityPolicy-TLS-1-2-2017-01

このコントロールは、クロスゾーンロードバランシングが Classic Load Balancer (CLB) に対して有効になっているかどうかをチェックします。クロスゾーンロードバランシングが CLB に対して有効になっていない場合、このコントロールは失敗します。

ロードバランサノードは、アベイラビリティーゾーン内の登録済みターゲット全体にのみトラフィックを分散します。クロスゾーンロードバランシングが無効の場合、各ロードバランサーノードは、そのアベイラビリティーゾーンの登録済みターゲットにのみトラフィックを分散します。登録済みターゲット数がアベイラビリティーゾーン間で同じでない場合、トラフィックは均等に分散されず、あるゾーンのインスタンスは、別のゾーンのインスタンスと比較して過剰に使用される可能性があります。クロスゾーンロードバランシングを有効にすると、Classic Load Balancer の各ロードバランサーノードは、有効なすべてのアベイラビリティーゾーンに登録済みのインスタンスにリクエストを均等に分散します。詳細については、「Elastic Load Balancing ユーザーガイド」の「クロスゾーンロードバランシング」を参照してください。

注記

このコントロールは、アフリカ (ケープタウン) および中東 (UAE) ではサポートされていません。

修正

Classic Load Balancer でクロスゾーンロードバランシングを有効にするには、「Elastic Load Balancing ユーザーガイド」の「クロスゾーンロードバランシングを有効にする」を参照してください。

[ELB.10] Classic Load Balancers は、複数のアベイラビリティーゾーンにまたがっている必要があります

カテゴリ: リカバリ > 耐障害性 > 高可用性

重要度: 中

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

AWS Config ルール : clb-multiple-az

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Classic Load Balancer が複数のアベイラビリティーゾーンにまたがるように設定されているかどうかをチェックします。Classic Load Balancer が複数のアベイラビリティーゾーンにまたがっていない場合、コントロールは失敗します。

Classic Load Balancer は、単一のアベイラビリティーゾーンまたは複数のアベイラビリティーゾーンにある Amazon EC2 インスタンスに受信リクエストを配信するように設定できます。複数のアベイラビリティーゾーンにまたがらない Classic Load Balancer は、単独で構成されたアベイラビリティーゾーンが使用できなくなった場合、別のアベイラビリティーゾーンのターゲットにトラフィックをリダイレクトすることはできません。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

Classic Load Balancer にアベイラビリティーゾーンを追加する方法については、「Classic Load Balancer ユーザーガイド」の「アベイラビリティーゾーンの追加または削除」を参照してください。

[ELB.12] Application Load Balancerは、防御モードまたは最も厳密な非同期緩和モードで構成する必要があります

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

重要度: 中

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

AWS Config ルール : alb-desync-mode-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

desyncMode: 防御、最も厳密

このコントロールは、Application Load Balancer が防御モードまたは最も厳密な非同期緩和モードに設定されているかどうかをチェックします。Application Load Balancer が防御モードまたは最も厳密な非同期緩和モードに設定されていない場合、このコントロールは失敗します。

HTTP 非同期の問題はリクエストスマグリングにつながり、アプリケーションがリクエストキューやキャッシュポイズニングに対して脆弱になる可能性があります。そしてこうした脆弱性は、認証情報スタッフィングや不正なコマンドの実行につながります。防御モードまたは最も厳密な非同期緩和モードで構成された Application Load Balancer は、HTTP 非同期に起因するセキュリティ上の問題からアプリケーションを保護します。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

Application Load Balancer の非同期緩和モードの更新方法については、「Application Load Balancer ユーザーガイド」の「Desync mitigation mode」(非同期緩和モード) を参照してください。

[ELB.13] アプリケーション、ネットワーク、Gateway Load Balancer は、複数のアベイラビリティーゾーンにまたがっている必要があります

カテゴリ: リカバリ > 耐障害性 > 高可用性

重要度: 中

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

AWS Config ルール : elbv2-multiple-az

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Elastic Load Balancer V2 (アプリケーション、ネットワーク、または Gateway Load Balancer) に複数のアベイラビリティーゾーン (AZ) のインスタンスが登録されているかどうかをチェックします。Elastic Load Balancer V2 に登録されているインスタンスのアベイラビリティゾーンが 2 つ未満の場合、このコントロールは失敗します。

Elastic Load Balancing は、受信したトラフィックを複数のアベイラビリティーゾーンの複数のターゲット (EC2 インスタンス、コンテナ、IP アドレスなど) に自動的に分散させます。Elastic Load Balancing は、受信トラフィックの時間的な変化に応じて、ロードバランサーをスケーリングします。サービスの可用性を確保するため、2 つ以上のアベイラビリティーゾーンを設定することが推奨されます。それにより、Elastic Load Balancer はアベイラビリティーゾーンを使用できなくなったときに、別のアベイラビリティーゾーンにトラフィックを転送することができます。複数のアベイラビリティーゾーンを設定しておくと、アプリケーションの単一障害点を回避できます。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

アベイラビリティーゾーンを Application Load Balancer に追加する方法については、「Application Load Balancer ユーザーガイド」の「Application Load Balancer のアベイラビリティーゾーン」参照してください。アベイラビリティーゾーンを Network Load Balancer に追加する方法については、「Network Load Balancer ユーザーガイド」の「Network Load Balancer」を参照してください。アベイラビリティーゾーンを Gateway Load Balancer に追加する方法については、「Gateway Load Balancer ユーザーガイド」の「Create a Gateway Load Balancer」(Gateway Load Balancer の作成) を参照してください。

[ELB.14] Application Load Balancer は、防御モードまたは最も厳密な非同期緩和モードで設定する必要があります

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

重要度: 中

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

AWS Config ルール : clb-desync-mode-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

desyncMode: 防御、最も厳密

このコントロールは、Classic Load Balancer が防御モードまたは最も厳密な非同期緩和モードで設定されているかどうかをチェックします。Application Load Balancer が防御モードまたは最も厳密な非同期緩和モードで設定されていない場合、このコントロールは失敗します。

HTTP 非同期の問題はリクエストスマグリングにつながり、アプリケーションがリクエストキューやキャッシュポイズニングに対して脆弱になる可能性があります。そしてこうした脆弱性は、認証情報の乗っ取りや不正なコマンドの実行につながります。防御モードまたは最も厳密な非同期緩和モードで構成された Classic Load Balancer は、HTTP 非同期に起因するセキュリティ上の問題からアプリケーションを保護します。

注記

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

中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

Classic Load Balancer の非同期緩和モードの更新方法については、「Classic Load Balancer ユーザーガイド」の「Modify desync mitigation mode」(非同期緩和モードの変更) を参照してください。

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

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

重要度: 中

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

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

スケジュールタイプ: 定期的

パラメータ : なし

このコントロールは、HTTP から HTTPS へのリダイレクトが Application Load Balancer のすべての HTTP リスナーで設定されているかどうかを確認します。Application Load Balancer の 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 のリスナー」を参照してください。

注記

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

アフリカ (ケープタウン)
ヨーロッパ (ミラノ)
中東 (アラブ首長国連邦)

修正

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

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

Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
ナビゲーションペインで、[Load Balancers] (ロードバランサー) を選択します。
Application Load Balancer を選択します。
[Listeners] (リスナー) タブを選択します。
HTTP リスナー (ポート 80 TCP) を選択し、[Edit] (編集) を選択します。
既存のルールがある場合は、それを削除する必要があります。それ以外の場合は、[Add action] (アクションの追加) を選択し、[Redirect to...] (リダイレクト先...) を選択します。
HTTPS を選択し、443 と入力します。
丸印で囲まれたチェックマークを選択し、[Update] (更新) を選択します。

[EMR.1] Amazon EMR クラスターマスターノードは、パブリック IP アドレスを設定していない必要があります

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

重要度: 高

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

AWS Config ルール : emr-master-no-public-ip

スケジュールタイプ: 定期的

パラメータ : なし

このコントロールは、Amazon EMR クラスターのマスターノードにパブリック IP アドレスが設定されているかどうかをチェックします。

マスターノードに、インスタンスのいずれかに関連付けられたパブリック IP アドレスがある場合、コントロールは失敗します。パブリック IP アドレスは、インスタンスの NetworkInterfaces 設定の PublicIp フィールドで指定されます。このコントロールは、RUNNING または WAITING 状態にある Amazon EMR クラスターのみをチェックします。

注記

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

アフリカ (ケープタウン)
ヨーロッパ (ミラノ)
中東 (アラブ首長国連邦)

修正

起動中に、デフォルトサブネットまたはデフォルト以外のサブネット内のインスタンスがパブリック IPv4 アドレスを割り当てられるかどうかをコントロールできます。

デフォルトでは、デフォルトサブネットのこの属性は true に設定されています。Amazon EC2 起動インスタンスウィザードによって作成された場合を除き、デフォルト以外のサブネットで IPv4 パブリックアドレス属性は false に設定されています。この場合、ウィザードは属性を true に設定します。

IPv4 パブリックアドレス属性が false に設定されているプライベートサブネットを持つ VPC でクラスターを起動する必要があります。

起動後に、インスタンスからパブリック IPv4 アドレスの割り当てを手動で解除することはできません。

この結果を修正するには、VPC プライベートサブネットに新しいクラスターを作成する必要があります。VPC プライベートサブネットでクラスターを起動する方法の詳細については、「Amazon EMR 管理ガイド」の「VPC 内でクラスターを起動する」を参照してください。

[ES.1] Elasticsearch ドメインは、保管中の暗号化を有効にする必要があります

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

重要度: 中

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

AWS Config ルール : elasticsearch-encrypted-at-rest

スケジュールタイプ: 定期的

パラメータ : なし

このコントロールは、Elasticsearch ドメインで保管中の暗号化設定が有効になっているかどうかをチェックします。保管中の暗号化が有効になっていない場合、チェックは失敗します。

OpenSearch 内の機密データのセキュリティを強化するには、保管中に暗号化されるように OpenSearch を設定する必要があります。Elasticsearch ドメインは、保管中のデータの暗号化を提供します。この機能では AWS KMS を使用して、暗号化キーを保存し管理します。暗号化の実行には、256 ビットキーを使用した Advanced Encryption Standard アルゴリズム (AES-256) を使用します。

保管中の OpenSearch での暗号化の詳細については、「Amazon OpenSearch Service 開発者ガイド」の「Amazon OpenSearch Service の保管中のデータの暗号化」を参照してください。

注記

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

修正

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

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

保管中のデータの暗号化には、OpenSearch Service 5.1 以降が必要です。OpenSearch Service での保管中のデータの暗号化の詳細については、「Amazon OpenSearch Service 開発者ガイド」を参照してください。

[ES.2] Elasticsearch ドメインは VPC 内に存在する必要があります

カテゴリ: 保護 > セキュアなネットワーク設定 > VPC 内のリソース

重要度: 非常事態

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

AWS Config ルール : elasticsearch-in-vpc-only

スケジュールタイプ: 定期的

パラメータ : なし

このコントロールは、Elasticsearch ドメインが VPC 内にあるかどうかをチェックします。このコントロールは、パブリックアクセスの可能性を判断するための VPC サブネットルーティング設定を評価しません。Elasticsearch ドメインがパブリックサブネットに添付済みでないことを確認する必要があります。「Amazon OpenSearch Service 開発者ガイド」の「リソースベースのポリシー」を参照してください。また、推奨されるベストプラクティスに従って VPC が確実に設定されていることを確認する必要があります。「Amazon VPC ユーザーガイド」の「VPC のセキュリティのベストプラクティス」を参照してください。

VPC 内にデプロイされた Elasticsearch ドメインは、パブリックインターネットを経由する必要なく、プライベート AWS ネットワーク経由で VPC リソースと通信できます。この設定では、転送中のデータへのアクセスを制限することにより、セキュリティ体制が向上します。VPC は、ネットワーク ACL やセキュリティグループを含む Elasticsearch ドメインへのアクセスを保護するための多数のネットワークコントロールを提供します。Security Hub では、これらのコントロールを有効に利用するために、パブリック Elasticsearch ドメインを VPC に移行することを推奨します。

修正

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

「Amazon OpenSearch Service 開発者ガイド」の「VPC 内で Amazon OpenSearch Service ドメインを起動する」を参照してください。

[ES.3] Elasticsearch ドメインは、ノード間で送信されるデータを暗号化する必要があります

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

重要度: 中

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

AWS Config ルール : elasticsearch-node-to-node-encryption-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは Elasticsearch ドメインでノード間の暗号化が有効になっているかどうかをチェックします。

HTTPS (TLS) を使用すると、潜在的な攻撃者が中間者攻撃または同様の攻撃を使用してネットワークトラフィックを盗聴または操作することを防止できます。HTTPS (TLS) 経由の暗号化された接続のみを許可する必要があります。Elasticsearch ドメインのノード間の暗号化を有効にすると、クラスター内の通信が転送中に確実に暗号化されます。

この設定には、パフォーマンス上のペナルティが発生する可能性があります。このオプションを有効にする前に、パフォーマンスのトレードオフを認識してテストする必要があります。

注記

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

アフリカ (ケープタウン)
中国 (北京)
中国 (寧夏)
ヨーロッパ (ミラノ)

修正

新規および既存のドメインでノード間の暗号化を有効にする方法については、「Amazon OpenSearch Service デベロッパーガイド」の「ノード間の暗号化を有効にする」を参照してください。

[ES.4] CloudWatch Logs への Elasticsearch ドメインエラーログ記録を有効にする必要があります

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

重要度: 中

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

AWS Config ルール : elasticsearch-logs-to-cloudwatch

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

logtype = 'error'

このコントロールは、Elasticsearch ドメインが CloudWatch Logs にエラーログを送信するように設定されているかどうかをチェックします。

Elasticsearch ドメインのエラーログを有効にし、これらのログは保持と応答のために CloudWatch Logs に送信する必要があります。ドメインのエラーログは、セキュリティとアクセス監査や、可用性の問題の診断に役立ちます。

注記

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

中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

ログ発行を有効にする方法については、「Amazon OpenSearch Service 開発者ガイド」の「ログ発行を有効にする (コンソール)」を参照してください。

[ES.5] Elasticsearch ドメインで監査ログ記録が有効になっている必要があります

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

重要度: 中

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

AWS Config ルール: elasticsearch-audit-logging-enabled (Security Hub が開発したカスタムルール)

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

cloudWatchLogsLogGroupArnList (オプション) Security Hub は、このパラメータを設定しません。監査ログ用に設定する必要がある CloudWatch Logs ロググループのカンマ区切りリスト。

Elasticsearch ドメインの CloudWatch Logs ロググループがこのパラメータリストで指定されていない場合、このルールは NON_COMPLIANT です。

このコントロールは、Elasticsearch ドメインで監査ログ記録が有効になっているかどうかをチェックします。Elasticsearch ドメインで監査ログ記録が有効になっていない場合、このコントロールは失敗します。

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

修正

監査ログを有効にする詳細な手順については、「Amazon OpenSearch Service 開発者ガイド」の「監査ログの有効化」を参照してください。

[ES.6] Elasticsearch ドメインには少なくとも 3 つのデータノードが必要です

カテゴリ: リカバリ > 耐障害性 > 高可用性

重要度: 中

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

AWS Config ルール: elasticsearch-data-node-fault-tolerance (Security Hub が開発したカスタムルール)

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Elasticsearch ドメインに少なくとも 3 つのデータノードが設定されていること、また zoneAwarenessEnabled が true かどうかをチェックします。

Elasticsearch ドメインでは、高可用性と耐障害性のために少なくとも 3 つのデータノードが必要です。少なくとも 3 つのデータノードを持つ Elasticsearch ドメインをデプロイすると、ノードに障害が発生した場合のクラスター操作が確保されます。

修正

Elasticsearch ドメインのデータノードの数を変更するには

Amazon OpenSearch Service コンソール (https://console.aws.amazon.com/aos/) を開きます。
[My domains] (ドメイン) で、編集するドメインの名前を選択します。
[Edit domain] (ドメインの編集) を選択します。
[Data nodes] (データノード) で、[Number of nodes] (ノード数) に 3 以上の数値を設定します。

3 つのアベイラビリティーゾーンのデプロイは、3 の倍数に設定してアベイラビリティーゾーン間で均等に配信されるようにします。
[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 ドメインをデプロイすると、ノードに障害が発生した場合に十分なマスターノードのリソース容量とクラスター操作が確保されます。

修正

OpenSearch ドメイン内の専用マスターノード数を変更するには

Amazon OpenSearch Service コンソール (https://console.aws.amazon.com/aos/) を開きます。
[My domains] (ドメイン) で、編集するドメインの名前を選択します。
[Edit domain] (ドメインの編集) を選択します。
[Dedicated master nodes] (専用マスターノード) で、[Instance type] (インスタンスタイプ) に目的のインスタンスタイプを設定します。
[Number of master nodes] (マスターノードの数) を 3 以上に設定します。
[Submit] (送信) を選択します。

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

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

重要度: 中

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

AWS Config ルール: elasticsearch-https-required (Security Hub が開発したカスタムルール)

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

修正

TLS 暗号化を有効にするには、UpdateDomainConfig API オペレーションを使用して、TLSSecurityPolicy を設定するために DomainEndpointOptions を設定します。詳細については、「Amazon OpenSearch Service 開発者ガイド」を参照してください。

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

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

重要度: 高

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

AWS Config ルール : guardduty-enabled-centralized

スケジュールタイプ: 定期的

パラメータ : なし

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

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

注記

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

アフリカ (ケープタウン)
中国 (北京)
中国 (寧夏)
ヨーロッパ (ミラノ)
中東 (バーレーン)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)

修正

この問題を修正するには、GuardDuty を有効にします。

GuardDuty を有効にする方法 (AWS Organizations を使用して複数のアカウントを管理する方法を含む) の詳細については、「Amazon GuardDuty ユーザーガイド」の「GuardDuty の開始方法」を参照してください。

[IAM.1] IAM ポリシーでは、完全な「*」管理者権限を許可しないでください

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

重要度: 高

リソースタイプ : AWS::IAM::Policy

AWS Config ルール : iam-policy-no-statements-with-admin-access

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

excludePermissionBoundaryPolicy: true

このコントロールは、IAM ポリシー (カスタマー管理ポリシーとも呼ばれます) のデフォルトバージョンに、"Action": "*" が "Resource": "*" に対して規定された "Effect": "Allow" ステートメントを持つ管理者アクセス権があるかどうかをチェックします。このようなステートメントを含む IAM ポリシーがある場合、コントロールは失敗します。

コントロールは、作成したカスタマーマネージドポリシーのみをチェックします。インラインおよび AWS マネージドポリシーはチェックされません。

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

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

"Effect": "Allow" および "Action": "*" が "Resource": "*" に対して規定されたステートメントを持つ IAM ポリシーは削除する必要があります。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

AWS Config は、Security Hub を使用するすべてのリージョンで有効にする必要があります。ただし、グローバルリソースの記録は 1 つのリージョンで有効にすることができます。グローバルリソースを 1 つのリージョンにのみ記録する場合は、グローバルリソースを記録するリージョン以外のすべてのリージョンでこのコントロールを無効にすることができます。

修正

IAM ポリシーを変更して、完全な「*」管理者権限を許可しないようにする方法については、「IAM ユーザーガイド」の「IAM ポリシーの編集」を参照してください。

[IAM.2] IAM ユーザーには IAM ポリシーを添付しないでください

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

重要度: 低

リソースタイプ : AWS::IAM::User

AWS Config ルール : iam-user-no-policies-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、いずれの IAM ユーザーにもポリシーが添付済みでないことをチェックします。代わりに、IAM ユーザーは、IAM グループまたはロールから許可を継承する必要があります。

デフォルトでは、IAM ユーザー、グループ、ロールには AWS リソースへのアクセス権はありません。IAM ポリシーで、ユーザー、グループ、またはロールに権限を付与します。IAM ポリシーはグループとロールには直接適用しますが、ユーザーには直接適用しないことを推奨します。グループレベルまたはロールレベルで権限を割り当てると、ユーザー数が増えるにつれてアクセス管理の複雑さが軽減されます。アクセス管理の複雑さを軽減することで、プリンシパルが誤って過剰な権限を受け取ったり保持する機会を減らすことができます。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

Amazon Simple Email Service が作成した IAM ユーザーは、インラインポリシーを使用して自動作成されます。Security Hub は、これらのユーザーをこのコントロールから自動的に除外します。

修正

この問題を解決するには、IAM グループを作成し、ポリシーをこのグループにアタッチします。続いて、ユーザーをこのグループに追加します。ポリシーは、グループ内の各ユーザーに適用されます。ユーザーに直接添付されているポリシーを削除するには、IAM ユーザーガイドの「IAM ID のアクセス許可の追加および削除」を参照してください。

[IAM.3] IAM ユーザーのアクセスキーは 90 日以内にローテーションする必要があります

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

重要度: 中

リソースタイプ : AWS::IAM::User

AWS Config ルール : access-keys-rotated

スケジュールタイプ: 定期的

パラメータ:

maxAccessKeyAge: 90

このコントロールは、アクティブなアクセスキーが 90 日以内にローテーションされているかどうかをチェックします。

アカウントのすべてのアクセスキーを生成したり削除したりしないことを強く推奨します。代わりにベストプラクティスとして、1 つ以上の IAM ロールを作成するか、AWS IAM Identity Center (successor to AWS Single Sign-On) によるフェデレーションを使用することを推奨します。これらのメソッドを使用して、ユーザーが AWS Management Console および AWS CLI にアクセスできるようにすることができます。

各アプローチにはそれぞれのユースケースがあります。フェデレーションは、既存の中央ディレクトリを保有する企業や、現在の制限 IAM ユーザーよりも多くを必要とする予定の企業にとって一般的に適しています。AWS 環境の外部で実行されるアプリケーションには、AWS リソースへのプログラムによるアクセスキーが必要です。

ただし、プログラムによるアクセスを必要とするリソースが AWS 内部で実行される場合、IAM ロールの使用がベストプラクティスとなります。ロールを使用すると、アクセスキー ID とシークレットアクセスキーを設定にハードコーディングすることなく、リソースへのアクセスを許可できます。

アクセスキーとアカウントの保護の詳細については、「AWS 全般のリファレンス」の「AWS アクセスキーを管理するためのベストプラクティス」を参照してください。また、ブログ記事「プログラムからのアクセス利用時に AWS アカウントを保護するためのガイドライン」も参照してください。

アクセスキーが既に存在する場合、Security Hub では 90 日ごとにアクセスキーをローテーションすることを推奨します。アクセスキーをローテーションすることにより、侵害されたアカウントや終了したアカウントに関連付けられているアクセスキーが使用される可能性が低くなります。また、紛失した、クラックされた、盗まれた古いキーでデータにアクセスできないようにします。アクセスキーをローテーションしたら、必ずアプリケーションを更新してください。

アクセスキーは、アクセスキー ID とシークレットアクセスキーで構成されます。これは AWS へのプログラムによるリクエストの署名に使用されます。AWS CLI、Tools for Windows PowerShell、AWS SDK から AWS をプログラムで呼び出したり、個々の AWS のサービスの API 操作を使用して直接 HTTP 呼び出しを行うには、ユーザー自身のアクセスキーが必要です。

組織で AWS IAM Identity Center (successor to AWS Single Sign-On) (IAM Identity Center) を使用している場合、ユーザーは Active Directory、組み込み IAM Identity Center ディレクトリ、または IAM Identity Center に接続された別の ID プロバイダー (IdP) にサインインできます。次に、アクセスキーを必要とせずに、AWS CLI コマンドを実行したり、AWS API オペレーションを呼び出しす IAM ロールにマッピングされます。詳細については、「AWS Command Line Interface ユーザーガイド」の「AWS CLI を設定して AWS IAM Identity Center (successor to AWS Single Sign-On) を使用する」を参照してください。

注記

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

アフリカ (ケープタウン)
ヨーロッパ (ミラノ)
中東 (アラブ首長国連邦)

修正

この問題を修正するには、90 日より古いキーをすべて置き換えます。

アクセスキーが 90 日間を越えて使用されないようにするには

IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
[Users] (ユーザー) を選択します。
[Access key age] (アクセスキーの古さ) が 90 日を超えている各ユーザーに対して、[User name] (ユーザー名) を選択してそのユーザーの設定を開きます。
[Security credentials] (セキュリティ認証情報) を選択します。
ユーザーの新しいキーを作成するには:
1. [Create access key] (アクセスキーの作成) を選択します。
2. キーの内容を保存するには、シークレットアクセスキーをダウンロードするか、[Show] (表示) を選択した後でページからコピーします。
3. ユーザーに提供するための安全な場所にキーを保存します。
4. [Close] (閉じる) を選択します。
以前のキーを使用していたすべてのアプリケーションを更新し、新しいキーを使用するようにします。
以前のキーで、[Make inactive] (非アクティブにする) を選択してアクセスキーを非アクティブにします。これで、ユーザーは以前のキーを使用してリクエストを行うことができなくなります。
すべてのアプリケーションが新しいキーで想定どおりに機能することを確認します。
すべてのアプリケーションが新しいキーで想定どおりに機能することを確認したら、以前のキーを削除します。アクセスキーは削除した後に復元することはできません。

以前のキーを削除するには、行の末尾にある X を選択し、[Delete] (削除) を選択します。

[IAM.4] IAM ルートユーザーアクセスキーが存在してはいけません

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

重要度: 非常事態

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

AWS Config ルール : iam-root-access-key-check

スケジュールタイプ: 定期的

パラメータ : なし

このコントロールは、ルートユーザーアクセスキーが存在するかどうかをチェックします。

ルートユーザーは、最も権限のある AWS アカウントです。AWS アクセスキーは、指定されたアカウントにプログラムからアクセスすることを可能にします。

Security Hub では、ルートユーザーに関連付けられたすべてのアクセスキーの削除を推奨します。これにより、お使いのアカウントの侵害に使用できるベクトルが制限されます。また、最小特権のロールベースのアカウントの作成と使用が促進されます。

注記

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

アジアパシフィック (ジャカルタ)
アジアパシフィック (大阪)
中東 (アラブ首長国連邦)

修正

ルートユーザーアクセスキーを削除するには、「IAM ユーザーガイドの「ルートユーザーのアクセスキーの削除」を参照してください。

[IAM.5] コンソールパスワードを使用するすべての IAM ユーザーに対して MFA を有効にする必要があります

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

重要度: 中

リソースタイプ : AWS::IAM::User

AWS Config ルール : mfa-enabled-for-iam-console-access

スケジュールタイプ: 定期的

パラメータ : なし

このコントロールは、コンソールパスワードを使用するすべての IAM ユーザーについて AWS 多要素認証 (MFA) が有効になっているかどうかをチェックします。

多要素認証 (MFA) は、ユーザー名とパスワードに更なる保護手段を追加します。MFA が有効な場合、ユーザーが AWS ウェブサイトにサインインすると、ユーザー名とパスワードの入力を求められます。さらに、AWS MFA デバイスからの認証コードの入力が求められます。

コンソールパスワードを使用するすべてのアカウントにおいて、MFA を有効にすることを推奨します。MFA は、コンソールアクセスのセキュリティを強化するために設計されています。認証プリンシパルは、時間的制約のあるキーを発行するデバイスを所有し、認証情報に関する知識がある必要があります。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

IAM ユーザーを MFA に追加するには、IAM ユーザーガイドの「AWS での多要素認証 (MFA) の使用」を参照してください。

対象となるお客様には、MFA セキュリティキーを無料で提供しています。資格があるかどうかを確認し、無料のキーを注文します。

[IAM.6] ルートユーザーに対してハードウェア MFA を有効にする必要があります

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

重要度: 非常事態

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

AWS Config ルール : root-account-hardware-mfa-enabled

スケジュールタイプ: 定期的

パラメータ : なし

このコントロールは、AWS アカウントで、ルートユーザー認証情報を使用してサインインする際に、ハードウェア多要素認証 (MFA) デバイスの使用が有効になっているかどうかをチェックします。

仮想 MFA はハードウェア MFA デバイスと同じレベルのセキュリティを提供しない可能性があります。ハードウェアの購入承認の待機中、またはハードウェアの到着を待つ間にのみ、仮想 MFA デバイスの使用を推奨します。詳細については、「IAM ユーザーガイド」の「仮想多要素認証 (MFA) デバイスの有効化 (コンソール)」を参照してください。

タイムベースドワンタイムパスワード (TOTP) トークンと、ユニバーサルセカンドファクター (U2F) トークンの両方が、ハードウェア MFA オプションとして実行可能です。

注記

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

中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)。

修正

ルートユーザー用にハードウェア MFA デバイスを追加するには、IAM ユーザーガイドの「AWS アカウントルートユーザー用にハードウェア MFA デバイスを有効にする (コンソール)」を参照してください。

対象となるお客様には、MFA セキュリティキーを無料で提供しています。資格があるかどうかを確認し、無料のキーを注文します。

[IAM.7] IAM ユーザーのパスワードポリシーには強力な設定が必要です

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

重要度: 中

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

AWS Config ルール : iam-password-policy

スケジュールタイプ: 定期的

パラメータ:

RequireUppercaseCharacters: true
RequireLowercaseCharacters: true
RequireSymbols: true
RequireNumbers: true
MinimumPasswordLength: 8

このコントロールは、IAM ユーザーのアカウントパスワードポリシーが推奨設定を使用しているかどうかをチェックします。

IAM ユーザーが AWS Management Console にアクセスするには、パスワードが必要です。ベストプラクティスとして、Security Hub では IAM ユーザーを作成する代わりに、フェデレーションの使用を強く推奨します。フェデレーションでは、ユーザーは既存の企業認証情報を使用して、AWS Management Console にログインできます。AWS IAM Identity Center (successor to AWS Single Sign-On) (IAM Identity Center)を使用してユーザーを作成またはフェデレートし、IAM ロールをアカウントに引継ぎます。

アイデンティティプロバイダーとフェデレーションの詳細については、「IAM ユーザーガイド」の「アイデンティティプロバイダーとフェデレーション」を参照してください。IAM Identity Center の詳細については、AWS IAM Identity Center (successor to AWS Single Sign-On) ユーザーガイドを参照してください。

IAM ユーザーを使用する必要がある場合は、Security Hub では、強力なユーザーパスワードの作成を強制することを推奨します。AWS アカウントにパスワードポリシーを設定し、パスワードの複雑さの要件と必須のローテーション期間を指定することができます。パスワードポリシーを作成または変更する場合、パスワードポリシーの設定の多くは、ユーザーが次回パスワードを変更するときに適用されます。ただし、一部の設定は即座に適用されます。

修正

推奨される設定を使用するようにパスワードポリシーを更新するには、「IAM ユーザーガイドの「IAM ユーザー用のアカウントパスワードポリシーの設定」を参照してください。

[IAM.8] 未使用の IAM ユーザー認証情報は削除する必要があります

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

重要度: 中

リソースタイプ : AWS::IAM::User

AWS Config ルール : iam-user-unused-credentials-check

スケジュールタイプ: 定期的

パラメータ:

maxCredentialUsageAge: 90

このコントロールは、IAM ユーザーが 90 日間使用されていないパスワードまたはアクティブなアクセスキーを持っているかどうかをチェックします。

IAM ユーザーは、パスワードやアクセスキーなどのさまざまなタイプの認証情報を使用して AWS リソースにアクセスできます。

Security Hub では、90 日以上使用されていないすべての認証情報を削除または非アクティブ化することを推奨します。不要な認証情報を無効化または削除することにより、侵害または放棄されたアカウントに関連付けられている認証情報が使用される可能性が少なくなります。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

認証情報が期限切れのアカウントをモニタリングするために必要な一部の情報を取得するには、IAM コンソールを使用します。例えば、お使いのアカウントのユーザーを表示すると、[Access key age] (アクセスキーの古さ)、[Password age] (パスワードの古さ)、および [Last activity] (最終アクティビティ) の列が表示されます。これらの列の値のいずれかが 90 日より大きい場合は、それらのユーザーの認証情報を非アクティブにします。

認証情報レポートを使用してユーザーアカウントをモニタリングし、90 日以上アクティビティのないアカウントを特定することもできます。IAM コンソールから認証情報レポートを .csv 形式でダウンロードできます。認証情報レポートの詳細については、「IAM ユーザーガイド」の「AWS アカウントの認証情報レポートの取得」を参照してください。

非アクティブなアカウントや使用されていない認証情報を特定したら、次のステップを使用してそれらを無効にします。

非アクティブなアカウントの認証情報を無効にするには

IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
[Users] (ユーザー) を選択します。
90 日を超えた認証情報を持つユーザーの名前を選択します。
[Security credentials] (セキュリティ認証情報) を選択します。
90 日以上使用されていないサインイン認証情報とアクセスキーごとに、[Make inactive] (非アクティブにする) を選択します。

[IAM.21] 作成する IAM カスタマーマネージドポリシーにはサービスのワイルドカードアクションを許可してはいけません

カテゴリ: 検出 > セキュアなアクセス管理

重要度: 低

リソースタイプ : AWS::IAM::Policy

AWS Config ルール : iam-policy-no-statements-with-full-access

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

excludePermissionBoundaryPolicy: True

このコントロールは、作成した IAM アイデンティティベースのポリシーに、ワイルドカード (*) を使用して、任意のサービスに対してすべてのアクションに許可を付与する許可ステートメントがあるかどうかをチェックします。ポリシーステートメントに、"Effect": "Allow" と "Action": "Service:*" が含まれている場合、コントロールは失敗します。

例えば、ポリシーに次のような記述があると、結果は失敗となります。


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

"Effect": "Allow" と "NotAction": "service:*" を使用する場合も、コントロールは失敗します。この場合、NotAction 要素は、NotAction で指定したアクションを除く AWS のサービスのすべてのアクションへのアクセスを許可します。

このコントロールは、カスタマー管理 IAM ポリシーにのみ適用されます。AWS によって管理される IAM ポリシーには適用されません。

AWS のサービスサービスにアクセス許可を割り当てるときには、許可される IAM アクションの範囲を IAM ポリシーで指定することが重要です。IAM アクションは、必要なアクションのみに制限する必要があります。これは、最小特権の許可のプロビジョンに役立ちます。ポリシーが許可を必要としない IAM プリンシパルに添付済みの場合、過度に許可されたポリシーは特権エスカレーションにつながる可能性があります。

場合によっては、DescribeFlowLogs や DescribeAvailabilityZones のような類似のプレフィックスを持つ IAM アクションを許可する必要があります。これらの承認済みのケースでは、共通プレフィクスにサフィックス付きワイルドカードを追加することができます。例えば、ec2:Describe* です。

プレフィクスが付いた IAM アクションとサフィックス付きワイルドカードを使用する場合、このコントロールは成功します。例えば、ポリシー内の次のステートメントでは、結果が成功になります。


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

この方法で関連する IAM アクションをグループ化することで、IAM ポリシーのサイズ制限を超えないようにすることもできます。

注記

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

アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

この問題を修正するには、IAM ポリシーを更新して、完全な「*」管理者権限を許可しないようにします。IAM ポリシーを編集する方法の詳細は、「IAM ユーザーガイド」の「IAM ポリシーの編集」を参照してください。

[Kinesis.1] Kinesis Data Streams は、保管中に暗号化する必要があります

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

重要度: 中

リソースタイプ : AWS::Kinesis::Stream

AWS Config ルール : kinesis-stream-encrypted

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon Kinesis Streams が保管中にサーバー側の暗号化を使用して暗号化されているかどうかをチェックします。Amazon Kinesis Streams が、保管中にサーバー側の暗号化を使用して暗号化されていない場合、このコントロールは失敗します。

サーバー側の暗号化は、AWS KMS keyを使用してデータを保管中になる前に自動的に暗号化する、Amazon Kinesis Data Streams の機能です。データは、Kinesis ストリームストレージレイヤーに書き込まれる前に暗号化され、ストレージから取得された後で復号されます。これにより、Amazon Kinesis Data Streams サービス内に保管中のデータは暗号化されます。

注記

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

中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

Kinesis Streams でサーバー側の暗号化を有効にする方法については、「Amazon Kinesis Data Streams デベロッパーガイド」の「How Do I Get Started with Server-Side Encryption?」(サーバー側の暗号化を使用する) を参照してください。

[KMS.1] IAM カスタマーマネージドポリシーでは、すべての KMS キーの復号化と再暗号化アクションを許可してはいけません

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

重要度: 中

リソースタイプ : AWS::IAM::Policy

AWS Config ルール : iam-customer-policy-blocked-kms-actions

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

blockedActionsPatterns: kms:ReEncryptFrom, kms:Decrypt
excludePermissionBoundaryPolicy: True

IAM カスタマーマネージドポリシーのデフォルトバージョンで、プリンシパルにすべてのリソースに対する AWS KMS 復号化アクションの使用を許可しているかどうかをチェックします。このコントロールは、自動推論エンジンである「Zelkova」を使用して、AWS アカウントの機密情報への幅広いアクセスを許可する可能性のあるポリシーを検証し警告します。

ポリシーが任意の KMS キーに kms:Decrypt またはkms:ReEncryptFrom アクションを許可できるほどオープンな場合、このコントロールは失敗し、ポリシーを FAILED とフラグ付けします。

コントロールはリソース要素の KMS キーのみをチェックし、ポリシーの Condition 要素の条件は考慮しません。このコントロールは、添付済みのカスタマーマネージドポリシーと添付されていないカスタマーマネージドポリシーの両方を評価します。インラインポリシーまたは AWS マネージドポリシーのチェックは行いません。

AWS KMS を使用すると、KMS キーを使用して、暗号化済みのデータにアクセスできるユーザーをコントロールできます。IAM ポリシーは、アイデンティティ (ユーザー、グループ、またはロール) がどのリソースに対してどのアクションを実行できるかを定義します。セキュリティのベストプラクティスに従い、AWS は、最小特権を許可することを推奨します。つまり、ID に付与するのは kms:Decrypt または kms:ReEncryptFrom 許可と、タスクの実行に必要なキーのみにする必要があります。そうでない場合、ユーザーはデータに適さないキーを使用する可能性があります。

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

注記

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

アジアパシフィック (ジャカルタ)
アジアパシフィック (大阪)
中東 (アラブ首長国連邦)

修正

この問題を修正するには、IAM カスタマーマネージドポリシーを変更して、キーへのアクセスを制限します。

IAM カスタマーマネージドポリシーを変更するには

IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
左の IAM ナビゲーションペインの [Policies] (ポリシー) を選択します。
変更するポリシーの横にある矢印を選択します。
[Edit policy] (ポリシーの編集) を選択します。
[JSON] タブを選択します。
許可する特定のキー、または複数のキーの “Resource” 値を変更します。
ポリシーを変更したら、[Review policy] (ポリシーの確認) を選択します。
[Save changes] (変更の保存) を選択します。

詳細については、「AWS Key Management Service 開発者ガイド」の「AWS KMS で IAM ポリシーを使用する」を参照してください。

[KMS.2] IAM プリンシパルは、すべての KMS キーで復号化および再暗号化アクションを許可する IAM インラインポリシーを使用するべきではありません

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

重要度: 中

リソースタイプ :

AWS::IAM::Role
AWS::IAM::User
AWS::IAM::Group

AWS Config ルール : iam-inline-policy-blocked-kms-actions

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

blockedActionsPatterns: kms:ReEncryptFrom, kms:Decrypt

IAM アイデンティティ (ロール、ユーザー、またはグループ) に埋め込まれたインラインポリシーですべての KMS キーに対する AWS KMS 復号と再暗号化アクションが許可されているかどうかをチェックします。このコントロールは、自動推論エンジンである「Zelkova」を使用して、AWS アカウントの機密情報への幅広いアクセスを許可する可能性のあるポリシーを検証し警告します。ポリシーが任意の KMS キーに対して kms:Decrypt またはkms:ReEncryptFrom のアクションを許可するのに十分にオープンな場合、このコントロールは失敗します。

コントロールはリソース要素の KMS キーのみをチェックし、ポリシーの Condition 要素の条件は考慮しません。

AWS KMS を使用すると、KMS キーを使用して、暗号化済みのデータにアクセスできるユーザーをコントロールできます。IAM ポリシーは、アイデンティティ (ユーザー、グループ、またはロール) がどのリソースに対してどのアクションを実行できるかを定義します。セキュリティのベストプラクティスに従い、AWS は、最小特権を許可することを推奨します。つまり、ID には必要な許可のみを、タスクの実行に必要なキーにのみ付与する必要があります。そうでない場合、ユーザーはデータに適さないキーを使用する可能性があります。

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

注記

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

アジアパシフィック (ジャカルタ)
アジアパシフィック (大阪)
中東 (アラブ首長国連邦)

修正

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

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

IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
IAM ナビゲーションペインで、[Users] (ユーザー)、[Groups] (グループ)、または [Roles] (ロール) を選択します。
IAM インラインポリシーを変更するユーザー、グループ、またはロールの名前を選択します。
変更するポリシーの横にある矢印を選択します。
[Edit policy] (ポリシーの編集) を選択します。
[JSON] タブを選択します。
許可する特定キーの "Resource" 値を変更します。
ポリシーを変更したら、[Review policy] (ポリシーの確認) を選択します。
[Save changes] (変更の保存) を選択します。

詳細については、「AWS Key Management Service 開発者ガイド」の「AWS KMS で IAM ポリシーを使用する」を参照してください。

[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 キーの削除の詳細については、「AWS Key Management Service 開発者ガイド」の「KMS キーの削除」を参照してください。

注記

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

修正

スケジュール済み 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 関数は、関数に格納されているユーザーのコードへの意図しないアクセスを許可する可能性があるため、パブリックからアクセスできない必要があります。

注記

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

修正

Lambda 関数がこのコントロールに失敗した場合、Lambda 関数のリソースベースのポリシーステートメントがパブリックアクセスを許可していることを示します。

この問題を修正するには、ポリシーを更新して許可を削除するか、AWS:SourceAccount 条件を追加します。Lambda API からのみリソースベースのポリシーを更新できます。

次の手順では、コンソールを使用してポリシーと AWS Command Line Interface を確認し、許可を削除します。

Lambda 関数のリソースベースのポリシーを表示するには

AWS Lambda コンソールを (https://console.aws.amazon.com/lambda/) 開きます。
ナビゲーションペインで、[Functions] (関数) を選択します。
関数を選択します。
[Permissions] (許可) を選択します。リソースベースのポリシーは、別のアカウントまたは AWS のサービスがその機能にアクセスしようとしたときに適用される許可を表示します。
リソースベースのポリシーを調査します。ポリシーをパブリックにする Principal フィールド値を持つポリシーステートメントを特定します。例えば、"*" または { "AWS": "*" } を許可しています。

ポリシーはコンソールから編集できません。関数から許可を削除するには、AWS CLI から remove-permission コマンドを使用します。

削除するステートメントのステートメント 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 に置き換えます。

許可が更新されていることを確認するには

AWS Lambda コンソールを (https://console.aws.amazon.com/lambda/) 開きます。
ナビゲーションペインで、[Functions] (関数) を選択します。
更新した関数を選択します。
[Permissions] (許可) を選択します。

リソースベースのポリシーを更新する必要があります。ポリシーにステートメントが 1 つしかない場合、ポリシーは空です。

詳細については、「AWS Lambda 開発者ガイド」の「AWS Lambda のリソースベースのポリシーを使用する」を参照してください。

[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります

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

重要度: 中

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

AWS Config ルール : lambda-function-settings-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

runtime: nodejs18.x, nodejs16.x, nodejs14.x, nodejs12.x, python3.9, python3.8, python3.7, ruby2.7, java11, java8, java8.al2, go1.x, dotnetcore3.1, dotnet6

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

AWS Config ルールは、パッケージタイプが Image の関数を無視します。

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

サポートされている言語について、このコントロールがチェックするサポートされるランタイムの詳細については、「AWS Lambda 開発者ガイド」の「AWS Lambda ランタイム」を参照してください。

注記

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

修正

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

[Lambda.5] VPC Lambda 関数は複数のアベイラビリティーゾーンで運用する必要があります

カテゴリ: リカバリ > 耐障害性 > 高可用性

重要度: 中

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

AWS Config ルール : lambda-vpc-multi-az-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Lambda に 1 つ以上のアベイラビリティーゾーンが関連付けられているかどうかをチェックします。Lambda に関連付けられているアベイラビリティーゾーンが 1 つだけの場合、ルールは失敗します。

複数のアベイラビリティーゾーンにリソースをデプロイするには、アーキテクチャ内で高可用性を確保するための AWS のベストプラクティスです。可用性は、機密性、完全性、可用性から成り立つセキュリティモデルの 3 要素における中心的な柱です。すべての Lambda 関数には、1 つのゾーンで障害が発生しても運用が完全に中断されないように、複数のアベイラビリティーゾーンをデプロイする必要があります。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

コンソールを使用して複数のアベイラビリティーゾーンに Lambda 関数をデプロイするには:

AWS Lambda コンソールを (https://console.aws.amazon.com/lambda/) 開きます。
Lambda コンソールの [Functions] (関数) ページから関数を選択します。
[Configuration] (設定)、VPC の順に選択します。
[Edit] (編集) を選択します。
関数がもともと VPC に接続されていなかった場合は、ドロップダウンメニューから VPC を選択します。機能がもともと VPC に接続されていなかった場合は、その機能に添付するセキュリティグループを少なくとも 1 つ選択してください。

注記
関数実行ロールには、EC2 で CreateNetworkInterface を呼び出すための許可が必要です。
[Save] (保存) を選択します。

[Network Firewall.3] Network Firewall ポリシーには、1 つ以上のルールグループが関連付けられている必要があります

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

重要度: 中

リソースタイプ : AWS::NetworkFirewall::FirewallPolicy

AWS Config ルール : netfw-policy-rule-group-associated

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Network Firewall ポリシーに、ステートフルなルールグループかステートレスなルールグループのいずれかが関連付けられているかどうかをチェックします。ステートレスまたはステートフルなルールグループが割り当てられていない場合、このコントロールは失敗します。

ファイアウォールポリシーは、ファイアウォールが Amazon Virtual Private Cloud (Amazon VPC) のトラフィックをモニタリングおよび処理する方法を定義します。ステートレスおよびステートフルのルールグループの設定は、パケットとトラフィックフローのフィルタリングに役立ち、デフォルトのトラフィック処理を定義します。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

Network Firewall ポリシーにルールグループを追加する方法については、「AWS Network Firewall デベロッパーガイド」の「Updating a firewall policy」(ファイアウォールポリシーの更新) を参照してください。ルールグループの作成および管理方法については、「AWS Network Firewall のルールグループ」を参照してください。

[NetworkFirewall.4] Network Firewall ポリシーのデフォルトのステートレスアクションは、完全なパケットに対してドロップまたは転送される必要があります。

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

重要度: 中

リソースタイプ : AWS::NetworkFirewall::FirewallPolicy

AWS Config ルール : netfw-policy-default-action-full-packets

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

statelessDefaultActions: aws:drop,aws:forward_to_sfe

このコントロールは、Network Firewall ポリシーの完全なパケットに対するデフォルトのステートレスアクションが、ドロップまたは転送かどうかをチェックします。Drop または Forward が選択されている場合、コントロールはパスします。Pass が選択されている場合、このコントロールは失敗します。

ファイアウォールポリシーは、ファイアウォールが Amazon VPC のトラフィックをモニタリングおよび処理する方法を定義します。ステートレスおよびステートフルのルールグループを設定し、パケットとトラフィックフローをフィルタリングします。Pass をデフォルトに設定すると、意図しないトラフィックが許可される可能性があります。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

ファイアウォールポリシーを変更するには

Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。
ナビゲーションペインの [Network Firewall] (ネットワークファイアウォール) で [Firewall policies] (ファイアウォールポリシー) を選択します。
編集したいファイアウォールポリシーの名前を選択します。これにより、ファイアウォールのポリシーの詳細ページが表示されます。
[Stateless Default Actions] (ステートレスデフォルトアクション) で、[Edit] (編集) を選択します。続いて、[Default actions for full packets] (完全なパケットのデフォルトアクション) として、[Drop] (ドロップ) または [Forward to stateful rule groups] (ステートフルルールグループに転送) を選択します。

[NetworkFirewall.5] Network Firewall ポリシーのデフォルトのステートレスアクションは、断片化されたパケットに対してドロップまたは転送される必要があります。

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

重要度: 中

リソースタイプ : AWS::NetworkFirewall::FirewallPolicy

AWS Config ルール : netfw-policy-default-action-fragment-packets

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

statelessFragDefaultActions (Required) : aws:drop, aws:forward_to_sfe

このコントロールは、Network Firewall ポリシーの断片化されたパケットに対するデフォルトのステートレスアクションが、ドロップまたは転送かどうかをチェックします。Drop または Forward が選択されている場合、コントロールはパスします。Pass が選択されている場合、このコントロールは失敗します。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

ファイアウォールポリシーを変更するには

Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。
ナビゲーションペインの [Network Firewall] (ネットワークファイアウォール) で [Firewall policies] (ファイアウォールポリシー) を選択します。
編集したいファイアウォールポリシーの名前を選択します。これにより、ファイアウォールのポリシーの詳細ページが表示されます。
[Stateless Default Actions] (ステートレスデフォルトアクション) で、[Edit] (編集) を選択します。続いて、[Default actions for full packets] (断片化されたパケットのデフォルトアクション) として、[Drop] (ドロップ) または [Forward to stateful rule groups] (ステートフルルールグループに転送) を選択します。

[NetworkFireWall.6] ステートレスネットワークファイアウォールのルールグループを空にしないでください

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

重要度: 中

リソースタイプ : AWS::NetworkFirewall::RuleGroup

AWS Config ルール : netfw-stateless-rule-group-not-empty

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、AWS Network Firewall のステートレスルールグループにルールが含まれているかどうかをチェックします。ルールグループにルールが含まれない場合、ルールは失敗します。

ルールグループには、ファイアウォールが VPC 内のトラフィックを処理する方法を定義するルールが含まれています。ファイアウォールポリシーに空のステートレスルールグループが存在する場合、ルールグループがトラフィックを処理するという印象を与える可能性があります。しかし、ステートレスルールグループが空の場合、トラフィックを処理しません。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

ルールをネットワークファイアウォールルールグループに追加するには

AWS 管理コンソールにサインインして Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。
ナビゲーションペインで、[Network Firewall] (ネットワークファイアウォール) で、[Network Firewall rule groups] (ネットワークファイアウォールルールグループ) を選択します。
[Network Firewall rule groups] (ネットワークファイアウォールルールグループ) ページで、編集するルールグループの名前を選択します。これにより、ファイアウォールルールグループの詳細ページが表示されます。
ステートレスルールグループでは、[Edit Rules] (ルールの編集) 選択して、ルールグループにルールを追加します。

[OpenSearch.1] OpenSearch ドメインは保管中の暗号化を有効にする必要があります

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

重要度: 中

リソースタイプ : AWS::OpenSearch::Domain

AWS Config ルール : opensearch-encrypted-at-rest

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、OpenSearch ドメインで保管中の暗号化設定が有効になっているかどうかをチェックします。保管中の暗号化が有効になっていない場合、チェックは失敗します。

機密データのセキュリティを強化するには、保管中に暗号化するように OpenSearch Service ドメインを設定する必要があります。保管中のデータの暗号化の構成では、AWS KMS は暗号化キーを保存および管理します。暗号化を実行するために、AWS KMS は 256 ビットキーを使用した Advanced Encryption Standard アルゴリズム (AES-256) を使用します。

保管中の OpenSearch での暗号化の詳細については、Amazon OpenSearch Service デベロッパーガイド」の「Amazon OpenSearch Service の保管中のデータの暗号化」を参照してください。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

デフォルトでは、ドメインの保管中のデータは暗号化されず、既存のドメインでこの機能の使用は設定できません。この機能を有効にするには、別のドメインを作成してデータを移行する必要があります。

ドメインの作成の詳細については、「Amazon OpenSearch Service 開発者ガイド」の「Amazon OpenSearch Service ドメインの作成と管理」を参照してください。

保管中のデータの暗号化には、Amazon OpenSearch 1.0 以降が必要です。OpenSearch での保管中のデータの暗号化の詳細については、Amazon OpenSearch Service デベロッパーガイドの「Amazon OpenSearch Service の保管中のデータの暗号化」を参照してください。

[OpenSearch.2] OpenSearch ドメインは VPC 内に含まれている必要があります

カテゴリ: 保護 > セキュアなネットワーク設定 > VPC 内のリソース

重要度: 非常事態

リソースタイプ : AWS::OpenSearch::Domain

AWS Config ルール : opensearch-in-vpc-only

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、OpenSearch ドメインが VPC 内にあるかどうかをチェックします。このコントロールは、パブリックアクセスの可能性を判断するための VPC サブネットルーティング設定を評価しません。

OpenSearch ドメインがパブリックサブネットに添付済みではないことを確認する必要があります。「Amazon OpenSearch Service 開発者ガイド」の「リソースベースのポリシー」を参照してください。また、推奨されるベストプラクティスに従って VPC が確実に設定されていることを確認する必要があります。「Amazon VPC ユーザーガイド」の「VPC のセキュリティのベストプラクティス」を参照してください。

VPC 内にデプロイされた OpenSearch ドメインは、プライベート AWS ネットワーク経由で VPC リソースと通信できます。パブリックインターネットを経由する必要はありません。この設定では、転送中のデータへのアクセスを制限することにより、セキュリティ体制が向上します。VPC は、ネットワーク ACL やセキュリティグループを含む、OpenSearch ドメインへのアクセスを安全にするため、多数のネットワークコントロールを提供します。Security Hub では、これらのコントロールを有効に利用するために、パブリック OpenSearch ドメインを VPC に移行することを推奨します。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

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

代わりに、別のドメインを作成するか、このコントロールを無効にする必要があります。

「Amazon OpenSearch Service 開発者ガイド」の「VPC 内で Amazon OpenSearch Service ドメインを起動する」を参照してください。

[OpenSearch.3] OpenSearch ドメインはノード間で送信されるデータを暗号化する必要があります

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

重要度: 中

リソースタイプ : AWS::OpenSearch::Domain

AWS Config ルール : opensearch-node-to-node-encryption-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、OpenSearch ドメインでノード間の暗号化が有効になっているかどうかをチェックします。ドメインでノード間の暗号化が無効になっている場合、このコントロールは失敗します。

HTTPS (TLS) を使用すると、潜在的な攻撃者が中間者攻撃または同様の攻撃を使用してネットワークトラフィックを盗聴または操作することを防止できます。HTTPS (TLS) 経由の暗号化された接続のみを許可する必要があります。OpenSearch ドメインでノード間の暗号化を有効にすると、クラスター内通信は転送中に確実に暗号化されます。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

ノード間の暗号化は、新しいドメインでのみ有効にすることができます。この結果を修正するには、[Node-to-node encryption] (ノード間の暗号化) を有効にして新しいドメインを作成し、データを新しいドメインに移行します。「Amazon OpenSearch Service 開発者ガイド」の「新しいドメインを作成する」の指示に従って、新しいドメインの作成時は [Node-to-node encryption] (ノード間の暗号化) オプションを確実に選択してください。その後、「スナップショットを使用してデータを移行する」に従って、データを新しいドメインに移行します。

[OpenSearch.4] CloudWatch Logs への OpenSearch ドメインエラーのログ記録を有効にする必要があります

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

重要度: 中

リソースタイプ : AWS::OpenSearch::Domain

AWS Config ルール : opensearch-logs-to-cloudwatch

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

logtype = 'error'

このコントロールは、OpenSearch ドメインが CloudWatch Logs にエラーログを送信するように設定されているかどうかをチェックします。CloudWatch へのエラーログ記録がドメインに対して有効になっていない場合、このコントロールは失敗します。

OpenSearch ドメインのエラーログを有効にし、それらのログを CloudWatch Logs に送信して保持と応答を行う必要があります。ドメインのエラーログは、セキュリティとアクセス監査や、可用性の問題の診断に役立ちます。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

ログ発行を有効にする方法については、「Amazon OpenSearch Service 開発者ガイド」の「ログ発行を有効にする (コンソール)」を参照してください。

[OpenSearch.5] OpenSearch ドメインでは、監査ログ記録を有効にする必要があります

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

重要度: 中

リソースタイプ : AWS::OpenSearch::Domain

AWS Config ルール : opensearch-audit-logging-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

cloudWatchLogsLogGroupArnList (オプション) Security Hub は、このパラメータを設定しません。監査ログ用に設定する必要がある CloudWatch Logs ロググループのカンマ区切りリスト。

OpenSearch ドメインの CloudWatch Logs のロググループがこのパラメータリストで指定されていない場合、このルールは NON_COMPLIANT となります。

このコントロールは、OpenSearch ドメインで監査ログ記録が有効になっているかどうかをチェックします。OpenSearch ドメインで監査ログ記録が有効になっていない場合、このコントロールは失敗します。

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

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

監査ログを有効にする詳細な手順については、「Amazon OpenSearch Service 開発者ガイド」の「監査ログの有効化」を参照してください。

[OpenSearch.6] OpenSearch ドメインには少なくとも 3 つのデータノードが必要です

カテゴリ: リカバリ > 耐障害性 > 高可用性

重要度: 中

リソースタイプ : AWS::OpenSearch::Domain

AWS Config ルール : opensearch-data-node-fault-tolerance

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは OpenSearch ドメインが少なくとも 3 つのデータノードが設定されているか、また zoneAwarenessEnabled が true かどうかをチェックします。OpenSearch ドメインでは、instanceCount が 3 より小さいか zoneAwarenessEnabled が false の場合、このコントロールは失敗します。

OpenSearch ドメインでは、高可用性と耐障害性のために少なくとも 3 つのデータノードが必要です。少なくとも 3 つのデータノードを持つ OpenSearch ドメインをデプロイすると、ノードに障害が発生した場合のクラスター操作が確実になります。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

OpenSearch ドメインのデータノード数を変更するには

AWS コンソールにサインインして、Amazon OpenSearch Service コンソールを (https://console.aws.amazon.com/es/) で開きます。
[My domains] (ドメイン) で、編集するドメインの名前を選択し、[Edit] (編集) を選択します。
[Data nodes] (データノード) で、[Number of nodes] (ノード数) を 3 以上の数値に設定します。3 つのアベイラビリティーゾーンに展開する場合は、アベイラビリティーゾーン間で均等に分配されるように 3 の倍数に設定します。
[Submit] (送信) を選択します。

[OpenSearch.7] OpenSearch ドメインは、きめ細かなアクセスコントロールを有効にする必要があります

カテゴリ: 保護 > セキュアなアクセス管理 > 機密性の高い API オペレーションアクションを制限する

重要度: 高

リソースタイプ : AWS::OpenSearch::Domain

AWS Config ルール : opensearch-access-control-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

OpenSearch ドメインが、きめ細かなアクセスコントロールを有効にしているかどうかをチェックします。きめ細かなアクセスコントロールが有効でない場合、このコントロールは失敗します。OpenSearch パラメータ update-domain-config を有効にするには、きめ細かなアクセスコントロールに advanced-security-options が必要となります。

きめ細かなアクセスコントロールは、Amazon OpenSearch Service のデータへのアクセスをコントロールする追加の方法を提供します。

注記

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

アフリカ (ケープタウン)
アジアパシフィック (ジャカルタ)
アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
ヨーロッパ (ミラノ)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

きめ細かなアクセスコントロールを有効にする方法については、「Amazon OpenSearch Service デベロッパーガイド」の「Amazon OpenSearch Service のきめ細かなアクセスコントロール」を参照してください。

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

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

重要度: 中

リソースタイプ : AWS::OpenSearch::Domain

AWS Config ルール : opensearch-https-required

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

TLS 暗号化を有効にするには、TLSSecurityPolicy を設定するために、UpdateDomainConfig の API オペレーションを使用して、DomainEndpointOptions を設定します。詳細については、「Amazon OpenSearch Service 開発者ガイド」の「ノード間の暗号化」を参照してください。

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

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

重要度: 非常事態

リソースタイプ: AWS::RDS::DBSnapshot、AWS::RDS::DBClusterSnapshot

AWS Config ルール : rds-snapshots-public-prohibited

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon RDS スナップショットがパブリックかどうかをチェックします。RDS スナップショットがパブリックである場合、このコントロールは失敗します。このコントロールは、RDS インスタンス、Aurora DB インスタンス、Neptune DB インスタンス、Amazon DocumentDB クラスターを評価します。

RDS スナップショットは、特定の時点で RDS インスタンスのデータをバックアップするために使用されます。これらは、RDS インスタンスを以前の状態に復元するために使用できます。

RDS スナップショットは、意図しない限りパブリックにしないでください。暗号化されていない手動スナップショットをパブリックとして共有すると、このスナップショットをすべての AWS アカウントが使用できるようになります。これにより、RDS インスタンスの意図しないデータ漏えいが発生する可能性があります。

パブリックアクセスを許可するように設定を変更した場合、AWS Config ルールは最大 12 時間変更を検出できない場合があります。AWS Config ルールが変更を検出するまで、設定がルール違反をしていてもチェックは成功します。

DB スナップショットの共有の詳細については、「Amazon RDS ユーザーガイド」の「DB スナップショットの共有」を参照してください。

注記

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

アフリカ (ケープタウン)
ヨーロッパ (ミラノ)
中東 (アラブ首長国連邦)

修正

この問題を修正するには、RDS スナップショットを更新してパブリックアクセスを削除します。

RDS スナップショットのパブリックアクセスを削除するには

Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
[Snapshots] (スナップショット) に移動し、変更するパブリックスナップショットを選択します。
[Actions] (アクション) から、[Share Snapshots] (スナップショットの共有) を選択します。
[DB snapshot visibility] (DB スナップショットの可視性) から、[Private] (プライベート) を選択します。
[DB snapshot visibility] (DB スナップショットの可視性) から、[all] (すべて) を選択します。
[Save] (保存) を選択します。

[RDS.2] Amazon RDS DB インスタンスはパブリックアクセスを禁止する必要があります。これは、PubliclyAccessible 設定により判断されます。

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

重要度: 非常事態

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

AWS Config ルール : rds-instance-public-access-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

Neptune DB インスタンスと Amazon DocumentDB クラスターには、PubliclyAccessible フラグがないため、評価できません。ただし、このコントロールでは、これらのリソースに関する結果を生成できます。これらの結果を抑制できます。

RDS インスタンス設定の PubliclyAccessible 値は、DB インスタンスがパブリックにアクセスできるかどうかを示します。DB インスタンスが PubliclyAccessible で設定されている場合、パブリックに解決可能な DNS 名を持つインターネット向けインスタンスであり、パブリック IP アドレスに解決されます。DB インスタンスがパブリックにアクセスできない場合、それはプライベート IP アドレスに解決される DNS 名を持つ内部インスタンスとなります。

RDS インスタンスのパブリックアクセスを可能にする意図がない限り、RDS インスタンスを PubliclyAccessible 値に設定しないでください。この設定を行った場合、データベースインスタンスへの不要なトラフィックが許可される可能性があります。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

この問題を修正するには、RDS DB インスタンスを更新してパブリックアクセスを削除します。

RDS DB インスタンスからパブリックアクセスを削除するには

Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
[Databases] (データベース) に移動し、パブリックデータベースを選択します。
[Modify] (変更) を選択します。
[Connectivity] (接続) で、[Additional connectivity configuration] (追加の接続設定) を展開します。
[Public access] (パブリックアクセス) で、[Not publicly accessible] (パブリックアクセス不可) を選択します。
[Continue] (続行) を選択します。
[Scheduling of modifications] (変更のスケジュール) で [Apply immediately] (すぐに適用) を選択します。
[Modify DB Instance] (DB インスタンスの変更) を選択します。

詳細については、「Amazon RDS ユーザーガイド」の「VPC 内の DB インスタンスの使用」を参照してください。

[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 リソースの暗号化」を参照してください。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

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

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

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

重要度: 中

リソースタイプ: AWS::RDS::DBClusterSnapshot、 AWS::RDS::DBSnapshot

AWS Config ルール : rds-snapshots-encrypted

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、RDS スナップショットが暗号化されているかどうかをチェックします。

このコントロールは、RDS DB インスタンスを対象としています。ただし、Aurora DB インスタンス、Neptune DB インスタンス、および Amazon DocumentDB クラスターのスナップショットに関する結果を生成することもできます。これらの結果が役に立たない場合は、それらを抑制できます。

保管中のデータを暗号化すると、認証されていないユーザーがディスクに保存しているデータにアクセスするリスクが低減されます。RDS スナップショット内のデータは、セキュリティを強化するために、保管中に暗号化する必要があります。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

Amazon RDS コンソールを使用して、この問題を修正できます。

暗号化されていない RDS スナップショットを暗号化するには

Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
ナビゲーションペインで、[Snapshots] (スナップショット) を選択します。
[Manual] (手動) または [System] (システム) で、暗号化するスナップショットを検索します。
暗号化するスナップショットの横にあるチェックボックスを選択します。
[Actions] (アクション) を選択し、[Copy Snapshot] (スナップショットのコピー) を選択します。
[New DB Snapshot Identifier] (新しい DB スナップショット ID) で、新しいスナップショットの名前を入力します。
[Encryption] (暗号化) で、[Enable Encryption] (暗号化を有効にする) を選択します。
スナップショットの暗号化に使用する KMS キーを選択します。
[Copy Snapshot] (スナップショットをコピー) を選択します。
新しいスナップショットが作成されたら、オリジナルのスナップショットを削除します。
[Backup Retention Period] (バックアップ保持期間) で、ゼロ以外の正の値を選択します。例えば、30 日間です。

[RDS.5] RDS DB インスタンスは、複数のアベイラビリティーゾーンで設定する必要があります

カテゴリ: リカバリ > 耐障害性 > 高可用性

重要度: 中

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

AWS Config ルール : rds-multi-az-support

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、RDS DB インスタンスの高可用性が有効になっているかどうかをチェックします。

RDS DB インスタンスは、複数のアベイラビリティーゾーン (AZ) に対して設定する必要があります。これにより、保存されたデータの可用性が保証されます。マルチ AZ 配置では、アベイラビリティーゾーンの可用性に問題がある場合、および RDS の定期メンテナンス中に自動フェイルオーバーを実行できます。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

この問題を修正するには、DB インスタンスを更新して、複数のアベイラビリティーゾーンを有効にします。

DB インスタンスに複数のアベイラビリティーゾーンを有効にするには

Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
ナビゲーションペインで、[データベース] を選択し、変更する DB インスタンスを選択します。
[Modify] (変更) を選択します。[Modify DB Instance] (DBインスタンスを変更) ページが表示されます。
[Instance Specifications] (インスタンスの仕様) で、[Multi-AZ deployment] (マルチ AZ 配置) を [Yes] (はい) に設定します。
[Continue] (続行) を選択して、変更の概要をチェックします。
(オプション) 変更をすぐに適用するには、[Apply immediately] (すぐに適用) を選択します。このオプションを選択すると、停止状態になる場合があります。詳細については、「Amazon RDS ユーザーガイド」の「[すぐに適用] 設定を使用する」を参照してください。
確認ページで、変更内容を確認します。変更内容が正しい場合は、[Modify DB Instance] (DB インスタンスを変更) を選択して変更を保存します。

[RDS.6] RDS DB インスタンスとクラスターの拡張モニタリングを設定する必要があります

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

重要度: 低

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

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

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

Amazon RDS では、拡張モニタリングによって、基盤となるインフラストラクチャのパフォーマンスの変化に対してより迅速にレスポンスできます。これらのパフォーマンスの変化により、データの可用性が低下する可能性があります。拡張モニタリングが有効になっている場合、RDS DB インスタンスが実行される OS のリアルタイムメトリクスを提供します。エージェントがインスタンスにインストールされています。エージェントは、ハイパーバイザーレイヤーから得られるよりも正確にメトリクスを取得できます。

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

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

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

[RDS.7] RDS クラスターでは、削除保護が有効になっている必要があります

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

重要度: 低

リソースタイプ : AWS::RDS::DBCluster

AWS Config ルール : rds-cluster-deletion-protection-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、RDS クラスターで削除保護が有効になっているかどうかをチェックします。

クラスターの削除保護を有効にすることで、偶発的なデータベース削除や不正なエンティティによる削除に対して保護の強化を提供します。

削除保護が有効になっている場合、RDS クラスターは削除できません。削除リクエストが成功するには、削除保護を無効にする必要があります。

注記

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

中国 (北京)
中国 (寧夏)
中東 (バーレーン)
中東 (アラブ首長国連邦)
南米 (サンパウロ)

修正

この問題を修正するには、RDS DB クラスターを更新して削除保護を有効にします。

RDS DB クラスターの削除保護を有効にするには

Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
ナビゲーションペインで、[Databases] (データベース) を選択し、変更する DB クラスターを選択します。
[Modify] (変更) を選択します。
[Deletion protection] (削除保護) で、[Enable deletion protection] (削除保護の有効化) を選択します。
[Continue] (続行) を選択します。
[Scheduling of modifications] (変更のスケジューリング) で、変更を適用するタイミングを選択します。オプションは [Apply during the next scheduled maintenance window] (次回の定期メンテナンス期間中に適用) または [Apply immediately] (すぐに適用) です。
[Modify Cluster] (クラスターの変更) を選択します。

[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 インスタンスを削除できません。削除リクエストが成功するには、削除保護を無効にする必要があります。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

この問題を修正するには、RDS DB インスタンスを更新して削除保護を有効にします。

RDS DB インスタンスの削除保護を有効にするには

Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
ナビゲーションペインで、[Databases] (データベース) を選択し、変更する DB インスタンスを選択します。
[Modify] (変更) を選択します。
[Deletion protection] (削除保護) で、[Enable deletion protection] (削除保護の有効化) を選択します。
[Continue] (続行) を選択します。
[Scheduling of modifications] (変更のスケジューリング) で、変更を適用するタイミングを選択します。オプションは [Apply during the next scheduled maintenance window] (次回の定期メンテナンス期間中に適用) または [Apply immediately] (すぐに適用) です。
[Modify DB Instance] (DB インスタンスの変更) を選択します。

[RDS.9] データベースログ記録を有効にする必要があります

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

重要度: 中

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

AWS Config ルール : rds-logging-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon RDS で次のログが有効で CloudWatch Logs に送信されているかどうかをチェックします。

Oracle: (アラート、監査、トレース、リスナー)
PostgreSQL: (Postgresql、アップグレード)
MySQL: (監査、エラー、一般、SlowQuery)
MariaDB: (監査、エラー、一般、SlowQuery)
SQL Server: (エラー、エージェント)
Aurora: (監査、エラー、一般、SlowQuery)
Aurora-MySQL: (監査、エラー、一般、SlowQuery)
Aurora-PostgreSQL: (Postgresql、アップグレード)。

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

注記

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

アフリカ (ケープタウン)
アジアパシフィック (大阪)
中国 (寧夏)
ヨーロッパ (ミラノ)

修正

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

AWS Management Console から CloudWatch Logs に MariaDB、MySQL、または PostgreSQL のログを有効にして発行するには、カスタム 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`

データベースエンジン

パラメータ

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 パラメータグループを作成するには

Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
ナビゲーションペインで、[Parameter groups] (パラメータグループ) を選択します。
[Create parameter group] (パラメータグループの作成) を選択します。[Create parameter group] (パラメータグループの作成) ウィンドウが表示されます。
[Parameter group] (パラメータグループ) ファミリーリストで、DB パラメータグループファミリーを選択します。
[Type] (タイプ) リストで、[DB Parameter Group] (DB パラメータグループ) を選択します。
[Group name] (グループ名) ボックスに、新しい DB パラメータグループの名前を入力します。
[Description] (説明) に、新しい DB パラメータグループの説明を入力します。
[Create] (作成) を選択します。

MariaDB ログ記録の新しいオプショングループをコンソールを使用して作成するには

Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
ナビゲーションペインで、[Option groups] (オプショングループ) を選択します。
[Create group] (グループの作成) を選択します。
[Create option group] (オプショングループを作成) ウィンドウで次の操作を行います。
1. [Name] (名前) には、AWS アカウントアカウント内で一意であるオプショングループの名前を入力します。名前には、英字、数字、ハイフンのみ使用できます。
2. [Description] (説明) には、オプショングループの簡単な説明を入力します。説明は表示用に使用されます。
3. [Engine] (エンジン) で、使用する DB エンジンを選択します。
4. [Major Engine Version] (メジャーエンジンバージョン) で、必要な DB エンジンのメジャーバージョンを選択します。
続行するには、[Create] (作成) を選択します。
作成したオプショングループの名前を選択します。
[Add option] (オプションを追加) を選択します。
[Option name] (オプション名) リストから MARIADB_AUDIT_PLUGIN を選択します。
SERVER_AUDIT_EVENTS を CONNECT, QUERY, TABLE, QUERY_DDL, QUERY_DML, QUERY_DCL に設定します。
[Add option] (オプションを追加) を選択します。

AWS Management Console から CloudWatch Logs に SQL Server DB、Oracle DB、または PostgreSQL ログを発行するには

Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
ナビゲーションペインで、[Databases] (データベース) を選択します。
変更する DB インスタンスを選択します。
[Modify] (変更) を選択します。
[Log exports] (ログのエクスポート) で、すべてのログファイルを選択して CloudWatch Logs への発行をスタートします。

[Log exports] (ログのエクスポート) は、CloudWatch Logs への発行をサポートしているデータベースエンジンのバージョンでのみ使用できます。
[Continue] (続行) を選択します。概要ページで [Modify DB Instance] (DB インスタンスを変更) を選択します。

新しい DB パラメータグループ、または DB オプショングループを RDS DB インスタンスに適用するには

Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
ナビゲーションペインで、[Databases] (データベース) を選択します。
変更する DB インスタンスを選択します。
[Modify] (変更) を選択します。[Modify DB Instance] (DBインスタンスを変更) ページが表示されます。
[Database options (データベースオプション) で、必要に応じて DB パラメータグループと DB オプショングループを変更します。
変更が完了したら、[Continue] (続行) を選択します。変更の概要をチェックします。
(オプション) 変更をすぐに適用するには、[Apply immediately] (すぐに適用) を選択します。このオプションを選択すると、停止状態になる場合があります。詳細については、「Amazon RDS ユーザーガイド」の「[すぐに適用] 設定を使用する」を参照してください。
[Modify DB Instance] (DB インスタンスを変更) を選択して、変更を保存します。

[RDS.10] IAM 認証は RDS インスタンス用に設定する必要があります

カテゴリ: 保護 > セキュアなアクセス管理 > パスワードレス認証

重要度: 中

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

AWS Config ルール : rds-instance-iam-authentication-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、RDS DB インスタンスで IAM データベース認証が有効になっているかどうかをチェックします。RDS DB インスタンスに IAM 認証が設定されていない場合、コントロールは失敗します。このコントロールは、mysql、postgres、aurora、aurora-mysql、aurora-postgresql および mariadb のエンジンタイプの RDS インスタンスのみを評価します。また、RDS インスタンスが結果を生成するには、available、backing-up、storage-optimization、storage-full のいずれかの状態になっている必要があります。

IAM データベース認証では、パスワードではなく、認証トークンを使用したデータベースインスタンスへの認証が可能です。データベースに出入りするネットワークトラフィックは、SSL を使用して暗号化されます。詳細については、「Amazon Aurora ユーザーガイド」の「IAM データベース認証」を参照してください。

注記

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

アフリカ (ケープタウン)
アジアパシフィック (香港)
アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)

修正

この問題を修正するには、DB インスタンスを更新して IAM 認証を有効にします。

既存の DB インスタンスで IAM 認証を有効にするには

Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
[Databases] (データベース) を選択します。
変更する DB インスタンスを選択します。
[Modify] (変更) を選択します。
[Database authentication] (データベース認証) で、[Password and IAM database authentication] (パスワードと IAM データベース認証) を選択します。
[Continue] (続行) を選択します。
[Scheduling of modifications] (変更のスケジューリング) で、変更を適用するタイミングを選択します。オプションは [Apply during the next scheduled maintenance window] (次回の定期メンテナンス期間中に適用) または [Apply immediately] (すぐに適用) です。
クラスターの場合は、[Modify DB Instance] (DB インスタンスを変更) を選択します。

[RDS.11] Amazon RDS インスタンスでは、自動バックアップが有効になっている必要があります

カテゴリ: リカバリ > 耐障害性 > バックアップの有効化

重要度: 中

リソースタイプ : AWS::RDS::DBCluster

AWS Config ルール : db-instance-backup-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

backupRetentionMinimum: 7

このコントロールは、Amazon Relational Database Service インスタンスで自動バックアップが有効に設定されているかどうか、およびバックアップ保持期間が 7 日以上であるかどうかをチェックします。バックアップが有効になっていない場合や、保存期間が 7 日未満の場合、コントロールは失敗します。

バックアップは、セキュリティインシデントからより迅速に復元し、システムの耐障害性を強化するのに役立ちます。Amazon RDS は、毎日のフルインスタンスボリュームスナップショットを簡単に設定する方法を提供します。Amazon RDS の自動バックアップの詳細については、「Amazon RDS ユーザーガイド」の「バックアップの使用」を参照してください。

注記

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

修正

自動バックアップをすぐに有効にするには

Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
ナビゲーションペインで、[データベース] を選択し、変更する DB インスタンスを選択します。
[Modify] (変更) を選択し、[Modify DB Instance] (DB インスタンスを変更) ページを開きます。
[Backup Retention Period] (バックアップ保持期間) で、0 以外の正の値 (30 日間など) を選択し、[Continue] (続行) を選択します。
[Scheduling of modifications] (変更のスケジュール) セクションを選択し、変更を適用するタイミングを選択します: [Apply during the next scheduled maintenance window] (次回の定期メンテナンス期間中に適用)、または [Apply immediately] (すぐに適用) のいずれか選択します。
その後、確認ページで [Modify DB Instance] (DB インスタンスを変更) を選択して変更を保存し、自動バックアップを有効にします。

[RDS.12] IAM 認証は RDS クラスター用に設定する必要があります

カテゴリ: 保護 > セキュアなアクセス管理 > パスワードレス認証

重要度: 中

リソースタイプ : AWS::RDS::DBCluster

AWS Config ルール : rds-cluster-iam-authentication-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ: なし

このコントロールは、Amazon RDS DB クラスターで IAM データベース認証が有効になっているかどうかをチェックします。

IAM データベース認証では、データベースインスタンスへパスワードなしの認証が許可されています。認証には、認証トークンが使用されます。データベースに出入りするネットワークトラフィックは、SSL を使用して暗号化されます。詳細については、「Amazon Aurora ユーザーガイド」の「IAM データベース認証」を参照してください。

注記

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

アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
中東 (バーレーン)
中東 (アラブ首長国連邦)
南米 (サンパウロ)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

DB クラスターの IAM 認証は、Amazon RDS コンソールから有効にできます。

既存の DB クラスターで IAM 認証を有効にするには

Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
[Databases] (データベース) を選択します。
変更する DB クラスターを選択します。
[Modify] (変更) を選択します。
[Database options] (データベースオプション) で、[Enable IAM DB authentication] (IAM DB 認証を有効にする) を選択します。
[Continue] (続行) を選択します。
[Scheduling of modifications] (変更のスケジュール) で、変更を適用するタイミングを選択します: [Apply during the next scheduled maintenance window] (次回の定期メンテナンス期間中に適用)、または [Apply immediately] (すぐに適用) のいずれか選択します。
[Modify Cluster] (クラスターの変更) を選択します。

[RDS.13] RDS 自動マイナーバージョンアップグレードを有効にする必要があります

カテゴリ: 検出 > 脆弱性およびパッチ管理

重要度: 高

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

AWS Config ルール : rds-automatic-minor-version-upgrade-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、RDS データベースインスタンスでマイナーバージョン自動アップグレードが有効になっているかどうかをチェックします。

マイナーバージョン自動アップグレードを有効にすると、リレーショナルデータベース管理システム (RDBMS) に最新のマイナーバージョンの更新がインストールされます。これらのアップグレードには、セキュリティパッチとバグ修正を含む場合があります。パッチのインストールを最新の状態に保つことは、システムを保護する上で重要なステップです。

注記

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

アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

DB インスタンスのマイナーバージョンアップグレードは、Amazon RDS コンソールから有効にできます。

既存の DB インスタンスのマイナーバージョン自動アップグレードを有効にするには

Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
[Databases] (データベース) を選択します。
変更する DB インスタンスを選択します。
[Modify] (変更) を選択します。
[Maintenance] (メンテナンス) の [Auto minor version upgrade] (マイナーバージョン自動アップグレード) で、[Yes] (はい) を選択します。
[Continue] (続行) を選択します。
[Scheduling of modifications] (変更のスケジュール) で、変更を適用するタイミングを選択します: [Apply during the next scheduled maintenance window] (次回の定期メンテナンス期間中に適用)、または [Apply immediately] (すぐに適用) のいずれか選択します。
[Modify DB Instance] (DB インスタンスの変更) を選択します。

[RDS.14] Amazon Aurora クラスターはバックトラッキングを有効にする必要があります

カテゴリ: リカバリ > 耐障害性 > バックアップの有効化

重要度: 中

リソースタイプ : AWS::RDS::DBCluster

AWS Config ルール : aurora-mysql-backtracking-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon Aurora クラスターでバックトラッキングが有効になっているかどうかをチェックします。

バックアップは、セキュリティインシデントからより迅速に復元するために役立ちます。また、システムの耐障害性を強化します。Aurora バックトラッキングによって、データベースを特定の時点に復元する時間が短縮されます。復元を実行する場合にデータベースの復元は必要ありません。

Aurora でのバックトラッキングの詳細については、「Amazon Aurora ユーザーガイド」の「Aurora DB クラスターのバックトラック」を参照してください。

注記

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

アフリカ (ケープタウン)
アジアパシフィック (香港)
アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
ヨーロッパ (ミラノ)
ヨーロッパ (ストックホルム)
中東 (バーレーン)
中東 (アラブ首長国連邦)
南米 (サンパウロ)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

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 (米国西部)

修正

このコントロールを修正するには、DB クラスターを複数のアベイラビリティーゾーンに対して設定します。

DB クラスターでマルチ AZ を有効にするには

Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
ナビゲーションペインで、[Databases] (データベース) を選択し、変更する DB インスタンスを選択します。
[Modify] (変更) を選択します。[Modify DB Instance] (DBインスタンスを変更) ページが表示されます。
[Instance Specifications] (インスタンスの仕様) で、[Multi-AZ deployment] (マルチ AZ 配置) を [Yes] (はい) に設定します。
[Continue] (続行) を選択して、変更の概要を確認します。
(オプション) 変更をすぐに適用するには、[Apply immediately] (すぐに適用) を選択します。このオプションを選択すると、停止状態になる場合があります。詳細については、「Amazon RDS ユーザーガイド」の「[すぐに適用] 設定を使用する」を参照してください。

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

注記

Aurora グローバルデータベースでは、修正の手順が異なります。Aurora グローバルデータベースに複数のアベイラビリティーゾーンを設定するには、DB クラスターを選択します。次に、[Actions] (アクション) を選択し、[Add reader] (リーダーを追加) を選択します。詳細については、「Amazon Aurora ユーザーガイド」の「Aurora レプリカを 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 データベースクラスターと同じ方法でタグ付けする必要があります。この設定を有効にすると、スナップショットが親データベースクラスターのタグを継承します。

注記

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

中国 (北京)
中東 (バーレーン)
中東 (アラブ首長国連邦)
南米 (サンパウロ)

修正

DB クラスターのスナップショットへの自動タグコピーを有効にするには

Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
[Databases] (データベース) を選択します。
変更する DB クラスターを選択します。
[Modify] (変更) を選択します。
[Backup] (バックアップ) で、[Copy tags to snapshots] (スナップショットにタグをコピー) を選択します。
[Continue] (続行) を選択します。
[Scheduling of modifications] (変更のスケジューリング) で、変更を適用するタイミングを選択します。[Apply during the next scheduled maintenance window] (次回の定期メンテナンス期間中に適用)、または [Apply immediately] (すぐに適用) のいずれかを選択できます。

[RDS.17] RDS DB インスタンスは、タグをスナップショットにコピーするように設定する必要があります

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

重要度: 低

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

AWS Config ルール: rds-instance-copy-tags-to-snapshots-enabled (Security Hub が開発したカスタムルール)

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、スナップショットの作成時に、すべてのタグをスナップショットにコピーするように RDS DB インスタンスが構成されているかどうかをチェックします。

IT アセットの身分証明書とインベントリはガバナンスとセキュリティの重要な側面です。すべての RDS DB インスタンスを可視化することで、それらのセキュリティ体制を評価し、潜在的な弱点に対してアクションを起こせるようにする必要があります。スナップショットは、親 RDS データベースインスタンスと同じ方法でタグ付けする必要があります。この設定を有効にすると、スナップショットが親データベースインスタンスのタグを継承します。

修正

DB インスタンスのスナップショットへの自動タグコピーを有効にするには

Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
[Databases] (データベース) を選択します。
変更する DB インスタンスを選択します。
[Modify] (変更) を選択します。
[Backup] (バックアップ) で、[Copy tags to snapshots] (スナップショットにタグをコピー) を選択します。
[Continue] (続行) を選択します。
[Scheduling of modifications] (変更のスケジューリング) で、変更を適用するタイミングを選択します。[Apply during the next scheduled maintenance window] (次回の定期メンテナンス期間中に適用)、または [Apply immediately] (すぐに適用) のいずれかを選択できます。

[RDS.18] RDS インスタンスは VPC 内にデプロイする必要があります

カテゴリ: 保護 > セキュアなネットワーク設定 > VPC 内のリソース

重要度: 高

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

AWS Config ルール: rds-deployed-in-vpc (Security Hub が開発したカスタムルール)

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon RDS インスタンスが EC2-VPC にデプロイされているかどうかをチェックします。

VPC は、RDS リソースへのアクセスを保護するための多数のネットワークコントロールを提供します。これらのコントロールには、VPC エンドポイント、ネットワーク ACL、セキュリティグループが含まれます。これらのコントロールを利用するには、EC2-VPC 上に RDS インスタンスを作成することが推奨されます。

修正

RDS インスタンスを VPC に移動する方法の詳細については、「Amazon RDS ユーザーガイド」の「DB インスタンスの VPC を更新する」を参照してください。

[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 イベント通知の使用」を参照してください。

修正

RDS クラスターイベント通知にサブスクライブするには

Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
ナビゲーションペインで、[Event subscriptions] (イベントサブスクリプション) を選択します。
[Event subscriptions] (イベントサブスクリプション) で、[Create event subscription] (イベントサブスクリプションを作成) を選択します。
[Create event subscription] (イベントサブスクリプションを作成) ダイアログボックスで、次の操作を行います。
1. [Name] (名前) に、イベント通知サブスクリプションの名前を入力します。
2. [Send notifications to] (通知の送信先) の SNS トピックで、既存の Amazon SNS ARN を選択します。新しいトピックを使用するには、[create topic] (トピックの作成) を選択して、トピックの名前と受取人のリストを入力します。
3. [Source type] (ソースタイプ) で、[Clusters] (クラスター) を選択します。
4. [Instances to include] (含めるインスタンス) で、[All clusters] (すべてのクラスター) を選択します。
5. [Event categories to include] (含めるイベントカテゴリ) で、[Specific event categories] (特定のイベントカテゴリ) を選択します。[All event categories] (すべてのイベントカテゴリ) を選択した場合も、コントロールは成功します。
6. [maintenance] (メンテナンス) と [failure] (障害) を選択します。
7. [Create] (作成) を選択します。

[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 イベント通知の使用」を参照してください。

修正

RDS インスタンスイベント通知にサブスクライブするには

Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
ナビゲーションペインで、[Event subscriptions] (イベントサブスクリプション) を選択します。
[Event subscriptions] (イベントサブスクリプション) で、[Create event subscription] (イベントサブスクリプションを作成) を選択します。
[Create event subscription] (イベントサブスクリプションを作成) ダイアログボックスで、次の操作を行います。
1. [Name] (名前) に、イベント通知サブスクリプションの名前を入力します。
2. [Send notifications to] (通知の送信先) の SNS トピックで、既存の Amazon SNS ARN を選択します。新しいトピックを使用するには、[create topic] (トピックの作成) を選択して、トピックの名前と受取人のリストを入力します。
3. [Source type] (ソースタイプ) で、[Instance] (インスタンス) を選択します。
4. [Instances to include] (含めるインスタンス) で、[All instances] (すべてのインスタンス) を選択します。
5. [Event categories to include] (含めるイベントカテゴリ) で、[Specific event categories] (特定のイベントカテゴリ) を選択します。[All event categories] (すべてのイベントカテゴリ) を選択した場合も、コントロールは成功します。
6. [maintenance] (メンテナンス)、[configuration change] (設定変更)、および [failure] (障害) を選択します。
7. [Create] (作成) を選択します。

[RDS.21] 重大なデータベースパラメータグループイベントに対して RDS イベント通知サブスクリプションを設定する必要があります

カテゴリ: 検出 > 検出サービス > アプリケーションモニタリング

重要度: 低

リソースタイプ : AWS::RDS::EventSubscription

AWS Config ルール: rds-pg-event-notifications-configured (Security Hub が開発したカスタムルール)

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし


DBParameterGroup: ["configuration change"]

修正

RDS データベースパラメータグループのイベント通知をサブスクライブするには

Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
ナビゲーションペインで、[Event subscriptions] (イベントサブスクリプション) を選択します。
[Event subscriptions] (イベントサブスクリプション) で、[Create event subscription] (イベントサブスクリプションを作成) を選択します。
[Create event subscription] (イベントサブスクリプションを作成) ダイアログボックスで、次の操作を行います。
1. [Name] (名前) に、イベント通知サブスクリプションの名前を入力します。
2. [Send notifications to] (通知の送信先) の SNS トピックで、既存の Amazon SNS ARN を選択します。新しいトピックを使用するには、[create topic] (トピックの作成) を選択して、トピックの名前と受取人のリストを入力します。
3. [Source type] (ソースタイプ) で、[Parameter groups] (パラメータグループ) を選択します。
4. [Instances to include] (含めるインスタンス) で、[All parameter groups] (すべてのパラメータグループ) を選択します。
5. [Event categories to include] (含めるイベントカテゴリ) で、[Specific event categories] (特定のイベントカテゴリ) を選択します。[All event categories] (すべてのイベントカテゴリ) を選択した場合も、コントロールは成功します。
6. [configuration change] (設定変更) を選択します。
7. [Create] (作成) を選択します。

[RDS.22] 重大なデータベースセキュリティグループイベントに対して RDS イベント通知サブスクリプションを設定する必要があります

カテゴリ: 検出 > 検出サービス > アプリケーションモニタリング

重要度: 低

リソースタイプ : AWS::RDS::EventSubscription

AWS Config ルール: rds-sg-event-notifications-configured (Security Hub が開発したカスタムルール)

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし


DBSecurityGroup: ["configuration change","failure"]

RDS イベント通知は Amazon SNS を使用して、RDS リソースの可用性または設定の変更をユーザーに知らせます。これらの通知により、迅速なレスポンスが可能になります。RDS イベント通知の詳細については、「Amazon RDS ユーザーガイド」の「Amazon RDS イベント通知の使用」を参照してください。

修正

RDS データベースセキュリティグループのイベント通知をサブスクライブするには

Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
ナビゲーションペインで、[Event subscriptions] (イベントサブスクリプション) を選択します。
[Event subscriptions] (イベントサブスクリプション) で、[Create event subscription] (イベントサブスクリプションを作成) を選択します。
[Create event subscription] (イベントサブスクリプションを作成) ダイアログボックスで、次の操作を行います。
1. [Name] (名前) に、イベント通知サブスクリプションの名前を入力します。
2. [Send notifications to] (通知の送信先) の SNS トピックで、既存の Amazon SNS ARN を選択します。新しいトピックを使用するには、[create topic] (トピックの作成) を選択して、トピックの名前と受取人のリストを入力します。
3. [Source type] (ソースタイプ) で、[Security groups] (セキュリティグループ) を選択します。
4. [Instances to include] (含めるインスタンス) で、[All security groups] (すべてのセキュリティグループ) を選択します。
5. [Event categories to include] (含めるイベントカテゴリ) で、[Specific event categories] (特定のイベントカテゴリ) を選択します。[All event categories] (すべてのイベントカテゴリ) を選択した場合も、コントロールは成功します。
6. [configuration change] (設定変更) と [failure] (障害) を選択します。
7. [Create] (作成) を選択します。

[RDS.23] RDS データベースとクラスターはデータベースエンジンのデフォルトポートを使用しないでください

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

重要度: 低

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

AWS Config ルール: rds-no-default-ports (Security Hub が開発したカスタムルール)

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、RDS クラスターまたはインスタンスがデータベースエンジンのデフォルトポート以外のポートを使用しているかどうかをチェックします。

既知のポートを使用して RDS クラスターまたはインスタンスをデプロイすると、攻撃者はクラスターまたはインスタンスに関する情報を推測できる可能性があります。攻撃者は、この情報を他の情報と組み合わせ、RDS クラスターまたはインスタンスに接続したり、ユーザーのアプリケーションに関する追加情報を取得できます。

ポートを変更する場合は、古いポートへの接続に使用された既存の接続文字列も更新する必要があります。また、ユーザーは DB インスタンスのセキュリティグループをチェックして、新しいポートでの接続を許可するイングレスルールが確実に含まれていることを確認する必要があります。

修正

既存の DB インスタンスのデフォルトポートを変更するには

Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
[Databases] (データベース) を選択します。
変更する DB インスタンスを選択します。
[Modify] (変更) を選択します。
[Database options] (データベースオプション) で、[Database port] (データベースポート) をデフォルト以外の値に変更します。
[Continue] (続行) を選択します。
[Scheduling of modifications] (変更のスケジューリング) で、変更を適用するタイミングを選択します。[Apply during the next scheduled maintenance window] (次回の定期メンテナンス期間中に適用)、または [Apply immediately] (すぐに適用) のいずれかを選択できます。
クラスターの場合は、[Modify Cluster] (クラスターの変更) を選択します。インスタンスの場合は、[Modify DB Instance] (DB インスタンスを変更) を選択します。

[RDS.24] RDS データベースクラスターはカスタム管理者ユーザーネームを使用する必要があります

カテゴリ: 識別 > リソース設定

重要度: 中

リソースタイプ : AWS::RDS:DBCluster

AWS Config ルール : rds-cluster-default-admin-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon RDS データベースクラスターが管理者ユーザーネームをデフォルト値から変更したかどうかをチェックします。このコントロールは、Neptune (Neptune DB) または docdb (DocumentDB) タイプのエンジンには適用されません。管理者ユーザーネームがデフォルト値に設定されている場合、このルールは失敗します。

Amazon RDS データベースを作成するときは、デフォルトの管理者ユーザーネームを一意の値に変更する必要があります。デフォルトのユーザーネームはパブリックナレッジであり、RDS データベースの作成時に変更する必要があります。デフォルトのユーザーネームを変更すると、意図しないアクセスのリスクが軽減されます。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

Amazon RDS データベースクラスターに関連付けられている管理者ユーザーネームを変更するには、新しい RDS データベースクラスターを作成し、データベースの作成時に、デフォルトの管理者ユーザーネームを変更します。

[RDS.25] RDS データベースインスタンスはカスタム管理者ユーザーネームを使用する必要があります

カテゴリ: 識別 > リソース設定

重要度: 中

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

AWS Config ルール : rds-instance-default-admin-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールでは、Amazon Relational Database Service (Amazon RDS) のデータベースインスタンスの管理者ユーザーネームがデフォルト値から変更されたかどうかをチェックします。このコントロールは、Neptune (Neptune DB) または docdb (DocumentDB) タイプのエンジンには適用されません。管理者ユーザーネームがデフォルト値に設定されている場合、このコントロールは失敗します。

Amazon RDS データベースのデフォルトの管理ユーザーネームは、パブリックナレッジです。Amazon RDS データベースを作成するときは、意図しないアクセスのリスクを減らすために、デフォルトの管理ユーザーネームを一意の値に変更する必要があります。

修正

RDS データベースインスタンスに関連付けられている管理ユーザーネームを変更するには、始めに新しい RDS データベースインスタンスを作成します。データベースの作成時に、デフォルトの管理ユーザーネームを変更します。

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

カテゴリ: 保護 > セキュアなネットワーク設定 > パブリックアクセス不可のリソース

重要度: 非常事態

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

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

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

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

Amazon Redshift クラスター設定の PubliclyAccessible 属性は、クラスターがパブリックにアクセス可能かどうかを示します。クラスターが PubliclyAccessible を true に設定して構成されている場合、パブリックに解決可能な DNS 名を持つインターネット向けインスタンスであり、パブリック IP アドレスに解決されます。

クラスターがパブリックにアクセスできない場合、プライベート IP アドレスに解決される DNS 名を持つ内部インスタンスです。クラスターをパブリックにアクセスさせる意図がない限り、クラスターは PubliclyAccessible を true に設定しないでください。

修正

この問題を修正するには、Amazon Redshift クラスターを更新して、パブリックアクセスを無効にします。

Amazon Redshift クラスターへのパブリックアクセスを無効にするには

Amazon Redshift コンソール (https://console.aws.amazon.com/redshift/) を開きます。
ナビゲーションメニューで、[Clusters] (クラスター) を選択し、変更するセキュリティグループのあるクラスターの名前を選択します。
[Actions] (アクション)、[Modify publicly accessible setting] (パブリックアクセスに可能な設定を変更) の順に選択します。
[Allow instances and devices outside the VPC to connect to your database through the cluster endpoint] (VPC の外部のインスタンスとデバイスがクラスターエンドポイントを介してデータベースに接続するように許可する) で、[No] (いいえ) を選択します。
[Confirm] (確認) を選択します。

[Redshift.2] Amazon Redshift クラスターへの接続は転送中に暗号化する必要があります

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

重要度: 中

リソースタイプ: AWS::Redshift::Cluster、AWS::Redshift::ClusterParameterGroup

AWS Config ルール : redshift-require-tls-ssl

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon Redshift クラスターへの接続において、転送中に暗号化を使用する必要があるかどうかをチェックします。Amazon Redshift クラスターパラメータ require_SSL が True に設定されていない場合、チェックは失敗します。

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

注記

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

修正

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

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

Amazon Redshift コンソール (https://console.aws.amazon.com/redshift/) を開きます。
ナビゲーションメニューで、[Config] (設定) を選択し、次に [Workload management] (ワークロード管理) を選択して、[Workload management] (ワークロード管理) ページを表示します。
変更するパラメータグループを選択します。
[Parameters] (パラメータ) を選択します。
[Edit parameters] (パラメータの編集) を選択し、require_ssl を True に設定します。
変更を入力し、[Save] (保存) を選択します。

[Redshift.3] Amazon Redshift クラスターでは、自動スナップショットが有効になっている必要があります

カテゴリ: リカバリ > 耐障害性 > バックアップの有効化

重要度: 中

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

AWS Config ルール : redshift-backup-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

MinRetentionPeriod = 7

このコントロールは、Amazon Redshift クラスターで自動スナップショットが有効になっているかどうかをチェックします。また、スナップショットの保持期間が 7 以上であるかどうかをチェックします。

バックアップは、セキュリティインシデントからより迅速に復元するために役立ちます。これにより、システムの耐障害性が強化されます。Amazon Redshift は、デフォルトで定期的にスナップショットを作成します。このコントロールは、自動スナップショットが有効で、少なくとも 7 日間保持されているかどうかをチェックします。Amazon Redshift の自動スナップショットの詳細については、「Amazon Redshift 管理ガイド」の「自動スナップショット」を参照してください。

注記

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

アフリカ (ケープタウン)
アジアパシフィック (大阪)
アジアパシフィック (シドニー)
中国 (寧夏)
ヨーロッパ (ミラノ)

修正

この問題を修正するには、スナップショットの保持期間を少なくとも 7 に更新します。

スナップショットの保持期間を変更するには

Amazon Redshift コンソール (https://console.aws.amazon.com/redshift/) を開きます。
ナビゲーションメニューで [Clusters] (クラスター) を選択し、変更するクラスター名を選択します。
[Edit] (編集) を選択します。
[Backup] (バックアップ) で、[Snapshot retention] (スナップショットの保持) を 7 以上の値に設定します。
[Modify Cluster] (クラスターの変更) を選択します。

[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 管理ガイド」の「データベース監査ログ記録」を参照してください。

修正

クラスター監査ログを有効にするには

Amazon Redshift コンソール (https://console.aws.amazon.com/redshift/) を開きます。
ナビゲーションメニューで [Clusters] (クラスター) を選択し、変更するクラスター名を選択します。
[Maintenance and monitoring] (メンテナンスとモニタリング) を選択します。
[Audit logging] (監査ログ記録) で、[Edit] (編集) を選択します。
[Enable audit logging] (監査ログ記録の有効化) で [yes] (はい) に設定し、ログの送信先バケットの詳細を入力します。
[Confirm] (確認) を選択します。

[Redshift.6] Amazon Redshift でメジャーバージョンへの自動アップグレードが有効になっている必要があります

カテゴリ: 検出 > 脆弱性およびパッチ管理

重要度: 中

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

AWS Config ルール : redshift-cluster-maintenancesettings-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

allowVersionUpgrade = true

このコントロールは、Amazon Redshift クラスターで自動メジャーバージョンアップグレードが有効になっているかどうかをチェックします。

自動メジャーバージョンアップグレードを有効にすることで、メンテナンスウィンドウ中に Amazon Redshift クラスターの最新のメジャーバージョンの更新がインストールされます。これらのアップデートには、セキュリティパッチやバグ修正が含まれる場合があります。パッチのインストールを最新の状態に保つことは、システムを保護する上で重要なステップです。

注記

このコントロールは、中東 (バーレーン) ではサポートされていません。

修正

この問題を AWS CLI から修正するには、Amazon Redshift modify-cluster コマンドを使用して--allow-version-upgrade 属性を設定します。


aws redshift modify-cluster --cluster-identifier clustername --allow-version-upgrade

clustername は Amazon Redshift クラスターの名前です。

[Redshift.7] Amazon Redshift クラスターは拡張 VPC ルーティングを使用する必要があります

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

重要度: 中

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

AWS Config ルール : redshift-enhanced-vpc-routing-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon Redshift クラスターで EnhancedVpcRouting が有効かどうかをチェックします。

拡張 VPC ルーティングは、クラスターとデータリポジトリ間のすべての COPY および UNLOAD トラフィックが VPC を経由するよう強制します。その後、セキュリティグループやネットワークアクセスコントロールリストなどの VPC 機能を使用して、ネットワークトラフィックを保護することができます。VPC フローログを使用して、ネットワークトラフィックをモニタリングすることもできます。

注記

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

アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

詳細な修正手順については、「Amazon Redshift 管理ガイド」の「拡張された VPC ルーティングの有効化」を参照してください。

[Redshift.8] Amazon Redshift クラスターはデフォルトの管理者ユーザーネームを使用しないでください

カテゴリ: 識別 > リソース設定

重要度: 中

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

AWS Config ルール : redshift-default-admin-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon Redshift クラスターが、管理者ユーザーネームをデフォルト値から変更したかどうかをチェックします。Redshift クラスターの管理者ユーザーネームが awsuser に設定されている場合、このコントロールは失敗します。

Amazon RDS クラスターを作成するときは、デフォルトの管理者ユーザーネームを一意の値に変更する必要があります。デフォルトのユーザーネームはパブリックナレッジであり、設定時に変更する必要があります。デフォルトのユーザーネームを変更すると、意図しないアクセスのリスクが軽減されます。

修正

Amazon Redshift クラスターの管理者ユーザーネームは、作成後に変更することはできません。DB クラスターを新たに作成するには、「こちら」の手順に従います。

[Redshift.9] Redshift クラスターでは、デフォルトのデータベース名を使用しないでください

カテゴリ: 識別 > リソース設定

重要度: 中

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

AWS Config ルール : redshift-default-db-name-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon Redshift クラスターが、データベース名をデフォルト値から変更したかどうかをチェックします。Redshift クラスターのデータベース名が dev に設定されている場合、このコントロールは失敗します。

Amazon RDS クラスターを作成するときは、デフォルトのデータベース名を一意の値に変更する必要があります。デフォルトの名前は一般に知られているため、設定時に変更する必要があります。よく知られた名前は、IAM ポリシー条件などで使用されると偶発的なアクセスにつながる可能性があります。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

Amazon Redshift クラスターのデータベース名は、作成後に変更することはできません。新規クラスターの作成方法については、「Amazon Redshift の入門ガイド」の「Amazon Redshift の開始方法」を参照してください。

[S3.1] S3 ブロックパブリックアクセス設定を有効にする必要があります

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

重要度: 中

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

AWS Config ルール : s3-account-level-public-access-blocks-periodic

スケジュールタイプ: 定期的

パラメータ:

ignorePublicAcls: true
blockPublicPolicy: true
blockPublicAcls: true
restrictPublicBuckets: true

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

ignorePublicAcls: true
blockPublicPolicy: true
blockPublicAcls: true
restrictPublicBuckets: true

すべてのパブリックアクセスブロック設定が true に設定されている場合、コントロールは成功します。

いずれかの設定が false に設定されているか、またはいずれかが設定されていない場合、コントロールは失敗します。

Amazon S3 パブリックアクセスブロックは、AWS アカウント全体または個々の S3 バケットレベルでコントロールを提供し、オブジェクトがパブリックアクセスしないように設計されています。パブリックアクセスは、アクセスコントロールリスト (ACL)、バケットポリシー、またはその両方からバケットおよびオブジェクトに付与されます。

S3 バケットをパブリックにアクセスできるように意図する場合を除き、アカウントレベルの Amazon S3 ブロックパブリックアクセス機能を設定する必要があります。

詳細については、「Amazon Simple Storage Service ユーザーガイド」の「Amazon S3 ブロックパブリックアクセスの使用」を参照してください。

注記

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

中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

この問題を修正するには、Amazon S3 ブロックパブリックアクセスを有効にします。

Amazon S3 ブロックパブリックアクセスを有効にするには

https://console.aws.amazon.com/s3/ で Amazon S3 コンソールを開きます。
[Block public access (account settings)] (パブリックアクセスをブロック (アカウント設定)) を選択します。
[Edit] (編集) を選択します。
[Block all public access] (すべてのパブリックアクセスをブロックする) を選択します。
[Save changes] (変更の保存) を選択します。

詳細については、「Amazon Simple Storage Service ユーザーガイド」の「Amazon S3 ブロックパブリックアクセスの使用」を参照してください。

[S3.2] S3 バケットではパブリック読み取りアクセスを禁止する必要があります

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

重要度: 非常事態

リソースタイプ : AWS::S3::Bucket

AWS Config ルール : s3-bucket-public-read-prohibited

スケジュールタイプ: 定期的および変更がトリガーされた場合

パラメータ : なし

このコントロールは、S3 バケットがパブリック読み取りアクセスを許可するかどうかをチェックします。これにより、ブロックパブリックアクセス設定、バケットポリシー、およびバケットアクセスコントロールリスト (ACL) を評価します。

ユースケースによっては、インターネット上の全員が S3 バケットから読み取れる必要があります。しかし、そのような状況は稀です。データの整合性とセキュリティを確保するために、S3 バケットをパブリックに読み取り可能にしないでください。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

この問題を修正するには、S3 バケットを更新してパブリックアクセスを削除します。

S3 バケットからパブリックアクセスを削除するには

https://console.aws.amazon.com/s3/ で Amazon S3 コンソールを開きます。
左側のナビゲーションペインで、[Buckets] (バケット) を選択します。
更新する S3 バケットの名前を選択します。
[Permissions] (許可) を選択し、[Block public access] (パブリックアクセスのブロック) を選択します。
[Edit] (編集) を選択します。
[Block all public access] (すべてのパブリックアクセスをブロックする) を選択します。次に、[Save] (保存) を選択します。
プロンプトが表示されたら、confirm を入力して [Confirm] (確認) を選択します。

[S3.3] S3 バケットはパブリック書き込みアクセスを禁止する必要があります

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

重要度: 非常事態

リソースタイプ : AWS::S3::Bucket

AWS Config ルール : s3-bucket-public-write-prohibited

スケジュールタイプ: 定期的および変更がトリガーされた場合

パラメータ : なし

このコントロールは、S3 バケットがパブリック書き込みアクセスを許可するかどうかをチェックします。これにより、ブロックパブリックアクセス設定、バケットポリシー、およびバケットアクセスコントロールリスト (ACL) を評価します。

ユースケースによっては、インターネット上の全員が S3 バケットに書き込むことができる必要があります。しかし、そのような状況は稀です。データの整合性とセキュリティを確保するため、S3 バケットはパブリックに書き込み可能にしないでください。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

この問題を修正するには、S3 バケットを更新してパブリックアクセスを削除します。

S3 バケットに対するパブリックアクセスを削除するには

https://console.aws.amazon.com/s3/ で Amazon S3 コンソールを開きます。
左側のナビゲーションペインで、[Buckets] (バケット) を選択します。
更新する S3 バケットの名前を選択します。
[Permissions] (許可) を選択し、[Block public access] (パブリックアクセスのブロック) を選択します。
[Edit] (編集) を選択します。
[Block all public access] (すべてのパブリックアクセスをブロックする) を選択します。次に、[Save] (保存) を選択します。
プロンプトが表示されたら、confirm を入力して [Confirm] (確認) を選択します。

[S3.4] S3 バケットでは、サーバー側の暗号化を有効にする必要があります

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

重要度: 中

リソースタイプ : AWS::S3::Bucket

AWS Config ルール : s3-bucket-server-side-encryption-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、S3 バケットで Amazon S3 のデフォルトの暗号化が有効になっていること、または S3 バケットポリシーでサーバー側の暗号化なしの put-object リクエストを明示的に拒否しているかチェックします。

S3 バケット内の機密データのセキュリティを強化するには、サーバー側の暗号化を使用してバケットを設定し、保管中のデータを保護する必要があります。Amazon S3 は、一意のキーで各オブジェクトを暗号化します。追加の保護措置として、Amazon S3 は定期的にローテーションされるルートキーを使ってキーそのものを暗号化します。Amazon S3 のサーバー側の暗号化は、データの暗号化に利用できるものの中でも最強のブロック暗号の 1 つである 256 ビットの Advanced Encryption Standard (AES−256) を使用します。

詳細については、「Amazon Simple Storage Service ユーザーガイド」の「Amazon S3 が管理する暗号化キーによるサーバー側の暗号化 (SSE−S3) を使用したデータの保護」を参照してください。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

この問題を修正するには、S3 バケットを更新して、デフォルトの暗号化を有効にします。

S3 バケットのデフォルト暗号化を有効にするには

https://console.aws.amazon.com/s3/ で Amazon S3 コンソールを開きます。
左側のナビゲーションペインで、[Buckets] (バケット) を選択します。
リストから S3 バケットを選択します。
[Properties] (プロパティ) を選択します。
[Default encryption] (デフォルトの暗号化) を選択します。
暗号化には、AES-256 または AWS-KMS のいずれかを選択します。
- Amazon S3 によってマネージドされるキーをデフォルト暗号化に使用するには、AES-256 を選択します。Amazon S3 サーバー側暗号化を使用してデータを暗号化する方法の詳細については、「Amazon Simple Storage Service ユーザーガイド」を参照してください。
- AWS KMS によってマネージドされるキーをデフォルト暗号化に使用するには、AWS-KMS を選択します。次に、作成した AWS KMS ルートキーのリストからルートキーを選択します。
  
  使用する AWS KMS キーの Amazon リソースネーム (ARN) を入力します。IAM コンソールの [Encryption keys] (暗号化キー) で、AWS KMS キーの ARN を確認できます。または、ドロップダウンリストからキー名を選択できます。
  
  重要
  デフォルト暗号化設定に AWS KMS オプションを使用する場合、AWS KMS の RPS (1 秒あたりのリクエスト) クォータが適用されます。AWS KMS クォータの詳細およびクォータの引き上げをリクエストする方法については、「AWS Key Management Service 開発者ガイド」を参照してください。
  
  AWS KMS キーの作成方法の詳細については、「AWS Key Management Service 開発者ガイド」を参照してください。
  
  Amazon S3 で AWS KMS を使用する方法の詳細については、「Amazon Simple Storage Service ユーザーガイド」を参照してください。
デフォルト暗号化を有効にする際、バケットポリシーの更新が必要な場合があります。バケットポリシーからデフォルトの暗号化に移行する方法の詳細については、「Amazon Simple Storage Service ユーザーガイド」を参照してください。
[Save] (保存) を選択します。

デフォルトの S3 バケット暗号化の詳細については、「Amazon Simple Storage Service ユーザーガイド」を参照してください。

[S3.5] S3 バケットでは、Secure Socket Layer を使用するためのリクエストの要求が必要です。

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

重要度: 中

リソースタイプ : AWS::S3::Bucket

AWS Config ルール : s3-bucket-ssl-requests-only

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、S3 バケットのポリシーで、Secure Socket Layer (SSL) の使用にリクエストが必要とされているかどうかをチェックします。

S3 バケットには、条件キー aws:SecureTransport によって示される S3 リソースポリシーで HTTPS 経由のデータ送信のみを受け入れるために、すべてのリクエスト (Action: S3:*) を要求するポリシーを備える必要があります。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

この問題を修正するには、S3 バケットの許可ポリシーを更新します。

安全でない伝送の拒否を S3 バケットで設定するには

https://console.aws.amazon.com/s3/ で Amazon S3 コンソールを開きます。
非準拠バケットに移動し、バケット名を選択します。
[Permissions] (許可) を選択し、[Bucket Policy] (バケットポリシー) を選択します。

以下のポリシーに、同様のポリシーステートメントを追加します。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": "*"
        }
    ]
}

[Save] (保存) を選択します。

詳細については、ナレッジセンターの記事「AWS Config ルール s3-bucket-ssl-requests-only に準拠するには、どの S3 バケットポリシーを使用する必要がありますか?」を参照してください。

[S3.6] バケットポリシー内で別の AWS アカウントに付与された Amazon S3 許可は制限する必要があります

カテゴリ: 保護 > セキュアなアクセス管理 > 機密性の高い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

このコントロールでは、Principal 要素内のエンティティのみがチェックされ、ポリシーの Condition 要素内の条件は考慮されません。

最小特権アクセスの実装は、セキュリティリスクおよびエラーの影響や悪意ある行動を減らす上での基礎となります。もしS3 バケットポリシーで外部アカウントからのアクセスを許可している場合、内部脅威または攻撃者によるデータの漏えいにつながる可能性があります。

blacklistedactionpatterns パラメータを使用すると、S3 バケットのルールを正常に評価できます。パラメータは、外部アカウントに対して blacklistedactionpatterns リストに含まれていないアクションパターンのアクセス許可を付与します。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

この問題を修正するには、S3 バケットポリシーを編集して許可を削除します。

S3 バケットポリシーを編集するには

https://console.aws.amazon.com/s3/ で Amazon S3 コンソールを開きます。
[Bucket name] (バケット名) リストで、ポリシーを編集する S3 バケット名を選択します。
[Permissions] (許可) を選択し、[Bucket Policy] (バケットポリシー) を選択します。
[Bucket policy editor] (バケットポリシーエディタ) テキストボックスで、以下のいずれかの操作を行います。
- 別の AWS アカウントに拒否されたアクションへのアクセス許可を付与するステートメントを削除する
- 許可された拒否済みのアクションをステートメントから削除する
[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 (米国西部)

修正

バケットレベルでパブリックアクセスを削除する方法については、「Amazon S3 ユーザーガイド」の「Amazon S3 ストレージへのパブリックアクセスのブロック」を参照してください。

[S3.9] S3 バケットサーバーアクセスログ記録を有効にする必要があります

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

重要度: 中

リソースタイプ : AWS::S3::Bucket

AWS Config ルール : s3-bucket-logging-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、S3 バケットでサーバーアクセスログ記録が有効になっているかどうかをチェックします。ログ記録を有効にすると、Amazon S3 は、ソースバケットのアクセスログを選択されたターゲットバケットに配信します。ターゲットバケットは、ソースバケットと同じ AWS リージョン内にある必要があり、デフォルトの保持期間設定は設定しないでください。サーバーアクセスのログ記録が有効になっている場合、このコントロールは成功します。ターゲットのログ記録バケットは、サーバーアクセスのログ記録を有効にする必要がないため、このバケットの結果は非表示にします。

サーバーアクセスのログ記録には、バケットに対するリクエストの詳細を提供します。サーバーアクセスログは、セキュリティとアクセス監査に役立ちます。詳細については、「Amazon S3 のセキュリティベストプラクティス: Amazon S3 サーバーアクセスログを有効にします」を参照してください。

修正

S3 バケットのアクセスログ記録を有効にするには

AWS Management Console にサインインし、Amazon S3 コンソール https://console.aws.amazon.com/s3/ を開きます。
リストからバケットを選択します。
[Properties] (プロパティ) を選択します。
[Server access logging (サーバーアクセスのログ記録)] で、[Edit (編集)] を選択します。
[Server access logging] (サーバーアクセスのログ記録) で[Enable] (有効) を選択します。次に、[Save changes] (変更の保存) を選択します。

[S3.10] バージョニングが有効な S3 バケットでは、ライフサイクルポリシーを設定する必要があります

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

重要度: 中

リソースタイプ : AWS::S3::Bucket

AWS Config ルール : s3-version-lifecycle-policy-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon Simple Storage Service (Amazon S3) のバージョンが有効化されたバケットにライフサイクルポリシーが設定されているかどうかをチェックします。このルールは、Amazon S3 ライフサイクルポリシーが有効ではない場合、失敗します。

オブジェクトの存続期間中に Amazon S3 で実行するアクションの定義に役立てるため、Amazon S3 バケットにライフサイクルルールの設定を推奨します。

修正

Amazon S3 バケットでのライフサイクルの設定の詳細については、「バケットのライフサイクル設定の指定」と「ストレージのライフサイクルの管理」を参照してください。

[S3.11] S3 バケットでは、イベント通知を有効にする必要があります

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

重要度: 中

リソースタイプ : AWS::S3::Bucket

AWS Config ルール : s3-event-notifications-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、S3 イベント通知が Amazon S3 バケットで有効になっているかどうかをチェックします。バケットで S3 イベント通知が有効になっていない場合、このコントロールは失敗します。

イベント通知を有効にすると、特定のイベントが発生したときに、Amazon S3 バケットでアラートを受信します。例えば、オブジェクトの作成、オブジェクトの削除、オブジェクトの復元を通知を受けることができます。これらの通知により、不正なデータアクセスにつながる可能性のある偶発的または意図的な変更を関連チームに警告することができます。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

S3 バケットおよびオブジェクトの変更を、検出する方法の詳細については、「Amazon S3 ユーザーガイド」の「Amazon S3 イベント通知」を参照してください。

[S3.12] バケットへのユーザーアクセスを管理用として、S3 アクセスコントロールリスト (ACL) を使用しないでください

カテゴリ: 保護 > セキュアなアクセス管理 > アクセスコントロール

重要度: 中

リソースタイプ : AWS::S3::Bucket

AWS Config ルール : s3-bucket-acl-prohibited

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon S3 バケットが ACL を介してユーザー許可を提供しているかどうかをチェックします。S3 バケットでのユーザーアクセスを管理するために ACL が設定されている場合、コントロールは失敗します。

ACL は、IAM よりも前のレガシーアクセスコントロールメカニズムです。ACL の代わりに、IAM ポリシーまたは S3 バケットポリシーを使用して、ユーザーの S3 バケットへのアクセスをより簡単に管理することを推奨します。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

S3 バケットへのアクセス管理の詳細については、「Amazon S3 ユーザーガイド」の「バケットポリシーとユーザーポリシー」を参照してください。現在の ACL 許可を確認する方法の詳細については、「Amazon S3 ユーザーガイド」の「アクセスコントロールリスト (ACL) の概要」を参照してください。

[S3.13] S3 バケットでは、ライフサイクルポリシーを設定する必要があります

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

重要度: 低

リソースタイプ : AWS::S3::Bucket

AWS Config ルール : s3-lifecycle-policy-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon S3 バケットにライフサイクルポリシーが設定されているかどうかをチェックします。Amazon S3 バケットにライフサイクルポリシーが設定されていない場合、このコントロールは失敗します。

S3 バケットにライフサイクルルールを設定すると、オブジェクトの有効期間中に S3 が実行するアクションが定義されます。例えば、オブジェクトを別のストレージクラスに移行させる、アーカイブする、あるいは指定した期間後に削除する、といったことが可能です。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

Amazon S3 バケットでライフサイクルポリシーを設定する方法の詳細については、「Amazon S3 ユーザーガイド」の「バケットのライフサイクル設定の指定」および「ストレージのライフサイクルの管理」を参照してください。

[SageMaker.1] SageMaker ノートブックインスタンスは、インターネットに直接アクセスできないようにする必要があります

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

重要度: 高

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

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

スケジュールタイプ: 定期的

パラメータ : なし

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

VPC なしで SageMaker インスタンスを設定した場合、デフォルトではインスタンスでインターネットへの直接アクセスが有効になっています。VPC 有りでインスタンスを設定し、デフォルト設定を [Disable — Access the internet through a VPC] (無効化 - VPC 経由でインターネットにアクセスする) に変更する必要があります。

ノートブックからモデルをトレーニングまたはホストするには、インターネットアクセスが必要です。インターネットアクセスを有効にするには、VPC に NAT ゲートウェイがあり、セキュリティグループでアウトバウンド接続を許可していることを確認してください。ノートブックインスタンスを VPC 内のリソースに接続する方法の詳細については、「Amazon SageMaker 開発者ガイド」の「ノートブックインスタンスを VPC 内のリソースに接続する」を参照してください。

また、SageMaker 設定へのアクセスが認可されたユーザーのみに制限されていることも確認する必要があります。ユーザーの IAM 許可を、SageMaker の設定変更とリソースの変更に制限します。

注記

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

アフリカ (ケープタウン)
中国 (北京)
中国 (寧夏)
ヨーロッパ (ミラノ)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)

修正

ノートブックインスタンスの作成後は、インターネットアクセス設定を変更できないことに注意してください。停止、削除、再作成する必要があります。

直接のインターネットアクセスを拒否するように SageMaker ノートブックインスタンスを設定するには

SageMaker コンソール (https://console.aws.amazon.com/sagemaker/) を開きます。
[Notebook instances] (ノートブックインスタンス) に移動します。
インターネットへの直接のアクセスが有効になっているインスタンスを削除します。インスタンスを選択し、[Actions] (アクション)、[stop] (停止) の順に選択します。

インスタンスの停止後、[Actions] (アクション)、[delete] (削除) の順に選択します。
[Create notebook instance] (ノートブックインスタンスの作成) を選択します。設定の詳細を入力します。
[Network] (ネットワーク) セクションを展開し、VPC、[subnet] (サブネット)、および [security group](セキュリティグループ) を選択します。[Direct internet access] (直接のインターネットアクセス) で、[Disable — Access the internet through a VPC] (無効化 - VPC 経由でインターネットにアクセスする) を選択します。
[Create notebook instance] (ノートブックインスタンスの作成) を選択します。

詳細については、「Amazon SageMaker 開発者ガイド」の「ノートブックインスタンスを VPC 内のリソースに接続する」を参照してください。

[SageMaker.2] SageMaker ノートブックインスタンスはカスタム VPC で起動する必要があります

カテゴリ: 保護 > セキュアなネットワーク設定 > VPC 内のリソース

重要度: 高

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

AWS Config ルール : sagemaker-notebook-instance-inside-vpc

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon SageMaker ノートブックインスタンスがカスタム仮想プライベートクラウド (VPC) 内で起動されているかどうかをチェックします。SageMaker ノートブックインスタンスがカスタム VPC 内で起動されない場合、または SageMaker サービス VPC で起動された場合、このコントロールは失敗します。

サブネットは、ある範囲の IP アドレスが示す VPC 内の領域です。インフラストラクチャの安全なネットワーク保護を確保するために、リソースは可能な限りカスタム VPC 内に保管することをお勧めします。Amazon VPC は、ユーザーの AWS アカウント専用の仮想ネットワークです。Amazon VPC を使用すると、SageMaker Studio とノートブックインスタンスのネットワークアクセスとインターネット接続を制御できます。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

ノートブックインスタンスを作成した後は、VPC の設定を変更することはできません。代わりに、インスタンスを削除して再作成できます。ノートブックインスタンスの削除と作成の手順については、「Amazon SageMaker デベロッパーガイド」の「Amazon SageMaker ノートブックインスタンスの使用を開始する」を参照してください。

[SageMaker.3] ユーザーは SageMaker ノートブックインスタンスのルートアクセス権を付与されてはなりません

カテゴリ: 保護 > セキュアなアクセス管理 > ルートユーザーのアクセス制限

重要度: 高

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

AWS Config ルール : sagemaker-notebook-instance-root-access-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon SageMaker ノートブックインスタンスでルートアクセスが有効になっていないかをチェックします。Amazon SageMaker ノートブックインスタンスでルートアクセスが有効になっている場合、コントロールは失敗します。

最小特権のプリンシパルに従い、意図せずに権限を過剰にプロビジョニングしないために、ルートアクセスをインスタンスリソースに制限することが、推奨されるセキュリティ上のベストプラクティスです。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

SageMaker ノートブックインスタンスへのルートアクセスを制限するには、「Amazon SageMaker デベロッパーガイド」の「SageMaker ノートブックインスタンスへのルートアクセスを制御する」を参照してください。

[SecretsManager.1] Secrets Manager のシークレットは、自動ローテーションを有効にする必要があります

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

重要度: 中

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

AWS Config ルール : secretsmanager-rotation-enabled-check

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、AWS Secrets Manager に保存されているシークレットに自動ローテーションが設定されているかどうかをチェックします。

Secrets Manager は、組織のセキュリティ体制を向上するのに役立ちます。シークレットとは、データベース認証情報、パスワード、サードパーティーの API キーなどが含まれます。Secrets Manager を使用することで、シークレットを一元的に保存、シークレットの自動暗号化、シークレットへのアクセスコントロール、シークレットを安全かつ自動的にローテーションすることができます。

Secrets Manager はシークレットをローテーションできます。ローテーションを使用して、長期のシークレットを短期のシークレッに置き換えることができます。シークレットをローテーションすることで、権限のないユーザーが侵害されたシークレットを使用できる期間を制限することができます。このため、シークレットは頻繁にローテーションする必要があります。ローテーションの詳細については、「AWS Secrets Manager ユーザーガイド」の「AWS Secrets Manager シークレットのローテーション」を参照してください。

注記

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

アジアパシフィック (ジャカルタ)
アジアパシフィック (大阪)
中東 (アラブ首長国連邦)

修正

この問題を修正するには、シークレットの自動ローテーションを有効にします。

シークレットの自動ローテーションを有効にするには

Secrets Manager コンソール (https://console.aws.amazon.com/secretsmanager/) を開きます。
ローテーションが必要なシークレットを探すには、検索フィールドにシークレット名を入力します。
ローテーションするシークレットを選択すると、シークレットの詳細ページが表示されます。
[Rotation configuration] (ローテーション設定) で、[Edit rotation] (ローテーションを編集) を選択します。
[Edit rotation configuration] (ローテーション設定を編集する) で、[Enable automatic rotation] (自動ローテーションを有効にする) を選択します。
[Select Rotation Interval] (ローテーション間隔を選択) で、ローテーション間隔を選択します。
ローテーションの Lambda 関数を選択します。Lambda ローテーション関数のカスタマイズの詳細については、「AWS Secrets Managerユーザーガイド」の「Lambda ローテーション関数の理解とカスタマイズ」を参照してください。
ローテーションのシークレットを設定するには、[Next] (次へ) を選択します。

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 シークレットはローテーションスケジュールに基づいて正常にローテーションされたかどうかをチェックします。RotationOccurringAsScheduled が false の場合、コントロールは失敗します。コントロールは、ローテーションが設定されていないシークレットを評価しません。

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

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

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

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

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 (米国西部)

修正

Secrets Manager コンソールから、非アクティブなシークレットを削除できます。

非アクティブなシークレットを削除するには

Secrets Manager コンソール (https://console.aws.amazon.com/secretsmanager/) を開きます。
シークレットを探すには、検索ボックスにシークレット名を入力します。
削除するシークレットを選択します。
[Secret details] (シークレットの詳細) の [Actions] (アクション) から、[Delete secret] (シークレットを削除する) を選択します。
[Schedule secret deletion] (シークレットの削除をスケジュールする) で、シークレットが削除されるまでの待機日数を入力します。
[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 (米国西部)

修正

Secrets Manager コンソールで自動シークレットローテーションを有効にできます。

シークレットローテーションを有効にするには

Secrets Manager コンソール (https://console.aws.amazon.com/secretsmanager/) を開きます。
シークレットを探すには、検索ボックスにシークレット名を入力します。
表示するシークレットを選択します。
[Rotation configuration] (ローテーション設定) で、[Edit rotation] (ローテーションを編集) を選択します。
[Edit rotation configuration] (ローテーション設定を編集する) で、[Enable automatic rotation] (自動ローテーションを有効にする) を選択します。
[Select Rotation Interval] (ローテーション間隔を選択) で、ローテーション間隔を選択します。
ローテーションに使用する Lambda 関数を選択します。
[Next] (次へ) を選択します。
自動ローテーションのシークレットを設定した後、[Rotation Configuration] (ローテーション設定) で、[Rotate secret immediately] (すぐにシークレットをローテーションさせる) を選択します。

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

重要度: 中

リソースタイプ : AWS::SNS::Topic

AWS Config ルール : sns-encrypted-kms

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、AWS KMS を使用して SNS トピックが保管中に暗号化されているかどうかをチェックします。

保管中のデータを暗号化すると、ディスクに保存されているデータが、AWS に認証されていないユーザーによってアクセスされるリスクが軽減されます。また、権限のないユーザーがデータにアクセスできる能力を制限するための一連のアクセスコントロールも追加します。例えば、データを読み取る前にデータを復号化するには、API の許可が必要です。SNS トピックは、セキュリティを強化するために、保管時に暗号化する必要があります。詳細については、「Amazon Simple Notification Service 開発者ガイド」の「保管中の暗号化」を参照してください。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

この問題を修正するには、SNS トピックを更新して暗号化を有効にします。

暗号化されていない SNS トピックを暗号化するには

Amazon SNS コンソール (https://console.aws.amazon.com/sns/v3/home) を開きます。
ナビゲーションペインで、[Topics] (トピック) を選択します。
暗号化するトピックの名前を選択します。
[Edit] (編集) を選択します。
[Encryption] (暗号化) で、[Enable Encryption] (暗号化を有効にする) を選択します。
トピックの暗号化に使用する KMS キーを選択します。AWS のサービスがトピックのイベントソースである場合は、カスタマーマネージドキーを選択してください。
[Save changes] (変更の保存) を選択します。

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

重要度: 中

リソースタイプ : AWS::SNS::Topic

AWS Config ルール : sns-topic-message-delivery-notification-enabled

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、エンドポイントの Amazon SNS トピックに送信される通知メッセージの配信ステータスで、ログ記録が有効になっているかどうかをチェックします。メッセージの配信ステータス通知が有効になっていない場合、このコントロールは失敗します。

ログ記録は、サービスの信頼性、可用性、パフォーマンスを維持するための重要な要素です。メッセージの配信ステータスをログ記録することで、以下のようなオペレーション上のインサイトを得ることができます。

メッセージが Amazon SNS エンドポイントに配信されたかどうかを知ることができます。

Amazon SNS エンドポイントから Amazon SNS に送信された応答を識別します。

メッセージの滞留時間 (メッセージの発行から Amazon SNS エンドポイントに渡されるまでの時間) を決定する。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

トピックの配信ステータスロギングを設定する方法については、「Amazon Simple Notification Service デベロッパーガイド」の「Amazon SNS メッセージ配信ステータス」を参照してください。

[SQS.1] Amazon SQS キューは保管中に暗号化する必要があります

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

重要度: 中

リソースタイプ : AWS::SQS::Queue

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

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、Amazon SQS キューが保管中に暗号化されているかどうかをチェックします。Amazon SQS マネージドキー (SSE-SQS) または AWS Key Management Service (AWS KMS) キー (SSE-KMS) を使用している場合は、コントロールは成功します。

サーバー側の暗号化 (SSE) により、機密データを暗号化されたキューで送信できます。キュー内のメッセージの内容を保護するために、SSE は KMS キーを使用します。詳細については、「Amazon Simple Queue Service 開発者ガイド」の「保管中の暗号化」を参照してください。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

AWS Management Console を使用して SSE を管理する詳細については、「Amazon Simple Queue Service 開発者ガイド」の「キュー (コンソール) のサーバー暗号化 (SSE) を設定」を参照してください。

[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 ユーザーガイド」を参照してください。

注記

このコントロールは、中東 (UAE) ではサポートされていません。

修正

Systems Manager コンソールを使用して、この問題を修正できます。

EC2 インスタンスを Systems Manager で確実に管理するには

AWS Systems Manager コンソール (https://console.aws.amazon.com/systems-manager/) を開きます。
ナビゲーションメニューで、[Quick setup] (クイックセットアップ) を選択します。
[Create] (作成) を選択します。
[Configuration type] (設定タイプ) で、[Host Management] (ホスト管理) を選択し、[Next] (次へ) を選択します。
設定画面で、デフォルトのオプションをそのまま使用できます。

オプションで、以下の変更を行うことができます。
1. CloudWatch を使用して EC2 インスタンスをモニタリングする場合は、[Install and configure the CloudWatch agent] (CloudWatch エージェントをインストールして設定する) および [Update the CloudWatch agent once every 30 days] (CloudWatch エージェントを 30 日に 1 回更新する) を選択します。
2. [Targets] (ターゲット) で、管理範囲を選択して、この設定が適用するアカウントとリージョンを決定します。
3. [Instance profile options] (インスタンスプロファイルオプション) で、[Add required IAM policies to existing instance profiles attached to your instances] (インスタンスに添付済み既存のインスタンスプロファイルに必要な IAM ポリシーを追加する) を選択します。
[Create] (作成) を選択します。

インスタンスが Systems Manager の関連付けをサポートしていることを確認するには、「AWS Systems Manager ユーザーガイド」の「Systems Manager の前提条件」を参照してください。

[SSM.2] Systems Manager によって管理されるすべての EC2 インスタンスは、パッチ適用要件に準拠している必要があります。

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

重要度: 高

リソースタイプ : AWS::SSM::PatchCompliance

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

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、インスタンスへのパッチインストール後、Systems Manager パッチコンプライアンスのコンプライアンスステータスが、COMPLIANT と NON_COMPLIANT のどちらであるかをチェックします。このコントロールは、Systems Manager Patch Manager によって管理されているインスタンスのみをチェックします。

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

注記

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

アフリカ (ケープタウン)
ヨーロッパ (ミラノ)
中東 (バーレーン)
中東 (アラブ首長国連邦)

修正

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

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

AWS Systems Manager コンソール (https://console.aws.amazon.com/systems-manager/) を開きます。
[Node Management] (ノード管理) で、[Run Command] (コマンドを実行する) を選択し、[Run command] (コマンドを実行する) を選択します。
AWS-RunPatchBaseline の横にあるボタンを選択します。
[Operation] (オペレーション) を [Install] (インストール) に変更します。
[Choose instances manually] (インスタンスを手動で選択する) を選択し、非準拠のインスタンスを選択します。
ページの最下部で [Run] (実行) を選択します。
コマンドの完了後に、パッチを適用したインスタンスの新しいコンプライアンスステータスをモニタリングするには、ナビゲーションペインで [Compliance] (コンプライアンス) を選択します。

Systems Manager のドキュメントを使用してマネージドインスタンスにパッチを適用する詳細については、「AWS Systems Manager ユーザーガイド」の「インスタンスにパッチを適用する SSM ドキュメントについて」および「Systems Manager Run Command を使用してコマンドを実行」を参照してください。

[SSM.3] Systems Manager によって管理されるインスタンスの関連付けコンプライアンスステータスは、COMPLIANT である必要があります

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

重要度: 低

リソースタイプ : AWS::SSM::AssociationCompliance

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

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、インスタンスで関連付けが実行された後、AWS Systems Manager 関連付けのコンプライアンスのステータスが COMPLIANT または NON_COMPLIANT であるかどうかをチェックします。関連付けのコンプライアンスステータスが COMPLIANT の場合、コントロールは成功します。

State Manager の関連付けは、マネージドインスタンスに割り当てられる設定です。この設定では、インスタンスで維持する状態を定義します。例えば、関連付けでは、アンチウイルスソフトウェアをインスタンス上にインストールして実行する必要があること、または特定のポートを閉じる必要があることを指定できます。

State Manager の関連付けを 1 つまたは複数作成することで、コンプライアンスステータス情報をすぐに表示できるようになります。コンプライアンスステータスは、コンソールで、または AWS CLI マンドや対応する Systems Manager API アクションへの応答で表示することができます。関連付けでは、設定コンプライアンスはコンプライアンスステータスを表示します (Compliant または Non-compliant)。また、関連付けに割り当てられた Critical または Medium などの重要度レベルを表示します。

State Manager 関連付けのコンプライアンスの詳細については、「AWS Systems Manager ユーザーガイド」の「State Manager 関連付けのコンプライアンスについて」を参照してください。

注記

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

アフリカ (ケープタウン)
ヨーロッパ (ミラノ)
中東 (アラブ首長国連邦)

修正

失敗した関連付けは、ターゲットや SSM ドキュメント名など、さまざまなものに関連している可能性があります。この問題を修正するには、まず関連付けを特定して調査する必要があります。その後、関連付けを更新して、特定の問題を修正できます。

関連付けを編集して、新しい名前やスケジュール、重要度レベル、ターゲットを指定できます。関連付けを編集した後、AWS Systems Manager で新しいバージョンが作成されます。

失敗した関連付けを調査して更新するには

AWS Systems Manager コンソール (https://console.aws.amazon.com/systems-manager/) を開きます。
ナビゲーションペインで、[Node Management] (ノード管理) の [Fleet Manager] (フリートマネージャー) を選択します。
[Association status] (関連付けのステータス) が [Failed] (失敗) のインスタンス ID を選択します。
[View details] (詳細を表示する) を選択します。
[Association] (関連付け) を選択します。
[Association status] (関連付けのステータス) が [Failed] (失敗) の関連付けの名前を書き留めておきます。これはユーザーが調査する必要のある関連付けです。関連付けの名前は、次のステップで使用する必要があります。
ナビゲーションペインで、[Node Management] (ノード管理) の [State Manager] (ステートマネージャー) を選択します。関連付け名を検索し、関連付けを選択します。
問題を特定した後、失敗した関連付けを編集して問題を修正します。関連付けの編集方法の詳細については、「関連付けを編集する」を参照してください。

State Manager の関連付けの作成と編集の詳細については、「AWS Systems Manager ユーザーガイド」の「Systems Manager の関連付けの使用」を参照してください。

[SSM.4] SSM ドキュメントはパブリックにしないでください

カテゴリ: 保護 > セキュアなネットワーク設定 > パブリックアクセス不可のリソース

重要度: 非常事態

リソースタイプ : AWS::SSM::Document

AWS Config ルール : ssm-document-not-public

スケジュールタイプ: 定期的

パラメータ : なし

このコントロールは、アカウントによって所有されている AWS Systems Manager ドキュメントがパブリックかどうかをチェックします。所有者 Self の SSM ドキュメントがパブリックの場合、このコントロールは失敗します。

パブリックの SSM ドキュメントは、ドキュメントへの意図しないアクセスを許可する場合があります。パブリック SSM ドキュメントは、アカウント、リソース、および内部プロセスに関する貴重な情報を公開する可能性があります。

ユースケースでパブリック共有を有効にする必要がある場合を除き、Security Hub では、Self が所有する Systems Manager ドキュメントのパブリック共有のブロック設定をオンにすることを推奨します。

注記

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

AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

SSM ドキュメントへのパブリックアクセスの無効化の詳細については、「AWS Systems Manager ユーザーガイド」の「共有 SSM ドキュメントの許可を変更する」および「共有 SSM ドキュメントのベストプラクティス」を参照してください。

[WAF.1] AWS WAF クラシックグローバルウェブ ACL ログ記録を有効にする必要があります

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

重要度: 中

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

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

スケジュールタイプ: 定期的

パラメータ : なし

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

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

注記

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

米国東部 (オハイオ)
米国西部 (北カリフォルニア)
米国西部 (オレゴン)
アフリカ (ケープタウン)
アジアパシフィック (香港)
アジアパシフィック (ムンバイ)
アジアパシフィック (大阪)
アジアパシフィック (ソウル)
アジアパシフィック (シンガポール)
アジアパシフィック (シドニー)
アジアパシフィック (東京)
カナダ (中部)
中国 (北京)
中国 (寧夏)
ヨーロッパ (フランクフルト)
ヨーロッパ (アイルランド)
欧州 (ロンドン)
ヨーロッパ (ミラノ)
ヨーロッパ (パリ)
ヨーロッパ (ストックホルム)
中東 (バーレーン)
中東 (アラブ首長国連邦)
南米 (サンパウロ)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

Kinesis Data Firehose コンソールからウェブ ACL のログ記録を有効にすることができます。

ウェブ ACL でログ記録を有効にするには

Kinesis Data Firehose コンソール (https://console.aws.amazon.com/firehose/) を開きます。
Kinesis Data Firehose 配信ストリームを作成します。

名前の先頭には、プレフィックス aws-waf-logs- を付ける必要があります。例えば、aws-waf-logs-us-east-2-analytics です。

PUT ソースを使用して、ユーザーが操作するリージョンで、Kinesis Data Firehose 配信ストリームを作成します。Amazon CloudFront のログをキャプチャする場合は、米国東部 (バージニア北部) に配信ストリームを作成します。詳細については、「Amazon Kinesis Data Firehose 開発者ガイド」の「Amazon Kinesis Data Firehose 配信ストリームの作成」を参照してください。
[Services] (サービス) で、WAF & Shield を選択します。[Switch to AWS WAF Classic] (WAF クラシックに切り替える) を選択します。
[Filter] (フィルター) で、[Global (CloudFront)] (グローバル (CloudFront)) を選択します。
ログ記録を有効にするウェブ ACL を選択します。
[Logging] (ログ記録) で、[Enable logging] (ログの有効化) を選択します。
作成した Kinesis Data Firehose 配信ストリームを選択します。aws-waf-logs- で始まる名前の配信ストリームを選択する必要があります。
[Enable logging] (ログの有効化) を選択します。

[WAF.2] WAF リージョンルールには、1 つ以上の条件が必要です

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

重要度: 中

リソースタイプ : AWS::WAFRegional::Rule

AWS Config ルール : waf-regional-rule-not-empty

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、AWS WAF リージョンルールに 1 つ以上の条件があるかどうかをチェックします。ルールに条件が 1 つもない場合、このコントロールは失敗します。

WAF リージョンルールには、複数の条件を含めることが可能です。このルールの条件によってトラフィックの検査が許可され、定義されたアクション (許可、ブロック、カウント) が実行されます。条件が 1 つもないと、トラフィックは検査なしで通過します。条件がないにもかかわらず、許可、ブロック、カウントを示す名前またはタグが付いている WAF リージョンルールは、上記いずれかのアクションが行われているという誤解を生む可能性があります。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

空のルールに条件を追加する方法については、には、「AWS WAF デベロッパーガイド」の「ルールの条件の追加と削除」を参照してください。

[WAF.3] WAF リージョンルールグループには、1 つ以上の条件が必要です

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

重要度: 中

リソースタイプ : AWS::WAFRegional::RuleGroup

AWS Config ルール : waf-regional-rulegroup-not-empty

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、AWS WAF リージョンルールグループに 1 つ以上のルールがあるかどうかをチェックします。ルールグループにルールが 1 つもない場合、このコントロールは失敗します。

WAF リージョンルールグループには、複数のルールを含めることができます。このルールの条件によってトラフィックの検査が許可され、定義されたアクション (許可、ブロック、カウント) が実行されます。ルールが 1 つもないと、トラフィックは検査なしで通過します。ルールはないにもかかわらず、許可、ブロック、カウントを示す名前またはタグが付いている WAF リージョンルールグループは、上記いずれかのアクションが行われているという誤解を生む可能性があります。

注記

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

アジアパシフィック (ジャカルタ)
アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

空のルールグループにルールとルール条件を追加する方法については、「AWS WAF デベロッパーガイド」の「AWS WAF Classic ルールグループからルールの追加と削除」および「ルールの条件の追加と削除」を参照してください。

[WAF.4] WAF Classic リージョンウェブ ACL には、1 つ以上のルールまたはルールグループが必要です

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

重要度: 中

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

AWS Config ルール : waf-regional-webacl-not-empty

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、AWS WAF Classic Regional ウェブ ACL に WAF ルールまたは　WAF ルールグループが含まれているかどうかをチェックします。ウェブ ACL に WAF ルールまたはルールグループが含まれていない場合、このコントロールは失敗します。

WAF リージョンウェブ ACL には、ウェブリクエストを検査および制御する、ルールおよびルールグループのコレクションを含めることができます。ウェブ ACL が空の場合、ウェブトラフィックは、デフォルトのアクションに応じて WAF による検出または処理なしに通過できます。

注記

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

アジアパシフィック (ジャカルタ)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

ルールまたはルールグループを空のクラシックリージョンウェブ ACL に追加するには、「AWS WAF デベロッパーガイド」の「ウェブ ACL の編集」を参照してください。

[WAF.6] WAF グローバルルールには、1 つ以上の条件が必要です

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

重要度: 中

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

AWS Config ルール : waf-global-rule-not-empty

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、AWS WAF グローバルルールに条件が含まれているかどうかをチェックします。ルールに条件が 1 つもない場合、このコントロールは失敗します。

WAF グローバルルールには、複数の条件を含めることが可能です。ルールの条件によってトラフィックの検査が許可され、定義されたアクション (許可、ブロック、カウント) が実行されます。条件が 1 つもないと、トラフィックは検査なしで通過します。条件はないにもかかわらず、許可、ブロック、カウントを示す名前またはタグが付いている WAF グローバルルールは、上記いずれかのアクションが行われているという誤解を生む可能性があります。

注記

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

修正

ルールの作成方法および条件の追加方法については、「AWS WAF デベロッパーガイド」の「ルールの作成と条件の追加」を参照してください。

[WAF.7] WAF グローバルルールグループには、1 つ以上の条件が必要です

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

重要度: 中

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

AWS Config ルール : waf-global-rulegroup-not-empty

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、AWS WAF グローバルルールグループに 1 つ以上のルールがあるかどうかをチェックします。ルールグループにルールが 1 つもない場合、このコントロールは失敗します。

WAF グローバルルールグループには、複数のルールを含めることができます。このルールの条件によってトラフィックの検査が許可され、定義されたアクション (許可、ブロック、カウント) が実行されます。ルールが 1 つもないと、トラフィックは検査なしで通過します。ルールはないにもかかわらず、許可、ブロック、カウントを示す名前またはタグが付いている WAF グローバルルールグループは、上記いずれかのアクションが行われているという誤解を生む可能性があります。

注記

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

修正

ルールグループにルールを追加する方法については、「AWS WAF デベロッパーガイド」の「AWS WAF Classic ルールグループの作成」を参照してください。

[WAF.8] WAF グローバルウェブ ACL には、1 つ以上のルールまたはルールグループが必要です

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

重要度: 中

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

AWS Config ルール : waf-global-webacl-not-empty

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、AWS WAF グローバルウェブ ACL に、1 つ以上の WAF ルールまたは WAF ルールグループが含まれているかどうかをチェックします。ウェブ ACL に WAF ルールまたはルールグループが含まれていない場合、このコントロールは失敗します。

WAF グローバルウェブ ACL には、ウェブリクエストを検査および制御するルールおよびルールグループのコレクションを含めることができます。ウェブ ACL が空の場合、ウェブトラフィックは、デフォルトのアクションに応じて WAF による検出または処理なしに通過できます。

注記

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

修正

空のウェブ ACL にルールまたはルールグループを追加するには

https://console.aws.amazon.com/wafv2/ で AWS WAF コンソールを開きます。
ナビゲーションペインで [Switch to AWS WAF Classic] ( Classic に切り替え) を選択し、次に [Web ACLs] (ウェブ ACL) を選択します。
[Filter] (フィルター) で [Global (CloudFront)] (グローバル (CloudFront)) を選択します。
空のウェブ ACL の名前を選択します。
[Rules] (ルール) を選択し、[Edit web ACL] (ウェブ ACl を編集) を選択します。
[Rules] (ルール) で、ルールまたはルールグループを選択し、[Add rule to web ACL] (ルールをウェブ ACL に追加) を選択します。
ウェブ ACL に複数のルールまたはルールグループを追加する場合は、この時点でウェブ ACL 内のルールの順序を変更できます。
[Update] (更新) を選択します。

[WAF.10] WAFV2 ウェブ ACL には、1 つ以上のルールまたはルールグループが必要です

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

重要度: 中

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

AWS Config ルール : wafv2-webacl-not-empty

スケジュールタイプ: 変更がトリガーされた場合

パラメータ : なし

このコントロールは、WAFV2 ウェブアクセスコントロールリスト (ウェブ ACL) に、1 つ以上の WAF ルールまたは WAF ルールグループが含まれているかどうかをチェックします。ウェブ ACL に WAF ルールまたはルールグループが含まれていない場合、このコントロールは失敗します。

ウェブ ACL を使用すると、保護されたリソースが応答するすべての HTTP(S) ウェブリクエストをきめ細かく制御できます。ウェブ ACL には、ウェブリクエストを検査および制御するルールおよびルールグループのコレクションを含める必要があります。ウェブ ACL が空の場合、ウェブトラフィックは、デフォルトのアクションに応じて WAF による検出または処理なしに通過できます。

注記

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

アジアパシフィック (ジャカルタ)
アジアパシフィック (大阪)
中国 (北京)
中国 (寧夏)
中東 (アラブ首長国連邦)
AWS GovCloud (米国東部)
AWS GovCloud (米国西部)

修正

ルールまたはルールグループを空の WAFV2 ウェブ ACL に追加するには、「AWS WAF デベロッパーガイド」の「ウェブ ACL の編集」を参照してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

必要な AWS Config リソース

コントロールのカテゴリ

AWS Foundational Security Best Practices コントロール

サービス別に分類されたコントロール

[Account.1] AWS アカウント について、セキュリティの連絡先情報を提供する必要があります

修正

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

修正

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

修正

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

修正

[APIGateway.3] API Gateway REST API ステージでは、AWS X-Ray トレースを有効にする必要があります

修正

[APIGateway.4] API Gateway は、AWS WAF ウェブ ACL に関連付けられている必要があります

修正

[APIGateway.5] API Gateway REST API のキャッシュデータは、保管中に暗号化する必要があります

修正

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

[APIGateway.8] API Gateway ルートには認証タイプを指定する必要があります

修正

[APIGateway.9] API Gateway V2 ステージにアクセスロギングを設定する必要があります

修正

[AutoScaling.1] Classic Load Balancer に関連付けられた Auto Scaling グループは、ロードバランサーのヘルスチェックを使用する必要があります

修正

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

[AutoScaling.2] Amazon EC2 Auto Scaling グループは、複数のアベイラビリティーゾーンをカバーする必要があります

修正

[AutoScaling.3] Auto Scaling グループは、EC2 インスタンスを、Instance Metadata Service Version 2 (IMDSv2) を必要とするように設定する必要があります

修正

[AutoScaling.4] Auto Scaling グループの起動設定では、メタデータ応答ホップ制限が 1 を越えることはできません

修正

[Autoscaling.5] Auto Scaling グループの起動設定を使用して起動した Amazon EC2 インスタンスは、パブリック IP アドレスを含みません

修正

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

[AutoScaling.6] Auto Scaling グループは、複数のアベイラビリティーゾーンで複数のインスタンスタイプを使用する必要があります

修正

[Auto Scaling.9] EC2 Auto Scaling グループは EC2 起動テンプレートを使用する必要があります

修正

[CloudFormation.1] CloudFormation スタックは、Simple Notification Service (SNS) と統合させる必要があります

修正

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

修正

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

修正

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

修正

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

修正

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

修正

[CloudFront.6] CloudFront ディストリビューションでは、AWS WAF を有効にする必要があります

修正

[CloudFront.7] CloudFront ディストリビューションでは、カスタム SSL/TLS 証明書を使用する必要があります

修正

[CloudFront.8] CloudFront ディストリビューションでは、SNI を使用して HTTPS リクエストを処理する必要があります

修正

[CloudFront.9] CloudFront ディストリビューションでは、カスタムオリジンへのトラフィックを暗号化する必要があります

修正

[CloudFront.10] CloudFront ディストリビューションは、エッジロケーションとカスタムオリジン間に非推奨の SSL プロトコルを使用しないでください

修正

[CloudFront.12] CloudFront ディストリビューションは、存在しない S3 オリジンをポイントしない必要があります。

修正

[CloudTrail.1] CloudTrail を有効にして、少なくとも 1 つのマルチリージョンの追跡で、読み取りと書き込みの管理イベントを含めた設定をする必要があります。

修正

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

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

[CloudTrail.2] CloudTrail は、保管中の暗号化を有効にする必要があります

修正

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

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

修正

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

[CloudTrail.5] CloudTrail 追跡が Amazon CloudWatch Logs と確実に統合されていることを確認します

修正

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

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

修正

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

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

修正

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

[Account.1] AWS アカウントについて、セキュリティの連絡先情報を提供する必要があります

[AutoScaling.4] Auto Scaling グループの起動設定では、メタデータ応答ホップ制限が `1` を越えることはできません