Tác giả: Jonathan Woods và Pengfei Shao

Ngày xuất bản: 07 tháng 05 năm 2025

Danh mục: AWS WAF, Best Practices, Security, Identity, & Compliance

Các ứng dụng ngày nay phải đối mặt với nhiều mối đe dọa bảo mật khác nhau, chẳng hạn như các cuộc tấn công từ chối dịch vụ phân tán (DDoS), khai thác lỗ hổng ứng dụng web như SQL injection và cross-site scripting (XSS), cùng với lưu lượng truy cập từ bot.

Trong bài viết này, để giúp bạn bảo vệ ứng dụng của mình trước các mối đe dọa đó, chúng tôi sẽ hướng dẫn cách xây dựng web access control list (web ACL) đầu tiên của bạn trong AWS WAF. AWS WAF là một tường lửa ứng dụng web giúp bạn theo dõi các yêu cầu web và kiểm soát quyền truy cập vào ứng dụng. Chúng tôi sẽ trình bày cách xây dựng phiên bản đầu tiên của web ACL và cách mở rộng nó để bảo vệ ứng dụng web của bạn khỏi các mối đe dọa từ bên ngoài.

Các quy tắc (rules) ban đầu trong Web ACL của AWS WAF

Bước 1: Bật bảo vệ bằng tích hợp một cú nhấp chuột (One-click) với AWS WAF

Để thiết lập một cấu hình bảo mật ban đầu giúp bảo vệ ứng dụng của bạn khỏi các mối đe dọa bảo mật phổ biến nhất, chúng tôi khuyến nghị bạn sử dụng tính năng bảo vệ sẵn có cho ứng dụng như sau:

• Nếu bạn đang sử dụng Amazon CloudFront để lưu trữ ứng dụng, hãy bật tính năng bảo vệ bằng cách tích hợp AWS WAF với CloudFront thông qua one-click.
• Nếu bạn đang sử dụng Application Load Balancer (ALB) để lưu trữ ứng dụng, hãy bật tính năng bảo vệ bằng cách tích hợp AWS WAF với ALB thông qua one-click.

Khi bạn bật tích hợp One-click AWS WAF với CloudFront hoặc ALB, dịch vụ sẽ tự động tạo một web ACL kèm theo các AWS Managed Rule Groups (nhóm quy tắc do AWS quản lý) và gắn nó với tài nguyên của bạn. Các nhóm luật được quản lý này giúp bảo vệ ứng dụng khỏi phần lớn các mối đe dọa web phổ biến và có thể áp dụng cho hầu hết các ứng dụng web. Việc sử dụng các nhóm luật do AWS quản lý giúp bạn tiết kiệm thời gian triển khai bảo vệ với AWS WAF, vì AWS sẽ tự động cập nhật và phát hành các phiên bản mới của các nhóm luật khi có lỗ hổng hoặc mối đe dọa mới xuất hiện.

• Amazon IP reputation list managed rule group
  Amazon IP reputation list managed rule group là nhóm bao gồm các luật dựa trên thông tin tình báo về mối đe dọa nội bộ của Amazon. Các luật này kiểm tra các địa chỉ IP liên quan đến bot hoặc các mối đe dọa khác. Điều này giúp giảm lưu lượng bot và nguy cơ kẻ xấu phát hiện ra ứng dụng có lỗ hổng.
• Core rule set (CRS) managed rule group
  CRS managed rule group là nhóm bao gồm các luật áp dụng phổ biến cho ứng dụng web, giúp bảo vệ trước nhiều dạng khai thác lỗ hổng, bao gồm cả những lỗ hổng có mức rủi ro cao và thường gặp được nêu trong các tài liệu của OWASP như OWASP Top 10.
• Known bad inputs managed rule group
  Known bad inputs managed rule group là nhóm bao gồm các luật để chặn các mẫu yêu cầu được biết là không hợp lệ và thường được dùng để khai thác hoặc dò tìm lỗ hổng. Việc này giúp giảm nguy cơ kẻ tấn công phát hiện ra ứng dụng dễ bị tổn thương.

