IAM 原則評估與明確拒絕

AWS Security 開發者實務

Rahul Singh

Technical Product Manager

一個原則就是一串規則

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

單一 IAM 陳述的三個欄位沿一條主軸堆疊並標號 1 到 3：Effect 為允許或拒絕，Action 為哪個 API 呼叫，Resource 為指向的資源，由 ARN 命名。

AWS Security 開發者實務

一個原則就是一串規則

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

單一 IAM 陳述的四個欄位沿一條主軸堆疊並標號 1 到 4：Effect 為允許或拒絕，Action 為哪個 API 呼叫，Resource 為由 ARN 命名的目標資源，Condition 為必須符合的條件。結語：四個欄位，一條規則。

AWS Security 開發者實務

三欄發問，一欄作答

問題端

  • Action：是不是這個呼叫
  • Resource：是不是這個目標
  • Condition：條件是否符合

答案端

  • Effect：允許或拒絕

IAM 陳述的四個欄位垂直堆疊：Action、Resource 與 Condition 被一個大括號分組並標為「問題端」，Effect 被另一個括號分組並標為「答案端」。

AWS Security 開發者實務

規則不只來自一處

一份附加在角色上的原則文件，從角色畫出箭頭指向一個儲存貯體。

以身分為主（Identity-based）

  • 附加在角色上
  • 這個角色能做什麼
AWS Security 開發者實務

規則不只來自一處

一份附加在角色上的原則文件，從角色畫出箭頭指向一個儲存貯體。

一份附加在資源上的原則文件，從主體畫出箭頭指向一個儲存貯體。

以身分為主（Identity-based）

  • 附加在角色上
  • 這個角色能做什麼

以資源為主（Resource-based）

  • 附加在被存取的資源上
  • 誰可以存取這個儲存貯體
AWS Security 開發者實務

當規則互相牴觸時

{"Effect": "Allow", "Action": "s3:*", "Resource": "*"}
{"Effect": "Deny",  "Action": "s3:DeleteObject", "Resource": "*"}
AWS Security 開發者實務

當規則互相牴觸時

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

請求： s3:DeleteObject 的結果：Denied。

明確拒絕優先於任何允許，再廣也一樣

一條允許與一條拒絕的陳述同時導向一個請求，拒絕路徑加粗，結果標示為 denied。

AWS Security 開發者實務

評估順序與隱含拒絕

IAM 原則評估流程圖：API 請求先檢查是否有適用的明確拒絕，再檢查是否有適用的允許，若皆無則為隱含拒絕。

  • 明確拒絕： 有條規則明說不行
  • 允許： 有條規則說可以，且沒有規則說不行
  • 隱含拒絕： 沒有任何規則提到
AWS Security 開發者實務

四種請求，三種結果

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

{"Effect": "Deny", "Action": "s3:DeleteObject",
 "Resource": "*"}
  • s3:GetObject → 允許：廣泛的允許涵蓋它
  • s3:DeleteObject → 明確拒絕：有陳述說不行
  • kms:Decrypt、dynamodb:GetItem → 隱含拒絕：此原則未提到這些服務
  • KMS 管理加密金鑰；DynamoDB 是受管的鍵值資料庫
AWS Security 開發者實務

為什麼加權限常常沒效

同樣錯誤，兩種成因

明確拒絕

  • 再加允許也沒有用
  • 先找到拒絕，再縮小範圍或移除

隱含拒絕

  • 加上一條範圍精準的允許
  • 加在發出呼叫的身分上

AccessDenied 錯誤分支成兩個原因。左側找到拒絕，因此更多允許也無效。右側找不到允許，因此在呼叫身分上加上一條精準允許即可解決。

AWS Security 開發者實務

一起來練習吧！

AWS Security 開發者實務

Preparing Video For Download...