Điểm yếu thực sự của kẻ tấn công không còn nằm ở mã nguồn nữa mà là người dùng doanh nghiệp.

Dương Tấn Đạt Tác giả Dương Tấn Đạt 04/02/2026 16 phút đọc

Trong bối cảnh cuộc đua trí tuệ nhân tạo (AI) ngày càng khốc liệt, Apple đã đưa ra một quyết định chiến lược quan trọng khi chọn Google Gemini làm nền tảng AI chủ lực tích hợp vào hệ sinh thái iOS và trợ lý ảo Siri. Tuy nhiên, quyết định này cũng tiềm ẩn nguy cơ lớn, bởi mối quan hệ hợp tác sâu với Google có thể khiến Apple phụ thuộc vào đối tác cạnh tranh lớn nhất của mình.

Lý do Apple chọn Gemini

Apple đã bước chân vào cuộc đua AI muộn hơn nhiều so với các đối thủ như OpenAI hay Google. Dù Apple quảng bá Apple Intelligence là giải pháp tập trung bảo mật và xử lý trực tiếp trên thiết bị, những mô hình AI “on-device” của hãng không đủ mạnh để xử lý các tác vụ AI phức tạp mà người dùng kỳ vọng. Vì vậy Apple cần một đối tác có công nghệ AI quy mô lớn và có thể mở rộng để phục vụ hàng tỷ thiết bị. Trong bối cảnh đó, Google Gemini được xem là lựa chọn phù hợp nhất nhờ khả năng xử lý đa phương thức và cơ sở hạ tầng điện toán đám mây mạnh mẽ.

Gemini không chỉ là một chatbot mà được xây dựng như một nền tảng tích hợp sâu với nhiều dịch vụ khác nhau, điều mà Apple đang cần để đưa trợ lý ảo Siri vượt qua giới hạn hiện tại.

Rủi ro trong quan hệ hợp tác

Lịch sử cho thấy các thỏa thuận đối tác công nghệ giữa Apple và các công ty khác đôi khi có thể kết thúc không như mong đợi. Apple từng hợp tác với IBM và Intel trong quá khứ nhưng cuối cùng không đạt được mục tiêu dài hạn như kỳ vọng. Giờ đây, việc phụ thuộc vào Google — đối thủ lớn trong lĩnh vực Android và tìm kiếm — có thể khiến Apple gặp rủi ro chiến lược nếu quan hệ này trở nên căng thẳng hoặc nếu Google thay đổi ưu tiên công nghệ cho các sản phẩm Android trước.

Ngoài ra, việc tích hợp sâu Gemini vào iOS đồng nghĩa với việc Google có “cửa sổ quan sát” trực tiếp cách người dùng Apple tương tác với AI. Nếu mối quan hệ này đổ vỡ do tranh chấp về chia sẻ doanh thu hoặc xung đột chiến lược, Apple có thể bị ảnh hưởng mạnh mẽ.

Apple và các chiến lược phụ thuộc khác

Tình huống của Apple hiện tại có phần tương đồng với Microsoft, khi cả hai công ty đều phụ thuộc vào đối tác AI bên ngoài — Microsoft với OpenAI, Apple với Google. Điều này phản ánh một thực tế là cả hai gã khổng lồ công nghệ đều chưa hoàn toàn làm chủ được “ngăn xếp AI lõi” một cách độc lập, ngay cả khi họ đã đầu tư mạnh vào lĩnh vực này.

Kết luận

Quyết định chọn Google Gemini là một bước đi chiến lược quan trọng giúp Apple thu hẹp khoảng cách về AI so với đối thủ, nhất là trong bối cảnh các tính năng AI ngày càng trở thành yếu tố quyết định trong trải nghiệm người dùng. Tuy nhiên, rủi ro của việc phụ thuộc vào một đối tác cạnh tranh có thể tạo ra “chia rẽ chiến lược” trong tương lai nếu Apple không phát triển đủ năng lực nội bộ để thay thế hoặc đối trọng với Gemini của Google.


Nếu bạn muốn, mình có thể biên tập lại thành bài chuẩn đăng web với tiêu đề, mở bài, các mục chính và kết luận rõ ràng hơn. Bạn chỉ cần nói “viết thành bài web” nhé.

 
https://www.technewsworld.com/story/the-real-attack-surface-isnt-code-anymore-its-business-users-180111.html
 

Dưới đây là bản dịch tiếng Việt hoàn chỉnh của bài TechNewsWorld bạn gửi, viết lại dạng tin công nghệ trung lập và đầy đủ bối cảnh, không thêm icon/emoji và phù hợp để đăng web hoặc làm tài liệu:


Mối nguy bảo mật thực sự hiện nay không còn nằm ở mã nguồn mà là ở người dùng doanh nghiệp

Trong nhiều tổ chức, nhóm an ninh mạng (AppSec) cho rằng họ hiểu rõ về các công cụ tự động hóa “no-code” được nhân viên xây dựng nhằm đơn giản hóa công việc hàng ngày. Tuy nhiên, khi các nhóm bảo mật thực sự kiểm tra, họ phát hiện ra quy mô thực tế của các quy trình tự động này lớn hơn nhiều so với dự đoán, tạo ra một bề mặt tấn công tiềm ẩn mà hầu như không được quản lý hay giám sát.

