The Perimeter is Dead. Long Live Identity.

If 2020 taught us anything, it's that the "castle-and-moat" security strategy is obsolete. We sent everyone home in March, punched holes in our firewalls to allow RDP and VPN access, and prayed. The result? The attack surface didn't just expand; it exploded.

I still see sysadmins in Oslo clinging to the idea that a VPN makes them safe. It doesn't. Once an attacker compromises a single endpoint—phishing a developer or exploiting a weak home router—they are inside your network. They have lateral movement. They own the castle.

The only viable path forward for serious infrastructure in Europe right now is Zero Trust. Never trust, always verify. Every request, every packet, every time.

The Schrems II Reality Check

Before we touch the config files, let's address the elephant in the server room. The CJEU's Schrems II ruling this July invalidated the Privacy Shield. If you are moving PII (Personally Identifiable Information) between EU/EEA citizens and US-controlled cloud providers, you are walking a legal minefield.

Datatilsynet (The Norwegian Data Protection Authority) is not bluffing on this. Zero Trust isn't just about hackers; it's about data sovereignty. By architecting your infrastructure on local Norwegian ground—using a provider like CoolVDS that guarantees data stays within the kingdom—you solve the physical layer of trust. But you still need to solve the logical layer.

Step 1: Mutual TLS (mTLS) for Service-to-Service Communication

In a traditional setup, your database trusts connections from your web server's IP. In Zero Trust, IP addresses are circumstantial evidence, not proof of identity. We need cryptographic proof.

We implemented mTLS (Mutual TLS) on a high-availability cluster last month. Instead of just the server presenting a certificate, the client (your web app) must present one too. If the certificate isn't signed by your internal CA, the handshake fails before a single byte of application data is exchanged.

Here is a production-ready snippet for nginx.conf to enforce mTLS. This assumes you have already generated your internal CA and client keys.

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

    # Standard SSL Config
    ssl_certificate /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;
    
    # The Zero Trust Magic
    ssl_client_certificate /etc/nginx/ssl/internal-ca.crt;
    ssl_verify_client on;
    
    # Optimize for latency (Crucial for Oslo-London hops)
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;

    location / {
        if ($ssl_client_verify != SUCCESS) {
            return 403;
        }
        proxy_pass http://backend_service;
    }
}

Pro Tip: Enabling ssl_verify_client adds overhead to the TLS handshake. On standard shared hosting, this latency kills performance. This is why we deploy on CoolVDS NVMe instances; the high clock speed CPUs handle the cryptographic load without stalling the request queue.

Step 2: WireGuard over OpenVPN

OpenVPN is heavy, slow, and runs in userspace. For a Zero-Trust mesh where every server talks to every other server securely, we need something lighter. Enter WireGuard.

Since making it into the Linux 5.6 kernel earlier this year, WireGuard has become my default for encrypted overlays. It has a tiny attack surface (around 4,000 lines of code vs OpenVPN's 100,000+). It is also stateless, which means it handles mobile/roaming connections far better than IPsec.

Here is how to set up a peer-to-peer encrypted link between two nodes:

1. Generate Keys

wg genkey | tee privatekey | wg pubkey > publickey

2. Configure the Interface (wg0.conf)

[Interface]
Address = 10.0.0.1/24
SaveConfig = true
PrivateKey = 
ListenPort = 51820

[Peer]
PublicKey = 
AllowedIPs = 10.0.0.2/32

3. Bring it Up

wg-quick up wg0
systemctl enable wg-quick@wg0

With this setup, you can firewall off port 22 (SSH) to the entire world and only allow it via the WireGuard interface (10.0.0.x). It renders port scanners useless.

Step 3: Micro-Segmentation with iptables

Even with mTLS and WireGuard, you must assume a breach will happen. If an attacker compromises your web server, can they reach the database? Yes. Can they reach the backup server? They shouldn't be able to.

We use iptables (or nftables if you're feeling adventurous) to enforce strict micro-segmentation. Forget simple VLANs; we lock down process communication.

Here is a restrictive rule set that drops everything by default—the core philosophy of Zero Trust.

# Flush existing rules
iptables -F

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

# Allow loopback
iptables -A INPUT -i lo -j ACCEPT

# Allow established connections (keep your SSH alive)
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow WireGuard VPN traffic
iptables -A INPUT -p udp --dport 51820 -j ACCEPT

# Allow SSH ONLY from WireGuard Interface
iptables -A INPUT -i wg0 -p tcp --dport 22 -j ACCEPT

# Allow HTTP/HTTPS from everywhere (public facing)
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

The Hardware Reality: Isolation Matters

Software configuration is only half the battle. If you are running these secure configurations on a container-based VPS (like OpenVZ/LXC), you are sharing a kernel with your neighbors. If a neighbor exploits a kernel vulnerability, your Zero-Trust architecture crumbles.

This is the fundamental reason we advocate for KVM (Kernel-based Virtual Machine) virtualization, which is the standard at CoolVDS. KVM provides hardware-level virtualization. Your RAM is yours. Your Kernel is yours. Your SEContext is yours. In a regulatory environment tightening around GDPR and data privacy, "noisy neighbors" are a security risk, not just a performance nuisance.

Summary

Implementing Zero Trust in late 2020 isn't about buying a shiny new "security appliance" from a vendor. It's about architecture:

1. Identity First: Use mTLS to verify machines, not IPs.
2. Encryption Everywhere: WireGuard for the transport layer.
3. Micro-segmentation: Default deny policies in iptables.
4. Sovereignty: Host data in Norway to satisfy Datatilsynet and Schrems II requirements.

Security is a process, not a product. But having the right foundation helps. Start by auditing your current iptables rules and ask yourself: "Why do I trust this IP address?" If you don't have a good answer, block it.

Ready to lock down your infrastructure? Spin up a KVM-based, NVMe-powered instance on CoolVDS today and start building your Zero Trust perimeter in Oslo.