Blog chia sẻ kiến thức FPT Cloud

Trước khi đi vào vấn đề, cần làm rõ một điều: relational database và SQL không phải công nghệ lỗi thời. Relational Database (Cơ sở dữ liệu quan hệ) là một mô hình lưu trữ dữ liệu dưới dạng các bảng (tables) gồm các hàng và cột - rất giống với cách chúng ta nhìn một file Excel. Điểm đặc biệt là các bảng này không đứng độc lập mà có mối quan hệ (relationship) chặt chẽ với nhau thông qua các trường dữ liệu chung. SQL (Structured Query Language) chính là ngôn ngữ tiêu chuẩn dùng để "nói chuyện", truy vấn và thao tác với các cơ sở dữ liệu quan hệ này. Sự kết hợp này tạo nên một hệ thống cực kỳ chặt chẽ, hoạt động dựa trên bộ quy tắc bất di bất dịch mang tên ACID (đặc biệt là tính Atomicity - Nguyên tố và Isolation - Độc lập). Các quy tắc này đảm bảo rằng: hoặc là giao dịch của bạn thành công trọn vẹn hoặc là thất bại và hệ thống quay về trạng thái ban đầu chứ không bao giờ có chuyện lấp lửng hay sai lệch dữ liệu. Chính nhờ nền tảng vững chắc đó, phần mềm kế toán doanh nghiệp, hệ thống ngân hàng lõi, nền tảng quản lý giao dịch tài chính vẫn đang chạy ổn định. Vậy tại sao ngày càng nhiều engineering team đang gặp vấn đề với relational database khi hệ thống scale? Relational database được thiết kế khi hệ thống phần mềm điển hình có kiến trúc khá đơn giản: một ứng dụng trung tâm, một database, lượng truy cập ổn định và dự đoán được. Tuy nhiên, lấy ví dụ một nền tảng e-commerce trung bình ở Việt Nam giờ có thể gồm hàng chục ứng dụng vận hành độc lập, quản lý đơn hàng, thanh toán, kho hàng, gợi ý sản phẩm, thông báo đẩy, điểm thưởng và mỗi ứng dụng do một nhóm khác nhau phát triển. Đi kèm đó là lượng truy cập không còn ổn định. Một chiến dịch khuyến mãi có thể đẩy số lượng yêu cầu lên hàng chục lần chỉ trong vài phút. Thêm một điểm khác biệt so với hiện nay là yêu cầu về dữ liệu thay đổi liên tục. Nhóm sản phẩm cần thêm thuộc tính mới cho từng danh mục hàng hóa. Nhóm thiết kế cần ghi lại thêm hành vi người dùng. Nhóm phân tích cần dữ liệu theo thời gian thực. Khi đặt relational database vào bối cảnh này, ba điểm lệch pha bắt đầu bộc lộ. Ba điểm lệch pha giữa SQL và hệ thống hiện đại 1. Một database phục vụ quá nhiều ứng dụng - điểm nghẽn không ai tính đến Hãy hình dung thế này: một nhà bếp trung tâm phục vụ mười quầy bán hàng cùng lúc. Khi tất cả đều đặt đơn vào giờ cao điểm, vấn đề không phải là thiếu nguyên liệu mà là nhà bếp không thể xử lý tất cả cùng một lúc. Theo đó, nếu trong trường hợp nhiều bộ phận phần mềm dùng chung một relational database, kịch bản tương tự xảy ra. Khi một bộ phận chạy tác vụ nặng, ví dụ xuất báo cáo, gửi thông báo hàng loạt, nó chiếm dụng tài nguyên của hiệu năng của Database chung, kéo chậm tất cả các bộ phận còn lại dù chúng hoàn toàn không liên quan. Đây là vấn đề của kiến trúc thiết kế database, không phải vấn đề tối ưu. Viết lại câu truy vấn hay thêm chỉ mục tìm kiếm không giải quyết được khi nguyên nhân gốc rễ là tất cả đều đang tranh nhau một kho dữ liệu duy nhất. Câu chuyện thực tế: Một startup fintech tại Đông Nam Á từng gặp chính xác tình huống này. Khi hệ thống bắt đầu gửi thông báo đẩy hàng loạt vào buổi sáng - thời điểm người dùng hoạt động nhiều nhất, tốc độ xử lý giao dịch của toàn bộ hệ thống giảm đáng kể. Sau nhiều tuần tìm nguyên nhân, đội kỹ thuật nhận ra rằng bộ phận gửi thông báo và bộ phận xử lý thanh toán đang tranh nhau tài nguyên trên cùng một kho dữ liệu. Giải pháp cuối cùng không phải là tối ưu code mà là tách dữ liệu của hai bộ phận ra khỏi nhau. 2. Dữ liệu bị phân tán ở nhiều nơi và hợp nhất là điều không đơn giản Relational database có khả năng kết hợp dữ liệu từ nhiều bảng trong một câu truy vấn duy nhất. Đây là một trong những điểm mạnh nhất khiến nó phù hợp với báo cáo và phân tích phức tạp. Nhưng trong hệ thống hiện đại, mỗi bộ phận phần mềm thường quản lý dữ liệu riêng của mình. Thông tin đơn hàng ở một nơi, thông tin khách hàng ở một nơi khác, thông tin sản phẩm ở nơi khác nữa. Khi đó, việc tổng hợp dữ liệu từ nhiều nguồn không còn là một câu truy vấn đơn giản nữa. Nó trở thành một chuỗi các bước gọi qua lại giữa các bộ phận, tổng hợp kết quả ở tầng ứng dụng, và xử lý nhiều tình huống lỗi có thể xảy ra ở từng bước. Thao tác trước đây mất vài phần nghìn giây giờ có thể mất vài trăm lần lâu hơn và có thể gặp sự cố ở nhiều điểm khác nhau trong chuỗi xử lý. 3. Cấu trúc dữ liệu cứng nhắc - khi database chậm hơn nhịp độ kinh doanh Relational database được thiết kế với cấu trúc dữ liệu chặt chẽ: mỗi bảng có các cột xác định sẵn, mỗi cột có kiểu dữ liệu cố định. Tính chặt chẽ này là lợi thế khi dữ liệu ổn định và ít thay đổi. Nhưng nó trở thành rào cản khi sản phẩm cần thay đổi nhanh. Thêm một trường thông tin mới vào bảng dữ liệu đang có hàng chục triệu bản ghi trên hệ thống đang chạy thực tế không phải thao tác đơn giản. Tùy vào cách hệ thống được cấu hình, thao tác này có thể khóa bảng dữ liệu đó trong vài phút đến vài giờ đồng nghĩa với việc hệ thống gián đoạn. Ngay cả khi có công cụ hỗ trợ, quy trình vẫn đòi hỏi: viết kịch bản chuyển đổi dữ liệu, kiểm tra trên môi trường thử nghiệm, phối hợp giữa nhiều nhóm, và triển khai theo từng bước để tránh sự cố. Kết quả thực tế: những thay đổi nhỏ trong cách lưu trữ dữ liệu thêm một thuộc tính sản phẩm, ghi nhận thêm một loại hành vi người dùng, thay đổi cách tổ chức thông tin khuyến mãi tốn nhiều ngày công sức của đội kỹ thuật mà không trực tiếp tạo ra giá trị cho người dùng. Nhân con số đó với tần suất thay đổi trong một quý, và ta thấy cấu trúc dữ liệu cứng nhắc đang âm thầm làm chậm tốc độ phát triển sản phẩm theo cách khó đo lường nhưng rất thực tế. SQL vẫn là lựa chọn đúng, cho đúng bài toán Ba vấn đề trên không phải lý do để từ bỏ relational database. Đây là lý do để hiểu rõ hơn khi nào nó là lựa chọn tốt nhất. Vấn đề nảy sinh khi áp dụng relational database cho những bài toán khác với bản chất thiết kế của nó: dữ liệu sản phẩm cần thay đổi cấu trúc thường xuyên, thông tin người dùng với nhiều thuộc tính lồng nhau, luồng sự kiện từ hàng triệu người dùng, hay nội dung số với định dạng đa dạng. Khi hệ thống bắt đầu mở rộng, câu hỏi không còn là "SQL hay NoSQL?" mà nên là: Dữ liệu của ứng dụng/dịch vụ này cần được tổ chức như thế nào để có thể mở rộng độc lập, thay đổi cấu trúc mà không gây các tác động đến kết nối và sự liền mạch, và phục vụ đúng các yêu cầu truy cập của nó? Với một số hệ thống, câu trả lời vẫn là relational database. Với một số hệ thống khác, đặc biệt là những nơi dữ liệu thay đổi cấu trúc thường xuyên hoặc cần mở rộng linh hoạt theo chiều ngang - câu trả lời dần hướng về phía các mô hình database khác. Document database là một trong những mô hình được nhiều hệ thống lớn lựa chọn cho nhóm bài toán thứ hai. Trong bài tiếp theo, chúng ta sẽ đi vào câu hỏi thực tế nhất: relational database và document database khác nhau ở đâu — và khi nào nên chọn loại nào cho từng phần của hệ thố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 

