✍️ 필사 모드: Zero Trust Architecture Complete Guide 2025: Never Trust Always Verify, BeyondCorp, SASE

Traditional Perimeter Security Model:

  [Internet]  ──── [Firewall] ──── [Internal Network (Trusted Zone)]
     │                                   │
   Untrusted                        Everything trusted
     Zone                               │
     │                           Free lateral movement
  Access only
   via VPN

Breach Pattern (Perimeter Security Failure):

1. Initial Compromise
   Phishing email -> One employee's account compromised

2. Lateral Movement
   Free movement within the trusted internal network
   -> Unlimited access to other servers, DBs

3. Privilege Escalation
   No additional authentication inside the network
   -> Administrator privileges obtained

4. Data Exfiltration
   Internal-to-external communication loosely monitored
   -> Massive data leak

Zero Trust Core Principles:

┌─────────────────────────────────────────────────┐
│              Zero Trust Architecture             │
│                                                  │
│  1. Verify Explicitly                            │
│     -> Authenticate + authorize every request    │
│     -> Verify user, device, location, behavior   │
│                                                  │
│  2. Least Privilege Access                       │
│     -> Grant only the minimum required access    │
│     -> Just-In-Time, Just-Enough-Access          │
│                                                  │
│  3. Assume Breach                                │
│     -> Assume the network is already compromised │
│     -> Minimize blast radius                     │
│     -> Isolate via microsegmentation             │
└─────────────────────────────────────────────────┘

NIST 800-207 Zero Trust Architecture:

  [User/Device]
        │
        ▼
  ┌──────────────┐     ┌──────────────────────┐
  │  PEP         │────▶│  PDP (Policy Engine)  │
  │  Policy      │◀────│  + Policy Admin       │
  │  Enforcement │     │                       │
  │  Point       │     │  Decision inputs:     │
  └──────┬───────┘     │  - User identity      │
         │             │  - Device state        │
         ▼             │  - Network location    │
  ┌──────────────┐     │  - Requested resource  │
  │  Enterprise  │     │  - Time/behavior       │
  │  Resources   │     └──────────────────────┘
  └──────────────┘              │
                                ▼
                    ┌──────────────────────┐
                    │  Data Sources:        │
                    │  - CDM (Asset Mgmt)   │
                    │  - Threat Intel       │
                    │  - Activity Logs      │
                    │  - Compliance         │
                    │  - SIEM/SOAR          │
                    └──────────────────────┘

# Policy Engine decision example
policy_evaluation:
  input:
    user: "engineer@company.com"
    device_trust_score: 85
    location: "United States"
    resource: "production-database"
    time: "2025-03-15T14:30:00Z"
    mfa_verified: true
    risk_score: "low"

  rules:
    - name: "prod-db-access"
      conditions:
        - user.role IN ["sre", "dba"]
        - device.trust_score >= 80
        - device.os_patched == true
        - mfa.verified == true
        - risk.score IN ["low", "medium"]
      action: "allow"
      session_controls:
        max_duration: "4h"
        require_reauthentication: true
        log_all_queries: true

  decision: "ALLOW with session controls"

PEP Operation Flow:

  Request -> [PEP] -> Policy check request -> [PDP]
                                                │
                                       Allow/Deny decision
                                                │
             [PEP] <- Decision received <───────┘
               │
          Allow -> Resource access (encrypted channel)
          Deny  -> Block access + log event

CISA Zero Trust Maturity Model:

Level 1: Traditional
├── Static security policies
├── Manual provisioning
└── Limited visibility

Level 2: Advanced
├── Partially automated policies
├── Centralized identity management
└── Basic analytics

Level 3: Optimal
├── Fully automated policies
├── Continuous verification
├── AI/ML-based analytics
└── Dynamic policy enforcement

