Intune App SDK Androidhoz – Multi-Identity

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

Megjegyzés:

Ez az útmutató több különálló szakaszra oszlik. Első lépésként tekintse át az 1. szakaszt: Az integráció megtervezése.

5. szakasz: Többszörös identitás

Szakasz céljai

• Állapítsa meg, hogy az alkalmazásnak szüksége van-e többidentitásos támogatásra.
• Ismerje meg, hogy az Intune App SDK hogyan érzékeli az identitásokat.
• Dolgozza át az alkalmazást az identitástudatosság érdekében.
• Kód hozzáadásával tájékoztathatja az SDK-t az aktív és változó identitásokról az alkalmazásban.
• Alaposan tesztelheti az alkalmazásvédelmi szabályzat kényszerítését a felügyelt és a nem felügyelt identitásokra is.

Identitással kapcsolatos terminológia

A "felhasználó", a "fiók" és az "identitás" kifejezéseket gyakran ugyanolyan értelemben használják. Ez az útmutató az alábbiak szerint próbál megkülönböztetni:

• Felhasználó: a szoftverterméket használó személy. Emellett a végfelhasználó, az Android-alkalmazást használó ember és a rendszergazdai / rendszergazda informatikai / rendszergazda / ITPro, a Microsoft Intune Felügyeleti központot használó ember pedig megkülönböztethető.
• Ügyfél: a szervezethez tartozó szoftverrekord, amely egyedileg azonosítja a felhasználó entitását. Egy felhasználónak több fiókja is lehet.
• 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 az Intune App SDK a teljes alkalmazásra alkalmazza a szabályzatot. Miután regisztrált egy fiókot az alkalmazásvédelmi házirend megcélzásával, az SDK minden fájlt és tevékenységet az adott fiók identitásához társít, és univerzálisan alkalmazza a fiók célzott házirendjét.

Sok fejlesztő számára ez a kívánt alkalmazásvédelmi viselkedés. Ezek az alkalmazások egyetlen identitásnak minősülnek. Az előző lépések végrehajtásával az alkalmazás sikeresen integrálódott egyetlen identitásként, és képes az összes alapvető házirend kényszerítésére. Az egyetlen identitásra szánt alkalmazások kihagyhatják ezt a szakaszt, és továbbléphetnek a 6. szakaszra: App Configuration.

Az Intune App SDK igény szerint identitásonkénti szinten is kényszerítheti a szabályzatot. Ha az alkalmazás már támogatja egyszerre több bejelentkezett fiókot, és ezt a többfiókos támogatást alkalmazásvédelmi szabályzatokkal szeretné megőrizni, az alkalmazás többidentitásosnak minősül.

Tipp

Ha nem biztos abban, hogy az alkalmazásnak támogatnia kell-e az egy- vagy többidentitásos védelmet, tekintse át ismét Az alkalmazásom egy- vagy többidentitású?

Figyelmeztetés

A többidentitá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áshoz és más biztonsági problémákhoz vezethet. Alaposan tekintse át ezt a szakaszt, és tervezzen elegendő időt a tesztelésre, mielőtt továbblépne a következő szakaszra.

"Identity" az SDK számára

Amikor egy SDK-ba 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) menti identitásként. Az SDK identitás API-jainak többsége azonban a megadott OID-t (más néven Microsoft Entra ID vagy AAD ID) használja az identitás azonosítójaként. A MAM SD API-k identitásként visszaadják az OID karakterláncot, és megkövetelik az OID karakterlánc paramétert az identitáshoz. Egyes módszerek egyszerű felhasználónévi karakterláncot is felvesznek vagy visszaadnak, amely esetben az egyszerű felhasználónév 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 SDK-nak az identitásra vonatkozó kérések nem ugyanazt a kis- és nagybetűket adják vissza, mint amelyet az identitás regisztrálásakor vagy beállításakor használtak.

Figyelem!

Az elavult metódusokat használó, egyszerű felhasználónévi sztringet felvevő vagy visszaadott alkalmazások esetében az alkalmazásoknak biztosítaniuk kell, hogy a különböző API-hívásoknak átadott identitás-UPN-sztring konzisztens legyen. Az inkonzisztens UPN-karakterláncok átadása adatszivárgást okozhat.

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

Az alkalmazásvédelmi szabályzatra való regisztrációban leírtak szerint az alkalmazás felelős az SDK tájékoztatásáért, amikor egy felhasználó bejelentkezik. A bejelentkezés pillanatában előfordulhat, hogy a felhasználó fiókját az alkalmazásvédelmi házirend célozza meg, vagy nem. Ha a fiókot alkalmazásvédelmi szabályzat célozza meg, az SDK kezeltnek tekinti; Ellenkező esetben nem lesz felügyelve.

Az SDK kényszeríti a szabályzatokat az általa felügyeltnek tekintett identitásokra. Az SDK nem érvényesíti a házirendet a nem felügyeltnek tartott identitásokra.

Az Intune App SDK jelenleg eszközönként csak egyetlen felügyelt identitást támogat. Amint egy SDK-ba integrált alkalmazás regisztrál egy felügyelt identitást, a rendszer az összes később regisztrált identitást kezeletlenként kezeli, még akkor is, ha jelenleg alkalmazásvédelmi szabályzatok célozzák meg őket.

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, amelyet szintén az alkalmazásvédelmi szabályzat céloz meg, az SDK visszatér, MAMEnrollmentManager.Result.WRONG_USER és megkérdezi a végfelhasználót, hogy adja meg a szervizelési lehetőségeket. További részletekért lásd: Regisztráció az SDK értesítéseire .

Megjegyzés:

Azok a fiókok, amelyek nem szerepelnek alkalmazásvédelmi házirend alatt a regisztrációkor, nem kezeltnek minősülnek. Még ha a fiók nem is rendelkezik licenccel vagy nem vonatkozik alkalmazásvédelmi házirendre, az SDK rendszeres időközönként ellenőrzi, hogy a fiók licenceltté és célzottá válik-e a későbbiekben. Ha nincs más felügyelt identitás regisztrálva, az SDK ezt az identitást felügyeltként kezdi kezelni, miután a szabályzat megcélozta. A felhasználónak nem kell kijelentkeznie, majd újra bejelentkeznie ebbe a fiókba a módosítás elvégzéséhez.

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. Ha az aktív identitás felügyelve van, 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 ismeretekkel, megbízhatónak kell lennie az alkalmazásban a megfelelő aktív identitás megosztásában.

• 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, ami veszélyezteti 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 valójában egy nem felügyelt identitás van használatban, akkor az SDK nem megfelelően alkalmazza a védelmet. Ez nem adatszivárgás, de szükségtelenül korlátozhatja a felügyelet nélküli felhasználók számát, és veszélyeztetheti a nem felügyelt felhasználók adatai törlésének kockázatát.

