iOS 用 Intune アプリ SDK - マルチ ID

注:

このガイドは、いくつかの異なる段階に分かれています。まず、「ステージ 1: 統合を計画する」を確認することから始めます。

ステージ 5: マルチ ID (省略可能)

既定では、SDK はアプリ全体にポリシーを適用します。マルチ ID は、ID ごとにポリシーを適用するために有効にできる MAM 機能です。これには、他の MAM 機能よりも多くのアプリの参加が必要です。

アプリは、アクティブな ID を変更する場合は、アプリ SDK に通知する必要があります。また、ID の変更が必要な場合、SDK はアプリに通知します。現在、サポートされているマネージド ID は 1 つだけです。ユーザーがデバイスまたはアプリを登録すると、SDK はこの ID を使用し、プライマリマネージド ID と見なします。アプリ内の他のユーザーは、無制限のポリシー設定を持つ管理されていないものとして扱われます。

ID は単に文字列として定義されることに注意してください。 ID では大文字と小文字が区別されません。 SDK への ID の要求は、ID が設定されたときに最初に使用されたのと同じ大文字と小文字を返さない場合があります。

ステージ目標

アプリケーションにマルチ ID サポートが必要かどうかを判断します。
Intune アプリ SDK が ID をどのように認識するかを理解します。
ID 認識のためにアプリケーションをリファクタリングします。
アプリケーション全体でアクティブな ID と変更する ID を SDK に知らせるコードを追加します。
マネージド ID とアンマネージド ID の両方に対するアプリ保護ポリシーの適用を徹底的にテストします。

ID の概要

ID とは、アカウント ( user@contoso.com など) のユーザー名です。デベロッパーは、アプリの ID を次のレベルで設定できます。

プロセス ID: プロセス全体の ID を設定し、主に単一の ID アプリケーションに使用されます。この ID は、すべてのタスク、ファイル、UI に影響します。
UI ID: メインスレッドの UI タスクに適用されるポリシー (切り取り/コピー/貼り付け、PIN、認証、データ共有など) を決定します。 UI ID は、暗号化やバックアップなどのファイルタスクには影響しません。
スレッド ID: 現在のスレッドに適用されるポリシーに影響します。この ID は、すべてのタスク、ファイル、UI に影響します。

ユーザーが管理されているかどうかに関係なく、アプリでは ID を適切に設定する必要があります。

すべてのスレッドは、常に UI タスクおよびファイルタスクの有効な ID を持ちます。これは、適用する必要があるポリシー (ある場合) をチェックするために使用される ID です。 ID が "ID なし" の場合、またはユーザーが管理されていない場合、ポリシーは適用されません。次の図は、有効な ID がどのように決定されるかを示しています。

スレッドキュー

多くの場合、アプリは非同期タスクと同期タスクをスレッドキューにディスパッチします。 SDK はグランドセントラルディスパッチ (GCD) 呼び出しをインターセプトし、現在のスレッド ID をディスパッチされたタスクに関連付けます。タスクが完了すると、SDK はスレッド ID をタスクに関連付けられた ID に一時的に変更し、タスクを終了してから元のスレッド ID を復元します。

NSOperationQueue は GCD 上に構築されるため、NSOperations は、タスクが NSOperationQueue に追加された時点でスレッドの ID で実行されます。 NSOperations または GCD によって直接ディスパッチされた関数は、実行中の現在のスレッド ID を変更することもできます。この ID は、ディスパッチスレッドから継承された ID をオーバーライドします。

Swift では、SDK が DispatchWorkItem の ID を伝達する方法の結果として、 DispatchWorkItem に関連付けられた ID は、項目をディスパッチしたスレッドではなく、項目を作成したスレッドの ID です。

ファイル所有者

SDK はローカルファイル所有者の ID を追跡し、それに応じてポリシーを適用します。ファイル所有者は、ファイルが作成されたとき、または切り捨てモードでファイルが開かれたときに確立されます。所有者は、タスクを実行しているスレッドの有効なファイルタスク ID に設定されます。

