Automating GDPR Compliance: Surviving Schrems II with Ansible & OpenSCAP

If you are a CTO operating in the EEA right now, the date July 16, 2020, is burned into your memory. That was the day the Court of Justice of the European Union (CJEU) invalidated the Privacy Shield framework in the Schrems II ruling. Suddenly, relying on US-owned cloud providers became a legal minefield. Transferring personal data across the Atlantic is no longer just a technical task; it is a compliance risk that keeps legal teams awake at night.

I recall a specific audit meeting last month with a frantic fintech client in Oslo. They had excellent code quality, but their infrastructure documentation was a mess of PDFs and "gentlemen's agreements." When Datatilsynet (The Norwegian Data Protection Authority) comes knocking, they don't care about your clean Python code. They care about where the data lives and how you prove it is secure.

Compliance cannot be a manual checkbox. Manual audits are slow, expensive, and outdated the moment the auditor leaves the building. The only way to survive strict EU regulations while maintaining velocity is to treat compliance as code.

The Myth of "Set and Forget" Security

Many sysadmins spin up a VPS, run a hardening script, and assume they are secure. This is false. Configuration drift is real. A developer changes a permission to debug an issue at 2 AM, and suddenly your /var/www/html is world-writable, or worse, port 22 is open to the entire internet.

To combat this, we need continuous, automated enforcement. We need to define the desired state of our infrastructure and relentlessly apply it. In 2021, the standard for this is Ansible for remediation and OpenSCAP for auditing.

Step 1: Hardening the Base Image (The Code)

Let's look at a practical example using Ubuntu 20.04 LTS. This is the bedrock of most stable deployments today. We aren't just going to guess what settings to change; we are going to follow the CIS (Center for Internet Security) Benchmark.

First, secure the SSH daemon. This is the front door. Do not leave it ajar.

# /etc/ssh/sshd_config

# Protocol 2 is the only option in 2021. 
Protocol 2

# Disable root login immediately.
PermitRootLogin no

# Password authentication is a relic. Use keys.
PasswordAuthentication no
ChallengeResponseAuthentication no

# Limit who can even attempt to connect
AllowUsers deploy_user

# Disconnect idle sessions to prevent hijacking
ClientAliveInterval 300
ClientAliveCountMax 0

Manually editing files is how mistakes happen. Here is how we enforce this via an Ansible playbook. This task ensures that even if a junior dev enables password auth by mistake, the next playbook run will revert it.

- name: Secure SSH Configuration
  hosts: webservers
  become: yes
  tasks:
    - name: Disable Password Authentication
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^PasswordAuthentication'
        line: 'PasswordAuthentication no'
        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

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

Pro Tip: When using Ansible on CoolVDS instances, utilize the private network interface (often `eth1` or aliased depending on setup) for management traffic. Keep your public interface (`eth0`) strictly for application traffic and SSH via jump host. This segregation satisfies several network security clauses in GDPR article 32.

Step 2: Automated Auditing with OpenSCAP

Hardening is good. Proving it is better. OpenSCAP is an open-source tool that scans your system against a standard profile (like PCI-DSS or CIS) and generates a report.

Install the scanner on your Ubuntu 20.04 node:

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

Now, run a scan against the standard security profile. This command checks your system state against known vulnerabilities and misconfigurations.

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

The output gives you a definitive Pass/Fail for hundreds of checks. You can automate this via a cron job and ship the HTML report to your compliance officer. If a server fails a check, it should be automatically taken out of the load balancer rotation.

Data Sovereignty: The Hardware Layer

Software automation solves the configuration problem. It does not solve the jurisdiction problem. This is where Schrems II hits hard. If you are hosting on a US-controlled cloud (even if the datacenter is in Frankfurt), the US Cloud Act theoretically allows US law enforcement to demand data access.

For Norwegian entities handling sensitive data (health, finance, or personal ID), the safest legal route is Data Sovereignty. This means using a provider owned and operated within the EEA/Norway, subject primarily to local laws.

We built CoolVDS on KVM (Kernel-based Virtual Machine) because it offers true hardware virtualization. Unlike container-based VPS solutions (OpenVZ/LXC), KVM allows us to present a clean block device to your OS. This is critical for encryption.

Full Disk Encryption (LUKS)

To fully satisfy the "encryption at rest" requirement, you should encrypt the partition itself. On a CoolVDS NVMe instance, the I/O overhead of LUKS (Linux Unified Key Setup) is negligible thanks to modern CPU AES-NI instructions.

# Check for AES-NI support on your CPU
grep -m1 -o aes /proc/cpuinfo

If you see `aes` in the output, your compliance overhead is effectively zero. We see thousands of transactions per second on our NVMe arrays with LUKS enabled.

The Economic Argument

Compliance often sounds expensive. But consider the cost of an AWS consultant trying to map US-east-1 services to GDPR constraints versus a simple, compliant-by-design architecture in Oslo. Complexity is the enemy of security.

By combining Ansible for idempotent configuration, OpenSCAP for audit trails, and a sovereign host like CoolVDS, you reduce the scope of your audit significantly. You aren't fighting the infrastructure; you are building on a foundation that is already aligned with your legal reality.

Don't wait for the audit letter to land on your desk. Start hardening your infrastructure today. Deploy a KVM instance on CoolVDS, run the CIS benchmark scan, and sleep better knowing your data is legally and technically secure.