<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1563986768609-322da13575f3?w=1200">The old security model was built around a perimeter: inside the firewall, you’re trusted; outside, you’re not. For decades, this worked well enough. Corporate networks were physical places. Servers sat in data centers you controlled. Employees came to the office.That world is gone. Your infrastructure spans AWS, GCP, and Azure. Your employees work from cafés, home offices, and airports. Your microservices call each other across cloud boundaries. Your CI/CD pipeline touches production systems with broad permissions.The perimeter isn’t leaky. It doesn’t exist.Zero Trust is the security architecture built for this reality. But “zero trust” has also become one of the most abused buzzwords in enterprise tech — slapped on products that don’t deserve it and used as marketing language that obscures more than it reveals. This post is about what Zero Trust actually requires in a cloud-native system, and how to implement it practically.<img src="https://images.unsplash.com/photo-1550751827-4bd374c3f58b?w=800" alt="Digital padlock with circuit board patterns representing cybersecurity"> Photo by Adi Goldstein on Unsplash<hr><h2 id="the-three-principles-of-zero-trust">The Three Principles of Zero Trust</h2>Strip away the marketing and Zero Trust reduces to three principles:<h3 id="1-never-trust-always-verify">1. Never Trust, Always Verify</h3>Every request — whether from a user, a service, a machine, or an automated system — must be authenticated and authorized. Network location grants no trust. Being inside the VPN grants no trust. Being on a corporate laptop grants no trust (by itself).This doesn’t mean challenge users with MFA every 30 seconds. It means every access decision is based on verified identity and context, not assumed trust based on location.<h3 id="2-least-privilege-access">2. Least Privilege Access</h3>Every entity — human or machine — gets exactly the permissions it needs to do its job, and nothing more. A microservice that reads from one database table should not have write permissions. A developer who needs to debug a production issue should get temporary, scoped access, not permanent broad access.This is easy to state and hard to implement at scale. Most organizations have significant “privilege debt” — accumulated permissions that nobody remembers granting and nobody wants to revoke because something might break.<h3 id="3-assume-breach">3. Assume Breach</h3>Design your systems as if they’re already compromised. Because statistically, in a large enough organization, they are. The question is whether a compromised credential can move laterally and escalate privileges to cause catastrophic damage, or whether it’s isolated and detectable.Segmentation, monitoring, and blast radius limitation are as important as prevention.<hr><h2 id="the-five-pillars-what-you-need-to-implement">The Five Pillars: What You Need to Implement</h2>Zero Trust isn’t a product you buy. It’s an architecture implemented across five interconnected pillars:<h3 id="pillar-1-identity">Pillar 1: Identity</h3>Identity is the new perimeter. Everything else builds on it.For humans:<ul><li>Modern SSO (Okta, Azure AD, Google Workspace)</li><li>Hardware MFA (FIDO2/WebAuthn) — phishing-resistant, critical for privileged access</li><li>Continuous session evaluation: if a user’s device health changes or location shifts dramatically, re-challenge</li></ul>For machines:<ul><li>Workload identity: every service has an identity, cryptographically attested</li><li>AWS IAM Roles, GCP Service Accounts, Azure Managed Identities — short-lived credentials, never static secrets</li><li>SPIFFE/SPIRE for cross-cloud workload identity federation</li></ul><div><pre><code># Kubernetes — every pod gets a workload identity
apiVersion: v1
kind: ServiceAccount
metadata:
 name: payments-service
 namespace: production
 annotations:
 # AWS: IRSA (IAM Roles for Service Accounts)
 eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/payments-service-role
---
# The IAM role is scoped to exactly what payments-service needs
# No "God mode" service account with broad permissions
</code></pre></div>The identity governance problem: In a Zero Trust architecture, identity governance — tracking who has what access, and why — becomes a critical security control. Invest in tooling (Sailpoint, Veza, Britive) that gives you a single view of all human and machine identities and their permissions.<h3 id="pillar-2-device">Pillar 2: Device</h3>A user authenticating from a known, healthy corporate device is different from the same user authenticating from a personal device with no MDM enrollment and an outdated OS.Device trust contributes to the access decision:<div><pre><code>Access Request
 ├── User: authenticated, MFA verified ✓
 ├── Device: enrolled in MDM, current OS, no malware ✓
 ├── Location: normal (Seoul, usual ISP) ✓
 └── Risk score: LOW → Full access granted

