ASM helps realize zero trust

マイクロサービスは、スケーラビリティ、アジリティ、独立したスケーリング、ビジネスロジックの分離、独立したライフサイクル管理、分散開発の容易化など、多くの価値を提供します。しかし、これらの分散型マイクロサービスはセキュリティ上の課題も増大させており、各マイクロサービスが攻撃の対象となり得ます。Kubernetes はマイクロサービスのホスティングとオーケストレーションに優れたプラットフォームを提供します。しかし、マイクロサービス間のすべての対話はデフォルトでは安全ではありません。マイクロサービス間はプレーンテキストの HTTP で通信しますが、これはセキュリティ要件を満たすには不十分です。ネットワーク境界のみに依存してセキュリティを確保することも不十分です。なぜなら、内部サービスが 1 つでも侵害されれば、境界セキュリティの手段はマジノ線のようなものであり、攻撃者はそのマシンを踏み台にしてイントラネットに侵入できるからです。したがって、内部呼び出しも安全である必要があり、ここでゼロトラストが登場します。

ゼロトラストは Forrester のアナリスト John Kindervag によって提唱された概念で、ネットワーク境界の内側か外側かに関わらず、暗黙の信頼は一切存在しないことを意味します。つまり、あらゆる場所で明示的な認証を要求し、最小権限の原則に基づいてリソースへのアクセスを制限します。

サービスメッシュ技術の重要な価値提案は、開発者の生産性を損なうことなく、アプリケーションの本番環境をいかに効果的に保護できるかという点にあります。サービスメッシュ技術を通じて、マイクロサービスアーキテクチャはゼロトラストのネットワークセキュリティ方式を採用し、すべてのアクセスの強力な認証、コンテキストベースの認可、記録とモニタリングなどのセキュリティ目標を達成するために必要な基盤を提供します。これらのメッシュ機能を使用することで、メッシュに属するすべてのアプリケーションにセキュリティ制御を提供できます。たとえば、すべてのトラフィックの暗号化、ポリシー適用ポイント (PEP) によるすべてのトラフィックの認証などです。

2021 年 8 月に米国国家安全保障局 (NSA) が発行した「Kubernetes Hardening Guidance」でも、管理者は Kubernetes クラスターのセキュリティを強化するためにサービスメッシュの使用を検討すべきであることが言及されています。

Alibaba Cloud Service Mesh ASM (https://www.aliyun.com/product/servicemesh) は、クラウドネイティブなゼロトラストシステムを実装するための重要な基盤の 1 つとなっています。ASM はアプリケーションコードから認証と認可をサービスメッシュにオフロードし、すぐに使える、動的に設定可能な、そして即時に反映されるポリシー更新を実現します。Kubernetes Network Policy を使用した 3 層のネットワークセキュリティ制御に加え、サービスグリッド ASM は OPA (Open Policy Agent) ベースのポリシー制御を提供します。これにはピア ID とリクエスト ID の認証機能、Istio 認可ポリシー、さらにきめ細かな管理機能が含まれます。Alibaba Cloud Service Mesh ASM が提供するこれらのゼロトラストセキュリティ機能は、ユーザーが上記のセキュリティ目標を達成するのに役立ちます。

サービスグリッド ASM のプロダクト機能を構築するための理論体系には、以下の側面が含まれます：

⢠1) ゼロトラストの基盤 - ワークロード ID：クラウドネイティブワークロードに統一された ID を提供する方法。ASM プロダクトはサービスグリッド配下の各ワークロードに使いやすい ID 定義を提供し、特定のシナリオに応じたカスタマイズメカニズムを提供して ID 構築システムを拡張し、コミュニティの SPIFFE 標準と互換です。
⢠2) ゼロトラストのキャリア - セキュリティ証明書：ASM プロダクトは証明書の発行、証明書のライフサイクルとローテーションの管理方法を提供し、X509 TLS 証明書を通じて ID を確立します。これらの証明書は各エージェントによって使用されます。また、証明書と秘密鍵のローテーションも提供します。
⢠3) ゼロトラストエンジン - ポリシー実行：ポリシーベースの信頼エンジンはゼロトラスト構築の重要な核心です。ASM プロダクトは Istio RBAC 認可ポリシーをサポートするだけでなく、OPA ベースのよりきめ細かな認可ポリシーも提供します。
⢠4) ゼロトラストの可視化 - 可視化と分析：ASM プロダクトはポリシー実行のログと指標をモニタリングする可観測メカニズムを提供し、各ポリシーの実行状況を判断できます。

なぜゼロトラストにサービスメッシュを使用するのか

