Console Login

Automating Security Compliance: From "Schrems II" Anxiety to DevSecOps Reality

Automating Security Compliance: From "Schrems II" Anxiety to DevSecOps Reality

If you are still managing your infrastructure compliance using Excel spreadsheets and annual audits, you are already compromised. It might not be a hacker today; it might be a Data Protection Authority audit tomorrow.

Since the Schrems II ruling in July 2020, the legal ground under European tech companies has shifted violently. The reliance on US-based cloud providers has transitioned from "standard practice" to "calculated risk." As a CTO or Lead Architect, you face two distinct battles: technical hardening against intrusion and legal hardening against data sovereignty violations. You cannot solve the latter with code, but you must solve the former with automation.

This article details how to move from reactive compliance to Continuous Compliance using open-source tooling available right now in 2021, and why the physical location of your kernel is just as critical as the configuration of your firewall.

The Myth of the "Secure Cloud"

Many DevOps teams assume that spinning up an instance on a major hyperscaler implies a baseline of security. This is the "Shared Responsibility Model" trap. The provider secures the concrete floor; you are responsible for the walls, windows, and locks. If you deploy a default Ubuntu 20.04 image and fail to disable password authentication or leave root login enabled, the fastest NVMe storage in the world won't save you from a botnet.

Furthermore, in the context of the Norwegian Datatilsynet, technical measures are only half the battle. If your encrypted data sits on a disk controlled by a legal entity subject to the US CLOUD Act, your compliance posture is fragile. This is where CoolVDS differs. By hosting on Norwegian soil, under Norwegian jurisdiction, we eliminate the complex legal gymnastics required to justify data transfers outside the EEA. But hardware sovereignty is useless if your software is leaking.

Tooling: OpenSCAP and CIS Benchmarks

To automate security, we need a standard. The Center for Internet Security (CIS) Benchmarks are the industry gold standard for hardening. Implementing these manually on every VPS is impossible at scale. Enter OpenSCAP.

OpenSCAP allows us to scan systems against a specific profile (like CIS or PCI-DSS) and generate reports. It is lightweight, agentless if needed, and brutally honest.

Step 1: Installation and Scanning

On a standard CoolVDS instance running Ubuntu 20.04 LTS (Focal Fossa), installing the scanner and the security guides is straightforward:

sudo apt-get update sudo apt-get install libopenscap8 ssg-base ssg-deb ssg-modules ssg-utils

Once installed, do not guess your security posture. Measure it. The following command runs a scan against the CIS Level 2 Server benchmark. Level 2 is for environments where security is paramount, potentially at the cost of some usability—exactly what you want for a backend database or production web server.

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

This command compares your current system state against hundreds of rules defined in the XCCDF checklist. The output is an HTML report that usually scares the hell out of junior admins because it turns the screen red with failures.

Pro Tip: Do not run a "remediation" scan (which automatically fixes issues) on a production server without testing. OpenSCAP remediation can lock you out of your own server if it decides your SSH configuration is too weak.

Remediation as Code: The Ansible Approach

Finding holes is easy; patching them without breaking the application is the job. While OpenSCAP can generate bash scripts to fix issues, using Ansible is far superior for state management and idempotency. If you manage a fleet of VPS Norway instances, you want a playbook that ensures compliance is enforced every time it runs.

Here is a snippet of an Ansible role designed to enforce a critical CIS requirement: SSH Hardening. This ensures only public key authentication is allowed and root login is disabled.

---
- name: Hardening 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
        validate: 'sshd -t -f %s'
      notify: restart sshd

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

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

  handlers:
    - name: restart sshd
      service:
        name: sshd
        state: restarted

By integrating this into your CI/CD pipeline (Jenkins, GitLab CI), every deployment automatically enforces security standards. Security is no longer a gatekeeper that slows you down; it is part of the infrastructure definition.

The Performance Impact of Security

A common objection to heavy encryption and logging is the performance penalty. "Won't auditd logging kill my I/O?" In 2015, on spinning rust (HDD), perhaps. In 2021, on CoolVDS NVMe storage, the overhead is negligible.

We specifically tune our KVM virtualization layer to handle high interrupt loads generated by intensive logging and encrypted traffic. When we talk about "low latency," we aren't just talking about the ping to Oslo; we are talking about the time it takes for the kernel to write an audit log to disk and return control to the application. On our infrastructure, enabling full audit logging costs you microseconds, not milliseconds.

Feature Generic Cloud VPS CoolVDS NVMe Instance
Disk Encryption I/O Often throttled (IOPS limits) Native NVMe Speed (Pass-through)
Data Sovereignty Unclear (US Jurisdiction) 100% Norwegian (GDPR Safe)
Kernel Access Restricted / Shared Kernel (Containers) Full KVM Isolation

Data Sovereignty is the Ultimate Compliance

You can script firewalls. You can automate patch management. But you cannot script geography. In the wake of Schrems II, many Norwegian businesses are realizing that where the data lives is a security feature.

If you automate your CIS benchmarks using the tools above, but host that data on a server where a foreign government can compel access, your compliance is theoretical at best. CoolVDS provides the foundational layer of physical and legal security. You control the bits; Norwegian law protects the atoms.

Next Steps

Compliance is not a destination; it is a cron job. Start by auditing your current environment.

  1. Install OpenSCAP on your staging environment.
  2. Run a CIS Level 1 scan.
  3. Write Ansible roles to fix the red lines.

If you need a sandbox to test destructive hardening scripts without risking your production environment, spin up a CoolVDS instance. With our instant provisioning, you can deploy, test, break, and redeploy a fresh server in under 60 seconds.