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:
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.
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.
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.
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.
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.
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.
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:
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”
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.