Accesso da VPN a VLAN: costruite prima la matrice delle regole
Ruoli da un lato, servizi dall'altro. Cinque controlli trasformano un progetto vago di accesso da VPN a VLAN in una tabella che il responsabile del firewall può implementare.
Partite dalla matrice, non dalla sintassi del firewall. Una tabella con i ruoli da un lato e i servizi dall'altro può essere esaminata dal responsabile di un'applicazione, discussa dal responsabile della sicurezza e implementata da chi tiene il gateway. Quell'esame costa meno che fare debug di regole su cui nessuno si è messo d'accordo.
Un'ora di scrittura risparmia poi una settimana di archeologia delle regole. Il progetto parla di chi raggiunge quale servizio, ed è la parte che sopravvive alla rinumerazione.
Fase 1: nominate i ruoli prima delle reti
Partite dalle persone, non dallo switch. Annotate ogni gruppo che si collega da remoto e l'unica frase che descrive cosa fa quel gruppo, per esempio personale di magazzino che legge i livelli di scorta o un fornitore che mantiene un'integrazione. Se due gruppi ricevessero lo stesso accesso, per questo scopo sono un solo ruolo.
Fermatevi qui se un ruolo esiste solo per un organigramma. Un ruolo senza un bisogno di servizio proprio diventa una riga di celle identiche, e le righe identiche invitano qualcuno a concedere in seguito un'intera sottorete per comodità. Dividete per ciò che le persone fanno, non per chi firma le loro spese. Sei ruoli sono di solito troppi per un piccolo ufficio e tre spesso è la misura giusta.
Fase 2: trasformate ogni cella in un'affermazione di servizio
Una cella che dice «Applicazioni» non è verificabile. Una cella che dice «HTTPS verso l'host ERP sulla 443, dal pool del personale» lo è. Sostituite ogni nome di rete con una destinazione, un protocollo e una porta, poi aggiungete la dipendenza senza la quale il servizio non funziona, come il resolver interno o il fornitore di identità.
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
La colonna della direzione intercetta gli errori più costosi. Il permesso per il personale di aprire un'applicazione non implica il permesso per i server applicativi di aprire connessioni verso i portatili del personale, e una regola con stato che consente la prima direzione viene spesso letta come se consentisse la seconda.
Fase 3: decidete dove l'identità diventa politica
Qualcuno deve trasformare una sessione autenticata in un ruolo che il gateway può applicare. Le opzioni supportate includono policy di gruppo fornite dal backend di autenticazione, attributi di sessione attendibili o pool di indirizzi separati per ruolo. Tutte e tre funzionano; un'etichetta inviata dal client no. Scegliete il meccanismo che il vostro gateway documenta, non quello descritto da un messaggio di un forum.
Assegnare un indirizzo che sembra solo appartenere a una VLAN è la stessa non-risposta in un altro costume. La guida di Netgate alle regole del firewall di OpenVPN rende chiara la separazione: consentire al tunnel di salire è una decisione diversa dal consentire al traffico di attraversarlo.
Annotate quale meccanismo avete scelto e dove è configurato. Quando un ruolo cambia, quella nota è la differenza tra una modifica e una caccia attraverso tre interfacce. Dice anche a un revisore dove guardare per primo.
Fase 4: osservate l'indirizzo sorgente che vede la destinazione
La politica di inoltro deve corrispondere alla sorgente reale al confine. Se il gateway traduce i client VPN sul proprio indirizzo, ogni firewall a valle vede un'unica sorgente e perde la capacità di decidere per ruolo. Se conserva l'indirizzo del client, il percorso di ritorno deve esistere per quel pool.
Provate entrambe le direzioni prima di scrivere le regole finali, poi annotate la sorgente osservata accanto a ogni cella. Eseguite lo stesso controllo da due ruoli diversi e confrontate il risultato. Se entrambi mostrano l'indirizzo del gateway, la distinzione dei ruoli è già persa. Una matrice che presuppone indirizzi conservati mentre il gateway fa traduzione di sorgente fallisce alla prima ACL a valle.
Fase 5: provate ogni cella prima di pubblicare
Trasformate ogni cella consentita in un'operazione rappresentativa e ogni cella negata in un caso negativo. Eseguite entrambe da un client nel ruolo reale, non dalla console del gateway, perché la console aggira il percorso che state provando.
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'Un caso negativo che si connette è una scoperta, non un caso fortuito, e va nella matrice come cella fallita finché la regola non è corretta. Tenete i comandi di test accanto alla tabella perché il prossimo revisore li riesegua invece di ricostruire il ragionamento.
La tabella finita sopravvive al gateway per cui è stata scritta. Le regole cambiano con il firmware e il fornitore, mentre la riga che dice che un fornitore raggiunge un servizio di progetto resta vera finché quel lavoro non cambia.