Disegna il percorso decifrato: dove un'appliance VPN applica la policy
Un diagramma che si ferma al listener cifrato non mostra la policy che conta. Disegna il percorso decifrato, poi confronta le posizioni per ciò che la richiesta attraversa.
I diagrammi dei fornitori di solito si fermano al listener cifrato, perché è la parte con un indirizzo pubblico. La domanda che decide la postura di sicurezza è cosa accade dopo la decifratura, quando il pacchetto diventa IP ordinario e può raggiungere tutto ciò che la tabella di routing consente. Se nessuno ha disegnato quel tratto, nessuno lo possiede. Il runbook qui sotto lo disegna per primo e poi confronta le posizioni per ciò che la richiesta decifrata attraversa davvero.
Disegna il pacchetto dopo la decifratura, non prima
Il percorso esterno è la parte che i fornitori documentano: un endpoint pubblico, una policy di trasporto che ammette la connessione e un servizio che la termina. Il percorso interno inizia nel momento in cui il pacchetto perde l'intestazione del tunnel, e da lì è governato da regole di routing e di filtro che non hanno nulla a che vedere con il tunnel. Metti entrambi sulla stessa pagina, perché un diagramma con solo il primo suggerisce che ammissione e autorizzazione siano un'unica decisione. Non lo sono, e lo scarto tra le due è dove la maggior parte delle posizioni sbaglia.
Scrivi il tratto interno come una sequenza numerata con tipi di dispositivo nominati, non come una freccia. Una freccia nasconde se la richiesta attraversa un filtro, e attraversarlo o no è tutta la questione. Ogni salto qui sotto nomina il dispositivo e l'insieme di regole che agisce lì, così un filtro mancante appare come un vuoto invece di essere suggerito da una linea.
- Client remoto: il dispositivo dell'utente che origina il tunnel.
- Policy di bordo: l'insieme di regole che ammette il trasporto esterno verso il listener pubblico.
- Appliance di terminazione: l'endpoint VPN che decapsula e consegna il pacchetto all'IP ordinario.
- Filtro interno: l'insieme di regole di inoltro o di gruppi di sicurezza che limita il traffico da client a servizio.
- Host applicativo: il servizio che riceve la richiesta decifrata.
Due policy, due proprietari
La policy esterna risponde a chi può stabilire un tunnel, ed è espressa nelle regole che ammettono il trasporto verso il servizio di terminazione. La policy interna risponde a quale servizio può raggiungere un utente autenticato, e vive nelle regole di inoltro, nei gruppi di sicurezza o nell'applicazione stessa. Un solo dispositivo può ospitare entrambe, e un progetto con più dispositivi le ha comunque entrambe. È il nominarle separatamente che ti permette di dire quale ha fallito quando un utente non raggiunge un'applicazione.
I controlli di ammissione come i certificati e l'autenticazione a più fattori rispondono all'identità e a nient'altro. Non decidono la posizione e non concedono permessi per singola risorsa una volta che l'utente è dentro.
La posizione decide quale confine attraversa la richiesta
Tre posizioni sono comuni, e ciascuna cambia quale confine attraversa la richiesta decifrata. Confrontale per ciò che termina lì, ciò che può vedere il testo in chiaro, quale controllo può ancora negare la richiesta e cosa fallisce insieme all'appliance. La tabella qui sotto usa quelle quattro colonne invece di una domanda generica, perché ogni risposta è una decisione di progetto separata.
| Placement | What terminates there | What sees plaintext | Which control can still deny | Failure domain |
|---|---|---|---|---|
| Termination in a dedicated segment | A dedicated VPN endpoint | The endpoint and anything on its segment | The filter between that segment and the application | The segment path can bypass the filter if no rule sits on it |
| Termination on the edge firewall | The firewall's public listener | The firewall, after decapsulation | The firewall's inner rule set | Admission and inspection fail together |
| Termination on the protected LAN | The appliance's LAN leg | Every host on the protected LAN | Only a host control or a downstream gateway | The appliance and the protected hosts fail together |
La terza posizione è quella che elimina in silenzio l'applicazione, perché un tratto sul segmento protetto dà all'appliance un percorso diretto che il diagramma potrebbe non mostrare. Ispeziona le interfacce e le rotte invece dell'immagine: ip route get 10.20.5.10 riporta da quale interfaccia uscirebbe il pacchetto, e la risposta spesso non è quella che il progetto aveva assunto. Il ruolo classico del firewall di controllare il traffico tra posture, come descritto inNIST SP 800-41, è una prova utile qui, perché un dispositivo con un tratto senza restrizioni verso la rete protetta non controlla granché. Una ricerca di rotta è un diagramma più onesto di quello nella presentazione.
L'amministrazione appartiene a un proprio percorso esplicitamente consentito. Permettere agli utenti di raggiungere un'applicazione non richiede mai di permettere loro di raggiungere l'interfaccia di controllo dell'appliance, e i due permessi vanno concessi da regole diverse. Verifica entrambi i percorsi separatamente, perché una regola condivisa nasconde quale è stato aperto.
La traduzione cambia ciò che le regole a valle possono vedere
La traduzione della sorgente è comoda e distrugge informazione. Dopo il masquerade ogni client sembra l'appliance, quindi una regola a valle scritta per distinguere gli utenti non può più farlo. Non è solo un problema di log, è un problema di policy: una regola basata sull'indirizzo del client diventa in silenzio una regola basata sul gateway. Se la policy per utente conta, preserva la sorgente o applica la policy prima della traduzione.
Il percorso di ritorno merita lo stesso esame. Registra quale rotta la destinazione sceglie per il pacchetto di ritorno, perché un ritorno asimmetrico aggira l'ispezione con stato e produce una connessione che si stabilisce e poi si blocca. Entrambe le direzioni devono attraversare il confine che hai disegnato, altrimenti il confine è decorazione.
sudo tcpdump -ni inside0 host 10.20.5.10
ip route get 10.20.5.10
sudo iptables -t nat -S POSTROUTINGAccetta un'operazione consentita e una negata
Prova dal vero client remoto e non da un host di gestione, perché l'host di gestione di solito sta dove l'utente non sarà mai. Un'operazione consentita dimostra che il percorso funziona, e una negata dimostra che la policy fa qualcosa. Esegui entrambe dopo ogni cambio di posizione e registra l'identità di sorgente e la destinazione usate. Un test che dimostra solo il successo non distingue una regola corretta da una assente.
Poi prova i casi che cambiano stato: una riconnessione, una sessione che sopravvive a una rotazione delle chiavi e un guasto dell'appliance stessa. Confronta aggiornamenti, capacità e recupero come parte dello stesso layout, perché un'appliance che regge più controlli logici è un solo dominio di guasto con più etichette. Anche una seconda scatola non è indipendente quando una credenziale amministrativa condivisa o una rotta senza restrizioni sconfigge il confine che doveva creare.
Documenta l'endpoint, il percorso decifrato e il controllo che lo limita. Quelle tre righe restano significative qualunque sia il nome dell'implementazione.