Các chuyên gia viết chia sẻ kiến thức – FPT CLoud

Trong bài viết trước, chúng ta đã khẳng định OpenStack là "xương sống" cho hạ tầng AI thế hệ mới. Tuy nhiên, để chuyển đổi từ một cụm máy chủ gắn GPU rời rạc thành một AI Factory - một nhà máy sản xuất trí tuệ nhân tạo có khả năng thương mại hóa và mở rộng vô hạn – doanh nghiệp cần một bản thiết kế kiến trúc chuẩn mực.  Dựa trên Whitepaper "Open Infrastructure for AI", kiến trúc AI hiện đại không còn là câu chuyện của riêng con chip, mà là sự hòa quyện của ba trụ cột: GPU tối ưu, Lưu trữ hiệu năng cao và Mạng tốc độ cực lớn.  GPU: Tài nguyên chiến lược và tư duy đa mô hình  Trong một AI Factory, GPU không chỉ là phần cứng tăng tốc, nó là "tiền tệ" của hệ thống. Để tối ưu hóa dòng tiền này, kiến trúc hạ tầng phải cho phép khai thác GPU theo nhiều kịch bản khác nhau thay vì một cấu hình cố định.  OpenStack mang lại sự linh hoạt đặc yếu qua ba phương thức tiếp cận:  PCI Passthrough: Dành cho các tác vụ huấn luyện (Training) mô hình lớn hoặc suy luận (Inference) thời gian thực. Bằng cách gắn trực tiếp GPU vật lý vào máy ảo, chúng ta loại bỏ độ trễ của lớp trung gian, đạt hiệu năng tương đương máy chủ vật lý (Bare-metal).   Virtual GPU (vGPU): Giải pháp hoàn hảo cho môi trường phát triển (R&D) hoặc thử nghiệm. Một GPU vật lý được chia sẻ cho nhiều người dùng, giúp tối ưu hóa chi phí đầu tư ban đầu.  Multi-Instance GPU (MIG): Đây là chìa khóa cho mô hình AI đa người dùng (Multi-tenant). MIG chia nhỏ GPU thành các phân vùng có tài nguyên phần cứng độc lập, đảm bảo tính cô lập tuyệt đối và độ ổn định cho các dịch vụ Inference quy mô lớn.  Lợi thế của AI Factory trên nền OpenStack chính là khả năng điều phối tự động cả ba mô hình này trên cùng một cụm tài nguyên thông qua API, giúp doanh nghiệp sẵn sàng cung cấp dịch vụ GPU-as-a-Service chuyên nghiệp.   Lưu trữ và Network: "Hệ thần kinh" của các mô hình LLM  Nếu GPU là bộ não, thì lưu trữ và mạng lưới chính là hệ thần kinh trung ương. Với các mô hình ngôn ngữ lớn (LLM) nặng hàng trăm GB, bài toán không còn là "lưu trữ ở đâu" mà là "dữ liệu di chuyển nhanh thế nào".  Lưu trữ hiệu năng cao (HPS) – Bài toán sống còn  Thời gian tải mô hình từ ổ cứng lên vRAM của GPU quyết định tính sẵn sàng của dịch vụ. Whitepaper nhấn mạnh vai trò của Parallel File System. Trong kiến trúc AI Factory, lưu trữ không còn là thành phần phụ trợ mà là yếu tố quyết định khả năng mở rộng (Scalability) và thời gian đưa dịch vụ ra thị trường (Time-to-market).  Network - Kết nối quy mô siêu máy tính  Workload AI đòi hỏi băng thông mạng từ 100Gb/s đến 200Gb/s – gấp 10-20 lần so với ứng dụng web truyền thống. Để vận hành như một hệ thống HPC (Tính toán hiệu năng cao) thực thụ, AI Factory tích hợp sâu các công nghệ:  RDMA & InfiniBand: Giảm tải cho CPU và tăng tốc truyền dữ liệu giữa các node GPU.  SR-IOV: Tối ưu hóa hiệu suất mạng cho máy ảo.  Tối ưu hóa: Lợi thế cạnh tranh nằm ở những "chi tiết ẩn"  Một kiến trúc sư hạ tầng AI giỏi khác biệt ở chỗ họ biết cách "tinh chỉnh" những thông số nhỏ để tạo ra hiệu năng lớn. OpenStack cho phép can thiệp sâu vào tầng dưới cùng của phần cứng – điều mà các nền tảng Public Cloud đóng thường hạn chế:  NUMA Affinity & CPU Pinning: Giảm thiểu độ trễ truy cập bộ nhớ, giúp GPU VM hoạt động mượt mà nhất.  Hardware Offload & RoCE: Tận dụng tối đa năng lực card mạng để giảm tải cho vi xử lý chính.  Chính những tinh chỉnh mang tính đặc thù này giúp các AI Factory vận hành trên hạ tầng mở đạt hiệu suất vượt trội hơn hẳn so với các cấu hình phần cứng tương đương trên nền tảng đóng.  Hệ sinh thái toàn diện: Từ hạ tầng đến dịch vụ thương mại  Sức mạnh thực sự của OpenStack nằm ở khả năng biến các tài nguyên thô thành một hệ sinh thái dịch vụ hoàn chỉnh:  OpenStack Ironic: Cung cấp GPU Bare-metal cho các tác vụ cần hiệu năng tuyệt đối.  Magnum: Triển khai cụm Kubernetes GPU phục vụ container hóa ứng dụng AI.  Trove & Manila: Tự động hóa quản trị cơ sở dữ liệu và hệ thống tệp tin cho AI.  Khả năng tùy biến sâu này giúp doanh nghiệp không chỉ xây dựng được hạ tầng AI mà còn sở hữu một nền tảng sẵn sàng cho thương mại hóa, có thể thích ứng với bất kỳ framework hay dòng chip AI mới nào xuất hiện trong tương lai.  Minh chứng từ thực tế  Kiến trúc AI Factory trên nền OpenStack không còn là lý thuyết. Từ những "gã khổng lồ" viễn thông như China Mobile, các nhà cung cấp cloud như Rackspace, cho đến những đơn vị tiên phong tại Việt Nam như FPT Smart Cloud (FPT Cloud & FPT AI Factory), tất cả đều đang chứng minh rằng: Hạ tầng mở là con đường ngắn nhất và bền vững nhất để làm chủ cuộc chơi AI.  Đứng sau sự thành công này là AI Working Group (thuộc OpenInfra Foundation) – nơi quy tụ những khối óc hàng đầu thế giới về hạ tầng mở. Sự kết nối tri thức này đảm bảo rằng AI Factory của doanh nghiệp bạn luôn được vận hành dựa trên những tiêu chuẩn kiến trúc tiên tiến nhất toàn cầu.  Vì sao OpenStack đang trở thành nền tảng hạ tầng chiến lược cho AI thế hệ mới? Xem thêm thông tin về OpenStack tại đây. Tác giả: Trần Quốc Sang Phó Giám đốc Trung tâm Phát triển Dịch vụ Hạ Tầng Cloud - FPT Smart Cloud, Tập đoàn FPT

