Vælg HTTP-bevis: gateway-logge eller applikationslogge
En VPN-gateway ser forbindelser, din applikation ser anmodninger, og en TLS-proxy ser indhold. Vælg den mindst indgribende kilde, der besvarer det driftsmæssige spørgsmål.
Webovervågning begynder med et formål, ikke med et opsamlingspunkt. At tælle aktive klienter, måle et API-kald og læse meddelelsesindhold kræver hver især forskellige beviser og forskellige privatlivsbeslutninger. En gateway, der videresender beskyttet HTTPS, ser forbindelser frem for sideindhold. At vælge det forkerte lag giver data, der ser rige ud og ikke besvarer noget.
Navngiv spørgsmålet før datakilden
Begynd med den driftsmæssige beslutning, som dataene skal understøtte. Tilgængelighedsspørgsmål kræver optællinger og tider, anmodningsspørgsmål kræver stier og statuskoder, og indholdsspørgsmål kræver meddelelsesindhold. Hvert skridt indad tilføjer følsomhed og teknisk kompleksitet. Få serviceejeren og sikkerhedsejeren til at godkende publikum, formål og håndtering, før indsamlingen begynder, fordi drift af tunnelen ikke er den beslutning.
Skriv spørgsmålet i én sætning, og hold det ved siden af indsamlingsplanen. Det er den eneste pålidelige omfangskontrol.
Hvad gatewayen kan og ikke kan vise
En gateway, der videresender korrekt beskyttet HTTPS, ser normalt adresser, porte og volumener, ikke anmodningslinjer eller indhold.
conntrack -L -d 203.0.113.10 | head
tcpdump -ni vpn0 -c 20 'tcp port 443'conntrack-listen viser strømme og oversættelser, og den korte optagelse viser pakker uden læsbart applikationsindhold. Det er nok til at besvare, om trafikken løber, hvor meget, og mellem hvilke endepunkter. Det er ikke en liste over URL’er, og en almindelig CONNECT-proxy videresender den krypterede udveksling uden at afslutte applikationens TLS. Når nogen lover anmodningsstier fra den position, så spørg, hvilken komponent der dekrypterer, og under hvis tillid.
Applikationslogge besvarer de fleste anmodningsspørgsmål
For en applikation, du driver, besvarer dens egen understøttede logning normalt spørgsmålet på anmodningsniveau uden at dekryptere andres forbindelser.
curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" https://app.example.com/health
tail -n 5 /var/log/nginx/access.logTilstandsanmodningen måler tilgængelighed fra en klients position, og adgangsloggen registrerer de felter, som serveren allerede har valgt at beholde. Vælg de felter, opgaven har brug for, og lad resten være ude, fordi selv en URL kan bære følsomme parametre. En loglinje er bevis om den tjeneste, ikke om enhver anden tjeneste, brugeren nåede gennem tunnelen. At holde indsamlingen smal holder også opbevaringsspørgsmålet lille, så sæt et vindue kortere end det tankeeksperiment, der skabte kravet.
Aflytning er et separat tillidsdesign
Hvis inspektion på meddelelsesniveau virkelig er nødvendig, skaber TLS-aflytning et nyt betroet endepunkt og en klienttillidsordning, som skal distribueres og vedligeholdes. Applikationer, der pinner certifikater, vil gå i stykker, og operatøren har nu private nøgler, hvis beskyttelse betyder lige så meget som enhver servernøgle. At få indsamlingen til at virke ved at svække certifikatvalideringen eller ved at patche en applikation, der pinner sine certifikater, bytter en sikkerhedskontrol for en loglinje. Foretræk et dokumenteret inspektionsdesign, hvis tillidsdistribution allerede er styret, og hold myndighedens private nøgle ude af alt delt.
Ved indsamlingsvinduets udgang fjerner du konfigurationen og dens tillidsmateriale gennem deres ejere og bortskaffer opbevarede beviser efter den aftalte politik. Tilstrækkelig pålidelig information til det angivne formål er succesmålet, ikke den størst mulige optagelse.