Trong ngành F&B, sự tăng trưởng sẽ kéo theo áp lực lên toàn bộ hệ thống vận hành - từ xử lý đơn hàng, quản lý khách hàng đến đảm bảo trải nghiệm trên hàng trăm điểm bán. Đó cũng là bài toán mà Golden Gate - một trong những hệ thống F&B lớn tại Việt Nam - phải đối mặt khi bước vào giai đoạn tăng tốc mở rộng.  Tăng trưởng càng nhanh - Thách thức công nghệ càng lộ rõ Với quy mô khoảng 600 nhà hàng, hơn 35 thương hiệu và gần 50 hệ thống ứng dụng vận hành đồng thời, Golden Gate là một ví dụ điển hình cho độ phức tạp của bài toán công nghệ trong F&B. Khi số lượng điểm bán và thương hiệu tăng lên, hệ thống không chỉ phải xử lý nhiều hơn, mà còn phải xử lý trong những điều kiện khó dự đoán hơn - đặc biệt là các thời điểm lưu lượng tăng đột biến. Ở giai đoạn đầu, những giới hạn của hệ thống có thể chưa rõ ràng. Nhưng khi bước vào “pha” mở rộng nhanh, các thách thức bắt đầu xuất hiện. Đó là độ trễ trong giờ cao điểm, là việc triển khai thay đổi hệ thống mất nhiều thời gian hơn dự kiến, hay sự phụ thuộc vào các thao tác thủ công để duy trì vận hành ổn định. Những vấn đề này không xảy ra đồng loạt, nhưng tích tụ theo thời gian và dần trở thành lực cản đối với tăng trưởng. Đáng chú ý, trong ngành F&B, những thách thức này không dừng lại ở hệ thống mà nhanh chóng phản ánh ra trải nghiệm khách hàng. Với hơn 18 triệu lượt khách mỗi năm, bất kỳ gián đoạn nào trong quá trình đặt bàn, gọi món hay thanh toán đều có thể ảnh hưởng trực tiếp đến doanh thu và mức độ hài lòng. Chính những áp lực này buộc Golden Gate phải nhìn lại toàn bộ nền tảng công nghệ, không phải để tối ưu từng phần, mà để tái cấu trúc một cách tổng thể. Không chỉ là chuyển đổi hạ tầng, mà là một bài toán đồng phát triển Thay vì tiếp cận theo hướng “triển khai Cloud”, Golden Gate lựa chọn một hướng đi khác: bắt đầu từ bài toán vận hành và tìm lời giải công nghệ phù hợp. Đây cũng là điểm khởi đầu cho quá trình hợp tác với FPT Cloud. Trong quá trình triển khai, FPT không chỉ đóng vai trò là nhà cung cấp hạ tầng mà còn tham gia trực tiếp vào quá trình đánh giá và thiết kế lại hệ thống cùng đội ngũ IT của Golden Gate. Toàn bộ các ứng dụng, hạ tầng và luồng dữ liệu được rà soát để xác định đâu là điểm nghẽn thực sự ảnh hưởng đến khả năng mở rộng và vận hành. [caption id="attachment_71564" align="aligncenter" width="2560"] Anh Đào Văn Hoàn - Head of ITS, Golden Gate Group chia sẻ về hiệu quả chuyển đổi lên Cloud. Ảnh: FPT Smart Cloud.[/caption] Từ đó, một kiến trúc mới được xây dựng với mục tiêu không chỉ cải thiện hiệu năng mà còn tạo ra một nền tảng có thể mở rộng linh hoạt theo nhu cầu thực tế kinh doanh. Việc chuyển đổi lên Cloud vì vậy không đơn thuần là thay đổi nơi đặt hệ thống, mà là chuyển đổi cách hệ thống vận hành - từ mô hình hạ tầng cố định sang mô hình có thể co giãn theo thời gian thực. Quá trình này đòi hỏi sự phối hợp chặt chẽ giữa hai bên, bởi với các hệ thống quy mô lớn, không tồn tại một “mô hình chuẩn” có thể áp dụng sẵn. Mỗi quyết định về kiến trúc đều phải gắn trực tiếp với đặc thù vận hành của doanh nghiệp. Triển khai trong thời gian ngắn, nhưng không đánh đổi sự ổn định Một trong những thách thức lớn nhất của các dự án chuyển đổi hạ tầng là làm sao vừa thay đổi hệ thống, vừa không ảnh hưởng đến hoạt động kinh doanh đang diễn ra. Với Golden Gate, yêu cầu này càng khắt khe hơn khi hệ thống phải vận hành liên tục trên toàn chuỗi. Toàn bộ 12 ứng dụng với khoảng 70 máy chủ đã được chuyển đổi lên nền tảng Cloud trong thời gian ngắn, nhưng vẫn đảm bảo không gián đoạn vận hành. Để làm được điều đó, quá trình triển khai được chia thành nhiều giai đoạn với các phương án như chạy song song hệ thống, kiểm thử tải và cắt chuyển có kiểm soát. Điều này cho thấy trong các dự án chuyển đổi quy mô lớn, công nghệ chỉ là một phần của bài toán. Phần còn lại nằm ở phương pháp triển khai và khả năng kiểm soát rủi ro - nơi sự phối hợp giữa đội ngũ FPT Cloud và Golden Gate đóng vai trò quyết định. Khi hạ tầng không còn là điểm nghẽn của tăng trưởng Sau khi hoàn tất chuyển đổi, giá trị của việc hợp tác bắt đầu thể hiện rõ ở cách hệ thống vận hành. Khả năng tự động mở rộng giúp hệ thống thích ứng linh hoạt với các đợt traffic tăng đột biến, thay vì phụ thuộc vào dự báo trước hoặc can thiệp thủ công. Điều này đặc biệt quan trọng trong ngành F&B, nơi doanh thu thường tập trung vào các khung giờ cao điểm. Ở cấp độ vận hành, việc chuẩn hóa hạ tầng và áp dụng các công cụ giám sát tập trung giúp doanh nghiệp chuyển từ trạng thái phản ứng sang trạng thái chủ động. Các sự cố có thể được phát hiện sớm và xử lý nhanh hơn, giảm thiểu ảnh hưởng đến khách hàng. Đồng thời, việc rút ngắn thời gian triển khai và cập nhật hệ thống cũng tạo điều kiện để Golden Gate linh hoạt hơn trong việc phát triển sản phẩm, triển khai chương trình marketing và thử nghiệm các mô hình dịch vụ mới. Khi đó, công nghệ không còn là yếu tố cần “theo kịp”, mà trở thành nền tảng hỗ trợ doanh nghiệp đi nhanh hơn. Từ một dự án công nghệ mở ra nền tảng cho tăng trưởng dài hạn Điểm đáng chú ý trong quá trình hợp tác giữa FPT Cloud và Golden Gate không nằm ở việc “chuyển đổi thành công”, mà ở cách tiếp cận. Thay vì coi Cloud là một sản phẩm, hai bên tiếp cận như một nền tảng cần được thiết kế và vận hành cùng nhau. Khi hạ tầng không còn là giới hạn, doanh nghiệp có thể tập trung vào những yếu tố tạo ra giá trị thực sự: trải nghiệm khách hàng, tối ưu vận hành và khai thác dữ liệu. Đồng thời, nền tảng công nghệ linh hoạt cũng mở ra dư địa cho các bước phát triển tiếp theo, từ mở rộng hệ sinh thái số đến đáp ứng các yêu cầu về quy mô và quản trị trong dài hạn. Trong bối cảnh ngành F&B ngày càng cạnh tranh, câu chuyện này phản ánh một xu hướng rõ ràng: lợi thế không còn nằm ở việc doanh nghiệp có công nghệ hay không, mà ở cách xây dựng và vận hành nền tảng công nghệ phù hợp nhằm giải quyết bài toán hiện tại, cũng  trở thành nền móng cho tăng trưởng bền 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 

