Android 用 Intune App SDK - マルチ ID

  • [アーティクル]

Android 用 Microsoft Intune App SDK を使用すると、Intune アプリ保護ポリシー (APP または MAM ポリシーとも呼ばれます) をネイティブの Java/Kotlin Android アプリに組み込むことができます。 Intune で管理されるアプリケーションは、Intune App SDK と統合されたアプリケーションです。 Intune 管理者は、Intune がアプリをアクティブに管理するときに、Intune で管理されるアプリにアプリ保護ポリシーを簡単に展開できます。

注:

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

ステージ 5: マルチ ID

ステージ Goals

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

ID の用語

"user"、"account"、"identity" という用語は、多くの場合、同じ意味で使用されます。 このガイドでは、次のように区別しようとします。

  • ユーザー: ソフトウェア製品を使用している人間。 さらに、エンド ユーザー、Android アプリを使用する人間、および管理者 / 管理者ユーザー / IT 管理者 / IT Pro、Microsoft Intune管理センターを使用する人間として区別されます。
  • アカウント: ユーザーのエンティティを一意に識別するorganizationに属するソフトウェア レコード。 人間のユーザーは複数のアカウントを持つことができます。
  • ID: Intune App SDK がアカウントを一意に識別するために使用するデータのセット。

背景

既定では、Intune App SDK はアプリケーション全体にポリシーを適用します。 対象となるアプリ保護ポリシーでアカウントを登録した後、SDK は、すべてのファイルとすべてのアクティビティをそのアカウントの ID に関連付け、そのアカウントのターゲット ポリシーをユニバーサルに適用します。

多くの開発者にとって、これはアプリケーションに必要なアプリ保護の動作です。 これらのアプリケーションは 、単一 ID と見なされます。 前のステージを完了すると、アプリケーションは単一 ID として正常に統合され、すべての基本ポリシーを適用できます。 シングル ID を維持することを目的としたアプリは、このセクションをスキップして、ステージ 6: App Configurationに進むことができます。

Intune App SDK では、必要に応じて ID 単位のレベルでポリシーを適用できます。 アプリケーションで同時にログインした複数のアカウントが既にサポートされていて、アプリ保護ポリシーでこのマルチアカウントのサポートを保持する場合、アプリケーションは マルチ ID と見なされます。

ヒント

アプリケーションでシングル ID 保護またはマルチ ID 保護をサポートする必要があるかどうかが不明な場合は、「アプリケーションのシングル ID またはマルチ ID か」を参照してください。

警告

マルチ ID のサポートは、他のアプリ保護機能よりもかなり複雑です。 マルチ ID を不適切に統合すると、データ リークやその他のセキュリティの問題が発生する可能性があります。 このセクションを慎重に確認し、次のステージに進む前に、テストに十分な時間を計画してください。

SDK への "ID"

SDK 統合アプリケーションが registerAccountForMAM を使用してアカウントを登録すると、指定されたすべてのパラメーター (upn、aadId、tenantId、および機関) が ID として保存されます。 ただし、SDK の ID API のほとんどは、指定されたアップ文字列のみを ID の短縮形として使用します。 これらの API は、アップ文字列のみを ID として返し、ID に upn 文字列パラメーターのみを必要とします。

ID では大文字と小文字が区別されません。 ID に対する SDK への要求は、ID の登録または設定時に使用された大文字と小文字の区別を返さない場合があります。

ヒント

将来的には、SDK API は、アカウント登録時に提供されるすべてのフィールドを含む、より包括的な ID 構造を提供する可能性があります。これには、アップアップだけでなく、 マルチ ID サポートを統合する場合は、現在の API を使用して ID を設定するときに、アプリが aadId、tenantId、および機関にもアクセスできることを確認します。

マネージド ID とアンマネージド ID

「App Protection Policy の登録」で説明されているように、アプリケーションはユーザーがログインしたときに SDK に通知する責任を負います。 ログインの時点で、ユーザーのアカウントがアプリ保護ポリシーの対象になる場合と、ターゲットにされていない場合があります。 アカウントがアプリ保護ポリシーを対象としている場合、SDK は管理済みであると見なします。それ以外の場合は管理対象外です。

SDK では、マネージドと見なされる ID に対してポリシーが適用されます。 SDK では、アンマネージドと見なされる ID に対してポリシーは適用されません。

現在、Intune App SDK では、デバイスごとに 1 つのマネージド ID のみがサポートされています。 SDK 統合アプリケーションがマネージド ID を登録するとすぐに、その後登録されたすべての ID が、現在アプリ保護ポリシーを対象としている場合でも、アンマネージドとして扱われます。

マネージド ID がデバイスに既に登録されており、アプリがアプリ保護ポリシーを対象とする別の ID を登録している場合、SDK はを返 MAMEnrollmentManager.Result.WRONG_USER し、修復するオプションをエンド ユーザーに求めます。 詳細については、「 SDK からの通知の登録 」を参照してください。

注:

登録時にアプリ保護ポリシーを対象としていないアカウントは、アンマネージドと見なされます。 アプリ保護ポリシーでアカウントのライセンスが付与されていない、または対象とされていない場合でも、このアカウントが後でライセンスされ、ターゲットになった場合、SDK は定期的にチェックします。 他のマネージド ID が登録されていない場合、SDK はポリシーの対象になると、この ID をマネージドとして扱い始めます。 この変更を行うために、ユーザーはこのアカウントにログアウトして再度ログインする必要はありません。

アクティブ ID

アプリケーションでは、現在使用されている ID (アクティブ ID と呼ばれる) を常に SDK に通知する必要があります。 アクティブ ID が管理されている場合、SDK は保護を適用します。 アクティブ ID が管理されていない場合、SDK は保護を適用しません。

