Välja HTTP-bevis: gateway-loggar eller applikationsloggar

Webbövervakning börjar med ett syfte, inte med en upptagningspunkt. Att räkna aktiva klienter, mäta ett API-anrop och läsa meddelandekroppar kräver var och en olika bevis och olika integritetsbeslut. En gateway som vidarebefordrar skyddad HTTPS ser anslutningar i stället för sidinnehåll. Att välja fel lager ger data som ser rika ut och inte svarar på något.

Namnge frågan före datakällan

Börja med det driftsbeslut som data ska stödja. Tillgänglighetsfrågor behöver räkningar och tider, förfrågningsfrågor behöver sökvägar och statuskoder, och innehållsfrågor behöver meddelandekroppar. Varje steg inåt lägger till känslighet och teknisk komplexitet. Låt tjänsteägaren och säkerhetsägaren godkänna publik, syfte och hantering innan insamlingen börjar, eftersom att driva tunneln inte är det beslutet.

Skriv frågan i en mening och håll den vid sidan av insamlingsplanen. Det är den enda tillförlitliga omfattningskontrollen.

Vad gatewayen kan och inte kan visa

En gateway som vidarebefordrar korrekt skyddad HTTPS ser vanligtvis adresser, portar och volymer, inte förfrågningsrader eller innehåll.

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

conntrack-listan visar flöden och översättningar, och den korta upptagningen visar paket utan läsbart applikationsinnehåll. Det räcker för att svara om trafiken flyter, hur mycket och mellan vilka ändpunkter. Det är inte en lista över URL:er, och en vanlig CONNECT-proxy vidarebefordrar det krypterade utbytet utan att avsluta applikationens TLS. När någon lovar förfrågningsvägar från den positionen, fråga vilken komponent som dekrypterar och under vems förtroende.

Applikationsloggar svarar på de flesta förfrågningsfrågor

För en applikation du driver svarar dess egen stödda loggning vanligtvis på frågan på förfrågningsnivå utan att dekryptera andras anslutningar.

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

Hälsokontrollen mäter tillgänglighet från en klients position, och åtkomstloggen registrerar de fält som servern redan valt att behålla. Välj de fält som uppgiften behöver och lämna resten utanför, eftersom även en URL kan bära känsliga parametrar. En loggrada är bevis om den tjänsten, inte om varje annan tjänst som användaren nådde genom tunneln. Smal insamling håller också bevarandefrågan liten, så sätt ett fönster kortare än det tankeexperiment som skapade kravet.

Avlyssning är en separat förtroendedesign

Om inspektion på meddelandenivå verkligen behövs skapar TLS-avlyssning en ny betrodd ändpunkt och en klientförtroendeordning som måste distribueras och underhållas. Applikationer som fäster certifikat kommer att brytas, och operatören håller nu privata nycklar vars skydd betyder lika mycket som vilken servernyckel som helst. Att få insamlingen att fungera genom att svaga certifikatvalideringen, eller genom att lappa en applikation som fäster sina certifikat, byter en säkerhetskontroll mot en loggrada. Föredra en dokumenterad inspektionsdesign vars förtroendefördelning redan hanteras, och håll myndighetens privata nyckel utanför allt som delas.

I slutet av insamlingsfönstret borttar du konfigurationen och dess förtroendematerial genom deras ägare, och kasserar bevarade bevis enligt den avtalade policyn. Tillräckligt tillförlitlig information för det angivna syftet är framgångskriteriet, inte den största möjliga upptagningen.