5 Core Pillars:
┌────────────┬────────────┬────────────┬────────────┬────────────┐
│  Identity  │  Devices   │  Networks  │   Apps/    │   Data     │
│            │            │            │  Workloads │            │
├────────────┼────────────┼────────────┼────────────┼────────────┤
│ MFA, SSO   │ MDM, EDR   │ Micro-     │ SDLC       │ Classify,  │
│ Conditional│ Device     │ Segment    │ DAST/SAST  │ DLP,       │
│ Access     │ Inventory  │ Encryption │ Runtime    │ Encryption │
└────────────┴────────────┴────────────┴────────────┴────────────┘

BeyondCorp Core Principles:

1. Network location does not determine trust
   -> Office network = coffee shop Wi-Fi (treated equally)

2. Access is determined by user + device
   -> Who + What device + What state (health)

3. All access is authenticated, authorized, encrypted
   -> No VPN needed. Direct access via the internet

4. Access policies are dynamic and continuously evaluated
   -> One-time authentication is not enough

BeyondCorp Architecture:

  [Employee Device]
       │
       │ (Internet - from anywhere)
       ▼
  ┌──────────────────┐
  │  Access Proxy     │ <- Entry point for all requests
  │  (Identity-Aware  │
  │   Proxy)          │
  └────────┬─────────┘
           │
    ┌──────┴──────┐
    ▼              ▼
┌────────┐   ┌────────────┐
│ Access │   │ Device     │
│ Control│   │ Inventory  │
│ Engine │   │ Service    │
└───┬────┘   └─────┬──────┘
    │              │
    ▼              ▼
┌────────────────────────┐
│  Trust Evaluation       │
│                         │
│  User Identity ────────┤
│  Device State ─────────┤
│  Access Policy ────────┤
│  Context (time, loc) ──┤
│                         │
│  -> Trust Score calc    │
│  -> Allow/deny decision │
└────────────────────────┘

# GCP IAP Configuration
# iap-config.yaml
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: iap-backend-config
spec:
  iap:
    enabled: true
    oauthclientCredentials:
      secretName: iap-oauth-secret
  securityPolicy:
    name: "rate-limit-policy"
  healthCheck:
    requestPath: /healthz
    port: 8080

# Verifying access through IAP (server-side)
from google.auth.transport import requests
from google.oauth2 import id_token

def verify_iap_jwt(iap_jwt, expected_audience):
    """Verify IAP JWT token and return user identity"""
    try:
        decoded_jwt = id_token.verify_token(
            iap_jwt,
            requests.Request(),
            audience=expected_audience,
            certs_url="https://www.gstatic.com/iap/verify/public_key"
        )
        return {
            "email": decoded_jwt["email"],
            "sub": decoded_jwt["sub"],
            "access_levels": decoded_jwt.get("google", {}).get(
                "access_levels", []
            )
        }
    except Exception as e:
        print(f"JWT verification failed: {e}")
        return None

# Access level based policy enforcement
def check_access_policy(user_info, resource):
    """Compare user access levels against resource policies"""
    required_levels = get_resource_policy(resource)
    user_levels = set(user_info.get("access_levels", []))

    if required_levels.issubset(user_levels):
        return True
    return False

Google's BeyondCorp Transition (~8 years):

Phase 1: Gain Visibility
├── Build complete device inventory
├── Analyze all user access patterns
└── Monitor existing VPN traffic

Phase 2: Build Access Proxy
├── Deploy Identity-Aware Proxy
├── Move internal apps behind the proxy
└── Certificate-based device authentication

Phase 3: Build Policy Engine
├── Define dynamic access policies
├── Device trust scoring system
└── Context-based access control

Phase 4: Eliminate VPN
├── Gradual reduction of VPN traffic
├── Migrate all apps to proxy-based access
└── Full VPN decommission

Phase 5: Continuous Improvement
├── ML-based anomaly detection
├── Real-time risk assessment
└── Automated response (SOAR integration)

