Amazon Web Services ブログ

VPC Lattice サービスネットワーク内での SaaS サービス接続

多くの AWS 顧客は、開発プロセスを高速化し、アーキテクチャの一部としてそれぞれのサービスをスケールアウトする機能を向上させるために、モジュール化されたアプリケーションの近代化を行っています。これには顧客が開発したアプリケーションと、パートナーが開発した SaaS アプリケーションが含まれます。アプリケーション間の通信には、Amazon Web Services (AWS) 環境全体でのネットワーク接続が必要です。これらのアプリケーションについて、顧客とパートナーは、パートナーが各種 AWS サービスを使ってアプリケーションへのアクセスを許可する、さまざまなネットワーク接続モデルを使用します。アプリケーション間の通信を接続、監視、保護するネットワーク構造の 1 つが Amazon VPC Lattice です。顧客は、サービスへのアクセスをコントロールするきめ細かなアクセス制御ポリシーを使って、簡素化された安全なネットワーク接続モデルを提供する VPC Lattice を利用します。例えば、顧客はサービスネットワークに関連付けられている Amazon Virtual Private Cloud (VPC) の各クライアントアプリケーションから SaaS サービスとの通信方法をポリシーで定義します。

この記事では、Amazon VPC Lattice 内の SaaS サービスをどのように接続するかについて説明します。
SaaS サービスの接続を可能にする VPC Lattice 内のコンポーネントを確認し、パートナーアカウントと VPC にデプロイされた SaaS サービスを接続するためのベストプラクティスを概説します。
また、パートナーの視点と顧客の視点の両方から認証ポリシーの例を確認し、サービスネットワーク内のサービスへのアクセスを許可または拒否する方法を示します。

前提条件

以降のセクションでは、AWS Identity and Access Management (IAM) ポリシーの作成と、VPC Lattice の基本的な概念 (サービス、サービスネットワーク、認証ポリシーなど) を把握していることを前提とします。
また、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Elastic Kubernetes Service (Amazon EKS)、AWS Lambda を使ってサービスやアプリケーションをデプロイする方法に習熟していることを前提とします。

ソリューション概要

パートナーと VPC Lattice 内でサービスを共有するには、この接続モデルを提供する 2 つの機能、リソース共有とセキュリティコントロールがあります。
例として 3 つのサービスで構成するシンプルなアーキテクチャを使用します。
アプリケーションのフロントエンドとバックエンドの 2 つのサービスがお客様のアカウント内に存在します。
さらに、パートナーの SaaS ソリューションをサービスネットワークに追加し、異なるサービス間の通信を可能にします。
図 1 にこのネットワークの一部としてデプロイされたアプリケーションを示しています。

Figure 1: Application architecture between customer account and SaaS account

図 1: 顧客アカウントと SaaS アカウント間のアプリケーションアーキテクチャ

リソース共有

SaaS プロバイダと AWS アカウントまたは AWS Organizations アカウント内のサービスネットワークとの間でサービスを共有するには、AWS Resource Access Manager (AWS RAM) を利用します。
AWS RAM は、VPC Lattice リソースを他の AWS アカウントまたは組織と共有できるサービスです。
AWS RAM を使うと、パートナーは独自の SaaS サービスを共有し、あなたのサービスネットワークにアクセスし、VPC Lattice の一部としてデプロイされたサービスと VPC との間での通信を許可できます。
パートナーが所有する VPC Lattice リソースを他の AWS アカウントと共有する場合、それらのアカウントは、サービスやサービスネットワークなど、パートナーのリソースをお客様のアカウントのリソースに関連付けることができます。
AWS RAM では、パートナーが共有するテナンシモデルに応じて、1 つまたは複数のアカウントとサービスを共有できます。詳細は後の項で説明します。
共有リソースに対してアソシエーションを作成すると、リソースを所有しているアカウントに Amazon Resource Name (ARN)が生成され、アソシエーションを作成したアカウントにも ARN が生成されます。