SDK にはアプリケーション固有の知識がないため、正しいアクティブ ID を共有するためにアプリケーションを信頼する必要があります。

  • マネージド ID が実際に使用されているときにアンマネージド ID がアクティブであることがアプリケーションによって SDK に誤って通知された場合、SDK は保護を適用しません。 これにより、ユーザーのデータが危険にさらされるデータ リークが発生する可能性があります。

  • アンマネージド ID が実際に使用されているときにマネージド ID がアクティブであることがアプリケーションによって SDK に誤って通知された場合、SDK は不適切に保護を適用します。 これはデータ リークではありませんが、アンマネージド ユーザーを不必要に制限し、アンマネージド ユーザーのデータを削除のリスクにさらす可能性があります。

アプリケーションでユーザーのデータが表示される場合は、アクティブ ID に属するデータのみを表示する必要があります。 表示されるデータを所有するユーザーがアプリケーションで現在認識されていない場合は、マルチ ID サポートの統合を開始する前に、より多くの ID 認識のためにアプリケーションをリファクタリングする必要がある場合があります。

ID によるアプリ データの整理

アプリケーションが新しいファイルを書き込むたびに、SDK は現在のアクティブなスレッドとプロセス ID に基づいて ID をそのファイルに関連付けます ("タグ" とも呼ばれます)。 または、アプリで SDK を直接呼び出して、特定の ID を持つファイルに手動でタグを付けることができます (詳細については、「 保護されたファイルの書き込み 」を参照してください)。 SDK では、このタグ付きファイル ID を、ファイル暗号化と選択的ワイプの両方に使用します。

マネージド ID が暗号化ポリシーの対象である場合、マネージド ID でタグ付けされたファイルのみが暗号化されます。

管理者アクションまたは構成済みのポリシー要求でマネージド データがワイプされた場合、マネージド ID でタグ付けされたファイルのみが削除されます。

SDK では、複数の ID を 1 つのファイルに関連付けることはできません。 アプリが複数のユーザーに属するデータを同じファイルに格納する場合、SDK の既定の動作により、このデータの保護が不足または過剰に保護されます。 アプリのデータを ID で整理することを強くお勧めします。

アプリが異なる ID に属するデータを同じファイルに絶対に格納する必要がある場合、SDK は、ファイル内のデータのサブセットを ID タグ付けするための機能を提供します。 詳細については、「 データ バッファー保護 」を参照してください。

マルチ ID の実装

アプリのマルチ ID サポートを宣言するには、まず次のメタデータを AndroidManifest.xml に配置します。

  <meta-data
    android:name="com.microsoft.intune.mam.MAMMultiIdentity"
    android:value="true" />

アクティブ ID の設定

アプリケーションは、次のレベルのアクティブ ID を降順の優先順位で設定できます。

  1. スレッド レベル
  2. Context (一般に Activity)レベル
  3. プロセス レベル

スレッド レベルで設定された ID は、プロセス レベルの Context ID セットを置き換えるレベルの ID セットよりも優先されます。

に Context 設定された ID は、適切な関連シナリオでのみ使用されます。 たとえば、ファイル IO 操作に が関連付けられていない Context場合などです。 最も一般的に、アプリは に Context ID を Activity設定します。 で Activity.onCreateID をContext設定することを検討してください。 ID が同じ ID に設定されていない限りActivity、アプリは ID のデータを表示しないでください。

一般に、プロセス レベルの ID は、アプリがすべてのスレッドで一度に 1 つの ID でのみ動作する場合にのみ役立ちます。 これは、複数のアカウントをサポートするアプリの一般的な動作ではありません。 アカウント データを分離し、スレッドまたは Context レベルでアクティブ ID を設定することを強くお勧めします。

アプリでコンテキストを Application 使用してシステム サービスを取得する場合は、スレッドまたはプロセス ID が設定されていること、またはアプリの Application コンテキストで UI ID を設定していることを確認します。

アプリでコンテキストを使用して意図を Service 起動する場合、コンテンツ リゾルバーを使用する場合、または他のシステム サービスを利用する場合は、コンテキストで Service ID を必ず設定してください。 同様に、アプリでコンテキストをJobService使用してこれらのアクションを実行する場合は、実装で必要JobServiceに応じてコンテキストまたはスレッドで JobService ID を設定してください。 たとえば、1 つの ID のジョブを JobService 処理する場合は、コンテキストで JobService ID を設定することを検討してください。 複数の ID のジョブを JobService 処理する場合は、スレッド レベルで ID を設定することを検討してください。

注意

使用 WorkManager するアプリは、ID を設定するときに特別な注意を払う必要があります。 具体的には、これらのアプリは、コンストラクターで渡された に ID を Context 設定しないようにする Worker 必要があります。 この Context インスタンスは、複数 Worker のインスタンス間で同時に共有できます。 未定義の動作を回避するには、実装で必要に応じて、アプリで代わりに スレッド ID を に Worker.doWork() 設定する Worker 必要があります。

注:

CLIPBOARD_SERVICEは UI 操作に使用されるため、SDK では操作にフォアグラウンド アクティビティClipboardManagerの UI ID が使用されます。

MAMPolicyManager の次のメソッドを使用して、アクティブ ID を設定し、前に設定した ID 値を取得できます。

public static void setUIPolicyIdentity(final Context context, final String identity, final MAMSetUIIdentityCallback mamSetUIIdentityCallback,
final EnumSet<IdentitySwitchOption> options);

public static String getUIPolicyIdentity(final Context context);

public static MAMIdentitySwitchResult setProcessIdentity(final String identity);

public static String getProcessIdentity();

public static MAMIdentitySwitchResult setCurrentThreadIdentity(final String identity);

public static String getCurrentThreadIdentity();

/**
 * Get the current app policy. This does NOT take the UI (Context) identity into account.
 * If the current operation has any context (e.g. an Activity) associated with it, use the overload below.
 */
public static AppPolicy getCurrentThreadPolicy();

/**
 * Get the current app policy. This DOES take the UI (Context) identity into account.
 * If the current operation has any context (e.g. an Activity) associated with it, use this function.
 */