Access Request 
 ├── User: authenticated, MFA verified ✓
 ├── Device: personal device, no MDM ✗
 ├── Location: unusual country ✗
 └── Risk score: HIGH → Step-up auth required, limited access
</code></pre></div>Tools: Microsoft Endpoint Manager, Jamf (macOS/iOS), CrowdStrike Falcon (device health attestation), integrated with Okta or Azure AD conditional access.<h3 id="pillar-3-network">Pillar 3: Network</h3>Zero Trust doesn’t mean “eliminate the network.” It means stop treating network location as a trust signal.Service mesh for east-west traffic: Services communicating within your infrastructure should use mutual TLS (mTLS), where both sides present certificates and verify each other’s identity. No service can impersonate another.<div><pre><code># Istio: enforce mTLS between all services in the mesh
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
 name: default
 namespace: production
spec:
 mtls:
 mode: STRICT # All traffic must be mTLS — no plaintext
---
# Fine-grained authorization: payments can only talk to database
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: payments-to-database
 namespace: production
spec:
 selector:
 matchLabels:
 app: postgres-payments
 rules:
 - from:
 - source:
 principals: ["cluster.local/ns/production/sa/payments-service"]
 to:
 - operation:
 ports: ["5432"]
</code></pre></div>ZTNA (Zero Trust Network Access) replacing VPN: Traditional VPNs grant network-level access — once you’re in, you can reach anything on the network. ZTNA products (Cloudflare Access, Zscaler, Tailscale) grant application-level access. Contractors get access to the specific service they need, nothing else.<h3 id="pillar-4-applications">Pillar 4: Applications</h3>Application-level controls layer on top of network controls:Fine-grained authorization: Beyond “is the user authenticated?”, evaluate “can this user do this action on this resource?”<div><pre><code># Open Policy Agent (OPA) for fine-grained authorization
# policy.rego
package payments.authorization

default allow := false

# Payment managers can approve transactions under $10k
allow {
 input.action == "approve_payment"
 input.user.roles[_] == "payment_manager"
 input.resource.amount &lt;= 10000
}

# CFO can approve anything
allow {
 input.action == "approve_payment"
 input.user.roles[_] == "cfo"
}
</code></pre></div><div><pre><code># Enforced in the application
import requests

def approve_payment(user, payment):
 # Ask OPA if this is allowed
 response = requests.post("http://opa:8181/v1/data/payments/authorization", json={
 "input": {
 "user": user,
 "action": "approve_payment",
 "resource": {"amount": payment.amount}
 }
 })
 if not response.json()["result"]["allow"]:
 raise PermissionError(f"User {user.id} cannot approve ${payment.amount}")
 # Proceed with approval
