Zero Trust: Because the Call Is Coming From Inside the House

The traditional "castle and moat" security model assumed anything inside the corporate VPN was safe. With remote work and sophisticated phishing now the norm, that assumption is fatal.

Never Trust, Always Verify

Zero Trust isn't a product, it's a philosophy. It assumes a breach has already happened. Every request — whether from the CEO's laptop or a database server — must be authenticated and authorized explicitly.

Implementing in .NET & Azure

We implement this through identity-aware proxies and micro-segmentation:

• Identity as the perimeter: IP addresses don't matter. Only valid OAuth2 tokens, issued through Entra ID (or your identity provider of choice), grant access — an Azure App Proxy or equivalent identity-aware proxy sits in front of every internal app, not just the ones facing the internet.
• Least privilege: a service accessing the database should only have permission to read the specific table it needs, not the whole database. Role assignments should map to what a service actually does, not to a convenient shared "app service" account reused everywhere.
• Network segmentation: Network Security Groups (or your cloud's equivalent) enforce that a compromised container in one segment can't reach a database in another just because they're both "inside" the same VPC. The segment boundary matters as much as the identity boundary.

Implementing Zero Trust reduces the blast radius of any attack. If one container is compromised, the attacker finds themselves in a sealed room, not the main hallway. Rolling it out is rarely a single project — the practical order is usually identity first (strong auth, short-lived tokens), then least-privilege access reviews, then network segmentation last, since segmentation is the change most likely to break something that currently "just works" on implicit trust.