🔐 Security✍️ Khoa📅 19/04/2026☕ 6 phút đọc

Zero Trust Architecture — Tin Ai Bây Giờ?

"Never trust, always verify." Nghe như paranoia? Đúng rồi. Nhưng trong security, paranoia là chiến lược tốt nhất.

Mô hình truyền thống: "Trong VPN = an toàn, ngoài = nguy hiểm." Zero Trust nói: "Ở đâu cũng nguy hiểm. Verify EVERYTHING."


1. Tại sao Zero Trust?

Mô hình Castle-and-Moat (truyền thống):
  
  🏰 [Firewall/VPN]
  ├── Bên trong: trust everything
  └── Bên ngoài: block everything
  
  Vấn đề:
  → Attacker vào được VPN = game over
  → Insider threat không bị detect
  → Cloud/remote work phá vỡ "perimeter"
  → Lateral movement: 1 compromised service → access ALL

Zero Trust Model:
  → Không có "inside" và "outside"
  → Mọi request phải authenticated + authorized
  → Mọi connection phải encrypted
  → Least privilege: chỉ access đúng cần thiết
  → Assume breach: design as if already compromised

2. Zero Trust Principles (Google BeyondCorp)

1. Network location không quyết định trust
   ❌ "Request từ internal network → trusted"
   ✅ "Mọi request → verify identity + device + context"

2. Access dựa trên identity, device, và context
   → WHO: user identity (SSO, MFA)
   → WHAT: device health (patched? managed? encrypted?)
   → WHERE: location, time, risk score
   → WHY: business justification

3. Access should be ephemeral
   → Short-lived tokens (15 phút, không 24 giờ)
   → Re-authenticate cho sensitive operations
   → Session expiry + renewal

4. Encrypt everything
   → mTLS cho service-to-service
   → TLS 1.3 cho external
   → Encrypt data at rest

3. mTLS — Service-to-Service Authentication

3.1 Concept

Regular TLS:
  Client verifies server's certificate
  "Tôi đang nói chuyện với đúng server"

mTLS (mutual TLS):
  Client verifies server AND server verifies client
  "CẢ HAI bên đều chứng minh danh tính"

  ┌────────┐                    ┌────────┐
  │ Svc A  │── client cert ──→ │ Svc B  │
  │        │←── server cert ── │        │
  └────────┘                    └────────┘
  
  Svc B biết chắc request đến từ Svc A (không phải attacker)
  Svc A biết chắc đang nói với đúng Svc B

3.2 Implementation Patterns

Option 1: Service Mesh (Istio/Linkerd)
  → mTLS tự động giữa tất cả services
  → Sidecar proxy handle TLS, app không cần thay đổi
  → Certificate rotation tự động
  → Authorization policies declarative

  # Istio: enable mTLS cho namespace
  apiVersion: security.istio.io/v1beta1
  kind: PeerAuthentication
  metadata:
    name: default
    namespace: production
  spec:
    mtls:
      mode: STRICT  # Reject non-mTLS traffic

Option 2: Certificate Manager (Vault, SPIFFE)
  → SPIFFE: identity framework cho services
  → SPIRE: SPIFFE runtime, issue short-lived certs
  → Vault PKI: generate và rotate certificates
  → App-level TLS configuration

Option 3: DIY (cho small scale)
  → Generate CA + certs với openssl hoặc cfssl
  → Distribute certs qua K8s secrets
  → ⚠️ Manual rotation = operational burden

3.3 mTLS trong Go

// Server with mTLS
func startMTLSServer() {
    caCert, _ := os.ReadFile("ca.pem")
    caCertPool := x509.NewCertPool()
    caCertPool.AppendCertsFromPEM(caCert)

    tlsConfig := &tls.Config{
        ClientCAs:  caCertPool,
        ClientAuth: tls.RequireAndVerifyClientCert,
        MinVersion: tls.VersionTLS13,
    }

    server := &http.Server{
        Addr:      ":8443",
        TLSConfig: tlsConfig,
    }
    server.ListenAndServeTLS("server.pem", "server-key.pem")
}

// Client with mTLS
func callWithMTLS(url string) (*http.Response, error) {
    cert, _ := tls.LoadX509KeyPair("client.pem", "client-key.pem")
    caCert, _ := os.ReadFile("ca.pem")
    caCertPool := x509.NewCertPool()
    caCertPool.AppendCertsFromPEM(caCert)

    client := &http.Client{
        Transport: &http.Transport{
            TLSClientConfig: &tls.Config{
                Certificates: []tls.Certificate{cert},
                RootCAs:      caCertPool,
            },
        },
    }
    return client.Get(url)
}

4. Secrets Management