public static AppPolicy getPolicy(final Context context);


public static AppPolicy getPolicyForIdentity(final String identity);

public static boolean getIsIdentityManaged(final String identity);

便宜上、 を呼び出MAMPolicyManager.setUIPolicyIdentityす代わりに、MAMActivity のメソッドを介してアクティビティの ID を直接設定することもできます。 これを行うには、次のメソッドを使用します。

     public final void switchMAMIdentity(final String newIdentity, final EnumSet<IdentitySwitchOption> options);

注:

アプリがマニフェストでマルチ ID サポートを宣言していない場合、これらのメソッドを呼び出して ID を設定してもアクションは実行されず、 が返 MAMIdentitySwitchResultされる場合は、 は常に を返します FAILED。

一般的な ID スイッチの落とし穴

  • への startActivity呼び出しの場合、Intune App SDK は、レベルの Context アクティブ ID が指定された Intent パラメーターに関連付けられていると想定します。 "コンテキスト" ではなくApplication、 のコンテキストを使用してActivityレベル ID を設定Contextすることを強くお勧めします。

  • アクティビティonCreateのContextメソッド中に ID を設定することをお勧めします。 ただし、 などの onNewIntent他のエントリ ポイントについても必ず説明してください。 そうしないと、マネージド ID とアンマネージド ID の両方のデータを表示するために同じアクティビティが再利用されると、ポリシーが誤って適用され、保護されていない企業データまたは不適切に制限された個人データが発生する可能性があります。

ID スイッチの結果

ID を設定するために使用されるすべてのメソッドは、 MAMIdentitySwitchResult を使用して結果値をレポートします。 返すことができる値は 4 つあります。

戻り値 シナリオ
SUCCEEDED ID の変更が成功しました。
NOT_ALLOWED ID の変更は許可されません。 これは、現在のスレッドで別の ID が設定されているときに UI (Context) ID を設定しようとした場合に発生します。
CANCELLED ユーザーは、通常、PIN または認証プロンプトの戻るボタンを押すことによって、ID の変更を取り消しました。
FAILED ID の変更が不特定の理由で失敗しました。

アプリは、管理対象アカウントのデータを表示または使用する前に 、MAMIdentitySwitchResult が SUCCEEDED であることを確認する必要があります。

アクティブ ID を設定するためのほとんどのメソッドは、 MAMIdentitySwitchResult を 同期的に返します。 setUIPolicyIdentity を使用して ID を設定Contextする場合、結果は非同期的に報告されます。 アプリは、この結果を受け取るために MAMSetUIIdentityCallback を実装するか、コールバック オブジェクトに null を渡すことができます。 同じコンテキストでの以前の 呼び出しの結果がまだ配信されていない間に にsetUIPolicyIdentity呼び出しが行われたsetUIPolicyIdentity場合、新しいコールバックは古いコールバックに取って代わり、元のコールバックは結果を受け取りません。

注意

ContextsetUIPolicyIdentity に指定された が であるActivity場合、SDK は、管理者が構成した条件付き起動チェックを実行するまで、ID の変更が成功したかどうかを認識しません。 これにより、ユーザーが PIN または企業の資格情報を入力する必要がある場合があります。

現在、プロセス ID とスレッド ID スイッチは、マルチ ID 対応アプリでは常に成功します。 SDK は、将来エラー状態を追加する権利を留保します。

UI ID スイッチは、無効な引数に対して失敗する可能性があります。スレッド ID と競合する場合、またはユーザーが条件付き起動の要件を取り消した場合 (たとえば、PIN 画面の戻るボタンを押します)。

アクティビティの失敗した UI ID スイッチの既定の動作は、アクティビティを完了することです。 この動作を変更し、アクティビティの ID 変更試行に関する通知を受信するには、 で MAMActivityメソッドをオーバーライドできます。

    public void onSwitchMAMIdentityComplete(final MAMIdentitySwitchResult result);

オーバーライド onSwitchMAMIdentityComplete (または メソッドの super 呼び出し) を行う場合は、失敗した ID スイッチの後にマネージド アカウントのデータが表示されないようにする 必要があります 。

注:

ID を切り替える場合は、アクティビティを再作成する必要があります。 この場合、 onSwitchMAMIdentityComplete コールバックはアクティビティの新しいインスタンスに配信されます。

Identity、Intents、IdentitySwitchOptions

SDK では、アクティブ ID を使用して新しいファイルに自動的にタグを付けるだけでなく、アクティブな ID を使用して 意図 にタグを付けます。 既定では、SDK は受信意図で ID をチェックし、アクティブな ID と比較します。 これらの ID が一致しない場合、SDK は通常(*) によって ID スイッチを要求します (詳細については、以下の 「暗黙的な ID の変更 」を参照してください)。

SDK には、後で使用するために、この受信意図 ID も格納されます。 アプリが UI ID を明示的に変更すると、SDK は、アプリが切り替えようとしている ID を、最新の着信意図 ID と比較します。 これらの ID が一致しない場合、SDK は通常(*) ID スイッチに失敗します。

SDK は、アプリが意図にタグ付けされた ID に属する意図のコンテンツを表示していることを前提とするため、このチェックを実行します。 この前提は、マネージド データを表示するときにアプリが意図せずに保護をオフにすることを防ぎます。ただし、この前提はアプリの実際の動作に正しくない可能性があります。

