Bảo mật AI: Thách thức thời gian thực mà ngay cả Google cũng đang vật lộn

Gần đây, tôi đã có cơ hội trò chuyện với Francis de Souza, Giám đốc vận hành (COO) của Google Cloud, hậu trường tại một sự kiện ở Los Angeles. Giữa tiếng ồn ào xung quanh, de Souza — người nói chuyện với điềm tĩnh, đo lường như một giáo sư đại học — đã đưa ra những lời khuyên hữu ích cho các công ty đang vượt qua giai đoạn bão tố về bảo mật AI mà tất cả chúng ta đang trải qua. Ông nhận định rằng: “Sẽ có một giai đoạn chuyển giao, và sau đó tôi nghĩ chúng ta sẽ đến một nơi tốt đẹp hơn”.

Tuy nhiên, lúc đó ông không nói về Google, nhưng rõ ràng ngay cả Google cũng đang trong quá trình tìm hiểu và giải quyết vấn đề này.

Thông điệp cốt lõi của de Souza là điều mà các chuyên gia bảo mật đã cố gắng khắc sâu vào tâm trí các cấp điều hành trong nhiều năm nay, và nay AI đã khiến nó trở nên cấp bách: Bảo mật không thể là suy nghĩ sau cùng.

“Khi các công ty bắt đầu hành trình AI, họ cần tiếp cận theo hướng nền tảng,” ông nói. “Bảo mật không phải là thứ bạn có thể lắp ghép thêm vào sau này, và cũng không phải là thứ bạn có thể để nhân viên tự thực hiện”. Ông đặc biệt cảnh báo về hiện tượng “Shadow AI” (AI bóng tối) — khi nhân viên tự ý sử dụng các công cụ tiêu dùng mà không có sự giám sát của tổ chức — và lập luận rằng các công ty cần yêu cầu bảo mật, quản trị và khả năng kiểm toán từ các nền tảng ngay từ đầu. “Không có chiến lược AI nào mà không đi kèm chiến lược dữ liệu và chiến lược bảo mật. Chúng phải song hành”.

Đáng chú ý là, ông không chỉ quảng bá cho riêng Google Cloud. Khi tôi nhận xét rằng lời khuyên của ông nghe giống như một quảng cáo của Google, ông đã phản bác. Google, theo ông, cam kết với phương pháp đa đám mây (multicloud), và ông lập luận rằng các công ty nghĩ rằng mình đang hoạt động trên một đám mây duy nhất thì gần như chắc chắn là không. “Kể cả khi họ chọn một đám mây duy nhất, họ vẫn dựa vào các ứng dụng SaaS, có các đối tác kinh doanh có thể đang sử dụng các đám mây khác,” ông nói. “Rất quan trọng đối với các công ty là phải có tư thế bảo mật nhất quán trên các đám mây và trên các mô hình khác nhau”.

Ông cũng chỉ ra rằng bối cảnh đe dọa đã thay đổi một cách cơ bản khiến các mô hình phòng thủ cũ trở nên quá chậm. Ông lưu ý rằng thời gian trung bình giữa lần xâm nhập ban đầu và việc chuyển sang giai đoạn tiếp theo của cuộc tấn công đã giảm từ 8 tiếng xuống còn 22 giây, và bề mặt tấn công đã mở rộng vượt ra ngoài biên mạng truyền thống. “Ngoài tài sản thông thường của bạn, giờ đây bạn còn có các mô hình. Bạn có các đường ống dữ liệu dùng để huấn luyện mô hình. Bạn có các tác nhân (agents), bạn có các câu lệnh (prompts). Tất cả những thứ này đều cần được bảo vệ”.

Một mối đe dọa mà de Souza chỉ ra nhưng chưa nhận được sự chú ý đủ lớn là: các tác nhân di chuyển qua hệ thống nội bộ của công ty có thể phát hiện ra các kho lưu trữ dữ liệu bị lãng quên mà không ai nghĩ đến trong nhiều năm. “Nhiều tổ chức có các máy chủ SharePoint cũ [và các điều khiển truy cập] mà họ thực sự không cập nhật, nhưng điều đó không quan trọng vì không ai thực sự biết chúng ở đâu. Nhưng các tác nhân lang thang trong doanh nghiệp của bạn sẽ tìm thấy những tài sản dữ liệu đó và phơi bày dữ liệu trên chúng”.

Câu trả lời, theo quan điểm của ông, là phải dùng tốc độ của máy móc để đối phó với tốc độ của máy móc. “Chúng ta đang thấy sự xuất hiện của một hệ thống phòng thủ hoàn toàn tự chủ dựa trên AI (AI-native, fully agentic defense), nơi các tổ chức có thể chạy các tác nhân điều khiển hệ thống phòng thủ của mình,” ông nói. “Thay vì có một hệ thống phòng thủ do con người dẫn dắt hoặc thậm chí là con người nằm trong vòng lặp, giờ đây bạn có thể để con người giám sát một hệ thống phòng thủ hoàn toàn tự chủ”. Ông thêm rằng vấn đề này đã trở thành vấn đề của lãnh đạo, không chỉ là công nghệ. “Đây là vấn đề cấp độ hội đồng quản trị và cấp đội ngũ điều hành. Không chỉ là vấn đề của đội ngũ bảo mật”.

