Intune App SDK for Android - 多重身分識別

Microsoft Intune App SDK for Android 可讓您將 Intune 應用程式保護原則 (也稱為應用程式或 MAM 原則) 併入原生 Java/Kotlin Android 應用程式中。 Intune 受控應用程式是與 Intune App SDK 整合的應用程式。 Intune 系統管理員可以在 Intune 主動管理應用程式時，輕鬆地將應用程式保護原則部署到 Intune 管理的應用程式。

注意事項

本指南分成數個不同的階段。 從檢閱 階段 1：規劃整合開始。

階段 5：多重身分識別

階段 Goals

• 判斷您的應用程式是否需要多重身分識別支援。
• 瞭解 Intune App SDK 如何感知身分識別。
• 重構您的應用程式以獲得身分識別感知。
• 新增程式代碼，以通知 SDK 在整個應用程式中使用中和變更身分識別。
• 徹底測試受控和非受控識別的應用程式保護原則強制執行。

身分識別術語

「使用者」、「帳戶」和「身分識別」等詞彙通常會交替使用。 本指南嘗試區分如下：

• 使用者：使用軟體產品的人。 進一步區分為終端使用者、使用Android應用程式的人員，以及 / 使用 Microsoft Intune系統管理中心的系統管理員使用者 / IT / 系統管理員IT專業人員。
• 帳戶：屬於可唯一識別用戶實體之組織的軟體記錄。 人類使用者可以有多個帳戶。
• 身分識別：Intune App SDK 用來唯一識別帳戶的數據集。

Background

根據預設，Intune App SDK 會將原則套用至整個應用程式。 在以應用程式保護原則為目標註冊帳戶之後，SDK 會將每個檔案和每個活動與該帳戶的身分識別建立關聯，並會普遍套用該帳戶的目標原則。

對於許多開發人員而言，這是其應用程式所需的應用程式保護行為。 這些應用程式會被視為 單一身分識別。 藉由完成先前的階段，您的應用程式已成功整合為單一身分識別，並可強制執行所有基本原則。 想要保持單一身分識別的應用程式可以略過本節，並繼續進行第 6 階段：應用程式組態。

Intune 應用程式 SDK 可以選擇性地在每個身分識別層級上強制執行原則。 如果您的應用程式已支援同時登入的多個帳戶，而且您想要使用應用程式保護原則保留此多帳戶支援，則會將您的應用程式視為 多重身分識別。

提示

如果您不清楚應用程式是否應該支援單一身分識別或多重身分識別保護，請重新流覽 我的應用程式是單一身分識別還是多重身分識別？

警告

相較於其他應用程式保護功能，支援多重身分識別更為複雜。 不正確整合多重身分識別可能會導致數據外洩和其他安全性問題。 請仔細檢閱本節，並規劃測試的充分時間，再繼續進行下一個階段。

SDK 的「身分識別」

當 SDK 整合應用程式使用 registerAccountForMAM 註冊帳戶時，SDK 會將所有提供的參數儲存 (upn、aadId、tenantId 和 authority) 作為身分識別。 不過，大部分的 SDK 身分識別 API 都會使用提供的 OID (也稱為 Microsoft Entra ID 或 AAD 識別碼) 作為身分識別的標識碼。 MAM SDK API 會傳回 OID 字串作為身分識別，而且需要識別的 OID 字串串參數。 某些方法也可能採用或傳回UPN字串，在此情況下，UPN 僅供參考之用。

身分識別參數不區分大小寫。 對身分識別的 SDK 要求可能不會傳回註冊或設定身分識別時所使用的相同大小寫。

注意

對於使用已被取代方法來取得或傳回 UPN 字串的應用程式，應用程式必須確定傳遞給各種 API 呼叫的識別 UPN 字串是一致的。 傳遞不一致的UPN字串可能會導致數據外洩。

受控與非受控識別

如 註冊應用程式保護原則中所述，您的應用程式會負責在使用者登入時通知 SDK。 在登入時，用戶的帳戶可能會或可能不會以應用程式保護原則為目標。 如果帳戶是以應用程式保護原則為目標，則 SDK 會將其視為受控;否則為 Unmanaged。

SDK 會針對它認為受控的身分識別強制執行原則。 SDK 不會針對它認為非受控的身分識別強制執行原則。

目前，Intune App SDK 僅支援每個裝置的單一受控識別。 一旦 任何 SDK 整合應用程式註冊受控識別，所有後續註冊的身分識別，即使它們目前是應用程式保護原則的目標，也會被視為非受控。

如果受控識別已在裝置上註冊，且您的應用程式註冊另一個身分識別也以應用程式保護原則為目標，則 SDK 會傳回 MAMEnrollmentManager.Result.WRONG_USER 並提示使用者提供補救選項。 如需詳細資訊，請參閱 註冊 SDK 的通知。

注意事項

在註冊期間未以應用程式保護原則為目標的帳戶會被視為非受控帳戶。 即使帳戶未獲得應用程式保護原則的授權或目標，SDK 也會定期檢查此帳戶是否會在稍後變成授權並設為目標。 如果尚未註冊其他受控識別，SDK 會在以原則為目標之後，開始將此身分識別視為受控。 使用者不需要註銷並重新登入此帳戶，即可進行這項變更。

作用中身分識別

您的應用程式一律必須讓SDK掌握目前使用的身分識別，也就是作用中的身分識別。 如果使用中的身分識別受到管理，SDK 將會套用保護。 如果未管理作用中的身分識別，SDK 將不會套用保護。

因為 SDK 沒有應用程式特定的知識，所以必須信任應用程式才能共用正確的作用中身分識別。

• 如果應用程式在受控識別實際使用中時，不正確地告知 SDK Unmanaged 身分識別為作用中，則 SDK 將不會套用保護。 這可能會導致數據外泄，讓用戶的數據面臨風險。

• 如果應用程式在非受控識別實際使用中時，不正確地告知 SDK 受控識別為作用中，則 SDK 會不適當地套用保護。 這不是數據外泄，但無須限制 Unmanaged 使用者，並讓非受控用戶的數據面臨刪除的風險。

如果您的應用程式顯示任何用戶的數據，它只能顯示屬於使用中身分識別的數據。 如果您的應用程式目前不知道誰擁有所顯示的數據，您可能需要重構應用程式以提升身分識別感知，才能開始整合多重身分識別支援。

依身分識別組織應用程式數據

