シナリオ - Microsoft Entra ID を使用して SAP プラットフォームとアプリケーションへのアクセスをセキュリティで保護する

このドキュメントでは、MICROSOFT Entra ID を SAP Cloud Identity Services のプライマリ ユーザー認証サービスとして使用する場合の、SAP プラットフォームとアプリケーションの技術的な設計と構成に関するアドバイスを提供します。 SAP Cloud Identity Services には、ID 認証、ID プロビジョニング、ID ディレクトリ、および承認管理が含まれます。 認証の初期セットアップの詳細については、 Microsoft Entra シングル サインオン (SSO) と SAP Cloud Identity Services の統合に関するチュートリアルを参照してください。 プロビジョニングとその他のシナリオの詳細については、 SAP ソースアプリケーションとターゲットアプリケーションを使用したユーザープロビジョニング用の Microsoft Entra のデプロイを計画し 、 SAP アプリケーションへのアクセスを管理する方法を参照してください。

このガイドで使用される用語

概要

SAP および Microsoft テクノロジ スタックには、ユーザー認証と承認のシナリオで役割を果たす多くのサービスとコンポーネントがあります。 主なサービスを次の図に示します。

構成する可能性のあるシナリオは多数存在するため、Microsoft Entra ID ファースト戦略に沿った 1 つのシナリオに焦点を当てます。 次の前提条件を設定します。

• Microsoft Entra ID からのみ、すべての ID を一元的に管理する必要があります。
• メンテナンス作業を可能な限り削減し、Microsoft と SAP 全体の認証とアプリ アクセスを自動化したいと考えています。
• IAS を使用した Microsoft Entra ID の一般的なガイダンスは、BTP にデプロイされたアプリと、IAS で構成された SAP SaaS アプリに適用されます。 また、BTP (Microsoft Entra グループでのロール マッピングの使用など) と SAP SaaS アプリ (ロールベースの承認に ID プロビジョニング サービスを使用するなど) に適用できる場合にも、具体的な推奨事項が提供されます。
• また、Microsoft Entra ID と、ユーザーを機能させるためにプロビジョニングする必要がある SAP システムに対して、ユーザーが既にプロビジョニングされていることを前提としています。 それがどのように達成されたかに関係なく、プロビジョニングは手動で、オンプレミスの Active Directory から Microsoft Entra Connect を通じて、または SAP SuccessFactors などの人事システムを通じて行われた可能性があります。 したがって、このドキュメントでは、SuccessFactors は、(既存の) ユーザーがサインオンする他のアプリケーションと同様のアプリケーションと見なされます。 SuccessFactors から Microsoft Entra ID へのユーザーの実際のプロビジョニングについては説明しません。 SAP ワークロードで使用するためにユーザーを Microsoft Entra ID に取り込む方法の詳細については、 SAP ソース アプリケーションとターゲット アプリケーションを使用したユーザー プロビジョニング用に Microsoft Entra をデプロイする計画を参照し 、 SAP アプリケーションへのアクセスを管理します。

これらの前提に基づいて、主に次の図に示す製品とサービスに重点を置きます。 これらは、クラウドベースの環境での認証と承認に最も関連するさまざまなコンポーネントです。

SAP Identity Management (IDM) を使用している場合は、ID 管理シナリオを SAP IDM から Microsoft Entra に移行できます。 詳細については、「 SAP IDM から Microsoft Entra への ID 管理シナリオの移行」を参照してください。

推奨事項

概要

• 1 - SAP Identity Authentication Service を介して SAP Business Technology Platform および SAP SaaS アプリケーションでフェデレーション認証を使用する
• 2 - 認証に Microsoft Entra ID を使用し、承認に IAS/BTP を使用する
• 3 - IAS/BTP のロール コレクションによる承認に Microsoft Entra グループを使用する
• 4 - 同じ ID 要件を持つアプリケーションに対してのみ、単一の BTP サブアカウントを使用する
• 5 - すべてのエンド ユーザーの認証と承認に運用 IAS テナントを使用する
• 6 - SAML 署名証明書のロールオーバーのプロセスを定義する

