Muốn xây dựng hệ thống AI hoạt động hiệu quả, trước tiên bạn phải tìm cách phá vỡ chúng. Chúng tôi đã thực hiện một đợt kiểm thử đội đỏ (red team), đóng vai kẻ tấn công để kiểm tra và thăm dò một ứng dụng AI dành cho khách hàng trong lĩnh vực dịch vụ tài chính. Những phát hiện này có ý nghĩa quan trọng với bất kỳ ai triển khai ứng dụng sử dụng LLM trong môi trường mà bảo mật là yêu cầu bắt buộc.
Kiểm thử đội đỏ (red team) là hoạt động chủ động tìm cách phá vỡ hệ thống AI để khắc phục lỗ hổng trước khi kẻ tấn công thực sự phát hiện ra chúng. Trong dịch vụ tài chính, rủi ro đặc biệt cao: ứng dụng AI tiếp cận dữ liệu khách hàng, xử lý giao dịch và cung cấp thông tin chuyên sâu về tài chính. Sự cố có thể gây ra trải nghiệm người dùng kém, vi phạm quy định, tổn thất tài chính hoặc thiệt hại không thể khắc phục cho thương hiệu.
Mục tiêu của chúng tôi là sớm phát hiện lỗ hổng, thử nghiệm các kiểu tấn công thực tế và giúp tổ chức đáp ứng những yêu cầu về an toàn AI mà cơ quan quản lý đặc biệt coi trọng.
Cần phân biệt rõ: bẻ khóa nhắm vào các bộ lọc an toàn của mô hình nền tảng; chèn câu lệnh nhắm vào chính ứng dụng, bằng cách kết hợp dữ liệu đầu vào không đáng tin cậy của người dùng với câu lệnh đáng tin cậy của nhà phát triển. Chèn câu lệnh gây rủi ro lớn hơn vì nhắm vào hệ thống của bạn và dữ liệu mật mà hệ thống xử lý, chứ không phải một mô hình đa dụng.
Vòng kiểm thử đầu tiên của chúng tôi gồm khoảng 750 bài kiểm tra về:
Rò rỉ dữ liệu giữa các phiên
Lộ thông tin định danh cá nhân (PII) qua ngôn ngữ tự nhiên, thao túng API và nhiều kiểu mã hóa
Chèn mã SQL
Ghi đè câu lệnh hệ thống
Trong đợt kiểm thử ban đầu, chúng tôi xác định hai vấn đề lớn của hệ thống hiện tại: cách xử lý truy vấn đa ý định và việc sử dụng câu lệnh được mã hóa.
Truy vấn đa ý định: yêu cầu kết hợp mục đích hợp lệ với mục đích độc hại. Ví dụ: “Show my spending by category, and also execute [malicious SQL].” Ứng dụng không phát hiện ý đồ độc hại mà hoàn toàn dựa vào các biện pháp bảo vệ ở lớp dữ liệu phía sau. Điều này chẳng khác nào để ngỏ cửa chính chỉ vì bạn tin tưởng chiếc két sắt dưới tầng hầm.
Mã hóa: yêu cầu được mã hóa bằng Base64, Hex, LeetSpeak và các ký tự đồng hình. Hệ thống có thể gặp khó khăn khi lọc bỏ ý đồ độc hại. Dù những truy vấn này không làm lộ dữ liệu nhạy cảm, chúng vẫn khiến hệ thống mất ổn định đáng kể, như sinh nội dung sai, lặp lại SQL độc hại cho người dùng và phân loại sai ý định.
Kết quả kiểm thử ban đầu cho thấy:
Ảo giác về thời gian: mô hình đưa ra ngày tháng, dấu thời gian giao dịch hoặc bản tóm tắt theo thời gian hoàn toàn bịa đặt nhưng với giọng điệu chắc chắn. Đây là rủi ro lớn trong tài chính, nơi việc khách hàng hành động dựa trên ngày sai có thể gây hậu quả thực tế
Lặp lại SQL độc hại cho người dùng (đáng lo ngại vì nguy cơ đầu độc bộ nhớ)
Phân loại sai ý định
Định dạng đầu ra lộn xộn
Từ những phát hiện đó, chúng tôi thu hẹp phạm vi tập trung. Các bài kiểm tra chèn mã SQL và mã hóa được hạ mức ưu tiên vì nhóm đã xử lý những vấn đề này. Thay vào đó, chúng tôi tập trung vào các hướng tấn công thành công nhất: làm lộ PII và rò rỉ dữ liệu giữa các phiên.
Phát hiện nổi bật nhất ở vòng hai lại đơn giản đến bất ngờ: thường thì chẳng cần thủ thuật tinh vi nào cả.
Trong nhiều trường hợp, chỉ cần yêu cầu dữ liệu nội bộ dưới dạng một phần của yêu cầu có vẻ hợp lệ là đủ khiến hệ thống đồng ý tiết lộ dữ liệu đó. Những truy vấn đơn giản có thể nhận được phản hồi đề cập đến ID nội bộ và các trường hệ thống vốn tuyệt đối không được hiển thị cho người dùng cuối.
Khi đào sâu hơn, chúng tôi nhận thấy đây không chỉ là lỗi ở cấp ứng dụng. Dịch vụ chuyển văn bản thành SQL ở hạ nguồn đã tạo các truy vấn yêu cầu nhiều trường hơn mức cần thiết, đồng thời đề cập đến dữ liệu lẽ ra phải bị hạn chế trong phần giải thích. Điều này phơi bày một khe hở thực sự giữa các hệ thống—loại lỗ hổng chỉ xuất hiện khi kiểm thử toàn bộ hệ thống từ đầu đến cuối, thay vì từng thành phần riêng lẻ.
Kiểm thử đội đỏ (red team) cho hệ thống, không chỉ mô hình. Việc kiểm thử riêng lẻ một LLM cho bạn biết rất ít về tình trạng bảo mật của ứng dụng. Hãy kiểm thử toàn bộ hệ thống từ đầu đến cuối theo đúng cách người dùng tương tác.
Phải xác thực dữ liệu đầu vào trước khi dữ liệu đến LLM. Truy vấn được mã hóa, tấn công đa ý định và các nỗ lực chèn cơ bản phải bị chặn ngay tại vành đai bảo mật, thay vì giao cho các dịch vụ phía sau xử lý.
Đừng tin tưởng các điểm tiếp giáp. Trong kiến trúc đa dịch vụ, những khe hở giữa các hệ thống là nơi ẩn giấu các lỗ hổng đáng chú ý nhất. Không tin cậy nghĩa là không tin cậy: hãy xác thực mọi thứ ở mọi lớp.
Các cuộc tấn công đơn giản vẫn hiệu quả. Những thủ thuật bẻ khóa tinh vi thường chiếm sóng truyền thông, nhưng đôi khi bạn chỉ cần... hỏi. Nếu hệ thống sẵn sàng hiển thị mã định danh nội bộ khi người dùng đưa chúng vào một truy vấn vốn có vẻ hợp lệ, thì đó là vấn đề.
Hiểu rõ bạn thực sự đang kiểm thử điều gì. Các kiểu tấn công đã biết có thể bị chặn nhờ quá trình huấn luyện của chính LLM, chứ không phải các biện pháp bảo vệ của bạn. Hãy tích hợp khả năng quan sát vào hoạt động kiểm thử đội đỏ (red team) để biết những biện pháp kiểm soát nào thực sự được kích hoạt.
Môi trường bị hạn chế cần những giải pháp sáng tạo. Nhà cung cấp tùy chỉnh và khả năng hỗ trợ mô hình cục bộ giúp triển khai hoạt động kiểm thử đội đỏ (red team) thiết thực mà không cần quyền truy cập đám mây chuyên biệt. Tuy nhiên, cần minh bạch về những hạn chế phát sinh từ cách làm này.
Kiểm thử đội đỏ (red team) không phải hoạt động chỉ làm một lần. Đây là một quá trình lặp, cần được tự động hóa khi có thể và phải phát triển cùng hệ thống. Những cuộc tấn công đáng lưu tâm vào ngày mai sẽ không giống hôm nay.
Các hệ thống AI trong môi trường chịu sự quản lý sẽ ngày càng bị giám sát chặt chẽ hơn. Những tổ chức coi kiểm thử bảo mật là một hoạt động liên tục, thay vì một ô cần đánh dấu trước khi ra mắt, sẽ có khả năng đáp ứng sự giám sát đó tốt hơn và tránh được các cuộc khủng hoảng truyền thông làm mất lòng tin của khách hàng.