In a central management configuration, one Guardium unit is designated as the Central Manager. That unit can be used to monitor and control other Guardium units, which are referred to as managed units. Unmanaged units are referred to as standalone units.
The concept of a "local machine" can refer to any machine in the Central Management system. There are some applications (Audit Processes, Queries, Portlets, etc.) which can be run on both the Managed Units and the Central Manager. In both cases, the definitions come from the Central Manager and the data comes from the local machine (which could also be the Central Manager).
Once a Central Management system is set up, customers can use either the Central Manager or a Managed Unit to create or modify most definitions. Keep in mind that most of the definitions reside on the Central Manager, regardless of which machine the actual editing is done from.
Note: Using the ’Remote Source’ functionality, A user on the Manager can execute any report on the managed unit (as long as he has the right Role privileges) and view date and information of that managed unit.
Central Manager controls the definition of users, roles, and groups for all managed systems by exporting the Central Manager’s complete set of user, security role, and group definitions on a scheduled basis or on demand. The managed units update their internal databases on an hourly basis, which means that there may be a delay of up to an hour between the time that a managed unit receives updates and the time that the managed unit applies those updates. New users must log onto the Central Manager before logging onto a managed unit.
Notes: If you have Guardium users or security roles defined on an existing standalone unit that is about to be registered for central management, those definitions will not be available after the system is registered, unless those users and security roles have also been defined on the Central Manager. You cannot administer users or security roles on a managed unit. Those definitions can only be administered when logged on to the Central Manager. When a unit is unregistered for central management, the users and security roles that were backed up when the unit was registered are restored. When installing an Accelerator add-in product (PCI, SOX, etc.), in a Central Manager environment, install it first on the Central Manager and then on the managed unit. Add any roles and users as required for the Accelerator on the Central Manager (and those will be synchronized with the managed unit from there). See your Accelerator documentation for more information.
On all processes that automatically generate aliases or groups, for example: import user groups from LDAP, group generation from queries, alias generation from queries, classifier, etc. if the same group or alias is automatically generated on more than one managed machine, (managed by the same manager) then it may conflict with an existing group or alias, which will not be replaced.
The definitions of the Audit Process itself and all of its corresponding tasks are saved to the Central Manager and available to all managed units. However, Schedules, Results, and To-Do lists are saved on the local machine. This means that the same Audit Process tasks can be run on all Managed Units, plus the Central Manager. But it can be run at different times on different machines, which can be useful if the Managed Units have different peak load periods. Each machine will have its own set of results, based on the data that the machine has collected; and each machine will have its own set of To-Do lists for all users. Audit Process definitions are exported from the Central Manager to the managed units as part of the user synchronization process (see Synchronizing Portal User Accounts). When audit process results have been produced, the results will be available to users, but on managed units, there may be a delay of up to an hour before reports or monitors such as Outstanding Audit Process Reviews are updated.
Each query can only get database information from a single machine. Queries that requires access information including both Central Manager definitions and Managed Unit data will show no data, or missing data.
Policy definitions are saved on the Central Manager. However, when you install a policy on a Managed Unit, a local copy is made and saved on the Managed Unit. The reason for that is that we need the Managed Unit to keep on monitoring the database activity and using the policy even when the management unit is not available for any reason.
Report definitions are saved on the Central Manager. However, the Portlet is generated on the local machine. This means that the Portlet must be regenerated on every machine on which you wish to view it. From the Central Manager, reports and audit processes can use data from a managed unit. The managed unit is selected as a run-time parameter, and is referred to as a remote datasource. When an audit process references a remote datasource, that audit process can be run from the Central Manager only, so it will not appear in a list of audit processes displayed on a managed unit.
If a report on a pane of the Central Manager portal contains data from a remote datasource, and the managed unit becomes unavailable (due to a network outage, for example), the pane on which the report resides cannot be refreshed, which means that other reports on the same pane may not be displayed, even though data for those reports may be available. For this reason, when using remote datasources for a report, it is best to use a menu layout, with one report per menu entry, so that the unavailability of one remote source does not prevent any other reports from being displayed.
Like the Audit Process, the definition of the Security Assessment itself is saved to the Central Manager. But the results are saved on the local machine. This means that the same Security Assessment can be run on all Managed Units, plus the Central Manager.
Baselines are always saved on the Central Manager. However, baselines are GENERATED using the logged data that is local to the machine on which it is generated. Therefore, if you want to include constructs from all Managed Units, you must regenerate the baseline on ALL Managed Units and merge the new results into the existing baseline.
Comments can be saved on either the local machine or the Central Manager, depending on what the comment is associated with. If the Comment is associated with a definition that resides on the Central Manager, then it is also saved on the Central Manager. If the Comment is associated with a Result on the local machine, OR something specific to a Managed Unit (like an Inspection Engine), the Comment is also saved on the local machine.
Schedules are always saved on the local machine, even when the definition is saved on the Central Manager.
When a server is configured as a Central Manager, you must be aware of the tasks that cannot be performed on that unit, but rather must be performed on other (non-Central Manager) units. This includes the following:
Inspection engines cannot be defined on the Central Manager and can only be created on the Managed Units. But Inspection engines can be viewed from the Central Manager.
Load Balancing cannot be performed from the Central Manager.
It is recommended to have your Central Manager and managed units on the same version. The Central Manager should be upgraded first and then the managed units should follow. Having a manager in a different version than its managed units should be a temporary thing and it’s highly recommended to upgrade all managed units to the same version as the manager
The following table can help identify which components are taken from which location in a central management environment.
Guarium Component Sources
|
Central Manager |
Managed Unit |
|
Users* |
System Configuration |
|
Security Roles* |
Inspection Engines |
|
Application Role Permissions |
Alerter (configuration) |
|
Queries |
Anomaly Detection |
|
Reports |
Session Inference |
|
Time Periods |
IP-to-Hostname Aliasing |
|
Alerts |
System Backup |
|
Security Assessments |
Aggregation / Archiving |
|
Audit Processes* (definitions) |
Custom Assessment Tests |
|
Audit Process Results* |
Custom Alerting |
|
To-Do Lists* |
Custom Identification Procedures |
|
Privacy Sets |
Exported SCV Output |
|
Baselines |
Schedules |
|
Policies |
DB Auto-discovery Configurations |
|
Groups* |
|
|
Aliases |
|
* These elements are exported from the Central Manager to all managed units on a scheduled basis, as described later.
From the Central Manager, the administrator can:
Register Guardium units for management
Monitor managed units (unit availability, inspection engine status, etc.)
View system log files (syslogs) of managed units
View reports using data on managed units
View main statistics for managed units
Install Guardium security policies on managed units
Restart managed units
Manage Guardium inspection engines on managed units
Maintain the complete set of Users, Security Roles, Groups, and Application Role Permissions used on all managed systems
Note: Application Role Permissions can also be changed by the administrator from any managed unit. When this happens, the permissions are changed for all managed units.
In a new Guardium installation, implementing central management is a straight-forward process. In an existing Guardium environment, conversion to central management can be more complicated if you want to preserve components (reports, policies, etc.) that have been defined on standalone units. The following sections provide general guidelines for implementing central management in both situations.
The first thing you need to do is make one machine into a Central Manager. Select a machine, then do the following:
Log into the cli of the Machine that you want to make the Central Manager.
Enter "store unit type manager". This makes the machine a Central Manager; however, it is not yet managing anything.
Once you have a Central Manager, you must connect the other machines into a Central Management system. For security reasons, it is a requirement that the communication between the machines be encrypted using the same "shared secret". To do this, do the following:
For each machine (including the Central Manager), log into the Guardium GUI as the admin user
Click on the Administrator Console tab
Click on the System link in the left hand column menu
Set the Shared Secret to the same string on all systems
Finally, you must register the Managed Units to communicate with the Central Manager. You can register Guardium units for central management either from the Central Manager or from the unit itself. Regardless of how the registration is done, the Central Manager and all managed units must have the same System Shared Secret. If the unit to be managed is already registered for central management with another manager, un-register that unit from that manager before registering it with the new manager. Be sure to understand exactly what happens to that unit when it is registered and unregistered for central management (see below).
When you register a unit for central management, the system makes a pre-registration backup of the registered unit’s configuration. The backup includes all definition data on that machine: queries, reports, users, etc. - everything except actual logging data. While registered and under central management, local definitions of users and roles are used to control access, but these definitions cannot be modified while logged on to the managed unit. All other definitions and components are taken directly from the Central Manager, except for custom assessment tests, custom alerting classes, and custom identification procedures, as noted previously. If a security policy is installed on the managed unit, it is stored in the Guardium database on that unit, but the definition of that security policy is not available, except on the Central Manager.
When you unregister a unit from central management, the unregister process restores the configuration for that unit from the pre-registration backup. This means that any changes made to the configuration of this unit from the Central Manager (the definition of new users or the installation of a security policy, for example) will be overwritten by the preregistration configuration during the unregister process. Caution: When unregistering a unit, if the pre-registration backup was created under a previous release of the Guardium software, restoring that configuration without first applying a patch to bring it to the current software release level will disable the unit, potentially causing the loss of all data stored there. Accordingly, do not unregister a unit until you have verified that the preregistration configuration is at the current software release level.
If you are unsure about how to verify this, contact Guardium Support before unregistering the unit.
To register a unit for central management from the Central Manager, follow the procedure outlined below. The unit to be managed does not have to be online when it is registered (see the last step of the procedure for more information), but as mentioned earlier it must have the same System Shared Secret as the Central Manager.
Log into the Guardium GUI of the Central Manager as the admin user
Click on the Administrator Console tab
Click on the Central Management link under Central Management in the left hand column menu
Click on the Register New... button to open the Unit Registration panel
For Unit IP, enter the IP address of the Machine that you want to manage. If the unit you specify is already managed by another Central Manager, you will get an error message and the registration will fail. (You can unregister that unit from the other Central Manager, or directly from that unit.)
For Port, fill in the https port for the Machine that you want to manage (usually 8443).
Click Save.
Once you have registered on the Central Manager, it initiates communication with the Managed Unit, and nothing more needs to be done.
If you know the unit just registered is online and accessible from the Central Manager, but its status in the Central Management panel remains offline:
Verify that the unit to be managed is online, accessible, and operational by using a browser window to log in to the Guardium system on that unit.
In the Central Management panel, click the refresh button for the unit:
Check that you have entered the correct IP address for the unit.
Check that the unit has the same shared secret as the Central Manager.
Log into the Guardium GUI of the unit to be managed as the admin user
Click on the Administrator Console tab
Click on the Central Management link under Central Management in the left hand column menu
Mark the checkbox for the managed unit you want to unregister
Click Unregister
Unregistering from the Central Manager does NOT unregister the unit on the Managed Unit - the Managed Unit still thinks it is registered. The Unregister functionality on the Central Manager is included for emergency use ONLY. If a Managed Unit has been trashed and is no longer in service, then you must remove the record from the Central Manager only.
You can register a unit either from the Central Manager or the managed unit. On a managed unit, you can also use the CLI register command to register the unit (see register / unregister commands in Chapter 6).
Log into the Guardium GUI of the unit to be managed as the admin user
Click on the Administrator Console tab
Click on the Central Mgmt/Registration link under Central Management in the left hand column menu
For Central Management Host IP, enter the IP address of the Central Manager.
For Port, fill in the https port for the Central Manager (usually 8443).
Click the Register button.
Once you have registered on the Managed Unit, it initiates communication with the Central Manager, and nothing more needs to be done.
Note: The central management unit must be online and accessible by this unit when you register for central management. In contrast, when you register units for management from the central management unit, you can register units that are not currently accessible.
When a unit is unregistered, you should always perform that function from the Central Manager. This is the only way that the Central Manager decrements its count of managed units. You can unregister from the managed unit, but this capability is provided for emergency use only, for example if the Central Manager becomes unavailable. If you unregister only from the managed unit, the Central Manager will still count that unit as a managed unit for licensing purposes, and you may not be able to register another unit with the Central Manager.
Log into the Guardium GUI of the unit to be managed as the admin user
Click on the Administrator Console tab
Click on the Central Mgmt/Registration link under Central Management in the left hand column menu
Click Unregister.
Once you have unregistered from the Managed Unit, it severs communication with the Central Manager, and nothing more needs to be done.
On the Managed Unit, log into the cli
Type "register management <Manager IP> <Manager Port>".
Once you have registered on the Managed Unit, it initiates communication with the Central Manager, and nothing more needs to be done.
On the Managed Unit, log into the cli
Type "unregister management".
Once you have unregistered from the Managed Unit, it severs communication with the Central Manager, and nothing more needs to be done.
In an existing Guardium environment, refer to the procedure outlined below to develop a plan for implementing central management. If you are converting an existing Guardium unit to a Central Manager, keep in mind that a Central Manager can not monitor network traffic (i.e., inspection engines cannot be defined on a Central Manager).
Select a System Shared Secret to be used by the Central Manager and all managed units. See the System Configuration Panel Reference for more information about the System Shared Secret.
Install the Central Manager unit or designate one of the existing systems as the Central Manager. In either case, use the store unit type command to set the manager attribute for the Central Manager.
Any definitions from the standalone unit that you want to have available in the central management environment will have to be exported before the standalone unit is registered for management. Later, those definitions will be imported on the Central Manager. BEFORE exporting or importing any definitions, follow the procedure outlined below for each standalone unit that is to become a managed unit, and read through the introductory information under Exporting and Importing Definitions.
Decide which users, security roles, queries, reports, groups, time periods, alerts, security assessments, audit processes, privacy sets, baselines, policies, and aliases from the standalone system you want to have available after the system becomes a managed unit. For the remainder of this discussion, ignore any components on the standalone system you do not want to have available.
Compare the security roles and groups defined on the standalone unit with those defined on the Central Manager. Under central management, a single version of these definitions applies to all units.
If a security role with the same name exists on both systems and it is used for different purposes, add a new role on the Central Manager and assign the new role to the appropriate definitions after they are imported.
If the same group name exists on the standalone unit and the Central Manager but it has different members, create a new duplicate group on the standalone system, taking care to select a group name that does not exist on the Central Manager. In all of the definitions to be exported, change the old group name references to new group name references.
Note all security roles assigned to all definitions that will be exported from the standalone system. When definitions are imported, they are imported WITHOUT roles, so you have to add them manually.
Check the application role permissions on each system. If any security roles assigned to an application on the standalone unit are missing from the Central Manager, add them to the Central Manager.
Export all queries, reports, groups, time periods, alerts, security assessments, audit processes, privacy sets, baselines, policies, and aliases from the standalone system that you want to have available after the system becomes a managed unit. (See Exporting and Importing Definitions, later in this chapter.) Do not export users or security roles. If you are unsure about a definition, export it in a separate export operation so that you can decide later whether or not to import that definition to the Central Manager. Once you register for central management, none of the old definitions from the standalone unit are available.
On the standalone unit, if there are any audit process results that you want to view in the future, create PDF versions of those results and store them in an appropriate location. Under central management, only the audit results produced under central management are available.
On the standalone unit, instruct all users to remove all portlets containing custom report, and to not create any new reports until the conversion to central management is complete.
On the Central Manager, manually add all users from the standalone unit.
On the standalone unit, delete all user definitions except for the admin user (which cannot be deleted).
Register the standalone unit for central management. See Registering Units for Central Management, below.
On the Central Manager, import all definitions exported from the standalone system. Check to make sure that references to included items (receivers in alert notifications, for example) are correct.
Re-assign security roles, as necessary, to all imported definitions.
Inform users of the managed unit that they must use the Report Builder application to re-generate the portlets for any custom reports they want to display in their layouts.
If the Central Manager is unavailable to a managed unit (due to a network or system failure, for example), a message is displayed prominently in the Guardium management interface window when you log into the managed unit. You will be able to perform a very limited number of functions on that system, since most functions rely on the internal database stored on the Central Manager.
The Central Manager license limits the number of units that can be managed. If you attempt to register more units than are permitted, the operation will not be allowed. When a unit is unregistered, you should always perform that function from the Central Manager. This is the only way that the Central Manager reduces its count of managed units. You can unregister from the managed unit, but that capability is intended for emergency use only (for example, if the Central Manager becomes unavailable). If you unregister only from the managed unit, the Central Manager will still count that unit as a managed unit for licensing purposes, and you may not be able to register another unit with the Central Manager.
As mentioned earlier, the Central Manager controls the definition of Users, Security Roles, and Groups for all managed units. It does this by making an encrypted and signed copy of its complete set User, Security Role, and Group definitions, and transmitting that information to all managed units. The managed units then update their internal databases on an hourly basis, which means that there may be a delay of up to an hour between the time that the managed unit receives updates and the time that the managed unit applies those updates.
To manage portal user synchronization:
Log into the Guardium GUI of the Central Manager as the admin user
Click on the Administrator Console tab
Click on the Portal User Sync link under Central Management in the left hand column menu
Do one of the following:
Click Modify Schedule to change the user synchronization task schedule using the standard task scheduler.
If the task is actively scheduled, click Pause to stop further scheduled executions.
If the task is paused, click Resume to start running the task again (according to the defined schedule).
Click Run Once Now to run the synchronization task immediately.
Note: The task being scheduled or ”r;run once now” refers to the collection of data and its transmission to the managed units only - the managed units may not use that data to update their user tables until up to one hour after it has been received.
To monitor managed units:
Log into the Guardium GUI of the unit to be managed as the admin user
Click on the Administrator Console tab
Click on the Central Management link under Central Management in the left hand column menu to open the Central Management panel.
Each component of the Central Management panel is described in the table below.
|
Control |
Description | ||||||||||||||
|
Check box |
Mark this box to select the unit for an unregister or policy installation operation. | ||||||||||||||
|
Refresh Unit Info |
Refreshes all information displayed in the expanded view of that unit by issuing new requests to that unit. | ||||||||||||||
|
Reboot Unit |
Reboots the unit at the operating system level. By default, the Guardium portal is started at startup. | ||||||||||||||
|
Restart Unit Portal |
Restarts the Guardium application portal on the managed unit. You can then log into that unit to perform Guardium tasks that must be performed on that unit (defining or removing inspection engines, for example). | ||||||||||||||
|
View Unit SNMP Attributes |
Opens the SNMP Viewer panel in a separate window. Clicking the refresh icon in the lower left corer of the SNMP Viewer panel will refresh the data in the window. | ||||||||||||||
|
View Unit Syslog |
Opens the Syslog Viewer in a separate window, displaying the last 64KB of syslog messages. Clicking the refresh icon in the lower left corer of the SNMP Viewer panel will refresh the data in the window. | ||||||||||||||
|
Shortcut to Unit Portal |
Opens the Guarium login page for the managed unit, in a separate browser window. | ||||||||||||||
|
Unit Name |
The host name of the managed unit. If you hold the mouse pointer over the unit name, its IP address displays as a tool tip. If the hostname changes on the unit, the Central Manager will no longer see that unit when automatically refreshing the Online status. If you suspect the hostname has changed, use the Refresh button on the toolbar to obtain the changed hostname and update the displayed current Online status and other information for that unit. | ||||||||||||||
|
Online |
Indicates whether or not hteunit is online. If the green indicator is lit, the unit is online; if the red indicator is lit, the unit is offline. The Central Manager refreshes this status at the refresh interval specified in the central management configuration (one minute by default). If an error occurred connecting to a unit, the error description can be viewed as a tool tip when you hover the mouse indicator over that unit's record in the management table. | ||||||||||||||
|
Inspection Engines |
Click the 'plus' button to expand the list of inspection engines; click the 'minus' button to hide the list of inspection engines. The information displayed for each inspection engine is as follows (This information is fetched from the managed unit when the Refresh button is pressed, not on every ping):
| ||||||||||||||
|
Installed Security Policy |
The name of the security policy installed on the managed unit. This field is updated on every ping | ||||||||||||||
|
SqlGuard Model |
The Guardium model number of the managed unit | ||||||||||||||
|
SqlGuard Version |
The Guardium version number of the managed unit | ||||||||||||||
|
Last Ping Time |
The last time that the unit was pinged by the Central Manager to determine the managed unit's online/offline status | ||||||||||||||
|
Select All |
Selects all managed units | ||||||||||||||
|
Unselect All |
Unselects all managed units | ||||||||||||||
|
Unregister |
Unregister all selected units. | ||||||||||||||
|
Install Policy |
Opens the Install Security Policy panel, to install a security policy on all selected units | ||||||||||||||
|
Back |
Closes the panel and returns to the Administrator Console | ||||||||||||||
|
Register Now |
Opens the Unit Registration panel to register a new unit for management | ||||||||||||||
|
Show Distributed Map |
Displays a map of the Central Manager unit and all managed units | ||||||||||||||
|
Distributed Monitor |
Opens the Distributed Monitoring of Managed Nodes report in a separate window | ||||||||||||||
|
Done |
Closes the panel and returns to the Administrator Console |
To install a security policy on a managed unit:
Log into the Guardium GUI of the unit to be managed as the admin user
Click on the Administrator Console tab
Click on the Central Management link under Central Management in the left hand column menu to open the Install Security Policy panel.
Select each unit on which you want to install the same security policy. To select a unit, mark the checkbox in the first column of the row for that unit.
Click the Install Policy button to open the Install Security Policy panel.
From the Policy list, select the policy you want to install.
Click the Install Policy button. You will be informed of the success (or failure) of each policy installation. If a selected unit is not available (it may be offline or a link may be down), the Central Manager will inform you of that fact. It will continue attempting to install the new policy for a maximum of seven days (as long as that unit remains registered for central management).
To view management maps, you need the Adobe SVG Viewer. See Software Downloads from Adobe. If a map does not display as expected, or does not display at all, you may need to update your version of the SVG Viewer. Use the link above to check your SVG Viewer version.
To view a map showing all managed units:
Log into the Guardium GUI of the unit to be managed as the admin user
Click on the Administrator Console tab
Click on the Central Management link under Central Management in the left hand column menu
Click the Show Distributed Map button to display a map of the central manager unit and all managed units.
The following table describes the symbols used in the map.
|
Symbol |
Description |
|
Desktop Computer |
The Central Manager Unit, labeled with its hostname |
|
Rack Mount Computer |
A Managed Unit, labeled with its hostname |
|
Disk with CPU |
An aggregator unit, labeled with its hostname |
|
Blue Arrow |
A blue arrow labeled with the letter M connects the Central Manager Unit with all Managed Units (which are not also aggregation units). |
|
Yellow Arrow |
Yellow arrows labeled with the letter A connect Aggregation Units with the units being aggregated (unless the unit is also a Manged Unit). The arrow indicates the direction of aggregation. |
|
Green Arrow |
Green arrows labeled with the letters A/M relate Managed Aggregation Units to the Central Manager Unit. The arrows indicate the direction of aggregation (and may be included on both ends if the Central Manager Units is also an aggregation unit). |
Provide visibility and control over patch installation, status and history. On a Central management cluster provides a way to install patches on managed units from the Central Manager.
Log into the Guardium GUI of the unit to be managed as the admin user
Click on the Administrator Console tab
Click on the Central Management link under Central Management in the left hand column menu
Do one of the following:
Click on Patch Distribution
The Patch Distribution button will open a new screen, display an available patch list with dependencies, and allow for the selecting of a patch and installing it to all selected units. The list of available patches is constructed out of the available patches and evaluating the currently installed patches on each of the selected units along with the dependency list of available patches. Patches available but not installable (a dependent patch is missing) are shown in the list as grayed out and cannot be selected. The selection of patch to install is a single selection - only one patch can be installed at a time. Once a patch is selected and the install button pushed a command is sent to all selected units to install that patch.
Click on Patch Installation Status
The Patch Installation Status screen will display, for each unit, failed installations and discrepancies - situations such as having one patch being installed on part of the units only, regardless if it failed on other units or was not installed.
Click on a Remove button
Click this button to delete the patch file from the Central Manager, and remove the patch from the Available Patches list.