Vanliga frågor och svar om MAM och appskydd

MAM-översikt

Appskydd principer är regler som säkerställer att en organisations data förblir säkra eller finns i en hanterad app. En princip kan vara en regel som tillämpas när användaren försöker komma åt eller flytta "företagsdata" eller en uppsättning åtgärder som är förbjudna eller övervakade när användaren befinner sig i appen.

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

Om du tillämpar en MAM-princip på användaren utan att ange enhetshanteringstillståndet hämtar användaren MAM-principen på både BYOD-enheten och den Intune hanterade enheten. Du kan också tillämpa en MAM-princip baserat på enhetshanteringstillståndet. Så när du skapar en appskyddsprincip, bredvid Rikta till appar på alla enhetstyper, väljer du Nej. Gör sedan något av följande:

• 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 för att Intune hanterade enheter som för hanterade enheter från tredje part.
• Tillämpa endast en MAM-princip på oregistrerade enheter.

Mer information finns i Övervaka appskyddsprinciper.

Alla appar som har integrerats med Intune App SDK eller omslutits av Intune App Wrapping Tool kan hanteras med hjälp av 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. Se Lägga till användare och ge administratörsbehörighet till Intune för att lära dig hur du skapar Intune användare i Microsoft Entra ID.

• Slutanvändaren måste ha en licens för Microsoft Intune tilldelad till sitt Microsoft Entra konto. Se Hantera Intune licenser för att lära dig hur du tilldelar Intune licenser till slutanvändare.

• Slutanvändaren måste tillhöra en säkerhetsgrupp som omfattas av en appskyddsprincip. Samma appskyddsprincip måste vara riktad mot den specifika app som används. Appskydd principer kan skapas och distribueras i Microsoft Intune administrationscenter. 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.

Utvecklingsteamet för Intune SDK testar och underhåller aktivt stöd för appar som skapats med de inbyggda plattformarna Android, iOS/iPadOS (Obj-C, Swift), Xamarin och Xamarin.Forms. Vissa kunder har haft framgång med Intune SDK-integrering med andra plattformar som React Native och NativeScript, men vi ger inte uttrycklig vägledning eller plugin-program för apputvecklare som använder något annat än våra plattformar som stöds.

Intune App SDK kan använda Microsofts autentiseringsbibliotek för dess 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 länkad till sitt Microsoft Entra konto.

  Obs!

  Outlook-mobilappen stöder för närvarande endast Intune App Protection 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 som är länkad till deras Microsoft Entra konto. Prenumerationen måste innehålla Office-appar på mobila enheter och kan innehålla ett molnlagringskonto med OneDrive för företag. Microsoft 365-licenser kan tilldelas i Administrationscenter för Microsoft 365 genom att följa dessa instruktioner.

• Slutanvändaren måste ha en hanterad plats konfigurerad med hjälp av den detaljerade funktionen Spara som 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 distribueras till slutanvändaren.

  Obs!

  Office-mobilapparna stöder för närvarande endast SharePoint Online och inte lokal SharePoint.

Intune markerar alla data i appen som antingen "företagsdata" eller "personliga". Data anses vara "företag" när de kommer från en affärsplats. För Office-apparna betraktar Intune följande som affärsplatser: e-post (Exchange) eller molnlagring (OneDrive-app med ett OneDrive för företag konto).

Se Skype för företag licenskrav. För Skype för företag hybridkonfigurationer (SfB) och lokala konfigurationer finns i Hybrid Modern Auth for SfB and Exchange goes GA and Modern Auth for SfB on-premises with Microsoft Entra ID (Hybrid Modern Auth for SfB and Exchange goes GA and Modern Auth for SfB on-premises with Microsoft Entra ID, respectively).

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

Stöd för flera identiteter gör att appar med både företags- och konsumentpubliker (t.ex. Office-appar) kan släppas offentligt med Intune appskyddsfunktioner för "företagskontona".

Eftersom Outlook har en kombinerad e-postvy över både personliga och "företagsrelaterade" e-postmeddelanden, frågar Outlook-appen efter den Intune PIN-koden vid start.

