適用於 Android 的 Intune App SDK - 多重身分識別

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

注意事項

本指南分為幾個不同的階段。 首先檢閱 第 1 階段：規劃整合。

階段 5：多重身分識別

階段目標

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

身分識別術語

「使用者」、「帳戶」和「身分識別」等術語經常交替使用。 本指南嘗試區分如下：

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

Background

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

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

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

提示

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

警告

支援多重身分識別比其他應用程式保護功能複雜得多。 多重身分整合不當可能會導致資料外洩和其他安全問題。 在進入下一階段之前，請仔細閱讀本節並規劃充足的測試時間。

SDK 的「身分識別」

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

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

注意

對於使用採用或傳回 UPN 字串之已取代方法的應用程式，應用程式必須確定傳遞至各種 API 呼叫的身分識別 UPN 字串是一致的。 傳遞不一致的 UPN 字串可能會導致資料外洩。

受控與非受控識別

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

SDK 會針對其視為受管理的身分識別強制執行原則。 SDK 不會針對其視為未受管理的身分識別強制執行原則。

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

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

注意事項

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

主動式識別

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

由於 SDK 沒有應用程式特定知識，因此必須信任應用程式以共用正確的活動身分識別。

• 如果應用程式不正確地告知 SDK 非受控識別在實際使用中時處於使用中狀態，則 SDK 將不會套用保護。 這可能會導致資料外洩，使使用者的資料面臨風險。

• 當實際使用非受控識別時，如果應用程式不正確地告知 SDK 受控識別處於作用中狀態，則 SDK 將會不當地套用保護。 這不是資料外洩，但這可能會不必要地限制未受管理的使用者，並使未受管理的使用者資料面臨刪除的風險。

如果您的應用程式顯示任何使用者的資料，則必須只顯示屬於使用中身分識別的資料。 如果您的應用程式目前不知道誰擁有顯示的資料，您可能需要先重構應用程式，以提高身分識別意識，再開始整合多重身分識別支援。

依身分識別組織應用程式資料

每當您的應用程式寫入新檔案時，SDK 就會根據目前使用中的執行緒和處理程序身分識別，將 (也稱為「標籤」) 身分識別與該檔案建立關聯。 或者，您的應用程式可以直接呼叫 SDK，以手動標記具有特定身分識別的檔案 (請參閱撰寫受保護的Files以取得詳細資料) 。 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的 . 最常見的是，應用程式會在 上設定ContextActivity身分識別。 請考慮在 中Activity.onCreate設定Context身分識別。 除非身分識別設定為相同的身分識別，否則Activity應用程式不得顯示身分識別的資料。

一般而言，只有在應用程式一次只能在所有執行緒上使用單一身分識別時，程式層級身分識別才有用。 這不是支援多個帳戶的應用程式的典型行為。 強烈建議您隔離帳戶資料，並在執行緒或 Context 層級上設定使用中身分識別。

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

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

注意

使用的 WorkManager 應用程式在設定身分識別時應特別小心。 具體而言，這些應用程式應該避免在傳入Worker建構函式上Context設定身分識別。 此 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參數相關聯。 我們強烈建議您使用 's 內容而非 Application's 內容來Activity設定Context層級身分識別。

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

身分識別切換結果

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

傳回值	案例
SUCCEEDED	身分識別變更成功。
NOT_ALLOWED	不允許身分識別變更。 當目前執行緒上設定不同的身分識別時，嘗試設定 UI () Context 身分識別，就會發生這個問題。
CANCELLED	使用者取消身分識別變更，通常是透過按下 PIN 或驗證提示上的返回按鈕。
FAILED	身分識別變更失敗，原因未指定。

應用程式應先驗證 MAMIdentitySwitchResultSUCCEEDED，然後再顯示或使用受管理帳戶的資料。

大部分設定使用中身分識別的方法都會同步傳回 MAMIdentitySwitchResult 。 在透過 setUIPolicyIdentityOID 設定Context身分識別的情況下，結果會以非同步方式報告。 應用程式可能會實作 MAMSetUIIdentityCallback 來接收此結果，或可能會傳遞回呼物件的 null。 如果在先前呼叫setUIPolicyIdentityOIDContext的結果尚未傳遞時進行呼叫setUIPolicyIdentityOID，則新的回呼將取代舊的回呼，原始回呼永遠不會收到結果。