1 - SAP Identity Authentication Service を介して SAP Business Technology Platform および SAP SaaS アプリケーションでフェデレーション認証を使用する

Context

BTP のアプリケーションでは、 信頼構成 を通じて ID プロバイダーを使用し、BTP/XSUAA と ID プロバイダーの間で SAML 2.0 プロトコルを使用してユーザーを認証できます。 アプリケーション自体と BTP/XSUAA (このコンテキストでは関係ありません) の間で OpenID Connect プロトコルが使用されている場合でも、SAML 2.0 のみがサポートされることに注意してください。

BTP では、SAP Cloud Identity Services - Identity Authentication (既定) に対して信頼構成を設定することもできますが、権限のあるユーザー ディレクトリが Microsoft Entra ID の場合は、ユーザーが既存の Microsoft Entra アカウントでサインインできるように フェデレーション を設定できます。

フェデレーションの上に、必要に応じて、Microsoft Entra ユーザーが BTP で事前にプロビジョニングされるようにユーザー プロビジョニング を設定することもできます。 ただし、これにはネイティブサポートはありません (Microsoft Entra ID -> SAP Identity Authentication Service のみ)。ネイティブ サポートを備えた統合ソリューションは、BTP Identity Provisioning Service になります。 事前にユーザー アカウントをプロビジョニングすると、承認の目的 (ロールにユーザーを追加するなど) に役立つ場合があります。 ただし、要件によっては、Microsoft Entra グループ (下記参照) を使用してこれを実現することもできます。これは、ユーザー プロビジョニングがまったく必要ない可能性があります。

フェデレーション関係を設定する場合、複数のオプションがあります。

• BTP/XSUAA から Microsoft Entra ID に直接フェデレーションすることを選択できます。
• IAS とのフェデレーションを選択できます。これは、企業 ID プロバイダー ("SAML プロキシ" とも呼ばれます) として Microsoft Entra ID とフェデレーションするように設定されます。

SAP SaaS アプリケーションの場合、IAS はプロビジョニングされ、エンド ユーザーを簡単にオンボードできるように事前構成されています。 (この例には、SuccessFactors、Marketing Cloud、Cloud for Customer、Sales Cloud などがあります)。IAS はターゲット アプリに直接接続され、XSUAA にプロキシされないため、このシナリオは複雑ではありません。 いずれの場合も、IAS を使用する Microsoft Entra ID の場合と同じ規則が、このセットアップに適用されます。

何をお勧めしますか?

権限のあるユーザー ディレクトリが Microsoft Entra ID の場合は、BTP で IAS に対して信頼構成を設定することをお勧めします。 IAS は、企業 ID プロバイダーとして Microsoft Entra ID とフェデレーションするように設定されます。

BTP の信頼構成では、"ログオン中にシャドウ ユーザーを作成する" が有効にすることをお勧めします。 これにより、BTP でまだ作成されていないユーザーは、IAS/ Microsoft Entra ID を使用して初めてサインインしたときに自動的にアカウントを取得します。 この設定を無効にすると、事前プロビジョニングされたユーザーのみがサインインできるようになります。

この推奨事項はなぜですか?

フェデレーションを使用する場合は、BTP サブアカウント レベルで信頼構成を定義できます。 その場合は、使用している他のサブアカウントごとに構成を繰り返す必要があります。 中間信頼構成として IAS を使用すると、複数のサブアカウント間で一元化された構成を利用でき、 リスクベースの認証 やアサーション属性の一元化された エンリッチメントなどの IAS 機能を使用できます。 ユーザー エクスペリエンスを保護するために、これらの高度なセキュリティ機能は 1 つの場所にのみ適用する必要があります。 これは、IAS または Microsoft Entra ID を単一の権限のあるユーザー ストアとして保持する場合 (このホワイト ペーパーの前提と同様)、Microsoft Entra 条件付きアクセスによって一元的に処理されます。

注: IAS では、そのサブアカウント内で 1 つ以上のアプリケーションをデプロイできる場合でも、すべてのサブアカウントは "アプリケーション" と見なされます。 IAS 内では、このようなアプリケーションはすべて、同じ企業 ID プロバイダー (この場合は Microsoft Entra ID) とのフェデレーション用に設定できます。

