Thông tin chung về FPT Cloud

Trong kỷ nguyên chuyển đổi số, việc di dời hạ tầng lên môi trường đám mây đã trở thành bước đi chiến lược của nhiều doanh nghiệp. Tuy nhiên, đi kèm với sự linh hoạt là những thách thức không nhỏ về an toàn thông tin. Nghiên cứu từ Gartner chỉ ra một thực tế đáng chú ý: có tới 99% các vụ vi phạm bảo mật trên Cloud không xuất phát từ các đợt tấn công tinh vi hay lỗ hổng zero-day, mà lại bắt nguồn từ những lỗi cấu hình sai (misconfiguration) rất cơ bản. Nhằm giúp doanh nghiệp giải triệt để bài toán này, FPT Smart Cloud đã phát triển FPT CSPM (Cloud Security Posture Management) – giải pháp quản lý trạng thái bảo mật hạ tầng tự động, đóng vai trò như một "lá chắn" chuyên sâu và liên tục. 1. Tổng quan về FPT CSPM FPT CSPM là dịch vụ độc lập thuộc bộ giải pháp bảo mật Cloud toàn diện FPT Security Hub (CNAPP) nội địa duy nhất tại Việt Nam. Sản phẩm tích hợp ba năng lực cốt lõi bao gồm: tự động kiểm kê tài nguyên, liên tục phát hiện các lỗi cấu hình bảo mật và cung cấp hướng dẫn khắc phục rủi ro chi tiết. Trong kiến trúc tổng thể giải pháp Security của FPT Cloud, CSPM đóng vai trò trụ cột thuộc nhóm Posture, Compliance & Governance (PCG). Đây được xem là lớp phòng thủ can thiệp sớm nhất trong chuỗi bảo mật. Bằng cách phát hiện rủi ro ngay từ tầng hạ tầng trước khi kẻ tấn công có cơ hội khai thác, CSPM cung cấp dữ liệu đầu vào chuẩn xác cho hệ thống phân tích trí tuệ trung tâm Graph Risk Path Engine (GRPE) để đánh giá đúng bán kính ảnh hưởng (blast radius) và xác định các điểm nghẽn an ninh cần ưu tiên xử lý Giải pháp này được thiết kế để phục vụ đa dạng các nhóm nhân sự trong tổ chức. Từ các Cloud Admin mong muốn tối ưu hóa thời gian rà soát hạ tầng thủ công, các Security Engineer cần công cụ quản lý alert tập trung, cho đến các Giám đốc IT hay quản lý tại các doanh nghiệp vừa và nhỏ (SME) – những người cần một giải pháp bảo mật mạnh mẽ nhưng không đòi hỏi phải có đội ngũ chuyên gia vận hành quá phức tạp. 2. Các tính năng nổi bật của FPT CSPM FPT CSPM cung cấp hệ thống tính năng hỗ trợ doanh nghiệp quản lý trạng thái bảo mật hạ tầng Cloud, từ kiểm kê tài nguyên, phát hiện lỗi cấu hình đến đánh giá mức độ tuân thủ và phân tích rủi ro bảo mật. STT  Tính năng  Mô tả  1  Asset Inventory  Tự động khám phá và lập danh mục toàn bộ tài nguyên Cloud.  2  Misconfiguration Detection  Phát hiện sai cấu hình bảo mật trên hạ tầng Cloud.  3  Posture Dashboard  Đánh giá mức độ bảo mật tổng thể của môi trường Cloud.  4  Remediation Guidance  Cung cấp hướng dẫn khắc phục từng bước cho mỗi lỗi cấu hình.  5  CIS / NIST / ISO Compliance  Tự động đánh giá tuân thủ theo các framework bảo mật quốc tế.  6  Vietnamese Compliance  Đánh giá tuân thủ theo quy định pháp lý Việt Nam.  7  Attack Path Analysis  Phân tích và trực quan hóa chuỗi tấn công tiềm ẩn từ Internet đến tài nguyên nhạy cảm.  8  Automated Scan  Quét tự động môi trường Cloud theo lịch định kỳ hoặc kích hoạt theo sự kiện.  9  Custom Rules  Cho phép đội ngũ bảo mật tự định nghĩa quy tắc kiểm tra theo chính sách nội bộ.  10  SIEM Integration  Tích hợp với hệ thống SIEM/SOC hiện có để chuyển tiếp cảnh báo và sự kiện bảo mật.  11  Notification & Alerts  Gửi cảnh báo khi phát hiện rủi ro mới.    Thông qua các tính năng này, FPT CSPM hỗ trợ đội ngũ IT và Security theo dõi trạng thái bảo mật hạ tầng, nhận diện các vấn đề cần chú ý và chủ động quản lý rủi ro trong quá trình vận hành Cloud. 3. FPT CSPM vận hành như thế nào? Quy trình sử dụng FPT CSPM được triển khai qua bốn bước chính: Kích hoạt → Kiểm kê tài nguyên → Phát hiện và xử lý vấn đề → Theo dõi liên tục. Sau khi đăng ký và kích hoạt dịch vụ trên FPT Cloud Portal, hệ thống bắt đầu nhận diện các tài nguyên Cloud và đánh giá cấu hình. Kết quả được hiển thị trên Dashboard, bao gồm Security Posture Score, danh mục tài nguyên và các vấn đề bảo mật được phát hiện. Từ đây, người dùng có thể truy cập Asset Inventory để tìm tài nguyên cần kiểm tra, chuyển sang Issue Management để xem chi tiết từng vấn đề và tham khảo hướng dẫn khắc phục. Sau khi thực hiện remediation, đội ngũ tiếp tục theo dõi kết quả qua các lần đánh giá tiếp theo để cập nhật trạng thái bảo mật của hạ tầng. Quy trình này giúp kết nối các hoạt động kiểm kê, phát hiện và xử lý trong cùng một dịch vụ, thay vì tách rời thành nhiều bước kiểm tra thủ công.Kiến trúc và cách hoạt động của dịch vụ FPT CSPM. Kiến trúc và cách hoạt động của dịch vụ FPT CSPM  4. Những điểm nổi bật khi triển khai FPT CSPM Điểm tạo nên sự khác biệt lớn của FPT CSPM so với nhiều giải pháp trên thị trường nằm ở kiến trúc triển khai thông minh. Giải pháp vận hành hoàn toàn theo mô hình Agentless – không yêu cầu cài đặt thêm bất kỳ phần mềm hay agent nào lên máy ảo hay ứng dụng của khách hàng, nhờ đó loại bỏ hoàn toàn nguy cơ gây ảnh hưởng đến hiệu năng hay độ ổn định của hệ thống. Đồng thời, FPT CSPM hoạt động theo cơ chế Read-only. Dịch vụ chỉ thu thập các thông tin metadata về cấu hình hạ tầng (như quy tắc firewall, địa chỉ IP public, thiết lập IAM, chứng chỉ SSL...). Hệ thống cam kết tuyệt đối không truy cập hay thu thập các dữ liệu nghiệp vụ nhạy cảm bên trong như nội dung file, đĩa cứng, dữ liệu database hay các mã khóa bí mật của doanh nghiệp. Một điểm cộng chiến lược khác là 100% dữ liệu được xử lý và lưu trữ tại hạ tầng FPT Cloud trong lãnh thổ Việt Nam. Điều này giúp các tổ chức, đặc biệt là khối tài chính, ngân hàng và cơ quan nhà nước, hoàn toàn yên tâm về vấn đề chủ quyền dữ liệu cũng như đáp ứng đầy đủ các quy định pháp lý khắt khe như Luật Bảo vệ Dữ liệu Cá nhân và Luật An ninh mạng. Trong bối cảnh các mối đe dọa an toàn thông tin ngày càng gia tăng, việc sở hữu một công cụ tự động giúp rà soát và "chữa bệnh" cho hạ tầng Cloud từ sớm là yêu cầu sống còn đối với mọi doanh nghiệp. Với khả năng triển khai siêu tốc dưới 10 phút, không ảnh hưởng hệ thống và đáp ứng hoàn hảo các tiêu chuẩn bảo mật Việt Nam, FPT CSPM chính là người đồng hành tin cậy trên hành trình lên Cloud an toàn và bền vững. Tìm hiểu thêm về sản phẩm tại đây: https://fptcloud.com/product/fpt-cspm-2/ Liên hệ với chúng tôi để được tư vấn chi tiết về các giải pháp, dịch vụ của FPT Cloud: Hotline: 1800 6139 Email: support@fptcloud.com Support: m.me/fptsmartcloud

