Automating Security Compliance: From OpenSCAP to Ansible in a Post-Schrems II World

If you are still manually checking /etc/ssh/sshd_config lines on your production servers every quarter, you aren't just wasting time—you are actively creating a security debt that Datatilsynet (The Norwegian Data Protection Authority) will eventually cash in. In the wake of the Schrems II ruling, relying on US-based cloud giants has become a legal minefield for Norwegian companies handling personal data. The focus has shifted back to data sovereignty and rigorous, automated compliance on local infrastructure.

Compliance isn't a PDF you sign once a year. It's the state of your infrastructure at 3:00 AM on a Sunday. As a Systems Architect who has survived multiple GDPR audits, I can tell you that the only way to survive is to treat compliance as code. In this guide, we will build an automated hardening pipeline using OpenSCAP and Ansible on Ubuntu 22.04 LTS, ensuring your environment meets CIS (Center for Internet Security) benchmarks without human intervention.

The Compliance-as-Code Stack

We are going to use two industry-standard tools available in early 2023:

• OpenSCAP: For scanning and validating system configurations against XCCDF policies (extensible Configuration Checklist Description Format).
• Ansible: For remediation. Finding a vulnerability is useless if you don't fix it immediately.

Phase 1: Baseling with OpenSCAP

First, we need to know how broken the default installation is. On a standard generic VPS, you might score 40% on a CIS benchmark. On a specialized CoolVDS instance, we start with a cleaner image, but hardening is still your responsibility.

Install the necessary tooling on your audit node:

Now, let's list the available profiles for Ubuntu 22.04. This tells us what standards we can measure against.

You will likely see profiles for cis_level1_server, cis_level2_server, and standard. For most production web servers, CIS Level 1 is the baseline. Level 2 is for environments where security supersedes usability (e.g., banking backends).

Phase 2: The Audit Scan

Let's run a scan against the CIS Level 1 Server profile. This command generates an HTML report that you can show to your CISO.

oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --results-arf arf.xml \
  --report report.html \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml

Warning: Do not run heavy scans during peak traffic hours on under-provisioned hardware. While CoolVDS instances use dedicated NVMe storage to mitigate I/O wait, scanning thousands of filesystem permissions is IOPS-intensive.

The "Meat": Hardening the OS

Scanning is the easy part. Fixing the red flags is where systems break. Below are the critical configurations that often fail audits in 2023, specifically tailored for high-security environments.

1. SSH Hardening (The Front Door)

Standard SSH configs are too permissive. We need to disable weak ciphers and ensure root cannot login. Edit /etc/ssh/sshd_config:

# /etc/ssh/sshd_config
PermitRootLogin no
MaxAuthTries 4
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding no
# Force strong algorithms
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

2. Kernel Runtime Parameters

Network stack hardening is essential to prevent IP spoofing and Man-in-the-Middle attacks. Apply these settings in /etc/sysctl.d/99-security.conf:

net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv4.conf.all.log_martians = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
kernel.randomize_va_space = 2

Reload with sysctl -p /etc/sysctl.d/99-security.conf.

Pro Tip: Setting kernel.randomize_va_space = 2 forces Address Space Layout Randomization (ASLR), making buffer overflow attacks significantly harder. This is a zero-cost security win.

3. Auditd Rules (Watching the Watchers)

For GDPR compliance, you must know who changed a file and when. The Linux Audit daemon (auditd) is your flight recorder. Add these rules to /etc/audit/rules.d/audit.rules to monitor changes to the identity database:

-w /etc/group -p wa -k identity
-w /etc/passwd -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/security/opasswd -p wa -k identity

# Monitor sudoers usage
-w /etc/sudoers -p wa -k scope
-w /etc/sudoers.d/ -p wa -k scope

Phase 3: Automated Remediation with Ansible

Manually applying the above settings across 50 servers is impossible. We use Ansible. The Ansible Lockdown project provides excellent roles for this, but here is a simplified playbook structure to enforce the SSH hardening we discussed.

---
- name: Hardening CoolVDS Instances
  hosts: norway_production
  become: yes
  vars:
    ssh_port: 22
  
  tasks:
    - name: Ensure SSH protocol 2 is used
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^Protocol'
        line: 'Protocol 2'
        state: present
      notify: restart_ssh

    - name: Disable Root Login
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^PermitRootLogin'
        line: 'PermitRootLogin no'
        state: present
      notify: restart_ssh

    - name: Set idle timeout interval
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^ClientAliveInterval'
        line: 'ClientAliveInterval 300'
        state: present

    - name: Ensure permission 0600 on /etc/shadow
      file:
        path: /etc/shadow
        owner: root
        group: root
        mode: '0600'

  handlers:
    - name: restart_ssh
      service:
        name: sshd
        state: restarted

The Infrastructure Factor: Why Hardware Matters

You can have the most hardened OS in the world, but if your hypervisor is leaky or your data resides in a jurisdiction with invasive surveillance laws (like the US CLOUD Act), your compliance is void. This is where the choice of provider becomes an architectural decision, not just a procurement one.

We utilize KVM on CoolVDS because it provides strict isolation. Unlike container-based VPS solutions (like OpenVZ or LXC), a KVM instance has its own kernel. If a neighbor on the physical host kernel panics, you stay up. If they get compromised, the hardware virtualization extensions (Intel VT-x/AMD-V) keep them contained.

Final Thoughts: Compliance is Continuous

In 2023, the "set it and forget it" mentality is dead. Vulnerabilities like Log4j showed us that we need deep visibility and rapid patch management. By combining OpenSCAP for detection and Ansible for remediation, you build a self-healing infrastructure.

However, automation requires a stable foundation. Scripts fail when the underlying I/O hangs or the network jitters. For high-compliance workloads targeting the Nordic market, you need infrastructure that offers predictable performance and legal certainty.

Next Step: Stop guessing your compliance status. Deploy a fresh Ubuntu 22.04 instance on CoolVDS today, run the OpenSCAP scan above, and see the difference a clean, KVM-based environment makes to your security baseline.