Automating Security Compliance: Surviving Schrems II with OpenSCAP and Ansible in Norway

If you are still managing infrastructure compliance using Excel spreadsheets and manual checklists, you are not just inefficient—you are a liability. In the wake of the Schrems II ruling, the "wait and see" approach to data sovereignty effectively died. For CTOs and Systems Architects operating in Norway and the broader EEA, the mandate is clear: ensure strict isolation, validate configuration continuously, and keep personal data out of US-controlled cloud silos.

Compliance isn't a quarterly event. It is a continuous state of being.

In this guide, we aren't discussing abstract policies. We are going to build a compliance automation pipeline using OpenSCAP and Ansible on AlmaLinux 8 (a solid CentOS alternative in 2022). We will demonstrate how to enforce CIS Level 1 benchmarks automatically, ensuring your infrastructure on CoolVDS is harder than a frozen fjord.

The "Excel Hell" vs. Infrastructure as Code

The traditional audit model is broken. You deploy a server, a consultant runs a scan, you patch it, and five minutes later a developer changes an SSH config, rendering the audit obsolete. This drift is fatal.

Pro Tip: Compliance as Code means your infrastructure defines its own legal adherence. If the config drifts, the code corrects it automatically. No human intervention required.

In the Norwegian context, strict adherence to Datatilsynet guidelines often requires evidence that you have control over where your data lives and how it is accessed. This is why we advocate for KVM-based virtualization (standard on CoolVDS) over container-based shared kernels for sensitive workloads. You need that hard hardware interrupt boundary.

Step 1: The Baseline – CIS Benchmarks

The Center for Internet Security (CIS) benchmarks are the gold standard. But reading a 400-page PDF is not a strategy. We need to verify these checks programmatically. We utilize the OpenSCAP ecosystem, specifically the Security Content Automation Protocol.

First, install the necessary tools on your server:

dnf install openscap-scanner scap-security-guide -y

Now, let's assess the current state of a fresh VPS against the CIS Server Level 1 profile. Be warned: a standard install will likely fail 40% of these checks. That is normal.

oscap xccdf eval \
 --profile xccdf_org.ssgproject.content_profile_cis \
 --results /var/www/html/scan-report.xml \
 --report /var/www/html/scan-report.html \
 /usr/share/xml/scap/ssg/content/ssg-almalinux8-ds.xml

This command generates an HTML report showing exactly where you fail: weak password policies, open ports, or unsafe kernel parameters.

Step 2: Hardening the Kernel with Ansible

Identifying the problem is half the battle. Fixing it at scale is the other half. We don't manually edit /etc/sysctl.conf anymore. We use Ansible to enforce state.

Below is a snippet from a production Ansible playbook tailored for high-security environments. This specifically addresses network stack hardening—critical for preventing Man-in-the-Middle (MitM) and IP spoofing attacks.

---
- name: Apply CIS Kernel Hardening
  hosts: coolvds_instances
  become: yes
  tasks:
    - name: Ensure IP forwarding is disabled
      sysctl:
        name: net.ipv4.ip_forward
        value: '0'
        state: present
        reload: yes

    - name: Ensure packet redirect sending is disabled
      sysctl:
        name: net.ipv4.conf.all.send_redirects
        value: '0'
        state: present
        reload: yes

    - name: Ensure ICMP redirects are not accepted
      sysctl:
        name: net.ipv4.conf.all.accept_redirects
        value: '0'
        state: present
        reload: yes

    - name: Enable RFC 1337 - Protect against TCP time-wait assassination
      sysctl:
        name: net.ipv4.tcp_rfc1337
        value: '1'
        state: present
        reload: yes

Running this playbook ensures that even if a junior admin accidentally changes a setting, the next Ansible run resets it to the compliant state. Idempotency is your best friend.

Step 3: SSH Configuration & Access Control

The most common attack vector remains SSH. Bruteforce bots scan the entire IPv4 range of Norwegian data centers daily. If you are using password authentication, you are already compromised; you just don't know it yet.

Here is the requisite configuration for /etc/ssh/sshd_config. Do not compromise on these settings.

PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding no
PrintMotd no
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
# Ciphers hardening
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

The Hardware Reality: Why Virtualization Matters

Software automation is powerful, but it relies on the integrity of the underlying hardware. This is where the choice of hosting provider becomes a security decision, not just a procurement one.

Many budget providers use container virtualization (LXC/OpenVZ) where the kernel is shared among tenants. If a kernel-level exploit (like