översikt över Appskydd-principer

Appskydd principer (APP) ä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. En hanterad app är en app som har appskyddsprinciper som tillämpas på den och som kan hanteras av Intune.

Med mam-appskyddsprinciper (Mobile Application Management) kan du hantera och skydda organisationens data i ett program. Många produktivitetsappar, till exempel Microsoft Office-appar, kan hanteras av Intune MAM. Se den officiella listan över Microsoft Intune skyddade appar som är tillgängliga för offentlig användning.

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

Appskydd principer på enheter

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

  • Registrerade 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. Appskydd principer stöds inte för andra appar som ansluter till lokala Exchange- eller SharePoint-tjänster.

Fördelar med att använda Appskydd principer

De viktiga fördelarna med att använda Appskydd principer ä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.

  • Appskydd principer 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 Appskydd principer, och företag kan använda Appskydd principer 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 Appskydd principer medan den personliga enheten endast skyddas av Appskydd principer.

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 en MAM-princip baserat på det hanterade tillståndet. Så när du skapar en appskyddsprincip, bredvid Mål för alla apptyper, 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 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.

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

Viktigt

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

Appskydd dataskyddsramverk

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 mobil klientslutpunktshärdning har Microsoft infört taxonomi för appdataskyddsramverket för hantering av iOS- och Android-mobilappar.

