PCI-DSS 3.2.1 の AKS 規制クラスターの脆弱性を検出する (パート 5/9)

この記事では、Payment Card Industry Data Security Standard (PCI-DSS 3.2.1) に準拠して構成された Azure Kubernetes Service (AKS) クラスターの考慮事項について説明します。

この記事はシリーズの一部です。 概要を参照してください。

他のクラウド ソリューションと同様に、PCI ワークロードはネットワーク、ID、データの脅威の対象になります。 ワークロードとシステムの脆弱性を利用するソースの一般的な例は、望ましくない結果をもたらすウイルスやソフトウェア更新プログラムです。 脅威を早期に検出し、迅速に軽減策を使用して対応します。 ワークロード アクティビティの重要なアラートを作成し、それらのアラートをコア システム プロセスに拡張します。 ウイルス対策ツールまたはファイル整合性監視 (FIM) ツールを、常に実行しておく "必要があります"。 責任を持つ対応計画と、アラートを調査してアクションを実行するチームを作成します。

脆弱性管理プログラムを維持する

要件 5 — すべてのシステムをマルウェアから保護し、ウイルス対策ソフトウェアまたはアプリケーションを定期的に更新する

AKS 機能のサポート

AKS の動作は、従来のアプリケーション ホストとは異なります。 AKS クラスター内のノード VM の露出は限られており、直接アクセスされないように設計されています。 ノード VM は従来の VM と同じではないので、一般的な VM ツールを使用することはできません。 そのため、このセクションの推奨事項は、Kubernetes ネイティブのコンストラクトを通じて適用されます。 これらの要件を VM レベルで直接適用すると、クラスターがサポートされなくなる可能性があります。

すべてのノードのポッドで実行される DaemonSets に、選択したマルウェア対策ソフトウェアをデプロイする必要があります。

お客様の責任

ソフトウェアが Kubernetes とコンテナーに特化していることを確認します。 サードパーティ製ソフトウェアのオプションがいくつかあります。 一般的な選択肢には、Prisma Cloud と Aquasec があります。 Falco などのオープンソースも使用できます。 サード パーティ製ソフトウェアが最新の状態であることを確認するプロセスを設けるのは、お客様の責任です。 また、ソリューションを監視してアラートを出すのもお客様の責任です。

要件	担当
要件 5.1	悪意のあるソフトウェア (特にパーソナル コンピューターとサーバー) による影響を受けやすいすべてのシステムにウイルス対策ソフトウェアを展開します。
要件 5.2	すべてのウイルス対策メカニズムを次のように維持します。
要件 5.3	ウイルス対策メカニズムが有効化され実行中であることを確認してください。一定期間に限定し、管理者から個別に承認を得ている場合を除いて、ユーザーによって無効化または変更できないようにします。
要件 5.4	セキュリティ ポリシーとマルウェアからシステムを保護するための運用手順が、文書化され、使用され、すべての関係者に通知されていることを確認してください。

要件 6 — セキュリティで保護されたシステムとアプリケーションを開発して維持する

AKS 機能のサポート

他の Azure サービスと同様に、AKS は、開発プロセスのフェーズ全体を通したセキュリティに関して、Microsoft SDL (セキュリティ開発ライフサイクル) のプロセスに従います。 開発の初期段階からさまざまなコンポーネントがスキャンされ、可能な限り早い段階でセキュリティのギャップがカバーされます。

AKS イメージは FedRAMP SLA アプローチに従い、30 日以内にイメージの脆弱性に修正プログラムを適用する必要があります。 この要件を強制するため、すべてのイメージは DevSecOps パイプラインを通してサニタイズされます。

毎週、AKS によってノード プールに新しいイメージが提供されます。 お客様は、それらを適用して、Virtual Machine Scale Sets のワーカー ノードの修正プログラムの適用と更新を行う必要があります。 詳細については、「Azure Kubernetes Service (AKS) ノード イメージのアップグレード」を参照してください。

AKS コントロール プレーンについては、AKS によってセキュリティ パッチのインストールまたはアップグレードが行われます。 これらは 24 時間ごとに更新されます。