注意

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

目前，對於已啟用多重身分識別的應用程式，處理序和執行緒身分識別切換一律會成功。 SDK 保留未來新增失敗條件的權利。

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

活動上發生失敗的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 的預設行為確實包含特殊大小寫，例如，如果意圖來自相同應用程式內部或系統啟動程式，則會略過此資料輸入檢查。

清除使用中的身分識別

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

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

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

隱含身分識別變更

上一節說明您的應用程式可以在執行緒、內容和處理程序層級明確設定活動身分識別的不同方式。 不過，應用程式中的使用中身分識別也可以變更，而不需要呼叫任何這些方法。 本節說明您的應用程式如何接聽並回應這些隱含身分識別變更。

接聽這些隱含身分識別變更是選擇性的，但建議執行。 在未提供這些隱含身分識別變更通知的情況下，SDK 絕不會變更使用中的身分識別。

注意

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

隱含身分識別變更的來源

• 來自其他 Intune 託管應用程式的資料輸入可能會變更線程和內容層級上的作用中身分識別。

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

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

  • 針對服務，執行緒身分識別會在 OR onStartonBind 呼叫期間以類似的方式設定。 對 Binder 傳回者的 onBind 呼叫也會暫時設定執行緒身分識別。

  • 對 a ContentProvider 的呼叫同樣會在其持續時間內設定執行緒身分識別。

• 使用者與活動的互動可以變更內容層級的主動身分識別。 例如：

  • 使用者在執行期間 Resume 取消授權提示，將導致隱含切換至空白身分識別。

處理隱含身分識別變更

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

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

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

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

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

大部分應用程式不需要以不同的方式封鎖或延遲身分識別切換，但如果應用程式需要這樣做，必須考量下列幾點：

• 如果身分識別切換遭到封鎖，使用者行為就會與 SDK 的 [從其他應用程式接收資料] 應用程式保護設定已禁止資料輸入相同。

• 如果服務在主執行緒上執行，reportIdentitySwitchResult則必須同步呼叫，或 UI 執行緒停止回應。

• 針對 Activity 建立， onMAMIdentitySwitchRequired 會在之前 onMAMCreate呼叫。 如果應用程式必須顯示 UI 才能判斷是否允許身分識別切換，則必須使用 不同的 活動來顯示該 UI。

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

注意

多重身分識別應用程式可以接收來自受管理和非受管理應用程式的傳入資料。 應用程式的責任是以受控方式處理來自受控身分識別的資料。

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

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

同樣地，如果你需要重寫 MAMActivity.onSwitchMAMIdentityComplete，你可以實作 MAMActivityIdentitySwitchListener ，而不需要明確繼承自 MAMActivity。

身分識別切換和螢幕擷取畫面限制

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 和 onPreExecute 的doInBackground覆寫，分別用 和 onPreExecuteMAM 取代。doInBackgroundMAM 建構函式採用 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可讓您使用 和方法將wrapExecutor現有Executor或ExecutorService執行個體包裝為保留身分識別ExecutorServiceExecutor/。wrapExecutorService 例如

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

MAMIdentityExecutors 會根據一般優先順序採用使用中的身分識別。

檔案保護

寫入受保護的檔案 （Writing Protected Files）

