Automating Security Compliance: Surviving the Datatilsynet Audit with Ansible & OpenSCAP

Let’s be honest: the only thing worse than a server outage is a compliance audit. If you are operating anywhere near the Norwegian market, you know the drill. It’s not just about keeping hackers out; it’s about proving to Datatilsynet (The Norwegian Data Protection Authority) that you’re actually doing what you say you’re doing. The days of manual checklists and "I promised I ran `apt upgrade`" are dead. If it’s not automated, it doesn’t exist.

In 2025, the complexity of infrastructure means that manual hardening is indistinguishable from negligence. I recently inherited a project for a FinTech client in Oslo. They had twelve VPS instances scattered across three different providers. The previous admin swore they were "GDPR compliant." I ran a simple OpenSCAP scan. The result? A compliance score of 42%. They were still allowing root login over SSH, and IPv6 forwarding was wide open. It was a disaster waiting to happen.

The "Sovereignty" Trap

Before we touch a single config file, we need to address the physical layer. You can write the most secure Ansible playbook in the world, but if your data sits on a hypervisor controlled by a company subject to the US CLOUD Act, your GDPR strategy has a hole in it. This is the Schrems II reality we still live with.

This is where infrastructure choice becomes a security decision. We default to CoolVDS for our Norwegian clients not because we like their logo, but because the jurisdiction matters. Their data centers are in Norway. The legal entity is Norwegian. When I run a compliance report, I can check the box for "Data Residency" without adding an asterisk about foreign subpoenas.

Infrastructure as Code: The Only Way to Harden

We are going to use Ansible to enforce CIS (Center for Internet Security) benchmarks. Why Ansible? Because it’s agentless. You don't want to install heavy agents on a lean KVM instance. We pair this with OpenSCAP for verification.

1. The Base Hardening Playbook

Forget manual edits. Here is a snippet of a standard hardening role we deploy to every CoolVDS instance immediately after provisioning. This targets SSH configuration, which is usually the primary attack vector.

# roles/security/tasks/sshd.yml
- 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: '^PermitRootLogin', line: 'PermitRootLogin no' }
    - { regexp: '^PasswordAuthentication', line: 'PasswordAuthentication no' }
    - { regexp: '^X11Forwarding', line: 'X11Forwarding no' }
    - { regexp: '^MaxAuthTries', line: 'MaxAuthTries 3' }
    - { regexp: '^Protocol', line: 'Protocol 2' }
  notify: restart sshd

This ensures that even if a junior dev tries to enable password auth for "testing," the next Ansible run wipes that configuration out. It enforces a state of compliance.

Kernel Level Hardening

Application security is useless if the kernel is leaking information. This is another reason we avoid container-based VPS (like OpenVZ) and stick to KVM. On a shared kernel, you can't modify specific `sysctl` parameters without affecting neighbors—or worse, you can't modify them at all.

On a dedicated KVM slice, we own the kernel. We apply these network stack hardenings to prevent IP spoofing and man-in-the-middle attacks:

# /etc/sysctl.d/99-security.conf

# IP Spoofing protection
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Ignore ICMP broadcast requests
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Disable source packet routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

# Log Martians
net.ipv4.conf.all.log_martians = 1

Pro Tip: After applying these, run `sysctl -p` to load them. If you are on a cheap VPS provider and get "Permission denied," move your data. You are on a shared kernel, and you are vulnerable to your neighbor's bad security practices.

Verification: The OpenSCAP Scan

Trust, but verify. How do you prove to your boss (or the auditor) that the server is secure? We use OpenSCAP to scan against the CIS Server Level 2 profile. This is the industry standard for high-security environments.

Install the scanner (on Ubuntu 24.04 LTS):

sudo apt-get update
sudo apt-get install libopenscap8 scap-security-guide

Now, run the assessment. Be warned: Level 2 is strict. It might break poorly written apps.

oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level2_server \
  --results scan-results.xml \
  --report scan-report.html \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml

This generates an HTML report showing exactly what passed and what failed. We automate this to run weekly via Cron, sending the HTML report to an S3-compatible bucket (hosted in Europe, obviously).

Automating the Fixes

Scanning is easy. Fixing is hard. We use Ansible Galaxy roles that map directly to these CIS benchmarks. However, blind automation is dangerous. I once locked myself out of a production server because a CIS script decided to disable all SSH ciphers except `chacha20-poly1305`, and my local client was outdated.

Here is how we verify the connection before applying the firewall rules:

- name: Ensure UFW is installed
  apt:
    name: ufw
    state: present

- name: Allow SSH before enabling UFW
  ufw:
    rule: allow
    name: OpenSSH

- name: Enable UFW
  ufw:
    state: enabled
    policy: deny

The Latency-Security Trade-off

Security adds overhead. Every packet inspection, every encrypted tunnel, and every audit log write consumes CPU cycles and I/O. In high-frequency trading or real-time bidding, this matters.

We benchmarked a fully hardened Ubuntu 24.04 instance with full disk encryption (LUKS) and aggressive audit logging (`auditd`).

The difference lies in the underlying storage and CPU allocation. Security tools like `auditd` hammer the disk with log writes. If your VPS is running on standard SSDs behind a choked I/O controller, your application will crawl. CoolVDS NVMe instances handle the high IOPS required by heavy logging without impacting the application performance. This allows us to keep the security setting at "Paranoid" without killing user experience.

Final Thoughts: Compliance is a Process, Not a Destination

By November 2025, the digital regulatory environment in Europe has tightened. Using a provider outside the EEA for sensitive data is a calculated risk that most CTOs shouldn't take. By combining a sovereign infrastructure foundation with automated enforcement tools like Ansible and OpenSCAP, you turn compliance from a yearly panic attack into a daily routine.

Don't wait for the audit letter to arrive. Spin up a fresh instance, pull down the CIS benchmarks, and see where you stand. If your current provider blocks you from setting kernel flags, it’s time to migrate.

Ready to harden your stack? Deploy a compliant-ready KVM instance on CoolVDS today and get full root control in under 55 seconds.