PCI DSS コントロール - AWS Security Hub
[PCI.AutoScaling.1] ロードバランサーに関連付けられた Auto Scaling グループはヘルスチェックを使用する必要がある[PCI.CloudTrail.1] CloudTrail ログは、保管中に AWS KMS keys を使用して暗号化する必要がある[PCI.CloudTrail.2] CloudTrail を有効にする必要がある[PCI.CloudTrail.3] CloudTrail ログファイルの検証を有効にする必要がある[PCI.CloudTrail.4] CloudTrail 追跡は CloudWatch Logs と統合する必要がある[PCI.CodeBuild.1] CodeBuild GitHub または Bitbucket のソースリポジトリの URL は、OAuth を使用する必要がある[PCI.CodeBuild.2] CodeBuild プロジェクト環境変数にクリアテキストの認証情報を含めるべきではない[PCI.Config.1] AWS Config を有効にする必要がある[PCI.CW.1]「ルート」ユーザーの使用に対するログメトリクスフィルターとアラームが存在する必要がある[PCI.DMS.1] AWS Database Migration Service レプリケーションインスタンスはパブリックではない必要がある[PCI.EC2.1] Amazon EBS スナップショットをパブリックに復元できない[PCI.EC2.2] VPC のデフォルトのセキュリティグループで、インバウンドトラフィックとアウトバウンドトラフィックを禁止する必要がある[PCI.EC2.3] 未使用の EC2 セキュリティグループを削除する必要がある (使用停止)[PCI.EC2.4] 未使用の EC2 EIP を削除する必要がある[PCI.EC2.5] どのセキュリティグループでも 0.0.0.0/0 からポート 22 への入力を許可していない必要がある[PCI.EC2.6] すべての VPC で VPC フローログ記録を有効にする必要がある[PCI.ELBV2.1] Application Load Balancer は、すべての HTTP リクエストを HTTPS にリダイレクトするように設定する必要がある[PCI.ES.1] Elasticsearch ドメインは VPC 内に存在する必要がある[PCI.ES.2] Elasticsearch ドメインで保管中の暗号化を有効にする必要がある[PCI.GuardDuty.1] GuardDuty を有効にする必要がある[PCI.IAM.1] IAM ルートユーザーのアクセスキーが存在していてはならない[PCI.IAM.2] IAM ユーザーには IAM ポリシーを添付してはならない[PCI.IAM.3] IAM ポリシーで、完全な「*」管理者権限を許可してはならない[PCI.IAM.4] ルートユーザーに対してハードウェア MFA を有効にする必要がある[PCI.IAM.5] ルートユーザーに対して仮想 MFA を有効にする必要がある[PCI.IAM.6] すべての IAM ユーザーに対して MFA を有効にする必要がある[PCI.IAM.7] IAM ユーザー認証情報が事前定義された日数以内に使用されない場合、認証情報を無効にする必要がある[PCI.IAM.8] IAM ユーザーのパスワードポリシーには強力な設定が必要である[PCI.KMS.1] KMS キーのローテーションを有効にする必要がある[PCI.Lambda.1] Lambda 関数は、パブリックアクセスを禁止する必要がある[PCI.Lambda.2] Lambda 関数は VPC 内に存在する必要がある[PCI.OpenSearch.1] Amazon OpenSearch Service ドメインは VPC 内に存在している必要がある[PCI.OpenSearch.2] OpenSearch ドメインは保管中の暗号化を有効にする必要がある[PCI.RDS.1] Amazon RDS スナップショットでパブリックアクセスを禁止する必要があります[PCI.RDS.2] Amazon RDS DB インスタンスでは、パブリックアクセスを禁止する必要があります。これは、PubliclyAccessible 設定により判断されます[PCI.Redshift.1] Amazon Redshift クラスターはパブリックアクセスを禁止する必要がある[PCI.S3.1] S3 バケットはパブリック書き込みアクセスを禁止する必要がある[PCI.S3.2] S3 バケットではパブリック読み取りアクセスを禁止する必要がある[PCI.S3.3] S3 バケットでクロスリージョンレプリケーションを有効にする必要がある[PCI.S3.4] S3 バケットでは、サーバー側の暗号化を有効にする必要がある[PCI.S3.5] S3 バケットは Secure Socket Layer を使用するリクエストを要求する必要がある[PCI.S3.6] S3 パブリックアクセスブロック設定を有効にする必要がある[PCI.SageMaker.1] Amazon SageMaker ノートブックインスタンスは、インターネットに直接アクセスできないようにする必要がある[PCI.SSM.1] Systems Manager によって管理される Amazon EC2 インスタンスは、パッチのインストール後に、パッチコンプライアンスのステータスが COMPLIANT である必要がある[PCI.SSM.2] Systems Manager によって管理されるインスタンスの関連付けコンプライアンスのステータスは COMPLIANT である必要がある[PCI.SSM.3] EC2 インスタンスは AWS Systems Manager により管理される必要がある

PCI DSS コントロール

Security Hub の PCI DSS では、次のコントロールがサポートされています。各コントロールについて、重要度、リソースタイプ、AWS Config ルール、修正ステップの情報が含まれます。

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

重要度:

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

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

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

パラメータ: なし

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

PCI DSS では、ロードバランシングや高可用性の設定は必要ではありません。ただし、このチェックは AWS のベストプラクティスと一致するものです。

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 2.2: すべてのシステムコンポーネントについて、設定基準を作成する。この基準は、すべての既知のセキュリティ脆弱性に対処し、業界で受け入れられているシステム強化基準に準拠するものである必要がある。

ロードバランシングを使用してシステムを複製すると、高可用性を実現でき、DDoS イベントの影響を軽減できます。

これは、システム強化設定の実装に使用される方法の 1 つです。

修正

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

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

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

  3. リストからグループを選択するには、右側のボックスを選択します。

  4. [Actions] (アクション) で、[Edit] (編集) を選択します。

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

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

  7. [Save] (保存) を選択します。

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

[PCI.CloudTrail.1] CloudTrail ログは、保管中に AWS KMS keys を使用して暗号化する必要がある

重要度:

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

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

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

パラメータ: なし

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

デフォルトの暗号化オプションのみを使用している場合は、このチェックを無効にすることができます。

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 3.4: プライマリアカウント番号 (PAN) を、すべての保存場所で読み取り不能にする (ポータブルデジタルメディア、バックアップメディア、およびログ内を含む)。

AWS サービスを使用して PAN の処理と保存を行っている場合、CloudTrail ログを保管中に暗号化する必要があります。ログを暗号化すると、ログが PAN をキャプチャした場合でも PAN が保護されます。

デフォルトでは、CloudTrail によって S3 バケットに配信されるログファイルは、Amazon S3 が管理する暗号化キー (SSE-S3) による Amazon サーバー側の暗号化を使用して暗号化されます。「Amazon Simple Storage Service ユーザーガイド」を参照してください。

カスタマーマネージドキーを活用して CloudTrail ログの保護をさらに強化するように CloudTrail ログを設定できます。

これらは、PAN を読み取り不能にするための方法です。

修正

この問題を修正するには、CloudTrail ログファイルの暗号化を有効にします。

AWS KMS マネージドキー (SSE-KMS) で CloudTrail ログファイルを暗号化する方法の詳細については、「AWS CloudTrail ユーザーガイド」の「AWS KMS マネージドキー (SSE-KMS) による CloudTrail ログファイルの暗号化」を参照してください。

[PCI.CloudTrail.2] CloudTrail を有効にする必要がある

重要度:

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

AWS Config ルール : cloudtrail-enabled

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

パラメータ: なし

このコントロールは、お使いの AWS アカウントで CloudTrail が有効になっているかどうかを確認します。

ただし、一部の AWS サービスでは、すべての API およびイベントのログ記録を有効にすることができません。CloudTrail 以外の監査追跡を追加で実装し、「CloudTrail のサポートされているサービスと統合」内の各サービスのドキュメントを確認してください。

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 10.1: システムコンポーネントへのすべてのアクセスを個々のユーザーにリンクする監査追跡を実装する。

CloudTrail を有効にすると、イベント履歴によって、個々のユーザーによるシステムコンポーネントへのアクセスに対する 90 日間のイベントおよび監査追跡を容易に入手できるようになります。

ユーザーのアイデンティティは、CloudTrail ログの eventSource セクションで確認できます。

PCI DSS 10.2.1: すべてのシステムコンポーネントの自動監査追跡を実装して、次のイベントを再現する: 個々のすべてのユーザーによるカード所有者データへのアクセス

カード所有者データが保存されている場所に応じて、個々のユーザーによるカード所有者データへのアクセスは、CloudTrail ログの userIdentityeventSourceeventName、または responseElements セクションに記載されています。

PCI DSS 10.2.2: すべてのシステムコンポーネントの自動監査追跡を実装して、次のイベントを再現する: ルート権限または管理者権限を持つすべての個人が実行したすべてのアクション

ルートユーザーの ID は、ログの userIdentity セクションを参照してください。

PCI DSS 10.2.3: すべてのシステムコンポーネントの自動監査追跡を実装して、次のイベントを再現する: すべての監査追跡へのアクセス

監査追跡へのアクセスは、ログの eventSourceeventName、または responseElements セクションを参照してください。

PCI DSS 10.2.4: すべてのシステムコンポーネントの自動監査追跡を実装して、次のイベントを再現する: 無効な論理アクセスの試行

無効な論理アクセスの試行は CloudTrail ログを参照してください。例: responseElements : "ConsoleLogin" および responseElements : "Failure"

PCI DSS 10.2.5: すべてのシステムコンポーネントの自動監査追跡を実装して、次のイベントを再現する: 識別と認証メカニズムの使用および変更 (新規アカウントの作成や特権の昇格を含む、ただしこれに限定されない)、およびルート権限または管理者権限を持つアカウントの変更、追加、削除のすべて

識別と認証メカニズムの使用および変更については、ログの userAgenteventName、または responseElements セクションを参照してください。

PCI DSS 10.2.6: すべてのシステムコンポーネントの自動監査追跡を実装して、次のイベントを再現する: 監査ログの初期化、停止、または一時停止

ログの開始と停止が CloudTrail ログにキャプチャされます。

監査ログの起動と停止の例は、CloudTrail ログ内で次のように表示されます: eventName : "StopLogging" および eventName : "StartLogging"

PCI DSS 10.2.7: すべてのシステムコンポーネントの自動監査追跡を実装して、次のイベントを再現する: システムレベルオブジェクトの作成と削除

システムレベルオブジェクトの作成と削除は、CloudTrail ログにキャプチャされます。システムレベルオブジェクトの例は AWS Lambda 関数です。

AWS Lambda 開発者ガイド」に説明されているとおり、CloudTrail は createFunction および deleteFunction API コールをキャプチャします。

PCI DSS 10.3.1: イベントごとに、すべてのシステムコンポーネントについて少なくとも以下の監査追跡エントリを記録する: ユーザー ID

ユーザー ID は、CloudTrail ログの userIdentity セクションで確認できます。

PCI DSS 10.3.2: イベントごとに、すべてのシステムコンポーネントについて少なくとも以下の監査追跡エントリを記録する: イベントのタイプ

イベントのタイプは、CloudTrail ログの eventName セクションで確認できます。

PCI DSS 10.3.3: イベントごとに、すべてのシステムコンポーネントについて少なくとも以下の監査追跡エントリを記録する: 日付と時刻

イベントの日時は、CloudTrail ログの eventTime セクションで確認できます。

PCI DSS 10.3.4: イベントごとに、すべてのシステムコンポーネントについて少なくとも以下の監査追跡エントリを記録する: 成功または失敗を示す情報

成功または失敗を示す情報は、CloudTrail ログの responseElements セクションで確認できます。

PCI DSS 10.3.5: イベントごとに、すべてのシステムコンポーネントについて少なくとも以下の監査追跡エントリを記録する: イベントの発生元

イベントの発生元は、CloudTrail ログの userAgent または sourceIPAddress セクションで確認できます。

PCI DSS 10.3.6: イベントごとに、すべてのシステムコンポーネントについて少なくとも以下の監査追跡エントリを記録する: 影響を受けるデータ、システムコンポーネント、またはリソースの ID または名前。

リソースのアイデンティティは、CloudTrail ログの eventSource セクションで確認できます。

修正

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

  1. CloudTrail 管理用に設定した IAM ユーザーを使用して AWS Management Console にサインインします。

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

  3. [Region] (リージョン) セレクタで、追跡を作成する AWS リージョンを選択します。これは、追跡のホームリージョンです。

    追跡がすべての AWS リージョンのイベントを記録している場合でも、ホームリージョンは追跡の作成後に追跡を表示および更新できる唯一の AWS リージョンです。

  4. ナビゲーションペインで、[Trails] (追跡) を選択します。

  5. [Trails] (追跡) ページで、[Get Started Now] (今すぐ開始) を選択します。このオプションが表示されない場合は、[Create Trail] (追跡の作成) を選択します。

  6. [Trail name] (追跡名) で、追跡に名前を付けます (My-Management-Events-Trail など)。

    追跡の目的をすぐに識別できる名前を使用するのがベストプラクティスです。この例では、管理イベントをログに記録する追跡を作成しています。

  7. [Management Events] (管理イベント) で、[Read/Write events] (読み取り/書き込みイベント) が [All] (すべて) に設定されていることを確認します。

  8. [Data Events] (データイベント) では、何も変更しないでください。この追跡はデータイベントを記録しません。

  9. ログ用の新しい S3 バケットを作成します。

    1. [Storage Location] (保存場所) の [Create a new S3 bucket] (新しい S3 バケットを作成する) で、[Yes] (はい) を選択します。

    2. [S3 bucket] (S3 バケット) で、バケットに名前を付けます (my-bucket-for-storing-cloudtrail-logs など)。

      S3 バケットの名前はグローバルで一意である必要があります。S3 バケットの命名要件の詳細については、「AWS CloudTrail ユーザーガイド」を参照してください。

    3. [Advanced] (詳細) で、[Encrypt log files with SSE-KMS] (SSE-KMS でログファイルを暗号化する) および [Enable log file validation] (ログファイルの検証の有効化) の両方で [Yes] (はい) を選択します。

  10. [Create] (作成) を選択します。

詳細については、「AWS CloudTrail ユーザーガイド」のチュートリアルを参照してください。

[PCI.CloudTrail.3] CloudTrail ログファイルの検証を有効にする必要がある

重要度:

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

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

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

パラメータ: なし

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

設定が変更されたときはチェックしません。

ログファイルの変更をモニタリングして警告するには、Amazon EventBridge または CloudWatch メトリクスフィルターを使用します。

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 10.5.2: 監査追跡ファイルを不正な変更から保護する。

CloudTrail ログファイルの検証により、CloudTrail が Amazon S3 に書き込むそれぞれのログのハッシュを含むデジタル署名されたダイジェストファイルが作成されます。

これらのダイジェストファイルを使用して、CloudTrail がログを配信した後でログファイルが変更、削除、または変更されなかったかどうかを判断できます。

これは、不正な変更から監査追跡ファイルを保護するのに役立つ方法です。

PCI DSS 10.5.5: ログに対してファイル整合性モニタリングソフトウェアまたは変更検出ソフトウェアを使用して、警告を生成せずに既存のログデータを変更できないようにする。

CloudTrail ログファイルの検証により、CloudTrail が Amazon S3 に書き込むそれぞれのログのハッシュを含むデジタル署名されたダイジェストファイルが作成されます。

これらのダイジェストファイルを使用して、CloudTrail がログを配信した後でログファイルが変更、削除、または変更されなかったかどうかを判断できます。

