Planera och kontrollera Sophos Mobile-compliancepolicyer på ett säkert sätt

En compliancepolicy är varken ett certifikat eller en enhetsprofil. Den utvärderar utvalda regler för registrerade enheter och kan utlösa åtgärder vid regelöverträdelser. Det avgörande är vilken produktutgåva som faktiskt används (Sophos Mobile eller Sophos Mobile Threat Defense), plattform och OS-version, företagsägd eller privat enhet, registrerings- och hanteringsläge, eventuell Intercept X for Mobile-app (IXM) som hanteras av Sophos Mobile samt tilldelad enhetsgrupp. Att en regel eller PCI-/HIPAA-mall visas bevisar varken att den gäller för alla enheter eller att någon certifiering finns.

Före varje ändring i produktion: Check now kontrollerar alla registrerade enheter och utför konfigurerade åtgärder. Att skapa eller ändra en policy och tilldela den till en grupp är inte heller skrivskyddade steg. Fastställ först hela målgruppen och hur ändringen kan återställas; använd inte produktionsflottan för att prova dig fram.

Vad utvärderas egentligen?

Välj först produktutgåva och kontrollera sedan plattform, OS och registreringsläge: Med Android Enterprise fully managed hanterar MDM hela enheten; med Apple User Enrollment registreras privata Apple-enheter med begränsad hantering; supervised avser övervakade iPhone- och iPad-enheter. En IXM-app som hanteras av Sophos Mobile bevisar inte i sig att enheten har fullständig Mobile Device Management (MDM). Jämför i den egna miljön vilka regler som finns för den utgåva och det läge som faktiskt används; blanda inte ihop Sophos Mobiles och Sophos Mobile Threat Defenses regler och åtgärder.

Regler anger vilka enhetsfunktioner eller tillstånd som är tillåtna, förbjudna eller obligatoriska. Åtgärden vid en överträdelse väljs separat; ett compliancekriterium bevisar inte i sig att en enhetsinställning aktivt ändras eller tvingas igenom.

För att skapa en policy i Sophos Mobile eller den fristående utgåvan Sophos Mobile Threat Defense, öppna Compliance policies, klicka på Create compliance policy och välj mallen Default, PCI eller HIPAA. Ange ett namn och eventuellt en beskrivning; valet av mall begränsar inte senare inställningar. Endast mallen Default saknar förinställda åtgärder; PCI/HIPAA kan redan innehålla åtgärder. Sophos beskriver reglerna och åtgärderna i PCI-/HIPAA-mallarna som baserade på HIPAA och PCI DSS. Ordningen mellan mallarna och standarderna i dokumentationen är dock tvetydig; här ska därför ingen enskild mall kopplas till en viss standard utifrån den ordningen. Plattformens flik måste aktiveras med Enable platform: Om rutan inte är markerad utförs ingen compliancekontroll för enheter på den plattformen. Allvarlighetsgraderna high, medium, low är fast knutna till reglerna; de är inte samma sak som en fritt valbar åtgärd. Vid policyplaneringen hjälper de till att bedöma varje regels betydelse och välja en lämplig åtgärd vid en överträdelse. Detta innebär inget godkännande att utföra en åtgärd under en incident. Highlight rules i den fullständiga utgåvan hjälper till att markera en hanteringstyp men bevisar inte att en regel gäller för varje enhet av den typen.

Klicka på Save först när reglerna och de tillhörande åtgärderna har ställts in och kontrollerats för alla plattformar som behövs. Då sparas policyn under det angivna namnet; den efterföljande grupptilldelningen görs separat efter kontrollerna som beskrivs nedan.

Sophos Mobile (fullständig utgåva/MDM): Utöver plattformsberoende hanterings- och OS-regler kan IXM-signaler användas om Sophos Mobile hanterar appen. Som åtgärd per regel kan du välja Deny email, Lock container, Set health, Create alert och Transfer task bundle; respektive åtgärds plattformsbegränsningar och förutsättningar gäller fortfarande.
Sophos Mobile Threat Defense (separat produktutgåva): Dess egna regler omfattar bland annat Android-IXM-behörigheter och upptäckt av skadlig kod och appar, iOS-webbfiltrering samt säkerhetsregler för Chromebook. För denna utgåva beskrivs Create alert som åtgärd, inte MDM-åtgärderna för e-post, container, Health eller task bundles.

