Intune App SDK Androidhoz – Multi-Identity

Az Androidhoz készült Microsoft Intune App SDK lehetővé teszi, hogy Intune alkalmazásvédelmi szabályzatokat (más néven APP- vagy MAM-szabályzatokat) építsen be a natív Java/Kotlin Android-alkalmazásba. A Intune által felügyelt alkalmazás az Intune App SDK-val integrálva van. Intune rendszergazdák egyszerűen telepíthetnek alkalmazásvédelmi szabályzatokat a Intune által felügyelt alkalmazásra, ha Intune aktívan kezeli az alkalmazást.

Megjegyzés:

Ez az útmutató több különböző szakaszra oszlik. Először tekintse át az 1. fázis: Az integráció megtervezése című szakaszt.

5. fázis: Többszörös identitás

Szakasz Goals

• Állapítsa meg, hogy az alkalmazásnak szüksége van-e több identitás támogatására.
• Ismerje meg, hogyan érzékeli a Intune App SDK az identitásokat.
• Az alkalmazás újrabontása az identitástudatosság érdekében.
• Adjon hozzá kódot, amely tájékoztatja az SDK-t az alkalmazás aktív és változó identitásairól.
• Alaposan tesztelje az alkalmazásvédelmi szabályzatok kikényszerítését mind a felügyelt, mind a nem felügyelt identitások esetében.

Identitás terminológiája

A "user", "account" és "identity" kifejezéseket gyakran felcserélhetően használják. Ez az útmutató az alábbiak szerint próbálja megkülönböztetni a következőket:

• Felhasználó: a szoftverterméket használó személy. Tovább különböztetik meg a végfelhasználót, az Android-alkalmazást használó embert és azIT Prorendszergazdai rendszergazdai / rendszergazdai felhasználót / / , a Microsoft Intune felügyeleti központot használó embert.
• Fiók: egy szervezethez tartozó szoftverrekord, amely egyedileg azonosítja a felhasználó entitását. Egy emberi felhasználó több fiókkal is rendelkezhet.
• Identitás: az Intune App SDK által a fiók egyedi azonosításához használt adatkészlet.

Háttér

Alapértelmezés szerint a Intune App SDK a teljes alkalmazásra alkalmazza a szabályzatot. Miután regisztrált egy fiókot a célzott alkalmazásvédelmi szabályzattal, az SDK minden fájlt és minden tevékenységet társít a fiók identitásához, és általánosan alkalmazza a fiók célzott szabályzatát.

Sok fejlesztő számára ez a kívánt alkalmazásvédelmi viselkedés az alkalmazáshoz. Ezek az alkalmazások egy identitásnak minősülnek. Az előző szakaszok végrehajtásával az alkalmazás sikeresen integrálva lett egy identitásként, és minden alapvető szabályzatot érvényesíthet. Az önálló identitást maradásra szánt alkalmazások kihagyhatják ezt a szakaszt, és továbbléphetnek a 6. szakaszra: App Configuration.

A Intune App SDK igény szerint identitásonként is kikényszerítheti a szabályzatokat. Ha az alkalmazás már támogatja az egyidejűleg bejelentkezett több fiókot, és ezt a többfiókos támogatást alkalmazásvédelmi szabályzatokkal szeretné megőrizni, az alkalmazás több identitásnak minősül.

Tipp

Ha nem világos, hogy az alkalmazásnak támogatnia kell-e az egyszeres identitást vagy a több identitás védelmét, tekintse meg újra Az alkalmazásom egyszeres identitás vagy több identitás? című cikket.

Figyelmeztetés

A többszörös identitás támogatása lényegesen összetettebb, mint a többi alkalmazásvédelmi funkció. A többszörös identitás nem megfelelő integrálása adatszivárgást és egyéb biztonsági problémákat okozhat. Tekintse át alaposan ezt a szakaszt, és tervezze meg a teszteléshez szükséges időt, mielőtt továbblép a következő szakaszra.

"Identitás" az SDK-hoz

Amikor egy SDK-val integrált alkalmazás regisztrál egy fiókot a registerAccountForMAM használatával, az SDK az összes megadott paramétert (upn, aadId, tenantId és authority) identitásként menti. Az SDK identitás api-k többsége azonban a megadott objektumazonosítót (más néven Microsoft Entra ID vagy AAD-azonosítót) használja az identitás azonosítójaként. A MAM SDK API-k identitásként az OID sztringet fogják visszaadni, és az identitáshoz OID sztringparaméterre lesz szükség. Egyes metódusok UPN-sztringet is fogadnak vagy adnak vissza, amely esetben az UPN csak tájékoztatási célokat szolgál.

Az identitásparaméterek nem különböztetik meg a kis- és nagybetűket. Előfordulhat, hogy az identitásra vonatkozó SDK-kérések nem ugyanazt a burkolatot adták vissza, amelyet az identitás regisztrálásakor vagy beállításakor használtak.

Figyelem!

Az olyan elavult metódusokat használó alkalmazások esetében, amelyek UPN-sztringet fogadnak vagy adnak vissza, az alkalmazásoknak meg kell győződniük arról, hogy a különböző API-hívásoknak átadott identitás UPN-sztringje konzisztens. Az inkonzisztens UPN-sztringek átadása adatszivárgást okozhat.

Felügyelt és nem felügyelt identitások

Az Alkalmazásvédelmi szabályzat regisztrálása című szakaszban leírtak szerint az alkalmazás felelős azért, hogy tájékoztassa az SDK-t, amikor egy felhasználó bejelentkezik. A bejelentkezés pillanatában előfordulhat, hogy a felhasználó fiókja alkalmazásvédelmi szabályzattal van megcélzva. Ha a fiók alkalmazásvédelmi szabályzattal van megcélzva, az SDK felügyeltnek tekinti; ellenkező esetben nem lesz kezelve.

Az SDK kikényszeríti a szabályzatot az általa felügyeltnek ítélt identitásokhoz. Az SDK nem kényszerít szabályzatot a nem felügyeltnek ítélt identitásokhoz.

A Intune App SDK jelenleg eszközönként csak egyetlen felügyelt identitást támogat. Amint az SDK-val integrált alkalmazások regisztrálnak egy felügyelt identitást, a rendszer nem felügyeltként kezeli az összes később regisztrált identitást, még akkor is, ha azok jelenleg alkalmazásvédelmi szabályzatokkal vannak megcélzva.

Ha egy felügyelt identitás már regisztrálva van az eszközön, és az alkalmazás egy másik identitást regisztrál, amely szintén az alkalmazásvédelmi szabályzattal van megcélzva, az SDK visszatér MAMEnrollmentManager.Result.WRONG_USER , és megkéri a végfelhasználót a javítási lehetőségekre. További részletekért lásd: Regisztráció az SDK értesítéseihez .

Megjegyzés:

Az alkalmazásvédelmi szabályzattal nem rendelkező fiókokat a rendszer nem felügyeltnek tekinti. Az SDK akkor is rendszeres időközönként ellenőrzi, hogy a fiók licencelése és megcélzása egy későbbi időpontban történik-e. Ha nincs más felügyelt identitás regisztrálva, az SDK elkezdi felügyeltként kezelni ezt az identitást, miután a szabályzattal megcélozták. A felhasználónak nem kell kijelentkeznie, és vissza kell jelentkeznie ebbe a fiókba a módosítás végrehajtásához.

Az aktív identitás

Az alkalmazásnak mindig tájékoztatnia kell az SDK-t az aktuálisan használt identitásról, más néven az aktív identitásról. Az aktív identitás kezelése esetén az SDK védelmet alkalmaz. Ha az aktív identitás nincs felügyelve, az SDK nem alkalmaz védelmet.

Mivel az SDK nem rendelkezik alkalmazásspecifikus tudással, megbízhatónak kell lennie az alkalmazásban a megfelelő aktív identitás megosztásához.

• Ha az alkalmazás helytelenül közli az SDK-val, hogy egy nem felügyelt identitás aktív, amikor a felügyelt identitás ténylegesen használatban van, az SDK nem alkalmaz védelmet. Ez adatszivárgást okozhat, amely veszélyeztetheti a felhasználók adatait.

• Ha az alkalmazás helytelenül közli az SDK-val, hogy a felügyelt identitás aktív, amikor egy nem felügyelt identitás ténylegesen használatban van, akkor az SDK nem megfelelően alkalmazza a védelmet. Ez nem adatszivárgás, de szükségtelenül korlátozhatja a nem felügyelt felhasználókat, és a nem felügyelt felhasználók adatait a törlés kockázatának teheti ki.

Ha az alkalmazás megjelenít egy felhasználó adatait, csak az aktív identitáshoz tartozó adatokat kell megjelenítenie. Ha az alkalmazás jelenleg nem tudja, hogy kié a megjelenített adatok tulajdonosa, előfordulhat, hogy újra kell alakítania az alkalmazást a nagyobb identitástudat érdekében, mielőtt elkezdené integrálni a többszörös identitástámogatást.

