Automating Compliance: Why Manual Audits Will Fail You Before GDPR Arrives
If you are still manually editing /etc/ssh/sshd_config on your production servers, you are already non-compliant. The recent invalidation of the Safe Harbor agreement and the adoption of the EU's General Data Protection Regulation (GDPR) in April have fundamentally shifted the landscape. While the enforcement date of May 2018 feels far away, the architectural changes required to meet these standards cannot be built overnight.
As a CTO, my concern isn't just about hackers anymore; it's about auditors. With the introduction of the EU-US Privacy Shield this July, many businesses feel a false sense of security. However, data sovereignty remains the only foolproof strategy. If your customer data sits physically in Oslo, governed by Norwegian law and the Datatilsynet, you eliminate a massive layer of trans-Atlantic legal ambiguity.
But physical location is only half the battle. The other half is ensuring that every single Virtual Private Server (VPS) you deploy meets strict security baselines instantly, without human intervention. Here is how we move from "hope-based security" to deterministic compliance using Ansible on CoolVDS infrastructure.
The Myth of the "Golden Image"
In the past, we relied on "golden images"—snapshots of a perfectly configured server. In 2016, this is insufficient. A static image is obsolete the moment it is created. New vulnerabilities (CVEs) are discovered daily. If you deploy a three-month-old image today, you are deploying a security risk.
The solution is Infrastructure as Code (IaC). We define our compliance state in code, and we enforce it continuously. For this tutorial, we will use Ansible (version 2.1) because it requires no agents on the target nodes—just SSH, which fits perfectly with standard Linux instances.
Step 1: Defining the Norwegian Baseline
Before writing code, we must define the policy. For a standard web server hosting personal data in Norway, our baseline requirements usually look like this:
- Data Residency: Physical storage on NVMe disks within Norwegian borders (CoolVDS OSL-1 datacenter).
- Access Control: No root login, SSH keys only, MFA where possible.
- Firewall: Default deny incoming, allow only ports 80, 443, and customized SSH port.
- Logging: Retention set to meet local accounting laws (5 years for financial data, usually less for system logs).
Step 2: Automating SSH Hardening
The first vector of attack is always SSH. We don't just want to secure it; we want to ensure it stays secured even if a junior developer tries to change it. Here is an Ansible task list to enforce strict SSH configurations.
# roles/security/tasks/ssh.yml
---
- name: Ensure SSH protocol 2 only
lineinfile:
dest: /etc/ssh/sshd_config
regexp: '^Protocol'
line: 'Protocol 2'
state: present
- name: Disable Root Login
lineinfile:
dest: /etc/ssh/sshd_config
regexp: '^PermitRootLogin'
line: 'PermitRootLogin no'
state: present
notify: restart ssh
- name: Disable Password Authentication
lineinfile:
dest: /etc/ssh/sshd_config
regexp: '^PasswordAuthentication'
line: 'PasswordAuthentication no'
state: present
notify: restart ssh
- name: Ensure SSH runs on non-standard port
lineinfile:
dest: /etc/ssh/sshd_config
regexp: '^Port'
line: 'Port 2222'
state: present
notify: restart ssh
This simple playbook ensures that every time we run our provisioner, the server reverts to a secure state. If someone accidentally enables password auth for testing, the next run fixes it.
Step 3: Stateful Firewall Management
On CoolVDS instances, which often run on KVM virtualization, we have full control over the kernel's netfilter. While many use `iptables` commands directly, using the `ufw` (Uncomplicated Firewall) abstraction via Ansible ensures readability for auditors.
# roles/security/tasks/firewall.yml
---
- name: Install UFW
apt: name=ufw state=present
- name: Deny everything by default
ufw: state=enabled policy=deny direction=incoming
- name: Allow SSH on custom port
ufw: rule=allow port=2222 proto=tcp
- name: Allow HTTP/HTTPS
ufw: rule=allow port={{ item }} proto=tcp
with_items:
- 80
- 443
- name: Rate limit SSH to prevent brute force
ufw: rule=limit port=2222 proto=tcp
Pro Tip: When moving to a custom SSH port (like 2222), always update your firewall rules before restarting the SSH daemon. I have seen too many engineers lock themselves out of a remote VPS because they changed the port but forgot to open it in iptables first. On CoolVDS, you can use VNC console access to recover, but it's downtime you don't need.
Step 4: Automated Auditing with Lynis
Compliance is not just about configuration; it is about verification. We use Lynis, an open-source security auditing tool. It scans the system and provides a compliance score. In 2016, this is becoming the standard for lightweight Linux auditing.
You can automate the installation and daily execution of Lynis via cron:
# Manual run example
cd /usr/local/lynis
./lynis audit system --quick
The output gives you a hardening index. A fresh Ubuntu 16.04 install usually scores around 60. After applying our Ansible roles, it should hit 80+.
The "CoolVDS" Factor: Hardware-Level Compliance
Software automation solves the configuration problem, but it cannot solve the infrastructure problem. This is where your choice of host becomes a compliance decision.
When you deploy on AWS or Google Cloud, you are often dealing with "Availability Zones." While they claim data residency, the legal frameworks governing US-owned companies (even with servers in Europe) are complex. This is the core friction point that the Privacy Shield attempts to address, though skepticism remains high among legal experts here in Norway.
CoolVDS simplifies this significantly for the Pragmatic CTO:
- Jurisdiction: The company is Norwegian. The servers are in Oslo. The data never traverses US network borders.
- Performance as Security: We use NVMe storage exclusively. Why is this a security feature? Because legacy HDDs struggle during high-load DDoS attacks when logging subsystems need to write massive amounts of access logs instantly. Slow I/O can cause your logging daemon to crash, blinding you during an attack. High IOPS keeps your eyes open.
- Clean IP Reputation: We manually vet customers. This prevents your legitimate mail servers from being blacklisted because a "noisy neighbor" on the same subnet was sending spam.
Complete Playbook Example: The "GDPR-Ready" Web Node
Here is a more comprehensive Ansible playbook structure that pulls these elements together. This assumes you are running Ubuntu 16.04 LTS.
# site.yml
---
- hosts: norway_web_nodes
become: yes
vars:
ssh_port: 2222
sysctl_config:
- { key: 'net.ipv4.conf.all.accept_redirects', value: 0 }
- { key: 'net.ipv4.conf.all.send_redirects', value: 0 }
- { key: 'net.ipv4.ip_forward', value: 0 }
tasks:
- name: Update APT Cache
apt: update_cache=yes cache_valid_time=3600
- name: Upgrade all packages to latest version
apt: upgrade=dist
- name: Set correct timezone to Europe/Oslo
timezone:
name: Europe/Oslo
- name: Apply Kernel Hardening via Sysctl
sysctl:
name: "{{ item.key }}"
value: "{{ item.value }}"
state: present
reload: yes
with_items: "{{ sysctl_config }}"
- name: Install Fail2Ban
apt: name=fail2ban state=present
- name: Configure Fail2Ban for SSH
copy:
dest: /etc/fail2ban/jail.local
content: |
[sshd]
enabled = true
port = {{ ssh_port }}
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
notify: restart fail2ban
handlers:
- name: restart fail2ban
service: name=fail2ban state=restarted
Conclusion
The era of manual server administration is ending. The risks—legal, financial, and technical—are simply too high. By combining the legal certainty of Norwegian-based hosting with the deterministic security of Ansible, you create an infrastructure that is not just robust, but auditable.
Don't wait for the GDPR enforcement date to start scrambling. Build your compliance engine today on hardware that supports your mission.
Ready to audit your infrastructure? Spin up a CoolVDS NVMe instance in Oslo and run your first Lynis scan in under 2 minutes.