In general, Hitachi ID Privileged Access Manager should always be deployed with at least two servers, situated in at least two different locations. This minimizes the probability that all Privileged Access Manager servers are concurrently offline, due to simultaneous hardware failures or simultaneous site disasters.
This arrangement still leaves open the possibility that Privileged Access Manager is unreachable by some users due to failure of a single Privileged Access Manager server or of connectivity to a single Privileged Access Manager site. In fact, multiple modes of failure should be considered, as illustrated in Figure [link].
In the figure, there are several possible situations:
Once it has been established that work is possible, the next question is whether a privileged account is accessible:
In short, so long as the user is able to connect to the system he wishes to manage and so long as at least one Privileged Access Manager server is functional somewhere on the network (reachable or not), the user should be able to retrieve passwords -- directly or by asking for assistance from another user with better connectivity.
Access controls and approval workflows in Privileged Access Manager can be configured for "break glass" scenarios. Hitachi ID Systems customer must define who can request such access, who must approve it, for what systems, etc. Clearly, these are Hitachi ID Systems customer-specific policy decisions, rather than generic product features.
For example, in an all-out-emergency scenario, Hitachi ID Systems customer may set a flag on the system indicating that no approvals are required for any check-out. When this is done, all requests will be auto-approved (but still audited). This is an extreme example of what's possible -- not a recommendation by Hitachi ID Systems.
Hitachi ID Systems customers often ask whether Privileged Access Manager supports access to privileged accounts in a "break glass" scenario -- i.e., during an emergency. While the short answer is simply "yes," a more clear understanding of how this is done must begin with a classification of the different types of emergencies (disasters) that might arise and how best to respond to each one.
The term "break glass" is ambiguous, as it does not specify what part of the infrastructure was damaged, so it shall not be used in the following description.
The basic disaster scenarios depend on what part of an organization's infrastructure was damaged, as follows:
Hitachi ID Systems strongly urges customers to deploy Privileged Access Manager in a multi-master, geographically distributed configuration. This means that there should always be at least two active Privileged Access Manager nodes, installed in at least two data centers, with a maximum physical distance separating them.
How organizations respond to each scenario using Privileged Access Manager is described below:
As can be seen above, it would take something like a global-scale disaster to cause service interruption to Privileged Access Manager, due to its geographically distributed architecture, real-time and fault-tolerant data replication and multi-master operation. Not impossible, but also not likely.
A more practical consideration is whether access controls should be relaxed in the context of a disaster which incapacitates one or more data centers. For example, workflow approvals might be required under normal circumstances, to checkout access to some privileged accounts. Moreover, access to a directory might be required when users sign into Privileged Access Manager.
To expedite access to privileged accounts during an emergency, a handful of local login IDs can be defined on the Privileged Access Manager logical instance, with unrestricted access to some or all privileged accounts. In an emergency, these accounts may be enabled and their passwords distributed to the recovery team. This reduces "red tape" (and lowers security) and eliminates the dependency on an external directory.