Modern IAM Architecture:

  ┌─────────────────────────────────────────┐
  │           Identity Provider (IdP)        │
  │                                          │
  │  ┌──────────┐  ┌──────────┐  ┌────────┐│
  │  │ User     │  │ Directory│  │ MFA    ││
  │  │ Store    │  │ Service  │  │ Engine ││
  │  │ (DB)     │  │ (LDAP/   │  │        ││
  │  │          │  │  SCIM)   │  │        ││
  │  └──────────┘  └──────────┘  └────────┘│
  │                                          │
  │  ┌──────────┐  ┌──────────┐  ┌────────┐│
  │  │ SSO      │  │ OAuth2/  │  │ Risk   ││
  │  │ Engine   │  │ OIDC     │  │ Engine ││
  │  │ (SAML)   │  │ Server   │  │        ││
  │  └──────────┘  └──────────┘  └────────┘│
  └─────────────────────────────────────────┘
           │              │
      ┌────┴────┐    ┌───┴────┐
      ▼         ▼    ▼        ▼
   [SaaS]   [Internal] [Cloud]  [API]
    Apps      Apps      Infra   Services

# Conditional Access Policy Engine Implementation
from dataclasses import dataclass
from enum import Enum
from typing import List, Optional

class RiskLevel(Enum):
    LOW = "low"
    MEDIUM = "medium"
    HIGH = "high"
    CRITICAL = "critical"

@dataclass
class AccessContext:
    user_id: str
    user_role: str
    device_compliant: bool
    device_managed: bool
    mfa_completed: bool
    mfa_method: str  # "phishing_resistant", "push", "sms"
    location: str  # "corporate", "home", "unknown"
    ip_reputation: str  # "trusted", "suspicious", "malicious"
    risk_score: float  # 0.0 - 1.0
    resource_sensitivity: str  # "public", "internal", "confidential", "restricted"

class ConditionalAccessEngine:
    def evaluate(self, ctx: AccessContext) -> dict:
        """Evaluate an access request and return a decision"""

        # Rule 1: Block malicious IPs unconditionally
        if ctx.ip_reputation == "malicious":
            return self._deny("Malicious IP detected")

        # Rule 2: Restricted resource access
        if ctx.resource_sensitivity == "restricted":
            if not ctx.mfa_completed:
                return self._step_up("Require MFA for restricted resource")
            if ctx.mfa_method != "phishing_resistant":
                return self._step_up("Require phishing-resistant MFA (FIDO2)")
            if not ctx.device_managed:
                return self._deny("Managed device required for restricted access")

        # Rule 3: Dynamic policy based on risk score
        if ctx.risk_score > 0.8:
            return self._deny("Risk score too high")
        elif ctx.risk_score > 0.5:
            if not ctx.mfa_completed:
                return self._step_up("Elevated risk - MFA required")
            return self._allow_limited(session_duration="1h")

        # Rule 4: Unmanaged devices
        if not ctx.device_managed:
            if ctx.resource_sensitivity in ["confidential", "restricted"]:
                return self._deny("Managed device required")
            return self._allow_limited(
                session_duration="4h",
                block_download=True
            )

        return self._allow()

    def _allow(self):
        return {"decision": "allow", "session_duration": "8h"}

    def _allow_limited(self, **kwargs):
        return {"decision": "allow_limited", **kwargs}

    def _deny(self, reason: str):
        return {"decision": "deny", "reason": reason}

    def _step_up(self, reason: str):
        return {"decision": "step_up_auth", "reason": reason}

MFA Strength Pyramid:

   Strongest  ▲
              │  ┌─────────────────────────┐
              │  │  FIDO2/WebAuthn         │ <- Hardware keys (YubiKey)
              │  │  (Phishing-resistant)   │    Passkeys
              │  └─────────────────────────┘
              │  ┌─────────────────────────┐
              │  │  Certificate-based      │ <- Device certificates
              │  │                         │    Smart cards
              │  └─────────────────────────┘
              │  ┌─────────────────────────┐
              │  │  App-based Push/TOTP    │ <- Authenticator apps
              │  │                         │    Time-based OTP
              │  └─────────────────────────┘
              │  ┌─────────────────────────┐
   Weakest    │  │  SMS/Email OTP          │ <- SIM swapping vulnerable
              ▼  │  (Phishable)            │    Email compromise risk
                 └─────────────────────────┘