または、アプリで IntuneMAMFilePolicyManager を使用してファイル所有者 ID を明示的に設定することもできます。アプリでは、 IntuneMAMFilePolicyManager を使用してファイルの所有者を取得し、ファイルの内容を表示する前に UI ID を設定できます。

共有データ

アプリが、マネージドユーザーとアンマネージドユーザーの両方のデータを含むファイルを作成する場合、アプリはマネージドユーザーのデータを暗号化する責任を負います。 IntuneMAMDataProtectionManager の protect および unprotect API を使用してデータを暗号化できます。

protect メソッドは、マネージドユーザーまたはアンマネージドユーザーのいずれかの ID を受け入れます。ユーザーが管理されている場合、データは暗号化されます。ユーザーが管理されていない場合、ID をエンコードするデータにヘッダーが追加されますが、データは暗号化されません。 protectionInfo メソッドを使用して、データの所有者を取得できます。

アプリに共有拡張機能がある場合、共有されているアイテムの所有者は、IntuneMAMDataProtectionManager の protectionInfoForItemProvider メソッドを使用して取得できます。共有アイテムがファイルの場合、SDK はファイル所有者の設定を処理します。共有アイテムがデータである場合、アプリは、このデータがファイルに永続化されている場合はファイル所有者を設定し、このデータを UI に表示する前に setUIPolicyAccountId API を呼び出す必要があります。

マルチ ID を有効にする

既定では、アプリは単一の ID と見なされます。 SDK は、登録済みユーザーにプロセス ID を設定します。複数の ID のサポートを有効にするには、名前 MultiIdentity と値 YES を持つブール値設定を、アプリの Info.plist ファイル内の IntuneMAMSettings ディクショナリに追加します。

注:

マルチ ID を有効にすると、プロセス ID、UI ID、スレッド ID は nil に設定されます。アプリでは、それらを適切に設定する必要があります。

ID の切り替え

重要

SDK は、ID の変更を個別に検出することはできません。報告はアプリに完全に依存します。アプリが SDK に ID スイッチを正しく通知しない場合:

アクティブユーザーにアプリ保護ポリシーが適用されず、管理されたデータが保護されないままになる場合があります。
管理されていないデータが誤って制限されている可能性があります。

アプリの起動時、アカウントの切り替え時、別のユーザーのデータの表示など、アクティブなユーザーが変更されるたびに、アプリは適切な ID 切り替え API ( setUIPolicyAccountId など) を呼び出す必要があります。

アプリによって開始された ID スイッチ:

起動時には、マルチ ID アプリは不明な管理対象外のアカウントで実行されていると見なされます。条件付き起動 UI は実行されず、アプリにポリシーは適用されません。アプリは、ID を変更する必要があるたびに SDK に通知する役割を負います。通常、これはアプリが特定のユーザーアカウントのデータを表示するときに発生します。

例としては、ユーザーがノートブックでドキュメント、メールボックス、またはタブを開こうとしたときが挙げられます。アプリは、ファイル、メールボックス、またはタブを実際に開く前に SDK に通知する必要があります。これは、IntuneMAMPolicyManager の setUIPolicyAccountId API を通じて行われます。この API は、ユーザーが管理されているかどうかに関係なく呼び出す必要があります。ユーザーが管理されている場合、SDK は脱獄検出、PIN、認証などの条件付き起動チェックを実行します。

ID 切り替えの結果は、完了ハンドラーを通じてアプリに非同期的に返されます。アプリは、成功結果コードが返されるまで、ドキュメント、メールボックス、またはタブを開くのを延期する必要があります。 ID の切り替えに失敗した場合、アプリはタスクを取り消す必要があります。

マルチ ID アプリでは、ID を設定する方法として setProcessAccountId を使用しないようにする必要があります。 UIScenes を使用するアプリは、 setUIPolicyAccountId:forWindow API を使用して ID を設定する必要があります。