如上述依身分識別組織應用程式資料中所述，Intune App SDK 會在檔案寫入時，將來自執行緒/處理程序層級) 的使用中身分識別 (與檔案建立關聯。 在檔案建立時設定正確的身分識別，以確保正確的加密和選擇性抹除功能至關重要。

您的應用程式可能會使用 MAMFileProtectionManager 類別查詢或變更檔案的身分識別，專門 MAMFileProtectionManager.getProtectionInfo 用於查詢和 MAMFileProtectionManager.protectForOID 變更。

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

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

警告

請務必確保只有屬於特定身分的檔案會受到該身分識別的保護。 否則，當擁有身分登出時，其他身分識別可能會發生資料遺失，因為檔案將會遭到抹除，加密金鑰存取權將會遺失。

顯示受保護的檔案內容

在 顯示 檔案內容時設定正確的身分識別同樣重要，以防止未經授權的使用者檢視受管理資料。 SDK 無法自動推斷正在讀取的檔案與在 中 Activity顯示的資料之間的關係。 應用程式 必須 在顯示任何受管理資料之前，適當設定 UI 身分識別。 這包括從檔案讀取的資料。

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

如果報告非 Null、非空白身分識別，則 getProtectionInfo 應用程式 必須 使用 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>)
  

• 應用程式會等待，直到回報結果給回呼。

• 如果回報的結果為失敗，App 不會顯示文件。

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

如果應用程式使用 Android DownloadManager 下載檔案，SDK 會嘗試使用 前面所述的身份識別優先順序自動保護這些文件。 如果未設置執行緒身份，則將使用用來檢索內容 DownloadManager 。 如果下載的檔案包含公司資料，在下載後移動或重新建立檔案時，應用程式有責任呼叫 protectForOID 。

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

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

不需要 應用程式來處理 此轉換。 在轉換之前建立的所有檔案都會繼續被視為受管理 (因此，如果加密原則已啟用) ，這些檔案就會保持加密。

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

• 將應用程式的版本與已新增多重身分識別支援的已知版本比較，以偵測升級。
• 針對您不希望與受控識別關聯的檔案或目錄上的身分識別參數，以空字串呼叫 protectForOID 。

離線案例

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

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

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

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

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

資料緩衝區保護

警告

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

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

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

MAMDataProtectionManager 也可讓您查詢與身分識別相關聯的資料，並且對其進行取消加密。

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

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

警告

應避免在應用程式程序早期進行加密作業。 SDK 會在應用程式啟動後儘早以非同步方式執行加密初始化。 不過，如果應用程式在應用程式啟動時提出加密要求，則在加密初始化完成之前，可能會遭到封鎖。

注意事項

Intune App SDK 加密 API 只能用來加密Intune原則要求的資料。 未啟用加密原則的目標帳戶將不會套用任何保護，因此它不能用作一般用途的加密程式庫。

內容提供者

多重身分識別應用程式也必須保護透過 ContentProviders 共用的資料，以防止不當共用受管理內容。

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

如果您傳回 ParcelFileDescriptor，則ContentProvider不需要撥打電話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 抹除行為會給您的應用程式帶來相當大的風險。 您的應用程式將全權負責移除與受控身分識別相關聯的所有資料，包括已針對該身分識別標記的所有檔案和資料緩衝區。

• 如果受控識別受到加密保護，而且您應用程式的自訂抹除處理常式未完全移除所有受管理資料，則任何剩餘的受管理檔案都會保持加密。 此資料將變得無法存取，而且您的應用程式可能無法處理正常讀取加密資料的嘗試。
• 如果應用程式的抹除處理常式移除未以受控識別標記的檔案，則可能會導致未受管理使用者的資料遺失。

