單一帳戶中請求的政策評估 - AWS Identity and Access Management

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

單一帳戶中請求的政策評估

如何 AWS 評估政策取決於適用於請求內容的政策類型。下面以頻率順序列出的政策類型,可以提供單一 AWS 帳戶使用。如需有關這些政策類型的詳細資訊,請參閱 中的政策和許可 AWS Identity and Access Management。若要了解 AWS 如何評估跨帳戶存取的政策,請參閱跨帳戶政策評估邏輯

  • 身分型政策 – 身分型政策會連接至IAM身分 (使用者、使用者群組或角色),並將許可授予IAM實體 (使用者和角色)。如果只有身分型政策適用於 請求,則 AWS 會檢查所有這些政策中至少有一個 Allow

  • 資源型政策 – 資源型政策會授予政策中指定的主體許可。這些許可會定義主體可以對政策連接於其中的資源做哪些動作。

  • IAM 許可界限 – 許可界限是一項功能,可設定身分型政策可授予IAM實體 (使用者或角色) 的最大許可。當您為實體設定許可界限時,該實體只能執行其身分型政策及其許可界限允許的動作。在某些情況下,許可界限中的隱含拒絕會限制資源型政策所授予的許可。如需進一步了解,請參閱 強制執行程式碼邏輯如何 AWS 評估允許或拒絕存取的請求

  • AWS Organizations 服務控制政策 (SCPs) – 組織會為組織或組織單位 (OU) 中帳戶內的主體SCPs指定最大可用許可。SCPs 適用於成員帳戶中的主體,包括每個 AWS 帳戶根使用者。如果SCP存在 ,則身分型和資源型政策授予您成員帳戶中主體的許可只有在 SCP允許該動作時才有效。唯一的例外是組織管理帳戶和服務連結角色中的主體。

  • AWS Organizations 資源控制政策 (RCPs) – 組織會RCPs指定組織或組織單位 (OU) 中帳戶內資源的可用許可上限。RCPs 適用於成員帳戶中的資源,並影響主體的有效許可,包括 AWS 帳戶根使用者,無論主體是否屬於您的組織。RCPs 不適用於組織管理帳戶中的資源,以及服務連結角色進行的呼叫。

  • 工作階段政策 – 當您以程式設計方式為角色或聯合使用者建立臨時工作階段時,工作階段政策是作為參數傳遞的政策。若要以程式設計方式建立角色工作階段,請使用其中一個AssumeRole*API操作。當您執行此操作並傳遞工作階段政策時,產生的工作階段許可是IAM實體身分型政策和工作階段政策的交集。若要建立聯合使用者工作階段,您可以使用IAM使用者存取金鑰以程式設計方式呼叫 GetFederationTokenAPI操作。如需詳細資訊,請參閱工作階段政策

請記住,所有這類政策中的明確拒絕都會覆寫該允許。

搭配以資源為基礎的政策來評估以身分為基礎的政策

以身分為基礎的政策和以資源為基礎的政策,可為其連接到其中的身分或資源授予許可。當IAM實體 (使用者或角色) 請求存取相同帳戶中的資源時, 會 AWS 評估身分型和資源型政策授予的所有許可。產生的許可是兩種類型許可的聯合。如果身分型政策、資源型政策或兩者都允許動作,則 AWS 允許該動作。在這些政策的明確拒絕會覆寫允許。

搭配以資源為基礎的政策來評估以身分為基礎的政策

搭配許可界限來評估以身分為基礎的政策

當 AWS 評估使用者的身分型政策和許可界限時,產生的許可是兩個類別的交集。這表示,當您新增許可界限到已有現有以身分為基礎之政策的使用者時,您可能會減少使用者可執行的動作。或者,當您移除使用者的許可界限時,您可能會增加他們可以執行的動作。在這些政策的明確拒絕會覆寫允許。若要檢視有關如何搭配許可界限來評估其他政策類型的詳細資訊,請參閱評估含界限的有效許可