APP-dataskyddsramverket är indelat 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- och användarpopulationen i APP.
  • Enterprise enhanced data protection (Level 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.
  • Enterprise high data protection (Level 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 specifika rekommendationer för varje konfigurationsnivå och de minsta appar som måste skyddas kan du läsa 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.

Konceptbild för dataflytt mellan appar utan principer på plats

Dataskydd med appskyddsprinciper (APP)

Du kan använda Appskydd principer 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 Appskydd principer. Appskydd principinställningar är:

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

Konceptbild som visar företagsdata som skyddas av principer

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

Bilden nedan visar de skyddslager som MDM och Appskydd principer erbjuder tillsammans.

Bild som visar hur Appskydd principer fungerar på BYOD-enheter

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

De Appskydd principerna ger mervärde genom att ange 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.

Bild som visar hur Appskydd principer fungerar på enheter utan registrering (icke-hanterade enheter)

För BYOD-enheter som inte har registrerats i någon MDM-lösning kan Appskydd principer 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 Intune App Wrapping Tool kan hanteras med hjälp av 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.

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.

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:

Appskydd principer för Microsoft Office-appar

Det finns några ytterligare krav som du vill vara medveten om när du använder Appskydd principer med Microsoft Office-appar.

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 Azure Active Directory-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-applikationer för affärsverksamhet eller ett företag som är länkat till deras Azure Active Directory-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.

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ö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).

Skype for Business

Det finns ytterligare krav för att använda Skype för företag. Se Skype för företag licenskrav. För Skype för företag (SfB) hybridkonfigurationer och lokala konfigurationer, se Hybrid Modern Auth for SfB and Exchange goes GA and Modern Auth for SfB OnPrem with Azure AD, respectively.

Appskydd global princip

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 till OneDrive- och SharePoint-klientappar.

Inställningarna, som görs tillgängliga för OneDrive Admin-konsolen, 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. It-tekniker kan redigera den här principen i Intune-konsolen 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.

Även om den globala principen gäller för alla användare i din klientorganisation åsidosätter alla standardprinciper för Intune appskydd dessa inställningar.

Obs!

Principinställningarna i OneDrive Admin Center uppdateras inte längre. Microsoft Enpoint Manager kan användas i stället. Mer information finns i Kontrollera åtkomsten till funktioner i OneDrive- och SharePoint-mobilappar.

Appskydd funktioner

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 Office-användare. 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. Appskydd principer 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å "personlig" kontext är att betrakta en användare som startar ett nytt dokument i Word. Detta betraktas som personlig kontext så Intune appskyddsprinciper inte tillämpas. När dokumentet har sparats på onedrive-kontot för företag 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-kod 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 begränsade webbplatser 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 som 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 hjälp av Intune App Wrapping Tool, 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 inställningen för Intune appskyddsprincip kontrollera åtkomstkraven igen efter (minuter) i Intune-administratörskonsolen. 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 härnäst. 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 principen Intune PIN-kod (eller företagets autentiseringsuppgifter). 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öretagsautentiseringsuppgifter, oavsett inställningsvärdet "Kontrollera åtkomstkraven igen efter (minuter)" efter en enhetsomstart.
  • 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. Uppmaningen 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.

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
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-uppmaningarna samtidigt bör det förväntade beteendet vara att Intune PIN-kod 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 app. Den här autentiseringen hanteras av Azure Active Directory 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-kod
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
I iOS/iPadOS lagras PIN-informationen på appnivå i nyckelringen som delas mellan appar med samma utgivare, till exempel alla förstapartsappar Microsoft appar. 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) visas 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 Intune SDK inte om det finns några andra appar på enheten med samma utgivare. Därför rensar Intune SDK 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, Yammer) 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 eventuella 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 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.

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 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:

  • Email (Exchange)
  • 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".

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 registrerats med Intune hantering av mobila enheter (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 hjälp av 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 beror på 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.

Appskydd upplevelse för iOS-enheter

Enhetens fingeravtryck eller ansikts-ID

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 timeoutvärde för inaktivitet uppfylls. Ä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 Yammer.

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

Som standard förhindrar Intune 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 skulle behöva göra ett Open inapp-namn> 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.

Åtkomstinställningar för flera Intune appskydd för samma uppsättning appar och användare

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 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 har ett Intune SDK-versionskrav företräde och sedan ett krav på appversion följt av krav på version av 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.

Appskydd för Android-enheter

Obs!

Appskydd principer stöds inte på Intune hanterade dedikerade Android Enterprise-enheter. Om dina användare på dedikerade Android Enterprise-enheter har APP-principer tillämpade för en annan enhet ska du utföra följande steg:

  1. Kontrollera att de enheter som du vill ha målet bara är Intune hanterade dedikerade enheter. Blockeringsprincipen börjar inte gälla om enheten hanteras av en MDM-provider från tredje part.

  2. Kontrollera att Företagsportal är installerat på den dedikerade enheten. Detta krävs för att APP-blockeringsprincipen ska börja gälla. Ingen slutanvändarinteraktion krävs i Företagsportal app på dedikerade enheter för att blockera APP-funktioner, så det finns inget krav på att göra Företagsportal app startbar av slutanvändare. Företagsportal behöver bara installeras på enheten. Du behöver till exempel inte tillåta att den visas ovanpå Hanterad hemskärm.

Observera att användare som är mål för APP-principer på icke-dedikerade enheter inte påverkas.

Microsoft Teams Android-enheter

Teams-appen på Microsoft Teams Android-enheter stöder inte APP (tar inte emot principer via Företagsportal-appen). 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 villkorsstyrd å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 Efterlevnadsprincip för att se om du har inställningar som inte stöds. Relaterad information finns i Villkorlig åtkomst som stöds och Intune enhetsefterlevnadsprinciper för Microsoft Teams Rum och Teams Android-enheter. Information om Microsoft Teams Rum finns i Villkorlig åtkomst och Intune efterlevnad för Microsoft Teams Rum.

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öretagsportal app- och Intune-appskydd

Mycket av appskyddsfunktionerna är inbyggda i den Företagsportal appen. Enhetsregistrering krävs inte även om Företagsportal-appen alltid krävs. För hantering av mobilprogram (MAM) behöver slutanvändaren bara ha Företagsportal-appen installerad på enheten.

Åtkomstinställningar för flera Intune appskydd för samma uppsättning appar och användare

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 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. Så 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 versionskrav för Android-operativsystem och krav på Android-korrigeringsversion. Sedan kontrolleras alla varningar för alla typer av inställningar i samma ordning.

Intune appskyddsprinciper och Googles SafetyNet-attestering för Android-enheter

Intune appskyddsprinciper ger administratörer möjlighet att kräva att slutanvändarenheter skickar Googles SafetyNet-attestering 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 Inställningen Google SafetyNet-attestering 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.

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

Intune 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 SafetyNet-attesterings-API

Intune använder Google Play Protect SafetyNet-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 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 integritetscertifierade & enheter som 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-/utvecklarsystemsbild

Teknisk information finns i Googles dokumentation om SafetyNet-attestering .

SafetyNet-enhetsattesteringsinställning och inställningen "jailbrokade/rotade enheter"

Google Play Protects SafetyNet 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 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 SafetyNet-enhetsattestering och Hotgenomsökning för 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.

Nästa steg

Så här skapar och distribuerar du 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