Apple-wifi, certificaten, VPN en proxy plannen met Sophos Mobile

Reikwijdte: Sophos Mobile in Sophos Fusion (voorheen Sophos Central), iPhone en iPad met iOS/iPadOS. Deze oriëntatie maakt onderscheid tussen iOS-apparaatbeleid (Device Policy) en iOS-gebruikersbeleid (User Policy). Het is geen geteste stapsgewijze configuratie voor een specifieke tenant, geen macOS-handleiding en geen toestemming voor grootschalige productie-uitrol. Controleer eerst op het doelapparaat de versie van het besturingssysteem, de inschrijvingsmodus, het toezicht (Supervision), het beleidstype en de functies die in de eigen tenant beschikbaar zijn.

⚠️ Verbreek de verbinding niet: Een verkeerd wifi-/EAP-certificaat, een onbereikbare SCEP-CA, een foutief PAC/WPAD of een VPN-tunnel kan ook het retourkanaal voor MDM-taken onderbreken. Toon vóór wijzigingen een verbinding aan die onafhankelijk is van het gewijzigde profiel, plus een lokale route voor probleemherstel. Een in de console opgeslagen rollback bereikt een offline buitengesloten apparaat niet automatisch.

Maak eerst onderscheid tussen de beheermodi

Device Enrollment betekent niet automatisch Supervision (toezicht): Automated Device Enrollment plaatst het apparaat onder toezicht, andere methoden niet noodzakelijk. Apple User Enrollment plaatst het apparaat nooit onder toezicht en heeft betrekking op beheerde gegevens, niet op het volledige privéapparaat. Bij BYOD horen een Managed Apple Account en toestemming bij de voorbereiding. Daar zijn geen globale HTTP-proxy, geen gewoon apparaatbreed VPN en geen proxy-instellingen in de beheerde wifi-configuratie beschikbaar; Sophos kan MAC/UDID/IMEI niet opvragen voor NAC-identificatie.

Sophos beperkt profielgebaseerde User Enrollment tot iOS/iPadOS 17 of ouder; dat betekent niet dat account-driven User Enrollment in het algemeen is afgeschaft. Bij uitschrijving worden het beheerde APFS-volume en de beheerde Apple Account op het apparaat verwijderd; dit is geen algemene rollback van wifi of VPN. Apple beschrijft per-app-VPN als mogelijke functie bij User Enrollment, niet als bewijs dat de toewijzing van Sophos-apps daadwerkelijk werkt.

Plan wifi en de certificaatketen samen

Isoleer de BYOD-pilot vóór elke wijziging: Voor iOS-/iPadOS-gebruikersbeleid synchroniseert Sophos wijzigingen automatisch zodra het apparaat opnieuw verbinding maakt met Sophos Mobile; handmatig Update devices uitvoeren is daarvoor niet nodig. Gebruik daarom een afzonderlijk gebruikersbeleid dat alleen aan het goedgekeurde BYOD-testapparaat is toegewezen en controleer de huidige toewijzingen en het aantal doelapparaten vóór het bewerken en vóór Save. Wijzig tijdens de pilot geen beleid dat al samen met BYOD-apparaten in productie is toegewezen. Een latere toewijzing aan geselecteerde testapparaten beperkt de synchronisatie van de wijziging niet op andere apparaten waaraan hetzelfde beleid al is toegewezen. Deze afbakening geldt ook voor certificaatwijzigingen en correcties bij het terugdraaien; synchronisatie alleen bevestigt noch de netwerkfunctie, noch de MDM-herstelroute.

Wie controleert wie? Bij zakelijke wifi met EAP (authenticatie tussen apparaat en netwerk) controleert het apparaat de naam en certificaatketen van de RADIUS-server. Bij certificaatgebaseerde aanmelding controleert RADIUS omgekeerd de uitgegeven clientidentiteit. De server-CA en clientidentiteit vervullen dus verschillende rollen. Het in de wifi-configuratie selecteerbare Identity certificate vereist een Client certificate-configuratie in hetzelfde beleid; het servercertificaat onder Trusted certificates vereist daar een Root certificate-configuratie.

Uitsluitend fictieve placeholders, niet overnemen: radius.test.invalid als servernaam, Test-CA als vertrouwde server-CA en CN=Testperson,OU=Pilot,O=Beispiel als X.500-subject (velden voor de clientidentiteit). Vervang alle waarden door de namen, CA en identiteitsvelden die door het eigen PKI-/RADIUS-team zijn bevestigd. Controleer op het testapparaat of de ingestelde serveridentiteit overeenkomt met de werkelijke keten en of RADIUS het uitgegeven clientcertificaat accepteert. Het rootcertificaat is een X.509-certificaat in PEM/DER; een geïmporteerd clientcertificaat is PKCS#12 (.pfx). Een geüpload .pfx-bestand is niet automatisch herbruikbaar in meerdere beleidsregels: als je het clientcertificaat in een ander beleid nodig hebt, moet je het daar opnieuw uploaden. Controleer de herkomst van de CA, het eigendom van de sleutel, de geldigheid en het beoogde gebruik. Het uploaden van een root-CA bewijst niet dat alle apps die CA vertrouwen.