AWS RAM の強力なコンセプトの 1 つに、リソース共有がリソース所有者と、リソース所有者が直接共有する AWS アカウントもしくは組織との間でのみ行われるという点があります。そうした AWS アカウントや組織は、他のアカウントと直接リソースを共有することはできません (推移的な共有はできません)。例として、図 2 では SaaS アカウントが SaaS サービスを Account A と共有し、Account A はそのリソースをサービスネットワークに追加します。そのサービスネットワークの他のサービスも、VPC Lattice サービスとサービスネットワーク認証ポリシーがアクセスを許可している限り、SaaS サービスにアクセスできます。しかし、AWS RAM 内のリソースは推移的に共有することはできません。たとえば、Account A は Account B にサービスを共有してその サービスネットワークに SaaS サービスを追加することはできません。Account B がサービスネットワークに SaaS サービスを追加したい場合、SaaS アカウントから直接共有する必要があります。

Figure 2: Transitive service sharing is not permitted with AWS RAM

図 2: AWS RAM では推移的なサービス共有は許可されない

AWS RAM の動作がわかったところで、図 1 に示した SaaS サービスの共有方法を説明します。まず、SaaS アカウントが単一の SaaS サービスを作成しました。
AWS RAM 経由で、SaaS サービスはパートナーが提供するサービスを提供し、これがお客様のサービスネットワークに接続されます。

Figure 3: SaaS service created in the SaaS provider account

図 3: SaaS プロバイダー アカウントで作成された SaaS サービス

SaaS サービスをアカウントと共有するためには、パートナーがターゲットの AWS アカウントまたは組織向けに AWS RAM でリソース共有を作成します。
リソース共有で、パートナーは次の項目を選択します。

  • 共有するリソース: これには、パートナーがお客様の AWS アカウントまたは組織と共有する 1 つ以上の VPC Lattice サービスが含まれます。
  • リソース共有に関連した権限: デフォルトでは、VPC Lattice サービスの権限には VPC Lattice サービスの情報を取得する権限と VPC Lattice サービスをネットワークに関連付ける権限が含まれます。リソース共有で他の権限を許可するかどうかは、パートナーがカスタマイズできます。
  • アクセスを許可される対象: これは、パートナーがリソースを共有するアクセス権限を持つ対象の AWS アカウントまたは組織を指定します。

図 4 に示すように、パートナーがアカウントで SaaS サービスを共有すると、AWS RAM と VPC サービス の両方で共有されたサービスが表示されます。

Figure 4: Sharing the SaaS service with the customer account

図 4: SaaS サービスと顧客アカウントの共有

この例では、図 5 に示すように、サービスがあなたのアカウントに表示されます。

Figure 5: VPC Lattice services within your account

図 5: アカウント内の VPC Lattice サービス

既に AWS アカウントでデプロイされているサービスネットワークに SaaS サービスを追加します。これにより、自身のサービス (フロントエンドとバックエンド) と SaaS サービスの間でサービス間通信が可能になります。
ただし、その前にサービスネットワーク内におけるサービス間のセキュリティと認証ポリシーについて説明します。

VPC Lattice 内のセキュリティコントロール

セキュリティコントロールの観点から、VPC Lattice 認証ポリシーを使用すると、サービスネットワークまたはサービスネットワーク内のサービスグループに IAM ポリシーを割り当てることができます。
これにより、VPC Lattice 内の各サービスとサービスネットワークへのアクセスを制御できるメカニズムを提供します。
各認証ポリシーは AWS IAM リソースポリシーであり、サービスアクセスリクエストへのリクエストレベルの認証とコンテキストに応じた承認を提供します。
認証ポリシーは、IAM リソースレベルでアクセスを許可または拒否するための強力な機能を提供し、セキュリティグループやネットワークアクセスコントロールリスト (ACL)といったネットワークレベルの構成に加えて利用できます。

パートナー側の視点とお客様側の視点という 2 つの立場からシナリオを見ていきましょう。
パートナー側は、サービスを共有し、お客様側は VPC Lattice のサービスネットワークに SaaS サービスを追加します。
アーキテクチャは図 1 に示したものと同じで、フロントエンド、バックエンド、SaaS サービスで構成されます。
認証と認可の観点では、パートナー側はどの AWS アカウントや組織がサービスにアクセスできるかを決めるポリシーをデプロイします。
一方、お客様側は、サービス同士がどのように通信するかを決めるポリシーをデプロイします。

