Surviving Schrems II: Automating Security Compliance on Sovereign Norwegian Infrastructure

Let’s be honest: July 16, 2020, was a nightmare for every CTO in Europe. When the CJEU invalidated the Privacy Shield (Schrems II), the legal ground beneath our cloud infrastructure crumbled. If you are responsible for data in Norway, the reliance on US-based hyperscalers just went from "standard practice" to "legal liability."

I have spent the last four months sitting in meetings with legal teams and DPOs, debating Standard Contractual Clauses (SCCs). The conclusion is always the same: Data sovereignty is no longer optional.

But moving workloads back to local infrastructure brings back an old ghost: managing compliance at scale. We cannot afford to trade legal safety for operational inefficiency. We need the agility of the cloud with the certainty of Norwegian law. This requires a shift from manual checklists to Compliance as Code.

The Architecture of Trust: Why "Checklist" Security Fails

In the pre-2020 era, a sysadmin would manually harden a server, tick a box in an Excel sheet, and call it GDPR compliant. That doesn't scale. If you are running 50 microservices, manual hardening leads to configuration drift. Inevitably, someone opens a port for debugging and forgets to close it.

To satisfy Datatilsynet (The Norwegian Data Protection Authority), we need continuous proof. We need systems that self-heal. We need to deploy on infrastructure that offers raw, isolated compute—like CoolVDS KVM instances—where we control the entire stack, down to the kernel modules.

Step 1: The Base Layer (Hardening SSH)

Let's start with the basics. Whether you are running CentOS 8 or Ubuntu 20.04, the default SSH configuration is too permissive. We don't fix this by hand. We fix it with Ansible.

Here is a snippet from our standard hardening playbook. This isn't just about security; it's about uniformity across your fleet.

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

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

    - name: Ensure SSH Protocol 2 Only
      lineinfile:
        path: /etc/ssh/sshd_config
        line: 'Protocol 2'
        create: yes

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

Pro Tip: Never deploy a production VPS without SSH keys. At CoolVDS, we inject your public keys via cloud-init during the provisioning phase, which takes about 55 seconds. This means the root password vector effectively never exists on the public internet.

Step 2: Automated Auditing with OpenSCAP

Hardening is the action; auditing is the proof. For this, OpenSCAP is the industry standard (NIST certified). It allows us to scan our servers against the CIS (Center for Internet Security) Benchmarks automatically.

You don't need expensive proprietary software. You can install this right now on your CoolVDS instance:

# On CentOS 8 / RHEL 8
sudo dnf install openscap-scanner scap-security-guide

# List available profiles
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

Once installed, you can run a scan that generates an HTML report. This report is what you hand to your auditor when they ask if your systems are patched and configured correctly.

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-rhel8-ds.xml

This command checks hundreds of parameters: partition mounting options, permission bits on critical files, and kernel parameters. If you run this on a standard, unoptimized VPS from a budget provider, you will see a sea of red. On a properly managed infrastructure, it acts as a regression test for your security posture.

Step 3: Network Level Compliance (Nginx Hardening)

Compliance isn't just about the OS; it's about data in transit. GDPR requires "state of the art" protection. In 2020, that means perfect implementation of TLS 1.3 and HSTS.

Here is the Nginx configuration block we use to ensure an A+ rating on SSL Labs. Note the emphasis on Strict-Transport-Security.

server {
    listen 443 ssl http2;
    server_name secure.coolvds-client.no;

    ssl_certificate /etc/letsencrypt/live/domain/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/domain/privkey.pem;
    
    # Modern SSL configuration (2020 standards)
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;

    # Security Headers
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    add_header X-Frame-Options SAMEORIGIN;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    
    # ... rest of config
}

Data Sovereignty: The Norwegian Advantage

Technology is only half the battle. The physical location of the hardware determines the legal jurisdiction. This is where the "Pragmatic CTO" looks at the map, not just the spec sheet.

Hosting data in Frankfurt or Dublin on a US-owned cloud provider exposes you to the US Cloud Act, regardless of GDPR. By utilizing infrastructure owned and operated in Norway—like CoolVDS—you add a layer of legal insulation. Your data stays under Norwegian jurisdiction.

Performance vs. Compliance?

There is a misconception that local hosting means sacrificing performance. That might have been true five years ago, but not today. With NVMe storage becoming standard, local VPS performance often exceeds the IOPS limits throttled by major cloud providers.

Automating the Remediation

Finding problems is good; fixing them automatically is better. We can use a simple Bash script hooked into Cron to check for file integrity changes—a requirement for many banking standards.

#!/bin/bash
# Simple integrity checker script
# Date: Nov 2020

CHECKSUM_FILE="/var/log/sys_checksums.sha256"
TARGET_DIR="/etc/nginx"

# Generate current checksums
find $TARGET_DIR -type f -exec sha256sum {} \; | sort > /tmp/current_checksums.sha256

if [ ! -f $CHECKSUM_FILE ]; then
    echo "First run. Storing baseline."
    cp /tmp/current_checksums.sha256 $CHECKSUM_FILE
else
    DIFF=$(diff $CHECKSUM_FILE /tmp/current_checksums.sha256)
    if [ "$DIFF" != "" ]; then
        echo "ALERT: Configuration drift detected!"
        echo "$DIFF" | mail -s "Security Alert: Nginx Config Changed" sec-ops@yourdomain.no
    fi
fi

This is crude but effective. For larger environments, we would pipe this into an ELK stack, but the principle remains: Trust nothing, verify everything.

Conclusion

The regulatory landscape in late 2020 is unforgiving. The "move fast and break things" era is being replaced by "move fast and document everything." Automation allows you to do both.

By combining Ansible for consistency, OpenSCAP for verification, and sovereign infrastructure for legal safety, you build a platform that pleases both the developers and the DPO. You reduce your TCO by avoiding massive compliance fines and ensuring your latency remains low for your Norwegian user base.

Ready to audit your infrastructure? Don't risk your data on uncertain legal grounds. Spin up a compliant, high-performance NVMe instance on CoolVDS today and keep your data right here in Norway.