Ngôn ngữ hiển thị:
Ngôn ngữ hiển thị:
ChatBot AICó một misconception khá phổ biến mà mình thấy ở nhiều team khi migrate lên AWS: họ nghĩ rằng đặt tất cả workload vào trong VPC private là đủ an toàn. Khổ nỗi là, khi attacker đã vào được bên trong — dù qua credential bị lộ hay lateral movement — thì cái "tường thành" đó chẳng còn ý nghĩa gì. Zero Trust ra đời để giải quyết đúng vấn đề này: không tin tưởng bất kỳ ai, kể cả traffic nội bộ.
Nói thẳng: không có một tool nào bán "Zero Trust" cho bạn cả. Đây là một triết lý bảo mật dựa trên ba nguyên tắc cốt lõi: verify explicitly (xác thực mọi request bất kể nguồn gốc), use least privilege (chỉ cấp đúng quyền cần thiết), và assume breach (luôn giả định hệ thống đã bị xâm phạm).
Trên AWS, để hiện thực hóa ba nguyên tắc này, mình cần ít nhất hai thành phần trụ cột: IAM Identity Center để quản lý danh tính và xác thực tập trung, và VPC Lattice để kiểm soát giao tiếp giữa các service theo chính sách rõ ràng. Hai thứ này phối hợp với nhau mới tạo ra một mô hình Zero Trust thực sự — chứ không phải chắp vá.
Trước đây gọi là AWS SSO, IAM Identity Center giờ là nền tảng để quản lý access cho người dùng và ứng dụng trên toàn bộ AWS Organization. Thay vì mỗi account có IAM user riêng (một mớ credential riêng lẻ, khó audit), bạn có một điểm quản lý duy nhất.
Điều mình đánh giá cao nhất là Permission Sets. Thay vì assign trực tiếp IAM policy vào user, bạn định nghĩa permission set (ví dụ: ReadOnlyAccess-Prod, DevAccess-Staging) rồi gán cho group từ Identity Provider (IdP) của bạn — Okta, Azure AD, hay bất kỳ SAML 2.0 provider nào. Khi nhân viên nghỉ việc, remove họ khỏi IdP là xong — không cần chạy vào từng AWS account để revoke.
Một tính năng quan trọng khác là Attribute-Based Access Control (ABAC). Với ABAC, bạn viết policy dựa trên tag thay vì resource ARN cố định:
{
"Condition": {
"StringEquals": {
"aws:ResourceTag/Environment": "${aws:PrincipalTag/Environment}"
}
}
}Policy trên đảm bảo developer được tag Environment=staging chỉ có thể thao tác resource cũng được tag Environment=staging. Không cần viết hàng chục policy riêng cho từng môi trường.
Để kết nối IdP bên ngoài, vào IAM Identity Center → Settings → Identity source → Change, chọn External identity provider rồi upload SAML metadata. Sau đó enable SCIM provisioning để user và group tự đồng bộ — không cần import thủ công.
Đây là phần mà nhiều team bỏ qua nhất. Họ chú tâm vào bảo mật access của người dùng nhưng để service nội bộ giao tiếp với nhau mà không có authentication, không có authorization. Kết quả: nếu một service bị compromise, attacker có thể gọi tự do sang các service khác trong cùng VPC.
VPC Lattice giải quyết vấn đề này bằng cách tạo ra một application networking layer độc lập với hạ tầng mạng. Mỗi service đăng ký vào Service Network, và mọi request giữa các service đều phải qua layer này — nơi mà auth policy được kiểm tra trước khi forward.
Các khái niệm cần nắm:
Service Network: Đơn vị tổ chức cấp cao nhất. Bạn associate VPC và service vào service network này. Mọi VPC trong cùng network có thể kết nối với nhau, kể cả cross-account.
Service: Đại diện cho một workload cụ thể (Lambda function, ECS service, EC2 instance group, hoặc K8s pod). Mỗi service có DNS name riêng được VPC Lattice quản lý.
Auth Policy: Đây là trái tim của Zero Trust. Auth policy viết bằng IAM policy language, quy định ai (principal) được gọi vào service nào với điều kiện gì:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/OrderService"
},
"Action": "vpc-lattice-svcs:Invoke",
"Resource": "*",
"Condition": {
"StringEquals": {
"vpc-lattice-svcs:RequestMethod": "POST"
}
}
}]
}Policy trên chỉ cho phép OrderService role gọi POST request — không hơn, không kém. Cái hay là policy này được enforce ở network level, không cần code trong từng service phải tự implement auth logic.
Mẹo xương máu: Enable Sigv4 signing cho VPC Lattice request. Khi đó, mỗi request từ service của bạn sẽ được ký bằng IAM credentials của service đó. VPC Lattice sẽ verify chữ ký trước khi forward — không cần thêm API key hay custom header nào cả.
Đây là luồng mà mình thấy hiệu quả nhất cho môi trường multi-account:
1. Thiết lập IAM Identity Center ở management account
# Bật IAM Identity Center (chỉ làm 1 lần qua console)
# Sau đó tạo Permission Set cho developer
aws sso-admin create-permission-set --instance-arn $INSTANCE_ARN --name "DevAccess-Staging" --session-duration "PT8H"
aws sso-admin attach-managed-policy-to-permission-set --instance-arn $INSTANCE_ARN --permission-set-arn $PERMISSION_SET_ARN --managed-policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess2. Tạo Service Network cho VPC Lattice
aws vpc-lattice create-service-network --name "prod-service-network" --auth-type "AWS_IAM"
# Associate VPC vào service network
aws vpc-lattice create-service-network-vpc-association --service-network-identifier $NETWORK_ID --vpc-identifier $VPC_ID3. Register service và gắn auth policy
SERVICE_ARN=$(aws vpc-lattice create-service --name "payment-service" --auth-type "AWS_IAM" --query 'arn' --output text)
aws vpc-lattice put-auth-policy --resource-identifier $SERVICE_ARN --policy file://auth-policy.jsonNói thật thì phần hay nhất là sau khi setup xong, developer không cần làm gì khác. Họ vẫn gọi service qua DNS name như bình thường, chỉ khác là request giờ được Sigv4-signed tự động bởi SDK — nếu bạn dùng AWS SDK thì enable signingEnabled: true trong config là đủ.
Resource-based policy vs. auth policy nhầm lẫn nhau. VPC Lattice có hai loại policy: auth policy (kiểm soát ai được invoke service) và resource policy (kiểm soát ai được share service network cross-account). Lần đầu setup mình nhầm hai cái này, kết quả là service register thành công nhưng không có traffic nào vào được vì auth policy để mặc định là deny-all.
DNS resolution phải được bật trong VPC. VPC Lattice dùng Route 53 Private Hosted Zone để resolve DNS của service. Nếu VPC chưa bật enableDnsHostnames và enableDnsSupport, service discovery sẽ thất bại im lặng — không có error message rõ ràng, chỉ là connection timeout.
IAM Identity Center session duration mặc định là 1 giờ. Với developer phải làm việc liên tục, cứ 1 giờ phải re-authenticate một lần là cực kỳ khó chịu. Tăng lên 8 hoặc 12 giờ tùy policy công ty — nhưng đừng quên review lại khi có sự cố bảo mật.
CloudTrail logging cho VPC Lattice chưa granular như mong đợi. Access log của VPC Lattice ghi vào S3 hoặc CloudWatch, nhưng format hơi khác so với ALB log. Nếu team bạn đang dùng tool phân tích log cụ thể, cần test trước khi đưa vào production.
Q: VPC Lattice có hỗ trợ gRPC không, hay chỉ HTTP/HTTPS?A: VPC Lattice hiện hỗ trợ HTTP/1.1, HTTP/2 và HTTPS. gRPC chạy trên HTTP/2 nên về lý thuyết hoạt động được, nhưng bạn cần test kỹ vì gRPC dùng trailer-based status code — một số tính năng của VPC Lattice có thể chưa tương thích hoàn toàn. Kiểm tra AWS VPC Lattice documentation để cập nhật tính năng mới nhất.
Q: Chi phí của VPC Lattice tính như thế nào? Có đắt hơn dùng ALB nội bộ không?A: VPC Lattice tính phí theo Service Network hour, LCU (Lattice Capacity Unit) xử lý request, và data transfer. Với traffic thấp đến trung bình, chi phí thường thấp hơn hoặc tương đương ALB. Nhưng lợi thế thực sự là giảm chi phí vận hành — không cần quản lý target group, health check phức tạp, hay security group rules chồng chéo.
Q: Có thể dùng VPC Lattice mà không cần IAM Identity Center không?A: Được. IAM Identity Center và VPC Lattice là hai service độc lập. IAM Identity Center quản lý access của người dùng (human identity), còn VPC Lattice quản lý giao tiếp giữa service (machine identity). Bạn có thể triển khai từng thứ một tùy theo mức độ ưu tiên — nhiều team bắt đầu với IAM Identity Center trước vì ROI rõ ràng hơn.
Zero Trust không phải là dự án làm một lần xong. Đây là hành trình chuyển đổi tư duy từ "bảo vệ perimeter" sang "xác thực mọi thứ". IAM Identity Center và VPC Lattice là hai công cụ mạnh mà AWS cung cấp sẵn — nhưng hiệu quả hay không phụ thuộc vào cách bạn thiết kế policy và duy trì nó.
Nghĩ mà xem: nếu ngày mai một credential của developer bị lộ, với mô hình cũ attacker có thể đi khắp nơi trong VPC. Với Zero Trust, họ chỉ thấy đúng những resource mà credential đó được phép — và mọi hành động đều để lại dấu vết trong CloudTrail để bạn phát hiện kịp thời.
Điểm khởi đầu thực tế: bắt đầu với IAM Identity Center cho team hiện tại, migrate dần IAM user sang permission set, rồi từng bước đưa service quan trọng nhất vào VPC Lattice. Đừng cố làm tất cả cùng lúc — Zero Trust triển khai theo từng layer mới bền vững.
