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

Railway là một PaaS (Platform-as-a-Service) cho developer: kết nối GitHub repo là tự động build, deploy và có database managed (Postgres, MySQL, Redis) mà không cần tự quản lý hạ tầng bên dưới. Để tránh phụ thuộc một cloud provider duy nhất, Railway chạy workload trên cả AWS, Google Cloud và cụm bare-metal riêng (Railway Metal). Sự cố Railway ngày 19/5/2026 diễn ra theo bốn mốc:  22:11 UTC, dashboard Railway bắt đầu trả lỗi 503.   22:19, nguyên nhân được xác định: tài khoản production trên Google Cloud bị tự động khóa không báo trước  22:29, quyền truy cập được khôi phục nhưng toàn bộ compute vẫn dừng.  22:35, cache định tuyến bắt đầu hết hạn. Máy chủ trên AWS và Railway Metal vẫn sống nhưng các edge proxy không dựng lại được bảng định tuyến vì network control plane API mà nó phụ thuộc nằm trên chính các máy trong Google Cloud, khiến workload khách hàng tràn ngập lỗi 404.  Railway sau đó xác nhận chính phụ thuộc này biến sự cố ở một nhà cung cấp thành sự cố toàn nền tảng. Phân tán hạ tầng ra nhiều nơi không đồng nghĩa với phân tán được ranh giới lỗi (failure boundary). Multi-AZ cần được hiểu trong cùng giới hạn đó: một cơ chế khoanh vùng sự cố, không phải một minh chứng rằng các thành phần trong hệ thống có tính độc lập.  Multi-AZ thực sự cô lập lớp lỗi nào  Vật lý: Vùng khả dụng (AZ) được thiết kế trước hết để cô lập lỗi tương quan theo vị trí vật lý: nguồn điện, làm mát, hạ tầng mạng và những thành phần cùng chịu tác động trong một khuôn viên. Nhưng tự thân điều đó chưa đủ để đảm bảo high availability, cần thêm 3 điều kiện đúng: locality, quorum và capacity.  Điều kiện để AZ phát huy tác dụng  Locality: Giá trị của thiết kế zonal định lượng được. Giả định một trong ba vùng hỏng hoàn toàn, tài nguyên phân bố đều: nếu dịch vụ gọi ngẫu nhiên qua các AZ (kiểu regional), một lần gọi chỉ còn 4/9 khả năng thành công, và với chuỗi gọi dài N bước, khả năng đó giảm dần theo (2/3)N. Nếu dịch vụ chỉ gọi trong cùng một vùng (kiểu zonal), khả năng thành công luôn giữ ở mức 2/3, bất kể chuỗi gọi dài bao nhiêu - nguyên tắc "ưu tiên gọi trong cùng AZ" này gọi là locality, giúp tránh rủi ro cộng dồn qua từng bước gọi. Nhưng cả hai công thức trên đều giả định các AZ hoàn toàn độc lập với nhau - đây là điều kiện cần, chưa đủ để đảm bảo high availability.  Quorum và capacity: Cụ thể, dù đã chạy trên nhiều vùng, high availability vẫn chưa được đảm bảo do hai yếu tố thường bị bỏ sót:  Quorum: cluster 3 node đặt theo cấu hình 2+1 (2 node cùng một AZ, 1 node ở AZ khác) không chịu được mất AZ đang chứa 2 node đó. AZ đó sập nghĩa là mất quorum, vì chỉ còn 1 node, dưới ngưỡng đa số (2/3). Để chịu được mất bất kỳ AZ nào trong số 3 AZ, phải đặt đúng 1 node/AZ (cấu hình 1+1+1), không dồn 2 node vào cùng 1 AZ.  Capacity (static stability): nếu capacity dự phòng chỉ được provision sau khi một AZ đã sập (dynamic scale-up), việc phục hồi lại phụ thuộc đúng vào control plane thứ đang chịu tải cao nhất lúc đó, nên dễ chậm hoặc kẹt. Static stability yêu cầu cấp phát sẵn capacity dư từ trước khi có sự cố: với 3 AZ, mỗi AZ chỉ vận hành ở ~66% tải đã test (tức dư khoảng 50% headroom); mất 1 AZ, 2 AZ còn lại nhận thêm tải ngay không cần chờ tạo máy mới.  Giới hạn: nơi Multi-AZ không còn bảo vệ  Giả sử cả ba điều kiện trên: locality, quorum, capacity đều đã đúng, vẫn còn một lớp phụ thuộc chưa được tính tới: control plane dùng để vận hành chính các AZ đó, đây là hạ tầng nằm phía trên ranh giới AZ.  Dù có bao nhiêu AZ, chúng vẫn thường dùng chung một control plane duy nhất để điều phối (DNS, orchestration, network state). Khi control plane này gặp lỗi, tất cả AZ bên dưới đều bị ảnh hưởng cùng lúc, bất kể locality, quorum hay capacity đã cấu hình đúng. Hai dạng shared fate - tình trạng các thành phần đặt ở AZ khác nhau nhưng vẫn cùng sập chung vì chia sẻ một điểm phụ thuộc nào đó, trình bày dưới đây là hai trường hợp điển hình:  Shared fate #1: Control Plane nằm phía trên ranh giới của AZ  Bản chất: Nhân bản (Replication) không đồng nghĩa với tính độc lập. Nhiều bản sao đặt tại các AZ khác nhau vẫn sẽ chung số phận nếu cùng phụ thuộc vào một shared state, một Single point of failure, hay một control plane ở tầng cao hơn.  Thực tế:  Railway: Dù ứng dụng và hạ tầng mạng được phân tán qua AWS, Google Cloud lẫn Railway Metal, việc phát hiện workload lại phụ thuộc hoàn toàn vào một Control Plane API duy nhất trên Google Cloud. Kiến trúc trông có vẻ phân tán, nhưng điểm phụ thuộc lại mang tính tập trung. Route cache hết hạn sau ~1 giờ; tổng downtime kéo dài 8 giờ  AWS DynamoDB (20/10/2025): 3 tiến trình DNS Enactor chạy độc lập trên 3 AZ nhưng lại cùng thao tác lên một DNS state cấp Region. Một Enactor bị trễ đã ghi đè DNS plan cũ lên plan mới; cleanup process sau đó xóa nhầm bản cũ (lúc này đang là bản thực thi), gỡ toàn bộ IP khỏi DNS. Kết quả: 3 Enactor ở 3 AZ hoàn toàn vô dụng vì quyết định cuối cùng lại nằm ở shared DNS state  Shared fate #2: Blast Radius của cấu hình vượt ranh giới hạ tầng vật lý  Bản chất: Cô lập vật lý không bảo vệ hệ thống trước một cấu hình lỗi được phát tán đồng loạt. Blast Radius của cấu hình tỷ lệ thuận với phạm vi quyền hạn của nó, không bị giới hạn bởi ranh giới địa lý. Đáng cảnh giác nhất là các self-healing mechanism: phản ứng càng nhanh và rộng thì sức tàn phá càng lớn khi đánh giá sai.  Thực tế:  Azure (2/2/2026): Workflow khắc phục tự động áp nhầm chính sách tắt anonymous access lên nhóm Storage Account phục vụ hạ tầng (chứa gói extension của VM). Khâu đánh giá tình trạng không phát hiện trạng thái nhắm sai đủ sớm, chính sách này lan ra nhiều vùng địa lý public cloud khiến hàng loạt VM, AKS và dịch vụ phụ thuộc bị tê liệt Control Plane trong nhiều giờ. Pha rollback sau đó gây quá tải Managed Identities ở East US/West US thêm ~6 giờ — bản thân remediation cũng tạo blast radius riêng  Cloudflare (18/11/2025): Một permission change trên ClickHouse tạo ra các dòng metadata trùng lặp, khiến feature file của Bot Management vượt hard limit (từ ~60 lên >200). File này lập tức đồng bộ toàn mạng, kích hoạt sự cố proxy panic trên diện rộng. Vì file được regenerate mỗi 5 phút trong lúc cluster rollout dần, hệ thống lúc tốt lúc xấu outage dao động khiến ban đầu bị nhầm là DDoS.  Bước tiếp theo  Cả hai dạng Shared fate kể trên đều có chung một dấu hiệu nhận biết: tồn tại một shared logic nằm ngoài phạm vi cô lập của từng AZ.  Việc bạn có thể làm ngay lúc này là mở sơ đồ kiến trúc của hệ thống đang vận hành và đánh dấu đỏ toàn bộ các thành phần duy nhất cấp Region/Tài khoản - bao gồm bản ghi DNS, centralized config store, hay các automation process có quyền ghi diện rộng. Mỗi dấu là một điểm thể hiện số vùng khả dụng không có ý nghĩa.  Shared fate mới chỉ là một phần của bức tranh. Còn 3 dạng Failure mode khác mà mô hình Multi-AZ không thể tự bảo vệ:  Đường khôi phục đi qua đúng thành phần đang sụp đổ (Recovery dependency).  Trạng thái nghẽn kéo dài dù nguyên nhân gốc đã xử lý xong (Metastable failure).  Lỗi ngầm khiến người dùng chịu trận nhưng giám sát vẫn "xanh" (Gray failure).  Phần 2 đi sâu phân tích 3 dạng này.  Nguyễn Phúc LộcPhó Giám Đốc Trung Tâm Phát Triển Dịch Vụ Hạ Tầng Cloud

