すべてのプロダクト
Search

このプロダクト

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

    ドキュメントセンター

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

    最終更新日:Jan 13, 2025

    ゼロトラストとは、ネットワーク境界の内外で暗黙の信頼を排除するセキュリティアプローチです。Service Mesh (ASM) は、クラウドネイティブアプリケーションのゼロトラストセキュリティを実装します。以前はアプリケーションコードに記述されていた ID 認証と承認の機能を統合します。これらの機能はすぐに使用できます。ビジネスニーズに基づいて ID 認証と承認ポリシーを簡単に構成および更新でき、新しいポリシーはすぐに有効になります。このトピックでは、ASM を使用してゼロトラストセキュリティを実装する必要がある理由と、ASM でゼロトラストシステムを使用する方法について説明します。

    背景情報

    マイクロサービスアーキテクチャは、スケーラビリティ、アジリティ、独立したスケーリング、ビジネスロジックの分離、独立したライフサイクル管理、分散開発の容易さなど、さまざまなメリットをもたらします。ただし、マイクロサービスの分散アーキテクチャは、より大きなセキュリティリスクをもたらします。これは、各マイクロサービスが攻撃される可能性のあるオブジェクトであるためです。Kubernetes は、マイクロサービスをホストおよびオーケストレーションするための優れたプラットフォームです。デフォルトでは、Kubernetes クラスタ内のマイクロサービスは、プレーンテキストの HTTP リクエストを使用して相互に通信します。ただし、通信は安全ではありません。ネットワーク境界ベースのセキュリティでは不十分です。内部マイクロサービスが侵入された場合、攻撃者はこの単一の侵害を利用して、ネットワーク全体の任意の数のサービスにアクセスできます。したがって、内部ネットワークを介した通信も安全でなければなりません。これがゼロトラストが重要な理由です。ゼロトラストセキュリティでは、すべてのリクエストに対して明示的な認証が必要であり、最小限の権限の原則を適用してリソースへのアクセスを制限します。

    サービスメッシュテクノロジーの主な利点は、開発者の生産性を低下させることなく、アプリケーションのデプロイ環境を保護することです。サービスメッシュテクノロジーを使用して、マイクロサービスのゼロトラストセキュリティを有効にすることができます。これにより、すべてのアクセスリクエストに対して厳格な ID 認証、コンテキストベースの承認、監視、記録などのセキュリティ操作を実行できます。また、サービスメッシュに追加されるすべてのアプリケーションにセキュリティ制御を適用することもできます。たとえば、すべてのトラフィックが暗号化され、アプリケーションへのすべてのトラフィックがポリシー実施ポイント (PEP) によって認証されます。

    レイヤー 3 であるネットワークレイヤーでトラフィックを制御するために Kubernetes ネットワークポリシーを使用することに加えて、ASM はピア認証、リクエスト認証、Istio 承認ポリシー、および Open Policy Agent (OPA) ベースのきめ細かいアクセス制御も提供します。ASM は、これらのゼロトラストセキュリティ機能を提供して、セキュリティ目標の達成を支援します。

    ASM のゼロトラストセキュリティシステムには、次の側面が含まれます。

    • ワークロード ID: これは、ゼロトラストセキュリティシステムの基盤です。ASM は、各クラウドネイティブワークロードの ID を定義するための使いやすい方法を提供します。また、特定のシナリオのカスタム ID 定義方法も提供します。ID は、Secure Production Identity Framework for Everyone (SPIFFE) に準拠しています。

    • セキュリティ証明書: ASM は証明書を発行し、証明書のライフサイクル管理とローテーションを提供して、ゼロトラストセキュリティを実装します。ASM は、ID を含む TLS X.509 証明書を発行し、証明書と秘密鍵をローテーションします。すべてのプロキシが証明書を使用します。

    • ポリシーの実行: ポリシーはゼロトラストセキュリティに不可欠です。ASM は、Istio のロールベースアクセス制御 (RBAC) ポリシーと OPA ベースのきめ細かい承認ポリシーをサポートしています。

    • 可観測性と分析: ASM を使用すると、ポリシー実行のログとメトリックを観測できます。これに基づいて、各ポリシーの有効性を分析できます。

    ASM を使用してゼロトラストセキュリティを実装する理由

    アプリケーションコードにセキュリティメカニズムを追加する従来の方法と比較して、ASM には次の利点があります。

    • サイドカープロキシのライフサイクルはアプリケーションから独立しています。したがって、サイドカープロキシを簡単に管理できます。

    • ビジネスニーズに基づいてポリシーを構成および更新でき、新しいポリシーはすぐに有効になります。このようにして、アプリケーションを再デプロイする必要はありません。

    • ASM の集中制御アーキテクチャにより、企業のネットワークセキュリティチームは、企業全体に適用可能なセキュリティポリシーを構築、管理、およびデプロイできます。これにより、すべてのビジネスアプリケーションのセキュリティが確保されます。デプロイされたセキュリティポリシーは、開発者の追加の労力を必要とせずにすぐに有効になります。

    • ASM は、JSON Web Token (JWT) 機能などの機能を提供して、リクエスト内のユーザー資格情報を認証します。

    • ASM を使用すると、ID 認証および承認システムを ASM インスタンスのサービスとしてデプロイできます。ASM インスタンスの他のサービスと同様に、これらのセキュリティシステムも、ASM インスタンスによって提供されるセキュリティ対策（転送中暗号化、ID 認証、PEP、ユーザー資格情報の認証と承認など）の恩恵を受けます。

    ASM を使用すると、単一の制御プレーンを使用して、厳格な ID およびアクセス管理、Transport Layer Security (TLS) 暗号化、ID 認証と承認、および監査ログを実装できます。ASM は、これらの機能をすぐに使用できます。開発者、システム管理者、およびネットワークセキュリティチームは、マイクロサービス指向のアプリケーションを簡単に保護できます。

    ASM でゼロトラストシステムを使用する方法

    ASM は、クラウドネイティブ環境での攻撃対象領域を削減し、ゼロトラストアプリケーションネットワークを構築するための基本的なフレームワークを提供します。ASM は、エンドツーエンドの暗号化、サービスレベルの ID 認証、およびきめ細かい承認ポリシーを採用して、サービス間の通信を保護します。

    ASM は、次のセキュリティ対策をサポートしています。

    • サービスインタラクションで相互 TLS (mTLS) 認証またはサーバー側 TLS 認証が実行されます。自動証明書ローテーションなどの証明書ライフサイクル管理がサポートされています。ASM のすべての通信セッションでは、ID 認証が必要であり、暗号化されます。

    • ID ベースの承認が有効になっています。他の承認ディメンションも使用されます。RBAC は、最小限の権限の原則とともに使用されます。許可されたサービスのみが、ALLOW または DENY ルールに従って相互に通信できます。

    1

    ASM は、次のゼロトラストセキュリティ機能を提供します。ワークロード ID、ピア認証、リクエスト認証、承認ポリシー、および OPA ポリシー。

    ワークロード ID

    ASM インスタンスは、ASM インスタンスで実行される各マイクロサービスに一意の ID を割り当てます。マイクロサービスは、この ID を使用して、同じ ASM インスタンス内の他のマイクロサービスと通信します。この ID は、双方向認証で使用して、サービスへのアクセスを許可または拒否できます。この ID は、承認ポリシーでも使用できます。

    ASM を使用して Kubernetes クラスタで実行されるワークロードを管理する場合、ASM はワークロードのサービストークンに基づいて各ワークロードにサービス ID を割り当てます。

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

    ASM コンソールにログインして、ASM の Kubernetes クラスタにあるサービスのワークロード ID を表示できます。

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

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

    3. [ワークロード ID] ページの上部にある [データプレーン] ドロップダウンリストから目的のクラスタの ID を選択し、[名前空間] ドロップダウンリストから目的の名前空間を選択して、ASM の Kubernetes クラスタにあるサービスのワークロード ID を表示します。

    ピア認証

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

    • クライアントとサーバーの両方にサイドカープロキシが挿入されている場合、ASM 内のサービス間の通信に対して mTLS 暗号化が有効になります。

    • クライアントのみにサイドカープロキシが挿入されている場合、クライアントはサーバーの構成に基づいて通信の mTLS 暗号化を有効にします。

    • サーバーのみにサイドカープロキシが挿入されている場合、デフォルトの mTLS モードは permissive であり、サーバーがプレーンテキストと暗号化トラフィックの両方を受け入れることができることを示します。この場合にサーバーのピア認証を構成し、mTLS モードを strict に設定すると、リクエストは失敗します。

    リクエスト認証

    ASM は、ピア認証とリクエスト認証の 2 種類の認証を提供します。ASM を使用すると、ユーザーとシステムはリクエスト認証を使用してマイクロサービスと対話できます。一般に、JWT はリクエストを認証するために使用されます。

    マイクロサービスのリクエスト認証ポリシーを作成して、マイクロサービスへのリクエストに対して JWT ベースの認証を実装できます。リクエストに JWT が含まれている場合、リクエスト認証ポリシーを使用して JWT が有効かどうかを確認します。JWT が有効な場合にのみ、マイクロサービスにアクセスできます。リクエストに JWT が含まれていない場合、リクエストはチェックされず、マイクロサービスにはリクエストによって想定どおりにアクセスできます。

    説明

    承認ポリシーとリクエスト認証ポリシーを使用して、リクエストに有効な JWT が含まれている場合にのみマイクロサービスにアクセスできるように指定できます。この場合、無効な JWT を含むリクエストまたは JWT を含まないリクエストは、マイクロサービスにアクセスできません。

    1. リクエストを受信する Bookinfo アプリケーションをデプロイします。詳細については、「ASM インスタンスに追加された ACK クラスタにアプリケーションをデプロイする」をご参照ください。

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

      1. kubeconfig ファイルの情報に基づいて kubectl を使用して Container Service for Kubernetes (ACK) クラスタに接続し、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