Alkalmazásadatok rendszerezése identitás szerint

Amikor az alkalmazás új fájlt ír, az SDK társít egy identitást (más néven "címkéket") a fájlhoz az aktuális aktív szál és folyamatidentitás alapján. Másik lehetőségként az alkalmazás közvetlenül meghívhatja az SDK-t, hogy manuálisan címkézzen fel egy fájlt egy adott identitással (további részletekért lásd: Védett fájlok írása ). Az SDK ezt a címkézett fájlidentitást használja a fájltitkosításhoz és a szelektív törléshez is.

Ha a felügyelt identitás titkosítási szabályzattal van megcélzva, csak a felügyelt identitással címkézett fájlok lesznek titkosítva.

Ha a rendszergazdai művelet vagy a konfigurált házirend kéri, hogy a felügyelt adatok törlődnek, csak a felügyelt identitással címkézett fájlok törlődnek.

Az SDK nem társíthat több identitást egyetlen fájlhoz. Ha az alkalmazás több felhasználóhoz tartozó adatokat tárol ugyanabban a fájlban, az SDK alapértelmezett viselkedése az adatok alulvédett vagy túlzott védelmét eredményezi. Határozottan javasoljuk, hogy az alkalmazás adatait identitás szerint rendezze.

Ha az alkalmazásnak feltétlenül ugyanabban a fájlban kell tárolnia a különböző identitásokhoz tartozó adatokat, az SDK az adatok egy fájlon belüli részhalmazainak identitáscímkézéséhez biztosít funkciókat. További részletekért lásd: Adatpuffer-védelem .

A többszörös identitás implementálása

A többszörös identitás támogatásának deklarálásához először helyezze el a következő metaadatokat AndroidManifest.xml.

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

Az aktív identitás beállítása

Az alkalmazás a következő szinteken állíthatja be az aktív identitást csökkenő prioritással:

1. Szálszint
2. Context (általában Activity) szint
3. Folyamatszint

A szál szintjén beállított identitás felülírja a szinten beállított Context identitást, amely felülírja a folyamat szintjén beállított identitást.

Az a-n Context beállított identitások csak a megfelelő társított forgatókönyvekben használatosak. A fájl I/O-műveletei például nem rendelkeznek társított műveletekkel Context. A leggyakrabban az alkalmazások beállítják az Context identitást a Activitykövetkezőn: . Fontolja meg az identitás beállítását a Context következőben Activity.onCreate: . Egy alkalmazás csak akkor jelenítheti meg az identitás adatait, ha az Activity identitás ugyanarra az identitásra van beállítva.

Általánosságban elmondható, hogy a folyamatszintű identitás csak akkor hasznos, ha az alkalmazás egyszerre csak egyetlen identitással működik az összes szálon. Ez nem jellemző a több fiókot támogató alkalmazások esetében. Határozottan javasoljuk, hogy különítse el a fiókadatokat, és állítsa be az aktív identitást a szálon vagy Context szinteken.

Ha az alkalmazás a környezetet használja a Application rendszerszolgáltatások beszerzéséhez, győződjön meg arról, hogy a szál vagy a folyamat identitása be van állítva, vagy hogy a felhasználói felület identitását az alkalmazás környezetében Application állította be.

Ha az alkalmazás környezettel Service indítja el a szándékokat, tartalomfeloldókat használ, vagy más rendszerszolgáltatásokat használ, mindenképpen állítsa be az identitást a Service környezetben. Hasonlóképpen, ha az alkalmazás környezet használatával JobService hajtja végre ezeket a műveleteket, mindenképpen állítsa be az identitást a környezetben vagy a JobService szálon az JobService implementáció által megkövetelt módon. Ha például egyetlen JobService identitáshoz dolgoz fel feladatokat, fontolja meg az identitás beállítását a JobService környezetben. Ha több JobService identitáshoz dolgoz fel feladatokat, érdemes lehet az identitást a szál szintjén beállítani.

Figyelem!

A használt WorkManager alkalmazásoknak különös figyelmet kell fordítaniuk az identitás beállításakor. Ezeknek az alkalmazásoknak el kell kerülniük, hogy identitást állítsanak be az ContextWorker átadott konstruktoron. Ez a Context példány egyszerre több Worker példány között is megosztható. A nem definiált viselkedés elkerülése érdekében az alkalmazásoknak ehelyett be kell állítaniuk egy szálidentitást Worker.doWork() az Worker implementáció által megkövetelt módon.

Megjegyzés:

Mivel a CLIPBOARD_SERVICE felhasználói felületi műveletekhez használatos, az SDK az előtértevékenység felhasználói felületi identitását használja a műveletekhez ClipboardManager .

A MAMPolicyManager alábbi metódusai használhatók az aktív identitás beállításához és a korábban beállított identitásértékek lekéréséhez.

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

Kényelmesen beállíthatja egy tevékenység identitását közvetlenül a MAMActivity metódusán keresztül a meghívása MAMPolicyManager.setUIPolicyIdentityOIDhelyett. Ehhez használja a következő metódust:

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

Megjegyzés:

Ha az alkalmazás nem deklarált többszörös identitástámogatást a jegyzékfájlban, az identitás beállítására vonatkozó metódusok meghívása nem hajt végre semmilyen műveletet, és ha egy értéket adnak vissza, a mindig a értéket adja visszaMAMIdentitySwitchResultFAILED.

Gyakori identitásváltási buktatók

• A felé irányuló startActivityhívások esetében a Intune App SDK feltételezi, hogy a szinten lévő aktív identitás Context a megadott Intent paraméterhez van társítva. Határozottan javasoljuk, hogy a szint identitását Activityne a Context környezetével, hanem a Applicationkörnyezetével állítsa be.

• Javasoljuk, hogy az identitást a Context tevékenység metódusa onCreate során állítsa be. Ügyeljen azonban arra is, hogy más belépési pontokat is lefedjen, például onNewIntent: . Ellenkező esetben, ha ugyanazt a tevékenységet újra felhasználja a felügyelt és a nem felügyelt identitások adatainak megjelenítéséhez, előfordulhat, hogy a szabályzat helytelenül van alkalmazva, ami nem védett vállalati adatokhoz vagy nem megfelelően korlátozott személyes adatokhoz vezet.

Identitásváltás eredményei

Az identitásjelentés eredményértékeinek MAMIdentitySwitchResult használatával történő beállításához használt összes módszer. Négy érték adható vissza:

Visszatérési érték	Forgatókönyv
SUCCEEDED	Az identitás módosítása sikeres volt.
NOT_ALLOWED	Az identitás módosítása nem engedélyezett. Ez akkor fordul elő, ha megkísérlik beállítani a felhasználói felület (Context) identitását, ha egy másik identitás van beállítva az aktuális szálon.
CANCELLED	A felhasználó megszakította az identitásmódosítást, általában úgy, hogy lenyomja a vissza gombot egy PIN-kódon vagy hitelesítési kérésen.
FAILED	Az identitás módosítása meghatározatlan okból meghiúsult.

Az alkalmazásnak ellenőriznie kell a MAMIdentitySwitchResultSUCCEEDED értékét a felügyelt fiók adatainak megjelenítése vagy használata előtt.

Az aktív identitás beállításának legtöbb módszere szinkron módon adja vissza a MAMIdentitySwitchResult értéket. Ha egy identitást Contexta setUIPolicyIdentityOID használatával állít be, a rendszer aszinkron módon jelenti az eredményt. Az alkalmazás mamSetUIIdentityCallbacket implementálhat az eredmény fogadásához, vagy null értéket adhat át a visszahívási objektumnak. Ha a hívás arra az esetre történiksetUIPolicyIdentityOID, amikor az előző hívás setUIPolicyIdentityOID eredménye még nem lett kézbesítve, Context az új visszahívás felülírja a régit, és az eredeti visszahívás soha nem kap eredményt.

Figyelem!

Ha a ContextsetUIPolicyIdentityOID értéke egy Activity, az SDK nem tudja, hogy az identitás módosítása sikeres volt-e, amíg el nem végzi a rendszergazda által konfigurált feltételes indítási ellenőrzéseket. Előfordulhat, hogy a felhasználónak PIN-kódot vagy vállalati hitelesítő adatokat kell megadnia.

Jelenleg a folyamat- és szálidentitás-kapcsolók mindig sikeresek lesznek a több identitást engedélyező alkalmazások esetében. Az SDK fenntartja a jogot, hogy a jövőben hibafeltételeket adjon hozzá.

A felhasználói felület identitáskapcsolója érvénytelen argumentumok esetén meghiúsulhat, ha ütközne a szál identitásával, vagy ha a felhasználó megszakítja a feltételes indítás követelményeit (például megnyomja a VISSZA gombot a PIN-kód képernyőn).

Egy tevékenység sikertelen felhasználói felületi identitásváltásának alapértelmezett viselkedése a tevékenység befejezése. Ha módosítani szeretné ezt a viselkedést, és értesítéseket szeretne kapni egy tevékenység identitásmódosítási kísérletéről, felülbírálhat egy metódust a rendszerben MAMActivity.

    public void onSwitchMAMIdentityComplete(final MAMIdentitySwitchResult result);