Trong nhiều ngành nghề kinh doanh, câc dịp cao điểm như flash sale, sự kiện tri ân, Lễ Tết...thường dẫn đến lượng truy cập lớn trên hệ thống. Và kịch bản quen thuộc thường xảy ra: hệ thống bắt đầu chậm, sau đó lỗi hàng loạt chỉ sau vài phút traffic tăng. Điều đáng nói ở đây là gì? Đội ngũ vận hành đã có sự chuẩn bị. Server được tăng gấp đôi, thậm chí gấp ba tài nguyên từ chiều hôm trước. Hệ thống giám sát (Monitoring) đã bật cảnh báo từ sớm. Nhưng mọi nỗ lực dường như vô nghĩa và hệ thống vẫn "chết đứng" ngay vào những phút đầu tiên nổ ra sự kiện. Tại sao một hệ thống được chuẩn bị kỹ lưỡng về hạ tầng vẫn sập? Câu trả lời nằm ở một góc tối ít ai ngờ tới và thường bị bỏ qua đầu tiên: Không phải do Web Server đuối sức, cũng không phải do nghẽn băng thông mà thủ phạm chính là Database. Hệ thống của bạn không sập đơn thuần vì lượng traffic quá đông. Nguyên nhân cốt lõi là do kiến trúc hệ thống vốn dĩ không được sinh ra để phục vụ quy mô khổng lồ đó. Có 3 điểm nghẽn bóp nghẹt dòng chảy dữ liệu và cả ba đều liên quan trực tiếp đến cách Database được thiết kế từ gốc, chứ không phải do cách nó được phân bổ tài nguyên vận hành. 1. Khi Vertical Scaling chạm giới hạn của Database Một phản xạ phổ biến khi hệ thống bắt đầu chậm là nâng cấp phần cứng của server database. CPU được tăng thêm lõi xử lý, RAM được mở rộng, ổ lưu trữ được thay bằng loại có tốc độ cao hơn. Cách tiếp cận này được gọi là vertical scaling nhằm tăng sức mạnh cho một máy chủ duy nhất. Trong giai đoạn đầu, vertical scaling thường mang lại cải thiện rõ rệt. Các truy vấn dữ liệu (database queries) được xử lý nhanh hơn và thời gian phản hồi của hệ thống giảm xuống. Tuy nhiên, cách mở rộng này có một giới hạn tự nhiên: toàn bộ dữ liệu và toàn bộ truy cập vẫn đang tập trung vào một node database duy nhất. Khi lưu lượng truy cập tiếp tục tăng, database server dần trở thành một “điểm nghẽn trung tâm”. CPU có thể chạm ngưỡng sử dụng tối đa, hàng nghìn truy vấn đồng thời bắt đầu cạnh tranh tài nguyên, và thời gian xử lý mỗi request tăng lên nhanh chóng. Ở giai đoạn này, việc tiếp tục nâng cấp server thường mang lại hiệu quả rất hạn chế. Bởi dù phần cứng có mạnh đến đâu, một database đơn lẻ vẫn phải xử lý toàn bộ workload của hệ thống. Vấn đề lúc này không còn là server yếu, mà là kiến trúc database chưa được thiết kế để mở rộng theo lưu lượng truy cập. 2. Giới hạn kết nối: khi Database hết “làn xử lý” Hãy hình dung database như một trạm thu phí trên cao tốc với 200 làn xe cố định. Ngày thường, xe đi lại mượt mà. Nhưng vào 12:00 ngày 4.4, 50.000 xe đổ vào cùng lúc. Dù mỗi làn xử lý rất nhanh tuy nhiên ùn tắc vẫn xảy ra từ hàng cây số trước trạm. Trong hầu hết các hệ thống web, mỗi request từ người dùng sẽ cần một kết nối tới database để đọc hoặc ghi dữ liệu. Số lượng kết nối này được quản lý thông qua cơ chế gọi là connection pool. Trong điều kiện bình thường, cơ chế này hoạt động rất ổn định. Các request được phân phối qua các kết nối sẵn có và database xử lý chúng với độ trễ rất thấp. Nhưng khi traffic tăng đột biến, số lượng request đồng thời có thể tăng gấp hàng chục lần trong vài giây. Khi đó, toàn bộ connection pool nhanh chóng bị sử dụng hết. Những request mới buộc phải chờ kết nối trống trước khi được xử lý. Điều đáng chú ý là ở nhiều sự cố production, database server vẫn còn tài nguyên CPU và RAM. Tuy nhiên, vì tất cả các kết nối đều đã được sử dụng, hệ thống vẫn không thể xử lý thêm request mới. Trong một số trường hợp, tình hình còn trở nên tệ hơn khi ứng dụng bắt đầu tự động retry các request bị timeout. Những request retry này tạo thêm kết nối mới tới database, khiến connection pool cạn nhanh hơn và tạo ra hiệu ứng quá tải dây chuyền 3. Write Storm — sự bùng nổ lượng truy cập từ E-commerce và Fintech Trong các hệ thống có nhiều giao dịch như thương mại điện tử hoặc fintech, một vấn đề khác thường xuất hiện khi lượng giao dịch hoặc truy cập tăng mạnh: write storm trong database. Relational database được thiết kế để đảm bảo tính chính xác và nhất quán của dữ liệu. Khi một giao dịch đang cập nhật một bản ghi, database thường khóa tạm thời bản ghi đó để tránh việc nhiều giao dịch thay đổi dữ liệu cùng lúc. Trong ngày thường, cơ chế này hoạt động hoàn hảo. Nhưng trong flash sale và khi 10.000 người cùng bấm "Thanh toán" trong 3 giây cho cùng một sản phẩm theo đó tất cả 10.000 transaction đó đang tranh nhau một row lock. Kết quả: không phải 10.000 transactions xử lý song song. Mà là 10.000 transactions xếp hàng tuần tự, mỗi cái chờ cái trước hoàn thành. Trong các hệ thống có lưu lượng giao dịch lớn, hiện tượng này có thể lan rộng rất nhanh và trở thành nguyên nhân chính khiến database phản hồi chậm hoặc ngừng xử lý request mới. Bài toán thực sự không phải là server, mà là kiến trúc Database Nhìn lại, ba nguyên nhân trên đều dẫn tới một kết luận giống nhau: trong các hệ thống có lượng người dùng lớn, việc mở rộng server chỉ là một phần của bài toán. Yếu tố quan trọng hơn là cách kiến trúc database được thiết kế để xử lý lưu lượng truy cập tăng dần theo thời gian. Trong giai đoạn đầu của một sản phẩm, việc sử dụng một relational database chạy trên một node duy nhất là hoàn toàn hợp lý. Nó giúp hệ thống đơn giản, dễ vận hành và đảm bảo tính nhất quán của dữ liệu. Nhưng khi hệ thống phát triển và lượng giao dịch tăng lên, kiến trúc này bắt đầu bộc lộ giới hạn. Việc tập trung toàn bộ dữ liệu và toàn bộ truy cập vào một điểm duy nhất khiến database trở thành nút thắt cổ chai của toàn bộ hệ thống. Đó là lý do nhiều tổ chức khi thiết kế hệ thống ở quy mô lớn thường bắt đầu bằng một câu hỏi khác: Database cần được tổ chức như thế nào để hệ thống có thể phân tán tải và mở rộng theo lưu lượng truy cập, thay vì dồn toàn bộ áp lực vào một máy chủ duy nhất? Câu hỏi này chính là điểm khởi đầu của nhiều kiến trúc database hiện đại.

