SA.

Bài blog

Zero Trust Architecture: Identity Là Perimeter Mới

Never trust, always verify — zero trust chuyển security từ network edge đến mọi request, mọi service, mọi identity.

Danh mục
system-design
Xuất bản
Ổ khóa kỹ thuật số xanh và dấu vân tay — minh họa bảo mật mạng và xác thực

Zero Trust Thay Thế Gì

Mô hình security truyền thống giả định rằng mọi thứ bên trong mạng nội bộ đều đáng tin cậy. VPN cho bạn truy cập mạng, và mạng cho bạn truy cập service. Đây là mô hình castle-and-moat: cứng bên ngoài, mềm bên trong.

Mô hình này thất bại theo hai cách: thứ nhất, nếu attacker vào được bên trong perimeter, họ có thể di chuyển ngang với ít ma sát. Thứ hai, các hệ thống hiện đại không có perimeter rõ ràng.

Zero trust thay thế vị trí mạng bằng identity làm trust anchor. Ở trên mạng không có nghĩa gì. Mọi request phải được xác thực và phân quyền, bất kể xuất phát từ đâu.

Ba Nguyên Tắc

1. Xác minh rõ ràng. Xác thực và phân quyền mọi request sử dụng tất cả tín hiệu có sẵn: identity, tình trạng device, vị trí, thời gian. Không bao giờ cấp quyền chỉ dựa trên vị trí mạng.

2. Sử dụng quyền truy cập tối thiểu. Mỗi service, user, và device nhận quyền tối thiểu cần thiết.

3. Giả định đã bị xâm phạm. Thiết kế như thể attacker đã ở bên trong. Phân đoạn mọi thứ. Log mọi thứ. Giảm thiểu blast radius.

Những Gì Bạn Thực Sự Triển Khai

mTLS cho xác thực service-to-service

Mutual TLS là nền tảng của zero trust cho giao tiếp service. Cả hai bên đều trình bày certificate: client xác thực server (TLS tiêu chuẩn) và server xác thực client (phần "mutual").

Trong service mesh như Istio hay Linkerd, mTLS được thực thi tự động. Mỗi service nhận certificate ngắn hạn, và sidecar proxy xử lý mTLS handshake trong suốt.

Chính sách phân quyền tập trung

Authentication cho bạn biết ai đang gọi. Authorization cho bạn biết họ được phép làm gì. Trong zero trust, chính sách phân quyền được tập trung và thực thi tại policy engine.

Open Policy Agent (OPA) là lựa chọn phổ biến: policy được viết bằng Rego, đánh giá tại sidecar hoặc API gateway.

Credential ngắn hạn

API key dài hạn là rủi ro. Hệ thống zero trust sử dụng token ngắn hạn (JWT có expiry, SPIFFE SVIDs, AWS STS temporary credentials) hết hạn trong vài phút đến vài giờ.

Nơi Team Bị Kẹt

Retrofit service cũ. Service xác thực bằng shared secret hay IP allowlist khó migrate. Đặt chúng sau API gateway hay service mesh xử lý mTLS thay thế họ, sau đó migrate auth nội bộ dần.

Certificate rotation ở quy mô lớn. Nếu bạn quản lý certificate thủ công, rotation trở thành rủi ro reliability. Tự động hóa từ đầu với cert-manager hoặc SPIRE.

Con Đường Migration

Zero trust không phải một dự án đơn — đó là một hướng đi:

  1. Kiểm kê tất cả service-to-service call và ánh xạ authentication hiện tại của chúng.
  2. Deploy service mesh ở chế độ observe để hiểu traffic pattern.
  3. Bật mTLS enforcement từng service một, bắt đầu từ path rủi ro nhất.
  4. Migrate user access sang short-lived token và device-aware policy.
  5. Tập trung authorization policy và xóa authorization logic khỏi application code.