Stop Treating Compliance as a Checkbox: It's an Engineering Problem

Let’s be honest. Nobody wakes up excited to read the latest guidance from Datatilsynet (The Norwegian Data Protection Authority). But after the CJEU's Schrems II ruling last year invalidated the Privacy Shield, compliance stopped being a legal department problem and became an engineering emergency. If you are hosting customer PII on US-owned infrastructure—even if that server is physically in Frankfurt or Stockholm—you are exposed to the US CLOUD Act.

The solution isn't just "move to a Norwegian host." That’s step one. Step two is proving that your infrastructure is hardened enough to deserve that data. Manual hardening is dead. If you are SSHing into a server to edit /etc/ssh/sshd_config by hand, you have already failed the audit.

We are going to look at how to automate security compliance on a CoolVDS instance running Ubuntu 20.04 LTS, aiming for CIS (Center for Internet Security) benchmarks. This approach reduces TCO and keeps the auditors happy.

The Architecture of Sovereign Compliance

Compliance requires predictability. You cannot achieve predictability on noisy, oversubscribed public clouds where your neighbor's compromised container might impact your I/O.

For this architecture, we rely on KVM-based virtualization. Unlike container-based VPS (LXC/OpenVZ), KVM provides a hard kernel isolation layer. This is non-negotiable for serious GDPR workloads. At CoolVDS, we map NVMe storage directly to these instances to ensure that the overhead of encryption-at-rest doesn't kill your transaction speeds.

1. Infrastructure as Code: The Ansible Approach

We define our security state in code. Below is a foundational Ansible playbook snippet that enforces SSH hardening. This isn't just about changing a port; it's about disabling the protocols that script-kiddies use to hammer your servers.

---
- name: Harden SSH Configuration
  hosts: all
  become: yes
  tasks:
    - name: Ensure SSH Protocol is set to 2
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^Protocol'
        line: 'Protocol 2'
        state: present

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

    - name: Disable Password Authentication
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^PasswordAuthentication'
        line: 'PasswordAuthentication no'
        state: present

    - name: Restart SSHD
      service:
        name: sshd
        state: restarted

Running this ensures every node you deploy—whether it's a test environment or your production DB in Oslo—has the exact same access surface.

2. Automated Auditing with OpenSCAP

Deploying secure configs is easy. Keeping them secure is hard. Entropy sets in. A developer enables a port for debugging and forgets to close it. This is where OpenSCAP comes in. It is the industry standard for verifying Linux configuration against the SCAP (Security Content Automation Protocol) standard.

On a CoolVDS Ubuntu 20.04 instance, install the tooling:

sudo apt-get update
sudo apt-get install libopenscap8 scap-security-guide

Now, run a scan against the standard profile. This will generate an HTML report showing exactly where you fail GDPR or PCI-DSS requirements.

sudo oscap xccdf eval \
 --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
 --results report.xml \
 --report report.html \
 /usr/share/xml/scap/ssg/content/ssg-ubuntu2004-ds.xml

Pro Tip: Don't try to fix 100% of the failures immediately. Some CIS benchmarks (like disabling all USB storage modules) might interfere with specific kernel operations depending on your virtualization drivers. Start with Level 1 Server profile and tune from there.

3. The Persistence of Logs: Auditd

If a breach happens, Datatilsynet will ask for logs. If your answer is "the attacker deleted them," start writing the check for the fine.

We configure auditd to monitor file changes in critical areas. This writes to disk, so having high-speed NVMe storage (standard on our plans) is critical to prevent logging from becoming a bottleneck.

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

# Monitor changes to the shadow file (passwords)
-w /etc/shadow -p wa -k shadow_changes

# Monitor changes to group information
-w /etc/group -p wa -k group_changes

# Monitor privilege escalation (sudo usage)
-w /etc/sudoers -p wa -k scope_changes

# Lock the configuration so it cannot be changed until reboot
-e 2

Reload the daemon:

Why Hosting Location Matters More Than Ever

You can script security all day, but you cannot script jurisdiction. In late 2021, the legal reality is that data residency is a security feature.

When you deploy on CoolVDS, your data sits in a facility protected by Norwegian privacy laws. There is no "backdoor" for foreign intelligence agencies. For a CTO, that is the ultimate risk mitigation strategy.

Conclusion: Verify, Don't Trust

Compliance is a moving target. The only way to hit it consistently is through automation and selecting the right infrastructure foundation. By combining Ansible for configuration management, OpenSCAP for continuous auditing, and CoolVDS for jurisdictional safety, you build a fortress that satisfies both the hackers and the lawyers.

Ready to audit your infrastructure? Spin up a dedicated KVM instance on CoolVDS today. With our pure NVMe storage, your OpenSCAP scans will finish before you finish your coffee.