Aceptar o acceso remoto por VPC esixe probas de denegación

A aceptación do acceso remoto é unha táboa de resultados esperados, non unha captura de pantalla dunha páxina que funciona. Para cada grupo, escriba que debería funcionar e que debería fallar, e despois execute ambas as dúas cousas con identidades de proba dedicadas nunha xanela controlada. As denegacións son a parte que demostra a fronteira; un inicio de sesión correcto só demostra que o túnel existe. Todo isto funciona co produto VPN xa elixido.

Use contas separadas para as probas e etiquéteas de xeito que ninguén confunda unha identidade de proba cunha excepción real.

Escriba a fronteira como resultados esperados

Comece polos roles e non polos compoñentes: quen necesita que servizo, desde onde e con que identidade. Tome unha VPC ilustrativa: un grupo necesita a contorna de proba por HTTPS, outro necesita unha base de datos de produción, e un terceiro grupo, máis pequeno, administra a propia pasarela. Cada fila recibe unha autorización esperada e unha denegación esperada, incluído o servizo veciño e a conta veciña que non deberían funcionar. Esa táboa é o criterio de aceptación, e as persoas que non executan as probas poden revisala.

Probe o inicio de sesión na base de datos por separado do camiño de rede. Un porto TCP accesible non debería facer que unha conta de base de datos non aprobada teña éxito, e a pertenza á VPN non debería crear un rol IAM na nube nin conceder acceso administrativo á API. Son tres controis independentes, e fallan de xeito independente.

Unha ruta non é autorización

Unha ruta fai posible un camiño; non outorga permiso. Reter unha ruta é un substituto feble dunha restrición aplicada no destino, xa que un cliente sempre pode engadir unha ruta propia. O grupo de seguridade, a concesión da base de datos e a propia autorización da aplicación seguen sendo os controis que deciden. Cando unha proba ten éxito de xeito inesperado, mire primeiro a política do destino e non a táboa de encamiñamento que pretendía que tivese o cliente.

Por iso tamén as probas de denegación apuntan ao lado do servidor: eses resultados non se poden cambiar editando o cliente.

Que orixe ve realmente o control?

O enderezo de orixe que avalía un control depende da arquitectura da pasarela. Unha pasarela aloxada en EC2 pode reenviar un conxunto encamiñado, traducilo ao seu propio enderezo ou presentar outro enderezo despois do NAT; o Client VPN xestionado asóciase a unha subrede e segue o seu propio modelo. Os grupos de seguridade e as ACL de rede ven o que chega despois dese procesamento. Inspeccionar unha regra cunha suposición de orixe incorrecta é unha forma habitual de construír unha fronteira que parece correcta e admite o tráfico equivocado.

Correlacione cada resultado co acontecemento útil máis pequeno: identidade e sesión, recurso, operación, hora e a decisión. Unha chamada á API de CloudTrail, un rexistro de fluxo de VPC e un rexistro de sesión VPN responden a preguntas distintas, e ningún por si só é unha auditoría da aplicación.

Retire unha identidade e vólvaa probar

Inclúa a retirada na mesma táboa. Elimine unha identidade de proba, confirme que se rexeita unha sesión nova e despois confirme por separado como se tratan as sesións existentes, porque son comportamentos distintos con propietarios distintos. Comprobe que ocorre tras reiniciar ou substituír a pasarela, para que unha excepción engadida á man non desapareza en silencio nin volva máis ampla. Unha fronteira que só dura ata o seguinte despregamento non é unha fronteira.

Nada disto substitúe o traballo de parches, recuperación ou ciclo de vida das credenciais. Fai medible unha promesa máis estreita: as persoas correctas chegan aos servizos correctos, mentres que as rutas, contas e superficies de xestión próximas quedan fóra da concesión.

Manteña a táboa co despregamento e vólvaa executar cando cambie a pasarela. As probas son baratas; as suposicións que hai detrás, non.