Identity and Access Management: アーキテクチャと使用

JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

May 12, 2026 · 25 min read

本記事の位置づけ#

参考資料#

1) Identity and Access Management（IAM）の全体像#

SAP BTP のアイデンティティ管理は、4つの異なるコンポーネントからなる階層化スタックであり、各コンポーネントがアイデンティティライフサイクルの明確に定義された部分を担当します（ SAP Cloud Identity Services 管理ガイド）。

これらは代替手段ではありません。IASは認証を行い、IPSはプロビジョニングを実行し、XSUAAは認可を担当し、Identity Directoryは保存と割り当ての一元管理を行います。

2) S/4HANA への接続方法#

推奨されるアーキテクチャでは、IASを企業のIDプロバイダーとすべてのBTPサブアカウント間の中央認証プロキシとして配置します（ UAAとの信頼とフェデレーションを確立）。S/4HANAは、IPSプロビジョニングのターゲットとして、またそれ自体がサービスプロバイダーとして位置づけられます。

[Corporate IdP — Entra ID / ADFS / Okta]
         |
         |  SAML 2.0 or OIDC federation
         v
[IAS Tenant — SAML Proxy / OIDC Broker]
         |                        |
         | SAML/OIDC trust        | SCIM provisioning (IPS)
         v                        v
[BTP Subaccount — XSUAA]    [SAP S/4HANA Cloud / On-premise]
         |                   [Build Work Zone / SuccessFactors]
         | OAuth 2.0
         v
[BTP Applications — Role Collections → JWT tokens]

ユーザーは企業IdPで一度認証を行います。IASがSAMLアサーションを検証し、リスクベースのポリシーを適用した上で、BTPサブアカウントにOIDC IDトークンを発行します。XSUAAはそのトークンを、ロールコレクションのスコープを含むOAuth 2.0 JWTと交換します。並行して、IPSはスケジュールに基づき、企業ディレクトリからIdentity Directoryおよび対象のSAPシステムへユーザーとグループのレコードをレプリケーションします。

S/4HANA Cloud Public Edition の場合、同じIASテナントがSAML IdPとして機能するため、単一のフェデレーションでBTPアプリケーションとS/4HANAログインの両方をカバーします。オンプレミスのS/4HANAでは、IPSが専用コネクタを介してABAPユーザーストアにユーザーレコードをプッシュし、Fiori LaunchpadがBTP上で動作する際には、認証はIASを通じて仲介されます。

重要ポイント: 1つのIASテナントにトラストを集中管理することで、単一のフェデレーション設定がすべてのサブアカウントをカバーします。証明書のローテーションやSSOエンドポイントの変更は、サブアカウントごとではなく、1か所で行う必要があります。

3) 成熟度マップ#

4つのコアコンポーネントはすべて本番環境で使用可能です（ Identity Provisioningとは）。AMSは前提条件が必要な唯一の領域です。

4) 要件チェックリスト#

アイデンティティアーキテクチャの前提条件#

ロールコレクションとグループの設計#

シャドウユーザーとライフサイクル管理#

IPS ソースおよびターゲットシステム設定#

5) 意思決定基準#

最初に問うべき3つの質問#

Q1. 現在、測定可能なアクセス管理の課題はどこにあるのでしょうか？

設定パターンに着手する前に、具体的な運用上の障害を特定してください。「ユーザーが企業の認証情報でログインできない」はIASフェデレーションを示します。「新入社員が入社から数週間経ってもBTPにアクセスできない」はIPS自動化を示します。「開発者がきめ細かい認可を定義できない」はXSUAAまたはAMSを示します。各症状は異なるコンポーネントに対応しており、誤った問題を解決しても複雑性が増すだけで根本的な問題は解決されません（ XSUAAドキュメント）。

Q2. ユーザーレコードとグループ割り当てはどこで管理されますか？

これにより、アーキテクチャが「コーポレートIdP権限」（グループがEntra IDからIAS、BTPへと流れる）か「IAS権限」（ユーザーがIdentity Directoryに直接作成され、IPSがターゲットにプッシュする）かが決まります。ほとんどの企業ではコーポレートIdPがマスターとなりますが、IASのグループクレームパススルー設定は正しく構成する必要があります。同じデプロイメント内で両方のモデルを混在させると、調整の問題が発生します。