Sự trỗi dậy của Generative AI không chỉ thay đổi cách chúng ta tương tác với công nghệ mà đã kéo theo một làn sóng tái kiến trúc hạ tầng ở quy mô toàn cầu. Những mô hình ngôn ngữ lớn (LLM), GPU chuyên dụng như H100/H200, hay các cụm HPC tốc độ cao đã khiến yêu cầu về hạ tầng tăng mạnh chưa từng thấy. Doanh nghiệp không chỉ cần sức mạnh tính toán; họ cần một nền tảng mở, linh hoạt, dễ mở rộng và có khả năng bắt kịp tốc độ thay đổi của hệ sinh thái AI. Họ cần một "AI Factory" – một nhà máy AI thực thụ.  Trong bối cảnh đó, OpenStack đang nổi lên như một nền tảng mở, linh hoạt và mạnh mẽ, đóng vai trò kim chỉ nam cho hạ tầng AI thế hệ tiếp theo nơi khả năng mô-đun hóa, tự do tích hợp và tốc độ cải tiến cộng đồng trở thành lợi thế vượt trội.  OpenStack: Nền tảng mở cho kỷ nguyên AI  Khi các workload AI ngày càng tiêu tốn tài nguyên hơn và nhạy cảm về độ trễ hơn, OpenStack cung cấp lớp ảo hóa và quản trị hạ tầng mạnh mẽ, đủ khả năng hỗ trợ môi trường tính toán hiệu suất cao thông qua các dịch vụ như Nova, Neutron, Cinder và Ironic. Khả năng mở rộng đã được kiểm chứng và mức độ linh hoạt cao khiến OpenStack trở thành lựa chọn phù hợp cho thế hệ tiếp theo của workload AI và HPC.  Khác với các giải pháp đám mây độc quyền vốn phụ thuộc vào lộ trình của nhà cung cấp, OpenStack được phát triển bởi chính cộng đồng những doanh nghiệp vận hành nó trong thực tế. Điều này đảm bảo tốc độ cải tiến nhanh, khả năng cập nhật các công nghệ mới nổi như lập lịch GPU đa người dùng, tối ưu theo NUMA hay tăng tốc mạng SR-IOV, đồng thời mang lại mức độ linh hoạt mà các nền tảng đóng không thể có.  Xuất phát từ thực tiễn đó, AI Working Group - được thành lập bởi Open Infra Foundation đã cùng hợp tác để giới thiệu kiến trúc và usecase công nghệ của việc sử dụng OpenStack nhằm hỗ trợ các workload AI trong whitepaper “Open Infrastructure for AI: OpenStack’s Role in the Next Generation Cloud”  Kim chỉ nam cho hạ tầng AI - Và 5 bài toán lớn định hình tương lai  Generative AI tạo ra một sự thay đổi căn bản trong cách chúng ta thiết kế, triển khai và vận hành hạ tầng AI. Việc huấn luyện mô hình ngôn ngữ lớn, tự lưu trữ các mô hình mã nguồn mở, hay phục vụ suy luận (inference) ở quy mô lớn đòi hỏi phần cứng thế hệ mới như GPU H100/H200 cùng với tốc độ kết nối và băng thông lưu trữ ở mức HPC.  Nhằm bám sát vào những thay đổi lớn của hạ tầng AI thế hệ mới này, 5 bài toán kinh điển và cách thức để hạ tầng mã nguồn mở giải quyết chúng đã được đưa ra bao gồm:  1. ModelTraining & Serving - Tăng tốc sáng tạo mô hình  Trong nhiều năm, xây dựng một pipeline AI hoàn chỉnh đòi hỏi đội ngũ kỹ thuật phải giải quyết hàng loạt bước phức tạp ở tầng hạ tầng. Xu hướng hiện nay đi theo hướng đơn giản hóa: nhà phát triển ứng dụng AI không cần quan tâm vào hạ tầng, chỉ cần thông qua giao diện code như Jupiter Notebook hoặc code IDE là có thể gọi vào training một model LLM. Sau khi training thì có thể chạy serving model đó thông qua API (e.g. OpenAI Compatible API) chỉ với vài thao tác.  2. GPU-as-a-Service - Tối ưu hiệu năng và chi phí GPU Những dòng GPU tân tiến như H100/H200 rất mạnh mẽ nhưng giá thành cao, việc sở hữu một thiết bị H100 gần như là chỉ có ở những doanh nghiệp lớn và thường không sử dụng hết năng lực của một thiết bị gây lãng phí, thay vào đó là việc đi thuê tài nguyên mang lại chi phí tối ưu hơn và phù hợp cho mọi doanh nghiệp. Kiến trúc mở cho phép chia nhỏ GPU thành nhiều phần (MIG), xây dựng máy ảo GPU theo nhu cầu (vGPU), hoặc cấp quyền truy cập trực tiếp (PCI Passthrough) để tối ưu hiệu năng.  Thay vì sở hữu toàn bộ phần cứng, doanh nghiệp có thể thuê đúng mức tài nguyên cần thiết, tránh tình trạng “đầu tư lớn – sử dụng thấp”, đồng thời linh hoạt mở rộng theo nhịp phát triển AI. 3. Nền tảngMLOps - Vận hành mô hình AI ở quy mô lớn  Các mô hình ngôn ngữ lớn thay đổi nhanh chóng và đòi hỏi một vòng đời vận hành liên tục: cập nhật mô hình, giám sát, tối ưu chi phí suy luận, kiểm soát hiệu năng, đảm bảo uptime. Một nền tảng MLOps hiện đại cần làm được tất cả điều này trong khi vẫn duy trì sự ổn định của hệ thống và tính liên tục của dịch vụ.  OpenStack với bộ dịch vụ mở rộng xung quanh trở thành lựa chọn phù hợp để xây dựng nền tảng tự động hóa toàn trình, từ training đến inference.  4. High-PerformanceComputing Cluster - Sức mạnh kết nối cụm GPU lớn  Những mô hình hàng tỷ tham số yêu cầu khả năng huấn luyện phân tán trên hàng chục node GPU. Kết nối một cụm 32 node H100 với thông lượng Tbps, độ trễ cực thấp và khả năng đọc ghi dữ liệu tốc độ cao là một thách thức mà chỉ các nền tảng HPC thực thụ có thể đáp ứng.  OpenStack cung cấp khả năng quản lý bare-metal kết hợp với các công nghệ tối tân như Infiniband, high-performance storage, giúp doanh nghiệp tiếp cận sức mạnh của các “AI SuperPod” theo cách linh hoạt và tối ưu chi phí hơn. 5. AIIoT& Edge Computing - Đưa AI đến gần dữ liệu hơn  Ứng dụng AI ngày càng mở rộng sang robot, xe tự hành, camera thông minh và các thiết bị IoT. Những tác vụ này cần xử lý ngay tại nguồn để đảm bảo tốc độ theo thời gian thực. Kiến trúc phân tán, edge computing và khả năng đồng bộ giữa trung tâm dữ liệu -  biên - thiết bị trở thành yếu tố then chốt.  OpenStack hỗ trợ tốt cho những mô hình hạ tầng lai (hybrid) và distributed, giúp doanh nghiệp triển khai AI ở biên một cách nhất quán và an toàn.  OpenStack - nền tảng mở cho tương lai AI  Trong thế giới nơi AI đang thúc đẩy mọi ngành công nghiệp, một hạ tầng mở, linh hoạt và dễ mở rộng không còn là tùy chọn - mà trở thành nền tảng cốt lõi. OpenStack mang lại khả năng tùy biến sâu, tích hợp rộng và tốc độ cải tiến nhanh nhờ cộng đồng, giúp doanh nghiệp xây dựng “AI Factory” với chi phí tối ưu và khả năng mở rộng bền vững.  Whitepaper “Open Infrastructure for AI” không chỉ mô tả các kiến trúc kỹ thuật, mà mở ra cách nhìn toàn diện về việc vận hành AI ở quy mô lớn bằng hạ tầng mở. Đây là bước đi quan trọng để doanh nghiệp sẵn sàng cho tương lai AI, nơi tốc độ và khả năng tự chủ hạ tầng trở thành lợi thế cạnh tranh hàng đầu.  Tác giả: Trần Quốc Sang Phó Giám đốc Trung tâm Phát triển Dịch vụ Hạ Tầng Cloud - FPT Smart Cloud, Tập đoàn FPT