Bước 2: Thêm các luật AWS WAF phổ biến khác

Chúng tôi khuyến nghị bạn nên bổ sung thêm một số luật thường dùng cho hầu hết các ứng dụng web, được cấu hình tùy theo yêu cầu của bạn. Nếu bạn có các nguồn tin cậy, hãy thêm danh sách IP cho phép (IP allow list) để giảm số lượng cảnh báo sai (false positive). Bạn cũng nên thêm danh sách IP bị chặn (IP block list) để loại trừ lưu lượng độc hại mà bạn phát hiện theo thời gian, và thêm quy tắc dựa trên tần suất (rate-based rule) dựa trên đặc điểm lưu lượng dự kiến của ứng dụng để bảo vệ khỏi các cuộc tấn công làm ngập yêu cầu (request floods).

• IP Allow list rule (nếu áp dụng)
  Luật này cho phép lưu lượng hợp lệ đã được xác định đi qua. Thường bao gồm các dải IP đáng tin cậy từ trung tâm dữ liệu hoặc văn phòng. Bạn create an IP set chứa các dải IP đáng tin cậy, sau đó tạo một IP set match rule  và đặt hành động của luật là Allow để cho phép yêu cầu từ các IP đó.
• IP Block list rule
  Luật này dùng để chặn các nguồn độc hại đã được biết mà không cần xử lý thêm. Thường bao gồm các dải IP cho thấy lưu lượng từ các nguồn nguy hiểm. Bạn bắt đầu với một IP set rỗng, rồi cập nhật nó dần dần khi phát hiện các nguồn độc hại, sau đó tạo luật kiểm tra IP set và đặt hành động của luật là Block để chặn các yêu cầu từ các IP đó.
• Luật rate-based tổng quát
  rate-based rule này đếm số lượng yêu cầu đến và áp dụng giới hạn khi vượt ngưỡng bạn định nghĩa. Luật này giúp bảo vệ tài nguyên khỏi việc đột ngột bị gửi quá nhiều yêu cầu. Bạn cấu hình luật với ngưỡng tần suất và khung thời gian đánh giá (evaluation window) để tổng hợp các yêu cầu dựa trên địa chỉ IP nguồn, và đặt hành động của luật là Block. Để tìm hiểu cách xác định ngưỡng cho luật rate-based và các thực hành tốt nhất khi tạo luật này, hãy tham khảo bài viết về three most important AWS WAF rate-based rules.

Bước 3: Bật tính năng ghi log cho AWS WAF

Sau khi cấu hình các luật trong web ACL, bạn có thể sử dụng  Web ACL traffic overview dashboard, để nhanh chóng có cái nhìn tổng quan về lưu lượng mà web ACL đang xử lý.

Chúng tôi cũng khuyến khích bạn enable AWS WAF logging để có thông tin chi tiết hơn về lưu lượng. Việc này hữu ích cho việc phân tích mối đe dọa, tinh chỉnh luật, xử lý các cảnh báo sai và phản ứng khi có sự cố. Để tìm hiểu cách phân tích log của AWS WAF, hãy tham khảo bài viết Analyzing AWS WAF Logs in Amazon CloudWatch Logs và How to use Amazon Athena queries to analyze AWS WAF logs.

Thứ tự luật và hành động luật trong AWS WAF

Trước khi bạn mở rộng từ các luật ban đầu trong web ACL, bạn cần hiểu rõ về thứ tự đánh giá luật và hành động của luật.

