Trong triển khai thực tế, bài toán nhạy cảm nhất của log không nằm ở việc phát hiện PII hay secrets, mà nằm ở vị trí xử lý: dữ liệu bị rò rỉ có thể đã vượt qua ranh giới kiểm soát trước khi được làm sạch. Datadog giải bài toán này bằng Sensitive Data Scanner (SDS) với hai mô hình triển khai khác nhau: chạy trên Datadog backend và chạy trong hạ tầng của bạn thông qua Observability Pipelines.

SDS backend và pipeline SDS

SDS backend

SDS backend hoạt động ở phía Datadog: dữ liệu telemetry được gửi lên Datadog, sau đó SDS quét và xử lý trong quá trình processing để dữ liệu nhạy cảm được loại bỏ trước khi indexing và hiển thị trong Datadog UI.

Điểm quan trọng là SDS backend không giới hạn ở logs. Theo tài liệu chính thức, SDS backend có thể quét và áp dụng hành động trên:

• Logs: toàn bộ log content và attribute values
• APM: chỉ span attribute values
• RUM: chỉ event attribute values
• Events: chỉ event attribute values

Việc cấu hình được thực hiện thông qua scanning group, trong đó có các tuỳ chọn bật/tắt theo từng sản phẩm logs, APM spans, RUM events và Datadog events.

Pipeline SDS

Pipeline SDS chạy trong hạ tầng của bạn bằng cách đặt Sensitive Data Scanner processor vào pipeline của Observability Pipelines để xử lý dữ liệu trước khi được chuyển tiếp.

Khác biệt cần làm rõ để tránh hiểu nhầm: Sensitive Data Scanner processor trong Observability Pipelines hiện được mô tả là available for logs.

Threat model và compliance: ranh giới egress là điểm quyết định

Nếu threat model và chính sách compliance cho phép dữ liệu raw đi qua ranh giới egress, SDS backend là đủ trong nhiều trường hợp vì dữ liệu được redact trước khi indexing và hiển thị trong Datadog UI.

Tuy nhiên, khi dùng SDS backend, bạn gửi logs và events lên Datadog nên dữ liệu rời khỏi môi trường của bạn trước khi được redaction.

Với các yêu cầu compliance theo hướng data minimization trước khi transfer, hoặc yêu cầu không để PII, PCI, secrets vượt qua boundary của hệ thống kiểm soát, lựa chọn phù hợp là dùng Observability Pipelines cùng Sensitive Data Scanner processor để scan và redact trước khi dữ liệu rời khỏi môi trường.

Kiến trúc triển khai pipeline SDS trong Observability Pipelines

Observability Pipelines Worker chạy trong hạ tầng của bạn để thu thập, xử lý và route dữ liệu đến các đích downstream. Mục tiêu là cung cấp quyền kiểm soát dữ liệu observability trước khi dữ liệu rời khỏi môi trường.

Một pipeline trong Observability Pipelines là một đường xử lý tuần tự gồm ba loại component:

• Source: nhận dữ liệu từ data source như Datadog Agent
• Processors: transform, enrich hoặc filter dữ liệu
• Destinations: nơi dữ liệu sau xử lý được gửi tới

Sensitive Data Scanner processor được đặt ở lớp processors để xử lý logs trong pipeline.

Rule, phạm vi quét, hành động áp dụng

Sensitive Data Scanner processor trong Observability Pipelines quét logs để phát hiện và xử lý dữ liệu nhạy cảm như PII, PCI và dữ liệu nhạy cảm tuỳ chỉnh. Processor hỗ trợ rule library và custom regex rules.

Filter query để giới hạn phạm vi quét

Processor yêu cầu khai báo filter query. Chỉ các logs match với filter query mới bị quét và xử lý; logs không match vẫn đi tiếp trong pipeline.

Phạm vi target và dữ liệu lồng nhau

Khi cấu hình rule, có thể chọn scan toàn bộ event, scan một số attributes, hoặc exclude một số attributes. Path notation dạng outer_key.inner_key cho dữ liệu nested.

Actions on match

Nêu rõ redaction, partial redaction và hashing là các hành động không đảo ngược.

Trong SDS backend, tài liệu cũng định nghĩa các hành động:

• Redact: thay toàn bộ match bằng token
• Partially redact: thay một phần match
• Hash: thay toàn bộ match bằng non-reversible unique identifier
• Mask chỉ dành cho logs và có cơ chế quyền Data Scanner Unmask để giải obfuscation trong Datadog

Mục tiêu vận hành và đặc tính kỹ thuật

Trong SDS, hash được dùng khi cần giữ khả năng correlation mà không giữ giá trị gốc.

• Mục tiêu: thay thế giá trị nhạy cảm bằng một định danh ổn định để phục vụ grouping, correlation và điều tra theo dấu vết, không nhằm phục hồi dữ liệu gốc.
• Đặc tính: non-reversible unique identifier.
• Chi tiết implementation trong Sensitive Data Scanner processor: UTF-8 bytes của match được hash bằng 64-bit fingerprint của FarmHash.

Hash trong ngữ cảnh này là một hành động xử lý dữ liệu để giảm rủi ro lộ thông tin trong telemetry, không được định vị như một cơ chế mã hoá để khôi phục dữ liệu.

Các bottleneck triển khai thường gặp

Vị trí đặt processor trong pipeline

Pipeline là chuỗi source → processors → destinations. SDS processor cần được đặt trước các destinations để đảm bảo dữ liệu đã được xử lý trước khi được route ra downstream systems.

Hiệu năng, throughput và phạm vi quét

SDS processor hoạt động dựa trên rule library hoặc regex rules. Filter query là cơ chế trực tiếp để giảm tải bằng cách giới hạn tập logs cần quét.

Backpressure và buffering

Observability Pipelines propagate backpressure khi hệ thống không xử lý kịp và có in-memory buffering khi component kế tiếp đang bận. Đây là phần cần được tính đến trong sizing và trong các tình huống downstream chậm hoặc log volume tăng đột biến.

Event batching ở destinations

Đa số destinations gửi events theo batch đến downstream integration. Điều này ảnh hưởng trực tiếp đến latency và hành vi khi downstream chậm.

Quản trị thay đổi và vận hành Worker

Khuyến nghị cập nhật Observability Pipelines Worker theo mỗi minor/patch release hoặc tối thiểu hàng tháng. Đây là yêu cầu thực tế để giảm rủi ro về tương thích và hành vi pipeline theo thời gian.

Mô hình quyền truy cập và audit

Ở SDS backend, Các quyền data_scanner_read, data_scanner_write để quản trị cấu hình, và quyền data_scanner_unmask cho mask action. Đây là điểm thường bị hỏi trong review về access control và kiểm toán.

Kết luận

Điểm khác biệt có giá trị triển khai của Datadog trong bài toán dữ liệu nhạy cảm nằm ở việc SDS có hai mô hình rõ ràng:

• SDS backend xử lý trong Datadog processing để dữ liệu được redaction trước indexing và hiển thị, đồng thời hỗ trợ logs, APM spans, RUM events và events theo phạm vi tài liệu mô tả.
• Pipeline SDS xử lý trong hạ tầng của bạn bằng Observability Pipelines để đáp ứng các yêu cầu compliance theo hướng xử lý trước ranh giới egress, với processor được mô tả là dành cho logs.