A que pode chegar aínda unha pasarela web comprometida?

Supoñamos que o host da pasarela está comprometido mentres o seu certificado segue sendo válido. Todas as regras que rexían que páxinas pode solicitar un visitante seguen vixentes, e ningunha desas regras limita a conexión que o atacante abre agora desde ese host cara á subrede da base de datos. Esa fenda é a razón pola que un punto de entrada só web non é a mesma afirmación que unha rede segmentada. As dúas afirmacións necesitan revisións separadas, desde puntos de partida distintos, antes de que calquera delas poida facerse con honestidade.

Dúas afirmacións, e só unha delas comeza no visitante

A primeira afirmación trata dunha persoa: un visitante cun navegador e unha sesión válida pode abrir unha aplicación e nada máis. Un punto de entrada só web responde ben a esa afirmación, porque o visitante recibe unha páxina en lugar dunha ruta. Esa resposta paga a pena, e tamén é a única afirmación que rexistran a maioría dos diagramas.

A segunda afirmación trata dun compoñente: sospéitase que a pasarela, ou o proceso de aplicación que hai detrás, está baixo o control doutra persoa. A partir dese suposto, a pregunta cambia de que URL se permiten a que destinos e identidades pode chegar aínda o proceso.

As dúas afirmacións teñen propietarios distintos, producen probas distintas e fallan de forma independente. Un equipo de identidade pode demostrar a primeira cunha proba de sesión; a segunda necesita política de rede, revisión da conta de servizo e controis do host. Un deseño que só rexistra a metade do visitante parece completo nunha diapositiva de revisión e escaso durante un incidente, porque os controis que importan despois dun compromiso nunca estiveron no alcance. Nomee que afirmación apoia cada control, ou unha regra de pasarela atribuirase ás dúas.

Un servizo de gastos desenvolvido, e as dúas formas en que perde

Tomemos un servizo de gastos: unha pasarela pública en 10.60.4.10 autentica o persoal e reenvía as solicitudes aprobadas a un receptor de aplicación no porto 8443, e esa aplicación chega a un único receptor PostgreSQL en 10.60.4.20:5432 como o rol expenses_app. Non se pretende que os empregados reciban acceso interno xeral. En funcionamento normal, o deseño si entrega unha entrada específica da aplicación sen publicar o receptor da base de datos en ningures. Os enderezos importan, porque cada comprobación posterior neste artigo os nomea.

Agora quite a pasarela do conxunto de confianza. A que destinos pode chegar 10.60.4.10 unha vez que o seu proceso pertence a un atacante? O filtro de URL que restrinxía os visitantes non di nada sobre unha conexión que o host da pasarela abre cara á subrede da base de datos.

Quite en cambio o proceso de aplicación, e a autoridade cambia de forma: o rol expenses_app, os servizos que ese servidor pode alcanzar e os ficheiros que esa conta pode ler. En ambos os casos a porta de entrada pode seguir sendo só web mentres falta o límite do backend. Por tanto, a etiqueta da porta de entrada non é resposta a ningunha das dúas preguntas.

Mapee a autoridade que cada parte posúe realmente

Un contrato escrito como permisos previstos tende a repetirlle o deseño. Escríbao como autoridade posuída, a comprobación que refuta o exceso e o propietario desa comprobación, e cada fila vólvese comprobable. Esta táboa é unha proposta para o exemplo anterior, non unha afirmación de produto:

A propiedade segue a autoridade. O equipo de identidade posúe as asercións, o equipo de plataforma de rede posúe as rutas, o equipo de aplicación posúe o rol de base de datos, o administrador de base de datos posúe o receptor e as súas regras baseadas en host, e o propietario da plataforma posúe o plano de xestión. Unha denegación sen propietario é unha frase nun documento, non un control.

A división tamén evita o dobre cómputo. Unha restrición de porto non pode expresar un privilexio de táboa, e un rol de base de datos non pode impedir que un host abra un socket cara a unha subrede non relacionada.

Enumere a que pode chegar a pasarela en lugar de afirmalo

Unha afirmación de límite vale tanto como a enumeración que a sostén. No host da pasarela, tres ordes cobren a selección de ruta, unha sonda en vivo e a política de saída:

ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter output

Lea a saída nesa orde. A ruta di se 10.60.4.20 se selecciona sequera desde ese host; a sonda di se o receptor responde; a listaxe de regras mostra se a política detén o paquete ou se nunca houbo nada no seu camiño.

Repita a enumeración desde o host da aplicación. Desde alí, o lado da base de datos é unha consulta executada como o rol da aplicación:

psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'

Unha conexión correcta baixo un rol que non pode ler outro esquema é un resultado distinto dunha conexión correcta baixo un rol propietario. Só a segunda é un achado.

Rexiste as denegacións e despois data a revisión

A aceptación escríbese como resultados e non como intencións: unha sesión de empregado non pode chegar ao receptor, o host da pasarela non pode chegar a unha subrede non relacionada e o rol da aplicación non pode crear unha base de datos. Cada unha é unha comprobación separada cun propietario nomeado e unha data.

Manteña a monitorización, o parcheo e a recuperación accesibles pola ruta de xestión deseñada para eles. Un límite que tamén bloquea o seu propietario convértese nunha interrupción, e a primeira resposta habitual a esa interrupción é volver ampliar a regra. A guía de perímetro da CISA pide limitar o acceso entrante e saínte a portos e protocolos xustificados, incluído o tráfico entre redes internas, que é a dirección iniciada polo backend que a maioría dos diagramas omite.

Data a revisión e nomee o seu propietario. Volva executar a enumeración e a consulta de privilexios tras calquera cambio na imaxe da pasarela, na táboa de rutas ou no rol da aplicación.