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

# Security Hub CSPM のコントロールリファレンス
<a name="securityhub-controls-reference"></a>

このコントロールリファレンスは、利用可能な AWS Security Hub CSPM コントロールの表と、各コントロールに関する詳細情報へのリンクを提供します。テーブルでは、コントロールはコントロール ID によってアルファベット順にリストされています。Security Hub CSPM でアクティブに使用されているコントロールのみがここに含まれています。廃止されたコントロールは、表から除外されます。

このテーブルには、各コントロールの以下の情報が表示されます。
+ **セキュリティコントロール ID** – この ID は標準に適用され、コントロールに関連する AWS のサービス とリソースを示します。Security Hub CSPM コンソールには、アカウントで [[統合されたコントロールの検出結果]](controls-findings-create-update.md#consolidated-control-findings) が有効か無効かに関係なく、セキュリティコントロール ID が表示されます。ただし、Security Hub CSPM の検出結果がセキュリティコントロール ID を参照するのは、アカウントで [統合されたコントロールの検出結果] が有効になっている場合のみです。アカウントで [統合されたコントロールの検出結果] が無効になっている場合、一部のコントロール ID はコントロールの検出結果に含まれる標準によって異なります。標準固有のコントロール ID をセキュリティコントロール ID にマッピングする方法については、「[統合がコントロール ID とタイトルに与える影響](asff-changes-consolidation.md#securityhub-findings-format-changes-ids-titles)」を参照してください。

  セキュリティコントロールの[自動化](automations.md)を設定するときは、タイトルや説明ではなく、コントロール ID に基づいてフィルタリングすることをお勧めします。Security Hub CSPM はコントロールのタイトルや説明を更新することがありますが、コントロール ID は変わりません。

  コントロール ID は数字が飛ばされることがあります。これらは将来のコントロール用のプレースホルダーです。
+ **セキュリティコントロールタイトル** — このタイトルはあらゆる標準に適用されます。Security Hub CSPM コンソールには、アカウントで [統合されたコントロールの検出結果] が有効か無効かに関係なく、セキュリティコントロールタイトルが表示されます。ただし、Security Hub CSPM 検出結果がセキュリティコントロールタイトルを参照するのは、アカウントで [統合されたコントロールの検出結果] が有効になっている場合のみです。アカウントで [統合されたコントロールの検出結果] が無効になっている場合、一部のコントロールタイトルはコントロールの検出結果に含まれる標準によって異なります。標準固有のコントロール ID をセキュリティコントロール ID にマッピングする方法については、「[統合がコントロール ID とタイトルに与える影響](asff-changes-consolidation.md#securityhub-findings-format-changes-ids-titles)」を参照してください。
+ **適用される標準** — コントロールが適用される標準を示します。コントロールを選択して、サードパーティのコンプライアンスフレームワークにおける特定の要件を確認します。
+ **重要度** — コントロールの重要度は、セキュリティの観点からその重要性を示します。Security Hub CSPM がコントロールの重要度を決定する方法の詳細については、「[コントロールの検出結果の重要度](controls-findings-create-update.md#control-findings-severity)」を参照してください。
+ **カスタムパラメータをサポート** — コントロールが 1 つ以上のパラメータのカスタム値をサポートしているかどうかを示します。コントロールを選択して、パラメータの詳細を確認します。詳細については、「[Security Hub CSPM のコントロールパラメータについて](custom-control-parameters.md)」を参照してください。
+ **スケジュールタイプ** — コントロールがいつ評価されるかを示します。詳細については、「[セキュリティチェックの実行スケジュール](securityhub-standards-schedule.md)」を参照してください。

コントロールを選択して、追加の詳細を確認します。コントロールは、セキュリティコントロール ID によってアルファベット順に一覧表示されます。


| セキュリティコントロール ID | セキュリティコントロールのタイトル | 適用される標準 | 緊急度 | カスタムパラメータをサポート | スケジュールタイプ | 
| --- | --- | --- | --- | --- | --- | 
| [Account.1](account-controls.md#account-1)  | のセキュリティ連絡先情報は、 に提供する必要があります。 AWS アカウント  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、 AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  | 中  | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  | 定期的  | 
|  [Account.2](account-controls.md#account-2)  |  AWS アカウント は AWS Organizations 組織の一部である必要があります  |  NIST SP 800-53 Rev. 5  |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [ACM.1](acm-controls.md#acm-1)  |  インポートされ ACM によって発行された証明書は、一定期間後に更新する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2、PCI DSS v4.0.1 |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  変更によるトリガーと定期的なトリガー  | 
|  [ACM.2](acm-controls.md#acm-2)  |  ACM が管理する RSA 証明書は、少なくとも 2,048 ビットのキーの長さを使用する必要があります  | AWS Foundational Security Best Practices v1.0.0、PCI DSS v4.0.1 |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ACM.3](acm-controls.md#acm-3)  | ACM 証明書にはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Amplify.1](amplify-controls.md#amplify-1)  | Amplify アプリにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Amplify.2](amplify-controls.md#amplify-2)  | Amplify ブランチにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [APIGateway.1](apigateway-controls.md#apigateway-1)  |  API Gateway REST および WebSocket API 実行ログ記録を有効にする必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  変更によってトリガーされる  | 
|  [APIGateway.2](apigateway-controls.md#apigateway-2)  |  API Gateway REST API ステージでは、バックエンド認証に SSL 証明書を使用するように設定する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [APIGateway.3](apigateway-controls.md#apigateway-3)  |  API Gateway REST API ステージでは、 AWS X-Ray トレースを有効にする必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [APIGateway.4](apigateway-controls.md#apigateway-4)  |  API Gateway は、WAF ウェブ ACL に関連付けられている必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [APIGateway.5](apigateway-controls.md#apigateway-5)  |  API Gateway REST API のキャッシュデータは、保管中に暗号化する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [APIGateway.8](apigateway-controls.md#apigateway-8)  |  API Gateway ルートには認可タイプを指定する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  定期的  | 
|  [APIGateway.9](apigateway-controls.md#apigateway-9)  |  API Gateway V2 ステージにアクセスログ記録を設定する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [APIGateway.10](apigateway-controls.md#apigateway-10)  |  API Gateway V2 統合では、プライベート接続に HTTPS を使用する必要があります  |  AWS 基本的なセキュリティのベストプラクティス v1.0.0  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [AppConfig.1](appconfig-controls.md#appconfig-1)  | AWS AppConfig アプリケーションにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [AppConfig.2](appconfig-controls.md#appconfig-2)  | AWS AppConfig 設定プロファイルにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [AppConfig.3](appconfig-controls.md#appconfig-3)  | AWS AppConfig 環境にはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [AppConfig.4](appconfig-controls.md#appconfig-4)  | AWS AppConfig 拡張機能の関連付けにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [AppFlow.1](appflow-controls.md#appflow-1)  | Amazon AppFlow フローにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [AppRunner.1](apprunner-controls.md#apprunner-1)  | App Runner サービスにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [AppRunner.2](apprunner-controls.md#apprunner-2)  | App Runner VPC コネクタにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [AppSync.2](appsync-controls.md#appsync-2)  |  AWS AppSync ではフィールドレベルのログ記録が有効になっている必要があります  |  AWS Foundational Security Best Practices v1.0.0、PCI DSS v4.0.1 |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  変更によってトリガーされる  | 
|  [AppSync.4](appsync-controls.md#appsync-4)  | AWS AppSync GraphQL APIsタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [AppSync.5](appsync-controls.md#appsync-5)  |  AWS AppSync GraphQL APIsは API キーで認証しないでください  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Athena.2](athena-controls.md#athena-2)  | Athena データカタログにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Athena.3](athena-controls.md#athena-3)  | Athena ワークグループにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Athena.4](athena-controls.md#athena-4)  | Athena ワークグループではログ記録が有効になっている必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [AutoScaling.1](autoscaling-controls.md#autoscaling-1)  | ロードバランサーに関連付けられた Auto Scaling グループは、ELB のヘルスチェックを使用する必要があります | AWS Foundational Security Best Practices、PCI DSS v3.2.1、NIST SP 800-53 Rev. 5 | 低 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [AutoScaling.2](autoscaling-controls.md#autoscaling-2)  |  Amazon EC2 Auto Scaling グループは、複数のアベイラビリティーゾーンをカバーする必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  変更によってトリガーされる  | 
|  [AutoScaling.3](autoscaling-controls.md#autoscaling-3)  |  Auto Scaling グループの起動設定は、EC2 インスタンスを、インスタンスメタデータサービスバージョン 2 (IMDSv2) を必要とするように設定する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Autoscaling.5](autoscaling-controls.md#autoscaling-5)  |  Auto Scaling グループの起動設定を使用して起動した Amazon EC2 インスタンスは、パブリック IP アドレスを含みません  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [AutoScaling.6](autoscaling-controls.md#autoscaling-6)  |  Auto Scaling グループは、複数のアベイラビリティーゾーンで複数のインスタンスタイプを使用する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [AutoScaling.9](autoscaling-controls.md#autoscaling-9)  |  EC2 Auto Scaling グループは EC2 起動テンプレートを使用する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [AutoScaling.10](autoscaling-controls.md#autoscaling-10)  | EC2 Auto Scaling グループにタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Backup.1](backup-controls.md#backup-1)  |  AWS Backup リカバリポイントは保管時に暗号化する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Backup.2](backup-controls.md#backup-2)  | AWS Backup 復旧ポイントにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Backup.3](backup-controls.md#backup-3)  | AWS Backup ボールトにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Backup.4](backup-controls.md#backup-4)  | AWS Backup レポートプランにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Backup.5](backup-controls.md#backup-5)  | AWS Backup バックアッププランにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [バッチ.1](batch-controls.md#batch-1)  | バッチジョブキューにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [バッチ.2](batch-controls.md#batch-2)  | バッチスケジューリングポリシーにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [バッチ.3](batch-controls.md#batch-3)  | バッチコンピューティング環境にはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [バッチ.4](batch-controls.md#batch-4)  | マネージドバッチコンピューティング環境のコンピューティングリソースプロパティにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [CloudFormation.2](cloudformation-controls.md#cloudformation-2)  | CloudFormation スタックにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [CloudFormation.3](cloudformation-controls.md#cloudformation-3)  | CloudFormation スタックで終了保護を有効にする必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [CloudFormation.4](cloudformation-controls.md#cloudformation-4)  | CloudFormation スタックにはサービスロールが関連付けられている必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [CloudFront.1](cloudfront-controls.md#cloudfront-1)  | CloudFront ディストリビューションでは、デフォルトのルートオブジェクトが設定されている必要があります | AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [CloudFront.3](cloudfront-controls.md#cloudfront-3)  |  CloudFront ディストリビューションでは、転送中に暗号化が必要となります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [CloudFront.4](cloudfront-controls.md#cloudfront-4)  |  CloudFront ディストリビューションでは、オリジンフェイルオーバーが設定されている必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [CloudFront.5](cloudfront-controls.md#cloudfront-5)  |  CloudFront ディストリビューションでは、ログ記録を有効にする必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [CloudFront.6](cloudfront-controls.md#cloudfront-6)  |  CloudFront ディストリビューションでは、WAF を有効にする必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [CloudFront.7](cloudfront-controls.md#cloudfront-7)  |  CloudFront ディストリビューションでは、カスタム SSL/TLS 証明書を使用する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2  | 低 |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [CloudFront.8](cloudfront-controls.md#cloudfront-8)  |  CloudFront ディストリビューションでは、SNI を使用して HTTPS リクエストを処理する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [CloudFront.9](cloudfront-controls.md#cloudfront-9)  |  CloudFront ディストリビューションでは、カスタムオリジンへのトラフィックを暗号化する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [CloudFront.10](cloudfront-controls.md#cloudfront-10)  |  CloudFront ディストリビューションは、エッジロケーションとカスタムオリジン間に非推奨の SSL プロトコルを使用しないでください  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [CloudFront.12](cloudfront-controls.md#cloudfront-12)  |  CloudFront ディストリビューションは、存在しない S3 オリジンをポイントしない必要があります。 |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [CloudFront.13](cloudfront-controls.md#cloudfront-13)  |  CloudFront ディストリビューションはオリジンアクセスコントロールを使用する必要があります  |  AWS 基本的なセキュリティのベストプラクティス v1.0.0  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [CloudFront.14](cloudfront-controls.md#cloudfront-14)  | CloudFront ディストリビューションにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [CloudFront.15](cloudfront-controls.md#cloudfront-15)  | CloudFront ディストリビューションは、推奨される TLS セキュリティポリシーを使用する必要があります | AWS 基本的なセキュリティのベストプラクティス v1.0.0 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [CloudFront.16](cloudfront-controls.md#cloudfront-16)  | CloudFront ディストリビューションは Lambda 関数 URL オリジンのオリジンアクセスコントロールを使用する必要があります | AWS 基本的なセキュリティのベストプラクティス v1.0.0 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [CloudFront.17](cloudfront-controls.md#cloudfront-17)  | CloudFront ディストリビューションは、署名付き URLsと Cookie に信頼されたキーグループを使用する必要があります | AWS 基本的なセキュリティのベストプラクティス v1.0.0 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [CloudTrail.1](cloudtrail-controls.md#cloudtrail-1)  | CloudTrail を有効にして、少なくとも 1 つのマルチリージョンの追跡で、読み取りと書き込みの管理イベントを含めた設定をする必要があります | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、 AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [CloudTrail.2](cloudtrail-controls.md#cloudtrail-2)  |  CloudTrail は保管時の暗号化を有効にする必要があります  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.2.0、CIS AWS Foundations Benchmark v1.4.0 AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2、PCI DSS v3.2.1、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [CloudTrail.3](cloudtrail-controls.md#cloudtrail-3)  | 少なくとも 1 つの CloudTrail 証跡を有効にする必要があります | NIST SP 800-171 Rev. 2、PCI DSS v4.0.1、PCI DSS v3.2.1 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [CloudTrail.4](cloudtrail-controls.md#cloudtrail-4)  |  CloudTrail ログファイルの検証を有効にする必要があります  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、 AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2、PCI DSS v4.0.1、PCI DSS v3.2.1 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [CloudTrail.5](cloudtrail-controls.md#cloudtrail-5)  |  CloudTrail 証跡は、Amazon CloudWatch Logs と統合する必要があります  | CIS AWS Foundations Benchmark v1.2.0、CIS AWS Foundations Benchmark v1.4.0、 AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、PCI DSS v3.2.1、PCI DSS v4.0.1 | 中 |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [CloudTrail.6](cloudtrail-controls.md#cloudtrail-6)  |  CloudTrail ログの保存に使用されるS3 バケットが一般公開されていないことを確認します  |  CIS AWS Foundations Benchmark v1.2.0、CIS AWS Foundations Benchmark v1.4.0、PCI DSS v4.0.1 |  重大  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によるトリガーと定期的なトリガー  | 
|  [CloudTrail.7](cloudtrail-controls.md#cloudtrail-7)  |  S3 バケットアクセスログ記録が CloudTrail S3 バケットで有効になっていることを確認します  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.2.0、CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v3.0.0、PCI DSS v4.0.1 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [CloudTrail.9](cloudtrail-controls.md#cloudtrail-9)  | CloudTrail 証跡にはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [CloudTrail.10](cloudtrail-controls.md#cloudtrail-10)  | CloudTrail Lake イベントデータストアはカスタマーマネージドで暗号化する必要があります AWS KMS keys | NIST SP 800-53 Rev. 5 | 中 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 定期的 | 
|  [CloudWatch.1](cloudwatch-controls.md#cloudwatch-1)  |  「ルート」ユーザーの使用に対するログメトリックフィルターとアラームが存在する必要があります  | CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、NIST SP 800-171 Rev. 2、PCI DSS v3.2.1 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [CloudWatch.2](cloudwatch-controls.md#cloudwatch-2)  |  不正な API コールに対するログメトリクスフィルターとアラームが存在することを確認する  | CIS AWS Foundations Benchmark v1.2.0、NIST SP 800-171 Rev. 2 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [CloudWatch.3](cloudwatch-controls.md#cloudwatch-3)  |  MFA を使用しないマネジメントコンソールサインインに対してログメトリクスフィルターとアラームが存在することを確認します  | CIS AWS Foundations Benchmark v1.2.0  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [CloudWatch.4](cloudwatch-controls.md#cloudwatch-4)  |  MFA なしの IAM ポリシーの変更に対してログメトリクスフィルターとアラームが存在することを確認します。 | CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、NIST SP 800-171 Rev. 2 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [CloudWatch.5](cloudwatch-controls.md#cloudwatch-5)  |  CloudTrail の設定の変更に対するログメトリクスフィルターとアラームが存在することを確認します。 | CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、NIST SP 800-171 Rev. 2 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [CloudWatch.6](cloudwatch-controls.md#cloudwatch-6)  |  AWS マネジメントコンソール 認証失敗のログメトリクスフィルターとアラームが存在することを確認する  | CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、NIST SP 800-171 Rev. 2 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [CloudWatch.7](cloudwatch-controls.md#cloudwatch-7)  |  カスタマー作成の CMK の無効化またはスケジュールされた削除に対してログメトリクスフィルターとアラームが存在することを確認します  | CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、NIST SP 800-171 Rev. 2  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [CloudWatch.8](cloudwatch-controls.md#cloudwatch-8)  |  S3 バケットの変更に対してログメトリクスフィルターとアラームが存在することを確認します  | CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、NIST SP 800-171 Rev. 2 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [CloudWatch.9](cloudwatch-controls.md#cloudwatch-9)  |  AWS Config 設定変更のログメトリクスフィルターとアラームが存在することを確認する  | CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、NIST SP 800-171 Rev. 2  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [CloudWatch.10](cloudwatch-controls.md#cloudwatch-10)  |  セキュリティグループの変更に対するメトリクスフィルターとアラームが存在することを確認します  | CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、NIST SP 800-171 Rev. 2 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [CloudWatch.11](cloudwatch-controls.md#cloudwatch-11)  |  ネットワークアクセスコントロールリスト (NACL) への変更に対するログメトリクスとアラームが存在することを確認します  | CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、NIST SP 800-171 Rev. 2  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [CloudWatch.12](cloudwatch-controls.md#cloudwatch-12)  |  ネットワークゲートウェイへの変更に対するログメトリクスとアラームが存在することを確認します  | CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、NIST SP 800-171 Rev. 2 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [CloudWatch.13](cloudwatch-controls.md#cloudwatch-13)  |  ルートテーブルの変更に対してログメトリクスフィルターとアラームが存在することを確認します  | CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、NIST SP 800-171 Rev. 2  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [CloudWatch.14](cloudwatch-controls.md#cloudwatch-14)  |  VPC の変更に対してログメトリクスフィルターとアラームが存在することを確認します  | CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、NIST SP 800-171 Rev. 2 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [CloudWatch.15](cloudwatch-controls.md#cloudwatch-15)  |  CloudWatch アラームには、指定されたアクションが設定されている必要があります  | NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2 |  高い  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  変更によってトリガーされる  | 
|  [CloudWatch.16](cloudwatch-controls.md#cloudwatch-16)  |  CloudWatch ロググループは指定された期間保持する必要があります  |  NIST SP 800-53 Rev. 5  |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  定期的  | 
|  [CloudWatch.17](cloudwatch-controls.md#cloudwatch-17)  |  CloudWatch アラームアクションを有効にする必要があります  |  NIST SP 800-53 Rev. 5  |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [CodeArtifact.1](codeartifact-controls.md#codeartifact-1)  | CodeArtifact リポジトリにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [CodeBuild.1](codebuild-controls.md#codebuild-1)  | CodeBuild Bitbucket のソースリポジトリの URL には機密認証情報を含めないでください | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v3.2.1、PCI DSS v4.0.1 | 重大 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [CodeBuild.2](codebuild-controls.md#codebuild-2)  |  CodeBuild プロジェクト環境変数に、クリアテキストの認証情報を含めるべきでない  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v3.2.1、PCI DSS v4.0.1 |  重大  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [CodeBuild.3](codebuild-controls.md#codebuild-3)  |  CodeBuild S3 ログは暗号化する必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1、 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [CodeBuild.4](codebuild-controls.md#codebuild-4)  |  CodeBuild プロジェクト環境にはログ記録の設定が必要です  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [CodeBuild.7](codebuild-controls.md#codebuild-7)  | CodeBuild レポートグループのエクスポートは保管時に暗号化する必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [CodeGuruProfiler.1](codeguruprofiler-controls.md#codeguruprofiler-1)  | CodeGuru Profiler プロファイリンググループにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [CodeGuruReviewer.1](codegurureviewer-controls.md#codegurureviewer-1)  | CodeGuru Reviewer リポジトリの関連付けにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Cognito.1](cognito-controls.md#cognito-1)  | Cognito ユーザープールでは、標準認証の完全な関数強制モードで脅威保護を有効にする必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Cognito.2](cognito-controls.md#cognito-2)  | Cognito アイデンティティプールは認証されていない ID を許可すべきではありません | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [Cognito.3](cognito-controls.md#cognito-3)  | Cognito ユーザープールのパスワードポリシーには強力な設定が必要です | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Cognito.4](cognito-controls.md#cognito-4)  | Cognito ユーザープールでは、カスタム認証の完全な関数強制モードで脅威保護を有効にする必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [Cognito.5](cognito-controls.md#cognito-5)  | Cognito ユーザープールに対して MFA を有効にする必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [Cognito.6](cognito-controls.md#cognito-6)  | Cognito ユーザープールでは削除保護を有効にする必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [Config.1](config-controls.md#config-1)  | AWS Config を有効にし、サービスにリンクされたロールをリソース記録に使用する必要があります | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、 AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v3.2.1 | 重大 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 定期的 | 
|  [Connect.1](connect-controls.md#connect-1)  | Amazon Connect Customer Profiles オブジェクトタイプにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Connect.2](connect-controls.md#connect-2)  | Amazon Connect インスタンスでは CloudWatch ログ記録が有効になっている必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [DataFirehose.1](datafirehose-controls.md#datafirehose-1)  | Firehose 配信ストリームは保管時に暗号化する必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [DataSync.1](datasync-controls.md#datasync-1)  | DataSync タスクではログ記録が有効になっている必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [DataSync.2](datasync-controls.md#datasync-2)  | DataSync タスクにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Detective.1](detective-controls.md#detective-1)  | 検出動作グラフにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [DMS.1](dms-controls.md#dms-1)  |  Database Migration Service のレプリケーションインスタンスは、パブリックではない必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v3.2.1、PCI DSS v4.0.1 |  重大  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [DMS.2](dms-controls.md#dms-2)  | DMS 証明書にはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [DMS.3](dms-controls.md#dms-3)  | DMS イベントサブスクリプションにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [DMS.4](dms-controls.md#dms-4)  | DMS レプリケーションインスタンスにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [DMS.5](dms-controls.md#dms-5)  | DMS レプリケーションサブネットグループにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [DMS.6](dms-controls.md#dms-6)  |  DMS レプリケーションインスタンスでは、マイナーバージョンの自動アップグレードが有効になっている必要があります。 | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [DMS.7](dms-controls.md#dms-7)  |  ターゲットデータベースの DMS レプリケーションタスクでは、ログ記録が有効になっている必要があります。 | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [DMS.8](dms-controls.md#dms-8)  |  ソースデータベースの DMS レプリケーションタスクでは、ログ記録が有効になっている必要があります。 | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [DMS.9](dms-controls.md#dms-9)  |  DMS エンドポイントは SSL を使用する必要があります。 | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [DMS.10](dms-controls.md#dms-10)  | Neptune データベースの DMS エンドポイントでは、IAM 認証が有効になっている必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [DMS.11](dms-controls.md#dms-11)  | MongoDB の DMS エンドポイントでは、認証メカニズムが有効になっている必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [DMS.12](dms-controls.md#dms-12)  | Redis OSS の DMS エンドポイントでは TLS が有効になっている必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [DMS.13](dms-controls.md#dms-13)  | DMS レプリケーションインスタンスは、複数のアベイラビリティーゾーンを使用するよう設定する必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [DocumentDB.1](documentdb-controls.md#documentdb-1)  |  Amazon DocumentDB クラスターは、保管中に暗号化する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [DocumentDB.2](documentdb-controls.md#documentdb-2)  |  Amazon DocumentDB クラスターには、適切なバックアップ保持期間が必要です  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1  |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  変更によってトリガーされる  | 
|  [DocumentDB.3](documentdb-controls.md#documentdb-3)  |  Amazon DocumentDB 手動クラスタースナップショットはパブリックにできません  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  重大  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [DocumentDB.4](documentdb-controls.md#documentdb-4)  |  Amazon DocumentDB クラスターでは、監査ログを CloudWatch Logs に発行する必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [DocumentDB.5](documentdb-controls.md#documentdb-5)  |  Amazon DocumentDB では、削除保護が有効になっている必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [DocumentDB.6](documentdb-controls.md#documentdb-6)  | Amazon DocumentDB クラスターは、転送中に暗号化する必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [DynamoDB.1](dynamodb-controls.md#dynamodb-1)  |  DynamoDB テーブルは、需要に応じて容量をオートスケーリングする必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  定期的  | 
|  [DynamoDB.2](dynamodb-controls.md#dynamodb-2)  |  DynamoDB テーブルでは、ポイントインタイムリカバリが有効になっている必要があります。 |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [DynamoDB.3](dynamodb-controls.md#dynamodb-3)  |  DynamoDB Accelerator (DAX) クラスターは、保管中に暗号化する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [DynamoDB.4](dynamodb-controls.md#dynamodb-4)  |  DynamoDB テーブルはバックアッププランに含まれている必要があります  |  NIST SP 800-53 Rev. 5  |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  定期的  | 
|  [DynamoDB.5](dynamodb-controls.md#dynamodb-5)  | DynamoDB テーブルにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [DynamoDB.6](dynamodb-controls.md#dynamodb-6)  |  DynamoDB テーブルで、削除保護が有効になっている必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [DynamoDB.7](dynamodb-controls.md#dynamodb-7)  | DynamoDB Accelerator クラスターは、転送中に暗号化する必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [EC2.1](ec2-controls.md#ec2-1)  |  EBS スナップショットをパブリックに復元可能であってはなりません  |  AWS Foundational Security Best Practices v1.0.0、PCI DSS v3.2.1、NIST SP 800-53 Rev. 5  |  重大  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [EC2.2](ec2-controls.md#ec2-2)  |  VPC のデフォルトのセキュリティグループでは、インバウンドトラフィックまたはアウトバウンドトラフィックを許可しないようにする必要があります  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.2.0、 AWS Foundational Security Best Practices v1.0.0、PCI DSS v3.2.1、CIS AWS Foundations Benchmark v1.4.0、NIST SP 800-53 Rev. 5  |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [EC2.3](ec2-controls.md#ec2-3)  |  アタッチされた EBS ボリュームは、保管時に暗号化する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [EC2.4](ec2-controls.md#ec2-4)  |  停止した EC2 インスタンスは、指定した期間後に削除する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  定期的  | 
|  [EC2.6](ec2-controls.md#ec2-6)  |  すべての VPC で VPC フローログ記録を有効にする必要があります  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.2.0、 AWS Foundational Security Best Practices v1.0.0、PCI DSS v3.2.1、CIS AWS Foundations Benchmark v1.4.0、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [EC2.7](ec2-controls.md#ec2-7)  |  EBS のデフォルト暗号化を有効にする必要があります  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、 AWS Foundational Security Best Practices v1.0.0、CIS AWS Foundations Benchmark v1.4.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [EC2.8](ec2-controls.md#ec2-8)  |  EC2 インスタンスは、インスタンスメタデータサービスバージョン 2 (IMDSv2) を使用する必要があります  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、 AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [EC2.9](ec2-controls.md#ec2-9)  |  EC2 インスタンスは、パブリック IPv4 アドレスを未設定にする必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [EC2.10](ec2-controls.md#ec2-10)  |  Amazon EC2 サービス用に作成された VPC エンドポイントを使用するように Amazon EC2 を設定する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [EC2.12](ec2-controls.md#ec2-12)  |  未使用の EC2 EIP を削除する必要があります  |  PCI DSS v3.2.1、NIST SP 800-53 Rev. 5  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [EC2.13](ec2-controls.md#ec2-13)  | セキュリティグループは、0.0.0.0/0 または ::/0 からポート 22 への入力を許可しないようにする必要があります | CIS AWS Foundations Benchmark v1.2.0、PCI DSS v3.2.1、PCI DSS v4.0.1、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によるトリガーと定期的なトリガー | 
|  [EC2.14](ec2-controls.md#ec2-14)  | セキュリティグループは、0.0.0.0/0 または ::/0 からポート 3389 への入力を許可しないようにする必要があります | CIS AWS Foundations Benchmark v1.2.0、PCI DSS v4.0.1 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によるトリガーと定期的なトリガー | 
|  [EC2.15](ec2-controls.md#ec2-15)  |  EC2 サブネットは、パブリック IP アドレスを自動的に割り当てないでください  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1、 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [EC2.16](ec2-controls.md#ec2-16)  |  未使用のネットワークアクセスコントロールリストを削除する必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2、PCI DSS v4.0.1、 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [EC2.17](ec2-controls.md#ec2-17)  |  EC2 インスタンスは複数の ENI を使用しないでください  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [EC2.18](ec2-controls.md#ec2-18)  |  セキュリティグループは、許可されたポートに対して無制限の着信トラフィックのみを許可する必要があります。 |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2  |  高い  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  変更によってトリガーされる  | 
|  [EC2.19](ec2-controls.md#ec2-19)  | セキュリティグループは、リスクの高いポートへの無制限アクセスを許可しないでください | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2 | 重大 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によるトリガーと定期的なトリガー | 
|  [EC2.20](ec2-controls.md#ec2-20)  |  AWS Site-to-Site VPN トンネルが稼働している必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [EC2.21](ec2-controls.md#ec2-21)  |  ネットワーク ACL は、0.0.0.0/0 からポート 22、またはポート 3389 への侵入を許可しないようにする必要があります  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.4.0、 AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [EC2.22](ec2-controls.md#ec2-22)  | 未使用の EC2 セキュリティグループを削除する必要があります |   | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [EC2.23](ec2-controls.md#ec2-23)  |  EC2 Transit Gateway は VPC アタッチメントリクエストを自動的に受け付けないようにする必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [EC2.24](ec2-controls.md#ec2-24)  |  EC2 準仮想化インスタンスタイプは使用しないでください  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [EC2.25](ec2-controls.md#ec2-25)  |  EC2 起動テンプレートはパブリック IP をネットワークインターフェイスに割り当ててはなりません  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [EC2.28](ec2-controls.md#ec2-28)  |  EBS ボリュームはバックアッププランに入っている必要があります  |  NIST SP 800-53 Rev. 5  |  低  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  定期的  | 
|  [EC2.33](ec2-controls.md#ec2-33)  | EC2 Transit Gateway アタッチメントにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.34](ec2-controls.md#ec2-34)  | EC2 Transit Gateway ルートテーブルにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.35](ec2-controls.md#ec2-35)  | EC2 ネットワークインターフェイスにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.36](ec2-controls.md#ec2-36)  | EC2 カスタマーゲートウェイにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.37](ec2-controls.md#ec2-37)  | EC2 Elastic IP アドレスにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.38](ec2-controls.md#ec2-38)  | EC2 インスタンスにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.39](ec2-controls.md#ec2-39)  | EC2 インターネットゲートウェイにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.40](ec2-controls.md#ec2-40)  | EC2 NAT ゲートウェイにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.41](ec2-controls.md#ec2-41)  | EC2 ネットワーク ACL にはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.42](ec2-controls.md#ec2-42)  | EC2 ルートテーブルにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.43](ec2-controls.md#ec2-43)  | EC2 セキュリティグループにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.44](ec2-controls.md#ec2-44)  | EC2 サブネットにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.45](ec2-controls.md#ec2-45)  | EC2 ボリュームにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.46](ec2-controls.md#ec2-46)  | Amazon VPC にはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.47](ec2-controls.md#ec2-47)  | Amazon VPC エンドポイントサービスはタグ付けする必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.48](ec2-controls.md#ec2-48)  | Amazon VPC フローログにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.49](ec2-controls.md#ec2-49)  | Amazon VPC ピアリング接続にはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.50](ec2-controls.md#ec2-50)  | EC2 VPN ゲートウェイにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.51](ec2-controls.md#ec2-51)  |  EC2 Client VPN エンドポイントでは、クライアント接続ログ記録が有効になっている必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2、PCI DSS v4.0.1 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [EC2.52](ec2-controls.md#ec2-52)  | EC2 Transit Gateway にはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.53](ec2-controls.md#ec2-53)  | EC2 セキュリティグループは、0.0.0.0/0 からリモートサーバー管理ポートへの入力を許可しないようにする必要があります。 | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、PCI DSS v4.0.1 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [EC2.54](ec2-controls.md#ec2-54)  | EC2 セキュリティグループは、::/0 からリモートサーバー管理ポートへの入力を許可していないようにする必要があります。 | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、PCI DSS v4.0.1 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [EC2.55](ec2-controls.md#ec2-55)  | VPC は ECR API のインターフェイスエンドポイントで設定する必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 | 中 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 定期的 | 
|  [EC2.56](ec2-controls.md#ec2-56)  | VPC は Docker Registry のインターフェイスエンドポイントで設定する必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 | 中 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 定期的 | 
|  [EC2.57](ec2-controls.md#ec2-57)  | VPC は Systems Manager のインターフェイスエンドポイントで設定する必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 | 中 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 定期的 | 
|  [EC2.58](ec2-controls.md#ec2-58)  | VPC は、Systems Manager Incident Manager Contacts のインターフェイスエンドポイントで設定する必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 | 中 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 定期的 | 
|  [EC2.60](ec2-controls.md#ec2-60)  | VPC は Systems Manager Incident Manager のインターフェイスエンドポイントで設定する必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 | 中 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 定期的 | 
|  [EC2.170](ec2-controls.md#ec2-170)  | EC2 起動テンプレートは、インスタンスメタデータサービスバージョン 2 (IMDSv2) を使用する必要があります | AWS Foundational Security Best Practices、PCI DSS v4.0.1 | 低 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [EC2.171](ec2-controls.md#ec2-171)  | EC2 VPN 接続ではログ記録が有効になっている必要があります | AWS Foundational Security Best Practices、PCI DSS v4.0.1 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [EC2.172](ec2-controls.md#ec2-172)  | EC2 VPC パブリックアクセスのブロック設定はインターネットゲートウェイトラフィックをブロックする必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.173](ec2-controls.md#ec2-173)  | 起動パラメータを含む EC2 スポットフリートリクエストは、アタッチされた EBS ボリュームの暗号化を有効にする必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [EC2.174](ec2-controls.md#ec2-174)  | EC2 DHCP オプションセットにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.175](ec2-controls.md#ec2-175)  | EC2 起動テンプレートにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.176](ec2-controls.md#ec2-176)  | EC2 プレフィックスリストにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.177](ec2-controls.md#ec2-177)  | EC2 トラフィックミラーセッションにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.178](ec2-controls.md#ec2-178)  | EC2 トラフィックミラーフィルターにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.179](ec2-controls.md#ec2-179)  | EC2 トラフィックミラーターゲットにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EC2.180](ec2-controls.md#ec2-180)  | EC2 ネットワークインターフェイスでは、送信元/送信先チェックを有効にする必要があります | AWS 基本的なセキュリティのベストプラクティス v1.0.0 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [EC2.181](ec2-controls.md#ec2-181)  | EC2 起動テンプレートは、アタッチされた EBS ボリュームの暗号化を有効にする必要があります | AWS 基本的なセキュリティのベストプラクティス v1.0.0 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [EC2.182](ec2-controls.md#ec2-182)  | EBS スナップショットはパブリックにアクセスできません | AWS 基本的なセキュリティのベストプラクティス | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [ECR.1](ecr-controls.md#ecr-1)  |  ECR プライベートリポジトリでは、イメージスキャニングが設定されている必要があります  | AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [ECR.2](ecr-controls.md#ecr-2)  |  ECR プライベートリポジトリでは、タグのイミュータビリティが設定されている必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ECR.3](ecr-controls.md#ecr-3)  |  ECR リポジトリには、少なくとも 1 つのライフサイクルポリシーが設定されている必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ECR.4](ecr-controls.md#ecr-4)  | ECR パブリックリポジトリにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [ECR.5](ecr-controls.md#ecr-5)  | ECR リポジトリはカスタマーマネージド AWS KMS keysで暗号化する必要があります | NIST SP 800-53 Rev. 5 | 中 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [ECS.2](ecs-controls.md#ecs-2)  |  Amazon ECS サービスには、パブリック IP アドレスを自動で割り当てないでください  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ECS.3](ecs-controls.md#ecs-3)  |  ECS タスク定義では、ホストのプロセス名前空間を共有しないでください  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ECS.4](ecs-controls.md#ecs-4)  |  ECS コンテナは、非特権として実行する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ECS.5](ecs-controls.md#ecs-5)  |  ECS コンテナは、ルートファイルシステムへの読み取り専用アクセスに制限する必要があります。 |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ECS.8](ecs-controls.md#ecs-8)  |  シークレットは、コンテナ環境の変数として渡さないでください  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ECS.9](ecs-controls.md#ecs-9)  |  ECS タスク定義にはログ設定が必要です。 |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ECS.10](ecs-controls.md#ecs-10)  |  ECS Fargate サービスは、最新の Fargate プラットフォームバージョンで実行する必要があります。 | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ECS.12](ecs-controls.md#ecs-12)  |  ECS クラスターはコンテナインサイトを使用する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ECS.13](ecs-controls.md#ecs-13)  | ECS サービスにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [ECS.14](ecs-controls.md#ecs-14)  | ECS クラスターにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [ECS.15](ecs-controls.md#ecs-15)  | ECS タスク定義にはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [ECS.16](ecs-controls.md#ecs-16)  | ECS タスクは、パブリック IP アドレスを自動的に割り当てないでください | AWS Foundational Security Best Practices、PCI DSS v4.0.1 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [ECS.17](ecs-controls.md#ecs-17)  | ECS タスク定義ではホストネットワークモードを使用すべきではありません | NIST SP 800-53 Rev. 5 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [ECS.18](ecs-controls.md#ecs-18)  | ECS タスク定義では、EFS ボリュームの転送時の暗号化を使用する必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [ECS.19](ecs-controls.md#ecs-19)  | ECS キャパシティプロバイダーはマネージド終了保護を有効にする必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [ECS.20](ecs-controls.md#ecs-20)  | ECS タスク定義では、Linux コンテナ定義で非ルートユーザーを設定する必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [ECS.21](ecs-controls.md#ecs-21)  | ECS タスク定義は、Windows コンテナ定義で管理者以外のユーザーを設定する必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [EFS.1](efs-controls.md#efs-1)  |  Elastic File System は、 を使用して保管中のファイルデータを暗号化するように設定する必要があります。 AWS KMS  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、 AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [EFS.2](efs-controls.md#efs-2)  |  Amazon EFS ボリュームは、バックアッププランに含める必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [EFS.3](efs-controls.md#efs-3)  |  EFS アクセスポイントは、ルートディレクトリを適用する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [EFS.4](efs-controls.md#efs-4)  |  EFS アクセスポイントは、ユーザー ID を適用する必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [EFS.5](efs-controls.md#efs-5)  | EFS アクセスポイントにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EFS.6](efs-controls.md#efs-6)  | EFS マウントターゲットは、起動時にパブリック IP アドレスを割り当てるサブネットに関連付けるべきではありません | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [EFS.7](efs-controls.md#efs-7)  | EFS ファイルシステムでは、自動バックアップが有効になっている必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [EFS.8](efs-controls.md#efs-8)  | EFS ファイルシステムは保管時に暗号化する必要があります | CIS AWS Foundations Benchmark v5.0.0、 AWS 基盤セキュリティのベストプラクティス | 中 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EKS.1](eks-controls.md#eks-1)  |  EKS クラスターエンドポイントがパブリックにアクセスできないようにする必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [EKS.2](eks-controls.md#eks-2)  |  EKS クラスターは、サポートされている Kubernetes バージョンで実行する必要があります。 | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [EKS.3](eks-controls.md#eks-3)  | EKS クラスターは暗号化された Kubernetes シークレットを使用する必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [EKS.6](eks-controls.md#eks-6)  | EKS クラスターにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EKS.7](eks-controls.md#eks-7)  | EKS ID プロバイダー設定にはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EKS.8](eks-controls.md#eks-8)  |  EKS クラスターでは、監査ログ記録が有効になっている必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ElastiCache.1](elasticache-controls.md#elasticache-1)  | ElastiCache (Redis OSS) クラスターでは自動バックアップを有効にする必要があります | AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5 | 高い | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 定期的 | 
|  [ElastiCache.2](elasticache-controls.md#elasticache-2)  |  ElastiCache クラスターでは、マイナーバージョンの自動アップグレードを有効にする必要があります。 | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [ElastiCache.3](elasticache-controls.md#elasticache-3)  | ElastiCache レプリケーショングループでは自動フェイルオーバーを有効にする必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [ElastiCache.4](elasticache-controls.md#elasticache-4)  | ElastiCache レプリケーショングループは保管時に暗号化する必要があります |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [ElastiCache.5](elasticache-controls.md#elasticache-5)  | ElastiCache レプリケーショングループは、転送中に暗号化されている必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [ElastiCache.6](elasticache-controls.md#elasticache-6)  |  以前の Redis バージョンの ElastiCache (Redis OSS) レプリケーショングループでは、Redis OSS AUTH を有効にする必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [ElastiCache.7](elasticache-controls.md#elasticache-7)  | ElastiCache クラスターでは、デフォルトのサブネットグループを使用しないでください |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [ElasticBeanstalk.1](elasticbeanstalk-controls.md#elasticbeanstalk-1)  |  Elastic Beanstalk 環境では、拡張ヘルスレポートを有効にする必要があります。 |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ElasticBeanstalk.2](elasticbeanstalk-controls.md#elasticbeanstalk-2)  |  Elastic Beanstalk のマネージドプラットフォームの更新を有効にする必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  高い  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  変更によってトリガーされる  | 
|  [ElasticBeanstalk.3](elasticbeanstalk-controls.md#elasticbeanstalk-3)  |  Elastic Beanstalk は CloudWatch にログをストリーミングする必要があります  | AWS Foundational Security Best Practices、PCI DSS v4.0.1 |  高い  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  変更によってトリガーされる  | 
|  [ELB.1](elb-controls.md#elb-1)  |  Application Load Balancer は、すべての HTTP リクエストを HTTPS にリダイレクトするように設定する必要があります  |  AWS Foundational Security Best Practices v1.0.0、PCI DSS v3.2.1、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [ELB.2](elb-controls.md#elb-2)  |  SSL/HTTPS リスナーを使用する Classic Load Balancer は、 AWS Certificate Manager によって提供される証明書を使用する必要があります。 |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ELB.3](elb-controls.md#elb-3)  |  Classic Load Balancer のリスナーは、HTTPS または TLS ターミネーションで設定する必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ELB.4](elb-controls.md#elb-4)  |  Application Load Balancer は、http ヘッダーを削除するように設定する必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ELB.5](elb-controls.md#elb-5)  |  アプリケーションおよび Classic Load Balancer のログ記録を有効にする必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ELB.6](elb-controls.md#elb-6)  | アプリケーション、ゲートウェイ、Network Load Balancer で削除保護を有効にする必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [ELB.7](elb-controls.md#elb-7)  |  Classic Load Balancer は、Connection Draining を有効にする必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  | 低 |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ELB.8](elb-controls.md#elb-8)  |  SSL リスナーを使用する Classic Load Balancer は、強力な設定を持つ事前定義されたセキュリティポリシーを使用する必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ELB.9](elb-controls.md#elb-9)  |  Classic Load Balancer では、クロスゾーンロードバランシングが有効になっている必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ELB.10](elb-controls.md#elb-10)  |  Classic Load Balancer は、複数のアベイラビリティーゾーンにまたがっている必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  変更によってトリガーされる  | 
|  [ELB.12](elb-controls.md#elb-12)  |  Application Load Balancer は、防御モードまたは最も厳密な非同期緩和モードで構成する必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ELB.13](elb-controls.md#elb-13)  |  Application、Network、Gateway Load Balancer は、複数のアベイラビリティーゾーンにまたがっている必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  変更によってトリガーされる  | 
|  [ELB.14](elb-controls.md#elb-14)  |  Classic Load Balancer は、防御モードまたは最も厳密な非同期緩和モードで設定する必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ELB.16](elb-controls.md#elb-16)  |  Application Load Balancer は AWS WAF ウェブ ACL に関連付ける必要があります  |  NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ELB.17](elb-controls.md#elb-17)  | リスナーを使用する Application Load Balancer と Network Load Balancer は、推奨されるセキュリティポリシーを使用する必要があります。 |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ELB.18](elb-controls.md#elb-18)  | Application Load Balancer リスナーと Network Load Balancer リスナーは、安全なプロトコルを使用して転送中のデータを暗号化する必要があります | AWS 基本的なセキュリティのベストプラクティス v1.0.0 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [ELB.21](elb-controls.md#elb-21)  |  Application Load Balancer および Network Load Balancer ターゲットグループは、暗号化されたヘルスチェックプロトコルを使用する必要があります  |  AWS 基本的なセキュリティのベストプラクティス v1.0.0  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ELB.22](elb-controls.md#elb-22)  |  ELB ターゲットグループは暗号化されたトランスポートプロトコルを使用する必要があります  |  AWS 基本的なセキュリティのベストプラクティス v1.0.0  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [EMR.1](emr-controls.md#emr-1)  | Amazon EMR クラスタープライマリノードは、パブリック IP アドレスを未設定にする必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [EMR.2](emr-controls.md#emr-2)  | Amazon EMR ブロックパブリックアクセス設定を有効にする必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 | 重大 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [EMR.3](emr-controls.md#emr-3)  | Amazon EMR セキュリティ設定は保管時に暗号化する必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [EMR.4](emr-controls.md#emr-4)  | Amazon EMR セキュリティ設定は転送中に暗号化する必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [ES.1](es-controls.md#es-1)  |  Elasticsearch ドメインは、保管中の暗号化を有効にする必要があります  |  AWS Foundational Security Best Practices v1.0.0、PCI DSS v3.2.1、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [ES.2](es-controls.md#es-2)  |  Elasticsearch ドメインがパブリックにアクセスできないようにする必要があります  | AWS Foundational Security Best Practices、PCI DSS v3.2.1、PCI DSS v4.0.1、NIST SP 800-53 Rev. 5  |  重大  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [ES.3](es-controls.md#es-3)  |  Elasticsearch ドメインは、ノード間で送信されるデータを暗号化する必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1、 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ES.4](es-controls.md#es-4)  |  CloudWatch Logs への Elasticsearch ドメインエラーログ記録を有効にする必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ES.5](es-controls.md#es-5)  |  Elasticsearch ドメインで監査ログ記録が有効になっている必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ES.6](es-controls.md#es-6)  |  Elasticsearch ドメインには少なくとも 3 つのデータノードが必要です  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ES.7](es-controls.md#es-7)  |  Elasticsearch ドメインは、少なくとも 3 つの専用マスターノードを設定する必要があります。 |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [ES.8](es-controls.md#es-8)  | Elasticsearch ドメインへの接続は TLS セキュリティポリシーを使用して暗号化する必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [ES.9](es-controls.md#es-9)  | Elasticsearch ドメインには タグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EventBridge.2](eventbridge-controls.md#eventbridge-2)  | EventBridge イベントバスにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [EventBridge.3](eventbridge-controls.md#eventbridge-3)  |  Amazon EventBridge カスタムイベントバスにリソースポリシーがアタッチされている必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [EventBridge.4](eventbridge-controls.md#eventbridge-4)  |  EventBridge グローバルエンドポイントでは、イベントの複製が有効になっている必要があります  |  NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [FraudDetector.1](frauddetector-controls.md#frauddetector-1)  | Amazon Fraud Detector エンティティタイプにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [FraudDetector.2](frauddetector-controls.md#frauddetector-2)  | Amazon Fraud Detector ラベルにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [FraudDetector.3](frauddetector-controls.md#frauddetector-3)  | Amazon Fraud Detector の結果にはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [FraudDetector.4](frauddetector-controls.md#frauddetector-4)  | Amazon Fraud Detector 変数にはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [FSx.1](fsx-controls.md#fsx-1)  |  FSx for OpenZFS ファイルシステムでは、タグをバックアップとボリュームにコピーするように設定する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  | 定期的 | 
|  [FSx.2](fsx-controls.md#fsx-2)  | FSx for Lustre ファイルシステムでは、タグをバックアップにコピーするように設定する必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 | 低 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [FSx.3](fsx-controls.md#fsx-3)  | FSx for OpenZFS ファイルシステムはマルチ AZ 配置用に設定する必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [FSx.4](fsx-controls.md#fsx-4)  | FSx for NetApp ONTAP ファイルシステムは、マルチ AZ 配置用に設定する必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 定期的 | 
|  [FSx.5](fsx-controls.md#fsx-5)  | FSx for Windows File Server ファイルシステムは、マルチ AZ 配置用に設定する必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [Glue.1](glue-controls.md#glue-1)  | AWS Glue ジョブにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Glue.3](glue-controls.md#glue-3)  | AWS Glue 機械学習変換は保管時に暗号化する必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [Glue.4](glue-controls.md#glue-4)  | AWS Glue Spark ジョブは、サポートされているバージョンの で実行する必要があります。 AWS Glue | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [GlobalAccelerator.1](globalaccelerator-controls.md#globalaccelerator-1)  | Global Accelerator アクセラレーターにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [GuardDuty.1](guardduty-controls.md#guardduty-1)  |  GuardDuty を有効にする必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2、PCI DSS v3.2.1、PCI DSS v4.0.1 |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [GuardDuty.2](guardduty-controls.md#guardduty-2)  | GuardDuty フィルターにはタグを付ける必要があります  | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [GuardDuty.3](guardduty-controls.md#guardduty-3)  | GuardDuty IPSet タグを付ける必要があります  | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [GuardDuty.4](guardduty-controls.md#guardduty-4)  | GuardDuty ディテクターにはタグを付ける必要があります  | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [GuardDuty.5](guardduty-controls.md#guardduty-5)  | GuardDuty EKS 監査ログモニタリングを有効にする必要があります | AWS 基本的なセキュリティのベストプラクティス | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [GuardDuty.6](guardduty-controls.md#guardduty-6)  | GuardDuty Lambda Protection を有効にする必要があります | AWS Foundational Security Best Practices、PCI DSS v4.0.1 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [GuardDuty.7](guardduty-controls.md#guardduty-7)  | GuardDuty EKS ランタイムモニタリングを有効にする必要があります | AWS Foundational Security Best Practices、PCI DSS v4.0.1 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [GuardDuty.8](guardduty-controls.md#guardduty-8)  | EC2 の GuardDuty Malware Protection を有効にする必要があります | AWS 基本的なセキュリティのベストプラクティス | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [GuardDuty.9](guardduty-controls.md#guardduty-9)  | GuardDuty RDS Protection を有効にする必要があります | AWS Foundational Security Best Practices、PCI DSS v4.0.1 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [GuardDuty.10](guardduty-controls.md#guardduty-10)  | GuardDuty S3 Protection を有効にする必要があります | AWS Foundational Security Best Practices、PCI DSS v4.0.1 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [GuardDuty.11](guardduty-controls.md#guardduty-11)  | GuardDuty ランタイムモニタリングを有効にする必要があります | AWS 基本的なセキュリティのベストプラクティス | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [GuardDuty.12](guardduty-controls.md#guardduty-12)  | GuardDuty ECS ランタイムモニタリングを有効にする必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [GuardDuty.13](guardduty-controls.md#guardduty-13)  | GuardDuty EC2 ランタイムモニタリングを有効にする必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [IAM.1](iam-controls.md#iam-1)  |  IAM ポリシーでは、完全な「\$1」管理権限を許可してはなりません  | CIS AWS Foundations Benchmark v1.2.0、 AWS Foundational Security Best Practices v1.0.0、PCI DSS v3.2.1、CIS AWS Foundations Benchmark v1.4.0、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2  |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [IAM.2](iam-controls.md#iam-2)  |  IAM ユーザーには IAM ポリシーをアタッチしてはなりません  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.2.0、 AWS Foundational Security Best Practices v1.0.0、PCI DSS v3.2.1、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [IAM.3](iam-controls.md#iam-3)  |  IAM ユーザーのアクセスキーは 90 日以内ごとに更新する必要があります  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、 AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [IAM.4](iam-controls.md#iam-4)  |  IAM ルートユーザーのアクセスキーが存在してはいけません  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、 AWS Foundational Security Best Practices v1.0.0、PCI DSS v3.2.1、NIST SP 800-53 Rev. 5  |  重大  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [IAM.5](iam-controls.md#iam-5)  |  MFA は、コンソールパスワードを持つすべての IAM ユーザーに対して有効にする必要があります  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、 AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [IAM.6](iam-controls.md#iam-6)  |  ルートユーザーに対してハードウェア MFA を有効にする必要があります  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、 AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v3.2.1、PCI DSS v4.0.1 |  重大  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [IAM.7](iam-controls.md#iam-7)  |  IAM ユーザーのパスワードポリシーには強力な設定が必要です  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2、PCI DSS v4.0.1 |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  定期的  | 
|  [IAM.8](iam-controls.md#iam-8)  |  未使用の IAM ユーザー認証情報は削除する必要があります  | CIS AWS Foundations Benchmark v1.2.0、 AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2、PCI DSS v3.2.1、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [IAM.9](iam-controls.md#iam-9)  |  ルートユーザーに対して MFA を有効にする必要があります  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、NIST SP 800-53 Rev. 5、PCI DSS v3.2.1、PCI DSS v4.0.1 |  重大  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [IAM.10](iam-controls.md#iam-10)  |  IAM ユーザーのパスワードポリシーには強力な設定が必要です  | NIST SP 800-171 Rev. 2、PCI DSS v3.2.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [IAM.11](iam-controls.md#iam-11)  |  IAM パスワードポリシーで少なくとも 1 文字の大文字が要求されていることを確認する  | CIS AWS Foundations Benchmark v1.2.0、NIST SP 800-171 Rev. 2、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [IAM.12](iam-controls.md#iam-12)  |  IAM パスワードポリシーで少なくとも 1 文字の小文字が要求されていることを確認する  | CIS AWS Foundations Benchmark v1.2.0、NIST SP 800-171 Rev. 2、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [IAM.13](iam-controls.md#iam-13)  |  IAM パスワードポリシーで少なくとも 1 文字の記号が要求されていることを確認する  | CIS AWS Foundations Benchmark v1.2.0、NIST SP 800-171 Rev. 2 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [IAM.14](iam-controls.md#iam-14)  |  IAM パスワードポリシーで少なくとも 1 文字の数字が要求されていることを確認する  | CIS AWS Foundations Benchmark v1.2.0、NIST SP 800-171 Rev. 2、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [IAM.15](iam-controls.md#iam-15)  |  IAM パスワードポリシーにおいて、14 文字以上のパスワードが要求されるようにする  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、NIST SP 800-171 Rev. 2 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [IAM.16](iam-controls.md#iam-16)  |  IAM パスワードポリシーはパスワードの再使用を禁止しています  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、NIST SP 800-171 Rev. 2、PCI DSS v4.0.1 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [IAM.17](iam-controls.md#iam-17)  |  IAM パスワードポリシーでパスワードが 90 日以内に有効期限切れとなることを確認する  | CIS AWS Foundations Benchmark v1.2.0、PCI DSS v4.0.1 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [IAM.18](iam-controls.md#iam-18)  |  AWS サポート でインシデントを管理するためのサポートロールが作成されていることを確認する | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、NIST SP 800-171 Rev. 2、PCI DSS v4.0.1 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [IAM.19](iam-controls.md#iam-19)  |  すべての IAM ユーザーに対して MFA を有効にする必要があります  | NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2、PCI DSS v3.2.1、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [IAM.21](iam-controls.md#iam-21)  |  作成する IAM カスタマー管理ポリシーにはサービスのワイルドカードアクションを許可しないでください  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [IAM.22](iam-controls.md#iam-22)  |  45 日間未使用の IAM ユーザー認証情報は削除する必要があります  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.4.0、NIST SP 800-171 Rev. 2 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [IAM.23](iam-controls.md#iam-23)  | IAM Access Analyzer アナライザーにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IAM.24](iam-controls.md#iam-24)  | IAM ロールにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IAM.25](iam-controls.md#iam-25)  | IAM ユーザーはタグ付けする必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IAM.26](iam-controls.md#iam-26) | IAM で管理されている期限切れの SSL/TLS 証明書は削除する必要があります | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [IAM.27](iam-controls.md#iam-27)  | IAM ID に AWSCloudShellFullAccess ポリシーをアタッチしないでください | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [IAM.28](iam-controls.md#iam-28)  | IAM Access Analyzer の外部アクセスアナライザーを有効にする必要があります | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [Inspector.1](inspector-controls.md#inspector-1)  | Amazon Inspector EC2 スキャンを有効にする必要があります | AWS Foundational Security Best Practices、PCI DSS v4.0.1 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [Inspector.2](inspector-controls.md#inspector-2)  | Amazon Inspector ECR スキャンを有効にする必要があります | AWS Foundational Security Best Practices、PCI DSS v4.0.1 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [Inspector.3](inspector-controls.md#inspector-3)  | Amazon Inspector Lambda コードスキャンを有効にする必要があります | AWS Foundational Security Best Practices、PCI DSS v4.0.1 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [Inspector.4](inspector-controls.md#inspector-4)  | Amazon Inspector Lambda 標準スキャンを有効する必要があります | AWS Foundational Security Best Practices、PCI DSS v4.0.1 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [IoT.1](iot-controls.md#iot-1)  | AWS IoT Device Defender セキュリティプロファイルにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IoT.2](iot-controls.md#iot-2)  | AWS IoT Core 緩和アクションにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IoT.3](iot-controls.md#iot-3)  | AWS IoT Core ディメンションにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IoT.4](iot-controls.md#iot-4)  | AWS IoT Core オーソライザーにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IoT.5](iot-controls.md#iot-5)  | AWS IoT Core ロールエイリアスにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IoT.6](iot-controls.md#iot-6)  | AWS IoT Core ポリシーにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IoTEvents.1](iotevents-controls.md#iotevents-1)  | AWS IoT Events 入力にはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IoTEvents.2](iotevents-controls.md#iotevents-2)  | AWS IoT Events ディテクターモデルにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IoTEvents.3](iotevents-controls.md#iotevents-3)  | AWS IoT Events アラームモデルにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IoTSiteWise.1](iotsitewise-controls.md#iotsitewise-1)  | AWS IoT SiteWise アセットモデルにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IoTSiteWise.2](iotsitewise-controls.md#iotsitewise-2)  | AWS IoT SiteWise ダッシュボードにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IoTSiteWise.3](iotsitewise-controls.md#iotsitewise-3)  | AWS IoT SiteWise ゲートウェイにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IoTSiteWise.4](iotsitewise-controls.md#iotsitewise-4)  | AWS IoT SiteWise ポータルにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IoTSiteWise.5](iotsitewise-controls.md#iotsitewise-5)  | AWS IoT SiteWise プロジェクトにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IoTTwinMaker.1](iottwinmaker-controls.md#iottwinmaker-1)  | AWS IoT TwinMaker 同期ジョブにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IoTTwinMaker.2](iottwinmaker-controls.md#iottwinmaker-2)  | AWS IoT TwinMaker ワークスペースにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IoTTwinMaker.3](iottwinmaker-controls.md#iottwinmaker-3)  | AWS IoT TwinMaker シーンにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IoTTwinMaker.4](iottwinmaker-controls.md#iottwinmaker-4)  | AWS IoT TwinMaker エンティティにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IoTWireless.1](iotwireless-controls.md#iotwireless-1)  | AWS IoT Wireless マルチキャストグループにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IoTWireless.2](iotwireless-controls.md#iotwireless-2)  | AWS IoT Wireless サービスプロファイルにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IoTWireless.3](iotwireless-controls.md#iotwireless-3)  | AWS IoT Wireless FUOTA タスクにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IVS.1](ivs-controls.md#ivs-1)  | IVS 再生キーペアにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IVS.2](ivs-controls.md#ivs-2)  | IVS 記録設定にはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [IVS.3](ivs-controls.md#ivs-3)  | IVS チャネルにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Keyspaces.1](keyspaces-controls.md#keyspaces-1)  | Amazon Keyspaces キースペースにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Kinesis.1](kinesis-controls.md#kinesis-1)  |  Kinesis Streams は、保管中に暗号化する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Kinesis.2](kinesis-controls.md#kinesis-2)  | Kinesis ストリームにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Kinesis.3](kinesis-controls.md#kinesis-3)  | Kinesis ストリームには適切なデータ保持期間が必要です | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [KMS.1](kms-controls.md#kms-1)  |  IAM カスタマー管理ポリシーでは、すべての KMS キーの復号アクションを許可しないでください  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [KMS.2](kms-controls.md#kms-2)  |  IAM プリンシパルは、すべての KMS キーで復号アクションを許可する IAM インラインポリシーを使用ないでください  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [KMS.3](kms-controls.md#kms-3)  |  AWS KMS keys 意図せずに削除しないでください  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  重大  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [KMS.4](kms-controls.md#kms-4)  |  AWS KMS key ローテーションを有効にする必要があります  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.4.0、CIS AWS Foundations Benchmark v1.2.0、NIST SP 800-53 Rev. 5、PCI DSS v3.2.1、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [KMS.5](kms-controls.md#kms-5)  | KMS キーはパブリックにアクセスできません | AWS 基本的なセキュリティのベストプラクティス | 重大 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [Lambda.1](lambda-controls.md#lambda-1)  |  Lambda 関数ポリシーでは、パブリックアクセスを禁止する必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v3.2.1、PCI DSS v4.0.1 |  重大  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Lambda.2](lambda-controls.md#lambda-2)  |  Lambda 関数はサポートされているランタイムを使用する必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Lambda.3](lambda-controls.md#lambda-3)  |  Lambda 関数は VPC 内に存在する必要があります  |  PCI DSS v3.2.1、NIST SP 800-53 Rev. 5  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Lambda.5](lambda-controls.md#lambda-5)  |  VPC Lambda 関数は複数のアベイラビリティーゾーンで運用する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  変更によってトリガーされる  | 
|  [Lambda.6](lambda-controls.md#lambda-6)  | Lambda 関数にはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Lambda.7](lambda-controls.md#lambda-7)  | Lambda 関数では AWS X-Ray アクティブトレースが有効になっている必要があります | NIST SP 800-53 Rev. 5 | 低 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [Macie.1](macie-controls.md#macie-1)  |  Amazon Macie を有効にする必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [Macie.2](macie-controls.md#macie-2)  | Macie 自動機密データ検出を有効にする必要があります | AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [MSK.1](msk-controls.md#msk-1)  |  MSK クラスターはブローカーノード間の転送時に暗号化される必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [MSK.2](msk-controls.md#msk-2)  |  MSK クラスターでは、拡張モニタリングを設定する必要があります  |  NIST SP 800-53 Rev. 5  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [MSK.3](msk-controls.md#msk-3)  | MSK Connect コネクタは転送中に暗号化する必要があります | AWS Foundational Security Best Practices、PCI DSS v4.0.1 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  | 変更によってトリガーされる | 
|  [MSK.4](msk-controls.md#msk-4)  | MSK クラスターではパブリックアクセスを無効にする必要があります | AWS 基本的なセキュリティのベストプラクティス | 重大 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [MSK.5](msk-controls.md#msk-5)  | MSK コネクタではログ記録が有効になっている必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [MSK.6](msk-controls.md#msk-6)  | MSK クラスターは認証されていないアクセスを無効にする必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [MQ.2](mq-controls.md#mq-2)  | ActiveMQ ブローカーは監査ログを CloudWatch にストリーミングする必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [MQ.4](mq-controls.md#mq-4)  | Amazon MQ ブローカーにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [MQ.5](mq-controls.md#mq-5)  |  ActiveMQ ブローカーはアクティブ/スタンバイデプロイメントモードを使用する必要があります  | NIST SP 800-53 Rev. 5 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [MQ.6](mq-controls.md#mq-6)  |  RabbitMQ ブローカーはクラスターデプロイメントモードを使用する必要があります。 | NIST SP 800-53 Rev. 5 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Neptune.1](neptune-controls.md#neptune-1)  |  Neptune DB クラスターは、保管中に暗号化する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  | 変更によってトリガーされる | 
|  [Neptune.2](neptune-controls.md#neptune-2)  |  Neptune DB クラスターでは、監査ログを CloudWatch Logs に発行する必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  | 変更によってトリガーされる | 
|  [Neptune.3](neptune-controls.md#neptune-3)  |  Neptune DB クラスタースナップショットはパブリックにしないでください  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  重大  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Neptune.4](neptune-controls.md#neptune-4)  |  Neptune DB クラスターでは、削除保護が有効になっている必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Neptune.5](neptune-controls.md#neptune-5)  |  Neptune DB クラスターでは、自動バックアップが有効になっている必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  変更によってトリガーされる  | 
|  [Neptune.6](neptune-controls.md#neptune-6)  |  Neptune DB クラスタースナップショットは、保管中に暗号化する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Neptune.7](neptune-controls.md#neptune-7)  |  Neptune DB クラスターでは、IAM データベース認証が有効になっている必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Neptune.8](neptune-controls.md#neptune-8)  |  Neptune DB クラスターでは、タグをスナップショットにコピーするように設定する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Neptune.9](neptune-controls.md#neptune-9)  |  Neptune DB クラスターを複数のアベイラビリティーゾーンにデプロイする必要があります  |  NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [NetworkFirewall.1](networkfirewall-controls.md#networkfirewall-1)  |  Network Firewall ファイアウォールを複数のアベイラビリティーゾーンにデプロイする必要があります  |  NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [NetworkFirewall.2](networkfirewall-controls.md#networkfirewall-2)  |  Network Firewall ログ記録を有効にする必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [NetworkFirewall.3](networkfirewall-controls.md#networkfirewall-3)  |  Network Firewall ポリシーには、1 つ以上のルールグループが関連付けられている必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [NetworkFirewall.4](networkfirewall-controls.md#networkfirewall-4)  |  Network Firewall ポリシーのデフォルトのステートレスアクションは、完全なパケットに対してドロップまたは転送される必要があります。 |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [NetworkFirewall.5](networkfirewall-controls.md#networkfirewall-5)  |  Network Firewall ポリシーのデフォルトのステートレスアクションは、断片化されたパケットに対してドロップまたは転送される必要があります。 |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [NetworkFirewall.6](networkfirewall-controls.md#networkfirewall-6)  |  ステートレスネットワークファイアウォールのルールグループを空にしないでください  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [NetworkFirewall.7](networkfirewall-controls.md#networkfirewall-7)  | Network Firewall ファイアウォールにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [NetworkFirewall.8](networkfirewall-controls.md#networkfirewall-8)  | Network Firewall ファイアウォールポリシーにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [NetworkFirewall.9](networkfirewall-controls.md#networkfirewall-9)  |  Network Firewall は削除保護を有効にする必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [NetworkFirewall.10](networkfirewall-controls.md#networkfirewall-10)  | Network Firewall ファイアウォールはサブネット変更保護を有効にする必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [Opensearch.1](opensearch-controls.md#opensearch-1)  |  OpenSearch ドメインは保管中の暗号化を有効にする必要があります  |  AWS Foundational Security Best Practices v1.0.0、PCI DSS v3.2.1、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Opensearch.2](opensearch-controls.md#opensearch-2)  |  OpenSearch ドメインがパブリックにアクセスできないようにする必要があります  |  AWS Foundational Security Best Practices v1.0.0、PCI DSS v3.2.1、NIST SP 800-53 Rev. 5  |  重大  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Opensearch.3](opensearch-controls.md#opensearch-3)  |  OpenSearch ドメインはノード間で送信されるデータを暗号化する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Opensearch.4](opensearch-controls.md#opensearch-4)  |  CloudWatch Logs への OpenSearch ドメインエラーのログ記録を有効にする必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Opensearch.5](opensearch-controls.md#opensearch-5)  |  OpenSearch ドメインでは、監査ログ記録を有効にする必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Opensearch.6](opensearch-controls.md#opensearch-6)  |  OpenSearch ドメインには少なくとも 3 つのデータノードが必要です  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Opensearch.7](opensearch-controls.md#opensearch-7)  |  OpenSearch ドメインは、きめ細かなアクセスコントロールを有効にする必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Opensearch.8](opensearch-controls.md#opensearch-8)  | OpenSearch ドメインへの接続は 最新の TLS セキュリティポリシーを使用して暗号化する必要があります |  AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [Opensearch.9](opensearch-controls.md#opensearch-9)  | OpenSearch ドメインにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Opensearch.10](opensearch-controls.md#opensearch-10)  |  OpenSearch ドメインには、最新のソフトウェアアップデートがインストールされている必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 | 中 |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Opensearch.11](opensearch-controls.md#opensearch-11)  | OpenSearch ドメインには少なくとも 3 つの専用プライマリノードが必要です | NIST SP 800-53 Rev. 5 | 低 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [PCA.1](pca-controls.md#pca-1)  |  AWS Private CA ルート認証機関を無効にする必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  | 定期的 | 
|  [PCA.2](pca-controls.md#pca-2)  | AWS プライベート CA 認証機関にはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [RDS.1](rds-controls.md#rds-1)  |  RDS スナップショットはプライベートである必要があります  |  AWS Foundational Security Best Practices v1.0.0、PCI DSS v3.2.1、NIST SP 800-53 Rev. 5  |  重大  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.2](rds-controls.md#rds-2)  |  RDS DB インスタンスは、PubliclyAccessible 設定によって判断される、パブリックアクセスを禁止する必要があります  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、 AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v3.2.1、PCI DSS v4.0.1 |  重大  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.3](rds-controls.md#rds-3)  |  RDS DB インスタンスでは、保管時の暗号化が有効になっている必要があります  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.4.0、 AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.4](rds-controls.md#rds-4)  |  RDS クラスタースナップショットとデータベーススナップショットは保管中に暗号化する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.5](rds-controls.md#rds-5)  |  RDS DB インスタンスは、複数のアベイラビリティーゾーンで設定する必要があります  | CIS AWS Foundations Benchmark v5.0.0、 AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.6](rds-controls.md#rds-6)  |  RDS DB インスタンスの拡張モニタリングを設定する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  低  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  変更によってトリガーされる  | 
|  [RDS.7](rds-controls.md#rds-7)  |  RDS クラスターでは、削除保護が有効になっている必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  | 中 |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.8](rds-controls.md#rds-8)  |  RDS DB インスタンスで、削除保護が有効になっている必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.9](rds-controls.md#rds-9)  | RDS DB インスタンスは CloudWatch Logs にログを発行する必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.10](rds-controls.md#rds-10)  |  IAM 認証は RDS インスタンス用に設定する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.11](rds-controls.md#rds-11)  |  Amazon RDS インスタンスでは、自動バックアップが有効になっている必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  変更によってトリガーされる  | 
|  [RDS.12](rds-controls.md#rds-12)  |  IAM 認証は RDS クラスター用に設定する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.13](rds-controls.md#rds-13)  |  RDS 自動マイナーバージョンアップグレードを有効にする必要があります  | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、 AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.14](rds-controls.md#rds-14)  |  Amazon Aurora クラスターはバックトラッキングを有効にする必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  変更によってトリガーされる  | 
|  [RDS.15](rds-controls.md#rds-15)  |  RDS DB クラスターを複数のアベイラビリティーゾーンに対して設定する必要があります  | CIS AWS Foundations Benchmark v5.0.0、 AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.16](rds-controls.md#rds-16)  | Aurora DB クラスターでは、タグを DB スナップショットにコピーするように設定する必要があります | AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5 | 低  | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [RDS.17](rds-controls.md#rds-17)  |  RDS DB インスタンスは、タグをスナップショットにコピーするように設定する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.18](rds-controls.md#rds-18)  |  RDS インスタンスは VPC 内にデプロイする必要があります  |   |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.19](rds-controls.md#rds-19)  |  重大なクラスターイベントについて、既存の RDS イベント通知サブスクリプションを設定する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.20](rds-controls.md#rds-20)  |  重大なデータベースインスタンスイベントに対して、既存の RDS イベント通知サブスクリプションを設定する必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.21](rds-controls.md#rds-21)  |  重大なデータベースパラメータグループイベントに対して RDS イベント通知サブスクリプションを設定する必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.22](rds-controls.md#rds-22)  |  重大なデータベースセキュリティグループイベントに対して RDS イベント通知サブスクリプションを設定する必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.23](rds-controls.md#rds-23)  |  RDS インスタンスはデータベースエンジンのデフォルトポートを使用しないようにする必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.24](rds-controls.md#rds-24)  |  RDS データベースクラスターはカスタム管理者ユーザー名を使用する必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.25](rds-controls.md#rds-25)  |  RDS データベースインスタンスはカスタム管理者ユーザー名を使用する必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.26](rds-controls.md#rds-26)  |  RDS DB インスタンスはバックアッププランで保護する必要があります  |  NIST SP 800-53 Rev. 5  |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  定期的  | 
|  [RDS.27](rds-controls.md#rds-27)  |  RDS DB クラスターは保管中に暗号化する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.28](rds-controls.md#rds-28)  | RDS DB クラスターにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [RDS.29](rds-controls.md#rds-29)  | RDS DB クラスタースナップショットにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [RDS.30](rds-controls.md#rds-30)  | RDS DB インスタンスにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [RDS.31](rds-controls.md#rds-31)  | RDS DB セキュリティグループにタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [RDS.32](rds-controls.md#rds-32)  | RDS DB スナップショットにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [RDS.33](rds-controls.md#rds-33)  | RDS DB サブネットグループはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [RDS.34](rds-controls.md#rds-34)  |  Aurora MySQL DB クラスターでは、監査ログを CloudWatch Logs に発行する必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.35](rds-controls.md#rds-35)  |  RDS DB クラスターではマイナーバージョンの自動アップグレードを有効にしておく必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [RDS.36](rds-controls.md#rds-36)  | RDS for PostgreSQL DB インスタンスは CloudWatch Logs にログを発行する必要があります | AWS Foundational Security Best Practices、PCI DSS v4.0.1 | 中 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [RDS.37](rds-controls.md#rds-37)  | Aurora PostgreSQL DB クラスターでは、ログを CloudWatch Logs に発行する必要があります | AWS Foundational Security Best Practices、PCI DSS v4.0.1 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [RDS.38](rds-controls.md#rds-38)  | RDS for PostgreSQL DB インスタンスは転送中に暗号化する必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [RDS.39](rds-controls.md#rds-39)  | RDS for MySQL DB インスタンスは転送中に暗号化する必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [RDS.40](rds-controls.md#rds-40)  | RDS for SQL Server DB インスタンスは CloudWatch Logs にログを発行する必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 | 中 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [RDS.41](rds-controls.md#rds-41)  | RDS for SQL Server DB インスタンスは転送中に暗号化する必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [RDS.42](rds-controls.md#rds-42)  | RDS for MariaDB DB インスタンスは CloudWatch Logs にログを発行する必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 | 中 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 定期的 | 
|  [RDS.43](rds-controls.md#rds-43)  | RDS DB プロキシの接続には TLS 暗号化が必要です | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [RDS.44](rds-controls.md#rds-44)  | RDS for MariaDB DB インスタンスは転送中に暗号化する必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [RDS.45](rds-controls.md#rds-45)  | Aurora MySQL DB クラスターでは、監査ログ記録が有効になっている必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [RDS.46](rds-controls.md#rds-46)  | RDS DB インスタンスは、インターネットゲートウェイへのルートを持つパブリックサブネットにデプロイすべきではありません | AWS 基本的なセキュリティのベストプラクティス | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [RDS.47](rds-controls.md#rds-47)  | タグを DB スナップショットにコピーするように RDS for PostgreSQL DB クラスターを設定する必要があります | AWS 基本的なセキュリティのベストプラクティス | 低 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [RDS.48](rds-controls.md#rds-48)  | タグを DB スナップショットにコピーするように RDS for MySQL DB クラスターを設定する必要があります | AWS 基本的なセキュリティのベストプラクティス | 低 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [RDS.50](rds-controls.md#rds-50)  |  RDS DB クラスターには十分なバックアップ保持期間を設定する必要があります  |  AWS 基本的なセキュリティのベストプラクティス v1.0.0  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) はい  |  変更によってトリガーされる  | 
|  [Redshift.1](redshift-controls.md#redshift-1)  |  Amazon Redshift クラスターはパブリックアクセスを禁止する必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v3.2.1、PCI DSS v4.0.1 |  重大  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Redshift.2](redshift-controls.md#redshift-2)  |  Amazon Redshift クラスターへの接続は転送中に暗号化する必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Redshift.3](redshift-controls.md#redshift-3)  |  Amazon Redshift クラスターでは、自動スナップショットが有効になっている必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  変更によってトリガーされる  | 
|  [Redshift.4](redshift-controls.md#redshift-4)  |  Amazon Redshift クラスターでは、監査ログ記録が有効になっている必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Redshift.6](redshift-controls.md#redshift-6)  |  Amazon Redshift でメジャーバージョンへの自動アップグレードが有効になっている必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Redshift.7](redshift-controls.md#redshift-7)  |  Redshift クラスターは拡張 VPC ルーティングを使用する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Redshift.8](redshift-controls.md#redshift-8)  |  Amazon Redshift クラスターでデフォルトの管理者ユーザー名を使用しないでください  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Redshift.10](redshift-controls.md#redshift-10)  |  Redshift クラスターは保存時に暗号化する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [Redshift.11](redshift-controls.md#redshift-11)  | Redshift クラスターにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Redshift.12](redshift-controls.md#redshift-12)  | Redshift イベントサブスクリプション通知にはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Redshift.13](redshift-controls.md#redshift-13)  | Redshift クラスタースナップショットにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Redshift.14](redshift-controls.md#redshift-14)  | Redshift クラスターサブネットグループはタグ付けする必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Redshift.15](redshift-controls.md#redshift-15)  | Redshift セキュリティグループは、制限されたオリジンからのみクラスターポートへの入力を許可する必要があります | AWS Foundational Security Best Practices、PCI DSS v4.0.1 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [Redshift.16](redshift-controls.md#redshift-16)  | Redshift クラスターサブネットグループには、複数のアベイラビリティーゾーンからのサブネットが必要です | NIST SP 800-53 Rev. 5 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [Redshift.17](redshift-controls.md#redshift-17)  | Redshift クラスターパラメータグループはタグ付けする必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Redshift.18](redshift-controls.md#redshift-18)  | Redshift クラスターでは、マルチ AZ 配置を有効にする必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [RedshiftServerless.1](redshiftserverless-controls.md#redshiftserverless-1)  | Amazon Redshift Serverless ワークグループは拡張された VPC のルーティングを使用する必要があります | AWS 基本的なセキュリティのベストプラクティス | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [RedshiftServerless.2](redshiftserverless-controls.md#redshiftserverless-2)  | SSL を使用するには、Redshift Serverless ワークグループへの接続が必要です | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [RedshiftServerless.3](redshiftserverless-controls.md#redshiftserverless-3)  | Redshift Serverless ワークグループはパブリックアクセスを禁止する必要があります | AWS 基本的なセキュリティのベストプラクティス | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [RedshiftServerless.4](redshiftserverless-controls.md#redshiftserverless-4)  | Redshift Serverless 名前空間はカスタマーマネージドで暗号化する必要があります AWS KMS keys | NIST SP 800-53 Rev. 5 | 中 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 定期的 | 
|  [RedshiftServerless.5](redshiftserverless-controls.md#redshiftserverless-5)  | Redshift サーバーレス名前空間でデフォルトの管理者ユーザー名を使用すべきではありません | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [RedshiftServerless.6](redshiftserverless-controls.md#redshiftserverless-6)  | Redshift Serverless 名前空間は CloudWatch Logs にログをエクスポートする必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [Route53.1](route53-controls.md#route53-1)  | Route 53 ヘルスチェックにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Route53.2](route53-controls.md#route53-2)  |  Route 53 のパブリックホストゾーンは DNS クエリをログに記録する必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [S3.1](s3-controls.md#s3-1)  | S3 汎用バケットではブロックパブリックアクセスの設定が有効になっている必要があります | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.4.0、 AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v3.2.1、PCI DSS v4.0.1 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [S3.2](s3-controls.md#s3-2)  | S3 汎用バケットではパブリック読み取りアクセスをブロックする必要があります | AWS Foundational Security Best Practices、PCI DSS v3.2.1、NIST SP 800-53 Rev. 5 | 重大 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によるトリガーと定期的なトリガー | 
|  [S3.3](s3-controls.md#s3-3)  | S3 汎用バケットではパブリック書き込みアクセスをブロックする必要があります。 | AWS Foundational Security Best Practices、PCI DSS v3.2.1、NIST SP 800-53 Rev. 5 | 重大 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によるトリガーと定期的なトリガー | 
|  [S3.5](s3-controls.md#s3-5)  | S3 汎用バケットではリクエストに SSL を使用する必要があります | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.4.0、 AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2、PCI DSS v3.2.1、PCI DSS v4.0.1 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [S3.6](s3-controls.md#s3-6)  | S3 汎用バケットポリシーは、他の へのアクセスを制限する必要があります AWS アカウント | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [S3.7](s3-controls.md#s3-7)  | S3 汎用バケットではクロスリージョンレプリケーションを使用する必要があります | PCI DSS v3.2.1、NIST SP 800-53 Rev. 5 | 低 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [S3.8](s3-controls.md#s3-8)  | S3 汎用バケットではパブリックアクセスをブロックする必要があります | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.4.0、 AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [S3.9](s3-controls.md#s3-9)  | S3 汎用バケットでは、サーバーアクセスログ記録が有効になっている必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2、PCI DSS v4.0.1 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [S3.10](s3-controls.md#s3-10)  | バージョニングが有効になっている S3 汎用バケットにはライフサイクル設定が必要です | NIST SP 800-53 Rev. 5 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [S3.11](s3-controls.md#s3-11)  | S3 汎用バケットでは、イベント通知を有効にする必要があります | NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2 | 中 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [S3.12](s3-controls.md#s3-12)  | ACL は、S3 汎用バケットへのユーザーアクセスの管理に使用しません | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [S3.13](s3-controls.md#s3-13)  | S3 汎用バケットにはライフサイクル設定が必要です | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [S3.14](s3-controls.md#s3-14)  | S3 汎用バケットでは バージョニングが有効になっている必要があります | NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2 | 低 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [S3.15](s3-controls.md#s3-15)  | S3 汎用バケットでは Object Lock が有効になっている必要があります | NIST SP 800-53 Rev. 5、CI DSS v4.0.1 | 中 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [S3.17](s3-controls.md#s3-17)  | S3 汎用バケットは保管時に で暗号化する必要があります AWS KMS keys | NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2、PCI DSS v4.0.1 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [S3.19](s3-controls.md#s3-19)  | S3 アクセスポイントでは、ブロックパブリックアクセス設定を有効にする必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 | 重大 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [S3.20](s3-controls.md#s3-20)  | S3 汎用バケットでは MFA 削除が有効になっている必要があります | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、CIS AWS Foundations Benchmark v1.4.0、NIST SP 800-53 Rev. 5 | 低 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [S3.22](s3-controls.md#s3-22)  | S3 汎用バケットはオブジェクトレベルの書き込みイベントをログに記録する必要があります | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、PCI DSS v4.0.1 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [S3.23](s3-controls.md#s3-23)  | S3 汎用バケットはオブジェクトレベルの読み取りイベントをログに記録する必要があります | CIS AWS Foundations Benchmark v5.0.0、CIS AWS Foundations Benchmark v3.0.0、PCI DSS v4.0.1 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [S3.24](s3-controls.md#s3-24)  | S3 マルチリージョンアクセスポイントでは、ブロックパブリックアクセス設定を有効にする必要があります | AWS Foundational Security Best Practices、PCI DSS v4.0.1 | 高 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [S3.25](s3-controls.md#s3-25)  | S3 ディレクトリバケットにはライフサイクル設定が必要です | AWS 基本的なセキュリティのベストプラクティス | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [SageMaker.1](sagemaker-controls.md#sagemaker-1)  |  Amazon SageMaker ノートブックインスタンスは、インターネットに直接アクセスできないようにする必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v3.2.1、PCI DSS v4.0.1 |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [SageMaker.2](sagemaker-controls.md#sagemaker-2)  |  SageMaker ノートブックインスタンスはカスタム VPC で起動する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [SageMaker.3](sagemaker-controls.md#sagemaker-3)  |  ユーザーは SageMaker ノートブックインスタンスのルートアクセス権を付与されてはなりません  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [SageMaker.4](sagemaker-controls.md#sagemaker-4)  | SageMaker エンドポイントの本番稼働バリアントの初期インスタンス数は 1 より大きい必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [SageMaker.5](sagemaker-controls.md#sagemaker-5)  | SageMaker モデルでは、ネットワーク分離を有効にする必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [SageMaker.6](sagemaker-controls.md#sagemaker-6)  | SageMaker アプリのイメージ設定にはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [SageMaker.7](sagemaker-controls.md#sagemaker-7)  | SageMaker イメージにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [SageMaker.8](sagemaker-controls.md#sagemaker-8)  | SageMaker ノートブックインスタンスは、サポートされているプラットフォームで実行する必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [SageMaker.9](sagemaker-controls.md#sagemaker-9)  |  SageMaker データ品質ジョブ定義では、コンテナ間のトラフィック暗号化を有効にする必要があります  |  AWS 基本的なセキュリティのベストプラクティス v1.0.0  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [SageMaker.10](sagemaker-controls.md#sagemaker-10)  |  SageMaker モデルの説明可能性ジョブ定義では、コンテナ間のトラフィック暗号化を有効にする必要があります  |  AWS 基本的なセキュリティのベストプラクティス v1.0.0  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [SageMaker.11](sagemaker-controls.md#sagemaker-11)  |  SageMaker データ品質ジョブ定義では、ネットワーク分離を有効にする必要があります  |  AWS 基本的なセキュリティのベストプラクティス v1.0.0  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [SageMaker.12](sagemaker-controls.md#sagemaker-12)  |  SageMaker モデルバイアスジョブ定義では、ネットワーク分離を有効にする必要があります  |  AWS 基本的なセキュリティのベストプラクティス v1.0.0  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [SageMaker.13](sagemaker-controls.md#sagemaker-13)  |  SageMaker モデル品質ジョブ定義では、コンテナ間のトラフィック暗号化を有効にする必要があります  |  AWS 基本的なセキュリティのベストプラクティス v1.0.0  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [SageMaker.14](sagemaker-controls.md#sagemaker-14)  |  SageMaker モニタリングスケジュールでは、ネットワーク分離を有効にする必要があります  |  AWS 基本的なセキュリティのベストプラクティス v1.0.0  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [SageMaker.15](sagemaker-controls.md#sagemaker-15)  |  SageMaker モデルバイアスジョブ定義では、コンテナ間のトラフィック暗号化を有効にする必要があります  |  AWS 基本的なセキュリティのベストプラクティス v1.0.0  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [SecretsManager.1](secretsmanager-controls.md#secretsmanager-1)  |  Secrets Manager のシークレットは、自動ローテーションを有効にする必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  変更によってトリガーされる  | 
|  [SecretsManager.2](secretsmanager-controls.md#secretsmanager-2)  |  自動ローテーションを設定した Secrets Manager のシークレットは正常にローテーションする必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [SecretsManager.3](secretsmanager-controls.md#secretsmanager-3)  |  未使用の Secrets Manager のシークレットを削除します  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  定期的  | 
|  [SecretsManager.4](secretsmanager-controls.md#secretsmanager-4)  |  Secrets Manager のシークレットは、指定された日数以内にローテーションする必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  定期的  | 
|  [SecretsManager.5](secretsmanager-controls.md#secretsmanager-5)  | Secrets Manager シークレットにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [ServiceCatalog.1](servicecatalog-controls.md#servicecatalog-1)  | Service Catalog ポートフォリオは AWS 組織内でのみ共有する必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [SES.1](ses-controls.md#ses-1)  | SES 連絡先リストにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [SES.2](ses-controls.md#ses-2)  | SES 設定セットにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [SES.3](ses-controls.md#ses-3)  | SES 設定セットでは、TLS を有効にして E メールを送信する必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [SNS.1](sns-controls.md#sns-1)  | SNS トピックは、保管時に を使用して暗号化する必要があります AWS KMS | NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [SNS.3](sns-controls.md#sns-3)  | SNS トピックにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [SNS.4](sns-controls.md#sns-4)  | SNS トピックアクセスポリシーでパブリックアクセスを許可しないでください | AWS 基本的なセキュリティのベストプラクティス | 重大 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [SQS.1](sqs-controls.md#sqs-1)  |  Amazon SQS キューは保管中に暗号化する必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [SQS.2](sqs-controls.md#sqs-2)  | SQS キューにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [SQS.3](sqs-controls.md#sqs-3)  | SQS キューアクセスポリシーでパブリックアクセスを許可しないでください | AWS 基本的なセキュリティのベストプラクティス | 重大 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [SSM.1](ssm-controls.md#ssm-1)  |  EC2 インスタンスは によって管理する必要があります AWS Systems Manager  |  AWS Foundational Security Best Practices v1.0.0、PCI DSS v3.2.1、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [SSM.2](ssm-controls.md#ssm-2)  |  Systems Manager によって管理される EC2 インスタンスは、パッチのインストール後に、パッチコンプライアンスのステータスが COMPLIANT である必要があります  | AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2、PCI DSS v3.2.1、PCI DSS v4.0.1 |  高  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [SSM.3](ssm-controls.md#ssm-3)  |  Systems Manager によって管理される EC2 インスタンスの関連付けコンプライアンスステータスは、COMPLIANT である必要があります  | AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、PCI DSS v3.2.1、PCI DSS v4.0.1 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [SSM.4](ssm-controls.md#ssm-4)  |  SSM ドキュメントはパブリックにしないでください  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  重大  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [SSM.5](ssm-controls.md#ssm-5)  | SSM ドキュメントにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [SSM.6](ssm-controls.md#ssm-6)  | SSM Automation では CloudWatch ログ記録が有効になっている必要があります | AWS 基本的なセキュリティのベストプラクティス v1.0.0 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [SSM.7](ssm-controls.md#ssm-7)  | SSM ドキュメントでは、パブリック共有ブロック設定を有効にする必要があります | AWS 基本的なセキュリティのベストプラクティス v1.0.0 | 重大 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [StepFunctions.1](stepfunctions-controls.md#stepfunctions-1)  |  Step Functions ステートマシンでは、ログ記録がオンになっている必要があります  | AWS Foundational Security Best Practices v1.0.0、PCI DSS v4.0.1 |  中  |  ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい  |  変更によってトリガーされる  | 
|  [StepFunctions.2](stepfunctions-controls.md#stepfunctions-2)  | Step Functions アクティビティにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Transfer.1](transfer-controls.md#transfer-1)  | Transfer Family ワークフローにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Transfer.2](transfer-controls.md#transfer-2)  | Transfer Family サーバーはエンドポイント接続に FTP プロトコルを使用しないでください | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 定期的 | 
|  [Transfer.3](transfer-controls.md#transfer-3)  | Transfer Family コネクタでは、ログ記録が有効になっている必要があります | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5 | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [Transfer.4](transfer-controls.md#transfer-4)  | Transfer Family 契約にはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Transfer.5](transfer-controls.md#transfer-5)  | Transfer Family 証明書にはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Transfer.6](transfer-controls.md#transfer-6)  | Transfer Family コネクタにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [Transfer.7](transfer-controls.md#transfer-7)  | Transfer Family プロファイルにはタグを付ける必要があります | AWS リソースタグ付け標準 | 低 | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-yes.png) はい | 変更によってトリガーされる | 
|  [WAF.1](waf-controls.md#waf-1)  |  AWS WAF Classic グローバルウェブ ACL ログ記録を有効にする必要があります  | AWS Foundational Security Best Practices、NIST SP 800-53 Rev. 5、PCI DSS v4.0.1 |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [WAF.2](waf-controls.md#waf-2)  |  AWS WAF Classic リージョンルールには少なくとも 1 つの条件が必要です  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [WAF.3](waf-controls.md#waf-3)  |  AWS WAF Classic リージョンルールグループには少なくとも 1 つのルールが必要です  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [WAF.4](waf-controls.md#waf-4)  |  AWS WAF Classic リージョンウェブ ACLs には、少なくとも 1 つのルールまたはルールグループが必要です  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [WAF.6](waf-controls.md#waf-6)  |  AWS WAF Classic グローバルルールには少なくとも 1 つの条件が必要です  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [WAF.7](waf-controls.md#waf-7)  |  AWS WAF Classic グローバルルールグループには少なくとも 1 つのルールが必要です  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [WAF.8](waf-controls.md#waf-8)  |  AWS WAF Classic グローバルウェブ ACLs には、少なくとも 1 つのルールまたはルールグループが必要です  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [WAF.10](waf-controls.md#waf-10)  |  AWS WAF ウェブ ACLs には少なくとも 1 つのルールまたはルールグループが必要です  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [WAF.11](waf-controls.md#waf-11)  |  AWS WAF ウェブ ACL ログ記録を有効にする必要があります  | NIST SP 800-53 Rev. 5、CI DSS v4.0.1 |  低  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  定期的  | 
|  [WAF.12](waf-controls.md#waf-12)  |  AWS WAF ルールでは CloudWatch メトリクスを有効にする必要があります  |  AWS Foundational Security Best Practices v1.0.0、NIST SP 800-53 Rev. 5、NIST SP 800-171 Rev. 2  |  中  |  ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ  |  変更によってトリガーされる  | 
|  [WorkSpaces.1](workspaces-controls.md#workspaces-1)  | WorkSpaces ユーザーボリュームは保管時に暗号化する必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 
|  [WorkSpaces.2](workspaces-controls.md#workspaces-2)  | WorkSpaces ルートボリュームは保管時に暗号化する必要があります | AWS 基本的なセキュリティのベストプラクティス | 中 | ![\[No\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/images/icon-no.png) いいえ | 変更によってトリガーされる | 

# Security Hub CSPM コントロールの変更ログ
<a name="controls-change-log"></a>

次の変更ログは、既存の AWS Security Hub CSPM コントロールの重要な変更を追跡します。これにより、コントロールの全体的なステータスとその検出結果のコンプライアンスステータスが変更される可能性があります。Security Hub CSPM がコントロールステータスをどのように評価するかは、「[コンプライアンスステータスとコントロールステータスの評価](controls-overall-status.md)」を参照してください。このログへの入力後、コントロールが利用可能なすべての AWS リージョン に影響するまで、変更に数日かかる場合があります。

このログは、2023 年 4 月以降に発生した変更を追跡します。コントロールを選択して、そのコントロールに関する追加の詳細を確認します。タイトルの変更は、90 日間コントロールの詳細な説明に記載されます。


| 変更日 | コントロール ID とタイトル | 変更点の説明 | 
| --- | --- | --- | 
| 2026 年 4 月 3 日 | [[EKS.2] EKS クラスターは、サポートされている Kubernetes バージョンで実行する必要があります。](eks-controls.md#eks-2) | このコントロールは、Amazon EKS クラスターが、サポートされている Kubernetes バージョンで実行されているかどうかをチェックします。Security Hub CSPM は、このコントロールのパラメータ値を `1.32` から `1.33` に変更しました。Amazon EKS での Kubernetes バージョン 1.32 の標準サポートは、2026 年 3 月 23 日に終了しました。  | 
| 2026 年 4 月 3 日 | [[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります](lambda-controls.md#lambda-2)  | Lambda がこのランタイムを廃止したruby3.2ため、サポートされているランタイムの Lambda.2 パラメータに が含まれなくなりました。 | 
| 2026 年 3 月 24 日 | [[RDS.50] RDS DB クラスターには十分なバックアップ保持期間を設定する必要があります](rds-controls.md#rds-50) | Security Hub CSPM は、コントロールがすべての RDS DB クラスターをチェックすることを反映するようにコントロールタイトルを更新しました。 | 
| 2026 年 3 月 24 日 | [[ECS.5] ECS タスク定義では、ルートファイルシステムへの読み取り専用アクセスに制限するようにコンテナを設定する必要があります](ecs-controls.md#ecs-5) | Security Hub CSPM は、コントロールが ECS タスク定義をチェックすることを反映するように、コントロールのタイトルと説明を更新しました。また、Security Hub CSPM は、`WINDOWS_SERVER`OS ファミリーを指定するように`runtimePlatform`設定された でタスク定義の結果を生成しないようにコントロールを更新しました。 | 
| 2026 年 3 月 9 日 | [AppSync.1] AWS AppSync API キャッシュは保管時に暗号化する必要があります | Security Hub CSPM はこのコントロールを廃止し、 [AWS Foundational Security Best Practices (FSBP) 標準](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html)から削除しました。 は現在および将来のすべての API キャッシュでデフォルトの暗号化を提供する AWS AppSync ようになりました。 | 
| 2026 年 3 月 9 日 | [AppSync.6] AWS AppSync API キャッシュは転送中に暗号化する必要があります | Security Hub CSPM はこのコントロールを廃止し、 [AWS Foundational Security Best Practices (FSBP) 標準](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html)から削除しました。 は現在および将来のすべての API キャッシュでデフォルトの暗号化を提供する AWS AppSync ようになりました。 | 
| 2026 年 3 月 4 日 | [ECS.1] Amazon ECS タスク定義には、セキュアなネットワークモードとユーザー定義が必要です。 | Security Hub CSPM はこのコントロールを廃止し、 [AWS Foundational Security Best Practices (FSBP) 標準](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html)および [NIST SP 800-53 Rev. 5 標準](https://docs.aws.amazon.com/securityhub/latest/userguide/nist-standard.html)から削除しました。  | 
| 2026 年 2 月 5 日 | [[AppSync.1] AWS AppSync API キャッシュは保管時に暗号化する必要があります](appsync-controls.md#appsync-1) | Security Hub CSPM は、2026 年 3 月 9 日にこのコントロールを廃止し、該当するすべての Security Hub CSPM 標準から を削除します。 AWS AppSync は、現在および将来のすべての API キャッシュでデフォルトの暗号化を提供します。 | 
| 2026 年 2 月 5 日 | [[AppSync.6] AWS AppSync API キャッシュは転送中に暗号化する必要があります](appsync-controls.md#appsync-6) | Security Hub CSPM は、2026 年 3 月 9 日にこのコントロールを廃止し、該当するすべての Security Hub CSPM 標準から を削除します。 AWS AppSync は、現在および将来のすべての API キャッシュでデフォルトの暗号化を提供します。 | 
| 2026 年 1 月 16 日 | [[ECS.1] Amazon ECS タスク定義には、セキュアなネットワークモードとユーザー定義が必要です。](ecs-controls.md#ecs-1) | Security Hub CSPM は、2026 年 2 月 16 日以降、このコントロールが廃止され、該当するすべての Security Hub CSPM 標準から削除されることを通知しました。 | 
| 2026 年 1 月 12 日 | [[Redshift.4] Amazon Redshift クラスターでは、監査ログ記録が有効になっている必要があります](redshift-controls.md#redshift-4) | Security Hub CSPM は、このコントロールを更新して `loggingEnabled`パラメータを削除しました。 | 
| 2026 年 1 月 12 日 | [MQ.3] Amazon MQ ブローカーでは、自動マイナーバージョンアップグレードが有効になっている必要があります | Security Hub CSPM はコントロールを廃止し、該当するすべての標準からコントロールを削除しました。Security Hub CSPM は、Amazon MQ の自動マイナーバージョンアップグレードの要件により、コントロールを廃止しました。 以前は、このコントロールは [AWS Foundational Security Best Practices (FSBP) 標準](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html)、[NIST SP 800-53 Rev. 5 標準](https://docs.aws.amazon.com/securityhub/latest/userguide/nist-standard.html)、および [PCI DSS v4.0.1 標準](https://docs.aws.amazon.com/securityhub/latest/userguide/pci-standard.html)に適用されていました。  | 
| 2026 年 1 月 12 日 | [[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります](lambda-controls.md#lambda-2) | このコントロールは、 AWS Lambda 関数のランタイム設定が、各言語でサポートされているランタイムの期待値と一致するかどうかをチェックします。Security Hub CSPM で、このコントロールのパラメータ値`dotnet10`として がサポートされるようになりました。このランタイムのサポート AWS Lambda が追加されました。 | 
| 2025 年 12 月 15 日 | [[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります](lambda-controls.md#lambda-2) | このコントロールは、 AWS Lambda 関数のランタイム設定が、各言語でサポートされているランタイムの期待値と一致するかどうかをチェックします。Security Hub CSPM は、このコントロールのパラメータ値`python3.9`として をサポートしなくなりました。 は、このランタイムをサポートし AWS Lambda なくなりました。 | 
| 2025 年 12 月 12 日 | [[EKS.2] EKS クラスターは、サポートされている Kubernetes バージョンで実行する必要があります。](eks-controls.md#eks-2) | このコントロールは、Amazon EKS クラスターが、サポートされている Kubernetes バージョンで実行されているかどうかをチェックします。Security Hub CSPM は、このコントロールのパラメータ値を `1.31` から `1.32` に変更しました。Amazon EKS での Kubernetes バージョン 1.31 の標準サポートは、2025 年 11 月 26 日に終了しました。  | 
| 2025 年 11 月 21 日 | [[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります](lambda-controls.md#lambda-2) | このコントロールは、 AWS Lambda 関数のランタイム設定が、各言語でサポートされているランタイムの期待値と一致するかどうかをチェックします。Security Hub CSPM は、このコントロールのパラメータ値`python3.14`として `nodejs24.x`と をサポートするようになりました。これらのランタイムのサポート AWS Lambda が追加されました。 | 
| 2025 年 11 月 14 日 | [[EC2.15] Amazon EC2 サブネットは、パブリック IP アドレスを自動的に割り当てないことをお勧めします](ec2-controls.md#ec2-15) | Security Hub CSPM は、このコントロールの説明と根拠を更新しました。以前は、コントロールは `MapPublicIpOnLaunch`フラグを使用して Amazon VPC サブネットで IPv4 パブリック IP 自動割り当てのみをチェックしていました。このコントロールは、IPv4 と IPv6 の両方のパブリック IP 自動割り当てをチェックするようになりました。コントロールの説明と根拠が更新され、これらの変更が反映されました。 | 
| 2025 年 11 月 14 日 | [[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります](lambda-controls.md#lambda-2) | このコントロールは、 AWS Lambda 関数のランタイム設定が、各言語でサポートされているランタイムの期待値と一致するかどうかをチェックします。Security Hub CSPM で、このコントロールのパラメータ値として `java25` がサポートされるようになりました。 AWS Lambda はこのランタイムのサポートを追加しました。 | 
| 2025 年 11 月 13 日 | [[SNS.4] SNS トピックアクセスポリシーはパブリックアクセスを許可しないでください](sns-controls.md#sns-4) | Security Hub CSPM は、このコントロールの重要度を から `HIGH`に変更しました`CRITICAL`。Amazon SNS トピックへのパブリックアクセスを許可すると、セキュリティ上の重大なリスクが生じます。 | 
| 2025 年 11 月 13 日 | [[SQS.3] SQS トピックアクセスポリシーはパブリックアクセスを許可しないでください](sqs-controls.md#sqs-3) | Security Hub CSPM は、このコントロールの重要度を から `HIGH`に変更しました`CRITICAL`。Amazon SQS キューへのパブリックアクセスを許可すると、セキュリティ上の重大なリスクが生じます。 | 
| 2025 年 11 月 13 日 | [[GuardDuty.7] GuardDuty EKS ランタイムモニタリングを有効にする必要があります](guardduty-controls.md#guardduty-7) | Security Hub CSPM は、このコントロールの重要度を から `MEDIUM`に変更しました`HIGH`。このタイプのランタイムモニタリングは、Amazon EKS リソースの脅威検出を強化します。 | 
| 2025 年 11 月 13 日 | [[MQ.3] Amazon MQ ブローカーでは、自動マイナーバージョンアップグレードが有効になっている必要があります](mq-controls.md#mq-3) | Security Hub CSPM は、このコントロールの重要度を から `LOW`に変更しました`MEDIUM`。マイナーバージョンアップグレードには、Amazon MQ ブローカーのセキュリティを維持するために必要なセキュリティパッチが含まれます。 | 
| 2025 年 11 月 13 日 | [[Opensearch.10] OpenSearch ドメインには、最新のソフトウェアアップデートがインストールされている必要があります](opensearch-controls.md#opensearch-10) | Security Hub CSPM は、このコントロールの重要度を から `LOW`に変更しました`MEDIUM`。ソフトウェアの更新には、OpenSearch ドメインのセキュリティを維持するために必要なセキュリティパッチが含まれます。 | 
| 2025 年 11 月 13 日 | [[RDS.7] RDS クラスターでは、削除保護が有効になっている必要があります](rds-controls.md#rds-7) | Security Hub CSPM は、このコントロールの重要度を から `LOW`に変更しました`MEDIUM`。削除保護は、Amazon RDS データベースの誤った削除や、不正なエンティティによる RDS データベースの削除を防ぐのに役立ちます。 | 
| 2025 年 11 月 13 日 | [[CloudTrail.5] CloudTrail 追跡は Amazon CloudWatch Logs と統合する必要があります](cloudtrail-controls.md#cloudtrail-5) | Security Hub CSPM は、このコントロールの重要度を から `LOW`に変更しました`MEDIUM`。Amazon CloudWatch Logs でのデータの AWS CloudTrail ログ記録は、監査アクティビティ、アラーム、その他の重要なセキュリティオペレーションに使用できます。 | 
| 2025 年 11 月 13 日 | [[ServiceCatalog.1] Service Catalog ポートフォリオは AWS 組織内でのみ共有する必要があります](servicecatalog-controls.md#servicecatalog-1) | Security Hub CSPM は、このコントロールの重要度を から `HIGH`に変更しました`MEDIUM`。 AWS Service Catalog ポートフォリオを特定のアカウントと共有することは意図的なことであり、ポートフォリオがパブリックにアクセス可能であるとは限りません。 | 
| 2025 年 11 月 13 日 | [[CloudFront.7] CloudFront ディストリビューションでは、カスタム SSL/TLS 証明書を使用する必要があります](cloudfront-controls.md#cloudfront-7) | Security Hub CSPM は、このコントロールの重要度を から `MEDIUM`に変更しました`LOW`。Amazon CloudFront ディストリビューションのデフォルト`cloudfront.net`ドメイン名はランダムに生成されるため、セキュリティリスクが軽減されます。 | 
| 2025 年 11 月 13 日 | [[ELB.7] Classic Load Balancers は、Connection Draining を有効にする必要があります](elb-controls.md#elb-7) | Security Hub CSPM は、このコントロールの重要度を から `MEDIUM`に変更しました`LOW`。マルチインスタンスデプロイでは、他の正常なインスタンスは、接続ドレイニングなしでインスタンスが終了したときにユーザーセッションを処理できるため、運用への影響と可用性のリスクが軽減されます。 | 
| 2025 年 11 月 13 日 | [[RedshiftServerless.5] Redshift サーバーレス名前空間でデフォルトの管理者ユーザー名を使用すべきではありません](redshiftserverless-controls.md#redshiftserverless-5) | Security Hub CSPM はこのコントロールを更新して、オプションの `validAdminUserNames`パラメータを削除しました。 | 
| 2025 年 10 月 23 日 | [[ElastiCache.1] ElastiCache (Redis OSS) クラスターでは自動バックアップを有効にする必要があります](elasticache-controls.md#elasticache-1) | Security Hub CSPM は、2025 年 10 月 14 日にこのコントロールのタイトル、説明、およびルールに加えられた変更を元に戻しました。 | 
| 2025 年 10 月 22 日 | [[CloudFront.1] CloudFront ディストリビューションでは、デフォルトのルートオブジェクトが設定されている必要があります](cloudfront-controls.md#cloudfront-1) | Security Hub CSPM は、このコントロールを更新し、カスタムオリジンを使用する Amazon CloudFront ディストリビューションの検出結果を生成しないようにしました。  | 
| 2025 年 10 月 16 日 | [[CloudFront.15] CloudFront ディストリビューションは、推奨される TLS セキュリティポリシーを使用する必要があります](cloudfront-controls.md#cloudfront-15) | このコントロールは、Amazon CloudFront ディストリビューションが推奨 TLS セキュリティポリシーを使用するように設定されているかどうかを確認します。Security Hub CSPM は、このコントロールのパラメータ値として `TLSv1.2_2025` と `TLSv1.3_2025` をサポートするようになりました。 | 
| 2025 年 10 月 14 日 | [[ElastiCache.1] ElastiCache (Redis OSS) クラスターでは自動バックアップを有効にする必要があります](elasticache-controls.md#elasticache-1) | Security Hub CSPM は、このコントロールのタイトル、説明、およびルールを変更しました。以前は、コントロールは [elasticache-redis-cluster-automatic-backup-check](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-redis-cluster-automatic-backup-check.html) ルールを使用して、Redis OSS クラスターとすべてのレプリケーショングループをチェックしていました。コントロールのタイトルは、*ElastiCache (Redis OSS) クラスターで自動バックアップを有効にする必要があります*です。 このコントロールは、[elasticache-automatic-backup-check-enabled](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-automatic-backup-check-enabled.html) ルールを使用して、Redis OSS クラスターとすべてのレプリケーショングループに加え、Valkey クラスターをチェックするようになりました。新しいタイトルと説明は、コントロールが両方のタイプのクラスターをチェックすることを反映しています。　  | 
| 2025 年 10 月 5 日 | [[Opensearch.10] OpenSearch ドメインには、最新のソフトウェアアップデートがインストールされている必要があります](opensearch-controls.md#opensearch-10) | このコントロールのルールが更新され、Amazon OpenSearch Service ドメインに利用可能なソフトウェア更新がなく、更新ステータスが対象外である場合にも `PASSED` 検出結果を生成するようになりました。以前は、このコントロールは OpenSearch ドメインに利用可能なソフトウェア更新がなく、更新ステータスが完了した場合にのみ `PASSED` 検出結果を生成していました。  | 
| 2025 年 9 月 24 日 | [Redshift.9] Redshift クラスターでは、デフォルトのデータベース名を使用しないでください [RedshiftServerless.7] Redshift サーバーレス名前空間では、デフォルトのデータベース名を使用しないでください | Security Hub CSPM はこれらのコントロールを廃止し、すべての該当する標準からそれらを削除しました。Security Hub CSPM は、コントロールの `FAILED` 検出結果の効果的な修復を妨げた固有の Amazon Redshift の制限により、これらのコントロールを廃止しました。 以前、このコントロールは、[AWS Foundational Security Best Practices (FSBP) 標準](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html)と[NIST SP 800-53 Rev. 5 標準](https://docs.aws.amazon.com/securityhub/latest/userguide/nist-standard.html)に適用されていました。Redshift.9 コントロールは、[AWS Control Tower サービスマネージド標準](https://docs.aws.amazon.com/securityhub/latest/userguide/service-managed-standard-aws-control-tower.html)にも適用されていました。  | 
| 2025 年 9 月 9 日 | [[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります](lambda-controls.md#lambda-2) | このコントロールは、 AWS Lambda 関数のランタイム設定が、各言語でサポートされているランタイムの期待値と一致するかどうかをチェックします。Security Hub CSPM は、このコントロールのパラメータ値として `nodejs18.x` をサポートしなくなりました。 AWS Lambda は Node.js 18 ランタイムをサポートしなくなりました。 | 
| 2025 年 8 月 13 日 | [[SageMaker.5] SageMaker モデルでは、ネットワーク分離を有効にする必要があります](sagemaker-controls.md#sagemaker-5) | Security Hub CSPM は、このコントロールのタイトルと説明を変更しました。新しいタイトルと説明は、コントロールが Amazon SageMaker AI でホストされているモデルの `EnableNetworkIsolation` パラメータの設定をチェックしていることをより正確に反映しています。以前は、このコントロールのタイトルは *SageMaker models should block inbound traffic* でした。  | 
| 2025 年 8 月 13 日 | [[EFS.6] EFS マウントターゲットは、起動時にパブリック IP アドレスを割り当てるサブネットに関連付けるべきではありません](efs-controls.md#efs-6) | Security Hub CSPM は、このコントロールのタイトルと説明を変更しました。新しいタイトルと説明は、コントロールが実行するチェックの範囲と性質をより正確に反映しています。以前は、このコントロールのタイトルは *EFS mount targets should not be associated with a public subnet* でした。  | 
| 2025 年 7 月 24 日 | [[EKS.2] EKS クラスターは、サポートされている Kubernetes バージョンで実行する必要があります。](eks-controls.md#eks-2) | このコントロールは、Amazon EKS クラスターが、サポートされている Kubernetes バージョンで実行されているかどうかをチェックします。Security Hub CSPM は、このコントロールのパラメータ値を `1.30` から `1.31` に変更しました。Amazon EKS での Kubernetes バージョン 1.30 の標準サポートは、2025 年 7 月 23 日に終了しました。  | 
| 2025 年 7 月 23 日 | [[EC2.173] 起動パラメータを含む EC2 スポットフリートリクエストは、アタッチされた EBS ボリュームの暗号化を有効にする必要があります](ec2-controls.md#ec2-173) | Security Hub CSPM は、このコントロールのタイトルを変更しました。新しいタイトルは、このコントロールが起動パラメータを指定する Amazon EC2 スポットフリートリクエストのみをチェックすることをより正確に反映しています。以前は、このコントロールのタイトルは *EC2 Spot Fleet requests should enable encryption for attached EBS volumes* でした。  | 
| 2025 年 6 月 30 日 | [[IAM.13] IAM パスワードポリシーで少なくとも 1 文字の記号が要求されていることを確認します](iam-controls.md#iam-13) | Security Hub CSPM は、[PCI DSS v4.0.1 標準](pci-standard.md)からこのコントロールを削除しました。PCI DSS v4.0.1 では、パスワードに記号を使用することを明示的に要求していません。  | 
| 2025 年 6 月 30 日 | [[IAM.17] IAM パスワードポリシーでパスワードが 90 日以内に有効期限切れとなることを確認します](iam-controls.md#iam-17) | Security Hub CSPM は、このコントロールを [NIST SP 800-171 Revision 2 標準](standards-reference-nist-800-171.md)から削除しました。NIST SP 800-171 Revision 2 では、パスワードの有効期限を 90 日以内に設定することを明示的に要求していません。  | 
| 2025 年 6 月 30 日 | [[RDS.16] Aurora DB クラスターでは、タグを DB スナップショットにコピーするように設定する必要があります](rds-controls.md#rds-16) | Security Hub CSPM は、このコントロールのタイトルを変更しました。新しいタイトルは、コントロールが Amazon Aurora DB クラスターのみをチェックすることをより正確に反映しています。以前は、このコントロールのタイトルは *RDS DB clusters should be configured to copy tags to snapshots* でした。 | 
| 2025 年 6 月 30 日 | [[SageMaker.8] SageMaker ノートブックインスタンスは、サポートされているプラットフォームで実行する必要があります](sagemaker-controls.md#sagemaker-8) | このコントロールは、Amazon SageMaker AI ノートブックインスタンスに指定されたプラットフォーム識別子に基づいて、ノートブックインスタンスがサポートされているプラットフォームで実行されるように設定されているかどうかチェックします。Security Hub CSPM は、このコントロールのパラメータ値として `notebook-al2-v1` および `notebook-al2-v2` をサポートしなくなりました。これらのプラットフォームで実行されるノートブックインスタンスは、2025 年 6 月 30 日をもってサポートは終了しました。 | 
| 2025 年 5 月 30 日 | [[IAM.10] IAM ユーザーのパスワードポリシーには強力な設定が必要です](iam-controls.md#iam-10) | Security Hub CSPM は、[PCI DSS v4.0.1 標準](pci-standard.md)からこのコントロールを削除しました。このコントロールは、IAM ユーザーのアカウントパスワードポリシーが、パスワードの最小長 7 文字を含む最小要件を満たしているかどうかをチェックします。PCI DSS v4.0.1 では、8 文字以上のパスワードが必要です。このコントロールは、異なるパスワード要件を持つ PCI DSS v3.2.1 標準に引き続き適用されます。 PCI DSS v4.0.1 の要件に照らしてアカウントのパスワードポリシーを評価するには、[IAM.7 コントロール](iam-controls.md#iam-7)を使用できます。このコントロールでは、8 文字以上のパスワードが必要です。また、パスワードの長さやその他のパラメータのカスタム値もサポートしています。IAM.7 コントロールは、Security Hub CSPM における PCI DSS v4.0.1 標準の一部です。  | 
| 2025 年 5 月 8 日 | [RDS.46] RDS DB インスタンスは、インターネットゲートウェイへのルートを持つパブリックサブネットにデプロイすべきではありません | Security Hub CSPM は、すべての AWS リージョンで RDS.46 コントロールのリリースをロールバックしました。以前は、このコントロールは AWS Foundational Security Best Practices (FSBP) 標準をサポートしていました。 | 
| 2025 年 4 月 7 日 | [[ELB.17] リスナーを使用する Application Load Balancer と Network Load Balancer は、推奨されるセキュリティポリシーを使用する必要があります。](elb-controls.md#elb-17) | このコントロールは、Application Load Balancer 用の HTTPS リスナーまたは Network Load Balancer 用の TLS リスナーが、推奨されるセキュリティポリシーを使用して転送中のデータを暗号化するように設定されているかどうかをチェックします。Security Hub CSPM は、このコントロールで `ELBSecurityPolicy-TLS13-1-2-Res-2021-06` と `ELBSecurityPolicy-TLS13-1-2-Res-FIPS-2023-04` の 2 つの追加のパラメータ値をサポートするようになりました。 | 
| 2025 年 3 月 27 日 | [[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります](lambda-controls.md#lambda-2) | このコントロールは、 AWS Lambda 関数のランタイム設定が、各言語でサポートされているランタイムの期待値と一致するかどうかを確認します。Security Hub CSPM は、このコントロールのパラメータ値`ruby3.4`として をサポートするようになりました。このランタイムのサポート AWS Lambda が追加されました。 | 
| 2025 年 3 月 26 日 | [[EKS.2] EKS クラスターは、サポートされている Kubernetes バージョンで実行する必要があります。](eks-controls.md#eks-2) | このコントロールは、Amazon Elastic Kubernetes Service (Amazon EKS) クラスターが、サポートされている Kubernetes バージョンで実行されるかどうかをチェックします。`oldestVersionSupported` パラメータの場合、Security Hub CSPM は値を `1.29` から `1.30` に変更しました。現在、サポートされている最も古い Kubernetes バージョンは `1.30` です。 | 
| 2025 年 3 月 10 日 | [[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります](lambda-controls.md#lambda-2) | このコントロールは、 AWS Lambda 関数のランタイム設定が、各言語でサポートされているランタイムの期待値と一致するかどうかを確認します。Security Hub CSPM は、このコントロールのパラメータ値`python3.8`として `dotnet6`および をサポートしなくなりました。 は、これらのランタイムをサポートし AWS Lambda なくなりました。 | 
| 2025 年 3 月 7 日 | [[RDS.18] RDS インスタンスは VPC 内にデプロイする必要があります](rds-controls.md#rds-18) | Security Hub CSPM は、NIST SP 800-53 Rev. 5 要件の AWS Foundational Security Best Practices 標準および自動チェックからこのコントロールを削除しました。Amazon EC2-Classic ネットワークが廃止されたため、Amazon Relational Database Service (Amazon RDS) インスタンスを VPC の外部にデプロイできなくなりました。コントロールは引き続き [AWS Control Tower サービスマネージド標準](service-managed-standard-aws-control-tower.md)の一部です。 | 
| 2025 年 1 月 10 日 | [Glue.2] AWS Glue ジョブではログ記録を有効にする必要があります | Security Hub CSPM はこのコントロールを廃止し、すべての標準から削除しました。 | 
| 2024 年 12 月 20 日 | EC2.61～EC2.169  | Security Hub CSPM は、EC2.61 から EC2.169 までのコントロールのリリースをロールバックしました。 | 
| 2024 年 12 月 12 日 | [[RDS.23] RDS インスタンスはデータベースエンジンのデフォルトポートを使用しないようにする必要があります](rds-controls.md#rds-23)  | RDS.23 は、Amazon Relational Database Service (Amazon RDS) クラスターまたはインスタンスがデータベースエンジンのデフォルトポート以外のポートを使用しているかどうかをチェックします。コントロールを更新し、基盤となる AWS Config ルールがクラスターの一部である RDS インスタンスNOT\$1APPLICABLEに対して の結果を返すようにしました。 | 
| 2024 年 12 月 2 日 | [[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります](lambda-controls.md#lambda-2)  | Lambda.2 は、ランタイムの AWS Lambda 関数設定が、各言語でサポートされているランタイムに設定された想定値と一致するかどうかを確認します。Security Hub CSPM では、パラメータとして nodejs22.x がサポートされるようになりました。 | 
| 2024 年 11 月 26 日 | [[EKS.2] EKS クラスターは、サポートされている Kubernetes バージョンで実行する必要があります。](eks-controls.md#eks-2)  | このコントロールは、Amazon Elastic Kubernetes Service (Amazon EKS) クラスターが、サポートされている Kubernetes バージョンで実行されるかどうかをチェックします。現在、サポートされている最も古いバージョンは 1.29 です。 | 
| 2024 年 11 月 20 日 | [[Config.1] を有効にし、サービスにリンクされたロールをリソース記録に使用 AWS Config する必要があります](config-controls.md#config-1)  | Config.1 AWS Config は、 が有効になっているかどうかをチェックし、サービスにリンクされたロールを使用し、有効なコントロールのリソースを記録します。Security Hub CSPM は、このコントロールの重要度を `MEDIUM` から `CRITICAL` に引き上げました。Security Hub CSPM は、Config.1 の検出に失敗した[新しいステータスコードとステータス理由](controls-findings-create-update.md#control-findings-asff-compliance)も追加しました。これらの変更は、Security Hub CSPM コントロールのオペレーションに対する Config.1 の重要性を反映しています。 AWS Config または リソースの記録が無効になっている場合、不正確なコントロール結果を受け取る可能性があります。 Config.1 の `PASSED` 検出結果を受け取るには、有効な Security Hub CSPM コントロールに対応するリソースのリソース記録をオンにし、組織で必要のないコントロールを無効にします。Security Hub CSPM AWS Config の を設定する手順については、「」を参照してください[Security Hub CSPM AWS Config の有効化と設定](securityhub-setup-prereqs.md)。Security Hub CSPM のコントロールとその対応するリソースのリストについては、「[コントロールの検出結果に必要な AWS Config リソース](controls-config-resources.md)」を参照してください。 | 
| 2024 年 11 月 12 日 | [[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります](lambda-controls.md#lambda-2)  | Lambda.2 は、ランタイムの AWS Lambda 関数設定が、各言語でサポートされているランタイムに設定された想定値と一致するかどうかを確認します。Security Hub CSPM では、パラメータとして python3.13 がサポートされるようになりました。 | 
| 2024 年 10 月 11 日 | ElastiCache コントロール  | ElastiCache.3、ElastiCache.4、ElastiCache.5、および ElastiCache.7 のコントロールのタイトルを変更しました。コントロールは ElastiCache for Valkey にも適用されるため、タイトルは Redis OSS で言及されなくなりました。 | 
| 2024 年 9 月 27 日 | [[ELB.4] Application Load Balancer は、無効な http ヘッダーを削除するように設定する必要があります](elb-controls.md#elb-4)  | タイトルを「Application Load Balancer は、httpヘッダーを削除するように設定する必要があります」から「Application Load Balancer は無効な http ヘッダーを削除するように設定する必要があります」に変更しました。 | 
| 2024 年 8 月 19 日 | DMS.12 および ElastiCache コントロールのタイトルの変更  | DMS.12 および ElastiCache.1 から ElastiCache.7 までのコントロールのタイトルを変更しました。Amazon ElastiCache (Redis OSS) サービスの名前変更を反映するように、これらのタイトルを変更しました。 | 
| 2024 年 8 月 15 日 | [[Config.1] を有効にし、サービスにリンクされたロールをリソース記録に使用 AWS Config する必要があります](config-controls.md#config-1)  | Config.1 AWS Config は、 が有効になっているかどうかをチェックし、サービスにリンクされたロールを使用し、有効なコントロールのリソースを記録します。Security Hub CSPM は、includeConfigServiceLinkedRoleCheck という名前のカスタムコントロールパラメータを追加しました。このパラメータを false に設定することで、 AWS Config がサービスにリンクされたロールを使用するかどうかの確認をオプトアウトできます。 | 
| 2024 年 7 月 31 日 | [[IoT.1] AWS IoT Device Defender セキュリティプロファイルにはタグを付ける必要があります](iot-controls.md#iot-1)  | コントロールのタイトルを「AWS IoT Core セキュリティプロファイルにタグ付けする必要があります」から「AWS IoT Device Defender セキュリティプロファイルにタグ付けする必要があります」に変更しました。 | 
| 2024 年 7 月 29 日 | [[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります](lambda-controls.md#lambda-2)  | Lambda.2 は、ランタイムの AWS Lambda 関数設定が、各言語でサポートされているランタイムに設定された想定値と一致するかどうかを確認します。Security Hub CSPM では、パラメータとして nodejs16.x がサポートされなくなりました。 | 
| 2024 年 7 月 29 日 | [[EKS.2] EKS クラスターは、サポートされている Kubernetes バージョンで実行する必要があります。](eks-controls.md#eks-2)  | このコントロールは、Amazon Elastic Kubernetes Service (Amazon EKS) クラスターが、サポートされている Kubernetes バージョンで実行されるかどうかをチェックします。サポートされている最も古いバージョンは 1.28 です。 | 
| 2024 年 6 月 25 日 | [[Config.1] を有効にし、サービスにリンクされたロールをリソース記録に使用 AWS Config する必要があります](config-controls.md#config-1)  | このコントロール AWS Config は、 が有効になっているかどうかをチェックし、サービスにリンクされたロールを使用し、有効なコントロールのリソースを記録します。Security Hub CSPM は、コントロールの評価を反映するようにコントロールのタイトルを更新しました。 | 
| 2024 年 6 月 14 日 | [[RDS.34] Aurora MySQL DB クラスターでは、監査ログを CloudWatch Logs に発行する必要があります](rds-controls.md#rds-34)  | このコントロールは、Amazon Aurora MySQL DB クラスターが監査ログを Amazon CloudWatch Logs に発行するように設定されているかどうかをチェックします。Security Hub CSPM は、Aurora Serverless v1 DB クラスターの検出結果を生成しないようにコントロールを更新しました。 | 
| 2024 年 6 月 11 日 | [[EKS.2] EKS クラスターは、サポートされている Kubernetes バージョンで実行する必要があります。](eks-controls.md#eks-2)  | このコントロールは、Amazon Elastic Kubernetes Service (Amazon EKS) クラスターが、サポートされている Kubernetes バージョンで実行されるかどうかをチェックします。サポートされている最も古いバージョンは 1.27 です。 | 
| 2024 年 6 月 10 日 | [[Config.1] を有効にし、サービスにリンクされたロールをリソース記録に使用 AWS Config する必要があります](config-controls.md#config-1)  | このコントロール AWS Config は、 が有効で、 AWS Config リソース記録が有効になっているかどうかを確認します。以前は、コントロールは、すべてのリソースに対して記録を設定した場合のみ PASSED 検出結果を生成していました。Security Hub CSPM は、有効なコントロールに必要なリソースの記録が有効になっているときに PASSED 検出結果を生成するようにコントロールを更新しました。コントロールも更新され、 AWS Config サービスにリンクされたロールが使用されているかどうかが確認されました。これにより、必要なリソースを記録するためのアクセス許可が提供されます。 | 
| 2024 年 5 月 8 日 | [[S3.20] S3 汎用バケットでは MFA 削除が有効になっている必要があります](s3-controls.md#s3-20)  | このコントロールは、Amazon S3 の汎用バージョンバケットで多要素認証 (MFA) 削除が有効になっているかどうかをチェックします。以前は、コントロールはライフサイクル設定を持つバケットの FAILED 検出結果を生成していました。ただし、ライフサイクル設定を持つバケットでは、バージョニングによる MFA 削除を有効にすることはできません。Security Hub CSPM は、ライフサイクル設定を持つバケットの検出結果を生成しないようにコントロールを更新しました。コントロールの説明は、現在の動作を反映して更新されました。 | 
| 2024 年 5 月 2 日 | [[EKS.2] EKS クラスターは、サポートされている Kubernetes バージョンで実行する必要があります。](eks-controls.md#eks-2)  | Security Hub CSPM は、Amazon EKS クラスターが成功の検出結果を生成するために実行できる Kubernetes のサポートされている最も古いバージョンを更新しました。現在サポートされている最も古いバージョンは Kubernetes 1.26 です。 | 
| 2024 年 4 月 30 日 | [[CloudTrail.3] 少なくとも 1 つの CloudTrail 証跡を有効にする必要があります](cloudtrail-controls.md#cloudtrail-3)  | コントロールのタイトルを「CloudTrail を有効にする必要があります」から「少なくとも 1 つの CloudTrail 証跡を有効にする必要があります」に変更しました。このコントロールは現在、 AWS アカウント で少なくとも 1 つの CloudTrail 証跡が有効になっている場合にPASSED検出結果を生成します。現在の動作を正確に反映するように、タイトルと説明が変更されました。 | 
| 2024 年 4 月 29 日 | [[AutoScaling.1] ロードバランサーに関連付けられた Auto Scaling グループは ELB ヘルスチェックを使用する必要がある](autoscaling-controls.md#autoscaling-1)  | コントロールのタイトルを「Classic Load Balancer に関連付けられた Auto Scaling グループはロードバランサーのヘルスチェックを使用する必要があります」から「ロードバランサーに関連付けられた Auto Scaling グループは ELB ヘルスチェックを使用する必要があります」に変更しました。このコントロールは現在、アプリケーション、ゲートウェイ、ネットワーク、Classic Load Balancer を評価します。現在の動作を正確に反映するように、タイトルと説明が変更されました。 | 
| 2024 年 4 月 19 日 | [[CloudTrail.1] CloudTrail を有効にして、少なくとも 1 つのマルチリージョンの追跡で、読み取りと書き込みの管理イベントを含めた設定をする必要があります。](cloudtrail-controls.md#cloudtrail-1)  | コントロール AWS CloudTrail は、 が有効で、読み取りおよび書き込み管理イベントを含む少なくとも 1 つのマルチリージョン証跡で設定されているかどうかを確認します。以前は、アカウントで CloudTrail が有効で、少なくとも 1 つのマルチリージョン証跡が設定されていると、証跡がキャプチャされた読み取りおよび書き込み管理イベントがない場合でも、コントロールは誤って PASSED 検出結果を生成していました。コントロールは、CloudTrail が有効で、読み取りおよび書き込み管理イベントをキャプチャする少なくとも 1 つのマルチリージョン証跡で設定されている場合にのみ、PASSED 検出結果を生成するようになりました。 | 
| 2024 年 4 月 10 日 | [Athena.1] Athena ワークグループは、保管中に暗号化する必要があります  | Security Hub CSPM はこのコントロールを廃止し、すべての標準から削除しました。Athena ワークグループは、Amazon Simple Storage Service (Amazon S3) バケットにログを送信します。Amazon S3 では、新規および既存の S3 バケットで S3 マネージドキー (SS3-S3) によるデフォルトの暗号化を提供するようになりました。 | 
| 2024 年 4 月 10 日 | [AutoScaling.4] Auto Scaling グループの起動設定では、メタデータ応答ホップ制限が 1 を超えることはできません  | Security Hub CSPM はこのコントロールを廃止し、すべての標準から削除しました。Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのメタデータ応答ホップ制限はワークロードによって異なります。 | 
| 2024 年 4 月 10 日 | [CloudFormation.1] CloudFormation スタックは、Simple Notification Service (SNS) と統合させる必要があります  | Security Hub CSPM はこのコントロールを廃止し、すべての標準から削除しました。 AWS CloudFormation スタックを Amazon SNS トピックと統合することは、もはやセキュリティのベストプラクティスではありません。重要な CloudFormation スタックを SNS トピックと統合することは便利ですが、すべてのスタックに必要というわけではありません。 | 
| 2024 年 4 月 10 日 | [CodeBuild.5] CodeBuild プロジェクト環境では特権モードを有効にしないでください  | Security Hub CSPM はこのコントロールを廃止し、すべての標準から削除しました。CodeBuild プロジェクトで特権モードを有効にしても、顧客環境に追加のリスクは課されません。 | 
| 2024 年 4 月 10 日 | [IAM.20] ルートユーザーの使用を避けます  | Security Hub CSPM はこのコントロールを廃止し、すべての標準から削除しました。このコントロールの目的は、別のコントロール [[CloudWatch.1] 「ルート」ユーザーの使用に対するログメトリクスフィルターとアラームが存在する必要があります](cloudwatch-controls.md#cloudwatch-1) でカバーされています。 | 
| 2024 年 4 月 10 日 | [SNS.2] トピックに送信される通知メッセージでは、配信ステータスのログ記録を有効にする必要があります  | Security Hub CSPM はこのコントロールを廃止し、すべての標準から削除しました。SNS トピックの配信ステータスのログ記録は、もはやセキュリティのベストプラクティスではありません。重要な SNS トピックの配信ステータスのログ記録は便利ですが、すべてのトピックに必要というわけではありません。 | 
| 2024 年 4 月 10 日 | [[S3.10] バージョニングが有効になっている S3 汎用バケットにはライフサイクル設定が必要です](s3-controls.md#s3-10)  | Security Hub CSPM は、このコントロールを AWS Foundational Security Best Practices および Service-Managed Standard: から削除しました AWS Control Tower。このコントロールの目的は、[[S3.13] S3 汎用バケットにはライフサイクル設定が必要です](s3-controls.md#s3-13) と [[S3.14] S3 汎用バケットではバージョニングが有効になっている必要があります](s3-controls.md#s3-14) の 2 つの他のコントロールでカバーされています。このコントロールは依然として NIST SP 800-53 Rev. 5 の一部です。 | 
| 2024 年 4 月 10 日 | [[S3.11] S3 汎用バケットでは、イベント通知を有効にする必要があります](s3-controls.md#s3-11)  | Security Hub CSPM は、このコントロールを AWS Foundational Security Best Practices および Service-Managed Standard: から削除しました AWS Control Tower。S3 バケットのイベント通知が役立つ場合もありますが、これは一般的なセキュリティのベストプラクティスではありません。このコントロールは依然として NIST SP 800-53 Rev. 5 の一部です。 | 
| 2024 年 4 月 10 日 | [[SNS.1] SNS トピックは、保管時に を使用して暗号化する必要があります AWS KMS](sns-controls.md#sns-1)  | Security Hub CSPM は、このコントロールを AWS Foundational Security Best Practices および Service-Managed Standard: から削除しました AWS Control Tower。デフォルトでは、SNS はディスク暗号化を使用して保管中のトピックを暗号化します。詳細については、「[データの暗号化](https://docs.aws.amazon.com/sns/latest/dg/sns-data-encryption.html)」を参照してください。 AWS KMS を使用してトピックを暗号化することは、セキュリティのベストプラクティスとしては推奨されなくなりました。このコントロールは依然として NIST SP 800-53 Rev. 5 の一部です。 | 
| 2024 年 4 月 8 日 | [[ELB.6] アプリケーション、ゲートウェイ、および Network Load Balancer で削除保護を有効にする必要があります](elb-controls.md#elb-6)  | コントロールのタイトルを「Application Load Balancer の削除保護を有効化する必要があります」から「アプリケーション、ゲートウェイ、および Network Load Balancer で削除保護が有効になっている必要があります」に変更しました。このコントロールは現在、アプリケーション、ゲートウェイ、Network Load Balancer を評価します。現在の動作を正確に反映するように、タイトルと説明が変更されました。 | 
| 2024 年 3 月 22 日 | [[Opensearch.8] OpenSearch ドメインへの接続は最新の TLS セキュリティポリシーを使用して暗号化する必要があります](opensearch-controls.md#opensearch-8)  | コントロールのタイトルを「OpenSearch ドメインへの接続は TLS 1.2 を使用して暗号化する必要があります」から「OpenSearch ドメインへの接続は最新の TLS セキュリティポリシー を使用して暗号化する必要があります」に変更しました。以前は、コントロールは OpenSearch ドメインへの接続で TLS 1.2 が使用されたかどうかのみを確認していました。コントロールは、OpenSearch ドメインが最新の TLS セキュリティポリシーを使用して暗号化されている場合に PASSED 検出結果を生成するようになりました。コントロールのタイトルと説明は、現在の動作を反映して更新されました。 | 
| 2024 年 3 月 22 日 | [[ES.8] Elasticsearch ドメインへの接続は最新の TLS セキュリティポリシーを使用して暗号化する必要があります](es-controls.md#es-8)  | コントロールのタイトルを「Elasticsearch ドメインへの接続は TLS 1.2 を使用して暗号化する必要があります」から「Elasticsearch ドメインへの接続は最新の TLS セキュリティポリシー を使用して暗号化する必要があります」に変更しました。以前は、コントロールは Elasticsearch ドメインへの接続で TLS 1.2 が使用されたかどうかのみを確認していました。コントロールは、Elasticsearch ドメインが最新の TLS セキュリティポリシーを使用して暗号化されている場合に PASSED 検出結果を生成するようになりました。コントロールのタイトルと説明は、現在の動作を反映して更新されました。 | 
| 2024 年 3 月 12 日 | [[S3.1] S3 汎用バケットではブロックパブリックアクセスの設定が有効になっている必要があります。](s3-controls.md#s3-1)  | タイトルを「S3 パブリックアクセスブロック設定を有効にする必要があります」から「S3 汎用バケットではパブリックアクセスブロック設定を有効にする必要があります」に変更しました。Security Hub CSPM は、新しい S3 バケットタイプを考慮してタイトルを変更しました。 | 
| 2024 年 3 月 12 日 | [[S3.2] S3 汎用バケットはパブリック読み取りアクセスをブロックする必要があります](s3-controls.md#s3-2)  | タイトルを「S3 バケットはパブリック読み取りアクセスを禁止する必要があります」から「S3 汎用バケットはパブリック読み取りアクセスをブロックする必要があります」に変更しました。Security Hub CSPM は、新しい S3 バケットタイプを考慮してタイトルを変更しました。 | 
| 2024 年 3 月 12 日 | [[S3.3] S3 汎用バケットではパブリック書き込みアクセスをブロックする必要があります。](s3-controls.md#s3-3)  | タイトルを「S3 バケットではパブリック書き込みアクセスを禁止する必要があります」から「S3 汎用バケットではパブリック書き込みアクセスをブロックする必要があります」に変更しました。Security Hub CSPM は、新しい S3 バケットタイプを考慮してタイトルを変更しました。 | 
| 2024 年 3 月 12 日 | [[S3.5] S3 汎用バケットではリクエストに SSL を使用する必要があります。](s3-controls.md#s3-5)  | タイトルを「S3 バケットでは Secure Socket Layer を使用するリクエストが必要です」から「S3 汎用バケットでは SSL を使用するリクエストが必要です」に変更しました。Security Hub CSPM は、新しい S3 バケットタイプを考慮してタイトルを変更しました。 | 
| 2024 年 3 月 12 日 | [[S3.6] S3 汎用バケットポリシーは、他の へのアクセスを制限する必要があります AWS アカウント](s3-controls.md#s3-6)  | タイトルを「バケットポリシーで他の AWS アカウント に付与される S3 アクセス許可を制限する必要があります」から「S3 汎用バケットポリシーは他の AWS アカウントへのアクセスを制限する必要があります」に変更しました。Security Hub CSPM は、新しい S3 バケットタイプを考慮してタイトルを変更しました。 | 
| 2024 年 3 月 12 日 | [[S3.7] S3 汎用バケットでクロスリージョンレプリケーションを使用する必要があります](s3-controls.md#s3-7)  | タイトルを「S3 バケットではクロスリージョンレプリケーションが有効になっている必要があります」から「S3 汎用バケットではクロスリージョンレプリケーションを使用する必要があります」に変更しました。Security Hub CSPM は、新しい S3 バケットタイプを考慮してタイトルを変更しました。 | 
| 2024 年 3 月 12 日 | [[S3.7] S3 汎用バケットでクロスリージョンレプリケーションを使用する必要があります](s3-controls.md#s3-7)  | タイトルを「S3 バケットではクロスリージョンレプリケーションが有効になっている必要があります」から「S3 汎用バケットではクロスリージョンレプリケーションを使用する必要があります」に変更しました。Security Hub CSPM は、新しい S3 バケットタイプを考慮してタイトルを変更しました。 | 
| 2024 年 3 月 12 日 | [[S3.8] S3 汎用バケットはパブリックアクセスをブロックする必要があります](s3-controls.md#s3-8)  | タイトルを「S3 パブリックアクセスブロック設定はバケットレベルで有効にする必要があります」から「S3 汎用バケットはパブリックアクセスをブロックする必要があります」に変更しました。Security Hub CSPM は、新しい S3 バケットタイプを考慮してタイトルを変更しました。 | 
| 2024 年 3 月 12 日 | [[S3.9] S3 汎用バケットは、サーバーアクセスログ記録を有効にする必要があります](s3-controls.md#s3-9)  | タイトルを「S3 バケットサーバーのアクセスログ記録を有効にする必要があります」から「S3 汎用バケット のサーバーアクセスログ記録を有効にする必要があります」に変更しました。Security Hub CSPM は、新しい S3 バケットタイプを考慮してタイトルを変更しました。 | 
| 2024 年 3 月 12 日 | [[S3.10] バージョニングが有効になっている S3 汎用バケットにはライフサイクル設定が必要です](s3-controls.md#s3-10)  | タイトルを「バージョニングが有効になっている S3 バケットはライフサイクルポリシーを設定する必要があります」から「バージョニングが有効になっている S3 汎用バケットはライフサイクルポリシーを設定する必要があります」に変更しました。Security Hub CSPM は、新しい S3 バケットタイプを考慮してタイトルを変更しました。 | 
| 2024 年 3 月 12 日 | [[S3.11] S3 汎用バケットでは、イベント通知を有効にする必要があります](s3-controls.md#s3-11)  | タイトルを「S3 バケットではイベント通知が有効になっている必要があります」から「S3 汎用バケットではイベント通知が有効になっている必要があります」に変更しました。Security Hub CSPM は、新しい S3 バケットタイプを考慮してタイトルを変更しました。 | 
| 2024 年 3 月 12 日 | [[S3.12] ACL は、S3 汎用バケットへのユーザーアクセスの管理に使用しないでください。](s3-controls.md#s3-12)  | タイトルを「S3 アクセスコントロールリスト (ACLs) はバケットへのユーザーアクセスを管理するのに使用しないでください」から「ACLs へのユーザーアクセスは S3 汎用バケット へのユーザーアクセスを管理するために使用しないでください」に変更しました。Security Hub CSPM は、新しい S3 バケットタイプを考慮してタイトルを変更しました。 | 
| 2024 年 3 月 12 日 | [[S3.13] S3 汎用バケットにはライフサイクル設定が必要です](s3-controls.md#s3-13)  | タイトルを「S3 バケットはライフサイクルポリシーをから設定する必要があります」から「S3 汎用バケットはライフサイクル設定する必要があります」に変更しました。Security Hub CSPM は、新しい S3 バケットタイプを考慮してタイトルを変更しました。 | 
| 2024 年 3 月 12 日 | [[S3.14] S3 汎用バケットではバージョニングが有効になっている必要があります](s3-controls.md#s3-14)  | タイトルを「S3 バケットはバージョニングを使用する必要があります」から「S3 汎用バケットでバージョニングが有効になっている必要があります」に変更しました。Security Hub CSPM は、新しい S3 バケットタイプを考慮してタイトルを変更しました。 | 
| 2024 年 3 月 12 日 | [[S3.15] S3 汎用バケットでは Object Lock が有効になっている必要があります](s3-controls.md#s3-15)  | タイトルを「S3 バケットは Object Lock を使用するように設定する必要があります」から「S3 汎用バケットでは Object Lock が有効になっている必要があります」に変更しました。Security Hub CSPM は、新しい S3 バケットタイプを考慮してタイトルを変更しました。 | 
| 2024 年 3 月 12 日 | [[S3.17] S3 汎用バケットは保管時に で暗号化する必要があります AWS KMS keys](s3-controls.md#s3-17)  | タイトルを「S3 バケットを保管時に AWS KMS keysで暗号化する必要があります」から「S3 汎用バケットを保管時に AWS KMS keysで暗号化する必要があります」に変更しました。Security Hub CSPM は、新しい S3 バケットタイプを考慮してタイトルを変更しました。 | 
| 2024 年 3 月 7 日 | [[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります](lambda-controls.md#lambda-2)  | Lambda.2 は、ランタイムの AWS Lambda 関数設定が、各言語でサポートされているランタイムに設定された想定値と一致するかどうかを確認します。Security Hub CSPM では、パラメータとして nodejs20.x および ruby3.3 がサポートされるようになりました。 | 
| 2024 年 2 月 22 日 | [[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります](lambda-controls.md#lambda-2)  | Lambda.2 は、ランタイムの AWS Lambda 関数設定が、各言語でサポートされているランタイムに設定された想定値と一致するかどうかを確認します。Security Hub CSPM では、パラメータとして dotnet8 がサポートされるようになりました。 | 
| 2024 年 2 月 5 日 | [[EKS.2] EKS クラスターは、サポートされている Kubernetes バージョンで実行する必要があります。](eks-controls.md#eks-2)  | Security Hub CSPM は、Amazon EKS クラスターが成功の検出結果を生成するために実行できる Kubernetes のサポートされている最も古いバージョンを更新しました。現在サポートされている最も古いバージョンは Kubernetes 1.25 です。 | 
| 2024 年 1 月 10 日 | [[CodeBuild.1] CodeBuild Bitbucket ソースリポジトリの URL には機密認証情報を含めないでください](codebuild-controls.md#codebuild-1)  | タイトルを「CodeBuild GitHub または Bitbucket のソースリポジトリの URL は OAuth を使用する必要があります」から「CodeBuild Bitbucket ソースリポジトリ URL に機密認証情報 を含めないでください」に変更しました。Security Hub CSPM は、他の接続方法も安全であるため、OAuth に関する言及を削除しました。Security Hub CSPM は GitHub のソースリポジトリの URL に個人用アクセストークンまたはユーザー名とパスワードを持つことができなくなったため、GitHub の言及を削除しました。 | 
| 2024 年 1 月 8 日 | [[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります](lambda-controls.md#lambda-2)  | Lambda.2 は、ランタイムの AWS Lambda 関数設定が、各言語でサポートされているランタイムに設定された想定値と一致するかどうかを確認します。廃止されたランタイムであるため、Security Hub CSPM ではパラメータとして go1.x および java8 がサポートされなくなりました。 | 
| 2023 年 12 月 29 日 | [[RDS.8] RDS DB インスタンスで、削除保護が有効になっている必要があります](rds-controls.md#rds-8)  | RDS.8 は、サポートされているデータベースエンジンのいずれかを使用する Amazon RDS DB インスタンスで削除保護が有効になっているかどうかをチェックします。Security Hub CSPM では custom-oracle-ee、oracle-ee-cdb、および oracle-se2-cdb がデータベースエンジンとしてサポートされるようになりました。 | 
| 2023 年 12 月 22 日 | [[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります](lambda-controls.md#lambda-2)  | Lambda.2 は、ランタイムの AWS Lambda 関数設定が、各言語でサポートされているランタイムに設定された想定値と一致するかどうかを確認します。Security Hub CSPM では、パラメータとして java21 および python3.12 がサポートされるようになりました。Security Hub CSPM では、パラメータとして ruby2.7 がサポートされなくなりました。 | 
| 2023 年 12 月 15 日 | [[CloudFront.1] CloudFront ディストリビューションでは、デフォルトのルートオブジェクトが設定されている必要があります](cloudfront-controls.md#cloudfront-1)  | CloudFront.1 は、Amazon CloudFront ディストリビューションにデフォルトルートオブジェクトが設定されているかどうかを確認します。Security Hub CSPM では、このコントロールの重大度が CRITICAL から HIGH に下げられました。これは、デフォルトルートオブジェクトを追加することがユーザーのアプリケーションと特定の要件に依存する推奨事項であるためです。 | 
| 2023 年 12 月 5 日  | [[EC2.13] セキュリティグループは、0.0.0.0/0 または ::/0 からポート 22 への入力を許可しないようにする必要があります](ec2-controls.md#ec2-13)  | コントロールタイトルが「セキュリティグループでは 0.0.0.0/0 からポート 22 へのイングレスは許可しない必要があります」から「セキュリティグループでは 0.0.0.0/0 または ::/0 からポート 22 へのイングレスは許可しない必要があります」に変更されました。 | 
| 2023 年 12 月 5 日  | [[EC2.14] セキュリティグループは、0.0.0.0/0 または ::/0 からポート 3389 への入力を許可しないようにする必要があります](ec2-controls.md#ec2-14)  | コントロールタイトルが「セキュリティグループでは 0.0.0.0/0 からポート 3389 へのイングレスは許可されないことを確認します」から「セキュリティグループでは 0.0.0.0/0 または ::/0 からポート 3389 へのイングレスは許可しない必要があります」に変更されました。 | 
| 2023 年 12 月 5 日  | [[RDS.9] RDS DB インスタンスは CloudWatch Logs にログを発行する必要があります](rds-controls.md#rds-9)  | コントロールタイトルが「データベースのログ記録を有効にする必要があります」から「RDS DB インスタンスは CloudWatch Logs にログを発行する必要があります」に変更されました。Security Hub CSPM では、このコントロールはログが Amazon CloudWatch Logs に発行されているかどうかのみをチェックし、RDS ログが有効になっているかどうかはチェックしません。RDS DB インスタンスが CloudWatch Logs にログを発行するように設定されている場合、このコントロールは PASSED 検出結果を生成します。コントロールタイトルは、現在の動作を反映して更新されました。 | 
| 2023 年 12 月 5 日 | [[EKS.8] EKS クラスターでは、監査ログ記録が有効になっている必要があります](eks-controls.md#eks-8)  | このコントロールは、Amazon EKS クラスターで監査ログ記録が有効になっているかどうかをチェックします。Security Hub CSPM がこのコントロールを評価するために使用する AWS Config ルールが から eks-cluster-logging-enabledに変更されましたeks-cluster-log-enabled。 | 
| 2023 年 11 月 17 日  | [[EC2.19] セキュリティグループは、リスクの高いポートへの無制限アクセスを許可してはいけません](ec2-controls.md#ec2-19)  | EC2.19 は、指定した高リスクと見なされるポートにセキュリティグループの無制限の受信トラフィックがアクセス可能かどうかをチェックします。Security Hub CSPM では、セキュリティグループルールのソースとして提供される場合、マネージド型プレフィックスリストを考慮するようにこのコントロールが更新されました。コントロールは、プレフィックスリストに文字列「0.0.0.0/0」または「::/0」が含まれている場合、FAILED 検出結果を生成します。 | 
| 2023 年 11 月 16 日  | [[CloudWatch.15] CloudWatch アラームには、指定されたアクションが設定されている必要があります](cloudwatch-controls.md#cloudwatch-15)  | コントロールタイトルが「CloudWatch アラームには ALARM 状態用に設定されたアクションが必要です」から、「CloudWatch アラームには、指定されたアクションが設定されている必要があります」に変更されました。 | 
| 2023 年 11 月 16 日  | [[CloudWatch.16] CloudWatch ロググループは指定した期間保持する必要があります](cloudwatch-controls.md#cloudwatch-16)  | コントロールタイトルが「CloudWatch ロググループは少なくとも 1 年間保持する必要があります」から「CloudWatch ロググループは指定された期間保持する必要があります」に変更されました。 | 
| 2023 年 11 月 16 日  | [[Lambda.5] VPC Lambda 関数は複数のアベイラビリティーゾーンで運用する必要があります](lambda-controls.md#lambda-5)  | コントロールタイトルが「VPC Lambda 関数は複数のアベイラビリティーゾーンで運用する必要があります」から「VPC Lambda 関数は複数のアベイラビリティーゾーンで運用する必要があります」に変更されました。 | 
| 2023 年 11 月 16 日  | [[AppSync.2] AWS AppSync フィールドレベルのログ記録を有効にする必要があります](appsync-controls.md#appsync-2)  | コントロールタイトルが「AWS AppSync は、リクエストレベルとフィールドレベルのログ記録をオンにする必要があります」から「AWS AppSync はフィールドレベルのログ記録を有効にする必要があります」に変更されました。 | 
| 2023 年 11 月 16 日  | [[EMR.1] Amazon EMR クラスタープライマリノードは、パブリック IP アドレスを未設定にする必要があります](emr-controls.md#emr-1)  | コントロールタイトルが「Amazon Elastic MapReduce クラスターマスターノードは、パブリック IP アドレスを未設定にする必要があります」から「Amazon EMR クラスタープライマリノードは、パブリック IP アドレスを未設定にする必要があります」に変更されました。 | 
| 2023 年 11 月 16 日  | [[Opensearch.2] OpenSearch ドメインがパブリックにアクセスできないようにする必要があります](opensearch-controls.md#opensearch-2)  | コントロールタイトルが「OpenSearch ドメインは VPC 内に含まれている必要があります」から「OpenSearch ドメインがパブリックにアクセスできないようにする必要があります」に変更されました。 | 
| 2023 年 11 月 16 日  | [[ES.2] Elasticsearch ドメインがパブリックにアクセスできないようにする必要があります](es-controls.md#es-2)  | コントロールタイトルが「Elasticsearch ドメインは VPC 内に含まれている必要があります」から「Elasticsearch ドメインがパブリックにアクセスできないようにする必要があります」に変更されました。 | 
| 2023 年 10 月 31 日  | [[ES.4] CloudWatch Logs への Elasticsearch ドメインエラーログ記録を有効にする必要があります](es-controls.md#es-4)  | ES.4 は Elasticsearch ドメインが、Amazon CloudWatch Logs にエラーログを送信するように設定されているかどうかを確認します。このコントロールは以前、CloudWatch Logs に送信するように設定されているログを含む Elasticsearch ドメインの PASSED 検出結果を生成していました。Security Hub CSPM は、CloudWatch Logs にエラーログを送信するように設定された Elasticsearch ドメインのみの PASSED 検出結果を生成するようにコントロールを更新しました。コントロールも更新され、エラーログをサポートしない Elasticsearch バージョンを評価から除外するようになりました。 | 
| 2023 年 10 月 16 日  | [[EC2.13] セキュリティグループは、0.0.0.0/0 または ::/0 からポート 22 への入力を許可しないようにする必要があります](ec2-controls.md#ec2-13)  | EC2.13 は、セキュリティグループがポート 22 への無制限のイングレスアクセスを許可しているかどうかをチェックします。Security Hub CSPM では、セキュリティグループルールのソースとして提供される場合、マネージド型プレフィックスリストを考慮するようにこのコントロールが更新されました。コントロールは、プレフィックスリストに文字列「0.0.0.0/0」または「::/0」が含まれている場合、FAILED 検出結果を生成します。 | 
| 2023 年 10 月 16 日  | [[EC2.14] セキュリティグループは、0.0.0.0/0 または ::/0 からポート 3389 への入力を許可しないようにする必要があります](ec2-controls.md#ec2-14)  | EC2.14 は、セキュリティグループがポート 3389 への無制限のイングレスアクセスを許可しているかどうかをチェックします。Security Hub CSPM では、セキュリティグループルールのソースとして提供される場合、マネージド型プレフィックスリストを考慮するようにこのコントロールが更新されました。コントロールは、プレフィックスリストに文字列「0.0.0.0/0」または「::/0」が含まれている場合、FAILED 検出結果を生成します。 | 
| 2023 年 10 月 16 日  | [[EC2.18] セキュリティグループは、許可されたポートに対して無制限の着信トラフィックのみを許可することをお勧めします](ec2-controls.md#ec2-18)  | EC2.18 は、使用中のセキュリティグループが、無制限の受信トラフィックを許可しているかどうかをチェックします。Security Hub CSPM では、セキュリティグループルールのソースとして提供される場合、マネージド型プレフィックスリストを考慮するようにこのコントロールが更新されました。コントロールは、プレフィックスリストに文字列「0.0.0.0/0」または「::/0」が含まれている場合、FAILED 検出結果を生成します。 | 
| 2023 年 10 月 16 日  | [[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります](lambda-controls.md#lambda-2)  | Lambda.2 は、ランタイムの AWS Lambda 関数設定が、各言語でサポートされているランタイムに設定された想定値と一致するかどうかを確認します。Security Hub CSPM では、パラメータとして python3.11 がサポートされるようになりました。 | 
| 2023 年 10 月 4 日  | [[S3.7] S3 汎用バケットでクロスリージョンレプリケーションを使用する必要があります](s3-controls.md#s3-7)  | Security Hub CSPM は、S3 CROSS-REGION バケットで同じリージョンのレプリケーションではなくクロスリージョンレプリケーションを有効にするために、ReplicationType という値を持つパラメータが追加されました。 | 
| 2023 年 9 月 27 日  | [[EKS.2] EKS クラスターは、サポートされている Kubernetes バージョンで実行する必要があります。](eks-controls.md#eks-2)  | Security Hub CSPM は、Amazon EKS クラスターが成功の検出結果を生成するために実行できる Kubernetes のサポートされている最も古いバージョンを更新しました。現在サポートされている最も古いバージョンは Kubernetes 1.24 です。 | 
| 2023 年 9 月 20 日  | [CloudFront.2] CloudFront ディストリビューションでは、オリジンアクセスアイデンティティを有効にする必要があります  | Security Hub CSPM はこのコントロールを廃止し、すべての標準から削除しました。代わりに、「[[CloudFront.13] CloudFront ディストリビューションでは、オリジンアクセスコントロールを有効にする必要があります](cloudfront-controls.md#cloudfront-13)」を参照してください。オリジンのアクセスコントロールは、現在のセキュリティのベストプラクティスです。このコントロールは 90 日後にドキュメントから削除されます。 | 
| 2023 年 9 月 20 日  | [[EC2.22] 未使用の Amazon EC2 セキュリティグループを削除することをお勧めします](ec2-controls.md#ec2-22)  | Security Hub CSPM は AWS 、 Foundational Security Best Practices (FSBP) と National Institute of Standards and Technology (NIST) SP 800-53 Rev. 5 からこのコントロールを削除しました。これはまだサービスマネージドスタンダードの一部です AWS Control Tower。この コントロールでは、セキュリティグループが EC2 インスタンス、または Elastic Network Interface にアタッチされている場合に、合格の検出結果を生成します。ただし、特定のユースケースでは、セキュリティグループがアタッチされていなくてもセキュリティ上のリスクはありません。他の EC2 コントロール (EC2.2、EC2.13、EC2.14、EC2.18、EC2.19 など) を使用すると、セキュリティグループをモニタリングできます。 | 
| 2023 年 9 月 20 日  | [EC2.29] EC2 インスタンスは VPC で起動することをお勧めします  | Security Hub CSPM はこのコントロールを廃止し、すべての標準から削除しました。Amazon EC2 では、EC2-Classic インスタンスが VPC に移行されました。このコントロールは 90 日後にドキュメントから削除されます。 | 
| 2023 年 9 月 20 日  | [S3.4] S3 バケットでは、サーバー側の暗号化を有効にする必要があります  | Security Hub CSPM はこのコントロールを廃止し、すべての標準から削除しました。Amazon S3 では、新規および既存の S3 バケットで S3 マネージドキー (SS3-S3) によるデフォルトの暗号化を提供するようになりました。SS3-S3 または SS3-KMS のサーバー側の暗号化を使用して暗号化された既存のバケットの場合、暗号化設定は変更されません。このコントロールは 90 日後にドキュメントから削除されます。 | 
| 2023 年 9 月 14 日  | [[EC2.2] VPC のデフォルトのセキュリティグループでは、インバウンドトラフィックまたはアウトバウンドトラフィックを許可しないようにすることをお勧めします](ec2-controls.md#ec2-2)  | コントロールタイトルを「VPC のデフォルトのセキュリティグループでは、インバウンドトラフィックとアウトバウンドトラフィックを許可しないようにする必要があります」から「VPC のデフォルトのセキュリティグループ (複数可) では、インバウンドトラフィックまたはアウトバウンドトラフィックを許可しないようにする必要があります」に変更しました。 | 
| 2023 年 9 月 14 日  | [[IAM.9] ルートユーザーに対して MFA を有効にする必要があります](iam-controls.md#iam-9)  | コントロールタイトルを「ルートユーザーに対して仮想 MFA を有効にする必要があります」から「ルートユーザーに対して MFA を有効にする必要があります」に変更しました。 | 
|  2023 年 9 月 14 日  | [[RDS.19] 重大なクラスターイベントについて、既存の RDS イベント通知サブスクリプションを設定する必要があります](rds-controls.md#rds-19)  | コントロールタイトルを「重大なクラスターイベントについて、RDS イベント通知のサブスクリプションを設定する必要があります」から「重大なクラスターイベントに対して、既存の RDS イベント通知サブスクリプションを設定する必要があります」に変更しました。 | 
| 2023 年 9 月 14 日  | [[RDS.20] 重大なデータベースインスタンスイベントに対して、既存の RDS イベント通知サブスクリプションを設定する必要があります](rds-controls.md#rds-20)  | コントロールタイトルを「重大なデータベースインスタンスイベントに対して RDS イベント通知サブスクリプションを設定する必要があります」から「重大なデータベースインスタンスイベントに対して、既存の RDS イベント通知サブスクリプションを設定する必要があります」に変更しました。 | 
| 2023 年 9 月 14 日  | [[WAF.2] AWS WAF Classic リージョンルールには少なくとも 1 つの条件が必要です](waf-controls.md#waf-2)  | コントロールタイトルを「WAF リージョンルールには、1 つ以上の条件が必要です」から「AWS WAF Classic リージョンルールには、1 つ以上の条件が必要です」に変更しました。 | 
| 2023 年 9 月 14 日  | [[WAF.3] AWS WAF Classic リージョンルールグループには少なくとも 1 つのルールが必要です](waf-controls.md#waf-3)  | コントロールタイトルを「WAF リージョンルールグループには、1 つ以上の条件が必要です」から「AWS WAF Classic リージョンルールグループには、1 つ以上の条件が必要です」に変更しました。 | 
| 2023 年 9 月 14 日  | [[WAF.4] AWS WAF Classic Regional Web ACLs には、少なくとも 1 つのルールまたはルールグループが必要です](waf-controls.md#waf-4)  | コントロールタイトルを「WAF リージョンウェブ ACL には、1 つ以上のルールまたはルールグループが必要です」から「AWS WAF Classic リージョンウェブ ACL には、1 つ以上のルールまたはルールグループが必要です」に変更しました。 | 
| 2023 年 9 月 14 日  | [[WAF.6] AWS WAF Classic グローバルルールには少なくとも 1 つの条件が必要です](waf-controls.md#waf-6)  | コントロールタイトルを「WAF グローバルルールには、1 つ以上の条件が必要です」から「AWS WAF Classic グローバルルールには、1 つ以上の条件が必要です」に変更しました。 | 
| 2023 年 9 月 14 日  | [[WAF.7] AWS WAF Classic グローバルルールグループには少なくとも 1 つのルールが必要です](waf-controls.md#waf-7)  | コントロールタイトルを「WAF グローバルルールグループには、1 つ以上の条件が必要です」から「AWS WAF Classic グローバルルールグループには、1 つ以上の条件が必要です」に変更しました。 | 
| 2023 年 9 月 14 日  | [[WAF.8] AWS WAF Classic グローバルウェブ ACLs には、少なくとも 1 つのルールまたはルールグループが必要です](waf-controls.md#waf-8)  | コントロールタイトルを「WAF グローバルウェブ ACL には、1 つ以上のルールまたはルールグループが必要です」から「AWS WAF Classic グローバルウェブ ACL には、1 つ以上のルールまたはルールグループが必要です」に変更しました。 | 
| 2023 年 9 月 14 日  | [[WAF.10] AWS WAF ウェブ ACLs には少なくとも 1 つのルールまたはルールグループが必要です](waf-controls.md#waf-10)  | コントロールタイトルを「WAFv2 ウェブ ACL には、1 つ以上のルールまたはルールグループが必要です」から「AWS WAF ウェブ ACL には、1 つ以上のルールまたはルールグループが必要です」に変更しました。 | 
| 2023 年 9 月 14 日  | [[WAF.11] AWS WAF ウェブ ACL ログ記録を有効にする必要があります](waf-controls.md#waf-11)  | コントロールタイトルを「AWS WAF v2 ウェブ ACL ログ記録を有効にする必要があります」から「AWS WAF ウェブ ACL ログ記録を有効にする必要があります」に変更しました。 | 
|  2023 年 7 月 20 日  | [S3.4] S3 バケットでは、サーバー側の暗号化を有効にする必要があります  | S3.4 は、Amazon S3 バケットでサーバー側の暗号化が有効になっているか、または S3 バケットポリシーでサーバー側の暗号化なしの PutObject リクエストを明示的に拒否しているかどうかをチェックします。Security Hub CSPM はこのコントロールを更新し、KMS キーによる二層式サーバー側の暗号化 (DSSE-KMS) を追加しました。S3 バケットが SSE-S3、SSE-KMS、または DSSE-KMS で暗号化されている場合、このコントロールは合格の検出結果を生成します。 | 
| 2023 年 7 月 17 日  | [[S3.17] S3 汎用バケットは保管時に で暗号化する必要があります AWS KMS keys](s3-controls.md#s3-17)  | S3.17 は Amazon S3 バケットが AWS KMS keyで暗号化されているかどうかをチェックします。Security Hub CSPM はこのコントロールを更新し、KMS キーによる二層式サーバー側の暗号化 (DSSE-KMS) を追加しました。S3 バケットが SSE-KMS または DSSE-KMS で暗号化されている場合、このコントロールは合格の検出結果を生成します。 | 
| 2023 年 6 月 9 日  | [[EKS.2] EKS クラスターは、サポートされている Kubernetes バージョンで実行する必要があります。](eks-controls.md#eks-2)  | EKS.2 は、Amazon EKS クラスターがサポートされている Kubernetes バージョンで実行されているかどうかをチェックします。サポートされている最も古いバージョンは現在のところ、1.23 です。 | 
| 2023 年 6 月 9 日  | [[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります](lambda-controls.md#lambda-2)  | Lambda.2 は、ランタイムの AWS Lambda 関数設定が、各言語でサポートされているランタイムに設定された想定値と一致するかどうかを確認します。Security Hub CSPM では、パラメータとして ruby3.2 がサポートされるようになりました。 | 
| 2023 年 6 月 5 日  | [[APIGateway.5] API Gateway REST API のキャッシュデータは、保管中に暗号化する必要があります](apigateway-controls.md#apigateway-5)  | APIGateway.5.は、Amazon API Gateway REST API ステージのすべてのメソッドが保存時に暗号化されているかどうかをチェックします。Security Hub CSPM を更新し、特定のメソッドのキャッシュが有効になっている場合にのみ、そのメソッドの暗号化を評価するようにしました。 | 
| 2023 年 5 月 18 日  | [[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります](lambda-controls.md#lambda-2)  | Lambda.2 は、ランタイムの AWS Lambda 関数設定が、各言語でサポートされているランタイムに設定された想定値と一致するかどうかを確認します。Security Hub CSPM では、パラメータとして java17 がサポートされるようになりました。 | 
| 2023 年 5 月 18 日  | [[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります](lambda-controls.md#lambda-2)  | Lambda.2 は、ランタイムの AWS Lambda 関数設定が、各言語でサポートされているランタイムに設定された想定値と一致するかどうかを確認します。Security Hub CSPM では、パラメータとして nodejs12.x がサポートされなくなりました。 | 
| 2023 年 4 月 23 日  | [[ECS.10] ECS Fargate サービスは、最新の Fargate プラットフォームバージョンで実行する必要があります。](ecs-controls.md#ecs-10)  | ECS.10 は、Amazon ECS Fargate サービスが最新の Fargate プラットフォームバージョンで実行されているかどうかをチェックします。お客様は ECS を通じて直接、または CodeDeploy を使用して Amazon ECS をデプロイできます。Security Hub CSPM では、このコントロールが更新され、CodeDeploy を使用して ECS Fargate サービスをデプロイすると [成功] という検出結果が表示されるようになりました。 | 
| 2023 年 4 月 20 日  | [[S3.6] S3 汎用バケットポリシーは、他の へのアクセスを制限する必要があります AWS アカウント](s3-controls.md#s3-6)  | S3.6 は、Amazon Simple Storage Service (Amazon S3) バケットポリシーによって、他の のプリンシパルが S3 バケット内のリソースに対して拒否 AWS アカウント されたアクションを実行できないかどうかを確認します。Security Hub CSPM では、このコントロールが更新され、バケットポリシーの条件を考慮するようになりました。 | 
| 2023 年 4 月 18 日  | [[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります](lambda-controls.md#lambda-2)  | Lambda.2 は、ランタイムの AWS Lambda 関数設定が、各言語でサポートされているランタイムに設定された想定値と一致するかどうかを確認します。Security Hub CSPM では、パラメータとして python3.10 がサポートされるようになりました。 | 
| 2023 年 4 月 18 日  | [[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります](lambda-controls.md#lambda-2)  | Lambda.2 は、ランタイムの AWS Lambda 関数設定が、各言語でサポートされているランタイムに設定された想定値と一致するかどうかを確認します。Security Hub CSPM では、パラメータとして dotnetcore3.1 がサポートされなくなりました。 | 
| 2023 年 4 月 17 日  | [[RDS.11] RDS インスタンスでは、自動バックアップが有効になっている必要があります](rds-controls.md#rds-11)  | RDS.11 は、Amazon RDS インスタンスで自動バックアップが有効になっているかどうか、およびバックアップ保持期間が 7 日以上であるかどうかをチェックします。Security Hub CSPM では、このコントロールが更新され、リードレプリカを評価から除外するようになりました。すべてのエンジンがリードレプリカの自動バックアップをサポートしているわけではないためです。また、RDS には、リードレプリカの作成時にバックアップ保持期間を指定するオプションはありません。リードレプリカは、デフォルトでバックアップ保持期間 0 で作成されます。 | 

# の Security Hub CSPM コントロール AWS アカウント
<a name="account-controls"></a>

これらの Security Hub CSPM コントロールは を評価します AWS アカウント。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [Account.1] のセキュリティ連絡先情報を に提供する必要があります AWS アカウント
<a name="account-1"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/1.2、NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/security-account-information-provided.html](https://docs.aws.amazon.com/config/latest/developerguide/security-account-information-provided.html)

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

**パラメータ :** なし

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

代替のセキュリティ連絡先により AWS 、 は、利用できなくなった場合に、アカウントの問題について別のユーザーに連絡することができます。通知は サポート、 AWS アカウント の使用に関連するセキュリティ関連のトピックに関する または他の AWS のサービス チームから行うことができます。

### 修正
<a name="account-1-remediation"></a>

代替連絡先を のセキュリティ連絡先として追加するには AWS アカウント、「 *AWS アカウント管理リファレンスガイド*[」の「 の代替連絡先の更新 AWS アカウント](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-alternate.html)」を参照してください。

## [Account.2] は AWS Organizations 組織の一部 AWS アカウント である必要があります
<a name="account-2"></a>

**カテゴリ:** 保護 > セキュアなアクセス管理 > アクセスコントロール

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/account-part-of-organizations.html](https://docs.aws.amazon.com/config/latest/developerguide/account-part-of-organizations.html)

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

**パラメータ :** なし

このコントロールは、 AWS アカウント が で管理されている組織の一部であるかどうかをチェックします AWS Organizations。アカウントが組織の一部ではない場合、コントロールは失敗します。

Organizations を使用すると、ワークロードのスケーリングに合わせて環境を一元管理できます AWS。特定のセキュリティ要件があるワークロードの分離や、HIPAA または PCI といったフレームワークへの準拠のため、 AWS アカウント を複数使用できます。組織を作成することで、複数のアカウントを 1 つのユニットとして管理し AWS のサービス、それらのアクセス、リソース、リージョンを一元管理できます。

### 修正
<a name="account-2-remediation"></a>

新しい組織を作成して自動的に追加するには、 AWS アカウント *AWS Organizations 「 ユーザーガイド*」の[「組織の作成](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_create.html)」を参照してください。既存の組織にアカウントを追加するには、「 *AWS Organizations ユーザーガイド*[」の「組織 AWS アカウント への の招待](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html)」を参照してください。

# の Security Hub CSPM コントロール AWS Amplify
<a name="amplify-controls"></a>

これらの Security Hub CSPM コントロールは、 AWS Amplify サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [Amplify.1] Amplify アプリにはタグを付ける必要があります
<a name="amplify-1"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::Amplify::App`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/amplify-app-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/amplify-app-tagged.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | 評価されたリソースに割り当てる必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目) | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし | 

このコントロールは、 AWS Amplify アプリケーションに `requiredKeyTags`パラメータで指定されたタグキーがあるかどうかをチェックします。アプリにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。`requiredKeyTags` パラメータの値を指定しない場合、コントロールはタグキーの存在のみをチェックし、アプリにタグキーがない場合に失敗します。このコントロールはシステムタグを無視します。システムタグは自動的に付与され、`aws:` プレフィックスが付きます。

タグは、 AWS リソースを作成して割り当てるラベルです。各タグは、必要なタグキーとオプションのタグ値で設定されています。タグを使用して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。またそれらは、アクションと通知のリソース所有者を追跡するのにも役立ちます。タグを使用して、認可戦略として属性ベースのアクセス制御 (ABAC) を実装することもできます。ABAC 戦略の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。タグの詳細については、[「 AWS リソースのタグ付け」および「タグエディタユーザーガイド](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。

**注記**  
個人を特定できる情報 (PII) などの機密情報や秘匿性の高い情報はタグに格納しないでください。タグには多くの からアクセスできます AWS のサービス。それらは、プライベートデータや機密データに使用することを意図していません。

### 修正
<a name="amplify-1-remediation"></a>

 AWS Amplify アプリにタグを追加する方法については、「 ホスティングユーザーガイド[」の「リソースタグ付けのサポート](https://docs.aws.amazon.com/amplify/latest/userguide/resource-tagging-support-chapter.html)」を参照してください。 *AWS Amplify *

## [Amplify.2] Amplify ブランチにはタグを付ける必要があります
<a name="amplify-2"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::Amplify::Branch`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/amplify-branch-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/amplify-branch-tagged.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | 評価されたリソースに割り当てる必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目) | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし | 

このコントロールは、 AWS Amplify ブランチに `requiredKeyTags`パラメータで指定されたタグキーがあるかどうかをチェックします。ブランチにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。`requiredKeyTags` パラメータに値を指定しない場合、コントロールはタグキーの存在のみをチェックし、ブランチにタグキーがない場合に失敗します。このコントロールはシステムタグを無視します。システムタグは自動的に付与され、`aws:` プレフィックスが付きます。

タグは、 AWS リソースを作成して割り当てるラベルです。各タグは、必要なタグキーとオプションのタグ値で設定されています。タグを使用して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。またそれらは、アクションと通知のリソース所有者を追跡するのにも役立ちます。タグを使用して、認可戦略として属性ベースのアクセス制御 (ABAC) を実装することもできます。ABAC 戦略の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。タグの詳細については、[「 AWS リソースのタグ付け」および「タグエディタユーザーガイド](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。

**注記**  
個人を特定できる情報 (PII) などの機密情報や秘匿性の高い情報はタグに格納しないでください。タグには多くの からアクセスできます AWS のサービス。それらは、プライベートデータや機密データに使用することを意図していません。

### 修正
<a name="amplify-2-remediation"></a>

 AWS Amplify ブランチにタグを追加する方法については、[「 ホスティングユーザーガイド」の「リソースタグ付けのサポート](https://docs.aws.amazon.com/amplify/latest/userguide/resource-tagging-support-chapter.html)*AWS Amplify *」を参照してください。

# Amazon API Gateway の Security Hub CSPM コントロール
<a name="apigateway-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon API Gateway サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [APIGateway.1] API Gateway REST および WebSocket API 実行ログ記録を有効にする必要があります
<a name="apigateway-1"></a>

**関連する要件:** NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-7(8)

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

**重要度:** 中

**リソースタイプ:** `AWS::ApiGateway::Stage`、`AWS::ApiGatewayV2::Stage`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/api-gw-execution-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/api-gw-execution-logging-enabled.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `loggingLevel`  |  ログ記録レベル  |  列挙型  |  `ERROR`, `INFO`  |  `No default value`  | 

このコントロールは、Amazon API Gateway REST または WebSocket API のすべてのステージでログ記録が有効になっているかどうかをチェックします。API のすべてのステージで、`loggingLevel` が `ERROR` でも `INFO` でもない場合、コントロールは失敗します。特定のログタイプを有効にする必要があることを示すカスタムパラメータ値を指定しない限り、Security Hub CSPM は、ログレベルが `ERROR`または のいずれかである場合に合格した結果を生成します`INFO`。

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

### 修正
<a name="apigateway-1-remediation"></a>

REST および WebSocket API オペレーションのログ記録を有効にするには、「API Gateway 開発者ガイド」の「[API Gateway コンソールを使用した CloudWatch による API のログの設定](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-logging.html#set-up-access-logging-using-console)」を参照してください。

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

**関連する要件:** NIST.800-53.r5 AC-17(2)、NIST.800-53.r5 AC-4、NIST.800-53.r5 IA-5(1)、NIST.800-53.r5 SC-12(3)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-23、NIST.800-53.r5 SC-23(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-8、NIST.800-53.r5 SC-8(1)、NIST.800-53.r5 SC-8(2)、NIST.800-53.r5 SI-7(6)、NIST.800-171.r2 3.13.15

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/api-gw-ssl-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/api-gw-ssl-enabled.html)

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

**パラメータ:** なし

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

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

### 修正
<a name="apigateway-2-remediation"></a>

API Gateway REST API SSL 証明書を生成し設定する方法の詳細については、「API Gateway 開発者ガイド」の「[バックエンド認証用 SSL 証明書の生成と設定](https://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started-client-side-ssl-authentication.html)」を参照してください。

## [APIGateway.3] API Gateway REST API ステージでは、 AWS X-Ray トレースを有効にする必要があります
<a name="apigateway-3"></a>

**関連する要件:** NIST.800-53.r5 CA-7

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

**重要度:** 低

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/api-gw-xray-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/api-gw-xray-enabled.html)

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

**パラメータ :** なし

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

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

### 修正
<a name="apigateway-3-remediation"></a>

API Gateway REST API オペレーションの X-Ray アクティブトレースを有効にする方法の詳細については、[AWS X-Ray 開発者ガイド]の[[AWS X-Rayの Amazon API Gateway アクティブトレースサポート](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-apigateway.html)]を参照してください。

## [APIGateway.4] API Gateway は、WAF ウェブ ACL に関連付けられている必要があります
<a name="apigateway-4"></a>

**関連する要件:** NIST.800-53.r5 AC-4(21)

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/api-gw-associated-with-waf.html](https://docs.aws.amazon.com/config/latest/developerguide/api-gw-associated-with-waf.html)

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

**パラメータ :** なし

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

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

### 修正
<a name="apigateway-4-remediation"></a>

API Gateway コンソールを使用して AWS WAF リージョンウェブ ACL を既存の API Gateway API ステージに関連付ける方法については、「 API *Gateway デベロッパーガイド*」の[「 を使用して AWS WAF API を保護する APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html)」を参照してください。

## [APIGateway.5] API Gateway REST API のキャッシュデータは、保管中に暗号化する必要があります
<a name="apigateway-5"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SI-7(6)

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

**重要度:** 中

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

**AWS Config rule:** `api-gw-cache-encrypted` (カスタム Security Hub CSPM ルール)

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

**パラメータ:** なし

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

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

API Gateway REST API キャッシュは、セキュリティを強化するために、保管中に暗号化する必要があります。

### 修正
<a name="apigateway-5-remediation"></a>

ステージの API キャッシュを設定するには、「*API Gateway デベロッパーガイド*」の「[Amazon API Gateway のキャッシュを有効にする](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-caching.html#enable-api-gateway-caching)」を参照してください。**[キャッシュ設定]** で、**[キャッシュデータを暗号化する]** を選択します。

## [APIGateway.8] API Gateway ルートには認可タイプを指定する必要があります
<a name="apigateway-8"></a>

**関連する要件:** NIST.800-53.r5 AC-3、NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/api-gwv2-authorization-type-configured.html](https://docs.aws.amazon.com/config/latest/developerguide/api-gwv2-authorization-type-configured.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `authorizationType`  |  API ルートの認可タイプ  |  列挙型  |  `AWS_IAM`, `CUSTOM`, `JWT`  |  デフォルト値なし  | 

このコントロールは、Amazon API Gateway ルートに認可タイプが設定されているかどうかを確認します。API Gateway ルートで認可タイプが指定されていない場合、コントロールは失敗します。`authorizationType` パラメータで指定された認可タイプをルートが使用する場合にのみコントロールを成功させたい場合は、必要に応じてカスタムパラメータ値を指定できます。

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

### 修正
<a name="apigateway-8-remediation"></a>

HTTP API の認可タイプを設定するには、「*API Gateway デベロッパーガイド*」の「[API Gateway での HTTP API へのアクセスの制御と管理](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-access-control.html)」を参照してください。WebSocket API の認可タイプを設定するには、「*API Gateway デベロッパーガイド*」の「[API Gateway での WebSocket API へのアクセスの制御と管理](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-control-access.html)」を参照してください。

## [APIGateway.9] API Gateway V2 ステージにアクセスロギングを設定する必要があります
<a name="apigateway-9"></a>

**関連する要件:** NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-7(8)、PCI DSS v4.0.1/10.4.2

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/api-gwv2-access-logs-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/api-gwv2-access-logs-enabled.html)

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

**パラメータ :** なし

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

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

その他のベストプラクティスについては、「*API Gateway デベロッパーガイド*」の「[REST API のモニタリング](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-monitor.html)」を参照してください。

### 修正
<a name="apigateway-9-remediation"></a>

アクセスログ記録を設定するには、「*API Gateway デベロッパーガイド*」の「[API Gateway コンソールを使用した CloudWatch による API のログの設定](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-logging.html#set-up-access-logging-using-console)」を参照してください。

## [APIGateway.10] API Gateway V2 統合では、プライベート接続に HTTPS を使用する必要があります
<a name="apigateway-10"></a>

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

**重要度:** 中

**リソースタイプ :** `AWS::ApiGatewayV2::Integration`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/apigatewayv2-integration-private-https-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/apigatewayv2-integration-private-https-enabled.html)

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

**パラメータ :** なし

このコントロールは、API Gateway V2 統合でプライベート接続に対して HTTPS が有効になっているかどうかを確認します。プライベート接続に TLS が設定されていない場合、コントロールは失敗します。

VPC リンクは API Gateway をプライベートリソースに接続します。VPC リンクはプライベート接続を作成しますが、本質的にデータを暗号化しません。TLS を設定すると、API Gateway を介してクライアントからバックエンドへのend-to-end暗号化に HTTPS を使用できます。TLS を使用しない場合、機密性の高い API トラフィックはプライベート接続間で暗号化されません。HTTPS 暗号化は、データ傍受、man-in-the-middle攻撃、認証情報の漏洩からプライベート接続を介してトラフィックを保護します。

### 修正
<a name="apigateway-10-remediation"></a>

API Gateway v2 統合でプライベート接続の転送中の暗号化を有効にするには、*Amazon API Gateway デベロッパーガイド*」の[「プライベート統合の更新](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-private-integration.html#set-up-private-integration-update)」を参照してください。プライベート統合が HTTPS プロトコルを使用するように [TLS 設定](https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/apis-apiid-integrations-integrationid.html#apis-apiid-integrations-integrationid-model-tlsconfig)を構成します。

# の Security Hub CSPM コントロール AWS AppConfig
<a name="appconfig-controls"></a>

これらの Security Hub CSPM コントロールは、 AWS AppConfig サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [AppConfig.1] AWS AppConfig アプリケーションにはタグを付ける必要があります
<a name="appconfig-1"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::AppConfig::Application`

**AWS Config ルール :** `appconfig-application-tagged`

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、 AWS AppConfig アプリケーションにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。アプリケーションにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、アプリケーションにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="appconfig-1-remediation"></a>

 AWS AppConfig アプリケーションにタグを追加するには、 *AWS AppConfig API リファレンス*[https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_TagResource.html](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_TagResource.html)の「」を参照してください。

## [AppConfig.2] AWS AppConfig 設定プロファイルにはタグを付ける必要があります
<a name="appconfig-2"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::AppConfig::ConfigurationProfile`

**AWS Config ルール :** `appconfig-configuration-profile-tagged`

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、 AWS AppConfig 設定プロファイルにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。設定プロファイルにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、設定プロファイルにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、* AWS 「 リソースのタグ付けとタグエディタユーザーガイド」の*[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。

### 修正
<a name="appconfig-2-remediation"></a>

 AWS AppConfig 設定プロファイルにタグを追加するには、 *AWS AppConfig API リファレンス*[https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_TagResource.html](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_TagResource.html)の「」を参照してください。

## [AppConfig.3] AWS AppConfig 環境にはタグを付ける必要があります
<a name="appconfig-3"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::AppConfig::Environment`

**AWS Config ルール :** `appconfig-environment-tagged`

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、 AWS AppConfig 環境にパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。環境にタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、環境にキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="appconfig-3-remediation"></a>

 AWS AppConfig 環境にタグを追加するには、 *AWS AppConfig API リファレンス*[https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_TagResource.html](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_TagResource.html)の「」を参照してください。

## [AppConfig.4] AWS AppConfig 拡張機能の関連付けにはタグを付ける必要があります
<a name="appconfig-4"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::AppConfig::ExtensionAssociation`

**AWS Config ルール :** `appconfig-extension-association-tagged`

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、 AWS AppConfig 拡張機能の関連付けにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。拡張機能の関連付けにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、拡張機能の関連付けにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="appconfig-4-remediation"></a>

 AWS AppConfig 拡張機能の関連付けにタグを追加するには、 *AWS AppConfig API リファレンス*[https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_TagResource.html](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_TagResource.html)の「」を参照してください。

# Amazon AppFlow の Security Hub CSPM コントロール
<a name="appflow-controls"></a>

これらの Security Hub CSPM コントロールは、Amazon AppFlow サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [AppFlow.1] Amazon AppFlow フローにはタグを付ける必要があります
<a name="appflow-1"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::AppFlow::Flow`

**AWS Config ルール :** `appflow-flow-tagged`

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon AppFlow フローにパラメータ `requiredKeyTags` で定義された特定のキーを含むタグがあるかどうかをチェックします。フローにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、フローにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="appflow-1-remediation"></a>

Amazon AppFlow フローにタグを追加するには、「*Amazon AppFlow ユーザーガイド*」の「[Creating flows in Amazon AppFlow](https://docs.aws.amazon.com/appflow/latest/userguide/flows-manage.html)」を参照してください。

# の Security Hub CSPM コントロール AWS App Runner
<a name="apprunner-controls"></a>

これらの AWS Security Hub CSPM コントロールは、 AWS App Runner サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [AppRunner.1] App Runner サービスにはタグを付ける必要があります
<a name="apprunner-1"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::AppRunner::Service`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/apprunner-service-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/apprunner-service-tagged.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、 AWS App Runner サービスにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。App Runner サービスにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、App Runner サービスがキーでタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="apprunner-1-remediation"></a>

 AWS App Runner サービスにタグを追加する方法については、 *AWS App Runner API リファレンス*[https://docs.aws.amazon.com/apprunner/latest/api/API_TagResource.html](https://docs.aws.amazon.com/apprunner/latest/api/API_TagResource.html)の「」を参照してください。

## [AppRunner.2] App Runner VPC コネクタにはタグを付ける必要があります
<a name="apprunner-2"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::AppRunner::VpcConnector`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/apprunner-vpc-connector-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/apprunner-vpc-connector-tagged.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、 AWS App Runner VPC コネクタにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。VPC コネクタにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、VPC コネクタにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="apprunner-2-remediation"></a>

 AWS App Runner VPC コネクタにタグを追加する方法については、 *AWS App Runner API リファレンス*[https://docs.aws.amazon.com/apprunner/latest/api/API_TagResource.html](https://docs.aws.amazon.com/apprunner/latest/api/API_TagResource.html)の「」を参照してください。

# の Security Hub CSPM コントロール AWS AppSync
<a name="appsync-controls"></a>

これらの Security Hub CSPM コントロールは、 AWS AppSync サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [AppSync.1] AWS AppSync API キャッシュは保管時に暗号化する必要があります
<a name="appsync-1"></a>

**重要**  
Security Hub CSPM は、2026 年 3 月 9 日にこのコントロールを廃止しました。詳細については、「」を参照してください[Security Hub CSPM コントロールの変更ログ](controls-change-log.md)。 AWS AppSync 現在および将来のすべての API キャッシュでデフォルトの暗号化が提供されるようになりました。

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

**重要度:** 中

**リソースタイプ :** `AWS::AppSync::GraphQLApi`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/appsync-cache-ct-encryption-at-rest.html](https://docs.aws.amazon.com/config/latest/developerguide/appsync-cache-ct-encryption-at-rest.html)

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

**パラメータ :** なし

このコントロールは、 AWS AppSync API キャッシュが保管中に暗号化されているかどうかをチェックします。API キャッシュが保管時に暗号化されていない場合、コントロールは失敗します。

保管中のデータとは、永続的な不揮発性ストレージに任意の期間保管されているデータを指します。保管中のデータを暗号化すると、その機密性が保護され、権限のないユーザーがアクセスするリスクが低減されます。

### 修正
<a name="appsync-1-remediation"></a>

 AWS AppSync API のキャッシュを有効にした後で暗号化設定を変更することはできません。代わりに、キャッシュを削除し、暗号化を有効にして再作成する必要があります。詳細については、「*AWS AppSync デベロッパーガイド*」の「[キャッシュ暗号化](https://docs.aws.amazon.com/appsync/latest/devguide/enabling-caching.html#caching-encryption)」を参照してください。

## [AppSync.2] AWS AppSync フィールドレベルのログ記録を有効にする必要があります
<a name="appsync-2"></a>

**関連する要件:** PCI DSS v4.0.1/10.4.2

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

**重要度:** 中

**リソースタイプ :** `AWS::AppSync::GraphQLApi`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/appsync-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/appsync-logging-enabled.html)

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

**パラメータ :** 


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `fieldLoggingLevel`  |  フィールドのログ記録レベル  |  列挙型  |  `ERROR`, `ALL`, `INFO`, `DEBUG`  |  `No default value`  | 

このコントロールは、 AWS AppSync API でフィールドレベルのログ記録が有効になっているかどうかをチェックします。フィールドリゾルバーのログレベルが **[なし]** に設定されている場合、コントロールは失敗します。特定のログタイプを有効にする必要があることを示すカスタムパラメータ値を指定しない限り、フィールドリゾルバーのログレベルが `ERROR`または の場合、Security Hub CSPM は渡された結果を生成します`ALL`。

ログおよびメトリクスを使用して、GraphQL クエリを特定、トラブルシューティング、最適化できます。 AWS AppSync GraphQL のログ記録を有効にすると、API リクエストとレスポンスに関する詳細情報を取得し、問題を特定して対応し、規制要件に準拠できます。

### 修正
<a name="appsync-2-remediation"></a>

のログ記録を有効にするには AWS AppSync、 *AWS AppSync デベロッパーガイド*の[「セットアップと設定](https://docs.aws.amazon.com/appsync/latest/devguide/monitoring.html#setup-and-configuration)」を参照してください。

## [AppSync.4] AWS AppSync GraphQL APIsにはタグを付ける必要があります
<a name="appsync-4"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::AppSync::GraphQLApi`

**AWS Config rule:** `tagged-appsync-graphqlapi` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、 AWS AppSync GraphQL API にパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。GraphQL API にタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、GraphQL API にキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。IAM エンティティ (ユーザーまたはロール) と AWS リソースにタグをアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、『』の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="appsync-4-remediation"></a>

 AWS AppSync GraphQL API にタグを追加するには、 *AWS AppSync API リファレンス*[https://docs.aws.amazon.com/appsync/latest/APIReference/API_TagResource.html](https://docs.aws.amazon.com/appsync/latest/APIReference/API_TagResource.html)の「」を参照してください。

## [AppSync.5] AWS AppSync GraphQL APIsは API キーで認証しないでください
<a name="appsync-5"></a>

**関連する要件:** NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-6

**カテゴリ:** 保護 > セキュアなアクセス管理 > パスワードレス認証

**重要度:** 高

**リソースタイプ :** `AWS::AppSync::GraphQLApi`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/appsync-authorization-check.html](https://docs.aws.amazon.com/config/latest/developerguide/appsync-authorization-check.html)

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

**パラメータ :**
+ `AllowedAuthorizationTypes`: ` AWS_LAMBDA, AWS_IAM, OPENID_CONNECT, AMAZON_COGNITO_USER_POOLS` (カスタマイズ不可)

このコントロールは、アプリケーションが API キーを使用して AWS AppSync GraphQL API を操作するかどうかをチェックします。 AWS AppSync GraphQL API が API キーで認証されている場合、コントロールは失敗します。

API キーは、認証されていない GraphQL エンドポイントを作成するときに AWS AppSync サービスによって生成されるアプリケーション内のハードコードされた値です。この API キーが侵害されると、エンドポイントは意図しないアクセスに対して脆弱になります。一般にアクセス可能なアプリケーションやウェブサイトをサポートしている場合を除き、API キーを認証に使用することはお勧めしません。

### 修正
<a name="appsync-5-remediation"></a>

 AWS AppSync GraphQL API の認可オプションを設定するには、「 *AWS AppSync デベロッパーガイド*」の[「認可と認証](https://docs.aws.amazon.com/appsync/latest/devguide/security-authz.html)」を参照してください。

## [AppSync.6] AWS AppSync API キャッシュは転送中に暗号化する必要があります
<a name="appsync-6"></a>

**重要**  
Security Hub CSPM は、2026 年 3 月 9 日にこのコントロールを廃止しました。詳細については、「」を参照してください[Security Hub CSPM コントロールの変更ログ](controls-change-log.md)。 AWS AppSync 現在および将来のすべての API キャッシュでデフォルトの暗号化が提供されるようになりました。

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

**重要度:** 中

**リソースタイプ :** `AWS::AppSync::ApiCache`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/appsync-cache-ct-encryption-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/appsync-cache-ct-encryption-in-transit.html)

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

**パラメータ :** なし

このコントロールは、 AWS AppSync API キャッシュが転送中に暗号化されているかどうかをチェックします。API キャッシュが転送中に暗号化されていない場合、コントロールは失敗します。

転送中のデータとは、クラスター内のノード間やクラスターとアプリケーション間など、ある場所から別の場所に移動するデータを指します。データはインターネット内またはプライベートネットワーク内を移動する場合があります。転送中のデータを暗号化することで、権限のないユーザーがネットワークトラフィックを盗聴するリスクが軽減されます。

### 修正
<a name="appsync-6-remediation"></a>

 AWS AppSync API のキャッシュを有効にした後で暗号化設定を変更することはできません。代わりに、キャッシュを削除し、暗号化を有効にして再作成する必要があります。詳細については、「*AWS AppSync デベロッパーガイド*」の「[キャッシュ暗号化](https://docs.aws.amazon.com/appsync/latest/devguide/enabling-caching.html#caching-encryption)」を参照してください。

# Amazon Athena の Security Hub CSPM コントロール
<a name="athena-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon Athena サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [Athena.1] Athena ワークグループは、保管中に暗号化する必要があります
<a name="athena-1"></a>

**重要**  
Security Hub CSPM は、2024 年 4 月にこのコントロールを廃止しました。詳細については、「[Security Hub CSPM コントロールの変更ログ](controls-change-log.md)」を参照してください。

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

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SI-7(6)

**重要度:** 中

**リソースタイプ :** `AWS::Athena::WorkGroup`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/athena-workgroup-encrypted-at-rest.html](https://docs.aws.amazon.com/config/latest/developerguide/athena-workgroup-encrypted-at-rest.html)

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

**パラメータ :** なし

このコントロールは、Athena ワークグループが保管中に暗号化されているかどうかをチェックします。Athena ワークグループが保管中に暗号化されていない場合、コントロールは失敗します。

Athena では、チーム、アプリケーション、またはさまざまなワークロードのクエリを実行するためのワークグループを作成できます。各ワークグループには、すべてのクエリで暗号化を有効にする設定があります。Amazon Simple Storage Service (Amazon S3) マネージドキーによるサーバー側の暗号化、 AWS Key Management Service (AWS KMS) キーによるサーバー側の暗号化、またはカスタマーマネージド KMS キーによるクライアント側の暗号化を使用できます。保管中のデータとは、永続的な不揮発性ストレージに任意の期間保管されているデータを指します。暗号化は、このようなデータの機密性を保護し、権限のないユーザーがデータにアクセスするリスクを低減するのに役立ちます。

### 修正
<a name="athena-1-remediation"></a>

Athena ワークグループの保管中の暗号化を有効にするには、「*Amazon Athena ユーザーガイド*」の「[ワークグループの編集](https://docs.aws.amazon.com/athena/latest/ug/workgroups-create-update-delete.html#editing-workgroups)」を参照してください。**[クエリ結果の設定]** セクションで **[クエリ結果の暗号化]** をクリックします。

## [Athena.2] Athena データカタログにはタグを付ける必要があります
<a name="athena-2"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::Athena::DataCatalog`

**AWS Config rule:** `tagged-athena-datacatalog` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、Amazon Athena データカタログにパラメータ `requiredTagKeys` で定義された特定のキーを含むタグがあるかどうかをチェックします。データカタログにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、データカタログにキーがタグ付けされていない場合に失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="athena-2-remediation"></a>

Athena データカタログにタグを追加するには、「*Amazon Athena ユーザーガイド*」の「[Athena リソースのタグ付け](https://docs.aws.amazon.com/athena/latest/ug/tags.html)」を参照してください。

## [Athena.3] Athena ワークグループにはタグを付ける必要があります
<a name="athena-3"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::Athena::WorkGroup`

**AWS Config rule:** `tagged-athena-workgroup` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、Amazon Athena ワークグループにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。ワークグループにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ワークグループにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="athena-3-remediation"></a>

Athena ワークグループにタグを追加するには、「*Amazon Athena ユーザーガイド*」の「[個々のワークグループでのタグの追加と削除](https://docs.aws.amazon.com/athena/latest/ug/tags-console.html#tags-add-delete)」を参照してください。

## [Athena.4] Athena ワークグループではログ記録が有効になっている必要があります
<a name="athena-4"></a>

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

**重要度:** 中

**リソースタイプ :** `AWS::Athena::WorkGroup`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/athena-workgroup-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/athena-workgroup-logging-enabled.html)

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

**パラメータ :** なし

このコントロールは、Amazon Athena ワークグループのログ記録が有効になっているかどうかを確認します。ワークグループでログ記録が有効になっていない場合、コントロールは失敗します。

監査ログは、システムアクティビティを追跡およびモニタリングします。これらは、セキュリティ違反の検出、インシデントの調査、規制の遵守に役立つイベントの記録を提供します。監査ログは、組織の全体的な説明責任と透明性も強化します。

### 修正
<a name="athena-4-remediation"></a>

Athena ワークグループのログ記録を有効にする方法については、「*Amazon Athena ユーザーガイド*」の「[Athena で CloudWatch クエリメトリクスを有効にする](https://docs.aws.amazon.com/athena/latest/ug/athena-cloudwatch-metrics-enable.html)」を参照してください。

# の Security Hub CSPM コントロール AWS Backup
<a name="backup-controls"></a>

これらの Security Hub CSPM コントロールは、 AWS Backup サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [Backup.1] AWS Backup 復旧ポイントは保管時に暗号化する必要があります
<a name="backup-1"></a>

**関連する要件:** NIST.800-53.r5 CP-9(8)、NIST.800-53.r5 SI-12

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

**重要度:** 中

**リソースタイプ :** `AWS::Backup::RecoveryPoint`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/backup-recovery-point-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/backup-recovery-point-encrypted.html)

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

**パラメータ :** なし

このコントロールは、保管時に AWS Backup 復旧ポイントが暗号化されているかどうかを確認します。復旧ポイントが保管時に暗号化されていない場合、コントロールは失敗します。

 AWS Backup 復旧ポイントとは、バックアッププロセスの一部として作成されるデータの特定のコピーまたはスナップショットを指します。データがバックアップされた特定の瞬間を表し、元のデータが失われたり、破損したり、アクセス不能になったりした場合の復元ポイントとして機能します。バックアップ復旧ポイントを暗号化すると、不正アクセスに対する保護をさらに強化することができます。暗号化は、バックアップデータの機密性、完全性、およびセキュリティを保護するためのベストプラクティスです。

### 修正
<a name="backup-1-remediation"></a>

 AWS Backup 復旧ポイントを暗号化するには、 *AWS Backup デベロッパーガイド*の「 [でのバックアップの暗号化 AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html)」を参照してください。

## [Backup.2] AWS Backup 復旧ポイントにはタグを付ける必要があります
<a name="backup-2"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::Backup::RecoveryPoint`

**AWS Config rule:** `tagged-backup-recoverypoint` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、 AWS Backup 復旧ポイントにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。リカバリポイントにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、復旧ポイントにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、『』の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="backup-2-remediation"></a>

**AWS Backup 復旧ポイントにタグを追加するには**

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. ナビゲーションペインで、**[バックアッププラン]** を選択します。

1. リストからバックアッププランを選択します。

1. **[バックアッププランタグ]** セクションで、**[タグを管理]** を選択します。

1. タグのキーと値を入力します。追加のキーと値のペアについては **[新しいタグの追加]** を選択します。

1. タグの追加を完了したら、**[保存]** を選択します。

## [Backup.3] AWS Backup ボールトにはタグを付ける必要があります
<a name="backup-3"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::Backup::BackupVault`

**AWS Configルール:** `tagged-backup-backupvault` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、 AWS Backup ボールトにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。リカバリポイントにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、復旧ポイントにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="backup-3-remediation"></a>

**AWS Backup ボールトにタグを追加するには**

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. ナビゲーションペインで、**[バックアップボールト]** を選択します。

1. リストからバックアップボールトを選択します。

1. **[バックアップボールトタグ]** セクションで、**[タグを管理]** を選択します。

1. タグのキーと値を入力します。追加のキーと値のペアについては **[新しいタグの追加]** を選択します。

1. タグの追加を完了したら、**[保存]** を選択します。

## [Backup.4] AWS Backup レポートプランにはタグを付ける必要があります
<a name="backup-4"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::Backup::ReportPlan`

**AWS Config rule:** `tagged-backup-reportplan` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、 AWS Backup レポートプランにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。レポートプランにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、レポートプランにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、『』の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="backup-4-remediation"></a>

**AWS Backup レポートプランにタグを追加するには**

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. ナビゲーションペインで、**[バックアップボールト]** を選択します。

1. リストからバックアップボールトを選択します。

1. **[バックアップボールトタグ]** セクションで、**[タグを管理]** を選択します。

1. [**新しいタグを追加**] をクリックします。タグのキーと値を入力します。追加のキーと値のペアについても繰り返します。

1. タグの追加を完了したら、**[保存]** を選択します。

## [Backup.5] AWS Backup バックアッププランにはタグを付ける必要があります
<a name="backup-5"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::Backup::BackupPlan`

**AWS Config rule:** `tagged-backup-backupplan` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、 AWS Backup バックアッププランにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。バックアッププランにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、バックアッププランにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、『』の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="backup-5-remediation"></a>

**AWS Backup バックアッププランにタグを追加するには**

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. ナビゲーションペインで、**[バックアップボールト]** を選択します。

1. リストからバックアップボールトを選択します。

1. **[バックアップボールトタグ]** セクションで、**[タグを管理]** を選択します。

1. [**新しいタグを追加**] をクリックします。タグのキーと値を入力します。追加のキーと値のペアについても繰り返します。

1. タグの追加を完了したら、**[保存]** を選択します。

# の Security Hub CSPM コントロール AWS Batch
<a name="batch-controls"></a>

これらの Security Hub CSPM コントロールは、 AWS Batch サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [Batch.1] バッチジョブキューにはタグを付ける必要があります
<a name="batch-1"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::Batch::JobQueue`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/batch-job-queue-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/batch-job-queue-tagged.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、 AWS Batch ジョブキューにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。ジョブキューにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ジョブキューにキーがタグ付けされていない場合に失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="batch-1-remediation"></a>

バッチジョブキューにタグを追加するには、「*AWS Batch ユーザーガイド*」の「[リソースのタグ付け](https://docs.aws.amazon.com/batch/latest/userguide/tag-resources.html)」を参照してください。

## [Batch.2] バッチスケジューリングポリシーにはタグを付ける必要があります
<a name="batch-2"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::Batch::SchedulingPolicy`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/batch-scheduling-policy-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/batch-scheduling-policy-tagged.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、 AWS Batch スケジューリングポリシーにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。スケジューリングポリシーにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、スケジューリングポリシーにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="batch-2-remediation"></a>

バッチスケジューリングポリシーにタグを追加するには、「*AWS Batch ユーザーガイド*」の「[リソースのタグ付け](https://docs.aws.amazon.com/batch/latest/userguide/tag-resources.html)」を参照してください。

## [Batch.3] バッチコンピューティング環境にはタグを付ける必要があります
<a name="batch-3"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::Batch::ComputeEnvironment`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/batch-compute-environment-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/batch-compute-environment-tagged.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、 AWS Batch コンピューティング環境にパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。コンピューティング環境にタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、コンピューティング環境にキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="batch-3-remediation"></a>

バッチコンピューティング環境にタグを追加するには、「*AWS Batch ユーザーガイド*」の「[リソースのタグ付け](https://docs.aws.amazon.com/batch/latest/userguide/tag-resources.html)」を参照してください。

## [Batch.4] マネージドバッチコンピューティング環境のコンピューティングリソースプロパティにはタグを付ける必要があります
<a name="batch-4"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::Batch::ComputeEnvironment`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/batch-managed-compute-env-compute-resources-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/batch-managed-compute-env-compute-resources-tagged.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | 評価されたリソースに割り当てる必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目) | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし | 

このコントロールは、マネージド AWS Batch コンピューティング環境のコンピューティングリソースプロパティに、`requiredKeyTags` パラメータで指定されたタグキーがあるかどうかをチェックします。コンピューティングリソースプロパティにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。`requiredKeyTags` パラメータに値を指定しない場合、コントロールはタグキーの存在のみをチェックし、コンピューティングリソースプロパティにタグキーがない場合に失敗します。このコントロールはシステムタグを無視します。システムタグは自動的に付与され、`aws:` プレフィックスが付きます。このコントロールは、アンマネージド型のコンピューティング環境や、 AWS Fargate リソースを使用するマネージド環境を評価しません。

タグは、 AWS リソースを作成して割り当てるラベルです。各タグは、必要なタグキーとオプションのタグ値で設定されています。タグを使用して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。またそれらは、アクションと通知のリソース所有者を追跡するのにも役立ちます。タグを使用して、認可戦略として属性ベースのアクセス制御 (ABAC) を実装することもできます。ABAC 戦略の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。タグの詳細については、[「 AWS リソースのタグ付け」および「タグエディタユーザーガイド](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。

**注記**  
個人を特定できる情報 (PII) などの機密情報や秘匿性の高い情報はタグに格納しないでください。タグには多くの からアクセスできます AWS のサービス。それらは、プライベートデータや機密データに使用することを意図していません。

### 修正
<a name="batch-4-remediation"></a>

マネージドコンピューティング環境で AWS Batch コンピューティングリソースにタグを追加する方法については、*AWS Batch 「 ユーザーガイド*」の[「リソースのタグ付け](https://docs.aws.amazon.com/batch/latest/userguide/tag-resources.html)」を参照してください。

# の Security Hub CSPM コントロール AWS Certificate Manager
<a name="acm-controls"></a>

これらの AWS Security Hub CSPM コントロールは、 AWS Certificate Manager (ACM) サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [ACM.1] インポートされ ACM によって発行された証明書は、一定期間後に更新する必要があります
<a name="acm-1"></a>

**関連する要件:** NIST.800-53.r5 SC-28(3)、NIST.800-53.r5 SC-7(16)、NIST.800-171.r2 3.13.15、PCI DSS v4.0.1/4.2.1

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/acm-certificate-expiration-check.html](https://docs.aws.amazon.com/config/latest/developerguide/acm-certificate-expiration-check.html)

**スケジュールタイプ:** 変更がトリガーされ、定期的に行われる場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `daysToExpiration`  |  ACM 証明書を更新する必要がある日数  |  整数  |  `14`～`365`  |  `30`  | 

このコントロールは、 AWS Certificate Manager (ACM) 証明書が指定された期間内に更新されるかどうかをチェックします。インポートした証明書と ACM によって提供された証明書の両方をチェックします。指定された期間内に証明書が更新されない場合、コントロールは失敗します。更新期間にカスタムパラメータ値を指定しない限り、Security Hub CSPM はデフォルト値の 30 日を使用します。

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

### 修正
<a name="acm-1-remediation"></a>

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

**E メールで検証されたドメイン**  
証明書の有効期限まで 45 日間の時点で、ACM はドメイン所有者にドメイン名ごとに E メールを送信します。ドメインを検証して更新を完了するには、E メール通知に応答する必要があります。  
詳細については、「AWS Certificate Manager ユーザーガイド」の「[E メールで検証されたドメインの更新](https://docs.aws.amazon.com/acm/latest/userguide/email-renewal-validation.html)」を参照してください。

**DNS によって検証されたドメイン**  
ACM は DNS 検証を使用する証明書を自動的に更新します。有効期限の 60 日前に、ACM は証明書が更新できることを確認します。  
ドメイン名を検証できない場合、ACM は手動検証が必要である旨の通知を送信します。これらの通知は、有効期限の 45 日、30 日、7 日、1 日前に送信されます。  
詳細については、「AWS Certificate Manager ユーザーガイド」の「[DNS によって検証されたドメインの更新](https://docs.aws.amazon.com/acm/latest/userguide/dns-renewal-validation.html)」を参照してください。

## [ACM.2] ACM によって管理される RSA 証明書は、少なくとも 2,048 ビットのキーの長さを使用する必要があります
<a name="acm-2"></a>

**関連する要件:** PCI DSS v4.0.1/4.2.1

**カテゴリ:** 識別 > インベントリ > インベントリサービス

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/acm-certificate-rsa-check.html](https://docs.aws.amazon.com/config/latest/developerguide/acm-certificate-rsa-check.html)

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

**パラメータ :** なし

このコントロールは、 によって管理される RSA 証明書が少なくとも 2,048 ビットのキー長 AWS Certificate Manager を使用しているかどうかをチェックします。キーの長さが 2,048 ビットより小さい場合、コントロールは失敗します。

暗号化の強度はキーサイズと直接相関します。コンピューティング能力が安価になり、サーバーがより高度になるため、 AWS リソースを保護するために、キーの長さを 2,048 ビット以上にすることをお勧めします。

### 修正
<a name="acm-2-remediation"></a>

ACM が発行する RSA 証明書における最小のキーの長さは、既に 2,048 ビットです。ACM で新しい RSA 証明書を発行する手順については、「*AWS Certificate Manager ユーザーガイド*」の「[証明書の発行と管理](https://docs.aws.amazon.com/acm/latest/userguide/gs.html)」を参照してください。

ACM では短いキーの長さで証明書をインポートできますが、この制御を行うには少なくとも 2,048 ビットのキーを使用する必要があります。証明書をインポートした後で、キーの長さを変更することはできません。代わりに、キーの長さが 2,048 ビット未満の証明書を削除する必要があります。ACM への証明書のインポートに関する詳細については、「*AWS Certificate Manager ユーザーガイド*」の「[証明書をインポートするための前提条件](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-prerequisites.html)」を参照してください。

## [ACM.3] ACM 証明書にはタグを付ける必要があります
<a name="acm-3"></a>

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

**重要度:** 低

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

**AWS Config rule:** `tagged-acm-certificate` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、 AWS Certificate Manager (ACM) 証明書にパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。証明書にタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、証明書にキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="acm-3-remediation"></a>

ACM 証明書にタグを追加するには、*AWS Certificate Manager 「 ユーザーガイド*[」の AWS Certificate Manager 「証明書のタグ付け](https://docs.aws.amazon.com/acm/latest/userguide/tags.html)」を参照してください。

# の Security Hub CSPM コントロール CloudFormation
<a name="cloudformation-controls"></a>

これらの Security Hub CSPM コントロールは、 AWS CloudFormation サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [CloudFormation.1] CloudFormation スタックは、Simple Notification Service (SNS) と統合させる必要があります
<a name="cloudformation-1"></a>

**重要**  
Security Hub CSPM は、2024 年 4 月にこのコントロールを廃止しました。詳細については、「[Security Hub CSPM コントロールの変更ログ](controls-change-log.md)」を参照してください。

**関連する要件:** NIST.800-53.r5 SI-4(12)、NIST.800-53.r5 SI-4(5)

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

**重要度:** 低

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloudformation-stack-notification-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudformation-stack-notification-check.html)

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

**パラメータ :** なし

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

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

### 修正
<a name="cloudformation-1-remediation"></a>

CloudFormation スタックと SNS トピックを統合するには、「*AWS CloudFormation ユーザーガイド*」の「[スタックの直接更新](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-direct.html)」を参照してください。

## [CloudFormation.2] CloudFormation スタックにはタグを付ける必要があります
<a name="cloudformation-2"></a>

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

**重要度:** 低

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

**AWS Config rule:** `tagged-cloudformation-stack` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、 AWS CloudFormation スタックにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。スタックにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、スタックにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、『』の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="cloudformation-2-remediation"></a>

CloudFormation スタックにタグを追加するには、「*AWS CloudFormation API リファレンス*」の「[CreateStack](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateStack.html)」を参照してください。

## [CloudFormation.3] CloudFormation スタックでは終了保護を有効にする必要があります
<a name="cloudformation-3"></a>

**カテゴリ:** 保護 > データ保護 > データ削除保護

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloudformation-termination-protection-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudformation-termination-protection-check.html)

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

**パラメータ :** なし

このコントロールは、 AWS CloudFormation スタックで終了保護が有効になっているかどうかを確認します。CloudFormation スタックで終了保護が有効になっていない場合、コントロールは失敗します。

CloudFormation は、関連するリソースを スタックと呼ばれる単一のユニットとして管理するのに役立ちます。スタックの削除保護を有効にして、スタックが誤って削除されるのを防ぐことができます。削除保護を有効にした状態でスタックを削除しようとすると、削除は失敗し、ステータスを含め、スタックが変更されることはありません。スタックの削除保護は、任意のステータスで設定できます ([`DELETE_IN_PROGRESS`] または [`DELETE_COMPLETE`] を除く)。

**注記**  
スタックで削除保護を有効または無効にすると、そのスタックに属するネストされたスタックにも同じ選択が適用されます。ネストされたスタックの削除保護を直接有効または無効にすることはできません。終了保護が有効になっているスタックに属するネストされたスタックを直接削除することはできません。スタック名の横に [ネスト] と表示されている場合、そのスタックは、ネストされたスタックです。ネストされたスタックが属するルートスタックの削除保護のみ変更することができます。

### 修正
<a name="cloudformation-3-remediation"></a>

CloudFormation スタックで終了保護を有効にするには、「 *AWS CloudFormation ユーザーガイド*」の[CloudFormation スタックが削除されないように保護する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-protect-stacks.html)」を参照してください。

## [CloudFormation.4] CloudFormation スタックには関連するサービスロールが必要です
<a name="cloudformation-4"></a>

**カテゴリ:** 検出 > セキュアなアクセス管理

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloudformation-stack-service-role-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudformation-stack-service-role-check.html)

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

**パラメータ :** なし

このコントロールは、 AWS CloudFormation スタックにサービスロールが関連付けられているかどうかをチェックします。CloudFormation スタックにサービスロールが関連付けられていない場合、コントロールは失敗します。

サービスマネージド StackSets は、 AWS Organizations の信頼されたアクセス統合を通じて実行ロールを使用します。コントロールは、サービスマネージド StackSets によって作成された AWS CloudFormation スタックの FAILED 検出結果も生成します。これは、サービスロールが関連付けられていないためです。サービスマネージド StackSets の認証方法により、これらのスタックに `roleARN`フィールドを入力することはできません。

CloudFormation スタックでサービスロールを使用すると、スタックを作成/更新するユーザーとCloudFormation がリソースを作成/更新するために必要なアクセス許可を分離することで、最小特権アクセスを実装できます。これにより、特権エスカレーションのリスクが軽減され、さまざまな運用ロール間のセキュリティ境界を維持するのに役立ちます。

**注記**  
スタックの作成後に、スタックにアタッチされたサービスロールを削除することはできません。このスタックで操作を実行する権限を持つ他のユーザーは、`iam:PassRole` 権限の有無にかかわらず、このロールを使用できます。ユーザーが持つべきではないアクセス許可がロールに含まれる場合、ユーザーのアクセス許可を非意図的にエスカレーションできてしまいます。ロールが 最小特権 を付与することを確認します。

### 修正
<a name="cloudformation-4-remediation"></a>

サービスロールを CloudFormation スタックに関連付けるには、*AWS CloudFormation 「 ユーザーガイド*」の[CloudFormation サービスロール](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-servicerole.html)」を参照してください。

# Amazon CloudFront の Security Hub CSPM コントロール
<a name="cloudfront-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon CloudFront サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

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

**関連する要件:** NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、PCI DSS v4.0.1/2.2.6

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-default-root-object-configured.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-default-root-object-configured.html)

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

**パラメータ :** なし

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

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

### 修正
<a name="cloudfront-1-remediation"></a>

CloudFront ディストリビューションのデフォルトルートオブジェクトを設定するには、「*Amazon CloudFront デベロッパーガイド*」の「[デフォルトルートオブジェクトを指定する方法](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DefaultRootObject.html#DefaultRootObjectHowToDefine)」を参照してください。

## [CloudFront.3] CloudFront ディストリビューションでは、転送中に暗号化が必要となります
<a name="cloudfront-3"></a>

**関連する要件:** NIST.800-53.r5 AC-17(2)、NIST.800-53.r5 AC-4、NIST.800-53.r5 IA-5(1)、NIST.800-53.r5 SC-12(3)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-23、NIST.800-53.r5 SC-23(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-8、NIST.800-53.r5 SC-8(1)、NIST.800-53.r5 SC-8(2)、NIST.800-53.r5 SI-7(6)、PCI DSS v4.0.1/4.2.1

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-viewer-policy-https.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-viewer-policy-https.html)

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

**パラメータ:** なし

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

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

### 修正
<a name="cloudfront-3-remediation"></a>

転送中の CloudFront ディストリビューションを暗号化するには、「*Amazon CloudFront デベロッパーガイド*」の「[ビューワーと CloudFront 間の通信で HTTPS を必須にする](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html)」を参照してください。

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

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 SC-36、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)

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

**重要度:** 低

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-origin-failover-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-origin-failover-enabled.html)

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

**パラメータ:** なし

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

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

### 修正
<a name="cloudfront-4-remediation"></a>

CloudFront ディストリビューションのオリジンフェイルオーバーを設定するには、「*Amazon CloudFront デベロッパーガイド*」の「[オリジングループの作成](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html#concept_origin_groups.creating)」を参照してください。

## [CloudFront.5] CloudFront ディストリビューションでは、ログ記録を有効にする必要があります
<a name="cloudfront-5"></a>

**関連する要件:** NIST.800-53.r5 AC-2(4)、NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AC-6(9)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4(20)、NIST.800-53.r5 SI-7(8)、PCI DSS v4.0.1/10.4.2

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-accesslogs-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-accesslogs-enabled.html)

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

**パラメータ :** なし

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

CloudFront アクセスログは、CloudFront が受信するすべてのユーザーリクエストに関する詳細情報を提供します。各ログには、リクエストが受信された日時、リクエストを行ったビューワーの IP アドレス、リクエストソース、ビューワーからのリクエストポート番号などの情報が含まれます。これらのログは、セキュリティ監査やアクセス監査、証拠調査などのアプリケーションに役立ちます。アクセスログの分析の詳細については、「*Amazon Athena ユーザーガイド*」の「[Amazon CloudFront ログのクエリ](https://docs.aws.amazon.com/athena/latest/ug/cloudfront-logs.html)」を参照してください。

### 修正
<a name="cloudfront-5-remediation"></a>

CloudFront ディストリビューションの標準ログ記録 (レガシー) を設定するには、「*Amazon CloudFront デベロッパーガイド*」の「[標準ログ記録 (レガシー) を設定する](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logging-legacy-s3.html)」を参照してください。

## [CloudFront.6] CloudFront ディストリビューションでは、WAF を有効にする必要があります
<a name="cloudfront-6"></a>

**関連する要件:** NIST.800-53.r5 AC-4(21)、PCI DSS v4.0.1/6.4.2

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-associated-with-waf.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-associated-with-waf.html)

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

**パラメータ :** なし

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

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

### 修正
<a name="cloudfront-6-remediation"></a>

 AWS WAF ウェブ ACL を CloudFront ディストリビューションに関連付けるには、*Amazon CloudFront デベロッパーガイド*[AWS WAF 」の「 を使用してコンテンツへのアクセスを制御する](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-awswaf.html)」を参照してください。

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

**関連する要件:** NIST.800-53.r5 AC-17(2)、NIST.800-53.r5 AC-4、NIST.800-53.r5 IA-5(1)、NIST.800-53.r5 SC-12(3)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-23、NIST.800-53.r5 SC-23(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-8、NIST.800-53.r5 SC-8(1)、NIST.800-53.r5 SC-8(2)、NIST.800-53.r5 SI-7(6)、NIST.800-171.r2 3.13.15

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

**重要度:** 低

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-custom-ssl-certificate.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-custom-ssl-certificate.html)

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

**パラメータ :** なし

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

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

### 修正
<a name="cloudfront-7-remediation"></a>

カスタム SSL/TLS 証明書を使用して CloudFront ディストリビューション用の代替ドメイン名を追加するには、「*Amazon CloudFront デベロッパーガイド*」の「[代替ドメイン名の追加](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html#CreatingCNAME)」を参照してください。

## [CloudFront.8] CloudFront ディストリビューションでは、SNI を使用して HTTPS リクエストを処理する必要があります
<a name="cloudfront-8"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2

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

**重要度:** 低

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-sni-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-sni-enabled.html)

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

**パラメータ :** なし

このコントロールは、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 アドレスはディストリビューション専用にはなりません。

### 修正
<a name="cloudfront-8-remediation"></a>

SNI を使用して HTTPS リクエストを処理するように CloudFront ディストリビューションを設定するには、「CloudFront デベロッパーガイド」の「[SNI を使用した HTTPS リクエストの処理 (ほとんどのクライアントで動作)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-https-dedicated-ip-or-sni.html#cnames-https-sni)」を参照してください。カスタム SSL 証明書の詳細については、「[CloudFront で SSL/TLS 証明書を使用するための要件](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-and-https-requirements.html)」を参照してください。

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

**関連する要件:** NIST.800-53.r5 AC-17(2)、NIST.800-53.r5 AC-4、NIST.800-53.r5 IA-5(1)、NIST.800-53.r5 SC-12(3)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-23、NIST.800-53.r5 SC-23(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-8、NIST.800-53.r5 SC-8(1)、NIST.800-53.r5 SC-8(2)、NIST.800-53.r5 SI-7(6)、PCI DSS v4.0.1/4.2.1

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-traffic-to-origin-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-traffic-to-origin-encrypted.html)

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

**パラメータ:** なし

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

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

### 修正
<a name="cloudfront-9-remediation"></a>

CloudFront 接続の暗号化を義務付けするようにオリジンプロトコルポリシーを更新するには、「*Amazon CloudFront デベロッパーガイド*」の「[CloudFront とカスタムオリジン間の通信で HTTPS を必須にする](https://docs.aws.amazon.com//AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-custom-origin.html)」を参照してください。

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

**関連する要件:** NIST.800-53.r5 AC-17(2)、NIST.800-53.r5 AC-4、NIST.800-53.r5 IA-5(1)、NIST.800-53.r5 SC-12(3)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-23、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-8、NIST.800-53.r5 SC-8(1)、NIST.800-53.r5 SC-8(2)、NIST.800-53.r5 SI-7(6)、NIST.800-171.r2 3.13.15、PCI DSS v4.0.1/4.2.1

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-no-deprecated-ssl-protocols.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-no-deprecated-ssl-protocols.html)

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

**パラメータ :** なし

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

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

### 修正
<a name="cloudfront-10-remediation"></a>

CloudFront ディストリビューションのオリジン SSL プロトコルを更新する方法については、「*Amazon CloudFront デベロッパーガイド*」の「[CloudFront とカスタムオリジン間の通信で HTTPS を必須にする](https://docs.aws.amazon.com//AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-custom-origin.html)」を参照してください。

## [CloudFront.12] CloudFront ディストリビューションは、存在しない S3 オリジンをポイントしない必要があります
<a name="cloudfront-12"></a>

**関連する要件:** NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)、PCI DSS v4.0.1/2.2.6

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-s3-origin-non-existent-bucket.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-s3-origin-non-existent-bucket.html)

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

**パラメータ :** なし

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

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

### 修正
<a name="cloudfront-12-remediation"></a>

CloudFront ディストリビューションを変更して新しいオリジンをポイントさせるには、「*Amazon CloudFront デベロッパーガイド*」の「[ディストリビューションの更新](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/HowToUpdateDistribution.html)」を参照してください。

## [CloudFront.13] CloudFront ディストリビューションでは、オリジンアクセスコントロールを有効にする必要があります
<a name="cloudfront-13"></a>

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-s3-origin-access-control-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-s3-origin-access-control-enabled.html)

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

**パラメータ :** なし

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

S3 バケットを CloudFront ディストリビューションのオリジンとして使用する場合、OAC を有効にできます。これにより、指定した CloudFront ディストリビューションを介してのみバケット内のコンテンツにアクセスでき、バケットや他のディストリビューションからの直接アクセスは禁止されます。CloudFront はオリジンアクセスアイデンティティ (OAI) をサポートしていますが、OAC には追加機能があり、OAI を使用するディストリビューションは OAC に移行できます。OAI は S3 オリジンに安全にアクセスする方法を提供しますが、きめ細かなポリシー設定や、 AWS 署名バージョン 4 (SigV4) AWS リージョン を必要とする で POST メソッドを使用する HTTP/HTTPS リクエストのサポートがないなどの制限があります。OAI は による暗号化もサポートしていません AWS Key Management Service。OAC は、IAM サービスプリンシパルを使用して S3 オリジンで認証するという AWS ベストプラクティスに基づいています。

### 修正
<a name="cloudfront-13-remediation"></a>

S3 オリジンの CloudFront ディストリビューション用に OAC を設定するには、「*Amazon CloudFront デベロッパーガイド*」の「[Amazon S3 オリジンへのアクセス制限](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html)」を参照してください。

## [CloudFront.14] CloudFront ディストリビューションにはタグを付ける必要があります
<a name="cloudfront-14"></a>

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

**重要度:** 低

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

**AWS Config rule:**`tagged-cloudfront-distribution` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon CloudFront ディストリビューションにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。ディストリビューションにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ディストリビューションにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くの がアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「*AWS 全般のリファレンス*」の「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。

### 修正
<a name="cloudfront-14-remediation"></a>

CloudFront ディストリビューションにタグを追加するには、「*Amazon CloudFront デベロッパーガイド*」の「[Amazon CloudFront ディストリビューションのタグ付け](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/tagging.html)」を参照してください。

## [CloudFront.15] CloudFront ディストリビューションは、推奨される TLS セキュリティポリシーを使用する必要があります
<a name="cloudfront-15"></a>

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-ssl-policy-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-ssl-policy-check.html)

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

**パラメータ:** `securityPolicies`: `TLSv1.2_2021,TLSv1.2_2025,TLSv1.3_2025` (カスタマイズ不可)

このコントロールは、Amazon CloudFront ディストリビューションが推奨 TLS セキュリティポリシーを使用するように設定されているかどうかを確認します。CloudFront ディストリビューションが推奨される TLS セキュリティポリシーを使用するように設定されていない場合、コントロールは失敗します。

ビューワーが HTTPS を使用してコンテンツにアクセスするように Amazon CloudFront ディストリビューションを設定する場合は、セキュリティポリシーを選択し、使用する最小 SSL/TLS プロトコルバージョンを指定する必要があります。これにより、CloudFront がビューワーとの通信に使用するプロトコルバージョンと、CloudFront が通信の暗号化に使用する暗号が決まります。CloudFront が提供する最新のセキュリティポリシーを使用することをお勧めします。これにより、CloudFront は最新の暗号スイートを使用して、ビューワーと CloudFront ディストリビューション間の転送中のデータを暗号化します。

**注記**  
このコントロールは、カスタム SSL 証明書を使用するように設定され、レガシークライアントをサポートするように設定されていない CloudFront ディストリビューションについてのみ結果を生成します。

### 修正
<a name="cloudfront-15-remediation"></a>

CloudFront ディストリビューションのセキュリティポリシー設定の詳細については、「*Amazon CloudFront デベロッパーガイド*」の「[ディストリビューションの更新](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/HowToUpdateDistribution.html)」を参照してください。ディストリビューションのセキュリティポリシーを設定するときは、最新のセキュリティポリシーを選択してください。

## [CloudFront.16] CloudFront ディストリビューションでは、Lambda 関数 URL オリジンのオリジンアクセスコントロールを使用する必要があります
<a name="cloudfront-16"></a>

**カテゴリ:** 保護 > セキュアなアクセス管理 > アクセスコントロール

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-origin-lambda-url-oac-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-origin-lambda-url-oac-enabled.html)

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

**パラメータ :** なし

このコントロールは、オリジンとして AWS Lambda 関数 URL を持つ Amazon CloudFront ディストリビューションでオリジンアクセスコントロール (OAC) が有効になっているかどうかを確認します。CloudFront ディストリビューションがオリジンとして Lambda 関数 URL を持っており、かつ OAC が有効になっていない場合、コントロールは失敗します。

 AWS Lambda 関数 URL は、Lambda 関数専用の HTTPS エンドポイントです。Lambda 関数 URL が CloudFront ディストリビューションのオリジンである場合、その関数 URL はパブリックアクセス可能である必要があります。したがって、セキュリティのベストプラクティスとして、OAC を作成し、ディストリビューションの Lambda 関数 URL に追加する必要があります。OAC は IAM サービスプリンシパルを使用して、CloudFront と関数 URL 間のリクエストを認証します。また、リソースベースのポリシーを使用して、リクエストがポリシーで指定された CloudFront ディストリビューションに代わって実行されている場合にのみ、関数の呼び出しを許可します。

### 修正
<a name="cloudfront-16-remediation"></a>

Lambda 関数 URL をオリジンとして使用する Amazon CloudFront ディストリビューションの OAC の設定については、*Amazon CloudFront * [デベロッパーガイド」の AWS Lambda 「関数 URL オリジンへのアクセスを制限する](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-lambda.html)」を参照してください。

## [CloudFront.17] CloudFront ディストリビューションは、署名付き URLsと Cookie に信頼されたキーグループを使用する必要があります
<a name="cloudfront-17"></a>

**カテゴリ:** 保護 > セキュアなアクセス管理 > アクセスコントロール

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-distribution-key-group-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-distribution-key-group-enabled.html)

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

**パラメータ :** なし

このコントロールは、Amazon CloudFront ディストリビューションが、署名付き URL または署名付き Cookie 認証に信頼されたキーグループを使用するように設定されているかどうかをチェックします。CloudFront ディストリビューションが信頼された署名者を使用する場合、またはディストリビューションに認証が設定されていない場合、コントロールは失敗します。

署名付き URL または署名付き Cookie を使用するには、*署名者*が必要です。署名者は、CloudFront で作成する信頼されたキーグループ、または CloudFront キーペアを含む AWS アカウントのいずれかです。CloudFront キーグループでは、CloudFront 署名付き URLsと署名付き Cookie のパブリックキーを管理するために AWS アカウントのルートユーザーを使用する必要がないため、信頼されたキーグループを使用することをお勧めします。

**注記**  
このコントロールは、マルチテナント CloudFront ディストリビューション を評価しません`(connectionMode=tenant-only)`。

### 修正
<a name="cloudfront-17-remediation"></a>

署名付き URLs*Amazon CloudFront * [デベロッパーガイド」の「信頼されたキーグループ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html)の使用」を参照してください。

# の Security Hub CSPM コントロール AWS CloudTrail
<a name="cloudtrail-controls"></a>

これらの AWS Security Hub CSPM コントロールは、 AWS CloudTrail サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

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

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/3.1、 CIS AWS Foundations Benchmark v1.2.0/2.1、 CIS AWS Foundations Benchmark v1.4.0/3.1、 CIS AWS Foundations Benchmark v3.0.0/3.1、 NIST.800-53.r5 AC-2(4)、 NIST.800-53.r5 AC-4(26)、 NIST.800-53.r5 AC-6(9)、 NIST.800-53.r5 AU-10、 NIST.800-53.r5 AU-12、 NIST.800-53.r5 AU-2、 NIST.800-53.r5 AU-3、 NIST.800-53.r5 AU-6(3)、 NIST.800-53.r5 AU-6(4)、 NIST.800-53.r5 AU-14(1)、 NIST.800-53.r5 CA-7、 NIST.800-53.r5 SC-7(9)、 NIST.800-53.r5 SI-3(8)、 NIST.800-53.r5 SI-4(20)、 NIST.800-53.r5 SI-7(8)、 NIST.800-53.r5 SA-8(22)

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/multi-region-cloudtrail-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/multi-region-cloudtrail-enabled.html)

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

**パラメータ :**
+ `readWriteType`: `ALL` (カスタマイズ不可)

  `includeManagementEvents`: `true` (カスタマイズ不可)

このコントロールは、読み取りおよび書き込み管理イベントをキャプチャするマルチリージョン AWS CloudTrail 証跡が少なくとも 1 つあるかどうかを確認します。CloudTrail が無効になっているか、読み取りおよび書き込み管理イベントをキャプチャする CloudTrail 証跡が少なくとも 1 つ存在しない場合、コントロールは失敗します。

AWS CloudTrail は、アカウントの AWS API コールを記録し、ログファイルを配信します。記録された情報には、以下の情報が含まれます。
+ API 発信者の ID
+ API コールの時刻
+ API 発信者の送信元 IP アドレス
+ リクエストパラメータ
+ によって返されるレスポンス要素 AWS のサービス

CloudTrail は、、 AWS SDKs AWS マネジメントコンソール、コマンドラインツールからの AWS API コールなど、アカウントの API コールの履歴を提供します。履歴には、 AWS のサービス などの上位レベルの API コールも含まれます AWS CloudFormation。

CloudTrail によって生成された AWS API コール履歴により、セキュリティ分析、リソース変更の追跡、コンプライアンス監査が可能になります。マルチリージョン追跡には、次の利点もあります。
+ マルチリージョン追跡により、使用していないリージョンで発生する予期しないアクティビティを検出できます。
+ マルチリージョン追跡では、グローバルサービスイベントのログ記録がデフォルトで追跡に対して確実に有効になっています。グローバルサービスイベントのログ記録は、 AWS グローバルサービスによって生成されたイベントを記録します。
+ マルチリージョン追跡では、すべての読み取りオペレーションと書き込みオペレーションの管理イベントによって、CloudTrail がすべての AWS アカウントアカウントのリソースに対する管理オペレーションを確実に記録します。

デフォルトでは、 を使用して作成された CloudTrail 証跡はマルチリージョン証跡 AWS マネジメントコンソール です。

### 修正
<a name="cloudtrail-1-remediation"></a>

CloudTrail で新しいマルチリージョンの追跡を作成するには、「*AWS CloudTrail ユーザーガイド*」の「[追跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)」を参照してください。以下の値を使用します。


| フィールド | 値 | 
| --- | --- | 
|  追加設定、ログファイル検証  |  有効  | 
|  ログイベント、管理イベント、API アクティビティを選択  |  **[読み取り]** と **[書き込み]** 除外にするチェックボックスはオフにしてください。  | 

既存の追跡を更新するには、「*AWS CloudTrail ユーザーガイド*」の「[追跡の更新](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-update-a-trail-console.html)」を参照してください。**[管理イベント]** の **[API アクティビティ]** で、**[読み取り]** と **[書き込み]** を選択します。

## [CloudTrail.2] CloudTrail は保管時の暗号化を有効にする必要があります
<a name="cloudtrail-2"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/3.5、CIS AWS Foundations Benchmark v1.2.0/2.7、CIS AWS Foundations Benchmark v1.4.0/3.7、CIS AWS Foundations Benchmark v3.0.0/3.5、NIST.800-53.r5 AU-9、NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53SC-28.r5 SC-28 (1)、NIST.800-53.r5 SC-7 SI-710.3.2

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloud-trail-encryption-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cloud-trail-encryption-enabled.html)

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

**パラメータ:** なし

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

機密性の高い CloudTrail ログファイルのセキュリティを強化するには、CloudTrail ログファイルに [AWS KMS keys (SSE-KMS) を使用したサーバー側の暗号化](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingKMSEncryption.html)を使用して保管時の暗号化を行う必要があります。デフォルトでは、CloudTrail によってバケットに配信されるログファイルは、「[Amazon S3 マネージド暗号化キーによる Amazon サーバー側の暗号化 (SSE-S3)](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html)」によって暗号化されることに注意してください。

### 修正
<a name="cloudtrail-2-remediation"></a>

CloudTrail ログファイルの SSE-KMS 暗号化を有効にするには、「*AWS CloudTrail ユーザーガイド*」の「[KMS キーを使用するように追跡を更新する](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/create-kms-key-policy-for-cloudtrail-update-trail.html#kms-key-policy-update-trail)」を参照してください。

## [CloudTrail.3] 少なくとも 1 つの CloudTrail 証跡を有効にする必要があります
<a name="cloudtrail-3"></a>

**関連する要件:** NIST.800-171.r2 3.3.1、NIST.800-171.r2 3.14.6、NIST.800-171.r2 3.14.7、PCI DSS v3.2.1/10.1、PCI DSS v3.2.1/10.2.1、PCI DSS v3.2.1/10.2.2、PCI DSS v3.2.1/10.2.3、PCI DSS v3.2.1/10.2.4、PCI DSS v3.2.1/10.2.5、PCI DSS v3.2.1/10.2.6、PCI DSS v3.2.1/10.2.7、PCI DSS v3.2.1/10.3.1、PCI DSS v3.2.1/10.3.2、PCI DSS v3.2.1/10.3.3、PCI DSS v3.2.1/10.3.4、PCI DSS v3.2.1/10.3.5、PCI DSS v3.2.1/10.3.6、PCI DSS v4.0.1/10.2.1

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloudtrail-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudtrail-enabled.html)

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

**パラメータ :** なし

このコントロールは、 で AWS CloudTrail 証跡が有効になっているかどうかを確認します AWS アカウント。アカウントに少なくとも 1 つの CloudTrail 追跡が有効になっていない場合、コントロールは失敗します。

ただし、一部の AWS サービスでは、すべての APIsとイベントのログ記録が有効になっていません。CloudTrail 以外の監査追跡を追加で実装し、「[CloudTrail のサポートされているサービスと統合](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html)」内の各サービスのドキュメントを確認してください。

### 修正
<a name="cloudtrail-3-remediation"></a>

CloudTrail の使用を開始し、証跡を作成するには、*AWS CloudTrail 「 ユーザーガイド*」の[「Getting started with AWS CloudTrail tutorial](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-tutorial.html)」を参照してください。

## [PCI.CloudTrail.4] CloudTrail ログファイルの検証を有効にする必要があります
<a name="cloudtrail-4"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/3.2、CIS AWS Foundations Benchmark v1.2.0/2.2、CIS AWS Foundations Benchmark v1.4.0/3.2、CIS AWS Foundations Benchmark v3.0.0/3.2、NIST.800-53.r5 AU-9、NIST.800-53.r5 SI-4、NIST.800-53.r5 SI-7(1)、NIST.800-53.r5 SI-7(3)、NIST.800-53.r5 SI-7(7)、NIST.800-1.r2 3.3.8、PCI v3.210.5.210.5.510.3.2

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

**重要度:** 低

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloud-trail-log-file-validation-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cloud-trail-log-file-validation-enabled.html)

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

**パラメータ:** なし

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

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

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

### 修正
<a name="cloudtrail-4-remediation"></a>

CloudTrail ログファイルの検証を有効にするには、「*AWS CloudTrail ユーザーガイド*」の「[CloudTrail のログファイルの整合性検証を有効にする](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-log-file-validation-enabling.html)」を参照してください。

## [CloudTrail.5] CloudTrail 追跡は Amazon CloudWatch Logs と統合する必要があります
<a name="cloudtrail-5"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/3.4、 PCI DSS v3.2.1/10.5.3、 CIS AWS Foundations Benchmark v1.2.0/2.4、 CIS AWS Foundations Benchmark v1.4.0/3.4、 NIST.800-53.r5 AC-2(4)、 NIST.800-53.r5 AC-4(26)、 NIST.800-53.r5 AC-6(9)、 NIST.800-53.r5 AU-10、 NIST.800-53.r5 AU-12、 NIST.800-53.r5 AU-2、 NIST.800-53.r5 AU-3、 NIST.800-53.r5 AU-6(1)、 NIST.800-53.r5 AU-6(3)、 NIST.800-53.r5 AU-6(4)、 NIST.800-53.r5 AU-6(5)、 NIST.800-53.r5 AU-7(1)、 NIST.800-53.r5 CA-7、 NIST.800-53.r5 SC-7(9)、 NIST.800-53.r5 SI-20、 NIST.800-53.r5 SI-3(8)、 NIST.800-53.r5 SI-4(20)、 NIST.800-53.r5 SI-4(5)、 NIST.800-53.r5 SI-7(8)

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloud-trail-cloud-watch-logs-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cloud-trail-cloud-watch-logs-enabled.html)

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

**パラメータ:** なし

このコントロールは、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 CSPM では、CloudTrail ログを CloudWatch Logs に送信することをお勧めします。この推奨事項は、アカウントアクティビティが確実にキャプチャおよびモニタリングされ、適切なアラームが出されることを確認する目的であることにご注意ください CloudWatch Logs を使用して、 でこれをセットアップできます AWS のサービス。この推奨事項は、別のソリューションの使用を除外するものではありません。

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

### 修正
<a name="cloudtrail-5-remediation"></a>

CloudTrail を CloudWatch Logs と統合するには、「*AWS CloudTrail ユーザーガイド*」の「[CloudWatch Logs へのイベントの送信](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/send-cloudtrail-events-to-cloudwatch-logs.html)」を参照してください。

## [CloudTrail.6] CloudTrail ログの保存に使用される S3 バケットが一般公開されていないことを確認します
<a name="cloudtrail-6"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/2.3、CIS AWS Foundations Benchmark v1.4.0/3.3、PCI DSS v4.0.1/1.4.4

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

**重要度:** 非常事態

**リソースタイプ :** `AWS::S3::Bucket`

**AWS Config ルール:** なし (カスタム Security Hub CSPM ルール)

**スケジュールタイプ:** 定期的および変更がトリガーされた場合

**パラメータ :** なし

CloudTrail は、アカウント内で実行された API コールをすべて記録します。これらのログファイルは S3 バケットに保存されます。CIS では、CloudTrail が記録する S3 バケットに S3 バケットポリシーまたはアクセスコントロールリスト (ACL) を適用して、CloudTrail ログへのパブリックアクセスを禁止することを推奨しています。CloudTrail ログコンテンツへのパブリックアクセスを許可すると、攻撃者が感染したアカウントの使用または設定における弱点を特定する手助けとなる可能性があります。

このチェックを実行するために、Security Hub CSPM はまずカスタムロジックを使用して、CloudTrail ログが保存されている S3 バケットを探します。次に、 AWS Config マネージドルールを使用して、バケットがパブリックにアクセス可能であることを確認します。

ログを 1 つの一元化された S3 バケットに集約する場合、Security Hub CSPM は、一元化された S3 バケットがあるアカウントとリージョンに対してのみチェックを実行します。他のアカウントとリージョンでは、コントロールステータスは **[No data]** (データなし) となります。

バケットがパブリックアクセス可能な場合、チェックにより結果 (失敗) が生成されます。

### 修正
<a name="cloudtrail-6-remediation"></a>

CloudTrail S3 バケットへのパブリックアクセスをブロックするには、「*Amazon Simple Storage Service ユーザーガイド*」の「[3 バケットへのパブリックアクセスブロック設定の構成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/configuring-block-public-access-bucket.html)」を参照してください。4 つの Amazon S3 パブリックアクセスブロック設定をすべて選択します。

## [CloudTrail.7] CloudTrail S3 バケットで、S3 バケットアクセスログ記録が有効であることを確認します
<a name="cloudtrail-7"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/2.6、CIS AWS Foundations Benchmark v1.4.0/3.6、CIS AWS Foundations Benchmark v3.0.0/3.4、PCI DSS v4.0.1/10.2.1

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

**重要度:** 低

**リソースタイプ :** `AWS::S3::Bucket`

**AWS Config ルール:** なし (カスタム Security Hub CSPM ルール)

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

**パラメータ :** なし

S3 バケットアクセスログ記録により、S3 バケットに対して行われたリクエストごとのアクセスレコードを含むログが生成されます。アクセスログレコードには、リクエストのタイプ、リクエストに指定されたリソース、リクエストが処理された日時など、リクエストの詳細が記録されます。

CIS では、CloudTrail S3 バケットでバケットアクセスログ記録を有効にすることを推奨しています。

ターゲット S3 バケットで S3 バケットのログ記録を有効にすることで、ターゲットバケット内のオブジェクトに影響を与える可能性のあるすべてのイベントをキャプチャできます。ログを別のバケットに配置するように設定すると、ログ情報にアクセスできるようになり、セキュリティおよびインシデント対応のワークフローで役立ちます。

このチェックを実行するために、Security Hub CSPM はまずカスタムロジックを使用して CloudTrail ログが保存されているバケットを検索し、次に AWS Config マネージドルールを使用してログ記録が有効になっているかどうかを確認します。

CloudTrail が複数の から 1 つの送信先 Amazon S3 バケット AWS アカウント にログファイルを配信する場合、Security Hub CSPM はこのコントロールが配置されているリージョンの送信先バケットに対してのみこのコントロールを評価します。これにより、結果が効率化されます。ただし、宛先バケットにログを配信するすべてのアカウントで CloudTrail を有効にする必要があります。宛先バケットを保持しているアカウントを除くすべてのアカウントの制御ステータスは「**データなし**」です。

### 修正
<a name="cloudtrail-7-remediation"></a>

CloudTrail S3 バケットのサーバーアクセスのログ記録を有効にするには、「*Amazon Simple Storage Service ユーザーガイド*」の「[Amazon S3 サーバーアクセスログの有効化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html#enable-server-logging)」を参照してください。

## [CloudTrail.9] CloudTrail 証跡にはタグを付ける必要があります
<a name="cloudtrail-9"></a>

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

**重要度:** 低

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

**AWS Config rule:** `tagged-cloudtrail-trail` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、 AWS CloudTrail 証跡にパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。証跡にタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、証跡にキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="cloudtrail-9-remediation"></a>

CloudTrail 証跡にタグを追加するには、「*AWS CloudTrail API リファレンス*」の「[AddTags](https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AddTags.html)」を参照してください。

## [CloudTrail.10] CloudTrail Lake イベントデータストアはカスタマーマネージドで暗号化する必要があります AWS KMS keys
<a name="cloudtrail-10"></a>

**関連する要件:** NIST.800-53.r5 AU-9、NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SC-12(2)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SI-7(6)

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

**重要度:** 中

**リソースタイプ :** `AWS::CloudTrail::EventDataStore`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/event-data-store-cmk-encryption-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/event-data-store-cmk-encryption-enabled.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `kmsKeyArns`  |  評価 AWS KMS keys に含める の Amazon リソースネーム (ARNs) のリスト。イベントデータストアがリスト内の KMS キーで暗号化されていない場合、コントロールは `FAILED` 結果を生成します。  |  StringList (最大 3 項目)  |  既存の KMS キーの 1～3 個の ARN。例: `arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab`。  |  デフォルト値なし  | 

このコントロールは、 AWS CloudTrail Lake イベントデータストアがカスタマーマネージドで保管中に暗号化されているかどうかをチェックします AWS KMS key。イベントデータストアがカスタマーマネージド KMS キーで暗号化されていない場合、コントロールは失敗します。必要に応じて、コントロールの評価に含める KMS キーのリストを指定することができます。

デフォルトでは、 AWS CloudTrail Lake は AES-256 アルゴリズムを使用して Amazon S3 マネージドキー (SSE-S3) でイベントデータストアを暗号化します。追加の制御のために、代わりにカスタマーマネージド AWS KMS key (SSE-KMS) を使用してイベントデータストアを暗号化するように CloudTrail Lake を設定できます。カスタマーマネージド KMS キーは、 AWS KMS key で作成、所有、管理する です AWS アカウント。ユーザーは、このタイプの KMS キーについては完全なコントロール権を持ちます。これには、キーポリシーの定義と維持管理、許可の管理、暗号化マテリアルのローテーション、タグの割り当て、エイリアスの作成、キーの有効化と無効化が含まれます。CloudTrail データの暗号化オペレーションでカスタマーマネージド KMS キーを使用して、CloudTrail ログでその使用を監査することができます。

### 修正
<a name="cloudtrail-10-remediation"></a>

指定した を使用して AWS CloudTrail Lake イベントデータストアを暗号化する方法については、*AWS CloudTrail 「 ユーザーガイド*」の AWS KMS key [「イベントデータストアの更新](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/query-event-data-store-update.html)」を参照してください。イベントデータストアを KMS キーに関連付けた後に、その KMS キーを削除または変更することはできません。

# Amazon CloudWatch の Security Hub CSPM コントロール
<a name="cloudwatch-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon CloudWatch サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [CloudWatch.1] 「ルート」ユーザーの使用に対するログメトリクスフィルターとアラームが存在する必要があります
<a name="cloudwatch-1"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/1.1、CIS AWS Foundations Benchmark v1.2.0/3.3、CIS AWS Foundations Benchmark v1.4.0/1.7、CIS AWS Foundations Benchmark v1.4.0/4.3、NIST.800-171.r2 3.14.6、NIST.800-171.r2 3.14.7、PCI DSS v3.2.1/7.2.1

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

**重大度:** 低

**リソースタイプ:** `AWS::Logs::MetricFilter`、`AWS::CloudWatch::Alarm`、`AWS::CloudTrail::Trail`、`AWS::SNS::Topic`

**AWS Config ルール:** なし (カスタム Security Hub CSPM ルール)

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

**パラメータ :** なし

ルートユーザーは、 AWS アカウントのすべてのリソースとサービスに完全かつ無制限にアクセスできます。日常的なタスクにはルートユーザーを使用しないことが強く推奨されます。ルートユーザーの使用を最小限にし、アクセス管理の最小特権の原則を採用することにより、高い権限を持つ認証情報の意図しない変更や偶発的な開示のリスクが軽減されます。

ベストプラクティスは、[アカウントおよびサービスの管理タスクを実行する](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html)ときに必要となる場合のみ、ルートユーザー認証情報を使用することです。 AWS Identity and Access Management (IAM) ポリシーをグループとロールに直接適用しますが、ユーザーには適用されません。日常的に使用する管理者を設定する方法のチュートリアルについては、「*IAM ユーザーガイド*」の「[Creating your first IAM admin user and group](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html)」を参照してください。

このチェックを実行するために、Security Hub CSPM はカスタムロジックを使用して、[CIS AWS Foundations Benchmark v1.4.0 のコントロール 1.7 ](https://acrobat.adobe.com/link/track?uri=urn:aaid:scds:US:2e5fec5c-5e99-4fb5-b08d-bb46b14754c1#pageNum=1)に規定された正確な監査ステップを実行します。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

**注記**  
Security Hub CSPM がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡を検索します。これらの追跡は、別のアカウントに属する組織の追跡である可能性があります。マルチリージョンの追跡は、別のリージョンに基づいている可能性もあります。  
チェックの結果、以下の場合は結果 `FAILED` となります。  
追跡が設定されていません。
現在のリージョンにあり、現在のアカウントが所有している利用可能な追跡が、コントロール要件を満たしていません。
チェックの結果、以下の場合はコントロール状況が `NO_DATA` になります。  
マルチリージョンの追跡が別のリージョンに基づいています。Security Hub CSPM は、証跡が基づいているリージョンでのみ結果を生成できます。
マルチリージョンの追跡が別のアカウントに属しています。Security Hub CSPM は、証跡を所有するアカウントの結果のみを生成できます。  
組織内の多数のアカウントからのイベントを記録するには、組織の証跡をお勧めします。組織の証跡はデフォルトではマルチリージョンの証跡であり、 AWS Organizations 管理アカウントまたは CloudTrail 委任管理者アカウントによってのみ管理できます。組織の証跡を使用すると、組織のメンバーアカウントで評価されたコントロールの管理ステータスは `NO_DATA` になります。メンバーアカウントでは、Security Hub CSPM はメンバー所有のリソースの結果のみを生成します。組織の証跡に関する検出結果は、リソース所有者のアカウントで生成されます。これらの検出結果は、クロスリージョン集約を使用して Security Hub CSPM 委任管理者アカウントで確認できます。
アラームの場合、現在のアカウントは、参照されている Amazon SNS トピックを所有しているか、`ListSubscriptionsByTopic` を呼び出すことで Amazon SNS トピックにアクセスできる必要があります。それ以外の場合、Security Hub CSPM はコントロールの検出`WARNING`結果を生成します。

### 修正
<a name="cloudwatch-1-remediation"></a>

このコントロールに合格するには、以下の手順に従って Amazon SNS トピック、 AWS CloudTrail 追跡、メトリクスフィルター、メトリクスフィルターのアラームを作成します。

1. Amazon SNS トピックを作成します。詳細については、「*Amazon Simple Notification Service デベロッパーガイド*」の「[Amazon SNS の開始方法](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic)」を参照してください。すべての CIS アラームを受信するトピックを作成し、そのトピックへのサブスクリプションを少なくとも 1 つ作成します。

1. すべての AWS リージョンに適用される CloudTrail 追跡を作成します。手順については、「*AWS CloudTrail ユーザーガイド*」の「[追跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)」を参照してください。

   CloudTrail 追跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。次の手順で、そのロググループに対してメトリクスフィルターを作成します。

1. メトリクスのフィルターを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

1. フィルターに基づいてアラームを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターに基づく CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.2] 不正な API 呼び出しに対してログメトリクスフィルターとアラームが存在することを確認します
<a name="cloudwatch-2"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/3.1、NIST.800-171.r2 3.13.1、NIST.800-171.r2 3.14.6、NIST.800-171.r2 3.14.7

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

**重大度:** 低

**リソースタイプ:** `AWS::Logs::MetricFilter`、`AWS::CloudWatch::Alarm`、`AWS::CloudTrail::Trail`、`AWS::SNS::Topic`

**AWS Config ルール:** なし (カスタム Security Hub CSPM ルール)

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

**パラメータ :** なし

CloudTrail ログを CloudWatch Logs に転送し、対応するメトリクスフィルターとアラームを設定することにより、API コールのリアルタイムモニタリングを実行できます。

CIS では、不正な API コールに対するメトリクスフィルターとアラームを作成することを推奨しています。不正な API コールをモニタリングすることでアプリケーションエラーを明らかにし、悪意のあるアクティビティを検出するのにかかる時間を短縮できる可能性があります。

このチェックを実行するために、Security Hub CSPM はカスタムロジックを使用して、[CIS AWS Foundations Benchmark v1.2 のコントロール 3.1 ](https://d1.awsstatic.com/whitepapers/compliance/AWS_CIS_Foundations_Benchmark.pdf)に規定された正確な監査ステップを実行します。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

**注記**  
Security Hub CSPM がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡を検索します。これらの追跡は、別のアカウントに属する組織の追跡である可能性があります。マルチリージョンの追跡は、別のリージョンに基づいている可能性もあります。  
チェックの結果、以下の場合は結果 `FAILED` となります。  
追跡が設定されていません。
現在のリージョンにあり、現在のアカウントが所有している利用可能な追跡が、コントロール要件を満たしていません。
チェックの結果、以下の場合はコントロール状況が `NO_DATA` になります。  
マルチリージョンの追跡が別のリージョンに基づいています。Security Hub CSPM は、証跡が基づいているリージョンでのみ結果を生成できます。
マルチリージョンの追跡が別のアカウントに属しています。Security Hub CSPM は、証跡を所有するアカウントの結果のみを生成できます。  
組織内の多数のアカウントからのイベントを記録するには、組織の証跡をお勧めします。組織の証跡はデフォルトではマルチリージョンの証跡であり、 AWS Organizations 管理アカウントまたは CloudTrail 委任管理者アカウントによってのみ管理できます。組織の証跡を使用すると、組織のメンバーアカウントで評価されたコントロールの管理ステータスは `NO_DATA` になります。メンバーアカウントでは、Security Hub CSPM はメンバー所有のリソースの結果のみを生成します。組織の証跡に関する検出結果は、リソース所有者のアカウントで生成されます。これらの検出結果は、クロスリージョン集約を使用して Security Hub CSPM 委任管理者アカウントで確認できます。
アラームの場合、現在のアカウントは、参照されている Amazon SNS トピックを所有しているか、`ListSubscriptionsByTopic` を呼び出すことで Amazon SNS トピックにアクセスできる必要があります。それ以外の場合、Security Hub CSPM はコントロールの検出`WARNING`結果を生成します。

### 修正
<a name="cloudwatch-2-remediation"></a>

このコントロールに合格するには、以下の手順に従って Amazon SNS トピック、 AWS CloudTrail 追跡、メトリクスフィルター、メトリクスフィルターのアラームを作成します。

1. Amazon SNS トピックを作成します。詳細については、「*Amazon Simple Notification Service デベロッパーガイド*」の「[Amazon SNS の開始方法](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic)」を参照してください。すべての CIS アラームを受信するトピックを作成し、そのトピックへのサブスクリプションを少なくとも 1 つ作成します。

1. すべての AWS リージョンに適用される CloudTrail 追跡を作成します。手順については、「*AWS CloudTrail ユーザーガイド*」の「[追跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)」を参照してください。

   CloudTrail 追跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。次の手順で、そのロググループに対してメトリクスフィルターを作成します。

1. メトリクスのフィルターを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

1. フィルターに基づいてアラームを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターに基づく CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.3] MFA を使用しないマネジメントコンソールサインインに対してログメトリクスフィルターとアラームが存在することを確認します
<a name="cloudwatch-3"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/3.2

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

**重大度:** 低

**リソースタイプ:** `AWS::Logs::MetricFilter`、`AWS::CloudWatch::Alarm`、`AWS::CloudTrail::Trail`、`AWS::SNS::Topic`

**AWS Config ルール:** なし (カスタム Security Hub CSPM ルール)

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

**パラメータ :** なし

CloudTrail ログを CloudWatch Logs に転送し、対応するメトリクスフィルターとアラームを設定することにより、API コールのリアルタイムモニタリングを実行できます。

CIS では、MFA で保護されていないコンソールログインに対するメトリクスフィルターとアラームを作成することを推奨しています。単一要素のコンソールログインをモニタリングすることにより、MFA によって保護されていないアカウントへの可視性が向上します。

このチェックを実行するために、Security Hub CSPM はカスタムロジックを使用して、[CIS AWS Foundations Benchmark v1.2 のコントロール 3.2 ](https://d1.awsstatic.com/whitepapers/compliance/AWS_CIS_Foundations_Benchmark.pdf)に規定された正確な監査ステップを実行します。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

**注記**  
Security Hub CSPM がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡を検索します。これらの追跡は、別のアカウントに属する組織の追跡である可能性があります。マルチリージョンの追跡は、別のリージョンに基づいている可能性もあります。  
チェックの結果、以下の場合は結果 `FAILED` となります。  
追跡が設定されていません。
現在のリージョンにあり、現在のアカウントが所有している利用可能な追跡が、コントロール要件を満たしていません。
チェックの結果、以下の場合はコントロール状況が `NO_DATA` になります。  
マルチリージョンの追跡が別のリージョンに基づいています。Security Hub CSPM は、証跡が基づいているリージョンでのみ結果を生成できます。
マルチリージョンの追跡が別のアカウントに属しています。Security Hub CSPM は、証跡を所有するアカウントの結果のみを生成できます。  
組織内の多数のアカウントからのイベントを記録するには、組織の証跡をお勧めします。組織の証跡はデフォルトではマルチリージョンの証跡であり、 AWS Organizations 管理アカウントまたは CloudTrail 委任管理者アカウントによってのみ管理できます。組織の証跡を使用すると、組織のメンバーアカウントで評価されたコントロールの管理ステータスは `NO_DATA` になります。メンバーアカウントでは、Security Hub CSPM はメンバー所有のリソースの結果のみを生成します。組織の証跡に関する検出結果は、リソース所有者のアカウントで生成されます。これらの検出結果は、クロスリージョン集約を使用して Security Hub CSPM 委任管理者アカウントで確認できます。
アラームの場合、現在のアカウントは、参照されている Amazon SNS トピックを所有しているか、`ListSubscriptionsByTopic` を呼び出すことで Amazon SNS トピックにアクセスできる必要があります。それ以外の場合、Security Hub CSPM はコントロールの検出`WARNING`結果を生成します。

### 修正
<a name="cloudwatch-3-remediation"></a>

このコントロールに合格するには、以下の手順に従って Amazon SNS トピック、 AWS CloudTrail 追跡、メトリクスフィルター、メトリクスフィルターのアラームを作成します。

1. Amazon SNS トピックを作成します。詳細については、「*Amazon Simple Notification Service デベロッパーガイド*」の「[Amazon SNS の開始方法](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic)」を参照してください。すべての CIS アラームを受信するトピックを作成し、そのトピックへのサブスクリプションを少なくとも 1 つ作成します。

1. すべての AWS リージョンに適用される CloudTrail 追跡を作成します。手順については、「*AWS CloudTrail ユーザーガイド*」の「[追跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)」を参照してください。

   CloudTrail 追跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。次の手順で、そのロググループに対してメトリクスフィルターを作成します。

1. メトリクスのフィルターを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

1. フィルターに基づいてアラームを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターに基づく CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.4] IAM ポリシーの変更に対するログメトリクスフィルターとアラームが存在することを確認します
<a name="cloudwatch-4"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/3.4、CIS AWS Foundations Benchmark v1.4.0/4.4、NIST.800-171.r2 3.14.6、NIST.800-171.r2 3.14.7

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

**重大度:** 低

**リソースタイプ:** `AWS::Logs::MetricFilter`、`AWS::CloudWatch::Alarm`、`AWS::CloudTrail::Trail`、`AWS::SNS::Topic`

**AWS Config ルール:** なし (カスタム Security Hub CSPM ルール)

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

**パラメータ :** なし

このコントロールは、CloudTrail ログを CloudWatch Logs に転送し、対応するメトリクスフィルターとアラームを設定することにより、API コールのリアルタイムモニタリングを実行するかどうかを確認します。

CIS では、IAM ポリシーに加えられた変更に対するメトリクスフィルターとアラームを作成することを推奨しています。これらの変更をモニタリングすることで、認証と認可の管理が損なわれないようにできます。

**注記**  
Security Hub CSPM がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡を検索します。これらの追跡は、別のアカウントに属する組織の追跡である可能性があります。マルチリージョンの追跡は、別のリージョンに基づいている可能性もあります。  
チェックの結果、以下の場合は結果 `FAILED` となります。  
追跡が設定されていません。
現在のリージョンにあり、現在のアカウントが所有している利用可能な追跡が、コントロール要件を満たしていません。
チェックの結果、以下の場合はコントロール状況が `NO_DATA` になります。  
マルチリージョンの追跡が別のリージョンに基づいています。Security Hub CSPM は、証跡が基づいているリージョンでのみ結果を生成できます。
マルチリージョンの追跡が別のアカウントに属しています。Security Hub CSPM は、証跡を所有するアカウントの結果のみを生成できます。  
組織内の多数のアカウントからのイベントを記録するには、組織の証跡をお勧めします。組織の証跡はデフォルトではマルチリージョンの証跡であり、 AWS Organizations 管理アカウントまたは CloudTrail 委任管理者アカウントによってのみ管理できます。組織の証跡を使用すると、組織のメンバーアカウントで評価されたコントロールの管理ステータスは `NO_DATA` になります。メンバーアカウントでは、Security Hub CSPM はメンバー所有のリソースの結果のみを生成します。組織の証跡に関する検出結果は、リソース所有者のアカウントで生成されます。これらの検出結果は、クロスリージョン集約を使用して Security Hub CSPM 委任管理者アカウントで確認できます。
アラームの場合、現在のアカウントは、参照されている Amazon SNS トピックを所有しているか、`ListSubscriptionsByTopic` を呼び出すことで Amazon SNS トピックにアクセスできる必要があります。それ以外の場合、Security Hub CSPM はコントロールの検出`WARNING`結果を生成します。

### 修正
<a name="cloudwatch-4-remediation"></a>

**注記**  
これらの修復手順で推奨されるフィルターパターンは、CIS ガイダンスのフィルターパターンとは異なります。推奨フィルターは IAM API 呼び出しからのイベントのみを対象としています。

このコントロールに合格するには、以下の手順に従って Amazon SNS トピック、 AWS CloudTrail 追跡、メトリクスフィルター、メトリクスフィルターのアラームを作成します。

1. Amazon SNS トピックを作成します。詳細については、「*Amazon Simple Notification Service デベロッパーガイド*」の「[Amazon SNS の開始方法](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic)」を参照してください。すべての CIS アラームを受信するトピックを作成し、そのトピックへのサブスクリプションを少なくとも 1 つ作成します。

1. すべての AWS リージョンに適用される CloudTrail 追跡を作成します。手順については、「*AWS CloudTrail ユーザーガイド*」の「[追跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)」を参照してください。

   CloudTrail 追跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。次の手順で、そのロググループに対してメトリクスフィルターを作成します。

1. メトリクスのフィルターを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

1. フィルターに基づいてアラームを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターに基づく CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.5] CloudTrail 設定の変更に対するログメトリクスフィルターとアラームが存在することを確認します
<a name="cloudwatch-5"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/3.5、CIS AWS Foundations Benchmark v1.4.0/4.5、NIST.800-171.r2 3.3.8、NIST.800-171.r2 3.14.6、NIST.800-171.r2 3.14.7

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

**重大度:** 低

**リソースタイプ:** `AWS::Logs::MetricFilter`、`AWS::CloudWatch::Alarm`、`AWS::CloudTrail::Trail`、`AWS::SNS::Topic`

**AWS Config ルール:** なし (カスタム Security Hub CSPM ルール)

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

**パラメータ :** なし

CloudTrail ログを CloudWatch Logs に転送し、対応するメトリクスフィルターとアラームを設定することにより、API コールのリアルタイムモニタリングを実行できます。

CIS では、CloudTrail 構成設定の変更に対するメトリクスフィルターとアラームを作成することを推奨しています。これらの変更をモニタリングすることで、アカウント内のアクティビティを継続的に可視化できます。

このチェックを実行するために、Security Hub CSPM はカスタムロジックを使用して、[CIS AWS Foundations Benchmark v1.4.0 のコントロール 4.5 ](https://acrobat.adobe.com/link/track?uri=urn:aaid:scds:US:2e5fec5c-5e99-4fb5-b08d-bb46b14754c1#pageNum=1)に規定された正確な監査ステップを実行します。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

**注記**  
Security Hub CSPM がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡を検索します。これらの追跡は、別のアカウントに属する組織の追跡である可能性があります。マルチリージョンの追跡は、別のリージョンに基づいている可能性もあります。  
チェックの結果、以下の場合は結果 `FAILED` となります。  
追跡が設定されていません。
現在のリージョンにあり、現在のアカウントが所有している利用可能な追跡が、コントロール要件を満たしていません。
チェックの結果、以下の場合はコントロール状況が `NO_DATA` になります。  
マルチリージョンの追跡が別のリージョンに基づいています。Security Hub CSPM は、証跡が基づいているリージョンでのみ結果を生成できます。
マルチリージョンの追跡が別のアカウントに属しています。Security Hub CSPM は、証跡を所有するアカウントの結果のみを生成できます。  
組織内の多数のアカウントからのイベントを記録するには、組織の証跡をお勧めします。組織の証跡はデフォルトではマルチリージョンの証跡であり、 AWS Organizations 管理アカウントまたは CloudTrail 委任管理者アカウントによってのみ管理できます。組織の証跡を使用すると、組織のメンバーアカウントで評価されたコントロールの管理ステータスは `NO_DATA` になります。メンバーアカウントでは、Security Hub CSPM はメンバー所有のリソースの結果のみを生成します。組織の証跡に関する検出結果は、リソース所有者のアカウントで生成されます。これらの検出結果は、クロスリージョン集約を使用して Security Hub CSPM 委任管理者アカウントで確認できます。
アラームの場合、現在のアカウントは、参照されている Amazon SNS トピックを所有しているか、`ListSubscriptionsByTopic` を呼び出すことで Amazon SNS トピックにアクセスできる必要があります。それ以外の場合、Security Hub CSPM はコントロールの検出`WARNING`結果を生成します。

### 修正
<a name="cloudwatch-5-remediation"></a>

このコントロールに合格するには、以下の手順に従って Amazon SNS トピック、 AWS CloudTrail 追跡、メトリクスフィルター、メトリクスフィルターのアラームを作成します。

1. Amazon SNS トピックを作成します。詳細については、「*Amazon Simple Notification Service デベロッパーガイド*」の「[Amazon SNS の開始方法](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic)」を参照してください。すべての CIS アラームを受信するトピックを作成し、そのトピックへのサブスクリプションを少なくとも 1 つ作成します。

1. すべての AWS リージョンに適用される CloudTrail 追跡を作成します。手順については、「*AWS CloudTrail ユーザーガイド*」の「[追跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)」を参照してください。

   CloudTrail 追跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。次の手順で、そのロググループに対してメトリクスフィルターを作成します。

1. メトリクスのフィルターを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

1. フィルターに基づいてアラームを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターに基づく CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.6] AWS マネジメントコンソール 認証の失敗に対してログメトリクスフィルターとアラームが存在することを確認する
<a name="cloudwatch-6"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/3.6、CIS AWS Foundations Benchmark v1.4.0/4.6、NIST.800-171.r2 3.14.6、NIST.800-171.r2 3.14.7

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

**重大度:** 低

**リソースタイプ:** `AWS::Logs::MetricFilter`、`AWS::CloudWatch::Alarm`、`AWS::CloudTrail::Trail`、`AWS::SNS::Topic`

**AWS Config ルール:** なし (カスタム Security Hub CSPM ルール)

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

**パラメータ :** なし

CloudTrail ログを CloudWatch Logs に転送し、対応するメトリクスフィルターとアラームを設定することにより、API コールのリアルタイムモニタリングを実行できます。

CIS では、コンソール認証の試行の失敗に対するメトリクスフィルターとアラームを作成することを推奨しています。コンソールログインの失敗をモニタリングすることにより、認証情報へのブルートフォース攻撃の試行の検出にかかるリードタイムを短縮できる可能性があり、ソース IP などの、他のイベント相関で使用できるインジケータが得られる可能性もあります。

このチェックを実行するために、Security Hub CSPM はカスタムロジックを使用して、[CIS AWS Foundations Benchmark v1.4.0 のコントロール 4.6 ](https://acrobat.adobe.com/link/track?uri=urn:aaid:scds:US:2e5fec5c-5e99-4fb5-b08d-bb46b14754c1#pageNum=1)に規定された正確な監査ステップを実行します。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

**注記**  
Security Hub CSPM がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡を検索します。これらの追跡は、別のアカウントに属する組織の追跡である可能性があります。マルチリージョンの追跡は、別のリージョンに基づいている可能性もあります。  
チェックの結果、以下の場合は結果 `FAILED` となります。  
追跡が設定されていません。
現在のリージョンにあり、現在のアカウントが所有している利用可能な追跡が、コントロール要件を満たしていません。
チェックの結果、以下の場合はコントロール状況が `NO_DATA` になります。  
マルチリージョンの追跡が別のリージョンに基づいています。Security Hub CSPM は、証跡が基づいているリージョンでのみ結果を生成できます。
マルチリージョンの追跡が別のアカウントに属しています。Security Hub CSPM は、証跡を所有するアカウントの結果のみを生成できます。  
組織内の多数のアカウントからのイベントを記録するには、組織の証跡をお勧めします。組織の証跡はデフォルトではマルチリージョンの証跡であり、 AWS Organizations 管理アカウントまたは CloudTrail 委任管理者アカウントによってのみ管理できます。組織の証跡を使用すると、組織のメンバーアカウントで評価されたコントロールの管理ステータスは `NO_DATA` になります。メンバーアカウントでは、Security Hub CSPM はメンバー所有のリソースの結果のみを生成します。組織の証跡に関する検出結果は、リソース所有者のアカウントで生成されます。これらの検出結果は、クロスリージョン集約を使用して Security Hub CSPM 委任管理者アカウントで確認できます。
アラームの場合、現在のアカウントは、参照されている Amazon SNS トピックを所有しているか、`ListSubscriptionsByTopic` を呼び出すことで Amazon SNS トピックにアクセスできる必要があります。それ以外の場合、Security Hub CSPM はコントロールの検出`WARNING`結果を生成します。

### 修正
<a name="cloudwatch-6-remediation"></a>

このコントロールに合格するには、以下の手順に従って Amazon SNS トピック、 AWS CloudTrail 追跡、メトリクスフィルター、メトリクスフィルターのアラームを作成します。

1. Amazon SNS トピックを作成します。詳細については、「*Amazon Simple Notification Service デベロッパーガイド*」の「[Amazon SNS の開始方法](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic)」を参照してください。すべての CIS アラームを受信するトピックを作成し、そのトピックへのサブスクリプションを少なくとも 1 つ作成します。

1. すべての AWS リージョンに適用される CloudTrail 追跡を作成します。手順については、「*AWS CloudTrail ユーザーガイド*」の「[追跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)」を参照してください。

   CloudTrail 追跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。次の手順で、そのロググループに対してメトリクスフィルターを作成します。

1. メトリクスのフィルターを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

1. フィルターに基づいてアラームを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターに基づく CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.7] カスタマーマネージドキーの無効化またはスケジュールされた削除に対するログメトリクスフィルターとアラームが存在することを確認します
<a name="cloudwatch-7"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/3.7、CIS AWS Foundations Benchmark v1.4.0/4.7、NIST.800-171.r2 3.13.10、NIST.800-171.r2 3.13.16、NIST.800-171.r2 3.14.6、NIST.800-171.r2 3.14.7

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

**重大度:** 低

**リソースタイプ:** `AWS::Logs::MetricFilter`、`AWS::CloudWatch::Alarm`、`AWS::CloudTrail::Trail`、`AWS::SNS::Topic`

**AWS Config ルール:** なし (カスタム Security Hub CSPM ルール)

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

**パラメータ :** なし

CloudTrail ログを CloudWatch Logs に転送し、対応するメトリクスフィルターとアラームを設定することにより、API コールのリアルタイムモニタリングを実行できます。

CIS では、状態が無効またはスケジュールされた削除に変更されたカスタマーマネージドキーに対するメトリクスフィルターとアラームを作成することを推奨しています。無効になっているか、または削除されたキーで暗号化されたデータには、アクセスできなくなります。

このチェックを実行するために、Security Hub CSPM はカスタムロジックを使用して、[CIS AWS Foundations Benchmark v1.4.0 のコントロール 4.7 ](https://acrobat.adobe.com/link/track?uri=urn:aaid:scds:US:2e5fec5c-5e99-4fb5-b08d-bb46b14754c1#pageNum=1)に規定された正確な監査ステップを実行します。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。`ExcludeManagementEventSources` が `kms.amazonaws.com` を含む場合も、コントロールは失敗します。

**注記**  
Security Hub CSPM がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡を検索します。これらの追跡は、別のアカウントに属する組織の追跡である可能性があります。マルチリージョンの追跡は、別のリージョンに基づいている可能性もあります。  
チェックの結果、以下の場合は結果 `FAILED` となります。  
追跡が設定されていません。
現在のリージョンにあり、現在のアカウントが所有している利用可能な追跡が、コントロール要件を満たしていません。
チェックの結果、以下の場合はコントロール状況が `NO_DATA` になります。  
マルチリージョンの追跡が別のリージョンに基づいています。Security Hub CSPM は、証跡が基づいているリージョンでのみ結果を生成できます。
マルチリージョンの追跡が別のアカウントに属しています。Security Hub CSPM は、証跡を所有するアカウントの結果のみを生成できます。  
組織内の多数のアカウントからのイベントを記録するには、組織の証跡をお勧めします。組織の証跡はデフォルトではマルチリージョンの証跡であり、 AWS Organizations 管理アカウントまたは CloudTrail 委任管理者アカウントによってのみ管理できます。組織の証跡を使用すると、組織のメンバーアカウントで評価されたコントロールの管理ステータスは `NO_DATA` になります。メンバーアカウントでは、Security Hub CSPM はメンバー所有のリソースの結果のみを生成します。組織の証跡に関する検出結果は、リソース所有者のアカウントで生成されます。これらの検出結果は、クロスリージョン集約を使用して Security Hub CSPM 委任管理者アカウントで確認できます。
アラームの場合、現在のアカウントは、参照されている Amazon SNS トピックを所有しているか、`ListSubscriptionsByTopic` を呼び出すことで Amazon SNS トピックにアクセスできる必要があります。それ以外の場合、Security Hub CSPM はコントロールの検出`WARNING`結果を生成します。

### 修正
<a name="cloudwatch-7-remediation"></a>

このコントロールに合格するには、以下の手順に従って Amazon SNS トピック、 AWS CloudTrail 追跡、メトリクスフィルター、メトリクスフィルターのアラームを作成します。

1. Amazon SNS トピックを作成します。詳細については、「*Amazon Simple Notification Service デベロッパーガイド*」の「[Amazon SNS の開始方法](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic)」を参照してください。すべての CIS アラームを受信するトピックを作成し、そのトピックへのサブスクリプションを少なくとも 1 つ作成します。

1. すべての AWS リージョンに適用される CloudTrail 追跡を作成します。手順については、「*AWS CloudTrail ユーザーガイド*」の「[追跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)」を参照してください。

   CloudTrail 追跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。次の手順で、そのロググループに対してメトリクスフィルターを作成します。

1. メトリクスのフィルターを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

1. フィルターに基づいてアラームを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターに基づく CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.8] S3 バケットポリシーの変更に対するログメトリクスフィルターとアラームが存在することを確認します
<a name="cloudwatch-8"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/3.8、CIS AWS Foundations Benchmark v1.4.0/4.8、NIST.800-171.r2 3.14.6、NIST.800-171.r2 3.14.7

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

**重大度:** 低

**リソースタイプ:** `AWS::Logs::MetricFilter`、`AWS::CloudWatch::Alarm`、`AWS::CloudTrail::Trail`、`AWS::SNS::Topic`

**AWS Config ルール:** なし (カスタム Security Hub CSPM ルール)

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

**パラメータ :** なし

CloudTrail ログを CloudWatch Logs に転送し、対応するメトリクスフィルターとアラームを設定することにより、API コールのリアルタイムモニタリングを実行できます。

CIS では、S3 バケットポリシーの変更に対するメトリクスフィルターとアラームを作成することを推奨しています。これらの変更をモニタリングすることで、機密性の高い S3 バケットの過剰な権限のあるポリシーを検出して修正するまでの時間を短縮できます。

このチェックを実行するために、Security Hub CSPM はカスタムロジックを使用して、[CIS AWS Foundations Benchmark v1.4.0 のコントロール 4.8 ](https://acrobat.adobe.com/link/track?uri=urn:aaid:scds:US:2e5fec5c-5e99-4fb5-b08d-bb46b14754c1#pageNum=1)に規定された正確な監査ステップを実行します。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

**注記**  
Security Hub CSPM がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡を検索します。これらの追跡は、別のアカウントに属する組織の追跡である可能性があります。マルチリージョンの追跡は、別のリージョンに基づいている可能性もあります。  
チェックの結果、以下の場合は結果 `FAILED` となります。  
追跡が設定されていません。
現在のリージョンにあり、現在のアカウントが所有している利用可能な追跡が、コントロール要件を満たしていません。
チェックの結果、以下の場合はコントロール状況が `NO_DATA` になります。  
マルチリージョンの追跡が別のリージョンに基づいています。Security Hub CSPM は、証跡が基づいているリージョンでのみ結果を生成できます。
マルチリージョンの追跡が別のアカウントに属しています。Security Hub CSPM は、証跡を所有するアカウントの結果のみを生成できます。  
組織内の多数のアカウントからのイベントを記録するには、組織の証跡をお勧めします。組織の証跡はデフォルトではマルチリージョンの証跡であり、 AWS Organizations 管理アカウントまたは CloudTrail 委任管理者アカウントによってのみ管理できます。組織の証跡を使用すると、組織のメンバーアカウントで評価されたコントロールの管理ステータスは `NO_DATA` になります。メンバーアカウントでは、Security Hub CSPM はメンバー所有のリソースの結果のみを生成します。組織の証跡に関する検出結果は、リソース所有者のアカウントで生成されます。これらの検出結果は、クロスリージョン集約を使用して Security Hub CSPM 委任管理者アカウントで確認できます。
アラームの場合、現在のアカウントは、参照されている Amazon SNS トピックを所有しているか、`ListSubscriptionsByTopic` を呼び出すことで Amazon SNS トピックにアクセスできる必要があります。それ以外の場合、Security Hub CSPM はコントロールの検出`WARNING`結果を生成します。

### 修正
<a name="cloudwatch-8-remediation"></a>

このコントロールに合格するには、以下の手順に従って Amazon SNS トピック、 AWS CloudTrail 追跡、メトリクスフィルター、メトリクスフィルターのアラームを作成します。

1. Amazon SNS トピックを作成します。詳細については、「*Amazon Simple Notification Service デベロッパーガイド*」の「[Amazon SNS の開始方法](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic)」を参照してください。すべての CIS アラームを受信するトピックを作成し、そのトピックへのサブスクリプションを少なくとも 1 つ作成します。

1. すべての AWS リージョンに適用される CloudTrail 追跡を作成します。手順については、「*AWS CloudTrail ユーザーガイド*」の「[追跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)」を参照してください。

   CloudTrail 追跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。次の手順で、そのロググループに対してメトリクスフィルターを作成します。

1. メトリクスのフィルターを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

1. フィルターに基づいてアラームを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターに基づく CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.9] AWS Config 設定変更のログメトリクスフィルターとアラームが存在することを確認する
<a name="cloudwatch-9"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/3.9、CIS AWS Foundations Benchmark v1.4.0/4.9、NIST.800-171.r2 3.3.8、NIST.800-171.r2 3.14.6、NIST.800-171.r2 3.14.7

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

**重大度:** 低

**リソースタイプ:** `AWS::Logs::MetricFilter`、`AWS::CloudWatch::Alarm`、`AWS::CloudTrail::Trail`、`AWS::SNS::Topic`

**AWS Config ルール:** なし (カスタム Security Hub CSPM ルール)

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

**パラメータ :** なし

CloudTrail ログを CloudWatch Logs に転送し、対応するメトリクスフィルターとアラームを設定することにより、API コールのリアルタイムモニタリングを実行できます。

CIS では、 AWS Config 構成設定の変更に対するメトリクスフィルターとアラームを作成することを推奨しています。これらの変更をモニタリングすることで、アカウント内の設定項目を継続的に可視化できます。

このチェックを実行するために、Security Hub CSPM はカスタムロジックを使用して、[CIS AWS Foundations Benchmark v1.4.0 のコントロール 4.9 ](https://acrobat.adobe.com/link/track?uri=urn:aaid:scds:US:2e5fec5c-5e99-4fb5-b08d-bb46b14754c1#pageNum=1)に規定された正確な監査ステップを実行します。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

**注記**  
Security Hub CSPM がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡を検索します。これらの追跡は、別のアカウントに属する組織の追跡である可能性があります。マルチリージョンの追跡は、別のリージョンに基づいている可能性もあります。  
チェックの結果、以下の場合は結果 `FAILED` となります。  
追跡が設定されていません。
現在のリージョンにあり、現在のアカウントが所有している利用可能な追跡が、コントロール要件を満たしていません。
チェックの結果、以下の場合はコントロール状況が `NO_DATA` になります。  
マルチリージョンの追跡が別のリージョンに基づいています。Security Hub CSPM は、証跡が基づいているリージョンでのみ結果を生成できます。
マルチリージョンの追跡が別のアカウントに属しています。Security Hub CSPM は、証跡を所有するアカウントの結果のみを生成できます。  
組織内の多数のアカウントからのイベントを記録するには、組織の証跡をお勧めします。組織の証跡はデフォルトではマルチリージョンの証跡であり、 AWS Organizations 管理アカウントまたは CloudTrail 委任管理者アカウントによってのみ管理できます。組織の証跡を使用すると、組織のメンバーアカウントで評価されたコントロールの管理ステータスは `NO_DATA` になります。メンバーアカウントでは、Security Hub CSPM はメンバー所有のリソースの結果のみを生成します。組織の証跡に関する検出結果は、リソース所有者のアカウントで生成されます。これらの検出結果は、クロスリージョン集約を使用して Security Hub CSPM 委任管理者アカウントで確認できます。
アラームの場合、現在のアカウントは、参照されている Amazon SNS トピックを所有しているか、`ListSubscriptionsByTopic` を呼び出すことで Amazon SNS トピックにアクセスできる必要があります。それ以外の場合、Security Hub CSPM はコントロールの検出`WARNING`結果を生成します。

### 修正
<a name="cloudwatch-9-remediation"></a>

このコントロールに合格するには、以下の手順に従って Amazon SNS トピック、 AWS CloudTrail 追跡、メトリクスフィルター、メトリクスフィルターのアラームを作成します。

1. Amazon SNS トピックを作成します。詳細については、「*Amazon Simple Notification Service デベロッパーガイド*」の「[Amazon SNS の開始方法](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic)」を参照してください。すべての CIS アラームを受信するトピックを作成し、そのトピックへのサブスクリプションを少なくとも 1 つ作成します。

1. すべての AWS リージョンに適用される CloudTrail 追跡を作成します。手順については、「*AWS CloudTrail ユーザーガイド*」の「[追跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)」を参照してください。

   CloudTrail 追跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。次の手順で、そのロググループに対してメトリクスフィルターを作成します。

1. メトリクスのフィルターを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

1. フィルターに基づいてアラームを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターに基づく CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.10] セキュリティグループの変更に対するログメトリクスフィルターとアラームが存在することを確認します
<a name="cloudwatch-10"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/3.10、CIS AWS Foundations Benchmark v1.4.0/4.10、NIST.800-171.r2 3.14.6、NIST.800-171.r2 3.14.7

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

**重大度:** 低

**リソースタイプ:** `AWS::Logs::MetricFilter`、`AWS::CloudWatch::Alarm`、`AWS::CloudTrail::Trail`、`AWS::SNS::Topic`

**AWS Config ルール:** なし (カスタム Security Hub CSPM ルール)

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

**パラメータ :** なし

CloudTrail ログを CloudWatch Logs に転送し、対応するメトリクスフィルターとアラームを設定することにより、API コールのリアルタイムモニタリングを実行できます。セキュリティグループは、VPC の入力トラフィックと出力トラフィックを制御するステートフルパケットフィルターです。

CIS では、セキュリティグループの変更に対するメトリクスフィルターとアラームを作成することを推奨しています。これらの変更をモニタリングすることにより、リソースやサービスが意図せずに公開されないようにできます。

このチェックを実行するために、Security Hub CSPM はカスタムロジックを使用して、[CIS AWS Foundations Benchmark v1.4.0 のコントロール 4.10 ](https://acrobat.adobe.com/link/track?uri=urn:aaid:scds:US:2e5fec5c-5e99-4fb5-b08d-bb46b14754c1#pageNum=1)に規定された正確な監査ステップを実行します。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

**注記**  
Security Hub CSPM がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡を検索します。これらの追跡は、別のアカウントに属する組織の追跡である可能性があります。マルチリージョンの追跡は、別のリージョンに基づいている可能性もあります。  
チェックの結果、以下の場合は結果 `FAILED` となります。  
追跡が設定されていません。
現在のリージョンにあり、現在のアカウントが所有している利用可能な追跡が、コントロール要件を満たしていません。
チェックの結果、以下の場合はコントロール状況が `NO_DATA` になります。  
マルチリージョンの追跡が別のリージョンに基づいています。Security Hub CSPM は、証跡が基づいているリージョンでのみ結果を生成できます。
マルチリージョンの追跡が別のアカウントに属しています。Security Hub CSPM は、証跡を所有するアカウントの結果のみを生成できます。  
組織内の多数のアカウントからのイベントを記録するには、組織の証跡をお勧めします。組織の証跡はデフォルトではマルチリージョンの証跡であり、 AWS Organizations 管理アカウントまたは CloudTrail 委任管理者アカウントによってのみ管理できます。組織の証跡を使用すると、組織のメンバーアカウントで評価されたコントロールの管理ステータスは `NO_DATA` になります。メンバーアカウントでは、Security Hub CSPM はメンバー所有のリソースの結果のみを生成します。組織の証跡に関する検出結果は、リソース所有者のアカウントで生成されます。これらの検出結果は、クロスリージョン集約を使用して Security Hub CSPM 委任管理者アカウントで確認できます。
アラームの場合、現在のアカウントは、参照されている Amazon SNS トピックを所有しているか、`ListSubscriptionsByTopic` を呼び出すことで Amazon SNS トピックにアクセスできる必要があります。それ以外の場合、Security Hub CSPM はコントロールの検出`WARNING`結果を生成します。

### 修正
<a name="cloudwatch-10-remediation"></a>

このコントロールに合格するには、以下の手順に従って Amazon SNS トピック、 AWS CloudTrail 追跡、メトリクスフィルター、メトリクスフィルターのアラームを作成します。

1. Amazon SNS トピックを作成します。詳細については、「*Amazon Simple Notification Service デベロッパーガイド*」の「[Amazon SNS の開始方法](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic)」を参照してください。すべての CIS アラームを受信するトピックを作成し、そのトピックへのサブスクリプションを少なくとも 1 つ作成します。

1. すべての AWS リージョンに適用される CloudTrail 追跡を作成します。手順については、「*AWS CloudTrail ユーザーガイド*」の「[追跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)」を参照してください。

   CloudTrail 追跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。次の手順で、そのロググループに対してメトリクスフィルターを作成します。

1. メトリクスのフィルターを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

1. フィルターに基づいてアラームを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターに基づく CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.11] ネットワークアクセスコントロールリスト (NACL) への変更に対するログメトリクスフィルターとアラームが存在することを確認します
<a name="cloudwatch-11"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/3.11、CIS AWS Foundations Benchmark v1.4.0/4.11、NIST.800-171.r2 3.14.6、NIST.800-171.r2 3.14.7

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

**重大度:** 低

**リソースタイプ:** `AWS::Logs::MetricFilter`、`AWS::CloudWatch::Alarm`、`AWS::CloudTrail::Trail`、`AWS::SNS::Topic`

**AWS Config ルール:** なし (カスタム Security Hub CSPM ルール)

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

**パラメータ :** なし

CloudTrail ログを CloudWatch Logs に転送し、対応するメトリクスフィルターとアラームを設定することにより、API コールのリアルタイムモニタリングを実行できます。NACL は、VPC 内のサブネットの入力トラフィックと出力トラフィックを制御するためのステートレスパケットフィルターとして使用されます。

CIS では、NACL の変更に対するメトリクスフィルターとアラームを作成することを推奨しています。これらの変更をモニタリングすることで、 AWS リソースとサービスが意図せずに公開されないようにすることができます。

このチェックを実行するために、Security Hub CSPM はカスタムロジックを使用して、[CIS AWS Foundations Benchmark v1.4.0 のコントロール 4.11 ](https://acrobat.adobe.com/link/track?uri=urn:aaid:scds:US:2e5fec5c-5e99-4fb5-b08d-bb46b14754c1#pageNum=1)に規定された正確な監査ステップを実行します。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

**注記**  
Security Hub CSPM がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡を検索します。これらの追跡は、別のアカウントに属する組織の追跡である可能性があります。マルチリージョンの追跡は、別のリージョンに基づいている可能性もあります。  
チェックの結果、以下の場合は結果 `FAILED` となります。  
追跡が設定されていません。
現在のリージョンにあり、現在のアカウントが所有している利用可能な追跡が、コントロール要件を満たしていません。
チェックの結果、以下の場合はコントロール状況が `NO_DATA` になります。  
マルチリージョンの追跡が別のリージョンに基づいています。Security Hub CSPM は、証跡が基づいているリージョンでのみ結果を生成できます。
マルチリージョンの追跡が別のアカウントに属しています。Security Hub CSPM は、証跡を所有するアカウントの結果のみを生成できます。  
組織内の多数のアカウントからのイベントを記録するには、組織の証跡をお勧めします。組織の証跡はデフォルトではマルチリージョンの証跡であり、 AWS Organizations 管理アカウントまたは CloudTrail 委任管理者アカウントによってのみ管理できます。組織の証跡を使用すると、組織のメンバーアカウントで評価されたコントロールの管理ステータスは `NO_DATA` になります。メンバーアカウントでは、Security Hub CSPM はメンバー所有のリソースの結果のみを生成します。組織の証跡に関する検出結果は、リソース所有者のアカウントで生成されます。これらの検出結果は、クロスリージョン集約を使用して Security Hub CSPM 委任管理者アカウントで確認できます。
アラームの場合、現在のアカウントは、参照されている Amazon SNS トピックを所有しているか、`ListSubscriptionsByTopic` を呼び出すことで Amazon SNS トピックにアクセスできる必要があります。それ以外の場合、Security Hub CSPM はコントロールの検出`WARNING`結果を生成します。

### 修正
<a name="cloudwatch-11-remediation"></a>

このコントロールに合格するには、以下の手順に従って Amazon SNS トピック、 AWS CloudTrail 追跡、メトリクスフィルター、メトリクスフィルターのアラームを作成します。

1. Amazon SNS トピックを作成します。詳細については、「*Amazon Simple Notification Service デベロッパーガイド*」の「[Amazon SNS の開始方法](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic)」を参照してください。すべての CIS アラームを受信するトピックを作成し、そのトピックへのサブスクリプションを少なくとも 1 つ作成します。

1. すべての AWS リージョンに適用される CloudTrail 追跡を作成します。手順については、「*AWS CloudTrail ユーザーガイド*」の「[追跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)」を参照してください。

   CloudTrail 追跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。次の手順で、そのロググループに対してメトリクスフィルターを作成します。

1. メトリクスのフィルターを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

1. フィルターに基づいてアラームを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターに基づく CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.12] ネットワークゲートウェイへの変更に対するログメトリクスフィルターとアラームが存在することを確認します
<a name="cloudwatch-12"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/3.12、CIS AWS Foundations Benchmark v1.4.0/4.12、NIST.800-171.r2 3.3.1、NIST.800-171.r2 3.13.1

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

**重大度:** 低

**リソースタイプ:** `AWS::Logs::MetricFilter`、`AWS::CloudWatch::Alarm`、`AWS::CloudTrail::Trail`、`AWS::SNS::Topic`

**AWS Config ルール:** なし (カスタム Security Hub CSPM ルール)

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

**パラメータ :** なし

CloudTrail ログを CloudWatch Logs に転送し、対応するメトリクスフィルターとアラームを設定することにより、API コールのリアルタイムモニタリングを実行できます。ネットワークゲートウェイは、VPC の外部にある送信先との間でトラフィックを送受信する必要があります。

CIS では、ネットワークゲートウェイの変更に対するメトリクスフィルターとアラームを作成することを推奨しています。これらの変更をモニタリングすることにより、すべての入力トラフィックと出力トラフィックが制御されたパスを通じて VPC 境界を通過するようになります。

このチェックを実行するために、Security Hub CSPM はカスタムロジックを使用して、[CIS AWS Foundations Benchmark v1.2 のコントロール 4.12 ](https://acrobat.adobe.com/link/track?uri=urn:aaid:scds:US:2e5fec5c-5e99-4fb5-b08d-bb46b14754c1#pageNum=1)に規定された正確な監査ステップを実行します。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

**注記**  
Security Hub CSPM がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡を検索します。これらの追跡は、別のアカウントに属する組織の追跡である可能性があります。マルチリージョンの追跡は、別のリージョンに基づいている可能性もあります。  
チェックの結果、以下の場合は結果 `FAILED` となります。  
追跡が設定されていません。
現在のリージョンにあり、現在のアカウントが所有している利用可能な追跡が、コントロール要件を満たしていません。
チェックの結果、以下の場合はコントロール状況が `NO_DATA` になります。  
マルチリージョンの追跡が別のリージョンに基づいています。Security Hub CSPM は、証跡が基づいているリージョンでのみ結果を生成できます。
マルチリージョンの追跡が別のアカウントに属しています。Security Hub CSPM は、証跡を所有するアカウントの結果のみを生成できます。  
組織内の多数のアカウントからのイベントを記録するには、組織の証跡をお勧めします。組織の証跡はデフォルトではマルチリージョンの証跡であり、 AWS Organizations 管理アカウントまたは CloudTrail 委任管理者アカウントによってのみ管理できます。組織の証跡を使用すると、組織のメンバーアカウントで評価されたコントロールの管理ステータスは `NO_DATA` になります。メンバーアカウントでは、Security Hub CSPM はメンバー所有のリソースの結果のみを生成します。組織の証跡に関する検出結果は、リソース所有者のアカウントで生成されます。これらの検出結果は、クロスリージョン集約を使用して Security Hub CSPM 委任管理者アカウントで確認できます。
アラームの場合、現在のアカウントは、参照されている Amazon SNS トピックを所有しているか、`ListSubscriptionsByTopic` を呼び出すことで Amazon SNS トピックにアクセスできる必要があります。それ以外の場合、Security Hub CSPM はコントロールの検出`WARNING`結果を生成します。

### 修正
<a name="cloudwatch-12-remediation"></a>

このコントロールに合格するには、以下の手順に従って Amazon SNS トピック、 AWS CloudTrail 追跡、メトリクスフィルター、メトリクスフィルターのアラームを作成します。

1. Amazon SNS トピックを作成します。詳細については、「*Amazon Simple Notification Service デベロッパーガイド*」の「[Amazon SNS の開始方法](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic)」を参照してください。すべての CIS アラームを受信するトピックを作成し、そのトピックへのサブスクリプションを少なくとも 1 つ作成します。

1. すべての AWS リージョンに適用される CloudTrail 追跡を作成します。手順については、「*AWS CloudTrail ユーザーガイド*」の「[追跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)」を参照してください。

   CloudTrail 追跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。次の手順で、そのロググループに対してメトリクスフィルターを作成します。

1. メトリクスのフィルターを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

1. フィルターに基づいてアラームを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターに基づく CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.13] ルートテーブルの変更に対してログメトリクスフィルターとアラームが存在することを確認します
<a name="cloudwatch-13"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/3.13、CIS AWS Foundations Benchmark v1.4.0/4.13、NIST.800-171.r2 3.3.1、NIST.800-171.r2 3.13.1、NIST.800-171.r2 3.14.6、NIST.800-171.r2 3.14.7

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

**重大度:** 低

**リソースタイプ:** `AWS::Logs::MetricFilter`、`AWS::CloudWatch::Alarm`、`AWS::CloudTrail::Trail`、`AWS::SNS::Topic`

**AWS Config ルール:** なし (カスタム Security Hub CSPM ルール)

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

**パラメータ :** なし

このコントロールは、CloudTrail ログを CloudWatch Logs に転送し、対応するメトリクスフィルターとアラームを設定することにより、API コールのリアルタイムモニタリングを実行するかどうかを確認します。ルーティングテーブルは、サブネット間およびネットワークゲートウェイへのネットワークトラフィックをルーティングします。

CIS では、ルートテーブルの変更に対するメトリクスフィルターとアラームを作成することを推奨しています。これらの変更をモニタリングすることで、すべての VPC トラフィックが確実に想定どおりのパスを通過するようにできます。

**注記**  
Security Hub CSPM がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡を検索します。これらの追跡は、別のアカウントに属する組織の追跡である可能性があります。マルチリージョンの追跡は、別のリージョンに基づいている可能性もあります。  
チェックの結果、以下の場合は結果 `FAILED` となります。  
追跡が設定されていません。
現在のリージョンにあり、現在のアカウントが所有している利用可能な追跡が、コントロール要件を満たしていません。
チェックの結果、以下の場合はコントロール状況が `NO_DATA` になります。  
マルチリージョンの追跡が別のリージョンに基づいています。Security Hub CSPM は、証跡が基づいているリージョンでのみ結果を生成できます。
マルチリージョンの追跡が別のアカウントに属しています。Security Hub CSPM は、証跡を所有するアカウントの結果のみを生成できます。  
組織内の多数のアカウントからのイベントを記録するには、組織の証跡をお勧めします。組織の証跡はデフォルトではマルチリージョンの証跡であり、 AWS Organizations 管理アカウントまたは CloudTrail 委任管理者アカウントによってのみ管理できます。組織の証跡を使用すると、組織のメンバーアカウントで評価されたコントロールの管理ステータスは `NO_DATA` になります。メンバーアカウントでは、Security Hub CSPM はメンバー所有のリソースの結果のみを生成します。組織の証跡に関する検出結果は、リソース所有者のアカウントで生成されます。これらの検出結果は、クロスリージョン集約を使用して Security Hub CSPM 委任管理者アカウントで確認できます。
アラームの場合、現在のアカウントは、参照されている Amazon SNS トピックを所有しているか、`ListSubscriptionsByTopic` を呼び出すことで Amazon SNS トピックにアクセスできる必要があります。それ以外の場合、Security Hub CSPM はコントロールの検出`WARNING`結果を生成します。

### 修正
<a name="cloudwatch-13-remediation"></a>

**注記**  
これらの修復手順で推奨されるフィルターパターンは、CIS ガイダンスのフィルターパターンとは異なります。推奨フィルターは Amazon Elastic Compute Cloud (EC2) 呼び出しからのイベントのみを対象としています。

このコントロールに合格するには、以下の手順に従って Amazon SNS トピック、 AWS CloudTrail 追跡、メトリクスフィルター、メトリクスフィルターのアラームを作成します。

1. Amazon SNS トピックを作成します。詳細については、「*Amazon Simple Notification Service デベロッパーガイド*」の「[Amazon SNS の開始方法](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic)」を参照してください。すべての CIS アラームを受信するトピックを作成し、そのトピックへのサブスクリプションを少なくとも 1 つ作成します。

1. すべての AWS リージョンに適用される CloudTrail 追跡を作成します。手順については、「*AWS CloudTrail ユーザーガイド*」の「[追跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)」を参照してください。

   CloudTrail 追跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。次の手順で、そのロググループに対してメトリクスフィルターを作成します。

1. メトリクスのフィルターを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

1. フィルターに基づいてアラームを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターに基づく CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.14] VPC の変更に対してログメトリクスフィルターとアラームが存在することを確認します
<a name="cloudwatch-14"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/3.14、CIS AWS Foundations Benchmark v1.4.0/4.14、NIST.800-171.r2 3.3.1、NIST.800-171.r2 3.13.1、NIST.800-171.r2 3.14.6、NIST.800-171.r2 3.14.7

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

**重大度:** 低

**リソースタイプ:** `AWS::Logs::MetricFilter`、`AWS::CloudWatch::Alarm`、`AWS::CloudTrail::Trail`、`AWS::SNS::Topic`

**AWS Config ルール:** なし (カスタム Security Hub CSPM ルール)

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

**パラメータ :** なし

CloudTrail ログを CloudWatch Logs に転送し、対応するメトリクスフィルターとアラームを設定することにより、API コールのリアルタイムモニタリングを実行できます。1 つのアカウントに複数の VPC を含めることができるのに加えて、2 つの VPC 間にピア接続を作成し、ネットワークトラフィックを VPC 間でルーティングすることができます。

CIS では、VPC の変更に対するメトリクスフィルターとアラームを作成することを推奨しています。これらの変更をモニタリングすることで、認証と認可の管理が損なわれないようにできます。

このチェックを実行するために、Security Hub CSPM はカスタムロジックを使用して、[CIS AWS Foundations Benchmark v1.4.0 のコントロール 4.14 ](https://acrobat.adobe.com/link/track?uri=urn:aaid:scds:US:2e5fec5c-5e99-4fb5-b08d-bb46b14754c1#pageNum=1)に規定された正確な監査ステップを実行します。CIS によって規定された正確なメトリクスフィルターが使用されていない場合、このコントロールは失敗します。追加のフィールドまたは用語をメトリクスフィルターに追加することはできません。

**注記**  
Security Hub CSPM がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 証跡を検索します。これらの追跡は、別のアカウントに属する組織の追跡である可能性があります。マルチリージョンの追跡は、別のリージョンに基づいている可能性もあります。  
チェックの結果、以下の場合は結果 `FAILED` となります。  
追跡が設定されていません。
現在のリージョンにあり、現在のアカウントが所有している利用可能な追跡が、コントロール要件を満たしていません。
チェックの結果、以下の場合はコントロール状況が `NO_DATA` になります。  
マルチリージョンの追跡が別のリージョンに基づいています。Security Hub CSPM は、証跡が基づいているリージョンでのみ結果を生成できます。
マルチリージョンの追跡が別のアカウントに属しています。Security Hub CSPM は、証跡を所有するアカウントの結果のみを生成できます。  
組織内の多数のアカウントからのイベントを記録するには、組織の証跡をお勧めします。組織の証跡はデフォルトではマルチリージョンの証跡であり、 AWS Organizations 管理アカウントまたは CloudTrail 委任管理者アカウントによってのみ管理できます。組織の証跡を使用すると、組織のメンバーアカウントで評価されたコントロールの管理ステータスは `NO_DATA` になります。メンバーアカウントでは、Security Hub CSPM はメンバー所有のリソースの結果のみを生成します。組織の証跡に関する検出結果は、リソース所有者のアカウントで生成されます。これらの検出結果は、クロスリージョン集約を使用して Security Hub CSPM 委任管理者アカウントで確認できます。
アラームの場合、現在のアカウントは、参照されている Amazon SNS トピックを所有しているか、`ListSubscriptionsByTopic` を呼び出すことで Amazon SNS トピックにアクセスできる必要があります。それ以外の場合、Security Hub CSPM はコントロールの検出`WARNING`結果を生成します。

### 修正
<a name="cloudwatch-14-remediation"></a>

このコントロールに合格するには、以下の手順に従って Amazon SNS トピック、 AWS CloudTrail 追跡、メトリクスフィルター、メトリクスフィルターのアラームを作成します。

1. Amazon SNS トピックを作成します。詳細については、「*Amazon Simple Notification Service デベロッパーガイド*」の「[Amazon SNS の開始方法](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic)」を参照してください。すべての CIS アラームを受信するトピックを作成し、そのトピックへのサブスクリプションを少なくとも 1 つ作成します。

1. すべての AWS リージョンに適用される CloudTrail 追跡を作成します。手順については、「*AWS CloudTrail ユーザーガイド*」の「[追跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)」を参照してください。

   CloudTrail 追跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。次の手順で、そのロググループに対してメトリクスフィルターを作成します。

1. メトリクスのフィルターを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

1. フィルターに基づいてアラームを作成します。手順については、「*Amazon CloudWatch ユーザーガイド*」の「[ロググループのメトリクスフィルターに基づく CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html)」を参照してください。以下の値を使用します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.15] CloudWatch アラームには、指定されたアクションが設定されている必要があります
<a name="cloudwatch-15"></a>

**関連する要件:** NIST.800-53.r5 AU-6(1)、NIST.800-53.r5 AU-6(5)、NIST.800-53.r5 CA-7、NIST.800-53.r5 IR-4(1)、NIST.800-53.r5 IR-4(5)、NIST.800-53.r5 SI-2、NIST.800-53.r5 SI-20、NIST.800-53.r5 SI-4(12)、NIST.800-53.r5 SI-4(5)、NIST.800-171.r2 3.3.4、NIST.800-171.r2 3.14.6

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

**重要度:** 高

**リソースタイプ :** `AWS::CloudWatch::Alarm`

**AWS Config ルール:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudwatch-alarm-action-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudwatch-alarm-action-check.html) ``

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `alarmActionRequired`  |  パラメータが `true` に設定されていて、アラームの状態が `ALARM` に変わるとアラームがアクションを起こす場合に、コントロールが `PASSED` 検出結果を生成します。  |  ブール値  |  カスタマイズ不可  |  `true`  | 
|  `insufficientDataActionRequired`  |  パラメータが `true` に設定されていて、アラームの状態が `INSUFFICIENT_DATA` に変わるとアラームがアクションを起こす場合に、コントロールが `PASSED` 検出結果を生成します。  |  ブール値  |  `true` または `false`  |  `false`  | 
|  `okActionRequired`  |  パラメータが `true` に設定されていて、アラームの状態が `OK` に変わるとアラームがアクションを起こす場合に、コントロールが `PASSED` 検出結果を生成します。  |  ブール値  |  `true` 、、または `false`  |  `false`  | 

このコントロールは、Amazon CloudWatch アラームに `ALARM` 状態に応じて設定されたアクションが 1 つ以上あるかどうかを確認します。`ALARM` 状態に対して設定されたアクションがアラームにない場合、コントロールは失敗します。必要に応じて、カスタムパラメータ値を含めて、`INSUFFICIENT_DATA` 状態または `OK` 状態のアラームアクションを要求することもできます。

**注記**  
Security Hub CSPM は、CloudWatch メトリクスアラームに基づいてこのコントロールを評価します。メトリクスアラームは、指定されたアクションが設定された複合アラームの一部である場合があります。コントロールは、次の場合に `FAILED` 検出結果を生成します。  
指定されたアクションは、メトリクスアラーム用に設定されていません。
メトリクスアラームは、指定されたアクションが設定された複合アラームの一部です。

このコントロールは CloudWatch アラームでアラームアクションが設定されているかどうかに重点を置いていますが、[CloudWatch.17](#cloudwatch-17) は CloudWatch アラームアクションのアクティベーションステータスに重点を置いています。

モニタリング対象のメトリクスが定義されたしきい値を超えると自動的に警告する CloudWatch アラームアクションを使用することをお勧めします。アラームをモニタリングすることで、異常なアクティビティを特定し、アラームが特定の状態になったときのセキュリティや運用上の問題に迅速に対応できます。アラームアクションの最も一般的なタイプは、Amazon Simple Notification Service (Amazon SNS) トピックにメッセージを送信して、1 人または複数のユーザーに通知することです。

### 修正
<a name="cloudwatch-15-remediation"></a>

CloudWatch アラームでサポートされているアクションの詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[アラームアクション](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions)」を参照してください。

## [CloudWatch.16] CloudWatch ロググループは指定した期間保持する必要があります
<a name="cloudwatch-16"></a>

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

**関連する要件:** NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-11、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SI-12

**重要度:** 中

**リソースタイプ :** `AWS::Logs::LogGroup`

**AWS Config ルール:** [https://docs.aws.amazon.com/config/latest/developerguide/cw-loggroup-retention-period-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cw-loggroup-retention-period-check.html) ``

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `minRetentionTime`  |  CloudWatch ロググループの最小保持期間 (日数)  |  列挙型  |  `365, 400, 545, 731, 1827, 3653`  |  `365`  | 

このコントロールは、Amazon CloudWatch ロググループの保持期間が少なくとも指定された日数以上あるかどうかをチェックします。保持期間が指定された日数未満の場合、コントロールは失敗します。保持期間にカスタムパラメータ値を指定しない限り、Security Hub CSPM はデフォルト値の 365 日を使用します。

CloudWatch Logs は、すべてのシステム、アプリケーション、および からのログを 1 つの高度にスケーラブルなサービス AWS のサービス に一元化します。CloudWatch Logs を使用して、Amazon Elastic Compute Cloud (EC2) インスタンス、Amazon Route 53、およびその他のソースからログファイルをモニタリング AWS CloudTrail、保存、およびアクセスできます。ログを少なくとも 1 年間保存することで、ログ保持標準への準拠に役立ちます。

### 修正
<a name="cloudwatch-16-remediation"></a>

ログ保持の設定については、「*Amazon CloudWatch ユーザーガイド*」の「[Change log data retention in CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention)」を参照してください。

## [CloudWatch.17] CloudWatch アラームアクションをアクティブにする必要があります
<a name="cloudwatch-17"></a>

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

**関連する要件:** NIST.800-53.r5 AU-6(1)、NIST.800-53.r5 AU-6(5)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SI-2、NIST.800-53.r5 SI-4(12)

**重要度:** 高

**リソースタイプ :** `AWS::CloudWatch::Alarm`

**AWS Config ルール:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudwatch-alarm-action-enabled-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudwatch-alarm-action-enabled-check.html) ``

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

**パラメータ :** なし

このコントロールは、CloudWatch アラームアクションがアクティブになっているかどうかをチェックします (`ActionEnabled` を true に設定する必要があります)。CloudWatch アラームのアラームアクションが非アクティブ化されていると、コントロールは失敗します。

**注記**  
Security Hub CSPM は、CloudWatch メトリクスアラームに基づいてこのコントロールを評価します。メトリクスアラームは、アラームアクションがアクティブ化された複合アラームの一部である場合があります。コントロールは、次の場合に `FAILED` 検出結果を生成します。  
指定されたアクションは、メトリクスアラーム用に設定されていません。
メトリクスアラームは、アラームアクションがアクティブ化された複合アラームの一部です。

このコントロールは CloudWatch アラームアクションのアクティベーションステータスに重点を置いていますが、[CloudWatch.15](#cloudwatch-15) は CloudWatch アラームで `ALARM` アクションが設定されているかどうかに重点を置いています。

アラームアクションは、モニタリング対象のメトリクスが定義されたしきい値を超えると自動的に警告します。アラームアクションが非アクティブ化されている場合、アラームの状態が変わってもアクションは実行されず、モニタリング対象メトリクスの変更に関する警告は表示されません。セキュリティや運用上の問題に迅速に対応できるように、CloudWatch アラームアクションをアクティブにすることをお勧めします。

### 修正
<a name="cloudwatch-17-remediation"></a>

**CloudWatch アラームアクションを有効にアクティブにするには (コンソール)**

1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。

1. ナビゲーションペインの **[アラーム]** で、**[すべてのアラーム]** を選択します。

1. アクションをアクティブにするアラームを選択します。

1. **[アクション]** で、**[アラームアクション — 新規]** を選択し、**[有効化]** を選択します。

CloudWatch アラームアクションのアクティブ化の詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[アラームアクション](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions)」を参照してください。

# CodeArtifact の Security Hub CSPM コントロール
<a name="codeartifact-controls"></a>

これらの Security Hub CSPM コントロールは、 AWS CodeArtifact サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [CodeArtifact.1] CodeArtifact リポジトリにはタグを付ける必要があります
<a name="codeartifact-1"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::CodeArtifact::Repository`

**AWS Config rule:** `tagged-codeartifact-repository` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、 AWS CodeArtifact リポジトリにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。リポジトリにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、リポジトリにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="codeartifact-1-remediation"></a>

CodeArtifact リポジトリにタグを追加するには、「*AWS CodeArtifact ユーザーガイド*」の「[CodeArtifact のリポジトリにタグを付ける](https://docs.aws.amazon.com/codeartifact/latest/ug/tag-repositories.html)」を参照してください。

# CodeBuild の Security Hub CSPM コントロール
<a name="codebuild-controls"></a>

これらの Security Hub CSPM コントロールは、 AWS CodeBuild サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [CodeBuild.1] CodeBuild Bitbucket ソースリポジトリの URL には機密認証情報を含めないでください
<a name="codebuild-1"></a>

**関連する要件:** NIST.800-53.r5 SA-3、PCI DSS v3.2.1/8.2.1、PCI DSS v4.0.1/8.3.2

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

**重要度:** 非常事態

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/codebuild-project-source-repo-url-check.html](https://docs.aws.amazon.com/config/latest/developerguide/codebuild-project-source-repo-url-check.html)

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

**パラメータ :** なし

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

**注記**  
このコントロールは、CodeBuild ビルドプロジェクトのプライマリソースとセカンダリソースの両方を評価します。プロジェクトソースの詳細については、「*AWS CodeBuild ユーザーガイド*」の「[複数の入力ソースと出力アーティファクトのサンプル](https://docs.aws.amazon.com/codebuild/latest/userguide/sample-multi-in-out.html)」を参照してください。

サインイン認証情報は、クリアテキストで保存または送信したり、ソースリポジトリ URL に表示しないでください。個人用アクセストークンやサインイン認証情報の代わりに、CodeBuild のソースプロバイダーにアクセスし、Bitbucket リポジトリの場所へのパスのみを含むようにソースリポジトリ URL を変更する必要があります。個人用アクセストークンまたはサインイン認証情報を使用すると、意図しないデータ漏えいや不正アクセスに認証情報が公開される可能性があります。

### 修正
<a name="codebuild-1-remediation"></a>

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

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

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

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

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

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

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

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

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

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

詳細については、「AWS CodeBuild ユーザーガイド」の「[CodeBuild ユースケースベースのサンプル](https://docs.aws.amazon.com/codebuild/latest/userguide/use-case-based-samples.html)」を参照してください。

## [CodeBuild.2] CodeBuild プロジェクト環境変数にクリアテキストの認証情報を含めることはできません
<a name="codebuild-2"></a>

**関連する要件:** NIST.800-53.r5 IA-5(7)、NIST.800-53.r5 SA-3、PCI DSS v3.2.1/8.2.1、PCI DSS v4.0.1/8.3.2

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

**重要度:** 非常事態

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/codebuild-project-envvar-awscred-check.html](https://docs.aws.amazon.com/config/latest/developerguide/codebuild-project-envvar-awscred-check.html)

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

**パラメータ:** なし

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

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

### 修正
<a name="codebuild-2-remediation"></a>

CodeBuild プロジェクトから環境変数を削除するには、「*AWS CodeBuild ユーザーガイド*」の「[AWS CodeBuildでのビルドプロジェクトの設定の変更](https://docs.aws.amazon.com/codebuild/latest/userguide/change-project.html)」を参照してください。**[環境変数]** に何も選択されていないことを確認します。

機密値を持つ環境変数を Parameter Store AWS Systems Manager または に保存し AWS Secrets Manager 、ビルド仕様から取得できます。手順については、「*AWS CodeBuild ユーザーガイド*」の「[Environment section](https://docs.aws.amazon.com/codebuild/latest/userguide/change-project-console.html#change-project-console-environment)」セクションで、「**重要**」ラベルの付いたボックスを参照してください。

## [CodeBuild.3] CodeBuild S3 ログは暗号化する必要があります
<a name="codebuild-3"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SI-7(6)、PCI DSS v4.0.1/10.3.2

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

**重要度:** 低

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/codebuild-project-s3-logs-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/codebuild-project-s3-logs-encrypted.html)

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

**パラメータ :** なし

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

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

### 修正
<a name="codebuild-3-remediation"></a>

CodeBuild プロジェクトの S3 ログの暗号化設定を変更するには、「*AWS CodeBuild ユーザーガイド*」の「[Change a build project's settings in AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/change-project.html)」を参照してください。

## [CodeBuild.4] CodeBuild AWS Configプロジェクト環境にはログ記録設定が必要です
<a name="codebuild-4"></a>

**関連する要件:** NIST.800-53.r5 AC-2(12)、NIST.800-53.r5 AC-2(4)、NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AC-6(9)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 AU-9(7)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4、NIST.800-53.r5 SI-4(20)、NIST.800-53.r5 SI-7(8)

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/codebuild-project-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/codebuild-project-logging-enabled.html)

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

**パラメータ:** なし

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

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

### 修正
<a name="codebuild-4-remediation"></a>

CodeBuild プロジェクトログの設定方法の詳細については、「CodeBuild ユーザーガイド」の「[ビルドプロジェクトの作成 (コンソール)](https://docs.aws.amazon.com/codebuild/latest/userguide/create-project-console.html#create-project-console-logs)」を参照してください。

## [CodeBuild.5] CodeBuild プロジェクト環境では特権モードを有効にしないでください
<a name="codebuild-5"></a>

**重要**  
Security Hub CSPM は、2024 年 4 月にこのコントロールを廃止しました。詳細については、「[Security Hub CSPM コントロールの変更ログ](controls-change-log.md)」を参照してください。

**関連する要件:** NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-5、NIST.800-53.r5 AC-6、NIST.800-53.r5 AC-6(10)、NIST.800-53.r5 AC-6(2)

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/codebuild-project-environment-privileged-check.html](https://docs.aws.amazon.com/config/latest/developerguide/codebuild-project-environment-privileged-check.html)

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

**パラメータ :** なし

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

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

### 修正
<a name="codebuild-5-remediation"></a>

CodeBuild プロジェクト環境設定を設定するには、「*CodeBuild ユーザーガイド*」の「[Create a build project (console)](https://docs.aws.amazon.com/codebuild/latest/userguide/create-project-console.html#create-project-console-environment)」を参照してください。**[環境]** セクションでは、**[特権付与]** 設定を選択しないでください。

## [CodeBuild.7] CodeBuild レポートグループのエクスポートは保管時に暗号化する必要があります
<a name="codebuild-7"></a>

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

**重要度:** 中

**リソースタイプ :** `AWS::CodeBuild::ReportGroup`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/codebuild-report-group-encrypted-at-rest.html](https://docs.aws.amazon.com/config/latest/developerguide/codebuild-report-group-encrypted-at-rest.html)

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

**パラメータ :** なし

このコントロールは、Amazon Simple Storage Service (Amazon S3) バケットにエクスポートされた AWS CodeBuild レポートグループのテスト結果が保管時に暗号化されているかどうかを確認します。レポートグループのエクスポートが保管時に暗号化されていない場合、コントロールは失敗します。

保管中のデータとは、永続的な不揮発性ストレージに任意の期間保管されているデータを指します。保管中のデータを暗号化すると、その機密性が保護され、権限のないユーザーがアクセスするリスクが低減されます。

### 修正
<a name="codebuild-7-remediation"></a>

S3 へのレポートグループのエクスポートを暗号化するには、 「*AWS CodeBuild ユーザーガイド*」の「[レポートグループの更新](https://docs.aws.amazon.com/codebuild/latest/userguide/report-group-export-settings.html)」を参照してください。

# Amazon CodeGuru Profiler の Security Hub CSPM コントロール
<a name="codeguruprofiler-controls"></a>

これらの Security Hub CSPM コントロールは、Amazon CodeGuru Profiler サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [CodeGuruProfiler.1] CodeGuru Profiler プロファイリンググループにはタグを付ける必要があります
<a name="codeguruprofiler-1"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::CodeGuruProfiler::ProfilingGroup`

**AWS Config ルール :** `codeguruprofiler-profiling-group-tagged`

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon CodeGuru Profiler プロファイリンググループに、パラメータ `requiredKeyTags` で定義された特定のキーを持つタグがあるかどうかをチェックします。プロファイリンググループにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、プロファイリンググループがキーでタグ付けされていない場合に失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="codeguruprofiler-1-remediation"></a>

CodeGuru Profiler プロファイリンググループにタグを追加するには、「[Amazon CodeGuru Profiler ユーザーガイド](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/tagging-profiling-groups.html)」の「*Tagging profiling groups*」を参照してください。

# Amazon CodeGuru Reviewer の Security Hub CSPM コントロール
<a name="codegurureviewer-controls"></a>

これらの Security Hub CSPM コントロールは、Amazon CodeGuru Reviewer サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [CodeGuruReviewer.1] CodeGuru Reviewer リポジトリの関連付けにはタグを付ける必要があります
<a name="codegurureviewer-1"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::CodeGuruReviewer::RepositoryAssociation`

**AWS Config ルール :** `codegurureviewer-repository-association-tagged`

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon CodeGuru Reviewer リポジトリの関連付けにパラメータ `requiredKeyTags` で定義された特定のキーを持つタグがあるかどうかをチェックします。リポジトリの関連付けにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、リポジトリの関連付けにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="codegurureviewer-1-remediation"></a>

CodeGuru Reviewer リポジトリの関連付けにタグを追加するには、「*Amazon CodeGuru Reviewer ユーザーガイド*」の「[Tagging a repository association](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/tag-repository-association.html)」を参照してください。

# Amazon Cognito の Security Hub CSPM コントロール
<a name="cognito-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon Cognito サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [Cognito.1] Cognito ユーザープールでは、標準認証のフル機能強制モードで脅威保護を有効にする必要があります
<a name="cognito-1"></a>

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

**重要度:** 中

**リソースタイプ :** `AWS::Cognito::UserPool`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cognito-user-pool-advanced-security-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cognito-user-pool-advanced-security-enabled.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `SecurityMode`  |  コントロールがチェックする脅威保護の強制適用モード。  |  String  |  `AUDIT`, `ENFORCED`  |  `ENFORCED`  | 

このコントロールは、Amazon Cognito ユーザープールで、標準認証のフル機能に強制モードが設定された状態で脅威保護が有効になっているかどうかをチェックします。ユーザープールで脅威保護が無効になっている場合、または標準認証のフル機能に強制モードが設定されていない場合、コントロールは失敗します。カスタムパラメータ値を指定しない限り、Security Hub CSPM は、標準認証`ENFORCED`の完全な 関数に設定されたエンフォースメントモードに のデフォルト値を使用します。

Amazon Cognito ユーザープールを作成したら、脅威保護をアクティブ化し、さまざまなリスクに応じて実行されるアクションをカスタマイズできます。また、監査モードを使用して、セキュリティ緩和策を適用せずに、検出されたリスクに関するメトリクスを収集できます。監査モードでは、脅威保護は Amazon CloudWatch にメトリクスを発行します。Amazon Cognito が最初のイベントを生成した後にメトリクスを確認できます。

### 修正
<a name="cognito-1-remediation"></a>

Amazon Cognito ユーザープールの脅威保護のアクティブ化については、「*Amazon Cognito デベロッパーガイド*」の「[Advanced security with threat protection](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-threat-protection.html)」を参照してください。

## [Cognito.2] Cognito アイデンティティプールでは、認証されていない ID を許可しないこと
<a name="cognito-2"></a>

**カテゴリ:** 保護 > セキュアなアクセス管理 > パスワードレス認証

**重要度:** 中

**リソースタイプ :** `AWS::Cognito::IdentityPool`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cognito-identity-pool-unauth-access-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cognito-identity-pool-unauth-access-check.html)

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

**パラメータ :** なし

このコントロールは、Amazon Cognito アイデンティティプールが認証されていない ID を許可するように設定されているかどうかをチェックします。ゲストアクセスがアクティブ化されている場合 (`AllowUnauthenticatedIdentities`パラメータが `true` に設定されている場合)、アイデンティティプールに対してコントロールは失敗します。

Amazon Cognito ID プールで認証されていない ID が許可されている場合、ID プールは ID プロバイダー (ゲスト) を介して認証されていないユーザーに一時的な AWS 認証情報を提供します。これにより、 AWS リソースへの匿名アクセスが許可されるため、セキュリティリスクが発生します。ゲストアクセスを非アクティブ化すると、適切に認証されたユーザーのみが AWS リソースにアクセスできるため、不正アクセスや潜在的なセキュリティ違反のリスクが軽減されます。ベストプラクティスとして、アイデンティティプールは、サポートされている ID プロバイダーによる認証を必要とするよう設定してください。認証されていないアクセスが必要な場合は、認証されていない ID のアクセス許可を慎重に制限し、その使用状況を定期的にレビューおよびモニタリングすることが重要です。

### 修正
<a name="cognito-2-remediation"></a>

Amazon Cognito アイデンティティプールのゲストアクセスを無効にする方法については、「*Amazon Cognito デベロッパーガイド*」の「[Activate or deactivate guest access](https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html#enable-or-disable-unauthenticated-identities)」を参照してください。

## [Cognito.3] Cognito ユーザープールのパスワードポリシーには強力な設定が必要です
<a name="cognito-3"></a>

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

**重要度:** 中

**リソースタイプ :** `AWS::Cognito::UserPool`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cognito-user-pool-password-policy-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cognito-user-pool-password-policy-check.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `minLength`  | パスワードの最小必要文字数。 | 整数 | `8`～`128` | `8 ` | 
|  `requireLowercase`  | パスワードには少なくとも 1 つの小文字が必要です。 | ブール値 | `True`, `False` | `True`  | 
|  `requireUppercase`  | パスワードには少なくとも 1 つの大文字が必要です。 | ブール値 | `True`, `False` | `True`  | 
|  `requireNumbers`  | パスワードには少なくとも 1 つの数字が必要です。 | ブール値 | `True`, `False` | `True`  | 
|  `requireSymbols`  | パスワードには少なくとも 1 つの記号が必要です。 | ブール値 | `True`, `False` | `True`  | 
|  `temporaryPasswordValidity`  | パスワードの有効期限が切れるまでの最大使用可能日数。 | 整数 | `7`～`365` | `7`  | 

このコントロールは、Amazon Cognito ユーザープールのパスワードポリシーが、パスワードポリシーの推奨設定に基づく強力なパスワードの使用を義務付けているかどうかを確認します。ユーザープールのパスワードポリシーが強力なパスワードの使用を義務付けていない場合、コントロールは失敗します。オプションで、コントロールがチェックするポリシー設定のカスタム値を指定できます。

強力なパスワードの使用は、Amazon Cognito ユーザープールのセキュリティのためのベストプラクティスです。パスワードが弱いと、パスワードを推測してデータにアクセスしようとするシステムにユーザーの認証情報が漏洩する可能性があります。これは特に、インターネットに公開されているアプリケーションの場合に当てはまります。パスワードポリシーは、ユーザーディレクトリのセキュリティの中心的な要素です。パスワードポリシーを使用することで、自組織のセキュリティ標準や要件に応じたパスワードの複雑度やその他の設定を義務付けするようにユーザープールを構成できます。

### 修正
<a name="cognito-3-remediation"></a>

Amazon Cognito ユーザープールのパスワードポリシーの作成または更新の詳細については、「*Amazon Cognito デベロッパーガイド*」の「[Adding user pool password requirements](https://docs.aws.amazon.com/cognito/latest/developerguide/managing-users-passwords.html#user-pool-settings-policies)」を参照してください。

## [Cognito.4] Cognito ユーザープールでは、カスタム認証の完全な関数強制モードで脅威保護を有効にする必要があります
<a name="cognito-4"></a>

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

**重要度:** 中

**リソースタイプ :** `AWS::Cognito::UserPool`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cognito-userpool-cust-auth-threat-full-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cognito-userpool-cust-auth-threat-full-check.html)

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

**パラメータ :** なし

このコントロールは、Amazon Cognito ユーザープールで脅威保護が有効になっているかどうかをチェックし、エンフォースメントモードをカスタム認証の完全な 関数に設定します。ユーザープールで脅威保護が無効になっている場合、またはカスタム認証の強制モードがフル関数に設定されていない場合、コントロールは失敗します。

脅威保護 (以前は高度なセキュリティ機能と呼ばれていました) は、ユーザープール内の望ましくないアクティビティをモニタリングするツールと、潜在的に悪意のあるアクティビティを自動的にシャットダウンする設定ツールのセットです。Amazon Cognito ユーザープールを作成したら、カスタム認証用のフル関数強制モードで脅威保護をアクティブ化し、さまざまなリスクに応じて実行されるアクションをカスタマイズできます。フル機能モードには、不要なアクティビティや侵害されたパスワードを検出するための一連の自動リアクションが含まれています。

### 修正
<a name="cognito-4-remediation"></a>

Amazon Cognito ユーザープールの脅威保護のアクティブ化については、「*Amazon Cognito デベロッパーガイド*」の「[Advanced security with threat protection](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-threat-protection.html)」を参照してください。

## [Cognito.5] Cognito ユーザープールに対して MFA を有効にする必要があります
<a name="cognito-5"></a>

**カテゴリ:** 保護 > 安全なアクセス管理 > 多要素認証

**重要度:** 中

**リソースタイプ :** `AWS::Cognito::UserPool`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cognito-user-pool-mfa-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cognito-user-pool-mfa-enabled.html)

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

**パラメータ :** なし

このコントロールは、パスワードのみのサインインポリシーで設定された Amazon Cognito ユーザープールで多要素認証 (MFA) が有効になっているかどうかを確認します。パスワードのみのサインインポリシーで設定されたユーザープールで MFA が有効になっていない場合、コントロールは失敗します。

多要素認証 (MFA) は、既知の要素 (通常はユーザー名とパスワード) に認証要素を持つものを追加します。フェデレーティッドユーザーの場合、Amazon Cognito は認証を ID プロバイダー (IdP) に委任し、追加の認証要素を提供しません。ただし、パスワード認証を使用するローカルユーザーがいる場合、ユーザープールに MFA を設定するとセキュリティが向上します。

**注記**  
このコントロールは、フェデレーティッドユーザーおよびパスワードレス要素でサインインするユーザーには適用されません。

### 修正
<a name="cognito-5-remediation"></a>

Amazon Cognito ユーザープールの MFA を設定する方法については、*Amazon Cognito デベロッパーガイド*」の[「ユーザープールへの MFA の追加](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-mfa.html)」を参照してください。

## [Cognito.6] Cognito ユーザープールでは削除保護を有効にする必要があります
<a name="cognito-6"></a>

**カテゴリ:** 保護 > データ保護 > データ削除保護

**重要度:** 中

**リソースタイプ :** `AWS::Cognito::UserPool`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cognito-user-pool-deletion-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cognito-user-pool-deletion-protection-enabled.html)

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

**パラメータ :** なし

このコントロールは、Amazon Cognito ユーザープールで削除保護が有効になっているかどうかを確認します。ユーザープールの削除保護が無効になっている場合、コントロールは失敗します。

削除保護は、ユーザープールが誤って削除されないようにするのに役立ちます。削除保護を使用してユーザープールを設定すると、どのユーザーもプールを削除することはできません。削除保護では、最初にプールを変更して削除保護を非アクティブ化しない限り、ユーザープールの削除をリクエストすることはできません。

### 修正
<a name="cognito-6-remediation"></a>

Amazon Cognito ユーザープールの削除保護を設定するには、*Amazon Cognito デベロッパーガイド*」の[「ユーザープールの削除保護](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-deletion-protection.html)」を参照してください。

# の Security Hub CSPM コントロール AWS Config
<a name="config-controls"></a>

これらの Security Hub CSPM コントロールは、 AWS Config サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [Config.1] を有効にし、サービスにリンクされたロールをリソース記録に使用 AWS Config する必要があります
<a name="config-1"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/3.3、CIS AWS Foundations Benchmark v1.2.0/2.5、CIS AWS Foundations Benchmark v1.4.0/3.5、CIS AWS Foundations Benchmark v3.0.0/3.3、NIST.800-53.r5 CM-3、NIST.800-53.r5 CM-6(1)、NIST.800-53.r5 CM-8、NIST.800-53.r5 CM-8(2)、PCI DSS v3.2.1/10.5.2、PCI DSS v3.2.1/1.5

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

**重要度:** 非常事態

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

**AWS Config ルール:** なし (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `includeConfigServiceLinkedRoleCheck`  |  パラメータが に設定されている場合、コントロールは がサービスにリンクされたロール AWS Config を使用するかどうかを評価しません`false`。  |  ブール値  |  `true` 、、または `false`  |  `true`  | 

このコントロール AWS Config は、現在の のアカウントで が有効になっているかどうかをチェックし AWS リージョン、現在のリージョンで有効になっているコントロールに対応するすべてのリソースを記録し、[サービスにリンクされた AWS Config ロール](https://docs.aws.amazon.com/config/latest/developerguide/using-service-linked-roles.html)を使用します。サービスにリンクされたロールの名前は、**AWSServiceRoleForConfig** です。サービスにリンクされたロールを使用せず、 `includeConfigServiceLinkedRoleCheck`パラメータを に設定しない場合`false`、他のロールには AWS Config がリソースを正確に記録するために必要なアクセス許可がないため、コントロールは失敗します。

この AWS Config サービスは、アカウントでサポートされている AWS リソースの設定管理を実行し、ログファイルをユーザーに配信します。記録された情報には、設定項目 (AWS リソース）、設定項目間の関係、リソース内の設定変更が含まれます。グローバルリソースは、どのリージョンでも利用できるリソースです。

コントロールは次のように評価されます。
+ 現在のリージョンが[集約リージョン](finding-aggregation.md)として設定されている場合、コントロールは AWS Identity and Access Management (IAM) グローバルリソースが記録されている (それらを必要とするコントロールを有効にしている場合) 場合にのみ`PASSED`結果を生成します。
+ 現在のリージョンがリンクされたリージョンとして設定されている場合、コントロールは IAM グローバルリソースが記録されているかどうかを評価しません。
+ 現在のリージョンがアグリゲータにない場合、またはクロスリージョン集約がアカウントで設定されていない場合、コントロールは IAM グローバルリソースが記録されている (それらを必要とするコントロールを有効にしている場合) 場合にのみ `PASSED` 検出結果を生成します。

コントロールの結果は、 AWS Configでリソースの状態の変化を毎日記録するか、継続的に記録するかにかかわらず、影響を受けません。ただし、新しいコントロールの自動有効化を設定している場合、または新しいコントロールを自動的に有効にする中央設定ポリシーがある場合、新しいコントロールがリリースされると、このコントロールの結果が変わる可能性があります。このような場合、すべてのリソースを記録しない場合は、`PASSED` 検出結果を受け取るために新しいコントロールに関連付けられているリソースの記録を設定する必要があります。

Security Hub CSPM セキュリティチェックは、すべてのリージョン AWS Config で を有効にし、それを必要とするコントロールのリソース記録を設定する場合にのみ、意図したとおりに機能します。

**注記**  
Config.1 では AWS Config 、Security Hub CSPM を使用するすべてのリージョンで が有効になっている必要があります。  
Security Hub CSPM はリージョン別サービスであるため、このコントロールに対して実行されるチェックでは、アカウントの現在のリージョンのみが評価されます。  
グローバルリソースに対するセキュリティチェックをリージョンで許可するには、そのリージョン内の IAM グローバルリソースを記録する必要があります。IAM グローバルリソースが記録されていないリージョンには、IAM グローバルリソースをチェックするコントロールのデフォルトの `PASSED` 検出結果が送信されます。IAM グローバルリソースは 間で同じであるため AWS リージョン、IAM グローバルリソースはホームリージョンのみに記録することをお勧めします (クロスリージョン集約がアカウントで有効になっている場合）。IAM リソースはグローバルリソース記録が有効になっているリージョンでのみ記録されます。  
 AWS Config がサポートする IAM グローバルに記録されたリソースタイプは、IAM ユーザー、グループ、ロール、カスタマー管理ポリシーです。グローバルリソース記録がオフになっているリージョンで、これらのリソースタイプをチェックする Security Hub CSPM コントロールを無効にすることを検討できます。詳細については、「[Security Hub CSPM で無効化を推奨するコントロール](controls-to-disable.md)」を参照してください。

### 修正
<a name="config-1-remediation"></a>

ホームリージョンとアグリゲータの一部ではないリージョンでは、IAM グローバルリソースを必要とするコントロールを有効にしている場合は、IAM グローバルリソースを含め、現在のリージョンで有効になっているコントロールに必要なすべてのリソースを記録します。

リンクされたリージョンでは、現在のリージョンで有効になっているコントロールに対応するすべてのリソースを記録する限り、任意の記録 AWS Config モードを使用できます。リンクされたリージョンで、IAM グローバルリソースの記録を必要とするコントロールを有効にしている場合、`FAILED` 検出結果を受け取ることはできません (他のリソースの記録で十分です)。

検出結果の `Compliance` オブジェクトの `StatusReasons` フィールドは、このコントロールの検出結果に失敗した理由を特定するのに役立ちます。詳細については、「[コントロールの検出結果のコンプライアンスの詳細](controls-findings-create-update.md#control-findings-asff-compliance)」を参照してください。

コントロールごとに記録する必要があるリソースのリストについては、「[コントロールの検出結果に必要な AWS Config リソース](controls-config-resources.md)」を参照してください。リソース記録の有効化 AWS Config と設定に関する一般的な情報については、「」を参照してください[Security Hub CSPM AWS Config の有効化と設定](securityhub-setup-prereqs.md)。

# Amazon Connect の Security Hub CSPM コントロール
<a name="connect-controls"></a>

これらの Security Hub CSPM コントロールは、Amazon Connect サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [Connect.1] Amazon Connect Customer Profiles オブジェクトタイプにはタグを付ける必要があります
<a name="connect-1"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::CustomerProfiles::ObjectType`

**AWS Config ルール :** `customerprofiles-object-type-tagged`

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon Connect Customer Profiles オブジェクトタイプに、パラメータ `requiredKeyTags` で定義された特定のキーを持つタグがあるかどうかをチェックします。オブジェクトタイプにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、オブジェクトタイプにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="connect-1-remediation"></a>

Customer Profiles オブジェクトタイプにタグを追加するには、「[Amazon Connect 管理者ガイド](https://docs.aws.amazon.com/connect/latest/adminguide/tagging.html)」の「*Add tags to resources in Amazon Connect*」を参照してください。

## [Connect.2] Amazon Connect インスタンスでは CloudWatch ログ記録が有効になっている必要があります
<a name="connect-2"></a>

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

**重要度:** 中

**リソースタイプ :** `AWS::Connect::Instance`

**AWS Config ルール:** [connect-instance-logging-enabled](https://docs.aws.amazon.com/config/latest/developerguide/connect-instance-logging-enabled.html)

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

**パラメータ :** なし

このコントロールは、Amazon Connect インスタンスが、Amazon CloudWatch ロググループにフローログを生成して保存するように構成されているかどうかをチェックします。Amazon Connect インスタンスが CloudWatch ロググループにフローログを生成して保存するように設定されていない場合、コントロールは失敗します。

Amazon Connect フローログは、Amazon Connect フロー内のイベントに関するリアルタイムの詳細を提供します。*フロー*により、Amazon Connect コンタクトセンターでのカスタマーエクスペリエンスを最初から最後まで定義します。デフォルトでは、新しい Amazon Connect インスタンスを作成すると、Amazon CloudWatch ロググループが自動的に作成され、インスタンスのフローログが保存されます。フローログは、フローの分析、エラーの検索、運用メトリクスのモニタリングに役立ちます。フローで発生する可能性のある特定のイベントのアラートを設定することもできます。

### 修正
<a name="connect-2-remediation"></a>

Amazon Connect インスタンスのフローログを有効にする方法については、「*Amazon Connect 管理者ガイド*」の「[Enable Amazon Connect flow logs in an Amazon CloudWatch log group](https://docs.aws.amazon.com/connect/latest/adminguide/contact-flow-logs.html)」を参照してください。

# Amazon Data Firehose の Security Hub CSPM コントロール
<a name="datafirehose-controls"></a>

これらの Security Hub CSPM コントロールは、Amazon Data Firehose サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [DataFirehose.1] Firehose 配信ストリームは保管時に暗号化する必要があります
<a name="datafirehose-1"></a>

**関連する要件:** NIST.800-53.r5 AC-3、NIST.800-53.r5 AU-3、NIST.800-53.r5 SC-12、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28

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

**重要度:** 中

**リソースタイプ :** `AWS::KinesisFirehose::DeliveryStream`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/kinesis-firehose-delivery-stream-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/kinesis-firehose-delivery-stream-encrypted.html)

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

**パラメータ :** なし 

このコントロールは、Amazon Data Firehose 配信ストリームが保管中にサーバー側の暗号化を使用して暗号化されているかどうかをチェックします。Firehose 配信ストリームが、保管中にサーバー側の暗号化を使用して暗号化されていない場合、このコントロールは失敗します。

サーバー側の暗号化は、Amazon Data Firehose 配信ストリームの機能であり、 AWS Key Management Service () で作成されたキーを使用して、保管中のデータを自動的に暗号化しますAWS KMS。データは、Data Firehose ストリームストレージレイヤーに書き込まれる前に暗号化され、ストレージから取得された後で復号されます。これにより、厳格な規制要件に準拠し、データのセキュリティを強化することが可能になります。

### 修正
<a name="datafirehose-1-remediation"></a>

Firehose 配信ストリームでサーバー側の暗号化を有効にするには、「*Amazon Data Firehose デベロッパーガイド*」の「[Amazon Data Firehose でのデータ保護](https://docs.aws.amazon.com/firehose/latest/dev/encryption.html)」を参照してください。

# の Security Hub CSPM コントロール AWS Database Migration Service
<a name="dms-controls"></a>

これらの AWS Security Hub CSPM コントロールは、 AWS Database Migration Service (AWS DMS) と AWS DMS リソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [DMS.1] Database Migration Service のレプリケーションインスタンスは非パブリックである必要があります
<a name="dms-1"></a>

**関連する要件:** NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)、PCI DSS v3.2.1/1.2.1、PCI DSS v3.2.1/1.3.1、PCI DSS v3.2.1/1.3.4、PCI DSS v3.2.1/1.3.2、PCI DSS v3.2.1/1.3.6、PCI DSS v4.0.1/1.4.4

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

**重要度:** 非常事態

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/dms-replication-not-public.html](https://docs.aws.amazon.com/config/latest/developerguide/dms-replication-not-public.html)

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

**パラメータ :** なし

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

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

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

### 修正
<a name="dms-1-remediation"></a>

DMS レプリケーションインスタンスのパブリックアクセス設定は、作成後に変更できません。パブリックアクセス設定を変更するには、[現在のインスタンスを削除](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.Deleting.html)してから[再作成](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)します。**[パブリックアクセス可能]** オプションは選択しないでください。

## [DMS.2] DMS 証明書にはタグを付ける必要があります
<a name="dms-2"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::DMS::Certificate`

**AWS Config rule:** `tagged-dms-certificate` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、 AWS DMS 証明書にパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。証明書にタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、証明書にキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="dms-2-remediation"></a>

DMS 証明書にタグを追加するには、「*AWS Database Migration Service ユーザーガイド*」の「[AWS Database Migration Serviceのリソースのタグ付け](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tagging.html)」を参照してください。

## [DMS.3] DMS イベントサブスクリプションにはタグを付ける必要があります
<a name="dms-3"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::DMS::EventSubscription`

**AWS Config rule:** `tagged-dms-eventsubscription` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、 AWS DMS イベントサブスクリプションにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。イベントサブスクリプションにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、イベントサブスクリプションにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、『』の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="dms-3-remediation"></a>

DMS イベントサブスクリプションにタグを追加するには、「*AWS Database Migration Service ユーザーガイド*」の「[AWS Database Migration Serviceのリソースのタグ付け](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tagging.html)」を参照してください。

## [DMS.4] DMS レプリケーションインスタンスにはタグを付ける必要があります
<a name="dms-4"></a>

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

**重要度:** 低

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

**AWS Config rule:** `tagged-dms-replicationinstance` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、レ AWS DMS プリケーションインスタンスにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。レプリケーションインスタンスにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、レプリケーションインスタンスにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、『』の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="dms-4-remediation"></a>

DMS レプリケーションインスタンスにタグを追加するには、「*AWS Database Migration Service ユーザーガイド*」の「[AWS Database Migration Serviceのリソースのタグ付け](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tagging.html)」を参照してください。

## [DMS.5] DMS レプリケーションサブネットグループにはタグを付ける必要があります
<a name="dms-5"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::DMS::ReplicationSubnetGroup`

**AWS Config rule:** `tagged-dms-replicationsubnetgroup` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、 AWS DMS レプリケーションサブネットグループにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。レプリケーションサブネットグループにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、レプリケーションサブネットグループにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、『』の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="dms-5-remediation"></a>

DMS レプリケーションサブネットグループにタグを追加するには、「*AWS Database Migration Service ユーザーガイド*」の「[AWS Database Migration Serviceのリソースのタグ付け](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tagging.html)」を参照してください。

## [DMS.6] DMS レプリケーションインスタンスでは、マイナーバージョンの自動アップグレードが有効になっている必要があります。
<a name="dms-6"></a>

**関連する要件:** NIST.800-53.r5 SI-2、NIST.800-53.r5 SI-2(2)、NIST.800-53.r5 SI-2(4)、NIST.800-53.r5 SI-2(5)、PCI DSS v4.0.1/6.3.3

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/dms-auto-minor-version-upgrade-check.html](https://docs.aws.amazon.com/config/latest/developerguide/dms-auto-minor-version-upgrade-check.html)

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

**パラメータ :** なし

このコントロールは、 AWS DMS レプリケーションインスタンスで自動マイナーバージョンアップグレードが有効になっているかどうかを確認します。このコントロールは、DMS レプリケーションインスタンスのマイナーバージョンの自動アップグレードが有効になっているかどうかを確認します。

DMS は、サポートされている各レプリケーションエンジンに自動的にマイナーバージョンアップグレードを行うため、レプリケーションインスタンスを最新の状態に保つことができます。マイナーバージョンには、ソフトウェアの新機能、バグ修正、セキュリティパッチ、およびパフォーマンスの向上を含む可能性があります。DMS レプリケーションインスタンスでマイナーバージョン自動アップグレードを有効にすると、マイナーアップグレードはメンテナンス期間中に自動的に適用され、**[変更を今すぐ適用]** オプションが選択されている場合はすぐに適用されます。

### 修正
<a name="dms-6-remediation"></a>

DMS レプリケーションインスタンスのマイナーバージョン自動アップグレードを有効にするには、「**AWS Database Migration Service ユーザーガイド」の「[レプリケーションインスタンスの変更](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.Modifying.html)」を参照してください。

## [DMS.7] ターゲットデータベースの DMS レプリケーションタスクでは、ロギングが有効になっている必要があります。
<a name="dms-7"></a>

**関連する要件:** NIST.800-53.r5 AC-2(4)、NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AC-6(9)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4(20)、NIST.800-53.r5 SI-7(8)、PCI DSS v4.0.1/10.4.2

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

**重要度:** 中

**リソースタイプ :** `AWS::DMS::ReplicationTask`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/dms-replication-task-targetdb-logging.html](https://docs.aws.amazon.com/config/latest/developerguide/dms-replication-task-targetdb-logging.html)

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

**パラメータ :** なし

このコントロールは、DMS レプリケーションタスク `TARGET_APPLY` および `TARGET_LOAD` の `LOGGER_SEVERITY_DEFAULT` の最小重要度レベルでログ記録が有効になっているかどうかを確認します。これらのタスクでロギングが有効になっていない場合や、最小重大度レベルが `LOGGER_SEVERITY_DEFAULT` よりも低い場合、コントロールは失敗します。

DMS は、移行プロセス中に Amazon CloudWatch を使用して情報をログ記録します。ロギングタスク設定を使用して、ログ記録するコンポーネントアクティビティとログに記録する情報量を指定できます。次のタスクにはロギングを指定する必要があります。
+ `TARGET_APPLY` - データおよびデータ定義言語 (DDL) ステートメントがターゲットデータベースに適用されます。
+ `TARGET_LOAD` — データはターゲットデータベースにロードされます。

ロギングは、モニタリング、トラブルシューティング、監査、パフォーマンス分析、エラー検出、リカバリのほか、履歴分析やレポート作成を可能にするため、DMS のレプリケーションタスクにおいて重要な役割を果たします。これにより、データの整合性と規制要件の遵守を維持しながら、データベース間のデータレプリケーションを正常に行うことができます。これらのコンポーネントでは、トラブルシューティング時に `DEFAULT` 以外のログレベルが必要になることは、ほぼありません。 サポートにより特に変更の要求がない限り、これらのコンポーネントには `DEFAULT` と同じログレベルを維持するようにしてください。`DEFAULT` の最低限のロギングレベルでは、情報メッセージ、警告、エラーメッセージが確実にログに書き込まれます。このコントロールは、前述のレプリケーションタスクのログレベルが、`LOGGER_SEVERITY_DEFAULT`、`LOGGER_SEVERITY_DEBUG` または `LOGGER_SEVERITY_DETAILED_DEBUG` のいずれかのログレベルであるかどうかを確認します。

### 修正
<a name="dms-7-remediation"></a>

ターゲットデータベースの DMS レプリケーションタスクのログ記録を有効にするには、*AWS Database Migration Service 「 ユーザーガイド*[」の AWS DMS 「タスクログの表示と管理](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Monitoring.html#CHAP_Monitoring.ManagingLogs)」を参照してください。

## [DMS.8] ソースデータベースの DMS レプリケーションタスクでは、ロギングが有効になっている必要があります。
<a name="dms-8"></a>

**関連する要件:** NIST.800-53.r5 AC-2(4)、NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AC-6(9)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4(20)、NIST.800-53.r5 SI-7(8)、PCI DSS v4.0.1/10.4.2

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

**重要度:** 中

**リソースタイプ :** `AWS::DMS::ReplicationTask`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/dms-replication-task-sourcedb-logging.html](https://docs.aws.amazon.com/config/latest/developerguide/dms-replication-task-sourcedb-logging.html)

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

**パラメータ :** なし

このコントロールは、DMS レプリケーションタスク `SOURCE_CAPTURE` および `SOURCE_UNLOAD` の `LOGGER_SEVERITY_DEFAULT` の最小重要度レベルでログ記録が有効になっているかどうかを確認します。これらのタスクでロギングが有効になっていない場合や、最小重大度レベルが `LOGGER_SEVERITY_DEFAULT` よりも低い場合、コントロールは失敗します。

DMS は、移行プロセス中に Amazon CloudWatch を使用して情報をログ記録します。ロギングタスク設定を使用して、ログ記録するコンポーネントアクティビティとログに記録する情報量を指定できます。次のタスクにはロギングを指定する必要があります。
+ `SOURCE_CAPTURE`— 進行中のレプリケーションまたは変更データキャプチャ (CDC) データがソースデータベースまたはサービスからキャプチャされ、`SORTER` サービスコンポーネントに渡されます。
+ `SOURCE_UNLOAD`— 全ロード中に、データがソースデータベースまたはサービスからアンロードされます。

ロギングは、モニタリング、トラブルシューティング、監査、パフォーマンス分析、エラー検出、リカバリのほか、履歴分析やレポート作成を可能にするため、DMS のレプリケーションタスクにおいて重要な役割を果たします。これにより、データの整合性と規制要件の遵守を維持しながら、データベース間のデータレプリケーションを正常に行うことができます。これらのコンポーネントでは、トラブルシューティング時に `DEFAULT` 以外のログレベルが必要になることは、ほぼありません。 サポートにより特に変更の要求がない限り、これらのコンポーネントには `DEFAULT` と同じログレベルを維持するようにしてください。`DEFAULT` の最低限のロギングレベルでは、情報メッセージ、警告、エラーメッセージが確実にログに書き込まれます。このコントロールは、前述のレプリケーションタスクのログレベルが、`LOGGER_SEVERITY_DEFAULT`、`LOGGER_SEVERITY_DEBUG` または `LOGGER_SEVERITY_DETAILED_DEBUG` のいずれかのログレベルであるかどうかを確認します。

### 修正
<a name="dms-8-remediation"></a>

ソースデータベースの DMS レプリケーションタスクのログ記録を有効にするには、*AWS Database Migration Service 「 ユーザーガイド*[」の AWS DMS 「タスクログの表示と管理](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Monitoring.html#CHAP_Monitoring.ManagingLogs)」を参照してください。

## [DMS.9] DMS エンドポイントは SSL を使用する必要があります。
<a name="dms-9"></a>

**関連する要件:** NIST.800-53.r5 AC-4、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-23、NIST.800-53.r5 SC-23(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-8、NIST.800-53.r5 SC-8(1)、NIST.800-53.r5 SC-8(2)、PCI DSS v4.0.1/4.2.1

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

**重要度:** 中

**リソースタイプ :** `AWS::DMS::Endpoint`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/dms-endpoint-ssl-configured.html](https://docs.aws.amazon.com/config/latest/developerguide/dms-endpoint-ssl-configured.html)

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

**パラメータ :** なし

このコントロールは、 AWS DMS エンドポイントが SSL 接続を使用しているかどうかをチェックします。エンドポイントが SSL を使用していない場合、コントロールは失敗します。

SSL/TLS 接続は、DMS レプリケーションインスタンスとデータベースの間の接続を暗号化することによって、セキュリティレイヤーを 1 つ提供します。証明書を使用すると、想定されるデータベースへの接続が確立されていることを検証することによって、追加のセキュリティレイヤーが提供されます。これを行うには、プロビジョニングしたすべての DB インスタンスに自動インストールされたサーバー証明書を確認します。DMS エンドポイントで SSL 接続を有効にすることで、移行中のデータの機密性を保護できます。

### 修正
<a name="dms-9-remediation"></a>

SSL 接続を新規または既存の DMS エンドポイントに追加するには、「**AWS Database Migration Service ユーザーガイド」の「[AWS Database Migration Serviceでの SSL の使用](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Security.SSL.html#CHAP_Security.SSL.Procedure)」を参照してください。

## [DMS.10] Neptune データベースの DMS エンドポイントでは、IAM 認証が有効になっている必要があります
<a name="dms-10"></a>

**関連する要件:** NIST.800-53.r5 AC-2、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-6、NIST.800-53.r5 AC-17、NIST.800-53.r5 IA-2、NIST.800-53.r5 IA-5、PCI DSS v4.0.1/7.3.1

**カテゴリ:** 保護 > セキュアなアクセス管理 > パスワードレス認証

**重要度:** 中

**リソースタイプ :** `AWS::DMS::Endpoint`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/dms-neptune-iam-authorization-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/dms-neptune-iam-authorization-enabled.html)

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

**パラメータ :** なし

このコントロールは、Amazon Neptune データベースの AWS DMS エンドポイントが IAM 認可で設定されているかどうかを確認します。DMS エンドポイントで IAM 認証が有効になっていない場合、コントロールは失敗します。

AWS Identity and Access Management (IAM) は、 全体できめ細かなアクセスコントロールを提供します AWS。IAM では、誰がどのサービスとリソースにアクセスできるか、またどの条件下でアクセスできるかを指定できます。IAM ポリシーを使用すると、ワークフォースとシステムへのアクセス許可を管理し、最小特権のアクセス許可を確保できます。Neptune データベースの AWS DMS エンドポイントで IAM 認可を有効にすると、 `ServiceAccessRoleARN`パラメータで指定されたサービスロールを使用して、IAM ユーザーに認可権限を付与できます。

### 修正
<a name="dms-10-remediation"></a>

Neptune データベースの DMS エンドポイントで IAM 認証を有効にするには、「*AWS Database Migration Service ユーザーガイド*」の「[Amazon Neptune を AWS Database Migration Serviceのターゲットとして使用する](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.Neptune.html)」を参照してください。

## [DMS.11] MongoDB の DMS エンドポイントでは、認証メカニズムが有効になっている必要があります
<a name="dms-11"></a>

**関連する要件:** NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-6、NIST.800-53.r5 IA-2、NIST.800-53.r5 IA-5、PCI DSS v4.0.1/7.3.1

**カテゴリ:** 保護 > セキュアなアクセス管理 > パスワードレス認証

**重要度:** 中

**リソースタイプ :** `AWS::DMS::Endpoint`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/dms-mongo-db-authentication-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/dms-mongo-db-authentication-enabled.html)

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

**パラメータ :** なし

このコントロールは、MongoDB の AWS DMS エンドポイントが認証メカニズムで設定されているかどうかをチェックします。エンドポイントに認証タイプが設定されていない場合、コントロールは失敗します。

AWS Database Migration Service は、MongoDB の 2 つの認証方法をサポートしています。MongoDB バージョン 2.x の場合は **MONGODB-CR**、MongoDB バージョン 3.x 以降の場合は **SCRAM-SHA-1** です。これらの認証方法は、ユーザーがパスワードを使用してデータベースにアクセスする場合に MongoDB パスワードを認証および暗号化するために使用されます。 AWS DMS エンドポイントでの認証により、承認されたユーザーのみがデータベース間で移行されるデータにアクセスして変更できるようになります。適切な認証がないと、移行プロセス中に権限のないユーザーが機密データにアクセスできる可能性があります。これにより、データ侵害、データ損失、またはその他のセキュリティインシデントが発生する可能性があります。

### 修正
<a name="dms-11-remediation"></a>

MongoDB の DMS エンドポイントで認証メカニズムを有効にするには、「*AWS Database Migration Service ユーザーガイド*」の「[MongoDB を AWS DMSのソースとして使用する](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.MongoDB.html)」を参照してください。

## [DMS.12] Redis OSS の DMS エンドポイントでは TLS が有効になっている必要があります
<a name="dms-12"></a>

**関連する要件:** NIST.800-53.r5 SC-8、NIST.800-53.r5 SC-13、PCI DSS v4.0.1/4.2.1

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

**重要度:** 中

**リソースタイプ :** `AWS::DMS::Endpoint`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/dms-redis-tls-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/dms-redis-tls-enabled.html)

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

**パラメータ :** なし

このコントロールは、Redis OSS の AWS DMS エンドポイントが TLS 接続で設定されているかどうかを確認します。エンドポイントで TLS が有効になっていない場合、コントロールは失敗します。

TLS は、データがインターネット経由でアプリケーションまたはデータベース間で送信されるときに、エンドツーエンドのセキュリティを提供します。DMS エンドポイントに SSL 暗号化を設定すると、移行プロセス中にソースデータベースとターゲットデータベース間の暗号化された通信が可能になります。これにより、悪意のある攻撃者による機密データの盗聴や傍受を防ぐことができます。SSL 暗号化を使用しないと、機密データにアクセスされ、データ侵害、データ損失、またはその他のセキュリティインシデントが発生する可能性があります。

### 修正
<a name="dms-12-remediation"></a>

Redis の DMS エンドポイントで TLS 接続を有効にするには、「*AWS Database Migration Service ユーザーガイド*」の「[AWS Database Migration Serviceのターゲットとして Redis を使用する](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.Redis.html)」を参照してください。

## [DMS.13] DMS レプリケーションインスタンスは、複数のアベイラビリティーゾーンを使用するよう設定する必要があります
<a name="dms-13"></a>

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/dms-replication-instance-multi-az-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/dms-replication-instance-multi-az-enabled.html)

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

**パラメータ :** なし

このコントロールは、 AWS Database Migration Service (AWS DMS) レプリケーションインスタンスが複数のアベイラビリティーゾーン (マルチ AZ 配置) を使用するように設定されているかどうかを確認します。 AWS DMS レプリケーションインスタンスがマルチ AZ 配置を使用するように設定されていない場合、コントロールは失敗します。

マルチ AZ 配置では、 は別のアベイラビリティーゾーン (AZ) にレプリケーションインスタンスのスタンバイレプリカ AWS DMS を自動的にプロビジョニングして維持します。その後、プライマリレプリケーションインスタンスは、同期的にスタンバイレプリカにレプリケートされます。プライマリレプリケーション インスタンスに障害が発生するか、応答しない場合、スタンバイ状態で中断時間をできる限り抑えて、実行中のタスクを再開します。詳細については、「*AWS Database Migration Service ユーザーガイド*」の「[Working with a replication instance](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.html)」を参照してください。

### 修正
<a name="dms-13-remediation"></a>

 AWS DMS レプリケーションインスタンスを作成したら、そのインスタンスのマルチ AZ デプロイ設定を変更できます。既存のレプリケーションインスタンスのこの設定やその他の設定を変更する方法については、「*AWS Database Migration Service ユーザーガイド*」の「[Modifying a replication instance](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.Modifying.html)」を参照してください。

# の Security Hub CSPM コントロール AWS DataSync
<a name="datasync-controls"></a>

これらの Security Hub CSPM コントロールは、 AWS DataSync サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [DataSync.1] DataSync タスクではログ記録が有効になっている必要があります
<a name="datasync-1"></a>

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

**重要度:** 中

**リソースタイプ :** `AWS::DataSync::Task`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/datasync-task-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/datasync-task-logging-enabled.html)

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

**パラメータ :** なし

このコントロールは、 AWS DataSync タスクでログ記録が有効になっているかどうかを確認します。タスクでログ記録が有効になっていない場合、コントロールは失敗します。

監査ログは、システムアクティビティを追跡およびモニタリングします。これらは、セキュリティ違反の検出、インシデントの調査、規制の遵守に役立つイベントの記録を提供します。監査ログは、組織の全体的な説明責任と透明性も強化します。

### 修正
<a name="datasync-1-remediation"></a>

 AWS DataSync タスクのログ記録の設定については、「 *AWS DataSync ユーザーガイド*」の[Amazon CloudWatch Logs によるデータ転送のモニタリング](https://docs.aws.amazon.com/datasync/latest/userguide/configure-logging.html)」を参照してください。

## [DataSync.2] DataSync タスクにはタグを付ける必要があります
<a name="datasync-2"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::DataSync::Task`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/datasync-task-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/datasync-task-tagged.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | 評価されたリソースに割り当てる必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目) | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし | 

このコントロールは、 AWS DataSync タスクに `requiredKeyTags`パラメータで指定されたタグキーがあるかどうかをチェックします。タスクにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。`requiredKeyTags` パラメータの値を指定しない場合、コントロールはタグキーの存在のみをチェックし、タスクにタグキーがない場合に失敗します。このコントロールはシステムタグを無視します。システムタグは自動的に付与され、`aws:` プレフィックスが付きます。

タグは、 AWS リソースを作成して割り当てるラベルです。各タグは、必要なタグキーとオプションのタグ値で設定されています。タグを使用して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。またそれらは、アクションと通知のリソース所有者を追跡するのにも役立ちます。タグを使用して、認可戦略として属性ベースのアクセス制御 (ABAC) を実装することもできます。ABAC 戦略の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。タグの詳細については、[「 AWS リソースのタグ付け」および「タグエディタユーザーガイド](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。

**注記**  
個人を特定できる情報 (PII) などの機密情報や秘匿性の高い情報はタグに格納しないでください。タグには多くの からアクセスできます AWS のサービス。それらは、プライベートデータや機密データに使用することを意図していません。

### 修正
<a name="datasync-2-remediation"></a>

 AWS DataSync タスクにタグを追加する方法については、*AWS DataSync 「 ユーザーガイド*[」の AWS DataSync 「タスクのタグ付け](https://docs.aws.amazon.com/datasync/latest/userguide/tagging-tasks.html)」を参照してください。

# Amazon Detective の Security Hub CSPM コントロール
<a name="detective-controls"></a>

この AWS Security Hub CSPM コントロールは、Amazon Detective サービスとリソースを評価します。コントロールは、すべての AWS リージョンで使用できるとは限りません。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [Detective.1] 検出動作グラフにはタグを付ける必要があります
<a name="detective-1"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::Detective::Graph`

**AWS Config rule:** `tagged-detective-graph` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、Amazon Detective 動作グラフにパラメータ `requiredTagKeys` で定義された特定のキーを含むタグがあるかどうかをチェックします。動作グラフにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、動作グラフにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="detective-1-remediation"></a>

Detective 動作グラフにタグを追加するには、「*Amazon Detective 管理ガイド*」の「[動作グラフにタグを追加する](https://docs.aws.amazon.com/detective/latest/adminguide/graph-tags.html#graph-tags-add-console)」を参照してください。

# Amazon DocumentDB の Security Hub CSPM コントロール
<a name="documentdb-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon DocumentDB (MongoDB 互換) サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [DocumentDB.1] Amazon DocumentDB クラスターは、保管中に暗号化する必要があります
<a name="documentdb-1"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SI-7(6)

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

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-encrypted.html)

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

**パラメータ :** なし

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

保管中のデータとは、永続的な不揮発性ストレージに任意の期間保管されているデータを指します。暗号化は、このようなデータの機密性を保護し、権限のないユーザーがデータにアクセスするリスクを低減するのに役立ちます。Amazon DocumentDB クラスター内のデータは、セキュリティを強化するために、保管中に暗号化する必要があります。Amazon DocumentDB は、256 ビット高度暗号化標準 (AES-256) を使用し、 AWS Key Management Service (AWS KMS) に保存されている暗号化キーを使用してデータを暗号化します。

### 修正
<a name="documentdb-1-remediation"></a>

Amazon DocumentDB クラスターを作成するときに、保管中の暗号化を有効にできます。クラスターを作成した後で暗号化設定を変更することはできません。詳細については、「*Amazon DocumentDB デベロッパーガイド*」の「[Enabling encryption at rest for an Amazon DocumentDB cluster](https://docs.aws.amazon.com/documentdb/latest/developerguide/encryption-at-rest.html#encryption-at-rest-enabling)」を参照してください。

## [DocumentDB.2] Amazon DocumentDB クラスターには、適切なバックアップ保持期間が必要です
<a name="documentdb-2"></a>

**関連する要件:** NIST.800-53.r5 SI-12、PCI DSS v4.0.1/3.2.1

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

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-backup-retention-check.html](https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-backup-retention-check.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `minimumBackupRetentionPeriod`  |  最小バックアップ保持期間 (日数)  |  整数  |  `7`～`35`  |  `7`  | 

このコントロールは、Amazon DocumentDB クラスターのバックアップ保持期間が指定された時間枠以上であるかどうかをチェックします。バックアップ保持期間が指定された時間枠未満の場合、コントロールは失敗します。バックアップ保持期間にカスタムパラメータ値を指定しない限り、Security Hub CSPM はデフォルト値の 7 日間を使用します。

バックアップは、セキュリティインシデントからの迅速な復元と、システムの耐障害性の強化に役立ちます。Amazon DocumentDB クラスターのバックアップを自動化すると、システムを特定の時点に復元し、ダウンタイムとデータ損失を最小限に抑えることができます。Amazon DocumentDB では、クラスターのデフォルトのバックアップ保持期間は 1 日です。このコントロールを成功させるには、この値を 7 日から 35 日までの値に増やす必要があります。

### 修正
<a name="documentdb-2-remediation"></a>

Amazon DocumentDB クラスターのバックアップ保持期間を変更するには、「*Amazon DocumentDB デベロッパーガイド*」の「[Amazon DocumentDB クラスターの変更](https://docs.aws.amazon.com/documentdb/latest/developerguide/db-cluster-modify.html)」を参照してください。**[バックアップ]** で、バックアップ保持期間を選択します。

## [DocumentDB.3] Amazon DocumentDB 手動クラスタースナップショットはパブリックにできません
<a name="documentdb-3"></a>

**関連する要件:** NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)、PCI DSS v4.0.1/1.4.4

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

**重要度:** 非常事態

**リソースタイプ :** `AWS::RDS::DBClusterSnapshot`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-snapshot-public-prohibited.html](https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-snapshot-public-prohibited.html)

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

**パラメータ :** なし

このコントロールは、Amazon DocumentDB の手動クラスタースナップショットがパブリックかどうかをチェックします。手動クラスタースナップショットがパブリックの場合、コントロールは失敗します。

Amazon DocumentDB 手動クラスタースナップショットは、意図しない限りパブリックにしないでください。暗号化されていない手動スナップショットをパブリックとして共有すると、すべての AWS アカウントでこのスナップショットを使用できるようになります。パブリックスナップショットは、意図しないデータ漏えいにつながる可能性があります。

**注記**  
このコントロールは手動クラスタースナップショットを評価します。Amazon DocumentDB 自動クラスタースナップショットを共有することはできません。ただし、自動スナップショットをコピーして手動スナップショットを作成し、そのコピーを共有できます。

### 修正
<a name="documentdb-3-remediation"></a>

Amazon DocumentDB 手動クラスタースナップショットへのパブリックアクセスを削除するには、「*Amazon DocumentDB* デベロッパーガイド」の「[スナップショットの共有](https://docs.aws.amazon.com/documentdb/latest/developerguide/backup_restore-share_cluster_snapshots.html#backup_restore-share_snapshots)」を参照してください。プログラムでは、Amazon DocumentDB のオペレーション `modify-db-snapshot-attribute` を使用できます。`attribute-name` を `restore` として、`values-to-remove` を `all` として設定します。

## [DocumentDB.4] Amazon DocumentDB クラスターでは、監査ログを CloudWatch Logs に発行する必要があります
<a name="documentdb-4"></a>

**関連する要件:** NIST.800-53.r5 AC-2(4)、NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AC-6(9)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4(20)、NIST.800-53.r5 SI-7(8)、PCI DSS v4.0.1/10.3.3

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

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-audit-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-audit-logging-enabled.html)

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

**パラメータ :** なし

このコントロールは、Amazon DocumentDB クラスターが監査ログを Amazon CloudWatch Logs に発行しているかどうかを確認します。クラスターが監査ログを CloudWatch Logs に発行していない場合、コントロールは失敗します。

Amazon DocumentDB (MongoDB 互換) を使用すると、クラスター内で実行されたイベントを監査できます。ログに記録されるイベントの例としては、認証の成功と失敗、データベース内のコレクションの削除、インデックスの作成などがあります。デフォルトでは、監査が Amazon DocumentDB 上で無効化されているため、この機能を有効化する必要があります。

### 修正
<a name="documentdb-4-remediation"></a>

Amazon DocumentDB 監査ログを CloudWatch Logs に公開するには、「*Amazon DocumentDB デベロッパーガイド*」の「[監査の有効化](https://docs.aws.amazon.com/documentdb/latest/developerguide/event-auditing.html#event-auditing-enabling-auditing)」を参照してください。

## [DocumentDB.5] Amazon DocumentDB では、削除保護が有効になっている必要があります
<a name="documentdb-5"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)、NIST.800-53.r5 CM-3、NIST.800-53.r5 SC-5(2)

**カテゴリ:** 保護 > データ保護 > データ削除保護

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-deletion-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-deletion-protection-enabled.html)

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

**パラメータ :** なし

このコントロールは、Amazon DocumentDB クラスターで削除保護が有効になっているかどうかを確認します。クラスターで削除保護が有効になっていない場合、コントロールは失敗します。

クラスターの削除保護を有効にすることで、偶発的なデータベース削除や権限のないユーザーによる削除に対して保護の強化を提供します。削除保護が有効の間、Amazon DocumentDB クラスターは削除できません。削除リクエストを成功させるには、まず削除保護を無効にする必要があります。Amazon DocumentDB コンソールを使用してクラスターを作成する場合は、デフォルトで削除保護が有効になっています。

### 修正
<a name="documentdb-5-remediation"></a>

*既存の Amazon DocumentDB クラスターの削除保護を有効にするには、「Amazon DocumentDB デベロッパーガイド*」の「[Amazon DocumentDB クラスターの変更](https://docs.aws.amazon.com/documentdb/latest/developerguide/db-cluster-modify.html)」を参照してください。**[クラスターの変更]** セクションで、******[削除保護の有効化]**を選択します。

## [DocumentDB.6] Amazon DocumentDB クラスターは、転送中に暗号化する必要があります
<a name="documentdb-6"></a>

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

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-encrypted-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-encrypted-in-transit.html)

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

**パラメータ:** `excludeTlsParameters`: `disabled`、`enabled` (カスタマイズ不可)

このコントロールは、Amazon DocumentDB クラスターがクラスターへの接続に TLS を要求するかどうかをチェックします。クラスターに関連付けられたクラスターパラメータグループが同期していない場合、または TLS クラスターパラメータが `disabled` または `enabled` に設定されている場合、コントロールは失敗します。

TLS を使用して、アプリケーションと Amazon DocumentDB クラスター間の接続を暗号化できます。TLS を使用すると、アプリケーションと Amazon DocumentDB クラスター間の転送中にデータが傍受されるのを防ぐことができます。Amazon DocumentDB クラスターの転送中の暗号化は、クラスターに関連付けられているクラスターパラメータグループ の TLS パラメータを使用して管理されます。転送中の暗号化が有効になっている場合、クラスターに接続するには TLS を使用したセキュアな接続が必要です。TLS パラメータ `tls1.2+`、`tls1.3+`、`fips-140-3` を使用することをお勧めします。

### 修正
<a name="documentdb-6-remediation"></a>

Amazon DocumentDB クラスターの TLS 設定を変更する方法については、「*Amazon DocumentDB デベロッパーガイド*」の「[Encrypting data in transit](https://docs.aws.amazon.com/documentdb/latest/developerguide/security.encryption.ssl.html)」を参照してください。

# DynamoDB の Security Hub CSPM コントロール
<a name="dynamodb-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon DynamoDB サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [DynamoDB.1] DynamoDB テーブルは、需要に応じて容量をオートスケーリングする必要があります
<a name="dynamodb-1"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-2(2)、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 SC-36、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/dynamodb-autoscaling-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/dynamodb-autoscaling-enabled.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 有効なカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `minProvisionedReadCapacity`  |  DynamoDB 自動スケーリング用にプロビジョニングされた読み込みキャパシティユニットの最小数  |  整数  |  `1`～`40000`  |  デフォルト値なし  | 
|  `targetReadUtilization`  |  読み込みキャパシティのターゲット使用率 (%)  |  整数  |  `20`～`90`  |  デフォルト値なし  | 
|  `minProvisionedWriteCapacity`  |  DynamoDB 自動スケーリング用にプロビジョニングされた書き込みキャパシティユニットの最小数  |  整数  |  `1`～`40000`  |  デフォルト値なし  | 
|  `targetWriteUtilization`  |  書き込みキャパシティのターゲット使用率 (%)  |  整数  |  `20`～`90`  |  デフォルト値なし  | 

このコントロールは、Amazon DynamoDB テーブルが必要に応じて読み取りおよび書き込み容量をスケーリングできるかどうかをチェックします。テーブルで自動スケーリングが設定されたオンデマンドキャパシティモードまたはプロビジョンモードを使用しない場合、コントロールは失敗します。デフォルトでは、このコントロールは、特定のレベルの読み込みまたは書き込みキャパシティに関係なく、これらのモードのいずれかを設定するだけで済みます。必要に応じて、特定のレベルの読み込みおよび書き込みキャパシティ、またはターゲット使用率を必要とするカスタムパラメータ値を指定できます。

需要に応じて容量をスケーリングすると、スロットリング例外を回避し、アプリケーションの可用性を維持するのに役立ちます。オンデマンドキャパシティモードを使用する DynamoDB テーブルは、DynamoDB スループットのデフォルトテーブルクォータによってのみ制限されます。これらのクォータを引き上げるには、 にサポートチケットを提出できます サポート。自動スケーリングを使うプロビジョニングモードを使用する DynamoDB テーブルでは、トラフィックパターンに応じてプロビジョンドスループットキャパシティ性能を動的に調整します。DynamoDB リクエストスロットリングの詳細については、「*Amazon DynamoDB デベロッパーガイド*」の「[Request throttling and burst capacity](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ProvisionedThroughput.html#ProvisionedThroughput.Throttling)」を参照してください。

### 修正
<a name="dynamodb-1-remediation"></a>

キャパシティモードで既存テーブルの DynamoDB 自動スケーリングを有効にするには、「*Amazon DynamoDB デベロッパーガイド*」の「[既存のテーブルでの DynamoDB Auto Scaling の有効化](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.Console.html#AutoScaling.Console.ExistingTable)」を参照してください。

## [DynamoDB.2] DynamoDB テーブルでは、ポイントインタイムリカバリが有効になっている必要があります。
<a name="dynamodb-2"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 CP-9、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-12、NIST.800-53.r5 SI-13(5)

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/dynamodb-pitr-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/dynamodb-pitr-enabled.html)

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

**パラメータ:** なし

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

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

### 修正
<a name="dynamodb-2-remediation"></a>

DynamoDB テーブルを特定の時点に復元するには、「*Amazon DynamoDB デベロッパーガイド*」の「[DynamoDB テーブルを特定の時点に復元](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.Tutorial.html)」を参照してください。

## [DynamoDB.3] DynamoDB Accelerator (DAX) クラスターは、保管中に暗号化する必要があります
<a name="dynamodb-3"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SI-7(6)

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/dax-encryption-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/dax-encryption-enabled.html)

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

**パラメータ :** なし

このコントロールは、Amazon DynamoDB Accelerator (DAX) クラスターが保管時に暗号化されているかどうかをチェックします。DAX クラスターが保管中に暗号化されていない場合、コントロールは失敗します。

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

### 修正
<a name="dynamodb-3-remediation"></a>

クラスターが作成された後は、保管中の暗号化を有効または無効にすることはできません。保管中の暗号化を有効にするにはクラスターを再作成する必要があります。保管中の暗号化が有効な DAX クラスターを作成する方法の詳細については、「Amazon DynamoDB 開発者ガイド」の「[AWS マネジメントコンソールを使用して保管中の暗号化を有効にする](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAXEncryptionAtRest.html#dax.encryption.tutorial-console)」を参照してください。

## [DynamoDB.4] DynamoDB テーブルはバックアッププランにある必要があります
<a name="dynamodb-4"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6、NIST.800-53.r5 CP-6(1)、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 CP-9、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-12、NIST.800-53.r5 SI-13(5)

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

**重要度:** 中

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

**AWS Config ルール:** [https://docs.aws.amazon.com/config/latest/developerguide/dynamodb-resources-protected-by-backup-plan.html](https://docs.aws.amazon.com/config/latest/developerguide/dynamodb-resources-protected-by-backup-plan.html) ``

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `backupVaultLockCheck`  |  パラメータが に設定`true`され、リソースが AWS Backup ボールトロックを使用する場合、コントロールは`PASSED`結果を生成します。  |  ブール値  |  `true` 、、または `false`  |  デフォルト値なし  | 

このコントロールは、`ACTIVE` 状態の Amazon DynamoDB テーブルがバックアッププランの対象になっているかどうかを評価します。DynamoDB テーブルがバックアッププランの対象になっていない場合、コントロールは失敗します。`backupVaultLockCheck` パラメータを に設定すると`true`、DynamoDB テーブルが AWS Backup ロックされたボールトにバックアップされている場合にのみコントロールが成功します。

AWS Backup は、 全体のデータのバックアップを一元化および自動化するのに役立つフルマネージドバックアップサービスです AWS のサービス。を使用すると AWS Backup、データのバックアップ頻度やバックアップの保持期間など、バックアップ要件を定義するバックアッププランを作成できます。バックアッププランに DynamoDB テーブルを含めると、意図しない損失や削除からデータを保護できます。

### 修正
<a name="dynamodb-4-remediation"></a>

 AWS Backup バックアッププランに DynamoDB テーブルを追加するには、「 *AWS Backup デベロッパーガイド*[」の「バックアッププランへのリソースの割り当て](https://docs.aws.amazon.com/aws-backup/latest/devguide/assigning-resources.html)」を参照してください。

## [DynamoDB.5] DynamoDB テーブルにはタグを付ける必要があります
<a name="dynamodb-5"></a>

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

**重要度:** 低

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

**AWS Config rule:** `tagged-dynamodb-table` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、Amazon DynamoDB テーブルにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。テーブルにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、テーブルにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="dynamodb-5-remediation"></a>

DynamoDB テーブルにタグを追加するには、「*Amazon DynamoDB デベロッパーガイド*」の「[DynamoDB でのリソースのタグ付け](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Tagging.Operations.html)」を参照してください。

## [DynamoDB.6] DynamoDB テーブルで、削除保護が有効になっている必要があります
<a name="dynamodb-6"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)、NIST.800-53.r5 CM-3、NIST.800-53.r5 SC-5(2)

**カテゴリ:** 保護 > データ保護 > データ削除保護

**重要度:** 中

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

**AWS Config ルール:** [https://docs.aws.amazon.com/config/latest/developerguide/dynamodb-table-deletion-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/dynamodb-table-deletion-protection-enabled.html) ``

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

**パラメータ :** なし

このコントロールは、Amazon DynamoDB テーブルで削除保護が有効になっているかどうかをチェックします。DynamoDB テーブルで削除保護が有効になっていない場合、コントロールは失敗します。

削除保護プロパティを使用すると、DynamoDB テーブルを誤って削除しないように保護できます。テーブルに対してこのプロパティを有効にすると、管理者が通常のテーブル管理オペレーションを行うときにテーブルが誤って削除されるのを防ぐことができます。これにより、通常業務が中断されるのを防ぐことができます。

### 修正
<a name="dynamodb-6-remediation"></a>

DynamoDB テーブルの削除保護を有効にするには、「*Amazon DynamoDB デベロッパーガイド*」の「[削除保護の使用](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithTables.Basics.html#WorkingWithTables.Basics.DeletionProtection)」を参照してください。

## [DynamoDB.7] DynamoDB Accelerator クラスターは、保管中に暗号化する必要があります
<a name="dynamodb-7"></a>

**関連する要件:** NIST.800-53.r5 AC-17、NIST.800-53.r5 SC-8、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-23、PCI DSS v4.0.1/4.2.1

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/dax-tls-endpoint-encryption.html](https://docs.aws.amazon.com/config/latest/developerguide/dax-tls-endpoint-encryption.html)

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

**パラメータ :** なし

このコントロールは、Amazon DynamoDB Accelerator (DAX) クラスターが転送中に暗号化され、エンドポイント暗号化タイプが TLS に設定されているかどうかを確認します。DAX クラスターが転送中に暗号化されていない場合、コントロールは失敗します。

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

### 修正
<a name="dynamodb-7-remediation"></a>

DAX クラスターを作成した後で TLS 暗号化設定を変更することはできません。既存の DAX クラスターを暗号化するには、転送中の暗号化を有効にした新しいクラスターを作成し、アプリケーションのトラフィックをそのクラスターに移行してから、古いクラスターを削除します。詳細については、「Amazon DynamoDB ディベロッパーガイド」の「[削除保護の使用](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithTables.Basics.html#WorkingWithTables.Basics.DeletionProtection)」を参照してください。**

# Amazon EC2 の Security Hub CSPM コントロール
<a name="ec2-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon Elastic Compute Cloud (Amazon EC2) サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [EC2.1] Amazon EBS スナップショットはパブリックに復元できないようにすることをお勧めします
<a name="ec2-1"></a>

**関連する要件:** PCI DSS v3.2.1/1.2.1、PCI DSS v3.2.1/1.3.1、PCI DSS v3.2.1/1.3.4、PCI DSS v3.2.1/7.2.1、NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)

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

**重要度:** 非常事態 

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ebs-snapshot-public-restorable-check.html](https://docs.aws.amazon.com/config/latest/developerguide/ebs-snapshot-public-restorable-check.html)

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

**パラメータ :** なし

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

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

### 修正
<a name="ec2-1-remediation"></a>

パブリック EBS スナップショットをプライベートにするには、「*Amazon EC2 ユーザーガイド*」の「[スナップショットの共有](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html#share-unencrypted-snapshot)」を参照してください。**[アクション、権限の変更]** で、**[非公開]** を選択します。

## [EC2.2] VPC のデフォルトのセキュリティグループでは、インバウンドトラフィックまたはアウトバウンドトラフィックを許可しないようにすることをお勧めします
<a name="ec2-2"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/5.5、PCI DSS v3.2.1/1.2.1、PCI DSS v3.2.1/1.3.4、PCI DSS v3.2.1/2.1、CIS AWS Foundations Benchmark v1.2.0/4.3、CIS AWS Foundations Benchmark v1.4.0/5.3、CIS AWS Foundations Benchmark v3.0.0/5.4、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(1) NIST.800-53.r5 SC-7 、

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

**重要度:** 高 

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-default-security-group-closed.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-default-security-group-closed.html)

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

**パラメータ :** なし

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

[デフォルトのセキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/default-security-group.html)のルールでは、同じセキュリティグループに割り当てられているネットワークインターフェイス (および関連するインスタンス) からのすべてのアウトバウンドトラフィックとインバウンドトラフィックを許可します。デフォルトのセキュリティグループを使用しないことをお勧めします。デフォルトのセキュリティグループは削除できないため、デフォルトのセキュリティグループルール設定を変更して、インバウンドトラフィックとアウトバウンドトラフィックを制限する必要があります。これにより、デフォルトのセキュリティグループが EC2 インスタンスなどのリソースに対して誤って設定されている場合に、意図しないトラフィックが防止されます。

### 修正
<a name="ec2-2-remediation"></a>

この問題を解決するには、まず新しい最小特権のセキュリティグループを作成することから始めます。手順については、「*Amazon VPC ユーザーガイド*」の「[セキュリティグループの作成](https://docs.aws.amazon.com/vpc/latest/userguide/security-groups.html#creating-security-groups)」を参照してください。次に、新しいセキュリティグループを EC2 インスタンスに割り当てます。手順については、「*Amazon EC2 ユーザーガイド*」の「[インスタンスのセキュリティグループの変更](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#changing-security-group)」を参照してください。

新しいセキュリティグループをリソースに割り当てた後、デフォルトのセキュリティグループからすべてのインバウンドルールとアウトバウンドルールを削除します。手順については、「*Amazon VPC ユーザーガイド*」の「[セキュリティグループの設定](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html)」を参照してください。

## [EC2.3] アタッチされた Amazon EBS ボリュームは、保管時に暗号化することをお勧めします
<a name="ec2-3"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SI-7(6)

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/encrypted-volumes.html](https://docs.aws.amazon.com/config/latest/developerguide/encrypted-volumes.html)

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

**パラメータ:** なし

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

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

Amazon EBS 暗号化の詳細については、「[Amazon EC2 ユーザーガイド](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)」の「*Amazon EBS 暗号化*」を参照してください。

### 修正
<a name="ec2-3-remediation"></a>

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

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

詳細については、「[Amazon EC2 ユーザーガイド](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-volume.html)」の「*Amazon EBS ボリュームの作成*」および「[Amazon EBS スナップショットのコピー](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-copy-snapshot.html)」を参照してください。

## [EC2.4] 停止した EC2 インスタンスは、指定した期間後に削除する必要があります
<a name="ec2-4"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-stopped-instance.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-stopped-instance.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `AllowedDays`  |  失敗の検出結果が生成される前に、EC2 インスタンスが停止状態になっても許容される日数。  |  整数  |  `1`～`365`  |  `30`  | 

このコントロールは、許可されている日数よりも長く停止している Amazon EC2 インスタンスがあるかどうかをチェックします。EC2 インスタンスが最大許容期間よりも長く停止すると、コントロールは失敗します。最大許容期間にカスタムパラメータ値を指定しない限り、Security Hub CSPM はデフォルト値の 30 日を使用します。

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

### 修正
<a name="ec2-4-remediation"></a>

非アクティブな EC2 インスタンスを終了するには、「*Amazon EC2 ユーザーガイド*」の「[インスタンスの終了](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#terminating-instances-console)」を参照してください。

## [EC2.6] すべての VPC で VPC フローログ記録を有効にすることをお勧めします
<a name="ec2-6"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/3.7、 CIS AWS Foundations Benchmark v1.2.0/2.9、 CIS AWS Foundations Benchmark v1.4.0/3.9、 CIS AWS Foundations Benchmark v3.0.0/3.7、 NIST.800-53.r5 AC-4(26)、 NIST.800-53.r5 AU-12、 NIST.800-53.r5 AU-2、 NIST.800-53.r5 AU-3、 NIST.800-53.r5 AU-6(3)、 NIST.800-53.r5 AU-6(4)、 NIST.800-53.r5 CA-7、 NIST.800-53.r5 SI-7(8)、 NIST.800-171.r2 3.1.20、 NIST.800-171.r2 3.3.1、 NIST.800-171.r2 3.13.1、 PCI DSS v3.2.1/10.3.3、 PCI DSS v3.2.1/10.3.4、 PCI DSS v3.2.1/10.3.5、 PCI DSS v3.2.1/10.3.6

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-flow-logs-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-flow-logs-enabled.html)

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

**パラメータ :**
+ `trafficType`: `REJECT` (カスタマイズ不可)

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

**注記**  
このコントロールは、 AWS アカウントの Amazon Security Lake を介して Amazon VPC フローログが有効になっているかどうかをチェックしません。

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

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

デフォルトでは、レコードには送信元、送信先、プロトコルなど、IP アドレスフローのさまざまなコンポーネントの値が含まれています。ログフィールドの詳細と説明については、「Amazon VPC ユーザーガイド」の「[VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)」を参照してください。

### 修正
<a name="ec2-6-remediation"></a>

VPC フローログを作成するには、「*Amazon VPC ユーザーガイド*」の「[フローログの作成](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-flow-logs.html#create-flow-log)」を参照してください。Amazon VPC コンソールを開いたら、**[お客様の VPC]** を選択します。**[フィルター]** で、**[拒否]** または **[すべて]** を選択します。

## [EC2.7] EBS のデフォルト暗号化を有効にすることをお勧めします
<a name="ec2-7"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/5.1.1、CIS AWS Foundations Benchmark v1.4.0/2.2.1、CIS AWS Foundations Benchmark v3.0.0/2.2.1、NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SI-7(6)

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-ebs-encryption-by-default.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-ebs-encryption-by-default.html)

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

**パラメータ :** なし

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

アカウントで暗号化が有効になっている場合、Amazon EBS ボリュームとスナップショットのコピーは保管中に暗号化されます。これにより、データの保護レイヤーが追加されます。詳細については、「*Amazon EC2 ユーザーガイド*」の「[デフォルトでの暗号化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default)」を参照してください。

### 修正
<a name="ec2-7-remediation"></a>

Amazon EBS ボリュームのデフォルト暗号化の設定については、「*Amazon EC2 ユーザーガイド*」の「[デフォルトでの暗号化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default)」を参照してください。

## [EC2.8] EC2 インスタンスは、インスタンスメタデータサービスバージョン 2 (IMDSv2) を使用することをお勧めします
<a name="ec2-8"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/5.7、CIS AWS Foundations Benchmark v3.0.0/5.6、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-6、PCI DSS v4.0.1/2.2.6

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-imdsv2-check.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-imdsv2-check.html)

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

**パラメータ:** なし

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

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

IMDS のバージョン 2 では、次の種類の脆弱性に対する新しい保護が追加されています。これらの脆弱性は IMDS へのアクセスに利用される可能性があります。
+ ウェブサイトアプリケーションのファイアウォールを開く
+ リバースプロキシを開く
+ サーバー側リクエスト偽造 (SSRF) の脆弱性
+ レイヤー 3 ファイアウォールおよびネットワークアドレス変換 (NAT) を開く

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

### 修正
<a name="ec2-8-remediation"></a>

EC2 インスタンスを IMDSv2 で設定するには、「[Amazon EC2 ユーザーガイド](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html#recommended-path-for-requiring-imdsv2)」の「*IMDSv2 を必要とする場合の推奨方法*」を参照してください。

## [EC2.9] Amazon EC2 インスタンスは、パブリック IPv4 アドレスを未設定にすることをお勧めします
<a name="ec2-9"></a>

**関連する要件:** NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-no-public-ip.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-no-public-ip.html)

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

**パラメータ:** なし

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

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

IPv6 アドレスはグローバルに一意であるため、インターネットから到達できます。ただし、デフォルトではすべてのサブネットで IPv6 アドレス指定属性が false に設定されています。VPC での IPv6 の詳細については、「Amazon VPC ユーザーガイド」の「[VPC での IP アドレス指定](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html)」を参照してください。

パブリック IP アドレスで EC2 インスタンスを維持する正当なユースケースがある場合は、このコントロールの結果を抑制できます。フロントエンドアーキテクチャオプションの詳細については、[AWS 「アーキテクチャブログ](https://aws.amazon.com/blogs/architecture/)」または[「This Is My Architecture series](https://aws.amazon.com/this-is-my-architecture/?tma.sort-by=item.additionalFields.airDate&tma.sort-order=desc&awsf.category=categories%23mobile) AWS video series」を参照してください。

### 修正
<a name="ec2-9-remediation"></a>

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

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

自動で割り当てられたパブリック IP アドレスを EC2 インスタンスから関連付け解除することができます。詳細については、「*Amazon EC2 ユーザーガイド*」の「[パブリック IPv4 アドレスと外部 DNS ホスト名](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-public-addresses)」を参照してください。

## [EC2.10] Amazon EC2 サービス用に作成された VPC エンドポイントを使用するようにAmazon EC2 を設定することをお勧めします
<a name="ec2-10"></a>

**関連する要件:** NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-171.r2 3.1.3、NIST.800-171.r2 3.13.1

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/service-vpc-endpoint-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/service-vpc-endpoint-enabled.html)

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

**パラメータ :** 
+ `serviceName`: `ec2` (カスタマイズ不可)

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

このコントロールは、単一のアカウントのリソースを評価します。アカウント外のリソースは記述できません。 AWS Config と Security Hub CSPM はクロスアカウントチェックを実行しないため、アカウント間で共有されている VPCs `FAILED`の検出結果が表示されます。Security Hub CSPM では、これらの`FAILED`検出結果を抑制することをお勧めします。

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

Amazon EC2 の VPC エンドポイントの作成の詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 とインターフェイス VPC エンドポイント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/interface-vpc-endpoints.html)」を参照してください。

### 修正
<a name="ec2-10-remediation"></a>

Amazon VPC コンソールから Amazon EC2 へのインターフェイスエンドポイントを作成するには、「*AWS PrivateLink ガイド*」の「[VPC エンドポイントの作成](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws)」を参照してください。**[サービス名]** で **[com.amazonaws.*region*.ec2]** を選択します。

また、エンドポイントポリシーを作成し、VPC エンドポイントにアタッチして Amazon EC2 API へのアクセスを制御することもできます。VPC エンドポイントポリシーを作成する手順については、「*Amazon EC2 ユーザーガイド*」の「[エンドポイントポリシーの作成](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/interface-vpc-endpoints.html#endpoint-policy)」を参照してください。

## [EC2.12] 未使用の Amazon EC2 EIP を削除することをお勧めします
<a name="ec2-12"></a>

**関連する要件:** PCI DSS v3.2.1/2.4、NIST.800-53.r5 CM-8(1)

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

**重要度:** 低

**リソースタイプ :** `AWS::EC2::EIP`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/eip-attached.html](https://docs.aws.amazon.com/config/latest/developerguide/eip-attached.html)

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

**パラメータ :** なし

このコントロールは、VPC に割り当てられた Elastic IP (EIP) アドレスが、 EC2 インスタンスまたは使用中の Elastic Network Interface (ENI) にアタッチされているかどうかを確認します。

検出に失敗した場合は、未使用の EC2 EIP がある可能性があります。

これにより、カード所有者データ環境 (CDE) 内の EIP のアセットインベントリを正確な状態に維持できます。

### 修正
<a name="ec2-12-remediation"></a>

未使用の EIP をリリースするには、「*Amazon EC2 ユーザーガイド*」の「[Elastic IP アドレスを解放する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html#using-instance-addressing-eips-releasing)」を参照してください。

## [EC2.13] セキュリティグループは、0.0.0.0/0 または ::/0 からポート 22 への入力を許可しないようにする必要があります
<a name="ec2-13"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/4.1、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 CM-7、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7800-53.r5 SC-7(5)、NIST.800-171

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/restricted-ssh.html](https://docs.aws.amazon.com/config/latest/developerguide/restricted-ssh.html)

**スケジュールタイプ:** 変更がトリガーされ、定期的に行われる場合

**パラメータ :** なし

このコントロールは、Amazon EC2 セキュリティグループが 0.0.0.0/0 または ::/0 からポート 22 への入力を許可しているかどうかをチェックします。セキュリティグループが 0.0.0.0/0 または ::/0 からポート 22 への入力を許可している場合、コントロールは失敗します。

セキュリティグループは、 AWS リソースへの入力および出力ネットワークトラフィックのステートフルフィルタリングを提供します。セキュリティグループはポート 22 への無制限の入力を許可しません。SSH などのリモートコンソールサービスへの自由な接続を制限することにより、サーバーがリスクにさらされることを軽減できます。

### 修正
<a name="ec2-13-remediation"></a>

ポート 22 への進入を禁止するには、VPC に関連付けられている各セキュリティグループにそのようなアクセスを許可するルールを削除します。手順については、「*Amazon EC2 ユーザーガイド*」の「[セキュリティグループのルールの更新](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#updating-security-group-rules)」を参照してください。Amazon EC2 コンソールでセキュリティグループを選択したら、**[アクション、インバウンドルールの編集]** を選択します。ポート 22 へのアクセスを許可するルールを削除します。

## [EC2.14] セキュリティグループは、0.0.0.0/0 または ::/0 からポート 3389 への入力を許可しないようにする必要があります
<a name="ec2-14"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/4.2、PCI DSS v4.0.1/1.3.1

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

**重要度:** 高

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

**AWS Config ルール:** [https://docs.aws.amazon.com/config/latest/developerguide/restricted-common-ports.html](https://docs.aws.amazon.com/config/latest/developerguide/restricted-common-ports.html) (作成されたルールは `restricted-rdp`)

**スケジュールタイプ:** 変更がトリガーされ、定期的に行われる場合

**パラメータ :** なし

このコントロールは、Amazon EC2 セキュリティグループが 0.0.0.0/0 または ::/0 からポート 3389 への入力を許可しているかどうかをチェックします。セキュリティグループが 0.0.0.0/0 または ::/0 からポート 3389 への入力を許可している場合、コントロールは失敗します。

セキュリティグループは、 AWS リソースへの入力および出力ネットワークトラフィックのステートフルフィルタリングを提供します。セキュリティグループはポート 3389 への無制限の入力を許可しません。RDP などのリモートコンソールサービスへの自由な接続を制限することにより、サーバーがリスクにさらされることを軽減できます。

### 修正
<a name="ec2-14-remediation"></a>

ポート 3389 への進入を禁止するには、VPC に関連付けられている各セキュリティグループにそのようなアクセスを許可するルールを削除します。手順については、「*Amazon VPC ユーザーガイド*」の「[Update security group rules](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html#updating-security-group-rules)」を参照してください。Amazon VPC コンソールでセキュリティグループを選択したら、**[アクション、インバウンドルールの編集]** を選択します。ポート 3389 へのアクセスを許可するルールを削除します。

## [EC2.15] Amazon EC2 サブネットは、パブリック IP アドレスを自動的に割り当てないことをお勧めします
<a name="ec2-15"></a>

**関連する要件:** NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)、PCI DSS v4.0.1/1.4.4

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/subnet-auto-assign-public-ip-disabled.html](https://docs.aws.amazon.com/config/latest/developerguide/subnet-auto-assign-public-ip-disabled.html)

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

**パラメータ :** なし

このコントロールは、Amazon Virtual Private Cloud (Amazon VPC) サブネットがパブリック IP アドレスを自動的に割り当てるように設定されているかどうかをチェックします。サブネットがパブリック IPv4 アドレスまたは IPv6 アドレスを自動的に割り当てるように設定されている場合、コントロールは失敗します。

サブネットには、ネットワークインターフェイスがパブリック IPv4 アドレスと IPv6 アドレスを自動的に受信するかどうかを決定する属性があります。IPv4 `TRUE`の場合、この属性はデフォルトサブネットの場合は に、デフォルト以外のサブネット`FALSE`の場合は に設定されます (EC2 インスタンス起動ウィザードで作成されたデフォルト以外のサブネットは例外で、 に設定されます`TRUE`)。IPv6 の場合、この属性はデフォルトですべてのサブネット`FALSE`に対して に設定されます。これらの属性を有効にすると、サブネットで起動されたインスタンスは、プライマリネットワークインターフェイスで対応する IP アドレス (IPv4 または IPv6) を自動的に受信します。

### 修正
<a name="ec2-15-remediation"></a>

パブリック IP アドレスを割り当てないようにサブネットを設定するには、「*Amazon VPC ユーザーガイド*」の「[サブネットの IP アドレス指定属性を変更する](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-public-ip.html)」を参照してください。

## [EC2.16] 未使用のネットワークアクセスコントロールリストを削除することをお勧めします
<a name="ec2-16"></a>

**関連する要件:** NIST.800-53.r5 CM-8(1)、NIST.800-171.r2 3.4.7、PCI DSS v4.0.1/1.2.7

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

**重要度:** 低

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-network-acl-unused-check.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-network-acl-unused-check.html)

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

**パラメータ :** なし

このコントロールは、仮想プライベートクラウド (VPC) に未使用のネットワークアクセスコントロールリスト (ネットワーク ACL) があるかどうかをチェックします。ネットワーク ACL がサブネットに関連付けられていない場合、コントロールは失敗します。コントロールは、未使用のデフォルトネットワーク ACL の検出結果を生成しません。

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

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

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

### 修正
<a name="ec2-16-remediation"></a>

未使用のネットワーク ACL を削除する方法については、「*Amazon VPC ユーザーガイド*」の「[ネットワーク ACL の削除](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#DeleteNetworkACL)」を参照してください。デフォルトのネットワーク ACL またはサブネットに関連付けられた ACL は削除できません。

## [EC2.17] Amazon EC2 インスタンスが複数の ENI を使用しないようにすることをお勧めします
<a name="ec2-17"></a>

**関連する要件:** NIST.800-53.r5 AC-4(21)

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

**重要度:** 低

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-multiple-eni-check.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-multiple-eni-check.html)

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

**パラメータ :** なし

このコントロールは、EC2 インスタンスが複数の Elastic Network Interface (ENI) または Elastic Fabric Adapter (EFA) を使用しているかどうかをチェックします。このコントロールは、単一のネットワークアダプタが使用されている場合に成功します。コントロールには、許可された ENI を識別するためのオプションのパラメータリストが含まれています。Amazon EKS クラスターに属する EC2 インスタンスが複数の ENI を使用している場合も、このコントロールは失敗します。EC2 インスタンスに Amazon EKS クラスターの一部として複数の ENI が必要な場合は、これらのコントロールの検出結果を抑制できます。

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

### 修正
<a name="ec2-17-remediation"></a>

EC2 インスタンスからネットワークインターフェイスをデタッチするには、「*Amazon EC2 ユーザーガイド*」の「[インスタンスからネットワークインターフェイスをデタッチする](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#detach_eni)」を参照してください。

## [EC2.18] セキュリティグループは、許可されたポートに対して無制限の着信トラフィックのみを許可することをお勧めします
<a name="ec2-18"></a>

**関連する要件:** NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(5)、NIST.800-171.r2 3.1.3、NIST.800-171.r2 3.1.20、NIST.800-171.r2 3.13.1

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-sg-open-only-to-authorized-ports.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-sg-open-only-to-authorized-ports.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `authorizedTcpPorts`  |  許可されている TCP ポートのリスト  |  IntegerList (最小 1 項目、最大 32 項目)  |  `1`～`65535`  |  `[80,443]`  | 
|  `authorizedUdpPorts`  |  許可されている UDP ポートのリスト  |  IntegerList (最小 1 項目、最大 32 項目)  |  `1`～`65535`  |  デフォルト値なし  | 

このコントロールは、Amazon EC2 セキュリティグループが、許可されていないポートからの無制限の着信トラフィックを許可しているかどうかをチェックします。コントロールのステータスは次のように決定されます。
+ `authorizedTcpPorts` のデフォルト値を使用する場合、セキュリティグループがポート 80 およびポート 443 以外のポートからの無制限の着信トラフィックを許可すると、コントロールは失敗します。
+ `authorizedTcpPorts` または `authorizedUdpPorts` にカスタム値を指定した場合、セキュリティグループがリストにないポートからの無制限の着信トラフィックを許可すると、コントロールは失敗します。

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

### 修正
<a name="ec2-18-remediation"></a>

セキュリティグループを変更するには、「*Amazon VPC ユーザーガイド*」の「[セキュリティグループの操作](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-groups.html)」を参照してください。

## [EC2.19] セキュリティグループは、リスクの高いポートへの無制限アクセスを許可してはいけません
<a name="ec2-19"></a>

**関連する要件:** NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)、NIST.800-53.r5 CM-7、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(5)、NIST.800-171.r2 3.1.3、NIST.800-171.r2 3.1.20、NIST.800-171.r2 3.13.1

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

**重要度:** 非常事態

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

**AWS Config ルール:** [https://docs.aws.amazon.com/config/latest/developerguide/restricted-common-ports.html](https://docs.aws.amazon.com/config/latest/developerguide/restricted-common-ports.html) (作成されたルールは `vpc-sg-restricted-common-ports`)

**スケジュールタイプ:** 変更がトリガーされ、定期的に行われる場合

**パラメータ:** `"blockedPorts": "20,21,22,23,25,110,135,143,445,1433,1434,3000,3306,3389,4333,5000,5432,5500,5601,8080,8088,8888,9200,9300"` (カスタマイズ不可)

このコントロールは、指定した高リスクと見なされるポートに Amazon EC2 セキュリティグループの無制限の受信トラフィックがアクセス可能かどうかをチェックします。セキュリティグループ内のルールがこれらのポートへの「0.0.0.0/0」または「::/0」からの入力トラフィックを許可している場合、このコントロールは失敗します。

セキュリティグループは、 AWS リソースへの入力および出力ネットワークトラフィックのステートフルフィルタリングを提供します。無制限のアクセス (0.0.0.0/0) では、ハッキング、サービス拒否攻撃、データ損失などの悪意のあるアクティビティの機会が増えます。どのセキュリティグループでも、以下のポートへの無制限の入力アクセスを許可してはいけません。
+ 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)

### 修正
<a name="ec2-19-remediation"></a>

セキュリティグループからルールを削除するには、「*Amazon EC2 ユーザーガイド*」の「[セキュリティグループからのルールの削除](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#deleting-security-group-rule)」を参照してください。

## [EC2.20] AWS Site-to-Site VPN トンネルが稼働している必要があります
<a name="ec2-20"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 SC-36、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)、NIST.800-171.r2 3.1.13、NIST.800-171.r2 3.1.20

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

**重要度:** 中 

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-vpn-2-tunnels-up.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-vpn-2-tunnels-up.html)

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

**パラメータ :** なし

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

このコントロールは、 AWS Site-to-Site VPN によって提供される両方の VPN トンネルが UP ステータスであることを確認します。一方または両方のトンネルのステータスが DOWN の場合、コントロールは失敗します。

### 修正
<a name="ec2-20-remediation"></a>

VPN トンネルオプションを変更するには、[Site-to-Site VPN ユーザーガイド」の「Site-to-Site VPN トンネルオプションの変更](https://docs.aws.amazon.com/vpn/latest/s2svpn/modify-vpn-tunnel-options.html)」を参照してください。 AWS Site-to-Site 

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

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/5.2、CIS AWS Foundations Benchmark v1.4.0/5.1、CIS AWS Foundations Benchmark v3.0.0/5.1、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)、NIST.800-53.r5 SCCM-7、NIST.800-53.r5 SC-7.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7-5 3.1.20

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

**重要度:** 中 

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/nacl-no-unrestricted-ssh-rdp.html](https://docs.aws.amazon.com/config/latest/developerguide/nacl-no-unrestricted-ssh-rdp.html)

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

**パラメータ :** なし

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

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

### 修正
<a name="ec2-21-remediation"></a>

ネットワーク ACL トラフィックルールを編集するには、「*Amazon VPC ユーザーガイド*」の「[ネットワーク ACL を操作する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#nacl-tasks)」を参照してください。

## [EC2.22] 未使用の Amazon EC2 セキュリティグループを削除することをお勧めします
<a name="ec2-22"></a>

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

**重要度:** 中 

**リソースタイプ:** `AWS::EC2::NetworkInterface`、`AWS::EC2::SecurityGroup`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-security-group-attached-to-eni-periodic.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-security-group-attached-to-eni-periodic.html)

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

**パラメータ :** なし

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

**重要**  
2023 年 9 月 20 日、Security Hub CSPM は AWS Foundational Security Best Practices および NIST SP 800-53 Revision 5 標準からこのコントロールを削除しました。このコントロールは、引き続き AWS Control Tower サービスマネージド標準の一部です。このコントロールでは、セキュリティグループが EC2 インスタンス、または Elastic Network Interface にアタッチされている場合に、合格の検出結果を生成します。ただし、特定のユースケースでは、セキュリティグループがアタッチされていなくてもセキュリティ上のリスクはありません。他の EC2 コントロール (EC2.2、EC2.13、EC2.14、EC2.18、EC2.19 など) を使用すると、セキュリティグループをモニタリングできます。

### 修正
<a name="ec2-22-remediation"></a>

セキュリティグループを作成、割り当て、削除するには、「*Amazon EC2 ユーザーガイド*」の「[EC2 インスタンスのセキュリティグループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html)」を参照してください。

## [EC2.23] Amazon EC2 Transit Gateway が VPC アタッチメントリクエストを自動的に受け付けないようにすることをお勧めします
<a name="ec2-23"></a>

**関連する要件:** NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2

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

**重要度:** 高 

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-transit-gateway-auto-vpc-attach-disabled.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-transit-gateway-auto-vpc-attach-disabled.html)

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

**パラメータ :** なし

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

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

### 修正
<a name="ec2-23-remediation"></a>

中継ゲートウェイを変更するには、「Amazon VPC デベロッパーガイド」の「[中継ゲートウェイの変更](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html#tgw-modifying)」を参照してください。

## [EC2.24] Amazon EC2 準仮想化インスタンスタイプを使用しないことをお勧めします
<a name="ec2-24"></a>

**関連する要件:** NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)

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

**重要度:** 中 

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-paravirtual-instance-check.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-paravirtual-instance-check.html)

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

**パラメータ :** なし

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

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

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

### 修正
<a name="ec2-24-remediation"></a>

EC2 インスタンスを新しいインスタンスタイプに更新するには、「*Amazon EC2 ユーザーガイド*」の「[インスタンスタイプを変更する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-resize.html)」を参照してください。

## [EC2.25] Amazon EC2 起動テンプレートがパブリック IP をネットワークインターフェイスに割り当てないようにすることをお勧めします
<a name="ec2-25"></a>

**関連する要件:** NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)、PCI DSS v4.0.1/1.4.4

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

**重要度:** 高 

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-launch-template-public-ip-disabled.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-launch-template-public-ip-disabled.html)

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

**パラメータ :** なし

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

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

### 修正
<a name="ec2-25-remediation"></a>

EC2 起動テンプレートを更新するには、「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[デフォルトのネットワークインターフェイス設定を変更する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html#change-network-interface)」を参照してください。

## [EC2.28] EBS ボリュームをバックアッププランの対象にすることをお勧めします
<a name="ec2-28"></a>

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

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6、NIST.800-53.r5 CP-6(1)、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 CP-9、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-12、NIST.800-53.r5 SI-13(5)

**重要度:** 低

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

**AWS Config ルール:** [https://docs.aws.amazon.com/config/latest/developerguide/ebs-resources-protected-by-backup-plan.html](https://docs.aws.amazon.com/config/latest/developerguide/ebs-resources-protected-by-backup-plan.html) ``

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `backupVaultLockCheck`  |  パラメータが `true` に設定されていて、リソースが AWS Backup Vault Lock を使用している場合、コントロールは `PASSED` 検出結果を生成します。  |  ブール値  |  `true` 、、または `false`  |  デフォルト値なし  | 

このコントロールは、`in-use` 状態の Amazon EBS ボリュームがバックアッププランの対象になっているかどうかを評価します。EBS ボリュームがバックアッププランの対象でない場合、コントロールは失敗します。`backupVaultLockCheck` パラメータを に設定すると`true`、EBS ボリュームが AWS Backup ロックされたボールトにバックアップされている場合にのみコントロールが成功します。

バックアップは、セキュリティインシデントからより迅速に復元するために役立ちます。また、システムの耐障害性を強化します。バックアッププランに Amazon EBS ボリュームを含めると、意図しない損失や削除からデータを保護できます。

### 修正
<a name="ec2-28-remediation"></a>

Amazon EBS ボリュームを AWS Backup バックアッププランに追加するには、「 *AWS Backup デベロッパーガイド*[」の「バックアッププランへのリソースの割り当て](https://docs.aws.amazon.com/aws-backup/latest/devguide/assigning-resources.html)」を参照してください。

## [EC2.33] EC2 Transit Gateway アタッチメントにはタグを付ける必要があります
<a name="ec2-33"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::EC2::TransitGatewayAttachment`

**AWS Config rule:** `tagged-ec2-transitgatewayattachment` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon EC2 Transit Gateway アタッチメントに、パラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。Transit Gateway アタッチメントにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、トランジットゲートウェイアタッチメントにキーがタグ付けされていない場合に失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くの がアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「*AWS 全般のリファレンス*」の「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。

### 修正
<a name="ec2-33-remediation"></a>

EC2 Transit Gateway アタッチメントにタグを追加するには、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)」を参照してください。

## [EC2.34] EC2 Transit Gateway ルートテーブルにはタグを付ける必要があります
<a name="ec2-34"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::EC2::TransitGatewayRouteTable`

**AWS Config rule:** `tagged-ec2-transitgatewayroutetable` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon EC2 トランジットゲートウェイルートテーブルに、パラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。トランジットゲートウェイルートテーブルにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、トランジットゲートウェイルートテーブルにキーがタグ付けされていない場合に失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くの がアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「*AWS 全般のリファレンス*」の「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。

### 修正
<a name="ec2-34-remediation"></a>

EC2 トランジットゲートウェイルートテーブルにタグを追加するには、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)」を参照してください。

## [EC2.35] EC2 ネットワークインターフェイスにはタグを付ける必要があります
<a name="ec2-35"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::EC2::NetworkInterface`

**AWS Config rule:** `tagged-ec2-networkinterface` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon EC2 ネットワークインターフェイスにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。ネットワークインターフェイスにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ネットワークインターフェイスにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くの がアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「*AWS 全般のリファレンス*」の「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。

### 修正
<a name="ec2-35-remediation"></a>

EC2 ネットワークインターフェイスにタグを追加するには、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)」を参照してください。

## [EC2.36] EC2 カスタマーゲートウェイにはタグを付ける必要があります
<a name="ec2-36"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::EC2::CustomerGateway`

**AWS Config rule:** `tagged-ec2-customergateway` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon EC2 カスタマーゲートウェイにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。カスタマーゲートウェイにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、カスタマーゲートウェイにキーがタグ付けされていない場合に失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くの がアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「*AWS 全般のリファレンス*」の「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。

### 修正
<a name="ec2-36-remediation"></a>

EC2 カスタマーゲートウェイにタグを追加するには、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)」を参照してください。

## [EC2.37] EC2 Elastic IP アドレスにはタグを付ける必要があります
<a name="ec2-37"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::EC2::EIP`

**AWS Config rule:** `tagged-ec2-eip` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon EC2 Elastic IP アドレスに、パラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。Elastic IP アドレスにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、Elastic IP アドレスにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くの がアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「*AWS 全般のリファレンス*」の「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。

### 修正
<a name="ec2-37-remediation"></a>

EC2 Elastic IP アドレスにタグを追加するには、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)」を参照してください。

## [EC2.38] EC2 インスタンスにはタグを付ける必要があります
<a name="ec2-38"></a>

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

**重要度:** 低

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

**AWS Config rule:** `tagged-ec2-instance` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon EC2 インスタンスにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。インスタンスにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、インスタンスにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くの がアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「*AWS 全般のリファレンス*」の「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。

### 修正
<a name="ec2-38-remediation"></a>

EC2 インスタンスにタグを追加するには、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)」を参照してください。

## [EC2.39] EC2 インターネットゲートウェイにはタグを付ける必要があります
<a name="ec2-39"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::EC2::InternetGateway`

**AWS Config rule:** `tagged-ec2-internetgateway` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon EC2 インターネットゲートウェイにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。インターネットゲートウェイにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、インターネットゲートウェイにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くの がアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「*AWS 全般のリファレンス*」の「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。

### 修正
<a name="ec2-39-remediation"></a>

EC2 インターネットゲートウェイにタグを追加するには、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)」を参照してください。

## [EC2.40] EC2 NAT ゲートウェイにはタグを付ける必要があります
<a name="ec2-40"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::EC2::NatGateway`

**AWS Config rule:** `tagged-ec2-natgateway` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon EC2 ネットワークアドレス変換 (NAT) ゲートウェイに、パラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。NAT ゲートウェイにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、NAT ゲートウェイにキーがタグ付けされていない場合に失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くの がアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「*AWS 全般のリファレンス*」の「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。

### 修正
<a name="ec2-40-remediation"></a>

EC2 NAT ゲートウェイにタグを追加するには、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)」を参照してください。

## [EC2.41] EC2 ネットワーク ACL にはタグを付ける必要があります
<a name="ec2-41"></a>

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

**重要度:** 低

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

**AWS Config rule:** `tagged-ec2-networkacl` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon EC2 ネットワークアクセスコントロールリスト (ネットワーク ACL) に、`requiredTagKeys` パラメータで定義された特定のキーを持つタグがあるかどうかをチェックします。ネットワーク ACL にタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ネットワーク ACL にキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くの がアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「*AWS 全般のリファレンス*」の「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。

### 修正
<a name="ec2-41-remediation"></a>

EC2 ネットワーク ACL にタグを追加するには、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)」を参照してください。

## [EC2.42] EC2 ルートテーブルにはタグを付ける必要があります
<a name="ec2-42"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::EC2::RouteTable`

**AWS Config rule:** `tagged-ec2-routetable` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon EC2 ルートテーブルに、パラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。ルートテーブルにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ルートテーブルにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くの がアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「*AWS 全般のリファレンス*」の「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。

### 修正
<a name="ec2-42-remediation"></a>

EC2 ルートテーブルにタグを追加するには、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)」を参照してください。

## [EC2.43] EC2 セキュリティグループにはタグを付ける必要があります
<a name="ec2-43"></a>

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

**重要度:** 低

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

**AWS Config rule:** `tagged-ec2-securitygroup` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon EC2 セキュリティグループにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。セキュリティグループにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、セキュリティグループがキーでタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くの がアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「*AWS 全般のリファレンス*」の「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。

### 修正
<a name="ec2-43-remediation"></a>

EC2 セキュリティグループにタグを追加するには、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースにタグを付ける](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)」を参照してください。

## [EC2.44] EC2 サブネットにはタグを付ける必要があります
<a name="ec2-44"></a>

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

**重要度:** 低

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

**AWS Config rule:** `tagged-ec2-subnet` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon EC2 サブネットにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。サブネットにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、サブネットにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くの がアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「*AWS 全般のリファレンス*」の「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。

### 修正
<a name="ec2-44-remediation"></a>

EC2 サブネットにタグを追加するには、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)」を参照してください。

## [EC2.45] EC2 ボリュームにはタグを付ける必要があります
<a name="ec2-45"></a>

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

**重要度:** 低

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

**AWS Config rule:** `tagged-ec2-volume` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon EC2 ボリュームにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。ボリュームにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ボリュームにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くの がアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「*AWS 全般のリファレンス*」の「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。

### 修正
<a name="ec2-45-remediation"></a>

EC2 ボリュームにタグを追加するには、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)」を参照してください。

## [EC2.46] Amazon VPC にはタグを付ける必要があります
<a name="ec2-46"></a>

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

**重要度:** 低

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

**AWS Config rule:** `tagged-ec2-vpc` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon Virtual Private Cloud (Amazon VPC) に、 パラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。Amazon VPC にタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、Amazon VPC にキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くの がアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「*AWS 全般のリファレンス*」の「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。

### 修正
<a name="ec2-46-remediation"></a>

VPC にタグを追加するには、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)」を参照してください。

## [EC2.47] Amazon VPC エンドポイントサービスはタグを付ける必要があります
<a name="ec2-47"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::EC2::VPCEndpointService`

**AWS Config rule:** `tagged-ec2-vpcendpointservice` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon VPC エンドポイントサービスにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。エンドポイントサービスにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、エンドポイントサービスにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くの がアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「*AWS 全般のリファレンス*」の「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。

### 修正
<a name="ec2-47-remediation"></a>

Amazon VPC エンドポイントサービスにタグを追加するには、「*AWS PrivateLink ガイド*」の「[エンドポイントサービスの設定](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html)」セクションの「[タグの管理](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html#add-remove-endpoint-service-tags)」を参照してください。

## [EC2.48] Amazon VPC フローログにはタグを付ける必要があります
<a name="ec2-48"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::EC2::FlowLog`

**AWS Config rule:** `tagged-ec2-flowlog` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon VPC フローログにパラメータ `requiredTagKeys` で定義された特定のキーを含むタグがあるかどうかをチェックします。フローログにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、フローログにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くの がアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「*AWS 全般のリファレンス*」の「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。

### 修正
<a name="ec2-48-remediation"></a>

Amazon VPC フローログにタグを追加するには、「*Amazon VPC ユーザーガイド*」の「[フローログのタグ付け](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-flow-logs.html#modify-tags-flow-logs)」を参照してください。

## [EC2.49] Amazon VPC ピアリング接続にはタグを付ける必要があります
<a name="ec2-49"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::EC2::VPCPeeringConnection`

**AWS Config rule:** `tagged-ec2-vpcpeeringconnection` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon VPC ピアリング接続に、パラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。ピアリング接続にタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ピアリング接続にどのキーもタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くの がアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「*AWS 全般のリファレンス*」の「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。

### 修正
<a name="ec2-49-remediation"></a>

Amazon VPC ピアリング接続にタグを追加するには、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)」を参照してください。

## [EC2.50] EC2 VPN ゲートウェイにはタグを付ける必要があります
<a name="ec2-50"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::EC2::VPNGateway`

**AWS Config rule:** `tagged-ec2-vpngateway` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon EC2 VPN ゲートウェイにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。VPN ゲートウェイにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、VPN ゲートウェイにキーがタグ付けされていない場合に失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くの がアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「*AWS 全般のリファレンス*」の「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。

### 修正
<a name="ec2-50-remediation"></a>

EC2 VPN ゲートウェイにタグを追加するには、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)」を参照してください。

## [EC2.51] EC2 Client VPN エンドポイントでは、クライアント接続ログ記録が有効になっている必要があります
<a name="ec2-51"></a>

**関連する要件:** NIST.800-53.r5 AC-2(12)、NIST.800-53.r5 AC-2(4)、NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AC-6(9)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 AU-9(7)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4、NIST.800-53.r5 SI-4(20)、NIST.800-53.r5 SI-7(8)、NIST.800-171.r2 3.1.12、NIST.800-171.r2 3.1.20、PCI DSS v4.0.1/10.2.1

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

**重要度:** 低

**リソースタイプ :** `AWS::EC2::ClientVpnEndpoint`

**AWS Config ルール:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-client-vpn-connection-log-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-client-vpn-connection-log-enabled.html) ``

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

**パラメータ :** なし

このコントロールは、 AWS Client VPN エンドポイントでクライアント接続のログ記録が有効になっているかどうかを確認します。エンドポイントでクライアント接続ログ記録が有効になっていない場合、コントロールは失敗します。

Client VPN エンドポイントにより、リモートクライアントは AWSの仮想プライベートクラウド (VPC) 内のリソースに安全に接続できます。接続ログにより、VPN エンドポイントでのユーザーアクティビティを追跡し、可視化することができます。接続ログを有効にすると、ロググループ内のログストリームの名前を指定できます。ログストリームを指定しない場合、クライアント VPN サービスによって自動的に作成されます。

### 修正
<a name="ec2-51-remediation"></a>

接続ログ記録を有効にするには、「*AWS Client VPN 管理者ガイド*」の「[既存のクライアント VPN エンドポイントの接続ログを有効にする](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/cvpn-working-with-connection-logs.html#create-connection-log-existing)」を参照してください。

## [EC2.52] EC2 Transit Gateway にはタグを付ける必要があります
<a name="ec2-52"></a>

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

**重要度:** 低

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

**AWS Config rule:** `tagged-ec2-transitgateway` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、Amazon EC2 トランジットゲートウェイにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。トランジットゲートウェイにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、トランジットゲートウェイにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くの がアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「*AWS 全般のリファレンス*」の「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。

### 修正
<a name="ec2-52-remediation"></a>

EC2 トランジットゲートウェイにタグを追加するには、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースにタグを付ける](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)」を参照してください。

## [EC2.53] EC2 セキュリティグループが 0.0.0.0/0 からリモートサーバー管理ポートへの入力を許可することがないようにする必要があります
<a name="ec2-53"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/5.3、CIS AWS Foundations Benchmark v3.0.0/5.2、PCI DSS v4.0.1/1.3.1

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-sg-port-restriction-check.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-sg-port-restriction-check.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `ipType`  |  IP バージョン  |  String  |  カスタマイズ不可  |  `IPv4`  | 
|  `restrictPorts`  |  入力トラフィックを拒否するポートのリスト  |  IntegerList  |  カスタマイズ不可  |  `22,3389`  | 

このコントロールは、Amazon EC2 セキュリティグループが 0.0.0.0/0 からリモートサーバー管理ポート (ポート 22 と 3389 ) への入力を許可しているかどうかをチェックします。セキュリティグループが 0.0.0.0/0 からポート 22 または 3389 への入力を許可している場合、コントロールは失敗します。

セキュリティグループは、 AWS リソースへの入力および出力ネットワークトラフィックのステートフルフィルタリングを提供します。TDP (6)、UDP (17)、または ALL (-1) プロトコルのいずれかを使用して、SSH からポート 22、RDP からポート 3389 などのリモートサーバー管理ポートへの無制限の入力アクセスをセキュリティグループで許可しないことをお勧めします。これらのポートへのパブリックアクセスを許可すると、リソースのアタックサーフェスが増加し、リソースが侵害されるリスクが高まります。

### 修正
<a name="ec2-53-remediation"></a>

指定されたポートへの入力トラフィックを禁止するように EC2 セキュリティグループルールを更新するには、「*Amazon EC2 ユーザーガイド*」の「[セキュリティグループルールの更新](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#updating-security-group-rules)」を参照してください。Amazon EC2 コンソールでセキュリティグループを選択したら、**[アクション、インバウンドルールの編集]** を選択します。ポート 22 または 3389 へのアクセスを許可するルールを削除します。

## [EC2.54] EC2 セキュリティグループは ::/0 からリモートサーバー管理ポートへの入力を許可しない必要があります
<a name="ec2-54"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/5.4、CIS AWS Foundations Benchmark v3.0.0/5.3、PCI DSS v4.0.1/1.3.1

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-sg-port-restriction-check.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-sg-port-restriction-check.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `ipType`  |  IP バージョン  |  String  |  カスタマイズ不可  |  `IPv6`  | 
|  `restrictPorts`  |  入力トラフィックを拒否するポートのリスト  |  IntegerList  |  カスタマイズ不可  |  `22,3389`  | 

このコントロールは、Amazon EC2 セキュリティグループが ::/0 からリモートサーバー管理ポート (ポート 22 および 3389) への入力を許可するかどうかをチェックします。セキュリティグループが ::/0 からポート 22 または 3389 への入力を許可している場合、コントロールは失敗します。

セキュリティグループは、 AWS リソースへの入力および出力ネットワークトラフィックのステートフルフィルタリングを提供します。TDP (6)、UDP (17)、または ALL (-1) プロトコルのいずれかを使用して、SSH からポート 22、RDP からポート 3389 などのリモートサーバー管理ポートへの無制限の入力アクセスをセキュリティグループで許可しないことをお勧めします。これらのポートへのパブリックアクセスを許可すると、リソースのアタックサーフェスが増加し、リソースが侵害されるリスクが高まります。

### 修正
<a name="ec2-54-remediation"></a>

指定されたポートへの入力トラフィックを禁止するように EC2 セキュリティグループルールを更新するには、「*Amazon EC2 ユーザーガイド*」の「[セキュリティグループルールの更新](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#updating-security-group-rules)」を参照してください。Amazon EC2 コンソールでセキュリティグループを選択したら、**[アクション、インバウンドルールの編集]** を選択します。ポート 22 または 3389 へのアクセスを許可するルールを削除します。

## [EC2.55] VPC は ECR API のインターフェイスエンドポイントで設定する必要があります
<a name="ec2-55"></a>

**関連する要件:** NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)

**カテゴリ:** 保護 > セキュアなアクセス管理 > アクセスコントロール

**重要度:** 中

**リソースタイプ:** `AWS::EC2::VPC`、`AWS::EC2::VPCEndpoint`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-endpoint-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-endpoint-enabled.html)

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

**パラメータ :**


| [Parameter] (パラメータ) | [Required] (必須) | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | --- | 
| serviceNames  | 必須  | コントロールが評価するサービスの名前  | String  | カスタマイズ不可  | ecr.api | 
| vpcIds  | オプションです。 | VPC エンドポイントの Amazon VPC ID のカンマ区切りリスト。指定した場合、serviceName パラメータで指定されたサービスにこれらの VPC エンドポイントのいずれかがないと、コントロールは失敗します。 | StringList  | 1 つ以上の VPC ID を使用したカスタマイズ  | デフォルト値なし  | 

このコントロールは、管理する仮想プライベートクラウド (VPC) に Amazon ECR API のインターフェイス VPC エンドポイントがあるかどうかをチェックします。VPC に ECR API のインターフェイス VPC エンドポイントがない場合、コントロールは失敗します。このコントロールは、単一のアカウントのリソースを評価します。

AWS PrivateLink を使用すると、お客様はネットワーク内のすべてのネットワークトラフィックを維持しながら、高可用性でスケーラブルな方法で AWS でホストされているサービスにアクセスできます AWS 。サービスユーザーは、パブリック IP を使用せず、トラフィックをインターネット経由にする必要なく、VPC またはオンプレミスから PrivateLink を利用したサービスにプライベートにアクセスできます。

### 修正
<a name="ec2-55-remediation"></a>

VPC エンドポイントを設定するには、「 *AWS PrivateLink ガイド*」の[「インターフェイス VPC エンドポイント AWS のサービス を使用して にアクセスする](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)」を参照してください。

## [EC2.56] VPC は Docker Registry のインターフェイスエンドポイントで設定する必要があります
<a name="ec2-56"></a>

**関連する要件:** NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)

**カテゴリ:** 保護 > セキュアなアクセス管理 > アクセスコントロール

**重要度:** 中

**リソースタイプ:** `AWS::EC2::VPC`、`AWS::EC2::VPCEndpoint`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-endpoint-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-endpoint-enabled.html)

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

**パラメータ :**


| [Parameter] (パラメータ) | [Required] (必須) | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | --- | 
| serviceNames  | 必須  | コントロールが評価するサービスの名前  | String  | カスタマイズ不可  | ecr.dkr | 
| vpcIds  | オプションです。 | VPC エンドポイントの Amazon VPC ID のカンマ区切りリスト。指定した場合、serviceName パラメータで指定されたサービスにこれらの VPC エンドポイントのいずれかがないと、コントロールは失敗します。 | StringList  | 1 つ以上の VPC ID を使用したカスタマイズ  | デフォルト値なし  | 

このコントロールは、管理する仮想プライベートクラウド (VPC) に Docker レジストリのインターフェイス VPC エンドポイントがあるかどうかをチェックします。VPC に Docker レジストリのインターフェイス VPC エンドポイントがない場合、コントロールは失敗します。このコントロールは、単一のアカウントのリソースを評価します。

AWS PrivateLink を使用すると、お客様はネットワーク内のすべてのネットワークトラフィックを維持しながら、高可用性でスケーラブルな方法で AWS でホストされているサービスにアクセスできます AWS 。サービスユーザーは、パブリック IP を使用せず、トラフィックをインターネット経由にする必要なく、VPC またはオンプレミスから PrivateLink を利用したサービスにプライベートにアクセスできます。

### 修正
<a name="ec2-56-remediation"></a>

VPC エンドポイントを設定するには、「 *AWS PrivateLink ガイド*」の[「インターフェイス VPC エンドポイント AWS のサービス を使用して にアクセスする](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)」を参照してください。

## [EC2.57] VPC は Systems Manager のインターフェイスエンドポイントで設定する必要があります
<a name="ec2-57"></a>

**関連する要件:** NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)

**カテゴリ:** 保護 > セキュアなアクセス管理 > アクセスコントロール

**重要度:** 中

**リソースタイプ:** `AWS::EC2::VPC`、`AWS::EC2::VPCEndpoint`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-endpoint-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-endpoint-enabled.html)

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

**パラメータ :**


| [Parameter] (パラメータ) | [Required] (必須) | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | --- | 
| serviceNames  | 必須  | コントロールが評価するサービスの名前  | String  | カスタマイズ不可  | ssm | 
| vpcIds  | オプションです。 | VPC エンドポイントの Amazon VPC ID のカンマ区切りリスト。指定した場合、serviceName パラメータで指定されたサービスにこれらの VPC エンドポイントのいずれかがないと、コントロールは失敗します。 | StringList  | 1 つ以上の VPC ID を使用したカスタマイズ  | デフォルト値なし  | 

このコントロールは、管理する仮想プライベートクラウド (VPC) に AWS Systems Managerのインターフェイス VPC エンドポイントがあるかどうかをチェックします。VPC に Systems Manager のインターフェイス VPC エンドポイントがない場合、コントロールは失敗します。このコントロールは、単一のアカウントのリソースを評価します。

AWS PrivateLink を使用すると、お客様はネットワーク内のすべてのネットワークトラフィックを維持しながら、高可用性でスケーラブルな方法で AWS でホストされているサービスにアクセスできます AWS 。サービスユーザーは、パブリック IP を使用せず、トラフィックをインターネット経由にする必要なく、VPC またはオンプレミスから PrivateLink を利用したサービスにプライベートにアクセスできます。

### 修正
<a name="ec2-57-remediation"></a>

VPC エンドポイントを設定するには、「 *AWS PrivateLink ガイド*」の[「インターフェイス VPC エンドポイント AWS のサービス を使用して にアクセスする](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)」を参照してください。

## [EC2.58] VPC は、Systems Manager Incident Manager Contacts のインターフェイスエンドポイントで設定する必要があります
<a name="ec2-58"></a>

**関連する要件:** NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)

**カテゴリ:** 保護 > セキュアなアクセス管理 > アクセスコントロール

**重要度:** 中

**リソースタイプ:** `AWS::EC2::VPC`、`AWS::EC2::VPCEndpoint`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-endpoint-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-endpoint-enabled.html)

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

**パラメータ :**


| [Parameter] (パラメータ) | [Required] (必須) | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | --- | 
| serviceNames  | 必須  | コントロールが評価するサービスの名前  | String  | カスタマイズ不可  | ssm-contacts | 
| vpcIds  | オプションです。 | VPC エンドポイントの Amazon VPC ID のカンマ区切りリスト。指定した場合、serviceName パラメータで指定されたサービスにこれらの VPC エンドポイントのいずれかがないと、コントロールは失敗します。 | StringList  | 1 つ以上の VPC ID を使用したカスタマイズ  | デフォルト値なし  | 

このコントロールは、管理する Virtual Private Cloud (VPC) に AWS Systems Manager Incident Manager Contacts のインターフェイス VPC エンドポイントがあるかどうかをチェックします。VPC に Systems Manager Incident Manager Contacts のインターフェイス VPC エンドポイントがない場合、コントロールは失敗します。このコントロールは、単一のアカウントのリソースを評価します。

AWS PrivateLink を使用すると、お客様はネットワーク内のすべてのネットワークトラフィックを維持しながら、高可用性でスケーラブルな方法で AWS でホストされているサービスにアクセスできます AWS 。サービスユーザーは、パブリック IP を使用せず、トラフィックをインターネット経由にする必要なく、VPC またはオンプレミスから PrivateLink を利用したサービスにプライベートにアクセスできます。

### 修正
<a name="ec2-58-remediation"></a>

VPC エンドポイントを設定するには、「 *AWS PrivateLink ガイド*」の[「インターフェイス VPC エンドポイント AWS のサービス を使用して にアクセスする](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)」を参照してください。

## [EC2.60] VPC は Systems Manager Incident Manager のインターフェイスエンドポイントで設定する必要があります
<a name="ec2-60"></a>

**関連する要件:** NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)

**カテゴリ:** 保護 > セキュアなアクセス管理 > アクセスコントロール

**重要度:** 中

**リソースタイプ:** `AWS::EC2::VPC`、`AWS::EC2::VPCEndpoint`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-endpoint-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-endpoint-enabled.html)

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

**パラメータ :**


| [Parameter] (パラメータ) | [Required] (必須) | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | --- | 
| serviceNames  | 必須  | コントロールが評価するサービスの名前  | String  | カスタマイズ不可  | ssm-incidents | 
| vpcIds  | オプションです。 | VPC エンドポイントの Amazon VPC ID のカンマ区切りリスト。指定した場合、serviceName パラメータで指定されたサービスにこれらの VPC エンドポイントのいずれかがないと、コントロールは失敗します。 | StringList  | 1 つ以上の VPC ID を使用したカスタマイズ  | デフォルト値なし  | 

このコントロールは、管理する仮想プライベートクラウド (VPC) に AWS Systems Manager Incident Manager のインターフェイス VPC エンドポイントがあるかどうかをチェックします。VPC に Systems Manager Incident Manager のインターフェイス VPC エンドポイントがない場合、コントロールは失敗します。このコントロールは、単一のアカウントのリソースを評価します。

AWS PrivateLink を使用すると、お客様はネットワーク内のすべてのネットワークトラフィックを維持しながら、高可用性でスケーラブルな方法で AWS でホストされているサービスにアクセスできます AWS 。サービスユーザーは、パブリック IP を使用せず、トラフィックをインターネット経由にする必要なく、VPC またはオンプレミスから PrivateLink を利用したサービスにプライベートにアクセスできます。

### 修正
<a name="ec2-60-remediation"></a>

VPC エンドポイントを設定するには、「 *AWS PrivateLink ガイド*」の[「インターフェイス VPC エンドポイント AWS のサービス を使用して にアクセスする](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)」を参照してください。

## [EC2.170] EC2 起動テンプレートは、インスタンスメタデータサービスバージョン 2 (IMDSv2) を使用することをお勧めします
<a name="ec2-170"></a>

**関連する要件:** PCI DSS v4.0.1/2.2.6

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

**重要度:** 低

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-launch-template-imdsv2-check.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-launch-template-imdsv2-check.html)

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

**パラメータ :** なし

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

サポートされているソフトウェアバージョンでリソースを実行すると、最適なパフォーマンス、セキュリティ、最新機能へのアクセスが保証されます。定期的な更新は脆弱性から保護するため、安定した効率的なユーザーエクスペリエンスを確保できます。

### 修正
<a name="ec2-170-remediation"></a>

EC2 起動テンプレートで IMDSv2 を要求するには、「*Amazon EC2 ユーザーガイド*」の「[インスタンスメタデータサービスオプションの設定](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html)」を参照してください。

## [EC2.171] EC2 VPN 接続では、ログ記録が有効になっている必要があります
<a name="ec2-171"></a>

**関連する要件:** CIS AWS Foundations Benchmark v3.0.0/5.3、PCI DSS v4.0.1/10.4.2

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-vpn-connection-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-vpn-connection-logging-enabled.html)

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

**パラメータ :** なし

このコントロールは、 AWS Site-to-Site VPN 接続で両方のトンネルに対して Amazon CloudWatch Logs が有効になっているかどうかを確認します。Site-to-Site VPN 接続で両方のトンネルで CloudWatch Logs が有効になっていない場合、コントロールは失敗します。

AWS Site-to-Site VPN ログを使用すると、Site-to-Site VPN デプロイをより詳細に把握できます。この機能を使用すると、IP セキュリティ (IPsec)トンネル確立、インターネットキー交換 (IKE) ネゴシエーション、およびデッドピア検出 (DPD) プロトコルメッセージの詳細を示す Site-to-Site VPN 接続ログにアクセスできます。Site-to-Site VPN ログは CloudWatch Logs に発行できます。この機能により、単一の一貫した方法で、すべての Site-to-Site VPN 接続の詳細なログにアクセスして分析できます。

### 修正
<a name="ec2-171-remediation"></a>

EC2 VPN 接続でトンネルログ記録を有効にするには、「*AWS Site-to-Site VPN ユーザーガイド*」の「[AWS Site-to-Site VPN ログ](https://docs.aws.amazon.com/vpn/latest/s2svpn/monitoring-logs.html#enable-logs)」を参照してください。

## [EC2.172] EC2 VPC パブリックアクセスのブロック設定はインターネットゲートウェイトラフィックをブロックする必要があります
<a name="ec2-172"></a>

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

**重要度:** 中

**リソースタイプ :** `AWS::EC2::VPCBlockPublicAccessOptions`

**AWS Config rule:** `ec2-vpc-bpa-internet-gateway-blocked` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `vpcBpaInternetGatewayBlockMode`  |  VPC BPA オプションモードの文字列値。  |  列挙型  |  `block-bidirectional`, `block-ingress`  |  デフォルト値なし  | 

このコントロールは、Amazon EC2 VPC ブロックパブリックアクセス (BPA) 設定が、 AWS アカウント内のすべての Amazon VPC のインターネットゲートウェイトラフィックをブロックするように設定されているかどうかをチェックします。VPC BPA 設定がインターネットゲートウェイトラフィックをブロックするように設定されていない場合、コントロールは失敗します。コントロールを成功させるには、VPC BPA `InternetGatewayBlockMode` を `block-bidirectional` または `block-ingress` に設定する必要があります。パラメータ `vpcBpaInternetGatewayBlockMode` が指定されている場合、コントロールは `InternetGatewayBlockMode` の VPC BPA 値がパラメータと一致するときのみ成功します。

でアカウントの VPC BPA 設定 AWS リージョン を構成すると、そのリージョンで所有している VPCs とサブネットのリソースが、インターネットゲートウェイと Egress-Only インターネットゲートウェイを介してインターネットに到達したり、インターネットから到達したりすることをブロックできます。特定の VPC とサブネットがインターネットに到達したり、インターネットから到達されたりできるようにする必要がある場合は、VPC BPA 除外を設定することでそれらを除外できます。除外の作成と削除の手順については、「*Amazon VPC ユーザーガイド*」の「[除外を作成および削除する](https://docs.aws.amazon.com/vpc/latest/userguide/security-vpc-bpa-basics.html#security-vpc-bpa-exclusions)」を参照してください。

### 修正
<a name="ec2-172-remediation"></a>

アカウントレベルで双方向 BPA を有効にするには、「*Amazon VPC ユーザーガイド*」の「[アカウントのために VPC BPA 双方向モードを有効にする](https://docs.aws.amazon.com/vpc/latest/userguide/security-vpc-bpa-basics.html#security-vpc-bpa-enable-bidir)」を参照してください。イングレスのみの BPA を有効にするには、「[VPC BPA モードをイングレスのみに変更する](https://docs.aws.amazon.com/vpc/latest/userguide/security-vpc-bpa-basics.html#security-vpc-bpa-ingress-only)」を参照してください。組織レベルで VPC BPA を有効にするには、「[組織レベルで VPC BPA を有効にする](https://docs.aws.amazon.com/vpc/latest/userguide/security-vpc-bpa-basics.html#security-vpc-bpa-exclusions-orgs)」を参照してください。

## [EC2.173] 起動パラメータを含む EC2 スポットフリートリクエストは、アタッチされた EBS ボリュームの暗号化を有効にする必要があります
<a name="ec2-173"></a>

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

**重要度:** 中

**リソースタイプ :** `AWS::EC2::SpotFleet`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-spot-fleet-request-ct-encryption-at-rest.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-spot-fleet-request-ct-encryption-at-rest.html)

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

**パラメータ :** なし

このコントロールは、起動パラメータを指定する Amazon EC2 スポットフリートリクエストが、EC2 インスタンスにアタッチされたすべての Amazon Elastic Block Store (Amazon EBS) ボリュームの暗号化を有効にするように設定されているかどうかをチェックします。スポットフリートリクエストが起動パラメータを指定し、リクエストで指定された 1 つ以上の EBS ボリュームの暗号化を有効にしない場合、コントロールは失敗します。

セキュリティを強化するために、Amazon EBS ボリュームの暗号化を有効にする必要があります。そうすると、暗号化オペレーションが Amazon EC2 インスタンスをホストするサーバー上で実行され、インスタンスとそれにアタッチされた EBS ストレージ間での保管中のデータと転送中のデータの両方のセキュリティを確保できます。Amazon EBS 暗号化 は、EC2 インスタンスに関連付けられた EBS リソースの簡単な暗号化ソリューションです。EBS 暗号化では、独自のキー管理インフラストラクチャを構築、保守、保護する必要はありません。EBS 暗号化は、暗号化されたボリュームを作成する AWS KMS keys ときに を使用します。

**注意事項**  
このコントロールは、起動テンプレートを使用する Amazon EC2 スポットフリートリクエストの検出結果を生成しません。また、`encrypted` パラメータの値を明示的に指定しないスポットフリートリクエストの検出結果は生成されません。

### 修正
<a name="ec2-173-remediation"></a>

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

ただし、暗号化をデフォルトで有効にした場合、Amazon EBS は EBS 暗号化のデフォルトキーを使用して、新しいボリュームを暗号化します。デフォルトで暗号化を有効にしていない場合でも、個々のボリュームを作成するときに暗号化を有効にすることができます。どちらの場合も、EBS 暗号化のデフォルトキーを上書きし、カスタマーマネージド AWS KMS keyを選択できます。EBS 暗号化の詳細については、「*Amazon EBS ユーザーガイド*」の「[Amazon EBS 暗号化](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html)」を参照してください。

Amazon EC2 スポットフリートリクエストの作成方法の詳細については、「*Amazon Elastic Compute Cloud ユーザーガイド*」の「[スポットフリートを作成する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-spot-fleet.html)」を参照してください。

## [EC2.174] EC2 DHCP オプションセットにはタグを付ける必要があります
<a name="ec2-174"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::EC2::DHCPOptions`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-dhcp-options-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-dhcp-options-tagged.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | 評価されたリソースに割り当てる必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目) | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし | 

このコントロールは、Amazon EC2 DHCP オプションセットに `requiredKeyTags` パラメータで指定されたタグキーがあるかどうかをチェックします。オプションセットにタグキーがない場合、または `requiredKeyTags` パラメータで指定されたすべてのキーがない場合、コントロールは失敗します。`requiredKeyTags` パラメータの値を指定しない場合、コントロールはタグキーの存在のみをチェックし、オプションセットにタグキーがない場合は失敗します。このコントロールはシステムタグを無視します。システムタグは自動的に付与され、`aws:` プレフィックスが付きます。

タグは、 AWS リソースを作成して割り当てるラベルです。各タグは、必要なタグキーとオプションのタグ値で設定されています。タグを使用して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。またそれらは、アクションと通知のリソース所有者を追跡するのにも役立ちます。タグを使用して、認可戦略として属性ベースのアクセス制御 (ABAC) を実装することもできます。ABAC 戦略の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。タグの詳細については、[「 AWS リソースのタグ付け」および「タグエディタユーザーガイド](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。

**注記**  
個人を特定できる情報 (PII) などの機密情報や秘匿性の高い情報はタグに格納しないでください。タグには多くの からアクセスできます AWS のサービス。それらは、プライベートデータや機密データに使用することを意図していません。

### 修正
<a name="ec2-174-remediation"></a>

Amazon EC2 DHCP オプションセットへのタグの追加方法については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)」を参照してください。

## [EC2.175] EC2 起動テンプレートにはタグを付ける必要があります
<a name="ec2-175"></a>

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

**重要度:** 低

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-launch-template-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-launch-template-tagged.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | 評価されたリソースに割り当てる必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目) | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし | 

このコントロールは、Amazon EC2 起動テンプレートに `requiredKeyTags` パラメータで指定されたタグキーがあるかどうかをチェックします。起動テンプレートにタグキーがない場合、または `requiredKeyTags` パラメータで指定されたすべてのキーがない場合、コントロールは失敗します。`requiredKeyTags` パラメータの値を指定しない場合、コントロールはタグキーの存在のみをチェックし、起動テンプレートにタグキーがない場合は失敗します。このコントロールはシステムタグを無視します。システムタグは自動的に付与され、`aws:` プレフィックスが付きます。

タグは、 AWS リソースを作成して割り当てるラベルです。各タグは、必要なタグキーとオプションのタグ値で設定されています。タグを使用して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。またそれらは、アクションと通知のリソース所有者を追跡するのにも役立ちます。タグを使用して、認可戦略として属性ベースのアクセス制御 (ABAC) を実装することもできます。ABAC 戦略の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。タグの詳細については、[「 AWS リソースのタグ付け」および「タグエディタユーザーガイド](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。

**注記**  
個人を特定できる情報 (PII) などの機密情報や秘匿性の高い情報はタグに格納しないでください。タグには多くの からアクセスできます AWS のサービス。それらは、プライベートデータや機密データに使用することを意図していません。

### 修正
<a name="ec2-175-remediation"></a>

Amazon EC2 起動テンプレートへのタグの追加方法については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)」を参照してください。

## [EC2.176] EC2 プレフィックスリストにはタグを付ける必要があります
<a name="ec2-176"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::EC2::PrefixList`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-prefix-list-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-prefix-list-tagged.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | 評価されたリソースに割り当てる必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目) | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし | 

このコントロールは、Amazon EC2 プレフィックスリストに `requiredKeyTags` パラメータで指定されたタグキーがあるかどうかをチェックします。プレフィックスリストにタグキーがない場合、または `requiredKeyTags` パラメータで指定されたすべてのキーがない場合、コントロールは失敗します。`requiredKeyTags` パラメータの値を指定しない場合、コントロールはタグキーの存在のみをチェックし、プレフィックスリストにタグキーがない場合は失敗します。このコントロールはシステムタグを無視します。システムタグは自動的に付与され、`aws:` プレフィックスが付きます。

タグは、 AWS リソースを作成して割り当てるラベルです。各タグは、必要なタグキーとオプションのタグ値で設定されています。タグを使用して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。またそれらは、アクションと通知のリソース所有者を追跡するのにも役立ちます。タグを使用して、認可戦略として属性ベースのアクセス制御 (ABAC) を実装することもできます。ABAC 戦略の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。タグの詳細については、[「 AWS リソースのタグ付け」および「タグエディタユーザーガイド](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。

**注記**  
個人を特定できる情報 (PII) などの機密情報や秘匿性の高い情報はタグに格納しないでください。タグには多くの からアクセスできます AWS のサービス。それらは、プライベートデータや機密データに使用することを意図していません。

### 修正
<a name="ec2-176-remediation"></a>

Amazon EC2 プレフィックスリストへのタグの追加方法については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)」を参照してください。

## [EC2.177] EC2 トラフィックミラーセッションにはタグを付ける必要があります
<a name="ec2-177"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::EC2::TrafficMirrorSession`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-traffic-mirror-session-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-traffic-mirror-session-tagged.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | 評価されたリソースに割り当てる必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目) | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし | 

このコントロールは、Amazon EC2 トラフィックミラーセッションに `requiredKeyTags` パラメータで指定されたタグキーがあるかどうかをチェックします。セッションにタグキーがない場合、または `requiredKeyTags` パラメータで指定されたすべてのキーがない場合、コントロールは失敗します。`requiredKeyTags` パラメータの値を指定しない場合、コントロールはタグキーの存在のみをチェックし、セッションにタグキーがない場合は失敗します。このコントロールはシステムタグを無視します。システムタグは自動的に付与され、`aws:` プレフィックスが付きます。

タグは、 AWS リソースを作成して割り当てるラベルです。各タグは、必要なタグキーとオプションのタグ値で設定されています。タグを使用して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。またそれらは、アクションと通知のリソース所有者を追跡するのにも役立ちます。タグを使用して、認可戦略として属性ベースのアクセス制御 (ABAC) を実装することもできます。ABAC 戦略の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。タグの詳細については、[「 AWS リソースのタグ付け」および「タグエディタユーザーガイド](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。

**注記**  
個人を特定できる情報 (PII) などの機密情報や秘匿性の高い情報はタグに格納しないでください。タグには多くの からアクセスできます AWS のサービス。それらは、プライベートデータや機密データに使用することを意図していません。

### 修正
<a name="ec2-177-remediation"></a>

Amazon EC2 トラフィックミラーセッションへのタグの追加方法については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)」を参照してください。

## [EC2.178] EC2 トラフィックミラーフィルターにはタグを付ける必要があります
<a name="ec2-178"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::EC2::TrafficMirrorFilter`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-traffic-mirror-filter-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-traffic-mirror-filter-tagged.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | 評価されたリソースに割り当てる必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目) | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし | 

このコントロールは、Amazon EC2 トラフィックミラーフィルターに `requiredKeyTags` パラメータで指定されたタグキーがあるかどうかをチェックします。フィルターにタグキーがない場合、または `requiredKeyTags` パラメータで指定されたすべてのキーがない場合、コントロールは失敗します。`requiredKeyTags` パラメータの値を指定しない場合、コントロールはタグキーの存在のみをチェックし、フィルターにタグキーがない場合は失敗します。このコントロールはシステムタグを無視します。システムタグは自動的に付与され、`aws:` プレフィックスが付きます。

タグは、 AWS リソースを作成して割り当てるラベルです。各タグは、必要なタグキーとオプションのタグ値で設定されています。タグを使用して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。またそれらは、アクションと通知のリソース所有者を追跡するのにも役立ちます。タグを使用して、認可戦略として属性ベースのアクセス制御 (ABAC) を実装することもできます。ABAC 戦略の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。タグの詳細については、[「 AWS リソースのタグ付け」および「タグエディタユーザーガイド](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。

**注記**  
個人を特定できる情報 (PII) などの機密情報や秘匿性の高い情報はタグに格納しないでください。タグには多くの からアクセスできます AWS のサービス。それらは、プライベートデータや機密データに使用することを意図していません。

### 修正
<a name="ec2-178-remediation"></a>

Amazon EC2 トラフィックミラーフィルターへのタグの追加方法については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)」を参照してください。

## [EC2.179] EC2 トラフィックミラーターゲットにはタグを付ける必要があります
<a name="ec2-179"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::EC2::TrafficMirrorTarget`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-traffic-mirror-target-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-traffic-mirror-target-tagged.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | 評価されたリソースに割り当てる必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目) | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし | 

このコントロールは、Amazon EC2 トラフィックミラーターゲットに `requiredKeyTags` パラメータで指定されたタグキーがあるかどうかをチェックします。ターゲットにタグキーがない場合、または `requiredKeyTags` パラメータで指定されたすべてのキーがない場合、コントロールは失敗します。`requiredKeyTags` パラメータの値を指定しない場合、コントロールはタグキーの存在のみをチェックし、ターゲットにタグキーがない場合は失敗します。このコントロールはシステムタグを無視します。システムタグは自動的に付与され、`aws:` プレフィックスが付きます。

タグは、 AWS リソースを作成して割り当てるラベルです。各タグは、必要なタグキーとオプションのタグ値で設定されています。タグを使用して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。またそれらは、アクションと通知のリソース所有者を追跡するのにも役立ちます。タグを使用して、認可戦略として属性ベースのアクセス制御 (ABAC) を実装することもできます。ABAC 戦略の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。タグの詳細については、[「 AWS リソースのタグ付け」および「タグエディタユーザーガイド](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。

**注記**  
個人を特定できる情報 (PII) などの機密情報や秘匿性の高い情報はタグに格納しないでください。タグには多くの からアクセスできます AWS のサービス。それらは、プライベートデータや機密データに使用することを意図していません。

### 修正
<a name="ec2-179-remediation"></a>

Amazon EC2 トラフィックミラーターゲットへのタグの追加方法については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)」を参照してください。

## [EC2.180] EC2 ネットワークインターフェイスでは、送信元/送信先チェックを有効にする必要があります
<a name="ec2-180"></a>

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

**重要度:** 中

**リソースタイプ :** `AWS::EC2::NetworkInterface`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-enis-source-destination-check-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-enis-source-destination-check-enabled.html)

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

**パラメータ :** なし

このコントロールは、ユーザーが管理する Amazon EC2 Elastic Network Interface (ENI) で送信元/送信先チェックが有効になっているかどうかをチェックします。ユーザー管理の ENI で送信元/送信先チェックが無効になっている場合、コントロールは失敗します。このコントロールは、`aws_codestar_connections_managed`、`branch`、`efa`、`interface`、`lambda`、`quicksight` のタイプの ENI のみをチェックします。

Amazon EC2 インスタンスとアタッチされた ENI の送信元/送信先チェックは、EC2 インスタンス全体で一貫して有効にして設定する必要があります。各 ENI には、それぞれ固有の送信元/送信先チェックの設定があります。送信元/送信先チェックが有効になっている場合、Amazon EC2 は送信元/送信先アドレスの検証を適用し、インスタンスが受信するトラフィックの送信元または送信先であることを確認します。これにより、リソースが意図しないトラフィックを処理しないようにし、IP アドレスのなりすましを防止することで、ネットワークセキュリティをさらに強化できます。

**注記**  
EC2 インスタンスを NAT インスタンスとして使用していて、その ENI の送信元/送信先チェックを無効にした場合は、代わりに [NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)を使用できます。

### 修正
<a name="ec2-180-remediation"></a>

Amazon EC2 ENI の送信元/送信先チェックを有効にする方法については、「*Amazon EC2 ユーザーガイド*」の「[ネットワークインターフェイス属性の変更](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/modify-network-interface-attributes.html#modify-source-dest-check)」を参照してください。

## [EC2.181] EC2 起動テンプレートは、アタッチされた EBS ボリュームの暗号化を有効にする必要があります
<a name="ec2-181"></a>

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-launch-templates-ebs-volume-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-launch-templates-ebs-volume-encrypted.html)

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

**パラメータ :** なし

このコントロールは、Amazon EC2 起動テンプレートが、アタッチされたすべての EBS ボリュームの暗号化を有効にするかどうかをチェックします。EC2 起動テンプレートで指定された EBS ボリュームの暗号化パラメータが `False` に設定されている場合、コントロールは失敗します。

Amazon EBS 暗号化 は、Amazon EC2 インスタンスに関連付けられた EBS リソースの簡単な暗号化ソリューションです。EBS 暗号化では、独自のキー管理インフラストラクチャを構築、保守、保護する必要はありません。EBS 暗号化は、暗号化されたボリュームとスナップショットを作成するときに、 AWS KMS keys を使用します。暗号化オペレーションが EC2 インスタンスをホストするサーバー上で実行され、EC2 インスタンスとそれにアタッチされた EBS ストレージ間での保管中のデータと転送中のデータの両方のセキュリティを確保できます。詳細については、「*Amazon EBS ユーザーガイド*」の「[Amazon EBS 暗号化](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html)」を参照してください。

個々の EC2 インスタンスの手動起動時に EBS 暗号化を有効にすることができます。ただし、EC2 起動テンプレートを使用し、それらのテンプレートで暗号化設定を行うと、いくつかの利点があります。暗号化を標準として適用し、一貫した暗号化設定を使用できます。また、インスタンスの手動起動に伴って発生する可能性のあるエラーやセキュリティギャップのリスクを減らすこともできます。

**注記**  
このコントロールは EC2 起動テンプレートをチェックするときに、テンプレートで明示的に指定された EBS 暗号化設定のみを評価します。評価には、アカウントレベルの EBS 暗号化設定、AMI ブロックデバイスマッピング、またはソーススナップショットの暗号化ステータスから継承された暗号化設定は含まれません。

### 修正
<a name="ec2-181-remediation"></a>

Amazon EC2 起動テンプレートを作成したら、それを変更することはできません。ただし、起動テンプレートの新しいバージョンを作成し、その新しいバージョンのテンプレートの暗号化設定を変更することはできます。起動テンプレートの新しいバージョンをデフォルトバージョンとして指定することもできます。そうすると、起動テンプレートから EC2 インスタンスを起動し、テンプレートバージョンを指定しない場合、EC2 はインスタンスの起動時にデフォルトバージョンの設定を使用します。詳細については、「*Amazon EC2 ユーザーガイド*」の「[起動テンプレートを変更する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/manage-launch-template-versions.html)」を参照してください。

## [EC2.182] Amazon EBS スナップショットはパブリックにアクセスできません
<a name="ec2-182"></a>

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

**重要度:** 高

**リソースタイプ :** `AWS::EC2::SnapshotBlockPublicAccess`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ebs-snapshot-block-public-access.html](https://docs.aws.amazon.com/config/latest/developerguide/ebs-snapshot-block-public-access.html)

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

**パラメータ :** なし

コントロールは、Amazon EBS スナップショットのすべての共有をブロックするためにパブリックアクセスのブロックが有効になっているかどうかを確認します。すべての Amazon EBS スナップショットのすべての共有をブロックするためにパブリックアクセスのブロックが有効になっていない場合、コントロールは失敗します。

Amazon EBS スナップショットのパブリック共有を防ぐには、スナップショットのパブリックアクセスのブロックを有効にします。リージョンでスナップショットのパブリックアクセスのブロックを有効にすると、そのリージョンでスナップショットをパブリックに共有しようとすると、自動的にブロックされます。これにより、スナップショットのセキュリティが向上し、スナップショットデータが不正アクセスや意図しないアクセスから保護されます。

### 修正
<a name="ec2-182-remediation"></a>

スナップショットのパブリックアクセスブロックを有効にするには、[「Amazon EBS ユーザーガイド」の「Amazon EBS スナップショットのパブリックアクセスブロックを設定する](https://docs.aws.amazon.com/ebs/latest/userguide/block-public-access-snapshots-enable.html)」を参照してください。 ****パブリックアクセスをブロック** で、**すべてのパブリックアクセスをブロック** を選択します。

# Auto Scaling の Security Hub CSPM コントロール
<a name="autoscaling-controls"></a>

これらの Security Hub CSPM コントロールは、Amazon EC2 Auto Scaling サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [AutoScaling.1] ロードバランサーに関連付けられた Auto Scaling グループは ELB ヘルスチェックを使用する必要がある
<a name="autoscaling-1"></a>

**関連する要件:** PCI DSS v3.2.1/2.2、NIST.800-53.r5 CA-7、NIST.800-53.r5 CP-2(2)、NIST.800-53.r5 SI-2

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

**重要度:** 低

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-group-elb-healthcheck-required.html](https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-group-elb-healthcheck-required.html)

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

**パラメータ :** なし

このコントロールは、ロードバランサーに関連付けられた Amazon EC2 Auto Scaling グループで、Elastic Load Balancing (ELB) のヘルスチェックが使用されているかどうかをチェックします。Auto Scaling グループが ELB ヘルスチェックを使用しない場合、コントロールは失敗します。

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

### 修正
<a name="autoscaling-1-remediation"></a>

Elastic Load Balancing ヘルスチェックを追加するには、「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[Add Elastic Load Balancing health checks](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-add-elb-healthcheck.html#as-add-elb-healthcheck-console)」を参照してください。

## [AutoScaling.2] Amazon EC2 Auto Scaling グループは、複数のアベイラビリティーゾーンをカバーする必要があります
<a name="autoscaling-2"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-2(2)、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 SC-36、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-multiple-az.html](https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-multiple-az.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `minAvailabilityZones`  |  アベイラビリティーゾーンの最小数  |  列挙型  |  `2, 3, 4, 5, 6`  |  `2`  | 

このコントロールは、Amazon EC2 Auto Scaling グループが少なくとも指定された数のアベイラビリティーゾーン (AZ) にまたがっているかどうかをチェックします。Auto Scaling グループが少なくとも指定された数の AZ にまたがっていない場合、コントロールは失敗します。AZs の最小数にカスタムパラメータ値を指定しない限り、Security Hub CSPM はデフォルト値の 2 つの AZs を使用します。

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

### 修正
<a name="autoscaling-2-remediation"></a>

既存の Auto Scaling グループに AZ を追加するには、「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[Add and remove Availability Zones](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-add-availability-zone.html)」を参照してください。

## [AutoScaling.3] Auto Scaling グループ起動設定は、EC2 インスタンスを、インスタンスメタデータサービスバージョン 2 (IMDSv2) を必要とするように設定する必要があります
<a name="autoscaling-3"></a>

**関連する要件:** NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-6、NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、PCI DSS v4.0.1/2.2.6

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-launchconfig-requires-imdsv2.html](https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-launchconfig-requires-imdsv2.html)

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

**パラメータ :** なし

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

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

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

### 修正
<a name="autoscaling-3-remediation"></a>

Auto Scaling グループは、一度に 1 つの起動設定に関連付けられます。起動設定は、作成後に変更することはできません。Auto Scaling グループの起動設定を変更するには、新しい起動設定のベースとして、既存の起動設定を IMDSv2 を有効にした上で使用します。詳細については、「*Amazon EC2 ユーザーガイド*」の「[新規インスタンスのインスタンスメタデータオプションの設定](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-IMDS-new-instances.html)」を参照してください。

## [AutoScaling.4] Auto Scaling グループの起動設定では、メタデータ応答ホップ制限が 1 を超えることはできません
<a name="autoscaling-4"></a>

**重要**  
Security Hub CSPM は、2024 年 4 月にこのコントロールを廃止しました。詳細については、「[Security Hub CSPM コントロールの変更ログ](controls-change-log.md)」を参照してください。

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-launch-config-hop-limit.html](https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-launch-config-hop-limit.html)

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

**パラメータ :** なし

これにより、メタデータトークンが移動できる、ネットワークホップの数をチェックします。メタデータの応答ホップ制限が `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 インスタンスから移動することができます。

### 修正
<a name="autoscaling-4-remediation"></a>

既存の起動設定のメタデータ応答ホップ制限を変更する方法については、「*Amazon EC2 ユーザーガイド*」の「[既存インスタンスのインスタンスメタデータオプションの変更](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html#configuring-IMDS-existing-instances)」を参照してください。

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

**関連する要件:** NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)、PCI DSS v4.0.1/1.4.4

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-launch-config-public-ip-disabled.html](https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-launch-config-public-ip-disabled.html)

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

**パラメータ :** なし

このコントロールは、Auto Scaling グループに関連付けられた起動設定が、グループのインスタンスに[パブリック IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#public-ip-addresses)を割り当てるかどうかをチェックします。関連付けられた起動設定が、パブリック IP アドレスを割り当てている場合に、このコントロールは失敗します。

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

### 修正
<a name="autoscaling-5-remediation"></a>

Auto Scaling グループは、一度に 1 つの起動設定に関連付けられます。起動設定は、作成後に変更することはできません。Auto Scaling グループの起動設定を変更するには、新しい起動設定のベースとして既存の起動設定を使用します。次に、Auto Scaling グループを新しい起動設定を使用するように更新します。手順については、「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[Auto Scaling グループの起動設定を変更する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/change-launch-config.html)」を参照してください。新しい起動設定を作成する際、**[追加設定]** にある **[高度な詳細] の [IP アドレスタイプ]** で、**[どのインスタンスにもパブリック IP アドレスを割り当てない]** を選択します。

起動設定を変更すると、Auto Scaling は、新しいインスタンスを新しい設定オプションで起動します。既存のインスタンスは影響を受けません。既存のインスタンスを更新するには、インスタンスの更新を行うか、終了ポリシーに基づいて自動スケーリングで古いインスタンスを新しいインスタンスに徐々に置き換えるようにすることをお勧めします。Auto Scaling インスタンスの更新についての詳細は、「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[Auto Scaling インスタンスの更新](https://docs.aws.amazon.com/autoscaling/ec2/userguide/update-auto-scaling-group.html#update-auto-scaling-instances)」を参照してください。

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

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-2(2)、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 SC-36、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-multiple-instance-types.html](https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-multiple-instance-types.html)

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

**パラメータ :** なし

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

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

### 修正
<a name="autoscaling-6-remediation"></a>

複数のインスタンスタイプで Auto Scaling グループを作成するには、「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[複数のインスタンスタイプと購入オプションを使用する Auto Scaling グループ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups.html)」を参照してください。

## [AutoScaling.9] Amazon EC2 Auto Scaling グループは Amazon EC2 起動テンプレートを使用する必要があります
<a name="autoscaling-9"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-launch-template.html](https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-launch-template.html)

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

**パラメータ :** なし

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

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

### 修正
<a name="autoscaling-9-remediation"></a>

EC2 起動テンプレートを使用して Auto Scaling グループを作成するには、「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[起動テンプレートを使用して Auto Scaling グループを作成する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-launch-template.html)」を参照してください。起動設定を起動テンプレートに置き換える方法については、「*Amazon EC2 ユーザーガイド*」の「[起動設定を起動テンプレートに置き換える](https://docs.aws.amazon.com/autoscaling/ec2/userguide/replace-launch-config.html)」を参照してください。

## [AutoScaling.10] EC2 Auto Scaling グループにタグを付ける必要があります
<a name="autoscaling-10"></a>

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

**重要度:** 低

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

**AWS Config rule:** `tagged-autoscaling-autoscalinggroup` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon EC2 Auto Scaling グループにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。Auto Scaling グループにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、Auto Scaling グループがキーでタグ付けされていない場合に失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="autoscaling-10-remediation"></a>

Auto Scaling グループにタグを追加するには、「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[Auto Scaling グループとインスタンスにタグを付ける](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-tagging.html)」を参照してください。

# Amazon ECR の Security Hub CSPM コントロール
<a name="ecr-controls"></a>

これらの Security Hub CSPM コントロールは、Amazon Elastic Container Registry (Amazon ECR) サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [ECR.1] ECR プライベートリポジトリでは、イメージスキャニングが設定されている必要があります
<a name="ecr-1"></a>

**関連する要件:** NIST.800-53.r5 RA-5、PCI DSS v4.0.1/6.2.3、PCI DSS v4.0.1/6.2.4

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ecr-private-image-scanning-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/ecr-private-image-scanning-enabled.html)

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

**パラメータ :** なし

このコントロールは、プライベート Amazon ECR リポジトリでイメージスキャニングが設定されているかどうかをチェックします。プライベート ECR リポジトリがプッシュ時スキャンまたは連続スキャン用に設定されていない場合、コントロールは失敗します。

ECR イメージスキャニングは、コンテナイメージ内のソフトウェアの脆弱性を特定するのに役立ちます。ECR リポジトリでイメージスキャンを設定すると、保存されているイメージの整合性と安全性を検証するレイヤーが追加されます。

### 修正
<a name="ecr-1-remediation"></a>

ECR リポジトリのイメージスキャニングを設定する方法については、「*Amazon Elastic Container Registry ユーザーガイド*」の「[Image scanning](https://docs.aws.amazon.com//AmazonECR/latest/userguide/image-scanning.html)」を参照してください。

## [ECR.2] ECR プライベートリポジトリでは、タグのイミュータビリティが設定されている必要があります
<a name="ecr-2"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-8(1)

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ecr-private-tag-immutability-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/ecr-private-tag-immutability-enabled.html)

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

**パラメータ :** なし

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

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

### 修正
<a name="ecr-2-remediation"></a>

イミュータブル (変更不可能) なタグが設定されたリポジトリを作成する場合、または既存のリポジトリのイメージタグのミュータビリティ (変更可能性) を更新する場合は、「*Amazon Elastic Container Registry ユーザーガイド*」の「[Image tag mutability](https://docs.aws.amazon.com//AmazonECR/latest/userguide/image-tag-mutability.html)」を参照してください。

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

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ecr-private-lifecycle-policy-configured.html](https://docs.aws.amazon.com/config/latest/developerguide/ecr-private-lifecycle-policy-configured.html)

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

**パラメータ:** なし

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

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

### 修正
<a name="ecr-3-remediation"></a>

ライフサイクルポリシーを設定するには、「*Amazon Elastic Container Registry ユーザーガイド*」の「[Creating a lifecycle policy preview](https://docs.aws.amazon.com//AmazonECR/latest/userguide/lpp_creation.html)」を参照してください。

## [ECR.4] ECR パブリックリポジトリにはタグを付ける必要があります
<a name="ecr-4"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::ECR::PublicRepository`

**AWS Config rule:** `tagged-ecr-publicrepository` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon ECR パブリックリポジトリにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。パブリックリポジトリにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、パブリックリポジトリにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="ecr-4-remediation"></a>

ECR パブリックリポジトリにタグを追加するには、「*Amazon Elastic Container Registry ユーザーガイド*」の「[Amazon ECR パブリックリポジトリのタグ付け](https://docs.aws.amazon.com/AmazonECR/latest/public/ecr-public-using-tags.html)」を参照してください。

## [ECR.5] ECR リポジトリはカスタマーマネージドで暗号化する必要があります AWS KMS keys
<a name="ecr-5"></a>

**関連する要件:** NIST.800-53.r5 SC-12(2)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 SI-7(6)、NIST.800-53.r5 AU-9

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ecr-repository-cmk-encryption-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/ecr-repository-cmk-encryption-enabled.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `kmsKeyArns`  |  評価 AWS KMS keys に含める の Amazon リソースネーム (ARNs) のリスト。ECR リポジトリがリスト内の KMS キーで暗号化されていない場合、コントロールは `FAILED` 検出結果を生成します。  |  StringList (最大 10 項目)  |  既存の KMS キーの 1～10 個の ARN。例: `arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab`  |  デフォルト値なし  | 

このコントロールは、Amazon ECR リポジトリが保管時にカスタマーマネージド AWS KMS keyで暗号化されているかどうかをチェックします。ECR リポジトリがカスタマーマネージド KMS キーで暗号化されていない場合、コントロールは失敗します。必要に応じて、コントロールの評価に含める KMS キーのリストを指定することができます。

デフォルトでは、Amazon ECR は AES-256 アルゴリズムを使用して Amazon S3 マネージドキー (SSE-S3) でリポジトリデータを暗号化します。追加コントロールのために、代わりに AWS KMS key (SSE-KMS または DSSE-KMS) を使用してデータを暗号化するように Amazon ECR を設定できます。KMS キーは、Amazon ECR によって作成および管理されていてエイリアス `aws/ecr` がある AWS マネージドキー 、または AWS アカウントでユーザーが作成および管理しているカスタマーマネージドキーです。カスタマーマネージド KMS キーを使用すると、ユーザーがキーを完全にコントロールできます。これには、キーポリシーの定義と維持管理、許可の管理、暗号化マテリアルのローテーション、タグの割り当て、エイリアスの作成、キーの有効化と無効化が含まれます。

**注記**  
AWS KMS は、KMS キーへのクロスアカウントアクセスをサポートします。ECR リポジトリが、別のアカウントが所有する KMS キーで暗号化されている場合、このコントロールはリポジトリを評価するときにクロスアカウントチェックを実行しません。コントロールは、リポジトリの暗号化オペレーションを実行するときに Amazon ECR がキーにアクセスして使用できるかどうかを評価しません。

### 修正
<a name="ecr-5-remediation"></a>

既存の ECR リポジトリの暗号化設定を変更することはできません。ただし、後で作成する ECR リポジトリには、異なる暗号化設定を指定できます。Amazon ECR は、個々のリポジトリに対して異なる暗号化設定の使用をサポートしています。

ECR リポジトリの暗号化オプションの詳細については、「*Amazon ECR ユーザーガイド*」の「[保管時の暗号化](https://docs.aws.amazon.com/AmazonECR/latest/userguide/encryption-at-rest.html)」を参照してください。カスタマー管理の詳細については AWS KMS keys、「 *AWS Key Management Service デベロッパーガイド*[AWS KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html)」の「」を参照してください。

# Amazon ECS の Security Hub CSPM コントロール
<a name="ecs-controls"></a>

これらの Security Hub CSPM コントロールは、Amazon Elastic Container Service (Amazon ECS) サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [ECS.1] Amazon ECS タスク定義には、セキュアなネットワークモードとユーザー定義が必要です。
<a name="ecs-1"></a>

**重要**  
Security Hub CSPM は 2026 年 3 月にこのコントロールを廃止しました。詳細については、「[Security Hub CSPM コントロールの変更ログ](controls-change-log.md)」を参照してください。特権設定、ネットワークモード設定、およびユーザー設定の評価については、次のコントロールを参照してください。  
 [[ECS.4] ECS コンテナは、非特権として実行する必要があります](#ecs-4) 
 [[ECS.17] ECS タスク定義ではホストネットワークモードを使用すべきではありません](#ecs-17) 
 [[ECS.20] ECS タスク定義では、Linux コンテナ定義で非ルートユーザーを設定する必要があります](#ecs-20) 
 [[ECS.21] ECS タスク定義では、Windows コンテナ定義で管理者以外のユーザーを設定する必要があります](#ecs-21) 

**関連する要件:** NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-5、NIST.800-53.r5 AC-6

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-user-for-host-mode-check.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-user-for-host-mode-check.html)

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

**パラメータ :**
+ `SkipInactiveTaskDefinitions`: `true` (カスタマイズ不可)

このコントロールは、ホストネットワークモードを使用するアクティブな Amazon ECS タスク定義に `privileged` または `user` コンテナの定義もあるかどうかをチェックします。ホストネットワークモードとコンテナ定義が `privileged=false`、空で、`user=root`、または空のタスク定義では、制御に失敗します。

このコントロールは、Amazon ECS タスク定義の最新のアクティブなリビジョンのみを評価します。

この制御の目的は、ホストネットワークモードを使用するタスクを実行するときに、アクセスが意図的に定義されるようにすることです。タスク定義に昇格されたアクセス権限がある場合は、その構成を選択したことによるものです。このコントロールは、タスク定義でホストネットワークが有効になっていても、お客様が昇格されたアクセス権限を選択していない場合に、予期しない権限の昇格の有無をチェックします。

### 修正
<a name="ecs-1-remediation"></a>

タスク定義を更新する方法については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[タスク定義の更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-task-definition.html)」を参照してください。

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

## [ECS.2] ECS サービスには、パブリック IP アドレスを自動で割り当てないでください
<a name="ecs-2"></a>

**関連する要件:** NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)、PCI DSS v4.0.1/1.4.4

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

**重要度:** 高

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

**AWS Config rule:** `ecs-service-assign-public-ip-disabled` (カスタム Security Hub CSPM ルール)

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

**パラメータ :** なし

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

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

### 修正
<a name="ecs-2-remediation"></a>

まず、`awsvpc` ネットワークモードを使用し、`requiresCompatibilities` の **FARGATE** を指定するクラスターのタスク定義を作成する必要があります。次に、**[コンピューティング設定]**で、**[起動タイプ]** と **[FARGATE] **を選択します。最後に、**[ネットワーキング]** フィールドで **[パブリック IP]** をオフにして、サービスの自動パブリック IP 割り当てを無効にします。

## [ECS.3] ECS タスクの定義では、ホストのプロセス名前空間を共有しないでください
<a name="ecs-3"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-pid-mode-check.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-pid-mode-check.html)

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

**パラメータ :** なし

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

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

### 修正
<a name="ecs-3-remediation"></a>

タスク定義上で `pidMode` を設定する方法については、「Amazon Elastic Container Service デベロッパーガイド」の「[タスク定義パラメータ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#task_definition_pidmode)」を参照してください。

## [ECS.4] ECS コンテナは、非特権として実行する必要があります
<a name="ecs-4"></a>

**関連する要件:** NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-5、NIST.800-53.r5 AC-6

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-containers-nonprivileged.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-containers-nonprivileged.html)

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

**パラメータ :** なし

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

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

### 修正
<a name="ecs-4-remediation"></a>

タスク定義上で `privileged` を設定する方法については、「Amazon Elastic Container Service デベロッパーガイド」の「[詳細コンテナ定義パラメータ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_security)」を参照してください。

## [ECS.5] ECS タスク定義では、ルートファイルシステムへの読み取り専用アクセスに制限するようにコンテナを設定する必要があります
<a name="ecs-5"></a>

**関連する要件:** NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-5、NIST.800-53.r5 AC-6

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-containers-readonly-access.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-containers-readonly-access.html)

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

**パラメータ :** なし

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

Amazon ECS タスク定義で `readonlyRootFilesystem` パラメータが `true` に設定されている場合、ECS コンテナにはルートファイルシステムへの読み取り専用アクセス権が付与されます。これにより、ファイルシステムフォルダとディレクトリの読み取り/書き込み権限を持つ明示的なボリュームマウントがないと、コンテナインスタンスのルートファイルシステムを改ざんしたり書き込んだりできないため、セキュリティ攻撃ベクトルが減少します。このオプションを有効にすると、最小特権の原則にも準拠できます。

**注記**  
`readonlyRootFilesystem` パラメータは Windows コンテナではサポートされていません。`WINDOWS_SERVER` OS ファミリーを指定するように`runtimePlatform`設定された のタスク定義は としてマーク`NOT_APPLICABLE`され、このコントロールの結果は生成されません。

### 修正
<a name="ecs-5-remediation"></a>

Amazon ECS コンテナにルートファイルシステムへの読み取り専用アクセス権を付与するには、コンテナのタスク定義に `readonlyRootFilesystem` パラメータを追加し、このパラメータの値を `true` に設定します。タスク定義パラメータの詳細とそれらをタスク定義に追加する方法については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[Amazon ECS タスク定義](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html)」と「[タスク定義の更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-task-definition-console-v2.html)」を参照してください。

## [ECS.8] シークレットは、コンテナ環境の変数として渡さないでください
<a name="ecs-8"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、PCI DSS v4.0.1/8.6.2

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-no-environment-secrets.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-no-environment-secrets.html) 

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

**パラメータ:** `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 を使用して保存することが推奨されます。

### 修正
<a name="ecs-8-remediation"></a>

SSM を使用してパラメータを作成する方法については、「*AWS Systems Manager ユーザーガイド*」の「[Systems Manager パラメータを作成する](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-su-create.html)」を参照してください。シークレットを指定するタスク定義の作成に関する詳細は、「*Amazon Elastic Container Service デベロッパーガイド*」の「[Secrets Manager を使用した機密データの指定](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/specifying-sensitive-data-secrets.html#secrets-create-taskdefinition)」を参照してください。

## [ECS.9] ECS タスク定義にはログ設定が必要です。
<a name="ecs-9"></a>

**関連する要件:** NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-7(8)

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

**重要度:** 高

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

**AWS Config rule:** [ecs-task-definition-log-configuration](https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-log-configuration.html)

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

**パラメータ :** なし

このコントロールは、最新のアクティブな Amazon ECS タスク定義にロギング設定が指定されているかどうかを確認します。タスク定義に `logConfiguration` プロパティが定義されていない場合、または少なくとも 1 つのコンテナ定義で `logDriver` の値が null の場合、コントロールは失敗します。

ログ記録は Amazon ECS の信頼性、可用性、パフォーマンスの維持に有益です。タスク定義からデータを収集すると可視性が得られ、プロセスのデバッグやエラーの根本原因の特定に役立ちます。ECS タスク定義で定義する必要のないロギングソリューション (サードパーティのロギングソリューションなど) を使用している場合は、ログを無効にできますが、無効にする前に、ログが適切に取得、保存されていることを確認してください。

### 修正
<a name="ecs-9-remediation"></a>

Amazon ECS タスク定義のログ設定を定義するには、「**Amazon Elastic Container Service デベロッパーガイド」の「[タスク定義でログ設定を指定する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_awslogs.html#specify-log-config)」を参照してください。

## [ECS.10] ECS Fargate サービスは、最新の Fargate プラットフォームバージョンで実行する必要があります。
<a name="ecs-10"></a>

**関連する要件:** NIST.800-53.r5 SI-2、NIST.800-53.r5 SI-2(2)、NIST.800-53.r5 SI-2(4)、NIST.800-53.r5 SI-2(5)、PCI DSS v4.0.1/6.3.3

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-fargate-latest-platform-version.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-fargate-latest-platform-version.html)

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

**パラメータ :**
+ `latestLinuxVersion: 1.4.0` (カスタマイズ不可)
+ `latestWindowsVersion: 1.0.0` (カスタマイズ不可)

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

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

### 修正
<a name="ecs-10-remediation"></a>

プラットフォームバージョンを含む既存サービスの更新方法については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[サービスの更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service.html)」を参照してください。

## [ECS.12] ECS クラスターはコンテナインサイトを使用する必要があります
<a name="ecs-12"></a>

**関連する要件:** NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SI-2

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-container-insights-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-container-insights-enabled.html)

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

**パラメータ :** なし

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

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

### 修正
<a name="ecs-12-remediation"></a>

Container Insights の使用方法については、「*Amazon CloudWatch ユーザーガイド*」の「[サービスの更新](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-ECS.html)」を参照してください。

## [ECS.13] ECS サービスにはタグを付ける必要があります
<a name="ecs-13"></a>

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

**重要度:** 低

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

**AWS Config rule:** `tagged-ecs-service` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon ECS サービスにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。サービスにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、サービスがキーでタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。IAM エンティティ (ユーザーまたはロール) と AWS リソースにタグをアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="ecs-13-remediation"></a>

ECS サービスにタグを追加するには、「*Amazon Elastic Container Service デベロッパーガイド*」の「[Amazon ECS リソースにタグを付ける](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html)」を参照してください。

## [ECS.14] ECS クラスターにはタグを付ける必要があります
<a name="ecs-14"></a>

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

**重要度:** 低

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

**AWS Config rule:** `tagged-ecs-cluster` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon ECS クラスターにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。クラスターにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、クラスターにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。IAM エンティティ (ユーザーまたはロール) と AWS リソースにタグをアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="ecs-14-remediation"></a>

ECS クラスターにタグを追加するには、「*Amazon Elastic Container Service デベロッパーガイド*」の「[Amazon ECS リソースにタグを付ける](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html)」を参照してください。

## [ECS.15] ECS タスク定義にはタグを付ける必要があります
<a name="ecs-15"></a>

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

**重要度:** 低

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

**AWS Config rule:** `tagged-ecs-taskdefinition` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon ECS タスク定義に、パラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。タスク定義にタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、タスク定義にキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。IAM エンティティ (ユーザーまたはロール) と AWS リソースにタグをアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、『』の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="ecs-15-remediation"></a>

ECS タスク定義にタグを追加するには、「*Amazon Elastic Container Service デベロッパーガイド*」の「[Amazon ECS リソースのタグ付け](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html)」を参照してください。

## [ECS.16] ECS タスクセットはパブリック IP アドレスを自動的に割り当てないでください。
<a name="ecs-16"></a>

**関連する要件:** PCI DSS v4.0.1/1.4.4

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

**重要度:** 高

**リソースタイプ :** `AWS::ECS::TaskSet`

**AWS Config rule:** `ecs-taskset-assign-public-ip-disabled` (カスタム Security Hub CSPM ルール)

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

**パラメータ :** なし

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

パブリック IP アドレスは、インターネットから到達可能です。タスクセットをパブリック IP アドレスで設定すると、タスクセットに関連付けられたリソースにインターネットからアクセスできます。ECS タスクセットは、コンテナアプリケーションサーバーへの意図しないアクセスを許可する可能性があるため、パブリックにアクセスができないようにする必要があります。

### 修正
<a name="ecs-16-remediation"></a>

パブリック IP アドレスを使用しないように ECS タスクセットを更新するには、「*Amazon Elastic Container Service デベロッパーガイド*」の「[コンソールを使用した Amazon ECS タスク定義の更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-task-definition-console-v2.html)」を参照してください。

## [ECS.17] ECS タスク定義ではホストネットワークモードを使用すべきではありません
<a name="ecs-17"></a>

**関連する要件:** NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-5、NIST.800-53.r5 AC-6

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-network-mode-not-host.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-network-mode-not-host.html)

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

**パラメータ :** なし

このコントロールは、Amazon ECS タスク定義の最新のアクティブなリビジョンが `host` ネットワークモードを使用しているかどうかをチェックします。ECS タスク定義の最新のアクティブなリビジョンが `host` ネットワークモードを使用している場合、このコントロールは失敗します。

`host` ネットワークモードを使用すると、Amazon ECS コンテナのネットワークは、コンテナを実行している基盤となるホストに直接関連付けられます。そのため、このモードでは、コンテナはホスト上のプライベートループバックネットワークサービスに接続でき、ホストになりすますことができます。その他の重大な欠点として、`host` ネットワークモードを使用している場合、コンテナポートを再マッピングする方法がなく、各ホストで 1 つのタスクを複数インスタンス化することができないことが挙げられます。

### 修正
<a name="ecs-17-remediation"></a>

Amazon EC2 インスタンスでホストされている Amazon ECS タスクのネットワークモードとオプションについては、「*Amazon Elastic Container Service デベロッパーガイド*」の「[EC2 起動タイプの Amazon ECS タスクネットワークオプション](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html)」を参照してください。タスク定義の新しいリビジョンを作成し、別のネットワークモードを指定する方法については、そのガイドの「[Amazon ECS タスク定義の更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-task-definition-console-v2.html)」を参照してください。

Amazon ECS タスク定義が によって作成された場合は AWS Batch、[AWS Batch 「ジョブのネットワークモード](https://docs.aws.amazon.com/batch/latest/userguide/networking-modes-jobs.html)」を参照して、 AWS Batch ジョブタイプのネットワークモードと一般的な使用法について学び、安全なオプションを選択します。

## [ECS.18] ECS タスク定義ではEFS ボリュームの転送時の暗号化を使用する必要があります
<a name="ecs-18"></a>

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-efs-encryption-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-efs-encryption-enabled.html)

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

**パラメータ :** なし

このコントロールは、Amazon ECS タスク定義の最新のアクティブなリビジョンが EFS ボリュームの転送中の暗号化を使用しているかどうかをチェックします。ECS タスク定義の最新のアクティブなリビジョンで EFS ボリュームの転送中の暗号化が無効になっている場合、コントロールは失敗します。

Amazon EFS ボリュームは、Amazon ECS タスクで使用できるように、シンプルでスケーラブル、永続的な共有ファイルストレージを提供します。Amazon EFS は、Transport Layer Security (TLS) による転送中のデータの暗号化をサポートしています。転送中のデータの暗号化が EFS ファイルシステムのマウントオプションとして宣言されると、Amazon EFS はファイルシステムのマウント時に EFS ファイルシステムとの安全な TLS 接続を確立します。

### 修正
<a name="ecs-18-remediation"></a>

EFS ボリュームで Amazon ECS タスク定義の転送時の暗号化を有効にする方法については、「Amazon *Elastic Container Service* [デベロッパーガイド」の「ステップ 5: タスク定義を作成する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/tutorial-efs-volumes.html#efs-task-def)」を参照してください。

## [ECS.19] ECS キャパシティプロバイダーはマネージド終了保護を有効にする必要があります
<a name="ecs-19"></a>

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

**重要度:** 中

**リソースタイプ :** `AWS::ECS::CapacityProvider`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-capacity-provider-termination-check.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-capacity-provider-termination-check.html)

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

**パラメータ :** なし

このコントロールは、Amazon ECS キャパシティプロバイダーがマネージド終了保護を有効にしているかどうかをチェックします。ECS キャパシティープロバイダーでマネージド終了保護が有効になっていない場合、コントロールは失敗します。

Amazon ECS キャパシティープロバイダーは、クラスター内のタスクに対するインフラストラクチャのスケーリングを管理できます。キャパシティーとして EC2 インスタンスを使用する場合は、Auto Scaling グループを使用して EC2 インスタンスを管理します。マネージド終了保護を使用すると、クラスターの自動スケーリングで、どのインスタンスを終了するかを制御できます。マネージド終了保護を使用した場合、Amazon ECS は、実行中の Amazon ECS タスクがない EC2 インスタンスのみを終了します。

**注記**  
マネージド終了保護を使用する場合は、マネージドスケーリングも使用する必要があります。そうしなければ、マネージド終了保護は機能しません。

### 修正
<a name="ecs-19-remediation"></a>

Amazon ECS キャパシティープロバイダーのマネージド終了保護を有効にするには、[「Amazon Elastic Container Service デベロッパーガイド」の「Amazon ECS キャパシティープロバイダーのマネージド終了保護の更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-managed-termination-protection.html)」を参照してください。 **

## [ECS.20] ECS タスク定義では、Linux コンテナ定義で非ルートユーザーを設定する必要があります
<a name="ecs-20"></a>

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-linux-user-non-root.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-linux-user-non-root.html)

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

**パラメータ :** なし

このコントロールは、Amazon ECS タスク定義の最新のアクティブなリビジョンが、非ルートユーザーとして実行されるように Linux コンテナを設定するかどうかをチェックします。デフォルトのルートユーザーが設定されている場合、またはコンテナにユーザー設定がない場合、コントロールは失敗します。

Linux コンテナがルート権限で実行されると、いくつかの重大なセキュリティリスクが生じます。ルートユーザーは、コンテナ内で無制限にアクセスできます。この昇格されたアクセスは、攻撃者がコンテナの分離から抜け出し、基盤となるホストシステムにアクセスする可能性のある、コンテナエスケープ攻撃のリスクを高めます。ルートとして実行されているコンテナが侵害された場合、攻撃者はこれを悪用してホストシステムリソースにアクセスまたは変更し、他のコンテナまたはホスト自体に影響を与える可能性があります。さらに、ルートアクセスにより特権エスカレーション攻撃が可能になり、攻撃者はコンテナの意図した範囲を超える追加のアクセス許可を取得できます。ECS タスク定義のユーザーパラメータは、ユーザー名、ユーザー ID、 グループのユーザー名、 グループ ID の UID など、複数の形式でユーザーを指定できます。誤ってルートアクセスが付与されないようにタスク定義を設定するときは、これらのさまざまな形式に注意することが重要です。最小特権の原則に従って、コンテナはルート以外のユーザーを使用して最低限必要なアクセス許可で実行する必要があります。このアプローチにより、潜在的な攻撃対象領域が大幅に減少し、潜在的なセキュリティ侵害の影響が軽減されます。

**注記**  
このコントロールは、 `operatingSystemFamily`が `LINUX`として設定されているか、タスク定義で設定`operatingSystemFamily`されていない場合にのみ、タスク定義のコンテナ定義を評価します。タスク定義内のコンテナ定義がデフォルトのルートユーザーとして設定または`user`設定`user`されていない場合、コントロールは評価されたタスク定義`FAILED`の結果を生成します。`LINUX` コンテナのデフォルトのルートユーザーは `"root"`および です`"0"`。

### 修正
<a name="ecs-20-remediation"></a>

Amazon ECS タスク定義の新しいリビジョンの作成とコンテナ定義の `user`パラメータの更新については、「Amazon *Elastic Container Service デベロッパーガイド*[」の「Amazon ECS タスク定義の更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-task-definition-console-v2.html)」を参照してください。

## [ECS.21] ECS タスク定義では、Windows コンテナ定義で管理者以外のユーザーを設定する必要があります
<a name="ecs-21"></a>

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-windows-user-non-admin.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-windows-user-non-admin.html)

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

**パラメータ :** なし

このコントロールは、Amazon ECS タスク定義の最新のアクティブなリビジョンが、デフォルト管理者ではないユーザーとして実行するように Windows コンテナを設定するかどうかをチェックします。デフォルトの管理者がユーザーとして設定されている場合、またはコンテナにユーザー設定がない場合、コントロールは失敗します。

Windows コンテナが管理者権限で実行されると、いくつかの重大なセキュリティリスクが生じます。管理者は、コンテナ内で無制限にアクセスできます。この昇格されたアクセスは、攻撃者がコンテナの分離から抜け出し、基盤となるホストシステムにアクセスする可能性のある、コンテナエスケープ攻撃のリスクを高めます。

**注記**  
このコントロールは、 が `WINDOWS_SERVER`として`operatingSystemFamily`設定されているか、タスク定義で設定`operatingSystemFamily`されていない場合にのみ、タスク定義のコンテナ定義を評価します。タスク定義内のコンテナ定義が であるコンテナのデフォルト管理者として設定または`user`設定`user`されていない場合、コントロールは評価`WINDOWS_SERVER`されたタスク定義`FAILED`の結果を生成します`"containeradministrator"`。

### 修正
<a name="ecs-21-remediation"></a>

Amazon ECS タスク定義の新しいリビジョンの作成とコンテナ定義の `user`パラメータの更新については、「Amazon *Elastic Container Service デベロッパーガイド*[」の「Amazon ECS タスク定義の更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-task-definition-console-v2.html)」を参照してください。

# Amazon EFS の Security Hub CSPM コントロール
<a name="efs-controls"></a>

これらの Security Hub CSPM コントロールは、Amazon Elastic File System (Amazon EFS) サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [EFS.1] Elastic File System は、 を使用して保管中のファイルデータを暗号化するように設定する必要があります AWS KMS
<a name="efs-1"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/2.3.1、CIS AWS Foundations Benchmark v3.0.0/2.4.1、NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SI-7(6)

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/efs-encrypted-check.html](https://docs.aws.amazon.com/config/latest/developerguide/efs-encrypted-check.html)

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

**パラメータ :** なし

このコントロールは、Amazon Elastic File System が を使用してファイルデータを暗号化するように設定されているかどうかを確認します AWS KMS。次の場合、チェックは失敗します。
+ [https://docs.aws.amazon.com/efs/latest/ug/API_DescribeFileSystems.html](https://docs.aws.amazon.com/efs/latest/ug/API_DescribeFileSystems.html) レスポンスで `Encrypted` は、`false` に設定されている。
+ [https://docs.aws.amazon.com/efs/latest/ug/API_DescribeFileSystems.html](https://docs.aws.amazon.com/efs/latest/ug/API_DescribeFileSystems.html) レスポンスの `KmsKeyId` キーが [https://docs.aws.amazon.com/config/latest/developerguide/efs-encrypted-check.html](https://docs.aws.amazon.com/config/latest/developerguide/efs-encrypted-check.html) の `KmsKeyId` パラメータと一致しない。

このコントロールでは、[https://docs.aws.amazon.com/config/latest/developerguide/efs-encrypted-check.html](https://docs.aws.amazon.com/config/latest/developerguide/efs-encrypted-check.html) の `KmsKeyId` パラメータを使用しないことに注意してください。`Encrypted` の値のみをチェックします。

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

### 修正
<a name="efs-1-remediation"></a>

新しい Amazon EFS ファイルシステムを暗号化する方法の詳細については、「Amazon Elastic File System ユーザーガイド」の「[保管中のデータの暗号化](https://docs.aws.amazon.com/efs/latest/ug/encryption-at-rest.html)」を参照してください。

## [EFS.2] Amazon EFS ボリュームは、バックアッププランに含める必要があります
<a name="efs-2"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6、NIST.800-53.r5 CP-6(1)、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 CP-9、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-12、NIST.800-53.r5 SI-13(5)

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/efs-in-backup-plan.html](https://docs.aws.amazon.com/config/latest/developerguide/efs-in-backup-plan.html)

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

**パラメータ:** なし

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

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

### 修正
<a name="efs-2-remediation"></a>

既存の Amazon EFS ファイルシステムの自動バックアップを有効にするには、「*AWS Backup デベロッパーガイド*」の「[開始方法 4: Amazon EFS 自動バックアップの作成](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-auto-backup.html)」を参照してください。

## [EFS.3] EFS アクセスポイントは、ルートディレクトリを適用する必要があります
<a name="efs-3"></a>

**関連する要件:** NIST.800-53.r5 AC-6(10)

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/efs-access-point-enforce-root-directory.html](https://docs.aws.amazon.com/config/latest/developerguide/efs-access-point-enforce-root-directory.html)

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

**パラメータ :** なし

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

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

### 修正
<a name="efs-3-remediation"></a>

Amazon EFS アクセスポイントのルートディレクトリを適用する方法については、「*Amazon Elastic File System ユーザーガイド*」の「[Enforcing a root directory with an access point](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html#enforce-root-directory-access-point)」を参照してください。

## [EFS.4] EFS アクセスポイントは、ユーザー ID を適用する必要があります
<a name="efs-4"></a>

**関連する要件:** NIST.800-53.r5 AC-6(2)、PCI DSS v4.0.1/7.3.1

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/efs-access-point-enforce-user-identity.html](https://docs.aws.amazon.com/config/latest/developerguide/efs-access-point-enforce-user-identity.html)

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

**パラメータ :** なし

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

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

### 修正
<a name="efs-4-remediation"></a>

Amazon EFS アクセスポイントのユーザー ID を適用する方法については、「*Amazon Elastic File System ユーザーガイド*」の「[アクセスポイントを使用したユーザー ID の適用](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html#enforce-identity-access-points)」を参照してください。

## [EFS .5] EFS アクセスポイントにはタグを付ける必要があります
<a name="efs-5"></a>

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

**重要度:** 低

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

**AWS Config rule:** `tagged-efs-accesspoint` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon EFS アクセスポイントにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。アクセスポイントにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、アクセスポイントにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、『』の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="efs-5-remediation"></a>

EFS アクセスポイントにタグを追加するには、「*Amazon Elastic File System ユーザーガイド*」の「[Amazon EFS リソースのタグ付け](https://docs.aws.amazon.com/efs/latest/ug/manage-fs-tags.html)」を参照してください。

## [EFS.6] EFS マウントターゲットは、起動時にパブリック IP アドレスを割り当てるサブネットに関連付けるべきではありません
<a name="efs-6"></a>

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/efs-mount-target-public-accessible.html](https://docs.aws.amazon.com/config/latest/developerguide/efs-mount-target-public-accessible.html)

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

**パラメータ :** なし

このコントロールは、Amazon EFS マウントターゲットが、起動時にパブリック IP アドレスを割り当てるサブネットに関連付けられているかどうかをチェックします。マウントターゲットが、起動時にパブリック IP アドレスを割り当てるサブネットに関連付けられている場合、コントロールは失敗します。

サブネットには、ネットワークインターフェイスがパブリック IPv4 アドレスと IPv6 アドレスを自動的に受信するかどうかを決定する属性があります。IPv4 `TRUE`の場合、この属性はデフォルトサブネットの場合は に、デフォルト以外のサブネット`FALSE`の場合は に設定されます (EC2 インスタンス起動ウィザードで作成されたデフォルト以外のサブネットは例外で、 に設定されます`TRUE`)。IPv6 の場合、この属性はデフォルトですべてのサブネット`FALSE`に対して に設定されます。これらの属性を有効にすると、サブネットで起動されたインスタンスは、プライマリネットワークインターフェイスで対応する IP アドレス (IPv4 または IPv6) を自動的に受け取ります。この属性が有効になっているサブネットで起動される Amazon EFS マウントターゲットでは、プライマリネットワークインターフェイスにパブリック IP アドレスが割り当てられます。

### 修正
<a name="efs-6-remediation"></a>

既存のマウントターゲットを別のサブネットに関連付けるには、起動時にパブリック IP アドレスを割り当てないサブネットに新しいマウントターゲットを作成し、古いマウントターゲットを削除する必要があります。マウントターゲットの管理については、「*Amazon Elastic File System ユーザーガイド*」の「[マウントターゲットとセキュリティグループの作成と管理](https://docs.aws.amazon.com/efs/latest/ug/accessing-fs.html)」を参照してください。

## [EFS .7] EFS ファイルシステムでは、自動バックアップが有効になっている必要があります
<a name="efs-7"></a>

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/efs-automatic-backups-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/efs-automatic-backups-enabled.html)

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

**パラメータ :** なし

このコントロールは、Amazon EFS ファイルシステムに自動バックアップが有効になっているかどうかを確認します。EFS ファイルシステムに自動バックアップが有効になっていない場合、このコントロールは失敗します。

データバックアップは、システム、設定、またはアプリケーションデータのコピーであり、元のデータとは別に保存されます。定期的なバックアップを有効にすると、システム障害、サイバー攻撃、偶発的な削除などの予期しないイベントから貴重なデータを保護することができます。堅牢なバックアップ戦略を持つことで、データ損失の可能性に直面しても、より迅速な復旧、事業継続性、安心感が得られます。

### 修正
<a name="efs-7-remediation"></a>

 AWS Backup EFS ファイルシステムで を使用する方法については、「Amazon Elastic [File System ユーザーガイド」のEFS ](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html) ファイルシステムのバックアップ」を参照してください。 *Amazon Elastic File System *

## [EFS .8] EFS ファイルシステムは保管中に暗号化する必要があります
<a name="efs-8"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/2.3.1

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/efs-filesystem-ct-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/efs-filesystem-ct-encrypted.html)

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

**パラメータ :** なし

このコントロールは、Amazon EFS ファイルシステムが AWS Key Management Service () でデータを暗号化しているかどうかをチェックしますAWS KMS。ファイルシステムが暗号化されていない場合、コントロールは失敗します。

保管中のデータとは、永続的な不揮発性ストレージに任意の期間保管されているデータを指します。保管中のデータを暗号化すると、その機密性が保護され、権限のないユーザーがアクセスするリスクが低減されます。

### 修正
<a name="efs-8-remediation"></a>

新しい EFS ファイルシステムの保管中の暗号化を有効にするには、「*Amazon Elastic File System ユーザーガイド*」の「[保管中のデータの暗号化](https://docs.aws.amazon.com/efs/latest/ug/encryption-at-rest.html)」を参照してください。

# Amazon EKS の Security Hub CSPM コントロール
<a name="eks-controls"></a>

これらの Security Hub CSPM コントロールは、Amazon Elastic Kubernetes Service (Amazon EKS) サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [EKS.1] EKS クラスターエンドポイントがパブリックにアクセスできないようにする必要があります
<a name="eks-1"></a>

**関連する要件:** NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)、PCI DSS v4.0.1/1.4.4

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/eks-endpoint-no-public-access.html](https://docs.aws.amazon.com/config/latest/developerguide/eks-endpoint-no-public-access.html)

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

**パラメータ :** なし

このコントロールは、Amazon EKS クラスターエンドポイントがパブリックにアクセス可能かどうかをチェックします。EKS クラスターにパブリックにアクセス可能なエンドポイントがある場合、コントロールは失敗します。

新しいクラスターを作成すると、Amazon EKS によって、マネージド型 Kubernetes API サーバー用にエンドポイントが作成されます。このエンドポイントは、ユーザーがクラスターとの通信に使用します。デフォルトでは、この API サーバーエンドポイントはインターネットで公開されています。API サーバーへのアクセスは、 AWS Identity and Access Management (IAM) とネイティブ Kubernetes ロールベースアクセスコントロール (RBAC) の組み合わせを使用して保護されます。エンドポイントへのパブリックアクセスを削除することで、意図しない公開やクラスターへのアクセスを防ぐことができます。

### 修正
<a name="eks-1-remediation"></a>

既存の EKS クラスターのエンドポイントアクセスを変更するには、「**Amazon EKS ユーザーガイド**」の「[クラスターエンドポイントのアクセスの変更](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html#modify-endpoint-access)」を参照してください。新しい EKS クラスターの作成時に、エンドポイントアクセスを設定できます。新しい Amazon EKS クラスターを作成する手順については、「**Amazon EKS ユーザーガイド**」の「[Amazon EKS クラスターの作成](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html)」を参照してください。

## [EKS.2] EKS クラスターは、サポートされている Kubernetes バージョンで実行する必要があります。
<a name="eks-2"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 SI-2、NIST.800-53.r5 SI-2(2)、NIST.800-53.r5 SI-2(4)、NIST.800-53.r5 SI-2(5)、PCI DSS v4.0.1/12.3.4

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/eks-cluster-supported-version.html](https://docs.aws.amazon.com/config/latest/developerguide/eks-cluster-supported-version.html)

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

**パラメータ :**
+ `oldestVersionSupported`: `1.33` (カスタマイズ不可)

このコントロールは、Amazon Elastic Kubernetes Service (Amazon EKS) クラスターが、サポートされている Kubernetes バージョンで実行されるかどうかをチェックします。EKS クラスターがサポートされていないバージョンで実行される場合、このコントロールは失敗します。

アプリケーションが Kubernetes の特定のバージョンを必要としない場合は、EKS がクラスター用にサポートしている、Kubernetes の使用可能な最新バージョンを使用することが推奨されます。詳細については、「**Amazon EKS ユーザーガイド**」の「[Amazon EKS Kubernetes リリースカレンダー](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#kubernetes-release-calendar)」と「[Amazon EKS の Kubernetes バージョンライフサイクルを理解する](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#version-deprecation)」を参照してください。

### 修正
<a name="eks-2-remediation"></a>

EKS クラスターの更新方法については、「**Amazon EKS ユーザーガイド**」の「[既存のクラスターを新しい Kubernetes バージョンに更新する](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html)」を参照してください。

## [EKS.3] EKS クラスターは暗号化された Kubernetes シークレットを使用する必要があります
<a name="eks-3"></a>

**関連する要件:** NIST.800-53.r5 SC-8、NIST.800-53.r5 SC-12、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、PCI DSS v4.0.1/8.3.2

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/eks-cluster-secrets-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/eks-cluster-secrets-encrypted.html)

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

**パラメータ :** なし

このコントロールは、Amazon EKS クラスターが暗号化された Kubernetes シークレットを使用しているかどうかを確認します。クラスターの Kubernetes シークレットが暗号化されていない場合、コントロールは失敗します。

シークレットを暗号化するときは、 AWS Key Management Service (AWS KMS) キーを使用して、クラスターの etcd に保存されている Kubernetes シークレットのエンベロープ暗号化を提供できます。この暗号化は、EKS クラスターの一部として etcd に保存されているすべてのデータ (シークレットを含む) に対してデフォルトで有効になっている EBS ボリューム暗号化に加えて行われます。EKS クラスターにシークレット暗号化を使用すると、定義して管理する KMS キーを使用して Kubernetes シークレットを暗号化することで、Kubernetes アプリケーションの防御を詳細にデプロイできます。

### 修正
<a name="eks-3-remediation"></a>

EKS クラスターでシークレット暗号化を有効にするには、「**Amazon EKS ユーザーガイド**」の「[既存のクラスターでシークレット暗号化を有効にする](https://docs.aws.amazon.com/eks/latest/userguide/enable-kms.html)」を参照してください。

## [EKS.6] EKS クラスターにはタグを付ける必要があります
<a name="eks-6"></a>

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

**重要度:** 低

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

**AWS Config rule:** `tagged-eks-cluster` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon EKS クラスターにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。クラスターにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、クラスターにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。IAM エンティティ (ユーザーまたはロール) と AWS リソースにタグをアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="eks-6-remediation"></a>

EKS クラスターにタグを追加するには、「**Amazon EKS ユーザーガイド**」の「[Amazon EKS リソースのタグ付け](https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html)」を参照してください。

## [EKS.7] EKS ID プロバイダーの設定にはタグを付ける必要があります
<a name="eks-7"></a>

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

**重要度:** 低

**リソースタイプ :** `AWS::EKS::IdentityProviderConfig`

**AWS Config rule:** `tagged-eks-identityproviderconfig` (カスタム Security Hub CSPM ルール)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon EKS ID プロバイダー設定に、パラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。設定にタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、設定にキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。IAM エンティティ (ユーザーまたはロール) と AWS リソースにタグをアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="eks-7-remediation"></a>

EKS ID プロバイダー設定にタグを追加するには、「**Amazon EKS ユーザーガイド**」の「[Amazon EKS リソースのタグ付け](https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html)」を参照してください。

## [EKS.8] EKS クラスターでは、監査ログ記録が有効になっている必要があります
<a name="eks-8"></a>

**関連する要件:** NIST.800-53.r5 AC-2(12)、NIST.800-53.r5 AC-2(4)、NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AC-6(9)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 AU-9(7)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4、NIST.800-53.r5 SI-4(20)、NIST.800-53.r5 SI-7(8)、PCI DSS v4.0.1/10.2.1

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/eks-cluster-log-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/eks-cluster-log-enabled.html)

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

**パラメータ :**
+ `logTypes: audit` (カスタマイズ不可)

このコントロールは、Amazon EKS クラスターで監査ログ記録が有効になっているかどうかをチェックします。クラスターで監査ログ記録が有効になっていない場合、コントロールは失敗します。

**注記**  
このコントロールは、 AWS アカウントの Amazon Security Lake を介して Amazon EKS 監査ログ記録が有効になっているかどうかをチェックしません。

EKS コントロールプレーンのログ記録により、アカウント内で EKS コントロールプレーンから Amazon CloudWatch Logs に対し、監査および診断ログを直接送れるようになります。必要なログタイプを選択することで、CloudWatch 内で各 EKS クラスターのためのグループに対し、ログストリームの形態でログを送信できます。ログ記録により、EKS クラスターのアクセスとパフォーマンスを可視化できます。EKS クラスターの EKS コントロールプレーンログを CloudWatch Logs に送信することで、監査と診断を目的とした操作を一元的な場所に記録できます。

### 修正
<a name="eks-8-remediation"></a>

EKS クラスターの監査ログを有効にするには、「**Amazon EKS ユーザーガイド**」の「[コントロールプレーンログの有効化と無効化](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html#enabling-control-plane-log-export)」を参照してください。

# ElastiCache の Security Hub CSPM コントロール
<a name="elasticache-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon ElastiCache サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [ElastiCache.1] ElastiCache (Redis OSS) クラスターでは自動バックアップを有効にする必要があります
<a name="elasticache-1"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6、NIST.800-53.r5 CP-6(1)、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 CP-9、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-12、NIST.800-53.r5 SI-13(5)

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

**重要度:** 高

**リソースタイプ:** `AWS::ElastiCache::CacheCluster`、`AWS:ElastiCache:ReplicationGroup`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elasticache-redis-cluster-automatic-backup-check.html](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-redis-cluster-automatic-backup-check.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `snapshotRetentionPeriod`  |  最小スナップショット保持期間 (日数)  |  整数  |  `1`～`35`  |  `1`  | 

このコントロールは、Amazon ElastiCache (Redis OSS) クラスターで自動バックアップが有効になっているかどうかを評価します。Redis OSS クラスターの `SnapshotRetentionLimit` が指定された期間未満の場合、コントロールは失敗します。スナップショット保持期間にカスタムパラメータ値を指定しない限り、Security Hub CSPM はデフォルト値の 1 日を使用します。

ElastiCache (Redis OSS) クラスターでは、データをバックアップできます。バックアップを使用して、クラスターを復元したり、新しいクラスターをシードしたりできます。バックアップは、クラスター内の全データとクラスターのメタデータで構成されます。すべてのバックアップは、堅牢なストレージを提供する Amazon S3 に書き込まれます。新しい ElastiCache クラスターを作成し、バックアップのデータを挿入することでデータを復元できます。バックアップは AWS マネジメントコンソール、、 AWS CLI、および ElastiCache API を使用して管理できます。

**注記**  
このコントロールは、ElastiCache (Redis OSS および Valkey) レプリケーショングループも評価します。

### 修正
<a name="elasticache-1-remediation"></a>

ElastiCache クラスターの自動バックアップのスケジュールについては、「*Amazon ElastiCache ユーザーガイド*」の「[自動バックアップのスケジュール](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups-automatic.html)」を参照してください。

## [ElastiCache.2] ElastiCache クラスターでは、マイナーバージョンの自動アップグレードを有効にする必要があります。
<a name="elasticache-2"></a>

**関連する要件:** NIST.800-53.r5 SI-2、NIST.800-53.r5 SI-2(2)、NIST.800-53.r5 SI-2(4)、NIST.800-53.r5 SI-2(5)、PCI DSS v4.0.1/6.3.3

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

**重要度:** 高

**リソースタイプ :** `AWS::ElastiCache::CacheCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elasticache-auto-minor-version-upgrade-check.html](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-auto-minor-version-upgrade-check.html)

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

**パラメータ :** なし

このコントロールは、Amazon ElastiCache がキャッシュクラスターにマイナーバージョンアップグレードを自動的に適用するかどうかを評価します。キャッシュクラスターにマイナーバージョンアップグレードを自動的に適用しない場合、コントロールは失敗します。

**注記**  
このコントロールは ElastiCache Memcached クラスターには適用されません。

自動マイナーバージョンアップグレードは、新しいマイナーキャッシュエンジンバージョンが利用可能になるとキャッシュクラスターを自動的にアップグレードできる機能であり、Amazon ElastiCache で有効化できます。これらのアップグレードには、セキュリティパッチとバグ修正を含む場合があります。パッチのインストールを最新の状態に保つことは、システムを保護する上で重要なステップです。

### 修正
<a name="elasticache-2-remediation"></a>

既存の ElastiCache キャッシュクラスターにマイナーバージョンアップグレードを自動的に適用するには、「*Amazon ElastiCache ユーザーガイド*」の「[ElastiCache のバージョン管理](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/VersionManagement.html)」を参照してください。

## [ElastiCache.3] ElastiCache (Redis OSS) レプリケーショングループでは、自動フェイルオーバーを有効にする必要があります
<a name="elasticache-3"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 SC-36、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)

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

**重要度:** 中

**リソースタイプ :** `AWS::ElastiCache::ReplicationGroup`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elasticache-repl-grp-auto-failover-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-repl-grp-auto-failover-enabled.html)

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

**パラメータ :** なし

このコントロールは、Amazon ElastiCache レプリケーショングループの自動フェイルオーバーが有効になっているかどうかをチェックします。Redis OSS プリケーショングループで自動フェイルオーバーが有効になっていない場合、コントロールは失敗します。

レプリケーショングループで自動フェイルオーバーを有効にすると、プライマリノードのロールは、いずれかのリードレプリカに自動的にフェイルオーバーされます。このフェイルオーバーとレプリカの昇格により、昇格の完了後すぐに新しいプライマリへの書き込みを再開できるため、障害発生時も全体のダウンタイムを短縮できます。

### 修正
<a name="elasticache-3-remediation"></a>

既存の ElastiCache レプリケーショングループの自動フェイルオーバーを有効にするには、「*Amazon ElastiCache ユーザーガイド*」の「[ElastiCache クラスターの変更](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Clusters.Modify.html#Clusters.Modify.CON)」を参照してください。ElastiCache コンソールを使用する場合は、**[自動フェイルオーバー]** を有効に設定します。

## [ElastiCache.4] ElastiCache レプリケーショングループは保管中に暗号化する必要があります
<a name="elasticache-4"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SI-7(6)

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

**重要度:** 中

**リソースタイプ :** `AWS::ElastiCache::ReplicationGroup`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elasticache-repl-grp-encrypted-at-rest.html](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-repl-grp-encrypted-at-rest.html)

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

**パラメータ :** なし

このコントロールは、ElastiCache レプリケーショングループが保管時に暗号化されているかどうかをチェックします。レプリケーショングループが保管時に暗号化されていない場合、コントロールは失敗します。

保管中のデータを暗号化すると、認証されていないユーザーがディスクに保存しているデータにアクセスするリスクが低減されます。ElastiCache (Redis OSS) レプリケーショングループは、セキュリティを強化するために、保管中に暗号化する必要があります。

### 修正
<a name="elasticache-4-remediation"></a>

ElastiCache レプリケーショングループで保管中の暗号化を設定するには、「*Amazon ElastiCache ユーザーガイド*」の「[保管時の暗号化を有効にする](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/at-rest-encryption.html#at-rest-encryption-enable)」を参照してください。

## [ElastiCache.5] ElastiCache レプリケーショングループは転送時に暗号化する必要があります
<a name="elasticache-5"></a>

**関連する要件:** NIST.800-53.r5 AC-17(2)、NIST.800-53.r5 AC-4、NIST.800-53.r5 IA-5(1)、NIST.800-53.r5 SC-12(3)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-23、NIST.800-53.r5 SC-23(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-8、NIST.800-53.r5 SC-8(1)、NIST.800-53.r5 SC-8(2)、NIST.800-53.r5 SI-7(6)、PCI DSS v4.0.1/4.2.1

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

**重要度:** 中

**リソースタイプ :** `AWS::ElastiCache::ReplicationGroup`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elasticache-repl-grp-encrypted-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-repl-grp-encrypted-in-transit.html)

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

**パラメータ :** なし

このコントロールは、ElastiCache レプリケーショングループが転送中に暗号化されているかどうかをチェックします。レプリケーショングループが転送中に暗号化されていない場合、コントロールは失敗します。

転送中のデータを暗号化することで、権限のないユーザーがネットワークトラフィックを盗聴するリスクが軽減されます。ElastiCache レプリケーショングループで転送中の暗号化を有効にすると、ある場所から別の場所に移動するデータ (クラスターのノード間、クラスターとアプリケーション間など) に対して必ず暗号化が行なわれます。

### 修正
<a name="elasticache-5-remediation"></a>

ElastiCache レプリケーショングループで転送中の暗号化を設定するには、「*Amazon ElastiCache ユーザーガイド*」の「[転送時の暗号化を有効にする](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/in-transit-encryption.html)」を参照してください。

## [ElastiCache.6] 以前のバージョンの ElastiCache (Redis OSS) レプリケーショングループでは Redis OSS AUTH を有効にする必要があります
<a name="elasticache-6"></a>

**関連する要件:** NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-6、PCI DSS v4.0.1/8.3.1

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

**重要度:** 中

**リソースタイプ :** `AWS::ElastiCache::ReplicationGroup`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elasticache-repl-grp-redis-auth-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-repl-grp-redis-auth-enabled.html)

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

**パラメータ :** なし

このコントロールは、ElastiCache (Redis OSS) レプリケーショングループの Redis OSS AUTH が有効になっているかどうかを確認します。Redis OSS バージョンが 6.0 より前で `AuthToken` が使用されていない場合、ElastiCache for Redis レプリケーショングループのコントロールは失敗します。

Redis 認証トークンまたはパスワードを使用すると、Redis はクライアントにコマンドの実行を許可する前にパスワードを要求するため、データのセキュリティが向上します。Redis 6.0 以降のバージョンでは、ロールベースのアクセス制御 (RBAC) の使用をお勧めします。RBAC は 6.0 より前のバージョンの Redis ではサポートされていないため、このコントロールは RBAC 機能を使用できないバージョンのみを評価します。

### 修正
<a name="elasticache-6-remediation"></a>

ElastiCache (Redis OSS) レプリケーショングループで Redis AUTH を使用するには、「*Amazon ElastiCache ユーザーガイド*」の「[既存の ElastiCache (Redis OSS) クラスターでの AUTH トークンの変更](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/auth.html#auth-modifyng-token)」を参照してください。

## [ElastiCache.7] ElastiCache クラスターでは、デフォルトのサブネットグループを使用しないでください
<a name="elasticache-7"></a>

**関連する要件:** NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(5)

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

**重要度:** 高

**リソースタイプ :** `AWS::ElastiCache::CacheCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elasticache-subnet-group-check.html](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-subnet-group-check.html)

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

**パラメータ :** なし

このコントロールは、ElastiCache クラスターにカスタムサブネットグループが設定されているかどうかをチェックします。ElastiCache クラスターの `CacheSubnetGroupName` の値が `default` である場合、コントロールは失敗します。

ElastiCache クラスターを起動すると、デフォルトのサブネットグループがまだ存在しない場合は作成されます。デフォルトグループは、デフォルトの仮想プライベートクラウド (VPC) のサブネットを使用します。クラスターが存在するサブネットや、クラスターがサブネットから継承するネットワークの制限機能がより強力な、カスタムサブネットグループを使用することをお勧めします。

### 修正
<a name="elasticache-7-remediation"></a>

ElastiCache クラスターの新しいサブネットグループを作成するには、「*Amazon ElastiCache ユーザーガイド*」の「[サブネットグループの作成](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/SubnetGroups.Creating.html)」を参照してください。

# Elastic Beanstalk の Security Hub CSPM コントロール
<a name="elasticbeanstalk-controls"></a>

これらの AWS Security Hub CSPM コントロールは、 AWS Elastic Beanstalk サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [ElasticBeanstalk.1] Elastic Beanstalk 環境では、拡張ヘルスレポートを有効にする必要があります。
<a name="elasticbeanstalk-1"></a>

**関連する要件:** NIST.800-53.r5 CA-7、NIST.800-53.r5 SI-2

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

**重要度:** 低

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/beanstalk-enhanced-health-reporting-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/beanstalk-enhanced-health-reporting-enabled.html)

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

**パラメータ:** なし

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

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

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

詳細については、「AWS Elastic Beanstalk 開発者ガイド」の「[拡張ヘルスレポートおよびモニタリング](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/health-enhanced.html)」を参照してください。

### 修正
<a name="elasticbeanstalk-1-remediation"></a>

拡張ヘルスレポートを有効にする手順については、「AWS Elastic Beanstalk 開発者ガイド」の「[Elastic Beanstalk コンソールを使用した拡張ヘルスレポートの有効化](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/health-enhanced-enable.html#health-enhanced-enable-console)」を参照してください。

## [ElasticBeanstalk.2] Elastic Beanstalk のマネージドプラットフォームの更新を有効にする必要があります
<a name="elasticbeanstalk-2"></a>

**関連する要件:** NIST.800-53.r5 SI-2、NIST.800-53.r5 SI-2(2)、NIST.800-53.r5 SI-2(4)、NIST.800-53.r5 SI-2(5)、PCI DSS v4.0.1/6.3.3

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elastic-beanstalk-managed-updates-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/elastic-beanstalk-managed-updates-enabled.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `UpdateLevel`  |  バージョン更新レベル  |  列挙型  |  `minor`, `patch`  |  デフォルト値なし  | 

このコントロールは、Elastic Beanstalk 環境でマネージドプラットフォームの更新が有効になっているかどうかをチェックします。マネージドプラットフォームの更新が有効になっていない場合、コントロールは失敗します。デフォルトでは、何らかのプラットフォーム更新が有効になっていればコントロールは成功します。必要に応じて、特定の更新レベルを要求するカスタムパラメータ値を指定できます。

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

### 修正
<a name="elasticbeanstalk-2-remediation"></a>

マネージドプラットフォームの更新を有効にするには、「*AWS Elastic Beanstalk デベロッパーガイド*」の「[To configure managed platform updates under Managed platform updates](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environment-platform-update-managed.html)」を参照してください。

## [ElasticBeanstalk.3] Elastic Beanstalk は CloudWatch にログをストリーミングする必要があります
<a name="elasticbeanstalk-3"></a>

**関連する要件:** PCI DSS v4.0.1/10.4.2

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

**重要度:** 高

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elastic-beanstalk-logs-to-cloudwatch.html](https://docs.aws.amazon.com/config/latest/developerguide/elastic-beanstalk-logs-to-cloudwatch.html)

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

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `RetentionInDays`  |  有効期限が切れるまでログイベントを保持する日数  |  列挙型  |  `1`, `3`, `5`, `7`, `14`, `30`, `60`, `90`, `120`, `150`, `180`, `365` , `400`, `545`, `731`, `1827`, `3653`   |  デフォルト値なし  | 

このコントロールは、Elastic Beanstalk 環境が CloudWatch Logs にログを送信するように設定されているかどうかをチェックします。Elastic Beanstalk 環境が CloudWatch Logs にログを送信するように設定されていない場合、コントロールは失敗します。有効期限が切れる前の指定された日数だけログが保持される場合にのみコントロールを成功させたい場合は、必要に応じて `RetentionInDays` パラメータにカスタム値を指定できます。

CloudWatch は、アプリケーションやインフラストラクチャリソースのさまざまなメトリクスを収集して監視するのに役立ちます。CloudWatch を使用して、特定のメトリックスに基づいてアラームアクションを設定することもできます。Elastic Beanstalk 環境への可視性を高めるために、Elastic Beanstalk を CloudWatch と統合することをおすすめします。Elastic Beanstalk のログには、eb-activity.log、その環境の nginx または Apache プロキシサーバーからのアクセスログ、および環境に固有のログが含まれます。

### 修正
<a name="elasticbeanstalk-3-remediation"></a>

Elastic Beanstalk を CloudWatch Logs と統合するには、「*AWS Elastic Beanstalk デベロッパーガイド*」の「[CloudWatch Logs へのインスタンスログのストリーミング](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo.cloudwatchlogs.html#AWSHowTo.cloudwatchlogs.streaming)」を参照してください。

# Elastic Load Balancing の Security Hub CSPM コントロール
<a name="elb-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Elastic Load Balancing サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [ELB.1] Application Load Balancer は、すべての HTTP リクエストを HTTPS にリダイレクトするように設定する必要があります
<a name="elb-1"></a>

**関連する要件:** PCI DSS v3.2.1/2.3、PCI DSS v3.2.1/4.1、NIST.800-53.r5 AC-17(2)、NIST.800-53.r5 AC-4、NIST.800-53.r5 IA-5(1)、NIST.800-53.r5 SC-12(3)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-23、NIST.800-53.r5 SC-23(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-8、NIST.800-53.r5 SC-8(1)、NIST.800-53.r5 SC-8(2)、NIST.800-53.r5 SI-7(6)

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/alb-http-to-https-redirection-check.html](https://docs.aws.amazon.com/config/latest/developerguide/alb-http-to-https-redirection-check.html) 

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

**パラメータ:** なし

このコントロールは、HTTP から HTTPS へのリダイレクトが Application Load Balancer のすべての HTTP リスナーで設定されているかどうかを確認します。HTTP から HTTPS へのリダイレクトが設定されていない Application Load Balancer の HTTP リスナーがある場合、コントロールは失敗します。

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

詳細については、「Application Load Balancer ユーザーガイド」の「[Application Load Balancer のリスナー](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html)」を参照してください。

### 修正
<a name="elb-1-remediation"></a>

HTTP リクエストを HTTPS にリダイレクトするには、Application Load Balancer のリスナールールを追加するか、既存のルールを編集する必要があります。

新しいルールを追加する手順については、「*Application Load Balancer ユーザーガイド*」の「[ルールの追加](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-update-rules.html#add-rule)」を参照してください。**[プロトコル: ポート]** で **[HTTP]** を選択し、**80** と入力します。**[アクションの追加、リダイレクト先]** で **[HTTPS]** を選択し、**443** と入力します。

既存のルールを編集する手順については、「*Application Load Balancer ユーザーガイド*」の「[ルールの編集](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-update-rules.html#edit-rule)」を参照してください。**[プロトコル: ポート]** で **[HTTP]** を選択し、**80** と入力します。**[アクションの追加、リダイレクト先]** で **[HTTPS]** を選択し、**443** と入力します。

## [ELB.2] SSL/HTTPS リスナーを使用する Classic Load Balancer は、 が提供する証明書を使用する必要があります AWS Certificate Manager
<a name="elb-2"></a>

**関連する要件:** NIST.800-53.r5 AC-17(2)、NIST.800-53.r5 AC-4、NIST.800-53.r5 IA-5(1)、NIST.800-53.r5 SC-12(3)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-23、NIST.800-53.r5 SC-23(5)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-8、NIST.800-53.r5 SC-8(1)、NIST.800-53.r5 SC-8(2)、NIST.800-53.r5 SI-7(6)、NIST.800-171.r2 3.13.8

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elb-acm-certificate-required.html](https://docs.aws.amazon.com/config/latest/developerguide/elb-acm-certificate-required.html)

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

**パラメータ:** なし

Classic Load Balancer が AWS Certificate Manager (ACM) によって提供される HTTPS/SSL 証明書を使用しているかどうかをチェックします。HTTPS/SSL リスナーで構成された Classic Load Balancer が ACM によって提供される証明書を使用しない場合、コントロールは失敗します。

証明書の作成には、ACM または SSL や TLS プロトコルをサポートする OpenSSL などのツールを使用できます。Security Hub CSPM では、ACM を使用してロードバランサーの証明書を作成またはインポートすることをお勧めします。

ACM は Classic Load Balancer と統合して、ロードバランサーに証明書をデプロイできます。また、これらの証明書は自動的に更新する必要があります。

### 修正
<a name="elb-2-remediation"></a>

ACM SSL/TLS 証明書を Classic Load Balancer に関連付ける方法については、 AWS ナレッジセンターの記事[「ACM SSL/TLS 証明書を Classic、Application、または Network Load Balancer に関連付けるにはどうすればよいですか？」を参照してください。](https://aws.amazon.com/premiumsupport/knowledge-center/associate-acm-certificate-alb-nlb/)

## [ELB.3] Classic Load Balancer のリスナーは、HTTPS または TLS ターミネーションで設定する必要があります
<a name="elb-3"></a>

**関連する要件:** NIST.800-53.r5 AC-17(2)、NIST.800-53.r5 AC-4、NIST.800-53.r5 IA-5(1)、NIST.800-53.r5 SC-12(3)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-23、NIST.800-53.r5 SC-23(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-8、NIST.800-53.r5 SC-8(1)、NIST.800-53.r5 SC-8(2)、NIST.800-53.r5 SI-7(6)、NIST.800-171.r2 3.13.8、NIST.800-171.r2 3.13.15、PCI DSS v4.0.1/4.2.1

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elb-tls-https-listeners-only.html](https://docs.aws.amazon.com/config/latest/developerguide/elb-tls-https-listeners-only.html)

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

**パラメータ:** なし

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

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

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

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

### 修正
<a name="elb-3-remediation"></a>

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

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

1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。

1. ナビゲーションペインの [**Load Balancing**] で、[**Load Balancers**] を選択します。

1. Classic Load Balancer を選択します。

1. [**Listeners**] タブで、[**Edit**] を選択します。

1. すべてのリスナーについて、**[Load Balancer Protocol]** (ロードバランサーのプロトコル) が HTTPS または SSL に設定されていない場合は、設定を HTTPS または SSL に変更します。

1. 変更されたすべてのリスナーに対して、**[証明書]** タブで **[デフォルトの変更]** を選択します。

1. **[ACM 証明書と IAM 証明書]**の場合は、証明書を選択します。

1. **[デフォルトとして保存]** を選択します。

1. すべてのリスナーを更新したら、**[Save]** (保存) を選択します。

## [ELB.4] Application Load Balancer は、無効な http ヘッダーを削除するように設定する必要があります
<a name="elb-4"></a>

**関連する要件:** NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-8(2)、PCI DSS v4.0.1/6.2.4

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/alb-http-drop-invalid-header-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/alb-http-drop-invalid-header-enabled.html)

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

**パラメータ :** なし

このコントロールは、 Application Load Balancer が無効な HTTP ヘッダーを削除するように設定されているかどうかを評価します。`routing.http.drop_invalid_header_fields.enabled` の値が `false` に設定されている場合、コントロールは失敗します。

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

**注記**  
アカウントで ELB.12 が有効になっている場合は、このコントロールを無効にすることをお勧めします。詳細については、「[[ELB.12] Application Load Balancer は、防御モードまたは最も厳密な非同期緩和モードで構成する必要があります](#elb-12)」を参照してください。

### 修正
<a name="elb-4-remediation"></a>

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

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

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

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

1. Application Load Balancer を選択します。

1. **[Actions]** (アクション) で、**[Edit attributes]** (属性の編集) を選択します。

1. **[Drop Invalid Header Fields]** (無効なヘッダーフィールドを削除) で、**[Enable]** (有効) を選択します。

1. **[Save]** (保存) を選択します。

## [ELB.5] アプリケーションおよび Classic Load Balancer のログ記録を有効にする必要があります
<a name="elb-5"></a>

**関連する要件:** NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-7(8)

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

**重要度:** 中

**リソースタイプ:** `AWS::ElasticLoadBalancing::LoadBalancer`、`AWS::ElasticLoadBalancingV2::LoadBalancer`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elb-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/elb-logging-enabled.html)

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

**パラメータ:** なし

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

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

詳細については、「Classic Load Balancer ユーザーガイド」の「[Classic Load Balancerのアクセスログ](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/access-log-collection.html)」を参照してください。

### 修正
<a name="elb-5-remediation"></a>

アクセスログを有効にするには、「*Application Load Balancer ユーザーガイド*」の「[ステップ 3: アクセスログの設定](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/enable-access-logging.html#enable-access-logs)」を参照してください。

## [ELB.6] アプリケーション、ゲートウェイ、および Network Load Balancer で削除保護を有効にする必要があります
<a name="elb-6"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)、NIST.800-53.r5 CM-3、NIST.800-53.r5 SC-5(2)

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

**重要度:** 中

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

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elb-deletion-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/elb-deletion-protection-enabled.html)

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

**パラメータ :** なし

このコントロールは、アプリケーション、ゲートウェイ、または Network Load Balancer で削除保護が有効になっているかどうかをチェックします。削除保護が無効になっている場合、コントロールは失敗します。

削除保護を有効にして、アプリケーション、ゲートウェイ、または Network Load Balancer を削除されないよう保護します。

### 修正
<a name="elb-6-remediation"></a>

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

ロードバランサーの削除保護を有効にした場合、ロードバランサーを削除する前に無効にする必要があります。

Application Load Balancer の削除保護については、「*Application Load Balancer ユーザーガイド*」の「[削除保護](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#deletion-protection)」を参照してください。Gateway Load Balancer の削除保護については、「*Gateway Load Balancer ユーザーガイド*」の「[削除保護](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/gateway-load-balancers.html#deletion-protection)」を参照してください。Network Load Balancer の削除保護については、「*Network Load Balancer ユーザーガイド*」の「[削除保護](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html#deletion-protection)」を参照してください。

## [ELB.7] Classic Load Balancers は、Connection Draining を有効にする必要があります
<a name="elb-7"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2

**カテゴリ:** リカバリ > 耐障害性

**重要度:** 低

**リソースタイプ :** `AWS::ElasticLoadBalancing::LoadBalancer`

**AWS Config rule:** `elb-connection-draining-enabled` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ:** なし

このコントロールは、Classic Load Balancers で Connection Draining が有効になっているかどうかをチェックします。

Classic Load Balancers で Connection Draining を有効にすることで、ロードバランサーは、登録解除中のインスタンスまたは異常の発生したインスタンスへのリクエストの送信を確実に停止します。既存の接続を開いたままにします。これは、Auto Scaling グループのインスタンスで、接続が突然切断されないようにするために特に役立ちます。

### 修正
<a name="elb-7-remediation"></a>

Classic Load Balancer で Connection Draining を有効にするには、「*Classic Load Balancer ユーザーガイド*」の「[Classic Load Balancer の Connection Draining の設定](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/config-conn-drain.html)」を参照してください。

## [ELB.8] SSL リスナーを使用する Classic Load Balancer は、強力な uration AWS Configを持つ事前定義されたセキュリティポリシーを使用する必要があります
<a name="elb-8"></a>

**関連する要件:** NIST.800-53.r5 AC-17(2)、NIST.800-53.r5 AC-4、NIST.800-53.r5 IA-5(1)、NIST.800-53.r5 SC-12(3)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-23、NIST.800-53.r5 SC-23(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-8、NIST.800-53.r5 SC-8(1)、NIST.800-53.r5 SC-8(2)、NIST.800-53.r5 SI-7(6)、NIST.800-171.r2 3.13.8、NIST.800-171.r2 3.13.15、PCI DSS v4.0.1/4.2.1

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::ElasticLoadBalancing::LoadBalancer`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elb-predefined-security-policy-ssl-check.html](https://docs.aws.amazon.com/config/latest/developerguide/elb-predefined-security-policy-ssl-check.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**
+ `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 セキュリティポリシー](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)」を参照してください。

### 修正
<a name="elb-8-remediation"></a>

Classic Load Balancer で定義済みのセキュリティポリシー `ELBSecurityPolicy-TLS-1-2-2017-01` を使用する方法については、「Classic Load Balancer ユーザーガイド」の「[セキュリティ設定の構成](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-create-https-ssl-load-balancer.html#config-backend-auth)」を参照してください。

## [ELB.9] Classic Load Balancer では、クロスゾーンロードバランシングが有効になっている必要があります
<a name="elb-9"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 SC-36、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)

**カテゴリ:** リカバリ > 耐障害性 > 高可用性

**重要度:** 中

**リソースタイプ :** `AWS::ElasticLoadBalancing::LoadBalancer`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elb-cross-zone-load-balancing-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/elb-cross-zone-load-balancing-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、クロスゾーンロードバランシングが Classic Load Balancer (CLB) に対して有効になっているかどうかをチェックします。クロスゾーンロードバランシングが CLB に対して有効になっていない場合、コントロールは失敗します。

ロードバランサノードは、アベイラビリティーゾーン内の登録済みターゲット全体にのみトラフィックを分散します。クロスゾーンロードバランシングが無効の場合、各ロードバランサーノードは、そのアベイラビリティーゾーンの登録済みターゲットにのみトラフィックを分散します。登録済みターゲット数がアベイラビリティーゾーン間で同じでない場合、トラフィックは均等に分散されず、あるゾーンのインスタンスは、別のゾーンのインスタンスと比較して過剰に使用される可能性があります。クロスゾーンロードバランシングを有効にすると、Classic Load Balancer の各ロードバランサーノードは、有効なすべてのアベイラビリティーゾーンに登録済みのインスタンスにリクエストを均等に分散します。詳細については、「Elastic Load Balancing ユーザーガイド」の「[クロスゾーンロードバランシング](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#cross-zone-load-balancing)」を参照してください。

### 修正
<a name="elb-9-remediation"></a>

Classic Load Balancer でクロスゾーンロードバランシングを有効にするには、「*Classic Load Balancer ユーザーガイド*」の「[クロスゾーンロードバランシングを有効にする](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-disable-crosszone-lb.html#enable-cross-zone)」を参照してください。

## [ELB.10] Classic Load Balancer は、複数のアベイラビリティーゾーンにまたがっている必要があります
<a name="elb-10"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 SC-36、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)

**カテゴリ:** リカバリ > 耐障害性 > 高可用性

**重要度:** 中

**リソースタイプ :** `AWS::ElasticLoadBalancing::LoadBalancer`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/clb-multiple-az.html](https://docs.aws.amazon.com/config/latest/developerguide/clb-multiple-az.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `minAvailabilityZones`  |  アベイラビリティーゾーンの最小数  |  列挙型  |  `2, 3, 4, 5, 6`  |  `2`  | 

このコントロールは、Classic Load Balancer が少なくとも指定された数のアベイラビリティーゾーン (AZ) にまたがるように設定されているかどうかをチェックします。Classic Load Balancer が少なくとも指定された数の AZ にまたがっていない場合、コントロールは失敗します。AZs の最小数にカスタムパラメータ値を指定しない限り、Security Hub CSPM はデフォルト値の 2 つの AZs を使用します。

 Classic Load Balancer は、単一のアベイラビリティーゾーンまたは複数のアベイラビリティーゾーンにある Amazon EC2 インスタンスに受信リクエストを配信するように設定できます。複数のアベイラビリティーゾーンにまたがらない Classic Load Balancer は、単独で構成されたアベイラビリティーゾーンが使用できなくなった場合、別のアベイラビリティーゾーンのターゲットにトラフィックをリダイレクトすることはできません。

### 修正
<a name="elb-10-remediation"></a>

 Classic Load Balancer にアベイラビリティーゾーンを追加するには、「*Classic Load Balancer ユーザーガイド*」の「[Add or remove subnets for your Classic Load Balancer](https://docs.aws.amazon.com//elasticloadbalancing/latest/classic/elb-manage-subnets.html)」を参照してください。

## [ELB.12] Application Load Balancer は、防御モードまたは最も厳密な非同期緩和モードで構成する必要があります
<a name="elb-12"></a>

**関連する要件:** NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、PCI DSS v4.0.1/6.2.4

**カテゴリ:** 保護 > データ保護 > データの整合性

**重要度:** 中

**リソースタイプ :** `AWS::ElasticLoadBalancingV2::LoadBalancer`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/alb-desync-mode-check.html](https://docs.aws.amazon.com/config/latest/developerguide/alb-desync-mode-check.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**
+ `desyncMode`: `defensive, strictest` (カスタマイズ不可)

このコントロールは、Application Load Balancer が防御モードまたは最も厳密な非同期緩和モードに設定されているかどうかをチェックします。Application Load Balancer が防御モードまたは最も厳密な非同期緩和モードに設定されていない場合、このコントロールは失敗します。

HTTP 非同期の問題はリクエストスマグリングにつながり、アプリケーションがリクエストキューやキャッシュポイズニングに対して脆弱になる可能性があります。そしてこうした脆弱性は、認証情報スタッフィングや不正なコマンドの実行につながります。防御モードまたは最も厳密な非同期緩和モードで構成された Application Load Balancer は、HTTP 非同期に起因するセキュリティ上の問題からアプリケーションを保護します。

### 修正
<a name="elb-12-remediation"></a>

Application Load Balancer の非同期緩和モードの更新方法については、「*Application Load Balancer ユーザーガイド*」の「[Desync mitigation mode](https://docs.aws.amazon.com//elasticloadbalancing/latest/application/application-load-balancers.html#desync-mitigation-mode)」(非同期緩和モード) を参照してください。

## [ELB.13] Application、Network、Gateway Load Balancer は、複数のアベイラビリティーゾーンにまたがっている必要があります
<a name="elb-13"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 SC-36、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)

**カテゴリ:** リカバリ > 耐障害性 > 高可用性 

**重要度:** 中

**リソースタイプ :** `AWS::ElasticLoadBalancingV2::LoadBalancer`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elbv2-multiple-az.html](https://docs.aws.amazon.com/config/latest/developerguide/elbv2-multiple-az.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `minAvailabilityZones`  |  アベイラビリティーゾーンの最小数  |  列挙型  |  `2, 3, 4, 5, 6`  |  `2`  | 

このコントロールは、Elastic Load Balancer V2 (アプリケーション、ネットワーク、または Gateway Load Balancer) に少なくとも指定された数のアベイラビリティーゾーン (AZ) のインスタンスが登録されているかどうかをチェックします。Elastic Load Balancer V2 で、少なくとも指定された数の AZ にインスタンスが登録されていない場合、コントロールは失敗します。AZs の最小数にカスタムパラメータ値を指定しない限り、Security Hub CSPM はデフォルト値の 2 つの AZs を使用します。

Elastic Load Balancing は、受信したトラフィックを複数のアベイラビリティーゾーンの複数のターゲット (EC2 インスタンス、コンテナ、IP アドレスなど) に自動的に分散させます。Elastic Load Balancing は、受信トラフィックの時間的な変化に応じて、ロードバランサーをスケーリングします。サービスの可用性を確保するため、2 つ以上のアベイラビリティーゾーンを設定することが推奨されます。それにより、Elastic Load Balancer はアベイラビリティーゾーンを使用できなくなったときに、別のアベイラビリティーゾーンにトラフィックを転送することができます。複数のアベイラビリティーゾーンを設定しておくと、アプリケーションの単一障害点を回避できます。

### 修正
<a name="elb-13-remediation"></a>

アベイラビリティーゾーンを Application Load Balancer に追加する方法については、「*Application Load Balancer ユーザーガイド*」の「[Application Load Balancer のアベイラビリティーゾーン](https://docs.aws.amazon.com//elasticloadbalancing/latest/application/load-balancer-subnets.html)」参照してください。アベイラビリティーゾーンを Network Load Balancer に追加する方法については、「*Network Load Balancer ユーザーガイド*」の「[Network Load Balancer](https://docs.aws.amazon.com//elasticloadbalancing/latest/network/network-load-balancers.html#availability-zones)」を参照してください。アベイラビリティーゾーンを Gateway Load Balancer に追加する方法については、「*Gateway Load Balancer ユーザーガイド*」の「[Create a Gateway Load Balancer](https://docs.aws.amazon.com//elasticloadbalancing/latest/gateway/create-load-balancer.html)」を参照してください。

## [ELB.14] Classic Load Balancer は、防御モードまたは最も厳密な非同期緩和モードで設定する必要があります
<a name="elb-14"></a>

**関連する要件:** NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、PCI DSS v4.0.1/6.2.4

**カテゴリ:** 保護 > データ保護 > データの整合性

**重要度:** 中

**リソースタイプ :** `AWS::ElasticLoadBalancing::LoadBalancer`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/clb-desync-mode-check.html](https://docs.aws.amazon.com/config/latest/developerguide/clb-desync-mode-check.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**
+ `desyncMode`: `defensive, strictest` (カスタマイズ不可)

このコントロールは、Classic Load Balancer が防御モードまたは最も厳密な非同期緩和モードで設定されているかどうかをチェックします。Classic Load Balancer が防御モードまたは最も厳密な非同期緩和モードに設定されていない場合、このコントロールは失敗します。

HTTP 非同期の問題はリクエストスマグリングにつながり、アプリケーションがリクエストキューやキャッシュポイズニングに対して脆弱になる可能性があります。そしてこうした脆弱性は、認証情報の乗っ取りや不正なコマンドの実行につながります。防御モードまたは最も厳密な非同期緩和モードで構成された Classic Load Balancer は、HTTP 非同期に起因するセキュリティ上の問題からアプリケーションを保護します。

### 修正
<a name="elb-14-remediation"></a>

Classic Load Balancer の非同期緩和モードの更新方法については、「*Classic Load Balancer ユーザーガイド*」の「[非同期緩和モードの変更](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/config-desync-mitigation-mode.html#update-desync-mitigation-mode)」を参照してください。

## [ELB.16] Application Load Balancer は AWS WAF ウェブ ACL に関連付ける必要があります
<a name="elb-16"></a>

**関連する要件:** NIST.800-53.r5 AC-4(21)

**カテゴリ:** 保護 > 保護サービス

**重要度:** 中

**リソースタイプ :** `AWS::ElasticLoadBalancingV2::LoadBalancer`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/alb-waf-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/alb-waf-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Application Load Balancer が AWS WAF Classic または AWS WAF ウェブアクセスコントロールリスト (ウェブ ACL) に関連付けられているかどうかをチェックします。 AWS WAF 設定の `Enabled`フィールドが に設定されている場合、コントロールは失敗します`false`。

AWS WAF は、ウェブアプリケーションと APIsから保護するのに役立つウェブアプリケーションファイアウォールです。を使用すると AWS WAF、ウェブ ACL を設定できます。これは、定義したカスタマイズ可能なウェブセキュリティルールと条件に基づいてウェブリクエストを許可、ブロック、またはカウントする一連のルールです。Application Load Balancer を AWS WAF ウェブ ACL に関連付けて、悪意のある攻撃から保護することをお勧めします。

### 修正
<a name="elb-16-remediation"></a>

Application Load Balancer をウェブ ACL に関連付けるには、[「 デベロッパーガイド」の「ウェブ ACL と AWS リソースの関連付けまたは関連付け解除](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-associating-aws-resource.html)」を参照してください。 *AWS WAF *

## [ELB.17] リスナーを使用する Application Load Balancer と Network Load Balancer は、推奨されるセキュリティポリシーを使用する必要があります。
<a name="elb-17"></a>

**関連する要件:** NIST.800-53.r5 AC-17(2)、NIST.800-53.r5 AC-4、NIST.800-53.r5 IA-5(1)、NIST.800-53.r5 SC-12(3)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-23、NIST.800-53.r5 SC-23(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-8、NIST.800-53.r5 SC-8(1)、NIST.800-53.r5 SC-8(2)、NIST.800-53.r5 SI-7(6)

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::ElasticLoadBalancingV2::Listener`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elbv2-predefined-security-policy-ssl-check.html](https://docs.aws.amazon.com/config/latest/developerguide/elbv2-predefined-security-policy-ssl-check.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ:** `sslPolicies`: `ELBSecurityPolicy-TLS13-1-2-2021-06, ELBSecurityPolicy-TLS13-1-2-FIPS-2023-04, ELBSecurityPolicy-TLS13-1-3-2021-06, ELBSecurityPolicy-TLS13-1-3-FIPS-2023-04, ELBSecurityPolicy-TLS13-1-2-Res-2021-06, ELBSecurityPolicy-TLS13-1-2-Res-FIPS-2023-04` (カスタマイズ不可)

このコントロールは、Application Load Balancer 用の HTTPS リスナーまたは Network Load Balancer 用の TLS リスナーが、推奨されるセキュリティポリシーを使用して転送中のデータを暗号化するように設定されているかどうかをチェックします。ロードバランサー用の HTTPS リスナー または TLS リスナーが推奨されるセキュリティポリシーを使用するように設定されていない場合、コントロールは失敗します。

Elastic Load Balancing は、*セキュリティポリシー*と呼ばれる SSL ネゴシエーション設定を使用して、クライアントとロードバランサー間の通信をネゴシエートします。セキュリティポリシーはプロトコルと暗号の組み合わせを指定するものです。プロトコルは、クライアントとサーバー間のセキュアな接続を確立します。暗号とは、暗号化キーを使用してコード化されたメッセージを作成する暗号化アルゴリズムです。接続ネゴシエーションのプロセスで、クライアントとロードバランサーでは、それぞれサポートされる暗号とプロトコルのリストが優先される順に表示されます。ロードバランサーに推奨されるセキュリティポリシーを使用すると、コンプライアンスとセキュリティの基準を満たすのに役立ちます。

### 修正
<a name="elb-17-remediation"></a>

推奨されるセキュリティポリシーとリスナーの更新方法については、「*Elastic Load Balancing ユーザーガイド*」の「[Application Load Balancer のセキュリティポリシー](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/describe-ssl-policies.html)」、「[Network Load Balancer のセキュリティポリシー](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/describe-ssl-policies.html)」、「[Application Load Balancer 用の HTTPS リスナーを更新する](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-update-certificates.html)」、「[Update a listener for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/listener-update-rules.html)」のセクションを参照してください。

## [ELB.18] Application Load Balancer リスナーと Network Load Balancer リスナーは、安全なプロトコルを使用して転送中のデータを暗号化する必要があります
<a name="elb-18"></a>

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::ElasticLoadBalancingV2::Listener`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elbv2-listener-encryption-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/elbv2-listener-encryption-in-transit.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Application Load Balancer 用または Network Load Balancer 用のリスナーが、安全なプロトコルを使用して転送中のデータを暗号化するように設定されているかどうかをチェックします。Application Load Balancer リスナーが HTTPS プロトコルを使用するように設定されていない場合、または Network Load Balancer リスナーが TLS プロトコルを使用するように設定されていない場合、コントロールは失敗します。

クライアントとロードバランサーの間で転送されるデータを暗号化するには、Elastic Load Balancer リスナーが業界標準のセキュリティプロトコル (Application Load Balancer の場合は HTTPS、Network Load Balancer の場合は TLS) を使用するように設定されている必要があります。そうしないと、クライアントとロードバランサーの間で転送されるデータは、傍受、改ざん、不正アクセスに対して脆弱になります。リスナーで HTTPS または TLS を使用すると、セキュリティのベストプラクティスに沿った運用になり、転送中のデータの機密性と整合性を確保するのに役立ちます。これは、機密情報を処理するアプリケーションや、転送中のデータの暗号化を必要とするセキュリティ標準に準拠する必要があるアプリケーションにとって特に重要です。

### 修正
<a name="elb-18-remediation"></a>

リスナーのセキュリティプロトコルの設定の詳細については、「*Elastic Load Balancing ユーザーガイド*」の「[Application Load Balancer 用の HTTPS リスナーを作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html)」および「[Network Load Balancer のリスナーを作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-listener.html)」のセクションを参照してください。

## [ELB.21] Application and Network Load Balancer ターゲットグループは、暗号化されたヘルスチェックプロトコルを使用する必要があります
<a name="elb-21"></a>

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::ElasticLoadBalancingV2::TargetGroup`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elbv2-targetgroup-healthcheck-protocol-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/elbv2-targetgroup-healthcheck-protocol-encrypted.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、アプリケーションおよびネットワークロードバランサーのヘルスチェックのターゲットグループが暗号化されたトランスポートプロトコルを使用しているかどうかをチェックします。ヘルスチェックプロトコルが HTTPS を使用しない場合、コントロールは失敗します。このコントロールは Lambda ターゲットタイプには適用されません。

 ロードバランサーは、登録されたターゲットにヘルスチェックリクエストを送信してステータスを判断し、それに応じてトラフィックをルーティングします。ターゲットグループ設定で指定されたヘルスチェックプロトコルによって、これらのチェックの実行方法が決まります。ヘルスチェックプロトコルが HTTP などの暗号化されていない通信を使用する場合、リクエストとレスポンスは送信中に傍受または操作できます。これにより、攻撃者はインフラストラクチャの設定に関するインサイトを取得したり、ヘルスチェックの結果を改ざんしたり、ルーティングの決定に影響を与えるman-in-the-middle攻撃を実行したりできます。ヘルスチェックに HTTPS を使用すると、ロードバランサーとそのターゲット間の暗号化された通信が可能になり、ヘルスステータス情報の整合性と機密性が保護されます。

### 修正
<a name="elb-21-remediation"></a>

Application Load Balancer ターゲットグループの暗号化されたヘルスチェックを設定するには、*Elastic Load Balancing ユーザーガイド*の[Application Load Balancer ターゲットグループのヘルスチェック設定を更新する](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/modify-health-check-settings.html)」を参照してください。Network Load Balancer ターゲットグループの暗号化されたヘルスチェックを設定するには、*Elastic Load Balancing ユーザーガイド*の[「Network Load Balancer ターゲットグループのヘルスチェック設定を更新する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/modify-health-check-settings.html)」を参照してください。

## [ELB.22] ELB ターゲットグループは暗号化されたトランスポートプロトコルを使用する必要があります
<a name="elb-22"></a>

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::ElasticLoadBalancingV2::TargetGroup`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elbv2-targetgroup-protocol-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/elbv2-targetgroup-protocol-encrypted.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Elastic Load Balancing ターゲットグループが暗号化されたトランスポートプロトコルを使用しているかどうかをチェックします。このコントロールは、ターゲットタイプが Lambda または ALB のターゲットグループ、または GENEVE プロトコルを使用するターゲットグループには適用されません。ターゲットグループが HTTPS、TLS、または QUIC プロトコルを使用していない場合、コントロールは失敗します。

 転送中のデータを暗号化すると、権限のないユーザーによる傍受から保護されます。暗号化されていないプロトコル (HTTP、TCP、UDP) を使用するターゲットグループは、暗号化なしでデータを送信し、盗聴に対して脆弱になります。暗号化されたプロトコル (HTTPS、TLS、QUIC) を使用すると、ロードバランサーとターゲット間で送信されるデータが保護されます。

### 修正
<a name="elb-22-remediation"></a>

暗号化されたプロトコルを使用するには、HTTPS、TLS、または QUIC プロトコルを使用して新しいターゲットグループを作成する必要があります。ターゲットグループプロトコルは、作成後に変更することはできません。Application Load Balancer ターゲットグループを作成するには、*Elastic Load Balancingユーザーガイド*」の[Application Load Balancer のターゲットグループを作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-target-group.html)」を参照してください。Network Load Balancer ターゲットグループを作成するには、*Elastic Load Balancing * [ユーザーガイド」の「Network Load Balancer のターゲットグループを作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-target-group.html)」を参照してください。

# Elasticsearch 用 Security Hub CSPM
<a name="es-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Elasticsearch サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [ES.1] Elasticsearch ドメインは、保管中の暗号化を有効にする必要があります
<a name="es-1"></a>

**関連する要件:** PCI DSS v3.2.1/3.4、NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SI-7(6)

**カテゴリ:** 保護 > データ保護 > 保管中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::Elasticsearch::Domain`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elasticsearch-encrypted-at-rest.html](https://docs.aws.amazon.com/config/latest/developerguide/elasticsearch-encrypted-at-rest.html)

**スケジュールタイプ :** 定期的

**パラメータ:** なし

このコントロールは、Elasticsearch ドメインで保管中の暗号化設定が有効になっているかどうかをチェックします。保管中の暗号化が有効になっていない場合、チェックは失敗します。

OpenSearch 内の機密データのセキュリティを強化するには、保管中に暗号化されるように OpenSearch を設定する必要があります。Elasticsearch ドメインは、保管中のデータの暗号化を提供します。この機能では AWS KMS 、 を使用して暗号化キーを保存および管理します。暗号化の実行には、256 ビットキーを使用した Advanced Encryption Standard アルゴリズム (AES-256) を使用します。

保管中の OpenSearch での暗号化の詳細については、「*Amazon OpenSearch Service デベロッパーガイド*」の「[Amazon OpenSearch Service の保管中のデータの暗号化](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/encryption-at-rest.html)」を参照してください。

`t.small` や `t.medium` などの特定のインスタンスタイプでは、保管中のデータの暗号化がサポートされていません。詳細については、「*Amazon OpenSearch Service デベロッパーガイド*」の「[サポートされるインスタンスタイプ](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/supported-instance-types.html)」を参照してください。

### 修正
<a name="es-1-remediation"></a>

新規および既存の Elasticsearch ドメインの保管時の暗号化を有効にするには、「*Amazon OpenSearch Service デベロッパーガイド*」の「[保管中のデータの暗号化の有効化](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/encryption-at-rest.html#enabling-ear)」を参照してください。

## [ES.2] Elasticsearch ドメインがパブリックにアクセスできないようにする必要があります
<a name="es-2"></a>

**関連する要件:** PCI DSS v3.2.1/1.2.1、PCI DSS v3.2.1/1.3.1、PCI DSS v3.2.1/1.3.2、PCI DSS v3.2.1/1.3.4、PCI DSS v3.2.1/1.3.6、NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)、PCI DSS v4.0.1/1.4.4

**カテゴリ:** 保護 > セキュアなネットワーク設定 > VPC 内のリソース 

**重要度:** 非常事態

**リソースタイプ :** `AWS::Elasticsearch::Domain`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elasticsearch-in-vpc-only.html](https://docs.aws.amazon.com/config/latest/developerguide/elasticsearch-in-vpc-only.html)

**スケジュールタイプ :** 定期的

**パラメータ:** なし

このコントロールは、Elasticsearch ドメインが VPC 内にあるかどうかをチェックします。このコントロールは、パブリックアクセスの可能性を判断するための VPC サブネットルーティング設定を評価しません。Elasticsearch ドメインがパブリックサブネットに添付済みでないことを確認する必要があります。「*Amazon OpenSearch Service デベロッパーガイド*」の「[リソースベースのポリシー](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ac.html#ac-types-resource)」を参照してください。また、推奨されるベストプラクティスに従って VPC が確実に設定されていることを確認する必要があります。「Amazon VPC ユーザーガイド」の「[VPC のセキュリティのベストプラクティス](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html)」を参照してください。

VPC 内にデプロイされた Elasticsearch ドメインは、パブリックインターネットを経由することなく、プライベート AWS ネットワーク経由で VPC リソースと通信できます。この設定では、転送中のデータへのアクセスを制限することにより、セキュリティ体制が向上します。VPC は、ネットワーク ACL やセキュリティグループを含む Elasticsearch ドメインへのアクセスを保護するための多数のネットワークコントロールを提供します。Security Hub CSPM では、パブリック Elasticsearch ドメインを VPCs に移行して、これらのコントロールを利用することをお勧めします。

### 修正
<a name="es-2-remediation"></a>

パブリックエンドポイントを使用してドメインを作成する場合、後で VPC 内にドメインを配置することはできません。代わりに、新規のドメインを作成して、データを移行する必要があります。逆の場合も同様です。VPC 内にドメインを作成する場合、パブリックエンドポイントを持つことはできません。代わりに、[別のドメインを作成する](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/createupdatedomains.html)か、このコントロールを無効にする必要があります。

「*Amazon OpenSearch Service デベロッパーガイド*」の「[VPC 内で Amazon OpenSearch Service ドメインを起動する](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/vpc.html)」を参照してください。

## [ES.3] Elasticsearch ドメインは、ノード間で送信されるデータを暗号化する必要があります
<a name="es-3"></a>

**関連する要件:** NIST.800-53.r5 AC-4、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-23、NIST.800-53.r5 SC-23(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-8、NIST.800-53.r5 SC-8(1)、NIST.800-53.r5 SC-8(2)、PCI DSS v4.0.1/4.2.1

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::Elasticsearch::Domain`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elasticsearch-node-to-node-encryption-check.html](https://docs.aws.amazon.com/config/latest/developerguide/elasticsearch-node-to-node-encryption-check.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは Elasticsearch ドメインでノード間の暗号化が有効になっているかどうかをチェックします。Elasticsearch ドメインでノード間の暗号化が有効になっていない場合、このコントロールは失敗します。Elasticsearch バージョンがノード間の暗号化チェックをサポートしていない場合、コントロールは失敗した検出結果も生成します。

HTTPS (TLS) を使用すると、潜在的な攻撃者が中間者攻撃または同様の攻撃を使用してネットワークトラフィックを盗聴または操作することを防止できます。HTTPS (TLS) 経由の暗号化された接続のみを許可する必要があります。Elasticsearch ドメインのノード間の暗号化を有効にすると、クラスター内の通信が転送中に確実に暗号化されます。

この設定には、パフォーマンス上のペナルティが発生する可能性があります。このオプションを有効にする前に、パフォーマンスのトレードオフを認識してテストする必要があります。

### 修正
<a name="es-3-remediation"></a>

新規および既存のドメインでノード間の暗号化を有効にする方法については、「*Amazon OpenSearch Service デベロッパーガイド*」の「[ノード間の暗号化を有効にする](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ntn.html#enabling-ntn)」を参照してください。

## [ES.4] CloudWatch Logs への Elasticsearch ドメインエラーログ記録を有効にする必要があります
<a name="es-4"></a>

**関連する要件:** NIST.800-53.r5 AC-2(4)、NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AC-6(9)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4(20)、NIST.800-53.r5 SI-7(8)

**カテゴリ:** 識別 - ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::Elasticsearch::Domain`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/elasticsearch-logs-to-cloudwatch.html](https://docs.aws.amazon.com/config/latest/developerguide/elasticsearch-logs-to-cloudwatch.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**
+ `logtype = 'error'` (カスタマイズ不可)

このコントロールは、Elasticsearch ドメインが CloudWatch Logs にエラーログを送信するように設定されているかどうかをチェックします。

Elasticsearch ドメインのエラーログを有効にし、これらのログは保持と応答のために CloudWatch Logs に送信する必要があります。ドメインのエラーログは、セキュリティとアクセス監査や、可用性の問題の診断に役立ちます。

### 修正
<a name="es-4-remediation"></a>

ログ発行を有効にする方法については、「*Amazon OpenSearch Service デベロッパーガイド*」の「[Enabling log publishing (console)](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/createdomain-configure-slow-logs.html#createdomain-configure-slow-logs-console)」を参照してください。

## [ES.5] Elasticsearch ドメインで監査ログ記録が有効になっている必要があります
<a name="es-5"></a>

**関連する要件:** NIST.800-53.r5 AC-2(4)、NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AC-6(9)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4(20)、NIST.800-53.r5 SI-7(8)、PCI DSS v4.0.1/10.4.2

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::Elasticsearch::Domain`

**AWS Config rule:** `elasticsearch-audit-logging-enabled` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**
+ `cloudWatchLogsLogGroupArnList` (カスタマイズ不可)。Security Hub CSPM はこのパラメータに入力しません。監査ログ用に設定する必要がある CloudWatch Logs ロググループのカンマ区切りリスト。

  Elasticsearch ドメインの CloudWatch Logs ロググループがこのパラメータリストで指定されていない場合、このルールは `NON_COMPLIANT` です。

このコントロールは、Elasticsearch ドメインで監査ログ記録が有効になっているかどうかをチェックします。Elasticsearch ドメインで監査ログ記録が有効になっていない場合、このコントロールは失敗します。

監査ログは高度なカスタマイズが可能です。これにより、認証の成功と失敗、OpenSearch へのリクエスト、インデックス変更、受信検索クエリなど、Elasticsearch クラスターでのユーザーアクティビティを追跡できます。

### 修正
<a name="es-5-remediation"></a>

監査ログを有効にする詳細な手順については、「*Amazon OpenSearch Service デベロッパーガイド*」の「[Enabling audit logs](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/audit-logs.html#audit-log-enabling)」を参照してください。

## [ES.6] Elasticsearch ドメインには少なくとも 3 つのデータノードが必要です
<a name="es-6"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 SC-36、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)

**カテゴリ:** リカバリ > 耐障害性 > 高可用性

**重要度:** 中

**リソースタイプ :** `AWS::Elasticsearch::Domain`

**AWS Config rule:** `elasticsearch-data-node-fault-tolerance` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ:** なし

このコントロールは、Elasticsearch ドメインに少なくとも 3 つのデータノードが設定されていること、また `zoneAwarenessEnabled` が `true` かどうかをチェックします。

Elasticsearch ドメインでは、高可用性と耐障害性のために少なくとも 3 つのデータノードが必要です。少なくとも 3 つのデータノードを持つ Elasticsearch ドメインをデプロイすると、ノードに障害が発生した場合のクラスター操作が確保されます。

### 修正
<a name="es-6-remediation"></a>

**Elasticsearch ドメインのデータノードの数を変更するには**

1. [https://console.aws.amazon.com/aos/](https://console.aws.amazon.com/aos/) で Amazon OpenSearch Service コンソールを開きます。

1. **[ドメイン]** で、編集するドメインの名前を選択します。

1. **[Edit domain]** (ドメインの編集) を選択します。

1. **[Data nodes]** (データノード) で、**[Number of nodes]** (ノード数) に `3` 以上の数値を設定します。

   3 つのアベイラビリティーゾーンのデプロイは、3 の倍数に設定してアベイラビリティーゾーン間で均等に配信されるようにします。

1. **[Submit]** (送信) を選択します。

## [ES.7] Elasticsearch ドメインは、少なくとも 3 つの専用マスターノードを設定する必要があります。
<a name="es-7"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 SC-36、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)

**カテゴリ:** リカバリ > 耐障害性 > 高可用性

**重要度:** 中

**リソースタイプ :** `AWS::Elasticsearch::Domain`

**AWS Config rule:** `elasticsearch-primary-node-fault-tolerance` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Elasticsearch ドメインが、少なくとも 3 つの専用プライマリノードで構成されているかどうかをチェックします。ドメインが専用プライマリノードを使用しない場合、このコントロールは失敗します。Elasticsearch ドメインに 5 つの専用プライマリノードがある場合、このコントロールは成功します。ただし、3 つ以上のプライマリノードの使用は、可用性リスクを低減するために不要な場合があり、使用により追加コストが発生します。

Elasticsearch ドメインでは、高可用性と耐障害性のために、少なくとも 3 つの専用プライマリノードが必要です。専用プライマリノードのリソースは、データノードのブルー/グリーンのデプロイ中に管理が必要なノードが追加されるため、負荷がかかることがあります。少なくとも 3 つの専用プライマリノードを持つ Elasticsearch ドメインをデプロイすると、ノードに障害が発生した場合に十分なプライマリノードのリソース容量とクラスター操作が確保されます。

### 修正
<a name="es-7-remediation"></a>

**OpenSearch ドメイン内の専用プライマリノード数を変更するには**

1. [https://console.aws.amazon.com/aos/](https://console.aws.amazon.com/aos/) で Amazon OpenSearch Service コンソールを開きます。

1. **[ドメイン]** で、編集するドメインの名前を選択します。

1. **[Edit domain]** (ドメインの編集) を選択します。

1. **[Dedicated master nodes]** (専用マスターノード) で、**[Instance type]** (インスタンスタイプ) に目的のインスタンスタイプを設定します。

1. **[Number of master nodes]** (マスターノードの数) を 3 以上に設定します。

1. **[Submit]** (送信) を選択します。

## [ES.8] Elasticsearch ドメインへの接続は最新の TLS セキュリティポリシーを使用して暗号化する必要があります
<a name="es-8"></a>

**関連する要件:** NIST.800-53.r5 AC-17(2)、NIST.800-53.r5 AC-4、NIST.800-53.r5 IA-5(1)、NIST.800-53.r5 SC-12(3)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-23、NIST.800-53.r5 SC-23(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-8、NIST.800-53.r5 SC-8(1)、NIST.800-53.r5 SC-8(2)、NIST.800-53.r5 SI-7(6)、PCI DSS v4.0.1/4.2.1

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::Elasticsearch::Domain`

**AWS Config rule:** `elasticsearch-https-required` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Elasticsearch ドメインエンドポイントが最新の TLS セキュリティポリシーを使用するように設定されているかどうかを確認します。Elasticsearch ドメインエンドポイントが最新のサポートされているポリシーを使用するように設定されていない場合、または HTTP が有効になっていない場合、コントロールは失敗します。現在サポートされている最新の TLS セキュリティポリシーは `Policy-Min-TLS-1-2-PFS-2023-10` です。

HTTPS (TLS) を使用すると、潜在的な攻撃者が中間者攻撃または同様の攻撃を使用してネットワークトラフィックを盗聴または操作することを防止できます。HTTPS (TLS) 経由の暗号化された接続のみを許可する必要があります。転送中のデータの暗号化は、パフォーマンスに影響する可能性があります。TLS のパフォーマンスプロファイルと TLS の影響を把握するには、この機能を使用してアプリケーションをテストする必要があります。TLS 1.2 は、以前の TLS バージョンに比べて、いくつかのセキュリティ機能の強化を提供します。

### 修正
<a name="es-8-remediation"></a>

TLS 暗号化を有効にするには、[https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_UpdateDomainConfig.html](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_UpdateDomainConfig.html) API オペレーションを使用して、[https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_DomainEndpointOptions.html](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_DomainEndpointOptions.html) を設定します。これにより、`TLSSecurityPolicy` が設定されます。

## [ES.9] Elasticsearch ドメインにはタグを付ける必要があります
<a name="es-9"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::Elasticsearch::Domain`

**AWS Config rule:** `tagged-elasticsearch-domain` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、Elasticsearch ドメインにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。ドメインにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ドメインにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="es-9-remediation"></a>

Elasticsearch ドメインにタグを追加するには、「*Amazon OpenSearch Service デベロッパーガイド*」の「[タグの使用](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/managedomains-awsresourcetagging.html#managedomains-awsresourcetagging-console)」を参照してください。

# Amazon EMR の Security Hub CSPM コントロール
<a name="emr-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon EMR (以前は Amazon Elastic MapReduce と呼ばれていました) サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [EMR.1] Amazon EMR クラスタープライマリノードは、パブリック IP アドレスを未設定にする必要があります
<a name="emr-1"></a>

**関連する要件:** PCI DSS v3.2.1/1.2.1、PCI DSS v3.2.1/1.3.1、PCI DSS v3.2.1/1.3.2、PCI DSS v3.2.1/1.3.4、PCI DSS v3.2.1/1.3.6、PCI DSS v4.0.1/1.4.4、NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 高

**リソースタイプ :** `AWS::EMR::Cluster`

**AWS Config ルール:** [emr-master-no-public-ip](https://docs.aws.amazon.com/config/latest/developerguide/emr-master-no-public-ip.html)

**スケジュールタイプ :** 定期的

**パラメータ:** なし

このコントロールは、Amazon EMR クラスターのマスターノードにパブリック IP アドレスが設定されているかどうかをチェックします。マスターノードインスタンスのいずれかにパブリック IP アドレスが関連付けられている場合、コントロールは失敗します。

パブリック IP アドレスは、インスタンスの `NetworkInterfaces` 設定の `PublicIp` フィールドで指定されます。このコントロールは、`RUNNING` または `WAITING` 状態にある Amazon EMR クラスターのみをチェックします。

### 修正
<a name="emr-1-remediation"></a>

起動中に、デフォルトサブネットまたはデフォルト以外のサブネット内のインスタンスがパブリック IPv4 アドレスを割り当てられるかどうかをコントロールできます。デフォルトでは、デフォルトサブネットのこの属性は `true` に設定されています。Amazon EC2 起動インスタンスウィザードによって作成された場合を除き、デフォルト以外のサブネットで IPv4 パブリックアドレス属性は `false` に設定されています。その場合、属性は `true` に設定されます。

起動後に、インスタンスからパブリック IPv4 アドレスの割り当てを手動で解除することはできません。

失敗した検出結果を修正するには、IPv4 パブリックアドレス属性が `false` に設定されているプライベートサブネットを使用して、VPC で新しいクラスターを起動する必要があります。手順については、「*Amazon EMR 管理ガイド*」の「[Launch clusters into a VPC](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-vpc-launching-job-flows.html)」を参照してください。

## [EMR.2] Amazon EMR ブロックパブリックアクセス設定を有効にする必要があります
<a name="emr-2"></a>

**関連する要件:** PCI DSS v4.0.1/1.4.4、NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)

**カテゴリ:** 保護 > セキュアなアクセス管理 > パブリックアクセスが不可能なリソース

**重要度:** 非常事態

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール:** [emr-block-public-access](https://docs.aws.amazon.com/config/latest/developerguide/emr-block-public-access.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、アカウントに Amazon EMR ブロックパブリックアクセスが設定されているかどうかをチェックします。ブロックパブリックアクセス設定が有効になっていない場合、またはポート 22 以外のポートが許可されている場合、コントロールは失敗します。

Amazon EMR のブロックパブリックアクセスは、クラスターのセキュリティ設定でポートのパブリック IP アドレスからのインバウンドトラフィックが許可されている場合に、ユーザーがパブリックサブネットでクラスターを起動するのを防止します。 AWS アカウント のユーザーがクラスターを起動すると、Amazon EMR はクラスターのセキュリティグループのポートルールをチェックし、インバウンドトラフィックルールと比較します。セキュリティグループに、パブリック IP アドレス IPv4 0.0.0.0/0 または IPv6 ::/0 に対してポートを開くインバウンドルールがあり、それらのポートがアカウントで適切に指定されていない場合、Amazon EMR はユーザーにクラスターの作成を許可しません。

**注記**  
ブロックパブリックアクセスはデフォルトで有効になっています。アカウントの保護を強化するには、これを有効のままにしておくことが推奨されます。

### 修正
<a name="emr-2-remediation"></a>

Amazon EMR のブロックパブリックアクセスを設定するには、「*Amazon EMR 管理ガイド*」の「[Using Amazon EMR block public access](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-block-public-access.html)」を参照してください。

## [EMR.3] Amazon EMR セキュリティ設定は保管時に暗号化する必要があります
<a name="emr-3"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CP-9(8)、NIST.800-53.r5 SI-12

**カテゴリ:** 保護 > データ保護 > 保管中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::EMR::SecurityConfiguration`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/emr-security-configuration-encryption-rest.html](https://docs.aws.amazon.com/config/latest/developerguide/emr-security-configuration-encryption-rest.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon EMR のセキュリティ設定で保管時の暗号化が有効になっているかどうかをチェックします。セキュリティ設定で保管時の暗号化が有効になっていない場合、コントロールは失敗します。

保管中のデータとは、永続的な不揮発性ストレージに任意の期間保管されているデータを指します。保管中のデータを暗号化すると、その機密性が保護され、権限のないユーザーがアクセスするリスクが低減されます。

### 修正
<a name="emr-3-remediation"></a>

Amazon EMR セキュリティ設定で保管時の暗号化を有効にするには、「*Amazon EMR 管理ガイド*」の「[データ暗号化の設定](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-create-security-configuration.html#emr-security-configuration-encryption.html)」を参照してください。

## [EMR.4] Amazon EMR セキュリティ設定は転送中に暗号化する必要があります
<a name="emr-4"></a>

**関連する要件:** NIST.800-53.r5 AC-4、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-8、NIST.800-53.r5 SC-8(1)、NIST.800-53.r5 SC-8(2)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-23、NIST.800-53.r5 SC-23(3)

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::EMR::SecurityConfiguration`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/emr-security-configuration-encryption-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/emr-security-configuration-encryption-transit.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon EMR のセキュリティ設定で転送中の暗号化が有効になっているかどうかをチェックします。セキュリティ設定で転送中の暗号化が有効になっていない場合、コントロールは失敗します。

転送中のデータとは、クラスター内のノード間やクラスターとアプリケーション間など、ある場所から別の場所に移動するデータを指します。データはインターネット内またはプライベートネットワーク内を移動する場合があります。転送中のデータを暗号化することで、権限のないユーザーがネットワークトラフィックを盗聴するリスクが軽減されます。

### 修正
<a name="emr-4-remediation"></a>

Amazon EMR セキュリティ設定で転送中の暗号化を有効にするには、「*Amazon EMR 管理ガイド*」の「[データ暗号化の設定](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-create-security-configuration.html#emr-security-configuration-encryption.html)」を参照してください。

# EventBridge の Security Hub CSPM コントロール
<a name="eventbridge-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon EventBridge サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [EventBridge.2] EventBridge イベントバスにはタグを付ける必要があります
<a name="eventbridge-2"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::Events::EventBus`

**AWS Config rule:**`tagged-events-eventbus` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon EventBridge イベントバスにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。イベントバスにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、イベントバスにキーがタグ付けされていない場合に失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="eventbridge-2-remediation"></a>

EventBridge イベントバスにタグを追加するには、「*Amazon EventBridge ユーザーガイド*」の「[Amazon EventBridge タグ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-tagging.html)」を参照してください。

## [EventBridge.3] Amazon EventBridge カスタムイベントバスにリソースポリシーがアタッチされている必要があります
<a name="eventbridge-3"></a>

**関連する要件:** NIST.800-53.r5 AC-2、NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-5、NIST.800-53.r5 AC-6、NIST.800-53.r5 AC-6(3)、PCI DSS v4.0.1/10.3.1

**カテゴリ:** 保護 > セキュアなアクセス管理 > パブリックアクセスが不可能なリソース

**重要度:** 低

**リソースタイプ :** `AWS::Events::EventBus`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/custom-eventbus-policy-attached.html](https://docs.aws.amazon.com/config/latest/developerguide/custom-eventbus-policy-attached.html) 

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは Amazon EventBridge カスタムイベントバスにリソースベースのポリシーがアタッチされているかどうかを確認します。カスタムイベントバスにリソースベースのポリシーがない場合、このコントロールは失敗します。

デフォルトでは、EventBridge カスタムイベントバスには、リソースベースのポリシーはアタッチされていません。これにより、アカウント内のプリンシパルはイベントバスにアクセスできます。リソースベースのポリシーをイベントバスにアタッチすることで、イベントバスへのアクセスを特定のアカウントに制限したり、別のアカウントのエンティティへのアクセスを意図的に許可したりできます。

### 修正
<a name="eventbridge-3-remediation"></a>

リソースベースのポリシーを EventBridge カスタムイベントバスにアタッチするには、「*Amazon EventBridge ユーザーガイド*」の「[Amazon EventBridge のリソースベースのポリシーの使用](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-resource-based.html)」を参照してください。

## [EventBridge.4] EventBridge グローバルエンドポイントでは、イベントの複製が有効になっている必要があります
<a name="eventbridge-4"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 SC-36、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)

**カテゴリ:** リカバリ > 耐障害性 > 高可用性

**重要度:** 中

**リソースタイプ :** `AWS::Events::Endpoint`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/global-endpoint-event-replication-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/global-endpoint-event-replication-enabled.html) 

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは Amazon EventBridge グローバルエンドポイントでイベントレプリケーションが有効になっているかどうかを確認します。グローバルエンドポイントでイベントレプリケーションが有効になっていない場合、コントロールは失敗します。

グローバルエンドポイントによりアプリケーションをリージョンフォールトトレラントにできます。開始するには、エンドポイントに Amazon Route 53 ヘルスチェックを割り当てます。フェイルオーバーが開始されると、ヘルスチェックは「異常」状態を報告します。フェイルオーバーの開始から数分以内に、すべてのカスタムイベントがセカンダリリージョンのイベントバスにルーティングされ、そのイベントバスによって処理されます。グローバルエンドポイントを使用する場合、イベントレプリケーションを有効にできます。イベントレプリケーションは、マネージドルールを使用して、すべてのカスタムイベントをプライマリリージョンとセカンダリリージョンのイベントバスに送信します。グローバルエンドポイントを設定する場合は、イベントレプリケーションを有効にすることをお勧めします。イベントレプリケーションは、グローバルエンドポイントが正しく設定されていることを確認するのに役立ちます。フェイルオーバーイベントから自動的にリカバリするには、イベントレプリケーションが必要です。イベントレプリケーションを有効にしていない場合は、イベントがプライマリリージョンにルーティングされる前に、Route 53 ヘルスチェックを手動で「正常」にリセットする必要があります。

**注記**  
カスタムイベントバスを使用している場合、フェイルオーバーが正常に機能するためには、各リージョンに同じ名前と同じアカウントを持つカスタムイベントバスが必要です。イベントレプリケーションを有効にすると、月額のコストが増加する可能性があります。料金の詳細については、[Amazon EventBridge の料金](https://aws.amazon.com/eventbridge/pricing/)を参照してください。

### 修正
<a name="eventbridge-4-remediation"></a>

EventBridge グローバルエンドポイントのイベントレプリケーションを有効にするには、「**Amazon EventBridge ユーザーガイド」の「[グローバルエンドポイントの作成](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-global-endpoints.html#eb-ge-create-endpoint)」を参照してください。**イベントレプリケーション**の場合は、[**イベントレプリケーションが有効**] を選択します。

# Amazon Fraud Detector の Security Hub CSPM コントロール
<a name="frauddetector-controls"></a>

これらの Security Hub CSPM コントロールは、Amazon Fraud Detector サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [FraudDetector.1] Amazon Fraud Detector エンティティタイプにはタグを付ける必要があります
<a name="frauddetector-1"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::FraudDetector::EntityType`

**AWS Config ルール :** `frauddetector-entity-type-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon Fraud Detector エンティティタイプにパラメータ `requiredKeyTags` で定義された特定のキーを持つタグがあるかどうかをチェックします。エンティティタイプにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、エンティティタイプにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="frauddetector-1-remediation"></a>

**Amazon Fraud Detector エンティティタイプにタグを追加するには (コンソール)**

1. Amazon Fraud Detector コンソールを [https://console.aws.amazon.com/frauddetector](https://console.aws.amazon.com/frauddetector/) で開きます。

1. ナビゲーションペインで **[エンティティ]** を選択します。

1. リストからエンティティタイプを選択します。

1. **[エンティティタイプタグ]** セクションで、**[タグを管理]** を選択します。

1. [**新しいタグを追加**] をクリックします。タグのキーと値を入力します。追加のキーと値のペアについても繰り返します。

1. タグの追加を完了したら、**[保存]** を選択します。

## [FraudDetector.2] Amazon Fraud Detector ラベルにはタグを付ける必要があります
<a name="frauddetector-2"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::FraudDetector::Label`

**AWS Config ルール :** `frauddetector-label-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon Fraud Detector ラベルにパラメータ `requiredKeyTags` で定義された特定のキーを持つタグがあるかどうかをチェックします。ラベルにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ラベルにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="frauddetector-2-remediation"></a>

**Amazon Fraud Detector ラベルにタグを追加するには (コンソール)**

1. Amazon Fraud Detector コンソールを [https://console.aws.amazon.com/frauddetector](https://console.aws.amazon.com/frauddetector/) で開きます。

1. ナビゲーションペインで、**[ラベル]** を選択します。

1. リストからラベルを選択します。

1. **[ラベルタグ]** セクションで、**[タグを管理]** を選択します。

1. [**新しいタグを追加**] をクリックします。タグのキーと値を入力します。追加のキーと値のペアについても繰り返します。

1. タグの追加を完了したら、**[保存]** を選択します。

## [FraudDetector.3] Amazon Fraud Detector の結果にはタグを付ける必要があります
<a name="frauddetector-3"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::FraudDetector::Outcome`

**AWS Config ルール :** `frauddetector-outcome-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon Fraud Detector の結果にパラメータ `requiredKeyTags` で定義された特定のキーを持つタグがあるかどうかをチェックします。結果にタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、結果にキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="frauddetector-3-remediation"></a>

**Amazon Fraud Detector の結果にタグを追加するには (コンソール)**

1. Amazon Fraud Detector コンソールを [https://console.aws.amazon.com/frauddetector](https://console.aws.amazon.com/frauddetector/) で開きます。

1. ナビゲーションペインで、**[結果]** を選択します。

1. リストから結果を選択します。

1. **[結果タグ]** セクションで、**[タグを管理]** を選択します。

1. [**新しいタグを追加**] をクリックします。タグのキーと値を入力します。追加のキーと値のペアについても繰り返します。

1. タグの追加を完了したら、**[保存]** を選択します。

## [FraudDetector.4] Amazon Fraud Detector 変数にはタグを付ける必要があります
<a name="frauddetector-4"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::FraudDetector::Variable`

**AWS Config ルール :** `frauddetector-variable-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon Fraud Detector 変数にパラメータ `requiredKeyTags` で定義された特定のキーを持つタグがあるかどうかをチェックします。変数にタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、変数にキーがタグ付けされていない場合に失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="frauddetector-4-remediation"></a>

**Amazon Fraud Detector 変数にタグを追加するには (コンソール)**

1. Amazon Fraud Detector コンソールを [https://console.aws.amazon.com/frauddetector](https://console.aws.amazon.com/frauddetector/) で開きます。

1. ナビゲーションペインで、**[変数]** を選択します。

1. リストから変数を選択します。

1. **[変数タグ]** セクションで、**[タグを管理]** を選択します。

1. [**新しいタグを追加**] をクリックします。タグのキーと値を入力します。追加のキーと値のペアについても繰り返します。

1. タグの追加を完了したら、**[保存]** を選択します。

# Amazon FSx の Security Hub CSPM コントロール
<a name="fsx-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon FSx サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [FSx.1] FSx for OpenZFS ファイルシステムでは、タグをバックアップとボリュームにコピーするように設定する必要があります
<a name="fsx-1"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::FSx::FileSystem`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/fsx-openzfs-copy-tags-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/fsx-openzfs-copy-tags-enabled.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、Amazon FSx for OpenZFS ファイルシステムがタグをバックアップとボリュームにコピーするように設定されているかどうかをチェックします。OpenZFS ファイルシステムがタグをバックアップとボリュームにコピーするように設定されていない場合、コントロールは失敗します。

IT アセットの身分証明書とインベントリはガバナンスとセキュリティの重要な側面です。タグは、目的、所有者、環境など、さまざまな方法で AWS リソースを分類するのに役立ちます。割り当てたタグに基づいて特定のリソースをすばやく識別できるため、これは同じ型のリソースが多い場合に役立ちます。

### 修正
<a name="fsx-1-remediation"></a>

タグをバックアップとボリュームにコピーするように FSx for OpenZFS ファイルシステムを設定する方法については、「*Amazon FSx for OpenZFS ユーザーガイド*」の「[Updating a file system](https://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/updating-file-system.html)」を参照してください。

## [FSx.2] FSx for Lustre ファイルシステムでは、タグをバックアップにコピーするように設定する必要があります
<a name="fsx-2"></a>

**関連する要件:** NIST.800-53.r5 CP-9、NIST.800-53.r5 CM-8

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::FSx::FileSystem`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/fsx-lustre-copy-tags-to-backups.html](https://docs.aws.amazon.com/config/latest/developerguide/fsx-lustre-copy-tags-to-backups.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、Amazon FSx for Lustre ファイルシステムがタグをバックアップとボリュームにコピーするように設定されているかどうかをチェックします。Lustre ファイルシステムがタグをバックアップとボリュームにコピーするように設定されていない場合、コントロールは失敗します。

IT アセットの身分証明書とインベントリはガバナンスとセキュリティの重要な側面です。タグは、目的、所有者、環境など、さまざまな方法で AWS リソースを分類するのに役立ちます。割り当てたタグに基づいて特定のリソースをすばやく識別できるため、これは同じ型のリソースが多い場合に役立ちます。

### 修正
<a name="fsx-2-remediation"></a>

タグをバックアップにコピーするように FSx for Lustre ファイルシステムを設定する方法については、「*Amazon FSx for Lustre ユーザーガイド*」の「[Copying backups within the same AWS アカウント](https://docs.aws.amazon.com/fsx/latest/LustreGuide/copying-backups-same-account.html)」を参照してください。

## [FSx.3] FSx for OpenZFS ファイルシステムはマルチ AZ 配置用に設定する必要があります
<a name="fsx-3"></a>

**カテゴリ:** リカバリ > 耐障害性 > 高可用性

**重要度:** 中

**リソースタイプ :** `AWS::FSx::FileSystem`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/fsx-openzfs-deployment-type-check.html](https://docs.aws.amazon.com/config/latest/developerguide/fsx-openzfs-deployment-type-check.html)

**スケジュールタイプ:** 定期的

**パラメータ:** `deploymentTypes: MULTI_AZ_1` (カスタマイズ不可)

このコントロールは、Amazon FSx for OpenZFS ファイルシステムがマルチアベイラビリティーゾーン (マルチ AZ) 配置タイプを使用するように設定されているかどうかをチェックします。ファイルシステムがマルチ AZ 配置タイプを使用するように設定されていない場合、コントロールは失敗します。

Amazon FSx for OpenZFS は、ファイルシステムで*マルチ AZ (HA)*、*シングル AZ (HA)*、*シングル AZ (非 HA)* などさまざまな配置タイプをサポートしています。配置タイプは、さまざまなレベルの可用性と耐久性を提供します。マルチ AZ (HA) ファイルシステムは、2 つのアベイラビリティーゾーン (AZ) にまたがるファイルサーバーの高可用性 (HA) ペアで構成されます。高い可用性と耐久性を持つモデルを実現できるため、ほとんどのプロダクションワークロードでマルチ AZ (HA) 配置タイプを使用することをお勧めします。

### 修正
<a name="fsx-3-remediation"></a>

ファイルシステムの作成時にマルチ AZ 配置タイプを使用するように Amazon FSx for OpenZFS ファイルシステムを設定できます。既存の FSx for OpenZFS ファイルシステムの配置タイプを変更することはできません。

FSx for OpenZFS ファイルシステムの配置タイプとオプションの詳細については、「*Amazon FSx for OpenZFS ユーザーガイド*」の「[Availability and durability for Amazon FSx for OpenZFS](https://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/availability-durability.html)」および「[Managing file system resources](https://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/managing-file-systems.html)」を参照してください。

## [FSx.4] FSx for NetApp ONTAP ファイルシステムは、マルチ AZ 配置用に設定する必要があります
<a name="fsx-4"></a>

**カテゴリ:** リカバリ > 耐障害性 > 高可用性

**重要度:** 中

**リソースタイプ :** `AWS::FSx::FileSystem`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/fsx-ontap-deployment-type-check.html](https://docs.aws.amazon.com/config/latest/developerguide/fsx-ontap-deployment-type-check.html)

**スケジュールタイプ :** 定期的

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `deploymentTypes`  |  評価に含める配置タイプのリスト。ファイルシステムがリストで指定された配置タイプを使用するように設定されていない場合、コントロールは `FAILED` 検出結果を生成します。  |  列挙型  |  `MULTI_AZ_1`, `MULTI_AZ_2`  |  `MULTI_AZ_1`, `MULTI_AZ_2`  | 

このコントロールは、Amazon FSx for NetApp ONTAP ファイルシステムマルチアベイラビリティーゾーン (マルチ AZ) 配置タイプを使用するように設定されているかどうかをチェックします。ファイルシステムがマルチ AZ 配置タイプを使用するように設定されていない場合、コントロールは失敗します。必要に応じて、評価に含める配置タイプのリストを指定できます。

Amazon FSx for NetApp ONTAP は、ファイルシステムで *Single-AZ 1*、*Single-AZ 2*、*Multi-AZ 1*、*Multi-AZ 2* という複数の配置タイプをサポートしています。配置タイプは、さまざまなレベルの可用性と耐久性を提供します。マルチ AZ 配置タイプでは高い可用性と耐久性を持つモデルを実現できるため、ほとんどのプロダクションワークロードでマルチ AZ 配置タイプを使用することをお勧めします。マルチ AZ ファイルシステムは、シングル AZ ファイルシステムの可用性と耐久性の機能をすべてサポートしています。さらに、アベイラビリティーゾーン (AZ) が利用できない場合でも、データに継続的な可用性を提供するように設計されています。

### 修正
<a name="fsx-4-remediation"></a>

既存の Amazon FSx for NetApp ONTAP ファイルシステムの配置タイプを変更することはできません。ただし、データをバックアップし、マルチ AZ 配置タイプを使用する新しいファイルシステムに復元することはできます。

FSx for ONTAP ファイルシステムの配置タイプとオプションの詳細については、「*FSx for ONTAP ユーザーガイド*」の「[Availability, durability, and deployment options](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/high-availability-AZ.html)」および「[Managing file systems](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/managing-file-systems.html)」を参照してください。

## [FSx.5] FSx for Windows File Server ファイルシステムは、マルチ AZ 配置用に設定する必要があります
<a name="fsx-5"></a>

**カテゴリ:** リカバリ > 耐障害性 > 高可用性

**重要度:** 中

**リソースタイプ :** `AWS::FSx::FileSystem`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/fsx-windows-deployment-type-check.html](https://docs.aws.amazon.com/config/latest/developerguide/fsx-windows-deployment-type-check.html)

**スケジュールタイプ:** 定期的

**パラメータ:** `deploymentTypes: MULTI_AZ_1` (カスタマイズ不可)

このコントロールは、Amazon FSx for Windows File Server ファイルシステムマルチアベイラビリティーゾーン (マルチ AZ) 配置タイプを使用するように設定されているかどうかをチェックします。ファイルシステムがマルチ AZ 配置タイプを使用するように設定されていない場合、コントロールは失敗します。

Amazon FSx for Windows File Server は、ファイルシステムで*シングル AZ* と*マルチ AZ* という 2 種類の配置タイプをサポートしています。配置タイプは、さまざまなレベルの可用性と耐久性を提供します。シングル AZ ファイルシステムは、単一の Windows ファイルサーバーインスタンスと、単一のアベイラビリティーゾーン (AZ) 内の一連のストレージボリュームで構成されます。マルチ AZ ファイルシステムは、2 つのアベイラビリティーゾーンにまたがる Windows ファイルサーバーの高可用性クラスターで構成されます。高い可用性と耐久性を持つモデルを実現できるため、ほとんどのプロダクションワークロードでマルチ AZ 配置タイプを使用することをお勧めします。

### 修正
<a name="fsx-5-remediation"></a>

ファイルシステムの作成時にマルチ AZ 配置タイプを使用するように Amazon FSx for Windows File Server ファイルシステムを設定できます。既存の FSx for Windows File Server ファイルシステムの配置タイプを変更することはできません。

FSx for Windows File Server ファイルシステムの配置タイプとオプションの詳細については、「*Amazon FSx for Windows File Server ユーザーガイド*」の「[Availability and durability: Single-AZ and Multi-AZ file systems](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/high-availability-multiAZ.html)」および「[Getting started with Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/getting-started.html)」を参照してください。

# Global Accelerator の Security Hub CSPM コントロール
<a name="globalaccelerator-controls"></a>

これらの AWS Security Hub CSPM コントロールは、 AWS Global Accelerator サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [GlobalAccelerator.1] Global Accelerator アクセラレーターにはタグを付ける必要があります
<a name="globalaccelerator-1"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::GlobalAccelerator::Accelerator`

**AWS Config rule:** `tagged-globalaccelerator-accelerator` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、アクセラレーターにパラメータ AWS Global Accelerator で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。アクセラレータにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、アクセラレータにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="globalaccelerator-1-remediation"></a>

Global Accelerator グローバルアクセラレーターにタグを追加するには、「*AWS Global Accelerator デベロッパーガイド*」の「[AWS Global Acceleratorのタグ付け](https://docs.aws.amazon.com/global-accelerator/latest/dg/tagging-in-global-accelerator.html)」を参照してください。

# の Security Hub CSPM コントロール AWS Glue
<a name="glue-controls"></a>

これらの AWS Security Hub CSPM コントロールは、 AWS Glue サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [Glue.1] AWS Glue ジョブにはタグを付ける必要があります
<a name="glue-1"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::Glue::Job`

**AWS Config rule:** `tagged-glue-job` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、 AWS Glue ジョブにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。ジョブにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ジョブにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="glue-1-remediation"></a>

 AWS Glue ジョブにタグを追加するには、「 *AWS Glue ユーザーガイド*」の「 [AWS のタグ AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/monitor-tags.html)」を参照してください。

## [Glue.3] AWS Glue 機械学習変換は保管時に暗号化する必要があります
<a name="glue-3"></a>

**カテゴリ:** 保護 > データ保護 > 保管中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::Glue::MLTransform`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/glue-ml-transform-encrypted-at-rest.html](https://docs.aws.amazon.com/config/latest/developerguide/glue-ml-transform-encrypted-at-rest.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、 AWS Glue 機械学習変換が保管時に暗号化されているかどうかをチェックします。機械学習変換が保管中に暗号化されていない場合、コントロールは失敗します。

保管中のデータとは、永続的な不揮発性ストレージに任意の期間保管されているデータを指します。保管中のデータを暗号化すると、その機密性が保護され、権限のないユーザーがアクセスするリスクが低減されます。

### 修正
<a name="glue-3-remediation"></a>

 AWS Glue 機械学習変換の暗号化を設定するには、「 *AWS Glue ユーザーガイド*」の[「機械学習変換の使用](https://docs.aws.amazon.com/glue/latest/dg/console-machine-learning-transforms.html)」を参照してください。

## [Glue.4] AWS Glue Spark ジョブは、サポートされているバージョンの で実行する必要があります AWS Glue
<a name="glue-4"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 SI-2、NIST.800-53.r5 SI-2(2)、NIST.800-53.r5 SI-2(4)、NIST.800-53.r5 SI-2(5)

**カテゴリ:** 特定 > 脆弱性、パッチ、バージョン管理

**重要度:** 中

**リソースタイプ :** `AWS::Glue::Job`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/glue-spark-job-supported-version.html](https://docs.aws.amazon.com/config/latest/developerguide/glue-spark-job-supported-version.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ:** `minimumSupportedGlueVersion`: `3.0` (カスタマイズ不可)

このコントロールは、 AWS Glue for Spark ジョブがサポートされているバージョンの で実行されるように設定されているかどうかを確認します AWS Glue。Spark ジョブがサポートされている最小バージョンより前のバージョンの で実行されるように設定されている場合、コントロール AWS Glue は失敗します。

**注記**  
このコントロールは、 AWS Glue バージョン (`GlueVersion`) プロパティが存在しないか、ジョブの設定項目 (CI) AWS Glue が null の場合にも、Spark ジョブの `FAILED`の結果を生成します。このような場合、検出結果には `GlueVersion is null or missing in glueetl job configuration` という注釈が含まれます。このタイプの `FAILED` 検出結果に対処するには、ジョブの設定に `GlueVersion` プロパティを追加します。サポートされているバージョンとランタイム環境のリストについては、「*AWS Glue ユーザーガイド*」の「[AWS Glue バージョン](https://docs.aws.amazon.com/glue/latest/dg/release-notes.html#release-notes-versions)」を参照してください。

の最新バージョンで AWS Glue Spark ジョブを実行すると、パフォーマンス、セキュリティ、および の最新機能へのアクセスを最適化 AWS Glue できます AWS Glue。また、セキュリティの脆弱性に対する保護にも役立ちます。たとえば、新しいバージョンがリリースされて、セキュリティ更新プログラムの提供、問題への対処、新機能の導入が行われることがあります。

### 修正
<a name="glue-4-remediation"></a>

Spark ジョブをサポートされている バージョンに移行する方法については AWS Glue、*AWS Glue 「 ユーザーガイド*」の[「Spark ジョブ AWS Glue の移行](https://docs.aws.amazon.com/glue/latest/dg/migrating-version-40.html)」を参照してください。

# Amazon GuardDuty の Security Hub CSPM コントロール
<a name="guardduty-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon GuardDuty サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [GuardDuty.1] GuardDuty を有効にする必要があります
<a name="guardduty-1"></a>

**関連する要件:** NIST.800-53.r5 AC-2(12)、NIST.800-53.r5 AU-6(1)、NIST.800-53.r5 AU-6(5)、NIST.800-53.r5 CA-7、NIST.800-53.r5 CM-8(3)、NIST.800-53.r5 RA-3(4)、NIST.800-53.r5 SA-11(1)、NIST.800-53.r5 SA-11(6)、NIST.800-53.r5 SA-15(2)、NIST.800-53.r5 SA-15(8)、NIST.800-53.r5 SA-8(19)、NIST.800-53.r5 SA-8(21)、NIST.800-53.r5 SA-8(25)、NIST.800-53.r5 SC-5、NIST.800-53.r5 SC-5(1)、NIST.800-53.r5 SC-5(3)、NIST.800-53.r5 SI-20、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4、NIST.800-53.r5 SI-4(1)、NIST.800-53.r5 SI-4(13)、NIST.800-53.r5 SI-4(2)、NIST.800-53.r5 SI-4(22)、NIST.800-53.r5 SI-4(25)、NIST.800-53.r5 SI-4(4)、NIST.800-53.r5 SI-4(5)、NIST.800-171.r2 3.4.2、NIST.800-171.r2 3.14.6、NIST.800-171.r2 3.14.7、PCI DSS v3.2.1/11.4、PCI DSS v4.0.1/11.5.1

**カテゴリ:** 検出 > 検出サービス

**重要度:** 高

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/guardduty-enabled-centralized.html](https://docs.aws.amazon.com/config/latest/developerguide/guardduty-enabled-centralized.html)

**スケジュールタイプ :** 定期的

**パラメータ:** なし

このコントロールは、GuardDuty アカウントおよびリージョンで Amazon GuardDuty が有効になっているかどうかをチェックします。

サポートされているすべての AWS リージョンで GuardDuty を有効にすることを強くお勧めします。このように設定することで、ユーザーが能動的に使用していないリージョンでも、許可されていないアクティビティや異常なアクティビティに関する結果を GuardDuty で生成できます。これにより GuardDuty で、IAM などのグローバルな AWS のサービス の CloudTrail イベントもモニタリングできます。

### 修正
<a name="guardduty-1-remediation"></a>

GuardDuty を有効にするには、「*Amazon GuardDuty ユーザーガイド*」の「[GuardDuty の開始方法](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html)」を参照してください。

## [GuardDuty.2] GuardDuty フィルターにはタグを付ける必要があります
<a name="guardduty-2"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::GuardDuty::Filter`

**AWS Config rule:** `tagged-guardduty-filter` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、Amazon GuardDuty フィルターにパラメータ `requiredTagKeys` で定義された特定のキーを含むタグがあるかどうかをチェックします。フィルターにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、フィルターにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="guardduty-2-remediation"></a>

GuardDuty フィルターにタグを追加するには、「*Amazon GuardDutyリファレンス*」の「[https://docs.aws.amazon.com/guardduty/latest/APIReference/API_TagResource.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_TagResource.html)」を参照してください。

## [GuardDuty.3] GuardDuty IPSets にはタグを付ける必要があります
<a name="guardduty-3"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::GuardDuty::IPSet`

**AWS Config rule:** `tagged-guardduty-ipset` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、Amazon GuardDuty IPSet にパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。IPSet にタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、IPSet にキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、『』の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="guardduty-3-remediation"></a>

GuardDuty IPSet にタグを追加するには、「*Amazon GuardDutyリファレンス*」の「[https://docs.aws.amazon.com/guardduty/latest/APIReference/API_TagResource.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_TagResource.html)」を参照してください。

## [GuardDuty.4] GuardDuty ディテクターにはタグを付ける必要があります
<a name="guardduty-4"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::GuardDuty::Detector`

**AWS Config rule:** `tagged-guardduty-detector` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、Amazon GuardDuty ディテクターにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。ディテクターにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ディテクターがキーでタグ付けされていない場合に失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="guardduty-4-remediation"></a>

GuardDuty ディテクターにタグを追加するには、「*Amazon GuardDutyリファレンス*」の「[https://docs.aws.amazon.com/guardduty/latest/APIReference/API_TagResource.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_TagResource.html)」を参照してください。

## [GuardDuty.5] GuardDuty EKS 監査ログモニタリングを有効にする必要があります
<a name="guardduty-5"></a>

**カテゴリ:** 検出 > 検出サービス

**重要度:** 高

**リソースタイプ :** `AWS::GuardDuty::Detector`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/guardduty-eks-protection-audit-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/guardduty-eks-protection-audit-enabled.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、GuardDuty EKS 監査ログモニタリングが有効になっているかを確認します。スタンドアロンアカウントの場合、アカウントで GuardDuty EKS 監査ログモニタリングが無効になっていると、コントロールは失敗します。マルチアカウント環境では、委任 GuardDuty 管理者アカウントとすべてのメンバーアカウントで EKS 監査ログモニタリングが有効になっていない場合、コントロールは失敗します。

マルチアカウント環境では、コントロールは委任 GuardDuty 管理者アカウントでのみ結果を生成します。組織内のメンバーアカウントの EKS 監査ログのモニタリング機能を有効または無効にできるのは、委任管理者アカウントのみです。GuardDuty メンバーアカウントからは、この設定を変更できません。このコントロールは、委任 GuardDuty 管理者に GuardDuty EKS 監査ログモニタリングが有効になっていない停止されたメンバーアカウントがある場合に `FAILED` 検出結果を生成します。`PASSED` 検出結果を受け取るには、委任管理者が GuardDuty でこれらの停止されたアカウントの関連付けを解除する必要があります。

GuardDuty EKS 監査ログのモニタリングは、Amazon Elastic Kubernetes Service (Amazon EKS) クラスターの疑わしいアクティビティの可能性を検出するのに役立ちます。EKS 監査ログのモニタリングは、ユーザー、Kubernetes API を使用するアプリケーション、およびコントロールプレーンからの時系列アクティビティをキャプチャします。

### 修正
<a name="guardduty-5-remediation"></a>

GuardDuty EKS 監査ログモニタリングを有効にするには、「*Amazon GuardDuty ユーザーガイド*」の「[EKS 監査ログモニタリング](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty-eks-audit-log-monitoring.html)」を参照してください。

## [GuardDuty.6] GuardDuty Lambda Protection を有効にする必要があります
<a name="guardduty-6"></a>

**関連する要件:** PCI DSS v4.0.1/11.5.1

**カテゴリ:** 検出 > 検出サービス

**重要度:** 高

**リソースタイプ :** `AWS::GuardDuty::Detector`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/guardduty-lambda-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/guardduty-lambda-protection-enabled.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、GuardDuty Lambda Protection が有効になっているかどうかをチェックします。スタンドアロンアカウントの場合、アカウントで GuardDuty Lambda Protection が無効になっていると、コントロールは失敗します。マルチアカウント環境では、委任 GuardDuty 管理者アカウントとすべてのメンバーアカウントで Lambda Protection が有効になっていない場合、コントロールは失敗します。

マルチアカウント環境では、コントロールは委任 GuardDuty 管理者アカウントでのみ結果を生成します。委任管理者は、組織内の既存のメンバーアカウントに対して Lambda Protection 機能を有効または無効にできます。GuardDuty メンバーアカウントからは、この設定を変更できません。このコントロールは、委任 GuardDuty 管理者に GuardDuty Lambda Protection が有効になっていない停止メンバーアカウントがある場合に `FAILED` 検出結果を生成します。`PASSED` 検出結果を受け取るには、委任管理者が GuardDuty でこれらの停止されたアカウントの関連付けを解除する必要があります。

GuardDuty Lambda Protection は、 AWS Lambda 関数が呼び出されたときに潜在的なセキュリティ脅威を特定するのに役立ちます。Lambda Protection を有効にすると、GuardDuty は AWS アカウントの Lambda 関数に関連付けられた Lambda ネットワークアクティビティログのモニタリングを開始します。Lambda 関数が呼び出され GuardDuty が Lambda 関数に潜在的に悪意のあるコードが存在することを示す疑わしいネットワークトラフィックを特定した場合、GuardDuty は検出結果を生成します。

### 修正
<a name="guardduty-6-remediation"></a>

GuardDuty Lambda Protection を有効にするには、「*Amazon GuardDutyユーザーガイド*」の「[Lambda Protection の設定](https://docs.aws.amazon.com/guardduty/latest/ug/configuring-lambda-protection.html)」を参照してください。

## [GuardDuty.7] GuardDuty EKS ランタイムモニタリングを有効にする必要があります
<a name="guardduty-7"></a>

**関連する要件:** PCI DSS v4.0.1/11.5.1

**カテゴリ:** 検出 > 検出サービス

**重要度:** 高

**リソースタイプ :** `AWS::GuardDuty::Detector`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/guardduty-eks-protection-runtime-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/guardduty-eks-protection-runtime-enabled.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、自動エージェント管理による GuardDuty EKS ランタイムモニタリングが有効になっているかを確認します。スタンドアロンアカウントの場合、アカウントで自動エージェント管理による GuardDuty EKS ランタイムモニタリングが無効になっていると、コントロールは失敗します。マルチアカウント環境では、委任 GuardDuty 管理者アカウントとすべてのメンバーアカウントに自動エージェント管理が有効になっている EKS Runtime Monitoring がない場合、コントロールは失敗します。

マルチアカウント環境では、コントロールは委任 GuardDuty 管理者アカウントでのみ結果を生成します。委任管理者のみが、組織内のメンバーアカウントのエージェント管理を自動化して EKS ランタイムモニタリング機能を有効または無効にできます。GuardDuty メンバーアカウントからは、この設定を変更できません。このコントロールは、委任 GuardDuty 管理者に GuardDuty EKS ランタイムモニタリングが有効になっていない停止メンバーアカウントがある場合に `FAILED` 検出結果を生成します。`PASSED` 検出結果を受け取るには、委任管理者が GuardDuty でこれらの停止されたアカウントの関連付けを解除する必要があります。

Amazon GuardDuty の EKS Protection は、脅威検出の範囲を提供し、 AWS 環境内の Amazon EKS クラスターを保護するのに役立ちます。EKS Runtime Monitoring は、オペレーティングシステムレベルのイベントを使用して、EKS クラスター内の EKS ノードとコンテナにおける潜在的な脅威を検出するのに役立ちます。

### 修正
<a name="guardduty-7-remediation"></a>

自動エージェント管理で EKS ランタイムモニタリングを有効にするには、「*Amazon GuardDuty ユーザーガイド*」の「[GuardDuty ランタイムモニタリングの有効化](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring-configuration.html)」を参照してください。

## [GuardDuty.8] GuardDuty Malware Protection for EC2 を有効にする必要があります
<a name="guardduty-8"></a>

**カテゴリ:** 検出 > 検出サービス

**重要度:** 高

**リソースタイプ :** `AWS::GuardDuty::Detector`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/guardduty-malware-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/guardduty-malware-protection-enabled.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、GuardDuty Malware Protection が有効になっているかどうかをチェックします。スタンドアロンアカウントの場合、アカウントで GuardDuty Malware Protection が無効になっていると、コントロールは失敗します。マルチアカウント環境では、委任 GuardDuty 管理者アカウントとすべてのメンバーアカウントで Malware Protection が有効になっていない場合、コントロールは失敗します。

マルチアカウント環境では、コントロールは委任 GuardDuty 管理者アカウントでのみ結果を生成します。委任管理者のみが、組織内のメンバーアカウントに対して Malware Protection 機能を有効または無効にできます。GuardDuty メンバーアカウントからは、この設定を変更できません。このコントロールは、委任された GuardDuty 管理者に GuardDuty Malware Protection が有効になっていない停止メンバーアカウントがある場合に `FAILED` 検出結果を生成します。`PASSED` 検出結果を受け取るには、委任管理者が GuardDuty でこれらの停止されたアカウントの関連付けを解除する必要があります。

GuardDuty Malware Protection for EC2 は、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスおよびコンテナワークロードにアタッチされた Amazon Elastic Block Store (Amazon EBS) ボリュームをスキャンすることで、マルウェアの潜在的な存在を検出することに役立ちます。Malware Protection は、スキャン時に特定の EC2 インスタンスおよびコンテナワークロードを含めるか除外するかを決定できるスキャンオプションを提供します。EC2 インスタンスまたはコンテナワークロードにアタッチされた EBS ボリュームのスナップショットを GuardDuty アカウントに保持するオプションも提供します。スナップショットは、マルウェアが検出されて Malware Protection の検出結果が生成された場合にのみ保持されます。

### 修正
<a name="guardduty-8-remediation"></a>

EC2 で GuardDuty Malware Protection を有効にするには、「*Amazon GuardDuty ユーザーガイド*」の「[GuardDuty で開始されたマルウェアスキャンの設定](https://docs.aws.amazon.com/guardduty/latest/ug/gdu-initiated-malware-scan-configuration.html)」を参照してください。

## [GuardDuty.9] GuardDuty RDS Protection を有効にする必要があります
<a name="guardduty-9"></a>

**関連する要件:** PCI DSS v4.0.1/11.5.1

**カテゴリ:** 検出 > 検出サービス

**重要度:** 高

**リソースタイプ :** `AWS::GuardDuty::Detector`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/guardduty-rds-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/guardduty-rds-protection-enabled.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、GuardDuty RDS Protection が有効になっているかを確認します。スタンドアロンアカウントの場合、アカウントで GuardDuty RDS Protection が無効になっていると、コントロールは失敗します。マルチアカウント環境では、委任 GuardDuty 管理者アカウントとすべてのメンバーアカウントで RDS Protection が有効になっていない場合、コントロールは失敗します。

マルチアカウント環境では、コントロールは委任 GuardDuty 管理者アカウントでのみ結果を生成します。委任管理者のみが、組織内のメンバーアカウントに対して RDS Protection 機能を有効または無効にできます。GuardDuty メンバーアカウントからは、この設定を変更できません。このコントロールは、委任された GuardDuty 管理者に GuardDuty RDS Protection が有効になっていない停止メンバーアカウントがある場合に`FAILED` 検出結果を生成します。`PASSED` 検出結果を受け取るには、委任管理者が GuardDuty でこれらの停止されたアカウントの関連付けを解除する必要があります。

GuardDuty の RDS Protection は、RDS ログインアクティビティを分析してプロファイリングし、Amazon Aurora データベース (Aurora MySQL 互換エディションおよび Aurora PostgreSQL 互換エディション) への潜在的なアクセス脅威がないかどうかを調べます。この機能により、潜在的に疑わしいログイン動作を特定できます。RDS Protection は追加のインフラストラクチャが不要で、データベースインスタンスのパフォーマンスに影響を与えないように設計されています。RDS Protection がデータベースへの脅威を示す潜在的に疑わしいログイン試行または異常なログイン試行を検出すると、GuardDuty は侵害の可能性があるデータベースに関する詳細な新しい検出結果を生成します。

### 修正
<a name="guardduty-9-remediation"></a>

GuardDuty RDS Protection を有効にするには、「*Amazon GuardDuty ユーザーガイド*」の「[GuardDuty RDS Protection](https://docs.aws.amazon.com/guardduty/latest/ug/rds-protection.html)」を参照してください。

## [GuardDuty.10] GuardDuty S3 Protection を有効にする必要があります
<a name="guardduty-10"></a>

**関連する要件:** PCI DSS v4.0.1/11.5.1

**カテゴリ:** 検出 > 検出サービス

**重要度:** 高

**リソースタイプ :** `AWS::GuardDuty::Detector`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/guardduty-s3-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/guardduty-s3-protection-enabled.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、GuardDuty S3 Protection が有効になっているかどうかをチェックします。スタンドアロンアカウントの場合、アカウントで GuardDuty S3 Protection が無効になっていると、コントロールは失敗します。マルチアカウント環境では、委任 GuardDuty 管理者アカウントとすべてのメンバーアカウントで S3 Protection が有効になっていない場合、コントロールは失敗します。

マルチアカウント環境では、コントロールは委任 GuardDuty 管理者アカウントでのみ結果を生成します。委任管理者のみが、組織内のメンバーアカウントに対して S3 Protection 機能を有効または無効にできます。GuardDuty メンバーアカウントからは、この設定を変更できません。このコントロールは、委任された GuardDuty 管理者に GuardDuty S3 Protection が有効になっていない停止メンバーアカウントがある場合に `FAILED` 検出結果を生成します。`PASSED` 検出結果を受け取るには、委任管理者が GuardDuty でこれらの停止されたアカウントの関連付けを解除する必要があります。

S3 Protectionにより、GuardDuty は、オブジェクトレベルの API オペレーションをモニタリングし、Amazon Simple Storage Service (Amazon S3) バケット内のデータに関する潜在的なセキュリティリスクを特定できるようになります。GuardDuty は、 AWS CloudTrail 管理イベントと CloudTrail S3 データイベントを分析して、S3 リソースに対する脅威をモニタリングします。

### 修正
<a name="guardduty-10-remediation"></a>

GuardDuty S3 Protection を有効にするには、「*Amazon GuardDuty ユーザーガイド*」の「[Amazon S3 protection in Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/s3-protection.html)」を参照してください。

## [GuardDuty.11] GuardDuty ランタイムモニタリングを有効にする必要があります
<a name="guardduty-11"></a>

**カテゴリ:** 検出 > 検出サービス

**重要度:** 高

**リソースタイプ :** `AWS::GuardDuty::Detector`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/guardduty-runtime-monitoring-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/guardduty-runtime-monitoring-enabled.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、Amazon GuardDuty でランタイムモニタリングが有効になっているかどうかをチェックします。スタンドアロンアカウントの場合、アカウントで GuardDuty ランタイムモニタリングが無効になっていると、コントロールは失敗します。マルチアカウント環境では、委任 GuardDuty 管理者アカウントとすべてのメンバーアカウントで GuardDuty ランタイムモニタリングが無効になっている場合、コントロールは失敗します。

マルチアカウント環境で組織内のアカウントの GuardDuty ランタイムモニタリングを有効または無効にできるのは、委任 GuardDuty 管理者アカウントのみです。さらに、GuardDuty が組織内のアカウントの AWS ワークロードとリソースのランタイムモニタリングに使用するセキュリティエージェントを設定および管理できるのは、GuardDuty 管理者のみです。GuardDuty メンバーアカウントは、自分のアカウントのランタイムモニタリングを有効化、設定、または無効化することはできません。

GuardDuty Runtime Monitoring は、オペレーティングシステムレベル、ネットワーク、ファイルイベントを監視および分析して、環境内の特定の AWS ワークロードで潜在的な脅威を検出するのに役立ちます。GuardDuty セキュリティエージェントを使用して、ファイルアクセス、プロセス実行、コマンドライン引数、ネットワーク接続などのランタイム動作を可視化します。Amazon EKS クラスターや Amazon EC2 インスタンスなど、潜在的な脅威をモニタリングするリソースタイプごとに、セキュリティエージェントを有効にして管理できます。

### 修正
<a name="guardduty-11-remediation"></a>

GuardDuty ランタイムモニタリングの設定と有効化の詳細については、「*Amazon GuardDuty ユーザーガイド*」の「[GuardDuty ランタイムモニタリング](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html)」と「[GuardDuty ランタイムモニタリングの有効化](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring-configuration.html)」を参照してください。

## [GuardDuty.12] GuardDuty ECS ランタイムモニタリングを有効にする必要があります
<a name="guardduty-12"></a>

**カテゴリ:** 検出 > 検出サービス

**重要度:** 中

**リソースタイプ :** `AWS::GuardDuty::Detector`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/guardduty-ecs-protection-runtime-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/guardduty-ecs-protection-runtime-enabled.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、 AWS Fargateで Amazon ECS クラスターのランタイムモニタリングを行うために Amazon GuardDuty 自動セキュリティエージェントが有効になっているかどうかをチェックします。スタンドアロンアカウントの場合、アカウントでセキュリティエージェントが無効になっていると、コントロールは失敗します。マルチアカウント環境では、委任 GuardDuty 管理者アカウントとすべてのメンバーアカウントでセキュリティエージェントが無効になっている場合、コントロールは失敗します。

マルチアカウント環境では、このコントロールは委任 GuardDuty 管理者アカウントでのみ検出結果を生成します。これは、組織内のアカウントの ECS-Fargate リソースのランタイムモニタリングを有効または無効にできるのは 委任 GuardDuty 管理者のみであるためです。GuardDuty メンバーアカウントは、自分のアカウントに対してこれを行うことはできません。さらに、このコントロールは、GuardDuty がメンバーアカウントで停止されていて、メンバーアカウントで ECS-Fargate リソースのランタイムモニタリングが無効になっている場合に `FAILED` 検出結果を生成します。`PASSED` 検出結果を受け取るには、GuardDuty 管理者が GuardDuty を使用して、停止されたメンバーアカウントと管理者アカウントの関連付けを解除する必要があります。

GuardDuty Runtime Monitoring は、オペレーティングシステムレベル、ネットワーク、ファイルイベントを監視および分析して、環境内の特定の AWS ワークロードで潜在的な脅威を検出するのに役立ちます。GuardDuty セキュリティエージェントを使用して、ファイルアクセス、プロセス実行、コマンドライン引数、ネットワーク接続などのランタイム動作を可視化します。潜在的な脅威をモニタリングするリソースタイプごとに、セキュリティエージェントを有効にして管理できます。これには、 AWS Fargate上の Amazon ECS クラスターが含まれます。

### 修正
<a name="guardduty-12-remediation"></a>

ECS-Fargate リソースの GuardDuty ランタイムモニタリングを行うために、セキュリティエージェントを有効にして管理するには、GuardDuty を直接使用する必要があります。ECS-Fargate リソースに対してこの機能を手動で有効化または管理することはできません。セキュリティエージェントの有効化と管理の詳細については、[「Amazon GuardDuty ユーザーガイド」の AWS Fargate 「(Amazon ECS のみ) サポートの前提条件](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ecs-support.html)」と[AWS Fargate 「(Amazon ECS のみ) の自動セキュリティエージェントの管理](https://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-ecs-automated.html)」を参照してください。 *Amazon GuardDuty *

## [GuardDuty.13] GuardDuty EC2 ランタイムモニタリングを有効にする必要があります
<a name="guardduty-13"></a>

**カテゴリ:** 検出 > 検出サービス

**重要度:** 中

**リソースタイプ :** `AWS::GuardDuty::Detector`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/guardduty-ec2-protection-runtime-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/guardduty-ec2-protection-runtime-enabled.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、Amazon EC2 インスタンスのランタイムモニタリングを行うために Amazon GuardDuty 自動セキュリティエージェントが有効になっているかどうかをチェックします。スタンドアロンアカウントの場合、アカウントでセキュリティエージェントが無効になっていると、コントロールは失敗します。マルチアカウント環境では、委任 GuardDuty 管理者アカウントとすべてのメンバーアカウントでセキュリティエージェントが無効になっている場合、コントロールは失敗します。

マルチアカウント環境では、このコントロールは委任 GuardDuty 管理者アカウントでのみ検出結果を生成します。これは、組織内のアカウントの Amazon EC2 インスタンスのランタイムモニタリングを有効または無効にできるのは 委任 GuardDuty 管理者のみであるためです。GuardDuty メンバーアカウントは、自分のアカウントに対してこれを行うことはできません。さらに、このコントロールは、GuardDuty がメンバーアカウントで停止されていて、メンバーアカウントで EC2 インスタンスのランタイムモニタリングが無効になっている場合に `FAILED` 検出結果を生成します。`PASSED` 検出結果を受け取るには、GuardDuty 管理者が GuardDuty を使用して、停止されたメンバーアカウントと管理者アカウントの関連付けを解除する必要があります。

GuardDuty Runtime Monitoring は、オペレーティングシステムレベル、ネットワーク、ファイルイベントを監視および分析して、環境内の特定の AWS ワークロードで潜在的な脅威を検出するのに役立ちます。GuardDuty セキュリティエージェントを使用して、ファイルアクセス、プロセス実行、コマンドライン引数、ネットワーク接続などのランタイム動作を可視化します。潜在的な脅威をモニタリングするリソースタイプごとに、セキュリティエージェントを有効にして管理できます。これには Amazon EC2 インスタンスが含まれます。

### 修正
<a name="guardduty-13-remediation"></a>

EC2 インスタンスの GuardDuty ランタイムモニタリングを行うために自動セキュリティエージェントを設定して管理する方法については、「*Amazon GuardDuty ユーザーガイド*」の「[Prerequisites for Amazon EC2 instance support](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html)」と「[Enabling the automated security agent for Amazon EC2 instances](https://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-ec2-automated.html)」を参照してください。

# の Security Hub CSPM コントロール AWS Identity and Access Management
<a name="iam-controls"></a>

これらの AWS Security Hub CSPM コントロールは、 AWS Identity and Access Management (IAM) サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [IAM.1] IAM ポリシーでは、完全な「\$1」管理者権限を許可しないでください
<a name="iam-1"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/1.22、CIS AWS Foundations Benchmark v1.4.0/1.16、NIST.800-53.r5 AC-2、NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-5、NIST.800-53.r5 AC-6r5 AC-6(10)、NIST.800-53.r5 AC-6(2) NIST.800-53.r5 AC-6

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 高

**リソースタイプ :** `AWS::IAM::Policy`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/iam-policy-no-statements-with-admin-access.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-policy-no-statements-with-admin-access.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**
+ `excludePermissionBoundaryPolicy: true` (カスタマイズ不可)

このコントロールは、IAM ポリシー (カスタマー管理ポリシーとも呼ばれます) のデフォルトバージョンに、`"Action": "*"` が `"Resource": "*"` に対して規定された `"Effect": "Allow"` ステートメントを持つ管理者アクセス権があるかどうかをチェックします。このようなステートメントを含む IAM ポリシーがある場合、コントロールは失敗します。

コントロールは、作成したカスタマーマネージドポリシーのみをチェックします。インラインポリシーと AWS 管理ポリシーはチェックされません。

IAM ポリシーは、ユーザー、グループ、またはロールに付与される権限のセットを定義します。標準のセキュリティアドバイスに従って、 AWS は最小権限を付与することをお勧めします。これは、タスクの実行に必要なアクセス許可のみを付与することを意味します。ユーザーが必要とする最小限の許可セットではなく、完全な管理者権限を提供すると、リソースが不要なアクションにさらされる可能性があります。

完全な管理者権限を許可するのではなく、ユーザーが何をする必要があるのかを決定し、ユーザーが、それらのタスクのみを実行できるポリシーを作成します。最小限の許可セットから開始し、必要に応じて追加許可を付与する方がより安全です。あまりにも寛大な許可から始めて、後でそれらを強化しようとしないでください。

`"Effect": "Allow" ` および `"Action": "*"` が `"Resource": "*"` に対して規定されたステートメントを持つ IAM ポリシーは削除する必要があります。

**注記**  
AWS Config Security Hub CSPM を使用するすべてのリージョンで を有効にする必要があります。ただし、グローバルリソースの記録は 1 つのリージョンで有効にすることができます。グローバルリソースを 1 つのリージョンにのみ記録する場合は、グローバルリソースを記録するリージョン以外のすべてのリージョンでこのコントロールを無効にすることができます。

### 修正
<a name="iam-1-remediation"></a>

IAM ポリシーを変更して、完全な「\$1」管理者権限を許可しないようにする方法については、「*IAM ユーザーガイド*」の「[IAM ポリシーの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html)」を参照してください。

## [IAM.2] IAM ユーザーには IAM ポリシーを添付しないでください
<a name="iam-2"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/1.14、CIS AWS Foundations Benchmark v3.0.0/1.15、CIS AWS Foundations Benchmark v1.2.0/1.16、NIST.800-53.r5 AC-2、NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-63.NIST.800-53.r5 AC-6800-17r2

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 低

**リソースタイプ :** `AWS::IAM::User`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/iam-user-no-policies-check.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-user-no-policies-check.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、IAM ユーザーにポリシーが添付済みかどうかをチェックします。IAM ユーザーにポリシーが添付されている場合、コントロールは失敗します。代わりに、IAM ユーザーは、IAM グループまたはロールから許可を継承するか、ロールを引き受ける必要があります。

デフォルトでは、IAM ユーザー、グループ、ロールは AWS リソースにアクセスできません。IAM ポリシーで、ユーザー、グループ、またはロールに権限を付与します。IAM ポリシーはグループとロールには直接適用しますが、ユーザーには直接適用しないことを推奨します。グループレベルまたはロールレベルで権限を割り当てると、ユーザー数が増えるにつれてアクセス管理の複雑さが軽減されます。アクセス管理の複雑さを軽減することで、プリンシパルが誤って過剰な権限を受け取ったり保持する機会を減らすことができます。

**注記**  
AWS Config Security Hub CSPM を使用するすべてのリージョンで を有効にする必要があります。ただし、グローバルリソースの記録は 1 つのリージョンで有効にすることができます。グローバルリソースを 1 つのリージョンにのみ記録する場合は、グローバルリソースを記録するリージョン以外のすべてのリージョンでこのコントロールを無効にすることができます。

### 修正
<a name="iam-2-remediation"></a>

この問題を解決するには、[IAM グループを作成し](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_create.html)、ポリシーをこのグループにアタッチします。続いて、[ユーザーをこのグループに追加します](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_add-remove-users.html)。ポリシーは、グループ内の各ユーザーに適用されます。ユーザーに直接添付されているポリシーを削除するには、「*IAM ユーザーガイド*」の「[IAM ID のアクセス許可の追加および削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)」を参照してください。

## [IAM.3] IAM ユーザーのアクセスキーは 90 日以内にローテーションする必要があります
<a name="iam-3"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/1.13、CIS AWS Foundations Benchmark v3.0.0/1.14、CIS AWS Foundations Benchmark v1.4.0/1.14、CIS AWS Foundations Benchmark v1.2.0/1.4、NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-2(3)、NIST.800-53.r5 AC-3(15)、PCI DSS v4.0.1/8.3.9、PCI DSS v4.0.1/8.6.3

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 中 

**リソースタイプ :** `AWS::IAM::User`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/access-keys-rotated.html](https://docs.aws.amazon.com/config/latest/developerguide/access-keys-rotated.html)

**スケジュールタイプ :** 定期的

**パラメータ :**
+ `maxAccessKeyAge`: `90` (カスタマイズ不可)

このコントロールは、アクティブなアクセスキーが 90 日以内にローテーションされているかどうかをチェックします。

アカウントのすべてのアクセスキーを生成したり削除したりしないことを強く推奨します。代わりに、1 つ以上の IAM ロールを作成するか、[フェデレーション](https://aws.amazon.com/identity/federation/)を使用することをお勧めします AWS IAM アイデンティティセンター。これらの方法を使用して、 AWS マネジメントコンソール および へのアクセスをユーザーに許可できます AWS CLI。

各アプローチにはそれぞれのユースケースがあります。フェデレーションは、既存の中央ディレクトリを保有する企業や、現在の制限 IAM ユーザーよりも多くを必要とする予定の企業にとって一般的に適しています。 AWS 環境外で実行されるアプリケーションには、 AWS リソースへのプログラムによるアクセスのためのアクセスキーが必要です。

ただし、プログラムによるアクセスを必要とするリソースが内部で実行されている場合 AWS、ベストプラクティスは IAM ロールを使用することです。ロールを使用すると、アクセスキー ID とシークレットアクセスキーを設定にハードコーディングすることなく、リソースへのアクセスを許可できます。

アクセスキーとアカウントの保護の詳細については、の[AWS 「アクセスキーを管理するためのベストプラクティス](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html)」を参照してください*AWS 全般のリファレンス*。また、ブログ記事[「プログラムによるアクセスの使用 AWS アカウント 中に を保護するためのガイドライン」も参照してください](https://aws.amazon.com/blogs/security/guidelines-for-protecting-your-aws-account-while-using-programmatic-access/)。

アクセスキーがすでにある場合、Security Hub CSPM では、アクセスキーを 90 日ごとにローテーションすることをお勧めします。アクセスキーをローテーションすることにより、侵害されたアカウントや終了したアカウントに関連付けられているアクセスキーが使用される可能性が低くなります。また、紛失した、クラックされた、盗まれた古いキーでデータにアクセスできないようにします。アクセスキーをローテーションしたら、必ずアプリケーションを更新してください。

アクセスキーは、アクセスキー ID とシークレットアクセスキーで構成されます。これは AWSへのプログラムによるリクエストの署名に使用されます。ユーザーは、、Tools for Windows PowerShell AWS CLI、 AWS SDKs、または個々の API オペレーションを使用した直接 HTTP 呼び出し AWS からプログラムで を呼び出すために、独自のアクセスキーが必要です AWS のサービス。

組織が AWS IAM アイデンティティセンター (IAM Identity Center) を使用している場合、ユーザーは Active Directory、組み込みの IAM Identity Center ディレクトリ、または [IAM Identity Center に接続された別の ID プロバイダー (IdP) に](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html)サインインできます。その後、アクセスキーを必要とせずに AWS CLI コマンドを実行したり AWS API オペレーションを呼び出すことができる IAM ロールにマッピングできます。詳細については、「 *AWS Command Line Interface ユーザーガイド*[」の「 を使用する AWS CLI ように AWS IAM アイデンティティセンター](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html)を設定する」を参照してください。

**注記**  
AWS Config Security Hub CSPM を使用するすべてのリージョンで を有効にする必要があります。ただし、グローバルリソースの記録は 1 つのリージョンで有効にすることができます。グローバルリソースを 1 つのリージョンにのみ記録する場合は、グローバルリソースを記録するリージョン以外のすべてのリージョンでこのコントロールを無効にすることができます。

### 修正
<a name="iam-3-remediation"></a>

90 日以上経過したアクセスキーをローテーションするには、「*IAM ユーザーガイド*」の「[アクセスキーのローテーション](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)」を参照してください。**[アクセスキーの有効期間]** が 90 日を超えるすべてのユーザーに対する指示に従ってください。

## [IAM.4] IAM ルートユーザーアクセスキーが存在してはいけません
<a name="iam-4"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/1.3、CIS AWS Foundations Benchmark v3.0.0/1.4、CIS AWS Foundations Benchmark v1.4.0/1.4、CIS AWS Foundations Benchmark v1.2.0/1.12、PCI DSS v3.2.1/2.1、PCI DSS v3.2.1/2.2、PCI DSS v3.2.1/7.2.1、NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)NIST.800-53.r5 AC-6 -

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 非常事態 

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/iam-root-access-key-check.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-root-access-key-check.html)

**スケジュールタイプ :** 定期的

**パラメータ:** なし

このコントロールは、ルートユーザーアクセスキーが存在するかどうかをチェックします。

ルートユーザーは、 で最も特権のあるユーザーです AWS アカウント。 AWS アクセスキーは、特定のアカウントへのプログラムによるアクセスを提供します。

Security Hub CSPM では、ルートユーザーに関連付けられているすべてのアクセスキーを削除することをお勧めします。これにより、お使いのアカウントの侵害に使用できるベクトルが制限されます。また、最小特権のロールベースのアカウントの作成と使用が促進されます。

### 修正
<a name="iam-4-remediation"></a>

ルートユーザーアクセスキーを削除するには、「*IAM ユーザーガイド*」の「[ルートユーザーのアクセスキーの削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#id_root-user_manage_delete-key)」を参照してください。 AWS アカウント の からルートユーザーアクセスキーを削除するには AWS GovCloud (US)、*AWS GovCloud (US) 「 ユーザーガイド*[」の AWS GovCloud (US) 「アカウントルートユーザーアクセスキーの削除](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-account-root-user.html#delete-govcloud-root-access-key)」を参照してください。

## [IAM.5] コンソールパスワードを使用するすべての IAM ユーザーに対して MFA を有効にする必要があります
<a name="iam-5"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/1.9、CIS AWS Foundations Benchmark v3.0.0/1.10、CIS AWS Foundations Benchmark v1.4.0/1.10、CIS AWS Foundations Benchmark v1.2.0/1.2、NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 IA-2(1)、NIST.800-53.r5 IA-2(2)、NIST.800-53.r5 IA-2(6)、NIST.800-53.r5 IA-2(8 IA-2)

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 中

**リソースタイプ :** `AWS::IAM::User`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/mfa-enabled-for-iam-console-access.html](https://docs.aws.amazon.com/config/latest/developerguide/mfa-enabled-for-iam-console-access.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、コンソールパスワードを使用するすべての IAM ユーザーに対して AWS 多要素認証 (MFA) が有効になっているかどうかを確認します。

多要素認証 (MFA) は、ユーザー名とパスワードに更なる保護手段を追加します。MFA を有効にすると、ユーザーが AWS ウェブサイトにサインインすると、ユーザー名とパスワードの入力を求められます。さらに、 AWS MFA デバイスから認証コードの入力を求められます。

コンソールパスワードを使用するすべてのアカウントにおいて、MFA を有効にすることを推奨します。MFA は、コンソールアクセスのセキュリティを強化するために設計されています。認証プリンシパルは、時間的制約のあるキーを発行するデバイスを所有し、認証情報に関する知識がある必要があります。

**注記**  
AWS Config Security Hub CSPM を使用するすべてのリージョンで を有効にする必要があります。ただし、グローバルリソースの記録は 1 つのリージョンで有効にすることができます。グローバルリソースを 1 つのリージョンにのみ記録する場合は、グローバルリソースを記録するリージョン以外のすべてのリージョンでこのコントロールを無効にすることができます。

### 修正
<a name="iam-5-remediation"></a>

IAM ユーザーに MFA を追加するには、「*IAM ユーザーガイド*」の「[Using multi-factor authentication (MFA) in AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)」を参照してください。

## [IAM.6] ルートユーザーに対してハードウェア MFA を有効にする必要があります
<a name="iam-6"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/1.5、CIS AWS Foundations Benchmark v3.0.0/1.6、CIS AWS Foundations Benchmark v1.4.0/1.6、CIS AWS Foundations Benchmark v1.2.0/1.14、PCI DSS v3.2.1/8.3.1、NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 IA-2(1)、NIST.800IA-2-53.r5 IA-2(2)、NIST.800- IA-2

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 非常事態

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/root-account-hardware-mfa-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/root-account-hardware-mfa-enabled.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロール AWS アカウント は、 がハードウェア多要素認証 (MFA) デバイスを使用してルートユーザー認証情報でサインインできるかどうかを確認します。ハードウェア MFA が有効になっていない場合や、仮想 MFA デバイスにルートユーザー認証情報によるサインインが許可されている場合、コントロールは失敗します。

仮想 MFA はハードウェア MFA デバイスと同じレベルのセキュリティを提供しない可能性があります。ハードウェアの購入承認の待機中、またはハードウェアの到着を待つ間にのみ、仮想 MFA デバイスの使用を推奨します。詳細については、*IAM ユーザーガイド*[の「仮想 MFA デバイスの割り当て (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable_virtual.html)」を参照してください。

**注記**  
Security Hub CSPM は、 内のルートユーザー認証情報 (ログインプロファイル) の存在に基づいてこのコントロールを評価します AWS アカウント。コントロールは、次の場合に `PASSED` 検出結果を生成します。  
ルートユーザーの認証情報がアカウントに存在し、ルートユーザーのハードウェア MFA が有効になっている。
ルートユーザーの認証情報がアカウントに存在しない。
このコントロールは、ルートユーザーの認証情報がアカウントに存在し、ルートユーザーのハードウェア MFA が有効になっていない場合、`FAILED` 検出結果を生成します。

### 修正
<a name="iam-6-remediation"></a>

ルートユーザーのハードウェア MFA を有効にする方法については、「*IAM ユーザーガイド*」の「[AWS アカウントのルートユーザーの多要素認証](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-mfa-for-root.html)」を参照してください。

## [IAM.7] IAM ユーザーのパスワードポリシーには強力な設定が必要です
<a name="iam-7"></a>

**関連する要件:** NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-2(3)、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 IA-5(1)、NIST.800-171.r2 3.5.2、NIST.800-171.r2 3.5.7、NIST.800-171.r2 3.5.8、PCI DSS v4.0.1/8.3.6、PCI DSS v4.0.1/8.3.7、PCI DSS v4.0.1/8.3.9、PCI DSS v4.0.1/8.3.10.1、PCI DSS v4.0.1/8.6.3

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 中

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html)

**スケジュールタイプ :** 定期的

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `RequireUppercaseCharacters`  |  パスワードには少なくとも 1 つの大文字が必要です  |  ブール値  |  `true` 、、または `false`  |  `true`  | 
|  `RequireLowercaseCharacters`  |  パスワードには少なくとも 1 つの小文字が必要です  |  ブール値  |  `true` 、、または `false`  |  `true`  | 
|  `RequireSymbols`  |  パスワードには少なくとも 1 つの記号が必要です  |  ブール値  |  `true` 、、または `false`  |  `true`  | 
|  `RequireNumbers`  |  パスワードには少なくとも 1 つの数字が必要です  |  ブール値  |  `true` 、、または `false`  |  `true`  | 
|  `MinimumPasswordLength`  |  パスワードに含まれる文字の最小数  |  整数  |  `8`～`128`  |  `8`  | 
|  `PasswordReusePrevention`  |  古いパスワードを再使用できるようになるまでのパスワードローテーション回数  |  整数  |  `12`～`24`  |  デフォルト値なし  | 
|  `MaxPasswordAge`  |  パスワードが有効期限切れになるまでの日数  |  整数  |  `1`～`90`  |  デフォルト値なし  | 

このコントロールは、IAM ユーザーのアカウントパスワードポリシーが強力な設定を使用しているかどうかをチェックします。パスワードポリシーが強力な設定を使用していない場合、コントロールは失敗します。カスタムパラメータ値を指定しない限り、Security Hub CSPM は前の表で説明したデフォルト値を使用します。`PasswordReusePrevention` および `MaxPasswordAge`パラメータにはデフォルト値がないため、これらのパラメータを除外すると、Security Hub CSPM はこのコントロールを評価するときにパスワードのローテーション数とパスワード経過時間を無視します。

にアクセスするには AWS マネジメントコンソール、IAM ユーザーにパスワードが必要です。ベストプラクティスとして、Security Hub CSPM では、IAM ユーザーを作成する代わりにフェデレーションを使用することを強くお勧めします。フェデレーションでは、ユーザーは既存の企業認証情報を使用して、 AWS マネジメントコンソールにログインできます。 AWS IAM アイデンティティセンター (IAM Identity Center) を使用してユーザーを作成またはフェデレーションし、アカウントに IAM ロールを引き受けます。

アイデンティティプロバイダーとフェデレーションの詳細については、「IAM ユーザーガイド」の「[アイデンティティプロバイダーとフェデレーション](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)」を参照してください。IAM Identity Center の詳細については、「[https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」を参照してください。

 IAM ユーザーを使用する必要がある場合、Security Hub CSPM では、強力なユーザーパスワードの作成を強制することをお勧めします。でパスワードポリシーを設定 AWS アカウント して、パスワードの複雑さの要件と必須のローテーション期間を指定できます。パスワードポリシーを作成または変更する場合、パスワードポリシーの設定の多くは、ユーザーが次回パスワードを変更するときに適用されます。ただし、一部の設定は即座に適用されます。

### 修正
<a name="iam-7-remediation"></a>

パスワードポリシーの更新については、「*IAM ユーザーガイド*」の「[IAM ユーザーのアカウントパスワードポリシーの設定](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)」を参照してください。

## [IAM.8] 未使用の IAM ユーザー認証情報は削除する必要があります
<a name="iam-8"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/1.3、NIST.800-53.r5 AC-2、NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-2(3)、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-6、NIST.800-171.r2 3.1.2、PCI DSS v3.2.1/8.1.4、PCI DSS v4.0.1/8.2.

**カテゴリ:** 保護 > セキュアなアクセス管理 

**重要度:** 中 

**リソースタイプ :** `AWS::IAM::User`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/iam-user-unused-credentials-check.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-user-unused-credentials-check.html)

**スケジュールタイプ :** 定期的

**パラメータ :**
+ `maxCredentialUsageAge`: `90` (カスタマイズ不可)

このコントロールは、IAM ユーザーが 90 日間使用されていないパスワードまたはアクティブなアクセスキーを持っているかどうかをチェックします。

IAM ユーザーは、パスワードやアクセスキーなど、さまざまなタイプの認証情報を使用して AWS リソースにアクセスできます。

Security Hub CSPM では、90 日以上使用されていないすべての認証情報を削除または非アクティブ化することをお勧めします。不要な認証情報を無効化または削除することにより、侵害または放棄されたアカウントに関連付けられている認証情報が使用される可能性が少なくなります。

**注記**  
AWS Config Security Hub CSPM を使用するすべてのリージョンで を有効にする必要があります。ただし、グローバルリソースの記録は 1 つのリージョンで有効にすることができます。グローバルリソースを 1 つのリージョンにのみ記録する場合は、グローバルリソースを記録するリージョン以外のすべてのリージョンでこのコントロールを無効にすることができます。

### 修正
<a name="iam-8-remediation"></a>

IAM コンソールでユーザー情報を表示すると、**[アクセスキーの有効期間]**、**[パスワードの有効期間]**、**[最終アクティビティ]** の列が表示されます。これらの列の値のいずれかが 90 日より大きい場合は、それらのユーザーの認証情報を非アクティブにします。

[認証情報レポート](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html#getting-credential-reports-console)を使用してユーザーアカウントをモニタリングし、90 日以上アクティビティのないアカウントを特定することもできます。IAM コンソールから認証情報レポートを `.csv` 形式でダウンロードできます。

非アクティブなアカウント、または未使用の認証情報を特定したら、それらを非アクティブ化します。手順については、「*IAM ユーザーガイド*」の「[IAM ユーザーパスワードの作成、変更、削除 (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_admin-change-user.html#id_credentials_passwords_admin-change-user_console)」を参照してください。

## [IAM.9] ルートユーザーに対して MFA を有効にする必要があります
<a name="iam-9"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/1.4、PCI DSS v3.2.1/8.3.1、PCI DSS v4.0.1/8.4.2、CIS AWS Foundations Benchmark v3.0.0/1.5、CIS AWS Foundations Benchmark v1.4.0/1.5、CIS AWS Foundations Benchmark v1.2.0/1.13、NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3(15)、NIST.800IA-2-53.r5 IA-2(2)、NIST.800-5 IA-2 

**カテゴリ:** 保護 > セキュアなアクセス管理 

**重要度:** 非常事態

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/root-account-mfa-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/root-account-mfa-enabled.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、 の IAM ルートユーザーが にサインイン AWS アカウント するために多要素認証 (MFA) が有効になっているかどうかを確認します AWS マネジメントコンソール。アカウントのルートユーザーに対して MFA が有効になっていない場合、コントロールは失敗します。

の IAM ルートユーザーは AWS アカウント 、アカウント内のすべてのサービスとリソースに完全にアクセスできます。MFA が有効になっている場合、 にサインインするには、ユーザーは AWS MFA デバイスからユーザー名、パスワード、および認証コードを入力する必要があります AWS マネジメントコンソール。MFA は、ユーザー名とパスワードに更なる保護手段を追加します。

このコントロールは、次の場合に `PASSED` 検出結果を生成します。
+ ルートユーザーの認証情報がアカウントに存在し、ルートユーザーの MFA が有効になっている。
+ ルートユーザーの認証情報がアカウントに存在しない。

このコントロールは、ルートユーザーの認証情報がアカウントに存在し、ルートユーザーに対して MFA が有効になっていない場合、`FAILED` 検出結果を生成します。

### 修正
<a name="iam-9-remediation"></a>

のルートユーザーの MFA を有効にする方法については AWS アカウント、*AWS Identity and Access Management 「 ユーザーガイド*」の[「 の多要素認証 AWS アカウントのルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-mfa-for-root.html)」を参照してください。

## [IAM.10] IAM ユーザーのパスワードポリシーには強力な設定が必要です
<a name="iam-10"></a>

**関連する要件:** NIST.800-171.r2 3.5.2、NIST.800-171.r2 3.5.7、NIST.800-171.r2 3.5.8、PCI DSS v3.2.1/8.1.4、PCI DSS v3.2.1/8.2.3、PCI DSS v3.2.1/8.2.4、PCI DSS v3.2.1/8.2.5

**カテゴリ:** 保護 > セキュアなアクセス管理 

**重要度:** 中

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html)

**スケジュールタイプ :** 定期的

**パラメータ:** なし

このコントロールは、IAM ユーザーのアカウントパスワードポリシーが次の最低限の PCI DSS 設定を使用しているかどうかをチェックします。
+ `RequireUppercaseCharacters` - パスワードには少なくとも 1 つの大文字が必要。(デフォルト = `true`)
+ `RequireLowercaseCharacters` - パスワードには少なくとも 1 つの小文字が必要。(デフォルト = `true`)
+ `RequireNumbers` - パスワードには少なくとも 1 つの数字が必要。(デフォルト = `true`)
+ `MinimumPasswordLength` - パスワードの最小文字数。(デフォルト = 7 以上)
+ `PasswordReusePrevention` - パスワードの再利用を許可するまでのパスワードの数。(デフォルト = 4)
+ `MaxPasswordAge` – パスワードが有効期限切れになるまでの日数。(デフォルト = 90)

**注記**  
2025 年 5 月 30 日、Security Hub CSPM は PCI DSS v4.0.1 標準からこのコントロールを削除しました。PCI DSS v4.0.1 では、8 文字以上のパスワードが必要です。このコントロールは、異なるパスワード要件を持つ PCI DSS v3.2.1 標準に引き続き適用されます。  
PCI DSS v4.0.1 の要件に照らしてアカウントのパスワードポリシーを評価するには、[IAM.7 コントロール](#iam-7)を使用できます。このコントロールでは、8 文字以上のパスワードが必要です。また、パスワードの長さやその他のパラメータのカスタム値もサポートしています。IAM.7 コントロールは、Security Hub CSPM における PCI DSS v4.0.1 標準の一部です。

### 修正
<a name="iam-10-remediation"></a>

推奨される設定を使用するようにパスワードポリシーを更新するには、「*IAM ユーザーガイド*」の「[IAM ユーザー用のアカウントパスワードポリシーの設定](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)」を参照してください。

## [IAM.11] IAM パスワードポリシーで少なくとも 1 文字の大文字が要求されていることを確認します
<a name="iam-11"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/1.5、NIST.800-171.r2 3.5.7、PCI DSS v4.0.1/8.3.6、PCI DSS v4.0.1/8.6.3

**カテゴリ:** 保護 > セキュアなアクセス管理 

**重要度:** 中

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

パスワードポリシーは、パスワードの複雑さの要件をある程度強制します。IAM パスワードポリシーを使用して、パスワードで異なる文字セットを使用するようにします。

CIS では、パスワードポリシーで少なくとも 1 文字の大文字を要求することを推奨しています。パスワードの複雑さに関するポリシーを設定すると、ブルートフォースのログイン試行に対するアカウントの耐障害性が高まります。

### 修正
<a name="iam-11-remediation"></a>

パスワードポリシーの変更については、「*IAM ユーザーガイド*」の「[IAM ユーザーのアカウントパスワードポリシーの設定](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)」を参照してください。**[パスワードの強度]** で、**[ラテンアルファベット (A–Z) の少なくとも 1 つの大文字が必要]** を選択します。

## [IAM.12] IAM パスワードポリシーで少なくとも 1 文字の小文字が要求されていることを確認します
<a name="iam-12"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/1.6、NIST.800-171.r2 3.5.7、PCI DSS v4.0.1/8.3.6、PCI DSS v4.0.1/8.6.3

**カテゴリ:** 保護 > セキュアなアクセス管理 

**重要度:** 中

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

パスワードポリシーは、パスワードの複雑さの要件をある程度強制します。IAM パスワードポリシーを使用して、パスワードで異なる文字セットを使用するようにします。CIS では、パスワードポリシーで少なくとも 1 文字の小文字を要求することを推奨しています。パスワードの複雑さに関するポリシーを設定すると、ブルートフォースのログイン試行に対するアカウントの耐障害性が高まります。

### 修正
<a name="iam-12-remediation"></a>

パスワードポリシーの変更については、「*IAM ユーザーガイド*」の「[IAM ユーザーのアカウントパスワードポリシーの設定](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)」を参照してください。**[パスワードの強度]** で、**[ラテンアルファベット (A–Z) の少なくとも 1 つの小文字が必要]** を選択します。

## [IAM.13] IAM パスワードポリシーで少なくとも 1 文字の記号が要求されていることを確認します
<a name="iam-13"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/1.7、NIST.800-171.r2 3.5.7

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 中

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

パスワードポリシーは、パスワードの複雑さの要件をある程度強制します。IAM パスワードポリシーを使用して、パスワードで異なる文字セットを使用するようにします。

CIS では、パスワードポリシーで少なくとも 1 文字の記号を要求することを推奨しています。パスワードの複雑さに関するポリシーを設定すると、ブルートフォースのログイン試行に対するアカウントの耐障害性が高まります。

### 修正
<a name="iam-13-remediation"></a>

パスワードポリシーの変更については、「*IAM ユーザーガイド*」の「[IAM ユーザーのアカウントパスワードポリシーの設定](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)」を参照してください。**[パスワードの強度]** で、**[少なくとも 1 つの英数字以外の文字が必要]** を選択します。

## [IAM.14] IAM パスワードポリシーで少なくとも 1 文字の数字が要求されていることを確認します
<a name="iam-14"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/1.8、NIST.800-171.r2 3.5.7、PCI DSS v4.0.1/8.3.6、PCI DSS v4.0.1/8.6.3

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 中

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

パスワードポリシーは、パスワードの複雑さの要件をある程度強制します。IAM パスワードポリシーを使用して、パスワードで異なる文字セットを使用するようにします。

CIS では、パスワードポリシーで少なくとも 1 文字の数字を要求することを推奨しています。パスワードの複雑さに関するポリシーを設定すると、ブルートフォースのログイン試行に対するアカウントの耐障害性が高まります。

### 修正
<a name="iam-14-remediation"></a>

パスワードポリシーの変更については、「*IAM ユーザーガイド*」の「[IAM ユーザーのアカウントパスワードポリシーの設定](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)」を参照してください。**[パスワードの強度]** で、**[少なくとも 1 つの数字が必要]** を選択します。

## [IAM.15] IAM パスワードポリシーで 14 文字以上の長さが要求されていることを確認します
<a name="iam-15"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/1.7、CIS AWS Foundations Benchmark v3.0.0/1.8、CIS AWS Foundations Benchmark v1.4.0/1.8、CIS AWS Foundations Benchmark v1.2.0/1.9、NIST.800-171.r2 3.5.7

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 中

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

パスワードポリシーは、パスワードの複雑さの要件をある程度強制します。IAM パスワードポリシーを使用して、パスワードが指定された長さ以上になるようにします。

CIS では、パスワードポリシーで 14 文字以上の長さを要求することを推奨しています。パスワードの複雑さに関するポリシーを設定すると、ブルートフォースのログイン試行に対するアカウントの耐障害性が高まります。

### 修正
<a name="iam-15-remediation"></a>

パスワードポリシーの変更については、「*IAM ユーザーガイド*」の「[IAM ユーザーのアカウントパスワードポリシーの設定](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)」を参照してください。**[パスワードの最小文字数]** で、**14** またはそれ以上の数字を入力します。

## [IAM.16] IAM パスワードポリシーはパスワードの再使用を禁止しています
<a name="iam-16"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/1.8、CIS AWS Foundations Benchmark v3.0.0/1.9、CIS AWS Foundations Benchmark v1.4.0/1.9、CIS AWS Foundations Benchmark v1.2.0/1.10、NIST.800-171.r2 3.5.8、PCI DSS v4.0.1/8.3.7

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 低

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、記憶するパスワードの数が 24 に設定されているかどうかをチェックします。値が 24 でない場合、コントロールは失敗します。

IAM パスワードポリシーにより、同じユーザーによる特定のパスワードの再使用を防ぐことができます。

CIS では、パスワードポリシーでパスワードの再使用を禁止することを推奨しています。パスワードの再使用を禁止すると、ブルートフォースのログイン試行に対するアカウントの耐障害性が高まります。

### 修正
<a name="iam-16-remediation"></a>

パスワードポリシーの変更については、「*IAM ユーザーガイド*」の「[IAM ユーザーのアカウントパスワードポリシーの設定](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)」を参照してください。**[パスワードの再利用を禁止]** で、**24** と入力します。

## [IAM.17] IAM パスワードポリシーでパスワードが 90 日以内に有効期限切れとなることを確認します
<a name="iam-17"></a>

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/1.11、PCI DSS v4.0.1/8.3.9、PCI DSS v4.0.1/8.3.10.1

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 低

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

IAM パスワードポリシーでは、指定された日数後にパスワードをローテーションするか、または有効期限切れにすることを要求できます。

CIS では、パスワードポリシーでパスワードを 90 日以内に有効期限切れにすることを推奨しています。パスワードの有効期間を短くすると、ブルートフォースのログイン試行に対するアカウントの耐障害性が高まります。定期的なパスワード変更の要求は、以下のシナリオでも役立ちます。
+ パスワードはユーザーが知らない間に、盗まれたり漏洩したりする可能性があります。これは、システムの侵害、ソフトウェアの脆弱性、または内部の脅威によって起こりえます。
+ 特定の企業や政府のウェブフィルターまたはプロキシサーバーは、暗号化されている場合でもトラフィックを傍受し記録できます。
+ 多くの人々が仕事、E メール、個人用など多くのシステムで同じパスワードを使用しています。
+ 侵害されたエンドユーザーのワークステーションに、キーストロークロガーが設置されている可能性があります。

### 修正
<a name="iam-17-remediation"></a>

パスワードポリシーの変更については、「*IAM ユーザーガイド*」の「[IAM ユーザーのアカウントパスワードポリシーの設定](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)」を参照してください。**[パスワードの有効期間をオンにする]** で、**90** またはそれより小さい数字を入力します。

## [IAM.18] でインシデントを管理するためのサポートロールが作成されていることを確認します AWS サポート
<a name="iam-18"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/1.16、CIS AWS Foundations Benchmark v3.0.0/1.17、CIS AWS Foundations Benchmark v1.4.0/1.17、CIS AWS Foundations Benchmark v1.2.0/1.20、NIST.800-171.r2 3.1.2、PCI DSS v4.0.1/12.10.3

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 低

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/iam-policy-in-use.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-policy-in-use.html)

**スケジュールタイプ :** 定期的

**パラメータ :**
+ `policyARN`: `arn:partition:iam::aws:policy/AWSSupportAccess` (カスタマイズ不可)
+ `policyUsageType`: `ANY` (カスタマイズ不可)

AWS は、インシデントの通知と対応、テクニカルサポート、カスタマーサービスに使用できるサポートセンターを提供します。

IAM ロールを作成して、認可済みのユーザーが AWS サポートでインシデントを管理できるようにします。アクセスコントロールの最小権限を実装することで、IAM ロールには、インシデントを管理するためにサポートセンターへのアクセスを許可する適切な IAM ポリシーが必要です サポート。

**注記**  
AWS Config Security Hub CSPM を使用するすべてのリージョンで を有効にする必要があります。ただし、グローバルリソースの記録は 1 つのリージョンで有効にすることができます。グローバルリソースを 1 つのリージョンにのみ記録する場合は、グローバルリソースを記録するリージョン以外のすべてのリージョンでこのコントロールを無効にすることができます。

### 修正
<a name="iam-18-remediation"></a>

この問題を修正するには、認可済みのユーザーに サポート インシデントの管理を許可するロールを作成します。

**サポート アクセスに使用するロールを作成するには**

1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

1. IAM ナビゲーションペインで **[Roles]** (ロール) を選択し、続いて **[Create role]** (ロールの作成) を選択します。

1. **[Role type]** (ロールタイプ) で、**[Another AWS アカウント]** を選択します。

1. **アカウント ID** には、リソースへのアクセスを許可する AWS アカウント の AWS アカウント ID を入力します。

   このロールを引き受けるユーザーまたはグループが同じアカウントに属している場合は、ローカルアカウント番号を入力します。
**注記**  
指定したアカウントの管理者は、そのアカウントのすべての ユーザーに、このロールを引き受けるアクセス許可を付与できます。そのためには、管理者から `sts:AssumeRole` アクションの許可を付与するユーザーまたはグループにポリシーを添付します。そのポリシーで、リソースはロール ARN である必要があります。

1. **[Next: Permissions]** (次へ: 許可) を選択します。

1. マネージドポリシー `AWSSupportAccess` を検索します。

1. `AWSSupportAccess` マネージドポリシーのチェックボックスを選択します。

1. **[Next: Tags]** (次へ: タグ) を選択します。

1. (オプション) ロールにメタデータを追加するには、キーバリューのペアとしてタグをアタッチします。

   IAM でのタグの使用の詳細については、「*IAM ユーザーガイド*」の「[IAM ユーザーとロールのタグ付け](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html)」を参照してください。

1. **[Next: Review]** (次へ: レビュー) を選択します。

1. **[Role name]** (ロール名) に、ロールの名前を入力します。

   ロール名は 内で一意である必要があります AWS アカウント。大文字と小文字は区別されません。

1. (オプション) **[Role description]** (ロールの説明) に、新しいロールの説明を入力します。

1. ロールを確認し、**[Create role]** (ロールの作成) を選択します。

## [IAM.19] すべての IAM ユーザーに対して MFA を有効にする必要があります
<a name="iam-19"></a>

**関連する要件:** NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 IA-2(1)、NIST.800-53.r5 IA-2(2)、NIST.800-53.r5 IA-2(6)、NIST.800-53.r5 IA-2(8)、NIST.800-171.r2 3.3.8、NIST.800-171.r2 3.5.3、NIST.800-171.r2 3.5.4、NIST.800-171.r2 3.7.5、PCI DSS v3.2.1/8.3.1、PCI DSS v4.0.1/8.4.2 

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 中

**リソースタイプ :** `AWS::IAM::User`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/iam-user-mfa-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-user-mfa-enabled.html)

**スケジュールタイプ :** 定期的

**パラメータ:** なし

このコントロールは、IAM ユーザーが多要素認証 (MFA) を有効にしているかどうかを確認します。

**注記**  
AWS Config Security Hub CSPM を使用するすべてのリージョンで を有効にする必要があります。ただし、グローバルリソースの記録は 1 つのリージョンで有効にすることができます。グローバルリソースを 1 つのリージョンにのみ記録する場合は、グローバルリソースを記録するリージョン以外のすべてのリージョンでこのコントロールを無効にすることができます。

### 修正
<a name="iam-19-remediation"></a>

IAM ユーザーに MFA を追加するには、「*IAM ユーザーガイド*」の「[Enabling MFA devices for users in AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable.html)」を参照してください。

## [IAM.20] ルートユーザーの使用を避けます
<a name="iam-20"></a>

**重要**  
Security Hub CSPM は、2024 年 4 月にこのコントロールを廃止しました。詳細については、「[Security Hub CSPM コントロールの変更ログ](controls-change-log.md)」を参照してください。

**関連する要件:** CIS AWS Foundations Benchmark v1.2.0/1.1

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 低

**リソースタイプ :** `AWS::IAM::User`

**AWS Config rule:** `use-of-root-account-test` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロール AWS アカウント は、 にルートユーザーの使用に制限があるかどうかをチェックします。このコントロールは、以下のリソースを評価します。
+ Amazon Simple Notification Service (Amazon SNS)のトピック
+ AWS CloudTrail 証跡
+ CloudTrail トレイルに関連するメトリックスフィルター
+ フィルターに基づく Amazon CloudWatch アラーム

チェックの結果、以下の記述の 1 つ以上が真であれば `FAILED` と判定されます:
+ アカウントには CloudTrail トレイルは存在しません。
+ CloudTrail を有効にして、少なくとも 1 つのマルチリージョンの追跡で、読み取りと書き込みの管理イベントを含めた設定をする必要があります
+ CloudTrail トレイルは有効になっていますが、CloudWatch Logs ロググループには関連付けられていません。
+ Center for Internet Security (CIS) が規定する正確なメトリックフィルターが使用されていません。規定のメトリックフィルターは `'{$.userIdentity.type="Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType !="AwsServiceEvent"}'` です。
+ メトリックスフィルターに基づく CloudWatch アラームがアカウントに存在しません。
+ 関連する SNS トピックに通知を送信するように設定された CloudWatch アラームは、アラーム条件に基づいてトリガーされません。
+ SNS トピックが、[SNS トピックにメッセージを送信するための制約](https://docs.aws.amazon.com/sns/latest/api/API_Publish.html)に準拠していません。
+ SNS トピックに 1 人以上のサブスクライバーが存在しません。

チェックの結果、以下の条件の 1 つ以上に当てはまれば、`NO_DATA` コントロールステータスになります:
+ マルチリージョンの追跡が別のリージョンに基づいています。Security Hub CSPM は、証跡が基づいているリージョンでのみ結果を生成できます。
+ マルチリージョンの追跡が別のアカウントに属しています。Security Hub CSPM は、証跡を所有するアカウントの結果のみを生成できます。

チェックの結果、以下の条件の 1 つ以上に当てはまれば、`WARNING` コントロールステータスになります:
+ 現在のアカウントは、CloudWatch アラームで参照されている SNS トピックを所有していません。
+ `ListSubscriptionsByTopic` SNS API を呼び出しても、現在のアカウントは SNS トピックにアクセスできません。

**注記**  
組織内の多数のアカウントからのイベントを記録するには、組織の証跡を使用することをお勧めします。組織の証跡は、デフォルトではマルチリージョンの証跡であり、 AWS Organizations 管理アカウントまたは CloudTrail 委任管理者アカウントによってのみ管理できます。組織の証跡を使用すると、組織のメンバーアカウントで評価されたコントロールの管理ステータスは NO\$1DATA になります。メンバーアカウントでは、Security Hub CSPM はメンバー所有のリソースの結果のみを生成します。組織の証跡に関する検出結果は、リソース所有者のアカウントで生成されます。これらの検出結果は、クロスリージョン集約を使用して Security Hub CSPM 委任管理者アカウントで確認できます。

ベストプラクティスは、[アカウントおよびサービスの管理タスクを実行する](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html)ときに必要となる場合のみ、ルートユーザー認証情報を使用することです。IAM ポリシーは直接ユーザーに適用するのではなく、グループとロールに適用します。毎日使用するために管理者を設定する手順については、IAM *ユーザーガイド*の[「最初の IAM 管理者ユーザーとグループの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html)」を参照してください。

### 修正
<a name="iam-20-remediation"></a>

この問題を修正するためのステップには、Amazon SNS トピック、CloudTrail 追跡、メトリクスフィルター、およびメトリクスフィルターのアラームの設定が含まれます。

**Amazon SNS トピックを作成するには**

1. Amazon SNS コンソール ([https://console.aws.amazon.com/sns/v3/home](https://console.aws.amazon.com/sns/v3/home)) を開きます。

1. すべての CIS アラームを受信する Amazon SNS トピックを作成します。

   トピックに少なくとも 1 人の受信者を作成します。詳細については、「Amazon Simple Notification Service 開発者ガイド」の「[Amazon SNS の開始方法](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic)」を参照してください。

次に、すべてのリージョンに適用されるアクティブな CloudTrail を設定します。これを行うには、[[CloudTrail.1] CloudTrail を有効にして、少なくとも 1 つのマルチリージョンの追跡で、読み取りと書き込みの管理イベントを含めた設定をする必要があります。](cloudtrail-controls.md#cloudtrail-1) の修正ステップに従います。

CloudTrail 追跡に関連付ける CloudWatch Logs ロググループの名前を書き留めます。そのロググループに対してメトリクスフィルターを作成します。

最後に、メトリクスフィルターとアラームを作成します。

**メトリクスフィルターとアラームを作成するには**

1. CloudWatch コンソール ([https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)) を開きます。

1. ナビゲーションペインで、**[Log groups]** (ロググループ) を選択します。

1. 作成した CloudTrail 追跡に関連付けられている CloudWatch Logs ロググループのチェックボックスを選択します。

1. **[Actions]** (アクション) から、**[Create Metric Filter]** (メトリクスフィルターの作成) を選択します。

1. **[Define pattern]** (パターンを定義) で、以下の操作を行います。

   1. 次のパターンをコピーして、**[Filter Pattern]** (フィルターパターン) フィールドに貼り付けます。

      ```
      {$.userIdentity.type="Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType !="AwsServiceEvent"}
      ```

   1. **[Next]** (次へ) を選択します。

1. **[Assign Metric]** (メトリクスの割り当て) で、以下の操作を行います。

   1. **[Filter name]** (フィルター名) に、メトリクスフィルターの名前を入力します。

   1. **[Metric namespace]** (メトリクス名前空間) に **LogMetrics** と入力します。

      すべての CIS ログメトリクスフィルターに同じ名前空間を使用した場合、すべての CIS Benchmark メトリクスがグループ化されます。

   1. **[Metric Name]** (メトリクス名) に、メトリクスの名前を入力します。メトリクスの名前を忘れないでください。アラームの作成時にメトリクスを選択する必要があります。

   1. **[Metric value]** (メトリクス値) に **1** と入力します。

   1. **[Next]** (次へ) を選択します。

1. **[Review and create]** (確認して作成) で、新しいメトリクスフィルター用に入力した情報を確認します。その後、**[Create metric filter]** (メトリクスフィルターの作成) を選択します。

1. ナビゲーションペインで **[Log groups]** (ロググループ)を選択し、**[Metric filters]** (メトリクスフィルター) で作成したフィルターを選択します。

1. フィルターのチェックボックスをオンにします。[**アラームの作成**] を選択します。

1. **[Specify metric and conditions]** (メトリクスと条件の指定) で、以下の操作を行います。

   1. **[Conditions]** (条件) の **[Threshold]** (しきい値) で、**[Static]** (静的) を選択します。

   1. **[Define the alarm condition]** (アラーム条件を定義) で、**[Greater/Equal]** (より大きい/等しい) を選択します。

   1. **[Define the threshold value]** (しきい値の定義) で、**1** を入力します。

   1. **[Next]** (次へ) を選択します。

1. **[Configure actions]** (アクションの設定) で、次の作業を行います。

   1. **[Alarm state trigger]** (アラーム状態トリガー) で、**[In alarm]** (アラーム状態) を選択します。

   1. **[Select an SNS topic]** (SNS トピックの選択) で、**[Select an existing SNS topic]** (既存の SNS トピックの選択) を選択します。

   1. **[Send a notification to]** (通知の送信先) で、前の手順で作成した SNS トピックの名前を入力します。

   1. **[Next]** (次へ) を選択します。

1. **[Add name and description]** (名前と説明を追加) に、アラームの **[Name]** (名前)と **[Description]** (説明)を **CIS-1.1-RootAccountUsage** のように入力します。続いて、**[Next]** (次へ) を選択します。

1. **[Preview and create]** (プレビューと作成) で、アラームの設定を確認します。次に **[Create alarm]** (アラームの作成) を選択します。

## [IAM.21] 作成する IAM カスタマーマネージドポリシーにはサービスのワイルドカードアクションを許可してはいけません
<a name="iam-21"></a>

**関連する要件:** NIST.800-53.r5 AC-2、NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-5、NIST.800-53.r5 AC-6、NIST.800-53.r5 AC-6(10)、NIST.800-53.r5 AC-6(2)、NIST.800-53.r5 AC-6(3)、NIST.800-171.r2 3.1.1、NIST.800-171.r2 3.1.2、NIST.800-171.r2 3.1.5、NIST.800-171.r2 3.1.7、NIST.800-171.r2 3.3.8、NIST.800-171.r2 3.3.9、NIST.800-171.r2 3.13.3、NIST.800-171.r2 3.13.4

**カテゴリ:** 検出 > セキュアなアクセス管理 

**重要度:** 低

**リソースタイプ :** `AWS::IAM::Policy`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/iam-policy-no-statements-with-full-access.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-policy-no-statements-with-full-access.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**
+ `excludePermissionBoundaryPolicy`: `True` (カスタマイズ不可)

このコントロールは、作成した IAM アイデンティティベースのポリシーに、ワイルドカード (\$1) を使用して、任意のサービスに対してすべてのアクションに許可を付与する許可ステートメントがあるかどうかをチェックします。ポリシーステートメントに、`"Effect": "Allow"` と `"Action": "Service:*"` が含まれている場合、コントロールは失敗します。

例えば、ポリシーに次のような記述があると、結果は失敗となります。

```
"Statement": [
{
  "Sid": "EC2-Wildcard",
  "Effect": "Allow",
  "Action": "ec2:*",
  "Resource": "*"
}
```

`"Effect": "Allow"` と `"NotAction": "service:*"` を使用する場合も、コントロールは失敗します。この場合、 `NotAction`要素は、 で指定されたアクションを除き AWS のサービス、 のすべてのアクションへのアクセスを提供します`NotAction`。

このコントロールは、カスタマー管理 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 Config Security Hub CSPM を使用するすべてのリージョンで を有効にする必要があります。ただし、グローバルリソースの記録は 1 つのリージョンで有効にすることができます。グローバルリソースを 1 つのリージョンにのみ記録する場合は、グローバルリソースを記録するリージョン以外のすべてのリージョンでこのコントロールを無効にすることができます。

### 修正
<a name="iam-21-remediation"></a>

この問題を修正するには、IAM ポリシーを更新して、完全な「\$1」管理者権限を許可しないようにします。IAM ポリシーを編集する方法の詳細は、「*IAM ユーザーガイド*」の「[IAM ポリシーの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html)」を参照してください。

## [IAM.22] 45 日間未使用の IAM ユーザー認証情報は削除する必要があります
<a name="iam-22"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/1.11、CIS AWS Foundations Benchmark v3.0.0/1.12、CIS AWS Foundations Benchmark v1.4.0/1.12、NIST.800-171.r2 3.1.2

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 中

**リソースタイプ :** `AWS::IAM::User`

**AWS Config ルール: **[https://docs.aws.amazon.com/config/latest/developerguide/iam-user-unused-credentials-check.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-user-unused-credentials-check.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、IAM ユーザーが 45 日以上使用されていないパスワードまたはアクティブなアクセスキーを持っていないかどうかをチェックします。そのためには、 AWS Config ルールの `maxCredentialUsageAge`パラメータが 45 以上であるかどうかをチェックします。

ユーザーは、パスワードやアクセスキーなど、さまざまなタイプの認証情報を使用して AWS リソースにアクセスできます。

CIS では、45 日以上使用されていないすべての認証情報を削除または非アクティブ化することが推奨されています。不要な認証情報を無効化または削除することにより、侵害または放棄されたアカウントに関連付けられている認証情報が使用される可能性が少なくなります。

このコントロールの AWS Config ルールは、4 時間ごとにのみ更新される [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetCredentialReport.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetCredentialReport.html)および [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GenerateCredentialReport.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GenerateCredentialReport.html) API オペレーションを使用します。IAM ユーザーへの変更がこのコントロールから確認できるようになるまでに、最大 4 時間かかる場合があります。

**注記**  
AWS Config Security Hub CSPM を使用するすべてのリージョンで を有効にする必要があります。ただし、グローバルリソースの記録は 1 つのリージョンで有効にすることができます。グローバルリソースを 1 つのリージョンにのみ記録する場合は、グローバルリソースを記録するリージョン以外のすべてのリージョンでこのコントロールを無効にすることができます。

### 修正
<a name="iam-22-remediation"></a>

IAM コンソールでユーザー情報を表示すると、**[アクセスキーの有効期間]**、**[パスワードの有効期間]**、**[最終アクティビティ]** の列が表示されます。これらの列の値のいずれかが 45 日より大きい場合は、それらのユーザーの認証情報を非アクティブにします。

[認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html#getting-credential-reports-console)レポートを使用してユーザーアカウントをモニタリングし、45 日以上アクティビティのないアカウントを特定することもできます。IAM コンソールから認証情報レポートを `.csv` 形式でダウンロードできます。

非アクティブなアカウント、または未使用の認証情報を特定したら、それらを非アクティブ化します。手順については、「*IAM ユーザーガイド*」の「[IAM ユーザーパスワードの作成、変更、削除 (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_admin-change-user.html#id_credentials_passwords_admin-change-user_console)」を参照してください。

## [IAM.23] IAM Access Analyzer アナライザーにはタグを付ける必要があります
<a name="iam-23"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::AccessAnalyzer::Analyzer`

**AWS Config rule: ** `tagged-accessanalyzer-analyzer` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、 AWS Identity and Access Management Access Analyzer (IAM Access Analyzer) によって管理されるアナライザーに、パラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。アナライザーにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、アナライザーにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="iam-23-remediation"></a>

アナライザーにタグを追加するには、「*AWS IAM Access Analyzer API リファレンス*」の「[https://docs.aws.amazon.com/access-analyzer/latest/APIReference/API_TagResource.html](https://docs.aws.amazon.com/access-analyzer/latest/APIReference/API_TagResource.html)」を参照してください。

## [IAM.24] IAM ロールにはタグを付ける必要があります
<a name="iam-24"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IAM::Role`

**AWS Config rule: ** `tagged-iam-role` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、 AWS Identity and Access Management (IAM) ロールにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。ロールにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ロールにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、『』の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="iam-24-remediation"></a>

IAM ロールにタグを追加するには、「*IAM ユーザーガイド*」の「[IAM リソースのタグ付け](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html)」を参照してください。

## [IAM.25] IAM ユーザーにはタグを付ける必要があります
<a name="iam-25"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IAM::User`

**AWS Config rule: ** `tagged-iam-user` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、 AWS Identity and Access Management (IAM) ユーザーにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。ユーザーにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ユーザーがキーでタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、『』の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="iam-25-remediation"></a>

IAM ユーザーにタグを追加するには、「*IAM ユーザーガイド*」の「[IAM リソースのタグ付け](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html)」を参照してください。

## [IAM.26] IAM で管理されている期限切れの SSL/TLS 証明書は削除する必要があります
<a name="iam-26"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/1.18、CIS AWS Foundations Benchmark v3.0.0/1.19

**カテゴリ：** 識別 > コンプライアンス

**重要度:** 中

**リソースタイプ :** `AWS::IAM::ServerCertificate`

**AWS Config ルール: **[https://docs.aws.amazon.com/config/latest/developerguide/iam-server-certificate-expiration-check.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-server-certificate-expiration-check.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、IAM で管理されているアクティブな SSL/TLS サーバー証明書の有効期限が切れているかどうかを確認します。期限切れの SSL/TLS サーバー証明書が削除されない場合、コントロールは失敗します。

でウェブサイトまたはアプリケーションへの HTTPS 接続を有効にするには AWS、SSL/TLS サーバー証明書が必要です。IAM または AWS Certificate Manager (ACM) を使用して、サーバー証明書を保存およびデプロイできます。ACM でサポートされていない で HTTPS 接続をサポートする必要がある場合にのみ、IAM AWS リージョン を証明書マネージャーとして使用します。IAM はプライベートキーを安全に暗号化し、暗号化されたバージョンを IAM SSL 証明書ストレージに保存します。IAM はすべてのリージョンでのサーバー証明書のデプロイをサポートしていますが、 で使用するには外部プロバイダーから証明書を取得する必要があります AWS。ACM 証明書を IAM にアップロードすることはできません。また、IAM コンソールから証明書を管理することはできません。期限切れの SSL/TLS 証明書を削除すると、基盤となるアプリケーションやウェブサイトの信頼性を損うような、無効な証明書が誤ってリソースにデプロイされるといったリスクがなくなります。

### 修正
<a name="iam-26-remediation"></a>

IAM からサーバー証明書を削除するには、「*IAM ユーザーガイド*」の「[IAM でのサーバー証明書の管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_server-certs.html)」を参照してください。

## [IAM.27] IAM ID に AWSCloudShellFullAccess ポリシーをアタッチしないでください
<a name="iam-27"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/1.21、CIS AWS Foundations Benchmark v3.0.0/1.22

**カテゴリ:** 保護 > セキュアなアクセス管理 > セキュアな IAM ポリシー

**重要度:** 中

**リソースタイプ:** `AWS::IAM::Role`、`AWS::IAM::User`、`AWS::IAM::Group`

**AWS Config ルール: **[https://docs.aws.amazon.com/config/latest/developerguide/iam-policy-blacklisted-check.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-policy-blacklisted-check.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**
+ "policyArns": "arn:aws:iam::aws:policy/AWSCloudShellFullAccess,arn:aws-cn:iam::aws:policy/AWSCloudShellFullAccess, arn:aws-us-gov:iam::aws:policy/AWSCloudShellFullAccess"

このコントロールは、IAM ID (ユーザー、ロール、またはグループ) に AWS 管理ポリシーが`AWSCloudShellFullAccess`アタッチされているかどうかを確認します。IAM ID に `AWSCloudShellFullAccess` ポリシーがアタッチされている場合、コントロールは失敗します。

AWS CloudShell は、 CLI コマンドを実行するのに便利な方法を提供します AWS のサービス。 AWS マネージドポリシー`AWSCloudShellFullAccess`は CloudShell へのフルアクセスを提供します。これにより、ユーザーのローカルシステムと CloudShell 環境間のファイルのアップロードおよびダウンロード機能が可能になります。CloudShell 環境内では、ユーザーは sudo アクセス許可を持ち、インターネットにアクセスできます。その結果、このマネージドポリシーを IAM ID にアタッチすることで、ファイル転送ソフトウェアをインストールし、データを CloudShell から外部のインターネットサーバーに移動できます。最小特権の原則に従い、IAM ID に狭いアクセス許可をアタッチすることをお勧めします。

### 修正
<a name="iam-27-remediation"></a>

IAM ID から `AWSCloudShellFullAccess` ポリシーをデタッチするには、「*IAM ユーザーガイド*」の「[IAM ID アクセス許可の追加と削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)」を参照してください。

## [IAM.28] IAM Access Analyzer 外部アクセスアナライザーを有効にする必要があります
<a name="iam-28"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/1.19、CIS AWS Foundations Benchmark v3.0.0/1.20

**カテゴリ:** 検出 > 検出サービス > 特権使用状況モニタリング monitoring

**重要度:** 高

**リソースタイプ :** `AWS::AccessAnalyzer::Analyzer`

**AWS Config ルール: **[https://docs.aws.amazon.com/config/latest/developerguide/iam-external-access-analyzer-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-external-access-analyzer-enabled.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロール AWS アカウント は、 で IAM Access Analyzer 外部アクセスアナライザーが有効になっているかどうかを確認します。現在選択されている AWS リージョンで外部アクセスアナライザーが有効になっていない場合、コントロールは失敗します。

IAM Access Analyzer 外部アクセスアナライザーは、外部エンティティと共有されている Amazon Simple Storage Service (Amazon S3) バケットや IAM ロールなどのリソースを識別するのに役立ちます。これは、リソースやデータへの意図しないアクセスを回避するのに役立ちます。IAM Access Analyzer はリージョン別であり、各リージョンで有効にする必要があります。外部プリンシパルと共有されているリソースを識別するために、アクセスアナライザーはロジックベースの推論を使用して AWS 環境内のリソースベースのポリシーを分析します。外部アクセスアナライザー作成するときに、組織全体または個々のアカウントに対してアナライザーを作成して有効にすることができます。

**注記**  
アカウントが の組織の一部である場合 AWS Organizations、このコントロールでは、組織を信頼ゾーンとして指定し、現在のリージョンの組織に対して有効になっている外部アクセスアナライザーは考慮されません。組織がこのタイプの設定を使用している場合は、リージョンの組織内の個々のメンバーアカウントに対してこのコントロールを無効にすることを検討してください。

### 修正
<a name="iam-28-remediation"></a>

特定のリージョンで外部アクセスアナライザーを有効にする方法については、「*IAM ユーザーガイド*」の「[IAM Access Analyzer の開始方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html)」を参照してください。アナライザーは、リソースへのアクセスをモニタリングするリージョンごとに有効にする必要があります。

# Amazon Inspector の Security Hub CSPM コントロール
<a name="inspector-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon Inspector サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [Inspector.1] Amazon Inspector EC2 スキャンを有効にする必要があります
<a name="inspector-1"></a>

**関連する要件:** PCI DSS v4.0.1/11.3.1

**カテゴリ:** 検出 > 検出サービス

**重要度:** 高

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/inspector-ec2-scan-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/inspector-ec2-scan-enabled.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、Amazon Inspector EC2 スキャンが有効になっているかを確認します。スタンドアロンアカウントの場合、アカウントで Amazon Inspector EC2 スキャンが無効になっていると、コントロールは失敗します。マルチアカウント環境では、委任 Amazon Inspector 管理者アカウントとすべてのメンバーアカウントで EC2 スキャンが有効になっていない場合、コントロールは失敗します。

マルチアカウント環境では、コントロールは委任 Amazon Inspector 管理者アカウントでのみ検出結果を生成します。委任管理者のみが、組織内のメンバーアカウントの EC2 スキャン機能を有効または無効にできます。Amazon Inspector メンバーアカウントからは、この設定を変更できません。このコントロールは、委任管理者に Amazon Inspector EC2 スキャンが有効になっていない停止メンバーアカウントがある場合に `FAILED` 検出結果を生成します。`PASSED` 検出結果を受け取るには、委任管理者は Amazon Inspector でこれらの停止されたアカウントの関連付けを解除する必要があります。

Amazon Inspector EC2 スキャンは、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスからメタデータを抽出し、このメタデータをセキュリティアドバイザリから収集されたルールと比較して、検出結果を生成します。Amazon Inspector はインスタンスをスキャンして、パッケージの脆弱性とネットワークの到達性の問題がないか調べます。SSM エージェントなしでスキャンできるオペレーティングシステムなど、サポートされているオペレーティングシステムの詳細については、「[サポートされているオペレーティングシステム: Amazon EC2 スキャン](https://docs.aws.amazon.com/inspector/latest/user/supported.html#supported-os-ec2)」を参照してください。

### 修正
<a name="inspector-1-remediation"></a>

Amazon Inspector EC2 スキャンを有効にするには、「*Amazon Inspector ユーザーガイド*」の「[スキャンのアクティブ化](https://docs.aws.amazon.com/inspector/latest/user/activate-scans.html#activate-scans-proc)」を参照してください。

## [Inspector.2] Amazon Inspector ECR スキャンを有効にする必要があります
<a name="inspector-2"></a>

**関連する要件:** PCI DSS v4.0.1/11.3.1

**カテゴリ:** 検出 > 検出サービス

**重要度:** 高

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/inspector-ecr-scan-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/inspector-ecr-scan-enabled.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、Amazon Inspector ECR スキャンが有効になっているかを確認します。スタンドアロンアカウントの場合、アカウントで Amazon Inspector ECR スキャンが無効になっていると、コントロールは失敗します。マルチアカウント環境では、委任 Amazon Inspector 管理者アカウントとすべてのメンバーアカウントで ECR スキャンが有効になっていない場合、コントロールは失敗します。

マルチアカウント環境では、コントロールは委任 Amazon Inspector 管理者アカウントでのみ検出結果を生成します。委任管理者のみが、組織内のメンバーアカウントの ECR スキャン機能を有効または無効にできます。Amazon Inspector メンバーアカウントからは、この設定を変更できません。このコントロールは、委任管理者に Amazon Inspector ECR スキャンが有効になっていない停止メンバーアカウントがある場合に `FAILED` 検出結果を生成します。`PASSED` 検出結果を受け取るには、委任管理者は Amazon Inspector でこれらの停止されたアカウントの関連付けを解除する必要があります。

Amazon Inspector は、Amazon Elastic Container Registry (Amazon ECR) に保存されているコンテナイメージをスキャンしてソフトウェアの脆弱性がないかを調べ、パッケージ 脆弱性の検出結果を生成します。Amazon ECR の Amazon Inspector スキャンをアクティブ化すると、Amazon Inspector をプライベートレジストリの優先スキャンサービスとして設定します。これにより、Amazon ECR が無料で提供する基本的なスキャンが、Amazon Inspector を通じて提供および請求される拡張スキャンに置き換わります。拡張スキャンでは、オペレーティングシステムパッケージとプログラミング言語パッケージの両方をレジストリレベルで脆弱性スキャンできるという利点があります。拡張スキャンを使用して検出された検出結果は、Amazon ECR コンソールで、イメージのレイヤーごとにイメージレベルで確認できます。さらに、 や AWS Security Hub CSPM Amazon EventBridge など、基本的なスキャン検出には利用できない他のサービスで、これらの検出結果を確認して操作できます。

### 修正
<a name="inspector-2-remediation"></a>

Amazon Inspector ECR スキャンを有効にするには、「*Amazon Inspector ユーザーガイド*」の「[スキャンのアクティブ化](https://docs.aws.amazon.com/inspector/latest/user/activate-scans.html#activate-scans-proc)」を参照してください。

## [Inspector.3] Amazon Inspector Lambda コードスキャンを有効にする必要があります
<a name="inspector-3"></a>

**関連する要件:** PCI DSS v4.0.1/6.2.4、PCI DSS v4.0.1/6.3.1

**カテゴリ:** 検出 > 検出サービス

**重要度:** 高

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/inspector-lambda-code-scan-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/inspector-lambda-code-scan-enabled.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、Amazon Inspector Lambda コードスキャンが有効になっているかを確認します。スタンドアロンアカウントの場合、アカウントで Amazon Inspector Lambda コードスキャンが無効になっていると、コントロールは失敗します。マルチアカウント環境では、委任 Amazon Inspector 管理者アカウントとすべてのメンバーアカウントで Lambda コードスキャンが有効になっていない場合、コントロールは失敗します。

マルチアカウント環境では、コントロールは委任 Amazon Inspector 管理者アカウントでのみ検出結果を生成します。委任管理者のみが、組織内のメンバーアカウントの Lambda コードスキャン機能を有効または無効にできます。Amazon Inspector メンバーアカウントからは、この設定を変更できません。このコントロールは、委任管理者に Amazon Inspector Lambda コードスキャンが有効になっていない停止メンバーアカウントがある場合に `FAILED` 検出結果を生成します。`PASSED` 検出結果を受け取るには、委任管理者は Amazon Inspector でこれらの停止されたアカウントの関連付けを解除する必要があります。

Amazon Inspector Lambda コードスキャンは、 AWS セキュリティのベストプラクティスに基づいて、 AWS Lambda 関数内のカスタムアプリケーションコードをスキャンして、コードの脆弱性を検出します。Lambda コードスキャンでは、コード内のインジェクションの欠陥、データ漏洩、脆弱な暗号化、または暗号化の欠落を検出できます。この機能は特定の [AWS リージョン でのみ](https://docs.aws.amazon.com/inspector/latest/user/inspector_regions.html#ins-regional-feature-availability)使用できます。Lambda コードスキャンを Lambda 標準スキャンと同時にアクティブ化できます ([[Inspector.4] Amazon Inspector Lambda 標準スキャンを有効にする必要があります](#inspector-4) を参照)。

### 修正
<a name="inspector-3-remediation"></a>

Amazon Inspector Lambda コードスキャンを有効にするには、「*Amazon Inspector ユーザーガイド*」の「[スキャンのアクティブ化](https://docs.aws.amazon.com/inspector/latest/user/activate-scans.html#activate-scans-proc)」を参照してください。

## [Inspector.4] Amazon Inspector Lambda 標準スキャンを有効にする必要があります
<a name="inspector-4"></a>

**関連する要件:** PCI DSS v4.0.1/6.2.4、PCI DSS v4.0.1/6.3.1

**カテゴリ:** 検出 > 検出サービス

**重要度:** 高

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/inspector-lambda-standard-scan-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/inspector-lambda-standard-scan-enabled.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、Amazon Inspector Lambda 標準スキャンが有効になっているかを確認します。スタンドアロンアカウントの場合、アカウントで Amazon Inspector Lambda 標準スキャンが無効になっていると、コントロールは失敗します。マルチアカウント環境では、委任 Amazon Inspector 管理者アカウントとすべてのメンバーアカウントで Lambda 標準スキャンが有効になっていない場合、コントロールは失敗します。

マルチアカウント環境では、コントロールは委任 Amazon Inspector 管理者アカウントでのみ検出結果を生成します。委任管理者のみが、組織内のメンバーアカウントの Lambda 標準スキャン機能を有効または無効にできます。Amazon Inspector メンバーアカウントからは、この設定を変更できません。このコントロールは、委任管理者に Amazon Inspector Lambda 標準スキャンが有効になっていない停止メンバーアカウントがある場合に `FAILED` 検出結果を生成します。`PASSED` 検出結果を受け取るには、委任管理者は Amazon Inspector でこれらの停止されたアカウントの関連付けを解除する必要があります。

Amazon Inspector Lambda 標準スキャンは、 AWS Lambda 関数コードとレイヤーに追加するアプリケーションパッケージの依存関係のソフトウェアの脆弱性を特定します。Amazon Inspector が Lambda 関数のアプリケーションパッケージの依存関係に脆弱性を検出すると、Amazon Inspector は詳細な `Package Vulnerability` タイプの検出結果を生成します。Lambda コードスキャンを Lambda 標準スキャンと同時にアクティブ化できます ([[Inspector.3] Amazon Inspector Lambda コードスキャンを有効にする必要があります](#inspector-3) を参照)。

### 修正
<a name="inspector-4-remediation"></a>

Amazon Inspector Lambda 標準スキャンを有効にするには、「*Amazon Inspector ユーザーガイド*」の「[スキャンのアクティブ化](https://docs.aws.amazon.com/inspector/latest/user/activate-scans.html#activate-scans-proc)」を参照してください。

# の Security Hub CSPM コントロール AWS IoT
<a name="iot-controls"></a>

これらの AWS Security Hub CSPM コントロールは、 AWS IoT サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [IoT.1] AWS IoT Device Defender セキュリティプロファイルにはタグを付ける必要があります
<a name="iot-1"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IoT::SecurityProfile`

**AWS Config rule:** `tagged-iot-securityprofile` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、 AWS IoT Device Defender セキュリティプロファイルにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。セキュリティプロファイルにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、セキュリティプロファイルにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="iot-1-remediation"></a>

 AWS IoT Device Defender セキュリティプロファイルにタグを追加するには、「 *AWS IoT デベロッパーガイド*[」の「 AWS IoT リソースのタグ付け](https://docs.aws.amazon.com/iot/latest/developerguide/tagging-iot.html)」を参照してください。

## [IoT.2] AWS IoT Core 緩和アクションにはタグを付ける必要があります
<a name="iot-2"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IoT::MitigationAction`

**AWS Config rule:** `tagged-iot-mitigationaction` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、 AWS IoT Core 緩和アクションにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。緩和アクションにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、緩和アクションにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="iot-2-remediation"></a>

 AWS IoT Core 緩和アクションにタグを追加するには、「 *AWS IoT デベロッパーガイド*[」の AWS IoT 「リソースのタグ付け](https://docs.aws.amazon.com/iot/latest/developerguide/tagging-iot.html)」を参照してください。

## [IoT.3] AWS IoT Core ディメンションにはタグを付ける必要があります
<a name="iot-3"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IoT::Dimension`

**AWS Config rule:** `tagged-iot-dimension` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、 AWS IoT Core ディメンションにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。ディメンションにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ディメンションにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="iot-3-remediation"></a>

 AWS IoT Core ディメンションにタグを追加するには、「 *AWS IoT デベロッパーガイド*[」の AWS IoT 「リソースのタグ付け](https://docs.aws.amazon.com/iot/latest/developerguide/tagging-iot.html)」を参照してください。

## [IoT.4] AWS IoT Core オーソライザーにはタグを付ける必要があります
<a name="iot-4"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IoT::Authorizer`

**AWS Config rule:** `tagged-iot-authorizer` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、 AWS IoT Core オーソライザーにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。オーソライザーにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、オーソライザーがキーでタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、『』の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="iot-4-remediation"></a>

 AWS IoT Core オーソライザーにタグを追加するには、「 *AWS IoT デベロッパーガイド*[」の「 AWS IoT リソースのタグ付け](https://docs.aws.amazon.com/iot/latest/developerguide/tagging-iot.html)」を参照してください。

## [IoT.5] AWS IoT Core ロールエイリアスにはタグを付ける必要があります
<a name="iot-5"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IoT::RoleAlias`

**AWS Config ルール:** `tagged-iot-rolealias` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、 AWS IoT Core ロールエイリアスにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。ロールエイリアスにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ロールエイリアスがキーでタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="iot-5-remediation"></a>

 AWS IoT Core ロールエイリアスにタグを追加するには、「 *AWS IoT デベロッパーガイド*」の[AWS IoT 「リソースのタグ付け](https://docs.aws.amazon.com/iot/latest/developerguide/tagging-iot.html)」を参照してください。

## [IoT.6] AWS IoT Core ポリシーにはタグを付ける必要があります
<a name="iot-6"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IoT::Policy`

**AWS Config rule:** `tagged-iot-policy` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、 AWS IoT Core ポリシーにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。ポリシーにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ポリシーにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、『』の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="iot-6-remediation"></a>

 AWS IoT Core ポリシーにタグを追加するには、「 *AWS IoT デベロッパーガイド*[」の「 AWS IoT リソースのタグ付け](https://docs.aws.amazon.com/iot/latest/developerguide/tagging-iot.html)」を参照してください。

# AWS IoT イベントの Security Hub CSPM コントロール
<a name="iotevents-controls"></a>

これらの AWS Security Hub CSPM コントロールは、 AWS IoT Events サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [IoTEvents.1] AWS IoT Events 入力にはタグを付ける必要があります
<a name="iotevents-1"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IoTEvents::Input`

**AWS Config ルール :** `iotevents-input-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  デフォルト値なし  | 

このコントロールは、 AWS IoT Events 入力にパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。入力にタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、入力にキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="iotevents-1-remediation"></a>

 AWS IoT Events 入力にタグを追加するには、「 *AWS IoT Events デベロッパーガイド*[」の AWS IoT Events 「リソースのタグ付け](https://docs.aws.amazon.com/iotevents/latest/developerguide/tagging-iotevents.html)」を参照してください。

## [IoTEvents.2] AWS IoT Events ディテクターモデルにはタグを付ける必要があります
<a name="iotevents-2"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IoTEvents::DetectorModel`

**AWS Config ルール :** `iotevents-detector-model-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  デフォルト値なし  | 

このコントロールは、 AWS IoT Events ディテクターモデルにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。ディテクターモデルにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ディテクターモデルがキーでタグ付けされていない場合に失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="iotevents-2-remediation"></a>

 AWS IoT Events ディテクターモデルにタグを追加するには、「 *AWS IoT Events デベロッパーガイド*[」の「 AWS IoT Events リソースのタグ付け](https://docs.aws.amazon.com/iotevents/latest/developerguide/tagging-iotevents.html)」を参照してください。

## [IoTEvents.3] AWS IoT Events アラームモデルにはタグを付ける必要があります
<a name="iotevents-3"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IoTEvents::AlarmModel`

**AWS Config ルール :** `iotevents-alarm-model-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  デフォルト値なし  | 

このコントロールは、 AWS IoT Events アラームモデルにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。アラームモデルにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、アラームモデルにキーがタグ付けされていない場合に失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="iotevents-3-remediation"></a>

 AWS IoT Events アラームモデルにタグを追加するには、「 *AWS IoT Events デベロッパーガイド*[」の AWS IoT Events 「リソースのタグ付け](https://docs.aws.amazon.com/iotevents/latest/developerguide/tagging-iotevents.html)」を参照してください。

# AWS IoT SiteWise の Security Hub CSPM コントロール
<a name="iotsitewise-controls"></a>

これらの AWS Security Hub CSPM コントロールは、 AWS IoT SiteWise サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [IoTSiteWise.1] AWS IoT SiteWise アセットモデルにはタグを付ける必要があります
<a name="iotsitewise-1"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IoTSiteWise::AssetModel`

**AWS Config ルール :** `iotsitewise-asset-model-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  デフォルト値なし  | 

このコントロールは、 AWS IoT SiteWise アセットモデルにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。アセットモデルにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、アセットモデルにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="iotsitewise-1-remediation"></a>

 AWS IoT SiteWise アセットモデルにタグを追加するには、*AWS IoT SiteWise 「 ユーザーガイド*」の[AWS IoT SiteWise 「リソースのタグ付け](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/tag-resources.html)」を参照してください。

## [IoTSiteWise.2] AWS IoT SiteWise ダッシュボードにはタグを付ける必要があります
<a name="iotsitewise-2"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IoTSiteWise::Dashboard`

**AWS Config ルール :** `iotsitewise-dashboard-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  デフォルト値なし  | 

このコントロールは、 AWS IoT SiteWise ダッシュボードにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。ダッシュボードにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ダッシュボードにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="iotsitewise-2-remediation"></a>

 AWS IoT SiteWise ダッシュボードにタグを追加するには、*AWS IoT SiteWise 「 ユーザーガイド*」の[AWS IoT SiteWise 「リソースのタグ付け](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/tag-resources.html)」を参照してください。

## [IoTSiteWise.3] AWS IoT SiteWise ゲートウェイにはタグを付ける必要があります
<a name="iotsitewise-3"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IoTSiteWise::Gateway`

**AWS Config ルール :** `iotsitewise-gateway-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  デフォルト値なし  | 

このコントロールは、 AWS IoT SiteWise ゲートウェイにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。ゲートウェイにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ゲートウェイにキーがタグ付けされていない場合に失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="iotsitewise-3-remediation"></a>

 AWS IoT SiteWise ゲートウェイにタグを追加するには、*AWS IoT SiteWise 「 ユーザーガイド*」の[AWS IoT SiteWise 「リソースのタグ付け](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/tag-resources.html)」を参照してください。

## [IoTSiteWise.4] AWS IoT SiteWise ポータルにはタグを付ける必要があります
<a name="iotsitewise-4"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IoTSiteWise::Portal`

**AWS Config ルール :** `iotsitewise-portal-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  デフォルト値なし  | 

このコントロールは、 AWS IoT SiteWise ポータルにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。ポータルにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ポータルにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="iotsitewise-4-remediation"></a>

 AWS IoT SiteWise ポータルにタグを追加するには、*AWS IoT SiteWise 「 ユーザーガイド*」の[AWS IoT SiteWise 「リソースのタグ付け](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/tag-resources.html)」を参照してください。

## [IoTSiteWise.5] AWS IoT SiteWise プロジェクトにはタグを付ける必要があります
<a name="iotsitewise-5"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IoTSiteWise::Project`

**AWS Config ルール :** `iotsitewise-project-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  デフォルト値なし  | 

このコントロールは、 AWS IoT SiteWise プロジェクトにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。プロジェクトにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、プロジェクトにキーがタグ付けされていない場合に失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="iotsitewise-5-remediation"></a>

 AWS IoT SiteWise プロジェクトにタグを追加するには、*AWS IoT SiteWise 「 ユーザーガイド*」の[AWS IoT SiteWise 「リソースのタグ付け](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/tag-resources.html)」を参照してください。

# AWS IoT TwinMaker の Security Hub CSPM コントロール
<a name="iottwinmaker-controls"></a>

これらの AWS Security Hub CSPM コントロールは、 AWS IoT TwinMaker サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [IoTTwinMaker.1] AWS IoT TwinMaker 同期ジョブにはタグを付ける必要があります
<a name="iottwinmaker-1"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IoTTwinMaker::SyncJob`

**AWS Config ルール :** `iottwinmaker-sync-job-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  デフォルト値なし  | 

このコントロールは、 AWS IoT TwinMaker 同期ジョブにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。同期ジョブにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、同期ジョブにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="iottwinmaker-1-remediation"></a>

 AWS IoT TwinMaker 同期ジョブにタグを追加するには、*AWS IoT TwinMaker 「 ユーザーガイド*[https://docs.aws.amazon.com/iot-twinmaker/latest/apireference/API_TagResource.html](https://docs.aws.amazon.com/iot-twinmaker/latest/apireference/API_TagResource.html)」の「」を参照してください。

## [IoTTwinMaker.2] AWS IoT TwinMaker ワークスペースにはタグを付ける必要があります
<a name="iottwinmaker-2"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IoTTwinMaker::Workspace`

**AWS Config ルール :** `iottwinmaker-workspace-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  デフォルト値なし  | 

このコントロールは、 AWS IoT TwinMaker ワークスペースにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。ワークスペースにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ワークスペースにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="iottwinmaker-2-remediation"></a>

 AWS IoT TwinMaker ワークスペースにタグを追加するには、*AWS IoT TwinMaker 「 ユーザーガイド*[https://docs.aws.amazon.com/iot-twinmaker/latest/apireference/API_TagResource.html](https://docs.aws.amazon.com/iot-twinmaker/latest/apireference/API_TagResource.html)」の「」を参照してください。

## [IoTTwinMaker.3] AWS IoT TwinMaker シーンにはタグを付ける必要があります
<a name="iottwinmaker-3"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IoTTwinMaker::Scene`

**AWS Config ルール :** `iottwinmaker-scene-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  デフォルト値なし  | 

このコントロールは、 AWS IoT TwinMaker シーンにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。シーンにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、シーンにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="iottwinmaker-3-remediation"></a>

 AWS IoT TwinMaker シーンにタグを追加するには、*AWS IoT TwinMaker 「 ユーザーガイド*[https://docs.aws.amazon.com/iot-twinmaker/latest/apireference/API_TagResource.html](https://docs.aws.amazon.com/iot-twinmaker/latest/apireference/API_TagResource.html)」の「」を参照してください。

## [IoTTwinMaker.4] AWS IoT TwinMaker エンティティにはタグを付ける必要があります
<a name="iottwinmaker-4"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IoTTwinMaker::Entity`

**AWS Config ルール :** `iottwinmaker-entity-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  デフォルト値なし  | 

このコントロールは、 AWS IoT TwinMaker エンティティにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。エンティティにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、エンティティにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="iottwinmaker-4-remediation"></a>

 AWS IoT TwinMaker エンティティにタグを追加するには、*AWS IoT TwinMaker 「 ユーザーガイド*[https://docs.aws.amazon.com/iot-twinmaker/latest/apireference/API_TagResource.html](https://docs.aws.amazon.com/iot-twinmaker/latest/apireference/API_TagResource.html)」の「」を参照してください。

# AWS IoT Wireless の Security Hub CSPM コントロール
<a name="iotwireless-controls"></a>

これらの AWS Security Hub CSPM コントロールは、 AWS IoT Wireless サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [IoTWireless.1] AWS IoT Wireless マルチキャストグループにはタグを付ける必要があります
<a name="iotwireless-1"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IoTWireless::MulticastGroup`

**AWS Config ルール :** `iotwireless-multicast-group-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  デフォルト値なし  | 

このコントロールは、 AWS IoT Wireless マルチキャストグループにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。マルチキャストグループにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、マルチキャストグループがキーでタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="iotwireless-1-remediation"></a>

 AWS IoT Wireless マルチキャストグループにタグを追加するには、「 *AWS IoT Wireless デベロッパーガイド*[」の AWS IoT Wireless 「リソースのタグ付け](https://docs.aws.amazon.com/iot-wireless/latest/developerguide/tagging-iotwireless.html)」を参照してください。

## [IoTWireless.2] AWS IoT Wireless サービスプロファイルにはタグを付ける必要があります
<a name="iotwireless-2"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IoTWireless::ServiceProfile`

**AWS Config ルール :** `iotwireless-service-profile-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  デフォルト値なし  | 

このコントロールは、 AWS IoT Wireless サービスプロファイルにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。サービスプロファイルにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、サービスプロファイルがキーでタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="iotwireless-2-remediation"></a>

 AWS IoT Wireless サービスプロファイルにタグを追加するには、「 *AWS IoT Wireless デベロッパーガイド*[」の「 AWS IoT Wireless リソースのタグ付け](https://docs.aws.amazon.com/iot-wireless/latest/developerguide/tagging-iotwireless.html)」を参照してください。

## [IoTWireless.3] AWS IoT FUOTA タスクにはタグを付ける必要があります
<a name="iotwireless-3"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IoTWireless::FuotaTask`

**AWS Config ルール :** `iotwireless-fuota-task-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  デフォルト値なし  | 

このコントロールは、 AWS IoT Wireless ファームウェアのover-the-air更新 (FUOTA) タスクに、パラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。FUOTA タスクにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、FUOTA タスクにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="iotwireless-3-remediation"></a>

 AWS IoT Wireless FUOTA タスクにタグを追加するには、「 *AWS IoT Wireless デベロッパーガイド*[」の「 AWS IoT Wireless リソースのタグ付け](https://docs.aws.amazon.com/iot-wireless/latest/developerguide/tagging-iotwireless.html)」を参照してください。

# Amazon IVS の Security Hub CSPM コントロール
<a name="ivs-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon Interactive Video Service (IVS) サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [IVS.1] IVS 再生キーペアにはタグを付ける必要があります
<a name="ivs-1"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IVS::PlaybackKeyPair`

**AWS Config ルール :** `ivs-playback-key-pair-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  デフォルト値なし  | 

このコントロールは、Amazon IVS 再生キーペアにパラメータ `requiredKeyTags` で定義された特定のキーを持つタグがあるかどうかをチェックします。再生キーペアにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、再生キーペアにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="ivs-1-remediation"></a>

IVS 再生キーペアにタグを追加するには、「*Amazon IVS Real-Time Streaming API リファレンス*」の「[https://docs.aws.amazon.com/ivs/latest/RealTimeAPIReference/API_TagResource.html](https://docs.aws.amazon.com/ivs/latest/RealTimeAPIReference/API_TagResource.html)」を参照してください。

## [IVS.2] IVS 記録設定にはタグを付ける必要があります
<a name="ivs-2"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IVS::RecordingConfiguration`

**AWS Config ルール :** `ivs-recording configuration-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  デフォルト値なし  | 

このコントロールは、Amazon IVS 録画設定にパラメータ `requiredKeyTags` で定義された特定のキーを持つタグがあるかどうかをチェックします。録画設定にタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、録画設定にキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="ivs-2-remediation"></a>

IVS 録画設定にタグを追加するには、「*Amazon IVS Real-Time Streaming API リファレンス*」の「[https://docs.aws.amazon.com/ivs/latest/RealTimeAPIReference/API_TagResource.html](https://docs.aws.amazon.com/ivs/latest/RealTimeAPIReference/API_TagResource.html)」を参照してください。

## [IVS.3] IVS チャネルにはタグを付ける必要があります
<a name="ivs-3"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::IVS::Channel`

**AWS Config ルール :** `ivs-channel-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  デフォルト値なし  | 

このコントロールは、Amazon IVS チャネルにパラメータ `requiredKeyTags` で定義された特定のキーを持つタグがあるかどうかをチェックします。チャネルにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、チャネルにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="ivs-3-remediation"></a>

IVS チャネルにタグを追加するには、「*Amazon IVS Real-Time Streaming API リファレンス*」の「[https://docs.aws.amazon.com/ivs/latest/RealTimeAPIReference/API_TagResource.html](https://docs.aws.amazon.com/ivs/latest/RealTimeAPIReference/API_TagResource.html)」を参照してください。

# Amazon Keyspaces の Security Hub CSPM コントロール
<a name="keyspaces-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon Keyspaces サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [Keyspaces.1] Amazon Keyspaces キースペースにはタグを付ける必要があります
<a name="keyspaces-1"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::Cassandra::Keyspace`

**AWS Config ルール :** `cassandra-keyspace-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  デフォルト値なし  | 

このコントロールは、Amazon Keyspaces キースペースにパラメータ `requiredKeyTags` で定義された特定のキーを持つタグがあるかどうかをチェックします。キースペースにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、キースペースにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="keyspaces-1-remediation"></a>

Amazon Keyspaces キースペースにタグを追加するには、「*Amazon Keyspaces デベロッパーガイド*」の「[Add tags to a keyspace](https://docs.aws.amazon.com/keyspaces/latest/devguide/Tagging.Operations.existing.keyspace.html)」を参照してください。

# Kinesis の Security Hub CSPM コントロール
<a name="kinesis-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon Kinesis サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [Kinesis.1] Kinesis ストリームは、保管中に暗号化する必要があります
<a name="kinesis-1"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SI-7(6)

**カテゴリ:** 保護 > データ保護 > 保管中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::Kinesis::Stream`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/kinesis-stream-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/kinesis-stream-encrypted.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし 

このコントロールは、Amazon Kinesis Streams が保管中にサーバー側の暗号化を使用して暗号化されているかどうかをチェックします。Amazon Kinesis Streams が、保管中にサーバー側の暗号化を使用して暗号化されていない場合、このコントロールは失敗します。

サーバー側の暗号化は、 AWS KMS keyを使用してデータを保管中になる前に自動的に暗号化する、Amazon Kinesis Data Streams の機能です。データは、Kinesis ストリームストレージレイヤーに書き込まれる前に暗号化され、ストレージから取得された後で復号されます。これにより、Amazon Kinesis Data Streams サービス内に保管中のデータは暗号化されます。

### 修正
<a name="kinesis-1-remediation"></a>

Kinesis Streams でサーバー側の暗号化を有効にする方法については、「*Amazon Kinesis デベロッパーガイド*」の「[How do I get started with server-side encryption?](https://docs.aws.amazon.com/streams/latest/dev/getting-started-with-sse.html)」を参照してください。

## [Kinesis.2] Kinesis ストリームにはタグを付ける必要があります
<a name="kinesis-2"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::Kinesis::Stream`

**AWS Config rule:** `tagged-kinesis-stream` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon Kinesis データストリームにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。データストリームにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、データストリームにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="kinesis-2-remediation"></a>

Kinesis データストリームにタグを追加するには、「*Amazon Kinesis デベロッパーガイド*」の「[Amazon Kinesis Data Streams でのストリームのタグ付け](https://docs.aws.amazon.com/streams/latest/dev/tagging.html)」を参照してください。

## [Kinesis.3] Kinesis ストリームには適切なデータ保持期間が必要です
<a name="kinesis-3"></a>

**重要度:** 中

**リソースタイプ :** `AWS::Kinesis::Stream`

**AWS Configルール :** [https://docs.aws.amazon.com/config/latest/developerguide/kinesis-stream-backup-retention-check.html](https://docs.aws.amazon.com/config/latest/developerguide/kinesis-stream-backup-retention-check.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  minimumBackupRetentionPeriod  | データが保持される最小時間数。 | String  | 24～8760  | 168  | 

このコントロールは、Amazon Kinesis データストリームのデータ保持期間が指定された時間枠以上であるかどうかをチェックします。データ保持期間が指定された時間枠未満の場合、コントロールは失敗します。データ保持期間にカスタムパラメータ値を指定しない限り、Security Hub CSPM はデフォルト値の 168 時間を使用します。

Kinesis Data Streams では、データストリームは、データレコードの順序付けられたシーケンスで、リアルタイムで書き込みと読み取りができることが前提となっています。データレコードはシャードに一時的に保存されます。レコードが追加されてからアクセスできなくなるまでの期間は、保持期間と呼ばれます。Kinesis Data Streams は、保持期間が短縮されると、新しい保持期間よりも古いレコードをほぼ即座にアクセス不能にします。たとえば、保持期間を 24 時間から 48 時間に変更すると、23 時間 55 分前にストリームに追加されたレコードは、さらに 24 時間後まで使用できます。

### 修正
<a name="kinesis-3-remediation"></a>

Kinesis Data Streams のバックアップ保持期間を変更するには、「*Amazon Kinesis Data Streams デベロッパーガイド*」の「[データ保持期間の変更](https://docs.aws.amazon.com/streams/latest/dev/kinesis-extended-retention.html)」を参照してください。

# の Security Hub CSPM コントロール AWS KMS
<a name="kms-controls"></a>

これらの AWS Security Hub CSPM コントロールは、 AWS Key Management Service (AWS KMS) サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [KMS.1] IAM カスタマー管理ポリシーでは、すべての KMS キーの復号アクションを許可しないでください
<a name="kms-1"></a>

**関連する要件:** NIST.800-53.r5 AC-2、NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-5、NIST.800-53.r5 AC-6、NIST.800-53.r5 AC-6(3)

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 中

**リソースタイプ :** `AWS::IAM::Policy`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/iam-customer-policy-blocked-kms-actions.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-customer-policy-blocked-kms-actions.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :** 
+ `blockedActionsPatterns: kms:ReEncryptFrom, kms:Decrypt` (カスタマイズ不可)
+ `excludePermissionBoundaryPolicy`: `True` (カスタマイズ不可)

IAM カスタマー管理ポリシーのデフォルトバージョンで、プリンシパルがすべてのリソースで復 AWS KMS 号アクションを使用できるようにするかどうかを確認します。ポリシーがすべての KMS キーに対して `kms:Decrypt` または `kms:ReEncryptFrom` のアクションを許可するのに十分にオープンな場合、このコントロールは失敗します。

コントロールはリソース要素の KMS キーのみをチェックし、ポリシーの Condition 要素の条件は考慮しません。このコントロールは、添付済みのカスタマーマネージドポリシーと添付されていないカスタマーマネージドポリシーの両方を評価します。インラインポリシーや AWS 管理ポリシーはチェックされません。

を使用すると AWS KMS、KMS キーを使用できるユーザーを制御し、暗号化されたデータにアクセスできます。IAM ポリシーは、アイデンティティ (ユーザー、グループ、またはロール) がどのリソースに対してどのアクションを実行できるかを定義します。セキュリティのベストプラクティスに従って、 は最小権限を許可することを AWS 推奨しています。つまり、ID に付与するのは `kms:Decrypt` または `kms:ReEncryptFrom` 許可と、タスクの実行に必要なキーのみにする必要があります。そうでない場合、ユーザーはデータに適さないキーを使用する可能性があります。

すべてのキーに対する許可を付与する代わりに、ユーザーが暗号化されたデータにアクセスするために必要な最小限のキーのセットを決定します。次に、ユーザーがそれらのキーのみを使用できるようにするポリシーを設計します。例えば、すべての KMS キーに `kms:Decrypt` 許可を付与しないでください。代わりに、アカウントの特定のリージョン内のキーのみに `kms:Decrypt` を許可します。最小特権のプリンシパルを採用することで、意図しないデータ開示のリスクを減らすことができます。

### 修正
<a name="kms-1-remediation"></a>

IAM カスタマー管理ポリシーを変更するには、「*IAM ユーザーガイド*」の「[カスタマー管理ポリシーの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html#edit-managed-policy-console)」を参照してください。`Resource` フィールドのポリシーを編集する際、復号化アクションを許可する特定の 1 つまたは複数キーの Amazon リソースネーム (ARN) を指定します。

## [KMS.2] IAM プリンシパルは、すべての KMS キーで復号アクションを許可する IAM インラインポリシーを使用しないでください
<a name="kms-2"></a>

**関連する要件:** NIST.800-53.r5 AC-2、NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-5、NIST.800-53.r5 AC-6、NIST.800-53.r5 AC-6(3)

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 中

**リソースタイプ: **
+ `AWS::IAM::Group`
+ `AWS::IAM::Role`
+ `AWS::IAM::User`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/iam-inline-policy-blocked-kms-actions.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-inline-policy-blocked-kms-actions.html) 

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**
+ `blockedActionsPatterns: kms:ReEncryptFrom, kms:Decrypt` (カスタマイズ不可)

このコントロールは、IAM ID (ロール、ユーザー、またはグループ) に埋め込まれているインラインポリシーが、すべての AWS KMS KMS キーで復号化および再暗号化アクションを許可しているかどうかをチェックします。ポリシーがすべての KMS キーに対して `kms:Decrypt` または `kms:ReEncryptFrom` のアクションを許可するのに十分にオープンな場合、このコントロールは失敗します。

コントロールはリソース要素の KMS キーのみをチェックし、ポリシーの Condition 要素の条件は考慮しません。

を使用すると AWS KMS、KMS キーを使用できるユーザーを制御し、暗号化されたデータにアクセスできます。IAM ポリシーは、アイデンティティ (ユーザー、グループ、またはロール) がどのリソースに対してどのアクションを実行できるかを定義します。セキュリティのベストプラクティスに従って、 は最小権限を許可することを AWS 推奨しています。つまり、ID には必要な許可のみを、タスクの実行に必要なキーにのみ付与する必要があります。そうでない場合、ユーザーはデータに適さないキーを使用する可能性があります。

すべてのキーに対する許可を付与する代わりに、ユーザーが暗号化されたデータにアクセスするために必要なキーの最小セットを決定します。次に、ユーザーがそれらのキーのみを使用できるようにするポリシーを設計します。例えば、すべての KMS キーに `kms:Decrypt` 許可を付与しないでください。代わりに、アカウントの特定リージョンでの特定のキーにのみ許可を付与してください。最小特権のプリンシパルを採用することで、意図しないデータ開示のリスクを減らすことができます。

### 修正
<a name="kms-2-remediation"></a>

IAM インラインポリシーを変更するには、「*IAM ユーザーガイド*」の「[インラインポリシーの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html#edit-inline-policy-console)」を参照してください。`Resource` フィールドのポリシーを編集する際、復号化アクションを許可する特定の 1 つまたは複数キーの Amazon リソースネーム (ARN) を指定します。

## [KMS.3] AWS KMS keys を意図せずに削除しないでください
<a name="kms-3"></a>

**関連する要件:** NIST.800-53.r5 SC-12、NIST.800-53.r5 SC-12(2)

**カテゴリ:** 保護 > データ保護 > データ削除保護

**重要度:** 非常事態

**リソースタイプ :** `AWS::KMS::Key`

**AWS Config rule:** `kms-cmk-not-scheduled-for-deletion-2` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、KMS キーの削除がスケジュール済みかどうかをチェックします。KMS キーの削除がスケジュール済みの場合、コントロールは失敗します。

KMS キーは、一度削除すると復元できません。KMS キーで暗号化されたデータも、KMS キーが削除された場合は永久に回復できません。削除予定の KMS キーで、意味のあるデータが暗号化されている場合、意図的に暗号化消去を実行しない限り、データの復号化または新しい KMS キーでデータの再暗号化を検討してください。

KMS キーの削除がスケジュール済みで、誤ってスケジュールされた場合、削除の取り消し時間を確保するために、強制的に待ち時間が適用されます。デフォルトの待機期間は 30 日間ですが、KMS キーの削除がスケジュールされている場合は 7 日以内に短縮できます。待機期間中、スケジュール済みの削除はキャンセルすることができ、KMS キーは削除されません。

KMS キーの削除の詳細については、「AWS Key Management Service 開発者ガイド」の「[KMS キーの削除](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html)」を参照してください。

### 修正
<a name="kms-3-remediation"></a>

スケジュール済み KMS キーの削除をキャンセルには、「*AWS Key Management Service デベロッパーガイド*」の「[キー削除のスケジュールとキャンセル (コンソール)](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys-scheduling-key-deletion.html#deleting-keys-scheduling-key-deletion-console)」内にある「**キーの削除をキャンセルするには**」を参照してください。

## [KMS.4] AWS KMS キーローテーションを有効にする必要があります
<a name="kms-4"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/3.6、CIS AWS Foundations Benchmark v3.0.0/3.6、CIS AWS Foundations Benchmark v1.4.0/3.8、CIS AWS Foundations Benchmark v1.2.0/2.8、NIST.800-53.r5 SC-12、NIST.800-53.r5 SC-12(2)、NIST.800-53.r5 SC-28(3)、PCI DSS v3.2.1/3.6.4、PCI DSS v4.0.1/3.7.4

**カテゴリ:** 保護 > データ保護 > 保管中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::KMS::Key`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cmk-backing-key-rotation-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cmk-backing-key-rotation-enabled.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

AWS KMS では、 に保存されているキーマテリアルであり、KMS キーのキー ID AWS KMS に関連付けられているバッキングキーをローテーションできます。バッキングキーは、暗号化や復号化などの暗号化オペレーションを実行するために使用されます。現在、キーの自動ローテーションでは以前のすべてのバッキングキーが保持されるため、暗号化したデータは透過的に復号化できます。

CIS では、KMS キーのローテーションを有効にすることを推奨しています。新しいキーで暗号化されたデータは、漏洩した可能性がある以前のキーではアクセスできないため、暗号化キーをローテーションすることで、漏洩したキーにより起こる可能性のある被害を減らすことができます。

### 修正
<a name="kms-4-remediation"></a>

KMS キーローテーションを有効にするには、「*AWS Key Management Service デベロッパーガイド*」の「[自動キーローテーションを有効または無効にする方法](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html#rotating-keys-enable-disable)」を参照してください。

## [KMS.5] KMS キーはパブリックにアクセスしないでください
<a name="kms-5"></a>

**カテゴリ:** 保護 > セキュアなネットワーク設定 > パブリックアクセス不可のリソース

**重要度:** 非常事態

**リソースタイプ :** `AWS::KMS::Key`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/kms-key-policy-no-public-access.html](https://docs.aws.amazon.com/config/latest/developerguide/kms-key-policy-no-public-access.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロール AWS KMS key は、 がパブリックにアクセス可能かどうかをチェックします。KMS キーがパブリックにアクセス可能な場合、コントロールは失敗します。

最小特権アクセスの実装は、セキュリティリスクおよびエラーの影響や悪意ある行動を減らす上での基礎となります。のキーポリシーで外部アカウントからのアクセス AWS KMS key が許可されている場合、サードパーティーは キーを使用してデータを暗号化および復号化できる場合があります。これにより、 キーを使用する内部または外部の脅威 AWS のサービス が からデータを流出する可能性があります。

**注記**  
このコントロールは、設定で が KMS キーの設定項目 (CI) にキーポリシー AWS Config を記録 AWS KMS key できない場合も、 `FAILED`の結果を返します。 AWS Config が KMS キーの CI にキーポリシーを入力するには、[AWS Config ロール](https://docs.aws.amazon.com/config/latest/developerguide/gs-cli-prereq.html#gs-cli-create-iamrole)に [GetKeyPolicy](https://docs.aws.amazon.com/kms/latest/APIReference/API_GetKeyPolicy.html) API コールを使用してキーポリシーを読み取るためのアクセス権が必要です。このタイプの`FAILED`検出結果を解決するには、 AWS Config ロールが KMS キーのキーポリシーに読み取りアクセスできないようにするポリシーを確認します。たとえば、次のものをチェックします。  
KMS キーのキーポリシー。
アカウント AWS Organizations に適用される [のサービスコントロールポリシー (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) と[リソースコントロールポリシー (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)。
[AWS Config サービスにリンク](https://docs.aws.amazon.com/config/latest/developerguide/using-service-linked-roles.html)された AWS Config ロールを使用していない場合のロールのアクセス許可。
さらに、このコントロールはワイルドカード文字または変数を使用するポリシー条件を評価しません。`PASSED` 検出結果を生成するには、キーポリシーの条件は固定値のみを使用する必要があります。固定値は、ワイルドカード文字やポリシー変数を含まない値です。ポリシー変数に関する詳細については、「*AWS Identity and Access Management ユーザーガイド*」の「[変数およびタグ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html)」を参照してください。

### 修正
<a name="kms-5-remediation"></a>

のキーポリシーの更新については AWS KMS key、「 *AWS Key Management Service デベロッパーガイド*」の「 [のキーポリシー AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-overview)」を参照してください。

# の Security Hub CSPM コントロール AWS Lambda
<a name="lambda-controls"></a>

これらの AWS Security Hub CSPM コントロールは、 AWS Lambda サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [Lambda.1] Lambda 関数ポリシーでは、パブリックアクセスを禁止する必要があります
<a name="lambda-1"></a>

**関連する要件:** NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)、PCI DSS v3.2.1/1.2.1、PCI DSS v3.2.1/1.3.1、PCI DSS v3.2.1/1.3.2、PCI DSS v3.2.1/1.3.4、PCI DSS v3.2.1/7.2.1、PCI DSS v4.0.1/7.2.1

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 非常事態

**リソースタイプ :** `AWS::Lambda::Function`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/lambda-function-public-access-prohibited.html](https://docs.aws.amazon.com/config/latest/developerguide/lambda-function-public-access-prohibited.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ:** なし

このコントロールは、Lambda 関数リソースベースポリシーがアカウントの外部からのパブリックアクセスを禁止しているかどうかをチェックします。パブリックアクセスが許可されている場合、コントロールは失敗します。Lambda 関数が Amazon S3 から呼び出され、ポリシーが `AWS:SourceAccount` などパブリックアクセスを制限する条件が含まれていない場合も、コントロールは失敗します。より細かくアクセスするには、バケットポリシーで他の S3 条件を `AWS:SourceAccount` と併用することをおすすめします。

**注記**  
このコントロールはワイルドカード文字または変数を使用するポリシー条件を評価しません。`PASSED` 検出結果を生成するには、Lambda 関数のポリシーの条件は固定値のみを使用する必要があります。固定値は、ワイルドカード文字やポリシー変数を含まない値です。ポリシー変数に関する詳細については、「*AWS Identity and Access Management ユーザーガイド*」の「[変数およびタグ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html)」を参照してください。

Lambda 関数は、関数コードへの意図しないアクセスを許可する可能性があるため、パブリックからアクセスできない必要があります。

### 修正
<a name="lambda-1-remediation"></a>

この問題を修正するには、関数のリソースベースのポリシーを更新して許可を削除するか、`AWS:SourceAccount` 条件を追加します。リソースベースのポリシーは、Lambda API または からのみ更新できます AWS CLI。

まず、Lambda コンソールで[リソースベースのポリシーを確認](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html)します。`"*"` や `{ "AWS": "*" }` など、ポリシーをパブリックにする `Principal` フィールド値を持つポリシーステートメントを特定します。

ポリシーはコンソールから編集できません。関数から許可を削除するには、 AWS CLIから [https://docs.aws.amazon.com/cli/latest/reference/lambda/remove-permission.html](https://docs.aws.amazon.com/cli/latest/reference/lambda/remove-permission.html) コマンドを作動します。

```
$ aws lambda remove-permission --function-name <function-name> --statement-id <statement-id>
```

`<function-name>` を Lambda 関数の名前で置き換え、`<statement-id>` を削除するステートメントのステートメント ID (`Sid`) に置き換えます。

## [Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります
<a name="lambda-2"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 SI-2、NIST.800-53.r5 SI-2(2)、NIST.800-53.r5 SI-2(4)、NIST.800-53.r5 SI-2(5)、PCI DSS v4.0.1/12.3.4

**カテゴリ:** 保護 > セキュアな開発

**重要度:** 中

**リソースタイプ :** `AWS::Lambda::Function`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/lambda-function-settings-check.html](https://docs.aws.amazon.com/config/latest/developerguide/lambda-function-settings-check.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :** 
+ `runtime`: `dotnet10, dotnet8, java25, java21, java17, java11, java8.al2, nodejs24.x, nodejs22.x, nodejs20.x, python3.14, python3.13, python3.12, python3.11, python3.10, ruby3.4, ruby3.3` (カスタマイズ不可)

このコントロールは、 AWS Lambda 関数のランタイム設定が、各言語でサポートされているランタイムに設定された想定値と一致するかどうかをチェックします。Lambda 関数でサポートされているランタイムが使用されていない場合、パラメータセクションに記載されているように、コントロールは失敗します。Security Hub CSPM は、パッケージタイプが の関数を無視します`Image`。

Lambda ランタイムは、メンテナンスとセキュリティの更新の対象となる OS、プログラミング言語、およびソフトウェアライブラリの組み合わせを中心に構築されています。ランタイムコンポーネントがセキュリティアップデートでサポート対象外となった場合、Lambda はこのランタイムを非推奨にします。非推奨のランタイムを使用する関数を作成することはできませんが、この関数は呼び出しイベントのプロセスに使用できます。Lambda 関数が最新であり、非推奨のランタイム環境の使用は避けることをお勧めします。サポートされているランタイム識別子のリストについては、「*AWS Lambda デベロッパーガイド*」の「[Lambda ランタイム](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html)」を参照してください。

### 修正
<a name="lambda-2-remediation"></a>

サポートされているランタイムおよび非推奨スケジュールの詳細については、「*AWS Lambda デベロッパーガイド*」の「[ランタイムの非推奨化に関するポリシー](https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html)」を参照してください。ランタイムを最新バージョンに移行するときは、言語の発行元からの構文とガイダンスに従ってください。ランタイムバージョンの非互換性というまれな状況で、ワークロードに影響が及ぶリスクを軽減するために、[ランタイム更新](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-update.html#runtime-management-controls)を適用することをお勧めします。

## [Lambda.3] Lambda 関数は VPC 内に存在する必要があります
<a name="lambda-3"></a>

**関連する要件:** PCI DSS v3.2.1/1.2.1、PCI DSS v3.2.1/1.3.1、PCI DSS v3.2.1/1.3.2、PCI DSS v3.2.1/1.3.4、NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 低

**リソースタイプ :** `AWS::Lambda::Function`

**AWS Config ルール: ** [https://docs.aws.amazon.com/config/latest/developerguide/lambda-inside-vpc.html](https://docs.aws.amazon.com/config/latest/developerguide/lambda-inside-vpc.html) 

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Lambda 関数が 仮想プライベートクラウド (VPC) にデプロイされているかどうかをチェックします。Lambda 関数が VPC にデプロイされていない場合、コントロールは失敗します。Security Hub CSPM は、パブリック到達可能性を判断するために VPC サブネットルーティング設定を評価しません。Lambda@Edge リソースに関する失敗の結果が表示される場合があります。

VPC にリソースをデプロイすると、ネットワーク設定のセキュリティとコントロールが強化されます。このようなデプロイでは、複数のアベイラビリティーゾーンにわたってスケーラビリティと高い耐障害性も提供されます。VPC デプロイをカスタマイズして、さまざまなアプリケーション要件を満たすことができます。

### 修正
<a name="lambda-3-remediation"></a>

VPC のプライベートサブネットに接続する既存の機能を設定するには、「*AWS Lambda デベロッパーガイド*」の「[VPC アクセスの設定](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html#vpc-configuring)」を参照してください。可用性を高めるためにプライベートサブネットを少なくとも 2 つ選択し、機能の接続要件を満たすセキュリティグループを少なくとも 1 つ選択することをお勧めします。

## [Lambda.5] VPC Lambda 関数は複数のアベイラビリティーゾーンで運用する必要があります
<a name="lambda-5"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 SC-36、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)

**カテゴリ:** リカバリ > 耐障害性 > 高可用性

**重要度:** 中

**リソースタイプ :** `AWS::Lambda::Function`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/lambda-vpc-multi-az-check.html](https://docs.aws.amazon.com/config/latest/developerguide/lambda-vpc-multi-az-check.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `availabilityZones`  |  アベイラビリティーゾーンの最小数  |  列挙型  |  `2, 3, 4, 5, 6`  |  `2`  | 

このコントロールは、仮想プライベートクラウド (VPC) に接続する AWS Lambda 関数が、少なくとも指定された数のアベイラビリティーゾーン (AZs) で動作するかどうかを確認します。少なくとも指定された数の AZ で関数が動作していない場合、コントロールは失敗します。AZs の最小数にカスタムパラメータ値を指定しない限り、Security Hub CSPM はデフォルト値の 2 つの AZs を使用します。

複数の AZs にリソースをデプロイすることは、アーキテクチャ内で高可用性を確保するための AWS ベストプラクティスです。可用性は、機密性、完全性、可用性から成り立つセキュリティモデルの 3 要素における中心的な柱です。VPC に接続するすべての Lambda 関数には、1 つのゾーンで障害が発生しても運用が完全に中断されないように、マルチ AZ 配置がある必要があります。

### 修正
<a name="lambda-5-remediation"></a>

お客様のアカウントで VPC に接続するように関数を設定する場合は、複数のアベイラビリティーゾーン (AZ) でサブネットを指定することで、高可用性を確保します。手順については、「*AWS Lambda デベロッパーガイド*」の「[VPC アクセスの設定](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html#vpc-configuring)」を参照してください。

Lambda は、複数のアベイラビリティーゾーン (AZ) で他の関数を自動的に実行し、1 つのゾーンでサービスの中断が発生した場合にも、関数をイベントの処理に使用できることを保証します。

## [Lambda.6] Lambda 関数にはタグを付ける必要があります
<a name="lambda-6"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::Lambda::Function`

**AWS Config rule:** `tagged-lambda-function` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、 AWS Lambda 関数にパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。関数にタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、関数にキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くの がアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「*AWS 全般のリファレンス*」の「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。

### 修正
<a name="lambda-6-remediation"></a>

Lambda 関数にタグを追加するには、「*AWS Lambda デベロッパーガイド*」の「[Lambda 関数でのタグの使用](https://docs.aws.amazon.com/lambda/latest/dg/configuration-tags.html)」を参照してください。

## [Lambda.7] Lambda 関数では AWS X-Ray アクティブトレースを有効にする必要があります
<a name="lambda-7"></a>

**関連する要件:** NIST.800-53.r5 CA-7

**カテゴリ:** 識別 > ログ記録

**重要度:** 低

**リソースタイプ :** `AWS::Lambda::Function`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/lambda-function-xray-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/lambda-function-xray-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロール AWS X-Ray は、 関数で を使用したアクティブトレースが有効になっている AWS Lambda かどうかを確認します。Lambda 関数で X-Ray によるアクティブトレースが無効になっている場合、コントロールは失敗します。

AWS X-Ray は AWS Lambda 関数のトレースとモニタリング機能を提供し、Lambda 関数のデバッグと運用にかかる時間と労力を節約できます。Lambda 関数のレイテンシーを分類することで、エラーを診断し、パフォーマンスのボトルネック、速度低下、タイムアウトを特定するのに役立ちます。また、データのプライバシーとコンプライアンスの要件にも役立ちます。Lambda 関数のアクティブトレースを有効にすると、X-Ray が Lambda 関数内のデータフローと処理の全体像を提供するため、潜在的なセキュリティ脆弱性や非準拠のデータ処理プラクティスを特定するのに役立ちます。この可視性は、データ整合性、機密性、関連する規制へのコンプライアンスを維持するのに役立ちます。

**注記**  
AWS X-Ray 現在、トレースは、Amazon Managed Streaming for Apache Kafka (Amazon MSK)、セルフマネージド Apache Kafka、ActiveMQ および RabbitMQ を使用した Amazon MQ、または Amazon DocumentDB イベントソースマッピングを使用する Lambda 関数ではサポートされていません。

### 修正
<a name="lambda-7-remediation"></a>

 AWS Lambda 関数のアクティブトレースを有効にする方法については、 *AWS Lambda デベロッパーガイド*の「 [を使用して Lambda 関数の呼び出しを視覚化する AWS X-Ray](https://docs.aws.amazon.com/lambda/latest/dg/services-xray.html)」を参照してください。

# Macie の Security Hub CSPM コントロール
<a name="macie-controls"></a>

これらの AWS Security Hub CSPM コントロールは Amazon Macie サービスを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [Macie.1] Amazon Macie を有効にする必要があります
<a name="macie-1"></a>

**関連する要件:** NIST.800-53.r5 CA-7、NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 RA-5、NIST.800-53.r5 SA-8(19)、NIST.800-53.r5 SI-4

**カテゴリ:** 検出 > 検出サービス

**重要度:** 中

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/macie-status-check.html](https://docs.aws.amazon.com/config/latest/developerguide/macie-status-check.html)

**スケジュールタイプ:** 定期的

このコントロールは、アカウントで Amazon Macie が有効になっているかどうかをチェックします。アカウントに対して Macie が有効になっていない場合、コントロールは失敗します。

Amazon Macie は、機械学習とパターンマッチングを使用して機密データを検出し、データセキュリティリスクを可視化し、それらのリスクに対する自動保護を可能にします。Macie は、Amazon Simple Storage Service (Amazon S3) バケットのセキュリティとアクセスコントロールを自動的かつ継続的に評価し、検出結果を生成して、Amazon S3 データのセキュリティまたはプライバシーに関する潜在的な問題について通知します。また、Macie は、Amazon S3 に保存している個人を特定できる情報 (PII) などの機密データを詳細に把握できるよう、そのようなデータの検出とレポートを自動化します。詳細については、「[https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html](https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html)」を参照してください。

### 修正
<a name="macie-1-remediation"></a>

Macie を有効にするには、「*Amazon Macie ユーザーガイド*」の「[Macie を有効化する](https://docs.aws.amazon.com/macie/latest/user/getting-started.html#enable-macie)」を参照してください。

## [Macie.2] Macie 機密データ自動検出を有効にする必要があります
<a name="macie-2"></a>

**関連する要件:** NIST.800-53.r5 CA-7、NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 RA-5、NIST.800-53.r5 SA-8(19)、NIST.800-53.r5 SI-4

**カテゴリ:** 検出 > 検出サービス

**重要度:** 高

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/macie-auto-sensitive-data-discovery-check.html](https://docs.aws.amazon.com/config/latest/developerguide/macie-auto-sensitive-data-discovery-check.html)

**スケジュールタイプ:** 定期的

このコントロールは、Amazon Macie 管理者アカウントに対して機密データ自動検出が有効になっているかどうかを確認します。Macie 管理者アカウントに対して機密データ自動検出が有効になっていない場合、コントロールは失敗します。このコントロールは管理者アカウントにのみ適用されます。

Macie は、Amazon Simple Storage Service (Amazon S3) バケット内の個人を特定できる情報 (PII) などの機密データの検出と報告を自動化します。機密データ自動検出により、Macie はバケットインベントリを継続的に評価し、サンプリング技術を使用してバケットから代表的な S3 オブジェクトを識別して選択します。その後、Macie は選択したオブジェクトを分析し、機密データがないか検査します。分析が進むにつれて、Macie は S3 データについて提供する統計、インベントリデータ、およびその他の情報を更新します。Macie は検出結果を生成して、検出した機密データを報告します。

### 修正
<a name="macie-2-remediation"></a>

S3 バケット内のオブジェクトを分析するための自動機密データ検出ジョブを作成して設定するには、「*Amazon Macie ユーザーガイド*」の「[アカウントの自動機密データ検出の設定](https://docs.aws.amazon.com/macie/latest/user/discovery-asdd-account-manage.html)」を参照してください。

# Amazon MSK の Security Hub CSPM コントロール
<a name="msk-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon Managed Streaming for Apache Kafka (Amazon MSK) サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [MSK.1] MSK クラスターはブローカーノード間の転送時に暗号化される必要があります
<a name="msk-1"></a>

**関連する要件:** NIST.800-53.r5 AC-4、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-23、NIST.800-53.r5 SC-23(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-8、NIST.800-53.r5 SC-8(1)、NIST.800-53.r5 SC-8(2)、PCI DSS v4.0.1/4.2.1

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::MSK::Cluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/msk-in-cluster-node-require-tls.html](https://docs.aws.amazon.com/config/latest/developerguide/msk-in-cluster-node-require-tls.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは Amazon MSK クラスターが、クラスターのブローカーノードで HTTPS (TLS) で転送中のデータを暗号化しているかどうかを確認します。クラスターブローカーノード接続でプレーンテキスト通信が有効になっていると、コントロールは失敗します。

HTTPS ではデータの移動に TLS を使用する追加のセキュリティレイヤーが提供されており、これをすると、潜在的な攻撃者が中間者攻撃または同様の攻撃を使用してネットワークトラフィックを盗聴または操作することを防止できます。デフォルトでは、Amazon MSK は転送中のデータを TLS で暗号化します。ただし、このデフォルトはクラスターの作成時に上書きできます。ブローカーノード接続には、HTTPS (TLS) 経由の暗号化接続を使用することをお勧めします。

### 修正
<a name="msk-1-remediation"></a>

Amazon MSK クラスターの暗号化設定を更新する方法については、「*Amazon Managed Streaming for Apache Kafka デベロッパーガイド*」の「[Updating security settings of a cluster](https://docs.aws.amazon.com/msk/latest/developerguide/msk-update-security.html)」を参照してください。

## [MSK.2] MSK クラスターでは、拡張モニタリングを設定する必要があります
<a name="msk-2"></a>

**関連する要件:** NIST.800-53.r5 CA-7、NIST.800-53.r5 SI-2

**カテゴリ:** 検出 > 検出サービス

**重要度:** 低

**リソースタイプ :** `AWS::MSK::Cluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/msk-enhanced-monitoring-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/msk-enhanced-monitoring-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon MSK クラスターに、少なくとも `PER_TOPIC_PER_BROKER` のモニタリングレベルで指定された拡張モニタリングが設定されているかどうかをチェックします。クラスターのモニタリングレベルが `DEFAULT` または `PER_BROKER` に設定されている場合、コントロールは失敗します。

`PER_TOPIC_PER_BROKER` モニタリングレベルでは、MSK クラスターのパフォーマンスをより詳細に把握できる他、CPU やメモリ使用量などのリソース使用率に関連するメトリクスも表示されます。これにより、個々のトピックおよびブローカーのパフォーマンスボトルネックやリソース使用パターンを特定できるようになります。この可視性により、Kafka ブローカーのパフォーマンスを最適化できます。

### 修正
<a name="msk-2-remediation"></a>

MSK クラスターの拡張モニタリングを設定するには、以下の手順を実行します。

1. [https://console.aws.amazon.com/msk/home?region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/) で Amazon MSK コンソールを開きます。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。次に、クラスターを選択します。

1. **[アクション]** で **[モニタリングを編集]** を選択します。

1. **[拡張トピックレベルモニタリング]** のオプションを選択します。

1. **[Save changes]** (変更の保存) をクリックします。

モニタリングレベルの詳細については、「*Amazon Managed Streaming for Apache Kafka デベロッパーガイド*」の「[Amazon MSK metrics for monitoring Standard brokers with CloudWatch](https://docs.aws.amazon.com/msk/latest/developerguide/metrics-details.html)」を参照してください。

## [MSK.3] MSK Connect コネクタは転送中に暗号化する必要があります
<a name="msk-3"></a>

**関連する要件:** PCI DSS v4.0.1/4.2.1

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::KafkaConnect::Connector`

**AWS Config rule:** `msk-connect-connector-encrypted` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon MSK Connect コネクタが転送中の暗号化されているかどうかを確認します。コネクタが転送中に暗号化されていない場合、このコントロールは失敗します。

転送中のデータとは、クラスター内のノード間やクラスターとアプリケーション間など、ある場所から別の場所に移動するデータを指します。データはインターネット内またはプライベートネットワーク内を移動する場合があります。転送中のデータを暗号化することで、権限のないユーザーがネットワークトラフィックを盗聴するリスクが軽減されます。

### 修正
<a name="msk-3-remediation"></a>

MSK Connect コネクタを作成するときに、転送中の暗号化を有効にすることができます。コネクタを作成した後で暗号化設定を変更することはできません。詳細については、「*Amazon Managed Streaming for Apache Kafka デベロッパーガイド*」の「[コネクタの作成](https://docs.aws.amazon.com/msk/latest/developerguide/mkc-create-connector-intro.html)」を参照してください。

## [MSK.4] MSK クラスターではパブリックアクセスを無効にする必要があります
<a name="msk-4"></a>

**カテゴリ:** 保護 > セキュアなアクセス管理 > パブリックアクセスが不可能なリソース

**重要度:** 非常事態

**リソースタイプ :** `AWS::MSK::Cluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/msk-cluster-public-access-disabled.html](https://docs.aws.amazon.com/config/latest/developerguide/msk-cluster-public-access-disabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon MSK クラスターでパブリックアクセスが無効になっているかどうかをチェックします。MSK クラスターでパブリックアクセスが有効になっている場合、コントロールは失敗します。

デフォルトでは、クライアントは、クラスターと同じ VPC 内にある場合にのみ Amazon MSK クラスターにアクセスできます。Kafka クライアントと MSK クラスター間のすべての通信はデフォルトでプライベートであり、ストリーミングデータがインターネットを経由することはありません。ただし、MSK クラスターがパブリックアクセスを許可するように設定されている場合、インターネット上の誰でも、クラスター内で実行されている Apache Kafka ブローカーへの接続を確立できます。そのため、不正アクセス、データ侵害、または脆弱性の悪用などの問題につながる可能性があります。認証と認可の手段を要求してクラスターへのアクセスを制限すると、機密情報を保護し、リソースの整合性を維持できます。

### 修正
<a name="msk-4-remediation"></a>

Amazon MSK クラスターへのパブリックアクセスの管理については、「*Amazon Managed Streaming for Apache Kafka デベロッパーガイド*」の「[Turn on public access to an MSK Provisioned cluster](https://docs.aws.amazon.com/msk/latest/developerguide/public-access.html)」を参照してください。

## [MSK.5] MSK コネクタではログ記録が有効になっている必要があります
<a name="msk-5"></a>

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::KafkaConnect::Connector`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/msk-connect-connector-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/msk-connect-connector-logging-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon MSK コネクタでログ記録が有効になっているかどうかをチェックします。MSK コネクタでログ記録が無効になっていると、コントロールは失敗します。

Amazon MSK コネクタは、ストリーミングデータをデータソースから Apache Kafka クラスターに継続的にコピーするか、クラスターからデータシンクにデータを継続的にコピーすることにより、外部システムと Amazon サービスを Apache Kafka と統合します。MSK Connect は、コネクタのデバッグに役立つログイベントを書き込むことができます。コネクタを作成するときに、ログの送信先を、Amazon CloudWatch Logs、Amazon S3、Amazon Data Firehose の中から 0 個以上指定できます。

**注記**  
プラグインで機密設定値をシークレットとして定義していない場合、機密設定値がコネクタログに表示される可能性があります。Kafka Connect は、未定義の設定値を他のプレーンテキスト値と同じように扱います。

### 修正
<a name="msk-5-remediation"></a>

既存の Amazon MSK コネクタのログ記録を有効にするには、適切なログ記録設定を指定してコネクタを再作成する必要があります。詳細については、「*Amazon Managed Streaming for Apache Kafka デベロッパーガイド*」の「[Logging for MSK Connect](https://docs.aws.amazon.com/msk/latest/developerguide/msk-connect-logging.html)」を参照してください。

## [MSK.6] MSK クラスターは認証されていないアクセスを無効にする必要があります
<a name="msk-6"></a>

**カテゴリ:** 保護 > セキュアなアクセス管理 > パスワードレス認証

**重要度:** 中

**リソースタイプ :** `AWS::MSK::Cluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/msk-unrestricted-access-check.html](https://docs.aws.amazon.com/config/latest/developerguide/msk-unrestricted-access-check.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon MSK クラスターで非認証アクセスが有効になっているかどうかをチェックします。MSK クラスターで非認証アクセスが有効になっている場合、コントロールは失敗します。

Amazon MSK は、クラスターへのアクセスを制御するクライアント認証および認可メカニズムをサポートしています。これらのメカニズムは、クラスターに接続するクライアントの ID を検証し、クライアントが実行できるアクションを特定します。MSK クラスターは、非認証アクセスを許可するように設定できます。これにより、ネットワーク接続を持つすべてのクライアントは、認証情報を指定せずに Kafka トピックを発行およびサブスクライブできます。認証を必要とせずに MSK クラスターを実行すると、最小特権の原則に違反し、クラスターが不正アクセスにさらされる可能性があります。それによって、すべてのクライアントが Kafka トピックのデータにアクセスして、変更、削除できるため、データ侵害、不正なデータ変更、またはサービスの中断につながる可能性があります。適切なアクセスコントロールを確保し、セキュリティコンプライアンスを維持するために、IAM 認証、SASL/SCRAM、相互 TLS などの認証メカニズムを有効にすることをお勧めします。

### 修正
<a name="msk-6-remediation"></a>

Amazon MSK クラスターの認証設定を変更する方法については、「*Amazon Managed Streaming for Apache Kafka デベロッパーガイド*」の「[Update security settings of an Amazon MSK cluster](https://docs.aws.amazon.com/msk/latest/developerguide/msk-update-security.html)」と「[Authentication and authorization for Apache Kafka APIs](https://docs.aws.amazon.com/msk/latest/developerguide/kafka_apis_iam.html)」のセクションを参照してください。

# Amazon MQ の Security Hub CSPM コントロール
<a name="mq-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon MQ サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [MQ.2] ActiveMQ ブローカーは監査ログを CloudWatch にストリーミングする必要があります
<a name="mq-2"></a>

**関連する要件:** NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-12、NIST.800-53.r5 SI-4、PCI DSS v4.0.1/10.3.3

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::AmazonMQ::Broker`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/mq-cloudwatch-audit-log-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/mq-cloudwatch-audit-log-enabled.html) 

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon MQ ActiveMQ ブローカーが監査ログを Amazon CloudWatch Logs にストリーミングするかどうかをチェックします。ブローカーが監査ログを CloudWatch Logs にストリーミングしていない場合、コントロールは失敗します。

ActiveMQ ブローカーログを CloudWatch Logs に発行することで、セキュリティ関連情報の可視性を高める CloudWatch アラームとメトリクスを作成できます。

### 修正
<a name="mq-2-remediation"></a>

ActiveMQ ブローカーログを CloudWatch Logs にストリーミングするには、「*Amazon MQ デベロッパーガイド*」の「[Amazon MQ for ActiveMQ ログの設定](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/configure-logging-monitoring-activemq.html)」を参照してください。

## [MQ.3] Amazon MQ ブローカーでは、自動マイナーバージョンアップグレードが有効になっている必要があります
<a name="mq-3"></a>

**重要**  
Security Hub CSPM は、2026 年 1 月にこのコントロールを廃止しました。詳細については、「[Security Hub CSPM コントロールの変更ログ](controls-change-log.md)」を参照してください。

**関連する要件:** NIST.800-53.r5 CM-3、NIST.800-53.r5 SI-2、PCI DSS v4.0.1/6.3.3

**カテゴリ:** 特定 > 脆弱性、パッチ、バージョン管理

**重要度:** 中

**リソースタイプ :** `AWS::AmazonMQ::Broker`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/mq-auto-minor-version-upgrade-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/mq-auto-minor-version-upgrade-enabled.html) 

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon MQ ブローカーの自動マイナーバージョンアップグレードが有効になっているかどうかを確認します。ブローカーの自動マイナーバージョンアップグレードが有効になっていない場合、コントロールは失敗します。

Amazon MQ が新しいブローカーエンジンバージョンをリリースしてサポートしているため、変更は既存のアプリケーションと下位互換性があり、既存の機能を非推奨にすることはありません。自動ブローカーエンジンバージョン更新は、セキュリティリスクから保護し、バグを修正し、機能を改善します。

**注記**  
自動マイナーバージョンアップグレードに関連付けられたブローカーが最新のパッチにあり、サポートされない場合は、アップグレードのために手動アクションを実行する必要があります。

### 修正
<a name="mq-3-remediation"></a>

MQ ブローカーの自動マイナーバージョンアップグレードを有効にするには、「*Amazon MQ デベロッパーガイド*」の「[マイナーエンジンバージョンの自動アップグレード](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/upgrading-brokers.html#upgrading-brokers-automatic-upgrades.html)」を参照してください。

## [MQ.4] Amazon MQ ブローカーにはタグを付ける必要があります
<a name="mq-4"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::AmazonMQ::Broker`

**AWS Config rule:** `tagged-amazonmq-broker` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、Amazon MQ ブローカーにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。ブローカーにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ブローカーがキーでタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="mq-4-remediation"></a>

Amazon MQ ブローカーにタグを追加するには、「*Amazon MQ デベロッパーガイド*」の「[リソースのタグ付け](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/amazon-mq-tagging.html)」を参照してください。

## [MQ.5] ActiveMQ ブローカーはアクティブ/スタンバイデプロイメントモードを使用する必要があります
<a name="mq-5"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 SC-36、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)

**カテゴリ:** リカバリ > 耐障害性 > 高可用性

**重要度:** 低

**リソースタイプ :** `AWS::AmazonMQ::Broker`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/mq-active-deployment-mode.html](https://docs.aws.amazon.com/config/latest/developerguide/mq-active-deployment-mode.html) 

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon MQ ActiveMQ ブローカーのデプロイモードがアクティブ/スタンバイに設定されているかどうかを確認します。単一インスタンスブローカー (デフォルトで有効) がデプロイモードに設定されている場合、コントロールは失敗します。

アクティブ/スタンバイデプロイにより、 AWS リージョン内の Amazon MQ ActiveMQ ブローカーの可用性が高くなります。アクティブ/スタンバイのデプロイモードには、2 つの異なるアベイラビリティーゾーンの 2 つのブローカーインスタンスが冗長ペアとして設定されています。これらのブローカーはアプリケーションと同期して通信するため、障害発生時のダウンタイムやデータ損失を減らすことができます。

### 修正
<a name="mq-5-remediation"></a>

アクティブ/スタンバイデプロイモードで新しい ActiveMQ ブローカーを作成するには、「**Amazon MQ デベロッパーガイド」の「[ActiveMQ ブローカーの作成と設定](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/amazon-mq-creating-configuring-broker.html)」を参照してください。**[デプロイモード]** で、**[アクティブ/スタンバイブローカー]** を選択します。既存のブローカーのデプロイモードは変更できません。代わりに、新しいブローカーを作成し、古いブローカーから設定をコピーする必要があります。

## [MQ.6] RabbitMQ ブローカーはクラスターデプロイメントモードを使用する必要があります。
<a name="mq-6"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 SC-36、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5

**カテゴリ:** リカバリ > 耐障害性 > 高可用性

**重要度:** 低

**リソースタイプ :** `AWS::AmazonMQ::Broker`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/mq-rabbit-deployment-mode.html](https://docs.aws.amazon.com/config/latest/developerguide/mq-rabbit-deployment-mode.html) 

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon MQ RabbitMQ ブローカーのデプロイモードがクラスターデプロイに設定されているかどうかを確認します。単一インスタンスブローカー (デフォルトで有効) がデプロイモードに設定されている場合、コントロールは失敗します。

クラスターデプロイにより、 AWS リージョン内の Amazon MQ RabbitMQ ブローカーの可用性が高くなります。クラスターデプロイは、3 つの RabbitMQ ブローカーノードを論理的にグループ化したもので、それぞれに独自の Amazon Elastic Block Store (Amazon EBS) ボリュームと 1 つの共有状態があります。クラスターデプロイは、データがクラスター内の全ノードに確実に複製され、障害発生時のダウンタイムとデータ損失が減少するようにします。

### 修正
<a name="mq-6-remediation"></a>

クラスターデプロイモードで新しい RabbitMQ ブローカーを作成するには、「**Amazon MQ デベロッパーガイド」の「[RabbitMQ ブローカーの作成と接続](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/getting-started-rabbitmq.html)」を参照してください。**[デプロイモード]** で、**[クラスターデプロイ]** を選択します。既存のブローカーのデプロイモードは変更できません。代わりに、新しいブローカーを作成し、古いブローカーから設定をコピーする必要があります。

# Neptune の Security Hub CSPM コントロール
<a name="neptune-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon Neptune サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [Neptune.1] Neptune DB クラスターは、保管中に暗号化する必要があります
<a name="neptune-1"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SI-7(6)

**カテゴリ:** 保護 > データ保護 > 保管中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-encrypted.html) 

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Neptune DB クラスターが保管中に暗号化されているかどうかをチェックします。Neptune DB クラスターが保管中に暗号化されていない場合、コントロールは失敗します。

保管中のデータとは、永続的な不揮発性ストレージに任意の期間保管されているデータを指します。暗号化は、このようなデータの機密性を保護し、権限のないユーザーがデータにアクセスするリスクを低減するのに役立ちます。Neptune DB クラスターを暗号化することで、データとメタデータを不正アクセスから保護します。また、本番稼働用ファイルシステムにおける保管中のデータの暗号化に関するコンプライアンス要件も満たします。

### 修正
<a name="neptune-1-remediation"></a>

Neptune DB クラスターを作成するときに、保管中の暗号化を有効にできます。クラスターを作成した後で暗号化設定を変更することはできません。詳細については、「*Neptune ユーザーガイド*」の「[Encrypting Neptune resources at rest](https://docs.aws.amazon.com/neptune/latest/userguide/encrypt.html)」を参照してください。

## [Neptune.2] Neptune DB クラスターでは、監査ログを CloudWatch Logs に発行する必要があります
<a name="neptune-2"></a>

**関連する要件:** NIST.800-53.r5 AC-2(4)、NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AC-6(9)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(1)、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 AU-6(5)、NIST.800-53.r5 AU-7(1)、NIST.800-53.r5 AU-9(7)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-20、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4(20)、NIST.800-53.r5 SI-4(5)、NIST.800-53.r5 SI-7(8)、PCI DSS v4.0.1/10.3.3

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-cloudwatch-log-export-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-cloudwatch-log-export-enabled.html) 

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Neptune DB クラスターが監査ログを Amazon CloudWatch Logs に発行しているかどうかをチェックします。Neptune DB クラスターが監査ログを CloudWatch Logs に発行しない場合、コントロールは失敗します。`EnableCloudWatchLogsExport` は `Audit` に設定する必要があります。

Amazon Neptune と Amazon CloudWatch が統合され、パフォーマンスメトリクスを収集して分析できるようになりました。Neptune はメトリクスを自動的に CloudWatch に送信し、CloudWatch アラームもサポートしています。監査ログは高度なカスタマイズが可能です。データベースを監査すると、データに対する各操作をモニタリングし、どのデータベースクラスターがどのようにアクセスされたかに関する情報などを監査証跡に記録できます。Neptune DB クラスターのモニタリングに役立てるため、これらのログを CloudWatch に送信することをお勧めします。

### 修正
<a name="neptune-2-remediation"></a>

Neptune の監査ログを CloudWatch Logs に発行するには、「*Neptune ユーザーガイド*」の「[Amazon CloudWatch Logs への Neptune ログの発行](https://docs.aws.amazon.com/neptune/latest/userguide/cloudwatch-logs.html)」を参照してください。**[Log exports]** セクションで、**[Audit]** を選択します。

## [Neptune.3] Neptune DB クラスタースナップショットはパブリックにしないでください
<a name="neptune-3"></a>

**関連する要件:** NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)、PCI DSS v4.0.1/1.4.4

**カテゴリ:** 保護 > セキュアなネットワーク設定 > パブリックアクセス不可のリソース

**重要度:** 非常事態

**リソースタイプ :** `AWS::RDS::DBClusterSnapshot`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-snapshot-public-prohibited.html](https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-snapshot-public-prohibited.html) 

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Neptune の手動 DB クラスタースナップショットがパブリックかどうかをチェックします。Neptune の手動 DB クラスタースナップショットがパブリックの場合、コントロールは失敗します。

Neptune DB クラスターの手動スナップショットは、意図しない限りパブリックにしないでください。暗号化されていない手動スナップショットをパブリックとして共有すると、すべての AWS アカウントでこのスナップショットを使用できるようになります。パブリックスナップショットは、意図しないデータ漏えいにつながる可能性があります。

### 修正
<a name="neptune-3-remediation"></a>

Neptune の手動 DB クラスタースナップショットからパブリックアクセスを削除するには、「*Neptune ユーザーガイド*」の「[DB クラスターのスナップショットの共有](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-share-snapshot.html)」を参照してください。

## [Neptune.4] Neptune DB クラスターでは、削除保護が有効になっている必要があります
<a name="neptune-4"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)、NIST.800-53.r5 CM-3、NIST.800-53.r5 SC-5(2)

**カテゴリ:** 保護 > データ保護 > データ削除保護

**重要度:** 低

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-deletion-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-deletion-protection-enabled.html) 

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Neptune DB クラスターの削除保護が有効になっているかどうかをチェックします。Neptune DB クラスターで削除保護が有効になっていない場合、コントロールは失敗します。

クラスターの削除保護を有効にすることで、偶発的なデータベース削除や権限のないユーザーによる削除に対して保護の強化を提供します。削除保護が有効の間、Neptune DB クラスターは削除できません。削除リクエストを成功させるには、まず削除保護を無効にする必要があります。

### 修正
<a name="neptune-4-remediation"></a>

既存の Neptune DB クラスターの削除保護を有効にするには、「*Amazon Aurora ユーザーガイド*」の「[コンソール、CLI、API を使用した DB クラスターの変更](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Modifying.html#Aurora.Modifying.Settings)」を参照してください。

## [Neptune.5] Neptune DB クラスターでは、自動バックアップが有効になっている必要があります
<a name="neptune-5"></a>

**関連する要件:** NIST.800-53.r5 SI-12

**カテゴリ:** リカバリ > 耐障害性 > バックアップの有効化

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-backup-retention-check.html](https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-backup-retention-check.html) 

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `minimumBackupRetentionPeriod`  |  最小バックアップ保持期間 (日数)  |  整数  |  `7`～`35`  |  `7`  | 

このコントロールは、Neptune DB クラスターで自動バックアップが有効になっているかどうか、およびバックアップ保持期間が指定された時間枠以上であるかどうかをチェックします。Neptune DB クラスターのバックアップが有効になっていない場合や、保持期間が指定された時間枠未満の場合、コントロールは失敗します。バックアップ保持期間にカスタムパラメータ値を指定しない限り、Security Hub CSPM はデフォルト値の 7 日を使用します。

バックアップは、セキュリティインシデントからの迅速な復元と、システムの耐障害性の強化に役立ちます。Neptune DB クラスターのバックアップを自動化すると、システムを特定の時点に復元し、ダウンタイムとデータ損失を最小限に抑えることができます。

### 修正
<a name="neptune-5-remediation"></a>

Neptune DB クラスターの自動バックアップを有効にしてバックアップ保持期間を設定するには、「*Amazon RDS ユーザーガイド*」の「[自動バックアップの有効化](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html#USER_WorkingWithAutomatedBackups.Enabling)」を参照してください。**[バックアップ保持期間]** で 7 以上の値を選択します。

## [Neptune.6] Neptune DB クラスタースナップショットは、保管中に暗号化する必要があります
<a name="neptune-6"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SC-7(18)

**カテゴリ:** 保護 > データ保護 > 保管中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBClusterSnapshot`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-snapshot-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-snapshot-encrypted.html) 

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Neptune DB クラスタースナップショットが保管中に暗号化されているかどうかをチェックします。Neptune DB クラスターが保管中に暗号化されていない場合、コントロールは失敗します。

保管中のデータとは、永続的な不揮発性ストレージに任意の期間保管されているデータを指します。暗号化は、このようなデータの機密性を保護し、権限のないユーザーがデータにアクセスするリスクを低減するのに役立ちます。Neptune DB クラスタースナップショット内のデータは、セキュリティを強化するために、保管中に暗号化する必要があります。

### 修正
<a name="neptune-6-remediation"></a>

既存の Neptune DB クラスタースナップショットは暗号化できません。代わりに、スナップショットを新しい DB クラスターに復元し、このクラスターで暗号化を有効にする必要があります。これで、暗号化されたクラスターから、暗号化されたスナップショットを作成できます。手順については、「*Neptune ユーザーガイド*」の「[DB クラスターのスナップショットからの復元](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-restore-snapshot.html)」と「[Neptune での DB クラスタースナップショットの作成](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-create-snapshot.html)」を参照してください。

## [Neptune.7] Neptune DB クラスターでは、IAM データベース認証が有効になっている必要があります
<a name="neptune-7"></a>

**関連する要件:** NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-6

**カテゴリ:** 保護 > セキュアなアクセス管理 > パスワードレス認証

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-iam-database-authentication.html](https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-iam-database-authentication.html) 

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Neptune DB クラスターで IAM データベース認証が有効になっているかどうかをチェックします。Neptune DB クラスターで IAM データベース認証が有効になっていない場合、コントロールは失敗します。

Amazon Neptune データベースクラスターの IAM データベース認証では、認証は IAM を使用して外部で管理されるため、ユーザー認証情報をデータベース設定内に保存する必要がなくなります。IAM データベース認証が有効になっている場合は、 AWS 署名バージョン 4 を使用して各リクエストに署名する必要があります。

### 修正
<a name="neptune-7-remediation"></a>

デフォルトでは、Neptune DB クラスターの作成時、IAM データベース認証は無効になっています。有効にするには、「*Neptune ユーザーガイド*」の「[Neptune で IAM データベース認証を有効にする](https://docs.aws.amazon.com/neptune/latest/userguide/iam-auth-enable.html)」を参照してください。

## [Neptune.8] Neptune DB クラスターでは、タグをスナップショットにコピーするように設定する必要があります
<a name="neptune-8"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-copy-tags-to-snapshot-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-copy-tags-to-snapshot-enabled.html) 

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、スナップショットの作成時に、すべてのタグをスナップショットにコピーするように Neptune DB クラスターが設定されているかどうかをチェックします。Neptune DB クラスターがタグをスナップショットにコピーするように設定されていない場合、コントロールは失敗します。

IT アセットの身分証明書とインベントリはガバナンスとセキュリティの重要な側面です。スナップショットは、親 Amazon RDS データベースクラスターと同じ方法でタグ付けする必要があります。タグをコピーすると、DB スナップショットと親データベースクラスターのメタデータが確実に一致し、また、DB スナップショットと親 DB インスタンスのアクセスポリシーが確実に一致するようになります。

### 修正
<a name="neptune-8-remediation"></a>

Neptune DB クラスターのスナップショットにタグをコピーするには、「*Neptune ユーザーガイド*」の「[Neptune でタグをコピーする](https://docs.aws.amazon.com/neptune/latest/userguide/tagging.html#tagging-overview)」を参照してください。

## [Neptune.9] Neptune DB クラスターを複数のアベイラビリティーゾーンにデプロイする必要があります
<a name="neptune-9"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 SC-36、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)

**カテゴリ:** リカバリ > 耐障害性 > 高可用性

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-multi-az-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-multi-az-enabled.html) 

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon Neptune DB クラスターで、複数のアベイラビリティーゾーン (AZ) にリードレプリカインスタンスがあるかどうかをチェックします。クラスターが 1 つの AZ にのみデプロイされている場合、コントロールは失敗します。

AZ が使用できなくなった場合や、定期的なメンテナンスイベントでは、リードレプリカがプライマリインスタンスのフェイルオーバーターゲットとして機能します。つまり、プライマリインスタンスが失敗した場合、Neptune はリードレプリカをプライマリインスタンスに昇格します。対照的に、DB クラスターにリードレプリカインスタンスが含まれていない場合、プライマリインスタンスが再作成されるまで障害が発生しても、DB クラスターは使用できないままになります。プライマリインスタンスの再作成は、リードレプリカの昇格よりもかなり時間がかかります。高可用性を確保するために、プライマリインスタンスと同じ DB インスタンスクラスを持ち、プライマリインスタンスとは異なる AZ に配置する 1 つ以上のリードレプリカインスタンスを作成することをお勧めします。

### 修正
<a name="neptune-9-remediation"></a>

Neptune DB クラスターを複数の AZ にデプロイするには、「*Neptune ユーザーガイド*」の「[Neptune DB クラスター内のリードレプリカ DB インスタンス](https://docs.aws.amazon.com/neptune/latest/userguide/feature-overview-db-clusters.html#feature-overview-read-replicas)」を参照してください。

# の Security Hub CSPM コントロール AWS Network Firewall
<a name="networkfirewall-controls"></a>

これらの AWS Security Hub CSPM コントロールは、 AWS Network Firewall サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [NetworkFirewall.1] Network Firewall ファイアウォールを複数のアベイラビリティーゾーンにデプロイする必要があります
<a name="networkfirewall-1"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 SC-36、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)

**カテゴリ:** リカバリ > 耐障害性 > 高可用性

**重要度:** 中

**リソースタイプ :** `AWS::NetworkFirewall::Firewall`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/netfw-multi-az-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/netfw-multi-az-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、 で管理されるファイアウォール AWS Network Firewall が複数のアベイラビリティーゾーン (AZs) にデプロイされているかどうかを評価します。ファイアウォールが 1 つの AZ にのみデプロイされている場合、コントロールは失敗します。

AWS グローバルインフラストラクチャには複数の が含まれています AWS リージョン。AZ は、低レイテンシー、高スループット、高冗長性のネットワークで接続されている、各リージョン内の物理的に独立し隔離されたロケーションです。Network Firewall ファイアウォールを複数の AZ にデプロイすることで、AZ 間でトラフィックを分散およびシフトできるため、可用性の高いソリューションを設計できるようになります。

### 修正
<a name="networkfirewall-1-remediation"></a>

**Network Firewall ファイアウォールを複数の AZ にデプロイする**

1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。

1. ナビゲーションペインで、**[ネットワークファイアウォール]** の下にある **[ファイアウォール]** を選択します。

1. **[ファイアウォール]** ページで、編集するファイアウォールを選択します。

1. ファイアウォールの詳細ページで、**[ファイアウォールの詳細]** タブを選択します。

1. **[関連付けられたポリシーと VPC]** セクションで、**[編集]** を選択します。

1. 新しい AZ を追加するには、**[新しいサブネットを追加]** を選択します。使用する AZ とサブネットを選択します。少なくとも 2 つの AZ を選択するようにします。

1. **[保存]** を選択します。

## [NetworkFirewall.2] Network Firewall ログ記録を有効にする必要があります
<a name="networkfirewall-2"></a>

**関連する要件:** NIST.800-53.r5 AC-2(12)、NIST.800-53.r5 AC-2(4)、NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AC-6(9)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 AU-9(7)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4、NIST.800-53.r5 SI-4(20)、NIST.800-53.r5 SI-7(8)、NIST.800-171.r2 3.1.20、NIST.800-171.r2 3.13.1

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::NetworkFirewall::LoggingConfiguration`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/netfw-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/netfw-logging-enabled.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、 AWS Network Firewall ファイアウォールでログ記録が有効になっているかどうかをチェックします。少なくとも 1 つのログタイプでログ記録が有効になっていない場合、またはログ記録先が存在しない場合、コントロールは失敗します。

ログ記録はファイアウォールの信頼性、可用性、パフォーマンスの維持に有益です。Network Firewall でログを記録すると、ステートフルエンジンがパケットフローを受信した時間、パケットフローに関する詳細情報、パケットフローに対して実行されたステートフルルールアクションなど、ネットワークトラフィックに関する詳細情報が得られます。

### 修正
<a name="networkfirewall-2-remediation"></a>

ファイアウォールのログ記録を有効にするには、「*AWS Network Firewall デベロッパーガイド*」の「[Updating a firewall's logging configuration](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-update-logging-configuration.html)」を参照してください。

## [Network Firewall.3] Network Firewall ポリシーには、1 つ以上のルールグループが関連付けられている必要があります
<a name="networkfirewall-3"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-171.r2 3.1.3、NIST.800-171.r2 3.13.1

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 中

**リソースタイプ :** `AWS::NetworkFirewall::FirewallPolicy`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/netfw-policy-rule-group-associated.html](https://docs.aws.amazon.com/config/latest/developerguide/netfw-policy-rule-group-associated.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Network Firewall ポリシーに、ステートフルなルールグループかステートレスなルールグループのいずれかが関連付けられているかどうかをチェックします。ステートレスまたはステートフルなルールグループが割り当てられていない場合、このコントロールは失敗します。

ファイアウォールポリシーは、ファイアウォールが Amazon Virtual Private Cloud (Amazon VPC) のトラフィックをモニタリングおよび処理する方法を定義します。ステートレスおよびステートフルのルールグループの設定は、パケットとトラフィックフローのフィルタリングに役立ち、デフォルトのトラフィック処理を定義します。

### 修正
<a name="networkfirewall-3-remediation"></a>

Network Firewall ポリシーにルールグループを追加する方法については、「*AWS Network Firewall デベロッパーガイド*」の「[Updating a firewall policy](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-policy-updating.html)」を参照してください。ルールグループの作成および管理方法については、「[AWS Network Firewallのルールグループ](https://docs.aws.amazon.com/network-firewall/latest/developerguide/rule-groups.html)」を参照してください。

## [NetworkFirewall.4] Network Firewall ポリシーのデフォルトのステートレスアクションは、完全なパケットに対してドロップまたは転送される必要があります。
<a name="networkfirewall-4"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 中

**リソースタイプ :** `AWS::NetworkFirewall::FirewallPolicy`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/netfw-policy-default-action-full-packets.html](https://docs.aws.amazon.com/config/latest/developerguide/netfw-policy-default-action-full-packets.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**
+ `statelessDefaultActions: aws:drop,aws:forward_to_sfe` (カスタマイズ不可)

このコントロールは、Network Firewall ポリシーの完全なパケットに対するデフォルトのステートレスアクションが、ドロップまたは転送かどうかをチェックします。`Drop` または `Forward` が選択されている場合、コントロールはパスします。`Pass` が選択されている場合、このコントロールは失敗します。

ファイアウォールポリシーは、ファイアウォールが Amazon VPC のトラフィックをモニタリングおよび処理する方法を定義します。ステートレスおよびステートフルのルールグループを設定し、パケットとトラフィックフローをフィルタリングします。`Pass` をデフォルトに設定すると、意図しないトラフィックが許可される可能性があります。

### 修正
<a name="networkfirewall-4-remediation"></a>

ファイアウォールポリシーを変更する方法については、「*AWS Network Firewall デベロッパーガイド*」の「[Updating a firewall policy](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-policy-updating.html)」を参照してください。**[ステートレスデフォルトアクション]** で、**[編集]** を選択します。続いて、**[アクション]** として、**[ドロップ]** または **[ステートフルルールグループに転送]** を選択します。

## [NetworkFirewall.5] Network Firewall ポリシーのデフォルトのステートレスアクションは、断片化されたパケットに対してドロップまたは転送される必要があります。
<a name="networkfirewall-5"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-171.r2 3.1.3、NIST.800-171.r2 3.1.14、NIST.800-171.r2 3.13.1、NIST.800-171.r2 3.13.6

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 中

**リソースタイプ :** `AWS::NetworkFirewall::FirewallPolicy`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/netfw-policy-default-action-fragment-packets.html](https://docs.aws.amazon.com/config/latest/developerguide/netfw-policy-default-action-fragment-packets.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**
+ `statelessFragDefaultActions (Required) : aws:drop, aws:forward_to_sfe` (カスタマイズ不可)

このコントロールは、Network Firewall ポリシーの断片化されたパケットに対するデフォルトのステートレスアクションが、ドロップまたは転送かどうかをチェックします。`Drop` または `Forward` が選択されている場合、コントロールはパスします。`Pass` が選択されている場合、このコントロールは失敗します。

ファイアウォールポリシーは、ファイアウォールが Amazon VPC のトラフィックをモニタリングおよび処理する方法を定義します。ステートレスおよびステートフルのルールグループを設定し、パケットとトラフィックフローをフィルタリングします。`Pass` をデフォルトに設定すると、意図しないトラフィックが許可される可能性があります。

### 修正
<a name="networkfirewall-5-remediation"></a>

ファイアウォールポリシーを変更する方法については、「*AWS Network Firewall デベロッパーガイド*」の「[Updating a firewall policy](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-policy-updating.html)」を参照してください。**[ステートレスデフォルトアクション]** で、**[編集]** を選択します。続いて、**[アクション]** として、**[ドロップ]** または **[ステートフルルールグループに転送]** を選択します。

## [NetworkFirewall.6] ステートレス Network Firewall のルールグループを空にしないでください
<a name="networkfirewall-6"></a>

**関連する要件:** NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(5)、NIST.800-171.r2 3.1.3、NIST.800-171.r2 3.1.14、NIST.800-171.r2 3.13.1、NIST.800-171.r2 3.13.6

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 中

**リソースタイプ :** `AWS::NetworkFirewall::RuleGroup`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/netfw-stateless-rule-group-not-empty.html](https://docs.aws.amazon.com/config/latest/developerguide/netfw-stateless-rule-group-not-empty.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、 のステートレスルールグループにルール AWS Network Firewall が含まれているかどうかを確認します。ルールグループにルールが含まれない場合、コントロールは失敗します。

ルールグループには、ファイアウォールが VPC 内のトラフィックを処理する方法を定義するルールが含まれています。ファイアウォールポリシーに空のステートレスルールグループが存在する場合、ルールグループがトラフィックを処理するという印象を与える可能性があります。ただし、ステートレスルールグループが空の場合、トラフィックは処理されません。

### 修正
<a name="networkfirewall-6-remediation"></a>

ネットワークファイアウォールのルールグループにルールを追加するには、「*AWS Network Firewall デベロッパーガイド*」の「[Updating a stateful rule group](https://docs.aws.amazon.com/network-firewall/latest/developerguide/rule-group-stateful-updating.html)」を参照してください。ファイアウォールの詳細ページの **[ステートレスルールグループ]** で、**[編集]** を選択してルールを追加します。

## [NetworkFirewall.7] Network Firewall ファイアウォールにはタグを付ける必要があります
<a name="networkfirewall-7"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::NetworkFirewall::Firewall`

**AWS Config rule:** `tagged-networkfirewall-firewall` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、 AWS Network Firewall ファイアウォールにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。ファイアウォールにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ファイアウォールにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="networkfirewall-7-remediation"></a>

Network Firewall ファイアウォールにタグを追加するには、「 *AWS Network Firewall デベロッパーガイド*[」の AWS Network Firewall 「リソースのタグ付け](https://docs.aws.amazon.com/network-firewall/latest/developerguide/tagging.html)」を参照してください。

## [NetworkFirewall.8] Network Firewall ファイアウォールポリシーにはタグを付ける必要があります
<a name="networkfirewall-8"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::NetworkFirewall::FirewallPolicy`

**AWS Config rule:** `tagged-networkfirewall-firewallpolicy` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、 AWS Network Firewall ファイアウォールポリシーにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。ファイアウォールポリシーにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ファイアウォールポリシーにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、『』の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="networkfirewall-8-remediation"></a>

Network Firewall ポリシーにタグを追加するには、「 *AWS Network Firewall デベロッパーガイド*[」の AWS Network Firewall 「リソースのタグ付け](https://docs.aws.amazon.com/network-firewall/latest/developerguide/tagging.html)」を参照してください。

## [NetworkFirewall.9] Network Firewall は削除保護を有効にする必要があります
<a name="networkfirewall-9"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)、NIST.800-53.r5 CM-3、NIST.800-53.r5 SC-5(2)

**カテゴリ:** 保護 > ネットワークセキュリティ

**重要度:** 中

**リソースタイプ :** `AWS::NetworkFirewall::Firewall`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/netfw-deletion-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/netfw-deletion-protection-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、 AWS Network Firewall ファイアウォールで削除保護が有効になっているかどうかを確認します。ファイアウォールで削除保護が有効になっていないと、コントロールは失敗します。

AWS Network Firewall は、仮想プライベートクラウド (VPCs。削除防止設定は、ファイアウォールが誤って削除されないように保護するものです。

### 修正
<a name="networkfirewall-9-remediation"></a>

既存の Network Firewall ファイアウォールで削除保護を有効にするには、「**AWS Network Firewall デベロッパーガイド」の「[ファイアウォールの更新](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-updating.html)」を参照してください。**[変更保護]** で **[有効化]** を選択します。[UpdateFirewallDeleteProtection](https://docs.aws.amazon.com/network-firewall/latest/APIReference/API_UpdateFirewallDeleteProtection.html) API を呼び出し、`DeleteProtection` フィールドを `true` に設定することで削除保護を有効にすることもできます。

## [NetworkFirewall.10] Network Firewall ファイアウォールはサブネット変更保護を有効にする必要があります
<a name="networkfirewall-10"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)、NIST.800-53.r5 CM-3、NIST.800-53.r5 SC-5(2)

**カテゴリ:** 保護 > ネットワークセキュリティ

**重要度:** 中

**リソースタイプ :** `AWS::NetworkFirewall::Firewall`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/netfw-subnet-change-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/netfw-subnet-change-protection-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、 AWS Network Firewall ファイアウォールでサブネット変更保護が有効になっているかどうかをチェックします。ファイアウォールでサブネット変更保護が有効になっていない場合、コントロールは失敗します。

AWS Network Firewall は、仮想プライベートクラウド (VPCs。Network Firewall ファイアウォールのサブネット変更保護を有効にすると、ファイアウォールのサブネットの関連付けが誤って変更されないようにファイアウォールを保護できます。

### 修正
<a name="networkfirewall-10-remediation"></a>

既存の Network Firewall ファイアウォールのサブネット変更保護を有効にする方法については、「*AWS Network Firewall デベロッパーガイド*」の「[Updating a Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-updating.html)」を参照してください。

# Amazon OpenSearch Service の Security Hub CSPM コントロール
<a name="opensearch-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon OpenSearch Service (OpenSearch Service) サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [Opensearch.1] OpenSearch ドメインは保管中の暗号化を有効にする必要があります
<a name="opensearch-1"></a>

**関連する要件:** PCI DSS v3.2.1/1.2.1、PCI DSS v3.2.1/1.3.1、PCI DSS v3.2.1/1.3.4、PCI DSS v3.2.1/7.2.1、NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SI-7(6)

**カテゴリ:** 保護 > データ保護 > 保管中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::OpenSearch::Domain`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/opensearch-encrypted-at-rest.html](https://docs.aws.amazon.com/config/latest/developerguide/opensearch-encrypted-at-rest.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ:** なし

このコントロールは、OpenSearch ドメインで保管中の暗号化設定が有効になっているかどうかをチェックします。保管中の暗号化が有効になっていない場合、チェックは失敗します。

機密データのセキュリティを強化するには、保管中に暗号化するように OpenSearch Service ドメインを設定する必要があります。保管中のデータの暗号化を設定すると、 は暗号化キー AWS KMS を保存および管理します。暗号化を実行するために、 は 256 ビットキー (AES-256) で Advanced Encryption Standard アルゴリズム AWS KMS を使用します。

保管中の OpenSearch での暗号化の詳細については、「*Amazon OpenSearch Service* *デベロッパーガイド*」の「[Encryption of data at rest for Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/encryption-at-rest.html)」を参照してください。

### 修正
<a name="opensearch-1-remediation"></a>

新規および既存の OpenSearch ドメインの保管時の暗号化を有効にするには、「*Amazon OpenSearch Service デベロッパーガイド*」の「[Enabling encryption of data at rest](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/encryption-at-rest.html#enabling-ear)」を参照してください。

## [Opensearch.2] OpenSearch ドメインがパブリックにアクセスできないようにする必要があります
<a name="opensearch-2"></a>

**関連する要件:** PCI DSS v3.2.1/1.2.1、PCI DSS v3.2.1/1.3.1、PCI DSS v3.2.1/1.3.2、PCI DSS v3.2.1/1.3.4、PCI DSS v3.2.1/1.3.6、NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)

**カテゴリ:** 保護 > セキュアなネットワーク設定 > VPC 内のリソース

**重要度:** 非常事態

**リソースタイプ :** `AWS::OpenSearch::Domain`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/opensearch-in-vpc-only.html](https://docs.aws.amazon.com/config/latest/developerguide/opensearch-in-vpc-only.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ:** なし

このコントロールは、OpenSearch ドメインが VPC 内にあるかどうかをチェックします。このコントロールは、パブリックアクセスの可能性を判断するための VPC サブネットルーティング設定を評価しません。

OpenSearch ドメインがパブリックサブネットに添付済みではないことを確認する必要があります。「Amazon OpenSearch Service 開発者ガイド」の「[リソースベースのポリシー](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ac.html#ac-types-resource)」を参照してください。また、推奨されるベストプラクティスに従って VPC が確実に設定されていることを確認する必要があります。「Amazon VPC ユーザーガイド」の「[VPC のセキュリティのベストプラクティス](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html)」を参照してください。

VPC 内にデプロイされた OpenSearch ドメインは、パブリックインターネットを経由することなく、プライベート AWS ネットワーク経由で VPC リソースと通信できます。この設定では、転送中のデータへのアクセスを制限することにより、セキュリティ体制が向上します。VPC は、ネットワーク ACL やセキュリティグループを含む、OpenSearch ドメインへのアクセスを安全にするため、多数のネットワークコントロールを提供します。Security Hub では、これらのコントロールを有効に利用するために、パブリック OpenSearch ドメインを VPC に移行することを推奨します。

### 修正
<a name="opensearch-2-remediation"></a>

パブリックエンドポイントを使用してドメインを作成する場合、後で VPC 内にドメインを配置することはできません。代わりに、新規のドメインを作成して、データを移行する必要があります。逆の場合も同様です。VPC 内にドメインを作成する場合、パブリックエンドポイントを持つことはできません。代わりに、[別のドメインを作成する](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/createupdatedomains.html#es-createdomains)か、このコントロールを無効にする必要があります。

手順については、「*Amazon OpenSearch Service デベロッパーガイド*」の「[Launching your Amazon OpenSearch Service domains within a VPC](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/vpc.html)」を参照してください。

## [Opensearch.3] OpenSearch ドメインはノード間で送信されるデータを暗号化する必要があります
<a name="opensearch-3"></a>

**関連する要件:** NIST.800-53.r5 AC-4、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-23、NIST.800-53.r5 SC-23(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-8、NIST.800-53.r5 SC-8(1)、NIST.800-53.r5 SC-8(2)

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::OpenSearch::Domain`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/opensearch-node-to-node-encryption-check.html](https://docs.aws.amazon.com/config/latest/developerguide/opensearch-node-to-node-encryption-check.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ:** なし

このコントロールは、OpenSearch ドメインでノード間の暗号化が有効になっているかどうかをチェックします。ドメインでノード間の暗号化が無効になっている場合、このコントロールは失敗します。

HTTPS (TLS) を使用すると、潜在的な攻撃者が中間者攻撃または同様の攻撃を使用してネットワークトラフィックを盗聴または操作することを防止できます。HTTPS (TLS) 経由の暗号化された接続のみを許可する必要があります。OpenSearch ドメインでノード間の暗号化を有効にすると、クラスター内通信は転送中に確実に暗号化されます。

この設定には、パフォーマンス上のペナルティが発生する可能性があります。このオプションを有効にする前に、パフォーマンスのトレードオフを認識してテストする必要があります。

### 修正
<a name="opensearch-3-remediation"></a>

OpenSearch ドメインでノード間の暗号化を有効にするには、「*Amazon OpenSearch Service デベロッパーガイド*」の「[ノード間の暗号化を有効にする](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ntn.html#enabling-ntn)」を参照してください。

## [Opensearch.4] CloudWatch Logs への OpenSearch ドメインエラーのログ記録を有効にする必要があります
<a name="opensearch-4"></a>

**関連する要件:** NIST.800-53.r5 AC-2(4)、NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AC-6(9)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4(20)、NIST.800-53.r5 SI-7(8)

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::OpenSearch::Domain`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/opensearch-logs-to-cloudwatch.html](https://docs.aws.amazon.com/config/latest/developerguide/opensearch-logs-to-cloudwatch.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**
+ `logtype = 'error'` (カスタマイズ不可)

このコントロールは、OpenSearch ドメインが CloudWatch Logs にエラーログを送信するように設定されているかどうかをチェックします。CloudWatch へのエラーログ記録がドメインに対して有効になっていない場合、このコントロールは失敗します。

OpenSearch ドメインのエラーログを有効にし、それらのログを CloudWatch Logs に送信して保持と応答を行う必要があります。ドメインのエラーログは、セキュリティとアクセス監査や、可用性の問題の診断に役立ちます。

### 修正
<a name="opensearch-4-remediation"></a>

ログ発行を有効にするには、「*Amazon OpenSearch Service デベロッパーガイド*」の「[Enabling log publishing (console)](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/createdomain-configure-slow-logs.html#createdomain-configure-slow-logs-console)」を参照してください。

## [Opensearch.5] OpenSearch ドメインでは、監査ログ記録を有効にする必要があります
<a name="opensearch-5"></a>

**関連する要件:** NIST.800-53.r5 AC-2(4)、NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AC-6(9)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4(20)、NIST.800-53.r5 SI-7(8)、PCI DSS v4.0.1/10.2.1

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::OpenSearch::Domain`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/opensearch-audit-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/opensearch-audit-logging-enabled.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**
+ `cloudWatchLogsLogGroupArnList` (カスタマイズ不可) – Security Hub CSPM はこのパラメータに入力しません。監査ログ用に設定する必要がある CloudWatch Logs ロググループのカンマ区切りリスト。

このコントロールは、OpenSearch ドメインで監査ログ記録が有効になっているかどうかをチェックします。OpenSearch ドメインで監査ログ記録が有効になっていない場合、このコントロールは失敗します。

監査ログは高度なカスタマイズが可能です。これらを使用することで、認証の成功と失敗、OpenSearch へのリクエスト、インデックスの変更、受信検索クエリなど、OpenSearch クラスターでのユーザーアクティビティを追跡できます。

### 修正
<a name="opensearch-5-remediation"></a>

監査ログを有効にする手順については、「*Amazon OpenSearch Service デベロッパーガイド*」の「[Enabling audit logs](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/audit-logs.html#audit-log-enabling)」を参照してください。

## [Opensearch.6] OpenSearch ドメインには少なくとも 3 つのデータノードが必要です
<a name="opensearch-6"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 SC-36、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)

**カテゴリ:** リカバリ > 耐障害性 > 高可用性

**重要度:** 中

**リソースタイプ :** `AWS::OpenSearch::Domain`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/opensearch-data-node-fault-tolerance.html](https://docs.aws.amazon.com/config/latest/developerguide/opensearch-data-node-fault-tolerance.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ:** なし

このコントロールは OpenSearch ドメインが少なくとも 3 つのデータノードが設定されているか、また `zoneAwarenessEnabled` が `true` かどうかをチェックします。OpenSearch ドメインでは、`instanceCount` が 3 より小さいか `zoneAwarenessEnabled` が `false` の場合、このコントロールは失敗します。

クラスターレベルの高可用性と耐障害性を実現するには、OpenSearch ドメインに少なくとも 3 つのデータノードが必要です。少なくとも 3 つのデータノードを持つ OpenSearch ドメインをデプロイすると、ノードに障害が発生した場合のクラスター操作が確実になります。

### 修正
<a name="opensearch-6-remediation"></a>

**OpenSearch ドメインのデータノード数を変更するには**

1.  AWS コンソールにサインインし、[https://console.aws.amazon.com/aos/](https://console.aws.amazon.com/aos/) で Amazon OpenSearch Service コンソールを開きます。

1. **[My domains]** (ドメイン) で、編集するドメインの名前を選択し、**[Edit]** (編集) を選択します。

1. **[Data nodes]** (データノード) で、**[Number of nodes]** (ノード数) を `3` 以上の数値に設定します。3 つのアベイラビリティーゾーンに展開する場合は、アベイラビリティーゾーン間で均等に分配されるように 3 の倍数に設定します。

1. [**Submit**] を選択してください。

## [Opensearch.7] OpenSearch ドメインは、きめ細かなアクセスコントロールを有効にする必要があります
<a name="opensearch-7"></a>

**関連する要件:** NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-5、NIST.800-53.r5 AC-6

**カテゴリ:** 保護 > セキュアなアクセス管理 > 機密性の高い API オペレーションアクションを制限する

**重要度:** 高

**リソースタイプ :** `AWS::OpenSearch::Domain`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/opensearch-access-control-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/opensearch-access-control-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

OpenSearch ドメインが、きめ細かなアクセスコントロールを有効にしているかどうかをチェックします。きめ細かなアクセスコントロールが有効でない場合、このコントロールは失敗します。OpenSearch パラメータ `update-domain-config` を有効にするには、きめ細かなアクセスコントロールに `advanced-security-options` が必要となります。

きめ細かなアクセスコントロールは、Amazon OpenSearch Service のデータへのアクセスをコントロールする追加の方法を提供します。

### 修正
<a name="opensearch-7-remediation"></a>

きめ細かなアクセスコントロールを有効にする方法については、「*Amazon OpenSearch Service デベロッパーガイド*」の「[Fine-grained access control in Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac.html)」を参照してください。

## [Opensearch.8] OpenSearch ドメインへの接続は最新の TLS セキュリティポリシーを使用して暗号化する必要があります
<a name="opensearch-8"></a>

**関連する要件:** NIST.800-53.r5 AC-17(2)、NIST.800-53.r5 AC-4、NIST.800-53.r5 IA-5(1)、NIST.800-53.r5 SC-12(3)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-23、NIST.800-53.r5 SC-23(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-8、NIST.800-53.r5 SC-8(1)、NIST.800-53.r5 SC-8(2)、NIST.800-53.r5 SI-7(6)

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::OpenSearch::Domain`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/opensearch-https-required.html](https://docs.aws.amazon.com/config/latest/developerguide/opensearch-https-required.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**
+ `tlsPolicies: Policy-Min-TLS-1-2-PFS-2023-10` (カスタマイズ不可)

このコントロールは、Amazon OpenSearch Service ドメインエンドポイントが最新の TLS セキュリティポリシーを使用するように設定されているかどうかを確認します。OpenSearch ドメインエンドポイントが最新のサポートされているポリシーを使用するように設定されていない場合、または HTTPS が有効になっていない場合、コントロ―ルは失敗します。

HTTPS (TLS) を使用すると、潜在的な攻撃者が中間者攻撃または同様の攻撃を使用してネットワークトラフィックを盗聴または操作することを防止できます。HTTPS (TLS) 経由の暗号化された接続のみを許可する必要があります。転送中のデータの暗号化は、パフォーマンスに影響する可能性があります。TLS のパフォーマンスプロファイルと TLS の影響を把握するには、この機能を使用してアプリケーションをテストする必要があります。TLS 1.2 は、以前の TLS バージョンに比べて、いくつかのセキュリティ機能の強化を提供します。

### 修正
<a name="opensearch-8-remediation"></a>

TLS 暗号化を有効にするには、[UpdateDomainConfig](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_UpdateDomainConfig.html) API オペレーションを使用してください。「[DomainEndpointOptions](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_DomainEndpointOptions.html)」フィールドを設定して、`TLSSecurityPolicy` の値を指定します。詳細については、「*Amazon OpenSearch Service デベロッパーガイド*」の「[Node-to-node encryption](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ntn.html)」を参照してください。

## [Opensearch.9] OpenSearch ドメインはにはタグを付ける必要があります
<a name="opensearch-9"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::OpenSearch::Domain`

**AWS Config rule:** `tagged-opensearch-domain` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、Amazon OpenSearch Service ドメインにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。ドメインにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ドメインにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="opensearch-9-remediation"></a>

OpenSearch Service ドメインにタグを追加するには、「*Amazon OpenSearch Service デベロッパーガイド*」の「[タグの使用](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/managedomains-awsresourcetagging.html#managedomains-awsresourcetagging-console)」を参照してください。

## [Opensearch.10] OpenSearch ドメインには、最新のソフトウェアアップデートがインストールされている必要があります
<a name="opensearch-10"></a>

**関連する要件:** NIST.800-53.r5 SI-2、NIST.800-53.r5 SI-2(2)、NIST.800-53.r5 SI-2(4)、NIST.800-53.r5 SI-2(5)、PCI DSS v4.0.1/6.3.3

**カテゴリ:** 特定 > 脆弱性、パッチ、バージョン管理

**重要度:** 中

**リソースタイプ :** `AWS::OpenSearch::Domain`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/opensearch-update-check.html](https://docs.aws.amazon.com/config/latest/developerguide/opensearch-update-check.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon OpenSearch Service ドメインに最新のソフトウェアアップデートがインストールされているかどうかをチェックします。ソフトウェアアップデートが利用可能で、ドメインにインストールされていない場合、コントロールは失敗します。

OpenSearch Service のソフトウェアアップデートは、環境で使用可能な最新のプラットフォーム修正、更新、および機能を提供します。パッチのインストールを最新の状態に保つことは、ドメインのセキュリティと可用性を維持するのに役立ちます。必要なアップデートに関するアクションを実行しない場合、サービスソフトウェアは (通常 2 週間後に) 自動的に更新されます。サービスの中断を最小限に抑えるため、ドメインへのトラフィックが少ない時間帯にアップデートをスケジュールすることをお勧めします。

### 修正
<a name="opensearch-10-remediation"></a>

OpenSearch ドメインのソフトウェアアップデートをインストールするには、「*Amazon OpenSearch Service デベロッパーガイド*」の「[Starting an update](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/service-software.html#service-software-requesting)」を参照してください。

## [Opensearch.11] OpenSearch ドメインには少なくとも 3 つの専用プライマリノードが必要です
<a name="opensearch-11"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-2、NIST.800-53.r5 SC-5、NIST.800-53.r5 SC-36、NIST.800-53.r5 SI-13

**カテゴリ:** リカバリ > 耐障害性 > 高可用性

**重要度:** 低

**リソースタイプ :** `AWS::OpenSearch::Domain`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/opensearch-primary-node-fault-tolerance.html](https://docs.aws.amazon.com/config/latest/developerguide/opensearch-primary-node-fault-tolerance.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは Amazon OpenSearch Service ドメインが少なくとも 3 つの専用プライマリノードで設定されているかどうかをチェックします。ドメインの専用プライマリノードが 3 つ未満の場合、コントロールは失敗します。

OpenSearch Service では、クラスターの安定性を向上するために専用プライマリノードを使用します。専用プライマリノードはクラスター管理タスクを実行しますが、データは保持せず、データのアップロードリクエストにも応答しません。スタンバイ付きマルチ AZ を使用することを推奨します。これにより、本番稼働用の各 OpenSearch Service ドメインに 3 つの専用プライマリノードが追加されます。

### 修正
<a name="opensearch-11-remediation"></a>

OpenSearch ドメインのプライマリノードの数を変更するには、「*Amazon OpenSearch Service デベロッパーガイド*」の「[Amazon OpenSearch Service ドメインの作成と管理](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/createupdatedomains.html)」を参照してください。

# の Security Hub CSPM コントロール AWS Private CA
<a name="pca-controls"></a>

これらの AWS Security Hub CSPM コントロールは、 AWS Private Certificate Authority (AWS Private CA) サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [PCA.1] AWS Private CA ルート認証機関を無効にする必要があります
<a name="pca-1"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 低

**リソースタイプ :** `AWS::ACMPCA::CertificateAuthority`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/acm-pca-root-ca-disabled.html](https://docs.aws.amazon.com/config/latest/developerguide/acm-pca-root-ca-disabled.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロール AWS Private CA は、無効になっているルート認証機関 (CA) があるかどうかをチェックします。ルート CA が有効になっている場合、コントロールは失敗します。

を使用すると AWS Private CA、ルート CA と下位 CAs を含む CA 階層を作成できます。特に本番環境では、日常的なタスクでのルート CA の使用を最小限に抑える必要があります。ルート CA は、中間 CA 認定を交付するためにのみ使用する必要があります。これにより、中間 CA がエンドエンティティ証明書を発行する毎日のタスクを実行しながら、ルート CA を害のない方法で保存することができます。

### 修正
<a name="pca-1-remediation"></a>

ルート CA を無効にするには、「*AWS Private Certificate Authority ユーザーガイド*」の「[CA ステータスの更新](https://docs.aws.amazon.com/privateca/latest/userguide/console-update.html#console-update-status-steps)」を参照してください。

## [PCA.2] AWS プライベート CA 認証機関にはタグを付ける必要があります
<a name="pca-2"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::ACMPCA::CertificateAuthority`

**AWS Config ルール :** `acmpca-certificate-authority-tagged`

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  デフォルト値なし  | 

このコントロールは、 AWS プライベート CA 認証機関にパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredKeyTags`。認証機関にタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredKeyTags` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、認証機関にキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、「 リソースのタグ付けとタグエディタユーザーガイド」の[「ベストプラクティスと戦略](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください。 * AWS *

### 修正
<a name="pca-2-remediation"></a>

 AWS プライベート CA 機関にタグを追加するには、*AWS Private Certificate Authority 「 ユーザーガイド*」の[「プライベート CA のタグを追加する](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCaTagging.html)」を参照してください。

# Amazon RDS の Security Hub CSPM コントロール
<a name="rds-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon Relational Database Service (Amazon RDS) および Amazon RDS リソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [RDS.1] RDS スナップショットはプライベートである必要があります
<a name="rds-1"></a>

**関連する要件:** PCI DSS v3.2.1/1.2.1、PCI DSS v3.2.1/1.3.1、PCI DSS v3.2.1/1.3.4、PCI DSS v3.2.1/1.3.6、PCI DSS v3.2.1/7.2.1、NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 非常事態

**リソースタイプ:** `AWS::RDS::DBClusterSnapshot`、`AWS::RDS::DBSnapshot`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-snapshots-public-prohibited.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-snapshots-public-prohibited.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ:** なし

このコントロールは、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 スナップショットの共有](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ShareSnapshot.html)」を参照してください。

### 修正
<a name="rds-1-remediation"></a>

RDS スナップショットからパブリックアクセスを削除するには、「*Amazon RDS ユーザーガイド*」の「[スナップショットの共有](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ShareSnapshot.html#USER_ShareSnapshot.Sharing)」を参照してください。**[DB スナップショットの可視性]** で、**[プライベート]** を選択します。

## [RDS.2] RDS DB インスタンスは、PubliclyAccessible 設定によって判断される、パブリックアクセスを禁止する必要があります
<a name="rds-2"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/2.2.3、CIS AWS Foundations Benchmark v3.0.0/2.3.3、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-70-53.r5 SC-7(5)、PCI v3.2

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 非常事態

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-instance-public-access-check.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-instance-public-access-check.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ:** なし

このコントロールは、インスタンス設定項目内の `PubliclyAccessible` フィールドを評価して、Amazon RDS インスタンスがパブリックにアクセスできるかどうかをチェックします。

Neptune DB インスタンスと Amazon DocumentDB クラスターには、`PubliclyAccessible` フラグがないため、評価できません。ただし、このコントロールでは、これらのリソースに関する結果を生成できます。これらの結果を抑制できます。

RDS インスタンス設定 の `PubliclyAccessible` 値は、DB インスタンスがパブリックにアクセスできるかどうかを示します。DB インスタンスが `PubliclyAccessible` で設定されている場合、パブリックに解決可能な DNS 名を持つインターネット向けインスタンスであり、パブリック IP アドレスに解決されます。DB インスタンスがパブリックにアクセスできない場合、それはプライベート IP アドレスに解決される DNS 名を持つ内部インスタンスとなります。

RDS インスタンスのパブリックアクセスを可能にする意図がない限り、RDS インスタンスを `PubliclyAccessible` 値に設定しないでください。この設定を行った場合、データベースインスタンスへの不要なトラフィックが許可される可能性があります。

### 修正
<a name="rds-2-remediation"></a>

RDS DB インスタンスからパブリックアクセスを削除するには、「*Amazon RDS ユーザーガイド*」の「[Amazon RDS DB インスタンスを変更する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html)」を参照してください。**[パブリックアクセス]** で **[いいえ]** を選択します。

## [RDS.3] RDS DB インスタンスでは、保管時の暗号化が有効になっている必要があります。
<a name="rds-3"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/2.2.1、CIS AWS Foundations Benchmark v3.0.0/2.3.1、CIS AWS Foundations Benchmark v1.4.0/2.3.1、NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SI-7(6)

**カテゴリ:** 保護 > データ保護 > 保管中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-storage-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-storage-encrypted.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ:** なし

このコントロールは、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 リソースの暗号化](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)」を参照してください。

### 修正
<a name="rds-3-remediation"></a>

Amazon RDS での DB インスタンスの暗号化の詳細については、「Amazon RDS ユーザーガイド」の「[Amazon RDS リソースの暗号化](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)」を参照してください。

## [RDS.4] RDS クラスタースナップショットとデータベーススナップショットは保管中に暗号化する必要があります
<a name="rds-4"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SI-7(6)

**カテゴリ:** 保護 > データ保護 > 保管中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBClusterSnapshot`、` AWS::RDS::DBSnapshot`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-snapshot-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-snapshot-encrypted.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、RDS DB スナップショットが暗号化されているかどうかをチェックします。RDS DB スナップショットが暗号化されていない場合、コントロールは失敗します。

このコントロールは、RDS DB インスタンスを対象としています。ただし、Aurora DB インスタンス、Neptune DB インスタンス、および Amazon DocumentDB クラスターのスナップショットに関する結果を生成することもできます。これらの結果が役に立たない場合は、それらを抑制できます。

保管中のデータを暗号化すると、認証されていないユーザーがディスクに保存しているデータにアクセスするリスクが低減されます。RDS スナップショット内のデータは、セキュリティを強化するために、保管中に暗号化する必要があります。

### 修正
<a name="rds-4-remediation"></a>

RDS スナップショットを暗号化するには、「*Amazon RDS ユーザーガイド*」の「[Amazon RDS リソースの暗号化](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)」を参照してください。RDS DB インスタンスを暗号化するとき、暗号化されたデータにはインスタンスの基盤となるストレージ、自動バックアップ、リードレプリカ、スナップショットが含まれます。

RDS DB インスタンスを暗号化できるのは作成時のみであり、DB インスタンスの作成後には暗号化できません。ただし、暗号化されていないスナップショットのコピーは暗号化できるので、暗号化されていない DB インスタンスに効果的に暗号化を追加できます。つまり、DB インスタンスのスナップショットを作成し、そのスナップショットの暗号化済みコピーを作成します。この暗号化されたスナップショットから DB インスタンスを復元することで、元の DB インスタンスの暗号化されたコピーを作成できます。

## [RDS.5] RDS DB インスタンスは、複数のアベイラビリティーゾーンで設定する必要があります
<a name="rds-5"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/2.2.4、NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 SC-36、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)

**カテゴリ:** リカバリ > 耐障害性 > 高可用性

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-multi-az-support.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-multi-az-support.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ:** なし

このコントロールは、RDS DB インスタンスの高可用性が有効になっているかどうかをチェックします。RDS DB インスタンスが複数のアベイラビリティーゾーン (AZ) で設定されていない場合、コントロールは失敗します。このコントロールは、マルチ AZ DB クラスターデプロイの一部である RDS DB インスタンスには適用されません。

AZ を使用して Amazon RDS DB インスタンスを設定すると、保存されたデータの可用性を確保できます。マルチ AZ 配置では、AZ の可用性に問題が発生した場合や、RDS の定期メンテナンス中に自動フェイルオーバーを実行できます。

### 修正
<a name="rds-5-remediation"></a>

DB インスタンスを複数の AZ にデプロイするには、「*Amazon RDS ユーザーガイド*」の「[DB インスタンスをマルチ AZ DB インスタンスのデプロイに変更する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html#Concepts.MultiAZ.Migrating)」を参照してください。

## [RDS.6] RDS DB インスタンスの拡張モニタリングを設定する必要があります
<a name="rds-6"></a>

**関連する要件:** NIST.800-53.r5 CA-7、NIST.800-53.r5 SI-2

**カテゴリ:** 検出 > 検出サービス

**重要度:** 低

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-enhanced-monitoring-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-enhanced-monitoring-enabled.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `monitoringInterval`  |  モニタリングメトリクスの収集間隔の秒数  |  列挙型  |  `1`, `5`, `10`, `15`, `30`, `60`  |  デフォルト値なし  | 

このコントロールは、Amazon Relational Database Service (Amazon RDS) DB インスタンスに対して拡張モニタリングが有効になっているかどうかをチェックします。インスタンスで拡張モニタリングが有効になっていない場合、コントロールは失敗します。`monitoringInterval` パラメータにカスタム値を指定したときは、指定された間隔でインスタンスの拡張モニタリングメトリクスが収集された場合にのみコントロールが成功します。

Amazon RDS では、拡張モニタリングによって、基盤となるインフラストラクチャのパフォーマンスの変化に対してより迅速にレスポンスできます。これらのパフォーマンスの変化により、データの可用性が低下する可能性があります。拡張モニタリングが有効になっている場合、RDS DB インスタンスが実行される OS のリアルタイムメトリクスを提供します。エージェントがインスタンスにインストールされています。エージェントは、ハイパーバイザーレイヤーから得られるよりも正確にメトリクスを取得できます。

拡張モニタリングのメトリクスは、DB インスタンス上のさまざまなプロセスやスレッドがどのように CPU を使用しているかを表示するときに便利です。詳細については、「Amazon RDS ユーザーガイド」の「[拡張モニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)」を参照してください。

### 修正
<a name="rds-6-remediation"></a>

DB インスタンスで拡張モニタリングを有効にする手順の詳細については、「*Amazon RDS ユーザーガイド*」の「[拡張モニタリングの設定と有効化](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.Enabling)」を参照してください。

## [RDS.7] RDS クラスターでは、削除保護が有効になっている必要があります
<a name="rds-7"></a>

**関連する要件:** NIST.800-53.r5 CM-3、NIST.800-53.r5 SC-5(2)

**カテゴリ:** 保護 > データ保護 > データ削除保護

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-deletion-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-deletion-protection-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、RDS DB クラスターで削除保護が有効になっているかどうかをチェックします。RDS DB クラスターで削除保護が有効になっていない場合、コントロールは失敗します。

このコントロールは、RDS DB インスタンスを対象としています。ただし、Aurora DB インスタンス、Neptune DB インスタンス、および Amazon DocumentDB クラスターの結果を生成することもできます。これらの結果が役に立たない場合は、それらを抑制できます。

クラスターの削除保護を有効にすることで、偶発的なデータベース削除や不正なエンティティによる削除に対して保護の強化を提供します。

削除保護が有効になっている場合、RDS クラスターは削除できません。削除リクエストが成功するには、削除保護を無効にする必要があります。

### 修正
<a name="rds-7-remediation"></a>

RDS DB クラスターの削除保護を有効にするには、「*Amazon RDS ユーザーガイド*」の「[コンソール、CLI、API を使用した DB クラスターの変更](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Modifying.html#Aurora.Modifying.Cluster)」を参照してください。**[削除保護]** で **[削除保護の有効化]** を選択します。

## [RDS.8] RDS DB インスタンスで、削除保護が有効になっている必要があります
<a name="rds-8"></a>

**関連する要件:** NIST.800-53.r5 CM-3、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)

**カテゴリ:** 保護 > データ保護 > データ削除保護

**重要度:** 低

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-instance-deletion-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-instance-deletion-protection-enabled.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**
+ `databaseEngines`: `mariadb,mysql,custom-oracle-ee,oracle-ee-cdb,oracle-se2-cdb,oracle-ee,oracle-se2,oracle-se1,oracle-se,postgres,sqlserver-ee,sqlserver-se,sqlserver-ex,sqlserver-web` (カスタマイズ不可)

このコントロールは、リストされたデータベースエンジンのいずれかを使用する RDS DB インスタンスで削除保護が有効になっているかどうかをチェックします。RDS DB インスタンスで削除保護が有効になっていない場合、コントロールは失敗します。

インスタンス削除保護を有効にすると、偶発的なデータベース削除や不正なエンティティによる削除に対する保護の強化を提供します。

削除保護が有効になっている間は、RDS DB インスタンスを削除できません。削除リクエストが成功するには、削除保護を無効にする必要があります。

### 修正
<a name="rds-8-remediation"></a>

RDS DB インスタンスの削除保護を有効にするには、「*Amazon RDS ユーザーガイド*」の「[Amazon RDS DB インスタンスを変更する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html)」を参照してください。**[削除保護]** で **[削除保護の有効化]** を選択します。

## [RDS.9] RDS DB インスタンスは CloudWatch Logs にログを発行する必要があります
<a name="rds-9"></a>

**関連する要件:** NIST.800-53.r5 AC-2(4)、NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AC-6(9)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4(20)、NIST.800-53.r5 SI-7(8)、PCI DSS v4.0.1/10.2.1

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-logging-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon RDS DB インスタンスが以下のログを Amazon CloudWatch Logs に発行するように設定されているかどうかをチェックします。インスタンスが以下のログを CloudWatch Logs に発行するように設定されていない場合、コントロールは失敗します。
+ Oracle: アラート、監査、トレース、リスナー
+ PostgreSQL: Postgresql、アップグレード
+ MySQL: 監査、エラー、一般、SlowQuery
+ MariaDB: 監査、エラー、一般、SlowQuery
+ SQL Server: エラー、エージェント
+ Aurora: 監査、エラー、一般、SlowQuery
+ Aurora-MySQL: 監査、エラー、一般、SlowQuery
+ Aurora-PostgreSQL: Postgresql

RDS データベースでは、関連するログを有効にする必要があります。データベースログ記録は、RDS に対して行われたリクエストの詳細な記録を提供します。データベースログは、セキュリティとアクセス監査に役立ち、可用性の問題を診断するのに役立ちます。

### 修正
<a name="rds-9-remediation"></a>

RDS データベースログを CloudWatch Logs に発行する方法については、「*Amazon RDS ユーザーガイド*」の「[CloudWatch Logs に発行するログの指定](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Procedural.UploadtoCloudWatch.html#integrating_cloudwatchlogs.configure)」を参照してください。

## [RDS.10] IAM 認証は RDS インスタンス用に設定する必要があります
<a name="rds-10"></a>

**関連する要件:** NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-6

**カテゴリ:** 保護 > セキュアなアクセス管理 > パスワードレス認証

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-instance-iam-authentication-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-instance-iam-authentication-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ:** なし

このコントロールは、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 データベース認証](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.html)」を参照してください。

### 修正
<a name="rds-10-remediation"></a>

RDS DB インスタンスで IAM データベース認証を有効にするには、「*Amazon RDS ユーザーガイド*」の「[IAM データベース認証の有効化と無効化](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.Enabling.html)」を参照してください。

## [RDS.11] RDS インスタンスでは、自動バックアップが有効になっている必要があります
<a name="rds-11"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6、NIST.800-53.r5 CP-6(1)、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 CP-9、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-12、NIST.800-53.r5 SI-13(5)

**カテゴリ:** リカバリ > 耐障害性 > バックアップの有効化 

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/db-instance-backup-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/db-instance-backup-enabled.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `backupRetentionMinimum`  |  最小バックアップ保持期間 (日数)  |  整数  |  `7`～`35`  |  `7`  | 
|  `checkReadReplicas`  |  リードレプリカに対して RDS DB インスタンスでバックアップが有効になっているかどうかを確認します  |  ブール値  |  カスタマイズ不可  |  `false`  | 

このコントロールは、Amazon Relational Database Service インスタンスで自動バックアップが有効に設定されていて、バックアップ保持期間が指定された時間枠以上であるかどうかをチェックします。リードレプリカは評価から除外されます。インスタンスのバックアップが有効になっていない場合や、保持期間が指定された時間枠未満の場合、コントロールは失敗します。バックアップ保持期間にカスタムパラメータ値を指定しない限り、Security Hub CSPM はデフォルト値の 7 日を使用します。

バックアップは、セキュリティインシデントからより迅速に復元し、システムの耐障害性を強化するのに役立ちます。Amazon RDS により、毎日のフルインスタンスボリュームスナップショットを設定することができます。Amazon RDS の自動バックアップの詳細については、「*Amazon RDS ユーザーガイド*」の「[バックアップの使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html)」を参照してください。

### 修正
<a name="rds-11-remediation"></a>

RDS DB インスタンスの自動バックアップを有効化するには、「*Amazon RDS ユーザーガイド*」の「[自動バックアップの有効化](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html#USER_WorkingWithAutomatedBackups.Enabling)」を参照してください。

## [RDS.12] IAM 認証は RDS クラスター用に設定する必要があります
<a name="rds-12"></a>

**関連する要件:** NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-6

**カテゴリ:** 保護 > セキュアなアクセス管理 > パスワードレス認証

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-iam-authentication-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-iam-authentication-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon RDS DB クラスターで IAM データベース認証が有効になっているかどうかをチェックします。

IAM データベース認証では、データベースインスタンスへパスワードなしの認証が許可されています。認証には、認証トークンが使用されます。データベースに出入りするネットワークトラフィックは、SSL を使用して暗号化されます。詳細については、「Amazon Aurora ユーザーガイド」の「[IAM データベース認証](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.html)」を参照してください。

### 修正
<a name="rds-12-remediation"></a>

DB クラスターで IAM 認証を有効にするには、「*Amazon Aurora ユーザーガイド*」の「[IAM データベース認証の有効化と無効化](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.Enabling.html)」を参照してください。

## [RDS.13] RDS 自動マイナーバージョンアップグレードを有効にする必要があります
<a name="rds-13"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/2.2.2、CIS AWS Foundations Benchmark v3.0.0/2.3.2、NIST.800-53.r5 SI-2、NIST.800-53.r5 SI-2(2)、NIST.800-53.r5 SI-2(4)、NIST.800-53.r5 SI-2(5)、PCI DSS v4.0.1/6.3.3

**カテゴリ:** 特定 > 脆弱性、パッチ、バージョン管理

**重要度:** 高

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-automatic-minor-version-upgrade-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-automatic-minor-version-upgrade-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ:** なし

このコントロールは、RDS データベースインスタンスでマイナーバージョン自動アップグレードが有効になっているかどうかをチェックします。

マイナーバージョン自動アップグレードは、データベースを定期的に最新のデータベースエンジンのバージョンに更新します。ただし、アップグレードに最新のデータベースエンジンのバージョンが含まれているとは限りません。特定の時間に特定のバージョンでデータベースを維持する必要がある場合は、必要なスケジュールに従って必要なデータベースのバージョンに手動でアップグレードすることをお勧めします。重大なセキュリティ問題が発生した場合、またはバージョンがサポート終了日に達すると、**[マイナーバージョン自動アップグレード]** オプションを有効にしていない場合でも、Amazon RDS はマイナーバージョンアップグレードを適用することがあります。詳細については、お使いのデータベースエンジンの Amazon RDS アップグレードドキュメントを参照してください。
+ [RDS for MariaDB の自動マイナーバージョンアップグレード](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MariaDB.Minor.html)
+ [RDS for MySQL の自動マイナーバージョンアップグレード](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MySQL.Minor.html)
+ [RDS for PostgreSQL の自動マイナーバージョンアップグレード](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.Minor.html)
+ [Amazon RDS バージョンの Db2 ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Db2.Concepts.VersionMgmt.html)
+ [Oracle マイナーバージョンアップグレード](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Oracle.Minor.html)
+ [Microsoft SQL Server DB エンジンのアップグレード](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.SQLServer.html)

### 修正
<a name="rds-13-remediation"></a>

既存の DB インスタンスの自動マイナーバージョンアップグレードを有効にするには、「*Amazon RDS ユーザーガイド*」の「[Amazon RDS DB インスタンスを変更する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html)」を参照してください。**[マイナーバージョン自動アップグレード]** で **[はい]** を選択します。

## [RDS.14] Amazon Aurora クラスターはバックトラッキングを有効にする必要があります
<a name="rds-14"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6、NIST.800-53.r5 CP-6(1)、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 CP-9、NIST.800-53.r5 SI-13(5)

**カテゴリ:** リカバリ > 耐障害性 > バックアップの有効化 

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/aurora-mysql-backtracking-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/aurora-mysql-backtracking-enabled.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `BacktrackWindowInHours`  |  Aurora MySQL クラスターをバックトラックする時間数  |  Double  |  `0.1`～`72`  |  デフォルト値なし  | 

このコントロールは、Amazon Aurora クラスターでバックトラックが有効になっているかどうかをチェックします。クラスターでバックトラックが有効になっていない場合、コントロールは失敗します。`BacktrackWindowInHours` パラメータにカスタム値を指定したときは、指定された時間、クラスターがバックトラックされた場合にのみコントロールが成功します。

バックアップは、セキュリティインシデントからより迅速に復元するために役立ちます。また、システムの耐障害性を強化します。Aurora バックトラッキングによって、データベースを特定の時点に復元する時間が短縮されます。復元を実行する場合にデータベースの復元は必要ありません。

### 修正
<a name="rds-14-remediation"></a>

Aurora バックトラックを有効にするには、「*Amazon Aurora ユーザーガイド*」の「[バックトラックの設定](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.Backtrack.html#AuroraMySQL.Managing.Backtrack.Configuring)」を参照してください。

既存のクラスターではバックトラッキングを有効にできないことに注意してください。代わりに、バックトラッキングが有効になっているクローンを作成できます。Aurora でのバックトラック制限の詳細については、「[バックトラックの概要](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.Backtrack.html)」の制限事項の一覧を参照してください。

## [RDS.15] RDS DB クラスターを複数のアベイラビリティーゾーンに対して設定する必要があります
<a name="rds-15"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/2.2.4、NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 SC-36、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)

**カテゴリ:** リカバリ > 耐障害性 > 高可用性

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-multi-az-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-multi-az-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ:** なし

このコントロールは、RDS DB クラスターで高可用性が有効になっているかどうかをチェックします。RDS DB クラスターが複数のアベイラビリティーゾーン (AZ) にデプロイされていない場合、コントロールは失敗します。

RDS DB クラスターは、保存されたデータの可用性を確保するために、複数の AZ に対して設定する必要があります。複数の AZ にデプロイすると、AZ の可用性に問題が発生した場合や、RDS の定期メンテナンスイベント中に自動フェイルオーバーを実行できます。

### 修正
<a name="rds-15-remediation"></a>

DB クラスターを複数の AZ にデプロイするには、「*Amazon RDS ユーザーガイド*」の「[DB インスタンスをマルチ AZ DB インスタンスのデプロイに変更する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html#Concepts.MultiAZ.Migrating)」を参照してください。

Aurora グローバルデータベースでは、修正の手順が異なります。Aurora グローバルデータベースに複数のアベイラビリティーゾーンを設定するには、DB クラスターを選択します。次に、**[アクション]** と **[リーダーの追加]** を選択し、複数の AZ を指定します。詳細については、「*Amazon Aurora ユーザーガイド*」の「[DB クラスターに Aurora レプリカを追加する](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-replicas-adding.html)」を参照してください。

## [RDS.16] Aurora DB クラスターでは、タグを DB スナップショットにコピーするように設定する必要があります
<a name="rds-16"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)

**カテゴリ:** 識別 > インベントリ

**重要度:** 低

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config rule:** `rds-cluster-copy-tags-to-snapshots-enabled` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、スナップショットの作成時に、DB クラスターのスナップショットにタグを自動的にコピーするように Amazon Aurora DB クラスターが設定されているかどうかをチェックします。スナップショットの作成時にクラスターのスナップショットにタグを自動的にコピーするように Aurora DB クラスターが設定されていない場合、コントロールは失敗します。

IT アセットの身分証明書とインベントリはガバナンスとセキュリティの重要な側面です。すべての Amazon Aurora DB クラスターを可視化することで、それらのセキュリティ体制を評価し、潜在的な弱点に対してアクションを起こせるようにする必要があります。Aurora DB スナップショットには、親 DB クラスターと同じタグが必要です。Amazon Aurora では、クラスターのすべてのタグをクラスターのスナップショットに自動的にコピーするように DB クラスターを設定できます。この設定を有効にすると、DB スナップショットが親 DB クラスターと同じタグを継承します。

### 修正
<a name="rds-16-remediation"></a>

タグを DB スナップショットに自動的にコピーするように Amazon Aurora DB クラスターを設定する方法については、「*Amazon Aurora ユーザーガイド*」の「[Amazon Aurora DB クラスターの変更](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Modifying.html)」を参照してください。

## [RDS.17] RDS DB インスタンスは、タグをスナップショットにコピーするように設定する必要があります
<a name="rds-17"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)

**カテゴリ:** 識別 > インベントリ

**重要度:** 低

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config rule:** `rds-instance-copy-tags-to-snapshots-enabled` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ:** なし

このコントロールは、スナップショットの作成時に、すべてのタグをスナップショットにコピーするように RDS DB インスタンスが構成されているかどうかをチェックします。

IT アセットの身分証明書とインベントリはガバナンスとセキュリティの重要な側面です。すべての RDS DB インスタンスを可視化することで、それらのセキュリティ体制を評価し、潜在的な弱点に対してアクションを起こせるようにする必要があります。スナップショットは、親 RDS データベースインスタンスと同じ方法でタグ付けする必要があります。この設定を有効にすると、スナップショットが親データベースインスタンスのタグを継承します。

### 修正
<a name="rds-17-remediation"></a>

RDS DB インスタンスのスナップショットにタグを自動的にコピーするには、「*Amazon RDS ユーザーガイド*」の「[Amazon RDS DB インスタンスを変更する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html)」を参照してください。**[タグをスナップショットへコピー]** を選択します。

## [RDS.18] RDS インスタンスは VPC 内にデプロイする必要があります
<a name="rds-18"></a>

**カテゴリ:** 保護 > セキュアなネットワーク設定 > VPC 内のリソース 

**重要度:** 高

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config rule:** `rds-deployed-in-vpc` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon RDS インスタンスが EC2-VPC にデプロイされているかどうかをチェックします。

VPC は、RDS リソースへのアクセスを保護するための多数のネットワークコントロールを提供します。これらのコントロールには、VPC エンドポイント、ネットワーク ACL、セキュリティグループが含まれます。これらのコントロールを利用するには、EC2-VPC 上に RDS インスタンスを作成することが推奨されます。

### 修正
<a name="rds-18-remediation"></a>

RDS インスタンスを VPC に移動する方法については、「*Amazon RDS ユーザーガイド*」の「[DB インスタンスの VPC の更新](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.VPC2VPC.html)」を参照してください。

## [RDS.19] 重大なクラスターイベントについて、既存の RDS イベント通知サブスクリプションを設定する必要があります
<a name="rds-19"></a>

**関連する要件:** NIST.800-53.r5 CA-7、NIST.800-53.r5 SI-2

**カテゴリ:** 検出 > 検出サービス > アプリケーションモニタリング

**重要度:** 低

**リソースタイプ :** `AWS::RDS::EventSubscription`

**AWS Config rule:** `rds-cluster-event-notifications-configured` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、データベースクラスターの既存の Amazon RDS イベントサブスクリプションに、次のソースタイプ、イベントカテゴリのキーと値のペアに対して有効な通知があるかどうかをチェックします。

```
DBCluster: ["maintenance","failure"]
```

アカウントに既存のイベントサブスクリプションがない場合、コントロールはパスします。

RDS イベント通知は Amazon SNS を使用して、RDS リソースの可用性または設定の変更を通知します。これらの通知により、迅速な対応が実現します。RDS イベント通知の詳細については、「Amazon RDS ユーザーガイド」の「[Amazon RDS イベント通知の使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html)」を参照してください。

### 修正
<a name="rds-19-remediation"></a>

RDS クラスターイベント通知にサブスクライブするには、「*Amazon RDS ユーザーガイド*」の「[Amazon RDS イベント通知にサブスクライブする](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Subscribing.html)」を参照してください。以下の値を使用します。


| フィールド | 値 | 
| --- | --- | 
|  ソースタイプ  |  クラスター  | 
|  含めるクラスター  |  すべてのクラスター  | 
|  含めるイベントカテゴリ  |  [Specific event categories] (特定のイベントカテゴリ) または [All event categories] (すべてのイベントカテゴリ) を選択します  | 

## [RDS.20] 重大なデータベースインスタンスイベントに対して、既存の RDS イベント通知サブスクリプションを設定する必要があります
<a name="rds-20"></a>

**関連する要件:** NIST.800-53.r5 CA-7、NIST.800-53.r5 SI-2、PCI DSS v4.0.1/11.5.2

**カテゴリ:** 検出 > 検出サービス > アプリケーションモニタリング

**重要度:** 低

**リソースタイプ :** `AWS::RDS::EventSubscription`

**AWS Config rule:** `rds-instance-event-notifications-configured` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、データベースインスタンスの既存の Amazon RDS イベントサブスクリプションに、次のソースタイプ、イベントカテゴリのキーと値のペアに対して有効な通知があるかどうかをチェックします。

```
DBInstance: ["maintenance","configuration change","failure"]
```

アカウントに既存のイベントサブスクリプションがない場合、コントロールはパスします。

RDS イベント通知は Amazon SNS を使用して、RDS リソースの可用性または設定の変更をユーザーに知らせます。これらの通知により、迅速な対応が実現します。RDS イベント通知の詳細については、「Amazon RDS ユーザーガイド」の「[Amazon RDS イベント通知の使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html)」を参照してください。

### 修正
<a name="rds-20-remediation"></a>

RDS インスタンスイベント通知にサブスクライブするには、「*Amazon RDS ユーザーガイド*」の「[Amazon RDS イベント通知にサブスクライブする](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Subscribing.html)」を参照してください。以下の値を使用します。


| フィールド | 値 | 
| --- | --- | 
|  ソースタイプ  |  インスタンス  | 
|  含めるインスタンス  |  すべてのインスタンス  | 
|  含めるイベントカテゴリ  |  [Specific event categories] (特定のイベントカテゴリ) または [All event categories] (すべてのイベントカテゴリ) を選択します  | 

## [RDS.21] 重大なデータベースパラメータグループイベントに対して RDS イベント通知サブスクリプションを設定する必要があります
<a name="rds-21"></a>

**関連する要件:** NIST.800-53.r5 CA-7、NIST.800-53.r5 SI-2、PCI DSS v4.0.1/11.5.2

**カテゴリ:** 検出 > 検出サービス > アプリケーションモニタリング

**重要度:** 低

**リソースタイプ :** `AWS::RDS::EventSubscription`

**AWS Config rule:** `rds-pg-event-notifications-configured` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ:** なし

このコントロールは、次のソースタイプ、イベントカテゴリのキーバリューペアに対して通知が有効になっている Amazon RDS イベントサブスクリプションが存在するかどうかをチェックします。アカウントに既存のイベントサブスクリプションがない場合、コントロールはパスします。

```
DBParameterGroup: ["configuration change"]
```

RDS イベント通知は Amazon SNS を使用して、RDS リソースの可用性または設定の変更をユーザーに知らせます。これらの通知により、迅速な対応が実現します。RDS イベント通知の詳細については、「Amazon RDS ユーザーガイド」の「[Amazon RDS イベント通知の使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html)」を参照してください。

### 修正
<a name="rds-21-remediation"></a>

RDS データベースパラメータグループイベント通知にサブスクライブするには、「*Amazon RDS ユーザーガイド*」の「[Amazon RDS イベント通知にサブスクライブする](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Subscribing.html)」を参照してください。以下の値を使用します。


| フィールド | 値 | 
| --- | --- | 
|  ソースタイプ  |  パラメータグループ  | 
|  含めるパラメータグループ  |  すべてのパラメータグループ  | 
|  含めるイベントカテゴリ  |  [Specific event categories] (特定のイベントカテゴリ) または [All event categories] (すべてのイベントカテゴリ) を選択します  | 

## [RDS.22] 重大なデータベースセキュリティグループイベントに対して RDS イベント通知サブスクリプションを設定する必要があります
<a name="rds-22"></a>

**関連する要件:** NIST.800-53.r5 CA-7、NIST.800-53.r5 SI-2、PCI DSS v4.0.1/11.5.2

**カテゴリ:** 検出 > 検出サービス > アプリケーションモニタリング

**重要度:** 低

**リソースタイプ :** `AWS::RDS::EventSubscription`

**AWS Config rule:** `rds-sg-event-notifications-configured` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ:** なし

このコントロールは、次のソースタイプ、イベントカテゴリのキーバリューペアに対して通知が有効になっている Amazon RDS イベントサブスクリプションが存在するかどうかをチェックします。アカウントに既存のイベントサブスクリプションがない場合、コントロールはパスします。

```
DBSecurityGroup: ["configuration change","failure"]
```

RDS イベント通知は Amazon SNS を使用して、RDS リソースの可用性または設定の変更をユーザーに知らせます。これらの通知により、迅速なレスポンスが可能になります。RDS イベント通知の詳細については、「Amazon RDS ユーザーガイド」の「[Amazon RDS イベント通知の使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html)」を参照してください。

### 修正
<a name="rds-22-remediation"></a>

RDS インスタンスイベント通知にサブスクライブするには、「*Amazon RDS ユーザーガイド*」の「[Amazon RDS イベント通知にサブスクライブする](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Subscribing.html)」を参照してください。以下の値を使用します。


| フィールド | 値 | 
| --- | --- | 
|  ソースタイプ  |  セキュリティグループ  | 
|  含めるセキュリティグループ  |  すべてのセキュリティグループ  | 
|  含めるイベントカテゴリ  |  [Specific event categories] (特定のイベントカテゴリ) または [All event categories] (すべてのイベントカテゴリ) を選択します  | 

## [RDS.23] RDS インスタンスはデータベースエンジンのデフォルトポートを使用しないようにする必要があります
<a name="rds-23"></a>

**関連する要件:** NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(5)

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 低

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config rule:** `rds-no-default-ports` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、RDS クラスターまたはインスタンスがデータベースエンジンのデフォルトポート以外のポートを使用しているかどうかをチェックします。RDS クラスターまたはインスタンスがデフォルトポートを使用する場合、このコントロールは失敗します。このコントロールは、クラスターの一部である RDS インスタンスには適用されません。

既知のポートを使用して RDS クラスターまたはインスタンスをデプロイすると、攻撃者はクラスターまたはインスタンスに関する情報を推測できる可能性があります。攻撃者は、この情報を他の情報と組み合わせ、RDS クラスターまたはインスタンスに接続したり、ユーザーのアプリケーションに関する追加情報を取得できます。

ポートを変更する場合は、古いポートへの接続に使用された既存の接続文字列も更新する必要があります。また、ユーザーは DB インスタンスのセキュリティグループをチェックして、新しいポートでの接続を許可するイングレスルールが確実に含まれていることを確認する必要があります。

### 修正
<a name="rds-23-remediation"></a>

既存の RDS DB インスタンスのデフォルトポートを変更するには、「*Amazon RDS ユーザーガイド*」の「[Amazon RDS DB インスタンスを変更する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html)」を参照してください。既存の RDS DB クラスターのデフォルトポートを変更するには、「*Amazon Aurora ユーザーガイド*」の「[コンソール、CLI、API を使用した DB クラスターの変更](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Modifying.html#Aurora.Modifying.Cluster)」を参照してください。**データベースポート**について、ポート値をデフォルト以外の値に変更します。

## [RDS.24] RDS データベースクラスターはカスタム管理者ユーザー名を使用する必要があります
<a name="rds-24"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、PCI DSS v4.0.1/2.2.2

**カテゴリ:** 識別 > リソース設定

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール :** `[rds-cluster-default-admin-check](https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-default-admin-check.html)`

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ:** なし

このコントロールは、Amazon RDS データベースクラスターが管理者ユーザーネームをデフォルト値から変更したかどうかをチェックします。このコントロールは、Neptune (Neptune DB) または docdb (DocumentDB) タイプのエンジンには適用されません。管理者ユーザーネームがデフォルト値に設定されている場合、このルールは失敗します。

Amazon RDS データベースを作成するときは、デフォルトの管理者ユーザーネームを一意の値に変更する必要があります。デフォルトのユーザーネームはパブリックナレッジであり、RDS データベースの作成時に変更する必要があります。デフォルトのユーザーネームを変更すると、意図しないアクセスのリスクが軽減されます。

### 修正
<a name="rds-24-remediation"></a>

Amazon RDS データベースクラスターに関連付けられている管理者ユーザーネームを変更するには、[新しい RDS データベースクラスターを作成](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.CreateInstance.html)し、データベースの作成時に、デフォルトの管理者ユーザーネームを変更します。

## [RDS.25] RDS データベースインスタンスはカスタム管理者ユーザーネームを使用する必要があります
<a name="rds-25"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、PCI DSS v4.0.1/2.2.2

**カテゴリ:** 識別 > リソース設定

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config ルール :** `[rds-instance-default-admin-check](https://docs.aws.amazon.com/config/latest/developerguide/rds-instance-default-admin-check.html)`

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ:** なし

このコントロールでは、Amazon Relational Database Service (Amazon RDS) のデータベースインスタンスの管理者ユーザーネームがデフォルト値から変更されたかどうかをチェックします。管理者ユーザーネームがデフォルト値に設定されている場合、このコントロールは失敗します。このコントロールは、Neptune (Neptune DB) または docdb (DocumentDB) タイプのエンジンと、クラスターの一部である RDS インスタンスには適用されません。

Amazon RDS データベースのデフォルトの管理ユーザーネームは、パブリックナレッジです。Amazon RDS データベースを作成するときは、意図しないアクセスのリスクを減らすために、デフォルトの管理ユーザーネームを一意の値に変更する必要があります。

### 修正
<a name="rds-25-remediation"></a>

RDS データベースインスタンスに関連付けられている管理ユーザーネームを変更するには、始めに[新しい RDS データベースインスタンスを作成します](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.html)。データベースの作成時に、デフォルトの管理ユーザーネームを変更します。

## [RDS.26] RDS DB インスタンスはバックアッププランで保護する必要があります
<a name="rds-26"></a>

**カテゴリ:** リカバリ > 耐障害性 > バックアップの有効化

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6、NIST.800-53.r5 CP-6(1)、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 CP-9、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-12、NIST.800-53.r5 SI-13(5)

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config ルール:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-resources-protected-by-backup-plan.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-resources-protected-by-backup-plan.html) ``

**スケジュールタイプ :** 定期的

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `backupVaultLockCheck`  |  パラメータが true に設定され、リソースが AWS Backup ボールトロックを使用する場合、コントロールは`PASSED`結果を生成します。  |  ブール値  |  `true` 、、または `false`  |  デフォルト値なし  | 

このコントロールは、Amazon RDS DB インスタンスがバックアッププランの対象かどうかを評価します。RDS DB インスタンスがバックアッププランの対象となっていない場合、このコントロールは失敗します。`backupVaultLockCheck` パラメータを に設定すると`true`、インスタンスが AWS Backup ロックされたボールトにバックアップされている場合にのみコントロールが成功します。

**注記**  
このコントロールは Neptune インスタンスと DocumentDB インスタンスを評価しません。また、クラスターのメンバーである RDS DB インスタンスも評価しません。

AWS Backup は、データのバックアップを一元化および自動化するフルマネージドバックアップサービスです AWS のサービス。を使用すると AWS Backup、バックアッププランと呼ばれるバックアップポリシーを作成できます。これらのプランを使用して、データのバックアップ頻度やバックアップを保持する期間など、バックアップ要件を定義できます。バックアッププランに RDS DB インスタンスを含めると、意図しない損失や削除からデータを保護できます。

### 修正
<a name="rds-26-remediation"></a>

RDS DB インスタンスを AWS Backup バックアッププランに追加するには、「 *AWS Backup デベロッパーガイド*[」の「バックアッププランへのリソースの割り当て](https://docs.aws.amazon.com/aws-backup/latest/devguide/assigning-resources.html)」を参照してください。

## [RDS.27] RDS DB クラスターは保管中に暗号化する必要があります
<a name="rds-27"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SI-7(6)

**カテゴリ:** 保護 > データ保護 > 保管中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-encrypted-at-rest.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-encrypted-at-rest.html) ``

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、RDS DB クラスターが保管中に暗号化されているかどうかをチェックします。RDS DB クラスターが保管中に暗号化されていない場合、コントロールは失敗します。

保管中のデータとは、永続的な不揮発性ストレージに任意の期間保管されているデータを指します。暗号化は、このようなデータの機密性を保護し、権限のないユーザーがデータにアクセスするリスクを低減するのに役立ちます。RDS DB クラスターを暗号化することで、データとメタデータを不正アクセスから保護します。また、本番稼働用ファイルシステムにおける保管中のデータの暗号化に関するコンプライアンス要件も満たします。

### 修正
<a name="rds-27-remediation"></a>

RDS DB クラスターを作成するときに、保管中の暗号化を有効にできます。クラスターを作成した後で暗号化設定を変更することはできません。詳細については、「*Amazon Aurora ユーザーガイド*」の「[Amazon Aurora DB クラスターの暗号化](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Overview.Encryption.html#Overview.Encryption.Enabling)」を参照してください。

## [RDS.28] RDS DB クラスターにはタグを付ける必要があります
<a name="rds-28"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config rule:**`tagged-rds-dbcluster` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon RDS DB クラスターにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。DB クラスターにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、DB クラスターにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。IAM エンティティ (ユーザーまたはロール) と AWS リソースにタグをアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="rds-28-remediation"></a>

RDS DB クラスターにタグを追加するには、*「Amazon RDS ユーザーガイド*」の「[Amazon RDS リソースのタグ付け](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html)」を参照してください。

## [RDS.29] RDS DB クラスタースナップショットにはタグを付ける必要があります
<a name="rds-29"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::RDS::DBClusterSnapshot`

**AWS Config rule:**`tagged-rds-dbclustersnapshot` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon RDS DB クラスタースナップショットに、パラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。DB クラスタースナップショットにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、DB クラスタースナップショットにキーがタグ付けされていない場合に失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。IAM エンティティ (ユーザーまたはロール) と AWS リソースにタグをアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="rds-29-remediation"></a>

RDS DB クラスタースナップショットにタグを追加するには、「*Amazon RDS ユーザーガイド*」の「[Amazon RDS リソースのタグ付け](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html)」を参照してください。

## [RDS.30] RDS DB インスタンスにはタグを付ける必要があります
<a name="rds-30"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config rule:**`tagged-rds-dbinstance` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon RDS DB インスタンスにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。DB インスタンスにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、DB インスタンスにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。IAM エンティティ (ユーザーまたはロール) と AWS リソースにタグをアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="rds-30-remediation"></a>

RDS DB インスタンスにタグを追加するには、「*Amazon RDS ユーザーガイド*」の「[Amazon RDS リソースのタグ付け](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html)」を参照してください。

## [RDS.31] RDS DB セキュリティグループにはタグを付ける必要があります
<a name="rds-31"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::RDS::DBSecurityGroup`

**AWS Config rule:**`tagged-rds-dbsecuritygroup` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon RDS DB セキュリティグループに、パラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。DB セキュリティグループにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、DB セキュリティグループがキーでタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。IAM エンティティ (ユーザーまたはロール) と AWS リソースにタグをアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、『』の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="rds-31-remediation"></a>

RDS DB セキュリティグループにタグを追加するには、「*Amazon RDS ユーザーガイド*」の「[Amazon RDS リソースのタグ付け](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html)」を参照してください。

## [RDS.32] RDS DB スナップショットにはタグを付ける必要があります
<a name="rds-32"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::RDS::DBSnapshot`

**AWS Config rule:**`tagged-rds-dbsnapshot` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon RDS DB スナップショットにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。DB スナップショットにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、DB スナップショットにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。IAM エンティティ (ユーザーまたはロール) と AWS リソースにタグをアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="rds-32-remediation"></a>

RDS スナップショットにタグを追加するには、「*Amazon RDS ユーザーガイド*」の「[Amazon RDS リソースのタグ付け](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html)」を参照してください。

## [RDS.33] RDS DB サブネットグループにはタグを付ける必要があります
<a name="rds-33"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::RDS::DBSubnetGroup`

**AWS Config rule:**`tagged-rds-dbsubnetgroups` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon RDS DB サブネットグループに、パラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。DB サブネットグループにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、DB サブネットグループがキーでタグ付けされていない場合に失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。IAM エンティティ (ユーザーまたはロール) と AWS リソースにタグをアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="rds-33-remediation"></a>

RDS DB サブネットグループにタグを追加するには、「*Amazon RDS ユーザーガイド*」の「[Amazon RDS リソースのタグ付け](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html)」を参照してください。

## [RDS.34] Aurora MySQL DB クラスターでは、監査ログを CloudWatch Logs に発行する必要があります
<a name="rds-34"></a>

**関連する要件:** NIST.800-53.r5 AC-2(4)、NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AC-6(9)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4(20)、NIST.800-53.r5 SI-7(8)、PCI DSS v4.0.1/10.2.1

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-aurora-mysql-audit-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-aurora-mysql-audit-logging-enabled.html) ``

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon Aurora MySQL DB クラスターが監査ログを Amazon CloudWatch Logs に発行するように設定されているかどうかをチェックします。クラスターが監査ログを CloudWatch Logs に発行するように設定されていない場合、コントロールは失敗します。コントロールは Aurora Serverless v1 DB クラスターの検出結果を生成しません。

監査ログには、ログイン試行、データ変更、スキーマ変更、セキュリティとコンプライアンスの目的で監査の対象となる可能性のあるその他のイベントなど、データベースアクティビティのレコードが記録されます。Aurora MySQL DB クラスターを Amazon CloudWatch Logs のロググループに発行するように設定すると、ログデータのリアルタイム分析を実行できます。CloudWatch Logs は、耐久性の高いストレージにログを保持します。また、CloudWatch でのアラームの作成やメトリクスの表示が可能です。

**注記**  
CloudWatch Logs に監査ログを発行する別の方法は、高度な監査を有効にし、クラスターレベルの DB パラメータ `server_audit_logs_upload` を `1` に設定することです。`server_audit_logs_upload parameter` のデフォルト値は `0` です。ただし、このコントロールを渡すには、代わりに以下の修正手順を使用することをおすすめします。

### 修正
<a name="rds-34-remediation"></a>

Aurora MySQL DB のクラスターの監査ログを CloudWatch Logs に発行するには、「**Amazon Aurora ユーザーガイド」の「[Amazon CloudWatch Logs への Amazon Aurora MySQL ログの発行](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.CloudWatch.html)」を参照してください。

## [RDS.35] RDS DB クラスターは自動マイナーバージョンアップグレードを有効にする必要があります
<a name="rds-35"></a>

**関連する要件:** NIST.800-53.r5 SI-2、NIST.800-53.r5 SI-2(2)、NIST.800-53.r5 SI-2(4)、NIST.800-53.r5 SI-2(5)、PCI DSS v4.0.1/6.3.3

**カテゴリ:** 特定 > 脆弱性、パッチ、バージョン管理

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-auto-minor-version-upgrade-enable.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-auto-minor-version-upgrade-enable.html) ``

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon RDS マルチ AZ DB クラスターの自動マイナーバージョンアップグレードが有効になっているかどうかを確認します。マルチ AZ DB クラスターで自動マイナーバージョンアップグレードが有効になっていない場合、コントロールは失敗します。

RDS では、マルチ AZ DB クラスターを最新の状態に保つことができるように、マイナーバージョンの自動アップグレードを実行します。マイナーバージョンには、ソフトウェアの新機能、バグ修正、セキュリティパッチ、およびパフォーマンスの向上を含む可能性があります。RDS データベースクラスターでマイナーバージョンの自動アップグレードを有効にすると、新しいバージョンが利用可能になった時点で、クラスターとクラスター内のインスタンスがマイナーバージョンへ自動更新を受け取ります。更新はメンテナンスの時間帯に自動で適用されます。

### 修正
<a name="rds-35-remediation"></a>

マルチ AZ DB クラスターでマイナーバージョンの自動アップグレードを有効にするには、「*Amazon RDS ユーザーガイド*」の「[マルチ AZ DB クラスターの変更](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/modify-multi-az-db-cluster.html)」を参照してください。

## [RDS.36] RDS for PostgreSQL DB は CloudWatch Logs にログを発行する必要があります
<a name="rds-36"></a>

**関連する要件:** PCI DSS v4.0.1/10.4.2

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-postgresql-logs-to-cloudwatch.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-postgresql-logs-to-cloudwatch.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `logTypes`  |  CloudWatch Logs に発行するログタイプのカンマ区切りリスト  |  StringList  |  カスタマイズ不可  |  `postgresql`  | 

このコントロールは、Amazon RDS for PostgreSQL DB インスタンスがログを Amazon CloudWatch Logs に発行するように設定されているかどうかをチェックします。PostgreSQL DB インスタンスが、 `logTypes` パラメータに記載されているログタイプを CloudWatch Logs に発行するように設定されていない場合、コントロールは失敗します。

データベースログ記録は、RDS インスタンスに対して行われたリクエストの詳細な記録を提供します。PostgreSQL は、管理者に役立つ情報を含むイベントログを生成します。これらのログを CloudWatch Logs に発行すると、ログ管理が一元化され、ログデータのリアルタイム分析の実行に役立ちます。CloudWatch Logs は、耐久性の高いストレージにログを保持します。また、CloudWatch でのアラームの作成やメトリクスの表示が可能です。

### 修正
<a name="rds-36-remediation"></a>

PostgreSQL DB インスタンスログを CloudWatch Logs に発行するには、「*Amazon RDS ユーザーガイド*」の「[Amazon CloudWatch Logs への PostgreSQL ログの発行](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.PostgreSQL.html#USER_LogAccess.Concepts.PostgreSQL.PublishtoCloudWatchLogs)」を参照してください。

## [RDS.37] Aurora PostgreSQL DB クラスターでは、ログを CloudWatch Logs に発行する必要があります
<a name="rds-37"></a>

**関連する要件:** PCI DSS v4.0.1/10.4.2

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-aurora-postgresql-logs-to-cloudwatch.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-aurora-postgresql-logs-to-cloudwatch.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon Aurora PostgreSQL DB クラスターがログを Amazon CloudWatch Logs に発行するように設定されているかどうかをチェックします。Aurora PostgreSQL DB クラスターが PostgreSQL ログを CloudWatch Logs に発行するように設定されていない場合、コントロールは失敗します。

データベースログ記録は、RDS クラスターに対して行われたリクエストの詳細な記録を提供します。Aurora PostgreSQL は、管理者に役立つ情報を含むイベントログを生成します。これらのログを CloudWatch Logs に発行すると、ログ管理が一元化され、ログデータのリアルタイム分析の実行に役立ちます。CloudWatch Logs は、耐久性の高いストレージにログを保持します。また、CloudWatch でのアラームの作成やメトリクスの表示が可能です。

### 修正
<a name="rds-37-remediation"></a>

Aurora PostgreSQL DB クラスターの監査ログを CloudWatch Logs に発行するには、「*Amazon Aurora ユーザーガイド*」の「[Amazon CloudWatch Logs への Amazon Aurora PostgreSQL ログの発行](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.CloudWatch.html)」を参照してください。

## [RDS.38] RDS for PostgreSQL DB インスタンスは転送中に暗号化する必要があります
<a name="rds-38"></a>

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-postgres-instance-encrypted-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-postgres-instance-encrypted-in-transit.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、 Amazon RDS for PostgreSQL データベース (DB) インスタンスへの接続が転送中に暗号化されているかどうかを確認します。インスタンスに関連付けられたパラメータグループの `rds.force_ssl` パラメータが `0` (オフ) に設定されている場合、コントロールは失敗します。このコントロールは、DB クラスターの一部である RDS DB インスタンスは評価しません。

転送中のデータとは、クラスター内のノード間やクラスターとアプリケーション間など、ある場所から別の場所に移動するデータを指します。データはインターネット内またはプライベートネットワーク内を移動する場合があります。転送中のデータを暗号化することで、権限のないユーザーがネットワークトラフィックを盗聴するリスクが軽減されます。

### 修正
<a name="rds-38-remediation"></a>

RDS for PostgreSQL DB インスタンスへのすべての接続に SSL を使用するよう要求するには、「*Amazon RDS ユーザーガイド*」の「[PostgreSQL DB インスタンスで SSL を使用する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Concepts.General.SSL.html)」を参照してください。

## [RDS.39] RDS for MySQL DB インスタンスは転送中に暗号化する必要があります
<a name="rds-39"></a>

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-mysql-instance-encrypted-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-mysql-instance-encrypted-in-transit.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、 Amazon RDS for MySQL データベース (DB) インスタンスへの接続が転送中に暗号化されているかどうかを確認します。インスタンスに関連付けられたパラメータグループの `rds.require_secure_transport` パラメータが `0` (オフ) に設定されている場合、コントロールは失敗します。このコントロールは、DB クラスターの一部である RDS DB インスタンスは評価しません。

転送中のデータとは、クラスター内のノード間やクラスターとアプリケーション間など、ある場所から別の場所に移動するデータを指します。データはインターネット内またはプライベートネットワーク内を移動する場合があります。転送中のデータを暗号化することで、権限のないユーザーがネットワークトラフィックを盗聴するリスクが軽減されます。

### 修正
<a name="rds-39-remediation"></a>

RDS for MySQL DB インスタンスへのすべての接続に SSL を使用するよう要求するには、「*Amazon RDS ユーザーガイド*」の「[Amazon RDS 上の MySQL DB インスタンスの SSL/TLS サポート](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Concepts.SSLSupport.html)」を参照してください。

## [RDS.40] RDS for SQL Server DB インスタンスは CloudWatch Logs にログを発行する必要があります
<a name="rds-40"></a>

**関連する要件:** NIST.800-53.r5 AC-2(4)、NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AC-6(9)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4(20)、NIST.800-53.r5 SI-7(8)

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-sql-server-logs-to-cloudwatch.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-sql-server-logs-to-cloudwatch.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `logTypes`  |  RDS for SQL Server DB インスタンスが CloudWatch Logs に発行するように設定する必要があるログのタイプのリスト。DB インスタンスがリストで指定されたタイプのログを発行するように設定されていない場合、このコントロールは失敗します。  |  EnumList (最大 2 項目)  |  `agent`, `error`  |  `agent`, `error`  | 

このコントロールは、Amazon RDS for Microsoft SQL Server DB インスタンスがログを Amazon CloudWatch Logs に発行するように設定されているかどうかをチェックします。RDS for SQL Server DB インスタンスがログを CloudWatch Logs に発行するように設定されていない場合、コントロールは失敗します。必要に応じて、DB インスタンスが発行するように設定する必要があるログのタイプを指定できます。

データベースログ記録は、Amazon RDS DB インスタンスに対して行われたリクエストの詳細な記録を提供します。ログを CloudWatch Logs に発行すると、ログ管理が一元化され、ログデータのリアルタイム分析の実行に役立ちます。CloudWatch Logs は、耐久性の高いストレージにログを保持します。さらに、これを使用して、エラーログに記録される頻繁な再起動など、発生する可能性のある特定のエラーのアラームを作成できます。同様に、SQL エージェントジョブに関連する SQL Server エージェントログに記録されるエラーまたは警告のアラームを作成できます。

### 修正
<a name="rds-40-remediation"></a>

RDS for SQL Server DB インスタンスでログを CloudWatch Logs に発行する方法については、「*Amazon Relational Database Service ユーザーガイド*」の「[Amazon RDS for Microsoft SQL Server データベースのログファイル](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.SQLServer.html)」を参照してください。

## [RDS.41] RDS for SQL Server DB インスタンスは転送中に暗号化する必要があります
<a name="rds-41"></a>

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-sqlserver-encrypted-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-sqlserver-encrypted-in-transit.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、Amazon RDS for Microsoft SQL Server DB インスタンスへの接続が転送中に暗号化されているかどうかをチェックします。インスタンスに関連付けられたパラメータグループの `rds.force_ssl` パラメータが `0 (off)` に設定されている場合、コントロールは失敗します。

転送中のデータとは、DB クラスター内のノード間や DB クラスターとクライアントアプリケーション間など、ある場所から別の場所に移動するデータを指します。データはインターネット内またはプライベートネットワーク内を移動する可能性があります。転送中のデータを暗号化することで、権限のないユーザーがネットワークトラフィックを盗聴するリスクが軽減されます。

### 修正
<a name="rds-41-remediation"></a>

Microsoft SQL Server を実行している Amazon RDS DB インスタンスへの接続で SSL/TLS を有効にする方法については、「*Amazon Relational Database Service ユーザーガイド*」の「[Microsoft SQL Server DB インスタンスでの SSL の使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html)」を参照してください。

## [RDS.42] RDS for MariaDB DB インスタンスは CloudWatch Logs にログを発行する必要があります
<a name="rds-42"></a>

**関連する要件:** NIST.800-53.r5 AC-2(4)、NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AC-6(9)、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4(20)、NIST.800-53.r5 SI-7(8)

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/mariadb-publish-logs-to-cloudwatch-logs.html](https://docs.aws.amazon.com/config/latest/developerguide/mariadb-publish-logs-to-cloudwatch-logs.html)

**スケジュールタイプ :** 定期的

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `logTypes`  |  MariaDB DB インスタンスが CloudWatch Logs に発行するように設定する必要があるログのタイプのリスト。DB インスタンスがリストで指定されたタイプのログを発行するように設定されていない場合、コントロールは `FAILED` 検出結果を生成します。  |  EnumList (最大 4 項目)  |  `audit`, `error`, `general`, `slowquery`  |  `audit, error`  | 

このコントロールは、Amazon RDS for MariaDB DB インスタンスが特定のタイプのログを Amazon CloudWatch Logs に発行するように設定されているかどうかをチェックします。MariaDB DB インスタンスがログを CloudWatch Logs に発行するように設定されていない場合、コントロールは失敗します。必要に応じて、MariaDB DB インスタンスが発行するように設定する必要があるログのタイプを指定できます。

データベースログ記録は、Amazon RDS for MariaDB DB インスタンスに対して行われたリクエストの詳細な記録を提供します。ログを Amazon CloudWatch Logs に発行すると、ログ管理が一元化され、ログデータのリアルタイム分析の実行に役立ちます。さらに、CloudWatch Logs はログを耐久性を持つストレージに保存し、セキュリティ、アクセス、可用性のレビューと監査に対応できるようにします。CloudWatch Logs では、アラームの作成やメトリクスの確認も可能です。

### 修正
<a name="rds-42-remediation"></a>

ログを Amazon CloudWatch Logs に発行するように Amazon RDS for MariaDB DB インスタンスを設定する方法については、「*Amazon Relational Database Service ユーザーガイド*」の「[MariaDB ログを Amazon CloudWatch Logs に発行する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MariaDB.PublishtoCloudWatchLogs.html)」を参照してください。

## [RDS.43] RDS DB プロキシの接続には TLS 暗号化が必要です
<a name="rds-43"></a>

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBProxy`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-proxy-tls-encryption.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-proxy-tls-encryption.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、Amazon RDS DB Proxy がプロキシと基盤となる RDS DB インスタンス間のすべての接続に TLS を要求するかどうかをチェックします。プロキシが、プロキシと RDS DB インスタンス間のすべての接続に TLS を要求しない場合、コントロールは失敗します。

Amazon RDS Proxy は、クライアントアプリケーションと基盤となる RDS DB インスタンスの間に別のセキュリティ層を追加します。例えば、基盤となる DB インスタンスが古いバージョンの TLS をサポートしている場合でも、TLS 1.3 を使用して RDS Proxy に接続できます。RDS Proxy を使用すると、データベースアプリケーションに強力な認証要件を適用できます。

### 修正
<a name="rds-43-remediation"></a>

TLS を要求するように Amazon RDS Proxy の設定を変更する方法については、「*Amazon Relational Database Service ユーザーガイド*」の「[RDS Proxy の変更](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy-modifying-proxy.html)」を参照してください。

## [RDS.44] RDS for MariaDB DB インスタンスは転送中に暗号化する必要があります
<a name="rds-44"></a>

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-mariadb-instance-encrypted-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-mariadb-instance-encrypted-in-transit.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、Amazon RDS for MariaDB DB インスタンスへの接続が転送中に暗号化されているかどうかをチェックします。DB インスタンスに関連付けられた DB パラメータグループが同期していない場合、またはそのパラメータグループの `require_secure_transport` パラメータが `ON` に設定されていない場合、コントロールは失敗します。

**注記**  
このコントロールは、バージョン 10.5 より前の MariaDB バージョンを使用する Amazon RDS DB インスタンスは評価しません。`require_secure_transport` パラメータは、MariaDB バージョン 10.5 以降でのみサポートされます。

転送中のデータとは、DB クラスター内のノード間や DB クラスターとクライアントアプリケーション間など、ある場所から別の場所に移動するデータを指します。データはインターネット内またはプライベートネットワーク内を移動する可能性があります。転送中のデータを暗号化することで、権限のないユーザーがネットワークトラフィックを盗聴するリスクが軽減されます。

### 修正
<a name="rds-44-remediation"></a>

Amazon RDS for MariaDB DB インスタンスへの接続で SSL/TLS を有効にする方法については、「*Amazon Relational Database Service ユーザーガイド*」の「[MariaDB DB インスタンスへのすべての接続に SSL/TLS を要求する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mariadb-ssl-connections.require-ssl.html)」を参照してください。

## [RDS.45] Aurora MySQL DB クラスターでは、監査ログ記録が有効になっている必要があります
<a name="rds-45"></a>

**関連する要件:** NIST.800-53.r5 AC-2(4)、NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AC-6(9)、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4(20)、NIST.800-53.r5 SI-7(8)

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/aurora-mysql-cluster-audit-logging.html](https://docs.aws.amazon.com/config/latest/developerguide/aurora-mysql-cluster-audit-logging.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、Amazon Aurora MySQL DB クラスターで監査ログ記録が有効になっているかどうかをチェックします。DB クラスターに関連付けられた DB パラメータグループが同期していない場合や、`server_audit_logging` パラメータが `1` に設定されていない場合、または `server_audit_events` パラメータが空の値に設定されている場合、コントロールは失敗します。

データベースログは、セキュリティとアクセス監査に役立ち、可用性の問題を診断するのに役立ちます。監査ログには、ログイン試行、データ変更、スキーマ変更、セキュリティとコンプライアンスの目的で監査の対象となる可能性のあるその他のイベントなど、データベースアクティビティのレコードが記録されます。

### 修正
<a name="rds-45-remediation"></a>

Amazon Aurora MySQL DB クラスターのログ記録を有効にする方法については、「*Amazon Aurora ユーザーガイド*」の「[Amazon CloudWatch Logs への Amazon Aurora MySQL ログの発行](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.CloudWatch.html)」を参照してください。

## [RDS.46] RDS DB インスタンスは、インターネットゲートウェイへのルートを持つパブリックサブネットにデプロイすべきではありません
<a name="rds-46"></a>

**カテゴリ:** 保護 > セキュアなネットワーク設定 > パブリックアクセス不可のリソース

**重要度:** 高

**リソースタイプ :** `AWS::RDS::DBInstance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-instance-subnet-igw-check.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-instance-subnet-igw-check.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、Amazon RDS DB インスタンスがインターネットゲートウェイへのルートがあるパブリックサブネットにデプロイされているかどうかをチェックします。RDS DB インスタンスがインターネットゲートウェイへのルートがあるサブネットにデプロイされていて、送信先が `0.0.0.0/0` または `::/0` に設定されている場合、コントロールは失敗します。

Amazon RDS リソースをプライベートサブネットにプロビジョニングすることで、RDS リソースがパブリックインターネットからインバウンドトラフィックを受信しないようにし、RDS DB インスタンスへの意図しないアクセスを防ぐことができます。RDS リソースがインターネットに開放されているパブリックサブネットにプロビジョニングされている場合、データ流出などのリスクに対して脆弱になる可能性があります。

### 修正
<a name="rds-46-remediation"></a>

Amazon RDS DB インスタンスのプライベートサブネットのプロビジョニングの詳細については、「*Amazon Relational Database Service ユーザーガイド*」の「[VPC 内の DB インスタンスの使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html)」を参照してください。

## [RDS.47] タグを DB スナップショットにコピーするように RDS for PostgreSQL DB クラスターを設定する必要があります
<a name="rds-47"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-pgsql-cluster-copy-tags-to-snapshot-check.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-pgsql-cluster-copy-tags-to-snapshot-check.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、スナップショットの作成時に、DB クラスターのスナップショットにタグを自動的にコピーするように Amazon RDS for PostgreSQL DB クラスターが設定されているかどうかをチェックします。RDS for PostgreSQL DB クラスターで `CopyTagsToSnapshot` パラメータが `false` に設定されている場合、コントロールは失敗します。

DB スナップショットにタグをコピーすることで、バックアップリソース全体で適切なリソース追跡、ガバナンス、コスト配分を維持できます。これにより、アクティブなデータベースとそのスナップショットの両方で、一貫したリソース識別、アクセスコントロール、コンプライアンスモニタリングが可能になります。スナップショットに適切にタグ付けすることで、バックアップリソースがソースデータベースと同じメタデータを継承するようになり、セキュリティ運用が向上します。

### 修正
<a name="rds-47-remediation"></a>

タグを DB スナップショットに自動的にコピーするように Amazon RDS for PostgreSQL DB クラスターを設定する方法については、「*Amazon Relational Database Service ユーザーガイド*」の「[Amazon RDS リソースのタグ付け](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html)」を参照してください。

## [RDS.48] タグを DB スナップショットにコピーするように RDS for MySQL DB クラスターを設定する必要があります
<a name="rds-48"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-mysql-cluster-copy-tags-to-snapshot-check.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-mysql-cluster-copy-tags-to-snapshot-check.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、スナップショットの作成時に、DB クラスターのスナップショットにタグを自動的にコピーするように Amazon RDS for MySQL DB クラスターが設定されているかどうかをチェックします。RDS for MySQL DB クラスターで `CopyTagsToSnapshot` パラメータが `false` に設定されている場合、コントロールは失敗します。

DB スナップショットにタグをコピーすることで、バックアップリソース全体で適切なリソース追跡、ガバナンス、コスト配分を維持できます。これにより、アクティブなデータベースとそのスナップショットの両方で、一貫したリソース識別、アクセスコントロール、コンプライアンスモニタリングが可能になります。スナップショットに適切にタグ付けすることで、バックアップリソースがソースデータベースと同じメタデータを継承するようになり、セキュリティ運用が向上します。

### 修正
<a name="rds-48-remediation"></a>

タグを DB スナップショットに自動的にコピーするように Amazon RDS for MySQL DB クラスターを設定する方法については、「*Amazon Relational Database Service ユーザーガイド*」の「[Amazon RDS リソースのタグ付け](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html)」を参照してください。

## [RDS.50] RDS DB クラスターには十分なバックアップ保持期間を設定する必要があります
<a name="rds-50"></a>

**カテゴリ:** リカバリ > 耐障害性 > バックアップの有効化 

**重要度:** 中

**リソースタイプ :** `AWS::RDS::DBCluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-backup-retention-check.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-backup-retention-check.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `minimumBackupRetentionPeriod`  |  コントロールがチェックする最小バックアップ保持期間  |  整数  |  `7`～`35`  |  `7`  | 

このコントロールは、RDS DB クラスターに最小バックアップ保持期間があるかどうかをチェックします。バックアップ保持期間が指定されたパラメータ値より短い場合、コントロールは失敗します。カスタムパラメータ値を指定しない限り、Security Hub はデフォルト値の 7 日を使用します。

このコントロールは、RDS DB クラスターに最小バックアップ保持期間があるかどうかをチェックします。バックアップ保持期間が指定されたパラメータ値より短い場合、コントロールは失敗します。顧客のパラメータ値を指定しない限り、Security Hub はデフォルト値の 7 日を使用します。このコントロールは、Aurora DB クラスター、DocumentDB クラスター、NeptuneDB クラスターなど、すべてのタイプの RDS DB クラスターに適用されます。

### 修正
<a name="rds-50-remediation"></a>

RDS DB クラスターのバックアップ保持期間を設定するには、クラスター設定を変更し、バックアップ保持期間を少なくとも 7 日間 (またはコントロールパラメータで指定された値) に設定します。詳細な手順については、*Amazon Relational Database Service ユーザーガイド*」の[「バックアップ保持期間](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.BackupRetention.html)」を参照してください。Aurora DB クラスターについては、[「Aurora 用 Amazon Aurora ユーザーガイド」の「Aurora DB クラスターのバックアップと復元の概要](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Backups.html)」を参照してください。 **他のタイプの DB クラスター (DocumentDB クラスターなど) については、クラスターのバックアップ保持期間を更新する方法については、対応するサービスユーザーガイドを参照してください。

# Amazon Redshift の Security Hub CSPM コントロール
<a name="redshift-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon Redshift サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [PCI.Redshift.1] Amazon Redshift クラスターはパブリックアクセスを禁止する必要があります
<a name="redshift-1"></a>

**関連する要件:** NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)、PCI DSS v3.2.1/1.2.1、PCI DSS v3.2.1/1.3.1、PCI DSS v3.2.1/1.3.2、PCI DSS v3.2.1/1.3.4、PCI DSS v3.2.1/1.3.6、PCI DSS v4.0.1/1.4.4

**カテゴリ:** 保護 > セキュアなネットワーク設定 > パブリックアクセス不可のリソース

**重要度:** 非常事態

**リソースタイプ :** `AWS::Redshift::Cluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-public-access-check.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-public-access-check.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ:** なし 

このコントロールは、Amazon Redshift クラスターがパブリックにアクセス可能かどうかをチェックします。このコントロールは、クラスター設定項目の `PubliclyAccessible` フィールドを評価します。

Amazon Redshift クラスター設定の `PubliclyAccessible` 属性は、クラスターがパブリックにアクセス可能かどうかを示します。クラスターが `PubliclyAccessible` を `true` に設定して構成されている場合、パブリックに解決可能な DNS 名を持つインターネット向けインスタンスであり、パブリック IP アドレスに解決されます。

クラスターがパブリックにアクセスできない場合、プライベート IP アドレスに解決される DNS 名を持つ内部インスタンスです。クラスターをパブリックにアクセスさせる意図がない限り、クラスターは `PubliclyAccessible` を `true` に設定しないでください。

### 修正
<a name="redshift-1-remediation"></a>

Amazon Redshift クラスターを更新してパブリックアクセスを無効にするには、「*Amazon Redshift 管理ガイド*」の「[クラスターの変更](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-console.html#modify-cluster)」を参照してください。[**Publicly Accessible**] を [**No**] に設定します。

## [Redshift.2] Amazon Redshift クラスターへの接続は転送中に暗号化する必要があります
<a name="redshift-2"></a>

**関連する要件:** NIST.800-53.r5 AC-4、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-23、NIST.800-53.r5 SC-23(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-8、NIST.800-53.r5 SC-8(1)、NIST.800-53.r5 SC-8(2)、PCI DSS v4.0.1/4.2.1

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ:** `AWS::Redshift::Cluster` `AWS::Redshift::ClusterParameterGroup`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-require-tls-ssl.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-require-tls-ssl.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ:** なし

このコントロールは、Amazon Redshift クラスターへの接続において、転送中に暗号化を使用する必要があるかどうかをチェックします。Amazon Redshift クラスターパラメータ `require_SSL` が `True` に設定されていない場合、チェックは失敗します。

TLS を使用すると、潜在的な攻撃者が中間者攻撃または同様の攻撃を使用してネットワークトラフィックを盗聴または操作することを防止できます。TLS 経由の暗号化された接続のみを許可する必要があります。転送中のデータの暗号化は、パフォーマンスに影響する可能性があります。TLS のパフォーマンスプロファイルと TLS の影響を把握するには、この機能を使用してアプリケーションをテストする必要があります。

### 修正
<a name="redshift-2-remediation"></a>

Amazon Redshift パラメータグループを更新して暗号化を要求するには、「*Amazon Redshift 管理ガイド*」の「[パラメータグループの変更](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-parameter-groups-console.html#parameter-group-modify)」を参照してください。`require_ssl`を **True** に設定します。

## [Redshift.3] Amazon Redshift クラスターでは、自動スナップショットが有効になっている必要があります
<a name="redshift-3"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6、NIST.800-53.r5 CP-6(1)、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 CP-9、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SI-13(5)

**カテゴリ:** リカバリ > 耐障害性 > バックアップの有効化 

**重要度:** 中

**リソースタイプ :** `AWS::Redshift::Cluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-backup-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-backup-enabled.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `​MinRetentionPeriod`  |  最小スナップショット保持期間 (日数)  |  整数  |  `7`～`35`  |  `7`  | 

このコントロールは、Amazon Redshift クラスターで自動スナップショットが有効になっているかどうか、および保持期間が指定された時間枠以上であるかどうかをチェックします。クラスターの自動スナップショットが有効になっていない場合や、保持期間が指定された時間枠未満の場合、コントロールは失敗します。スナップショット保持期間にカスタムパラメータ値を指定しない限り、Security Hub CSPM はデフォルト値の 7 日を使用します。

バックアップは、セキュリティインシデントからより迅速に復元するために役立ちます。これにより、システムの耐障害性が強化されます。Amazon Redshift は、デフォルトで定期的にスナップショットを作成します。このコントロールは、自動スナップショットが有効で、少なくとも 7 日間保持されているかどうかをチェックします。Amazon Redshift の自動スナップショットの詳細については、「*Amazon Redshift 管理ガイド*」の「[自動スナップショット](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-snapshots.html#about-automated-snapshots)」を参照してください。

### 修正
<a name="redshift-3-remediation"></a>

Amazon Redshift クラスターのスナップショット保持期間を更新するには、「*Amazon Redshift 管理ガイド*」の「[クラスターの変更](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-console.html#modify-cluster)」を参照してください。**[Backup]** (バックアップ) の場合、**[Snapshot retention]** (スナップショットの保持) を 7 以上の値に設定します。

## [Redshift.4] Amazon Redshift クラスターでは、監査ログ記録が有効になっている必要があります
<a name="redshift-4"></a>

**関連する要件:** NIST.800-53.r5 AC-2(4)、NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AC-6(9)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4(20)、NIST.800-53.r5 SI-7(8)、PCI DSS v4.0.1/10.2.1

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::Redshift::Cluster`

**AWS Config rule:** `redshift-cluster-audit-logging-enabled` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :** なし 

このコントロールは、Amazon Redshift クラスターで監査ログ記録が有効になっているかどうかをチェックします。

Amazon Redshift 監査ログ記録は、ユーザーのクラスター内の接続とユーザーアクティビティに関する追加情報を提供します。このデータは、Amazon S3 内で保存および保護することができ、セキュリティ監査や調査に役立ちます。詳細については、「*Amazon Redshift 管理ガイド*」の「[データベース監査ログ作成](https://docs.aws.amazon.com/redshift/latest/mgmt/db-auditing.html)」を参照してください。

### 修正
<a name="redshift-4-remediation"></a>

Amazon Redshift クラスターの監査ログを設定するには、「*Amazon Redshift 管理ガイド*」の「[コンソールを使用して監査を設定する](https://docs.aws.amazon.com/redshift/latest/mgmt/db-auditing-console.html)」を参照してください。

## [Redshift.6] Amazon Redshift でメジャーバージョンへの自動アップグレードが有効になっている必要があります
<a name="redshift-6"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 CP-9、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-2、NIST.800-53.r5 SI-2(2)、NIST.800-53.r5 SI-2(4)、NIST.800-53.r5 SI-2(5)

**カテゴリ:** 特定 > 脆弱性、パッチ、バージョン管理

**重要度:** 中

**リソースタイプ :** `AWS::Redshift::Cluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-maintenancesettings-check.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-maintenancesettings-check.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**
+ `allowVersionUpgrade = true` (カスタマイズ不可)

このコントロールは、Amazon Redshift クラスターで自動メジャーバージョンアップグレードが有効になっているかどうかをチェックします。

自動メジャーバージョンアップグレードを有効にすることで、メンテナンスウィンドウ中に Amazon Redshift クラスターの最新のメジャーバージョンの更新がインストールされます。これらのアップデートには、セキュリティパッチやバグ修正が含まれる場合があります。パッチのインストールを最新の状態に保つことは、システムを保護する上で重要なステップです。

### 修正
<a name="redshift-6-remediation"></a>

この問題を から修正するには AWS CLI、Amazon Redshift `modify-cluster` コマンドを使用して `--allow-version-upgrade` 属性を設定します。 `clustername`は Amazon Redshift クラスターの名前です。

```
aws redshift modify-cluster --cluster-identifier clustername --allow-version-upgrade
```

## [Redshift.7] Redshift クラスターは拡張 VPC ルーティングを使用する必要があります
<a name="redshift-7"></a>

**関連する要件:** NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)

**カテゴリ:** 保護 > セキュアなネットワーク設定 > API プライベートアクセス

**重要度:** 中

**リソースタイプ :** `AWS::Redshift::Cluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-enhanced-vpc-routing-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-enhanced-vpc-routing-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ:** なし

このコントロールは、Amazon Redshift クラスターで `EnhancedVpcRouting` が有効かどうかをチェックします。

拡張 VPC ルーティングは、クラスターとデータリポジトリ間のすべての `COPY` および `UNLOAD` トラフィックが VPC を経由するよう強制します。その後、セキュリティグループやネットワークアクセスコントロールリストなどの VPC 機能を使用して、ネットワークトラフィックを保護することができます。VPC フローログを使用して、ネットワークトラフィックをモニタリングすることもできます。

### 修正
<a name="redshift-7-remediation"></a>

詳細な修正手順については、「*Amazon Redshift 管理ガイド*」の「[拡張された VPC ルーティングの有効化](https://docs.aws.amazon.com/redshift/latest/mgmt/enhanced-vpc-enabling-cluster.html)」を参照してください。

## [Redshift.8] Amazon Redshift クラスターはデフォルトの管理者ユーザーネームを使用しないでください
<a name="redshift-8"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2

**カテゴリ:** 識別 > リソース設定

**重要度:** 中

**リソースタイプ :** `AWS::Redshift::Cluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-default-admin-check.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-default-admin-check.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon Redshift クラスターが、管理者ユーザーネームをデフォルト値から変更したかどうかをチェックします。Redshift クラスターの管理者ユーザーネームが `awsuser` に設定されている場合、このコントロールは失敗します。

Amazon RDS クラスターを作成するときは、デフォルトの管理者ユーザーネームを一意の値に変更する必要があります。デフォルトのユーザーネームはパブリックナレッジであり、設定時に変更する必要があります。デフォルトのユーザーネームを変更すると、意図しないアクセスのリスクが軽減されます。

### 修正
<a name="redshift-8-remediation"></a>

Amazon Redshift クラスターの管理者ユーザーネームは、作成後に変更することはできません。デフォルト以外のユーザー名で新しいクラスターを作成するには、「*Amazon Redshift 入門ガイド*」の「[ステップ 1: サンプル Amazon Redshift クラスターを作成する](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-prereq.html)」を参照してください。

## [Redshift.10] Redshift クラスターは保存時に暗号化する必要があります
<a name="redshift-10"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SI-7(6)

**カテゴリ:** 保護 > データ保護 > 保管中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::Redshift::Cluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-kms-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-kms-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon Redshift クラスターが保管時に暗号化されているかどうかをチェックします。Redshift クラスターが保存時に暗号化されていない場合、または暗号化キーがルールパラメータで指定されたキーと異なる場合、コントロールは失敗します。

Amazon Redshift では、クラスターに対してデータベースの暗号化を有効にして、保管中のデータを保護できます。クラスターに対して暗号化を有効にすると、クラスターとそのスナップショットのデータブロックとシステムメタデータが暗号化されます。保管中のデータの暗号化は、データにアクセス管理のレイヤーを追加できるため、推奨されるベストプラクティスです。保管中の Redshift クラスターを暗号化すると、認証されていないユーザーがディスクに保存しているデータにアクセスするリスクが低減されます。

### 修正
<a name="redshift-10-remediation"></a>

KMS 暗号化を使用するように Redshift クラスターを変更するには、「*Amazon Redshift 管理ガイド*」の「[クラスターの暗号化の変更](https://docs.aws.amazon.com/redshift/latest/mgmt/changing-cluster-encryption.html)」を参照してください。

## [Redshift.11] Redshift クラスターにはタグを付ける必要があります
<a name="redshift-11"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::Redshift::Cluster`

**AWS Config rule:** `tagged-redshift-cluster` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、Amazon Redshift クラスターにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。クラスターにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、クラスターにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="redshift-11-remediation"></a>

Redshift クラスターにタグを追加するには、「*Amazon Redshift 管理ガイド*」の「[Amazon Redshift でのリソースのタグ付け](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-tagging.html)」を参照してください。

## [Redshift.12] Redshift イベント通知サブスクリプションにはタグを付ける必要があります
<a name="redshift-12"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::Redshift::EventSubscription`

**AWS Config rule:** `tagged-redshift-eventsubscription` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、Amazon Redshift クラスタースナップショットに、パラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。クラスタースナップショットにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、クラスタースナップショットにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="redshift-12-remediation"></a>

Redshift イベント通知サブスクリプションにタグを追加するには、「*Amazon Redshift 管理ガイド*」の「[Amazon Redshift でのリソースのタグ付け](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-tagging.html)」を参照してください。

## [Redshift.13] Redshift クラスタースナップショットにはタグを付ける必要があります
<a name="redshift-13"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::Redshift::ClusterSnapshot`

**AWS Config rule:** `tagged-redshift-clustersnapshot` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、Amazon Redshift クラスタースナップショットに、パラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。クラスタースナップショットにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、クラスタースナップショットにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="redshift-13-remediation"></a>

Redshift クラスタースナップショットにタグを追加するには、「*Amazon Redshift 管理ガイド*」の「[Amazon Redshift でのリソースのタグ付け](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-tagging.html)」を参照してください。

## [Redshift.14] Redshift クラスターサブネットグループにはタグを付ける必要があります
<a name="redshift-14"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::Redshift::ClusterSubnetGroup`

**AWS Config rule:** `tagged-redshift-clustersubnetgroup` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、Amazon Redshift クラスターサブネットグループに、パラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。クラスターサブネットグループにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、クラスターサブネットグループがキーでタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="redshift-14-remediation"></a>

Redshift クラスターサブネットグループにタグを追加するには、「*Amazon Redshift 管理ガイド*」の「[Amazon Redshift でのリソースのタグ付け](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-tagging.html)」を参照してください。

## [Redshift.15] Redshift セキュリティグループは、制限されたオリジンからのみクラスターポートへの入力を許可する必要があります
<a name="redshift-15"></a>

**関連する要件:** PCI DSS v4.0.1/1.3.1

**カテゴリ:** 保護 > セキュアなネットワーク設定 > セキュリティグループの設定

**重要度:** 高

**リソースタイプ :** `AWS::Redshift::Cluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-unrestricted-port-access.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-unrestricted-port-access.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、Amazon Redshift クラスターに関連付けられたセキュリティグループに、インターネット (0.0.0.0/0 または ::/0) からのクラスターポートへのアクセスを許可する入力ルールがあるかどうかをチェックします。セキュリティグループの入力ルールがインターネットからのクラスターポートへのアクセスを許可すると、コントロールは失敗します。

Redshift クラスターポート (/0 サフィックスを持つ IP アドレス) への無制限のインバウンドアクセスを許可すると、不正アクセスやセキュリティインシデントが発生する可能性があります。セキュリティグループを作成し、インバウンドルールを設定するときは、最小特権アクセスのプリンシパルを適用することをお勧めします。

### 修正
<a name="redshift-15-remediation"></a>

Redshift クラスターポートの入力を制限されたオリジンに制限するには、「*Amazon VPC ユーザーガイド*」の「[セキュリティグループルールの操作](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html#working-with-security-group-rules)」を参照してください。ポート範囲が Redshift クラスターポートと一致し、IP ポート範囲が 0.0.0.0/0 であるルールを更新します。

## [Redshift.16] Redshift クラスターサブネットグループには、複数のアベイラビリティーゾーンからのサブネットが必要です
<a name="redshift-16"></a>

**カテゴリ:** リカバリ > 耐障害性 > 高可用性

**重要度:** 中

**リソースタイプ :** `AWS::Redshift::ClusterSubnetGroup`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-subnet-group-multi-az.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-subnet-group-multi-az.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon Redshift クラスターサブネットグループに複数のアベイラビリティーゾーン (AZ) からのサブネットがあるかどうかをチェックします。クラスターサブネットグループに少なくとも 2 つの異なる AZ からのサブネットがない場合、コントロールは失敗します。

複数の AZ にまたがるサブネットを設定することで、障害イベントが発生した場合でも、Redshift データウェアハウスの運用を継続できます。

### 修正
<a name="redshift-16-remediation"></a>

複数の AZ にまたがるように Redshift クラスターサブネットグループを変更するには、「*Amazon Redshift 管理ガイド*」の「[クラスターサブネットグループの変更](https://docs.aws.amazon.com/redshift/latest/mgmt/modify-cluster-subnet-group.html)」を参照してください。

## [Redshift.17] Redshift クラスターパラメータグループはタグ付けする必要があります
<a name="redshift-17"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::Redshift::ClusterParameterGroup`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-parameter-group-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-parameter-group-tagged.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | 評価されたリソースに割り当てる必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目) | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし | 

このコントロールは、Amazon Redshift クラスターパラメータグループに、`requiredKeyTags` パラメータで指定されたタグキーがあるかどうかをチェックします。パラメータグループにタグキーがない場合、または `requiredKeyTags` パラメータで指定されたすべてのキーがない場合、コントロールは失敗します。`requiredKeyTags` パラメータの値を指定しない場合、コントロールはタグキーの存在のみをチェックし、パラメータグループにタグキーがない場合は失敗します。このコントロールはシステムタグを無視します。システムタグは自動的に付与され、`aws:` プレフィックスが付きます。

タグは、 AWS リソースを作成して割り当てるラベルです。各タグは、必要なタグキーとオプションのタグ値で設定されています。タグを使用して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。またそれらは、アクションと通知のリソース所有者を追跡するのにも役立ちます。タグを使用して、認可戦略として属性ベースのアクセス制御 (ABAC) を実装することもできます。ABAC 戦略の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。タグの詳細については、[「 AWS リソースのタグ付け」および「タグエディタユーザーガイド](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。

**注記**  
個人を特定できる情報 (PII) などの機密情報や秘匿性の高い情報はタグに格納しないでください。タグには多くの からアクセスできます AWS のサービス。それらは、プライベートデータや機密データに使用することを意図していません。

### 修正
<a name="redshift-17-remediation"></a>

Redshift クラスターパラメータグループにタグを追加する方法については、「*Amazon Redshift 管理ガイド*」の「[Amazon Redshift でのリソースのタグ付け](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-tagging.html)」を参照してください。

## [Redshift.18] Redshift クラスターでは、マルチ AZ 配置を有効にする必要があります
<a name="redshift-18"></a>

**カテゴリ:** リカバリ > 耐障害性 > 高可用性

**重要度:** 中

**リソースタイプ :** `AWS::Redshift::Cluster`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-multi-az-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-multi-az-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon Redshift クラスターで複数のアベイラビリティーゾーン (マルチ AZ) 配置が有効になっているかどうかを確認します。Amazon Redshift クラスターでマルチ AZ 配置が有効になっていない場合、コントロールは失敗します。

Amazon Redshift は、プロビジョニングされたクラスター用に複数のアベイラビリティーゾーン (マルチ AZ) 配置をサポートしています。クラスターでマルチ AZ 配置が有効になっている場合、アベイラビリティーゾーン (AZ) で予期しないイベントが発生した障害シナリオでも Amazon Redshift データウェアハウスを引き続き運用できます。マルチ AZ 配置は、複数の AZ にコンピューティングリソースをデプロイし、これらのコンピューティングリソースは 1 つのエンドポイントからアクセスできます。AZ 全体で障害が発生しても、別の AZ の残りのコンピューティングリソースは引き続きワークロードの処理に使用できます。既存のシングル AZ データウェアハウスをマルチ AZ データウェアハウスに変換することもできます。その後、追加のコンピューティングリソースが 2 番目の AZ にプロビジョニングされます。

### 修正
<a name="redshift-18-remediation"></a>

Amazon Redshift クラスターのマルチ AZ 配置の設定については、「*Amazon Redshift 管理ガイド*」の「[シングル AZ データウェアハウスをマルチ AZ データウェアハウスに変換する](https://docs.aws.amazon.com/redshift/latest/mgmt/convert-saz-to-maz.html)」を参照してください。

# Amazon Redshift Serverless の Security Hub CSPM コントロール
<a name="redshiftserverless-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon Redshift Serverless サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [RedshiftServerless.1] Amazon Redshift Serverless ワークグループは拡張された VPC のルーティングを使用する必要があります
<a name="redshiftserverless-1"></a>

**カテゴリ:** 保護 > セキュアなネットワーク設定 > VPC 内のリソース

**重要度:** 高

**リソースタイプ :** `AWS::RedshiftServerless::Workgroup`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-workgroup-routes-within-vpc.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-workgroup-routes-within-vpc.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、Amazon Redshift Serverless ワークグループで拡張された VPC ルーティングが有効になっているかどうかをチェックします。ワークグループで拡張された VPC ルーティングが無効になっている場合、コントロールは失敗します。

Amazon Redshift Serverless ワークグループで拡張 VPC ルーティングが無効になっている場合、Amazon Redshift は AWS ネットワーク内の他のサービスへのトラフィックを含め、インターネット経由でトラフィックをルーティングします。ワークグループで拡張された VPC ルーティングを有効にすると、Amazon Redshift はクラスターとデータリポジトリ間のすべての `COPY` および `UNLOAD` のトラフィックが Amazon VPC サービスに基づく仮想プライベートクラウド (VPC) を通過するように強制します。拡張された VPC ルーティングを有効にすることで、標準の VPC 機能を使用して、Amazon Redshift クラスターと他のリソースの間のデータフローを制御できます。これには、VPC セキュリティグループとエンドポイントポリシー、ネットワークアクセスコントロールリスト (ACL)、ドメインネームシステム (DNS) サーバーなどの機能が含まれます。VPC フローログを使用して `COPY` と `UNLOAD` のトラフィックをモニタリングすることもできます。

### 修正
<a name="redshiftserverless-1-remediation"></a>

拡張された VPC ルーティングの詳細とワークグループで有効にする方法については、「*Amazon Redshift 管理ガイド*」の「[Controlling network traffic with Redshift enhanced VPC routing](https://docs.aws.amazon.com/redshift/latest/mgmt/enhanced-vpc-routing.html)」を参照してください。

## [RedshiftServerless.2] SSL を使用するには、Redshift Serverless ワークグループへの接続が必要です
<a name="redshiftserverless-2"></a>

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::RedshiftServerless::Workgroup`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-workgroup-encrypted-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-workgroup-encrypted-in-transit.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、Amazon Redshift Serverless ワークグループへの接続で、転送中のデータを暗号化する必要があるかどうかをチェックします。ワークグループの `require_ssl` 設定パラメータが `false` に設定されている場合、コントロールは失敗します。

Amazon Redshift Serverless ワークグループは、RPU、VPC サブネットグループ、セキュリティグループなどのコンピューティングリソースをグループ化する、コンピューティングリソースのコレクションです。ワークグループのプロパティには、ネットワークとセキュリティ設定が含まれます。これらの設定は、ワークグループへの接続で転送中のデータを暗号化するために SSL を使用する必要があるかどうかを指定します。

### 修正
<a name="redshiftserverless-2-remediation"></a>

Amazon Redshift Serverless ワークグループの設定を更新して SSL 接続を要求する方法については、「*Amazon Redshift 管理ガイド*」の「[Amazon Redshift Serverless への接続](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-connecting.html)」を参照してください。

## [RedshiftServerless.3] Redshift Serverless ワークグループはパブリックアクセスを禁止する必要があります
<a name="redshiftserverless-3"></a>

**カテゴリ:** 保護 > セキュアなネットワーク設定 > パブリックアクセス不可のリソース

**重要度:** 高

**リソースタイプ :** `AWS::RedshiftServerless::Workgroup`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-workgroup-no-public-access.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-workgroup-no-public-access.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、Amazon Redshift Serverless ワークグループでパブリックアクセスが無効になっているかどうかをチェックします。Redshift Serverless ワークグループの `publiclyAccessible` プロパティを評価します。ワークグループのパブリックアクセスが有効 (`true`) になっている場合、コントロールは失敗します。

Amazon Redshift Serverless ワークグループのパブリックアクセス (`publiclyAccessible`) 設定は、ワークグループにパブリックネットワークからアクセスできるかどうかを指定します。ワークグループのパブリックアクセスが有効 (`true`) になっている場合、Amazon Redshift は Elastic IP アドレスを作成して、ワークグループを VPC の外部からパブリックにアクセスできるようにします。ワークグループにパブリックアクセスを許可しない場合は、パブリックアクセスを無効にします。

### 修正
<a name="redshiftserverless-3-remediation"></a>

Amazon Redshift Serverless ワークグループのパブリックアクセス設定を変更する方法については、「*Amazon Redshift 管理ガイド*」の「[ワークグループのプロパティを表示する](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-console-workgroups.html)」を参照してください。

## [RedshiftServerless.4] Redshift Serverless 名前空間はカスタマーマネージドで暗号化する必要があります AWS KMS keys
<a name="redshiftserverless-4"></a>

**関連する要件:** NIST.800-53.r5 AU-9、NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SC-12(2)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SI-7(6)

**カテゴリ:** 保護 > データ保護 > 保管中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::RedshiftServerless::Namespace`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-namespace-cmk-encryption.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-namespace-cmk-encryption.html)

**スケジュールタイプ :** 定期的

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `kmsKeyArns`  |  評価 AWS KMS keys に含める の Amazon リソースネーム (ARNs) のリスト。Redshift Serverless 名前空間がリスト内の KMS キーで暗号化されていない場合、コントロールは `FAILED` 検出結果を生成します。  |  StringList (最大 3 項目)  |  既存の KMS キーの 1～3 個の ARN。例: `arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab`。  |  デフォルト値なし  | 

このコントロールは、Amazon Redshift Serverless 名前空間が保管時にカスタマーマネージド AWS KMS keyで暗号化されているかどうかをチェックします。Redshift Serverless 名前空間がカスタマーマネージド KMS キーで暗号化されていない場合、コントロールは失敗します。必要に応じて、コントロールの評価に含める KMS キーのリストを指定することができます。

Amazon Redshift Serverless では、名前空間はデータベースオブジェクトの論理コンテナを定義します。このコントロールは、名前空間の暗号化設定が、名前空間内のデータの暗号化のために AWS KMS key、マネージド KMS キーではなくカスタマー AWS マネージド を指定するかどうかを定期的にチェックします。カスタマーマネージド KMS キーを使用すると、ユーザーがキーを完全にコントロールできます。これには、キーポリシーの定義と維持管理、許可の管理、暗号化マテリアルのローテーション、タグの割り当て、エイリアスの作成、キーの有効化と無効化が含まれます。

### 修正
<a name="redshiftserverless-4-remediation"></a>

Amazon Redshift Serverless 名前空間の暗号化設定の更新とカスタマー管理の指定については AWS KMS key、「Amazon Redshift 管理ガイド」の[「名前空間 AWS KMS key の の変更](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-workgroups-and-namespaces-rotate-kms-key.html)」を参照してください。 **

## [RedshiftServerless.5] Redshift サーバーレス名前空間でデフォルトの管理者ユーザー名を使用すべきではありません
<a name="redshiftserverless-5"></a>

**カテゴリ:** 識別 > リソース設定

**重要度:** 中

**リソースタイプ :** `AWS::RedshiftServerless::Namespace`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-default-admin-check.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-default-admin-check.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、Amazon Redshift Serverless 名前空間の管理者ユーザー名がデフォルトの管理者ユーザー名 `admin` であるかどうかをチェックします。Redshift Serverless 名前空間の管理者ユーザー名が `admin` の場合、コントロールは失敗します。

Amazon Redshift Serverless 名前空間を作成するときに、名前空間のカスタム管理者ユーザー名を指定する必要があります。デフォルトの管理者ユーザー名は一般に知られています。カスタム管理者ユーザー名を指定することで、たとえば、名前空間に対するブルートフォース攻撃のリスクや有効性を軽減できます。

### 修正
<a name="redshiftserverless-5-remediation"></a>

Amazon Redshift Serverless コンソールまたは API を使用して、Amazon Redshift Serverless 名前空間の管理者ユーザー名を変更できます。コンソールを使用して変更するには、名前空間設定を選択し、**[アクション]** メニューで **[管理者認証情報の編集]** を選択します。プログラムで変更するには、[UpdateNamespace](https://docs.aws.amazon.com/redshift-serverless/latest/APIReference/API_UpdateNamespace.html) オペレーションを使用するか、 を使用している場合は AWS CLI update[-namespace](https://docs.aws.amazon.com/cli/latest/reference/redshift-serverless/update-namespace.html) コマンドを実行します。管理者ユーザー名を変更する場合は、同時に管理者パスワードも変更する必要があります。

## [RedshiftServerless.6] Redshift Serverless 名前空間は CloudWatch Logs にログをエクスポートする必要があります
<a name="redshiftserverless-6"></a>

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::RedshiftServerless::Namespace`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-publish-logs-to-cloudwatch.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-publish-logs-to-cloudwatch.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、Amazon Redshift Serverless 名前空間が接続ログとユーザーログを Amazon CloudWatch Logs にエクスポートするように設定されているかどうかをチェックします。Redshift Serverless 名前空間がログを CloudWatch Logs にエクスポートするように設定されていない場合、コントロールは失敗します。

Amazon Redshift Serverless の設定で、接続ログ (`connectionlog`) とユーザーログ (`userlog`) のデータを Amazon CloudWatch Logs のロググループにエクスポートするように設定すると、ログレコードを収集して耐久性のあるストレージに保存できるため、セキュリティ、アクセス、可用性のレビューと監査に対応できます。CloudWatch Logs では、ログデータのリアルタイム分析を実行したり、CloudWatch を使用してアラームを作成したり、メトリクスを確認したりすることもできます。

### 修正
<a name="redshiftserverless-6-remediation"></a>

Amazon Redshift Serverless 名前空間のログデータを Amazon CloudWatch Logs にエクスポートするには、名前空間の監査ログ設定で、対応するログをエクスポート対象として選択する必要があります。これらの設定を更新する方法については、「*Amazon Redshift 管理ガイド*」の「[セキュリティと暗号化を編集する](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-console-configuration-edit-network-settings.html)」を参照してください。

# Route 53 の Security Hub CSPM コントロール
<a name="route53-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon Route 53 サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [Route53.1] Route 53 ヘルスチェックにはタグを付ける必要があります
<a name="route53-1"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::Route53::HealthCheck`

**AWS Config rule:**`tagged-route53-healthcheck` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon Route 53 ヘルスチェックにパラメータ `requiredTagKeys` で定義された特定のキーを含むタグがあるかどうかをチェックします。ヘルスチェックにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ヘルスチェックにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="route53-1-remediation"></a>

Route 53 ヘルスチェックにタグを追加するには、「*Amazon Route 53 デベロッパーガイド*」の「[ヘルスチェックの命名とタグ付け](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-tagging.html)」を参照してください。

## [Route53.2] Route 53 のパブリックホストゾーンは DNS クエリをログに記録する必要があります
<a name="route53-2"></a>

**関連する要件:** NIST.800-53.r5 AC-2(4)、NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AC-6(9)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4(20)、NIST.800-53.r5 SI-7(8)、PCI DSS v4.0.1/10.4.2

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::Route53::HostedZone`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/route53-query-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/route53-query-logging-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

Amazon Route 53 パブリックホストゾーンで DNS クエリログ記録が有効になっているかどうかを確認します。このコントロールは Amazon Route 53 パブリックホストゾーンで DNS クエリログ記録が有効になっているかどうかを確認します。

Route 53 ホストゾーンの DNS クエリを記録することで、DNS のセキュリティとコンプライアンスの要件に対応し、可視性を高めます。ログには、クエリされたドメインまたはサブドメイン、クエリの日時、DNS レコードタイプ (A や AAAA など)、DNS 応答コード (`NoError` または `ServFail`) などの情報が含まれます。DNS クエリのロギングが有効になると、Route 53 はログファイルを Amazon CloudWatch Logs に発行します。

### 修正
<a name="route53-2-remediation"></a>

Route 53 パブリックホストゾーンの DNS クエリをログ記録するには、「**Amazon Route 53 デベロッパーガイド」の「[DNS クエリのログ記録の設定](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/query-logs.html#query-logs-configuring)」を参照してください。

# Amazon S3 の Security Hub CSPM コントロール
<a name="s3-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon Simple Storage Service (Amazon S3) サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [S3.1] S3 汎用バケットではブロックパブリックアクセスの設定が有効になっている必要があります。
<a name="s3-1"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/2.1.4、 CIS AWS Foundations Benchmark v3.0.0/2.1.4、 CIS AWS Foundations Benchmark v1.4.0/2.1.5、 NIST.800-53.r5 AC-21、 NIST.800-53.r5 AC-3、 NIST.800-53.r5 AC-3(7)、 NIST.800-53.r5 AC-4、 NIST.800-53.r5 AC-4(21)、 NIST.800-53.r5 AC-6、 NIST.800-53.r5 SC-7、 NIST.800-53.r5 SC-7(11)、 NIST.800-53.r5 SC-7(16)、 NIST.800-53.r5 SC-7(20)、 NIST.800-53.r5 SC-7(21)、 NIST.800-53.r5 SC-7(3)、 NIST.800-53.r5 SC-7(4)、 NIST.800-53.r5 SC-7(9)、 PCI DSS v3.2.1/1.2.1、 PCI DSS v3.2.1/1.3.1、 PCI DSS v3.2.1/1.3.2、 PCI DSS v3.2.1/1.3.4、 PCI DSS v3.2.1/1.3.6、 PCI DSS v4.0.1/1.4.4

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 中

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/s3-account-level-public-access-blocks-periodic.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-account-level-public-access-blocks-periodic.html) 

**スケジュールタイプ :** 定期的

**パラメータ :** 
+ `ignorePublicAcls`: `true` (カスタマイズ不可)
+ `blockPublicPolicy`: `true` (カスタマイズ不可)
+ `blockPublicAcls`: `true` (カスタマイズ不可)
+ `restrictPublicBuckets`: `true` (カスタマイズ不可)

このコントロールは、前の Amazon S3 パブリックアクセス設定が S3 汎用バケットのアカウントレベルで設定されているかどうかをチェックします: 1 つ以上のブロックパブリックアクセス設定が `false` に設定されている場合、このコントロールは失敗します。

いずれかの設定が `false` に設定されているか、またはいずれかが設定されていない場合、コントロールは失敗します。

Amazon S3 パブリックアクセスブロックは、オブジェクトがパブリックアクセスを持たないように、 全体 AWS アカウント または個々の S3 バケットレベルでコントロールを提供するように設計されています。パブリックアクセスは、アクセスコントロールリスト (ACL)、バケットポリシー、またはその両方からバケットおよびオブジェクトに付与されます。

S3 バケットをパブリックにアクセスできるように意図する場合を除き、アカウントレベルの Amazon S3 ブロックパブリックアクセス機能を設定する必要があります。

詳細については、「Amazon Simple Storage Service ユーザーガイド」の「[Amazon S3 ブロックパブリックアクセスの使用](https://docs.aws.amazon.com/AmazonS3/latest/dev/access-control-block-public-access.html)」を参照してください。

### 修正
<a name="s3-1-remediation"></a>

の Amazon S3 パブリックアクセスブロックを有効にするには AWS アカウント、*「Amazon Simple Storage Service* [ユーザーガイド」の「アカウントのパブリックアクセスブロックの設定](https://docs.aws.amazon.com/AmazonS3/latest/userguide/configuring-block-public-access-account.html)」を参照してください。

## [S3.2] S3 汎用バケットはパブリック読み取りアクセスをブロックする必要があります
<a name="s3-2"></a>

**関連する要件:** PCI DSS v3.2.1/1.2.1、PCI DSS v3.2.1/1.3.1、PCI DSS v3.2.1/1.3.2、PCI DSS v3.2.1/1.3.6、PCI DSS v3.2.1/7.2.1、NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 非常事態

**リソースタイプ :** `AWS::S3::Bucket`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-public-read-prohibited](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-public-read-prohibited)

**スケジュールタイプ:** 定期的および変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon S3 汎用バケットがパブリック読み取りアクセスを許可するかどうかをチェックします。これにより、ブロックパブリックアクセス設定、バケットポリシー、およびバケットアクセスコントロールリスト (ACL) を評価します。バケットが公開読み取りアクセスを許可している場合、このコントロールは失敗します。

**注記**  
S3 バケットにバケットポリシーがある場合、このコントロールはワイルドカード文字または変数を使用するポリシー条件を評価しません。`PASSED` 検出結果を生成するには、バケットポリシーの条件は固定値のみを使用する必要があります。固定値は、ワイルドカード文字やポリシー変数を含まない値です。ポリシー変数に関する詳細については、「*AWS Identity and Access Management ユーザーガイド*」の「[変数およびタグ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html)」を参照してください。

ユースケースによっては、インターネット上のすべてのユーザーが S3 バケットからの読み取りが必要な場合があります。しかし、そのような状況は稀です。データの整合性とセキュリティを確保するために、S3 バケットをパブリックに読み取り可能にしないでください。

### 修正
<a name="s3-2-remediation"></a>

Amazon S3 バケットで公開読み取りアクセスをブロックするには、「*Amazon Simple Storage Service ユーザーガイド*」の「[S3 バケットへのパブリックアクセスブロック設定の構成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/configuring-block-public-access-bucket.html)」を参照してください。

## [S3.3] S3 汎用バケットではパブリック書き込みアクセスをブロックする必要があります。
<a name="s3-3"></a>

**関連する要件:** PCI DSS v3.2.1/1.2.1、PCI DSS v3.2.1/1.3.1、PCI DSS v3.2.1/1.3.2、PCI DSS v3.2.1/1.3.4、PCI DSS v3.2.1/1.3.6、PCI DSS v3.2.1/7.2.1、NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 非常事態

**リソースタイプ :** `AWS::S3::Bucket`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-public-write-prohibited.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-public-write-prohibited.html) 

**スケジュールタイプ:** 定期的および変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon S3 汎用バケットがパブリック書き込みアクセスを許可するかどうかをチェックします。これにより、ブロックパブリックアクセス設定、バケットポリシー、およびバケットアクセスコントロールリスト (ACL) を評価します。バケットが公開書き込みアクセスを許可している場合、このコントロールは失敗します。

**注記**  
S3 バケットにバケットポリシーがある場合、このコントロールはワイルドカード文字または変数を使用するポリシー条件を評価しません。`PASSED` 検出結果を生成するには、バケットポリシーの条件は固定値のみを使用する必要があります。固定値は、ワイルドカード文字やポリシー変数を含まない値です。ポリシー変数に関する詳細については、「*AWS Identity and Access Management ユーザーガイド*」の「[変数およびタグ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html)」を参照してください。

ユースケースによっては、インターネット上の全員が S3 バケットに書き込むことができる必要があります。しかし、そのような状況は稀です。データの整合性とセキュリティを確保するため、S3 バケットはパブリックに書き込み可能にしないでください。

### 修正
<a name="s3-3-remediation"></a>

Amazon S3 バケットで公開書き込みアクセスをブロックするには、「*Amazon Simple Storage Service ユーザーガイド*」の「[S3 バケットへのパブリックアクセスブロック設定の構成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/configuring-block-public-access-bucket.html)」を参照してください。

## [S3.5] S3 汎用バケットではリクエストに SSL を使用する必要があります。
<a name="s3-5"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/2.1.1、 CIS AWS Foundations Benchmark v3.0.0/2.1.1、 CIS AWS Foundations Benchmark v1.4.0/2.1.2、 NIST.800-53.r5 AC-17(2)、 NIST.800-53.r5 AC-4、 NIST.800-53.r5 IA-5(1)、 NIST.800-53.r5 SC-12(3)、 NIST.800-53.r5 SC-13、 NIST.800-53.r5 SC-23、 NIST.800-53.r5 SC-23(3)、 NIST.800-53.r5 SC-7(4)、 NIST.800-53.r5 SC-8、 NIST.800-53.r5 SC-8(1)、 NIST.800-53.r5 SC-8(2)、 NIST.800-53.r5 SI-7(6)、 NIST.800-171.r2 3.13.8、 NIST.800-171.r2 3.13.15、 PCI DSS v3.2.1/4.1、 PCI DSS v4.0.1/4.2.1

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 中

**リソースタイプ :** `AWS::S3::Bucket`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-ssl-requests-only.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-ssl-requests-only.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon S3 汎用バケットに SSL を使用するためのリクエストを要求するポリシーがあるかどうかをチェックします。バケットポリシーが SSL を使用するリクエストを必要としない場合、コントロールは失敗します。

S3 バケットには、条件キー `aws:SecureTransport` によって示される S3 リソースポリシーで HTTPS 経由のデータ送信のみを受け入れるために、すべてのリクエスト (`Action: S3:*`) を要求するポリシーを備える必要があります。

### 修正
<a name="s3-5-remediation"></a>

Amazon S3 バケットポリシーを更新して非セキュアなトランスポートを拒否するには、「*Amazon Simple Storage Service ユーザーガイド*」の「[Amazon S3 コンソールを使用したバケットポリシーの追加](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html)」を参照してください。

以下のポリシーに、同様のポリシーステートメントを追加します。`amzn-s3-demo-bucket` を変更するバケットの名前で置き換えます。

------
#### [ JSON ]

****  

```
{
    "Id": "ExamplePolicy",
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowSSLRequestsOnly",
            "Action": "s3:*",
            "Effect": "Deny",
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket",
                "arn:aws:s3:::amzn-s3-demo-bucket/*"
            ],
            "Condition": {
                "Bool": {
                     "aws:SecureTransport": "false"
                }
            },
           "Principal": "*"
        }
    ]
}
```

------

詳細については、*AWS 「 公式ナレッジセンター*」の「ルール [AWS Config sS3-bucket-ssl-requests-only に準拠するために使用する S3 バケットポリシー](https://aws.amazon.com/premiumsupport/knowledge-center/s3-bucket-policy-for-config-rule/)」を参照してください。

## [S3.6] S3 汎用バケットポリシーは、他の へのアクセスを制限する必要があります AWS アカウント
<a name="s3-6"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-171.r2 3.13.4

**カテゴリ:** 保護 > セキュアなアクセス管理 > 機密性の高いAPIオペレーションアクションを制限する 

**重要度:** 高

**リソースタイプ :** `AWS::S3::Bucket`

**AWS Configルール :** [https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-blacklisted-actions-prohibited.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-blacklisted-actions-prohibited.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :**
+ `blacklistedactionpatterns`: `s3:DeleteBucketPolicy, s3:PutBucketAcl, s3:PutBucketPolicy, s3:PutEncryptionConfiguration, s3:PutObjectAcl` (カスタマイズ不可)

このコントロールは、Amazon S3 汎用バケットポリシーが別の AWS アカウント からのプリンシパルが、S3 バケット内のリソースに対して拒否されたアクションの実行を防止するかどうかをチェックします。バケットポリシーで、別の AWS アカウントのプリンシパルに対して前のいずれかのアクションが許可されている場合、このコントロールは失敗します。

最小特権アクセスの実装は、セキュリティリスクおよびエラーの影響や悪意ある行動を減らす上での基礎となります。もしS3 バケットポリシーで外部アカウントからのアクセスを許可している場合、内部脅威または攻撃者によるデータの漏えいにつながる可能性があります。

`blacklistedactionpatterns` パラメータを使用すると、S3 バケットのルールを正常に評価できます。パラメータは、外部アカウントに対して `blacklistedactionpatterns` リストに含まれていないアクションパターンのアクセス許可を付与します。

### 修正
<a name="s3-6-remediation"></a>

Amazon S3 バケットポリシーを更新してアクセス許可を削除するには、「*Amazon Simple Storage Service ユーザーガイド*」の「[Amazon S3 コンソールを使用したバケットポリシーの追加](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html)」を参照してください。

**[バケットポリシーを編集]** ページのポリシー編集テキストボックスで、以下のいずれかのアクションを実行します。
+ 拒否されたアクションへのアクセス許可を別の  AWS アカウント に付与するステートメントを削除する。
+ 許可済みの拒否されたアクションをステートメントから削除する。

## [S3.7] S3 汎用バケットでクロスリージョンレプリケーションを使用する必要があります
<a name="s3-7"></a>

**関連する要件:** PCI DSS v3.2.1/2.2、NIST.800-53.r5 AU-9(2)、NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6、NIST.800-53.r5 CP-6(1)、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 CP-9、NIST.800-53.r5 SC-36(2)、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 低

**リソースタイプ :** `AWS::S3::Bucket`

**AWS Config ルール: ** [https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-cross-region-replication-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-cross-region-replication-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは Amazon S3 バケット 汎用バケットでクロスリージョンレプリケーションが有効かどうかをチェックします。バケットでクロスリージョンレプリケーションが有効になっていない場合、このコントロールは失敗します。

レプリケーションとは、同じまたは異なるバケット間でオブジェクトを自動的に非同期コピーすることです AWS リージョン。レプリケーションは、新しく作成されたオブジェクトと、レプリケート元バケットからレプリケート先バケットへのオブジェクトの更新をコピーします。 AWS  ベストプラクティスでは、同じ AWS アカウント が所有するレプリケート元バケットとレプリケート先バケットのレプリケーションを推奨しています。可用性に加えて、他のシステム強化構成も考慮する必要があります。

このコントロールは、リージョン間のレプリケーションが有効になっていない場合、レプリケーション先バケット `FAILED` の検出結果を生成します。送信先バケットでクロスリージョンレプリケーションを有効にする必要がない正当な理由がある場合は、このバケットの検出結果を抑制できます。

### 修正
<a name="s3-7-remediation"></a>

Amazon S3 バケットのレプリケーションを有効にするには、「**Amazon Simple Storage Service ユーザーガイド」の「[同じアカウントが所有するレプリケート元バケットとレプリケート先バケットのレプリケーションの設定](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-walkthrough1.html)」を参照してください。**[ソースバケット]** で、**[バケット内のすべてのオブジェクトに適用]** を選択します。

## [S3.8] S3 汎用バケットはパブリックアクセスをブロックする必要があります
<a name="s3-8"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/2.1.4、CIS AWS Foundations Benchmark v3.0.02.1.4、CIS AWS Foundations Benchmark v1.4.0/2.1.5、NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7-53.r5 NIST.800-53.r5 SC-71)、NIST.800-53.r5 SC-7 IST

**カテゴリ:** 保護 > セキュアなアクセス管理 > アクセスコントロール

**重要度:** 高

**リソースタイプ :** `AWS::S3::Bucket`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-level-public-access-prohibited.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-level-public-access-prohibited.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**
+ `excludedPublicBuckets` (カスタマイズ不可) - 既知の許可されているパブリック S3 バケット名のカンマ区切りリスト

このコントロールは、Amazon S3 汎用バケットがバケットレベルでパブリックアクセスをブロックするかどうかをチェックします。次の設定のいずれかが `false` に設定されている場合、コントロールは失敗します。
+ `ignorePublicAcls`
+ `blockPublicPolicy`
+ `blockPublicAcls`
+ `restrictPublicBuckets`

S3 バケットレベルのブロックパブリックアクセスは、オブジェクトがパブリックアクセスできないようにコントロールを提供します。パブリックアクセスは、アクセスコントロールリスト (ACL)、バケットポリシー、またはその両方からバケットおよびオブジェクトに付与されます。

S3 バケットをパブリックにアクセスできるように意図する場合を除き、バケットレベルの Amazon S3 ブロックパブリックアクセス機能を設定する必要があります。

### 修正
<a name="s3-8-remediation"></a>

バケットレベルでパブリックアクセスを削除する方法については、「Amazon S3 ユーザーガイド」の「[Amazon S3 ストレージへのパブリックアクセスのブロック](https://docs.aws.amazon.com/AmazonS3/latest/dev/access-control-block-public-access.html)」を参照してください。

## [S3.9] S3 汎用バケットは、サーバーアクセスログ記録を有効にする必要があります
<a name="s3-9"></a>

**関連する要件:** NIST.800-53.r5 AC-2(4)、NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AC-6(9)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4(20)、NIST.800-53.r5 SI-7(8)、NIST.800-171.r2 3.3.8、PCI DSS v4.0.1/10.2.1

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::S3::Bucket`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-logging-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon S3 汎用バケットでサーバーアクセスログ記録が有効になっているかどうかをチェックします。サーバーアクセスのログ記録が有効になっていない場合、コントロールは失敗します。ログ記録を有効にすると、Amazon S3 は、ソースバケットのアクセスログを選択されたターゲットバケットに配信します。ターゲットバケットはソースバケット AWS リージョン と同じ にある必要があり、デフォルトの保持期間を設定してはいけません。ターゲットのログ記録バケットは、サーバーアクセスのログ記録を有効にする必要がないため、このバケットの結果は非表示にします。

サーバーアクセスのログ記録には、バケットに対するリクエストの詳細を提供します。サーバーアクセスログは、セキュリティとアクセス監査に役立ちます。詳細については、「[Amazon S3 のセキュリティベストプラクティス: Amazon S3 サーバーアクセスログを有効にします](https://docs.aws.amazon.com/AmazonS3/latest/dev/security-best-practices.html)」を参照してください。

### 修正
<a name="s3-9-remediation"></a>

Amazon S3 のサーバーアクセスのログ記録を有効にするには、「*Amazon S3 ユーザーガイド*」の「[Amazon S3 サーバーアクセスログの有効化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html)」を参照してください。

## [S3.10] バージョニングが有効になっている S3 汎用バケットにはライフサイクル設定が必要です
<a name="s3-10"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 CP-9、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::S3::Bucket`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/s3-version-lifecycle-policy-check.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-version-lifecycle-policy-check.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon S3 汎用バージョニングバケットにライフサイクル設定があるかどうかをチェックします。バケットにライフサイクル設定がない場合、コントロールは失敗します。

オブジェクトの存続期間中に Amazon S3 で実行するアクションの定義に役立てるため、S3 バケットにライフサイクル設定を作成することを推奨します。

### 修正
<a name="s3-10-remediation"></a>

Amazon S3 バケットでのライフサイクルの設定の詳細については、「[バケットのライフサイクル設定の指定](https://docs.aws.amazon.com/AmazonS3/latest/userguide/how-to-set-lifecycle-configuration-intro.html)」と「[ストレージのライフサイクルの管理](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)」を参照してください。

## [S3.11] S3 汎用バケットでは、イベント通知を有効にする必要があります
<a name="s3-11"></a>

**関連する要件:** NIST.800-53.r5 CA-7、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4、NIST.800-53.r5 SI-4(4)、NIST.800-171.r2 3.3.8

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::S3::Bucket`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/s3-event-notifications-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-event-notifications-enabled.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `eventTypes`  |  推奨される S3 イベントタイプのリスト  |  EnumList (最大 28 項目)  |  `s3:IntelligentTiering, s3:LifecycleExpiration:*, s3:LifecycleExpiration:Delete, s3:LifecycleExpiration:DeleteMarkerCreated, s3:LifecycleTransition, s3:ObjectAcl:Put, s3:ObjectCreated:*, s3:ObjectCreated:CompleteMultipartUpload, s3:ObjectCreated:Copy, s3:ObjectCreated:Post, s3:ObjectCreated:Put, s3:ObjectRemoved:*, s3:ObjectRemoved:Delete, s3:ObjectRemoved:DeleteMarkerCreated, s3:ObjectRestore:*, s3:ObjectRestore:Completed, s3:ObjectRestore:Delete, s3:ObjectRestore:Post, s3:ObjectTagging:*, s3:ObjectTagging:Delete, s3:ObjectTagging:Put, s3:ReducedRedundancyLostObject, s3:Replication:*, s3:Replication:OperationFailedReplication, s3:Replication:OperationMissedThreshold, s3:Replication:OperationNotTracked, s3:Replication:OperationReplicatedAfterThreshold, s3:TestEvent`  |  デフォルト値なし  | 

このコントロールは、S3 イベント通知が Amazon S3 汎用バケットで有効になっているかどうかをチェックします。バケットで S3 イベント通知が有効になっていない場合、コントロールは失敗します。`eventTypes` パラメータにカスタム値を指定したときは、指定されたタイプのイベントに対してイベント通知が有効になっている場合にのみコントロールが成功します。

S3 イベント通知を有効にすると、S3 バケットに影響する特定のイベントが発生したときに、アラートを受信します。例えば、オブジェクトの作成、オブジェクトの削除、オブジェクトの復元を通知を受けることができます。これらの通知により、不正なデータアクセスにつながる可能性のある偶発的または意図的な変更を関連チームに警告することができます。

### 修正
<a name="s3-11-remediation"></a>

S3 バケットおよびオブジェクトの変更を検出する方法の詳細については、「*Amazon S3 ユーザーガイド*」の「[Amazon S3 イベント通知](https://docs.aws.amazon.com/AmazonS3/latest/userguide/NotificationHowTo.html)」を参照してください。

## [S3.12] ACL は、S3 汎用バケットへのユーザーアクセスの管理に使用しないでください。
<a name="s3-12"></a>

**関連する要件:** NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-6

**カテゴリ:** 保護 > セキュアなアクセス管理 > アクセスコントロール

**重要度:** 中

**リソースタイプ :** `AWS::S3::Bucket`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-acl-prohibited.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-acl-prohibited.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon S3 汎用バケットがアクセスコントロールリスト (ACL) を持つユーザーアクセス許可を提供するかどうかをチェックします。バケットでのユーザーアクセスを管理するために ACL が設定されている場合、コントロールは失敗します。

ACL は、IAM よりも前のレガシーアクセスコントロールメカニズムです。ACLs の代わりに、S3 バケットポリシーまたは AWS Identity and Access Management (IAM) ポリシーを使用して S3 バケットへのアクセスを管理することをお勧めします。

### 修正
<a name="s3-12-remediation"></a>

このコントロールに合格するには、S3 バケットの ACL を無効にする必要があります。手順については、「*Amazon Simple Storage Service ユーザーガイド*」の「[オブジェクトの所有権の制御とバケットの ACL の無効化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html)」を参照してください。

S3 バケットポリシーを作成するには、「[Amazon S3 コンソールを使用したバケットポリシーの追加](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html)」を参照してください。S3 バケットに IAM ユーザーポリシーを作成するには、「[ユーザーポリシーを使用したバケットへのアクセスの制御](https://docs.aws.amazon.com/AmazonS3/latest/userguide/walkthrough1.html#walkthrough-grant-user1-permissions)」を参照してください。

## [S3.13] S3 汎用バケットにはライフサイクル設定が必要です
<a name="s3-13"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 CP-9、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-13(5)

**カテゴリ:** 保護 > データ保護 

**重要度:** 低

**リソースタイプ :** `AWS::S3::Bucket`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/s3-lifecycle-policy-check.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-lifecycle-policy-check.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `targetTransitionDays`  |  オブジェクトが、その作成後、指定されたストレージクラスに移行するまでの日数  |  整数  |  `1`～`36500`  |  デフォルト値なし  | 
|  `targetExpirationDays`  |  オブジェクトが作成されてから削除されるまでの日数  |  整数  |  `1`～`36500`  |  デフォルト値なし  | 
|  `targetTransitionStorageClass`  |  送信先 S3 ストレージクラスのタイプ  |  列挙型  |  `STANDARD_IA, INTELLIGENT_TIERING, ONEZONE_IA, GLACIER, GLACIER_IR, DEEP_ARCHIVE`  |  デフォルト値なし  | 

このコントロールは、Amazon S3 汎用バケットにライフサイクル設定があるかどうかをチェックします。バケットにライフサイクル設定がない場合、コントロールは失敗します。前述の 1 つ以上のパラメータにカスタム値を指定したときは、指定されたストレージクラス、削除時間、または移行時間がポリシーに含まれている場合にのみコントロールが成功します。

S3 バケットでライフサイクル設定を作成すると、オブジェクトの存続期間中に Amazon S3 が実行するアクションが定義されます。例えば、オブジェクトを別のストレージクラスに移行させる、アーカイブする、あるいは指定した期間後に削除する、といったことが可能です。

### 修正
<a name="s3-13-remediation"></a>

Amazon S3 バケットでライフサイクルポリシーを設定する方法の詳細については、「*Amazon S3 ユーザーガイド*」の「[バケットのライフサイクル設定の指定](https://docs.aws.amazon.com/AmazonS3/latest/userguide/how-to-set-lifecycle-configuration-intro.html)」および「[ストレージのライフサイクルの管理](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)」を参照してください。

## [S3.14] S3 汎用バケットではバージョニングが有効になっている必要があります
<a name="s3-14"></a>

**カテゴリ:** 保護 > データ保護 > データ削除保護

**関連する要件:** NIST.800-53.r5 AU-9(2)、NIST.800-53.r5 CP-10、NIST.800-53.r5 CP-6、NIST.800-53.r5 CP-6(1)、NIST.800-53.r5 CP-6(2)、NIST.800-53.r5 CP-9、NIST.800-53.r5 SC-5(2)、NIST.800-53.r5 SI-12、NIST.800-53.r5 SI-13(5)、NIST.800-171.r2 3.3.8

**重要度:** 低

**リソースタイプ :** `AWS::S3::Bucket`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-versioning-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-versioning-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon S3 汎用バケットでバージョニングが有効になっているかどうかを確認します。バケットのバージョニングが停止されている場合、コントロールは失敗します。

バージョニングにより、同じ S3 バケット内でオブジェクトの複数のバリアントを保持します。バージョニングを使用して、S3 バケットに保存されたオブジェクトの旧バージョンを保存、取得、復元することができます。バージョニングによって、意図しないユーザーアクションとアプリケーション障害から復旧できます。

**ヒント**  
バージョニングによるバケット内オブジェクト数の増加に合わせて、ルールに基づき、バージョニングされたオブジェクトを自動的にアーカイブまたは削除するようにライフサイクル設定をセットアップできます。詳細については、「[バージョニングされたオブジェクトの Amazon S3 ライフサイクル管理](https://aws.amazon.com/blogs/aws/amazon-s3-lifecycle-management-update/)」を参照してください。

### 修正
<a name="s3-14-remediation"></a>

S3 バケットでバージョニングを使用するには、「*Amazon S3 ユーザーガイド*」の「[バケットでのバージョニングの有効化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/manage-versioning-examples.html)」を参照してください。

## [S3.15] S3 汎用バケットでは Object Lock が有効になっている必要があります
<a name="s3-15"></a>

**カテゴリ:** 保護 > データ保護 > データ削除保護

**関連する要件:** NIST.800-53.r5 CP-6(2)、PCI DSS v4.0.1/10.5.1

**重要度:** 中

**リソースタイプ :** `AWS::S3::Bucket`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-default-lock-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-default-lock-enabled.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `mode`  |  S3 Object Lock の保持モード  |  列挙型  |  `GOVERNANCE`, `COMPLIANCE`  |  デフォルト値なし  | 

このコントロールは、Amazon S3 汎用バケットで Object Lock が有効になっているかどうかを確認します。バケットで Object Lock が有効になっていない場合、コントロールは失敗します。`mode` パラメータにカスタム値を指定したときは、S3 Object Lock が指定された保持モードを使用する場合にのみコントロールが成功します。

S3 Object Lock では、Write Once Read Many (WORM) モデルを使用してオブジェクトを保存できます。Object Lock により、S3 バケットのオブジェクトが削除または上書きされることを、一定期間または無期限に防止できます。S3 Object Lock を使用して、WORM ストレージを必要とする規制要件を満たしたり、オブジェクトの変更や削除に対する保護レイヤーを追加したりできます。

### 修正
<a name="s3-15-remediation"></a>

新規および既存の S3 バケットの Object Lock を設定するには、「*Amazon S3 ユーザーガイド*」の「[S3 オブジェクトロックの設定](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-configure.html)」を参照してください。

## [S3.17] S3 汎用バケットは保管時に で暗号化する必要があります AWS KMS keys
<a name="s3-17"></a>

**カテゴリ:** 保護 > データ保護 > 保管中のデータの暗号化

**関連する要件:** NIST.800-53.r5 SC-12(2)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 SI-7(6)、NIST.800-53.r5 AU-9、NIST.800-171.r2 3.8.9、NIST.800-171.r2 3.13.11、NIST.800-171.r2 3.13.16、PCI DSS v4.0.1/3.5.1

**重要度:** 中

**リソースタイプ :** `AWS::S3::Bucket`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/s3-default-encryption-kms.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-default-encryption-kms.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon S3 汎用バケットが AWS KMS key (SSE-KMS または DSSE-KMS) で暗号化されているかどうかをチェックします。バケットがデフォルトの暗号化 (SSE-S3) で暗号化されている場合、コントロールは失敗します。

サーバー側の暗号化 (SSE)とは、データを受信するアプリケーションまたはサービスによって、送信先でデータを暗号化することです。特に指定しない限り、デフォルトでは、S3 バケットはサーバー側の暗号化に Amazon S3 マネージドキー (SSE-S3) を使用します。ただし、コントロールを強化するために、代わりに AWS KMS keys (SSE-KMS または DSSE-KMS) でサーバー側の暗号化を使用するようにバケットを設定することもできます。Amazon S3 は、 AWS データセンターのディスクに書き込むときにオブジェクトレベルでデータを暗号化し、アクセス時に復号します。

### 修正
<a name="s3-17-remediation"></a>

SSE-KMS を使用して S3 バケットを暗号化するには、*Amazon S3*[S3 ユーザーガイド」の AWS KMS 「 (SSE-KMS) を使用したサーバー側の暗号化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/specifying-kms-encryption.html)の指定」を参照してください。DSSE-KMS を使用して S3 バケットを暗号化するには、*Amazon S3ユーザーガイド*[」の AWS KMS keys 「(DSSE-KMS) による二層式サーバー側の暗号化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/specifying-dsse-encryption.html)の指定」を参照してください。

## [S3.19] S3 アクセスポイントでは、ブロックパブリックアクセス設定を有効にする必要があります
<a name="s3-19"></a>

**関連する要件:** NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)、PCI DSS v4.0.1/1.4.4

**カテゴリ:** 保護 > セキュアなアクセス管理 > パブリックアクセスが不可能なリソース

**重要度:** 非常事態

**リソースタイプ :** `AWS::S3::AccessPoint`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/s3-access-point-public-access-blocks.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-access-point-public-access-blocks.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon S3 アクセスポイントでブロックパブリックアクセス設定が有効になっているかどうかをチェックします。アクセスポイントのブロックパブリックアクセス設定が有効になっていない場合、コントロールは失敗します。

Amazon S3 パブリックアクセスブロック機能は、アカウント、バケット、アクセスポイントの 3 つのレベルで S3 リソースへのアクセスを管理するのに役立ちます。各レベルの設定は個別に構成できるため、データに対して異なるレベルのパブリックアクセス制限を設定できます。アクセスポイントの設定で、より高いレベル (アカウントレベルまたはアクセスポイントに割り当てられたバケット) のより制限的な設定を個別にオーバーライドすることはできません。むしろ、アクセスポイントレベルの設定は付加的です。つまり、他のレベルの設定を補完し、連携して機能します。S3 アクセスポイントをパブリックにアクセス可能にする予定がない限り、ブロックパブリックアクセス設定を有効にする必要があります。

### 修正
<a name="s3-19-remediation"></a>

Amazon S3 は、現在、アクセスポイントの作成後におけるアクセスポイントのブロックパブリックアクセス設定の変更をサポートしていません。デフォルトでは、新しいアクセスポイントを作成すると、すべてのブロックパブリックアクセス設定が有効になります。これらの設定を特に無効にする必要がある場合を除いて、すべての設定を有効にしておくことをお勧めします。詳細については、「*Amazon Simple Storage Service ユーザーガイド*」の「[汎用バケットのアクセスポイントへのパブリックアクセスの管理](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-points-bpa-settings.html)」を参照してください。

## [S3.20] S3 汎用バケットでは MFA 削除が有効になっている必要があります
<a name="s3-20"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/2.1.2、CIS AWS Foundations Benchmark v3.0.0/2.1.2、CIS AWS Foundations Benchmark v1.4.0/2.1.3、NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)、NIST.800-53.r5 CM-3、NIST.800-53.r5 SC-5(2)

**カテゴリ:** 保護 > データ保護 > データ削除保護

**重要度:** 低

**リソースタイプ :** `AWS::S3::Bucket`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-mfa-delete-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-mfa-delete-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon S3 の汎用バケットに対して多要素認証 (MFA) 削除が有効になっているかどうかをチェックします。バケットに対して MFA 削除が有効になっていない場合、コントロールは失敗します。コントロールは、ライフサイクル設定を持つバケットの検出結果を生成しません。

S3 汎用バケットのバージョニングを有効にする場合は、オプションでバケットの MFA 削除を設定することで、別のセキュリティレイヤーを追加できます。この設定を行うと、バケット所有者はバケット内のオブジェクトのバージョンを削除したり、バケットのバージョニング状態を変更したりするために、すべてのリクエストに 2 つの認証形式を含める必要があります。MFA Delete は、バケット所有者のセキュリティ認証情報に不正なアクセスがあった場合などにセキュリティを強化します。また、MFA 削除は、削除アクションを開始したユーザーに MFA コードを使って MFA デバイスの物理的所有を証明するように要求したり、削除アクションに摩擦とセキュリティのレイヤーをさらに追加したりすることで、バケットの偶発的な削除を防ぎます。

**注記**  
このコントロールは、S3 汎用バケットで MFA 削除が有効になっている場合にのみ `PASSED` 検出結果を生成します。バケットに対して MFA 削除を有効にするには、バケットに対してバージョニングも有効にする必要があります。バケットのバージョニングとは、同じバケット内で S3 オブジェクトの複数のバリエーションを保持する方法です。さらに、ルートユーザーとしてログインしているバケット所有者のみが、MFA 削除を有効にして、バケットで削除アクションを実行できます。ライフサイクル設定を持つバケットで MFA 削除を使用することはできません。

### 修正
<a name="s3-20-remediation"></a>

S3 バケットのバージョニングを有効にして MFA 削除を設定するには、「*Amazon Simple Storage Service ユーザーガイド*」の「[MFA 削除の設定](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiFactorAuthenticationDelete.html)」を参照してください。

## [S3.22] S3 汎用バケットはオブジェクトレベルの書き込みイベントをログに記録する必要があります
<a name="s3-22"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/3.8、CIS AWS Foundations Benchmark v3.0.0/3.8、PCI DSS v4.0.1/10.2.1

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloudtrail-all-write-s3-data-event-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudtrail-all-write-s3-data-event-check.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロール AWS アカウント は、 に Amazon S3 バケットのすべての書き込みデータイベントを記録する AWS CloudTrail マルチリージョン証跡が少なくとも 1 つあるかどうかをチェックします。 Amazon S3 S3 バケットの書き込みデータイベントをログに記録するマルチリージョン証跡がアカウントに存在しない場合、コントロールは失敗します。

`GetObject`、`DeleteObject`、`PutObject` などの S3 オブジェクトレベルのオペレーションは、データイベントと呼ばれます。デフォルトでは、CloudTrail はデータイベントを記録しませんが、S3 バケットのデータイベントを記録するように証跡を設定できます。書き込みデータイベントのオブジェクトレベルのログ記録を有効にすると、S3 バケット内の個々のオブジェクト (ファイル) アクセスをログ記録できます。オブジェクトレベルのログ記録を有効にすると、Amazon CloudWatch Events を使用して、データコンプライアンス要件を満たし、包括的なセキュリティ分析を実行し、 のユーザー動作の特定のパターンをモニタリングし AWS アカウント、S3 バケット内のオブジェクトレベルの API アクティビティに対してアクションを実行できます。このコントロールは、すべての S3 バケットの書き込み専用またはすべてのタイプのデータイベントを記録するマルチリージョン証跡を設定すると、`PASSED` 検出結果を生成します。

### 修正
<a name="s3-22-remediation"></a>

S3 バケットのオブジェクトレベルのログ記録を有効にするには、「*Amazon Simple Storage Service ユーザーガイド*」の「[S3 バケットとオブジェクトの CloudTrail イベントログ記録の有効化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html)」を参照してください。

## [S3.23] S3 汎用バケットはオブジェクトレベルの読み取りイベントをログに記録する必要があります
<a name="s3-23"></a>

**関連する要件:** CIS AWS Foundations Benchmark v5.0.0/3.9、CIS AWS Foundations Benchmark v3.0.0/3.9、PCI DSS v4.0.1/10.2.1

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/cloudtrail-all-read-s3-data-event-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudtrail-all-read-s3-data-event-check.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロール AWS アカウント は、 に Amazon S3 バケットのすべての読み取りデータイベントを記録する AWS CloudTrail マルチリージョン証跡が少なくとも 1 つあるかどうかをチェックします。 Amazon S3 S3 バケットの読み取りデータイベントをログに記録するマルチリージョン証跡がアカウントにない場合、コントロールは失敗します。

`GetObject`、`DeleteObject`、`PutObject` などの S3 オブジェクトレベルのオペレーションは、データイベントと呼ばれます。デフォルトでは、CloudTrail はデータイベントを記録しませんが、S3 バケットのデータイベントを記録するように証跡を設定できます。読み取りデータイベントのオブジェクトレベルのログ記録を有効にすると、S3 バケット内の個々のオブジェクト (ファイル) アクセスをログ記録できます。オブジェクトレベルのログ記録を有効にすると、Amazon CloudWatch Events を使用して、データコンプライアンス要件を満たし、包括的なセキュリティ分析を実行し、 のユーザー動作の特定のパターンをモニタリングし AWS アカウント、S3 バケット内のオブジェクトレベルの API アクティビティに対してアクションを実行できます。このコントロールは、すべての S3 バケットの読み取り専用またはすべてのタイプのデータイベントを記録するマルチリージョン証跡を設定すると、`PASSED` 検出結果を生成します。

### 修正
<a name="s3-23-remediation"></a>

S3 バケットのオブジェクトレベルのログ記録を有効にするには、「*Amazon Simple Storage Service ユーザーガイド*」の「[S3 バケットとオブジェクトの CloudTrail イベントログ記録の有効化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html)」を参照してください。

## [S3.24] S3 マルチリージョンアクセスポイントでは、ブロックパブリックアクセス設定を有効にする必要があります
<a name="s3-24"></a>

**関連する要件:** PCI DSS v4.0.1/1.4.4

**カテゴリ:** 保護 > セキュアなネットワーク設定 > パブリックアクセス不可のリソース

**重要度:** 高

**リソースタイプ :** `AWS::S3::MultiRegionAccessPoint`

**AWS Config rule:** `s3-mrap-public-access-blocked` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon S3 マルチリージョンアクセスポイントでブロックパブリックアクセス設定が有効になっているかどうかをチェックします。マルチリージョンアクセスポイントでブロックパブリックアクセス設定が有効になっていない場合、コントロールは失敗します。

パブリックにアクセス可能なリソースは、不正アクセス、データ侵害、または脆弱性の悪用につながる可能性があります。認証および認可手段によるアクセスの制限は、機密情報を保護し、リソースの整合性を維持するのに役立ちます。

### 修正
<a name="s3-24-remediation"></a>

デフォルトでは、S3 マルチリージョンアクセスポイントに対してすべてのブロックパブリックアクセス設定が有効になります。詳細については、「*Amazon Simple Storage Service ユーザーガイド*」の「[Amazon S3 マルチリージョンアクセスポイントによるパブリックアクセスのブロック](https://docs.aws.amazon.com/AmazonS3/latest/userguide/multi-region-access-point-block-public-access.html)」を参照してください。マルチリージョンアクセスポイントを作成した後にブロックパブリックアクセス設定を変更することはできません。

## [S3.25] S3 ディレクトリバケットにはライフサイクル設定が必要です
<a name="s3-25"></a>

**カテゴリ:** 保護 > データ保護

**重要度:** 低

**リソースタイプ :** `AWS::S3Express::DirectoryBucket`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/s3express-dir-bucket-lifecycle-rules-check.html](https://docs.aws.amazon.com/config/latest/developerguide/s3express-dir-bucket-lifecycle-rules-check.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `targetExpirationDays`  |  オブジェクトの作成後、オブジェクトの有効期限が切れる日数。  |  整数  |  `1`～`2147483647`  |  デフォルト値なし  | 

このコントロールは、S3 ディレクトリバケットにライフサイクルルールが設定されているかどうかをチェックします。ディレクトリバケットにライフサイクルルールが設定されていない場合、またはバケットのライフサイクルルールでオプションで指定したパラメータ値と一致しない有効期限設定が指定されている場合、コントロールは失敗します。

Amazon S3 のライフサイクル設定とは、Amazon S3 がバケット内のオブジェクトのグループに適用するアクションを定義するルールセットです。S3 ディレクトリバケットの場合、経過時間 (日数) に基づいてオブジェクトの有効期限を指定するライフサイクルルールを作成できます。不完全なマルチパートアップロードを削除するライフサイクルルールを作成することもできます。汎用バケットなどの他のタイプの S3 バケットとは異なり、ディレクトリバケットは、ストレージクラス間でオブジェクトを移行するなど、ライフサイクルルールの他のタイプのアクションをサポートしていません。

### 修正
<a name="s3-25-remediation"></a>

S3 ディレクトリバケットのライフサイクル設定を定義するには、バケットのライフサイクルルールを作成します。詳細については、「*Amazon Simple Storage Service ユーザーガイド*」の「[ディレクトリバケットのライフサイクル設定の作成と管理](https://docs.aws.amazon.com/AmazonS3/latest/userguide/directory-bucket-create-lc.html)」を参照してください。

# SageMaker AI の Security Hub CSPM コントロール
<a name="sagemaker-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon SageMaker AI サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [SageMaker.1] Amazon SageMaker ノートブックインスタンスは、インターネットに直接アクセスできないようにする必要があります
<a name="sagemaker-1"></a>

**関連する要件:** NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)、PCI DSS v3.2.1/1.2.1、PCI DSS v3.2.1/1.3.1、PCI DSS v3.2.1/1.3.2、PCI DSS v3.2.1/1.3.4、PCI DSS v3.2.1/1.3.6、PCI DSS v4.0.1/1.4.4

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 高

**リソースタイプ :** `AWS::SageMaker::NotebookInstance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-notebook-no-direct-internet-access.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-notebook-no-direct-internet-access.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、SageMaker AI ノートブックインスタンスでインターネットへの直接アクセスが無効になっているかどうかをチェックします。ノートブックインスタンスで `DirectInternetAccess` フィールドが有効になっている場合、コントロールは失敗します。

VPC なしで SageMaker AI インスタンスを設定した場合、デフォルトではインスタンスでインターネットへの直接アクセスが有効になっています。VPC ありでインスタンスを設定し、デフォルト設定を **[無効化 - VPC 経由でインターネットにアクセスする]** に変更する必要があります。ノートブックからモデルをトレーニングまたはホストするには、インターネットアクセスが必要です。インターネットアクセスを有効にするには、VPC にインターフェイスエンドポイント (AWS PrivateLink) または NAT ゲートウェイ、およびアウトバウンド接続を許可するセキュリティグループが必要です。ノートブックインスタンスを VPC 内のリソースに接続する方法の詳細については、「*Amazon SageMaker AI デベロッパーガイド*」の「[ノートブックインスタンスを VPC 内のリソースに接続する](https://docs.aws.amazon.com/sagemaker/latest/dg/appendix-notebook-and-internet-access.html)」を参照してください。また、SageMaker AI 設定へのアクセスが認可されたユーザーのみに制限されていることも確認する必要があります。ユーザーに SageMaker AI の設定変更とリソースの変更を許可する IAM 許可を制限します。

### 修正
<a name="sagemaker-1-remediation"></a>

ノートブックインスタンスを作成した後は、インターネットアクセスの設定を変更することはできません。代わりに、インターネットアクセスがブロックされているインスタンスを停止して削除し、再作成できます。インターネットへの直接アクセスを許可するノートブックインスタンスを削除するには、「*Amazon SageMaker AI デベロッパーガイド*」で「[Use notebook instances to build models: Clean up](https://docs.aws.amazon.com/sagemaker/latest/dg/ex1-cleanup.html)」を参照してください。インターネットアクセスを拒否するノートブックインスタンスを再作成するには、「[ノートブックインスタンスを作成する](https://docs.aws.amazon.com/sagemaker/latest/dg/howitworks-create-ws.html)」を参照してください。**[ネットワーク] の [直接インターネットアクセス]** で、**[無効化 - VPC 経由でインターネットにアクセスする]** を選択します。

## [SageMaker.2] SageMaker ノートブックインスタンスはカスタム VPC で起動する必要があります
<a name="sagemaker-2"></a>

**関連する要件:** NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)

**カテゴリ:** 保護 > セキュアなネットワーク設定 > VPC 内のリソース

**重要度:** 高

**リソースタイプ :** `AWS::SageMaker::NotebookInstance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-notebook-instance-inside-vpc.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-notebook-instance-inside-vpc.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon SageMaker AI ノートブックインスタンスがカスタム仮想プライベートクラウド (VPC) 内で起動されているかどうかをチェックします。SageMaker AI ノートブックインスタンスがカスタム VPC 内で起動されない場合、または SageMaker AI サービス VPC で起動された場合、このコントロールは失敗します。

サブネットは、ある範囲の IP アドレスが示す VPC 内の領域です。インフラストラクチャの安全なネットワーク保護を確保するために、リソースは可能な限りカスタム VPC 内に保管することをお勧めします。Amazon VPC は、 専用の仮想ネットワークです AWS アカウント。Amazon VPC を使用すると、SageMaker AI Studio とノートブックインスタンスのネットワークアクセスとインターネット接続を制御できます。

### 修正
<a name="sagemaker-2-remediation"></a>

ノートブックインスタンスを作成した後は、VPC の設定を変更することはできません。代わりに、インスタンスを停止して削除し、再作成できます。手順については、「*Amazon SageMaker AI デベロッパーガイド*」で「[Use notebook instances to build models: Clean up](https://docs.aws.amazon.com/sagemaker/latest/dg/ex1-cleanup.html)」を参照してください。

## [SageMaker.3] ユーザーは SageMaker ノートブックインスタンスのルートアクセス権を付与されてはなりません
<a name="sagemaker-3"></a>

**関連する要件:** NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-6、NIST.800-53.r5 AC-6(10)、NIST.800-53.r5 AC-6(2)

**カテゴリ:** 保護 > セキュアなアクセス管理 > ルートユーザーのアクセス制限

**重要度:** 高

**リソースタイプ :** `AWS::SageMaker::NotebookInstance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-notebook-instance-root-access-check.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-notebook-instance-root-access-check.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon SageMaker AI ノートブックインスタンスでルートアクセスが有効になっていないかをチェックします。Amazon SageMaker AI ノートブックインスタンスでルートアクセスが有効になっている場合、コントロールは失敗します。

最小特権のプリンシパルに従い、意図せずに権限を過剰にプロビジョニングしないために、ルートアクセスをインスタンスリソースに制限することが、推奨されるセキュリティ上のベストプラクティスです。

### 修正
<a name="sagemaker-3-remediation"></a>

SageMaker AI ノートブックインスタンスへのルートアクセスを制限するには、「*Amazon SageMaker AI デベロッパーガイド*」の「[SageMaker AI ノートブックインスタンスへのルートアクセスを制御する](https://docs.aws.amazon.com/sagemaker/latest/dg/nbi-root-access.html)」を参照してください。

## [SageMaker.4] SageMaker エンドポイントの本番稼働バリアントの初期インスタンス数は 1 より大きい必要があります
<a name="sagemaker-4"></a>

**関連する要件:** NIST.800-53.r5 CP-10、NIST.800-53.r5 SC-5、NIST.800-53.r5 SC-36、NIST.800-53.r5 SA-13

**カテゴリ:** リカバリ > 耐障害性 > 高可用性

**重要度:** 中

**リソースタイプ :** `AWS::SageMaker::EndpointConfig`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-endpoint-config-prod-instance-count.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-endpoint-config-prod-instance-count.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、Amazon SageMaker AI エンドポイントの本番稼働用バリアントの初期インスタンス数が 1 より大きいかどうかを確認します。エンドポイントの本番稼働用バリアントの初期インスタンスが 1 つしかない場合、コントロールは失敗します。

インスタンス数が 1 を超える本番稼働用バリアントは、SageMaker AI によって管理されるマルチ AZ インスタンスの冗長性を許可します。複数のアベイラビリティーゾーンにリソースをデプロイすることは、アーキテクチャ内で高可用性を提供するための AWS ベストプラクティスです。高可用性は、セキュリティインシデントからの復旧に役立ちます。

**注記**  
このコントロールは、インスタンスベースのエンドポイント設定にのみ適用されます。

### 修正
<a name="sagemaker-4-remediation"></a>

その他のエンドポイント設定のパラメータの詳細については、「*Amazon SageMaker AI デベロッパーガイド*」の「[Create an endpoint configuration](https://docs.aws.amazon.com/sagemaker/latest/dg/serverless-endpoints-create.html#serverless-endpoints-create-config)」を参照してください。

## [SageMaker.5] SageMaker モデルでは、ネットワーク分離を有効にする必要があります
<a name="sagemaker-5"></a>

**カテゴリ:** 保護 > セキュアなネットワーク設定 > パブリックアクセス不可のリソース

**重要度:** 中

**リソースタイプ :** `AWS::SageMaker::Model`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-model-isolation-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-model-isolation-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon SageMaker AI でホストされるモデルでネットワーク分離が有効になっているかどうかをチェックします。ホストされたモデルの `EnableNetworkIsolation` パラメータが `False` に設定されている場合、コントロールは失敗します。

SageMaker AI トレーニングとデプロイされた推論コンテナは、デフォルトでインターネットが有効になっています。SageMaker AI でトレーニングコンテナや推論コンテナへの外部ネットワークアクセスを許可しないようにする場合は、ネットワーク分離を有効にします。ネットワーク分離を有効にすると、他の AWS のサービスとの間の呼び出しを含め、モデルコンテナとの間でインバウンドまたはあうんとバウンドのネットワーク呼び出しを行うことができなくなります。さらに、コンテナランタイム環境で使用できる AWS 認証情報はありません。ネットワーク分離を有効にすると、インターネットから SageMaker AI リソースへの意図しないアクセスを防ぐことができます。

**注記**  
2025 年 8 月 13 日、Security Hub CSPM はこのコントロールのタイトルと説明を変更しました。新しいタイトルと説明は、コントロールが Amazon SageMaker AI でホストされているモデルの `EnableNetworkIsolation` パラメータの設定をチェックしていることをより正確に反映しています。以前は、このコントロールのタイトルは *SageMaker models should block inbound traffic* でした。

### 修正
<a name="sagemaker-5-remediation"></a>

SageMaker AI モデルのネットワーク分離の詳細については、「*Amazon SageMaker AI デベロッパーガイド*」の「[Run training and inference containers in internet-free mode](https://docs.aws.amazon.com/sagemaker/latest/dg/mkt-algo-model-internet-free.html)」を参照してください。モデルの作成時にネットワーク分離を有効にするには、`EnableNetworkIsolation` パラメータの値を `True` に設定します。

## [SageMaker.6] SageMaker アプリのイメージ設定にはタグを付ける必要があります
<a name="sagemaker-6"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::SageMaker::AppImageConfig`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-app-image-config-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-app-image-config-tagged.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | 評価されたリソースに割り当てる必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目) | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし | 

このコントロールは、Amazon SageMaker AI アプリケーションイメージ設定 (`AppImageConfig`) に `requiredKeyTags` パラメータで指定されたタグキーがあるかどうかをチェックします。アプリケーションイメージ設定にタグキーがない場合、または `requiredKeyTags` パラメータで指定されたすべてのキーがない場合、コントロールは失敗します。`requiredKeyTags` パラメータの値を指定しない場合、コントロールはタグキーの存在のみをチェックし、アプリケーションイメージ設定にタグキーがない場合は失敗します。このコントロールはシステムタグを無視します。システムタグは自動的に付与され、`aws:` プレフィックスが付きます。

タグは、 AWS リソースを作成して割り当てるラベルです。各タグは、必要なタグキーとオプションのタグ値で設定されています。タグを使用して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。またそれらは、アクションと通知のリソース所有者を追跡するのにも役立ちます。タグを使用して、認可戦略として属性ベースのアクセス制御 (ABAC) を実装することもできます。ABAC 戦略の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。タグの詳細については、[「 AWS リソースのタグ付け」および「タグエディタユーザーガイド](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。

**注記**  
個人を特定できる情報 (PII) などの機密情報や秘匿性の高い情報はタグに格納しないでください。タグには多くの からアクセスできます AWS のサービス。それらは、プライベートデータや機密データに使用することを意図していません。

### 修正
<a name="sagemaker-6-remediation"></a>

Amazon SageMaker AI アプリイメージ設定 (`AppImageConfig`) にタグを追加するには、SageMaker AI API の [AddTags](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_AddTags.html) オペレーションを使用するか、 を使用している場合は [add-tags](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/add-tags.html) コマンド AWS CLIを実行します。

## [SageMaker.7] SageMaker イメージにはタグを付ける必要があります
<a name="sagemaker-7"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::SageMaker::Image`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-image-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-image-tagged.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | 評価されたリソースに割り当てる必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目) | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし | 

このコントロールは、Amazon SageMaker AI イメージに `requiredKeyTags` パラメータで指定されたタグキーがあるかどうかをチェックします。イメージにタグキーがない場合、または `requiredKeyTags` パラメータで指定されたすべてのキーがない場合、コントロールは失敗します。`requiredKeyTags` パラメータの値を指定しない場合、コントロールはタグキーの存在のみをチェックし、イメージにタグキーがない場合は失敗します。このコントロールはシステムタグを無視します。システムタグは自動的に付与され、`aws:` プレフィックスが付きます。

タグは、 AWS リソースを作成して割り当てるラベルです。各タグは、必要なタグキーとオプションのタグ値で設定されています。タグを使用して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。またそれらは、アクションと通知のリソース所有者を追跡するのにも役立ちます。タグを使用して、認可戦略として属性ベースのアクセス制御 (ABAC) を実装することもできます。ABAC 戦略の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。タグの詳細については、[「 AWS リソースのタグ付けとタグエディタユーザーガイド](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。

**注記**  
個人を特定できる情報 (PII) などの機密情報や秘匿性の高い情報はタグに格納しないでください。タグには多くの からアクセスできます AWS のサービス。それらは、プライベートデータや機密データに使用することを意図していません。

### 修正
<a name="sagemaker-7-remediation"></a>

Amazon SageMaker AI イメージにタグを追加するには、SageMaker AI API の [AddTags](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_AddTags.html) オペレーションを使用するか、 を使用している場合は AWS CLI add[-tags](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/add-tags.html) コマンドを実行します。

## [SageMaker.8] SageMaker ノートブックインスタンスは、サポートされているプラットフォームで実行する必要があります
<a name="sagemaker-8"></a>

**カテゴリ:** 検出 > 脆弱性、パッチ、バージョン管理

**重要度:** 中

**リソースタイプ :** `AWS::SageMaker::NotebookInstance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-notebook-instance-platform-version.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-notebook-instance-platform-version.html)

**スケジュールタイプ :** 定期的

**パラメータ :**
+ `supportedPlatformIdentifierVersions`: `notebook-al2-v3` (カスタマイズ不可)

このコントロールは、Amazon SageMaker AI ノートブックインスタンスに指定されたプラットフォーム識別子に基づいて、ノートブックインスタンスがサポートされているプラットフォームで実行されるように設定されているかどうかチェックします。サポートされなくなったプラットフォームでノートブックインスタンスを実行するように設定されている場合、コントロールは失敗します。

Amazon SageMaker AI ノートブックインスタンスのプラットフォームがサポートされなくなった場合、セキュリティパッチ、バグ修正、またはその他のタイプの更新を受信できない可能性があります。ノートブックインスタンスは引き続き機能する可能性がありますが、SageMaker AI セキュリティ更新プログラムや重大なバグ修正は受信しません。サポートされていないプラットフォームの使用に伴うリスクはユーザーが負うことになります。詳細については、「*Amazon SageMaker AI デベロッパーガイド*」の「[JupyterLab のバージョニング](https://docs.aws.amazon.com/sagemaker/latest/dg/nbi-jl.html)」を参照してください。

### 修正
<a name="sagemaker-8-remediation"></a>

Amazon SageMaker AI が現在サポートしているプラットフォームとその移行方法については、「*Amazon SageMaker AI デベロッパーガイド*」の「[Amazon Linux 2 notebook instances](https://docs.aws.amazon.com/sagemaker/latest/dg/nbi-al2.html)」を参照してください。

## [SageMaker.9] SageMaker データ品質ジョブ定義では、コンテナ間のトラフィック暗号化を有効にする必要があります
<a name="sagemaker-9"></a>

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::SageMaker::DataQualityJobDefinition`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-data-quality-job-encrypt-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-data-quality-job-encrypt-in-transit.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon SageMaker AI データ品質ジョブ定義でコンテナ間のトラフィックに対して暗号化が有効になっているかどうかを確認します。データ品質とドリフトをモニタリングするジョブの定義でコンテナ間のトラフィックに対して暗号化が有効になっていない場合、コントロールは失敗します。

コンテナ間のトラフィック暗号化を有効にすると、分散処理中の機密性の高い ML データがデータ品質分析のために保護されます。

### 修正
<a name="sagemaker-9-remediation"></a>

Amazon SageMaker AI のコンテナ間トラフィック暗号化の詳細については、「Amazon *Amazon SageMaker AI デベロッパーガイド*[」の「分散トレーニングジョブで ML コンピューティングインスタンス間の通信を保護する](https://docs.aws.amazon.com/sagemaker/latest/dg/train-encrypt.html)」を参照してください。データ品質ジョブ定義を作成するときに、 `EnableInterContainerTrafficEncryption`パラメータの値を に設定することで、コンテナ間のトラフィック暗号化を有効にできます`True`。

## [SageMaker.10] SageMaker モデルの説明可能性ジョブ定義では、コンテナ間のトラフィック暗号化を有効にする必要があります
<a name="sagemaker-10"></a>

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::SageMaker::ModelExplainabilityJobDefinition`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-model-explainability-job-encrypt-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-model-explainability-job-encrypt-in-transit.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon SageMaker モデルの説明可能性ジョブ定義でコンテナ間のトラフィック暗号化が有効になっているかどうかを確認します。モデルの説明可能性ジョブ定義でコンテナ間のトラフィック暗号化が有効になっていない場合、コントロールは失敗します。

コンテナ間のトラフィック暗号化を有効にすると、説明可能性分析のために、分散処理中のモデルデータ、トレーニングデータセット、中間処理結果、パラメータ、モデル重みなどの機密データ ML データが保護されます。

### 修正
<a name="sagemaker-10-remediation"></a>

既存の SageMaker モデルの説明可能性ジョブ定義では、コンテナ間のトラフィック暗号化を更新することはできません。コンテナ間のトラフィック暗号化を有効にして新しい SageMaker モデルの説明可能性ジョブ定義を作成するには、[API](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateModelExplainabilityJobDefinition.html) または [CLI](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/create-model-explainability-job-definition.html) または [ CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-sagemaker-modelexplainabilityjobdefinition.html) を使用して [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_MonitoringNetworkConfig.html#API_MonitoringNetworkConfig_Contents](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_MonitoringNetworkConfig.html#API_MonitoringNetworkConfig_Contents)を に設定します`True`。

## [SageMaker.11] SageMaker データ品質ジョブ定義では、ネットワーク分離を有効にする必要があります
<a name="sagemaker-11"></a>

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 中

**リソースタイプ :** `AWS::SageMaker::DataQualityJobDefinition`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-data-quality-job-isolation.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-data-quality-job-isolation.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon SageMaker AI データ品質モニタリングジョブ定義でネットワーク分離が有効になっているかどうかを確認します。データ品質とドリフトをモニタリングするジョブの定義でネットワーク分離が無効になっている場合、コントロールは失敗します。

ネットワーク分離は攻撃を軽減します。 は外部アクセスを表面化し、防止することで、不正な外部アクセス、偶発的なデータ漏洩、潜在的なデータ流出から保護します。

### 修正
<a name="sagemaker-11-remediation"></a>

SageMaker AI のネットワーク分離の詳細については、*Amazon SageMaker AI デベロッパーガイド*」の[「インターネットフリーモードでトレーニングコンテナと推論コンテナを実行する](https://docs.aws.amazon.com/sagemaker/latest/dg/mkt-algo-model-internet-free.html)」を参照してください。データ品質ジョブ定義を作成するときに、 `EnableNetworkIsolation`パラメータの値を に設定することで、ネットワーク分離を有効にできます`True`。

## [SageMaker.12] SageMaker モデルバイアスジョブ定義では、ネットワーク分離を有効にする必要があります
<a name="sagemaker-12"></a>

**カテゴリ:** 保護 > 安全なネットワーク設定 > リソースポリシー設定

**重要度:** 中

**リソースタイプ :** `AWS::SageMaker::ModelBiasJobDefinition`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-model-bias-job-isolation.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-model-bias-job-isolation.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、SageMaker モデルバイアスジョブ定義でネットワーク分離が有効になっているかどうかを確認します。モデルバイアスジョブ定義でネットワーク分離が有効になっていない場合、コントロールは失敗します。

ネットワーク分離により、SageMaker モデルバイアスジョブがインターネット経由で外部リソースと通信できなくなります。ネットワーク分離を有効にすることで、ジョブのコンテナがアウトバウンド接続を実行できないようにし、攻撃対象領域を減らし、機密データを流出から保護します。これは、規制されたデータまたは機密データを処理するジョブで特に重要です。

### 修正
<a name="sagemaker-12-remediation"></a>

ネットワーク分離を有効にするには、 `EnableNetworkIsolation`パラメータを に設定して新しいモデルバイアスジョブ定義を作成する必要があります`True`。ジョブ定義の作成後にネットワーク分離を変更することはできません。新しいモデルバイアスジョブ定義を作成するには、*Amazon SageMaker AI* [ CreateModelBiasJobDefinition](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateModelBiasJobDefinition.html)」を参照してください。

## [SageMaker.13] SageMaker モデル品質ジョブ定義では、コンテナ間のトラフィック暗号化を有効にする必要があります
<a name="sagemaker-13"></a>

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::SageMaker::ModelQualityJobDefinition`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-model-quality-job-encrypt-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-model-quality-job-encrypt-in-transit.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon SageMaker モデル品質ジョブ定義で、コンテナ間のトラフィックに対して転送中の暗号化が有効になっているかどうかを確認します。モデル品質ジョブ定義でコンテナ間のトラフィック暗号化が有効になっていない場合、コントロールは失敗します。

コンテナ間のトラフィック暗号化は、分散モデル品質モニタリングジョブ中にコンテナ間で送信されるデータを保護します。デフォルトでは、コンテナ間のトラフィックは暗号化されません。暗号化を有効にすると、処理中のデータの機密性が維持され、転送中のデータの保護に関する規制要件への準拠がサポートされます。

### 修正
<a name="sagemaker-13-remediation"></a>

Amazon SageMaker モデル品質ジョブ定義のコンテナ間トラフィック暗号化を有効にするには、適切な転送時の暗号化設定でジョブ定義を再作成する必要があります。モデル品質ジョブ定義を作成するには、*Amazon SageMaker AI* [ CreateModelQualityJobDefinition](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateModelQualityJobDefinition.html)」を参照してください。

## [SageMaker.14] SageMaker モニタリングスケジュールでは、ネットワーク分離を有効にする必要があります
<a name="sagemaker-14"></a>

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 中

**リソースタイプ :** `AWS::SageMaker::MonitoringSchedule`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-monitoring-schedule-isolation.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-monitoring-schedule-isolation.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon SageMaker モニタリングスケジュールでネットワーク分離が有効になっているかどうかを確認します。モニタリングスケジュールで EnableNetworkIsolation が false に設定されているか、設定されていない場合、コントロールは失敗します

ネットワーク分離により、モニタリングジョブがアウトバウンドネットワークコールを行うのを防ぎ、コンテナからのインターネットアクセスを排除することで攻撃対象領域を減らします。

### 修正
<a name="sagemaker-14-remediation"></a>

モニタリングスケジュールを作成または更新するときに NetworkConfig パラメータでネットワーク分離を設定する方法については、*Amazon SageMaker * [CreateMonitoringSchedule](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateMonitoringSchedule.html)」または[UpdateMonitoringSchedule](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateMonitoringSchedule.html)」を参照してください。

## [SageMaker.15] SageMaker モデルバイアスジョブ定義では、コンテナ間のトラフィック暗号化を有効にする必要があります
<a name="sagemaker-15"></a>

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::SageMaker::ModelBiasJobDefinition`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-model-bias-job-encrypt-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-model-bias-job-encrypt-in-transit.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、複数のコンピューティングインスタンスを使用するときに Amazon SageMaker モデルバイアスジョブ定義でコンテナ間のトラフィック暗号化が有効になっているかどうかを確認します。`EnableInterContainerTrafficEncryption` が false に設定されているか、インスタンス数が 2 以上のジョブ定義用に設定されていない場合、コントロールは失敗します。

EInterトラフィック暗号化は、分散モデルバイアスモニタリングジョブ中にコンピューティングインスタンス間で送信されるデータを保護します。暗号化は、インスタンス間で送信される重みなどのモデル関連情報への不正アクセスを防止します。

### 修正
<a name="sagemaker-15-remediation"></a>

SageMaker モデルバイアスジョブ定義のコンテナ間トラフィック暗号化を有効にするには、ジョブ定義が複数のコンピューティングインスタンスを使用する`True`ときに `EnableInterContainerTrafficEncryption`パラメータを に設定します。ML コンピューティングインスタンス間の通信を保護する方法については、*Amazon SageMaker AI デベロッパーガイド*[」の「分散トレーニングジョブで ML コンピューティングインスタンス間の通信を保護する](https://docs.aws.amazon.com/sagemaker/latest/dg/train-encrypt.html)」を参照してください。

# Secrets Manager の Security Hub CSPM コントロール
<a name="secretsmanager-controls"></a>

これらの AWS Security Hub CSPM コントロールは、 AWS Secrets Manager サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [SecretsManager.1] Secrets Manager のシークレットは、自動ローテーションを有効にする必要があります
<a name="secretsmanager-1"></a>

**関連する要件:** NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3(15)、PCI DSS v4.0.1/8.6.3、PCI DSS v4.0.1/8.3.9

**カテゴリ:** 保護 > セキュアな開発

**重要度:** 中

**リソースタイプ :** `AWS::SecretsManager::Secret`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/secretsmanager-rotation-enabled-check.html](https://docs.aws.amazon.com/config/latest/developerguide/secretsmanager-rotation-enabled-check.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `maximumAllowedRotationFrequency`  |  シークレットローテーション頻度の許容最大日数  |  整数  |  `1`～`365`  |  デフォルト値なし  | 

このコントロール AWS Secrets Manager は、 に保存されているシークレットが自動ローテーションで設定されているかどうかを確認します。シークレットが自動ローテーションで構成されていない場合、コントロールは失敗します。`maximumAllowedRotationFrequency` パラメータにカスタム値を指定したときは、指定された時間帯内にシークレットが自動的にローテーションされた場合にのみコントロールが成功します。

Secrets Manager は、組織のセキュリティ体制を向上するのに役立ちます。シークレットとは、データベース認証情報、パスワード、サードパーティーの API キーなどが含まれます。Secrets Manager を使用することで、シークレットを一元的に保存、シークレットの自動暗号化、シークレットへのアクセスコントロール、シークレットを安全かつ自動的にローテーションすることができます。

Secrets Manager はシークレットをローテーションできます。ローテーションを使用して、長期のシークレットを短期のシークレッに置き換えることができます。シークレットをローテーションすることで、権限のないユーザーが侵害されたシークレットを使用できる期間を制限することができます。このため、シークレットは頻繁にローテーションする必要があります。ローテーションの詳細については、「 *AWS Secrets Manager ユーザーガイド*」の「シー[AWS Secrets Manager クレットのローテーション](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html)」を参照してください。

### 修正
<a name="secretsmanager-1-remediation"></a>

Secrets Manager シークレットの自動ローテーションを有効にするには、「 *AWS Secrets Manager ユーザーガイド*」の[「コンソールを使用してシーク AWS Secrets Manager レットの自動ローテーションを設定する](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_turn-on-for-other.html)」を参照してください。ローテーションする AWS Lambda 関数を選択して設定する必要があります。

## [SecretsManager.2] 自動ローテーションを設定した Secrets Manager のシークレットは正常にローテーションする必要があります
<a name="secretsmanager-2"></a>

**関連する要件:** NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3(15)、PCI DSS v4.0.1/8.6.3、PCI DSS v4.0.1/8.3.9

**カテゴリ:** 保護 > セキュアな開発

**重要度:** 中

**リソースタイプ :** `AWS::SecretsManager::Secret`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/secretsmanager-scheduled-rotation-success-check.html](https://docs.aws.amazon.com/config/latest/developerguide/secretsmanager-scheduled-rotation-success-check.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、ローテーションスケジュールに基づいて AWS Secrets Manager シークレットが正常にローテーションされたかどうかをチェックします。`RotationOccurringAsScheduled` が `false` の場合、コントロールは失敗します。コントロールは、ローテーションがオンになっているシークレットのみを評価します。

Secrets Manager は、組織のセキュリティ体制を向上するのに役立ちます。シークレットとは、データベース認証情報、パスワード、サードパーティーの API キーなどが含まれます。Secrets Manager を使用することで、シークレットを一元的に保存、シークレットの自動暗号化、シークレットへのアクセスコントロール、シークレットを安全かつ自動的にローテーションすることができます。

Secrets Manager はシークレットをローテーションできます。ローテーションを使用して、長期のシークレットを短期のシークレッに置き換えることができます。シークレットをローテーションすることで、権限のないユーザーが侵害されたシークレットを使用できる期間を制限することができます。このため、シークレットは頻繁にローテーションする必要があります。

シークレットが自動的にローテーションされるように設定することに加えて、これらのシークレットがローテーションスケジュールに基づいて正常にローテーションするように設定する必要があります。

ローテーションの詳細については、「AWS Secrets Manager ユーザーガイド」の「[AWS Secrets Manager シークレットのローテーション](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html)」を参照してください。

### 修正
<a name="secretsmanager-2-remediation"></a>

自動ローテーションが失敗した場合、Secrets Manager の設定でエラーが発生している可能性があります。Secrets Manager でシークレットをローテーションさせるには、シークレットを所有するデータベースまたはサービスとの対話方法を定義する Lambda 関数を使用する必要があります。

シークレットのローテーションに関連する一般的なエラーの診断と修正については、*AWS Secrets Manager 「 ユーザーガイド*」の「シーク[レットの AWS Secrets Manager ローテーションのトラブルシューティング](https://docs.aws.amazon.com/secretsmanager/latest/userguide/troubleshoot_rotation.html)」を参照してください。

## [SecretsManager.3] 未使用の Secrets Manager のシークレットを削除します
<a name="secretsmanager-3"></a>

**関連する要件:** NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3(15)

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 中

**リソースタイプ :** `AWS::SecretsManager::Secret`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/secretsmanager-secret-unused.html](https://docs.aws.amazon.com/config/latest/developerguide/secretsmanager-secret-unused.html)

**スケジュールタイプ :** 定期的

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `unusedForDays`  |  シークレットを未使用のままにできる最大日数  |  整数  |  `1`～`365`  |  `90`  | 

このコントロールは、シー AWS Secrets Manager クレットが指定された期間内にアクセスされたかどうかを確認します。指定された時間枠を過ぎてもシークレットが使用されない場合、コントロールは失敗します。アクセス期間のカスタムパラメータ値を指定しない限り、Security Hub CSPM はデフォルト値の 90 日を使用します。

未使用のシークレットを削除することは、シークレットをローテーションするのと同様に重要です。未使用のシークレットは、これらのシークレットにアクセスする必要のない以前のユーザーによって悪用される可能性があります。また、より多くのユーザーがシークレットへのアクセスすると、誰かが誤って処理して権限のないエンティティに漏洩する可能性があるため、不正使用のリスクが高まります。未使用のシークレットを削除することで、必要としないユーザーからのシークレットへのアクセスを取り消すことができます。また、Secrets Manager の使用コスト削減にも役立ちます。したがって、未使用のシークレットを定期的に削除することが不可欠です。

### 修正
<a name="secretsmanager-3-remediation"></a>

非アクティブな Secrets Manager シークレットを削除するには、*AWS Secrets Manager 「 ユーザーガイド*」の「 [AWS Secrets Manager シークレットの削除](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_delete-secret.html)」を参照してください。

## [SecretsManager.4] Secrets Manager のシークレットは、指定された日数以内にローテーションする必要があります
<a name="secretsmanager-4"></a>

**関連する要件:** NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3(15)、PCI DSS v4.0.1/8.6.3、PCI DSS v4.0.1/8.3.9

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 中

**リソースタイプ :** `AWS::SecretsManager::Secret`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/secretsmanager-secret-periodic-rotation.html](https://docs.aws.amazon.com/config/latest/developerguide/secretsmanager-secret-periodic-rotation.html)

**スケジュールタイプ :** 定期的

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `maxDaysSinceRotation`  |  シークレットを未変更のままにできる最大日数  |  整数  |  `1`～`180`  |  `90`  | 

このコントロールは、シー AWS Secrets Manager クレットが指定された期間内に少なくとも 1 回ローテーションされているかどうかをチェックします。シークレットを少なくともこの頻度でローテーションしないと、コントロールは失敗します。ローテーション期間にカスタムパラメータ値を指定しない限り、Security Hub CSPM はデフォルト値の 90 日を使用します。

シークレットをローテーションすることで、 AWS アカウントでユーザーのシークレットが不正に使用されるリスクを減らすのに役立ちます。例えば、データベース認証情報、パスワード、サードパーティーの API キーおよび任意のテキストなどがあります。シークレットを長期間変更しない場合、シークレットが侵害される可能性が高くなります。

より多くのユーザーがシークレットへのアクセスすると、誰かが操作を誤り、権限のないエンティティに漏洩する可能性があります。シークレットは、ログとキャッシュデータを介して漏洩する可能性があります。これらはデバッグ目的で共有でき、デバッグ完了後に変更または取り消されることはありません。これらすべての理由から、シークレットは頻繁にローテーションする必要があります。

 AWS Secrets Managerでシークレットの自動ローテーションを設定できます。自動ローテーションにより、長期のシークレットを短期のシークレットに置き換えることが可能となり、侵害されるリスクを大幅に減少させるのに役立ちます｡ Secrets Manager のシークレットの自動ローテーションを設定することをお勧めします。詳細については、「AWS Secrets Manager ユーザーガイド」の「[AWS Secrets Manager シークレットのローテーション](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html)」を参照してください。

### 修正
<a name="secretsmanager-4-remediation"></a>

Secrets Manager シークレットの自動ローテーションを有効にするには、「 *AWS Secrets Manager ユーザーガイド*」の[「コンソールを使用してシーク AWS Secrets Manager レットの自動ローテーションを設定する](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_turn-on-for-other.html)」を参照してください。ローテーションする AWS Lambda 関数を選択して設定する必要があります。

## [SecretsManager.5] Secrets Manager のシークレットにはタグを付ける必要があります
<a name="secretsmanager-5"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::SecretsManager::Secret`

**AWS Config rule:** `tagged-secretsmanager-secret` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、 AWS Secrets Manager シークレットにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。シークレットにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、シークレットにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="secretsmanager-5-remediation"></a>

Secrets Manager シークレットにタグを追加するには、*AWS Secrets Manager *「 ユーザーガイド」の「タグシーク[AWS Secrets Manager レット](https://docs.aws.amazon.com/secretsmanager/latest/userguide/managing-secrets_tagging.html)」を参照してください。

# の Security Hub CSPM コントロール AWS Service Catalog
<a name="servicecatalog-controls"></a>

この AWS Security Hub CSPM コントロールは、 AWS Service Catalog サービスとリソースを評価します。コントロールは、すべての AWS リージョンで使用できるとは限りません。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [ServiceCatalog.1] Service Catalog ポートフォリオは AWS 組織内でのみ共有する必要があります
<a name="servicecatalog-1"></a>

**関連する要件:** NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-6、NIST.800-53.r5 CM-8、NIST.800-53.r5 SC-7

**カテゴリ:** 保護 > セキュアなアクセス管理

**重要度:** 中

**リソースタイプ :** `AWS::ServiceCatalog::Portfolio`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/service-catalog-shared-within-organization.html](https://docs.aws.amazon.com/config/latest/developerguide/service-catalog-shared-within-organization.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、 と AWS Organizations の統合が有効になっているときに、 が組織内のポートフォリオ AWS Service Catalog を共有するかどうかをチェックします。ポートフォリオが組織内で共有されていない場合、コントロールは失敗します。

Organizations 内でのみポートフォリオを共有すると、ポートフォリオが間違った AWS アカウントと共有されないようになります。Service Catalog ポートフォリオを組織内のアカウントと共有するために、Security Hub CSPM では、 `ORGANIZATION_MEMBER_ACCOUNT` の代わりに を使用することをお勧めします`ACCOUNT`。これにより、組織全体のアカウントに付与されたアクセスを制御できるため、管理が簡素化されます。Service Catalog ポートフォリオを外部アカウントと共有する必要がある場合は、このコントロールの[検出結果を自動的に抑制](automation-rules.md)するか、[無効](disable-controls-overview.md)にすることができます。

### 修正
<a name="servicecatalog-1-remediation"></a>

とのポートフォリオ共有を有効にするには AWS Organizations、 *AWS Service Catalog 管理者ガイド*の[「 との共有 AWS Organizations](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/catalogs_portfolios_sharing_how-to-share.html#portfolio-sharing-organizations)」を参照してください。

# Amazon SES の Security Hub CSPM コントロール
<a name="ses-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon Simple Email Service (Amazon SES) サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [SES.1] SES 連絡先リストにはタグを付ける必要があります
<a name="ses-1"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::SES::ContactList`

**AWS Config rule:** `tagged-ses-contactlist` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon SES 連絡先リストにパラメータ `requiredTagKeys` で定義された特定のキーを含むタグがあるかどうかをチェックします。連絡先リストにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、連絡先リストにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="ses-1-remediation"></a>

Amazon SES 連絡先リストにタグを追加するには、「*Amazon SES API v2 リファレンス*」の「[TagResource](https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_TagResource.html)」を参照してください。

## [SES.2] SES 設定セットにはタグを付ける必要があります
<a name="ses-2"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::SES::ConfigurationSet`

**AWS Config rule:** `tagged-ses-configurationset` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、Amazon SES 設定セットにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。設定セットにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、設定セットにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルで、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="ses-2-remediation"></a>

Amazon SES 設定セットにタグを追加するには、「*Amazon SES API v2 リファレンス*」の「[TagResource](https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_TagResource.html)」を参照してください。

## [SES.3] SES 設定セットでは、TLS を有効にして E メールを送信する必要があります
<a name="ses-3"></a>

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化 

**重要度:** 中

**リソースタイプ :** `AWS::SES::ConfigurationSet`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ses-sending-tls-required.html](https://docs.aws.amazon.com/config/latest/developerguide/ses-sending-tls-required.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon SES 設定セットに TLS 接続が必要かどうかをチェックします。設定セットの TLS ポリシーが に設定されていない場合、コントロールは失敗`'REQUIRE'`します。

デフォルトでは、Amazon SES は日和見 TLS を使用します。つまり、受信メールサーバーで TLS 接続を確立できない場合、E メールを暗号化せずに送信できます。E メール送信に TLS を適用すると、安全な暗号化された接続を確立できる場合にのみメッセージが配信されます。これにより、Amazon SES と受信者のメールサーバー間の送信中に E メールコンテンツの機密性と整合性を保護することができます。安全な TLS 接続を確立できない場合、メッセージは配信されないため、機密情報が公開される可能性があります。

**注記**  
TLS 1.3 は Amazon SES のデフォルトの配信方法ですが、設定セットを通じて TLS 要件を強制することなく、TLS 接続が失敗した場合にメッセージがプレーンテキストで配信される可能性があります。このコントロールを渡すには、SES 設定セットの配信オプション`'REQUIRE'`で TLS ポリシーを に設定する必要があります。TLS が必要な場合、メッセージは受信メールサーバーで TLS 接続を確立できる場合にのみ配信されます。

### 修正
<a name="ses-3-remediation"></a>

設定セットの TLS 接続を要求するように Amazon SES を設定するには、[Amazon SESデベロッパーガイド」の「Amazon SES とセキュリティプロトコル](https://docs.aws.amazon.com/ses/latest/dg/security-protocols.html#security-ses-to-receiver)」を参照してください。 *Amazon SES *

# Amazon SNS の Security Hub CSPM コントロール
<a name="sns-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon Simple Notification Service (Amazon SNS) サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [SNS.1] SNS トピックは、保管時に を使用して暗号化する必要があります AWS KMS
<a name="sns-1"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SI-7(6)、NIST.800-171.r2 3.13.11、NIST.800-171.r2 3.13.16

**カテゴリ:** 保護 > データ保護 > 保管中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::SNS::Topic`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/sns-encrypted-kms.html](https://docs.aws.amazon.com/config/latest/developerguide/sns-encrypted-kms.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon SNS トピックが AWS Key Management Service (AWS KMS) に管理されているキーを使用して保管中に暗号化されているかどうかをチェックします。SNS トピックがサーバー側の暗号化 (SSE) に KMS キーを使用しない場合、コントロールは失敗します。デフォルトでは、SNS はディスク暗号化を使用してメッセージとファイルを保存します。このコントロールに合格するには、代わりに暗号化に KMS キーを使用する必要があります。これにより、セキュリティレイヤーが追加され、アクセスコントロールの柔軟性が向上します。

保管中のデータを暗号化することで、ディスクに保存されているデータが認証されていないユーザーがアクセスするリスクが軽減されます AWS。データを読み取る前にデータを復号化するには、API の許可が必要です。セキュリティを強化するために、SNS トピックを KMS キーで暗号化することをお勧めします。

### 修正
<a name="sns-1-remediation"></a>

SNS トピックで SSE を有効にするには、「*Amazon Simple Notification Service デベロッパーガイド*」の「[Amazon SNS トピックのサーバー側の暗号化 (SSE) を有効にする](https://docs.aws.amazon.com/sns/latest/dg/sns-enable-encryption-for-topic.html)」を参照してください。SSE を使用する前に、トピックの暗号化とメッセージの暗号化と復号を許可する AWS KMS key ポリシーも設定する必要があります。詳細については、*Amazon Simple Notification Service デベロッパーガイド*の[AWS KMS 「アクセス許可の設定](https://docs.aws.amazon.com/sns/latest/dg/sns-key-management.html#sns-what-permissions-for-sse)」を参照してください。

## [SNS.2] トピックに送信される通知メッセージでは、配信ステータスのログ記録を有効にする必要があります
<a name="sns-2"></a>

**重要**  
Security Hub CSPM は、2024 年 4 月にこのコントロールを廃止しました。詳細については、「[Security Hub CSPM コントロールの変更ログ](controls-change-log.md)」を参照してください。

**関連する要件:** NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::SNS::Topic`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/sns-topic-message-delivery-notification-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/sns-topic-message-delivery-notification-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、エンドポイントの Amazon SNS トピックに送信される通知メッセージの配信ステータスで、ログ記録が有効になっているかどうかをチェックします。メッセージの配信ステータス通知が有効になっていない場合、このコントロールは失敗します。

ログ記録は、サービスの信頼性、可用性、パフォーマンスを維持するための重要な要素です。メッセージの配信ステータスをログ記録することで、以下のようなオペレーション上のインサイトを得ることができます。
+ メッセージが Amazon SNS エンドポイントに配信されたかどうかを知ることができます。
+ Amazon SNS エンドポイントから Amazon SNS に送信された応答を識別します。
+ メッセージの滞留時間 (メッセージの発行から Amazon SNS エンドポイントに渡されるまでの時間) を決定する。

### 修正
<a name="sns-2-remediation"></a>

トピックの配信ステータスロギングを設定する方法については、「*Amazon Simple Notification Service デベロッパーガイド*」の「[Amazon SNS メッセージ配信ステータス](https://docs.aws.amazon.com/sns/latest/dg/sns-topic-attributes.html)」を参照してください。

## [SNS.3] SNS トピックにはタグを付ける必要があります
<a name="sns-3"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::SNS::Topic`

**AWS Config rule:** `tagged-sns-topic` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、Amazon SNS トピックにパラメータ `requiredTagKeys` で定義された特定のキーを含むタグがあるかどうかをチェックします。トピックにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、トピックにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="sns-3-remediation"></a>

SNS トピックにタグを追加するには、「*Amazon Simple Notification Service デベロッパーガイド*」の「[Amazon SNS トピックタグの設定](https://docs.aws.amazon.com/sns/latest/dg/sns-tags-configuring.html)」を参照してください。

## [SNS.4] SNS トピックアクセスポリシーはパブリックアクセスを許可しないでください
<a name="sns-4"></a>

**カテゴリ:** 保護 > セキュアなネットワーク設定 > パブリックアクセス不可のリソース

**重要度:** 非常事態

**リソースタイプ :** `AWS::SNS::Topic`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/sns-topic-no-public-access.html](https://docs.aws.amazon.com/config/latest/developerguide/sns-topic-no-public-access.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon SNS トピックアクセスポリシーがパブリックアクセスを許可するかどうかを確認します。SNS トピックアクセスポリシーでパブリックアクセスが許可されている場合、このコントロールは失敗します。

特定のトピックに関連付ける Amazon SNS アクセスポリシーにより、そのトピックを操作できるユーザー (トピックにメッセージを発行できるユーザーまたはサブスクライブできるユーザーなど) を制限できます。SNS ポリシーは AWS アカウント、他のユーザー、または独自の 内のユーザーにアクセス権を付与できます AWS アカウント。トピックポリシーの `Principal` フィールドにワイルドカード (\$1) を指定し、トピックポリシーを制限する条件がないと、攻撃者によるデータの流出、サービス拒否、またはサービスへの望ましくないメッセージの挿入につながる可能性があります。

**注記**  
このコントロールはワイルドカード文字または変数を使用するポリシー条件を評価しません。`PASSED` 検出結果を生成するには、トピックの Amazon SNS アクセスポリシーの条件は固定値のみを使用する必要があります。固定値は、ワイルドカード文字やポリシー変数を含まない値です。ポリシー変数に関する詳細については、「*AWS Identity and Access Management ユーザーガイド*」の「[変数およびタグ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html)」を参照してください。

### 修正
<a name="sns-4-remediation"></a>

SNS トピックのアクセスポリシーを更新するには、「*Amazon Simple Notification Service デベロッパーガイド*」の「[Amazon SNSでのアクセス管理の概要](https://docs.aws.amazon.com/sns/latest/dg/sns-overview-of-managing-access.html)」を参照してください。

# Amazon SQS の Security Hub CSPM コントロール
<a name="sqs-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon Simple Queue Service (Amazon SQS) サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [SQS.1] Amazon SQS キューは保管中に暗号化する必要があります
<a name="sqs-1"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-3(6)、NIST.800-53.r5 SC-13、NIST.800-53.r5 SC-28、NIST.800-53.r5 SC-28(1)、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SI-7(6)

**カテゴリ:** 保護 > データ保護 > 保管中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::SQS::Queue`

**AWS Config rule:** `sqs-queue-encrypted` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon SQS キューが保管中に暗号化されるかどうかをチェックします。キューが SQS マネージドキー (SSE-SQS) または AWS Key Management Service () キー (SSE-KMS AWS KMS) で暗号化されていない場合、コントロールは失敗します。

保管中のデータを暗号化すると、認証されていないユーザーがディスクに保存されているデータにアクセスするリスクが低減されます。サーバー側の暗号化 (SSE) は、SQS マネージド暗号化キー (SSE-SQS) または AWS KMS キー (SSE-KMS) を使用して、SQS キュー内のメッセージの内容を保護します。

### 修正
<a name="sqs-1-remediation"></a>

SQS キューの SSE を設定するには、「*Amazon Simple Queue Service デベロッパーガイド*」の「[キューのサーバー側の暗号化 (SSE) の設定 (コンソール)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-sse-existing-queue.html)」を参照してください。

## [SQS.2] SQS キューにはタグを付ける必要があります
<a name="sqs-2"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::SQS::Queue`

**AWS Config rule:** `tagged-sqs-queue` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、Amazon SQS キューにパラメータ `requiredTagKeys` で定義された特定のキーを持つタグがあるかどうかをチェックします。キューにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、キューにキーがタグ付けされていない場合に失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="sqs-2-remediation"></a>

Amazon SQS コンソールを使用して既存のキューにタグを追加するには、「*Amazon Simple Queue Service デベロッパーガイド*」の[Amazon SQSキュー (コンソール) のコスト配分タグの設定](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-tag-queue.html)」を参照してください。

## [SQS.3] SQS トピックアクセスポリシーはパブリックアクセスを許可しないでください
<a name="sqs-3"></a>

**カテゴリ:** 保護 > セキュアなアクセス管理 > パブリックアクセスが不可能なリソース

**重要度:** 非常事態

**リソースタイプ :** `AWS::SQS::Queue`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/sqs-queue-no-public-access.html](https://docs.aws.amazon.com/config/latest/developerguide/sqs-queue-no-public-access.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon SQS アクセスポリシーが SQS キューへのパブリックアクセスを許可するかどうかをチェックします。SQS アクセスポリシーでキューへのパブリックアクセスが許可されている場合、このコントロールは失敗します。

Amazon SQS アクセスポリシーでは、SQS キューへのパブリックアクセスを許可できます。これにより、匿名ユーザーまたは認証された IAM ID AWS がキューにアクセスできるようになります。SQS アクセスポリシーは、通常、ポリシーの `Principal` 要素でワイルドカード文字 (`*`) を指定し、適切な条件を使用してキューへのアクセスを制限するのではなく、またはその両方を指定することで、このアクセスを提供します。SQS アクセスポリシーでパブリックアクセスが許可されている場合、サードパーティーはキューからのメッセージの受信、キューへのメッセージの送信、キューのアクセスポリシーの変更などのタスクを実行できます。これにより、データ流出、サービス拒否、脅威アクターによるキューへのメッセージの挿入などのイベントが発生する可能性があります。

**注記**  
このコントロールはワイルドカード文字または変数を使用するポリシー条件を評価しません。`PASSED` 検出結果を生成するには、キューの Amazon SQS アクセスポリシーの条件は固定値のみを使用する必要があります。固定値は、ワイルドカード文字やポリシー変数を含まない値です。ポリシー変数に関する詳細については、「*AWS Identity and Access Management ユーザーガイド*」の「[変数およびタグ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html)」を参照してください。

### 修正
<a name="sqs-3-remediation"></a>

SQS キューの SQS アクセスポリシーの設定については、「*Amazon Simple Queue Service デベロッパーガイド*」の「[Using custom policies with the Amazon SQS Access Policy Language](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-creating-custom-policies.html)」を参照してください。

# Step Functions の Security Hub CSPM コントロール
<a name="stepfunctions-controls"></a>

これらの AWS Security Hub CSPM コントロールは、 AWS Step Functions サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [StepFunctions.1] Step Functions ステートマシンではログ記録がオンになっている必要があります
<a name="stepfunctions-1"></a>

**関連する要件:** PCI DSS v4.0.1/10.4.2

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::StepFunctions::StateMachine`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/step-functions-state-machine-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/step-functions-state-machine-logging-enabled.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  `logLevel`  |  最小ログ記録レベル  |  列挙型  |  `ALL, ERROR, FATAL`  |  デフォルト値なし  | 

このコントロールは、 AWS Step Functions ステートマシンでログ記録が有効になっているかどうかをチェックします。ステートマシンでログ記録が有効になっていない場合、コントロールは失敗します。`logLevel` パラメータにカスタム値を指定したときは、ステートマシンで指定されたログ記録レベルがオンになっている場合にのみコントロールが成功します。

モニタリングは、Step Functions の信頼性、可用性、パフォーマンスを維持するのに役立ちます。マルチポイント障害をより簡単にデバッグできるように、 AWS のサービス 使用する からモニタリングデータを収集する必要があります。Step Functions のステートマシンにログ記録の設定を定義しておくと、Amazon CloudWatch Logs で実行履歴と結果を追跡できます。オプションで、エラーまたは致命的なイベントのみを追跡できます。

### 修正
<a name="stepfunctions-1-remediation"></a>

Step Functions ステートマシンのログ記録を有効にするには、「*AWS Step Functions デベロッパーガイド*」の「[ログ記録の設定](https://docs.aws.amazon.com/step-functions/latest/dg/cw-logs.html#monitoring-logging-configure)」を参照してください。

## [StepFunctions.2] Step Functions アクティビティにはタグを付ける必要があります
<a name="stepfunctions-2"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::StepFunctions::Activity`

**AWS Config rule:**`tagged-stepfunctions-activity` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし  | 

このコントロールは、 AWS Step Functions アクティビティにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。アクティビティにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、アクティビティにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="stepfunctions-2-remediation"></a>

Step Functions アクティビティにタグを追加するには、「*AWS Step Functions デベロッパーガイド*」の「[Step Functions のタグ付け](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-tagging.html)」を参照してください。

# Systems Manager の Security Hub CSPM コントロール
<a name="ssm-controls"></a>

これらの AWS Security Hub CSPM コントロールは、 AWS Systems Manager (SSM) サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [SSM.1] Amazon EC2 インスタンスは によって管理する必要があります AWS Systems Manager
<a name="ssm-1"></a>

**関連する要件:** PCI DSS v3.2.1/2.4、NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)、NIST.800-53.r5 CM-8、NIST.800-53.r5 CM-8(1)、NIST.800-53.r5 CM-8(2)、NIST.800-53.r5 CM-8(3)、NIST.800-53.r5 SA-15(2)、NIST.800-53.r5 SA-15(8)、NIST.800-53.r5 SA-3、NIST.800-53.r5 SI-2(3)

**カテゴリ:** 識別 > インベントリ

**重要度:** 中

**評価されたリソース:** `AWS::EC2::Instance`

**必要な AWS Config 記録リソース:** `AWS::EC2::Instance`、 `AWS::SSM::ManagedInstanceInventory`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-managed-by-systems-manager.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-managed-by-systems-manager.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、アカウントで停止および実行中の EC2 インスタンスが によって管理されているかどうかを確認します AWS Systems Manager。Systems Manager AWS のサービス は、 AWS インフラストラクチャの表示と制御に使用できる です。

セキュリティとコンプライアンスを維持するために、Systems Manager は停止中および実行中のマネージドインスタンスをスキャンします。マネージドインスタンスとは、Systems Manager で使用するために設定されたマシンです。Systems Manager が検出したポリシー違反について報告または是正処置を講じます。Systems Manager は、マネージドインスタンスを設定して維持するのにも役立ちます。詳細については、[AWS Systems Manager ユーザーガイド](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)を参照してください。

**注記**  
このコントロールは、 によって管理される AWS Elastic Disaster Recovery レプリケーションサーバーインスタンスである EC2 インスタンスの検出`FAILED`結果を生成します AWS。レプリケーションサーバーインスタンスは、ソースサーバーからの継続的なデータレプリケーション AWS Elastic Disaster Recovery をサポートするために によって自動的に起動される EC2 インスタンスです。 AWS は、これらのインスタンスから Systems Manager (SSM) エージェントを意図的に削除して分離を維持し、意図しないアクセスパスの可能性を防止します。

### 修正
<a name="ssm-1-remediation"></a>

を使用した EC2 インスタンスの管理の詳細については AWS Systems Manager、*AWS Systems Manager 「 ユーザーガイド*」の[Amazon EC2 ホスト管理](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-host-management.html)」を参照してください。 AWS Systems Manager コンソールの**「設定オプション**」セクションで、デフォルト設定のままにするか、必要に応じて設定を変更できます。

## [SSM.2] Systems Manager によって管理される Amazon EC2 インスタンスは、パッチのインストール後に、パッチコンプライアンスのステータスが COMPLIANT である必要があります
<a name="ssm-2"></a>

**関連する要件:** NIST.800-53.r5 CM-8(3)、NIST.800-53.r5 SI-2、NIST.800-53.r5 SI-2(2)、NIST.800-53.r5 SI-2(3)、NIST.800-53.r5 SI-2(4)、NIST.800-53.r5 SI-2(5)、NIST.800-171.r2 3.7.1、PCI DSS v3.2.1/6.2、PCI DSS v4.0.1/2.2.1、PCI DSS v4.0.1/6.3.3

**カテゴリ:** 検出 > 検出サービス 

**重要度:** 高

**リソースタイプ :** `AWS::SSM::PatchCompliance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-managedinstance-patch-compliance-status-check.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-managedinstance-patch-compliance-status-check.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、インスタンスへのパッチインストール後、Systems Manager パッチコンプライアンスのコンプライアンスステータスが、`COMPLIANT` と `NON_COMPLIANT` のどちらであるかをチェックします。コンプライアンスステータスが `NON_COMPLIANT` の場合、コントロールは失敗します。このコントロールは、Systems Manager Patch Manager によって管理されているインスタンスのみをチェックします。

組織の要求に応じて EC2 インスタンスにパッチを適用すると、 AWS アカウントのアタックサーフェスが低減されます。

### 修正
<a name="ssm-2-remediation"></a>

Systems Manager では、[パッチポリシー](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-policies.html)を使用して、マネージドインスタンスのパッチ適用を設定することを推奨しています。次の手順で説明するように、[Systems Manager のドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-ssm-documents.html)を使用してインスタンスにパッチを適用することもできます。

**非準拠のパッチを修正するには**

1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) で AWS Systems Manager コンソールを開きます。

1. **[ノード管理]** で、**[コマンドを実行する]** を選択し、**[コマンドを実行する]** を選択します。

1. **AWS-RunPatchBaseline** のオプションを選択します。

1. **[Operation]** (オペレーション) を **[Install]** (インストール) に変更します。

1. **[インスタンスを手動で選択する]** を選択し、非準拠のインスタンスを選択します。

1. **[Run]** (実行) を選択します。

1. コマンドの完了後に、パッチを適用したインスタンスの新しいコンプライアンスステータスをモニタリングするには、ナビゲーションペインで **[コンプライアンス]** を選択します。

## [SSM.3] Systems Manager によって管理される Amazon EC2 インスタンスの関連付けコンプライアンスのステータスは COMPLIANT である必要があります
<a name="ssm-3"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2、NIST.800-53.r5 CM-2(2)、NIST.800-53.r5 CM-8、NIST.800-53.r5 CM-8(1)、NIST.800-53.r5 CM-8(3)、NIST.800-53.r5 SI-2(3)、PCI DSS v3.2.1/2.4、PCI DSS v4.0.1/2.2.1、PCI DSS v4.0.1/6.3.3

**カテゴリ:** 検出 > 検出サービス

**重要度:** 低

**リソースタイプ :** `AWS::SSM::AssociationCompliance`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-managedinstance-association-compliance-status-check.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-managedinstance-association-compliance-status-check.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、 AWS Systems Manager 関連付けコンプライアンスのステータスが であるか`COMPLIANT`、インスタンスで関連付けが実行され`NON_COMPLIANT`た後であるかをチェックします。関連付けのコンプライアンスステータスが `NON_COMPLIANT` の場合、コントロールは失敗します。

State Manager の関連付けは、マネージドインスタンスに割り当てられる設定です。この設定では、インスタンスで維持する状態を定義します。例えば、関連付けでは、アンチウイルスソフトウェアをインスタンス上にインストールして実行する必要があること、または特定のポートを閉じる必要があることを指定できます。

State Manager の関連付けを 1 つまたは複数作成することで、コンプライアンスステータス情報をすぐに表示できるようになります。コンプライアンスステータスは、 コンソールで、または AWS CLI コマンドや対応する Systems Manager API アクションに応じて表示できます。関連付けでは、設定コンプライアンスはコンプライアンスステータスを表示します (`Compliant` または `Non-compliant`)。また、関連付けに割り当てられた `Critical` または `Medium` などの重要度レベルを表示します。

State Manager 関連付けのコンプライアンスの詳細については、「AWS Systems Manager ユーザーガイド」の「[State Manager 関連付けのコンプライアンスについて](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-compliance-about.html#sysman-compliance-about-association)」を参照してください。

### 修正
<a name="ssm-3-remediation"></a>

失敗した関連付けは、ターゲットや Systems Manager ドキュメント名など、さまざまなものに関連している可能性があります。この問題を修正するには、まず関連付けの履歴を表示し、関連付けを特定して調査する必要があります。関連付けの履歴を表示するには、「*AWS Systems Manager ユーザーガイド*」の「[関連付けの履歴の表示](https://docs.aws.amazon.com/systems-manager/latest/userguide/state-manager-associations-history.html)」を参照してください。

調査後、関連付けを編集して特定された問題を修正できます。関連付けを編集して、新しい名前やスケジュール、重要度レベル、ターゲットを指定できます。関連付けを編集すると、 は新しいバージョン AWS Systems Manager を作成します。関連付けの編集については、「*AWS Systems Manager ユーザーガイド*」の「[関連付けの編集と新しいバージョンの作成](https://docs.aws.amazon.com/systems-manager/latest/userguide/state-manager-associations-edit.html)」を参照してください。

## [SSM.4] SSM ドキュメントはパブリックにしないでください
<a name="ssm-4"></a>

**関連する要件:** NIST.800-53.r5 AC-21、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-4、NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 AC-6、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(20)、NIST.800-53.r5 SC-7(21)、NIST.800-53.r5 SC-7(3)、NIST.800-53.r5 SC-7(4)、NIST.800-53.r5 SC-7(9)

**カテゴリ:** 保護 > セキュアなネットワーク設定 > パブリックアクセス不可のリソース

**重要度:** 非常事態

**リソースタイプ :** `AWS::SSM::Document`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ssm-document-not-public.html](https://docs.aws.amazon.com/config/latest/developerguide/ssm-document-not-public.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、アカウントが所有する AWS Systems Manager ドキュメントがパブリックかどうかをチェックします。所有者として `Self` の Systems Manager ドキュメントがパブリックの場合、このコントロールは失敗します。

パブリックの Systems Manager ドキュメントは、ドキュメントへの意図しないアクセスを許可する場合があります。パブリック Systems Manager ドキュメントは、アカウント、リソース、および内部プロセスに関する貴重な情報を公開する可能性があります。

ユースケースでパブリック共有が必要な場合を除き、`Self` 所有者として Systems Manager ドキュメントのパブリック共有設定をブロックすることを推奨します。

### 修正
<a name="ssm-4-remediation"></a>

Systems Manager ドキュメントの共有の設定については、「*AWS Systems Manager ユーザーガイド*」の「[SSM ドキュメントの共有](https://docs.aws.amazon.com/systems-manager/latest/userguide/documents-ssm-sharing.html#ssm-how-to-share)」を参照してください。

## [SSM.5] SSM ドキュメントにはタグを付ける必要があります
<a name="ssm-5"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::SSM::Document`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ssm-document-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/ssm-document-tagged.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | 評価されたリソースに割り当てる必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目) | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし | 

このコントロールは、 AWS Systems Manager ドキュメントに `requiredKeyTags`パラメータで指定されたタグキーがあるかどうかをチェックします。ドメインにタグキーがない場合、または `requiredKeyTags` パラメータで指定されたすべてのキーがない場合、コントロールは失敗します。`requiredKeyTags` パラメータの値を指定しない場合、コントロールはタグキーの存在のみをチェックし、ドキュメントにタグキーがない場合に失敗します。このコントロールはシステムタグを無視します。システムタグは自動的に付与され、`aws:` プレフィックスが付きます。このコントロールは、Amazon が所有する Systems Manager ドキュメントを評価しません。

タグは、 AWS リソースを作成して割り当てるラベルです。各タグは、必要なタグキーとオプションのタグ値で設定されています。タグを使用して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。またそれらは、アクションと通知のリソース所有者を追跡するのにも役立ちます。タグを使用して、認可戦略として属性ベースのアクセス制御 (ABAC) を実装することもできます。ABAC 戦略の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。タグの詳細については、[「 AWS リソースのタグ付け」および「タグエディタユーザーガイド](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。

**注記**  
個人を特定できる情報 (PII) などの機密情報や秘匿性の高い情報はタグに格納しないでください。タグには多くの からアクセスできます AWS のサービス。それらは、プライベートデータや機密データに使用することを意図していません。

### 修正
<a name="ssm-5-remediation"></a>

 AWS Systems Manager ドキュメントにタグを追加するには、 AWS Systems Manager API の [AddTagsToResource](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html) オペレーションを使用するか、 を使用している場合は AWS CLI add[add-tags-to-resource](https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html) コマンドを実行します。 AWS Systems Manager コンソールを使用することもできます。

## [SSM.6] SSM Automation では CloudWatch ログ記録が有効になっている必要があります
<a name="ssm-6"></a>

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ssm-automation-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/ssm-automation-logging-enabled.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールはAmazon CloudWatch ログ記録が AWS Systems Manager (SSM) Automation で有効になっているかどうかをチェックします。SSM Automation で CloudWatch ログ記録が有効になっていない場合、コントロールは失敗します。

SSM Automation は、事前定義されたランブックまたはカスタムランブックを使用して、リソースを大規模 AWS にデプロイ、設定、管理するための自動ソリューションを構築するのに役立つ AWS Systems Manager ツールです。組織の運用上またはセキュリティ上の要件を満たすために、実行されるスクリプトの記録が必要となることがあります。ランブック内にある `aws:executeScript` アクションからの出力は、指定した Amazon CloudWatch Logs ロググループに送信するために SSM Automation を設定することができます。CloudWatch Logs を使用すると、さまざまな AWS のサービスからのログファイルについて、モニタリング、保存、アクセスが行えます。

### 修正
<a name="ssm-6-remediation"></a>

SSM Automation で CloudWatch ログ記録を有効にする方法については、「*AWS Systems Manager ユーザーガイド*」の「[CloudWatch Logs を使用した自動アクション出力のログ記録](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-action-logging.html)」を参照してください。

## [SSM.7] SSM ドキュメントでは、パブリック共有ブロック設定を有効にする必要があります
<a name="ssm-7"></a>

**カテゴリ:** 保護 > セキュアなアクセス管理 > パブリックアクセスが不可能なリソース

**重要度:** 非常事態

**リソースタイプ :** `AWS::::Account`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/ssm-automation-block-public-sharing.html](https://docs.aws.amazon.com/config/latest/developerguide/ssm-automation-block-public-sharing.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、 AWS Systems Manager ドキュメントでブロックパブリック共有設定が有効になっているかどうかをチェックします。Systems Manager ドキュメントでブロックパブリック共有設定が無効になっていると、コントロールは失敗します。

 AWS Systems Manager (SSM) ドキュメントのブロックパブリック共有設定は、アカウントレベルの設定です。この設定を有効にすると、SSM ドキュメントへの不要なアクセスを防止できます。この設定を有効にしても、現在パブリックと共有している SSM ドキュメントには影響しません。ユースケースでパブリック共有を有効にする必要がある場合を除き、設定共有ブロック設定をオンにすることをお勧めします。設定は、それぞれ異なる場合があります AWS リージョン。

### 修正
<a name="ssm-7-remediation"></a>

 AWS Systems Manager (SSM) ドキュメントのブロックパブリック共有設定を有効にする方法については、「*AWS Systems Manager ユーザーガイド*」の「[SSM ドキュメントのパブリック共有をブロックする](https://docs.aws.amazon.com/systems-manager/latest/userguide/documents-ssm-sharing.html#block-public-access)」を参照してください。

# の Security Hub CSPM コントロール AWS Transfer Family
<a name="transfer-controls"></a>

これらの AWS Security Hub CSPM コントロールは、 AWS Transfer Family サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [Transfer.1] AWS Transfer Family ワークフローにはタグを付ける必要があります
<a name="transfer-1"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::Transfer::Workflow`

**AWS Config rule:** `tagged-transfer-workflow` (カスタム Security Hub CSPM ルール)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | 評価されたリソースに含める必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目)  | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 |  No default value  | 

このコントロールは、 AWS Transfer Family ワークフローにパラメータ で定義された特定のキーを持つタグがあるかどうかをチェックします`requiredTagKeys`。ワークフローにタグキーがない場合、またはパラメータ `requiredTagKeys` で指定されたすべてのキーがない場合、コントロールは失敗します。パラメータ `requiredTagKeys` が指定されていない場合、コントロールはタグキーの存在のみをチェックし、ワークフローにキーがタグ付けされていない場合は失敗します。自動的に適用され、`aws:` で始まるシステムタグは無視されます。

タグは、 AWS リソースに割り当てるラベルであり、キーとオプションの値で構成されます。タグを作成して、リソースを目的、所有者、環境、またはその他の基準別に分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。タグ付けは、アクションと通知の説明責任のあるリソース所有者を追跡するのに役立ちます。タグ付けを使用する場合、タグに基づいてアクセス許可を定義する認証戦略として属性ベースのアクセス制御 (ABAC) を実装できます。タグは、IAM エンティティ (ユーザーまたはロール) および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または個別のポリシーセットを作成できます。これらの ABAC ポリシーを、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

**注記**  
タグには、個人を特定できる情報 (PII) や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグには AWS のサービス、 を含む多くのユーザーがアクセスできます AWS Billing。タグ付けのベストプラクティスの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices)」を参照してください*AWS 全般のリファレンス*。

### 修正
<a name="transfer-1-remediation"></a>

**Transfer Family ワークフローにタグを追加するには (コンソール)**

1.  AWS Transfer Family コンソールを開きます。

1. ナビゲーションペインで、[**Workflows**] (ワークフロー) をクリックします。次に、タグ付けするワークフローを選択します。

1. [**タグ管理**] を選択してからタグを追加します。

## [Transfer.2] Transfer Family サーバーはエンドポイント接続に FTP プロトコルを使用しないでください
<a name="transfer-2"></a>

**関連する要件:** NIST.800-53.r5 CM-7、NIST.800-53.r5 IA-5、NIST.800-53.r5 SC-8、PCI DSS v4.0.1/4.2.1

**カテゴリ:** 保護 > データ保護 > 転送中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::Transfer::Server`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/transfer-family-server-no-ftp.html](https://docs.aws.amazon.com/config/latest/developerguide/transfer-family-server-no-ftp.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、 AWS Transfer Family サーバーがエンドポイント接続に FTP 以外のプロトコルを使用しているかどうかをチェックします。サーバーがクライアントに FTP プロトコルを使用してサーバーのエンドポイントに接続すると、コントロールは失敗します。

FTP (File Transfer Protocol) は、暗号化されていないチャネルを介してエンドポイント接続を確立し、これらのチャネル経由で送信されたデータは傍受されやすくなります。SFTP (SSH File Transfer Protocol)、FTPS (File Transfer Protocol Secure)、または AS2 (適用可能性ステートメント 2) を使用すると、転送中のデータを暗号化することでセキュリティを強化できます。また、潜在的な攻撃者が中間者攻撃や類似の攻撃を使用してネットワークトラフィックを盗聴または操作するのを防ぐのに役立ちます。

### 修正
<a name="transfer-2-remediation"></a>

Transfer Family サーバーのプロトコルを変更するには、「*AWS Transfer Family ユーザーガイド*」の「[ファイル転送プロトコルの編集](https://docs.aws.amazon.com/transfer/latest/userguide/edit-server-config.html#edit-protocols)」を参照してください。

## [Transfer.3] Transfer Family コネクタでは、ログ記録が有効になっている必要があります
<a name="transfer-3"></a>

**関連する要件:** NIST.800-53.r5 AC-2(12)、NIST.800-53.r5 AC-2(4)、NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AC-6(9)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 AU-9(7)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-3(8)、NIST.800-53.r5 SI-4、NIST.800-53.r5 SI-4(20)、NIST.800-53.r5 SI-7(8)

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::Transfer::Connector`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/transfer-connector-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/transfer-connector-logging-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、 AWS Transfer Family コネクタで Amazon CloudWatch ログ記録が有効になっているかどうかをチェックします。コネクタで CloudWatch ログ記録が有効になっていない場合、このコントロールは失敗します。

Amazon CloudWatch は、 AWS リソースを含む AWS Transfer Family リソースを可視化するモニタリングおよびオブザーバビリティサービスです。Transfer Family では、CloudWatch は、ワークフローの進行状況と結果に関する統合監査とログ記録を提供します。これには、Transfer Family がワークフロー用に定義するいくつかのメトリクスが含まれます。Transfer Family を設定して、CloudWatch でコネクタイベントを自動的にログ記録できます。これを行うには、コネクタのログ記録ロールを指定します。ログ記録ロールには、IAM ロールと、ロールのアクセス許可を定義するリソースベースの IAM ポリシーを作成します。

### 修正
<a name="transfer-3-remediation"></a>

Transfer Family コネクタの CloudWatch ログ記録を有効にする方法については、「*AWS Transfer Family ユーザーガイド*」の「[Amazon CloudWatch logging for AWS Transfer Family servers](https://docs.aws.amazon.com/transfer/latest/userguide/structured-logging.html)」を参照してください。

## [Transfer.4] Transfer Family 契約にはタグを付ける必要があります
<a name="transfer-4"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::Transfer::Agreement`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/transfer-agreement-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/transfer-agreement-tagged.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | 評価されたリソースに割り当てる必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目) | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし | 

このコントロールは、 AWS Transfer Family 契約に `requiredKeyTags`パラメータで指定されたタグキーがあるかどうかをチェックします。契約にタグキーがない場合、または `requiredKeyTags` パラメータで指定されたすべてのキーがない場合、コントロールは失敗します。`requiredKeyTags` パラメータに値を指定しない場合、コントロールはタグキーの存在のみをチェックし、契約にタグキーがない場合に失敗します。このコントロールはシステムタグを無視します。システムタグは自動的に付与され、`aws:` プレフィックスが付きます。

タグは、 AWS リソースを作成して割り当てるラベルです。各タグは、必要なタグキーとオプションのタグ値で設定されています。タグを使用して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。またそれらは、アクションと通知のリソース所有者を追跡するのにも役立ちます。タグを使用して、認可戦略として属性ベースのアクセス制御 (ABAC) を実装することもできます。ABAC 戦略の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。タグの詳細については、[「 AWS リソースのタグ付け」および「タグエディタユーザーガイド](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。

**注記**  
個人を特定できる情報 (PII) などの機密情報や秘匿性の高い情報はタグに格納しないでください。タグには多くの からアクセスできます AWS のサービス。それらは、プライベートデータや機密データに使用することを意図していません。

### 修正
<a name="transfer-4-remediation"></a>

 AWS Transfer Family 契約にタグを追加する方法については、[「 リソースのタグ付けとタグエディタユーザーガイド」の「リソースのタグ付け方法](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#intro-tag-methods)* AWS *」を参照してください。

## [Transfer.5] Transfer Family 証明書にはタグを付ける必要があります
<a name="transfer-5"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::Transfer::Certificate`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/transfer-certificate-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/transfer-certificate-tagged.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | 評価されたリソースに割り当てる必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目) | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし | 

このコントロールは、 AWS Transfer Family 証明書に `requiredKeyTags`パラメータで指定されたタグキーがあるかどうかをチェックします。証明書にタグキーがまったくない場合、または `requiredKeyTags` パラメータで指定されたすべてのキーを持っていない場合、このコントロールは失敗となります。`requiredKeyTags` パラメータに値を指定しない場合、コントロールはタグキーの存在のみをチェックし、証明書にタグキーがない場合に失敗します。このコントロールはシステムタグを無視します。システムタグは自動的に付与され、`aws:` プレフィックスが付きます。

タグは、 AWS リソースを作成して割り当てるラベルです。各タグは、必要なタグキーとオプションのタグ値で設定されています。タグを使用して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。またそれらは、アクションと通知のリソース所有者を追跡するのにも役立ちます。タグを使用して、認可戦略として属性ベースのアクセス制御 (ABAC) を実装することもできます。ABAC 戦略の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。タグの詳細については、[「 AWS リソースのタグ付け」および「タグエディタユーザーガイド](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。

**注記**  
個人を特定できる情報 (PII) などの機密情報や秘匿性の高い情報はタグに格納しないでください。タグには多くの からアクセスできます AWS のサービス。それらは、プライベートデータや機密データに使用することを意図していません。

### 修正
<a name="transfer-5-remediation"></a>

 AWS Transfer Family 証明書にタグを追加する方法については、[「 リソースのタグ付け」および「タグエディタユーザーガイド」の「リソースのタグ付け方法](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#intro-tag-methods)* AWS *」を参照してください。

## [Transfer.6] Transfer Family コネクタにはタグを付ける必要があります
<a name="transfer-6"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::Transfer::Connector`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/transfer-connector-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/transfer-connector-tagged.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | 評価されたリソースに割り当てる必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目) | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし | 

このコントロールは、 AWS Transfer Family コネクタに `requiredKeyTags`パラメータで指定されたタグキーがあるかどうかをチェックします。コネクタにタグキーがない場合、または `requiredKeyTags` パラメータで指定されたすべてのキーがない場合、コントロールは失敗します。`requiredKeyTags` パラメータに値を指定しない場合、コントロールはタグキーの存在のみをチェックし、コネクタにタグキーがない場合に失敗します。このコントロールはシステムタグを無視します。システムタグは自動的に付与され、`aws:` プレフィックスが付きます。

タグは、 AWS リソースを作成して割り当てるラベルです。各タグは、必要なタグキーとオプションのタグ値で設定されています。タグを使用して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。またそれらは、アクションと通知のリソース所有者を追跡するのにも役立ちます。タグを使用して、認可戦略として属性ベースのアクセス制御 (ABAC) を実装することもできます。ABAC 戦略の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。タグの詳細については、[「 AWS リソースのタグ付け」および「タグエディタユーザーガイド](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。

**注記**  
個人を特定できる情報 (PII) などの機密情報や秘匿性の高い情報はタグに格納しないでください。タグには多くの からアクセスできます AWS のサービス。それらは、プライベートデータや機密データに使用することを意図していません。

### 修正
<a name="transfer-6-remediation"></a>

 AWS Transfer Family コネクタにタグを追加する方法については、[「 リソースのタグ付けとタグエディタユーザーガイド」の「リソースのタグ付け方法](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#intro-tag-methods)* AWS *」を参照してください。

## [Transfer.7] Transfer Family プロファイルにはタグを付ける必要があります
<a name="transfer-7"></a>

**カテゴリ:** 識別 > インベントリ > タグ付け

**重要度:** 低

**リソースタイプ :** `AWS::Transfer::Profile`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/transfer-profile-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/transfer-profile-tagged.html)

**スケジュールタイプ :** 変更がトリガーされた場合

**パラメータ :**


| パラメータ | 説明 | タイプ | 許可されているカスタム値 | Security Hub CSPM のデフォルト値 | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | 評価されたリソースに割り当てる必要があるシステム以外のタグキーのリスト。タグキーでは大文字と小文字が区別されます。 | StringList (最大 6 項目) | [AWS 要件を満たす](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions) 1～6 個のタグキー。 | デフォルト値なし | 

このコントロールは、 AWS Transfer Family プロファイルに `requiredKeyTags`パラメータで指定されたタグキーがあるかどうかをチェックします。プロファイルにタグキーがない場合、またはパラメータ `requiredKeyTags` で指定されたすべてのキーがない場合、コントロールは失敗します。`requiredKeyTags` パラメータに値を指定しない場合、コントロールはタグキーの存在のみをチェックし、プロファイルにタグキーがない場合に失敗します。このコントロールはシステムタグを無視します。システムタグは自動的に付与され、`aws:` プレフィックスが付きます。コントロールは、ローカルプロファイルとパートナープロファイルを評価します。

タグは、 AWS リソースを作成して割り当てるラベルです。各タグは、必要なタグキーとオプションのタグ値で設定されています。タグを使用して、リソースを目的、所有者、環境、またはその他の基準で分類できます。タグは、リソースの識別、整理、検索、フィルタリングに役立ちます。またそれらは、アクションと通知のリソース所有者を追跡するのにも役立ちます。タグを使用して、認可戦略として属性ベースのアクセス制御 (ABAC) を実装することもできます。ABAC 戦略の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。タグの詳細については、[「 AWS リソースのタグ付け」および「タグエディタユーザーガイド](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。

**注記**  
個人を特定できる情報 (PII) などの機密情報や秘匿性の高い情報はタグに格納しないでください。タグには多くの からアクセスできます AWS のサービス。それらは、プライベートデータや機密データに使用することを意図していません。

### 修正
<a name="transfer-7-remediation"></a>

 AWS Transfer Family プロファイルにタグを追加する方法については、[「リソースのタグ付け」および「タグエディタユーザーガイド」の「リソースのタグ付け方法](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#intro-tag-methods)* AWS *」を参照してください。

# の Security Hub CSPM コントロール AWS WAF
<a name="waf-controls"></a>

これらの AWS Security Hub CSPM コントロールは、 AWS WAF サービスとリソースを評価します。コントロールは一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [WAF.1] AWS WAF Classic Global Web ACL ログ記録を有効にする必要があります
<a name="waf-1"></a>

**関連する要件:** NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-7(8)、PCI DSS v4.0.1/10.4.2

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::WAF::WebACL`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/waf-classic-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/waf-classic-logging-enabled.html)

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、 AWS WAF グローバルウェブ ACL でログ記録が有効になっているかどうかを確認します。ウェブ ACL のログ記録が有効でない場合、このコントロールは失敗します。

ログ記録は、 の信頼性、可用性、パフォーマンスを AWS WAF グローバルに維持する上で重要な部分です。これは、多くの組織でビジネスおよびコンプライアンス要件であり、アプリケーションの動作をトラブルシューティングできます。また、 AWS WAFに添付済みのウェブ ACL によって分析されるトラフィックに関する詳細情報も提供します。

### 修正
<a name="waf-1-remediation"></a>

 AWS WAF ウェブ ACL のログ記録を有効にするには、「 *AWS WAF デベロッパーガイド*」の[「ウェブ ACL トラフィック情報のログ記録](https://docs.aws.amazon.com/waf/latest/developerguide/classic-logging.html)」を参照してください。

## [WAF.2] AWS WAF Classic リージョンルールには少なくとも 1 つの条件が必要です
<a name="waf-2"></a>

**関連する要件:** NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(21)

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 中

**リソースタイプ :** `AWS::WAFRegional::Rule`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/waf-regional-rule-not-empty.html](https://docs.aws.amazon.com/config/latest/developerguide/waf-regional-rule-not-empty.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、 AWS WAF リージョンルールに少なくとも 1 つの条件があるかどうかをチェックします。ルールに条件が 1 つもない場合、このコントロールは失敗します。

WAF リージョンルールには、複数の条件を含めることが可能です。このルールの条件によってトラフィックの検査が許可され、定義されたアクション (許可、ブロック、カウント) が実行されます。条件が 1 つもないと、トラフィックは検査なしで通過します。条件がないにもかかわらず、許可、ブロック、カウントを示す名前またはタグが付いている WAF リージョンルールは、上記いずれかのアクションが行われているという誤解を生む可能性があります。

### 修正
<a name="waf-2-remediation"></a>

空のルールに条件を追加する方法については、には、「*AWS WAF デベロッパーガイド*」の「[Adding and removing conditions in a rule](https://docs.aws.amazon.com/waf/latest/developerguide/classic-web-acl-rules-editing.html)」を参照してください。

## [WAF.3] AWS WAF Classic リージョンルールグループには少なくとも 1 つのルールが必要です
<a name="waf-3"></a>

**関連する要件:** NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(21)

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 中

**リソースタイプ :** `AWS::WAFRegional::RuleGroup`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/waf-regional-rulegroup-not-empty.html](https://docs.aws.amazon.com/config/latest/developerguide/waf-regional-rulegroup-not-empty.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、 AWS WAF リージョンルールグループに少なくとも 1 つのルールがあるかどうかをチェックします。ルールグループにルールが 1 つもない場合、このコントロールは失敗します。

WAF リージョンルールグループには、複数のルールを含めることができます。このルールの条件によってトラフィックの検査が許可され、定義されたアクション (許可、ブロック、カウント) が実行されます。ルールが 1 つもないと、トラフィックは検査なしで通過します。ルールはないにもかかわらず、許可、ブロック、カウントを示す名前またはタグが付いている WAF リージョンルールグループは、上記いずれかのアクションが行われているという誤解を生む可能性があります。

### 修正
<a name="waf-3-remediation"></a>

空のルールグループにルールとルール条件を追加するには、「 *AWS WAF デベロッパーガイド*」の[AWS WAF 「 Classic ルールグループへのルールの追加と削除](https://docs.aws.amazon.com/waf/latest/developerguide/classic-rule-group-editing.html)」および[「ルールの条件の追加と削除](https://docs.aws.amazon.com/waf/latest/developerguide/classic-web-acl-rules-editing.html)」を参照してください。

## [WAF.4] AWS WAF Classic Regional Web ACLs には、少なくとも 1 つのルールまたはルールグループが必要です
<a name="waf-4"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 中

**リソースタイプ :** `AWS::WAFRegional::WebACL`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/waf-regional-webacl-not-empty](https://docs.aws.amazon.com/config/latest/developerguide/waf-regional-webacl-not-empty)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、 AWS WAF Classic Regional ウェブ ACL に WAF ルールまたは WAF ルールグループが含まれているかどうかをチェックします。ウェブ ACL に WAF ルールまたはルールグループが含まれていない場合、このコントロールは失敗します。

WAF リージョンウェブ ACL には、ウェブリクエストを検査および制御する、ルールおよびルールグループのコレクションを含めることができます。ウェブ ACL が空の場合、ウェブトラフィックは、デフォルトのアクションに応じて WAF による検出または処理なしに通過できます。

### 修正
<a name="waf-4-remediation"></a>

空の AWS WAF Classic Regional Web ACL にルールまたはルールグループを追加するには、「 *AWS WAF デベロッパーガイド*[」の「ウェブ ACL の編集](https://docs.aws.amazon.com/waf/latest/developerguide/classic-web-acl-editing.html)」を参照してください。

## [WAF.6] AWS WAF Classic グローバルルールには少なくとも 1 つの条件が必要です
<a name="waf-6"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 中

**リソースタイプ :** `AWS::WAF::Rule`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/waf-global-rule-not-empty.html](https://docs.aws.amazon.com/config/latest/developerguide/waf-global-rule-not-empty.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、 AWS WAF グローバルルールに条件が含まれているかどうかをチェックします。ルールに条件が 1 つもない場合、このコントロールは失敗します。

WAF グローバルルールには、複数の条件を含めることが可能です。ルールの条件によってトラフィックの検査が可能になり、定義されたアクション (許可、ブロック、カウント) を実行できます。条件が 1 つもないと、トラフィックは検査なしで通過します。条件はないにもかかわらず、許可、ブロック、カウントを示す名前またはタグが付いている WAF グローバルルールは、上記いずれかのアクションが行われているという誤解を生む可能性があります。

### 修正
<a name="waf-6-remediation"></a>

ルールの作成方法および条件の追加方法については、「*AWS WAF デベロッパーガイド*」の「[Creating a rule and adding conditions](https://docs.aws.amazon.com/waf/latest/developerguide/classic-web-acl-rules-creating.html)」を参照してください。

## [WAF.7] AWS WAF Classic グローバルルールグループには少なくとも 1 つのルールが必要です
<a name="waf-7"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 中

**リソースタイプ :** `AWS::WAF::RuleGroup`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/waf-global-rulegroup-not-empty.html](https://docs.aws.amazon.com/config/latest/developerguide/waf-global-rulegroup-not-empty.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、 AWS WAF グローバルルールグループに少なくとも 1 つのルールがあるかどうかをチェックします。ルールグループにルールが 1 つもない場合、このコントロールは失敗します。

WAF グローバルルールグループには、複数のルールを含めることができます。このルールの条件によってトラフィックの検査が許可され、定義されたアクション (許可、ブロック、カウント) が実行されます。ルールが 1 つもないと、トラフィックは検査なしで通過します。ルールはないにもかかわらず、許可、ブロック、カウントを示す名前またはタグが付いている WAF グローバルルールグループは、上記いずれかのアクションが行われているという誤解を生む可能性があります。

### 修正
<a name="waf-7-remediation"></a>

ルールグループにルールを追加する手順については、 *AWS WAF デベロッパーガイド*[の AWS WAF Classic ルールグループ](https://docs.aws.amazon.com/waf/latest/developerguide/classic-create-rule-group.html)の作成を参照してください。

## [WAF.8] AWS WAF Classic グローバルウェブ ACLs には、少なくとも 1 つのルールまたはルールグループが必要です
<a name="waf-8"></a>

**関連する要件:** NIST.800-53.r5 AC-4(21)、NIST.800-53.r5 SC-7、NIST.800-53.r5 SC-7(11)、NIST.800-53.r5 SC-7(16)、NIST.800-53.r5 SC-7(21)

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 中

**リソースタイプ :** `AWS::WAF::WebACL`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/waf-global-webacl-not-empty](https://docs.aws.amazon.com/config/latest/developerguide/waf-global-webacl-not-empty)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、 AWS WAF グローバルウェブ ACL に少なくとも 1 つの WAF ルールまたは WAF ルールグループが含まれているかどうかをチェックします。ウェブ ACL に WAF ルールまたはルールグループが含まれていない場合、このコントロールは失敗します。

WAF グローバルウェブ ACL には、ウェブリクエストを検査および制御するルールおよびルールグループのコレクションを含めることができます。ウェブ ACL が空の場合、ウェブトラフィックは、デフォルトのアクションに応じて WAF による検出または処理なしに通過できます。

### 修正
<a name="waf-8-remediation"></a>

空の AWS WAF グローバルウェブ ACL にルールまたはルールグループを追加するには、「 *AWS WAF デベロッパーガイド*[」の「ウェブ ACL の編集](https://docs.aws.amazon.com/waf/latest/developerguide/classic-web-acl-editing.html)」を参照してください。**[Filter]** (フィルター) で **[Global (CloudFront)]** (グローバル (CloudFront)) を選択します。

## [WAF.10] AWS WAF ウェブ ACLs には少なくとも 1 つのルールまたはルールグループが必要です
<a name="waf-10"></a>

**関連する要件:** NIST.800-53.r5 CA-9(1)、NIST.800-53.r5 CM-2

**カテゴリ:** 保護 > セキュアなネットワーク設定

**重要度:** 中

**リソースタイプ :** `AWS::WAFv2::WebACL`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/wafv2-webacl-not-empty.html](https://docs.aws.amazon.com/config/latest/developerguide/wafv2-webacl-not-empty.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、 AWS WAF V2 ウェブアクセスコントロールリスト (ウェブ ACL) に少なくとも 1 つのルールまたはルールグループが含まれているかどうかを確認します。ウェブ ACL にルールまたはルールグループが含まれていない場合、このコントロールは失敗します。

ウェブ ACL を使用すると、保護されたリソースが応答するすべての HTTP(S) ウェブリクエストをきめ細かく制御できます。ウェブ ACL には、ウェブリクエストを検査および制御するルールおよびルールグループのコレクションを含める必要があります。ウェブ ACL が空の場合、デフォルトのアクション AWS WAF に応じて、ウェブトラフィックは検出されず、 によって処理されずに通過できます。

### 修正
<a name="waf-10-remediation"></a>

ルールまたはルールグループを空の WAFV2 ウェブ ACL に追加するには、「*AWS WAF デベロッパーガイド*」の「[Editing a Web ACL](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-editing.html)」を参照してください。

## [WAF.11] AWS WAF ウェブ ACL ログ記録を有効にする必要があります
<a name="waf-11"></a>

**関連する要件:** NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-7(8)、PCI DSS v4.0.1/10.4.2

**カテゴリ:** 識別 > ログ記録

**重要度:** 低

**リソースタイプ :** `AWS::WAFv2::WebACL`

**AWS Config ルール:** [https://docs.aws.amazon.com/config/latest/developerguide/wafv2-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/wafv2-logging-enabled.html) ``

**スケジュールタイプ :** 定期的

**パラメータ :** なし

このコントロールは、 AWS WAF V2 ウェブアクセスコントロールリスト (ウェブ ACL) のログ記録が有効になっているかどうかを確認します。ウェブ ACL のログ記録が無効の場合、このコントロールは失敗します。

**注記**  
このコントロールは、Amazon Security Lake を介してアカウントに対して AWS WAF ウェブ ACL ログ記録が有効になっているかどうかをチェックしません。

ログ記録は、 の信頼性、可用性、パフォーマンスを維持します AWS WAF。また、多くの組織において、ログ記録はビジネスおよびコンプライアンス要件となっています。ウェブ ACL で分析されたトラフィックをログに記録することで、アプリケーションの挙動のトラブルシューティングができます。

### 修正
<a name="waf-11-remediation"></a>

 AWS WAF ウェブ ACL のログ記録を有効にするには、「 *AWS WAF デベロッパーガイド*」の[「ウェブ ACL のログ記録の管理](https://docs.aws.amazon.com/waf/latest/developerguide/logging-management.html)」を参照してください。

## [WAF.12] AWS WAF ルールでは CloudWatch メトリクスを有効にする必要があります
<a name="waf-12"></a>

**関連する要件:** NIST.800-53.r5 AC-4(26)、NIST.800-53.r5 AU-10、NIST.800-53.r5 AU-12、NIST.800-53.r5 AU-2、NIST.800-53.r5 AU-3、NIST.800-53.r5 AU-6(3)、NIST.800-53.r5 AU-6(4)、NIST.800-53.r5 CA-7、NIST.800-53.r5 SC-7(10)、NIST.800-53.r5 SC-7(9)、NIST.800-53.r5 SI-7(8)、NIST.800-171.r2 3.14.6、NIST.800-171.r2 3.14.7

**カテゴリ:** 識別 > ログ記録

**重要度:** 中

**リソースタイプ :** `AWS::WAFv2::RuleGroup`

**AWS Config ルール:** [https://docs.aws.amazon.com/config/latest/developerguide/wafv2-rulegroup-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/wafv2-rulegroup-logging-enabled.html) ``

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、 AWS WAF ルールまたはルールグループで Amazon CloudWatch メトリクスが有効になっているかどうかを確認します。ルールまたはルールグループで CloudWatch メトリクスが有効になっていない場合、コントロールは失敗します。

 AWS WAF ルールとルールグループで CloudWatch メトリクスを設定すると、トラフィックフローを可視化できます。どの ACL ルールがトリガーされ、どのリクエストが受け入れられブロックされたかを確認できます。この可視性は、関連リソースでの悪意のあるアクティビティを特定するのに役立ちます。

### 修正
<a name="waf-12-remediation"></a>

 AWS WAF ルールグループで CloudWatch メトリクスを有効にするには、[UpdateRuleGroup](https://docs.aws.amazon.com/waf/latest/APIReference/API_UpdateRuleGroup.html) API を呼び出します。 AWS WAF ルールで CloudWatch メトリクスを有効にするには、[UpdateWebACL](https://docs.aws.amazon.com/waf/latest/APIReference/API_UpdateWebACL.html) API を呼び出します。`CloudWatchMetricsEnabled` フィールドは `true` に設定されます。 AWS WAF コンソールを使用してルールまたはルールグループを作成すると、CloudWatch メトリクスが自動的に有効になります。

# WorkSpaces の Security Hub CSPM コントロール
<a name="workspaces-controls"></a>

これらの AWS Security Hub CSPM コントロールは、Amazon WorkSpaces サービスとリソースを評価します。

これらのコントロールは、一部の で使用できない場合があります AWS リージョン。詳細については、「[リージョン別のコントロールの可用性](securityhub-regions.md#securityhub-regions-control-support)」を参照してください。

## [WorkSpaces.1] WorkSpaces ユーザーボリュームは保管中に暗号化する必要があります
<a name="workspaces-1"></a>

**カテゴリ:** 保護 > データ保護 > 保管中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::WorkSpaces::Workspace`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/workspaces-user-volume-encryption-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/workspaces-user-volume-encryption-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon WorkSpaces WorkSpace のユーザーボリュームが保管中に暗号化されているかどうかを確認します。WorkSpace ユーザーボリュームが保管中に暗号化されていない場合、コントロールは失敗します。

保管中のデータとは、永続的な不揮発性ストレージに任意の期間保管されているデータを指します。保管中のデータを暗号化すると、その機密性が保護され、権限のないユーザーがアクセスするリスクが低減されます。

### 修正
<a name="workspaces-1-remediation"></a>

WorkSpaces ユーザーボリュームを暗号化するには、「*Amazon WorkSpaces 管理ガイド*」の「[WorkSpace の暗号化](https://docs.aws.amazon.com/workspaces/latest/adminguide/encrypt-workspaces.html#encrypt_workspace)」を参照してください。

## [WorkSpaces.2] WorkSpaces ルートボリュームは保管中に暗号化する必要があります
<a name="workspaces-2"></a>

**カテゴリ:** 保護 > データ保護 > 保管中のデータの暗号化

**重要度:** 中

**リソースタイプ :** `AWS::WorkSpaces::Workspace`

**AWS Config ルール :** [https://docs.aws.amazon.com/config/latest/developerguide/workspaces-root-volume-encryption-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/workspaces-root-volume-encryption-enabled.html)

**スケジュールタイプ:** 変更がトリガーされた場合

**パラメータ :** なし

このコントロールは、Amazon WorkSpaces WorkSpace のルートボリュームが保管中に暗号化されているかどうかを確認します。WorkSpace ルートボリュームが保管中に暗号化されていない場合、コントロールは失敗します。

保管中のデータとは、永続的な不揮発性ストレージに任意の期間保管されているデータを指します。保管中のデータを暗号化すると、その機密性が保護され、権限のないユーザーがアクセスするリスクが低減されます。

### 修正
<a name="workspaces-2-remediation"></a>

WorkSpaces ルートボリュームを暗号化するには、「*Amazon WorkSpaces 管理ガイド*」の「[WorkSpace の暗号化](https://docs.aws.amazon.com/workspaces/latest/adminguide/encrypt-workspaces.html#encrypt_workspace)」を参照してください。