次の方法で共有

Azure での SaaS ワークロードの ID およびアクセス管理

  • [アーティクル]

アプリケーション ID は、データを保護するための防御の第一線として機能するため、SaaS ワークロードにとって重要な領域です。 プロジェクトの後半まで見過ごされることが多いものの、アプリケーションの他の要素に関する多くの決定事項は、堅実な ID 戦略に依存します。 顧客データの保護に役立つ ID の重要性を過小評価してはいけません。

SaaS ワークロードのコンテキストにおいては、2 つの異なる種類の ID があります。

  • アプリケーション ID: "顧客 ID およびアクセス管理 (CIAM)" とも呼ばれます。これにより、エンド ユーザーは SaaS アプリケーションを認証して使用できるようになります。 アプリケーション ID プロバイダーにユーザーをサインインするには、主に次の 2 つの方法があります。

    • フェデレーション ID。 ユーザーは、別の ID プロバイダーによって管理されている既存の資格情報を使用してサインインします。 そのプロバイダーは、Google、Facebook、LinkedIn などのソーシャル ID プロバイダーか、顧客が使用する Microsoft Entra や Okta などのエンタープライズ ID プロバイダーである場合があります。 ユーザー アカウントのメンテナンスは、フェデレーション ID プロバイダーの責任となります。

    • ローカル ID。 ユーザーは、アプリケーション用のアカウントのみを作成します。 そのアカウントは、ユーザー名とパスワード、パスキー、またはその他の認証方法によってセキュリティで保護されます。 ユーザー アカウントのメンテナンスは、ユーザーの責任となります。

  • エンタープライズ ID: ビジネス生産性ツール、内部のツールまたはサービス、Azure サービスに対して、内部のユーザーとワークロードを認証するために使用される ID ソリューションです。 内部のユーザーとワークロードにエンタープライズ ID ソリューションを使用し、ビジネス生産性ツール、内部のツールまたはサービス、Azure サービスに対して認証します。

    SE:05 ID およびアクセス管理を参照してください。

アプリケーション ID とエンタープライズ ID の関係を示すダイアグラム。

アプリケーションおよびエンタープライズの ID は異なる目的で機能し、異なる ID プロバイダーを使用する場合があります。 この記事では、アプリケーション ID の設計上の考慮事項に焦点を当てていますが、どちらの種類も SaaS ワークロード環境内に存在する場合があります。

ID 管理には、認証 (ユーザー ID の確認) と認可 (ID に基づくアクセス許可の付与) の、2 つの関連する考慮事項が含まれます。 この記事の最初の 3 つのセクションでは、SaaS の認証に焦点を当てています。 最後のセクションでは、SaaS プロバイダーの認可に関する考慮事項について説明します。

マルチテナント アプリケーションでの ID

マルチテナント アプリケーションでは、テナント データを分離して保持することが重要です。 そのセグメント化は、効果的なユーザー認証と認可の選択によって推進されます。 また、テナント モデルの選択は、ID プロバイダーに関する決定事項に大きく影響します。 主要なセキュリティ境界として ID を優先してください。

SE:04 セグメント化の推奨事項を参照してください。

設計上の考慮事項

アプリケーションのテナントおよびデプロイのモデルについて理解する。 ID 戦略に影響を与える微妙な認識違いがある可能性があります。 たとえば、デプロイ スタンプ パターンでは、各スタンプ内に ID プロバイダーが必要であるという誤解があります。 ほとんどの ID プロバイダーでは、多くの場合、代替の分離モデルを使用できます。

マルチテナント用に ID プロバイダーを選択する場合は、障害の影響を評価します。 構成を間違えると、すべてのテナントのアプリケーション全体がダウンする潜在的なおそれがあります。 潜在的な影響範囲のリスクに対するオーバーヘッド コストを比較検討します。

ソリューションを顧客の Azure 環境にデプロイし、顧客の代わりにそれを管理する場合は、エンタープライズ ID プロバイダーとの統合が必要になる場合があります。 次の側面を明確に理解してください。

  • ユーザーの種類と、アプリケーション テナントとやり取りする場合のアクセスのニーズ。 たとえば、ユーザー A はテナント 1 へのサインインにのみアクセスが必要ですが、ユーザー B はテナント 1 とテナント 2 の両方へのサインインにアクセスが必要な場合があります。
  • データ所在地の規制への準拠 (その ID プロバイダーに適用される場合)。 場合によっては、ID プロバイダーによって格納されるデータが規制の対象になる可能性があります。 多くの ID プロバイダーは、このシナリオに固有のガイダンスと機能を提供しています。 このシナリオに関連するかどうかを評価し、コンプライアンスを確保するために必要な手順を実行します。

設計の推奨事項