Ha felülírja onSwitchMAMIdentityComplete (vagy meghívja a super metódust), meg kell győződnie arról, hogy a felügyelt fiók adatai nem jelennek meg a sikertelen identitásváltás után.

Megjegyzés:

Az identitásváltáshoz szükség lehet a tevékenység újralétesítésére. Ebben az esetben a onSwitchMAMIdentityComplete visszahívás a tevékenység új példányához lesz kézbesítve.

Identity, Intents és IdentitySwitchOptions

Amellett, hogy automatikusan címkéz új fájlokat az aktív identitással, az SDK az aktív identitással is címkézi a szándékokat . Alapértelmezés szerint az SDK ellenőrzi az identitást egy bejövő szándékon, és összehasonlítja az aktív identitással. Ha ezek az identitások nem egyeznek, az SDK általában (*) identitásváltást kér (további részletekért lásd alább az implicit identitásmódosításokat ).

Az SDK ezt a bejövő szándéki identitást is tárolja későbbi használatra. Amikor az alkalmazás explicit módon módosítja a felhasználói felületi identitást, az SDK összehasonlítja azt az identitást, amelyre az alkalmazás megpróbál váltani a legutóbbi bejövő szándéki identitással. Ha ezek az identitások nem egyeznek, az SDK általában (*) nem tudja végrehajtani az identitásváltást.

Az SDK azért végzi el ezt az ellenőrzést, mert feltételezi, hogy az alkalmazás továbbra is megjeleníti a szándék azon tartalmát, amely a szándékon címkézett identitáshoz tartozik. Ez a feltételezés véd az alkalmazástól, amely akaratlanul kikapcsolja a védelmet a felügyelt adatok megjelenítésekor; ez a feltételezés azonban nem biztos, hogy helyes az alkalmazás tényleges viselkedéséhez.

A választható IdentitySwitchOption enumerálások átadhatók a setUIPolicyIdentityOID és a switchMAMIdentityOID API-knak az SDK alapértelmezett viselkedésének módosításához.

• IGNORE_INTENT: amikor identitásváltást kér a felhasználói felületi rétegben, ez a beállítás arra figyelmezteti az SDK-t, hogy hagyja ki a kért identitásparaméter és a legutóbb tárolt szándék identitásának összehasonlítását. Ez akkor hasznos, ha az alkalmazás már nem jeleníti meg az adott identitáshoz tartozó tartalmat, és az SDK nem tiltja le ezt az identitásváltást. Például:

  1. Az alkalmazás egy dokumentummegjelenítő. Képes renderelni a más alkalmazásokból átadott dokumentumokat. Egy olyan funkciót is tartalmaz, amelyben a felhasználók fiókokat válthatnak. Amikor a felhasználó ezt a fiókváltási funkciót használja, az alkalmazás egy fiókspecifikus kezdőlapra lép a fiók legutóbbi dokumentumaival.
  2. Az alkalmazás megkapja a dokumentum megjelenítésére való szándékot. Ez a szándék a felügyelt identitással van címkézve.
  3. Az alkalmazás át lesz kapcsolva a felügyelt identitásra, és megjeleníti ezt a dokumentumot, megfelelően alkalmazott védelemmel.
  4. A felhasználó a fiókváltóval vált a személyes fiókjára.

  Az alkalmazásnak módosítania kell a felhasználói felület identitását a 4. lépésben. Ebben az esetben, mivel az alkalmazás viselkedése a felügyelt fiók adataiból való navigálás (a szándékban lévő dokumentum), az identitásváltási hívásban kell használnia IGNORE_INTENT . Ez megakadályozza, hogy az SDK helytelenül meghiúsuljon a hívásban.

• DATA_FROM_INTENT: amikor identitásváltást kér a felhasználói felület rétegében, ez a beállítás tájékoztatja az SDK-t arról, hogy a legutóbb tárolt szándéki identitás adatai az identitásváltás sikerességét követően is megjelennek. Ennek eredményeképpen az SDK teljes mértékben kiértékeli a fogadási szabályzatot az előző szándékidentitás alapján annak megállapításához, hogy az megjeleníthető-e. Például:

  1. Az alkalmazás egy dokumentummegjelenítő. Képes renderelni a más alkalmazásokból átadott dokumentumokat. Egy olyan funkciót is tartalmaz, amelyben a felhasználók fiókokat válthatnak. A korábbi példától eltérően, amikor a felhasználó ezt a fiókváltási funkciót használja, az alkalmazás egy megosztott lapra lép, amely az összes fiók legutóbbi dokumentumait jeleníti meg".
  2. Az alkalmazás megkapja a dokumentum megjelenítésére való szándékot. Ez a szándék a felügyelt identitással van címkézve.
  3. Az alkalmazás át lesz kapcsolva a felügyelt identitásra, és megjeleníti ezt a dokumentumot, megfelelően alkalmazott védelemmel.
  4. A felhasználó a fiókváltóval vált a személyes fiókjára.

  Az alkalmazásnak módosítania kell a felhasználói felület identitását a 4. lépésben. Ebben az esetben, mivel az alkalmazás viselkedése az, hogy továbbra is megjeleníti a felügyelt identitás adatait (a dokumentum előnézetét a szándékban), az identitásváltási hívásban kell használnia DATA_FROM_INTENT . Ez tájékoztatja az SDK-t, hogy ellenőrizze a konfigurált alkalmazásvédelmi szabályzatot, és állapítsa meg, hogy megfelelő-e az adatok további megjelenítéséhez.

(*) Az SDK alapértelmezett viselkedése magában foglalja a speciális burkolatot, amely kihagyja ezt az adatbemenő forgalmat annak ellenőrzéséhez, hogy a szándék például ugyanabban az alkalmazásban vagy a rendszerindítóból származik-e.

Az aktív identitás törlése

Előfordulhat, hogy az alkalmazás fiókfüggetlen forgatókönyvekkel rendelkezik. Előfordulhat, hogy az alkalmazás olyan helyi, nem felügyelt forgatókönyvekhez is rendelkezik forgatókönyvekkel, amelyekhez nincs szükség bejelentkezésre. Mindkét esetben előfordulhat, hogy az alkalmazás nem szeretné, hogy az SDK kikényszerítse a felügyelt identitás szabályzatait, de előfordulhat, hogy nem rendelkezik explicit identitással, amelyre váltania kell.

Az aktív identitás törléséhez hívja meg a beállított identitáskezelési módszerek bármelyikét úgy, hogy az identitás OID paramétere értékre nullvan állítva. Ha egy szinten törli az identitást, az SDK az aktív identitást más szinteken is megkeresi, az elsőbbségi sorrend alapján.

Másik lehetőségként üres sztringet adhat át identitásazonosító paraméterként, amely az identitást egy speciális üres értékre állítja, amelyet a rendszer nem felügyelt identitásként kezel. Ha az aktív identitást üres sztringre állítja, az SDK nem kényszerít alkalmazásvédelmi szabályzatot.

Implicit identitásváltozások

A fenti szakasz ismerteti azokat a különböző módszereket, amelyekkel az alkalmazás explicit módon beállíthatja az aktív identitást a szál, a környezet és a folyamat szintjén. Az alkalmazásban lévő aktív identitás azonban anélkül is megváltozhat, hogy az alkalmazás meghívja bármelyik metódust. Ez a szakasz azt ismerteti, hogy az alkalmazás hogyan figyelheti és válaszolhatja meg ezeket az implicit identitásmódosításokat.

Az implicit identitásmódosítások figyelása nem kötelező, de ajánlott. Az SDK soha nem módosítja az aktív identitást az implicit identitásváltozási értesítések megadása nélkül.

Figyelem!

Ha az alkalmazás úgy dönt, hogy nem figyeli az implicit identitásmódosításokat, ügyeljen arra, hogy ne feltételezzük az aktív identitást. Ha kétségei vannak, használja a getCurrentThreadIdentityOID, getUIPolicyIdentityOIDés getProcessIdentityOID metódusokat az aktív identitás megerősítéséhez.

Az implicit identitásváltozások forrásai

• A más Intune által felügyelt alkalmazásokból bejövő adatok megváltoztathatják az aktív identitást a szál és a környezet szintjén.

  • Ha egy tevékenységet egy Intent másik MAM-alkalmazás küldött, a tevékenység identitása a másik alkalmazás aktív identitása alapján lesz beállítva az Intent elküldés időpontjában.

    • Egy Word dokumentum megtekintésére irányuló tevékenység például a Microsoft Outlook egyik szándékából indul ki, amikor egy felhasználó kijelöl egy dokumentummellékletet. Az Office dokumentummegjelenítő tevékenységének identitása az Outlookból az identitásra vált.

  • A szolgáltatások esetében a szál identitása hasonlóképpen lesz beállítva egy onStart vagy onBind hívás időtartamára. A visszaadott onBind fájl hívásai Binder szintén ideiglenesen beállítják a szál identitását.

  • A hívásai ContentProvider hasonlóképpen beállítják a szál identitását az időtartamukhoz.

