Lợi nhuận:
- Khả năng tách biệt xác thực và ủy quyền và áp dụng ủy quyền tối thiểu với RBAC/ABAC
- Khả năng tránh rủi ro proxy hỗn hợp bằng cách chạy mô hình trong ngữ cảnh người dùng
- Khả năng lưu trữ và xoay vòng API key bằng hệ thống quản lý bí mật
Một phần đáng kể các cuộc tấn công vào hệ thống AI bắt đầu không phải bằng việc “đánh lừa” mô hình mà bằng khóa API bị đánh cắp hoặc tài khoản được ủy quyền quá mức. Lớp bảo mật này xuất phát từ bảo mật thông tin cổ điển, nhưng lại tiềm ẩn thêm những rủi ro mới trong bối cảnh AI: một người mẫu thay mặt người khác gọi xe, một tài khoản dịch vụ truy cập tất cả dữ liệu, một khóa bị rò rỉ tới GitHub. Trong phần này, chúng ta sẽ tìm hiểu cách thu hẹp quyền truy cập vào hệ thống AI bằng xác thực, ủy quyền (RBAC/ABAC), ủy quyền tối thiểu và quản lý bí mật.
Sự khác biệt giữa xác thực và ủy quyền
Hai thuật ngữ này thường bị nhầm lẫn:
- Xác thực: "Bạn là ai?" — chứng minh rằng người dùng/dịch vụ thực sự là người mà họ tuyên bố (mật khẩu, mã thông báo, chứng chỉ, MFA).
- Giấy phép: "Bạn có thể làm gì?" - xác định tài nguyên/hành động nào mà bên được xác thực có thể truy cập.
Điểm tinh tế quan trọng trong hệ thống AI là: khi mô hình thực hiện công việc thay mặt cho người dùng, nó sẽ hoạt động với quyền của người dùng đó hay với một tài khoản dịch vụ rộng rãi? Điều thứ hai là nguy hiểm - vì mô hình bị lừa bởi việc tiêm có quyền truy cập đầy đủ vào tài khoản dịch vụ.
Thận trọng: Vấn đề "Cấp phó bối rối": người dùng có thẩm quyền thấp truy cập gián tiếp vào dữ liệu mà anh ta không thể truy cập bằng cách thuê ngoài một mô hình có thẩm quyền cao. Mô hình phải luôn hoạt động trong bối cảnh thẩm quyền của người dùng chứ không phải thẩm quyền rộng rãi của chính người đó.
RBAC và ABAC
- RBAC (Kiểm soát truy cập dựa trên vai trò): Quyền truy cập tùy thuộc vào vai trò của người dùng. Vai trò "chuyên gia hỗ trợ" có thể đọc ghi chú của khách hàng nhưng không thể xóa chúng. Đơn giản và phổ biến.
- ABAC (Kiểm soát truy cập dựa trên thuộc tính): Quyền truy cập phụ thuộc vào các thuộc tính: bộ phận của người dùng, nhãn quyền riêng tư của dữ liệu, thời gian trong ngày, mạng nơi yêu cầu được gửi đến. Tinh chỉnh hơn nhưng phức tạp hơn.
Hầu hết các tổ chức đều bắt đầu với RBAC và đi sâu hơn vào ABAC đối với dữ liệu nhạy cảm. Nguyên tắc nhỏ đối với AI: mô hình phải lọc mọi tác nhân mà nó gọi và mọi dữ liệu mà nó truy cập dựa trên vai trò/thuộc tính của người dùng đưa ra yêu cầu.
Từng bước: Thực thi quyền tối thiểu
- Lấy hàng tồn kho. Mô hình gọi những công cụ nào, nó truy cập dữ liệu gì? Liệt kê tất cả chúng.
- Biện minh cho mỗi lần truy cập. “Trợ lý này có thực sự cần quyền xóa không?” Nếu không, hãy loại bỏ nó.
- Mặc định chỉ đọc. Mô hình sẽ có thể đọc theo mặc định; Yêu cầu ghi/xóa mã thông báo riêng biệt, phạm vi hẹp.
- Di chuyển bối cảnh người dùng. Gọi xe bằng quyền của người dùng chứ không phải bằng tài khoản dịch vụ.
- Thông tin xác thực có thời hạn sử dụng ngắn. Sử dụng mã thông báo có thời hạn sử dụng ngắn, tự động gia hạn thay vì khóa có thời hạn sử dụng lâu dài.
Quản lý bí mật
Bí mật là thông tin xác thực phải được giữ bí mật, chẳng hạn như khóa API, mật khẩu, mã thông báo hoặc chứng chỉ. Tai nạn thường gặp nhất trong các dự án AI là khi khóa API của nhà cung cấp mô hình được nhúng vào mã và rò rỉ vào phần kiểm soát phiên bản (Git).
Ứng dụng đúng:
- Không bao giờ nhúng khóa vào mã; Sử dụng biến môi trường hoặc hệ thống quản lý bí mật (dịch vụ lưu trữ khóa được mã hóa và kiểm soát quyền truy cập).
- Luân phiên: Gia hạn khóa theo định kỳ (ví dụ: 90 ngày một lần); Nếu nghi ngờ rò rỉ, hãy hủy ngay lập tức.
- Giảm phạm vi: Mỗi switch chỉ có dịch vụ cần thiết và ủy quyền cần thiết.
- Kiểm tra: Ghi lại ai đã sử dụng khóa, khi nào và ở đâu.
Bốn mẫu có thể sao chép
Truy cập lời nhắc kiểm soát đánh giá:
Đối với mỗi công cụ trong danh sách công cụ bên dưới, hãy đánh giá:- Công cụ này có BẮT BUỘC để thực hiện công việc của trợ lý này không? (có/không) - Nó chỉ đọc hay ghi/xóa? - Công cụ này có được gọi bằng tài khoản ủy quyền hoặc dịch vụ của người dùng không? Đánh dấu những cái không cần thiết hoặc được ủy quyền quá mức là "XÓA/XÓA".<tools>{{ tool_list }</tools>
Lời nhắc quét rò rỉ bí mật:
Tìm bất cứ thứ gì có thể là bí mật được mã hóa cứng trong đoạn mã sau: khóa API, mật khẩu, mã thông báo, chuỗi kết nối, khóa riêng tư. Đưa ra hàng và gõ cho mỗi. SAO CHÉP giá trị vào phản hồi;mặt nạ (4 ký tự đầu tiên + ***).<code>{{ source }</code>
Quy tắc ra quyết định có thẩm quyền tối thiểu:
Khi có yêu cầu truy cập/công cụ mới đến, hãy hỏi:1. Nhiệm vụ có thể được thực hiện mà không có quyền truy cập này? -> Nếu có: REJECT2. Chỉ đọc có đủ không? -> Nếu có: CẤP quyền ghi3. Phạm vi có thể được thu hẹp xuống một nguồn duy nhất? -> Nếu có: daratCâu trả lời mặc định là "không"; Quyền truy cập có được nhờ lý trí.
Nhắc nhở lịch quay:
Đối với mỗi bí mật, ghi: chủ sở hữu, ngày tạo, hết hạn, phạm vi. Báo cáo bất kỳ khóa nào đã vượt quá 90 ngày hoặc không được sử dụng trong 30 ngày là "THÍ SINH XUẤT/HỦY".
Nhắc yếu / Nhắc mạnh
cách tiếp cận kém
Cách tiếp cận mạnh mẽ
Mô hình truy cập tất cả dữ liệu bằng một tài khoản dịch vụ
Mô hình truy cập với quyền của người dùng đưa ra yêu cầu
Khóa API được nhúng trong mã, nó không bao giờ thay đổi
Luân chuyển người quản lý bí mật chính, 90 ngày
Quyền "làm bất cứ điều gì" rộng rãi cho trợ lý
Mặc định chỉ đọc, viết hẹp
Quyền truy cập không bao giờ được xem xét
Đánh giá và thu hồi quyền truy cập thường xuyên
Ba hộp nhỏ
Trường hợp 1 - Dữ liệu proxy hỗn hợp bị rò rỉ. Một trợ lý nội bộ đang làm việc với một tài khoản dịch vụ có quyền truy cập vào tất cả hồ sơ nhân viên. Một người dùng thực tập đã truy cập dữ liệu mà anh ta thường không nhìn thấy bằng cách nói "tóm tắt bảng lương điều hành"; bởi vì mô hình đã đặt câu hỏi về nó trong bối cảnh thẩm quyền rộng rãi của chính nó chứ không phải của người dùng. Sau khi bối cảnh người dùng được điều chỉnh để di chuyển, thực tập sinh có thể lấy các bản ghi mà chỉ họ mới có thể xem.
Trường hợp 2 — Chìa khóa bị rò rỉ, hóa đơn 190.000 TL trong 2 tuần. Một nhà phát triển đã nhúng khóa API mô hình vào tập lệnh trợ giúp và đẩy nó vào kho lưu trữ công khai. Một bot tìm thấy chìa khóa trong 40 phút và sử dụng nó trong hai tuần; Hóa đơn đạt 190.000 TL. Khi khóa được chuyển đến trình quản lý bí mật, kết nối với tính năng xoay vòng và thêm tính năng quét kho lưu trữ, sự cố đã không tái diễn.
Trường hợp 3 - Ngăn chặn ngắt mặc định chỉ đọc. Trợ lý DevOps đã nhận được lệnh "đặt lại cơ sở dữ liệu sản xuất" thông qua tính năng chèn lời nhắc. Tuy nhiên, trợ lý chỉ được cấp mã thông báo chỉ đọc; ghi/xóa nằm trong một luồng riêng biệt đã được phê duyệt. Lệnh bị từ chối do lỗi ủy quyền và sự kiện được ghi lại dưới dạng cảnh báo; Không có mất dữ liệu.
Mẹo: Đặt câu trả lời mặc định là "không" cho yêu cầu truy cập mới. Quyền tiếp cận là thứ đạt được thông qua sự biện minh; Cung cấp rộng rãi cho mọi người và sau đó cắt giảm hầu như không bao giờ được thực hiện và rủi ro sẽ tích lũy.
Những lỗi thường gặp
- Chạy mô hình với tài khoản dịch vụ lớn và mất bối cảnh người dùng (proxy hỗn hợp).
- Nhúng khóa API vào mã và rò rỉ nó vào phần kiểm soát phiên bản.
- Không xoay phím nào cả ("đang hoạt động, không chạm").
- Cấp quyền ghi/xóa cho trợ lý theo mặc định.
- Cấp quyền truy cập một lần và không bao giờ xem xét lại nó.
- Nhầm lẫn xác thực với ủy quyền và cho rằng "anh ấy đã đăng nhập, anh ấy có thể truy cập mọi thứ".
Tóm lại
- Xác thực là câu hỏi “bạn là ai”, ủy quyền là câu hỏi “bạn có thể làm gì”; Trong AI, cả hai đều phải hoạt động trong bối cảnh của người dùng.
- Mô hình nên hoạt động với thẩm quyền của người dùng đưa ra yêu cầu chứ không phải với thẩm quyền rộng rãi của chính nó (tránh rủi ro của cơ quan hỗn hợp).
- Bắt đầu với RBAC, đào sâu hơn với ABAC trên dữ liệu nhạy cảm; Đặt quyền hạn tối thiểu làm mặc định.
- Đừng chôn giấu bí mật trong mã; lưu trữ nó trong trình quản lý bí mật, thu hẹp nó lại và đưa vào chế độ luân chuyển thường xuyên.
- Mặc định chỉ đọc và ghi hẹp hạn chế đáng kể tác động của việc tiêm.
Nhiệm vụ ứng dụng
Liệt kê tất cả các công cụ và dữ liệu mà trợ lý AI của bạn truy cập. Trả lời ba câu hỏi cho mỗi câu: (1) Có thực sự cần thiết không? (2) Chỉ đọc có đủ không? (3) Nó có chạy trong ngữ cảnh của người dùng không? Sau đó tìm kiếm tất cả các bí mật được mã hóa cứng (thông qua dấu nhắc quét ở trên) và viết kế hoạch xoay vòng cho từng khóa bạn tìm thấy. Xóa ít nhất một ủy quyền không cần thiết.
danh sách kiểm tra
- [ ] Mô hình chạy trong ngữ cảnh quyền hạn của người dùng đưa ra yêu cầu.
- [ ] Quyền truy cập vào công cụ và dữ liệu đã được thu hẹp theo nguyên tắc đặc quyền tối thiểu.
- [ ] Ghi/xóa tách biệt với chỉ đọc, được xác thực và thu hẹp.
- [ ] Không có bí mật nào được chôn giấu trong mã; Nó được giữ trong người quản lý bí mật.
- [ ] Có lịch luân chuyển và thủ tục hủy chìa khóa.
- [ ] Các quyền truy cập được xem xét thường xuyên.