A que pode ainda chegar um gateway web comprometido?

Suponha que o host do gateway seja comprometido enquanto o seu certificado ainda é válido. Todas as regras que determinavam que páginas um visitante pode pedir continuam em vigor, e nenhuma dessas regras limita a ligação que o atacante abre agora desse host em direção à sub-rede da base de dados. É esta lacuna que faz com que um ponto de entrada apenas web não seja a mesma afirmação que uma rede segmentada. As duas afirmações exigem revisões separadas, de pontos de partida diferentes, antes de qualquer delas poder ser feita com honestidade.

Duas afirmações, e apenas uma delas começa no visitante

A primeira afirmação diz respeito a uma pessoa: um visitante com navegador e sessão válida pode abrir uma aplicação e nada mais. Um ponto de entrada apenas web responde bem a essa afirmação, porque o visitante recebe uma página em vez de uma rota. Essa resposta vale a pena, e é também a única afirmação que a maioria dos diagramas registra.

A segunda afirmação diz respeito a um componente: assume-se que o gateway, ou o processo de aplicação por trás dele, está sob o controlo de outra pessoa. A partir dessa suposição, a pergunta passa de que URL são permitidos para que destinos e identidades o processo ainda pode chegar.

As duas afirmações têm proprietários diferentes, produzem provas diferentes e falham de forma independente. Uma equipa de identidade pode demonstrar a primeira com um teste de sessão; a segunda exige política de rede, revisão da conta de serviço e controlos do host. Um desenho que registe apenas a metade do visitante parece completo num diapositivo de revisão e fino durante um incidente, porque os controlos que importam após um compromisso nunca estiveram no âmbito. Nomeie que afirmação cada controlo suporta, ou uma regra de gateway será creditada às duas.

Um serviço de despesas trabalhado, e as duas formas como perde

Tomemos um serviço de despesas: um gateway público em 10.60.4.10 autentica o pessoal e reencaminha os pedidos aprovados para um listener da aplicação na porta 8443, e essa aplicação chega a um único listener PostgreSQL em 10.60.4.20:5432 como a função expenses_app. Os funcionários não devem receber acesso interno geral. Em funcionamento normal, o desenho fornece de facto uma entrada específica da aplicação sem publicar o listener da base de dados em lado nenhum. Os endereços importam, porque cada verificação posterior neste artigo os nomeia.

Agora retire o gateway do conjunto de confiança. A que destinos pode 10.60.4.10 chegar quando o seu processo pertence a um atacante? O filtro de URL que restringia os visitantes não diz nada sobre uma ligação que o host do gateway abre em direção à sub-rede da base de dados.

Retire antes o processo da aplicação, e a autoridade muda de forma: a função expenses_app, os serviços que esse servidor pode alcançar e os ficheiros que essa conta pode ler. Em ambos os casos a porta da frente pode ficar apenas web enquanto falta o limite do backend. Por isso, a etiqueta na porta da frente não é resposta a nenhuma das duas perguntas.

Mapeie a autoridade que cada parte detém realmente

Um contrato escrito como permissões previstas tende a repetir-lhe o desenho. Escreva-o como autoridade detida, a verificação que refuta o excesso e o proprietário dessa verificação, e cada linha torna-se testável. Esta tabela é uma proposta para o exemplo acima, não uma afirmação de produto:

A propriedade segue a autoridade. A equipa de identidade detém as asserções, a equipa da plataforma de rede detém as rotas, a equipa de aplicação detém a função da base de dados, o administrador da base de dados detém o listener e as suas regras baseadas no host, e o proprietário da plataforma detém o plano de gestão. Uma negação sem proprietário é uma frase num documento, não um controlo.

A divisão também evita a dupla contagem. Uma restrição de porta não pode expressar um privilégio de tabela, e uma função de base de dados não pode impedir um host de abrir um socket para uma sub-rede não relacionada.

Enumere a que pode o gateway chegar em vez de o afirmar

Uma afirmação de limite vale tanto quanto a enumeração por trás dela. No host do gateway, três comandos cobrem a seleção de rota, uma sonda ao 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

Leia a saída nessa ordem. A rota diz se 10.60.4.20 é sequer selecionado a partir desse host; a sonda diz se o listener responde; a lista de regras mostra se a política detém o pacote ou se nunca houve nada no seu caminho.

Repita a enumeração a partir do host da aplicação. A partir daí, o lado da base de dados é uma consulta executada como a função da aplicação:

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

Uma ligação bem-sucedida sob uma função que não pode ler outro esquema é um resultado diferente de uma ligação bem-sucedida sob uma função de proprietário. Apenas a segunda é uma descoberta.

Registe as negações e depois date a revisão

A aceitação é escrita como resultados e não como intenções: uma sessão de funcionário não pode chegar ao listener, o host do gateway não pode chegar a uma sub-rede não relacionada, e a função da aplicação não pode criar uma base de dados. Cada uma é uma verificação separada com um proprietário nomeado e uma data.

Mantenha a monitorização, a aplicação de patches e a recuperação acessíveis através do caminho de gestão concebido para elas. Um limite que também bloqueia o seu proprietário torna-se uma interrupção, e a primeira resposta habitual a essa interrupção é alargar novamente a regra. A orientação de perímetro da CISA pede que o acesso de entrada e de saída seja limitado a portas e protocolos justificados, incluindo o tráfego entre redes internas, que é a direção iniciada pelo backend que a maioria dos diagramas omite.

Date a revisão e nomeie o seu proprietário. Volte a executar a enumeração e a consulta de privilégios após qualquer alteração à imagem do gateway, à tabela de rotas ou à função da aplicação.