I den fristående utgåvan gäller Installed apps och Mandatory apps endast Chromebooks. För Installed apps, välj först Allowed apps eller Forbidden apps och sedan appgruppen med de tillåtna respektive förbjudna apparna eller tilläggen. För Mandatory apps, välj appgruppen med de appar eller tillägg som måste vara installerade. Kopplingarna till Android, iOS och Mac samt informationen om systemappar och Android-appuppdateringar längre ned hör till den allmänna katalogen för den fullständiga utgåvan Sophos Mobile, inte till dessa två regler i den fristående Threat Defense-utgåvan.

Den separata katalogen Mobile Threat Defense compliance rules i hjälpen för Sophos Mobile beskriver en delmängd regler för Android-/iOS-enheter vars IXM-app hanteras av Sophos Mobile: till exempel root/jailbreak, OS-gränser, IXM-synkronisering och skanning av Android-appar. En hanterad app bevisar inte i sig fullständig MDM-hantering av enheten; denna delmängd är inte heller regelkatalogen för den fristående produktutgåvan Sophos Mobile Threat Defense. Regeln Intercept X for Mobile permissions can be denied anger på Android om nekade behörigheter för IXM-appen gör enheten icke-kompatibel. Den kan synliggöra ett avbrott i Web Filtering som en överträdelse om Accessibility Service nekas; Sophos rekommenderar värdet No när Web Filtering används. iOS-regeln Web Filtering turned on finns i Sophos Mobiles allmänna regelkatalog och i katalogen för den fristående Threat Defense-utgåvan, inte i den nämnda IXM-delmängden. Den kräver att Web Filtering i Intercept X for Mobile är aktiverat på iPhone- och iPad-enheter; detta är ett separat kriterium, inte Android-regeln för behörigheter. Chromebook-regler är inte automatiskt Android-/iOS-regler.

Delmängden för hanterad IXM finns dokumenterad i båda hjälpsystemen, för Sophos Mobile och Sophos Mobile Threat Defense. För enheter vars IXM-app hanteras av Sophos Mobile anges följande:

Managed required gäller Android och iOS. Regeln anger åtgärden när en enhet inte längre hanteras. Den är inte samma sak som Device administrator management allowed och bevisar inte fullständig MDM-hantering.
Minimum OS version och Maximum OS version gäller Android och iOS i denna delmängd. De anger den lägsta OS-version som krävs respektive den högsta som tillåts. Att den allmänna katalogen längre ned saknar en plattformslista ändrar inte detta.
Malware apps allowed gäller här endast Android. Regeln anger om skadliga appar som IXM upptäcker är tillåtna.
PUAs allowed gäller här endast Android. Regeln anger om potentiellt oönskade appar som IXM upptäcker är tillåtna.

De två appreglerna utvärderar compliance. De är varken skanningsinställningar eller ett godkännande att låsa upp upptäckta appar eller undanta dem från framtida skanningar. Följder av upptäckter och undantag granskas separat i anvisningen för hantering av en compliance-incident som länkas längre ned.

En regel av typen Maximum interval between … synchronizations är en konfigurerbar complianceregel för respektive synkroniseringskälla: operativsystemets inbyggda MDM-programvara, Sophos Mobile Control, IXM eller Sophos Chrome Security. I den allmänna katalogen gäller följande fördelning:

Native MDM: iPhone-/iPad-enheter utan Sophos Mobile Control eller IXM samt Mac- och Windows-datorer.
SMC (Sophos Mobile Control): Android- och iPhone-/iPad-enheter.
Intercept X for Mobile: Android- och iPhone-/iPad-enheter.
Sophos Chrome Security: Chromebooks.