オプションの IdentitySwitchOption 列挙型を setUIPolicyIdentity API と switchMAMIdentity API に渡して、SDK の既定の動作を変更できます。

  • IGNORE_INTENT: UI レイヤーで ID スイッチを要求する場合、このオプションは、要求された ID パラメーターと最近格納された意図 ID の比較をスキップするように SDK に通知します。 これは、アプリがその ID に属するコンテンツを表示しなくなり、SDK がこの ID スイッチをブロックしないようにする場合に便利です。 例:

    1. アプリはドキュメント ビューアーです。 他のアプリから渡されたドキュメントをレンダリングできます。 また、ユーザーがアカウントを切り替えることができる機能も含まれています。 ユーザーがこのアカウント切り替え機能を使用するたびに、アプリはそのアカウントの最近のドキュメントを含むアカウント固有のランディング ページに移動します。
    2. アプリは、ドキュメントを表示する意図を受け取ります。 この意図にはマネージド ID でタグが付けられます。
    3. アプリがマネージド ID に切り替わり、保護が適切に適用された状態でこのドキュメントが表示されます。
    4. ユーザーはアカウント スイッチャーを使用して、個人用アカウントに変更します。

    アプリでは、手順 4 で UI ID を変更する必要があります。 この場合、アプリの動作はマネージド アカウントのデータ (意図内のドキュメント) から移動するため、ID スイッチ呼び出しで使用 IGNORE_INTENT する必要があります。 これにより、SDK がこの呼び出しを不適切に失敗しないようにします。

  • DATA_FROM_INTENT: UI レイヤーで ID スイッチを要求する場合、このオプションは、ID スイッチが成功した後も、最後に格納された意図 ID のデータが引き続き表示されることを SDK に通知します。 その結果、SDK は前の意図 ID に対して受信ポリシーを完全に評価し、表示が許可されているかどうかを判断します。 例:

    1. アプリはドキュメント ビューアーです。 他のアプリから渡されたドキュメントをレンダリングできます。 また、ユーザーがアカウントを切り替えることができる機能も含まれています。 前の例とは異なり、ユーザーがこのアカウント切り替え機能を使用するたびに、アプリ はすべてのアカウントの最近のドキュメントを表示する共有ページに移動します。
    2. アプリは、ドキュメントを表示する意図を受け取ります。 この意図にはマネージド ID でタグが付けられます。
    3. アプリがマネージド ID に切り替わり、保護が適切に適用された状態でこのドキュメントが表示されます。
    4. ユーザーはアカウント スイッチャーを使用して、個人用アカウントに変更します。

    アプリでは、手順 4 で UI ID を変更する必要があります。 この場合、アプリの動作はマネージド ID のデータ (意図内のドキュメントのプレビュー) を引き続き表示するため、ID スイッチ呼び出しで使用 DATA_FROM_INTENT する必要があります。 これにより、データが引き続き表示されるのに適しているかどうかを判断するために、構成されたアプリ保護ポリシーをチェックするように SDK に通知されます。

(*)SDK の既定の動作には、このデータイングレスチェックをスキップする特別な大文字と小文字が含まれています。たとえば、意図が同じアプリ内またはシステム起動ツールから取得された場合などです。

アクティブ ID のクリア

アプリケーションには、アカウントに依存しないシナリオがある場合があります。 また、アプリケーションには、ログインを必要としないローカルアンマネージド シナリオのシナリオもあります。 どちらの場合も、アプリは SDK でマネージド ID のポリシーを適用することを望まない場合がありますが、切り替える明示的な ID がない可能性があります。

ID パラメーターが に null設定されている任意の設定 ID メソッドを呼び出すことで、アクティブ ID をクリアできます。 ID を 1 つのレベルでクリアすると、SDK は優先順位に基づいて、他のレベルでアクティブな ID を検索します。

または、ID パラメーターとして空の文字列を渡すことができます。これにより、ID がアンマネージド ID として扱われる特殊な空の値に設定されます。 アクティブ ID を空の文字列に設定すると 、SDK は アプリ保護ポリシーを適用しないように指示します。

暗黙的な ID の変更

上記のセクションでは、アプリがスレッド、コンテキスト、およびプロセス レベルでアクティブ ID を明示的に設定できるさまざまな方法について説明します。 ただし、アプリ内のアクティブな ID は、アプリがこれらのメソッドを呼び出さずに変更される場合もあります。 このセクションでは、アプリがこれらの暗黙的な ID 変更をリッスンして応答する方法について説明します。

これらの暗黙的な ID の変更をリッスンすることは省略可能ですが、推奨されます。 SDK は、これらの暗黙的な ID 変更通知を提供せずに、アクティブ ID を変更することはありません。

注意

アプリが暗黙的な ID の変更をリッスンしないことを選択した場合は、アクティブな ID を想定しないように注意してください。 不明な場合は、 メソッド、、および getProcessIdentity メソッドをgetCurrentThreadIdentitygetUIPolicyIdentity使用して、アクティブな ID を確認します。

暗黙的な ID 変更のソース

  • 他の Intune で管理されるアプリからのデータイングレスによって、スレッドとコンテキスト レベルのアクティブ ID が変更される可能性があります。

    • 別の MAM アプリによって送信されたから Intent アクティビティが起動された場合、アクティビティの ID は、 が送信された時点 Intent の他のアプリのアクティブ ID に基づいて設定されます。

      • たとえば、ユーザーがドキュメントの添付ファイルを選択すると、Microsoft Outlook の意図からWordドキュメントを表示するアクティビティが起動されます。 Office のドキュメント ビューアー アクティビティの ID は、Outlook から ID に切り替えられます。

    • サービスの場合、スレッド ID は、 または onBind 呼び出しのonStart間も同様に設定されます。 からonBind返された をBinder呼び出すと、スレッド ID も一時的に設定されます。

    • への ContentProvider 呼び出しも同様に、その期間のスレッド ID を設定します。

  • ユーザー がアクティビティと対話すると、コンテキスト レベルのアクティブ ID が変更される可能性があります。 例:

    • の間 Resume に承認プロンプトから取り消したユーザーは、空の ID に暗黙的に切り替わります。

暗黙的な ID 変更の処理