Trong bối cảnh các mối đe dọa an ninh mạng ngày càng tinh vi, nền tảng FPT AppSec đã khẳng định năng lực khi xuất sắc giành giải Đồng (Bronze) tại hạng mục Application Security của Cybersecurity Excellence Awards. Đây là một trong những giải thưởng uy tín do Cybersecurity Insiders tổ chức, với hơn 600.000 chuyên gia an ninh mạng và CNTT toàn cầu tham gia đánh giá. Các đề cử được xét duyệt dựa trên những tiêu chí khắt khe về tính sáng tạo, hiệu quả, tác động và khả năng bảo vệ doanh nghiệp trước các mối đe dọa ngày càng phức tạp.  Chia sẻ về khoảnh khắc nhận giải, anh Bùi Song Toàn – Leader dự án – cho biết: “Thật ra lúc đầu mình không có cảm xúc gì hoành tráng lắm, chủ yếu là nhẹ nhõm. Nhẹ nhõm vì hướng anh em chọn từ đầu là đúng“. Với anh, giải thưởng không chỉ là thành tích mà còn là một sự xác nhận: “Giải này như một cái gật đầu từ bên ngoài: ‘Ừ, đúng rồi đó“.  FPT AppSec là nền tảng Application Security Posture Management (ASPM) được phát triển nhằm giải quyết một trong những thách thức lớn nhất hiện nay: tình trạng phân mảnh và thiếu tính chủ động trong bảo mật ứng dụng, đặc biệt trong môi trường cloud-native.  Khác với các phương pháp truyền thống vốn dựa vào nhiều công cụ rời rạc và các đợt quét định kỳ, FPT AppSec cung cấp khả năng quan sát liên tục đối với toàn bộ bề mặt tấn công của ứng dụng. Nền tảng này cho phép tổng hợp và phân tích các lỗ hổng, điểm yếu bảo mật và yếu tố rủi ro trong một bức tranh thống nhất, từ đó giúp doanh nghiệp đưa ra quyết định chính xác và kịp thời.  Anh Bùi Song Toàn (áo cam) và team FPT AppSec. Đáng chú ý, bài toán khó nhất mà team phải đối mặt không nằm ở công nghệ mà ở cách xác định giá trị thực của bảo mật. Như anh Toàn chia sẻ: “Bài toán khó nhất không phải về code, mà về mục tiêu: làm sao để bảo mật thực sự có ích chứ không chỉ có mặt“.  Thực tế, nhiều công cụ bảo mật hiện nay tạo ra khối lượng lớn cảnh báo nhưng lại thiếu khả năng định hướng hành động. Điều này khiến đội ngũ phát triển khó ưu tiên xử lý, dẫn đến hiệu quả bảo mật không như kỳ vọng. Xuất phát từ vấn đề đó, đội ngũ đã dành nhiều thời gian để tìm lời giải cho câu hỏi: “Làm sao để nói cho đúng nguy cơ nào thực sự nguy hiểm?“.  Một trong những điểm khác biệt nổi bật của FPT AppSec đến từ nền tảng nghiên cứu chuyên sâu. Sản phẩm được xây dựng dựa trên kinh nghiệm thực tiễn trong việc phát hiện và công bố các lỗ hổng bảo mật, qua đó tích hợp góc nhìn của “attacker” vào quá trình phân tích và ưu tiên rủi ro. Như anh Toàn nhấn mạnh, đây là quá trình “đi từ thực tế”: tự nghiên cứu lỗ hổng, tham gia coordinated disclosure và chuyển hóa hiểu biết đó thành logic đánh giá rủi ro trong sản phẩm.  Không chỉ dừng lại ở việc phát hiện, FPT AppSec còn hỗ trợ doanh nghiệp chuyển đổi từ cách tiếp cận bảo mật dựa trên tuân thủ sang mô hình quản trị rủi ro chủ động. Bằng việc đặt các lỗ hổng trong bối cảnh vận hành thực tế, nền tảng giúp giảm thiểu tình trạng “alert fatigue” và nâng cao hiệu quả xử lý.  Theo anh Toàn, điều giúp sản phẩm ghi điểm với hội đồng quốc tế không nằm ở cách “trình bày”, mà ở bản chất giải pháp: “FPT AppSec giải một bài toán thật, theo cách thật. Không phải marketing“. Đồng thời, toàn bộ mô tả sản phẩm đều có thể kiểm chứng từ chính hoạt động nghiên cứu và triển khai thực tế của team.  Là một sản phẩm thuộc hệ sinh thái của FPT Smart Cloud, FPT AppSec tiếp tục khẳng định năng lực nghiên cứu, phát triển và làm chủ công nghệ của FPT trong lĩnh vực an toàn thông tin.  Giải thưởng lần này không chỉ là sự ghi nhận về mặt chuyên môn mà còn mở ra cơ hội để các giải pháp “Make in Vietnam” tiến xa hơn trên thị trường quốc tế. Với team phát triển, đây cũng là một cột mốc để nhìn lại và tiếp tục tiến lên. Như anh Toàn chia sẻ: “Giải thưởng này là lý do để mình nhìn lại xem đã đi đúng hướng chưa, nhưng không phải lý do để dừng lại“. 

