Accettare l’accesso remoto VPC richiede test di rifiuto

L’accettazione dell’accesso remoto è una tabella di risultati attesi, non uno screenshot di una pagina funzionante. Per ogni gruppo scrivete cosa dovrebbe riuscire e cosa dovrebbe fallire, poi eseguite entrambi con identità di test dedicate in una finestra controllata. I rifiuti sono la parte che dimostra il confine; un login riuscito dimostra solo che il tunnel esiste. Tutto questo funziona con il prodotto VPN già scelto.

Usate account separati per i test ed etichettateli in modo che nessuno confonda un’identità di test con un’eccezione reale.

Scrivere il confine come risultati attesi

Partite dai ruoli e non dai componenti: chi ha bisogno di quale servizio, da dove e con quale identità. Prendete un VPC illustrativo: un gruppo ha bisogno dell’ambiente di staging via HTTPS, un altro di un database di produzione, e un terzo gruppo più piccolo amministra il gateway stesso. Ogni riga riceve un’autorizzazione attesa e un rifiuto atteso, compresi il servizio vicino e l’account vicino che non dovrebbero funzionare. Quella tabella è il criterio di accettazione, e chi non esegue i test può rivederla.

Testate il login al database separatamente dal percorso di rete. Una porta TCP raggiungibile non dovrebbe far riuscire un account database non approvato, e l’appartenenza alla VPN non dovrebbe creare un ruolo IAM cloud né concedere accesso amministrativo alle API. Sono tre controlli indipendenti, e falliscono in modo indipendente.

Una rotta non è un’autorizzazione

Una rotta rende possibile un percorso; non concede il permesso. Trattenere una rotta è un sostituto debole di una restrizione applicata alla destinazione, perché un client può sempre aggiungere una rotta propria. Il gruppo di sicurezza, la concessione del database e l’autorizzazione dell’applicazione restano i controlli che decidono. Quando un test riesce inaspettatamente, guardate prima la politica della destinazione e non la tabella di routing che volevate dare al client.

È anche per questo che i test di rifiuto mirano al lato server: quei risultati non si possono cambiare modificando il client.

Quale sorgente vede davvero il controllo?

L’indirizzo di origine che un controllo valuta dipende dall’architettura del gateway. Un gateway ospitato su EC2 può inoltrare un pool instradato, tradurlo nel proprio indirizzo o presentare un altro indirizzo dopo il NAT; il Client VPN gestito si associa a una sottorete e segue il proprio modello. I gruppi di sicurezza e le ACL di rete vedono ciò che arriva dopo quella elaborazione. Ispezionare una regola con l’ipotesi di origine sbagliata è un modo comune di costruire un confine che sembra corretto e ammette il traffico sbagliato.

Correlate ogni risultato con l’evento utile più piccolo: identità e sessione, risorsa, operazione, ora e la decisione. Una chiamata API di CloudTrail, un record di flusso VPC e un log di sessione VPN rispondono a domande diverse, e nessuno da solo è un audit dell’applicazione.

Ritirare un’identità e testarla di nuovo

Includete il ritiro nella stessa tabella. Rimuovete un’identità di test, confermate che una nuova sessione viene rifiutata, poi confermate separatamente come vengono trattate le sessioni esistenti, perché sono comportamenti diversi con proprietari diversi. Verificate cosa succede dopo un riavvio o una sostituzione del gateway, così un’eccezione aggiunta a mano non svanisca in silenzio né torni più ampia. Un confine che dura solo fino al prossimo deployment non è un confine.

Niente di tutto questo sostituisce il lavoro su patch, ripristino o ciclo di vita delle credenziali. Rende misurabile una promessa più stretta: le persone giuste raggiungono i servizi giusti, mentre rotte, account e superfici di gestione vicini restano fuori dalla concessione.

Tenete la tabella insieme al deployment e rieseguitela quando il gateway cambia. I test costano poco; le ipotesi dietro di essi no.