Var och en av dessa regler begränsar det längsta tillåtna intervallet mellan respektive agents synkroniseringar med Sophos Fusion; blanda inte ihop agenterna eller deras tidsvärden. Maximum interval between Intercept X for Mobile scans begränsar däremot på Android intervallet mellan IXM-skanningar efter skadlig kod, inte mellan synkroniseringar. Om gränsen har överskridits kan bara bedömas utifrån den regel som faktiskt har aktiverats och överträtts samt den tillhörande synkroniserings- eller skanningstidpunkten. Separat från detta kan en fördröjd eller misslyckad synkronisering innebära att den visade compliancestatusen inte längre är aktuell; den bevisar i sig varken en regelöverträdelse eller att enheten uppfyller reglerna. En status som är okänd för EAS Proxy är ytterligare ett annat fall i ett separat konfigurerat Exchange-karantänflöde, inte automatiskt en överträdelse av regeln om maximalt synkroniseringsintervall.

Välj regler utifrån vad som ska kontrolleras

Följande grupper delar in den allmänna regelkatalogen för den fullständiga utgåvan Sophos Mobile som stöd för planeringen. De är inte en lista med rekommenderade standardvärden. Kontrollera först utgåva och hanteringsläge, välj sedan bara de kriterier som passar och granska åtgärden för varje regel separat.

Hanteringsstatus, versioner och uppdateringar

Managed required / Device administrator management allowed: Den första regeln gäller enheter som inte längre hanteras; den andra anger åtgärder för Android-enheter där Sophos Mobile självt används som Device Administrator. Detta hanteringsläge är föråldrat i Sophos Mobile och är endast tillgängligt för Android 9 eller äldre; det kan inte användas med Android 10 eller senare. Sophos rekommenderar att enheter i detta läge migreras till Android Enterprise. Det är en begränsning för det Sophos Mobile-hanteringsläge som beskrivs här, inte ett påstående om att Androids Device Administrator-API:er generellt har tagits bort, och inte heller en anvisning om att nyregistrera sådana enheter.
Minimum SMC version: Lägsta tillåtna version av Sophos Mobile Control-appen, för Android- och iPhone-/iPad-enheter. Blanda inte ihop den med IXM- eller OS-versionen.
Minimum OS version / Maximum OS version: Lägsta respektive högsta tillåtna operativsystemsversion. Katalogen anger ingen separat plattformslista för dessa två poster; kontrollera tillgängligheten på respektive plattformsflik.
Mandatory OS updates: Gäller övervakade iPhone-/iPad-enheter, inte Apple User Enrollment. Latest available update kräver den senaste tillgängliga uppdateringen; Latest critical update kräver den senaste uppdatering som Apple klassificerar som kritisk. Den senaste tillgängliga uppdateringen kan vara nyare än den senaste kritiska. Latest critical update är inte tillgänglig från iOS/iPadOS 27. För uppdateringshantering av dessa enheter anger Sophos en deklarativ policy med Software update settings eller Enforced software update; dra inte slutsatsen att det tidigare compliancevalet har oförändrad effekt. Software update settings kräver iOS/iPadOS 26 eller senare, hanteringsläget Apple Device Enrollment och en övervakad enhet. För Enforced software update anger Sophos iOS/iPadOS 26 eller senare och Apple Device Enrollment som förutsättningar, men inget ytterligare krav på övervakning. Denna minimiversion 26 ska skiljas från gränsen 27 för det tidigare valet Latest critical update.

Apples uppdateringsinformation kräver en egen nätverksväg: För information om tillgängliga uppdateringar på iPhone, iPad och Mac måste mesu.apple.com kunna nås via HTTPS 443. Om denna destination inte kan nås har Sophos Mobile ingen uppdateringsinformation; complianceregler för obligatoriska uppdateringar har då ingen effekt. Kontrollera den faktiska nätverksvägen tillsammans med nätverksadministrationen innan en sådan regelstatus bedöms som tillförlitlig. Detta utökar inte de ovan angivna begränsningarna för plattform, operativsystem eller registrering för Mandatory OS updates och innebär inte att alla installationer av Apple-uppdateringar misslyckas.

Enhetsskydd och separation av arbetsdata

