As your reliance on cloud platforms such as AWS grows, so do demands for exceptional “break glass” privileged access to the AWS infrastructure. This, combined with development, IT, or operations teams that could request such access, requires that you have a scalable way to process such requests while maintaining security requirements. It is also important that the permission to access any critical infrastructure platform such as AWS is based on the “least-privilege access” principle: Users are limited to the resources that need such exceptional access, and only for the duration of the access.
SGNL provides an innovative solution which doesn’t require users to have ambient access privileges to AWS. SGNL integrates with your Identity Provider (IdP) and authorizes specific users limited privileged access to AWS only when needed. SGNL determines the need based on data continuously ingested from multiple systems of record. This includes approval workflows in your existing ITSM system such that permissions for a specific user are elevated when a case is appropriately escalated, approved and assigned, and removed as soon as the case is marked as completed. SGNL also produces a detailed audit of each such access that helps with your compliance goals.
SGNL provides an innovative solution which doesn’t require users to have ambient access privileges to AWS. SGNL integrates with your Identity Provider (IdP) and authorizes specific users limited privileged access to AWS only when needed.
Scaling Approval Processes
A normal business process where an issue is discovered, tracked, and escalated will naturally intersect substantially with an organization’s ITSM system such as ServiceNow or JIRA. These systems also offer flexible workflow and approval processes, which can be tailored to your organization.
Sometimes, organizations trigger manual workflows in unrelated systems such as their IGA to actually grant the right employee the required access to AWS in order to respond to the issue. Since the issue details in the ITSM system are not available in the IGA, approvers have to manually determine which specific AWS instances or resources the employee needs to be provided access to. Such manual determination and decision making could become a source of compromise or erroneous access grants.
With SGNL, another system (such as your IGA) is not required to map such activity into manually granting a privilege to access AWS. Instead, SGNL derives this information by continuously synchronizing data from your systems of record, including your directory and your ITSM system. So, if you define a secure workflow in your ITSM environment (where the issue is tracked anyway), SGNL can directly leverage that to determine access to AWS.
If you define a secure workflow in your ITSM environment (where the issue is tracked anyway), SGNL can directly leverage that to determine access to AWS.
SGNL dynamically assigns privileges to the specific AWS resources required to address the issue for the duration required by the ITSM ticket. SGNL does this by working in conjunction with your IdP and ensures that the SAML assertion that AWS receives from your organization to login the employee has the appropriate attributes and duration that is required to resolve the issue.
IGA Automates Coarse-Grained Access
IGA systems are designed to combine approval workflows with role management. This role data is then propagated as required by various applications. This model, which is successfully deployed in a number of organizations, works great for coarse-grained access control. You can think of coarse-grained access control as something that answers the questions: “Can this user access this application”, or “In which role can this user access this application”.
SGNL on the other hand, provides fine-grained access control, which answers the question “Should this user access this specific functionality within this application at this time, and with what privileges should the current access be granted”. In the case of AWS, the IGA system can be used to determine the set of all users who could get break-glass access to AWS. Coexisting with your IdP and IGA, the SGNL solution can be used to determine whether a specific user should be allowed to login to AWS at this particular time, and if they are allowed, which specific AWS resources should they be allowed to access for the current session, and how long the session should last.
Coexisting with your IdP and IGA, the SGNL solution can be used to determine whether a specific user should be allowed to login to AWS at this particular time, and if they are allowed, which specific AWS resources should they be allowed to access for the current session, and how long the session should last.
Just-In-Time Access Management
SGNL does all this by implementing a new approach: Just-In-Time Access Management (JITAM). It works as follows:
- Dynamic Graph Directory: SGNL builds and continuously updates a rich graph based on an organization’s systems of record, such as directories, Identity Providers, HR systems, CRM systems, ITSM systems and others.
- Human Readable Policies: The rich graph data structure enables administrators to write simple, human readable policies that translate to relationships within the graph. Reusable snippets enable administrators to share common policies also in a human readable fashion.
- Real-time Enforcement: SGNL enforces the access policy at the time an access request is actually made, based on the latest data available in the graph directory. In the case of AWS, this enforcement is done at the time a user requests a login via your IdP. For other applications, this can happen for every access.
- Comprehensive Audit: Since every access decision is based on real-time data available in the graph, a detailed audit of why an access was granted or denied is generated for every access.
AWS Integration Architecture
The following diagram describes how SGNL works with various systems of record and your identity provider to provide limited, temporary break-glass access to specific AWS resources.
Limited Access
An organization may possess hundreds of AWS instances, and it is important that any access to AWS is limited to the specific instance(s) required to address a particular issue. Leveraging information in the graph, SGNL shapes the SAML assertion the IdP sends to AWS to only have the instance(s) required to address the issue the user is working on.
Similarly, SGNL also controls the duration of the AWS session so that users cannot retain the access beyond the period of time the issue is expected to resolve in.