実装の概要

In Microsoft Entra ID:

• 必要に応じて、シームレス シングル サインオン (シームレス SSO) 用に Microsoft Entra ID を構成 します。これは、ユーザーが企業ネットワークに接続されている企業デバイス上にいるときに自動的にサインインします。 有効にすると、ユーザーは Microsoft Entra ID にサインインするためにパスワードを入力する必要がなく、通常はユーザー名を入力することもできます。

Microsoft Entra ID と IAS の場合:

• ドキュメントに従って、フェデレーション (プロキシ) モード (SAP ドキュメント、 Microsoft ドキュメント) で Microsoft Entra ID を IAS に接続します。 UPN は必ずしも電子メール アドレスではないので、Microsoft Entra ID の SSO 構成の NameID 設定に注意してください。
• [条件付き認証] ページに移動し、"既定の認証 ID プロバイダー" を Microsoft Entra ディレクトリを表す企業 ID プロバイダーに設定して、Microsoft Entra ID を使用するように "バンドルされたアプリケーション" を構成します。

BTP の場合:

• IAS (SAP ドキュメント) に対して信頼構成を設定し、"ユーザー ログオンで使用可能" と "ログオン中にシャドウ ユーザーを作成する" の両方が有効になっていることを確認します。
• 必要に応じて、既定の "SAP ID サービス" 信頼構成で "ユーザー ログオンで使用可能" を無効にして、ユーザーが常に Microsoft Entra ID を使用して認証を行い、ID プロバイダーを選択するための画面が表示されないようにします。

2 - 認証に Microsoft Entra ID を使用し、承認に IAS/BTP を使用する

Context

BTP と IAS が Microsoft Entra ID へのフェデレーションによるユーザー 認証 用に構成されている場合、 承認を構成するための複数のオプションがあります。

• Microsoft Entra ID では、Microsoft Entra ID で SAP IAS インスタンスを表すエンタープライズ アプリケーションに Microsoft Entra ユーザーとグループを割り当てることができます。
• IAS では、リスクベースの認証を使用してサインインを許可またはブロックし、BTP でアプリケーションへのアクセスを禁止することができます。
• BTP では、ロール コレクションを使用して、アプリケーションにアクセスして特定のロールを取得できるユーザーとグループを定義できます。

何をお勧めしますか?

Microsoft Entra 自体には承認を直接配置せず、Microsoft Entra ID のエンタープライズ アプリケーションで "ユーザー割り当てが必要" を明示的に無効にすることをお勧めします。 SAML アプリケーションの場合、この設定は既定で有効になっているため、明示的なアクションを実行して無効にする必要があることに注意してください。

この推奨事項はなぜですか?

アプリケーションが IAS 経由でフェデレーションされている場合、Microsoft Entra ID の観点から、ユーザーは基本的にサインイン フロー中に "IAS に対する認証" を行います。 つまり、Microsoft Entra ID には、ユーザーがサインインしようとしている最終的な BTP アプリケーションに関する情報がありません。 また、Microsoft Entra ID での承認は、非常に粗い承認を行うためにのみ使用できることも意味します。たとえば、ユーザーが BTP 内 の任意 のアプリケーションにサインインしたり、 まったくサインインしたりすることはできません。 これは、BTP サブアカウント レベルでアプリと認証メカニズムを分離する SAP の戦略にも重点を置きます。

これは "ユーザー割り当てが必要" を使用する正当な理由である可能性がありますが、承認情報を維持する必要がある場所が 2 つ存在する可能性があることを意味します。エンタープライズ アプリケーションの Microsoft Entra ID ( すべての BTP アプリケーションに適用される場所) と各 BTP サブアカウントの両方です。 これにより、承認設定が 1 か所で更新されるが、もう一方の場所では更新されないという混乱や構成の誤りにつながる可能性があります。 たとえば、ユーザーは BTP で許可されましたが、Microsoft Entra ID でアプリケーションに割り当てられなかったため、認証が失敗します。

実装の概要