Trong nhiều năm, F&B được nhìn nhận là ngành xoay quanh mặt bằng, sản phẩm và trải nghiệm tại chỗ. Tuy nhiên, nhận định này đã trở nên lỗi thời khi quy mô kinh tế số Việt Nam đã vượt mốc hàng chục tỷ USD và tiếp tục tăng trưởng mạnh, kéo theo sự bùng nổ của các dịch vụ tiêu dùng trực tuyến như giao đồ ăn và đặt bàn qua app. Điều này khiến mỗi trải nghiệm ăn uống ngày nay không còn dừng ở “món ăn”, mà được quyết định bởi tốc độ xử lý đơn, độ ổn định hệ thống và khả năng cá nhân hóa theo thời gian thực. Khi mà doanh thu có thể tăng vọt chỉ trong vài giờ cao điểm, mọi giới hạn về công nghệ đều nhanh chóng trở thành điểm nghẽn tăng trưởng. Đặc thù vận hành khiến F&B trở thành một bài toán công nghệ phức tạp Điểm làm nên sự khác biệt của F&B không nằm ở quy mô lớn hay nhỏ, mà nằm ở tính “không ổn định có hệ thống” trong vận hành. Khác với nhiều ngành có nhu cầu tương đối dự đoán được, F&B thường xuyên phải đối mặt với những biến động đột ngột về lưu lượng - nơi nhu cầu có thể tăng vọt chỉ trong vài giờ cao điểm và nhanh chóng quay về mức bình thường ngay sau đó. Chỉ trong vài giờ cao điểm của các dịp lễ hoặc chiến dịch marketing, lượng truy cập hệ thống có thể tăng vọt nhiều lần so với bình thường. Chính đặc điểm này khiến cho bài toán công nghệ trong F&B không còn đơn thuần là “đủ dùng", mà phải luôn trong trạng thái sẵn sàng thích ứng. Nếu hệ thống không kịp phản ứng lại, hậu quả không chỉ là chậm đơn hay lỗi app, mà là trải nghiệm khách hàng bị gián đoạn ngay tại thời điểm họ sẵn sàng chi tiêu nhất - thời điểm mang tính quyết định về doanh thu. Song song với đó là sự phức tạp đến từ mô hình vận hành đa thương hiệu. Một doanh nghiệp F&B quy mô lớn không chỉ quản lý một chuỗi, mà thường vận hành hàng chục thương hiệu khác nhau, mỗi thương hiệu lại có định vị, tệp khách hàng và mô hình vận hành riêng. Điều này kéo theo hàng loạt hệ thống ứng dụng song song - từ POS, CRM, loyalty cho đến các ứng dụng dành cho khách hàng. Vấn đề không chỉ là “có bao nhiêu hệ thống”, mà là làm thế nào để những hệ thống này vừa độc lập đủ để linh hoạt, vừa kết nối đủ để tạo thành một bức tranh vận hành thống nhất. Áp lực càng trở nên rõ rệt hơn khi đặt trong bối cảnh tăng trưởng nhanh của thị trường. Không ít doanh nghiệp đặt mục tiêu mở rộng từ vài trăm lên hàng nghìn nhà hàng trong vòng vài năm. Khi đó, hạ tầng công nghệ không còn đơn thuần là công cụ hỗ trợ, mà trở thành yếu tố quyết định xem doanh nghiệp có thể mở rộng nhanh đến đâu. Nếu hệ thống không đủ linh hoạt, mỗi lần mở thêm điểm bán sẽ kéo theo một chuỗi các điều chỉnh phức tạp về hạ tầng, khiến tốc độ tăng trưởng bị chậm lại đáng kể. Ở một góc nhìn khác, F&B cũng là ngành có “ngưỡng chịu lỗi” gần như bằng không. Một sự cố hệ thống trong giờ cao điểm không chỉ ảnh hưởng đến một giao dịch, mà có thể tác động đồng thời đến hàng trăm, hàng nghìn khách hàng. Điều này khiến yêu cầu về độ ổn định và khả năng phục hồi của hệ thống trở nên khắt khe hơn rất nhiều so với nhiều ngành khác. Chính những đặc thù này đã đẩy quá trình chuyển đổi số trong F&B đi nhanh hơn so với nhiều lĩnh vực khác. Tuy nhiên, điều đáng chú ý là chuyển đổi số trong ngành không bắt đầu từ công nghệ, mà bắt đầu từ áp lực vận hành và kỳ vọng của khách hàng. Các doanh nghiệp có thể triển khai ứng dụng khách hàng, xây dựng chương trình loyalty hay đầu tư vào dữ liệu, nhưng nếu nền tảng hạ tầng phía dưới không đủ linh hoạt, mọi nỗ lực phía trên sẽ nhanh chóng chạm trần. Đây là điểm mà nhiều doanh nghiệp nhận ra: chuyển đổi số không chỉ là “thêm một lớp công nghệ”, mà là tái thiết lại nền móng vận hành. Trong bức tranh đó, Cloud dần trở thành lựa chọn mang tính nền tảng. Không chỉ bởi khả năng mở rộng linh hoạt, mà còn vì Cloud cho phép doanh nghiệp chuyển từ tư duy đầu tư cố định sang vận hành linh hoạt, từ phản ứng bị động sang chủ động thích ứng với biến động. Golden Gate Group: Khi chuyển đổi công nghệ trở thành đòn bẩy tăng trưởng Golden Gate Group là một ví dụ điển hình cho cách một doanh nghiệp F&B quy mô lớn tiếp cận bài toán công nghệ. Với hơn 500 nhà hàng thuộc hơn 40 thương hiệu tại 42 tỉnh thành toàn quốc - số lượng được dự kiến sẽ tiếp tục tăng trưởng trong tương lai - đặt áp lực lớn lên đội ngũ công nghệ phải sẵn sàng cho bài toán vận hành liên tục.Trong giai đoạn sử dụng mô hình hạ tầng truyền thống mỗi lần cần tăng tài nguyên cho vận hành, Doanh nghiệp này cần phải có thời gian chuẩn bị và chi phí đáng kể, trong khi khả năng dự phòng và giám sát còn hạn chế. Điều này tạo ra một nghịch lý: doanh nghiệp có thể sẵn sàng về mặt kinh doanh để tăng trưởng, nhưng hệ thống công nghệ lại trở thành điểm nghẽn. [caption id="attachment_71479" align="aligncenter" width="2560"] Anh Đào Văn Hoàn - Head of ITS, Golden Gate Group chia sẻ tại một sự kiện tại Hà Nội.[/caption] Quyết định chuyển đổi lên Cloud không đơn thuần là một thay đổi về hạ tầng, mà là một bước tái cấu trúc toàn diện. Toàn bộ hệ thống được đánh giá lại, thiết kế kiến trúc mới và thực hiện chuyển đổi trong một lộ trình ngắn nhưng kiểm soát chặt chẽ. Việc hoàn tất chuyển đổi hàng chục ứng dụng trong thời gian chỉ khoảng một tháng, với yêu cầu không làm gián đoạn vận hành tại các điểm kinh doanh, cho thấy mức độ quyết liệt cũng như năng lực triển khai của đội ngũ. Điều quan trọng hơn nằm ở những gì diễn ra sau đó. Khi hệ thống có khả năng tự động mở rộng theo nhu cầu, bài toán traffic đột biến không còn là rủi ro lớn. Khi môi trường phát triển và vận hành được chuẩn hóa, tốc độ triển khai sản phẩm được rút ngắn đáng kể. Và khi toàn bộ hệ thống có thể được giám sát theo thời gian thực, việc xử lý sự cố chuyển từ bị động sang chủ động. Nói cách khác, với Golden Gate Group công nghệ không còn là “chi phí cần tối ưu” mà giờ đây trở thành “đòn bẩy giúp tăng tốc” trong chiến lược dài hạn của doanh nghiệp này. Từ hạ tầng đến hệ sinh thái: Bước đi tiếp theo của F&B Điểm đáng chú ý là chuyển đổi công nghệ trong F&B không dừng lại ở việc tối ưu vận hành hiện tại. Khi nền tảng hạ tầng đã đủ linh hoạt, doanh nghiệp có thể bắt đầu xây dựng những lớp giá trị cao hơn, đặc biệt là xoay quanh dữ liệu và trải nghiệm khách hàng. Việc kết nối các hệ thống rời rạc thành một nền tảng dữ liệu thống nhất cho phép doanh nghiệp hiểu khách hàng ở mức sâu hơn - không chỉ là họ mua gì, mà còn là họ có xu hướng quay lại khi nào, phản ứng ra sao với từng loại ưu đãi, hay khả năng chi tiêu trong từng bối cảnh. Đồng thời, Cloud cũng tạo điều kiện để mở rộng các dịch vụ số như ứng dụng khách hàng, chương trình thành viên hay các kênh bán hàng trực tuyến, mà không cần lo ngại về giới hạn hạ tầng. Khi đó, F&B không còn là một chuỗi nhà hàng, mà dần trở thành một hệ sinh thái dịch vụ xoay quanh trải nghiệm ẩm thực. Ngành F&B đang bước vào một giai đoạn mà tăng trưởng không còn phụ thuộc chủ yếu vào số lượng cửa hàng, mà phụ thuộc vào khả năng vận hành ở quy mô lớn với hiệu quả cao. Trong bối cảnh đó, công nghệ - đặc biệt là Cloud và các kiến trúc hiện đại - đóng vai trò như nền móng cho toàn bộ chiến lược phát triển. 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 