# Okta Conditional MFA Configuration Example
authentication_policies:
  - name: "High Security Resources"
    conditions:
      applications:
        - "production-admin"
        - "financial-systems"
        - "customer-data-platform"
    actions:
      require_mfa: true
      allowed_factors:
        - "fido2_webauthn"
        - "okta_verify_push"
      factor_lifetime: "1h"
      re_authentication_frequency: "every_request"

  - name: "Standard Resources"
    conditions:
      applications:
        - "email"
        - "chat"
        - "wiki"
    actions:
      require_mfa: true
      allowed_factors:
        - "fido2_webauthn"
        - "okta_verify_push"
        - "okta_verify_totp"
      factor_lifetime: "12h"
      re_authentication_frequency: "every_sign_on"

  - name: "Unknown Location Policy"
    conditions:
      network_zones:
        exclude:
          - "corporate_network"
          - "known_vpn_endpoints"
    actions:
      require_mfa: true
      allowed_factors:
        - "fido2_webauthn"
      session_lifetime: "4h"

Device Trust Evaluation Flow:

  [Device] -> Agent collects state
       │
       ▼
  ┌──────────────────────────────────┐
  │     Device Trust Signals         │
  │                                  │
  │  OS version/patch status ── 20%  │
  │  Disk encryption ────────── 15%  │
  │  Firewall enabled ───────── 10%  │
  │  EDR installed/running ──── 20%  │
  │  MDM managed state ─────── 15%  │
  │  Certificate validity ───── 10%  │
  │  Recent security scan ───── 10%  │
  │                                  │
  │  -> Trust Score: 0-100           │
  └──────────────────────────────────┘
       │
       ▼
  Trust Score feeds into access policies
  Score >= 80 -> Full Access
  Score >= 60 -> Limited Access
  Score < 60  -> Block + remediation guidance

# Device certificate validation logic
import ssl
from cryptography import x509
from cryptography.x509.oid import NameOID

class DeviceCertificateValidator:
    def __init__(self, ca_cert_path: str, crl_url: str):
        self.ca_cert = self._load_cert(ca_cert_path)
        self.crl_url = crl_url

    def validate_device(self, client_cert_pem: bytes) -> dict:
        """Validate device certificate and return device info"""
        try:
            cert = x509.load_pem_x509_certificate(client_cert_pem)

            # 1. Check validity period
            self._check_validity(cert)

            # 2. Verify CA signature
            self._verify_signature(cert)

            # 3. Check CRL (Certificate Revocation List)
            self._check_revocation(cert)

            # 4. Extract device information
            device_info = {
                "device_id": cert.subject.get_attributes_for_oid(
                    NameOID.COMMON_NAME
                )[0].value,
                "org": cert.subject.get_attributes_for_oid(
                    NameOID.ORGANIZATION_NAME
                )[0].value,
                "serial": str(cert.serial_number),
                "not_after": cert.not_valid_after_utc.isoformat(),
                "verified": True
            }

            return device_info

        except Exception as e:
            return {"verified": False, "error": str(e)}

# Microsoft Intune Compliance Policy Example
compliance_policy:
  name: "Zero Trust Device Compliance"
  platforms:
    - windows
    - macos
    - ios
    - android

  windows_rules:
    os_minimum_version: "10.0.19045"  # Windows 10 22H2+
    bitlocker_required: true
    secure_boot_required: true
    tpm_required: true
    firewall_required: true
    antivirus_required: true
    antivirus_signatures_up_to_date: true
    defender_for_endpoint_risk_level: "medium_or_below"

  macos_rules:
    os_minimum_version: "14.0"  # Sonoma+
    filevault_required: true
    firewall_required: true
    gatekeeper_required: true
    system_integrity_protection: true

  non_compliance_actions:
    - action: "notify_user"
      grace_period_hours: 0
      message: "Your device does not meet security requirements"
    - action: "mark_non_compliant"
      grace_period_hours: 24
    - action: "block_access"
      grace_period_hours: 72
    - action: "retire_device"
      grace_period_hours: 720  # 30 days