これらのセキュリティメカニズムをアプリケーションコードに直接構築する従来のアプローチと比較して、サービスメッシュアーキテクチャはいくつかのセキュリティ上の利点を提供します。
⢠サイドカープロキシのライフサイクルはアプリケーションから独立して維持されるため、これらのサイドカープロキシをより簡単に管理できます。
⢠動的設定をサポートするため、ポリシーの更新が容易になり、アプリケーションを再デプロイすることなく、更新が即座に反映されます。
⢠サービスメッシュの集中制御アーキテクチャにより、企業のセキュリティチームは企業全体に適用されるセキュリティポリシーを構築、管理、デプロイでき、アプリケーション開発者が構築するビジネスアプリケーションをデフォルトで安全にします。開発者は追加の作業なしに、これらのセキュリティポリシーをすぐに使用できます。
⢠サービスメッシュは、JWT としてリクエストに付与されたエンドユーザーの認証情報を検証する機能を提供します。
⢠さらに、サービスメッシュアーキテクチャを使用すると、認証・認可システムをメッシュ内のサービスとしてデプロイできます。これにより、グリッド内の他のサービスと同様に、これらのセキュリティシステムはグリッド自体からセキュリティ保護を受けます。これには、転送中の暗号化、ID 特定、ポリシー適用ポイント、エンドユーザー認証情報の認証と認可などが含まれます。

Alibaba Cloud Service Mesh ASM を使用すると、単一のコントロールプレーンで強力な ID とアクセス管理、透過的な TLS と暗号化、認証と認可、監査ログを実装できます。Alibaba Cloud Service Mesh ASM はこれらの機能をすぐに使える形で提供し、インストールと管理の簡便さにより、開発者、システム管理者、セキュリティチームはマイクロサービスアプリケーションを適切に保護できます。

ASM におけるゼロトラストシステム

サービスメッシュはクラウドネイティブ環境の攻撃対象領域を縮小し、ゼロトラストアプリケーションネットワークに必要な基本フレームワークを提供できます。ASM を通じてサービス間のセキュリティを管理し、サービスグリッドのエンドツーエンド暗号化、サービスレベルの認証、きめ細かな認可ポリシーを確保します。

サービスグリッドの仕組みでは、以下をサポートできます：

⢠サービス間の双方向 TLS 認証、またはサーバー側の TLS 認証を実装し、証明書の自動ローテーションなどのライフサイクル管理をサポートします。メッシュ内の通信は認証され、暗号化されます。
⢠ID ベースのきめ細かな認可、およびその他のディメンションパラメータに基づく認可を実現します。「最小権限」の姿勢をサポートするロールベースアクセス制御 (RBAC) の基盤により、認可されたサービスのみが ALLOW/DENY ルールに従って相互に通信できます。

現在、Alibaba Cloud Service Mesh ASM は以下の基本的なゼロトラストセキュリティ機能を提供しています：

1. ワークロード ID

アプリケーションがサービスメッシュ環境で実行されると、サービスメッシュは各サービスに一意の ID を提供します。この ID は、サービスメッシュ内で実行されている他のマイクロサービスへの接続時に使用されます。サービス ID はサービス間の双方向認証に使用され、サービス間のアクセスが許可されているかどうかを検証でき、認可ポリシーでも使用できます。

サービスメッシュ ASM を使用して Kubernetes 上で実行されるワークロードを管理する場合、または WorkloadEntry に基づいて仮想マシンのワークロードを定義する場合、ASM は各ワークロードにサービス ID を提供します。この ID はワークロードのサービスアカウントトークンに基づいて実装されます。

ASM のサービス ID は SPIFFE に準拠しており、以下の形式を持ちます：
spiffe:///ns//sa/

サービスグリッド ASM コンソールで対応する ASM インスタンスを開くと、左側のナビゲーションバーのゼロトラストセキュリティセクションに以下のワークロード ID が表示されます。

データプレーンの Kubernetes クラスター配下のワークロードとその ID 定義：

WorkloadEntry に基づいて仮想マシンワークロードとその ID を定義：

2. ピア認証

認証とは ID を指します。このサービスは誰か。このエンドユーザーは誰か。彼らが主張通りの存在であると信じられるか。
ASM プロダクトは 2 種類の認証を提供します。
- ピア認証：2 つのマイクロサービスが相互に対話する際に、ピア認証の相互 TLS を有効にするか無効にするか。
- リクエスト認証：エンドユーザーやシステムがリクエスト認証を使用してマイクロサービスと対話できるようにします。通常、JSON Web Token (JWT) を使用します。

