AWS Network Firewall là dịch vụ quản lý tường lửa mạng lưu giữ trạng thái, được thiết kế phát hiện xâm nhập và ngăn chặn cho  Amazon Virtual Private Cloud (Amazon VPC). Bài viết này tập trung vào việc tự động cập nhật quy tắc ở trung tâm dịch vụ Network Firewall bằng cách sử dụng cấu hình tường lửa phân tán . Nếu bạn mới biết tới Network Firewall hoặc đang tìm kiếm nền tảng kỹ thuật trong việc quản lý quy tắc, hãy xem qua AWS Network Firewall – New Managed Firewall Service in VPC.

Network Firewall đưa ra ba mô hình triển khai: Phân tán, Tập trung và Kết hợp. Rất nhiều khách hàng chọn lựa mô hình tập trung để giảm thiểu chi phí. Ở mô hình này, khách hàng được phân trách nhiệm cho việc quản lý bộ quy tắc để bảo vệ cho người sở hữu hạ tầng VPC ( tài khoản khác ). Bằng cách chuyển dịch trách nhiệm và cung cấp sự linh hoạt cho các tài khoản. Để quản lý bộ quy tắc trong chính sách tường lửa dùng chung từ việc cấu hình phân tán đầu vào cho việc bảo vệ VPC ở ( các tài khoản phụ thuộc ) là một thách thức khi không có cho phép từ đầu vào, quản lý trạng thái hay kiểm soát số lượng.

Ở bài này, chúng tôi sẽ cho bạn thấy làm cách nào để tự động quản lý quy tắc tường lửa ở phía trong tường lửa trung tâm bằng cách sử dụng cấu hình tường lửa phân tán trải rộng khắp nhiều tài khoản AWS. Giải pháp anfw-automate cung cấp việc kiểm tra đầu vào, quản lý trạng thái, và kiểm soát số lượng, giảm thời gian cập nhật quy tắc tường lửa từ vài phút sang vài giây. Ngoài ra, giải pháp cũng giảm chi phí giám sát,  bao gồm quản lý quy tắc, chi phí phụ trợ khi mà tích hợp liền mạch với quy trình tích hợp liên tục, chuyển giao liên tục.

Điều kiện tiên quyết

Để đạt được hướng dẫn này, các điều kiện sau đây cần phải đáp ứng:

• Kiến thức cơ bản về định nghĩa mạng như routing, và phương pháp định vị địa chỉ IP ( CIDR ) 
• Kiến thức cơ bản về cấu hình YAML và JSON như formats, definitions, và schema
• Kiến thức cơ bản về Định dạng quy tắc Suricata và Quản lý quy tắc Network Firewall
• Kiến thức cơ bản về triển khai CDK
• AWS Identity and Access Management (IAM) Quyền bootstrap cho tài khoản AWS sử dụng AWS Cloud Development Kit (AWS CDK).
• Tường lửa VPC ở tài khoản trung tâm cần phải tiếp cận được tài khoản phụ thuộc (xem mô hình triển khai tập trung). Về giải pháp này, bạn cần hai tài khoản AWS từ đó triển khai mô hình tập trung.

+  Tài khoản phụ thuộc là tài khoản người dùng định nghĩa quy tắc tường lửa cho tài khoản và sử dụng endpoints của tường lửa trung tâm để lọc kết nối tới. Cần ít nhất là một tài khoản này để mô phỏng lại quy trình xác thực người dùng.

+ Tài khoản trung tâm là một tài khoản trong đó chứa endpoints của tường lửa. Tài khoản này được sử dụng bởi ứng dụng và dịch vụ Network Firewall

