About Rulestacks and Rules on Cloud NGFW for AWS
Table of Contents
Expand all | Collapse all
-
- About Cloud NGFW for AWS
- Getting Started from the AWS Marketplace
- Register Your Cloud NGFW Tenant with a Palo Alto Networks Support Account
- Cloud NGFW for AWS Pricing
- Cloud NGFW Credit Distribution and Management
- Cloud NGFW for AWS Free Trial
- Cloud NGFW for AWS Limits and Quotas
- Subscribe to Cloud NGFW for AWS
- Locate Your Cloud NGFW for AWS Serial Number
- Cross-Account Role CFT Permissions for Cloud NGFW
- Invite Users to Cloud NGFW for AWS
- Manage Cloud NGFW for AWS Users
- Deploy Cloud NGFW for AWS with the AWS Firewall Manager
- Enable Programmatic Access
- Terraform Support for Cloud NGFW AWS
- Provision Cloud NGFW Resources to your AWS CFT
- Configure Automated Account Onboarding
- Usage Explorer
- Create a Support Case
-
-
- Prepare for Panorama Integration
- Link the Cloud NGFW to Palo Alto Networks Management
- Unlink the Cloud NGFW from Palo Alto Networks Management
- Associate a Linked Panorama to the Cloud NGFW Resource
- Use Panorama for Cloud NGFW Policy Management
- View Cloud NGFW Logs and Activity in Panorama
- View Cloud NGFW Logs in Strata Logging Service
- Tag Based Policies
- Configure Zone-based Policy Rules
- Enterprise Data Loss Prevention (E-DLP) Integration with Cloud NGFW for AWS
-
- Strata Cloud Manager Policy Management
About Rulestacks and Rules on Cloud NGFW for AWS
Rulestacks defines access control (App-ID, URL Filtering)
and threat prevention behavior of Cloud NGFW resources. A Cloud
NGFW resource uses your rulestack definitions to protect the traffic
by a two-step process. First, it enforces your rules on the to allow
or deny your traffic. Second, it performs content inspection on
the allowed traffic based on what you specify on the Security Profiles.
A rulestack includes a set of security rules, associated objects,
and profiles similar to devices groups on Panorama.
There are two types of rulestacks.
- Local Rulestack—A Local Rulestack consists of local rules and manages the local rules. A local account administrator can associate a local rulestack to an NGFW in their AWS account. To create and manage local rulestacks, you must have the Local Rulestack Admin role.
- Global Rulestack—The AWS Firewall Manager administrator can author a Firewall Manager Service (FMS) policy and associate a Global Rulestack with it. AWS Firewall Manager manages the Global Rulestack across all these NGFWs in different AWS accounts of an AWS Organization. A Global Rulestack configures pre-rules and post-rules on each NGFW. To create and manage global rulestacks, you must have the Global Rulestack Admin role.
- Pre Rules—Rules that are added to the top of the rule order and are evaluated first.
- Post Rules—Rules that are added at the bottom of the rule order and are evaluated after the pre-rules and rules defined in a local rulestack applied to an individual NGFW.
When using Firewall Manager, a combination of local and global
rulestacks allows you to create a hierarchical rules model. The
pre-rules of a global rulestacks can act as global default rules
for all associated firewalls. Then you can use a local rulestack
to define rules for specific applications or users. The post rules
can be used to allow or deny traffic that does not match any pre-rules
or those rules defined in the local rulestack.
One global rulestack and one local rulestack can be applied
to each NGFW.
If you are using Multi-Account Tenant or Multi-VPC, consider
the following changes to rulestack behavior:
- when a rulestack is created, it is mapped to a specific account.
- you can now associate a rulestack with a firewall resource in any onboarded account.
- permissions are still mapped to the account associated with the rulestack; any modifications to the rulestack must be done by a user with LRA permissions in the rulestacks account.
Certificates from any onboarded account can be mapped to a rulestack.
For example, the certificate in account1 and the certificate
in account2 can be mapped to a rulestack in account3 which could
be associated with a firewall resource in account4. In this scenario,
all accounts (1-4) must be successfully onboarded.