Audit Logs
Audit Logs
Audit logs allow platform operators to see what actions were triggered, when, and by whom, providing a sense of accountability in every step of a process. The creation of these logs is disabled by default.
Enable Audit Logs in a9s Service Broker
To enable the audit logs in the a9s Service Broker the a9s Data Services must
be deployed with the Ops file: ops/enable-service-broker-audit-logs.yml
. The
destination endpoints must be passed to this Ops file using a variable array.
The audit log file is rotated on a daily base and the audit log file from the
last day is kept in case that there was an issue while streaming the logs.
For example:
$ bosh deploy -d postgresql-service postgresql-service/postgresql-service.yml \
-l config/iaas-config \
-l config/postgresql.yml \
-o ops/enable-service-broker-audit-logs.yml \
-v audit_endpoints="[foo.example.com:3000, bar.example.com:4321]" \
Enable Audit Logs in a9s Backup Manager
To activate the audit logs in the a9s Backup Manager the a9s Data Services must
be deployed with the Ops file: ops/enable-backup-manager-audit-logs.yml
. The
destination endpoints must be passed to this Ops file using a variable array.
The audit log file is rotated on a daily base and the audit log file from the
last day is kept in case that there was an issue while streaming the logs.
For example:
$ bosh deploy -d backup-service backup-service/backup-service.yml \
-l config/iaas-config.yml \
-o ops/enable-backup-manager-audit-logs.yml \
-v audit_endpoints="[foo.example.com:3000, bar.example.com:4321]" \
Audit Logs Format
The audit logs format follows the Common Event Format (CEF)
standard, a well
defined audit logging format that can be sent via the syslog protocol. For more
information see here.
The message sent over the syslog protocol follows the format shown below:
CEF:Version|Device Vendor|Device Product|Device Version|Signature|ID|Name|Severity|Extension
Where the values are such:
- Version: An
integer
that identifies the version of the CEF format. We use Version 0 - Device Vendor: A
string
that uniquely identifies the sending device vendor - Device Product: A
string
that uniquely identifies the type of sending device product - Device Version: A
string
that uniquely identifies the type of sending device version - Signature ID: A unique identifier per event-type
- Name: A
string
representing a human-readable and understandable description of the event - Severity: An
integer
ranging from0
to10
, with10
being the most severe - Extension: A collection of key-value pairs, predefined by the CEF format
It is in this Extension
parameter where the audit information is parsed to,
using the following extension key-value pairs:
- act: The action mentioned in the event (String 63)
- app: The application level protocol, some example values are: HTTP, HTTPS, etc (String 31)
- deviceExternalId: A name that uniquely identifies the device generating this event
- deviceFacility: The facility generating this event. For example, Syslog has an explicit facility associated with every event
- dtz: The timezone for the device generating the event
- dvc: Identifies the device address that an event refers to in an IP
network. The format is an IPv4 address. Example:
192.168.10.1
- dvchost: The format should be a fully qualified domain name (FQDN)
associated with the device node, when a node is available.
Example:
host.domain.com
orhost
- dvcpid: Provides the ID of the process on the device generating the event
- end: The time when the event ended (Date format
MM dd yyyy HH:mm:ss
) - outcome: Displays the event's status as
success
orfailure
(String 63) - reason: The The reason an audit event was generated (String 1043)
- request: The URL accessed, protocol included (String 1023)
- requestClientApplication: The User-Agent associated with the request (String 1023)
- requestMethod: The HTTP method used to access a URL. Possible values:
POST
,GET
, etc. (String 1023) - src: Identifies the source that an event refers to in an IP network.
Example:
192.168.10.1
- start: The time when the event started (Date format
MM dd yyyy HH:mm:ss
) - suid: The ID of the user associated with the source of the event (String 1023)
- suser: The username of the user associated with the event (String 1023). For more information see Variances Of The suser Field
The information sent through these extensions varies according to the application executing the logged event, there are even some additional extensions that aren't shared between the apps. Therefore, the following sections go over the application specific configuration.
Audit Logs Format For The a9s Backup Manager
The configuration for the a9s Backup Manager's audit logs approximates the structure of the format mentioned above.
The CEF message's header fields have the following values for the a9s Backup Manager:
- Device Vendor:
anynines
- Device Product:
a9s Backup Manager
- Device Version: The version of the a9s Backup Manager. Example:
1.3.5
- Signature ID:
backup_manager_api
- Name: The URL path of the action which has been triggered. Example:
/backup_agent/backup_all
- Severity: The following severity levels are supported in the a9s Backup
Manager:
- 1 = response succeeded,
- 4 = response failed because of client error,
- 7 = failed because of server error
The CEF message's extension fields have the following values for the a9s Backup Manager:
- cs1: The request parameters. Example: the ID of the restored backup
- cs1Label:
requestParameters
- cs2: The id of the instance that was called in requests
- cs2Label:
InstanceID
Audit Logs Format For The a9s Service Broker
The configuration for the a9s Service Broker's audit logs approximates the structure of the format mentioned above.
The CEF message's header fields have the following values for the a9s Service Broker:
- Device Vendor:
anynines
- Device Product:
a9s Service Broker
- Device Version: The version of the a9s Service Broker. Example:
1.3.5
- Signature ID:
broker_api
- Name: The URL path of the action which has been triggered. Example:
/v2/service_instances/1234-5678-90123
- Severity: The following severity levels are supported in the a9s Service
Broker:
- 1 = response succeeded,
- 4 = response failed because of client error,
- 7 = failed because of server error
The CEF message's extension fields have the following values for the a9s Service Broker:
- deviceExternalId: The GUID of the a9s Service Broker
Variances of the suser Field
It should be noted that the suser
value will vary depending on the application
that executed the logged event, as shown in the cases below:
- In the case of the event originating on the a9s Service Dashboard, the
suser
value will be logged as theusername
that executed the logged event - In the case of the event originating on the Cloud Foundry, the
suser
value will not correspond to theusername
and instead theuser_id
will be logged in its place, which always has the prefixcf-
. This is due to a limitation by Cloud Foundry on the OSBAPI's Originating header, since it as it has no access to theusername
and only provides theuser_id
- There are special cases that apply in every application: The System generated
events and Unknown user events. For system generated events the
suser
will be logged assystem
, and for an event with an unknown origin of execution then thesuser
will be logged asunknown