Anthos Service Mesh セキュリティの概要

Anthos Service Mesh セキュリティは、ワークロード間のすべての通信が確実に暗号化、相互認証、承認されるようにすることで、インサイダー脅威の緩和データ侵害のリスク軽減に役立ちます。

従来より、IP ベースのルールを使用するマイクロ セグメンテーションは、インサイダー リスクを緩和するために使用されています。ただし、コンテナ、共有サービス、複数のクラウドに分散した本番環境を採用すると、このアプローチは構成が難しくなり、維持がさらに難しくなります。

Anthos Service Mesh では、サービス コンテキスト アウェアとリクエスト コンテキスト アウェアのネットワーク セキュリティ レイヤを構成できます。これは、基盤となるネットワークのセキュリティから独立しています。このため、Anthos Service Mesh では、ゼロトラストのセキュリティ原則と整合した多重防護体制を採用できます。宣言型ポリシーにより、アプリケーション コードを一切変更せずにこの体制を実現できます。

相互 TLS

Anthos Service Mesh では、ピア認証に相互 TLS(mTLS)を使用します。認証とは、身元を確認するためのプロセスです。たとえば、このサービスの名前は何か、このエンドユーザーは誰なのか、自己申告されている身元を信頼できるのかといった点を確認できます。

mTLS を使用すると、ワークロード同士が ID を相互に識別し、互いに認証を行うことができます。HTTPS では、ブラウザがウェブサーバーを信頼し、暗号化されたデータを交換するためにシンプルな TLS が使用されています。シンプルな TLS では、クライアントは証明書を検証してサーバーが信頼できるかどうか確認します。mTLS は、クライアントとサーバーの両方が相互に証明書を提示し、互いの ID を検証します。

Anthos Service Mesh では、mTLS を使用してサービス間の認証と暗号化の両方を行います。

Anthos Service Mesh 1.6 以降では、自動 mTLS はデフォルトで有効になっています。自動 mTLS の場合、クライアント サイドカー プロキシがサーバーにサイドカーがあるかどうかを自動的に検出します。クライアント サイドカーは、サイドカーを含むワークロードには mTLS を送信し、サイドカーを含まないワークロードには書式なしテキストを送信します。ただし、サービスは書式なしテキストと mTLS トラフィックの両方を受け入れます。サービス メッシュを保護するには、mTLS トラフィックのみを受け入れるようにサービスを移行することをおすすめします。

mTLS のみを適用する方法については、Anthos Service Mesh の例: mTLS をご覧ください。

暗号スイートの構成

次のリストには、Anthos Service Mesh のデフォルトの FIPS 遵守暗号スイートが含まれています。

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384

Anthos Service Mesh ワークロードでサポートされているサーバーサイドの最小 TLS バージョンは、1.2 です。このバージョンは暗号スイートのカスタマイズをサポートしており、セキュリティを強化できます。Anthos Service Mesh は TLS v1.3 もサポートしていますが、このバージョンには暗号スイートがハードコードされていて、変更することはできません

暗号スイートの詳細については、Envoy の共通 TLS 構成Istio の相互 TLS 認証をご覧ください。

セキュリティ上のメリット

Anthos Service Mesh には次のようなセキュリティ上のメリットがあります。

  • 盗まれた認証情報によるリプレイまたはなりすまし攻撃のリスクを軽減する。Anthos Service Mesh では、JSON Web Token(JWT)などの署名なしトークンではなく、mTLS 証明書を使用してピアを認証します。mTLS 証明書は TLS チャネルにバインドされているため、本番環境内のエンティティが秘密鍵にアクセスせずに認証トークンをリプレイするだけで他人になりすますことはできません。

  • 通信中の暗号化を保証する。認証に mTLS を使用すると、すべての TCP 通信が通信中に暗号化されます。

  • 承認されたクライアントだけが機密データを含むサービスにアクセスできるように保証します。クライアントのネットワークのロケーションやアプリケーション レベルの認証情報にかかわらず、承認されたクライアントだけが機密データを含むサービスにアクセスできます。承認されたサービス ID を持つクライアント、または承認された Kubernetes 名前空間のクライアントだけが、サービスにアクセスできるように指定できます。IP ベースのアクセス ポリシーを使用して、GKE Enterprise 環境の外でデプロイされたクライアントにアクセス権を付与することもできます。

  • 本番環境ネットワーク内でユーザーデータ侵害のリスクを軽減する。インサイダーが機密データにアクセスするときには、必ず承認されたクライアントを使用するようにします。さらに、特定のクライアントが、有効期間が短い有効なユーザー トークンを提示できる場合にのみ、ユーザーデータへのアクセスが許可されます。これにより、単一のクライアント認証情報の漏えいですべてのユーザーデータがアクセスされるリスクを軽減できます。

  • 機密データのあるサービスにアクセスしたクライアントを識別する。Anthos Service Mesh のアクセス ロギングを使用すると、IP アドレスだけでなく、クライアントの mTLS ID も収集できます。ワークロードがエフェメラルで動的にデプロイされている場合や、別のクラスタまたは Virtual Private Cloud(VPC)ネットワーク内にある場合でも、サービスにアクセスしたワークロードを簡単に把握できます。

機能

このセクションでは、Anthos Service Mesh がセキュリティ上のメリットを実現するために提供する機能について説明します。

証明書と鍵のローテーション

