Auditing AWS IAM for better security practices

Bài tóm tắt Postman 2019 2. Tăng trưởng Độ khó: Cơ bản

Postman · 2019 · 2. Tăng trưởng · Độ khó: Cơ bản — bài gốc

Bài đăng trên publication DevRel của Postman và cuối bài quảng bá một template Postman; phần đáng giữ là cấu trúc IAM và việc chuyển audit từ tay sang lịch tự động.

Bối cảnh

  • Mỗi dịch vụ cloud mới đều có IAM riêng chỉ cần vài cú nhấp để cấp quyền; theo bài, nếu khả năng đánh giá và thu hồi quyền không tăng theo thì quyền thừa tích tụ thành rủi ro rò rỉ từ bên trong.
  • Postman (2019) chạy microservice trên AWS (Beanstalk, RDS, ElastiCache, nhóm Data Science dùng DynamoDB, Kinesis, Redshift, EMR…).

Thay đổi chính

  • IAM phản ánh sơ đồ tổ chức: IAM user theo email nhân viên; IAM group theo team (Services, App, DevOps, Security, Data Science, Marketing) với các nhóm anh em <team>-admins, -power-users, -users, -interns; thêm group theo service <service>-admins cho chủ của từng microservice. Chia group theo dịch vụ AWS mà team thật sự dùng.
  • Chiến lược audit ba lớp: (1) cơ chế xác thực: root key tắt, chính sách mật khẩu, MFA; (2) tương tác của thực thể IAM: xoay key (người 45 ngày, bot 180 ngày), thực thể không hoạt động quá 180 ngày, quyền không dùng trong 180 ngày (dựa trên Last Accessed Data), policy wildcard *; (3) cấu trúc IAM còn khớp tổ chức không, group không phải admin có bị gắn quyền phá huỷ không.
  • Từ tay sang lịch: lần audit đầu làm tay theo checklist mất 3 ngày; họ chuyển thành một collection gọi IAM REST API, chạy định kỳ bằng Monitor và đẩy kết quả vào Slack.

Vì sao

  • Quyền gắn với thực thể IAM thay đổi liên tục, nên audit phải chạy thường xuyên; làm tay 3 ngày mỗi lần thì không duy trì được (theo Postman).
  • Bài nói rõ chỉ dừng ở phát hiện; cách khắc phục không được mô tả.

Bài học cho SWE

  • Cấu trúc quyền bám theo cấu trúc tổ chức thì audit được bằng máy: "group không phải admin có quyền xoá không" là một truy vấn, không phải một cuộc phỏng vấn.
  • Quyền không dùng trong N ngày là tín hiệu thu hồi rẻ và khách quan.
  • Đối chiếu: Segment 2018 đi xa hơn, bỏ hẳn IAM user có key cho người và cấp quyền tạm qua IdP (Segment 2018); với mô hình còn key dài hạn như Postman, xoay vòng và audit định kỳ là lớp bảo vệ chính.

Liên quan