• Triển khai stackset cùng với quản lý quyền quản lý dịch vụ cần phải được bật tại  AWS Organizations (kích hoạt quyền truy cập đáng tin cậy với AWS Organizations). Tài khoản quản trị được ủy quyền yêu cầu phải triển khai được stacks AWS CloudFormation trên mọi tài khoản ở trong tổ chức. Các CloudFormation StackSets được triển khai trên tài khoản là cần thiết. CloudFormation stacks sẽ ở tài khoản phụ thuộc. Nếu bạn không có tài khoản được ủy quyền quản trị, bạn cần phải tự triển khai tài nguyên thủ công trên tài khoản phụ thuộc. Triển khai thủ công sẽ không được đề xuất ở môi trường production.
• Tài khoản nguồn là tài khoản CI/CD dùng để triển khai các stacks cần thiết từ  AWS CodePipeline. Các pipelines triển khai sẽ nối tài khoản, và region với các tài khoản AWS trước đó

+ Phân quyền IAM để triển khai stacks CDK trên tài khoản nguồn.

Mô tả giải pháp

Trong dịch vụ Network Firewall, với từng endpoint tường lửa kết nối tới một chính cách tường lửa, nó giám sát từng lưu lượng và lọc hành vi được định nghĩa trong mạng. Các chi tiết hành vi được định nghĩa ở nhóm quy tắc – các quy tắc được sử dụng lại – dùng để kiểm tra và phân phối lưu lượng trong mạng. Các quy tắc ở trong nhóm quy tắc được cung cấp chi tiết cho việc kiểm tra packet và xác định hành động cần thực hiện khi một packet phù hợp với tiêu chí kiểm tra. Dịch vụ Network Firewall sử dụng một Bộ máy quy tắc của Suricata để xử lý tất cả quy tắc lưu giữ trạng thái. Hiện tại, bạn có thể khởi tạo Suricata tương thích hoặc các quy tắc cơ bản ( ví dụ như list các domain ) ở network firewall. Chúng tôi sử dụng quy tắc chuỗi suricata tương thích ở trong bài viết này để tương thích việc bảo trì tốt nhất trong phần lớn các trường hợp sử dụng.

Ảnh 1 Mô tả làm thế nào giải pháp anfw-automate sử dụng tường lửa phân tán để cấu hình quy tắc nhằm đơn giản việc quản lý quy tắc cho nhiều nhóm. Các quy tắc được xác thực, thay đổi, và lưu trữ chính sách ở trung tâm AWS Network Firewall. Giải pháp này tách bạch các quy tắc được khởi tạo cho tài khoản AWS phụ thuộc, nhưng vẫn sử dụng cho chính sách chia sẻ tường lửa và một trung tâm ANFW cho việc lọc lưu lượng. Cách tiếp cận này cung cấp cho tài khoản AWS phụ thuộc khả năng linh hoạt để quản lý quy tắc tường lửa mà nó sở hữu trong khi vẫn duy trì trách nhiệm với các quy tắc đó trong đó là chính sách của tường lửa. Giải pháp này kích hoạt trung tâm nhóm bảo mật để xác minh và ghi đè những quy tắc tường lửa được định nghĩa của người dùng trước khi đẩy nó lên chính sách tường lửa trên production. Nhóm bảo mật giám sát trung tâm tường lửa có thể định nghĩa thêm các quy tắc để xác nhận trên nhiều tài khoản phụ thuộc khác, bằng cách này sẽ thực thi được chính sách bảo mật cho toàn tổ chức.

Ảnh 1: Khởi chạy khối lượng công việc bằng cách tải lên tệp cấu hình để cấu hình bucket

Cả dịch vụ Network Firewall có endpoints tường lửa và giải pháp anfw-automate được triển khai cùng lúc trên tài khoản trung tâm. Các tài khoản phụ thuộc sử dụng ứng dụng cho việc tự động quy tắc và Network Firewall cho việc kiểm tra lưu lượng.

Như đã thấy ở hình 1, tài khoản phụ thuộc có những thứ sau đây:

