AWS の基本的なセキュリティのベストプラクティスコントロール - AWS Security Hub
[ACM.1] インポートされた ACM 証明書は、指定された期間後に更新する必要があります[AutoScaling.1] Auto Scaling に関連付けられた Load Balancer グループは、 Load Balancer ヘルスチェックを使用する必要があります[CloudFront.1] ディストリビューションにはデフォルトのルートオブジェクトを設定する必要がありますCloudFront[CloudFront.2] CloudFront ディストリビューションでは、オリジンアクセスアイデンティティを有効にする必要があります[CloudFront.3]] CloudFront ディストリビューションでは、転送中に暗号化が必要です。[CloudFront.4]] CloudFront ディストリビューションにはオリジンフェイルオーバーが設定されている必要があります[CloudTrail.1] CloudTrail を有効にし、少なくとも 1 つのマルチリージョンの証跡で設定する必要があります。[CloudTrail.2] CloudTrail では、保管時の暗号化を有効にする必要があります[CodeBuild.1] CodeBuild GitHub または Bitbucket ソースリポジトリ URLs は OAuth を使用する必要があります[CodeBuild.2] CodeBuild プロジェクト環境変数にクリアテキストの認証情報を含めることはできません[Config.1] AWS Config を有効にする必要があります[DMS.1] Database Migration Service レプリケーションインスタンスをパブリックにすることはできません[DynamoDB.1] テーブルでは、需要に応じて自動的にキャパシティーがスケールされますDynamoDB[DynamoDB.2]] DynamoDB テーブルでは、ポイントインタイムリカバリを有効にする必要があります[DynamoDB.3]] DynamoDB アクセラレーター (DAX) クラスターは保管時に暗号化する必要があります[EC2.1] Amazon EBS スナップショットは、パブリックであってはなりません。これは誰でも復元できるかどうかによって判断されます[EC2.2] VPC のデフォルトのセキュリティグループでは、インバウンドトラフィックとアウトバウンドトラフィックが禁止されます [EC2.3] アタッチされた EBS ボリュームは、保管時に暗号化する必要があります[EC2.4] 停止した EC2 インスタンスは、指定した期間後に削除する必要があります[EC2.6] すべての VPCs で VPC フローログ記録を有効にする必要があります [EC2.7] EBS デフォルト暗号化を有効にする必要があります[EC2.8] EC2 インスタンスは IMDSv2 を使用する必要があります[EFS.1] Amazon EFS は、AWS KMS を使用して保管中のファイルデータを暗号化するように設定する必要があります[ELB.3] Classic Load Balancer リスナーは、HTTPS または TLS 終了で設定する必要があります[ELB.4] Application Load Balancer は、HTTP ヘッダーを削除するよう設定する必要があります[ELB.5] アプリケーションおよび Classic Load Balancer のログ記録を有効にする必要があります[ELBv2.1] Application Load Balancer は、すべての HTTP リクエストを HTTPS にリダイレクトするように設定する必要があります[EMR.1] Amazon EMR クラスターマスターノードにパブリック IP アドレスがあってはいけません[ES.1] Elasticsearch ドメインは保存時の暗号化を有効にする必要があります[GuardDuty.1] GuardDuty を有効にする必要があります[IAM.1] IAM ポリシーでは、完全な「*」管理権限を許可しないでください[IAM.2] IAM ユーザーには IAM ポリシーをアタッチしないでください[IAM.3] IAM ユーザーのアクセスキーは 90 日ごとに更新する必要があります[IAM.4] IAM ルートユーザーアクセスキーが存在してはいけません[IAM.5] コンソールパスワードを持つすべての IAM ユーザーに対して MFA を有効にする必要があります[IAM.6] ルートユーザーに対してハードウェア MFA を有効にする必要があります[IAM.7] IAM ユーザーのパスワードポリシーには強力な設定が必要です[IAM.8] 使用されていない IAM ユーザー認証情報を削除する必要があります[KMS.1] IAM カスタマー管理ポリシーでは、すべての KMS キーに対する復号アクションを許可しないでください[KMS.2] IAM プリンシパルには、すべての KMS キーの復号アクションを許可する IAM インラインポリシーがあってはなりません [Lambda.1] Lambda 関数ポリシーはパブリックアクセスを禁止する必要があります[Lambda.2] Lambda 関数は最新のランタイムを使用する必要があります[RDS.1] RDS スナップショットはプライベートである必要があります[RDS.2] RDS DB インスタンスは、PubliclyAccessible 設定によって決定されるパブリックアクセスを禁止する必要があります[RDS.3] RDS DB インスタンスでは、保管時の暗号化を有効にする必要があります[RDS.4] RDS クラスタースナップショットとデータベーススナップショットは保管時に暗号化する必要があります[RDS.5] RDS DB インスタンスは、複数のアベイラビリティーゾーンで設定する必要があります[RDS.6] RDS DB インスタンスとクラスターには拡張モニタリングを設定する必要があります[RDS.7] RDS クラスターでは、削除保護を有効にする必要があります[RDS.8] RDS DB インスタンスで削除保護を有効にする必要があります[RDS.9] データベースのログ記録を有効にする必要があります[RDS.10] IAM 認証を RDS インスタンス用に設定する必要があります[RDS.11] RDS インスタンスでは、自動バックアップを有効にする必要があります[Redshift.1] Amazon Redshift クラスターはパブリックアクセスを禁止する必要があります[Redshift.2] Amazon Redshift クラスターへの接続は転送時に暗号化する必要があります[Redshift.3] Amazon Redshift クラスターでは、自動スナップショットを有効にする必要があります[Redshift.6] Amazon Redshift ではメジャーバージョンへの自動アップグレードを有効にする必要があります[S3.1] S3 ブロックパブリックアクセス設定を有効にする必要があります[S3.2] S3 バケットではパブリック読み取りアクセスを禁止する必要があります[S3.3] S3 バケットはパブリック書き込みアクセスを禁止する必要があります[S3.4] S3 バケットでは、サーバー側の暗号化を有効にする必要があります[S3.5] S3 バケットでは、Secure Socket Layer を使用するためのリクエストが必要です。[S3.6] バケットポリシーの他の Amazon S3 アカウントに付与される AWS アクセス許可は制限する必要があります[SageMaker.1] SageMaker ノートブックインスタンスは直接インターネットにアクセスできません[SecretsManager.1] Secrets Manager シークレットは自動ローテーションを有効にする必要があります[SecretsManager.2] 自動ローテーションで設定された Secrets Manager シークレットは正常にローテーションする必要があります[SNS.1] SNS トピックは、AWS KMS を使用して保管時に暗号化する必要があります[SSM.1] EC2 インスタンスは AWS Systems Manager によって管理される必要があります[SSM.2] Systems Manager によって管理されるすべての EC2 インスタンスは、パッチ適用要件に準拠している必要があります。[SSM.3] Systems Manager によって管理されるインスタンスは、関連付けコンプライアンスのステータスが COMPLIANT である必要があります。

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

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

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

  • コントロールが適用されるカテゴリとサブカテゴリ

  • 重要度

  • 該当するリソース

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

  • 修復ステップ

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

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

重大度:

リソース: ACM 証明書

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

パラメータ:

  • daysToExpiration: 30

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

ACM が提供する証明書は自動的に更新されます。ACM が提供する証明書を使用する場合、SSL/TLS 証明書を更新する必要はありません。ACM が更新を管理します。

ACM はインポートした証明書を自動的に更新しません。インポートした証明書を手動で更新する必要があります。

詳細については、https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html の「マネージド型更新AWS Certificate Manager ユーザーガイド」を参照してください。

注記

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

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

  • 中国 (北京)

  • 中国 (寧夏)

  • ヨーロッパ (ミラノ)

Remediation

ACM は、Amazon 発行の SSL/TLS 証明書のマネージド型更新を提供しています。これには、 を使用して発行されたパブリック証明書とプライベート証明書の両方が含まれます。ACM. 可能な限り、ACM は手動によるアクションを必要とせずに、自動的に証明書を更新します。証明書は、AWS や Elastic Load Balancing などの別の Amazon CloudFront. サービスに関連付けられている場合、更新の対象となります。また、発行以降または最終更新後にエクスポートされている場合にも、更新できます。

ACM が証明書内の 1 つ以上のドメイン名を自動的に検証できない場合、ACM は、ドメインを手動で検証する必要があることをドメイン所有者に通知します。ドメインの手動検証が必要になるのは、次のような理由によります。

  • ACM がドメインと HTTPS 接続を確立できない。

  • HTTPS リクエストに対する応答で返された証明書が ACM が更新する証明書と一致しない。

証明書が有効期限の 45 日前となった場合、証明書の 1 つ以上のドメイン名で手動検証が必要な場合は、ACM からドメインの所有者に通知されます。

E メールで (検証済みの証明書 の場合)

証明書を最後に検証したのが E メールである場合は、手動検証が必要なドメイン名ごとに E メールが ACM よりドメイン所有者に 送信されます。この E メールを確実に受信するために、ドメイン所有者は各ドメインの E メールを正しく構成する必要があります。

詳細については、「(省略可能) ドメインの E メールを設定する.」を参照してください。E メールには、検証を行うリンクが含まれています。このリンクは 72 時間後に失効します。必要な場合には、ACM コンソール、AWS CLI、または API を使用して、ACM がドメイン検証 E メールを再送信するようリクエストできます。詳細については、「証明書を更新するためにドメイン検証 E メールをリクエストする.」を参照してください。

重要

E メールで検証済みの証明書は、手動で最後に検証してから最大 825 日後に自動更新されます。825 日が経過した後に更新を続行するには、ドメイン所有者または承認された担当者が手動でドメインの所有権を再検証し、再確認する必要があります。この問題を回避するために、セキュリティハブ では、新しい証明書を作成し、可能であれば DNS 検証を使用することを推奨します。これらの証明書が適切に設定されている場合、DNS で検証された証明書は無期限に再検証されます。

で通知する AWS Personal Health Dashboard

ACM は、証明書を更新する前に、証明書の 1 つ以上のドメイン名に検証が必要であることを示す通知を Personal Health Dashboard に送信します。ACM は、証明書の失効日まで 45 日、30 日、15 日、7 日、3 日、1 日となるときに、この通知を送信します。これらの通知は情報提供のみを目的としています。

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

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

重大度:

リソースタイプ: AutoScaling AutoScalingGroup

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

パラメータ: なし

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

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

Remediation

修復するには、Auto Scaling ヘルスチェックを使用するように Elastic Load Balancing グループを更新します。

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

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

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

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

  4. Edit.] を選択します。

  5. [ヘルスチェック] の [ヘルスチェックタイプ] で、[ELB] を選択します。

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

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

Auto Scaling Load Balancer ロードバランサー Auto Scaling」を参照してください。AWS Auto Scaling ユーザーガイド

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

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

重要度: 非常事態

リソース: ディストリビューション

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

パラメータ: なし

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

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

注記

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

  • 米国東部 (オハイオ)

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

  • 米国西部 (オレゴン)

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

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

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

  • アジアパシフィック (大阪: ローカル)

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

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

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

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

  • カナダ (中部)

  • 中国 (北京)

  • 中国 (寧夏)

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

  • 欧州 (アイルランド)

  • 欧州 (ロンドン)

  • ヨーロッパ (ミラノ)

  • 欧州 (パリ)

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

  • 中東 (バーレーン)

  • 南米 (サンパウロ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (US-West)

Remediation

ディストリビューションのデフォルトルートオブジェクトを指定する方法に関する詳細については、https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DefaultRootObject.html#DefaultRootObjectHowToDefine の「デフォルトルートオブジェクトを指定する方法Amazon CloudFront 開発者ガイド」を参照してください。

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

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

重大度:

リソース: ディストリビューション

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

パラメータ: なし

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

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

注記

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

  • 米国東部 (オハイオ)

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

  • 米国西部 (オレゴン)

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

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

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

  • アジアパシフィック (大阪: ローカル)

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

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

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

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

  • カナダ (中部)

  • 中国 (北京)

  • 中国 (寧夏)

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

  • 欧州 (アイルランド)

  • 欧州 (ロンドン)

  • ヨーロッパ (ミラノ)

  • 欧州 (パリ)

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

  • 中東 (バーレーン)

  • 南米 (サンパウロ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (US-West)

Remediation

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

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

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

重大度:

リソース: ディストリビューション

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

パラメータ: なし

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

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

注記

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

  • 米国東部 (オハイオ)

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

  • 米国西部 (オレゴン)

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

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

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

  • アジアパシフィック (大阪: ローカル)

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

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

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

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

  • カナダ (中部)

  • 中国 (北京)

  • 中国 (寧夏)

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

  • 欧州 (アイルランド)

  • 欧州 (ロンドン)

  • ヨーロッパ (ミラノ)

  • 欧州 (パリ)

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

  • 中東 (バーレーン)

  • 南米 (サンパウロ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (US-West)

Remediation

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

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

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

重大度:

リソース: ディストリビューション

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

パラメータ: なし

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

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

注記

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

  • 米国東部 (オハイオ)

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

  • 米国西部 (オレゴン)

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

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

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

  • アジアパシフィック (大阪: ローカル)

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

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

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

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

  • カナダ (中部)

  • 中国 (北京)

  • 中国 (寧夏)

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

  • 欧州 (アイルランド)

  • 欧州 (ロンドン)

  • ヨーロッパ (ミラノ)

  • 欧州 (パリ)

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

  • 中東 (バーレーン)

  • 南米 (サンパウロ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (US-West)

Remediation

修復の詳細な手順については、https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html#concept_origin_groups.creating の「オリジングループの作成Amazon CloudFront 開発者ガイド」を参照してください。

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

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

重大度:

リソース: アカウント

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

パラメータ:

  • readWriteType: ALL

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

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

  • API 発信者の ID

  • API コールの時刻

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

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

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

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

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

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

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

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

Remediation

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

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

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

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

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

  5. Apply trail to all regions (すべてのリージョンで証跡を適用)] では [いいえ.] を選択します。

  6. [Storage location] で、次のいずれかの操作を行います。

    1. ログ用に新しい S3 バケットを作成するには、[CloudTrailCreate a new S3 bucket (新しい S3 バケットの作成)] で [はい] を選択し、新しい S3 バケットの名前を入力します。

    2. 既存の S3 バケットを使用するには、[Create a new S3 bucket] で [No] を選択し、使用する S3 バケットを選択します。

  7. Advanced.] を選択します。Enable log file validation (ログファイルの検証を有効にする)] で、[Yes (はい).] を選択します。

  8. 作成.] を選択します。

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

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

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

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

  4. [Trail settings (証跡設定)] で、鉛筆アイコンを選択します。

  5. Apply trail to all regions (すべてのリージョンに証跡を適用する)] で、[はい] を選択して [保存.] を選択します。

  6. [Management events (管理イベント)] で、鉛筆アイコンを選択します。

  7. Read/Write events (読み込み/書き込みイベント)] の [すべて] を選択し、[保存.] を選択します。

  8. [Storage location] で、鉛筆アイコンを選択します。

  9. Enable log file validation (ログファイルの検証を有効にする)] で、[はい] を選択し、[保存.] を選択します。

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

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