アプリでは、 setCurrentThreadIdentity: と setCurrentThreadIdentity:forScope: を使用して現在のスレッドの ID を設定することもできます。たとえば、アプリでバックグラウンドスレッドを生成し、ID をマネージド ID に設定してから、マネージドファイルに対してファイル操作を実行する場合があります。アプリで setCurrentThreadAccountId: を使用している場合は、完了後に元の ID を復元できるように、アプリも getCurrentThreadAccountId を使用する必要があります。ただし、アプリで setCurrentThreadAccountId:forScope: を使用している場合は、古い ID が自動的に復元されます。 setCurrentThreadAccountId:forScope: を使用することをお勧めします。

swift では、async/await が原因で、 [IntuneMAMPolicyManager setCurrentThreadAccountId:] と [IntuneMAMPolicyManager setCurrentThreadAccountId:forScope:] を使用できません。代わりに、Swiftで現在のIDを設定するには、 IntuneMAMSwiftContextManager.setAccountId(_, forScope:)を使用します。この API には、非同期、スロー、非同期スローのクロージャを渡すバリエーションがあります。
SDK によって開始された ID スイッチ:

場合によっては、SDK はアプリに対して特定の ID に切り替えるように要求する必要があります。マルチ ID アプリでは、この要求を処理するために IntuneMAMPolicyDelegate に identitySwitchRequiredForAccountId メソッドを実装する必要があります。

このメソッドが呼び出されると、アプリが指定された ID に切り替える要求を処理できる場合は、完了ハンドラーに IntuneMAMAddIdentityResultSuccess 渡す必要があります。 ID の切り替えを処理できない場合、アプリは完了ハンドラーに IntuneMAMAddIdentityResultFailed を渡す必要があります。

アプリは、この呼び出しに応答して setUIPolicyAccountId を呼び出す必要はありません。 SDK でアプリをアンマネージドユーザーアカウントに切り替える必要がある場合は、空の文字列が identitySwitchRequiredForAccountId 呼び出しに渡されます。
SDK によって開始された ID の自動登録:

SDK がアクションを実行するためにユーザーをアプリに自動登録する必要がある場合、アプリは IntuneMAMPolicyDelegate で addIdentity:completionHandler: メソッドを実装する必要があります。その後、アプリケーションは完了ハンドラーを呼び出し、アプリが ID を追加できる場合は IntuneMAMAddIdentityResultSuccess を渡す必要があり、それ以外の場合は IntuneMAMAddIdentityResultFailed を渡す必要があります。
選択的ワイプ:

アプリが選択的にワイプされると、SDK は IntuneMAMPolicyDelegate の wipeDataForAccountId メソッドを呼び出します。アプリは、指定されたユーザーのアカウントとそれに関連付けられているすべてのデータを削除する責任があります。 SDK は、ユーザーが所有するすべてのファイルを削除でき、アプリが wipeDataForAccountId 呼び出しから FALSE を返した場合も削除します。

このメソッドはバックグラウンドスレッドから呼び出されることに注意してください。ユーザーのすべてのデータが削除されるまで、アプリは値を返すべきではありません (アプリが FALSE を返した場合、ファイルを除く)。

終了条件

アプリのマルチ ID の統合を検証するためにかなりの時間を費やすことを計画します。テストを開始する前に:

アプリ保護ポリシーを作成してアカウントに割り当てます。これがテスト用マネージドアカウントになります。
別のアカウントを作成しますが、アプリの保護ポリシーを割り当てないでください。これがテスト用のアンマネージドアカウントになります。または、アプリで Microsoft Entra アカウント以外の複数のアカウントの種類がサポートされている場合は、既存の非 AAD アカウントをアンマネージドテストアカウントとして使用できます。
アプリ内でポリシーが適用される方法について理解し直します。マルチ ID テストでは、ポリシーが適用された状態でアプリが動作しているときと動作していないときを簡単に区別できます。スクリーンショットをブロックするアプリの保護ポリシー設定は、ポリシーの適用をすばやくテストするのに効果的です。
アプリで提供される UI のセット全体を検討します。アカウントデータが表示される画面を列挙します。アプリは一度に 1 つのアカウントのデータしか表示しませんか、それとも複数のアカウントに属するデータを同時に表示できますか?
アプリが作成するファイルのセット全体について考えてみましょう。これらのファイルのうち、システムレベルのデータではなく、アカウントに属するデータが含まれているものを列挙します。
- これらの各ファイルで暗号化を検証する方法を決定します。
アプリが他のアプリと対話する方法全体を検討します。すべてのイングレスポイントとエグレスポイントを列挙します。アプリはどのような種類のデータを取り込むことができますか? どのような意図をブロードキャストしますか? 実装されるコンテンツプロバイダーは何ですか?
- これらの各データ共有機能をどのように実行するかを決定します。
- アプリと対話できるマネージドアプリとアンマネージドアプリの両方を含むテストデバイスを準備します。
エンドユーザーがログインしているすべてのアカウントと対話できるようにアプリを使用している方法を検討してください。アカウントのデータが表示される前に、ユーザーがアカウントに手動で切り替える必要がありますか?

