Kies HTTP-bewyse: gateway-rekords of programlogboeke

Webmonitering begin met ’n doel, nie met ’n opvangpunt nie. Om aktiewe kliënte te tel, ’n API-oproep te tydsbereken en boodskapinhoud te lees, vereis elkeen ander bewyse en ander privaatheidsbesluite. ’n Gateway wat beskermde HTTPS aanstuur, sien verbindings eerder as bladsyinhoud. As jy die verkeerde laag kies, kry jy data wat ryk lyk en niks beantwoord nie.

Name die vraag voor die databron

Begin met die operasionele besluit wat die data moet ondersteun. Beskikbaarheidsvrae het tellings en tydsberekenings nodig, versoekvrae het paaie en statuskodes nodig, en inhoudsvrae het boodskapinhoud nodig. Elke stap na binne voeg sensitiwiteit en ingenieurskompleksiteit by. Kry die diens-eienaar en die sekuriteits-eienaar om oudienste, doel en hantering goed te keur voordat die versameling begin, want om die tonnel te bedryf is nie daardie besluit nie.

Skryf die vraag in een sin en hou dit langs die versamelplan. Dit is die enigste betroubare beheer van die omvang.

Wat die gateway wel en nie kan wys nie

’n Gateway wat korrek beskermde HTTPS aanstuur, sien gewoonlik adresse, poorte en volumes, nie versoekreëls of inhoud nie.

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

Die conntrack-lys wys strome en vertalings, en die kort opname wys pakkette sonder leesbare toepassingsinhoud. Dit is genoeg om te antwoord of verkeer vloei, hoeveel, en tussen watter eindpunte. Dit is nie ’n lys van URL’s nie, en ’n gewone CONNECT-proxy stuur die geënkripteerde uitruiling aan sonder om toepassing-TLS te beëindig. Wanneer iemand versoekpaaie vanuit daardie posisie belowe, vra watter komponent ontsyfer en onder wie se vertroue.

Programlogboeke beantwoord die meeste versoekvrae

Vir ’n program wat jy bedryf, beantwoord sy eie ondersteunde logboeke gewoonlik die vraag op versoekvlak sonder om ander se verbindings te ontsyfer.

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

Die gesondheidsversoek meet beskikbaarheid vanuit ’n kliënt se posisie, en die toegangslogboek teken die velde aan wat die bediener reeds gekies het om te hou. Kies die velde wat die taak nodig het en laat die res uit, want selfs ’n URL kan sensitiewe parameters dra. ’n Logreël is bewys oor daardie diens, nie oor elke ander diens wat die gebruiker deur die tonnel bereik het nie. Om die versameling smal te hou, hou ook die bewaringsvraag klein, so stel ’n tydvenster korter as die gedagte-eksperiment wat die vereiste opgelewer het.

Onderskepping is ’n aparte vertrouensontwerp

As boodskapvlak-ondersoek werklik nodig is, skep TLS-onderskepping ’n nuwe vertroude eindpunt en ’n kliëntevertrouensreëling wat versprei en instandgehou moet word. Programme wat sertifikate vaspen, sal breek, en die operateur hou nou privaat sleutels waarvan die beskerming net so belangrik soos enige bediener-sleutel is. Om die versameling te laat werk deur sertifikaatvalidasie te verswak, of deur ’n program wat sy sertifikate vaspen aan te pas, verruil ’n sekuriteitsbeheer vir ’n logreël. Verkies ’n gedokumenteerde ondersoekontwerp wie se vertrouensverspreiding reeds bestuur word, en hou die owerheid se privaat sleutel uit alles wat gedeel word.

Aan die einde van die versamelingstydperk, verwyder die konfigurasie en sy vertrouensmateriaal deur hul eienaars, en gooi bewaarde bewyse weg volgens die ooreengekome beleid. Genoeg betroubare inligting vir die genoemde doel is die sukseskriterium, nie die grootste moontlike opname nie.