Token Proxy: Giải pháp ẩn danh dữ liệu cho LLM mà vẫn giữ nguyên ngữ cảnh phân tích

Trong quá trình xây dựng một "Ghost Analyst" (chuyên gia phân tích ảo) dựa trên Anthropic Claude để xử lý các sự cố bảo mật trên Microsoft Sentinel và Defender, đội ngũ phát triển đã gặp phải một bài toán nan giải làm thế nào để tận dụng sức mạnh suy luận của mô hình đẳng cấp nhất (frontier model) mà không gửi dữ liệu nhạy cảm của khách hàng lên đám mây.

Dữ liệu phân loại sự cố (triage) thường chứa địa chỉ IP, tên người dùng, tên máy chủ nội bộ và tên miền công ty. Việc sử dụng mô hình cục bộ (local model) có thể giải quyết vấn đề quyền riêng tư, nhưng các mô hình mã nguồn mở hiện nay chưa thể sánh bằng Claude Opus về khả năng suy luận logic. Cần một giải pháp trung gian: tiếp tục sử dụng mô hình hàng đầu nhưng giữ dữ liệu khách hàng ở lại nội bộ.

Đó chính là lý do Token Proxy ra đời — một lớp phòng ngừa mất dữ liệu (Data Loss Prevention) thông minh hoạt động như một "dịch giả" thay vì một công cụ xóa bỏ thô thiển.

Kiến trúc Token Proxy

Cách hoạt động của Token Proxy

Về cơ bản, proxy này nằm giữa tác nhân (agent) và API của Anthropic. Nhiệm vụ của nó là ẩn danh hóa (pseudonymize) dữ liệu nhạy cảm khi gửi đi và khôi phục dữ liệu gốc khi nhận kết quả trả về. Mục tiêu là LLM không bao giờ nhìn thấy dữ liệu thật, trong khi chuyên gia phân tích không bao giờ thấy dữ liệu giả.

Tuy nhiên, việc ẩn dữ liệu hoàn toàn sẽ phá vỡ khả năng suy luận của LLM. Đội ngũ phát triển đã trải qua 3 phiên bản để khắc phục các vấn đề này:

V1: Regex và sự ảo giác "Sarah Kowalski"

Phiên bản đầu tiên sử dụng Regex để khớp và thay thế email bằng các thẻ (ví dụ: [email protected] thành [User_Email_1]). LLM đã phản ứng tiêu cực vì cấu trúc này bất thường trong dữ liệu huấn luyện của nó.

• Ảo giác cú pháp: Để "sửa" lỗi cú pháp, Claude đã tự tạo ra một người dùng có tên thực như sarah.kowalski và thực hiện truy vấn trên người này.
• Phân mảnh thực thể: Khi thay bằng tên giả realistic (ví dụ: [email protected]), Claude nhận ra cấu trúc email và chỉ truy vấn phần tên john.smith. Proxy không nhận ra khớp một phần, dẫn đến truy vấn thất bại.

V2: NER và khoảng trống ngữ cảnh

Phiên bản thứ hai sử dụng mô hình Nhận diện Thực thể Được đặt tên (NER) của spaCy kết hợp Regex để phát hiện tốt hơn. Các thay thế cũng được điều chỉnh để có cú pháp hợp lệ (ví dụ: [email protected]). Tuy nhiên, vấn đề mới phát sinh: LLM mất khả năng nhận diện các mối đe dọa nhờ vào đặc điểm của dữ liệu.

• Di chuyển bất khả thi (Impossible Travel): Nếu một người dùng đăng nhập từ Hà Lan rồi đến Nga, Claude thường sẽ cảnh báo. Nhưng sau khi ẩn danh, cả hai IP trở thành các placeholder ngẫu nhiên (ví dụ: 198.51.100.1 và 198.51.100.2), mô hình không thể biết chúng nằm ở hai châu lục khác nhau.
• Typosquatting: Một miền tấn công giả mạo như miicrosoft.com sẽ rất dễ nhận ra. Nhưng khi bị ẩn thành domain-external-005.net, tín hiệu đe dọa biến mất.