1. Một Amazon Simple Storage Service (Amazon S3) bucket để lưu trữ nhiều tệp cấu hình, một cái cho một Region. Các quy tắc được định nghĩa trên tệp cấu hình được cho phép lưu lượng đến VPC thông qua tài khoản phụ thuộc. Các tệp cấu hình cần phải tuân theo với quy ước đặt tên được định nghĩa ($Region-config.yaml) và xác nhận chắc chắn chỉ có một tệp cấu hình tồn tại đối với một region trên một tài khoản. Các S3 bucket được bật thông báo về sự kiện mà nó sẽ xuất tất cả sự thay đổi từ tệp cấu hình đến một local default bus tại Amazon EventBridge.

2. Các quy tắc của EventBridge để giám sát những bus mặc định và chuyển tiếp nó đến các sự kiện liên quan đến sự kiện bus tùy chỉnh ở tài khoản trung tâm. Các quy tắc của EventBridge đặc biệt giám sát sự kiện VPCDelete được đẩy lên bởi Amazon CloudTrail và Thông báo sự kiện từ S3. Khi một VPC bị xóa từ tài khoản phụ thuộc, Các sự kiện VPCDelete dẫn đến việc loại bỏ các quy tắc tương ứng từ chính sách tường lửa. Thêm nữa, tất cả sự kiện, khởi tạo, cập nhật, xóa từ thông báo của Amazon S3 cũng gọi các hành động tương ứng trên chính sách tường lửa

3. Hai AWS Identity and Access Manager (IAM) roles với từ khóa xaccount.lmb.rc và   xaccount.lmb.re được giả định bởi hàm RuleCollect và RuleExcute ở tài khoản trung tâm 

4. Nhóm Nhật ký CloudWatch để lưu trữ nhật ký các sự kiện được xử lý bởi ứng dụng AWS Lambda ở trung tâm.

Ở tài khoản trung tâm:

5. Các quy tắc của EventBridge giám sát những sự kiện bus tùy chỉnh và gọi một hàm Lambda được gọi là RuleCollect. Một hàng đợi thông báo không gửi được được gán vào các quy tắc của EventBridge để lưu trữ sự kiện khi gọi hàm Lambda thất bại.

6. Hàm RuleCollect lấy tệp cấu hình từ tài khoản phụ thuộc bởi việc giả định một vai trò ở các tài khoản khác. Với vai trò được tiển khai bởi cùng stack mà nó được tạo bởi tài nguyên từ tài khoản phụ thuộc khác. Hàm lambda sẽ xác minh những yêu cầu,thay đổi những yêu cầu tới quy tắc syntax của Suricata, và công bố các quy tắc cho một Amazon Simple Queue Service (Amazon SQS) hàng đợi vào trước – ra trước ( FIFO ). Kiểm soát được đầu vào là điều cần thiết để chắc chắn những người dùng sẽ không lạm dụng các chức năng của giải pháp này và bypass được quyền quản trị trung tâm. Hàm lambda có kiểm soát xác thực đầu vào để xác thực các thông tin sau:

• ID VPC trong tệp cấu hình tồn tại trong Khu vực được định cấu hình và cùng tài khoản AWS với S3 bucket.
• Đối tượng S3 có id phiên bản được nhận từ sự kiện phải trùng khớp với id phiên bản mới nhất để giảm thiểu các điều kiện giống nhau
• Người dùng không có các miền cấp cao nhất (ví dụ: .com, .de) trong quy tắc.
• Quy tắc tùy chỉnh của Suricata không có bất kì địa chỉ IP hoặc tên miền đích nào.
• Định danh của VPC đúng với yêu cầu định dạng, như là, a+ (ID tài khoản aws ) + ( VPC ID không cần vpc-prefix ) trong quy tắc tùy chọn. Điều này là quan trọng để có biến quy tắc độc nhất trong nhóm các quy tắc
• Các quy tắc không sử dụng các từ khóa bảo mật nhạy cảm như là sid, priority, or metadata. Những từ khóa này được dành riêng cho quản trị viên tường lửa và ứng dụng lambda
• Cấu hình VPC đã được gán cho một AWS Transit Gateway.
• Chỉ có quy tắc cho phép tồn tại trong cấu hình quy tắc.
• Khoảng CIDR cho một VPC được ánh xạ phù hợp để sử dụng biến IP Set.

