Hight Availability and Read-Only Replica

Securden Unified PAM acts as the secure gateway for users and IT administrators to access sensitive assets like servers, VMs and important credentials such as passwords, SSH keys, DevOps secrets and certificates. Reliable, uninterrupted access to these passwords and privileged accounts is critical for business continuity.

If the PAM server goes down, it could potentially hinder critical business operations. Securden comes with provisions to handle unexpected situations and ensure continuous availability to the database.

High availability refers to the number of possible failovers, reaching for the maximum amount of uptime.

How High Availability is Generally Configured

Generally, PAM is installed on a primary server with one or more secondary servers. This ensures that in emergencies such as heavy traffic spikes, server outage, network issues, network latency, etc. users will be automatically connected to another available secondary server.

The failover mechanism ensures continuous uptime and ready access to privileged credentials and accounts.

Encryption Key - Security and Location

The encryption key associated with the primary server is of very high importance. The best way to safeguard the key is to store it in a network location that is not on primary or secondary(in a separate machine) and use a service account to access the location for read or write and use the service account to run the Securden service so that only Securden has access to that location and even if the servers where Securden is installed is compromised, the key isn't available in that server.

You can alternatively store it in a secure location such as a mounted physical Hardware Security Module (HSM).

When secondary server is created and added to Securden; the key of the primary server is replicated to the secondary PAM server.

High Availability & Read-Only Architecture

The following architecture diagram provides an outline of the major components that are part of a highly available PAM setup.

High Availability – Primary and Secondary Servers

High Availability allows the configuration of multiple PAM Servers to work as a highly available pair, with one server being the active server and the other server(s) in a standby state.

The first PAM Server is deployed as the Primary and becomes the active server. The Primary is used to configure the HA Pair and will receive all user traffic as the active server.

The second PAM Server is deployed as the Secondary and will become the standby server. The standby server will receive encrypted database replication from the active server so it is ready to take over if the active server should fail.

The HA setup in Securden consists of two layers. The Application Layer and the Database Layer. The application layer has the application servers, and the database layer has a master server (active) and multiple slave servers (standby).

Server Failover - When Primary & Secondary Server are Configured

Only one of the slave servers can be made as the master server in the event of a failover. All other slave servers work only as read-only servers. The write operations are redirected to the master.

The replication of data between the Primary and Secondary servers is ASYNCHRONOUS. As streaming replication is used for PostgreSQL, the synchronization is instantaneous which ensures that data commited on the primary server has a minimal to zero chance of being lost in case of failure.

Read-only Replica Server

The read-only replica server helps users access Securden when the primary server is down. The replica server, however, only allows users to perform ‘READ’ operations. This prevents them from modifying data. Based on your requirements, any number of Read-Only servers can be set up in various locations.

All activities performed on the Read-Only server are fully audited and propagated to the Primary server. The replication of data between the Primary and Read-Only servers is SYNCHRONOUS.

Server Failover - When Primary & Read-Only Server are Configured

In case the primary goes down and the read-only server takes over, users would be able to carry out all read operations until the primary/secondary servers are active. Once the primary/secondary is active, the read-only server automatically connects to it.

The read-only server allows all read applications, the operations that would not work are listed out below:

• (If JIT Workflows are Enabled) Time-Limited, Exclusive Password Access: In read-only mode, users can request access to passwords for certain accounts mapped to them by the administrator for 30 minutes. During this period, no other users can access the password.

• No Automatic Password Reset: In read-only mode, passwords will not be reset after the time-limited access expires.

• Session Recording Disabled: Session recording is not available in read-only mode. This includes all session types supported in Securden including RDP, SSH, SQL, and more.

• Audit Trail Syncing: Audit trails will not be updated in real-time in read-only mode. Instead, they will be stored separately on the read-only server and synchronized once the primary server is restored. The records will then appear in the respective tab with accurate timestamps.

• Emergency Access Availability: The emergency access feature is not functional in read-only mode.

Logging into Securden from read-only server: When the primary server goes down, the read-only replica server requires users to login afresh, and access the data that was last synchronized.

Using Read-Only Servers for Performance Optimization

Removing reporting query load from the primary server improves both reporting query time and transaction processing performance.

You can utilize the read-only replica server for handling user requests that mostly involve read operations.

If users directly connect to the read-only's server FQDN, write requests are directed to primary and read requests to the read-only. This might slow down all write requests and there might be a delay in seeing the newly added assets on the read-only server.

Diversified Geographical Locations

You have the option to deploy multiple application servers, which help in handling privileged account management for a distributed network or distributed data center environments from a central installation.

Secondary application servers could be distributed geographically, supporting organizations and service providers with multi-tenant networks.

Read-only servers help only with handling password retrieval and taking remote connections in distributed networks.

Note

Each HA instance must run the same version of Securden Unified PAM. This means that you need to update PAM on all secondary servers if you carry out an upgrade on the primary server.