Automating Compliance: Infrastructure as Code & Data Sovereignty in Norway

Let’s be honest: if you are still manually editing /etc/ssh/sshd_config on production servers, you are already non-compliant. In the current climate—post-Snowden and with the EU Data Protection Directive (95/46/EC) under intense scrutiny—security cannot be a "set it and forget it" task. It must be a repeatable, audit-proof process.

As a CTO, my nightmare isn't just a breach; it's the auditor from Datatilsynet (The Norwegian Data Protection Authority) asking for a change log that doesn't exist. We need to move away from "golden images" that rot over time and towards Infrastructure as Code (IaC).

The End of the "Manual" Admin

We recently migrated a financial services client from a legacy hosting provider to a dedicated KVM cluster. The audit requirements were brutal. They needed proof that every single server had specific kernel parameters set, root login disabled, and IPTables configured strictly.

Doing this manually across 50 nodes is negligence. One typo in a firewall rule on Node #42, and you expose the internal network. We utilized Ansible 1.9 to enforce this state. Unlike Puppet or Chef, Ansible is agentless, which fits perfectly with the lean philosophy we apply to our infrastructure.

Code Snippet: Enforcing SSH Security

Here is a snippet from a standard playbook we use to lock down fresh CentOS 7 instances. This ensures that no matter who deploys the server, the security posture remains identical.

- name: Secure SSH configuration
  lineinfile:
    dest: /etc/ssh/sshd_config
    regexp: "{{ item.regexp }}"
    line: "{{ item.line }}"
    state: present
  with_items:
    - { regexp: '^PasswordAuthentication', line: 'PasswordAuthentication no' }
    - { regexp: '^PermitRootLogin', line: 'PermitRootLogin no' }
    - { regexp: '^Port', line: 'Port 2222' }
  notify: restart sshd

By defining this in code, our documentation is the code. When an auditor asks, "How do you ensure root login is disabled?", I don't show them a policy PDF nobody reads. I show them the Git commit hash that applied this rule.

Data Sovereignty: Location is a Feature

Automation handles the how, but we must also address the where. Since the 2013 revelations regarding US surveillance, relying on Safe Harbor is becoming a strategic risk. There are rumblings in Brussels that could invalidate data transfers to the US entirely (keep an eye on the Schrems case).

For European businesses, and specifically those operating under Norwegian jurisdiction, hosting data outside the EEA is becoming a legal minefield. Latency is another factor—if your customers are in Oslo or Bergen, routing traffic through Frankfurt or London adds unnecessary milliseconds.

Pro Tip: Don't just look at the ping time. Look at the traceroute. You want your VPS provider to peer directly with NIX (Norwegian Internet Exchange) to ensure local traffic stays local.

The KVM Difference

Compliance also touches on isolation. Many budget providers use OpenVZ, which shares the host kernel among all tenants. From a security perspective, this is a larger attack surface. If a kernel exploit hits the host, your container is vulnerable.

This is why we standardized our architecture on CoolVDS. They utilize KVM (Kernel-based Virtual Machine) virtualization exclusively. KVM provides hardware-assisted virtualization, meaning your OS has its own kernel, separate from the host and other tenants. It allows us to enable SELinux inside the VM without fighting the host node's configuration.

Building the Fortress

To wrap up, your compliance strategy in 2015 should rest on two pillars:

1. Automation: Use tools like Ansible to ensure your security baseline is applied automatically to every new instance.
2. Sovereignty: Host your data in a jurisdiction that respects privacy, on infrastructure that guarantees isolation.

We are seeing a shift. The "cloud" is maturing from a buzzword into a utility that requires rigorous governance. Whether you are running a high-traffic Magento store or a custom SaaS application, the foundation matters.

If you need a compliant, low-latency environment to test your new Ansible playbooks, spin up a KVM instance on CoolVDS. It’s the closest you’ll get to bare metal isolation with the flexibility of a cloud instance.