重大度:

リソース: CloudTrail 証跡

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

パラメータ: なし

このコントロールは、CloudTrail がサーバー側の暗号化 (SSE) AWS Key Management Service カスタマーマスターキー (CMK) 暗号化を使用するよう設定されているかどうかを確認します。KmsKeyId が定義されている場合、チェックは合格します。

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

Remediation

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

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

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

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

  4. [Storage location] で、鉛筆アイコンを選択して設定を編集します。

  5. Encrypt log files with SSE-KMS (SSE-KMS でログファイルを暗号化する)] で、[はい.] を選択します。

  6. [Create a new KMS key] で、次のいずれかの操作を行います。

    • キーを作成するには、[Yes (はい)] を選択し、[KMS キー] フィールドにキーのエイリアスを入力します。キーは、バケットと同じリージョンに作成されます。

    • 既存のキーを使用するには、[いいえ] を選択し、KMS キーリストからキーを選択します。

    注記

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

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

    CMK と正常にやり取りするためには、CloudTrail のポリシーを変更する必要がある場合があります。詳細については、 の「CloudTrail で管理されたキー (SSE-KMS) による AWS KMS ログファイルの暗号化」を参照してください。AWS CloudTrail User Guide

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

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

重要度: 非常事態

リソース: CodeBuild プロジェクト

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

パラメータ: なし

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

注記

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

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

  • ヨーロッパ (ミラノ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (US-West)

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

Remediation

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

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

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

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

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

  5. [ を使用して接続OAuth] を選択し、[Connect to / BitbucketGitHub] を選択します。

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

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

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

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

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

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

重要度: 非常事態

リソース: CodeBuild プロジェクト

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

パラメータ: なし

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

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

注記

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

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

  • ヨーロッパ (ミラノ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (US-West)

Remediation

環境変数を削除するには

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

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

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

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

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

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

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

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

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

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

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

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

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

  6. このチュートリアルに従って、機密データを含む パラメータを作成します。Systems Manager

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

  8. CodeBuild コンソールに戻り、[Create environmental variable (環境変数の作成).] を選択します。

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

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

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

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

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

詳細については、https://docs.aws.amazon.com/codebuild/latest/userguide/build-env-ref-env-vars.html の「ビルド環境の環境変数AWS CodeBuild ユーザーガイド」を参照してください。

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

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

重大度:

リソース: アカウント

AWS Config ルール: なし。

パラメータ: なし

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

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

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

注記

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

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

詳細については、AWS Config の「 の開始方法」を参照してください。AWS Config Developer Guide

Remediation

AWS Config 設定を構成するには

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

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

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

  4. [Settings] ページで、次の操作を行います。

    1. [Resource types to record] で、[Record all resources supported in this region] および [Include global resources (example AWS resources)IAM] を選択します。

    2. [Amazon S3 バケット Amazon S3

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

    4. [ AWS Config ロール] で、[ サービスにリンクされたロールの作成AWS Config] または [Choose a role from your account (アカウントからロールを選択)] を選択し、使用するロールを選択します。

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

  6. AWS Config] ルールページで、[Skip (スキップ).] を選択します。

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

からの AWS Config の使用の詳細については、AWS CLI の「AWS Config の有効化」を参照してください。AWS Config Developer Guide

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

[DMS.1] Database Migration Service レプリケーションインスタンスをパブリックにすることはできません

重要度: 非常事態

リソース: DMS:ReplicationInstance

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

パラメータ: なし

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

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

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

注記

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

Remediation

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

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

  1. AWS Database Migration Servicedms/https://console.aws.amazon.com/ にある . コンソールを開きます。

  2. レプリケーションインスタンスに移動してから、パブリックインスタンスを削除します。インスタンスを選択し、[Actions]、[delete] の順に選択します。

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

  4. パブリックアクセスを無効にするには、[パブリックアクセス可能] が選択されていないことを確認します。

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

詳細については、https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.html#CHAP_ReplicationInstance.Creating の「レプリケーションインスタンスの作成AWS Database Migration Service ユーザーガイド」のセクションを参照してください。

[DynamoDB.1] テーブルでは、需要に応じて自動的にキャパシティーがスケールされますDynamoDB

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

重大度:

リソース: テーブル

AWS Config ルール: dynamodb-autoscaling-enabled

パラメータ: なし

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

オンデマンドキャパシティーモードの DynamoDB テーブルは、DynamoDB スループットのデフォルトテーブルクォータによってのみ制限されます。これらのクォータを引き上げるには、https://aws.amazon.com/support

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

注記

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

Remediation

キャパシティーモードで既存のテーブルで DynamoDB Auto Scaling を有効にする方法の詳細については、の「DynamoDB既存のテーブルで Auto Scaling を有効にする」を参照してください。Amazon DynamoDB 開発者ガイド

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

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

重大度:

リソース: テーブル

AWS Config ルール: dynamodb-pitr-enabled

パラメータ: なし

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

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

Remediation

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

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

  2. 使用するテーブルを選択し、[Backups (バックアップ)] を選択します。

  3. [ポイントインタイムリカバリ] セクションの [ステータス] で、[有効] を選択します。

  4. [有効化] をもう一度選択して、変更を確定します。

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

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

重大度:

リソース: クラスター

AWS Config ルール: dax_encryption_enabled

パラメータ: なし

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

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

Remediation

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

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

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

重要度: 非常事態

リソース: アカウント

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

パラメータ: なし

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

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

注記

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

Remediation

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

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

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

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

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

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

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

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

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

重大度:

リソース: EC2 セキュリティグループ

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

パラメータ: なし

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

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

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

Remediation

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

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

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

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

  3. リソースに対して最小権限のセキュリティグループのセットを作成します。セキュリティグループを作成する方法の詳細については、https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#CreatingSecurityGroups の「セキュリティグループの作成Amazon VPC ユーザーガイド」を参照してください。

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

  5. Amazon EC2 コンソールで、デフォルトのセキュリティグループを使用しているリソースのセキュリティグループを、作成した最小権限のセキュリティグループに変更します。『https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SG_Changing_Group_Membership』の「インスタンスのセキュリティグループの変更Amazon VPC ユーザーガイド」を参照してください。

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

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

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

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

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

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

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

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

詳細については、https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#WorkingWithSecurityGroups の「セキュリティグループの操作Amazon VPC ユーザーガイド」を参照してください。

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

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

重大度:

リソース: EC2 ボリューム

AWS Config ルール: encrypted-volumes

パラメータ: なし

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

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

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

注記

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

Remediation

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

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

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

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

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

重大度:

リソース: EC2 インスタンス

AWS Config ルール: ec2-stopped-instance

パラメータ:

  • allowedDays: 30

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

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

注記

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

Remediation

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

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

  • ボリュームが終了時に削除されないことを確認します。Amazon EBS

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

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

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

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

  3. インスタンスを選択し、[Actions]、[Instance State]、[Terminate] の順に選択します。

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

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

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

インスタンスの削除の詳細については、https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#terminating-instances-console の「インスタンスの削除Linux インスタンス用 Amazon EC2 ユーザーガイド」を参照してください。

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

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

重大度:

リソース: EC2 VPC

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

パラメータ:

  • trafficType: REJECT

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

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

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

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

Remediation

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

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

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

  2. [Virtual Private Cloud] で、[Your VPCs] を選択します。

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

  4. ページの下部で、[Flow Logs] を選択します。

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

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

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

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

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

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

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

重大度:

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

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

パラメータ: なし

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

アカウントで暗号化が有効になっている場合、Amazon EBS ボリュームとスナップショットのコピーは保管時に暗号化されます。これにより、データの保護レイヤーが追加されます。詳細については、https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default の「デフォルトでの暗号化Linux インスタンス用 Amazon EC2 ユーザーガイド」を参照してください。

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

Remediation

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

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

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

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

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

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

  5. 有効化.] を選択します。ユーザーに代わって作成したエイリアス AWS をデフォルトの暗号化キーとして使用して alias/aws/ebs 管理の CMK を保持するか、対称カスタマー管理の CMK を選択します。

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

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

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

重大度:

リソースタイプ: EC2 インスタンス

AWS Config ルール: ec2-imdsv2-check

パラメータ: なし

このコントロールは、EC2 インスタンスのメタデータバージョンが Instance Metadata Service バージョン 2 (IMDSv2) で設定されているかどうかを確認します。が HttpTokens に必要な値に設定されている場合、コントロールは渡されます。IMDSv2 が HttpTokens に設定されている場合、コントロールは失敗します。optional

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

IMDS バージョン 2 では、以下のタイプの脆弱性に対する新しい保護が追加されています。これらの脆弱性を使用して、IMDS にアクセスを試みることができます。

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

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

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

  • Open Layer 3 ファイアウォールおよびネットワークアドレス変換 (NAT)

セキュリティハブ では、EC2 インスタンスを IMDSv2 に設定することをお勧めします。

注記

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

Remediation

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

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

新しいインスタンスの起動時にそのインスタンスでの IMDSv2 の使用を要求するには、『https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html』の「新しいインスタンスのインスタンスメタデータオプションの設定Linux インスタンス用 Amazon EC2 ユーザーガイド」の手順に従います。

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

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

  2. [Launch instance (インスタンスの起動)]、[Launch instance (インスタンスの起動)] の順に選択します。

  3. [Configure Instance Details] ステップで、[Advanced Details] の [Metadata version] にある [V2 (token required)] を選択します。

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

ソフトウェアで IMDSv1 を使用している場合は、IMDSv2 を使用するようにソフトウェアを再設定できます。 詳細については、https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html#instance-metadata-transition-to-version-2 の「インスタンスメタデータサービスバージョン 2 を使用した への移行Linux インスタンス用 Amazon EC2 ユーザーガイド」を参照してください。

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

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

重大度:

リソース: EFS ファイルシステム

AWS Config ルール: efs-encrypted-check

パラメータ: なし

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

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

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

注記

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

Remediation

新しい Amazon EFS ファイルシステムを暗号化する方法の詳細については、https://docs.aws.amazon.com/efs/latest/ug/encryption-at-rest.html の「保管時のデータの暗号化Amazon Elastic File System ユーザーガイド」を参照してください。

[ELB.3] Classic Load Balancer リスナーは、HTTPS または TLS 終了で設定する必要があります

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

重大度:

リソース: ELB Load Balancer

AWS Config ルール: elb_tls_https_listeners_only

パラメータ: なし

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

Classic Load Balancer リスナーにフロントエンド接続用の TLS または HTTPS が設定されている場合、コントロールは渡されます。

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

ロードバランサーLoad Balancer リスナーとは、設定したプロトコルとポートを使用して接続リクエストをチェックするプロセスです。リスナーは、HTTP プロトコルと HTTPS/TLS プロトコルの両方をサポートできます。ロードバランサーLoad Balancer

Remediation

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

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

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

  3. [Listeners] タブを選択してから、[Edit] を選択します。

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

  5. 変更されたすべてのリスナーについて、[SSL Certificate] の [Change] を選択します。

  6. 変更されたすべてのリスナーで、[Choose a certificate from ACM (ACM から証明書を選択)] を選択します。

  7. [証明書] ドロップダウンリストから証明書を選択します。次に、[Save .] を選択します。

  8. すべてのリスナーを更新したら、[保存] を選択します。

[ELB.4] Application Load Balancer は、HTTP ヘッダーを削除するよう設定する必要があります

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

重大度:

リソースタイプ: ELB Load Balancer

AWS Config ルール: alb_http_drop_invalid_header_enabled

パラメータ: なし

このコントロールは、AWS Application Load Balancer (ALB) を評価して、無効な HTTP ヘッダーを削除するように設定されていることを確認します。の値が routing.http.drop_invalid_header_fields.enabled に設定されている場合、コントロールは失敗します。false

デフォルトでは、ALBs は無効な HTTP ヘッダー値を削除するよう設定されていません。これらのヘッダー値を削除すると、HTTP の非同期攻撃が防止されます。

注記

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

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

  • アジアパシフィック (大阪: ローカル)

  • ヨーロッパ (ミラノ)

Remediation

無効なヘッダーフィールドを削除するようにLoad Balancerを設定するには

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

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

  3. [Application Load Balancer] を選択します。

  4. [アクション] から、[属性の編集] を選択します。

  5. [Drop Invalid Header Fields] で、[Enable] を選択します。

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

[ELB.5] アプリケーションおよび Classic Load Balancer のログ記録を有効にする必要があります

カテゴリ: ログ記録

重大度:

リソース: ELB Load Balancer

AWS Config ルール: elb-logging-enabled

パラメータ: なし

このコントロールは、 Application Load Balancer と Classic Load Balancer のログ記録が有効になっているかどうかを確認します。が access_logs.s3.enabled の場合、コントロールは失敗します。false

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

詳細については、Load Balancer Classic ロードバランサーのアクセスログクラシックロードバランサー 用ユーザーガイド」を参照してください。

Remediation

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

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

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

  3. [Application Load Balancer] を選択します。

  4. [アクション] から、[属性の編集] を選択します。

  5. [アクセスログ] で、[有効化] を選択します。

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

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

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

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

重大度:

リソース: Elbv2 ロードバランサー

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

パラメータ: なし

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

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

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

注記

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

Remediation

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

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

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

  3. ] を選択します。Application Load Balancer.

  4. [Listeners] タブを選択します。

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

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

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

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

