クロステナントのアクセスの防止

各 SaaS アーキテクチャでは、テナントが他のテナントのリソースにアクセスするのを防止する方法についても考慮する必要があります。設計上は、特定のタイミンで Lambda 機能を実行できるのは 1 つのテナントのみであるため、AWS Lambda を使用してテナントを隔離する必要性について疑問に思われるかもしれません。確かにそのとおりですが、隔離において、機能を実行しているテナントが、他のテナントに属する可能性のある他のリソースにアクセスしないようにする必要もあります。

SaaS プロバイダーにおいて、サーバーレス SaaS 環境に隔離を実装するための基本的なアプローチが 2 つあります。この最初のアプローチでは、サイロのパターンに従い、各テナントの Lambda 機能の個別のセットをデプロイします。このモデルでは、各テナントの実行ロールを定義し、各テナントの個別の機能をその実行ロールとともにデプロイします。この実行ロールは、特定のテナントでどのリソースがアクセス可能なのかを定義します。このモデルで一連のプレミアム層のテナントをデプロイするとします。しかし、これは管理が困難で、アカウントの制限に達する可能性があります (システムがサポートするテナント数による)。

もう 1 つのアプローチは、プールモデルにより合わせられています。ここでは、すべてのテナントからの呼び出しを受け入れるために十分な範囲を持つ実行ロールとともに、機能がデプロイされます。このモデルでは、マルチテナントの機能の実装でのランタイムで、隔離を適用する必要があります。図 2 は、これがどのようにして行われるかを示しています。

図 2: サーバーレス環境での隔離

この例では、一連の Lambda 機能にアクセスする 3 つのテナントがあることがわかります。これらの機能は共有されているため、すべてのテナントをカバーする実行ロールとともにデプロイされます。これらの機能の実装の中で、AWS Security Token Service (AWS STS) からの新たな一連のテナント範囲の認証情報を取得するために、現在のテナントのコンテキスト (JWT を介して提供される) が使用されます。これらの認証情報があれば、テナントのコンテキストでリソースにアクセスするために使用できます。この例では、ストレージにアクセスするためにこれらの範囲が指定された認証情報を使用します。

このモデルでは、隔離モデルの一部が Lambda 機能のコードにプッシュされるという点に注意してください。デベロッパーの視野外でこの概念を導入できる、機能ラッパーなどのテクニックがあります。これらの認証情報の取得の詳細を Lambda レイヤーに移動させ、さらにシームレスで中央管理された構造にすることもできます。