Ha az alkalmazás felhasználói adatokat jelenít meg, csak az aktív identitáshoz tartozó adatokat jelenítheti meg. Ha az alkalmazás jelenleg nem ismeri, hogy ki a megjelenített adatok tulajdonosa, előfordulhat, hogy a többidentitás-támogatás integrálása előtt át kell dolgoznia az alkalmazást a nagyobb identitástudatosság érdekében.

Alkalmazásadatok rendszerezése identitás szerint

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

Ha a felügyelt identitást titkosítási házirend célozza meg, csak a felügyelt identitással címkézett fájlok lesznek titkosítva.

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

Az SDK nem tud több identitást egyetlen fájlhoz társítani. 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 alul- vagy túlvédelmét eredményezi. Határozottan javasoljuk, hogy az alkalmazás adatait identitás szerint rendszerezze.

Ha az alkalmazásnak feltétlenül különböző identitásokhoz tartozó adatokat kell ugyanabban a fájlban tárolnia, az SDK olyan funkciókat biztosít, amelyekkel identitáscímkével láthatja el a fájlon belüli adatok részhalmazát. Részletes információkért olvassa el az Adatpuffer elleni védelem című részt.

Többszörös identitás implementálása

Ha deklarálni szeretné az alkalmazás többidentitásos támogatását, először helyezze el a következő metaadatokat a 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ő csökkenő prioritási szinteken állíthatja be az aktív identitást:

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

A szál szintjén beállított identitáskészletek felülírják a szinten beállított identitáskészleteket Context , amelyek felülírnak egy folyamat szintű identitáskészletet.

Az identitáskészlet Context csak a megfelelő társított forgatókönyvekben használatos. A fájl I/O műveletei például nem rendelkeznek társított Context. Az alkalmazások Context általában egy Activity. Érdemes az identitást a következőre állítani: ContextActivity.onCreate. Az alkalmazások csak akkor jeleníthetnek meg identitásokhoz kapcsolódó adatokat, ha az Activity identitás ugyanarra az identitásra van beállítva.

A folyamatszintű identitás általában csak akkor hasznos, ha az alkalmazás egyszerre csak egyetlen identitással dolgozik 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 Application a rendszerszolgáltatások beszerzéséhez használja, győződjön meg arról, hogy a szál- vagy folyamatidentitás be van állítva, vagy hogy a felhasználói felület identitása be van állítva az alkalmazás Application környezetében.

Ha az alkalmazás környezetet használ Service a szándékok indításához, tartalomfeloldókat használ, vagy más rendszerszolgáltatásokat használ, mindenképpen állítsa be az identitást a környezeten Service . Hasonlóképpen, ha az alkalmazás környezetet JobService használ a műveletek végrehajtásához, mindenképpen állítsa be az identitást a környezeten vagy a JobService szálon az implementáció által megkövetelt JobService módon. Ha például egyetlen identitás feldolgozási feladatait végzi JobService , érdemes lehet az identitást a JobService környezetre állítani. Ha JobService több identitás feldolgozási feladatait is feldolgozza, érdemes lehet az identitást szálszinten beállítani.

Figyelem!

A használó WorkManager alkalmazásoknak különös körültekintéssel kell eljárniuk az identitás beállításakor. Ezeknek az alkalmazásoknak el kell kerülniük az identitás beállítását a Worker konstruktorban átadott identitáshozContext. Ez a Context példány egyidejűleg 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()Worker az implementáció által megkövetelt módon.

Megjegyzés:

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

A MAMPolicyManager alábbi módszereivel beállíthatja az aktív identitást, és lekérheti a korábban beállított identitásértékeket.

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ényelmesebben, a MAMActivity alkalmazásban a hívás MAMPolicyManager.setUIPolicyIdentityOIDhelyett közvetlenül is megadhatja a tevékenységek identitását. Ehhez használja a következő módszert:

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

Megjegyzés:

Ha az alkalmazás nem deklarálta a többidentitásos támogatás használatát a jegyzékfájlban, ezeknek a metódusoknak az identitás beállításához való meghívása nem hajt végre semmilyen műveletet, és ha visszaad egy MAMIdentitySwitchResult, akkor mindig visszaadja FAILED.

Az identitáskapcsoló gyakori buktatói

• A hívások startActivityesetében az Intune App SDK feltételezi, hogy az aktív identitás az adott Context szinten a megadott Intent paraméterhez van társítva. Erősen javasoljuk, hogy a szintidentitást Context egy Activity's környezettel állítsa be, ne a Application's környezetével.

• Az identitást Context ajánlott a tevékenység onCreate metódusa során beállítani. Ügyeljen azonban arra, hogy más belépési pontokra is kiterjedjen, mint például onNewIntent. Máskülönben, ha ugyanazt a tevékenységet újra felhasználja a felügyelt és a nem felügyelt identitások adatainak megjelenítésére, a házirend helytelenül alkalmazva, ami nem védett vállalati adatokhoz vagy nem megfelelően korlátozott személyes adatokhoz vezethet.

Az identitásváltás eredményei

Az identitásjelentés eredményértékeinek a MAMIdentitySwitchResult-on keresztüli visszaá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ásmódosítás sikeres volt.
NOT_ALLOWED	Az identitásmódosítás nem engedélyezett. Ez akkor fordul elő, ha megpróbálják beállítani a felhasználói felület (Context) identitását, miközben 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 a PIN-kódon vagy a hitelesítést kérő párbeszédpanelen a vissza gomb megnyomásával.
FAILED	Az identitásmódosítás ismeretlen okból nem sikerült.

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

Az aktív identitás beállítására szolgáló módszerek többsége szinkron módon adja vissza a MAMIdentitySwitchResult eredményt. Ha a setUIPolicyIdentityOID használatával állít be egy Context identitást, az eredményt aszinkron módon jelenti a rendszer. Az alkalmazás implementálhat egy MAMSetUIIdentityCallback-et az eredmény fogadásához, vagy null értéket adhat át a visszahívási objektumra. Ha hívást setUIPolicyIdentityOID kezdeményez, miközben egy korábbi hívásContextsetUIPolicyIdentityOID eredménye még nem lett kézbesítve, 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 számára megadott érték egy Activity, az SDK nem tudja, hogy az identitásmódosítás sikeres volt-e, amíg végre nem hajtja a rendszergazda által konfigurált feltételes indítási ellenőrzéseket. Ehhez a felhasználónak PIN kódot vagy vállalati hitelesítő adatokat kell megadnia.

Jelenleg a folyamat- és szálidentitás-váltások mindig sikeresek a többidentitásos alkalmazások esetén. Az SDK fenntartja a jogot arra, hogy a jövőben hibafeltételeket vegyen fel.

A felhasználói felület identitásváltása érvénytelen argumentumok esetén sikertelen lehet, ha ütközik a szálidentitással, vagy ha a felhasználó megszakítja a feltételes indítási követelményeket (például megnyomja a vissza gombot a PIN-kód képernyőn).