Root access allowed (Android): Ange om enheter med rootbehörighet är tillåtna. Den dokumenterade tillåtelsen omfattar även Sony-enheter med Enterprise API Level 4 eller senare och Samsung-enheter med Knox Standard SDK 5.5 (API Level 17) eller äldre som operativsystemet klassificerar som osäkra. Detta är historiska förbehåll i regelhjälpen, inte en rekommendation att använda dessa enheter i dag.
Android Debug Bridge (ADB) allowed (Android): Ange om felsökningsgränssnittet ADB är tillåtet eller förbjudet.
Allow jailbreak (iPhone/iPad): Ange separat om enheter med jailbreak är tillåtna; överför inte Android-regeln för rootbehörighet till dessa enheter.
Screen lock required (Android, iPhone/iPad, Windows): Ange om ett enhetslösenord eller någon annan låsmekanism krävs. På Android räknas Pattern, PIN och Password, men inte Swipe. Vid Apple User Enrollment är regeln uppfylld om den tilldelade policyn innehåller en Password policies-konfiguration.
Encryption required (Android, Mac, Windows): Kräv kryptering; på macOS avser regeln fullständig kryptering med FileVault. Enligt regelhjälpen är iPhone- och iPad-enheter alltid krypterade och ingår inte i listan över plattformar som denna regel gäller för.
Container configured (Android): En container måste vara konfigurerad och aktiverad, till exempel en Android-arbetsprofil eller en Samsung Knox-container. Detta är ett tillståndskriterium, inte åtgärden Lock container.
Data roaming allowed: Tillåt eller förbjud dataroaming, för Android- och iPhone-/iPad-enheter utan Apple User Enrollment.

Använd inte en generell lösning för Android-kryptering: Den aktuella regelhjälpen innehåller fortfarande en hänvisning under Encryption required för Android till Require PIN to start device eller Require Password to start device när skärmlås konfigureras. Det bevisar inte att alternativen för PIN eller lösenord vid start finns på aktuella Android-versioner eller i alla Android Enterprise-lägen. Den separata KBA-000004067 beskriver ett fel med den visade standardkrypteringsnyckeln och anger start-PIN och manuell synkronisering som åtgärd, utan att ange OS-version eller registreringsläge; det är ingen universallösning för aktuella Android-versioner eller Android Enterprise-lägen. Klarlägg det faktiskt observerade felet, vilken OS-version som stöds och registreringsläget före varje ingrepp på en enhet; rekommendera inte en generell PIN-ändring eller Synchronize now.

Appar, profiler och behörigheter

Installed apps: Välj först Allowed apps eller Forbidden apps och sedan appgruppen med de tillåtna respektive förbjudna apparna. Gäller Android, iPhone-/iPad-enheter utan Apple User Enrollment, Mac-datorer och Chromebooks. Android-systemappar är alltid tillåtna; Chrome OS-appgrupper kan innehålla appar och tillägg.
Mandatory apps: Välj i listan den appgrupp vars appar måste vara installerade. Chrome OS-grupper kan även innehålla tillägg. Lägg inte in systemappar som obligatoriska appar under Mandatory apps på iOS: Sophos Mobile kan inte upptäcka att de är installerade och markerar enligt regelhjälpen alla berörda enheter som icke-kompatibla. För Android beskriver Sophos i SMCAND-3159 att parallella appuppdateringar under en synkronisering mellan Control-appen och Mobile-backend kan få statusen att tillfälligt växla till icke-kompatibel och sedan tillbaka till kompatibel, särskilt på äldre enheter. För att bedöma detta utan att göra ändringar, jämför den regel som faktiskt har överträtts, tidpunkterna för uppdateringarna och synkroniseringen samt den status som observerats därefter. Detta är inget skäl att försvaga regeln för obligatoriska appar. Dra inte slutsatsen att driften varit utan konsekvenser eller att åtkomsten till appar, e-post eller Wireless har återställts bara för att statusen senare är kompatibel; den dokumenterade automatiska återgången till compliance är varken ett resultat som observerats här eller en garanti för när det sker.
Suspicious apps allowed (Android): Ange om misstänkta appar som IXM upptäcker är tillåtna. Detta är ett separat complianceval, inte automatiskt samma sak som skanningsinställningar för appar med lågt anseende.
Third-party profiles allowed (iPhone/iPad, utan Apple User Enrollment): Ange om konfigurationsprofiler som inte hanteras av Sophos Mobile är tillåtna.
Unmanaged apps from unknown sources allowed (iPhone/iPad): Ange om egenutvecklade appar som installerats manuellt via en IPA-fil och signerats med en ad hoc-provisioneringsprofil är tillåtna. Likställ inte detta med Chromebook-regeln för appar utanför Chrome Web Store.
SMC permissions can be denied (Android): Control-appen behöver behörigheter för att fungera, och dessa måste beviljas vid installationen. Regeln anger om nekade behörigheter utlöser en complianceöverträdelse. Detta är en annan app än den som avses i Intercept X for Mobile permissions can be denied ovan.
Locate permission required (Android): Ange för funktionen Locate om Control-appens behörighet att hämta platsdata, som beviljas vid installationen, krävs för att enheten ska uppfylla reglerna.
App is able to locate (iPhone/iPad): Platstjänster måste vara aktiverade och Control-appen måste få använda dem. Denna kombination är skild från installationskriteriet för Android. Ingen av platsreglerna ger organisatoriskt eller rättsligt godkännande att samla in platsdata.