Tại sự kiện công nghệ FPT Transform 2026 diễn ra ngày 17/10 diễn ra ở Hà Nội, FPT giới thiệu loạt giải pháp AI dành cho các doanh nghiệp chuyển từ giai đoạn thử nghiệm AI sang vận hành thực tế. Ông Lê Hồng Việt, phân tích thêm các cấp độ làm chủ AI phù hợp với từng doanh nghiệp, vai trò của dữ liệu và tri thức nội bộ trong tạo lợi thế cạnh tranh, cũng như cách lựa chọn mô hình, hạ tầng và phát triển năng lực công nghệ để giảm phụ thuộc vào bên ngoài. Theo ông, doanh nghiệp cần xác định mức độ làm chủ AI như thế nào để phù hợp với năng lực và mục tiêu kinh doanh?  Làm chủ AI hiện nay là yêu cầu bắt buộc với doanh nghiệp. Do đó, câu hỏi đặt ra không phải có làm hay không, mà là làm như thế nào. Mỗi tổ chức sẽ có năng lực công nghệ, nguồn lực và nhu cầu khác nhau nên cần lựa chọn mức độ làm chủ phù hợp. Doanh nghiệp có thể chia thành ba mức độ. Thứ nhất, với những đơn vị chưa có nhiều năng lực công nghệ, họ có thể bắt đầu từ các ứng dụng AI phục vụ những công việc thông dụng như mua sắm, bán hàng, nhân sự, marketing và quản trị. Ví dụ, giải pháp FPT AI EOS cho phép doanh nghiệp xây dựng các nhân sự số (digital worker) để thực hiện công việc cùng con người. Ngay cả tổng giám đốc cũng có thể tự xây dựng nhân sự số cho tổ chức của mình. Thứ hai, với những doanh nghiệp đã có nền tảng công nghệ nhưng chưa có năng lực chuyên sâu về AI, họ có thể sử dụng các nền tảng cung cấp mô hình có sẵn như FPT Token Factory. Cách tiếp cận này giúp doanh nghiệp lựa chọn mô hình phù hợp để giải quyết công việc, tối ưu chi phí và giảm gánh nặng vận hành hệ thống kỹ thuật. Thứ ba, với những công ty chuyên về AI, đã có đội ngũ kỹ sư AI, họ có thể sử dụng FPT Kubernetes Engine với GPU để tự xây dựng, lưu trữ, điều chỉnh và sử dụng mô hình theo nhu cầu. Như vậy, doanh nghiệp có thể bắt đầu từ việc sử dụng AI, sau đó, phát triển năng lực kỹ thuật để giải quyết những bài toán đặc thù. Mức độ làm chủ không nhất thiết phải giống nhau ở tất cả doanh nghiệp. Điều quan trọng là lựa chọn được cách tiếp cận phù hợp và từng bước nâng cao năng lực của mình. Doanh nghiệp cần ưu tiên những yếu tố nào để duy trì quyền chủ động về công nghệ? – Theo tôi, điều quan trọng nhất trước tiên là doanh nghiệp phải chủ động về dữ liệu. Dữ liệu tồn tại dưới hai dạng chính: dữ liệu giao dịch, thường được thể hiện bằng số liệu, và tri thức của doanh nghiệp được lưu trong các tài liệu, bản trình bày hoặc những nguồn thông tin nội bộ khác. Doanh nghiệp cần tổng hợp, làm sạch và tổ chức những dữ liệu này để cả con người lẫn AI có thể hiểu, khai thác được; sau đó, cần tiếp tục tích lũy tri thức. Đây là nền tảng để ứng dụng AI vào hoạt động và tạo ra những kết quả phù hợp với đặc thù của tổ chức. Bước tiếp theo là ứng dụng các tác nhân AI (AI Agent) để xây dựng lực lượng nhân sự số. Về lâu dài, mọi doanh nghiệp đều nên phát triển năng lực AI ít nhất đến mức kỹ thuật, đủ để xử lý những bài toán riêng của mình. Với mô hình và hạ tầng, doanh nghiệp cần lựa chọn phương án phù hợp với năng lực, yêu cầu sử dụng và mức độ kiểm soát mong muốn. Việc tự xây dựng mô hình đòi hỏi nguồn lực và chuyên môn cao, nên doanh nghiệp có thể khai thác các mô hình có sẵn trước khi tiến tới tự phát triển nếu cần thiết. Ở góc độ rộng hơn, làm chủ công nghệ còn gắn với chủ quyền công nghệ. Theo tôi, điều đó có nghĩa là ngay cả khi một quốc gia khác ngừng cung cấp công nghệ, hoạt động và quá trình phát triển của chúng ta vẫn có thể tiếp tục. Để đạt được mục tiêu này, Việt Nam cần có năng lực tự phát triển công nghệ, đồng thời tiếp nhận và cải tiến những công nghệ do cộng đồng xây dựng. Khi nhiều doanh nghiệp cùng sử dụng các mô hình AI có sẵn, yếu tố nào tạo nên lợi thế cạnh tranh riêng? – Để tự xây dựng và sử dụng mô hình AI riêng, doanh nghiệp cần năng lực rất cao. Khoảng 90-95% doanh nghiệp sẽ sử dụng các mô hình có sẵn từ những nền tảng cung cấp dịch vụ trong nước hoặc quốc tế. Điều này hoàn toàn bình thường, tương tự việc doanh nghiệp lựa chọn nhà cung cấp điện hay internet đáp ứng các tiêu chí của mình. Lợi thế cạnh tranh lớn nhất đến từ bí quyết và tri thức riêng của doanh nghiệp được tích lũy thành các thư viện tri thức. Khi xây dựng một AI Agent, những hướng dẫn đưa vào hệ thống cần được thiết kế bởi chính các chuyên gia của doanh nghiệp, dựa trên triết lý kinh doanh và cách thức hoạt động của tổ chức. Những hướng dẫn này định hình cách AI thực hiện công việc trong suốt quá trình vận hành. Vì vậy, dù hai doanh nghiệp có thể cùng sử dụng một mô hình nền tảng, cách AI xử lý công việc vẫn có thể khác nhau dựa trên tri thức, kinh nghiệm và hướng dẫn riêng của từng bên. Để tự làm chủ AI, doanh nghiệp cần cả một hệ sinh thái công nghệ. Họ có thể tận dụng các nền tảng trong nước và quốc tế để đưa AI vào nhiều công đoạn hoạt động trước, sau đó mới tiến tới tự phát triển AI. Theo tôi, doanh nghiệp cần làm chủ được việc ứng dụng AI vào hoạt động của mình, rồi từng bước nâng cao năng lực xây dựng công nghệ riêng. Ba sản phẩm FPT AI EOS, FPT Token Factory và FPT Kubernetes Engine với GPU vừa được FPT giới thiệu tại FPT Transform 2026 giải quyết những nhu cầu nào trong quá trình phát triển AI? – Ba sản phẩm được phát triển để đáp ứng những mức độ năng lực công nghệ khác nhau, đồng thời, kết nối các lớp trong quá trình đưa AI vào vận hành. Ở lớp ứng dụng, FPT AI EOS hỗ trợ doanh nghiệp xây dựng và vận hành các nhân sự số làm việc cùng con người. Thay vì chỉ phản hồi từng yêu cầu riêng lẻ, nhân sự AI có thể tham gia xuyên suốt quy trình, theo dõi công việc và phối hợp với các hệ thống doanh nghiệp đang sử dụng. Những quyết định quan trọng vẫn có thể được chuyển cho con người phê duyệt. Với lớp khai thác mô hình, FPT Token Factory cung cấp cổng truy cập thống nhất tới nhiều mô hình AI, gồm mô hình quốc tế, mô hình mở và các năng lực AI do FPT vận hành tại Việt Nam và Nhật Bản. Tùy yêu cầu về quy mô, hiệu năng và dữ liệu, doanh nghiệp có thể lựa chọn phương thức sử dụng phù hợp. Điều này giúp giảm sự phân mảnh khi phải làm việc với nhiều mô hình và nhà cung cấp khác nhau. Cuối cùng, ở lớp hạ tầng, FPT Kubernetes Engine với GPU cung cấp môi trường phục vụ các công việc AI từ huấn luyện, tinh chỉnh đến triển khai mô hình. Tài nguyên có thể mở rộng theo nhu cầu, đi kèm các công cụ quản trị, giám sát và bảo mật. Nhờ đó, đội ngũ phát triển có thể tập trung hơn vào sản phẩm thay vì phải tự xây dựng và vận hành toàn bộ hạ tầng GPU. Khi kết nối ba lớp này, doanh nghiệp có thể lựa chọn cách tiếp cận phù hợp, từ sử dụng ứng dụng AI, khai thác mô hình có sẵn đến tự phát triển và triển khai mô hình trên hạ tầng đáp ứng yêu cầu. Đây là cách chúng tôi xây dựng hệ sinh thái AI – Cloud – Data, giúp doanh nghiệp linh hoạt lựa chọn từng lớp theo nhu cầu và năng lực của mình. Theo ông, khó khăn lớn nhất của doanh nghiệp khi đưa AI từ thử nghiệm vào vận hành thực tế? – Khó khăn lớn nhất khi đưa AI vào vận hành là ý chí của lãnh đạo. AI là lĩnh vực còn mới. Nếu doanh nghiệp yêu cầu phải chứng minh hiệu quả đầu tư rồi mới cho phép thử nghiệm, quá trình ứng dụng sẽ gặp khó khăn vì chưa có đủ lịch sử để đánh giá. Doanh nghiệp cần thử nghiệm trước, có kết quả rồi mới đánh giá, cũng như chấp nhận một mức độ rủi ro nhất định để bắt đầu. Bên cạnh đó, doanh nghiệp cần thay đổi quy trình. Nếu chỉ đưa AI vào quy trình hiện tại và yêu cầu công nghệ làm việc giống hệt con người, khả năng thành công sẽ không cao. Khi AI làm thay đổi cách nhìn về năng lực và phương thức thực hiện công việc, quy trình cũng cần điều chỉnh để thích ứng. Chúng ta phải khai thác những điểm mạnh của trí tuệ nhân tạo, thay vì chỉ yêu cầu công nghệ bắt chước cách con người đang làm. Việc giám sát AI cũng cần được tính đến ngay từ đầu. Với những công cụ phù hợp, người quản lý có thể theo dõi chi tiết hệ thống đã và đang thực hiện công việc gì. Ví dụ, FPT AI EOS cho phép doanh nghiệp giám sát hoạt động của nhân sự số, đồng thời xác định những công việc cần chuyển cho con người kiểm soát. Điều này tạo điều kiện để doanh nghiệp ứng dụng AI vào nhiều công đoạn mà vẫn duy trì quyền giám sát đối với các quyết định quan trọng. Cuối cùng, hiệu quả của AI vẫn cần được đánh giá theo những tiêu chí kinh doanh cơ bản: doanh số có tăng trưởng không, lợi nhuận có tăng không và năng suất lao động có cải thiện không. Việc đánh giá không khác với các khoản đầu tư thông thường, nhưng cách triển khai và quyết tâm của doanh nghiệp sẽ quyết định kết quả. Hệ sinh thái AI – Cloud – Data cần phát triển như thế nào để doanh nghiệp Việt Nam tăng năng lực tự chủ và sức cạnh tranh? – Theo tôi, năng lực làm chủ AI có hai yếu tố. Thứ nhất là năng lực sử dụng AI. Đây là khả năng mọi doanh nghiệp cần trang bị ngay từ bây giờ. Trong ngắn hạn, nếu không sử dụng AI, doanh nghiệp sẽ có nguy cơ tụt lại phía sau. Thứ hai là năng lực của cộng đồng công nghệ Việt Nam trong việc phát triển các mô hình, hạ tầng và ứng dụng riêng để giảm sự phụ thuộc vào nước ngoài. Đây là bài toán dài hạn, đòi hỏi quá trình nghiên cứu, phát triển, tiếp nhận và cải tiến công nghệ. Với FPT, chúng tôi xây dựng hệ sinh thái theo ba lớp: ứng dụng ở trên cùng, nền tảng ở giữa và phần cứng hạ tầng ở dưới. Các lớp được xây dựng trên hệ thống hạ tầng mà FPT đã đầu tư. Cách tiếp cận này giúp nhiều nhóm khách hàng lựa chọn giải pháp theo nhu cầu, từ doanh nghiệp cần ứng dụng AI nhanh chóng đến những đơn vị có đội ngũ kỹ sư muốn phát triển và vận hành mô hình riêng. Chúng tôi cũng mong muốn chia sẻ kiến thức, kinh nghiệm xây dựng và vận hành nền tảng để cộng đồng công nghệ có thể khai thác, chủ động phát triển, tùy biến và triển khai các mô hình, ứng dụng AI, phục vụ những bài toán thực tiễn. Mục tiêu là tạo điều kiện để nhiều đối tượng tham gia sáng tạo, từ kỹ sư công nghệ đến nhân sự kinh doanh và người dùng phổ thông. Về lâu dài, năng lực cạnh tranh của doanh nghiệp Việt Nam sẽ gắn với khả năng ứng dụng AI hiệu quả và năng lực phát triển công nghệ của chính mình. Chúng ta cần vừa tận dụng những thành tựu sẵn có, vừa từng bước xây dựng mô hình, hạ tầng và ứng dụng riêng để duy trì khả năng chủ động trong quá trình phát triển.

