Utente Mac standard con una VPN gestita: cosa deve assumersi l’IT
Scegliete tra un profilo gestito, un installatore self-service e una connessione creata dall’utente su macOS, poi consegnate l’account senza diritti di amministratore.
Gli account macOS standard possono far funzionare una VPN aziendale tutto il giorno mentre l’IT conserva ogni operazione privilegiata. Arrivarci è una decisione di consegna, non una discussione sui permessi: scegliete chi installa il client, chi scrive la connessione e cosa può modificare l’utente. Tre vie coprono quasi tutti i casi, e ciascuna fallisce in modo diverso. Scegliete la via in base alla proprietà del dispositivo e al tipo di credenziale, poi provatela come utente standard anziché come voi stessi.
Tre vie di consegna e cosa risolve ciascuna
La prima via è un profilo di configurazione gestito, consegnato dalla gestione dei dispositivi dell’organizzazione. Il carico VPN trasporta il gateway, il metodo di autenticazione, le route e il DNS, e si installa attraverso il canale del dispositivo o dell’utente a seconda di come è registrato il Mac. La seconda via è un installatore self-service: l’utente esegue un pacchetto approvato che colloca il client e scrive la connessione al posto suo. Funziona quando manca un’iscrizione alla gestione, ma l’organizzazione vuole comunque una configurazione ripetibile e verificabile. La terza via è che l’utente crei la connessione a mano in Impostazioni di Sistema, seguendo valori pubblicati. È la più economica da avviare e la più costosa da supportare, perché ogni errore lato client diventa una chiamata all’help desk e ogni modifica un promemoria.
scutil --nc list
sudo profiles show -type configuration
system_profiler SPConfigurationProfileDataType
Leggete il primo elenco per vedere quali connessioni esistono e a chi appartengono, e gli altri due per vedere cosa è stato installato come criterio. Un profilo che non compare in nessuno dei due elenchi non è arrivato, qualunque cosa sia stata detta all’utente.
Decidete in base alla proprietà del dispositivo, non all’anzianità
Un Mac di proprietà dell’organizzazione di solito giustifica la prima via, perché lo stesso canale che consegna la VPN può rimuoverla, e l’utente non può modificare la connessione in silenzio. Scegliete il canale del dispositivo quando il tunnel deve esistere prima che qualsiasi utente acceda, e il canale dell’utente quando la connessione appartiene alla persona. Un Mac di proprietà personale con un servizio aziendale di solito punta alla seconda via. L’organizzazione non può gestire il dispositivo, quindi l’installatore deve essere piccolo, reversibile e documentato abbastanza bene che l’utente possa annullarlo.
La terza via resta ragionevole per una manciata di utenti tecnici con una configurazione stabile, e per chiunque provi un gateway prima del rilascio. Sotto quella scala diventa un insieme non verificato di impostazioni digitate a mano che nessuno può inventariare.
Separate il profilo dall’account
Un profilo di connessione locale dice come raggiungere il gateway. Un account autorizzato sul gateway dice se chi chiama può entrare. Sono forniti da persone diverse e revocati per motivi diversi, quindi non trattate mai il profilo come l’autorizzazione. I certificati stanno nel mezzo. Un certificato consegnato con il profilo autentica il dispositivo o l’utente, e revocarlo sul gateway termina l’accesso anche se il profilo resta sul disco. Un progetto basato solo sulla password si appoggia invece al ciclo di vita dell’account, per questo la nota di consegna deve dire quale dei due è in gioco.
Decidete anche se il client è una VPN di sistema o un tunnel per applicazione. Un progetto per applicazione instrada solo le applicazioni scelte, e dipende dal fatto che il client supporti quel modello sulla versione di macOS in uso, quindi verificatelo su una macchina pilota invece di dare per scontato che l’impostazione viaggi.
Consegnate senza password di amministratore
L’utente deve avviare la connessione, accedere e riprendersi da un cambio di password. Niente di tutto ciò richiede un account di amministratore, e niente giustifica incorporare credenziali in uno script, in un’azione Automator o in un passo successivo all’installazione di un pacchetto firmato.
scutil --nc start "Acme VPN"
scutil --nc status "Acme VPN"
log show --predicate 'subsystem == "com.apple.networkextension"' --last 10m
I primi due comandi sono operazioni a livello utente che un help desk può far seguire a qualcuno. Il terzo legge l’attività recente del tunnel quando una connessione fallisce, ed è l’artefatto da chiedere invece di uno screenshot di una finestra di errore.
Se un passo richiede ancora l’approvazione di un amministratore, è un difetto di consegna: rimandate la richiesta esatta al proprietario del profilo invece di distribuire un account con più autorità di quella che serve al compito.
Accedete come utente standard, poi scrivete l’uscita
Accedete con l’account standard, collegatevi, raggiungete l’host interno previsto, lasciate dormire il Mac, svegliatelo e confermate la riconnessione. Ripetetelo dopo un cambio di password, perché è proprio lì che metà di queste distribuzioni fallisce davvero. Scrivete il percorso di ripristino prima che il primo utente ne abbia bisogno: cosa fare quando il profilo manca, quando il certificato è scaduto e quando il gateway rifiuta un accesso altrimenti valido. Tenete quelle tre risposte dove l’help desk può trovarle.
Infine, pianificate la rimozione. Una VPN che non può essere rimossa dal Mac di un utente che se ne va in una sola operazione è un rilievo di revisione degli accessi che sta per accadere.