Q3. 証明書管理とライフサイクル自動化の予算を持つIAMワークストリームオーナーはいますか？

IAMには継続的な運用投資が必要です。証明書のローテーション（1～3年ごと）、プロビジョニングジョブの監視、シャドウユーザーのクリーンアップ、ロールコレクションのガバナンスが含まれます。要件定義時にオーナーが特定されていない場合、これらのタスクは技術負債として蓄積されます。本番稼働前に運用オーナーを確認してください。

プロジェクトコンテキストによるドメイン選択#

ライセンスとコスト#

6) よくある障害#

障害 1: IAS を使用しないサブアカウントと企業IdPの直接フェデレーション

各BTPサブアカウントは、IASを完全に経由せず、企業IdPとの直接的なSAMLトラストで構成されています。そのため、トラスト設定、証明書ローテーション、MFAポリシーの変更、属性マッピングを、すべてのサブアカウントに対して個別に繰り返し実行する必要があります。サブアカウント数が増加するにつれて、メンテナンスは線形に拡大します。IASを中央プロキシとして挿入することで、IAS内の1つの企業IdPフェデレーションが、すべてのサブアカウントを同時にカバーします。

障害 2: 企業 IdP グループが必要な場合に「Identity Authentication ユーザーストアを使用」が有効のままになっている

IAS が SAML プロキシとして機能する場合、「Use Identity Authentication user store（Identity Authentication ユーザーストアを使用）」設定により、IAS が企業 IdP からの属性を通過させるかどうかが制御されます。この設定が有効（デフォルト）の場合、企業 IdP からのグループクレームは IAS によって破棄され、XSUAA ロールコレクションマッピングに到達しません。ユーザーは認証に成功しますが、ロールコレクションは付与されません。この設定を IAS の企業 IdP 構成で無効にするか、IAS のデフォルト属性で ${corporateIdP.Groups} 構文を使用してパススルーを再宣言してください。

障害 3: Entra ID ロールコレクションマッピングにオブジェクト ID の代わりにグループ表示名が使用されている

Teamsは、Entraグループの表示名をマッピングキーとして使用します。これは人間が読みやすいためです。グループが削除され、同じ表示名で再作成された場合、新しいグループはロールコレクションのマッピングを継承し、意図しないアクセス権が付与される可能性があります。グループ名が変更された場合、マッピングは機能しなくなります。常にEntraグループのオブジェクトIDを「Groups」クレームの値として、またBTP信頼設定のマッピングキーとして使用してください。

障害 4: マルチテナント SaaS サブアカウントで「ログオン時にシャドウユーザーを作成」が有効のままになっている

シングルテナントのエンタープライズデプロイメントでは、自動シャドウユーザー作成は便利な機能です。しかし、マルチテナントSaaSアーキテクチャでは、これは重大なセキュリティ脆弱性となります。IASテナントに存在するユーザーは、初回アクセス時に任意のコンシューマーサブアカウントに認証できるからです。プロバイダーとすべてのコンシューマーサブアカウントの両方で「ログオン時のシャドウユーザー作成」を無効にし、IAS管理API（集中管理されたIASアプリケーション登録からX.509認証を使用）を介してプログラム的にシャドウユーザーをプロビジョニングしてください。

障害 5: ユーザー退社後のシャドウユーザーの古いレコード

企業IdPからユーザーが削除されても、BTP Cloud Foundryサブアカウント内のシャドウユーザーレコードは自動的に削除されません。IPSのプロビジョニング解除はCFシャドウユーザーのクリーンアップには及びません。古いレコードはデータプライバシーと不正アクセスのリスクをもたらします。ユーザー非アクティブ化イベント時にBTP CFユーザー管理APIを呼び出すカスタムクリーンアップ自動化を構築するか、定義されたSLAとともにオンボーディング解除のランブックにシャドウユーザー削除を明示的に含めてください。

障害 6: ロールコレクションの過多によるSAMLアサーションサイズ超過

