Đã đăng vào khoảng 11 giờ trước 13 phút đọc

Tấn Công Embedding Trong Hệ Thống RAG - Phần 1: "Ảo Tưởng Bảo Mật - Vì Sao Embedding Không Phải Là Hàm Băm"

Mở đầu: Câu chuyện về hai thế giới

Hãy tưởng tượng bạn là một tên trộm chuyên nghiệp. Bạn đã đột nhập thành công vào một tòa nhà văn phòng. Trên tầng 5, bạn thấy hai căn phòng:

Phòng thứ nhất: Một kho tiền truyền thống. Nó nặng nề, được hàn kín, có hai lớp cửa thép, hệ thống báo động cảm biến chuyển động, camera 24/7 và một bảo vệ ngồi trực. Để đột nhập, bạn cần cả một đội chuyên nghiệp, mất vài tuần chuẩn bị, và xác suất thành công... không cao.

Phòng thứ hai: Cũng là một kho tiền, nhưng mới được lắp đặt tuần trước. Cửa vẫn bằng kính cường lực (trông rất hiện đại), hệ thống khóa thông minh kết nối Wi-Fi, và nhà sản xuất quảng cáo rằng "không ai có thể mở được vì chúng tôi không lưu mật khẩu, chỉ lưu "dấu ấn ngữ nghĩa" của mật khẩu thôi!". Nghe có vẻ an toàn phải không?

Bạn cười khẩy. Vì bạn biết: Dấu ấn ngữ nghĩa thì vẫn là dấu ấn. Và ở nơi có dấu ấn, kẻ theo dõi giỏi có thể tìm ra dấu vết.

Đó chính xác là câu chuyện của chúng ta hôm nay: Cơ sở dữ liệu quan hệ (RDB) là phòng thứ nhất. Cơ sở dữ liệu vector là phòng thứ hai. Và embedding? Đó là "dấu ấn" mà họ lưu trữ.

Vấn đề là: Người ta đang sống trong ảo tưởng rằng embedding là hàm băm một chiều - một sai lầm đắt giá mà chúng ta sẽ mổ xẻ ngay sau đây.

1. Sự trưởng thành của các "ông già" RDB

Cơ sở dữ liệu quan hệ - hay còn gọi là các "ông già" trong thế giới lưu trữ dữ liệu - đã tồn tại từ thập niên 1970. Hãy tưởng tượng họ như những chiến binh già dặn, đã trải qua hàng nghìn trận chiến:

Họ đã bị tấn công đủ kiểu: SQL Injection, tràn bộ đệm, leo thang đặc quyền, v.v.
Họ đã phát triển áo giáp: Kiểm soát truy cập chi tiết, mã hóa, kiểm toán, xác thực đa tầng.
Họ có một bản đồ mối đe dọa rõ ràng: Mọi kiểu tấn công đều đã được phân loại, mọi lỗ hổng đều có CVE, mọi bản vá đều có quy trình.

Kết quả? Để đột nhập vào một RDB trong một doanh nghiệp hiện đại, bạn cần một kịch bản tấn công phức tạp, nhiều bước, và thậm chí khi thành công, bạn cũng chỉ lấy được dữ liệu thô - vốn đã được mã hóa, kiểm soát và theo dõi sát sao.

2. Vector Database: "Đứa trẻ mới lớn" và những rủi ro ngây thơ

Bây giờ, hãy đến với Cơ sở dữ liệu vector - những "đứa trẻ mới" của làng công nghệ AI.

Chúng ra đời trong khoảng 5-7 năm trở lại đây, được thiết kế cho một mục đích cụ thể: tìm kiếm ngữ nghĩa. Nghĩa là thay vì tìm kiếm từ khóa chính xác, chúng tìm kiếm ý nghĩa.

Và vì chúng còn trẻ, chúng còn mang nhiều sự ngây thơ đáng yêu:

Thứ nhất: Bảo mật không được xây dựng từ đầu, mà được thêm vào sau. Giống như xây nhà xong mới nhớ lắp cửa vậy. Hầu hết các hệ thống vector DB đầu tiên ra đời với tư duy "hãy làm cho nó chạy trước đã, bảo mật tính sau". Và các tính năng bảo mật bây giờ tuy có, nhưng chưa được thử thách qua thời gian.

Thứ hai: Các nhà phát triển và quản trị viên có một quan niệm sai lầm nguy hiểm. Họ nghĩ rằng:

"Embedding giống như hàm băm mật khẩu - bạn cho đầu vào, nhận ra một chuỗi số, và không thể đảo ngược. Nên việc lưu embedding cũng an toàn như lưu mật khẩu đã hash vậy!"

Sai. Hoàn toàn sai. Và đây là sai lầm có thể khiến cả công ty bị đánh cắp thông tin.

3. Vạch trần ảo tưởng: Embedding KHÔNG phải Hash

Hãy cùng tôi làm một phép so sánh nho nhỏ.

🔒 Hàm băm (Hash) - Chiếc hộp đen tuyệt đối

Khi bạn băm mật khẩu "Password123" qua SHA-256, bạn nhận được một dãy 64 ký tự hex:

ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f

Bạn có thể lấy đầu ra này và ném vào Google, chatGPT, hay siêu máy tính mạnh nhất thế giới - không ai có thể khôi phục lại "Password123". Vì sao?

Hàm băm được thiết kế để là một chiều.
Có vô số input có thể cho ra cùng một output (collision).
Thông tin về input đã bị phá hủy hoàn toàn.

Tóm lại: Hash = Destroy & Forget.

🔓 Embedding - Chiếc hộp thủy tinh

Ngược lại, embedding là một vector số (ví dụ 384 chiều) được sinh ra từ một mô hình AI. Và điều kỳ diệu (hay nguy hiểm) là:

Embedding được thiết kế để bảo toàn ý nghĩa.
Nếu "Tôi yêu mèo" và "Tôi thích mèo" có nghĩa gần giống nhau, embeddings của chúng sẽ nằm gần nhau trong không gian vector.
Nghĩa là vector không phá hủy thông tin mà nó nén và tái cấu trúc thông tin.
Và ở nơi thông tin được bảo toàn, kẻ tấn công - với các công cụ phù hợp - có thể khôi phục lại thông tin.

Hãy tưởng tượng: Embedding giống như việc bạn nén một bức ảnh JPG. Bạn vẫn có thể nhìn thấy bức ảnh đó, dù không rõ nét bằng bản gốc. Hàm băm thì giống như bạn ném bức ảnh vào lò đốt và chỉ giữ lại số cân nặng của tro. Sự khác biệt là RẤT LỚN.

4. Một thí nghiệm tư duy nhanh

Hãy thử tưởng tượng:

Bạn có một embedding vector.
Tôi lấy 100.000 câu tiếng Việt và nhúng tất cả vào không gian vector.
Bây giờ tôi tìm câu nào có embedding gần nhất với vector của bạn.
Tôi đã khôi phục được nội dung gần đúng của văn bản gốc rồi đấy.

Không cần biết mật khẩu. Không cần bẻ khóa. Chỉ cần tìm kiếm hàng xóm.

Đó là lý do vì sao các cuộc tấn công như Đảo ngược Embedding (Embedding Inversion) và Suy luận Thành viên (Membership Inference) là có thật, và được chứng minh qua các nghiên cứu học thuật như Vec2Text (arXiv 2304.09649) hay Zero2Text (arXiv 2602.01757v2).

5. Hệ lụy của ảo tưởng

Khi các kỹ sư tin rằng embedding là "hàm băm một chiều", họ sẽ:

Không mã hóa embedding khi lưu trữ ("Dù có lấy cũng chả hiểu được mà!").
Không kiểm soát truy cập chặt chẽ ("Lấy được embedding thì biết làm gì?")
Không giám sát việc xuất khẩu embeddings ("Nó chỉ là số thôi mà!")

Và kết quả là: Họ đặt một cánh cửa kính cường lực (trông rất sang trọng, rất AI, rất hiện đại) lên một căn phòng chứa đầy tài liệu mật.