IAS とのフェデレーション関係を表す Microsoft Entra Enterprise アプリケーションで、"ユーザー割り当てが必要" を無効にします。 これは、ユーザーの割り当てを安全にスキップできることを意味します。

3 - IAS/BTP のロール コレクションによる承認に Microsoft Entra グループを使用する

Context

BTP アプリケーションの承認を構成する場合は、複数のオプションがあります。

• サインインしているユーザーに基づいて、アプリケーション自体内できめ細かいアクセス制御を構成できます。
• ユーザーの割り当てまたはグループの割り当てに基づいて、BTP のロールとロール コレクションを使用してアクセスを指定できます。

最終的な実装では、両方の戦略の組み合わせを使用できます。 ただし、ロール コレクションを使用した割り当てについては、ユーザーごとにこれを行うか、構成された ID プロバイダーのグループを使用できます。

何をお勧めしますか?

きめ細かい承認の権限のあるソースとして Microsoft Entra ID を使用する場合は、Microsoft Entra グループを使用し、BTP のロール コレクションに割り当てることをお勧めします。 ユーザーに特定のアプリケーションへのアクセスを許可するということは、IAS/BTP で追加の構成を必要とせずに、ユーザーを関連する Microsoft Entra グループに追加することを意味します。

この構成では、表示名 ("sAMAccountName") ではなく、Microsoft Entra グループのグループ ID (オブジェクト ID) をグループの一意識別子として使用することをお勧めします。 つまり、Microsoft Entra ID によって発行された SAML トークンの "Groups" アサーションとしてグループ ID を使用する必要があります。 さらに、BTP のロール コレクションへの割り当てにもグループ ID が使用されます。

この推奨事項はなぜですか?

BTP のロール コレクションに ユーザー を直接割り当てる場合、Microsoft Entra ID で承認の決定を一元化することはありません。 また、ユーザーが BTP のロール コレクションに割り当てられる前に、ユーザーが IAS に既に存在している必要があることも意味します。つまり、ユーザー プロビジョニングではなくフェデレーションをお勧めします。つまり、ユーザーの割り当てを行う時点で、ユーザーのシャドウ アカウントがまだ IAS に存在しない可能性があります。 Microsoft Entra グループを使用してロール コレクションに割り当てると、これらの問題が解消されます。

ロール コレクションにグループを割り当てると、 承認に Microsoft Entra ID を使用しないという以前の推奨事項と矛盾しているように見える場合があります。 ただし、この場合でも、承認の決定は BTP で引き続き行われています。決定は、Microsoft Entra ID で保持されているグループ メンバーシップに基づいているだけです。

グループ ID はグローバルに一意で不変であり、後で別のグループに再利用することはできないため、名前ではなく Microsoft Entra グループのグループ ID を使用することをお勧めします。一方、グループ名を使用すると、名前が変更されたときに問題が発生する可能性があり、グループが削除され、同じ名前で別のグループが作成され、アプリケーションにアクセスできないユーザーが作成されるというセキュリティ 上のリスクがあります。

実装の概要

In Microsoft Entra ID:

• BTP 内のアプリケーションにアクセスする必要があるユーザーを追加できるグループを作成します (たとえば、BTP の各ロール コレクションに対して Microsoft Entra グループを作成します)。
• IAS とのフェデレーション関係を表す Microsoft Entra Enterprise アプリケーションで、SAML ユーザー属性と要求を構成して、 セキュリティ グループのグループ要求を追加します。

  • Source 属性を "Group ID" に設定し、Name を Groups に設定します (大文字の 'G' とまったく同じスペルです)。

  • さらに、要求ペイロードを小さくし、Microsoft Entra ID が SAML アサーションでグループ要求の数を 150 に制限するという制限に達しないようにするには、要求で返されるグループを、明示的に割り当てられたグループのみに制限することを強くお勧めします。

    • [要求でユーザーに関連付けられているグループを返す必要がありますか?] で、"アプリケーションに割り当てられたグループ" と回答します。 次に、要求として含めるグループに対して、[ユーザーとグループ] セクションを使用して[ユーザーとグループ]、[ユーザー/グループの追加] の順に選択してエンタープライズ アプリケーションに割り当てます。

    