---
// sleep ポッドをデプロイするための YAML ファイルです。
// このポッドは、curl コマンドを使用して他のサービスへのリクエストをシミュレートします。
// sleep コマンドを使用して、ポッドを長時間実行状態に保ちます。

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

        kubectl apply -f sleep.yaml -n default
// sleep.yaml ファイルを適用して、sleep アプリケーションをデプロイします。
// -n default は、アプリケーションを "default" 名前空間にデプロイすることを指定します。

    3. details サービスにアクセスするためのすべてのリクエストに対して JWT 認証を要求するリクエスト認証ポリシーを作成します。

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

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

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

        3

        次のセクションでは、いくつかのパラメータについて説明します。

        • issuer: JWT の発行者。この例では、このパラメータは testing@asm.istio.io に設定されています。

        • audiences: JWT の対象者。このパラメータは、JWT を使用して目的のサービスにアクセスできるサービスを指定します。この例では、対象者は指定されていません。これは、すべてのサービスが JWT を使用して目的のサービスにアクセスできることを示します。

        • jwks: JWT リクエスト情報。この例では、このパラメータは次のコードブロックに示す内容に設定されています。詳細については、「jwks.json」をご参照ください。

          { "keys":[ {"e":"AQAB","kid":"DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ","kty":"RSA","n":"xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"}]}
