Console Login

Automating Security Compliance: Surviving Schrems II with Infrastructure as Code

Automating Security Compliance: Surviving Schrems II with Infrastructure as Code

If you are still manually editing /etc/ssh/sshd_config on your production servers, you have already failed the audit. In late 2022, security is not a state; it is a continuous loop of verification. With the Schrems II ruling effectively nuking the Privacy Shield, operating infrastructure in Europe—specifically Norway—has moved from a "nice-to-have" to a legal necessity for handling sensitive user data.

I recently watched a competent DevOps team nearly crumble during a due diligence phase. Their code was clean, but their infrastructure was a drift-ridden mess of "snowflake" servers. They couldn't prove who accessed the database three weeks ago. They couldn't guarantee data residency.

This guide ignores the buzzwords. We are going to look at how to automate compliance using tools available right now—Ansible, OpenSCAP, and strict kernel-level auditing—on a clean KVM stack.

The "Trust Nothing" Architecture

Compliance begins at the bare metal. Before we even touch automation, we must define the environment. Shared hosting or container-based VPS solutions (like OpenVZ) often share kernel space. This is a non-starter for strict isolation requirements.

We strictly utilize KVM (Kernel-based Virtual Machine) virtualization. It provides true hardware virtualization, meaning your OS kernel is yours alone. This prevents "noisy neighbor" exploits and allows the implementation of custom kernel modules for security monitoring.

Pro Tip: When selecting a provider, ask for the output of virt-what. If it doesn't say kvm, run. At CoolVDS, every instance is KVM by default because we refuse to gamble with tenant isolation.

Step 1: The Hardened Base (CIS Benchmarks)

The Center for Internet Security (CIS) benchmarks are the gold standard. Implementing them manually on Ubuntu 22.04 LTS takes hours. Automating them takes seconds.

Here is a snippet from an Ansible playbook we use to enforce SSH hardening. This isn't just about closing ports; it's about forcing cryptographic hygiene.

- name: Secure SSH Configuration
  hosts: production
  become: yes
  tasks:
    - name: Disable Root Login
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^PermitRootLogin'
        line: 'PermitRootLogin no'
        state: present

    - name: Disable Password Authentication
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^PasswordAuthentication'
        line: 'PasswordAuthentication no'
        state: present

    - name: Enforce Protocol 2
      lineinfile:
        path: /etc/ssh/sshd_config
        line: 'Protocol 2'
        state: present

    - name: Set Max Auth Tries
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^MaxAuthTries'
        line: 'MaxAuthTries 3'
        state: present
      notify: Restart SSH

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

This script ensures that even if a junior admin tries to enable password auth for "just a quick fix," the next playbook run will revert it immediately.

Step 2: Immutable Auditing with Auditd

Logs are your legal defense. If Datatilsynet (The Norwegian Data Protection Authority) asks for evidence of a breach investigation, "I think nobody touched that file" is not an acceptable answer.

We use the Linux Audit daemon (auditd) to watch critical system calls. However, standard I/O on spinning disks can choke under heavy audit logging. This is where hardware matters. Running strict audit rules on standard HDDs adds significant wait time (iowait). On CoolVDS NVMe storage, the latency impact is negligible.

Here is a robust /etc/audit/rules.d/audit.rules configuration for watching identity changes:

# Remove any existing rules
-D

# Buffer Size
-b 8192

# Failure Mode (2=shutdown, 1=printk, 0=silent)
-f 1

# Watch /etc/passwd for write/attribute change
-w /etc/passwd -p wa -k identity
-w /etc/group -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 (potential data destruction)
-a always,exit -F arch=b64 -S truncate -S ftruncate -F auid>=1000 -F auid!=4294967295 -k file_modification

Load these rules instantly:

sudo auditctl -R /etc/audit/rules.d/audit.rules

Step 3: Automated Verification with OpenSCAP

You have hardened the system. How do you prove it? OpenSCAP allows you to scan your system against the XCCDF (eXtensible Configuration Checklist Description Format) standard. This is standard procedure for government-grade systems in Europe.

Install the scanner (available in Ubuntu 22.04 repos):

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

Run a compliance scan against the standard profile and generate a report:

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

If you see red on that report, you have work to do.

Data Sovereignty & Network Latency

Technical configuration is only half the battle. The physical location of the bits is the other.

Under GDPR and the interpretations following Schrems II, transferring personal data to jurisdictions without equivalent protections (like the US) is fraught with risk. Using a massive US-based hyperscaler often involves complex Standard Contractual Clauses (SCCs) and Transfer Impact Assessments (TIAs).

Hosting locally simplifies this. A VPS in Norway essentially keeps the data within the EEA framework (Norway is EEA, GDPR applies). Furthermore, for users in Oslo or Stockholm, the physics of routing is undeniable. Routing traffic through Frankfurt or London adds milliseconds. Routing locally keeps it tight.

Metric US Cloud Provider (EU Region) CoolVDS (Oslo/Local)
Ping to Oslo (NIX) ~25-40ms ~2-5ms
Data Jurisdiction US CLOUD Act Risk Norwegian/EEA Law
Storage Backend Networked Block (often throttled) Local NVMe (Direct)

Final Thoughts: The Cost of Non-Compliance

Security automation requires an upfront investment in code and configuration. But the alternative is manual panicked patching at 3 AM or a fine that is 4% of your global turnover.

The stack we discussed—KVM isolation, Ansible enforcement, Auditd logging, and OpenSCAP verification—is not theoretical. It is the baseline for modern hosting. You need a platform that supports this natively, without throttling your I/O when the audit logs start writing fast.

Don't let slow I/O or legal ambiguity kill your project. Deploy a compliant, high-performance test instance on CoolVDS today and see what low latency actually feels like.