A felhasználói felület sikertelen identitásváltása alapértelmezés szerint befejezi a tevékenységet. 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érleteiről, felülbírálhat egy metódust a MAMActivity.

    public void onSwitchMAMIdentityComplete(final MAMIdentitySwitchResult result);

Ha felülbírálja 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 egy sikertelen identitásváltás után.

Megjegyzés:

Az identitás módosításához előfordulhat, hogy újra létre kell hoznia a tevékenységet. Ebben az esetben a visszahívást onSwitchMAMIdentityComplete a rendszer a tevékenység új példányába kézbesíti.

Identity, Intents, and IdentitySwitchOptions

Az új fájlok aktív identitással való automatikus címkézése mellett az SDK a szándékokat is az aktív identitással címkézi meg. Alapértelmezés szerint az SDK ellenőrzi az identitást egy bejövő szándék alapján, és összehasonlítja azt 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ásváltozásokat ).

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

Az SDK azért hajtja végre ezt az ellenőrzést, mert azt feltételezi, hogy az alkalmazás továbbra is a szándékon megjelölt identitáshoz tartozó szándékból jelenít meg tartalmat. Ez a feltételezés védelmet nyújt az ellen, hogy az alkalmazás véletlenül kikapcsolja a védelmet a felügyelt adatok megjelenítésekor; Ez a feltételezés azonban nem feltétlenül igaz az alkalmazás tényleges viselkedéséhez.

Az opcionális IdentitySwitchOption felsorolá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 tájékoztatja az SDK-t, hogy hagyja ki a kért identitásparaméter összehasonlítását a legutóbb tárolt szándékidentitással. Ez akkor hasznos, ha az alkalmazás már nem jelenít meg az identitáshoz tartozó tartalmat, és az SDK nem blokkolja ezt az identitáskapcsolót. Például:

  1. Az alkalmazás egy dokumentummegtekintő. Képes renderelni a más appokból beadott dokumentumokat. Emellett tartalmaz egy olyan funkciót is, amellyel a felhasználók fiókot válthatnak. Amikor a felhasználó ezt a fiókváltási funkciót használja, az alkalmazás egy fiókspecifikus kezdőlapra navigál, amelyen az adott fiók legutóbbi dokumentumai találhatók.
  2. Az alkalmazás megkapja a dokumentum megjelenítésére vonatkozó szándékot. Ez a szándék a felügyelt identitással van címkézve.
  3. Az alkalmazás a felügyelt identitásra vált, és megfelelően alkalmazott védelemmel jeleníti meg ezt a dokumentumot.
  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 elhagyja a felügyelt fiók adatait (a szándékban szereplő dokumentumot), az identitásváltás-hívásban kell használnia IGNORE_INTENT . Ezzel elkerülhető, hogy az SDK nem megfelelően utasítsa el ezt a hívást.

• DATA_FROM_INTENT: amikor identitásváltást kér a felhasználói felületi rétegben, ez a beállítás tájékoztatja az SDK-t arról, hogy a legutóbb tárolt szándékidentitásból származó adatok továbbra is megjelennek az identitásváltás sikeres végrehajtása után. Ennek eredményeképpen az SDK teljes mértékben kiértékeli a fogadási szabályzatot az előző szándékidentitással annak megállapításához, hogy engedélyezett-e a megjelenítése. Például:

  1. Az alkalmazás egy dokumentummegtekintő. Képes renderelni a más appokból beadott dokumentumokat. Emellett tartalmaz egy olyan funkciót is, amellyel a felhasználók fiókot 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 olyan megosztott lapra navigál, amely az összes fiók legutóbbi dokumentumait megjeleníti.
  2. Az alkalmazás megkapja a dokumentum megjelenítésére vonatkozó szándékot. Ez a szándék a felügyelt identitással van címkézve.
  3. Az alkalmazás a felügyelt identitásra vált, és megfelelően alkalmazott védelemmel jeleníti meg ezt a dokumentumot.
  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 szándékban a dokumentum előnézetét), az identitásváltás-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 annak megállapításához, hogy megfelelő-e az adatok további megjelenítése.

(*) Az SDK alapértelmezett viselkedése tartalmaz egy speciális kis- és nagybetűket, amelyek kihagyják az adatok betöltésének ellenőrzését, ha például a szándék ugyanabból az alkalmazásból vagy a rendszerindítóból származik.

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

Előfordulhat, hogy az alkalmazás fiókfüggetlen forgatókönyvekkel rendelkezik. Az alkalmazásnak lehetnek olyan forgatókönyvei is helyi, nem felügyelt forgatókönyvekhez, amelyek nem igényelnek bejelentkezést. Mindkét ilyen esetben előfordulhat, hogy az alkalmazás nem szeretné, hogy az SDK kényszerítse a felügyelt identitás szabályzatait, de előfordulhat, hogy nem rendelkezik explicit identitással, amelyre váltania kellene.

Az aktív identitást úgy törölheti, hogy meghívja a beállított identitásmódszerek egyikét úgy, hogy az identitás OID paramétert null. Ha egy szinten törli az identitást, az SDK a prioritási sorrend alapján más szinteken is keresi az aktív identitást.

Másik lehetőségként üres karakterláncot is átadhat identitás-OID paraméterként, amely az identitást egy speciális, nem felügyelt identitásként kezelt üres értékre állítja. Ha az aktív identitást üres sztringre állítja, arra utasítja az SDK-t, hogy ne kényszerítsen alkalmazásvédelmi szabályzatot.

Implicit identitásváltozások

A fenti szakasz azt ismerteti, hogy az alkalmazás milyen különböző módokon állíthatja be explicit módon az aktív identitást a szál, a környezet és a folyamat szintjén. Az aktív identitás azonban az alkalmazásban anélkül is módosulhat, hogy az alkalmazás meghívná e módszerek bármelyikét. Ez a szakasz azt ismerteti, hogy az alkalmazás hogyan figyelheti és reagálhat ezekre az implicit identitásváltozásokra.

Az implicit identitásváltozások figyelése nem kötelező, de ajánlott. Az SDK soha nem módosítja az aktív identitást anélkül, hogy meg ne küldené ezeket az implicit identitásmódosítási értesítéseket.

Figyelem!

Ha az alkalmazás úgy dönt, hogy nem figyeli az implicit identitásváltozásokat, különösen ügyeljen arra, hogy ne feltételezze az aktív identitást. Ha kétségei vannak, a getCurrentThreadIdentityOID, getUIPolicyIdentityOIDés getProcessIdentityOID a módszerekkel erősítse meg az aktív személyazonosságot.

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