每當您的應用程式寫入新檔案時，SDK 就會根據目前的作用中線程和進程身分識別，將 (也稱為「標記」，) 該檔案與該檔案建立關聯。 或者，您的應用程式可以直接呼叫 SDK 以手動標記具有特定身分識別的檔案 (如需詳細數據，請參閱 撰寫受保護的檔案) 。 SDK 會使用此標記的檔案身分識別來進行檔案加密和選擇性抹除。

如果受控識別是以加密原則為目標，則只會加密標記為受控識別的檔案。

如果清除系統管理員動作或設定的原則要求，則只會刪除標記為受控識別的檔案。

SDK 無法將多個身分識別與單一檔案產生關聯。 如果您的應用程式將屬於多個使用者的數據儲存在同一個檔案中，則 SDK 的預設行為會導致保護不足或過度保護此數據。 強烈建議您依身分識別組織應用程式的數據。

如果您的應用程式絕對必須將屬於不同身分識別的數據儲存在同一個檔案中，則 SDK 會提供在檔案中標記數據子集的功能。 如需詳細資訊，請參閱 數據緩衝區保護 。

實作多重身分識別

若要宣告應用程式的多重身分識別支援，請從將下列元數據放在 AndroidManifest.xml 開始。

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

設定作用中身分識別

您的應用程式可以以遞減優先順序在下列層級上設定作用中的身分識別：

1. 線程層級
2. Context (通常 Activity) 層級
3. 進程層級

在線程層級設定的身分識別會取代層級上 Context 設定的身分識別，進而取代進程層級上設定的身分識別。

上設定的 Context 身分識別僅用於適當的相關案例。 例如，檔案 IO 作業沒有相關聯 Context的 。 最常見的情況是，應用程式會在 上設定 Context 身分識別 Activity。 請考慮在 Context 中設定身分識別 Activity.onCreate。 除非身分識別設定為相同的身分識別，Activity否則應用程式不得顯示身分識別的數據。

一般而言，只有當應用程式在所有線程上一次只使用單一身分識別時，處理程式層級身分識別才有用。 對於支援多個帳戶的應用程式而言，這不是典型的行為。 強烈建議您隔離帳戶數據，並在線程或層級上設定作用中的身分識別 Context 。

如果您的應用程式使用內容 Application 來取得系統服務，請確定已設定線程或進程身分識別，或您已在應用程式 Application 的內容上設定 UI 身分識別。

如果您的應用程式使用 Service 內容來啟動意圖、使用內容解析程式，或利用其他系統服務，請務必在內容上設定身 Service 分識別。 同樣地，如果您的應用程式使用 JobService 內容來執行這些動作，請務必在實作所需的內容或線程上 JobService 設定身 JobService 分識別。 例如，如果您 JobService 處理單一身分識別的工作，請考慮在內容上設定身分 JobService 識別。 如果您 JobService 處理多個身分識別的工作，請考慮在線程層級設定身分識別。

注意

設定身分識別時，使用 WorkManager 的應用程式應該特別小心。 具體而言，這些應用程式應該避免在建構函式中傳遞的 ContextWorker 上設定身分識別。 這個 Context 實例可以同時在多個 Worker 實例之間共用。 為了避免未定義的行為，應用程式應該改為在 中設定實作所需的Worker線程Worker.doWork()身分識別。

注意事項

CLIPBOARD_SERVICE因為 用於UI作業，所以SDK會針對作業使用前景活動的 ClipboardManager UI身分識別。

MAMPolicyManager 中的下列方法可用來設定作用中的身分識別，並擷取先前設定的識別值。

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);

為了方便起見，您也可以直接透過 MAMActivity 中的方法來設定活動的身分識別，而不是呼叫 MAMPolicyManager.setUIPolicyIdentityOID。 使用下列方法來執行此動作：

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

注意事項

如果您的應用程式尚未在指令清單中宣告多重身分識別支援，呼叫這些方法來設定身分識別將不會執行任何動作，而且如果它們傳回 MAMIdentitySwitchResult，則一律會傳回 FAILED。

常見的身分識別切換陷阱

• 對於的呼叫startActivity，Intune App SDK 會假設層級的作用中Context身分識別與提供的Intent參數相關聯。 強烈建議您使用 的內容而不是 Application的內容來設定Context層級Activity身分識別。

• 建議您在 Context Activity 的 onCreate 方法期間設定身分識別。 不過，請務必也涵蓋其他進入點，例如 onNewIntent。 否則，當重複使用相同的活動來顯示受控和非受控識別的數據時，可能會不正確地套用原則，導致未受保護的公司數據或不當限制的個人資料。

身分識別切換結果

所有用來透過 MAMIdentitySwitchResult 設定身分識別報表結果值的方法。 有四個值可以傳回：

傳回值	案例
SUCCEEDED	身分識別變更成功。
NOT_ALLOWED	不允許身分識別變更。 如果在目前線程上設定不同的身分識別時，嘗試設定UI (Context) 識別，就會發生這種情況。
CANCELLED	使用者已取消身分識別變更，通常是在 PIN 或驗證提示上按 [上一頁] 按鈕。
FAILED	身分識別變更因為未指定的原因而失敗。

應用程式應該先確認 MAMIdentitySwitchResult 是否為 SUCCEEDED ，再顯示或使用受管理帳戶的數據。

大部分設定作用中身分識別的方法都會同步傳回 MAMIdentitySwitchResult 。 如果透過 setUIPolicyIdentityOID 設定Context身分識別，則會以異步方式報告結果。 應用程式可以實作 MAMSetUIIdentityCallback 來接收此結果，或是針對回呼對象傳遞 Null。 setUIPolicyIdentityOID如果在先前對 相同 Context上呼叫setUIPolicyIdentityOID的結果尚未傳遞時呼叫 ，則新的回呼會取代舊的回呼，而原始回呼永遠不會收到結果。

注意

Context如果提供給 setUIPolicyIdentityOID 的 是 Activity，則在執行系統管理員設定的條件式啟動檢查之前，SDK 不知道身分識別變更是否成功。 這可能會要求使用者輸入 PIN 或公司認證。

目前，啟用多重身分識別的應用程式，進程和線程身分識別切換一律會成功。 SDK 保留未來新增失敗條件的許可權。

如果UI身分識別切換與線程身分識別衝突，或使用者取消條件式啟動需求 (例如，按 PIN 畫面上的返回按鈕) ，UI 身分識別參數可能會因為無效的自變數而失敗。