V3: Ẩn danh bảo toàn ngữ cảnh (Context-preserving)

Phiên bản hiện tại giải quyết vấn đề bằng cách đóng vai trò là một dịch giả có hiểu biết: Lọc thông tin cá nhân (PII) nhưng giữ lại siêu dữ liệu (metadata) kỹ thuật.

• Thay thế IP có nhận biết ASN: Proxy tra cứu ASN và mạng của mỗi IP bằng cơ sở dữ liệu MaxMind GeoLite2, sau đó thay thế bằng một IP khác từ cùng ASN và subnet đó. Ví dụ, một IP của Hetzner tại Đức sẽ được thay bằng một IP Hetzner khác tại Đức. Điều này cho phép LLM vẫn thực hiện được lệnh whois, phát hiện di chuyển bất khả thi và phát hiện hosting đáng ngờ.
• Phân loại Nội bộ/Đối tác/Bên ngoài: Các thực thể được phân loại trong tệp cấu hình để LLM hiểu được ngữ cảnh bảo mật (ví dụ: người nội bộ nói chuyện với máy chủ bên ngoài).

Cuộc chiến với Dương tính giả (False Positive)

Xây dựng pipeline phát hiện chỉ là một nửa công việc. Nửa còn lại là dạy cho proxy biết những gì không nên ẩn danh, vì hệ sinh thái Microsoft chứa đầy các chuỗi trông giống dữ liệu nhạy cảm nhưng thực ra không phải.

Ví dụ, các phạm vi quyền của Graph API như Policy.ReadWrite.All trông giống tên miền. Phiên bản đầu tiên đã vui vẻ ẩn danh chúng thành domain-external-042.net, khiến LLM không biết nó đang gọi API nào. Tương tự cho các đường dẫn thuộc tính Azure như ConsentContext.IsAdminConsent.

Giải pháp là nhiều lớp lọc:

1. Bộ phát hiện thuộc tính có dấu chấm (dotted-property) nhận diện các mẫu PascalCase và động từ.
2. Danh sách bỏ qua (skiplist) có thể cấu hình với hơn 8.000 thuật ngữ bảng và cột KQL.
3. Danh sách cho phép (allowlist) miền cho các trang như mitre.org hay virustotal.com.
4. Phát hiện CamelCase để bỏ qua các định danh code như TimeGenerated.

Nhờ đó, tỷ lệ dương tính giả đã giảm từ 82% xuống gần như bằng không.

Kỹ thuật Streaming: Vấn đề đệm đuôi (Tail-buffer)

Khi Claude streaming token-by-token, một pseudonym có thể bị chia cắt qua hai chunk dữ liệu (ví dụ: domain-inter đến trước, nal-001.com đến sau). Một thao tác tìm và thay thế na sẽ bỏ sót hoàn toàn.

Giải pháp là một tail buffer giữ lại 80 ký tự cuối của mỗi chunk, nối chúng với chunk tiếp theo, thực hiện thay thế và chỉ gửi đi phần an toàn. Chi phí độ trễ rất nhỏ, đảm bảo không có pseudonym nào bị bỏ sót.

Kết luận

Token Proxy hiện là một dự án mã nguồn mở. Nó đóng vai trò là một mạng lưới an toàn, không phải là sự đảm bảo tuyệt đối. Nó bắt được các mẫu phổ biến (API keys, credentials, dữ liệu cá nhân), nhưng không có bộ lọc nào hoàn hảo. Tuy nhiên, đối với các trường hợp sử dụng SOC (Trung tâm Vận hành An ninh) hoặc bất kỳ ai muốn sử dụng suy luận của frontier-model trên dữ liệu không thể gửi lên đám mây, đây là một giải pháp bảo mật chiều sâu (defence in depth) rất hiệu quả.

Bạn có thể thử nghiệm dự án tại GitHub: github.com/zolderio/token-proxy.