AI đang viết một tỷ lệ ngày càng lớn lượng code mới của thế giới với tốc độ nhanh hơn mọi quy trình security review truyền thống có thể theo kịp. Phần lớn doanh nghiệp không thiếu công cụ bảo mật mà họ thiếu context: khả năng ghép hàng trăm cảnh báo rời rạc thành đường tấn công, cho thấy kẻ tấn công sẽ đi từ đâu đến đâu. Bài viết phân tích vì sao tốc độ của AI buộc bảo mật phải thay đổi ở tầng kiến trúc thay vì bổ sung công cụ, và cách chúng tôi giải bài toán đó với FPT Cloud Security Platform.  AI làm code nhanh hơn, lỗ hổng bảo mật cũng nhiều hơn  75% dòng code mới tại Google hiện do AI tạo ra, theo công bố của CEO Alphabet Sundar Pichai. Kevin Scott, CTO Microsoft dự báo con số này tiến tới 95% trong 5 năm tới. GenAI đang dẫn đầu tăng trưởng trong các dịch vụ public cloud: mức sử dụng tăng 8 điểm phần trăm (percentage point) lên 58%, với 45% tổ chức đã triển khai ở quy mô lớn (Flexera, 2026 State of the Cloud Report). Gartner nhận định tới năm 2028, điện toán đám mây chuyển từ vai trò công nghệ đột phá thành cấu phần bắt buộc của năng lực cạnh tranh. Tại Việt Nam, thị trường cloud được dự báo đạt 6,98 tỷ USD vào năm 2030, CAGR 10,94% (TechSci Research). Cloud đã không còn chỉ là nơi đặt máy chủ mà trở thành nền tảng nơi phần mềm và AI được tạo ra, triển khai và vận hành.  Khoảng cách giữa tốc độ phát triển và tốc độ bảo mật ngày càng lớn  Cái giá của những dòng “code nhanh” từ AI không nằm ở màn hình người viết. 61% kỹ sư đánh giá code do AI tạo "trông đúng nhưng chưa chắc đáng tin" (Sonar, State of Code Developer Survey 2026).   Veracode, trong GenAI Code Security Report 2025, đo tỷ lệ code do AI sinh ra không vượt qua kiểm tra bảo mật theo từng ngôn ngữ:  Ngôn ngữ  Tỷ lệ code AI-generated không vượt qua kiểm tra bảo mật  Java  72%  C#  45%  JavaScript  43%  Python  38%  Nguồn: Veracode, 2025 GenAI Code Security Report  Đây không phải bài toán riêng của doanh nghiệp dùng AI viết phần mềm. Code do AI tạo đang chảy vào mọi hệ thống qua thư viện mã nguồn mở, đối tác gia công và nhà cung cấp phần mềm. Ở chiều ngược lại, tin tặc dùng AI để dò lỗ hổng và tự động hóa khai thác. 94% lãnh đạo trong khảo sát của Diễn đàn Kinh tế Thế giới coi AI là động lực thay đổi lớn nhất của an ninh mạng (WEF Global Cybersecurity Outlook 2026).    6 “điểm đau” bảo mật doanh nghiệp thường mắc phải  security tham gia quá muộn, lỗi chỉ được phát hiện sau khi release;   mỗi giai đoạn phát triển dùng một công cụ riêng, không chia sẻ dữ liệu;   nhiều dashboard nhưng không có bức tranh tổng thể;   đội vận hành ngập trong cảnh báo tới mức chai lì (alert fatigue);   báo động giả (false positive) bào mòn niềm tin vào chính công cụ;   và khi mọi cảnh báo đều "đỏ", không còn gì thực sự quan trọng.  Hầu hết tổ chức tập trung phòng thủ luồng North-South - traffic ra vào giữa Internet và hệ thống nội bộ, nơi dễ nhận diện và chặn bằng gateway hay WAF. Luồng East-West - giao tiếp giữa các server, ứng dụng và database - chiếm khoảng 70-80% tổng traffic nhưng hiếm khi được kiểm soát tương xứng: thiếu microsegmentation và giám sát nội vùng, kẻ tấn công chỉ cần vượt qua perimeter một lần là di chuyển ngang (lateral movement) gần như tự do để tiếp cận dữ liệu.  Điểm mấu chốt: một quyền truy cập cấp quá rộng, một cổng dịch vụ mở, một lỗ hổng ứng dụng đứng riêng lẻ đều vô hại trong báo cáo của từng công cụ; ghép đúng trình tự, chúng là một đường tấn công (attack path) hoàn chỉnh. Không công cụ đơn lẻ nào nhìn thấy phép ghép đó, vì mỗi công cụ chỉ giữ một mảnh dữ liệu. Giới bảo mật gọi đây là bất đối xứng kinh điển, theo định đề của John Lambert (Microsoft Threat Intelligence): "Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win."  FPT Cloud Security Platform: kết nối các dấu vết rời rạc, chỉ rõ đường tấn công   Nguyên tắc thiết kế của chúng tôi xuất phát từ chẩn đoán trên: nếu vấn đề là context, lời giải phải bắt đầu từ tầng dữ liệu, không phải từ việc bổ sung tính năng. Nền tảng được tổ chức thành ba tầng, theo thứ tự dữ liệu được xử lý.  Security Data Lake gom log tường lửa, sự kiện container, kết quả quét lỗ hổng và API call trên cloud về một nơi duy nhất, lưu trữ tại Việt Nam. Với CISO, điều này nghĩa là một giao diện duy nhất, thay vì gộp báo cáo thủ công từ nhiều tính năng bảo mật rời rạc.  Security Graph nối các tín hiệu trong data lake thành đường tấn công cụ thể - cho thấy nếu bị khai thác, kẻ tấn công sẽ đi từ đâu đến đâu. Đây là tầng trả lời câu hỏi ưu tiên: từ 500 cảnh báo không rõ mức độ, hệ thống lọc còn 5 lỗ hổng nằm trên đường tấn công khả thi dẫn tới tài sản quan trọng.  AI Security Engine làm việc trên cùng context đó với ba nhiệm vụ: AI Triage đọc context của từng phát hiện trước khi quyết định có báo động hay không, thay vì đẩy mọi phát hiện cho con người; AI Correlation nối tín hiệu từ code, runtime và cấu hình cloud để phát hiện những kiểu tấn công mà luật cố định (rule-based) bỏ sót; AI Remediation không dừng ở việc chỉ ra lỗi, mà đề xuất đoạn code cần sửa kèm lý do.  AI giảm tải chứ không thay quy trình. Dù tầng AI lọc được phần lớn nhiễu, luôn có một tỷ lệ phát hiện phải do con người phân tích và quyết định - thường là những ca khó nhất, nơi rủi ro kỹ thuật đan với bối cảnh nghiệp vụ. Tổ chức vẫn cần quy trình phản hồi, người chịu trách nhiệm và kỷ luật vá lỗi; nền tảng chỉ bảo đảm thời gian của đội ngũ dồn vào đúng phần đáng dồn  Lộ trình từ Code -> Security Platform  AppSec chạy song song sáu lớp quét - SAST, secret scan, IaC scan, container image scan, DAST API scan - tích hợp thẳng vào CI/CD theo hướng shift-left. Khác biệt nằm ở pipeline suy luận sâu: source code được phân tích qua AST, data flow, taint analysis, rồi tới bước AI reasoning chạy trên FPT AI Factory để đưa ra kết luận theo context (context-aware verdict). Kết quả từ tất cả các lớp đổ về một correlation engine, xếp hạng rủi ro theo khả năng khai thác (exploitability), phạm vi ảnh hưởng (blast radius) và tác động kinh doanh - hiển thị trên một dashboard chung cho Dev, Sec và Ops. Cách gom mọi rủi ro về một đồ thị phân tích duy nhất cắt 80-90% cảnh báo rác.  Auto-triage là một cơ chế suppression, và mọi cơ chế suppression đều có xác suất nén nhầm một phát hiện thật. Đổi lấy việc cắt 80-90% cảnh báo rác là rủi ro false negative, và rủi ro đó phải được quản trị bằng thiết kế chứ không bằng niềm tin vào mô hình. Ba nguyên tắc chúng tôi áp dụng: chỉ tự động đóng khi mức tin cậy vượt ngưỡng đặt trước, dưới ngưỡng thì hạ mức ưu tiên chứ không tắt cảnh báo; một số lớp không bao giờ được tự động đóng, gồm secret bị lộ, lỗ hổng trên bề mặt hướng Internet và tài sản thuộc nhóm quan trọng nhất; và mọi quyết định suppress đều lưu lại tín hiệu cùng lý do dẫn tới nó để truy vết ngược khi cần. Đi kèm là một chỉ số vận hành ít được nhắc nhưng quan trọng nhất với tầng này: tỷ lệ phát hiện từng bị nén rồi sau đó được xác nhận là thật. Nếu con số ấy không được đo, không thể khẳng định cơ chế đang chạy đúng.  Với các tổ chức thuộc phạm vi điều chỉnh của quy định trong nước, nền tảng tự động phát hiện sai lệch cấu hình và xuất báo cáo làm bằng chứng tuân thủ khi kiểm tra, đánh giá định kỳ. Từ 01/7/2026, Luật An ninh mạng số 116/2025/QH15 hợp nhất và thay thế Luật An toàn thông tin mạng 2015 cùng Luật An ninh mạng 2018; cơ chế bảo vệ theo 5 cấp độ nay được chi tiết hóa tại Nghị định 331/2026/NĐ-CP (19/8/2026) — văn bản thay vai trò của Nghị định 85/2016/NĐ-CP và Thông tư 12/2022/TT-BTTTT, bổ sung yêu cầu đánh giá rủi ro, rà quét lỗ hổng và kiểm thử xâm nhập. Hệ thống đã phê duyệt cấp độ theo luật cũ phải cập nhật biện pháp bảo vệ trong 12 tháng kể từ ngày Luật có hiệu lực; ở phía ngân sách, Điều 38 yêu cầu dành tối thiểu 15% kinh phí dự án chuyển đổi số dùng ngân sách nhà nước cho an ninh mạng.  Hợp nhất context đồng nghĩa với tập trung dữ liệu bảo mật - và kho dữ liệu ấy tự nó là mục tiêu giá trị cao. Log bảo mật thường chứa cả secret bị lộ lẫn dữ liệu cá nhân, nên đi kèm nó phải là phân quyền theo least privilege, mã hóa khi lưu và khi truyền, quản lý khóa tách biệt, audit log truy cập, cùng chính sách retention và masking - thiết kế từ đầu, không bổ sung sau. Đây là nghĩa vụ pháp lý: Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 và Nghị định 356/2025/NĐ-CP (hiệu lực 01/01/2026, thay Nghị định 13/2023) buộc lập hồ sơ DPIA và đánh giá tác động chuyển dữ liệu ra nước ngoài trong 60 ngày, bố trí nhân sự bảo vệ dữ liệu, thông báo vi phạm trong 72 giờ với dữ liệu vị trí và sinh trắc học. Mức phạt tới 3 tỷ đồng, hoặc 5% doanh thu năm liền trước với vi phạm chuyển dữ liệu xuyên biên giới, chi tiết tại Nghị định 330/2026/NĐ-CP (hiệu lực 05/10/2026). Data lake đặt tại Việt Nam đáp ứng yêu cầu vị trí lưu trữ theo Điều 19 Nghị định 333/2026/NĐ-CP (thay Nghị định 53/2022) và sàn retention nhật ký tối thiểu 12 tháng; nếu dữ liệu chạm ngưỡng "quan trọng"/"cốt lõi" theo Quyết định 20/2025/QĐ-TTg thì áp thêm nghĩa vụ đánh giá rủi ro hằng năm của Luật Dữ liệu 60/2024/QH15 và Nghị định 165/2025/NĐ-CP.  Nội dung bài viết là thông tin kỹ thuật, không phải tư vấn pháp lý.  Tác Giả: Bùi Song Toàn  Bùi Song Toàn là Phó Giám đốc Trung tâm Phát triển dịch vụ Nền tảng Cloud, FPT Smart Cloud, với hơn 10 năm kinh nghiệm trong hạ tầng CNTT và platform engineering. Ông phụ trách phát triển lớp dịch vụ nền tảng trên FPT Cloud: Kubernetes và container platform, CI/CD cùng các dịch vụ platform engineering, data platform, observability, hạ tầng phục vụ AI, và nhóm dịch vụ bảo mật nền tảng - trong đó có FPT Cloud Security Platform và FPT AppSec.   

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