// JWT (JSON Web Token) の公開鍵情報です。
// この情報は、JWT の署名を検証するために使用されます。

    4. JWT ツール を使用して、JWT リクエスト情報を JWT 文字列にエンコードします。

      { "keys":[ {"e":"AQAB","kid":"DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ","kty":"RSA","n":"xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"}]}
// JWT (JSON Web Token) の公開鍵情報です。
// この情報は、JWT の署名を検証するために使用されます。

      エンコード後の JWT 文字列 (想定):

      eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3Uc1MI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg
// エンコードされた JWT 文字列です。
// この文字列は、リクエストヘッダーに含めて認証に使用されます。

    5. リクエスト認証ポリシーが想定どおりに有効になっていることを確認します。

      1. 次のコマンドを実行して、エンコードされた JWT 文字列を使用して details サービスにアクセスします。

        export TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3Uc1MI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_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'
// JWT を使用して details サービスにアクセスします。
// details サービスは、Bookinfo アプリケーションの一部です。
// %{http_code}\n は、HTTP ステータスコードを出力します。

        値 200 が返されます。これは、details サービスに想定どおりにアクセスできたことを示します。

      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'
// 無効な JWT を使用して details サービスにアクセスします。
// badtoken は無効な JWT を表します。
// %{http_code}\n は、HTTP ステータスコードを出力します。

        値 403 が返されます。これは、details サービスにアクセスできなかったことを示します。

      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'
