Automating the GDPR Headache: Compliance as Code in a Post-May 25th World

We survived May 25th. The flood of "We've updated our Privacy Policy" emails has finally subsided. But if you are a CTO or Lead Systems Architect operating in Norway, you know the silence is deceptive. The implementation of the General Data Protection Regulation (GDPR) into the Norwegian personopplysningsloven didn't just add paperwork; it fundamentally changed how we must architect infrastructure.

The days of manual "hardening checklists" saved in an Excel sheet are over. You cannot prove continuous compliance to Datatilsynet (The Norwegian Data Protection Authority) with a spreadsheet from three months ago. If you are still manually editing /etc/ssh/sshd_config, you are already non-compliant because you lack reproducibility.

This is where Compliance as Code enters the conversation. We need to define our security posture in code, apply it automatically, and audit it continuously.

The Architecture of Trust: Start at the Kernel

Before we talk about automated tools, we have to talk about the substrate. If your underlying virtualization technology is leaky, no amount of software patching will save you. This is why, when we architect solutions at CoolVDS, we strictly utilize KVM (Kernel-based Virtual Machine) rather than container-based virtualization like OpenVZ for our secure instances.

In a shared kernel environment (containers), a kernel panic in a neighbor's instance can theoretically affect you. With KVM, you have a hardware-assisted virtualization boundary. For GDPR compliance, this isolation is a critical argument when documenting technical measures for data protection.

Phase 1: Automated Hardening with Ansible

Consistency is the enemy of risk. We use Ansible because it is agentless and human-readable. In 2018, Ansible 2.5 gives us robust modules to enforce state. Here is a battle-tested snippet we use to harden the SSH daemon on our Ubuntu 18.04 LTS nodes immediately after provisioning.

This playbook ensures that the root user cannot log in and that password authentication is disabled in favor of SSH keys. This is the absolute baseline for any VPS in Norway exposed to the public internet.

---
- hosts: secure_nodes
  become: yes
  tasks:
    - name: Ensure SSH Protocol is set to 2
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^Protocol'
        line: 'Protocol 2'
        state: present

    - 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 Max Auth Tries
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^MaxAuthTries'
        line: 'MaxAuthTries 3'
        state: present

    - name: Restart SSHD
      service:
        name: sshd
        state: restarted

Phase 2: Continuous Auditing with OpenSCAP

Applying configuration is half the battle. Verifying it is the other half. How do you prove to an auditor that your server was secure at 03:00 AM on a Tuesday? You use OpenSCAP.

The Security Content Automation Protocol (SCAP) allows us to scan servers against standard security profiles (like PCI-DSS or STIG). For a standard Linux box, using the Common Configuration Scored Benchmark is a good starting point.

First, install the necessary tooling on your CentOS 7 or Ubuntu 18.04 instance:

# On Ubuntu 18.04
sudo apt-get update
sudo apt-get install libopenscap8 scap-security-guide

# On CentOS 7
sudo yum install openscap-scanner scap-security-guide

Once installed, do not just run it once. Cron it. Here is how you run a scan and generate a human-readable HTML report that you can archive for your records:

oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_standard \
  --results-arf /var/log/scap/results.xml \
  --report /var/www/html/compliance_report.html \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu1804-ds.xml

If you see a fail in that report, your CI/CD pipeline should break. That is the level of discipline required post-2018.

Pro Tip: Do not expose the report HTML file to the public internet. Restrict access to your office IP range using Nginx or Apache allow/deny rules. It contains a roadmap of your vulnerabilities.

Phase 3: The Transport Layer (Nginx & SSL)

GDPR Article 32 explicitly mentions "encryption of personal data." If you are serving content over HTTP, you are negligent. But even HTTPS isn't enough if your cipher suites are from 2014. With the vulnerabilities found in older protocols, TLS 1.0 and 1.1 should be considered deprecated for secure environments.

We configure our Nginx edge nodes to strictly prefer TLS 1.2. While TLS 1.3 is currently in draft (draft-28 as of writing), it is not yet stable enough for enterprise production enforcement without risks of client incompatibility.

Here is the nginx.conf snippet we recommend for achieving an A+ rating on Qualys SSL Labs:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    
    # Certs provided by Let's Encrypt
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Modern SSL parameters for 2018
    ssl_protocols TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers on;
    
    # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
    add_header Strict-Transport-Security "max-age=15768000; includeSubDomains" always;
    
    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;
}

The Jurisdiction Trap: The US CLOUD Act

Technical implementation is only one pillar of compliance. The other is legal jurisdiction. In March 2018, the US passed the CLOUD Act (Clarifying Lawful Overseas Use of Data Act). This law allows US federal law enforcement to compel US-based technology companies to provide requested data stored on servers, regardless of whether the data is stored within the US or on foreign soil.

This creates a massive conflict for Norwegian businesses. If you host your customer data on AWS or Google Cloud, even in their Frankfurt or London regions, that data is arguably subject to US warrant access. This puts you in a difficult position regarding GDPR safeguards against third-party access.

Why Sovereignty Matters

At CoolVDS, we own our hardware in Oslo. We are a Norwegian entity. Your data stays under Norwegian jurisdiction. For sectors like healthcare, finance, or public sector consulting, this distinction is not just a feature—it is a legal necessity.

Performance Meets Compliance

Security often comes with a performance tax. Encryption consumes CPU cycles; complex firewalls add latency. This is why underlying hardware matters. We have moved entirely to NVMe storage for our high-performance tiers. In our benchmarks, NVMe drives handle the I/O overhead of heavy database logging (required for audit trails) roughly 6x faster than standard SATA SSDs.

When you enable auditd logging on Linux to track every file access for compliance, standard SSDs choke. NVMe drives don't blink. We combine this with 10Gbps uplinks to ensuring that while your security is heavy, your user experience remains light.

Conclusion

The post-GDPR world requires a shift in mindset. We must move from "is it secure?" to "is it verifiable?". By automating your baseline hardening with Ansible and validating it with OpenSCAP, you turn compliance from a yearly panic into a daily routine.

But software automation needs a solid home. Don't build a compliant castle on shifting sand. Ensure your data resides on hardware that respects your sovereignty and delivers the IOPS required for modern encryption.

Ready to audit your infrastructure? Spin up a dedicated KVM instance on CoolVDS today. We offer a 100% SLA on power and network, and your data never leaves Norway.