Azure Well-Architected Framework は、アーキテクチャ エクセレンスの品質の重要な要素によってソリューションを評価するために使用できる一連の基本原則です。
この記事で、このシリーズは終了します。 概要を参照してください。
このシリーズで提供されているこのガイダンスには、設計上のすべての選択に Well-Architected の原則が組み込まれています。 この記事では、それらの選択をまとめています。 該当する場合、GitHub: 規制対象ワークロード向け Azure Kubernetes Service (AKS) ベースライン クラスターの実装で、それらの原則について説明しています。
PCI DSS 3.2.1 ワークロードには、Well-Architected ソリューションとしての厳格さが求められます。 インフラストラクチャを PCI 要件に合わせることは重要ですが、コンプライアンスはインフラストラクチャのホストに留まりません。 品質の重要な要素、特にセキュリティに対処しないと、コンプライアンスを損なう可能性があります。 Well-Architected ソリューションでは、インフラストラクチャとワークロードの両方の観点を組み合わせることで、結果の準拠を実現するために必要な厳格さを満たすことができます。
Security
「セキュリティ設計原則」に記載されている基本的なガイダンスに従います。 これらのセクションでは、規制対象環境のベストプラクティスをまとめています。
ガバナンス
ガバナンスの実装は、PCI DSS 3.2.1 のコンプライアンス要件によって決まります。 これは、セグメント化の管理、リソースへのアクセス、脆弱性の検出、さらに最も重要である顧客データの保護の技術的な制御に影響します。
企業のセグメント化戦略
完全な分離を維持するには、スタンドアロン サブスクリプションで規制対象インフラストラクチャをデプロイすることが推奨されます。 コンプライアンスに必要な複数のサブスクリプションがある場合は、対象のサブスクリプション全体に関連 Azure ポリシーを一様に適用する管理グループ階層下でループ化することを検討してください。 サブスクリプション内で、関連 Azure ポリシーをサブスクリプション レベルで適用して、カード会員データ環境 (CDE) 内のすべてのクラスターに適用する必要がある広範なポリシーをキャプチャします。 関連 Azure ポリシーをリソース グループ レベルで適用し、特定のクラスター インスタンスに適用するポリシーをキャプチャします。 これらのポリシーにより、ランディング ゾーンの中核となるガードレールを構築します。
運用と接続に関して、PCI ワークロード (対象) を他の (対象外) ワークロードから分離します。 分離を作成するには、個別のクラスターにデプロイします。 または、セグメント化戦略を使用して、分離を維持します。 たとえば、クラスターで個別のノード プールを使用して、ワークロードがノード仮想マシン (VM) を共有しないようにします。
ポリシーの適用
Azure ポリシーを有効にして、セキュリティ制御を適用します。 たとえば、この規制対象アーキテクチャでは、カード会員データ環境の構成の誤りを防ぐことができます。 VM ノードへのパブリック IP の割り当てを許可しない Azure ポリシーを適用できます。 このような割り当ては検出され、報告されるかブロックされます。
AKS で有効にできるポリシーの詳細については、「Azure Kubernetes Service 用の Azure Policy 組み込み定義」を参照してください。
Azure には、ほとんどのサービスに対応するいくつかの組み込みのポリシーが用意されています。 これらの Azure Policy 組み込みポリシー定義を確認し、必要に応じて適用します。
コンプライアンスの監視
コンプライアンスは体系的に監視し、維持する必要があります。 標準のコンプライアンス構成証明が実行されます。 クラウド リソースが準拠しているかどうかを把握することは、構成証明と監査の準備に役立ちます。
Microsoft Defender for Cloud の法令遵守ダッシュボードを活用してください。 ダッシュボードを継続的に監視することにより、ワークロードのコンプライアンスの状態を追跡できます。
ネットワークのセキュリティ
ハブスポーク トポロジでは、エンティティごとに個別の仮想ネットワークを使用することで、ネットワーク フットプリントに基本的なセグメント化を提供します。 各ネットワークはさらにサブネットにセグメント化されます。
AKS クラスターは、CDE の中核を形成します。 パブリック IP アドレスからアクセスできず、接続をセキュリティで保護する必要があります。 CDE を出入りする一般的なフローは、次のように分類できます。
- クラスターへの受信トラフィック。
- クラスターからの送信トラフィック。
- ポッド間のクラスター内トラフィック。
規制対象環境の要件を満たすために、クラスターはプライベート クラスターとしてデプロイされます。 このモードでは、パブリック インターネットとの間のトラフィックが制限されます。 AKS によって管理される Kubernetes API サーバーとの通信もプライベートです。 セキュリティは、厳密なネットワーク制御と IP ファイアウォール規則によってさらに強化されます。
- ネットワーク内のリソース間のセキュリティで保護された通信に役立つネットワーク セキュリティ グループ (NSG)。
- クラウド リソース、インターネット、およびオンプレミス間のすべての送信トラフィックをフィルター処理する Azure Firewall。
- Azure Application Gateway がインターセプトするインターネットからのすべての受信トラフィックをフィルター処理するための、Azure Web Application Framework に統合された Azure Application Gateway。
- クラスター内のポッド間で特定のパスのみを許可する Kubernetes ネットワーク ポリシー。
- 運用タスクのために、Azure Key Vault や Azure Container Registry などの他の Azure のサービスとしてのプラットフォーム (PaaS) サービスに接続する Azure Private Link。
トラフィックが予期したとおりにフローし、すべての異常が検出され、報告されることを確認するための監視プロセスが用意されています。
ネットワーク セキュリティの詳細については、ネットワークのセグメント化に関するページを参照してください。
データのセキュリティ
PCI DSS 3.2.1 では、転送中も保存中も、すべてのカード会員データ (CHD) が明かされることがないようにする必要があります。
このアーキテクチャと実装は、ワークロードではなくインフラストラクチャに焦点を合わせているため、データ管理については説明しません。 以下に、Well-Architected の推奨事項をいくつか示します。
保存データ
データは、業界標準の暗号化アルゴリズムを使用して暗号化する必要があります。
- カード会員環境にデータを保存しないでください。
- ストレージ レイヤーの外部で暗号化します。
- 暗号化されたデータのみをストレージ メディアに書き込みます。
- キーをストレージ レイヤーに保存しないでください。
Azure Storage 内のすべてのデータは、強力な暗号を使用して暗号化および復号化します。 自己管理型暗号化キーが推奨されています。
データを一時的に保存する必要がある場合は、そのデータに同じ考慮事項を適用します。 AKS のホスト暗号化機能を有効にすることが強く推奨されます。 組み込みの Azure ポリシーを使用して、一時データの暗号化を適用できます。
ストレージ テクノロジを選択する場合は、保持機能を確認してください。 構成された時間が経過したら、すべてのデータが安全に削除されることを確認します。
標準では、機密認証データ (SAD) が保存されないことも必要とされます。 データがログ、ファイル名、キャッシュ、およびその他のデータで公開されていないことを確認します。
転送中のデータ
CDE とやりとりするエンティティとのすべての通信が、暗号化されたチャネルを経由する必要があります。
- HTTPS トラフィックのみが CDE へのフローが許可される必要があります。 このアーキテクチャでは、Azure Application Gateway で、ポート 80 経由のすべてのトラフィックが拒否されます。
- 可能であれば、CDE の外部でデータを暗号化および復号化しないでください。 そうする場合は、そのエンティティを CDE の一部にすることを検討してください。
- CDE 内では、mTLS によって、ポッド間のセキュリティで保護された通信を提供します。 この目的のためにサービス メッシュを実装することを選択できます。
- 安全な暗号と TLS 1.2 以降のみを許可します。
ID
アクセス ポリシーを設計するときは、次のセキュリティ原則に従ってください。
- ゼロトラスト ポリシーから始めます。 必要に応じて、例外を認めます。
- タスクを完了するのに十分なだけの最小限の特権を付与します。
- 永続的なアクセスを最小限にします。
Kubernetes ロールベースのアクセス制御 (RBAC) によって、Kubernetes API へのアクセス許可を管理します。 AKS では、それらの Kubernetes ロールがサポートされています。 AKS は Microsoft Entra ID と完全に統合されています。 ロールに Microsoft Entra ID を割り当てることができ、その他の機能を利用することもできます。
ゼロトラスト アクセス
既定で、Kubernetes RBAC、Azure RBAC、および Azure サービスでは、すべて拒否が実装されます。 この設定を慎重にオーバーライドして、アクセスを必要とするエンティティのみにアクセスを許可します。 ゼロトラストを実装するもう 1 つの領域は、クラスターノードへの SSH アクセスを無効にすることです。
最小限の特権
Azure のリソースとポッドにマネージド ID を使用し、それらを予想されるタスクにスコープ設定できます。 たとえば、Azure Application Gateway には、Azure Key Vault からシークレット (TLS 証明書) を取得するためのアクセス許可が必要です。 シークレットを変更するアクセス許可を持たせないようにする必要があります。
永続的なアクセスの最小化
Just-In-Time Microsoft Entra グループ メンバーシップを使用して、永続的なアクセスを最小限に抑えます。 Microsoft Entra ID の条件付きアクセス ポリシーによって制御を強化します。 このオプションでは、多要素認証、Microsoft Entra テナントによって管理されるデバイスに対する認証の制限、通常とは異なるサインイン試行のブロックなどの多くのユースケースがサポートされています。
シークレットの管理
シークレット、証明書、キー、およびパスワードは、CDE の外部に保存します。 ネイティブの Kubernetes シークレット、または Azure Key Vault などのマネージド キーストアを使用できます。 マネージド ストアを使用すると、キーのローテーションや証明書の更新などのシークレット管理タスクに役立ちます。
キー ストアへのアクセスで、ネットワーク制御とアクセス制御のバランスが取れていることを確認します。 マネージド ID を有効にする場合、クラスターが Key Vault に対して自身を認証し、アクセスできるようにする必要があります。 さらに、キー ストアへの接続が、パブリック インターネットを経由しないようにする必要があります。 プライベート リンクなどのプライベート ネットワークを使用します。
オペレーショナル エクセレンス
オペレーショナル エクセレンスの原則に記載されている基本ガイダンスに従います。 これらのセクションでは、規制対象環境のベストプラクティスをまとめています。
役割の分離
規制対象環境には明確な義務の分離を適用することが重要です。 ワークロードのニーズと CDE との対話に基づいて、ロールと責任を定義します。 たとえば、クラスターおよび依存サービスに関連する操作には、インフラストラクチャ オペレーターまたはサイト信頼性エンジニア (SRE) のロールが必要になる可能性があります。 このロールは、セキュリティ、分離、デプロイ、および可観測性の維持を担当します。 それらの定義を形式化し、それらのロールに必要なアクセス許可を決定します。 たとえば、SRE はクラスター アクセスに対して高度な特権を持ちますが、ワークロード名前空間への読み取りアクセス権が必要です。
ワークロードの分離
PCI-DSS 3.2.1 では運用に関して、PCI ワークロードを他のワークロードから分離する必要があります。 この実装では、対象ワークロードと対象外ワークロードを、2 つの個別のユーザー ノード プールにセグメント化します。 対象ワークロードのアプリケーション開発者と、対象外ワークロードの開発者は、異なるアクセス許可のセットを持つことがあります。 また、個別の品質ゲートがあります。 たとえば、対象コードではコンプライアンスと構成証明を守る必要がありますが、対象外のコードでは必要ありません。 また、個別のビルド パイプラインとリリース管理プロセスを使用する必要もあります。
運用メタデータ
PCI DSS 3.2.1 標準の要件 12 では、ワークロード インベントリと職員のアクセスのドキュメントに関する情報を保持する必要があります。 環境情報を Azure リソース、リソース グループ、およびサブスクリプションと照合できるため、Azure タグを使用することが強く推奨されます。
インフラストラクチャとワークロードの一部である承認済みソリューションに関する情報を保持します。 これには、CDE に取り込む選択した VM イメージ、データベース、およびサードパーティ ソリューションの一覧が含まれます。 サービス カタログを構築して、そのプロセスを自動化することもできます。 それにより、特定の構成でそれらの承認済みソリューションを使用して、実行中のプラットフォーム運用に準拠するセルフサービス デプロイを実現します。
可観測性
要件 10 を満たすために、CDE への可観測性はコンプライアンスに不可欠です。 アクティビティ ログは、アカウントとシークレットの管理に関連する操作に関する情報 (診断設定の管理、サーバー管理、その他のリソース アクセス操作) を提供します。 すべてのログには、日付、時刻、ID、その他の詳細情報が記録されます。 Azure Monitor Logs でデータの保持ポリシーとアーカイブ ポリシー を構成して、ログを最大 1 年間保持します。
ログには、それらを必要とするロールだけがアクセスすることを確認します。 Log Analytics と Microsoft Sentinel では、監査証跡アクセスを管理するためのさまざまなロールベースのアクセス制御がサポートされています。
応答と修復
Azure 監視サービスの Azure Monitor と Microsoft Defender for Cloud では、異常なアクティビティを検出したときに通知またはアラートを生成できます。 これらのアラートには、重大度、状態、アクティビティの時刻などのコンテキスト情報が含まれます。 アラートが生成されたら、修復戦略を設定し、進行状況を確認します。 データを統合することで、豊富なアラート コンテキストを提供できるため、セキュリティ情報とイベント管理 (SIEM) ソリューションにデータを一元化することが推奨されます。
Microsoft Defender for Cloud の [セキュリティ アラート] ビューから、Microsoft Defender for Cloud がリソースで検出したすべてのアラートにアクセスできます。 問題に対処するトリアージ プロセスを設定します。 セキュリティ チームと協力して、ワークロード所有者が関連アラートを利用できるようにする方法を理解します。
パフォーマンス効率
「パフォーマンス効率の原則」に記載されている基本ガイダンスに従います。 これらのセクションでは、規制対象環境のベストプラクティスをまとめています。
Scaling
変化する要求に合わせて環境がどのように調整されるかを観察すると、負荷の高い環境で予想される実行時動作が示されます。 ワークロード内のリソースの自動スケールによって、CDE での人による操作が最小限に抑えられます。 追加されたセキュリティ上の利点によって、常に攻撃面が減少します。 scale-to-zero (0 へのスケーリング) アプローチをサポートするリソースを利用することで、利点を最大化できます。 たとえば、AKS では、ユーザー ノード プールの 0 へのスケールダウンをサポートしています。 詳細については、「User ノード プールを 0 にスケーリングする」を参照してください。
パーティション分割
パーティション分割は、規制対象ワークロードのパフォーマンス効率の重要な要素です。 個別のコンポーネントを使用することで、責任を明確に定義することができ、ネットワーク ポリシーなどの正確な制御に役立ちます。 セグメント化戦略と同様に、パーティション分割によってコンポーネントを分離し、予期しない障害やシステム侵害の爆発半径の影響を制御します。
シェアード ナッシング アーキテクチャ
シェアード ナッシング アーキテクチャは、併置されたワークロード間の競合を除去するように設計されます。 また、これは単一障害点を除去するための戦略でもあります。 規制対象環境では、論理または物理境界によってコンポーネントを分離する必要があります。 これを、シェアード ナッシング アーキテクチャに合わせて調整することで、スケーラビリティに利益をもたらします。 また、関連するセキュリティ制御の対象を設定したり、さまざまなコンポーネントの監査機能を強化したりすることもできます。
軽量フレームワーク
ワークロードの複雑さによって、ドキュメント化と監査が困難になります。 パフォーマンス上の利点と、規制要件の監査の容易さのために、簡素化を追求してください。 攻撃可能な領域が増加し、誤用や構成の誤りの可能性が大きくなるため、必要以上の選択肢を評価します。
[信頼性]
規制対象環境の信頼性は、監査目的で一貫して説明できるように、予測可能である必要があります。 信頼性の原則に記載されている基本ガイダンスに従ってください。 これらのセクションでは、規制対象環境のベストプラクティスをまとめています。
回復ターゲットとディザスター リカバリー
規制対象ワークロードで処理されるデータの機密性のため、回復ターゲットと回復ポイントの目標 (RPO) を定義することが重要です。 CHD の許容できる損失は何でしょうか。 CDE 内の回復作業は、引き続き標準要件の対象となります。 障害を予測し、ロール、責任、および正当なデータ アクセスに適合するそれらの障害の明確な回復計画を策定します。 ライブサイトの問題は、あらゆる規制からの逸脱の正当な理由になりません。 これは、完全なディザスター リカバリーの状況で特に重要です。 要件に準拠し、予期しない CDE または CHD アクセスを最小限に抑える明確なディザスター リカバリー ドキュメントを用意します。 回復後に、常に回復プロセス手順を確認して、予期しないアクセスが発生していないことを確認します。 それらのインスタンスの業務上の正当な理由をドキュメント化します。
Recovery
回復力と回復戦略をアーキテクチャに追加すると、CDE へのアドホック アクセスの必要性を回避できます。 システムは、人による直接の介入を必要とせずに、定義された RPO で自己回復できる必要があります。 このように、緊急アクセスが認可されている個人に対しても、CHD の不要な公開を排除できます。 回復プロセスは監査可能である必要があります。
セキュリティ関連リスクへの対処
セキュリティ リスクは、ワークロードのダウンタイムとデータ損失の原因になる可能性があるため、それらを確認します。 セキュリティへの投資は、ワークロードの信頼性にも影響します。
運用プロセス
信頼性は、CDE 内および CDE に隣接するすべての運用プロセスにまで及びます。 イメージの構築やジャンプ ボックス管理などの注意事項の、適切に定義され、自動化された、テスト済みのプロセスを Well-Architected ソリューションに組み込みます。
コストの最適化
コストの最適化の原則に関するページに記載されている基本ガイダンスに従います。
コンプライアンス要件と厳密なセキュリティ制御のため、明確なトレードオフはコストです。 料金計算ツールを使用して、初期見積もりを立てることが推奨されます。
次に、このアーキテクチャで使用される主なリソースのコストへの影響の概要を示します。
主な推進要因は、ノード プールと Azure Firewall を構成する仮想マシン スケール セットです。 もう 1 つの要因は Log Analytics です。 また、選択したプランに応じて、Microsoft Defender for Cloud に関連する増分コストもあります。
サービスの価格を構成するものを明確に理解します。 Azure では従量制課金使用量が追跡されます。 次に、このアーキテクチャの Azure Firewall のドリルダウンを示します。
Azure Firewall などの一部のリソースに関連するコストは、複数の事業単位やアプリケーションに分散できます。 コストを最適化するもう 1 つの方法は、組織内でマルチテナント クラスターをホストし、ワークロードの多様性によって密度を最大化することです。 規制対象ワークロードには、このアプローチは推奨されません。 コスト上の利点よりもコンプライアンスとセグメント化を常に優先します。
予算の制約内に収めるために、コストを制御するいくつかの方法は、Azure Application Gateway インフラストラクチャを調整し、自動スケーリングのインスタンス数を設定し、PCI-DSS 3.2.1 によって必要とされる監査証跡を引き続き満たす限り、ログ出力を減らすことです。 常にそれらの選択肢を、SLA を満たすことができる設計の他の側面のトレードオフに対して評価します。 たとえば、トラフィックの急増に対応して適切にスケーリングできるかなどです。
Azure リソースのグループを作成する際は、コストを追跡できるようにタグを適用します。 コストの追跡と分析のために、Azure Advisor や Azure Cost Management などのコスト管理ツールを使用します。
Kubernetes 固有のコンストラクトによる詳細なクラスター インフラストラクチャ コストの割り当てに対して、AKS コスト分析を有効にすることを検討してください。