IAS の場合:

• 企業 ID プロバイダーの構成で、[ID フェデレーション] オプションで、[Use Identity Authentication user store]\(ID 認証ユーザー ストアの使用\) を無効にしてください。それ以外の場合、Microsoft Entra ID のグループ情報は BTP に対する SAML トークンに保持されず、承認は失敗します。

BTP の場合:

• そのサブアカウント内のアプリケーションによって使用されるロール コレクションで、IAS ID プロバイダーの構成を追加し、Microsoft Entra グループのグループ ID (オブジェクト ID) に名前を設定することで、 ロール コレクションをユーザー グループにマップします。

4 - 同じ ID 要件を持つアプリケーションに対してのみ、単一の BTP サブアカウントを使用する

Context

BTP 内では、各サブアカウントに複数のアプリケーションを含めることができます。 ただし、IAS の観点からは、"バンドルされたアプリケーション" は完全な BTP サブアカウントであり、その中のより細かいアプリケーションではありません。 つまり、IAS のすべての信頼設定、認証、アクセス構成、およびブランドとレイアウトのオプションは、そのサブアカウント内のすべてのアプリケーションに適用されます。 同様に、BTP のすべての信頼構成とロール コレクションも、そのサブアカウント内のすべてのアプリケーションに適用されます。

何をお勧めしますか?

1 つの BTP サブアカウントに複数のアプリケーションを組み合わせることをお勧めします。これは、ID レベル (ユーザー、グループ、ID プロバイダー、ロール、信頼構成、ブランド化など) に類似した要件がある場合に限られます。

この推奨事項はなぜですか?

非常に異なる ID 要件を持つ複数のアプリケーションを BTP の 1 つのサブアカウントに結合することで、最終的にセキュリティで保護されていない構成や、より簡単に正しく構成できない可能性がある構成になる可能性があります。 たとえば、ID プロバイダーなどの共有リソースに対する構成変更が BTP の 1 つのアプリケーションに対して行われた場合、これは、この共有リソースに依存するすべてのアプリケーションに影響します。

実装の概要

BTP のサブアカウント間で複数のアプリケーションをグループ化する方法を慎重に検討してください。 詳細については、 SAP アカウント モデルのドキュメントを参照してください。

5 - すべてのエンド ユーザーの認証と承認に運用 IAS テナントを使用する

Context

IAS を使用する場合、通常は運用テナントと開発/テスト テナントがあります。 BTP のさまざまなサブアカウントまたはアプリケーションについて、使用する ID プロバイダー (IAS テナント) を選択できます。

何をお勧めしますか?

サインインする 必要があるアプリケーション の開発/テスト バージョンや環境のコンテキストであっても、エンド ユーザーとの対話には常に運用 IAS テナントを使用することをお勧めします。

他の IAS テナントは、運用テナントから分離して実行する必要がある ID 関連の構成のテストにのみ使用することをお勧めします。

この推奨事項はなぜですか?

IAS は Microsoft Entra ID とフェデレーションするように設定された一元化されたコンポーネントであるため、フェデレーションと ID の構成を設定して維持する必要がある場所は 1 つだけです。 他の IAS テナントでこれを複製すると、環境間のエンド ユーザー アクセスの構成ミスや不整合が発生する可能性があります。

6 - SAML 署名証明書のロールオーバーのプロセスを定義する

Context

Microsoft Entra ID と IAS の間、および IAS と BTP の間のフェデレーションを構成すると、SAML メタデータが交換されます。このメタデータには、両方の当事者間で送信される SAML トークンの暗号化と暗号化署名に使用される X.509 証明書が含まれます。 これらの証明書には有効期限があり、定期的に更新する必要があります (たとえば、証明書が侵害された場合でも)。

注: SAML アサーションの署名に使用される最初の Microsoft Entra 証明書の既定の有効期間は 3 年です (また、証明書は、Microsoft Entra ID のグローバル証明書によって署名される OpenID Connect および OAuth 2.0 トークンとは異なり、エンタープライズ アプリケーションに固有であることに注意してください)。 有効期限が異なる新しい証明書を生成するか、独自の証明書を作成してインポートすることができます。