• Az egyéb 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 másik MAM-alkalmazásból indítanak el, vagy egy Intent másik MAM-alkalmazás küldte, akkor a tevékenység identitása a másik alkalmazásban az elküldés időpontjában Intent aktív identitás alapján lesz beállítva.

    • Egy Word-dokumentum megtekintésére irányuló tevékenység például a Microsoft Outlook szándékából indul el, amikor egy felhasználó kiválaszt egy dokumentummellékletet. Az Office dokumentummegtekintő tevékenységének identitása átvált az Outlook identitására.

  • Szolgáltatások esetén a szálidentitás hasonlóképpen lesz beállítva a hívás időtartamára onStartonBind . A visszatért feladóba BinderonBind irányuló hívások szintén ideiglenesen beállítják a szálidentitást.

  • A hívások ContentProvider hasonlóképpen állítják be az időtartamuk szálidentitását.

• Egy tevékenység felhasználói interakciója a kontextus szintjén megváltoztathatja az aktív identitást. Például:

  • Ha a felhasználó ebben az esetben Resume szakítja meg az engedélyezési kérést, az üres identitásra való implicit váltást eredményez.

Az implicit identitásváltozások kezelése

Az alkalmazás szükség esetén figyelhet ezekre az implicit identitásváltozásokra, és reagálhat rájuk. Például előfordulhat, hogy egy új fiók használhatóvá válása több lépést is el tud végezni egy új fiók létrehozásához, például egy levelezőappnak. Amikor látja, hogy egy identitásváltási kísérlet történik a hiányos fiók identitására, az alkalmazás kezelője az identitásváltás elfogadása előtt átirányíthatja a felhasználót a fiókbeállítási tevékenységhez. Másik lehetőségként az alkalmazás kezelője megjeleníthet egy hibaüzenetet, és letilthatja az identitáskapcsolót.

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

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

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

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

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

Felsorolási érték	Az SDK alapértelmezett viselkedése	Leírás
CREATE	Engedélyezze az identitáskapcsolót.	Az identitásváltás egy tevékenység létrehozása miatt történik.
NEW_INTENT	Engedélyezze az identitáskapcsolót.	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	Az identitáskapcsoló letiltása.	Az identitásváltás egy önéletrajz visszavonása miatt történik. Ez leggyakrabban akkor fordul elő, amikor a végfelhasználó megnyomja a vissza gombot a PIN-kód, a hitelesítés vagy a megfelelőség felhasználói felületén.

Az AppIdentitySwitchResultCallback paraméter lehetővé teszi a fejlesztők számára, hogy felülbíráljá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 minden implicit identitásmódosításhoz szükséges, kivéve azokat, amelyek egy iratgyűjtőn keresztül történtek MAMService.onMAMBind. Az azonnali hívás alapértelmezett megvalósításai 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 letiltania vagy késleltetnie egy identitásváltást, de ha egy alkalmazásnak ezt kell tennie, akkor az alábbi szempontokat kell figyelembe venni:

• Ha egy identitásváltás le van tiltva, a végfelhasználó viselkedése ugyanaz, mintha az SDK "adatok fogadása más alkalmazásoktól" alkalmazásvédelmi beállítása letiltotta volna az adatok behatolását.

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

• A létrehozáshoz Activity az onMAMIdentitySwitchRequired műveletet előbb onMAMCreatekell meghívni. 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, akkor ezt a felhasználói felületet egy másik tevékenység használatával kell megjeleníteni.

• Ha Activityaz üres identitásra való váltást kéri a következő indokkal RESUME_CANCELLED, , az alkalmazásnak módosítania kell a folytatott tevékenységet az identitásváltásnak megfelelő adatok megjelenítéséhez. Ha ez nem lehetséges, az alkalmazásnak vissza kell utasítania az átváltást, és a rendszer ismét megkéri a felhasználót, hogy feleljen meg a folytatási identitásra vonatkozó házirendnek (például az alkalmazás PIN-kódjának beviteli képernyőjének megjelenítésével).

Figyelem!

A több identitást használó alkalmazások felügyelt és nem felügyelt appokból egyaránt fogadhatnak bejövő adatokat. Az alkalmazás felelőssége a felügyelt identitásokból származó adatok felügyelt módon történő kezelése.

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

Az alapértelmezett viselkedés 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.onSwitchMAMIdentityComplete, végrehajthatja MAMActivityIdentitySwitchListener anélkül, hogy explicit módon örökölne a .MAMActivity

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

Az Intune App SDK a Window jelzővel FLAG_SECURE kényszeríti ki a képernyőkép-házirendet. Egyes alkalmazások beállíthatják FLAG_SECURE a beállításokat saját céljaikra. Ha az alkalmazásvédelmi házirend nem korlátozza a képernyőképeket, az SDK nem módosul FLAG_SECURE.

Olyan identitásváltás esetén, amelynek a házirendje megköveteli a képernyőképek letiltását, olyan identitásra, amelynek a szabályzata nem, az SDK törli.FLAG_SECURE Ennek eredményeképpen az alkalmazásnak nem szabad az FLAG_SECURE identitásváltás után beállított értékekre hagyatkoznia.

Az identitás megőrzése aszinkron műveletekben

Az alkalmazások gyakran küldenek háttérfeladatokat a felhasználói felület szálából más szálakon végrehajtott műveletek kezeléséhez. A többidentitásos alkalmazásoknak biztosítaniuk kell, hogy ezek a háttérfeladatok a megfelelő identitással működjenek, amely gyakran megegyezik a kiadó tevékenység által használt identitással.

Az Intune App SDK a MAMAsyncTask és a MAMIdentityExecutors szolgáltatást biztosítja, hogy segítse az identitás megőrzését aszinkron műveletekben. Az alkalmazásnak ezeket kell használnia (vagy explicit módon be kell állítania a szálidentitást a feladatokon), ha aszinkron műveletei:

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

MAMAsyncTask

A használathoz MAMAsyncTaskegyszerűen örököljön innen, és AsyncTask cserélje le az és onPreExecutedoInBackgroundMAM a és felülbírálásait doInBackgroundonPreExecuteMAM. A MAMAsyncTask konstruktor egy tevékenységi környezetet vesz fel. 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 prioritási sorrend szerint veszi fel.

MAMIdentityExecutors

MAMIdentityExecutorsLehetővé teszi egy meglévő vagy példány identitásmegőrzésiExecutorServicewrapExecutorExecutor/és metódusként wrapExecutorService történő becsomagolását.ExecutorServiceExecutor Például

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

MAMIdentityExecutors Az aktív identitást a normál prioritási sorrend szerint veszi fel.

Fájlvédelem

Védett Files írása

Ahogy azt a fenti, Alkalmazásadatok identitás szerinti rendezése című szakaszban említettük, az Intune App SDK az aktív identitást (a szál/folyamat szintjéről) a fájlokhoz társítja a megírásuk során. A megfelelő titkosítás és szelektív törlési funkció biztosításához kritikus fontosságú, hogy a fájlok létrehozásakor a megfelelő identitás legyen beállítva.