Từ năm 2020, FPT Cloud được xây dựng bởi hơn 400 kỹ sư Việt Nam, từ tầng hạ tầng lõi đến AI và bảo mật. Bảy bức ảnh dưới đây kể lại hành trình ấy, cùng những con số về hơn 3.000 doanh nghiệp đồng hành. Năm 2020, Tập đoàn FPT thành lập FPT Smart Cloud, giao ông Lê Hồng Việt, khi ấy là Giám đốc Công nghệ của Tập đoàn, làm Tổng Giám đốc. Cùng năm đó, FPT Cloud ra mắt thị trường. Từ hạ tầng mã nguồn mở OpenStack, hơn 400 kỹ sư Việt Nam trực tiếp vận hành và tùy biến tầng lõi, rồi từng bước xây thêm các tầng cloud-native, dữ liệu, AI và bảo mật, tạo nên bộ gần 100 dịch vụ. Trên nền đó, FPT AI Factory cùng NVIDIA phát triển hơn 3.000 GPU, vận hành tại Việt Nam và Nhật Bản. Song song, tháng 8/2025, Bộ Công an xác nhận FPT Cloud đáp ứng An toàn hệ thống thông tin Cấp độ 4, còn FPT AppSec đạt giải Cybersecurity Excellence Awards 2026. Nhờ vậy, hơn 3.000 doanh nghiệp đã đồng hành cùng FPT Cloud, với chi phí đầu tư, vận hành giảm 30% so với mô hình on-premise. Hạ tầng đạt Tier III, SLA 99,99%, vận hành tại ba vùng. Từ đó, FPT Cloud hướng tới mở rộng khách hàng và doanh thu quốc tế.

Deploy tăng 30%, rollback tăng 50%: thay đổi tư duy đọc DORA metrics khi việc tạo code quá nhanh và dễ dàng với AI  AI đang được sử dụng để viết code ngày càng nhiều, tốc độ cũng ngày càng nhanh. Đối với vai trò quản lý kỹ thuật hiện nay hầu hết đã từng hoặc sẽ sớm gặp tình huống này: trong hai kỳ có cùng độ dài, một dịch vụ tăng từ 100 lên 130 lần triển khai, nhưng số deployment phải rollback cũng tăng từ 10 lên 15. Người phụ trách phát triển (VP Engineering) nhận định kết quả này là một thành công: tốc độ tăng rõ rệt, còn rollback là "chi phí học hỏi" tạm thời nên cần nhân rộng mô hình ngay. Người phụ trách độ tin cậy (SRE) thì ngược lại, xem đây là tín hiệu báo động hệ thống đang xuống cấp và phải rà soát gấp trước khi có sự cố lớn.  Những tranh luận ngược chiều cho cùng kết quả tương tự này đang diễn ra ở các đội ngũ kỹ thuật khắp thế giới, từ báo cáo DORA của Google đến các bộ benchmark hàng triệu pull request.  Một người có kinh nghiệm vận hành sẽ hiểu rằng số lần triển khai tăng cùng số lần rollback chưa đủ để kết luận AI đang giúp hay làm khó đội ngũ lập trình, mà cần phân biệt lượng công việc, tỷ lệ triển khai thất bại và mức ảnh hưởng tới người dùng trước khi quyết định mở rộng. Trong ví dụ giả định bên trên, số deployment phải rollback tăng 50%, còn tỷ lệ tăng từ 10% lên 11,54%: chênh 1,54 điểm phần trăm, tương đương tăng khoảng 15,4% tương đối. Phép tính là (1,5 / 1,3 − 1) × 100%. Hai mức tăng mô tả hai khía cạnh khác nhau: tổng số lần cần xử lý và tỷ lệ deployment cần hoàn tác. Kết quả phép tính không thể hiện được bản chất của ảnh hưởng bởi vì 15 lần rollback tự động, ít tác động tới người dùng có thể tạo gánh nặng khác hẳn 10 lần khôi phục kéo dài.   Để đánh giá hiệu quả của AI, chúng ta còn phải biết những deployment tăng thêm mang lại thay đổi gì và đội ngũ tốn bao nhiêu công sức để đưa chúng vào vận hành.  Báo cáo DORA 2025 phơi bày sự ảo tưởng về năng suất khi dùng AI  Báo cáo DORA 2024 1 đi ngược kỳ vọng của nhóm nghiên cứu: cứ mỗi 25% tăng mức áp dụng AI đi kèm mức giảm ước tính 1,5% ở throughput (tốc độ/lưu lượng bàn giao) và 7,2% ở delivery stability (độ ổn định phân phối). Trong khi AI giúp tăng năng suất cá nhân (viết code, làm tài liệu), nó lại gây tắc nghẽn ở quy trình kiểm thử/review và đưa code lên hệ thống thật, dẫn tới tốc độ bàn giao chung bị chậm đi nhẹ và độ lỗi/bất ổn định tăng lên.  Báo cáo DORA 2025 (State of AI-assisted Software Development)2 ghi nhận bước ngoặt lớn: việc áp dụng AI đã thực sự giúp tăng tốc độ bàn giao (throughput chuyển từ âm sang dương). Tuy nhiên, mức áp dụng AI vẫn tỉ lệ thuận với tỷ lệ thất bại khi thay đổi (CFR), nghĩa là AI giúp làm nhanh hơn nhưng hệ thống vẫn kém ổn định như trước.   Một năm nâng cấp công cụ AI giúp tăng tốc bàn giao nhưng lại không giảm bớt lỗi hệ thống, chứng minh rằng nguyên nhân không nằm ở chất lượng công cụ kém hoặc lỗi do lập trình viên “chưa quen tay", mà do quy trình vận hành hiện tại có lỗ hổng về mặt kiến trúc.  Bất ổn luôn tồn tại nếu quy trình vận hành kiểm thử của con người không theo kịp tốc độ viết code của AI  Trước khi có AI, viết code là khâu tốn thời gian nhất (bottleneck). Lập trình viên mất nhiều giờ suy nghĩ, viết từng dòng nên họ hiểu rất rõ logic code của mình. Khi họ tạo PR (Pull Request), dung lượng PR nhỏ và dễ review. Khi đưa AI vào làm việc, AI giúp sinh hàng trăm dòng code chỉ trong vài giây. Tuy nhiên, quy trình review code (kiểm thử tự động, đọc hiểu logic, đánh giá bảo mật, chạy thử) vẫn tốn dung lượng bộ nhớ/thời gian suy nghĩ của con người. Việc bơm một lượng code cực lớn vào một quy trình kiểm duyệt có năng lực giới hạn sẽ tự động tạo ra nút nghẽn (bottleneck) mới và bỏ sót lỗi ra môi trường thật. Dữ liệu benchmark độc lập của LinearB (báo cáo benchmark 2026), phân tích 8,1 triệu pull request từ khoảng 4.800 team kỹ thuật tại 42 quốc gia, chỉ đích danh nút nghẽn. PR có AI hỗ trợ chỉ đạt tỷ lệ merge 32,7% trong 30 ngày, so với khoảng 84,5% của PR người viết. Thời gian chờ được review dài gần 5 lần (khoảng 960 phút so với ~200 phút), và PR cũng lớn hơn hẳn: từ 400 dòng trở lên so với 157 dòng ở phân vị 75. Chi phí tạo code đã sụp xuống, còn chi phí kiểm chứng thì không.  Bản chất Mô hình Ngôn ngữ Lớn (LLM): AI sinh code bằng cách dự đoán từ tiếp theo dựa trên xác suất, không phải bằng tư duy logic hệ thống. Code do AI tạo ra có thể trông rất "mượt" và chạy đúng ở các case cơ bản (happy path), nhưng dễ bỏ qua các trường hợp biên (edge cases), ngoại lệ bảo mật hay tính tương thích với hạ tầng hiện có. Nếu đưa AI vào quy trình theo kiểu "ủy thác viết code" mà không nâng cấp quy trình kiểm thử tương ứng, hệ thống sẽ liên tục dung nạp các đoạn code tiềm ẩn lỗi ngầm.  Việc đọc hiểu và phát hiện lỗi trong 500 dòng code do AI viết tốn nhiều năng lượng não bộ hơn rất nhiều so với việc review code do đồng nghiệp tự tay viết. Chính DORA chỉ ra cơ chế: thời gian tiết kiệm ở khâu viết code đã bị dồn sang khâu đánh giá và kiểm chứng, khi có tới 30% kỹ sư thừa nhận họ ít hoặc không tin tưởng code do AI sinh ra.3 Khi xảy ra sự cố trên môi trường vận hành thực tế (production), kỹ sư trực ca (SRE/DevOps) phải sửa những dòng code mà chính họ không hề viết từ đầu, điều này làm kéo dài thời gian xử lý sự cố.   Tóm lại, Bất ổn định là thuộc tính cấu trúc vì chúng ta đang dùng công cụ của kỷ nguyên AI (sinh code cực nhanh) nhưng lại chạy trên quy trình vận hành của kỷ nguyên cũ (review và test thủ công/bằng con người). Nếu chỉ đẩy mạnh dùng AI để tạo code mà không thay đổi cấu trúc quy trình (như tự động hóa test, chia nhỏ PR, tăng cường AI review), thì tốc độ tăng đến đâu, rủi ro và bất ổn sẽ tăng tương ứng đến đó.   Thay đổi tư duy đọc DORA Metrics từ “đo KPI" sang “đo nút nghẽn"  Trong bộ 4 chỉ số DORA (2 chỉ số Tốc độ + 2 chỉ số Ổn định), công cụ AI chỉ tác động trực tiếp và làm tăng tức thì đúng 1 chỉ số duy nhất là Tần suất triển khai (Deployment Frequency).   Chỉ số AI tác động qua kênh nào? Chiều tác động Độ trễ trước khi chỉ số nói thật Tần suất triển khai (Deploy frequency) Trực tiếp: chi phí tạo code giảm thì số thay đổi và số lần deploy tăng gần như tự động Tăng ngay khi bật AI assistant, chưa cần biết code tốt hay xấu. Không có độ trễ - đây chính là gốc rễ của ảo tưởng về năng suất của AI. Thời gian hoàn thành (Lead time for changes) Gián tiếp: thời gian viết code rút ngắn lại nhưng thời gian review và kiểm chứng kéo dài, bị nghẽn lại Hai lực ngược chiều triệt tiêu nhau; con số tổng dễ đứng yên, che đậy sự dịch chuyển nút nghẽn. Số trung bình che đậy độ lệch, phải tách pha viết và pha review mới thấy. Tỷ lệ lỗi / Tỷ lệ làm lại (Change failure rate / Rework rate) Gián tiếp: Phản ánh qua chất lượng thực tế của code khi chạy trên Production. Tăng tỉ lệ thuận khi khối lượng code AI chưa kiểm soát bùng nổ. Trễ từ một đến vài chu kỳ release. Thời gian khôi phục dịch vụ (MTTR) Gián tiếp: Phản ánh năng lực đọc hiểu và làm chủ hệ thống của kỹ sư lúc xảy ra sự cố. Nguy cơ kéo dài: Kỹ sư trực ca phải sửa những dòng code do AI viết mà họ chưa từng đọc kỹ. Trễ nhất, chỉ bộc lộ khi có sự cố lớn xảy ra trên Production.  Bảng phân tích trên giải thích lý do vì sao dashboard ở các buổi review quý thường tạo ra hai góc nhìn trái ngược.   AI không làm cho DORA metrics vô dụng, nhưng nó bắt chúng ta phải thay đổi hoàn toàn cách đọc. Đọc DORA thời AI không phải để đếm xem team bận rộn ra sao, mà là để nhận diện nút nghẽn đã dịch chuyển về đâu và ngăn chặn rủi ro sập hệ thống trước khi quá trễ. Để nhận diện đúng sức khỏe hệ thống, quản lý kỹ thuật cần thay đổi tư duy khi phân tích báo cáo:  Tuyệt đối không đọc đơn độc chỉ số Tốc độ (Deployment Frequency / Lead Time): Bắt buộc phải đọc sóng đôi với Chỉ số Ổn định (Change Failure Rate, hoặc Rework Rate — chỉ số bổ trợ ngoài bộ 4 chỉ số DORA) trên cùng một màn hình quan sát. Việc tách rời hai nhóm chỉ số này sẽ tạo ra "ảo tưởng về tốc độ", che đậy rủi ro tích tụ ở khâu kiểm thử.  Tách bạch nguồn dữ liệu (AI vs. Non-AI): Bắt buộc phải đo lường riêng biệt các PR có AI hỗ trợ và PR do con người tự viết hoàn toàn. Nếu gộp chung, lãnh đạo sẽ liên tục rơi vào bẫy "nhiễu" số liệu - nơi các chỉ số trung bình làm mờ đi bản chất vấn đề như ví dụ tranh luận ở đầu bài.  Áp dụng vào hệ thống của bạn:   Hãy mở dashboard quản lý hiện tại và đếm xem có bao nhiêu chỉ số tốc độ đang đứng đơn độc mà không có chỉ số ổn định đi kèm. Con số đó sẽ cho bạn biết hệ thống đang thực sự đo sức khỏe vận hành, hay chỉ đang "đếm dòng code" cùng AI.  Nhận diện được nút nghẽn mới chỉ là bước đầu tiên. Làm sao để điều chỉnh quy trình kiểm thử và review code để giải phóng nút nghẽn này mà không làm chậm tốc độ của đội ngũ? Chúng ta sẽ cùng giải bài toán này ở bài viết tiếp theo: "Tái cấu trúc quy trình vận hành khi AI tham gia viết code: 3 nguyên tắc bắt buộc".  Nguyễn Phương Lan  Trưởng Phòng Điều Hành Sản Xuất FPT Cloud  Câu hỏi thường gặp  DORA metrics là gì?  DORA (DevOps Research and Assessment) là chương trình nghiên cứu của Google về hiệu năng phân phối phần mềm, với bốn chỉ số kinh điển gồm:  Tần suất triển khai (deploy frequency)   Thời gian từ commit đến production (lead time for changes)  Tỷ lệ thay đổi gây lỗi trên production (change failure rate)  Thời gian khôi phục sau sự cố (MTTR; DORA gần đây đổi tên thành Failed deployment recovery time)  Rework rate khác change failure rate ở điểm nào?  Change failure rate đếm tỷ lệ thay đổi gây ra sự cố chính thức trên Production (Môi trường thực tế). Rework rate đếm tỷ lệ deploy sinh ra chỉ để sửa hệ quả của đợt deploy trước, nên nó bắt được cả những lần sửa chữa ngầm không đi kèm báo cáo sự cố. Với code AI, Rework rate nhạy hơn vì phần lớn chi phí ẩn nằm ở việc phải sửa đi sửa lại.  Làm sao biết bao nhiêu phần trăm code do AI viết?  Gắn nhãn tại nguồn (Tagging at source): thông qua IDE Plugin, PR Label (Nhãn trên Pull Request) hoặc Commit Trailer ngay từ lúc tạo thay đổi. Các phương pháp Retrospective Estimation (Ước lượng hồi tố) bằng cảm nhận hay khảo sát đều không đủ tin cậy để đưa vào chỉ số vận hành.  

