Chiudete l'anteprima temporanea prima che diventi permanente

Un revisore che non può accedere alla VPN ha bisogno di un link per un pomeriggio, e la sera il servizio di produzione ha un nome host pubblico che nessuno ricorda di aver approvato. La richiesta era piccola; il cambiamento no. Un'anteprima temporanea è un nuovo percorso di accesso con un pubblico, un perimetro di dati e un'ora di fine. Trattatela come qualsiasi altro ingresso, perché la parola temporaneo non chiude nulla.

Temporaneo è una durata, non un controllo

La parola temporaneo descrive quanto a lungo qualcosa dovrebbe esistere, non ciò che lo limita mentre esiste. Un nome host pubblico senza scadenza diventa permanente nel momento in cui la persona che l'ha creato cambia team.

Prima che qualcosa venga esposto, il proprietario del servizio e il proprietario della sicurezza dovrebbero approvare tre cose: il pubblico, i dati e la durata.

Un ambiente ospite o di revisione esistente è spesso più semplice della pubblicazione del servizio di produzione. Ha già un proprietario, un percorso di approvazione e un processo di rimozione. Costruire una nuova eccezione per un pomeriggio è il modo in cui una piccola richiesta diventa un bene permanente. Iniziate chiedendo se la revisione può avvenire dentro qualcosa che esiste già.

Pubblicate una sola operazione, mai una sottorete

Scegliete l'ingresso più piccolo che ancora supporta la revisione. Preferite una copia di preproduzione con dati adeguati alla produzione, e un frontend autenticato che raggiunge un'origine privata invece di qualsiasi rotta di sottorete.

Un relay con raggiungibilità VPN non deve pubblicare un'intera sottorete privata, e di certo non dovrebbe pubblicare l'interfaccia di amministrazione del gateway.

Nominate gli account autorizzati a passare e le azioni che possono compiere. Limitare per IP di origine restringe davvero chi può connettersi. Non identifica però una persona, perché gli indirizzi pubblici sono condivisi e cambiano.

Mantenete l'autorizzazione propria dell'applicazione o un ingresso esplicitamente fidato e consapevole dell'identità. Proteggete download, API e percorsi amministrativi, non solo la pagina di destinazione. Un frontend che termina TLS diventa un endpoint fidato, e una rotta privata dietro di esso non trasforma un visitatore pubblico in un membro della VPN. Testate i percorsi esclusi con la stessa cura della pagina di destinazione.

L'identità al frontend, non nell'indirizzo di origine

Le regole sull'IP di origine servono a ridurre l'esposizione e non servono a dimostrare chi è un revisore. Le connessioni domestiche cambiano, le reti mobili condividono indirizzi e un collega può trovarsi dietro lo stesso NAT.

Un proxy consapevole dell'identità o l'accesso proprio dell'applicazione vi dà una decisione per persona. È questo che rende possibile la revoca in seguito, perché potete rimuovere un'identità senza cambiare la rete.

Lasciate attiva la validazione dei certificati e bloccate l'accesso diretto all'origine. Se l'origine è ancora raggiungibile da internet, il frontend è solo decorazione.

Revocate il diritto e la rotta

Registrate un proprietario e una scadenza esatta nel sistema operativo che già traccia gli accessi. Usate un accesso limitato nel tempo o una rimozione pianificata dove la piattaforma lo supporta, e aggiungete un controllo nel caso l'automazione fallisca.

Alla fine concordata, ritirate il frontend temporaneo, l'autorizzazione di rotta e il diritto del revisore tramite i loro proprietari. Le sessioni esistenti e le connessioni di lunga durata richiedono un trattamento proprio, perché una rotta rimossa non le termina.

Un TTL DNS breve non è la scadenza dell'accesso. Cambia quanto a lungo un resolver conserva la risposta. Non disattiva un account, non interrompe una sessione attiva e non chiude una porta che sta ancora ascoltando.

Le copie in cache fanno parte dello stesso problema. Togliere il percorso dell'origine non recupera un file che qualcuno ha già salvato, e una cache condivisa può servire copie dopo che il relay è sparito. Scegliete la politica di risposta e di archiviazione prima che inizi la revisione.

Verificate che il vecchio percorso sia davvero sparito

L'accettazione è una nuova richiesta che fallisce, più il normale flusso di lavoro VPN che funziona ancora. Testate entrambe le cose, perché una rimozione che rompe il percorso ordinario non è una rimozione pulita.

Dall'esterno della rete, confermate che il nome e l'origine sono entrambi chiusi:

dig +short review.example
curl -sSI --max-time 5 https://review.example/
ss -ltnp | grep ':443'

Tenete un registro di audit ristretto di ciò che è stato approvato, chi poteva raggiungerlo e quando è stato rimosso. Quel registro è la differenza tra un'eccezione controllata e un nome host inspiegato. Un'anteprima temporanea riesce quando fornisce la revisione richiesta e poi smette di fornirla. La scomparsa dell'URL da un messaggio di chat non è quel test.