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 などのオープンソースも使用できます。 サード パーティ製ソフトウェアが最新の状態であることを確認するプロセスを設けるのは、お客様の責任です。 また、ソリューションを監視してアラートを出すのもお客様の責任です。

要件 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 と統合されます。 Microsoft Defender for Cloud の継続的なスキャン機能を備えた Azure Container Registry を使用して、さまざまなリスク レベルの脆弱なイメージとアプリケーションを識別します。 イメージ スキャンとリスク制御については、「Microsoft Defender for Containers」を参照してください。

お客様の責任

要件 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 for Endpoint のウイルス対策更新プログラムの適用方法については、「Microsoft Defender ウイルス対策のセキュリティ インテリジェンスと製品の更新プログラム」を参照してください。

要件 5.3

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

お客様の責任

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

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

要件 5.4

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

お客様の責任

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

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

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

要件 6.1

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

お客様の責任

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

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

詳細については、「Defender for Cloud でのコンテナー保護」を参照してください。

要件 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) を精査します。 また、

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

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

• イメージのサイズを減らします。 通常、イメージには必要以上のバイナリが含まれています。 イメージのサイズを小さくすると、パフォーマンスが向上するだけでなく、攻撃対象領域も制限されます。 たとえば、distroless イメージを使用すると、ベース 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) アプローチを使用すると、そのプロセスが簡単になります。 たとえば、Bicep ファイルまたは Azure Resource Manager テンプレート (ARM テンプレート) を使用すると、what-if 操作を使用してデプロイの変更をプレビューできます。 詳細については、インフラストラクチャの変更に関する Bicep デプロイメントの 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) の Core Rule Set (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 保護状態に関する明確なガイドラインを示します。

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

次の手順

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