Az alkalmazás lekérdezheti vagy módosíthatja egy fájl identitását a MAMFileProtectionManager osztály használatával, kifejezetten MAMFileProtectionManager.getProtectionInfo lekérdezés és MAMFileProtectionManager.protectForOID módosítás céljából.

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, az abban létrehozott összes új fájl automatikusan azonos védelmet kap. Mivel a címtárvédelem alkalmazása rekurzív módon történik, protectForOID a hívás végrehajtása a nagy könyvtárak esetében némi időt vehet igénybe. Emiatt előfordulhat, hogy a sok fájlt tartalmazó könyvtárra védelmet alkalmazó alkalmazások aszinkron módon futnak protectForOID a háttérszálon.

Ha az identitásparaméterhez üres sztringet hív meg protectForOID , a program a fájlt/könyvtárat nem felügyelt identitással címkézi meg. Ez a művelet eltávolítja a korábban titkosított fájl/könyvtár titkosítását. Szelektív törlési parancs kiadásakor a fájl/könyvtár nem törlődik.

Figyelmeztetés

Fontos gondoskodni arról, hogy csak az adott identitáshoz tartozó fájlok kerüljenek védelembe az adott identitással. Ellenkező esetben a többi identitás adatvesztést tapasztalhat, amikor a tulajdonos identitás kijelentkezik, mivel a fájlok törlődnek, és a titkosítási kulcshoz való hozzáférés elvész.

Védett fájltartalom megjelenítése

Ugyanilyen fontos a megfelelő identitás beállítása a fájltartalmak megjelenítésekor , hogy megakadályozza a jogosulatlan felhasználók számára a kezelt adatok megtekintését. Az SDK nem tudja automatikusan kikövetkeztetni az olvasott fájlok és a .Activity Az alkalmazásoknak megfelelően kell beállítaniuk a felhasználói felület identitását a felügyelt adatok megjelenítése előtt. Ez magában foglalja a fájlokból beolvasott adatokat is.

Ha egy fájl az alkalmazáson kívülről érkezik (vagy ContentProvider nyilvánosan írható helyről olvasható), az alkalmazásnak meg kell kísérelnie meghatározni a fájlidentitást (az adatforráshoz tartozó megfelelő MAMFileProtectionManager.getProtectionInfo adat-túltöltés használatával), mielőtt megjelenítené a fájlból olvasott információkat.

Ha getProtectionInfo nem null, 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ó adatokat nem szabad megjeleníteni.

Egy tartalmi URI-ról való beolvasáskor előfordulhat, hogy először be kell olvasnia az identitást (a getProtectionInfo túlterhelésen Urikeresztül), majd megfelelően be kell állítania a környezetet vagy a szálidentitást. Ezt egy fájlleíró vagy bemeneti adatfolyam megnyitása előtt kell megtenni a ContentResolver, különben a művelet meghiúsulhat.

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

• A felhasználó kiválaszt egy dokumentumot az alkalmazásban való megnyitáshoz.

• A nyitott folyamat során, mielőtt beolvasná az adatokat 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 a visszahívás eredményét.

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

• Az alkalmazás megnyílik és megjeleníti a fájlt.

Ha egy alkalmazás az Android rendszeren DownloadManager tölt le fájlokat, az SDK a korábban ismertetett identitásprioritás használatával automatikusan megpróbálja megvédeni a fájlokat. A lekéréshez DownloadManager használt környezetet akkor használja a rendszer, ha a szálidentitás nincs beállítva. Ha a letöltött fájlok vállalati adatokat tartalmaznak, az alkalmazás felelőssége meghívni a protectForOID azonosítót , ha a fájlokat letöltés után áthelyezik vagy újra létrehozzák.

Single-Identity áttérés a több identitásra

Ha egy korábban egyetlen identitásos Intune-integrációval kiadott alkalmazás később integrálja a több identitást, a korábban telepített alkalmazások átmenetet fognak tapasztalni. Ezt az áttűnést a felhasználó nem látja.

Az átvitel kezeléséhez nem szükséges az alkalmazás. Az áttérés előtt létrehozott fájlok továbbra is felügyeltnek minősülnek (tehát titkosítva maradnak, ha a titkosítási házirend be van kapcsolva).

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

• A frissítést úgy észlelheti, hogy összehasonlítja az alkalmazás verzióját egy olyan ismert verzióval, ahol a többidentitásos támogatás hozzá lett adva.
• Hívás protectForOID üres karakterlánccal az identitásparaméterhez olyan fájlok vagy könyvtárak esetében, amelyeket nem szeretne a felügyelt identitással társítani.

Offline esetek

Az Intune App SDK "offline" módban fut, ha a Céges portál alkalmazás nincs telepítve. A fájlidentitás-címkézés érzékeny az offline módra:

• Ha a Céges portál nincs telepítve, a fájlok nem címkézhetők identitáscímkével. A MAMFileProtectionManager.protectForOID offline módban történő hí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 házirenddel, a fájlok nem címkézhetők megbízhatóan identitáscímkével.

• Amikor a fájlidentitás-címkézés elérhetővé válik, a rendszer az összes korábban létrehozott fájlt személyesként/nem felügyeltként kezeli (az üres karakterlánc-identitáshoz tartozóként), kivéve azokat az eseteket, amikor az alkalmazás korábban egyetlen identitással felügyelt alkalmazásként volt telepítve, ahogy azt az "Átmenet az egyetlen identitásból több identitásba történő váltás" című szakasz ismerteti.

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ók regisztrációja 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, miután az SDK online állapotba került.

Adatpuffer-védelem

Figyelmeztetés

Nem ajánlott több fiókhoz tartozó adatokat egyetlen fájlba írni. Ha lehetséges, rendszerezze az app fájljait identitás szerint.

Az SDK MAMDataProtectionManager metódusait követve ellenőrizheti és módosíthatja a címkézett identitást adott adatpuffereken a byte[] OR InputStream formátumban.

MAMDataProtectionManager.protectForOID Lehetővé teszi, hogy az alkalmazás adatokat társítson egy identitással, és ha az identitást jelenleg titkosítási házirend célozza meg, titkosítsa az adatokat. Ezek a titkosított adatok alkalmasak fájlban lemezen történő tárolásra.

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

Az ezt MAMDataProtectionManager használó alkalmazásoknak létre kell valósítaniuk egy fogadót az értesítéshez MANAGEMENT_REMOVED . További részletekért lásd: Regisztráció az SDK értesítéseire .

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

Figyelmeztetés

A titkosítási műveleteket el kell kerülni az alkalmazásfolyamat korai szakaszában. 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 titkosítási kérelmet nyújt be az alkalmazás indításakor, előfordulhat, hogy a titkosítás inicializálásának befejezéséig le van tiltva.

Megjegyzés:

Az Intune App SDK titkosítási API-ja csak az Intune-szabályzat által megkövetelt adatok titkosítására használható. Nem vonatkozik védelem azokra a fiókokra, amelyek nincsenek engedélyezve a titkosítási házirenddel, így nem használhatók általános célú titkosítási könyvtárként.