Open voor Root certificate in een iOS-apparaatbeleid op Edit policy de configuratie via Add configuration > Root certificate. Selecteer met Upload a file het X.509-bestand in PEM/DER en open het met Open. Na het uploaden toont Certificate name de Distinguished Name (DN) van de uitgever, niet de clientidentiteit. Sla met Apply de configuratie op en sla daarna op Edit policy met Save het beleid op. Volgens Sophos installeert de toewijzing van het beleid het geüploade rootcertificaat op het apparaat. De weergave en het opslaan alleen bewijzen niet dat het certificaat vertrouwd of geldig is of dat de installatie is geslaagd. Voor elk extra rootcertificaat is een afzonderlijke Root certificate-configuratie in hetzelfde beleid nodig.

Voor Root certificate in een iOS-gebruikersbeleid beschrijft Sophos de import op Edit policy via Add configuration > Root certificate. Selecteer met Upload a file het X.509-bestand in PEM/DER en open het met Open. Na het uploaden toont Certificate name de Distinguished Name van de uitgever. Sla met Apply de configuratie op en sla daarna op Edit policy met Save het beleid op. Voeg voor elk extra rootcertificaat een afzonderlijke Root certificate-configuratie toe. Volgens Sophos installeert de toewijzing van het gebruikersbeleid het certificaat op het apparaat; binnen hetzelfde beleid kan het bijvoorbeeld als EAP-servercertificaat voor wifi worden gebruikt. De uploadweergave en het opgeslagen beleid bewijzen niet dat de installatie is geslaagd, dat het certificaat wordt vertrouwd of dat wifi-aanmelding werkt.

In de Client certificate-configuratie van het iOS-apparaatbeleid kies je onder File eerst Upload a file en daarna het PKCS#12-certificaatbestand (.pfx). Onder Certificate name toont Sophos Mobile de naam die uit het certificaatbestand is gelezen. Die naam alleen bewijst niet dat het certificaat vertrouwd of geldig is of dat de installatie is geslaagd.

Vóór de SCEP-configuratie: Als je de in Sophos setup ingestelde SCEP-koppeling met de hieronder genoemde variabelen gebruikt, controleer dan eerst de SCEP-vereisten en certificaatprocedure: bereikbaarheid van de CA vanuit Sophos Fusion, regionaal afgebakende firewalltoegang en, voor deze gedocumenteerde Windows-CA-route, een account met rechten om challenges te maken en certificaten aan te vragen. Stel vóór SCEP het CA-certificaat van de SCEP-server beschikbaar als Root certificate in hetzelfde beleid. Dit serververtrouwen staat los van het vertrouwen in de RADIUS-server en de uitgegeven clientidentiteit; hiermee wordt Windows niet als vereiste voor elke directe SCEP-implementatie voorgesteld.

Met SCEP (Simple Certificate Enrollment Protocol) kan een apparaat een certificaat aanvragen bij de CA. Daarvoor is een bereikbare CA-URL of de correct geconfigureerde Sophos-SCEP-proxyvariabele nodig. Laat het PKI-team de X.500-subjectvelden en SAN/UPN (aanvullende identiteitsnamen), de challenge, de herhalingsparameters voor openstaande aanvragen, de sleutellengte en de gebruiksbits afstemmen op de eigen CA. Voor de SCEP-configuratie van een iOS-apparaatbeleid zijn de volgende keuzes belangrijk:

• CA-eindpunt en naam: URL is het webadres van de CA-server. %_SCEPPROXYURL_% verwijst naar de server-URL op het tabblad SCEP van de pagina Sophos setup. CA name is een naam die de CA begrijpt; deze kan bijvoorbeeld dienen om CA-instanties te onderscheiden. Bevestig met het PKI-team welke naam de eigen CA verwacht. Dit veld is niet de weergave Certificate name van een geïmporteerd certificaat en ook niet de voorbeeldnaam van de vertrouwde RADIUS-server-CA.
• Gebruikers- of apparaatidentiteit: Subject mag placeholders voor gebruikersgegevens of apparaateigenschappen bevatten. Sophos noemt CN=%_USERNAME_% voor een gebruiker en CN=%_DEVPROP(SerialNumber)_% voor een iPhone of iPad. Dit zijn gedocumenteerde syntaxisvoorbeelden, geen waarden die voor je tenant zijn getest. Laat het PKI-team de gewenste identiteit goedkeuren en controleer of de gegevens beschikbaar zijn en het subject na vervanging een geldige X.500-naam is. BYOD: Een gedocumenteerde placeholder voor het serienummer bewijst niet dat een op het serienummer gebaseerde identiteit bij User Enrollment kan worden bepaald; Sophos kan daar geen apparaat-ID’s opvragen. Controleer subject en uitgifte met een testgebruiker.
• SAN-type en waarde: Kies onder Type of Subject Alternative Name het door het PKI-team goedgekeurde type en voer de bijbehorende waarde in onder Value of Subject Alternative Name. RFC 822 name staat voor een geldig e-mailadres. Voor deze iOS-SCEP-configuratie beschrijft Sophos DNS name als de DNS-naam van de CA-server en Uniform resource identifier als de volledig gekwalificeerde URL daarvan, niet als de RADIUS-servernaam of het challenge-adres. AD user logon name staat hiervan los en is de UPN die in Active Directory is ingesteld. Challenge is het webadres waar het apparaat een challenge-wachtwoord van de SCEP-server ophaalt. %_CACHALLENGE_% verwijst naar de challenge-URL die op het tabblad SCEP van de pagina Sophos setup is ingesteld, niet naar het wachtwoord zelf. Neem geen echte geheimen op in openbare voorbeelden of tickets.
• Openstaande aanvragen: Retries bepaalt het aantal nieuwe pogingen wanneer de server met pending antwoordt; het is geen algemene teller voor herhalingen bij alle netwerkfouten. Retry delay is de tijd tussen deze pogingen in seconden. Stem aantal en tijdsduur af met het PKI-team en verwar ze niet met certificaatvernieuwing.
• Sleutels en gebruiksdoel: Key size is de grootte van de publieke sleutel in het uitgegeven certificaat en moet overeenkomen met de grootte die op de SCEP-server is ingesteld. Certificate usage bepaalt het toegestane gebruiksdoel: Use as digital signature voor digitale handtekeningen en Use for encryption voor gegevensversleuteling. De keuze moet passen bij de PKI-vereisten en de doeldienst; ze bewijst niet dat wifi-/VPN-aanmelding slaagt of dat al het apparaatverkeer wordt versleuteld.

Bij het maken van het beleid bestaat het veld SCEP renewal interval. Controleer het interval, de vervaldatum, de intrekking en de vervanging met het PKI-team; een ingesteld interval garandeert noch een geslaagde vernieuwing, noch herstel van een apparaat dat offline is gebleven.

Identiteitsvervanging in apparaat- en gebruikersbeleid: In het bovenstaande voorbeeld CN=%_USERNAME_% wordt %_USERNAME_% vervangen door Exchange Login van de gebruiker die aan het apparaat is toegewezen, niet noodzakelijk door diens weergavenaam en niet automatisch door de AD-UPN. Controleer vóór toewijzing de juiste gebruikerskoppeling en deze eigenschapswaarde; het ingevulde subject moet nog steeds een geldige, door het PKI-team goedgekeurde X.500-naam zijn. AD user logon name blijft het afzonderlijke UPN-veld.

Leg voor SCEP in een iOS-gebruikersbeleid de eindpunten afzonderlijk vast. URL is het webadres van de CA-server. De variabele %_SCEPPROXYURL_% verwijst naar de server-URL op het tabblad SCEP van de pagina Sophos setup. Challenge is de URL om een challenge-wachtwoord van de SCEP-server op te halen, niet het wachtwoord zelf. %_CACHALLENGE_% verwijst naar de challenge-URL die daar op het tabblad SCEP is ingesteld. Net als bij de hierboven beschreven aanvraagparameters telt Retries alleen herhalingen na een pending-antwoord; Retry delay geeft de tijd daartussen in seconden aan. Key size moet overeenkomen met de grootte van de publieke sleutel die op de SCEP-server is ingesteld. Bevestig deze parameters met het PKI-team; het zijn geen vernieuwingsintervallen en ze bewijzen niet dat de uitgifte is geslaagd.

Zakelijke wifi en het privé-wifi-adres

Voor een geïsoleerde wifi-pilot met apparaatbeleid koppelt de volgende procedure de netwerkgegevens aan de beleidstoewijzing. Zorg vooraf voor de onafhankelijke netwerk- en herstelroute uit de pilotsectie; bewerk geen beleid dat in productie is toegewezen.

1. Open onder Policies het Apple-platform dat bij het doelapparaat past, maak met Create een apparaatbeleid en voer de naam, beschrijving en organisatienaam in. Voeg op Edit policy met Add configuration de Wi-Fi-configuratie toe en open de naam ervan om deze te bewerken. Stel voor zakelijke wifi eerst de benodigde client- en rootcertificaten in hetzelfde beleid beschikbaar, zoals hierboven beschreven; Apply bij de rootcertificaatconfiguraties vervangt Save voor het volledige beleid niet.
2. Voer onder SSID de door het netwerkteam bevestigde wifi-naam in en stem Security type af op de daadwerkelijke methode, inclusief de Personal-/Enterprise-variant. Personal vereist het wifi-wachtwoord; gebruik voor Enterprise de hieronder beschreven EAP-, aanmeldings- en vertrouwensinstellingen. Connect automatically maakt automatisch verbinding wanneer het netwerk beschikbaar is; Hidden network duidt een netwerk aan dat de SSID niet uitzendt. Kies beide opties alleen passend bij het beoogde netwerk, niet als bewijs van beveiliging.
3. Controleer alle configuraties en sla op Edit policy met Save het beleid op. Gebruik voor de daaropvolgende toewijzing de procedure ‘Beleid maken en toewijzen’: kies het opgeslagen pilotbeleid, selecteer alleen de afzonderlijke goedgekeurde testapparaten en controleer vóór Finish de lijst en het aantal. Houd rekening met de daar genoemde voorbehouden voor planning en iPadOS. Observeer daarna de taak-/toewijzingsstatus, de daadwerkelijke wifi-aanmelding en de MDM-check-in afzonderlijk volgens de hieronder genoemde testcriteria; opslaan en toewijzen zijn geen bevestigde verbindingsresultaten.