1. CVE-2025-55182 – Lỗ hổng RCE “React2Shell” & Thống kê đáng báo động Cuối năm 2025, cộng đồng bảo mật toàn cầu đã bị báo động mạnh mẽ bởi một lỗ hổng cực kỳ nguy hiểm mang tên CVE-2025-55182, hay còn gọi là React2Shell, liên quan đến cơ chế React Server Components (RSC) và lan rộng đến các framework như Next.js, vốn được sử dụng phổ biến trong hàng chục triệu ứng dụng web và dịch vụ đám mây. Theo dữ liệu nghiên cứu bảo mật, ~39% môi trường cloud surveyed chứa instance dễ bị tấn công bởi lỗ hổng này, tức là gần 4 trong 10 hệ thống cloud đang hoạt động có nguy cơ bị khai thác nếu chưa vá lỗi. Những gì khiến CVE-2025-55182 trở nên “nóng”: (1) Điểm CVSS tối đa 10.0, mức nghiêm trọng cao nhất, cho phép thực thi mã từ xa ngay cả khi không xác thực; (2) Exploit đã bắt đầu xuất hiện trong tự nhiên chỉ sau vài giờ kể từ khi được công khai, với nhiều scanner tự động và tay hacker chủ động tìm kiếm mục tiêu; (3) Các nhóm tội phạm mạng được ghi nhận khai thác lỗ hổng này để chèn malware, mở backdoor và thu thập credential; (4) Báo cáo cho thấy ít nhất ~30 tổ chức ở nhiều lĩnh vực khác nhau đã bị xâm nhập, bao gồm rò rỉ thông tin đăng nhập, cài malware khai thác tiền điện tử và mở lối vào hệ thống. Trong bối cảnh này, việc phát hiện sớm lỗ hổng trong container image, hiểu rõ chính xác package/version bị ảnh hưởng ngay từ đầu, và xử lý trước khi sản phẩm được đưa vào production là ưu tiên hàng đầu của mọi đội DevSecOps. Và đây là lúc FPT AppSec - với tính năng Image Scanning mạnh mẽ, phát huy vai trò quan trọng, giúp doanh nghiệp scan hàng nghìn image tự động, xác định đúng vị trí tồn tại lỗ hổng như CVE-2025-55182 và giảm thiểu rủi ro trong thời gian ngắn nhất. 2. Case study: FPT AppSec – Giải pháp phát hiện & xử lí CVE-2025-55182 chỉ trong vài giây Khi khách hàng kích hoạt Image Scanning (tích hợp Docker registry hoặc CI/CD pipeline), FPT AppSec lập tức phân tích tất cả layer của image. Trong phát hiện CVE-2025-55182, hệ thống đã: (1) Nhanh chóng xác định đúng image bị ảnh hưởng; (2) Highlight rõ gói next@15.x đang chứa lỗ hổng; (3) Chỉ ra layer build mà package này được đưa vào container; (4) Xếp hạng mức độ Critical và cảnh báo real-time. Nhờ vậy, thay vì phải grep log build hoặc manually check package version, đội kỹ thuật có thể xử lí ngay, đúng vị trí gây rủi ro, giảm đáng kể thời gian điều tra. [caption id="attachment_69816" align="aligncenter" width="977"] FPT AppSec phát hiện image chứa thành phần Next.js bị ảnh hưởng bởi lỗ hổng CVE-2025-55182[/caption] Một trong những khó khăn lớn nhất khi xử lý lỗ hổng trong container là: “Package này đến từ đâu? Layer nào? Tại sao image lại mang phiên bản dễ tổn thương?” Với FPT AppSec, người dùng có thể giải quyết triệt để bằng cách hiển thị Dockerfile layer gây ra việc cài đặt dependency và cho biết danh sách phiên bản an toàn (patched versions). [caption id="attachment_69817" align="aligncenter" width="977"] FPT AppSec chỉ rõ lỗ hổng xuất hiện ở layer nào trong image[/caption] FPT AppSec sở hữu những tính năng ưu việt giúp người dùng xử lý nhanh chóng, chính xác những sự cố như CVE-2025-55182: Quét số lượng lớn image cùng lúc: Hệ thống được xây dựng theo kiến trúc cloud-native, scale-out linh hoạt, có thể xử lí mượt mà 100 hay 10.000 container images. Phát hiện lỗ hổng real-time: Ngay khi CVE mới được công bố, hệ thống tự động đồng bộ dữ liệu vulnerability feed và re-scan nếu cần. Giảm thời gian phản ứng từ hàng giờ xuống vài phút: Đội DevSecOps không cần truy ngược build log, không cần manually inspect, mọi thứ hiển thị trực quan. Dễ dàng tích hợp vào hệ thống CI/CD hiện tại: Chỉ một bước thêm vào pipeline, FPT AppSec sẽ quét trước khi image được push lên registry. 3. Hướng dẫn chi tiết Cách xử lý CVE-2025-55182 trong thực tế CVE-2025-55182 là một lỗ hổng Remote Code Execution (RCE) cực kỳ nghiêm trọng trong React Server Components (RSC), cho phép kẻ tấn công thực thi mã trên server mà không cần xác thực thông qua payload đặc biệt gửi tới endpoint RSC. Lỗi gốc nằm ở việc deserialization không an toàn của các component trên server. NVD Bước 1: Xác định phạm vi ảnh hưởng - React Server Components Các phiên bản sau của React Server Components bị ảnh hưởng: react-server-dom-webpack: 0.0, 19.1.0, 19.1.1, 19.2.0 react-server-dom-parcel: 0.0, 19.1.0, 19.1.1, 19.2.0 react-server-dom-turbopack: 0.0, 19.1.0, 19.1.1, 19.2.0 NVD Những phiên bản này là đích ngắm chính của exploit do lỗi xử lý unsafe deserialization trong Flight Protocol. NVD Next.js Mặc dù lỗi gốc là ở React RSC, Next.js cũng chịu ảnh hưởng khi sử dụng RSC trong App Router. Theo advisory từ Next.js, các version Next.js bị ảnh hưởng và đã được patched bao gồm: Next.js Next.js Tình trạng 15.0.0 – 15.0.4 Vulnerable 15.1.0 – 15.1.8 Vulnerable 15.2.0 – 15.2.5 Vulnerable 15.3.0 – 15.3.5 Vulnerable 15.4.0 – 15.4.7 Vulnerable 15.5.0 – 15.5.6 Vulnerable 16.0.0 – 16.0.6 Vulnerable Tương ứng các bản an toàn (patched) đã được Next.js phát hành: 0.5, 15.1.9, 15.2.6 3.6, 15.4.8, 15.5.7 0.7 Next.js Bước 2: Cập nhật dependency ngay Nguyên tắc đầu tiên và quan trọng nhất là không chạy code với phiên bản RSC/Next.js dễ bị tấn công: React Server Components: Cập nhật các package RSC lên phiên bản an toàn mới nhất (ví dụ 19.2.1 hoặc cao hơn nếu đã phát hành) npm install react-server-dom-webpack@19.2.1 \ react-server-dom-parcel@19.2.1 \ react-server-dom-turbopack@19.2.1 Lưu ý: Nếu bạn không trực tiếp thêm các package RSC vào project, hãy kiểm tra plugin/bundler (ví dụ Webpack/Turbopack) đang sử dụng có phụ thuộc RSC hay không và cập nhật tương ứng. Next.js: Nâng Next.js lên ít nhất một trong các bản đã patched. Đảm bảo lựa chọn đúng phiên bản phù hợp với nhánh hiện tại của bạn để không gây xung đột dependency. npm install next@15.0.5   # nếu đang dùng 15.0.x npm install next@15.1.9   # nếu đang dùng 15.1.x npm install next@15.2.6   # nếu đang dùng 15.2.x npm install next@15.3.6   # nếu đang dùng 15.3.x npm install next@15.4.8   # nếu đang dùng 15.4.x npm install next@15.5.7   # nếu đang dùng 15.5.x npm install next@16.0.7   # nếu đang dùng 16.x Bước 3. Quét lại & xác nhận bằng FPT AppSec Sau khi nâng cấp: Rebuild toàn bộ image/container để loại bỏ dependency cũ. Scan lại với FPT AppSec Image Scanning để đảm bảo không còn phiên bản vulnerable trong bất kỳ layer nào. Kiểm tra điều kiện chạy (runtime environment, build cache, CI/CD pipeline) để chắc chắn không còn CVE-2025-55182. FPT AppSec sẽ chỉ ra chính xác: Image nào còn chứa phiên bản vulnerable; Layer nào cài đặt các package đó; Package/version hiện tại đã được cập nhật hay chưa. Điều này giúp bạn chốt được việc xử lý tận gốc, không chỉ patch tạm thời. Tác giả: Lê Ngọc Linh Chuyên gia Bảo mật - FPT Smart Cloud, Tập đoàn FPT