Việc xác thực đầu vào phải chắc chắn rằng quy tắc được định nghĩa bởi một tài khoản phụ thuộc mà không ảnh hưởng đến các quy tắc của các tài khoản phụ thuộc khác. Các xác thực được đồng ý vào các quy tắc tường lửa có thể được cập nhật và quản lý lúc cần thiết theo nhu cầu của bạn. Các quy tắc được tạo ra cần phải theo một định dạng nghiêm ngặt, và việc sai lệch từ những quy tắc ở trước sẽ dẫn tới việc từ chối yêu cầu.

7. Dịch vụ Amazon SQS có hàng đợi duy trì thứ tự thực hiện các hoạt động, tạo , cập nhật và xóa trong cấu hình bucket của các tài khoản phụ thuộc. Các biện pháp kiểm soát quản lý trạng thái này duy trì tính nhất quán giữa các quy tắc tường lửa trong tệp cấu hình ở trong một s3 bucket và các quy tắc ở trong chính sách tường lửa. Nếu như trình tự cập nhật được cung cấp bởi cấu hình phân tán không được tuân theo, các cấu hình ở trong chính sách tường lửa có thể sẽ không trùng với các quy tắc dự kiến.

Các quy tắc không được xử lý vượt quá ngưỡng của  maxReceiveCount sẽ được chuyển sang hàng đợi thông báo không gửi được để khắc phục sự cố.

8. Các tin nhắn từ SQS sau đó được xử lý bởi một hàm lambda khác gọi là RuleExecute. Nhiều sự thay đổi đến một cấu hình sẽ được gộp lại với nhau trong một tin nhắn. Hàm RuleExecute phân tích các thông báo và khởi tạo các nhóm quy tắc, biến IP set, và quy tắc ở trong dịch vụ Network Firewall. Ngoài ra, các hàm Lambda thiết lập một nhóm quy tắc dành riêng, cái này có thể quản lý bởi các quản trị viên giải pháp và họ sử dụng nó để định nghĩa quy tắc chung. Các quy tắc chung, áp dụng cho các tài khoản AWS tham gia, có thể được quản lý tại tệp data/defaultdeny.yaml bởi trung tâm nhóm bảo mật.

Hàm RuleExecute còn thực hiện được việc kiểm soát số lượng để chắc chắn rằng các quy tắc này đã được áp dụng vào chính sách tường lửa mà không gặp ngoại lệ ThrottlingException từ Network Firewall  (xem các lỗi thường gặp). Các hàm này cũng thực hiện back-off logic ( phương thức giảm nhấp nhô ) để xử lý các ngoại lệ. Hiệu ứng kiểm soát này có thể xảy ra nếu có quá nhiều yêu cầu được gửi tới Network Firewall API.

Các hàm này thực hiện việc gọi tới Network Firewall đi qua các Region dựa trên Region được cung cấp trong cấu hình người dùng. Cũng như không cần phải triển khai các hàm Lambda RuleExcute và RuleCollect ở trên nhiều region trừ khi trường hợp sử dụng cho phép điều đó.

Hướng dẫn

Phần sau đây sẽ hướng dẫn bạn cách triển khai công cụ quản lý quy tắc.

• Triển khai: Nêu các bước để triển khai giải pháp vào các tài khoản AWS mục tiêu.
• Xác thực: Mô tả các bước để xác thực việc triển khai và đảm bảo chức năng của giải pháp.
• Dọn dẹp: Cung cấp hướng dẫn để dọn dẹp những tài nguyên đã được triển khai.

Triển khai

Trong giai đoạn này, bạn triển khai ứng dụng pipeline trong tài khoản tài nguyên. Pipeline này chịu trách nhiệm triển khai các stack CDK đa tài khoản đa khu vực trong cả tài khoản trung tâm và tài khoản quản trị viên được ủy quyền.

