Automating Security Compliance: Surviving Datatilsynet Audits in 2015
If you are still manually editing /etc/ssh/sshd_config on your production servers, you represent a liability to your organization. I don't say this to be harsh; I say it because the Norwegian Data Protection Authority (Datatilsynet) does not grade on a curve.
With the ongoing scrutiny of the US Safe Harbor framework and the fallout from the Snowden revelations, the "cloud" has shifted from a buzzword to a compliance minefield for European CTOs. If your customer data leaves the European Economic Area (EEA), or even just crosses the wrong border, you aren't just facing latency issues—you are facing legal ones.
Security compliance isn't about buying a firewall appliance anymore. It is about infrastructure as code. Here is how we architect compliance automation to satisfy Norwegian standards without hiring an army of sysadmins.
The Myth of the "Secure" Default Image
Most VPS providers hand you a root password and wish you luck. This is negligence. A fresh install of CentOS 7 or Ubuntu 14.04 is designed for compatibility, not security. Services are listening, ports are open, and older protocols are enabled by default.
In a manual setup, an admin logs in, patches the server, configures IPTables, and installs a LAMP stack. But what happens six months later when the "Ghost" vulnerability (CVE-2015-0235) hits? If you have 50 servers, you have a panic attack. If you have automation, you have a coffee break.
The Foundation: True Isolation
Before we touch code, we must address the substrate. Compliance requires strict data segregation. This is why we argue against container-based virtualization like OpenVZ for mission-critical data handling. You share the kernel with every other customer on the node. A kernel panic in their container can affect yours.
At CoolVDS, we standardize on KVM (Kernel-based Virtual Machine). Each instance runs its own kernel. It is heavier, yes, but it provides the hardware-level isolation required for strict adherence to the Personal Data Act. You get dedicated RAM and NVMe storage slices that aren't overcommitted to the point of failure.
The Automation Stack: Ansible & OpenSCAP
In 2015, Puppet and Chef are the enterprise standards, but Ansible is winning the war for simplicity. It is agentless, which means you don't need to install a listening daemon on your secure servers. You push configurations over SSH, and then you disconnect.
1. Hardening SSH Automatically
Your first playbook should lock the door. We enforce key-based authentication and disable root login immediately. Here is a snippet from our standard baseline playbook:
- name: Secure SSH configuration
lineinfile:
dest: /etc/ssh/sshd_config
regexp: "^{{ item.key }}"
line: "{{ item.key }} {{ item.value }}"
state: present
with_items:
- { key: 'PermitRootLogin', value: 'no' }
- { key: 'PasswordAuthentication', value: 'no' }
- { key: 'Protocol', value: '2' }
- { key: 'AllowUsers', value: 'deploy_user' }
notify: restart sshd
This ensures that every server you deploy—whether it's one or one hundred—has the exact same access policy. No "forgotten" servers.
2. Continuous Auditing with SCAP
Configuration is one thing; verification is another. How do you prove to an auditor that your servers are compliant? We use the Security Content Automation Protocol (SCAP). Specifically, the openscap-scanner tool available in RHEL/CentOS 7.
You can scan a CoolVDS instance against the PCI-DSS profile or the STIG baseline with a single command:
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_pci-dss \
--results results.xml \
--report report.html \
/usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml
This generates a clean HTML report showing exactly where you pass and where you fail. Attach this to your internal audit documentation, and you have tangible proof of due diligence.
Pro Tip: Automate your updates. On Debian/Ubuntu, installunattended-upgrades. On CentOS, useyum-cron. The window between a vulnerability announcement and an exploit is shrinking. Don't rely on human memory to runyum update.
Data Sovereignty and the "Norwegian Fortress"
Technology implementation is useless if the legal footing is weak. The concept of "Data Sovereignty" is becoming critical for European businesses. If your data resides on a server physically located in the US, it is subject to the PATRIOT Act. This creates a direct conflict with European privacy directives.
This is where physical location becomes a feature. CoolVDS infrastructure is hosted in Oslo. We are governed by Norwegian law. For a Norwegian business, this simplifies the legal landscape immensely. Furthermore, the latency benefits are undeniable. Pinging a server in Virginia takes 90-100ms. Pinging a CoolVDS instance via the NIX (Norwegian Internet Exchange) takes 2-5ms.
Performance vs. Encryption
A common objection to full-disk encryption and heavy SSL/TLS (switching to 4096-bit keys) is the performance hit. This was true in 2010. Today, with the AES-NI instruction set present in modern CPUs, the overhead is negligible.
| Feature | Legacy HDD VPS | CoolVDS NVMe |
|---|---|---|
| I/O Wait | High (Mechanical seek time) | Near Zero (Flash storage) |
| Encryption Overhead | Noticeable latency | Invisible (CPU assisted) |
| Compliance Audits | Manual/Spreadsheets | Automated via API/Ansible |
The Verdict
Compliance is not a one-time checkbox; it is a continuous state of infrastructure. By combining the raw, isolated power of KVM virtualization with modern automation tools like Ansible and OpenSCAP, you transform security from a bottleneck into a competitive advantage.
Do not let your data drift across borders or sit on unpatched servers. Take control of your stack.
Ready to audit-proof your infrastructure? Spin up a CentOS 7 KVM instance on CoolVDS today and experience the stability of true Norwegian hosting.