Segmentation Evolution:

1. Traditional: VLAN-based
   ┌──────────┐  ┌──────────┐  ┌──────────┐
   │  VLAN 10 │  │  VLAN 20 │  │  VLAN 30 │
   │  (Dev)   │  │  (Prod)  │  │  (DB)    │
   └──────────┘  └──────────┘  └──────────┘
   -> Free communication within same VLAN (problem!)

2. Firewall-based: Zone segmentation
   ┌──────────┐     ┌──────────┐
   │  Trust   │─FW─▶│  DMZ     │─FW─▶ Internet
   │  Zone    │     │  Zone    │
   └──────────┘     └──────────┘
   -> Zone-to-zone control, free within zone (insufficient)

3. Microsegmentation: Workload-level
   ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐
   │A │─│B │ │C │─│D │ │E │
   └──┘ └──┘ └──┘ └──┘ └──┘
     │         │
     └────X────┘  <- Communication between A and C blocked
   -> Per-workload policies (ideal)

# 1. Default policy: deny all traffic (Default Deny)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
# 2. Allow frontend -> backend API only
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend-api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080
---
# 3. Allow backend API -> DB only
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: backend-api
      ports:
        - protocol: TCP
          port: 5432
---
# 4. Allow DNS access (all Pods)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

# Istio PeerAuthentication: enforce mTLS across the mesh
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT  # mTLS required. Reject plaintext traffic
---
# AuthorizationPolicy: service-to-service access control
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: payment-service-policy
  namespace: production
spec:
  selector:
    matchLabels:
      app: payment-service
  rules:
    # Rule 1: Only order-service can call payment API
    - from:
        - source:
            principals:
              - "cluster.local/ns/production/sa/order-service"
      to:
        - operation:
            methods: ["POST"]
            paths: ["/api/v1/payments", "/api/v1/payments/*"]
    # Rule 2: Monitoring service only gets health checks
    - from:
        - source:
            principals:
              - "cluster.local/ns/monitoring/sa/prometheus"
      to:
        - operation:
            methods: ["GET"]
            paths: ["/health", "/metrics"]
  # All other access is implicitly denied

VPN (Traditional):

  [User] ──VPN tunnel──▶ [Access to entire company network]
                              │
                    All internal resources exposed
                    (including unnecessary servers)

ZTNA (Zero Trust):

  [User] ──Encrypted channel──▶ [Access to authorized App A only]
                                    │
                          Rest of network is invisible
                          (Dark Cloud principle)

# Cloudflare Access Policy Example
application:
  name: "Internal Dashboard"
  domain: "dashboard.company.com"
  type: "self_hosted"

  identity_providers:
    - name: "Okta"
      type: "saml"
    - name: "GitHub"
      type: "oauth"

  policies:
    - name: "Allow Engineering"
      decision: "allow"
      include:
        - group: "engineering@company.com"
      require:
        - mfa: true
        - device_posture:
            - serial_number_check: true
            - disk_encryption: true
            - os_version:
                operator: ">="
                version: "14.0"

    - name: "Block Countries"
      decision: "block"
      include:
        - country:
            - "KP"
            - "IR"
            - "SY"

  session_duration: "12h"
  cors_headers:
    allowed_origins: ["https://dashboard.company.com"]
    allowed_methods: ["GET", "POST"]

