Översikt över appskyddsprinciper

Intunes appskyddsprinciper (APP) är regler som säkerställer att en organisations data förblir säkra eller finns i en hanterad app. Med de här principerna kan du styra hur data används och delas av appar på mobila enheter. 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. En hanterad app i Intune är en skyddad app med Intune-appskyddsprinciper som tillämpas på den och som hanteras av Intune.

Det finns flera fördelar med att använda Intunes appskyddsprinciper, inklusive att skydda företagsdata på mobila enheter utan att kräva enhetsregistrering och styra hur data används och delas av appar på mobila enheter.

Exempel på användning av appskyddsprinciper med Microsoft Intune är:

• Kräva en PIN-kod eller fingeravtryck för åtkomst till företagets e-post på en mobil enhet
• Förhindra användare från att kopiera och klistra in företagsdata i personliga appar
• Begränsa åtkomsten till företagsdata till endast godkända appar

Många produktivitetsappar, till exempel Microsoft 365-appar (Office), kan hanteras med Intune MAM. Se den officiella listan över Microsoft Intune-skyddade appar som är tillgängliga för offentligt bruk.

Hur du kan skydda appdata

Dina anställda använder mobila enheter för både personliga uppgifter och arbetsuppgifter. Samtidigt som du ser till att dina anställda kan vara produktiva vill du förhindra dataförlust, avsiktlig och oavsiktlig. Du vill också skydda företagsdata som nås från enheter som inte hanteras av dig.

Du kan använda Intunes appskyddsprinciper oberoende av alla lösningar för hantering av mobila enheter (MDM). Detta oberoende hjälper dig att skydda företagets data med eller utan att registrera enheter i en enhetshanteringslösning. Genom att implementera principer på appnivå kan du begränsa åtkomsten till företagsresurser och hålla data inom IT-avdelningens ansvarsområde.

Appskyddsprinciper på enheter

Appskyddsprinciper kan konfigureras för appar som körs på enheter som är:

• Registrerad i Microsoft Intune: Dessa enheter är vanligtvis företagsägda.

• Registrerad i en MDM-lösning (Mobile Device Management) från tredje part: Dessa enheter är vanligtvis företagsägda.

  Obs!

  Hanteringsprinciper för mobilappar bör inte användas med hantering av mobilappar från tredje part eller säkra containerlösningar.

• Inte registrerad i någon lösning för hantering av mobila enheter: Dessa enheter är vanligtvis personalägda enheter som inte hanteras eller registreras i Intune eller andra MDM-lösningar.

Viktigt

Du kan skapa hanteringsprinciper för mobilappar för Office-mobilappar som ansluter till Microsoft 365-tjänster. Du kan också skydda åtkomsten till lokala Exchange-postlådor genom att skapa Intune-appskyddsprinciper för Outlook för iOS/iPadOS och Android aktiverat med modern hybridautentisering. Innan du använder den här funktionen måste du uppfylla kraven för Outlook för iOS/iPadOS och Android. Appskyddsprinciper stöds inte för andra appar som ansluter till lokala Exchange- eller SharePoint-tjänster.

Fördelar med att använda appskyddsprinciper

De viktiga fördelarna med att använda appskyddsprinciper är följande:

• Skydda företagets data på appnivå. Eftersom hantering av mobilappar inte kräver enhetshantering kan du skydda företagsdata på både hanterade och ohanterade enheter. Hanteringen är centrerad på användaridentiteten, vilket tar bort kravet på enhetshantering.

• Slutanvändarens produktivitet påverkas inte och principer tillämpas inte när du använder appen i en personlig kontext. Principerna tillämpas endast i en arbetskontext, vilket ger dig möjlighet att skydda företagets data utan att röra personliga data.

• Appskyddsprinciper ser till att appnivåskydden är på plats. Du kan till exempel:

  • Kräv en PIN-kod för att öppna en app i en arbetskontext
  • Kontrollera delning av data mellan appar
  • Förhindra att företagets appdata sparas på en personlig lagringsplats

• MDM, förutom MAM, ser till att enheten är skyddad. Du kan till exempel kräva en PIN-kod för att få åtkomst till enheten, eller så kan du distribuera hanterade appar till enheten. Du kan också distribuera appar till enheter via din MDM-lösning för att ge dig mer kontroll över apphantering.

