Trust Engine Constructs and Policy Model

introduction the nile trust engine enforces access decisions based on a structured and consistent policy framework 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 boundary 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 ) attributes – identity and context metadata used for advanced policy decisions (available in future releases) 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 group types group type example description user employees, contractors classifies endpoints based on user identity or scim group membership device printers, cameras, sensors groups devices not tied to user accounts using identity, mac/oui, or fingerprint data application internet, intranet, saas defines application destinations using ips, fqdns, or categories each endpoint is classified into exactly one policy group when multiple groups could apply, the most specific rule (based on ordering) takes precedence classification and ordering endpoints are evaluated against policy group definitions in sequence user groups are checked first, followed by device groups more specific classification rules 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 in an unclassified group similarly, devices that fail security posture checks are placed in the quarantine 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 not in the intranet group unclassified users or devices that do not match any defined group quarantine devices that fail 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 are 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 example for a printer, different functions (discovery, printing, administration) use distinct ports and protocols a service profile can allow employees to send print jobs while restricting administrative access to it staff default profiles open service profile allows all protocols and ports; intended for temporary use during migration or testing infrastructure services profile supports dhcp, https for identity provider (idp) communication, and optional dns dns services profile enables communication with local or external dns servers (udp/tcp 53, tcp 853 for dns over tls) custom service profiles are available to enterprise tier customers, providing fine grained control over protocol level access policy sets and policies a policy set is a collection of policies that together define how access is managed across the network each policy specifies a source, destination, service profile, and action policy components component description source the initiating policy group service profile defines the permitted protocols and ports destination the target policy group action determines enforcement allow, deny, forward, or forward to sse status indicates whether the policy is active or disabled 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