Vanliga frågor och svar om MAM och appskydd

MAM-översikt

Principer för appskydd är regler som säkerställer att en organisations data förblir säkra eller finns i en hanterad app. En princip är en regel som Intune tillämpar när användaren försöker komma åt eller flytta "företagsdata". Den kan också definiera åtgärder som Intune blockerar eller övervakar medan användaren är i appen.

Mer information om varje inställning för appskyddsprinciper finns i Inställningar för Android-appskyddsprinciper och iOS/iPadOS-inställningar för appskyddsprinciper.

Om du använder en MAM-princip för användaren utan att ange enhetshanteringstillstånd får användaren MAM-principen på både den personliga enheten, även kallad BYOD (Bring Your Own Device), och den Intune-hanterade enheten. Du kan också tillämpa en MAM-princip baserat på enhetshanteringstillstånd. Så när du skapar en appskyddsprincip bredvid Rikta till appar på alla typer av enheter väljer du Nej. Välj sedan något av följande alternativ:

• Tillämpa en mindre strikt MAM-princip på Intune hanterade enheter och tillämpa en mer restriktiv MAM-princip på icke-MDM-registrerade enheter.
• Tillämpa en lika strikt MAM-princip på Intune-hanterade enheter och på icke-Microsoft-hanterade enheter.
• Tillämpa en MAM-princip endast på oregistrerade enheter.

Mer information finns i Övervaka appskyddsprinciper.

Alla appar som är integrerade med Intune App SDK eller som omsluts av Intune App Wrapping Tool kan hanteras med Intune appskyddsprinciper. Se den officiella listan över Intune-hanterade appar som är tillgängliga för offentlig användning.

• Slutanvändaren måste ha ett Microsoft Entra konto. Mer information om hur du skapar Intune -användare i Microsoft Entra ID finns i Lägga till användare och ge administrativ behörighet till Intune.

• Slutanvändaren måste ha en licens för Microsoft Intune tilldelad till sitt Microsoft Entra konto. Mer information om hur du tilldelar Intune licenser till slutanvändare finns i Hantera Intune licenser.

• Slutanvändaren måste tillhöra en säkerhetsgrupp som är mål för en appskyddsprincip. Samma appskyddsprincip måste rikta in sig på den specifika app som används. Principer för appskydd kan skapas och distribueras i administrationscentret för Microsoft Intune. Säkerhetsgrupper kan för närvarande skapas i Administrationscenter för Microsoft 365.

• Slutanvändaren måste logga in på appen med sitt Microsoft Entra konto.

Intune SDK-utvecklingsteamet testar aktivt och underhåller stöd för appar som skapats med de inbyggda Android-, iOS/iPadOS-plattformarna (Obj-C, Swift), .NET och MAUI. Vissa kunder integrerar Intune SDK med andra plattformar, till exempel React Native och NativeScript. Microsoft tillhandahåller dock inte vägledning eller plugin-program för andra plattformar än de som stöds.

Intune App SDK kan använda Microsofts autentiseringsbibliotek för sina autentiserings- och villkorsstyrda startscenarier. Den förlitar sig också på MSAL för att registrera användaridentiteten med MAM-tjänsten för hantering utan scenarier för enhetsregistrering.

• Slutanvändaren måste ha Outlook-mobilappen installerad på sin enhet.

• Slutanvändaren måste ha en Microsoft 365 Exchange Online postlåda och licens kopplad till sitt Microsoft Entra konto.

  Obs!

  Outlook-mobilappen stöder för närvarande endast Intune-appskydd för Microsoft Exchange Online och Exchange Server med modern hybridautentisering och stöder inte Exchange i Office 365 Dedicated.

• Slutanvändaren måste ha en licens för Microsoft 365-applikationer för affärsverksamhet eller företag kopplad till sitt Microsoft Entra konto. Prenumerationen måste innehålla Office-apparna på mobila enheter och kan inkludera ett molnlagringskonto med OneDrive, molnlagring och fildelning för företag. Microsoft 365-licenser kan tilldelas i Administrationscenter för Microsoft 365 genom att följa dessa anvisningar.

• Slutanvändaren måste ha en hanterad plats konfigurerad med den detaljerade Spara som-funktionen under principinställningen "Spara kopior av organisationsdata" för programskydd. Om den hanterade platsen till exempel är OneDrive ska OneDrive-appen konfigureras i slutanvändarens Word, Excel eller PowerPoint-app.

