Izbira dokazov HTTP: dnevniki prehoda ali dnevniki aplikacije

Spremljanje spleta se začne s ciljem, ne s točko zajema. Štetje aktivnih odjemalcev, merjenje klica API in branje teles sporočil zahtevajo vsako svoje dokaze in svoje odločitve o zasebnosti. Prehod, ki posreduje zaščiten HTTPS, vidi povezave in ne vsebine strani. Izbira napačnega sloja da podatke, ki so videti bogati in ne odgovorijo na nič.

Poimenujte vprašanje pred virom podatkov

Začnite z operativno odločitvijo, ki jo morajo podpreti podatki. Vprašanja o razpoložljivosti potrebujejo štetja in čase, vprašanja o zahtevah potrebujejo poti in statusne kode, vprašanja o vsebini pa telesa sporočil. Vsak korak navznoter doda občutljivost in inženirsko zapletenost. Pridobite od lastnika storitve in lastnika varnosti odobritev občinstva, namena in obravnave pred začetkom zbiranja, ker upravljanje predora ni ta odločitev.

Zapišite vprašanje v enem stavku in ga imejte ob načrtu zbiranja. To je edini zanesljiv nadzor obsega.

Kaj prehod lahko in česa ne more pokazati

Prehod, ki posreduje pravilno zaščiten HTTPS, običajno vidi naslove, vrata in obsege, ne vrstic zahtev ali teles.

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

Seznam conntrack prikazuje tokove in prevode, kratek zajem pa prikaže pakete brez berljive vsebine aplikacije. To zadostuje za odgovor, ali promet teče, koliko in med katerimi končnimi točkami. Ni seznam URL in običajen proxy CONNECT posreduje šifrirano izmenjavo brez dokončanja TLS aplikacije. Ko nekdo obljublja poti zahtev s tega položaja, vprašajte, katera komponenta dešifrira in pod čigavim zaupanjem.

Dnevniki aplikacije odgovorijo na večino vprašanj o zahtevah

Za aplikacijo, ki jo upravljate, njeno lastno podprto beleženje običajno odgovori na vprašanje na ravni zahteve brez dešifriranja povezav drugih.

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

Zahteva za stanje meri razpoložljivost s položaja odjemalca, dnevnik dostopa pa beleži polja, ki jih je strežnik že izbral za hrambo. Izberite polja, ki jih naloga potrebuje, in ostala pustite zunaj, ker je tudi URL lahko nosilec občutljivih parametrov. Vrstica dnevnika je dokaz o tej storitvi, ne o vsaki drugi storitvi, do katere je uporabnik prišel skozi predor. Ozko zbiranje ohranja majhno tudi vprašanje hrambe, zato nastavite okno krajše od miselnega poskusa, ki je zahtevo ustvaril.

Prestrezanje je ločen načrt zaupanja

Če je pregled na ravni sporočila res potreben, prestrezanje TLS ustvari novo zaupanja vredno končno točko in odjemalčevo ureditev zaupanja, ki jo je treba razširjati in vzdrževati. Aplikacije, ki pripenjajo potrdila, se bodo pokvarile, upravljavec pa zdaj hrani zasebne ključe, katerih zaščita šteje enako kot vsak strežniški ključ. Da zbiranje deluje s slabitvijo preverjanja potrdil ali s popravljanjem aplikacije, ki pripenja svoja potrdila, zamenja varnostni nadzor za vrstico dnevnika. Raje izberite dokumentiran načrt pregleda, katerega razširjanje zaupanja je že upravljano, in hranite zasebni ključ organa zunaj vsega deljenega.

Ob koncu okna zbiranja odstranite konfiguracijo in njeno gradivo zaupanja prek njihovih lastnikov ter zavrzite hranjene dokaze v skladu z dogovorjeno politiko. Dovolj zanesljivih informacij za navedeni namen je merilo uspeha, ne največji možni zajem.