HTTP-bizonyítékok választása: átjárónaplók vagy alkalmazásnaplók

A webfigyelés céllal kezdődik, nem rögzítési ponttal. Az aktív kliensek számlálása, egy API-hívás időzítése és üzenettörzsek olvasása mind más-más bizonyítékot és más-más adatvédelmi döntést igényel. Az átjáró, amely védett HTTPS-t továbbít, kapcsolatokat lát, nem oldaltartalmat. A rossz réteg választása olyan adatot ad, amely gazdagnak látszik, és semmire nem válaszol.

Nevezd meg a kérdést az adatforrás előtt

Kezdd azzal az üzemeltetési döntéssel, amelyet az adatoknak támogatniuk kell. A rendelkezésre állási kérdések számokat és időket igényelnek, a kéréskérdések útvonalakat és állapotkódokat, a tartalomkérdések pedig üzenettörzseket. Minden befelé tett lépés érzékenységet és mérnöki bonyolultságot ad hozzá. A szolgáltatás tulajdonosa és a biztonsági tulajdonos hagyja jóvá a közönséget, a célt és a kezelést a gyűjtés megkezdése előtt, mert az alagút üzemeltetése nem ez a döntés.

Írd le a kérdést egy mondatban, és tartsd a gyűjtési terv mellett. Ez az egyetlen megbízható hatókör-ellenőrzés.

Mit mutathat az átjáró, és mit nem

Az átjáró, amely helyesen védett HTTPS-t továbbít, általában címeket, portokat és mennyiségeket lát, nem kérésorokat vagy törzseket.

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

A conntrack lista folyamokat és fordításokat mutat, a rövid rögzítés pedig csomagokat olvasható alkalmazástartalom nélkül. Ez elég annak megválaszolására, folyik-e a forgalom, mennyi, és mely végpontok között. Ez nem URL-lista, és egy közönséges CONNECT-proxy továbbítja a titkosított cserét anélkül, hogy lezárná az alkalmazás TLS-ét. Amikor valaki kérésútvonalakat ígér erről a pozícióból, kérdezd meg, melyik komponens fejt vissza, és kinek a bizalmában.

Az alkalmazásnaplók válaszolják meg a legtöbb kéréskérdést

Egy általad üzemeltetett alkalmazás esetében a saját támogatott naplózása általában megválaszolja a kérés szintű kérdést anélkül, hogy mások kapcsolatait visszafejtené.

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

Az állapotkérés egy kliens pozíciójából méri a rendelkezésre állást, és a hozzáférési napló rögzíti azokat a mezőket, amelyeket a kiszolgáló már megtartani választott. Válaszd ki a feladat számára szükséges mezőket, a többit hagyd ki, mert még egy URL is hordozhat érzékeny paramétereket. Egy naplósor erről a szolgáltatásról szóló bizonyíték, nem minden más szolgáltatásról, amelyet a felhasználó az alagúton át elért. A szűk gyűjtés a megtartási kérdést is kicsiben tartja, ezért állíts olyan ablakot, amely rövidebb, mint a követelményt létrehozó gondolatkísérlet.

Az elfogás külön bizalmi tervezés

Ha az üzenetszintű vizsgálat valóban szükséges, a TLS-elfogás új megbízható végpontot és ügyfél-bizalmi megállapodást hoz létre, amelyet terjeszteni és karbantartani kell. A tanúsítványokat rögzítő alkalmazások eltörnek, és az üzemeltető most olyan privát kulcsokat tart, amelyek védelme annyit számít, mint bármely szerverkulcs. A gyűjtést a tanúsítvány-ellenőrzés gyengítésével vagy a tanúsítványait rögzítő alkalmazás javításával működtetni biztonsági kontrollt cserél egy naplósorra. Előnyben részesíts dokumentált vizsgálati tervet, amelynek bizalomterjesztése már kezelt, és tartsd a hatóság privát kulcsát minden megosztott dologtól távol.

A gyűjtési ablak végén távolítsd el a konfigurációt és annak bizalmi anyagát tulajdonosaikon keresztül, és a megállapodott szabályzat szerint semmisítsd meg a megtartott bizonyítékokat. Az állított célhoz elegendő megbízható információ a siker kritériuma, nem a lehető legnagyobb rögzítés.