Kies voor de Wi-Fi-configuratie van een iOS-apparaatbeleid eerst een Security type dat bij het netwerk past. Bij een Personal-variant is het wifi-wachtwoord beschikbaar. Alleen een Enterprise-variant biedt Protocols, Authentication en Trusted certificates. Stem onder Accepted EAP types de door het apparaat geaccepteerde methoden met het RADIUS-team af op de netwerkaanmelding. De hierboven beschreven client- en rootcertificaten blijven aan hetzelfde beleid gebonden.

Onder Authentication van het iOS-apparaatbeleid is User de wifi-gebruikersnaam en Password het wifi-wachtwoord voor aanmelding met inloggegevens. Require password on each connect verstuurt volgens Sophos het wachtwoord bij elke authenticatie; de optie belooft geen interactieve wachtwoordvraag. Stem de aanmeldroute met inloggegevens en deze keuze af met het RADIUS-team. Kies voor certificaatgebaseerde aanmelding in plaats daarvan het passende Identity certificate uit een Client certificate-configuratie in hetzelfde apparaatbeleid. Controleer op het testapparaat, afhankelijk van de gekozen route, of RADIUS de inloggegevens of het clientcertificaat accepteert; de serveridentiteit en vertrouwensketen moeten in beide gevallen afzonderlijk worden gecontroleerd.

Bij TTLS is Internal identity het protocol voor gebruikersaanmelding binnen de tunnel. Dit is niet de buitenste identiteit. Voor EAP-FAST kan een Protected Access Credential (PAC) worden geconfigureerd; dit PAC is geen script voor automatische proxyconfiguratie. Stem het TTLS-protocol en zo nodig de EAP-FAST-credential af met het RADIUS-team en controleer de aanmelding op het doelapparaat. Laat zonder die afstemming de betreffende EAP-variant buiten de pilot.

Stel bij EAP beide TLS-grenzen in of laat beide open. Sophos beschrijft Outer identity voor TTLS, PEAP en EAP-FAST en vereist een buitenste identiteit voor TLS 1.3. Gebruik daarvoor geen gebruikersnamen of geheimen, omdat de buitenste identiteit in platte tekst wordt verzonden. Laat het PKI-/RADIUS-team zo nodig een anonieme buitenste identiteit met passende realm voor de routering controleren. Observeer op het testapparaat de onderhandelde aanmelding en TLS-versie; de selectie alleen bewijst niet dat de verbinding werkt.

Met Turn off private address gebruikt het apparaat voor dit wifi-netwerk zijn hardware-MAC-adres in plaats van een door iOS aangemaakt netwerkspecifiek adres. Dit vermindert de privacy. Gebruik de optie alleen als het apparaat zich in de eigen netwerken noodzakelijkerwijs met hetzelfde MAC-adres moet identificeren. Volgens Sophos werkt Synchronized Security niet met privé-MAC-adressen: Sophos Fusion Wireless kent alleen het privéadres, Sophos Mobile alleen het hardwareadres. Uitschakelen alleen garandeert echter niet dat Synchronized Security werkt; controleer de koppeling en het gewenste gedrag in het beoogde netwerk. Behandel dit niet als BYOD-omweg voor NAC. Bij User Enrollment kan Sophos het MAC-adres niet opvragen voor NAC.

Ook voor Wi-Fi in een iOS-gebruikersbeleid maakt Sophos onder Security type onderscheid tussen Personal en Enterprise. Personal gebruikt het wifi-wachtwoord. Protocols, Authentication en Trusted certificates zijn alleen beschikbaar bij Enterprise. Voor aanmelding met inloggegevens is User de wifi-gebruikersnaam en Password het wifi-wachtwoord. Require password on each connect verstuurt volgens Sophos het wachtwoord bij elke authenticatie. Stem deze keuze af met het RADIUS-team en vat dit niet op als een toezegging dat om het wachtwoord wordt gevraagd. Kies bij certificaatgebaseerde aanmelding in plaats daarvan het passende Identity certificate uit een Client certificate-configuratie in hetzelfde gebruikersbeleid. Ook het servercertificaat onder Trusted certificates vereist een Root certificate-configuratie in dit beleid. Gebruik het clientcertificaat en de acceptatie ervan door RADIUS alleen voor de certificaatgebaseerde aanmeldroute als testcriterium.

