Auditing
Auditing
20.1 Overview
Auditing allows you to keep a record of significant events on servers and applications, which helps give you a picture of what information is being accessed, how it's being accessed and changed, and who is performing these operations. This information is recorded in a database called the Auditing Data
Store (ADS). Once the data is in the ADS, you can design custom reports to suit your needs. You can look for sample universes and reports on the SAP Developer Network .
For the purposes of this chapter, an auditor is a system responsible for recording or storing information on an event, and an auditee is any system responsible for performing an auditable event. There are some circumstances where a single system can perform both functions.
How Auditing works
The Central Management Server (CMS) acts as the system auditor, while each server or application that triggers an auditable event acts as an auditee. When an audited event is triggered, the auditee will generate a record and store it in a local temporary file. At regular intervals, the CMS communicates with the auditees to request these records and writes the data to the ADS.
The CMS also controls the synchronization of auditing events that occur on different machines. Each auditee provides a timestamp for the auditing events that it records. To ensure that the timestamps of events on different servers are consistent, the CMS periodically broadcasts its system time to the auditees. The auditees then compare this time to their internal clocks. If differences exist, they correct the time recorded for subsequent auditing events.
Depending on the type of auditee, the system uses one of the following workflows to record the events.
Server auditing
In cases of server generated events, the CMS can act as both Auditee and Auditor.
639 2012-12-12
Auditing
1.
An auditable event is performed by the server.
2.
The server auditee writes events in a temporary file.
3.
The auditor polls the auditee and requests a batch of auditing events.
4.
The server auditee retrieves the events from the temporary files.
5.
The server auditee transmits the events to the auditor.
6.
The auditor writes events to the ADS and signals the server auditee to delete the events from the temporary files.
Client logon auditing for clients connecting through CORBA
This includes applications such as SAP BusinessObjects Web Intelligence.
640
1.
The client connects to the CMS, which will act as the auditee. The client provides its IP address and machine name, which the auditee then verifies.
Note:
A port should be opened in the firewall between the client and CMS. More details on firewalls can be found in the security chapter of the
SAP BusinessObjects Business Intelligence Platform
Administrator Guide.
2.
The auditee writes events in a temporary file.
3.
The auditor polls the auditee and requests a batch of auditing events.
4.
The auditee retrieves the events from the temporary files.
5.
The auditee transmits the events to the auditor.
2012-12-12
Auditing
6.
The auditor writes events to the ADS and signals the auditee to delete the events from the temporary files.
Client logon auditing for clients connecting through HTTP
This includes online applications such as BI launch pad, Central Management Console, SAP
BusinessObjects Web Intelligence, and so on.
641
1.
The browser connects to the web application server, and logon data is submitted to the web application server.
2.
The BI platform SDK submits the logon request to the auditee (CMS), along with the IP address and name of the browser machine.
3.
The auditee writes events in a temporary file.
4.
The auditor polls the auditee and requests a batch of auditing events.
5.
The auditee retrieves the events from the temporary files.
6.
The auditee sends events to the auditor.
7.
The auditor writes events to the ADS and signals the auditee to delete the events from the temporary files.
Non-logon auditing for clients connecting through CORBA
This workflow applies to auditing SAP BusinessObjects Web Intelligence events when connecting through CORBA.
2012-12-12
Auditing
642
1.
The user performs an operation that may be audited.
2.
The client contacts the CMS to check if the operation is configured to be audited.
3.
If the action is set to be audited, the CMS communicates this information to the client.
4.
The client sends the event information to the Client Auditing Proxy Service (CAPS), hosted in an
Adaptive Processing Server.
Note:
A port in the firewall should be opened between each client and any Adaptive Processing Servers that hosts a CAPS, and also between each client and the CMS. More details on firewalls can be found in the security chapter of the
SAP BusinessObjects Business Intelligence Platform Administrator
Guide.
5.
The CAPS writes events in a temporary file.
6.
The Auditor polls the CAPS and requests a batch of auditing events.
7.
The CAPS retrieves the events from the temporary files.
8.
The CAPS sends the event information to the auditor.
9.
The auditor writes events to the ADS and signals the CAPS to delete the events from the temporary files.
Non-login auditing for clients connecting through HTTP
This workflow applies to auditing SAP BusinessObjects Web Intelligence events (except for logon events) when connecting through HTTP.
2012-12-12
Auditing
643
1.
The user initiates a potentially auditable event. The client application contacts the web application server.
2.
The web application checks to see if the event is configured to be audited.
Note:
The diagram shows the Auditor CMS being contacted, but any CMS in the cluster can be contacted for this information.
3.
The CMS returns the audit configuration information to the web application server, which passes this information back to the client application.
4.
If the event is configured to be audited, the client sends the event information to the web application server, which passes it to the Client Auditing Proxy Service (CAPS), hosted in an Adaptive Processing
Server (APS).
5.
The CAPS writes events in a temporary file.
6.
The auditor polls the CAPS and requests a batch of auditing events.
7.
The CAPS retrieves the events from the temporary files.
8.
The CAPS sends the event information to the auditor.
9.
The auditor writes events to the ADS and signals the CAPS to delete the events from the temporary files.
Clients that support auditing
The following client applications support auditing:
• Central Management Console (CMC)
• BI launch pad
• Open Document
• Analysis
• Live Office Web Services Provider
2012-12-12
Auditing
644
• Web Intelligence desktop
• Mobile
• Dashboard & Presentation Design
• Dashboard Manager
Note:
At least one instance of CAPS must be running in order to collect auditing events from the clients listed above.
Clients not listed above do not directly generate events, but some actions performed by the servers as a result of client application operations can be audited.
Auditing consistency
In most cases, where auditing is properly installed, configured, secured, and correct versions of all client applications are used, auditing will properly and consistently record all indicated system events.
It is important to keep in mind, however, that certain system and environment conditions can adversely affect auditing.
There is always a delay between the time an event occurs and its final transfer to the Auditor database.
Conditions such as the unavailability of the CMS or auditing database or loss of network connectivity can increase these delays.
As a system administrator, you should work to avoid any of the following conditions, which could result in incomplete auditing records:
• A drive where auditing data is stored reaches maximum capacity. You should ensure plenty of disk space is available for your auditing database and auditee temporary files.
• An auditee server is improperly removed from the network before it can transmit all audit events.
You should ensure that when removing a server from the network, sufficient time is allowed for audit events to post to the auditing database.
• The deletion or modification of auditee temporary files.
• A hardware or disk failure.
• Physical destruction of an auditee or auditor host machine.
There are also some conditions where audit events may be prevented from reaching the CMS-Auditor.
These can include:
• Users with older client versions.
• Transmission of auditing information may be blocked by improperly configured firewalls.
Note:
• Events generated by client applications contain information submitted from the client side, in other words outside the trusted area of the system. Therefore under some conditions this information may not be as reliable as information recorded by the system servers.
• If you want to remove a server from your deployment, you should first disable that server but keep it running and connected to your network until all the events in the temporary files have had a chance to transfer to the auditing database. The server's "Current Number of Auditing Events in the Queue" metric will show how many auditing events are waiting to be transferred, when this reaches zero you can stop the server. The location of the Temporary files is defined in the Placeholders for that node. See the Server Administration chapter for more details on placeholders.
2012-12-12