Nhằm mang đến trải nghiệm quản trị cơ sở dữ liệu tối ưu và an toàn nhất, FPT Database Engine chính thức cập nhật bộ ba tính năng mới: Engine Version Upgrade, Point-in-Time Recovery (PITR) và hỗ trợ OpenSearch Version 3.5.0. Những nâng cấp này là "chìa khóa" giúp doanh nghiệp giải quyết bài toán vận hành phức tạp, bảo vệ dữ liệu toàn vẹn và dễ dàng tiếp cận các nền tảng cơ sở dữ liệu thế hệ mới. Engine Version Upgrade: Nâng cấp database trực tiếp trên cluster hiện có Trước đây, việc cập nhật phiên bản cơ sở dữ liệu thường là "nỗi ám ảnh" của các kỹ sư hệ thống khi đòi hỏi phải triển khai một cluster hoàn toàn mới, sau đó thực hiện chuyển đổi dữ liệu với rất nhiều thao tác rủi ro và tốn kém thời gian.  Với Engine Version Upgrade, FPT Database Engine cho phép khách hàng nâng cấp phiên bản database engine trực tiếp trên cluster hiện có thông qua FPT DBaaS Portal mà không cần tạo database cluster mới, giúp đơn giản hóa việc quản lý vòng đời database và giảm thiểu công việc vận hành. Thông qua FPT DBaaS Portal, khách hàng có thể thực hiện nâng cấp trực tiếp, kiểm tra điều kiện trước khi nâng cấp và theo dõi tiến trình thực hiện.  Tính năng mang lại các lợi ích:  Đa dạng nền tảng: Hỗ trợ nâng cấp (Patch Upgrade và Minor Upgrade) cho các engine phổ biến gồm: MySQL, Redis, MongoDB Standard và Kafka. Thao tác trực quan, dễ dàng: Khách hàng có thể chủ động kiểm tra các điều kiện cần thiết trước khi nâng cấp và theo dõi sát sao toàn bộ tiến trình thực hiện ngay trên giao diện FPT DBaaS Portal. An toàn và tương thích: Hệ thống chỉ cho phép cập nhật lên các phiên bản đã được đội ngũ chuyên gia FPT kiểm thử và chứng nhận độ ổn định.   Lưu ý: Engine Version Upgrade chỉ hỗ trợ theo các đường nâng cấp (Upgrade Path) do FPT Database Engine cung cấp. Trong quá trình nâng cấp, database cluster sẽ được khởi động lại (restart) và có thể xảy ra gián đoạn dịch vụ trong thời gian ngắn. FPT khuyến nghị thực hiện nâng cấp trong Maintenance Window hoặc ngoài giờ cao điểm, đồng thời thực hiện backup trước khi nâng cấp nhằm đảm bảo an toàn dữ liệu. Point-in-Time Recovery (PITR): Khôi phục dữ liệu về thời điểm mong muốn Trong quá trình vận hành database, các sự cố như thao tác nhầm, lỗi ứng dụng hoặc thay đổi dữ liệu ngoài mong muốn có thể ảnh hưởng đến trạng thái dữ liệu hiện tại. Vì vậy, khả năng khôi phục chính xác dữ liệu tại một thời điểm cụ thể là yêu cầu quan trọng để đảm bảo tính liên tục của hệ thống.  FPT Database Engine bổ sung tính năng Point-in-Time Recovery (PITR) cho phép doanh nghiệp khôi phục cơ sở dữ liệu về bất kỳ thời điểm hợp lệ nào trong khoảng thời gian lưu trữ, thay vì chỉ phụ thuộc vào các bản backup định kỳ. Tính năng được áp dụng cho các dịch vụ: PostgreSQL, MySQL và MariaDB. Các khả năng chính: Lựa chọn thời điểm khôi phục: Khôi phục chính xác trạng thái dữ liệu tại một thời điểm tùy chọn trong phạm vi lưu trữ cấu hình. Khởi tạo instance độc lập: Dữ liệu được khôi phục sang một database instance mới, hoàn toàn không ghi đè lên database gốc hiện tại. Quản lý chủ động: Cho phép bật/tắt PITR trên từng cluster, cấu hình thời gian và thực hiện thao tác khôi phục trực tiếp thông qua FPT Console Portal. Lưu ý: Point-in-Time Recovery (PITR) chỉ khả dụng sau khi tính năng được bật, hệ thống hoàn tất bản Full Backup đầu tiên và ghi nhận transaction log kể từ thời điểm đó để phục vụ khôi phục. Khả năng khôi phục phụ thuộc vào thời gian lưu trữ (Retention Period) được cấu hình. Hỗ trợ OpenSearch Version 3.5.0: Mở rộng khả năng tìm kiếm và phân tích FPT Database Engine bổ sung OpenSearch version 3.5.0 vào danh mục hỗ trợ, cho phép người dùng lựa chọn trực tiếp phiên bản này khi khởi tạo OpenSearch cluster trên FPT DBaaS Portal. Phiên bản mới hỗ trợ triển khai theo hai mô hình Single-node và Dedicated Node Architecture. Trong đó, Dedicated Node Architecture cho phép tách biệt các thành phần Cluster Manager Node, Data Node và Coordinator Node, phù hợp với các nhu cầu triển khai OpenSearch cluster khác nhau. Việc hỗ trợ OpenSearch 3.5.0 giúp doanh nghiệp nhanh chóng tiếp cận các tính năng, cải tiến và bản vá bảo mật mới nhất, đồng thời linh hoạt lựa chọn mô hình triển khai phù hợp với nhu cầu thực tế. Bên cạnh đó, toàn bộ quá trình triển khai và quản lý OpenSearch cluster đều được thực hiện tập trung trên FPT DBaaS Portal, giúp tối ưu hóa hiệu quả vận hành. Lưu ý: Để sử dụng OpenSearch version 3.5.0, người dùng cần khởi tạo một cluster mới và thực hiện migrate dữ liệu. Các OpenSearch cluster hiện tại không tự động nâng cấp lên phiên bản này. FPT khuyến nghị bật Backup trước khi thực hiện migrate để đảm bảo an toàn dữ liệu.  Bằng việc liên tục bổ sung các tính năng cao cấp, FPT Database Engine một lần nữa khẳng định cam kết mang đến một hạ tầng dữ liệu An toàn - Hiệu suất - Đơn giản hóa vận hành cho mọi doanh nghiệp.  Liên hệ với chúng tôi để được tư vấn chi tiết về các giải pháp, dịch vụ của FPT Cloud:    Hotline: 1800 6139   Email: support@fptcloud.com   Support: m.me/fptsmartcloud 

