Xây dựng hệ thống kiểm duyệt bảo mật dựa trên AI Agent trên nền tảng Databricks

Chúng tôi đã có sẵn tính năng tự động hóa trong một số phần của quy trình đánh giá bảo mật. Nó hữu ích, nhưng chưa giảm bớt đủ khối lượng công việc thủ công.

Tôi liên tục thấy cùng một mô hình trong hàng đợi: một tích hợp định kỳ sử dụng thiết kế quen thuộc lại nằm cạnh một kiến trúc thực sự mới lạ, rủi ro cao, cả hai đều chờ đợi cùng một nguồn lực khan hiếm: một chuyên gia đánh giá.

Vấn đề không phải là tính năng tự động hóa hiện tại của chúng tôi đã thất bại. Nó chỉ đơn giản là đã đạt đến giới hạn. Chúng tôi vẫn đang dành thời gian của chuyên gia cho những công việc có thể dự đoán trước, khiến cho việc đưa ra các quyết định thực sự cần đến sự phán đoán của chuyên gia bị hạn chế.

Vì vậy, tôi đã xây dựng một lớp dựa trên tác nhân (agent-based layer) để mở rộng những gì chúng tôi đang có. Mục tiêu không phải là thay thế quy trình hay con người đằng sau nó. Mục tiêu là giúp hệ thống hiểu được yêu cầu, áp dụng các tiêu chuẩn của chúng tôi, yêu cầu thông tin còn thiếu và nhận biết khi nào cần sự can thiệp của con người.

Phiên bản dựa trên tác nhân đầu tiên tập trung vào một lộ trình đánh giá. Nhóm của tôi đã nhìn thấy mô hình rộng hơn và mở rộng nó thành một tập hợp các tác nhân hiện đang hỗ trợ các phần bổ sung trong quy trình tiếp nhận và đánh giá bảo mật của chúng tôi. Tôi đã xây dựng phiên bản đầu tiên đó hoàn toàn trên Databricks, cùng nền tảng mà khách hàng của chúng tôi đang sử dụng.

Tại sao nền tảng này lại quan trọng

Tôi có thể di chuyển nhanh chóng vì các thành phần cốt lõi đã có sẵn trong cùng một môi trường.

Unity Catalog cung cấp một không gian được quản trị cho các tiêu chuẩn bảo mật, dữ liệu yêu cầu, bằng chứng hỗ trợ, quyết định và kết quả đầu ra của hệ thống. Các mô hình nền tảng (foundation models) được lưu trữ trên Databricks cung cấp lớp mô hình cho việc phân loại và lập luận. Lakeflow Jobs điều phối các quy trình làm việc dựa trên notebook trên nền tảng tính toán serverless. Databricks Apps cung cấp trải nghiệm tiếp nhận và bảng điều khiển dành cho quản lý.

Cách các thành phần kết hợp với nhau

Ở cấp độ cao, một yêu cầu đi qua nền tảng theo một lộ trình liên tục, với mỗi bước đều đọc và ghi vào cùng các bảng được quản trị:

1. Tiếp nhận (Intake) - Một ứng dụng hội thoại được xây dựng trên Databricks Apps chuyển đổi mô tả bằng ngôn ngữ thông thường thành một yêu cầu có cấu trúc và đính kèm bất kỳ tài liệu thiết kế hỗ trợ nào.
2. Lập luận (Reasoning) - Các mô hình nền tảng được lưu trữ trên Databricks (Claude Haiku, Sonnet và Opus) phân loại yêu cầu, đánh giá rủi ro và soạn thảo các yêu cầu, luôn dựa trên các tiêu chuẩn bảo mật của chúng tôi. Haiku xử lý phân loại nhẹ, Sonnet xử lý hầu hết công việc đánh giá và Opus được dành riêng cho các tác vụ lập luận phức tạp nhất.
3. Điều phối (Orchestration) - Lakeflow Jobs chạy các tác nhân đánh giá trên nền tảng tính toán serverless, đưa từng yêu cầu qua các giai đoạn theo lịch trình.
4. Hệ thống ghi chép (System of record) - Unity Catalog lưu trữ các tiêu chuẩn, dữ liệu yêu cầu, bằng chứng, kết quả đầu ra của mô hình và các quyết định dưới dạng các bảng được quản trị, với một mô hình phân quyền và dòng dõi dữ liệu (lineage) thống nhất cho tất cả.
5. Khả năng quan sát (Observability) - Một Databricks App thứ hai đọc cùng các bảng đó để báo cáo về khối lượng, hỗn hợp rủi ro, tỷ lệ tự động hóa và thời gian tiết kiệm được.

