User Data Center Traffic Policies

1. Create application allow list Security policy rules for user traffic to allow appropriate access.
   Place allow rules for user access at the top of the rulebase, before block rules, to prevent accidentally blocking legitimate traffic. For each rule, configure Log at Session End on the Actions tab and set up Log Forwarding to track and analyze rule violations.
   • Enable employee user access to internal corporate DNS servers. This rule allows any user because users access DNS services before they log in. The rule tightly controls the source zone, destination servers, and application, and applies Security profiles to the traffic.
     Block access to external DNS servers at the internet gateway to prevent DNS traffic from going out on the internet to public servers. Allow access only to sanctioned DNS servers and use the DNS Security service to prevent connections to malicious DNS servers.

   • Allow secured, privileged access to data center management interfaces for the necessary IT personnel. Restrict the rule to management interfaces (this example uses an address group to identify the devices and a custom service to identify the management ports) and the necessary applications, in this example, RDP, SSH, and SSL. Use a dedicated VLAN to separate management traffic from other traffic and place management interfaces on the same subnet.
     If the same IT user group also manages switches, routers, and other data center devices, add them to the destination and add their ports to the custom service so the rule secures traffic for connections to their management interfaces. If different IT groups manage different data center resources, create separate Security policy rules and corresponding Decryption and Authentication policy rules for each group.

   • Allow required access for employee user groups. These rules limit each user group’s (or user’s) access to the necessary applications and servers. This example limits an engineering user group’s access to only its development servers and applications.

   • Allow targeted, limited access to contractors, partners, customers, and other third-parties. This example limits access for an SAP contractor group so the group can reach only the appropriate SAP database servers, using only the appropriate applications.

2. Create Authentication policy rules for user traffic to authenticate data center access.
   For each user group or user for whom you create application allow rules, create an analogous authentication rule (except the DNS allow rule because DNS occurs before users authenticate to log in). For each rule, configure Log at Session End on the Actions tab and set up Log Forwarding to track and analyze rule violations.
   • Authenticate users who need specialized access. This example authenticates the IT personnel who need secure privileged access to manage data center servers from the preceding step’s allow rule. Because compromising the credentials of a privileged user hands an attacker the keys to your data center kingdom, require Multi-Factor Authentication (MFA) to protect against stolen credentials.
     If the same IT user group also manages switches, routers, and other data center devices, add them to the destination and add their ports to the custom service so the rule authenticates traffic for connections to their management interfaces. If different IT groups manage different data center resources, create separate Security policy rules and corresponding Decryption and Authentication policy rules for each group.

   • Authenticate employees with legitimate business reasons to access the data center. This example authenticates the engineering development user group from the preceding step’s allow rule.

   • Authenticate contractors, partners, customers, and other non-employee groups. Require MFA for non-employee groups to protect against credential theft at a third-party company. This example authenticates the SAP developers from the preceding step’s allow rule.

3. Create Decryption policy rules for user traffic to decrypt traffic you allow so the firewall can see, inspect, and apply Security policy to the traffic.
   For each Decryption policy rule, apply the appropriate best practice Decryption profile (SSL Inbound Inspection, SSL Forward Proxy, SSH Proxy, or No Decryption, including best practice SSL Protocol Settings for SSL Inbound Inspection and SSL Forward Proxy rules) to block weak protocols and algorithms and to verify server certificates. For each SSL Inbound Inspection rule, import the certificate of the of the data center server you are protecting with decryption.
   Exclude traffic from decryption only for these two reasons:

   • Traffic breaks decryption for technical reasons, such as a pinned certificate or mutual authentication. Add technical exclusions to the DeviceCertificate ManagementSSL Decryption Exclusion list.
   • Traffic that you choose not to decrypt because of business, regulatory, compliance, or other reasons, such as financial, health, or government traffic. Create policy-based decryption exclusions for traffic you choose not to decrypt.
   • Decrypt traffic from the previously created Security policy rule that allows IT privileged access to management servers. The Decryption policy rule and its associated Decryption profile differ depending on whether the IT group uses SSL (SSL Forward Proxy Decryption profile) or SSH (SSH Proxy Decryption profile) to access management ports.
     If the same IT user group also manages data center switches, routers, and other devices, add them to the destination and add the server certificates so the rule decrypts traffic for connections to their management interfaces. If different IT groups manage different sets of data center resources, create separate, tight Security policy rules and corresponding Decryption and Authentication policy rules for each group.
     For SSL privileged access:
     For SSH privileged access:

   • Configure SSL Inbound Inspection to decrypt allowed traffic from employee user groups. This example decrypts traffic from the analogous engineering development user group allow rule.

   • Configure SSL Inbound Inspection to decrypt allowed traffic from contractors, partners, customers, and other third-parties. This example decrypts traffic from the analogous SAP contractor user group allow rule.

   • Apply a No Decryption profile to configure server verification for traffic that you choose not to decrypt because of business, regulatory, compliance, or other reasons, such as financial, health, or government traffic. This example shows how to exclude two groups of finance users from decryption when they access servers in the Fin Servers address group.
     Do not apply a No Decryption profile to TLSv1.3 traffic because the certificate information is encrypted, so the firewall cannot block sessions based on certificate information.