これは、ログに対してファイル整合性モニタリングソフトウェアまたは変更検出ソフトウェアが使用されることを確認するための方法です。

修正

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

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

  2. [Trails] (追跡) を選択します。

  3. [Name] (名前) 列で、編集する追跡の名前を選択します。

  4. [General details] (一般的な詳細) で、[Edit] (編集) を選択します。

  5. [Additional settings] (追加設定) の [Log file validation] (ログファイルの検証) で、[Enabled] (有効) を選択します。

  6. [Save] (保存) を選択します。

[PCI.CloudTrail.4] CloudTrail 追跡は CloudWatch Logs と統合する必要がある

重要度:

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

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

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

パラメータ: なし

このコントロールは、CloudWatch Logs にログを送信するように CloudTrail 追跡が設定されているかどうかをチェックします。

ログやロググループを変更するためのユーザー許可はチェックされません。CloudTrail ログが変更されたときに警告する、特定の CloudWatch ルールを作成する必要があります。

このコントロールは、CloudTrail 以外の追加の監査ログソースが CloudWatch Logs グループに送信されているかどうかもチェックしません。

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 10.5.3: 監査追跡ファイルは、変更が難しい一元管理されたログサーバーまたはメディアに直ちにバックアップする。

CloudTrail はログファイルの保存と配信に Amazon S3 を使用するため、ログファイルは永続的に保存されます。

CloudWatch Logs ログは、監査追跡ファイルを迅速にバックアップするためのネイティブな方法です。

修正

CloudTrail 追跡が CloudWatch Logs に統合されていることを確認するには

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

  2. [Trails] (追跡) を選択します。

  3. [CloudWatch Logs Log group] (CloudWatch Logs ロググループ) 列に値のない追跡を選択します。

  4. CloudWatch Logs セクションまで下にスクロールし、[Edit] (編集) を選択します。

  5. [Log group] (ロググループ) フィールドで、次のいずれかの操作を行います。

    • デフォルトのロググループを使用するには、名前を変更しないでください。

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

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

  6. [Continue] (続行) を選択します。

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

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

    • 新しいロールを作成する場合は、[New] (新規) を選択し、作成するロールの名前を入力します。

      新しいロールには、必要な許可を付与するポリシーが割り当てられます。

    ロールに付与された許可を表示するには、[Policy document] (ポリシードキュメント) を展開します。

  8. [Save changes] (変更の保存) を選択します。

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

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

重要度: 非常事態

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

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

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

パラメータ: なし

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

