> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xloud.tech/llms.txt
> Use this file to discover all available pages before exploring further.

# Compliance and Auditing

> Configure audit logging, log aggregation, and retention for Xloud Platform. Map platform controls to SOC 2, ISO 27001, HIPAA, PCI-DSS, and GDPR frameworks.

## Overview

Xloud Platform generates structured audit logs for all API calls, authentication events, and administrative operations. Logs follow the CADF (Cloud Audit Data Federation) standard. You can ship them to external SIEM systems, log aggregation pipelines, or retain them locally with configurable retention policies. This page covers audit log configuration, aggregation, and framework-by-framework compliance mapping.

<Note>
  **Prerequisites**

  * Administrator role in Xloud Identity
  * For log aggregation: XIMP (Infrastructure Monitoring) enabled with the centralized logging add-on
  * For compliance reports: access to the audit log pipeline or SIEM tool receiving Xloud events
</Note>

***

## Audit Logging

### CADF Event Structure

Every platform event produces a CADF-formatted audit record:

```json title="Example CADF audit event" theme={null}
{
  "typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event",
  "id": "evt-a1b2c3d4-...",
  "eventTime": "2025-03-18T09:30:00.000000+00:00",
  "action": "create",
  "outcome": "success",
  "initiator": {
    "typeURI": "service/security/account/user",
    "id": "user-id-...",
    "name": "admin",
    "project_id": "project-id-...",
    "host": {
      "address": "10.0.0.100",
      "agent": "python-keystoneclient"
    }
  },
  "target": {
    "typeURI": "compute/machine",
    "id": "server-id-...",
    "name": "prod-web-01"
  },
  "observer": {
    "typeURI": "service/compute",
    "id": "nova-api-host-01"
  },
  "reason": {
    "reasonCode": "200",
    "reasonType": "HTTP"
  }
}
```

### Enable Audit Middleware

Audit middleware is enabled per service. By default, all Xloud API services have audit middleware active. To verify:

```bash title="Check audit middleware status" theme={null}
docker exec nova_api grep -i "audit" /etc/nova/nova.conf | grep -v "^#"
```

To enable or reconfigure audit middleware explicitly:

```yaml title="/etc/xavs/globals.d/_60_audit.yml" theme={null}
nova_audit_events: "all"
keystone_audit_events: "all"
neutron_audit_events: "all"
cinder_audit_events: "all"
glance_audit_events: "all"
```

***

## Log Aggregation and Retention

<Tabs>
  <Tab title="Centralized Logging (XIMP)" icon="gauge">
    <Steps titleSize="h3">
      <Step title="Enable central logging" icon="settings">
        In XDeploy, navigate to **Configuration → Global Settings** and enable **Central Logging**. This activates Fluentd on all nodes and deploys OpenSearch as the log aggregation backend.
      </Step>

      <Step title="Configure retention policy" icon="clock">
        Navigate to **XIMP → Log Management → Index Policies**. Set the retention period:

        | Log Type              | Minimum Retention | Recommended |
        | --------------------- | ----------------- | ----------- |
        | Authentication events | 90 days           | 1 year      |
        | API audit events      | 90 days           | 1 year      |
        | Service logs          | 30 days           | 90 days     |
        | Security events       | 1 year            | 3 years     |

        <Warning>Some compliance frameworks require specific minimum retention periods. PCI-DSS requires 1 year with 3 months immediately available. HIPAA requires 6 years for audit logs. Configure retention before collecting audit data.</Warning>
      </Step>

      <Step title="Configure SIEM forwarding" icon="arrow-right">
        To forward audit events to an external SIEM:

        Navigate to **XIMP → Integrations → Log Forwarding** and configure the SIEM endpoint, authentication, and event filter.

        <Check>Events appear in the SIEM within the configured polling interval (typically 30–60 seconds).</Check>
      </Step>
    </Steps>
  </Tab>

  <Tab title="CLI" icon="terminal">
    ```yaml title="Enable centralized logging" theme={null}
    # /etc/xavs/globals.d/_60_logging.yml
    enable_central_logging: "yes"
    opensearch_log_retention_days: 365
    fluentd_syslog_port: 5140
    ```

    ```bash title="Deploy logging stack" theme={null}
    xavs-ansible deploy --tags fluentd,opensearch,opensearch-dashboards
    ```

    ```bash title="Query audit logs via OpenSearch API" theme={null}
    curl -sk -u admin:<password> \
      "https://10.0.1.71:9200/audit-*/_search" \
      -H "Content-Type: application/json" \
      -d '{
        "query": {
          "bool": {
            "filter": [
              {"term": {"action": "delete"}},
              {"range": {"eventTime": {"gte": "now-24h"}}}
            ]
          }
        },
        "sort": [{"eventTime": "desc"}],
        "size": 50
      }' | python3 -m json.tool
    ```
  </Tab>
</Tabs>

***

## Compliance Framework Mapping

The following table maps Xloud platform controls to requirements in major compliance frameworks.

