Automating Compliance: Surviving the Data Protection Act with Puppet and KVM

If you are still manually editing /etc/ssh/sshd_config across ten different servers, stop. You are a liability.

April 2014 changed everything. The Heartbleed bug wasn't just a vulnerability; it was a wake-up call for every Systems Architect in Europe. If it took you more than an hour to patch your entire infrastructure, your deployment pipeline is broken. In Norway, where the Personopplysningsloven (Personal Data Act) places strict liability on data handlers, relying on manual updates isn't just inefficient—it's legally dangerous.

We are seeing a shift. The old way of "configure once, run forever" is dead. The new reality is infrastructure as code. Today, we look at how to enforce Norwegian security standards automatically using Puppet, and why the underlying virtualization technology—specifically KVM—matters more than you think.

The Norwegian Context: Datatilsynet is Watching

Here in Norway, the Data Protection Authority (Datatilsynet) doesn't care about your uptime. They care about integrity. Under the current directive, you must ensure unauthorized access is technically impossible.

When you host data outside the EEA, you rely on Safe Harbor frameworks, which, let's be honest, feel shakier every month since the Snowden leaks last year. Hosting locally in Oslo isn't just about millisecond latency—though your developers will thank you for that—it is about sovereignty. Data staying on Norwegian soil, governed by Norwegian law.

The "Golden Image" Myth vs. Continuous State

Many sysadmins rely on a "Golden Image"—a hardened snapshot of CentOS 6 or Ubuntu 14.04. This works for Day 1. By Day 30, configuration drift sets in. A junior dev opens a port for testing. A package gets updated with a default config file. Suddenly, your "secure" server is wide open.

Solution: Active state enforcement. We don't hope the server is secure; we run an agent that ensures it is secure every 30 minutes.

Example: Enforcing SSH Hardening via Puppet

Instead of manually editing files, we define the state. Here is a production-ready Puppet class we use to ensure no root login and strict protocol usage.

class profile::base::ssh {
  package { 'openssh-server':
    ensure => present,
  }

  service { 'ssh':
    ensure    => running,
    enable    => true,
    subscribe => File['/etc/ssh/sshd_config'],
  }

  file { '/etc/ssh/sshd_config':
    ensure  => file,
    owner   => 'root',
    group   => 'root',
    mode    => '0600',
    content => template('profile/sshd_config.erb'),
  }
}

Inside your template, you hardcode the variables that matter:

# Managed by Puppet - DO NOT EDIT
Port 22
Protocol 2
PermitRootLogin no
PasswordAuthentication no
X11Forwarding no
UsePAM yes
AllowUsers deployer sysadmin

If someone manually changes PermitRootLogin to yes at 3:00 AM, Puppet reverts it at 3:30 AM. That is compliance.

The Sysctl Harden Loop

Network stack hardening is often overlooked in standard VPS templates. To mitigate SYN floods and spoofing, your sysctl.conf needs to be aggressive. Don't rely on OS defaults.

Run this check to see your current exposure:

If that returns 1, fix it immediately. Here is the block we push to all CoolVDS high-security instances:

# 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

# Ignore bogus error responses
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Log martian packets
net.ipv4.conf.all.log_martians = 1

Pro Tip: After applying these changes, run sysctl -p to load them without a reboot. If you are on a CoolVDS instance, these kernel parameters are fully tunable because we give you a true dedicated kernel, unlike shared-kernel containers.

KVM vs. OpenVZ: The Compliance Trap

This brings us to the architecture. In the Nordic hosting market, you see a lot of cheap VPS offers. Dig deeper, and you'll find they are often OpenVZ containers.

For a hobby blog, OpenVZ is fine. For compliance? It is a risk.

With KVM (Kernel-based Virtual Machine), your OS is self-contained. If a neighbor on the physical node crashes their kernel, you don't even blink. More importantly for Personopplysningsloven, memory segments are strictly isolated. There is no "bleed" between tenants. We use KVM exclusively at CoolVDS because we refuse to sell "noisy neighbor" problems as a service.

Nginx SSL: Post-Heartbleed Best Practices

SSL Labs is now the standard benchmark. If you aren't scoring an 'A', you are failing your users. The default Nginx config on Ubuntu 12.04 or even 14.04 is outdated. SSLv3 is effectively dead (POODLE is the new worry on the horizon).

Explicitly disable weak protocols in your nginx.conf:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";

The Latency Factor

Security is the baseline, but performance is the differentiator. Encrypted traffic (HTTPS) requires a handshake. The further your server is from the user, the slower that handshake feels.

Hosting in Germany or the US adds 30-100ms to every round trip. For a user in Trondheim or Bergen, a CoolVDS instance in Oslo cuts that network latency to single digits. When you combine our local peering with pure SSD storage arrays (no spinning rust here), the Time-To-First-Byte (TTFB) drops drastically.

Conclusion

Compliance is not a PDF you sign; it is a script you run. In 2014, the tools exist to make security automatic, auditable, and robust. But software can't fix hardware limitations.

You need a foundation that respects data sovereignty and offers true hardware isolation. Don't build a fortress on a swamp.

Ready to lock down your infrastructure? Deploy a KVM-based, SSD-accelerated instance in our Oslo datacenter today.