The Perimeter is Dead: Architecting Zero-Trust Infrastructure in Norway

Stop trusting your local network. It’s a harsh reality, but the moment you assume traffic inside your VPC or LAN is safe, you’ve already lost. The traditional "castle and moat" strategy—where a VPN acts as the drawbridge—is obsolete. Once an attacker breaches that single perimeter, lateral movement is trivial. I've seen it happen. A dev leaves a redis port open on an internal IP, thinking "it's behind the firewall." Next thing you know, the database is encrypted by ransomware.

We need Zero Trust. Never trust, always verify. Every packet, every request, every user.

This isn't just paranoia; it's a necessity, especially here in Norway where Datatilsynet is tightening the screws on GDPR compliance following Schrems II. If you can't prove strict access control, you are a liability. Here is how we build a fortress using Linux primitives, WireGuard, and mTLS on CoolVDS infrastructure.

1. The Foundation: Identity-Based Access, Not IP-Based

In 2023, IP whitelisting is insufficient. IPs change. Spoofing happens. We need cryptographic identity.

For service-to-service communication, Mutual TLS (mTLS) is non-negotiable. It ensures that not only does the client verify the server, but the server cryptographically verifies the client. This adds overhead. On cheap, oversold VPS providers, the CPU context switching required for constant handshake verification will kill your latency. This is why we rely on CoolVDS instances backed by high-frequency CPUs and NVMe storage; the cryptographic tax is negligible when the hardware isn't fighting for air.

Implementing mTLS on Nginx

Here is a battle-tested configuration for Nginx to enforce client certificate authentication. This setup assumes you have your own CA (Certificate Authority).

server {
    listen 443 ssl http2;
    server_name internal-api.coolvds-node.no;

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

    # The CA that signed the client certificates
    ssl_client_certificate /etc/nginx/ssl/ca.crt;
    
    # Force verification
    ssl_verify_client on;
    
    # Optional: Check depth to prevent long chains
    ssl_verify_depth 2;

    location / {
        proxy_pass http://localhost:8080;
        # Pass the CN to the backend for audit logs
        proxy_set_header X-Client-DN $ssl_client_s_dn;
    }
}

Pro Tip: Don't manually manage OpenSSL commands for your internal CA if you value your sanity. Use tools like cfssl or HashiCorp Vault. Rotation is the hardest part of PKI.

2. The Transport Layer: WireGuard Mesh

IPsec is bloated. OpenVPN is slow. For securing traffic between servers—say, a database node in Oslo and a backup server in Bergen—WireGuard is the only logical choice in late 2023. It lives in the kernel, it's quiet (doesn't respond to unauthenticated packets), and it's fast.

Instead of a hub-and-spoke model, we build a mesh. Every server talks directly to every other server, encrypted.

Server Config (/etc/wireguard/wg0.conf)

[Interface]
Address = 10.100.0.1/24
SaveConfig = true
PostUp = ufw route allow in on wg0 out on eth0
PostDown = ufw route delete allow in on wg0 out on eth0
ListenPort = 51820
PrivateKey = 

[Peer]
# Client: Dev-Laptop-01
PublicKey = 
AllowedIPs = 10.100.0.2/32

Bring it up:

With CoolVDS KVM virtualization, you have full kernel module access. We don't block you from loading WireGuard modules or manipulating iptables at a granular level, unlike many container-based "VPS" providers.

3. Micro-Segmentation with NFTables

Zero Trust means no open ports, even on the internal interface, unless explicitly allowed. ufw is great for simple stuff, but for Zero Trust, we often need the raw power of nftables to handle complex sets and maps.

Here is an example of an nftables config that drops everything by default and only allows specific combinations. This script prevents the "flat network" problem.

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;

        # Allow loopback
        iifname lo accept

        # Allow established/related connections
        ct state established,related accept

        # Allow SSH only from WireGuard interface (Internal Admin)
        iifname wg0 tcp dport 22 accept

        # Allow Web traffic public
        tcp dport { 80, 443 } accept

        # ICMP (Ping) with rate limiting to prevent flooding
        ip protocol icmp limit rate 1/second accept
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
    }
    chain output {
        type filter hook output priority 0; policy accept;
    }
}

This configuration ensures that SSH is invisible to the public internet. You must be on the WireGuard VPN to even see port 22. This drastically reduces the attack surface against brute-force bots targeting standard ports.

4. SSH Certificates: No More Static Keys

Static SSH keys are a nightmare to manage when an employee leaves. In a Zero Trust model, we issue short-lived SSH certificates. You authenticate via your SSO provider, receive a certificate valid for 1 hour, and use that to log in.

Signing a User Key

On your CA server (secure offline machine):

ssh-keygen -s ca_key -I key_id -n user -V +1h -z 1 user_key.pub

Configure your sshd_config on the CoolVDS instance to trust the CA:

Now, access is temporal. If a laptop is stolen, the key is useless after 60 minutes.

5. Data Sovereignty and Latency

Technical security is useless if you violate legal compliance. Storing data on US-owned clouds brings the CLOUD Act into play. By hosting on CoolVDS in Norway, you ensure your data remains under European jurisdiction.

Furthermore, Zero Trust adds latency. Handshakes, encryption, proxies. To counter this, your physical distance to the user matters. If your users are in Oslo, hosting in Frankfurt adds ~20ms round trip. Hosting in Oslo adds <2ms. When every request requires an authentication check, those milliseconds stack up.

Conclusion

Zero Trust isn't a product you buy; it's a discipline. It requires rigorous configuration of firewalls, aggressive encryption policies, and infrastructure that doesn't buckle under the load of constant verification.

Don't let your infrastructure be the weak link. You need raw compute power to handle encryption overhead and local presence to keep latency low. Deploy a KVM-based instance on CoolVDS today, configure WireGuard, and lock your doors properly.