Les regles d'AWS Client VPN van al recurs, no a la subxarxa

El personal ha d'arribar a una aplicació a la VPC i no ha d'arribar al listener de base de dades de la mateixa instància, així que algú afegeix una segona subxarxa pública per a l'endpoint de VPN i dona el requisit per complert. La ubicació de la subxarxa canvia l'encaminament i la disponibilitat. No concedeix ni denega cap port. El permís que expressa el requisit viu a la destinació, al grup de seguretat del recurs, i la frontera de la VPN proporciona el mànec a què fa referència aquesta regla.

La ubicació de la subxarxa és encaminament, no autorització

On se situa l'associació de xarxa de l'endpoint decideix quina taula d'encaminament porta el trànsit dels clients i quines zones de disponibilitat sobreviuen a una fallada. No diu res sobre quin port de quina instància pot assolir aquest trànsit. Dos clients associats a la mateixa subxarxa arriben amb la mateixa identitat d'origen, i el recurs no els pot distingir pel nom de la subxarxa.

Comença, en lloc d'això, pel requisit: qui truca, quin recurs, quin port de servei i quina direcció. Després tria el model de regla que pot expressar aquestes quatre coses a la destinació. Aquest plantejament normalment elimina del tot la subxarxa extra del disseny.

El grup d'associació de Client VPN és el mànec

Per a un endpoint d'AWS Client VPN associat a una subxarxa, el dispositiu documentat és concret. Aplica el grup de seguretat previst a les associacions de xarxa objectiu de l'endpoint i després permet el trànsit necessari al grup de seguretat del recurs fent servir aquest grup de Client VPN com a origen.

Concretament, el grup de la instància d'aplicació permet el port de l'aplicació des del grup d'associació, i res més. El procediment d'accés al recurs d'AWS descriu aquesta relació, i val la pena mantenir la mateixa política de grup a cada subxarxa amb què s'associa l'endpoint, perquè una associació antiga amb un grup diferent amplia la frontera sense soroll.

Aquesta regla no autentica ningú. L'inici de sessió és un control a part, i la ruta fins al recurs és un tercer. Els tres han de complir-se abans que arribi una petició. El que falli decideix quina correcció és la bona, i canviar la regla és la resposta correcta només per al primer.

Què no pot distingir un sol grup d'associació

Cada client darrere del mateix grup d'associació arriba al recurs com el mateix origen de grup de seguretat. Dos usuaris amb rols diferents són indistingibles en aquesta capa, per molt que es nomeni o s'etiqueti el grup. L'autorització de grups externs de Client VPN limita l'accés pel prefix de destinació per a un grup de directori o SAML, cosa més grollera que un rol de recurs i que cal tractar com una frontera de xarxa, no com un sistema d'identitat.

Les distincions més fines pertanyen a l'aplicació. Un listener de base de dades que ha de romandre tancat per a la majoria del personal està millor protegit si no és accessible gens al prefix permès que si s'espera que la pertinença al grup es mantingui endreçada.

Canviar el nom del grup no crea cap identitat, i duplicar-lo per equip només multiplica les associacions que cal auditar.

No copiïs aquesta regla a tots els dissenys de VPN

Una passarel·la EC2 VPN autogestionada, un aparell d'inspecció encaminat i un Client VPN gestionat són tres camins de paquets diferents. Estableix quina adreça d'origen arriba realment al recurs, si hi ha traducció pel mig i quins mecanismes de referència admet el servei en aquest camí.

Fer passar el trànsit per un dispositiu intermedi no conserva una referència de grup de seguretat d'origen com ho fa el trànsit directe entre instàncies. AWS documenta que aquests dissenys poden necessitar les adreces privades d'origen o els CIDR adequats en lloc d'una referència de grup. El procediment del Client VPN gestionat no demostra que el grup adjunt de cada passarel·la funcioni com un testimoni d'identitat universal per als paquets reenviats.

Un sol salt NAT al camí ja trenca la suposició, i la fallada sembla una regla que hi és però que no coincideix mai.

Revisa la frontera efectiva

Llegeix cada grup de seguretat adjunt al recurs, perquè les regles de permetre es combinen i una regla estreta no cancel·la una de més àmplia en un altre grup. Després comprova la ACL de xarxa, el tallafocs de l'amfitrió i l'autorització pròpia de l'aplicació, que són capes separades amb errors separats.

Acaba amb una petició permesa i una petició exclosa deliberadament contra el mateix recurs. La parella demostra la frontera, mentre que una sola connexió correcta només demostra que alguna cosa està oberta. Confirma la ruta, l'origen efectiu i el port de servei previst, no la subxarxa que conté l'endpoint.

Ordre de feina: escriu el requisit de quatre parts, adjunta el grup a les associacions, limita la regla del recurs al port, verifica un permís i una denegació, i només després considera dividir subxarxes per motius d'encaminament.