活動上失敗的 UI 身分識別切換的預設行為是完成活動。 若要變更此行為並接收活動之身分識別變更嘗試的通知，您可以覆寫 中 MAMActivity的方法。

    public void onSwitchMAMIdentityComplete(final MAMIdentitySwitchResult result);

如果您覆寫 onSwitchMAMIdentityComplete (或呼叫 super 方法) ，您 必須 確定受控帳戶的數據不會在身分識別切換失敗之後顯示。

注意事項

切換身分識別可能需要重新建立活動。 在此情況下， onSwitchMAMIdentityComplete 回呼會傳遞至活動的新實例。

身分識別、意圖和 IdentitySwitchOptions

除了使用作用中身分識別自動標記新檔案之外，SDK 也會使用作用中的身分識別標記 意圖 。 根據預設，SDK 會檢查傳入意圖上的身分識別，並將其與作用中的身分識別進行比較。 如果這些身分識別不相符，SDK 通常會 (*) 要求身分識別切換 (請參閱下方 的隱含 身分識別變更，以取得詳細數據) 。

SDK 也會儲存此傳入意圖身分識別，以供稍後使用。 當應用程式明確變更 UI 身分識別時，SDK 會比較應用程式嘗試切換至 的身分識別與最新的傳入意圖身分識別。 如果這些身分識別不相符，SDK 通常會 (*) 無法進行身分識別切換。

SDK 會執行這項檢查，因為它假設應用程式仍在顯示來自意圖的內容，而該意圖屬於在意圖上標記的身分識別。 此假設可防止應用程式在顯示受控數據時無意中關閉保護;不過，此假設可能與應用程式的實際行為不正確。

選擇性的 IdentitySwitchOption 列舉可以傳遞至 setUIPolicyIdentityOID 和 switchMAMIdentityOID API，以修改 SDK 的預設行為。

• IGNORE_INTENT：在 UI 層要求身分識別切換時，此選項會通知 SDK 略過比較要求的身分識別參數與最近儲存的意圖身分識別。 當您的應用程式不再顯示屬於該身分識別的內容，且 SDK 不應封鎖此身分識別切換時，這會很有用。 例如：

  1. 您的應用程式是檔案查看器。 它可以轉譯從其他應用程式傳入的檔。 它也包含使用者可以切換帳戶的功能。 每當使用者使用此帳戶切換功能時，應用程式就會流覽至具有該帳戶最近檔的帳戶特定登陸頁面。
  2. 您的應用程式會收到顯示檔的意圖。 此意圖會以受控識別標記。
  3. 您的應用程式會切換至受控識別，並顯示這份檔，並正確套用保護。
  4. 使用者會使用帳戶切換器來變更為其個人帳戶。

  您的應用程式必須在步驟 4 中變更 UI 身分識別。 在此情況下，因為應用程式的行為是離開受控帳戶的數據， (意圖) 中的檔，所以應該在身分識別切換呼叫中使用 IGNORE_INTENT 。 這可避免 SDK 不適當地讓此呼叫失敗。

• DATA_FROM_INTENT：在 UI 層要求身分識別切換時，此選項會通知 SDK，在身分識別 切換成功之後，來自最近儲存意圖身分識別的數據將會繼續顯示。 因此，SDK 會針對先前的意圖身分識別完整評估接收原則，以判斷是否允許顯示。 例如：

  1. 您的應用程式是檔案查看器。 它可以轉譯從其他應用程式傳入的檔。 它也包含使用者可以切換帳戶的功能。 不同於先前的範例，每當使用者使用此帳戶切換功能時，應用程式就會流覽至顯示 所有帳戶最近檔的共享頁面。
  2. 您的應用程式會收到顯示檔的意圖。 此意圖會以受控識別標記。
  3. 您的應用程式會切換至受控識別，並顯示這份檔，並正確套用保護。
  4. 使用者會使用帳戶切換器來變更為其個人帳戶。

  您的應用程式必須在步驟 4 中變更 UI 身分識別。 在此情況下，因為應用程式的行為是繼續顯示受控識別的數據， (意圖) 中的檔預覽，所以應該在身分識別切換呼叫中使用 DATA_FROM_INTENT 。 這會通知 SDK 檢查已設定的應用程式保護原則，以判斷是否適合繼續顯示數據。

(*) SDK 的預設行為包含會略過此數據輸入檢查的特殊大小寫，例如意圖是否來自相同應用程式內或系統啟動器。

清除作用中身分識別

您的應用程式可能有與帳戶無關的案例。 您的應用程式也可能具有不需要任何登入之本機 Unmanaged 案例的案例。 在這兩種情況下，您的應用程式可能不希望 SDK 強制執行受控識別的原則，但您可能沒有要切換的明確身分識別。

您可以藉由呼叫身分識別 OID 參數設為 null的任何 set 識別方法，來清除作用中的身分識別。 清除某個層級的身分識別會導致 SDK 根據優先順序的順序，在其他層級尋找作用中的身分識別。

或者，您可以傳遞空字串做為識別 OID 參數，這會將身分識別設定為特殊空值，而這個值會被視為 Unmanaged 身分識別。 將作用中的身分識別設定為空字串，會告知 SDK 不要強制執行 任何 應用程式保護原則。

隱含身分識別變更

上一節說明您的應用程式可在線程、內容和進程層級明確設定作用中身分識別的不同方式。 不過，您的應用程式中的作用中身分識別也可以變更，而不需要您的應用程式呼叫上述任何方法。 本節說明您的應用程式如何接聽和回應這些隱含的身分識別變更。

接聽這些隱含的身分識別變更是選擇性的，但建議使用。 SDK 永遠不會變更作用中的身分識別，而不提供這些隱含的身分識別變更通知。

注意

如果您的應用程式選擇不接聽隱含身分識別變更，請特別小心不要假設使用中的身分識別。 不確定時，請使用 getCurrentThreadIdentityOID、 getUIPolicyIdentityOID和 getProcessIdentityOID 方法來確認作用中的身分識別。

隱含身分識別變更的來源

• 來自其他 Intune 受控應用程式的數據輸入可以變更線程和內容層級上的作用中身分識別。

  • 如果活動是從另一個 Intent MAM 應用程式所傳送的 啟動，則活動身分識別會在傳送時根據另一個應用程式 Intent 中的作用中身分識別來設定。

    • 例如，當使用者選取檔附件時，檢視 Word 檔的活動會從 Microsoft Outlook 的意圖啟動。 Office 的文件查看器活動的身分識別會從 Outlook 切換至身分識別。

  • 對於服務，線程身分識別在 或 onBind 呼叫期間的onStart設定方式類似。 從傳回onBind的 Binder 呼叫也會暫時設定線程識別。

  • 對的 ContentProvider 呼叫同樣會設定線程身分識別的持續時間。

