The Panic is Over. The Work Begins.

May 25th has come and gone. The emails about privacy policy updates have finally stopped clogging our inboxes. But for those of us managing infrastructure in Norway and the EEA, the real headache has just started. Datatilsynet (The Norwegian Data Protection Authority) is not looking for intent; they are looking for documentation.

As a CTO, I see too many teams treating compliance as a checkbox exercise performed once a year. That is a recipe for disaster. In a dynamic environment where you are spinning up VPS instances to handle traffic spikes, manual security hardening is negligence. If a server goes live for 10 minutes with default credentials or weak ciphers, you are vulnerable.

We need to move from "Security by Checklist" to "Security as Code." In this guide, I will detail how we automate server hardening on CoolVDS infrastructure using Ansible and OpenSCAP, ensuring that every byte stored in Oslo remains compliant with Article 32 of the GDPR.

The Core Problem: Configuration Drift

I recall a project earlier this year involving a financial services client in Bergen. They had strict ISO 27001 requirements. Their production environment was pristine. But their dev/staging environment? It was the Wild West. Developers were turning off firewalls "just to test connectivity" and forgetting to turn them back on. This is configuration drift.

To solve this, we define the state of our infrastructure. We do not SSH into servers to fix things; we push code.

Pro Tip: Never rely on the default image provided by any host without immediate hardening. While CoolVDS provides clean, minimal templates (CentOS 7 and Ubuntu 18.04 LTS), it is your responsibility to lock the doors immediately upon boot.

Step 1: The Base Hardening Playbook

We use Ansible (currently version 2.6) because it is agentless. You do not need to install extra software on your CoolVDS instance to manage it; you just need SSH. Below is a snippet from our standard `common-security.yml` playbook that we run against every new node.

This specifically targets the SSH daemon, which is the primary attack vector for Linux servers.

- name: Secure SSH Configuration
  hosts: all
  become: yes
  tasks:
    - name: Disable Root Login
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^PermitRootLogin'
        line: 'PermitRootLogin no'
        state: present
      notify: restart ssh

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

    - name: Ensure Protocol 2 is enforced
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^Protocol'
        line: 'Protocol 2'
        state: present

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

This automation ensures that no matter who provisions the server, root login is dead on arrival.

Step 2: Kernel & Network Hardening

GDPR requires us to implement "appropriate technical measures." Tuning the Linux kernel to resist DDoS attacks and IP spoofing is exactly that. We apply these settings via `sysctl`.

On high-performance NVMe instances like those from CoolVDS, you also want to ensure that security doesn't kill I/O throughput. However, network stack hardening is non-negotiable.

# /etc/sysctl.d/99-security.conf

# IP Spoofing protection
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Ignore ICMP broadcast requests
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Disable source packet routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

# SYN Flood protection
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 2

To apply this via Ansible:

- name: Apply sysctl security settings
  sysctl:
    name: "{{ item.key }}"
    value: "{{ item.value }}"
    state: present
    reload: yes
  with_dict:
    "net.ipv4.conf.all.rp_filter": "1"
    "net.ipv4.icmp_echo_ignore_broadcasts": "1"
    "net.ipv4.tcp_syncookies": "1"

Step 3: Automated Auditing with OpenSCAP

Hardening is good. Proving it is better. For this, we use the OpenSCAP ecosystem. It allows us to scan our servers against the Security Content Automation Protocol (SCAP) standards.

For a Centos 7 server hosted in Norway handling personal data, we often check against the PCI-DSS profile or the standard SSG (SCAP Security Guide).

Installation and Scan

yum install openscap-scanner scap-security-guide -y

# Run a scan and generate an HTML report
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_pci-dss \
--results result.xml \
--report report.html \
/usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml

This command generates a `report.html`. This file is gold. It shows exactly where you fail compliance (e.g., "Ensure /tmp is a separate partition" or "Ensure auditd is enabled"). You can attach this report directly to your internal audit documentation.

Data Sovereignty and the "Cloud Act" Factor

Here is the uncomfortable truth about hosting in 2018: If you host on a US-owned cloud provider, the US CLOUD Act (signed earlier this year) technically allows US law enforcement to demand data stored on foreign soil.

For Norwegian entities, or European companies handling sensitive data, this creates a legal grey area that makes legal counsels nervous. This is where CoolVDS becomes a strategic asset, not just a vendor.

We use KVM virtualization on CoolVDS because it provides strict memory and CPU isolation. Unlike container-based virtualization (OpenVZ/LXC), KVM ensures that your kernel memory is not accessible by a noisy neighbor. This isolation is a critical component of a "defense in depth" strategy.

Continuous Updates: Unattended Upgrades

The WannaCry ransomware attack last year taught us that patching speed matters. You cannot rely on a sysadmin remembering to run `apt-get upgrade`. On Ubuntu 18.04 servers, we configure `unattended-upgrades` to handle security patches automatically.

// /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}";
        "${distro_id}:${distro_codename}-security";
        // We strictly limit this to security updates to avoid breaking changes
};

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

Is there a risk an update breaks something? Yes. Is that risk lower than running a vulnerable kernel with known exploits? Absolutely.

Conclusion: Sleep Better

Compliance isn't about paperwork; it's about architecture. By leveraging Ansible for consistent configuration and OpenSCAP for verification, you transform security from a manual burden into an automated standard.

You need a foundation that respects data sovereignty and offers the raw I/O performance required for encryption overhead. Don't let slow hardware be the excuse for turning off security features.

Secure your infrastructure today. Deploy a hardened KVM instance on CoolVDS in Oslo and keep your data strictly under Norwegian jurisdiction.