Automating the Audit: Infrastructure Compliance in a Post-Schrems II World

If you are still manually editing /etc/ssh/sshd_config on your production servers, you have already failed. In the current regulatory climate—specifically looking at the aggressive stance taken by Datatilsynet (The Norwegian Data Protection Authority) regarding data transfers—security is no longer just about keeping hackers out. It is about proving to an auditor that your infrastructure was compliant at 03:00 AM last Tuesday.

The Schrems II ruling effectively killed the Privacy Shield framework. For those of us managing critical data in Norway and Europe, this created a massive headache: relying on US-owned hyperscalers is now a legal gray area that requires endless risk assessments. The pragmatic solution? Move the data closer to home and automate the hell out of the security layer.

I want to walk you through how we architect "Audit-Ready" infrastructure. We aren't just talking about firewalls; we are talking about immutable infrastructure state enforced by code.

The "War Story": When Manual Hardening Fails

In early 2021, I audited a fintech startup based in Oslo. They had decent security hygiene, or so they thought. They followed the CIS (Center for Internet Security) benchmarks. But they applied them manually.

During a penetration test simulation, we found a single developer had temporarily enabled PasswordAuthentication yes on a staging server to copy some logs via SCP because he lost his private key. He forgot to revert it. That server was a gateway to their internal Redis cluster. A simple brute-force attack would have cracked it in hours. Manual processes drift. Code does not.

Step 1: Infrastructure as Code (IaC) is Non-Negotiable

Compliance documentation usually demands that you define who has access to what. If you use a GUI to configure your firewall, you have no audit trail. By using tools like Terraform or Ansible, the configuration is the documentation.

At CoolVDS, we encourage clients to treat their VPS instances as cattle, not pets. Use Cloud-Init or Ansible to bootstrap security immediately upon provisioning. Here is a snippet of an Ansible role we use to enforce strict SSH configurations across all Norwegian nodes:

- name: Secure SSH Configuration
  lineinfile:
    dest: /etc/ssh/sshd_config
    regexp: "^{{ item.key }}"
    line: "{{ item.key }} {{ item.value }}"
    state: present
    validate: '/usr/sbin/sshd -t -f %s'
  with_items:
    - { key: "PermitRootLogin", value: "no" }
    - { key: "PasswordAuthentication", value: "no" }
    - { key: "X11Forwarding", value: "no" }
    - { key: "MaxAuthTries", value: "3" }
    - { key: "Protocol", value: "2" }
  notify: restart sshd

This ensures that every time the playbook runs, the server is forced back into compliance. If a junior admin changes a setting manually, the next automation run fixes it and logs the change.

Step 2: Automated Auditing with OpenSCAP

You can harden a server, but how do you prove it matches the standard? This is where OpenSCAP shines. It scans your system against a standard profile (like CIS or PCI-DSS) and generates a report.

For a Red Hat/CentOS based system (common in enterprise environments), you can install the scanner and the security guides:

yum install openscap-scanner scap-security-guide

To run a compliance scan against the PCI-DSS profile on a CoolVDS instance running CentOS 7/8:

oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_pci-dss \
  --results /var/www/html/compliance/scan-report.xml \
  --report /var/www/html/compliance/scan-report.html \
  /usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml

We often set this as a cron job. The output is a detailed HTML report showing exactly which kernel parameters or package versions failed the check. You can hand this directly to an auditor.

Pro Tip: Running full system scans consumes significant I/O. On budget HDDs, this can cause "iowait" spikes that slow down your application. This is why CoolVDS standardizes on NVMe storage. The high IOPS capability means you can run heavy security audits in the background without degrading the performance of your Nginx or MySQL processes.

Step 3: File Integrity Monitoring (FIM)

GDPR requires you to detect breaches quickly. If an attacker injects a backdoor into /bin/ls or modifies your nginx.conf, you need to know instantly. AIDE (Advanced Intrusion Detection Environment) creates a database of file hashes and checks against them.

Initialize the database:

aide --init
mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

Add a crontab entry to run the check daily and email the differences:

0 4 * * * /usr/sbin/aide --check | /bin/mail -s "Daily AIDE Report - $(hostname)" security@yourcompany.no

The CoolVDS Factor: Jurisdiction as a Feature

You can automate every security control in the book, but you cannot automate jurisdiction. If your server physically resides in a data center owned by a US company, it is subject to the US CLOUD Act, regardless of where the data center is located. This is the core friction of Schrems II.

For Norwegian businesses, the simplest path to compliance is reducing the scope of foreign data transfers. CoolVDS infrastructure is owned and operated within the EEA, with servers located in Oslo. This provides two distinct advantages:

1. Legal Clarity: Your data stays under Norwegian and European law.
2. Low Latency: Physics still applies. A packet round-trip from Oslo to a generic "EU-North" region (often in Ireland or Sweden) takes 15-30ms. Local routing in Oslo is often sub-2ms.

Configuring Auditd for Forensic Logging

Finally, to truly satisfy the "Accountability" principle of GDPR, you must log suspicious events. The Linux audit daemon (auditd) is powerful but noisy. Here is a pragmatic configuration snippet for /etc/audit/rules.d/audit.rules that tracks permission changes (chmod/chown) and file deletion, without logging every single file read:

# Delete rules
-D

# Buffer Size
-b 8192

# Failure Mode (1=printk, 2=panic)
-f 1

# Monitor for permission changes
-a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod

# Monitor for file deletions
-a always,exit -F arch=b64 -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete

# Lock the configuration
-e 2

Note the -e 2 flag. This makes the audit configuration immutable until the next reboot. Even root cannot change the logging rules without restarting the server—a massive win for integrity.

Conclusion

Compliance is a moving target, but your infrastructure foundation shouldn't be. By combining robust automation tools like Ansible and OpenSCAP with sovereign hosting on CoolVDS, you shift the conversation from "Are we secure?" to "Here is the report proving we are secure."

Don't wait for a letter from Datatilsynet to take this seriously. Spin up a compliant, NVMe-powered instance in Oslo today and lock it down before you even deploy your first container.