De hierboven beschreven EAP-keuzes gelden volgens de Wi-Fi-beschrijving ook voor dit gebruikersbeleid. Stem Accepted EAP types af op de netwerkaanmelding, bepaal bij TTLS het protocol onder Internal identity en bespreek bij EAP-FAST zo nodig het Protected Access Credential (PAC). Deze credential is geen proxy-PAC-script. Stel beide TLS-grenzen in of laat beide open. Outer identity is beschreven voor TTLS, PEAP en EAP-FAST en is vereist voor TLS 1.3. Neem de bovenstaande opmerkingen over platte tekst en realms in acht. Leid hieruit niet af dat alle opties in de eigen tenant beschikbaar zijn of dat de aanmelding slaagt; de uitsluiting van een beheerde wifi-proxy en het voorbehoud voor MAC/NAC bij User Enrollment blijven gelden.

Proxy en VPN zijn verschillende ingrepen

• Wifi-proxy: In iOS-apparaatbeleid handmatig of via PAC (bestand met proxyregels) te configureren. Bij Apple User Enrollment ondersteunt de wifi-configuratie geen proxy. Sophos noemt daar WPAD (automatisch een proxy vinden) op het access point en de mogelijkheid dat de gebruiker de HTTP-proxy in de wifi-instellingen zelf op automatisch instelt als mogelijke uitwijkroute, niet als op afstand beheerde BYOD-proxypayload. Test PAC/WPAD, DNS en bereikbaarheid afzonderlijk.
• Globale HTTP-proxy: Sophos staat deze iOS-apparaatconfiguratie alleen toe voor apparaten onder toezicht; handmatig met server/poort/eventuele inloggegevens of automatisch via een PAC-URL. In de handmatige modus is Server de naam of het IP-adres van de HTTP-proxy en Port het poortnummer ervan. Authentication is de gebruikersnaam voor de verbinding met de proxyserver en Password het bijbehorende wachtwoord. Dit biedt noch een BYOD-oplossing, noch een garantie bij uitval.
• Apparaatbreed VPN: iOS-apparaatbeleid bevat verbindingstype, server en authenticatie; bij Custom SSL/TLS moet de app van de aanbieder geïnstalleerd zijn. Pas deze configuratie niet toe op Apple User Enrollment: Apple staat daar geen gewoon apparaatbreed VPN toe.
• Per-app-VPN: Afzonderlijke configuratie voor geselecteerde apps, niet hetzelfde als een apparaat-VPN. Controleer de aanbieder-app bij Custom SSL/TLS, server, authenticatie, optionele certificaten/proxy, On-Demand en domeinregels voor Safari/andere browsers, agenda, contacten en e-mail apart. Controleer ook Send all traffic through VPN op het werkelijke bereik; leid uit de naam geen universele app-isolatie of apparaatbrede werking af. De Sophos-documentatie is hier niet eenduidig: De beschrijving van User Policy bevat per-app-VPN, maar voor app-toewijzing worden alleen Device Policies als voorwaarde en keuzemogelijkheid genoemd. Beweer daarom niet dat er een werkend klikpad voor BYOD-toewijzing is: toon dit eerst aan in de huidige tenant met een test-app en testapparaat.

Apparaat-VPN: aanbieder, aanmelding en verkeersroute

De volgende gegevens horen bij de VPN-configuratie van een iOS-apparaatbeleid, niet bij de per-app-VPN-configuratie of Apple User Enrollment. Controleer de beschikbaarheid en ondersteuning door de aanbieder in de eigen tenant. Connection name is de naam van de verbinding die op het apparaat wordt weergegeven. Voer onder Server de hostnaam of het IP-adres van de VPN-server in; bevestig het passende eindpunt met de VPN-verantwoordelijke.

