Alegerea probelor HTTP: jurnale de gateway sau jurnale de aplicație

Monitorizarea web începe cu un scop, nu cu un punct de captură. Numărarea clienților activi, cronometrarea unui apel API și citirea corpurilor mesajelor cer fiecare probe diferite și decizii de confidențialitate diferite. Un gateway care transmite HTTPS protejat vede conexiuni, nu conținutul paginii. Alegerea stratului greșit produce date care par bogate și nu răspund la nimic.

Numiți întrebarea înainte de sursa de date

Începeți cu decizia operațională pe care datele trebuie să o sprijine. Întrebările de disponibilitate au nevoie de numărători și timpi, întrebările de cereri au nevoie de căi și coduri de stare, iar întrebările de conținut au nevoie de corpuri de mesaje. Fiecare pas spre interior adaugă sensibilitate și complexitate inginerească. Cereți proprietarului serviciului și proprietarului de securitate să aprobe audiența, scopul și tratarea înainte de a începe colectarea, pentru că operarea tunelului nu este acea decizie.

Scrieți întrebarea într-o singură propoziție și țineți-o lângă planul de colectare. Este singurul control fiabil al scopului.

Ce poate și ce nu poate arăta gateway-ul

Un gateway care transmite HTTPS corect protejat vede de obicei adrese, porturi și volume, nu linii de cerere sau corpuri.

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

Lista conntrack arată fluxuri și traduceri, iar captura scurtă arată pachete fără conținut de aplicație lizibil. Este suficient pentru a răspunde dacă traficul curge, cât și între ce puncte finale. Nu este o listă de URL, iar un proxy CONNECT obișnuit transmite schimbul cifrat fără a termina TLS-ul aplicației. Când cineva promite căi de cerere din acea poziție, întrebați ce componentă descifrează și sub a cui încredere.

Jurnalele aplicației răspund la majoritatea întrebărilor de cerere

Pentru o aplicație pe care o operați, jurnalizarea sa suportată răspunde de obicei la întrebarea la nivel de cerere fără a descifra conexiunile altora.

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

Cererea de sănătate măsoară disponibilitatea din poziția unui client, iar jurnalul de acces notează câmpurile pe care serverul a ales deja să le păstreze. Alegeți câmpurile de care are nevoie sarcina și lăsați restul afară, pentru că chiar și un URL poate transporta parametri sensibili. O linie de jurnal este probă despre acel serviciu, nu despre orice alt serviciu la care utilizatorul a ajuns prin tunel. O colectare îngustă menține mică și întrebarea despre păstrare, deci stabiliți o fereastră mai scurtă decât experimentul mental care a produs cerința.

Interceptarea este un design de încredere separat

Dacă inspecția la nivel de mesaj este cu adevărat necesară, interceptarea TLS creează un nou punct final de încredere și o înțelegere de încredere a clientului care trebuie distribuită și întreținută. Aplicațiile care fixează certificate se vor rupe, iar operatorul ține acum chei private a căror protecție contează la fel ca orice cheie de server. A face colectarea să funcționeze slăbind validarea certificatelor, sau corectând o aplicație care își fixează certificatele, schimbă un control de securitate cu o linie de jurnal. Preferați un design de inspecție documentat a cărui distribuție a încrederii este deja gestionată, și țineți cheia privată a autorității în afara oricărui lucru partajat.

La sfârșitul ferestrei de colectare, eliminați configurația și materialul său de încredere prin proprietarii lor, și eliminați probele reținute conform politicii convenite. Informația fiabilă suficientă pentru scopul declarat este criteriul de succes, nu cea mai mare captură posibilă.