Console Login

Automating Compliance: Surviving Schrems II with OpenSCAP and Ansible on Norwegian Soil

Automating Compliance: Surviving Schrems II with OpenSCAP and Ansible on Norwegian Soil

If you are still manually checking /etc/ssh/sshd_config lines on your production servers, you are already behind. In the wake of the CJEU's Schrems II ruling last July, the legal landscape for data hosting in Europe has shifted violently. The privacy shield is dead. For those of us operating in Norway, Datatilsynet isn't asking politely anymore; they demand demonstrable control over where data lives and how it is secured.

Compliance is no longer a quarterly paperwork exercise. It is an engineering challenge. As a CTO, I see too many teams treating security hardening as a one-time setup task. They deploy a hardened image, pat themselves on the back, and then watch configuration drift erode that security over six months. A junior dev changes a firewall rule for debugging and forgets to revert it. Suddenly, port 22 is open to the world.

We need immutable infrastructure concepts applied to compliance. We need to automate the boring, rigorous work of checking CIS Benchmarks. Here is how we build a self-auditing architecture using tools available right now, ensuring your VPS Norway infrastructure remains fortress-grade.

The Stack: OpenSCAP and Ansible

To solve this, we rely on the Security Content Automation Protocol (SCAP). Specifically, the open-source implementation OpenSCAP. It allows us to scan servers against standard profiles (like PCI-DSS or CIS) and generate human-readable reports.

We combine this with Ansible for remediation. Why Ansible? Because it’s agentless. Installing heavy agents on a performance-critical NVMe VPS defeats the purpose of buying high-performance hosting.

Pro Tip: Never run compliance scans on your production database master during peak hours. Even with nice values, the I/O load of hashing thousands of files can cause latency spikes. Schedule these via cron for 03:00 AM local Oslo time.

Step 1: Establishing the Baseline (CIS Benchmarks)

The Center for Internet Security (CIS) benchmarks are the gold standard. For a standard web server, we usually target CIS Level 1 Server. Level 2 is more secure but can break functionality if you aren't careful (e.g., restricting compiler access).

First, install the scanner and the security guides on your Ubuntu 20.04 LTS instance:

sudo apt-get update
sudo apt-get install libopenscap8 sshed-tools scap-security-guide

Step 2: The Audit Scan

This is where we stop guessing. We run a scan against the standard profile. This command checks your system configuration against hundreds of rules.

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-ubuntu2004-ds.xml

The output report.html will likely show a fail rate of 30-50% on a vanilla OS install. Do not panic. Default installs prioritize compatibility, not security. You will see failures for things like:

  • /tmp partition mounting options (noexec, nosuid)
  • SSH root login enabled
  • Unrestricted ICMP redirects

Step 3: Automated Remediation

We don't fix these by hand. We fix them with code. Below is a snippet of an Ansible playbook designed to remediate common failures found in the scan. This ensures that every node you deploy on CoolVDS starts in a compliant state.

---
- name: Hardening Baseline for Ubuntu 20.04
  hosts: all
  become: yes
  tasks:
    - name: Ensure SSH Root Login is disabled
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^PermitRootLogin'
        line: 'PermitRootLogin no'
        state: present
      notify: Restart SSH

    - name: Set permissions on bootloader config
      file:
        path: /boot/grub/grub.cfg
        owner: root
        group: root
        mode: '0600'

    - name: Disable IP forwarding (if not a router)
      sysctl:
        name: net.ipv4.ip_forward
        value: '0'
        state: present
        reload: yes

    - name: Set password expiration to 90 days
      lineinfile:
        path: /etc/login.defs
        regexp: '^PASS_MAX_DAYS'
        line: 'PASS_MAX_DAYS   90'

  handlers:
    - name: Restart SSH
      service:
        name: sshd
        state: restarted

Running this playbook takes seconds. Doing it manually takes hours.

The Hardware Reality: Isolation Matters

Software configuration is only half the battle. The other half is the infrastructure itself. In the post-Schrems II era, data residency is critical. If your VPS provider is essentially a reseller for a US-based hyperscaler, you are navigating a legal minefield regarding data access.

At CoolVDS, we own the hardware. It sits in Oslo. But more importantly, we use KVM virtualization. Unlike container-based VPS solutions (OpenVZ or LXC), KVM provides a hardware-level abstraction.

Feature Container VPS (LXC/OpenVZ) CoolVDS (KVM)
Kernel Isolation Shared Kernel (Risk of escape) Dedicated Kernel (High Isolation)
SELinux/AppArmor Often Restricted Full Control
Custom Modules No Yes (Load your own security modules)

Continuous Monitoring with Auditd

Prevention is ideal; detection is mandatory. Once your system is hardened, you must watch for changes. auditd is the Linux Audit Daemon. It listens to the kernel and logs specific events.

Here is a robust configuration block to detect if any user attempts to alter the /etc/passwd file or change file attributes—classic signs of an intrusion attempt.

# /etc/audit/rules.d/audit.rules

# Watch critical files for write access or attribute changes
-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 system calls for file truncation (often used to hide tracks)
-a always,exit -F arch=b64 -S ftruncate -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k access

# Lock the configuration so it cannot be changed until reboot
-e 2

Load these rules instantly:

sudo augenrules --load

The Economic Argument

Why go through this trouble? Because the Total Cost of Ownership (TCO) of a breach is infinite compared to the cost of automation. European businesses are moving workloads back to local providers not just for low latency—though pinging Oslo in 2ms is nice—but for legal certainty.

When you deploy on CoolVDS, you aren't just getting raw NVMe storage and CPU cycles. You are getting a clean slate, physically located in Norway, ready for the rigorous configuration required by 2021 standards. We provide the infrastructure; you provide the code.

Don't let compliance be a bottleneck. Script it, schedule it, and sleep better knowing your infrastructure defends itself.

Ready to audit? Spin up a fresh KVM instance on CoolVDS today and run your first OpenSCAP scan in under 60 seconds.