// JWT トークンを含まないリクエストを送信して details サービスにアクセスします。
// %{http_code}\n は、HTTP ステータスコードを出力します。

        値 200 が返されます。これは、details サービスに想定どおりにアクセスできたことを示します。

        前述の結果は、リクエストに有効な JWT が含まれている場合、または JWT が含まれていない場合にリクエストが details サービスにアクセスでき、無効な JWT を含むリクエストは details サービスにアクセスできないことを示しています。これは、リクエスト認証ポリシーが有効になっていることを示します。

    承認ポリシー

    マイクロサービスの承認ポリシーを作成して、指定された要件を満たすリクエストのみがマイクロサービスにアクセスできるように指定できます。たとえば、有効なリクエストのポート、IP アドレス、および送信元を指定できます。この例では、承認ポリシーを使用して、リクエストに指定された発行者によって発行された JWT が含まれている場合にのみ、リクエストが宛先サービスにアクセスできるように指定します。

    1. リクエストを受信する Bookinfo アプリケーションをデプロイします。詳細については、「ASM インスタンスに追加された ACK クラスタにアプリケーションをデプロイする」をご参照ください。

    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
---
// sleep ポッドをデプロイするための YAML ファイルです。
// このポッドは、curl コマンドを使用して他のサービスへのリクエストをシミュレートします。
// sleep コマンドを使用して、ポッドを長時間実行状態に保ちます。

      2. kubeconfig ファイルの情報に基づいて kubectl を使用して ACK クラスタに接続し、次のコマンドを実行して sleep サービスをデプロイします。

        kubectl apply -f sleep.yaml -n default
// sleep.yaml ファイルを適用して、sleep アプリケーションをデプロイします。
// -n default は、アプリケーションを "default" 名前空間にデプロイすることを指定します。

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

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

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

    4. [作成] ページで、[名前空間] ドロップダウンリストから [default] を選択し、次の YAML コードをコードエディタにコピーして、[作成] をクリックします。

      YAML コードのフィールドの詳細については、「Authorization Policy」をご参照ください。

      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
// details サービスへのアクセスを制御するための承認ポリシーです。
// testing@secure.istio.io/testing@secure.istio.io からの JWT を持つリクエストのみを許可します。

    5. 次のコマンドを実行して、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'
// JWT トークンを含まないリクエストを送信して details サービスにアクセスします。
// %{http_code}\n は、HTTP ステータスコードを出力します。

      期待される出力:

      403
// HTTP ステータスコード 403 (Forbidden) が返されます。
// これは、承認ポリシーによってリクエストが拒否されたことを示します。

      JWT を含まないリクエストは details サービスにアクセスできません。これは、承認ポリシーが想定どおりに有効になっていることを示します。承認ポリシーは、testing@secure.istio.io によって発行された JWT をリクエストに含む場合にのみ、リクエストが宛先サービスにアクセスできるように指定します。

    OPA ポリシー

    OPA は汎用ポリシーエンジンであり、アプリケーションのきめ細かいアクセス制御を可能にします。OPA は、マイクロサービスとともにスタンドアロンサービスとしてデプロイできます。アプリケーションを保護するには、アプリケーションのマイクロサービスへの各リクエストが処理される前に承認されていることを確認します。マイクロサービスは OPA に API 呼び出しを行い、リクエストが承認されているかどうかを確認します。詳細については、OPA にアクセスしてください。

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

    まとめと例

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

    • 証明書のライフサイクル全体を管理するインフラストラクチャ。証明書の発行と CA 証明書のローテーションを簡素化します。

    • ID 認証ポリシー、承認ポリシー、およびセキュリティネーミング情報を Envoy プロキシに配布するマネージドコントロールプレーン API。

    • PEP を使用して ASM インスタンスのセキュリティを確保するサイドカープロキシ。

    • テレメトリデータの収集と監査を可能にする Envoy 拡張機能。

    各ワークロードには、ID を含む TLS X.509 証明書があります。各サイドカープロキシはこの証明書を使用します。ASM は証明書を提供し、証明書と秘密鍵を定期的にローテーションします。秘密鍵が盗まれた場合、ASM はすぐに新しい秘密鍵に置き換えます。これにより、攻撃対象領域が減少します。

    例

    • 承認ポリシーがイングレスゲートウェイに追加され、IP ベースのアクセス制御またはカスタム外部承認に基づくアクセス制御が実装されます。

    • インターネット金融の顧客は、リージョン間の複数言語アプリケーションにアクセス制御を実装したいと考えています。ASM は、顧客に承認ポリシーを提供して、アプリケーションを外部ネットワークから保護します。また、ASM は、エグレスゲートウェイを使用してエグレストラフィックを監査します。エグレストラフィックの監査と承認ポリシーは、アプリケーションがサードパーティサービスにアクセスすることを制御します。