• 用戶 與活動的互動可以變更內容層級上的作用中身分識別。 例如：

  • 用戶在期間 Resume 取消授權提示會導致隱含切換至空的身分識別。

處理隱含身分識別變更

您的應用程式可以選擇性地接聽並回應這些隱含的身分識別變更。 例如，您的應用程式可能需要多個步驟，才能使用新增的帳戶，例如設定新收件匣的電子郵件應用程式。 當您看到嘗試的身分識別切換到這個不完整的帳戶身分識別時，應用程式的處理程式可能會先將使用者重新導向至帳戶設定活動，然後再接受身分識別切換。 或者，您應用程式的處理程式可能會顯示錯誤對話框，並封鎖身分識別切換。

您的應用程式可以在 或 上ServiceContextProvider實作 MAMIdentityRequirementListener 介面，以進行套用至此線程的身分識別變更。 您的實作必須覆寫：

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

您的應用程式可以針對套用至此活動的身分識別變更，在 上Activity實作 MAMActivityIdentityRequirementListener 介面。 您的實作必須覆寫：

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

enum AppIdentitySwitchReason 參數描述隱含身分識別參數的來源。

列舉值	預設 SDK 行為	描述
CREATE	允許身分識別切換。	因為活動建立，所以會發生身分識別切換。
NEW_INTENT	允許身分識別切換。	發生身分識別切換是因為新的意圖已指派給活動。
RESUME_CANCELLED	封鎖身分識別參數。	發生身分識別切換是因為已取消履歷。 當終端使用者在 PIN、驗證或合規性 UI 上按下返回按鈕時，這是最常見的情況。

AppIdentitySwitchResultCallback 參數可讓開發人員覆寫身分識別參數的默認行為：

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 所進行的變更除外。 立即呼叫的 onMAMIdentitySwitchRequired 預設實作：

• callback.reportIdentitySwitchResult(FAILURE) 當原因為 RESUME_CANCELLED時。

• callback.reportIdentitySwitchResult(SUCCESS) 在所有其他情況下。

並非預期大部分的應用程式都需要以不同的方式封鎖或延遲身分識別切換，但如果應用程式需要這麼做，則必須考慮下列幾點：

• 如果封鎖身分識別切換，用戶行為就如同 SDK 的[接收來自其他應用程式的數據] 應用程式保護設定禁止數據輸入一樣。

• 如果服務正在主線程上執行， reportIdentitySwitchResult則必須 以同步方式呼叫 ，否則 UI 線程會停止回應。

• 若Activity要建立，將會在 之前onMAMCreate呼叫 onMAMIdentitySwitchRequired。 如果應用程式必須顯示 UI 以決定是否允許身分識別切換，則必須使用 不同的 活動來顯示該 UI。

• 在 中 Activity，當要求切換至空白身分識別，且原因為 RESUME_CANCELLED時，應用程式必須修改繼續的活動，以顯示與該身分識別切換一致的數據。 如果無法這麼做，應用程式應該拒絕切換，而且系統會再次要求使用者遵守原則以繼續身分識別 (例如，透過顯示應用程式 PIN 輸入畫面) 。

注意

多重身分識別應用程式可以接收來自受控和非受控應用程式的傳入數據。 應用程式必須負責以受控方式處理來自受控識別的數據。

如果要求的身分識別是受控 (請使用 MAMPolicyManager.getIsIdentityOIDManaged 來檢查) ，但應用程式無法使用該帳戶 (例如，因為必須先在應用程式中設定電子郵件帳戶等帳戶) 所以應該拒絕身分識別切換。

您可以呼叫靜態方法 MAMActivity.defaultOnMAMIdentitySwitchRequired(activity, upn, oid, reason, callback)來存取的預設行為MAMActivity.onMAMIdentitySwitchRequired。

同樣地，如果您需要覆寫 MAMActivity.onSwitchMAMIdentityComplete，則可以在不明確繼承自 MAMActivity的情況下實MAMActivityIdentitySwitchListener作 。

身分識別切換和螢幕快照限制

Intune App SDK 會使用 Window 旗標FLAG_SECURE來強制執行螢幕快照原則。 某些應用程式可能也會針對自己的用途進行設定 FLAG_SECURE 。 當應用程式保護原則不限制螢幕快照時，SDK 將不會修改 FLAG_SECURE。

在身分識別從原則需要停用螢幕快照的身分識別切換至原則不停用的身分識別時，SDK 會清除 FLAG_SECURE。 因此，您的應用程式不應該在身分識別切換之後依賴 FLAG_SECURE 剩餘的設定。

在異步操作中保留身分識別

應用程式通常會從UI線程分派背景工作，以處理其他線程上的作業。 多重身分識別應用程式必須確保這些背景工作會以適當的身分識別運作，這通常是分派它們的活動所使用的相同身分識別。

Intune App SDK 提供 MAMAsyncTask 和 MAMIdentityExecutors 作為便利性，以協助在異步操作中保留身分識別。 您的應用程式必須使用這些 (，或在其異步操作可以的情況下，明確地在) 工作上設定線程識別：

• 將屬於受控識別的數據寫入檔案
• 與其他應用程式通訊

MAMAsyncTask

若要使用 MAMAsyncTask，只要繼承自它，而非 AsyncTask ，並分別以 doInBackgroundMAM 和 onPreExecuteMAM 取代和 onPreExecute 的覆doInBackground寫。 建 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 會根據優先順序的正常順序來假設作用中的身分識別。

MAMIdentityExecutors

MAMIdentityExecutors可讓您使用 和方法，將現有的 Executor 或 ExecutorService 實例包裝為身分識別保留ExecutorService。wrapExecutorService/ExecutorwrapExecutor 例如

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

MAMIdentityExecutors 會根據優先順序的正常順序來假設作用中的身分識別。

檔案保護

寫入受保護的檔案

