Automating Security Compliance: From Datatilsynet Audits to CI/CD Pipelines

If you are still manually editing /etc/ssh/sshd_config on your production servers, you are already compromised. It is not a matter of if, but when a configuration drift leaves a door open that shouldn't be there.

In the wake of Schrems II and the tightening grip of GDPR, relying on US-based hyperscalers has become a legal minefield for Norwegian CTOs. But data sovereignty is only half the battle. You can host your data in a nuclear bunker in Oslo, but if your systems administration practices are stuck in 2015, the location doesn't matter. I recently audited a fintech setup where the infrastructure was "compliant" on paper, yet a junior developer had temporarily opened port 3306 to the world for debugging and forgot to close it. The firewall rules were manually applied. No logs, no alerts, just a ticking time bomb.

Security is not a state; it is a continuous loop. In this article, we will dismantle manual hardening and replace it with immutable infrastructure pipelines using Terraform, Ansible, and OpenSCAP, specifically tailored for environments running on high-performance platforms like CoolVDS.

The Architecture of "Compliance as Code"

The goal is simple: no human logs into a server to configure it. We define the desired state in code, and the machines enforce it. This reduces the risk of "fat-finger" errors and ensures that every single VDS instance you spin up is identical to the others.

1. Provisioning with Terraform

Before we touch the OS, we define the infrastructure. Using Terraform allows us to version control our network topology. Whether you are using a generic provider or the CoolVDS API (which offers granular control over NVMe storage allocation), the principle remains: define your firewall at the edge.

Here is a simplified HCL snippet representing a restrictive security group policy. Notice we aren't allowing traffic from 0.0.0.0/0 for SSH.

resource "openstack_networking_secgroup_rule_v2" "ssh_rule" {
  direction         = "ingress"
  ethertype         = "IPv4"
  protocol          = "tcp"
  port_range_min    = 22
  port_range_max    = 22
  remote_ip_prefix  = "192.168.1.0/24" # VPN Gateway only
  security_group_id = "${var.secgroup_id}"
}

Pro Tip: Never expose management ports to the public internet, even with fail2ban. Use a WireGuard bastion host or a VPN gateway. The latency on CoolVDS instances within Norway is typically under 5ms, so the VPN overhead is negligible.

2. Hardening with Ansible (CIS Benchmarks)

Once the VDS is running, we need to lock it down. The Center for Internet Security (CIS) benchmarks are the gold standard. Implementing these manually is tedious. Implementing them via Ansible is scalable.

Below is a production-grade Ansible task list that disables unused filesystems—a common vector for privilege escalation attacks. This uses the modprobe configuration to ensure these modules can't be loaded.

- name: "Ensure unused filesystems are disabled"
  ansible.builtin.copy:
    dest: "/etc/modprobe.d/CIS.conf"
    content: |
      install cramfs /bin/true
      install freevxfs /bin/true
      install jffs2 /bin/true
      install hfs /bin/true
      install hfsplus /bin/true
      install squashfs /bin/true
      install udf /bin/true
      install vfat /bin/true
    owner: root
    group: root
    mode: '0644'
  notify: Unload modules

We also need to secure the network stack. Linux defaults are designed for compatibility, not security. We need to prevent source routing and ICMP redirects to stop Man-in-the-Middle (MITM) attacks.

- name: "Network Hardening: Sysctl settings"
  ansible.posix.sysctl:
    name: "{{ item.key }}"
    value: "{{ item.value }}"
    state: present
    reload: yes
  loop:
    - { key: 'net.ipv4.conf.all.accept_redirects', value: '0' }
    - { key: 'net.ipv4.conf.default.accept_redirects', value: '0' }
    - { key: 'net.ipv4.conf.all.secure_redirects', value: '0' }
    - { key: 'net.ipv4.conf.all.send_redirects', value: '0' }
    - { key: 'net.ipv4.icmp_echo_ignore_broadcasts', value: '1' }

3. Validation with OpenSCAP

You have deployed your code. How do you prove to Datatilsynet (The Norwegian Data Protection Authority) that you are compliant? You don't send them your Ansible playbooks; you send them an audit report.

OpenSCAP is a powerful tool for scanning your system against the Security Content Automation Protocol (SCAP) standards. It checks the actual runtime configuration against the policy.

Here is how you run a vulnerability scan on a Red Hat or Ubuntu based system:

# Install OpenSCAP scanner
sudo apt-get install libopenscap8

# Download the OVAL definitions (Ubuntu 22.04 example)
wget https://security-metadata.canonical.com/oval/com.ubuntu.jammy.cve.oval.xml.bz2
bunzip2 com.ubuntu.jammy.cve.oval.xml.bz2

# Run the evaluation and generate an HTML report
oscap oval eval --report report.html com.ubuntu.jammy.cve.oval.xml

This report generates a readable HTML file showing exactly which CVEs affect your system and which configuration rules passed or failed.

The Sovereignty & Performance Nexus

Automation solves the configuration problem, but it doesn't solve the jurisdiction problem. This is where infrastructure choice becomes a compliance decision. Hosting sensitive Norwegian user data on US-controlled clouds (even if the region is "EU-North") introduces legal ambiguity regarding the CLOUD Act.

We built CoolVDS to offer a binary alternative: pure European jurisdiction with raw KVM performance. Unlike container-heavy services where "noisy neighbors" can steal CPU cycles via micro-architectural exploits, CoolVDS provides strict resource isolation.

When running database clusters that require high IOPS—like a sharded PostgreSQL setup—latency kills performance. By utilizing local NVMe storage on CoolVDS, we eliminate the network hop required by SAN-based block storage, often reducing disk wait times by 40-60%. This performance headroom is critical when running encryption-at-rest (LUKS), which is mandatory for GDPR compliance.

Final Thoughts: The Cost of Inaction

The era of manual sysadmin work is over. If you cannot destroy your entire infrastructure and rebuild it from code in under an hour, you do not have a disaster recovery plan; you have a hope and a prayer.

By combining Ansible for idempotent configuration, OpenSCAP for verification, and a sovereign host like CoolVDS for legal safety, you create a fortress that satisfies both the auditors and the engineers. Don't wait for the breach letter to arrive.

Ready to harden your stack? Spin up a CoolVDS instance in Oslo today and benchmark your compliance pipelines against a true NVMe backend.