Kill the VPN: Implementing Zero-Trust Security for GDPR Compliance on Linux Infrastructure

Date: April 17, 2018

The deadline is May 25th. In barely a month, the General Data Protection Regulation (GDPR) goes live, and the panic in European boardrooms is palpable. If you are a systems administrator operating in Norway or the broader EU, you are likely drowning in compliance checklists. Most of them miss the point.

We spent the last decade building "castles." We dug moats (firewalls), built drawbridges (VPNs), and assumed that anyone inside the walls was a friend. That model is dead. It died the moment lateral movement became the primary vector for modern APTs (Advanced Persistent Threats). If an attacker compromises a single developer's laptop connected to your OpenVPN, they own your entire internal network.

It is time to adopt the Zero-Trust model. The philosophy is simple: The network is always hostile. Even your local LAN. Even the private interconnect between your database and your web server.

Here is how we architect this on Linux infrastructure, specifically focusing on data sovereignty within Norway to satisfy Datatilsynet requirements.

1. Identity is the New Perimeter

In a Zero-Trust architecture, IP addresses mean nothing. Spoofing an IP is trivial. We rely on cryptographic identity. For web services and APIs, this means moving beyond simple TLS encryption to Mutual TLS (mTLS).

With mTLS, the server validates the client's certificate. No certificate? No connection. It doesn't matter if the firewall is wide open (though it shouldn't be); the handshake fails immediately.

Implementing mTLS with Nginx

We use Nginx (currently stable branch 1.12 or mainline 1.13) as the gatekeeper. First, you act as your own Certificate Authority (CA) to sign client keys.

Step 1: Generate the CA and Client Keys

# Create the CA Key and Certificate
openssl genrsa -des3 -out ca.key 4096
openssl req -new -x509 -days 365 -key ca.key -out ca.crt

# Create the Client Key and CSR
openssl genrsa -des3 -out client.key 1024
openssl req -new -key client.key -out client.csr

# Sign the Client Certificate
openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out client.crt

Step 2: Configure Nginx

In your nginx.conf or sites-available config, strict verification is enforced. Note the ssl_verify_client directive.

server {
    listen 443 ssl;
    server_name api.internal.yourservice.no;

    ssl_certificate /etc/nginx/certs/server.crt;
    ssl_certificate_key /etc/nginx/certs/server.key;

    # The CA used to sign client certs
    ssl_client_certificate /etc/nginx/certs/ca.crt;
    
    # ABORT connection if no valid cert is presented
    ssl_verify_client on;

    location / {
        proxy_pass http://localhost:8080;
        # Pass SSL details to backend application for auditing
        proxy_set_header X-SSL-Client-Serial $ssl_client_serial;
        proxy_set_header X-SSL-Client-Verify $ssl_client_verify;
    }
}

Pro Tip: Do not automate the signing of client certificates without a manual approval step. If a developer's laptop is stolen, you must revoke that specific certificate immediately using a Certificate Revocation List (CRL) referenced by ssl_crl in Nginx.

2. SSH: Keys are Not Enough

Managing static SSH keys across 50 servers is a nightmare. It creates "key sprawl." When an admin leaves, you have to rotate keys on every host. If you miss one, you have a backdoor.

The solution is an SSH Certificate Authority. This has been available in OpenSSH since version 5.4, yet almost nobody uses it. It allows you to issue short-lived SSH certificates to your team. They expire automatically after 8 or 24 hours.

Configuring SSH CA on Ubuntu 16.04 LTS

On the Signing Server (The "Vault"):

# Generate the User CA key
ssh-keygen -f /etc/ssh/user_ca -C "CA for Employees"

# Sign a user's public key (valid for 8 hours only)
ssh-keygen -s /etc/ssh/user_ca -I "john_doe" -n root,deploy -V +8h id_rsa.pub

On the Target Server (CoolVDS Instance):

Edit /etc/ssh/sshd_config to trust the CA public key:

# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/user_ca.pub

# Disable password auth completely
PasswordAuthentication no
ChallengeResponseAuthentication no

Now, access requires a signed certificate. When the cert expires, access is revoked. No clean-up required.

3. The Hardware Reality: Why KVM Matters

Software security means nothing if your hypervisor leaks data. In the VPS market, many budget providers use OpenVZ or LXC containers. These share the host kernel. A kernel panic or a zero-day vulnerability in the host kernel can compromise every container on the node.

This is why CoolVDS exclusively uses KVM (Kernel-based Virtual Machine). KVM provides hardware-level virtualization. Your OS kernel is distinct from the host. This isolation is critical for GDPR compliance, specifically regarding the "integrity and confidentiality" clause.

4. Host-Level Micro-Segmentation

Cloud firewalls are great, but they are external. Once a packet hits the network interface eth0, the OS takes over. You need iptables to ensure that even if the external firewall fails, the host rejects traffic.

Here is a battle-tested iptables configuration script for a web server. It drops everything by default—the essence of Zero Trust.

#!/bin/bash
# Flush existing rules
iptables -F

# Default Policy: DROP EVERYTHING
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Allow loopback (critical for local services)
iptables -A INPUT -i lo -j ACCEPT

# Allow established connections (so you don't lock yourself out)
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow SSH (Only from VPN/Office Static IP if possible)
# Replace 1.2.3.4 with your admin IP
iptables -A INPUT -p tcp -s 1.2.3.4 --dport 22 -j ACCEPT

# Allow HTTP/HTTPS
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Log dropped packets (for auditing/GDPR)
iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "IPTables-Dropped: "

# Save rules
/sbin/iptables-save > /etc/iptables/rules.v4

5. Data Sovereignty and Latency

The GDPR imposes strict rules on data transfers outside the EU/EEA. While the Privacy Shield framework exists, privacy advocates (like Max Schrems) have challenged previous agreements, and legal uncertainty remains. Hosting data directly in Norway eliminates this legal headache.

Furthermore, physics is undefeated. If your customers are in Oslo, Bergen, or Trondheim, routing traffic through Frankfurt or London adds 20-30ms of unnecessary latency. CoolVDS infrastructure peers directly at NIX (Norwegian Internet Exchange). We see ping times as low as 2-3ms from major Norwegian ISPs.

Conclusion

Zero Trust is not a product you buy; it is a mindset. It assumes breach and demands verification for every packet. By leveraging Nginx mTLS, SSH CAs, and robust iptables configurations, you harden your infrastructure against the threats of 2018.

But software hardening requires a solid foundation. You cannot build a secure fortress on shared, oversold kernels. You need dedicated resources and strict isolation.

Next Step: Audit your current VPS. If you are running sensitive customer data on a shared-kernel container, you are non-compliant. Migrate to a KVM-based CoolVDS instance today and secure your data before May 25th.