CNTT ngầm từng chủ yếu là vấn đề dịch vụ phần mềm. Một nhân viên đăng ký công cụ mới, kết nối nó với Google Workspace, rồi bộ phận bảo mật phát hiện một quyền truy cập OAuth chưa được phê duyệt. Tình huống này gây phiền toái, nhưng vẫn có dấu vết để phát hiện và khoanh vùng.
Giờ đây, CNTT ngầm có thể xuất hiện ngay trong tài khoản đám mây của doanh nghiệp. Một kỹ sư có ý tốt yêu cầu tác nhân AI dựng ứng dụng và hạ tầng trong một buổi chiều. Không có phiếu yêu cầu, không có quy trình rà soát và cũng không có bộ phận bảo mật tham gia.
Theo The New Stack, đây là dạng CNTT ngầm mới do ứng dụng viết theo cảm hứng tạo ra. Bài gốc được đăng lần đầu trên trang của Webflow vào ngày 13 tháng 8 năm 2026. Những công cụ này loại bỏ phần lớn trở ngại từng làm chậm quá trình triển khai, nhưng một phần trở ngại đó vốn là công việc bảo mật cần thiết.
Ý định tốt vẫn có thể tạo ra phạm vi thiệt hại lớn
CNTT ngầm truyền thống thường gắn với việc một nhóm cố tình đi vòng qua bộ phận công nghệ hoặc quy trình mua sắm. Với ứng dụng viết theo cảm hứng, kỹ sư không nhất thiết muốn né tránh chính sách. Họ có thể chỉ đang cố tự động hóa một công việc thủ công cho nhóm của mình.
Một tác nhân AI hỗ trợ viết mã có thể tạo mã nguồn, sinh chương trình Pulumi và dựng hạ tầng nhanh hơn tốc độ xử lý của quy trình rà soát. Nếu người vận hành chưa có kinh nghiệm về bảo mật đám mây, họ có thể không nhận ra ứng dụng vừa triển khai đã tạo thêm rủi ro.
Kịch bản xấu có thể bắt đầu bằng một ứng dụng nội bộ nhỏ. Tác nhân AI cấp phát tài nguyên trong tài khoản AWS của nhóm, mở các cổng cần thiết rồi triển khai ứng dụng. Công cụ hoạt động tốt nên không ai nghĩ rằng cần lập phiếu kiểm tra.
Sáu tuần sau, nền tảng quản lý trạng thái bảo mật đám mây phát hiện một điểm cuối công khai gắn với vai trò IAM có quyền quá rộng. Lúc này, ứng dụng đã chạy trong môi trường vận hành đủ lâu để nguy cơ di chuyển ngang trong hệ thống không còn chỉ là giả thuyết. Ý định ban đầu là giúp nhóm làm việc nhanh hơn, nhưng hậu quả có thể lan sang nhiều tài nguyên khác.
Từ dịch vụ phần mềm tràn lan đến mã nguồn tràn lan
Khi CNTT ngầm chủ yếu là dịch vụ phần mềm chưa được phê duyệt, doanh nghiệp có một bề mặt phát hiện tương đối rõ. Dấu hiệu có thể nằm trong quyền OAuth, lưu lượng mạng, báo cáo chi phí hoặc bất thường đăng nhập một lần. Công cụ nằm ngoài hạ tầng của tổ chức nên có thể bị nhận diện và ngắt kết nối, còn thiệt hại thường có giới hạn.
Ứng dụng nội bộ do tác nhân tạo ra lại nằm ngay trong hạ tầng của doanh nghiệp. Nó có vai trò IAM và có thể truy cập trực tiếp dữ liệu vận hành, giao diện lập trình nội bộ hoặc hệ thống nhạy cảm. Ứng dụng trông hợp lệ vì được một nhân viên hợp lệ xây dựng bằng công cụ hợp lệ. Mã nguồn không tự thông báo rằng nó chưa được quản trị. Nó chỉ tiếp tục chạy.
Sự thay đổi quan trọng là doanh nghiệp đã đi từ tình trạng dịch vụ phần mềm tràn lan sang mã nguồn tràn lan. Cách phát hiện kiểu cũ không thể được áp dụng nguyên vẹn cho tình huống mới. Khi hạ tầng AI và cách vận hành ngày càng gần với công việc hằng ngày của kỹ sư, khoảng cách giữa ý tưởng và triển khai càng ngắn.
Thiết lập rào chắn ngay trên nền tảng
Mục tiêu không phải làm kỹ sư chậm lại mà là biến phương án an toàn thành lựa chọn dễ thực hiện nhất. Mô hình Webflow hướng tới gồm hai lớp là kiểm soát nền tảng và kiểm soát quy trình.
Kiểm soát nền tảng được cấu hình một lần ở cấp tổ chức hoặc tài khoản để giảm khả năng tạo cấu hình nguy hiểm do sơ suất. Quyền trong các tài khoản AWS cấp nhóm nên được giới hạn theo nguyên tắc đặc quyền tối thiểu. Một kỹ sư không nên có khả năng tạo tài nguyên công khai với vai trò mang quyền rộng mà không gặp rào chắn.
Thông tin xác thực cũng không nên được ghi cứng trong mã. Nếu doanh nghiệp không làm cho phương án đúng trở nên rõ ràng, ứng dụng viết theo cảm hứng rất dễ chứa khóa hoặc mật khẩu trực tiếp. Bắt buộc sử dụng trình quản lý bí mật ở tầng hạ tầng sẽ loại bỏ quyết định này khỏi từng cá nhân.
Ứng dụng nội bộ nên mặc định được triển khai phía sau mạng riêng ảo của doanh nghiệp. Nếu một tài nguyên thực sự cần truy cập công khai, đó phải là quyết định rõ ràng thay vì kết quả của cấu hình mặc định.
Rà soát theo mức độ rủi ro trước khi triển khai
Kiểm soát quy trình bắt đầu ở cấp công cụ. Trước khi một người có kiến thức bảo mật đọc mã, hệ thống nên tự động đối chiếu mã nguồn và cấu hình hạ tầng với đường cơ sở đã đặt ra. Các vi phạm cần được đánh dấu theo mức độ nghiêm trọng và đi kèm hướng khắc phục cụ thể.
Một kỹ năng dành cho Claude hoặc công cụ AI tương tự có thể đảm nhiệm bước kiểm tra ban đầu. Người rà soát sau đó tập trung vào các vấn đề đã được hệ thống phát hiện thay vì bắt đầu từ con số không. Việc đơn giản hóa việc tích hợp AI ở quy mô lớn không thay đổi giới hạn đó: công cụ chỉ thực hiện kiểm tra ban đầu trước khi con người rà soát.
Mọi công cụ nội bộ chạm tới hạ tầng vận hành đều cần một người hiểu bảo mật xem xét trước khi phát hành. Với công cụ ít rủi ro, người rà soát có thể là kỹ sư cùng nhóm nhưng phải hiểu phạm vi ảnh hưởng của mã. Những trường hợp liên quan đến hạ tầng đám mây, truy cập dữ liệu trực tiếp hoặc vai trò IAM mới cần được chuyển sang quy trình rà soát bảo mật chính thức.
Người rà soát phải thực sự hiểu mã nguồn. Tác giả của một ứng dụng viết theo cảm hứng có thể không hiểu đầy đủ những gì tác nhân AI đã tạo. Vì vậy, rà soát không chỉ là cổng kiểm soát chất lượng mà còn là bước xác nhận mức độ hiểu biết về hệ thống sắp được đưa vào vận hành.
Phát hiện là lớp bảo vệ cuối, không phải lớp đầu tiên
Đường cơ sở và quy trình rà soát có tác dụng phòng ngừa. Nền tảng quản lý trạng thái bảo mật đám mây có nhiệm vụ phát hiện những gì đã lọt qua. Wiz và các công cụ cùng loại có thể chỉ ra điểm cuối công khai, vai trò có quyền quá rộng hoặc vùng lưu trữ thiếu kiểm soát truy cập phù hợp.
Hạn chế là công cụ này chỉ tìm thấy tài nguyên đã được triển khai. Một ứng dụng chạy cục bộ hoặc trong tài khoản riêng của nhóm có thể không để lại dấu vết trong lớp quan sát thông thường. Nó không đi qua quy trình triển khai, không có phiếu thay đổi và không xuất hiện trong danh mục tài sản.
Doanh nghiệp cần chú ý đến các tín hiệu hành vi trong dữ liệu đo đạc đám mây. Ví dụ gồm vai trò IAM được tạo ngoài hoạt động thông thường của quy trình, tài nguyên công khai mới không có hồ sơ thay đổi tương ứng, hoặc lệnh gọi giao diện lập trình đi thẳng từ máy của lập trình viên vào tài khoản vận hành thay vì qua công cụ chuẩn.
Từng tín hiệu riêng lẻ chưa đủ để kết luận. Khi chúng xuất hiện cùng nhau, hệ thống đáng được kiểm tra kỹ hơn. Khoảng trống hiện nay là nhiều nhóm chưa chủ động tìm các tín hiệu này trong bối cảnh công cụ do tác nhân AI xây dựng.
Đưa nội dung đường cơ sở vào chính công cụ của kỹ sư
Một tài liệu nằm trong trang nội bộ khó phát huy tác dụng vào đúng lúc kỹ sư đang xây dựng ứng dụng. Đường cơ sở bảo mật nên có mặt trong công cụ họ đang sử dụng và đưa ra phản hồi ngay tại thời điểm tạo mã hoặc hạ tầng.
Công cụ AI có thể kiểm tra mô tả kiến trúc hoặc hạ tầng được sinh tự động theo tiêu chuẩn riêng của tổ chức. Kỹ sư nhận được hướng dẫn cụ thể trước khi chuyển cho người rà soát. Bộ phận bảo mật cũng nhận một hồ sơ đã được lọc qua các lỗi rõ ràng, nhờ đó có bức tranh đầy đủ hơn khi bắt đầu đánh giá.
Biện pháp này chỉ có tác dụng khi kỹ sư biết công cụ tồn tại và quy trình rà soát được vận hành thật. Doanh nghiệp nên giới thiệu cả hai trong quá trình tiếp nhận nhân sự. Phản hồi của công cụ cũng có thể giải thích lý do của từng phép kiểm tra, giúp kỹ sư hiểu vì sao rào chắn cần thiết.
Xây đường cơ sở trước khi công cụ giám sát phát hiện sự cố
Ứng dụng nội bộ viết theo cảm hứng sẽ không biến mất. Trở ngại từng làm chậm hạ tầng thiếu quản trị đã được loại bỏ và khó có khả năng quay lại. Vấn đề là đường cơ sở bảo mật có theo kịp trước khi nền tảng giám sát phát hiện tài nguyên nguy hiểm hay không.
Kiểm soát nền tảng giúp phương án an toàn trở thành mặc định. Kiểm soát quy trình bảo đảm một người có kiến thức bảo mật xem xét công cụ trước khi triển khai. Hoạt động phát hiện tạo lớp bảo vệ cho những trường hợp vẫn lọt qua hai bước trên.
Doanh nghiệp không nhất thiết phải có một nhóm bảo mật ứng dụng hoặc trung tâm điều hành an ninh chuyên trách. Cần có đường cơ sở rõ ràng, công cụ thực thi được đường cơ sở đó và kỹ sư hiểu nội dung họ đang rà soát.
Quyền sở hữu kiểm soát nền tảng có thể nằm ở cấp tổ chức hoặc nhóm kỹ thuật bảo mật, được thiết lập một lần rồi áp dụng rộng rãi. Trách nhiệm kiểm soát quy trình được phân bổ theo rủi ro. Kỹ sư có kiến thức bảo mật xử lý công cụ ít rủi ro, còn mọi trường hợp chạm đến hạ tầng đám mây, dữ liệu trực tiếp hoặc vai trò IAM mới được chuyển sang rà soát chính thức.
Hãy bắt đầu xác định đường cơ sở bảo mật cho ứng dụng do AI tạo ra trước khi công cụ giám sát phải tìm thấy vấn đề thay bạn.