Det finns ytterligare fördelar med att använda MDM med appskyddsprinciper, och företag kan använda appskyddsprinciper med och utan MDM på samma gång. Anta till exempel att en anställd använder både en telefon som utfärdats av företaget och en egen personlig surfplatta. Företagstelefonen registreras i MDM och skyddas av appskyddsprinciper medan den personliga enheten endast skyddas av appskyddsprinciper.

Om du tillämpar en MAM-princip på användaren utan att ange enhetstillståndet får användaren MAM-principen på både BYOD-enheten och den Intune-hanterade enheten. Du kan också tillämpa MAM-principer baserat på enhetshanteringstillståndet. Mer information finns i Rikta appskyddsprinciper baserat på enhetshanteringstillstånd. När du skapar en appskyddsprincip väljer du Nej bredvid Mål för alla apptyper. 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 endast en MAM-princip på oregistrerade enheter.

Plattformar som stöds för appskyddsprinciper

Intune erbjuder en mängd funktioner som hjälper dig att få de appar du behöver på de enheter som du vill köra dem på. Mer information finns i Apphanteringsfunktioner per plattform.

Plattformsstödet för Intune-appskyddsprinciper överensstämmer med plattformsstödet för Mobila Office-program för Android- och iOS/iPadOS-enheter. Mer information finns i avsnittet Mobilappar i Systemkrav för Office.

Förhandsversion: Dessutom kan du skapa appskyddsprinciper för Windows-enheter. Mer information finns i Appskyddsupplevelse för Windows-enheter.

Viktigt

Intune-företagsportalen krävs på enheten för att ta emot appskyddsprinciper på Android.

Dataskyddsramverk för appskyddsprinciper

De alternativ som är tillgängliga i appskyddsprinciper (APP) gör det möjligt för organisationer att anpassa skyddet efter deras specifika behov. För vissa kanske det inte är uppenbart vilka principinställningar som krävs för att implementera ett fullständigt scenario. För att hjälpa organisationer att prioritera härdning av slutpunkt för mobilklient har Microsoft infört taxonomi för sitt APP-dataskyddsramverk för hantering av iOS- och Android-mobilappar.

APP-dataskyddsramverket är uppdelat i tre olika konfigurationsnivåer, där varje nivå bygger på föregående nivå:

• Grundläggande dataskydd för företag (nivå 1) säkerställer att appar skyddas med en PIN-kod och krypteras och utför selektiva rensningsåtgärder. För Android-enheter validerar den här nivån Android-enhetsattestering. Det här är en konfiguration på ingångsnivå som ger liknande dataskyddskontroll i Exchange Online-postlådeprinciper och introducerar IT-avdelningen och användarpopulationen i APP.
• Utökat dataskydd för företag (nivå 2) introducerar mekanismer för skydd mot dataläckage i APP och minimikrav på operativsystem. Det här är den konfiguration som gäller för de flesta mobila användare som har åtkomst till arbets- eller skoldata.
• Högt dataskydd för företag (Nivå 3) introducerar avancerade dataskyddsmekanismer, förbättrad PIN-konfiguration och APP Mobile Threat Defense. Den här konfigurationen är önskvärd för användare som har åtkomst till data med hög risk.

Om du vill se de specifika rekommendationerna för varje konfigurationsnivå och de lägsta appar som måste skyddas kan du granska dataskyddsramverket med hjälp av appskyddsprinciper.

Så skyddar appskyddsprinciper appdata

Appar utan appskyddsprinciper

När appar används utan begränsningar kan företagsdata och personliga data blandas. Företagsdata kan hamna på platser som personlig lagring eller överföras till appar utöver din kontroll och resultera i dataförlust. Pilarna i följande diagram visar obegränsad dataförflyttning mellan både företagsappar och personliga appar och lagringsplatser.

Dataskydd med appskyddsprinciper (APP)

Du kan använda appskyddsprinciper för att förhindra att företagsdata sparas till enhetens lokala lagring (se bilden nedan). Du kan också begränsa dataflytten till andra appar som inte skyddas av appskyddsprinciper. Inställningarna för appskyddsprinciper omfattar:

• Dataflyttprinciper som Spara kopior av organisationsdata och Begränsa klipp ut, kopiera och klistra in.
• Åtkomstprincipinställningar som Kräv enkel PIN-kod för åtkomst och Blockera hanterade appar från att köras på jailbrokade eller rotade enheter.

Dataskydd med APP på enheter som hanteras av en MDM-lösning

Bilden nedan visar de skyddslager som MDM- och appskyddsprinciper erbjuder tillsammans.

MDM-lösningen tillför värde genom att tillhandahålla följande:

• Registrerar enheten
• Distribuerar apparna till enheten
• Tillhandahåller löpande enhetsefterlevnad och hantering

Appskyddsprinciperna ger mervärde genom att tillhandahålla följande:

• Skydda företagets data från att läcka till konsumentappar och konsumenttjänster
• Tillämpa begränsningar som Spara som, Urklipp eller PIN-kod för klientappar
• Rensa företagsdata när det behövs från appar utan att ta bort dessa appar från enheten

Dataskydd med APP för enheter utan registrering

Följande diagram visar hur dataskyddsprinciperna fungerar på appnivå utan MDM.

För BYOD-enheter som inte har registrerats i någon MDM-lösning kan appskyddsprinciper skydda företagets data på appnivå. Det finns dock vissa begränsningar att känna till, till exempel:

• Du kan inte distribuera appar till enheten. Slutanvändaren måste hämta apparna från butiken.
• Du kan inte etablera certifikatprofiler på dessa enheter.
• Du kan inte etablera företagsinställningar för Wi-Fi och VPN på dessa enheter.

Appar som du kan hantera med appskyddsprinciper

Alla appar som har integrerats med Intune SDK eller omslutits av Intunes programhanteringsverktyg kan hanteras med intune-appskyddsprinciper. Se den officiella listan över Microsoft Intune-skyddade appar som har skapats med hjälp av dessa verktyg och som är tillgängliga för offentligt bruk.

Intune SDK-utvecklingsteamet testar och underhåller aktivt stödet för appar som skapats med de inbyggda plattformarna Android, iOS/iPadOS (Obj-C, Swift), Xamarin och Xamarin.Forms. Vissa kunder har lyckats 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.

Slutanvändarkrav för att använda appskyddsprinciper

Följande lista innehåller slutanvändarkraven för att använda appskyddsprinciper i en Intune-hanterad app:

• Slutanvändaren måste ha ett Microsoft Entra-konto. Se Lägga till användare och ge administrativ behö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 som tilldelats deras 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. Appskyddsprinciper kan skapas och distribueras i administrationscentret för Microsoft Intune. Säkerhetsgrupper kan för närvarande skapas i administrationscentret för Microsoft 365.

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

Appskyddsprinciper för Microsoft 365-appar (Office)

Det finns några ytterligare krav som du vill vara medveten om när du använder appskyddsprinciper med Microsoft 365-appar (Office).

Viktigt

Intune-hantering av mobilprogram (MAM) på Android kräver registrering av Microsoft Entra-ID-enheter för Microsoft 365-appar. För att förbättra säkerheten måste Android-enheter registreras med Microsoft Entra-ID för att fortsätta ta emot MAM-principer för Microsoft 365-appar.

När du kommer åt Microsoft 365-appar som är riktade mot en MAM-princip kan användarna uppmanas att autentisera om enheten inte redan är registrerad med Entra-ID. Användarna måste slutföra autentiserings- och registreringsprocessen för att få åtkomst till sina Microsoft 365 MAM-aktiverade program.

Om du har principer för villkorsstyrd åtkomst eller multifaktorautentisering aktiverade bör enheterna redan vara registrerade och användarna kommer inte att märka någon ändring.

Om du vill visa vilka enheter som är registrerade går du till administrationscentret> för Microsoft EntraEnheter>Rapporten Alla enheter, filtrerar efter operativsystem och sorterar efter Registrerad. Relaterad information finns i Hantera enhetsidentiteter med hjälp av administrationscentret för Microsoft Entra.

Outlook-mobilapp

De ytterligare kraven för att använda Outlook-mobilappen är följande:

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

Word, Excel och PowerPoint