</code></pre></div>Secrets management: No static credentials in environment variables, config files, or code. Use Vault, AWS Secrets Manager, or GCP Secret Manager. Short-lived credentials, automatic rotation.<h3 id="pillar-5-data">Pillar 5: Data</h3>The ultimate goal: protect the data, even when everything else is compromised.<img src="https://images.unsplash.com/photo-1495107334309-fcf20504a5ab?w=800" alt="Server room with locks and security badges on the door"> Photo by Franck on UnsplashEncryption everywhere:<ul><li>Data at rest: encrypted with customer-managed keys (CMEK)</li><li>Data in transit: TLS 1.3 everywhere, mTLS for internal traffic</li><li>Data in use: application-level encryption for the most sensitive fields</li></ul>Data access logging: Every access to sensitive data should be logged with enough context to answer “who accessed what, when, from where, and why?” This is as much for compliance as security — but it also enables detecting compromised credentials through behavioral anomalies.Data classification: You can’t apply the right controls if you don’t know what you’re protecting. Automated data classification (using ML to identify PII, payment data, health information) is table stakes for mature Zero Trust implementations.<hr><h2 id="the-implementation-journey-where-to-start">The Implementation Journey: Where to Start</h2>Zero Trust is not a project with a completion date. It’s an ongoing program. But you have to start somewhere.<h3 id="phase-1-identity-foundation-months-1-3">Phase 1: Identity Foundation (Months 1-3)</h3><ol><li>Implement SSO if you haven’t (Okta, Azure AD)</li><li>Enforce MFA for all users — hardware tokens for privileged users</li><li>Audit all service accounts and eliminate overly-permissive ones</li><li>Implement workload identity for your top 5 production services</li></ol>Measurable outcome: Zero static credentials for any service in the identity-covered scope.<h3 id="phase-2-network-segmentation-months-3-6">Phase 2: Network Segmentation (Months 3-6)</h3><ol><li>Deploy a service mesh (Istio or Cilium) in your top production environment</li><li>Enable mTLS between services in the mesh</li><li>Write explicit authorization policies (start with “deny by default, allowlist specific communications”)</li><li>Replace VPN with ZTNA for at least one application</li></ol>Measurable outcome: No service-to-service communication without verified identity.<h3 id="phase-3-least-privilege-enforcement-months-6-12">Phase 3: Least Privilege Enforcement (Months 6-12)</h3><ol><li>Audit all IAM roles and database permissions</li><li>Implement just-in-time (JIT) access for privileged operations</li><li>Deploy fine-grained authorization (OPA or similar) for sensitive API endpoints</li><li>Enable comprehensive access logging</li></ol>Measurable outcome: 80% reduction in standing privileged access.<h3 id="phase-4-data-centric-controls-ongoing">Phase 4: Data-Centric Controls (Ongoing)</h3><ol><li>Data classification across your data estate</li><li>CMEK for sensitive data stores</li><li>Automated PII detection in new data flows</li><li>Regular access reviews</li></ol><hr><h2 id="common-pitfalls">Common Pitfalls</h2>Starting with network, ignoring identity: ZTNA and microsegmentation are impressive but useless if your identities are weak. Compromised credentials can still reach services they’re authorized for.“Zero Trust washing”: Buying a product labeled “Zero Trust” and declaring victory. Zero Trust is a posture and architecture, not a feature.Ignoring developer experience: If Zero Trust makes developers’ lives miserable — constant re-authentication, complex workflows to get the access they need — they’ll route around it. JIT access, short-lived credentials with easy renewal, and good tooling matter.Treating it as a one-time project: Permissions drift. New services get created with broad access. The program needs ongoing governance, regular access reviews, and continuous monitoring.<hr><h2 id="the-bottom-line">The Bottom Line</h2>Zero Trust security is not simple or cheap. A full implementation across a mid-size organization takes 18-36 months and requires coordinated investment in identity, networking, application controls, and data governance.But the alternative — perimeter-based security in an environment where the perimeter is a fiction — is worse. The average time to detect a breach is still over 200 days. The average cost is still tens of millions of dollars. Most of that damage comes from lateral movement after initial compromise.Zero Trust doesn’t prevent initial compromise. It contains it.That containment — limiting blast radius, enabling rapid detection, preventing credential reuse across systems — is what turns a catastrophic breach into an incident. In the threat landscape of 2026, that distinction is worth every implementation dollar.Start with identity. Instrument everything. Assume breach. Verify always. <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

