Audit Trail

GuardianKey Auth Bastion can record HTTP accesses that pass through the reverse proxy. The audit trail provides operational and security visibility into protected applications without requiring changes to their source code.

The access audit trail is different from the administrative audit log:

• Audit Trail records HTTP requests processed by the Bastion, including the client, requested resource, HTTP result, processing time, and upstream information.
• Audit Log records changes made by administrators to Bastion entities and settings.

Enabling the audit trail

Audit trail collection can be controlled at two levels:

1. In Settings → Domain Names, set Audit Trails to Enabled or Disabled. This is the default for the protected domain.
2. In Settings → Protection Groups, set Audit Trails to:
   • Inherit: use the Domain Name setting;
   • Enabled: enable collection for this Protection Group, regardless of the domain default;
   • Disabled: disable collection for this Protection Group, regardless of the domain default.

This inheritance allows broad configuration at the domain level and exceptions for specific applications or protected paths.

After a setting is changed and the Bastion configuration is updated, the proxy marks eligible access records for collection. Static JavaScript and CSS requests are excluded from the audit trail pipeline.

Information recorded

Depending on the request and available upstream data, an audit trail record can contain:

• Identification: date and time, trail/request ID, organization, Protection Group, level, tags, and rule description;
• HTTP request: method, URI, full URL, protocol, content type and length, request length, referrer, and user agent;
• HTTP result: response status, bytes sent, and total request time;
• Client: client and proxy-related IP addresses, authenticated Bastion user, browser, operating system, and device type;
• Geolocation and network: country, country code, timezone, coordinates, ASN, and ASN organization, when enrichment data is available;
• Upstream: backend address, status, connection time, header time, and response time.

Because the trail is collected at the reverse-proxy layer, it records user actions that produce HTTP requests in the protected application. For example, report generation, record queries, updates, and deletions can be identified by their route and HTTP method. Trail Rules add business meaning to these requests through tags and descriptions defined for each protected application.

The audit trail records request metadata, not request or response bodies. However, URLs, query strings, referrers, user-agent values, IP addresses, and session-related identifiers may contain sensitive information. Restrict access to the console and avoid placing credentials or secrets in URLs.

Trail Rules

Administrators can use Settings → Trail Rules to classify matching audit trail records. A rule contains:

• an optional Protection Group; leaving it empty matches all groups available to the organization;
• regular expressions for URI, request method, HTTP status, and URL; an empty expression matches any value;
• a numeric priority, where a lower number has higher priority;
• Tag 1, Tag 2, and a required description;
• an Active or Inactive status.

Search-field mapping

The exploration interface supports the following audit search mapping:

Audit information	GuardianKey field
Date and time	Request timestamp and time-range filter
Protected system or group	Protection Group
User credential or identifier	Username
Action performed	HTTP method plus Trail Rule tags and description
Resource accessed	URI and full URL

These fields can be combined in a single search. Additional filters include client IP, level, HTTP and upstream status, geolocation, ASN, and upstream address.

Use narrowly scoped regular expressions and review their results in Explore Audit Trails before relying on tags for operational analysis.

Example rules

Purpose	URI regex	Method regex	Status regex	Tags
Track authentication submissions	^/login$	^POST$	Any	authentication, login
Identify server errors	Any	Any	^5[0-9]{2}$	availability, server-error
Monitor an administrative area	`^/admin(?:/	$)`	Any	Any

Values are examples and must be adapted to the paths and behavior of the protected application.

Dashboards - Audit Trails

The audit trail dashboard summarizes records for the selected interval. It provides:

• a time chart grouped by level;
• the distribution of event levels;
• top users and client IP addresses;
• top values for Tag 1 and Tag 2.

Use the filters to narrow the analysis by time, Protection Group, username, level, HTTP method, client IP, geolocation, status, URI, URL, tags, and upstream information.

Explore Audit Trails

Explore Audit Trails is intended for investigation of individual access records. The results table shows the date and time, Protection Group, client IP, request method, URL, username, Tag 1, and description. Select a record to inspect its full metadata in the details panel.

Common investigation paths include:

• use the request ID shown in the record to correlate the transaction with related system logs;
• combine username, client IP, and time range to review a user's activity;
• filter by status or upstream status to troubleshoot application errors;
• use tags defined by Trail Rules to find accesses of interest;
• compare request and upstream timing to identify latency between the Bastion and the protected backend.

Operational recommendations

• Enable collection only for the domains and Protection Groups that need access auditing.
• Review Trail Rules after protected application routes change.
• Limit console access according to the administrator's responsibilities.
• Treat audit trail data as security-sensitive because it may include personal and session-related metadata.
• Use the administrative Audit Log, rather than the access audit trail, when investigating who changed a Bastion setting.