Automating the GDPR Nightmare: Security Compliance as Code for Norwegian Infrastructure

It is March 2018. We are roughly two months away from the enforcement of the General Data Protection Regulation (GDPR). If you are still managing server security using Excel spreadsheets and manual checklists, you are already behind. I have seen perfectly good infrastructure teams paralyzed by compliance audits because they treated security as a quarterly event rather than a continuous state.

In the Norwegian hosting market, where Datatilsynet does not mess around, reliance on manual intervention is a single point of failure. The only way to survive the upcoming regulatory shift without halting your deployment velocity is to treat compliance exactly like your application logic: as code.

The "Compliance as Code" Architecture

The concept is simple but brutal to implement: define your infrastructure state in configuration management tools, and audit it programmatically. We are not just talking about installing patches. We are talking about enforcing strict cryptographic policies, file integrity monitoring, and kernel hardening.

For this workflow, we rely on a stack that was battle-tested in 2017 and is now mature: Ansible for enforcement and OpenSCAP for validation. But before you write a single line of YAML, you need to look at where your code is running.

The Underlying Hardware Matters

Pro Tip: You cannot automate security on a compromised substrate. Many budget VPS providers use OpenVZ containers where you share a kernel with noisy neighbors. This makes kernel-level hardening (like modifying sysctl.conf for network stack security) impossible or ineffective.

This is why, for compliance-heavy workloads, we default to CoolVDS. They utilize KVM (Kernel-based Virtual Machine) virtualization exclusively. This gives us a dedicated kernel space. When I run a hardening script on a CoolVDS instance, I know the iptables modules and kernel parameters are mine to control, isolated from whatever the other tenants are doing.

Step 1: Hardening the Base with Ansible

Let’s look at a practical scenario. We need to harden an Ubuntu 16.04 LTS server to meet basic CIS (Center for Internet Security) benchmarks. We don't do this by hand. We use an Ansible role.

Here is a snippet from a playbook strictly for SSH hardening. We are disabling root login and forcing protocol 2, which are immediate red flags in any audit.

- name: Secure SSH Configuration
  hosts: all
  become: yes
  tasks:
    - name: Ensure protocol 2 is used
      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
      notify: restart ssh

  handlers:
    - name: restart ssh
      service:
        name: sshd
        state: restarted

This playbook does more than just configure; it documents your security posture. If an auditor asks how you handle remote access, you don't show them a policy document nobody reads; you show them the code that enforces the policy every hour.

Step 2: Network Level Isolation

On a public-facing VPS, latency is not just about speed; it is an attack vector. DDoS attacks can mask intrusion attempts. While CoolVDS provides upstream DDoS protection, you must configure local firewalls to limit rate. Do not rely solely on security groups if you are moving between providers. Use iptables or ufw.

# Configure UFW to limit SSH connections (Anti-Bruteforce)
ufw limit 22/tcp

# Allow HTTP/HTTPS
ufw allow 80/tcp
ufw allow 443/tcp

# Deny everything else incoming by default
ufw default deny incoming
ufw enable

Step 3: Automated Auditing with OpenSCAP

Once Ansible has applied the configuration, how do you prove it? This is where OpenSCAP comes in. It parses the XCCDF (Extensible Configuration Checklist Description Format) standards and checks your system against them.

Install the scanner on your CoolVDS instance:

sudo apt-get install libopenscap8 python-openscap

Now, run a scan against the standard SSG (SCAP Security Guide) profile for Ubuntu 16.04:

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

This generates an HTML report showing exactly where you pass and fail. Red implies a violation. Green implies compliance. You can automate this via a cron job and ship the logs to a central server.

Data Sovereignty and the "Cloud Act" Panic

With the recent news around the US CLOUD Act (passed just this month, March 2018), the location of your data is critical. US-based hyperscalers are under increasing legal pressure to provide data access to US authorities, regardless of where the server physically sits.

This is a massive legal gray area for Norwegian companies handling EU citizen data. Hosting on CoolVDS, which operates strictly out of European datacenters with strong adherence to Norwegian privacy laws, mitigates this risk. You are not just buying NVMe storage; you are buying jurisdictional certainty.

Performance vs. Security Trade-offs

Security agents like OSSEC or ClamAV can be heavy on I/O. I have seen traditional SATA-based VPS instances grind to a halt during a scheduled file system scan. This leads to the dangerous practice of DevOps engineers disabling security tools to "fix performance."

Because CoolVDS standardizes on NVMe storage, you can run aggressive intrusion detection systems (IDS) and compliance scans in the background without degrading the user experience for your customers. Security should never be a bottleneck.

Final Thoughts

The May 25th deadline for GDPR is not a suggestion. By moving your infrastructure to a KVM-based, NVMe-powered environment like CoolVDS, and wrapping it in Ansible automation, you transform compliance from a yearly panic into a daily routine. Don't let your infrastructure be the reason you get fined.

Ready to audit your stack? Deploy a compliant-ready KVM instance on CoolVDS in under 60 seconds and run your first OpenSCAP scan today.