• Om den hanterade platsen är OneDrive måste appen vara mål för den appskyddsprincip som distribuerats till slutanvändaren.

  Obs!

  Office-mobilapparna har för närvarande endast stöd för SharePoint Online och inte SharePoint lokalt.

Intune markerar alla data i appen som antingen "företag" eller "personliga". Data betraktas som "företagsinformation" om de kommer från ett företag. För Office-appar behandlar Intune e-post (Exchange) och molnlagring (OneDrive) som företagsplatser.

Se Licenskrav för Skype för företag. Information om hybridkonfigurationer och lokala konfigurationer för Skype för företag (SfB) finns i Modern hybridautentisering för SfB och Exchange blir allmänt tillgängligoch modern autentisering för SfB lokalt med Microsoft Entra ID.

Stöd för flera identiteter är möjligheten för Intune App SDK att endast tillämpa appskyddsprinciper på arbets- eller skolkontot som är inloggat i appen. Om ett personligt konto är inloggat i appen berörs inte data.

Stöd för flera identiteter gör att appar med både "företags"- och konsumentmålgrupper (d.v.s. Office-apparna) kan släppas offentligt med Intune appskyddsfunktioner för "företagskontona".

Eftersom Outlook har en kombinerad e-postvy med både personliga e-postmeddelanden och "företagsmeddelanden" frågar Outlook-appen efter Intune PIN-kod vid start.

PIN-koden (Personal Identification Number) är en kod som används för att verifiera att rätt användare har åtkomst till organisationens data i ett program.

Intune frågar efter användarens app-PIN-kod när användaren ska få åtkomst till företagsdata. I appar med flera identiteter, till exempel Word/Excel/PowerPoint, uppmanas användaren att ange sin PIN-kod när de försöker öppna ett "företagsdokument" eller en "företagsfil". I appar med en enda identitet, till exempel verksamhetsspecifika appar som hanteras med Intune App Wrapping Tool, uppmanas PIN-koden vid start eftersom Intune App SDK vet att användarens upplevelse i appen alltid är "företagsinformation".

IT-administratören kan definiera Intune appskyddsprincipinställning "Kontrollera åtkomstkraven igen efter (minuter)" i Microsoft Intune administrationscenter. Den här inställningen anger hur lång tid det ska ta innan åtkomstkraven kontrolleras på enheten och skärmen med programmets PIN-kod visas igen. Viktig information om PIN-kod som påverkar hur ofta användare tillfrågas är dock:

• PIN-koden delas mellan appar från samma utgivare för att förbättra användbarheten: I iOS/iPadOS delas en PIN-kod för appen mellan alla appar från samma apputgivare. På Android delas en app-PIN mellan alla appar.
• Beteendet 'Kontrollera åtkomstkraven igen efter (minuter) efter en omstart av enheten: En "PIN-timer" spårar antalet minuters inaktivitet som avgör när PIN-koden för Intune App ska visas härnäst. I iOS/iPadOS påverkas inte PIN-timern av omstart av enheten. Omstart av enheten har alltså ingen effekt på antalet minuter som användaren är inaktiv från en iOS/iPadOS-app med PIN-principen för Intune. På Android återställs PIN-kodstimern när enheten startas om. Därför kommer Android-appar med Intune PIN-princip sannolikt att fråga efter en app-PIN oavsett inställningsvärdet "Kontrollera åtkomstkraven igen efter (minuter)" efter en omstart av enheten.
• Den rullande karaktären hos timern som är associerad med PIN-koden: När du anger en PIN-kod för åtkomst till en app (app A) och appen lämnar förgrunden (huvudfokus) på enheten återställs PIN-kodstimern för den PIN-koden. Appar (app B) som delar den här PIN-koden uppmanar inte användaren att ange PIN-koden eftersom timern har återställts. Kommandotolken visas igen när värdet Kontrollera åtkomstkraven igen efter (minuter) uppfylls igen.

På iOS/iPadOS-enheter kan appar från olika utgivare dela samma PIN-kod. Men när värdet Kontrollera åtkomstkraven igen efter (minuter) har uppnåtts uppmanar Intune användaren att ange en PIN-kod om appen inte var huvudfokus för inmatning. En användare har till exempel app A från utgivare X och app B från utgivare Y, och de två apparna delar samma PIN-kod. Användaren fokuserar på app A (förgrund) och app B minimeras. Efter att värdet Kontrollera åtkomstkraven igen efter (minuter) har uppfyllts och användaren växlar till app B krävs PIN-koden.