AKS コントロール プレーンとワーカー ノードは、Center for Internet Security (CIS) に対して強化されます。 具体的には、AKS CIS、Ubuntu CIS、Windows CIS です。

AKS は Azure Container Registry (ACR) と統合されます。 ACR と Microsoft Defender for Cloud の継続的スキャン機能を使用して、さまざまなリスク レベルで脆弱なイメージとアプリケーションを特定します。 イメージ スキャンとリスク制御については、「Microsoft Defender for Containers」を参照してください。

お客様の責任

要件	担当
要件 6.1	セキュリティの脆弱性については、信頼できる外部情報源からのセキュリティ脆弱性に関する情報を使用して特定し、新しく検出されたセキュリティの脆弱性にリスク格付け (たとえば "高"、"中"、または "低") を割り当てるプロセスを確立します。
要件 6.2	ベンダーから提供された該当するセキュリティ修正プログラムをインストールすることによって、すべてのシステム コンポーネントとソフトウェアを既知の脆弱性から守ります。 リリース 1 か月以内に、重要なセキュリティ更新プログラムをインストールします。
要件 6.3	セキュリティ保護された内部および外部のソフトウェア アプリケーション (アプリケーションへの Web ベースの管理アクセス権を含む) を開発します。
要件 6.4	システム コンポーネントに変更を加える場合は、必ず制御プロセスおよび手続きに従います。
要件 6.5	ソフトウェア開発プロセスでよく見られるコーディングに関する脆弱性に対処します。
要件 6.6	公開された Web アプリケーションの場合、新しい脅威と脆弱性に継続的に対処し、これらのアプリケーションを既知の攻撃から保護します。
要件 6.7	セキュリティ保護されたシステムおよびアプリケーションを開発および維持するためのセキュリティ ポリシーと運用手順が文書化され、使用され、すべての関係者に周知されていることを確認します。

要件 5.1

悪意のあるソフトウェアによる影響を受けやすいすべてのシステム (特にパーソナル コンピューターとサーバー) にウイルス対策ソフトウェアを展開します。

お客様の責任

お客様は、適切なマルウェア対策ソフトウェアを選択して、ワークロード、インフラストラクチャ、デプロイ パイプラインを保護する必要があります。

AKS ノード VM へのアクセスは制限されているので、ノード VM にマルウェアを挿入できるレイヤーでシステムを保護します。 クラスター ノード、コンテナー イメージ、Kubernetes API サーバーとのランタイム相互作用での検出と防止が含まれます。 クラスターに加えて、クラスターと対話し、従来の方法でウイルス対策ソフトウェアをインストールできる次のコンポーネントを保護します。

• ジャンプ ボックス
• ビルド エージェント

スキャン アクティビティをセキュリティ開発ライフサイクル (SDL) に合わせて調整します。 SDL に従うと、アーキテクチャのさまざまなコンポーネントのスキャンが開発の早い段階で開始され、セキュリティのギャップが可能な限り早期にカバーされます。

要件 5.1.1

ウイルス対策プログラムが、すべての既知の種類の悪意のあるソフトウェアを検出、削除、阻止する能力があることを確認します。

お客様の責任

各ソフトウェア オファリングの機能セットと、それが実行できるスキャンの深さについて学習します。 ソフトウェアで、一般的な脅威をブロックし、新しい脅威を監視する必要があります。 ソフトウェアが定期的に更新され、テストされて、不適切であることがわかった場合は置き換えられるようにします。 信頼されたベンダーが開発したソフトウェアを検討します。

