Overview
Xloud Cloud Platform generates structured audit logs for all API calls, authentication events, and administrative operations. Logs follow the CADF (Cloud Audit Data Federation) standard and can be shipped to external SIEM systems, log aggregation pipelines, or retained locally with configurable retention policies. This page covers audit log configuration, aggregation, and framework-by-framework compliance mapping.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
Audit Logging
CADF Event Structure
Every platform event produces a CADF-formatted audit record:Example CADF audit event
Enable Audit Middleware
Audit middleware is enabled per service. By default, all Xloud API services have audit middleware active. To verify:Check audit middleware status
/etc/xavs/globals.d/_60_audit.yml
Log Aggregation and Retention
- Centralized Logging (XIMP)
- CLI
Enable central logging
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.
Configure retention policy
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 |
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
Schedule regular vulnerability scans
Integrate Xloud with your vulnerability scanning tool (Wazuh, OpenVAS, Qualys, or similar). Scan all compute nodes and control plane hosts at minimum monthly.
Run Lynis system audit
Review and triage findings
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 |
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.View recent deployment history
Filter audit events for a specific user
Incident Response
Suspected credential compromise
Suspected credential compromise
Immediate actions:
- Revoke the compromised credential or token immediately:
- Review audit logs for the compromised account in the 30 days prior to detection.
- Identify all resources created or modified with the compromised credential.
- Rotate any application credentials created by the affected account.
- File an incident report with exact timeline, affected resources, and remediation actions taken.
Unauthorized API access detected
Unauthorized API access detected
Encryption key suspected compromised
Encryption key suspected compromised
Immediate actions:
- Identify all volumes and objects using the compromised key.
- Snapshot all affected volumes immediately.
- Create new encrypted volumes with a fresh key, copy data, and delete old volumes.
- Delete the compromised key from Xloud Key Management after verifying all data has been migrated.
- Document the scope of exposure and notify relevant parties per your incident response policy.
Next Steps
Hardening Guide
Pre-deployment hardening checklist to meet baseline compliance requirements
Infrastructure Security
TLS configuration for SOC 2 and PCI-DSS encryption-in-transit controls
Data Security
Volume and object encryption for data-at-rest compliance requirements
Monitoring (XIMP)
Log aggregation, alerting, and security event dashboards