Automating Sovereignty: Hardening Linux Infrastructure for GDPR & CIS Compliance

There is a specific kind of dread that sets in when you receive an email from Datatilsynet (The Norwegian Data Protection Authority). It’s not the panic of a DDoS attack—that’s just adrenaline and iptables. It’s the slow, crushing weight of bureaucracy and liability.

In 2024, if you are manually hardening your servers, you are already non-compliant. Configuration drift is real. A developer enables password authentication for "just a quick test," forgets to disable it, and suddenly your perfectly compliant node is a liability. I’ve seen production environments fail audits because of a single unchecked `chrony` configuration.

This isn't about ticking boxes. It's about building a fortress that rebuilds itself. Here is how we automate security compliance on CoolVDS instances using Ansible and OpenSCAP, ensuring your infrastructure stays within the strict boundaries of Norwegian and EU regulations.

The "Schrems II" Reality Check

Before touching a single config file, we need to address the physical layer. After the Schrems II ruling, relying on US-owned cloud providers for processing Norwegian citizen data is a legal minefield. Standard Contractual Clauses (SCCs) are often not enough.

Architect's Note: Compliance starts at the metal. If your hypervisor is managed by a US entity, you are subject to the CLOUD Act. We built CoolVDS on purely Norwegian infrastructure. Your data sits on NVMe drives in Oslo, not a cached edge node in Virginia. That is your legal bedrock.

Step 1: The Baseline – CIS Benchmarks

The Center for Internet Security (CIS) benchmarks are the gold standard. For a standard Ubuntu 22.04 or 24.04 LTS server, there are over 200 specific configuration checks. Doing this manually is insanity.

We use OpenSCAP to assess the current state of a system against these benchmarks. First, install the necessary tooling on your CoolVDS instance:

sudo apt-get update
sudo apt-get install libopenscap8 libscap-security-guide -y

Now, run a scan against the CIS profile. Note: In 2024, Ubuntu 24.04 support in standard SCAP guides is stabilizing, but 22.04 is rock solid.

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

This command generates an HTML report. When you run this on a fresh, unoptimized VPS from a budget provider, you will likely see a score of roughly 40%. On a CoolVDS instance, we pre-harden the base templates, but application-level compliance is on you.

Step 2: Automating Remediation with Ansible

Scanning is useless without remediation. We don't fix things by hand; we write code. Below is a snippet of a hardened Ansible role designed to enforce SSH security, a critical component of CIS Level 1.

The sshd_config Enforcer

- name: Secure SSH Configuration
  hosts: all
  become: yes
  tasks:
    - name: Ensure SSH Protocol 2 is enforced
      lineinfile:
        path: /etc/ssh/ssd_config
        regexp: '^Protocol'
        line: 'Protocol 2'
        state: present
        validate: 'sshd -t -f %s'

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

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

    - name: Set Idle Timeout Interval
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^ClientAliveInterval'
        line: 'ClientAliveInterval 300'
        state: present

  handlers:
    - name: restart_sshd
      service:
        name: sshd
        state: restarted

Notice the validate argument. This prevents you from locking yourself out if the config syntax is invalid. It’s a small detail that saves you a trip to the KVM console.

Step 3: Auditd and Immutable Logs

GDPR requires accountability. If a breach happens, you must know exactly what files were touched. The Linux Audit Daemon (`auditd`) is your flight recorder. By default, it’s often too quiet.

Here is a production-grade audit.rules configuration for monitoring access to critical files (like /etc/passwd) and file deletion events.

# /etc/audit/rules.d/audit.rules

# Remove any existing rules
-D

# Buffer Size
-b 8192

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

# Watch critical files for write/attr changes
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k identity

# Monitor file deletions by users
-a always,exit -F arch=b64 -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete

Combine this with a remote log shipper. On CoolVDS, we recommend isolating your logging server on a private VLAN. This ensures that even if a web node is compromised, the attacker cannot wipe the logs that incriminate them.

Performance vs. Security: The Trade-off

Security adds overhead. Running `auditd` with aggressive rules can consume CPU cycles. On a standard HDD VPS, high I/O wait times from logging can kill your application performance. This is why underlying hardware matters.

Implementation Strategy

Do not apply these rules blindly to production. Here is the workflow I use for high-stakes Norwegian fintech clients:

1. Spin up a Staging CoolVDS instance. It takes less than 60 seconds.
2. Run the Ansible Hardening Playbook.
3. Execute the OpenSCAP scan. Verify the score moves from 40% to >90%.
4. Load Test. Ensure `auditd` isn't choking your database I/O.
5. Promote to Production.

Compliance is a continuous loop, not a destination. By automating it, you transform it from a quarterly nightmare into a daily routine.

Ready to build infrastructure that keeps the auditors happy and your data in Norway? Deploy a hardened test instance on CoolVDS today and see the difference dedicated NVMe performance makes.