Pin-koden (Personal Identification Number) är ett lösenord 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 är på väg att komma åt "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 fil. I appar med en enda identitet, till exempel verksamhetsspecifika appar som hanteras med hjälp av Intune App Wrapping Tool, uppmanas PIN-koden vid start, eftersom Intune App SDK vet att användarens upplevelse i appen alltid är "företagsbaserad".

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

• PIN-koden delas mellan appar i samma utgivare för att förbättra användbarheten: På iOS/iPadOS delas en app-PIN-kod mellan alla appar i samma apputgivare. På Android delas en app-PIN-kod mellan alla appar.
• Beteendet "Kontrollera åtkomstkraven igen efter (minuter)" efter en omstart av enheten: En "PIN-timer" spårar antalet minuter av inaktivitet som avgör när Intune appens PIN-kod ska visas härnäst. Pin-timern påverkas inte av omstart av enheten på iOS/iPadOS. Därför har omstart av enheten ingen effekt på antalet minuter som användaren har varit inaktiv från en iOS/iPadOS-app med Intune PIN-princip. På Android återställs PIN-timern vid omstart av enheten. Därför kommer Android-appar med Intune PIN-princip sannolikt att fråga efter en app-PIN-kod oavsett inställningsvärdet "Kontrollera åtkomstkraven igen efter (minuter)" efter en omstart av enheten.
• Den rullande typen av timer som är associerad med PIN-koden: När en PIN-kod har angetts för att få åtkomst till en app (app A), och appen lämnar förgrunden (huvudfokus) på enheten, återställs PIN-timern för pin-koden. Alla appar (app B) som delar den här PIN-koden uppmanar inte användaren att ange PIN-kod eftersom timern har återställts. Prompten visas igen när värdet "Kontrollera åtkomstkraven igen efter (minuter)" har uppfyllts igen.

För iOS/iPadOS-enheter, även om PIN-koden delas mellan appar från olika utgivare, visas uppmaningen igen när värdet Kontrollera åtkomstkraven igen efter (minuter) uppfylls igen för appen som inte är huvudfokus. En användare har till exempel app A från utgivare X och app B från utgivare Y, och dessa två appar delar samma PIN-kod. Användaren fokuserar på app A (förgrund) och app B minimeras. När värdet Kontrollera åtkomstkraven igen efter (minuter) är uppfyllt och användaren växlar till app B krävs PIN-koden.

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

PIN-koden ger endast 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 sin pin-kod för Intune app. Den här autentiseringen hanteras av Microsoft Entra ID via säker 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 dem. Kryptering är inte relaterat till appens PIN-kod, men är en egen appskyddsprincip.

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

MAM (på iOS/iPadOS) tillåter för närvarande PIN-kod på programnivå med alfanumeriska tecken och specialtecken (kallas "lösenord") som kräver medverkan av program (t.ex. WXP, Outlook, Managed Browser, Yammer) för att integrera Intune APP SDK för iOS/iPadOS. Utan detta tillämpas inte lösenordsinställningarna korrekt för målprogrammen. Det här var en funktion som släpptes i Intune SDK för iOS/iPadOS v. 7.1.12.

För att stödja den här funktionen och säkerställa bakåtkompatibilitet med tidigare versioner av Intune SDK för iOS/iPadOS hanteras alla PIN-koder (antingen numeriska eller lösenord) i 7.1.12+ separat från den numeriska PIN-koden i tidigare versioner av SDK. 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 detta sagt är de två PIN-koderna (för varje app) inte relaterade på något sätt, dvs. de måste följa appskyddsprincipen som tillämpas på appen. Därför kan användare bara konfigurera samma PIN-kod två gånger om apparna A och B har samma principer tillämpade (med avseende på PIN-kod).

Det här beteendet är specifikt för PIN-koden för iOS/iPadOS-program som är aktiverade med Intune Mobile App Management. Med tiden, när program inför 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. Ett exempel finns i anteckningen nedan.

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 krypteras.

Mer information om principinställningen för krypteringsappskydd finns i Inställningar för Android-appskyddsprinciper och iOS/iPadOS-appskyddsprinciper .