Kontrollera Chromebook, Mac och Windows specifikt

Chromebooks: Följande regler gäller Sophos Chrome Security, inte Android-Control-appen:

Tamper protection turned off: Välj åtgärder för det fall att Chrome Security policy har manipulerats.
Minimum Sophos Chrome Security version: Ange lägsta tillåtna version av Chrome Security-tillägget.
Apps from unknown sources allowed: Ange om appar och tillägg utanför Chrome Web Store är tillåtna.

Mac-datorer: Kriterierna avser att respektive skydd är aktiverat, inte ett bevis för att complianceregeln själv aktiverar det:

Firewall required: macOS-brandväggen måste vara aktiverad.
System Integrity Protection required: SIP måste vara aktiverat. Denna skyddsfunktion i macOS begränsar rootanvändarens åtgärder; den kan konfigureras vid start från macOS Recovery. Detta ger inget godkännande att ändra SIP under pågående drift.
Security updates required: Automatisk installation av macOS-säkerhetsuppdateringar måste vara aktiverad. Regelhjälpen begränsar detta till macOS 26 (Tahoe) eller äldre; denna gräns är inte iOS/iPadOS 27-gränsen för den mobila uppdateringsregeln.

Windows-datorer: Välj tre separata Defender-kriterier och härled dem inte från en enda status:

Windows Defender must be turned on: Windows Defenders realtidsskydd måste vara aktiverat. Detta avsedda kriterium gäller fortfarande. För Windows 10 beskriver Sophos dock i SMCSRV-13801 en begränsning i kontrollen: Regeln kontrollerar bara om Defender-tjänsten körs, inte om realtidsskyddet är aktiverat. En enhet kan därför visas som kompatibel trots att skyddet är avstängt. Innan du förlitar dig på skyddet, kontrollera det faktiska realtidsskyddet separat på den berörda Windows 10-enheten utan att ändra skyddsinställningar eller policyer. Att tjänsten körs och att compliancestatusen är kompatibel ersätter inte denna kontroll på enheten.
Clean status from Windows Defender required: Enheten är icke-kompatibel om Windows Defender visar varningar.
Up-to-date Windows Defender definitions required: Windows Defender måste använda de senaste definitionerna för spionprogram.

Blanda inte ihop åtgärd och regel