• クラスターの脆弱性を検出する監視ツール。

  AKS では、従来のエージェント ベースの VM ソリューションをノード VM で直接実行することはできません。 すべてのノードのポッドで実行される DaemonSets に、マルウェア対策ソフトウェアをデプロイする必要があります。

  Kubernetes とコンテナー専用に作成されたソフトウェアを選択します。 サードパーティ製ソフトウェアのオプションがいくつかあります。 一般的な選択肢には、Prisma Cloud と Aquasec があります。 Falco などのオープンソースも使用できます。

  デプロイすると、それらはすべてのユーザーとシステム ノード プールをスキャンするクラスター内のエージェントとして実行されます。 AKS ではそのランタイム システム バイナリにシステム ノード プールが使用されますが、基になるコンピューティングは引き続きユーザーの責任です。

  エージェントを実行する目的は、クラスターの異常なアクティビティを検出することです。 たとえば、アプリケーションで API サーバーを呼び出そうとしていますか。 一部のソリューションでは、ポッド間での API 呼び出しのログが生成され、レポートが生成され、アラートが生成されます。 それらのログを確認し、必要なアクションを実行してください。

  クラスターのブートストラップの直後にセキュリティ エージェントをインストールして、クラスターと AKS リソースのデプロイの間の監視されていないギャップを最小限に抑えます。

  セキュリティ エージェントは、高い特権で実行され、ワークロードだけでなく、クラスターで実行されるすべてのものをスキャンします。 それらがデータ流出元になってはなりません。 また、コンテナーではサプライ チェーン攻撃がよく発生します。 多層防御戦略を使用し、ソフトウェアとすべての依存関係が信頼できることを確認する必要があります。

  また、クラスターの操作に参加する外部資産に対して、ウイルス対策ソフトウェアを実行します。 例としては、ジャンプ ボックス、ビルド エージェント、クラスターと対話するコンテナー イメージなどがあります。

  エージェントがスキャンするときに、ファイルのロックなどにより、クラスターの重要な操作をブロックしたり干渉したりしないようにする必要があります。 構成の誤りにより、安定性の問題が発生したり、クラスターがサポートされなくなったりする可能性があります。

  重要

  リファレンス実装により、マルウェア対策エージェントを実行するためのプレースホルダー DaemonSet のデプロイが提供されます。 エージェントは、クラスター内のすべてのノード VM 上で実行されます。 このデプロイに任意のマルウェア対策ソフトウェアを配置します。

• コンテナーの安全性の維持。 パイプラインでコンテナー スキャン ツールを実行して、Microsoft Defender for Containers の CI/CD 脆弱性スキャンなど、コンテナー イメージを介して発生する可能性のある脅威を検出します。 サードパーティの選択肢には、Trivy と Clair があります。 イメージをビルドするときは、常にディストリビューションレス イメージになるようにしてください。 これらのイメージには、基本 Linux イメージ内の重要なバイナリのみが含まれているので、攻撃対象領域が減ります。 Microsoft Defender for Containers の脆弱性評価のような継続的なスキャン ソリューションを使用して、リポジトリに既に保存されているイメージを継続的にスキャンします。

要件 5.1.2

悪意のあるソフトウェアの標的になったり影響を受けたりしにくいシステムの場合は、定期的な評価を実行して、進化するマルウェアの脅威を特定および評価し、ウイルス対策ソフトウェアが引き続き不要かどうかを確認します。

お客様の責任

一般的な脆弱性により、クラスター外のコンポーネントが影響を受ける可能性があります。 Azure プラットフォームからの CVE や他のセキュリティ アラートを監視して、セキュリティの脆弱性を追跡します。 Azure でホストされているサービスで脆弱性を検出してウイルス対策ソリューションを実行できる新機能については、Azure の更新プログラムを確認してください。

たとえば、BLOB ストレージには、疑わしいアップロードを検出するためのマルウェア レピュテーション スクリーニングが必要です。 新しい機能である Microsoft Defender for Storage には、マルウェア レピュテーション スクリーニングが含まれます。 また、そのようなサービスにウイルス対策ソリューションが必要かどうかを検討します。

要件 5.2

すべてのウイルス対策メカニズムを次のように維持します。

• 常に最新の状態にします。
• 定期的にスキャンを実行します。
• PCI DSS 要件 10.7 で維持される監査ログを生成します。

お客様の責任

