Automating GDPR Compliance: A DevOps Guide to Hardening Linux Infrastructure
It has been three months since GDPR (Personvernforordningen) went into full enforcement on May 25th. The panic has subsided, but for Systems Administrators and DevOps engineers in Norway, the headache is just beginning. The reality is simple: if you are still manually hardening servers via SSH, you are already non-compliant.
I recently consulted for a mid-sized fintech in Oslo. They had excellent documentation, but their infrastructure reality had drifted. When Datatilsynet asks for proof of patch management and access control, showing them a PDF policy document isn't enough. You need audit trails, and you need infrastructure that self-corrects.
In this guide, we aren't talking about high-level theory. We are going to look at how to automate security compliance on CentOS 7 and Ubuntu 18.04 LTS using Ansible and OpenSCAP. We will focus on the technical implementation of GDPR Article 32: "Security of processing."
The Problem: Configuration Drift
You deploy a VPS. You run your hardening script. It disables root login, sets up UFW, and configures Fail2Ban. Great.
Six months later, a junior dev changes a permission to debug an issue. A package update overwrites a config file. Suddenly, your "secure" server is exposing a vulnerability. In a traditional hosting environment, you might not notice until it's too late. This is why Infrastructure as Code (IaC) is not optional for security.
Pro Tip: Never rely on default VPS templates for security. While CoolVDS provides optimized base images, the responsibility for the application layer security rests with you. We provide the isolated KVM environment; you provide the logic.
Step 1: The Base Hardening (Ansible)
We will use Ansible because it requires no agents—just SSH. This keeps our overhead low, which is crucial on smaller VPS instances. Below is a snippet from a production playbook targeting the SSH daemon. This enforces key-based authentication and disables root login—two absolute prerequisites.
Configuring sshd_config via Ansible
This task ensures that your SSH configuration matches the CIS (Center for Internet Security) benchmarks.
- name: Secure SSH configuration
lineinfile:
dest: /etc/ssh/sshd_config
regexp: "{{ item.regexp }}"
line: "{{ item.line }}"
state: present
validate: 'sshd -t -f %s'
with_items:
- { regexp: '^PasswordAuthentication', line: 'PasswordAuthentication no' }
- { regexp: '^PermitRootLogin', line: 'PermitRootLogin no' }
- { regexp: '^MaxAuthTries', line: 'MaxAuthTries 3' }
- { regexp: '^Protocol', line: 'Protocol 2' }
- { regexp: '^X11Forwarding', line: 'X11Forwarding no' }
notify: restart sshd
- name: Ensure SSH protocol 1 is disabled
lineinfile:
dest: /etc/ssh/sshd_config
regexp: '^Protocol 1'
state: absent
notify: restart sshd
By defining this in code, you can run this playbook against 10 or 100 servers every night. If a configuration has drifted, Ansible pulls it back in line.
Step 2: Automated Compliance Scanning with OpenSCAP
Hardening is one thing; proving it is another. OpenSCAP is an open-source tool that scans your system against a specific profile (like PCI-DSS or NIST). For Red Hat/CentOS systems, this is native.
First, install the scanner on your CoolVDS CentOS 7 instance:
yum install openscap-scanner scap-security-guide -y
Now, run a scan against the standard security profile. This command generates an HTML report that you can actually show to an auditor.
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_standard \
--results /var/www/html/scan-report.xml \
--report /var/www/html/scan-report.html \
/usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml
If you automate this via cron, you have a daily compliance report. If a vulnerability appears (like a new CVE), OpenSCAP will flag it based on the definitions.
Step 3: Encryption and I/O Performance
GDPR emphasizes encryption at rest. On Linux, this usually means LUKS (Linux Unified Key Setup). However, encryption adds CPU overhead and I/O latency. This is where your choice of infrastructure matters.
Running full-disk encryption on a legacy SATA-based VPS will kill your database performance. The I/O wait times will skyrocket during backups or heavy writes.
This is why we standardized on NVMe storage at CoolVDS. The high IOPS capability of NVMe mitigates the penalty of LUKS encryption.
Checking I/O Scheduler
When running on NVMe inside KVM, you should ensure your guest OS is using the correct I/O scheduler. For modern kernels (4.x+), `none` or `mq-deadline` is often preferred over `cfq` for low-latency devices.
# Check current scheduler
cat /sys/block/vda/queue/scheduler
# Set to none (pass-through to hypervisor) for lowest latency
echo none > /sys/block/vda/queue/scheduler
Data Sovereignty: Why Location Matters
Under current regulations, transferring data outside the EEA can be legally complex. While the Privacy Shield agreement exists, many Norwegian companies prefer to keep data strictly within Norway to simplify legal standing with Datatilsynet.
CoolVDS infrastructure is located physically in Oslo. This offers two advantages:
- Compliance: Data never crosses borders.
- Latency: If your users are in Norway, your round-trip time (RTT) to NIX (Norwegian Internet Exchange) is minimal—often under 2ms.
The "Noisy Neighbor" Risk in Compliance
Security isn't just about software; it's about isolation. Many budget providers use container-based virtualization (like OpenVZ) where the kernel is shared. If the host kernel has a vulnerability, your container is exposed. Furthermore, resource isolation is weaker.
| Feature | Container (OpenVZ/LXC) | Hardware Virt (KVM/CoolVDS) |
|---|---|---|
| Kernel Isolation | Shared (High Risk) | Dedicated (High Security) |
| Swap Access | Often Unavailable | Dedicated |
| SELinux Support | Limited | Full |
For GDPR-critical workloads, we rely strictly on KVM. It provides a true hardware virtualization layer. Even if a neighbor on the physical node is compromised, they cannot access your memory space or kernel.
Summary
Compliance is a moving target. The only way to hit it consistently is through automation. By combining Ansible for configuration management, OpenSCAP for verification, and the right underlying infrastructure (KVM + NVMe), you can build a fortress that satisfies the auditors and performs for the users.
Don't let legacy infrastructure compromise your compliance posture. Deploy a secure, Norway-based KVM instance on CoolVDS today and start automating.