SASE = Network (SD-WAN) + Security (SSE) unified in the cloud

  ┌─────────────────────────────────────────────────────┐
  │                    SASE Platform                     │
  │                                                      │
  │  ┌─────────────────┐  ┌──────────────────────────┐  │
  │  │   SD-WAN         │  │   SSE (Security)          │  │
  │  │                  │  │                           │  │
  │  │  - WAN optim.    │  │  - ZTNA                  │  │
  │  │  - Traffic ctrl  │  │  - CASB (Cloud Access    │  │
  │  │  - QoS           │  │         Security Broker)  │  │
  │  │  - Multi-link    │  │  - SWG (Secure Web GW)   │  │
  │  │                  │  │  - FWaaS (FW as Service)  │  │
  │  │                  │  │  - DLP (Data Loss Prev.)  │  │
  │  └─────────────────┘  └──────────────────────────┘  │
  │                                                      │
  │  ┌──────────────────────────────────────────────┐   │
  │  │  Common: Unified policy, console, API        │   │
  │  └──────────────────────────────────────────────┘   │
  └─────────────────────────────────────────────────────┘
         │              │              │
    ┌────┴────┐   ┌────┴────┐   ┌────┴────┐
    │   HQ    │   │ Branch  │   │ Remote  │
    └─────────┘   └─────────┘   └─────────┘

ZTNA (Zero Trust Network Access):
├── User/device authentication
├── App-level access control
├── Context-based policies
└── VPN replacement

CASB (Cloud Access Security Broker):
├── Shadow IT discovery
├── SaaS data protection (DLP)
├── Anomalous behavior detection (UEBA)
└── Compliance monitoring

SWG (Secure Web Gateway):
├── URL filtering
├── Malware blocking
├── SSL/TLS inspection
└── Content filtering

FWaaS (Firewall as a Service):
├── L3-L7 firewall
├── IPS/IDS
├── DNS security
└── Cloud-based scaling

Kubernetes Zero Trust Layers:

Layer 1: Cluster Access
├── RBAC (Role-Based Access Control)
├── OIDC authentication (kubectl + IdP)
├── Admission Control (OPA/Kyverno)
└── API Server Audit Logging

Layer 2: Pod-to-Pod Communication
├── NetworkPolicy (basic L3/L4)
├── Service Mesh mTLS (L7)
├── DNS Policy
└── Egress Control

Layer 3: Workload Identity
├── ServiceAccount Token (Projected)
├── SPIFFE/SPIRE
├── Workload Identity Federation
└── Secret Management (Vault)

Layer 4: Data Protection
├── Encryption at Rest (etcd)
├── Encryption in Transit (TLS)
├── Secret Encryption (KMS)
└── PodSecurity Standards

# OPA Gatekeeper: Enforce Pod Security
# ConstraintTemplate definition
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredsecuritycontext
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredSecurityContext
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredsecuritycontext

        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          not container.securityContext.runAsNonRoot
          msg := sprintf(
            "Container '%v' must set runAsNonRoot to true",
            [container.name]
          )
        }

        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          not container.securityContext.readOnlyRootFilesystem
          msg := sprintf(
            "Container '%v' must set readOnlyRootFilesystem to true",
            [container.name]
          )
        }

        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          container.securityContext.privileged
          msg := sprintf(
            "Container '%v' must not be privileged",
            [container.name]
          )
        }
---
# Constraint application
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredSecurityContext
metadata:
  name: must-have-security-context
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaces:
      - "production"
      - "staging"
  enforcementAction: deny

# Kyverno: Image signature verification + registry restriction
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signatures
spec:
  validationFailureAction: Enforce
  background: false
  rules:
    - name: verify-cosign-signature
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "registry.company.com/*"
          attestors:
            - entries:
                - keys:
                    publicKeys: |
                      -----BEGIN PUBLIC KEY-----
                      MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...
                      -----END PUBLIC KEY-----
    - name: restrict-registries
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Only approved registries are allowed"
        pattern:
          spec:
            containers:
              - image: "registry.company.com/* | gcr.io/company-project/*"