• A tevékenységekkel folytatott felhasználói interakciók a környezeti szinten módosíthatják az aktív identitást. Például:

  • Ha egy felhasználó kilép egy engedélyezési kérésből a következő időpontban Resume , implicit módon átvált egy üres identitásra.

Implicit identitásmódosítások kezelése

Az alkalmazás opcionálisan figyelheti ezeket az implicit identitásmódosításokat, és reagálhat rájuk. Előfordulhat például, hogy az alkalmazásnak több lépésre van szüksége ahhoz, hogy egy hozzáadott fiók használható legyen, például egy új beérkezett üzeneteket beállító levelezőalkalmazáshoz. Amikor megkísérli az identitásváltást ennek a hiányos fióknak az identitására, az alkalmazás kezelője átirányíthatja a felhasználót a fiókbeállítási tevékenységhez az identitásváltás elfogadása előtt. Másik lehetőségként az alkalmazás kezelője megjeleníthet egy hibaablakot, és letilthatja az identitáskapcsolót.

Az alkalmazás implementálhatja a MAMIdentityRequirementListener felületet egy vagy ContextProvider az Service adott szálra vonatkozó identitásmódosításokhoz. Az implementációnak felül kell bírálnia a következőt:

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

Az alkalmazás implementálhatja a MAMActivityIdentityRequirementListener felületet a Activity tevékenységre vonatkozó identitásmódosításokhoz. Az implementációnak felül kell bírálnia a következőt:

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

Az AppIdentitySwitchReason enumerálási paraméter az implicit identitáskapcsoló forrását írja le.

Enumerálási érték	Alapértelmezett SDK-viselkedés	Leírás
CREATE	Engedélyezze az identitásváltást.	Az identitásváltás egy tevékenység létrehozása miatt történik.
NEW_INTENT	Engedélyezze az identitásváltást.	Az identitásváltás azért történik, mert egy új szándék van hozzárendelve egy tevékenységhez.
RESUME_CANCELLED	Tiltsa le az identitáskapcsolót.	Az identitásváltás egy önéletrajz megszakítása miatt történik. Ez leggyakrabban akkor fordul elő, ha a végfelhasználó lenyomja a VISSZA gombot a PIN-kód, a hitelesítés vagy a megfelelőségi felhasználói felületen.

Az AppIdentitySwitchResultCallback paraméterrel a fejlesztők felülbírálhatják az identitáskapcsoló alapértelmezett viselkedését:

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

onMAMIdentitySwitchRequired A meghívja az összes implicit identitásmódosítást, kivéve azokat, amelyeket a által MAMService.onMAMBindvisszaadott Binderen keresztül hajtottak végre. Az azonnali hívás alapértelmezett implementációi onMAMIdentitySwitchRequired :

• callback.reportIdentitySwitchResult(FAILURE)ha az ok .RESUME_CANCELLED

• callback.reportIdentitySwitchResult(SUCCESS) minden más esetben.

Nem várható, hogy a legtöbb alkalmazásnak más módon kell blokkolnia vagy késleltetnie az identitásváltást, de ha egy alkalmazásnak ezt kell tennie, a következő szempontokat kell figyelembe vennie:

• Ha egy identitásváltás le van tiltva, a végfelhasználói viselkedés ugyanaz, mintha az SDK "más alkalmazásokból származó adatok fogadása" alkalmazásvédelmi beállítása tiltotta volna a bejövő adatokat.

• Ha egy szolgáltatás a fő szálon fut, reportIdentitySwitchResult szinkron módon kell meghívni, vagy a felhasználói felület szála nem válaszol.

• A létrehozáshoz Activity a rendszer az onMAMIdentitySwitchRequired parancsot hívja meg a következő előtt onMAMCreate: . Ha az alkalmazásnak meg kell jelenítenie a felhasználói felületet annak megállapításához, hogy engedélyezi-e az identitásváltást, az adott felhasználói felületet egy másik tevékenységgel kell megjeleníteni.

• ActivityHa az alkalmazásban az üres identitásra való váltást kéri a következő okkalRESUME_CANCELLED: , az alkalmazásnak módosítania kell az újrakezdett tevékenységet, hogy az ezzel az identitásváltással összhangban lévő adatokat jelenítsen meg. Ha ez nem lehetséges, az alkalmazásnak el kell utasítania a váltást, és a rendszer ismét megkéri a felhasználót, hogy feleljen meg a folytatási identitásra vonatkozó szabályzatnak (például az alkalmazás PIN-kódjának beviteli képernyőjével).

Figyelem!

A több identitással rendelkező alkalmazások a felügyelt és a nem felügyelt alkalmazásokból is fogadhatnak bejövő adatokat. Az alkalmazás felelőssége, hogy felügyelt módon kezelje a felügyelt identitásokból származó adatokat.

Ha felügyelt egy kért identitást (az ellenőrzéshez használja a MAMPolicyManager.getIsIdentityOIDManaged parancsot), de az alkalmazás nem tudja használni ezt a fiókot (például mert először be kell állítani a fiókokat, például az e-mail-fiókokat), akkor el kell utasítania az identitásváltást.

A alapértelmezett viselkedése MAMActivity.onMAMIdentitySwitchRequired a statikus metódus MAMActivity.defaultOnMAMIdentitySwitchRequired(activity, upn, oid, reason, callback)meghívásával érhető el.

Hasonlóképpen, ha felül kell bírálnia MAMActivity.onSwitchMAMIdentityCompletea elemet, implementálhatja MAMActivityIdentitySwitchListener anélkül, hogy explicit módon örökölnie kellene a elemet.MAMActivity

Identitáskapcsolók és képernyőkép-korlátozások

A Intune App SDK a jelölő FLAG_SECURE használatával kényszeríti ki a Window képernyőkép-szabályzatot. Egyes alkalmazások saját célokra is beállíthatók FLAG_SECURE . Ha az alkalmazásvédelmi szabályzat nem korlátozza a képernyőképeket, az SDK nem módosítja a következőt FLAG_SECURE: .

Az identitásváltáskor egy olyan identitásról, amelynek szabályzata megköveteli a képernyőképek letiltását egy olyan identitásra, amelynek a szabályzata nem, az SDK törli a következőt FLAG_SECURE: . Ennek eredményeképpen az alkalmazás nem hagyatkozhat az identitásváltás után fennmaradó készletre FLAG_SECURE .

Identitás megőrzése az aszinkron műveletekben

Az alkalmazások gyakran küldenek háttérfeladatokat a felhasználói felületi szálról a más szálakon végzett műveletek kezeléséhez. A több identitást használó alkalmazásoknak biztosítaniuk kell, hogy ezek a háttérfeladatok a megfelelő identitással működjenek, amely gyakran megegyezik az őket küldő tevékenység által használt identitással.

A Intune App SDK a MAMAsyncTask és a MAMIdentityExecutor eszközt biztosítja az identitás aszinkron műveletekben való megőrzéséhez. Az alkalmazásnak ezeket kell használnia (vagy explicit módon be kell állítania a szál identitását a feladatokon), ha az aszinkron műveletei a következőkre képesek:

• Felügyelt identitáshoz tartozó adatok írása fájlba
• Kommunikáció más alkalmazásokkal

MAMAsyncTask

A használatához MAMAsyncTaskegyszerűen örökölje azt a helyettAsyncTask, és cserélje le a és onPreExecutedoInBackgroundMAMonPreExecuteMAM a és a felülbírálását.doInBackground A MAMAsyncTask konstruktor egy tevékenységkörnyezetet vesz igénybe. Például:

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 az aktív identitást a normál elsőbbségi sorrend alapján veszi fel.

MAMIdentityExecutors

MAMIdentityExecutorslehetővé teszi egy meglévő Executor vagy példány identitásmegőrzőként való burkolásátExecutorService/Executor a és wrapExecutorService metódusokkal.wrapExecutorExecutorService Például

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

MAMIdentityExecutors az aktív identitást a normál elsőbbségi sorrend alapján veszi fel.

Fájlvédelem

Védett fájlok írása

Ahogy azt a fenti Alkalmazásadatok identitás szerinti rendszerezése című cikk is említi, a Intune App SDK az aktív identitást (a szál/folyamat szintjén) társítja a fájlokhoz írás közben. Fontos, hogy a megfelelő identitás legyen beállítva a fájl létrehozásakor a megfelelő titkosítás és szelektív törlési funkciók biztosítása érdekében.

Az alkalmazás lekérdezheti vagy módosíthatja egy fájl identitását a MAMFileProtectionManager osztály használatával, különösen MAMFileProtectionManager.getProtectionInfo a lekérdezéshez és MAMFileProtectionManager.protectForOID a módosításhoz.