推奨 特長
複数テナント用のソリューションをパーティション分割するための、ID プロバイダーのベスト プラクティスとガイドラインに従います。 テナントの分離は、セキュリティとコンプライアンスの目標を達成するのに役立ちます。
同じユーザーに複数アカウントを持たせないようにします。 ユーザーは、複数テナントへのアクセスが必要な場合でも、1 つの資格情報セットを含む 1 つのアカウントを持つ必要があります。 同じユーザーに複数アカウントを作成するのではなく、必要に応じて各テナントへのアクセスを付与します。 同じユーザーに複数アカウントを作成するとセキュリティ リスクが高くなり、同じソフトウェアに対して複数のユーザー名とパスワードを覚える必要があるため、ユーザーが混乱するおそれがあります。
データ所在地を考慮する場合は、ユーザー データを別々の場所内に格納する方法を計画します。 他の地域内のユーザー用に別のデプロイ スタンプをデプロイする場合は、別の ID プロバイダーが必要になる場合もあります。

必要に応じて、ユーザーのデータが格納されている場所を特定し、サインインする適切な地域に誘導できるようにする必要があります。		 ユーザーの場所に適したサインイン エクスペリエンスへとユーザーをルーティングすることで、コンプライアンス要件をサポートし、ユーザー エクスペリエンスを強化できます。

ID プロバイダーの選択

各 ID プロバイダーは、固有の機能、制限事項、価格モデル、実装パターンを提供しています。 Microsoft Entra と Okta は、サービスとしての ID (IDaaS) の一般的なオプションです。 Keycloak や Authentik など、他のオープン ソース プロバイダーも存在します。

設計上の考慮事項

  • ID 要件を文書化する。 まず、アプリケーションに現在必要な、および今後必要になる機能を一覧化します。 考慮すべき一般的な機能は次のとおりです。

    • 顧客の ID ソリューションと統合するための、フェデレーション ID プロバイダーのサポート。 この機能を使用すると、新しい ID の作成を回避できます。
    • 外観を変更してブランド化を維持するための、カスタマイズ可能なサインイン/サインアップ フロー。 この機能は、サインイン/サインアップ プロセスの中にカスタム ビジネス ロジックを挿入する機能も提供します。
    • テナント分離を維持するための、個別のサイロへのテナント データ分離。
    • セキュリティ管理用にサインイン ログを保持またはエクスポートするための、監査のサポート。

    重要

    ID ソリューションのコストを評価する場合は、計画されているユーザーの増加を考慮してください。 ソリューションは、長期的にはコスト効率やスケーラビリティを維持できない可能性がありますが、現時点では役に立つ可能性があります。 必要に応じて、使用できる移行計画を用意します。

    たとえば、あるソリューションは 500 人のユーザーに対しては手頃な価格でも、500 万人に対しては持続不可能な場合があります。 必要なセットアップが最小限で、ユーザー フレンドリかつ簡単に他へ移行できる場合は、(スケーリングのコストによって別のソリューションへの切り替えが正当化されるまで) それが適切な選択肢になる可能性があります。

  • ID プロバイダーの機能を徹底的に調査する。 その ID ソリューションが、必要な機能の一覧と一致することを確認します。 現在はフェデレーション ID などの複雑なシナリオが必要ない場合でも、今後のニーズを考慮してください。 企業間 (B2B) SaaS ソリューションの場合、最終的にはフェデレーション ID が必要になる場合があります。

  • 管理オーバーヘッドを考慮する。 異なる ID プロバイダーには、さまざまなレベルの管理オーバーヘッドが必要になります。 よく知られている IDaaS ソリューションでは、ホスティング、メンテナンス、セキュリティが対応されるため、通常はオーバーヘッドが少なくなります。 ただし、そのソリューションが特殊なニーズにより適している場合は、オープン ソース ソリューションの追加オーバーヘッドにそれだけの価値がある可能性があります。

設計の推奨事項

推奨 特長
独自の ID ソリューションを作成しないでください。 ID は高度に特殊化された領域であり、ID ソリューションを作成することは複雑でコストがかかります。 安全かつ信頼性の高い ID ソリューションを作成することは困難です。 アンチパターン (独自のプロバイダーを作成する) を回避して、ソリューションのセキュリティ、信頼性、運用効率が向上します。
ID プロバイダーによって提供される機能の機能マトリックスを作成し、ID 要件に対してマッピングします。 限られた ID 機能のセットに制約されることなく、発展する能力が確保されます。
オープン ソース ソリューションよりも IDaaS のオプションを優先します。