Tuy nhiên, ngay cả khi AI đảm nhận nhiều khối lượng công việc phòng thủ hơn, những người có đủ năng lực để giám sát nó lại đang khan hiếm — và các lỗ hổng mà chính AI tạo ra đang nhân lên nhanh hơn khả năng giải quyết của các đội ngũ bảo mật. “Chúng ta sẽ cần những người để đối phó với sự bùng nổ lỗi (bug-pocalypse),” Lea Kissner, Giám đốc bảo mật thông tin của LinkedIn, nói với New York Times tuần này, thêm rằng bà không mong đợi ngành công nghiệp hiểu rõ về bảo mật AI theo một cách bền vững lâu dài trong ít nhất vài năm tới.

Điều này đưa chúng ta quay lại chính các nhà cung cấp nền tảng. The Register đã xuất bản một loạt báo cáo trong vài tuần qua, ghi nhận làn sóng các nhà phát triển Google Cloud bị tính hóa đơn năm chữ số sau các cuộc gọi API trái phép vào các mô hình Gemini — các dịch vụ mà nhiều người trong số họ chưa bao giờ sử dụng hoặc cố ý bật. Các trường hợp này tuân theo một mô hình quen thuộc: các khóa API ban đầu được triển khai cho Google Maps, được đặt công khai theo hướng dẫn của chính Google, đã âm thầm có khả năng truy cập Gemini sau khi Google mở rộng phạm vi của chúng mà không công bố rõ ràng sự thay đổi này.

Rod Danan, CEO của nền tảng chuẩn bị phỏng vấn Prentus, cho biết hóa đơn của ông lên tới 10.138 USD trong khoảng 30 phút sau khi kẻ tấn công khai thác khóa API bị xâm phạm của ông. Isuru Fonseka, một nhà phát triển tại Sydney có tài khoản cũng bị xâm phạm tương tự, đã tỉnh dậy với khoản phí khoảng 17.000 AUD dù tin rằng mình đã đặt giới hạn chi tiêu là 250 USD. Điều mà cả hai không biết là hệ thống tự động của Google đã nâng cấp gói thanh toán của họ dựa trên lịch sử tài khoản, nâng trần hiệu quả của họ lên tới 100.000 USD mà không có sự đồng ý rõ ràng.

Google đã hoàn tiền cho cả hai sau khi The Register xuất bản báo cáo ban đầu. Tuy nhiên, Google nói với The Register rằng họ không có kế hoạch thay đổi chính sách nâng cấp gói tự động của mình, nói rằng họ ưu tiên việc ngăn chặn sự cố dịch vụ hơn là thực thi các tùy chọn ngân sách đã nêu của người dùng.

Trong lúc đó, còn có một câu hỏi riêng về điều gì xảy ra khi một nhà phát triển cố gắng tắt mọi thứ. The Register đưa tin tuần này về nghiên cứu của công ty bảo mật Aikido phát hiện ra rằng ngay cả những nhà phát triển bắt được khóa bị xâm phạm và xóa nó ngay lập tức cũng có thể không an toàn. Theo phát hiện của Aikido, kẻ tấn công dường như có thể tiếp tục sử dụng khóa đó trong tối đa 23 phút vì việc thu hồi của Google lan truyền chậm qua cơ sở hạ tầng của họ. Nhà nghiên cứu của Aikido, Joseph Leon, nói với The Register rằng trong khoảng thời gian đó, tỷ lệ thành công là khó dự đoán — trong một số phút, hơn 90% yêu cầu vẫn được xác thực — và kẻ tấn công có thể sử dụng thời gian để rút xuất (exfiltrate) các tệp và dữ liệu cuộc trò chuyện được lưu trong bộ nhớ đệm từ Gemini.

Leon cũng lưu ý rằng các định dạng thông tin xác thực mới hơn của Google dường như không gặp vấn đề tương tự: thông tin xác thực API tài khoản dịch vụ được thu hồi trong khoảng năm giây, và định dạng khóa tiền tố AQ mới hơn của Gemini mất khoảng một phút. “Cả hai đều chạy ở quy mô của Google,” ông viết trong bài báo liên quan của Aikido. “Cả hai đều cho thấy điều này có thể giải quyết được về mặt kỹ thuật đối với khóa API Google của họ”. Nói tóm lại, theo Leon, khoảng thời gian 23 phút không phải là một ràng buộc kỹ thuật mà là vấn đề ưu tiên của công ty.

Điều đó đáng cân nhắc khi đọc lời khuyên của de Souza, vốn rất hợp lý và cần được nghiêm túc thực hiện. Ông không sai, nhưng hiện tại vẫn có khoảng cách giữa những gì các nền tảng đang kê đơn và tốc độ thích nghi của chính họ, và việc nhận thức rõ điều này cũng rất quan trọng.