如上述依身分識別組織應用程式數據中所述，Intune App SDK 會在寫入檔案時，將線程/進程層級) 的作用中身分識別 (關聯。 請務必在檔案建立時設定正確的身分識別，以確保適當的加密和選擇性抹除功能。

您的應用程式可以使用 MAMFileProtectionManager 類別來查詢或變更檔案的身分識別，特別是 MAMFileProtectionManager.getProtectionInfo 用於查詢和 MAMFileProtectionManager.protectForOID 變更。

方法 protectForOID 也可以用來保護目錄。 目錄保護會以遞歸方式套用至目錄中包含的所有檔案和子目錄。 當目錄受到保護時，目錄內建立的所有新檔案都會自動套用相同的保護。 因為目錄保護是以遞歸方式套用， protectForOID 所以大型目錄的呼叫可能需要一些時間才能完成。 因此，將保護套用至包含大量檔案之目錄的應用程式可能會想要在背景線程上以異步方式執行 protectForOID 。

使用 protectForOID 空字串呼叫 identity 參數會以 Unmanaged 身分識別標記檔案/目錄。 如果先前已加密，此作業將會從檔案/目錄中移除加密。 發出選擇性抹除命令時，不會刪除檔案/目錄。

警告

請務必確保只有屬於特定身分識別的檔案才會受到該身分識別的保護。 否則，當擁有的身分識別註銷時，其他身分識別可能會遺失數據，因為檔案將會被抹除，而且加密密鑰存取將會遺失。

顯示受保護的檔案內容

在 顯示 檔案內容時，設定正確的身分識別同樣重要，以防止未經授權的用戶檢視受控數據。 SDK 無法自動推斷正在讀取的檔案與中 Activity顯示的數據之間的關聯性。 應用程式 必須 先適當地設定UI身分識別，才能顯示任何受控數據。 這包括從檔案讀取的數據。

如果檔案來自應用程式外部， (來自 ContentProvider 或從可公開寫入的位置讀取) ，則應用程式 必須 先嘗試判斷檔案身分識別 (針對數據源) 使用正確的 MAMFileProtectionManager.getProtectionInfo 多載，再顯示從檔案讀取的資訊。

如果 getProtectionInfo 報告非 Null 的非空白身分識別，應用程式 必須 使用 MAMActivity.switchMAMIdentityOID 或 MAMPolicyManager.setUIPolicyIdentityOID 來設定 UI 身分識別以符合此身分識別。 如果身分識別切換失敗， 則不得 顯示檔案中的數據。

從內容 URI 讀取時，可能需要先透過擷取 Uri) getProtectionInfo 的多載來讀取 (識別，然後適當地設定內容或線程識別。 在上開啟檔案描述項或輸入數據流 ContentResolver之前，必須先完成此作業，否則作業可能會失敗。

範例流程可能如下所示：

• 用戶選取要在應用程式中開啟的檔案。

• 在開啟流程期間，在從磁碟讀取數據之前，應用程式會確認應該用來顯示內容的身分識別：

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

• 應用程式會等到結果回報回呼為止。

• 如果回報的結果是失敗，應用程式就不會顯示檔。

• 應用程式會開啟並轉譯檔案。

如果應用程式使用 Android DownloadManager 下載檔，SDK 會嘗試使用 先前所述的身分識別優先順序來自動保護這些檔案。 如果未設定線程識別， DownloadManager 將會使用用來擷取 的內容。 如果下載的檔案包含公司數據，應用程式必須負責在檔案在下載後移動或重新建立時呼叫 protectForOID 。

Single-Identity 至多重身分識別轉換

如果先前使用單一身分識別發行的應用程式 Intune 整合之後整合多重身分識別，先前安裝的應用程式將會經歷轉換。 使用者看不到此轉換。

應用程式 不需要 處理此轉換。 在轉換之前建立的所有檔案都會繼續被視為受控 (，因此，如果加密原則是在) 上，則會保持加密狀態。

如果您不希望所有先前的應用程式數據都與受控識別相關聯，您可以偵測此轉換並明確移除保護。

• 藉由比較應用程式的版本與已新增多重身分識別支援的已知版本來偵測升級。
• 在 protectForOID 您不想要與受控識別相關聯的檔案或目錄上，使用空字串呼叫 identity 參數。

脫機案例

Intune 應用程式 SDK 會在未安裝 公司入口網站 應用程式時，以「離線」模式執行。 檔案身分識別標記會區分為離線模式：

• 如果未安裝 公司入口網站，則無法標記檔案的身分識別。 在離線模式中呼叫 MAMFileProtectionManager.protectForOID 是安全的，但不會有任何作用。

• 如果已安裝 公司入口網站，但應用程式沒有應用程式保護原則，則檔案無法可靠地標記身分識別。

• 當檔案身分識別標記變成可用時，所有先前建立的檔案都會被視為屬於空字串身分識別) 的個人/非受控 (，除非先前將應用程式安裝為單一身分識別受控應用程式，如單一身分識別 轉換為多重身分識別轉換中所述。

若要避免這些情況，應用程式應避免建立包含帳戶數據的檔案，直到帳戶註冊成功完成為止。 如果您的應用程式絕對必須在離線時建立檔案，它可以使用 MAMFileProtectionManager.protectForOID 在 SDK 上線後更正檔案的相關身分識別。

數據緩衝區保護

警告

不建議在單一檔案中寫入屬於多個帳戶的數據。 可能的話，請依身分識別組織應用程式的檔案。

SDK 的 MAMDataProtectionManager 提供方法來檢查和變更特定數據緩衝 byte[] 區上標記的身分識別，其格式為 或 InputStream 。

MAMDataProtectionManager.protectForOID 允許應用程式將數據與身分識別建立關聯，如果身分識別目前以加密原則為目標，則加密數據。 此加密數據適合儲存至檔案中的磁碟。

MAMDataProtectionManager 也可讓您查詢與身分識別相關聯的數據，並將其取消加密。

使用的 MAMDataProtectionManager 應用程式應該實作通知的 MANAGEMENT_REMOVED 接收者。 如需詳細資訊，請參閱 註冊 SDK 的通知。

此通知完成之後，如果在緩衝區受到保護時啟用檔案加密，則無法再讀取透過此類別保護的緩衝 () 。 應用程式可以在處理通知時呼叫 MAMDataProtectionManager.unprotect 所有緩衝區，以防止這些緩衝區變成無法讀取 MANAGEMENT_REMOVED 。 如果您要保留身分識別資訊，也可在此通知期間安全地呼叫 protectForOID 。 加密保證會在通知期間停用，而且在處理程式中呼叫 protectForOID 不會加密數據緩衝區。

警告

在應用程式程式中，應提早避免加密作業。 SDK 會在應用程式啟動後，儘早以異步方式執行加密初始化。 不過，如果應用程式在應用程式啟動時提出加密要求，則可能會遭到封鎖，直到加密初始化完成為止。

注意事項

Intune 應用程式 SDK 加密 API 只能用來加密 Intune 原則所需的數據。 未針對未啟用加密原則的帳戶套用保護，因此無法作為一般用途加密連結庫使用。

內容提供者

多重身分識別應用程式也必須保護透過 ContentProvider共用的數據，以防止不當共享受控內容。

您的應用程式必須先呼叫靜態 MAMContentProvider 方法 isProvideContentAllowedForOid(provider, oid) ，才能傳回內容。 如果此函式傳回 false，則 內容不得 傳回給呼叫者。

如果您ContentProvider要傳回 ParcelFileDescriptor，則不需要呼叫 isProvideContentAllowedForOid 。 透過內容提供者傳回的檔案描述項會根據檔案身分識別自動處理。

選擇性抹除

根據預設，Intune App SDK 會自動處理選擇性抹除，並刪除與受控識別相關聯的所有檔案。 之後，SDK 會正常關閉應用程式、完成活動並終止應用程式程式。

SDK 可讓您的應用程式選擇性地補充 (建議) 或覆寫預設抹除行為。

SDK 的預設抹除處理程式不會處理 受 MAMDataProtectionManager保護的數據緩衝區。 如果您的應用程式使用這項功能，它 必須 補充或覆寫預設抹除處理程式，才能移除該數據。

注意事項

補充和覆寫預設抹除行為需要處理特定 SDK 通知。 如需實作通知處理程式的詳細資訊，請參閱 註冊 SDK 的通知。

補充預設抹除行為

若要補充預設 SDK 抹除行為，您的應用程式可以註冊 WIPE_USER_AUXILIARY_DATAMAMNotificationType。

SDK 會在執行預設的選擇性抹除 之前 傳送此通知。 SDK 會先等候應用程式的通知處理程式完成，再刪除數據並終止應用程式。 您的應用程式應該以同步方式清除資料，直到所有清除完成後才會傳回。

應用程式應該強烈考慮使用 WIPE_USER_AUXILIARY_DATA來補充預設抹除行為，因為應用程式特定的清除適用於多重身分識別應用程式。

覆寫預設抹除行為

若要覆寫預設 SDK 抹除行為，您的應用程式可以註冊 WIPE_USER_DATAMAMNotificationType。

警告

應用程式不得同時註冊 WIPE_USER_DATA 和 WIPE_USER_AUXILIARY_DATA。

覆寫預設 SDK 抹除行為會對您的應用程式造成相當大的風險。 您的應用程式將完全負責移除與受控識別相關聯的所有數據，包括已標記該身分識別的所有檔案和數據緩衝區。

• 如果受控識別受到加密保護，而且您應用程式的自定義抹除處理程序並未完全移除所有受控數據，則任何剩餘的受控檔案都會保持加密狀態。 此數據將會變成無法存取，而且您的應用程式可能無法正常地處理讀取加密數據的嘗試。
• 如果應用程式的抹除處理程式移除未標記為受控識別的檔案，可能會導致 Unmanaged 使用者的數據遺失。

如果您應用程式的自定義抹除處理程式從檔案中移除受控數據，但想要將其他數據保留在檔案中，則 必須 透過 MAMFileProtectionManager.protectForOID) 將 (檔案的身分識別變更為非受控識別或空字元串。

您覆寫的抹除處理程式應該會同步清除數據，而且在所有清除完成之前不會傳回數據。

請考慮在完成自定義抹除處理程式步驟之後手動關閉您的應用程式，以防止使用者在抹除之後存取記憶體內部數據。

結束準則

規劃為驗證應用程式的多重身分識別整合提供大量時間。 開始測試之前：

• 建立應用程式保護原則並將其指派給帳戶。 這會是您的測試管理帳戶。
• 建立另一個帳戶，但不要將應用程式保護原則指派給該帳戶。 這會是您的測試 Unmanaged 帳戶。 或者，如果您的應用程式支援 Microsoft Entra 帳戶以外的多個帳戶類型，您可以使用現有的非 Entra 帳戶作為 Unmanaged 測試帳戶。
• 使用如何在您的應用程式內強制執行原則來自我反轉。 多重身分識別測試需要您輕鬆地區分應用程式何時為 且未在強制執行原則的情況下運作。 封鎖螢幕快照的應用程式保護原則設定可在快速測試原則強制執行時生效。
• 請考慮您的應用程式提供的整組UI。 列舉顯示帳戶數據的畫面。 您的應用程式是否只會一次呈現單一帳戶的數據，或是可以同時呈現屬於多個帳戶的數據？
• 請考慮您的應用程式所建立的整組檔案。 列舉其中哪一個檔案包含屬於帳戶的數據，而不是系統層級數據。
  • 決定您要如何驗證每個檔案的加密。
• 請考慮您的應用程式與其他應用程式互動的整組方式。 列舉所有輸入和輸出點。 您的應用程式可以內嵌哪些類型的數據？ 它會廣播哪些意圖？ 它會實作哪些內容提供者？
  • 決定您要如何執行這些數據共用功能。
  • 準備同時具有可與應用程式互動之受控和非受控應用程式的測試裝置。
• 請考慮您的應用程式如何讓終端使用者與所有登入的帳戶互動。 使用者是否需要手動切換至帳戶，才能顯示該帳戶的數據？

一旦您徹底評估應用程式的目前行為之後，請執行下列一組測試來驗證多重身分識別整合。 請注意，這不是完整的清單，也不保證應用程式的多重身分識別實作沒有 Bug。

驗證登入和註銷案例

您的多重身分識別應用程式最多支援 1 個受控帳戶和多個 Unmanaged 帳戶。 這些測試有助於確保您的多重身分識別整合不會在使用者登入或註銷時不當變更保護。

針對這些測試，請安裝您的應用程式和 Intune 公司入口網站;請勿在開始測試之前登入。

案例	步驟
先登入Managed	- 先使用受管理的帳戶登入，並驗證帳戶的數據是否受到管理。 - 使用 Unmanaged 帳戶登入，並驗證帳戶的數據未受管理。
先登入 Unmanaged	- 先使用 Unmanaged 帳戶登入，並驗證帳戶的數據未受管理。 - 使用受管理的帳戶登入，並驗證帳戶的數據是否受到管理。
登入多個Managed	- 先使用受管理的帳戶登入，並驗證帳戶的數據是否受到管理。 - 使用第二個受管理帳戶登入，並驗證使用者是否遭到封鎖而無法登入，而不會先移除原始的受管理帳戶。
註銷Managed	- 使用受管理的 Unmanaged 帳戶登入您的應用程式。 - 註銷Managed帳戶。 - 確認受控帳戶已從您的應用程式中移除，且該帳戶的所有數據都已移除。 - 確認 Unmanaged 帳戶仍已登入，未移除任何 Unmanaged 帳戶的數據，且仍然未套用原則。
註銷 Unmanaged	- 使用受管理的 Unmanaged 帳戶登入您的應用程式。 - 註銷 Unmanaged 帳戶。 - 確認 Unmanaged 帳戶已從您的應用程式中移除，且該帳戶的所有數據都已移除。 - 確認受管理的帳戶仍已登入，未移除任何 Unmanaged 帳戶的數據，且仍會套用原則。

驗證作用中的身分識別和應用程式生命週期

您的多重身分識別應用程式可能會顯示具有單一帳戶數據的檢視，並允許使用者明確變更目前使用中的帳戶。 它也可以同時顯示具有多個帳戶數據的檢視。 這些測試有助於確保您的多重身分識別整合在整個應用程式生命週期的每個頁面上為作用中身分識別提供正確的保護。

針對這些測試，請安裝您的應用程式和 Intune 公司入口網站;在開始測試之前，請先使用受控帳戶和 Unmanaged 帳戶登入。

案例	步驟
單一帳戶檢視，已管理	- 切換至 Managed 帳戶。 - 瀏覽至應用程式中呈現單一帳戶數據的所有頁面。 - 確認每個頁面上都套用原則。
單一帳戶檢視，Unmanaged	- 切換至 Unmanaged 帳戶。 - 瀏覽至應用程式中呈現單一帳戶數據的所有頁面。 - 確認未在任何頁面上套用原則。
多帳戶檢視	- 瀏覽至應用程式中同時呈現多個帳戶數據的所有頁面。 - 確認每個頁面上都套用原則。
Managed 暫停	- 在顯示受控數據且原則作用中的畫面上，流覽至裝置主畫面或其他應用程式來暫停應用程式。 - 繼續應用程式。 - 確認仍然套用原則。
非受控暫停	- 在顯示非受控數據且未啟用原則的畫面上，流覽至裝置主畫面或其他應用程式來暫停應用程式。 - 繼續應用程式。 - 確認未套用原則。
Managed kill	- 在顯示受控數據且原則作用中的畫面上，強制終止應用程式。 - 重新啟動應用程式。 - 確認如果應用程式繼續在畫面上，且受管理帳戶的數據 (預期) ，仍會套用原則。 如果應用程式在包含 Unmanaged 帳戶數據的畫面上繼續，請確認未套用原則。
非受控終止	- 在顯示非受控數據且原則為作用中的畫面上，強制終止應用程式。 - 重新啟動應用程式。 - 確認如果應用程式在畫面上繼續執行，且未受管理帳戶的數據 (預期) ，則不會套用原則。 如果應用程式在包含受管理帳戶數據的畫面上繼續，請確認仍會套用原則。
身分識別切換臨機操作	- 實驗在帳戶之間切換，以及暫停/繼續/終止/重新啟動應用程式。 - 確認受管理帳戶的數據一律受到保護，且 Unmanaged 帳戶的數據永遠不會受到保護。

驗證數據共用案例

您的多重身分識別應用程式可能會將數據傳送至其他應用程式並接收來自其他應用程式的數據。 Intune的應用程式保護原則具有指定此行為的設定。 這些測試有助於確保您的多重身分識別整合接受這些數據共享設定。

針對這些測試，請安裝您的應用程式和 Intune 公司入口網站;在開始測試之前，請先使用受控帳戶和 Unmanaged 帳戶登入。 此外：

• 將受管理帳戶的原則設定為：
  • 「將組織數據傳送至其他應用程式」至「受原則管理的應用程式」。
  • 「從其他應用程式接收數據」至「受原則管理的應用程式」。
• 在測試裝置上安裝其他應用程式：
  • 受控應用程式，以與您的應用程式相同的原則為目標，可傳送和接收數據 (，例如 Microsoft Outlook) 。
  • 任何可傳送和接收數據的 Unmanaged 應用程式。
• 使用 Managed 測試帳戶登入其他 Managed 應用程式。 即使另一個受控應用程式是多重身分識別，也只能使用受控帳戶登入。

如果您的應用程式能夠將數據傳送至其他應用程式，例如Microsoft Outlook 將檔附件傳送至 Microsoft Office：

案例	步驟
將受控識別傳送至 Unmanaged 應用程式	- 切換至 Managed 帳戶。 - 瀏覽至您的應用程式可以傳送資料的位置。 - 嘗試將數據傳送至 Unmanaged 應用程式。 - 您應該會遭到封鎖，無法將數據傳送至 Unmanaged 應用程式。
受控識別傳送至受控應用程式	- 切換至 Managed 帳戶。 - 瀏覽至您的應用程式可以傳送資料的位置。 - 嘗試使用已登入的Managed帳戶，將數據傳送至另一個Managed應用程式。 - 您應該允許將資料傳送至 Managed 應用程式。
非受控識別傳送至受控應用程式	- 切換至 Unmanaged 帳戶。 - 瀏覽至您的應用程式可以傳送資料的位置。 - 嘗試使用已登入的Managed帳戶，將數據傳送至另一個Managed應用程式。 - 您應該會遭到封鎖，無法將數據傳送至其他受控應用程式。
Unmanaged 身分識別傳送至 Unmanaged 應用程式	- 切換至 Unmanaged 帳戶。 - 瀏覽至您的應用程式可以傳送資料的位置。 - 嘗試將數據傳送至 Unmanaged 應用程式。 - 應一律允許您將 Unmanaged 帳戶的數據傳送至 Unmanaged 應用程式。

您的應用程式可能會主動從其他應用程式匯入數據，例如Microsoft Outlook 從 Microsoft OneDrive 附加檔案。 您的應用程式也可能被動接收來自其他應用程式的數據，例如Microsoft Office 從 Microsoft Outlook 附件開啟檔。 接收應用程式保護原則設定涵蓋這兩種案例。

如果應用程式能夠主動從其他應用程式匯入資料：

案例	步驟
從非受控應用程式匯入受控識別	- 切換至 Managed 帳戶。 - 瀏覽至您的應用程式可以從其他應用程式匯入資料的位置。 - 嘗試從 Unmanaged 應用程式匯入數據。 - 您應該會遭到封鎖，無法從 Unmanaged 應用程式匯入數據。
從受控應用程式匯入受控識別	- 切換至 Managed 帳戶。 - 瀏覽至您的應用程式可以從其他應用程式匯入資料的位置。 - 嘗試使用已登入的Managed帳戶，從其他Managed應用程式匯入數據。 - 您應該允許從其他 Managed 應用程式匯入資料。
從受控應用程式匯入非受控識別	- 切換至 Unmanaged 帳戶。 - 瀏覽至您的應用程式可以從其他應用程式匯入資料的位置。 - 嘗試使用已登入的Managed帳戶，從其他Managed應用程式匯入數據。 - 您應該會遭到封鎖，無法從其他受控應用程式匯入數據。
從 Unmanaged 應用程式匯入非受控識別	- 切換至 Unmanaged 帳戶。 - 瀏覽至您的應用程式可以從其他應用程式匯入資料的位置。 - 嘗試從 Unmanaged 應用程式匯入數據。 - 一律允許您從 Unmanaged 應用程式匯入 Unmanaged 帳戶的數據。

如果應用程式能夠被動接收來自其他應用程式的資料：

案例	步驟
從 Unmanaged 應用程式接收的受控識別	- 切換至 Managed 帳戶。 - 切換至 Unmanaged 應用程式。 - 瀏覽至可傳送資料的位置。 - 嘗試將數據從 Unmanaged 應用程式傳送至您的應用程式。 - 您應用程式的受控帳戶不應該能夠從 Unmanaged 應用程式接收資料。
受控識別從受控應用程式接收	- 切換至 Managed 帳戶。 - 切換至另一個已登入Managed帳戶的Managed應用程式。 - 瀏覽至可傳送資料的位置。 - 嘗試將數據從 Managed 應用程式傳送至您的應用程式。 - 應允許您應用程式的Managed帳戶接收來自其他Managed 應用程式的數據。
從受控應用程式接收的非受控身分識別	- 切換至 Unmanaged 帳戶。 - 切換至另一個已登入Managed帳戶的Managed應用程式。 - 瀏覽至可傳送資料的位置。 - 嘗試將數據從 Managed 應用程式傳送至您的應用程式。 - 您應用程式的 Unmanaged 帳戶應該無法從受控應用程式接收數據。
從非受控應用程式接收的非受控身分識別	- 切換至 Unmanaged 帳戶。 - 切換至 Unmanaged 應用程式。 - 瀏覽至可傳送資料的位置。 - 嘗試將數據從 Unmanaged 應用程式傳送至您的應用程式。 - 您應用程式的 Unmanaged 帳戶應一律允許從 Unmanaged 應用程式接收數據。

這些測試中的失敗可能表示您的應用程式在嘗試傳送或接收數據時，並未設定正確的作用中身分識別。 您可以在傳送/接收時利用 SDK 的取得身分識別 API 來確認作用中的身分識別已正確設定，以調查此問題。

驗證選擇性抹除案例

您的多重身分識別應用程式可能已補充或覆寫 SDK 的預設抹除行為。 這些測試有助於確保您的多重身分識別整合會在起始抹除時適當地移除受控數據，而不會影響 Unmanaged 數據。

警告

提醒，如果您的應用程式利用 MAMDataProtectionManager.protectForOID，它必須實作 或WIPE_USER_DATA的WIPE_USER_AUXILIARY_DATA處理程式。

針對這些測試，請安裝您的應用程式和 Intune 公司入口網站;在開始測試之前，請先使用受控帳戶和 Unmanaged 帳戶登入。 針對這兩個帳戶，請練習儲存帳戶數據的應用程式案例。

案例	前提條件	步驟
補充抹除處理程式	您的應用程式已實作的處理程式 WIPE_USER_AUXILIARY_DATA	- 從 Microsoft Intune 系統管理中心發出選擇性抹除。 - 確認 (通常透過記錄) 您的抹除處理程式已成功執行。 - 確認受控帳戶已從您的應用程式中移除，且該帳戶的所有數據都已移除。 - 確認 Unmanaged 帳戶仍已登入，未移除任何 Unmanaged 帳戶的數據，且仍然未套用原則。
覆寫抹除處理程式	您的應用程式已實作的處理程式 WIPE_USER_DATA	- 從 Microsoft Intune 系統管理中心發出選擇性抹除。 - 確認 (通常透過記錄) 您的抹除處理程式已成功執行。 - 確認受控帳戶已從您的應用程式中移除，且該帳戶的所有數據都已移除。 - 確認 Unmanaged 帳戶仍已登入，未移除任何 Unmanaged 帳戶的數據，且仍然未套用原則。 - 確認您的應用程式已正常結束，或在抹除處理程式完成後仍處於狀況良好的狀態。
手動檔案保護	- 您的應用程式呼叫 MAMFileProtectionManager.protectForOID - 您的應用程式已實作 的處理程式 WIPE_USER_DATA	- 請確定您已練習應用程式會手動保護至少一個屬於受管理帳戶的檔案。 - 從 Microsoft Intune 系統管理中心發出選擇性抹除。 - 確認檔案已移除。
手動數據緩衝區保護	- 您的應用程式呼叫 MAMDataProtectionManager.protectForOID - 您的應用程式已實作 或 的 WIPE_USER_AUXILIARY_DATA 處理程式 WIPE_USER_DATA	- 請確定您已練習應用程式會手動保護至少一個屬於受管理帳戶的數據緩衝區。 - 從 Microsoft Intune 系統管理中心發出選擇性抹除。 - 確認數據緩衝區已從儲存在其中的任何檔案中移除，而且您的應用程式仍然可以從這些檔案讀取 Unmanaged 數據。

後續步驟

完成上述所有 結束準則 之後，您的應用程式現在已成功整合為多重身分識別，並可根據每個身分識別強制執行應用程式保護原則。 視您應用程式所需的應用程式保護原則支援而定，後續各節的階段 6：應用程式組態 和階段 7：應用程式參與功能不一定需要。 如果您不確定這些區段中是否有任何一個適用於您的應用程式，請重新流覽 SDK 整合的重要決策。