スターティングガイド (https://help.aliyun.com/document_detail/149552.html) に従って、bookinfo サンプルアプリケーションをインストールしてデプロイします。

まず、同じ名前空間 (この例では default) の productpage Pod からプレーン HTTP で details サービスにアクセスしてみると、デフォルトではステータス 200 で正常にレスポンスが返されるはずです。

次に、ピア認証を default 名前空間配下に定義します。
サービスグリッド ASM コンソールで対応する ASM インスタンスを開くと、左側のナビゲーションバーのゼロトラストセキュリティセクションに以下のピア間 ID 認証が表示されます。右側のページで「新規双方向 mTLS モード」ボタンをクリックし、ワークロード details の mTLS モードを STRICT に定義します。

終了コード 56 はネットワークデータの受信失敗を示します。これは期待通りの動作です。ワークロード details は mTLS モードを STRICT に定義しており、各リクエストで TLS 証明書認証が必要です。

通常のアクセスを許可するには、上記で定義したピア認証を STRICT から PERMISSIVE に変更します。

3. リクエスト認証

まず、details サービスへの受信リクエストに JWT 認証を強制するリクエスト認証ポリシーを作成します。サービスグリッド ASM コンソールで対応する ASM インスタンスを開くと、左側のナビゲーションバーにゼロトラストセキュリティセクションのリクエスト ID 認証が以下のように表示されます。右側のページで「新規作成」ボタンをクリックし、ワークロード details 用の JWT ルールを定義します。

次に、productpage Pod を使用してプレーン HTTP で details サービスにアクセスしてみると、レスポンスは 200 であることが確認できます。

無効なトークンを渡すと、「401: Unauthorized」レスポンスが表示されるはずです。

ただし、トークンを全く渡さない場合、RequestAuthentication はポリシーを適用しません。JWT Token を使用しないリクエストも 200 を返します。

したがって、この認証ポリシーに加えて、すべてのリクエストに JWT を要求する認可ポリシーが必要です。次のセクションでは、ASM プロダクトでの認可ポリシーの定義方法を説明します。

4. 認可ポリシー

ASM プロダクトは認可ポリシーを提供し、AuthorizationPolicy リソースを使用してマイクロサービス間の認可メカニズムを有効化し、以下の内容を使用して適切なトラフィック認可ポリシーメカニズムを確立します。
⢠ワークロードラベルのセレクターフィールドでポリシーのターゲットを指定します。
⢠アクションフィールドで ALLOW または DENY を指定します。アクションを指定しない場合、デフォルトは ALLOW です。明確にするため、常にアクションを指定することを推奨します (認可ポリシーは AUDIT および CUSTOM 操作もサポートします)。
⢠ルールはアクションがトリガーされるタイミングを指定します。
⢠ルール内の from フィールドはリクエストの送信元を指定します。
⢠ルール内の to フィールドはリクエストされたアクションを指定します。
⢠when フィールドはルールの適用に必要なその他の条件を指定します。

JWT Token を使用せずにリクエストを再送信すると、403 - Forbidden が表示されるはずです。これは AuthorizationPolicy が有効になり、すべてのフロントエンドリクエストに JWT Token が必要になったためです。

5. OPA ポリシー

CNCF がホストするインキュベートプロジェクトである Open Policy Agent (OPA) は、アプリケーションにきめ細かなアクセス制御を実装するために使用できるポリシーエンジンです。OPA は汎用ポリシーエンジンとして、マイクロサービスと共に独立したサービスとしてデプロイできます。アプリケーションを保護するには、マイクロサービスへのすべてのリクエストが処理前に認可される必要があります。認可のチェックを行うため、マイクロサービスは OPA に API 呼び出しを行い、リクエストが認可されているかどうかを判断します。

サービスグリッド ASM は OPA プラグインを統合し、OPA を通じてアクセス制御ポリシーを定義することで、アプリケーションのきめ細かなアクセス制御を実現し、OPA ポリシーの動的更新をサポートします。
詳細については、https://help.aliyun.com/document_detail/277428.html を参照してください。

まとめと参考事例
まとめると、サービスメッシュ ASM はセキュリティ強化のために以下のコンポーネントを提供します。

⢠完全な証明書ライフサイクル管理を備えたマネージド証明書基盤を提供し、証明書の発行と CA ローテーションの複雑さに対処します。
⢠認証ポリシー、認可ポリシー、安全な命名情報を Envoy プロキシに配信するマネージドコントロールプレーン API。
⢠サイドカープロキシはポリシー適用ポイント (PEP) を提供することでメッシュのセキュリティを支援します。
⢠Envoy プロキシの拡張機能により、テレメトリデータの収集と監査が可能になります。

各ワークロードは X509 TLS 証明書を通じて ID を確立し、この証明書は各サイドカープロキシによって使用されます。サービスメッシュ ASM は証明書と秘密鍵を提供し、定期的にローテーションします。特定の秘密鍵が漏洩した場合、サービスメッシュは迅速に新しいものに置き換え、攻撃対象領域を大幅に縮小します。