Surviving Schrems II: Automating Infrastructure Compliance in a Post-Privacy Shield World

If the recent ruling by the Austrian Data Protection Authority (DSB) regarding Google Analytics didn't wake you up, nothing will. As of January 2022, the message is clear: data transfers to US-controlled providers—even those with "regions" in Europe—are radioactive under GDPR. For CTOs operating in Norway and the broader EEA, the era of "trust us, we have a DPA" is over.

We are now in the age of Schrems II enforcement. The legal department is panic-calling the engineering team, asking where the data actually lives. If your answer relies on a US hyperscaler subject to the CLOUD Act, you have a problem that a lawyer cannot fix.

But migration to sovereign infrastructure is only half the battle. The other half is proving that your local environment is hardened, monitored, and compliant. You cannot achieve this with Excel spreadsheets and manual checklists. You need Compliance as Code.

The Myth of Manual Hardening

In a traditional setup, a sysadmin spins up a VPS, manually edits /etc/ssh/sshd_config, configures iptables, and perhaps installs Fail2Ban. This works for day one. By day one hundred, configuration drift has set in. Someone opened a port for debugging and forgot to close it. A kernel update reverted a sysctl flag.

On CoolVDS NVMe instances, we see this constantly. Customers deploy powerful hardware but leave the software layer wide open. Compliance is not a state; it is a continuous loop. To survive a Datatilsynet audit, you must automate the hardening process and the verification of that hardening.

Step 1: The Baseline (CIS Benchmarks)

We don't guess what secure looks like. We use the Center for Internet Security (CIS) benchmarks. For an Ubuntu 20.04 LTS server (the current standard for stability), there are hundreds of checks.

Let's look at a typical kernel hardening requirement. You need to disable IP forwarding and redirects to prevent man-in-the-middle attacks.

Manually, you might run:

But this is ephemeral. To make it persistent and audit-proof, we use Ansible.

Step 2: Automating Hardening with Ansible

Below is a production-ready Ansible playbook snippet that enforces critical kernel parameters and SSH configurations. We run this against every fresh CoolVDS deployment to ensure the "clean slate" is actually clean.

---
- name: Hardening Baseline for GDPR Compliance
  hosts: all
  become: yes
  vars:
    sysctl_config:
      - { name: 'net.ipv4.conf.all.accept_redirects', value: '0' }
      - { name: 'net.ipv4.conf.all.send_redirects', value: '0' }
      - { name: 'net.ipv4.ip_forward', value: '0' }
      
  tasks:
    - name: Apply Kernel Security Parameters
      sysctl:
        name: "{{ item.name }}"
        value: "{{ item.value }}"
        state: present
        reload: yes
      loop: "{{ sysctl_config }}"

    - name: Secure SSH Configuration
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: "^{{ item.key }}"
        line: "{{ item.key }} {{ item.value }}"
        validate: '/usr/sbin/sshd -t -f %s'
      loop:
        - { key: 'PermitRootLogin', value: 'no' }
        - { key: 'PasswordAuthentication', value: 'no' }
        - { key: 'X11Forwarding', value: 'no' }
        - { key: 'MaxAuthTries', value: '3' }
      notify: Restart SSH

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

This playbook does not just change settings; it ensures they stay changed. If a junior dev changes PermitRootLogin to yes, the next Ansible run reverts it. That is the definition of control.

Step 3: Continuous Verification with OpenSCAP

Configuring is not enough. You must verify. OpenSCAP is the gold standard for this. It scans your system against the XCCDF (Extensible Configuration Checklist Description Format) profile.

First, install the necessary tools on your server:

Now, we don't just run a generic scan. We run a scan specifically mapping to the CIS Level 1 Server profile. This is crucial for high-security environments like financial services or healthcare data handling in Norway.

#!/bin/bash

# Define the policy profile (CIS for Ubuntu 20.04)
PROFILE="xccdf_org.ssgproject.content_profile_cis_level1_server"
CONTENT="/usr/share/xml/scap/ssg/content/ssg-ubuntu2004-ds.xml"
REPORT_DIR="/var/www/html/security-reports"
DATE=$(date +%F)

# Ensure report directory exists
mkdir -p $REPORT_DIR
chmod 750 $REPORT_DIR

echo "Starting OpenSCAP Audit for $DATE..."

# Run the evaluation
oscap xccdf eval \
  --profile $PROFILE \
  --results $REPORT_DIR/results-$DATE.xml \
  --report $REPORT_DIR/report-$DATE.html \
  $CONTENT

# Simple check for failure count
FAILURES=$(grep -c "fail" $REPORT_DIR/results-$DATE.xml)

if [ "$FAILURES" -gt 0 ]; then
    echo "CRITICAL: Security Audit Failed with $FAILURES errors."
    # In a real setup, integrate this with PagerDuty or Slack
    exit 1
else
    echo "SUCCESS: System is compliant."
fi

Automating this script via Cron creates a daily paper trail. When the auditor asks, "How do you know you were secure on February 14th?", you show them the report generated at 03:00 AM that day.

The Infrastructure Reality Check

You can have the most hardened sysctl.conf in the world, but if your virtualization layer is noisy or your data residency is legally ambiguous, your compliance posture collapses.

Pro Tip: Check your provider's ASN (Autonomous System Number). If the IP ranges belong to a US entity, the CLOUD Act applies regardless of the physical server location. CoolVDS operates under a Norwegian entity with local jurisdiction.

For workloads requiring high-performance I/O—like database clusters handling encrypted personal data—we utilize KVM (Kernel-based Virtual Machine) exclusively. Unlike container-based virtualization (LXC/OpenVZ), KVM provides strict memory and kernel isolation. This prevents "noisy neighbor" attacks and side-channel vulnerabilities, which are becoming increasingly theoretical vectors in multi-tenant environments.

Performance vs. Encryption

A common objection to full-disk encryption (LUKS) is the performance penalty. On legacy spinning rust (HDD), this was true. With the NVMe storage standard on CoolVDS, the overhead is negligible.

To verify the impact of encryption on I/O, you can run a fio test. Here is a command to benchmark random read/write performance, which simulates a transactional database load:

On our infrastructure, you will see tens of thousands of IOPS even with LUKS enabled. Do not sacrifice security for speed; in 2022, you can have both.

Final Thoughts: The Cost of Non-Compliance

The landscape has shifted. The tools we used in 2019 are no longer sufficient for the regulatory environment of 2022. By combining Terraform for provisioning, Ansible for configuration management, and OpenSCAP for continuous auditing, you build a fortress.

But a fortress built on quicksand will still sink. Choosing a hosting partner that understands the nuances of Norwegian data privacy laws and provides the raw power to handle encryption overhead is not optional anymore. It is a due diligence requirement.

Is your infrastructure ready for a Datatilsynet audit? Spin up a compliant, hardened KVM instance on CoolVDS today and keep your data strictly within Norwegian borders.