Điều này mang lại cho chúng tôi một mô hình quản trị và vận hành nhất quán trên toàn bộ dữ liệu, mô hình, quy trình làm việc và ứng dụng. Thay vì lắp ghép các dịch vụ riêng biệt với các quyền, nhật ký và đường dẫn dữ liệu khác nhau, tôi có thể tập trung vào logic đánh giá và trải nghiệm người dùng.

Sự khác biệt thực tế nằm ở tốc độ. Tôi đã có một hệ thống hoạt động trong chưa đầy hai giờ. Việc làm tương tự bằng cách kết nối các dịch vụ riêng biệt sẽ mất hàng tuần.

Không phải mọi đánh giá đều cần cùng một lộ trình

Hầu hết các hàng đợi bảo mật đều chứa cả các yêu cầu có thể dự đoán được và các ngoại lệ thực sự.

Một tích hợp sử dụng mô hình xác thực đã được phê duyệt và không xử lý dữ liệu nhạy cảm không phải là quyết định giống như một dịch vụ hướng internet xử lý thông tin nhạy cảm với quyền truy cập quản trị rộng rãi. Tuy nhiên, một hàng đợi truyền thống có thể gửi cả hai qua cùng một lộ trình thủ công.

Tôi không nhắm đến việc tự động hóa mọi đánh giá. Tôi tự động hóa các phần có thể lặp lại và giữ lại sự phán đoán của con người ở những nơi rủi ro hoặc sự không chắc chắn cao hơn.

Điều đó dẫn đến một quy tắc đơn giản: tự động hóa cho các trường hợp đã hiểu rõ trong các tiêu chí rõ ràng; con người cho các quyết định mới lạ, rủi ro cao hoặc mơ hồ.

Một "cánh cửa" tiếp nhận tốt hơn

Chất lượng đánh giá phụ thuộc vào thông tin có sẵn ngay từ đầu.

Các biểu mẫu tĩnh yêu cầu người gửi phải biết họ cần đánh giá gì, hiểu thuật ngữ bảo mật và dự đoán bằng chứng mà người đánh giá sẽ yêu cầu. Khi họ không làm được, yêu cầu sẽ đến nơi không đầy đủ và quá trình đánh giá bắt đầu bằng một vòng câu hỏi khác.

Tôi đã xây dựng một ứng dụng tiếp nhận hội thoại với Databricks Apps. Người gửi mô tả những gì họ đang cố gắng thực hiện bằng ngôn ngữ thông thường. Ứng dụng xác định lộ trình đánh giá khả thi, đặt các câu hỏi tiếp theo tùy thuộc vào ngữ cảnh và có thể sử dụng tài liệu thiết kế tích hợp làm ngữ cảnh hỗ trợ. Nó làm nổi bật thông tin còn thiếu và cung cấp chỉ báo rủi ro sơ bộ trước khi một yêu cầu chính thức được tạo ra.

Khi đã có đủ ngữ cảnh, nó sẽ tạo ra một yêu cầu có cấu trúc cho nhóm bảo mật.

Ứng dụng cũng có chế độ tư vấn dựa trên các tiêu chuẩn bảo mật của chúng tôi. Không phải câu hỏi nào cũng cần trở thành một ticket. Các nhóm có thể nhận hướng dẫn trong khi họ vẫn đang định hình thiết kế và chỉ mở một đánh giá chính thức khi thực sự cần thiết.

Đây đã trở thành một trong những phần hữu ích nhất của hệ thống. Nó cho phép mọi người đạt được tiến bộ sớm hơn, thay vì coi hàng đợi là cách duy nhất để tương tác với bộ phận bảo mật.

Cách các tác nhân hoạt động

Đằng sau ứng dụng tiếp nhận là một tập hợp các tác nhân chuyên biệt được triển khai trong Databricks Notebooks và được điều phối bằng Lakeflow Jobs.

Tôi cố tình tránh xây dựng một tác nhân duy nhất với thẩm quyền rộng để đóng vai trò là người đánh giá bảo mật. Mỗi tác nhân có một trách nhiệm giới hạn: thu thập ngữ cảnh, đánh giá rủi ro, ánh xạ yêu cầu tới các tiêu chuẩn liên quan, soạn thảo các yêu cầu, quản lý các bước tiếp theo hoặc chuẩn bị bàn giao cho con người.

Bảy tác nhân chuyên biệt, mỗi tác nhân một nhiệm vụ

