How we approach access to resources:
In StrongDM, access to resources (i.e., Datasources, Servers, Clusters, Clouds, and Websites) is granted to Users through Role Membership, via the Static and Dynamic Access Rules that have been defined for that Role. Roles are assigned to (or unassigned from) User accounts and Service Accounts in either the Admin UI, CLI, or programmatically via the StrongDM Terraform provider or one of our public SDKs. All permanent User access privileges are inherited via Roles. The only way to grant access directly to Users is with Temporary Access. Some organizations deliberately implement a zero standing resources/access posture, where Users must request access to resources when they need. In this case, StrongDM can grant temporary or “time-boxed” access to a User. These types of grants occur at the User level, rather than Role level. Access is revoked by simply unassigning Role(s) from User accounts and Service Accounts in either the Admin UI CLI, or programmatically via the StrongDM Terraform provider or one of our SDKs.
Options for temporary resource access:
Generally, StrongDM administrators must grant temporary access manually with the Admin UI or CLI, or decide on the appropriate processes to do so programmatically. Ticketing systems like ServiceNow and Jira are frequently involved in temporary access workflows, especially when the requested resources are critical to a business function or process sensitive or heavily regulated data. Incident management platforms like PagerDuty and OpsGenie can also integrate with StrongDM to provide temporary access as well, and are especially suited to constantly changing duty rosters and unscheduled events. Another increasingly popular venue for temporary access workflows centers around the concept of chat ops, where requesters gain access by interacting with a bot in their corporate chat provider. StrongDM maintains an extensible chatbot for Slack and Microsoft Teams that is derived from the popular errbot project. The StrongDM CLI, Terraform provider, and SDKs may also be used to bring temporary access into IaC workflows, shell scripting, and custom/legacy codebases. Regardless of the processes used to grant temporary access, the systems, software, and tooling involved will interact with the StrongDM API.
Questions to frame temporary resource access workflows:
- What processes does your organization use to provide temporary access today?
- What resources in your organization’s infrastructure are suitable for temporary access workflows? What resources are not suitable for temporary access workflows?
- What systems, software, and tooling does your organization use to provide temporary access?
- What individuals, teams, or business units approve temporary access in your organization?
- What individuals, teams or business units consume the audit trail created by granting and revoking temporary access in your organization?
- What business processes and outcomes depend on temporary access in your organization?
- What are the regulations and policies that govern temporary access in your organization?
General recommendations and operational notes:
- If your organization has invested time, money and resources establishing a ticketing or incident response system, use it. StrongDM is working to publish official integrations to vendor marketplaces like ServiceNow and Atlassian Jira; in the interim, there is a high likelihood that integrating StrongDM with your existing tech investments will be straightforward using one of our four public SDKs (Python, Go Java, and Ruby).
- If your organization is using DevOps practices to achieve CI/CD, you should consider using the StrongDM Terraform provider to approach temporary access workflows, framed in the context of Access as Code.
- Technical staff requesting temporary access to resources are only half of the workflow; approvers are also a point of friction and delay, and access requests likely disrupt their other work. For temporary access workflows, consider what resources are suitable for automatic approval. StrongDM creates a centralized, immutable audit trail for any queries or sessions it proxies on behalf of users, and access can be revoked almost instantly, so adopting a “default yes” position for temporary resource access is greatly de-risked with StrongDM.
Relevant StrongDM Documentation:
- Access to resources via StrongDM
- Overview of roles in StrongDM
- Overview of temporary access in StrongDM
- Temporary access workflows with the StrongDM chatbot
- Temporary access via StrongDM and PagerDuty
- How to grant temporary access with the StrongDM CLI
- How to revoke temporary access with the StrongDM CLI
- Overview of the StrongDM API with links to API documentation
- Using admin tokens for programmatic access in StrongDM
- Using API Keys for programmatic access in StrongDM
- StrongDM accessbot repo on GitHub