アプリの現在の動作を十分に評価したら、次の一連のテストを実行して、マルチ ID 統合を検証します。これは包括的なリストではなく、アプリのマルチ ID の実装にバグがないことを保証するものではないことに注意してください。

マルチ ID アプリは、1 つまでのマネージドアカウントと複数のアンマネージドアカウントをサポートします。これらのテストは、ユーザーのログイン時またはログアウト時にマルチ ID 統合で保護が不適切に変更されないことを確認するのに役立ちます。

これらのテストでは、テストデバイスにアプリをインストールします。テストを開始する前にログインしないでください。

シナリオ	手順
まず管理対象へのログイン	- まず管理対象アカウントでログインし、アカウントのデータが管理されていることを確認します。 - 管理対象外アカウントでログインし、アカウントのデータが管理されていないことを確認します。
まずはアンマネージドにログインする	- まずアンマネージドアカウントでログインし、そのアカウントのデータが管理されていないことを確認します。 - 管理対象アカウントでログインし、アカウントのデータが管理されていることを確認します。
複数のマネージドデータベースにログインする	- まず管理対象アカウントでログインし、アカウントのデータが管理されていることを確認します。 - 2 番目の管理対象アカウントでログインし、最初に元の管理対象アカウントを削除せずにユーザーのログインがブロックされていることを確認します。
管理対象からのログアウト	- 管理対象アカウントとアンマネージドアカウントの両方でアプリにログインします。 - 管理対象アカウントからログアウトします。 - 管理対象アカウントがアプリから削除され、そのアカウントのデータがすべて削除されていることを確認します。 - アンマネージドアカウントがまだログインしていること、アンマネージドアカウントのデータが削除されていないこと、およびポリシーがまだ適用されていないことを確認します。
非管理対象からのログアウト	- 管理対象アカウントとアンマネージドアカウントの両方でアプリにログインします。 - 管理対象外アカウントからログアウトします。 - 管理対象外のアカウントがアプリから削除され、そのアカウントのデータがすべて削除されていることを確認します。 - 管理対象アカウントがまだログインしていること、管理対象外アカウントのデータが削除されていないこと、およびポリシーが引き続き適用されていることを確認します。

アクティブな ID とアプリのライフサイクルの検証

マルチ ID アプリで 1 つのアカウントのデータを含むビューを表示し、ユーザーが現在使用中のアカウントを明示的に変更できるようにすることができます。また、複数のアカウントのデータを含むビューを同時に表示する場合もあります。これらのテストは、アプリのライフサイクル全体を通じて、マルチ ID 統合がすべてのページのアクティブな ID に対して適切に保護されていることを確認するのに役立ちます。

これらのテストでは、テストデバイスにアプリをインストールします。テストを開始する前に、マネージドアカウントとアンマネージドアカウントの両方でログインします。

