Understanding Policies and Policy Sets

overview any communication across the zero trust fabric must have an access policy in place policies are access rules and are unidirectional when a policy is selected, the reverse trafic direction is implicitly defined using the same service profile implicit deny all posture and default inbound deny an implicit 'deny all' posture exists no endpoint can talk to any other endpoint in any other policy group without an explicit policy this implicit deny is immutable and does not appear in the ui list of policies it applies to all endpoints and isoaltes them into a "segment of one", regardless of what network segment they may be on boarded into a default non editable policy explicitly denies inbound traffic from outside the zero trust fabric external > local / deny any inbound communication that should be allowed must be explicitly defined policy components true 330,331left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type all network traffic is evaluated against the active policy set if no matching policy exists, the traffic is denied by default policy sets and matching a policy set is the collection of policies evaluated for each flow policies within a policy set have no order each flow is matched based on source group and destination group once a match occurs, the corresponding action is taken and the enforcement action is logged the zero trust fabric prevents the creation of multiple policies with the same source and destination groups, eliminating policy sprawl for example, if the following policy is configured user group “ employees ” access to device group “ printers ” with service profile “ printing service profile ”, allow then the nile control center will prevent the creation of a new policy with the exact same source and destination but perhaps different action or service profile note while there is no ordering of policies, there is ordering amongst policy groups any user endpoint will be classified into a user group based on the ordering of user policy groups, and any device will similarly be classified into a device group based on ordering of device policy groups it is important to place more specific endpoint classification rules earlier in the ordered list of policy groups by default, if no policy exists, the flow is denied enabling macro & micro segmentation the core trust service tier support traffic access policies at the network segment granularity level enterprises looking to configure basic east/west inter and intra segment granular access policies and enforce the policies natively within the zero trust fabric can do so using the core trust service tier by defining source and destination polyc groups based on network segment classification citeria for more advanced security use cases requiring zero trust least privilege access policies with micro segmentation granularity, the enterprise trust service adds an extensive level of fine grained policy controls and identity centric classification options policy definition using enterprise trust service takes into consideration user/device/application identity, customizable service profiles, and other tools for implementing more precise access controls global policy set the trust service currently supports a single global policy set it is automatically created with default policies, applies to all deployments in the tenant, and all sites are tagged with it by default the global policy set cannot be deleted by default, the global policy set includes a number of default policies default policies the trust engine automatically includes foundational policies to support essential services true 165,142,63 09969788519637,290 90030211480365left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type these defaults ensure the network remains secure and operational immediately after deployment administrators can add new rules to this policy set to reflect organizational security and compliance needs future releases will support multiple policy sets for environments that require site level customization modifying policies when a policy or any component of a policy is updated, the impact of the change is reflected not just on new flows, but also on existing flows that are impacted by the change in near realtime the nile system is periodically checking for changes that may impact traffic to ensure proper zero trust enforcement east/west and north/south policy enforcement in additton to conventional east/west enforcement within the zero trust fabric, the trust engine is capable of supporting enforcement in the north to south and south to north traffic directions when an upstream edge firewall or sd wan device exists, consideration of where north south traffic enforcement occurs is required customers have flexibility in deciding which trust service policies should be enforced locally and which should be forwarded upstream for enforcement traffic will be subjected to both the set of enforcement policies in the upstream system as well as those defined natively for outbound south to north traffic, allow and forward upstream actions are synonymous traffic that is allowed in the zero trust fabric can still be blocked by the upstream system for inbound north to south traffic, any traffic allowed by the upstream firewall is still subjected to any local policies defined that match the inbound traffic