• 最新バージョンのウイルス対策ソフトウェアを使用して、クラスターが新しい攻撃から保護されていることを確認します。 2 つの種類の更新プログラムを検討します。
  • ウイルス対策ソフトウェアを最新の機能更新プログラムにしておく必要があります。 1 つの方法は、プラットフォーム更新の一部として更新プログラムをスケジュールすることです。
  • 最新の脅威を検出して識別できるように、セキュリティ インテリジェンスの更新プログラムが使用可能になったらすぐに適用する必要があります。 自動更新を選択します。
• スケジュールどおりに脆弱性スキャンが実行されていることを検証します。
• スキャンの結果として生成される、正常および異常なコンポーネントを示すログを保持します。 要件 10.7 で推奨される保持期間が指定されており、1 年です。
• 検出された問題をトリアージして修復するプロセスを設けます。

Microsoft Defender のウイルス対策更新プログラムの適用方法については、「Microsoft Defender のウイルス対策更新プログラムを管理してベースラインを適用する」を参照してください。

要件 5.3

ウイルス対策機能が有効化され実行中である必要があり、ユーザーによって無効化または変更することはできません。 一定期間に限定し、管理者から個別に承認を得ている場合を除きます。

お客様の責任

お客様は、セキュリティ エージェントの監視とアラートを設定する必要があります。 ワークロードだけでなく、コア システム プロセスについても重要なアラートを作成します。 エージェントを常に実行しておく "必要があります"。 マルウェア対策ソフトウェアによって生成されたアラートに応答します。

• スキャン アクティビティのログ証跡を保持します。 スキャン プロセスで、ディスクまたはメモリから取得されたカード所有者のデータがログに記録されないようにします。
• 予期しないコンプライアンス違反になる可能性があるアクティビティのアラートを設定します。 アラートが誤ってオフにされてはなりません。
• エージェント (および他の重要なセキュリティ ツール) のデプロイを変更するアクセス許可を制限します。 それらのアクセス許可は、ワークロードのデプロイのアクセス許可とは別にしておきます。
• セキュリティ エージェントが想定した通りに実行されていない場合は、ワークロードをデプロイしてはなりません。

要件 5.4

マルウェアからシステムを保護するためのセキュリティ ポリシーと運用手順が、文書化され、使用され、すべての関係者に通知されていることを確認してください。

お客様の責任

プロセスとポリシーに関する詳細なドキュメント (特に、システムの保護に使用されるウイルス対策ソリューションに関する詳細) を維持することが重要です。 製品サイクルにおいてセキュリティ インテリジェンスの更新プログラムが維持される場所、スキャンの頻度、リアルタイムのスキャン機能などに関する情報を含めます。

ログを格納するための保持ポリシーを設けます。 コンプライアンスのために長期的なストレージが必要になる場合があります。

問題の評価と修復のための標準的な運用手順に関するドキュメントを保持します。 規制の対象となる環境の運用担当者に対し、セキュリティの保証をサポートするための教育を施し、情報を提供し、動機付けを行う必要があります。 これは、ポリシーの観点から承認プロセスに関わっている担当者にとって重要です。

要件 6.1

セキュリティの脆弱性については、信頼できる外部情報源からのセキュリティ脆弱性に関する情報を使用して特定し、新しく検出されたセキュリティの脆弱性にリスク格付け (たとえば高、中、または低) を割り当てるプロセスを確立します。

お客様の責任

検出された脆弱性を確認し、適切にランク付けするプロセスを作成します。 Microsoft Defender for Cloud には、推奨事項とアラート、ベースとなるリソースの種類とその重大度、環境が表示されます。 ほとんどのアラートには、キル チェーンの意図を理解するのに役立つ MITRE ATT&CK® の方針があります。 問題を調査して軽減するための修復計画が設けられていることを確認します。

AKS では、Azure Container Registry と継続的スキャンを組み合わせて使用し、さまざまなリスク レベルで脆弱なイメージとアプリケーションを識別できます。 結果は、Microsoft Defender for Cloud で表示できます。

詳細については、Container Registry に関するページを参照してください。

要件 6.2

ベンダーから提供された該当するセキュリティ修正プログラムをインストールすることによって、すべてのシステム コンポーネントとソフトウェアを既知の脆弱性から守ります。 リリース 1 か月以内に、重要なセキュリティ更新プログラムをインストールします。