FPT Cloud, nền tảng điện toán đám mây thuộc FPT Smart Cloud, Tập đoàn FPT công bố vùng hạ tầng mang tên Zone Thủ Đức, là vùng hạ tầng thứ hai của FPT Cloud tại TP.HCM và thứ tư tại Việt Nam, được xây dựng trên nền tảng nguồn mở OpenStack do kỹ sư Việt Nam vận hành và làm chủ đến tầng lõi. Vùng hạ tầng bổ sung tài nguyên tính toán, lưu trữ và lựa chọn dự phòng dữ liệu trong nước cho doanh nghiệp. Trong hệ thống điện toán đám mây, mỗi vùng hạ tầng độc lập, gồm tài nguyên máy chủ, lưu trữ và kết nối mạng được gọi là Zone. Zone Thủ Đức đặt tại Trung tâm Dữ liệu FPT Fornix HCM02, Khu Công nghệ cao TP.HCM giúp doanh nghiệp triển khai ứng dụng gần nơi hoạt động, mở rộng tài nguyên, tối ưu độ trễ và xây dựng phương án dự phòng dữ liệu trong nước. Với việc mở rộng này, quy mô hạ tầng FPT Cloud đạt 5.000 máy chủ vật lý, vận hành hàng trăm nghìn máy chủ ảo cùng năng lực lưu trữ đạt mức hàng trăm Petabyte (PB). Nền tảng đáp ứng đa dạng các hình thức lưu trữ từ Block, Object đến High-Performance Storage, sẵn sàng xử lý đa dạng  tải công việc (workload) từ các hệ thống nghiệp vụ cốt lõi, dữ liệu lớn (Big Data) cho đến các bài toán AI phức tạp. FPT Cloud hiện đáp ứng yêu cầu an toàn hệ thống thông tin cấp độ 4, được Bộ Công an thẩm định và phê duyệt theo Văn bản số 3810/BCA-A05. Zone Thủ Đức bắt đầu cung cấp dịch vụ từ ngày 13/04/2026, được phát triển trên nền tảng nguồn mở OpenStack do kỹ sư FPT Cloud vận hành, tuỳ biến và can thiệp đến tầng lõi. Mở rộng năng lực triển khai và dự phòng trong nước Zone Thủ Đức được trang bị toàn bộ phần cứng thế hệ 2026 nhằm mang lại hiệu năng xử lý cao cho các ứng dụng doanh nghiệp. Hạ tầng tính toán sử dụng bộ xử lý Intel thế hệ 6 và AMD thế hệ thứ 5 duy trì ổn định, hỗ trợ tối ưu chi phí cấp phép phần mềm và đảm bảo các hệ thống nghiệp vụ cốt lõi như ERP hay Core Banking vận hành mượt mà. Hệ thống lưu trữ chuyển đổi hoàn toàn sang công nghệ NVMe thế hệ mới thay thế chuẩn SSD SAS truyền thống, giúp rút ngắn tới 60% thời gian truy xuất cơ sở dữ liệu và xử lý giao dịch thời gian thực. Một điểm đáng chú ý của việc bổ sung Zone Thủ Đức là khả năng kết nối giữa các vùng hạ tầng của FPT Cloud tại TP.HCM. Tuyến liên kết nội vùng giữa các trung tâm dữ liệu tại TP.HCM đạt tổng băng thông 400Gbps với độ trễ khứ hồi 3ms. Hệ thống được triển khai trên 4 tuyến cáp quang song song hoàn toàn độc lập qua 2 nhà cung cấp viễn thông riêng biệt. Ngay cả khi một nhà cung cấp gặp sự cố diện rộng hay đứt cáp đứt đoạn, các tuyến còn lại vẫn duy trì kết nối liên tục, cho phép doanh nghiệp xây kiến trúc đa vùng (multi-Zone) và đồng bộ dữ liệu gần thời gian thực ngay trong TP.HCM. Đối với nhu cầu dự phòng thảm họa, FPT Cloud duy trì tuyến kết nối Hà Nội – TP.HCM với tổng dung lượng 80 Gbps. Doanh nghiệp có thể bố trí hệ thống chính tại một thành phố và hệ thống dự phòng tại thành phố còn lại, tạo khoảng cách địa lý cần thiết khi xây dựng phương án khôi phục sau sự cố. Tại TP.HCM, FPT Cloud có tổng băng thông kết nối Internet 100 Gbps qua nhiều nhà mạng. Với các dịch vụ và dữ liệu đặt trong nước, hệ thống kết nối nội địa giúp doanh nghiệp giảm ảnh hưởng khi đường truyền Internet quốc tế gặp sự cố. Bổ sung dịch vụ lưu trữ và năng lực xử lý AI Với hạ tầng máy chủ ảo gia tăng sức mạnh bởi GPU tại Zone Thủ Đức, doanh nghiệp dễ dàng triển khai các bài toán suy luận AI, học máy (Machine Learning) và xử lý dữ liệu lớn theo mô hình pay-as-you-go (dùng đâu trả đó). Điều này giúp các tổ chức linh hoạt mở rộng tài nguyên tính toán ngay khi phát sinh nhu cầu mà không cần gánh nặng chi phí mua sắm và bảo trì hệ thống GPU riêng. Song song với việc vận hành chính thức, FPT Cloud cũng triển khai lộ trình mở rộng các dịch vụ chuyên sâu trên nền tảng Zone Thủ Đức trong năm 2026. Cụ thể, bên cạnh dịch vụ lưu trữ đối tượng tùy chỉnh theo nhu cầu riêng (FPT Object Storage Dedicated) đã sẵn sàng, vùng hạ tầng sẽ tiếp tục bổ sung dòng lưu trữ hiệu năng cao dành riêng cho AI (FPT High Performance Storage for AI) và nâng cấp máy chủ ảo hỗ trợ giao thức IPv6 Compute, mang lại khả năng mở rộng tài nguyên mạng hướng tới gần như không giới hạn cho doanh nghiệp. “Làm chủ công nghệ theo tinh thần Make in Vietnam không chỉ giúp chúng tôi chủ động trong phát triển sản phẩm và tối ưu nguồn lực, mà còn tạo nền tảng để FPT Cloud xây dựng hạ tầng theo cách phù hợp nhất với nhu cầu của doanh nghiệp Việt Nam. Việc đưa vào vận hành FPT Cloud Zone Thủ Đức là một bước tiếp theo trong quá trình mở rộng năng lực hạ tầng Cloud trên toàn quốc. Cùng với các Zone tại Cầu Giấy, Hòa Lạc và Tân Thuận, chúng tôi đang từng bước hình thành một hạ tầng Cloud có khả năng mở rộng linh hoạt, tăng cường kết nối giữa các khu vực và hỗ trợ doanh nghiệp triển khai các phương án dự phòng ngay tại Việt Nam. Việc liên tục mở rộng các Zone không chỉ để đáp ứng nhu cầu tăng trưởng linh hoạt của khối doanh nghiệp, mà còn là cam kết của FPT Cloud trong việc xây dựng nền tảng điện toán đám mây do người Việt tự chủ. Chúng tôi hướng tới việc cung cấp một hạ tầng số an toàn, chuẩn hóa, sẵn sàng đồng hành cùng các tổ chức trong chiến lược Chuyển đổi số quốc gia và bảo đảm chủ quyền dữ liệu trên không gian mạng” ông Phan Hồng Tâm, Giám đốc Công nghệ Cloud, FPT Smart Cloud, cho biết. Sẵn sàng hạ tầng cho mùa cao điểm và kế hoạch 2027 Quý IV hàng năm là giai đoạn lưu lượng truy cập tăng đột biến trước đợt mua sắm Tết, đồng thời là thời điểm các doanh nghiệp thực hiện kiểm toán tuân thủ và hoàn thiện kế hoạch ngân sách hạ tầng cho năm 2027. Việc đưa vùng hạ tầng Thủ Đức vào vận hành cung cấp nguồn dung lượng hạ tầng sẵn sàng cao tại TP.HCM, cho phép các tổ chức chủ động thử nghiệm khả năng chịu tải, diễn tập phương án khôi phục thảm họa (DR) và mở rộng tài nguyên tính toán từ sớm.  Các gói dịch vụ tính toán, lưu trữ hiệu năng cao và hạ tầng hỗ trợ AI tại Zone Thủ Đức hiện đã sẵn sàng cấp phát. Doanh nghiệp có thể đăng ký trải nghiệm và nhận tư vấn giải pháp kỹ thuật chi tiết tại web vùng hạ tầng chính thức fptcloud.com. Liên hệ với chúng tôi để được tư vấn chi tiết về các giải pháp, dịch vụ của FPT Cloud: Hotline: 1800 6139 Email: support@fptcloud.com Support: m.me/fptsmartcloud