オープン ソース ソリューションをユーザー自身がホストすると、運用上の大きなオーバーヘッドとセキュリティ リスクを引き起こします。 ただし、あるプロバイダーが満たせないコンプライアンス、データ所在地、または信頼性に関する特定の要件を満たすために、そのオプションを選択する場合があります。 詳細については、IDaaS ID プロバイダーを参照してください。		 IDaaS ID プロバイダーを使用すると、不要な複雑さを回避し、コア ビジネスに労力を集中できます。

フェデレーション ID

フェデレーション ID ("シングル サインオン (SSO)" とも呼ばれます) を使用すると、ユーザーは既に他の場所で使用している資格情報を使用してサインインできます。 フェデレーション ID を有効にするには、アプリケーション ID プロバイダーと顧客の既存 ID プロバイダーとの間に信頼関係を確立します。 フェデレーション ID は、SaaS ソリューションの (特に B2B において) 一般的な要件です。これは、顧客が従業員に企業の資格情報を使用してもらうことを好むためです。 一元化された ID 管理や自動ライフサイクル管理など、いくつかの利点が B2B ソリューションに提供されます。 B2C の SaaS 製品において、ソーシャル ID プロバイダーと統合することは、ユーザーが既存の資格情報でサインインできるようにするために一般的です。

トレードオフ: 複雑さと運用効率。フェデレーション ID プロバイダーと連携することで、ユーザー ID 管理の複雑さが軽減されます。 ただし、別の ID プロバイダーとの統合のコストがかかります。 運用の労力をどこに集中するかを決定します。

最初はフェデレーション ID の実装は簡単ですが、サポート対象の ID プロバイダーの数が増えるにつれてより複雑になります。 特に、各顧客が一意の ID プロバイダーを使用する場合は、慎重な計画が不可欠になります。 同じ ID プロバイダーを使用する場合でも、多くの場合、特定の構成の詳細のために、顧客ごとに一意の信頼関係が必要になります。

次の画像は、アプリケーション、アプリケーション ID プロバイダー、および ID フェデレーションを使用して実装することを選択できるダウンストリームの ID プロバイダー間の関係を示しています。

あるアプリケーションが、(一方では複数の顧客 ID プロバイダーとフェデレーションしている) 1 つの ID プロバイダーを信頼していることを示すダイアグラム。

設計上の考慮事項

  • サポートする必要がある ID プロバイダーの種類と数を見積もる。 固定的な数のソーシャル ID プロバイダーが必要な場合や、顧客ごとに一意のフェデレーション ID プロバイダーが必要な場合があります。 顧客が OpenID Connect (OIDC)、Security Assertion Markup Language (SAML)、またはその両方を統合に使用するかどうかを把握する必要があります。

  • サインイン エクスペリエンスを詳細に計画する。 サインアップおよびサインイン プロセスのユーザー フローを視覚化します。 ユーザー フローの設計を変更する可能性がある特殊な要件に注意してください。 次に例を示します。

    • カスタムのブランド化。 顧客ごとのホワイト ラベルまたはカスタムのサインイン ドメイン。

    • カスタムの情報。 複数テナントにアクセスできるユーザーに対するテナント選択など、サインアップまたはサインイン中の追加のユーザー情報の収集。

    • ID プロバイダーの選択。 多数のフェデレーション ID プロバイダーが信頼している 1 つのアプリケーション ID プロバイダーを使用する場合は、プロバイダーを選択する方法を決定します。 この選択は、ボタンを使用して手動で行うか、既知のユーザー情報に基づいて自動的に行います。 プロバイダーの数が増えるにつれて、自動的な選択がより実用的になります。 この機能は、"ホーム領域検出" と呼ばれています。

設計の推奨事項

推奨 特長
必要なフェデレーション ID プロバイダーの数に合わせてスケーリングできる ID プロバイダーを選択します。

プロバイダーのハード制限に注意してください。その制限を超えることはできません。		 拡張に合わせて、その ID ソリューションをスケーリングできることが保証されます。
各フェデレーション ID プロバイダーのオンボーディングを計画し、可能な限りそのプロセスを自動化します。

組織と顧客の間のこの共同作業には、通常は OIDC または SAML プロトコルを使用し、信頼関係を確立するための情報を交換することが含まれます。		 ID 統合では、自分と顧客の両方に時間と労力がかかる場合があります。 そのプロセスを計画することで、運用効率が向上します。
フェデレーション ID の複雑さとコストを、価格とビジネス モデルの中に反映します。

顧客が独自の ID プロバイダーを使用できるようにすると、複数のフェデレーション ID の信頼関係を維持するオーバーヘッドが発生するため、運用上の複雑さとコストが増加します。 エンタープライズ向けの SaaS ソリューションでは、フェデレーション サインインを可能にする上位レベルに対して支払うのが一般的です。		 顧客の ID プロバイダーとのフェデレーションが、SaaS ソリューションにおける隠れたコストになる場合があります。 計画を立てることで、実装時の予期しないコストを回避します。
サインイン フロー中にユーザーの ID プロバイダーを選択する方法を計画します。 ホーム領域検出の使用を考慮してください。

