Cato Management Application (CMA) roles implement RBAC to define view and edit permissions for CMA pages. Sub-policies let you assign RBAC for a set of rules to give admins autonomy over the areas they’re responsible for, while preserving centralized control and security boundaries.
Create sub-policies for specific rules and define which admins have view or edit access to those sub-policies.
Sample company has 2 SOC teams, one for EMEA and one for APJ. There are 50 rules in the Internet Firewall policy: 20 apply to all regions, 10 are only related to EMEA traffic, and 20 are only for APJ traffic. Before sub-policies, the SOC teams had permissions to view and edit all the rules in the Internet Firewall policy, which did not meet the company's compliance regulations.
Sample company used sub-policies to restrict access, so each SOC team only had access to rules that manage traffic for their region. They created an EMEA sub-policy for the 10 rules for EMEA traffic, and an APJ one for the 20 rules for APJ traffic. Now, the SOC teams can only edit the rules for their regional traffic, and the company is fully compliant with the regulations.
- The parent rule of the sub-policy is a scoping rule that defines when the rules in the sub-policy are applied to the traffic
- The sub-policy rules are also ordered rules, and the action of the first matching rule is applied to the traffic
- You can add sections for rules in the sub-policies
-
By default, an optional ANY ANY cleanup rule is added at the end of the sub-policy. This rule is only applied to:
- Traffic that matches the scoping rule for the sub-policy
- Doesn't match any other rule in that sub-policy
Note: Rules inside a sub-policy that have ANY conditions are only applied to the traffic that also matches the scoping rule of the sub-policy. That means that a rule with ANY ANY Block, doesn't impact traffic that does NOT match the scoping rule.
- Sub-policies cannot contain other sub-policies (no nesting)
Any rules not included in a sub-policy are part of the main sub-policy when defining admin permissions.
You can define which admins can view/edit each sub-policy.
First, create sub-policies and then define admin permissions for who is allowed to view or edit the rules.
Rule numbers stay consistent across the entire policy, even when some admins cannot view certain sub-policies. As a result, admins without view permissions for specific sub-policies may see gaps in the rule numbering.
You can create a sub-policy in any of the supported policies. The conditions of the sub-policy define when traffic will be applied to the rules inside a sub-policy.
Note: Make sure you define rules and permissions before you enable the sub-policy.
To create a sub-policy:
- In the relevant policy, click New > Sub-Policy.
- Define the name, position, and conditions for the sub-policy and click Save.
By default, admins have permissions to view and edit all sub-policies on every page that they have permissions for. Remove permissions for the entity for all the sub-policies and add it back for the new individual sub-policy.
To define admin permissions on a sub-policy:
- From the navigation menu, select Administration > Admins.
- Select an admin, and go to the Access Permissions for Entities area.
- In the table, locate the line for the policy (e.g., All Internet Firewall Policies) and remove view and edit permissions.
- In the drop-down, select the sub-policy category for your page (e.g., Internet Firewall Sub-Policies).
- In the second drop-down, select the target sub-policy. The sub-policy is added to the table.
- In the table, give the admin Edit or View Only permissions for the sub-policy.
- Repeat this process for every admin.
- After the admin permissions are defined, they can start configuring rules for the sub-policy.
0 comments
Article is closed for comments.