Triar proves HTTP: registres de la passarel·la o registres de l’aplicació

El monitoratge web comença amb un propòsit, no amb un punt de captura. Comptar clients actius, mesurar una crida API i llegir cossos de missatges requereixen proves diferents i decisions de privadesa diferents. Una passarel·la que reenvia HTTPS protegit veu connexions, no contingut de pàgina. Triar la capa equivocada dona dades que semblen riques i no responen res.

Anomeneu la pregunta abans que la font de dades

Comenceu per la decisió operativa que les dades han de sostenir. Les preguntes de disponibilitat necessiten recomptes i temps, les preguntes de peticions necessiten camins i codis d’estat, i les preguntes de contingut necessiten cossos de missatges. Cada pas endins afegeix sensibilitat i complexitat d’enginyeria. Feu que el propietari del servei i el propietari de seguretat aprovin l’audiència, el propòsit i el tractament abans que comenci la recollida, perquè operar el túnel no és aquesta decisió.

Escriviu la pregunta en una frase i tingueu-la al costat del pla de recollida. És l’únic control fiable de l’abast.

Què pot mostrar la passarel·la i què no

Una passarel·la que reenvia HTTPS correctament protegit normalment veu adreces, ports i volums, no línies de petició ni cossos.

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

El llistat de conntrack mostra fluxos i traduccions, i la captura curta mostra paquets sense contingut d’aplicació llegible. Això n’hi ha prou per respondre si el trànsit flueix, quant i entre quins extrems. No és una llista d’URL, i un proxy CONNECT corrent reenvia l’intercanvi xifrat sense acabar el TLS de l’aplicació. Quan algú promet camins de petició des d’aquella posició, pregunteu quin component desxifra i sota la confiança de qui.

Els registres de l’aplicació responen la majoria de preguntes de petició

Per a una aplicació que opereu, el seu propi registre compatible normalment respon la pregunta a nivell de petició sense desxifrar les connexions dels altres.

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

La petició de salut mesura la disponibilitat des de la posició d’un client, i el registre d’accés anota els camps que el servidor ja va triar conservar. Trieu els camps que la tasca necessita i deixeu la resta fora, perquè fins i tot un URL pot portar paràmetres sensibles. Una línia de registre és prova sobre aquell servei, no sobre tots els altres serveis que l’usuari va assolir pel túnel. Mantenir la recollida estreta també manté petita la pregunta de retenció, així que fixeu una finestra més curta que l’experiment mental que va produir el requisit.

La intercepció és un disseny de confiança separat

Si la inspecció a nivell de missatge és realment necessària, la intercepció TLS crea un nou extrem de confiança i un acord de confiança de client que cal distribuir i mantenir. Les aplicacions que fixen certificats es trencaran, i l’operador ara té claus privades la protecció de les quals importa tant com qualsevol clau de servidor. Fer funcionar la recollida debilitant la validació de certificats, o pedaçant una aplicació que fixa els seus certificats, bescanvia un control de seguretat per una línia de registre. Preferiu un disseny d’inspecció documentat la distribució de confiança del qual ja es gestiona, i manteniu la clau privada de l’autoritat fora de tot el que es comparteixi.

Al final de la finestra de recollida, retireu la configuració i el seu material de confiança a través dels seus propietaris, i elimineu les proves retingudes segons la política acordada. Prou informació fiable per al propòsit declarat és el criteri d’èxit, no la captura més gran possible.