Anthos Service Mesh セキュリティは、ワークロード間のすべての通信が確実に暗号化、相互認証、承認されるようにすることで、インサイダー脅威の緩和とデータ侵害のリスク軽減に役立ちます。
従来より、IP ベースのルールを使用するマイクロ セグメンテーションは、インサイダー リスクを緩和するために使用されています。ただし、コンテナ、共有サービス、複数のクラウドに分散した本番環境を採用すると、このアプローチは構成が難しくなり、維持がさらに難しくなります。
Anthos Service Mesh では、サービス コンテキスト アウェアとリクエスト コンテキスト アウェアのネットワーク セキュリティ レイヤを構成できます。これは、基盤となるネットワークのセキュリティとは独立しています。このため、Anthos Service Mesh では、ゼロトラストのセキュリティ原則と整合した多重防護体制を採用できます。宣言型ポリシーにより、アプリケーション コードを一切変更せずにこの体制を実現できます。
セキュリティ上のメリット
Anthos Service Mesh には次のようなセキュリティ上のメリットがあります。
盗まれた認証情報によるリプレイまたはなりすまし攻撃のリスクを軽減する。Anthos Service Mesh では、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 鍵と証明書のローテーションを管理します。これにより、無効期間を短くし、リスクを軽減できます。
マネージド プライベート認証局（Mesh CA）Anthos Service Mesh では、Google 管理のマルチリージョン認証局（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 サービス アカウント名
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 ゲートウェイまたはダウンストリーム サービス（サイドカーを使用）にアクセス権を付与できます。
ロギングとモニタリングへのアクセス。Anthos Service Mesh では、Google Cloud Observability でアクセスログと指標を使用できます。また、統合ダッシュボードで、このデータに基づくサービスまたはワークロードのアクセス パターンを把握できます。限定公開の宛先を構成することもできます。Anthos Service Mesh では、成功したアクセスのログを期間内に 1 回だけ記録します。これにより、アクセスログのノイズが少なくなります（この期間はユーザーが構成できます）。セキュリティ ポリシーで拒否されたリクエストや、エラーになったリクエストは常にログに記録されます。これにより、重要なセキュリティ シグナルを失うことなく、ログの取り込み、保存、処理に関連する費用を著しく削減できます。
制限事項
現在、Anthos Service Mesh のセキュリティには、次の制限事項があります。
mTLS 認証では 1 つのクラスタのみがサポートされています。クラスタ間での mTLS 認証はサポートされていません。クラスタ間および VPC 間の通信には、Ingress ゲートウェイと標準 TLS を使用することをおすすめします。
Mesh CA は、Google Cloud 上の GKE Enterprise デプロイでのみサポートされます。
IAP を使用するユーザー認証では、サービスがインターネットに公開されている必要があります。IAP と Anthos Service Mesh では、ポリシーを構成して、ホワイトリストに登録された IP 範囲内にある承認済みユーザーまたはクライアントへのアクセスを制限できます。同じネットワーク内のクライアントにのみサービスを公開する場合は、ユーザー認証とトークン発行用にカスタム ポリシー エンジンを構成する必要があります。