Automating GDPR & CIS Compliance: A CTO’s Guide to Hardening Linux Infrastructure in Norway

If you are still manually editing /etc/ssh/sshd_config on your production servers, you are already non-compliant. In the current regulatory climate—defined by strict enforcement from Datatilsynet (The Norwegian Data Protection Authority) and the legal fallout of Schrems II—security cannot be a "best effort" manual process. It must be code.

I recently audited a fintech startup in Oslo. They had robust encryption policies on paper, but their actual infrastructure told a different story. Root logins were permitted, SELinux was set to permissive because "it broke the app," and their kernel patch levels were three months behind. One nmap scan was all it took to expose liabilities that could have cost them 4% of their global turnover.

Compliance isn't about checking boxes for an auditor once a year. It is about Continuous Configuration Management. Here is how we build a self-healing, compliant infrastructure stack using OpenSCAP and Ansible, specifically tailored for the Norwegian market where data sovereignty is non-negotiable.

The Sovereignty Baseline: Why Location Matters

Before touching a single config file, we must address the infrastructure layer. Since the CJEU's Schrems II ruling, relying on US-owned cloud providers involves complex Transfer Impact Assessments (TIAs). The simplest path to compliance is data residency.

Pro Tip: Data residency is not just about where the drive spins. It's about who holds the keys to the building. We deploy on CoolVDS because their NVMe storage arrays are physically located in Norwegian datacenters, governed strictly by Norwegian law, not the US CLOUD Act. This eliminates an entire category of legal risk immediately.

Step 1: Automated Vulnerability Scanning with OpenSCAP

We don't guess if a server is secure. We measure it against the Center for Internet Security (CIS) benchmarks. In late 2023, the industry standard tool for this on RHEL/AlmaLinux/Rocky systems is OpenSCAP.

First, install the scanner and the security guides on your CoolVDS instance:

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

Once installed, you can scan your system against the CIS Server Level 2 profile. This is a rigorous standard suitable for environments handling sensitive data.

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-almalinux9-ds.xml

This command generates a human-readable HTML report. When I first run this on a generic, unoptimized VPS from budget providers, the compliance score usually hovers around 40%. On a standard CoolVDS image, we start higher because the base templates are clean, but "clean" isn't "compliant." We need to get that score to 100%.

Step 2: Remediation via Ansible

Don't fix the issues manually. If you fix it by hand, you'll forget to do it on the next server you spin up for Black Friday traffic. Use Ansible.

Below is a production-grade Ansible playbook snippet that enforces critical SSH configurations required by most GDPR implementations regarding access control. This ensures we disable root login and enforce empty password rejection.

Hardening SSH Configuration

---
- name: Harden SSH Configuration for CIS Compliance
  hosts: production_servers
  become: yes
  tasks:
    - name: Ensure SSH Protocol is set to 2
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^Protocol'
        line: 'Protocol 2'
        state: present
        validate: 'sshd -t -f %s'

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

    - name: Disable Empty Passwords
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^PermitEmptyPasswords'
        line: 'PermitEmptyPasswords no'
        state: present
        notify: Restart SSH

    - name: Set Max Auth Tries
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^MaxAuthTries'
        line: 'MaxAuthTries 4'
        state: present

  handlers:
    - name: Restart SSH
      service:
        name: sshd
        state: restarted

This playbook does more than change a file; it validates the configuration using sshd -t before applying it, preventing you from locking yourself out—a common disaster when hardening remote servers.

Step 3: Database Encryption at Rest

For applications handling Norwegian personal numbers (fødselsnummer) or payment data, database encryption is mandatory. While CoolVDS provides encrypted NVMe storage at the block level, you should also configure application-level encryption.

If you are using MariaDB (common in the Nordic hosting stack), verify your my.cnf includes the data-at-rest encryption settings. This was a critical update in the 10.x series that many sysadmins overlooked.

[mysqld]
plugin-load-add=file_key_management.so
file_key_management_filename=/etc/mysql/encryption/keyfile.enc
file_key_management_filekey=FILE:/etc/mysql/encryption/keyfile.key
file_key_management_encryption_algorithm=AES_CTR

innodb_encrypt_tables=FORCE
innodb_encrypt_log=ON
innodb_encryption_threads=4

Setting innodb_encrypt_tables=FORCE prevents any developer from accidentally creating an unencrypted table. It enforces security by default.

Step 4: Audit Logging for Datatilsynet

If a breach occurs, the first thing authorities ask for is logs. "We didn't see anything" is not a legal defense. You need auditd configured to watch sensitive files.

Here is a configuration to monitor changes to the /etc/passwd file. Add this to /etc/audit/rules.d/audit.rules:

-w /etc/passwd -p wa -k identity_change
-w /etc/group -p wa -k identity_change
-w /etc/shadow -p wa -k identity_change
-w /etc/sudoers -p wa -k privileged_actions

Reload the audit daemon:

Now, every time a user is added or a permission is changed, it is logged with a searchable key. This satisfies the accountability principle of GDPR.

Infrastructure Performance vs. Security Overhead

A common objection I hear from CTOs is that security agents kill performance. "We can't run FIPS mode or rigorous auditing because of latency."

This is where hardware choice becomes architectural destiny. On legacy spinning rust or oversold VPS platforms, high I/O wait times caused by audit logging can indeed cripple a database. However, this is a hardware bottleneck, not a software fault.

We utilize CoolVDS specifically because the KVM visualization layer passes through CPU instructions like AES-NI efficiently. This allows us to run full disk encryption and real-time audit logging without degrading the user experience. You get compliance without the latency penalty.

The Final Verdict

Compliance in 2023 is not a document; it is the state of your servers at any given millisecond. By combining the raw, sovereign power of CoolVDS's Norwegian infrastructure with the automation of Ansible and OpenSCAP, you transform compliance from a quarterly panic into a daily routine.

Do not wait for a letter from the authorities to audit your stack. Deploy a compliant baseline today.

Ready to harden your infrastructure? Spin up a CoolVDS instance in Oslo and start your scan in under 60 seconds.