Compliance as Code: Automating Server Hardening for the Norwegian Data Protection Act

If you are a CTO operating in Norway right now, you are likely losing sleep over two things: The US Patriot Act and the Norwegian Data Inspectorate (Datatilsynet). With the increasing scrutiny on Safe Harbor agreements, relying on American-owned cloud infrastructure is becoming a legal minefield for any company handling sensitive Nordic user data.

We have moved past the era where a manual checklist in an Excel spreadsheet is sufficient for a security audit. In 2013, if your infrastructure cannot document its own state, you are already non-compliant. The goal of this article is to move your team from "security by obscurity" to "compliance as code," utilizing tools like Puppet and the inherent isolation of KVM virtualization to satisfy the requirements of the Personal Data Act (Personopplysningsloven) and EU Directive 95/46/EC.

The "Noisy Neighbor" Compliance Risk

Before we touch a single configuration file, we must address architecture. Many budget VPS providers in Europe are still heavily relying on container-based virtualization like OpenVZ or Virtuozzo to maximize density. While cost-effective, these technologies share a single kernel across all tenants.

From a security perspective, this is a nightmare. A kernel exploit in a neighboring container could theoretically expose your memory segments. For strict compliance, hardware-assisted virtualization (KVM) is the only logical choice. It provides a complete isolation layer where your OS has its own kernel.

Pro Tip: Always verify your virtualization type. Run virt-what on your instance. If it doesn't say "kvm", you are sharing a kernel with potentially hundreds of other users. At CoolVDS, we strictly use KVM for all "managed hosting" plans to ensure this isolation boundary is never breached.

Automating Hardening with Puppet

Manual server hardening is prone to human error. If you manage five servers, you might remember to disable root login on all of them. If you manage fifty, you will miss one. That one missed server is your audit failure.

In 2013, the industry is coalescing around configuration management. While Chef is powerful, Puppet offers a declarative syntax that is easier for auditors to read. Instead of writing a script that says "how" to secure a server, you write a manifest that describes "what" a secure server looks like.

Example: Enforcing SSH Security

Below is a basic Puppet class designed to enforce SSH standards required by most enterprise security policies. This ensures that even if a junior sysadmin manually changes the config, Puppet will revert it back to the compliant state on the next run (usually every 30 minutes).

class secure_ssh {  package { 'openssh-server':    ensure => installed,  }  file { '/etc/ssh/sshd_config':    ensure  => present,    owner   => 'root',    group   => 'root',    mode    => '0600',    source  => 'puppet:///modules/ssh/sshd_config_secure',    require => Package['openssh-server'],    notify  => Service['sshd'],  }  service { 'sshd':    ensure     => running,    enable     => true,    hasrestart => true,    hasstatus  => true,    subscribe  => File['/etc/ssh/sshd_config'],  }}

Your sshd_config_secure source file should explicitly set PermitRootLogin no and Protocol 2. By committing this code to your repository, you effectively create a version-controlled history of your compliance posture, which is exactly what Datatilsynet wants to see.

File Integrity Monitoring (FIM)

One of the specific requirements of PCI-DSS (which is a good baseline even if you don't handle credit cards) is tracking changes to system binaries. If an attacker manages to replace /bin/ls with a rootkit, how would you know?

We recommend AIDE (Advanced Intrusion Detection Environment). It creates a database of file hashes and checks them against the current state. It is lightweight and standard in the CentOS 6 repositories.

Configuring AIDE

First, install it via yum: yum install aide. Then, configure /etc/aide.conf to watch critical directories but exclude rapidly changing log files to avoid false positives.

# /etc/aide.conf snippets# Define the rule for critical binariesBinLib = p+i+n+u+g+s+b+m+c+md5+sha1# Apply to system directories/bin BinLib/sbin BinLib/usr/bin BinLib/usr/sbin BinLib/etc/hosts$ BinLib/etc/resolv.conf$ BinLib# Ignore logs!/var/log/messages$ !/var/log/secure$ !

Initialize the database and move it to a safe location (ideally read-only media, or an off-site backup):

Schedule a daily cron job to run aide --check and mail the results to your security team. This provides a daily audit trail of exactly what changed on your file system.

Network Locking: State of the Art IPTables

While hardware firewalls are great, host-based firewalls are mandatory. In CentOS 6, we rely on IPTables. The default configuration is often too permissive. For a compliant web server, we want a "default drop" policy.

Here is a robust configuration script. Note the explicit handling of the loopback interface—forgetting this can break local applications connecting to MySQL via localhost.

*filter:INPUT DROP [0:0]:FORWARD DROP [0:0]:OUTPUT ACCEPT [0:0]# Allow established connections-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT# Allow loopback-A INPUT -i lo -j ACCEPT# Allow SSH (Change 22 to your custom port)-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT# Allow Web Traffic-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT# ICMP (Ping) - Rate limited to prevent flooding-A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j ACCEPTCOMMIT

The Data Residency Advantage

Technological hardening is useless if the physical drives reside in a jurisdiction that allows warrantless seizure. This is why "VPS Norway" has become such a critical search term for Enterprise IT this year.

Latency is another factor often overlooked in compliance. Complex encryption and SSL handshakes add overhead. By hosting in Oslo, you are reducing the Round Trip Time (RTT) to your Norwegian user base to roughly 2-5 milliseconds. Compare this to hosting in Frankfurt or Amsterdam, where latency can triple.

At CoolVDS, our infrastructure is built on Enterprise SSD storage (often utilizing high-performance PCIe flash technology) which drastically reduces I/O wait times during database audits and backup rotations. When you combine local residency, high-speed storage, and the KVM isolation discussed above, you build a fortress that is not only secure but performant.

Final Recommendation

Compliance is not a one-time setup; it is a continuous process. Start by deploying a test environment that mirrors your production stack.

1. Provision a CentOS 6 instance on KVM.
2. Write a Puppet manifest to lock down users and SSH.
3. Configure IPTables to drop everything by default.
4. Install AIDE for integrity monitoring.

If you need a reliable foundation for this architecture, deploy a test instance on CoolVDS today. Our data centers in Oslo offer the low latency and legal protections your "Pragmatic CTO" persona demands, backed by the raw power of SSD RAID arrays.