Large organizations can have a number of different technologies that relate to identity: Identity Providers, Identity Governance and Administration (IGA) systems, Privileged Access Management (PAM) systems, 2FA providers, Identity Orchestration Systems and possibly developer frameworks such as Open Policy Agent, and machine identity frameworks such as SPIFFE/SPIRE. So when SGNL states their offering to be a “Modern Privileged Identity Management” system, a question we get asked sometimes is: What exactly is that and how does it relate to all these other terms we’ve seen?
Privileged Access to Critical Systems
A core focus of SGNL is ensuring that, when users in the extended workforce (i.e., employees, contractors, and temps) access critical systems, their access is limited to what their current context demands - or “just-in-time” access, instead of what is the sum total of anything the employee may need to do ever (which we’ve heard people refer to sometimes as “just-in-case” access).
There are a few key tenets to SGNL’s approach:
- Zero standing access: For most critical systems, almost no one needs “birthright access”. They may be able to log in, but even after they are logged in, they should be unable to access any resources within the system, unless the context of their current access demands it.
- Access context is already available in your systems of record: You do not need to define new processes for managing access. Instead, you should be able to define policies in general and not have to take manual steps to grant or remove access on a case-by-case basis. The policies you define can take advantage of your existing business processes, as captured in your systems of record, such as CRM, CSM, ITSM, user directory, HR, device management systems, etc.
- Access policies must be readable and executable: Oftentimes, organizations define access policies in a human-readable form (i.e., English), and they get translated into groups, roles, or entitlements. Manual processes that refer to those policies are used to determine membership, either as needed, or during periodic reviews. Applications that use these groups, roles, and entitlements decide for themselves what that policy means within the scope of that application. SGNL, on the other hand, believes that policies should be simultaneously readable, manageable at enterprise scale, and executable such that decisions are always consistent with specified policies.
- Enforcement is continuous: Every access must be enforced just-in-time, as and when users require access to critical systems. Such access decisions must be made with the latest information and policies, without impacting user experience and efficiency. Even after a user logs in to a target system, if events affect their current access level, any changes in their current access levels are instantaneously propagated to all target systems, so that the user’s access within their current login session is modulated appropriately, immediately. Such propagation is done using open standards like CAEP or using proprietary integrations.
Since this deals with privileged access, you might wonder how this compares or contrasts with IGA and PAM.
Comparison with IGA (Identity Governance and Administration)
IGA systems are great for provisioning user accounts into various systems, directories, and databases. They provide rich user interfaces for managing entitlements, groups, and roles, and flexible workflows that can be adapted to your organization’s needs. They provide a good baseline for managing standing access permissions in your organization, which may be sufficient for a number of systems.
SGNL complements IGA systems (and in fact, SGNL integrates with IGA as a system of record) in order to provide zero standing access to critical systems, where standing access may cause significant risk exposure. SGNL thus provides a greater return on your IGA investments by ensuring that the access limits offered by IGA are further tightened without impacting user experience or defining new management processes.
Comparison with PAM (Privileged Access Management)
PAM systems mostly use a “shared secret” model of operation. Users check out these secrets as needed, use them in the target systems, and then check them back in. PAM systems often provide conveniences so that the user hassle is minimized and secrets are rotated so that exposure is limited if a user makes an unauthorized copy of a secret. Which users can or cannot check out secrets is generally determined using roles, groups, and entitlements, and your PAM system may often be integrated with your IGA system for this purpose.
There are a large number of critical services and systems where the shared secret model is the only option. These systems (e.g., routers or on-premise servers) often do not provide single sign-on-based access directly to users, therefore users have to obtain a shared secret (e.g., a “root” account and password).
Newer systems, especially those that run in the cloud, most often provide single sign-on capabilities. Once users log in using their own employee account, their access privileges are most often determined by roles and groups within the target system. IGA systems can be used to provision these memberships in the target system.
Where the target system offers single sign-on, SGNL’s Modern Privileged Identity Management approach has several advantages:
- Role memberships are reduced to zero by default. No one has birthright access to anything, so even if a user logs in to those systems, they are unable to do anything.
- Users gain access only to those parts of the target system that are required by the current context of the user’s access. For example, if a user is assigned an on-call ticket to deploy a patch to specific production resources, the user gets temporary access only to those resources.
- Users’ access is removed when the context no longer demands it. Say, when a case the user is working on is closed, they immediately lose access in the target system, because SGNL does “event-time” processing in order to update the role or group memberships in the target system to remove such access.
Related Articles
Here are a few other articles on the SGNL website about Zero Standing Privilege:
- SGNL is proud to support Zero Standing Privilege in Microsoft Copilot as a plugin on that platform.
- The evolution of Authorization: A quick summary of the CyberHut webinar featuring SGNL CTO, Atul Tulshibagwale
- CAEP: The “R” in ITDR: A blog post that describes how standards such as CAEP can deliver ZSP