Automating CIS Compliance: Surviving Schrems II with OpenSCAP and Ansible in Norway

The Auditor is Coming, and Excel Sheets Won't Save You

If you are still managing server compliance with a spreadsheet and a manual checklist, you are already behind. In the current regulatory climate—specifically after the CJEU's Schrems II ruling—compliance has shifted from a "nice-to-have" to a critical survival metric for any CTO operating in the EEA. The Norwegian Data Protection Authority (Datatilsynet) is not known for its leniency regarding international data transfers.

Here is the hard truth: You can harden your kernel until it's bulletproof, but if that kernel is running on a hypervisor owned by a US-based hyperscaler, you have a legal vulnerability that iptables cannot block. This is why architecture matters as much as configuration.

In this guide, we are going to automate the implementation of the CIS (Center for Internet Security) Benchmark Level 2 on an AlmaLinux 8 node. We will use OpenSCAP to find the holes and Ansible to patch them. We do this on CoolVDS infrastructure because, frankly, keeping the physical data inside Norway is the only way to sleep soundly when the legal team starts asking questions.

The Foundation: Why Data Sovereignty is the First Security Layer

Before we touch a single config file, we must address the infrastructure. Post-2020, reliance on US cloud providers (AWS, Azure, GCP) introduces a complexity regarding the US CLOUD Act. Even with Standard Contractual Clauses (SCCs), the legal footing is shaky.

For our clients in finance and healthcare, we deploy on CoolVDS NVMe instances located in Oslo. Why? Because low latency to the Norwegian Internet Exchange (NIX) is great for performance, but knowing the physical drives are under Norwegian jurisdiction is essential for GDPR compliance. You cannot automate legal jurisdiction, but you can choose the right vendor.

Step 1: The Audit (OpenSCAP)

Stop guessing your security posture. We use the Security Content Automation Protocol (SCAP) to validate our servers against industry standards. On RHEL-based systems like AlmaLinux 8 (the stable successor to CentOS), this is straightforward.

First, install the scanner and the security guides:

sudo dnf install -y openscap-scanner scap-security-guide

Now, let's identify the CIS Level 2 Server profile. This profile is strict. It is intended for environments where security is paramount, often at the expense of some usability.

oscap info /usr/share/xml/scap/ssg/content/ssg-almalinux8-ds.xml

Once you have identified the profile ID (usually xccdf_org.ssgproject.content_profile_cis), run a scan. This command generates a human-readable HTML report and an XML results file.

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

Pro Tip: Do not run this on a production database during peak hours. The SCAP scanner is thorough and CPU-intensive. Run it on a staging clone first—CoolVDS snapshots make this trivial (clone, scan, destroy in under 10 minutes).

Step 2: Remediation with Ansible

A scan report is useless if you don't fix the findings. Manual remediation is error-prone. We use Ansible to enforce the state. Below is a targeted playbook that addresses three common failures in a fresh provisioning: SSH root login, chrony configuration, and kernel parameter hardening.

The Playbook: harden_cis.yml

---# Target: CoolVDS AlmaLinux 8 Instance# Objective: CIS Level 2 Partial Remediation- hosts: all  become: yes  vars:    sysctl_config:      - { 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.icmp_echo_ignore_broadcasts', value: '1' }  tasks:    - name: "CIS 5.2.5 - Ensure SSH root login is disabled"      lineinfile:        path: /etc/ssh/sshd_config        regexp: '^PermitRootLogin'        line: 'PermitRootLogin no'        state: present      notify: restart_sshd    - name: "CIS 1.5.1 - Ensure Core Dumps are restricted"      sysctl:        name: fs.suid_dumpable        value: '0'        state: present        reload: yes    - name: "CIS 3.2.1 - Network Kernel Hardening"      sysctl:        name: "{{ item.key }}"        value: "{{ item.value }}"        state: present        reload: yes      loop: "{{ sysctl_config }}"  handlers:    - name: restart_sshd      service:        name: sshd        state: restarted

This is declarative security. If a junior admin accidentally enables root login effectively creating a backdoor, the next Ansible run closes it immediately.

Step 3: Advanced Audit Logging

Compliance requires evidence. The auditd subsystem is your flight recorder. However, the default rules are often too quiet. For CIS compliance, we need to track changes to the system time, user/group modification, and network configuration.

Add these rules to /etc/audit/rules.d/audit.rules:

## CIS 4.1.4 - Record events that modify date and time-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time-change-a always,exit -F arch=b64 -S clock_settime -k time-change-w /etc/localtime -p wa -k time-change## CIS 4.1.5 - Record events that modify user/group information-w /etc/group -p wa -k identity-w /etc/passwd -p wa -k identity-w /etc/gshadow -p wa -k identity-w /etc/shadow -p wa -k identity

Reload the audit daemon cleanly to apply changes without a reboot:

service auditd reload

Performance Considerations on Virtualized Hardware

Security has a cost. Enabling strict auditing and SELinux (which you must keep Enforcing) consumes CPU cycles. On older VPS platforms with spinning rust (HDD), enabling full audit logging could cause I/O wait times to spike, killing your application performance.

This is where the underlying hardware of CoolVDS becomes a strategic asset. Our infrastructure utilizes enterprise-grade NVMe storage. High I/O throughput means the system can write thousands of audit logs per second without blocking your database queries. We have benchmarked this extensive logging on our standard 4 vCPU instances, and the overhead is negligible—less than 1.5% CPU impact.

Comparison: Hardening Impact on I/O

Conclusion: Sovereignty is the Strategy

In 2022, you cannot separate code from geography. A script can secure a port, but it cannot secure a jurisdiction. By combining OpenSCAP for visibility, Ansible for enforcement, and CoolVDS for data sovereignty, you build a fortress that satisfies both the hacker and the auditor.

Don't wait for a letter from Datatilsynet to audit your stack. Deploy a hardened, compliant environment today.

Ready to lock it down? Spin up an AlmaLinux 8 instance on CoolVDS in Oslo now and test your Ansible roles on true NVMe power.