Best Practices for Global Device Management with Forum Sentry
Article Outline:
I. GDM Overview
II. Full GDM Transfers
III. Partial GDM Transfers
IV. Recommendations on Policy Naming Conventions
V. Using Hostnames with Partial GDM Transfers
VI. Considerations for HSM Configurations
I. GDM Overview
Global Device Management (GDM) is the method of administration where one Policy Server machine (Master) holds the policies used in your business processes. This system has the ability to mirror policy configuration (.fsx files) from the Policy Server machine to any number of managed Agent machines. Additionally, all Agents retain the ability to customize their own system to their specific IPs and ports. Any and all Agents can also be used as a secondary Master to push their policies to one another.
In short, GDM allows an administrator the ability to manage all of the policies on all deployed instances of Sentry from a central instance.
A typically deployment will have a single Master instance of Sentry which is considered either a DEV, QA, or UAT instance of Sentry (an instance not handling production traffic) where the policies are built, tested, and then transferred to Agent instances in the same or in different data centers.
If the different environments (Dev, QA, UAT, Production) are completely segmented, it is possible to have a Master instance with its own agents in each environment.
There are two types of GDM transfers: Full and Partial. There is also the ability to manually export a configuration (.FSX) from one Sentry instance and then import it into another Sentry instance. The GDM / Agent architecture is meant as an easier alternative to the manual exporting/importing of full configuration files.
For full details on the GDM functionality, including how to configure the Agents and transfer configurations, please review the attached System Management Guide.
II. Full GDM Transfers
Full GDM transfers push the full configuration (all policies, keys, etc..) from the source instance (MASTER) to an agent. As any Agent can also be used as a Master to transfer configurations, it is therefore possible to transfer configurations from any Sentry instance to another.
Full GDM transfers push everything, but there are options to overwrite certain settings, such as listener and remote IP addresses and various system settings.
III. Partial GDM Transfers
A partial transfer pushes selected individual (or multiple) WSDL or XML policies, with all dependencies (keys, tasks, etc), from one Sentry instance to another (Master to Agent). The dependencies are all policies that are associated to the WSDL or XML Policy and they include:
- The network listener and remote policies
- Associated Task Lists
- Associated Task List Groups
- Associated Keys
- Associated SSL Policies
- Associated XML Encryption / Decryption / Signature / Verification Policies
- Etc.
The transfer will either add or update existing policies residing on the target system. Updates occur when the same name policy exists on the target system. However, if there is a policy residing on the target system that is using the same IP and port - but is named differently - the transfer will fail.
* Note that if you are transferring more than one policy at a time, if there are any errors the entire transfer will fail and the previous configuration will remain intact.
IV. Naming Conventions
We recommend using clear and concise naming conventions for all aspects of the Sentry policies including:
- HTTP Listener and Remote Policies
- WSDL Policies
- XML Policies
- Task Lists
- Task List Groups
- Keys
- SSL Policies
- XML Encryption / Decryption / Signature / Verification Policies
When using GDM, the policy names will be the same on each instance of Sentry. For instance, when you transfer a WSDL Policy named “WSDL Policy 1” from one instance into another, the name of the WSDL policy on both instances is now “WSDL Policy 1”. In addition, the names of all dependencies (listener, tasks, keys, etc.) will also be the same. For this reason, it is not important to use location names or IP addresses (both of which might change with different Sentry instances) in the names of the policies. Rather, we recommend using a name that appropriately describes the service and the version of the service.
* Note that when using the GDM transfer feature, there are certain policies you can build in Sentry that can be renamed after initially created. Tasks Lists, for example, can be renamed while WSDL Policies cannot.
What's important to remember is that Sentry stores the initial policy name internally as an object. If you later change the name of the policy in the GUI, this change will not modify the name of the object, it will only change the alias name that is shown in the WebAdmin interface. Therefore, when using the GDM transfer feature, be aware that changing the policy names (when possible) in the WebAdmin after they've been created might lead to policies being overwritten inadvertently.
For instance, if you create a Task List named TaskList1 and later rename it to TaskList2, Sentry still refers to this policy as TaskList1. So, if you later transfer (or import) a WSDL or XML policy into the system that is associated with a task list named TaskList1, the import will happen and it will overwrite the existing policy that shows as TaskList2 in the GUI on the target system before the transfer.
For this reason we strongly recommend you do a full configuration backup on each system periodically and/or before doing any transfers. The backup can be made using the export option on the Configuration>>Import/Export page of the WebAdmin. This is a complete backup of the configuration and can be reloaded onto the system if you find any problems after the transfer.
* Alternatively, we also recommend configuring daily backups on each Sentry instance, so that you'll always have a current configuration stored for safe keeping. For more information on the automated configuration back-up routine please see: https://forumsystems.zendesk.com/entries/122511-how-to-guides-backi....
V. Using Hostnames to Override Remote Server Locations with Partial GDM Transfers
When using partial GDM transfers the remote endpoint IP address might change with each different environment. For instance, “WSDL Policy 1” might use a remote server of 10.1.2.3 in the UAT environment but in production it uses 11.12.13.14.
VI. Considerations for HSM Configurations
With the Sentry HSM appliances (xx64 models), the keys are stored in FIPS 140-2 Level III encrypted format and can only be decrypted by HSM modules tied to the Security World. When a configuration is associated to a Security World, it can only be transferred into another Sentry instance that resides in the same Security World. This is applicable to both full and partial GDM transfers.
It is possible to transfer a full or partial configuration that is not associated to any Security World into a Sentry instance that is associated to a Security World. However, the reverse is not possible – you cannot transfer a full or partial configuration from a Sentry instance in a Security World to another Sentry instance not in the same Security World. Once the import has been completed into a device with a security world, it becomes formatted and encrypted exclusively for that device, or other devices within the security world.
A common deployment option is to have development instances of Sentry running on non HSM appliances or as software instances (Windows, Linux, Solaris) while the production Sentry instances are HSM appliances. In this case, it is possible to build the policies in the development (non-HSM) instance and then transfer them into the production HSM instances.
0 Comments