Microsoft Entra ID には、組み込みのホーム領域検出が用意されています。		 カスタマー エクスペリエンスが効率化され、ユーザーが適切なサインイン プロセスへと誘導されることが保証されます。

承認

ユーザー認可は、多くの場合、複数テナントのデータを格納する SaaS アプリケーションにとって重要です。 誤って他テナントのデータにアクセスすることなく、自分のデータのみにアクセスするようにユーザーを認可する方法を明確に定義します。 さらに、テナント内に詳細な認可を用意し、更新や他のデータへのアクセスを制限しながら、ユーザーが特定の情報を読み取ったりアクセスしたりできるようにします。

設計上の考慮事項

  • ユース ケースに適した認可モデルを選択する。 主に次の 2 種類があります。

    • ロールベースの認可。 ユーザーにはロールまたはグループが割り当てられ、特定の機能は特定のロールに制限されます。 たとえば、管理者はすべてのアクションを実行できますが、他のロールのユーザーはアクセス許可が制限されています。
    • リソースベースの認可。 各リソースには、独自のアクセス許可のセットがあります。 あるユーザーが、あるリソースに対しては管理者であっても、別のリソースに対してはアクセスできない場合があります。

  • 認可データを格納する場所を決定する。 アプリケーションの認可データは、次の中に格納できます。

    • ID プロバイダー。 組み込みのグループまたはロールを活用し、アプリケーションに発行されたトークン内にクレームとしてアクセス許可を示します。 アプリケーションでは、これらのトークン クレームを使用して認可規則を適用できます。
    • アプリケーション。 独自の認可ロジックを開発し、ユーザーのアクセス許可をデータベースまたは同様のシステム内に格納して、きめ細かなロールベースまたはリソース レベルの認可制御を可能にします。

    トレードオフ: 複雑さ、柔軟性、セキュリティ。ID プロバイダー内に認可データを格納し、トークン クレームを使用して示すほうが、通常、独自の認可システムを管理するよりも簡単です。 ただし、クレームベースの認可では柔軟性が制限されるため、クレームはトークンが再発行された場合にのみ更新されることを容認する必要があります。これにより、変更されたアクセス許可の適用が遅れる場合があります。

  • 委任された管理の影響を評価する。 ほとんどの SaaS アプリケーション (特に B2B アプリケーション) において、ロールとアクセス許可の管理は顧客に委任されます。 この機能がなければ、顧客がユーザーのアクセス許可を頻繁に変更する場合、管理オーバーヘッドが増加する可能性があります。

  • マルチテナント アクセスを評価する。 システムによっては、1 人のユーザーが複数テナントのデータにアクセスする必要がある場合があります。 たとえば、コンサルタントが複数テナントのデータにアクセスする必要がある場合があります。 顧客がこれらのユーザーへのアクセスを付与する方法と、サインイン フローでテナント間の選択と切り替えをサポートする方法を計画します。

設計の推奨事項

推奨 特長
アクセスが明示的に許可されていない限り、ユーザーがテナント境界を越えてデータにアクセスできないようにします。 不慮のアクセスだとしても、別テナントのデータへの認可されていないアクセスは重大なセキュリティ インシデントと見なされ、そのプラットフォームに対する顧客の信頼を損なうおそれがあります。 不要なアクセスをブロックすることは、このような状況を回避するのに役立ちます。
データが静的であり、変更頻度が低い場合は、ID プロバイダー内に格納します。 ユーザーがソフトウェアを使用している間に頻繁に変更が必要となる場合は、認可データをアプリケーション内に格納します。 認可データに最適なデータ ストアを選択すると、運用効率が向上し、スケーラビリティのニーズを満たすのに役立ちます。
アクセス許可の管理を顧客に委任する場合は、アクセス許可を管理するための明確な方法を提供します。 たとえば、ユーザーのアクセス許可を変更するために、テナント管理者のみがアクセスできる Web ポータルを作成します。 顧客により多くの制御を提供し、サポート チームの不要な運用上の負担を回避します。

その他のリソース

マルチテナントは、SaaS ワークロードを設計するための中心的なビジネス手法です。 次の記事では、ID およびアクセス管理の詳細が説明されています。

次のステップ

コンピューティング ホスティング モデルの選択、その運用上の側面、サービス レベル アグリーメントおよび目標を満たすために役立つテクノロジ オプションを最適化する方法について学習します。

設計領域: Azure での SaaS ワークロードのコンピューティング