[EMR.1] Amazon EMR クラスターマスターノードにパブリック IP アドレスがあってはいけません

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

重大度:

リソースタイプ: EMR:Cluster

AWS Config ルール: emr-master-no-public-ip

パラメータ: なし

このコントロールは、Amazon EMR クラスターのマスターノードにパブリック IP アドレスがあるかどうかを確認します。

マスターノードに、そのインスタンスに関連付けられているパブリック IP アドレスがある場合、コントロールは失敗します。パブリック IP アドレスは、インスタンスの PublicIp 設定の NetworkInterfaces フィールドで指定されます。このコントロールは、Amazon EMR または RUNNING 状態の WAITING クラスターのみをチェックします。

注記

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

Remediation

起動時に、デフォルトサブネットまたはデフォルト以外のサブネットのインスタンスにパブリック IPv4 アドレスを割り当てるかどうかを制御できます。

デフォルトでは、デフォルトのサブネットでこの属性が true に設定されています。 デフォルト以外のサブネットでは、IPv4 パブリックアドレス属性が false に設定されています。ただし、Amazon EC2 起動インスタンスウィザードで作成されている場合は除きます。その場合、ウィザードは属性を true に設定します。

パブリックアドレス属性が IPv4 に設定されているプライベートサブネットを持つ VPC でクラスターを起動する必要があります。false

起動後、パブリック IPv4 アドレスとインスタンスの関連付けを手動で解除することはできません。

この結果を修正するには、VPC プライベートサブネットに新しいクラスターを作成する必要があります。クラスターを VPC プライベートサブネット内で起動する方法については、https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-vpc-launching-job-flows.html の「VPC でクラスターを起動するAmazon EMR 管理ガイド」を参照してください。

[ES.1] Elasticsearch ドメインは保存時の暗号化を有効にする必要があります

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

重大度:

リソース: Elasticsearch ドメイン

AWS Config ルール: elasticsearch-encrypted-at-rest

パラメータ: なし

このコントロールは、Amazon Elasticsearch Service (Amazon ES) ドメインで保管時の暗号化設定が有効になっているかどうかを確認します。保存時の暗号化が有効になっていない場合、チェックは失敗します。

Elasticsearch で機密データのセキュリティを強化するには、保管時に暗号化するように Elasticsearch を設定する必要があります。Elasticsearch ドメインは、保管中のデータの暗号化を提供します。この機能によって、AWS KMS を使用して、暗号化キーが保存および管理されます。暗号化を実行するには、256 ビットキー (AES-256) を使用した高度な暗号化標準アルゴリズムを使用します。

保管時の Elasticsearch 暗号化の詳細については、Amazon Elasticsearch Serviceの「 の保管時のデータの暗号化」を参照してください。Amazon Elasticsearch Service 開発者ガイド

注記

t.small や t.medium などの特定のインスタンスタイプでは、保管中のデータの暗号化がサポートされていません。詳細については、https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/aes-supported-instance-types.html の「サポートされるインスタンスタイプAmazon Elasticsearch Service 開発者ガイド」を参照してください。

Remediation

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

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

保管時のデータの暗号化には Amazon ES 5.1 以降が必要です。Amazon ES の保管時のデータの暗号化の詳細については、「Amazon Elasticsearch Service 開発者ガイド.」を参照してください。

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

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

重大度:

リソース: アカウント

AWS Config ルール: guardduty-enabled-centralized

パラメータ: なし

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

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

注記

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

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

  • 中国 (北京)

  • 中国 (寧夏)

  • ヨーロッパ (ミラノ)

  • 中東 (バーレーン)

  • AWS GovCloud (米国東部)

Remediation

を有効にするには (GuardDuty

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

  2. Get Started.] を選択します。

  3. GuardDuty の有効化.] を選択します。

[IAM.1] IAM ポリシーでは、完全な「*」管理権限を許可しないでください

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

重大度:

リソース: IAM ポリシー

AWS Config ルール: iam-policy-no-statements-with-admin-access

パラメータ: なし

このコントロールは、IAM ポリシーのデフォルトバージョン (顧客管理ポリシーとも呼ばれます) が、「効果」:「許可」と「アクション」:「*」と「リソース」:「*」のステートメントを含む管理者アクセス権を持っているかどうかをチェックします。

コントロールは、作成したカスタマー管理ポリシーのみをチェックします。インラインおよび AWS 管理ポリシーはチェックされません。

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

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

IAM ではなく "Effect": "Allow" を使用した "Action": "*" のステートメントを含む "Resource": "*". ポリシーは、削除する必要があります。

Remediation

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

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

  2. ポリシー.] を選択します。

  3. 削除するポリシーの横にあるボタンを選択します。

  4. Policy actions (ポリシーアクション)] から [Detach (デタッチ).] を選択します。

  5. ポリシーをデタッチする各ユーザーで、ユーザーの横にあるボタンを選択して、[Detach policy (ポリシーのデタッチ).] を選択します。

ポリシーをデタッチしたユーザーが、想定どおりに AWS サービスおよびリソースには引き続きアクセスできることを確認します。

[IAM.2] IAM ユーザーには IAM ポリシーをアタッチしないでください

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

重大度:

リソース: IAM ユーザー

AWS Config ルール: iam-user-no-policies-check

パラメータ: なし

このコントロールは、いずれの IAM ユーザーにもポリシーがアタッチされていないことを確認します。代わりに、IAM ユーザーは、IAM グループまたはロールからアクセス許可を継承する必要があります。

デフォルトでは、IAM ユーザー、グループ、およびロールは、AWS リソースへアクセスすることはできません。IAM ポリシーはユーザー、グループ、またはロールに権限を付与する方法です。IAM ポリシーはグループとロールには直接適用しますが、ユーザーには直接適用しません。グループレベルまたはロールレベルで権限を割り当てると、ユーザー数が増えるにつれてアクセス管理の複雑さが軽減されます。アクセス管理の複雑さを軽減することで、プリンシパルが誤って過剰な権限を受け取ったり保持したりする機会を減らすことができます。

Remediation

この問題を解決するには、 IAM グループを作成し、そのグループにポリシーを割り当て、ユーザーをグループに追加します。ポリシーは、グループ内の各ユーザーに適用されます。

IAM グループを作成するには

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

  2. グループ] を選択し、[Create New Group (新しいグループの作成).] を選択します。

  3. 作成するグループの名前を入力し、[次のステップ.] を選択します。

  4. グループに割り当てる各ポリシーを選択し、[次のステップ.] を選択します。選択したポリシーには、現在ユーザーアカウントに直接アタッチされているすべてのポリシーが含まれている必要があります。

  5. ユーザーをグループに追加し、そのグループにポリシーを割り当てます。グループ内の各ユーザーには、グループに割り当てられたポリシーが割り当てられます。

  6. 確認] ページで詳細を確認し、[グループの作成.] を選択します。

グループの作成の詳細については、IAM の「 グループの作成」を参照してください。IAM ユーザーガイド

IAM グループにユーザーを追加するには

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

  2. グループ.] を選択します。

  3. Group Actions (グループアクション)] で、[Add Users to Group (ユーザーをグループに追加).] を選択します。

  4. グループに追加するユーザーを選択し、[Add Users (ユーザーを追加).] を選択します。

グループへのユーザーの追加の詳細については、IAM の「 グループのユーザーの追加と削除」を参照してください。IAM ユーザーガイド

ユーザーに直接アタッチされているポリシーを削除するには

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

  2. ユーザー.] を選択します。

  3. ポリシーをデタッチするユーザーの User name 列から名前を選択します。

  4. Attached directly (直接アタッチ)] に一覧表示されている各ポリシーで、ページの右側にある [X] を選択してユーザーからポリシーを削除し、[削除.] を選択します。

  5. 想定した通りにユーザーが AWS サービスを利用できることを確認します。

[IAM.3] IAM ユーザーのアクセスキーは 90 日ごとに更新する必要があります

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

重大度:

リソース: IAM ユーザー

AWS Config ルール: access-keys-rotated

パラメータ:

  • maxAccessKeyAge: 90

このコントロールは、アクティブなアクセスキーが 90 日以内に更新されているかどうかをチェックします。

アカウントのすべてのアクセスキーを生成したり削除したりしないことを強くお勧めします。代わりに、1 つ以上の IAM ロールを作成するか、 フェデレーション.を使用することをお勧めします。これらの方法を使用すると、ユーザーが既存の企業認証情報を使用して AWS マネジメントコンソール および AWS CLI. にログインできます。

各アプローチにはユースケースがあります。フェデレーションは、既存の中央ディレクトリを持っている企業や、現在の制限 IAM ユーザーよりも多くを必要とする予定の企業にとって一般的に適しています。環境の外部で実行されるアプリケーションには、AWS リソースへのプログラムによるアクセスキーが必要です。AWS

ただし、プログラムによるアクセスを必要とするリソースが AWS 内部で実行されている場合は、IAM ロールを使用するのがベストプラクティスです。ロールを使用すると、アクセスキー ID とシークレットアクセスキーを設定にハードコーディングすることなく、リソースへのアクセスを許可できます。

アクセスキーとアカウントの保護の詳細については、AWS の「 アクセスキーを管理するためのベストプラクティス」を参照してください。AWS General Referenceまた、ブログ記事「プログラムによるアクセス使用中に AWS アカウントを保護するためのガイドライン.」も参照してください。

アクセスキーがすでにある場合、セキュリティハブ では 90 日ごとにアクセスキーを更新することをお勧めします。アクセスキーを更新することにより、侵害されたアカウントや終了したアカウントに関連付けられているアクセスキーが使用される可能性が低くなります。また、紛失したり、ひび割れたり、盗まれたりした古いキーでデータにアクセスできないようにします。アクセスキーを更新したら、必ずアプリケーションを更新してください。

AWS アクセスキーは、アクセスキー ID とシークレットアクセスキーで構成されます。これらは、AWS に対して行うプログラムリクエストに署名するために使用されます。AWS ユーザーは、AWS、Tools for Windows AWS CLI、PowerShell AWS、または個々の SDKs サービスの APIs を使用した直接 HTTP 呼び出しから AWS をプログラムで呼び出すために独自のアクセスキーが必要です。

組織で AWS シングルサインオン (AWS SSO) を使用している場合、ユーザーは Active Directory、組み込み AWS SSO ディレクトリ、または AWS SSO に接続された別の ID プロバイダー (IdP). にサインインできます。次に、IAM ユーザーアクセスキーを必要とせずに、AWS CLI コマンドを実行したり AWS APIs を呼び出したりできる IAM ロールにマッピングできます。詳細については、AWS CLI の「AWS シングルサインオン を使用するための の設定」を参照してください。AWS Command Line Interface ユーザーガイド

注記

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

Remediation