お客様の責任

• サードパーティ ベンダーからのサプライ チェーン攻撃を防ぐには、すべての依存関係が信頼されていることを確認します。 評判がよくて信頼できるベンダーを選択することが重要です。

• 毎週、AKS によってノード プールに新しいイメージが提供されます。 それらのイメージは自動的には適用されません。 使用可能になったらすぐに適用してください。 ノード イメージの更新を使用して手動または自動で更新できます。 詳細については、「Azure Kubernetes Service (AKS) ノード イメージのアップグレード」を参照してください

  AKS コントロール プレーンについては、AKS によってセキュリティ パッチのインストールまたはアップグレードが行われます。

• 24 時間ごとに、AKS ノードによって、オペレーティング システムとセキュリティの更新プログラムが個別にダウンロードされてインストールされます。 それらの更新プログラムを受け取りたい場合は、ファイアウォールでこのトラフィックをブロックしないようにする必要があります。

  セキュリティ エージェントでレポート機能を有効にして、適用された更新プログラムに関する情報を取得することを検討します。 一部のセキュリティ更新プログラムでは再起動が必要です。 アラートを確認し、それらの再起動によるアプリケーションのダウンタイムが最小限またはゼロになるように、対処する必要があります。 再起動を制御された方法で実行するオープンソースの オプションは、Kured (Kubernetes の再起動デーモン) です。

• ジャンプ ボックスやビルド エージェントなど、プロビジョニングするクラスターの外部にあるリソースまで、修正プログラムの適用プロセスを拡張します。

• サポートされている AKS のバージョンを最新の状態に維持します。 有効期限が切れたバージョンを設計で使用している場合は、現在のバージョンにアップグレードします。 詳細については、サポートされる AKS のバージョンに関する記事を参照してください。

要件 6.3

次のように、セキュリティ保護された内部および外部のソフトウェア アプリケーション (アプリケーションへの Web ベースの管理アクセス権を含む) を開発します。

• PCI DSS に準拠する (たとえば、セキュリティで保護された認証およびログ記録)
• 業界の標準とベスト プラクティスに従います。
• ソフトウェア開発ライフサイクル全体に、情報セキュリティを組み込みます。これは、サードパーティによって開発されたオーダーメイドまたはカスタム ソフトウェアを含む、内部で開発されたすべてのソフトウェアに適用されます。

お客様の責任

ワークロードのライフサイクルと操作の一部として、セキュリティの選択肢を統合し、優先順位を付けます。

いくつかの業界フレームワークは、NIST フレームワークなどのライフサイクルに対応しています。 NIST の機能 (識別、保護、検出、応答、回復) により、各フェーズでの予防的な制御の戦略が提供されます。

Microsoft SDL (セキュリティ開発ライフサイクル) では、開発プロセスのフェーズ全体を通じたセキュリティのためのベスト プラクティス、ツール、プロセスが提供されます。 AKS を含むすべての Azure サービスは、Microsoft SDL のプラクティスに従っています。 また、クラウド サービス運用のための Operational Security Assurance (OSA) フレームワークにも従っています。 お客様も同様のプロセスを用意する必要があります。 アプリケーションのセキュリティ保護に役立つよう、これらのプラクティスは公開されています。

• Microsoft SDL
• Microsoft OSA

要件 6.3.1

アプリケーションがアクティブ化される、または顧客にリリースされる前に、開発、テスト、カスタム アプリケーション用のアカウント、ユーザー ID およびパスワードを削除します。

お客様の責任

クラスターの作成の一環として、複数のローカル Kubernetes ユーザーが既定で作成されます。 それらのユーザーは、一意の ID を表していないため、監査することはできません。 その中には、高い特権を持つものもあります。 AKS のローカル アカウント無効化機能を使用して、それらのユーザーを無効にします。

他の考慮事項については、公式の PCI-DSS 3.2.1 標準のガイダンスを参照してください。

要件 6.3.2

以下が実行されるように、運用環境または顧客にリリースする前にカスタム コードをレビューして、コーディングの脆弱性の可能性を (手動または自動のプロセスを使用して) 特定します。

