Zero-Trust in 2023: Stop Trusting Your Internal Network

"But the server is behind the VPN."

If I had a krone for every time I heard this before a post-mortem meeting, I could buy the entire Aker Brygge waterfront. The traditional "castle-and-moat" strategy—where you harden the perimeter and assume everything inside is friendly—is not just outdated; it is negligent. In October 2023, with lateral movement attacks becoming automated and ruthless, trusting a packet just because it has a local IP address is a career-ending mistake.

We are going to build a Zero-Trust Architecture (ZTA). No buzzwords. No expensive vendor appliances. Just pure Linux primitives, cryptography, and a philosophy that treats every single request as hostile until proven otherwise. We will cover Mutual TLS (mTLS), identity-aware proxies, and why hosting this on high-performance infrastructure like CoolVDS in Norway isn't just a performance tweak—it's a compliance necessity under GDPR and Schrems II.

The Core Problem: Lateral Movement

I recently audited a setup for a logistics firm in Oslo. They had a rock-solid firewall. But one developer's laptop was compromised via a phishing email. Because that laptop was connected to the corporate OpenVPN with a 10.8.0.0/24 IP, the attacker had unrestricted access to the database port 5432. The firewall saw "internal traffic" and let it pass.

Zero Trust dictates: Identity is the new perimeter.

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

Passwords are leaked. API keys are committed to GitHub. Certificates, however, are harder to fake if managed correctly. We replace standard authentication with mTLS. Here, the server verifies the client's certificate, and the client verifies the server's. If you don't have the cert, the TCP handshake drops.

This adds overhead. Every handshake requires asymmetric encryption math. This is where hardware matters. On budget VPS providers, I've seen mTLS introduce 50-100ms of latency during high concurrency. On CoolVDS, where we have dedicated CPU cycles and no noisy neighbors stealing verify time, the impact is negligible.

Here is a hardened Nginx configuration for mTLS on Ubuntu 22.04:

server {
    listen 443 ssl http2;
    server_name api.internal.yoursystem.no;

    # Server Certificate
    ssl_certificate /etc/nginx/certs/server.crt;
    ssl_certificate_key /etc/nginx/certs/server.key;

    # Client Certificate Verification (The Zero Trust Part)
    ssl_client_certificate /etc/nginx/certs/ca.crt;
    ssl_verify_client on;
    ssl_verify_depth 2;

    # Optimization for 2023 standards
    ssl_protocols TLSv1.3;
    ssl_prefer_server_ciphers off;
    
    location / {
        # Pass the common name to the backend for audit logging
        proxy_set_header X-Client-DN $ssl_client_s_dn;
        proxy_pass http://127.0.0.1:8080;
    }
}

Pro Tip: Never use a public CA (like Let's Encrypt) for ssl_client_certificate. Build your own internal PKI using step-ca or HashiCorp Vault. You want to control issuance and revocation instantly.

Phase 2: The Network Overlay (WireGuard Mesh)

Forget IPsec. It's bloated and difficult to audit. WireGuard is part of the Linux kernel (since 5.6) and is the standard for secure point-to-point meshes in 2023. Unlike a hub-and-spoke VPN, we want a mesh where every node can talk only to specific peers.

However, WireGuard is UDP. Some restrictive corporate firewalls block UDP. A robust Zero-Trust implementation accounts for this fallback, but for server-to-server communication within Europe, UDP is king for speed.

Here is a configuration for a database node that only accepts traffic from the app server, encrypted at the kernel level:

# /etc/wireguard/wg0.conf on Database Node
[Interface]
Address = 10.100.0.2/32
SaveConfig = false
PrivateKey = <DB_PRIVATE_KEY>
ListenPort = 51820

# Application Server Peer
[Peer]
PublicKey = <APP_PUBLIC_KEY>
AllowedIPs = 10.100.0.1/32
# If the app server is behind NAT, use PersistentKeepalive
PersistentKeepalive = 25

Combine this with nftables to drop everything else on the physical interface:

# Reject everything on eth0 except WireGuard and SSH
nft add rule inet filter input iifname "eth0" udp dport 51820 accept
nft add rule inet filter input iifname "eth0" tcp dport 22 accept
nft add rule inet filter input iifname "eth0" drop

Phase 3: Identity-Aware SSH

Static SSH keys (id_rsa) are a nightmare. You can't expire them easily. In a Zero-Trust model, engineers exchange their identity (via OIDC/Keycloak) for a short-lived SSH certificate.

We use a Certificate Authority (CA) to sign user keys. The server trusts the CA, not the specific user key.

1. Generate the CA on a secure machine:

ssh-keygen -t ed25519 -f ssh_user_ca -C "CA"

2. Configure the target server (/etc/ssh/sshd_config):

TrustedUserCAKeys /etc/ssh/ssh_user_ca.pub
AuthenticationMethods publickey

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

ssh-keygen -s ssh_user_ca -I "dev-ops-user" -n root,deploy -V +1h user_key.pub

If a developer leaves the company, you don't need to touch the servers. You just stop signing their keys. This is crucial for maintaining control in dynamic environments.

The Latency & Sovereignty Factor

Here is where physics meets compliance. Zero Trust requires constant verification. Every request triggers an authentication check, often against a central Identity Provider (IdP) like Keycloak or Dex.

If your infrastructure is in Oslo, but your IdP is hosted on a US cloud provider's "European" region in Dublin or Frankfurt, you are adding 30-50ms round-trip time (RTT) to every single request initiation. For a microservices architecture, this compounds rapidly.

The CoolVDS Advantage:

• Local Peering: By hosting both your services and your IdP on CoolVDS in Norway, latency drops to sub-2ms. The handshake is instant.
• Datatilsynet Compliance: Under Schrems II, transferring metadata (like IP addresses in auth logs) to US-owned clouds is legally risky. CoolVDS is a Nordic entity. Data stays here.
• NVMe Performance: Logging is the heavy lifter in Zero Trust. You need to log every allowed and denied packet for auditing. Our NVMe storage arrays handle high-write log ingestion without blocking your application threads.

Comparison: Zero Trust Overhead

Conclusion

Implementing Zero Trust is not about buying a product; it's about architectural discipline. It forces you to clean up your network, rotate your secrets, and acknowledge that the threat is already inside the building.

Do not let infrastructure bottlenecks derail your security posture. Encryption is CPU intensive. Logging is I/O intensive. You need hardware that keeps up.

Stop guessing. Start verifying. Deploy a high-performance Keycloak instance and your first WireGuard mesh on CoolVDS today. Your future security audit will thank you.