Console Login

Automating CIS & GDPR Compliance in a Post-Schrems II World: A DevOps Survival Guide

The "Schrems II" Hangover: Why Your Compliance Strategy Is Likely Broken

It has been five months since the CJEU (Court of Justice of the European Union) dropped the Schrems II ruling, and the panic in the Norwegian tech sector hasn't settled. If you are still relying on the Privacy Shield framework to justify sending data to US-owned hyperscalers, stop. You are exposing your organization to massive liability. The Datatilsynet (Norwegian Data Protection Authority) is not known for its leniency regarding data transfers to jurisdictions with conflicting surveillance laws.

But let's put the legal text aside. I am an engineer, not a lawyer. My job—and yours—is to architect systems that are secure by design and compliant by default. In December 2020, manual checklists are dead. If you cannot audit your infrastructure with a script, you don't have infrastructure; you have a pet project.

This guide covers how to automate security compliance using the Center for Internet Security (CIS) benchmarks on Ubuntu 20.04 LTS and CentOS 7, specifically tailored for hosting environments where data sovereignty is non-negotiable.

1. The Foundation: CIS Benchmarks via Ansible

Compliance isn't about buying a firewall; it's about configuring your OS to be hostile to intruders. The CIS Benchmarks provide the gold standard. However, the PDF is 800 pages long. We automate this.

I recently worked with a fintech startup in Oslo that failed an audit because a junior dev left port 22 open to the world on a test server. We fixed this by enforcing a hardening role that runs on every boot.

Here is a snippet of an Ansible task that enforces SSH hardening, a critical requirement for CIS Level 1:

# roles/security/tasks/sshd.yml
- name: Ensure SSH Protocol 2 is set
  lineinfile:
    path: /etc/ssh/sshd_config
    regexp: '^Protocol'
    line: 'Protocol 2'
    state: present

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

- name: Ensure SSH MaxAuthTries is set to 4 or less
  lineinfile:
    path: /etc/ssh/sshd_config
    regexp: '^MaxAuthTries'
    line: 'MaxAuthTries 4'
    state: present
  notify: restart sshd
Pro Tip: Don't just apply these blindly. If you are using a provider with a VNC console (like the HTML5 console in the CoolVDS dashboard), ensure you have a fallback user with sudo access before disabling root login, or you will lock yourself out. I've seen it happen too many times.

2. Kernel Hardening: Stopping Attacks Before They Start

Application firewalls are great, but kernel-level hardening is better. Network stack tuning prevents IP spoofing and Man-in-the-Middle (MITM) attacks. This is often overlooked in basic VPS setups.

On a high-performance CoolVDS NVMe instance, we recommend applying these sysctl settings to harden the network stack without sacrificing throughput. Add these to /etc/sysctl.conf:

# /etc/sysctl.conf

# IP Spoofing protection
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Ignore ICMP broadcast requests
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Disable source packet routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

# Log Martians
net.ipv4.conf.all.log_martians = 1

Run sysctl -p to apply. These settings mitigate DDoS amplification vectors, which is crucial if you aren't hiding behind a massive scrubbing center. While CoolVDS includes standard DDoS protection, local mitigation reduces noise.

3. Automated Auditing: OpenSCAP

You applied the config. Great. How do you prove it to the auditor? Screenshots? Please.

Use OpenSCAP. It's open-source, standard-compliant, and available in the repositories of major distros. It compares your system against the XCCDF (eXtensible Configuration Checklist Description Format) profile.

Here is how to run a scan on Ubuntu 20.04:

sudo apt-get update && sudo apt-get install libopenscap8 ssg-base ssg-deb ssg-utils -y

# Run the scan against the CIS Level 1 Server profile
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

This generates an HTML report showing exactly where you pass and fail. Green is good. Red means work.

4. The Data Sovereignty Argument (Why Hardware Matters)

Software compliance is useless if the physical disk resides in a jurisdiction that legally mandates backdoor access. This is the crux of the Schrems II decision.

When you deploy on a CoolVDS instance, your data sits on NVMe storage physically located in our Oslo data center. We are a Norwegian company. We answer to Norwegian courts. There is no murky legal chain that allows a foreign agency to subpoena your database without going through proper diplomatic channels.

Furthermore, we use KVM (Kernel-based Virtual Machine) virtualization. Unlike container-based virtualization (like OpenVZ/LXC), KVM provides a higher degree of isolation. Your kernel is your kernel. This is vital for security compliance.

Comparison: KVM vs. Containers for Compliance

Feature KVM (CoolVDS Standard) OpenVZ / LXC
Kernel Isolation Complete (Own Kernel) Shared (Host Kernel)
SELinux/AppArmor Full Control Limited/Restricted
Swap Access Dedicated Often Shared/Burstable

5. Monitoring File Integrity

Finally, we need to know if something changes. auditd is the Linux Audit Daemon. It hooks into the kernel and watches system calls. For GDPR compliance, you must know who accessed sensitive data and when.

Add these rules to /etc/audit/rules.d/audit.rules to monitor changes to the user database and network config:

# Monitor changes to /etc/passwd
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/gshadow -p wa -k identity

# Monitor changes to network configuration
-w /etc/hosts -p wa -k system-locale
-w /etc/network/ -p wa -k system-locale

# Lock the configuration
-e 2

Restart the daemon with service auditd restart. Now, any attempt to write to these files is logged.

Summary: Compliance is a Process, Not a Product

Recent events—specifically the turmoil with CentOS 8 (announced just days ago) and the Schrems II fallout—have shown us that stability and sovereignty are rare commodities. Relying on default configurations or foreign cloud giants is a risk strategy, not an IT strategy.

By combining rigorous Ansible automation, OpenSCAP auditing, and the physical security of Norwegian-based VPS Norway infrastructure, you build a fortress. It doesn't matter how fast your NVMe storage is (and on CoolVDS, it is incredibly fast) if your server is compromised.

Ready to audit your stack? Spin up a fresh, isolated KVM instance on CoolVDS today. Our low latency network ensures your management tools run instantly, and our Oslo location keeps the lawyers happy.