アクセスキーを 90 日間以上使用しないようにするには

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

  2. ユーザー.] を選択します。

  3. 90 日を超える [Access key age (アクセスキーの古さ)] を示す各ユーザーで、[ユーザー名] を選択してそのユーザーの設定を開きます。

  4. セキュリティ認証情報.] を選択します。

  5. ユーザーの新しいキーを作成するには:

    1. アクセスキーの作成.] を選択します。

    2. キーコンテンツを保存するには、シークレットアクセスキーをダウンロードするか、[表示] を選択してページからコピーします。

    3. ユーザーに提供する安全な場所にキーを格納します。

    4. Close.] を選択します。

  6. 以前のキーを使用していたすべてのアプリケーションを更新し、新しいキーを使用するようにします。

  7. 前のキーでは、[Make inactive (非アクティブにする)] を選択してアクセスキーを非アクティブにします。これで、ユーザーはそのキーを使用してリクエストを行うことができなくなります。

  8. すべてのアプリケーションが新しいキーで想定どおりに機能することを確認します。

  9. すべてのアプリケーションが新しいキーで想定どおりに機能することを確認したら、以前のキーを削除します。削除した後でアクセスキーを復元することはできません。

    前のキーを削除するには、行の末尾にある [X] を選択し、[削除.] を選択します。

[IAM.4] IAM ルートユーザーアクセスキーが存在してはいけません

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

重要度: 非常事態

リソース: アカウント

AWS Config ルール: iam-root-access-key-check

パラメータ: なし

このコントロールは、ルートユーザーのアクセスキーが存在するかどうかをチェックします。

ルートアカウントは、AWS アカウントで最も権限があるユーザーです。AWS アクセスキーは、プログラムから指定されたアカウントにアクセスできます。

セキュリティハブ では、ルートアカウントに関連付けられたすべてのアクセスキーを削除することをお勧めします。これにより、アカウントを侵害するために使用できるベクターが制限されます。また、最も権限の低いロールベースのアカウントの作成と使用が促進されます。

注記

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

Remediation

アクセスキーを削除するには

  1. AWS アカウントのルートユーザー の認証情報を使用してアカウントにログインします。

  2. ページの右上隅近くにあるアカウント名を選択し、[My Security Credentials (セキュリティの認証情報).] を選択します。

  3. ポップアップ警告で、[Continue to Security Credentials (セキュリティ認証情報に進む).] を選択します。

  4. アクセスキー (アクセスキー ID とシークレットアクセスキー).] を選択します。

  5. 完全にキーを削除するには、[Delete (削除)] を選択し、次に [Yes (はい).] を選択します。削除したキーを復元することはできません。

  6. 複数のルートユーザーアクセスキーがある場合は、キーごとにステップ 4 と 5 を繰り返します。

[IAM.5] コンソールパスワードを持つすべての IAM ユーザーに対して MFA を有効にする必要があります

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

重大度:

リソース: IAM ユーザー

AWS Config ルール: mfa-enabled-for-iam-console-access

パラメータ: なし

このコントロールは、コンソールパスワードを使用するすべての AWS ユーザーについて IAM Multi-Factor Authentication (MFA) が有効になっているかどうかを確認します。

多要素認証 (MFA) はユーザー名とパスワードの上に、もう 1 つの保護レイヤーを追加します。MFA が有効な場合、ユーザーが AWS ウェブサイトにサインインすると、ユーザー名とパスワードの入力を求められます。さらに、AWS MFA デバイスからの認証コードの入力が求められます。

コンソールパスワードを持つすべてのアカウントの MFA を有効にすることをお勧めします。MFA は、コンソールアクセスのセキュリティを強化するように設計されています。認証プリンシパルは、時間に依存するキーを発行するデバイスを所有し、認証情報に関する知識を持っている必要があります。

Remediation

ユーザーの MFA を設定するには

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

  2. ユーザー.] を選択します。

  3. MFA を設定するユーザーの [ユーザー名] を選択します。

  4. セキュリティ認証情報.] を選択します。

  5. Assigned MFA Device (割り当て済み MFA デバイス)] の横で、[管理.] を選択します。

  6. [MFA デバイスの管理] ウィザードに従って、環境に適したデバイスのタイプを割り当てます。

ユーザーに MFA セットアップを委任する方法については、「AWS IAM ユーザーに多要素認証の管理を委任する方法.」を参照してください。

[IAM.6] ルートユーザーに対してハードウェア MFA を有効にする必要があります

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

重要度: 非常事態

リソース: アカウント

AWS Config ルール: root-account-hardware-mfa-enabled

パラメータ: なし

このコントロールは、AWS アカウントのユーザーで、ルートユーザー の認証情報を使用してサインインする際に Multi-Factor Authentication (MFA) デバイスの使用が有効になっているかどうかを確認します。

仮想 MFA はハードウェア MFA デバイスと同じレベルのセキュリティを提供しない可能性があります。ハードウェアの購入承認の待機中、またはハードウェアの到着を待つ間にのみ、仮想 MFA デバイスを使用することをお勧めします。詳細については、 の「 Multi-Factor Authentication (MFA) デバイス (コンソール) の有効化」を参照してください。IAM ユーザーガイド

注記

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

  • 中国 (北京)

  • 中国 (寧夏)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (US-West).

Remediation

ルートアカウントのハードウェアベースの MFA を有効にするには

  1. ルートユーザー の認証情報を使用してアカウントにログインします。

  2. ページの右上隅近くにあるアカウント名を選択し、[My Security Credentials (セキュリティの認証情報).] を選択します。

  3. ポップアップ警告で、[Continue to Security Credentials (セキュリティ認証情報に進む).] を選択します。

  4. Multi-Factor Authentication (MFA) (多要素認証 (MFA)).] を選択します。

  5. MFA の有効化.] を選択します。

  6. MFA で使用するハードウェアベース (仮想ではない) のデバイスを選択し、 [続行.] を選択します。

  7. 選択に応じて適切なデバイスタイプを設定するステップを完了します。

[IAM.7] IAM ユーザーのパスワードポリシーには強力な設定が必要です

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

重大度:

リソース: アカウント

AWS Config ルール: iam-password-policy

パラメータ:

  • RequireUppercaseCharacters: true

  • RequireLowercaseCharacters: true

  • RequireSymbols: true

  • RequireNumbers: true

  • MinimumPasswordLength: 8

このコントロールは、IAM ユーザーのアカウントパスワードポリシーが次の推奨設定を使用しているかどうかをチェックします。

  • RequireUppercaseCharacters: true

  • RequireLowercaseCharacters: true

  • RequireSymbols: true

  • RequireNumbers: true

  • MinimumPasswordLength: 8

にアクセスするには、AWS マネジメントコンソール ユーザーにはパスワードが必要です。IAMベストプラクティスとして、セキュリティハブ では、IAM ユーザーを作成するのではなく、フェデレーションを使用することを強くお勧めします。フェデレーションを使用すると、ユーザーは既存の企業認証情報を使用して AWS マネジメントコンソールにログインできます。(AWS シングルサインオン) を使用してユーザーを作成またはフェデレーションし、AWS SSO ロールをアカウントに引き受けます。IAM

ID プロバイダーとフェデレーションの詳細については、https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html の「ID プロバイダーとフェデレーションIAM ユーザーガイド」を参照してください。の詳細については、「AWS SSOAWS シングルサインオン ユーザーガイド」を参照してください。

ユーザーを使用する必要がある場合は、IAM では、強力なユーザーパスワードの作成を強制することをお勧めします。セキュリティハブアカウントでパスワードポリシーを設定して、複雑な要件やパスワードの必須ローテーション期間を指定できます。AWSパスワードポリシーを作成または変更する場合、パスワードポリシーの設定のほとんどは、ユーザーが次回パスワードを変更するときに適用されます。一部の設定はすぐに適用されます。詳細については、https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html の「IAM ユーザー用のアカウントパスワードポリシーの設定IAM ユーザーガイド」を参照してください。

Remediation

パスワードポリシーを変更するには

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

  2. Account settings (アカウント設定).] を選択します。

  3. Requires at least one uppercase letter (少なくとも 1 つの大文字が必要).] を選択します。

  4. Requires at least one lowercase letter (少なくとも 1 つの小文字が必要).] を選択します。

  5. Requires at least one non-alphanumeric character (少なくとも 1 つの英数字以外の文字が必要).] を選択します。

  6. Requires at least one number (少なくとも 1 つの番号が必要です).] を選択します。

  7. Minimum password length (パスワードの最小長)] に「8.」と入力します。

  8. Apply Password Policy (パスワードポリシーの適用).] をクリックします。

[IAM.8] 使用されていない IAM ユーザー認証情報を削除する必要があります

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

重大度:

リソース: IAM ユーザー

AWS Config ルール: iam-user-unused-credentials-check

パラメータ:

  • maxCredentialUsageAge: 90

このコントロールは、IAM ユーザーが 90 日間使用されていないパスワードまたはアクティブなアクセスキーを持っているかどうかを確認します。

パスワードやアクセスキーなど、さまざまなタイプの認証情報を使用して IAM ユーザーは AWS リソースにアクセスできます。

セキュリティハブ では、90 日以上使用されていないすべての認証情報を削除または非アクティブ化することをお勧めします。不要な認証情報を無効化または削除することにより、認証情報が漏洩したり、放棄されたアカウントが使用される機会が少なくなります。

Remediation

日付付きの認証情報のアカウントを監視するために必要な一部の情報を取得するには、IAM コンソールを使用します。たとえば、アカウントのユーザーを表示する場合、[Access key age (アクセスキーの古さ)]、[Password age (パスワードの古さ)]、および [Last activity (最後のアクティビティ).] の列が表示されます。これらの列の値が 90 日より大きい場合は、それらのユーザーの認証情報を無効にします。

認証情報レポートを使用してユーザーアカウントを監視し、90 日以上アクティビティのないアカウントを特定することもできます。コンソールから .csv 形式で認証情報レポートをダウンロードできます。IAM認証情報レポートの詳細については、AWS の「 アカウントの認証情報レポートの取得」を参照してください。IAM ユーザーガイド

非アクティブなアカウントや使用されていない認証情報を識別したら、次のステップを使用してそれらを無効にします。

非アクティブなアカウントの認証情報を無効にするには

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

  2. ユーザー.] を選択します。

  3. 90 日を超えた認証情報を持つユーザーの名前を選択します。

  4. セキュリティ認証情報.] を選択します。

  5. 少なくとも 90 日間に使用されていないサインイン認証情報とアクセスキーごとに、[Make inactive] を選択します。

[KMS.1] IAM カスタマー管理ポリシーでは、すべての KMS キーに対する復号アクションを許可しないでください

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

重大度:

リソース: IAM ポリシー

AWS Config ルール: iam_customer_policy_blocked_kms_actions

パラメータ:

  • kms:ReEncryptFrom, kms:Decrypt

カスタマー管理ポリシーのデフォルトバージョンが、プリンシパルがすべてのリソースで IAM 復号アクションを使用できるようにするかどうかを確認します。AWS KMSこのコントロールは、自動推論エンジンである Zelkova を使用して、AWS アカウント間でシークレットに広範なアクセスを許可する可能性のあるポリシーを検証して警告します。

すべての KMS キーで kms:Decrypt または kms:ReEncryptFrom アクションが許可されている場合、このコントロールは失敗します。コントロールは、アタッチされているカスタマー管理ポリシーとアタッチされていないカスタマー管理ポリシーの両方を評価します。インラインポリシーまたは AWS 管理ポリシーはチェックされません。

では、だれがカスタマーマスターキー (AWS KMSCMKCMKs ポリシーは、ID (ユーザー、グループ、またはロール) がどのリソースに対してどのアクションを実行できるかを定義します。IAMセキュリティのベストプラクティスに従って、AWS では最小限の権限を許可することをお勧めします。つまり、kms:Decrypt または kms:ReEncryptFrom アクセス権限のみをアイデンティティに付与し、タスクを実行するために必要なキーに対してのみ付与する必要があります。そうしないと、ユーザーがデータに適切ではないキーを使用する場合があります。

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

Remediation

この問題を修正するには、IAM カスタマー管理ポリシーを変更して、キーへのアクセスを制限します。

カスタマー管理ポリシーを変更するにはIAM

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

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

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

  4. ポリシーの編集.] を選択します。

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

  6. 値を、許可する特定のキーに変更します。“Resource”

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

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

詳細については、IAM の「AWS KMS での ポリシーの使用」を参照してください。AWS Key Management Service Developer Guide

[KMS.2] IAM プリンシパルには、すべての KMS キーの復号アクションを許可する IAM インラインポリシーがあってはなりません

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

重大度:

リソース:

  • IAM ロール

  • IAM ユーザー

  • IAM グループ

AWS Config ルール: iam_inline_policy_blocked_kms_actions

パラメータ:

  • kms:ReEncryptFrom, kms:Decrypt

ID (ロール、ユーザー、またはグループ) に埋め込まれたインラインポリシーで、すべての KMS キーに対する IAM 復号アクションが許可されるかどうかを確認します。AWS KMSこのコントロールは、自動推論エンジンである Zelkova を使用して、AWS アカウント間でシークレットに広範なアクセスを許可する可能性のあるポリシーを検証して警告します。

インラインポリシーですべての KMS キーに対して kms:Decrypt または kms:ReEncryptFrom アクションが許可されている場合、このコントロールは失敗します。

では、だれがカスタマーマスターキー (AWS KMSCMKCMKs ポリシーは、アイデンティティ (ユーザー、グループ、またはロール) がどのリソースに対してどのアクションを実行できるかを定義します。IAMセキュリティのベストプラクティスに従って、AWS では最小限の特権を許可することをお勧めします。つまり、必要なアクセス許可のみをアイデンティティに付与し、タスクの実行に必要なキーに対してのみ付与する必要があります。そうしないと、ユーザーがデータに適切ではないキーを使用する場合があります。

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

Remediation

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

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

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

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

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

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

  5. ポリシーの編集.] を選択します。

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

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

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

  9. Save changes.] を選択します。