A protectForOID metódus a könyvtárak védelmére is használható. A címtárvédelem rekurzív módon vonatkozik a könyvtárban található összes fájlra és alkönyvtárra. Ha egy könyvtár védett, a könyvtárban létrehozott összes új fájlra automatikusan ugyanaz a védelem lesz alkalmazva. Mivel a címtárvédelem rekurzív módon van alkalmazva, a protectForOID hívás végrehajtása hosszabb időt vehet igénybe a nagy könyvtárak esetében. Emiatt előfordulhat, hogy a sok fájlt tartalmazó könyvtárra védelmet alkalmazó alkalmazások aszinkron módon szeretnének futni protectForOID egy háttérszálon.

Az identitásparaméter üres sztringjét tartalmazó hívás protectForOID a nem felügyelt identitással címkézi meg a fájlt/könyvtárat. Ez a művelet eltávolítja a titkosítást a fájlból/könyvtárból, ha korábban titkosítva volt. Szelektív törlési parancs kiadásakor a fájl/könyvtár nem törlődik.

Figyelmeztetés

Fontos biztosítani, hogy csak az adott identitáshoz tartozó fájlok legyenek védve ezzel az identitással. Ellenkező esetben más identitások adatvesztést tapasztalhatnak, amikor a tulajdonosi identitás kijelentkezik, mivel a fájlok törlődnek, és a titkosítási kulcshoz való hozzáférés elveszik.

Védett fájltartalom megjelenítése

Ugyanilyen fontos, hogy a fájltartalom megjelenítésekor a megfelelő identitás legyen beállítva, hogy a jogosulatlan felhasználók ne tekinthessék meg a felügyelt adatokat. Az SDK nem tud automatikusan következtetni az éppen beolvasott fájlok és a -ben Activitymegjelenített adatok közötti kapcsolatra. Az alkalmazásoknak megfelelően kell beállítaniuk a felhasználói felületi identitást a felügyelt adatok megjelenítése előtt. Ide tartoznak a fájlokból beolvasott adatok is.

Ha egy fájl az alkalmazáson kívülről származik (nyilvánosan ContentProvider írható helyről vagy olvasott), az alkalmazásnak meg kell próbálnia meghatározni a fájl identitását (az adatforrás megfelelő MAMFileProtectionManager.getProtectionInfo túlterhelésének használatával), mielőtt megjelenítené a fájlból beolvasott információkat.

Ha getProtectionInfo nem null értékű, nem üres identitást jelent, az alkalmazásnak úgy kell beállítania a felhasználói felületi identitást, hogy megfeleljen ennek az identitásnak a MAMActivity.switchMAMIdentityOID vagy a MAMPolicyManager.setUIPolicyIdentityOID használatával. Ha az identitásváltás sikertelen, a fájlból származó adatok nem jeleníthetők meg.

Amikor egy tartalom URI-jából olvas, előfordulhat, hogy először be kell olvasnia az identitást (a getProtectionInfo túlterhelés miatt Uri), majd megfelelően be kell állítania a környezet vagy a szál identitását. Ezt a fájlleíró vagy a bemeneti adatfolyam megnyitása előtt kell elvégezni a ContentResolverfájlon, különben a művelet meghiúsulhat.

Egy példafolyamat az alábbihoz hasonlóan nézhet ki:

• A felhasználó kiválasztja az alkalmazásban megnyitni kívánt dokumentumot.

• A nyitott folyamat során, mielőtt adatokat olvas be a lemezről, az alkalmazás megerősíti a tartalom megjelenítéséhez használandó identitást:

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

• Az alkalmazás megvárja, amíg az eredmény visszahívásra kerül.

• Ha a jelentett eredmény hiba, az alkalmazás nem jeleníti meg a dokumentumot.

• Megnyílik az alkalmazás, és megjeleníti a fájlt.

Ha egy alkalmazás az Android DownloadManager használatával tölti le a fájlokat, az SDK megpróbálja automatikusan védeni ezeket a fájlokat a korábban ismertetett identitásprioritás használatával. A lekéréséhez DownloadManager használt környezet akkor lesz használva, ha a szálidentitás nincs beolvasva. Ha a letöltött fájlok vállalati adatokat tartalmaznak, az alkalmazásnak kell meghívnia a protectForOID függvényt, ha a fájlokat a letöltés után áthelyezi vagy újra létrehozza.

Single-Identity több identitásra váltás

Ha egy korábban önálló identitással Intune integrációval kiadott alkalmazás később integrálja a többszörös identitást, a korábban telepített alkalmazások áttűnést tapasztalnak. Ez az áttűnés nem látható a felhasználó számára.

Az áttűnés kezeléséhez nincs szükség az alkalmazásra. Az áttérés előtt létrehozott fájlok továbbra is felügyeltnek minősülnek (így titkosítva maradnak, ha a titkosítási szabályzat be van kapcsolva).

Ha nem szeretné, hogy az összes korábbi alkalmazásadat a felügyelt identitáshoz legyen társítva, észlelheti ezt az átmenetet, és explicit módon eltávolíthatja a védelmet.

• A frissítés észleléséhez hasonlítsa össze az alkalmazás verzióját egy olyan ismert verzióval, amelyben több identitás támogatása lett hozzáadva.
• Hívja meg protectForOID üres sztringgel az identitásparamétert azon fájlok vagy könyvtárak esetében, amelyeket nem szeretne hozzárendelni a felügyelt identitáshoz.

Offline forgatókönyvek

A Intune App SDK offline módban fut, ha az Céges portál alkalmazás nincs telepítve. A fájl identitáscímkézése érzékeny az offline módra:

• Ha a Céges portál nincs telepítve, a fájlok nem címkézhetők meg identitással. A MAMFileProtectionManager.protectForOID offline módban való meghívása biztonságos, de nincs hatása.

• Ha a Céges portál telepítve van, de az alkalmazás nem rendelkezik alkalmazásvédelmi szabályzattal, a fájlok nem címkézhetők megbízhatóan identitáscímkézettként.

• Amikor elérhetővé válik a fájlidentitás-címkézés, a rendszer az összes korábban létrehozott fájlt személyes/nem felügyeltként kezeli (amely az üres sztringű identitáshoz tartozik), kivéve azokat az eseteket, amikor az alkalmazást korábban egyetlen identitással felügyelt alkalmazásként telepítették, az egyszeri identitásról a több identitásra való áttérésről szóló szakaszban leírtak szerint.

Az ilyen esetek elkerülése érdekében az alkalmazásoknak kerülniük kell a fiókadatokat tartalmazó fájlok létrehozását, amíg a fiókregisztráció sikeresen be nem fejeződik. Ha az alkalmazásnak feltétlenül létre kell hoznia fájlokat offline állapotban, a MAMFileProtectionManager.protectForOID használatával kijavíthatja a fájl társított identitását, amint az SDK online állapotban van.

Adatpuffer-védelem

Figyelmeztetés

Nem ajánlott több fiók adatainak írása egyetlen fájlban. Ha lehetséges, rendezze az alkalmazás fájljait identitás szerint.

Az SDK MAMDataProtectionManager metódusokat biztosít a címkézett identitás ellenőrzéséhez és módosításához adott adatpuffereken vagy byte[]InputStream formátumban.

MAMDataProtectionManager.protectForOID lehetővé teszi, hogy az alkalmazás adatokat társítson egy identitáshoz, és ha az identitás jelenleg titkosítási szabályzattal van megcélzva, titkosítsa az adatokat. Ezek a titkosított adatok alkalmasak lemezen való tárolásra egy fájlban.

MAMDataProtectionManager emellett az identitáshoz társított adatok lekérdezését és titkosításának feloldását is lehetővé teszi.

Azokat az MAMDataProtectionManager alkalmazásokat, amelyek használják, implementálniuk kell egy fogadót az MANAGEMENT_REMOVED értesítéshez. További részletekért lásd: Regisztráció az SDK értesítéseihez .

Az értesítés befejeződése után az ezen osztályon keresztül védett pufferek nem lesznek olvashatók (ha a fájltitkosítás engedélyezve lett a pufferek védelmekor). Az alkalmazások megakadályozhatják, hogy ezek a pufferek olvashatatlanná váljanak, ha MAMDataProtectionManager.unprotect az értesítés kezelésekor meghívja az összes puffert MANAGEMENT_REMOVED . Az értesítés során is biztonságosan hívhat protectForOID , ha meg szeretné őrizni az identitásadatokat. A titkosítás garantáltan le lesz tiltva az értesítés során, és protectForOID a kezelő hívása nem titkosítja az adatpuffereket.

Figyelmeztetés

Az alkalmazásfolyamat korai szakaszában el kell kerülni a titkosítási műveleteket. Az SDK az alkalmazás indítása után a lehető leghamarabb aszinkron módon végzi el a titkosítás inicializálását. Ha azonban egy alkalmazás az alkalmazás indításakor küld titkosítási kérést, előfordulhat, hogy a titkosítás inicializálásának befejezéséig le lesz tiltva.

Megjegyzés:

Az Intune App SDK titkosítási API-t csak az Intune szabályzat által megkövetelt adatok titkosítására szabad használni. A rendszer nem alkalmaz védelmet azokra a fiókokra, amelyeken nincs engedélyezve a titkosítási szabályzat, ezért nem használható általános célú titkosítási kódtárként.

Tartalomszolgáltatók

A több identitást használó alkalmazásoknak az s-eken keresztül ContentProvidermegosztott adatokat is védenie kell, hogy megakadályozzák a felügyelt tartalmak nem megfelelő megosztását.

A tartalom visszaadása előtt az alkalmazásnak meg kell hívnia a statikus MAMContentProvider metódust isProvideContentAllowedForOid(provider, oid) . Ha ez a függvény hamis értéket ad vissza, a tartalmat nem szabad visszaadni a hívónak.

A hívására isProvideContentAllowedForOid nincs szükség, ha a ContentProvider függvényt ParcelFileDescriptorad vissza. A tartalomszolgáltatón keresztül visszaadott fájlleírók kezelése automatikusan történik a fájl identitása alapján.

Szelektív törlés

Alapértelmezés szerint a Intune App SDK automatikusan kezeli a szelektív törléseket, és törli a felügyelt identitáshoz társított összes fájlt. Ezt követően az SDK szabályosan bezárja az alkalmazást, befejezi a tevékenységeket, és leáll az alkalmazásfolyamat.

Az SDK opcionálisan lehetővé teszi az alkalmazás számára, hogy kiegészítse (ajánlott) vagy felülbírálja az alapértelmezett törlési viselkedést.

Az SDK alapértelmezett törléskezelője nem kezeli a által MAMDataProtectionManagervédett adatpuffereket. Ha az alkalmazás használta ezt a funkciót, ki kell egészítenie vagy felül kell bírálnia az alapértelmezett törléskezelőt az adatok eltávolításához.

Megjegyzés:

Az alapértelmezett törlési viselkedés kiegészítéséhez és felülbírálásához adott SDK-értesítéseket kell kezelni. Az értesítéskezelők implementálásával kapcsolatos további részletekért lásd: Regisztráció az SDK értesítéseihez .

Az alapértelmezett törlési viselkedés kiegészítése

Az alapértelmezett SDK-törlési viselkedés kiegészítéséhez az alkalmazás regisztrálhat a WIPE_USER_AUXILIARY_DATAMAMNotificationType típusra.

Ezt az értesítést az SDK az alapértelmezett szelektív törlés végrehajtása előtt küldi el. Az SDK megvárja, amíg az alkalmazás értesítéskezelője befejeződik az adatok törlése és az alkalmazás leállása előtt. Az alkalmazásnak szinkron módon kell törölnie az adatokat, és nem kell visszaadnia, amíg az összes törlés be nem fejeződik.

Az alkalmazásoknak erősen meg kell fontolniuk az alapértelmezett törlési viselkedés kiegészítését a használatával WIPE_USER_AUXILIARY_DATA, mivel a több identitással rendelkező alkalmazások esetében gyakori az alkalmazásspecifikus törlés.

Alapértelmezett törlési viselkedés felülbírálása

Az alapértelmezett SDK-törlési viselkedés felülírásához az alkalmazás regisztrálhat a WIPE_USER_DATAMAMNotificationType típusra.

Figyelmeztetés

Az alkalmazásoknak soha nem szabad regisztrálniuk mind a és WIPE_USER_AUXILIARY_DATAa alkalmazásra.WIPE_USER_DATA

Az alapértelmezett SDK-törlési viselkedés felülírása jelentős kockázatot jelent az alkalmazás számára. Az alkalmazás teljes mértékben felelős a felügyelt identitáshoz társított összes adat eltávolításáért, beleértve az identitáshoz címkézett összes fájlt és adatpuffert.

• Ha a felügyelt identitás titkosítással lett védve, és az alkalmazás egyéni törléskezelője nem távolítja el teljesen az összes felügyelt adatot, a fennmaradó felügyelt fájlok titkosítva maradnak. Ezek az adatok elérhetetlenné válnak, és előfordulhat, hogy az alkalmazás nem kezeli a titkosított adatok szabályos olvasására tett kísérleteket.
• Az alkalmazás törléskezelője adatvesztést okozhat a nem felügyelt felhasználók számára, ha eltávolítja a felügyelt identitással nem címkézett fájlokat.

Ha az alkalmazás egyéni törléskezelője eltávolítja a kezelt adatokat egy fájlból, de más adatokat szeretne a fájlban hagyni, módosítania kell a fájl identitását ( a MAMFileProtectionManager.protectForOID segítségével) nem felügyelt identitásra vagy üres sztringre.

A felülbírált törléskezelőnek szinkron módon kell törölnie az adatokat, és nem kell visszatérnie, amíg az összes törlés be nem fejeződik.

Fontolja meg az alkalmazás manuális bezárását az egyéni törléskezelő lépéseinek elvégzése után, hogy a felhasználó ne férhessen hozzá a memóriában tárolt adatokhoz a törlés után.

Kilépési feltételek

Tervezze meg, hogy jelentős időt szán az alkalmazás több identitással való integrációjának érvényesítésére. A tesztelés megkezdése előtt:

• Alkalmazásvédelmi szabályzat létrehozása és hozzárendelése egy fiókhoz. Ez lesz a teszt által felügyelt fiók.
• Hozzon létre egy másik fiókot, de ne rendeljen hozzá alkalmazásvédelmi szabályzatot. Ez lesz a teszt nem felügyelt fiókja. Ha az alkalmazás Microsoft Entra fiókokon kívül több fióktípust is támogat, használhat nem felügyelt tesztfiókként egy meglévő nem Entra-fiókot is.
• Ismerkedjen meg a szabályzat alkalmazáson belüli érvényre juttatásának módjával. A többszörös identitásteszteléshez könnyen meg kell különböztetnie, hogy az alkalmazás mikor van érvényben, és nem a szabályzat kikényszerítésével működik. A képernyőképek letiltására szolgáló alkalmazásvédelmi házirend-beállítás hatékony a szabályzatkényszerítés gyors teszteléséhez.
• Vegye figyelembe az alkalmazás által kínált felhasználói felület teljes készletét. Számba veszi azokat a képernyőket, ahol a fiókadatok megjelennek. Az alkalmazás csak egyetlen fiók adatait jeleníti meg egyszerre, vagy egyszerre több fiókhoz tartozó adatokat is megjeleníthet?
• Vegye figyelembe az alkalmazás által létrehozott fájlok teljes készletét. Enumerálja, hogy ezen fájlok közül melyik tartalmaz fiókhoz tartozó adatokat a rendszerszintű adatok helyett.
  • Határozza meg, hogyan fogja ellenőrizni az egyes fájlok titkosítását.
• Vegye figyelembe, hogy az alkalmazás milyen módon kommunikálhat más alkalmazásokkal. Az összes bejövő és kimenő pont számbavétele. Milyen típusú adatokat tud az alkalmazás betölteni? Milyen szándékokat közvetít? Milyen tartalomszolgáltatókat implementál?
  • Határozza meg, hogyan fogja használni ezeket az adatmegosztási funkciókat.
  • Készítsen elő egy olyan teszteszközt, amely felügyelt és nem felügyelt alkalmazásokkal is rendelkezik, amelyek képesek együttműködni az alkalmazással.
• Gondolja át, hogy az alkalmazás hogyan teszi lehetővé a végfelhasználó számára az összes bejelentkezett fiók használatát. A felhasználónak manuálisan kell váltania egy fiókra a fiók adatainak megjelenítése előtt?

Miután alaposan felmérte az alkalmazás aktuális viselkedését, ellenőrizze a több identitás integrációját az alábbi tesztek végrehajtásával. Vegye figyelembe, hogy ez nem egy átfogó lista, és nem garantálja, hogy az alkalmazás többszörös identitású implementációja hibamentes.

Bejelentkezési és kijelentkezési forgatókönyvek ellenőrzése

A több identitással rendelkező alkalmazás legfeljebb 1 felügyelt fiókot és több nem felügyelt fiókot támogat. Ezek a tesztek segítenek biztosítani, hogy a többszörös identitás integrációja ne módosítsa helytelenül a védelmet a felhasználók bejelentkezésekor vagy kijelentkezésekor.

Ezekhez a tesztekhez telepítse az alkalmazást és a Intune Céges portál; ne jelentkezzen be a teszt megkezdése előtt.

