マルチテナント SaaS 認証と API アクセスコントロール: 実装オプションとベストプラクティス

Tabby Ward、Thomas Davis、Gideon Landeman、Tomas Riha、Amazon Web Services (AWS）

2024 年 5 月 (ドキュメント履歴 )

認可と API アクセスコントロールは、多くのソフトウェアアプリケーション、特にマルチテナント Software as a Service (SaaS) アプリケーションにとって課題です。この複雑さは、保護する必要があるマイクロサービス APIsの拡散と、さまざまなテナント、ユーザー特性、アプリケーションの状態から発生する多数のアクセス条件を考慮すると明らかです。これらの問題に効果的に対処するために、ソリューションは、マイクロサービス、バックエンド for Frontend (BFF) レイヤー、およびマルチテナント SaaS アプリケーションのその他のコンポーネントによって提供される多くの APIs にわたってアクセス制御を実施する必要があります。このアプローチには、多くの要因と属性に基づいて複雑なアクセス決定を行うことができるメカニズムが伴う必要があります。

従来、API アクセスコントロールと承認はアプリケーションコードのカスタムロジックによって処理されていました。このアプローチは、このコードにアクセスできるデベロッパーが誤って、または意図的に認証ロジックを変更し、不正アクセスを引き起こす可能性があるため、エラーが発生しやすく、安全ではありませんでした。アプリケーションコード内のカスタムロジックによって行われた決定を監査することは困難でした。監査人は、特定の標準を維持する上での有効性を判断するためにカスタムロジックに専念する必要があるためです。さらに、API アクセスコントロールは一般的に不要でした。これは、保護する APIs の数が少ないためです。マイクロサービスやサービス指向アーキテクチャを優先するアプリケーション設計のパラダイムシフトにより、認証とアクセス制御の形式を使用する必要がある APIsの数が増えました。さらに、マルチテナント SaaS アプリケーションでテナントベースのアクセスを維持する必要性は、テナンシーを維持するために追加の認可の課題を提示します。このガイドで概説されているベストプラクティスには、いくつかの利点があります。

• 認証ロジックは、プログラミング言語に固有ではない高レベルの宣言言語で一元管理および記述できます。

• 認証ロジックはアプリケーションコードから抽象化され、アプリケーションのすべての APIsに繰り返し可能なパターンとして適用できます。

• 抽象化により、デベロッパーによる認証ロジックへの偶発的な変更を防ぐことができます。

• SaaS アプリケーションへの統合は、一貫性があり、シンプルです。

• 抽象化により、API エンドポイントごとにカスタム認証ロジックを記述する必要がなくなります。

• 監査は簡素化されます。監査人がコードを確認してアクセス許可を決定する必要がなくなるためです。

• このガイドで概説されているアプローチは、組織の要件に応じて複数のアクセスコントロールパラダイムの使用をサポートします。

• この認可とアクセスコントロールのアプローチにより、SaaS アプリケーションの API レイヤーでテナントデータの分離を簡単に維持できます。

• ベストプラクティスは、認可に関してテナントのオンボーディングとオフボーディングに一貫したアプローチを提供します。

• このアプローチでは、このガイドで説明するように、利点と欠点の両方を持つさまざまな認可デプロイモデル (プールまたはサイロ) を提供します。

ターゲットを絞ったビジネス成果

この規範的ガイダンスでは、マルチテナント SaaS アプリケーションに実装できる認可と API アクセスコントロールの反復可能な設計パターンについて説明します。このガイダンスは、複雑な認証要件または厳格な API アクセスコントロールのニーズを持つアプリケーションを開発するすべてのチームを対象としています。このアーキテクチャでは、ポリシー決定ポイント (PDP) またはポリシーエンジンの作成と、APIs。PDP を作成するための 2 つの特定のオプションについて説明します。Cedar SDK での Amazon Verified Permissions の使用と、Rego ポリシー言語での Open Policy Agent (OPA) の使用です。このガイドでは、属性ベースのアクセスコントロール (ABAC) モデルまたはロールベースのアクセスコントロール (RBAC) モデル、または両方のモデルの組み合わせに基づいてアクセスを決定する方法についても説明します。このガイドに記載されている設計パターンと概念を使用して、マルチテナント SaaS アプリケーションにおける認可と API アクセスコントロールの実装を通知し、標準化することをお勧めします。このガイダンスは、以下のビジネス成果を達成するのに役立ちます。

• マルチテナント SaaS アプリケーション用の標準化された API 認証アーキテクチャ – このアーキテクチャは、ポリシーが保存および管理されるポリシー管理ポイント ("")、承認決定に達するためにそれらのポリシーが評価されるポリシー決定ポイント (PDP)、およびその決定を適用するポリシー適用ポイント (PEP) の 3 つのコンポーネントを区別します。ホストされた認証サービスである Verified Permissions は、 と PDP の両方として機能します。または、Cedar や OPA などのオープンソースエンジンを使用して PDP を自分で構築することもできます。

• アプリケーションから認証ロジックを分離する – 認証ロジックは、アプリケーションコードに埋め込まれたり、アドホックな強制メカニズムによって実装されたりすると、意図しないクロステナントデータアクセスやその他のセキュリティ違反を引き起こす偶発的または悪意のある変更の対象となる可能性があります。これらの可能性を軽減するために、Verified Permissions などの を使用して、アプリケーションコードとは別に承認ポリシーを保存し、それらのポリシーの管理に強力なガバナンスを適用できます。ポリシーは高レベルの宣言言語で一元管理できるため、アプリケーションコードの複数のセクションにポリシーを埋め込む場合よりも、認証ロジックの維持がはるかにシンプルになります。このアプローチにより、更新が一貫して適用されるようになります。

• アクセスコントロールモデルへの柔軟なアプローチ – ロールベースのアクセスコントロール (RBAC)、属性ベースのアクセスコントロール (ABAC)、または両方のモデルの組み合わせはすべて、アクセスコントロールに対する有効なアプローチです。これらのモデルは、さまざまなアプローチを使用して、ビジネスの認証要件を満たすように試みます。このガイドでは、これらのモデルを比較して比較し、組織に適したモデルを選択するのに役立ちます。このガイドでは、これらのモデルが OPA/Rego や Cedar などのさまざまな認可ポリシー言語にどのように適用されるかについても説明します。このガイドで説明するアーキテクチャにより、モデルのいずれかまたは両方を正常に採用できます。

• 厳格な API アクセスコントロール – このガイドでは、最小限の労力でアプリケーション内で APIs を一貫して広範囲に保護する方法を提供します。これは、アプリケーション内通信を容易にするために一般的に多数の APIs を使用するサービス指向またはマイクロサービスアプリケーションアーキテクチャに特に役立ちます。厳格な API アクセスコントロールは、アプリケーションのセキュリティを強化し、攻撃や悪用の影響を受けにくくします。

テナント分離とマルチテナント認証

このガイドでは、テナント分離とマルチテナント認証の概念について説明します。テナント分離とは、共有インフラストラクチャで運用されている場合でも、各テナントのリソースを分離するために SaaS システムで使用する明示的なメカニズムを指します。マルチテナント認証とは、インバウンドアクションを承認し、間違ったテナントに実装されないようにすることです。架空のユーザーは認証および承認され、引き続き別のテナントのリソースにアクセスできます。認証と承認によってこのアクセスがブロックされることはありません。この目的を達成するには、テナント分離を実装する必要があります。これら 2 つの概念の違いの詳細については、ホワイトペーパーの「SaaS アーキテクチャの基礎」の「テナント分離」セクションを参照してください。 SaaS