Velge HTTP-bevis: gateway-logger eller applikasjonslogger
En VPN-gateway ser tilkoblinger, appen din ser forespørsler, og en TLS-proxy ser innhold. Velg den minst inngripende kilden som svarer på drifts-spørsmålet.
Overvåking av nettet starter med et formål, ikke med et opptakspunkt. Å telle aktive klienter, måle et API-kall og lese meldingskropper krever hver for seg ulike bevis og ulike personvernsvalg. En gateway som videresender beskyttet HTTPS, ser tilkoblinger i stedet for sideinnhold. Å velge feil lag gir data som ser rike ut og ikke svarer på noe.
Navngi spørsmålet før datakilden
Begynn med driftsbeslutningen som dataene skal støtte. Tilgjengelighetsspørsmål trenger tellinger og tider, forespørselsspørsmål trenger stier og statuskoder, og innholdsspørsmål trenger meldingskropper. Hvert steg innover legger til følsomhet og teknisk kompleksitet. Få tjenesteeieren og sikkerhetseieren til å godkjenne publikum, formål og håndtering før innsamlingen begynner, fordi å drifte tunnelen ikke er den beslutningen.
Skriv spørsmålet i én setning og hold det ved siden av innsamlingsplanen. Det er den eneste pålitelige omfangskontrollen.
Hva gatewayen kan og ikke kan vise
En gateway som videresender korrekt beskyttet HTTPS, ser vanligvis adresser, porter og volumer, ikke forespørselslinjer eller innhold.
conntrack -L -d 203.0.113.10 | head
tcpdump -ni vpn0 -c 20 'tcp port 443'conntrack-listen viser strømmer og oversettelser, og den korte opptaket viser pakker uten lesbart applikasjonsinnhold. Det er nok til å svare på om trafikken flyter, hvor mye, og mellom hvilke endepunkter. Det er ikke en liste over URL-er, og en vanlig CONNECT-proxy videresender den krypterte utvekslingen uten å avslutte applikasjonens TLS. Når noen lover forespørselsstier fra den posisjonen, spør hvilken komponent som dekrypterer og under hvis tillit.
Applikasjonslogger svarer på de fleste forespørselsspørsmål
For en applikasjon du driver, svarer dens egen støttede logging vanligvis på spørsmålet på forespørselsnivå uten å dekryptere andres tilkoblinger.
curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" https://app.example.com/health
tail -n 5 /var/log/nginx/access.logHelsesjekken måler tilgjengelighet fra en klients posisjon, og tilgangsloggen registrerer feltene serveren allerede valgte å beholde. Velg feltene oppgaven trenger og la resten være ute, fordi selv en URL kan bære sensitive parametere. En logglinje er bevis om den tjenesten, ikke om hver annen tjeneste brukeren nådde gjennom tunnelen. Smal innsamling holder også oppbevaringsspørsmålet lite, så sett et vindu kortere enn tankeeksperimentet som skapte kravet.
Avlytting er et eget tillitsdesign
Hvis inspeksjon på meldingsnivå virkelig er nødvendig, skaper TLS-avlytting et nytt betrodd endepunkt og en klienttillitsordning som må distribueres og vedlikeholdes. Applikasjoner som fester sertifikater vil knekke, og operatøren holder nå private nøkler hvis beskyttelse betyr like mye som enhver servernøkkel. Å få innsamlingen til å virke ved å svekke sertifikatvalideringen, eller ved å lappe en applikasjon som fester sertifikatene sine, bytter en sikkerhetskontroll mot en logglinje. Foretrekk et dokumentert inspeksjonsdesign hvis tillitsfordeling allerede er styrt, og hold myndighetens private nøkkel utenfor alt som deles.
Ved slutten av innsamlingsvinduet fjerner du konfigurasjonen og tillitsmaterialet gjennom deres eiere, og kasserer lagrede bevis etter den avtalte policyen. Nok pålitelig informasjon for det angitte formålet er suksesskriteriet, ikke den størst mulige opptaket.