Stop Treating Compliance Like a Spreadsheet

If you are still manually editing /etc/ssh/sshd_config on your production servers in July 2022, you have already lost. In the current operational climate, where the Schrems II ruling has effectively weaponized data sovereignty, relying on manual checklists is not just inefficient—it is negligent.

We talk to CTOs in Oslo and Bergen every week who are terrified of one thing: Configuration Drift. You harden a server on Monday. By Wednesday, a junior dev has opened port 8080 for debugging. By Friday, you are non-compliant with GDPR. And when the auditors from Datatilsynet come knocking, your manual Excel sheet of "security policies" will not save you.

This guide ignores the fluff. We are going to build a pipeline that enforces security at the kernel level, verifies it automatically, and runs on infrastructure that keeps your data legally on Norwegian soil.

The Architecture of "Compliance as Code"

Security cannot be an afterthought applied to a running VPS. It must be baked into the provisioning process. We define this in three stages:

1. Define: Infrastructure as Code (Terraform) to set boundaries.
2. Harden: Configuration Management (Ansible) to apply CIS Benchmarks.
3. Verify: OVAL/XCCDF Scanning (OpenSCAP) to generate evidence.

Stage 1: The Hardening Layer

We rely on Ansible because agents are heavy and proprietary scanners are expensive. Standardize on the CIS (Center for Internet Security) Benchmarks. Below is a realistic example of how we enforce SSH security programmatically.

Don't just set PermitRootLogin no. You need to handle ciphers and MACs to avoid downgrade attacks.

# tasks/ssh_hardening.yml
- name: Ensure SSH Protocol is set to 2
  lineinfile:
    dest: /etc/ssh/sshd_config
    regexp: '^Protocol'
    line: 'Protocol 2'
    state: present

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

- name: Limit SSH Ciphers to strong algorithms
  lineinfile:
    dest: /etc/ssh/sshd_config
    regexp: '^Ciphers'
    line: 'Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com'
    state: present

This is a fragment. A full role would also configure ClientAliveInterval (to kill stale sessions) and strict ownership of keys. When deploying on CoolVDS NVMe instances, this playbook executes in seconds because we don't throttle your I/O.

Stage 2: Kernel & Network Hardening

Filesystem permissions are table stakes. The real battle is in the kernel. By default, most Linux distros are tuned for compatibility, not security. We need to disable IP forwarding (unless it's a router) and tighten ICMP handling to mitigate DDoS fingerprinting.

Here is a snippet for /etc/sysctl.d/99-security.conf management:

# sysctl hardening
net.ipv4.ip_forward = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.log_martians = 1
kernel.sysrq = 0

Pro Tip: Always set kernel.randomize_va_space = 2 (ASLR) to make buffer overflow attacks significantly harder. On virtualized hardware, ensure your hypervisor exposes the correct CPU flags to support this efficiently. CoolVDS KVM nodes pass through host CPU flags to ensure ASLR works with zero performance penalty.

Stage 3: Automated Verification with OpenSCAP

Hardening is useless without proof. OpenSCAP is the industry standard for checking compliance against XCCDF profiles. It is lightweight, open-source, and verifiable.

First, install the security guides (on Ubuntu 20.04/22.04):

Now, run a scan against the CIS Level 1 Server profile. This command generates an HTML report you can literally hand to an auditor.

#!/bin/bash
# run_audit.sh

PROFILE="xccdf_org.ssgproject.content_profile_cis_level1_server"
CONTENT="/usr/share/xml/scap/ssg/content/ssg-ubuntu2004-ds.xml"
REPORT="/var/www/html/security-report-$(date +%F).html"

echo "Starting OpenSCAP Audit..."
oscap xccdf eval \
  --profile $PROFILE \
  --report $REPORT \
  $CONTENT

if [ $? -eq 0 ]; then
    echo "Compliance Status: PASS"
else
    echo "Compliance Status: FAIL - Check Report at $REPORT"
fi

Running this weekly via Cron ensures you catch drift immediately. If you try running heavy SCAP scans on oversold shared hosting, your CPU credits will vanish, and the scan might time out. This is why dedicated resources are not a luxury for compliance; they are a requirement.

The "Schrems II" Reality Check

Technical implementation is only half the battle. In 2022, where your code runs matters as much as how it runs.

Since the Schrems II ruling invalidated the Privacy Shield, storing personal data of Norwegian citizens on US-controlled cloud infrastructure (even if the datacenter is in Frankfurt) puts you in a legal grey zone. The US CLOUD Act allows American authorities to request data from US companies regardless of server location.

Why Latency Matters for Security

This sounds counter-intuitive, but low latency improves security posture. When you run centralized log aggregation (SIEM) using tools like Wazuh or ELK, you are streaming gigabytes of logs in real-time. High latency or packet loss causes log buffers to fill up on the agent side, leading to dropped events. A dropped log could be the trace of an intrusion.

With CoolVDS peering directly at NIX (Norwegian Internet Exchange), the path between your servers and your local office (or local SIEM) is negligible. You see the attack as it happens, not 500ms later.

Implementing the Fix

You don't need a team of 20 to be compliant. You need to automate the basics.

1. Provision a CoolVDS instance (Debian 11 or Ubuntu 22.04).
2. Bootstrap it with a cloud-init script that pulls your Ansible repo.
3. Schedule OpenSCAP to run every Sunday night.

Here is a final cloud-init snippet to get you started immediately upon boot:

#cloud-config
package_update: true
packages:
  - ansible
  - git
  - libopenscap8

runcmd:
  - git clone https://github.com/your-org/security-playbooks.git /opt/hardening
  - ansible-playbook -i "localhost," -c local /opt/hardening/site.yml
  - systemctl restart sshd

Security is not a product; it is a process. But it helps when the underlying infrastructure isn't fighting against you. By choosing a provider that respects Norwegian data sovereignty and provides the raw I/O performance needed for constant auditing, you turn compliance from a quarterly nightmare into a daily background task.

Don't wait for the breach. Deploy a hardened, compliant environment today.