Chi phí logistics Việt Nam hiện ở mức 16,8 - 17% GDP cao hơn so với mức trung bình toàn cầu đang ảnh hưởng đến biên lợi nhuận của doanh nghiệp và sức cạnh tranh của hàng hóa Việt. Để giải bài toán này, Smartlog và FPT Cloud đã cùng xây dựng, triển khai một hệ sinh thái công nghệ "Make in Vietnam" mang lại hiệu quả thực tiễn, tạo ra tiết giảm chi phí hiệu quả cho doanh nghiệp Một thập kỷ xây dựng giải pháp lõi Make in Vietnam Theo Hiệp hội Doanh nghiệp Dịch vụ Logistics Việt Nam (VLA), chi phí logistics nội địa hiện cao hơn đáng kể so với mức bình quân 10 – 11% của các nước phát triển. Khoảng cách này trực tiếp làm giảm lợi thế cạnh tranh quốc gia, bắt nguồn từ những điểm nghẽn thủ công ở tầng vận hành. Theo ghi nhận CTCP Giải pháp Chuỗi cung ứng Smartlog, vận hành truyền thống có thể khiến doanh nghiệp mất 5-10 phút để điều phối một chuyến xe, hơn 30 cuộc gọi mỗi ngày để tra cứu vị trí hàng hóa và tới 5 ngày cho một chu kỳ đối soát cước phí. Các điểm nghẽn này làm tăng thao tác thủ công và hạn chế khả năng kiểm soát theo thời gian thực. Bắt đầu từ năm 2015, giữa những hoài nghi về khả năng tự chủ công nghệ logistics của doanh nghiệp Việt, Smartlog kiên định phát triển các giải pháp lõi “Make in Vietnam” gồm Quản lý vận tải STM, Quản lý kho hàng SWM, Quản lý đơn hàng SOM, Nền tảng tối ưu container rỗng COS, Sàn giao dịch vận tải STX bám sát vận hành thực tế. Sau hơn một thập kỷ, Smartlog đã sở hữu hệ sinh thái kết nối từ hoạch định, thực thi đến tối ưu chuỗi cung ứng, với ứng dụng AI và giải thuật ngày một tiên tiến hơn. Song song với việc mở rộng quy mô triển khai, Smartlog không ngừng nâng cấp chiều sâu của hệ sinh thái giải pháp, tiêu biểu là SSCP - Giải pháp Hoạch định Chuỗi Cung ứng giúp doanh nghiệp nâng cao năng lực dự báo, lập kế hoạch và tối ưu nguồn lực. Hơn 200 doanh nghiệp trong và ngoài nước đã lựa chọn Smartlog, với quy mô quản lý hơn 5 triệu m² kho bãi và 24.000 phương tiện vận tải và liên tục được vinh danh tại các giải thưởng uy tín như Sao Khuê, I4.0, Giải Vàng Make in Vietnam và Giải Bạc APICTA châu Á - Thái Bình Dương. Từ bệ phóng vững chắc trong nước, Smartlog chính thức bước ra toàn cầu với văn phòng tại Ấn Độ cùng mạng lưới dịch vụ tại Malaysia, Indonesia, Thái Lan, Philippines, Campuchia, Myanmar, Nam Phi và Nhật Bản. Doanh nghiệp nhanh chóng trở thành đối tác chuyển đổi số logistics cho nhiều tập đoàn đa quốc gia tại các trung tâm sản xuất chiến lược. Cộng hưởng sức mạnh trên hạ tầng điện toán đám mây Khi hệ sinh thái Smartlog mở rộng sang các dự án xuyên biên giới, việc xử lý dữ liệu lớn theo thời gian thực (Real-time Big Data) đòi hỏi một nền tảng hạ tầng vượt trội. Smartlog đã lựa chọn hợp tác cùng FPT Cloud - nền tảng điện toán đám mây thế hệ mới chuẩn quốc tế do doanh nghiệp Việt làm chủ. FPT Cloud không chỉ đóng vai trò nhà cung cấp hạ tầng, mà còn trực tiếp cùng Smartlog nâng cấp kiến trúc hệ thống và tối ưu các thuật toán điều phối giao vận. Sự hợp tác công nghệ của Smartlog và FPT Cloud không chỉ ở vai trò đồng hành kỹ thuật mà được đo lường bằng những con số hiệu quả vận hành thiết thực cho các chủ hàng và đơn vị vận tải. Thông qua năng lực tính toán linh hoạt của FPT Cloud, hệ thống Smartlog cho phép tự động hóa quy trình lên phương án chia tuyến, rút ngắn thời gian điều phối xe từ vài giờ xuống còn vài phút, giải phóng tới 80% khối lượng thao tác thủ công. Toàn bộ chuỗi thao tác tốn nhiều nhân lực như nhập liệu đơn hàng, tính toán ghép chuyến/tải trọng, phân bổ xe và đối soát chứng từ đều được thuật toán tự động xử lý tức thì. Nhờ đó, nhân sự quản lý vận tải không còn bị cuốn vào các tác vụ nhập liệu lặp đi lặp lại, mà chuyển sang tập trung xử lý các ngoại lệ vận hành và nâng cao chất lượng dịch vụ khách hàng. Chu kỳ đối soát cước phí giữa chủ hàng và nhà xe được rút ngắn từ 5 ngày xuống tức thì, loại bỏ hoàn toàn rủi ro sai lệch chứng từ và giúp doanh nghiệp chủ động tối ưu dòng tiền. Nhờ lợi thế Data Center đặt ngay tại Việt Nam, hệ thống triệt tiêu độ trễ đường truyền quốc tế, giúp các tính năng phức tạp như hiển thị lịch trình bến bãi 3D hay định vị vị trí xe vận hành mượt mà với độ chính xác tuyệt đối. Đặc biệt, năng lực tính toán hiệu năng cao của hạ tầng đám mây nội địa còn tạo ra môi trường sinh thái để Smartlog tăng tốc phát triển nền tảng và mở rộng sang định hướng ứng dụng trí tuệ nhân tạo (AI-Native) chuyên sâu. Các tính năng như Hoạch định tuyến tự động (Route Auto Planning) hay Tháp điều khiển AI (AI-Driven Control Tower) giúp các nhà xe tính toán cung đường tối ưu nhất, giảm tỷ lệ chạy xe rỗng chiều về và tiết kiệm từ 10% đến 15% chi phí Logistics trung bình. Khả năng co giãn linh hoạt của FPT Cloud cũng giúp hệ thống đứng vững trước các đợt bùng nổ lưu lượng dữ liệu vào kỳ cao điểm mua sắm mà không bị nghẽn sập, đồng thời giúp Smartlog tối ưu chi phí hạ tầng CNTT hơn. Nhìn nhận về bài toán quản trị trong thời kỳ kinh tế nhiều biến động, ông Kurt Bình CEO Smartlog khẳng định bài toán cốt lõi của doanh nghiệp hiện nay là khả năng tối ưu hóa chi phí và kiểm soát rủi ro dựa trên dữ liệu: “Smartlog đã có những bước tiến nhất định tại thị trường quốc tế, với nhiều dự án triển khai cho tập đoàn đa quốc gia. Đây là tín hiệu tích cực trên hành trình vươn mình ra biển lớn, nhưng cũng đặt ra yêu cầu để chúng tôi tiếp tục hoàn thiện sản phẩm ở những tiêu chuẩn cao hơn về hiệu quả vận hành, tính ổn định, an toàn dữ liệu và khả năng mở rộng, tích hợp. Smartlog sẽ tiếp tục các công cuộc nghiên cứu sâu đặc thù thị trường, nâng cao năng lực đội ngũ và liên kết cùng các đối tác bản địa để giải pháp ngày càng đáp ứng tốt hơn nhu cầu của doanh nghiệp toàn cầu.” Ông Kurt Bình Founder & CEO Smartlog phát biểu tại hội nghị của Smartlog và FPT Cloud - Hình ảnh: FPT Smart Cloud Đồng hành cùng tầm nhìn đó, đại diện FPT Cloud khẳng định cam kết cung cấp hạ tầng điện toán đám mây đạt chuẩn quốc tế, giúp đối tác gỡ bỏ rào cản kỹ thuật và tối ưu chi phí vận hành để tập trung sáng tạo giá trị cốt lõi. Hợp tác giữa Smartlog và FPT Cloud không đơn thuần giải bài toán vận hành logistics. Quan trọng hơn, việc kết hợp giữa hạ tầng điện toán đám mây quốc tế và giải pháp tự động hóa toàn diện sẽ giúp các doanh nghiệp tối ưu chi phí, loại bỏ các mắt xích thủ công và bứt phá hiệu suất. Đây là lời khẳng định về năng lực của công nghệ Make in Vietnam trên hành trình chuyển đổi số quốc gia” - ông Đoàn Đăng Khoa, Phó Tổng Giám Đốc FPT Smart Cloud, Tập đoàn FPT chia sẻ. Ông Đoàn Đăng Khoa, Phó Tổng Giám Đốc FPT Smart Cloud, Tập đoàn FPT phát biểu tại hội nghị của Smartlog và FPT Cloud - Hình ảnh: FPT Smart Cloud Liên hệ với chúng tôi để được tư vấn chi tiết về dịch vụ của FPT Cloud Email: support@fptcloud.com Support: m.me/fptsmartcloud