詳細については、IAM の「AWS KMS での ポリシーの使用」を参照してください。AWS Key Management Service Developer Guide

[Lambda.1] Lambda 関数ポリシーはパブリックアクセスを禁止する必要があります

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

重要度: 非常事態

リソース: Lambda 関数

AWS Config ルール: lambda-function-public-access-prohibited

パラメータ: なし

このコントロールは、Lambda 関数リソースベースのポリシーがパブリックアクセスを禁止しているかどうかをチェックします。

この Lambda 関数は、関数に保存されているコードへの意図しないアクセスを可能にする可能性があるため、パブリックにアクセスすることはできません。

注記

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

Remediation

関数がこのコントロールに失敗すると、Lambda 関数のリソースベースのポリシーステートメントでパブリックアクセスが許可されていることを示します。Lambda

問題を修正するには、ポリシーを更新する必要があります。リソースベースのポリシーは、Lambda API からのみ更新できます。これらの手順では、 コンソールを使用してポリシーを確認し、AWS Command Line Interface を使用してアクセス許可を削除します。

関数のリソースベースのポリシーを表示するにはLambda

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

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

  3. 関数を選択します。

  4. Permissions.] を選択します。リソースベースのポリシーには、別のアカウントまたは AWS のサービスが関数にアクセスしようとしたときに適用されるアクセス許可が表示されます。

  5. リソースベースのポリシーを確認します。ポリシーを公開する Principal フィールド値を持つポリシーステートメントを識別します。たとえば、"*" または { "AWS": "*" } を許可します。

    コンソールからポリシーを編集することはできません。関数からアクセス権限を削除するには、remove-permission から AWS CLI コマンドを使用します。

    削除するステートメントのステートメント ID (Sid) の値を書き留めます。

を使用して AWS CLI 関数からアクセス許可を削除するには、Lambdaremove-permission コマンドを発行します。

$ aws lambda remove-permission --function-name <function-name> --statement-id <statement-id>

<function-name> 関数の名前に置き換え、Lambda は削除するステートメントのステートメント ID に置き換えます。<statement-id>

アクセス許可が更新されていることを確認するには

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

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

  3. 更新した関数を選択します。

  4. Permissions.] を選択します。

    リソースベースのポリシーを更新する必要があります。ポリシーにステートメントが 1 つしかない場合、ポリシーは空です。

詳細については、AWS Lambda の「 でリソースベースのポリシーを使用する」を参照してください。AWS Lambda Developer Guide

[Lambda.2] Lambda 関数は最新のランタイムを使用する必要があります

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

重大度:

リソース: Lambda 関数

AWS Config ルール: lambda-function-settings-check

パラメータ:

  • runtime: nodejs12.x, nodejs10.x, python3.8, python3.7, python3.6, python2.7, ruby2.5, ruby2.7, java11, java8,go1.x, dotnetcore2.1, dotnetcore3.1

このコントロールは、ランタイムの Lambda 関数設定が、サポートされている各言語の最新のランタイムに設定されている期待値と一致することを確認します。このコントロールは、次のランタイムをチェックします。nodejs12.xnodejs10.xpython3.8python3.7python3.6ruby2.5ruby2.7java11java8go1.xdotnetcore2.1dotnetcore3.1

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

このコントロールがサポートされているすべての言語をチェックする最新のランタイムの詳細については、AWS Lambda の「 ランタイムAWS Lambda Developer Guide」を参照してください。

注記

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

Remediation

サポートされているランタイムと非推奨スケジュールの詳細については、https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html の「ランタイムサポートポリシーAWS Lambda Developer Guide」セクションを参照してください。ランタイムを最新バージョンに移行するときは、言語の発行元からの構文とガイダンスに従ってください。

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

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

重要度: 非常事態

リソース: RDS DB スナップショット

AWS Config ルール: rds-snapshots-public-prohibited

パラメータ: なし

このコントロールは、Amazon RDS スナップショットがパブリックかどうかをチェックします。

RDS スナップショットは、特定の時点の RDS インスタンスのデータをバックアップするために使用されます。RDS インスタンスの以前の状態を復元するために使用できます。

RDS スナップショットは、意図しない限りパブリックにすることはできません。暗号化されていない手動スナップショットをパブリックとして共有すると、このスナップショットをすべての AWS アカウントが使用できるようになります。これにより、RDS インスタンスの意図しないデータ漏えいが発生する可能性があります。

パブリックアクセスを許可するように構成を変更した場合、AWS Config ルールは最大 12 時間変更を検出できない場合があります。AWS Config ルールが変更を検出するまで、設定がルールに違反していてもチェックは成功します。

DB スナップショットの共有の詳細については、https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ShareSnapshot.html の「DB スナップショットの共有Amazon RDS ユーザーガイド」を参照してください。

注記

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

Remediation

RDS スナップショットのパブリックアクセスを削除するには

  1. https://console.aws.amazon.com/rds/ にある Amazon RDS コンソールを開きます。

  2. [Snapshots] に移動し、変更するパブリックスナップショットを選択します。

  3. アクション] から、[スナップショットの共有.] を選択します。

  4. DB snapshot visibility (DB スナップショットの可視性)] から、[Private (プライベート).] を選択します。

  5. DB snapshot visibility (DB スナップショットの可視性)] から、[all (すべて).] を選択します。

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

[RDS.2] RDS DB インスタンスは、PubliclyAccessible 設定によって決定されるパブリックアクセスを禁止する必要があります

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

重要度: 非常事態

リソース: RDS DB インスタンス

AWS Config ルール: rds-instance-public-access-check

パラメータ: なし

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

RDS インスタンス設定 の PubliclyAccessible 値は、DB インスタンスがパブリックにアクセスできるかどうかを示します。DB インスタンスが PubliclyAccessible で設定されている場合、パブリックに解決可能な DNS 名を持つインターネット向けインスタンスであり、パブリック IP アドレスに解決されます。DB インスタンスはパブリックにアクセスできない場合、プライベート IP アドレスに解決される DNS 名を持つ内部インスタンスです。

RDS インスタンスにパブリックにアクセスできるようにする場合を除き、RDS インスタンスを PubliclyAccessible 値に設定しないでください。これにより、データベースインスタンスへの不要なトラフィックが許可される可能性があります。

Remediation

RDS DB インスタンスからパブリックアクセスを削除するには

  1. https://console.aws.amazon.com/rds/ にある Amazon RDS コンソールを開きます。

  2. [データベース] に移動し、パブリックデータベースを選択します。

  3. Modify.] を選択します。

  4. [接続] で、[追加の接続設定] を展開します。

  5. [Public access (パブリックアクセス)] で、[Not public accessible (パブリックにアクセスできません)] を選択します。

  6. Continue.] を選択します。

  7. Scheduling of modifications (変更のスケジュール)] で [Apply immediately (すぐに適用).] を選択します。

  8. Modify DB Instance (DB インスタンスの変更).] を選択します。

詳細については、https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html の「VPC での DB インスタンスの操作Amazon RDS ユーザーガイド」を参照してください。

[RDS.3] RDS DB インスタンスでは、保管時の暗号化を有効にする必要があります

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

重大度:

リソース: RDS DB インスタンス

AWS Config ルール: rds-storage-encrypted

パラメータ: なし

このコントロールは、Amazon RDS DB インスタンスに対してストレージの暗号化が有効になっているかどうかを確認します。

RDS DB インスタンスの機密データのセキュリティを強化するには、RDS DB インスタンスを保管時に暗号化するように設定する必要があります。保管中の Amazon RDS DB インスタンスとスナップショットを暗号化するには、RDS DB インスタンスの暗号化オプションを有効にします。保管時に暗号化されるデータには、DB インスタンス、自動バックアップ、リードレプリカ、スナップショットの基本的なストレージが含まれます。

RDS の暗号化された DB インスタンスでは、RDS DB インスタンスをホストしているサーバーでデータを暗号化するために、業界標準の AES-256 暗号化アルゴリズムを使用します。データが暗号化されると、Amazon RDS はパフォーマンスの影響を最小限に抑えながら、データへのアクセスと復号の認証を透過的に処理します。暗号化を使用するために、データベースのクライアントアプリケーションを変更する必要はありません。

Amazon RDS の暗号化は、現在すべてのデータベースエンジンおよびストレージタイプで使用することができます。Amazon RDS 暗号化は、ほとんどの DB インスタンスクラスで使用することができます。暗号化をサポートしない DB インスタンスクラスについては、Amazon RDS の「Amazon RDS リソースの暗号化」を参照してください。Amazon RDS ユーザーガイド

Remediation

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

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

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

重大度:

リソースタイプ: DBClusterSnapshot, DBSnapshot

AWS Config ルール: rds-snapshots-encrypted

パラメータ: なし

このコントロールは、RDS DB スナップショットが暗号化されているかどうかを確認します。

保管時のデータを暗号化することで、未認証ユーザーがディスクに保存されているデータにアクセスするリスクを軽減できます。RDS スナップショット内のデータは、セキュリティを強化するために保管時に暗号化する必要があります。

Remediation

コンソールを使用して、この問題を修正できます。Amazon RDS

暗号化されていない RDS スナップショットを暗号化するには

  1. https://console.aws.amazon.com/rds/ にある Amazon RDS コンソールを開きます。

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

  3. [手動] または [システム] で暗号化するスナップショットを見つけます。

  4. 暗号化するスナップショットの横にあるチェックボックスをオンにします。

  5. [アクション]、[スナップショットのコピー] の順に選択します。

  6. [New DB Snapshot Identifier] に、新しいスナップショットの名前を入力します。

  7. [Encryption] で、[Enable Encryption] を選択します。

  8. スナップショットの暗号化に使用する KMS キーを選択します。

  9. Copy Snapshot.] を選択します。

  10. 新しいスナップショットが作成されたら、元のスナップショットを削除します。

  11. [バックアップの保存期間] で、ゼロ以外の正の値を選択します。たとえば、30 日間です。

[RDS.5] RDS DB インスタンスは、複数のアベイラビリティーゾーンで設定する必要があります

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

重大度:

リソースタイプ: DBInstance

AWS Config ルール: rds-multi-az-support

パラメータ: なし

このコントロールは、RDS DB インスタンスの高可用性が有効になっているかどうかを確認します。

RDS DB インスタンスは、複数のアベイラビリティーゾーン (AZs) に設定する必要があります。これにより、保存されたデータの可用性が保証されます。マルチ AZ 配置では、アベイラビリティーゾーンの可用性や定期的な RDS のメンテナンス時に問題が発生した場合に、自動フェイルオーバーが可能になります。

Remediation

DB インスタンスの複数のアベイラビリティーゾーンを有効にするには

  1. https://console.aws.amazon.com/rds/ にある Amazon RDS コンソールを開きます。

  2. ナビゲーションペインで、[データベース] を選択し、変更する DB インスタンスを選択します。

  3. Modify.] を選択します。[Modify DB Instance] ページが表示されます。

  4. [Instance Specifications] で、[Multi-AZ deployment] を [Yes] に設定します。

  5. [Continue] を選択し、変更の概要を確認します。

  6. (オプション) 変更をすぐに適用するには、[すぐに適用] を選択します。このオプションを選択すると、停止状態になる場合があります。詳細については、https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html#USER_ModifyInstance.ApplyImmediately の「Apply Immediately (すぐに適用) 設定の使用Amazon RDS ユーザーガイド」を参照してください。

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

[RDS.6] RDS DB インスタンスとクラスターには拡張モニタリングを設定する必要があります

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

重大度:

リソースタイプ: DBInstance

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

パラメータ: なし

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

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

拡張モニタリングのメトリクスが便利なのは、DB インスタンス上のさまざまなプロセスやスレッドがどのように CPU を使用しているかを表示するときです。詳細については、https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html の「拡張モニタリングAmazon RDS ユーザーガイド」を参照してください。

Remediation

DB インスタンスで拡張モニタリングを有効にする方法の詳細については、https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html#USER_Monitoring.OS.Enabling の「拡張モニタリングの設定と有効化Amazon RDS ユーザーガイド」を参照してください。

[RDS.7] RDS クラスターでは、削除保護を有効にする必要があります

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

重大度:

リソースタイプ: DBCluster

AWS Config ルール: rds-cluster-deletion-protection-enabled

パラメータ: なし

このコントロールは、RDS クラスターで削除保護が有効になっているかどうかを確認します。

クラスター削除保護の有効化は、権限のないエンティティによるデータベースの削除の偶発的な削除または削除に対する保護の追加レイヤーです。

削除保護が有効になっている場合、RDS クラスターは削除できません。削除リクエストが成功する前に、削除保護を無効にする必要があります。

注記

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

  • 中国 (北京)

  • 中国 (寧夏)

  • 中東 (バーレーン)

  • 南米 (サンパウロ).

Remediation

RDS DB クラスターの削除保護を有効にするには

  1. https://console.aws.amazon.com/rds/ にある Amazon RDS コンソールを開きます。

  2. ナビゲーションペインで、[データベース] を選択し、変更する DB クラスターを選択します。

  3. Modify.] を選択します。

  4. [削除保護] で、[削除保護の有効化] を選択します。

  5. Continue.] を選択します。

  6. [Scheduling of modifications (変更のスケジュール)] で、変更を適用するタイミングを選択します。オプションは、[Apply during the next scheduled maintenance window] または [Apply immediately] です。

  7. Modify Cluster.] を選択します。