PIN-koden för Intune fungerar baserat på en inaktivitetsbaserad timer (värdet för "Kontrollera åtkomstkraven igen efter (minuter)"). Därför visas Intune PIN-uppmaningar oberoende av de inbyggda app-PIN-uppmaningarna för Outlook och OneDrive som ofta är knutna till appstart som standard. Om användaren får båda PIN-uppmaningarna samtidigt bör det förväntade beteendet vara att Intune PIN-koden har företräde.

PIN-koden ger bara rätt användare åtkomst till organisationens data i appen. Därför måste en slutanvändare logga in med sitt arbets- eller skolkonto innan de kan ange eller återställa PIN-koden för sin Intune-app. Microsoft Entra ID hanterar den här autentiseringen via säkert tokenutbyte och är inte transparent för Intune App SDK. Ur ett säkerhetsperspektiv är det bästa sättet att skydda arbets- eller skoldata att kryptera den. Kryptering är inte relaterat till appens PIN-kod utan är en egen appskyddsprincip.

Som en del av appens PIN-princip kan IT-administratören ange det maximala antalet gånger en användare kan försöka autentisera sin PIN-kod innan appen låses. När antalet försök har uppnåtts kan Intune App SDK rensa "företagsdata" i appen.

MAM på iOS/iPadOS har stöd för PIN-koder på programnivå med alfanumeriska tecken och specialtecken (en så kallad lösenkod). För att tillämpa lösenordsinställningar måste appar som Word, Excel, PowerPoint, Outlook, Managed Browser och Yammer integrera Intune App SDK för iOS/iPadOS. Utan den här integreringen kan Intune inte tillämpa lösenordsinställningarna för dessa appar. Intune introducerade den här funktionen i SDK version 7.1.12 för iOS/iPadOS.

För att stödja den här funktionen och behålla kompatibiliteten med tidigare versioner av Intune SDK för iOS/iPadOS hanterar version 7.1.12 och senare alla PIN-koder (numeriska eller lösenord) separat från den numeriska PIN-kod som används i tidigare versioner. Om en enhet har program med Intune SDK för iOS/iPadOS-versioner före 7.1.12 OCH efter 7.1.12 från samma utgivare måste de därför konfigurera två PIN-koder.

Med det sagt är de två PIN-koderna (för varje app) inte relaterade på något sätt. De måste följa den appskyddsprincip som tillämpas på appen. Det innebär att användaren bara kan konfigurera samma PIN-kod två gånger om app A och B har samma principer (med avseende på PIN-kod).

Det här beteendet är specifikt för PIN-koden på iOS/iPadOS-program som är aktiverade med Intune Mobile App Management. Med tiden, när program använder senare versioner av Intune SDK för iOS/iPadOS, blir det mindre problem att behöva ange en PIN-kod två gånger på appar från samma utgivare.

IT-administratörer kan distribuera en appskyddsprincip som kräver att appdata krypteras. Som en del av principen kan IT-administratören också ange när innehållet ska krypteras.

Intune krypterar data enligt appskyddsprincipinställningen för kryptering. Mer information finns i Inställningar för Android-appskyddsprinciper och iOS/iPadOS-inställningar för appskyddsprinciper.

Endast data som markerats som "företagsdata" krypteras enligt IT-administratörens programskyddsprincip. Data betraktas som "företagsinformation" om de kommer från ett företag. För Office-appar behandlar Intune e-post (Exchange) och molnlagring (OneDrive) som företagsplatser. För verksamhetsspecifika appar som hanteras av Intune App Wrapping Tool betraktas alla appdata som "företagsdata".

Intune kan rensa appdata på tre olika sätt: fullständig enhetsrensning, selektiv rensning för MDM och MAM-selektiv rensning. Mer information om fjärrensning för MDM finns i Ta bort enheter med hjälp av rensa eller dra tillbaka. Mer information om selektiv rensning med MAM finns i åtgärden Dra tillbaka och Så här rensar du endast företagsdata från appar.

Rensa tar bort alla användardata och inställningar från enheten genom att återställa enheten till fabriksinställningarna. Enheten tas bort från Intune.

Selektiv rensning för MDM tar bara bort företagsdata från enheten utan att påverka personliga data. Mer information finns i Ta bort enheter – dra tillbaka.

Selektiv rensning för MAM tar helt enkelt bort företagets appdata från en app. Begäran initieras med hjälp av Microsoft Intune administrationscenter. Information om hur du initierar en rensningsbegäran finns i Så här rensar du endast företagsdata från appar.

Om användaren använder appen när selektiv rensning initieras kontrollerar Intune App SDK var 30: e minut efter en selektiv rensningsbegäran från Intune MAM-tjänsten. Den söker också efter selektiv rensning när användaren startar appen för första gången och loggar in med sitt arbets- eller skolkonto.

