You can use the Auditing Facility to report and track auditable events to ensure the
integrity of your system.
About this task
Note: The security auditing subsystem has been introduced as part of the security infrastructure.
The primary responsibility of the security infrastructure is to prevent unauthorized access and
usage of resources. Utilizing security auditing has two primary goals:
- Confirming the effectiveness and integrity of the existing security configuration.
- Identifying areas where improvement to the security configuration might be needed.
Security auditing achieves these goals by providing the infrastructure that allows you to
implement your code to capture and store supported auditable security events. During run time, all
code other than the Java™ EE 5 application code is considered to be trusted. Each time a Java EE 5
application accesses a secured resource, any internal application server process with an audit point
included can be recorded as an auditable event.
The security auditing subsystem has the ability to capture the following types of auditable
events:
- Authentication
- Authorization
- Principal/Credential Mapping
- Audit policy management
- Delegation
These types of events can be recorded into audit log files. Each audit log has the option to be
signed and encrypted to ensure data integrity. These audit log files can be analyzed to discover
breaches over the existing security mechanisms and to discover potential weaknesses in the current
security infrastructure. Security event audit records are also useful for providing evidence of
accountability and nonrepudiation as well as vulnerability analysis. The security auditing
configuration provides four default filters, a default audit service provider, and a default event
factory. The default implementation write to a binary text-file based log. Use this topic to
customize your security auditing subsystem.
- Enabling the security auditing subsystem
Security auditing will not be performed unless the audit security subsystem has been enabled.
Global security must be enabled for the security audit subsystem to function, as no security
auditing occurs if global security is not also enabled.
- Assign the auditor role to a user
A user with the auditor role is required to enable and configure the security auditing subsystem.
It is important to require strict access control for security policy management. The auditor role
has been created providing granularity to allow for separation of the auditing role from the
authority of the administrator. When Security Auditing is initially enabled, the cell administrator
has auditor privileges. If the environment requires separation of privileges, then changes will need
to be made to the default role assignments.
- Creating security auditing event type filters
You can configure event type filters to only record a specific subset of auditable event types in
your audit logs. Filtering the event types that are recorded makes for easier analysis of your audit
records by ensuring only those records important to your environment are archived.
- Configuring the audit service provider.
The audit service provider is used to format the audit data object that was passed to it before
outputting the data to a repository. A default audit service provider implementation is in included.
See Configuring the default audit service providers for security auditing for more details on the default
implementation. A third party implementation can also be coded and used. See Configuring a third party audit service providers for security auditing for more details on this implementation.
An implementation for SMF is also available. See Configuring the SMF audit service providers for security auditing for more details on this implementation.
- Configuring audit event factories for security auditing
The audit event factory gathers the data associated with the auditable events and creates an
audit data object. The audit data object is then sent to the audit service provider to be formatted
and recorded to the repository.
- Protecting your security audit data
It is important to secure and ensure the data integrity of the recorded audit data. To ensure
that access to the data is restricted and tamper proof, you can encrypt and sign your audit data.
- Configuring security audit subsystem failure notifications
Notifications can be enabled to generate alerts when the security auditing subsystem experiences
a failure. Notifications can be configured to record an alert in the System logs or can be
configured to send an alert through email to a specified list of recipients.
What to do next
After configuring security auditing, you can analyze your audit data for potential
weaknesses in the current security infrastructure and to discover security breaches that may have
occurred over the existing security mechanisms. You can also use the security auditing subsystem to
provide data for problem determination. If the default audit service provider was selected, the
resulting binary audit log file can be read using the Audit Reader.