Escolher provas HTTP: registos da gateway ou registos da aplicação

A monitorização da web começa com um propósito, não com um ponto de captura. Contar clientes ativos, medir uma chamada API e ler corpos de mensagens exigem, cada um, provas diferentes e decisões de privacidade diferentes. Uma gateway que reencaminha HTTPS protegido vê ligações em vez de conteúdo de página. Escolher a camada errada produz dados que parecem ricos e não respondem a nada.

Nomeie a pergunta antes da fonte de dados

Comece pela decisão operacional que os dados devem sustentar. As perguntas de disponibilidade precisam de contagens e tempos, as perguntas de pedidos precisam de caminhos e códigos de estado, e as perguntas de conteúdo precisam de corpos de mensagens. Cada passo para dentro acrescenta sensibilidade e complexidade de engenharia. Faça com que o responsável pelo serviço e o responsável pela segurança aprovem audiência, propósito e tratamento antes de a recolha começar, porque operar o túnel não é essa decisão.

Escreva a pergunta numa frase e mantenha-a ao lado do plano de recolha. É o único controlo fiável do âmbito.

O que a gateway pode e não pode mostrar

Uma gateway que reencaminha HTTPS corretamente protegido vê normalmente endereços, portas e volumes, não linhas de pedido ou corpos.

conntrack -L -d 203.0.113.10 | head
tcpdump -ni vpn0 -c 20 'tcp port 443'

A lista conntrack mostra fluxos e traduções, e a captura curta mostra pacotes sem conteúdo de aplicação legível. Isso basta para responder se o tráfego flui, quanto e entre que extremos. Não é uma lista de URL, e um proxy CONNECT comum reencaminha a troca cifrada sem terminar o TLS da aplicação. Quando alguém promete caminhos de pedido a partir dessa posição, pergunte que componente desencripta e sob a confiança de quem.

Os registos da aplicação respondem à maioria das perguntas de pedido

Para uma aplicação que opera, o seu próprio registo suportado responde normalmente à pergunta ao nível do pedido sem desencriptar as ligações dos outros.

curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" https://app.example.com/health
tail -n 5 /var/log/nginx/access.log

O pedido de saúde mede a disponibilidade a partir da posição de um cliente, e o registo de acesso anota os campos que o servidor já escolheu guardar. Escolha os campos de que a tarefa precisa e deixe o resto de fora, porque até um URL pode transportar parâmetros sensíveis. Uma linha de registo é prova sobre esse serviço, não sobre todos os outros serviços que o utilizador alcançou pelo túnel. Manter a recolha estreita também mantém pequena a pergunta de retenção, por isso fixe uma janela mais curta do que a experiência mental que produziu o requisito.

A interceção é um desenho de confiança separado

Se a inspeção ao nível da mensagem for genuinamente necessária, a interceção TLS cria um novo ponto final de confiança e um acordo de confiança de cliente que tem de ser distribuído e mantido. As aplicações que fixam certificados vão partir-se, e o operador passa a deter chaves privadas cuja proteção importa tanto como qualquer chave de servidor. Fazer a recolha funcionar enfraquecendo a validação de certificados, ou corrigindo uma aplicação que fixa os seus certificados, troca um controlo de segurança por uma linha de registo. Prefira um desenho de inspeção documentado cuja distribuição de confiança já é gerida, e mantenha a chave privada da autoridade fora de tudo o que é partilhado.

No fim da janela de recolha, remova a configuração e o seu material de confiança através dos seus proprietários, e elimine as provas retidas segundo a política acordada. Informação fiável suficiente para o propósito declarado é o critério de sucesso, não a maior captura possível.