O tránsito cifrado non concede acceso ao operador

Dúas pasarelas aprobadas transportan o tráfico dunha rede de menor confianza a través dunha rede de transporte restrinxida. Cifrar a carga útil mantena ilexible para os observadores ordinarios do tránsito, e esa é a parte que a xente deseña primeiro e despois deixa de pensar. O que o cifrado non fai é definir que recursos pode alcanzar o lado de menor confianza. O deseño necesita dúas fronteiras: unha arredor da conversa transportada e outra arredor do acceso ao propio operador.

Execute os pasos seguintes en orde e trate calquera fallo en calquera paso como un cambio de deseño, non como un axuste de configuración.

Defina ambas as fronteiras antes de tocar unha configuración

A primeira fronteira é a conversa: que pares de pasarelas poden establecer un túnel e que tráfico interno se permite a través del. A segunda é o operador: que enderezos e servizos poden alcanzar os hosts de menor confianza fóra do túnel. Os equipos adoitan construír a primeira e herdar a segunda de calquera encamiñamento que xa existise, e así un deseño restrinxido convértese en silencio nun amplo. Esa herdanza é a causa raíz habitual cando unha revisión atopa un host de menor confianza falando con algo que ninguén aprobou.

Escriba ambas como listas de enderezos, portos e sentidos. Se unha lista non se pode escribir, a fronteira aínda non está definida.

Paso 1: restrinxa o túnel exterior

Na interface orientada ao operador, permita só o que o túnel necesita: IKE en UDP 500 e 4500 entre os dous enderezos de pasarela, e ESP onde non se use atravesamento NAT. Denegue todo o demais que chegue a esa interface, incluídos os protocolos de xestión. A especificación ESP cobre os servizos de protección; non di nada sobre que servizos propios do operador poden usar as pasarelas. Exprese isto como unha lista de permisos explícita, para que un servizo do operador publicado recentemente non se volva accesible por defecto.

Ese é o conxunto de regras que fai que o deseño sexa un deseño de tránsito e non un acordo de emparellamento.

Compróbeo desde o lado de menor confianza, non desde a consola da pasarela. Un host de alí debería fallar ao alcanzar un servidor DNS do operador mesmo antes de que o túnel estea levantado.

Paso 2: decida que entrega a pasarela remota

No extremo remoto, o tráfico recuperado ten que ir a algún lugar concreto. Defina que servizos internos se permiten, desde que rangos de orixe e se se espera que as respostas sexan simétricas. Revise o acceso de xestión por separado, porque a mesma pasarela adoita expor unha interface administrativa que nunca formou parte do plan de tránsito.

Un diagrama que se detén no descifrado correcto omitiu a decisión que máis importa.

Paso 3: manteña a propiedade por capa

O equipo de tránsito segue recibindo e reenviando paquetes exteriores, así que necesita parches e planificación de capacidade. Os extremos do túnel procesan o protocolo protexido e expoñen o tráfico interno á súa ruta de reenvío, así que necesitan as súas propias regras e a súa propia supervisión. As aplicacións finais procesan a carga útil, e unha carga opaca non é proba de que unha descarga descifrada sexa inofensiva.

Asigne un propietario a cada capa. As capas sen propietario son as que se desvían.

Paso 4: verifique e despois entrégueo á autoridade

Verifique a ruta exterior co túnel levantado e as regras do operador no seu sitio. Despois probe cada recurso ao que o lado de menor confianza non debería chegar e confirme que o fallo é unha denegación e non un tempo de espera que oculta unha ruta. Comprobe tamén a dispoñibilidade e os límites de recursos, porque unha ligazón cifrada tamén se pode saturar.

Para contornos regulados ou clasificados, leve o deseño á autoridade de seguridade responsable e use a súa arquitectura de separación aprobada. Unha configuración de VPN e unha explicación conceptual non establecen acreditación. Ese paso non é papeleo; decide se se permite que o deseño exista.