多くのロールコレクションを持つユーザーは、SAP BTP Cloud Foundryのサイズ制限を超えるSAMLアサーションを生成する可能性があります（SAP Note 2732890 — アクセスにはS-Userログインが必要）。症状としては、多くのロールを持つユーザーで断続的に認証エラーが発生する一方、ロールが少ないユーザーは正常にログインできます。ロールコレクションをより少ない、より広範な機能レベルのコレクションに再設計し、SAMLクレームを介してマッピングされるグループの数を減らしてください。

障害 7: SAML証明書の有効期限追跡プロセスがないこと

企業IdPとIAS間のフェデレーションは、SAML署名証明書に依存しています。Entra IDのエンタープライズアプリケーション証明書は、デフォルトで3年間の有効期限となっています。証明書が期限切れになると、すべてのフェデレーションログインが即座に失敗します。IASはEntra IDからの動的なメタデータ更新をサポートしていないため、証明書の更新のたびに、IASとBTPトラスト設定で手動によるメタデータの再アップロードが必要です。プロジェクト開始時に証明書の有効期限追跡台帳を作成し、各期限切れの90日前にカレンダーアラートを設定し、再アップロード手順を文書化してください。

障害 8: 開発/テスト環境でエンドユーザー認証に非本番用IASテナントを使用する

Teamsは、開発環境とテスト環境用に別のテスト用または非本番用のIASテナントをプロビジョニングし、設定を分離します。その結果、フェデレーション設定が重複し、時間の経過とともに乖離が生じます。つまり、テナント間で企業IdPメタデータ、グループマッピング、リスクベースの認証ポリシーが異なるため、ユーザーは環境間で一貫性のない認証動作を経験します。すべてのエンドユーザー認証（開発およびテストアプリケーション環境を含む）には、本番用IASテナントを使用してください。テスト用IASテナントは、ユーザーに影響を与えてはならない、隔離されたID設定テスト専用に予約してください。

障害 9: 誤った IdP に関連付けられたシャドウユーザー

BTP サブアカウントには、複数の信頼設定を構成できます。プラットフォーム用（BTP Cockpit の管理者アクセスに使用）と、アプリケーション用の1つ以上の信頼設定です。シャドウユーザーは、プラットフォームレベルの信頼ではなく、アプリケーションの信頼で構成された IdP に関連付ける必要があります。シャドウユーザーが誤ってプラットフォーム IdP に関連付けられると、ユーザーは BTP Cockpit にログインできるものの、アプリケーションにアクセスする際に認証エラーが発生する、またはその逆の現象が起こります。アプリケーションの信頼構成で参照されている IdP に対して、シャドウユーザーを明示的に作成し、監査してください。

障害10：単一のBTPサブアカウント内で異なるID要件を持つアプリケーションを混在させること

各BTPサブアカウントには、1つの信頼設定、1組のロールコレクション、およびIAS用の1組のアクセスポリシーがあります。異なるID要件を持つアプリケーション（例：内部従業員と外部パートナー、または異なるMFAポリシーを必要とするアプリケーション）が同じサブアカウントに配置されると、信頼設定やロールコレクションの変更がサブアカウント内のすべてのアプリケーションに同時に影響します。異なるID要件を持つアプリケーションは、アーキテクチャ段階で専用のサブアカウントに分離してください。

FAQ#

Q: IASを使用せず、XSUAAと直接の企業IdPトラストのみでBTP IAMを構成することは可能ですか？

Direct corporate IdPからXSUAAへのSAMLトラストはサポートされていますが、SAPのアーキテクチャガイダンスでは、エンタープライズデプロイメントにおいてこれを強く推奨していません。各サブアカウントには、独自のトラスト設定、証明書のアップロード、属性マッピングが必要です。MFAポリシーや属性エンリッチメントを適用するための一元管理された場所はありません。プロキシとしてのIASは、複数のサブアカウントを持つデプロイメントにおいて正しいアーキテクチャです。

Q: IASのライセンス状況はどうなっていますか — 別途契約が必要ですか？