Trong vài năm trở lại đây, phần lớn doanh nghiệp có xu hướng chuyển dần sang hạ tầng cloud hoặc các mô hình hybrid. Điều này mang lại tốc độ triển khai ứng dụng vượt bậc nhưng đồng thời cũng thay đổi hoàn toàn cách chúng ta đối diện với rủi ro bảo mật. Từ những cuộc tấn công tinh vi hơn do AI thúc đẩy, đến mức độ phức tạp ngày càng cao của kiến trúc microservices - tất cả đều khiến các công cụ bảo mật truyền thống trở nên “đuối sức". Bài viết này chia sẻ góc nhìn từ quá trình xây dựng hệ thống bảo vệ cloud-native tại FPT Smart Cloud, dựa trên triết lý CNAPP (Cloud-Native Application Protection Platform). Thay vì nói về “một sản phẩm”, chúng ta sẽ nói về “một hành trình” - và hành trình đó bắt đầu từ việc nhìn lại chính những điểm yếu thường trực trong môi trường ứng dụng hiện đại. 1. Khi tốc độ phát triển vượt quá tốc độ kiểm soát: Mối nguy hình thành từ đâu?  Điều đầu tiên cần thừa nhận: Hầu hết lỗ hổng xuất hiện không phải do hacker quá thông minh, mà do hệ thống quá phức tạp và đang thay đổi quá nhanh.  Nếu như trước đây, một ứng dụng cần vài tháng để có một bản cập nhật mới thì ngày nay, một đội DevOps nhỏ có thể triển khai hàng chục phiên bản mới mỗi tuần nhờ pipeline CI/CD luôn hoạt động, commit liên tục và khả năng tạo lập hạ tầng tức thì bằng IaC.Cùng với đó, container, microservices, serverless... khiến bề mặt tấn công được mở rộng theo cấp số nhân. Trong bối cảnh đó, những sai sót như S3 bucket để public, IAM role cấp quyền quá rộng, API key lọt vào repo hay các gói thư viện chứa CVE nghiêm trọng rất dễ bị bỏ sót giữa hàng trăm thay đổi mỗi ngày. Song song với đó, việc AI được sử dụng trong tấn công mạng đã giúp gia tăng tốc và mức độ tinh vi của các kỹ thuật tấn công một cách đáng kể. Một số báo cáo gần đây cho thấy những chiến dịch tấn công có dấu hiệu được tự động hóa bằng AI để mở rộng quy mô dò quét, tạo email giả mạo, thậm chí giả lập hành vi người dùng. Khi bên tấn công có “tốc độ máy”, bên phòng thủ không thể tiếp tục vận hành theo kiểu thủ công. Nói cách khác, tốc độ và mức độ phức tạp của các cuộc tấn công hiện nay khiến doanh nghiệp buộc phải thay đổi chiến lược bảo vệ. 2. Tại sao chỉ quét production là chưa đủ? Một thực tế thú vị trong ngành bảo mật là phần lớn lỗ hổng bảo mật nằm ngay trong code và cấu hình ở giai đoạn đầu, nhưng lại được phát hiện muộn nhất - thường là ở runtime. Trong khi đó, chi phí sửa lỗi trong production có thể tốn kém gấp 30 lần so với khi phát hiện ngay lúc viết code. Con số có thể thay đổi tùy báo cáo, nhưng ý nghĩa thì không đổi khi càng phát hiện muộn, chi phí càng lớn, từ downtime, ảnh hưởng tới người dùng, đến tài nguyên SOC. Thực tế tại nhiều doanh nghiệp, đội vận hành phải dành hàng giờ kiểm tra thủ công sự cố, trong khi nếu doanh nghiệp tích hợp công cụ quét vào pipeline, cùng lỗi đó có thể được phát hiện và ngăn ngay khi developer push code. Như vậy, nếu mục tiêu là “phản ứng nhanh và khắc phục tự động”, việc phòng thủ phải bắt đầu trước khi mã chạy, chứ không thể đợi đến khi incident xảy ra. 3. CNAPP - Giải pháp hợp nhất thay cho hệ thống bảo mật rời rạc Trong nhiều năm, các mảng AppSec, CSPM, CWPP, SIEM, hay SOAR… hoạt động như những “mảnh ghép rời rạc". Mỗi bộ phận triển khai công cụ riêng như đội DevSecOps quản lý SAST/DAST, đội hạ tầng phụ trách CSPM, SOC vận hành SIEM/SOAR hay nhóm vận hành container sử dụng CWPP. Mỗi công cụ này đều có giá trị riêng, nhưng khi đứng tách biệt, chúng không thể trả lời câu hỏi quan trọng nhất: “Trong hàng nghìn cảnh báo mỗi ngày, điều gì thực sự khiến hệ thống gặp rủi ro?” CNAPP ra đời để giải quyết vấn đề này. Đây không phải một sản phẩm cụ thể, mà là một cách hợp nhất góc nhìn bảo mật từ code → hạ tầng → runtime → vận hành. Sau khi gom toàn bộ tín hiệu riêng lẻ vào một bức tranh thống nhất, CNAPP áp dụng phân tích ngữ cảnh để hiểu mối liên hệ giữa chúng. Từ đó, hệ thống có thể xác định, ưu tiên các lỗ hổng quan trọng, tự động hoá bước khắc phục và rút ngắn thời gian phản ứng từ hàng giờ xuống chỉ còn vài phút. Đặc biệt, CNAPP không chỉ quét, nó còn có khả năng hiểu ngữ cảnh. Một lỗ hổng CVE mức cao có thể có mức độ rủi ro thấp nếu container đó không public ra ngoài và hoàn toàn không có traffic. Ngược lại, việc để lộ một API trong repo nhưng pipeline lại không ngăn chặn có thể là mối đe doạ nghiêm trọng. Chỉ khi có bức tranh tổng thể này, doanh nghiệp mới đưa ra quyết định đúng, tập trung vào những rủi ro đáng xử lý nhất mà không bị “ngộp” bởi hàng nghìn cảnh báo ồn ào. 4. Từ kinh nghiệm triển khai: Vì sao AppSec/ASPM nên là điểm khởi đầu? Ở FPT Smart Cloud, AppSec là bước mang lại hiệu quả rõ rệt nhất ngay từ đầu. Các bản quét code giúp phát hiện sớm những lỗi logic hoặc lỗ hổng injection. Việc quét IaC cũng giúp nhận diện các cấu hình sai như việc mở port không cần thiết, bỏ sót encryption hay IAM role quá rộng. Các công cụ secret scan giúp phát hiện kịp thời API key hoặc credentials trong repo. Đồng thời, image scan giúp làm rõ những gói phụ thuộc tồn tại CVE nghiêm trọng. Trước đây, những việc này được làm thủ công mất từ vài giờ đến vài ngày. Sau khi tự động hóa trong pipeline CI/CD, thời gian xử lý rút xuống chỉ còn vài phút. Chính vì vậy, điểm cốt lõi không nằm ở việc “dùng công cụ gì”, mà ở cách đưa bảo mật vào đúng thời điểm, biến nó thành một phần tự nhiên của vòng đời phát triển. Tham khảo: FPT AppSec hỗ trợ đội ngũ bảo mật tìm ra CVE-2025-63601 tại đây. 5. Từ code đến vận hành: Các lớp bảo mật doanh nghiệp cần mở rộng AppSec giúp giảm rủi ro từ gốc, nhưng để một hệ thống thực sự có khả năng phát hiện và phản ứng nhanh, doanh nghiệp cần thêm các lớp bảo vệ mạnh mẽ. CSPM (Cloud Security Posture Management) đóng vai trò quan sát cấu hình cloud theo thời gian thực. Nhờ đó, doanh nghiệp có thể phát hiện các rủi ro như storage bucket bị public, network rule mở quá rộng, các encryption bị tắt hoặc các dữ liệu nhạy cảm nằm sai vị trí. Điều đáng nói là phần lớn những sự cố cloud lớn trong suốt thập kỷ qua đều bắt nguồn từ cấu hình sai tương tự. Bên cạnh CSPM, CWPP (Cloud Workload Protection Platform)giúpbảo vệ workload trong quá trình runtime với khả năng phát hiện những hành vi bất thường, quy trình lạ trong container/VM, hỗ trợ tự động cô lập phiên bản bị xâm nhập. Ở tầng mạng, Cloud Network Firewall đóng vai trò phòng thủ quan trọng trong các môi trường multi-cloud hoặc hybrid. Firewall giúp phân vùng mạng, giảm nguy cơ lateral movement. Một số giải pháp firewall hiện đại còn tích hợp thêm WAF hoặc IDPS. Cuối cùng, SIEM kết hợp cùng SOAR giúp kết nối mọi dữ liệu để tự động hóa phản ứng. Một nền tảng SIEM/SOAR mạnh có khả năng thu thập log từ AppSec, CSPM, CWPP, Firewall, IAM sau đó mapping theo MITRE ATT&CK để xác minh hành vi tấn công, thay vì xem từng alert nhỏ lẻ. Khi cần, hệ thống có thể tự động chạy playbook để cô lập workload, vô hiệu hoá credential, chặn IP độc hại mà không cần con người can thiệp. Đây là bước quan trọng giúp doanh nghiệp chuyển từ thế “bị động" sang “chủ động". 6. FPT Cloud Defense - Giải pháp hiện thực hoá CNAPP theo cách linh hoạt FPT Cloud Defense hiện thực hoá triết lý CNAPP bằng cách chia nhỏ thành các năng lực dễ áp dụng và phù hợp với trạng thái trưởng thành của doanh nghiệp theo lộ trình: Bước 1: Bắt đầu bằng AppSec/ASPM, vì đây là phần dễ triển khai nhất và mang lại giá trị tức thì. Bước 2: Mở rộng sang CSPM và CWPP để quan sát posture và runtime. Bước 3: Kết hợp Cloud Network Firewall để bảo đảm phân vùng mạng và phòng thủ tầng network. Bước 4: Hợp nhất tất cả vào SIEM/SOAR, từ đó cho phép tự động hóa khắc phục theo mô hình end-to-end. Điều quan trọng là cách tiếp cận phù hợp, FPT Cloud Defense không phải là một “siêu sản phẩm" hay cố thay đổi toàn bộ hệ thống ngay lập tức, FPT Cloud Defense giúp doanh nghiệp từng bước, giúp nhìn rõ bề mặt tấn công, giảm thiểu lỗ hổng ngay từ code, xây dựng khả năng tự động xử lý sự cố theo playbook và giảm áp lực đáng kể cho đội SOC và DevSecOps. 7. Doanh nghiệp nên bắt đầu từ đâu? Từ góc nhìn và kinh nghiệm triển khai thực tiễn, đây là thứ tự mà nhiều tổ chức chọn khi triển khai bảo mật cloud-native: Bước 1: Triển khai AppSec/ASPM vào pipeline CI/CD. Bắt đầu bằng secret scan và IaC scan - hai nguồn rủi ro phổ biến nhất. Bước 2: Kích hoạt CSPM cơ bản để sửa lỗi cấu hình sớm. Bước 3: Thiết lập bảo vệ runtime (CWPP) cho workload quan trọng. Bước 4: Tối ưu firewall & network segmentation, nhất là nếu có multi-cloud. Bước 5: Kết nối vào SIEM, xây playbook SOAR, ưu tiên 2-3 playbook quan trọng trước (ví dụ: khóa tài khoản bị xâm nhập, chặn IP, rollback cấu hình). Bước 6: Tối ưu liên tục bằng cách đưa dữ liệu từ sự cố thực tế quay về quy trình phát triển. Đây là cách hầu hết doanh nghiệp trưởng thành về bảo mật cloud-native thực hiện trong 3-6 tháng đầu để tăng cường khả năng phòng thủ trước những cuộc tấn công mạng tinh vi. 8. Doanh nghiệp chuyển từ “chống đỡ” sang “chủ động” Câu chuyện bảo mật không còn là “đặt thêm tường lửa” hay “mua thêm công cụ”. Điều quan trọng doanh nghiệp cần là khả năng nhìn thấy rủi ro xuyên suốt - từ code tới production - và xử lý nó trước khi gây thiệt hại. Triết lý CNAPP, cùng sự kết hợp giữa AppSec, CSPM, CWPP, Network Firewall và SIEM/SOAR chính là cách tiếp cận giúp doanh nghiệp chủ động, thống nhất hơn trong bảo vệ toàn bộ hệ thống. Với FPT Cloud Defense, chúng tôi không đặt mục tiêu tạo ra “một công cụ thần kỳ”, mà hướng tới tạo ra một phương pháp phòng thủ hiện đại, giúp doanh nghiệp Việt Nam nâng cao năng lực bảo mật theo đúng cách mà thế giới đang chuyển dịch. Lắng nghe chia sẻ đầy đủ về cách tiếp cận phòng thủ chủ động dựa trên CNAPP và ASPM từ anh Lê Ngọc Linh, Chuyên gia bảo mật, FPT Smart Cloud, Tập đoàn FPT tại đây. Tác giả: Lê Ngọc Linh Chuyên gia bảo mật, FPT Smart Cloud, Tập đoàn FPT 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: 1900 638 399 Email: support@fptcloud.com Support: m.me/fptsmartcloud

