Console Login

Automating GDPR Compliance: Surviving Schrems II with IaC and Norwegian Sovereignty

Automating GDPR Compliance: Surviving Schrems II with IaC and Norwegian Sovereignty

Let’s be honest: if you are still manually editing /etc/ssh/sshd_config on your production servers, you are already non-compliant. In the wake of the Schrems II ruling last year, the definition of "safe data" shifted overnight. It is no longer enough to just have a Data Processing Agreement (DPA); you need to prove that technical measures prevent foreign surveillance. For a CTO or Lead Architect in 2021, this is a nightmare scenario where legal ambiguity meets technical debt.

I recently audited a fintech setup in Oslo. They had perfect documentation but their infrastructure was a house of cards hosted on a US-based hyperscaler. The latency to the Norwegian Internet Exchange (NIX) was acceptable, but the legal exposure was catastrophic. The solution wasn't more lawyers. It was Infrastructure as Code (IaC) combined with strict data sovereignty.

Here is how we automate compliance, lock down the OS, and ensure the Datatilsynet (Norwegian Data Protection Authority) doesn't have a reason to fine you 4% of your global turnover.

The "Code-First" Compliance Strategy

Security compliance cannot be a checkbox you tick once a year. It must be a continuous state enforced by code. We use Ansible for configuration management because it is agentless and audits are as simple as reading a YAML file. If a junior dev accidentally opens port 23 (Telnet) on a firewall, Ansible should close it on the next run. Automatically.

1. Hardening the Kernel with Sysctl

A default Linux installation is optimized for compatibility, not security. You need to restrict network stack behavior to prevent man-in-the-middle (MITM) attacks and IP spoofing. Do not do this manually. Deploy this `sysctl` configuration via your provisioning pipeline.

# /etc/sysctl.d/99-security.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

2. SSH: The Front Door Problem

In 2021, password authentication for SSH is negligence. We enforce SSH keys and disable root login immediately. Here is the Ansible task snippet we use for our high-security CoolVDS templates. This ensures that every node you spin up adheres to the policy before it even takes live traffic.

- name: Secure SSH Configuration
  lineinfile:
    path: /etc/ssh/sshd_config
    regexp: "{{ item.regexp }}"
    line: "{{ item.line }}"
    state: present
    validate: 'sshd -t -f %s'
  with_items:
    - { regexp: '^PermitRootLogin', line: 'PermitRootLogin no' }
    - { regexp: '^PasswordAuthentication', line: 'PasswordAuthentication no' }
    - { regexp: '^X11Forwarding', line: 'X11Forwarding no' }
    - { regexp: '^MaxAuthTries', line: 'MaxAuthTries 3' }
  notify: restart ssh
Pro Tip: On a CoolVDS instance running Ubuntu 20.04, always check your `Include /etc/ssh/sshd_config.d/*.conf` directive. Some defaults in the newer OpenSSH versions can override your main config file if you aren't careful.

Continuous Auditing with OpenSCAP

How do you prove to an auditor that your servers are patched? Screenshots? No. You use the Open Security Content Automation Protocol (OpenSCAP). It compares your system against a standard profile (like PCI-DSS or STIG) and generates an HTML report.

Install it on your bastion host:

sudo apt-get install libopenscap8 scap-security-guide

Run a scan against the standard profile:

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

This command checks everything: file permissions, partition mounting options, and package integrity. If you are running this on a sluggish VPS, expect high I/O wait times. This is why we insist on NVMe storage for all CoolVDS instances; compliance scans shouldn't cause your database to timeout.

The Infrastructure Layer: Why Location Matters

You can have the most hardened Nginx config in the world, but if your physical server resides in a jurisdiction subject to the US CLOUD Act, your GDPR compliance is shaky at best. This is the core issue with Schrems II.

When you deploy on CoolVDS, your data sits in a data center in Norway. It is subject to Norwegian law and the EEA agreement. There is no "upstream" provider that can be subpoenaed by a third-party nation without going through local courts.

Comparison: Hyperscaler vs. CoolVDS (Norway)

Feature US Hyperscaler (Frankfurt Region) CoolVDS (Oslo)
CLOUD Act Exposure High (US Parent Company) None (Norwegian Entity)
Latency to Oslo 15-25ms < 2ms
Storage Backend Networked Block Storage (EBS-like) Local NVMe RAID 10
Cost Predictability Complex (Traffic/IOPS fees) Flat Rate

Web Server Security Headers

Finally, your application layer needs to communicate its security requirements to the browser. I still see major Norwegian e-commerce sites missing basic HSTS headers. Do not rely on application logic to handle this; do it at the Nginx level.

server {
    listen 443 ssl http2;
    server_name secure.example.no;

    # Strict Transport Security (HSTS)
    # Enforces HTTPS for 1 year, including subdomains
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # X-Frame-Options to prevent Clickjacking
    add_header X-Frame-Options "SAMEORIGIN" always;

    # Content Security Policy (CSP)
    # Only allow scripts from self and trusted analytics
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://stats.example.com; object-src 'none';" always;

    # Prevent MIME type sniffing
    add_header X-Content-Type-Options "nosniff" always;
}

Performance meets Compliance

Security often comes with a performance tax. Encryption at rest (LUKS) eats CPU cycles. TLS handshakes require computation. Packet inspection adds latency. This is where hardware selection becomes critical. Running these security layers on shared, oversold legacy hardware results in a sluggish experience.

We built CoolVDS on KVM virtualization to ensure strict resource isolation. When you enable LUKS encryption on our NVMe drives, the I/O overhead is negligible because the underlying throughput is massive. You don't have to choose between a fast site and a legal site.

If you are navigating the post-Schrems II landscape, stop worrying about where your data might be physically located. Keep it in Norway, lock it down with Ansible, and sleep better.

Ready to audit your infrastructure? Spin up a CoolVDS instance in Oslo and run your first OpenSCAP scan in under 2 minutes.