Ngày 19/06/2026, AWS đưa Local Zone Hà Nội vào vận hành chính thức1. Hạ tầng này giải quyết đúng hai việc AWS công bố: độ trễ mili giây một chữ số cho workload hướng người dùng trong nước, và lưu trữ dữ liệu tại chỗ để đáp ứng yêu cầu residency. Đây chưa phải một AWS Region đầy đủ tại Việt Nam: Local Zone là phần mở rộng của parent Region Singapore và chỉ cung cấp một tập dịch vụ nhất định.2 Một hạ tầng có Control Plane phụ thuộc ra nước ngoài thì dù dữ liệu ở Hà Nội vẫn chưa thể coi là sovereign cloud hoàn toàn. Nhưng chính cấu hình này đã tạo ra một bài kiểm tra áp lực chiến lược (stress test) đáng đưa vào kế hoạch hạ tầng 3-5 năm: nếu trong tương lai một hyperscaler mở full Region tại Việt Nam, nhà cung cấp trong nước còn khác biệt ở đâu ngoài vị trí dữ liệu?  Động lực thị trường cho sovereign cloud đang tăng. Gartner ước tính chi tiêu IaaS sovereign cloud toàn cầu đạt 80 tỷ USD năm 2026, tăng 35,6%; riêng châu Á - Thái Bình Dương mới nổi tăng 76%, và hãng dự báo một phần workload sẽ dịch chuyển từ nhà cung cấp toàn cầu sang nhà cung cấp địa phương.3 Bất kể kịch bản full Region tại Việt Nam xảy ra khi nào, Local Zone Hà Nội đã đủ để buộc các quyết định phân bổ ngân sách cloud nội địa phải dựa trên nhiều yếu tố hơn thay vì chỉ xét đến vị trí đặt dữ liệu.  Lưu trữ dữ liệu tại chỗ mới chỉ là điểm bắt đầu, chưa phải toàn bộ bài toán chủ quyền  Khung pháp lý Việt Nam không quy định chung chung rằng 'mọi dữ liệu phải ở trong nước', mà phân loại cụ thể theo từng loại dữ liệu và chủ thể:    Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 (hiệu lực 01/01/2026)4 và Nghị định 356/2025/NĐ-CP đặt yêu cầu đối với hoạt động chuyển dữ liệu cá nhân xuyên biên giới, bao gồm nghĩa vụ đánh giá tác động trong các trường hợp thuộc phạm vi áp dụng.  Luật Dữ liệu số 60/2024/QH15 (hiệu lực 01/7/2025)5 thiết lập cơ chế quản lý riêng đối với dữ liệu quan trọng và dữ liệu cốt lõi, cần đánh giá trước khi chuyển/cung cấp dữ liệu ra nước ngoài.  Luật An ninh mạng số 116/2025/QH15 (hiệu lực 01/7/2026) 6 đặt ra yêu cầu về lưu trữ dữ liệu tại Việt Nam trong các trường hợp thuộc phạm vi điều chỉnh, không phải yêu cầu đồng nhất đối với mọi loại dữ liệu/workload.  Chính AWS cho thấy residency chưa đồng nghĩa với sovereignty: ngày 15/1/2026, hãng khai trương European Sovereign Cloud với pháp nhân riêng, nhân sự vận hành cư trú tại EU và hạ tầng tách biệt vật lý lẫn logic khỏi các region hiện hữu.7 Tiền lệ này cho thấy vị trí dữ liệu chỉ là một lớp của sovereignty. Nó không cho phép suy ra một full Region tương lai tại Việt Nam sẽ có cấu trúc pháp nhân, control plane hay mô hình vận hành nào; các yếu tố đó phải được kiểm tra theo thiết kế và điều khoản của từng nhà cung cấp.  Dù hyperscaler có mở full Region tại Việt Nam, hai giá trị cốt lõi của Sovereign cloud nội địa vẫn không tự mất đi.  Giá trị thứ nhất: kiến trúc may đo và tổng chi phí sở hữu dự đoán được  Hyperscaler cung cấp dịch vụ được chuẩn hóa ở quy mô toàn cầu. Chuẩn hóa tạo ra quy mô và catalogue rộng, nhưng không phải mọi yêu cầu đặc thù đều được phản ánh trực tiếp trong mô hình dịch vụ và thương mại tiêu chuẩn. Trong phát biểu tại tọa đàm Vietnam Cloud & Datacenter Convention 2026, tôi nêu ngân hàng, tài chính và khu vực công là những nhóm có thể cần kiến trúc hybrid thiết kế theo hiện trạng và mô hình thương mại linh hoạt hơn. Flexera ghi nhận 73% tổ chức đang vận hành hybrid cloud trong báo cáo State of the Cloud 2026: Hybrid Cloud không phải là trạng thái quá độ tạm thời, mà là mô hình kiến trúc đích của các tập đoàn lớn.  Trong phần stress test tại Vietnam Cloud & Datacenter Convention 2026, tôi nêu ba yếu tố FPT Cloud hướng tới để khớp với nhu cầu đó: SLA tùy chỉnh theo thỏa thuận, khả năng đáp ứng yêu cầu chủ quyền dữ liệu tại địa phương ngay trong dịch vụ, và chi phí tối ưu không kèm phí egress khó dự đoán hay phí ẩn.  Cấu phần chi phí cần đọc kỹ hơn bảng giá niêm yết. Flexera 2026 đo lãng phí cloud ở mức 29%; 76% doanh nghiệp lớn trong khảo sát chi trên 5 triệu USD mỗi tháng cho public cloud. 8 Ở quy mô Enterprise, chi phí Cloud đủ lớn và phức tạp để TCO 3 - 5 năm bắt buộc phải tính thêm data movement, egress, connectivity, integration, migration và nhân sự vận hành. Trong kiến trúc hybrid, lưu lượng trao đổi giữa cloud và hệ thống hiện hữu có thể trở thành một cấu phần biến động đáng kể; vì vậy doanh nghiệp cần mô hình hóa các kịch bản traffic thay vì chỉ đọc bảng giá niêm yết.  Giá trị thứ hai: Last-Mile Integrator và trách nhiệm vận hành đầu-cuối  Chiến lược tối ưu không phải là cạnh tranh hạ tầng, mà là đóng vai trò 'Last-Mile Integrator' -  cầu nối giúp doanh nghiệp giữ các workload cốt lõi trên hạ tầng sovereign nội địa, đồng thời kết nối an toàn với các dịch vụ AI nâng cao của Hyperscaler.  Điểm khác biệt nằm ở trách nhiệm, không nằm ở sơ đồ. Khi sự cố vắt trải dài qua các hạ tầng khác nhau, câu hỏi quan trọng không chỉ là dịch vụ nào đang lỗi mà là ai chịu trách nhiệm đưa service trở lại trạng thái hoạt động. Một đầu mối chịu trách nhiệm toàn tuyến chỉ có giá trị nếu phạm vi đó được thể hiện rõ trong SLA, RACI, escalation path và điều khoản hợp đồng; nếu cuối cùng khách hàng vẫn phải tự phân xử giữa nhiều ticket theo ranh giới sản phẩm, việc tích hợp mới chỉ dừng lại ở mặt sơ đồ kiến trúc (topology) chứ chưa giải quyết được bài toán vận hành thực tế. Giá trị của nhà cung cấp nội địa vì thế phải được chứng minh bằng khả năng thực thi tại chỗ và chịu trách nhiệm xuyên môi trường, không phải bằng tuyên bố "local" đơn thuần.  Ba câu hỏi trước khi phân bổ lại ngân sách cloud  Doanh nghiệp nên ra quyết định dựa trên đặc tính của từng danh mục workload, thay vì phụ thuộc vào thương hiệu của nhà cung cấp. Ba câu hỏi cần trả lời bằng số liệu trước khi ký cam kết dài hạn:  Control boundary nằm ở đâu? Workload nào thực sự có yêu cầu về vị trí lưu trữ, xử lý, quyền truy cập hoặc control plane; căn cứ đó đến từ luật, quy định ngành hay chính sách risk nội bộ?  Tổng chi phí sở hữu 3-5 năm của từng phương án là bao nhiêu khi tính đủ compute, storage, data movement/egress, tích hợp, kết nối, migration và nhân sự vận hành? Biến số nào khó dự báo nhất?  Accountability boundary nằm ở đâu? Khi sự cố vắt qua ranh giới các môi trường, ai chịu trách nhiệm phục hồi service đầu-cuối, và cam kết đó nằm ở SLA, RACI hoặc điều khoản nào của hợp đồng?  Doanh nghiệp cần rà soát bản chất của từng workload theo ba câu hỏi trên có thể làm việc trực tiếp với đội ngũ solution architect của FPT Cloud để nhận đánh giá kiến trúc và mô hình chi phí cho từng nhóm hệ thống. Đặt lịch tư vấn tại đây:   Nội dung bài viết là thông tin kỹ thuật và tham khảo pháp lý, không phải tư vấn pháp lý.  Trương Văn Quang Kiến trúc sư giải pháp (Solution Architect), FPT Cloud 

