What is Zero Trust Architecture?
Introduction to Zero Trust
For decades, corporate security relied on the “Castle and Moat” model.
The IT department built a heavily defended perimeter (the Moat) using corporate firewalls and VPNs. Everything outside the firewall (the internet) was considered dangerous. Everything inside the firewall (the corporate intranet) was implicitly trusted.
If an employee logged into the office Wi-Fi, the network assumed they were friendly. They had open access to internal file servers, databases, and printers without needing to re-authenticate.
This model breaks down against modern attacks. Attackers do not need to break down the castle walls; they can send a phishing email to an HR employee. Once the attacker steals the HR employee’s password and gets inside, the internal network treats them as “trusted,” letting them move laterally and reach the production database.
Zero Trust Architecture (ZTA) is the security model that replaces the Castle and Moat. Its defining principle is simple: Never Trust, Always Verify.
The Core Principles of Zero Trust
In a Zero Trust architecture, there is no “trusted internal network.” Following NIST SP 800-207, network location alone does not grant trust, so the corporate office Wi-Fi is treated with the same suspicion as a public coffee shop Wi-Fi.
To operate in a Zero Trust environment, architectures must enforce three core pillars:
1. Explicit Verification
Trust is never granted implicitly based on an IP address or a physical network location. Every access request must be authenticated and authorized, and trust is re-evaluated during the session. If an employee tries to access a corporate dashboard, the system doesn’t just check their password. It checks:
- Identity: Are they using Multi-Factor Authentication (MFA)?
- Device Health: Is the laptop running the latest antivirus software?
- Location: Are they logging in from New York, or suddenly from North Korea? If these signals look risky, access is denied or the user is asked for additional verification.
2. Least Privilege Access
Users and microservices are granted only the minimum permissions needed to do their specific job.
If a marketing intern logs in, they are explicitly granted READ access to the marketing_assets S3 bucket. They are blocked from the financial_records bucket, and ideally cannot even list it. Furthermore, this access is often temporary (Just-In-Time access), revoking itself after 2 hours to minimize risk.
3. Assume Breach (Micro-segmentation)
Zero Trust assumes that attackers may already be inside the network. To limit the “Blast Radius” of a compromised laptop, the internal network is partitioned using Micro-segmentation. If an attacker compromises the “Email Server,” they cannot easily jump to the “Database Server” because the two servers are isolated in separate network segments and must present verified credentials (such as mutual TLS certificates or signed tokens) to communicate.
Zero Trust in the Data Lakehouse
Applying Zero Trust to modern Data Engineering requires strict Identity and Access Management (IAM) at the query engine level.
Historically, business analysts shared a single, generic readonly_user password to access the data warehouse. This violates Zero Trust because the security team has no idea which specific human is running the queries.
Modern Lakehouse platforms (like Dremio) integrate with Identity Providers (like Okta or Microsoft Entra ID, formerly Azure AD) via Single Sign-On (SSO). When John Doe runs a SQL query, the query executes using John Doe’s specific identity token. The engine evaluates the Row-Level and Column-Level security policies that apply to John Doe, so he only sees the rows and columns his role permits, which applies Least Privilege at the data level.
Conclusion
Zero Trust is not a single product you can buy; it is an ongoing operational approach. As the corporate perimeter spreads across remote work, cloud infrastructure, and mobile devices, giving up the idea of a “safe internal network” is necessary to defend against modern ransomware and insider threats. By shifting security from the network perimeter to the individual user identity and the specific data asset, organizations make it much less likely that a single compromised password leads to a major breach.
Learn More
To learn more about the Data Lakehouse, read The Lakehouse Built for Everyone by Alex Merced. You can find this and other books by Alex Merced at books.alexmerced.com.