Automating Security Compliance: Surviving Datatilsynet with OpenSCAP and Ansible

If you are still manually editing /etc/ssh/sshd_config on every new server deployment, you are already non-compliant. In the current regulatory climate—where Datatilsynet (The Norwegian Data Protection Authority) is watching closely and GDPR fines are becoming a reality—reliance on human memory for server hardening is professional negligence.

We saw it with the massive CNIL fine against Google earlier this year. The message is clear: data protection isn't just about cookie banners; it's about the fundamental integrity of the infrastructure holding that data. For CTOs and Systems Architects operating in Norway and the EU, "Security by Design" is no longer a buzzword. It is a legal requirement under GDPR Article 25.

This guide moves beyond theory. We will build a compliance pipeline using Ansible for configuration management and OpenSCAP for automated auditing, specifically targeting the CIS (Center for Internet Security) benchmarks on a standard Ubuntu 18.04 LTS instance running on CoolVDS.

The Myth of the "Secure" Cloud

Many hosting providers claim their platform is "secure." This is a dangerous half-truth. They secure the physical perimeter and the hypervisor (hopefully). But once you spin up a VPS, the operating system is your responsibility. A fresh install of CentOS 7 or Ubuntu 18.04 is designed for compatibility, not security. It comes with open ports, permissible file systems, and chatty network protocols.

Furthermore, if you are hosting sensitive data on US-owned cloud giants, you are navigating a legal minefield regarding the EU-US Privacy Shield. The safest architectural decision for European businesses today is ensuring data never leaves the EEA. This is why we insist on Data Sovereignty. Hosting on CoolVDS guarantees your bits reside physically in Norway, subject to Norwegian law, not the US CLOUD Act.

Step 1: The Baseline – Infrastructure as Code

Consistency is the enemy of risk. We define our security baseline in code. We will use Ansible to enforce a hardened state. This playbook focuses on three critical vectors: SSH, Firewall, and Kernel parameters.

Hardening SSH

The default SSH configuration is too promiscuous. We need to disable root login, enforce key-based authentication, and remove weak ciphers. Here is a production-ready Ansible task list for 2019-era hardening:

---
- name: Harden SSH Configuration
  hosts: all
  become: yes
  tasks:
    - name: Ensure SSH Protocol 2 is used
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^Protocol'
        line: 'Protocol 2'
        state: present

    - name: Disable Root Login
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^PermitRootLogin'
        line: 'PermitRootLogin no'
        state: present

    - name: Disable Password Authentication
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^PasswordAuthentication'
        line: 'PasswordAuthentication no'
        state: present

    - name: MaxAuthTries set to 3
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^MaxAuthTries'
        line: 'MaxAuthTries 3'
        state: present
    
    - name: Restart SSH
      service:
        name: sshd
        state: restarted

Pro Tip: Before applying PasswordAuthentication no, ensure you have deployed your public SSH keys to the ~/.ssh/authorized_keys file. If you lock yourself out, you will have to use the VNC console in the CoolVDS dashboard to recover access. It works, but it’s a walk of shame you want to avoid.

Step 2: Kernel Hardening via Sysctl

Network stack hardening prevents common DDoS vectors like SYN floods and IP spoofing. While CoolVDS provides upstream DDoS protection, your OS should not be the weak link.

Add these configurations to /etc/sysctl.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

Apply them immediately without rebooting:

Step 3: Automated Auditing with OpenSCAP

You have applied your configs. How do you prove it to an auditor? This is where OpenSCAP comes in. It is an open-source tool that scans your system against the Security Content Automation Protocol (SCAP) standards.

First, install the scanner and the security guides on your Ubuntu 18.04 instance:

Now, run a scan against the standard profile. This will generate an HTML report highlighting every failed check.

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

You can download scan-report.html via SCP and open it in your browser. It provides a pass/fail status for hundreds of parameters, including file permissions, package integrity, and service configurations.

Step 4: AuditD – The Black Box Recorder

Compliance requires traceability. If a breach occurs, you need to know what happened. The Linux Audit Daemon (auditd) allows you to log specific system calls. For a high-compliance environment, we monitor changes to the user database and system time.

Here is a robust /etc/audit/audit.rules configuration for 2019 standards:

# Delete all existing rules
-D

# Buffer Size
-b 8192

# Failure Mode (2=shutdown, 1=printk, 0=silent)
-f 1

# Watch critical files for write access or attribute changes
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k identity

# Monitor system time changes
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time-change
-a always,exit -F arch=b32 -S adjtimex -S settimeofday -k time-change
-w /etc/localtime -p wa -k time-change

# Lock the configuration (must be the last rule)
-e 2

Restart the daemon to apply:

Why Underlying Architecture Matters

Software hardening is futile if the virtualization layer is compromised. This is why we avoid container-based virtualization (like OpenVZ) for high-security workloads. In those environments, you share the kernel with every other tenant on the host node. A kernel panic triggered by a neighbor brings you down; a kernel exploit could theoretically leak your memory.

CoolVDS uses KVM (Kernel-based Virtual Machine). Each instance runs its own isolated kernel. This provides a hard boundary between your data and the rest of the infrastructure. Combined with our NVMe storage backend, this ensures that security overhead doesn't kill your I/O performance.

Comparison: OpenVZ vs KVM for Security

Conclusion: Automation is Your Safety Net

In 2019, security is a process, not a state. By combining the strict isolation of KVM, the speed of NVMe storage, and the automation of Ansible and OpenSCAP, you create an environment that is hostile to attackers but transparent to auditors.

Do not wait for a breach or a Datatilsynet inquiry to take this seriously. Start with a clean slate.

Deploy a KVM instance on CoolVDS today, clone our Ansible hardening role, and sleep better knowing your infrastructure is compliant by design.