Theo khảo sát “State of Code Developer Survey 2026”, 61% kỹ sư phần mềm đánh giá code do AI viết "có thể đúng, nhưng chưa chắc đã đáng tin". Thông tin trên được ông Bùi Song Toàn, Phó Giám đốc Trung tâm Phát triển dịch vụ Nền tảng Cloud, FPT Smart Cloud, Tâp đoàn FPT đã đưa ra tại hội nghị GrowthVerse Cloud Day 2026 với chủ đề: "Tăng trưởng về điện toán đám mây và trí tuệ nhân tạo” được tổ chức tại TPHCM vào ngày 14/8 vừa qua. Ông Toàn cho biết, khảo sát toàn cầu của Flexera cho thấy 45% tổ chức đã triển khai GenAI ở quy mô lớn. Theo công bố của CEO Alphabet Sundar Pichai, 75% dòng code mới tại Google hiện do AI tạo ra; còn CTO Microsoft Kevin Scott dự báo tỷ lệ này sẽ tiến tới 95% trong vòng 5 năm tới. Theo ông Toàn, AI đang giúp doanh nghiệp tạo ra phần mềm nhanh chưa từng có, nhưng cũng khiến khoảng cách giữa tốc độ phát triển và năng lực bảo mật ngày càng lớn, đi kèm đó là nhiều rủi ro bảo mật hơn. Cụ thể về chất lượng bảo mật của code do AI sinh ra, báo cáo GenAI Code Security 2025 của Veracode cho thấy, hơn 70% code Java do AI tạo không vượt qua kiểm tra bảo mật; với C#, JavaScript và Python, tỷ lệ này lần lượt là 45%, 43% và 38%. Theo khảo sát “State of Code Developer Survey 2026”, 61% kỹ sư phần mềm đánh giá code do AI viết "có thể đúng, nhưng chưa chắc đã đáng tin". Ông Toàn phân tích, đây không phải bài toán riêng của doanh nghiệp dùng AI để viết phần mềm. Code do AI tạo ra đang chảy vào mọi hệ thống qua thư viện mã nguồn mở, đối tác gia công và nhà cung cấp phần mềm. Ở chiều ngược lại, tin tặc cũng dùng AI để dò lỗ hổng và tự động hóa tấn công. 94% lãnh đạo trong khảo sát của Diễn đàn Kinh tế Thế giới (WEF) coi AI là động lực thay đổi lớn nhất của an ninh mạng. Ông Bùi Song Toàn, Phó Giám đốc Trung tâm Phát triển dịch vụ Nền tảng Cloud, FPT Smart Cloud, Tâp đoàn - phát biểu tại sự kiện GrowthVerse Cloud Day 2026 Hiện nay, đã có nhiều doanh nghiệp coi điện toán đám mây là yếu tố bắt buộc trong chiến lược kinh doanh và trí tuệ nhân tạo tạo sinh (GenAI) trở thành động lực thúc đẩy chính. Việt Nam cũng không đứng ngoài cuộc, khi thị trường điện toán đám mây trong nước được dự báo đạt 6,98 tỷ USD vào năm 2030 với tốc độ tăng trưởng gần 11% mỗi năm. Và khi các rủi ro bảo mật mới xảy ra, phản xạ phổ biến của doanh nghiệp là đầu tư thêm công cụ bảo mật. Từ kinh nghiệm vận hành nền tảng cloud cho khối doanh nghiệp, đại diện FPT Smart Cloud chỉ ra sáu điểm "đau" lặp lại ở hầu hết tổ chức: lỗi bảo mật chỉ được phát hiện sau khi sản phẩm đã phát hành; mỗi khâu dùng một công cụ riêng không chia sẻ dữ liệu; quá nhiều màn hình báo cáo nhưng không có bức tranh tổng thể; đội vận hành "chai lì" vì ngập trong cảnh báo; báo động giả làm mất niềm tin; và khi mọi cảnh báo đều đỏ, không còn gì thực sự quan trọng. Để giải quyết bài toán này, theo ông Toàn phải bắt đầu từ nơi rủi ro sinh ra: những dòng code. Theo ông, bước khởi đầu chi phí thấp nhất là rà soát bảo mật ngay từ khâu phát triển phần mềm, trước khi mở rộng dần sang các lớp hạ tầng, dữ liệu và định danh khác. Theo báo Vietnamnet.vn