Intune appskydd är beroende av användarens identitet för att vara konsekvent mellan programmet och Intune App SDK. Det enda sättet att garantera det är genom modern autentisering. Det finns scenarier där appar kan fungera med en lokal konfiguration, men de är inte konsekventa eller garanterade.

Ja! IT-administratören kan distribuera och ange en appskyddsprincip för Microsoft Edge-appen. IT-administratören kan kräva att alla webblänkar i Intune-hanterade appar öppnas med Microsoft Edge-appen.

Appskydd i Företagsportal och Intune

Intune appskyddsprinciper för åtkomst tillämpas i en viss ordning på slutanvändarens enheter när de försöker komma åt en riktad app från sina företagskonton. I allmänhet skulle en blockering ha företräde och sedan en varning som kan stängas. Till exempel, om det är tillämpligt för den specifika användaren/appen, tillämpas en minsta Android-korrigeringsversion som varnar en användare att ta en korrigeringsuppgradering efter inställningen för lägsta Android-korrigeringsversion som blockerar användaren från åtkomst. Så i scenariot där IT-administratören konfigurerar lägsta Android-korrigeringsversion till 2018-03-01 och lägsta Android-korrigeringsversion (endast varning) till 2018-02-01, medan enheten som försöker komma åt appen hade en korrigeringsversion 2018-01-01, skulle slutanvändaren blockeras baserat på den mer restriktiva inställningen för min Android-korrigeringsversion som resulterar i blockerad åtkomst.

När du hanterar olika typer av inställningar skulle ett krav på appversion ha företräde, följt av versionskrav för Android-operativsystem och krav på Android-korrigeringsversion. Eventuella varningar för alla typer av inställningar i samma ordning markeras.

Intune-tjänsten kontaktar Google Play med ett icke konfigurerbart intervall som bestäms av tjänstbelastningen. Alla åtgärder som konfigureras av IT-administratörer för Google Plays inställning för enhetsintegritetskontroll vidtas baserat på det senast rapporterade resultatet till Intune-tjänsten vid tidpunkten för den villkorliga starten. Om Googles resultat för enhetsintegritet är kompatibelt vidtas ingen åtgärd. Om Googles resultat för enhetsintegritet inte är kompatibelt vidtas den åtgärd som konfigurerats av IT-administratören omedelbart. Om begäran till Google Plays enhetsintegritetskontroll av någon anledning misslyckas används det cachelagrade resultatet från föregående begäran i upp till 24 timmar eller nästa omstart av enheten, beroende på vilket som kommer först. Då blockerar Intune appskyddsprinciper åtkomst tills ett aktuellt resultat kan erhållas.

Anvisningarna om hur du gör detta varierar något beroende på enhet. Den allmänna processen innebär att du går till Google Play Butik och sedan klickar på Mina appar & spel och klickar på resultatet av den senaste appskanningen som tar dig till Play Protect-menyn. Se till att växlingsknappen för Sök igenom enheten efter säkerhetshot är aktiverad.

Intune tillämpar Google Play-integritets-API:er för att lägga till i våra befintliga rotidentifieringskontroller för oregistrerade enheter. Google utvecklade och underhöll denna API-uppsättning för Android-appar att använda om de inte vill att deras appar ska köras på rotade enheter. Android Pay-appen införlivade till exempel detta. Även om Google inte offentligt delar alla rotidentifieringskontroller som sker, förväntar vi oss att dessa API:er identifierar användare som har rotat sina enheter. Dessa användare kan sedan blockeras från att komma åt eller deras företagskonton rensas från sina principaktiverade appar. "Kontrollera grundläggande integritet" berättar om enhetens allmänna integritet. Rotade enheter, emulatorer, virtuella enheter och enheter med tecken på manipulering misslyckas med grundläggande integritet. "Kontrollera grundläggande integritet & certifierade enheter" visar enhetens kompatibilitet med Googles tjänster. Endast omodifierade enheter som har certifierats av Google kan klara denna kontroll. Exempel på enheter som misslyckas:

• Enheter som inte klarar den grundläggande integriteten
• Enheter med en olåst starthanterare
• Enheter med en anpassad systemavbildning/ROM
• Enheter som tillverkaren inte har ansökt om eller godkänt, Google-certifiering
• Enheter med en systemavbildning som skapats direkt från källfilerna i Android Open Source Program
• Enheter med en systemavbildning för beta-/utvecklarförhandsgranskning

