Surviving the May Deadline: Automating GDPR Compliance on Norwegian VPS Infrastructure

It is March 30, 2018. We are less than two months away from the implementation of the General Data Protection Regulation (GDPR). If you are a CTO or Systems Architect operating in Europe, you are likely staring at a spreadsheet of assets that need to be audited, hardened, and documented. And if you are still relying on manual checklists to secure your servers, you are already behind.

The days of "security through obscurity" are over. With the Datatilsynet (Norwegian Data Protection Authority) gearing up to enforce strict data handling rules, the only way to ensure consistent compliance without hiring an army of sysadmins is via Infrastructure as Code (IaC).

I have seen too many engineering teams fail audits because a junior developer manually deployed a server and forgot to disable password authentication or left a database port open to the public internet. In a post-GDPR world, that is not just a mistake; it is a potential 4% global turnover fine.

This guide focuses on automating security baselines on CentOS 7 and Ubuntu 16.04 LTS systems—the workhorses of the current web—ensuring that your VPS Norway infrastructure is compliant by design.

The Foundation: Isolation Matters

Before writing a single line of automation code, we must address the substrate. Compliance requires strict data isolation. In the budget hosting market, many providers use container-based virtualization (like OpenVZ) where the kernel is shared. If a kernel exploit hits the host, every tenant is compromised.

Architect's Note: For GDPR compliance, I strongly advise against shared-kernel virtualization for processing PII (Personally Identifiable Information). You need hardware-level virtualization. This is why CoolVDS exclusively uses KVM (Kernel-based Virtual Machine). It ensures that your memory, CPU, and disk operations are strictly isolated from "noisy neighbors" and other tenants. It provides the boundary required for a defensible compliance posture.

Step 1: The "Zero-Touch" Hardening Strategy

We cannot rely on humans to remember to edit /etc/ssh/sshd_config. We use Ansible (currently version 2.4/2.5) to enforce state. Whether you spin up one instance or one hundred, the security posture must be identical.

Here is a production-grade Ansible task list to secure the SSH daemon. This effectively kills brute-force attacks and satisfies the requirement for "access control" under GDPR Article 32.

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

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

    - name: "Security: Ensure Protocol 2 is enforced"
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^Protocol'
        line: 'Protocol 2'
        state: present
      notify: Restart SSH

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

Deploying this ensures that even if a password leaks, an attacker cannot log in without the private key. On high-performance NVMe storage instances like those at CoolVDS, these playbooks execute in seconds, allowing for rapid remediation.

Step 2: Automated Firewalling

Leaving ports open is negligence. On CentOS 7, we rely on firewalld. On Ubuntu, ufw. Do not disable these services. Configure them.

Below is a bash script often used in user-data or post-install scripts to set a baseline "Default Deny" policy immediately upon server provisioning. This is crucial when you have low latency connectivity to the NIX (Norwegian Internet Exchange)—speed is great for users, but also great for scanners.

#!/bin/bash
# Basic IPtables hardening for a Web Server

# Flush existing rules
iptables -F

# Set default policies to DROP
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Allow loopback
iptables -A INPUT -i lo -j ACCEPT

# Allow established connections (keep your SSH session alive!)
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow SSH, HTTP, HTTPS
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Save rules (CentOS/RHEL style)
service iptables save

echo "Firewall locked down."

Step 3: Continuous Auditing with OpenSCAP

Documentation is the hardest part of an audit. "Prove your systems are patched." Screenshots don't cut it. In 2018, the industry standard for Linux security automation is the OpenSCAP ecosystem using the XCCDF (Extensible Configuration Checklist Description Format) standard.

You can verify your CoolVDS instance against the Common Industry Security Benchmarks (CIS) or Red Hat security profiles automatically.

Installing OpenSCAP on CentOS 7:

yum install openscap-scanner scap-security-guide -y

Running a Compliance Scan:

This command checks the system against a standard security profile and generates an HTML report you can hand directly to an auditor.

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

If you see red failures in that report, you have work to do. Often, failures relate to partition mounting options (e.g., /tmp not having noexec). Addressing these at the partition level is much easier when you control the full KVM instance rather than a limited container.

Data Residency and Legal Latency

Technology is only half the battle. The physical location of your data is the other.

For Norwegian businesses, hosting data inside the country simplifies the legal argument significantly. You do not need to worry about the complexities of Trans-Atlantic data flows if the data never leaves Oslo.

Performance vs. Encryption

A common objection to full-disk encryption (required for strict compliance in some sectors) is the performance penalty. This was true on spinning rust (HDD). However, in 2018, with the adoption of AES-NI instruction sets in modern CPUs and NVMe storage, the overhead is negligible.

At CoolVDS, we see less than 3% CPU overhead for LUKS encryption on our standard instances. There is no excuse for storing sensitive data in plain text.

Benchmarking Encrypted I/O

If you want to verify the speed impact yourself, use dd with the oflag=direct parameter to bypass cache and test raw throughput on your encrypted volume:

dd if=/dev/zero of=/encrypted_vol/testfile bs=1G count=1 oflag=direct

On a standard CoolVDS instance, you should still see write speeds exceeding 400-500 MB/s, even with encryption enabled. This allows high-traffic databases to remain compliant without becoming sluggish.

Summary: The Audit is Coming

May 25, 2018 is a hard deadline. You cannot manually patch your way to safety. By leveraging Ansible for configuration management, OpenSCAP for continuous auditing, and KVM-based infrastructure for isolation, you turn compliance from a panic-induced nightmare into a documented engineering process.

Security is not a product; it is a process. But that process runs faster on the right hardware.

Is your infrastructure ready for the Datatilsynet? Spin up a compliant-ready KVM instance on CoolVDS today and run your first OpenSCAP scan in under 5 minutes.