Cloud Service Mesh のセキュリティのベスト プラクティス
このドキュメントでは、Google Kubernetes Engine（GKE）で実行される安全な Cloud Service Mesh の構成を確立して管理するためのベスト プラクティスについて説明します。このドキュメントでは、セキュリティ脅威からアプリケーションを保護するために、Cloud Service Mesh の構成とインストールで使用する設定と、Anthos Service Mesh と他の Google Cloud プロダクトおよび機能を使用する方法について説明します。
このドキュメントは、Cloud Service Mesh でポリシーを管理する管理者と、Cloud Service Mesh でサービスを実行するユーザーを対象にしています。ここで説明するセキュリティ対策は、コンプライアンス要件を満たすためにサービス メッシュのセキュリティを強化する必要がある組織にも有効な対策です。
ドキュメントの構成は次のとおりです。
- はじめに
- 攻撃ベクトルとセキュリティ リスク
- サービス メッシュを保護する対策
はじめに
Cloud Service Mesh は、サービスを一元的にモニタリング、管理、保護するための機能とツールを提供します。これは、ネットワーク IP を中心としたアプローチではなく、アプリケーション中心のアプローチを採用し、信頼できるアプリケーション ID を使用します。既存のアプリケーション コードを変更することなく、サービス メッシュを透過的にデプロイできます。Cloud Service Mesh では、ネットワークの動作を宣言的に制御できます。これにより、アプリケーションの機能の提供とリリースを担当するチームの作業を、セキュリティとネットワーキングを担当する管理者から分離できます。
Cloud Service Mesh はオープンソースの Istio サービス メッシュをベースとし、高度な構成とトポロジを実現します。組織の体制によっては、1 つ以上のチームまたはロールがメッシュのインストールと構成を担当する場合があります。Cloud Service Mesh のデフォルトの設定は、アプリケーションを保護するように設定されていますが、カスタム構成が必要になることもあります。また、例外を作成し、特定のアプリ、ポート、IP アドレスのメッシュへの参加を防ぐこともできます。メッシュの構成とセキュリティの例外を管理する体制を整えておくことが重要です。
攻撃ベクトルとセキュリティ リスク
攻撃ベクトル
Cloud Service Mesh セキュリティはゼロトラスト セキュリティ モデルを採用しています。このモデルは、セキュリティ脅威が組織のセキュリティ境界の内側と外側の両方で発生することを前提としています。サービス メッシュ内のアプリケーションを脅かすセキュリティ攻撃の種類としては、次のようなものがあります。
- データの引き出し攻撃。サービス間のトラフィックから機密データや認証情報などを盗み出します。
- 中間者攻撃。たとえば、サービス間の通信や変更を行うために正当なサービスを偽装する悪意のあるサービス。
- 権限昇格攻撃。昇格された権限に不正にアクセスして、ネットワーク内で操作を行います。
- サービス拒否（DoS）攻撃。
- サービスに侵入し、ボットネットを利用して他のサービスへの攻撃を仕掛けます。
攻撃は、攻撃対象に基づいて分類することもできます。
- メッシュ内部ネットワーク攻撃。メッシュ内部サービス間またはサービスとコントロール プレーン間の通信の改ざん、盗聴、なりすましを目的とした攻撃。
- コントロール プレーンに対する攻撃。コントロール プレーンを誤動作させたり（DoS 攻撃など）、コントロール プレーンから機密データを盗み出そうとします。
- メッシュエッジに対する攻撃。メッシュの上り（内向き）または下り（外向き）で通信の改ざん、傍受、なりすましを試みます。
- メッシュ オペレーションに対する攻撃。メッシュ オペレーションを狙った攻撃。攻撃者は、メッシュ内で悪意のある操作（セキュリティ ポリシーとワークロード イメージの変更など）を実行するために、上位の権限を取得しようとします。
セキュリティ リスク
メッシュには、セキュリティ攻撃以外にもセキュリティ リスクがあります。セキュリティ リスクとしては、次のようなものがあります。
- 不完全なセキュリティ。サービス メッシュを保護するために、サービス メッシュに認証ポリシーと認可ポリシーが構成されていません。たとえば、メッシュ内のサービスに認証ポリシーや認可ポリシーが定義されていません。
- セキュリティ ポリシーの例外。特定のユースケースに対応するため、特定のトラフィック（内部または外部）に対するセキュリティ ポリシーの例外を作成して、Cloud Service Mesh のセキュリティ ポリシーから除外できます。このようなケースを安全に処理するには、ポリシーの例外を安全に処理するのセクションをご覧ください。
- イメージのアップグレードを実施しない。メッシュで使用されているイメージの脆弱性が発見される可能性があります。脆弱性に対する最新の修正を適用し、メッシュ コンポーネントとワークロード イメージを最新の状態に保つ必要があります。
- メンテナンスの欠如（専門知識やリソースがない）。最新のセキュリティ保護メカニズムを利用するには、メッシュ ソフトウェアとポリシー構成を定期的にメンテナンスする必要があります。
- 可視性の欠如。メッシュ ポリシーや異常なメッシュ トラフィック / オペレーションの構成ミスまたは安全でない構成がメッシュ管理者に感知されない。
- 構成のずれ。メッシュ内のポリシーの構成が、信頼できる情報源から逸脱しています、
サービス メッシュを保護する対策
このセクションでは、サービス メッシュを保護するための運用マニュアルについて説明します。
セキュリティ アーキテクチャの
サービス メッシュのセキュリティは、メッシュ システムとそのアプリケーションのさまざまなレイヤに存在するコンポーネントのセキュリティに依存します。Cloud Service Mesh のセキュリティ対策では、異なるレイヤにある複数のセキュリティ メカニズムを統合してサービス メッシュを保護することを推奨しています。これにより、ゼロトラスト セキュリティ モデルでシステム全体のセキュリティを実現できます。次の図は、Cloud Service Mesh のセキュリティ ポスチャーの案を示しています。
Cloud Service Mesh は、次のような複数のレイヤでセキュリティを提供します。
- メッシュエッジのセキュリティ
- Cloud Service Mesh の上り（内向き）セキュリティは、外部トラフィックのアクセス制御を行い、メッシュ内のサービスで公開される API への外部アクセスを保護します。
- Cloud Service Mesh の下り（外向き）セキュリティは、内部ワークロードからの送信トラフィックを規制します。
- Cloud Service Mesh User Auth は Google インフラストラクチャと統合されており、ウェブブラウザからウェブ アプリケーションを実行するサービスへの外部呼び出しを認証します。
- Cloud Service Mesh のゲートウェイ証明書管理は、Certificate Authority Service を使用して、Anthos Service Mesh の上り（内向き）ゲートウェイと下り（外向き）ゲートウェイで使用される秘密鍵と X.509 証明書を保護し、ローテーションします。
- Cloud Armor は、外部の分散型サービス拒否攻撃（DDoS）やレイヤ 7 の攻撃から保護できます。これは、ウェブ アプリケーション ファイアウォール（WAF）として機能し、ネットワーク攻撃からメッシュを保護します。たとえば、インジェクションやリモートコード実行などの攻撃を阻止します。
- VPC と VPC Service Controls は、プライベート ネットワーク アクセス制御によってメッシュエッジを保護します。
- クラスタ セキュリティ
- Cloud Service Mesh 相互 TLS（mTLS）は、ワークロード間のトラフィックに暗号化と認証を適用します。
- Cloud Service Mesh 認証局や Certificate Authority Service などのマネージド CA は、ワークロードで使用される証明書を安全にプロビジョニングして管理します。
- Cloud Service Mesh の認証機能では、ID とその他の属性に基づいてメッシュ サービスのアクセスを制御します。
- GKE Enterprise セキュリティ ダッシュボードでは、ワークロードのセキュリティ ポリシーと Kubernetes ネットワーク ポリシーの構成をモニタリングできます。
- Kubernetes ネットワーク ポリシーでは、IP アドレス、Pod のラベル、名前空間などに基づいて Pod のアクセス制御が適用されます。
- コントロール プレーンのセキュリティにより、コントロール プレーンへの攻撃を阻止します。これにより、サービスとメッシュ構成データの不正な変更、悪用、流出を防ぐことができます。
- ワークロード セキュリティ
- Cloud Service Mesh のセキュリティ リリースを最新の状態にして、メッシュで実行されている Cloud Service Mesh バイナリに既知の脆弱性がないようにします。
- GKE 用 Workload Identity 連携を使用すると、ワークロードは Google サービスを安全に呼び出すための認証情報を取得できます。
- Kubernetes CNI（Container Network Interface）は、特権付きの Cloud Service Mesh init コンテナの必要性を排除することにより、権限昇格攻撃を防ぎます。
- オペレーターのセキュリティ
- Kubernetes ロールベースのアクセス制御（RBAC）は、Kubernetes リソースへのアクセスを制限し、オペレーターの権限を制限して、悪意のあるオペレーターやなりすましによる攻撃を回避します。
- GKE Enterprise Policy Controller は、メッシュ内のポリシー構成を検証して監査し、構成ミスを防ぎます。
- Google Cloud Binary Authorization は、メッシュ内のワークロード イメージが管理者によって承認されたイメージであることを確認します。
- Google Cloud Audit Logging はメッシュ オペレーションを監査します。
下の図は、Cloud Service Mesh に統合されたセキュリティ ソリューションとの通信と構成のフローを示しています。
クラスタ セキュリティ
厳格な相互 TLS を有効にする
中間者攻撃（MitM）は、通信を盗聴または操作するために、互いに通信している 2 者間に悪意のあるエンティティを挿入します。Cloud Service Mesh では、すべての通信者に mTLS 認証と暗号化を適用することで、MitM とデータ引き出し攻撃を防ぎます。両側が mTLS をサポートしている場合、Permissive モードで mTLS が使用されますが、mTLS を使用しない接続も許可されます。一方、厳密な mTLS の場合、トラフィックは mTLS で暗号化および認証される必要があり、暗号化されていないテキストのトラフィックは許可されません。
Cloud Service Mesh では、セキュリティとコンプライアンスの要件を満たすために、ワークロード間の TLS 接続に最小 TLS バージョンを構成できます。
詳細については、Cloud Service Mesh の例: mTLS | メッシュ全体の mTLS を適用するをご覧ください。
アクセス制御を有効にする
Cloud Service Mesh セキュリティ ポリシー（認証ポリシーや認可ポリシーなど）は、Anthos Service Mesh セキュリティ ポリシーからサービスまたは Pod を除外する正当な理由がない限り、メッシュを出入りするすべてのトラフィックに適用する必要があります。一部のポートと IP 範囲で Cloud Service Mesh セキュリティ ポリシーをバイパスする正当な理由がある場合があります。たとえば、Cloud Service Mesh で管理されていないサービスとネイティブ接続を確立する場合などです。このようなユースケースで Cloud Service Mesh を保護するには、Cloud Service Mesh ポリシーの例外を安全に処理するをご覧ください。
サービスへのアクセス制御は、サービスへの不正アクセスを防ぐために不可欠です。mTLS の適用でリクエストは暗号化されて認証されますが、サービスのアクセス制御を適用するために、メッシュでは引き続き Cloud Service Mesh 認可ポリシーが必要になります。たとえば、認証済みのクライアントからの未承認リクエストを拒否する場合などです。
Cloud Service Mesh 認可ポリシーでは、アクセス制御を柔軟に構成し、サービスを不正アクセスから保護します。Cloud Service Mesh 認可ポリシーは、認証結果から得られた認証済み ID に基づいて適用する必要があります。mTLS または JSON Web Token（JWT）ベースの認証は、Cloud Service Mesh 認可ポリシーの一部として一緒に使用する必要があります。
Cloud Service Mesh の認証ポリシーを適用する
JSON Web Token（JWT）
mTLS 認証に加えて、メッシュ管理者は、JWT に基づいてリクエストを認証し、認可するようサービスに要求できます。Cloud Service Mesh は JWT プロバイダとして機能しませんが、構成済みの JSON ウェブキーセット（JWKS）エンドポイントに基づいて JWT を認証します。JWT 認証は、Ingress ゲートウェイ（外部トラフィック）や内部サービス（メッシュ内トラフィック）に適用できます。呼び出し側を表す認証情報として JWT を使用し、リクエストされたサービスが呼び出し側に代わって呼び出されていることを証明する必要がある場合は、JWT 認証と mTLS 認証を組み合わせることができます。JWT 認証を適用すると、有効な認証情報なしで、実際のエンドユーザーに代わりサービスへのアクセスを試みる攻撃を阻止します。
Cloud Service Mesh のユーザー認証
Cloud Service Mesh のユーザー認証は、ワークロードに対するブラウザベースのエンドユーザー認証とアクセス制御を統合したソリューションです。サービス メッシュを既存の ID プロバイダ（IdP）と統合し、標準のウェブベースの OpenID Connect（OIDC）ログインと同意フローを実装して、アクセス制御に Cloud Service Mesh 認可ポリシーを使用します。
Cloud Service Mesh 認可ポリシーは、以下のものを制御します。
- サービスへのアクセスを許可するユーザーまたは対象。
- アクセスできるリソース。
- 許可されたリソースに対して実行できるオペレーション。
認可ポリシーは、サービスが実行する実際の ID、トラフィックのアプリケーション レイヤ（レイヤ 7）プロパティ（リクエスト ヘッダーなど）、ネットワーク レイヤ（レイヤ 3 およびレイヤ 4）プロパティ（IP 範囲やポートなど）に基づいてアクセス制御を構成する汎用的な方法です。
Cloud Service Mesh 認可ポリシーは、サービスまたはデータへの不正アクセスを防ぐために、認証結果から得られた認証済み ID に基づいて適用する必要があります。
デフォルトでは、認可ポリシーが明示的に定義されていない限り、サービスへのアクセスは拒否されます。アクセス リクエストを拒否する認可ポリシーの例については、認可ポリシーのベスト プラクティスをご覧ください。
認可ポリシーでは、信頼を可能な限り制限する必要があります。たとえば、サービスへのアクセスは、サービスによって公開された個々の URL パスに基づいて定義し、サービス A のみがサービス B のパス /admin にアクセスできるようにします。
認可ポリシーは Kubernetes ネットワーク ポリシーと組み合わせて使用できます。これは、ネットワーク レイヤ（レイヤ 3 とレイヤ 4）でのみ動作し、Kubernetes Pod と Kubernetes Namespace の IP アドレスとポートへのネットワーク アクセスを制御します。
メッシュ サービスにアクセスするためのトークン交換を適用する
トークンを盗み、盗まれたトークンを再利用してメッシュ サービスにアクセスするトークンリプレイ攻撃から保護するには、メッシュ外からのリクエストのトークンを、メッシュ エッジで有効期間が短いメッシュ内部のトークンと交換する必要があります。
メッシュ サービスによって認証と認可を行うため、メッシュ外部からメッシュ サービスにアクセスするために送信されたリクエストには JWT や Cookie などのトークンを含める必要があります。メッシュ外からのトークンは長期間存続する可能性があります。トークン リプレイ攻撃から防御するには、メッシュの上り（内向き）で、スコープが限定され、有効期間の短いメッシュ内部のトークンとメッシュ外からのトークンを交換する必要があります。メッシュ サービスはメッシュ内部トークンを認証し、メッシュ内部トークンに基づいてアクセス リクエストを認可します。