パートナー視点

VPC Lattice でサービスを提供するパートナーの場合、SaaS ソリューションのテナント分離戦略は、パートナーがリソースを共有する方法と、VPC Lattice サービスに追加する必要があるアクセス制御のポリシーに影響します。
SaaS アプリケーションの種類(フロントエンド、バックエンド、データアプリケーションなど)によって、パートナーが SaaS ソリューションをデプロイする方法が異なります。

シングルテナントモデル

シングルテナントモデルでは、パートナーは VPC Lattice サービスを単一のお客様と共有します。ただし、1 つの AWS アカウント、複数の AWS アカウント、または AWS Organizations アカウントの中の 1 つの組織で共有する場合があります。
パートナーサービス内のすべてのリソースは、単一のお客様に紐づけられ、他の SaaS 顧客からは分離されています。パートナーは、すべてのリソースを別々のアカウントや VPC に配置する必要はありません。ただし、各 VPC Lattice サービスを個々の顧客向けにプロビジョニングされたリソースに紐付ける必要があります。このモデルでは、パートナーの認証ポリシーにより、指定の AWS アカウントまたは組織に所属する認証済みプリンシパルからのリクエストへのアクセスが許可されます。

Figure 6: SaaS provider sharing the service with a single tenant

図 6: シングルテナントとサービスを共有する SaaS プロバイダー

例を見てみましょう。パートナーが組織と共有している SaaS サービスがあると想定します。認証と認可の観点から、SaaS プロバイダーは、指定された組織に属する主体者から発信された認証済みのリクエストに対してのみ権限を付与したいと考えています。このためパートナーは、次のポリシーを作成し、SaaS サービスにこのポリシーを適用します。

{
   "Version":"2012-10-17",
   "Statement":[ 
      {
         "Effect": "Allow",
         "Principal": "*",
         "Action": "vpc-lattice-svcs:Invoke",
         "Resource": [ 
            " arn:aws:vpc-lattice:us-east-1:444455556666:service/svc-0b847e0ccdc496cb3/*"
         ],
         "Condition": {
            "StringEquals": {
               "aws:PrincipalOrgID": [ 
                  "o-123456customer1"
               ] 
            }
         }
      }
   ] 
}

このポリシーにより、組織 ID (o-123456customer1) から SaaS サービス (svc-0b847e0ccdc496cb3) へのリクエストが許可されます。

マルチテナントモデル

マルチテナントモデルでは、パートナーが複数の顧客と VPC Lattice サービスを共有します。
SaaS サービス全体で顧客間でリソースを共有し、パートナーのサービスへのアクセスにはテナントごとの識別認証、パスベースの認証ポリシー、またはアプリケーションベースの別のメカニズムを使用して、リソースやカスタマーデータへのアクセスを定義します。
このモデルでは、パートナーの認証ポリシーが、顧客間の認証済み要求をすべて許可するか、または特定の顧客に対してのみ特定のパスへのアクセスを許可します。これは図 7 に示されています。

Figure 7: Saas provider sharing the service with multiple tenants

図 7: マルチテナントとサービスを共有する Saas プロバイダー

前の例を拡張して、パートナーは複数の顧客が利用する単一の SaaS サービスを展開し、サービスパスで認可を分離します。
これを実現するために、パートナーは前の例のポリシーを次のような例に変更し、SaaS サービスにポリシーを適用します。

{
   "Version":"2012-10-17",
   "Statement":[ 
      {
         "Effect": "Allow",
         "Principal": "*",
         "Action": "vpc-lattice-svcs:Invoke",
         "Resource": [ 
            " arn:aws:vpc-lattice:us-east-1:444455556666:service/svc-0b847e0ccdc496cb3/customer1"
         ],
         "Condition": {
            "StringEquals": {
               "aws:PrincipalOrgID": [ 
                  "o-123456customer1"
               ] 
            }
         }
      },
      {
         "Effect": "Allow",
         "Principal": "*",
         "Action": "vpc-lattice-svcs:Invoke",
         "Resource": [ 
            " arn:aws:vpc-lattice:us-east-1:444455556666:service/svc-0b847e0ccdc496cb3/customer2"
         ],
         "Condition": {
            "StringEquals": {
               "aws:PrincipalOrgID": [ 
                  "o-123456customer2"
               ] 
            }
         }
      }
   ] 
}