Tartalomszolgáltatók

A többidentitásos alkalmazásoknak az s segítségével ContentProvidermegosztott adatokat is védeniük kell, hogy megakadályozzák a felügyelt tartalmak nem megfelelő megosztását.

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

Nincs szükség hívásraisProvideContentAllowedForOid, ha ContentProvider .ParcelFileDescriptor A tartalomszolgáltatótól visszakapott fájlleírókat a rendszer automatikusan kezeli a fájlidentitás alapján.

Szelektív törlés

Alapértelmezés szerint az 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. Ezután az SDK szabályosan bezárja az alkalmazást, befejezi a tevékenységeket, és leállítja az alkalmazásfolyamatot.

Az SDK opcionális lehetőséget biztosít az alkalmazásnak az alapértelmezett törlési viselkedés kiegészítésére (ajánlott) vagy felülbírálására.

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

Megjegyzés:

Az alapértelmezett törlési viselkedés kiegészítése és felülbírálása adott SDK-értesítések kezelését igényli. Az értesítéskezelők implementálásával kapcsolatos további információkért lásd: Regisztráció az SDK értesítéseire .

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

Az alapértelmezett SDK-törlési viselkedés kiegészítéseként az alkalmazás regisztrálhat a MAMNotificationType típusraWIPE_USER_AUXILIARY_DATA.

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

Az alkalmazásoknak határozottan fontolóra kell venniük az alapértelmezett törlési viselkedés kiegészítését a következővel WIPE_USER_AUXILIARY_DATA: , mivel az alkalmazásspecifikus karbantartás gyakori a többidentitásos alkalmazások esetében.

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

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

Figyelmeztetés

Az alkalmazás soha nem regisztrálhat mind WIPE_USER_DATA a .WIPE_USER_AUXILIARY_DATA

Az SDK alapértelmezett törlési viselkedésének felülbírálása jelentős kockázatot jelent az alkalmazásra nézve. Az alkalmazás teljes felelőssége lesz 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 is.

• Ha a felügyelt identitás titkosítással védve volt, é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 tudja kezelni a titkosított adatok szabályos olvasását.
• Az alkalmazás törléskezelője adatvesztést okozhat a nem felügyelt felhasználók számára, ha eltávolít olyan fájlokat, amelyek nincsenek címkézve a felügyelt identitással.

Ha az alkalmazás egyéni törléskezelője eltávolítja a felügyelt adatokat egy fájlból, de más adatokat szeretne meghagyni a fájlban, módosítania kell a fájl identitását (a MAMFileProtectionManager.protectForOID-en keresztül) 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 karbantartá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, nehogy a felhasználó hozzáférjen a memóriában lévő adatokhoz a törlés után.

Kilépési feltételek

Tervezzen jelentős időt annak ellenőrzésére, hogy az alkalmazás integrálja-e a többidentitást. A tesztelés megkezdése előtt:

• Appvédelmi házirendet hozhat létre és rendelhet hozzá egy fiókhoz. Ez lesz a teszt által felügyelt fiók.
• Hozzon létre másik fiókot, de ne rendeljen hozzá alkalmazásvédelmi házirendet másik fiókhoz. Ez lesz a nem felügyelt tesztfiókja. Másik lehetőségként, ha az alkalmazás több fióktípust is támogat a Microsoft Entra-fiókokon kívül, használhat egy meglévő, nem Entra-fiókot nem felügyelt tesztfiókként.
• Ismerkedjen meg újra azzal, hogyan történik a házirendek alkalmazáson belüli érvényesítése. A többszörös identitás tesztelése megköveteli, hogy könnyen meg tudja különböztetni, hogy az alkalmazás mikor működik a kényszerített szabályzatokkal, illetve mikor nem. A képernyőképek letiltására vonatkozó appvédelmi házirend-beállítás hatékonyan teszteli a házirend-kényszerítést.
• Vegye figyelembe az alkalmazás által kínált felhasználói felület teljes készletét. Számba veheti azokat a képernyőket, amelyeken a fiókadatok megjelennek. Az alkalmazás mindig csak egy fiók adatait jeleníti meg egyszerre, vagy egyszerre több fiókhoz tartozó adatokat is képes megjeleníteni?
• Vegye figyelembe az alkalmazás által létrehozott fájlok teljes készletét. Számba veheti, hogy ezek közül a fájlok közül melyek tartalmaznak fiókhoz tartozó adatokat, nem pedig rendszerszintű adatokat.
  • Határozza meg, hogyan fogja ellenőrizni a titkosítást az egyes fájlokon.
• Vegye figyelembe az összes módszert, amellyel az alkalmazás kommunikálhat más alkalmazásokkal. Számba kell vennie az összes be- és kilépési pontot. Milyen típusú adatokat tud betölteni az alkalmazás? Milyen szándéka van közvetítve? Milyen tartalomszolgáltatókat valósít meg?
  • Határozza meg, hogyan fogja használni ezeket az adatmegosztási funkciókat.
  • Készítsen elő egy teszteszközt, amely felügyelt és nem felügyelt alkalmazásokkal is rendelkezik, amelyek képesek kommunikálni az alkalmazással.
• Gondolja át, hogy az alkalmazás hogyan teszi lehetővé a végfelhasználók számára az összes bejelentkezett fiók kezelését. A felhasználónak manuálisan kell váltania egy fiókra ahhoz, hogy megjelenjenek a fiók adatai?

Miután alaposan felmérte az alkalmazás jelenlegi viselkedését, ellenőrizze a többidentitásos integráció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öbb identitást tartalmazó implementációja hibamentes.

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

A többidentitásos 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öbbidentitásos integráció 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 az Intune Céges portál; ne jelentkezzen be a teszt megkezdése előtt.

Forgatókönyv	Lépések
Először kezelt bejelentkezés	- Először jelentkezzen be egy kezelt fiókkal, és ellenőrizze, hogy a fiók adatai kezelve vannak-e. - Jelentkezzen be egy nem kezelt fiókkal, és ellenőrizze, hogy a fiók adatai nincsenek kezelve.
Bejelentkezés nem felügyelt előbb	- Először jelentkezzen be egy nem kezelt fiókkal, és ellenőrizze, hogy a fiók adatai nem kezelve vannak-e. - Jelentkezzen be egy kezelt fiókkal, és ellenőrizze, hogy a fiók adatai kezelve vannak-e.
Bejelentkezés több felügyelt eszközbe	- Először jelentkezzen be egy kezelt fiókkal, és ellenőrizze, hogy a fiók adatai kezelve vannak-e. - Jelentkezzen be egy második kezelt fiókkal, és ellenőrizze, hogy a felhasználó le van-e tiltva a bejelentkezéshez anélkül, hogy először eltávolítaná az eredeti kezelt fiókot.
Kijelentkezés felügyelt	- Jelentkezzen be az alkalmazásba felügyelt és nem felügyelt fiókkal is. - Jelentkezzen ki a kezelt fiókból. - Győződjön meg arról, hogy a kezelt fiókot eltávolította 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 még mindig be van jelentkezve, a nem kezelt fiók adatai nem lettek eltávolítva, és a házirend továbbra sincs alkalmazva.
Felügyelet nélküli kijelentkezés	- Jelentkezzen be az alkalmazásba felügyelt és nem felügyelt fiókkal is. - Jelentkezzen ki a nem kezelt 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 kezelt fiókba továbbra is be van jelentkezve, a nem kezelt fiók egyetlen adata sem lett eltávolítva, és a házirend továbbra is érvényben van.

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