Đó là một tập hợp các tác nhân chuyên biệt - không phải một tác nhân tổng quát, cũng không phải một tập lệnh duy nhất - mỗi tác nhân có một công việc cụ thể, được điều phối như các công việc theo lịch trình đằng sau ứng dụng tiếp nhận:

• Tác nhân tiếp nhận (Intake agent) - Chạy "cánh cửa" hội thoại: xác định lộ trình đánh giá, đặt các câu hỏi tùy thuộc vào ngữ cảnh và tập hợp một yêu cầu có cấu trúc.
• Tác nhân đánh giá rủi ro (Risk assessment agent) - Gán cấp độ rủi ro kèm bằng chứng hỗ trợ và mặc định ở cấp độ cao hơn khi thông tin chưa đầy đủ.
• Tác nhân yêu cầu (Requirements agent) - Ánh xạ yêu cầu tới các tiêu chuẩn liên quan và soạn thảo các yêu cầu cụ thể cho việc triển khai đối với các trường hợp đã hiểu rõ.
• Các tác nhân đánh giá chuyên biệt (Specialized review agents) - Xử lý các loại yêu cầu cần logic chuyên dụng, chẳng hạn như mô hình hóa mối đe dọa của tiện ích mở rộng trình duyệt và đánh giá nhà cung cấp bên thứ ba.
• Tác nhân xác thực (Validation agent) - Xây dựng danh sách kiểm tra xác thực cho từng mục đối với các yêu cầu rủi ro cao hơn trước khi đóng bất kỳ việc gì.
• Tác nhân quy trình làm việc (Workflow agent) - Xử lý công việc tiếp theo: làm rõ, nhắc nhở, theo dõi xác nhận và leo thang cho con người.
• Tác nhân học tập (Learning agent) - Định kỳ so sánh các chỉnh sửa của người đánh giá với kết quả đầu ra ban đầu để đưa ra các cải tiến cho các câu lệnh (prompts) và tiêu chuẩn.

Mỗi tác nhân có trách nhiệm giới hạn, vì vậy hành vi của nó vẫn có thể kiểm tra và thử nghiệm được, và một thay đổi đối với tác nhân này sẽ không âm thầm ảnh hưởng đến tác nhân khác.

Hệ thống trước tiên đánh giá rủi ro của yêu cầu và ghi lại bằng chứng hỗ trợ cho đánh giá đó. Bản thân một nhãn rủi ro là chưa đủ.

Khi thông tin bị thiếu hoặc mâu thuẫn, hệ thống sẽ yêu cầu làm rõ hoặc chuyển yêu cầu đó cho người đánh giá. Hệ thống không tự suy diễn để đưa ra phê duyệt.

Đối với các yêu cầu thông thường, các agent sẽ tạo ra các yêu cầu dựa trên kiến trúc thực tế và các tiêu chuẩn áp dụng, thay vì trả về các mẫu văn bản chung chung. Người yêu cầu xác nhận các yêu cầu đó và cung cấp bằng chứng cần thiết. Các yêu cầu có mức độ rủi ro thấp và trung bình đủ điều kiện có thể được hoàn tất thông qua quy trình tự động sau khi các tiêu chí và xác thực đã được đáp ứng.

Một ví dụ

Hãy xem xét một trường hợp phổ biến: tích hợp nội bộ sử dụng mô hình single-sign-on đã được phê duyệt và không xử lý dữ liệu nhạy cảm. Thay vì các mẫu văn bản chung chung, agent yêu cầu sẽ tạo ra các hạng mục cụ thể, có thể kiểm tra được gắn liền với kiến trúc đó - ví dụ:

• Xác thực thông qua nhà cung cấp danh tính (identity provider) đã được phê duyệt và vô hiệu hóa mọi thông tin đăng nhập cục bộ hoặc dùng chung.
• Giới hạn việc tích hợp ở các phạm vi truy cập tối thiểu cần thiết và lập tài liệu cho chúng.
• Gửi nhật ký ứng dụng và nhật ký truy cập đến đường ống ghi nhật ký (logging pipeline) trung tâm.
• Xác nhận cấp độ phân loại dữ liệu và đánh giá lại trước khi đưa bất kỳ dữ liệu nhạy cảm nào vào.

Người yêu cầu xác nhận các hạng mục này và đính kèm bằng chứng. Nếu mọi thứ đều khớp và trường hợp đó đáp ứng các tiêu chí đủ điều kiện, nó có thể được hoàn tất thông qua quy trình tự động.

Bài gốc còn tiếp — xem tiếp tại bài gốc ↗