Kẻ tấn công chỉ cần một viên đá nhỏ. Và chuỗi series này sẽ chỉ cho bạn cách làm điều đó.

6. Ba cách đột nhập - Tổng quan nhanh

Trong phần 2, 3, 4 của series, chúng ta sẽ đi sâu vào từng kỹ thuật. Nhưng hãy điểm danh sơ bộ các chiến thuật tấn công:

🎯 Tấn công Đảo ngược Embedding (Embedding Inversion)

Mục tiêu: Tái tạo văn bản gốc từ embedding. Như lấy lại bức ảnh từ file JPG nén. Giá trị nhất nhưng tốn nhiều công sức nhất.

🔎 Suy luận Thành viên (Membership Inference)

Mục tiêu: Trả lời câu hỏi "Dữ liệu X có tồn tại trong hệ thống không?". Nếu tôi muốn biết mật khẩu của CEO có trong vector DB không, tôi sẽ hỏi câu này.

🏷️ Suy luận Thuộc tính (Attribute Inference)

Mục tiêu: Dự đoán metadata của tài liệu. "Đây là hợp đồng bảo mật hay báo cáo tài chính?" - Dù không đọc được nội dung, tôi vẫn biết được phân loại.

7. Giới hạn - Đừng mơ phục hồi văn bản 1000 từ

Để bạn không nghĩ rằng đảo ngược embedding là "phép màu", tôi xin nói thẳng một số thực tế:

Độ dài token: Hầu hết các công cụ hiện tại chỉ hoạt động tốt với 32-64 token. Đó là khoảng 1-2 câu ngắn. Văn bản 500 từ? Quên đi. Nhưng may thay, mật khẩu, khóa API, URL thường không dài hơn 1 câu.
Mật khẩu ngẫu nhiên: Nếu mật khẩu là 1qaz2wsx3edc4rfv - một chuỗi vô nghĩa, các mô hình AI không thể đoán được, và việc phục hồi gần như bất khả thi. (Nhưng chúng ta có cách khác, tôi sẽ nói ở phần 3).
Cần biết mô hình embedding: Bạn cần biết model nào sinh ra embedding (ví dụ: all-MiniLM-L6-v2). Có những ngoại lệ, như ALGEN (phần 4), nhưng nhìn chung, việc xác định model là bước bắt buộc.

8. Tóm tắt: 3 điều bạn cần nhớ

Embedding ≠ Hash. Hash phá hủy thông tin. Embedding nén và bảo toàn ý nghĩa. Kẻ tấn công có thể khôi phục từ nén.
Vector Database còn non. Thiếu kinh nghiệm chiến đấu với tấn công, thiếu mô hình mối đe dọa rõ ràng, và đang được triển khai với tốc độ chóng mặt - trong khi bảo mật đi sau.
Không phải AI nào cũng an toàn. Đội đỏ (Red Team) bắt đầu nhắm mục tiêu vào embedding - và bạn cần hiểu điều này để bảo vệ hệ thống của mình.

9. Preview Phần 2

Trong phần tiếp theo - "Trinh Sát Và Chọn Mục Tiêu", tôi sẽ hướng dẫn bạn:

Làm thế nào để xuất khẩu embedding từ một cơ sở dữ liệu vector thực tế.
Cách xác định mô hình embedding đã được sử dụng (có khi phải "hỏi han" qua API trò chuyện RAG - trông rất vô hại nhưng hiệu quả bất ngờ).
Phân loại đoạn (Chunk Triaging) để tìm ra những mẩu tin giá trị nhất trong hàng nghìn vector - như tìm kim trong bãi cỏ, nhưng tôi có nam châm.

Hãy chuẩn bị sẵn con dao mổ của bạn. Phòng thí nghiệm bắt đầu từ phần tới.

"Bảo mật là một quá trình, không phải một sản phẩm." — Bruce Schneier

Và trong thế giới AI, embedding là bằng chứng rõ nhất rằng những thứ trông có vẻ an toàn... thường thì không phải vậy.

AI Redteam AIEmbeddings