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

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

注:

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

ステージ 5: マルチ ID

ステージ目標

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

ID の用語

"ユーザー"、"アカウント"、"ID" という用語は、多くの場合、同じ意味で使用されます。 このガイドでは、次のように区別しようとします。

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

背景

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

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

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

ヒント

アプリケーションが単一 ID またはマルチ ID のどちらの保護をサポートする必要があるかが明確でない場合は、「アプリケーションが単一 ID ですか、それとも複数 ID ですか?」を再確認してください。

警告

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

SDK への "ID"

SDK 統合アプリケーションが registerAccountForMAM を使用してアカウントを登録すると、SDK は指定されたすべてのパラメーター (upn、aadId、tenantId、および権限) を ID として保存します。 ただし、SDK の ID API のほとんどでは、指定された OID (Microsoft Entra ID または AAD ID とも呼ばれます) を ID の識別子として使用します。 MAM SDK API は ID として OID 文字列を返し、ID に OID 文字列パラメーターを必要とします。 一部のメソッドは UPN 文字列を取得または返すこともあります。この場合、UPN は情報提供のみを目的としています。

ID パラメーターでは、大文字と小文字は区別されません。 SDK への ID の要求に対して、ID の登録または設定時に使用されたのと同じ大文字と小文字が返されない場合があります。

注意

UPN 文字列を受け取るか返す非推奨のメソッドを使用するアプリの場合、アプリはさまざまな API 呼び出しに渡される ID UPN 文字列に一貫性があることを確認する必要があります。 一貫性のない UPN 文字列を渡すと、データ リークが発生する可能性があります。

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

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

SDK は、管理対象と見なされる ID にポリシーを適用します。 SDK は、管理されていないと見なされる ID にポリシーを適用しません。

現時点では、Intune アプリ 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 を持つファイルを手動でタグ付けすることもできます (詳細については、「Written Protected Files」を参照)。 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)level
  3. プロセス レベル

スレッド レベルで設定された ID は、 Context レベルで設定された ID に優先し、 レベルの ID セットはプロセス レベルで設定された ID に優先します。

Context に設定された ID は、適切な関連シナリオでのみ使用されます。 たとえば、ファイル IO 操作には関連する Contextがありません。 通常、アプリはActivityにContext ID を設定します。 Activity.onCreate で Context ID を設定することを検討してください。 Activity ID が同じ ID に設定されていない限り、アプリでは ID のデータを表示してはなりません。

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

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

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

注意

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

注:

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

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

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

public static String getUIPolicyIdentityOID(final Context context);

public static MAMIdentitySwitchResult setProcessIdentityOID(final String oid);

public static String getProcessIdentityOID();

public static MAMIdentitySwitchResult setCurrentThreadIdentityOID(final String oid);

public static String getCurrentThreadIdentityOID();