SPIFFE/SPIRE Architecture:

  ┌──────────────────────────────┐
  │       SPIRE Server           │
  │                              │
  │  - CA (certificate issuance) │
  │  - Registration API          │
  │  - Node/Workload Attestation │
  └──────────┬───────────────────┘
             │
    ┌────────┴────────┐
    ▼                 ▼
┌──────────┐   ┌──────────┐
│  SPIRE   │   │  SPIRE   │
│  Agent   │   │  Agent   │
│ (Node 1) │   │ (Node 2) │
└────┬─────┘   └────┬─────┘
     │               │
  ┌──┴──┐         ┌──┴──┐
  │Pod A│         │Pod C│
  │Pod B│         │Pod D│
  └─────┘         └─────┘

  Each Pod receives an SVID (SPIFFE Verifiable Identity Document):
  spiffe://company.com/ns/production/sa/payment-service

# SPIRE Registration Example
apiVersion: spire.spiffe.io/v1alpha1
kind: ClusterSPIFFEID
metadata:
  name: payment-service-id
spec:
  spiffeIDTemplate: >-
    spiffe://company.com/ns/{{ .PodMeta.Namespace }}/sa/{{ .PodSpec.ServiceAccountName }}
  podSelector:
    matchLabels:
      app: payment-service
  namespaceSelector:
    matchLabels:
      environment: production
  dnsNameTemplates:
    - "{{ .PodSpec.ServiceAccountName }}.{{ .PodMeta.Namespace }}.svc.cluster.local"
  ttl: "1h"
  jwtTTL: "5m"

Phase 1: Gain Visibility (1-3 months)
├── Asset inventory (users, devices, apps, data)
├── Network flow mapping
├── Access pattern analysis
├── Current security gap assessment
└── Define success metrics (KPIs)

Phase 2: Identity Foundation (3-6 months)
├── Build/integrate centralized IdP
├── Implement SSO (SAML/OIDC)
├── Deploy MFA across the organization
├── Conditional Access policies
└── Device registration and management

Phase 3: Network Segmentation (6-12 months)
├── Design microsegmentation
├── East-West traffic control
├── DNS security
├── Encrypted communication (mTLS)
└── ZTNA pilot (begin VPN replacement)

Phase 4: Workload Security (12-18 months)
├── Application-level access control
├── API security (auth, rate limiting)
├── Data classification and DLP
├── CI/CD pipeline security
└── Runtime security (CWPP)

Phase 5: Automation and Optimization (18-24 months)
├── SOAR integration (automated response)
├── ML-based anomaly detection
├── Continuous compliance monitoring
├── Automated policy optimization
└── Full VPN decommission

# Phase 1 Detailed Checklist
phase_1_visibility:
  asset_inventory:
    - action: "Identify all user accounts"
      tools: ["IdP export", "AD/LDAP query"]
      kpi: "Identification rate >= 99%"
    - action: "Identify all devices"
      tools: ["MDM", "NAC", "network scan"]
      kpi: "Managed device ratio >= 90%"
    - action: "Map all applications"
      tools: ["CASB discovery", "network analysis"]
      kpi: "Shadow IT discovery rate"
    - action: "Map data flows"
      tools: ["DLP scan", "network tap"]
      kpi: "Sensitive data location awareness"

  network_mapping:
    - action: "Analyze East-West traffic"
      tools: ["NetFlow", "Service Mesh telemetry"]
    - action: "Analyze external communication patterns"
      tools: ["Firewall logs", "proxy logs"]
    - action: "Generate dependency graph"
      tools: ["Service discovery", "APM"]

  gap_assessment:
    - "Audit current authentication methods"
    - "Evaluate network segmentation level"
    - "Verify encryption coverage"
    - "Evaluate logging/monitoring coverage"

