Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE OpenStack Cloud 9

15 Security Audit Logs Edit source

15.1 The need for auditing Edit source

Enterprises need the ability to audit and monitor workflows and data in accordance with their strict corporate, industry or governmental policies and compliance requirements such as FIPS-140-2, PCI-DSS, HIPAA, SOX, or ISO. To meet this need, SUSE OpenStack Cloud supports CADF (Cloud Auditing Data Federation)-compliant security audit logs that can easily be integrated with your organization's Security Information and Event Management (SIEM) tools. Such auditing is valuable not only to meet regulatory compliance requirements, but also for correlating threat forensics.

Note that logs from existing OpenStack services can also be used for auditing purposes, even though they are not in a consistent audit friendly CADF format today. All logs can easily be integrated with a SIEM tool such as ArcSight, Splunk etc.

15.2 Audit middleware Edit source

Audit middleware is python middleware logic that addresses the aforementioned logging shortcomings. Audit middleware constructs audit event data in easily consumed CADF format. This data can be mined to answer critical questions about activities over REST resources such as who made the request, when, why, and so forth.

Audit middleware supports delivery of audit data via the Oslo messaging notifier feature. Each service is configured to route data to an audit-specific log file.

The following are key aspects of auditing support in SUSE OpenStack Cloud 9:

  • Auditing is disabled by default and can be enabled only after SUSE OpenStack Cloud installation.

  • Auditing support has been added to eight SUSE OpenStack Cloud services (nova, cinder, glance, keystone, neutron, heat, barbican, and ceilometer).

  • Auditing has been added for interactions where REST API calls are invoked.

  • All audit events are recorded in a service-specific audit log file.

  • Auditing configuration is centrally managed and indicates for which services auditing is currently disabled or enabled.

  • Auditing can be enabled or disabled on a per-service basis.

15.3 Centralized auditing configuration Edit source

In SUSE OpenStack Cloud, all auditing configuration is centrally managed and controlled via input model YAML files on the Cloud Lifecycle Manager node. The settings are configured in the file ~/openstack/my_cloud/definition/cloudConfig.yml in an audit-settings section shown below the following table.

KeyValue (default)TypeDescriptionExpected value(s)Comments
defaultdisabledStringFlag to globally enable or disable auditing for all services.disabled, enabled

A service's auditing behavior is determined via this default key value unless it is listed explicitly in the enabled-services or disabled-services list.

enabled-services[] (empty list)yaml list

Setting to explicitly enable auditing for listed services regardless of default flag setting.

nova, cinder, glance, keystone, neutron, heat, barbican, ceilometer

To enable a specific service, either add the service name in the enabled-services list when default is set to disabled or remove from disabled-services list when default is set to enabled.

If a service name is present in both enabled-services and disabled-services, then auditing will be enabled for that service.

disabled-servicesnova, barbican, keystone, cinder, ceilometer, neutronyaml list

Setting to explicitly disable auditing for listed services regardless of default flag setting.

nova, cinder, glance, keystone,neutron, heat, barbican, ceilometer

To disable a specific service, either add the service name in disabled-services when default is set to enabled. or remove from enabled-services list when default is set to disabled.

Audit settings in cloudConfig.yml with default set to disabled and services selectively enabled:

product:
    version: 2
    cloud:
    ....
    ....
    # Disc space needs to be allocated to the audit directory before enabling
    # auditing.
    # keystone and nova has auditing enabled
    # cinder, ceilometer, glance, neutron, heat, barbican have auditing disabled
    audit-settings:
    audit-dir: /var/audit
    default: disabled
    enabled-services:
    - keystone
    - nova
    disabled-services:
    - cinder
    - ceilometer

Audit setting in cloudConfig.yml with default set to enabled and services selectively disabled:

product:
    version: 2
    cloud:
    ....
    ....
    # Disc space needs to be allocated to the audit directory before enabling
    # auditing.
    # keystone, nova, glance, neutron, heat, barbican has auditing enabled
    # cinder, ceilometer has auditing disabled
    audit-settings:
    audit-dir: /var/audit
    default: enabled
    enabled-services:
    - keystone
    - nova
    disabled-services:
    - cinder
    - ceilometer

Because auditing is disabled by default, you will need to follow the steps below to enable it:

  1. Book “Operations Guide CLM”, Chapter 13 “Managing Monitoring, Logging, and Usage Reporting”, Section 13.2 “Centralized Logging Service”, Section 13.2.7 “Audit Logging Overview”, Section 13.2.7.1 “Audit Logging Checklist”

  2. Book “Operations Guide CLM”, Chapter 13 “Managing Monitoring, Logging, and Usage Reporting”, Section 13.2 “Centralized Logging Service”, Section 13.2.7 “Audit Logging Overview”, Section 13.2.7.2 “Enable Audit Logging”

For instructions on backing up and restoring audit logs, see: Book “Operations Guide CLM”, Chapter 17 “Backup and Restore”, Section 17.3 “Manual Backup and Restore Procedures”, Section 17.3.4 “Audit Log Backup and Restore” .

Print this page