Automating Security Compliance: Surviving the GDPR Era with Ansible and OpenSCAP in Norway

If you are still manually logging into your servers to check if root login is disabled, you have already lost. In 2019, the intersection of technical debt and legal liability is where CTOs get fired. With the General Data Protection Regulation (GDPR) fully mature and the Norwegian Data Protection Authority (Datatilsynet) becoming increasingly aggressive with audits, "security through obscurity" is no longer a strategy—it's negligence.

The challenge isn't just securing a server once; it's ensuring that the server stays secure after six months of deployments, hotfixes, and developer tinkering. Configuration drift is the silent killer of compliance. You deploy a hardened VPS, a junior dev temporarily opens port 22 to the world to "fix a connection issue," and suddenly your infrastructure is non-compliant. When you multiply this by fifty instances, manual verification becomes mathematically impossible.

The Legal Reality: Data Sovereignty in 2019

Before we touch a single line of code, we have to address the infrastructure layer. Many Norwegian businesses are currently migrating workloads back from US-based hyperscalers. Why? The US CLOUD Act (enacted last year) effectively allows US federal law enforcement to compel US-based providers to hand over data, regardless of where that data is physically stored—even if it's in a server farm in Frankfurt or Dublin.

For a Norwegian entity handling sensitive personal data, relying on the EU-US Privacy Shield is becoming a risky gamble. This is why physical data sovereignty is not just a buzzword; it is a legal safeguard. Hosting on a provider like CoolVDS, where the metal, the management, and the legal entity are strictly within Norwegian or European jurisdiction, mitigates this extraterritorial risk. You cannot automate your way out of a bad jurisdiction.

Step 1: Immutable Security with Ansible

The first step to automated compliance is defining your security state as code. We don't configure servers; we declare their state. Using Ansible (currently version 2.8), we can enforce hardening standards like the Center for Internet Security (CIS) benchmarks.

Here is a pragmatic Ansible role task to enforce SSH security. This isn't just about closing ports; it's about ensuring specific cryptographic standards are met.

# roles/security/tasks/sshd.yml
- name: Update SSH configuration to be more secure
  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: "^Ciphers", line: "Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com" }
  notify: restart sshd

This snippet does more than just disable root login. It forces the use of modern ciphers (ChaCha20-Poly1305), which offers superior performance on systems without AES-NI hardware acceleration, though on CoolVDS NVMe instances, CPU instruction sets are modern enough that AES-GCM is also blazing fast.

Step 2: The Firewall Gap

Automating the firewall is critical. I've seen too many `iptables` rules flushed by a reboot. On Ubuntu 18.04 LTS, `ufw` is the standard abstraction, but we need to ensure it fails closed.

- name: Configure UFW defaults
  ufw:
    state: enabled
    policy: deny
    direction: incoming

- name: Allow SSH from VPN Management IP only
  ufw:
    rule: allow
    proto: tcp
    from_ip: "192.168.10.50"
    to_port: "22"
    comment: "Management VPN Access"

Pro Tip: Never leave port 22 open to `0.0.0.0/0`, even with fail2ban. It creates log noise and consumes I/O resources processing the inevitable brute force attempts. Whitelist your office static IP or your VPN gateway. Low latency is great, but not when it's being used to serve 500 auth failures per second.

Step 3: Continuous Auditing with OpenSCAP

Applying the configuration is half the battle. Verifying it is the other. OpenSCAP (Open Security Content Automation Protocol) is the industry standard for verifying that a system adheres to a specific security baseline. It compares your current system state against the XCCDF (Extensible Configuration Checklist Description Format) checklist.

First, install the scanner and the security guides on your CentOS 7 or Ubuntu 18.04 server:

# Ubuntu 18.04
sudo apt-get update
sudo apt-get install libopenscap8 scap-security-guide

# CentOS 7
sudo yum install openscap-scanner scap-security-guide

Once installed, you can run a scan against the PCI-DSS or CIS profile. This will generate an HTML report highlighting exactly where you fail compliance.

oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_pci-dss \
  --results-arf /var/www/html/compliance/results.xml \
  --report /var/www/html/compliance/report.html \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu1804-ds.xml

This command generates a human-readable HTML report. You can schedule this via cron to run weekly. If the hash of the report changes drastically, you know someone has been messing with the config.

Performance Considerations: Audit Overhead

Security scanning is I/O intensive. It reads thousands of files to check permissions and hashes. On legacy spinning rust (HDD) VPS providers, a full OpenSCAP scan can cause I/O wait (iowait) to spike, effectively causing a Denial of Service on your own application database. This is where the underlying infrastructure matters.

We use KVM virtualization at CoolVDS specifically to ensure that your allocated I/O operations are yours. Unlike OpenVZ, where a neighbor's heavy file scan could choke your database, KVM provides stricter isolation. When you run a compliance scan on our infrastructure, it finishes before you can finish your coffee.

Automated Remediation

OpenSCAP can also generate bash scripts to fix the issues it finds. However, be extremely careful here. Blindly applying remediation scripts can break applications. For example, the CIS benchmark might recommend mounting `/tmp` with `noexec`, which will break many Java applications or install scripts that rely on executing binaries from temporary directories.

A safer approach is to use the scan results to inform your Ansible playbooks. Update your playbook, deploy to a staging environment hosted on a separate CoolVDS instance, verify the application works, and then roll out to production.

Conclusion

Compliance is not a checkbox; it's a process. In Norway, where the cost of a data breach involves both heavy fines and a loss of trust that is hard to recover from, you cannot afford manual errors. By combining Ansible for configuration management, OpenSCAP for auditing, and a hosting provider that respects data sovereignty, you build a fortress that is both legally and technically sound.

Don't let slow I/O kill your security posture. Deploy a high-performance, compliance-ready NVMe instance on CoolVDS today and audit your infrastructure in seconds, not hours.