HTTP-bewijs kiezen: gateway-logboeken of applicatielogs
Een VPN-gateway ziet verbindingen, je applicatie ziet verzoeken en een TLS-proxy ziet bodies. Kies de minst indringende bron die de operationele vraag beantwoordt.
Webmonitoring begint met een doel, niet met een opnamepunt. Actieve clients tellen, een API-aanroep timen en berichtinhoud lezen vereisen elk ander bewijs en andere privacybeslissingen. Een gateway die beveiligd HTTPS doorstuurt, ziet verbindingen en geen paginainhoud. De verkeerde laag kiezen levert gegevens op die rijk lijken en niets beantwoorden.
Noem de vraag voor de gegevensbron
Begin met de operationele beslissing die de gegevens moeten ondersteunen. Beschikbaarheidsvragen hebben tellingen en tijden nodig, verzoekvragen hebben paden en statuscodes nodig, en inhoudsvragen hebben berichtinhoud nodig. Elke stap naar binnen voegt gevoeligheid en technische complexiteit toe. Laat de diensteigenaar en de beveiligingseigenaar publiek, doel en behandeling goedkeuren voordat de verzameling begint, want de tunnel bedienen is niet die beslissing.
Schrijf de vraag in één zin en houd ze naast het verzamelplan. Het is de enige betrouwbare omvangscontrole.
Wat de gateway kan en niet kan tonen
Een gateway die correct beveiligd HTTPS doorstuurt, ziet normaal adressen, poorten en volumes, geen verzoekregels of bodies.
conntrack -L -d 203.0.113.10 | head
tcpdump -ni vpn0 -c 20 'tcp port 443'De conntrack-lijst toont stromen en vertalingen, en de korte opname toont pakketten zonder leesbare applicatie-inhoud. Dat is genoeg om te beantwoorden of verkeer stroomt, hoeveel en tussen welke eindpunten. Het is geen lijst van URL's, en een gewone CONNECT-proxy stuurt de versleutelde uitwisseling door zonder de TLS van de applicatie te beëindigen. Als iemand vanuit die positie verzoekpaden belooft, vraag dan welk component ontsleutelt en onder wiens vertrouwen.
Applicatielogs beantwoorden de meeste verzoekvragen
Voor een applicatie die je beheert, beantwoordt de eigen ondersteunde logging meestal de vraag op verzoekniveau zonder de verbindingen van anderen te ontsleutelen.
curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" https://app.example.com/health
tail -n 5 /var/log/nginx/access.logDe statusaanvraag meet beschikbaarheid vanuit de positie van een client, en het toegangslog legt de velden vast die de server al had gekozen te bewaren. Kies de velden die de taak nodig heeft en laat de rest weg, want zelfs een URL kan gevoelige parameters dragen. Een logregel is bewijs over die dienst, niet over elke andere dienst die de gebruiker via de tunnel bereikte. Verzameling smal houden houdt ook de bewaarvraag klein, dus stel een venster in korter dan het gedachte-experiment dat de eis opleverde.
Onderscheppen is een apart vertrouwensontwerp
Als inspectie op berichtniveau werkelijk nodig is, maakt TLS-onderschepping een nieuw vertrouwd eindpunt en een clientvertrouwensafspraak die gedistribueerd en onderhouden moet worden. Applicaties die certificaten vastpinnen, breken, en de operator houdt nu privésleutels waarvan de bescherming even belangrijk is als elke serversleutel. Verzameling laten werken door certificaatvalidatie te verzwakken, of door een applicatie te patchen die haar certificaten vastpint, wisselt een beveiligingscontrole in voor een logregel. Voorkom een gedocumenteerd inspectieontwerp waarvan de vertrouwensdistributie al wordt beheerd, en houd de privésleutel van de autoriteit buiten alles wat gedeeld wordt.
Aan het einde van het verzamelvenster verwijder je de configuratie en haar vertrouwensmateriaal via hun eigenaars, en verwijder je opgeslagen bewijs volgens de afgesproken policy. Genoeg betrouwbare informatie voor het genoemde doel is het succescriterium, niet de grootst mogelijke opname.