FPT Database Engine chính thức giới thiệu tính năng Point-In-Time Recovery (PITR). Đây là bước tiến quan trọng trong việc nâng cao khả năng dự phòng và hồi phục dữ liệu cho các doanh nghiệp đang vận hành cơ sở dữ liệu trên nền tảng Cloud. Point-In-Time Recovery (PITR) là gì? PITR là tính năng cho phép người dùng khôi phục dữ liệu MySQL hoặc PostgreSQL về một thời điểm cụ thể (Timestamp) trong quá khứ. Thay vì chỉ có thể khôi phục về các bản backup cố định theo ngày, PITR cung cấp sự linh hoạt tối đa để "du hành thời gian" về sát thời điểm xảy ra sự cố. Tính năng này là lá chắn bảo vệ dữ liệu khỏi: Lỗi thao tác người dùng: Xóa nhầm database hoặc table. Sự cố ứng dụng: Dữ liệu bị hỏng hoặc ghi đè do lỗi logic từ phía phần mềm. Rủi ro mất mát dữ liệu: Đảm bảo tính toàn vẹn và tuân thủ các chính sách bảo mật khắt khe Cơ chế hoạt động và Phạm vi hỗ trợ Đặc điểmMySQL PITRPostgreSQL PITRCơ chế chính+ Hệ thống cho phép cấu hình bật tính năng PITR để kích hoạt cơ chế lưu trữ binary log (binlog) + Hệ thống duy trì backup full định kỳ và Binlog liên tục theo lịch đã cấu hình. Binlog được lưu trữ an toàn theo retention policy được định nghĩa cho backup full. + Người dùng chỉ cần chọn thời điểm (timestamp) cần khôi phục trong phạm vi retention. + Hệ thống sẽ tạo một database instance mới được phục hồi đến thời điểm đó (không ghi đè lên instance hiện tại).Khôi phục cơ sở dữ liệu PostgreSQL đến thời điểm chỉ định (timestamp) hoặc LSN cụ thể trong khoảng thời gian lưu giữ WALPhạm vi hỗ trợCloud Database (Single node hoặc HA cluster).Cloud Database (Single node hoặc HA cluster).Thời gian lưu trữMặc định 7 ngày (có thể tùy chỉnh).Mặc định 7 ngày (có thể tùy chỉnh).Phương thức phục hồiKhôi phục về một Instance mới (không ghi đè instance gốc).Khôi phục về một Instance mới (không ghi đè instance gốc). Hướng dẫn sử dụng nhanh trên FPT Cloud Portal Người dùng có thể dễ dàng quản lý PITR thông qua giao diện Portal hoặc API của FPT Database Engine: Kích hoạt PITR: Enable PITR khi enable dịch vụ Backup. Truy cập cluster -> Mở tab Backup & Restore -> Enable PIT Thực hiện khôi phục: Truy cập Portal Cloud Database → Chọn MySQL/PostgreSQL Instance. Mở tab Backup & Restore -> chọn tab Restore. Chọn Recover to point in time Nhập thời điểm cần khôi phục → Xác nhận thao tác. Hệ thống sẽ tạo một instance mới từ dữ liệu khôi phục tại thời điểm bạn chọn. Những lưu ý quan trọng Với MySQLVới PostgreSQLPITR chỉ hoạt động khi:- Binary log đang bật- Instance có ít nhất một phiên bản full backup hợp lệ+ Thời điểm khôi phục phải nằm trong khoảng retention binlog.+ Thời gian khôi phục phụ thuộc dung lượng dữ liệu & tốc độ I/O.+ Trong môi trường HA, PITR được thực hiện từ node primary.+ Chỉ khả dụng cho các instance đã bật tính năng archived WAL logs.+ Thời điểm khôi phục hợp lệ nằm trong thời gian lưu giữ WAL (theo backup retention và thời điểm bật tính năng archived WAL Log).+ Việc khôi phục có thể mất vài phút tùy dung lượng dữ liệu và tốc độ I/O. Với việc bổ sung tính năng Point-In-Time Recovery, FPT Database Engine tiếp tục khẳng định cam kết mang lại giải pháp an toàn, tin cậy và tuân thủ các tiêu chuẩn bảo vệ dữ liệu cao nhất cho khách hàng.

