ChatBot AI

Tưởng tượng bạn là một startup founder. Bạn vừa tạo tài khoản AWS, bắt đầu thuê máy ảo để chạy backend, lưu ảnh trên S3, và setup database trên RDS. Mọi thứ chạy tốt... cho đến khi một lập trình viên mới nhất vô tình chạy một lệnh xóa trên production database. Tại sao lại xảy ra như vậy? Vì bạn đã trao cho họ "chìa khóa tổng" của tài khoản AWS mà không biết nó nguy hiểm đến mức nào.

Root Account Và IAM User Là Gì? Tại Sao Phải Phân Biệt?

Root Account là tài khoản "thần thánh" mà bạn sử dụng khi lần đầu tiên đăng ký AWS. Nó có quyền không giới hạn: có thể tạo/xóa bất kỳ resource nào, quản lý billing, thay đổi thông tin tài khoản, tắt bảo mật hai lớp (2FA), thậm chí xóa toàn bộ tài khoản AWS. Nếu ai có access vào Root Account, họ có quyền "làm tất cả".

IAM User (Identity and Access Management User) là một "tài khoản phụ" mà bạn tạo ra để cấp cho team. Mỗi IAM User có thể được gán một tập hợp quyền cụ thể. Đó là "chìa khóa riêng" với quyền hạn rõ ràng.

Tại sao phải phân biệt? Đơn giản: an toàn. Nếu một IAM User bị compromise, attacker chỉ có thể làm những gì mà user đó được phép làm. Nhưng nếu Root Account bị hack? Hacker có toàn quyền kiểm soát tài khoản, có thể xóa mọi dữ liệu, lạm dụng tài nguyên để khai thác tiền ảo hoặc bán dữ liệu của bạn. Chi phí thiệt hại có thể lên tới hàng triệu đô.

Use Case Thực Tế: Khi Nào Sử Dụng Root? Khi Nào Dùng IAM?

Use case 1 — Startup vừa thành lập: Bạn (founder) dùng Root Account chỉ để setup lần đầu. Sau đó, tạo 2-3 IAM Users cho team dev: một user có quyền S3 + EC2, một user quản lý database. Mỗi người chỉ có quyền cần thiết để làm việc của họ.
Use case 2 — Công ty đã phát triển: Root Account chỉ được sử dụng rất hiếm. Mọi công việc hàng ngày được thực hiện qua IAM Users + IAM Roles. Bạn có một user cho team DevOps, một user cho team Data, một user cho team Finance. Nếu một developer vô tình chạy một câu lệnh nguy hiểm, nó sẽ bị block.
Use case 3 — Startup muốn tăng bảo mật: Root Account được lock đặc biệt chặt (enable 2FA + MFA). Tất cả IAM Users sử dụng Temporary Security Credentials (được tạo tự động bằng STS) thay vì permanent access keys, giúp giảm rủi ro nếu credentials bị leak.

Hướng Dẫn Từng Bước: Cách Chia Quyền An Toàn Cho Team

Bước 1: Bảo Vệ Root Account

Sau khi tạo tài khoản AWS, bước đầu tiên là bảo vệ Root Account:

Bật Multi-Factor Authentication (MFA): Vào Account Settings → MFA device → scan QR code bằng Google Authenticator hoặc Authy.
Tạo access key root không bao giờ. Root Account chỉ sử dụng password.
Lưu mật khẩu Root ở một nơi an toàn (password manager, hoặc thậm chí in ra và lock trong safe).
Không share Root Account password cho ai, kể cả team lead.

Bước 2: Tạo IAM Users Cho Team

Đăng nhập bằng Root Account (lần cuối cùng!), vào AWS IAM Console:

Chọn "Users" → "Create user".
Đặt tên user: ví dụ "dev-team-1", "alice-devops", "bob-datascience".
Chọn "Provide user access to the AWS Management Console".
Bật "Require new password" (user sẽ phải đặt mật khẩu riêng lần đầu đăng nhập).
Click "Create user".

Bước 3: Gán Permissions Sử Dụng Policies

Sau khi tạo user, bạn cần gán quyền. AWS cung cấp hai cách:

Managed Policies (đơn giản): AWS đã viết sẵn các policy cho các công việc phổ biến. Ví dụ: "AmazonS3FullAccess" (toàn quyền S3), "AmazonEC2ReadOnlyAccess" (chỉ đọc EC2).
Custom Policies (an toàn hơn): Bạn viết một policy JSON để chỉ định chính xác quyền. Bạn kiểm soát từng hành động (Action), từng resource, thậm chí cấu hình điều kiện (Condition).

Mẹo từ kinh nghiệm: Không bao giờ hardcode access keys vào source code hoặc commit vào Git. Nếu bạn đã làm vậy, hãy rotate key ngay vì key đó là công khai.

Những Sai Lầm "Cạp Cùm" Mà Mọi Người Mắc Phải

Sai lầm 1: Sử dụng Root Account Hàng Ngày

Một founder từng để Root Account password trong file notes.txt trên máy tính. Một năm sau, khi máy tính bị lạm dụng, attacker tìm thấy file này, tạo 100 EC2 instances crypto mining, và founder bị tính hóa đơn hàng triệu đô. Root Account là "nuclear button" — bạn chỉ bấm nó khi thực sự cần thiết.

Sai lầm 2: Gán Policy "FullAccess" Cho Mọi IAM User

Lý do là nó "dễ" nhưng nguy hiểm. Nếu một IAM User bị hack, attacker có thể làm bất kỳ điều gì. Hãy áp dụng Principle of Least Privilege (PoLP): mỗi user chỉ được quyền tối thiểu cần thiết để hoàn thành công việc.

Những Câu Hỏi Thường Gặp

Q: Mình có 10 người trong team dev, mỗi người cần 1 IAM User riêng, hay nên tạo 1 user dùng chung?
A: Tuyệt đối phải tạo 1 user riêng cho mỗi người. Nếu dùng chung, bạn không biết ai làm hành động gì, và khi 1 người rời công ty, bạn phải tạo password mới cho cả team.

Q: IAM User có thể thay đổi quyền của chính nó không?
A: Không, trừ khi bạn cấp cho nó quyền. Mặc định, IAM User không có quyền "sửa chính mình".

Kết Luận: Bảo Mật Bắt Đầu Từ Những Bước Nhỏ

Root Account vs IAM User không phải là một khái niệm phức tạp, nhưng hậu quả của việc bỏ qua nó có thể rất nghiêm trọng. Một vài bước đơn giản — bảo vệ Root Account, tạo IAM Users cho team, gán permissions cụ thể — có thể giúp bạn tránh được những thảm họa bảo mật. Team của bạn sẽ làm việc an toàn hơn. Vậy nên, hãy dành 30 phút hôm nay để setup IAM users cho team bạn nếu bạn chưa làm — đó là 30 phút tốt nhất của tuần này!