The Perimeter is Dead: Implementing Zero Trust in a Post-Schrems II World

Stop trusting your local network. It is a lie. If the SolarWinds breach taught us anything late last year, it is that the "trusted internal network" is the most dangerous vulnerability in your stack. For years, sysadmins operated on the castle-and-moat fallacy: harden the firewall, set up a VPN, and assume everything inside the LAN is friendly. In 2021, that architecture is negligence.

For those of us operating out of Norway and the broader EEA, the challenge is twofold. Not only do we need to secure our lateral traffic against intruders, but following the CJEU's Schrems II ruling in July 2020, we must also treat data residency as a critical security component. You cannot have Zero Trust if you implicitly trust a cloud provider subject to FISA 702 warrants.

This guide ignores marketing fluff. We are going to look at how to implement actual Zero Trust principles—authenticated origins, micro-segmentation, and encryption in transit—on standard Linux VPS infrastructure available today.

1. The Legal Reality: Why Location is a Security Feature

Zero Trust dictates that you verify every request, regardless of origin. However, physical sovereignty remains the baseline. If your encrypted data sits on a hypervisor where the provider is legally compelled to provide backdoor access to foreign intelligence, your cryptographic efforts are compromised by policy.

Pro Tip: Norwegian data privacy laws are stringent. By hosting on CoolVDS, your data remains within Norwegian jurisdiction, mitigating the risks associated with the US CLOUD Act. This is the foundation upon which technical Zero Trust is built.

2. Killing the VPN: Enter WireGuard

Legacy VPNs like OpenVPN are bloated and often run in userspace, creating bottlenecks. In a Zero Trust model, we want an overlay network that treats every node as an isolated endpoint. WireGuard, which was merged into the Linux 5.6 kernel last year, is the answer. It is lean, operates in kernel space, and relies on state-of-the-art crypto (Noise protocol framework).

Instead of a hub-and-spoke VPN where clients get full network access, we use WireGuard to create point-to-point encrypted tunnels only between services that strictly require communication.

Configuration: Mesh Networking with WireGuard

On a Debian 10 (Buster) or Ubuntu 20.04 node, install WireGuard:

sudo apt update && sudo apt install wireguard

Here is a configuration for a database server that only accepts traffic from a specific application server. This denies all other traffic by default—a core Zero Trust tenet.

# /etc/wireguard/wg0.conf on Database Server
[Interface]
Address = 10.0.0.1/24
SaveConfig = true
ListenPort = 51820
PrivateKey = 

# Only allow the App Server IP
[Peer]
PublicKey = 
AllowedIPs = 10.0.0.2/32

This creates a cryptographically secured interface. Even if an attacker gains access to the public network switch, they cannot sniff or inject packets into this stream without the private keys.

3. Mutual TLS (mTLS): Authenticating Services, Not IP Addresses

IP whitelisting is fragile. IPs change, and BGP hijacking is real. In a Zero Trust architecture, services must authenticate via cryptographic identity. Mutual TLS (mTLS) ensures that the client verifies the server, and the server verifies the client.

We can implement this efficiently using Nginx. This ensures that even if someone bypasses your firewall rules, Nginx will drop the connection if the client does not present a certificate signed by your internal CA.

Generating the CA and Keys

# Create Internal CA
openssl genrsa -des3 -out ca.key 4096
openssl req -new -x509 -days 365 -key ca.key -out ca.crt

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

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

Nginx Configuration for mTLS

Add this to your Nginx server block. Note the ssl_verify_client on; directive. This is the gatekeeper.

server {
    listen 443 ssl http2;
    server_name api.internal.coolvds.net;

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

    # Enforce Client Certificates
    ssl_client_certificate /etc/nginx/certs/ca.crt;
    ssl_verify_client on;

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

If you run curl against this server without the cert, you get a 400 Bad Request immediately. No valid cert, no entry.

4. SSH Hardening: Certificates over Static Keys

Managing authorized_keys files across 50 servers is a nightmare and a security risk. If a developer's laptop is stolen, you have to scrub keys from every server. SSH Certificates (available in OpenSSH for years but rarely used) solve this. You sign a key with an expiration date. When it expires, access is revoked automatically.

Setting up the Signing Server

1. Generate a CA key on a secure, air-gapped machine (or a secure CoolVDS management instance):

ssh-keygen -f users_ca

2. Configure the target server to trust this CA by adding this to /etc/ssh/sshd_config:

TrustedUserCAKeys /etc/ssh/users_ca.pub

3. Sign a user's public key (valid for 1 hour only):

ssh-keygen -s users_ca -I user_identity -n root -V +1h user_key.pub

This generates user_key-cert.pub. The user logs in with this cert. If they leave the company or lose their laptop, you don't need to touch the server. The cert expires in an hour anyway.

5. Infrastructure Performance: The Cost of Encryption

Implementing mTLS and WireGuard adds overhead. Every packet is being encrypted and decrypted. On legacy hardware or oversold VPS hosts, this kills latency. You will see CPU steal shoot up, and I/O wait times increase as the system struggles to handle the context switches.

We optimized CoolVDS instances specifically for this workload. Our KVM implementation exposes the AES-NI instruction set directly to the guest OS, allowing hardware acceleration for encryption tasks. This is mandatory for running a Zero Trust stack without degrading user experience.

Summary

Zero Trust is not a product you buy; it is a mindset of "never trust, always verify." By moving away from static IPs and trusted LANs to cryptographic identity and micro-segmentation, you immunize your infrastructure against lateral movement attacks.

However, software architecture cannot fix physical insecurity. Hosting sensitive European data on US-controlled clouds is a compliance time bomb waiting to explode. Combine the architectural rigor of mTLS and WireGuard with the jurisdictional safety of Norwegian hosting.

Ready to harden your stack? Spin up a CoolVDS instance in Oslo. Our NVMe storage and unmetered internal networks are built for heavy encryption workloads.