Chọn bằng chứng HTTP: bản ghi cổng hay nhật ký ứng dụng

Giám sát web bắt đầu bằng mục đích, không phải bằng điểm thu thập. Đếm khách hàng đang hoạt động, đo thời gian gọi API và đọc phần thân thông điệp mỗi việc cần bằng chứng khác nhau và quyết định riêng tư khác nhau. Cổng chuyển tiếp HTTPS được bảo vệ thấy kết nối chứ không thấy nội dung trang. Chọn sai tầng sẽ cho dữ liệu trông phong phú mà không trả lời gì.

Đặt tên câu hỏi trước nguồn dữ liệu

Hãy bắt đầu từ quyết định vận hành mà dữ liệu phải hỗ trợ. Câu hỏi về khả dụng cần số đếm và thời gian, câu hỏi về yêu cầu cần đường dẫn và mã trạng thái, còn câu hỏi về nội dung cần phần thân thông điệp. Mỗi bước vào trong đều thêm độ nhạy cảm và độ phức tạp kỹ thuật. Hãy để chủ dịch vụ và chủ bảo mật phê duyệt đối tượng, mục đích và cách xử lý trước khi bắt đầu thu thập, vì vận hành đường hầm không phải quyết định đó.

Viết câu hỏi trong một câu và giữ nó bên cạnh kế hoạch thu thập. Đó là kiểm soát phạm vi duy nhất đáng tin cậy.

Cổng có thể và không thể hiển thị gì

Cổng chuyển tiếp HTTPS được bảo vệ đúng cách thường thấy địa chỉ, cổng và khối lượng, chứ không thấy dòng yêu cầu hay phần thân.

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

Danh sách conntrack hiển thị luồng và bản dịch, còn bản ghi ngắn hiển thị gói tin không có nội dung ứng dụng đọc được. Thế là đủ để trả lời lưu lượng có chảy không, bao nhiêu và giữa những điểm cuối nào. Đây không phải danh sách URL, và proxy CONNECT thông thường chuyển tiếp trao đổi mã hóa mà không kết thúc TLS của ứng dụng. Khi ai đó hứa hẹn đường dẫn yêu cầu từ vị trí đó, hãy hỏi thành phần nào giải mã và dưới sự tin cậy của ai.

Nhật ký ứng dụng trả lời phần lớn câu hỏi về yêu cầu

Với ứng dụng bạn vận hành, nhật ký được hỗ trợ của chính nó thường trả lời câu hỏi ở cấp yêu cầu mà không giải mã kết nối của người khác.

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

Yêu cầu sức khỏe đo khả dụng từ vị trí của khách hàng, và nhật ký truy cập ghi lại các trường mà máy chủ đã chọn giữ. Hãy chọn các trường công việc cần và bỏ phần còn lại ra ngoài, vì ngay cả URL cũng có thể mang tham số nhạy cảm. Một dòng nhật ký là bằng chứng về dịch vụ đó, không phải về mọi dịch vụ khác mà người dùng đã đến qua đường hầm. Giữ việc thu thập hẹp cũng giữ câu hỏi lưu trữ nhỏ, vì vậy hãy đặt một cửa sổ ngắn hơn thí nghiệm tư duy đã tạo ra yêu cầu.

Chặn bắt là một thiết kế tin cậy riêng

Nếu thực sự cần kiểm tra ở cấp thông điệp, chặn bắt TLS tạo ra một điểm cuối tin cậy mới và một thỏa thuận tin cậy của khách hàng phải được phân phối và duy trì. Các ứng dụng ghim chứng chỉ sẽ hỏng, và người vận hành giờ giữ khóa riêng mà việc bảo vệ quan trọng như bất kỳ khóa máy chủ nào. Làm cho việc thu thập hoạt động bằng cách làm yếu xác thực chứng chỉ, hoặc bằng cách vá một ứng dụng ghim chứng chỉ của nó, đánh đổi một kiểm soát bảo mật lấy một dòng nhật ký. Hãy ưu tiên một thiết kế kiểm tra có tài liệu mà việc phân phối tin cậy đã được quản lý, và giữ khóa riêng của cơ quan ngoài mọi thứ được chia sẻ.

Khi kết thúc cửa sổ thu thập, hãy gỡ cấu hình và vật liệu tin cậy của nó thông qua chủ sở hữu của chúng, và xử lý bằng chứng đã giữ theo chính sách đã thống nhất. Thông tin đáng tin cậy đủ cho mục đích đã nêu là tiêu chí thành công, không phải thu thập lớn nhất có thể.