{
  "acls": [
    {
      "action": "accept",
      "src": ["group:engineering"],
      "dst": [
        "tag:dev-server:22",
        "tag:staging-server:*",
        "tag:monitoring:3000,9090"
      ]
    },
    {
      "action": "accept",
      "src": ["group:sre"],
      "dst": [
        "tag:production-server:*",
        "tag:database:5432",
        "tag:monitoring:*"
      ]
    },
    {
      "action": "accept",
      "src": ["group:data-team"],
      "dst": [
        "tag:data-warehouse:5439",
        "tag:jupyter:8888"
      ]
    }
  ],
  "groups": {
    "group:engineering": ["user1@company.com", "user2@company.com"],
    "group:sre": ["sre1@company.com", "sre2@company.com"],
    "group:data-team": ["analyst@company.com"]
  },
  "tagOwners": {
    "tag:production-server": ["group:sre"],
    "tag:dev-server": ["group:engineering"],
    "tag:staging-server": ["group:engineering"],
    "tag:database": ["group:sre"],
    "tag:monitoring": ["group:sre"],
    "tag:data-warehouse": ["group:data-team"],
    "tag:jupyter": ["group:data-team"]
  },
  "ssh": [
    {
      "action": "accept",
      "src": ["group:sre"],
      "dst": ["tag:production-server"],
      "users": ["root", "ubuntu"]
    },
    {
      "action": "accept",
      "src": ["group:engineering"],
      "dst": ["tag:dev-server"],
      "users": ["autogroup:nonroot"]
    }
  ]
}

# Twingate Terraform Configuration
resource "twingate_remote_network" "production" {
  name = "Production Network"
}

resource "twingate_connector" "prod_connector" {
  remote_network_id = twingate_remote_network.production.id
  name              = "prod-connector-1"
}

resource "twingate_resource" "prod_api" {
  name              = "Production API"
  address           = "api.internal.company.com"
  remote_network_id = twingate_remote_network.production.id

  protocols {
    allow_icmp = false
    tcp {
      policy = "RESTRICTED"
      ports  = ["443", "8443"]
    }
    udp {
      policy = "DENY_ALL"
    }
  }

  access {
    group_ids = [twingate_group.engineering.id]
  }
}

resource "twingate_group" "engineering" {
  name = "Engineering Team"
}

Common Zero Trust Implementation Mistakes:

1. "Replace VPN with ZTNA and we're done" mindset
   -> Zero Trust is a strategy, not a product
   -> Requires coverage across network, ID, devices, apps, data

2. Trying to change everything at once
   -> Incremental migration is essential
   -> Start with the highest risks first

3. Ignoring user experience
   -> Too much friction leads to workarounds
   -> Balance security and convenience with SSO + passkeys

4. "Internal = trusted" assumptions baked into code
   -> Need to transition from IP-based to identity-based access control
   -> Plan for legacy app migration

5. Applying policies without visibility
   -> First run in monitoring mode to understand traffic
   -> Then gradually apply blocking policies

6. Overlooking DevOps/CI-CD pipelines
   -> Service accounts and API keys are also Zero Trust subjects
   -> Adopt Workload Identity

zero_trust_kpis:
  identity:
    - metric: "MFA adoption rate"
      target: "100%"
      current_industry_avg: "64%"
    - metric: "Phishing-resistant MFA (FIDO2) ratio"
      target: ">= 80%"
    - metric: "SSO-enabled app ratio"
      target: ">= 95%"
    - metric: "Orphan account count"
      target: "0"

  device:
    - metric: "Managed device ratio"
      target: ">= 95%"
    - metric: "Patch SLA compliance rate"
      target: ">= 90%"
    - metric: "Device compliance rate"
      target: ">= 90%"

  network:
    - metric: "Microsegmentation coverage"
      target: ">= 80%"
    - metric: "mTLS-enabled service ratio"
      target: ">= 95%"
    - metric: "VPN user count"
      target: "0 (fully migrated to ZTNA)"

  incident:
    - metric: "Lateral movement detection time"
      target: "< 1 hour"
    - metric: "Breach impact scope"
      target: "Single microsegment or less"
    - metric: "MTTD (Mean Time To Detect)"
      target: "< 24 hours"