Trong vài năm trở lại đây, trí tuệ nhân tạo (AI) phát triển với tốc độ chưa từng có, mở ra vô số cơ hội đổi mới cho doanh nghiệp và xã hội, đồng thời đẩy bối cảnh an ninh mạng trở nên phức tạp, tinh vi và khó lường hơn. Những cuộc tấn công mạng sử dụng AI, các chiến dịch tấn công được cá nhân hóa, mô hình bị đánh lừa bởi dữ liệu giả đang tạo ra sức ép chưa từng thấy lên đội ngũ lãnh đạo công nghệ. Giữa những biến động ấy, câu chuyện về AI và an ninh mạng không còn là hai chủ đề tách rời mà trở thành hai mặt của cùng một bức tranh lớn - nơi cả cơ hội lẫn rủi ro đều song hành.  Tại buổi chia sẻ trong khuôn khổ sự kiện về An toàn dữ liệu doanh nghiệp trong kỷ nguyên AI bùng nổ dành cho các lãnh đạo, startup công nghệ, anh Đặng Hải Sơn - Offensive Security Manager, FPT Smart Cloud, Tập đoàn FPT, khẳng định:“Mối quan hệ giữa AI và An ninh mạng đã chuyển từ trạng thái tuyến tính sang trạng thái tương hỗ phức tạp: AI giúp tăng cường năng lực phòng thủ, nhưng đồng thời việc ứng dụng AI lại tạo ra những lỗ hổng và bề mặt tấn công mới. Hai chiều này không thể tách rời - tổ chức muốn tận dụng AI thì phải hiểu đầy đủ cách AI can thiệp vào an ninh mạng và ngược lại, muốn vận hành AI một cách an toàn thì phải có nền tảng an ninh mạng đủ mạnh để kiểm soát.”  AI cho an ninh mạng: Cơ hội hình thành lớp phòng thủ chủ động thế hệ mới  Từ góc nhìn phòng thủ, AI đang mở ra một kỷ nguyên mới cho lĩnh vực an ninh mạng. Trước đây, các hệ thống bảo mật phần lớn dựa vào quy tắc cố định và khả năng phân tích thủ công của con người. Điều này dẫn đến tình trạng quá tải: đội ngũ SOC phải xử lý hàng nghìn cảnh báo mỗi ngày, rất nhiều trong số đó là cảnh báo giả, khiến phản ứng chậm trễ và tạo khoảng trống cho kẻ tấn công.   Sự xuất hiện của AI đã thay đổi hoàn toàn cục diện này. AI có thể phân tích dữ liệu bảo mật theo thời gian thực và học từ các mẫu tấn công trong quá khứ để dự đoán rủi ro trước khi sự cố xảy ra. Những mô hình học sâu giúp hệ thống nhận diện nhanh các hành vi bất thường trong lưu lượng mạng, từ đó phát hiện những mối đe dọa mà con người khó nhận ra. Quan trọng hơn, AI còn cho phép tự động hóa phản ứng - một máy chủ bị nghi ngờ có hành vi bất thường có thể được cô lập ngay lập tức mà không phải chờ sự can thiệp của chuyên gia. Điều này rút ngắn thời gian phản ứng từ hàng giờ xuống còn vài phút, tạo nên một hệ thống phòng thủ chủ động thay vì chỉ theo kiểu “chữa cháy” như trước.  Nhưng AI không thay thế con người. Như anh Sơn nhấn mạnh:“Cần dùng trí tuệ của con người kết hợp với tốc độ của AI để đưa ra quyết định cuối cùng.” Sự kết hợp giữa AI và con người tạo nên một mô hình phòng thủ lai vừa linh hoạt, vừa có chiều sâu, vừa tận dụng được tốc độ xử lý của máy tính vừa giữ được khả năng phán đoán chiến lược của con người. Chính sự bổ sung cho nhau này đang định hình lại cách các doanh nghiệp tổ chức vận hành an ninh mạng trong thời đại số.  An ninh mạng cho AI: Khi chính hệ thống AI trở thành mục tiêu tấn công  Ở chiều ngược lại, AI không chỉ là công cụ hỗ trợ phòng thủ mà chính nó cũng trở thành một tài sản giá trị cao và vì vậy luôn nằm trong tầm ngắm của các hacker. Các mô hình AI có thể bị thao túng chỉ bằng những tín hiệu nhỏ đến mức con người khó nhận ra. Những cuộc tấn công đối kháng (adversarial attack) có thể khiến hệ thống nhận diện hình ảnh hiểu sai biển báo, làm lệch quyết định của mô hình hỗ trợ xe tự lái và trực tiếp đe dọa an toàn con người.  Nghiêm trọng hơn là các hình thức tấn công sâu vào quá trình phát triển mô hình như đầu độc dữ liệu (data poisoning), khi dữ liệu độc hại được đưa vào giai đoạn huấn luyện khiến mô hình hoạt động sai lệch một cách âm thầm. Cùng với đó là chèn lệnh/prompt độc hại (prompt injection) - một kỹ thuật ngày càng phổ biến trong thời đại GenAI - khi các chỉ thị độc hại được giấu trong email, tệp tài liệu hoặc đường link, buộc mô hình phải thực thi những hành động vượt ngoài phạm vi an toàn đã được thiết lập và có thể dẫn đến rò rỉ dữ liệu nhạy cảm.  Những nguy cơ này cho thấy một thực tế rõ ràng: AI không được bảo vệ đúng cách có thể trở thành điểm yếu chí mạng, gây ra rủi ro lớn hơn rất nhiều so với những sự cố mất dữ liệu truyền thống.   Chính vì vậy, doanh nghiệp cần xây dựng một kiến trúc an ninh dành cho AI theo nhiều lớp, bao gồm bảo vệ dữ liệu, bảo vệ mô hình, bảo vệ hạ tầng triển khai và kiểm soát toàn bộ quá trình vận hành. Điều này đòi hỏi mã hóa dữ liệu và mô hình, tách biệt môi trường xử lý, giám sát hành vi mô hình theo thời gian thực, thực hiện red-teaming chuyên biệt cho AI và tuân thủ các tiêu chuẩn quốc tế như ISO, NIST AI RMF hay EU AI Act để bảo đảm hệ thống AI hoạt động an toàn, bền vững và đáng tin cậy.  Hai chiều - Một bức tranh thống nhất  Khi nhìn vào cả hai hướng - AI hỗ trợ an ninh mạng và an ninh mạng bảo vệ AI - có thể thấy rõ đây không còn là hai chiều hướng phát triển tách biệt với nhau. AI càng phát triển mạnh thì an ninh mạng càng cần đầu tư sâu để bảo vệ AI. Và chỉ khi nền tảng an ninh mạng đủ vững chắc, doanh nghiệp mới có khả năng để triển khai AI một cách an toàn, tận dụng trọn vẹn giá trị mà công nghệ này mang lại.  Trong phần kết của bài chia sẻ, anh Sơn nhấn mạnh thông điệp dành cho các nhà lãnh đạo: “AI không chờ đợi ai - Lãnh đạo cũng phải hành động ngay.” Doanh nghiệp không thể đợi đến khi sự cố xảy ra mới nghĩ đến việc bảo vệ AI. Thay vào đó, cần nhìn nhận đúng cả cơ hội và rủi ro, đưa an toàn vào ngay từ giai đoạn thiết kế, xem bảo mật AI như một phần của quản trị rủi ro tổng thể và đầu tư đúng mức cho những năng lực an ninh trọng yếu.  AI đang thay đổi mọi thứ với tốc độ nhanh hơn khả năng thích ứng của nhiều tổ chức. Những doanh nghiệp hành động sớm - xây dựng nền tảng an ninh vững chắc, chủ động trong chiến lược AI – sẽ là những doanh nghiệp dẫn đầu trong quá trình chuyển đổi số. Trong hành trình đó, FPT tiếp tục đóng vai trò đồng hành, mang đến các nền tảng Cloud và giải pháp AI được thiết kế theo tiêu chuẩn an toàn quốc tế, vận hành an ninh mạng toàn diện với mục tiêu không chỉ là hỗ trợ doanh nghiệp ứng dụng AI, mà là giúp ứng dụng AI một cách an toàn, bền vững để tiến xa hơn trong kỷ nguyên số.  Lắng nghe chia sẻ đầy đủ của anh Đặng Hải Sơn về bức tranh hai chiều của AI và An ninh mạng tại đây. 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: 1900 638 399      Email: support@fptcloud.com      Support: m.me/fptsmartcloud      