• Kies bij Connection type de passende aanbieder of het passende verbindingstype. Voor een VPN-aanbieder-app uit de App Store beschrijft Sophos Custom SSL/TLS. De app moet geïnstalleerd zijn; voer onder Identifier (reverse DNS format) de identificatie ervan in reverse-DNS-formaat in. Als de aanbieder eigen verbindingsparameters voorschrijft, leg dan de bevestigde sleutels en waarden onder Third-party settings vast als verbindingseigenschappen. Neem geen sleutels of waarden over uit configuraties van andere aanbieders.
• User authentication betreft de gebruikersaanmelding. Account is het gebruikersaccount voor de VPN-verbinding; Group kan een daarvoor vereiste authenticatiegroep aangeven. Geef bij Password het VPN-wachtwoord op en bij Certificate het VPN-authenticatiecertificaat. Stem met de VPN-verantwoordelijke af of een groep nodig is en welke identiteit wordt gebruikt. Deze inloggegevens zijn geen proxy-inloggegevens.
• Device authentication staat hiervan los. Geef bij Keys (Shared Secret)/Group name de vereiste groep op onder Group name en de gedeelde sleutel onder Keys (Shared Secret). Sophos noemt hierbij Use hybrid authentication en Request password, maar beschrijft op deze pagina alleen een keuze naar behoefte. De werking en noodzakelijke keuze zijn hier niet vastgesteld; neem deze twee opties pas na bevestiging door de aanbieder op in de pilot. Selecteer bij Certificate het vereiste certificaat voor apparaatauthenticatie. Including user PIN neemt volgens Sophos optioneel de gebruikers-PIN op in de apparaatauthenticatie. Pas geen van deze varianten zonder controle toe op elke aanbieder en leg geen echte sleutels of PIN’s vast in tickets.
• Send all traffic through VPN is de instelling om al het verkeer via deze VPN-verbinding te sturen. Sophos beschrijft hierbij dat al het verkeer door het VPN wordt gestuurd. Controleer de daadwerkelijke verkeersroute op het testapparaat in de gekozen aanbieder-/tunnelmodus en controleer het MDM-retourkanaal afzonderlijk. Dit bewijst niet dat al het verkeer zonder uitzondering wordt vastgelegd of dat apps worden geïsoleerd.
• Stel onder Proxy de proxy voor deze VPN-verbinding in. No proxy betekent zonder verbindingsproxy. Voer bij Manually onder Server and port het proxyadres en de poort in; Authentication is de proxy-gebruikersnaam en Password het bijbehorende wachtwoord. Geef bij Automatic onder Proxy server URL de URL van de server met de proxy-instellingen op. Deze keuze is noch de wifi-proxy, noch de globale HTTP-proxypayload; leid hieruit geen vereiste voor toezicht of garantie bij uitval af.
• Provider type maakt onderscheid tussen transportlagen, niet tussen de aanbieders onder Connection type. App proxy transporteert verkeer in de VPN-tunnel op applicatieniveau, Packet tunnel op netwerkniveau. App proxy is dus niet hetzelfde als per-app-VPN. Welke keuze de aanbieder ondersteunt en welk verkeer die daadwerkelijk omvat, moet nog op het doelapparaat worden gecontroleerd.

Per-app-VPN: invoer en verbindingsstart

Voor Per app VPN in een iOS-apparaatbeleid beschrijft Sophos de volgende invoer en gedragingen; de werking moet nog in de pilot worden gecontroleerd. Deze gegevens lossen de hierboven genoemde tegenstrijdigheid bij de app-toewijzing van User Policy niet op.

Bij Per app VPN in zowel iOS-apparaatbeleid als iOS-gebruikersbeleid is Connection name de naam van de verbinding die op het apparaat wordt weergegeven. Dit is de zichtbare verbindingsnaam, niet de reverse-DNS-identificatie van de aanbieder-app, het serveradres of het gebruikersaccount.

• Aanbieder-app: Als de VPN-aanbieder een app in de App Store heeft die de VPN-verbinding verzorgt, kies dan Custom SSL/TLS. Deze VPN-app moet op het apparaat geïnstalleerd zijn; voer onder Identifier (reverse DNS format) de identificatie ervan in reverse-DNS-formaat in, niet die van de bedrijfsapp waarvan het verkeer door de tunnel moet gaan.
• VPN-aanmelding: Server is de hostnaam of het IP-adres van de VPN-server en Account het gebruikersaccount voor authenticatie van de verbinding. Kies onder User authentication tussen Password en Certificate en geef daarbij onder Password het VPN-wachtwoord of onder Certificate het VPN-authenticatiecertificaat op. Deze gegevens staan los van de inloggegevens van een verbindingsproxy.
• Verbindingsstart: Als Connect automatically on demand is ingeschakeld, activeert het apparaat volgens Sophos het VPN wanneer de app een netwerkverbinding maakt. Als de optie is uitgeschakeld, moeten gebruikers het VPN zelf inschakelen. Controleer beide werkwijzen op het beoogde testapparaat.
• Verbindingsproxy: Proxy biedt No proxy, Manually en Automatic. Geef bij handmatige configuratie onder Server and port het geldige proxyadres en de poort op, onder Authentication de proxy-gebruikersnaam en onder Password het bijbehorende wachtwoord. Voer bij automatische configuratie onder Proxy server URL de URL van de server met de proxy-instellingen in. Dit is de proxy voor deze VPN-verbinding, niet de globale HTTP-proxypayload.

Voor Domains in Safari, Domains in Calendar, Domains in Contacts en Domains in Mail geldt dezelfde invoersyntaxis: één domein, gedeeltelijk domein of hostnaam per regel. Een gedeeltelijk domein komt overeen wanneer alle door punten gescheiden onderdelen van rechts af overeenkomen; punten aan het begin en einde worden genegeerd. Een tekenreeks zonder punt komt alleen overeen met de host met die naam, niet met willekeurige domeinen met die uitgang. Daarnaast geldt de aanvullende regel voor het domein op het tweede niveau voor agenda, contacten en e-mail; de pilotsectie beschrijft de passende positieve test.

Per-app-VPN in gebruikersbeleid en app-toewijzing