Tại sự kiện Partner Appreciation Day 2026 thường niên của hãng công nghệ Veeam, FPT Smart Cloud được vinh danh đối tác Platinum - cấp độ đối tác cao cấp nhất trong hệ thống phân hạng đối tác của Veeam, đồng thời là đối tác duy nhất tại Việt Nam đạt được cấp độ cao cấp nhất này.  [caption id="attachment_71461" align="aligncenter" width="2560"] Đại diện FPT Smart Cloud nhận chứng nhận từ hãng công nghệ Veeam tại sự kiện.[/caption]   Để đạt được cột mốc này, FPT Smart Cloud đã phải đáp ứng các tiêu chuẩn khắt khe về chứng chỉ kỹ thuật, và đặc biệt là sự hài lòng của khách hàng trong việc triển khai, vận hành các giải pháp Offsite Backup & DRaaS (Disaster Recovery as a Service). Việc trở thành đối tác cấp cao nhất của Veeam là cột mốc quan trọng khẳng định năng lực cung cấp dịch vụ của FPT Cloud tới khách hàng doanh nghiệp tại Việt Nam.  Theo đó, các khách hàng sử dụng dịch vụ trên nền tảng điện toán đám  mây FPT Cloud sẽ nhận được những lợi thế đặc biệt về: (1) Chuyên môn kỹ thuật cao cấp: Khách hàng được tư vấn và hỗ trợ bởi đội ngũ kỹ sư có trình độchuyên môn cao nhất, được đào tạo trực tiếp từ Veeam; (2) Giải pháp tối ưu hóa: Tiếp cận các kiến trúc hệ thống tiên tiến nhất, đảm bảo dữ liệu luôn khả dụng và an toàn trước mọi rủi ro an ninh mạng; (3) Hỗ trợ ưu tiên: Với tưcách là đối tác chiến lược cấp cao, khách hàng sẽ nhận được sự hỗ trợ kỹ thuật ưu tiên ở mức cao nhất từ hãng, giúp giải quyết các vấn đề phát sinh một cách nhanh chóng nhất; (4) Chi phí hiệu quả: Khách hàng được hưởng lợi từcác chính sách giá và chương trình ưu đãi tốt nhất của Veeam thông qua FPT Smart Cloud.  Chị Phương Anh, Nguyễn - Channel Manager, CLV, Veeam chia sẻ: “Với vai trò là đối tác Platinum VCSP, FPT Smart Cloud đại diện cho cấp độ hợp tác cao nhất trong hệ sinh thái Veeam Cloud & Service Provider. Cột mốc này không chỉ phản ánh hiệu quả kinh doanh ấn tượng, mà còn thể hiện năng lực kỹ thuật chuyên sâu, chất lượng dịch vụ vượt trội và cam kết lâu dài trong việc cung cấp các dịch vụ bảo vệ dữ liệu đáng tin cậy, an toàn và có khả năng mở rộng cho khách hàng tại Việt Nam.”  Veeam Software là hãng công nghệ có trụ sở đặt tại Thụy Sĩ, được thành lập từ năm 2006, tập trung vào lĩnh vực sao lưu và phục hồi dữ liệu. Các sản phẩm của Veem được Gartner đánh giá có chất lượng dẫn đầu thị trường trong nhiều năm liền. Veeam có hơn 450.000 khách hàng doanh nghiệp trên toàn thế giới đang sử dụng các sản phẩm Veeam để sao lưu, phục hồi và duy trì tính liên tục cho hệ thống CNTT.  Tìm hiểu thêm thông tin chi tiết về dịch vụ sao lưu dữ liệu 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: 1900 638 399 Email: support@fptcloud.com Support: m.me/fptsmartcloud 