Bề mặt tấn công “no-code” bị bỏ sót

Các chương trình AppSec truyền thống được thiết kế để bảo vệ mã nguồn do các nhóm phát triển tạo ra, kiểm tra qua quy trình CI/CD và được giám sát bằng các công cụ như SAST hay DAST. Tuy nhiên, hiện nay người dùng doanh nghiệp không chuyên kỹ thuật đang tạo ra hàng nghìn quy trình tự động hóa trong các nền tảng no-code như Power Platform, ServiceNow, Salesforce hay UiPath. Những quy trình này không nằm trong tầm kiểm soát của nhóm an ninh vì chúng không đi qua đánh giá mã, không được ghi log đầy đủ và không bị giám sát an ninh tiêu chuẩn.

Ví dụ, một doanh nghiệp toàn cầu dự đoán sẽ tìm được vài trăm workflow do người dùng tạo. Khi được kiểm tra, số lượng thực tế lại vượt mức 3.000. Một nhân viên tài chính, không có nền tảng kỹ thuật, cũng tự tạo hơn 150 quy trình tự động. Có trường hợp một workflow âm thầm chuyển tiếp email công ty sang tài khoản cá nhân mà không ai biết.

Các rủi ro tiềm ẩn từ workflow “ẩn”

Những quy trình tự động này có thể chứa thông tin đăng nhập nhúng trực tiếp, làm lộ dữ liệu, tạo ra kết nối bất an giữa các hệ thống, hoặc thậm chí cho phép các tác nhân AI truy cập tới dữ liệu sản xuất quan trọng. Đây không phải do ý đồ xấu mà là hậu quả của một hệ thống được tối ưu cho sự tiện lợi hơn là kiểm soát an toàn.

Do các workflow này được tạo ngoài hệ thống quản lý của IT, các công cụ bảo mật hiện tại không thể theo dõi hoặc đánh giá chúng. Chúng không sinh ra log dạng mà SIEM hoặc các công cụ giám sát yêu cầu, và vì vậy các lỗ hổng tiềm ẩn có thể tồn tại trong thời gian dài mà không ai biết.

Phần “IT bóng tối” và thiếu quyền sở hữu

Vấn đề sâu xa hơn là không rõ ai chịu trách nhiệm với các quy trình này. Workflow do tài khoản dịch vụ dùng chung, do nhân viên đã nghỉ việc tạo ra, hoặc do AI tự sinh ra đều có thể tồn tại mà không ai biết rõ mục đích thiết kế cũng như quyền truy cập của chúng. Khi một workflow gây ra sự cố — ví dụ rò rỉ dữ liệu — đội ngũ bảo mật không thể xác định người hiểu rõ logic hay có quyền thay đổi chúng, buộc họ phải tắt toàn bộ hệ thống tự động, gây gián đoạn quy trình quan trọng của doanh nghiệp.

Công cụ an ninh truyền thống không theo kịp

Các phương pháp đánh giá an ninh ứng dụng truyền thống như kiểm tra tĩnh, kiểm tra động, hay kiểm thử xâm nhập đều gặp khó với các workflow không tạo ra mã rõ rệt và không chạy qua các quy trình DevSecOps tiêu chuẩn. Vì vậy, lớp bảo mật mới này phát triển như một “di sản an ninh” mà vẫn tăng lên từng ngày.

Cách tiếp cận quản trị rủi ro

Việc cấm hoàn toàn tự động hoá do người dùng tạo ra sẽ bóp nghẹt đổi mới và không phải là giải pháp khả thi. Thay vào đó, các tổ chức cần:

  • Xác định liên tục các workflow no-code, nguồn dữ liệu và quyền truy cập của chúng.

  • Gán quyền sở hữu rõ ràng cho từng quy trình tự động.

  • Thiết lập quản trị vòng đời workflow, bao gồm theo dõi thay đổi, phiên bản và quy trình ngừng sử dụng.

  • Giám sát runtime để phát hiện truy cập vượt quyền hoặc hành vi bất thường.

  • Tích hợp quản lý tự động hoá vào khuôn khổ bảo mật hiện có cho đồng nhất.

Kết luận

Bề mặt tấn công trong doanh nghiệp ngày nay không chỉ nằm trong mã nguồn do các nhóm Dev tạo ra. Nó còn bao gồm hàng nghìn workflow no-code do người dùng tạo ra, vốn ẩn, không được quản lý và dễ bị lợi dụng. Để giảm bớt rủi ro tích lũy do lớp bảo mật bị bỏ sót này, các tổ chức cần xây dựng khả năng hiển thị và quản trị các workflow ngoài DevSecOps truyền thống.

Dương Tấn Đạt
Tác giả Dương Tấn Đạt Admin
Bài viết trước Trình quản lý mật khẩu của Chrome gần đây đã nuốt hơn 15 triệu mật khẩu

Trình quản lý mật khẩu của Chrome gần đây đã nuốt hơn 15 triệu mật khẩu

Bài viết tiếp theo

Hướng dẫn về cáp màn hình của PCWorld

Hướng dẫn về cáp màn hình của PCWorld
Viết bình luận
Thêm bình luận

Bài viết liên quan

Thông báo

0917111899