Cloud Service Mesh のセキュリティの概要
Cloud Service Mesh セキュリティは、ワークロード間のすべての通信が確実に暗号化、相互に認証、認可されるようにすることで、インサイダー脅威の緩和とデータ侵害のリスク軽減を支援します。
従来より、IP ベースのルールを使用するマイクロ セグメンテーションは、インサイダー リスクを緩和するために使用されています。ただし、コンテナ、共有サービス、複数のクラウドに分散した本番環境を採用すると、このアプローチは構成が難しくなり、維持がさらに難しくなります。
Cloud Service Mesh では、サービス コンテキスト アウェアとリクエスト コンテキスト アウェアのネットワーク セキュリティ レイヤを構成できます。これは、基盤となるネットワークのセキュリティから独立しています。このため、Cloud Service Mesh では、ゼロトラストのセキュリティ原則と整合した多重防護体制を採用できます。宣言型ポリシーにより、アプリケーション コードを一切変更せずにこの体制を実現できます。
相互 TLS
Cloud Service Mesh では、ピア認証に相互 TLS（mTLS）を使用します。 認証とは、身元を確認するためのプロセスです。たとえば、このサービスの名前は何か、このエンドユーザーは誰なのか、自己申告されている身元を信頼できるのかといった点を確認できます。
mTLS を使用すると、ワークロード同士が ID を相互に識別し、互いに認証を行うことができます。HTTPS では、ブラウザがウェブサーバーを信頼し、暗号化されたデータを交換するためにシンプルな TLS が使用されています。シンプルな TLS では、クライアントは証明書を検証してサーバーが信頼できるかどうか確認します。mTLS は、クライアントとサーバーの両方が相互に証明書を提示し、互いの ID を検証します。
Cloud Service Mesh では、mTLS を使用してサービス間の認証と暗号化の両方を行います。
Cloud Service Mesh 1.6 以降では、自動 mTLS はデフォルトで有効になっています。自動 mTLS の場合、クライアント サイドカー プロキシがサーバーにサイドカーがあるかどうかを自動的に検出します。クライアント サイドカーは、サイドカーを含むワークロードには mTLS を送信し、サイドカーを含まないワークロードには書式なしテキストを送信します。ただし、サービスは書式なしテキストと mTLS トラフィックの両方を受け入れます。サービス メッシュを保護するには、mTLS トラフィックのみを受け入れるようにサービスを移行することをおすすめします。
mTLS のみを適用する方法については、Cloud Service Mesh の例: mTLS をご覧ください。
暗号スイートの構成
次のリストには、Cloud Service Mesh のデフォルトの FIPS 遵守暗号スイートが含まれています。
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
Cloud Service Mesh ワークロードでサポートされているサーバーサイドの最小 TLS バージョンは、1.2 です。このバージョンは暗号スイートのカスタマイズをサポートしており、セキュリティを強化できます。Cloud Service Mesh は TLS v1.3 もサポートしていますが、このバージョンには暗号スイートがハードコードされていて、変更することはできません。
暗号スイートの詳細については、Envoy の共通 TLS 構成と Istio の相互 TLS 認証をご覧ください。
セキュリティ上のメリット
Cloud Service Mesh には次のようなセキュリティ上のメリットがあります。
盗まれた認証情報によるリプレイまたはなりすまし攻撃のリスクを軽減する。Cloud Service Mesh では、JSON Web Token（JWT）などの署名なしトークンではなく、mTLS 証明書を使用してピアを認証します。mTLS 証明書は TLS チャネルにバインドされているため、本番環境内のエンティティが秘密鍵にアクセスせずに認証トークンをリプレイするだけで他人になりすますことはできません。
通信中の暗号化を保証する。認証に mTLS を使用すると、すべての TCP 通信が通信中に暗号化されます。
承認されたクライアントだけが機密データを含むサービスにアクセスできるように保証します。クライアントのネットワークのロケーションやアプリケーション レベルの認証情報にかかわらず、承認されたクライアントだけが機密データを含むサービスにアクセスできます。承認されたサービス ID を持つクライアント、または承認された Kubernetes 名前空間のクライアントだけが、サービスにアクセスできるように指定できます。IP ベースのアクセス ポリシーを使用して、GKE Enterprise 環境の外でデプロイされたクライアントにアクセス権を付与することもできます。
本番環境ネットワーク内でユーザーデータ侵害のリスクを軽減する。インサイダーが機密データにアクセスするときに、承認されたクライアントを使用しなければなりません。さらに、特定のクライアントが、有効期間が短い有効なユーザー トークンを提示できる場合にのみ、ユーザーデータへのアクセスが許可されます。これにより、単一のクライアント認証情報の漏えいですべてのユーザーデータがアクセスされるリスクを軽減できます。
機密データのあるサービスにアクセスしたクライアントを識別する。Cloud Service Mesh のアクセス ロギングを使用すると、IP アドレスだけでなく、クライアントの mTLS ID も収集できます。ワークロードがエフェメラルで動的にデプロイされている場合や、別のクラスタまたは Virtual Private Cloud（VPC）ネットワーク内にある場合でも、サービスにアクセスしたワークロードを簡単に把握できます。
機能
このセクションでは、Cloud Service Mesh がセキュリティ上のメリットを実現するために提供する機能について説明します。
証明書と鍵のローテーション
サービス ID に基づく mTLS を使用して、すべての TCP 通信を暗号化します。アクセス制御で、より安全で再現不能な認証情報を使用します。大規模な環境で mTLS を使用する場合、すべてのターゲット ワークロードの鍵と証明書の管理が課題となります。Cloud Service Mesh では、通信を中断することなく、GKE Enterprise ワークロードの mTLS 鍵と証明書のローテーションを管理します。リスクを軽減するには、証明書の更新間隔を短くします。
Cloud Service Mesh 認証局
Cloud Service Mesh には、mTLS の証明書を発行するためのマネージド マルチリージョン非公開認証局（Cloud Service Mesh 認証局）が含まれています。Cloud Service Mesh 認証局は、信頼性とスケーラビリティに優れたサービスであり、クラウド プラットフォーム上で動的にスケーリングされるワークロード用に最適化されています。Cloud Service Mesh 認証局を使用して、Google は CA バックエンドのセキュリティと可用性を管理します。Cloud Service Mesh 認証局を使用すると、GKE Enterprise クラスタ間で単一のルート オブ トラストを使用できます。Cloud Service Mesh 認証局を使用する場合は、Workload Identity プールを利用して、きめの粗い分離を実行できます。デフォルトでは、クライアントとサーバーが同じ Workload Identity プールにないと認証が失敗します。
Cloud Service Mesh 認証局から発行された証明書には、アプリケーションのサービスに関する次のデータが含まれます。
- Google Cloud プロジェクト ID。
- GKE 名前空間
- GKE サービス アカウント名
Certificate Authority Service
Cloud Service Mesh 認証局の代わりに、Certificate Authority Service を使用するように Cloud Service Mesh を構成できます。Certificate Authority Service は次のユースケースに適しています。
- 異なるクラスタ上のワークロード証明書への署名に別の認証局が必要な場合。
- Istiod カスタム CA プラグイン証明書を使用する場合。
- マネージド HSM に署名鍵を元に戻す必要がある場合。
- 規制の厳しい業界で、コンプライアンスの対象となっている場合。
- Cloud Service Mesh CA をカスタム エンタープライズ ルート証明書のチェーンに追加して、ワークロード証明書に署名する場合。
Cloud Service Mesh 認証局の費用は Cloud Service Mesh の料金に含まれています。CA Service は Cloud Service Mesh の基本料金に含まれず、別途課金されます。また、CA Service には明示的な SLA が提供されますが、Cloud Service Mesh 認証局には提供されません。
この統合では、Cloud Service Mesh のワークロードすべてに次の 2 つの IAM ロールが付与されます。
ID に基づくアクセス制御（ファイアウォール）ポリシー
Cloud Service Mesh では、ピアの IP アドレスに対する mTLS ID に基づいてネットワーク セキュリティ ポリシーを構成できます。これにより、ワークロードのネットワーク上の場所に関係なくポリシーを作成できます。現在、同じ Google Cloud プロジェクトのクラスタ間の通信のみがサポートされています。
リクエスト クレームに基づくアクセス制御（ファイアウォール）ポリシー。
mTLS ID に加えて、HTTP または gRPC リクエストの JWT ヘッダー内のリクエスト クレームに基づいてアクセス権を付与できます。Cloud Service Mesh では、信頼できるエンティティによって JWT が署名されていることを保証できます。つまり、リクエスト クレームが存在するか、指定した値と一致する場合にのみ、特定のクライアントからのアクセスを許可するポリシーを構成できます。
Identity-Aware Proxy によるユーザー認証
Identity-Aware Proxy（IAP）を使用して、Cloud Service Mesh Ingress ゲートウェイで公開されているサービスにアクセスするユーザーを認証します。IAP は、ブラウザからログインするユーザーを認証し、カスタム ID プロバイダと連携して有効期間が短い JWT トークンや RCToken を発行できます。これにより、Ingress ゲートウェイまたはダウンストリーム サービス（サイドカーを使用）にアクセス権を付与できます。詳細については、IAP と Cloud Service Mesh の統合をご覧ください。
既存の ID プロバイダでのユーザー認証
既存の ID プロバイダを Cloud Service Mesh と統合すると、デプロイされるワークロードにブラウザベースのエンドユーザー認証とアクセス制御を提供できます。詳細については、Cloud Service Mesh ユーザー認証の構成をご覧ください。
ロギングとモニタリングへのアクセス
Cloud Service Mesh では、Google Cloud Observability でアクセスログと指標を使用できます。また、統合ダッシュボードで、このデータに基づくサービスまたはワークロードのアクセス パターンを把握できます。 限定公開の宛先を構成することもできます。Cloud Service Mesh では、成功したアクセスのログを期間内に 1 回だけ記録します。これにより、アクセスログのノイズが少なくなります（この期間はユーザーが構成できます）。セキュリティ ポリシーで拒否されたリクエストや、エラーになったリクエストは常にログに記録されます。これにより、重要なセキュリティ シグナルを失うことなく、ログの取り込み、保存、処理に関連する費用を著しく削減できます。
FIPS 遵守
x86 アーキテクチャのすべてのクラスタ内コントロール プレーン コンポーネントとプロキシで、FIPS 140-2 認証取得済みの暗号化モジュールが使用されます。
制限事項
現在、Cloud Service Mesh のセキュリティには、次の制限事項があります。
- IAP を使用するユーザー認証では、サービスがインターネットに公開されている必要があります。IAP と Cloud Service Mesh では、ポリシーを構成して、許可する IP 範囲内にある認可済みユーザーおよびクライアントへのアクセスを制限できます。同じネットワーク内のクライアントにのみサービスを公開する場合は、ユーザー認証とトークン発行用にカスタム ポリシー エンジンを構成する必要があります。