The Countdown is Over: Automating Infrastructure Compliance Before May 25

It is May 14, 2018. If you are a CTO or Lead SysAdmin operating in Europe, you have exactly 11 days left. The General Data Protection Regulation (GDPR) is no longer a distant bureaucratic threat; it is an imminent operational reality. The panic I see in the industry right now is not about intent—most of us want to protect user data—but about scalability. You cannot manually audit 500 servers for compliance every week. If you are still relying on a dusty Excel spreadsheet to track which servers have PermitRootLogin no set, you are already non-compliant.

Security is not a state; it is a continuous process. In the context of the Nordic market, where the Datatilsynet (Norwegian Data Protection Authority) is preparing to enforce these new standards, "best effort" is no longer sufficient. We need mathematical proof of security. This brings us to the intersection of Infrastructure as Code (IaC) and automated compliance auditing. Today, we are ditching manual checklists for Ansible playbooks and OpenSCAP scanning.

The Liability of the Human Element

In a recent audit for a financial client in Oslo, we found that despite a rigorous policy document, 30% of their production web nodes had drifted from the baseline security configuration. Why? Because a developer needed to debug a live issue at 3 AM and temporarily disabled SELinux. They forgot to turn it back on. This is configuration drift, and under the new regulations, it is a reportable vulnerability.

To eliminate this, we treat compliance as code. We define the state of the system in Ansible, and we verify it with the Security Content Automation Protocol (SCAP).

Defining the Hardened State with Ansible

Let's look at a practical example. We want to ensure that SSH is hardened across our entire fleet. We are not just editing files; we are enforcing state. Using Ansible 2.5 (released just a few months ago), we can ensure strict ownership and permissions on critical keys.

Below is a snippet from a hardening role we deploy on CoolVDS instances running CentOS 7:

- name: Ensure SSH protocol is set to 2
  lineinfile:
    dest: /etc/ssh/sshd_config
    regexp: '^Protocol'
    line: 'Protocol 2'
    state: present
    validate: '/usr/sbin/sshd -T -f %s'
  notify: restart sshd

- name: Secure SSH host keys permissions
  file:
    path: "{{ item }}"
    owner: root
    group: root
    mode: 0600
  with_items:
    - /etc/ssh/ssh_host_rsa_key
    - /etc/ssh/ssh_host_ecdsa_key
    - /etc/ssh/ssh_host_ed25519_key

Notice the validate argument. We don't just write the config; we test it before restarting the service to prevent locking ourselves out—a common disaster when managing remote VPS instances. This automation ensures that if that developer changes the config at 3 AM, Ansible will revert it to the secure state on the next run.

Verifying with OpenSCAP

Applying the configuration is step one. Proving it to an auditor is step two. This is where OpenSCAP shines. It allows us to scan our servers against the standard PCI-DSS or standard system security profiles.

On a standard CoolVDS Enterprise Linux instance, you can install the scanner immediately:

yum install openscap-scanner scap-security-guide

Once installed, you don't need to guess if you are compliant. You run a scan against the Common Configuration Scenery (CCS) profile. Here is how we verify a server's compliance status directly from the shell:

oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_standard \
  --results /var/www/html/scan-results.xml \
  --report /var/www/html/scan-report.html \
  /usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml

This command generates a human-readable HTML report. Green is good; red is a liability. You can automate this via cron and have the reports shipped to a central secure server. When the Datatilsynet asks for proof of your security posture, you don't scramble; you hand them the report generated 4 hours ago.

Pro Tip: Do not run heavy SCAP scans during peak traffic hours on shared hosting environments. The I/O load can be significant. This is why we insist on NVMe storage for all CoolVDS instances—the high IOPS capability allows you to run security audits in the background without degrading the performance of your PHP or Python applications.

Data Sovereignty and the "Noisy Neighbor" Risk

Automation solves configuration, but it cannot solve jurisdiction. With the fall of Safe Harbor in 2015 and the current scrutiny on the Privacy Shield framework, data residency is the elephant in the room. If your data sits on a server physically located in Virginia, US, automation won't save you from the legal complexities of GDPR Article 44 regarding data transfers.

This is where infrastructure choice becomes a compliance decision. Hosting in Norway (a logical choice for EEA stability) provides a layer of legal insulation. However, not all VPS hosting is equal. Many budget providers use OpenVZ or LXC containers where the kernel is shared. If an attacker manages a kernel-level exploit on a neighbor's container, your memory space could be compromised.

The KVM Advantage

At CoolVDS, we utilize KVM (Kernel-based Virtual Machine) exclusively. KVM treats your VPS as a distinct process with its own kernel, memory space, and hardware emulation. It provides the isolation of a dedicated server with the flexibility of the cloud.

For GDPR compliance, specifically regarding the "integrity and confidentiality" of data, KVM is the superior architectural choice. You can even encrypt your root partition using LUKS, which is impossible on container-based virtualization.

The Database Layer: `my.cnf` Matters

Finally, your database is the holy grail for attackers. Automating OS hardening is useless if MySQL is listening on 0.0.0.0 with the default root password. In 2018, we are seeing a rise in automated botnets specifically scanning for exposed port 3306.

Your Ansible playbook must enforce local binding unless absolutely necessary. Here is the configuration block that should be standard in your my.cnf (or 50-server.cnf on MariaDB 10.2):

[mysqld]
# Bind to localhost to prevent external access
bind-address = 127.0.0.1

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

# Ensure secure transport
ssl-ca=/etc/mysql/ssl/ca-cert.pem
ssl-cert=/etc/mysql/ssl/server-cert.pem
ssl-key=/etc/mysql/ssl/server-key.pem

If you need remote access, use an SSH tunnel. Never expose the database port directly to the internet. We see bruteforce attempts against database ports within minutes of a server going live.

Conclusion

The May 25th deadline is not the end; it is the starting line for a new era of data responsibility. Manual administration is dead. It is too slow, too error-prone, and legally dangerous.

By leveraging Ansible for consistent state and OpenSCAP for verification, you transform compliance from a headache into a deployable asset. And by anchoring your infrastructure on high-performance, KVM-based instances in Norway, you solve the physical and jurisdictional challenges in one move.

Do not let legacy infrastructure be your downfall. Audit your stack today.

Ready to harden your infrastructure? Deploy a fully isolated, NVMe-powered KVM instance in Oslo on CoolVDS in under 60 seconds and start your compliance automation journey on solid ground.