Anthos のセキュリティ設計図: ポリシーからの逸脱の監査とモニタリング

このドキュメントでは、Anthos クラスタに対する監査とモニタリングを実行し、セキュリティに関するベスト プラクティスおよびクラスタに接続したポリシーからの逸脱の有無を判断する方法について説明します。ポリシーに対する監査とモニタリングを実行する方法および理由の概要、さらにこのタスクに使用する Google Cloud コントロールについて説明します。

このドキュメントは、Anthos の使用に関する規範的なガイダンスを示す一連のブループリントの一部です。ブループリントの詳細については、Anthos セキュリティ ブループリント: よくある質問をご覧ください。

はじめに

クラスタには、アセットへのアクセスを保護できるようにするポリシーがあります。これらのポリシーからの逸脱に対して監査とモニタリングを実行することで、セキュリティを強化できます。監査とモニタリングでは、クラスタの現在のステータスを分析できますが、ポリシーを回避するアクションを阻止することはできません。変更を防ぐには、ポリシーを適用するための手順も実行する必要があります。

モニタリングは監査と類似していますが、目的がやや異なります。一般的なモニタリング ソリューションは、指標を収集する方法、システムとアプリのステータスを表示するダッシュボード、異常が検出されたときにアラートを送信する方法で構成されます。対照的に、監査はシステムのステータスを検証するために使用します。通常は、システムが満たす必要があるものとして定義した一連のポリシーに照らして検証を行います。

監査とモニタリングを行うには、次の要件を考慮する必要があります。

  • 実施している適用管理と、ポリシーからの逸脱を監査またはモニタリングする方法。
  • 統合されたモニタリング ソリューションと分離されたソリューションのどちらを必要とするか。

このブループリントに関連付けられている GitHub リポジトリの audit-monitor ディレクトリのコンテンツに、監査を設定するコントロールの構成方法と、ポリシーからの逸脱を監視するため使用できるモニタリング フレームワークが記載されています。

必要なセキュリティ管理について

このセクションでは、以下のことを行うために必要な制御について説明します。

  • ポリシーの適用ガイドに記載されているように、ポリシーの適用を補完する監査を実装する。

  • Anthos クラスタで動作するモニタリング ソリューションを、デプロイされているあらゆる場所で実装する。

Namespace

同じポリシーを使用するリソースにラベルを付ける

名前空間を使用すると、Pod、Service、レプリケーション コントローラなど、クラスタ内の関連付けられたリソースのスコープを指定できます。名前空間を使用することによって、関連付けられたリソースの管理責任を 1 つのユニットとして委任できます。したがって、名前空間はほとんどのセキュリティ パターンに不可欠です。

名前空間は、制御プレーンを分離するための重要な機能です。ただし、ノード分離、データプレーンの分離、ネットワークの分離を行うことはできません。

一般的な方法は、個別のアプリケーションの名前空間を作成することです。たとえば、アプリケーションの UI コンポーネントの Namespace myapp-frontend を作成できます。

Anthos Config Management

Anthos クラスタへの構成の適用

Anthos クラスタを管理する場合のおすすめの方法は、Anthos Config Management を使用することです。これにより、登録済みのクラスタが常に構成と同期されます。構成ファイルリポジトリに保存されている YAML または JSON ファイルです。このファイルには、kubectl apply コマンドを使用して手動でクラスタに適用できるものと同じタイプの構成情報が含まれています。Anthos Config Management を使用すると、宣言型のアプローチを採用することにより、アプリの場合と同様にポリシーとインフラストラクチャのデプロイを管理できます。

Anthos Config Management は、宣言されたポリシーの唯一の認証ソースとして機能する Git リポジトリと組み合わせて使用します。Anthos Config Management によって、RBAC、リソース割り当て、名前空間、プラットフォーム レベルでのインフラストラクチャのデプロイなどのアクセス制御ポリシーを管理できます。Anthos Config Management は宣言型です。クラスタの状態を継続的にチェックし、ポリシーを適用するために構成で宣言された状態を適用します。

Anthos Policy Controller

ポリシーの遵守の強制

Anthos Policy Controller は Kubernetes 向けの動的アドミッション コントローラで、Open Policy Agent(OPA)によって実行される CustomResourceDefinition ベース(CRD ベース)のポリシーを適用します。

アドミッション コントローラは、オブジェクトが永続化される前、かつリクエストが認証、承認された後に Kubernetes API サーバーへのリクエストをインターセプトする Kubernetes プラグインです。アドミッション コントローラを使用して、クラスタの使用方法を制限できます。

ポリシー コントローラを使用するには、制約テンプレートで一連の制約を宣言します。制約テンプレートがクラスタにデプロイされたら、制約テンプレートによって定義される個別の制約 CRD を作成できます。

次の図に、Policy Controller が OPA Constraint Framework を使用してポリシーを定義、適用する方法を示します。

OPA Constraint Framework はリクエストを受信し、他のリソースへのアクセスに関するポリシーを適用します。

この図は次のことを示しています。

  1. 制約は制約テンプレートから作成されます。
  2. クラスタでポリシーを有効にするには、制約を適用します。
  3. リクエストを受信するとアドミッションの審査がトリガーされ、許可または拒否の決定が行われます。
  4. 継続的な監査では、クラスタ上のすべてのアクティブなオブジェクトがポリシーに基づいて評価されます。