Endast data som har markerats som "företag" krypteras enligt IT-administratörens appskyddsprincip. Data anses vara "företag" när de kommer från en affärsplats. För Office-apparna betraktar Intune följande som affärsplatser: e-post (Exchange) eller molnlagring (OneDrive-app med ett OneDrive för företag konto). För verksamhetsspecifika appar som hanteras av Intune App Wrapping Tool betraktas alla appdata som "företagsbaserade".

Intune kan rensa appdata på tre olika sätt: fullständig enhetsrensning, selektiv rensning för MDM och selektiv MAM-rensning. Mer information om fjärrensning för MDM finns i Ta bort enheter med hjälp av rensning eller tillbakadragning. 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.

Rensning 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.

Se Ta bort enheter – dra tillbaka för att läsa om att ta bort företagsdata.

Selektiv rensning för MAM tar helt enkelt bort företagsappdata 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 beror på användarens identitet för att vara konsekvent mellan programmet och Intune App SDK. Det enda sättet att garantera detta är genom modern autentisering. Det finns scenarier där appar kan fungera med en lokal konfiguration, men de är varken 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 hjälp av Microsoft Edge-appen.

Företagsportal app- och Intune-appskydd

Intune appskyddsprinciper för åtkomst tillämpas i en specifik ordning på slutanvändarens enheter när de försöker komma åt en riktad app från sitt företagskonto. I allmänhet skulle ett block ha företräde och sedan en avvisande varning. Om det till exempel är tillämpligt för den specifika användaren/appen tillämpas en lägsta inställning för Android-korrigeringsversion som varnar en användare att utföra en korrigeringsuppgradering efter den lägsta android-korrigeringsversionsinställningen som blockerar användaren från åtkomst. I scenariot där IT-administratören konfigurerar den lägsta Android-korrigeringsversionen till 2018-03-01 och den lägsta Android-korrigeringsversionen (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 lägsta Android-korrigeringsversion som resulterar i blockerad åtkomst.

När du hanterar olika typer av inställningar har ett krav på appversion företräde, följt av krav på Android-operativsystemversion och krav på Android-korrigeringsversion. Sedan kontrolleras alla varningar för alla typer av inställningar i samma ordning.

Tjänsten Intune kontaktar Google Play vid ett icke-konfigurerbart intervall som bestäms av tjänstbelastningen. Alla IT-administratörskonfigurerade åtgärder för Google Plays inställning för enhetsintegritetskontroll kommer att vidtas baserat på det senaste rapporterade resultatet till Intune-tjänsten vid tidpunkten för villkorlig start. Om Googles resultat för enhetsintegritet är kompatibelt vidtas ingen åtgärd. Om Googles resultat för enhetsintegritet inte är kompatibelt vidtas den konfigurerade åtgärden av IT-administratören omedelbart. Om begäran till Google Play-enhetens integritetskontroll misslyckas av någon anledning, kommer det cachelagrade resultatet från den tidigare begäran att användas i upp till 24 timmar eller nästa omstart av enheten, som någonsin kommer först. Vid den tidpunkten blockerar Intune appskyddsprinciper åtkomst tills ett aktuellt resultat kan hämtas.

Instruktionerna för hur du gör detta varierar något beroende på enhet. Den allmänna processen innebär att gå till Google Play Store och sedan klicka på Mina appar & spel och klicka på resultatet av den senaste appgenomsökningen som tar dig till Play Protect-menyn. Kontrollera att växlingsknappen för Genomsök enhet efter säkerhetshot är aktiverad.

Intune använder GOOGLE Play Integrity API:er för att lägga till i våra befintliga rotidentifieringskontroller för oregistrerade enheter. Google har utvecklat och underhållit den här API-uppsättningen så att Android-appar kan implementeras om de inte vill att deras appar ska köras på rotade enheter. Android Pay-appen har till exempel införlivat detta. Google delar inte hela rotidentifieringskontrollerna offentligt, men vi förväntar oss att dessa API:er identifierar användare som har rotat sina enheter. Dessa användare kan sedan blockeras från åtkomst, eller så rensas deras företagskonton från deras 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 grundläggande integritet. "Kontrollera grundläggande integritet & certifierade enheter" berättar om enhetens kompatibilitet med Googles tjänster. Endast oförändrade enheter som har certifierats av Google kan klara den här kontrollen. Enheter som misslyckas omfattar följande:

• Enheter som inte uppfyller grundläggande integritet
• Enheter med en olåst startläsare
• Enheter med en anpassad systembild/ROM
• Enheter som tillverkaren inte ansökte om eller klarade Google-certifiering för
• Enheter med en systembild som skapats direkt från källfilerna för Android Open Source Program
• Enheter med en förhandsversion av en beta-/utvecklarsystembild

Teknisk information finns i Googles dokumentation om API:et för uppspelningsintegritet .

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 framtvingas från inställningen "jailbrokade/rotade enheter". Med detta sagt, om slutanvändaren har varit offline för länge spelar värdet "Offline respitperiod" in och all åtkomst till arbets- eller skoldata blockeras när det tidsinställda värdet nås tills nätverksåtkomst är tillgänglig. Om du aktiverar båda inställningarna kan du använda flera lager för att hålla slutanvändarnas enheter felfria, vilket är viktigt när slutanvändarna får åtkomst till arbets- eller skoldata på mobilen.

Både inställningarna "Play integrity verdict" och "Threat scan on apps" kräver att Googles beslutsamma version av Google Play Services fungerar korrekt. Eftersom det här är inställningar som faller inom säkerhetsområdet blockeras slutanvändaren om de har riktats mot de här inställningarna och inte uppfyller lämplig version av Google Play Services eller inte har någon åtkomst till Google Play-tjänster.

Intune appskyddsprinciper tillåter kontroll över appåtkomst till endast den Intune licensierade användaren. Ett sätt 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 om enhetens biometriska databas ändras Intune uppmanar användaren att ange en PIN-kod när nästa tidsgräns för inaktivitet uppnås. Ändringar av biometriska data omfattar tillägg eller borttagning av ett fingeravtryck eller ansikte. Om Intune användaren inte har en PIN-kod konfigureras en Intune PIN-kod.

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ändigt så att beteendet kan tillämpas på målprogrammen. Den här integreringen sker löpande och är beroende av de specifika programteamen. Vissa appar som deltar är WXP, Outlook, Managed Browser 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 kan inte öppnas utanför den hanterade appen.

Intune appskyddsprinciper för åtkomst tillämpas i en specifik ordning på slutanvändarens enheter när de försöker komma åt en riktad app från sitt företagskonto. I allmänhet skulle en rensning ha företräde, följt av ett block och sedan en avvisande varning. Om det till exempel är tillämpligt för den specifika användaren/appen tillämpas en lägsta inställning för iOS/iPadOS-operativsystem som varnar en användare att uppdatera sin iOS/iPadOS-version efter den lägsta iOS/iPadOS-operativsysteminställningen som blockerar användaren från åtkomst. I scenariot där IT-administratören konfigurerar operativsystemet min iOS/iPadOS till 11.0.0.0 och operativsystemet min iOS/iPadOS (endast varning) till 11.1.0.0, när enheten som försökte komma åt appen fanns på iOS/iPadOS 10, skulle slutanvändaren blockeras baserat på den mer restriktiva inställningen för den lägsta versionen av iOS/iPadOS-operativsystemet som resulterar i blockerad åtkomst.

När du hanterar olika typer av inställningar har ett Intune App SDK-versionskrav företräde och sedan ett krav på appversion följt av versionskravet för iOS/iPadOS-operativsystemet. Sedan kontrolleras alla varningar för alla typer av inställningar i samma ordning. Vi rekommenderar att versionskravet för Intune App SDK 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 mobilappar i iOS/iPadOS
• Appskydd principuppdatering
• Verifiera dina appskyddsprinciper
• Lägg till principer för appkonfiguration för hanterade appar utan enhetsregistrering
• Så här får du support i Microsoft Intune