The Perimeter is Dead: Implementing Zero-Trust Security on Norwegian Infrastructure
Stop me if you’ve heard this one before: You spend weeks configuring a Cisco ASA or a complex iptables perimeter, believing your infrastructure is a fortress. Then, a single developer’s laptop gets compromised via a phishing email, the attacker rides the VPN into your trusted zone, and suddenly that “hardened” perimeter is worthless. The network inside is soft, flat, and entirely open.
It is 2019. The traditional “Castle and Moat” security model is failing. With the rise of microservices and remote engineering teams scattered across Europe, the concept of a “trusted internal network” is a dangerous fallacy. Google proved this with BeyondCorp years ago, yet too many sysadmins in Oslo are still clinging to the idea that a VPN makes them safe.
In this architecture deep-dive, we are going to dismantle the trusted network. We will replace implicit trust with explicit verification—every user, every device, every packet. This is Zero Trust, and we’re going to build it on standard Linux tools available today.
The Norwegian Context: Data Sovereignty & The CLOUD Act
Before we touch the config files, we have to talk about jurisdiction. If you are operating here in Norway, relying on US-based cloud hyperscalers introduces a distinct vector of legal risk. The US CLOUD Act (passed last year, 2018) allows US law enforcement to compel American tech companies to provide data stored on their servers, regardless of whether that server is physically located in Frankfurt or Virginia.
For a Norwegian entity handling sensitive customer data, this is a compliance nightmare waiting to happen. The safest architectural decision is strictly separating infrastructure ownership. By deploying on CoolVDS, which is owned and operated within European legal frameworks, you add a layer of sovereignty that purely technical controls cannot provide. Your bits stay in Oslo, protected by Norwegian privacy laws and the Datatilsynet’s strict interpretation of GDPR.
Step 1: Mutual TLS (mTLS) for Service-to-Service Communication
In a Zero-Trust model, Service A should not talk to Service B just because they share a subnet. It requires cryptographic proof of identity. We achieve this with Mutual TLS. Unlike standard HTTPS where only the server proves its identity, mTLS requires the client to present a certificate signed by a trusted internal Certificate Authority (CA).
Here is how to configure Nginx to enforce mTLS. This setup assumes you have already generated your internal CA and signed a client certificate.
Nginx Configuration for mTLS
server {
listen 443 ssl http2;
server_name internal-api.coolvds.local;
# Standard Server SSL
ssl_certificate /etc/nginx/ssl/server.crt;
ssl_certificate_key /etc/nginx/ssl/server.key;
# Client Certificate Verification
ssl_client_certificate /etc/nginx/ssl/internal-ca.crt;
ssl_verify_client on;
# Optimization for handshake
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
# Pass the verified Subject DN to the application
location / {
proxy_set_header X-Client-DN $ssl_client_s_dn;
proxy_pass http://localhost:8080;
}
}
With ssl_verify_client on;, Nginx will drop the connection at the handshake level if the client (be it another microservice or a developer's workstation) does not present a valid certificate signed by your CA. No application logic required; the request never even hits your backend if the auth fails.
Pro Tip: On CoolVDS NVMe instances, the SSL handshake overhead is negligible due to the high clock speed of the underlying CPUs. Don't disable security for "performance" unless you have measured a bottleneck.
Step 2: Killing Static SSH Keys
If you are still copying `id_rsa.pub` files to `~/.ssh/authorized_keys` across 50 servers, you have a scalability and revocation problem. If a laptop is stolen, you have to scrub that key from every server. That is not Zero Trust.
The solution is an SSH Certificate Authority. You sign a user's public key with a validity period (e.g., 8 hours). When the certificate expires, access is revoked automatically.
Configuring the SSH CA
First, on your secure bastion host (or offline machine), generate the CA keys:
# Generate CA key
ssh-keygen -C "CoolVDS Internal CA" -f /etc/ssh/user_ca
# Sign a user's public key (valid for 8 hours)
ssh-keygen -s /etc/ssh/user_ca -I "johndoe_access" -n johndoe -V +8h id_rsa.pub
This generates `id_rsa-cert.pub`. Now, configure your CoolVDS destination servers to trust this CA.
/etc/ssh/sshd_config
# Trust the CA public key
TrustedUserCAKeys /etc/ssh/user_ca.pub
# Optional: Revocation list
RevokedKeys /etc/ssh/revoked_keys
# Disable password auth completely
PasswordAuthentication no
ChallengeResponseAuthentication no
Now, your engineers request a signed certificate at the start of their shift. By the time they go home, their access credential is useless. No lingering keys, no perimeter gaps.
Step 3: Micro-Segmentation with `nftables`
While `iptables` is the veteran standard, `nftables` is the modern replacement in Debian 10 and recent kernels. It allows for more atomic rule updates and better performance. In a Zero-Trust world, we default to deny.
Even inside a private VLAN provided by your host, you should lock down traffic. Here is a base configuration that drops everything except SSH and explicitly whitelisted internal traffic.
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
# Allow established/related connections
ct state established,related accept
# Allow localhost
iifname lo accept
# Allow SSH (Rate limited to prevent brute force)
tcp dport 22 ct state new limit rate 10/minute accept
# Allow internal mTLS traffic from specific subnet only
ip saddr 10.10.50.0/24 tcp dport 443 accept
# Log dropped packets (careful with disk I/O)
limit rate 5/minute log prefix "NFTABLES-DROP: "
}
chain forward {
type filter hook forward priority 0; policy drop;
}
chain output {
type filter hook output priority 0; policy accept;
}
}
This script ensures that even if an attacker pivots to a neighboring server, they cannot probe ports on this machine. They hit a wall.
Infrastructure Performance & The CoolVDS Advantage
Implementing Zero Trust adds overhead. Encryption at every layer (mTLS), constant verification, and complex packet filtering require CPU cycles. If you run this stack on oversold, budget VPS hosting where "vCPU" basically means "CPU steal time," your latency will spike. You will see SSL handshakes taking 500ms instead of 5ms.
This is why hardware transparency matters. CoolVDS utilizes KVM virtualization, which provides stronger isolation than container-based virtualization (like OpenVZ/LXC) used by budget providers. When you are encrypting all internal traffic, you need the consistent I/O of NVMe storage and dedicated CPU slices to handle the context switching. Zero Trust is a CPU-intensive architecture; treat it as such.
Conclusion
The transition to Zero Trust is not about buying a "Zero Trust Product." It is an architectural shift. It is about acknowledging that the network is hostile, even the cable plugged into eth0.
By implementing mTLS, utilizing SSH CAs, and respecting Norwegian data sovereignty, you build a system that is robust against both hackers and auditors. Start small: isolate one service, rotate your SSH keys, and ensure your hosting foundation is solid.
Ready to harden your stack? Deploy a high-performance KVM instance on CoolVDS today and build your fortress in Oslo.