Policy Controller を使用すると、ラベルの適用などのカスタム ポリシーを適用できます。Policy Controller では、PodSecurityPolicy で適用できる制約の大半を適用できますが、通常は、次のような理由で運用上のオーバーヘッドを削減することが必要となります。

  • Policy Controller には、制約テンプレートを含むデフォルトのテンプレート ライブラリが含まれています。つまり、PodSecurityPolicy のように、一般的なケースを対象とする独自のポリシーを作成する必要はありません。
  • PodSecurityPolicy を使用する場合とは異なり、RoleBinding を管理する必要はありません。
  • ポリシー コントローラはドライラン モードをサポートしているため、制約を適用する前にその効果を検証できます。
  • ポリシーのスコープを名前空間に設定することで、より制限の厳しいポリシーを段階的に実行できます。これは、予期しない影響が生じる可能性があるロールアウト ポリシーの公開を管理するカナリア リリース戦略と類似しています。たとえば、Pod からボリュームへのアクセスを制限していても、その Pod が対象ボリュームへのアクセス権を付与されている必要があることがロールアウトの段階で判明することがあります。
  • Policy Controller は、カスタム制約か、Gatekeeper リポジトリで定義された PodSecurityPolicy の制約かにかかわらず、ポリシーを適用する 1 つの方法として使用できます。

ポリシー コントローラを使用して、定義したポリシーを適用する方法の詳細については、Anthos Config Management ポリシー コントローラをご覧ください。

GKE 用 Cloud Operations

GKE クラスタのモニタリング

GKE 用 Cloud Operations は、GKE クラスタをモニタリングするように設計されています。Cloud Monitoring サービスと Cloud Logging サービスをまとめて管理し、GKE クラスタ用にカスタマイズされた GKE 用 Cloud Operations ダッシュボードを備えています。GKE 用 Cloud Operations には、クラスタ、ノード、Pod、コンテナなどのリソースを表す一連の GKE のモニタリング対象リソースが用意されています。GKEAnthos clusters on VMware では、Cloud Operations for GKE を無効にできますが、これらのプロダクトでは有効にしておくことをおすすめします。

セキュリティ分析の状況

脆弱性の特定

Security Health Analytics では、Google Cloud リソースの潜在的な構成ミスやコンプライアンス違反を特定し、適切な対処方法を提案することによってインシデントの発生を防止できるようにします。Security Health Analytics スキャナは、Security Command Center で利用可能な脆弱性検出のタイプを生成します。コンテナ スキャナの検出結果は GKE コンテナの構成に関連し、CONTAINER_SCANNER スキャナタイプに属します。

Security Command Center と Pub/Sub の統合

通知アプリを使用して、Security Command Center から検出結果に関するアラートを受け取ることができます。アプリは通知 Pub/Sub トピックに登録し、構成されたチャネル(メールや SMS など)に通知を送信します。

Cloud Asset Inventory

Google Cloud リソースのモニタリング

Cloud Asset Inventory を使用すると、登録しているリソースやポリシーの変更をリアルタイムの通知によってモニタリングできます。組織、フォルダ、プロジェクト、または指定したその他のリソース内でサポートされているリソースタイプポリシータイプの変更をモニタリングできます。登録を設定するには、フィードを作成します。サポートされているアセットタイプには、GKE リソースタイプと IAM ポリシータイプがあります。

ファイアウォール ルールや IAM ポリシーの変更など、セキュリティが重視されるリソースをモニタリングできます。これらのリソースの変更が行われると、直ちに Pub/Sub から通知が送信され、必要に応じて迅速に対処できます。

リアルタイム通知は、既存のワークロードに接続します。この機能を使用すると、変更が検出された後にリソースの変更を元に戻すために Cloud Functions の関数を作成するなどのアクションを統合できます。

Cloud Audit Logs を使用したアラート

GKE クラスタは Kubernetes Audit LoggingCloud Audit LogsCloud Logging に統合します。GKE 用 Cloud Operations を使用して、ログエントリに基づいて指標を設定できます。その後、ログベースの指標を使用してアラート ポリシーを設定できます。

アラート ポリシーは通知チャネルを指定します。通知チャネルによって、アラート ポリシーがトリガーされたことを通知する方法を指定できます。通知ハンドラを設定するには、Cloud Run または Cloud Functions を使用して、対応措置(変更を元に戻す、メールで通知するなど)を講じます。

まとめ

コントロールを統合するには、監査とモニタリングに関するニーズを決定します。次に、このガイドで説明したコントロールの範囲と、コントロールを構成する必要があるステージを、次の手順で説明するようにマッピングします。

  1. クラスタの構成を開始する前に、ハイブリッドおよびマルチクラウドのモニタリングとロギングのパターンを参照して、必要な分離レベルを決定してください。
  2. クラスタを作成します。該当するクラスタ強化ガイド(GKE または Anthos clusters on VMware)のガイダンスに従います。クラスタを作成する場合は、強化ガイドに従って --enable-network-policy フラグを使用してください。その際、ネットワーク ポリシーが必要です。この手順により、クラスタ内の Pod 間を通過するトラフィックを制限するファイアウォール ルールを後で実装できます。
  3. Pod に必要な名前空間とラベルを定義します。これにより、ポリシーと Kubernetes サービス アカウントを操作できる名前スコープが指定されます。
  4. Anthos Config Management を使用してポリシー コントローラをインストールします。

    ポリシーの適用ガイドに記載されているガイダンスに従ってください。

  5. 要件を満たすように GKE 用 Cloud Operations を構成します。

  6. GKE 用 Cloud Operations のアラート ポリシー、通知、ハンドラを構成します。

  7. Cloud Asset Inventory からのリアルタイム通知を構成します。

  8. Security Health Analytics スキャンで生成されたコンテナの検出結果を定期的に確認するプロセスを設定します。