Nếu như bạn không có tường lửa mạng đang hoạt động trong Network Firewall sử dụng mô hình triển khai trung tâm ở tài khoản trung tâm. Hãy xem qua README để được hướng dẫn trong việc triển khai Amazon VPC và Network Firewall stacks trước khi tiến hành. Bạn cần triển khai Tường lửa mạng trong quá trình triển khai tập trung ở từng Region và AZ của hạ tầng VPC được sử dụng từ tài khoản phụ thuộc.

Quy trình triển khai ba stack ứng dụng trong tất cả các khu vực được định cấu hình: LambdaStack và ServerlessStack trong tài khoản trung tâm và StacksetStack trong tài khoản quản trị viên được ủy quyền. Bạn chỉ nên triển khai các stacks này trong Region chính, vì giải pháp này có thể quản lý hiệu quả trên tất cả các Region mà nó hỗ trợ.

• LambdaStack triển khai các hàm Lambda RuleCollect và RuleExecute, hàng đợi FIFO của dịch vụ Amazon SQS, và hàng đợi FIFO không thông báo gởi.

• ServerlessStack triển khai bus EventBridge, quy tắc EventBridge và hàng đợi không thông báo gởi của EventBridge.

• StacksetStack triển khai bộ stack do dịch vụ quản lý trong tài khoản quản trị viên được ủy quyền. Bộ stacks bao gồm việc triển khai các vai trò IAM, quy tắc EventBridge, S3 bucket và nhóm nhật ký CloudWatch trong tài khoản phụ thuộc. Nếu bạn đang triển khai mẫu CloudFormation theo cách thủ công (templates/spoke-serverless-stack.yaml) trong tài khoản phụ thuộc , thì bạn có tùy chọn tắt stack này trong cấu hình ứng dụng.

Ảnh 2: Cloudformation stacks được triển khai bởi pipeline ứng dụng

Chuẩn bị cho boostrapping

1. Cài đặt và cấu hình hồ sơ cho tất cả các tài khoản AWS sử dụng Amazon Command Line Interface (AWS CLI)

2. Cài đặt Cloud Development Kit (CDK)

3. Cài đặt git và sao chép GitHub repo

4. Cài đặt và kích hoạt Docker Desktop

Chuẩn bị cho việc triển khai

1. Làm theo README và hướng dẫn cdk boostrapping để boostrap vào tài nguyên tài khoản. Sau đó, bootstrap tài khoản trung tâm và tài khoản quản trị ủy quyền ( tùy chọn nếu như StacksetStack được triển khai thủ công trên tài khoản phụ thuộc)  để tin cậy các tài nguyên tài khoản. Tài khoản phụ thuộc không cần thiết phải bootstrapped.
2. Tạo một thư mục có tên là <STAGE>, trong đó STAGE là tên của giai đoạn triển khai – ví dụ, local, dev, int , và nhiều hơn thế nữa – trong thư mục conf của repository được sao chép. Giai đoạn triển khai được đặt làm tham số Stage sau này và được sử dụng trong tên tài nguyên AWS.
3. Tạo Global.json trong thư mục <STAGE>. Thực hiện theo README để cập nhật các giá trị tham số. Tệp JSON mẫu được cung cấp trong thư mục conf/sample.
4. Chạy các lệnh sau để cấu hình môi trường cục bộ:

npm install export STAGE=<STAGE> export AWS_REGION=<AWS_REGION_to_deploy_pipeline_stack>

Triển khai ứng dụng

1. Tạo tệp có tên app.json trong thư mục <STAGE> và điền các tham số theo phần README và lược đồ đã xác định.

2. Nếu bạn chọn quản lý việc triển khai stack của tài khoản phụ thuộc bằng tài khoản quản trị viên được ủy quyền và đã đặt tham số triển khai_stacksets thành true, hãy tạo một tệp có tên stackset.json trong thư mục <STAGE>. Thực hiện theo phần README để phù hợp với các yêu cầu của lược đồ đã xác định.