[RDS.8] RDS DB インスタンスで削除保護を有効にする必要があります

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

重大度:

リソースタイプ: DBInstance

AWS Config ルール: rds-instance-deletion-protection-enabled

パラメータ: なし

このコントロールは、RDS DB インスタンスで削除保護が有効になっているかどうかを確認します。

インスタンスの削除保護の有効化は、権限のないエンティティによるデータベースの削除の偶発的な削除または削除に対する保護の追加レイヤーです。

削除保護が有効になっていると、RDS DB インスタンスは削除できません。削除リクエストが成功する前に、削除保護を無効にする必要があります。

Remediation

RDS DB インスタンスの削除保護を有効にするには

  1. https://console.aws.amazon.com/rds/ にある Amazon RDS コンソールを開きます。

  2. ナビゲーションペインで、[データベース] を選択し、変更する DB インスタンスを選択します。

  3. Modify.] を選択します。

  4. [削除保護] で、[削除保護の有効化] を選択します。

  5. Continue.] を選択します。

  6. [Scheduling of modifications (変更のスケジュール)] で、変更を適用するタイミングを選択します。オプションは、[Apply during the next scheduled maintenance window] または [Apply immediately] です。

  7. Modify DB Instance (DB インスタンスの変更).] を選択します。

[RDS.9] データベースのログ記録を有効にする必要があります

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

重大度:

リソース: DBInstance

AWS Config ルール: rds_logging_enabled

パラメータ:

  • お客様が提供したパラメータ:

    • [オプション] additionalLogs: セミコロンで区切られた '<Engine>: <comma-separated-logs>'

このコントロールは、Amazon RDS の次のログが有効であり、CloudWatch Logs に送信されているかどうかをチェックします。

  • Oracle: (アラート、監査、トレース、リスナー)

  • PostgreSQL : (Postgresql、Upgrade)

  • MySQL : (監査、エラー、一般、SlowQuery)

  • MariaDB : (監査、エラー、一般、SlowQuery)

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

  • Aurora: (監査、エラー、一般、SlowQuery)

  • Aurora-MySQL: (監査、エラー、全般、SlowQuery)

  • Aurora-PostgreSQL: (Postgresql、Upgrade)。

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

注記

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

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

アジアパシフィック (大阪: ローカル)

中国 (寧夏)

ヨーロッパ (ミラノ)

Remediation

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

、MariaDB、または MySQL ログを有効にして PostgreSQL から CloudWatch Logs に発行するには、カスタム DB パラメータグループで以下のパラメータを設定します。AWS マネジメントコンソール

データベースエンジン

パラメータ

MariaDB

general_log=1

slow_query_log=1

log_output = FILE

MariaDB には、以下に説明するカスタムオプショングループも必要です。

MySQL

general_log=1

slow_query_log=1

log_output = FILE

PostgreSQL

log_statement=all

log_min_duration_statement=minimum query duration (ms) to log

カスタム DB パラメータグループを作成するには

  1. https://console.aws.amazon.com/rds/ にある Amazon RDS コンソールを開きます。

  2. ナビゲーションペインで、[パラメータグループ.] を選択します。

  3. Create parameter group.] を選択します。[パラメータグループの作成] ウィンドウが表示されます。

  4. [パラメータグループ] ファミリーリストで、DB パラメータグループファミリーを選択します。

  5. [Type] リストで、[DB Parameter Group] を選択します。

  6. [グループ名] に新しい DB パラメータグループの名前を入力します。

  7. [説明] に、新しい DB パラメータグループの説明を入力します。

  8. 作成.] を選択します。

コンソールを使用して MariaDB ログ記録用の新しいオプショングループを作成するには

  1. https://console.aws.amazon.com/rds/ にある Amazon RDS コンソールを開きます。

  2. ナビゲーションペインで、[オプショングループ.] を選択します。

  3. Create group.] を選択します。

  4. [オプショングループの作成] ウィンドウで、以下の操作を行います。

    1. [名前] に、AWS アカウント内で一意であるオプショングループの名前を入力します。名前には、英字、数字、ハイフンのみを使用できます。

    2. [説明] に、オプショングループの簡単な説明を入力します。この説明は表示用に使用されます。

    3. [エンジン] で、使用する DB エンジンを選択します。

    4. [メジャーエンジンのバージョン] で、必要な DB エンジンのメジャーバージョンを選択します。

  5. 続行するには、[Yes, Create.(はい、作成する)] を選択します。

  6. 先ほど作成したオプショングループの名前を選択します。

  7. オプションの追加.] を選択します。

  8. を選択します。MARIADB_AUDIT_PLUGIN[オプション名] リストから

  9. SERVER_AUDIT_EVENTS に設定します。CONNECT, QUERY, TABLE, QUERY_DDL, QUERY_DML, QUERY_DCL

  10. オプションの追加.] を選択します。

SQL Server DB、Oracle DB、または PostgreSQL ログを CloudWatch から AWS マネジメントコンソール ログに発行するには

  1. https://console.aws.amazon.com/rds/ にある Amazon RDS コンソールを開きます。

  2. ナビゲーションペインで、[データベース.] を選択します。

  3. 変更する DB インスタンスを選択します。

  4. Modify.] を選択します。

  5. [Log exports (ログのエクスポート)] で、CloudWatch Logs への発行を開始するすべてのログファイルを選択します。

    ログのエクスポートは、CloudWatch Logs への発行をサポートするデータベースエンジンバージョンでのみ使用できます。

  6. Continue.] を選択します。次に、[Summary] ページで、[Modify DB Instance] を選択します。

新しい DB パラメータグループまたは DB オプショングループを RDS DB インスタンスに適用するには

  1. https://console.aws.amazon.com/rds/ にある Amazon RDS コンソールを開きます。

  2. ナビゲーションペインで、[データベース.] を選択します。

  3. 変更する DB インスタンスを選択します。

  4. Modify.] を選択します。[Modify DB Instance] ページが表示されます。

  5. [データベースの選択肢] で、必要に応じて DB パラメータグループと DB オプショングループを変更します。

  6. 変更が完了したら、[Continue] を選択します。変更の概要を確認します。

  7. (オプション) 変更をすぐに適用するには、[すぐに適用] を選択します。このオプションを選択すると、停止状態になる場合があります。詳細については、https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html#USER_ModifyInstance.ApplyImmediately の「Apply Immediately (すぐに適用) 設定の使用Amazon RDS ユーザーガイド」を参照してください。

  8. [Modify DB Instance] を選択して変更を保存します。

[RDS.10] IAM 認証を RDS インスタンス用に設定する必要があります

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

重大度:

リソース: DBInstance

AWS Config ルール: rds-instance-iam-authentication-enabled

パラメータ: なし

このコントロールは、RDS DB インスタンスで IAM データベース認証が有効になっているかどうかを確認します。

IAM データベース認証では、パスワードの代わりに認証トークンを使用してデータベースインスタンスを認証できます。データベースに出入りするネットワークトラフィックは、SSL を使用して暗号化されます。詳細については、https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.html の「IAM データベース認証Amazon Aurora ユーザーガイド」を参照してください。

注記

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

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

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

アジアパシフィック (大阪: ローカル)

中国 (北京)

中国 (寧夏)

Remediation

既存の DB インスタンスに対して IAM 認証を有効にするには

  1. https://console.aws.amazon.com/rds/ にある Amazon RDS コンソールを開きます。

  2. データベース.] を選択します。

  3. 変更する DB インスタンスを選択します。

  4. Modify.] を選択します。

  5. [データベースの選択肢] で、[ DB 認証の有効化IAM] を選択します。

  6. Continue.] を選択します。

  7. [Scheduling of modifications (変更のスケジュール)] で、変更を適用するタイミングを選択します。オプションは、[Apply during the next scheduled maintenance window] または [Apply immediately] です。

  8. クラスターの場合は、[DB インスタンスの変更] を選択します。

[RDS.11] RDS インスタンスでは、自動バックアップを有効にする必要があります

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

重大度:

リソース: DBInstance

AWS Config ルール: db-instance-backup-enabled

パラメータ:

  • によって設定されたデフォルトのパラメータ: セキュリティハブretentionPeriod = 7

  • お客様が指定したパラメータ: [オプション] retentionPeriod = integer 1-35

このコントロールは、RDS DB インスタンスで自動バックアップが有効になっているかどうか、バックアップ保持期間が 7 以上かどうかを確認します。必要に応じて、比較する retentionPeriod を指定できます。以下の条件がすべて当てはまる場合、コントロールは合格します。

  • バックアップが有効になります。

  • バックアップ保持期間が retentionPeriod 以上であること。

  • 保持期間が 7 以上である。

バックアップは、セキュリティインシデントからより迅速に復旧するのに役立ちます。また、システムの耐障害性を強化します。Amazon RDS では、毎日のフルインスタンスボリュームスナップショットを簡単に設定できます。このコントロールは、バックアップが有効であり、7 日間以上保持されていることを確認します。自動バックアップの詳細については、Amazon RDS の「バックアップの使用」を参照してください。Amazon RDS ユーザーガイド

Remediation

自動バックアップをすぐに有効にするには

  1. https://console.aws.amazon.com/rds/ にある Amazon RDS コンソールを開きます。

  2. ナビゲーションペインで、[データベース.] を選択します。

  3. 変更する DB インスタンスを選択してから、[変更] を選択します。[Modify DB Instance] ページが表示されます。

  4. [バックアップの保存期間] で、ゼロ以外の正の値 (30 日など) を選択します。

  5. Continue.] を選択します。

  6. [Scheduling of modifications (変更のスケジュール)] で、変更を適用するタイミングを選択します。オプションは、[Apply during the next scheduled maintenance window] または [Apply immediately] です。

  7. 確認ページで、[Modify DB Instance] を選択して変更を保存し、自動バックアップを有効にします。

自動バックアップの有効化の詳細については、Amazon RDS の「自動バックアップの有効化」を参照してください。Amazon RDS ユーザーガイド

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

カテゴリ: 保護 - セキュアなネットワーク構成 > リソースにパブリックアクセス不可

重要度: 非常事態

リソース: クラスター

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

パラメータ: なし

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

クラスター設定の PubliclyAccessible 属性は、クラスターがパブリックにアクセス可能かどうかを示します。Amazon Redshiftが PubliclyAccessible に設定されているクラスターは、パブリックに解決可能な DNS 名を持つインターネット向けインスタンスであり、パブリック IP アドレスに解決されます。true

クラスターがパブリックにアクセス可能でない場合、プライベート IP アドレスに解決される DNS 名を持つ内部インスタンスです。クラスターにパブリックにアクセスできるようにする場合を除き、クラスターを PubliclyAccessible に設定しないでください。true

Remediation

クラスターへのパブリックアクセスを無効にするにはAmazon Redshift

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

  2. ナビゲーションメニューで、[クラスター] を選択し、変更するセキュリティグループを含むクラスターの名前を選択します。

  3. [Actions] を選択してから、[Modify publicly accessible settings] を選択します。

  4. [Allow instances and devices outhide the VPC to connect to your database through the cluster endpoint] で、[No] を選択します。

  5. Confirm.] を選択します。

[Redshift.2] Amazon Redshift クラスターへの接続は転送時に暗号化する必要があります

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

重大度:

リソース: クラスター

AWS Config ルール: redshift-require-tls-ssl

パラメータ: なし

このコントロールは、転送中に暗号化を使用するために Amazon Redshift クラスターへの接続が必要かどうかをチェックします。クラスターパラメータ Amazon Redshift が 1 に設定されていない場合、チェックは失敗します。require_SSL

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

注記

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

Remediation

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

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

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

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

  4. [パラメータ] を選択します。

  5. [パラメータの編集] を選択し、require_ssl を 1 に設定します。

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

[Redshift.3] Amazon Redshift クラスターでは、自動スナップショットを有効にする必要があります

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

重大度:

リソース: クラスター

AWS Config ルール: redshift-backup-enabled

パラメータ:

  • によって設定されたデフォルトのパラメータ: セキュリティハブMinRetentionPeriod = 7

このコントロールは、Amazon Redshift クラスターで自動スナップショットが有効になっているかどうかを確認します。また、スナップショット保持期間が 7 以上であるかどうかも確認します。

バックアップは、セキュリティインシデントからより迅速に復旧するのに役立ちます。これらはシステムの耐障害性を強化します。Amazon Redshift は、デフォルトでは定期的にスナップショットを作成します。このコントロールは、自動スナップショットが有効で 7 日間以上保持されているかどうかを確認します。自動スナップショットの詳細については、Amazon Redshift の「自動スナップショット」を参照してください。Amazon Redshift Cluster Management Guide

注記

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

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

  • アジアパシフィック (大阪: ローカル)

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

  • 中国 (寧夏)

  • ヨーロッパ (ミラノ)

Remediation

スナップショット保持期間を変更するには

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

  2. ナビゲーションメニューで [クラスター] を選択し、変更するクラスターの名前を選択します。

  3. Edit.] を選択します。

  4. [Backup] で、[Snapshot retention] の値を 7 以上の値に設定します。

  5. Modify Cluster.] を選択します。