De ytterligare kraven för att använda Word-, Excel- och PowerPoint-apparna omfattar följande:

• Slutanvändaren måste ha en licens för Microsoft 365-appar för företag eller företag som är länkade 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 administrationscentret 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.

Hanterad plats som behövs för Office

En hanterad plats (t.ex. OneDrive) krävs för Office. Intune markerar alla data i appen som antingen "företag" 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).

Skype för företag

Det finns ytterligare krav för att använda Skype för företag. Se Licenskrav för Skype för företag . För hybridkonfigurationer i Skype för företag (SfB) och lokala konfigurationer kan du läsa Hybrid Modern Auth for SfB and Exchange goes GA and Modern Auth for SfB OnPrem with Microsoft Entra ID(Hybrid Modern Auth for SfB and Exchange goes GA and Modern Auth for SfB OnPrem with Microsoft Entra ID, respectively).

Global princip för appskydd

Om en OneDrive-administratör bläddrar till admin.onedrive.com och väljer Enhetsåtkomst kan de ställa in kontroller för hantering av mobilprogram på OneDrive- och SharePoint-klientappar.

Inställningarna, som görs tillgängliga för OneDrive-administratörskonsolen, konfigurerar en särskild Intune-appskyddsprincip som kallas den globala principen. Den här globala principen gäller för alla användare i din klientorganisation och har inget sätt att styra principinriktningen.

När de har aktiverats skyddas OneDrive- och SharePoint-apparna för iOS/iPadOS och Android med de valda inställningarna som standard. En IT-tekniker kan redigera den här principen i administrationscentret för Microsoft Intune för att lägga till fler riktade appar och ändra eventuella principinställningar.

Som standard kan det bara finnas en global princip per klientorganisation. Du kan dock använda Intune Graph-API:er för att skapa extra globala principer per klientorganisation, men det rekommenderas inte. Vi rekommenderar inte att du skapar extra globala principer eftersom det kan bli komplicerat att felsöka implementeringen av en sådan princip.

Den globala principen gäller för alla användare i din klientorganisation, men alla standardprinciper för Intune-appskydd åsidosätter dessa inställningar.

Obs!

Principinställningarna i administrationscentret för OneDrive uppdateras inte längre. Microsoft Intune kan användas i stället. Mer information finns i Kontrollera åtkomst till funktioner i OneDrive- och SharePoint-mobilappar.

Appskyddsfunktioner

Flera identiteter

Stöd för flera identiteter gör att en app kan stödja flera målgrupper. Dessa målgrupper är både "företagsanvändare" och "personliga" användare. Arbets- och skolkonton används av "företags" målgrupper, medan personliga konton skulle användas för konsumentpubliker, till exempel Microsoft 365-användare (Office). En app som stöder flera identiteter kan släppas offentligt, där appskyddsprinciper endast gäller när appen används i arbets- och skolkontexten ("företag"). Stöd för flera identiteter använder Intune SDK för 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. Appskyddsprinciper kan användas för att förhindra överföring av arbets- eller skolkontodata till personliga konton i appen med flera identiteter, personliga konton i andra appar eller personliga appar.

Viktigt

Oavsett om en app stöder flera identiteter kan endast en enda "företagsidentitet" ha en Intune-appskyddsprincip tillämpad.

Ett exempel på en "personlig" kontext är att betrakta en användare som startar ett nytt dokument i Word. Detta betraktas som en personlig kontext, så Intune-appskyddsprinciper tillämpas inte. När dokumentet har sparats på onedrive-kontot "corporate" betraktas det som "företagskontext" och Intune-appskyddsprinciper tillämpas.

Tänk på följande exempel för arbets- eller företagskontexten:

• En användare startar OneDrive-appen med sitt arbetskonto. I arbetskontexten kan de inte flytta filer till en personlig lagringsplats. Senare, när de använder OneDrive med sitt personliga konto, kan de kopiera och flytta data från sin personliga OneDrive utan begränsningar.
• En användare börjar skriva ett e-postmeddelande i Outlook-appen. När ämnet eller meddelandetexten har fyllts i kan användaren inte växla FROM-adressen från arbetskontexten till den personliga kontexten eftersom ämnes- och meddelandetexten skyddas av appskyddsprincipen.