標準的なケースでは、個別の契約は不要です（ SAP Cloud Identity Services 管理ガイド）。すべてのBTPグローバルアカウントには、追加料金なしで1つの本番用IASテナントと1つのテスト用テナントが含まれています。追加のテナントにはサブスクリプションが必要です。IPSは、標準コネクタ向けにBTPエンタープライズ契約にバンドルされています。どの特定のコネクタが含まれているかは、SAPのアカウントエグゼクティブにご確認ください。

Q: IAMはいつ初期のBTPプロジェクトフェーズから対象外とすべきですか？

IAMは、エンドユーザー向けアプリケーションを含むプロジェクトから除外することはできません。認証と認可は、本番稼働の前提条件だからです。段階的に導入できるのは、その洗練度です。フェーズ1では、手動によるロールコレクション割り当てを伴う基本的なIASフェデレーションを提供し、フェーズ2では、IPSによる自動プロビジョニング、グループベースのロールコレクション割り当て、シャドウユーザーのライフサイクル自動化を追加します。フェーズ1で完全なライフサイクルを提供しようとすると、多くの場合、主要なアプリケーションが不必要に遅延します。

Q: このアーキテクチャはSAP S/4HANAオンプレミスに適用されますか、それともBTPクラウドのみに適用されますか？

両方です。S/4HANA Cloud Public Editionでは、IASがSAML IdPとして機能し、同一テナントがBTPとS/4HANAのログインをカバーします。S/4HANAオンプレミスの場合、IPSはCloud Connectorを介して企業ディレクトリからABAPユーザーストアにユーザーレコードを複製できます。オンプレミスバックエンド向けにBTP上にFiori Launchpadがデプロイされている場合、完全な認証チェーン（企業IdP → IAS → BTP（XSUAA）→ Fiori → S/4HANA）は同一のIASテナントを通じて実行されます。

Q: IAMアーキテクチャ要件をプロジェクトの承認のためにどのように文書化すればよいですか？

IAM要件文書には以下を含める必要があります：(1) IDプロバイダの種類とフェデレーションプロトコル、(2) ユーザマスタリング戦略（企業IdP vs. IAS権限）、(3) グループからロールコレクションへのマッピング設計（クレーム属性名と識別子タイプを含む）、(4) シャドウユーザ作成戦略とその根拠、(5) ユーザプロビジョニング解除プロセス、(6) 証明書有効期限管理台帳（所有者とローテーションSLAを含む）、(7) サブアカウントからアプリケーションへのアイデンティティ境界定義。項目4、5、6は承認文書から最も頻繁に欠落し、事後的に追加するのに最もコストがかかるものです。

Q: IAS と XSUAA の違いは何ですか。また、それぞれがトークンを発行するのはどのような場合ですか。

IAS は OIDC ID トークンを発行します。これはユーザーの身元を確認するもの（認証）です。XSUAA は OAuth 2.0 JWT アクセストークンを発行します。これは特定の BTP Cloud Foundry アプリケーション内でユーザーが何を許可されているかを定義するもの（認可）です。標準フローでは、XSUAA は IAS ID トークンをロールコレクションのスコープを含むアクセストークンと交換します。アプリケーションは IAS トークンではなく XSUAA トークンを受け取ります。IAS ネイティブ認証を使用する CAP アプリケーションでは、IAS トークンを CAP が直接検証でき、その後の認可は XSUAA ではなく AMS を通じて管理されます（ CAP IAS/XSUAA ドキュメント）。

概要#

SAP BTPのID管理は4つのコンポーネントで構成されるスタックです。IASが認証、IPSがプロビジョニング、XSUAAが認可、Identity Directoryが一元化されたグループ割り当てを保存します。推奨されるエンタープライズパターンは3層フェデレーションです。企業IdPがIASに委任し、IASがBTPサブアカウントに委任することで、サブアカウントごとの構成オーバーヘッドをほぼゼロに削減します（ SAP Architecture Center）。最も重要な判断は要件定義時に行われます。ID境界によるサブアカウントの分割、シャドウユーザー作成戦略、表示名ではなくオブジェクトIDを使用したグループクレーム設計、そして証明書の有効期限追跡です。本記事で文書化されている10の一般的な障害はすべて、構成を記述する前に意図的なアーキテクチャ選択を行うことで防止可能です。

次に読むべきもの#