The old security model was built around a perimeter: inside the firewall, you’re trusted; outside, you’re not. For decades, this worked well enough. Corporate networks were physical places. Servers sat in data centers you controlled. Employees came to the office.
That world is gone. Your infrastructure spans AWS, GCP, and Azure. Your employees work from cafés, home offices, and airports. Your microservices call each other across cloud boundaries. Your CI/CD pipeline touches production systems with broad permissions.
The perimeter isn’t leaky. It doesn’t exist.
Zero Trust is the security architecture built for this reality. But “zero trust” has also become one of the most abused buzzwords in enterprise tech — slapped on products that don’t deserve it and used as marketing language that obscures more than it reveals. This post is about what Zero Trust actually requires in a cloud-native system, and how to implement it practically.
Photo by Adi Goldstein on Unsplash
The Three Principles of Zero Trust
Strip away the marketing and Zero Trust reduces to three principles:
1. Never Trust, Always Verify
Every request — whether from a user, a service, a machine, or an automated system — must be authenticated and authorized. Network location grants no trust. Being inside the VPN grants no trust. Being on a corporate laptop grants no trust (by itself).
This doesn’t mean challenge users with MFA every 30 seconds. It means every access decision is based on verified identity and context, not assumed trust based on location.
2. Least Privilege Access
Every entity — human or machine — gets exactly the permissions it needs to do its job, and nothing more. A microservice that reads from one database table should not have write permissions. A developer who needs to debug a production issue should get temporary, scoped access, not permanent broad access.
This is easy to state and hard to implement at scale. Most organizations have significant “privilege debt” — accumulated permissions that nobody remembers granting and nobody wants to revoke because something might break.
3. Assume Breach
Design your systems as if they’re already compromised. Because statistically, in a large enough organization, they are. The question is whether a compromised credential can move laterally and escalate privileges to cause catastrophic damage, or whether it’s isolated and detectable.
Segmentation, monitoring, and blast radius limitation are as important as prevention.
The Five Pillars: What You Need to Implement
Zero Trust isn’t a product you buy. It’s an architecture implemented across five interconnected pillars:
Pillar 1: Identity
Identity is the new perimeter. Everything else builds on it.
For humans:
Modern SSO (Okta, Azure AD, Google Workspace)
Hardware MFA (FIDO2/WebAuthn) — phishing-resistant, critical for privileged access
Continuous session evaluation: if a user’s device health changes or location shifts dramatically, re-challenge
For machines:
Workload identity: every service has an identity, cryptographically attested
AWS IAM Roles, GCP Service Accounts, Azure Managed Identities — short-lived credentials, never static secrets
SPIFFE/SPIRE for cross-cloud workload identity federation
# Kubernetes — every pod gets a workload identity
apiVersion: v1
kind: ServiceAccount
metadata:
 name: payments-service
 namespace: production
 annotations:
 # AWS: IRSA (IAM Roles for Service Accounts)
 eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/payments-service-role
---
# The IAM role is scoped to exactly what payments-service needs
# No "God mode" service account with broad permissions
The identity governance problem: In a Zero Trust architecture, identity governance — tracking who has what access, and why — becomes a critical security control. Invest in tooling (Sailpoint, Veza, Britive) that gives you a single view of all human and machine identities and their permissions.
Pillar 2: Device
A user authenticating from a known, healthy corporate device is different from the same user authenticating from a personal device with no MDM enrollment and an outdated OS.
Device trust contributes to the access decision:
Access Request
 ├── User: authenticated, MFA verified ✓
 ├── Device: enrolled in MDM, current OS, no malware ✓
 ├── Location: normal (Seoul, usual ISP) ✓
 └── Risk score: LOW → Full access granted
Access Request 
 ├── User: authenticated, MFA verified ✓
 ├── Device: personal device, no MDM ✗
 ├── Location: unusual country ✗
 └── Risk score: HIGH → Step-up auth required, limited access
Tools: Microsoft Endpoint Manager, Jamf (macOS/iOS), CrowdStrike Falcon (device health attestation), integrated with Okta or Azure AD conditional access.
Pillar 3: Network
Zero Trust doesn’t mean “eliminate the network.” It means stop treating network location as a trust signal.
Service mesh for east-west traffic: Services communicating within your infrastructure should use mutual TLS (mTLS), where both sides present certificates and verify each other’s identity. No service can impersonate another.
# Istio: enforce mTLS between all services in the mesh
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
 name: default
 namespace: production
spec:
 mtls:
 mode: STRICT # All traffic must be mTLS — no plaintext
---
# Fine-grained authorization: payments can only talk to database
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: payments-to-database
 namespace: production
spec:
 selector:
 matchLabels:
 app: postgres-payments
 rules:
 - from:
 - source:
 principals: ["cluster.local/ns/production/sa/payments-service"]
 to:
 - operation:
 ports: ["5432"]
ZTNA (Zero Trust Network Access) replacing VPN: Traditional VPNs grant network-level access — once you’re in, you can reach anything on the network. ZTNA products (Cloudflare Access, Zscaler, Tailscale) grant application-level access. Contractors get access to the specific service they need, nothing else.
Pillar 4: Applications
Application-level controls layer on top of network controls:
Fine-grained authorization: Beyond “is the user authenticated?”, evaluate “can this user do this action on this resource?”
# Open Policy Agent (OPA) for fine-grained authorization
# policy.rego
package payments.authorization
default allow := false
# Payment managers can approve transactions under $10k
allow {
 input.action == "approve_payment"
 input.user.roles[_] == "payment_manager"
 input.resource.amount <= 10000
}
# CFO can approve anything
allow {
 input.action == "approve_payment"
 input.user.roles[_] == "cfo"
}
# Enforced in the application
import requests
def approve_payment(user, payment):
 # Ask OPA if this is allowed
 response = requests.post("http://opa:8181/v1/data/payments/authorization", json={
 "input": {
 "user": user,
 "action": "approve_payment",
 "resource": {"amount": payment.amount}
 }
 })
 if not response.json()["result"]["allow"]:
 raise PermissionError(f"User {user.id} cannot approve ${payment.amount}")
 # Proceed with approval