• Thứ tự đánh giá luật: AWS WAF sẽ đánh giá các luật theo thứ tự từ độ ưu tiên số thấp nhất đến cao hơn, cho đến khi gặp một luật khớp và có hành động kết thúc (terminating action) thì quá trình đánh giá dừng lại. Nếu không có luật nào có hành động kết thúc, thì  web ACL default action sẽ được áp dụng.  rule order có ảnh hưởng lớn đến tính linh hoạt và chi phí. Bạn nên đặt các luật cụ thể ở trước các luật tổng quát để đảm bảo khớp chính xác và thực thi đúng. Ngoài ra, bạn cũng nên ưu tiên các AWS Managed Rule Group miễn phí trước các tính năng Intelligent Threat Mitigation để tiết kiệm chi phí. Điều này là bởi vì khi các yêu cầu khớp với những luật có hành động kết thúc, AWS WAF sẽ ngừng xử lý các yêu cầu đó, từ đó tránh phát sinh thêm chi phí liên quan đến  AWS WAF pricing khi các yêu cầu được đánh giá bởi các nhóm luật Intelligent Threat Mitigation.
• Hành động kết thúc (terminating action) và không kết thúc (non-terminating action): Hành động của luật quy định AWS WAF sẽ làm gì với một yêu cầu web khi nó khớp với điều kiện đã xác định trong luật.
  AWS WAF hỗ trợ five different actions for the rules: Allow và Block là hành động kết thúc, tức là khi một yêu cầu khớp luật có các hành động này, AWS WAF sẽ dừng tất cả các xử lý tiếp theo trong web ACL cho yêu cầu đó. Count là hành động không kết thúc, nghĩa là sau khi khớp yêu cầu, AWS WAF vẫn tiếp tục xử lý các luật tiếp theo. Hành động Count thường được sử dụng để giám sát các yêu cầu khớp với luật thông qua AWS WAF metrics, hoặc được dùng để gán AWS WAF label cho yêu cầu và đánh giá tiếp ở các bước sau trong quá trình xử lý của web ACL. CAPTCHA và Challenge có thể là hành động kết thúc hoặc không kết thúc, tùy thuộc vào việc yêu cầu có chứa AWS WAF token hợp lệ hay không.

Suy xét kỹ về ứng dụng của bạn

Mặc dù các luật ban đầu được đề cập ở trên là một điểm khởi đầu tốt cho việc bảo vệ ứng dụng web, nhưng điều quan trọng là bạn phải tinh chỉnh các luật AWS WAF sao cho phù hợp với nhu cầu cụ thể của ứng dụng hoặc doanh nghiệp của bạn. Mỗi ứng dụng đều có đặc điểm riêng, chức năng riêng và các điểm tấn công tiềm ẩn khác nhau. Việc tinh chỉnh các luật AWS WAF có xét đến các yếu tố này sẽ giúp bạn bảo vệ ứng dụng web hiệu quả hơn, đồng thời giảm thiểu ảnh hưởng đến lưu lượng hợp lệ và trải nghiệm người dùng.

Trong ba kịch bản sau, chúng ta sẽ quan sát các mối đe dọa mà ứng dụng web của bạn có thể gặp phải để xem web ACL của bạn có thể được thiết kế như thế nào.

Kịch bản 1: Bảo vệ trước DDoS

Hãy tưởng tượng bạn đang phát triển một nền tảng thương mại điện tử dựa trên web, cho phép khách hàng duyệt sản phẩm, thêm vào giỏ hàng và hoàn tất mua sắm. Trước đây, bạn đã từng gặp phải tình trạng flood yêu cầu dẫn đến thời gian phản hồi bị suy giảm. Một nhu cầu cốt lõi ở đây là bảo vệ ứng dụng khỏi các tác nhân độc hại, đồng thời giới hạn số lượng yêu cầu gửi về backend trong các đợt flood, đặc biệt là với các yêu cầu đến URI như “/search” – vốn tiêu tốn nhiều tài nguyên xử lý. Trong kịch bản này, khách hàng của bạn chỉ đến từ Hoa Kỳ.

Bạn bắt đầu với các luật cơ bản đã được đề xuất ở phần đầu, sau đó bổ sung các luật sau vào web ACL của mình, đồng thời tối ưu hoá thứ tự ưu tiên:

• Cập nhật hành động của luật AWSManagedIPDDoSList trong nhóm luật Amazon IP reputation list thành Block: Luật AWSManagedIPDDoSList kiểm tra các địa chỉ IP đã bị xác định là có hoạt động DDoS. Mặc định, luật này có hành động là Count để giảm nguy cơ báo sai (false positive).
  Sau khi bạn xem xét chỉ số CountedRequests trong AWS WAF metrics cho luật này và thấy giá trị rất thấp, bạn tự tin rằng luật này không gây ra false positives, do đó bạn override the rule action thành Block.
• Thêm luật lọc theo địa lý để chặn lưu lượng ngoài Hoa Kỳ:  geographic match rule này sẽ chặn các yêu cầu dựa trên quốc gia xuất phát. Bạn cấu hình luật này để kiểm tra các yêu cầu không đến từ Hoa Kỳ và đặt hành động của luật là Block.
• Thêm luật giới hạn theo tần suất cho các đường dẫn URI cụ thể: Luật này bảo vệ những đường dẫn như “/search” với ngưỡng giới hạn chặt hơn. Bạn tạo luật rate-based này với ngưỡng thấp hơn luật rate-based tổng quát đã cấu hình từ trước, đồng thời limit the scope of inspection  bằng cách chỉ áp dụng cho các yêu cầu có đường dẫn URI khớp với “/search”.

Ngoài ra, chúng tôi khuyến nghị bạn nên sử dụng CloudFront để lưu trữ ứng dụng, giúp tăng khả năng chống lại các cuộc tấn công DDoS. CloudFront chỉ chấp nhận các kết nối hợp lệ (well-formed connections), điều này giúp ngăn chặn các dạng tấn công DDoS phổ biến như SYN floods và UDP reflection attacks. CloudFront cho phép  default AWS WAF quota về số lượng yêu cầu tối đa mỗi giây trên mỗi web ACL cao hơn nhiều so với các tài nguyên khu vực như ALB. Để biết thêm hướng dẫn chi tiết, hãy tham khảo tài liệu AWS Best Practices for DDoS Resiliency.

Sau khi áp dụng các luật trên, web ACL của bạn sẽ trông như sau:

Hình 1: Các luật ví dụ trong kịch bản bảo vệ DDoS

Kịch bản 2: Bảo vệ khỏi các cuộc tấn công khai thác lỗ hổng ứng dụng web

Hãy tưởng tượng bạn đang phát triển một hệ thống quản lý nhân sự (HRM) dựa trên web, sử dụng cơ sở dữ liệu SQL để lưu trữ và quản lý thông tin nhân viên, bảng lương và các dữ liệu nhạy cảm khác. Trong vài tháng qua, thông qua việc phân tích nhật ký ứng dụng, nhóm bảo mật của bạn đã phát hiện khối lượng lớn các yêu cầu có URI và nội dung yêu cầu (request body) khớp với mẫu tấn công XSS và SQL injection. Bạn cần triển khai các biện pháp bảo mật mạnh mẽ để bảo vệ cả ứng dụng và cơ sở dữ liệu nền. Ngoài ra, bạn cũng muốn tăng cường bảo mật cho trang đăng nhập khách hàng cũng như cổng quản trị nội bộ của mình.

Bạn bắt đầu với các luật cơ bản được đề xuất ở phần đầu, sau đó bổ sung các luật sau vào web ACL, đồng thời tối ưu thứ tự ưu tiên. Lưu ý rằng nhóm luật CRS (Core Rule Set) trong phần luật ban đầu đã bao gồm các quy tắc để chặn yêu cầu có mẫu XSS, vì vậy bạn không cần thêm luật mới cho XSS.

