Tag and Policy Design¶
This guide provides a recommended tag taxonomy and policy naming conventions for MSPs managing multiple customer tenants. These conventions are not enforced by Enclave but help maintain consistency across your customer base and make it easier for any technician on your team to understand a customer's configuration at a glance.
Tag naming rules¶
Tag names must be:
- Lowercase alphanumeric (
a-z,0-9) - No spaces
- Up to 64 characters
- Separated by
-(hyphen) or.(period)
Use . to combine multiple designators into a compound tag, with the most specific designator last: london.developers, aws-eu-west-2.production.servers.
Single-word tags are valid for broad categories: staff, contractors, servers.
For the full reference, see Tags - Naming conventions.
Recommended tag taxonomy¶
Choose designators from these categories, combining them as needed for your customer's environment:
| Category | Purpose | Examples |
|---|---|---|
| Role | Who is connecting | staff, developers, it-admins, contractors, finance |
| Resource | What they connect to | servers, file-servers, database-servers, printers |
| Site | Physical or cloud location | london, nyc-office, aws-eu-west-2, azure-uksouth |
| Environment | Deployment stage | production, staging, uat |
| Function | System purpose | webservers, domain-controllers, monitoring |
| Project | Specific initiative | project-atlas, migration-q3 |
Compound tags¶
Combine designators with . when a single category is not specific enough:
| Tag | Meaning |
|---|---|
london.staff |
Staff devices in the London office |
london.servers |
Servers in the London data centre |
aws-eu-west-2.production.webservers |
Production web servers in AWS EU West 2 |
nyc-office.developers |
Developer workstations in the New York office |
Starter set¶
For a typical MSP customer with remote access as the initial use case, start with:
| Tag | Applied to |
|---|---|
staff |
All employee laptops and workstations |
it-admins |
IT administrator devices (subset of staff) |
servers |
On-premises or cloud servers |
remote |
Devices used outside the office |
Expand as the deployment grows. Adding tags later does not disrupt existing policies.
Policy naming conventions¶
Name policies using the X for Y pattern, where X is the resource being accessed and Y is the group accessing it:
| Policy name | Sender tags | Receiver tags |
|---|---|---|
Servers for Staff |
staff |
servers |
Servers for IT Admins |
it-admins |
servers |
Database Servers for Developers |
developers |
database-servers |
Office LAN for Remote Workers |
remote |
(gateway subnet) |
File Server for Finance |
finance |
file-servers |
This convention makes policies self-documenting. When you see Database Servers for Developers in a list, you know the resource and the consumer without opening the policy.
Separate policies may grant access to the same resource for different groups. For example, developers might get access to database servers during working hours via Active Hours, while the SRE team gets 24/7 access via a separate policy:
Database Servers for Developers(with Active Hours: Mon-Fri 08:00-18:00)Database Servers for SRE
For the full reference, see Policy - Naming.
Access control rules¶
Every new policy starts with a default rule allowing All Traffic. For production use, remove this rule and add specific rules for the required protocols and ports. Restricting traffic at the policy level means you do not need to rely on host firewalls alone.
For worked examples of ACL configuration in common scenarios, see:
- Accessing on-premise Active Directory servers, which lists the full port set for AD, LDAP, Kerberos, and SMB
- Private access to an Azure File Share for SMB access via a private endpoint
Last updated July 22, 2026