/**
 * 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 getPolicyForIdentityOID(final String oid);

public static boolean getIsIdentityOIDManaged(final String oid);

利便性を高めるために、MAMPolicyManager.setUIPolicyIdentityOID を呼び出すのではなく、MAMActivity のメソッドを使用してアクティビティの ID を直接設定することもできます。 これを行うには、次の方法を使用します。

     public final void switchMAMIdentityOID(final String newIdentityOid, final EnumSet<IdentitySwitchOption> options);

注:

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

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

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

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

ID 切り替えの結果

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

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

アプリは、マネージド アカウントのデータSUCCEEDED表示または使用する前に、MAMIdentitySwitchResult がされていることを確認する必要があります。

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

注意

setUIPolicyIdentityOID に指定されたContextが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 コールバックはアクティビティの新しいインスタンスに配信されます。

ID、意図、および IdentitySwitchOptions

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

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

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

省略可能な IdentitySwitchOption 列挙型を setUIPolicyIdentityOID API と switchMAMIdentityOID 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 の切り替えを要求する場合、このオプションは SDK に、 ID の切り替えが成功した後も、最後に保存された意図の ID からのデータが引き続き表示されることを SDK に通知します。 その結果、SDK は以前のインテント ID に対して受信ポリシーを完全に評価して、表示が許可されるかどうかを判断します。 例:

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

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

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

アクティブ ID のクリア

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

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

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

暗黙的な ID の変更

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

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

注意

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

暗黙的な ID の変更のソース

  • 他の Intune マネージド アプリからのデータ イングレスでは、スレッド レベルとコンテキスト レベルでアクティブ ID を変更できます。

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

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

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

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

  • アクティビティに対するユーザーの操作によって、コンテキスト レベルでアクティブ ID を変更できます。 例:

    • ユーザーが Resume 中に認証プロンプトをキャンセルすると、空の ID への暗黙的な切り替えが発生します。

暗黙的な ID の変更の処理

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

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

public abstract void onMAMIdentitySwitchRequired(String upn, String oid,
        AppIdentitySwitchResultCallback callback);

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

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

AppIdentitySwitchReason enum パラメーターは、暗黙的な 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の作成では、onMAMCreateの前に onMAMIdentitySwitchRequired が呼び出されます。 ID 切り替えを許可するかどうかを判断するためにアプリで UI を表示する必要がある場合は、 別の アクティビティを使用してその UI を表示する必要があります。

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

注意

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

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

MAMActivity.onMAMIdentitySwitchRequired の既定の動作にアクセスするには、静的メソッド MAMActivity.defaultOnMAMIdentitySwitchRequired(activity, upn, oid, reason, callback) を呼び出します。

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

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

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

ポリシーでスクリーンショットの無効化が要求されている ID からポリシーで必要のない ID に ID が切り替わると、SDK によって FLAG_SECUREがクリアされます。 そのため、アプリ FLAG_SECURE ID 切り替え後に残っているセットに依存すべきではありません。

非同期操作での ID の保持

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

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

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

MAMAsyncTask

MAMAsyncTaskを使用するには、AsyncTaskではなく継承し、doInBackgroundとonPreExecuteのオーバーライドをそれぞれ doInBackgroundMAM と 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 wrapExecutor メソッドと wrapExecutorService メソッドを使用して、既存の Executor または ExecutorService インスタンスを ID 保持Executor/ExecutorServiceとしてラップできます。 たとえば、

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

MAMIdentityExecutors 通常の優先順位に基づいてアクティブな ID を引き継ぎます。

ファイル保護

Protected Files の書き込み

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

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

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

ID パラメーターに空の文字列を使用して protectForOID を呼び出すと、ファイル/ディレクトリにアンマネージド ID がタグ付けされます。 この操作により、以前に暗号化されていたファイル/ディレクトリから暗号化が削除されます。 セレクティブ ワイプ コマンドが発行されても、ファイル/ディレクトリは削除されません。

警告

特定の ID に属するファイルのみがその ID で保護されるようにすることが重要です。 そうしないと、所有 ID がサインアウトしたときにファイルがワイプされ、暗号化キーへのアクセスが失われるため、他の ID でデータが失われる可能性があります。

保護されたファイルの内容の表示

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

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

getProtectionInfo が null 以外、空ではない ID を報告した場合、アプリは MAMActivity.switchMAMIdentityOID または MAMPolicyManager.setUIPolicyIdentityOID を使用して、この ID と一致するように UI ID を設定する必要があります。 ID 切り替えが失敗した場合は、ファイルのデータを表示 してはなり ません。

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

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

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

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

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

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

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

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

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

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

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

アプリでこの移行を処理する 必要はありません 。 移行前に作成されたすべてのファイルは、引き続き管理対象と見なされます (そのため、暗号化ポリシーがオンになっている場合は暗号化されたままになります)。

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

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

オフライン シナリオ

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

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

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

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

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

データ バッファー保護

警告

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

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

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

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

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

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

警告

暗号化操作は、アプリ プロセスの早い段階で回避する必要があります。 SDK は、アプリの起動後できるだけ早く、暗号化の初期化を非同期的に実行します。 ただし、アプリの起動時にアプリが暗号化要求を行った場合、暗号化の初期化が完了するまでブロックされる場合があります。

注:

Intune アプリ SDK 暗号化 API は、Intune ポリシーで要求されるデータを暗号化するためにのみ使用する必要があります。 暗号化ポリシーが有効になっている対象ではないアカウントには保護は適用されないため、汎用の暗号化ライブラリとして使用することはできません。

コンテンツ プロバイダー

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

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

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

選択的ワイプ

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

SDK には、アプリで既定のワイプ動作を補完 (推奨) またはオーバーライドするオプションの機能が用意されています。

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

注:

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

既定のワイプ動作の補完

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

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

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

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

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

警告

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

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

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

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

オーバーライドされたワイプ ハンドラーは、データを同期的にクリアし、すべてのクリーンアップが完了するまで戻らないようにします。

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

終了条件

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

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

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

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

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

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

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

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

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

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

シナリオ 手順
1 つのアカウント ビュー、管理対象 - 管理対象アカウントに切り替えます。
- 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 が設定されていないことを示している可能性があります。 これを調査するには、送受信時に SDK の get identity API を利用して、アクティブな ID が適切に設定されていることを確認します。

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

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

警告

アプリで MAMDataProtectionManager.protectForOID を利用している場合は、WIPE_USER_AUXILIARY_DATA または WIPE_USER_DATA のハンドラーを実装する必要があることに注意してください。

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

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

次の手順

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

  • Last updated on