シナリオ	手順
1 つのアカウントビュー、管理対象	- 管理対象アカウントに切り替えます。 - 1 つのアカウントのデータを表示するアプリ内のすべてのページに移動します。 - すべてのページにポリシーが適用されていることを確認します。
単一のアカウントビュー、アンマネージド	- 管理対象外のアカウントに切り替えます。 - 1 つのアカウントのデータを表示するアプリ内のすべてのページに移動します。 - ポリシーがどのページにも適用されていないことを確認します。
複数アカウントビュー	- 複数のアカウントのデータが同時に表示されるアプリ内のすべてのページに移動します。 - すべてのページにポリシーが適用されていることを確認します。
管理された一時停止	- マネージドデータが表示され、ポリシーがアクティブになっている画面で、デバイスのホーム画面または別のアプリに移動してアプリを一時停止します。 - アプリを再開します。 - ポリシーがまだ適用されていることを確認します。
管理されていない一時停止	- アンマネージドデータが表示され、ポリシーがアクティブになっていない画面で、デバイスのホーム画面または別のアプリに移動してアプリを一時停止します。 - アプリを再開します。 - ポリシーが適用されていないことを確認します。
管理キル	- 管理データが表示され、ポリシーがアクティブな画面で、アプリを強制終了します。 - アプリを再起動します。 - 管理対象アカウントのデータ(想定される)が表示されている画面でアプリが再開しても、ポリシーが引き続き適用されていることを確認します。アンマネージドアカウントのデータがある画面でアプリが再開する場合は、ポリシーが適用されていないことを確認します。
アンマネージドキル	- アンマネージドデータが表示され、ポリシーがアクティブな画面で、アプリを強制終了します。 - アプリを再起動します。 - アンマネージドアカウントのデータ (想定される) が表示されている画面でアプリが再開した場合、ポリシーが適用されないことを確認します。管理対象アカウントのデータを含む画面でアプリが再開する場合は、ポリシーが引き続き適用されていることを確認します。
ID のアドホック切り替え	- アカウント間の切り替えとアプリの一時停止/再開/強制終了/再起動を実験します。 - マネージドアカウントのデータは常に保護され、アンマネージドアカウントのデータは保護されないことを確認します。

マルチ ID アプリは、他のアプリとの間でデータを送受信する場合があります。 Intune のアプリ保護ポリシーには、この動作を指定する設定があります。これらのテストは、マルチ ID 統合でこれらのデータ共有設定が確実に尊重されていることを確認するのに役立ちます。

これらのテストでは、テストデバイスにアプリをインストールします。テストを開始する前に、マネージドアカウントとアンマネージドアカウントの両方でログインします。追加：

マネージドアカウントのポリシーを次のように設定します。
- [組織データを他のアプリに送信する] を [ポリシーで管理されるアプリ] に変更します。
- [他のアプリからデータを受信する] を [ポリシーで管理されるアプリ] に変更します。
テストデバイスに他のアプリをインストールします。
- データを送受信できる、アプリと同じポリシーを対象とするマネージドアプリ (Microsoft Outlook など)。
- データを送受信できるアンマネージドアプリ。
マネージドテストアカウントで他のマネージドアプリにログインします。他のマネージドアプリがマルチ ID の場合でも、マネージドアカウントでのみログインします。

アプリが他のアプリにデータを送信する機能 (Microsoft Outlook がドキュメントの添付ファイルを Microsoft Office に送信するなど) がある場合:

シナリオ	手順
マネージド ID のアンマネージドアプリへの送信	- 管理対象アカウントに切り替えます。 - アプリがデータを送信できる場所に移動します。 - アンマネージドアプリへのデータの送信を試みます。 - アンマネージドアプリへのデータ送信をブロックする必要があります。
マネージドアプリへの送信マネージド ID	- 管理対象アカウントに切り替えます。 - アプリがデータを送信できる場所に移動します。 - 管理対象アカウントがサインインして、他の管理対象アプリにデータを送信することを試みます。 - マネージドアプリへのデータの送信を許可する必要があります。
マネージドアプリへのアンマネージド ID の送信	- 管理対象外のアカウントに切り替えます。 - アプリがデータを送信できる場所に移動します。 - 管理対象アカウントがサインインして、他の管理対象アプリにデータを送信することを試みます。 - 他のマネージドアプリへのデータ送信をブロックする必要があります。
アンマネージド ID アンマネージドアプリへの送信	- 管理対象外のアカウントに切り替えます。 - アプリがデータを送信できる場所に移動します。 - アンマネージドアプリへのデータの送信を試みます。 - アンマネージドアカウントのデータをアンマネージドアプリに送信することを常に許可する必要があります。