アプリは必要に応じて、これらの暗黙的な ID の変更をリッスンし、それに対応できます。 たとえば、新しい受信トレイを設定するメール アプリなど、追加されたアカウントを使用できるようになる前に、アプリケーションで複数の手順が必要になる場合があります。 未完了のアカウントの ID に切り替えようとした場合、アプリのハンドラーは、ID スイッチを受け入れる前に、ユーザーをアカウントセットアップ アクティビティにリダイレクトできます。 または、アプリのハンドラーでエラー ダイアログを表示し、ID スイッチをブロックすることもできます。

アプリは、 または ContextProvider に MAMIdentityRequirementListener インターフェイスを実装して、このスレッドにService適用される ID の変更を行うことができます。 実装は、次をオーバーライドする必要があります。

public abstract void onMAMIdentitySwitchRequired(String identity,
        AppIdentitySwitchResultCallback callback);

アプリは、このアクティビティに適用される ID の変更に対して MAMActivityIdentityRequirementListener インターフェイス Activity を実装できます。 実装は、次をオーバーライドする必要があります。

public abstract void onMAMIdentitySwitchRequired(String identity,
        AppIdentitySwitchReason reason,
        AppIdentitySwitchResultCallback callback);

enum パラメーターは AppIdentitySwitchReason 、暗黙的な ID スイッチのソースを表します。

列挙値 既定の SDK 動作 説明
CREATE ID スイッチを許可します。 アクティビティの作成により、ID スイッチが発生しています。
NEW_INTENT ID スイッチを許可します。 新しい意図がアクティビティに割り当てられているため、ID スイッチが発生しています。
RESUME_CANCELLED ID スイッチをブロックします。 再開が取り消されたため、ID スイッチが発生しています。 これは、エンド ユーザーが PIN、認証、またはコンプライアンス UI の戻るボタンを押す場合に最も一般的です。

AppIdentitySwitchResultCallback パラメーターを使用すると、開発者は ID スイッチの既定の動作をオーバーライドできます。

public interface AppIdentitySwitchResultCallback {
  /**
    * @param result
    *            whether the identity switch can proceed.
    */
  void reportIdentitySwitchResult(AppIdentitySwitchResult result);
}
// Where [AppIdentitySwitchResult] is either `SUCCESS` or `FAILURE`.

onMAMIdentitySwitchRequired は、から MAMService.onMAMBind返される Binder を介して行われた変更を除き、すべての暗黙的な ID 変更に対して呼び出されます。 即時呼び出しの既定の onMAMIdentitySwitchRequired 実装:

  • callback.reportIdentitySwitchResult(FAILURE)理由が である場合。RESUME_CANCELLED

  • callback.reportIdentitySwitchResult(SUCCESS) 他のすべての場合。

ほとんどのアプリでは、別の方法で ID スイッチをブロックまたは遅延させる必要は想定されていませんが、アプリでこれを行う必要がある場合は、次の点を考慮する必要があります。

  • ID スイッチがブロックされている場合、エンド ユーザーの動作は、SDK の "他のアプリからデータを受信する" アプリ保護設定でデータイングレスが禁止されていた場合と同じです。

  • サービスがメイン スレッドで実行されている場合は、reportIdentitySwitchResult同期的に呼び出すか、UI スレッドが応答を停止する必要があります。

  • 作成の場合 Activity 、 onMAMIdentitySwitchRequired は の前に onMAMCreate呼び出されます。 ID スイッチを許可するかどうかを判断するためにアプリで UI を表示する必要がある場合は、 別 のアクティビティを使用してその UI を表示する必要があります。

  • では、 Activityという理由 RESUME_CANCELLEDで空の ID への切り替えが要求された場合、アプリは再開されたアクティビティを変更して、その ID スイッチと一致するデータを表示する必要があります。 これが不可能な場合、アプリは切り替えを拒否する必要があり、ユーザーは再開 ID のポリシーに従うように再度求められます (たとえば、アプリの PIN 入力画面が表示されます)。

注意

マルチ ID アプリは、マネージド アプリとアンマネージド アプリの両方から受信データを受信できます。 マネージド ID からのデータを管理された方法で処理するのはアプリの責任です。

要求された ID が管理されている場合 (MAMPolicyManager.getIsIdentityManaged を使用してチェック)、アプリではそのアカウントを使用できません (たとえば、メール アカウントなどのアカウントをアプリで最初に設定する必要があるため)、ID スイッチを拒否する必要があります。

の既定の MAMActivity.onMAMIdentitySwitchRequired 動作には、静的メソッド MAMActivity.defaultOnMAMIdentitySwitchRequired(activity, identity, reason, callback)を呼び出すことによってアクセスできます。

同様に、 をオーバーライドMAMActivity.onSwitchMAMIdentityCompleteする必要がある場合は、 からMAMActivity明示的に継承せずに を実装MAMActivityIdentitySwitchListenerできます。

ID スイッチとスクリーンショットの制限

Intune App SDK では、 フラグFLAG_SECUREをWindow使用してスクリーンショット ポリシーを適用します。 一部のアプリは、独自の目的で設定 FLAG_SECURE することもできます。 アプリ保護ポリシーでスクリーンショットが制限されない場合、SDK は を変更 FLAG_SECUREしません。

ポリシーでスクリーンショットを無効にする必要がある ID からポリシーが無効になっていない ID に ID 切り替えると、SDK は をクリア FLAG_SECUREします。 その結果、アプリは ID スイッチの後に残りのセットに FLAG_SECURE 依存しないようにする必要があります。

非同期操作での ID の保持

アプリは、多くの場合、UI スレッドからバックグラウンド タスクをディスパッチして、他のスレッドの操作を処理します。 マルチ ID アプリでは、これらのバックグラウンド タスクが適切な ID で動作することを確認する必要があります。これは、多くの場合、ディスパッチされたアクティビティで使用される ID と同じです。

Intune App SDK は、非同期操作での ID の保持に役立つ便利な機能として 、MAMAsyncTask と MAMIdentityExecutors を提供します。 非同期操作が可能な場合は、アプリでこれらを使用する (またはタスクでスレッド ID を明示的に設定する) 必要があります。

  • マネージド ID に属するデータをファイルに書き込む
  • 他のアプリと通信する