De Sophos-beschrijving van Per app VPN in een iOS-gebruikersbeleid documenteert eveneens de hierboven uitgelegde invoer voor de geïnstalleerde VPN-aanbieder-app en de reverse-DNS-identificatie ervan, de aanmelding met Password of Certificate, de on-demand-verbindingsstart, de verbindingsproxy en de domeinsyntaxis. Deze gedocumenteerde overeenkomsten bewijzen niet dat er bij Apple User Enrollment een werkende toewijzingsroute bestaat.

Sophos documenteert de volgende voorwaardelijke velden voor Per app VPN in zowel iOS-apparaatbeleid als iOS-gebruikersbeleid. De voorwaarden gelden voor beide beleidstypen; controleer de beschikbaarheid en ondersteuning door de aanbieder in de eigen tenant:

• Onder Third-party settings kunnen verbindingseigenschappen worden ingevoerd die de VPN-aanbieder voorschrijft. Het veld is alleen beschikbaar bij Custom SSL/TLS. Voer met Add de bevestigde waarden voor Key en Value in. Deze verbindingseigenschappen zijn niet de Managed configuration van de bedrijfsapp waarvan het verkeer door de tunnel moet gaan.
• Group is de groep die voor de aanmelding vereist is. Het veld is alleen beschikbaar voor Cisco AnyConnect en Cisco Legacy AnyConnect. Pas deze voorwaarde niet toe op andere verbindingstypen.
• Bij Provider type transporteert App proxy het verkeer in de VPN-tunnel op applicatieniveau en Packet tunnel op netwerkniveau. Voor Cisco AnyConnect is deze instelling niet beschikbaar. Controleer op het beoogde testapparaat welke keuze de aanbieder ondersteunt en welk verkeer die daadwerkelijk omvat. De transportlaag alleen bewijst noch app-isolatie, noch een apparaatbrede VPN-werking.

De toewijzing van een bestaande verbinding aan de bedrijfsapp hoort bij de app-distributiewerkwijze in de sectie ‘Beheerde configuratie en appgedrag controleren’. Daar is Per-app-VPN toewijzen uitdrukkelijk beperkt tot bestaand apparaatbeleid. De beleidsverantwoordelijken stellen de passende verbinding beschikbaar; de app-verantwoordelijken selecteren die onder VPN connection used by the app. Deze verwijzing lost de hierboven beschreven onzekerheid bij gebruikersbeleid niet op en geeft geen toestemming voor een ongecontroleerde BYOD-toewijzingsroute.

Controleer vooraf, observeer tijdens de pilot en spoor storingen op

1. Inventaris en herstelroute: Noteer eigendom, inschrijving, Supervision, iOS/iPadOS-versie, betrokken beleid en toewijzing. Leg voor een zakelijk testapparaat onder toezicht en een vrijwillig BYOD-testapparaat elk een onafhankelijke netwerkroute (bijvoorbeeld mobiel internet of andere wifi) en een contactpersoon vast. Voer zonder die route geen wijziging door die het apparaat mogelijk buitensluit. Gebruik voor wijzigingen in iOS-apparaatbeleid een uitsluitend aan het zakelijke pilottestapparaat toegewezen testbeleid en controleer vóór het bijwerken de huidige toewijzingen en het aantal doelapparaten; wijzig voor de pilot geen beleid dat al in productie is toegewezen.
2. Afhankelijkheden: Test vóór en na de wijziging de bereikbaarheid van DNS, APNs/MDM, CA/SCEP/RA, RADIUS/EAP-server, PAC/WPAD en het VPN-eindpunt. Controleer certificaatketen, servernamen, vervaldatum en geplande vervanging; kopieer geen privésleutels, challenges of inloggegevens naar tickets. Een geldige beleidstoewijzing op zichzelf bewijst niet dat wifi of VPN werkt.
3. Gerichte pilot: Begin met afzonderlijke testapparaten en een minimale toewijzing. Leg het volgende vast als testcriteria, niet als bevestigde resultaten: Het apparaat accepteert de gecontroleerde identiteit van de RADIUS-server en maakt verbinding met de zakelijke wifi. Controleer bij certificaatgebaseerde aanmelding bovendien de ontvangst van het clientcertificaat en de acceptatie ervan door RADIUS; controleer bij aanmelding met gebruikersnaam en wachtwoord de beoogde aanmeldroute met inloggegevens. Controleer bij per-app-VPN het tunnelverkeer van de toegewezen beheerde test-app; gebruik toegangspogingen vanuit andere apps alleen als negatieve test als die apps niet onder een andere VPN-toewijzing vallen en ook niet onder een ingestelde domeinregel. Als er domeinen zijn ingesteld voor Safari/andere browsers, agenda, contacten of e-mail, test dan ook de beoogde toegang tot overeenkomende domeinen en verwacht niet in het algemeen dat ‘ander verkeer buiten de tunnel blijft’. Test Safari-/browserdomeinen afzonderlijk: Volgens Sophos moet voor positieve tests met agenda, contacten en e-mail bovendien het domein op het tweede niveau van het opgegeven domein overeenkomen met dat van de VPN-server. Een afwijkend domein is geen geldige positieve tunneltest; als de tunnel daarvoor niet wordt gebruikt, bewijst dat op zichzelf niet dat de VPN-uitrol is mislukt. Controleer de domeinregels in de eigen tenant in plaats van hieruit een onbeproefd configuratierecept af te leiden. Controleer de werking van Send all traffic through VPN afzonderlijk op het testapparaat in de gekozen aanbieder-/tunnelmodus; leid daaruit geen ongecontroleerde apparaatbrede werking of app-isolatie af. Toon bij per-app-VPN met User Policy de daadwerkelijk beschikbare app-toewijzing aan, of laat die functie voorlopig buiten beschouwing. Observeer bij PAC/WPAD het vastgelegde uitvalscenario voor web/proxy; bevestig na elke wijziging een nieuwe MDM-check-in en de daadwerkelijke netwerkfunctie afzonderlijk. Als de check-in uitblijft of de onafhankelijke netwerkroute ontbreekt, stop dan de pilot en wijs geen andere apparaten toe.
4. Storing lokaliseren: Controleer bij ontbrekende wifi eerst de SSID en het beveiligingstype, de EAP-servernaam en de vertrouwde CA; controleer bij aanmelding met inloggegevens de gebruikersnaam, het wachtwoord en de beoogde RADIUS-aanmeldroute, en bij certificaatgebaseerde aanmelding de uitgegeven clientidentiteit en de bereikbaarheid van de CA; bij webuitval PAC/WPAD/DNS en proxytoegang; bij app-uitval de aanbieder-app, tunnel, het certificaat en de toewijzing. Observeer taak/check-in en daadwerkelijke verbinding afzonderlijk. Veroorzaak geen tweede uitval door certificaten of profielen ongecontroleerd te verwijderen.