Teknisk information finns i Googles dokumentation om Play Integrity API .

Google Play Integrity API-kontroller kräver att slutanvändaren är online, åtminstone under den tid då "tur och retur" för att fastställa attesteringsresultat körs. Om slutanvändaren är offline kan IT-administratören fortfarande förvänta sig att ett resultat tillämpas från inställningen "jailbrokade/rotade enheter". Med det sagt, om slutanvändaren har varit offline för länge kommer värdet "Offline respitperiod" in i bilden och all åtkomst till arbets- eller skoldata blockeras när det tidsvärdet har uppnåtts, tills nätverksåtkomst är tillgänglig. Genom att aktivera båda inställningarna kan du använda en lagerbaserad metod för att hålla slutanvändarens enheter felfria, vilket är viktigt när slutanvändare kommer åt arbets- eller skoldata på mobilen.

Både inställningarna för Play Integrity Verdict och Threat Scan on Apps kräver att Google-bestämd version av Google Play-tjänster fungerar korrekt. Eftersom det här är inställningar som faller inom säkerhetsområdet blockeras slutanvändaren om de utsätts för dessa inställningar och inte uppfyller lämplig version av Google Play-tjänster eller inte har åtkomst till Google Play-tjänster.

Intune appskyddsprinciper tillåter kontroll över appåtkomst till endast den Intune licensierade användaren. Ett av sätten att styra åtkomsten till appen är att kräva antingen Apples Touch ID eller Face ID på enheter som stöds. Intune implementerar ett beteende där Intune uppmanar användaren att ange en PIN-kod när nästa tidsgräns för inaktivitet uppfylls om det finns någon ändring i enhetens biometriska databas. Ändringar av biometriska data inkluderar tillägg eller borttagning av ett fingeravtryck eller ansikte. Om Intune användaren inte har en PIN-kod måste de konfigurera en Intune PIN.

Avsikten med detta är att fortsätta att skydda organisationens data i appen på appnivå. Den här funktionen är endast tillgänglig för iOS/iPadOS och kräver deltagande av program som integrerar Intune APP SDK för iOS/iPadOS, version 9.0.1 eller senare. Integrering av SDK är nödvändig så att beteendet kan tillämpas på målprogrammen. Den här integreringen sker löpande och är beroende av de specifika programteamen. Några appar som deltar är WXP, Outlook, Hanterad webbläsare och Yammer.

Intune appskyddsprincip kan inte styra iOS-resurstillägget utan att hantera enheten. Därför krypterar Intune "företagsdata" innan de delas utanför appen. Du kan verifiera detta genom att försöka öppna företagsfilen utanför den hanterade appen. Filen ska vara krypterad och får inte öppnas utanför den hanterade appen.

Intune appskyddsprinciper för åtkomst tillämpas i en viss ordning på slutanvändarens enheter när de försöker komma åt en riktad app från sina företagskonton. I allmänhet skulle en rensning ha företräde, följt av en blockering och sedan en varning som kan stängas. Om det till exempel är tillämpligt för den specifika användaren/appen tillämpas en lägsta iOS/iPadOS-operativsysteminställning som varnar en användare om att uppdatera sin iOS/iPadOS-version efter den lägsta iOS/iPadOS-operativsysteminställningen som blockerar användaren från åtkomst. Så i scenariot där IT-administratören konfigurerar operativsystemet iOS / iPadOS till 11.0.0.0 och minst iOS/iPadOS-operativsystemet (endast varning) till 11.1.0.0, medan enheten som försöker komma åt appen var på iOS/iPadOS 10, skulle slutanvändaren blockeras baserat på den mer restriktiva inställningen för min iOS/iPadOS-operativsystemversion som resulterar i blockerad åtkomst.

Vid hantering av olika typer av inställningar skulle ett krav på version av Intune App SDK ha företräde och sedan ett krav på appversion, följt av versionskravet för iOS/iPadOS-operativsystemet. Eventuella varningar för alla typer av inställningar i samma ordning markeras. Vi rekommenderar att kravet på Intune App SDK-versionen endast konfigureras efter vägledning från Intune-produktteamet för viktiga blockeringsscenarier.

Se även

• Distribuera Intune
• Skapa en distributionsplan
• Principinställningar för hantering av Android-mobilappar i Microsoft Intune
• Principinställningar för hantering av iOS/iPadOS-mobilappar
• Uppdatering av principer för Appskydd
• Verifiera dina programskyddsprinciper
• Lägg till principer för appkonfiguration för hanterade appar utan enhetsregistrering
• Få support i Microsoft Intune