サービス ID に基づく mTLS を使用して、すべての TCP 通信を暗号化します。アクセス制御で、より安全で再現不能な認証情報を使用します。大規模な環境で mTLS を使用する場合、すべてのターゲット ワークロードの鍵と証明書の管理が課題となります。Anthos Service Mesh では、通信を中断することなく、GKE Enterprise ワークロードの mTLS 鍵と証明書のローテーションを管理します。リスクを軽減するには、証明書の更新間隔を短くします。

Anthos Service Mesh 認証局(Mesh CA)

Anthos Service Mesh では、マネージド マルチリージョン認証局(Mesh CA)で mTLS の証明書を発行します。Mesh CA は信頼性とスケーラビリティに優れたサービスで、クラウド プラットフォーム上で動的にスケーリングされるワークロード用に最適化されています。Mesh CA を使用する場合、Google は CA バックエンドのセキュリティと可用性を管理します。Mesh CA を使用すると、GKE Enterprise クラスタ間で単一のルート オブ トラストを使用できます。Mesh CA では、Workload Identity プールを利用して、きめ細かい分離を実現できます。デフォルトでは、クライアントとサーバーが同じ Workload Identity プールにないと認証が失敗します。

Mesh CA からの証明書には、アプリケーションのサービスに関する次のデータが含まれます。

  • Google Cloud プロジェクト ID。
  • GKE 名前空間
  • GKE サービス アカウント名

Certificate Authority Service

Mesh CA の代わりに、Certificate Authority Service を使用するように Anthos Service Mesh を構成できます。これは、次のユースケースに適しています。

  • 異なるクラスタ上のワークロード証明書への署名に別の認証局が必要な場合。
  • Istiod カスタム CA プラグイン証明書を使用する場合。
  • マネージド HSM に署名鍵を元に戻す必要がある場合。
  • 規制の厳しい業界で、コンプライアンスの対象となっている場合。
  • Anthos Service Mesh CA をカスタム エンタープライズ ルート証明書のチェーンに追加して、ワークロード証明書に署名する場合。

メッシュ CA の費用は Anthos Service Mesh の料金に含まれています。CA Service は Anthos Service Mesh の基本料金に含まれず、別途課金されます。また、CA Service には明示的な SLA が提供されますが、Mesh CA には提供されません。

このインテグレーションでは、Anthos Service Mesh のワークロードすべてに次の 2 つの IAM ロールが付与されます。

ID に基づくアクセス制御(ファイアウォール)ポリシー

Anthos Service Mesh では、ピアの IP アドレスに対する mTLS ID に基づいてネットワーク セキュリティ ポリシーを構成できます。これにより、ワークロードのネットワーク上の場所に関係なくポリシーを作成できます。現在、同じ Google Cloud プロジェクトのクラスタ間の通信のみがサポートされています。

リクエスト クレームに基づくアクセス制御(ファイアウォール)ポリシー

mTLS ID に加えて、HTTP または gRPC リクエストの JWT ヘッダー内のリクエスト クレームに基づいてアクセス権を付与できます。Anthos Service Mesh では、信頼できるエンティティによって JWT が署名されていることを保証できます。つまり、リクエスト クレームが存在するか、指定した値と一致する場合にのみ、特定のクライアントからのアクセスを許可するポリシーを構成できます。

Identity-Aware Proxy によるユーザー認証

Identity-Aware Proxy(IAP)を使用して、Anthos Service Mesh Ingress ゲートウェイで公開されているサービスにアクセスするユーザーを認証します。IAP は、ブラウザからログインするユーザーを認証し、カスタム ID プロバイダと連携して有効期間が短い JWT トークンや RCToken を発行できます。これにより、Ingress ゲートウェイまたはダウンストリーム サービス(サイドカーを使用)にアクセス権を付与できます。詳細については、IAP と Anthos Service Mesh の統合をご覧ください。

既存の ID プロバイダでのユーザー認証

既存の ID プロバイダを Anthos Service Mesh と統合すると、デプロイされるワークロードにブラウザベースのエンドユーザー認証とアクセス制御を提供できます。詳細については、Anthos Service Mesh ユーザー認証の構成をご覧ください。

ロギングとモニタリングへのアクセス

Anthos Service Mesh では、Google Cloud Observability でアクセスログと指標を使用できます。また、統合ダッシュボードで、このデータに基づくサービスまたはワークロードのアクセス パターンを把握できます。限定公開の宛先を構成することもできます。Anthos Service Mesh では、成功したアクセスのログを期間内に 1 回だけ記録します。これにより、アクセスログのノイズが少なくなります(この期間はユーザーが構成できます)。セキュリティ ポリシーで拒否されたリクエストや、エラーになったリクエストは常にログに記録されます。これにより、重要なセキュリティ シグナルを失うことなく、ログの取り込み、保存、処理に関連する費用を著しく削減できます。

FIPS 遵守

x86 アーキテクチャのすべてのクラスタ内コントロール プレーン コンポーネントとプロキシで、FIPS 140-2 認証取得済みの暗号化モジュールが使用されます。

制限事項

現在、Anthos Service Mesh のセキュリティには、次の制限事項があります。

  • IAP を使用するユーザー認証では、サービスがインターネットに公開されている必要があります。IAP と Anthos Service Mesh では、ポリシーを構成して、許可する IP 範囲内にある認可済みユーザーおよびクライアントへのアクセスを制限できます。同じネットワーク内のクライアントにのみサービスを公開する場合は、ユーザー認証とトークン発行用にカスタム ポリシー エンジンを構成する必要があります。

次のステップ