| Control                    | SOC 2        | ISO 27001 | HIPAA               | PCI-DSS  | GDPR    |
| -------------------------- | ------------ | --------- | ------------------- | -------- | ------- |
| TLS for all API endpoints  | CC6.1        | A.10.1.1  | § 164.312(e)        | 4.1      | Art. 32 |
| Token-based authentication | CC6.1, CC6.2 | A.9.4.2   | § 164.312(d)        | 8.3      | Art. 32 |
| RBAC policy enforcement    | CC6.3        | A.9.4.1   | § 164.312(a)        | 7.1      | Art. 25 |
| Audit logging (CADF)       | CC7.2        | A.12.4.1  | § 164.312(b)        | 10.2     | Art. 30 |
| Log retention ≥ 1 year     | CC7.2        | A.12.4.1  | § 164.312(b)        | 10.7     | Art. 30 |
| Volume encryption (LUKS)   | CC6.7        | A.10.1.1  | § 164.312(a)(2)(iv) | 3.4, 3.5 | Art. 32 |
| Key management (Barbican)  | CC6.7        | A.10.1.2  | § 164.312(e)(2)     | 3.6      | Art. 32 |
| Network segmentation       | CC6.6        | A.13.1.1  | § 164.312(a)        | 1.1      | Art. 25 |
| Security group enforcement | CC6.6        | A.13.1.3  | § 164.312(a)        | 1.2      | Art. 32 |
| Change tracking            | CC8.1        | A.12.1.2  | § 164.312(b)        | 6.4.5    | Art. 30 |
| Vulnerability scanning     | CC7.1        | A.12.6.1  | § 164.308(a)(8)     | 6.3.3    | Art. 32 |

***

## Security Scanning and Vulnerability Management

<Steps titleSize="h3">
  <Step title="Schedule regular vulnerability scans" icon="search">
    Integrate Xloud with your vulnerability scanning tool (Wazuh, OpenVAS, Qualys, or similar). Scan all compute nodes and control plane hosts at minimum monthly.

    ```bash title="Run Lynis system audit" theme={null}
    lynis audit system --quick --report-file /var/log/lynis-report-$(date +%Y%m%d).txt
    ```
  </Step>

  <Step title="Review and triage findings" icon="list">
    Prioritize findings by CVSS score:

    | Severity | CVSS Range | Target Remediation |
    | -------- | ---------- | ------------------ |
    | Critical | 9.0–10.0   | 24 hours           |
    | High     | 7.0–8.9    | 7 days             |
    | Medium   | 4.0–6.9    | 30 days            |
    | Low      | 0.1–3.9    | 90 days            |
  </Step>

  <Step title="Patch and re-scan" icon="rotate-cw">
    Apply patches via the standard XOS update process and re-scan to confirm remediation.

    ```bash title="Apply security updates on all nodes" theme={null}
    xavs-ansible deploy --tags common --limit control,compute
    ```

    <Check>Re-scan confirms the vulnerability is resolved. Update the compliance tracking document with the remediation date.</Check>
  </Step>
</Steps>

***

## Change Tracking

All infrastructure changes made through XDeploy, xavs-ansible, and the Xloud API are recorded with timestamps, user identity, and the before/after state.

```bash title="View recent deployment history" theme={null}
xavs-ansible facts --list-hosts all
cat /var/log/xavs/ansible.log | grep -E "PLAY|TASK|fatal" | tail -50
```

For platform API changes, query the audit log:

```bash title="Filter audit events for a specific user" theme={null}
# Via OpenSearch
curl -sk -u admin:<password> \
  "https://10.0.1.71:9200/audit-*/_search" \
  -d '{"query": {"term": {"initiator.name": "admin"}}, "size": 100}'
```

***

## Incident Response

<AccordionGroup>
  <Accordion title="Suspected credential compromise" icon="key">
    **Immediate actions**:

    1. Revoke the compromised credential or token immediately:
       ```bash theme={null}
       openstack user password set --password <new-strong-password> <user>
       # Revoke all active tokens for the user:
       openstack token revoke $(openstack token issue -c id -f value)
       ```
    2. Review audit logs for the compromised account in the 30 days prior to detection.
    3. Identify all resources created or modified with the compromised credential.
    4. Rotate any application credentials created by the affected account.
    5. File an incident report with exact timeline, affected resources, and remediation actions taken.
  </Accordion>

  <Accordion title="Unauthorized API access detected" icon="circle-x">
    **Investigation steps**:

    1. Identify the source IP and token from the audit log.
    2. Check whether the token is still valid:
       ```bash theme={null}
       openstack token validate <token-id>
       ```
    3. Revoke the token if it remains active.
    4. Review HAProxy access logs for all requests from the source IP.
    5. Determine whether a firewall block is warranted at the network perimeter.
  </Accordion>

  <Accordion title="Encryption key suspected compromised" icon="lock">
    **Immediate actions**:

    1. Identify all volumes and objects using the compromised key.
    2. Snapshot all affected volumes immediately.
    3. Create new encrypted volumes with a fresh key, copy data, and delete old volumes.
    4. Delete the compromised key from Xloud Key Management after verifying all data has been migrated.
    5. Document the scope of exposure and notify relevant parties per your incident response policy.
  </Accordion>
</AccordionGroup>

***

## Next Steps

<CardGroup cols={2}>
  <Card title="Hardening Guide" href="/security/hardening-guide" color="#197560">
    Pre-deployment hardening checklist to meet baseline compliance requirements
  </Card>

  <Card title="Infrastructure Security" href="/security/infrastructure" color="#197560">
    TLS configuration for SOC 2 and PCI-DSS encryption-in-transit controls
  </Card>

  <Card title="Data Security" href="/security/data-security" color="#197560">
    Volume and object encryption for data-at-rest compliance requirements
  </Card>

  <Card title="Monitoring (XIMP)" href="/services/monitoring/index" color="#197560">
    Log aggregation, alerting, and security event dashboards
  </Card>
</CardGroup>