Escoller probas HTTP: rexistros da pasarela ou rexistros da aplicación

A supervisión web comeza cun propósito, non cun punto de captura. Contar clientes activos, medir unha chamada API e ler corpos de mensaxes esixen probas distintas e decisións de privacidade distintas. Unha pasarela que reenvía HTTPS protexido ve conexións en lugar de contido de páxina. Escoller a capa equivocada produce datos que parecen ricos e non responden nada.

Nomea a pregunta antes da fonte de datos

Comeza pola decisión operativa que os datos deben soster. As preguntas de dispoñibilidade precisan recontos e tempos, as preguntas de peticións precisan rutas e códigos de estado, e as preguntas de contido precisan corpos de mensaxes. Cada paso cara a dentro engade sensibilidade e complexidade de enxeñaría. Fai que o responsable do servizo e o responsable de seguridade aproben audiencia, propósito e tratamento antes de que comece a recollida, porque operar o túnel non é esa decisión.

Escribe a pregunta nunha frase e ténaa xunto ao plan de recollida. É o único control fiable do alcance.

Que pode mostrar a pasarela e que non

Unha pasarela que reenvía HTTPS correctamente protexido normalmente ve enderezos, portos e volumes, non liñas de petición nin corpos.

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

A lista de conntrack mostra fluxos e traducións, e a captura breve mostra paquetes sen contido de aplicación lexible. Iso abonda para responder se o tráfico flúe, canto e entre que extremos. Non é unha lista de URL, e un proxy CONNECT corrente reenvía o intercambio cifrado sen rematar o TLS da aplicación. Cando alguén promete rutas de petición desde esa posición, pregunta que compoñente descifra e baixo a confianza de quen.

Os rexistros da aplicación responden á maioría das preguntas de petición

Para unha aplicación que operas, o seu propio rexistro compatible normalmente responde á pregunta a nivel de petición sen descifrar as conexións doutros.

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

A petición de saúde mide a dispoñibilidade desde a posición dun cliente, e o rexistro de acceso anota os campos que o servidor xa escolleu conservar. Escolle os campos que a tarefa necesita e deixa fóra o resto, porque mesmo un URL pode levar parámetros sensibles. Unha liña de rexistro é proba sobre ese servizo, non sobre todos os demais servizos aos que o usuario chegou polo túnel. Manter a recollida estreita tamén mantén pequena a pregunta de retención, así que fixa unha ventá máis curta que o experimento mental que produciu o requisito.

A interceptación é un deseño de confianza á parte

Se a inspección a nivel de mensaxe é realmente necesaria, a interceptación TLS crea un novo extremo de confianza e un acordo de confianza de cliente que debe distribuírse e manterse. As aplicacións que fixan certificados romperán, e o operador agora garda claves privadas cuxa protección importa tanto coma calquera clave de servidor. Facer funcionar a recollida debilitando a validación de certificados, ou parcheando unha aplicación que fixa os seus certificados, cambia un control de seguridade por unha liña de rexistro. Prefire un deseño de inspección documentado cuxa distribución de confianza xa se xestiona, e mantén a clave privada da autoridade fóra de todo o compartido.

Ao final da ventá de recollida, retira a configuración e o seu material de confianza a través dos seus propietarios, e elimina as probas retidas segundo a política acordada. Suficiente información fiable para o propósito declarado é o criterio de éxito, non a captura máis grande posible.