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
- Google BeyondCorp — Original Zero Trust papers
- NIST SP 800-207: Zero Trust Architecture
- SPIFFE/SPIRE — Service identity framework
- HashiCorp Vault
- Sách: Zero Trust Networks — Gilman & Barth (O'Reilly)
💡 Remember: "Trust, but verify" đã lỗi thời. Bây giờ là "Never trust, always verify." Paranoid? Có. Effective? Rất. 🛡️