すべてのプロダクト
Search

このプロダクト

    Alibaba Cloud Service Mesh:ゼロトラストセキュリティの概要

    ドキュメントセンター

    Alibaba Cloud Service Mesh:ゼロトラストセキュリティの概要

    最終更新日:Jun 19, 2026

    ゼロトラストは、ネットワーク境界の内外における暗黙的な信頼を排除するセキュリティモデルです。Alibaba Cloud Service Mesh は、クラウドネイティブなゼロトラストアーキテクチャを実装するための重要なフレームワークです。認証と認可をサービスメッシュに統合し、アプリケーションコードから切り離します。これにより、セキュリティポリシーを容易に更新でき、即時に有効になる、すぐに使える動的に設定可能なソリューションを提供します。このトピックでは、ASM を使用してゼロトラストシステムを実装する理由と方法について説明します。

    背景情報

    マイクロサービスは、スケーラビリティ、アジリティ、独立したスケーリング、ビジネスロジックの分離、独立したライフサイクル管理、分散開発の簡素化など、多くのメリットをもたらします。しかし、この分散アーキテクチャは、各マイクロサービスが潜在的な攻撃対象となるため、セキュリティ上の課題も生じさせます。Kubernetes は、マイクロサービスをホストし、オーケストレーションするための優れたプラットフォームを提供します。しかし、デフォルトでは、マイクロサービス間のすべての通信は安全ではありません。これらは平文の HTTP を介して通信するため、現代のセキュリティ要件には不十分です。セキュリティをネットワーク境界のみに依存するだけでは十分ではありません。内部サービスが侵害された場合、攻撃者はネットワーク内で他のサービスを攻撃するために水平移動する可能性があります。したがって、内部トラフィックも保護する必要があります。これがゼロトラストセキュリティの価値です。ゼロトラストモデルでは、すべてのリクエストに対して明示的な検証が要求され、リソースへのアクセスを制限するために最小権限の原則が適用されます。

    Service Mesh技術の主な利点の 1 つは、開発者の生産性を低下させることなく、本番環境を保護できることです。Service Meshは、マイクロサービスに対してゼロトラストセキュリティアプローチを採用するための基盤を提供します。このアプローチは、強力な ID 認証、コンテキストアウェアな認可、およびすべてのアクセスに対する包括的なロギングとモニタリングといったセキュリティ目標の達成に役立ちます。これらのメッシュ機能を使用することで、メッシュ内のすべてのアプリケーションにセキュリティ制御を適用できます。たとえば、すべてのトラフィックが暗号化され、アプリケーションへのすべての着信トラフィックがポリシー適用ポイント (PEP) によって検証されるようにすることができます。

    ASM は、レイヤー 3 セキュリティ向けの Kubernetes ネットワークポリシーに加えて、ピア認証、リクエスト認証、Istio 認可ポリシー、およびきめ細かな OPA ポリシーを提供します。ASM のこれらのゼロトラストセキュリティ機能は、セキュリティ目標の達成に役立ちます。

    ASM の機能に関する理論的枠組みには、以下の側面が含まれます。

    • ワークロードアイデンティティ：ゼロトラストの基盤として、ASM は各クラウドネイティブなService Meshに統一された ID を提供します。サービスメッシュ内のすべてのワークロードに ID を定義する簡単な方法を提供し、特定のシナリオに合わせて ID システムを拡張するためのカスタマイズメカニズムも提供します。これらの ID は、コミュニティの SPIFFE 標準と互換性があります。

    • セキュリティ証明書：証明書はゼロトラストの中核となるコンポーネントです。ASM は、証明書の発行、ライフサイクル管理、およびローテーションを提供します。各プロキシは X.509 TLS 証明書を使用して自身の ID を確立します。ASM は証明書と秘密鍵のローテーションも管理します。

    • ポリシー適用：ポリシーベースの信頼エンジンは、ゼロトラストの中核です。ASM は、Istio のロールベースのアクセス制御 (RBAC) ポリシーをサポートするだけでなく、OPA に基づくよりきめ細かな認可ポリシーも提供します。

    • 可視化と分析：ゼロトラストシステムへのインサイトを提供するために、ASM はポリシー実行からのログとメトリクスを監視するオブザーバビリティメカニズムを提供しており、各ポリシーのパフォーマンスを評価できます。

    ASM を使用したゼロトラスト実装の理由

    ASM アーキテクチャは、アプリケーションコードに直接セキュリティメカニズムを組み込む従来のアプローチに比べて、いくつかのセキュリティ上の利点を提供します。

    • サイドカープロキシのライフサイクルはアプリケーションから独立しているため、プロキシの管理が容易になります。

    • ASM は動的な設定が可能です。ポリシーを簡単に更新でき、変更はアプリケーションを再デプロイすることなく即時に有効になります。

    • ASM の集中管理アーキテクチャにより、企業のセキュリティチームは組織全体でセキュリティポリシーを構築、管理、デプロイできます。これにより、ビジネスアプリケーションはデフォルトで安全になり、開発者は追加の作業なしでこれらのセキュリティポリシーの恩恵を受けることができます。

    • ASM は、JSON Web Token (JWT) など、リクエストに添付されたエンドユーザーの認証情報を認証できます。

    • ASM アーキテクチャでは、認証および認可システムをメッシュ内のサービスとしてデプロイできます。メッシュ内の他のサービスと同様に、これらのセキュリティシステムも、トランスポート暗号化、強力な ID、ポリシー適用ポイント、エンドユーザー認証情報の認証と認可など、メッシュが提供するセキュリティ保証の恩恵を受けます。

    ASM を使用すると、単一のコントロールプレーンで、強力な ID とアクセス管理、透過的な TLS 暗号化、認証、認可、および監査ロギングを実装できます。その簡単なインストールと管理により、開発者、システム管理者、およびセキュリティチームは、マイクロサービスアプリケーションを保護できます。

    ASM のゼロトラストシステムの使用

    ASM は、クラウドネイティブ環境における攻撃対象領域を削減し、ゼロトラストアプリケーションネットワークの基盤となるフレームワークを提供します。サービス間のセキュリティを管理することで、ASM はエンドツーエンドの暗号化、サービスレベルの認証、およびきめ細かな認可ポリシーを保証します。

    ASM フレームワークは、以下をサポートします。

    • サービス間の相互 TLS (mTLS) 認証またはサーバーサイド TLS 認証を強制するとともに、証明書のローテーションを含む自動的な証明書ライフサイクル管理をサポートします。メッシュ内のすべての通信は認証され、暗号化されます。

    • きめ細かな ID ベースの認可、および他のパラメーターに基づく認可を可能にします。ロールベースのアクセス制御 (RBAC) に基づいて、ASM は「最小権限」の姿勢をサポートし、ALLOW または DENY ルールに基づいて認可されたサービスのみが相互に通信できるようにします。

    1

    ASM は、ワークロードアイデンティティ、ピア認証、リクエスト認証、認可ポリシー、OPA ポリシーなど、基本的なゼロトラストセキュリティ機能を提供します。

    ワークロードアイデンティティ

    アプリケーションが ASM 環境で実行されると、ASM は各サービスに一意の ID を提供します。このサービス ID は、サービス間のアクセスを検証するための相互認証や認可ポリシーで使用できます。

    ASM を使用して Kubernetes 上で実行されているワークロードを管理する場合、ASM は各ワークロードにサービス ID を提供します。この ID は、ワークロードのサービスアカウントトークンに基づいています。

    ASM のサービス ID は SPIFFE 標準に準拠しており、次の形式を使用します： spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>。

    ASM コンソールにログインして、Kubernetes クラスターから接続されたサービスを表示できます。

    1. ASM コンソール にログインします。左側のナビゲーションウィンドウで、[サービスメッシュ] > [メッシュ管理] を選択します。

    2. [メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションウィンドウで、[メッシュセキュリティセンター] > [ワークロード ID] を選択します。

    3. Workload Identity ページで、Data Plane をクラスター ID に設定し、Namespaces を選択して、サービスメッシュに追加された Kubernetes クラスター内のサービスのワークロードアイデンティティを表示します。

    ピア認証

    ASM は、ピア認証とリクエスト認証の 2 種類の認証を提供します。ピア認証は、2 つのマイクロサービスが対話する際に、相互 TLS を使用してピアを認証します。

    • クライアントとサーバーの両方にサイドカープロキシが挿入されている場合、ASM では mTLS 通信がデフォルトで有効になります。

    • クライアントのみにサイドカープロキシが挿入されている場合、クライアントはサーバーの設定に基づいて mTLS 通信を使用するかどうかを決定します。

    • サーバーのみにサイドカープロキシが挿入されている場合、デフォルトの mTLS モードは PERMISSIVE であり、平文トラフィックと暗号化トラフィックの両方を受け入れます。サーバーに対して PeerAuthentication ポリシーを設定し、mTLS モードを STRICT に設定すると、リクエストは失敗します。

    リクエスト認証

    リクエスト認証により、エンドユーザーとシステムはマイクロサービスと対話できます。これは通常、JSON Web Token (JWT) を使用して行われます。

    マイクロサービスがリクエストされると、リクエスト認証ポリシーを作成して、着信リクエストに対して JWT 検証を実行できます。このポリシーは、JWT を含むリクエストを検証します。有効な JWT を持つリクエストのみがサービスに正常にアクセスできます。JWT を持たないリクエストは検証されず、制限なくサービスにアクセスできます。

    説明

    有効な JWT を持つリクエストのみがサービスにアクセスできるようにするには、リクエスト認証を認可ポリシーと組み合わせる必要があります。この設定では、無効な JWT または JWT のないリクエストを拒否します。

    1. リクエストを受信する bookinfo アプリケーションをデプロイします。詳細については、「ASM インスタンスに関連付けられたクラスターへのアプリケーションのデプロイ」をご参照ください。

    2. リクエストを送信する sleep アプリケーションをデプロイします。

      1. ACK クラスターの KubeConfig 環境で、sleep.yaml ファイルを作成します。

        Sleep.yaml ファイル

        apiVersion: v1
kind: ServiceAccount
metadata:
  name: sleep
---
apiVersion: v1
kind: Service
metadata:
  name: sleep
  labels:
    app: sleep
    service: sleep
spec:
  ports:
  - port: 80
    name: http
  selector:
    app: sleep
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      terminationGracePeriodSeconds: 0
      serviceAccountName: sleep
      containers:
      - name: sleep
        image: curlimages/curl
        command: ["/bin/sleep", "3650d"]
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /etc/sleep/tls
          name: secret-volume
      volumes:
      - name: secret-volume
        secret:
          secretName: sleep-secret
          optional: true
---

      2. 次のコマンドを実行して、sleep アプリケーションをデプロイします。

        kubectl apply -f sleep.yaml -n default

    3. リクエスト認証ポリシーを作成して、details サービスへのインバウンドリクエストに JWT 認証を適用します。

      1. ASM コンソール にログインします。左側のナビゲーションウィンドウで、[サービスメッシュ] > [メッシュ管理] を選択します。

      2. [メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションウィンドウで、[メッシュセキュリティセンター] > [requestauthentication] を選択します。表示されるページで、[作成] をクリックします。

      3. 作成ページで、次のパラメーターを設定し、Create をクリックして、details ワークロードの JWT ルールを定義します。

        default 名前空間を選択し、名前を test に設定し、名前が app で値が details のラベルセレクターを追加します。

        以下に一部のパラメーターの説明を示します。

        • issuer：JWT の発行者。この例では、testing@secure.istio.io に設定します。

        • audiences：JWT のオーディエンスのリスト。これは、どのサービスが JWT を使用してターゲットサービスにアクセスできるかを指定します。この例では、空のままにします。つまり、アクセスは特定のサービスに制限されません。

        • jwks：JWT の JSON Web Key Set (JWKS)。この例では、次の JWKS を使用します。詳細については、「jwks.json」をご参照ください。

          { "keys":[ {"e":"AQAB","kid":"DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ","kty":"RSA","n":"xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"}]}

    4. 次のステップで使用するトークンを生成するには、JWT ツールを使用できます。トークンは、JWKS の公開鍵に対応する秘密鍵を使用して作成し、発行者 testing@secure.istio.io を含める必要があります。

      { "keys":[ {"e":"AQAB","kid":"DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ","kty":"RSA","n":"xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"}]}

      期待されるトークンは次のとおりです。

      eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3UcMI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg

    5. リクエスト認証ポリシーが有効であることを確認します。

      1. 次のコマンドを実行して、エンコード済みの JWT を使用して details サービスにアクセスします。

        export TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3UcMI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg
kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null --header "Authorization: Bearer $TOKEN" -s -w '%{http_code}\n'

        200 ステータスコードが返され、アクセスが成功したことを示します。

      2. 次のコマンドを実行して、無効な JWT を使用して details サービスにアクセスします。

        kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null --header "Authorization: Bearer badtoken" -s -w '%{http_code}\n'

        401 ステータスコードが返され、アクセスが失敗したことを示します。

      3. 次のコマンドを実行して、JWT なしで details サービスにアクセスします。

        kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null  -s -w '%{http_code}\n'

        200 ステータスコードが返され、アクセスが成功したことを示します。

        これらの結果は、有効な JWT を持つリクエストは成功し、無効な JWT を持つリクエストは失敗し、JWT を持たないリクエストは成功することを示しています。これにより、リクエスト認証ポリシーが期待どおりに機能していることが確認されます。

    認可ポリシー

    マイクロサービスがリクエストされると、認可ポリシーを使用して、リクエストのポート、IP アドレス、ソースなどに基づいてアクセスを制限できます。要件を満たすリクエストのみがサービスにアクセスできます。次の認可ポリシーは、リクエストに特定の issuer からの JWT が含まれていることを要求することで、リクエストソースに基づいてアクセスを制限します。

    1. リクエストを受信する bookinfo アプリケーションをデプロイします。詳細については、「ASM インスタンスに関連付けられたクラスターへのアプリケーションのデプロイ」をご参照ください。

    2. リクエストを送信する sleep アプリケーションをデプロイします。

      1. 以下の内容で sleep.yaml ファイルを作成します。

        Sleep.yaml ファイル

        apiVersion: v1
kind: ServiceAccount
metadata:
  name: sleep
---
apiVersion: v1
kind: Service
metadata:
  name: sleep
  labels:
    app: sleep
    service: sleep
spec:
  ports:
  - port: 80
    name: http
  selector:
    app: sleep
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      terminationGracePeriodSeconds: 0
      serviceAccountName: sleep
      containers:
      - name: sleep
        image: curlimages/curl
        command: ["/bin/sleep", "3650d"]
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /etc/sleep/tls
          name: secret-volume
      volumes:
      - name: secret-volume
        secret:
          secretName: sleep-secret
          optional: true
---

      2. ACK クラスターの KubeConfig 環境で、次のコマンドを実行して sleep アプリケーションをデプロイします。

        kubectl apply -f sleep.yaml -n default

    3. 認可ポリシーを作成します。

      1. ASM コンソール にログインします。左側のナビゲーションウィンドウで、[サービスメッシュ] > [メッシュ管理] を選択します。

      2. [メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションウィンドウで、[メッシュセキュリティセンター] > [authorizationpolicy] を選択します。表示されるページで、[YAML から作成] をクリックします。

    4. Create ページで、default 名前空間を選択し、次の YAML を入力して、Create をクリックします。

      フィールドの詳細については、「承認ポリシー」をご参照ください。

      apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: default
spec:
  action: ALLOW
  rules:
    - from:
        - source:
            requestPrincipals:
              - testing@secure.istio.io/testing@secure.istio.io
  selector:
    matchLabels:
      app: details

    5. 次のコマンドを実行して、JWT なしでリクエストを送信し、サービスにアクセスします。

       kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null  -s -w '%{http_code}\n'

      期待される出力：

      403

      JWT なしの details サービスへのリクエストは失敗し、認可ポリシーが有効であることが確認されます。このポリシーでは、サービスに正常にアクセスするために、すべてのリクエストに testing@secure.istio.io によって発行された JWT が含まれている必要があります。

    OPA ポリシー

    OPA は、アプリケーションのきめ細かなアクセス制御を可能にするポリシーエンジンです。汎用ポリシーエンジンとして、OPA はマイクロサービスと並行してスタンドアロンサービスとしてデプロイできます。アプリケーションを保護するために、マイクロサービスへの各リクエストは処理される前に認可される必要があります。マイクロサービスは OPA API をクエリして、リクエストを許可すべきかどうかを判断します。詳細については、「OPA」をご参照ください。

    ASM は OPA プラグインを統合しており、OPA を使用してアクセス制御ポリシーを定義し、アプリケーションのきめ細かなアクセス制御を実現できます。これらの OPA ポリシーは動的に更新することもできます。詳細については、「ASM で OPA ポリシーを動的に更新する」をご参照ください。

    まとめとユースケース

    要約すると、ASM は以下のセキュリティ強化コンポーネントを提供します。

    • 証明書の発行と CA ローテーションを簡素化する、完全な証明書ライフサイクル管理を備えたマネージド証明書インフラストラクチャ。

    • 認証ポリシー、認可ポリシー、および安全なネーミング情報を Envoy プロキシに配布するためのマネージドコントロールプレーン API。

    • メッシュの保護に役立つポリシー適用ポイント (PEP) として機能するサイドカープロキシ。

    • テレメトリ収集と監査を可能にする Envoy プロキシ拡張。

    各ワークロードは、X.509 TLS 証明書を使用して自身の ID を確立します。この証明書は、ワークロードのサイドカープロキシによって使用されます。ASM は、これらの証明書と秘密鍵を提供し、定期的にローテーションします。秘密鍵が侵害された場合、ASM はそれを迅速に新しいものに置き換えることができ、攻撃対象領域を大幅に削減します。

    ユースケース

    • Ingress Gateway で認可ポリシーを使用して、IP ベースのアクセス制御またはカスタムの外部オーソライザーに基づくアクセス制御を実装します。

    • あるインターネット金融の顧客は、クラスターをまたがる多言語アプリケーションのアクセス権限を管理する必要がありました。ASM の認可ポリシーを使用して、外部向けゾーンを内部アプリケーションゾーンから分離しました。メッシュトラフィックを監査するためのEgress Gatewayと組み合わせて、認可ポリシーを使用してサードパーティ サービスへのアプリケーションアクセスも制御しました。