• Thêm nhóm luật quản lý cơ sở dữ liệu SQL:  SQL database rule group chứa các quy tắc bảo vệ cơ sở dữ liệu SQL, chẳng hạn như SQL injection. Bạn thêm nhóm luật này để ngăn việc chèn các truy vấn trái phép từ xa vào hệ thống.
• Thêm nhóm luật bảo vệ cổng quản trị (Admin Protection): Admin protection rule group chứa các quy tắc cho phép bạn chặn truy cập từ bên ngoài đến các trang quản trị đang bị lộ. Bạn thêm nhóm luật này để giảm nguy cơ kẻ tấn công giành được quyền truy cập quản trị vào ứng dụng của bạn, đồng thời giới hạn phạm vi kiểm tra bằng cách khớp với đường dẫn URI của cổng quản trị.
• Thêm luật giới hạn kích thước nội dung yêu cầu (request body) cho URI đăng nhập: Bạn tạo luật này với size constraint statement để hạn chế dung lượng request body. Luật này là một lớp bảo vệ bổ sung chống lại các cuộc tấn công chèn dữ liệu nguy hiểm vào biểu mẫu đăng nhập.
• Thêm luật giới hạn tần suất cho URI đăng nhập: Dựa vào mô hình lưu lượng truy cập và yêu cầu bảo mật của ứng dụng, bạn xác định rằng việc áp dụng giới hạn tần suất nghiêm ngặt hơn sẽ giúp ngăn chặn các cuộc tấn công brute-force. Bạn tạo một luật rate-based với ngưỡng thấp hơn luật rate-based tổng quát, giới hạn phạm vi kiểm tra ở các yêu cầu có đường dẫn URI khớp với trang đăng nhập, và thiết lập hành động của luật là CAPTCHA.
  CAPTCHA thường được sử dụng trong trường hợp hành động Block gây chặn quá nhiều yêu cầu hợp lệ, nhưng việc cho phép toàn bộ lưu lượng truy cập lại dẫn đến mức độ yêu cầu không mong muốn quá cao. Việc dùng CAPTCHA giúp giảm thiểu tác động tới người dùng hợp lệ, đồng thời vẫn ngăn được lưu lượng đáng ngờ cao đến trang đăng nhập.

Sau khi áp dụng các luật trên, web ACL của bạn sẽ trông như sau:

Hình 2: Các luật ví dụ trong kịch bản bảo vệ khỏi khai thác lỗ hổng ứng dụng web

Kịch bản 3: Giảm thiểu bot độc hại (Bot Mitigation)

Bạn đang quản lý một trang web du lịch trực tuyến, nơi khách hàng có thể tìm kiếm và đặt vé máy bay, khách sạn và các dịch vụ khác. Gần đây, bạn nhận thấy lưu lượng truy cập vào trang web tăng đáng kể, nhưng số lượt đặt chỗ không tăng tương ứng. Ngoài ra, bạn còn phát hiện số lượng lớn các lần đăng nhập và tài khoản giả mạo được tạo ra và sử dụng cho các hoạt động gian lận. Bạn nghi ngờ rằng trang web đang bị bot độc hại tấn công, và bạn muốn có cái nhìn rõ hơn về lưu lượng bot cũng như tìm cách ngăn chặn chúng.

Bạn bắt đầu từ các luật ban đầu đã đề xuất ở phần trước, sau đó thêm các luật miễn phí hoặc ít tốn chi phí sau đây để bắt đầu kiểm soát lưu lượng bot:

