次の方法で共有

Intune App SDK for Android - マルチ ID

  • [アーティクル]

Microsoft Intune App SDK for Android を使用すると、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 アプリを使用する人間、および admin / admin ユーザー / 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 のほとんどは、指定された OID (Microsoft Entra ID または AAD ID とも呼ばれます) を ID の識別子として使用します。 MAM SDK API は OID 文字列を ID として返し、ID に OID 文字列パラメーターを必要とします。 一部のメソッドでは、UPN 文字列を受け取ったり返したりすることもできます。この場合、UPN は情報提供のみを目的としています。

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

注意

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

マネージド 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がありません。 最も一般的には、アプリは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 を設定する必要があります。

注:

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

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 パラメーターに関連付けられていると想定します。 Applicationのコンテキストではなく、Activityのコンテキストを使用してContext レベルの ID を設定することを強くお勧めします。

  • アクティビティの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 を 同期的に返します。 setUIPolicyIdentityOID を使用してContext ID を設定する場合、結果は非同期的に報告されます。 アプリは、この結果を受け取るために MAMSetUIIdentityCallback を実装するか、コールバック オブジェクトに null を渡すことができます。 同じContextに対する以前の呼び出しの結果がまだ配信されていない間 setUIPolicyIdentityOIDにsetUIPolicyIdentityOID呼び出しが行われた場合、新しいコールバックは古いものに取って代わり、元のコールバックは結果を受け取りません。

注意

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

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 列挙型を 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 スイッチを要求する場合、このオプションは、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 OID パラメーターが null に設定されている任意のセット ID メソッドを呼び出すことで、アクティブ ID をクリアできます。 ID を 1 つのレベルでクリアすると、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 の変更のために、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列挙型パラメーターは、暗黙的な 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 の "他のアプリからデータを受信する" アプリ保護設定でデータイングレスが禁止されていた場合と同じです。

  • サービスがメイン スレッドで実行されている場合、reportIdentitySwitchResultmust を同期的に呼び出すか、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 に切り替えると、SDK は FLAG_SECUREをクリアします。 その結果、アプリは、ID 切り替え後 FLAG_SECURE 残りのセットに依存しないようにする必要があります。

非同期操作での ID の保持

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

Intune App 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では、既存のExecutorまたはExecutorServiceインスタンスを、wrapExecutorメソッドとwrapExecutorServiceメソッドを使用して ID 保持Executor/ExecutorServiceとしてラップできます。 たとえば、

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

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

ファイル保護

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

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

アプリでは、MAMFileProtectionManager クラスを使用してファイルの ID を照会または変更できます。具体的には、クエリを実行し、変更するためのMAMFileProtectionManager.protectForOIDMAMFileProtectionManager.getProtectionInfoします。

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

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

警告

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

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

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

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

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

コンテンツ URI から読み取る場合は、最初に ID を読み取り (Uriを取得するgetProtectionInfoオーバーロードを介して)、コンテキストまたはスレッド 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 優先度を使用してこれらのファイルを自動的に保護しようとします。 スレッド ID が設定されていない場合、 DownloadManager の取得に使用されるコンテキストが使用されます。 ダウンロードしたファイルに企業データが含まれている場合、ダウンロード後にファイルを移動または再作成する場合は 、protectForOID を呼び出す必要があります。

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

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

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

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

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

オフライン シナリオ

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

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

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

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

このようなケースを回避するには、アカウントの登録が正常に完了するまで、アプリはアカウント データを含むファイルの作成を避ける必要があります。 アプリでオフライン中にファイルを絶対に作成する必要がある場合は、 MAMFileProtectionManager.protectForOID を使用して、SDK がオンラインになると、ファイルに関連付けられている 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 App SDK 暗号化 API は、Intune ポリシーで必要に応じてデータを暗号化するためにのみ使用する必要があります。 暗号化ポリシーが有効になっている対象になっていないアカウントには保護が適用されないため、汎用暗号化ライブラリとして使用することはできません。

コンテンツ プロバイダー

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

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

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

選択的ワイプ

既定では、Intune App 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 でタグ付けされていないファイルを削除すると、アンマネージ ユーザーのデータ損失につながる可能性があります。

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

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

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

終了条件

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

  • アプリ保護ポリシーを作成してアカウントに割り当てます。 これは、テストマネージド アカウントになります。
  • 別のアカウントにアプリ保護ポリシーを作成しますが、割り当てないでください。 これは、テストアンマネージド アカウントになります。 または、アプリがMicrosoft Entra アカウント以外の複数のアカウントの種類をサポートしている場合は、アンマネージド テスト アカウントとして既存の非 Entra アカウントを使用できます。
  • アプリ内でポリシーがどのように適用されるかを確認します。 マルチ 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.protectForOIDを利用している場合は、WIPE_USER_AUXILIARY_DATAまたはWIPE_USER_DATAのいずれかのハンドラーを実装する必要があります。

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

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

次の手順

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