MAMAsyncTask

を使用MAMAsyncTaskするには、 の代わりに AsyncTask それを継承し、 のオーバーライドdoInBackgroundMAMdoInBackgroundonPreExecuteをそれぞれ と onPreExecuteMAM に置き換えます。 コンストラクターは MAMAsyncTask アクティビティ コンテキストを受け取ります。 例:

AsyncTask<Object, Object, Object> task = new MAMAsyncTask<Object, Object, Object>(thisActivity) {

    @Override
    protected Object doInBackgroundMAM(final Object[] params) {
        // Do operations.
    }

    @Override
    protected void onPreExecuteMAM() {
        // Do setup.
    };
}

MAMAsyncTask は、通常の優先順位に基づいてアクティブ ID を想定します。

MAMIdentityExecutors

MAMIdentityExecutorsでは、 メソッドと メソッドを使用して、既存ExecutorのインスタンスまたはExecutorServiceインスタンスを ExecutorwrapExecutor/ExecutorServicewrapExecutorService ID 保持としてラップできます。 たとえば、

Executor wrappedExecutor = MAMIdentityExecutors.wrapExecutor(originalExecutor, activity);
ExecutorService wrappedService = MAMIdentityExecutors.wrapExecutorService(originalExecutorService, activity);

MAMIdentityExecutors は、通常の優先順位に基づいてアクティブ ID を想定します。

ファイル保護

保護されたファイルの書き込み

前述の「 Id によるアプリ データの整理 」で説明したように、Intune App SDK は、アクティブな ID (スレッド/プロセス レベル) を、書き込み時にファイルに関連付けます。 適切な暗号化と選択的ワイプ機能を確保するには、ファイル作成時に正しい ID を設定することが重要です。

アプリでは、 MAMFileProtectionManager クラス (特に MAMFileProtectionManager.getProtectionInfo クエリと変更用) を使用して、ファイルの ID を照会または MAMFileProtectionManager.protect 変更できます。

メソッドを protect 使用してディレクトリを保護することもできます。 ディレクトリ保護は、ディレクトリに含まれるすべてのファイルとサブディレクトリに再帰的に適用されます。 ディレクトリが保護されると、ディレクトリ内に作成されたすべての新しいファイルに自動的に同じ保護が適用されます。 ディレクトリ保護は再帰的に適用されるため、大規模なディレクトリの protect 呼び出しが完了するまでに時間がかかる場合があります。 そのため、多数のファイルを含むディレクトリに保護を適用するアプリは、バックグラウンド スレッドで非同期的に実行 protect したい場合があります。

ID パラメーターに空の文字列を指定してを呼び出 protect すと、ファイル/ディレクトリにアンマネージド ID のタグが付けられます。 この操作では、以前に暗号化されていた場合、ファイル/ディレクトリから暗号化が削除されます。 選択的ワイプ コマンドが発行されると、ファイル/ディレクトリは削除されません。

保護されたファイル コンテンツの表示

未承認のユーザーがマネージド データを表示できないように、ファイル コンテンツを 表示 するときに正しい ID を設定することが同様に重要です。 SDK は、読み取られるファイルと に表示されるデータの間の関係を Activity自動的に推論することはできません。 アプリは、マネージド データを表示する前に UI ID を適切に設定する 必要があります 。 これには、ファイルから読み取られたデータが含まれます。

ファイルがアプリの外部 (パブリックに書き込み可能な場所からContentProviderまたはパブリックに書き込み可能な場所から読み取られる) から取得された場合、アプリは、ファイルから読み取られた情報を表示する前に、ファイル ID (データ ソースの正しい MAMFileProtectionManager.getProtectionInfo オーバーロードを使用) を確認する必要があります。

null 以外の空でない ID を報告する場合getProtectionInfo、アプリは、MAMActivity.switchMAMIdentity または MAMPolicyManager.setUIPolicyIdentity を使用して、この ID と一致するように UI ID を設定する必要があります。 ID スイッチが失敗した場合は、ファイルのデータを表示 しないでください 。

コンテンツ URI から読み取るときに、最初に ID を読み取り (オーバーロードを使用UriしてgetProtectionInfo)、コンテキストまたはスレッド ID を適切に設定する必要がある場合があります。 これは、 でファイル記述子または入力ストリームを開く前に ContentResolver行う必要があります。それ以外の場合は操作が失敗する可能性があります。

フローの例を次に示します。

  • ユーザーは、アプリで開くドキュメントを選択します。

  • オープン フローでは、ディスクからデータを読み取る前に、コンテンツの表示に使用する ID がアプリによって確認されます。

    MAMFileProtectionInfo info = MAMFileProtectionManager.getProtectionInfo(docPath)
if (info != null)
    MAMPolicyManager.setUIPolicyIdentity(activity, info.getIdentity(), callback, EnumSet.noneOf<IdentitySwitchOption.class>)

  • アプリは、結果がコールバックに報告されるまで待機します。

  • 報告された結果が失敗した場合、アプリはドキュメントを表示しません。

  • アプリが開き、ファイルがレンダリングされます。

アプリが Android DownloadManager を使用してファイルをダウンロードする場合、SDK は 前述の ID 優先度を使用してこれらのファイルを自動的に保護しようとします。 を取得 DownloadManager するために使用されるコンテキストは、スレッド ID が設定されていない場合に使用されます。 ダウンロードしたファイルに企業データが含まれている場合は、ダウンロード後にファイルが移動または再作成された場合に protect を呼び出す必要があります。

Single-Identity からマルチ ID への移行

以前にシングル ID Intune 統合でリリースされたアプリが後でマルチ ID を統合した場合、以前にインストールしたアプリに移行が発生します。 この遷移は、ユーザーには表示されません。

