Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa nhận việc DevOps tại một startup fintech ở TP.HCM. Ngày đầu tiên, sếp đưa cho bạn tài khoản đăng nhập vào AWS Console và nói: "Em có toàn quyền, tha hồ làm việc." Nghe thì sướng, nhưng thực ra đó là một quả bom hẹn giờ. Chỉ cần một lần bạn vô tình chạy nhầm lệnh xóa, hoặc laptop của bạn bị đánh cắp mật khẩu, toàn bộ hạ tầng công ty có thể bị xóa sạch hoặc bị hacker chiếm dụng để đào tiền ảo — dẫn tới hóa đơn hàng chục nghìn USD.
Đây chính là lý do IAM (Identity and Access Management — Quản lý danh tính và quyền truy cập) tồn tại. Trong mọi nền tảng cloud, IAM là lớp bảo vệ đầu tiên và quan trọng nhất. Nó trả lời ba câu hỏi cốt lõi mà bất kỳ hệ thống nào cũng phải giải quyết: Ai (danh tính) được phép làm gì (quyền) trên tài nguyên nào (resource), và trong điều kiện nào (condition).
Nếu bạn học cloud mà bỏ qua IAM, giống như xây nhà mà quên lắp cửa và khóa. Trong bài này, chúng ta sẽ đi sâu vào các khái niệm nền tảng của IAM — User, Group, Role, Policy — và cách chúng phối hợp để tạo ra một hệ thống phân quyền vừa an toàn vừa dễ vận hành. Đây là kiến thức bạn sẽ dùng mỗi ngày trong nghề, và cũng là phần được hỏi nhiều nhất trong các buổi phỏng vấn DevOps.
Khái niệm cốt lõi
IAM không phải một dịch vụ đơn lẻ mà là cả một khung tư duy về việc kiểm soát truy cập. Chúng ta sẽ mổ xẻ từng thành phần.
User — Danh tính con người
User là danh tính đại diện cho một con người cụ thể tương tác với cloud: bạn, đồng nghiệp của bạn, hoặc một nhân viên kế toán cần xem hóa đơn. Mỗi user có tên đăng nhập riêng, mật khẩu riêng, và lý tưởng nhất là bật MFA (Multi-Factor Authentication — xác thực đa yếu tố, ví dụ nhập thêm mã OTP từ app Google Authenticator sau khi nhập mật khẩu).
Nguyên tắc vàng: mỗi con người một user riêng. Tuyệt đối không dùng chung một tài khoản cho cả nhóm. Vì nếu dùng chung, khi có sự cố bạn không thể biết ai đã làm gì — mất hoàn toàn khả năng truy vết (audit trail). Ngoài ra, khi một người nghỉ việc, bạn chỉ cần vô hiệu hóa user của họ mà không ảnh hưởng người khác.
Có một loại user đặc biệt gọi là root user (trên AWS) hoặc tài khoản chủ sở hữu. Đây là user quyền lực nhất, được tạo ra khi bạn đăng ký tài khoản. Root có thể làm mọi thứ, kể cả đóng tài khoản. Vì quá nguy hiểm, quy tắc bất di bất dịch là: bật MFA cho root, cất mật khẩu root vào két, và không bao giờ dùng root cho công việc hằng ngày.
Group — Nhóm để quản lý quyền hàng loạt
Group (nhóm) là tập hợp các user có chung nhu cầu về quyền. Thay vì gán quyền cho từng người một, bạn gán quyền cho group, rồi ném user vào group đó.
Ví dụ, bạn tạo group Developers với quyền truy cập môi trường staging, group DBAdmins với quyền quản lý database, group Finance chỉ được xem billing. Khi có lập trình viên mới vào, bạn chỉ cần thêm họ vào group Developers là xong — họ tự động thừa hưởng toàn bộ quyền của nhóm. Khi họ chuyển sang làm DBA, bạn chuyển họ sang group DBAdmins. Cách này giúp việc quản lý quyền của một công ty 50-100 người trở nên gọn gàng thay vì hỗn loạn.
Lưu ý: group không có thông tin đăng nhập riêng — nó không phải một danh tính mà chỉ là công cụ tổ chức để gán quyền hàng loạt.
Role — Danh tính tạm thời, không mật khẩu
Role (vai trò) là khái niệm hay bị nhầm lẫn nhất, nhưng cực kỳ quan trọng. Khác với user, role không thuộc về một con người cố định và không có mật khẩu. Thay vào đó, role là một tập quyền mà một danh tính có thể "khoác lên người" tạm thời để làm một việc gì đó, rồi trả lại.
Role được dùng chủ yếu trong hai tình huống:
- Máy móc/dịch vụ cần quyền. Ví dụ, một máy chủ EC2 chạy ứng dụng web cần đọc file ảnh từ kho lưu trữ S3. Thay vì nhét mật khẩu vào code (cực kỳ nguy hiểm), bạn gán một role cho máy chủ đó. Máy chủ tự động nhận được "chứng chỉ tạm thời" (temporary credentials) hết hạn sau vài giờ và tự làm mới. Không có mật khẩu nào bị lộ trong code.
- Cấp quyền tạm thời cho con người hoặc tài khoản khác. Ví dụ, một DevOps thường ngày chỉ có quyền đọc, nhưng khi cần xử lý sự cố sản xuất, họ "assume" (khoác lên) một role quyền cao trong 1 giờ, làm xong thì quyền tự hết. Đây gọi là just-in-time access — cấp quyền đúng lúc, tránh giữ quyền cao thường trực.
Policy — Tài liệu định nghĩa quyền
Nếu User, Group, Role trả lời câu hỏi "ai", thì Policy trả lời câu hỏi "được làm gì". Policy là một tài liệu (thường viết bằng JSON) liệt kê rõ: hành động nào (Action) được phép hoặc bị từ chối (Effect: Allow/Deny) trên tài nguyên nào (Resource), trong điều kiện nào (Condition).
Ví dụ một policy đơn giản trên AWS cho phép đọc file trong một bucket S3 tên cong-ty-hoa-don:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::cong-ty-hoa-don/*"
}]
}
Bạn gắn policy này vào một user, group, hoặc role — và danh tính đó lập tức có quyền tương ứng. Trên GCP thuật ngữ tương đương là IAM Role/Binding, còn Azure gọi là Role Assignment, nhưng bản chất tư duy giống hệt nhau.
Nguyên tắc quyền tối thiểu (Least Privilege)
Kim chỉ nam của mọi thiết kế IAM là Principle of Least Privilege: chỉ cấp đúng, đủ quyền cần thiết để hoàn thành công việc, không hơn. Một lập trình viên frontend không cần quyền xóa database. Một script backup chỉ cần quyền đọc và ghi vào một bucket, không cần quyền tạo máy chủ mới. Càng ít quyền dư thừa, "bề mặt tấn công" càng nhỏ, và thiệt hại khi credential bị lộ càng được giới hạn.
Tình huống thực tế
Tình huống 1: Sàn thương mại điện tử và sự cố credential trong code
Một sàn TMĐT tại Hà Nội, gọi là ShopViet, có 15 lập trình viên. Ban đầu, để nhanh gọn, đội dev nhét trực tiếp access key AWS (dạng mật khẩu tĩnh) vào file cấu hình của ứng dụng để nó truy cập S3 và gửi email. Một hôm, một dev vô tình push nhầm file cấu hình lên GitHub công khai.
Chỉ trong 8 phút, các bot dò quét GitHub đã nhặt được key này. Kẻ tấn công dùng key khởi động 40 máy chủ GPU cỡ lớn ở nhiều vùng khác nhau để đào tiền ảo. Đến sáng hôm sau, ShopViet nhận hóa đơn ước tính hơn 12.000 USD.
Diễn giải: Access key tĩnh chính là gót chân Achilles. Nó không hết hạn, có quyền rộng, và một khi lộ là toàn bộ tài khoản gặp nguy. Giải pháp đúng: ứng dụng chạy trên EC2 nên dùng IAM Role gắn vào máy chủ (instance profile) — credentials tạm thời tự sinh, tự hết hạn, không bao giờ nằm trong code. Với CI/CD trên GitHub, dùng cơ chế OIDC federation để GitHub Actions "assume role" tạm thời thay vì lưu key cứng.
Bài học: Đừng bao giờ nhét credential tĩnh vào code hay file cấu hình. Máy móc cần quyền thì dùng Role, không dùng key. Và bật cảnh báo billing để phát hiện chi phí bất thường sớm.
Tình huống 2: Ngân hàng số và mô hình Group + phân tách môi trường
Một ngân hàng số tại Singapore mở rộng đội kỹ thuật từ 20 lên 120 người trong một năm. Ban đầu họ gán quyền thủ công cho từng người, dẫn tới tình trạng hỗn loạn: có người quyền quá cao, có người thiếu quyền phải chờ IT cấp thủ công cả ngày.
Họ tái cấu trúc theo mô hình group rõ ràng: Dev-ReadOnly (xem log, không sửa production), Dev-Deploy (deploy lên staging), SRE-Oncall (quyền cao nhưng phải assume role có MFA và hết hạn sau 4 giờ), Auditor (chỉ đọc log và cấu hình để kiểm toán). Kết hợp với việc tách production và development thành hai tài khoản riêng, quyền của developer thường không hề chạm được vào production.
Diễn giải: Nhờ group, khi có người mới, việc cấp quyền chỉ mất vài phút và luôn nhất quán. Nhờ tách tài khoản, một sai lầm ở môi trường dev không thể lan sang production. Nhờ role có MFA và thời hạn cho quyền cao, ngay cả khi một tài khoản SRE bị chiếm, kẻ tấn công cũng khó vượt qua MFA và chỉ có cửa sổ thời gian hẹp.
Bài học: Trong tổ chức đông người, group là công cụ quản lý sống còn. Với môi trường nhạy cảm như tài chính, hãy tách tài khoản theo môi trường và dùng role tạm thời cho các quyền nguy hiểm.
Tình huống 3: Startup SaaS và bài toán quyền cho đối tác bên thứ ba
Một startup SaaS về phân tích dữ liệu ở Đà Nẵng cần cho phép một công ty đối tác đọc dữ liệu báo cáo trong tài khoản cloud của mình. Cám dỗ ban đầu là tạo một user, đặt mật khẩu, rồi gửi mật khẩu đó cho đối tác qua email. Cách này cực kỳ nguy hiểm: mật khẩu có thể bị chuyển tay, không kiểm soát được, và nếu hợp tác kết thúc thì rất khó thu hồi triệt để.
Thay vào đó, họ tạo một cross-account role — một role trong tài khoản của mình, với "trust policy" chỉ cho phép tài khoản của đối tác được assume. Đối tác dùng danh tính của chính họ để khoác role này, nhận credentials tạm thời, và chỉ đọc được đúng dữ liệu được cho phép.
Diễn giải: Không có mật khẩu nào bị trao tay. Đối tác không có credential thường trực trong hệ thống của bạn. Khi ngừng hợp tác, bạn chỉ cần sửa trust policy là cắt sạch quyền ngay lập tức. Mọi hành động của đối tác đều được ghi log dưới danh tính rõ ràng.
Bài học: Khi cần cấp quyền cho bên ngoài, luôn dùng role với trust policy thay vì phát mật khẩu. Đây là chuẩn mực an toàn cho mọi tích hợp giữa các tổ chức.
Hướng dẫn từng bước
Dưới đây là quy trình thiết lập IAM cơ bản, an toàn cho một dự án mới. Ví dụ dùng bối cảnh AWS, nhưng tư duy áp dụng được cho GCP và Azure.
- Khóa chặt tài khoản root. Bật MFA cho root, đặt mật khẩu mạnh, cất kỹ và không dùng cho việc hằng ngày. Xóa mọi access key của root nếu có.
- Tạo user admin cá nhân. Tạo một IAM user cho chính bạn, gán quyền quản trị, bật MFA. Từ giờ dùng user này thay cho root.
- Thiết kế group theo vai trò. Liệt kê các nhóm công việc trong đội (dev, SRE, kế toán, kiểm toán...) và tạo group tương ứng. Gắn policy phù hợp cho từng group theo nguyên tắc quyền tối thiểu.
- Tạo user cho từng thành viên và đưa vào group. Mỗi người một user, bật MFA bắt buộc. Không dùng chung tài khoản.
- Dùng Role cho máy móc và dịch vụ. Bất kỳ máy chủ, hàm serverless, hay pipeline CI/CD nào cần quyền, hãy tạo role và gắn vào — không tạo user + access key cho máy.
- Áp dụng quyền tạm thời cho tác vụ nhạy cảm. Với quyền cao (xóa tài nguyên, chạm production), yêu cầu assume role có MFA và thời hạn ngắn thay vì gán quyền thường trực.
- Bật ghi log và rà soát định kỳ. Bật audit log (CloudTrail trên AWS) để ghi lại mọi hành động. Định kỳ hằng quý, rà soát và gỡ bỏ user cũ, quyền dư thừa, key không dùng.
Lỗi thường gặp & mẹo
- Dùng root hoặc quyền admin cho mọi việc. Đây là lỗi phổ biến nhất của người mới. Sửa: tạo user riêng, gán quyền tối thiểu, chỉ nâng quyền khi thật sự cần.
- Nhét access key tĩnh vào code hoặc file cấu hình. Như tình huống ShopViet, đây là nguyên nhân số một gây rò rỉ. Mẹo: dùng role cho máy móc, dùng công cụ quét secret (như git-secrets, truffleHog) trong pipeline để chặn key lọt lên git.
- Cấp quyền
(toàn quyền) cho tiện. Rất nhiều người viết policy vớiAction: ""vàResource: "*"cho nhanh. Đây là quả bom. Mẹo: bắt đầu với quyền hẹp, chỉ mở thêm khi ứng dụng báo lỗi thiếu quyền.
- Không bật MFA. Chỉ mật khẩu thôi thì quá mong manh. Bật MFA cho tất cả user, đặc biệt là user có quyền cao.
- Quên thu hồi quyền khi nhân viên nghỉ hoặc đổi vai trò. Mẹo: dùng group để việc chuyển/gỡ quyền chỉ là một thao tác, và rà soát định kỳ danh sách user.
- Nhầm lẫn Role với User. Nhớ: User có mật khẩu, dành cho người, tồn tại lâu dài. Role không mật khẩu, dùng credentials tạm thời, dành cho máy móc hoặc quyền tạm.
- Mẹo lớn: Luôn ưu tiên gán policy cho group (với người) và role (với máy/quyền tạm), hạn chế tối đa việc gán policy trực tiếp cho từng user — sẽ khó quản lý khi hệ thống lớn lên.
Bài tập thực hành
- Thiết kế trên giấy. Giả sử bạn phụ trách IAM cho một công ty gồm: 5 lập trình viên, 2 kỹ sư vận hành (SRE), 1 kế toán, và 1 kiểm toán viên bên ngoài. Hãy liệt kê các group bạn sẽ tạo và mô tả ngắn gọn quyền tối thiểu cho mỗi group.
- Phân biệt khái niệm. Với mỗi tình huống sau, xác định nên dùng User, Group hay Role: (a) một máy chủ web cần đọc file từ storage; (b) một nhân viên mới gia nhập đội dev; (c) một công ty đối tác cần truy cập tạm thời vào dữ liệu của bạn; (d) một pipeline CI/CD cần deploy ứng dụng.
- Đọc hiểu policy. Viết (bằng lời hoặc JSON) một policy cho phép một danh tính chỉ được đọc (không ghi, không xóa) các đối tượng trong một bucket S3 tên
bao-cao-thang, và giải thích tại sao bạn không dùngAction: "*".
- Rà soát rủi ro. Cho tình huống: một startup dùng chung một tài khoản admin cho cả đội 8 người, access key được lưu trong file
.envcommit lên GitHub private. Hãy chỉ ra ít nhất 4 rủi ro và đề xuất cách khắc phục cho từng cái.
Tóm tắt
IAM là nền tảng bảo mật của mọi hệ thống cloud, trả lời câu hỏi ai được làm gì trên tài nguyên nào. Bốn khái niệm cốt lõi bạn phải nắm chắc:
- User: danh tính con người, có mật khẩu, nên bật MFA, mỗi người một user riêng.
- Group: tập hợp user chung quyền, công cụ quản lý phân quyền hàng loạt gọn gàng.
- Role: danh tính tạm thời không mật khẩu, dùng credentials hết hạn, lý tưởng cho máy móc, dịch vụ và cấp quyền tạm.
- Policy: tài liệu (thường là JSON) định nghĩa cụ thể quyền được phép hay bị từ chối.