Hàng ngày, hàng ngàn ứng dụng web và API bị dò quét, kiểm tra và khai thác bởi các đối tượng tấn công, những kẻ đã nhận thức được một sự thật quan trọng: hầu hết các tổ chức không nhìn thấy được một phần nhỏ những gì thực sự đang diễn ra bên trong môi trường của họ. Các tường lửa, hệ thống phát hiện xâm nhập và WAF truyền thống được thiết kế cho một kỷ nguyên khác, trước thời kỳ của mã hóa di chuyển ngang, kiến trúc API-first và trước khi các đối tượng tấn công bắt đầu vũ khí hóa API làm điểm xâm nhập chính vào hệ thống doanh nghiệp. Tốc độ gia tăng tấn công mạng đã dẫn đến sự thay đổi cấu trúc trong bối cảnh mối đe dọa.
Tăng trưởng đột biến của các cuộc tấn công API
Dữ liệu cho thấy sự gia tăng đột biến 400% trong các cuộc tấn công API chỉ riêng trong năm 2025. Đồng thời, chỉ 19% các CISO báo cáo sự tự tin trong việc duy trì một kho kê khai API hoàn chỉnh. Điều này có nghĩa là gần 81% doanh nghiệp hoạt động với các API chưa được biết đến, chưa được tài liệu hóa hoặc API bóng ma (shadow API) trong môi trường sản xuất, tạo ra các vùng mù hiệu quả trên bề mặt tấn công của họ.
Nếu tổ chức của bạn đang đặt câu hỏi “Chúng ta có thực sự nhìn thấy mọi thứ không?”, thì thực tế khó chịu là hầu hết các doanh nghiệp thì không. Và khoảng trống hiển thị này chính là nơi các vụ xâm nhập hiện đại bắt nguồn.
WAAP: Giải pháp tiến hóa cho bảo mật ứng dụng và API
Các giải pháp WAAP (Web Application and API Protection) đại diện cho sự tiến hóa của WAF truyền thống, mở rộng bảo mật vào các môi trường dựa trên API và đám mây gốc. Tuy nhiên, việc triển khai đơn lẻ không đảm bảo khả năng hiển thị hoặc kiểm soát.
Môi trường ứng dụng hiện đại có tính động cao. API liên tục được tạo, sửa đổi và loại bỏ. Các microservices tự động mở rộng quy mô. Các đường ống CI/CD giới thiệu các điểm cuối mới với tốc độ cao. Đồng thời, các API bóng ma, dịch vụ cũ và các điểm cuối thử nghiệm bị lãng quên tiếp tục hoạt động trong môi trường sản xuất sau thời gian dự kiến ngừng hoạt động.
Ba lớp hiển thị quan trọng
Khoảng trống hiển thị mà hầu hết các doanh nghiệp phải đối mặt rơi vào ba lớp liên kết với nhau:
- Khám phá (Discovery): Khả năng xác định tất cả các API đang hoạt động, bao gồm cả các API chưa được ghi nhận.
- Tư thế (Posture): Đánh giá và quản lý cấu hình bảo mật, tuân thủ chính sách và các rủi ro tiềm ẩn liên quan đến các API đã xác định.
- Bảo vệ Runtime: Giám sát và thực thi chính sách bảo mật cho lưu lượng truy cập API theo thời gian thực, phát hiện và ngăn chặn các mối đe dọa.
Ba lớp này, Khám phá, Tư thế và Bảo vệ Runtime, tạo thành nền tảng của kiến trúc WAAP hiện đại.
Bản chất nguy hiểm của các cuộc tấn công API
Sự gia tăng 400% các cuộc tấn công API được ghi nhận vào năm 2025 không phải là một sự bất thường về số liệu thống kê. Đó là kết quả có thể dự đoán được của hai xu hướng hội tụ. API đã trở thành giao diện chính cho các ứng dụng hiện đại, nhưng mức độ trưởng thành về bảo mật đã không theo kịp. Điều này tạo ra những mối đe dọa mạng mới.
Điều làm cho các cuộc tấn công API đặc biệt nguy hiểm là cách chúng hòa lẫn một cách tự nhiên vào lưu lượng truy cập hợp pháp. Nhiều mẫu tấn công gây hại nhất không dựa vào mã độc hoặc mã khai thác. Thay vào đó, chúng lạm dụng chức năng API đã được dự định.
Một cuộc tấn công được chế tạo cẩn thận vào lỗ hổng Broken Object Level Authorization (BOLA) trông giống hệt như một yêu cầu API hợp pháp đối với một hệ thống phát hiện dựa trên chữ ký. Mã thông báo xác thực hợp lệ. Điểm cuối tồn tại. Phương thức HTTP là chính xác. Chỉ định danh tài nguyên đã bị thay đổi để truy cập dữ liệu của người dùng khác.
OWASP API Security Top 10
OWASP Foundation’s API Security Top 10 lập bản đồ các lỗ hổng quan trọng nhất mà các đối tượng tấn công đang tích cực khai thác ngày nay. Hiểu danh sách này là bối cảnh thiết yếu cho bất kỳ tổ chức nào đánh giá mức độ hoàn chỉnh của phạm vi bảo mật API của mình.
Nhận thức quan trọng ở đây là phần lớn các lỗ hổng này không thể nhìn thấy đối với việc phát hiện truyền thống dựa trên chữ ký. Việc phát hiện chúng đòi hỏi trí tuệ hành vi, hiểu rõ điều gì là bình thường đối với mỗi điểm cuối API và xác định các sai lệch cho thấy sự lạm dụng.
Tầm quan trọng của kho kê khai API chính xác
Một trong những rủi ro bị bỏ qua nhiều nhất trong bảo mật API là thiếu kho kê khai API chính xác. Các “API bóng ma” không chỉ là các điểm cuối tùy tiện, chúng bao gồm các API đã lỗi thời vẫn đang chạy trong môi trường sản xuất, các API nội bộ bị lộ trong quá trình di chuyển, các tích hợp của bên thứ ba bị lãng quên và các microservices chưa được tài liệu hóa.
Vấn đề cốt lõi rất đơn giản: nếu một API không có trong kho kê khai của bạn, nó sẽ không có trong chính sách bảo mật của bạn. Nó không được giám sát, giới hạn tốc độ hoặc quét. Trong các môi trường dựa trên CI/CD, nơi API thay đổi hàng ngày, kho kê khai thủ công luôn lỗi thời. Phương pháp duy nhất khả thi là khám phá thời gian chạy tự động liên tục phát hiện các API trong lưu lượng truy cập sản xuất.
Hiển thị lưu lượng East-West trong Kubernetes
Các microservices hiện đại dựa trên Kubernetes đã thay đổi hoàn toàn các mẫu lưu lượng. Một yêu cầu đơn lẻ có thể kích hoạt nhiều lệnh gọi API nội bộ giữa các dịch vụ (east-west) bên trong cụm, không bao giờ đến biên. WAF và API gateway truyền thống chỉ nhìn thấy lưu lượng north-south, khiến việc di chuyển ngang nội bộ không bị phát hiện. Nếu một microservice bị xâm phạm, kẻ tấn công có thể di chuyển ngang bằng cách sử dụng các API nội bộ đáng tin cậy mà không bị phát hiện.
Đây là lý do tại sao bảo vệ thời gian chạy phải mở rộng vào bên trong cụm. WAAP cung cấp cơ chế thực thi gốc Kubernetes cho cả lưu lượng north-south và east-west, đảm bảo hiển thị và kiểm soát đầy đủ trên các microservices.
Bảo vệ thời gian chạy hiệu quả trong các kiến trúc hiện đại đòi hỏi bảo mật được nhúng trong chính môi trường ứng dụng, không phải là một thành phần gắn thêm ở biên. Điều này có nghĩa là các kiểm soát bảo mật hiểu các khái niệm Kubernetes, bao gồm các namespace, pod, service và ingress controller, và có thể thực thi chính sách ở cấp độ giao tiếp dịch vụ-dịch vụ riêng lẻ.
Cách tiếp cận WAAP gốc Kubernetes mở rộng bảo vệ thời gian chạy vượt ra ngoài chu vi truyền thống, cung cấp khả năng hiển thị và thực thi cho cả lưu lượng north-south (từ ngoài vào trong) và east-west (từ dịch vụ đến dịch vụ). Kiến trúc này đảm bảo rằng các microservices bị xâm phạm không thể được sử dụng làm điểm phóng cho các cuộc tấn công tiếp theo, ngay cả khi các cuộc tấn công đó không bao giờ vượt qua ranh giới bên ngoài.
Các kịch bản tấn công minh họa
Để hiểu rõ khoảng trống hiển thị, hãy xem xét các kịch bản tấn công đại diện sau đây. Mỗi kịch bản có thể diễn ra hoàn toàn không bị phát hiện bởi các kiểm soát bảo mật truyền thống.
1. Tấn công đăng nhập phân tán (Credential Stuffing)
Các đối tượng tấn công sử dụng các bản ghi thông tin đăng nhập lớn (ví dụ: hơn 500.000 cặp tên người dùng/mật khẩu) và tránh bị phát hiện bằng cách phân phối các nỗ lực đăng nhập trên hàng trăm IP với tốc độ rất thấp theo thời gian. Sau nhiều ngày hoạt động chậm và kéo dài, hàng ngàn tài khoản bị xâm phạm.
WAF truyền thống xem đây là lưu lượng đăng nhập bình thường vì các yêu cầu được phân phối và giới hạn tốc độ không bị kích hoạt. Chỉ phân tích hành vi—theo dõi các mẫu lỗi xác thực trên nhiều người dùng và tương quan thông tin tình báo về vụ vi phạm—mới có thể phát hiện cuộc tấn công này.
2. Thu thập dữ liệu qua API (API Data Enumeration)
Một phiên người dùng bị xâm phạm được sử dụng để truy cập một API trả về dữ liệu khách hàng. Kẻ tấn công thay đổi có hệ thống tham số ID khách hàng để liệt kê các bản ghi và trích xuất khối lượng lớn dữ liệu nhạy cảm.
Mỗi yêu cầu về mặt kỹ thuật là hợp lệ và được ủy quyền, khiến nó không thể nhìn thấy đối với các công cụ bảo mật dựa trên chữ ký. Chỉ phát hiện hành vi, xác định các mẫu liệt kê tuần tự, mới cho thấy sự lạm dụng.
3. Di chuyển ngang nội bộ (Internal Lateral Movement)
Sau khi xâm phạm một microservice bị lộ, kẻ tấn công sử dụng nó để gọi các API nội bộ trong một cụm Kubernetes. Các lệnh gọi dịch vụ-dịch vụ này được tin cậy theo thiết kế và thường không được giám sát.
Điều này cho phép di chuyển ngang và truy cập dữ liệu hoàn toàn trong lưu lượng east-west, bỏ qua hoàn toàn WAF biên và API gateway.
Kiến trúc WAAP thống nhất
Prophaze WAAP giải quyết bảo mật WAAP hiện đại thông qua ba lớp tích hợp: Khám phá, Tư thế và Bảo vệ Runtime. Nền tảng hoạt động như một hệ thống thống nhất, trong đó mỗi lớp củng cố các lớp khác, tạo ra một tư thế bảo mật liên tục cập nhật, nhận biết theo ngữ cảnh và có thể hành động được về mặt vận hành.
1. Động cơ khám phá (Discovery Engine)
Động cơ khám phá liên tục xác định và lập danh mục các API trực tiếp từ lưu lượng truy cập thời gian thực mà không cần nhập thủ công. Điều này loại bỏ các điểm mù do API bóng ma, các điểm cuối cũ và các dịch vụ chưa được tài liệu hóa.
2. Phân tích hành vi AI (Behavioral AI Analytics)
Các đường cơ sở học máy xác định hành vi API bình thường (mẫu lưu lượng, tham số, vị trí địa lý, thời gian). Bất kỳ sai lệch nào cũng được phân tích theo ngữ cảnh để phát hiện sự lạm dụng với độ tin cậy cao và ít dương tính giả.
Cách tiếp cận dựa trên AI cho phép các tổ chức triển khai ở chế độ chặn ngay từ ngày đầu, với sự tự tin rằng lưu lượng truy cập hợp pháp sẽ không bị ảnh hưởng. Điều này giảm đáng kể thời gian để đạt được giá trị và đảm bảo bảo vệ hoạt động ngay từ thời điểm nền tảng đi vào hoạt động.
3. Bảo vệ Runtime Kubernetes-Native
Prophaze mở rộng bảo vệ thời gian chạy vượt ra ngoài biên để bao phủ lưu lượng east-west trong môi trường Kubernetes. Các lệnh gọi API dịch vụ-dịch vụ được kiểm tra và thực thi chính sách, đảm bảo rằng một microservice bị xâm phạm không thể được sử dụng làm điểm xoay để di chuyển ngang.
Hậu quả tài chính và vận hành của việc hoạt động với tư thế bảo mật API bị phân mảnh là rất đáng kể và ngày càng tăng. Các vụ xâm phạm API thuộc hàng các sự cố bảo mật tốn kém nhất do lộ dữ liệu, tác động pháp lý và thiệt hại danh tiếng lâu dài.
Hầu hết các tổ chức hoạt động với khả năng hiển thị API không đầy đủ—tạo ra cả các điểm mù đã biết và chưa biết trong bề mặt tấn công của họ. Mỗi API chưa được khám phá đại diện cho một điểm xâm nhập tiềm năng cho kẻ tấn công.
Các tổ chức đang thu hẹp khoảng cách này đang áp dụng các chiến lược WAAP thống nhất, tích hợp khám phá, tư thế và bảo vệ thời gian chạy thay vì dựa vào các công cụ phân mảnh. Điều này dẫn đến phát hiện nhanh hơn, giảm thiểu tác động của vụ vi phạm và tăng cường khả năng phục hồi hoạt động.
Mức tăng 400% các cuộc tấn công API vào năm 2025 nhấn mạnh một sự chuyển dịch rõ ràng sang các mối đe dọa cấp ứng dụng. Các công cụ chu vi cũ, phát hiện dựa trên chữ ký và kho kê khai API thủ công không còn đủ trong các môi trường hiện đại dựa trên API, khiến các tổ chức phải đối mặt với một bề mặt tấn công ngày càng mở rộng và phần lớn không nhìn thấy được.
Việc thu hẹp khoảng cách này đòi hỏi một cách tiếp cận WAAP thống nhất, tích hợp API Discovery, Posture và Runtime Protection vào một hệ thống duy nhất thay vì các công cụ riêng biệt. Đây là trọng tâm chính của Prophaze WAAP.
Với 81% doanh nghiệp vẫn hoạt động với các API chưa được khám phá, câu hỏi thực sự không phải là liệu khả năng hiển thị có cần thiết hay không, mà là các tổ chức có thể trì hoãn việc giải quyết nó trong bao lâu trước khi nó biến thành một vụ vi phạm.
Xem thêm chi tiết về cách WAAP giải quyết các khoảng trống hiển thị tại Prophaze Webinar.
