Dalle acceso aos usuarios de VPN a un servizo, non á subrede

Un contratista necesita unha aplicación web interna e nada máis, e a resposta fácil é darlle un túnel cara á subrede do servidor. Iso funciona ata o día en que a escanea. O deseño máis estreito require máis reflexión, porque a accesibilidade, o encamiñamento e o permiso da aplicación son tres controis separados que deben coincidir.

Escriba o requisito como un servizo, non como unha subrede

Comece polo host de destino, o protocolo e o porto, e despois engada o grupo de usuarios ou de dispositivos que debe chegar a el. Inclúa a zona DNS privada só se a aplicación resolve un nome, e inclúa un provedor de identidade só se o fluxo de inicio de sesión o necesita. Todo o demais é unha dependencia que aínda non xustificou.

Unha subrede é un detalle de implementación do equipo de rede, mentres que un servizo é o que pediu o negocio e a unidade que se pode revisar e retirar.

Se a lista de dependencias pasa de tres elementos, probablemente a aplicación necesita a súa propia conversación de deseño.

Encamiñe de forma estreita, pero aplique noutro lugar

Unha ruta ou un selector estreito dille ao túnel que paquetes debe transportar; non é unha política de autorización. O filtro da pasarela, a devasa do host de destino e o modelo de permisos da propia aplicación son onde se decide o acceso. Unha ruta que cobre unha soa dirección é un bo comezo, e non é o control que detén un usuario decidido. Ese illamento é o que lle permite cambiar o filtro sen redeseñar o túnel.

Ao revés, unha ruta ampla cun filtro estrito pode ser lexítima, pero só se todos os implicados saben cal das dúas fai a aplicación da norma.

Documente explicitamente o punto de aplicación, ou o seguinte cambio moverao por accidente.

Comprobe a orixe que o servizo ve realmente

O destino ve a dirección do grupo do cliente ou a dirección da pasarela, segundo se traduce. As regras da devasa do host e os rexistros deben coincidir coa orixe real. Se varios usuarios comparten unha orixe traducida, ningunha regra por usuario nese host pode distinguiros, e iso é unha restrición de deseño, non un erro.

Escolla a tradución deliberadamente: simplifica o encamiñamento e destrúe a identidade da orixe, o que importa para a auditoría e para as regras por usuario.

Anote cal das dúas escolleu, xunto á regra que depende dela.

A autorización da aplicación non é opcional

Chegar a un porto non outorga un rol. A aplicación segue necesitando o seu propio inicio de sesión e os seus propios permisos, porque a capa de rede non pode expresar que rexistros pode editar un usuario. Un servizo que confía en calquera petición da subrede interna converte un túnel estreito en acceso completo para unha credencial comprometida. O túnel decide quen pode abrir o socket, e a aplicación decide que pode facer con el.

Aquí é onde o deseño estreito compensa dúas veces, porque menos hosts accesibles significa menos lugares onde se pode explotar un erro a nivel de aplicación.

Manteña a regra de rede e o rol da aplicación en sistemas separados, e retíreos por separado.

Demostre tanto a ruta permitida como a denegada

Conéctese como o usuario autorizado e realice unha operación representativa inofensiva, e despois probe un destino que debería ser inalcanzable. Un deseño que só proba a primeira metade non está probado, e a proba denegada é a que demostra o deseño. Probe unha sesión nova despois de cada cambio de regra, e mire a ruta de retorno se chegan peticións pero non respostas.

Non desactive os filtros de reenvío para que pase a proba de aceptación, porque iso cambia a cousa que se está probando.

Cando o usuario xa non necesite o servizo, retire a identidade remota e o rol da aplicación nos seus sistemas respectivos, e rexistre ambos. A guía de reenvío de strongSwan cobre o lado da pasarela da ruta.