Bạn cũng có thể triển khai stack cho tài khoản phụ thuộc theo cách thủ công để thử nghiệm bằng cách sử dụng mẫu AWS CloudFormation trong templates/spoke-serverless-stack.yaml. Thao tác này sẽ tạo và định cấu hình các tài nguyên cần thiết của tài khoản phụ thuộc.

3. Chạy các lệnh sau để triển khai ứng dụng:

export STACKNAME=app && make deploy

Ảnh 3: Ví dụ về đầu ra của pipeline ứng dụng được triển khai

Sau khi triển khai giải pháp, tài khoản phụ thuộc cần phải cấu hình quy tắc lưu trữ trạng thái cho tất cả VPC trong tệp cấu hình và tải nó lên S3 bucket. Người sở hữu tài khoản phụ thuộc cần phải xác thực kết nối VPC đến tường lửa sử dụng mô hình triển khai trung tâm. Cấu hình được trình bày bằng ngôn ngữ cấu hình YAML, có thể bao gồm nhiều định nghĩa quy tắc. Mỗi tài khoản phải cung cấp một tệp cấu hình cho mỗi VPC để thiết lập trách nhiệm giải trình và tính không thoái thác.

Xác thực

Bây giờ bạn đã triển khai giải pháp này, làm theo các bước tới để xác nhận rằng mọi thứ đã hoàn thành như thực tế, và sau đó kiểm thử ứng dụng.

Xác thực việc triển khai

1. Đăng nhập vào AWS Management Console sử dụng tài nguyên của tài khoản và mở CodePipeline

2. Xác minh liệu có pipeline có tên 

cpp-app-<aws_organization_scope>-<project_name>-<module_name>-<STAGE>

có trong cấu hình ở Region

3. Xác minh các pipeline tồn tại trong mỗi quy trình trong tất cả các Region được định cấu hình.

4. Xác nhận rằng tất cả các pipeline của quy trình đều tồn tại. Các stage LambdaStack và ServerlessStack phải tồn tại trong stack 

cpp-app-<aws_ Organisation_scope>-<project_name>-<module_name>-<STAGE>.

StacksetStack Stage phải tồn tại nếu bạn đặt tham số triển khai_stacksets thành true trong Global.json.

Xác thực ứng dụng

1. Đăng nhập và mở Console Amazon s3 khi sử dụng tài khoản phụ thuộc.

2. Thực hiện theo lược đồ được xác định trong app/RuleCollect/schema.json và tạo một tệp có quy ước đặt tên như ${Region}-config.yaml. Lưu ý rằng Region trong tệp cấu hình là Region đích cho các quy tắc tường lửa. Xác minh rằng tệp có dữ liệu VPC và quy tắc hợp lệ.

Ảnh 4: Ví dụ về tệp cấu hình cho Region eu-west-1

3. Tải tệp cấu hình mới tạo lên bucket S3 có tên anfw-allowlist-<AWS_REGION for application stack>-<Spoke Account ID>-<STAGE>.

4. Nếu dữ liệu trong tệp cấu hình không hợp lệ, bạn sẽ thấy nhật ký lỗi và cảnh báo trong nhóm nhật ký CloudWatch có tên 

cw-<aws_ Organisation_scope>-<project_name>-<module_name>-CustomerLog-<STAGE>.

5. Nếu tất cả dữ liệu trong tệp cấu hình đều hợp lệ, bạn sẽ thấy nhật ký về thông tin trong cùng nhóm nhật ký CloudWatch

Ảnh 5: Ví dụ về nhật ký được khởi tạo bởi anfw-automate ở tài khoản phụ thuộc

6. Sau khi xử lý thành công các quy tắc, đăng nhập vào bảng điều khiển Network Firewall bằng tài khoản trung tâm.

7. Điều hướng đến các nhóm quy tắc trong Network Firewall và tìm kiếm nhóm quy tắc có tên số được gán ngẫu nhiên. Nhóm quy tắc này sẽ chứa các quy tắc Suricata của bạn sau quá trình chuyển đổi.

Ảnh 6: Quy tắc được tạo trong nhóm quy tắc Network Firewall dựa trên tệp cấu hình ở ảnh 4

