Automating Security Compliance: Surviving Schrems II and Datatilsynet with Infrastructure as Code

If your team is still manually editing /etc/ssh/sshd_config on production servers, you have already lost. In the current regulatory climate—post-Schrems II and with the Norwegian Data Protection Authority (Datatilsynet) becoming increasingly vigilant—security cannot be a manual checklist. It must be code.

I have sat in boardrooms where the panic wasn't about a hack, but about an audit. The fear of a 4% global turnover fine under GDPR is a powerful motivator. But fear doesn't configure firewalls. Engineering does. The problem is simple: Configuration Drift. You deploy a secure server on Day 1. By Day 30, a junior dev has opened a port for debugging. By Day 60, you are non-compliant.

This guide details how to replace hope with automation. We will focus on enforcing CIS Benchmarks and GDPR technical safeguards using Ansible and OpenSCAP, deployed on infrastructure that doesn't legally compromise you.

The Foundation: Data Sovereignty is Not Optional

Before we touch a single line of Python or YAML, we must address the hardware. You can have the most hardened kernel in existence, but if that kernel is running in a data center subject to US surveillance laws (FISA 702), your compliance posture is shaky at best. This is the core of the Schrems II ruling.

For my European clients, I stop recommending US hyperscalers for sensitive PII (Personally Identifiable Information). It creates a legal headache requiring complex Transfer Impact Assessments (TIAs). Hosting in Norway, on a provider like CoolVDS, removes this layer of complexity. Your data stays in Oslo. It stays under Norwegian jurisdiction. The latency to NIX (Norwegian Internet Exchange) is just a nice bonus for performance.

Phase 1: Hardening at Boot with Cloud-Init

Security starts before the OS allows the first login. We use cloud-init to ensure that when a CoolVDS instance spins up, it is already hostile to attackers. Do not rely on default images.

Pro Tip: Never allow password authentication, even for the first login. If you are provisioning a fleet, inject your SSH public keys directly via the cloud provider's API or cloud-init user-data.

Here is a standard user-data configuration we use to lock down a fresh Ubuntu 22.04 LTS instance immediately:

#cloud-config
users:
  - name: deploy
    gecos: Deploy User
    sudo: ALL=(ALL) NOPASSWD:ALL
    shell: /bin/bash
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIK... [YOUR_KEY]

package_update: true
package_upgrade: true

write_files:
  - path: /etc/ssh/sshd_config.d/99-hardened.conf
    content: |
      PermitRootLogin no
      PasswordAuthentication no
      X11Forwarding no
      AllowAgentForwarding no
      KbdInteractiveAuthentication no
      UsePAM yes
      AllowUsers deploy

runcmd:
  - systemctl restart ssh
  - ufw allow 22/tcp
  - ufw allow 80/tcp
  - ufw allow 443/tcp
  - ufw enable

Phase 2: Enforcing State with Ansible

Scripts fail. Playbooks describe a state. We want our infrastructure to be idempotent. If I run this playbook 100 times, the result is the same: a compliant server.

Below is a production-grade Ansible task list for kernel hardening. This modifies sysctl to prevent IP spoofing and Man-in-the-Middle (MitM) attacks. These settings are often required to pass CIS Level 1 benchmarks.

---
- name: Harden Network Stack via Sysctl
  hosts: production
  become: yes
  tasks:
    - name: Set kernel hardening parameters
      ansible.posix.sysctl:
        name: "{{ item.key }}"
        value: "{{ item.value }}"
        state: present
        reload: yes
      loop:
        - { key: 'net.ipv4.conf.all.accept_redirects', value: '0' }
        - { key: 'net.ipv4.conf.default.accept_redirects', value: '0' }
        - { key: 'net.ipv4.conf.all.secure_redirects', value: '0' }
        - { key: 'net.ipv4.conf.all.send_redirects', value: '0' }
        - { key: 'net.ipv4.conf.all.log_martians', value: '1' }
        - { key: 'net.ipv6.conf.all.disable_ipv6', value: '1' } # Unless strictly needed
        - { key: 'kernel.randomize_va_space', value: '2' }      # ASLR

This isn't just about checking boxes. Disabling ICMP redirects prevents routing table corruption. Logging martians helps you detect spoofing attempts early. On high-performance NVMe storage instances like those at CoolVDS, logging overhead is negligible, so turn it on.

Phase 3: Automated Auditing with OpenSCAP

You have hardened the server. How do you prove it to an auditor? You don't want to take screenshots of config files. You need an automated report.

OpenSCAP (Security Content Automation Protocol) allows us to scan a system against a standard profile (like PCI-DSS or CIS). In 2023, the usg (Ubuntu Security Guide) wrapper makes this trivial on Ubuntu systems.

Installing and Running a Scan

sudo apt-get update
sudo apt-get install usg

# Audit against the CIS Level 1 Server profile
sudo usg audit cis_level1_server

# Generate an HTML report for your Compliance Officer
sudo usg report > /var/www/html/audit-report.html

This command generates a granular HTML report highlighting exactly which rules passed and which failed. You can attach this artifact to your deployment pipeline. If the score drops below 95%, fail the build.

The NVMe Factor in Security

Security scanning is I/O intensive. Running ClamAV scans, OpenSCAP audits, and log analysis (ELK stack) simultaneously can crush a standard HDD-based VPS. This is where the "Pragmatic CTO" looks at TCO.

Cheap hosting saves $5 a month but costs you hours in engineering time waiting for I/O operations to complete. We benchmarked OpenSCAP scans on CoolVDS NVMe instances versus standard SSD VPS providers. The difference is stark.

Database Encryption & Performance

GDPR Article 32 explicitly mentions encryption. For databases, this means encryption at rest. However, many admins disable it fearing performance degradation.

On modern hardware with AES-NI instruction sets (standard on CoolVDS KVM slices), the overhead is less than 3%. Here is how you enable encryption at rest for MariaDB using the File Key Management plugin. Do not skip this.

[mariadb]
plugin_load_add = file_key_management
file_key_management_filename = /etc/mysql/encryption/keyfile.enc
file_key_management_filekey = FILE:/etc/mysql/encryption/keyfile.key
file_key_management_encryption_algorithm = AES_CTR

innodb_encrypt_tables = FORCE
innodb_encrypt_log = ON
innodb_encrypt_temporary_tables = ON
innodb_buffer_pool_size = 4G # Adjust based on RAM

Conclusion: Compliance is a Process, Not a Destination

The landscape of 2023 demands that we treat infrastructure as a living, breathing legal entity. Relying on manual updates is negligence. By combining the raw I/O performance of CoolVDS with the rigor of Ansible and OpenSCAP, you build a fortress that satisfies both the hackers and the lawyers.

Do not wait for the Datatilsynet letter to arrive. Audit your infrastructure today.

Ready to harden your stack? Deploy a CoolVDS NVMe instance in Oslo now and get root access in under 55 seconds.