| Oracle® Real User Experience Insight User's Guide Release 11.1 for Linux x86-64 Part Number E22309-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Real User Experience Insight User's Guide Release 11.1 for Linux x86-64 Part Number E22309-01 |
|
|
PDF · Mobi · ePub |
This chapter describes the use of Collector profiles and the configuration of the security-related settings used by RUEI for traffic monitoring. These include setting network filters to prevent the capturing of specific networks, hosts, Virtual Local Area Networks (VLANs), or to reduce overall monitored traffic. The security of sensitive data can also be maintained by specifying masking actions for HTTP protocol items (such as URL arguments, HTTP headers, and cookies). Finally, the managing of your Web server's private keys to handle encrypted secure traffic is also described.
The management of all security-related information is the responsibility of the Security Officer.
In order to facilitate the easy management of Collectors, each Collector is assigned to a Collector profile. When configuration changes are made to a Collector profile, they are automatically applied to all Collectors assigned to it.
Upon installation, a predefined Collector profile (System) is created. This is the default Collector profile. You can create additional profiles to meet your reporting requirements by copying an existing profile as the basis for the new one. Note that, unlike user-defined Collector profiles, the System Collector profile cannot be deleted.
To view the currently available Collector profiles, Select Configuration, then Security, and then Collector profiles. An example is shown in Figure 13-1.
For each Collector profile, the options shown in Table 13-1 are available from its context menu.
Table 13-1 Collector Profile Context Menu
| Option | Description |
|---|---|
|
Configure |
Allows you to specify the configuration of all Collectors assigned to the selected profile. These include the use of network filters, the TCP ports on which Collectors should listen, and the private keys used to decrypt secure traffic. This is described in Section 13.1.2, "Modifying Collector Profile Configurations". You can specify whether Collectors assigned to a profile are restarted automatically, or whether a required manual restart is indicated, after configuration changes to a profile. This is described in Section 13.1.5, "Restarting Collectors". |
|
Copy |
Uses the selected Collector profile as the basis for a new one. This is described in Section 13.1.1, "Creating Collector Profiles". |
|
Edit properties |
Allows you to modify the Collector profile's name and brief description. Note that the default Collector profile's properties cannot be modified. |
|
Remove |
Deletes the selected Collector profile. Note that if the select profile has Collectors assigned to it, these are automatically re-assigned to the default (System) Collector profile. Note that it is not possible to delete the default Collector profile. |
In order to create a new Collector profile, do the following:
Select Configuration, then Security, and then Collector profiles. The currently defined Collector profiles are displayed. An example is shown in Figure 13-1.
Select Copy from the context menu of the Collector profile you want to use as a basis for the new one. The dialog shown in Figure 13-2 appears.
Figure 13-2 Copy Collector Profile Dialog
Specify a unique name and, optionally, a brief description for the new Collector profile. It is recommended that the description provides an indication of the profile's purpose and scope. When ready, click Save. Upon creation, the new profile appears in the list of available Collector profiles (Figure 13-1).
Configure the new Collector profile to meet your monitoring requirements. This is described in Section 13.1.2, "Modifying Collector Profile Configurations".
After creating a new profile, its configuration is the same as the profile upon which it is based. In order to modify its configuration to meet your requirements, do the following:
Click the required profile from the list of available Collector profiles (Figure 13-1), or select Configure from its context menu. A window opens showing the Collectors currently assigned to the selected profile. An example is shown in Figure 13-3.
Figure 13-3 Configure Network Data Collectors Window
From the Configuration menu, select Configure to modify the Collector profile's configuration. The options shown in Table 13-2 are available.
Table 13-2 Collector Profile Configuration Options
| Option | Description |
|---|---|
|
Protocols |
Select this option to specify on which TCP ports Collectors assigned to the profile should listen. This is described in Section 13.2, "Managing the Scope of Monitoring". |
|
Network filters |
Select this option to specify whether collectors assigned to the profile should be restricted to monitoring specific segments of network traffic, or to specific servers and subnets. This is described in Section 13.3, "Defining Network Filters". |
|
SSL keys |
Select this option to specify the certificates that will be imported to each of the profile's assigned Collectors to monitor encrypted content. This is described in Section 13.4, "Managing SSL Keys". |
|
Collector restart method |
Select this option to specify whether Collectors assigned to the profile should be restarted automatically after configuration changes. This is described in Section 13.1.5, "Restarting Collectors." |
Collectors assigned to a profile can readily be re-assigned to another one in order to meet your reporting requirements. For example, as a result of changes in network traffic patterns or security requirements. To re-assign a Collector, do the following:
Select the profile to which the Collector is currently assigned. A window similar to the one shown in Figure 13-3 appears.
Select the Assign profile option from the Collector's context menu. The dialog shown in Figure 13-4 appears.
Select the new profile to which the Collector should be assigned. When ready, click Save.
After the Collector is assigned to the selected profile, the status message should in Figure 13-5 appears.
Figure 13-5 Moved Collector Status Message
This status message can remain for up to 60 seconds. After that, the Collector is either restarted automatically, or a required manual restart is indicated. See Section 13.1.5, "Restarting Collectors" for more information.
Important:
Be aware that if the new profile's segmentation scheme is different from that of the previous profile, the Collector's segmentation scheme is adjusted to be consistent with that of its new profile. Therefore, it is strongly recommended that you review its traffic filter settings after assigning it to a new profile. See Section 13.3.3, "Limiting Overall Traffic" for more information.If you want to assign a number of Collectors to a different profile, you can use the Multiple selection option within the Configuration menu. After clicking the required Collectors, click the Assign profile command button on the toolbar.
To attach a new Collector to the system, do the following:
Select Configuration, then Security, and then Collector profiles. The currently defined Collector profiles are listed. An example is shown in Figure 13-1.
Select the profile to which the new remote Collector should be attached. Alternatively, select Configure from its context menu. The Collectors currently assigned to the selected profile are listed. An example is shown in Figure 13-3.
Select the Register remote Collector option from the Configuration menu. The dialog shown in Figure 13-6 appears.
Specify the IP address of the new Collector system and, optionally, a brief description. It is recommended that this include an indication of its scope and purpose. When ready, click Register. See the Oracle Real User Experience Insight Installation Guide for information about the configuration requirements for Collector systems.
After making certain configuration changes to a Collector profile, all Collectors assigned to that profile must be restarted in order for the changes to take effect. This restart can either be performed automatically (the default), or be performed manually. To configure the Collector restart method, do the following:
Click the required profile from the list of available Collector profiles (Figure 13-1), or select Configure from its context menu. A window opens showing the Collectors currently assigned to the selected profile. An example is shown in Figure 13-3.
From the Configuration menu, select Configure, and then Collector restart method. The dialog shown in Figure 13-7 appears.
Figure 13-7 Edit Collector Restart Method
Use the Restart method menu to specify whether the Collectors assigned to the selected profile are restarted automatically after configuration changes to the profile (the default), or whether a manual restart is required. When ready, click Save.
Manually Restarting Collectors
You should not restart a Collector until a required restart is indicated in the Configure network data Collectors window. An example is shown in Figure 13-8.
To restart an individual Collector, select Restart from its context menu. Note that when a Collector profile contains a large number of Collectors, it may be more convenient to use the Restart all Collectors option within the Configuration menu.
It may be necessary to stop the Collector instance when performing maintenance or troubleshooting on a remote Collector system. In this case, you can select Disable from the Collector's context menu to stop the Collector's monitoring of traffic. When ready, the Collector can be instructed to resume monitoring by selecting the Restart option.
When a remote Collector system is decommissioned, it is necessary to remove it from the RUEI installation. To do so, select the Unregister option from the Collector's context menu. Upon confirmation, the Reporter's connection to the Collector system is abandoned. Note that the local Collector instance cannot be unregistered.
The local Collector instance on the Reporter system is represented by the System (localhost) item. Note that after installation, it is not yet enabled, and appears in each currently defined Collector profile. After being enabled within a specific profile, it only appears in the selected Collector profile. It is not possible to unregister the local Collector instance.
Within RUEI, you control the scope of traffic monitoring by specifying which TCP ports it should monitor. Obviously, no information is available for unmonitored ports. It is recommended that you carefully review your selections of monitored and unmonitored TCP ports (both HTTP and HTTPS).
The currently monitored ports can be viewed by selecting Configuration, then Security, and then Protocols. An example is shown in Figure 13-9.
To modify these settings, do the following:
Use the Profile menu to select the required Collector profile.
Click the protocol whose port settings you want to modify. Table 13-3 shows the available settings.
| Protocol | Description |
|---|---|
|
HTTP/Forms servlet mode |
Specifies the ports on which the profile's Collectors should listen for Forms servlet traffic. This option is only applicable to EBS-based traffic (see Appendix M, "Oracle E-Business Suite (EBS) Support"). |
|
Forms socket mode |
Specifies the ports on which the Profile's Collectors should listen for Forms traffic in socket mode. This option is only applicable to EBS-based traffic (see Appendix M, "Oracle E-Business Suite (EBS) Support"). |
|
HTTP |
Specifies the ports on which the profile's Collectors should listen for HTTP traffic. This setting should only be used for "pure" HTTP traffic. |
|
HTTPS proxy |
Specifies the proxy server port numbers to which SSL traffic is sent. Note that:
|
|
HTTPS |
Specifies the ports on which the profile's Collectors should listen for HTTPS traffic. Upon installation, the HTTPS port 443 is defined as the default monitored port. |
A dialog similar to the one shown in Figure 13-10 appears.
To add a new port number, enter the required number in the Port number field, and click Add. To remove a port from the list, click the Remove icon to the right of the port. When ready, click Save.
Important:
The port numbers specified within each protocol must be mutually exclusive within Collector profiles. That is, a port number should only appear in one protocol's list of assigned port numbers.When a required restart is indicated, restart the Collectors assigned to the profile. This is described in Section 13.1.5, "Restarting Collectors".
In addition to port numbers, you can use network filters to manage the scope of monitored traffic. They allow you to restrict monitoring to specific servers and subnets, and to restrict the level of packet capture.
To define or modify network filters, do the following:
Select Configuration, then Security, and then Network filters.
Use the Profile menu to select the required Collector profile. The currently defined network filters are displayed. An example is shown in Figure 13-11.
Use the filters described in the following sections to manage the scope of the monitored traffic.
When a required restart is indicated, restart the Collectors assigned to the profile. This is described in Section 13.1.5, "Restarting Collectors".
You can define filters to restrict the scope of monitoring to specific servers and subnets. Note that this facility is only available if at least one Collector has been assigned to the Collector profile. Do the following:
Click Add new filter to define a new filter, or click an existing filter to modify it. The dialog shown in Figure 13-12 appears.
Use the Server IP address and Netmask fields to specify the address to which the Collector should listen. It is recommended that this is done in consultation with your network specialist. When ready, click Save.
VLAN filters offer a means by which to limit monitored traffic to specific servers and subnets. To define VLAN filters, do the following:
Click the current setting for VLAN filter shown in Figure 13-11. The dialog shown in Figure 13-13 appears.
Figure 13-13 Configure VLAN Filter Dialog
Use the Filter menu to specify whether VLAN filtering should be enabled. Note that enabling this filter means that only VLAN traffic will be monitored.
Optionally, use the VLAN ID field to specify a specific VLAN on which to filter. When ready, click Save.
In addition to the use of network and VLAN filters, it is also possible to specify how much of the overall traffic that remains after the application of other filters is actually monitored. By default, all remaining traffic is monitored.
To specify the level of overall traffic monitoring, do the following:
Click the current setting for Traffic filter shown in Figure 13-11. The dialog shown in Figure 13-14 appears.
Figure 13-14 Limit Overall Traffic Dialog
Use the Filtering scheme menu to specify whether filtering of network traffic should be based on physical or functional IP addresses.
By default, filtering of network traffic is based on the physical IP address. That is, the IP address fetched from the IP packet. However, if a Collector is installed behind a CDN or proxy server, you may prefer that filtering is based on functional IP addresses. If so, you should be aware of the following:
If the functional IP address is not available, then the IP address obtained from the IP packet is used instead.
The use of a configured client IP header for network filtering places a considerable processing overhead on the Collector, especially when SSL encryption is being used in the monitored traffic. This is because filtering upon physical addresses can be performed at the TCP level, while filtering upon functional IP addresses normally has to be performed at HTTP level.
Use the Packet capture menu to specify which part of the traffic should the profile's Collectors monitor. Table 13-4 shows the available options.
Table 13-4 Packet Capture Schemes
| Option | Description |
|---|---|
|
All traffic |
Specifies that all traffic that remains after the application of other filters should be monitored. This is the default. |
|
Specified domains |
Specifies that monitoring should be restricted to those domains that are explicitly specified in your application, suite, and service definitions. |
|
Traffic sampling |
Specifies that only a portion of the traffic should be monitored, and which part of it. For example, you could have an installation in which four Collectors are configured, and all Collectors monitor the same portion of the packet stream. |
|
Load balancing |
Specifies that monitoring of the packet stream should be spread across the Collectors within the Collector profile, with each Collector receiving a separate portion. 2-16 Collectors are supported for this configuration. The assignment of Collectors can be:
This option is only available if at least one Collector has been assigned to the Collector profile. |
When ready, click Save.
When a required restart is indicated, restart the Collectors assigned to the profile. This is described in Section 13.1.5, "Restarting Collectors".
The setting described above specifies how much of the total network traffic is measured. Therefore, if you specify that half of all traffic should be monitored, only the monitored half is reported. When using a setting of less than 100%, you should bear in mind that the reported information does not reflect all actual traffic, but the selected sample.
Traffic monitoring is based on IP addresses. This means that, regardless of what setting you use, complete user sessions are recorded. However, the number of those sessions depends on your selected setting.
RUEI can be configured to monitor encrypted data (such as HTTPS and SSL). In order to do this, a copy of the Web server's private SSL keys needs to be imported into RUEI. To import certificates to monitor encrypted content, do the following:
Select Configuration, then Security, then SSL keys, and then SSL keys management. Use the Profile menu to select the required Collector profile. A list of the currently installed keys is displayed. An example is shown in Figure 13-15.
Click Add new key to define a new key. Note that existing SSL key definitions cannot be modified. The dialog shown in Figure 13-16 appears.
Use the Key field to specify the file containing the key. If the key is encrypted, you must specify the passphase. When ready, click Install key.
The certificate will be encrypted on the disk.
Note:
The supplied file can be in PEM, DER, or PKCS12 format, and must include the key and matching certificate. The key must be an RSA key. Note that encryption protocols that use 40-bit keys (such as DES_40, RS2_4-0, and RC4_40) are not supported.Supported Encryption Protocols and Mechanisms
Within Message Authentication Codes (MACs), the MD5, SDA-1, and SDA-2 functions are supported. The SSL v3 and TLS v1.0 cryptographic protocols are supported. A complete list of the currently supported encryption algorithms is available within the SSL connections section of the Collector statistics window (see Section 15.2, "Viewing the Status of the Collectors").
Be aware that both SSL and Oracle Forms traffic are particularly sensitive to disruptions in the TCP packet stream. This is because they require state information to be maintained for the duration of the connection, and any lost packets can cause that information to be lost, preventing RUEI from accurately monitoring and reporting the connection.
Therefore, you should ensure that each Collector is connected to a reliable network device, such as a TAP. In addition, it is strongly recommended that you regular review the information available through the Collector Statistics window (described in Section 15.2, "Viewing the Status of the Collectors") to verify the integrity of the TCP packet stream. Particular attention should be paid to the reported TCP and SSL connection errors.
To remove an installed SSL key, right click the required key, and select Remove. You are prompted to confirm the key's removal.
Optionally, you can configure notifications about pending SSL key expirations. This allows you to plan the importation of new keys, and ensures that there are no gaps in the monitored data while new keys are obtained and activated. Do the following:
Click the Monitor key expiration icon on the taskbar. If it is not already visible, select Configuration, then Security, then SSL keys, and then SSL keys management. The dialog shown in Figure 13-17 appears.
Specify the number of days prior to expiration when notification should be generated. Use the controls on the other tabs to specify the e-mailing, SNMP, and text message notification details. These are similar to the dialogs explained in Section 7.5.1, "Alert Profiles". When ready, click Save.
When a required restart is indicated, restart the Collectors assigned to the profile. This is described in Section 13.1.5, "Restarting Collectors".
Note:
The check for expired SSL keys is scheduled to be run once a day at 6 am (Reporter system time).The RUEI installation can be configured to omit the logging of sensitive information. This is called masking, and it allows you to prevent passwords, credit card details, and other sensitive information from being recorded on disk. RUEI's security facilities allow you to control the logging of POST URL arguments, HTTP headers, cookies and their values, Oracle Forms elements, and the contents of URLs.
Note:
The masking actions you define are applied to all monitored domains.To implement a masking, do the following:
Select Configuration, then Security, then Masking, and then select the appropriate option for the HTTP protocol item you want to configure. For example, URL prefix masking. A window similar to the one shown in Figure 13-18 appears.
The currently defined maskings for the selected HTTP protocol item are listed.
Click Add new masking to define a new masking, or click an existing one to modify it. A dialog similar to the one shown in Figure 13-19 appears.
Specify the name of the item whose logging you want to control. Depending on the selected protocol item, this will either be the name of a POST URL argument, a cookie name or value, an Oracle Forms element, or an item within a HTTP header or URL prefix. Note the procedure for defining URL prefix maskings is described later in this section.
Select the masking action to be assigned to the defined item. Table 13-5 shows the available for protocol items other than URL prefixes.
| Option | Description |
|---|---|
|
Default |
Specifies that the defined default action for the selected HTTP protocol item should be performed for this item. The use of this facility is described in the following section. |
|
Hashed |
Specifies that the item's contents should be replaced with a calculated hash value when logged. This mechanism provides a unique value for comparison purposes, but is not in human-readable form. For example, five different user IDs would receive five different hashes when logged, while multiple sessions by the same visitor would receive the same hash. This manufactured (hashed) value provides uniqueness, but not the real value itself. |
|
Blinded |
Specifies that the item's original contents should be overwritten with an Xs when logged. |
|
Plain |
Specifies that the item should be logged in its original state. That is, unprotected. |
|
Truncated |
Specifies that only the first 1 KB characters of the HTTP protocol item are logged. Values longer than this have their reminder truncated and hashed, and appended to the first 1 KB of plain (unhashed) data. In this way, their uniqueness is preserved. |
When ready, click Save. Any changes you specify take effect within 5 minutes.
Note:
All items are case insensitive.As mentioned earlier, the default setting specifies the action that should be taken for HTTP protocol items not explicitly specified in your security definitions. By defining items with the "Default" action, you can modify the security settings for a large number of data items (both listed and unlisted) with one user action.
To specify the default action, do the following:
Select the HTTP protocol item whose default action you want to specify. For example, HTTP header masking.
Click the current setting for the Default masking action menu. This is located at the top of the masking window. A dialog similar to the one shown in Figure 13-16 appears.
Figure 13-20 Edit Default Masking Setting Dialog
Select the required security setting to be applied to all data item's with the action "Default". When ready, click Save. Any changes you make to this setting take effect within 5 minutes.
In addition to the HTTP protocol item maskings you explicitly define, items are also automatically detected by RUEI during configuration. These are assigned the action "Default". You can modify their assigned actions either individually or collectively through changing the defined default action, but you cannot remove them.
In addition, be aware that after deleting an item (for example, a custom dimension item described in Section 3.11, "Working With Custom Dimensions"), if you have not modified its masking action, it is automatically removed from the displayed items list. However, if you have previously modified its defined action, you will need to explicitly remove it from the items list.
A number of pre-configured HTTP headers maskings are defined. These items are used by RUEI for the processing of monitored traffic. They have the action "Used in system" defined for them, which means their associated items are recorded in their original state. This action cannot be modified because they are required for the correct monitoring of network traffic.
Note that if session tracking is based on some standard technology (such as Apache or ColdFusion), the cookie is not reported in the "Used in" section. Instead, these cookies have the default masking action assigned to them, unless they have been defined manually, and have been configured differently from their default values. This does not represent a problem if the default masking action has not been set to blinded. If it has, all visitor sessions would be booked on one session.
In addition to URL POST arguments, Forms elements, cookies, and HTTP headers, it is also possible to protect certain URL contents by specifying a prefix. This facility is useful when you want to prevent the storage of URL structures that might contain sensitive information.
The options specify which parts, in terms of request and response headers and bodies, are preserved in the Replay Viewer facility and the Collector log files (from which information within the Data Browser groups and Session Diagnostics facility is derived). Table 13-6 shows the available masking actions.
Table 13-6 URL Masking Actions
| Masking Action | Description |
|---|---|
|
Complete logging |
Specifies that all parts should be preserved in both the Replay viewer and Collector log files (after all other defined maskings have been applied). |
|
No request body |
Specifies that all parts (after all other defined maskings have been applied) are preserved in Collector log files, but request bodies are not preserved in the Replay viewer. |
|
Headers only |
Specifies that all parts (after all other defined maskings have been applied) are preserved in the Collector log files, but only request and response headers are preserved in the Replay viewer. |
|
No replay |
Specifies that all parts (after any other defined maskings have been applied) are preserved in the Collector log files, but nothing is preserved in the Replay viewer. |
|
No logging |
Specifies that nothing is preserved in either the Replay viewer or Collector log files. |
Note:
Selecting the "Complete logging" option as the default masking action is the equivalent of enabling replay functionality in previous versions of RUEI by selecting Configuration, then Security, then Blinding, then clicking the Toggle Replay functionality icon on the toolbar, and selecting the "Enabled" option.The items recorded in the Replay Viewer facility and the Collector log files (from which information within Data Browser groups and Session Diagnostics is derived) for each of these masking actions is explained in Table 13-7.
Table 13-7 Items Logged With URL Prefix Masking Action
| Masking action | Request header | Request body | Response header | Response body | Recorded in Collector log file |
|---|---|---|---|---|---|
|
Complete logging |
X |
X |
X |
X |
X |
|
No request body |
X |
X |
X |
X |
|
|
Headers only |
X |
X |
X |
||
|
No replay |
X |
||||
|
No logging |
Note that if an item is used within the RUEI installation (for example, as part of an application or suite definition), this is indicated in the displayed list, and the item cannot be removed. In addition, be aware that while multiple (overlapping) item definitions are possible, the longest matching specification will be used as the assigned masking action.
Be aware that, in the case of overlapping matching URL prefixes (for example, /ru and /ruei), that have been assigned different masking actions, the longest match is taken. In addition, note that the prefix must be a true prefix. For example, if the matching URL is /app/ruei, neither /ru or /ruei will be matched.
In addition, it is important understand that the question mark character (?) should not be specified within URL prefixes. If it is, the question mark character, and everything after it, is ignored. For example, if you specify the URL /catalog/jn.php?item, it is truncated to /catalog/jn.php. URLs should be specified in human-readable format (not encoded).
Note:
URL prefixes are case sensitive.Masking Data Used by External Applications
As explained in Appendix R, "Enriched Data Export Facility", data collected by RUEI can be exported to enable its combination with other data warehouse data. Because any data items masked within RUEI are also masked when exported, it is recommended that you carefully review the requirements for data items used by external applications. The settings windows available within the masking facility provide an ideal audit tool to verify your security requirements.
Masking the Authorization Field
As explained in Section 8.2.10, "Defining User Identification", user identification is first based on the HTTP Authorization field. Be aware that, if this is sent over the network in plain format, this represents a security issue because the user name and password can potentially be decoded from it. This is a limitation of the basic authentication protocol.
If Authorization fields are sent over the network in plain format, you can use the masking options described in the previous section to control whether they are preserved in the Replay viewer. Alternatively, you can ensure that Authorization fields are hashed when included in network traffic. In this case, the user IDs are unavailable in the Session diagnostics facility.
See Appendix G, "Working With National Language Support" for a detailed discussion of the operation of data masking when working with international character sets.
Note that the cookie value -1 is automatically assigned the masking action "Plain" (that is, it is preserved in its original state). This is necessary because this value is often used within Oracle E-Business Suite to indicate an end of session.
Modifying Your Masking Definitions
Be aware that when changing a data item's security, any data already stored in log files is unaffected by the change. If necessary, you should consider purging the system (this is fully described in Section 15.11, "Resetting the System").
Important:
It is strongly recommended that you regularly verify that all sensitive data is masked correctly on a regular basis. Applications often change over time, and so do their use of POST variables, cookies, headers, and URL structures. The Collector and Reporter raw log files can be found in the directories
/var/opt/ruei/processor/data. The Session diagnostics export facility can also be used to audit the content of these files. This is described in Section 4.4, "Exporting Full Session Information".By default, all SSL client certificate properties (when available) are recorded as part of the log files generated by each Collector system. If this does not meet your organization's security policies, do the following:
Select Configuration, then General, then Advanced settings, and then SSL certificate masking. The panel shown in Figure 13-21 appears.
Figure 13-21 Collector SSL Client Certificate Masking Policy
Click the required Collector profile's certificate masking action. The dialog shown in Figure 13-22 appears.
Figure 13-22 Edit Collector SSL Certificate Masking Dialog
The options shown in Table 13-8 are available.
Table 13-8 SSL Certificate Masking Actions
| Option | Description |
|---|---|
|
Log full certificate properties |
Specifies that the complete SSL certificate should be logged. This is the default. |
|
Log session ID only |
Specifies that only session ID information should be recorded. |
|
No certificate properties logged |
Specifies that no proportion of the SSL certificate should be logged. |
Select the required masking action. When ready, click Save.
When a required restart is indicated, restart the Collectors assigned to the profile. This is described in Section 13.1.5, "Restarting Collectors".
To specify the data retention policy used by all Collectors attached to a Reporter, do the following:
Select Configuration, then Security, and then Collector data retention policy. The panel shown in Figure 13-23 appears.
Figure 13-23 Collector Data Retention Policy
For each currently defined application, suite, or service, the Oldest data column indicates how far back in time (in seconds, hours, minutes, or days) data for the indicated storage item is available. Typically, if the oldest entry is reported as 10 minutes, this indicates a very busy system that cannot store more than 10 minutes of data. The Newest entry column indicates how far back in time data to the indicated storage item was written.
For each application, suite, or service, use the check box in the Options column to specify whether the creation of replay data should be enabled. By default, replay data is enabled.
Click either the Error page replay store or Full session replay storage option for the application you want to modify. A dialog similar to the one shown in Figure 13-24 appears.
Figure 13-24 Error Page Replay Store Size Dialog
Specify the maximum amount of disk space that should be reserved for FSR or EPR data on the selected Collector for the specified application, suite, or service.
Note that the storage items for the "Unclassified" application refer to the maximum amount of disk space that should be reserved for network traffic that could not be associated with a particular application, suite, or service.
When ready, click Save.
Optionally, click the View security URL masking policies item. The dialog shown in Figure 13-25 appears. It highlights the currently defined URL prefixes masking actions, as well as the default masking action.
Figure 13-25 URL Prefix Blinding Settings Dialog
Alternatively, Instead of specifying the FSR and EPR data store sizes for individual applications, suites, and services, you can click the Set Full session replay store size for all applications or Set Error page replay store size for all applications icon shown in Figure 13-23. A dialog similar to the one shown in Figure 13-26 appears.
Figure 13-26 Full Session Replay Store Size Dialog
Specify the maximum amount of disk space for FSR or EPR data reserved on the selected Collector system for each application, suite, or service. When ready, click Save.
When a required restart is indicated, restart all Collectors. This is described in Section 13.1.5, "Restarting Collectors".
Note that when an application, suite, or service is deleted, its associated FSR and EPR data is not automatically removed from the Collector system. Instead, it remains available for viewing. If you want to delete this data, you should click the Remove icon shown in the Status column. You are prompted to confirm the data's deletion.
Be aware of the following:
When you reduce the replay disk space available to an application to an amount lower than that currently being used, the oldest data in store is removed to resize the replay data store. For example, imagine that you specify that an application's FSR data store should be reduced from 20 GB to 10 GB, and 14 GB is currently being used. In this case, the oldest 4 GB of the current FSR data is removed to resize the store.
If the EPR data store holds more days of data than the Failed event data setting, then the extra amount of data is not accessible via the GUI. Conversely, if the EPR size setting is lower than the number of days of failed event data, then Replay Viewer data will not be available for the extra period. However, the other views on the data will be available as usual, through the other Data Browser groups.
Note that if the FSR data setting is set to less than 15 minutes, the error replay facility may not function correctly. In addition, if set to zero, the EPR size setting can no longer be modified.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|