評估以身分為基礎的政策及許可界限

使用 Organizations SCPs或 評估身分型政策 RCPs

當使用者屬於屬於組織成員的帳戶,並存取未設定資源型政策的資源時,產生的許可是使用者政策、服務控制政策 (SCPs) 和資源控制政策 () 的交集RCP。這表示所有三種政策類型都必須允許 動作。身分型政策中的明確拒絕SCP、 或 會RCP覆寫允許。

身分型政策和 SCPs 或 的評估 RCPs

您可以了解您的帳戶是否為 AWS Organizations中組織的成員。組織成員可能會受到 SCP或 的影響RCP。若要使用 AWS CLI 命令或 AWS API操作檢視此資料,您必須具有 Organizations 實體organizations:DescribeOrganization動作的許可。您必須擁有其他許可,才能在 Organizations 主控台中執行操作。若要了解 SCP或 RCP 是否拒絕存取特定請求,或變更您的有效許可,請聯絡您的 AWS Organizations 管理員。

以身分為基礎和以資源為基礎的政策的範例

最常見的政策類型是以身分為基礎的政策和以資源為基礎的政策。請求存取資源時, 會 AWS 評估相同帳戶中至少一個允許之政策授予的所有許可。所有政策中的明確拒絕都會覆寫該允許。

重要

如果在相同帳戶中,身分型政策和資源型政策中的任意一項政策允許請求而另一項不允許,則請求仍將被允許。

假設 Carlos 有使用者名稱 carlossalazar,他嘗試儲存檔案到 amzn-s3-demo-bucket-carlossalazar-logs Amazon S3 儲存貯體。

也假設下列政策已連接至carlossalazarIAM使用者。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowS3ListRead", "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetAccountPublicAccessBlock", "s3:ListAccessPoints", "s3:ListAllMyBuckets" ], "Resource": "arn:aws:s3:::*" }, { "Sid": "AllowS3Self", "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar/*", "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar" ] }, { "Sid": "DenyS3Logs", "Effect": "Deny", "Action": "s3:*", "Resource": "arn:aws:s3:::*log*" } ] }

此政策中的 AllowS3ListRead 陳述式允許 Carlos 檢視帳戶中的所有儲存貯體的清單。AllowS3Self 陳述式允許 Carlos 完整存取名稱和他的使用者名稱完全相同的儲存貯體。DenyS3Logs 陳述式拒絕 Carlos 存取名稱中包含 log 的任何 S3 儲存貯體。

此外,以下以資源為基礎的政策 (稱為儲存貯體政策) 已連接到 amzn-s3-demo-bucket-carlossalazar 儲存貯體。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/carlossalazar" }, "Action": "s3:*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar/*", "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar" ] } ] }

此政策指定只有 carlossalazar 使用者可以存取 amzn-s3-demo-bucket-carlossalazar 儲存貯體。

當 Carlos 提出將檔案儲存到儲存amzn-s3-demo-bucket-carlossalazar-logs貯體的請求時, AWS 決定哪些政策適用於請求。在這種情況下,只有以身分為基礎的政策和以資源為基礎的政策適用。這兩者都是許可政策。由於未套用許可界限,評估邏輯會降低到以下邏輯。

評估流程圖

AWS 首先檢查適用於請求內容的Deny陳述式。它找到一個,因為以身分為基礎的政策明確拒絕 Carlos 存取任何用於記錄的 S3 儲存貯體。Carlos 存取遭拒。

假設他接著發現自己的錯誤,並嘗試將檔案儲存到儲存amzn-s3-demo-bucket-carlossalazar貯體。 AWS 檢查是否有Deny陳述式,但找不到陳述式。接著檢查許可政策。身分類型政策和資源類型政策都允許請求。因此, 會 AWS 允許請求。如果其中一個元素明確拒絕陳述式、請求會被拒絕。如果其中一種政策類型允許請求,但另一種則不允許,則仍會允許請求。