Deploying nShield Monitor
Centralized monitoring
When monitoring an estate of HSMs, it is recommended to keep all the data in as few instances as possible. This may be subject to external requirements such as network connectivity, regulatory control or other issues.
The best case scenarios are a single nShield Monitor instance that poll all HSMs in an estate. This provides a complete set of statistics for all HSMs in the estate from a single login. This is based on access rights and role/roles assigned within the nShield Monitor server.
Single instance monitoring
By collecting statistics in a single window it allows views of all groups of HSMs including events and alerts from a single browser when logged in as Administrator.
This configuration allows historical reporting for any and all HSMs in the estate as needed, again based on assigned rights or roles.
There may be additional requirements when monitoring must be continuous. For example, more than one instance of a central nShield Monitor virtual appliance is required in order to ensure monitoring is continuous and non-stop.
nShield Monitor multi-instance
A single nShield Monitor virtual appliance is all that is required to monitor an HSM estate. However, it is possible to utilize multiple nShield Monitor virtual appliances simultaneously as insurance in case of an outage. By distributing nShield Monitor virtual appliances across multiple locations, polling is maintained to all devices in the event of a network outage, other than to a single site. It is possible to ensure that, even during a single location network failure, only a minimal number of devices will be unmonitored until the issue is resolved.
Distributed monitoring
There are cases where multiple monitors are required due. For example:
-
Network connectivity via firewalls
-
Potential regulatory compliance requirements
-
Scenarios where one or more central nShield Monitor virtual appliances cannot poll specific HSM devices.
Multiple nShield Monitor instances
In this case, multiple regional or local nShield Monitor instances may be required in order to provide coverage and continuous monitoring of HSM estates.
Even in this case, central distribution of alerts using SIEM or email services is recommended. This enables a proactive notifications can be sent to the appropriate person or persons responsible for a given nShield Monitor or specific group of devices.
Deployment considerations
When looking into how to deploy nShield Monitor, there are some specific items that need to be considered prior to implementation.
User access requirements
nShield Monitor has included provisions to address user access requirements by providing the ability to limit which portions of HSM estates any given user can view. This is done by only assigning a specific group or portion of the total configured groups to a user with the group manager role assigned. These requirements may affect both centralized and distributed configurations. A thorough examination of the environment in question will need to be performed prior to implementing nShield Monitor.
There may also be regional requirements for monitoring encryption devices. These may require regional or local users to be the only authorized persons to access specific portions of the estate due to geographic location.
Network connectivity
Multiple instances of nShield Monitor may be required on a per region or location basis. This is mainly due to firewalling or other forms of limited network access to the local HSM estates. In this case, individual nShield Monitor systems will have to be configured individually to achieve full coverage and notification of failures per region or location.
Regulatory compliance requirements
nShield Monitor does not have any regulatory impact or requirements around it at this time. However, due to potential regional requirements for the HSM estates. For example, you may be required to have individual nShield Monitor servers deployed regionally in order to access the management ports of the HSMs to be monitored.
A distributed model of nShield Monitor can still provide the ability to distribute proactive alerts and event information to centralized tools. This can be based on configuration at the virtual appliance or HSM group level.