• コード レビューの方法とセキュリティ保護されたコーディング プラクティスに関する知識を持つ、コードを作成した開発者以外の開発者がコード変更をレビューする。
• セキュリティ上安全なコーディング ガイドラインに従ってコードが書かれていることをコード レビューで確認する。
• リリース前に適切な修正を実装する。
• リリースする前にコード レビューの結果を管理者が確認し承認する。

お客様の責任

クラスターにインストールされているすべてのソフトウェアは、コンテナー レジストリから供給されます。 アプリケーション コードと同様に、プロセスとユーザーで Azure とサードパーティのイメージ (DockerFile および OCI) を詳しく調べます。 また、

• クラスターを作成するときに、初期段階からコンテナー イメージのスキャンを開始します。 スキャン プロセスを継続的インテグレーションおよび継続的配置パイプラインの一部にします。

  クラスター ブートストラップ イメージとワークロードの両方がレビュー ゲートと検疫ゲートの一方または両方を通過するように、デプロイ パイプラインのゲートを設定します。 クラスターにプルされる前に使用されたプロセスとその方法についての履歴を保持します。

• イメージのサイズを減らします。 通常、イメージには必要以上のバイナリが含まれています。 イメージのサイズを小さくすると、パフォーマンスが向上するだけでなく、攻撃対象領域も制限されます。 たとえば、ディストリビューションレスを使用すると、Linux の基本イメージが最小になります。

• Dockerfile とマニフェストの整合性を検証する静的分析ツールを使用します。 サードパーティのオプションとしては、Dockle や Trivy があります。

• 署名されたイメージのみを使用します。

• Azure によって提供される基本イメージについて、およびそれが CIS ベンチマークにどのように準拠しているかについて、理解し (および受け入れ) ます。 詳細については、「Center for Internet Security (CIS) のベンチマーク」を参照してください。

Azure Container Registry と Microsoft Defender for Cloud での継続的スキャンは、脆弱なイメージと、それによってワークロードにもたらされる可能性のあるさまざまなリスクを明らかにするのに役立ちます。 イメージ スキャンとリスク制御の詳細については、コンテナーのセキュリティに関する記事を参照してください。

要件 6.4

システム コンポーネントに変更を加える場合は、必ず制御プロセスおよび手続きに従います。

お客様の責任

変更制御プロセスを文書化し、それらのプロセスに従ってデプロイ パイプラインを設計するようにします。 プロセスと実際のパイプラインが整合していない状況を検出するための他のプロセスを組み込みます。

要件 6.4.1、6.4.2

• 運用環境から開発/テスト環境を分離し、アクセス制御による分離を適用します。
• 開発およびテスト環境と運用環境の間の業務の分離。

お客様の責任

運用環境と運用前環境、およびそれらの環境で使用されるロールの分離を維持します。

• 開発とテストの目的に運用クラスターを使用しないでください。 たとえば、運用クラスターには "Bridge to Kubernetes" をインストールしないでください。 非運用ワークロードには専用のクラスターを使用します。

• 運用環境から運用前環境、またはその逆のネットワーク アクセスが許可されていないことを確認します。

• 運用前環境および運用環境のシステム ID を再利用しないでください。

  クラスター管理者やパイプライン プリンシパルなどのグループには、Microsoft Entra グループを使用します。 汎用的または一般的なグループをアクセス制御として使用しないでください。 運用前クラスターと運用クラスターの間でそのようなグループを再利用しないでください。 1 つの方法としては、メンバーシップで明示的になるように、グループ名でクラスター名 (または他の不透明な識別子) を使用します。

  Azure のロールベースのアクセス制御 (RBAC) のロールを、環境間で適切に使用します。 通常、運用前環境では、より多くのロールと権限が割り当てられます。

  (パイプラインまたはソフトウェア エンジニアリング チームに付与される) 運用前環境のみの ID には、運用環境でのアクセス権を付与しないでください。 逆に、運用環境のみの ID (パイプラインなど) には、運用前クラスターでのアクセス権を付与しないでください。

  運用前環境と運用環境のリソースに対して、同じユーザー管理の ID を使用しないでください。 この推奨事項は、クラスターにデプロイされるリソースだけでなく、ユーザー管理の ID をサポートするすべてのリソースに適用されます。 ルールとして、ID を必要とする Azure リソースには、他のリソースと共有するのではなく、専用の ID を使用する必要があります。