4.1 Anti-patterns

❌ Hardcode trong code:
   dbPassword := "super_secret_123"

❌ Environment variables (better, nhưng vẫn risky):
   → Visible trong process listing (ps aux)
   → Logged bởi many frameworks
   → Không rotate được dễ dàng
   → Không audit access

❌ Config files trong repo:
   → Dù .gitignore, sai 1 lần = leaked forever
   → Git history giữ secrets vĩnh viễn

4.2 Secrets Management Tools

HashiCorp Vault:
  → Dynamic secrets: generate DB credentials on-demand
  → Auto-rotation: secrets tự expire + renew
  → Audit log: ai access secret nào, khi nào
  → Encryption as a Service: encrypt/decrypt qua API

AWS Secrets Manager:
  → Managed, serverless
  → Auto-rotation cho RDS, Redshift
  → Cross-account sharing
  → Integrated với AWS services

Kubernetes Secrets + External Secrets Operator:
  → Sync secrets từ Vault/AWS vào K8s Secrets
  → App đọc từ mounted volume hoặc env
  → Rotation trigger pod restart

SOPS (Mozilla):
  → Encrypt secrets trong git (YAML/JSON)
  → KMS key cho encryption
  → Diff-friendly (chỉ encrypt values, không keys)
  → Good cho GitOps workflows

4.3 Secret Rotation Pattern

Phase 1: Generate new secret (parallel)
  Old secret: ACTIVE
  New secret: ACTIVE (cả 2 đều valid)

Phase 2: Update consumers
  All services switch to new secret
  Monitor for errors

Phase 3: Revoke old secret
  Old secret: REVOKED
  New secret: ACTIVE (only)

Tại sao overlap period quan trọng:
  → Rolling deployment: some pods dùng old, some dùng new
  → Nếu revoke old trước khi all pods update → outage
  → Overlap = zero-downtime rotation

5. Network Segmentation

Zero Trust Network:

  ┌──────────────────────────────────┐
  │ Public Subnet                    │
  │  ┌─────────────┐                │
  │  │ API Gateway  │ ← WAF, DDoS   │
  │  └──────┬──────┘                │
  └─────────┼────────────────────────┘
  - - - - - │ - - - - - trust boundary
  ┌─────────┼────────────────────────┐
  │ App Subnet (private)             │
  │  ┌──────▼──────┐  ┌───────────┐ │
  │  │ Order Svc   │──│Payment Svc│ │ ← mTLS between services
  │  └──────┬──────┘  └───────────┘ │
  └─────────┼────────────────────────┘
  - - - - - │ - - - - - trust boundary
  ┌─────────┼────────────────────────┐
  │ Data Subnet (isolated)           │
  │  ┌──────▼──────┐  ┌───────────┐ │
  │  │  PostgreSQL  │  │   Redis   │ │ ← Chỉ App Subnet access
  │  └─────────────┘  └───────────┘ │
  └──────────────────────────────────┘

Security Groups:
  → API Gateway: allow 443 from internet
  → App services: allow from API Gateway + other app services
  → Database: allow from App Subnet ONLY
  → Deny all by default

6. Encryption Deep Dive

At Rest:
  → Database: Transparent Data Encryption (TDE)
  → Disk: LUKS, AWS EBS encryption, GCP CMEK
  → Application-level: encrypt sensitive fields before storage
  → Key management: KMS (AWS/GCP), Vault Transit

In Transit:
  → External: TLS 1.3 (mandatory)
  → Internal: mTLS hoặc TLS (service mesh tự động)
  → Database connections: TLS + certificate verification

Key Management:
  → NEVER store encryption keys next to encrypted data
  → Use KMS: keys never leave hardware security module (HSM)
  → Key rotation: generate new key, re-encrypt data gradually
  → Envelope encryption:
    Data Encryption Key (DEK) encrypts data
    Key Encryption Key (KEK) encrypts DEK
    → Chỉ cần rotate KEK, không cần re-encrypt all data

7. Tóm tắt

Zero Trust Checklist:

  □ Identity: Strong auth (SSO + MFA) cho mọi access
  □ Device: Verify device health trước khi grant access
  □ Network: mTLS giữa services, network segmentation
  □ Secrets: Vault/KMS, auto-rotation, audit access
  □ Encryption: At rest + in transit, KMS key management
  □ Least privilege: RBAC/ABAC, short-lived credentials
  □ Monitoring: Audit logs, anomaly detection, SIEM
  □ Assume breach: Design for containment, not prevention

Tài liệu tham khảo


💡 Remember: "Trust, but verify" đã lỗi thời. Bây giờ là "Never trust, always verify." Paranoid? Có. Effective? Rất. 🛡️