HTTP pierādījumu izvēle: vārtejas ieraksti vai lietotnes žurnāli
VPN vārteja redz savienojumus, jūsu lietotne redz pieprasījumus, un TLS starpniekservers redz saturu. Izvēlieties vismazāk uzmācīgo avotu, kas atbild uz operatīvo jautājumu.
Tīmekļa uzraudzība sākas ar mērķi, nevis ar uztveršanas punktu. Aktīvo klientu skaitīšana, API izsaukuma laika mērīšana un ziņojumu satura lasīšana katram prasa citus pierādījumus un citus privātuma lēmumus. Vārteja, kas pārsūta aizsargātu HTTPS, redz savienojumus, nevis lapas saturu. Nepareizas slānis izvēle dod datus, kas izskatās bagātīgi un neatbild uz neko.
Nosauc jautājumu pirms datu avota
Sāciet ar operatīvo lēmumu, kuru datiem jāatbalsta. Pieejamības jautājumiem vajag skaitījumus un laikus, pieprasījumu jautājumiem vajag ceļus un statusa kodus, un satura jautājumiem vajag ziņojumu saturu. Katrs solis uz iekšu pievieno jutīgumu un inženiertehnisko sarežģītību. Lūdziet pakalpojuma īpašniekam un drošības īpašniekam apstiprināt auditoriju, mērķi un apstrādi pirms vākšanas sākuma, jo tuneļa pārvaldīšana nav tas lēmums.
Uzrakstiet jautājumu vienā teikumā un turiet to blakus vākšanas plānam. Tas ir vienīgā uzticamā apjoma kontrole.
Ko vārteja var un ko nevar parādīt
Vārteja, kas pārsūta pareizi aizsargātu HTTPS, parasti redz adreses, portus un apjomus, nevis pieprasījuma rindas vai saturu.
conntrack -L -d 203.0.113.10 | head
tcpdump -ni vpn0 -c 20 'tcp port 443'conntrack saraksts rāda plūsmas un tulkojumus, un īsā uztveršana rāda paketes bez lasāma lietotnes satura. Ar to pietiek, lai atbildētu, vai trafiks plūst, cik daudz un starp kuriem galapunktiem. Tas nav URL saraksts, un parasts CONNECT starpniekservers pārsūta šifrētu apmaiņu, neizbeidzot lietotnes TLS. Kad kāds sola pieprasījuma ceļus no šīs pozīcijas, jautājiet, kurš komponents atšifrē un kura uzticības ietvaros.
Lietotnes žurnāli atbild uz vairumu pieprasījumu jautājumu
Lietotnei, kuru pārvaldāt, tās pašas atbalstītā reģistrēšana parasti atbild uz pieprasījuma līmeņa jautājumu, neatšifrējot citu savienojumus.
curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" https://app.example.com/health
tail -n 5 /var/log/nginx/access.logVeselības pieprasījums mēra pieejamību no klienta pozīcijas, un piekļuves žurnāls ieraksta laukus, kurus serveris jau izvēlējās paturēt. Izvēlieties uzdevumam vajadzīgos laukus un atstājiet pārējos ārpusē, jo pat URL var nest jutīgus parametrus. Žurnāla rinda ir pierādījums par to pakalpojumu, nevis par katru citu pakalpojumu, kuru lietotājs sasniedza caur tuneli. Šaura vākšana uztur mazu arī uzglabāšanas jautājumu, tāpēc iestatiet logu īsāku par domu eksperimentu, kas radīja prasību.
Pārtveršana ir atsevišķs uzticības dizains
Ja ziņojumu līmeņa pārbaude patiešām ir vajadzīga, TLS pārtveršana rada jaunu uzticamu galapunktu un klienta uzticības vienošanos, kas jāizplata un jāuztur. Lietotnes, kas piesprauž sertifikātus, salūzīs, un operators tagad glabā privātās atslēgas, kuru aizsardzība ir tikpat svarīga kā jebkura servera atslēga. Vākšanas darbināšana, vājinot sertifikātu validāciju vai lāpīt lietotni, kas piesprauž savus sertifikātus, apmaina drošības kontroli pret žurnāla rindu. Dodiet priekšroku dokumentētam pārbaudes dizainam, kura uzticības izplatīšana jau tiek pārvaldīta, un turiet iestādes privāto atslēgu ārpus visa kopīgā.
Vākšanas loga beigās noņemiet konfigurāciju un tās uzticības materiālu, izmantojot to īpašniekus, un likvidējiet saglabātos pierādījumus saskaņā ar saskaņoto politiku. Pietiekami uzticama informācija norādītajam mērķim ir panākumu kritērijs, nevis lielākā iespējamā uztveršana.