注記

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

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

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

  • ヨーロッパ (ミラノ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 8.2.1: 強力な暗号化を使用して、すべてのシステムコンポーネントで、転送および保存中にすべての認証情報 (パスワード/フレーズなど) を読み取り不能にする。

PCI DSS 環境で CodeBuild を使用して、ソースコードをコンパイルしたり、ユニットテストを実行したり、すぐにデプロイ可能なアーティファクトを生成したりできます。実行する場合、認証情報をクリアテキストで保存または送信したり、リポジトリ URL に表示してはなりません。

GitHub または Bitbucket リポジトリにアクセスする認可を付与するには、個人のアクセストークンやユーザー名とパスワードではなく、OAuth を使用する必要があります。これは、強力な暗号化を使用して、認証情報を読み取り不能にする方法です。

修正

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

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

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

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

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

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

  6. ソースプロバイダーによって表示されるメッセージに応じて、適切に認証します。

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

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

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

[PCI.CodeBuild.2] CodeBuild プロジェクト環境変数にクリアテキストの認証情報を含めるべきではない

重要度: 非常事態

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

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

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

パラメータ: なし

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

注記

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

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

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

  • ヨーロッパ (ミラノ)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 8.2.1: 強力な暗号化を使用して、すべてのシステムコンポーネントで、転送および保存中にすべての認証情報 (パスワード/フレーズなど) を読み取り不能にする。

PCI DSS 環境で CodeBuild を使用して、ソースコードをコンパイルしたり、ユニットテストを実行したり、すぐにデプロイ可能なアーティファクトを生成したりできます。実行する場合、認証情報 AWS_ACCESS_KEY_ID および AWS_SECRET_ACCESS_KEY をクリアテキストで保存してはなりません。

環境変数を使用して CodeBuild プロジェクトに認証情報を保存すると、強力な暗号化を使用して認証情報を読み取り不能にするという要件に違反する可能性があります。

修正

環境変数を使用して CodeBuild の実行時に機密データを参照するには、次の手順を使用します。

環境変数を削除するには

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

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

  3. [Edit] (編集) から [Environment] (環境) を選択します。

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

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

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

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

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

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

  3. [Edit] (編集) から [Environment] (環境) を選択します。

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

  5. AWS Systems Manager で、機密データを含む Systems Manager パラメータを作成します。これを行う方法については、「AWS Systems Manager ユーザーガイド」のチュートリアルを参照してください。

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

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

  8. [name] (名前) には、ビルド仕様に表示される変数の名前を入力します。

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

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

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

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

AWS CodeBuild ユーザーガイド」のビルド環境の環境変数に関する情報を参照してください。

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

重要度:

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

AWS Config ルール: なし。このチェックを実行するために、Security Hub は「アマゾン ウェブ サービスのセキュリティ保護」に規定された監査ステップを実行します。AWS 環境では、このチェック用の AWS Config マネージドルールは作成されません。

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

パラメータ: なし

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

AWS Config はリソースタイプのサブセットのみをサポートするため、すべての重要なシステムファイルとコンテンツファイルの変更検出がチェックされるわけではありません。

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

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

注記

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

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

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

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 10.5.2: 監査追跡ファイルを不正な変更から保護する。

AWS Config は、AWS リソース設定における必要な設定について継続的にモニタリング、追跡、評価し、6 時間ごとに設定変更履歴ファイルを生成します。

不正な変更から監査追跡ファイルを保護するために、AWS Config を有効にする必要があります。

PCI DSS 11.5: 変更検出メカニズムをデプロイすることにより、重要なシステムファイル、設定ファイル、またはコンテンツファイルの不正な変更を担当者に警告し、重要なファイルの比較を少なくとも週に 1 回実行するようにソフトウェアを設定する。

AWS Config は、AWS リソース設定における必要な設定について継続的にモニタリング、追跡、評価し、6 時間ごとに設定変更履歴ファイルを生成します。

AWS Config を有効にして、変更検出メカニズムがデプロイされ、重要なファイルの比較を少なくとも週に 1 回実行するように設定する必要があります。

修正

AWS Config 設定を構成するには

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

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

  3. AWS Config をこれまでに使用したことがない場合は、「AWS Config デベロッパーガイド」の「使用の開始」を参照してください。

  4. メニューから [Settings] (設定) ページに進み、次を実行します。

    • [Edit] を選択します。

    • [Resource types to record] (記録するリソースタイプ) で、[Record all resources supported in this region] (このリージョンでサポートされているすべてのリソースを記録します) および [Include global resources (e.g., AWS IAM resources)] (グローバルリソースを含める(例: IAM リソース)) を選択します。

    • [Data retention period] (データ保持期間) で、AWS Config データのデフォルトの保持期間を選択するか、個別に保持期間を指定します。

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

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

    • [Amazon SNS topic] (Amazon SNS トピック) で、アカウントから Amazon SNS トピックを選択するか、トピックを作成します。Amazon SNS の詳細については、「Amazon Simple Notification Service の使用開始ガイド」を参照してください。

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

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

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

[PCI.CW.1]「ルート」ユーザーの使用に対するログメトリクスフィルターとアラームが存在する必要がある

重要度: 非常事態

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

AWS Config ルール: なし。Security Hub は、AWS アカウントにこのチェック用の AWS Config マネージドルールを作成せずに、監査ステップを実行します。

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

パラメータ : なし

このコントロールは、次のパターンを使用して CloudWatch メトリクスフィルターをチェックします。

{ $.userIdentity.type = "Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }

次の項目がチェックされます。

  • ロググループ名は、アクティブなマルチリージョン CloudTrail で使用するように設定されている。

  • IncludeManagementEventstrue に設定され、ReadWriteTypeAll に設定されている追跡には、少なくとも 1 つのイベントセレクタがある。

  • アラームに関連付けられた Amazon SNS トピックに対するアクティブな受信者が少なくとも 1 つ存在する。

注記

Security Hub がこのコントロールのチェックを実行すると、現在のアカウントが使用する CloudTrail 追跡が検索されます。これらの追跡は、別のアカウントに属する組織の追跡である可能性があります。マルチリージョンの追跡は、別のリージョンに基づいている可能性もあります。

チェックの結果、以下の場合は結果 FAILED となります。

  • 追跡が設定されていません。

  • 現在のリージョンにあり、現在のアカウントが所有している利用可能な追跡が、コントロール要件を満たしていません。

チェックの結果、以下の場合はコントロール状況が NO_DATA になります。

  • マルチリージョンの追跡が別のリージョンに基づいています。Security Hub は、追跡が基づいているリージョンでのみ結果を生成できます。

  • マルチリージョンの追跡が別のアカウントに属しています。Security Hub は、追跡を所有するアカウントの結果のみを生成できます。

アラームの場合、現在のアカウントは、参照されている Amazon SNS トピックを所有しているか、ListSubscriptionsByTopic を呼び出すことで Amazon SNS トピックにアクセスできる必要があります。それ以外の場合は、Security Hub はコントロールに対して結果 WARNING を生成します。

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 7.2.1: システムコンポーネントのアクセス制御システムを確立することにより、ユーザーの必要性に基づいてアクセスを制限し、明示的に許可していない限り「すべて拒否」に設定する。このアクセス制御システムは、すべてのシステムコンポーネントを対象に含んでいる必要がある。

ルートユーザーは AWS アカウントで最も権限のあるユーザーで、AWS アカウントのすべてのリソースに対して無制限にアクセスできます。

AWS アカウント ルートユーザー認証情報の使用に対して、ログメトリクスフィルターとアラームを設定する必要があります。

また、ルート権限または管理者権限を持つ個人が実行したアクションの監査追跡を保持するために、CloudTrail が有効化されていることを確認する必要もあります (「[PCI.CloudTrail.2] CloudTrail を有効にする必要がある」を参照)。ルートユーザーの ID は、CloudTrail ログの userIdentity セクションに記載されています。

修正

この問題を修正するためのステップには、Amazon SNS トピック、メトリクスフィルター、およびメトリクスフィルターのアラームの設定が含まれます。

これらは、3.3 - ルートユーザーに使用するログメトリクスフィルターとアラームが存在することを確認する の結果を修正するためのステップと同じです。

Amazon SNS トピックを作成するには

  1. Amazon SNS コンソール (https://console.aws.amazon.com/sns/v3/home) を開きます。

  2. すべての CIS アラームを受信する Amazon SNS トピックを作成します。

    トピックに少なくとも 1 人の受信者を作成します。

    Amazon SNS トピックの作成の詳細については、「Amazon Simple Notification Service 開発者ガイド」を参照してください。

  3. すべてのリージョンに適用されるアクティブな CloudTrail 追跡を設定します。

    これを行うには、2.1 - CloudTrail がすべてのリージョンで有効であることを確認する の修正ステップに従います。

    関連するロググループ名を書きとめておきます。

メトリクスフィルターとアラームを作成するには

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

  2. [Logs] (ログ) を選択し、[Log groups] (ロググループ) を選択します。

  3. CloudTrail がログ記録されているロググループを選択します。

  4. ロググループの詳細ページで、[Metric filters] (メトリクスフィルター) を選択します。

  5. [Create metric filter] (メトリクスフィルターの作成) を選択します。

  6. 次のパターンをコピーして、[Filter Pattern] (フィルターパターン) に貼り付けます。

    {$.userIdentity.type="Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType !="AwsServiceEvent"}
  7. [Next] を選択します。

  8. 新しいフィルターの名前を入力します。例えば、RootAccountUsage です。

  9. [Metric Namespace] (メトリクスの名前空間) の値が LogMetrics であることを確認します。

    これにより、すべての CIS Benchmark メトリクスがグループ化されます。

  10. [Metric name] (メトリクス名) に、メトリクスの名前を入力します。

  11. [Metric value] (メトリクス値) に 1 と入力し、[Next] (次へ) を選択します。

  12. [Create metric filter] (メトリクスフィルターの作成) を選択します。

  13. 次に、通知を設定します。作成したメトリクスフィルターを選択し、[Create alarm] (アラームの作成) を選択します。

  14. アラームのしきい値を入力し (例えば 1)、[Next] (次へ) を選択します。

  15. [Select an SNS topic] (SNS トピックの選択) の [Send notification to] (通知の送信先) で、E メールリストを選択し、[Next] (次へ) を選択します。

  16. アラームの [Name] (名前) と [Description] (説明) (RootAccountUsageAlarm など) を入力し、[Next] (次へ) を選択します。

  17. [Create alarm] (アラームの作成) を選択します。

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

重要度: 非常事態

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

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

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

パラメータ : なし

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

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

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

注記

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

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

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

  • ヨーロッパ (ミラノ)

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 1.2.1 - インバウンドおよびアウトバウンドトラフィックを、カード所有者データ環境 (CDE) に必要なトラフィックに制限し、それ以外のトラフィックを明確に拒否する。

お客様の定義済み CDE で AWS DMS を使用する場合、レプリケーションインスタンスの PubliclyAccessible フィールドを 'false' に設定します。レプリケーションインスタンスにパブリックアクセスを許可すると、CDE との間で必要なトラフィックのみを許可するという要件に違反する場合があります。

PCI DSS 1.3.1 - DMZ を実装して、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限する。

お客様の定義済み CDE で AWS DMS を使用する場合、レプリケーションインスタンスの PubliclyAccessible フィールドを 'false' に設定します。レプリケーションインスタンスにパブリックアクセスを許可すると、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限するという要件に違反する可能性があります。

PCI DSS 1.3.2 - インバウンドインターネットトラフィックを DMZ 内の IP アドレスに制限する。

お客様の定義済み CDE で AWS DMS を使用する場合、レプリケーションインスタンスの PubliclyAccessible フィールドを 'false' に設定します。レプリケーションインスタンスにパブリックアクセスを許可すると、インバウンドトラフィックを DMZ 内の IP アドレスに制限するという要件に違反する可能性があります。

PCI DSS 1.3.4 - カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックを許可しない。

お客様の定義済み CDE で AWS DMS を使用する場合、レプリケーションインスタンスの PubliclyAccessible フィールドを 'false' に設定します。レプリケーションインスタンスにパブリックアクセスを許可すると、カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックをブロックするという要件に違反する可能性があります。

PCI DSS 1.3.6: カード所有者データを保存するシステムコンポーネント (データベースなど) は、DMZ やその他の信頼できないネットワークから分離された内部ネットワークゾーンに配置する。

お客様の定義済み CDE で AWS DMS を使用する場合、カード所有者データを保存するデータベースを移行するには、レプリケーションインスタンスの PubliclyAccessible フィールドを 'false' に設定します。レプリケーションインスタンスにパブリックアクセスを許可すると、カード所有者データを保存するシステムコンポーネントを、DMZ やその他の信頼できないネットワークから分離された内部ネットワークゾーンに配置するという要件に違反する可能性があります。

修正

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

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

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

  2. 左のナビゲーションペインの [Resource management] (リソース管理) で、[Replication instances] (レプリケーションインスタンス) へ移動します。

  3. パブリックインスタンスを削除するには、インスタンスのチェックボックスを選択し、[Actions] (アクション)、[delete] (削除) の順に選択します。

  4. [Create replication instance] (レプリケーションインスタンスの作成) を選択します。設定の詳細を入力します。

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

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

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

[PCI.EC2.1] Amazon EBS スナップショットをパブリックに復元できない

重要度: 非常事態

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

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

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

パラメータ : なし

このコントロールは、Amazon Elastic Block Store スナップショットが誰でもパブリックに復元可能でないかどうかをチェックします。会社の機密データが誤って漏洩することを避けるために、Amazon EBS スナップショットは明示的な許可がない限り、誰であってもパブリックに復元できるべきではありません。

また、Amazon EBS 設定を変更する許可が、承認された AWS アカウントのみに制限されていることを確認する必要もあります。Amazon EBS スナップショットの許可の管理の詳細については、「Linux インスタンス用 Amazon EC2 ユーザーガイド」を参照してください。

注記

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

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

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

  • ヨーロッパ (ミラノ)

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 1.2.1: インバウンドおよびアウトバウンドトラフィックを、カード所有者データ環境 (CDE) に必要なトラフィックに制限し、それ以外のトラフィックを明確に拒否する。

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

Amazon EBS スナップショットにカード所有者データが保存されている場合、いかなるユーザーもそれをパブリックに復元できるべきではありません。許可すると、CDE との間で必要なトラフィックのみを許可するという要件に違反する場合があります。

PCI DSS 1.3.1: DMZ を実装して、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限する。

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

Amazon EBS スナップショットにカード所有者データが保存されている場合、いかなるユーザーもそれをパブリックに復元できるべきではありません。許可すると、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限するという要件に違反する可能性があります。

PCI DSS 1.3.4: カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックを許可しない。

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

Amazon EBS スナップショットにカード所有者データが保存されている場合、いかなるユーザーもそれをパブリックに復元できるべきではありません。許可すると、カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックをブロックするという要件に違反する可能性があります。

PCI DSS 7.2.1: システムコンポーネントのアクセス制御システムを確立することにより、ユーザーの必要性に基づいてアクセスを制限し、明示的に許可していない限り「すべて拒否」に設定する。このアクセス制御システムは、すべてのシステムコンポーネントを対象に含んでいる必要がある。

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

Amazon EBS スナップショットにカード所有者データが保存されている場合、いかなるユーザーもそれをパブリックに復元できるべきではありません。許可すると、システムコンポーネントへのアクセスを必要な最小特権に、またはユーザーの必要性に基づいて制限するという要件に違反する可能性があります。

修正

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

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

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

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

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

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

  6. [Save] (保存) を選択します。

Amazon EBS スナップショットの共有に関する詳細については、「Linux インスタンス用 Amazon EC2 ユーザーガイド」を参照してください。

[PCI.EC2.2] VPC のデフォルトのセキュリティグループで、インバウンドトラフィックとアウトバウンドトラフィックを禁止する必要がある

重要度:

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

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

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

パラメータ : なし

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

デフォルトではない他のセキュリティグループに対するアクセス制限や、他の VPC 設定はチェックされません。

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 1.2.1: インバウンドおよびアウトバウンドトラフィックを、カード所有者データ環境 (CDE) に必要なトラフィックに制限し、それ以外のトラフィックを明確に拒否する。

PCI DSS の対象範囲内のサービスがデフォルトのセキュリティグループに関連付けられている場合、セキュリティグループのデフォルトルールですべてのアウトバウンドトラフィックが許可されます。このルールは、同じセキュリティグループに割り当てられているネットワークインターフェイス (および関連付けられているインスタンス) からのすべてのインバウンドトラフィックも許可します。

デフォルトのセキュリティグループのルール設定を変更して、インバウンドトラフィックとアウトバウンドトラフィックを制限する必要があります。デフォルトを使用すると、CDE との間で必要なトラフィックのみを許可するという要件に違反する可能性があります。

PCI DSS 1.3.4: カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックを許可しない。

PCI DSS の対象範囲内のサービスがデフォルトのセキュリティグループに関連付けられている場合、セキュリティグループのデフォルトルールですべてのアウトバウンドトラフィックが許可されます。このルールは、同じセキュリティグループに割り当てられているネットワークインターフェイス (および関連付けられているインスタンス) からのすべてのインバウンドトラフィックも許可します。

デフォルトのセキュリティグループのルール設定を変更して、認可されていないインバウンドトラフィックとアウトバウンドトラフィックを制限する必要があります。デフォルトを使用すると、カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックをブロックするという要件に違反する可能性があります。

PCI DSS 2.1: ネットワークにシステムをインストールする前に、ベンダーが提供するデフォルト設定を常に変更し、不要なデフォルトアカウントを削除または無効にする。

PCI DSS の対象範囲内のサービスがデフォルトのセキュリティグループに関連付けられている場合、セキュリティグループのデフォルトルールですべてのアウトバウンドトラフィックが許可されます。このルールは、同じセキュリティグループに割り当てられているネットワークインターフェイス (および関連付けられているインスタンス) からのすべてのインバウンドトラフィックも許可します。

デフォルトのセキュリティグループのルール設定を変更して、インバウンドトラフィックとアウトバウンドトラフィックを制限する必要があります。デフォルトを使用すると、不要なデフォルトアカウントを削除または無効にするという要件に違反する可能性があります。

修正

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

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

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

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

  3. リソースに対して最小特権のセキュリティグループのセットを作成します。セキュリティグループの作成方法の詳細については、「Amazon VPC ユーザーガイド」の「セキュリティグループの作成」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

[PCI.EC2.3] 未使用の EC2 セキュリティグループを削除する必要がある (使用停止)

このコントロールは使用停止になりました。

[PCI.EC2.4] 未使用の EC2 EIP を削除する必要がある

重要度:

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

AWS Config ルール: eip-attached

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

パラメータ : なし

このコントロールは、VPC に割り当てられた Elastic IP アドレスが、Amazon EC2 インスタンスまたは使用中の Elastic Network Interface (ENI) に添付されているかどうかを確認します。

結果が失敗の場合は、未使用の Amazon EC2 EIP がある可能性があります。

これにより、カード所有者データ環境 (CDE) 内の EIP のアセットインベントリを正確な状態に維持できます。

注記

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

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 2.4: PCI DSS の対象となるシステムコンポーネントのインベントリを維持する。

EIP が Amazon EC2 インスタンスに添付されていない場合、その EIP が使用されていないことを示しています。

これらのリソースを保持するビジネス上の必要性がない限り、システムコンポーネントのインベントリを正確に保つために、未使用のリソースを削除する必要があります。

修正

Elastic IP アドレスが不要になった場合、Security Hub では解放することを推奨します (アドレスはインスタンスに関連付けられていてはなりません)。

コンソールを使用して Elastic IP アドレスを解放するには

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

  2. ナビゲーションペインの [Network & Security] (ネットワークとセキュリティ) で、[Elastic IPs] を選択します。

  3. Elastic IP アドレスを選択し、[Actions] (アクション)、[Release Elastic IP address] (Elastic IP アドレスの解放) の順に選択します。

  4. プロンプトが表示されたら、[Release] (解放) を選択します。

詳細については、「Linux インスタンス用 Amazon EC2 ユーザーガイド」の Elastic IP アドレスの解放に関する情報を参照してください。

[PCI.EC2.5] どのセキュリティグループでも 0.0.0.0/0 からポート 22 への入力を許可していない必要がある

重要度:

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

AWS Config ルール: restricted-ssh

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

パラメータ : なし

このコントロールは、使用中のセキュリティグループが、無制限の着信 SSH トラフィックを拒否しているかどうかを確認します。

アウトバウンドトラフィックは評価されません。

セキュリティグループはステートフルであることに注意してください。インスタンスからリクエストを送信すると、そのリクエストに対するレスポンストラフィックは、セキュリティグループのインバウンドルールにかかわらず流入が許可されます。許可されたインバウンドトラフィックに対するレスポンスは、アウトバウンドルールにかかわらず流出が許可されます。セキュリティグループの詳細については、「Amazon VPC ユーザーガイド」の「VPC のセキュリティグループ」を参照してください。

注記

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

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

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

  • ヨーロッパ (ミラノ)

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 1.2.1 - インバウンドおよびアウトバウンドトラフィックを、カード所有者データ環境 (CDE) に必要なトラフィックに制限し、それ以外のトラフィックを明確に拒否する。

お客様の定義済み CDE 内のインスタンスへの SSH トラフィックを許可する場合があります。その場合、インバウンド SSH ソースを、0.0.0.0/0 (任意の場所) から特定の IP アドレスまたは範囲に制限します。SSH へのアクセスを制限しない場合、CDE との間で必要なトラフィックのみを許可するという要件に違反する可能性があります。

PCI DSS 1.3.1 - DMZ を実装して、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限する。

お客様の定義済み CDE 内のインスタンスへの SSH トラフィックを許可する場合があります。その場合、インバウンド SSH ソースを、0.0.0.0/0 (任意の場所) から特定の IP アドレスまたは範囲に制限します。SSH へのアクセスを制限しない場合、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限するという要件に違反する可能性があります。

PCI DSS 2.2.2: システムの機能に必要なサービス、プロトコル、デーモンなどのみを有効にする。

お客様の定義済み CDE 内のインスタンスへの SSH トラフィックを許可する場合があります。その場合は、インバウンド SSH ソースを、0.0.0.0/0 (任意の場所) からセキュリティグループの機能に必要な特定の IP アドレスまたは範囲に制限します。CDE 内では、セキュリティグループはシステムコンポーネントと見なされる可能性があるため、適切に強化する必要があります。SSH へのアクセスを制限しない場合、システムの機能に必要なサービス、プロトコル、デーモンなどのみを有効にするという要件に違反する可能性があります。

修正

VPC に関連付けられている各セキュリティグループに対して次のステップを実行します。

セキュリティグループからポート 22 へのアクセスを削除するには

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

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

  3. セキュリティグループを選択します。

  4. ページ下部で、[Inbound rules] (インバウンドルール) を選択します。

  5. [Edit inbound rules] (インバウンドルールの編集) を選択します。

  6. ポート 22 を介したアクセスを許可しているルールを特定し、X を選択してそれを削除します。

  7. [Save Rules] (ルールの保存) を選択します。

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

重要度:

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

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

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

パラメータ:

  • trafficTypeREJECT

このコントロールは、VPC フローログが存在し、VPC に対して有効になっているかどうかを確認します。トラフィックタイプは REJECT に設定されています。

VPC フローログを使用すると、VPC のネットワークインターフェイスとの間を行き来する IP アドレストラフィックに関する情報をキャプチャできます。フローログを作成後、そのログデータを CloudWatch Logs で表示して取得できるようになります。

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

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

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 10.3.3 ログエントリに日付とタイムスタンプが含まれていることを確認する。

VPC に対して VPC フローログを有効にすることで、ログエントリの日付と時刻を特定できます。イベントの日付と時刻は、開始フィールドと終了フィールドに記録されます。値は Unix 秒単位で表示されます。

PCI DSS 10.3.4 成功または失敗を示す情報がログエントリに含まれていることを確認する。

VPC に対して VPC フローログを有効にすることで、発生したイベントのタイプを特定できます。イベントのタイプはアクションフィールドに記録され、ACCEPT または REJECT になります。

PCI DSS 10.3.5 イベントの発生元がログエントリに含まれていることを確認する。

VPC に対して VPC フローログを有効にすることで、イベントの発生元を確認できます。イベント発生元は pkt-srcaddrsrcaddr、および srcport フィールドに記録されます。これらのフィールドには、トラフィックの送信元 IP アドレスと送信元ポートが表示されます。

PCI DSS 10.3.6 影響を受けるデータ、システムコンポーネント、またはリソースのアイデンティティまたは名前がログエントリに含まれていることを確認する。

VPC に対して VPC フローログを有効にすることで、影響を受けるデータ、システムコンポーネント、またはリソースのアイデンティティまたは名前を確認できます。pkt-dstaddrdstaddr、および dstport フィールドには、トラフィックの送信先 IP アドレスと送信先ポートが表示されます。

修正

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

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

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

  2. ナビゲーションペインの [Virtual Private Cloud] (仮想プライベートクラウド)で、[Your VPC] (VPC) を選択します。

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

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

  5. [Create flow log] (フローログの作成) を選択します。

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

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

  8. 送信先ロググループに [CloudWatch Logs] を選択した場合、[IAM role] (IAM ロール) で使用する IAM ロールを選択します。

  9. [Create] を選択します。

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

重要度:

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

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

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

パラメータ : なし

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

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

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

注記

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

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

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

  • ヨーロッパ (ミラノ)

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 2.3 強力な暗号化を使用して、すべてのコンソール以外の管理アクセスを暗号化する。

Application Load Balancer を HTTP リスナーと共に使用する場合は、コンソール以外の管理アクセスでリスナーが HTTPS にリダイレクトされることを確認します。カード所有者データ環境の管理者に HTTP 経由の暗号化されていない認証を許可した場合、強力な暗号化を使用してすべてのコンソール以外の管理アクセスを暗号化するという要件に違反する可能性があります。

PCI DSS 4.1 オープンなパブリックネットワークで機密性の高いカード所有者データを送信する際に、強力な暗号化とセキュリティプロトコルを使用してデータを保護する。

Application Load Balancer を HTTP リスナーと共に使用する場合は、カード所有者データの送信でリスナーが HTTPS にリダイレクトされることを確認します。カード所有者データの暗号化されていない送信を許可すると、オープンなパブリックネットワークで機密性の高いカード所有者データを送信する際に、強力な暗号化とセキュリティプロトコルを使用してデータを保護するという要件に違反する可能性があります。

修正

この問題を修正するには、HTTP リクエストを HTTPS にリダイレクトします。

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

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

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

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

  4. [Listeners] (リスナー) を選択します。

  5. HTTP リスナー (ポート 80 TCP) のチェックボックスを選択して、[Edit] (編集) を選択します。

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

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

  8. 丸印で囲まれたチェックマークを選択し、[Update] (更新) を選択します。

[PCI.ES.1] Elasticsearch ドメインは VPC 内に存在する必要がある

重要度: 非常事態

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

AWS Config ルール: elasticsearch-in-vpc-only

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

パラメータ : なし

このコントロールは、Elasticsearch ドメインが VPC 内にあるかどうかをチェックします。

パブリック到達可能性を判断するための VPC サブネットルーティング設定は評価しません。

この AWS コントロールは、OpenSearch Service のリソースベースのポリシーによって、他のアカウントまたは外部エンティティによるパブリックアクセスが許可されるかどうかもチェックしません。Elasticsearch ドメインがパブリックサブネットに添付済みでないことを確認する必要があります。「Amazon OpenSearch Service 開発者ガイド」の「リソースベースのポリシー」を参照してください。

また、推奨されるベストプラクティスに従って VPC が確実に設定されていることを確認する必要があります。「Amazon VPC ユーザーガイド」の「VPC のセキュリティのベストプラクティス」を参照してください。

注記

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

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 1.2.1: インバウンドおよびアウトバウンドトラフィックを、カード所有者データ環境 (CDE) に必要なトラフィックに制限し、それ以外のトラフィックを明確に拒否する。

OpenSearch Service クラスターにカード所有者データが含まれている場合、OpenSearch Service ドメインを VPC 内に配置する必要があります。そうすることで、インターネットゲートウェイや NAT デバイス、VPN 接続ポートを必要とせずに、OpenSearch Service と VPC 内の他のサービスとの間の安全な通信が可能になります。

この方法は、CDE との間で必要なトラフィックのみを許可するために使用されます。

PCI DSS 1.3.1: DMZ を実装して、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限する。

OpenSearch Service クラスターにカード所有者データが含まれている場合、OpenSearch Service ドメインを VPC 内に配置する必要があります。そうすることで、インターネットゲートウェイや NAT デバイス、VPN 接続ポートを必要とせずに、OpenSearch Service と VPC 内の他のサービスとの間の安全な通信が可能になります。

この方法は、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限するために使用されます。

PCI DSS 1.3.2: インバウンドインターネットトラフィックを DMZ 内の IP アドレスに制限する。

OpenSearch Service クラスターにカード所有者データが含まれている場合、OpenSearch Service ドメインを VPC に配置する必要があります。こうすることで、インターネットゲートウェイや NAT デバイス、VPN 接続ポートを必要とせずに、OpenSearch Service と VPC 内の他のサービスとの間の安全な通信が可能になります。

この方法は、インバウンドインターネットトラフィックを DMZ 内の IP アドレスに制限するために使用されます。

リソースベースのポリシーを使用して、送信元 IP アドレスに基づいてアクセスを制限する IP 条件を指定することもできます。ブログ記事「Amazon OpenSearch Service ドメインへのアクセスを制御する方法」を参照してください。

PCI DSS 1.3.4: カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックを許可しない。

OpenSearch Service クラスターにカード所有者データが含まれている場合、OpenSearch Service ドメインを VPC に配置する必要があります。こうすることで、インターネットゲートウェイや NAT デバイス、VPN 接続ポートを必要とせずに、OpenSearch Service と VPC 内の他のサービスとの間の安全な通信が可能になります。

この方法は、カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックをブロックするために使用されます。

PCI DSS 1.3.6: カード所有者データを保存するシステムコンポーネント (データベースなど) は、DMZ やその他の信頼できないネットワークから分離された内部ネットワークゾーンに配置する。

OpenSearch Service クラスターにカード所有者データが含まれている場合、OpenSearch Service ドメインを VPC 内に配置する必要があります。そうすることで、インターネットゲートウェイや NAT デバイス、VPN 接続ポートを必要とせずに、OpenSearch Service と VPC 内の他のサービスとの間の安全な通信が可能になります。

この方法は、カード所有者データを保存するシステムコンポーネントを、DMZ やその他の信頼できないネットワークから分離された内部ネットワークゾーンに配置するために使用します。

修正

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

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

「Amazon OpenSearch Service 開発者ガイド」の「VPC 内で Amazon OpenSearch Service ドメインを起動する」を参照してください。

[PCI.ES.2] Elasticsearch ドメインで保管中の暗号化を有効にする必要がある

重要度:

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

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

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

パラメータ : なし

このコントロールは、Elasticsearch ドメインで保管中の暗号化設定が有効になっているかどうかをチェックします。

注記

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

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 3.4: プライマリアカウント番号 (PAN) を、すべての保存場所で読み取り不能にする (ポータブルデジタルメディア、バックアップメディア、およびログ内を含む)。

OpenSearch Service を使用してクレジットカードのプライマリアカウント番号 (PAN) を保存する場合は、OpenSearch Service ドメインの保管中の暗号化を有効にして PAN を保護する必要があります。

有効にすると、ドメインのインデックス、自動スナップショット、OpenSearch Service ログ、スワップファイル、アプリケーションディレクトリ内のその他すべてのデータが暗号化されます。

これは、PAN を読み取り不能にするための方法です。

修正

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

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

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

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

重要度:

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

AWS Config ルール : guardduty-enabled-centralized

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

パラメータ : なし

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

GuardDuty は、侵入検知システムが通常保護する攻撃に対して有効ですが、すべての環境にとって必ずしも完全なソリューションとはなりません。このルールでは、担当者へのアラートの生成もチェックしません。GuardDuty の詳細については、「Amazon GuardDuty ユーザーガイド」を参照してください。

注記

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

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

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

  • 中国 (北京)

  • 中国 (寧夏)

  • ヨーロッパ (ミラノ)

  • 中東 (バーレーン)

  • AWS GovCloud (米国東部)

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 11.4 侵入検知または侵入防止技術を使用して、ネットワークへの侵入を検知および/または防止する。

GuardDuty は、カード所有者データ環境の境界とその中のすべての重要なポイントでトラフィックをモニタリングすることにより、要件 11.4 を満たすのに役立ちます。また、すべての侵入検知エンジン、ベースライン、シグニチャを最新の状態に保つこともできます。結果は GuardDuty から生成されます。これらのアラートは Amazon CloudWatch を使用して担当者に送信できます。「Amazon GuardDuty ユーザーガイド」の「Amazon CloudWatch Events を使用した GuardDuty の結果に対するカスタムレスポンスの作成」を参照してください。AWS アカウントで GuardDuty を有効にしていない場合、侵入検知または侵入防止技術を使用してネットワークへの侵入を防止するという要件に違反する可能性があります。

修正

この問題を修正するには、GuardDuty を有効にします。

GuardDuty を有効にする方法 (AWS Organizations を使用して複数のアカウントを管理する方法を含む) の詳細については、「Amazon GuardDuty ユーザーガイド」の「GuardDuty の開始方法」を参照してください。

[PCI.IAM.1] IAM ルートユーザーのアクセスキーが存在していてはならない

重要度: 非常事態

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

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

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

パラメータ : なし

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

注記

このコントロールは、アフリカ (ケープタウン) およびアジアパシフィック (大阪) ではサポートされていません。

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 2.1: ネットワークにシステムをインストールする前に、ベンダーが提供するデフォルト設定を常に変更し、不要なデフォルトアカウントを削除または無効にする。

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

不要なデフォルトアカウントを削除または無効にするという要件に違反する可能性があるため、ルートユーザーのアクセスキーを作成しないでください。

PCI DSS 2.2: すべてのシステムコンポーネントについて、設定基準を作成する。この基準は、すべての既知のセキュリティ脆弱性に対処し、業界で受け入れられているシステム強化基準に準拠するものである必要がある。

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

システム強化設定を実装するという要件に違反する可能性があるため、ルートユーザーのアクセスキーを作成しないでください。

PCI DSS 7.2.1: システムコンポーネントのアクセス制御システムを確立することにより、ユーザーの必要性に基づいてアクセスを制限し、明示的に許可していない限り「すべて拒否」に設定する。このアクセス制御システムは、すべてのシステムコンポーネントを対象に含んでいる必要がある。

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

ルートユーザーのアクセスキーを作成しないでください。これを行うと、システムコンポーネントへのアクセスを必要な最小特権に、またはユーザーの必要性に基づいて制限するという要件に違反する可能性があります。

修正

ルートユーザーアクセスキーを削除するには、「IAM ユーザーガイドの「ルートユーザーのアクセスキーの削除」を参照してください。

[PCI.IAM.2] IAM ユーザーには IAM ポリシーを添付してはならない

重要度:

リソースタイプ: AWS::IAM::User

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

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

パラメータ : なし

このコントロールにより、IAM ユーザーのいずれにもポリシーが添付されていないことを確認できます。IAM ユーザーは、IAM グループまたはロールから許可を継承する必要があります。

IAM ロールとグループに、最小特権ポリシーが適用されているかどうかはチェックされません。

注記

Amazon Simple Email Service が作成した IAM ユーザーは、インラインポリシーを使用して自動作成されます。Security Hub は、これらのユーザーをこのコントロールから自動的に除外します。

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 7.2.1: システムコンポーネントのアクセス制御システムを確立することにより、ユーザーの必要性に基づいてアクセスを制限し、明示的に許可していない限り「すべて拒否」に設定する。このアクセス制御システムは、すべてのシステムコンポーネントを対象に含んでいる必要がある。

IAM ポリシーは、AWS でユーザー、グループ、またはロールに権限を付与する方法です。

デフォルトでは、IAM ユーザー、グループ、ロールには、IAM ポリシーが添付されるまでは AWS リソースへのアクセス権はありません。

最小特権アクセスを管理し、PCI DSS 対象リソースのアクセス管理の複雑さを軽減するには、ユーザーレベルではなく、グループレベルまたはロールレベルで IAM ポリシーを割り当てる必要があります。

アクセス管理の複雑さを軽減することにより、プリンシパルが誤って過剰な権限を受け取ったり保持したりする可能性を減らすことができます。

これは、カード所有者データを含むシステムコンポーネントへのアクセスを必要な最小特権に、またはユーザーの必要性に基づいて制限するために使用される方法です。

修正

この問題を解決するには、IAM グループを作成し、ポリシーをこのグループにアタッチします。続いて、ユーザーをこのグループに追加します。ポリシーは、グループ内の各ユーザーに適用されます。ユーザーに直接添付されているポリシーを削除するには、IAM ユーザーガイドの「IAM ID のアクセス許可の追加および削除」を参照してください。

[PCI.IAM.3] IAM ポリシーで、完全な「*」管理者権限を許可してはならない

重要度:

リソースタイプ : AWS::IAM::Policy

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

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

パラメータ : なし

このコントロールは、AWS Identity and Access Management ポリシー (カスタマーマネージドポリシーとも呼ばれます) のデフォルトバージョンに、"Effect": "Allow" with "Action": "*""Resource": "*" に対して規定されたステートメントを持つ管理者アクセス権がないかどうかをチェックします。

作成したカスタマーマネージドポリシーのみがチェックされますが、「S3:*」などの個々のサービスへの完全なアクセス権はチェックされません。

インラインポリシーおよび AWS マネージドポリシーのチェックは行いません。

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 7.2.1: システムコンポーネントのアクセス制御システムを確立することにより、ユーザーの必要性に基づいてアクセスを制限し、明示的に許可していない限り「すべて拒否」に設定する。このアクセス制御システムは、すべてのシステムコンポーネントを対象に含んでいる必要がある。

最低限必要な権限に制限せずに完全な管理者権限を付与した場合、システムコンポーネントへのアクセスを必要な最小特権に、またはユーザーの必要性に基づいて制限するという要件に違反する可能性があります。

修正

IAM ポリシーを変更して、完全な「*」管理者権限を許可しないようにする方法については、「IAM ユーザーガイド」の「IAM ポリシーの編集」を参照してください。

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

重要度: 非常事態

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

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

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

パラメータ : なし

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

仮想 MFA を使用しているかどうかはチェックされません。

PCI DSS 要件 8.3.1 に対応するために、ハードウェア MFA (このコントロール) または仮想 MFA ([PCI.IAM.5] ルートユーザーに対して仮想 MFA を有効にする必要がある) のいずれかを選択できます。

タイムベースドワンタイムパスワード (TOTP) トークンと、ユニバーサルセカンドファクター (U2F) トークンの両方が、ハードウェア MFA オプションとして実行可能です。

注記

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

  • 中国 (北京)

  • 中国 (寧夏)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 8.3.1: 管理者のアクセス権を持つ担当者のカード所有者データ環境 (CDE) へのすべての非コンソールアクセスに多要素認証を組み込む。

ルートユーザーは、アカウントで最も権限のあるユーザーです。

MFA は、ユーザー名とパスワードに更なる保護手段を追加します。管理者権限を持つユーザーが、システムコンポーネントへの直接の物理的な接続ではなく、ネットワークインターフェイス経由でカード所有者データ環境にアクセスしていて、管理しているマシンの前に物理的にいない場合、MFA が必要です。

ハードウェア MFA の有効化は、すべての非コンソール管理アクセスに対して多要素認証 (MFA) を組み込むために使用される方法です。

修正

ルートユーザー用にハードウェア MFA デバイスを追加するには、IAM ユーザーガイドの「AWS アカウント ルートユーザー用にハードウェア MFA デバイスを有効にする (コンソール)」を参照してください。

[PCI.IAM.5] ルートユーザーに対して仮想 MFA を有効にする必要がある

重要度: 非常事態

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

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

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

パラメータ : なし

このコントロールは、AWS アカウントのユーザーがルートユーザー認証情報を使用してサインインする際に、多要素認証 (MFA) デバイスを必要とするかどうかを確認します。

ハードウェア MFA を使用しているかどうかはチェックされません。

PCI DSS 要件 8.3.1 に対応するために、仮想 MFA (このコントロール) またはハードウェア MFA ([PCI.IAM.4] ルートユーザーに対してハードウェア MFA を有効にする必要がある) のいずれかを選択できます。

注記

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

  • 中国 (北京)

  • 中国 (寧夏)

  • AWS GovCloud (米国東部)

  • AWS GovCloud (米国西部)

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 8.3.1: 管理者のアクセス権を持つ担当者のカード所有者データ環境 (CDE) へのすべての非コンソールアクセスに多要素認証を組み込む。

ルートユーザーは、アカウントで最も権限のあるユーザーです。

MFA は、ユーザー名とパスワードに更なる保護手段を追加します。管理者権限を持つユーザーがカード所有者データ環境にアクセスしていて、管理しているマシンの前に物理的にいない場合、MFA が必要です。

仮想 MFA の有効化は、すべての非コンソール管理アクセスに対して多要素認証 (MFA) を組み込むために使用される方法です。

修正

ルートユーザー用にハードウェア MFA デバイスを追加するには、IAM ユーザーガイドの「AWS アカウントのルートユーザーの仮想 MFA デバイスを有効にする (コンソール)」を参照してください。

[PCI.IAM.6] すべての IAM ユーザーに対して MFA を有効にする必要がある

重要度:

リソースタイプ: AWS::IAM::User

AWS Config ルール: iam-user-mfa-enabled

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

パラメータ : なし

このコントロールは、IAM ユーザーが多要素認証 (MFA) を有効にしているかどうかを確認します。

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 8.3.1: 管理者のアクセス権を持つ担当者のカード所有者データ環境 (CDE) へのすべての非コンソールアクセスに多要素認証を組み込む。

すべての IAM ユーザーに対する MFA の有効化は、すべての非コンソール管理アクセスに対して多要素認証 (MFA) を組み込むために使用される方法です。

修正

IAM ユーザーを MFA に追加するには、IAM ユーザーガイドの「AWS での多要素認証 (MFA) の使用」を参照してください。

[PCI.IAM.7] IAM ユーザー認証情報が事前定義された日数以内に使用されない場合、認証情報を無効にする必要がある

重要度:

リソースタイプ: AWS::IAM::User

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

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

パラメータ :

  • maxCredentialUsageAge: 90 (日)

このコントロールは、IAM ユーザーのパスワードまたはアクティブなアクセスキーが、指定した日数以内に一度も使用されていないかどうかを確認します。デフォルトは 90 日間です。

Security Hub では、アカウントのすべてのアクセスキーを生成したり削除したりしないことを強く推奨しています。代わりにベストプラクティスとして、1 つ以上の IAM ロールを作成するか、フェデレーションを使用することを推奨します。これらのプラクティスを使用すると、ユーザーは既存の企業認証情報を使用して AWS Management Console コンソールと AWS CLI にサインインできます。

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

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

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

アクセスキーが既にある場合は、90 日以上非アクティブになっている未使用のユーザー認証情報を削除または無効化することを推奨します。

このコントロールは、非アクティブなパスワードまたはアクティブなアクセスキーのみをチェックします。90 日が経過していても、アカウントの使用を無効にすることはありません。お客様はアクションを実行し、未使用の認証情報を無効にする責任があります。

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 8.1.4 非アクティブなユーザーアカウントを 90 日以内に削除/無効にする。

IAM パスワードまたはアクセスキーを使用する場合は、使用をモニタリングし、90 日間使用しない場合は無効にしてください。IAM ユーザーアカウントで未使用の認証情報をアクティブにしておくことを許可した場合、非アクティブなユーザーアカウントを 90 日以内に削除/無効にするという要件に違反する可能性があります。

修正

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

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

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

非アクティブなアカウントまたは未使用の IAM 認証情報を無効にするには

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

  2. [Access management] (アクセス管理) で、[Users] (ユーザー) を選択します。

  3. 90 日より以前の認証情報を持つユーザーの名前を選択します。

  4. [Security credentials] (セキュリティ認証情報) を選択します。90 日以上使用されなかったすべてのサインイン認証情報とアクセスキーについて、[Make inactive] (非アクティブにする) を選択します。

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

重要度:

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

AWS Config ルール : iam-password-policy

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

パラメータ : なし

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

  • RequireUppercaseCharacters - パスワードには少なくとも 1 つの大文字が必要。(デフォルト = true)

  • RequireLowercaseCharacters - パスワードには少なくとも 1 つの小文字が必要。(デフォルト = true)

  • RequireNumbers - パスワードには少なくとも 1 つの数字が必要。(デフォルト = true)

  • MinimumPasswordLength - パスワードの最小文字数。(デフォルト = 7 以上)

  • PasswordReusePrevention - パスワードの再利用を許可するまでのパスワードの数。(デフォルト = 4)

  • MaxPasswordAge - パスワードが有効期限切れになるまでの日数。(デフォルト = 90)

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 8.1.4: 非アクティブなユーザーアカウントを 90 日以内に削除/無効にする。

AWS アカウントに IAM ユーザーがある場合は、IAM パスワードポリシーを適切に設定する必要があります。IAM ユーザーのパスワードを保護しないと、90 日以内に非アクティブなユーザーアカウントを削除または無効にするという要件に違反する可能性があります。デフォルトでは、MaxPasswordAge パラメータは 90 日に設定されています。パスワードの有効期限が切れると、IAM ユーザーはパスワードが変更されるまでアカウントにアクセスできません。これにより、ユーザーは無効になります。

PCI DSS 8.2.3: パスワード/パスフレーズは以下を満たしている必要がある: 少なくとも 7 文字以上で、数字とアルファベットの両方を含む。

AWS アカウントに IAM ユーザーがある場合は、IAM パスワードポリシーを適切に設定する必要があります。IAM ユーザーのパスワードを保護しないと、パスワードの長さは少なくとも 7 文字という要件に違反する可能性があります。また、数字とアルファベットの両方を含むという要件に違反する可能性もあります。デフォルトでは、MinimumPasswordLength7RequireUppercaseCharacterstrueRequireLowercaseCharacterstrue です。

PCI DSS 8.2.4: 少なくとも 90 日に 1 回、ユーザーのパスワード/パスフレーズを変更する。

AWS アカウントに IAM ユーザーがある場合は、IAM パスワードポリシーを適切に設定する必要があります。IAM ユーザーのパスワードを保護しないと、少なくとも 90 日に 1 回はユーザーのパスワードまたはパスフレーズを変更するという要件に違反する可能性があります。デフォルトでは、MaxPasswordAge パラメータは 90 日に設定されています。パスワードの有効期限が切れると、IAM ユーザーはパスワードが変更されるまでアカウントにアクセスできません。

PCI DSS 8.2.5: ユーザーが直近で使用した 4 つのパスワード/パスフレーズのいずれかと同じである新しいパスワード/パスフレーズの指定を許可しない。

AWS アカウントに IAM ユーザーがある場合は、IAM パスワードポリシーを適切に設定する必要があります。IAM ユーザーのパスワードを保護しないと、直近の 4 つのパスワードまたはパスフレーズと同じである新しいパスワードまたはパスフレーズの指定を許可しないという要件に違反する可能性があります。デフォルトでは、PasswordReusePrevention4 に設定されており、ユーザーは直近の 4 つのパスワードを再利用できなくなります。

修正

推奨される設定を使用するようにパスワードポリシーを更新するには、「IAM ユーザーガイドの「IAM ユーザー用のアカウントパスワードポリシーの設定」を参照してください。

[PCI.KMS.1] KMS キーのローテーションを有効にする必要がある

重要度:

リソースタイプ: AWS::KMS::Key

AWS Config ルール: cmk-backing-key-rotation-enabled

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

パラメータ : なし

このコントロールは、各 KMS キーについて、キーローテーションが有効になっていることを確認します。キーマテリアルをインポートした KMS キーはチェックされません。

マテリアルをインポートしたキーと、AWS KMS に保存されていないキーは必ずローテーションされるようにしてください。AWS マネージドキー は 3 年に 1 度ローテーションされます。

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 3.6.4: 暗号化キーは、暗号化期間の終了時点に到達したら変更する必要がある。

PCI DSS では暗号化期間は指定されていませんが、キーローテーションが有効な場合、デフォルトでは毎年ローテーションが行われます。

KMS キーを使用してカード所有者データを暗号化する場合は、キーローテーションを有効にする必要があります。

これは、暗号化期間の終了時点に到達した後、暗号化キーを変更するために使用される方法です。

修正

KMS キーローテーションを有効にするには

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

  2. AWS リージョン を変更するには、ページの右上隅にあるリージョンセレクターを使用します。

  3. [Customer managed keys] (カスタマーマネージドキー) を選択します。

  4. [Alias] (エイリアス) 列で、更新するキーのエイリアスを選択します。

  5. [Key rotation] (キーローテーション) を選択します。

  6. [Automatically rotate this KMS key every year] (この KMS キーを毎年自動的にローテーションする) を選択し、[Save] (保存) を選択します。

[PCI.Lambda.1] Lambda 関数は、パブリックアクセスを禁止する必要がある

重要度: 非常事態

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

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

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

パラメータ : なし

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

IAM ロールなどの内部プリンシパルによる Lambda 関数へのアクセスはチェックされません。最小特権の Lambda リソースベースのポリシーを使用して、Lambda 関数へのアクセスを認可されたプリンシパルのみに制限するようにしてください。

AWS Lambda のリソースベースのポリシーの使用の詳細については、「AWS Lambda 開発者ガイド」を参照してください。

注記

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

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

  • 中国 (北京)

  • 中国 (寧夏)

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 1.2.1: インバウンドおよびアウトバウンドトラフィックを、カード所有者データ環境 (CDE) に必要なトラフィックに制限し、それ以外のトラフィックを明確に拒否する。

PCI DSS の対象範囲内の Lambda 関数を使用する場合、その関数はパブリックにアクセス可能であってはなりません。パブリックにアクセス可能な関数は、CDE との間で必要なトラフィックのみを許可するという要件に違反する可能性があります。

PCI DSS 1.3.1: DMZ を実装して、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限する。

PCI DSS の対象範囲内の Lambda 関数を使用する場合、その関数はパブリックにアクセス可能であってはなりません。パブリックにアクセス可能な関数は、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限するという要件に違反する可能性があります。

PCI DSS 1.3.2: インバウンドインターネットトラフィックを DMZ 内の IP アドレスに制限する。

PCI DSS の対象範囲内の Lambda 関数を使用する場合、その関数はパブリックにアクセス可能であってはなりません。パブリックにアクセス可能な関数は、インバウンドインターネットトラフィックを DMZ 内の IP アドレスに制限するという要件に違反する可能性があります。

PCI DSS 1.3.4: カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックを許可しない。

PCI DSS の対象範囲内の Lambda 関数を使用する場合、その関数はパブリックにアクセス可能であってはなりません。パブリックにアクセス可能な関数は、カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックをブロックするという要件に違反する可能性があります。

PCI DSS 7.2.1: システムコンポーネントのアクセス制御システムを確立することにより、ユーザーの必要性に基づいてアクセスを制限し、明示的に許可していない限り「すべて拒否」に設定する。このアクセス制御システムは、すべてのシステムコンポーネントを対象に含んでいる必要がある。

PCI DSS の対象範囲内の Lambda 関数を使用する場合、その関数はパブリックにアクセス可能であってはなりません。パブリックにアクセス可能な関数は、カード所有者データを含むシステムコンポーネントへのアクセスを必要な最小特権に、またはユーザーの必要性に基づいて制限するという要件に違反する可能性があります。

修正

この問題を修正するには、リソースベースのポリシーを更新して、パブリックにアクセス可能な Lambda 関数をプライベートな Lambda 関数に変更します。

AddPermission および AddLayerVersionPermission API アクションの範囲内の Lambda リソースのリソースベースのポリシーのみを更新できます。

Lambda リソースのポリシーを JSON で作成したり、CLI または SDK を使用してこれらのアクションのパラメータにマッピングされない条件を使用したりすることはできません。

AWS CLI を使用して、AWS のサービスまたは別のアカウントから関数の使用の許可を取り消すには

  1. GetPolicy の出力からステートメントの ID を取得するために、AWS CLI から、次のコマンドを実行します。

    aws lambda get-policy --function-name yourfunctionname

    このコマンドは、パブリックにアクセス可能な Lambda 関数に関連付けられた Lambda リソースベースのポリシー文字列を返します。

  2. get-policy コマンドによって返されたポリシーステートメントから、Sid フィールドの文字列値をコピーします。

  3. AWS CLI から、次のコマンドを実行します

    aws lambda remove-permission --function-name yourfunctionname —statement-id youridvalue

Lambda コンソールを使用して Lambda 関数へのアクセスを制限するには

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

  2. [Functions] (関数) に移動し、パブリックにアクセス可能な Lambda 関数を選択します。

  3. [Designer] (デザイナー) で、左上のキーアイコンを選択します。ツールチップ [View permissions] (許可を表示) があります。

  4. [Function policy] (関数ポリシー) で、プリンシパル要素 “*” または {“AWS”: “*”} に対するアクションがポリシーで許可されている場合は、パブリックなアクセス可能です。

    次の IAM 条件を追加して、アクセスをお使いのアカウントのみに制限することを検討してください。

    "Condition": { "StringEquals": { "AWS:SourceAccount": "<account_id>" } } }

リソースごとに他のアカウントに使用許可を付与することを可能にする、他の Lambda リソースベースのポリシーの例については、「AWS Lambda 開発者ガイド」の、AWS Lambda でのリソースベースのポリシーの使用に関する情報を参照してください。

[PCI.Lambda.2] Lambda 関数は VPC 内に存在する必要がある

重要度:

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

AWS Config ルール: lambda-inside-vpc

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

パラメータ : なし

このコントロールは、Lambda 関数が VPC 内にあるかどうかをチェックします。Lambda@Edge リソースに関する失敗の結果が表示される場合があります。

パブリック到達可能性を判断するための VPC サブネットルーティング設定は評価しません。

注記

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

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

  • 中国 (北京)

  • 中国 (寧夏)

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 1.2.1: インバウンドおよびアウトバウンドトラフィックを、カード所有者データ環境 (CDE) に必要なトラフィックに制限し、それ以外のトラフィックを明確に拒否する。

デフォルトでは、Lambda は AWS サービスとインターネットにアクセスできる、安全なデフォルトの VPC で関数を実行します。

PCI DSS の対象範囲内の Lambda 関数を使用する場合、VPC エンドポイントを使用するように関数を設定できます。こうすることで、インターネットアクセスなしで VPC 内から Lambda 関数に接続できるようになります。この方法は、CDE との間で必要なトラフィックのみを許可するために使用されます。

PCI DSS 1.3.1: DMZ を実装して、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限する。

デフォルトでは、Lambda は AWS サービスとインターネットにアクセスできる、安全なデフォルトの VPC で関数を実行します。

PCI DSS の対象範囲内の Lambda 関数を使用する場合、VPC エンドポイントを使用するように関数を設定できます。こうすることで、インターネットアクセスなしで VPC 内から Lambda 関数に接続できるようになります。この方法は、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限するために使用されます。

PCI DSS 1.3.2: インバウンドインターネットトラフィックを DMZ 内の IP アドレスに制限する。

デフォルトでは、Lambda は AWS サービスとインターネットにアクセスできる、安全なデフォルトの VPC で関数を実行します。

PCI DSS の対象範囲内の Lambda 関数を使用する場合、VPC エンドポイントを使用するように関数を設定できます。こうすることで、インターネットアクセスなしで VPC 内から Lambda 関数に接続できるようになります。この方法は、インバウンドインターネットトラフィックを DMZ 内の IP アドレスに制限するために使用されます。

PCI DSS 1.3.4: カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックを許可しない。

デフォルトでは、Lambda は AWS サービスとインターネットにアクセスできる、安全なデフォルトの VPC で関数を実行します。

PCI DSS の対象範囲内の Lambda 関数を使用する場合、VPC エンドポイントを使用するように関数を設定できます。こうすることで、インターネットアクセスなしで VPC 内から Lambda 関数に接続できるようになります。この方法は、カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックをブロックするために使用されます。

修正

お使いのアカウントの 仮想プライベートクラウド (VPC) のプライベートサブネットに接続するように関数を設定するには

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

  2. [Functions] (関数) に移動し、Lambda 関数を選択します。

  3. [Network] (ネットワーク) までスクロールし、関数の接続要件を持つ VPC を選択します。

  4. 高可用性モードで関数を実行するために、Security Hub では少なくとも 2 つのサブネットを選択することを推奨します。

  5. 関数の接続要件を持つセキュリティグループを少なくとも 1 つ選択します。

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

詳細については、「AWS Lambda 開発者ガイド」の、VPC 内のリソースにアクセスできるように Lambda 関数を構成する方法についてのセクションを参照してください。

[PCI.OpenSearch.1] Amazon OpenSearch Service ドメインは VPC 内に存在している必要がある

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

重要度:

リソースタイプ: AWS::OpenSearch::Domain

AWS Config ルール: opensearch-in-vpc-only

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

パラメータ : なし

このコントロールは、OpenSearch ドメインが VPC 内にあるかどうかをチェックします。このコントロールは、パブリックアクセスの可能性を判断するための VPC サブネットルーティング設定を評価しません。

OpenSearch ドメインがパブリックサブネットに添付済みではないことを確認する必要があります。「Amazon OpenSearch Service 開発者ガイド」の「リソースベースのポリシー」を参照してください。

また、推奨されるベストプラクティスに従って VPC が設定されていることを確認する必要もあります。「Amazon VPC ユーザーガイド」の「VPC のセキュリティのベストプラクティス」を参照してください。

VPC 内にデプロイされた OpenSearch ドメインは、プライベート AWS ネットワーク経由で VPC リソースと通信できます。パブリックインターネットを経由する必要はありません。この設定では、転送中のデータへのアクセスを制限することにより、セキュリティ体制が向上します。VPC は、ネットワーク ACL やセキュリティグループを含む、OpenSearch ドメインへのアクセスを安全にするため、多数のネットワークコントロールを提供します。Security Hub では、これらのコントロールを有効に利用するために、パブリック OpenSearch ドメインを VPC に移行することを推奨します。

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 1.2.1: インバウンドおよびアウトバウンドトラフィックを、カード所有者データ環境 (CDE) に必要なトラフィックに制限し、それ以外のトラフィックを明確に拒否する。

Amazon ES クラスターにカード所有者データが含まれている場合、Amazon ES ドメインは VPC 内に配置する必要があります。そうすることで、インターネットゲートウェイや NAT デバイス、VPN 接続ポートを必要とせずに、Amazon ES と VPC 内の他のサービスとの間の安全な通信が可能になります。

この方法は、CDE との間で必要なトラフィックのみを許可するために使用されます。

PCI DSS 1.3.1: DMZ を実装して、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限する。

Amazon ES クラスターにカード所有者データが含まれている場合、Amazon ES ドメインは VPC 内に配置する必要があります。そうすることで、インターネットゲートウェイや NAT デバイス、VPN 接続ポートを必要とせずに、Amazon ES と VPC 内の他のサービスとの間の安全な通信が可能になります。

この方法は、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限するために使用されます。

PCI DSS 1.3.2: インバウンドインターネットトラフィックを DMZ 内の IP アドレスに制限する。

Amazon OpenSearch Service クラスターにカード所有者データが含まれている場合、Amazon OpenSearch Service ドメインを VPC に配置する必要があります。こうすることで、インターネットゲートウェイや NAT デバイス、VPN 接続ポートを必要とせずに、Amazon OpenSearch Service と VPC 内の他のサービスとの間の安全な通信が可能になります。

この方法は、インバウンドインターネットトラフィックを DMZ 内の IP アドレスに制限するために使用されます。

リソースベースのポリシーを使用して、送信元 IP アドレスに基づいてアクセスを制限する IP 条件を指定することもできます。ブログ記事「Amazon Elasticsearch Service ドメインへのアクセスを制御する方法」を参照してください。

PCI DSS 1.3.4: カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックを許可しない。

Amazon ES クラスターにカード所有者データが含まれている場合、Amazon ES ドメインを VPC に配置する必要があります。こうすることで、インターネットゲートウェイや NAT デバイス、VPN 接続ポートを必要とせずに、Amazon ES と VPC 内の他のサービスとの間の安全な通信が可能になります。

この方法は、カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックをブロックするために使用されます。

PCI DSS 1.3.6: カード所有者データを保存するシステムコンポーネント (データベースなど) は、DMZ やその他の信頼できないネットワークから分離された内部ネットワークゾーンに配置する。

Amazon ES クラスターにカード所有者データが含まれている場合、Amazon ES ドメインは VPC 内に配置する必要があります。そうすることで、インターネットゲートウェイや NAT デバイス、VPN 接続ポートを必要とせずに、Amazon ES と VPC 内の他のサービスとの間の安全な通信が可能になります。

この方法は、カード所有者データを保存するシステムコンポーネントを、DMZ やその他の信頼できないネットワークから分離された内部ネットワークゾーンに配置するために使用します。

修正

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

「Amazon OpenSearch Service 開発者ガイド」の「VPC 内で Amazon OpenSearch Service ドメインを起動する」を参照してください。

[PCI.OpenSearch.2] OpenSearch ドメインは保管中の暗号化を有効にする必要がある

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

重要度:

リソースタイプ: AWS::OpenSearch::Domain

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

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

パラメータ : なし

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

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

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

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 3.4: プライマリアカウント番号 (PAN) を、すべての保存場所で読み取り不能にする (ポータブルデジタルメディア、バックアップメディア、およびログ内を含む)。

Amazon OpenSearch Service を使用してクレジットカードのプライマリアカウント番号 (PAN) を保存する場合は、Amazon OpenSearch Service ドメインの保管中の暗号化を有効にして PAN を保護する必要があります。

有効にすると、ドメインのインデックス、自動スナップショット、Amazon OpenSearch Service ログ、スワップファイル、アプリケーションディレクトリ内のその他すべてのデータが暗号化されます。

これは、PAN を読み取り不能にするための方法です。

修正

デフォルトでは、ドメインの保管中のデータは暗号化されず、既存のドメインでこの機能の使用は設定できません。この機能を有効にするには、別のドメインを作成してデータを移行する必要があります。

ドメインの作成の詳細については、「Amazon OpenSearch Service 開発者ガイド」の「Amazon OpenSearch Service ドメインの作成と管理」を参照してください。

「Amazon OpenSearch Service 開発者ガイド」の「VPC 内で Amazon OpenSearch Service ドメインを起動する」を参照してください。

[PCI.RDS.1] Amazon RDS スナップショットでパブリックアクセスを禁止する必要があります

重要度: 非常事態

リソースタイプ: AWS::RDS::DBSnapshot

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

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

パラメータ : なし

このコントロールは、Amazon RDS DB スナップショットが他のアカウントによるアクセスを禁止しているかどうかをチェックします。また、スナップショットへのアクセスと Amazon RDS 設定を変更する許可が、認可されたプリンシパルのみに制限されていることを確認する必要があります。

Amazon RDS での DB スナップショットの共有の詳細については、「Amazon RDS ユーザーガイド」を参照してください。

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

注記

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

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

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

  • ヨーロッパ (ミラノ)

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 1.2.1: インバウンドおよびアウトバウンドトラフィックを、カード所有者データ環境 (CDE) に必要なトラフィックに制限し、それ以外のトラフィックを明確に拒否する。

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

RDS スナップショットにカード所有者データが保存されている場合、RDS スナップショットを他のアカウントと共有しないでください。RDS スナップショットを共有すると、他のアカウントがスナップショットから RDS インスタンスを復元できるようになります。これを許可すると、CDE との間で必要なトラフィックのみを許可するという要件に違反する場合があります。

PCI DSS 1.3.1: DMZ を実装して、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限する。

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

RDS スナップショットにカード所有者データが保存されている場合、RDS スナップショットを他のアカウントと共有しないでください。RDS スナップショットを共有すると、他のアカウントがスナップショットから RDS インスタンスを復元できるようになります。これを許可すると、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限するという要件に違反する可能性があります。

PCI DSS 1.3.4: カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックを許可しない。

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

RDS スナップショットにカード所有者データが保存されている場合、RDS スナップショットを他のアカウントと共有しないでください。RDS スナップショットを共有すると、他のアカウントがスナップショットから RDS インスタンスを復元できるようになります。これを許可すると、カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックをブロックするという要件に違反する可能性があります。

PCI DSS 1.3.6: カード所有者データを保存するシステムコンポーネント (データベースなど) は、DMZ やその他の信頼できないネットワークから分離された内部ネットワークゾーンに配置する。

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

RDS スナップショットにカード所有者データが保存されている場合、RDS スナップショットを他のアカウントと共有しないでください。RDS スナップショットを共有すると、他のアカウントがスナップショットから RDS インスタンスを復元できるようになります。これを許可すると、カード所有者データを保存するシステムコンポーネントを、DMZ やその他の信頼できないネットワークから分離された内部ネットワークゾーンに配置するという要件に違反する可能性があります。

PCI DSS 7.2.1: システムコンポーネントのアクセス制御システムを確立することにより、ユーザーの必要性に基づいてアクセスを制限し、明示的に許可していない限り「すべて拒否」に設定する。このアクセス制御システムは、すべてのシステムコンポーネントを対象に含んでいる必要がある。

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

RDS スナップショットにカード所有者データが保存されている場合、RDS スナップショットを他のアカウントと共有しないでください。RDS スナップショットを共有すると、他のアカウントがスナップショットから RDS インスタンスを復元できるようになります。これを許可すると、カード所有者データを含むシステムコンポーネントへのアクセスを必要な最小特権に、またはユーザーの必要性に基づいて制限するという要件に違反する可能性があります。

修正

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

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

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

  3. [Actions] (アクション) リストから [Share Snapshots] (スナップショットの共有) を選択します。

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

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

  6. [Save] (保存) を選択します。

[PCI.RDS.2] Amazon RDS DB インスタンスでは、パブリックアクセスを禁止する必要があります。これは、PubliclyAccessible 設定により判断されます

重要度: 非常事態

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

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

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

パラメータ : なし

このコントロールは、インスタンス設定項目の publiclyAccessible フィールドを評価して、RDS インスタンスがパブリックにアクセスできるかどうかをチェックします。publiclyAccessible の値は、DB インスタンスがパブリックにアクセスできるかどうかを示します。DB インスタンスがパブリックにアクセス可能な場合、それはパブリックに解決可能な DNS 名を持つインターネット向けインスタンスであり、DNS 名はパブリック IP アドレスに解決されます。DB インスタンスがパブリックにアクセスできない場合、それはプライベート IP アドレスに解決される DNS 名を持つ内部インスタンスとなります。

コントロールでは、VPC サブネットルーティング設定やセキュリティグループルールはチェックされません。お客様は VPC サブネットルーティングでパブリックアクセスが許可されていないことと、RDS インスタンスに関連付けられたセキュリティグループのインバウンドルールで無制限のアクセス (0.0.0.0/0) が許可されていないことを確認する必要もあります。また、RDS インスタンスの設定とリソースを変更するユーザーの IAM 許可を制限することにより、RDS インスタンス設定へのアクセスが認可されたユーザーのみに制限されていることも確認する必要があります。

詳細については、「Amazon RDS ユーザーガイド」の「VPC 内の DB インスタンスをインターネットから隠す」を参照してください。

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 1.2.1: インバウンドおよびアウトバウンドトラフィックを、カード所有者データ環境 (CDE) に必要なトラフィックに制限し、それ以外のトラフィックを明確に拒否する。

PCI DSS の対象範囲内の RDS インスタンスを使用する場合、その RDS インスタンスはパブリックアクセス可能であってはなりません。これを許可すると、CDE との間で必要なトラフィックのみを許可するという要件に違反する場合があります。

PCI DSS 1.3.1: DMZ を実装して、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限する。

RDS インスタンスを使用してカード所有者データを保存する場合、その RDS インスタンスはパブリックアクセス可能であってはなりません。これを許可すると、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限するという要件に違反する可能性があります。

PCI DSS 1.3.2: インバウンドインターネットトラフィックを DMZ 内の IP アドレスに制限する。

RDS インスタンスを使用してカード所有者データを保存する場合、その RDS インスタンスはパブリックアクセス可能であってはなりません。これは、インバウンドインターネットトラフィックを DMZ 内の IP アドレスに制限するという要件に違反する可能性があるためです。

PCI DSS 1.3.4: カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックを許可しない。

RDS インスタンスを使用してカード所有者データを保存する場合、その RDS インスタンスはパブリックアクセス可能であってはなりません。これを許可すると、カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックをブロックするという要件に違反する可能性があります。

PCI DSS 1.3.6: カード所有者データを保存するシステムコンポーネント (データベースなど) は、DMZ やその他の信頼できないネットワークから分離された内部ネットワークゾーンに配置する。

RDS インスタンスを使用してカード所有者データを保存する場合、その RDS インスタンスはパブリックアクセス可能であってはなりません。これを許可すると、カード所有者データを保存するシステムコンポーネントを、DMZ やその他の信頼できないネットワークから分離された内部ネットワークゾーンに配置するという要件に違反する可能性があります。

PCI DSS 7.2.1: システムコンポーネントのアクセス制御システムを確立することにより、ユーザーの必要性に基づいてアクセスを制限し、明示的に許可していない限り「すべて拒否」に設定する。このアクセス制御システムは、すべてのシステムコンポーネントを対象に含んでいる必要がある。

RDS インスタンスを使用してカード所有者データを保存する場合、RDS インスタンスはパブリックアクセス可能であってはなりません。これは、カード所有者データを含むシステムコンポーネントへのアクセスを必要な最小特権に、またはユーザーの必要性に基づいて制限するという要件に違反する可能性があるためです。

修正

Amazon RDS データベースのパブリックアクセスを削除するには

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

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

  3. 変更を選択します。

  4. [Network & Security] (ネットワークとセキュリティ) までスクロールします。

  5. [Public accessibility] (パブリックアクセシビリティ) で、[No] (いいえ) を選択します。

  6. 一番下までスクロールし、[Continue] (続行) を選択します。

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

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

VPC 内の DB インスタンスの使用方法の詳細については、「Amazon RDS ユーザーガイド」を参照してください。

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

重要度: 非常事態

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

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

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

パラメータ : なし

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

注記

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

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 1.2.1: インバウンドおよびアウトバウンドトラフィックを、カード所有者データ環境 (CDE) に必要なトラフィックに制限し、それ以外のトラフィックを明確に拒否する。

Amazon Redshift クラスターを使用してカード所有者データを保存する場合、クラスターはパブリックアクセス可能であってはなりません。これを許可すると、CDE との間で必要なトラフィックのみを許可するという要件に違反する場合があります。

PCI DSS 1.3.1: DMZ を実装して、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限する。

Amazon Redshift クラスターを使用してカード所有者データを保存する場合、クラスターはパブリックアクセス可能であってはなりません。これを許可すると、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限するという要件に違反する可能性があります。

PCI DSS 1.3.2: インバウンドインターネットトラフィックを DMZ 内の IP アドレスに制限する。

Amazon Redshift クラスターを使用してカード所有者データを保存する場合、クラスターはパブリックアクセス可能であってはなりません。これは、インバウンドインターネットトラフィックを DMZ 内の IP アドレスに制限するという要件に違反する可能性があるためです。

PCI DSS 1.3.4: カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックを許可しない。

Amazon Redshift クラスターを使用してカード所有者データを保存する場合、クラスターはパブリックアクセス可能であってはなりません。これを許可すると、カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックをブロックするという要件に違反する可能性があります。

PCI DSS 1.3.6: カード所有者データを保存するシステムコンポーネント (データベースなど) は、DMZ やその他の信頼できないネットワークから分離された内部ネットワークゾーンに配置する。

Amazon Redshift クラスターを使用してカード所有者データを保存する場合、クラスターはパブリックアクセス可能であってはなりません。これを許可すると、カード所有者データを保存するシステムコンポーネントを、DMZ やその他の信頼できないネットワークから分離された内部ネットワークゾーンに配置するという要件に違反する可能性があります。

修正

Amazon Redshift クラスターのパブリックアクセスを無効にするには

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

  2. ナビゲーションペインで [Clusters] (クラスター) を選択し、パブリック Amazon Redshift クラスターを選択します。

  3. [Cluster] (クラスター) ドロップダウンメニューから、[Modify cluster] (クラスターの変更) を選択します。

  4. [Publicly accessible] (パブリックアクセス可能) で、[No] (いいえ) を選択します。

  5. 変更を選択します。

VPC でクラスターを作成する方法の詳細については、「Amazon Redshift クラスター管理ガイド」を参照してください。

[PCI.S3.1] S3 バケットはパブリック書き込みアクセスを禁止する必要がある

重要度: 非常事態

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

AWS Config ルール : s3-bucket-public-write-prohibited

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

パラメータ : なし

このコントロールは、パブリックアクセスブロック設定、バケットポリシー、およびバケットアクセスコントロールリスト (ACL) を評価することにより、S3 バケットがパブリック書き込みアクセスを許可するかどうかをチェックします。

IAM ロールなどの内部プリンシパルによるバケットへの書き込みアクセス権はチェックされません。バケットへのアクセスは、認可されたプリンシパルのみに制限する必要があります。

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 1.2.1: インバウンドおよびアウトバウンドトラフィックを、カード所有者データ環境 (CDE) に必要なトラフィックに制限し、それ以外のトラフィックを明確に拒否する。

S3 バケットを使用してカード所有者データを保存する場合、バケットはパブリック書き込みアクセスを禁止する必要があります。パブリック書き込みアクセスを許可すると、CDE との間で必要なトラフィックのみを許可するという要件に違反する場合があります。

PCI DSS 1.3.1: DMZ を実装して、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限する。

S3 バケットを使用してカード所有者データを保存する場合、バケットはパブリック書き込みアクセスを禁止する必要があります。パブリック書き込みアクセスを許可すると、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限するという要件に違反する可能性があります。

インターネット上の誰でも S3 バケットに書き込みできるようにお客様が明示的にリクエストしない限り、S3 バケットがパブリックに書き込み可能ではないことを確認する必要があります。

PCI DSS 1.3.2: インバウンドインターネットトラフィックを DMZ 内の IP アドレスに制限する。

S3 バケットを使用してカード所有者データを保存する場合、バケットはパブリック書き込みアクセスを禁止する必要があります。パブリック書き込みアクセスを許可すると、インバウンドインターネットトラフィックを DMZ 内の IP アドレスに制限するという要件に違反する可能性があります。

PCI DSS 1.3.4: カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックを許可しない。

S3 バケットを使用してカード所有者データを保存する場合、バケットはパブリック書き込みアクセスを禁止する必要があります。パブリック書き込みアクセスを許可すると、カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックをブロックするという要件に違反する可能性があります。

PCI DSS 1.3.6: カード所有者データを保存するシステムコンポーネント (データベースなど) は、DMZ やその他の信頼できないネットワークから分離された内部ネットワークゾーンに配置する。

S3 バケットを使用してカード所有者データを保存する場合、バケットはパブリック書き込みアクセスを禁止する必要があります。パブリック書き込みアクセスを許可すると、カード所有者データを保存するシステムコンポーネントを、DMZ やその他の信頼できないネットワークから分離された内部ネットワークゾーンに配置するという要件に違反する可能性があります。

PCI DSS 7.2.1: システムコンポーネントのアクセス制御システムを確立することにより、ユーザーの必要性に基づいてアクセスを制限し、明示的に許可していない限り「すべて拒否」に設定する。このアクセス制御システムは、すべてのシステムコンポーネントを対象に含んでいる必要がある。

S3 バケットを使用してカード所有者データを保存する場合、バケットはパブリック書き込みアクセスを禁止する必要があります。パブリック書き込みアクセスを許可すると、システムコンポーネントへのアクセスを必要な最小特権に、またはユーザーの必要性に基づいて制限するという要件に違反する可能性があります。

修正

S3 バケットに対するパブリックアクセスを削除するには

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

  2. 結果で特定されたバケットの名前を選択します。

  3. [Permissions] (許可) を選択し、[Public access settings] (パブリックアクセス設定) を選択します。

  4. [Edit] (編集) を選択し、4 つのオプションをすべて選択して、次に [Save] (保存) を選択します。

  5. プロンプトが表示されたら、confirm を入力して [Confirm] (確認) を選択します。

[PCI.S3.2] S3 バケットではパブリック読み取りアクセスを禁止する必要がある

重要度: 非常事態

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

AWS Config ルール: s3-bucket-public-read-prohibited

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

パラメータ : なし

このコントロールは、パブリックアクセスブロック設定、バケットポリシー、およびバケットアクセスコントロールリスト (ACL) を評価することにより、S3 バケットがパブリック読み取りアクセスを許可するかどうかをチェックします。

インターネット上の誰でも S3 バケットに書き込みできるようにお客様が明示的にリクエストしない限り、S3 バケットがパブリックに書き込み可能ではないことを確認する必要があります。

IAM ロールなどの内部プリンシパルによるバケットへの読み取りアクセス権はチェックされません。バケットへのアクセスは、認可されたプリンシパルのみに制限する必要があります。

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 1.2.1: インバウンドおよびアウトバウンドトラフィックを、カード所有者データ環境 (CDE) に必要なトラフィックに制限し、それ以外のトラフィックを明確に拒否する。

S3 バケットを使用してカード所有者データを保存する場合、バケットはパブリック読み取りアクセスを禁止する必要があります。パブリック読み取りアクセスは、CDE との間で必要なトラフィックのみを許可するという要件に違反する可能性があります。

PCI DSS 1.3.1: DMZ を実装して、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限する。

S3 バケットを使用してカード所有者データを保存する場合、バケットはパブリック読み取りアクセスを禁止する必要があります。パブリック読み取りアクセスは、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限するという要件に違反する可能性があります。

PCI DSS 1.3.2: インバウンドインターネットトラフィックを DMZ 内の IP アドレスに制限する。

S3 バケットを使用してカード所有者データを保存する場合、バケットはパブリック読み取りアクセスを禁止する必要があります。パブリック読み取りアクセスは、インバウンドインターネットトラフィックを DMZ 内の IP アドレスに制限するという要件に違反する可能性があります。

PCI DSS 1.3.6: カード所有者データを保存するシステムコンポーネント (データベースなど) は、DMZ やその他の信頼できないネットワークから分離された内部ネットワークゾーンに配置する。

S3 バケットを使用してカード所有者データを保存する場合、バケットはパブリック読み取りアクセスを禁止する必要があります。パブリック読み取りアクセスは、カード所有者データを保存するシステムコンポーネントを、DMZ やその他の信頼できないネットワークから分離された内部ネットワークゾーンに配置するという要件に違反する可能性があります。

PCI DSS 7.2.1: システムコンポーネントのアクセス制御システムを確立することにより、ユーザーの必要性に基づいてアクセスを制限し、明示的に許可していない限り「すべて拒否」に設定する。このアクセス制御システムは、すべてのシステムコンポーネントを対象に含んでいる必要がある。

S3 バケットを使用してカード所有者データを保存する場合、バケットはパブリック読み取りアクセスを禁止する必要があります。パブリック読み取りアクセスは、システムコンポーネントへのアクセスを必要な最小特権に、またはユーザーの必要性に基づいて制限するという要件に違反する可能性があります。

修正

S3 バケットに対するパブリックアクセスを削除するには

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

  2. 結果で特定されたバケットの名前を選択します。

  3. [Permissions] (許可) を選択し、[Public access settings] (パブリックアクセス設定) を選択します。

  4. [Edit] (編集) を選択し、4 つのオプションをすべて選択して、次に [Save] (保存) を選択します。

  5. プロンプトが表示されたら、confirm を入力して [Confirm] (確認) を選択します。

[PCI.S3.3] S3 バケットでクロスリージョンレプリケーションを有効にする必要がある

重要度:

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

AWS Config ルール: s3-bucket-replication-enabled

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

パラメータ : なし

このコントロールは S3 バケットでクロスリージョンレプリケーションが有効かどうかをチェックします。

PCI DSS では、データレプリケーションや高可用性の設定は必要ではありません。ただし、このチェックは、AWS のこのコントロールのベストプラクティスと一致するものです。

可用性に加えて、他のシステム強化構成も考慮する必要があります。

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 2.2: すべてのシステムコンポーネントについて、設定基準を作成する。この基準は、すべての既知のセキュリティ脆弱性に対処し、業界で受け入れられているシステム強化基準に準拠するものである必要がある。

S3 バケットでクロスリージョンレプリケーションを有効にすると、異なる個別のリージョンで複数のバージョンのデータを使用できるようになります。これにより、さらに離れた場所へのデータの保存、レイテンシーの最小化、運用効率の向上、DDoS やデータ破損のイベントからの保護が可能になります。

これは、システム強化設定の実装に使用される方法の 1 つです。

修正

S3 バケットのレプリケーションを有効にするには

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

  2. クロスリージョンレプリケーションが有効になっていない S3 バケットを選択します。

  3. [Management] (管理) を選択し、[Replication] (レプリケーション) を選択します。

  4. [Add rule] (ルール追加) を選択します。バージョニングがまだ有効になっていない場合は、有効にするよう求められます。

  5. レプリケート元バケットを選択します - [Entire bucket] (バケット全体)。

  6. レプリケート先バケットを選択します。お使いのアカウントのレプリケート先バケットでバージョニングがまだ有効になっていない場合は、有効にするよう求められます。

  7. IAM ロールを選択します。レプリケーションの許可の設定の詳細については、「Amazon Simple Storage Service ユーザーガイド」を参照してください。

  8. ルール名を入力し、ステータスで [Enabled] (有効) を選択し、[Next] (次へ) を選択します。

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

レプリケーションの詳細については、「Amazon Simple Storage Service ユーザーガイド」を参照してください。

[PCI.S3.4] S3 バケットでは、サーバー側の暗号化を有効にする必要がある

重要度:

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

AWS Config ルール: s3-bucket-server-side-encryption-enabled

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

パラメータ : なし

このコントロールは、Amazon S3 バケットで Amazon S3 のデフォルトの暗号化が有効になっているか、または S3 バケットポリシーでサーバー側の暗号化なしの put-object リクエストを明示的に拒否しているかのいずれかであることを確認します。

バケットにデフォルトの暗号化を設定すると、バケットに保存されるすべての新規オブジェクト (クリアテキストの PAN データを含む) が保存時に暗号化されます。

バケットポリシーを使用して、バケットに保存されているすべてのオブジェクトに対してサーバー側の暗号化を適用することもできます。サーバー側の暗号化の詳細については、「Amazon Simple Storage Service ユーザーガイド」を参照してください。

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 3.4: プライマリアカウント番号 (PAN) を、すべての保存場所で読み取り不能にする (ポータブルデジタルメディア、バックアップメディア、およびログ内を含む)。

S3 バケットを使用してクレジットカードのプライマリアカウント番号 (PAN) を保存している場合に、PAN を読み取れないようにするには、バケットのデフォルトの暗号化を有効にするか、または S3 バケットポリシーでサーバー側の暗号化なしの put-object リクエストを明示的に拒否する必要があります。

修正

S3 バケットのデフォルト暗号化を有効にするには

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

  2. リストからバケットを選択します。

  3. [プロパティ] を選択します。

  4. [Default encryption (デフォルトの暗号化)] で、[Edit (編集)] を選択します。

  5. [Enable] (有効化) を選択し、サーバー側暗号化をオンにします。次に、[SSE-S3] または [SSE-KMS] のいずれかを選択します。

    • デフォルトの暗号化に、Amazon S3 が管理するキーを使用するときは、[SSE-S3] を選択します。Amazon S3 サーバー側暗号化を使用してデータを暗号化する方法の詳細については、「Amazon Simple Storage Service ユーザーガイド」を参照してください。

    • デフォルトの暗号化に、AWS KMS が管理するキーを使用するときは、[SSE-KMS] を選択します。次に、作成した AWS KMS マスターキーのリストからマスターキーを選択します。

      [SSE-KMS] を選択する場合、使用する AWS KMS キーの Amazon リソースネーム (ARN) を入力します。IAM コンソールの [Encryption keys] (暗号化キー) で、AWS KMS キーの ARN を確認できます。または、ドロップダウンリストからキー名を選択できます。

      重要

      デフォルト暗号化設定に AWS KMS オプションを使用する場合、AWS KMS の RPS (1 秒あたりのリクエスト) 制限が適用されます。AWS KMS の制限の概要と制限の引き上げをリクエストする方法については、「AWS Key Management Service 開発者ガイド」を参照してください。

      AWS KMS キーの作成方法の詳細については、「AWS Key Management Service 開発者ガイド」を参照してください。

      Amazon S3 で AWS KMS を使用する方法の詳細については、「Amazon Simple Storage Service ユーザーガイド」を参照してください。

    デフォルト暗号化を有効にする際、バケットポリシーの更新が必要な場合があります。バケットポリシーからデフォルトの暗号化に移行する方法の詳細については、「Amazon Simple Storage Service ユーザーガイド」を参照してください。

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

デフォルトの S3 バケット暗号化の詳細については、「Amazon Simple Storage Service ユーザーガイド」を参照してください。

[PCI.S3.5] S3 バケットは Secure Socket Layer を使用するリクエストを要求する必要がある

重要度:

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

AWS Config ルール: s3-bucket-ssl-requests-only

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

パラメータ : なし

このコントロールは、Amazon S3 バケットに Secure Socket Layer (SSL) を使用するリクエストを要求するポリシーがあるかどうかを確認します。

S3 バケットには、条件キー aws:SecureTransport によって示される S3 リソースポリシーで HTTPS 経由のデータ送信のみを受け入れるために、すべてのリクエスト (Action: S3:*) を要求するポリシーを備える必要があります。

SSL または TLS のバージョンはチェックされません。PCI DSS の要件に従い、SSL または TLS の初期のバージョン (SSLv3、TLS1.0) を許可すべきではありません。

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 4.1 オープンなパブリックネットワークで機密性の高いカード所有者データを送信する際に、強力な暗号化とセキュリティプロトコルを使用してデータを保護する。

S3 バケットを使用してカード所有者データを保存する場合、バケットポリシーでバケットへのリクエストが HTTPS 経由のデータ転送のみを受け入れるようにする必要があります。例えば、ポリシーステートメント "aws:SecureTransport": "false" を使用して、HTTPS 経由でアクセスされていないリクエストを拒否します。カード所有者データの暗号化されていない送信を許可すると、オープンなパブリックネットワークで機密性の高いカード所有者データを送信する際に、強力な暗号化とセキュリティプロトコルを使用してデータを保護するという要件に違反する可能性があります。

修正

この問題を修正するには、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] を選択します。

詳細については、ナレッジセンターの記事「AWS Config ルール s3-bucket-ssl-requests-only に準拠するには、どの S3 バケットポリシーを使用する必要がありますか?」を参照してください。

[PCI.S3.6] S3 パブリックアクセスブロック設定を有効にする必要がある

重要度:

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

AWS Config ルール: s3-account-level-public-access-blocks-periodic

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

パラメータ:

  • ignorePublicAcls: true

  • blockPublicPolicy: true

  • blockPublicAcls: true

  • restrictPublicBuckets: true

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

  • ignorePublicAcls: true,

  • blockPublicPolicy: true

  • blockPublicAcls: true

  • restrictPublicBuckets: true

すべてのパブリックアクセスブロック設定が true に設定されている場合、コントロールは成功します。

いずれかの設定が false に設定されているか、またはいずれかが設定されていない場合、コントロールは失敗します。

AWS のベストプラクティスとして、S3 バケットはパブリックアクセスをブロックすべきです。インターネット上の誰でも S3 バケットにアクセスできるようにお客様が明示的にリクエストしない限り、S3 バケットがパブリックアクセス可能ではないことを確認する必要があります。

注記

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

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

  • ヨーロッパ (ミラノ)

  • 中東 (バーレーン)

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 1.2.1 - インバウンドおよびアウトバウンドトラフィックを、カード所有者データ環境 (CDE) に必要なトラフィックに制限し、それ以外のトラフィックを明確に拒否する。

S3 バケットを使用してカード所有者データを保存する場合は、バケットがパブリックアクセスを許可していないことを確認してください。S3 バケットへのパブリックアクセスは、CDE との間で必要なトラフィックのみを許可するという要件に違反する可能性があります。

PCI DSS 1.3.1 - DMZ を実装して、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限する。

S3 バケットを使用してカード所有者データを保存する場合は、バケットがパブリックアクセスを許可していないことを確認してください。S3 バケットへのパブリックアクセスを許可すると、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限するという要件に違反する可能性があります。

PCI DSS 1.3.2 - インバウンドインターネットトラフィックを DMZ 内の IP アドレスに制限する。

S3 バケットを使用してカード所有者データを保存する場合は、バケットがパブリックアクセスを許可していないことを確認してください。S3 バケットへのパブリックアクセスを許可すると、インバウンドインターネットトラフィックを DMZ 内の IP アドレスに制限するという要件に違反する可能性があります。

PCI DSS 1.3.4 - カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックを許可しない。

S3 バケットを使用してカード所有者データを保存する場合は、バケットがパブリックアクセスを許可していないことを確認してください。S3 バケットへのパブリックアクセスを許可すると、カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックをブロックするという要件に違反する可能性があります。

PCI DSS 1.3.6: カード所有者データを保存するシステムコンポーネント (データベースなど) は、DMZ やその他の信頼できないネットワークから分離された内部ネットワークゾーンに配置する。

S3 バケットを使用してカード所有者データを保存する場合は、バケットがパブリックアクセスを許可していないことを確認してください。S3 バケットへのパブリックアクセスを許可すると、カード所有者データを保存するシステムコンポーネントを、DMZ やその他の信頼できないネットワークから分離された内部ネットワークゾーンに配置するという要件に違反する可能性があります。

修正

Amazon S3 ブロックパブリックアクセスを有効にするには

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

  2. ナビゲーションペインで、[Block public access (account settings)] (パブリックアクセスのブロック (アカウント設定)) を選択します。

  3. [Edit] を選択します。[Block all public access] (すべてのパブリックアクセスをブロック) を選択します。

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

詳細については、「Amazon Simple Storage Service ユーザーガイド」の「Amazon S3 ブロックパブリックアクセスの使用」を参照してください。

[PCI.SageMaker.1] Amazon SageMaker ノートブックインスタンスは、インターネットに直接アクセスできないようにする必要がある

重要度:

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

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

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

パラメータ : なし

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

VPC なしで SageMaker インスタンスを設定した場合、デフォルトではインスタンスでインターネットへの直接アクセスが有効になっています。VPC 有りでインスタンスを設定し、デフォルト設定を [Disable — Access the internet through a VPC] (無効化 - VPC 経由でインターネットにアクセスする) に変更する必要があります。

ノートブックからモデルをトレーニングまたはホストするには、インターネットアクセスが必要です。インターネットアクセスを有効にするには、VPC に NAT ゲートウェイがあり、セキュリティグループでアウトバウンド接続を許可していることを確認してください。ノートブックインスタンスを VPC 内のリソースに接続する方法の詳細については、「Amazon SageMaker 開発者ガイド」の「ノートブックインスタンスを VPC 内のリソースに接続する」を参照してください。

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

注記

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

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

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

  • 中国 (北京)

  • 中国 (寧夏)

  • ヨーロッパ (ミラノ)

  • AWS GovCloud (米国東部)

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 1.2.1 - インバウンドおよびアウトバウンドトラフィックを、カード所有者データ環境 (CDE) に必要なトラフィックに制限し、それ以外のトラフィックを明確に拒否する。

CDE 内で SageMaker ノートブックインスタンスを使用する場合、ノートブックインスタンスが直接のインターネットアクセスを許可していないことを確認してください。ノートブックインスタンスに直接のパブリックアクセスを許可すると、CDE との間で必要なトラフィックのみを許可するという要件に違反する場合があります。

PCI DSS 1.3.1 - DMZ を実装して、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限する。

CDE 内で SageMaker ノートブックインスタンスを使用する場合、ノートブックインスタンスが直接のインターネットアクセスを許可していないことを確認してください。ノートブックインスタンスに直接のパブリックアクセスを許可すると、パブリックにアクセスできる認可済みのサービス、プロトコル、およびポートを提供するシステムコンポーネントのみへのインバウンドトラフィックに制限するという要件に違反する可能性があります。

PCI DSS 1.3.2 - インバウンドインターネットトラフィックを DMZ 内の IP アドレスに制限する。

CDE 内で SageMaker ノートブックインスタンスを使用する場合、ノートブックインスタンスが直接のインターネットアクセスを許可していないことを確認してください。ノートブックインスタンスに直接のパブリックアクセスを許可すると、インバウンドトラフィックを DMZ 内の IP アドレスに制限するという要件に違反する可能性があります。

PCI DSS 1.3.4 - カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックを許可しない。

CDE 内で SageMaker ノートブックインスタンスを使用する場合、ノートブックインスタンスが直接のインターネットアクセスを許可していないことを確認してください。ノートブックインスタンスに直接のパブリックアクセスを許可すると、カード所有者データ環境からインターネットへの認可されていないアウトバウンドトラフィックをブロックするという要件に違反する可能性があります。

PCI DSS 1.3.6: カード所有者データを保存するシステムコンポーネント (データベースなど) は、DMZ やその他の信頼できないネットワークから分離された内部ネットワークゾーンに配置する。

SageMaker ノートブックインスタンスを使用していて、ノートブックインスタンスにカード所有者のデータが含まれている場合は、直接のインターネットアクセスを制限します。ノートブックインスタンスに直接のパブリックアクセスを許可すると、カード所有者データを保存するシステムコンポーネントを、DMZ やその他の信頼できないネットワークから分離された内部ネットワークゾーンに配置するという要件に違反する可能性があります。

修正

ノートブックインスタンスの作成後は、インターネットアクセス設定を変更できないことに注意してください。停止、削除、再作成する必要があります。

直接のインターネットアクセスを拒否するように SageMaker ノートブックインスタンスを設定するには

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

  2. [Notebook instances] (ノートブックインスタンス) に移動します。

  3. インターネットへの直接のアクセスが有効になっているインスタンスを削除します。インスタンスを選択し、[Actions] (アクション)、[stop] (停止) の順に選択します。

    インスタンスの停止後、[Actions] (アクション)、[delete] (削除) の順に選択します。

  4. [Create notebook instance] (ノートブックインスタンスの作成) を選択します。設定の詳細を入力します。

  5. [Network] (ネットワーク) セクションを展開します。次に、VPC、サブネット、セキュリティグループを選択します。[Direct internet access] (直接のインターネットアクセス) で、[Disable — Access the internet through a VPC] (無効化 - VPC 経由でインターネットにアクセスする) を選択します。

  6. [Create notebook instance] (ノートブックインスタンスの作成) を選択します。

詳細については、「Amazon SageMaker 開発者ガイド」の「ノートブックインスタンスを VPC 内のリソースに接続する」を参照してください。

[PCI.SSM.1] Systems Manager によって管理される Amazon EC2 インスタンスは、パッチのインストール後に、パッチコンプライアンスのステータスが COMPLIANT である必要がある

重要度:

リソースタイプ: AWS::SSM::PatchCompliance および AWS::EC2::Instance

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

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

パラメータ : なし

このコントロールは、インスタンスへのパッチインストール後、Amazon EC2 Systems Manager パッチコンプライアンスのコンプライアンスステータスが、COMPLIANTNON_COMPLIANT のどちらであるかをチェックします。

AWS Systems Manager Patch Manager によって管理されているインスタンスのみがチェックされます。

PCI DSS 要件 6.2 で規定されている、30 日間の期限内にパッチが適用されたかどうかはチェックされません。

また、適用されたパッチがセキュリティパッチとして分類されていたかどうかも検証しません。

適切なベースライン設定を使用してパッチグループを作成し、対象のシステムが Systems Manager でこれらのパッチグループによって管理されていることを確認する必要があります。パッチグループの詳細については、「AWS Systems Manager ユーザーガイド」を参照してください。

注記

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

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

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

  • ヨーロッパ (ミラノ)

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 6.2: すべてのシステムコンポーネントとソフトウェアに、ベンダーが提供する該当するセキュリティパッチがインストールされ、既知の脆弱性から保護されていることを確認する。重要なセキュリティパッチは、公開から 1 か月以内にインストールする。

PCI DSS の対象となるシステムに対してベンダーがリリースしたパッチは、本稼働環境にインストールする前にテストおよび検証される必要があります。デプロイ後は、デプロイされたパッチがカード所有者データ環境 (CDE) のセキュリティに影響を与えないように、セキュリティ設定とコントロールを検証する必要があります。

AWS Systems Manager Patch Manager で管理されている Amazon EC2 インスタンスを使用して CDE 内のマネージドインスタンスにパッチを適用する場合、パッチが正常に適用されたことを確認します。そのためには、Amazon EC2 Systems Manager パッチコンプライアンスのコンプライアンスステータスが「COMPLIANT」であることをチェックします。Patch Manager は、オペレーティングシステムとアプリケーションの両方に適用可能なパッチを適用できます。

これは、既知の脆弱性からシステムコンポーネントとソフトウェアを保護するために使用される方法です。

修正

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

このルールは、Amazon EC2 Systems Manager パッチコンプライアンスのコンプライアンスステータスが COMPLIANT と NON_COMPLIANT のどちらであるかをチェックします。パッチコンプライアンスステータスの詳細については、「AWS Systems Manager ユーザーガイド」を参照してください。

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

  2. ナビゲーションペインの [Node Management] (ノード管理) で、[Run Command] (コマンドを実行) を選択します。

  3. [Run command] (コマンドの実行) を選択します。

  4. AWS-RunPatchBaseline の横にあるラジオボタンを選択し、[Operation] (オペレーション) を [Install] (インストール) に変更します。

  5. [Choose instances manually] (インスタンスを手動で選択) を選択し、非準拠のインスタンスを選択します。

  6. 一番下までスクロールし、[Run] (実行) を選択します。

  7. コマンドの完了後、パッチを適用したインスタンスの新しいコンプライアンスステータスをモニタリングするには、ナビゲーションペインで [Compliance] (コンプライアンス) を選択します。

以下については、「AWS Systems Manager ユーザーガイド」を参照してください。

[PCI.SSM.2] Systems Manager によって管理されるインスタンスの関連付けコンプライアンスのステータスは COMPLIANT である必要がある

重要度:

リソースタイプ: AWS::SSM::AssociationCompliance

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

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

パラメータ : なし

このコントロールは、インスタンスで関連付けが実行された後、AWS Systems Manager 関連付けのコンプライアンスのステータスが COMPLIANT または NON_COMPLIANT であるかどうかをチェックします。関連付けのコンプライアンスステータスが COMPLIANT の場合、コントロールは成功します。

State Manager の関連付けは、マネージドインスタンスに割り当てられる設定です。この設定では、インスタンスで維持する状態を定義します。例えば、アンチウイルスソフトウェアをインスタンス上にインストールして実行する必要があることや、特定のポートを閉じる必要があることを関連付けで指定できます。

State Manager の関連付けを 1 つまたは複数作成すると、コンソールで、または AWS CLI コマンドや対応する Systems Manager API オペレーションへのレスポンスとして、コンプライアンスステータス情報をすぐに表示できるようになります。関連付けに関して、[Configuration Compliance] (設定コンプライアンス) では [Compliant] (準拠) または [Non-compliant] (非準拠) のステータス、および [Critical] (非常事態) や [Medium] (中) といった関連付けに割り当てられた重要度レベルが表示されます。State Manager 関連付けのコンプライアンスの詳細については、「AWS Systems Manager ユーザーガイド」の「State Manager 関連付けのコンプライアンスについて」を参照してください。

対象範囲内の EC2 インスタンスを、Systems Manager 関連付けに対して設定する必要があります。また、パッチベンダーのセキュリティ評価に関してパッチベースラインを設定し、自動承認日を PCI DSS 3.2.1 の要件 6.2 を満たすように設定する必要があります。関連付けの作成方法に関する追加のガイダンスについては、「AWS Systems Manager ユーザーガイド」の「関連付けの作成」を参照してください。Systems Manager でのパッチ適用に関する追加情報については、「AWS Systems Manager ユーザーガイド」の「AWS Systems Manager Patch Manager」を参照してください。

注記

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

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

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

  • ヨーロッパ (ミラノ)

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 2.4: PCI DSS の対象範囲であるシステムコンポーネントのインベントリを維持する。

Systems Manager によって管理される EC2 インスタンスを使用して、カード所有者データ環境 (CDE) のインベントリを収集する場合は、インスタンスが正常に関連付けられていることを確認してください。そのためには、Systems Manager 関連付けコンプライアンスのコンプライアンスステータスが COMPLIANT であるかどうかをチェックします。Systems Manager を使用すると、PCI DSS の対象範囲であるシステムコンポーネントのインベントリを維持するのに役立ちます。インベントリの整理方法に関する追加のガイダンスについては、「AWS Systems Manager ユーザーガイド」の「インベントリのリソースデータの同期の設定」を参照してください。

修正

失敗した関連付けは、ターゲットや SSM ドキュメント名など、さまざまなものに関連している可能性があります。この問題を修正するには、まず関連付けを特定して調査する必要があります。その後、関連付けを更新して、特定の問題を修正できます。

関連付けを編集して、新しい名前やスケジュール、重要度レベル、ターゲットを指定できます。関連付けを編集した後、Systems Manager で新しいバージョンが作成されます。

失敗した関連付けを調査して更新するには

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

  2. ナビゲーションペインで、[Node Management] (ノード管理) の [Fleet Manager] (フリートマネージャー) を選択します。

  3. [Association status] (関連付けのステータス) が [Failed] (失敗) のインスタンス ID を選択します。

  4. [View details] (詳細を表示する) を選択します。

  5. [Association] (関連付け) を選択します。

  6. [Association status] (関連付けのステータス) が [Failed] (失敗) の関連付けの名前を書き留めておきます。これはユーザーが調査する必要のある関連付けです。関連付けの名前は、次のステップで使用する必要があります。

  7. ナビゲーションペインで、[Node Management] (ノード管理) の [State Manager] (ステートマネージャー) を選択します。関連付け名を検索し、関連付けを選択します。

    問題を特定した後、失敗した関連付けを編集して問題を修正します。関連付けの編集方法の詳細については、「関連付けを編集する」を参照してください。

State Manager の関連付けの作成と編集の詳細については、「AWS Systems Manager ユーザーガイド」の「Systems Manager の関連付けの使用」を参照してください。

[PCI.SSM.3] EC2 インスタンスは AWS Systems Manager により管理される必要がある

重要度:

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

AWS Config ルール: ec2-instance-managed-by-systems-manager

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

パラメータ : なし

このコントロールは、アカウント内の EC2 インスタンスが Systems Manager によって管理されているかどうかを確認します。

AWS Systems Manager は、AWS インフラストラクチャを表示および管理するために使用できる AWS サービスです。セキュリティとコンプライアンスを維持するために、Systems Manager はマネージドインスタンスをスキャンします。マネージドインスタンスとは、Systems Manager で使用するために設定されたマシンです。Systems Manager が検出したポリシー違反について報告または是正処置を講じます。Systems Manager は、マネージドインスタンスの設定と維持管理にも役立ちます。マネージド EC2 インスタンスにパッチをデプロイするには、Systems Manager で追加の設定が必要です。

詳細については、「AWS Systems Manager ユーザーガイド」を参照してください。

関連する PCI DSS 要件

このコントロールは、次の PCI DSS 要件に関連しています。

PCI DSS 2.4: PCI DSS の対象範囲であるシステムコンポーネントのインベントリを維持する。

Systems Manager によって管理される EC2 インスタンスを使用して、カード所有者データ環境 (CDE) のインベントリを収集する場合は、インスタンスが Systems Manager によって管理されていることを確認してください。Systems Manager を使用すると、PCI DSS の対象範囲であるシステムコンポーネントのインベントリを維持するのに役立ちます。インベントリの整理方法に関する追加のガイダンスについては、「AWS Systems Manager ユーザーガイド」の「インベントリのリソースデータの同期の設定」を参照してください。

PCI DSS 6.2: すべてのシステムコンポーネントとソフトウェアに、ベンダーが提供する該当するセキュリティパッチがインストールされ、既知の脆弱性から保護されていることを確認する。重要なセキュリティパッチは、公開から 1 か月以内にインストールする。

PCI DSS の対象範囲となるシステムに関して、ベンダーのパッチは、本稼働環境にインストールする前にテストおよび検証される必要があります。パッチをデプロイした後、セキュリティ設定とコントロールを検証して、デプロイされたパッチが CDE のセキュリティに影響を与えないことを確認します。Systems Manager によって管理される EC2 インスタンスを使用して CDE 内のマネージドインスタンスにパッチを適用する場合は、インスタンスが Systems Manager で管理されていることを確認してください。Systems Manager は、既知の脆弱性からシステムコンポーネントとソフトウェアを保護するのに役立つシステムパッチをデプロイします。

修正

Systems Manager クイックセットアップを使用して、EC2 インスタンスを管理するように Systems Manager を設定できます。

インスタンスが Systems Manager の関連付けをサポートできるかどうかを確認するには、「AWS Systems Manager ユーザーガイド」の「Systems Manager の前提条件」を参照してください。

EC2 インスタンスが Systems Manager によって管理されていることを確認するには

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

  2. ナビゲーションペインで、[Quick setup] (クイックセットアップ) を選択します。

  3. 設定画面で、デフォルトのオプションをそのまま使用します。

  4. [Set up Systems Manager] (Systems Manager の設定) を選択します。