Obs!

Outlook har en kombinerad e-postvy över både "personliga" och "företagsrelaterade" e-postmeddelanden. I det här fallet frågar Outlook-appen efter Intune-PIN-koden vid start.

Viktigt

Även om Edge är i "företagskontext" kan användare avsiktligt flytta OneDrive-kontextfiler för "företag" till en okänd personlig molnlagringsplats. Undvik detta genom att läsa Hantera webbplatser för att tillåta uppladdning av filer och konfigurera listan över tillåtna/blockerade webbplatser för Edge.

PIN-kod för Intune-app

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.

PIN-fråga
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 eller 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 intune-programhanteringsverktyget, uppmanas PIN-koden vid start, eftersom Intune SDK vet att användarens upplevelse i appen alltid är "företag".

PIN-fråga eller fråga om företagets autentiseringsuppgifter, frekvens
IT-administratören kan definiera intune-appskyddsprincipinställningen Kontrollera åtkomstkraven igen efter (minuter) i administrationscentret för Microsoft Intune. Den här inställningen anger hur lång tid som krävs innan åtkomstkraven kontrolleras på enheten, och programmets PIN-skärm, eller företagets uppmaning om autentiseringsuppgifter, 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. Till exempel delar alla Microsoft-appar samma PIN-kod. På Android delas en app-PIN-kod mellan alla appar.
• Kontrollera åtkomstkraven igen efter (minuter) efter en omstart av enheten:
  En timer spårar antalet minuter av inaktivitet som avgör när intune-appens PIN-kod ska visas eller företagets uppmaning om autentiseringsuppgifter nästa gång. På iOS/iPadOS påverkas inte timern av omstart av enheten. Omstarten av enheten påverkar därför inte antalet minuter som användaren har varit inaktiv från en iOS/iPadOS-app med intune-principen för PIN-kod (eller företagets autentiseringsuppgifter) som mål. På Android återställs timern vid omstart av enheten. Därför kommer Android-appar med Intune PIN-kod (eller företagets autentiseringsuppgifter) sannolikt att fråga efter en app-PIN-kod eller fråga om företagets autentiseringsuppgifter, 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 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 det viktigaste indatafokuset. 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.

Obs!

För att verifiera användarens åtkomstkrav oftare (t.ex. PIN-fråga), särskilt för en app som används ofta, rekommenderar vi att du minskar värdet för inställningen "Kontrollera åtkomstkraven igen efter (minuter)".

Inbyggda app-PIN-koder för Outlook och OneDrive
Intune-PIN-koden fungerar baserat på en inaktivitetsbaserad timer (värdet för Kontrollera åtkomstkraven igen efter (minuter)). Därför visas Pin-prompter i Intune oberoende av de inbyggda pin-prompterna för appar 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 Intune PIN-koden har företräde.

Intune PIN-säkerhet
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-appen. Den här autentiseringen hanteras av Microsoft Entra-ID via säker tokenutbyte och är inte transparent för Intune 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.

Skydda mot råstyrkeattacker och Intune-PIN-koden
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 SDK rensa "företagsdata" i appen.

Intune PIN-kod och en selektiv rensning
På iOS/iPadOS lagras PIN-informationen på appnivå i nyckelringen som delas mellan appar med samma utgivare, till exempel alla Microsoft-appar från första part. Den här PIN-koden är också kopplad till ett slutanvändarkonto. En selektiv rensning av en app bör inte påverka en annan app.

En PIN-kod för Outlook för den inloggade användaren lagras till exempel i en delad nyckelring. När användaren loggar in på OneDrive (även publicerat av Microsoft) ser de samma PIN-kod som Outlook eftersom den använder samma delade nyckelring. När du loggar ut från Outlook eller rensar användardata i Outlook rensar Inte Intune SDK den nyckelringen eftersom OneDrive fortfarande använder pin-koden. Därför rensar selektiva rensningar inte den delade nyckelringen, inklusive PIN-koden. Det här beteendet förblir detsamma även om det bara finns en app av en utgivare på enheten.