Báo cáo OWASP GenAI LLM Top 10 2026 (OWASP - Open Worldwide Application Security Project, tổ chức quốc tế phi lợi nhuận về bảo mật ứng dụng) xác nhận: Prompt Injection tiếp tục đứng ở vị trí LLM01 đối với ứng dụng mô hình ngôn ngữ lớn (LLM). Điểm đáng chú ý của bản 2026 không phải là kỳ vọng "lọc sạch" prompt độc hại, mà là chuyển trọng tâm sang thiết kế hệ thống để giới hạn hậu quả khi mô hình bị đánh lừa.1  "Đừng cố xây dựng một mô hình không thể bị đánh lừa. Hãy xây hệ thống xung quanh nó để khi mô hình bị đánh lừa - và điều đó sẽ xảy ra - không có gì quan trọng bị phá vỡ."2  Câu hỏi kỹ thuật đặt ra: nếu không thể chặn triệt để prompt injection ở tầng đầu vào, kiến trúc phải thay đổi ở đâu để một ca tấn công thành công chỉ gây thiệt hại trong phạm vi lường trước?  Bài toán dữ liệu sự cố và sự thất bại của bộ lọc đầu vào  Báo cáo năm 2026 dựa trên phân tích 7.714 sự cố an ninh AI thực tế trong đó 6.639 sự cố đủ chi tiết để phân loại.3 Dữ liệu cho thấy sự dịch chuyển rõ rệt khi thiệt hại không còn nằm ở nội dung LLM tạo ra, mà ở hành động AI Agent thực thi, hạng mục excessive agency (trao quyền quá mức) tăng lên vị trí thứ 3.  Nguyên nhân bộ lọc đầu vào không phải là ranh giới tin cậy  Mặc dù các API LLM hiện đại đã phân tách vai trò (system, user, tool) và huấn luyện mô hình ưu tiên chỉ dẫn hệ thống, đây thuần túy là hành vi học được (learned behavior) thay vì một ranh giới cưỡng chế (enforced boundary). LLM vẫn xử lý cả câu lệnh lẫn dữ liệu truy xuất trên cùng một không gian ngữ cảnh xác suất (probabilistic context window), do đó hoàn toàn thiếu một trust boundary đúng nghĩa ở tầng giao thức. Khác với SQL injection nơi parameterized queries phân tách tuyệt đối mã lệnh và dữ liệu về mặt cú pháp, LLM chưa tồn tại cơ chế phòng ngự tương đương có tính tổng quát. Tài liệu OWASP thừa nhận chưa rõ có tồn tại phương pháp phòng ngừa tuyệt đối hay không. 4  Thực nghiệm độc lập năm 2025 trên 6 hệ guardrails thương mại và mã nguồn mở cho thấy kết quả đồng nhất: kỹ thuật giấu chỉ dẫn trong Emoji qua mặt bộ lọc với tỷ lệ 100%; ký tự Unicode đặc biệt vượt rào trên 90%; và không có giải pháp nào chống chịu được toàn bộ các kỹ thuật tấn công. Ngay cả ProtectAI v2 - giải pháp cải thiện mạnh nhất ở nhóm giấu ký tự (giảm tỷ lệ lọt từ 77,32% xuống 20,26%) vẫn để lọt hơn 1/5 số mẫu prompt injection trong chính nhóm này. 5  EchoLeak (CVE-2025-32711) trên Microsoft 365 Copilot là minh chứng thực tế cho indirect prompt injection trên hệ thống production. Kẻ tấn công chỉ cần gửi một email được chế tác để vượt bộ phân loại XPIA; khi Copilot về sau truy xuất email đó trong một truy vấn bình thường, chuỗi khai thác có thể khiến Copilot đưa dữ liệu nhạy cảm vào một URL/tham chiếu hình ảnh và tạo yêu cầu ra ngoài. Điểm quan trọng là đây là kịch bản zero-click: nạn nhân không cần mở hoặc bấm vào email độc hại; việc sử dụng Copilot bình thường có thể đủ để kích hoạt chuỗi tấn công.  Bảng 1. Lọc đầu vào: dùng để làm gì và không nên kỳ vọng gì  Lọc đầu vào LÀM ĐƯỢC Lọc đầu vào KHÔNG làm được Giảm nhiễu và chi phí: chặn một phần mẫu tấn công đã biết hoặc ít tinh vi trước khi đi vào các lớp xử lý sâu hơn. Tạo bảo đảm an toàn hoặc trust boundary: mẫu mới, biến thể/adaptive attack và dữ liệu gián tiếp vẫn có thể vượt qua. Tạo tín hiệu giám sát: log các mẫu bị chặn cho thấy ai đang thử tấn công Thay thế kiểm soát quyền: khi mẫu lọt qua thì mô hình vẫn giữ nguyên toàn bộ quyền được cấp Tăng chi phí tấn công và bổ sung cho model hardening, output checking, red teaming. Tạo miễn nhiễm với indirect/cross-modal prompt injection: EchoLeak cho thấy classifier chuyên dụng vẫn có thể bị bypass.  Tổ hợp "Lethal Trifecta" và nguyên lý Blast Radius  Theo Simon Willison, rủi ro lớn nhất xảy ra khi một AI Agent hội đủ 3 yếu tố mà ông gọi là “bộ ba chết người" (Lethal Trifecta) bao gồm:  Truy cập dữ liệu nhạy cảm/nội bộ.  Tiếp nhận/xử lý dữ liệu không tin cậy từ bên ngoài (email, web, file).  Có kênh giao tiếp hoặc gửi dữ liệu ra môi trường ngoài.  Khi cả 3 yếu tố hội tụ trong cùng một context, một ca injection thành công đồng nghĩa với sự cố rò rỉ dữ liệu (data exfiltration). Vì thế khi thiết kế kiến trúc bảo mật cho AI Agent cần đặt mục tiêu thu hẹp tối đa blast radius (Phạm vi thiệt hại) khi Agent bị chiếm quyền điều khiển.  Kiến trúc bảo mật phòng thủ chiều sâu (Defense-in-Depth)  Tầng 1: Tách biệt danh tính (workload identity)  Khoảng trống phổ biến là để AI Agent sử dụng trực tiếp session/token của end-user hoặc một service account có phạm vi quyền quá rộng. Đây không mặc nhiên là "privilege escalation"; vấn đề là agent có thể thừa hưởng tập quyền hiệu lực quá lớn so với nhiệm vụ cần thực hiện. Nếu bị prompt injection, phạm vi thiệt hại có thể mở rộng tới toàn bộ tài nguyên mà token đó truy cập được.  Kiến trúc đề xuất: cấp workload identity riêng cho runtime của từng agent hoặc từng nhóm tác vụ. Khi agent hành động thay người dùng, sử dụng cơ chế on-behalf-of/scoped delegation với token ngắn hạn và downscope. Quyền thực tế nên là giao của ba lớp: quyền người dùng, capability được cấp cho agent và policy của tài nguyên; tuyệt đối không đưa raw user token vào prompt/context.  Quản lý credential: ưu tiên workload identity/federation và token ngắn hạn thay cho API key tĩnh. Secret còn cần thiết phải lưu trong vault và chỉ được tool runner/broker lấy tại thời điểm thực thi. LLM chỉ tạo ý định hoặc tool call; credential không được xuất hiện trong prompt, model context, log hoặc output của mô hình.  Tầng 2: Sandbox Tool-Calling - LLM đề xuất, Broker thực thi  Áp dụng nguyên tắc cô lập: LLM không gọi API trực tiếp, chỉ đề xuất cấu trúc gọi lệnh (intent declaration). Một Broker độc lập nhận khai báo từ LLM, thẩm định tham số (input schema validation), áp dụng danh sách cho phép (allowlist) cho kết nối mạng của từng công cụ, và khởi chạy tác vụ trong môi trường cách ly (sandbox) với quyền truy cập tệp và mạng bị giới hạn.7  Tầng 3: Tách biệt luồng tin cậy (mô hình CaMeL của Google DeepMind)  Kiến trúc CaMeL (2025) của Google DeepMind tách đôi vai trò của mô hình: một mô hình đặc quyền (Privileged Model) nhận yêu cầu của người dùng và lập kế hoạch nhưng không bao giờ đọc dữ liệu không tin cậy, còn một mô hình cách ly (Isolated Model) đọc dữ liệu không tin cậy nhưng không được gọi công cụ, API.  Mỗi biến dữ liệu mang nhãn nguồn gốc (data lineage tagging), và chính sách dòng dữ liệu (data flow policy) quyết định nguồn nào được phép chảy vào hành động nào.8  Tầng 4: Con người kiểm soát đầu ra & phê duyệt tác động (Human-in-the-Loop)  Mọi thứ LLM sinh ra cần được đối xử như đối với dữ liệu không tin cậy (Untrusted Output): kiểm tra, mã hoá và làm sạch (encode/sanitize) trước khi hiển thị hoặc đưa vào luồng xử lý tiếp theo.   Với các hành động đặc quyền làm thay đổi hệ thống production, nhất là các hành động không thể khôi phục thì con người luôn phải là chốt chặn kiểm soát cuối cùng.  Tại FPT Cloud, các agent phân tích dữ liệu hiện được giới hạn ở tác vụ đọc/tổng hợp; các hành động làm thay đổi production như chặn IP, vô hiệu hóa tài khoản, thay đổi firewall hoặc xóa dữ liệu chưa được phép tự động thực thi nếu chưa có phê duyệt của người có thẩm quyền. Đây là baseline an toàn phù hợp trong giai đoạn đầu; về sau chỉ nên tự động hóa các hành động low-risk, reversible và đã được policy phê duyệt trước.  Bảng kiểm tra an ninh AI Agent trước khi lên production   (Production Security Checklist)  Stt Hạng mục kiểm tra Trạng thái 1 Agent dùng Workload Identity riêng, không mượn tài khoản User?  2 Credential/API Key được giấu hoàn toàn khỏi Prompt Context?  3 Token cấp cho Agent có vòng đời ngắn và cơ chế Revoke tức thì?  4 Danh sách Tool/API áp dụng nguyên tắc đặc quyền tối thiểu (Least Privilege) ?  5 Các Tool gọi ngoài có Allowlist kiểm soát kết nối Mạng/Domain riêng?  6 Đã rà soát và nhận diện các Agent hội đủ bộ ba "Lethal Trifecta"?  7 Dữ liệu không tin cậy (Email, Web, File) có xử lý ở luồng cô lập?  8 Đầu ra của LLM được Validate/Sanitize trước khi Render/Execute?  9 Các tác vụ Write/Delete trên môi trường Production bắt buộc có HITL?  10 Hệ thống SIEM/SOC có Alert riêng khi Agent có hành vi bất thường?   Sự đánh đổi về mặt kiến trúc (Architectural Trade-offs)  Tăng độ trễ (latency): tách đôi model nghĩa là hai lời gọi thay vì một; cộng với độ trễ của broker và kiểm tra schema thêm một lớp nữa.   Tăng approval fatigue: không nên bắt con người duyệt mọi tool call. HITL cần ưu tiên cho hành động đặc quyền, tác động lớn, khó khôi phục hoặc vượt risk threshold; các thao tác low-risk có thể tự động nếu được policy giới hạn chặt và có khả năng rollback.  Tăng chi phí: allowlist theo từng tool, danh tính theo từng agent, vòng đời token ngắn đều cần người vận hành và quy trình; retrofit lên hệ thống đã chạy khó hơn nhiều so với thiết kế từ đầu.  Khung pháp lý cho Agent AI tại Việt Nam  Sự tuân thủ cho các hệ thống AI Agent hiện được điều chỉnh bởi:  Luật Trí tuệ nhân tạo (Luật 134/2025/QH15, hiệu lực 01/3/2026) và Nghị định 142/2026/NĐ-CP (áp dụng từ 01/5/2026): phân loại hệ thống AI theo ba mức rủi ro.  Quyết định 33/2026/QĐ-TTg (hiệu lực 15/8/2026): ban hành Danh mục hệ thống AI có rủi ro cao.  Luật Bảo vệ dữ liệu cá nhân (Luật 91/2025/QH15): Ràng buộc trách nhiệm xử lý và rò rỉ dữ liệu cá nhân qua Agent.  Nội dung trên không phải tư vấn pháp lý; doanh nghiệp cần đối chiếu văn bản gốc cho trường hợp cụ thể.  3 việc doanh nghiệp có thể triển khai ngay trong tuần  Kiểm kê: toàn bộ agent đang chạy, tool từng agent gọi được và danh tính từng agent đang dùng.  Khoanh vùng: gắn nhãn các agent hội đủ bộ ba lethal trifecta để xử lý trước.  Thiết lập chốt chặn: trước khi có policy chi tiết, áp dụng default-deny đối với mọi hành động làm thay đổi production; bắt buộc HITL cho thao tác high-impact/irreversible. Chỉ mở tự động cho các thao tác low-risk, reversible sau khi đã có allowlist, giới hạn tham số, quota và rollback..  Đội kỹ thuật đang đưa agent LLM vào vận hành và muốn rà lại kiến trúc quyền, sandbox tool-calling và các chốt chặn theo khung OWASP 2026 có thể cùng rà trực tiếp trên sơ đồ hệ thống với đội chuyên gia bảo mật và AI của FPT Cloud. Liên hệ với chúng tôi để được tư vấn chi tiết về các giải pháp, dịch vụ của FPT Cloud:  Hotline: 1800 6139  Email: support@fptcloud.com  Support: m.me/fptsmartcloud  Nguyễn Hải Nam  Trưởng Phòng Vận Hành và Triển khai bảo mật FPT Cloud 