Forgatókönyv	Utaslépcső
Először jelentkezzen be felügyeltként	– Először jelentkezzen be egy felügyelt fiókkal, és ellenőrizze, hogy a fiók adatai kezelhetők-e. – Jelentkezzen be egy nem felügyelt fiókkal, és ellenőrizze, hogy a fiók adatai nincsenek-e kezelve.
Először jelentkezzen be nem felügyelt módon	– Először jelentkezzen be egy nem felügyelt fiókkal, és ellenőrizze, hogy a fiók adatai nincsenek-e kezelve. – Jelentkezzen be egy felügyelt fiókkal, és ellenőrizze, hogy a fiók adatainak kezelése megtörtént-e.
Több felügyelt bejelentkezés	– Először jelentkezzen be egy felügyelt fiókkal, és ellenőrizze, hogy a fiók adatai kezelhetők-e. – Jelentkezzen be egy második felügyelt fiókkal, és ellenőrizze, hogy a felhasználó nem jelentkezik-e be az eredeti felügyelt fiók eltávolítása nélkül.
Felügyelt kijelentkezés	– Jelentkezzen be az alkalmazásba egy felügyelt, nem felügyelt fiókkal. – Jelentkezzen ki a felügyelt fiókból. – Győződjön meg arról, hogy a felügyelt fiók el lett távolítva az alkalmazásból, és a fiók összes adata el lett távolítva. – Győződjön meg arról, hogy a nem felügyelt fiók továbbra is be van jelentkezve, a nem felügyelt fiók adatainak egyike sem lett eltávolítva, és a szabályzat még mindig nincs alkalmazva.
Nem felügyelt kijelentkezés	– Jelentkezzen be az alkalmazásba egy felügyelt, nem felügyelt fiókkal. – Jelentkezzen ki a nem felügyelt fiókból. – Győződjön meg arról, hogy a nem felügyelt fiók el lett távolítva az alkalmazásból, és a fiók összes adata el lett távolítva. – Győződjön meg arról, hogy a felügyelt fiók továbbra is be van jelentkezve, a nem felügyelt fiók adatainak egyike sem lett eltávolítva, és a szabályzat továbbra is érvényben van.

Az aktív identitás és az alkalmazás életciklusának ellenőrzése

A több identitást használó alkalmazás megjeleníthet nézeteket egyetlen fiók adataival, és lehetővé teheti a felhasználó számára, hogy explicit módon módosítsa az aktuális használatban lévő fiókot. Egyszerre több fiók adatait tartalmazó nézeteket is megjeleníthet. Ezek a tesztek segítenek biztosítani, hogy a többszörös identitásintegráció megfelelő védelmet biztosítson az aktív identitás számára az alkalmazás teljes életciklusa során minden oldalon.

Ezekhez a tesztekhez telepítse az alkalmazást és a Intune Céges portál; a teszt megkezdése előtt jelentkezzen be egy felügyelt és nem felügyelt fiókkal is.

Forgatókönyv	Utaslépcső
Egyfiókos nézet, felügyelt	– Váltson a felügyelt fiókra. – Navigáljon az alkalmazás összes olyan lapjára, amely egyetlen fiók adatait jeleníti meg. – Győződjön meg arról, hogy a szabályzat minden oldalon alkalmazva van.
Egyfiókos nézet, nem felügyelt	– Váltson a nem felügyelt fiókra. – Navigáljon az alkalmazás összes olyan lapjára, amely egyetlen fiók adatait jeleníti meg. – Győződjön meg arról, hogy a szabályzat nincs alkalmazva egyik oldalon sem.
Többfiókos nézet	– Navigáljon az alkalmazás összes olyan lapjához, amely egyszerre több fiók adatait jeleníti meg. – Győződjön meg arról, hogy a szabályzat minden oldalon alkalmazva van.
Felügyelt szüneteltetés	– A megjelenített felügyelt adatokat és aktív szabályzatot tartalmazó képernyőn az eszköz kezdőképernyőjére vagy egy másik alkalmazásra lépve szüneteltetheti az alkalmazást. – Folytassa az alkalmazást. – Győződjön meg arról, hogy a szabályzat továbbra is érvényben van.
Nem felügyelt szüneteltetés	– Olyan képernyőn, amelyen nem felügyelt adatok jelennek meg, és nincsenek aktív szabályzatok, az eszköz kezdőképernyőjére vagy egy másik alkalmazásra lépve szüneteltetheti az alkalmazást. – Folytassa az alkalmazást. – Győződjön meg arról, hogy a szabályzat nincs alkalmazva.
Felügyelt leölés	– A megjelenített felügyelt adatokkal és aktív szabályzattal rendelkező képernyőn kényszerítse ki az alkalmazást. – Indítsa újra az alkalmazást. – Győződjön meg arról, hogy ha az alkalmazás a felügyelt fiók adataival (várt) egy képernyőn folytatódik, a szabályzat továbbra is érvényben lesz. Ha az alkalmazás a nem felügyelt fiók adataival folytatódik egy képernyőn, győződjön meg arról, hogy a szabályzat nincs alkalmazva.
Nem felügyelt gyilkosság	– Egy képernyőn, amelyen nem felügyelt adatok jelennek meg, és a szabályzat aktív, kényszerítse az alkalmazás leállítását. – Indítsa újra az alkalmazást. – Győződjön meg arról, hogy ha az alkalmazás a nem felügyelt fiók adataival (várt) folytatódik a képernyőn, a szabályzat nem lesz alkalmazva. Ha az alkalmazás a felügyelt fiók adatait tartalmazó képernyőn folytatódik, ellenőrizze, hogy a szabályzat továbbra is érvényben van-e.
Identitásváltás ad hoc	– Kísérletezzen a fiókok közötti váltással és az alkalmazás szüneteltetésével/folytatásával/leállásával/újraindításával. – Győződjön meg arról, hogy a felügyelt fiók adatai mindig védettek, és a nem felügyelt fiók adatai soha nem védettek.

Adatmegosztási forgatókönyvek ellenőrzése

A többszörös identitású alkalmazás adatokat küldhet az alkalmazásnak, és adatokat fogadhat más alkalmazásokból. Intune alkalmazásvédelmi szabályzatai olyan beállításokkal rendelkeznek, amelyek meghatározzák ezt a viselkedést. Ezek a tesztek segítenek biztosítani, hogy a többszörös identitás integrációja figyelembe veszi ezeket az adatmegosztási beállításokat.

Ezekhez a tesztekhez telepítse az alkalmazást és a Intune Céges portál; a teszt megkezdése előtt jelentkezzen be egy felügyelt és nem felügyelt fiókkal is. Továbbá:

• Állítsa be a felügyelt fiók szabályzatát a következőként:
  • "Szervezeti adatok küldése más alkalmazásoknak" a szabályzattal felügyelt alkalmazásoknak.
  • "Adatok fogadása más alkalmazásokból" a szabályzattal felügyelt alkalmazásokba.
• Telepítsen más alkalmazásokat a teszteszközre:
  • Az alkalmazással azonos szabályzattal rendelkező felügyelt alkalmazás, amely képes adatokat küldeni és fogadni (például a Microsoft Outlookot).
  • Bármely nem felügyelt alkalmazás, amely képes adatokat küldeni és fogadni.
• Jelentkezzen be a másik felügyelt alkalmazásba a felügyelt tesztfiókkal. Még akkor is, ha a másik felügyelt alkalmazás több identitású, csak a felügyelt fiókkal jelentkezzen be.

Ha az alkalmazás képes adatokat küldeni más alkalmazásoknak, például a Microsoft Outlooknak, amely dokumentummellékletet küld a Microsoft Office-nak:

Forgatókönyv	Utaslépcső
Felügyelt identitás küldése nem felügyelt alkalmazásba	– Váltson a felügyelt fiókra. – Navigáljon arra a helyre, ahová az alkalmazás adatokat küldhet. – Nem felügyelt alkalmazásnak kísérel meg adatokat küldeni. – Le kell tiltani, hogy adatokat küldjön a nem felügyelt alkalmazásnak.
Felügyelt identitás küldése felügyelt alkalmazásba	– Váltson a felügyelt fiókra. – Navigáljon arra a helyre, ahová az alkalmazás adatokat küldhet. – Próbáljon meg adatokat küldeni a másik felügyelt alkalmazásnak a bejelentkezett felügyelt fiókkal. – Lehetővé kell tenni, hogy adatokat küldjön a felügyelt alkalmazásnak.
Nem felügyelt identitás küldése felügyelt alkalmazásba	– Váltson a nem felügyelt fiókra. – Navigáljon arra a helyre, ahová az alkalmazás adatokat küldhet. – Próbáljon meg adatokat küldeni a másik felügyelt alkalmazásnak a bejelentkezett felügyelt fiókkal. – Le kell tiltani, hogy adatokat küldjön a másik felügyelt alkalmazásnak.
Nem felügyelt identitás küldése nem felügyelt alkalmazásba	– Váltson a nem felügyelt fiókra. – Navigáljon arra a helyre, ahová az alkalmazás adatokat küldhet. – Nem felügyelt alkalmazásnak kísérel meg adatokat küldeni. – Mindig engedélyezni kell, hogy egy nem felügyelt fiók adatait elküldje egy nem felügyelt alkalmazásnak.

