Accesso VPN con account di servizio: certificato o login condiviso

Due progetti coprono quasi ogni configurazione VPN non presidiata: un login umano condiviso tenuto in uno script, o un certificato macchina legato all’host. Falliscono in punti diversi, il che conta più della velocità di configurazione. Una password memorizzata si rompe quando il proprietario la cambia o se ne va; un certificato si rompe quando scade o quando l’host viene ricostruito senza la chiave. Tre condizioni decidono quale costo potete sopportare, e nessuno dei due progetti limita nulla finché non lo fa la policy di autorizzazione.

Partite dal compito, non dall’account

Il compito definisce il confine: quali destinazioni, quali servizi, quali orari, quanto può durare una sessione. Una rotta del tunnel è solo metà di quel confine. Il gateway decide se la sessione è consentita; la risorsa dietro decide cosa può fare la sessione. Scrivete prima l’elenco, con un proprietario nominato, perché entrambi i progetti di identità devono soddisfarlo.

Tenete separati autenticazione e autorizzazione mentre lo scrivete. L’autenticazione risponde a chi si connette; l’autorizzazione risponde a cosa può raggiungere la sessione dopo. RADIUS trasporta la seconda parte come attributi quali Filter-Id, Framed-IP-Address, Session-Timeout e Class, e il gateway li allega quando il login riesce. Un progetto che scambia il login e lascia intatta l’autorizzazione non ha limitato nulla.

Login umano condiviso: la password diventa il confine

Riusare un account umano è la strada più rapida e quella che invecchia peggio. La credenziale è una password, quindi finisce in uno script, in un file d’ambiente e in una configurazione dello scheduler, e ogni copia richiede rotazione. Quando il proprietario la cambia di venerdì, il job fallisce alla corsa successiva e nessuno sta guardando.

L’MFA è il punto in cui questo progetto di solito crolla. Uno script non può rispondere a una richiesta push, quindi l’account viene escluso dalla policy, ed è esattamente l’account che sceglierebbe un attaccante. Esclusioni, bypass di posizioni attendibili ed esenzioni per account si moltiplicano, e nessuna è visibile alla persona successiva che legge le impostazioni del tenant.

L’attribuzione è l’altro costo. Ogni sessione nel log del gateway porta lo stesso nome utente, quindi la sincronizzazione notturna non si distingue dal lavoro della persona che l’ha scritta, e revocare il job significa revocare quella persona.

Certificato macchina: identità legata all’host

Un certificato cambia la domanda da ciò che l’account sa a ciò che l’host è. Con EAP-TLS il client presenta un certificato e prova il possesso della chiave privata corrispondente; il server dei criteri mappa il soggetto o l’account computer a un gruppo e applica la policy per quel gruppo. Nessun prompt, nessun segreto condiviso in un file di testo.

Il confine che crea è più stretto di quanto le persone si aspettino. Un certificato autentica l’host, non il compito, e chiunque abbia diritti di root o di amministratore locale può usare quella chiave su quell’host. Tenete la chiave dove la piattaforma la protegge: non esportabile nell’archivio certificati di Windows, con supporto TPM dove il profilo lo consente, oppure un file 0600 di proprietà di root su Linux. Compromettere l’host è compromettere la credenziale.

La scadenza è il guasto ricorrente. Un certificato che scade di domenica ferma il job di domenica, e il gateway di solito segnala un errore di autenticazione generico invece di indicare la data. Controllate le date dall’host del job come parte del runbook:

openssl x509 -in client.pem -noout -subject -issuer -dates
ipsec listcerts

La revoca richiede un percorso che il gateway verifichi. OpenVPN legge una CRL tramite l’opzione crl-verify, e strongSwan dipende da CRL o OCSP a seconda di come è costruito il profilo di connessione. Se nessuno dei due è collegato, rimuovere un host significa aspettare che il certificato scada.

Tre condizioni che decidono tra loro

Fate il confronto con la piattaforma che avete, non con un progetto di riferimento.

Prima condizione: il gateway può autorizzare un’identità macchina? Se mappa solo un nome utente RADIUS a un utente della directory, un certificato autentica l’host e poi si blocca sull’autorizzazione. Seconda condizione: il job ha bisogno di un accesso a una risorsa che solo un account utente porta, come una condivisione mappata o una licenza per postazione? Allora un’identità macchina non può sostituirla, e la risposta onesta è un account utente dedicato con una policy ristretta. Terza condizione: chi può ruotare la credenziale senza una persona nel ciclo? L’iscrizione automatica rende i certificati economici da mantenere; una password nota a una sola persona no.

Leggete la tabella come un elenco di costi, non come una classifica. La colonna del segreto memorizzato vince sulla velocità di revoca e sulla compatibilità con risorse che capiscono solo account utente; la colonna del certificato vince sulla rotazione e sul non indebolire l’MFA per far funzionare uno script.

Mettete il limite nella policy, dopo l’autenticazione

Qualunque identità scegliate, il limite dei permessi appartiene alla policy che viene eseguita dopo l’autenticazione. In NPS i criteri di rete vengono valutati in ordine e il primo criterio che corrisponde a ogni condizione applica le sue impostazioni, quindi un criterio ampio posto sopra uno stretto decide il risultato indipendentemente da ciò che presenta il client. Microsoft documenta il modello di condizioni e impostazioni nella sua panoramica dei criteri NPS.

Date al job un proprio gruppo o una propria condizione di policy, basata su qualcosa che l’identità macchina porta: un modello di certificato, un identificatore di stazione chiamante o un indirizzo da un pool dedicato. Poi vincolate la sessione con attributi: un Filter-Id per il ruolo a cui il vostro gateway la mappa, un Session-Timeout breve così un job bloccato si riautentica invece di tenere una sessione per giorni, e un Framed-IP-Address da un pool che filtrate con firewall dall’altra parte. L’autorizzazione applicativa resta separata: un tunnel verso un server di database non è il permesso di leggere una tabella al suo interno.

Verificate i rifiuti, poi pianificate la rimozione

Un accesso che funziona non dimostra nulla sul privilegio minimo. Testate invece i rifiuti: connettetevi con l’identità del job e cercate di raggiungere una destinazione fuori dall’elenco, aprite una seconda sessione simultanea se il gateway deve consentirne una sola, e ripetete il login dopo aver revocato la credenziale.

Poi confermate la stessa sessione in due posti. Il log del gateway mostra l’identità che si è autenticata; il log del server dei criteri mostra quale policy ha corrisposto e quali attributi ha restituito. Su OpenVPN il server registra il nome comune del certificato, e ipsec statusall su strongSwan stampa il tunnel stabilito con l’identità in uso. Se i due log non concordano sull’identità, la policy sta corrispondendo a qualcosa di diverso da ciò che supponete.

La rimozione fa parte del progetto, non di uno sprint di pulizia. Scrivete tutto ciò che va eliminato (certificato o account, appartenenza a gruppi, policy di rete, voce del pool, regola firewall sull’obiettivo) e fatelo una volta mentre il job è facile da ricostruire.

Se iniziate oggi, lavorate in questo ordine: scrivete l’elenco delle risorse, scegliete l’identità con le tre condizioni, mettete il limite nella policy ed esercitate un rifiuto prima che il job vada in produzione.