[Redshift.6] Amazon Redshift ではメジャーバージョンへの自動アップグレードを有効にする必要があります

カテゴリ: 検出 - 脆弱性およびパッチ管理

重大度:

リソース: クラスター

AWS Config ルール: redshift-cluster-maintenancesettings-check

パラメータ:

  • によって設定されたデフォルトのパラメータ:セキュリティハブ allowVersionUpgrade = true

このコントロールは、Amazon Redshift クラスターに対して自動メジャーバージョンアップグレードが有効になっているかどうかを確認します。

自動メジャーバージョンアップグレードを有効にすると、メンテナンスの時間帯に、Amazon Redshift クラスターに対する最新のメジャーバージョン更新がインストールされます。これらの更新には、セキュリティパッチとバグ修正が含まれる場合があります。パッチのインストールを最新の状態に保つことは、システムを保護するための重要なステップです。

注記

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

Remediation

からこの結果を修正するには、AWS CLI Amazon Redshift コマンドを使用して、modify-cluster 属性を設定します。--allow-version-upgrade

aws redshift modify-cluster --cluster-identifier clustername --allow-version-upgrade

は、clustername クラスターの名前です。Amazon Redshift

[S3.1] S3 ブロックパブリックアクセス設定を有効にする必要があります

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

重大度:

リソース: アカウント

AWS Config ルール: s3-account-level-public-access-blocks

パラメータ:

  • ignorePublicAcls: true

  • blockPublicPolicy: true

  • blockPublicAcls: true

  • restrictPublicBuckets: true

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

  • ignorePublicAcls: true

  • blockPublicPolicy: true

  • blockPublicAcls: true

  • restrictPublicBuckets: true

Amazon S3 パブリックアクセスブロックは、AWS アカウント全体または個々の S3 バケットレベルでコントロールを提供し、オブジェクトがパブリックアクセスを決して持たないように設計されています。パブリックアクセスは、アクセスコントロールリスト (ACL)、バケットポリシー、またはその両方からバケットおよびオブジェクトに付与されます。

S3 バケットをパブリックにアクセスできるようにする場合を除き、アカウントレベルの Amazon S3 ブロックパブリックアクセス機能を設定する必要があります。

詳細については、Amazon S3 の「 ブロックパブリックアクセスの使用」を参照してください。Amazon Simple Storage Service 開発者ガイド

注記

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

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

  • ヨーロッパ (ミラノ)

  • 中東 (バーレーン)

Remediation

Amazon S3 ブロックパブリックアクセスを有効にするには

  1. https://console.aws.amazon.com/s3/ にある Amazon S3 コンソールを開きます。

  2. Block public access (account settings) (ブロックパブリックアクセス (アカウント設定)).] を選択します。

  3. Edit.] を選択します。

  4. [Block all public access (すべてのパブリックアクセスをブロック)] を選択します。

  5. Save changes.] を選択します。

詳細については、Amazon S3 の「 ブロックパブリックアクセスの使用」を参照してください。Amazon Simple Storage Service 開発者ガイド

[S3.2] S3 バケットではパブリック読み取りアクセスを禁止する必要があります

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

重要度: 非常事態

リソース: S3 バケット

AWS Config ルール: s3-bucket-public-read-prohibited

パラメータ: なし

このコントロールは、S3 バケットがパブリック読み取りアクセスを許可するかどうかをチェックします。これにより、ブロックパブリックアクセス設定、バケットポリシー、およびバケットアクセスコントロールリスト (ACL) を確認します。

ユースケースによっては、インターネット上の全員が S3 バケットから読み取れる必要があります。しかし、そのような状況はまれです。データの整合性とセキュリティを確保するために、S3 バケットをパブリックに読み取り可能にしないでください。

Remediation

S3 バケットに対するパブリックアクセスを削除するには

  1. https://console.aws.amazon.com/s3/ にある Amazon S3 コンソールを開きます。

  2. 左のナビゲーションペインで [バケット] を選択します。

  3. 更新する S3 バケットの名前を選択します。

  4. [アクセス許可]、[パブリックアクセスブロック] の順に選択します。

  5. Edit.] を選択します。

  6. [Block all public access (すべてのパブリックアクセスをブロック)] を選択します。次に、[Save .] を選択します。

  7. プロンプトが表示されたら、confirm を入力し、[確認.] を選択します。

[S3.3] S3 バケットはパブリック書き込みアクセスを禁止する必要があります

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

重要度: 非常事態

リソース: S3 バケット

AWS Config ルール: s3-bucket-public-write-prohibited

パラメータ: なし

このコントロールは、S3 バケットがパブリック書き込みアクセスを許可するかどうかをチェックします。これにより、ブロックパブリックアクセス設定、バケットポリシー、およびバケットアクセスコントロールリスト (ACL) を確認します。

ユースケースによっては、インターネット上の全員が S3 バケットに書き込むことができる必要があります。しかし、そのような状況はまれです。データの整合性とセキュリティを確保するため、S3 バケットはパブリックに書き込み可能にしないでください。

Remediation

S3 バケットに対するパブリックアクセスを削除するには

  1. https://console.aws.amazon.com/s3/ にある Amazon S3 コンソールを開きます。

  2. 左のナビゲーションペインで [バケット] を選択します。

  3. 更新する S3 バケットの名前を選択します。

  4. [アクセス許可]、[パブリックアクセスブロック] の順に選択します。

  5. Edit.] を選択します。

  6. [Block all public access (すべてのパブリックアクセスをブロック)] を選択します。次に、[Save .] を選択します。

  7. プロンプトが表示されたら、confirm を入力し、[確認.] を選択します。

[S3.4] S3 バケットでは、サーバー側の暗号化を有効にする必要があります

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

重大度:

リソース: S3 バケット

AWS Config ルール: s3-bucket-server-side-encryption-enabled

パラメータ: なし

このコントロールは、S3 バケットで Amazon S3 のデフォルトの暗号化が有効になっていること、または S3 バケットポリシーでサーバー側の暗号化なしの put-object リクエストを明示的に拒否することを確認します。

S3 バケット内の機密データのセキュリティを強化するには、サーバー側の暗号化を使用してバケットを設定し、保管中のデータを保護する必要があります。Amazon S3 は、一意のキーで各オブジェクトを暗号化します。追加の安全策として、キー自体を定期的に更新するマスターキーで暗号化します。Amazon S3 サーバー側の暗号化は、利用可能な最も強力なブロック暗号の 1 つである 256 ビットの Advanced Encryption Standard (AES-256) を使用してデータを暗号化します。

詳細については、Amazon S3 の「 で管理された暗号化キーによるサーバー側の暗号化 (SSE-S3) を使用したデータの保護」を参照してください。Amazon Simple Storage Service 開発者ガイド

Remediation

S3 バケットのデフォルト暗号化を有効にする

  1. https://console.aws.amazon.com/s3/ にある Amazon S3 コンソールを開きます。

  2. 左のナビゲーションペインで [バケット] を選択します。

  3. リストから S3 バケットを選択します。

  4. プロパティ.] を選択します。

  5. Default encryption (デフォルト暗号化).] を選択します。

  6. 暗号化には、[AES-256] または [AWS-KMS.] のいずれかを選択します。

    • によって管理されるキーをデフォルト暗号化に使用するには、[AES-256] を選択します。Amazon S3Amazon S3 サーバー側の暗号化を使用してデータを暗号化する方法の詳細については、「Amazon Simple Storage Service 開発者ガイド.」を参照してください。

    • [AWS-KMS] を選択して、AWS KMS が管理するキーをデフォルトの暗号化に使用します。次に、作成したマスターキーのリストから AWS KMS マスターキーを選択します。

      使用する AWS KMS キーの Amazon リソースネーム (ARN) を入力します。AWS KMS キーの ARN は、IAM コンソールの [Encryption keys (暗号化キー).] の下にあります。または、ドロップダウンリストからキー名を選択します。

      重要

      デフォルト暗号化設定に AWS KMS オプションを使用する場合、AWS KMS. の RPS (1 秒あたりのリクエスト) のクォータが適用されます。AWS KMS クォータの詳細およびクォータの引き上げをリクエストする方法については、「AWS Key Management Service Developer Guide.」を参照してください。

      AWS KMS キーの作成の詳細については、「AWS Key Management Service Developer Guide.」を参照してください。

      AWS KMS を Amazon S3 と組み合わせて使用する方法の詳細については、「Amazon Simple Storage Service 開発者ガイド.」を参照してください。

    デフォルト暗号化を有効にする際、バケットポリシーの更新が必要な場合があります。バケットポリシーからデフォルト暗号化への移行の詳細については、「Amazon Simple Storage Service 開発者ガイド」を参照してください。

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

デフォルトの S3 バケット暗号化の詳細については、「Amazon Simple Storage Service コンソールユーザーガイド」を参照してください。

[S3.5] S3 バケットでは、Secure Socket Layer を使用するためのリクエストが必要です。

重大度:

リソース: S3 バケット

AWS Config ルール: s3-bucket-ssl-requests-only

パラメータ: なし

このコントロールは、S3 バケットに Secure Socket Layer (SSL) を使用するためのリクエストを必要とするポリシーがあるかどうかを確認します。

S3 バケットのポリシーでは、条件キー Action: S3:* で示される S3 リソースポリシーで HTTPS 経由のデータの送信のみを許可するように、すべてのリクエスト (aws:SecureTransport) を要求する必要があります。

Remediation

この問題を修正するには、S3 バケットのアクセス権限ポリシーを更新します。

S3 バケットを設定して安全でない移行を拒否するには

  1. https://console.aws.amazon.com/s3/ にある Amazon S3 コンソールを開きます。

  2. 非準拠のバケットに移動し、バケット名を選択します。

  3. Permissions (アクセス許可)] を選択し、[Bucket Policy (バケットポリシー).] を選択します。

  4. 以下のポリシーのものと同じようなポリシーステートメントを追加します。を、変更しているバケットの名前に置き換えます。awsexamplebucket

    { "Id": "ExamplePolicy", "Version": "2012-10-17", "Statement": [ { "Sid": "AllowSSLRequestsOnly", "Action": "s3:*", "Effect": "Deny", "Resource": [ "arn:aws:s3:::awsexamplebucket", "arn:aws:s3:::awsexamplebucket/*" ], "Condition": { "Bool": { "aws:SecureTransport": "false" } }, "Principal": "*" } ] }
  5. Save.] を選択します。

詳細については、ナレッジセンターの記事「 ルール s3-bucket-ssl-requests-onlyAWS Config」に準拠するためにどの S3 バケットポリシーを使用する必要がありますか?

[S3.6] バケットポリシーの他の Amazon S3 アカウントに付与される AWS アクセス許可は制限する必要があります

カテゴリ: 保護 - セキュアなアクセス管理 > 制限された APIs アクション

重大度:

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

AWS Config ルール: s3-bucket-blacklisted-actions-prohibited

パラメータ:

によって設定されたデフォルトのパラメータ:セキュリティハブ

  • blacklistedactionpatterns: s3:DeleteBucketPolicy, s3:PutBucketAcl, s3:PutBucketPolicy, s3:PutEncryptionConfiguration, s3:PutObjectAcl

お客様が提供したパラメータ:

  • blacklistedactionpatterns 。 これは、拒否するアクションパターンのカンマ区切りリストです。たとえば、s3:PutBucketPolicy and s3:DeleteObject と指定します。

このコントロールは、S3 バケットポリシーによって他の AWS アカウントのプリンシパルが S3 バケット内のリソースに対して拒否されたアクションを実行できなくなっているかどうかを確認します。S3 バケットポリシーが別の AWS アカウントのプリンシパルに次のいずれかのアクションを許可する場合、コントロールは失敗します。

  • s3:DeleteBucketPolicy

  • s3:PutBucketAcl

  • s3:PutBucketPolicy

  • s3:PutEncryptionConfiguration

  • s3:PutObjectAcl

最小限の特権アクセスの実装は、セキュリティリスクとエラーや悪意のあるインテントの影響を軽減するための基本となります。S3 バケットポリシーで外部アカウントからのアクセスが許可されている場合、そのポリシーは、部見脅威または攻撃者によるデータの不正引き出しにつながる可能性があります。

パラメータは、S3 バケットのルールを正常に評価できるようにします。blacklistedactionpatternsこのパラメータは、blacklistedactionpatterns リストに含まれていないアクションパターンの外部アカウントへのアクセスを許可します。

Remediation

この問題を修正するには、S3 バケットポリシーを編集してアクセス許可を削除します。

S3 バケットポリシーを編集するには

  1. https://console.aws.amazon.com/s3/ にある Amazon S3 コンソールを開きます。

  2. [バケット名] リストで、ポリシーを編集する S3 バケットの名前を選択します。

  3. Permissions (アクセス許可)] を選択し、[Bucket Policy (バケットポリシー).] を選択します。

  4. [Bucket policy editor] テキストボックスで、次のいずれかを実行します。

    • 他の AWS アカウントに対して拒否されたアクションへのアクセスを許可するステートメントを削除する

    • 許可された拒否アクションをステートメントから削除する

  5. Save.] を選択します。

[SageMaker.1] SageMaker ノートブックインスタンスは直接インターネットにアクセスできません

重大度:

