この記事では、Payment Card Industry Data Security Standard (PCI-DSS 3.2.1) に準拠してワークロードを実行する Azure Kubernetes Service (AKS) クラスターの考慮事項について説明します。
この記事はシリーズの一部です。 概要を参照してください。
重要
ガイダンスと付随する実装は、AKS ベースライン アーキテクチャに基づいています。 このアーキテクチャは、ハブアンドスポーク トポロジがベースとなっています。 ハブ仮想ネットワークには、エグレス トラフィック、オンプレミスのネットワークからのゲートウェイ トラフィック、およびメンテナンス用の 3 つ目のネットワークを制御するファイアウォールが含まれています。 スポーク仮想ネットワークには、カード所有者データ環境 (CDE) を提供し、PCI DSS ワークロードをホストする AKS クラスターが含まれています。
GitHub: 規制対象ワークロード向け Azure Kubernetes Service (AKS) ベースライン クラスターでは、規制された環境の実例を説明しています。 その実装で、Azure Monitor のさまざまな機能を介した監査証跡の使用を示しています。 クラスター内のネットワーク テスト ポイントと、クラスター サブネットとやり取りするリソースの例があります。
ネットワークを定期的に監視およびテストする
要件 10 - ネットワーク リソースとカード所有者データへのすべてのアクセスを追跡して監視する
AKS 機能のサポート
Azure では、AKS クラスターなどのコンテナーを監視するコンテナー分析情報機能が提供されています。 詳細については、「Container insights の概要」を参照してください。
AKS により、システムとデータを積極的に保護するのに役立つ監査ログが複数のレベルで提供されます。 アクティビティ ログは、アカウントとシークレットの管理に関連する操作の管理、診断設定の管理、サーバー管理、その他のリソース アクセス操作に関する情報を提供します。 すべてのログには、日付、時刻、ID、その他の詳細情報が記録されます。 また、AKS クラスターに対して行われたすべての API 呼び出しの時系列レコードすべてにアクセスできます。 ログには、呼び出し元、呼び出しが実行された時刻、呼び出しが開始されたソースなどに関する情報が含まれます。 詳細については、「Azure Kubernetes Service (AKS) で Kubernetes コントロール プレーンのログを有効にして表示する」を参照してください。
Azure での標準的な手法としてリソースのアクセス ポリシーを管理するために、RBAC (ロールベースのアクセス制御) を使用できます。
すべてのログは、顧客所有のストレージ アカウントまたは Azure Monitor ログに格納する必要があります。 そうすることで、大量のデータから分析情報をすばやく生成できます。 すべてのログは、1 つのリージョンに少なくとも 3 つのコピーで保持されます。 リージョン間のバックアップまたはレプリケーションを有効にすることで、より多くのコピーを保持できます。 すべてのログ エントリは、セキュリティで保護された HTTP (HTTPS) チャネルを介してのみ使用できます。
Azure のアラート フレームワークを使用すると、疑わしいアクセスを検出するようにアラートを構成できます。 作動させる必要があるアラートと、イベントを設定できます。 ユーザーは、アクティビティの種類、アクティビティの内容、またはアクティビティの呼び出し元に基づくフィルター機能を備えた Log Analytics を使用して完全なログを手動で確認することもできます。
お客様の責任
| 要件 | 担当 |
|---|---|
| 要件 10.1 | システム コンポーネントへのすべてのアクセスを各ユーザーにリンクする監査証跡を実装します。 |
| 要件 10.2 | 次のイベントを再現するために、すべてのシステム コンポーネントの自動監査証跡を実装します。 |
| 要件 10.3 | イベントごとに、すべてのシステム コンポーネントについて少なくとも次の監査証跡エントリを記録します。 |
| 要件 10.4 | 時刻同期テクノロジを使用してすべての重要なシステム クロックと時刻を同期し、時刻の取得、配布、格納のために以下を確実に実装します。 |
| 要件 10.5 | 変更できないよう監査証跡をセキュリティで保護します。 |
| 要件 10.6 | すべてのシステム コンポーネントのログとセキュリティ イベントを調べ、異常または疑わしいアクティビティを特定します。 |
| 要件 10.7 | 監査証跡の履歴を少なくとも 1 年間保持し、少なくとも 3 か月はすぐに分析できる状態にしておきます (オンライン、アーカイブ、バックアップから復元可能など)。 |
| 要件 10.8 | サービス プロバイダーのみの追加要件: すべての重要なセキュリティ制御の障害に適切なタイミングで対応します。 セキュリティ制御の障害に対応するためのプロセスには以下を含む必要があります |
| 要件 10.9 | ネットワーク リソースとカード所有者データへのすべてのアクセスを監視するためのセキュリティ ポリシーと運用手順を文書化して、使用し、すべての関係者に通知することを徹底します。 |
要件 11 - セキュリティ システムとプロセスを定期的にテストする
AKS 機能のサポート
AKS は、Azure の監視サービスと統合されています。
Microsoft Defender for Containers では、多くのセキュリティ スキャン機能が提供されています。 たとえば、Defender for Containers では、プルされたイメージ、プッシュされたイメージ、コンテナー レジストリにインポートされたイメージがスキャンされ、推奨事項が提供されます。 詳細については、「脆弱性評価」を参照してください。
Azure Monitor を使用すると、システムの整合性とセキュリティを保護するために、イベントの種類に基づいてアラートを設定できます。 AKS ノードで想定されたシステム障害が発生した場合、AKS はシステム処理を中断することなく、適切なタイミングでリソースを自動回復します。
AKS クラスターは、Azure Application Gateway と Web アプリケーション ファイアウォール (WAF) によって保護され、アラートと脅威をログに記録するように検出モードで構成できます。 より強力なモードは予防モードです。これにより、検出された侵入や攻撃が積極的にブロックされます。 詳細については、「Azure Kubernetes Service (AKS) でのネットワーク接続とセキュリティに関するベスト プラクティス」を参照してください。
お客様の責任
| 要件 | 担当 |
|---|---|
| 要件 11.1 | ワイヤレス アクセス ポイント (802.11) の存在をテストし、四半期ごとにすべての承認済みおよび承認されていないワイヤレス アクセス ポイントを検出および特定するプロセスを実装します。 |
| 要件 11.2 | 内部および外部ネットワークの脆弱性スキャンを、少なくとも四半期に 1 回と、ネットワークの大幅な変更 (新しいシステム コンポーネントのインストール、ネットワーク トポロジの変更、ファイアウォール規則の変更、製品のアップグレードなど) 後に実行します。 |
| 要件 11.3 | 以下を含む侵入テストの方法を実装します。 |
| 要件 11.4 | 侵入検出や侵入防止の手法を使用して、ネットワークへの侵入の検出や防止を行います。 |
| 要件 11.5 | 変更検出メカニズム (ファイルの整合性監視ツールなど) をデプロイして、重要なシステム ファイル、構成ファイル、コンテンツ ファイルの無許可の改変 (変更、追加、削除を含む) を担当者に通知します。また、重要なファイルの比較を少なくとも毎週実行するようにソフトウェアを構成します。 |
| 要件 11.6 | セキュリティ ポリシーおよびセキュリティの監視とテストに関する運用手順を文書化して、使用し、すべての関係者に通知することを徹底します。 |
要件 10.1
システム コンポーネントへのすべてのアクセスを各ユーザーにリンクする監査証跡を実装します。
お客様の責任
次の方法を使用して、各コンポーネントで実行される監査操作を使用することをお勧めします。
Azure Monitor アクティビティ ログ。 アクティビティ ログでは、Azure リソースの操作の種類と時刻に関する情報が提供されます。 また、操作を開始した ID もログされます。 既定で有効になっているため、リソース操作が実行されるとすぐに情報が収集されます。 監査証跡は書き込み専用であり、削除できません。
データは 90 日間保持されます。 保持期間を長くする場合は、アクティビティ ログ エントリを Azure Monitor ログに送信することを検討し、保持とアーカイブのポリシーを構成してください。
Azure 診断設定。 Azure リソースと設定が適用されるプラットフォームの診断および監査の情報を提供します。 AKS やシステム内のその他のコンポーネント (Azure Blob Storage や Key Vault など) に対して診断設定を有効にすることをお勧めします。 リソースの種類に基づいて、送信先に送信するログとメトリック データの種類を選択できます。 診断の送信先は、必要な保持期間を満たす必要があります。
AKS の診断設定。 指定された AKS カテゴリから、Kubernetes 監査ログを有効にします。 診断設定には、
kube-auditまたはkube-audit-admin、およびguardが含まれます。クラスターの状態を変更する可能性があるログ ベースの API サーバー呼び出しを確認するには、
kube-audit-adminを有効にします。 すべての API サーバーの操作 (読み取り要求などの変更しないイベントを含む) の監査証跡が必要な場合は、代わりにkube-auditを有効にします。 これらのイベントは大量になり、ノイズをもたらして、従量課金コストを増大させる可能性があります。 これらのログには、要求の作成に使用されるアクセスと ID 名に関する情報が含まれます。マネージド Microsoft Entra ID と Azure ロールベースのアクセス制御 (RBAC) の監査を追跡するには、
guardログを有効にします。
ユーザーベースのログに加えて、
kube-apiserverやkube-controller-managerなど、Kubernetes コントロール プレーンからのログを検討してください。 これらのログは通常、ユーザーに関連付けられていませんが、ユーザーが行ったシステム変更を関連付けるのに役立ちます。詳細については、コントロール プレーン コンポーネントのログを表示するに関するページを参照してください。
このリファレンス実装では、
cluster-autoscaler、kube-controller-manager、kube-audit-admin、guardログを有効にし、Log Analytics ワークスペースに転送します。 ワークスペース保持期間は 90 日に設定されます。
Azure Kubernetes Service (AKS) 診断は、ノード障害などのクラスターに関する問題の検出とトラブルシューティングに役立ちます。 また、ネットワーク固有の診断データも含まれます。追加コストはかかりません。 このデータは通常、ユーザーに関連付けられていませんが、ユーザーが行ったシステム変更を関連付けるのに役立ちます。 詳細については、Azure Kubernetes Service 診断に関するページを参照してください。
前述の監査証跡メカニズムは、リソースのデプロイ時に実装されている必要があります。 また、CDE でこれらの構成が誤ってまたは悪意を持って無効にされないように、Azure Policy がアクティブになっている必要があります。
要件 10.2
次のイベントを再現するために、すべてのシステム コンポーネントの自動監査証跡を実装します。
- 10. 2.1. カード会員データへのすべての個人アクセス
- 10.2.2 ルートまたは管理者特権を持つ個人によって行われたすべてのアクション
- 10.2.3 すべての監査証跡へのアクセス
- 10.2.4 無効な論理アクセス試行
- 10.2.5 識別と認証メカニズムの使用および変更 (新しいアカウントの作成、特権の昇格を含むがこれらに限定されない)、およびルートまたは管理者特権を持つアカウントの変更、追加、削除のすべて
- 10.2.6 監査ログの初期化、停止、または一時停止
- 10.2.7 システムレベル オブジェクトの作成および削除
お客様の責任
AKS では、「要件 10.1」に記載されているように、複数のレベルで監査ログが提供されます。 いくつかの要点を以下に示します。
- アクティビティ ログでは、既定で、重要な Azure リソース操作に関する情報が提供されます。 すべてのログには、状態、時刻、操作を開始した ID が含まれます。
- AKS クラスターに対して行われたすべての API 呼び出しのすべてのレコードにアクセスするために、診断設定を有効にします。 ログからは、要求元、タイム スタンプ、要求のソース、要求の内容についての詳細が得られます。 適切な保持期間を指定して Log Analytics ワークスペースにログを格納します。 Log Analytics ワークスペースのログを有効にして、監査証跡へのアクセスもログされるようにします。
- Container Insights を使用した Syslog 収集を有効にして、Log Analytics ワークスペースで AKS ノード レベルのオペレーティング システムのセキュリティと正常性イベント ログをキャプチャします。 これらのログは SIEM にも取り込む必要があります。
- ビルド エージェントやジャンプ ボックスなど、他のコンピューティングの OS や使用状況の監査ログを含めます。 システムへのルートとしての直接アクセスを無効にします。 すべてのアクションが特定の ID で実行されていることを確認します。
- 失敗したアクセス試行をログします。 これには、Azure Storage、Azure Key Vault、AKS API サーバーなどのコンポーネントへのアクセス要求と、他のシステムでの RDP/SSH アクセスが含まれます。
- サードパーティのセキュリティ エージェントによって提供される機能を活用します。これは、AKS クラスター内のユーザー パターンの分析に役立ちます。 これらの機能は、ユーザー アクセス監査データに役立つ場合があります。
要件 10.3
イベントごとに、すべてのシステム コンポーネントについて少なくとも次の監査証跡エントリを記録します。
- 10.3.1 ユーザー識別
- 10.3.2 イベントの種類
- 10.3.3 日付と時刻
- 10.3.4 成功または失敗を示す情報
- 10.3.5 イベントの発生元
- 10.3.6 影響を受けたデータ、システム コンポーネント、またはリソースの ID または名前。
お客様の責任
「要件 10.2」に記載されているように、AKS の診断設定を有効にすることで、クラスターから監査ログを取得できます。 ログには、get、list、create、update、delete、patch、post の各イベントに関する詳細情報が含まれます。 ログには、要件の下にある一覧の情報が含まれます。 情報のクエリを実行できるよう、ログをストレージ アカウントに格納します。
たとえば、こちらのクエリを実行して、kube-audit-admin イベントの上記の情報セットを表示できます。
AzureDiagnostics
| where Category == 'kube-audit-admin'
| project TimeGenerated, ResourceId, log_s, pod_s
| top 200 by TimeGenerated desc
結果セットには、log_s フィールドの一部として情報が表示されます。
| 必要な情報 | スキーマ |
|---|---|
| ユーザー ID | SourceIP |
| イベントの種類 | Verb |
| 日付と時刻 | requestReceivedTimestamp |
| 成功または失敗の表示 | responseStatus |
| イベントの発生元 | ユーザー |
| 影響を受けたデータ、システム コンポーネント、またはリソースの ID または名前 | objectRef |
マスター ログの詳細については、コントロール プレーン コンポーネントのログを表示するに関するページを参照してください。
要件 10.4
時刻同期テクノロジを使用してすべての重要なシステム クロックと時刻を同期し、時刻を取得、配布、保存するために以下の要件が実施されていることを確認します。
- 10.4.1 重要なシステムの時刻が正確で一致しています。
- 10.4.2 時刻データが保護されています。
- 10.4.3 業界で認知されている時刻ソースから時刻設定を受信しています。
注: 時刻同期テクノロジの 1 つの例は、ネットワーク タイム プロトコル (NTP) です。
お客様の責任
AKS では、基になる Azure ホストの NTP が使用され、NTP をサポートするために送信ネットワーク トラフィックの許容量は必要ありません。 CDE に追加する他の VM では、時刻同期元として ntp.ubuntu.org (とそのプール) などの外部 NTP サーバーが使用される場合があります。 CDE に追加するコンピューティングでは、選択した NTP ソースが明示的に使用されている必要があり、文書化されている必要があります。
要件 10.5
監査証跡の表示を、仕事関連のニーズを持つユーザーのみに制限します。
- 10.5.1 監査証跡の表示を、仕事関連のニーズを持つユーザーに制限します。
- 10.5.2 監査証跡ファイルを許可されない変更から保護します。
- 10.5.3 監査証跡ファイルは、一元管理されている変更が困難なログ サーバーまたはメディアにすぐにバックアップします。
- 10.5.4 外部に公開されているテクノロジのログは、一元管理されている安全な内部ログ サーバーまたはメディア デバイス上に書き込みます。
- 10.5.5 ログに対してファイル整合性監視または変更検出ソフトウェアを使用して、既存のログ データを変更するとアラートが生成されるようにする (ただし、新しいデータの追加ではアラートを生成させません)。
お客様の責任
複数のログ同期を実行すると、監査証跡データのセキュリティ保護、確認、分析、クエリのオーバーヘッドが増加します。 監査証跡の完全な分離と管理に関する懸念事項との間でトレードオフのバランスを取る監査証跡トポロジを計画します。
可能であれば、ログを統合します。 その利点は、データの確認、分析、クエリを効率的に実施できることです。 Azure には、いくつかのテクノロジ オプションが用意されています。 Azure Monitor Container Insights を使用して、Log Analytics ワークスペースにログを書き込むことができます。 もう 1 つのオプションは、Microsoft Sentinel などのセキュリティ情報イベント管理 (SIEM) ソリューションにデータを統合することです。 その他の一般的なサードパーティの選択肢は、Splunk、QRadar、および ArcSight です。 Microsoft Defender for Cloud と Azure Monitor では、これらのソリューションがすべてサポートされています。 これらのソリューションは、確実に証跡を変更できなくするため、追加専用のデータ シンクです。
Defender for Cloud では、構成された間隔で結果をエクスポートできます。 詳細については、連続エクスポートに関するページを参照してください。
すべてのログは、1 つのリージョンに少なくとも 3 つのコピーで保持されます。 バックアップ戦略として、リージョン間のバックアップまたはレプリケーションを有効にすることで、より多くのコピーを保持できます。 すべてのログ エントリは、セキュリティで保護された HTTP/S チャネルを介してのみ使用できます。
Log Analytics と Microsoft Sentinel では、監査証跡アクセスを管理するためのさまざまなロールベースのアクセス制御がサポートされています。 ロールが組織の役割および責任にマップされていることを確認してください。
Log Analytics ワークスペースが操作とコンプライアンスの両方のニーズをサポートしていることを確認します。 SIEM ソリューションに転送する、スコープ内のクラスター専用のワークスペースを検討してください。
AKS のほとんどのログは、stdout や stderr から発生し、Azure Monitor Container insights によって収集されます。 手動で作成した他のログがある場合は、信頼された転送ストリームに送信され、改ざんされることがない方法によるデータ出力を検討してください。
要件 10.6
すべてのシステム コンポーネントのログとセキュリティ イベントを調べ、異常または疑わしいアクティビティを特定します。
- 10.6.1 毎日 1 回以上次の項目を確認します。
- すべてのセキュリティ イベント
- CHD またはSAD (あるいは両方) を保存、処理、または送信するすべてのシステム コンポーネントのログ
- すべての重要なシステム コンポーネントのログ
- すべてのサーバーとセキュリティ機能を実行するシステム コンポーネント (ファイアウォール、侵入検知システム/侵入防止システム (IDS/IPS)、認証サーバー、eコマース リダイレクト サーバーなど) のログ。
- 10.6.2 組織の年間リスク アセスメントによって決定された、組織のポリシーおよびリスク管理戦略に基づいて、他のシステム コンポーネントすべてのログを定期的にレビューします。
- 10.6.3 レビュー プロセスで特定された例外と異常を追跡調査します。
お客様の責任
Azure 監視サービスの Azure Monitor と Microsoft Defender for Cloud では、異常なアクティビティを検出したときに通知またはアラートを生成できます。 これらのアラートには、重大度、状態、アクティビティの時刻などのコンテキスト情報が含まれます。
アラートが生成されたら、修復戦略を設定し、進行状況を確認します。 1 つの方法は、Microsoft Defender for Cloud のセキュリティ スコアを追跡し、履歴結果と比較することです。
Microsoft Sentinel などの SIEM ソリューションを使用して、単一ビューにデータを一元化します。 データを統合することで、充実したアラート コンテキストが得られます。
または、ストレージ内の完全なログを手動で確認します。 たとえば、Azure Monitor ログでは、アクティビティの種類、アクティビティの内容、またはアクティビティの呼び出し元に基づいてフィルタリング機能を使用できます。
アラートとイベントを定期的に確認するための組織のポリシーを設定し、具体的な改善目標を定めたイニシアティブを計画します。 Log Analytics のカスタムの保存済みクエリを使用して、対象のログ クエリの文書化とクエリ実行を容易にします。 これにより、チームが 10.6 に関連して何を確認することが重要であるかを理解することと、このプロセスに関係するすべての手動作業が一貫性のあるワークフローに従うことが徹底されます。
要件 10.7
監査証跡の履歴を少なくとも 1 年間保持し、少なくとも 3 か月はすぐに分析できる状態にしておきます (オンライン、アーカイブ、バックアップから復元可能など)。
お客様の責任
ログは無期限に使用できません。 Azure アクティビティ ログと診断設定が保持され、クエリの実行ができることを確認します。 リソースの診断設定を有効にするときに、3 か月の保持期間を指定します。 Azure Monitor ログは、監査やオフライン分析に使用できるように、長期的なアーカイブをサポートします。 書き込み 1 回、読み取り複数回の原則に沿った長期的なアーカイブ ソリューションを実装します。
要件 10.8
10.8.1 サービス プロバイダーのみの追加要件: すべての重要なセキュリティ制御の障害に適切なタイミングで対応します。 セキュリティ制御の障害に対応するためのプロセスには以下を含む必要があります。
セキュリティ機能の復元
セキュリティ障害の期間 (開始と終了の日付時刻) の識別および文書化
根本原因を含む障害の原因の識別と文書化、および根本原因に対処する改善案の文書化
障害中に発生したすべてのセキュリティ問題の識別および対処
セキュリティ障害の結果、さらなる処置が必要かどうか判断するためのリスク アセスメントの実施
障害原因の再発防止策の実装 (セキュリティ制御の監視の再開)
お客様の責任
実際に役立つ場合は、重要なセキュリティ制御の存在を示すアラートを設定します。 それ以外の場合は、予期されたセキュリティ制御の欠落が監査プロセスによって適切なタイミングで検出できるようにします。 AKS クラスターで実行されているセキュリティ エージェントや、Azure リソース上のアクセスの制御 (IAM およびネットワーク) などの制御を検討してください。 AKS クラスターがプライベート クラスターであるかどうかの確認、ネットワーク セキュリティ グループ (NSG) 規則によるネットワークの露出ポイントの確認、または予期しないパブリック IP の確認の設定を含めます。 また、DNS、ネットワーク ルーティング、ファイアウォール、および Microsoft Entra ID の予想外の変更も含めます。
要件 10.9
ネットワーク リソースとカード所有者データへのすべてのアクセスを監視するためのセキュリティ ポリシーと運用手順を文書化して、使用し、すべての関係者に通知することを徹底します。
お客様の責任
プロセスとポリシーに関する詳細なドキュメントを保持することが重要です。 適用されるポリシーに関するドキュメントを保守します。 監視作業の一環として、担当者は、監査ログの有効化と表示や、一般的なリスクの特定と修復に関するトレーニングを受ける必要があります。 これは、ポリシーの観点から承認プロセスに関わっている担当者にとって重要です。
要件 11.1
ワイヤレス アクセス ポイント (802.11) の存在をテストし、四半期ごとにすべての承認済みおよび承認されていないワイヤレス アクセス ポイントを検出および特定するプロセスを実装します。
外部ネットワークはこのドキュメントの対象外であり、個別に評価する必要があります。
お客様の責任
このアーキテクチャとその実装は、ワイヤレス接続を介してオンプレミスまたは企業のネットワークからクラウドへのトランザクションをサポートするように設計されていません。 考慮事項については、公式の PCI DSS 3.2.1 標準のガイダンスを参照してください。
要件 11.2
内部および外部ネットワークの脆弱性スキャンを、少なくとも四半期に 1 回と、次のようなネットワークの大幅な変更後に実行します。
- 新しいシステム コンポーネントのインストール
- ネットワーク トポロジの変更
- ファイアウォール規則の変更
- 製品のアップグレード
詳細については、「Payment Card Industry (PCI) Data Security Standard Approved Scanning Vendors」を参照してください。
お客様の責任
AKS クラスター、ネットワーク構成、コンテナー レジストリ、およびアーキテクチャのその他のコンポーネントの変更を確認するプロセスを設定します。
ネットワークに変更がある場合、スキャンが必要かどうかこのプロセスで評価する必要があります。 たとえば、クラスターが現在パブリック インターネットに公開されているか。 新しいファイアウォール規則の制限は緩すぎないか。 クラスター内で、ポッド間のフローにセキュリティの欠陥はあるか。
インフラストラクチャに関する重要な変更について明確な合意した定義を設定します。 いくつかの例を次に示します。
- NSG またはAzure Firewall 規則の構成
- 仮想ネットワークのピアリング
- DNS の設定
- Azure Private Link の構成
- 他のネットワーク コンポーネント
11.2.1 に適用
四半期ごとの脆弱性のスキャンは、Azure のネットワークと Kubernetes ネットワークの概念を深く理解したスキルのある担当者が実行する必要があります。 結果を重大度レベル付きで 要件 6.1 にマップし、優先度の高い項目を解決します。 大幅な変更がある場合は、スケジュールされた四半期ごとのスキャンの前にスキャンを実行します。 これは、先手を打って問題を解決できるように、新しい脆弱性を検出するのに役立ちます。
このスキャンには、クラスター内 (ポッド間) ネットワークも含める必要があります。
11.2.2 に適用 Azure のネットワークと Kubernetes での幅広い経験を持つ認定スキャン ベンダー (ASV) を選択します。 これにより、提案される修復に奥行きと特異性がもたらされます。
要件 11.3
以下を含む侵入テストの方法を実装します。
- 業界で受け入れられている侵入テスト アプローチ (たとえば、NIST SP800-115) に基づく
- CDE 境界全体と重要なシステムの対象範囲を含む
- ネットワークの内部と外部両方からのテストを含む
- 任意のセグメント化およびスコープの縮小制御を検証するテストを含む
- 少なくとも要件 6.5 に一覧表示されている脆弱性を含むようにアプリケーション レイヤー侵入テストを定義する
- ネットワーク機能とオペレーティング システムをサポートするコンポーネントを含むようにネットワーク レイヤー侵入テストを定義する
- 過去 12 か月間に発生した脅威と脆弱性のレビューと考慮事項を含む
- 侵入テストの結果と修復アクティビティの結果の保持を指定する
お客様の責任
侵入テストを実施して、情報の収集、脆弱性の分析、レポート作成を行うことでセキュリティの欠陥を見つけます。 侵入テスト実行標準 (PTES) に記載されている業界のガイドラインに従って、一般的なシナリオと、ベースラインの確立に必要なアクティビティに取り組むことをお勧めします。
侵入テストの実行者は、オンプレミスと Azure のネットワークについて深く理解して、毎年のセグメント化テストが広範囲に及ぶようにする必要があります。 テスト方法をクラスター内ネットワークに拡張します。 この担当者には、Kubernetes ネットワークの概念についての確かな経験が必要です。
テストは、CDE で実行されているアプリケーションおよびデータ層を対象にする必要があります。
侵入テストの練習では、実行者が組織全体の機密データへのアクセスを必要とする場合があります。 実施のルールに従い、アクセスと意図が誤って使用されないようにします。 シミュレートされた攻撃の計画と実行に関するガイダンスについては、「侵入テストの実施ルール」を参照してください。
要件 11.4
侵入検出や侵入防止の手法を使用して、ネットワークへの侵入の検出や防止を行います。 カード所有者データ環境の境界およびカード所有者データ環境内の重要ポイントですべてのトラフィックを監視します。 侵害が疑われる場合は担当者に通知します。
お客様の責任
Web アプリケーション ファイアウォール (WAF) を使用して受信トラフィックを検査することにより、AKS クラスターを保護します。 このアーキテクチャでは、統合された WAF を備えた Azure Application Gateway によって侵入が防止されます。 検出された侵入および攻撃を積極的にブロックするには、防止モードを使用します。 単に検出モードを使用するということはしないでください。 詳細については、「Azure Kubernetes Service (AKS) でのネットワーク接続とセキュリティに関するベスト プラクティス」を参照してください。
代替オプションは、Azure Firewall Premium で侵入検出または侵入防止、あるいはその両方の機能を使用することです。 詳細については、「IDPS」を参照してください。
もう 1 つのオプションは、Azure Monitor Network Insights を有効にすることです。これにより、接続モニター、ネットワーク セキュリティ グループ (NSG) のフロー ログ、および Traffic Analytics などのネットワーク監視機能にアクセスできます。
Microsoft Defender プランが CDE のさまざまなコンポーネントに適用されるときに、それらを有効にします。 たとえば、Azure SQL が CHD の格納に使用されている場合、Microsoft Defender for SQL によってデータ層の侵入が確実に検出されるようになります。
また、NSG フロー ログを Microsoft Sentinel などの一元化された SIEM ソリューションに接続することで、トラフィック パターンの異常も検出します。 このリファレンス実装では、ログは追加専用モードです。これにより、監査ログの変更の追跡が最小限に抑えられます。 ただし、長期的なストレージ用の外部シンクに送信されるすべてのログは変更できません。 これらは、書き込み 1 回、読み取り複数回の手法に従う必要があります。 ファイルの整合性の監視 (FIM) ソリューションでこれらの外部エンティティを対象にして、変更が検出されるようにします。
要件 11.5
変更追跡ソリューション (ファイルの整合性の監視ソリューションなど) をデプロイして、重要なシステム ファイル、構成ファイル、コンテンツ ファイルの無許可の改変を担当者に通知します。 重要なファイルの比較を少なくとも毎週実行するように製品を構成します。
お客様の責任
クラスターで、ファイルの整合性の監視 (FIM) ソリューションを Kubernetes 対応セキュリティ エージェントと連動させて実行し、ノード レベルの変更につながる可能性があるファイルおよびシステム レベルのアクセスを検出します。 FIM ソリューションを選択する際には、その機能と検出の深さを明確に理解してください。 信頼されたベンダーが開発したソフトウェアを検討します。
重要
このリファレンス実装により、FIM ソリューションのマルウェア対策エージェントを実行するプレースホルダー DaemonSet のデプロイが提供されます。 エージェントは、クラスター内のすべてのノード VM 上で実行されます。 このデプロイに任意のマルウェア対策ソフトウェアを配置します。
FIM ツールのすべての既定の設定を確認して、対象とするシナリオがその値で検出されることを確認し、それらの設定を適切に調整します。
このソリューションを有効にして、監視または SIEM ソリューションにログを送信し、それらがアラートを生成できるようにします。 ログ スキーマの変更に注意してください。そうしないと、重大なアラートを見逃す可能性があります。
CDE のその他のコンピューティングでは、変更の追跡が有効になっている必要があります。
要件 11.6
セキュリティ ポリシーおよびセキュリティの監視とテストに関する運用手順を文書化して、使用し、すべての関係者に通知することを徹底します。
お客様の責任
プロセスとポリシーに関する詳細なドキュメントを保持することが重要です。 適用されるポリシーに関するドキュメントを保守します。 テスト作業の一環として、レビューの頻度とレビュー基準を含めます。 チームが侵入テストの側面を理解していることを確認します。 検出されたリスクを軽減するために、修復計画を文書化しておきます。
これは、ポリシーの観点から承認プロセスに関わっている担当者にとって重要です。
次の手順
すべての職員の情報セキュリティに対処するポリシーを維持します。