Nile Trust Service Migration Guide

overview this document explains how to migrate to nile trust service, nile’s micro segmentation capability for controlling both east–west and north–south traffic it focuses on migration strategy and policy mapping, and assumes that the base trust service configuration is performed using the https //docs nilesecure com/setup guide for nile trust service greenfield deployments – new site rollouts brownfield migration from firewalls – migrating an existing firewall based network to nile trust service brownfield migration from trust service 1 0 to 1 6 – upgrading from an earlier version of nile’s micro segmentation to the latest release greenfield deployment nile recommends using identity based policies when doing a greenfield deployment the goal is to minimize the number of underlying segments while using trust service policy groups and service profiles to enforce least privilege access 1\ segregate your clients into policy groups at a new site, start by designing which policy groups you need in most environments, this includes user groups – endpoints tied to an authenticated user identity (for example, employees, guests, contractors, students/faculty) device groups – infrastructure or iot endpoints not associated with user identities (for example, printers, cameras, voip phones, bms, nvrs) application groups – destination endpoints that represent private or public applications (for example, internet, intranet, call manager, dvr, saas apps) use the https //docs nilesecure com/setup guide for nile trust service to create user, device, and application policy groups, including creating custom user, device, and app groups using device check for critical device groups where you want automatic quarantine on failed validation understanding and using system groups such as unclassified, quarantine, internet, intranet, and external 2\ design target policy groups and service profiles next, decide which service profiles you need to enforce least privilege traffic between these groups (for example, printing service , internet service , admin to printer service ) configuration for detailed steps on creating service profiles (port/protocol rule sets, default deny behavior, and profile ordering), see the “service profiles” section in the https //docs nilesecure com/setup guide for nile trust service 3\ policy creation once policy groups and service profiles are defined, create policies between groups use trust engine policies to allow, deny, or forward to firewall/sse between user, device, and app groups keep policies as simple, identity driven flows (for example, employees → printers (printing service → allow) , guests → internet (internet service → allow) , cameras → internet (all service → deny) ) for step by step instructions on creating policies like those in the table below—including matrix view, policy sets, service profile selection, and actions such as allow, deny, or forward to firewall—refer to the “policy creation” section of the https //docs nilesecure com/setup guide for nile trust service source service profile destination direction action admin printing administration printer uni allow admin all zoom rooms uni allow admin all dvr uni allow admin all voip uni allow admin all call manager uni allow admin all internet uni allow employee printing printer uni allow employee internet internet uni allow guest internet internet uni allow camera all dvr bi allow voip all voip bi allow voip all call manager bi allow zoom rooms all zoom rooms bi allow zoom rooms https internet uni allow 4\ plan and execute cutover start with a monitor/observe phase where trust service is enabled, but critical flows still go through the existing firewall (for example, via forward to firewall policies) gradually migrate specific flows (or segments) from “firewall only” enforcement to “trust service + firewall” to leverage trust service as the primary enforcement point for both east–west and north–south traffic use forward to firewall/sse only where you must preserve existing upstream inspection or meet specific compliance requirements, rather than limiting trust service to east–west traffic only 5\ validate using policy logs use policy logs in trust service and logs from the firewall to compare allowed/denied flows before and after cutover keep a simple rollback plan if an issue is detected, temporarily revert routing or disable the affected trust service policy, then reapply after correcting the rule brownfield deployment scenario 1 migration from firewalls to nile trust service use this scenario when you are replacing an existing firewall‑based segmentation design with nile trust service, while initially preserving equivalent policy behaviour assumptions a site is already onboarded to nile access service , and segments/dhcp pools are in place an on‑prem firewall is currently enforcing both east–west and north–south policies you have access to the firewall configuration and logs migration options 1 option 1 – one to one migration (no firewall changes) use nile trust service as the primary enforcement point for east–west traffic inside the nile service block for north–south flows (internet, data center, sse, etc ), create policies that forward to firewall/sse , so your existing upstream stack continues to inspect and log traffic this option minimizes risk by keeping current n/s behavior while you introduce trust service for micro segmentation 2 option 2 – extend to north/south enforcement start from the same design, but gradually shift both east–west and north–south access control to nile trust service, using upstream firewalls/sse only where deep inspection or compliance is required design appropriate user/device/app groups and service profiles for all key flows (internet, intranet, data center, sse, partner networks, etc ) create the corresponding n/s policies in the global policy set for step by step ui guidance (matrix view, policy sets, service profile selection, and actions such as allow , deny , or forward to firewall ), use the “policy creation” section of the https //docs nilesecure com/setup guide for nile trust service migration workflow 1 inventory existing firewall rules export all rules in priority order into a normalized table ( source type , source subnet , destination type , destination subnet , ports/protocols , direction ) keep this table as your single source of truth for validating the new trust service policies source type source subnet destination type destination subnet ports / protocols direction admin 192 168 10 0/24 printer 10 10 1 0/24 tcp 9100 https 443 ssh 22 uni admin 192 168 10 0/24 zoom rooms 10 10 4 0/24 all uni admin 192 168 10 0/24 dvr 172 16 2 0/24 all uni admin 192 168 10 0/24 voip 10 10 3 0/24 all uni admin 192 168 10 0/24 call manager 172 16 3 10/24 all uni admin 192 168 10 0/24 internet !192/!172/!10 all uni employee 192 168 20 0/24 printer 10 10 1 0/24 tcp 9100 uni employee 192 168 20 0/24 internet !192/!172/!10 https uni guest 192 168 254 0/24 internet !192/!172/!10 https uni camera 10 10 2 0/24 dvr 172 16 2 0/24 all bi voip 10 10 3 0/24 voip 10 10 3 0/24 all bi voip 10 10 3 0/24 call manager 172 16 3 10/24 all bi zoom rooms 10 10 4 0/24 zoom rooms 10 10 4 0/24 all bi zoom rooms 10 10 4 0/24 internet !192/!172/!10 https uni 2\ design target policy groups and service profiles map firewall source/destination objects (users, vlans, subnets, device types, application networks) to user , device , and app policy groups in nile map firewall service objects/port lists to service profiles in nile (for example, printing, admin access, internet access, voip signaling) configuration use the https //docs nilesecure com/setup guide for nile trust service “policy groups” – to create/adjust user, device, app, and system groups (including internet, intranet, external, quarantine, unclassified) “service profiles” – to define port/protocol rules corresponding to firewall services 3\ define nile policies that mirror firewall behaviour for each row in your firewall rule table, create an equivalent trust engine policy (source group, destination group, service profile, direction, action) decide, per flow, whether trust service should allow locally (enforced inside the nile service block), or forward to the firewall for upstream inspection (for example, internet and certain intranet flows) configuration follow the “policy creation” section in the nile trust service setup guide to use the global policy set or matrix view, select source/destination groups and service profiles, choose actions ( allow , deny , forward to firewall ) 4\ plan and execute cutover start with a monitor/observe phase where trust service is enabled, but critical flows still go through the existing firewall (for example, via forward to firewall policies) gradually migrate specific flows (or segments) from “firewall only” enforcement to “trust service + firewall” and, where appropriate, to pure trust service enforcement 5\ validation and rollback use policy logs in trust service and logs from the firewall to compare allowed/denied flows before and after cutover keep a simple rollback plan if an issue is detected, temporarily revert routing or disable the affected trust service policy, then reapply after correcting the rule scenario 2 migration from trust service 1 0 (access engine) to 1 6 (trust engine) use this scenario when you already run trust service 1 0 (access engine with segment based rules and east–west enforcement only) and want to move to trust service 1 6 (trust engine) with policy groups, service profiles, and optional north–south enforcement assumptions trust service 1 0 is enabled and actively enforcing segment‑based rules you have a backup/export of the current internal and external rules you understand whether you only need a one to one migration or also want to consolidate n/s rules migration options 1 option 1 – one to one migration (no firewall changes) contact nile support to enable the trust service 1 6 micro segmentation feature flag and to upgrade your environment to trust service 1 6 and migrate your existing trust service 1 0 rules to the new policy model verify that the generated policy groups and policies reflect the original segment rules for any additional tuning (e g , splitting segments into identity‑based groups), use the “policy groups” and “policy creation” sections of the https //docs nilesecure com/setup guide for nile trust service 2 option 2 – extend to north/south enforcement start from the 1 1 baseline above design user/device/app groups and service profiles for n/s flows (internet, data center, sse, etc ) create additional n/s policies in the global policy set using the same policy creation workflow described in the https //docs nilesecure com/setup guide for nile trust service note that trust service 1 0 sase forwarding patterns that are not supported in 1 6 must be redesigned here, typically using a combination of forward to firewall/sse actions and app groups such as internet, intranet, or specific sse gateways validation confirm that all original 1 0 east–west flows still work (same segment pairs, same outcomes) validate any new north–south flows against expected behavior and logging (both trust service policy logs and upstream firewall/sse logs)