Előfordulhat, hogy a többidentitásos alkalmazás egyetlen fiók adatait tartalmazó nézeteket jelenít meg, és lehetővé teszi a felhasználó számára az aktuális használatban lévő fiók explicit módosítását. Emellett egyszerre több fiók adatait is megjelenítheti. Ezek a tesztek segítenek biztosítani, hogy a többidentitásos integráció megfelelő védelmet biztosítson az aktív identitás számára minden lapon az alkalmazás teljes életciklusa során.

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

Forgatókönyv	Lépések
Egyetlen fiók nézet, felügyelt	- Váltson a kezelt fiókra. - Nyissa meg az alkalmazás összes olyan oldalát, amely egyetlen fiók adatait jeleníti meg. - Győződjön meg arról, hogy a házirend minden oldalon érvényes.
Egyetlen fiókos nézet, nem felügyelt	- Váltson a nem kezelt fiókra. - Nyissa meg az alkalmazás összes olyan oldalát, amely egyetlen fiók adatait jeleníti meg. - Győződjön meg arról, hogy a házirend nincs alkalmazva egyik oldalon sem.
Többfiókos nézet	- Nyissa meg az alkalmazás összes olyan oldalát, amely egyszerre több fiók adatait is megjeleníti. - Győződjön meg arról, hogy a házirend minden oldalon érvényes.
Felügyelt szünet	- A felügyelt adatokat megjelenítő és aktív házirendet megjelenítő képernyőn szüneteltesse az alkalmazást az eszköz kezdőképernyőjére vagy egy másik alkalmazásra navigálva. - Folytassa az alkalmazást. - Győződjön meg arról, hogy a házirend továbbra is érvényben van.
Nem kezelt szünet	- Olyan képernyőn, amelyen nem kezelt adatok jelennek meg, és nincs aktív házirend, szüneteltesse az alkalmazást az eszköz kezdőképernyőjére vagy egy másik alkalmazásra navigálva. - Folytassa az alkalmazást. - Győződjön meg arról, hogy a házirend nincs alkalmazva.
Felügyelt leállítás	- A felügyelt adatokat megjelenítő és aktív házirendet megjelenítő képernyőn kényszerítse le 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 adatait megjelenítő képernyőn folytatódik (várható), a házirend továbbra is érvényben van-e. Ha az alkalmazás a nem felügyelt fiók adatait megjelenítő képernyőn folytatódik, győződjön meg arról, hogy a házirend nincs alkalmazva.
Nem felügyelt leállítás	- Olyan képernyőn, amelyen nem kezelt adatok jelennek meg, és a házirend aktív, kényszerítse le 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 adatait megjelenítő képernyőn folytatódik (várt), akkor a rendszer nem alkalmazza a házirendet. Ha az alkalmazás a felügyelt fiók adatait megjelenítő képernyőn folytatódik, győződjön meg arról, hogy a házirend továbbra is érvényben van.
Alkalmi identitásváltás	- 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ítá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 kezelt fiók adatai soha nincsenek védve.

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

A többidentitásos alkalmazás adatokat küldhet más alkalmazásoknak, és adatokat fogadhat azoktól. Az Intune alkalmazásvédelmi szabályzatai olyan beállításokkal rendelkeznek, amelyek ezt a viselkedést írják le. Ezek a tesztek segítenek biztosítani, hogy a többidentitásos integráció figyelembe vegye ezeket az adatmegosztási beállításokat.

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

• Állítsa be a felügyelt fiók házirendjét a következőre:
  • "Szervezeti adatok küldése más alkalmazásoknak" beállítás a "Házirenddel felügyelt alkalmazások" beállításra.
  • "Adatok fogadása más alkalmazásoktól" beállításra "Házirenddel felügyelt alkalmazások" beállításra.
• Telepítsen más alkalmazásokat a teszteszközön:
  • Az alkalmazással megegyező házirenddel megcélzott felügyelt app, amely képes adatok küldésére és fogadására (például Microsoft Outlook).
  • Minden olyan nem felügyelt app, amely képes adatokat küldeni és fogadni.
• Jelentkezzen be a másik felügyelt appba a felügyelt tesztfiókkal. Még ha a másik felügyelt alkalmazás többidentitással is rendelkezik, 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 dokumentummelléklet küldésére a Microsoft Office-ba:

Forgatókönyv	Lépések
Felügyelt identitás küldése nem felügyelt alkalmazásnak	- Váltson a kezelt fiókra. - Navigáljon arra a helyre, ahová az alkalmazás adatokat küldhet. - Kísérlet adatok küldésére egy nem felügyelt alkalmazásnak. - Le kell tiltani az adatok nem kezelt alkalmazásnak való küldését.
Felügyelt identitás küldése felügyelt alkalmazásba	- Váltson a kezelt 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, amelyen a felügyelt fiók be van jelentkezve. - Engedélyezni kell az adatok küldését a felügyelt alkalmazásnak.
Nem felügyelt identitás küldése felügyelt alkalmazásnak	- Váltson a nem kezelt 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, amelyen a felügyelt fiók be van jelentkezve. - Le kell tiltani az adatok küldését a másik felügyelt alkalmazásnak.
Nem felügyelt identitás küldése nem felügyelt alkalmazásba	- Váltson a nem kezelt fiókra. - Navigáljon arra a helyre, ahová az alkalmazás adatokat küldhet. - Kísérlet adatok küldésére egy nem felügyelt alkalmazásnak. - Mindig engedélyezni kell a nem kezelt fiókok adatainak elküldését egy nem felügyelt alkalmazásnak.

Előfordulhat, hogy az alkalmazás aktívan importál adatokat más alkalmazásokból, például a Microsoft Outlookból, amely fájlt csatol a Microsoft OneDrive-ról. Az alkalmazás passzívan fogadhat adatokat más alkalmazásokból is, például a Microsoft Office-ból, amely megnyit egy dokumentumot egy Microsoft Outlook-mellékletből. Az appvédelmi házirend beállítása mindkét forgatókönyvre kiterjed.

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

