Избор на HTTP доказателства: записи на шлюза или журнали на приложението

Уеб мониторингът започва с цел, а не с точка на прихващане. Преброяването на активни клиенти, измерването на времето на API заявка и четенето на телата на съобщенията изискват различни доказателства и различни решения за поверителност. Шлюзът, който препредава защитен HTTPS, вижда връзки, а не съдържание на страница. Изборът на грешен слой дава данни, които изглеждат богати и не отговарят на нищо.

Назовете въпроса преди източника на данни

Започнете с оперативното решение, което данните трябва да подкрепят. Въпросите за наличност се нуждаят от броя и времената, въпросите за заявки — от пътища и кодове на състоянието, а въпросите за съдържание — от тела на съобщенията. Всяка стъпка навътре добавя чувствителност и инженерна сложност. Вземете одобрение от собственика на услугата и от собственика по сигурността за аудитория, цел и обработка преди началото на събирането, защото управлението на тунела не е това решение.

Напишете въпроса в едно изречение и го дръжте до плана за събиране. Това е единственият надежден контрол на обхвата.

Какво шлюзът може и какво не може да покаже

Шлюз, който препредава правилно защитен HTTPS, обикновено вижда адреси, портове и обеми, а не редове на заявки или тела.

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

Списъкът conntrack показва потоци и преобразувания, а краткият запис показва пакети без четим приложен смисъл. Това е достатъчно, за да се отговори дали трафикът тече, колко и между кои крайни точки. Това не е списък с URL адреси, а обикновено CONNECT прокси препредава шифрования обмен, без да прекратява TLS на приложението. Когато някой обещава пътища на заявки от тази позиция, попитайте кой компонент дешифрира и под чие доверие.

Журналите на приложението отговарят на повечето въпроси за заявки

За приложение, което управлявате, собственото му поддържано журналиране обикновено отговаря на въпроса на ниво заявка, без да дешифрира връзките на други.

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

Заявката за здраве измерва наличността от позицията на клиента, а журналът за достъп записва полетата, които сървърът вече е избрал да пази. Изберете полетата, нужни за задачата, и оставете останалите, защото дори URL може да носи чувствителни параметри. Редът в журнала е доказателство за тази услуга, а не за всяка друга услуга, до която потребителят е достигнал през тунела. Тясното събиране държи малък и въпроса за съхранението, затова задайте прозорец по-къс от мисления експеримент, който е създал изискването.

Прихващането е отделен дизайн на доверие

Ако инспекцията на ниво съобщение наистина е необходима, прихващането на TLS създава нова доверена крайна точка и клиентска доверителна уредба, която трябва да се разпространява и поддържа. Приложенията, които заковават сертификати, ще се счупят, а операторът вече държи частни ключове, чиято защита е също толкова важна, колкото всеки сървърен ключ. Да накараш събирането да работи чрез отслабване на проверката на сертификати или чрез кръпка на приложение, което заковава сертификатите си, заменя контрол за сигурност срещу ред в журнала. Предпочитайте документиран дизайн на инспекция, чието разпространение на доверие вече се управлява, и пазете частния ключ на органа извън всичко споделено.

В края на прозореца за събиране премахнете конфигурацията и нейния доверителен материал чрез техните собственици и унищожете запазените доказателства съгласно договорената политика. Достатъчно надеждна информация за заявената цел е критерият за успех, а не възможно най-големият запис.