The May 25th Deadline is Not a Suggestion: Automating Compliance on Norwegian Infrastructure

We are less than three months away from the enforcement of the General Data Protection Regulation (GDPR). If you are still managing server security via spreadsheets and manual SSH sessions, you are already behind. As a CTO, my concern isn't just the 4% global turnover fine; it's the sheer impossibility of maintaining "state" across growing infrastructure without automation.

In the Nordic market, where trust is our currency, Datatilsynet (The Norwegian Data Protection Authority) will not be lenient on negligence. The days of "security by obscurity" are dead. Today, we treat compliance as code.

This guide moves beyond high-level policy. We will look at how to automate security baselines on CentOS 7 and Ubuntu 16.04 instances using Ansible and OpenSCAP, ensuring your underlying compute—hosted right here in Norway—is audit-ready.

The Foundation: Isolation Matters

Before we touch a single line of configuration, we must address the substrate. Compliance requires strict data separation. This is why at CoolVDS, we exclusively utilize KVM (Kernel-based Virtual Machine) virtualization. Unlike OpenVZ or LXC containers where the kernel is shared, KVM provides a hardware-level virtualization boundary.

When you are storing sensitive customer data to meet Norwegian privacy standards, shared kernel vulnerabilities are an unacceptable risk. You need a dedicated kernel, and you need to know exactly where that physical drive sits. In our case: Oslo.

Phase 1: Hardening via Ansible

Consistency is the enemy of risk. We use Ansible (currently version 2.4) because it is agentless and audit-friendly. Below is a production-grade playbook snippet we use to enforce a baseline security posture. This disables root login, enforces SSH key authentication, and configures the firewall.

secure_baseline.yml

---
- hosts: secure_nodes
  become: yes
  vars:
    ssh_port: 22
    allowed_users: ['deploy', 'admin']

  tasks:
    - name: Ensure SSH Protocol 2 is enforced
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^Protocol'
        line: 'Protocol 2'
        state: present
      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

    - name: Install UFW (Ubuntu/Debian)
      apt: name=ufw state=present
      when: ansible_os_family == "Debian"

    - name: Deny all incoming by default
      ufw:
        policy: deny
        direction: incoming
      when: ansible_os_family == "Debian"

  handlers:
    - name: restart_sshd
      service: name=ssh state=restarted

This playbook does more than just configure; it documents your security state. When an auditor asks how you secure access, you don't show them a policy document nobody reads—you show them the code that enforces it every hour.

Phase 2: Automated Auditing with OpenSCAP

Hardening is one thing; proving it is another. For this, we utilize the Security Content Automation Protocol (SCAP). The oscap tool allows us to scan a server against standard profiles, such as the PCI-DSS or the Common Industry Benchmarks.

On a CentOS 7 instance (common in enterprise environments), you can install the scanner and the security guides directly from the repo:

sudo yum install openscap-scanner scap-security-guide

Once installed, you can run a compliance scan. This command checks the system against the standard RHEL/CentOS 7 profile and generates an HTML report of failures.

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

Pro Tip: Do not run high-intensity scans on production databases during peak hours. While CoolVDS NVMe storage handles high I/O remarkably well (thanks to the low latency of the NVMe interface compared to SATA SSDs), the CPU overhead of checksumming thousands of system files can trigger alerts in your monitoring stack.

Phase 3: Data Residency and The Cloud Act Anxiety

While the technical configuration is solvable via the methods above, the legal layer remains complex. With the recent pass of the CLOUD Act in the US, many European CTOs are rightfully nervous about hosting data with American hyperscalers. The jurisdiction of your data is defined by the physical location of the server and the legal domicile of the provider.

This is where local topology wins. By deploying on CoolVDS, your data resides in Norwegian data centers, governed by Norwegian law. We provide low-latency connectivity to the NIX (Norwegian Internet Exchange), ensuring that your traffic doesn't needlessly hair-pin through Frankfurt or London unless you want it to.

Performance vs. Encryption

GDPR Article 32 explicitly mentions encryption. However, encrypting data at rest (LUKS) and in transit (TLS 1.2/1.3) introduces overhead. This is often where budget VPS providers fail—they oversell CPU cycles (CPU steal time), causing encrypted connections to lag.

To mitigate this, ensure your web server is configured to prioritize modern ciphers that utilize hardware acceleration (AES-NI). Here is a snippet for your Nginx configuration to ensure you are getting A+ ratings on SSL Labs without killing your CPU:

ssl_protocols TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

The Verdict

Compliance is not a checkbox; it is a continuous loop of deployment, scanning, and remediation. By March 2018, manual administration is professional malpractice.

You need three things to survive the coming regulatory shift:

1. Code: Ansible playbooks to enforce state.
2. Verification: OpenSCAP to prove state.
3. Infrastructure: A provider that guarantees isolation and sovereignty.

Don't wait for a letter from Datatilsynet. Audit your infrastructure today.

Need a compliant sandbox? Deploy a fresh CentOS 7 instance on CoolVDS in under 55 seconds and run your first OpenSCAP scan immediately.