この移行を処理するためにアプリは 必要ありません 。 移行前に作成されたすべてのファイルは引き続きマネージドと見なされます (そのため、暗号化ポリシーがオンの場合は暗号化された状態を維持します)。

以前のすべてのアプリ データをマネージド ID に関連付けたくない場合は、この移行を検出し、保護を明示的に削除できます。

  • アプリのバージョンを、マルチ ID サポートが追加された既知のバージョンと比較して、アップグレードを検出します。
  • マネージド ID に関連付けたくないファイルまたはディレクトリで、ID パラメーターの空の文字列を使用して を呼び出 protect します。

オフライン シナリオ

ポータル サイト アプリがインストールされていない場合、Intune App SDK は "オフライン" モードで実行されます。 ファイル ID のタグ付けは、オフライン モードに依存します。

  • ポータル サイトがインストールされていない場合、ファイルに ID タグを付けることはできません。 オフライン モードで MAMFileProtectionManager.protect を呼び出しても安全ですが、効果はありません。

  • ポータル サイトがインストールされていても、アプリに App Protection ポリシーがない場合、ファイルを ID タグ付けすることはできません。

  • ファイル ID のタグ付けが使用可能になると、以前に作成したすべてのファイルは、単一 ID から マルチ ID への移行に関するページで説明されているように、アプリが以前にシングル ID マネージド アプリとしてインストールされていた場合を除き、個人用または非管理対象 (空の文字列 ID に属する) として扱われます。

このようなケースを回避するには、アカウントの登録が正常に完了するまで、アプリはアカウント データを含むファイルの作成を避ける必要があります。 アプリでオフライン中にファイルを絶対に作成する必要がある場合は、 MAMFileProtectionManager.protect を使用して、SDK がオンラインになると、ファイルの関連付けられている ID を修正できます。

データ バッファー保護

警告

複数のアカウントに属するデータを 1 つのファイルに書き込むのはお勧めしません。 可能であれば、アプリのファイルを ID で整理します。

SDK の MAMDataProtectionManager には、特定のデータ バッファーのタグ付き ID を確認および変更するためのメソッドがInputStream用意byte[]されています。

MAMDataProtectionManager.protect では、アプリがデータを ID に関連付け、ID が現在暗号化ポリシーの対象になっている場合は、データを暗号化できます。 この暗号化されたデータは、ファイル内のディスクに格納するのに適しています。

MAMDataProtectionManager また、ID に関連付けられているデータに対してクエリを実行し、暗号化を解除することもできます。

を利用するアプリでは MAMDataProtectionManager 、通知の受信者を実装する MANAGEMENT_REMOVED 必要があります。 詳細については、「 SDK からの通知の登録 」を参照してください。

この通知が完了すると、このクラスを介して保護されたバッファーは読み取りできなくなります (バッファーが保護されたときにファイル暗号化が有効にされた場合)。 アプリは、通知を処理するときにすべてのバッファーを呼び出 MAMDataProtectionManager.unprotect すことによって、これらのバッファーが読み取れなくなるのを MANAGEMENT_REMOVED 防ぐことができます。 また、ID 情報を保持する場合は、この通知中にを呼び出 protect しても安全です。 通知中に暗号化が無効になることが保証されており、ハンドラーでの呼び出し protect ではデータ バッファーは暗号化されません。

コンテンツ プロバイダー

マルチ ID アプリでは、マネージド コンテンツの不適切な共有を防ぐために、 を介して ContentProvider共有されるデータも保護する必要があります。

アプリは、コンテンツを返す前に静的 MAMContentProvider メソッド isProvideContentAllowed(provider, contentIdentity) を呼び出す必要があります。 この関数が false を返す場合、コンテンツを呼び出し元に返 してはなりません 。

が ContentProvider を返している場合、呼び出isProvideContentAllowedしParcelFileDescriptorは必要ありません。 コンテンツ プロバイダーから返されるファイル記述子は、ファイル ID に基づいて自動的に処理されます。

選択的ワイプ

既定では、Intune App SDK によって選択的ワイプが自動的に処理され、マネージド ID に関連付けられているすべての ファイル が削除されます。 その後、SDK はアプリを正常に閉じ、アクティビティを完了し、アプリ プロセスを強制終了します。

SDK は、アプリが既定のワイプ動作を補完 (推奨) またはオーバーライドするオプション機能を提供します。

SDK の既定のワイプ ハンドラーでは、 によって MAMDataProtectionManager保護されたデータ バッファーは処理されません。 アプリでこの機能を使用した場合、そのデータを削除するには、既定のワイプ ハンドラーを補完またはオーバーライドする 必要があります 。

注:

既定のワイプ動作を補足してオーバーライドするには、特定の SDK 通知を処理する必要があります。 通知ハンドラーの実装の詳細については、「 SDK からの通知の登録 」を参照してください。

既定のワイプ動作の補足

既定の SDK ワイプ動作を補完するために、アプリは MAMNotificationType にWIPE_USER_AUXILIARY_DATA登録できます。

この通知は、既定の選択的ワイプを実行する 前に SDK によって送信されます。 SDK は、アプリの通知ハンドラーが完了するまで待ってから、データを削除してアプリを終了します。 アプリはデータを同期的に消去し、すべてのクリーンアップが完了するまで返すべきではありません。

アプリ固有のクリーンアップはマルチ ID アプリで一般的であるため、アプリは、 で WIPE_USER_AUXILIARY_DATA既定のワイプ動作を補完することを強くお勧めします。

既定のワイプ動作のオーバーライド

既定の SDK ワイプ動作をオーバーライドするために、アプリは MAMNotificationType にWIPE_USER_DATA登録できます。

警告

アプリは、 と WIPE_USER_AUXILIARY_DATAの両方WIPE_USER_DATAに登録しないでください。