Create alert skapar i den fullständiga utgåvan en händelse som visas på enhetens detaljsida och ett larm; Threat Defense beskriver larm i Sophos Fusion. Ett larm är inte en konfigurerad blockering av e-post eller container. Att endast välja Create alert garanterar dock varken oförändrad enhets-Health eller oförändrad trådlös åtkomst; även andra följder av bristande compliance är möjliga.
Deny email är en konfigurerad åtgärd vid överträdelse av en policyregel i den fullständiga utgåvan; den kräver en konfigurerad anslutning till Sophos Mobile EAS Proxy och är avsedd för Android, iPhone/iPad och Windows. Att en EAS Proxy finns bevisar varken hur den aktuella e-posttjänsten autentiseras eller att leveransen faktiskt har stoppats eller återställts. Separat från detta beskriver Sophos Exchange-karantän för oregistrerade enheter endast när EAS Proxy körs i PowerShell-läge och Exchanges standardregel för åtkomst är konfigurerad därefter. Även registrerade enheter kan då hamna i karantän om deras compliancestatus är okänd för proxyn efter alltför lång tid utan synkronisering eller på grund av utebliven anslutning till Sophos Mobile. Det registreringsmeddelande som Exchange skickar i karantänflödet är varken Create alert eller ett bevis för att Deny email har utlösts. Dra inga slutsatser om generell karantän eller automatisk återställning av e-post utifrån en regelöverträdelse eller ett larm; utredningen hör till incidenthantering, inte till denna policyplanering.
Lock container är i den aktuella fullständiga utgåvan avsedd för Android Enterprise, inte en belagd containerlåsning på iOS. Den allmänna tabellen över complianceåtgärder i den fullständiga utgåvan beskriver denna konfigurerade åtgärd som låsning av alla appar utom Sophos Mobile Control, Sophos Intercept X for Mobile, Google Play Store, Contacts, Messages och Phone. Den allmänna beskrivningen klargör inte effekten på appar i BYOD-enhetens privata profil; varken de sex undantagen eller exemplet med arbetsprofilen nedan bevisar att privata appar förblir tillgängliga. För en Android-arbetsprofil som stöds dokumenterar Sophos i den separata åtkomststyrningen Auto (standard utan manuell åtkomsttillåtelse: arbetsprofilen låses om en överträdd complianceregel innehåller Lock container), Deny (arbetsprofilen låses) och Allow (arbetsprofilen låses upp). När den är låst går det inte att komma åt arbetsprofilens appar och data; inställningen tillämpas först efter synkronisering av enheten. Denna åtkomststyrning för arbetsprofilen är skild från kommandot för att låsa hela enheten; den bevisar varken effekten av den konfigurerade complianceåtgärden på privata appar, dess tillgänglighet i varje BYOD-/registreringsscenario eller att återställning har testats. Kontrollera målgrupp och effekt på en auktoriserad enhet före godkännande.
Skilj Set health från beräknad Health: Set health är i den fullständiga utgåvan en uttryckligen vald åtgärd per regel: Om regeln överträds tilldelas det valda värdet rött/gult/grönt; vid flera överträdda regler gäller det sämsta tilldelade Health-värdet. Åtgärden kräver att Synchronized Security är aktiverat för Android, iPhone och iPad; för en avsedd effekt på trådlös åtkomst måste dessutom policyns Health-värde för bristande compliance och de trådlösa reglerna vara konfigurerade. Därutöver visar Fusion en enhets-Health som baseras på överträdelser av complianceregler; när Synchronized Security är aktiverat kan den åsidosättas manuellt, medan Auto återgår till beräkning utifrån compliancestatus. Det är inte klarlagt vilket värde som uppstår utan Set health-åtgärd i varje utgåva och läge eller hur en manuell åsidosättning och en samtidig regelåtgärd prioriteras; härled varken en automatisk röd/gul tilldelning eller oförändrad Health från Create alert. Kontrollera separat överträdd regel/bristande compliance, sparad Set health-åtgärd, visad Health inklusive manuellt/Auto-läge, det värde som rapporteras till Wireless och faktisk åtkomst. Sophos Wireless kan beroende på konfiguration begränsa nätverksåtkomst; en konsolvisning bevisar inte någon viss effekt på trådlös åtkomst.
Transfer task bundle kan felkonfigurera eller till och med radera enheter. Lägg inte in wipe-/reset-uppgifter eller automatiska task bundles som standardåtgärd; None betyder här bara att inget task bundle överförs, inte att bristande compliance saknar konsekvenser.

Specialfall: På en icke-kompatibel Android Enterprise fully managed-enhet inaktiveras i den fullständiga utgåvan alla appar automatiskt, oavsett vilken åtgärd som valts per regel. Det är inte samma sak som den konfigurerbara åtgärden Lock container och är inte heller en belagd effekt för Android-BYOD-/arbetsprofilenheter, enheter med enbart MTD eller andra Android-lägen. För Android BYOD beror effekten av Lock container på vilket hanteringsläge som faktiskt stöds och på konfigurationen; dra inte slutsatsen att hela enheten låses utifrån en möjlig låsning av arbetsprofilen. Kontrollera åtkomst till telefonen, arbetsprofilen, återställningsfunktioner och kritiska appar på en auktoriserad testenhet före varje godkännande.

