Surviving the Audit: Automating Security Compliance on Norwegian VPS Infrastructure

It has been less than a month since May 25th, 2018. The GDPR panic emails have finally stopped flooding our inboxes, but for those of us managing infrastructure, the real work has just begun. If you are a CTO or Lead Sysadmin operating in the Nordic market, the realization is settling in: Manual security hardening is no longer just inefficient; it is a legal liability.

I recently consulted for a fintech startup in Oslo that was scrambling to meet Datatilsynet requirements. They had twelve developers spinning up instances, applying firewall rules by hand, and forgetting to disable root login. When the audit came, they failed. Not because they didn't know security, but because they lacked consistency.

In this guide, we aren't discussing vague "best practices." We are implementing Compliance as Code using Ansible and OpenSCAP on high-performance KVM instances. We will focus on data residency in Norway and how to lock down a standard CentOS 7 or Ubuntu 18.04 server automatically.

The Jurisdiction Trap: Why Hardware Location Matters

Before we touch a single config file, we must address the physical layer. Under GDPR, you are the Data Controller. If you host on a US-owned cloud provider, even in a European region, you navigate a complex legal gray area involving the CLOUD Act (passed just this March).

This is why pragmatic architects are moving critical datasets to local providers. CoolVDS operates out of Oslo with strict adherence to Norwegian privacy laws. Using a CoolVDS NVMe instance ensures that the physical drive resides within the EEA, simplifying your Data Processing Agreements (DPA) significantly.

Phase 1: The Base Hardening with Ansible

Scripts fail. Playbooks describe a state. We want to ensure that every new VPS provisioned—whether it's a staging server or production database—starts with the same security posture.

Here is a production-ready Ansible task list for 2018-era hardening. This specifically targets SSH, which is your primary attack vector.

# hardening.yml
- 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
      notify: Restart SSH

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

    - name: Set Idle Timeout Interval
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^ClientAliveInterval'
        line: 'ClientAliveInterval 300'
        state: present

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

Running this against a fresh CoolVDS instance takes about 15 seconds. Doing it manually takes 5 minutes and introduces human error.

Phase 2: Automated Vulnerability Scanning with OpenSCAP

Hardening is useless if you don't verify it. OpenSCAP (Security Content Automation Protocol) is the industry standard for checking Linux systems against known benchmarks, such as the PCI-DSS or CIS profiles.

On a CentOS 7 system, install the scanner and the security guides:

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

Now, let's run a scan against the SSG CentOS 7 XCCDF benchmark. This is resource-intensive. On legacy spinning rust (HDD) VPS providers, I have seen this scan cause I/O wait times to spike above 40%, effectively killing the web server during the audit. This is where the NVMe storage on CoolVDS becomes critical; the high IOPS capability allows the read-heavy audit to finish in under two minutes without starving your application threads.

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

Pro Tip: Don't just run this once. Add a cron job to run this scan weekly and email the HTML report to your security team. Compliance is a continuous state, not a one-time checkbox.

Phase 3: Network Level Protection (Firewalld & Fail2Ban)

In 2018, automated botnets are scanning the entire IPv4 range constantly. If you leave port 22 open to the world, your logs will fill with brute-force attempts within the hour. We need a dynamic defense.

We use firewalld for static rules and fail2ban for reactive banning. Here is a robust configuration for jail.local to protect your SSH daemon:

[sshd]
enabled = true
port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
maxretry = 3
bantime = 3600
findtime = 600

Combined with `ipset`, this efficiently drops packets from repeat offenders. While CoolVDS includes standard DDoS protection at the network edge, host-level mitigation is required for application-layer attacks and slow brute-force attempts.

Phase 4: Web Server Encryption (TLS 1.2 Only)

With Chrome and Firefox flagging HTTP sites as "Not Secure" starting later this year, and PCI-DSS requiring the removal of TLS 1.0, your Nginx config needs an update. We strongly recommend using the Mozilla Intermediate configuration.

Inside your nginx.conf, avoid the defaults. Explicitly define your cipher suites to prioritize Forward Secrecy (FS):

ssl_protocols TLSv1.2 TLSv1.3; # TLS 1.3 is draft/experimental in OpenSSL 1.1.1, stick to 1.2 for stability if unsure
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

The Total Cost of Ownership (TCO)

Many CTOs look at the raw price of a VPS—say, 50 NOK/month—and stop there. They forget the cost of the engineer spending four hours recovering a hacked server or the fine from a data breach.

Conclusion

GDPR is here to stay. The days of "Cowboy DevOps"—where we SSH into production and edit files with nano—are over. You need audit trails, you need reproducible infrastructure, and you need a hosting partner that understands the legal landscape in Norway.

By combining Ansible for consistency, OpenSCAP for verification, and CoolVDS for a reliable, local hardware foundation, you turn compliance from a nightmare into a cron job.

Ready to harden your infrastructure? Deploy a KVM instance on CoolVDS today and get full root access to build your compliance fortress.