Forgatókönyv	Lépések
Felügyelt identitás importálása nem felügyelt appból	- Váltson a kezelt fiókra. - Nyissa meg azt a helyet, ahová az alkalmazás adatokat importálhat más alkalmazásokból. - Kísérlet adatok importálására egy nem felügyelt alkalmazásból. - Le kell tiltani az adatok nem felügyelt alkalmazásokból történő importálását.
Felügyelt identitás importálása felügyelt appból	- Váltson a kezelt fiókra. - Nyissa meg azt a helyet, ahová 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, ha a felügyelt fiók be van jelentkezve. - Lehetővé kell tennie az adatok importálását a másik felügyelt alkalmazásból.
Nem felügyelt identitásimportálás felügyelt alkalmazásból	- Váltson a nem kezelt fiókra. - Nyissa meg azt a helyet, ahová 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, ha a felügyelt fiók be van jelentkezve. - Le kell tiltani az adatok importálását a másik felügyelt alkalmazásból.
Nem felügyelt identitásimportálás nem felügyelt alkalmazásból	- Váltson a nem kezelt fiókra. - Nyissa meg azt a helyet, ahová az alkalmazás adatokat importálhat más alkalmazásokból. - Kísérlet adatok importálására egy nem felügyelt alkalmazásból. - Mindig engedélyezni kell az adatok importálását nem felügyelt fiók nem felügyelt alkalmazásából.

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

Forgatókönyv	Lépések
Nem felügyelt alkalmazásból származó felügyelt identitás	- Váltson a kezelt 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ásba. - Az alkalmazás felügyelt fiókja nem fogadhat adatokat a nem felügyelt alkalmazásból.
Felügyelt identitás fogadja a felügyelt alkalmazástól	- Váltson a kezelt fiókra. - Váltson a másik felügyelt alkalmazásra, amelyen a felügyelt fiók be van jelentkezve. - Navigáljon arra a helyre, ahová adatokat küldhet. - Próbáljon meg adatokat küldeni a felügyelt alkalmazásból az alkalmazásba. - Az alkalmazás felügyelt fiókjának engedélyezni kell az adatok fogadását a másik felügyelt alkalmazásból.
Nem felügyelt identitás fogadása felügyelt alkalmazásból	- Váltson a nem kezelt fiókra. - Váltson a másik felügyelt alkalmazásra, amelyen a felügyelt fiók be van jelentkezve. - Navigáljon arra a helyre, ahová adatokat küldhet. - Próbáljon meg adatokat küldeni a felügyelt alkalmazásból az alkalmazásba. - Az alkalmazás nem felügyelt fiókja nem fogadhat adatokat a felügyelt alkalmazásból.
Nem felügyelt identitás fogadása nem felügyelt alkalmazásból	- Váltson a nem kezelt 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ásba. - Az alkalmazás nem felügyelt fiókjának mindig engedélyezni kell az adatok fogadását a nem kezelt alkalmazásból.

A tesztek sikertelensége azt jelezheti, hogy az alkalmazás nem rendelkezik a megfelelő aktív identitásbeállítással, amikor adatokat próbál küldeni vagy fogadni. Ezt az SDK Get Identity API-jainak használatával vizsgálhatja meg a küldés/fogadás pillanatában 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öbbidentitásos alkalmazás kiegészítette vagy felülbírálta az SDK alapértelmezett törlési viselkedését. Ezek a tesztek segítenek biztosítani, hogy a többidentitásos integráció megfelelően távolítsa el a felügyelt adatokat a törlések kezdeményezésekor anélkül, hogy hatással lenne a nem felügyelt adatokra.

Figyelmeztetés

Emlékeztető, ha az alkalmazás kihasználta MAMDataProtectionManager.protectForOIDa következőt, akkor létre kell hoznia egy kezelőt az WIPE_USER_AUXILIARY_DATA vagy WIPE_USER_DATA.

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

Forgatókönyv	Előfeltételek	Lépések
Kiegészítő törléskezelő	Az alkalmazás alkalmaz egy kezelőt a WIPE_USER_AUXILIARY_DATA	- Adjon ki szelektív törlést a Microsoft Intune Felügyeleti központból. - Ellenőrizze (általában naplózással), hogy a törléskezelő sikeresen lefutott-e. - Győződjön meg arról, hogy a kezelt fiókot eltávolította 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 még mindig be van jelentkezve, a nem kezelt fiók adatai nem lettek eltávolítva, és a házirend továbbra sincs alkalmazva.
Felülbírált törléskezelő	Az alkalmazás alkalmaz egy kezelőt a WIPE_USER_DATA	- Adjon ki szelektív törlést a Microsoft Intune Felügyeleti központból. - Ellenőrizze (általában naplózással), hogy a törléskezelő sikeresen lefutott-e. - Győződjön meg arról, hogy a kezelt fiókot eltávolította 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 még mindig be van jelentkezve, a nem kezelt fiók adatai nem lettek eltávolítva, és a házirend továbbra sincs alkalmazva. - Győződjön meg arról, hogy az alkalmazás szabályosan kilépett, vagy továbbra is kifogástalan állapotban van-e a törléskezelő befejezése után.
Manuális fájlvédelem	- Az alkalmazás hívásai MAMFileProtectionManager.protectForOID - Az alkalmazás alkalmazott kezelővel rendelkezik WIPE_USER_DATA	- Győződjön meg arról, hogy már gyakorolt olyan forgatókönyveket, amikor az alkalmazás manuálisan véd legalább egy, a felügyelt fiókhoz tartozó fájlt. - Adjon ki szelektív törlést a Microsoft Intune Felügyeleti központból. - Erősítse meg, hogy a fájlok el lettek távolítva.
Manuális adatpuffer-védelem	- Az alkalmazás hívásai MAMDataProtectionManager.protectForOID - Az alkalmazás alkalmazta a WIPE_USER_AUXILIARY_DATA vagy WIPE_USER_DATA	- Győződjön meg arról, hogy olyan forgatókönyveket gyakorolt, ahol az alkalmazás manuálisan védené a felügyelt fiókhoz tartozó legalább egy, adatpuffert. - Adjon ki szelektív törlést a Microsoft Intune Felügyeleti központból. - Győződjön meg arról, hogy az adatpufferek el lesznek távolítva azokról a fájlokról, amelyekben azok voltak, és hogy az alkalmazás továbbra is képes olvasni a nem kezelt adatokat ezekből a fájlokból.

Következő lépések

Miután teljesítette az összes fenti kilépési feltételt , az alkalmazás sikeresen integrálva van többidentitásként, és identitásonként alkalmazhat alkalmazásvédelmi szabályzatokat. A következő szakaszok, a 6. szakasz: App Configuration és a 7. szakasz: Alkalmazás-részvételi funkciók szükségesek vagy nem szükségesek attól függően, hogy az alkalmazás milyen alkalmazásvédelmi szabályzatot támogat. Ha nem biztos abban, hogy ezen szakaszok bármelyike vonatkozik-e az Ön alkalmazására, tekintse át újra az SDK-integrációval kapcsolatos legfontosabb döntéseket.