Synchronized Security är inte tillgängligt för alla enheter: Sophos utesluter Chromebooks, Apple User Enrollment och enheter med nätverksspecifik/privat eller randomiserad MAC-adress, eftersom de inte rapporterar sin MAC-adress till Sophos Mobile. Den separata möjligheten att överföra MAC-adressen via IXM-appkonfiguration hos en tredjeparts-EMM bevisar inte något undantag för privata/randomiserade MAC-adresser. Planera en pilot för trådlös åtkomst endast med ett enhets- och registreringsläge som faktiskt stöds och där MAC- och Synchronized Security-konfigurationen har kontrollerats; en Health-indikering ersätter inte ett åtkomsttest.

Tilldela stegvis i stället för att testa globalt

Inventera enheter och förutsättningar: Dokumentera miljö, licens/utgåva, hanteringsläge, plattform/OS, ägarskap, IXM-hanteringsstatus, senaste synkronisering, befintliga regler och aktiva beroenden till EAS Proxy och Sophos Wireless. Dokumentera stöd för Synchronized Security och MAC-begränsningar, visad enhets-Health inklusive manuellt/Auto-läge, befintliga trådlösa regler samt policyer och tilldelningar.
Bedöm regel och åtgärd var för sig: Öppna den aktuella regelkatalogen för rätt produktutgåva; inventera för varje aktiverad plattform varje regel som följde med mallen eller ställdes in manuellt, inklusive åtgärd. Kontrollera signal, läge och åtgärdens förutsättningar före Save och före tilldelning; utgå inte från att PCI/HIPAA är passiva. Planera för en godkänd pilot en ny, isolerad policy utan blockerande eller destruktiva åtgärder och kontrollera de åtgärder som faktiskt sparats på nytt. Att Set health saknas bevisar varken att beräknad/manuell Health förblir oförändrad eller att den trådlösa åtkomsten förblir oförändrad. Viktigt: Inte heller enbart Create alert eller None för ett task bundle förhindrar den dokumenterade automatiska appinaktiveringen på en icke-kompatibel Android Enterprise fully managed-enhet. Uteslut sådana enheter ur piloten tills ett enhetsspecifikt test av appåtkomst och återställning för den faktiska versionen och det faktiska läget är godkänt och förberett.
Välj en begränsad pilotgrupp: Behandla de planerade företagsägda och privata enheterna separat. Om en ny grupp behövs för den godkända piloten ska du först förbereda enhetsgruppen och stämma av omfattningen. Om båda ägartyperna hanteras rekommenderar Sophos separata compliancepolicyer för företagsägda och privata enheter; två separata tilldelningsfält betyder inte i sig att olika policyer används. Under Device groups > [gruppnamn] > Compliance policies tilldelas corporate och personal var för sig. Kontrollera före Save för varje målenhet dess enda aktuella enhetsgrupp (även den befintliga Default-gruppen om den är tilldelad), ägartyp (corporate/personal) och gruppens policystilldelning så att inga oavsiktliga enheter omfattas. När du har valt policyer för corporate och personal och kontrollerat omfattningen, klicka på Save för att spara grupptilldelningen. Jämför sedan båda kolumnerna Compliance policy (corporate) och Compliance policy (personal) för den valda gruppen på sidan Device groups med den planerade tilldelningen. Kontrollera alla grupper som har tilldelats policyn innan du ändrar en befintlig, delad policy; ändringen kan påverka ytterligare grupper, inte för att en enhet tillhör flera grupper. En ny isolerad pilot får inte ändra en gemensamt använd policy i det tysta.
Kontrollera effekten i en auktoriserad pilot: Säkerställ på nytt före en avsiktligt framkallad överträdelse att ingen Android Enterprise fully managed-enhet ingår i en pilot med enbart larm eller utan åtgärder; Create alert eller None skyddar inte dess appar. Jämför först grupptilldelningen och den konkreta enheten samt nytt compliancevärde, överträdd regel, synkroniseringstidpunkt och i förekommande fall larm/händelse. Observera separat på en testenhet som stöds, före och efter överträdelsen, den faktiskt sparade Set health-åtgärden, visad Health och manuellt/Auto-läge samt, när Synchronized Security är aktiverat, rapporterad Health, trådlös regel och faktisk trådlös åtkomst; kontrollera även e-postflöde och appåtkomst om konfigurationen gör dem relevanta. Förutsätt inte att nätverksåtkomsten är oförändrad ens utan Set health-åtgärd; tolka inte en fördröjd eller utebliven synkronisering som att enheten uppfyller reglerna. Testa en avsiktligt framkallad överträdelse endast när vägen tillbaka är bekräftad och produktionsdata inte riskeras. Innan piloten utvidgas till fullständigt hanterade Android Enterprise-enheter måste det först på en auktoriserad enhet kontrolleras om den dokumenterade automatiska följden inträffar för den faktiska versionen och det faktiska läget och om återställningen fungerar.
Utöka först efter godkännande: Jämför berörda enheter och oväntade överträdelser med utgångsläget. Stoppa utökningen vid avvikelser, återställ efter godkännande den dokumenterade tidigare grupptilldelningen och regel-/åtgärdskonfigurationen och kontrollera återställningen på nytt på enheten och i externa tjänster. Att ta bort en regel återställer inte automatiskt redan utförda task bundles, raderingar eller externa åtkomstblockeringar.