8. Truy cập nhóm quy tắc của Network Firewall được xác định bằng hậu tố dành riêng. Nhóm quy tắc này được chỉ định cho quản trị viên và các quy tắc chung. Xác nhận rằng các quy tắc được chỉ định trong app/data/defaultdeny.yaml đã được chuyển đổi thành quy tắc Suricata và được đặt chính xác trong nhóm quy tắc này.

9. Khởi tạo instance EC2 trong VPC được chỉ định trong tệp cấu hình và cố gắng truy cập vào cả địa chỉ đích được phép trong tệp và bất kỳ địa chỉ đích nào không được liệt kê. Lưu ý rằng các yêu cầu tới địa chỉ đích không được xác định trong tệp cấu hình sẽ bị chặn.

Dọn dẹp tài nguyên

1. Để tránh phát sinh phí trong tương lai, hãy xóa tất cả stack và instance được sử dụng trong hướng dẫn này.

2. Đăng nhập vào cả tài khoản trung tâm và tài khoản quản trị viên được ủy quyền. Xóa thủ công các stack trong Region được định cấu hình cho tham số ứng dụng trong Global.json. Đảm bảo rằng các stack được xóa cho tất cả các Khu vực được chỉ định cho tham số ứng dụng. Bạn có thể lọc tên stack bằng từ khóa 

<aws_ Organisation_scope>-<project_name>-<module_name> 

như được xác định trong Global.json

3. Sau khi xóa các stack, hãy xóa các pipeline stack bằng cách sử dụng lệnh tương tự như trong quá trình triển khai, thay thế cdk deploy bằng cdk destroy.

4. Chấm dứt hoặc dừng máy chủ EC2 dùng để kiểm tra ứng dụng.

Kết luận

Giải pháp này đơn giản hóa bảo mật mạng bằng cách kết hợp các cấu hình tường lửa ANFW phân tán trong chính sách tập trung. Việc quản lý quy tắc tự động có thể giúp giảm chi phí vận hành, giảm thời gian hoàn thành yêu cầu thay đổi tường lửa từ vài phút xuống vài giây, giảm tải các cơ chế vận hành và bảo mật như xác thực đầu vào, quản lý trạng thái và kiểm soát số lượng, đồng thời cho phép các nhóm bảo mật trung tâm thực thi các quy tắc tường lửa chung mà không ảnh hưởng về tính linh hoạt của các bộ quy tắc do người dùng xác định.

Ngoài việc sử dụng ứng dụng này thông qua quản lý cấu hình S3 bucket, bạn có thể tích hợp công cụ này với GitHub Actions vào quy trình CI/CD của mình để tải cấu hình quy tắc tường lửa lên S3 bucket. Bằng cách kết hợp các Github Actions, bạn có thể tự động cập nhật tệp cấu hình bằng các quy trình kiểm tra quy trình phát hành tự động, chẳng hạn như xác thực lược đồ và phê duyệt thủ công. Điều này cho phép nhóm của bạn duy trì và thay đổi các định nghĩa quy tắc tường lửa trong các quy trình và công cụ CI/CD hiện có của bạn. Bạn có thể tiến xa hơn bằng cách chỉ cho phép truy cập vào bucket S3 thông qua quy trình CI/CD.

Cuối cùng, bạn có thể đưa logs AWS Network Firewall vào một trong các giải pháp đối tác của chúng tôi để quản lý sự kiện và thông tin bảo mật (SIEM), giám sát bảo mật, thông tin về mối đe dọa cũng như phát hiện và phản hồi được quản lý (MDR). Bạn có thể khởi chạy các bản cập nhật quy tắc tự động dựa trên các sự kiện bảo mật được các giải pháp này phát hiện, điều này có thể giúp giảm thời gian phản hồi cho các sự kiện bảo mật.

Bài viết được dịch từ link blog sau đây: 

https://aws.amazon.com/blogs/security/how-to-automate-rule-management-for-aws-network-firewall