Đánh giá chính sách IAM và từ chối tường minh

Sử dụng AWS Security dành cho Developer

Rahul Singh

Technical Product Manager

Một policy là danh sách quy tắc

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports/*",
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "true"
    },
    "IpAddress": {
      "aws:SourceIp": "203.0.113.0/24"
    }
  }
}

Ba trường của một câu lệnh IAM xếp dọc trên một trục và đánh số 1 đến 3: Effect là allow hoặc deny, Action là gọi API nào, và Resource là đối tượng được trỏ tới, được đặt tên bằng ARN.

Một policy là danh sách quy tắc

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports/*",
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "true"
    },
    "IpAddress": {
      "aws:SourceIp": "203.0.113.0/24"
    }
  }
}

Bốn trường của một câu lệnh IAM xếp dọc trên một trục và đánh số 1 đến 4: Effect là allow hoặc deny, Action là gọi API nào, Resource là đối tượng được trỏ tới đặt tên bằng ARN, và Condition là các điều kiện cần thỏa. Dòng kết: bốn trường, một quy tắc.

Ba trường hỏi, một trường trả lời

Câu hỏi

Action: có phải là lời gọi này không
Resource: có phải là mục tiêu này không
Condition: điều kiện có khớp không

Câu trả lời

Effect: allow hay deny

Bốn trường của một câu lệnh IAM xếp dọc: Action, Resource và Condition được gom bởi một ngoặc nhọn ghi "Câu hỏi", và Effect được gom bởi một ngoặc khác ghi "Câu trả lời".

Quy tắc đến từ nhiều nơi

Một tài liệu policy gắn với một role, với mũi tên từ role sang một bucket.

Dựa trên danh tính (Identity-based)

Gắn vào role
Role này có thể làm gì

Quy tắc đến từ nhiều nơi

Một tài liệu policy gắn với một role, với mũi tên từ role sang một bucket.

Một tài liệu policy gắn với một tài nguyên, với mũi tên từ principal sang một bucket.

Dựa trên danh tính (Identity-based)

Gắn vào role
Role này có thể làm gì

Dựa trên tài nguyên (Resource-based)

Gắn vào đối tượng được truy cập
Ai có thể truy cập bucket này

Khi các quy tắc mâu thuẫn

{"Effect": "Allow", "Action": "s3:*", "Resource": "*"}
{"Effect": "Deny",  "Action": "s3:DeleteObject", "Resource": "*"}

Khi các quy tắc mâu thuẫn

{"Effect": "Allow", "Action": "s3:*", "Resource": "*"}
{"Effect": "Deny",  "Action": "s3:DeleteObject", "Resource": "*"}

Yêu cầu: s3:DeleteObject cho kết quả: Bị từ chối.

Deny tường minh luôn thắng mọi allow, dù allow đó rộng đến đâu

Một câu lệnh allow và một câu lệnh deny cùng đổ vào một yêu cầu, với nhánh deny được tô đậm và kết quả là bị từ chối.

Thứ tự đánh giá và deny ngầm

Lưu đồ đánh giá policy IAM: một yêu cầu API kiểm tra deny tường minh áp dụng, rồi allow áp dụng, và rơi vào deny ngầm khi không có cái nào.

Deny tường minh: có câu lệnh nói không
Allow: có câu lệnh nói có, và không câu lệnh nào nói không
Deny ngầm: không có câu lệnh nào nói gì cả

Bốn yêu cầu, ba kết quả

{"Effect": "Allow", "Action": "s3:*",
 "Resource": "*"}

{"Effect": "Deny", "Action": "s3:DeleteObject",
 "Resource": "*"}

s3:GetObject → allow: allow rộng bao phủ
s3:DeleteObject → deny tường minh: có câu lệnh nói không
kms:Decrypt, dynamodb:GetItem → deny ngầm: policy này không nhắc tới các dịch vụ đó
KMS giữ khóa mã hóa; DynamoDB là cơ sở dữ liệu key-value quản lý

Vì sao thêm quyền thường không hiệu quả

Cùng lỗi, hai nguyên nhân

Deny tường minh

Thêm allow khác cũng không đổi
Tìm deny đó, rồi thu hẹp hoặc gỡ bỏ

Deny ngầm

Chỉ cần một allow hẹp
Gắn trên danh tính đã gọi

Lỗi AccessDenied phân nhánh thành hai nguyên nhân. Bên trái, tìm thấy deny nên thêm allow cũng vô ích. Bên phải, không có allow nên chỉ cần thêm một allow hẹp trên danh tính gọi là giải quyết.

Cùng luyện tập nào!

Sử dụng AWS Security dành cho Developer