Compliance as Code: Automating CIS Benchmarks & GDPR Technical Safeguards
If you treat security compliance as a once-a-year panic attack before an audit, you are doing it wrong. In the post-Schrems II era, where data sovereignty is not just a buzzword but a legal minefield, manual hardening is a liability. I have sat in meetings with Datatilsynet (The Norwegian Data Protection Authority) where they didn't care about our policy documents; they wanted to see the current state of our root permissions and encryption protocols.
The reality for CTOs operating in Europe today is binary: either you automate your compliance, or you accept that your infrastructure is drifting into non-compliance every time a junior dev pushes a hotfix. This guide is not about policy writing. It is about implementing Compliance as Code using tools available right now on your Linux stack.
The Myth of the "Secure" Image
Many administrators spin up a standard image—Ubuntu 22.04 LTS or AlmaLinux 9—and assume the default settings are secure enough. They aren't. Default configurations prioritize compatibility, not security. A fresh install often listens on unnecessary ports, allows older TLS versions, and has permissive file permissions.
Pro Tip: Never trust the default "cloud-init" image blindly. While CoolVDS provides optimized base images, the responsibility for the OS-layer hardening (the Shared Responsibility Model) falls squarely on you. We provide the secure, encrypted NVMe storage; you must lock down the front door.
Phase 1: Assessing the Damage with OpenSCAP
Before we fix anything, we need to measure the gap between your current state and the standard. In 2023, the industry standard for this is the Security Content Automation Protocol (SCAP). We will use OpenSCAP to audit a server against the CIS (Center for Internet Security) benchmarks.
First, install the necessary tools. On an AlmaLinux 9 (Red Hat compatible) system:
dnf install openscap-scanner scap-security-guide -y
Once installed, do not just run a generic scan. You need to select the correct profile. For a production web server handling Norwegian customer data, we usually aim for the xccdf_org.ssgproject.content_profile_cis_workstation_l2 or server equivalent.
Here is how you execute a scan that generates a human-readable HTML report:
oscap xccdf eval \
--profile xccdf_org.ssgproject.content_profile_cis_server_l2 \
--results-arf /var/log/oscap-results.xml \
--report /var/www/html/compliance-report.html \
/usr/share/xml/scap/ssg/content/ssg-almalinux9-ds.xml
If you run this on a vanilla install, prepare for a lot of red text. You will likely fail checks for:
/tmppartition mounting options (noexec, nodev).- SSH root login permissions.
- Umask settings.
- Auditd configuration.
Phase 2: Remediation via Ansible
Knowing you are vulnerable is only half the battle. Fixing it manually is a waste of TCO. We use Ansible to enforce the state. This ensures that if a setting is changed manually, the next Ansible run reverts it to the compliant state. This is crucial for maintaining GDPR integrity.
Here is a snippet from a production playbook we use to enforce SSH hardening specifically for high-compliance environments. Note the explicit disabling of X11 forwarding and strict MAC algorithms, which are often overlooked.
---
- name: Harden SSH Configuration
hosts: all
become: yes
tasks:
- name: Ensure SSH Protocol 2 is strictly enforced
lineinfile:
path: /etc/ssh/sshd_config
regexp: '^Protocol'
line: 'Protocol 2'
state: present
validate: 'sshd -t -f %s'
- name: Disable Root Login
lineinfile:
path: /etc/ssh/sshd_config
regexp: '^PermitRootLogin'
line: 'PermitRootLogin no'
state: present
notify: Restart SSH
- name: Disable X11 Forwarding
lineinfile:
path: /etc/ssh/sshd_config
regexp: '^X11Forwarding'
line: 'X11Forwarding no'
state: present
- name: Limit SSH Access to Specific Users
lineinfile:
path: /etc/ssh/sshd_config
regexp: '^AllowUsers'
line: 'AllowUsers deploy_user admin_user'
state: present
handlers:
- name: Restart SSH
service:
name: sshd
state: restarted
Phase 3: Automated Drift Detection
Compliance is temporal. You are compliant now, but will you be compliant next Tuesday? To solve this, we set up a cron job that runs a lightweight scan and alerts us only on failure. This is far more efficient than running a heavy agent.
Here is a Bash script wrapper that you can drop into /etc/cron.daily/security-audit:
#!/bin/bash
PROFILE="xccdf_org.ssgproject.content_profile_standard"
DS_PATH="/usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml"
REPORT_DIR="/var/log/compliance"
DATE=$(date +%F)
HOSTNAME=$(hostname)
mkdir -p $REPORT_DIR
# Run the scan
oscap xccdf eval \
--profile $PROFILE \
--report $REPORT_DIR/audit-$DATE.html \
$DS_PATH > /dev/null 2>&1
# Grep for failures in the result (exit code 2 usually means non-compliant)
EXIT_CODE=$?
if [ $EXIT_CODE -eq 2 ]; then
echo "Subject: Security Drift Detected on $HOSTNAME" | sendmail admin@yourdomain.com
fi
The Hardware Layer: Why Your Host Matters
You can have the most hardened OS in the world, but if your physical data resides on a shared drive in a jurisdiction with invasive surveillance laws, your software compliance means nothing. This is the "Schrems II" reality.
When we architected the CoolVDS infrastructure in our Oslo datacenter, we focused on physical isolation and I/O path security. We use KVM (Kernel-based Virtual Machine) because it offers stricter isolation than container-based virtualization (like OpenVZ or LXC), preventing "noisy neighbor" exploits or kernel panic cascades.
Comparison: Container vs. KVM Compliance
| Feature | Container VPS (LXC/OpenVZ) | CoolVDS KVM |
|---|---|---|
| Kernel Isolation | Shared Kernel (High Risk) | Dedicated Kernel (High Security) |
| SELinux/AppArmor | Often Restricted | Full Control |
| Disk Encryption | Host-level only | Full Disk Encryption (LUKS) capable |
For GDPR compliance, the ability to run LUKS (Linux Unified Key Setup) on your partition is often a requirement for storing sensitive PII. You simply cannot do this effectively on many budget container VPS providers. CoolVDS NVMe instances expose the block device directly enough to allow full encrypted file systems.
Conclusion
Automation is the only way to scale security. By combining OpenSCAP for visibility and Ansible for enforcement, you turn compliance from a yearly headache into a daily routine. But remember, software runs on hardware. Ensure your foundation—your hosting provider—respects data sovereignty and offers the virtualization depth required for true isolation.
Next Step: Don't wait for a letter from the authorities. Audit your current setup today. If you need a clean, compliant slate physically located in Norway, spin up a CoolVDS instance and test these Ansible playbooks in a safe environment.