Automating the Auditor: Infrastructure Compliance in a Post-Safe Harbor World
The era of the "Excel spreadsheet audit" is dead. If you are still manually checking /etc/ssh/sshd_config across fifty servers or relying on a yearly pentest to catch vulnerabilities, you are already breachedâyou just don't know it yet. With the European Parliament formally adopting the General Data Protection Regulation (GDPR) just two weeks ago (April 14, 2016), the clock has started ticking. We have two years until enforcement hits, but the architectural changes need to happen now.
Add to this the fallout from the Schrems I ruling last October which invalidated the US-EU Safe Harbor agreement, and suddenly, where your data lives physically matters just as much as how it is encrypted. As a Systems Architect operating out of Oslo, I've seen too many CTOs panic because their hosting provider can't guarantee data sovereignty.
This is not a policy discussion. This is a technical guide on implementing Compliance as Code. We will look at automating security baselines using OpenSCAP and Ansible, ensuring your infrastructure is audit-ready every time a commit is pushed.
The Myth of the "Secure" Container
Before we touch the config files, we need to address the virtualization layer. In 2016, everyone is excited about Docker 1.11 and the new runC runtime. Containers are fantastic for deployment velocity, but for strict compliance isolation (PCI-DSS, HIPAA, or handling sensitive Norwegian citizen data), shared kernel architectures pose a risk.
If a kernel exploit hits the host, every container is compromised. This is why, for the compliance-heavy workloads we manage, we refuse to use container-based VPS solutions (like OpenVZ). We rely strictly on KVM (Kernel-based Virtual Machine). KVM provides hardware-level virtualization. If a neighbor on the physical node crashes their kernel, your instance keeps humming. CoolVDS defaults to KVM for this exact reasonâtrue isolation is a security prerequisite, not a feature.
Step 1: Baseling with OpenSCAP
You cannot improve what you cannot measure. OpenSCAP (Security Content Automation Protocol) allows us to scan our servers against standard profiles like the Red Hat benchmarks or PCI-DSS requirements.
On a CentOS 7 or RHEL 7 machine, install the scanner:
yum install openscap-scanner scap-security-guide
To run a scan against the standard security profile (ssg-centos7-ds.xml), execute:
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_standard \
--results /tmp/scan-results.xml \
--report /tmp/scan-report.html \
/usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml
The resulting HTML report will likely show a sea of red "Fail" statuses. Do not panic. This is your baseline. Common failures include SSH root login being enabled, weak partition options, or lax umask settings. In a recent audit for a client handling payment data, a default vendor installation failed 48% of the checks. Manual remediation would have taken days.
Step 2: Remediation with Ansible (v2.0)
Fixing these issues by hand is amateur hour. Scripts are brittle. We use Ansible. With the release of Ansible 2.0 this January, error handling has improved significantly, making it stable enough for production security enforcement.
Here is a battle-tested playbook snippet that enforces a secure SSH configuration, a requirement for almost every compliance standard.
The Secure SSH Task
- name: Secure SSH Configuration
hosts: webservers
become: yes
tasks:
- name: Disable Root Login
lineinfile:
dest: /etc/ssh/sshd_config
regexp: '^PermitRootLogin'
line: "PermitRootLogin no"
state: present
notify: restart ssh
- name: Disable Password Authentication (Keys Only)
lineinfile:
dest: /etc/ssh/sshd_config
regexp: '^PasswordAuthentication'
line: "PasswordAuthentication no"
state: present
notify: restart ssh
- name: Enforce Protocol 2
lineinfile:
dest: /etc/ssh/sshd_config
regexp: '^Protocol'
line: "Protocol 2"
state: present
notify: restart ssh
handlers:
- name: restart ssh
service: name=sshd state=restarted
This creates an idempotent state. Run it once, run it a thousand timesâthe result is always a compliant system.
Step 3: Network Stack Hardening
Beyond the application layer, the kernel network stack needs tuning to prevent IP spoofing and man-in-the-middle attacks. These settings are often overlooked by generic hosting providers but are critical for passing a rigorous Datatilsynet inspection.
Add the following to your /etc/sysctl.conf (or manage it via Ansible's `sysctl` module):
# Disable IP Forwarding (unless this is a router/VPN)
net.ipv4.ip_forward = 0
# Ignore ICMP redirects to prevent MITM
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
# Log Martians (packets with impossible addresses)
net.ipv4.conf.all.log_martians = 1
Apply these instantly with sysctl -p. If you are running on a VPS with shared kernel resources (OpenVZ/LXC), you might find you lack permission to change these flags. This is a showstopper. On CoolVDS KVM instances, you have full kernel authority. You own the stack, so you can secure the stack.
Data Sovereignty and Latency
Technical hardening is useless if the legal ground under your server shifts. Since the Safe Harbor ruling, relying on US-based giants involves complex legal gymnastics involving "Model Clauses." For Norwegian businesses, the simplest path to compliance is keeping data on Norwegian soil.
But there is a performance angle here too. If your primary user base is in Scandinavia, hosting in Virginia or even Frankfurt introduces avoidable latency.
| Origin | Destination: Ashburn (US) | Destination: Frankfurt (DE) | Destination: Oslo (CoolVDS) |
|---|---|---|---|
| Bergen, Norway | ~110ms | ~35ms | ~8ms |
| Trondheim, Norway | ~115ms | ~40ms | ~12ms |
Low latency isn't just about fast page loads; it's about database replication speed and SSH responsiveness. When you are debugging a live issue, 8ms latency feels like working on localhost.
Pro Tip: If you are moving to the newly released Ubuntu 16.04 LTS (Xenial Xerus), be aware that it replaces `apt-get` with `apt` for user interaction, and more importantly, it ships with systemd by default. Update your Ansible service handlers to avoid legacy wrapper issues.
The Storage Bottleneck
Finally, compliance logging generates massive I/O. If you enable auditd to log every file access (required for some high-security environments), a standard SATA SSD will choke. We've seen disk queues spike to 100% just from log rotation.
This is where hardware selection becomes architectural. NVMe (Non-Volatile Memory Express) is still considered "cutting edge" by many budget hosts in 2016, but it is the only interface capable of handling the parallel I/O depth of a fully audited system without stealing CPU cycles. CoolVDS has standardized on NVMe for this reasonâsecurity should not degrade performance.
Conclusion
The GDPR is coming. The tools to prepareâOpenSCAP, Ansible, and robust KVM virtualizationâare already here. You can either scramble in 2018 when the fines start, or you can bake compliance into your infrastructure today.
Don't build your fortress on rented land you can't control. Spin up a dedicated KVM instance on CoolVDS, verify the kernel flags, and lock it down. Your future audit logs will thank you.