Bảo mật AI ngầm: Tất cả những điều bạn cần biết

Trường hợp sử dụng: giảm thiểu rủi ro AI ẩn kiểu OpenClaw bằng quy trình DevSecOps.

OpenClaw là một trường hợp nghiên cứu hữu ích vì nó cho thấy cách thức... bóng ai Điều này trở thành rủi ro vận hành thực sự: một tác nhân chạy "cục bộ", kết nối với các kho lưu trữ và pipelineVà đột nhiên, một lượt truy cập trình duyệt, một mã thông báo hoặc một kỹ năng của bên thứ ba có thể biến thành một cuộc chiếm quyền kiểm soát. Mục tiêu không phải là cấm các tác nhân. Thay vào đó, mục tiêu là đảm bảo rằng công việc do tác nhân điều khiển được thực hiện thông qua cùng các biện pháp kiểm soát mà bạn đã tin tưởng đối với mã nguồn và chuỗi cung ứng.

Bước 1: Coi “kỹ năng” của tác nhân như những yếu tố phụ thuộc, chứ không phải là những tiện ích bổ sung vô hại.

Hầu hết các sự cố AI ngầm không bắt đầu bằng một cuộc tấn công tinh vi. Chúng bắt đầu từ việc triển khai: một nhà phát triển cài đặt một tác nhân, thêm một vài kỹ năng và cấp quyền truy cập cho nó "để nó hoạt động". Từ thời điểm đó, hệ sinh thái tác nhân hoạt động giống như một hệ sinh thái gói phần mềm: kỹ năng được cập nhật, các tập lệnh hỗ trợ xuất hiện và mã không đáng tin cậy có thể xâm nhập một cách âm thầm.

Vì vậy, bước đầu tiên là thay đổi tư duy: Bất cứ thứ gì mà tác nhân có thể cài đặt hoặc thực thi đều là một phần của chuỗi cung ứng của bạn.. trong một Quy trình làm việc của XygeniĐiều đó có nghĩa là bạn không cần chờ báo cáo về vi phạm. Bạn tập trung vào các dấu hiệu sớm hơn cho thấy một thành phần nào đó có rủi ro hoặc hoàn toàn độc hại, để việc áp dụng bị ngăn chặn trước khi nó lan rộng khắp các kho lưu trữ và máy tính của nhà phát triển.

Những thay đổi nào trong thực tiễn?

• Các nhóm ngừng sao chép và dán "cấu hình tác nhân đang hoạt động" mà không qua xem xét.
• Các kỹ năng mới và các gói hỗ trợ được coi như là các phụ thuộc cần thiết, chứ không phải là công cụ cá nhân.

Bước 2: Đặt PR làm điểm kiểm soát, ngay cả khi thay đổi do một nhân viên khác thực hiện.

Các tác nhân thúc đẩy sự thay đổi. Đó là điểm mấu chốt. Tuy nhiên, câu chuyện về OpenClaw cho thấy những "thay đổi nhỏ" nhanh chóng trở thành sự kiện bảo mật nghiêm trọng như thế nào khi các token và cổng công cụ được sử dụng. Do đó, chỉ dựa vào "sự thận trọng của nhà phát triển" là không đủ.

Thay vào đó, hãy định tuyến đầu ra của tác nhân thông qua pull requests và thực thi việc quét tại thời điểm tạo yêu cầu kéo (PR). Bằng cách đó, ngay cả khi một tác nhân đề xuất tăng mức độ phụ thuộc, tinh chỉnh tập lệnh xây dựng hoặc chỉnh sửa quy trình CI, PR sẽ trở thành điểm nghẽn nơi chính sách được áp dụng. Xygeni hoàn toàn phù hợp ở đây vì nó... được xây dựng cho CI/CD và quy trình làm việc PRNhờ vậy, những thay đổi rủi ro được phát hiện trước khi chúng lan rộng.

Các thay đổi điển hình do tác nhân thực hiện mà bạn muốn được giới hạn quyền truy cập

• Nâng cấp phụ thuộc và thay đổi tệp khóa
• Xây dựng tập lệnh và cài đặt hooks
• Chỉnh sửa quy trình CI (quyền hạn, sử dụng bí mật, cuộc gọi mạng)
• Các bước tự động hóa mới được chạy với quyền quản trị cao hơn.