Använd inte som test: Compliance policies > Check now påverkar alla registrerade enheter och utför de åtgärder som har konfigurerats där – även om avsikten bara var att testa en liten grupp. Före en planerad total kontroll måste alla grupper och åtgärder granskas och ändringen godkännas; denna artikel ger inget klartecken att trycka på knappen i produktionsmiljön.

Endast ett planeringsexempel, inte testat: En särskilt godkänd grupp med en företagsägd iPhone (varken Apple User Enrollment eller Android Enterprise fully managed), en icke-destruktiv regel som i förväg kontrollerats vara tillämplig och Create alert skulle kunna användas som begränsad pilot. Inventera före tilldelningen alla regel-/åtgärdspar, gruppmedlemskap och, om trådlös åtkomst ingår i testet, stöd för Synchronized Security samt MAC- och Wireless-konfiguration. Vid en auktoriserad, reversibel testöverträdelse kontrolleras i den fullständiga utgåvan överträdelsen/bristande compliance och händelsen på enhetens detaljsida i konsolen samt larmet i konsolen; i den fristående utgåvan Sophos Mobile Threat Defense kontrolleras larmet på sidan Alerts i Sophos Fusion. Förvänta dig inte ett larm på den fysiska målenheten. Kontrollera separat visad Health (manuellt/Auto-läge) samt e-postflöde, appåtkomst och faktisk trådlös åtkomst på målenheten före och efter synkroniseringen. Utgå inte från oförändrad Health eller oförändrat nätverk enbart på grund av Create alert. Stoppa om fler enheter påverkas, synkroniseringen uteblir eller Health/åtkomst avviker oväntat; utöka inte, återställ den tidigare tilldelningen efter godkännande och kontrollera effekten på nytt. Detta är en testplan, inte ett observerat testresultat.

Avgränsning och förutsättningar för användning

Utredning av en enhet som redan avviker eller är blockerad, larmtriage, hantering av falsklarm och återställning av e-post eller trådlös åtkomst ingår inte i denna vägledning för policyplanering. Den ersätter inte anvisningar för incidenter eller återställning. En åtgärd med Android-start-PIN eller manuell synkronisering enligt KBA-000004067 är ingen generell lösning utan kontroll av det konkreta felet och vilken enhets- och registreringskombination som stöds. För inledande triage utan ändringar och kontroll av wifiåtkomst finns vägledningen om hantering av en compliance-incident; inte heller den ger godkännande att utföra åtgärder.

De beskrivna förfarandena har inte validerats på enheter eller i en tenant. Den här artikeln ger inget godkännande att utföra åtgärder. Förhållandet mellan vald Set health-åtgärd, automatiskt beräknad/manuellt åsidosatt Health och effekten på trådlös åtkomst är här inte klarlagt för alla lägen. Kombinationer av regler och åtgärder per produktutgåva, OS och läge samt återställningsvägar för EAS/Wireless och Android-appåtkomst måste godkännas och kontrolleras på den aktuella enheten innan de används operativt.