Terugdraaien zonder apparaatreset

Bereid vóór de pilot een werkend vervangend beleid en vervangende vertrouwensketen met een bereikbaar netwerk voor. Verwijder de oude CA en identiteitscertificaten pas als de vervanging op het doelapparaat én de MDM-check-in bevestigd zijn.

Volgens Sophos vereisen wijzigingen in iOS-apparaatbeleid Update devices: dit maakt een bijwerktaak aan voor alle apparaten waaraan het gewijzigde beleid is toegewezen, niet alleen voor het pilottestapparaat. Werk daarom alleen het geïsoleerde pilotbeleid bij nadat de huidige doelapparaten zijn gecontroleerd; een gerichte Assign policy-taak voor geselecteerde apparaten is niet hetzelfde als het bijwerken van een gedeeld toegewezen beleid. De gerichte taak Uninstall policy is bedoeld voor Device Enrollment, maar kan zelf ook de netwerkroute verwijderen. Voor iOS-gebruikersbeleid op apparaten met User Enrollment bestaat deze taak Uninstall policy niet: Sophos biedt in plaats daarvan de gerichte taak Unassign iOS user policy. Afhankelijk van de storing kan het bijwerken of toewijzen van ander beleid eveneens zinvol zijn. Verwar de gerichte taak niet met Unassign voor alle apparaten.

iPadOS: maak onderscheid tussen directe acties en taaktypen. De beleidshandleiding licht de uiteenlopende benamingen voor de directe bijwerk- en deïnstallatieroutes toe: het typenoverzicht noemt iOS/iPadOS, de directe instructies alleen iOS device policies. Neem het klikpad daarvan daarom niet zonder controle over voor iPadOS; stel in de tenant en op het pilottestapparaat vast welke directe route beschikbaar is. Dit betekent niet dat het terugdraaien op iPadOS in het algemeen ongedocumenteerd of onmogelijk is: de iOS/iPadOS-taaktypen documenteren Uninstall policy voor Device Enrollment en Unassign iOS user policy voor User Enrollment. De modusafhankelijke taakbundelprocedure beschrijft deze keuze; blijf de taakoverdracht en het daadwerkelijke effect van het terugdraaien afzonderlijk controleren.

Test het terugdraaien afzonderlijk op een bereikbaar zakelijk testapparaat met Device Enrollment en een bereikbaar BYOD-testapparaat met User Enrollment: probeer op het zakelijke apparaat de passende gerichte Uninstall policy-taak voor precies dat apparaat en op het BYOD-apparaat de gerichte taak Unassign iOS user policy. Bevestig per apparaat de taak-/check-instatus en de daadwerkelijk gesynchroniseerde beleidstoestand; test daarna wifi-/VPN-werking en MDM-contact opnieuw, onafhankelijk van elkaar. Beperk verdere toewijzingen of terugdraaiingen tot de daadwerkelijk gecontroleerde testapparaten totdat beide herstelroutes zijn aangetoond. Een opgeslagen of verzonden taak bereikt een offline buitengesloten apparaat niet automatisch. Daarvoor zijn de vooraf geplande onafhankelijke netwerkroute en lokale herstelroute nodig; Unassign voor alle apparaten is geen risicoloze noodmaatregel. Noch volledig wissen (Wipe), noch uitschrijving via User Enrollment is een algemene rollback van beleid.