既定の SDK ワイプ動作をオーバーライドすると、アプリにかなりのリスクが発生します。 アプリは、マネージド ID に関連付けられているすべてのデータ (その ID に対してタグ付けされたすべてのファイルとデータ バッファーを含む) を完全に削除する責任を負います。

  • マネージド ID が暗号化で保護されていて、アプリのカスタム ワイプ ハンドラーによってすべてのマネージド データが完全に削除されない場合、残りのマネージド ファイルは暗号化されたままになります。 このデータにアクセスできなくなります。また、暗号化されたデータを正常に読み取ろうとしてもアプリで処理されない場合があります。
  • アプリのワイプ ハンドラーは、マネージド ID でタグ付けされていないファイルを削除すると、アンマネージ ユーザーのデータ損失につながる可能性があります。

アプリのカスタム ワイプ ハンドラーがファイルからマネージド データを削除するが、他のデータをファイルに残したい場合は、ファイルの ID (MAMFileProtectionManager.protect 経由) をアンマネージド ID または空の文字列に変更する必要があります。

オーバーライドされたワイプ ハンドラーは、すべてのクリーンアップが完了するまでデータを同期的にクリアし、返す必要はありません。

ワイプが発生した後、ユーザーがメモリ内データにアクセスできないように、カスタム ワイプ ハンドラーの手順を完了した後にアプリを手動で閉じることを検討してください。

終了条件

アプリのマルチ ID の統合を検証するためのかなりの時間を計画します。 テストを開始する前に、次の手順を実行します。

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

アプリの現在の動作を徹底的に評価したら、次の一連のテストを実行してマルチ ID 統合を検証します。 これは包括的なリストではなく、アプリのマルチ ID 実装がバグフリーであることを保証するものではありません。

ログインとログアウトのシナリオの検証

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

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

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

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

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

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

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

データ共有シナリオの検証

マルチ ID アプリは、他のアプリとの間でデータを送信したり、他のアプリからデータを受信したりできます。 Intune のアプリ保護ポリシーには、この動作を決定する設定があります。 これらのテストは、マルチ ID 統合がこれらのデータ共有設定を確実に受け入れるようにするのに役立ちます。

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

  • マネージド アカウントのポリシーを次のように設定します。
    • "組織データを他のアプリに送信する" を "ポリシー管理アプリ" に送信します。
    • "他のアプリからデータを受信する" から "ポリシー管理アプリ" に。
  • テスト デバイスに他のアプリをインストールします。
    • (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 が設定されていない可能性があります。 これを調査するには、アクティブな ID が正しく設定されていることを確認するために、送受信の時点で SDK の GET ID API を利用します。

選択的ワイプ シナリオの検証

マルチ ID アプリが SDK の既定のワイプ動作を補完またはオーバーライドしている可能性があります。 これらのテストは、非管理対象データに影響を与えずに、ワイプが開始されたときにマルチ ID 統合によってマネージド データが適切に削除されるようにするのに役立ちます。

警告

アプリが を利用している場合はMAMDataProtectionManager.protect、 または WIPE_USER_DATAのいずれかのWIPE_USER_AUXILIARY_DATAハンドラーを実装する必要があります。

これらのテストでは、アプリとIntune ポータル サイトをインストールします。テストを開始する前に、マネージド アカウントとアンマネージド アカウントの両方でログインします。 両方のアカウントについて、アカウント データを格納する演習アプリ シナリオ。

シナリオ 前提 条件 手順
補足ワイプ ハンドラー アプリで のハンドラーが実装されている WIPE_USER_AUXILIARY_DATA - Microsoft Intune管理センターから選択的ワイプを発行します。
- ワイプ ハンドラーが正常に実行されたことを (通常はログ記録によって) 確認します。
- マネージド アカウントがアプリから削除され、そのアカウントのデータがすべて削除されていることを確認します。
- アンマネージド アカウントがまだログインしていること、アンマネージド アカウントのデータが削除されていないこと、ポリシーがまだ適用されていないことを確認します。
オーバーライドされたワイプ ハンドラー アプリで のハンドラーが実装されている WIPE_USER_DATA - Microsoft Intune管理センターから選択的ワイプを発行します。
- ワイプ ハンドラーが正常に実行されたことを (通常はログ記録によって) 確認します。
- マネージド アカウントがアプリから削除され、そのアカウントのデータがすべて削除されていることを確認します。
- アンマネージド アカウントがまだログインしていること、アンマネージド アカウントのデータが削除されていないこと、ポリシーがまだ適用されていないことを確認します。
- アプリが正常に終了したか、ワイプ ハンドラーが完了した後も正常な状態であることを確認します。
手動によるファイル保護 - アプリの呼び出し MAMFileProtectionManager.protect
- アプリで のハンドラーが実装されている WIPE_USER_DATA		 - アプリがマネージド アカウントに属する少なくとも 1 つのファイルを手動で保護するシナリオが実行されていることを確認します。
- Microsoft Intune管理センターから選択的ワイプを発行します。
- ファイルが削除されていることを確認します。
手動データ バッファー保護 - アプリの呼び出し MAMDataProtectionManager.protect
- アプリで または のいずれかのハンドラー WIPE_USER_AUXILIARY_DATA が実装されている WIPE_USER_DATA		 - アプリがマネージド アカウントに属する少なくとも 1 つのデータ バッファーを手動で保護するシナリオが実行されていることを確認します。
- Microsoft Intune管理センターから選択的ワイプを発行します。
- データ バッファーが格納されているすべてのファイルから削除され、アプリがそれらのファイルからアンマネージド データを読み取ることができることを確認します。

次の手順

上記のすべての 終了条件 を完了すると、アプリはマルチ ID として正常に統合され、ID ごとにアプリ保護ポリシーを適用できます。 以降のセクションであるステージ 6: App Configurationおよびステージ 7: アプリ参加機能は、アプリの目的のアプリ保護ポリシーのサポートに応じて、必要な場合と必要ない場合があります。 これらのセクションのいずれかがアプリに適用されるかどうかわからない場合は、 SDK 統合に関する重要な決定事項に関するページを参照してください。