Secrets management: No static credentials in environment variables, config files, or code. Use Vault, AWS Secrets Manager, or GCP Secret Manager. Short-lived credentials, automatic rotation.
Pillar 5: Data
The ultimate goal: protect the data, even when everything else is compromised.
Photo by Franck on Unsplash
Encryption everywhere:
Data at rest: encrypted with customer-managed keys (CMEK)
Data in transit: TLS 1.3 everywhere, mTLS for internal traffic
Data in use: application-level encryption for the most sensitive fields
Data access logging: Every access to sensitive data should be logged with enough context to answer “who accessed what, when, from where, and why?” This is as much for compliance as security — but it also enables detecting compromised credentials through behavioral anomalies.
Data classification: You can’t apply the right controls if you don’t know what you’re protecting. Automated data classification (using ML to identify PII, payment data, health information) is table stakes for mature Zero Trust implementations.
The Implementation Journey: Where to Start
Zero Trust is not a project with a completion date. It’s an ongoing program. But you have to start somewhere.
Phase 1: Identity Foundation (Months 1-3)
Implement SSO if you haven’t (Okta, Azure AD)
Enforce MFA for all users — hardware tokens for privileged users
Audit all service accounts and eliminate overly-permissive ones
Implement workload identity for your top 5 production services
Measurable outcome: Zero static credentials for any service in the identity-covered scope.
Phase 2: Network Segmentation (Months 3-6)
Deploy a service mesh (Istio or Cilium) in your top production environment
Enable mTLS between services in the mesh
Write explicit authorization policies (start with “deny by default, allowlist specific communications”)
Replace VPN with ZTNA for at least one application
Measurable outcome: No service-to-service communication without verified identity.
Phase 3: Least Privilege Enforcement (Months 6-12)
Audit all IAM roles and database permissions
Implement just-in-time (JIT) access for privileged operations
Deploy fine-grained authorization (OPA or similar) for sensitive API endpoints
Enable comprehensive access logging
Measurable outcome: 80% reduction in standing privileged access.
Phase 4: Data-Centric Controls (Ongoing)
Data classification across your data estate
CMEK for sensitive data stores
Automated PII detection in new data flows
Regular access reviews
Common Pitfalls
Starting with network, ignoring identity: ZTNA and microsegmentation are impressive but useless if your identities are weak. Compromised credentials can still reach services they’re authorized for.
“Zero Trust washing”: Buying a product labeled “Zero Trust” and declaring victory. Zero Trust is a posture and architecture, not a feature.
Ignoring developer experience: If Zero Trust makes developers’ lives miserable — constant re-authentication, complex workflows to get the access they need — they’ll route around it. JIT access, short-lived credentials with easy renewal, and good tooling matter.
Treating it as a one-time project: Permissions drift. New services get created with broad access. The program needs ongoing governance, regular access reviews, and continuous monitoring.
The Bottom Line
Zero Trust security is not simple or cheap. A full implementation across a mid-size organization takes 18-36 months and requires coordinated investment in identity, networking, application controls, and data governance.
But the alternative — perimeter-based security in an environment where the perimeter is a fiction — is worse. The average time to detect a breach is still over 200 days. The average cost is still tens of millions of dollars. Most of that damage comes from lateral movement after initial compromise.
Zero Trust doesn’t prevent initial compromise. It contains it.
That containment — limiting blast radius, enabling rapid detection, preventing credential reuse across systems — is what turns a catastrophic breach into an incident. In the threat landscape of 2026, that distinction is worth every implementation dollar.
Start with identity. Instrument everything. Assume breach. Verify always.

Zero Trust Security in Practice: Moving Beyond the Perimeter in Cloud-Native Systems

댓글