I. Các lỗ hổng bảo mật được công bố trong tháng 08  1. Microsoft August 2026 Patch Tuesday khắc phục 3 lỗ hổng zero-days và 400 lỗ hổng bảo mật:    Hôm nay là bản cập nhật Patch Tuesday tháng 8 năm 2026 của Microsoft, với các bản cập nhật bảo mật cho 400 lỗ hổng, bao gồm 2 lỗ hổng zero-day đã được công bố công khai và 1 lỗ hổng đang bị khai thác tích cực trong các cuộc tấn công.   Bản vá Patch Tuesday lần này giải quyết 42 lỗ hổng "Nghiêm trọng" (Critical), trong đó 37 lỗ hổng là thực thi mã từ xa, 5 lỗ hổng là leo thang đặc quyền.   Số lượng lỗi trong từng danh mục lỗ hổng được liệt kê dưới đây:   176 Lỗ hổng Leo thang Đặc quyền (Elevation of Privilege)  11 Lỗ hổng Vượt qua Tính năng Bảo mật (Security Feature Bypass)  110 Lỗ hổng Thực thi Mã từ xa (Remote Code Execution)   86 Lỗ hổng Tiết lộ Thông tin (Information Disclosure)   12 Lỗ hổng Từ chối Dịch vụ (Denial of Service)   21 Lỗ hổng Giả mạo (Spoofing)   Khi thống kê các bản vá Patch Tuesday, BleepingComputer chỉ tính những bản cập nhật bảo mật được Microsoft phát hành trong ngày Patch Tuesday.  Do đó, thống kê 400 lỗ hổng không bao gồm một số lỗi trong Mariner, Microsoft Teams, Microsoft Azure, Microsoft Entra, Microsoft Office và Power Apps đã được Microsoft khắc phục trước đó trong tháng.  Mặc dù số lượng lỗ hổng trong tháng 8 thấp hơn đáng kể so với Patch Tuesday tháng 7, khi Microsoft khắc phục tới 570 lỗ hổng, đây vẫn là một đợt cập nhật có quy mô rất lớn.  Trước đó, Microsoft cảnh báo số lượng bản cập nhật bảo mật Patch Tuesday sẽ tiếp tục tăng do hãng bắt đầu sử dụng hệ thống phát hiện lỗ hổng được hỗ trợ bởi AI nhằm phát hiện thêm các lỗ hổng trong những sản phẩm phần mềm của mình trước khi chúng bị tin tặc khai thác.  Đối với các bản cập nhật không liên quan đến bảo mật được phát hành trong tháng này, người dùng có thể tham khảo các bản cập nhật tích lũy Windows 11 KB5121003 & KB5120240 cumulative updates , cùng với bản cập nhật bảo mật mở rộng Windows 10 KB5120249 extended security update  Microsoft vá 3 lỗ hổng zero-day   Bản cập nhật Patch Tuesday tháng 8/2026 khắc phục 3 lỗ hổng zero-day, gồm 1 lỗ hổng đang bị khai thác trong các cuộc tấn công và 2 lỗ hổng đã được công khai trước khi có bản vá chính thức.  Microsoft phân loại một lỗ hổng là zero-day nếu lỗ hổng đó đã được công khai hoặc đang bị khai thác tích cực trong khi chưa có bản vá chính thức.  Các lỗ hổng zero-day được giải quyết trong bản cập nhật tháng này bao gồm:  CVE-2026-68820 (Windows Ancillary Function Driver for WinSock - AFD.sys) – Đang bị khai thác: Lỗ hổng leo thang đặc quyền trong Windows Ancillary Function Driver for WinSock. Lỗ hổng dạng Use-After-Free cho phép kẻ tấn công đã được xác thực cục bộ chạy một ứng dụng được thiết kế đặc biệt để kích hoạt race condition và giành quyền SYSTEM trên hệ thống. Microsoft cho biết không yêu cầu tương tác của người dùng để khai thác. Lỗ hổng được các nhà nghiên cứu Moshe Marelus và David Driker của Check Point phát hiện. Theo Check Point, nhóm tin tặc Triều Tiên Lazarus đã khai thác CVE-2026-68820 trong các cuộc tấn công zero-day để triển khai phiên bản mới của FudModule, một rootkit hoạt động ở chế độ kernel.  CVE-2026-62832 (Windows User Profile Service) – Đã được công khai: Lỗ hổng leo thang đặc quyền trong Windows User Profile Service do cơ chế xử lý liên kết trước khi truy cập tệp không phù hợp. Kẻ tấn công đã được xác thực và có thông tin đăng nhập của một tài khoản cục bộ khác có thể chạy ứng dụng được tạo đặc biệt để tải registry hive của người dùng khác. Khai thác thành công có thể cho phép truy cập hoặc sửa đổi dữ liệu của người dùng khác và giành quyền quản trị viên. Lỗ hổng này có nhiều điểm tương đồng với zero-day LegacyHive được nhà nghiên cứu bảo mật Nightmare Eclipse công khai trước đó.  CVE-2026-72971 (Windows Container Isolation FS Filter Driver - unionfs.sys) – Đã được công khai: Lỗ hổng liên quan đến cơ chế xử lý liên kết trong Windows Container Isolation FS Filter Driver (unionfs.sys), cho phép kẻ tấn công đã được xác thực thực hiện hành vi giả mạo/thay đổi dữ liệu cục bộ. Microsoft không công bố chi tiết về nơi lỗ hổng được tiết lộ trước đó nhưng ghi nhận phát hiện của các nhà nghiên cứu yhw và txz.  Các nhà cung cấp khác cũng đã phát hành bản cập nhật hoặc advisory trong tháng 08/2026, bao gồm:  Adobe đã phát hành các bản cập nhật bảo mật cho nhiều sản phẩm, bao gồm ColdFusion, Commerce, Lightroom Classic, Content Credentials SDK và Campaign Classic. Cisco đã phát hành các bản cập nhật bảo mật cho nhiều sản phẩm, bao gồm Cisco Catalyst SD-WAN, IOS, IOS XE và các lỗ hổng trong ClamAV đã xuất hiện mã khai thác công khai.  Metabase đã phát hành bản cập nhật để khắc phục một lỗ hổng SQL Injection (SQLi) nghiêm trọng. Lỗ hổng này đã bị khai thác trong các cuộc tấn công nhằm đánh cắp dữ liệu.  N-able đã phát hành bản cập nhật bảo mật để khắc phục lỗ hổng bỏ qua cơ chế xác thực (Authentication Bypass) đang bị khai thác tích cực, CVE-2026-18577, ảnh hưởng đến cả máy chủ N-central dạng hosted và on-premises.  SAP đã phát hành bản cập nhật bảo mật tháng 8 cho nhiều sản phẩm, trong đó có một lỗ hổng Improper Authorization với mức độ nghiêm trọng CVSS 10.0 trong SAP Commerce Cloud (Data Hub Adapter).  TP-Link đã vá 15 lỗ hổng trong cơ chế Zero-Touch Provisioning (ZTP) của các thiết bị mạng Omada. Các lỗ hổng này có thể cho phép kẻ tấn công thực hiện Remote Code Execution (RCE). VMware đã phát hành các bản cập nhật bảo mật cho VMware Avi Load Balancer, trong đó có các lỗ hổng cho phép bỏ qua cơ chế xác thực và thực thi mã từ xa (RCE).  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 08 năm 2026.   Tag  CVE ID  CVE Title  Severity  Active Directory Certificate Services (AD CS)  CVE-2026-62818  Windows Active Directory Certificate Services (AD CS) Remote Code Execution Vulnerability  Critical  Application Insights Profiler  CVE-2026-49163  Application Insights Profiler Elevation of Privilege Vulnerability  Critical  Azure Active Directory  CVE-2026-50481  Azure Active Directory Elevation of Privilege Vulnerability  Critical  Azure Confidential Ledger  CVE-2026-68823  Azure Confidential Ledger Remote Code Execution Vulnerability  Critical  Azure Entra ID  CVE-2026-62869  Azure Entra ID Spoofing Vulnerability  Critical  Azure Logic Apps  CVE-2026-56161  Azure Logic Apps Information Disclosure Vulnerability  Critical  Azure Service Bus  CVE-2026-50515  Azure Service Bus Remote Code Execution Vulnerability  Critical  Azure SQL Database  CVE-2026-63522  Azure SQL Database Elevation of Privilege Vulnerability  Critical  Azure SQL Database  CVE-2026-56162  Azure SQL Database Elevation of Privilege Vulnerability  Critical  Azure SQL Managed Instance  CVE-2026-62836  Azure SQL Managed Instance Elevation of Privilege Vulnerability  Critical  Azure SRE Agent  CVE-2026-62830  Azure SRE Agent Elevation of Privilege Vulnerability  Critical  Microsoft 365 Admin Center  CVE-2026-62873  Microsoft 365 Admin Center Elevation of Privilege Vulnerability  Critical  Microsoft Azure Attestation service and Device Health Attestation Service  CVE-2026-71331  Windows Device Health Attestation (DHA) Remote Code Execution Vulnerability  Critical  Microsoft Azure Attestation service and Device Health Attestation Service  CVE-2026-66802  Windows Device Health Attestation (DHA) Remote Code Execution Vulnerability  Critical  Microsoft Azure Kubernetes Service  CVE-2026-50516  Microsoft Azure Kubernetes Service Elevation of Privilege Vulnerability  Critical  Microsoft Entra Provisioning Service (SyncFabric)  CVE-2026-59115  Microsoft Entra Provisioning Service Elevation of Privilege Vulnerability  Critical  Microsoft Exchange Server  CVE-2026-62911  Microsoft Exchange Server Elevation of Privilege Vulnerability  Critical  Microsoft Office  CVE-2026-63515  Microsoft Office Remote Code Execution Vulnerability  Critical  Microsoft Office  CVE-2026-63519  Microsoft Office Graphics Component Remote Code Execution Vulnerability  Critical  Microsoft Office  CVE-2026-65664  Microsoft Office Graphics Component Remote Code Execution Vulnerability  Critical  Microsoft Office  CVE-2026-63513  Microsoft Office Graphics Component Remote Code Execution Vulnerability  Critical  Microsoft Office  CVE-2026-65657  Microsoft Office Remote Code Execution Vulnerability  Critical  Microsoft Office  CVE-2026-64910  Microsoft Office Remote Code Execution Vulnerability  Critical  Microsoft Office  CVE-2026-64909  Microsoft Office Remote Code Execution Vulnerability  Critical  Microsoft Office  CVE-2026-63532  Microsoft Office Remote Code Execution Vulnerability  Critical  Microsoft Office  CVE-2026-64911  Microsoft Office Remote Code Execution Vulnerability  Critical  Microsoft Office  CVE-2026-64898  Microsoft Office Remote Code Execution Vulnerability  Critical  Microsoft Office  CVE-2026-64903  Microsoft Office Remote Code Execution Vulnerability  Critical  Microsoft Office  CVE-2026-66807  Microsoft Office Graphics Component Remote Code Execution Vulnerability  Critical  Microsoft Office  CVE-2026-70130  Microsoft Office Remote Code Execution Vulnerability  Critical  Microsoft Office  CVE-2026-63526  Microsoft Office Graphics Component Remote Code Execution Vulnerability  Critical  Microsoft Office Excel  CVE-2026-68794  Microsoft Excel Remote Code Execution Vulnerability  Critical  Microsoft Office Excel  CVE-2026-68804  Microsoft Excel Remote Code Execution Vulnerability  Critical  Microsoft Office Excel  CVE-2026-68816  Microsoft Excel Remote Code Execution Vulnerability  Critical  Microsoft Office SharePoint  CVE-2026-62827  Microsoft SharePoint Server Elevation of Privilege Vulnerability  Critical  Microsoft Office SharePoint  CVE-2026-64921  Microsoft SharePoint Server Elevation of Privilege Vulnerability  Critical  Microsoft Office SharePoint  CVE-2026-70332  Microsoft Office SharePoint Spoofing Vulnerability  Critical  Microsoft Office SharePoint  CVE-2026-65665  Microsoft SharePoint Server Remote Code Execution Vulnerability  Critical  Microsoft Office Word  CVE-2026-64907  Microsoft Office Word Remote Code Execution Vulnerability  Critical  Microsoft Office Word  CVE-2026-63518  Microsoft Office Word Remote Code Execution Vulnerability  Critical  Microsoft Office Word  CVE-2026-63525  Microsoft Office Word Remote Code Execution Vulnerability  Critical  Microsoft Planetary Computer Pro  CVE-2026-63508  Microsoft Planetary Computer Pro Elevation of Privilege Vulnerability  Critical  Microsoft Power Apps  CVE-2026-59118  Microsoft Power Apps Elevation of Privilege Vulnerability  Critical  Microsoft Purview eDiscovery  CVE-2026-65668  Microsoft Purview eDiscovery Elevation of Privilege Vulnerability  Critical  Microsoft QUIC  CVE-2026-62815  Microsoft QUIC Remote Code Execution Vulnerability  Critical  Microsoft Teams  CVE-2026-62896  Microsoft Teams Elevation of Privilege Vulnerability  Critical  Microsoft Teams  CVE-2026-65667  Microsoft Teams Elevation of Privilege Vulnerability  Critical  Microsoft Teams  CVE-2026-62918  Microsoft Teams Spoofing Vulnerability  Critical  Reliable Multicast Transport Driver (RMCAST)  CVE-2026-62816  Windows Reliable Multicast Transport Driver (RMCAST) Remote Code Execution Vulnerability  Critical  Remote Desktop Client  CVE-2026-62824  Remote Desktop Client Remote Code Execution Vulnerability  Critical  Windows Deployment Services  CVE-2026-62893  Windows Deployment Services TFTP Server Remote Code Execution Vulnerability  Critical  Windows DHCP Server  CVE-2026-62823  Windows DHCP Server Remote Code Execution Vulnerability  Critical  Windows DNS  CVE-2026-62817  Windows DNS Server Remote Code Execution Vulnerability  Critical  Windows DNS  CVE-2026-62820  Windows DNS Server Remote Code Execution Vulnerability  Critical  Windows DNS  CVE-2026-65789  Windows DNS Server Remote Code Execution Vulnerability  Critical  Windows DNS  CVE-2026-62878  Windows DNS Server Remote Code Execution Vulnerability  Critical  Windows GDI+  CVE-2026-62822  Windows GDI+ Remote Code Execution Vulnerability  Critical  Windows GDI+  CVE-2026-62890  Windows GDI+ Elevation of Privilege Vulnerability  Critical  Windows iSCSI Target Service  CVE-2026-65791  Windows iSCSI Target Service Remote Code Execution Vulnerability  Critical  Windows Key Guard  CVE-2026-66799  Windows Key Guard Elevation of Privilege Vulnerability  Critical  Windows Routing and Remote Access Service (RRAS)  CVE-2026-62819  Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability  Critical  Windows Secure Socket Tunneling Protocol (SSTP)  CVE-2026-62889  Windows Secure Socket Tunneling Protocol (SSTP) Remote Code Execution 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 công bố các lỗ hổng trong tháng 08  CVE   Mô tả lỗ hổng   CVE-2026-77113  Lỗ hổng Path Traversal trong apport-unpack của Canonical Apport cho phép kẻ tấn công kiểm soát tên key trong tệp crash report để thực hiện truy cập đường dẫn ngoài phạm vi dự kiến. Khai thác thành công có thể dẫn đến tạo hoặc ghi đè tệp tùy ý với quyền của người dùng đang thực thi apport-unpack, tạo điều kiện cho các cuộc tấn công tiếp theo tùy thuộc vào quyền của tài khoản bị ảnh hưởng. Lỗ hổng ảnh hưởng đến Canonical Apport trước các phiên bản 2.36.0, 2.34.2 và 2.28.4 trên Linux. Mức độ nghiêm trọng: Chưa xác định (NVD chưa cung cấp CVSS).  CVE-2026-76023  Lỗ hổng Improper Resource Control trong Linux Toolkit Theming của Google Chrome cho phép kẻ tấn công từ xa, sau khi đã xâm nhập renderer process, thực thi mã tùy ý bên ngoài sandbox thông qua một trang HTML được tạo специально. Lỗ hổng ảnh hưởng đến Google Chrome trước phiên bản 151.0.7922.173 trên Linux. Mức độ nghiêm trọng: High (CVSS 8.8 – CISA-ADP).  CVE-2026-74733  Lỗ hổng Race Condition/Improper Locking trong Linux Kernel GPIO PCA953x driver xảy ra do hàm pca953x_irq_bus_sync_unlock() không giữ đúng i2c_lock khi thực hiện thao tác với regmap, có thể khiến nhiều luồng đồng thời đọc/ghi sai thanh ghi. Khai thác có thể dẫn đến đọc hoặc ghi dữ liệu thanh ghi không chính xác, ảnh hưởng đến hoạt động của thiết bị GPIO. Lỗ hổng ảnh hưởng đến Linux Kernel có sử dụng driver PCA953x. Mức độ nghiêm trọng: Chưa xác định (NVD chưa cung cấp CVSS).  🔗 Chi tiết về các lỗ hổng có thể xem tại Advisories.   VMWare công bố các lỗ hổng trong tháng 08 CVE-2026-67261  Lỗ hổng OS Command Injection do thành phần IAPI của Dell Virtual Storage Integrator for VMware vSphere Client xử lý lệnh hệ điều hành không an toàn. Kẻ tấn công không cần xác thực và có thể thực hiện từ xa để khai thác lỗ hổng, thực thi các lệnh hệ điều hành tùy ý với quyền root, từ đó có khả năng kiểm soát hoàn toàn hệ thống. Lỗ hổng ảnh hưởng đến các phiên bản Dell Virtual Storage Integrator for VMware vSphere Client trước 10.11.1.0. Lỗ hổng được đánh giá Critical với CVSS 9.8. Dell đã phát hành bản cập nhật 10.11.1.0 để khắc phục và khuyến nghị người dùng nâng cấp sớm.  CVE-2026-54489  Lỗ hổng Sensitive Information Disclosure trong Dell Virtual Storage Integrator for VMware vSphere Client do cơ chế bảo vệ thông tin nhạy cảm không đầy đủ. Kẻ tấn công từ xa, không cần xác thực có thể khai thác để thu thập thông tin xác thực của các phiên đang hoạt động và thực hiện session hijacking. Từ đó, kẻ tấn công có thể giả mạo người dùng đã xác thực, bao gồm cả tài khoản quản trị viên. Lỗ hổng ảnh hưởng đến các phiên bản Dell Virtual Storage Integrator trước 10.11.1.0. Lỗ hổng được đánh giá Critical với CVSS 9.8 (NVD) và Dell khuyến nghị nâng cấp lên 10.11.1.0 hoặc mới hơn. CVE-2026-59309  Lỗ hổng Authentication Bypass trong VMware vCenter do cơ chế xác thực của VMware Directory Service được triển khai không chính xác. Kẻ tấn công có quyền truy cập mạng đến vCenter có thể khai thác lỗ hổng để vượt qua cơ chế xác thực và truy cập trái phép vào hệ thống. Việc khai thác thành công có thể dẫn đến mất tính bảo mật và kiểm soát trái phép đối với vCenter. Lỗ hổng được phân loại Critical với CVSS 3.1 là 9.8 bởi VMware. Lỗ hổng được gán CWE-303 – Incorrect Implementation of Authentication Algorithm.   🔗 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.  Malware Android nhắm mục tiêu hệ thống giải trí trên ô tô để gian lận quảng cáo và xây dựng mạng proxy  Các nhà nghiên cứu an ninh mạng đã phát hiện một họ mã độc mới nhắm trực tiếp vào firmware của các head unit ô tô chạy Android do DoFun phát triển. Theo Kaspersky, mã độc được phát tán thông qua cơ chế cập nhật phần mềm tích hợp sẵn của hệ thống, biến một kênh cập nhật hợp pháp thành phương thức phân phối mã độc. Chuỗi lây nhiễm bắt đầu từ ứng dụng hệ thống TWCore (com.tw.core), vốn có chức năng thu thập dữ liệu và cập nhật phần mềm thông qua MQTT broker. Kẻ tấn công đã lợi dụng cơ chế này để đưa dropper JarService vào head unit, sau đó tải xuống các payload độc hại nhiều giai đoạn. Hoạt động này được đánh giá có liên quan với độ tin cậy cao đến MoYu Group, nhóm từng gắn với hệ sinh thái BADBOX chuyên thực hiện gian lận quảng cáo và xây dựng mạng proxy.   Sau khi được cài đặt, mã độc hoạt động âm thầm dưới dạng một ứng dụng thông thường, định kỳ liên lạc với máy chủ C2 để gửi thông tin về thiết bị và nhận cấu hình hoặc lệnh mới. Malware hỗ trợ nhiều chức năng như thực hiện HTTP request, mở liên kết và chạy JavaScript, tải và thực thi mã bổ sung, thu thập thông tin thiết bị, đồng thời có khả năng triển khai module zhima để biến thiết bị thành một phần của mạng proxy. Mục tiêu chính của chiến dịch là phục vụ quảng cáo trái phép, thực hiện gian lận quảng cáo và mở rộng mạng proxy botnet. Đây được xem là trường hợp đầu tiên được ghi nhận về mã độc có chuỗi lây nhiễm được thiết kế riêng cho head unit ô tô, cho thấy các nền tảng Android trên phương tiện hiện đại đang trở thành một mục tiêu mới cần được bảo vệ chặt chẽ.  🔗 Thông tin chi tiết hơn xem thêm tại đây, Dịch vụ sao lưu dữ liệu đám mây - FPT Cloud: Sao lưu và khôi phục dữ liệu tức thời, an toàn và toàn vẹn dữ liệu.   2. 14 gói npm bị trojan hóa phát tán backdoor RedC2 4.0 trên Linux với C2 được hỗ trợ bởi AI.  Các nhà nghiên cứu an ninh mạng đã phát hiện 14 gói npm bị trojan hóa, giả dạng các tiện ích lịch và tính toán nhưng thực chất được thiết kế để phát tán RedC2 4.0, một backdoor Linux có khả năng hỗ trợ điều khiển từ xa. Khi module được import, file dist/index.mjs sẽ tự động tìm và thực thi binary độc hại ở chế độ nền mà không cần install hook. Payload được ngụy trang dưới nhiều tên như math-core.bin, calc.bin hoặc calc-mapping.bin. Sau khi hoạt động, RedShell Linux beacon có thể thu thập thông tin hệ thống, thực hiện lệnh, thao tác file, thu thập SSH key và thông tin trình duyệt, đồng thời kết nối tới máy chủ C2 để nhận lệnh.  Điểm đáng chú ý của RedC2 4.0 là framework này tích hợp AI thông qua Red Agent, cho phép chuyển các yêu cầu bằng ngôn ngữ tự nhiên thành chuỗi lệnh phục vụ hoạt động hậu khai thác. Điều này có thể làm giảm đáng kể rào cản kỹ thuật đối với kẻ tấn công. Vụ việc cho thấy rủi ro nghiêm trọng của software supply-chain attack khi chỉ cần một dependency bị nhiễm độc cũng có thể khiến payload được thực thi trên hệ thống. Đối với SOC, cần đặc biệt theo dõi việc cài đặt các package npm bất thường, tiến trình con được tạo ngay sau khi ứng dụng Node.js khởi chạy, binary lạ trong thư mục dist/, kết nối mạng tới C2 và các hành vi thu thập thông tin hoặc thực thi lệnh bất thường.  🔗 Thông tin chi tiết hơn xem thêm tại đây, Dịch vụ sao lưu dữ liệu đám mây - FPT Cloud: Sao lưu và khôi phục dữ liệu tức thời, an toàn và toàn vẹn dữ liệu. Liên hệ với chúng tôi để được tư vấn chi tiết về các giải pháp, dịch vụ của FPT Cloud: Hotline: 1800 6139 Email: support@fptcloud.com Support: m.me/fptsmartcloud   