• Thêm nhóm luật Anonymous IP list với hành động là Count: Anonymous IP list rule group giúp nhận diện các yêu cầu đến từ VPN, proxy, nút Tor, và nhà cung cấp dịch vụ lưu trữ. Việc hạn chế những IP này giúp giảm lưu lượng bot. Tuy nhiên, vì một số người dùng hợp lệ cũng có thể sử dụng các nguồn này, bạn chỉ đặt hành động của luật là Count. Điều này cho phép bạn gắn nhãn (label) cho các yêu cầu đó, sau đó giới hạn tần suất (rate limit) ở bước tiếp theo thay vì chặn ngay lập tức.
• Thêm luật rate-based cho các yêu cầu bị nhận diện bởi Anonymous IP list: Luật này áp dụng giới hạn tần suất cho các yêu cầu ẩn danh đã được nhận diện ở bước trước. Bạn tạo một luật rate-based với ngưỡng thấp hơn luật tổng quát ban đầu, và giới hạn phạm vi kiểm tra bằng cách matching the label namespace “awswaf:managed:aws:anonymous-ip-list:”. Bạn có thể tham khảo bài viết how to customize the behavior of AWS managed rule groups để biết thêm chi tiết.
• Thêm luật rate-based cho các endpoint đăng nhập và đăng ký tài khoản: Luật này áp dụng giới hạn tần suất nghiêm ngặt cho các yêu cầu đến trang đăng nhập và đăng ký, giới hạn theo từng địa chỉ IP. Bạn tạo luật với ngưỡng thấp hơn so với luật rate-based tổng quát, và giới hạn phạm vi kiểm tra với URI khớp với endpoint đăng nhập và đăng ký.
• Thêm nhóm luật Bot Control của AWS WAF với mức kiểm tra “Common” cho các tài nguyên nhạy cảm: Nhóm luật AWS WAF Bot Control (mức Common) giúp phát hiện bot phổ biến bằng cách kiểm tra đặc điểm yêu cầu, tra ngược DNS, và các xác minh hệ thống khác. Vì đây là tính năng trả phí, bạn cần kiểm soát chi phí bằng cách chỉ áp dụng nhóm luật này cho các đường dẫn URI hoặc API nhạy cảm, và loại trừ nội dung tĩnh như ảnh, CSS – những nội dung mà việc bot truy cập không gây ảnh hưởng. Bạn có thể tham khảo bài viết Fine-tune and optimize AWS WAF Bot Control mitigation capability để tối ưu hóa khả năng kiểm soát bot.

Sau khi thêm các luật ở trên vào web ACL của AWS WAF, thông qua bảng tổng quan lưu lượng của web ACL, bạn nhận thấy một lượng lớn lưu lượng bot đã bị chặn. Tuy nhiên, bạn cũng quan sát thấy các hiện tượng sau:

• Khi xem các chỉ số của ứng dụng, lưu lượng được phép vẫn cao hơn mức kỳ vọng, trong khi số lượt đặt chỗ trên website vẫn thấp hơn dự kiến.
• Số lượt đăng nhập và đăng ký tài khoản ở backend đã giảm rõ rệt, nhưng vẫn cao hơn mức bình thường.
• Khi xem log của AWS WAF, có rất nhiều yêu cầu được cho phép có header giống hệt trình duyệt của người dùng thật, nhưng lại thể hiện hành vi bất thường so với người dùng hợp pháp.

Bạn nghi ngờ rằng những yêu cầu này đến từ các bot độc hại. Do đó, bạn muốn kích hoạt một giải pháp giảm thiểu bot nâng cao hơn bằng cách thêm hoặc cập nhật các luật sau theo thứ tự sau:

• Cập nhật nhóm luật AWS WAF Bot Control với mức kiểm tra Targeted cho các tài nguyên nhạy cảm: Nhóm luật Bot Control với mức kiểm tra Targeted có khả năng phát hiện các bot nâng cao không tự nhận dạng, và áp dụng các biện pháp đối phó như giới hạn tần suất, gửi thử thách (Challenge) hoặc CAPTCHA, ngoài các biện pháp của mức Common. Bạn cập nhật nhóm luật này với cấu hình sau:
  • Thiết lập mức kiểm tra (inspection level) của Bot Control thành Targeted.
  • Bật học máy (machine learning) để phát hiện và giảm thiểu hoạt động của các bot phân tán và phối hợp với nhau. Tính năng này cung cấp một loạt các luật dựa trên mức độ tin cậy rằng một nhóm yêu cầu đang tham gia vào một cuộc tấn công phối hợp.
  • Đặt hành động luật TGT_ML_CoordinatedActivityMedium thành Challenge, và hành động luật TGT_ML_CoordinatedActivityHigh thành Block.