Eftersom PIN-koden delas mellan appar med samma utgivare, om rensningen går till en enda app, vet Inte Intune SDK om det finns några andra appar på enheten med samma utgivare. Intune SDK rensar därför inte PIN-koden eftersom den fortfarande kan användas för andra appar. Förväntningen är att appens PIN-kod ska rensas när den senaste appen från utgivaren tas bort så småningom som en del av viss rensning av operativsystemet.

Om du ser att PIN-koden rensas på vissa enheter händer förmodligen följande: Eftersom PIN-koden är kopplad till en identitet uppmanas användaren att ange en ny PIN-kod om användaren har loggat in med ett annat konto efter en rensning. Men om de loggar in med ett tidigare befintligt konto kan en PIN-kod som lagras i nyckelringen redan användas för att logga in.

Vill du ange en PIN-kod två gånger för appar från samma utgivare?
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, Viva Engage) för att integrera Intune SDK för iOS. 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 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. En annan ändring infördes i Intune SDK för iOS v 14.6.0 som gör att alla PIN-koder i 14.6.0+ hanteras separat från pin-koder i tidigare versioner av SDK.

Om en enhet har program med Intune SDK för iOS-versioner före 7.1.12 OCH efter 7.1.12 från samma utgivare (eller versioner före 14.6.0 OCH efter 14.6.0) måste de därför konfigurera två PIN-koder. De två PIN-koderna (för varje app) är inte relaterade på något sätt (dvs. de måste följa den appskyddsprincip 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 för appar från samma utgivare. Ett exempel finns i anteckningen nedan.

Obs!

Om app A till exempel har skapats med en version före 7.1.12 (eller 14.6.0) och app B har skapats med en version som är större än eller lika med 7.1.12 (eller 14.6.0) från samma utgivare, måste slutanvändaren konfigurera PIN-koder separat för A och B om båda är installerade på en iOS/iPadOS-enhet.

Om en app C som har SDK version 7.1.9 (eller 14.5.0) är installerad på enheten delar den samma PIN-kod som app A.

En app D som skapats med 7.1.14 (eller 14.6.2) delar samma PIN-kod som app B.

Om endast apparna A och C är installerade på en enhet måste en PIN-kod anges. Detsamma gäller om endast appar B och D är installerade på en enhet.

Appdatakryptering

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.

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

Data som är krypterade
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)
• Molnlagring (OneDrive-app med ett OneDrive för företag-konto)

För verksamhetsspecifika appar som hanteras av Intunes programhanteringsverktyg betraktas alla appdata som "företagsbaserade".

Selektiv rensning

Fjärrensa data
Intune kan rensa appdata på tre olika sätt:

• Fullständig enhetsrensning
• Selektiv rensning för MDM
• 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.

Fullständig enhetsrensning 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.

Obs!

Fullständig enhetsrensning och selektiv rensning för MDM kan endast uppnås på enheter som har registrerats med Hantering av mobila enheter i Intune (MDM).

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

Selektiv rensning för MAM
Selektiv rensning för MAM tar helt enkelt bort företagsappdata från en app. Begäran initieras med Intune. 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 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.

När lokala tjänster (lokala) inte fungerar med Intune-skyddade appar
Intune-appskydd är beroende av användarens identitet för att vara konsekvent mellan programmet och Intune 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.

Säkert sätt att öppna webblänkar från hanterade appar
IT-administratören kan distribuera och ange en appskyddsprincip för Microsoft Edge, en webbläsare som enkelt kan hanteras med Intune. IT-administratören kan kräva att alla webblänkar i Intune-hanterade appar öppnas med hjälp av en hanterad webbläsare.

Appskyddsupplevelse för iOS-enheter

Enhetens fingeravtryck eller ansikts-ID

Intunes 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 Intune uppmanar användaren att ange en PIN-kod när nästa timeout-värde för inaktivitet uppfylls om enhetens biometriska databas ändras. Ändringar av biometriska data omfattar tillägg eller borttagning av ett fingeravtryck eller ansikte. Om Intune-användaren inte har någon PIN-kod konfigureras en Intune-PIN-kod.

Syftet med den här processen är att fortsätta hålla organisationens data i appen säkra och skyddade på appnivå. Den här funktionen är endast tillgänglig för iOS/iPadOS och kräver deltagande av program som integrerar Intune 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 Viva Engage.

