Resources
Oct 6, 2022

How Opal Secures Internal Tools

Opal enables organizations to implement least privilege for sensitive custom apps and admin tools

Kudos to
No items found.
Author
Eugene Ling
Head of Growth

How Opal Secures Internal Tools

As companies grow, they often develop powerful admin tools so that customer-facing teams can support their users. Examples of these tools include impersonating customers and performing admin actions. While beneficial, they are also highly privileged. Especially in light of recent social engineering attacks, we take our customers’ trust very seriously. To protect our internal admin tool, we apply the following principles:

  1. Just-in-time access: Employees do not have long-standing access, and requests are just-in-time and fully audited
  2. Granular access: Access to the internal tool is highly scoped
  3. Time-bounded access: All access to the internal tool will automatically expire after 4 hours
  4. Authenticated approvals: Approvers must validate their identity using 2FA
  5. Audited controls: Audit and log all approvals.

Note: The screenshots below are not representative of our internal tool and are for illustrative purposes only.

To learn more about our custom connectors, please see our documentation.

1. Just-in-time access: Employees do not have long-standing access, and requests are just-in-time and fully audited

To help troubleshoot our customers, we have an internal tool that lets employees impersonate our customers in a Read-Only manner. Given the platform's sensitivity, Opal employees do not have long-lived access to the internal tool. All employees have to submit an access request to our security team.

2. Granular access: Access to the internal tool is highly scoped

Employees cannot request access to the impersonation tool in its entirety, and they must scope all requests to a specific user(s). In Opal, this maps to an Access Level. Granular access allows Opal to reduce the blast radius of a breach. If an attacker gets ahold of an employee’s credentials, exposure is limited to the granted access levels.

3. Time-bounded access: All access to the internal tool will automatically expire after 4 hours

In addition to access levels, all access requests to the internal tool have a maximum duration of 4 hours. After the employee starts their session, their access will automatically expire after 4 hours. Users will need to request extensions if they need additional time.

4. Authenticated approvals: Approvers must validate their identity using 2FA

Opal’s security team streamlines approvals by automatically notifying approvers via Slack. Since this is for a privileged request, Opal mandates that all approvers must complete a 2FA challenge first.

5. Audited controls: All approvals are audited

Opal audits every access request by default. For further visibility, access to internal tools - whether through Opal or not - will create a notification in a Slack channel.

How Opal integrates with your internal tool

We have built a powerful sync engine to orchestrate access workflows across cloud infrastructure, SaaS apps, and internal tools.

If customers implement our sync API REST specification, Opal can manage the tool as if it were any other third-party system with which Opal integrates. Opal will query your web service every hour or upon manual syncs to get an updated list of applications, resources, and access levels. Any updates pulled from your custom app will be reflected in the Opal UI. When a user is added or removed from a resource in Opal (e.g., due to an approved access request or expiring access), Opal will query the Web service to notify it of the change. Your Web service should respond by triggering the corresponding access changes in your custom app.

For each custom app, you’ll need to build a Web service that implements the following REST API:

  • List resources: GET /resources
  • Get resource: GET /resources/{resource_id}
  • List users of a resource: GET /resources/{resource_id}/users
  • Add user to resource: POST /resources/{resource_id}/users
  • Remove user from resource: DELETE /resources/{resource_id}/users

Using Opal’s API, customers are able to define the following concepts:

Applications: Applications would represent admin tools. In this example, we have called the internal app Piped Viper Config

Resources: These are the sub-components or functions within admin tools, such as customer impersonation, update billing and reset password. In this example, we have called these resources Gooli, Eviato, and Moolybib.

Access levels: These are additional metadata associated with the resource, in this case, the name of the individual you impersonate. These access levels will be fetched from your database in real-time and can represent any granularity, ranging from specific users or groups of users. In this example, we are requesting access to impersonate “Andrew Rishwain

About Opal:

Opal enables companies to implement least privilege while accelerating employee productivity. Integrated with infrastructure, SaaS apps, and custom internal tools, Opal is the access management solution for IT and infrastructure teams.

Want to see it yourself? Contact sales@opal.dev or book a meeting here for a personalized demo.

Eugene Ling

Interested in Opal?

Get in touch with our team to learn more!

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.