• Thêm nhóm luật AWS WAF Fraud Control – Account Takeover Prevention cho endpoint đăng nhập: Fraud Control account takeover prevention rule group  bảo vệ endpoint đăng nhập của bạn khỏi các hành vi đánh cắp thông tin đăng nhập, tấn công nhồi thông tin (credential stuffing), thử đăng nhập brute force, và các hoạt động đăng nhập bất thường khác. Bạn thêm nhóm luật này và giới hạn phạm vi kiểm tra bằng URI trùng khớp với endpoint đăng nhập.
• Thêm nhóm luật AWS WAF Fraud Control – Account Creation Fraud Prevention cho endpoint đăng ký: Nhóm luật Fraud Control account creation fraud prevention managed rule group giúp ngăn chặn việc tạo tài khoản giả mạo trên trang web của bạn. Bạn thêm nhóm luật này và giới hạn phạm vi kiểm tra bằng URI trùng khớp với endpoint đăng ký.

Ngoài ra, bạn implement AWS WAF application integration SDKs vào trong ứng dụng, bởi vì điều này giúp makes the most effective use of the Bot Control and Fraud Control rule groups. Script thử thách (challenge script) cần được thực thi trước khi các nhóm luật Bot Control và Fraud Control hoạt động, để có thể sử dụng token mà script thu thập được. Khi sử dụng SDK tích hợp ứng dụng, script này sẽ tự động chạy, giúp đơn giản hóa việc triển khai và nâng cao hiệu quả bảo vệ.

Với các luật trên được triển khai, web ACL của bạn sẽ như sau:

Hình 3: Các luật ví dụ cho kịch bản Giảm thiểu Bot (Bot Mitigation)

Kết luận

Bài viết này cung cấp các hướng dẫn để xây dựng web ACL trong AWS WAF nhằm bảo vệ các ứng dụng web của bạn khỏi các mối đe dọa như tấn công DDoS, khai thác lỗ hổng ứng dụng web và bot độc hại. Bạn bắt đầu bằng cách thêm các luật ban đầu vào web ACL, sau đó cập nhật và thêm các luật tùy chỉnh phù hợp với mối đe dọa mà ứng dụng của bạn đang đối mặt và nhu cầu cụ thể của ứng dụng, đồng thời luôn ghi nhớ tầm quan trọng của việc ưu tiên thứ tự các luật. Làm theo các hướng dẫn trong bài viết này cho phép bạn bảo vệ hiệu quả các ứng dụng web khỏi các mối đe dọa, giảm thiểu tác động đến lưu lượng hợp lệ và đảm bảo hiệu quả chi phí.

Nếu bạn có phản hồi về bài viết này, hãy gửi tại phần Comments. Nếu bạn có câu hỏi về bài viết, hãy bắt đầu một chuỗi thảo luận mới tại AWS WAF re:Post hoặc liên hệ với AWS Support.

Pengfei Shao

Pengfei là một Quản lý Kỹ thuật Khách hàng Cấp cao (Senior Technical Account Manager) tại AWS, làm việc tại Stockholm. Anh tập trung vào việc cung cấp hướng dẫn kỹ thuật cho khách hàng và chủ động giúp họ duy trì môi trường AWS vận hành ổn định. Ngoài công việc, anh thích trượt tuyết, làm vườn và dành thời gian cho gia đình.

Jonathan Woods

Jonathan là một Kiến trúc sư Giải pháp (Solutions Architect – SA) tại AWS, làm việc tại Nashville và hiện đang hỗ trợ các khách hàng SMB (doanh nghiệp vừa và nhỏ). Anh có niềm đam mê trong việc truyền đạt công nghệ AWS đến các doanh nghiệp một cách phù hợp, giúp khách hàng dễ dàng đổi mới. Ngoài công việc, anh cố gắng dành thời gian cho ba người con của mình.