iOS-resurstillägg

Du kan använda iOS/iPadOS-delningstillägget för att öppna arbets- eller skoldata i ohanterade appar, även om dataöverföringsprincipen är inställd på endast hanterade appar eller inga appar. Intunes appskyddsprincip kan inte styra iOS/iPadOS-resurstillägget utan att hantera enheten. Därför krypterar Intune "företagsdata" innan de delas utanför appen. Du kan verifiera det här krypteringsbeteendet genom att försöka öppna en "företagsfil" utanför den hanterade appen. Filen ska vara krypterad och kan inte öppnas utanför den hanterade appen.

Stöd för Universella länkar

Som standard förhindrar Intunes appskyddsprinciper åtkomst till otillåtet programinnehåll. I iOS/iPadOS finns det funktioner för att öppna specifikt innehåll eller program med universella länkar.

Användare kan inaktivera en apps universella länkar genom att besöka dem i Safari och välja Öppna på ny flik eller Öppna. För att kunna använda universella länkar med Intune-appskyddsprinciper är det viktigt att återaktivera de universella länkarna. Slutanvändaren måste göra ett Openin-appnamn>i< Safari efter att länge ha tryckt på en motsvarande länk. Detta bör uppmana ytterligare skyddade appar att dirigera alla universella länkar till det skyddade programmet på enheten.

Flera åtkomstinställningar för Intune-appskydd för samma uppsättning appar och användare

Intunes 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 det lägsta iOS-operativsystemet till 11.0.0.0 och det lägsta iOS-operativsystemet (endast varning) till 11.1.0.0, medan enheten som försöker komma åt appen var på iOS 10, skulle slutanvändaren blockeras baserat på den mer restriktiva inställningen för lägsta iOS-operativsystemversion som resulterar i blockerad åtkomst.

När du hanterar olika typer av inställningar skulle ett krav på Intune SDK-version ha 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 SDK endast konfigureras efter vägledning från Intune-produktteamet för viktiga blockeringsscenarier.

Appskyddsupplevelse för Android-enheter

Obs!

Appskyddsprinciper (APP) stöds inte på Intune-hanterade Dedikerade Android Enterprise-enheter utan läget Delad enhet. På dessa enheter krävs installation av företagsportalen för att en appblockeringsprincip ska börja gälla utan att användaren påverkas. Appskyddsprinciper stöds på Intune-hanterade dedikerade Android Enterprise-enheter med läget Delad enhet, samt på användarlösa AOSP-enheter som använder läget Delad enhet.

Microsoft Teams Android-enheter

Teams-appen på Microsoft Teams Android-enheter stöder inte APP (tar inte emot principer via företagsportalappen). Det innebär att inställningar för appskyddsprinciper inte tillämpas på Teams på Microsoft Teams Android-enheter. Om du har konfigurerat appskyddsprinciper för dessa enheter bör du överväga att skapa en grupp teams-enhetsanvändare och exkludera den gruppen från relaterade appskyddsprinciper. Överväg även att ändra din Intune-registreringsprincip, principer för villkorlig åtkomst och Intune-efterlevnadsprinciper så att de har inställningar som stöds. Om du inte kan ändra dina befintliga principer måste du konfigurera (exkludera) enhetsfilter. Kontrollera varje inställning mot den befintliga konfigurationen för villkorsstyrd åtkomst och Intune-efterlevnadsprincipen för att se om du har inställningar som inte stöds. Relaterad information finns i Villkorlig åtkomst som stöds och Efterlevnadsprinciper för Intune-enheter för Microsoft Teams-rum och Teams Android-enheter. Information om Microsoft Teams-rum finns i Villkorsstyrd åtkomst och Intune-efterlevnad för Microsoft Teams Rooms.

Enhetens biometriska autentisering

För Android-enheter som stöder biometrisk autentisering kan du tillåta slutanvändare att använda fingeravtryck eller ansiktslåsning, beroende på vad deras Android-enhet stöder. Du kan konfigurera om alla biometriska typer utöver fingeravtryck kan användas för att autentisera. Observera att fingeravtryck och ansiktslåsning endast är tillgängliga för enheter som har tillverkats för att stödja dessa biometriska typer och kör rätt version av Android. Android 6 och senare krävs för fingeravtryck, och Android 10 och senare krävs för ansiktslåsning.

