Acceptar l’accés remot per VPC requereix proves de denegació

L’acceptació de l’accés remot és una taula de resultats esperats, no una captura de pantalla d’una pàgina que funciona. Per a cada grup, escriviu què hauria de funcionar i què hauria de fallar, i després executeu totes dues coses amb identitats de prova dedicades en una finestra controlada. Les denegacions són la part que demostra la frontera; un inici de sessió correcte només demostra que el túnel existeix. Tot això funciona amb el producte VPN ja triat.

Feu servir comptes separats per a les proves i etiqueteu-los de manera que ningú confongui una identitat de prova amb una excepció real.

Escriviu la frontera com a resultats esperats

Comenceu pels rols i no pels components: qui necessita quin servei, des d’on i amb quina identitat. Agafeu una VPC il·lustrativa: un grup necessita l’entorn de proves per HTTPS, un altre necessita una base de dades de producció, i un tercer grup, més petit, administra la mateixa passarel·la. Cada fila rep una autorització esperada i una denegació esperada, incloent-hi el servei veí i el compte veí que no haurien de funcionar. Aquesta taula és el criteri d’acceptació, i les persones que no executen les proves la poden revisar.

Proveu l’inici de sessió a la base de dades per separat del camí de xarxa. Un port TCP accessible no hauria de fer que un compte de base de dades no aprovat tingués èxit, i la pertinença a la VPN no hauria de crear un rol IAM al núvol ni concedir accés administratiu a l’API. Són tres controls independents, i fallen de manera independent.

La ruta no és autorització

Una ruta fa possible un camí; no atorga permís. Retenir una ruta és un substitut feble d’una restricció aplicada a la destinació, ja que un client sempre pot afegir una ruta pròpia. El grup de seguretat, la concessió de la base de dades i l’autorització pròpia de l’aplicació continuen sent els controls que decideixen. Quan una prova té èxit inesperadament, mireu primer la política de la destinació i no la taula d’encaminament que volíeu que tingués el client.

Per això també les proves de denegació apunten al costat del servidor: aquests resultats no es poden canviar editant el client.

Quina font veu realment el control?

L’adreça d’origen que avalua un control depèn de l’arquitectura de la passarel·la. Una passarel·la allotjada a EC2 pot reenviar un pool encaminat, traduir-lo a la seva pròpia adreça o presentar una adreça diferent després del NAT; el Client VPN gestionat s’associa a una subxarxa i segueix el seu propi model. Els grups de seguretat i les ACL de xarxa veuen el que arriba després d’aquest processament. Inspeccionar una regla amb una suposició d’origen incorrecta és una manera habitual de construir una frontera que sembla correcta i admet el trànsit equivocat.

Correlacioneu cada resultat amb l’esdeveniment útil més petit: identitat i sessió, recurs, operació, hora i la decisió. Una crida a l’API de CloudTrail, un registre de flux de VPC i un registre de sessió VPN responen a preguntes diferents, i cap d’ells sol no és una auditoria de l’aplicació.

Retireu una identitat i torneu-la a provar

Incloeu la retirada a la mateixa taula. Elimineu una identitat de prova, confirmeu que es rebutja una sessió nova i després confirmeu per separat com es tracten les sessions existents, perquè són comportaments diferents amb propietaris diferents. Comproveu què passa després de reiniciar o substituir la passarel·la, perquè una excepció afegida a mà no desaparegui en silenci ni torni més àmplia. Una frontera que només dura fins al proper desplegament no és una frontera.

Res d’això no substitueix la feina de pedaços, recuperació o cicle de vida de credencials. Fa mesurable una promesa més estreta: les persones correctes arriben als serveis correctes, mentre que les rutes, els comptes i les superfícies de gestió properes queden fora de la concessió.

Manteniu la taula amb el desplegament i torneu-la a executar quan canviï la passarel·la. Les proves són barates; les suposicions que hi ha darrere, no.