Automating Security Compliance in a Post-Schrems II World: A CTO's Survival Guide

If you are still managing your infrastructure compliance using Excel spreadsheets and quarterly manual audits, you are already compromised. It is January 2022, and the landscape has shifted violently under our feet. The Norwegian Personal Data Act and the shockwaves from the Schrems II ruling have made one thing clear: data sovereignty isn't just a buzzword; it is a legal minefield.

I recently audited a fintech setup in Oslo that was technically secure but legally indefensible. They were hosting sensitive customer data on a US-owned hyperscaler. Technically, the encryption was solid. Legally? Datatilsynet (The Norwegian Data Protection Authority) would have had a field day. The transfer mechanisms were invalid.

The solution isn't just moving data back to Europe; it's proving that your local environment is as hardened as the clouds you left behind. This guide covers how to automate that proof using Infrastructure as Code (IaC) principles, specifically targeting CIS Benchmarks on Linux systems.

The "Compliance as Code" Architecture

Compliance cannot be a retrospective activity. It must be part of the deployment pipeline. We are going to build a loop that automatically scans for deviations from the Center for Internet Security (CIS) standards.

For this architecture, we rely on tools available right now in 2022:

• OpenSCAP: For automated vulnerability scanning and compliance evaluation.
• Ansible: For automated remediation.
• CoolVDS KVM Instances: Because containers (LXC/OpenVZ) often lack the kernel-level isolation required for strict CIS Level 2 compliance.

Step 1: The Baseline Hardening (SSH)

Before automating the scan, we apply a baseline. In 2022, standard SSH configurations are still too permissive. We need to disable weak ciphers explicitly. On a CoolVDS instance running AlmaLinux 8 (the robust alternative now that CentOS 8 is EOL), your /etc/ssh/sshd_config should look like this:

# /etc/ssh/sshd_config hardening
Protocol 2
LogLevel VERBOSE
MaxAuthTries 3
PermitRootLogin no

# Strong Ciphers Only (NIST 800-53 compliant)
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org

Pro Tip: Never edit this file manually in production. Use a configuration manager. If you edit manually and make a typo, you are locked out. If you use Ansible, you can validate the syntax before restarting the service.

Step 2: Automating the Audit with OpenSCAP

OpenSCAP allows us to scan against the Security Content Automation Protocol (SCAP). This isn't a vendor-proprietary tool; it is the industry standard.

First, install the scanner and the security guides on your server:

# On AlmaLinux 8 / Rocky Linux 8
sudo dnf install openscap-scanner scap-security-guide

Now, we run a scan against the CIS Server Level 2 profile. This profile is intended for environments where security is paramount and some usability functionality may be inhibited (perfect for backend database servers).

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

This command generates an HTML report showing exactly where you fail GDPR or PCI-DSS requirements. Doing this manually would take 40 hours. This command takes 45 seconds on a CoolVDS NVMe instance due to the high IOPS allowing rapid file system traversal.

Step 3: Automated Remediation with Ansible

Scanning identifies the problem. Ansible fixes it. We don't write bash scripts for this; they are brittle. We use idempotent Ansible tasks.

Here is a snippet to enforce password hashing rounds (a common failure point in audits):

- name: Ensure password hashing rounds are set to minimum 5000
  lineinfile:
    path: /etc/login.defs
    regexp: '^SHA_CRYPT_MIN_ROUNDS'
    line: 'SHA_CRYPT_MIN_ROUNDS 5000'
    state: present

- name: Set password quality requirements (pam_pwquality)
  lineinfile:
    path: /etc/security/pwquality.conf
    regexp: '^{{ item.key }}'
    line: '{{ item.key }} = {{ item.value }}'
  loop:
    - { key: 'minlen', value: '14' }
    - { key: 'dcredit', value: '-1' }
    - { key: 'ucredit', value: '-1' }
    - { key: 'ocredit', value: '-1' }
    - { key: 'lcredit', value: '-1' }

The Data Sovereignty Factor

Technology allows us to secure the OS, but it cannot solve the legal jurisdiction of the hardware. This is where the choice of provider becomes a compliance decision, not just a technical one.

Under GDPR Article 32, you must implement "appropriate technical and organisational measures." Hosting critical PII (Personally Identifiable Information) on a server where the root disk is accessible by foreign entities introduces unnecessary risk.

We built the CoolVDS platform on pure KVM virtualization. Unlike OpenVZ or LXC, KVM provides a dedicated kernel. This is mandatory for modifying kernel parameters like fs.suid_dumpable or kernel.randomize_va_space which are required by CIS benchmarks. You simply cannot achieve this level of compliance on shared-kernel container hosting.

Implementing the Loop

To finalize your automation, wrap the OpenSCAP scan in a cron job or a Jenkins pipeline that runs weekly. Pipe the failure results directly to your ticketing system (Jira or similar).

# Simple cron entry for weekly compliance checks
0 3 * * 0 /usr/bin/oscap xccdf eval --profile standard --results /var/log/oscap/$(date +\%F).xml /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml && mail -s "Security Scan Passed" admin@example.no

Security is not a product; it is a process. But in 2022, it is a process that must be automated if you want to survive the audit.

Ready to build a compliant infrastructure that keeps Datatilsynet happy? Deploy a hardened AlmaLinux 8 instance on CoolVDS today and keep your data strictly on Norwegian soil.