如果您應用程式的自訂抹除處理常式會從檔案中移除受管理資料，但想要在檔案中保留其他資料，則 必須 透過 MAMFileProtectionManager.protectForOID) 將檔案的身分識別 (變更為未受控身分識別或空白字串。

覆寫的抹除處理常式應該會同步清除資料，直到所有清理完成才會返回。

請考慮在完成自訂抹除處理常式步驟之後手動關閉您的 App，以防止使用者在抹除發生後存取記憶體內部資料。

結束準則

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

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

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

驗證登入和登出案例

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

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

案例	步驟
先登入受控	- 首先使用受管理的帳戶登入，並驗證該帳戶的資料是受管理的。 - 使用未受管理的帳戶登入，並驗證該帳戶的資料不受管理。
先在非受控狀態登入	- 先使用未受管理的帳戶登入，並驗證該帳戶的資料不受管理。 - 使用受管理的帳戶登入，並驗證該帳戶的資料已受管理。
登入多個受管理	- 首先使用受管理的帳戶登入，並驗證該帳戶的資料是受管理的。 - 使用第二個受管理帳戶登入，並驗證使用者是否已被封鎖登入，而不需要先移除原始受管理帳戶。
登出受控	- 使用託管帳戶和非託管帳戶登入您的應用程式。 - 登出託管帳戶。 - 確認受管理的帳戶已從應用程式中移除，且該帳戶的所有資料都已移除。 - 確認未受管帳戶仍已登入，未移除任何未受控帳戶的資料，且仍未套用原則。
在不受管理的情況下登出	- 使用託管帳戶和非託管帳戶登入您的應用程式。 - 登出未受管的帳戶。 - 確認已從應用程式中移除未受管理的帳戶，且該帳戶的所有資料都已移除。 - 確認受管帳戶仍已登入，未移除任何未受管帳戶的資料，且仍在套用原則。

驗證使用中身分識別與應用程式生命週期

您的多重身分識別應用程式可能會呈現包含單一帳戶資料的視圖，並允許使用者明確變更目前使用中的帳戶。 它也可能同時呈現包含多個帳戶資料的檢視。 這些測試有助於確保您的多重身份整合在整個應用程序生命週期中為每個頁面上的活動身份提供正確的保護。

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

案例	步驟
單一帳戶檢視，受管理	- 切換至受管理帳戶。 - 前往應用程式中顯示單一帳戶資料的所有頁面。 - 確認原則套用至每個頁面。
單一帳戶檢視、非受控	- 切換至非受管帳戶。 - 前往應用程式中顯示單一帳戶資料的所有頁面。 - 確認原則未套用至任何頁面。
多帳戶檢視	- 導航到應用程式中同時顯示多個帳戶資料的所有頁面。 - 確認原則套用至每個頁面。
受管理的暫停	- 在顯示受管理資料且原則處於作用中的畫面上，瀏覽至裝置主畫面或其他應用程式以暫停應用程式。 - 恢復應用程式。 - 確認原則仍在套用中。
未受管理的暫停	- 在顯示未受管理資料且未啟用任何原則的畫面上，瀏覽至裝置主畫面或其他應用程式，以暫停應用程式。 - 恢復應用程式。 - 確認未套用原則。
受控刪除	- 在顯示受管理資料且原則處於活動狀態的螢幕上，強制終止應用程式。 - 重新啟動應用程式。 - 確認如果應用程式在受管理帳戶資料 (預期) 螢幕上繼續，則仍會套用原則。 如果應用程式在含有未受管理帳戶資料的畫面上繼續顯示，請確認未套用原則。
未受控刪除	- 在顯示未受管理資料且原則處於活動狀態的螢幕上，強制終止應用程式。 - 重新啟動應用程式。 - 確認如果應用程式在未受管理帳戶資料 (預期) 螢幕上繼續，則不會套用原則。 如果應用程式在顯示受管理帳戶資料的畫面上繼續運作，請確認原則仍在套用。
身分識別切換臨機操作	- 嘗試在帳戶之間切換並暫停/恢復/終止/重新啟動應用程式。 - 確認受管理帳戶的資料一律受到保護，而非受管理帳戶的資料永遠不會受到保護。

驗證資料共用案例

您的多重身分識別 App 可能會傳送資料給其他 App，以及從其他 App 接收資料。 Intune 的應用程式保護原則具有指示此行為的設定。 這些測試有助於確保您的多重身分整合符合這些資料共用設定。

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

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

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

案例	步驟
受控識別傳送到未受控應用程式	- 切換至受管理帳戶。 - 前往應用程式可以傳送資料的位置。 - 嘗試將資料傳送至未受管理的應用程式。 - 應該會禁止您將資料傳送至未受管理的應用程式。
受控識別傳送到受控應用程式	- 切換至受管理帳戶。 - 前往應用程式可以傳送資料的位置。 - 嘗試將資料傳送至已登入受管理帳戶的其他受管理 App。 - 您應該能夠將資料傳送至受管理的應用程式。
未受控識別傳送到受控應用程式	- 切換至非受管帳戶。 - 前往應用程式可以傳送資料的位置。 - 嘗試將資料傳送至已登入受管理帳戶的其他受管理 App。 - 您應該被阻止向其他託管應用程式發送資料。
未受控識別傳送到未受控應用程式	- 切換至非受管帳戶。 - 前往應用程式可以傳送資料的位置。 - 嘗試將資料傳送至未受管理的應用程式。 - 您一律可以將未受管理帳戶的資料傳送至未受管理的應用程式。

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

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

案例	步驟
從未受管理應用程式匯入受控識別	- 切換至受管理帳戶。 - 前往您的應用程式可以從其他應用程式匯入資料的位置。 - 嘗試從未受管理的應用程式匯入資料。 - 應該禁止您從未受管理的應用程式匯入資料。
從受控應用程式匯入受控識別	- 切換至受管理帳戶。 - 前往您的應用程式可以從其他應用程式匯入資料的位置。 - 嘗試在已登入受管理帳戶的情況下，從其他受管理的 App 匯入資料。 - 您應該允許從其他託管應用程式匯入資料。
從受管理應用程式匯入未受控身分識別	- 切換至非受管帳戶。 - 前往您的應用程式可以從其他應用程式匯入資料的位置。 - 嘗試在已登入受管理帳戶的情況下，從其他受管理的 App 匯入資料。 - 您應該被阻止從其他託管應用程式匯入資料。
從未受管理應用程式匯入未受控身分識別	- 切換至非受管帳戶。 - 前往您的應用程式可以從其他應用程式匯入資料的位置。 - 嘗試從未受管理的應用程式匯入資料。 - 您一律可以從未受管理帳戶的非受管理應用程式匯入資料。

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

案例	步驟
從未受管理應用程式接收的受控識別	- 切換至受管理帳戶。 - 切換到非託管應用程式。 - 導航到可以傳送資料的位置。 - 嘗試將資料從未受管理的應用程式傳送至您的應用程式。 - 應用程式受管理的帳戶應該無法從未受管理的應用程式接收資料。
從受控應用程式接收的受控識別	- 切換至受管理帳戶。 - 切換至已登入受管理帳戶的其他受管理 App。 - 導航到可以傳送資料的位置。 - 嘗試將資料從託管應用程式傳送至您的應用程式。 - 應用程式的受管理帳戶應該能夠從其他受管理的應用程式接收資料。
從受管理應用程式接收的非受控識別	- 切換至非受管帳戶。 - 切換至已登入受管理帳戶的其他受管理 App。 - 導航到可以傳送資料的位置。 - 嘗試將資料從託管應用程式傳送至您的應用程式。 - 您應用程式的非受控帳戶應該無法從受控應用程式接收資料。
從未受控應用程式接收的非受控識別	- 切換至非受管帳戶。 - 切換到非託管應用程式。 - 導航到可以傳送資料的位置。 - 嘗試將資料從未受管理的應用程式傳送至您的應用程式。 - 應用程式的非受管理帳戶應始終被允許從未受管理的應用程式接收資料。

這些測試的失敗可能表示您的應用程式在嘗試傳送或接收資料時未設定正確的主動身分識別。 您可以在傳送/接收時運用 SDK 的取得身分識別 API 來調查這個問題，以確認使用中身分識別已正確設定。

驗證選擇性抹除案例

您的多重身分識別應用程式可能已補充或覆寫 SDK 的預設抹除行為。 這些測試有助於確保您的多重身分整合在起始抹除時正確移除受管理資料，而不會影響非受管理資料。

警告

提醒，如果您的應用程式運用了 MAMDataProtectionManager.protectForOID，它必須實作其中一個處理WIPE_USER_AUXILIARY_DATAWIPE_USER_DATA常式 或 。

針對這些測試，請安裝您的應用程式和 Intune 公司入口網站;在開始測試之前，請同時使用受管理和非受管理帳戶登入。 針對這兩個帳戶，練習儲存帳戶資料的應用程式案例。

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

後續步驟

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