• 高特権のアクセスには、可能であれば運用前クラスターも含めて、Just-In-Time (JIT) アクセスを使用します。 運用前クラスターと運用クラスターの両方で、条件付きアクセス ポリシーを使用します。

要件 6.4.3

テストまたは開発環境では、運用データ (ライブ PAN) は使用されません。

お客様の責任

CHD データが開発およびテスト環境に流れないことを確認します。 運用環境から開発およびテスト環境にデータを移動する手順が説明されている明確なドキュメントを用意します。 実際のデータの削除が、その手順に含まれていて、責任を持つ関係者により承認されている必要があります。

要件 6.4.4

システムを有効化する、または稼働を開始する前に、システム コンポーネントからテスト データおよびアカウントを削除します。

お客様の責任

運用環境にデプロイする前に、システム内の既定の構成データ、サンプル データ、および既知のテスト データを削除します。 テストのためにカード所有者のデータを使用しないでください。

要件 6.4.5

セキュリティ更新プログラムとソフトウェア変更を実装するための変更制御手続きには、次を含める必要があります。

• 6.4.5.1 影響に関するドキュメント。
• 6.4.5.2 承認者による変更の承認書。
• 6.4.5.3 変更がシステムのセキュリティに悪影響を及ぼさないことを確認する機能テスト。
• 6.4.5.4 バックアウト手続き。

お客様の責任

これらのガイダンス ポイントは、前の要件に対応しています。

• セキュリティ パッチとソフトウェア変更の結果として予想されるインフラストラクチャの変更をドキュメントにします。 コードとしてのインフラストラクチャ (IaC) アプローチを使用すると、そのプロセスが簡単になります。 たとえば、デプロイ用の Azure Resource Manager テンプレート (ARM テンプレート) を使用すると、What-If 操作で変更をプレビューできます。 詳細については、インフラストラクチャの変更に関する「ARM テンプレート デプロイの What-If 操作」を参照してください。

• 定期的なデプロイの変更の承認を検証するゲートをデプロイ パイプラインに実装します。 ゲートがバイパスされた可能性がある緊急デプロイの正当な理由をドキュメントにします。

  変更のレベルと深さを定義します。 軽微な変更とは異なり、重要な変更の定義についてはチームが同意するようにします。 実用的な場合は、そのような変更の一部の検出を自動化します。 ワークロード、インフラストラクチャ、パイプラインのレビュー担当者は、レベルを明確に理解し、それらの条件に対して検証する必要があります。

• セキュリティ アフォーダンスをテストします。 代理トランザクションによってセキュリティ (許可と拒否の両方) の問題がテストされるようにします。 また、それらの代理テストが運用前環境で実行されるようにします。

• セキュリティ修正プログラムで予期しない結果が発生した場合に備えて、バックアウト プロセスを用意します。 一般的な戦略は、ブルーグリーン デプロイを使用して以前の状態をデプロイすることです。 データベースを含むワークロードの場合、特定のトポロジに対して機能し、デプロイの単位を対象とする戦略を設けます。

要件 6.5

以下のような、ソフトウェア開発プロセスでよく見られるコーディングに関する脆弱性に対処します。

• 一般的なコーディングの脆弱性を回避する方法を含め、セキュリティ上安全な最新のコーディング技法について、年 1 回以上、開発者をトレーニングします。
• セキュリティ上安全なコーディングのガイドラインに基づいてアプリケーションを開発します。

お客様の責任

ワークロードとインフラストラクチャのスキャン アクティビティをサポートするために、アプリケーション チームと運用チームへの教育、情報提供、動機付けを行う必要があります。 次にリソースをいくつか示します。