リソース: SageMaker:NotebookInstance

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

パラメータ: なし

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

VPC を使用せずに SageMaker インスタンスを設定すると、インスタンスではデフォルトで直接インターネットアクセスが有効になります。VPC を使用してインスタンスを設定し、デフォルト設定を [Disable — Access the internet through a VPC] に変更する必要があります。

ノートブックからモデルをトレーニングまたはホストするには、インターネットアクセスが必要です。インターネットアクセスを有効にするには、VPC に NAT ゲートウェイがあり、セキュリティグループでアウトバウンド接続が許可されていることを確認します。ノートブックインスタンスを VPC のリソースに接続する方法の詳細については、https://docs.aws.amazon.com/sagemaker/latest/dg/appendix-notebook-and-internet-access.html の「ノートブックインスタンスを VPC のリソースに接続するAmazon SageMaker 開発者ガイド」を参照してください。

また、SageMaker 設定へのアクセスが、承認されたユーザーのみに制限されていることを確認する必要があります。ユーザーの IAM アクセス許可を制限して、SageMaker の設定とリソースを変更します。

注記

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

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

  • 中国 (北京)

  • 中国 (寧夏)

  • ヨーロッパ (ミラノ)

  • AWS GovCloud (米国東部)

Remediation

ノートブックインスタンスの作成後にインターネットアクセス設定を変更することはできません。停止、削除、再作成する必要があります。

直接インターネットアクセスを拒否するように SageMaker ノートブックインスタンスを設定するには

  1. コンソール (SageMakerhttps://console.aws.amazon.com/sagemaker/) を開きます

  2. [ノートブックインスタンス] に移動します。

  3. 直接インターネットアクセスが有効になっているインスタンスを削除します。インスタンスを選択し、[Actions] を選択してから、[Stop] を選択します。

    インスタンスが停止したら、[Actions]、[delete] の順に選択します。

  4. ノートブックインスタンスの作成.を選択します。設定の詳細を指定します。

  5. ネットワークセクションを展開し、VPC、サブネット、およびセキュリティグループを選択します。[直接インターネットアクセス] で、[無効化 - VPC 経由でインターネットにアクセス] を選択します。

  6. ノートブックインスタンスの作成.を選択します。

詳細については、https://docs.aws.amazon.com/sagemaker/latest/dg/appendix-notebook-and-internet-access.html の「ノートブックインスタンスを VPC 内のリソースに接続するAmazon SageMaker 開発者ガイド」を参照してください。

[SecretsManager.1] Secrets Manager シークレットは自動ローテーションを有効にする必要があります

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

重大度:

リソース: シークレットSecrets Manager

AWS Config ルール: secretsmanager-rotation-enabled-check

パラメータ: なし

このコントロールは、AWS Secrets Manager に保存されているシークレットに自動ローテーションが設定されているかどうかを確認します。

Secrets Manager は、組織のセキュリティ体制の向上に役立ちます。シークレットには、データベースの認証情報、パスワード、およびサードパーティーの API キーが含まれます。を使用すると、シークレットを一元的に保存したり、シークレットを自動的に暗号化したり、シークレットへのアクセスを制御したり、シークレットを安全かつ自動的に更新したりできます。Secrets Manager

Secrets Manager はシークレットを更新できます。ローテーションを使用して、長期のシークレットを短期のシークレットに置き換えることができます。シークレットの更新では、許可されていないユーザーが侵害されたシークレットを使用できる期間を制限します。このため、シークレットを頻繁にローテーションする必要があります。ローテーションの詳細については、AWS Secrets Manager の「 シークレットの更新」を参照してください。AWS Secrets Manager ユーザーガイド

Remediation

この問題を修正するには、シークレットの自動ローテーションを有効にします。

シークレットの自動ローテーションを有効にするには

  1. コンソール (Secrets Managerhttps://console.aws.amazon.com/secretsmanager) を開きます。

  2. ローテーションが必要なシークレットを見つけるには、検索フィールドにシークレット名を入力します。

  3. 更新するシークレットを選択すると、シークレットの詳細ページが表示されます。

  4. [Rotation configuration (ローテーション設定)] で、[Edit rotation (ローテーションの編集)] を選択します。

  5. [Edit rotation configuration (ローテーション設定の編集)] で、[Enable automatic rotation (自動ローテーションを有効化する)] を選択します。

  6. [Select Rotation Interval] で、ローテーション間隔を選択します。

  7. ローテーションする Lambda 関数を選択します。ローテーション関数のカスタマイズについては、Lambda の「 ローテーション関数の理解とカスタマイズLambda」を参照してください。AWS Secrets Manager ユーザーガイド

  8. ローテーション用にシークレットを設定するには、[次へ] を選択します。

の更新の詳細については、Secrets Manager の「AWS Secrets Manager シークレットの更新」を参照してください。AWS Secrets Manager ユーザーガイド

[SecretsManager.2] 自動ローテーションで設定された Secrets Manager シークレットは正常にローテーションする必要があります

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

重大度:

リソース: シークレットSecrets Manager

AWS Config ルール: secretsmanager-scheduled-rotation-success-check

パラメータ: なし

このコントロールは、ローテーションスケジュールに基づいて AWS Secrets Manager シークレットが正常にローテーションされたかどうかをチェックします。が RotationOccurringAsScheduled の場合、コントロールは失敗します。false このコントロールは、ローテーションが設定されていないシークレットは評価しません。

Secrets Manager は、組織のセキュリティ体制を向上させるのに役立ちます。シークレットには、データベースの認証情報、パスワード、およびサードパーティーの API キーが含まれます。を使用すると、シークレットを一元的に保存したり、シークレットを自動的に暗号化したり、シークレットへのアクセスを制御したり、シークレットを安全かつ自動的に更新したりできます。Secrets Manager

Secrets Manager はシークレットを更新できます。ローテーションを使用して、長期のシークレットを短期のシークレットに置き換えることができます。シークレットの更新では、許可されていないユーザーが侵害されたシークレットを使用できる期間を制限します。このため、シークレットを頻繁にローテーションする必要があります。

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

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

Remediation

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

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

シークレットのローテーションに関連する一般的なエラーを診断および修正する方法については、AWS Secrets Manager の「 シークレットの ローテーションのトラブルシューティングAWS Secrets Manager ユーザーガイド」を参照してください。

[SNS.1] SNS トピックは、AWS KMS を使用して保管時に暗号化する必要があります

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

重大度:

リソース: Amazon SNS トピック

AWS Config ルール: sns-encrypted-kms

パラメータ: なし

このコントロールは、SNS トピックが AWS KMS を使用して保管時に暗号化されているかどうかを確認します。

保管時のデータを暗号化することで、AWS に対して認証されていないユーザーがディスクに保存されているデータにアクセスするリスクを軽減できます。また、不正なユーザーによるデータへのアクセスを制限する別の一連のアクセス制御も追加されます。たとえば、データを読み取る前に復号するために API のアクセス権限が必要です。SNS トピックは、セキュリティを強化するために保管時に暗号化する必要があります。詳細については、https://docs.aws.amazon.com/sns/latest/dg/sns-server-side-encryption.html の「保管時の暗号化Amazon Simple Notification Service 開発者ガイド」を参照してください。

Remediation

暗号化されていない SNS トピックを暗号化するには

  1. Amazon SNS コンソール (https://console.aws.amazon.com/sns/v3/home) を開きます。

  2. ナビゲーションペインで、[トピック.] を選択します。

  3. 暗号化するトピックの名前を選択します。

  4. Edit.] を選択します。

  5. [Encryption] で、[Enable Encryption] を選択します。

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

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

[SSM.1] EC2 インスタンスは AWS Systems Manager によって管理される必要があります

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

重大度:

リソース: EC2 インスタンス

AWS Config ルール: ec2-instance-managed-by-systems-manager

パラメータ: なし

このコントロールは、アカウントの EC2 インスタンスが AWS Systems Manager によって管理されているかどうかをチェックします。Systems Manager は、AWS インフラストラクチャの表示と制御に使用できる AWS のサービスです。

セキュリティとコンプライアンスを維持するために、Systems Manager はマネージドインスタンスをスキャンします。マネージドインスタンスは、Systems Manager で使用するように設定されているマシンです。Systems Manager は、検出されたポリシー違反に対してレポートまたは修正アクションを実行します。Systems Manager は、マネージドインスタンスの設定と保守にも役立ちます。

詳細については、次を参照してください。AWS Systems Manager ユーザーガイド.

Remediation

コンソールを使用して、この問題を修正できます。Systems Manager

EC2 インスタンスが に管理されるようにするにはSystems Manager

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

  2. Quick setup (クイック設定).] を選択します。

  3. 設定画面で、デフォルトのオプションをそのまま使用します。

  4. Enable.] を選択します。

インスタンスが Systems Manager 関連付けをサポートしているかどうかを判断するには、 の「Systems Manager の前提条件」を参照してください。AWS Systems Manager ユーザーガイド

[SSM.2] Systems Manager によって管理されるすべての EC2 インスタンスは、パッチ適用要件に準拠している必要があります。

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

重大度:

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

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

パラメータ: なし

このコントロールは、インスタンスのパッチインストール実行後、Amazon EC2 Systems Manager パッチコンプライアンスのコンプライアンスステータスが COMPLIANTNON_COMPLIANT のどちらかを確認します。Systems Manager パッチマネージャーによって管理されているインスタンスのみがチェックされます。

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

注記

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

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

  • ヨーロッパ (ミラノ)

  • 中東 (バーレーン)

Remediation

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

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

  2. Instances & Nodes (インスタンスとノード)] で、[Run Command (コマンドを実行)] を選択し、[Run command (コマンドを実行)]. を選択します。

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

  4. Operation (オペレーション)] を [Install (インストール).] に変更します。

  5. [Choose instances manually (インスタンスを手動で選択)] を選択し、非準拠のインスタンスを選択します。

  6. ページの最下部で [Run (実行).] を選択します。

  7. コマンドが完了したら、パッチを適用したインスタンスの新しいコンプライアンスステータスをモニタリングするには、ナビゲーションペインで [Compliance (コンプライアンス).] を選択します。

ドキュメントを使用してマネージドインスタンスにパッチを適用する方法の詳細については、Systems Manager の「インスタンスにパッチを適用するための SSM ドキュメントについて」と「 Run command を使用したコマンドの実行Systems Manager」を参照してください。AWS Systems Manager ユーザーガイド

[SSM.3] Systems Manager によって管理されるインスタンスは、関連付けコンプライアンスのステータスが COMPLIANT である必要があります。

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

重大度:

リソース: AwsSSMAssociationCompliance

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

パラメータ: なし

このコントロールは、関連付けがインスタンスで実行された後、AWS Systems Manager 関連付けコンプライアンスのステータスが COMPLIANT または NON_COMPLIANT であるかを確認します。関連付けのコンプライアンスステータスが COMPLIANT の場合、コントロールは進みます。

ステートマネージャーの関連付けは、マネージドインスタンスに割り当てられる設定です。この設定では、インスタンスで管理する状態を定義します。たとえば、関連付けでは、アンチウイルスソフトウェアをインスタンスにインストールして実行する必要があること、または特定のポートを閉じる必要があることを指定できます。

1 つ以上のステートマネージャーの関連付けを作成すると、コンプライアンスステータス情報がすぐに利用可能になります。コンプライアンスステータスは、コンソールで表示したり、AWS CLI コマンドまたは対応する Systems Manager API アクションに応答して表示したりできます。関連付けの場合、設定コンプライアンスにはコンプライアンスステータス (Compliant または Non-compliant) が表示されます。また、関連付けに割り当てられた重大度 (CriticalMedium など) も表示されます。

ステートマネージャーの関連付けのコンプライアンスの詳細については、https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-compliance-about.html#sysman-compliance-about-association の「ステートマネージャーの関連付けのコンプライアンスについてAWS Systems Manager ユーザーガイド」を参照してください。

注記

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

Remediation

失敗した関連付けは、ターゲットや SSM ドキュメント名など、さまざまなモノに関連している可能性があります。この問題を修正するには、まず関連付けを特定して調査する必要があります。その後、関連付けを更新して特定の問題を修正できます。

関連付けを編集して新しい名前、スケジュール、重要度レベル、またはターゲットを指定できます。関連付けを編集した後、AWS Systems Manager で新しいバージョンが作成されます。

失敗した関連付けを調査して更新するには

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

  2. ナビゲーションペインの [Instances & Nodes] で、[Managed Instances] を選択します。

  3. [関連付けのステータス] が [失敗] であるインスタンス ID を選択します。

  4. View details.] を選択します。

  5. [Associations (関連付け)] を選択します。

  6. [関連付けのステータス] が [失敗] になっている関連付けの名前を書き留めます。これは調査する必要がある関連付けです。次のステップでは、関連付けの名前を使用する必要があります。

  7. ナビゲーションペインの [Instances & Nodes] で、[State Manager] を選択します。関連付けの名前を検索し、関連付けを選択します。

  8. 問題を特定したら、失敗した関連付けを編集して問題を解決します。関連付けを編集する方法については、「関連付けを編集する」を参照してください。

ステートマネージャーの関連付けの作成と編集の詳細については、https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-associations.html の「Systems Manager での関連付けの使用AWS Systems Manager ユーザーガイド」を参照してください。