I. Các lỗ hổng bảo mật được công bố trong tháng 02  1. Microsoft  Microsoft đã phát hành bản cập nhật bảo mật cho 58 lỗ hổng, trong đó có 6 zero day đang bị khai thác trong thực tế và 3 zero-day đã được công bố công khai.  Đợt Patch Tuesday này cũng khắc phục 5 lỗ hổng mức Critical, bao gồm:  3 lỗ hổng Elevation of Privilege  2 lỗ hổng Information Disclosure  Số lượng lỗ hổng theo từng loại như sau:  25 Elevation of Privilege vulnerabilities  5 Security Feature Bypass vulnerabilities  12 Remote Code Execution vulnerabilities  6 Information Disclosure vulnerabilities  3 Denial of Service vulnerabilities  7 Spoofing vulnerabilities  Khi BleepingComputer thống kê các bản vá Patch Tuesdat, chỉ những lỗ hổng được Microsoft phát hành trong ngày hôm đó mới được tính. Vì vậy, con số này không bao gồm 3 lỗ hổng của Microsoft Edge đã được vá trước đó trong tháng.  Microsoft bắt đầu triển khai Secure Boot certificates mới để thay thế các certificate từ năm 2011 sẽ hết hạn vào tháng 6/2026. Các Windows quality updates sẽ thu thập thông tin để xác định thiết bị có đủ điều kiện nhận certificatemới hay không, và việc cấp phát sẽ được thực hiện từng bước (phased rollout) sau khi thiết bị ghi nhận đủ tín hiệu cập nhật thành công nhằm đảm bảo an toàn. Các cập nhật không liên quan đến bảo mật được phát hành cùng đợt này bao gồm Windows 11 KB5077181, KB5075941 và Windows 10 KB5075912.  6 zero-day đang bị khai thác  CVE-2026-21510 – Windows Shell Security Feature Bypass: Lỗ hổng cho phép attacker bypass Windows SmartScreen và các Windows Shell security prompts khi nạn nhân mở một link hoặc shortcut file được tạo đặc biệt. Khi khai thác thành công, attacker có thể chạy attacker-controlled content mà không có cảnh báo bảo mật cho người dùng. Lỗ hổng nhiều khả năng liên quan đến việc bypass cơ chế Mark of the Web (MoTW).  CVE-2026-21513 – MSHTML Framework Security Feature Bypass: Đây là lỗ hổng Security Feature Bypass trong MSHTML Framework cho phép attacker bypass cơ chế bảo mật qua network do lỗi trong protection mechanismcủa MSHTML. Microsoft chưa công bố chi tiết cách thức khai thác, nhưng lỗ hổng đã được ghi nhận đang bị khai thác trong thực tế.  CVE-2026-21514 – Microsoft Word Security Feature Bypass: Lỗ hổng trong Microsoft Word cho phép attacker bypass các OLE mitigations trong Microsoft 365 và Office, vốn được thiết kế để bảo vệ khỏi vulnerable COM/OLE controls. Attacker cần gửi Office file độc hại và lừa nạn nhân mở file, tuy nhiên lỗ hổng không thể khai thác thông qua Office Preview Pane.  CVE-2026-21519 – Desktop Window Manager Elevation of Privilege: Lỗ hổng Elevation of Privilege trong Desktop Window Manager cho phép attacker sau khi khai thác thành công có thể leo thang đặc quyền lên mức SYSTEM trên hệ thống Windows. Microsoft chưa công bố chi tiết kỹ thuật về phương thức khai thác.  CVE-2026-21525 – Windows Remote Access Connection Manager Denial of Service: Lỗ hổng Denial of Service trong Windows Remote Access Connection Manager do lỗi null pointer dereference, cho phép attacker gây crashdịch vụ trên máy local. Exploit của lỗ hổng này được phát hiện trong một public malware repository vào cuối năm 2025.  CVE-2026-21533 – Windows Remote Desktop Services Elevation of Privilege: Lỗ hổng Elevation of Privilege trong Windows Remote Desktop Services do improper privilege management, cho phép attacker leo thang đặc quyền local. Exploit có thể sửa đổi service configuration key để thêm một user mới vào nhóm Administrator, giúp attacker kiểm soát hệ thống.  Các bản cập nhật gần đây từ các hãng khác  Các nhà cung cấp khác cũng đã phát hành các bản cập nhật hoặc advisory trong tháng 2/2026, bao gồm:  Adobe phát hành các bản cập nhật bảo mật cho Audition, After Effects, InDesign, Substance 3D, Adobe Lightroom Classic và nhiều phần mềm khác. Không có lỗ hổng nào trong số này đang bị khai thác.  BeyondTrust phát hành bản cập nhật bảo mật để vá một lỗ hổng Critical RCE trong phần mềm Remote Support (RS) và Privileged Remote Access (PRA).  CISA ban hành một binding operational directive mới yêu cầu các cơ quan liên bang loại bỏ các network edge devices đã hết thời gian hỗ trợ.  Cisco phát hành các bản cập nhật bảo mật cho Secure Web Appliance, Cisco Meeting Management và nhiều sản phẩm khác.  Fortinet phát hành các bản cập nhật bảo mật cho FortiOS và FortiSandbox.  Google phát hành Android February Security Bulletin, tuy nhiên bản tin này không bao gồm bản vá bảo mật nào.  n8n đã vá các lỗ hổng critical có thể được sử dụng để bypass bản vá trước đó của lỗ hổng RCE CVE-2025-68613.  SAP phát hành bản cập nhật bảo mật tháng 2 cho nhiều sản phẩm, bao gồm các bản vá cho hai lỗ hổng Critical.  Ngoài ra, mặc dù không phải là bản cập nhật bảo mật, Microsoft đã bắt đầu triển khai chức năng Sysmon tích hợp sẵn trong các bản Windows 11 Insider builds, điều mà nhiều quản trị viên Windows có thể thấy hữu ích.  Dưới đây là danh sách đầy đủ các lỗ hổng đã được giải quyết trong các bản cập nhật Patch Tuesday tháng 02 năm 2026.  Tag  CVE ID  CVE Title  Severity  Azure Arc  CVE-2026-24302  Azure Arc Elevation of PrivilegeVulnerability  Critical  Azure Compute Gallery  CVE-2026-23655  Microsoft ACI ConfidentialContainers Information DisclosureVulnerability  Critical  Azure Compute Gallery  CVE-2026-21522  Microsoft ACI ConfidentialContainers Elevation of PrivilegeVulnerability  Critical  Azure Front Door (AFD)  CVE-2026-24300  Azure Front Door Elevation ofPrivilege Vulnerability  Critical  Azure Function  CVE-2026-21532  Azure Function InformationDisclosure Vulnerability  Critical  Chi tiết về từng loại lỗ hổng và bản vá có thể xem thêm tại Tuesday Patch, paper.   2. Linux   CVE  Mô tả lỗ hổng  CVE-2025-71225  Lỗ hổng trong Linux kernel (md/RAID) xảy ra khi cập nhật raid_disksqua sysfs mà không suspend array, khiến r1bio có thể được giải phóng sai kích thước và truy cập bộ nhớ ngoài phạm vi. Bản vá khắc phục bằng cách suspend array trước khi cập nhật raid_disks để tránh lỗi bộ nhớ.  CVE-2025-71227  Lỗ hổng trong Linux kernel mac80211 xảy ra khi thiết bị cố kết nối vào channel không hợp lệ (ví dụ do thay đổi regulatory sau khi scan). Bản vá thay WARN bằng thông báo lỗi rõ ràng hơn để xử lý tình huống này.  CVE-2026-23211  Lỗ hổng trong Linux kernel swap subsystem có thể gây kernel panicdưới áp lực bộ nhớ cao do swap address space bị đặt read-only. Bản vá khôi phục swap address space không ở chế độ read-only để tránh lỗi này.  Chi tiết về các lỗ hổng có thể xem tại Advisories.  3. VMware   CVE  Mô tả lỗ hổng  CVE-2026-22719  CVE-2026-22719 là lỗ hổng command injection trong VMware AriaOperations, cho phép attacker unauthenticated thực thi lệnh từ xa (RCE) trong quá trình support-assisted product migration. Bản vá và workaroundđược cung cấp trong VMSA-2026-0001.  CVE-2026-22720  CVE-2026-22720 là lỗ hổng stored XSS trong VMware Aria Operations, cho phép attacker có quyền tạo custom benchmarks chèn script để thực hiện hành động quản trị. Bản vá được cung cấp trong VMSA-2026-0001.  CVE-2026-22715  CVE-2026-22715 là lỗ hổng logic flaw trong xử lý network packets của VMware Workstation và Fusion, cho phép attacker có quyền admin trên Guest VM chặn hoặc can thiệp kết nối mạng của các Guest VM khác. Khắc phục bằng cách nâng cấp lên VMware Workstation/Fusion25H2U1.  Chi tiết về các bản vá có thể xem tại Advisories  II. Một số sự kiện an ninh mạng đáng chú ý:  1. Lỗ hổng RoguePilot trong GitHub Codespaces khiến Copilot có thể làm rò rỉ GITHUB_TOKEN  Lỗ hổng RoguePilot trong GitHub Codespaces cho phép attacker chèn prompt injection vào một GitHub issue, khiến GitHub Copilot thực thi các chỉ dẫn độc hại khi người dùng mở Codespace từ issue đó. Điều này có thể dẫn đến rò rỉ dữ liệu nhạy cảm như GITHUB_TOKEN và thậm chí cho phép attacker kiểm soát repository. Lỗ hổng đã được Microsoft vá sau khi được Orca Security phát hiện.  Ngoài ra, các nghiên cứu gần đây cho thấy nhiều kỹ thuật tấn công mới nhắm vào LLM và AI agents như GRP-Obliteration (loại bỏ cơ chế an toàn của mô hình), ShadowLogic (backdoor trong AI agent), Semantic Chaining (imagejailbreak) và Promptware, một dạng “malware cho AI” sử dụng prompt để thực hiện các giai đoạn của cyber attack lifecycle.  2. Tấn công chuỗi cung ứng vào Cline CLI 2.3.0 khiến OpenClaw bị cài đặt trên hệ thống của các lập trình viên.  Một software supply chain attack đã xảy ra với Cline CLI 2.3.0, khi attacker sử dụng npm publish token bị compromise để phát hành phiên bản chứa script postinstall tự động cài OpenClaw trên máy developer. Sự cố ảnh hưởng đến những người cài đặt gói trong khoảng 8 giờ ngày 17/02/2026, và sau đó đã được khắc phục bằng Cline 2.4.0, đồng thời token bị thu hồi.  Cuộc tấn công có thể liên quan đến kỹ thuật Clinejection, trong đó attacker dùng prompt injection trong GitHub issue để thao túng AI agent (Claude) trong workflow tự động, dẫn đến arbitrary code execution và đánh cắp publishtoken. Điều này cho thấy rủi ro ngày càng lớn của AI trong software supply chain, khi AI agent có quyền cao trong quy trình CI/CD.  Đứng trước những cuộc tấn công mạng ngày càng tinh vi và nguy hiểm như hiện nay, FPT Cloud khuyến cáo người dùng nên chủ động cập nhật phần mềm, tiến hành ứng dụng các biện pháp bảo mật dữ liệu tiên tiến giúp sao lưu và khôi phục dữ liệu tức thời, an toàn và toàn vẹn.      Tìm hiểu thêm thông tin chi tiết về dịch vụ sao lưu dữ liệu của FPT Cloud.        Liên hệ với chúng tôi để được tư vấn :    Fanpage: https://www.facebook.com/fptsmartcloud/    Email: support@fptcloud.com    Hotline: 1900 638 399