Vào ngày 05/11/2025, tổ chức MITRE – một tổ chức phi lợi nhuận hàng đầu thế giới về an ninh mạng, đã chính thức công bố CVE-2025-63601 (https://www.cve.org/CVERecord?id=CVE-2025-63601) -lỗ hổng được đánh giá ở mức Critical (CVSS 9.9) do đội ngũ phát triển dịch vụ FPT AppSec, FPT Smart Cloud, Tập đoàn FPT phát hiện.  [caption id="attachment_68894" align="aligncenter" width="2056"] Thông tin chi tiết CVE-2025-63601 từ NVD[/caption] MITRE là đơn vị quản lý hệ thống CVE (Common Vulnerabilities and Exposures) – cơ sở dữ liệu toàn cầu ghi nhận và định danh các lỗ hổng bảo mật được phát hiện trên khắp thế giới. Khi một lỗ hổng được MITRE cấp mã CVE, điều đó có nghĩa là lỗ hổng ấy được công nhận chính thức, có ảnh hưởng thực tế và sẽ được các hãng công nghệ, tổ chức an ninh mạng toàn cầu theo dõi để phát hành bản vá, cập nhật hệ thống.  Trong quá trình rà soát bảo mật nội bộ với FPT AppSec, nhóm nghiên cứu của FPT Smart Cloud đã phát hiện một lỗ hổng trong chức năng khôi phục sao lưu (backup-restore) của Snipe-IT. Lỗ hổng này cho phép người dùng có quyền xác thực thực thi mã tùy ý trên hệ thống. Vấn đề đã được báo cáo có trách nhiệm tới nhà phát triển và được gán mã CVE-2025-63601 với mức độ nghiêm trọng Critical (CVSS 9.9). Ngay sau đó, nhóm dự án đã phát hành bản vá và thông báo cho người dùng để chủ động đảm bảo an toàn cho hệ thống và dữ liệu.  Trong toàn bộ quá trình này, FPT AppSec đóng vai trò quan trọng ở giai đoạn khoanh vùng và xác định phạm vi lỗ hổng. Công cụ Code Scan của FPT AppSec, kết hợp giữa phân tích tĩnh (taint tracing, data-flow tracking) và AI nhận dạng mẫu, đã giúp kỹ sư nhanh chóng tìm ra đường luồng dữ liệu dẫn tới đoạn mã dễ tổn thương, tiết kiệm đáng kể thời gian phân tích thủ công. Nhờ vậy, nhóm nghiên cứu có thể tập trung vào việc đánh giá mức độ khai thác thay vì mất thời gian lọc kết quả sai lệch.  FPT AppSec (Application Security Posture Management) là một trong những trụ cột quan trọng thuộc hệ sinh thái FPT CloudDefense Platform, được xây dựng nhằm giúp doanh nghiệp bảo đảm an toàn cho ứng dụng trong suốt toàn bộ vòng đời phát triển phần mềm (SDLC) - từ giai đoạn viết mã, xây dựng, triển khai cho đến vận hành thực tế.  Nền tảng này tích hợp đồng thời nhiều công nghệ quét bảo mật hiện đại như Code Scan (SAST) để phân tích mã nguồn, phát hiện sớm lỗi logic và lỗ hổng bảo mật; Secret Scan để tìm kiếm và cảnh báo các khóa API, token hoặc thông tin nhạy cảm bị lộ trong mã nguồn; IaC Scan nhằm rà soát các cấu hình hạ tầng dưới dạng mã như Terraform, CloudFormation hay Kubernetes YAML; Image Scan để kiểm tra container image, gói cài đặt và dependency; SCA Scan để phân tích các thành phần mã nguồn mở nhằm phát hiện lỗ hổng hoặc giấy phép không phù hợp; và DAST để quét, mô phỏng tấn công ứng dụng đang chạy, xác thực khả năng khai thác lỗ hổng trong môi trường thực tế.  Với khả năng kết hợp giữa phân tích tĩnh, phân tích động và trí tuệ nhân tạo hỗ trợ suy luận ngữ cảnh, FPT AppSec giúp doanh nghiệp phát hiện sớm rủi ro, tự động hóa quy trình đánh giá, rút ngắn thời gian xử lý cho đội ngũ kỹ sư, đồng thời nâng cao chất lượng và độ an toàn của phần mềm. Đây là bước tiến quan trọng trong hành trình giúp doanh nghiệp Việt Nam và toàn cầu đáp ứng các tiêu chuẩn bảo mật ngày càng khắt khe của thế giới số hiện nay.  Trong quá trình phát triển và nâng cấp dịch vụ, hàng trăm rule phân tích tĩnh được tinh chỉnh và bổ sung thêm yếu tố AI hỗ trợ phân tích mẫu – kết hợp với các kỹ thuật như Abstract Syntax Tree (AST), Taint tracing và Data-flow analysis – giúp hệ thống phát hiện chính xác hơn và giảm nhiễu cho người dùng kỹ thuật.  [caption id="attachment_68849" align="aligncenter" width="800"] Đội ngũ kỹ sư FSEC[/caption] Với đội ngũ kỹ sư, thành công này không chỉ là việc phát hiện một CVE, mà là cơ hội kiểm chứng năng lực “thực chiến” của dịch vụ. Mỗi rule được tinh chỉnh trong quá trình này sẽ giúp FPT AppSec hoàn thiện các tính năng, nâng cao khả năng phát hiện, đảm bảo kiểm soát truy cập linh hoạt và an toàn.  Bên cạnh đó, việc lỗ hổng CVE-2025-63601 được công bố đã thể hiện năng lực phát hiện sớm, xử lý tự động của nền tảng FPT AppSec cũng như uy tín và đóng góp của nhóm nghiên cứu vào cộng đồng bảo mật quốc tế. Thành công trong việc phát hiện CVE-2025-63601 củng cố niềm tin rằng sự kết hợp giữa nghiên cứu bảo mật chuyên sâu và AI hỗ trợ phân tích mã nguồn là hướng đi đúng đắn cho FPT AppSec.  Trong giai đoạn tiếp theo, đội ngũ phát triển sẽ mở rộng khả năng của nền tảng vượt ra ngoài phân tích tĩnh (SAST), hướng tới liên kết chặt chẽ với phân tích động (DAST) để hình thành chuỗi phát hiện – xác thực – khai thác mô phỏng thông minh.  AI sẽ đóng vai trò trung tâm trong việc tự động suy luận luồng dữ liệu, tái hiện hành vi tấn công và đề xuất bản vá phù hợp, giúp rút ngắn đáng kể thời gian phân tích thủ công cho kỹ sư bảo mật và nhà phát triển.  Bên cạnh việc mở rộng tập rule và tăng độ chính xác phát hiện, FPT AppSec cũng đặt mục tiêu xây dựng một hệ sinh thái phân tích thống nhất, nơi các module SAST, DAST, và AI phối hợp liền mạch – từ mã nguồn đến ứng dụng đang chạy – nhằm giúp doanh nghiệp chủ động hơn trong việc phòng ngừa, phát hiện và khắc phục lỗ hổng trong toàn bộ vòng đời phần mềm (SDLC).  Liên hệ với chúng tôi để được tư vấn về dịch vụ của FPT Cloud Fanpage: https://www.facebook.com/fptsmartcloud/ Email: support@fptcloud.com Hotline: 1900 638 399 

Bên lề Lễ mở ký Công ước của Liên Hợp Quốc về chống tội phạm mạng (Công ước Hà Nội), tọa đàm “Bảo vệ công dân và củng cố niềm tin số trong nỗ lực thực thi Công ước Hà Nội” đã diễn ra tại Trung tâm Hội nghị Quốc gia, do Hiệp hội An ninh mạng Quốc gia phối hợp với Doanh nghiệp xã hội Chống Lừa Đảo tổ chức. Tại sự kiện, ông Đặng Hải Sơn, Offensive Security Manager, FPT Smart Cloud (Tập đoàn FPT), chia sẻ kinh nghiệm triển khai các mô hình tấn công – phòng thủ thực chiến cho doanh nghiệp, cùng những kỹ năng mới bắt buộc trong môi trường an ninh mạng dựa trên AI và cách rèn luyện tư duy “phòng thủ chủ động” cho đội ngũ kỹ sư an ninh mạng Việt Nam.  Ông Sơn nhấn mạnh, AI Red Teaming đang trở thành năng lực cốt lõi: đội ngũ an ninh cần biết cách “đóng vai kẻ tấn công” để kiểm thử hệ thống AI từ nhiều lớp – prompt (câu lệnh), mô hình và pipeline huấn luyện/vận hành. Doanh nghiệp khi xây dựng kịch bản tấn công-phòng thủ, nên bám theo các chuẩn ngành như MITRE ATLAS/ATT&CK, STRIDE và OWASP Top 10 cho LLM nhằm bảo đảm không bỏ sót rủi ro.  [caption id="" align="alignnone" width="2165"] Ông Đặng Hải Sơn (đứng giữa) tại phiên thảo luận “Phát triển năng lực và hợp tác liên ngành về an ninh mạng” bên lề Lễ mở ký Công ước của Liên hợp quốc (LHQ) về chống tội phạm mạng (Công ước Hà Nội).[/caption]   Việc kiểm thử cần tự động hóa, đồng thời ghi nhật ký/giám sát để đo lường tỷ lệ “bẻ khóa” mô hình và tốc độ phát hiện/ứng phó sự cố. Ở chiều phòng thủ, hệ thống cần bộ bộ lọc an toàn đầu vào/đầu ra, cơ chế bảo vệ dữ liệu và mô hình, vận hành MLOps an toàn, cùng với việc áp dụng Zero Trust để xác thực mọi truy cập của AI/agent. Doanh nghiệp cũng nên tuân thủ các khung quản trị AI như NIST AI RMF và ISO/IEC 42001, cùng quy định trong nước.  Trong khuôn khổ sự kiện, FPT giới thiệu 08 nền tảng, giải pháp và dịch vụ bảo mật ứng dụng AI đã được ghi nhận bằng các giải thưởng khu vực, thể hiện năng lực công nghệ của doanh nghiệp Việt trong việc bảo vệ hạ tầng số quốc gia và thúc đẩy chuyển đổi số an toàn, bền vững.  [caption id="" align="alignnone" width="1462"] Không gian triển lãm của FPT tại sự kiện.[/caption] Công ước Hà Nội là văn kiện pháp lý quốc tế đầu tiên ở cấp độ Liên Hợp Quốc về phòng, chống tội phạm mạng, tạo cơ sở để Việt Nam thúc đẩy hợp tác, tiếp nhận hỗ trợ kỹ thuật, nâng cao năng lực điều tra số và chia sẻ thông tin với các đối tác. Sự kiện đánh dấu bước tiến quan trọng khi Việt Nam đăng cai ký kết Công ước toàn cầu đầu tiên về an ninh mạng, khẳng định vai trò chủ động, sáng tạo và có trách nhiệm của Việt Nam trong nỗ lực xây dựng không gian mạng an toàn, lành mạnh và hợp tác quốc tế vì hòa bình, thịnh vượng.  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: 1900 638 399 Email: support@fptcloud.com Support: m.me/fptsmartcloud

Serverless ngày càng trở thành một khái niệm quen thuộc với các tín đồ công nghệ và doanh nghiệp trong hành trình chuyển đổi số. Cùng FPT Cloud khám phá chi tiết về Serverless và cách áp dụng nền tảng này trong bài viết dưới đây! >>> Xem thêm: Cloud Compute là gì? Phân loại và cách thức hoạt động 1. Lịch sử các phương pháp triển khai Serverless Từ thời đại của hạ tầng vật lý, ứng dụng được triển khai trực tiếp lên hệ điều hành của một máy chủ ảo, mô hình này sẽ đòi hỏi nhiều tài nguyên để vận hành cũng như việc đầu tư thiết bị đắt tiền cùng hàng loạt những vấn đề mà người quản trị phải giải quyết như sao lưu/phục hồi, lãng phí tài nguyên, đảm bảo tính sẵn sàng, mở rộng và bảo mật cho ứng dụng. >> Xem thêm: Thuê VPS giá rẻ - Mua Cloud VPS tốc độ cao Hệ thống ảo hoá ra đời đã giải quyết hầu như triệt để những vấn đề của mô hình vật lý. Hàng loạt những công nghệ ảo hoá ra đời và hiện nay vẫn đang được dùng rất nhiều như VMware, KVM, Xen, HyperV… Bằng việc phân tách một máy vật lý ra thành nhiều máy ảo chạy hệ điều hành độc lập sẽ tận dụng được nhiều tài nguyên hơn. Ngoài ra, các nền tảng ảo hoá còn có nhiều tính năng như mở rộng linh hoạt, sao lưu/khôi phục, snapshot, live-migrate, khả năng HA các máy ảo trong cụm vật lý… giúp ứng dụng được triển khai một cách đáng tin cậy hơn so với mô hình vật lý. Ảo hoá ngày nay vẫn là một công nghệ đang hot, các hãng tận dụng công nghệ này và phát triển thêm hàng loạt những dịch vụ đi kèm, tổ hợp thành các Public/Private Cloud mà ta đang sử dụng ngày nay. Tuy vậy, việc triển khai ứng dụng trên VM khá cồng kềnh gồm cả OS, middle layer (thư viện, runtime,…), app gây khó khăn cho các team phát triển về việc quản lý version, môi trường triển khai, đóng gói, time-to-market. Vì vậy mà container ra đời giúp các nhà phát triển đóng gói nhanh chóng ứng dụng trong một container image, triển khai container lại vô cùng nhanh chóng đi kèm khả năng tương thích với hầu hết hệ điều hành. Với kiến trúc phức tạp và xu thế ngày nay như microservice, CI/CD, GitOps container hầu như trở thành yếu tố bắt buộc phải có. Qua phân tích trên ta thấy rằng công nghệ triển khai ứng dụng thay đổi theo từng thời kỳ đều tuân theo quy luật tiện dụng, nhanh chóng, khả năng mở rộng, chịu lỗi tốt. Chính vì thế mà container đã bùng nổ như một cơn sốt công nghệ, đạt CAGR 30.8% năm 2017-2022 và sẽ còn tiếp tục tăng trưởng những năm sắp tới, nhiều doanh nghiệp đang chuyển đổi số hoặc trong giai đoạn phát triển ứng dụng mới đều sẽ tận dụng những tiện nghi của công nghệ microservice, container để giúp sản phẩm của họ nhanh chóng được đưa đến người dùng (tối ưu time-to-market), tiết kiệm đáng kể chi phí hạ tầng và nhân sự vận hành quản trị. [caption id="attachment_35540" align="aligncenter" width="800"] Báo cáo thị trường container – Theo 451 Research[/caption] Tuy rằng có nhiều tiện ích trong việc phát triển ứng dụng nhưng chúng ta cần phải nhìn nhận rằng container nói chung hay Kubernetes nói riêng (công cụ quản trị, phân bố, tự động hoá trong triển khai container) vẫn còn nhiều điểm khó tiếp cận đến người dùng như: Vận hành quản trị: Đòi hỏi nhiều kỹ năng như network, system, develop, logging, monitoring,… Yêu cầu bảo mật cao cho ứng dụng container. Rất phức tạp cho người mới. Cần lựa chọn vendor cung cấp dịch vụ uy tín hoặc tự triển khai. Vấn đề về giải pháp lưu trữ dài hạn cho container. [caption id="attachment_35541" align="aligncenter" width="800"] Xếp hạng những khó khăn trong sử dụng Kubernetes (container) – Theo TheNewStack[/caption] >>> Xem thêm: Cloud Server là gì? Hoạt động của hệ thống máy chủ đám mây 2. Serverless – Xu thế tất yếu của điện toán đám mây Nhận định trên đưa ta đến một kết luận về sự ra đời tất yếu của nền tảng mới mà ở đó nhà phát triển ứng dụng sẽ chỉ cần tập trung vào việc coding, hoạch định bài toán kinh doanh còn lại toàn bộ hạ tầng đều được nhà cung cấp dịch vụ quản lý. Đó chính là công nghệ “Serverless”, serverless không có nghĩa là không cần máy chủ server để hoạt động, mà nó mang ý nghĩa trừu tượng về cách thức sử dụng, thực ra những máy chủ này đã được quản lý bởi nhà cung cấp dịch vụ (cloud provider) bao gồm hạ tầng, DC, network, storage, security, platform, auto-scale để người phát triển ứng dụng chỉ cần đẩy code lên để chạy, đồng thời chỉ chi trả cho những tài nguyên được tiêu thụ trong thời gian xử lý request. Việc này giúp tiết kiệm hơn rất nhiều so với mô hình cloud VM hoặc sử dụng dịch vụ Kubernetes đều phải trả chi phí hàng tháng dù tài nguyên có được sử dụng hoặc idle. Trong mô hình cung cấp dịch vụ của điện đoán đám mây, serverless được xếp vào lớp Function as a service (FaaS) – trong một số tài liệu vẫn xếp serverless vào lớp Platform as a service (PaaS) về bản chất FaaS hay PaaS đều cung cấp công cụ cho người dùng ở lớp nền tảng phát triển Application. Dịch vụ điển hình của PaaS như fully-managed kubernetes hoặc database engine cho phép người dùng sử dụng để triển khai (deploy) ứng dụng với một vài lượt nhấp hoặc kéo thả, tuy nhiên sẽ vẫn phải cần có kiến thức về DB hoặc K8S để thực hiện các task của DBA hoặc Devops khi cần triển khai ứng dụng. Còn đối với FaaS người dùng chỉ cần phát triển code để xử lý nghiệp vụ ứng dụng và hầu như không cần sự can thiệp về mặt hệ thống khi triển khai và vận hành. Bảng dưới đây so sánh sự khác nhau đặt trưng của IaaS, PaaS và FaaS: Mục IaaS PaaS FaaS Unit of development Operating System Application Functions Provides VM package with OS Dev platform Execute code on-demand Abstracts Physical server OS & middleware Programing runtime Hiện nay trên thị trường serverless có lẽ chúng ta đã quá quen với những cái tên lớn như AWS Lamda, Azure Functions, Google Cloud Functions, các nền tảng này được áp dụng rộng rãi với nhiều câu chuyện thành công được chia sẻ. Ở phân khúc mã nguồn mở của serverless, những nền tảng có cộng đồng lớn có thể kể đến như KNative, OpenFaaS, Apache OpenWhisk, Kubeless, fission. Để hiểu rõ hơn ưu thế của serverless chúng ta cùng điểm qua một số tiện tích cốt lõi của serverless mang lại: Được quản trị hoàn toàn (fully managed): Các nhà phát triển sẽ không phải bận tâm về hạ tầng nữa. Dịch vụ serverless được cloud provider quản trị toàn bộ phần hạ tầng, hệ điều hành, middleware, runtime của ngôn ngữ lập trình và các module liên quan. Kiến trúc event-driven: Một trong những yếu tố then chốt trong microservice để giải quyết bài toán decoupling và phân tán. Các nền tảng serverless đều có cơ chế để được gọi thực thi khi xảy ra sự kiện từ hệ thống (e.g AWS Lamda được trigger khi có sự kiện trên dịch vụ notification SNS). Mở rộng không giới hạn (scale-out): Tận dụng lợi thế hạ tầng sẵn có của cloud provider, giúp người dùng dễ dàng mở rộng ứng dụng ứng dụng theo lượng tải đột biết hoặc giảm về 0 khi không được sử dụng. Tính sẵn sàng cao (high availability): Bản chất của serverless được cung cấp trên nền tảng hạ tầng kế thừa của cả mức IaaS và PaaS do đó khả năng HA đã được tích hợp sẵn bên trong. Less-Ops: Một số thao tác vận hành vẫn có ở serverless như database, debugging, testing,… trong môi trường container shell. Ngoài ra, kiến trúc serverless sẽ sử dụng một số dịch vụ đi kèm của cloud như Database Engine, Message Queue Engine, Monitor/Alert, Vault Engine,… giúp hạn chế tối đa thao tác vận hành. Tối ưu hoá chi phí: Chỉ chi trả cho lượng tài nguyên xử lý khi có request hoặc event và sẽ không mất phí khi ứng dụng rảnh rỗi (idle). Việc này tối ưu hơn rất nhiều so với chúng ta chạy VM và phải trả một chi phí cố định hàng giờ. No vendor lock-in: Với cùng một mã nguồn của nhà phát triển có thể triển khai được trên nhiều dịch vụ serverless của các nhà cung cấp khác nhau. Ngoài ra, khả năng tương thích này còn giúp quá trình dịch chuyển dịch vụ một cách nhanh chóng. [caption id="attachment_35542" align="aligncenter" width="800"] Model FaaS giữ vị trí giữa PaaS và SaaS[/caption] 3. Một số dịch vụ điển hình ứng dụng công nghệ Serverless Ứng dụng web: Static website, webapps, micro frontend, common framework flask/django/spring/fastapi,… Ứng dụng backend: Backend app/service, backend mobile, IoT edge,… Xử lý dữ liệu: Real-time data processing, Map reduce, batch processing, stream processing, ML inference,… Tác vụ tự động hoá IT: policy engine, infrastructure management,… Bên cạnh những tiện ích vượt trội, không phải ứng dụng IT nào cùng có thể triển khai trên nền tảng serverless. Để xác định ứng dụng doanh nghiệp của bạn có phù hợp để triển khai serverless hay không chúng ta có thể xét qua 07 tiêu chí dưới đây: 1. Ứng dụng stateless: Những tài nguyên phát sinh trong quá trình thực hiện một request sẽ mất sau khi kết thúc request đó. Việc này cần lưu ý đối với những ứng dụng cần giữ session trong phiên giao dịch, cần có thiết kế lưu trữ ở DB hoặc cache trong dịch vụ trước khi kết thúc chu trình. 2. Tính chất ephemeral: Bản chất của serverless hoạt động trên nền container, do đó tất cả dữ liệu file được ghi trên container này sẽ bị xoá đi khi container không còn tồn tại do quá trình auto-scale. 3. Hỗ trợ ngôn ngữ: Không phải nền tảng serverless nào cũng hỗ trợ đầy đủ ngôn ngữ lập trình, nên việc lựa chọn nền tảng thống nhất để đáp ứng toàn bộ ngôn ngữ lập trình cho dự án của bạn cũng rất quan trọng. 4. Chỉ duy trì khi hoạt động: Một số nền tảng sẽ giảm số lượng container về 0 khi dịch vụ không hoạt động (idle) quá lâu. Điều này sẽ ảnh hưởng đến việc khi cần sử dụng ứng dụng sẽ mất thời gian để khởi động lại gây ảnh hưởng đến trải nghiệm. Nên thiết kế để dịch vụ luôn có ít nhất một thành phần sẵn sàng nhận request hoặc chạy keep-alive dịch vụ. 5. Cơ sở dữ liệu: Sử dụng serverless với cơ sở dữ liệu quan hệ (relational database) sẽ có nhiều hạn chế do cơ chế giới hạn concurrent connection của DB, nên việc lựa chọn NoSQL trong serverless sẽ có nhiều lợi thế hơn. 6. Không cho phép truy tập file system: Như tính chất stateless và ephemeral của serverless kể trên, việc ứng dụng sử dụng config từ file system hoặc ghi dữ liệu ra tệp tin sẽ không được hỗ trợ như sử dụng Cloud VM. 7. Logging & Monitoring: Mỗi nền tảng serverless sẽ có cơ chế lấy log cũng như khả năng giám sát giới hạn các thông tin có thể cung cấp đồng nghĩa với việc không thể tận dụng cũng như tích hợp được với các phần mềm có sẵn của người dùng. Hiện tại các nhà phát triển, doanh nghiệp đã có thể dễ dàng đăng ký cũng như sử dụng, trải nghiệm công nghệ Serverless của các nhà cung cấp cloud nước ngoài như AWS, Azure, Google Cloud. Đối với các nhà cung cấp cloud trong trước hiện tại vẫn chưa có đơn vị cung cấp dịch vụ serverless nên việc trải nghiệm sẽ còn hạn chế, thay vào đó bạn vẫn hoàn toàn có thể tự triển khai riêng cho mình một hệ thống serverless local dựa trên các dịch vụ có sẵn của nhà cung cấp trong nước. Dưới đây là một ví dụ tham khảo việc triển khai nền tảng serverless sử dụng mã nguồn OpenFaaS - mã nguồn mở cho phép triển khai hệ thống serverless với các tính năng cơ bản đáp ứng mức production ready (https://www.openfaas.com). Chuẩn bị hạ tầng: o Sử dụng Cloud Virtual Machine để tự triển khai Docker, Kubernetes bằng các công cụ như Rancher, Kuberspray, kubeadm, openshift,… tuy nhiên sẽ tương đối phức tạp cần có nhiều kiến thức để triển khai và vận hành hiệu quả. o Phương án sử dụng dịch vụ cloud có cung cấp sẵn nền tảng Managed Kubernetes – FPT Kubernetes Engine (FKE) của FPTCloud là một dịch vụ điển hình, bạn có thể tham khảo thêm tại đây. Triển khai dịch vụ Serverless: o Tham khảo hướng dẫn triển khai trên nền K8s tại đây. Cấu hình expose dịch vụ: o Đối với phương án tự triển khai trên virtual machine bước này sẽ cần bạn phải triển khai thêm dịch vụ LB trên K8s như MetalLB, Cilium,… và ingress controller như nginx, traefik, haproxy,… o Với cách sử dụng dịch vụ managed Kubernetes thì loadbalancer và ingress đã được tích hợp sẵn ở mức hạ tầng, bạn chỉ cần expose service ở tầng dịch vụ K8s, nhà cung cấp dịch vụ Cloud sẽ tự động hoá hoàn toàn các bước. Sau đó bạn chỉ cần truy cập từ domain đã khai báo ở phần cài đặt trên và trải nghiệm. [caption id="attachment_35543" align="aligncenter" width="800"] Mô hình triển khai Serverless in-house[/caption] Những bài viết liên quan: Kubernetes vs Docker: Lựa chọn nào cho doanh nghiệp So sánh VPS và Cloud Server chi tiết từ A đến Z Tìm hiểu chi tiết khả năng giám sát (Observability) là gì? Ngày nay, với sự bùng nổ trong nền công nghiệp 4.0, hàng loạt những công nghệ mới ra đời nhằm đáp ứng được nhu cầu ngày càng cao của con người. Xuyên suốt bài viết chúng ta đã sơ lược qua quá trình phát triển của lĩnh vực điện toán và sự xuất hiện tất yếu của nền tảng Serverless. Chúng ta cũng đã định hình được vị trí của FaaS trong mô hình cung cấp dịch vụ của điện toán đám mây cũng như đã liệt kê ra được những lợi ích và hạn thế mà nền tảng này mang lại, đồng thời đưa ra những ứng dụng cụ thể của serverless trong việc phát triển phần mềm. Vẫn còn quá sớm để có thể kết luận được serverless có thể hoàn toàn thay thế được toàn bộ workload IT trong tương lai hay không, do về cơ bản, bản thân cơ chế hoạt động, lưu trữ của serverless chưa phù hợp cho các ứng dụng đặc thù, ứng dụng cơ sở dữ liệu, ứng dụng cần tính toán lớn,… Tuy nhiên với vị trí của một công nghệ mới nổi (emerging technology) cùng với những tính chất vượt trội như tối ưu hoá chi phí hạ tầng/vận hành, tối ưu time-to-market, nhanh chóng và đảm bảo; serverless hoàn toàn có thể là một công nghệ được sử dụng nhiều nhất trong thời gian sắp tới ở thời đại của microservice, edge computing. Trần Quốc Sang – Senior Cloud Engineer, FPT Smart Cloud