Trust Service Constructs Overview

introduction the nile trust engine enforces access decisions for each flow based on a structured and consistent policy framework that applies to all endpoint types, without requiring agents this framework defines how users, devices, and applications are classified, grouped, and governed under the principles of zero trust every communication request passes through a sequence of constructs that determine whether access is allowed, denied, or redirected core constructs the trust engine relies on several key constructs that work together to deliver comprehensive and scalable policy enforcement policy groups – logical collections of endpoints that define the security perimeter based on endpoint characteristics, such as identity service profiles – sets of permitted protocols and ports for specific types of traffic policy sets and policies – the rules that dictate which entities can communicate and how actions – enforcement behaviors applied to matching traffic (allow, deny, forward, etc ) policy groups policy groups are the foundation of the trust engine they allow administrators to define security boundaries around users, devices, or applications based on identity, context, or network characteristics policy groups are used in defining access policies, either as a source or as a destination understanding policy groups vs network segments nile’s zero trust policies layer is decoupled from networking segments while traditional approaches use vlans and network segments as a means to define security boundaries, nile allows policy groups to be completely identity based any user or device can obtain an ip from any network segment, while their access policy can be purely based on identity and context with identity based policy groups, segmenting devivces using network segments is unnecessary all enterprise endpoints can reside in a single subnet and still be securely isolated with traffice governed by least privilege access policies for customers who still desire to segment endpoints using network segments, whether for organizational or operational/interworking purposes, or to support multiple authentication methods, nile fully supports policy groups that map to network segments group types true 121,100,100left 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 each endpoint is classified into exactly one policy group when multiple groups apply, the most specific rule (based on ordering) takes precedence classification and ordering the process of classifying endpoints occurs after an endpoint has obtained its ip address and has completed the network on boarding process once on boarded, e ndpoints are classified into a policy group based on evaluation priority user group definitions are checked first, followed by device groups more specific classification groups should be placed higher in the list to ensure correct matching if an endpoint does not match any defined policy group, it is automatically placed into the unclassified policy group, where they can then be manually assigned devices that fail continuous device validation checks are placed in the quarantine policy group default and system groups nile provides predefined groups to simplify policy creation local all endpoints within a nile service block external endpoints outside of a service block intranet customer defined rfc 1918 address space internet public network destinations that are non rfc 1918 addresses unclassified users or devices that don’t match any defined group quarantine devices that fail optional device validation checks these groups are automatically recognized by the trust engine and appear in the policy interface as selectable sources or destinations identity based segmentation unlike traditional vlan based security, nile’s policy groups can be identity driven this means users and devices can share the same ip segment while maintaining strict isolation through host based controls this approach simplifies network design and reduces the need for static segmentation service profiles service profiles define which protocols and ports are permitted when traffic between policy groups is allowed they ensure communication adheres to least privilege principles by restricting flows to only what is necessary service profiles are mandatory for any policy that is configured to allow or forward traffic this is consistent with zero trust principles rules within a service profile are ordered, and the default rule is to exclude any port and any protocol (i e , "deny all ports/protocols") example for a printer, different functions (discovery, printing, administration) use distinct ports and protocols a service profile can be used to allow employees to discover printers and send print jobs only, and restrict access to administrative interfaces with servicei profiles, precise access can be granted based on role default profiles open service profile allows all protocols and ports; intended for temporary use during migration or testing infrastructure services profile supports dhcp (udp 67), https (tcp 443) for sso identity provider (idp) communication if a local dns is used, the dns protocol can be added to this service profile dns services profile enables communication with external dns servers (udp/tcp 53, tcp 853 for dns over tls) custom service profiles are available to enterprise trust service customers, providing fine grained control over protocol level access action an action determines how a flow is enforced within an access policy every flow is inspected by the centralized policy engine and the resuling action is logged in the policy log, detailng how the flow was treated true 90,284 85260770975054,286 14739229024946left 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 policy sets and policies a policy set is a collection of policies that together define how access is managed within the network each policy specifies a source, destination, service profile, and action 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 global policy set each nile tenant includes one global policy set , automatically applied to all sites it contains system defined defaults that ensure essential network operations, such as dns resolution and dhcp onboarding, function without manual setup administrators can add custom policies to the global policy set to reflect organizational requirements future releases may include support for multiple policy sets per tenant for more granular control policy logging every flow evaluated by the trust engine generates a log entry visible in nile control center logs include timestamp source and destination groups ip and mac addresses protocol and port service profile name enforcement action these logs enable administrators to audit policy effectiveness, identify unauthorized attempts, and refine enforcement strategies summary the trust engine’s constructs—policy groups, service profiles, policy sets, and actions form a unified framework for implementing zero trust across enterprise networks by classifying endpoints through identity and context rather than topology, nile delivers precise, scalable, and adaptable security enforcement next policy group management — learn how to create, classify, and manage policy groups for users, devices, and applications