Auditing plays a vital role in maintaining database security, regulatory compliance, and operational accountability in SAP Adaptive Server Enterprise. By capturing security-related events such as login activity, privilege changes, object access, and administrative operations, the ASE audit subsystem provides administrators with a reliable mechanism for tracking and reviewing critical system activity.

Historically, SAP ASE stored audit records exclusively in the sysaudits table within the sybsecurity database. While this approach remains useful for database-centric auditing, modern enterprise environments often require tighter integration with operating system logging frameworks and centralized monitoring solutions.

To address these requirements, now SAP ASE supports multiple audit destinations through the audit trail type configuration parameter. In Linux environments, audit records can be directed to:

• the sysaudits table,
• the operating system syslog infrastructure,
• or both simultaneously (Starting from ASE 16.1 SP01)

The ability to write audit records to syslog enables integration with standard Linux logging utilities such as rsyslog, making it possible to:

• Redirect audit logs to dedicated files
• Forward audit events to centralised log servers
• Integrate with SIEM platforms
• Separate ASE audit data from general system logs for easier administration and monitoring

Starting with ASE 16.1 SP01, SAP ASE introduces support for the both audit trail type, allowing audited events to be written simultaneously to both the database audit table and the OS syslog service. This provides greater flexibility for environments that require both long-term database-side retention and external log aggregation.

This blog discusses the available audit trail types in SAP ASE, explains how syslog-based auditing works on Linux, and walks through the configuration required to redirect ASE audit records to custom log files using rsyslog.

Supported Audit Destinations

1. table (Default – All Platforms)

Audit records are written to the sysaudits table in the sybsecurity database.

sp_configure "audit trail type", 0, "syslog"
go

3. both (Introduced in ASE 16.1 SP01, Linux Only)

Starting with ASE 16.1 SP01, ASE introduces a new audit trail type:

When enabled, audit records are written simultaneously to:

• The sysaudits table
• The OS syslog service

This option provides flexibility for environments that require:

• Database-level audit retention
• Centralized OS-level log aggregation
• External monitoring or SIEM integration

sp_configure "audit trail type", 0, "both"
go

Every ASE audit entry written through syslog is tagged with:

sp_configure "audit trail type", 0, "syslog"
go

When using the syslog or both audit trail types, ASE audit entries are processed by the Linux syslog subsystem.

Using rsyslog, administrators can redirect these audit messages to any custom file location.

This approach is useful for:

• Separating audit logs from general system logs
• Simplifying audit monitoring
• Integrating with external log collectors
• Managing dedicated audit retention policies

Step 1 — Create an rsyslog Configuration File

Create a dedicated configuration file under:

sudo touch /etc/rsyslog.d/ase.conf

Step 2 — Add a Routing Rule

Insert the following lines into the configuration file:

if $programname == 'SAP_ASE_AUDIT' then /path_to_redirect_ase_logs
& stop

if $programname == 'SAP_ASE_AUDIT' then /var/log/ase_audit.log
& stop

Understanding the Rule

$programname

In rsyslog terminology:

$programname: represents the syslog tag (also called the program tag or ident) associated with the message.

SAP ASE audit messages use:

& stop

The directive:

& stop: terminates further processing of the current message.

Without this line, the same audit entry will continue to propagate to:

rsyslog configuration files are parsed and loaded into an ordered rule set during startup.

At runtime, each incoming log message is evaluated sequentially against these rules. Because configuration files are processed alphabetically, rule order directly affects message routing behavior.

Consider the following two configuration files:

abc.conf

if $programname == 'SAP_ASE_AUDIT' then /audit1.log
& stop

xyz.conf

if $programname == 'SAP_ASE_AUDIT' then /audit2.log
& stop

Since abc.conf is processed first:

1. The audit message matches the rule in abc.conf
2. The message is written to /audit1.log
3. & stop immediately halts further processing
4. The message never reaches xyz.conf
5. The message also does not propagate to /var/log/messages

As a result, the audit entry appears only in:

After updating the configuration, restart the service:

sudo systemctl restart rsyslog

Custom Log File Locations

Audit logs can be redirected to any arbitrary file path and are not restricted to root-owned directories.

Example:

Automatic File Creation

If the target log file does not exist, rsyslog automatically creates it when the first matching message arrives.

Depending on the target location, administrators may need to configure:

• File ownership
• Read permissions
• Log rotation policies

This typically requires root privileges.

The enhanced auditing capabilities introduced in ASE 16.1 SP01 provide significantly greater flexibility for audit log management in Linux environments.

By supporting:

SAP ASE allows administrators to integrate database auditing more effectively into modern operational and security workflows.

Combined with Linux rsyslog routing rules, ASE audit records can be redirected, isolated, archived, and monitored using standard enterprise logging infrastructure, making audit management more scalable and operationally efficient.