Từ ngày 1/9, FPT Smart Cloud chính thức sử dụng Tổng đài 24/7 1800 6139 cho các hoạt động tư vấn và hỗ trợ khách hàng. Đầu số tổng đài 1900 638 399 vẫn được duy trì đến hết 31/10. Nhằm nâng cao chất lượng chăm sóc khách hàng và tạo thuận tiện hơn trong quá trình hỗ trợ, FPT Smart Cloud triển khai sử dụng tổng mới mới 1800 6139. Đặc biệt, đây là đầu số miễn phí cước gọi dành cho khách hàng khi liên hệ với FPT Smart Cloud. Đầu số mới áp dụng cho toàn bộ các dịch vụ gồm: FPT.AI, FPT Cloud, FPT AI Factory, FPT CFS và FPT Data Suite. Hai Hotline cùng hoạt động trong 2 tháng chuyển đổi Trong giai đoạn từ 1/9 đến hết 31/10, FPT Smart Cloud sẽ duy trì đồng thời hai số Hotline: Hotline mới: 1800 6139 – miễn phí cước gọi. Hotline hiện tại: 1900 638 399 – tiếp tục hoạt động trong thời gian chuyển đổi. Chính thức sử dụng duy nhất Hotline mới | Từ sau ngày 31/10/2026 Từ 1/11, số 1900 638 399 sẽ chính thức ngừng hoạt động và không tiếp nhận cuộc gọi. Khi đó, 1800 6139 sẽ là Hotline duy nhất được sử dụng cho các hoạt động tư vấn và hỗ trợ khách hàng của FPT Smart Cloud. Việc chuyển đổi sang Hotline 1800 6139 không chỉ là thay đổi về đầu số, mà còn là một bước cải thiện trải nghiệm khách hàng của FPT Smart Cloud. Với đặc điểm miễn phí cước gọi, đầu số mới giúp giảm rào cản chi phí, khuyến khích khách hàng chủ động liên hệ khi cần tư vấn và hỗ trợ, đồng thời mang đến một kênh chăm sóc thuận tiện và dễ tiếp cận hơn. Quý khách hàng vui lòng lưu và cập nhật số Hotline mới 1800 6139 để thuận tiện liên hệ với FPT Smart Cloud khi cần hỗ trợ. FPT Smart Cloud xin chân thành cảm ơn Quý khách hàng đã luôn tin tưởng và đồng hành. Chúng tôi cam kết không ngừng đổi mới và nâng cao chất lượng dịch vụ, mang đến cho Quý khách những trải nghiệm hỗ trợ tối ưu, thuận tiện và trọn vẹn nhất.