Deployment Guide Part 4 (Proxy Node Reference Architectures)

Introduction

StrongDM Proxy Node Deployment architecture for any given organization is dependent on their unique resource configurations and network topologies. 

 

These reference architectures are intended to provide examples of various use cases, applicable architecture models, and help inform users on the array of solutions available. 

 

Flat network – Gateways Only



In simple, flat environments, deploying a pair of Gateways may be all that is required to start accessing resources. For a Gateway-only setup to function, resources must have ingress open to the Gateway, and the Gateway must have egress open to the end-resources. 

 

Example use cases:

 

  • AWS Console or AWS CLI proxying 
  • Servers or Databases that have lower sensitivity or serve public content, but still require private access for administration 

 

 

Resources in isolated, no-ingress subnets - Gateways/Relays

 

In many organizations, sensitive resources are isolated to subnets that do not permit any type of network ingress. To cover these cases, StrongDM Relays can be used in conjunction with Gateways. StrongDM Relays do not require ingress on Port 5000 as they form a reverse tunnel to Gateways via egress-only network paths. This provides the benefit of isolating resources via traditional network-based methods, while still permitting resource access to authorized consumers via StrongDM. 

 

Example use cases: 

 

  • Sensitive Internal website resources 
    • Data Science Query Tools (Snowsight, Redash)
    • CI/CD Admin Panels
    • Internally Hosted Repositories
    • Performance Metric Dashboards
  • Sensitive Databases with strict network compliance requirements
  • SSH / RDP Servers with strict network compliance requirements



 

Multi-VPC Hub & Spoke - Centralized Gateways serve multiple Relays

 

Expanding on the previous example, many organizations distribute resources into multiple, segregated VPCs that do not permit ingress. This pattern acts as a ‘hub and spoke’ model by using a centralized set of Gateways that serve multiple relays in isolated no-ingress subnets. 

 

Example use cases:

 

  • Segregation of different line of business’s applications 
  • Isolating PHI/PII to separate VPCs that have greater compliance requirements than others

 

 

Multi-Environment

In scenarios where it is not desirable to use a hub and spoke model, it is also possible to utilize separate gateways and relays for their own environments. This model may be employed  when an organization uses different cloud providers or on-premises data centers completely independent of each other, or they are located geographically far enough where latency considerations require closer Gateway entry points for clients. 

 

Example use cases: 

  • On-premises vs Cloud-hosted resources 
  • Geographical separation that requires latency considerations and closer Gateways/Relays in proximity to users/resources
  • Independent teams/application owners that require greater control of the management of their proxy nodes specific to their use cases 
  • Different sensitivity levels/controls between major environments

 

 

Secret Store-backed Resource Credentials

Considering different risk profiles for different resources, StrongDM Admins can choose where actual resource credentials are stored as part of a resource onboarding:

 

  1. The StrongDM Control Plane can be used as a secret store for resource credentials
  2. Alternatively, an external secret store can be used for scenarios where an organization would like to keep the credentials within their own network boundaries and independent/out-of-reach from StrongDM-managed infrastructure. Examples of secrets stores supported: 
    1. AWS Secrets Manager 
    2. Hashicorp Vault
    3. Azure Keyvault
    4. CyberArk Conjur
    5. CyberArk PAM
    6. Delinea

 

Example use cases:

  • A healthcare organization stores non-sensitive resource credentials with StrongDM, but chooses to use AWS Secrets Manager for RDS instances that contain PHI/PII both to reduce attack surface and take advantage of AWS-native credential rotation
  • A customer stores all resource secrets in Hashicorp Vault
  • A multi-cloud organization uses their respective cloud provider secrets store to keep all credentials in their environment

 

 

Session Logging to SIEM and/or Archive Locations

Organizations have the option to store their logs in the following configurations: 

 

  1. Stored in StrongDM-managed infrastructure with a retention of 13 months
    1. These logs can be encrypted by StrongDM, or alternatively encrypted via a user-held encryption key that StrongDM would not have access to
  2. Log solely locally to Gateways/Relays where logs can be shipped to a customer-held archive location and/or SIEM
  3. Both stored with StrongDM and logged locally to Gateways/Relays 

 

Local logging format options are configurable, and detailed here. 

 

Example use cases:

  • When session logs are considered confidential, and must only be stored in a customer-held location, so an organization chooses to log locally only, and opts out of storage with StrongDM
  • An organization takes advantage of StrongDM’s included 13 months by storing with StrongDM, but also logs locally to send a subset of logs to their SIEM to trigger workflows based on activity 
  • For redundancy, an organization logs both to StrongDM and locally, but encrypts all logs to satisfy compliance requirements specific to their business vertical
Powered by Zendesk