Nhìn lại lịch sử cybersecurity, phần lớn những năng lực phòng thủ mà chúng ta đang coi là tiêu chuẩn hôm nay đều được hình thành sau một sự cố. Từ Morris Worm, Code Red, Pegasus đến Capital One, mỗi sự cố đều tạo ra một bước chuyển trong cách ngành nhìn nhận và quản trị rủi ro. Khi AI đang thay đổi cách hệ thống vận hành, câu hỏi đặt ra là: điểm bùng phát rủi ro tiếp theo sẽ nằm ở đâu?  Có một cách để ta nhìn lại lịch sử ngành Cybersecurity: Đừng bắt đầu từ danh mục sản phẩm bảo mật. Hãy bắt đầu từ những lần chúng ta gặp sự cố. Mọi thứ chúng ta đang dùng hôm nay - từ quy trình, framework cho đến cả những chức danh trong team - đều không xuất hiện từ một bản kế hoạch nào cả. Chúng xuất hiện sau một sự cố, khi ai đó nhận ra rằng thứ mình đang có không còn đủ. Bốn mốc dưới đây không phải bốn vụ tấn công lớn nhất trong lịch sử. Chúng được lựa chọn vì mỗi mốc đánh dấu một lần ngành này buộc phải thừa nhận rằng mô hình phòng thủ đang sử dụng không còn phù hợp với hệ thống hiện đang vận hành. 1. 1988 - Morris Worm: Khi sự cố đầu tiên khai sinh ra Incident Response Ngày 2/11/1988, Internet là một không gian hoàn toàn sơ khai, chủ yếu kết nối các viện nghiên cứu, trường đại học và cơ quan chính phủ với quy mô chừng 60.000 máy tính. Khái niệm an ninh mạng lúc bấy giờ còn đơn giản là chưa tồn tại. Robert Tappan Morris, một nghiên cứu sinh tại Đại học Cornell, đã phát tán một chương trình tự nhân bản từ một máy đặt tại MIT để che giấu nguồn gốc. Chương trình này khai thác đồng thời ba điểm yếu kinh điển trên hệ thống Unix thời đó: sendmail: Phần mềm nhận email vốn bật sẵn chế độ debug cho phép chạy lệnh từ xa. fingerd: Dịch vụ tra cứu thông tin người dùng mắc lỗi tràn bộ đệm (buffer overflow). rsh: Cơ chế đăng nhập từ xa dựa trên quan hệ tin cậy giữa các máy kèm mật khẩu yếu. Sự lây lan chóng mặt của worm xuất phát từ thiết kế đa đường vào: nếu một cổng bị chặn, mã độc vẫn còn hai hướng khác để xâm nhập. Tuy nhiên, thảm họa thực sự lại đến từ một lỗi logic trong thuật toán kiểm soát tái nhiễm. Tỷ lệ tự sao chép bị tính toán sai khiến một máy tính có thể cộng dồn hàng chục bản sao cùng lúc, làm cạn kiệt toàn bộ tài nguyên CPU và bộ nhớ rồi làm tê liệt hệ thống. Ước tính khoảng 6.000 máy bị ảnh hưởng - chiếm khoảng 10% quy mô Internet khi đó. Thứ lộ ra sau đống tro tàn ấy còn đáng sợ hơn cả con số 10%: hoàn toàn không có một đầu mối trung tâm nào đứng ra điều phối ứng cứu. Mỗi tổ chức phải tự mày mò dịch ngược mã độc, tự vá lỗi và truyền tay nhau qua các mailing list thủ công. Mọi thứ vận hành được chỉ nhờ sự kết nối tự phát của vài chục chuyên gia tình cờ quen biết. Nhận ra khoảng trống tai hại này, DARPA đã giao cho Viện Kỹ thuật Phần mềm (SEI) tại Đại học Carnegie Mellon xây dựng một đầu mối chuyên trách. CERT/CC (Computer Emergency Response Team / Coordination Center) ra đời ngay trong tháng 11/1988. Phần lớn khung pháp lý và quy trình Phản ứng Sự cố (Incident Response) mà chúng ta đang sử dụng ngày nay được sinh ra từ chính cuộc khủng hoảng không được chuẩn bị trước đó. 2. 2001 - Code Red: Khoảng trễ vá lỗi (Patch Gap) là một dạng rủi ro hệ thống Mười ba năm sau, lịch sử lặp lại với một hình thái tinh vi hơn và quy mô lớn hơn gấp nhiều lần. Ngày 18/6/2001, Microsoft phát hành bản vá MS01-033 để xử lý lỗ hổng tràn bộ đệm trong Index Server (CVE-2001-0500) trên máy chủ web IIS. Lỗ hổng này sau đó được định danh là CVE-2001-0500 .Điểm quan trọng là bản vá đã tồn tại trước khi cuộc tấn công xảy ra. Khoảng trống nằm ở việc triển khai bản vá. Đến ngày 19/7/2001, biến thể Code Red version 2 (CRv2) bùng nổ sau khi thay đổi cơ chế sinh số ngẫu nhiên từ dạng tĩnh sang dạng động. Thay vì quét cùng một dải IP khiến các con worm tự giẫm chân nhau, mỗi máy nhiễm giờ đây tự quét một danh sách độc lập. Thay đổi nhỏ đó đẩy tốc độ lây nhiễm lên mức kỷ lục: hơn 359.000 máy tính bị hạ gục chỉ trong chưa đầy 14 giờ, với đỉnh điểm ghi nhận hơn 2.000 host mới mỗi phút (theo số liệu từ CAIDA). Một điểm cần phân biệt là Code Red II là một worm khác, xuất hiện ngày 4/8/2001. Nó sử dụng cùng vector khai thác với Code Red nhưng có payload khác, cài backdoor và ưu tiên lây lan sang các máy trong cùng subnet. Morris Worm cho thấy một chương trình tự sao chép có thể gây gián đoạn trên Internet. Code Red đưa vấn đề lên một cấp độ khác: khi hệ thống đã đủ lớn, khoảng trễ giữa “đã có bản vá” và “đã triển khai bản vá” có thể trở thành một rủi ro ở quy mô toàn hệ thống. Patch gap từ đó không còn đơn thuần là một vấn đề vận hành nội bộ. Nó trở thành một yếu tố rủi ro có thể đo lường và có thể trực tiếp quyết định tốc độ lan rộng của một cuộc tấn công. Từ đây, Quản trị lỗ hổng (Vulnerability Management), Quy trình Patching chuẩn hóa và hệ thống IDS/IPS chính thức trở thành yêu cầu sống còn của mọi hệ thống kết nối mạng. 3. 2016 - Pegasus và Ahmed Mansoor: Khi "Endpoint" có thể là một con người Tháng 8/2016, nhà hoạt động nhân quyền Ahmed Mansoor nhận được tin nhắn SMS lạ chứa liên kết hứa hẹn hé lộ thông tin về những vụ tra tấn trong tù. Cảnh giác trước cạm bẫy, ông không truy cập đường link mà chuyển tiếp tin nhắn cho Citizen Lab - nhóm nghiên cứu tại Munk School, tại Đại học Toronto, chuyên điều tra việc sử dụng phần mềm gián điệp nhắm vào các nhà hoạt động và nhà báo.  Bên dưới đường link đó là Trident - chuỗi 3 lỗ hổng zero-day trên iOS: CVE-2016-4657: Lỗi bộ nhớ trong WebKit mở đường đột nhập khi mở trang web. CVE-2016-4655: Lỗi rò rỉ thông tin kernel, được sử dụng để vượt qua KASLR CVE-2016-4656: Lỗi trong kernal cho phép thực thi mã độc, tiến hành jailbreak thiết bị hoàn toàn từ xa. Chuỗi khai thác này kích hoạt phần mềm gián điệp Pegasus do NSO Group phát triển. Điểm chấn động của sự cố không nằm ở kỹ thuật tấn công ồn ào, mà ở sự dịch chuyển toàn diện của mô hình mục tiêu: không có worm quét hàng trăm nghìn server, không cần người dùng cài đặt một phần mềm lạ hay nhập mật khẩu, không có lượng traffic bất thường đủ lớn để dễ dàng bị phát hiện bởi các hệ thống giám sát truyền thống. Một chuỗi khai thác có giá trị thị trường lên tới hàng trăm nghìn đến khoảng một triệu USD được sử dụng để nhắm  vào đúng một chiếc điện thoại của một cá nhân duy nhất. Định nghĩa "Endpoint" từ mốc này đã thay đổi vĩnh viễn. Nó không còn là một thiết bị nằm trong danh sách tài sản cần bảo vệ. Nó có thể là một cá nhân cụ thể, và mức độ đầu tư của kẻ tấn công có thể được quyết định bởi giá trị của chính mục tiêu đó.  4. 2019 - Capital One: Cloud không có lỗi, lỗi ở cấu hình  Ngày 22 và 23/3/2019, dữ liệu của ngân hàng Capital One bị truy cập trái phép.  Sự cố không được phát hiện trong khoảng bốn tháng. Đến ngày 17/7/2019, một người dùng GitHub phát hiện bài đăng của kẻ tấn công về dữ liệu đã lấy được và báo cho Capital One thông qua chương trình Responsible Disclosure. Ngày 19/7, sau điều tra nội bộ, Capital One xác định đã có truy cập trái phép và thông báo cho FBI. Sự việc được công bố ra công chúng  ngày 29/7  Khoảng 100 triệu người tại Mỹ và 6 triệu người tại Canada bị ảnh hưởng. Không có số thẻ tín dụng hay thông tin đăng nhập bị lộ. Điểm đáng chú ý nằm ở chuỗi tấn công. Theo hồ sơ của Bộ Tư pháp Mỹ và các phân tích sau đó, cuộc tấn công gồm bốn bước: Một tường lửa ứng dụng web (WAF) bị cấu hình sai, cho phép khai thác SSRF (Server-Side Request Forgery) - kiểu tấn công lừa máy chủ tự đứng ra gửi request thay mình, qua đó, chạm được vào những địa chỉ nội bộ mà từ bên ngoài không gọi tới được. Máy chủ chạy WAF được gán một IAM role có phạm vi quyền rộng hơn mức cần thiết. Kẻ tấn công dùng SSRF truy cập vào EC2 Metadata Service - một địa chỉ nội bộ mà mọi máy ảo trên AWS đều truy cập được để đánh cắp credential tạm thời của IAM Role. Bộ Credential này có đủ quyền để liệt kê và đọc dữ liệu trong S3, dịch vụ lưu trữ object của AWS. Điều đáng chú ý là không có zero-day và cũng không có thành phần Cloud nào tự thân bị lỗi. Các thành phần đều hoạt động theo đúng cách chúng được cấu hình. Khoảng trống nằm ở mối quan hệ giữa chúng: một cấu hình sai ở lớp ứng dụng, kết hợp với một IAM Role được cấp quyền rộng tay là đủ để biến kiến trúc đó thành cửa ngõ tới toàn bộ dữ liệu phía sau. Đây cũng là lúc Cloud Security, IAM, Configuration Management, CSPM và Shared Responsibility Model chuyển từ những khái niệm mang tính lý thuyết thành các năng lực phải được đưa vào vận hành thực tế. 5. Điểm bùng phát tiếp theo: AI đang đứng ở đâu trong chu kỳ lịch sử? Nhìn dọc theo chuỗi 4 thập kỷ, một quy luật ngầm lộ diện rõ ràng: Mỗi khi một làn sóng công nghệ mới đạt đến quy mô đại trà, ngành an ninh mạng luôn trải qua một khoảng trễ quản trị và khoảng trễ đó thường khép lại bằng một cuộc khủng hoảng hệ thống. Sau mỗi sự cố, ngành Cybersecurity lại được bổ sung thêm những lớp năng lực phòng thủ mới: sản phẩm, quy trình, framework và regulation. Quan trọng hơn, mỗi lần như vậy lại mở ra một cách nhìn mới về Risk.  Làn sóng AI hiện tại đang đứng ngay ranh giới của điểm bùng phát đó. Điểm khác biệt là các rủi ro mới không xuất hiện dưới dạng một mã độc phá hoại phần cứng, mà nằm ở sự đứt gãy kiến trúc vận hành: Prompt Injection: Việc chèn lệnh độc hại trực tiếp vào luồng dữ liệu đầu vào khiến mô hình nhầm lẫn giữa dữ liệu và mệnh lệnh. Chúng ta đang loay hoay xử lý bằng filter và guardrail, giống hệt cách ngành CNTT từng chắp vá để chặn SQL Injection trước khi có chuẩn hóa Prepared Statement. AI Agent tự trị: Các AI Agent đang được trao quyền thực thi và truy cập dữ liệu ở tốc độ machine-speed, lặp lại chính xác sai lầm cấp quyền lỏng lẻo của sự cố Capital One, nhưng ở cấp độ tự chủ cao hơn rất nhiều. Ranh giới tin cậy giữa dữ liệu và chỉ thị: Mọi kiến trúc CNTT trước đây đều tách biệt được hai luồng này - code đi một đường, data đi một đường. Với các mô hình LLM, cả hai lại đi chung trên cùng một kênh. Đây là bản chất và đặc tính cốt lõi của mô hình chứ không phải một lỗi kỹ thuật chờ được vá.  6. Rủi ro không đến từ một cuộc tấn công và 5 chốt kiểm soát doanh nghiệp cần kiểm tra Capital One vẫn cần một kẻ tấn công thực sự bước qua khe hở cấu hình. Nhưng với AI Agent, hệ thống có thể tự sụp đổ mà không cần bất kỳ tác nhân độc hại nào từ bên ngoài. Một agent chạy ở tốc độ máy có thể làm đúng chính xác những gì được cấu hình nhưng vẫn tự động duyệt nhầm hàng loạt khoản hoàn tiền, gửi sai danh sách khách hàng nhạy cảm, hay đưa ra một kết quả (output) sai lệch để làm đầu vào cho một quyết định chiến lược. Không ai xâm nhập, các công cụ giám sát hoàn toàn mù tịt vì không có bất kỳ dấu vết nào trông giống một cuộc tấn công.  Phần lớn các cuộc thảo luận về AI governance hiện nay đều được thiết kế quanh việc ngăn một vụ rò rỉ dữ liệu. Với bối cảnh này thì đó là hình dạng sai. Để không lặp lại sai lầm của các thế hệ đi trước, doanh nghiệp cần rà soát ngay 5 chốt kiểm soát cốt lõi:  Agent identity. Agent có danh tính riêng, hay đang mượn danh tính của một con người? (2016: endpoint trở thành một con người. Giờ con người đó là một service account.) Permission boundary. Quyền theo phạm vi, có thời hạn, tối thiểu, cấp theo tác vụ chứ không theo cả hệ thống. (Capital One, bước 2.) Human-in-the-loop. Xác định hành động nào tuyệt đối không được tự động. Thanh toán, thay đổi trên production, xuất dữ liệu, mọi thứ có đối tác bên ngoài tham gia. (Capital One, bước 4.) Observability. Bạn có dựng lại được vì sao agent làm việc đó không, ở dạng mà auditor chấp nhận? (Capital One: bốn tháng không ai biết.) Kill và rollback. Bạn có dừng được toàn bộ agent bằng một thao tác, và đảo ngược được thứ chúng đã làm không? (1988: không ai điều phối nổi việc phản ứng.) Có thể vài năm nữa, giai đoạn 2022-2023 sẽ được nhìn lại theo cách ngành Cybersecurity nhìn về năm 1988. Không phải vì đó là thời điểm AI trở nên nguy hiểm. Mà vì thế, đó có thể là thời điểm ngành nhận ra rằng mô hình phòng thủ cũ đã không còn đủ cho một hệ thống mới. Tác giả: Lê Ngọc Linh - Leader of Platform Security Engineers, FPT Smart Cloud  Liên hệ với chúng tôi để được tư vấn chi tiết về các giải pháp, dịch vụ của FPT Cloud:    Hotline: 1800 6139   Email: support@fptcloud.com   Support: m.me/fptsmartcloud