証明書の有効期限が切れると、証明書は使用できなくなり、新しい証明書を構成する必要があります。 そのため、証明書利用者内の証明書構成 (署名を検証する必要があります) を最新の状態に保ち、SAML トークンの署名に使用されている実際の証明書を使用するプロセスを確立する必要があります。

場合によっては、証明書利用者は、最新のメタデータ情報を動的に返すメタデータ エンドポイント (通常は、証明書利用者がメタデータを定期的に取得して内部構成ストアを更新できるパブリックにアクセス可能な URL) を提供することで、これを自動的に行うことができます。

ただし、IAS では、企業 ID プロバイダーをメタデータ XML ファイルのインポートによってのみ設定できます。Microsoft Entra メタデータを動的に取得するためのメタデータ エンドポイントの提供はサポートされていません (たとえば、 https://login.microsoftonline.com/my-azuread-tenant/federationmetadata/2007-06/federationmetadata.xml?appid=my-app-id)。 同様に、BTP では、IAS メタデータ エンドポイント ( https://my-ias-tenant.accounts.ondemand.com/saml2/metadata など) から新しい信頼構成を設定することはできません。また、メタデータ XML ファイルの 1 回限りのアップロードも必要です。

何をお勧めしますか?

任意の 2 つのシステム (Microsoft Entra ID、IAS、IAS、BTP など) 間で ID フェデレーションを設定する場合は、使用されている証明書の有効期限を必ずキャプチャしてください。 これらの証明書を適切に事前に置き換えることができることを確認し、これらの証明書に依存するすべての証明書利用者の新しいメタデータを更新するプロセスが文書化されていることを確認します。

前に説明したように、BTP で IAS に対する信頼構成を設定することをお勧めします。この構成は、企業 ID プロバイダーとして Microsoft Entra ID とフェデレーションするように設定されます。 この場合、次の証明書 (SAML 署名と暗号化に使用されます) が重要です。

• BTP のサブアカウント証明書: この変更時に、IAS のアプリケーションの SAML 2.0 構成を更新する必要があります。
• IAS のテナント証明書: この変更時に、エンタープライズ アプリケーションの Microsoft Entra ID の SAML 2.0 構成と BTP の信頼構成の両方を更新する必要があります。
• Microsoft Entra ID のエンタープライズ アプリケーション証明書: この変更時に、IAS の企業 ID プロバイダーの SAML 2.0 構成を更新する必要があります。

SAP には、SAP Cloud Integration と有効期限に近い処理を使用したクライアント証明書通知の実装例があります。 これは、Azure Integration Services または Power Automate に適応できます。 ただし、サーバー証明書を使用するように調整する必要があります。 このようなアプローチには、カスタム実装が必要です。

この推奨事項はなぜですか?

証明書の有効期限が切れるか、期限内に置き換えられたが、証明書に依存する証明書利用者が新しい証明書情報で更新されない場合、ユーザーはフェデレーションを使用してアプリケーションにサインインできなくなります。 これは、メタデータを再構成してサービスを復元する際に、すべてのユーザーにとって大幅なダウンタイムを意味する可能性があります。

実装の概要

Microsoft Entra ID で証明書の有効期限の電子メール通知アドレスを追加し、グループ メールボックスに設定して、1 人の個人に送信されないようにします (証明書の有効期限が切れるまでにアカウントを持っていない可能性があります)。 既定では、エンタープライズ アプリケーションを作成したユーザーのみが通知を受け取ります。

証明書のロールオーバー プロセス全体を実行するための自動化を構築することを検討してください。 たとえば、証明書の有効期限が切れていないかどうかを定期的に確認し、すべての証明書利用者を新しいメタデータで更新しながら、証明書を置き換えることができます。

次のステップ

• このチュートリアルで初期セットアップの詳細を確認する
• SAP ソースおよびターゲット アプリケーションを使用したユーザー プロビジョニング用の Microsoft Entra のデプロイを計画する
• SAP アプリケーションへのアクセスを管理する
• Microsoft Entra ID 以降を使用した追加の SAP 統合シナリオについて説明します