Az alkalmazás aktívan importálhat adatokat más alkalmazásokból, például a Microsoft Outlookból, amely egy fájlt csatol a Microsoft OneDrive-ról. Előfordulhat, hogy az alkalmazás passzívan fogad adatokat más alkalmazásokból, például a Microsoft Office-ból, amely megnyit egy dokumentumot egy Microsoft Outlook-mellékletből. A fogadási alkalmazásvédelmi szabályzat beállítása mindkét forgatókönyvet lefedi.

Ha az alkalmazás képes aktívan adatokat importálni más alkalmazásokból:

Forgatókönyv	Utaslépcső
Felügyelt identitás importálása nem felügyelt alkalmazásból	– Váltson a felügyelt fiókra. – Navigáljon oda, ahol az alkalmazás adatokat importálhat más alkalmazásokból. – Adatok importálása nem felügyelt alkalmazásból. – Le kell tiltani az adatok nem felügyelt alkalmazásokból való importálását.
Felügyelt identitás importálása felügyelt alkalmazásból	– Váltson a felügyelt fiókra. – Navigáljon oda, ahol az alkalmazás adatokat importálhat más alkalmazásokból. – Próbáljon meg adatokat importálni a másik felügyelt alkalmazásból a bejelentkezett felügyelt fiókkal. – Engedélyezni kell az adatok importálását a másik felügyelt alkalmazásból.
Nem felügyelt identitás importálása felügyelt alkalmazásból	– Váltson a nem felügyelt fiókra. – Navigáljon oda, ahol az alkalmazás adatokat importálhat más alkalmazásokból. – Próbáljon meg adatokat importálni a másik felügyelt alkalmazásból a bejelentkezett felügyelt fiókkal. – Le kell tiltani az adatok importálását a másik felügyelt alkalmazásból.
Nem felügyelt identitás importálása nem felügyelt alkalmazásból	– Váltson a nem felügyelt fiókra. – Navigáljon oda, ahol az alkalmazás adatokat importálhat más alkalmazásokból. – Adatok importálása nem felügyelt alkalmazásból. – Mindig engedélyezni kell, hogy adatokat importáljon nem felügyelt alkalmazásból egy nem felügyelt fiókhoz.

Ha az alkalmazás képes passzívan adatokat fogadni más alkalmazásokból:

Forgatókönyv	Utaslépcső
Felügyelt identitás fogadása nem felügyelt alkalmazásból	– Váltson a felügyelt fiókra. – Váltson a nem felügyelt alkalmazásra. – Navigáljon arra a helyre, ahová adatokat küldhet. – Próbáljon meg adatokat küldeni a nem felügyelt alkalmazásból az alkalmazásnak. – Az alkalmazás felügyelt fiókjának nem szabad tudnia adatokat fogadni a nem felügyelt alkalmazásból.
Felügyelt identitás fogadása felügyelt alkalmazásból	– Váltson a felügyelt fiókra. – Váltson a másik felügyelt alkalmazásra a bejelentkezett felügyelt fiókkal. – Navigáljon arra a helyre, ahová adatokat küldhet. – Próbáljon meg adatokat küldeni a felügyelt alkalmazásból az alkalmazásnak. – Engedélyezni kell az alkalmazás felügyelt fiókjának, hogy adatokat fogadjon a másik felügyelt alkalmazástól.
Felügyelt alkalmazásból érkező nem felügyelt identitás	– Váltson a nem felügyelt fiókra. – Váltson a másik felügyelt alkalmazásra a bejelentkezett felügyelt fiókkal. – Navigáljon arra a helyre, ahová adatokat küldhet. – Próbáljon meg adatokat küldeni a felügyelt alkalmazásból az alkalmazásnak. – Az alkalmazás nem felügyelt fiókjának nem kell tudnia adatokat fogadni a felügyelt alkalmazásból.
Nem felügyelt identitások fogadása nem felügyelt alkalmazásból	– Váltson a nem felügyelt fiókra. – Váltson a nem felügyelt alkalmazásra. – Navigáljon arra a helyre, ahová adatokat küldhet. – Próbáljon meg adatokat küldeni a nem felügyelt alkalmazásból az alkalmazásnak. – Az alkalmazás nem felügyelt fiókjának mindig engedélyezni kell az adatok fogadását a nem felügyelt alkalmazástól.

A tesztek hibái azt jelezhetik, hogy az alkalmazás nem rendelkezik a megfelelő aktív identitással, amikor adatokat próbál küldeni vagy fogadni. Ezt úgy vizsgálhatja meg, hogy az SDK get identity API-jait a küldés/fogadás időpontjában felhasználja annak ellenőrzéséhez, hogy az aktív identitás megfelelően van-e beállítva.

Szelektív törlési forgatókönyvek ellenőrzése

Előfordulhat, hogy a több identitást tartalmazó alkalmazás kiegészítette vagy felülírta az SDK alapértelmezett törlési viselkedését. Ezek a tesztek segítenek biztosítani, hogy a többszörös identitás integrációja megfelelően eltávolítsa a felügyelt adatokat a törlés kezdeményezésekor anélkül, hogy ez hatással lenne a nem felügyelt adatokra.

Figyelmeztetés

Ne feledje, hogy ha az alkalmazás kihasználta MAMDataProtectionManager.protectForOIDa elemet, egy kezelőt kell implementálnia a WIPE_USER_AUXILIARY_DATA vagy WIPE_USER_DATAa számára.

Ezekhez a tesztekhez telepítse az alkalmazást és a Intune Céges portál; a teszt megkezdése előtt jelentkezzen be egy felügyelt és nem felügyelt fiókkal is. Mindkét fiók esetében a fiókadatokat tároló alkalmazásforgatókönyvek használata.

Forgatókönyv	Előfeltételek	Utaslépcső
Kiegészítő törléskezelő	Az alkalmazás implementált egy kezelőt a következőhöz: WIPE_USER_AUXILIARY_DATA	- Szelektív törlést adhat ki a Microsoft Intune Felügyeleti központból. – Erősítse meg (általában naplózással), hogy a törléskezelő sikeresen végrehajtotta-e a törlendő adatokat. – Győződjön meg arról, hogy a felügyelt fiók el lett távolítva az alkalmazásból, és a fiók összes adata el lett távolítva. – Győződjön meg arról, hogy a nem felügyelt fiók továbbra is be van jelentkezve, a nem felügyelt fiók adatainak egyike sem lett eltávolítva, és a szabályzat még mindig nincs alkalmazva.
Felülbírált törléskezelő	Az alkalmazás implementált egy kezelőt a következőhöz: WIPE_USER_DATA	- Szelektív törlést adhat ki a Microsoft Intune Felügyeleti központból. – Erősítse meg (általában naplózással), hogy a törléskezelő sikeresen végrehajtotta-e a törlendő adatokat. – Győződjön meg arról, hogy a felügyelt fiók el lett távolítva az alkalmazásból, és a fiók összes adata el lett távolítva. – Győződjön meg arról, hogy a nem felügyelt fiók továbbra is be van jelentkezve, a nem felügyelt fiók adatainak egyike sem lett eltávolítva, és a szabályzat még mindig nincs alkalmazva. – Győződjön meg arról, hogy az alkalmazás szabályosan kilépett, vagy a törléskezelő befejezése után is kifogástalan állapotban van.
Manuális fájlvédelem	– Alkalmazáshívások MAMFileProtectionManager.protectForOID – Az alkalmazás implementált egy kezelőt a következőhöz: WIPE_USER_DATA	– Győződjön meg arról, hogy olyan forgatókönyveket használt, amelyekben az alkalmazás manuálisan védené a felügyelt fiókhoz tartozó legalább egy fájlt. - Szelektív törlést adhat ki a Microsoft Intune Felügyeleti központból. – Győződjön meg arról, hogy a fájlok el lettek távolítva.
Manuális adatpuffer-védelem	– Alkalmazáshívások MAMDataProtectionManager.protectForOID – Az alkalmazás egy kezelőt implementált a vagy a WIPE_USER_AUXILIARY_DATAWIPE_USER_DATA	– Győződjön meg arról, hogy olyan forgatókönyveket használt, amelyekben az alkalmazás manuálisan védené a felügyelt fiókhoz tartozó legalább egy adatpuffert. - Szelektív törlést adhat ki a Microsoft Intune Felügyeleti központból. – Győződjön meg arról, hogy az adatpufferek el lettek távolítva a tárolt fájlokból, és az alkalmazás továbbra is be tudja olvasni a nem felügyelt adatokat ezekből a fájlokból.

Következő lépések

Miután elvégezte a fenti kilépési feltételeket , az alkalmazás sikeresen integrálva lesz több identitásként, és identitásonként érvényesítheti az alkalmazásvédelmi szabályzatokat. A következő szakaszok, 6. fázis: App Configuration és 7. fázis: Az alkalmazás részvételi funkciói, az alkalmazás kívánt alkalmazásvédelmi szabályzatának támogatásától függően szükség lehet rá. Ha nem biztos abban, hogy ezek a szakaszok érvényesek-e az alkalmazásra, tekintse meg újra az SDK-integrációval kapcsolatos legfontosabb döntéseket.