Bước 3: Ưu tiên những gì kẻ tấn công sẽ sử dụng, chứ không chỉ những gì phần mềm quét tìm thấy.

AI ngầm (Shadow AI) làm tăng khối lượng công việc. Tự động hóa nhiều hơn đồng nghĩa với sự thay đổi phụ thuộc nhiều hơn, cấu hình biến đổi nhiều hơn và nhiều "thay đổi nhỏ" hơn mỗi tuần. Hậu quả là các nhóm có thể bị ngập trong các phát hiện trừ khi việc ưu tiên dựa trên khả năng khai thác thực tế.

Đây là lúc bối cảnh khai thác trở nên quan trọng. Nếu một lỗ hổng có khả năng bị khai thác và lỗ hổng khác thì không, quy trình làm việc của bạn cần phản ánh sự khác biệt đó. Xygeni's phương pháp ưu tiên Nó được thiết kế dựa trên thực tế này: giảm tiếng ồn bằng cách tập trung vào những vấn đề có khả năng gây ảnh hưởng nhất trong thực tế. 

Một quy tắc đơn giản có thể áp dụng cho mọi quy mô

• Chặn hoặc ưu tiên khắc phục các sự cố có rủi ro thực tế cao nhất.
• Hoãn xử lý nhiễu tín hiệu yếu để các kỹ sư có thể tiếp tục vận chuyển hàng hóa một cách an toàn.

Bước 4: Ngừng cho rằng “localhost là an toàn”

Vụ tấn công ClawJacked là một bài học quý giá vì nó vạch trần một giả định mà nhiều nhóm vẫn còn giữ: “nếu chỉ là cục bộ thì không sao”. Trên thực tế, các cổng cục bộ và giao diện người dùng cục bộ vẫn cần tư duy ở cấp độ sản xuất. Trình duyệt là một phần của bề mặt tấn công, và “chỉ cục bộ” không phải là ranh giới mà bạn có thể dựa vào.

Vì vậy, bạn cần tăng cường bảo mật cho các dịch vụ cục bộ giống như cách bạn làm với bất kỳ giao diện nhạy cảm nào khác:

• Xác thực mạnh mẽ (không chỉ là mật khẩu do người dùng chọn)
• Giới hạn tỷ lệ và khóa tài khoản
• Không có chức năng tự động kết nối nào tin tưởng vào các đầu vào chưa được xác thực.
• Hạn chế người được phép kết nối và vị trí kết nối.

Mặc dù Xygeni không phải là tường lửa localhost, nhưng nó giúp giảm thiểu tác động thực tế của các kiểu "bỏ qua cục bộ" bằng cách chuyển việc thực thi sang máy chủ cục bộ. pipeline và nền tảng. Khi các điều khiển nằm trong CI/CD và chính sách tư thế an ninh, trí tuệ nhân tạo ngầm ít có khả năng vượt qua chúng “vì nó hoạt động cục bộ”. 

Bước 5: Quan sát các hành vi bất thường có vẻ như là lạm dụng chuỗi cung ứng.

Các sự cố kiểu OpenClaw thường có chung một kiểu lỗi: một điều gì đó thay đổi âm thầm, sau đó quy trình làm việc bắt đầu hoạt động khác thường. Đó là lý do tại sao các tín hiệu tập trung vào sự bất thường lại quan trọng. Nếu một môi trường đột nhiên bắt đầu tải các phụ thuộc bất thường, phát hành các phiên bản nhanh chóng hoặc cho thấy các mô hình phù hợp với việc lạm dụng chuỗi cung ứng, bạn cần phải phát hiện sớm điều đó.

Phát hiện dị thường của Xygeni và việc xây dựng khung cảnh báo sớm phù hợp với mục tiêu đó: phát hiện các mô hình đáng ngờ từ sớm, trước khi chúng trở thành các sự cố lặp đi lặp lại trong các nhóm.

Những tín hiệu đáng chú ý

• Sự gia tăng đột ngột về các thay đổi phụ thuộc giữa các kho lưu trữ.
• Các gói/kỹ năng mới có uy tín thấp hoặc kiểu cập nhật bất thường
• Các bước CI không mong muốn tải xuống môi trường chạy hoặc thực thi tập lệnh
• Các cuộc gọi mạng bất thường từ ngữ cảnh xây dựng