次に、パートナーが顧客 1 に /customer1 パスを使用して SaaS サービスへのアクセスを許可します (組織 o-123456customer1 から)。パートナーは顧客 2 に /customer2 パスを使用して SaaS サービスへのアクセスを許可します (組織 o-123456customer2 から)。
同じサービスを複数の顧客で共有しますが、認証ポリシーによって、トラフィックの発信元に応じて異なるパスへのアクセスを許可または拒否できます。

顧客視点

お客様の観点では、どのサービスがパートナーの SaaS サービスにアクセスするのか、また SaaS サービスからサービスネットワーク内の他のサービスへの接続を開始するかどうかを検討する必要があります。
認証ポリシー内の複数の条件に基づいてアクセスを許可または拒否する、細かく制御可能な認証ポリシーを作成できます。
自身のサービス間通信に作成するポリシーと同様に、管理者はサービスネットワークに追加される各 SaaS ソリューションに対してどのようなアクセスを与えるかを決定する必要があります。次に図 8 を見てみましょう。

Figure 8: Front-end VPC initiates requests to the backend and SaaS services. All other requests are denied.

図 8: フロントエンド VPC は、バックエンド サービスと SaaS サービスへのリクエストを開始します。他のリクエストはすべて拒否されます。

この例では、バックエンドサービスと SaaS サービスの 2 つのサービスをサービスネットワークに関連付けています。
さらに、フロントエンド VPC からサービスネットワークへの接続を開始できるように、フロントエンド VPC との VPC 関連付けを作成しています。
フロントエンド VPC からバックエンドサービスと SaaS サービスへの接続のみを許可し、他の VPC からの接続は許可しない設定にします。
この設定を行うには、以下のポリシーを記述し、サービスネットワークに適用します。

{
   "Version":"2012-10-17",
   "Statement":[ 
      {
         "Effect": "Allow",
         "Principal": "*",
         "Action": "vpc-lattice-svcs:Invoke",
         "Resource": [ 
            " arn:aws:vpc-lattice:us-east-1:444455556666:service/svc-0b847e0ccdc496cb3/*",
            " arn:aws:vpc-lattice:us-east-1:111122223333:service/svc-0be0b12dd1d277c58/*",
         ],
         "Condition": {
            "StringEquals": {
               "vpc-lattice-svcs:SourceVPC": " vpc-1a2b3c4d"
            }
         }
      }
   ] 
}

このポリシーにより、フロントエンドサービス (vpc-1a2b3c4d) がバックエンドサービス (svc-0be0b12dd1d277c58) と SaaS サービス (svc-0b847e0ccdc496cb3) の両方に要求を送信できるようになります。
これで、お客様のサービスと組織で利用されているパートナーの SaaS サービスの間でサービス間通信を行うためのサービスネットワークが構築できました。

注意点

  • VPC Lattice でサポートされているリスナープロトコルとポートは、VPC Lattice ユーザーガイドに記載されています。
  • VPC Lattice サービスの所有者のみがそのサービスにアクセス権限ポリシーを追加できます。所有者があなたにサービスを共有した場合は、サービスネットワークまたはサービスネットワーク内のサービスに対してアクセス権限ポリシーを作成できます。

結論

この記事では、Amazon VPC Lattice を使用してサービスネットワーク全体のサービスと SaaS サービス間の安全な接続を提供する方法について説明しました。
パートナーがあなたの AWS アカウントまたは組織とサービスを共有する方法を確認しました。
次に、パートナーとあなた両方がサービスネットワーク内のサービス間通信を許可または拒否するために認証ポリシーを作成する例を示しました。
この記事に関する質問がある場合は、AWS re:Post に質問を投稿してください。
Amazon VPC Lattice の詳細については、Amazon VPC Lattice ドキュメント および VPC Lattice について説明する追加の Networking & Content Delivery ブログ投稿を参照してください。

本記事は、Connecting Saas services within a VPC Lattice service network を翻訳したものです。翻訳は Solutions Architect の 長屋 が担当しました。