• 安全なコーディングのガイドライン
• セキュリティで保護された DevOps
• 開発ライフサイクルのセキュリティ保護に関するリソース

要件 6.6

公開された Web アプリケーションの場合、新しい脅威と脆弱性に継続的に対処します。 次のいずれかの方法によって、これらのアプリケーションを既知の攻撃から保護します。

• 手動または自動のアプリケーション脆弱性セキュリティ評価のツールまたは方法を使用して、公開された Web アプリケーションをレビューします。 少なくとも年 1 回、および変更を加えた後に、脆弱性評価を実行します。

  注意

  この評価は、要件 11.2 の一部として実行される脆弱性のスキャンとは異なります。

• Web ベースの攻撃を検出して防止する自動ソリューションをインストールします。 たとえば、Web アプリケーション ファイアウォールです。 公開された Web アプリケーションの前にデプロイし、すべてのトラフィックをアクティブに評価します。

お客様の責任

Web アプリケーション ファイアウォール (WAF) を使用して、パブリック インターネットからのトラフィックを検出するチェックを実施します。 このアーキテクチャでは、Azure Application Gateway でその統合された WAF を使用してすべての受信トラフィックをチェックします。 WAF は、Open Web Application Security Project (OWASP) のコア ルール セット (CRS) に基づいています。 技術のコントロールが設けられていない場合は、それを補うコントロールを用意します。 1 つの方法は、手動でコードを検査することです。

ルール セットの最新バージョンを使用し、ワークロードに関連するルールを適用します。 ルールは防止モードで実行する必要があります。 WAF が有効になっているかどうか、およびそのモードで動作しているかどうかをチェックする Azure Policy インスタンスを追加することで、その要件を適用できます。

Application Gateway WAF によって生成されたログを保持して、検出された脅威に関する詳細を取得します。 必要に応じてルールを微調整します。

アプリケーションのコードに焦点を当てた侵入テストを実施します。 そうすることで、アプリケーション チームの一員ではない実施者が、情報の収集、脆弱性の分析、レポートにより、セキュリティのギャップ (SQL インジェクションやディレクトリ トラバーサルなど) を発見します。 この演習では、実施者による機密データへのアクセスが必要になる場合があります。 意図が誤用されていないことを確認するには、「侵入テストの実施ルール」で示されているガイダンスに従います。

要件 6.7

セキュリティ保護されたシステムおよびアプリケーションを開発および維持するためのセキュリティ ポリシーと運用手順が文書化され、使用され、すべての関係者に周知されていることを確認します。

お客様の責任

プロセスとポリシーに関する詳細なドキュメントを保持することが重要です。 ワークロードのライフサイクルと運用の一環として、セキュリティの選択の優先順位付けに関するトレーニングをチームに実施する必要があります。

Microsoft SDL により、開発プロセスのフェーズ全体を通じたセキュリティのためのベスト プラクティス、ツール、プロセスが提供されます。 Microsoft は内部的に、Microsoft SDL のプラクティスに厳格に従って、ソフトウェアを構築しています。 また、クラウド サービス運用のための Operational Security Assurance (OSA) フレームワークにも従っています。 アプリケーションのセキュリティ保護に役立つよう、これらのプラクティスは公開されています。

• Microsoft SDL
• Microsoft OSA

テストの範囲、トリアージ プロセス、検出された問題の修復戦略が説明されている侵入テストの詳細なドキュメントを保持します。 インシデントが発生した場合は、根本原因分析の一環として要件 6 の評価を組み込みます。 ギャップが検出された場合は (たとえば、OWASP ルールの違反が検出された場合)、それらのギャップを埋めます。

ドキュメントでは、想定される WAF 保護状態に関する明確なガイドラインを示します。

確実なセキュリティを実現するために、規制対象の環境の運用担当者に対し、教育を行い、情報を提供し、動機付けを行う必要があります。 これは、ポリシーの観点から承認プロセスに関わっている担当者にとって重要です。

次の手順

業務上の知る必要によってカード所有者データへのアクセスを制限します。 システム コンポーネントへのアクセスを識別して認証を行います。 カード所有者データへの物理的なアクセスを制限します。