How It Works | StrongDM

StrongDM local client infrastructure access list

The Local Client

The local client tunnels requests from the user’s workstation to the gateway, through a single TLS 1.2-secured TCP connection. StrongDM supports Mac, Windows, and Linux workstations.

To authenticate, users login to the local client; that call can be optionally redirected to your identity provider or SSO.

The local client consists of both graphical and command-line interfaces.

The Gateway

Gateways are the entry point to your network. They can be deployed with a DNS entry, sit privately on the corporate network, and/or behind a VPN.

In the case of a flat network, it is the gateway that talks to the target systems. If internal subnets disallow ingress, relays create a reverse tunnel to form connections to the gateway. All data routes through your network.

Gateways decrypt credentials on behalf of end users, and deconstruct requests for the purposes of auditing.

Gateways and relays are deployed in pairs, and scale horizontally.

Configuration Layer

The Admin UI houses configuration. Users are assigned to roles, and roles are collections of permissions across servers, databases, clusters, and web apps. Configuration is pushed down to the end user's local client, and updated in real-time.

Trusted by:

StrongDM Design Principles

Zero Trust means that determining whether a user (person or machine) should have access to a system or data needs to be assessed throughout every session, not only when they attempt access.

Using risk-based assessment, access needs to be severed immediately if trust is no longer achieved.

Access management does not work if it only supports part of the stack, leaving other parts vulnerable. Further, tech stacks are not static – they evolve constantly. The dynamic nature of infrastructure is compounded by the use of ephemeral technologies like Kubernetes. Access management must support all critical infrastructure, from legacy systems to modern cloud-native infrastructure and ephemeral resources. Secure access controls must apply to developer environments, proof-of-concept systems, and other technical resources which may not be mission-critical but, if breached, could create a path to critical systems.

Shared credentials and standing access grants add to an organization’s risk profile because they are vulnerable to malicious actors who could use those grants to gain access. Organizations should mature their access policies/procedures away from simple identity-based access and toward Zero Standing Privilege, using Just-in-Time access workflows to reduce risk caused by perpetual, standing grants.

If a password or credential for a critical system can be seen, there is a high likelihood that it has been shared or documented in code. Every effort must be made to prevent users from ever seeing credentials.

You’ll never come to the correct conclusion during an investigation or audit if you don’t have all the information. Modern security requires comprehensive audit logs (and session recordings where applicable) of all the actions taken by everyone in your staff – admins, developers, data analysts, and contractors – across your entire stack.

"Secure Access" and "Easy to Use" must not be at odds. To ensure full adoption and compliance, the end-user experience must be simple and eliminate all complexity from the process of accessing resources, from making a request to actually connecting to the resource. Security tools must be designed to make developers’ jobs easier. Otherwise, technical staff will find workarounds that undermine security. Core design principles must support developers’ native tooling, automation and workflow or risk undermining the intended result.