Företagsportalapp och Intune-appskydd

En stor del av appskyddsfunktionerna är inbyggda i företagsportalappen. Enhetsregistrering krävs inte även om företagsportalappen alltid krävs. För hantering av mobilprogram (MAM) behöver slutanvändaren bara ha företagsportalappen installerad på enheten.

Flera åtkomstinställningar för Intune-appskydd för samma uppsättning appar och användare

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

Intunes appskyddsprinciper och Google Play-enhetens integritetskontroll för Android-enheter

Intunes appskyddsprinciper ger administratörer möjlighet att kräva att slutanvändarenheter klarar Google Plays enhetsintegritetskontroll för Android-enheter. En ny Google Play-tjänstbestämning rapporteras till IT-administratören vid ett intervall som bestäms av Intune-tjänsten. Hur ofta tjänstanropet görs begränsas på grund av belastningen, vilket innebär att det här värdet underhålls internt och inte kan konfigureras. Alla IT-administratörskonfigurerade åtgärder för Googles enhetsintegritetsinställning kommer att vidtas baserat på det senaste rapporterade resultatet till Intune-tjänsten vid tidpunkten för villkorlig start. Om det inte finns några data tillåts åtkomst beroende på att inga andra villkorliga startkontroller misslyckas, och Google Play-tjänsten "tur och retur" för att fastställa attesteringsresultat börjar i serverdelen och frågar användaren asynkront om enheten har misslyckats. Om det finns inaktuella data blockeras eller tillåts åtkomst beroende på det senaste rapporterade resultatet, och på samma sätt startar en Google Play-tjänst "tur och retur" för att fastställa attesteringsresultat och uppmanar användaren asynkront om enheten har misslyckats.

Intunes appskyddsprinciper och Googles Verify Apps-API för Android-enheter

Intunes appskyddsprinciper ger administratörer möjlighet att kräva att slutanvändarenheter skickar signaler via Googles Verify Apps-API för Android-enheter. 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.

Googles API för uppspelningsintegritet

Intune använder Googles API:er för uppspelningsintegritet 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 för Android-appar 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 den grundläggande integriteten som 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 Googles API för uppspelningsintegritet .

Inställningen Spela integritetsutslag och inställningen "jailbrokade/rotade enheter"

Bedömning av spelintegritet 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 slutanvändarnas enheter vara felfria i flera lager, vilket är viktigt när slutanvändarna får åtkomst till arbets- eller skoldata på mobilen.

Google Play Protect-API:er och Google Play-tjänster

De inställningar för appskyddsprinciper som använder Google Play Protect-API:er kräver att Google Play-tjänster fungerar. Både inställningarna för Play-integritet och Hotgenomsökning i appar 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.

Förhandsversion: Appskyddsupplevelse för Windows-enheter

Det finns två kategorier av principinställningar: Dataskydd och hälsokontroller. Termen principhanterad app refererar till appar som har konfigurerats med appskyddsprinciper.

Dataskydd

Inställningarna för dataskydd påverkar organisationens data och kontext. Som administratör kan du styra dataflytten till och från organisationens skydd. Organisationskontexten definieras av dokument, tjänster och webbplatser som nås av det angivna organisationskontot. Följande principinställningar hjälper dig att styra externa data som tas emot i organisationskontexten och organisationsdata som skickas från organisationskontexten.

Hälsokontroller

Med hälsokontroller kan du konfigurera funktioner för villkorlig start. För att göra detta måste du ange villkor för hälsokontroll för din appskyddsprincip. Välj en inställning och ange det värde som användarna måste uppfylla för att få åtkomst till dina organisationsdata. Välj sedan den åtgärd som du vill vidta om användarna inte uppfyller dina villkor. I vissa fall kan flera åtgärder konfigureras för en enda inställning.

Nästa steg

Skapa och distribuera appskyddsprinciper med Microsoft Intune

Tillgängliga inställningar för Android-appskyddsprinciper med Microsoft Intune

Tillgängliga inställningar för iOS/iPadOS-appskyddsprinciper med Microsoft Intune