Access control

The ACL policy uses an ordered set of ACL rules that specify precedence and the behavior of object groups to which workloads can connect, as well as the applications used during the connection. The ACL policy is assigned to the Security Fabric.

Microsegmentation is essentially security policy applied on a per workload basis.

FortiPolicy ACL policy rules are defined with selectors and response actions. Multiple values can be specified within a selector using OR semantics. For example, an ACL policy can be applied to a Data Center App Tier object group to allow connections to a database tier and subnets.

Policy Generation proposes ACL policies with an “implicit deny all” rule at the end. All proposed rules are permit (allow) rules. Any packet for which there is not an explicit permit rule is denied. The following table shows a sample ACL rule ordering.

Rule order	Rule name	Enabled	Description	Service or AppID	Action
1	Allow DB Tier	Yes	Database rule	MySQL400LJ	Permit
2	Allow AllToThree	Yes	Access to DHCP, DNS, and so on	TCP	Permit
3	Allow AllToTwo	Yes	Two available to all	UDP	Permit
4	Implicit DenyAll	Yes	Default	Any	Deny

Configuring ACL policies

A FortiPolicy ACL policy is an ordered set of rules that govern the ability of workloads to make connections. The ACL policy is assigned to the Security Fabric. An ACL policy’s ordered set of ACL rules specify a hierarchy of precedence and behavior applied to resource groups to which workloads can connect (permit a connection or deny a connection), including access to the applications or protocols used during the connection, as part of FortiPolicy continuous monitoring and inspection.

ACLs are part of every Security Fabric configuration. This requirement allows you to create ACLs between workloads in different data planes. In fact, you control which ACL is applied to a resource group from inside an ACL policy rule set.

ACL policies in FortiPolicy are defined with selectors and response actions. For example, an ACL policy can be applied to a Data Center Web Tier resource group to PERMIT connections to an Application Tier and external IP addresses.

You can configure access control reporting that includes options to schedule and generate monthly or quarterly audit report(s). Configure report generation for either default or custom ACLs, as needed. Go to Configuration > Reports > Access Control Rules to configure. You will need the path to a location on an SMB server to generate the report.

From the Policy > Access Control page, you can create a new ACL policy and new ACL rules, or you can edit the Default ACL Policy and add rules to customize it.

Do NOT edit deployed ACL rules in FortiPolicy. Edit deployed ACL rules in the FortiGates’ Access Control tables.

To create a new ACL policy and ACL rules:

1. Go to Policy > Access Control.

   The rules in the Default ACL Policy are displayed by default in the table. If there are other ACL policies configured, you can select them from the Policy dropdown list.

   

2. To create a new ACL policy, click the + icon, enter a name for the new policy, and click SAVE.

   

   The new ACL policy is created with a baseline rule that permits all connections from any source resource group to any destination resource group. By default, the baseline rule is enabled. The baseline rule has initial precedence, but all new rules build on this rule and, in turn, take precedence in the order hierarchy. Check the settings of the baseline rule and be sure that you want it to permit all connections. This is the catch-all rule that is executed last in the rule set (after all other rules are executed per policy).

   To edit the baseline ACL rule, click the arrow at the beginning of the row to expand it. You can change the action, options, and policy set.

3. To add a new ACL rule to the policy selected in the Policy dropdown list, click ADD NEW RULE in the top right of the page.

   

4. Enter a unique rule name.

5. In the Source column for the new rule, click the Browse Groups icon to identify the source resource groups to monitor. Click NEW GROUP to create a new resource group. Select the resource groups and then click SAVE.

6. In the Destination column for the new rule, click the Browse Groups icon to identify the destination resource groups. The ACL rule will apply to the connection between the source resource groups and the destination resource groups. Click NEW GROUP to create a new resource group. Select the resource groups and then click SAVE.

7. In the Service/AppID column for the new rule, click the Browse Groups icon to select services and AppIDs that the ACL rule will affect. Click NEW SERVICE to create a new service. When you are done, click SAVE.

8. In the Action column for the new row, select Permit, Drop, or Deny. This action applies to the services and AppIDs that you selected.

9. In the Options column for the new row, you can enable SysLog and Timeout.

   • Enable SysLog if you want to capture events related to the ACL rule on the Syslog server. To configure a Syslog server, see Syslog.

   • Enable Timeout to limit the length of a session and then enter the number of seconds that the session will last before it times out.

   After selecting the options you want, click DONE.

10. In the Policy Set column for the new rule, select Discover, All Inclusive, or Testing.

    The following are the default SPSs:

    • All Inclusive—This is a preconfigured security policy set containing the All Threats threat-prevention policy, the Default URL Filtering Policy, and the WithSXCloud Malware Policy. The All Inclusive SPS contains all threats and all application protections.

    • Discover—This SPS contains the AppVisibility threat-prevention policy, but no threat rules are enabled, and no Malware policy or URL Filtering policy is associated with this SPS.

    • Testing—This SPS is tuned for optimized performance and includes the WithSXCloud malware policy and the Common Threats threat-prevention policy.

11. In the Hits column for the new rule, click RESET if you want to clear this counter.

12. In the Description column for the new rule, enter a description of the rule.

13. Click SAVE in the lower right of the page to save the ACL rule configuration.

    The new rule is added to the rules table for this policy, above the default rule. Use the up and down arrows to move the rule up or down and change its precedence.

14. Click ADD NEW RULE to create another rule. If you have a rule selected, click ADD RULE BELOW. Continue creating rules until all access conditions are defined for this ACL policy.

ACL rules and precedence

The order of ACL rules maters because it indicates the precedence of the ACL rules. FortiPolicy uses ACL rule precedence to resolve group membership and conflicts during segmentation and microsegmentation.

The default baseline ACL rule is a “catch-all” rule that contains otherwise unclassified workloads or IPs in rule assignments. This allows large parts of a data center or cloud to be referenced, without having to create many separate rules, but only when all members of the catch-all rule share security requirements.

The last rule in the ordered list (i.e., the rule with the lowest precedence) is the “catch-all” rule, which matches every workload that has not been specified by one of the preceding rules. N

ACL policy configuration strategies

The ACL policy is attached to the Security Fabric.

• ACL rules are written for the client, so begin by creating a list of which clients can initiate a connection.

• Set up rules using the outcome approach. Using the client-side approach, FortiPolicy is more aligned with the outcome.

• ACL rules with ACL policy assignments are executed in order.

• For ACL, each rule would have its own ACL policy; for example: the web tier of an application should only connect to the application tier. An application tier should never connect to a database tier, and so on. For database tiers, a database rule generally declares that the database cannot connect to anyone and will only permit incoming connections.