アプリは、Microsoft OneDrive のファイルを添付する Microsoft Outlook など、他のアプリからデータをアクティブにインポートする場合があります。アプリは、Microsoft Office が Microsoft Outlook の添付ファイルからドキュメントを開くなど、他のアプリからデータを受動的に受信する場合もあります。受信アプリ保護ポリシー設定は、両方のシナリオを対象としています。

アプリが他のアプリからデータをアクティブにインポートする機能を持っている場合:

シナリオ	手順
アンマネージドアプリからのマネージド ID のインポート	- 管理対象アカウントに切り替えます。 - アプリが他のアプリからデータをインポートできる場所に移動します。 - アンマネージドアプリからデータのインポートを試みます。 - 管理されていないアプリからのデータのインポートはブロックされる必要があります。
マネージドアプリからのマネージド ID のインポート	- 管理対象アカウントに切り替えます。 - アプリが他のアプリからデータをインポートできる場所に移動します。 - サインインした管理対象アカウントを使用して、他の管理対象アプリからデータのインポートを試みます。 - 他のマネージドアプリからデータをインポートできます。
マネージドアプリからのアンマネージド ID のインポート	- 管理対象外のアカウントに切り替えます。 - アプリが他のアプリからデータをインポートできる場所に移動します。 - サインインした管理対象アカウントを使用して、他の管理対象アプリからデータのインポートを試みます。 - 他のマネージドアプリからのデータのインポートはブロックされるべきです。
アンマネージドアプリからのアンマネージド ID のインポート	- 管理対象外のアカウントに切り替えます。 - アプリが他のアプリからデータをインポートできる場所に移動します。 - アンマネージドアプリからデータのインポートを試みます。 - アンマネージドアカウントのアンマネージドアプリからデータをインポートすることは常に許可されている必要があります。

アプリに他のアプリからデータを受動的に受信する機能がある場合:

シナリオ	手順
マネージド ID がアンマネージドアプリから受信する	- 管理対象アカウントに切り替えます。 - アンマネージドアプリに切り替えます。 - データを送信できる場所に移動します。 - アンマネージドアプリからアプリへのデータの送信を試みます。 - アプリのマネージドアカウントがアンマネージドアプリからデータを受信できないようにする必要があります。
マネージドアプリから受信するマネージド ID	- 管理対象アカウントに切り替えます。 - 管理対象アカウントがサインインした状態で、他の管理対象アプリに切り替えます。 - データを送信できる場所に移動します。 - マネージドアプリからアプリへのデータの送信を試みます。 - アプリの管理対象アカウントが、他の管理対象アプリからデータを受信できるようにする必要があります。
マネージドアプリからのアンマネージド ID の受信	- 管理対象外のアカウントに切り替えます。 - 管理対象アカウントがサインインした状態で、他の管理対象アプリに切り替えます。 - データを送信できる場所に移動します。 - マネージドアプリからアプリへのデータの送信を試みます。 - アプリのアンマネージドアカウントは、マネージドアプリからデータを受信できないようにする必要があります。
アンマネージド ID がアンマネージドアプリから受信する	- 管理対象外のアカウントに切り替えます。 - アンマネージドアプリに切り替えます。 - データを送信できる場所に移動します。 - アンマネージドアプリからアプリへのデータの送信を試みます。 - アプリのアンマネージドアカウントは、アンマネージドアプリからのデータの受信を常に許可する必要があります。

これらのテストが失敗した場合、アプリがデータを送受信しようとしたときに、アプリで適切なアクティブ ID が設定されていないことを示している可能性があります。これを調査するには、送受信時に SDK の get identity API を利用して、アクティブな ID が適切に設定されていることを確認します。

次の手順

上記のすべての終了基準を完了したら、アプリはマルチ ID として正常に統合され、ID ごとにアプリ保護ポリシーを適用できます。以降のセクション、ステージ 6: アプリ保護条件付きアクセスのサポートとステージ 7: Web ビュー機能は、アプリの必要なアプリ保護ポリシーのサポートに応じて、必要な場合と不要な場合があります。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-08-19