Identity Governance

Governance for Tier 0/1 Systems - Who should have access?

Governance for Tier 0/1 Systems - Who should have access?
5:33


The Enterprise Access Model (EAM), is a framework designed to safeguard privileged access. Originally developed by Microsoft, this model enhances security by segmenting access into distinct tiers, with the goal of preventing unauthorized privilege escalation and lateral movement by attackers.

This begs the question, who should have access to those tiers? Is that access appropriate?  This is the core of identity governance, and the Enterprise Access Model gives a nice frame of reference to answer these questions.   Let’s dig in:

For reference: the EAM categorizes IT resources into three tiers, but we’ll just discuss tier 0 and 1 today:

Tier 0 (Control Plane): The crown jewels of your IT environment. 

Tier 1 (Management Plane): Systems that manage business-critical applications and processes. 

Tier 2 (User Access): Encompasses user accounts and devices with minimal privileges to limit the damage of a potential breach.

Tier 0 Governance

Access to Tier 0 systems should be highly restricted and limited only to the most trusted personnel. These systems can grant attackers control over your entire infrastructure.  Having a Tier 0 account compromised is BAD NEWS. 


Who Should Have Access?

  • Dedicated Tier 0 Administrators
      • Ex. Identity and access management (IAM) admins, directory admins, and cloud control planes admins.
      • Best practice: Create dedicated admin accounts that work exclusively within the Tier 0 environment and not perform tasks in lower tiers (Tier 1 or Tier 2).  Lock those accounts down!
  • Privileged Identity Management (PIM) Users
      • Individuals granted elevated access temporarily using Privileged Identity Management tools. This access should be time-bound and provided only for specific tasks.
  • Incident Response and Security Teams (Under Specific Circumstances)
      • These teams may require Tier 0 access during security incidents to investigate, contain, and remediate threats. Access should be granted on a need-to-know basis and revoked immediately afterward.
  • Third-Party Vendors (Rare and Controlled)
    • External consultants or managed service providers may occasionally require Tier 0 access. Their access should be tightly controlled, monitored, and limited to the scope of their work.

Recommended Actions:

  1. Regularly review access for anyone with Tier 0 access, and removing anything not absolutely required (some teams do this monthly)

  2. Catalogue all trusts and nested access that provide Tier 0 controls (this is where most teams get caught).  Teams should specifically review: 
    1. Cross-forest Trusts
    2. Federated/Nested Access
    3. IDP Permissions
    4. Cloud Account Linkages (Ex. AWS to Azure)
    5. Legacy Trusts (Ex. NTLM / Kerberos)

It’s common to identify over-provisioned access due to un-managed trusts or nested access permissions.  Most IGA solutions don’t see those kinds of permissions and so they escape governance efforts.  

Clarity has found 30% of all access is nested or federated through trusts and outside the scope of typical controls.   That’s a lot of mistakes waiting to be discovered!


Tier 1 Governance

Tier 1 encompasses all your business critical systems (like CRM/ERP/Finance applications).  Since the number of systems is larger, and the number of people is much larger, leveraging approaches like RBAC and Separation of Duties is key. 

1. Role-Based Access Control (RBAC) / Least Privilege:

  • Define and enforce access policies based on job roles.
  • Differentiate between system administrators, application owners, and operations staff.

2. Separation of Duties:

  • Ensure no single individual has complete control over critical Tier 1 systems.
  • For example, separate responsibilities for system configuration and auditing.

3. Tier Boundary Enforcement:

  • Prevent cross-contamination with Tier 0 systems, like mixing credential use between layers

Who Should Have Access to Tier 1?

1. System Administrators / Application Owners

  • Ex. Administrators responsible for maintaining ERP systems like SAP or DevOps engineers managing Kubernetes or Jenkins pipelines.

2. IT Operations Staff - Teams responsible for monitoring, troubleshooting, and ensuring uptime

3. Third-Party Vendors or Contractors - External parties providing specialized support for Tier 1 applications.

  • Access should be limited to their scope of work.
  • Permissions should be temporary and monitored closely.

4. Incident Response Teams - Security teams that may require access during investigationsConditions:

  • Access should be temporary and revoked after the incident is resolved.
pg10

Conclusion

The Enterprise Access Model provides a strong framework for access governance, and an easy way of deciding “is this access appropriate”.   What it doesn’t do is help you find what access exists within your organization. 

Clarity has a set of best practices we’d recommend:

  • Don’t trust your IDP (it doesn't know everything) - Ensure you review application accounts that aren’t managed from the IDP
  • Actively manage your federation trusts and nested access (there’s more than you think)
  • Create a strong governance structure, and regularly review key access (what was appropriate then may not be appropriate now) 

Doing these things will help put your organization ahead of the next cyber attack, and help reduce costs for you. 

To learn more about how Clarity can secure your organization’s critical resources, visit Clarity Security.

Similar posts

Get notified on new IGA insights

Be the first to know about new Identity Governance insights, cybersecurity industry news, and product updates.