本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 中的政策和許可 AWS Identity and Access Management
AWS 透過建立政策並將其連接至 IAM 身分 （使用者、使用者群組或角色） 或 AWS 資源，在 中管理存取權。政策是 中的物件，當與身分或資源相關聯時， AWS 會定義其許可。當 IAM 主體 （使用者或角色） 發出請求時， 會 AWS 評估這些政策。政策中的許可決定是否允許或拒絕請求。大多數政策會以 JSON 文件 AWS 的形式存放在 中。 AWS 支援七種類型的政策：以身分為基礎的政策、以資源為基礎的政策、許可界限、 AWS Organizations 服務控制政策 (SCPs)、 AWS Organizations 資源控制政策 (RCPs)、存取控制清單 ACLs) 和工作階段政策。
IAM 政策定義該動作的許可，無論您使用何種方法來執行操作。例如，如果政策允許 [GetUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUser.html) 動作，則具有該政策的使用者可以從 AWS 管理主控台、 AWS CLI或 AWS API 取得使用者資訊。當您建立 IAM 使用者時，您可以選擇允許其主控台存取或程式化存取。如果允許主控台存取，則 IAM 使用者可以利用登入認證登入主控台。若在允許程式化存取情況下，使用者可以使用存取金鑰來操作 CLI 或 API。
## 政策類型
以下政策類型會以最常使用到較不常使用的順序列出，可以在 AWS中使用。如需更多詳細資訊，請參閱以下各節中的每個政策類型。
+ **[身分型政策](#policies_id-based)** – 將[受管](#managedpolicy)和[內嵌](#inline)政策連接到 IAM 身分 (使用者、使用者所屬的群組或角色)。身分型政策可為身分授予許可。
+ **[資源型政策](#policies_resource-based)** – 將內嵌政策連接到資源。資源型政策的最常見範例是 Amazon S3 儲存貯體政策和 IAM 角色信任政策。資源型政策會將許可授予政策中所指定的主體。主體可以位在與資源相同的帳戶，或位在其他的帳戶中。
+ **[許可界限](#policies_bound)** – 使用受管政策作為 IAM 實體 (使用者或角色) 的許可界限。該政策會定義身分型政策可為實體授予的最大許可，但並不會授予許可。許可界限不會定義資源型政策可以授予實體的許可上限。
+ **[AWS Organizations SCPs](#policies_scp)** – 使用 AWS Organizations 服務控制政策 (SCP) 來定義組織或組織單位 (OU) 中帳戶內 IAM 使用者和 IAM 角色的最大許可。SCP 會限制身分型政策或資源型政策為帳戶中的 IAM 使用者或 IAM 角色授予的許可。SCP 不會授予許可。
+ **[AWS Organizations RCPs](#policies_rcp)** – 使用 AWS Organizations 資源控制政策 (RCP) 來定義組織或組織單位 (OU) 中帳戶內資源的最大許可。RCP 會限制身分型和資源型政策可以授予組織內帳戶資源的許可。RCP 不會授予許可。
+ **[存取控制清單 (ACL)](#policies_acl)** – 使用 ACL，可以控制其他帳戶中的哪些主體可以存取其中已連接 ACL 的資源。ACL 類似資源型政策，雖然是不使用 JSON 政策文件結構的唯一政策類型。ACL 是跨帳戶許可的政策，負責為指定的主體授予許可。ACL 不可以為相同帳戶中的實體授予許可。
+ **[工作階段政策](#policies_session)** – 當您使用 AWS CLI 或 AWS API 擔任角色或聯合身分使用者時，傳遞進階工作階段政策。工作階段政策限制以角色或使用者身分型政策授予給該工作階段的許可。工作階段政策會限制已建工作階段的許可，但不會限制授予許可。如需詳細資訊，請參閱[工作階段政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)。
### 身分型政策
身分型政策是 JSON 許可政策文件，可控制身分 (使用者、使用者群組和角色) 會在何種條件下對哪些資源執行哪些動作。身分型政策可進一步分類：
+ **受管政策**：您可以連接到 中多個使用者、群組和角色的獨立身分型政策 AWS 帳戶。受管政策有兩種：
+ **AWS 受管政策** – 由 建立和管理的受管政策 AWS。
+ **客戶管理政策**：您在 AWS 帳戶中建立和管理的受管政策。客戶受管政策提供比 AWS 受管政策更精確的政策控制。
+ **內嵌政策** – 您直接新增至單一使用者、群組或角色的政策。內嵌政策可在政策與身分之間維持嚴格的一對一關聯性。當您刪除身分時，它們即會被刪除。
若要了解如何選擇受管政策和內嵌政策的相關資訊，請參閱 [在受管政策與內嵌政策之間選擇](access_policies-choosing-managed-or-inline.md)。
### 資源型政策
資源型政策是連接到資源 (如 Amazon S3 儲存貯體) 的 JSON 政策文件。這些政策會授予指定的主體許可，允許在該資源上執行特定的動作，並且定義資源所適用的條件。資源型政策是內嵌政策。不存在受管的資源型政策。
若要啟用跨帳戶存取，您可以指定在其他帳戶內的所有帳戶或 IAM 實體，作為資源型政策的主體。新增跨帳戶主體至資源型政策，只是建立信任關係的一半。當委託人和資源是分開的 AWS 帳戶，您還必須使用以身分為基礎的政策來授予委託人對資源的存取權。不過，如果資源型政策會為相同帳戶中的主體授予存取，這時就不需要額外的身分型政策。如需授予跨服務存取權限的逐步指示，請參閱 [IAM 教學課程：使用 IAM 角色在 AWS 帳戶之間委派存取權](tutorial_cross-account-with-roles.md)。
IAM 服務支援一種稱為角色*信任政策*，且已連接到 IAM 角色的資源型政策。IAM 角色既是一種身分，也是一項資源，可支援資源型政策。因此，您必須同時將信任政策和身分型政策連接到 IAM 角色。信任政策會定義哪些主體實體 (帳戶、使用者、角色和聯合身分使用者) 可擔任該角色。若要了解 IAM 角色與其他以資源為基礎之政策之間的差別，請參閱 [IAM 中的跨帳戶資源存取](access_policies-cross-account-resource-access.md)。
若要查看哪些其他服務可以支援資源型政策，請參閱[AWS 使用 IAM 的 服務](reference_aws-services-that-work-with-iam.md)。若要進一步了解資源型政策的詳細資訊，請參閱 [以身分為基礎和以資源為基礎的政策](access_policies_identity-vs-resource.md)。若要了解在您信任區域 (受信任組織或帳戶) 外帳戶中的主體是否具有擔任您角色的許可，請參閱[什麼是 IAM Access Analyzer？](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
### IAM 許可界限
許可界限是一種進階功能，可供您設定身分型政策可以授予 IAM 實體的最大許可。當您為實體設定許可界限時，實體只能執行由身分型政策和其許可界限同時允許的動作。如果您在資源型政策的主體元素中指定了角色工作階段或使用者，則在許可界限中不需要明確允許。不過，如果您在資源型政策的主體元素中指定了角色 ARN，則在許可界限中需要明確允許。在這兩種情況下，許可界限中的明確拒絕都有效。任何這些政策中的明確拒絕都會覆寫允許。如需有關許可界限的詳細資訊，請參閱 [IAM 實體的許可界限](access_policies_boundaries.md)。
### AWS Organizations 服務控制政策 SCPs)
若您啟用組織中的所有功能，您可以將服務控制政策 (SCP) 套用到任何或所有帳戶。SCP 是 JSON 政策，負責指定組織或組織單位 (OU) 帳戶內的 IAM 使用者和 IAM 角色的最大許可。SCP 會限制成員帳戶中主體的許可，包括每個主體 AWS 帳戶根使用者。所有這類政策中的明確拒絕都會覆寫其他政策中的允許。
如需 AWS Organizations 和 SCPs的詳細資訊，請參閱*AWS Organizations 《 使用者指南*》中的[服務控制政策 (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)。
### AWS Organizations 資源控制政策 RCPs)
如果您啟用組織中的所有功能，則可以使用資源控制政策 (RCP) 集中套用存取控制到多個 AWS 帳戶的資源。RCP 是 JSON 政策，可用來設定您帳戶中資源的可用許可上限，採取這種方式就不需要更新附加至您所擁有的每個資源的 IAM 政策。RCP 會限制成員帳戶中資源的許可，並可能影響身分的有效許可，包括 AWS 帳戶根使用者，無論它們是否屬於您的組織。任何適用 RCP 中的明確拒絕都會覆寫其他政策中的允許，這些政策可能連接到個別身分或資源。
如需 AWS Organizations 和 RCPs的詳細資訊 AWS 服務 ，包括支援 RCPs的 清單，請參閱*AWS Organizations 《 使用者指南*》中的[資源控制政策 (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)。
### 存取控制清單 (ACL)
存取控制清單 (ACL) 是一種服務政策，可讓您控制另一個帳戶中的哪些主體可以存取資源。ACL 不能用於控制相同帳戶中主體的存取。ACL 類似資源型政策，雖然是不使用 JSON 政策文件格式的唯一政策類型。Amazon S3 AWS WAF和 Amazon VPC 是支援 ACLs的服務範例。如需進一步瞭解 ACL，請參閱《*Amazon Simple Storage Service 開發人員指南*》中的[存取控制清單 (ACL) 概觀](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html)。
### 工作階段政策
當您以程式設計方式為角色或 AWS STS 聯合身分使用者主體建立臨時工作階段時，工作階段政策是做為參數傳遞的進階政策。工作階段的許可是用來建立工作階段及工作階段政策 IAM 實體 (使用者或角色) 之身分型政策的交集。許可也可以來自資源型政策。所有這類政策中的明確拒絕都會覆寫該允許。
您可以建立角色工作階段，以及透過程式設計方式使用 `AssumeRole`、`AssumeRoleWithSAML` 或 `AssumeRoleWithWebIdentity` API 操作來傳遞工作階段政策。您可以使用 `Policy` 參數傳遞單一 JSON 內嵌工作階段政策文件。您可以使用 `PolicyArns` 參數，指定多達 10 個受管工作階段政策。如需有關建立角色工作階段的詳細資訊，請參閱 [臨時安全憑證的許可](id_credentials_temp_control-access.md)。
當您建立 AWS STS 聯合身分使用者主體工作階段時，您可以使用 IAM 使用者的存取金鑰以程式設計方式呼叫 `GetFederationToken` API 操作。您也必須通過工作階段政策。所產生工作階段的許可會是身分類型政策和工作階段政策的交集。如需有關建立聯合身分使用者工作階段的詳細資訊，請參閱 [透過自訂身分經紀人請求憑證](id_credentials_temp_request.md#api_getfederationtoken)。
資源型政策可以指定使用者或角色 ARN 作為主體。在該情況下，在工作階段建立之前，依據資源型政策的許可會新增到該角色或使用者的身分型政策。工作階段政策限制由資源型政策、身分型政策所授予的總許可數。產生的工作階段的許可是工作階段政策與資源型政策的交集，加上工作階段政策與身分型政策的交集。
![\[評估的工作階段政策與資源型政策使用指定實體 ARN\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/EffectivePermissions-session-rbp-id.png)
資源型政策可以指定工作階段 ARN 作為主體。在該情況下，會在建立工作階段後，從資源型政策新增許可。資源型政策許可不會受到工作階段政策的限制。產生的工作階段擁有資源型政策的所有許可，*加上*身分型政策與工作階段政策的交集。
![\[評估的工作階段政策與資源型政策使用指定工作階段 ARN\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/EffectivePermissions-session-rbpsession-id.png)
許可界限可以為使用者或角色設定建立工作階段的許可上限。在該情況下，產生的工作階段的許可是工作階段政策、許可界限與身分型政策的交集。不過，許可界限不會限制由資源型政策所授予的許可，指定產生工作階段的 ARN。
![\[搭配許可界限的工作階段政策評估\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/EffectivePermissions-session-boundary-id.png)
## 政策和根使用者
受某些政策類型影響，但不受其他政策類型 AWS 帳戶根使用者 影響。您無法將身分型政策連接到根使用者，而且您無法為根使用者設定許可界限。不過，您可以在資源型政策或 ACL 中將根使用者指定為主體。根使用者仍是帳戶的成員。如果該帳戶是 中組織的成員 AWS Organizations，根使用者會受到帳戶的 SCPs 和 RCPs影響。
## JSON 政策概觀
大多數政策會以 JSON 文件 AWS 形式存放在 中。身分型政策以及用於設定許可界限的政策，都是您連接到使用者或角色的 JSON 政策文件。資源型政策是連接到資源的 JSON 政策文件。SCPs和 RCPs是您連接至 AWS Organizations組織根目錄、組織單位 (OU) 或帳戶的受限語法的 JSON 政策文件。ACL 也會連接到資源，但您必須使用不同的語法。工作階段政策是您在擔任角色或聯合身分使用者工作階段時所需要提供的 JSON 政策。
您不需要了解 JSON 語法。您可以使用 中的視覺化編輯器 AWS 管理主控台 來建立和編輯客戶受管政策，而無需使用 JSON。不過，如果將內嵌政策用於群組或複雜政策，您仍然必須在 JSON 編輯器中利用主控台建立和編輯這些政策。如需有關使用視覺化編輯器的詳細資訊，請參閱 [使用客戶管理政策定義自訂 IAM 許可](access_policies_create.md) 和 [編輯 IAM 政策](access_policies_manage-edit.md)。
當您建立或編輯 JSON 政策時，IAM 可以執行政策驗證以協助您建立有效的政策。IAM 會識別 JSON 語法錯誤，而 IAM Access Analyzer 會提供額外的政策檢查及建議，協助您進一步改良政策。若要進一步了解政策驗證的資訊，請參閱 [IAM 政策驗證](access_policies_policy-validator.md)。若要進一步了解 IAM Access Analyzer 政策檢查和可動作的建議，請參閱 [IAM Access Analyzer 政策驗證](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)。
### JSON 政策文件結構
如下圖所示，JSON 政策文件包含這些元素：
+ 在文件最上方選用的整體政策資訊
+ 一或多個個別的陳述式**
每個陳述式包含關於單一許可的資訊。如果政策包含多個陳述式， 會在評估陳述式時`OR`跨陳述式 AWS 套用邏輯。如果多個政策適用於請求， 會在評估所有`OR`政策時 AWS 套用邏輯。
![\[JSON 政策文件結構\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/AccessPolicyLanguage_General_Policy_Structure.diagram.png)
陳述式中的資訊包含在一系列的元素內。
+ **Version** – 指定您要使用的政策語言版本。建議您使用最新的 `2012-10-17 ` 版本。如需詳細資訊，請參閱[IAM JSON 政策元素：Version](reference_policies_elements_version.md)
+ **Statement** – 使用此主要政策元素作為以下元素的容器。您可以在政策中包含多個陳述式。
+ **Sid** (選用) – 包含選用的陳述式 ID 來區分您的陳述式。
+ **Effect** – 使用 `Allow` 或 `Deny` 來表示政策是否允許或拒絕存取。
+ **Principal** （在某些情況下為必要） – 如果您建立以資源為基礎的政策，您必須指定您想要允許或拒絕存取的帳戶、使用者、角色或 AWS STS 聯合身分使用者主體。如果您要建立 IAM 許可政策來連接到使用者或角色，您不能包含此元素。主體意味著該使用者或角色。
+ **Action** – 包含政策允許或拒絕的動作清單。
+ **Resource** (在某些情況下需要) – 如果您建立 IAM 許可政策，則必須指示要套用動作的資源清單。如果您建立資源型政策，則取決於您用來判斷是否需要此元素的資源。
+ **Condition** (選用) – 指定政策授予許可的條件。
若要了解這些內容及其他更進階的政策元素，請參閱[IAM JSON 政策元素參考](reference_policies_elements.md)。
### 多項陳述式和多個政策
如果您想要定義一個以上的實體 (使用者或角色) 許可，您可以在單一政策使用多個陳述式。您也可以連接多個政策。如果您嘗試在單一陳述式定義多個許可，您的政策可能不會授予您預期的存取權。建議您透過資源類型將政策分類。
由於[政策的大小限制](reference_iam-quotas.md)，可能需要針對更複雜的許可採用多重政策。在不同的客戶管理政策中建立許可的功能群組，也是不錯的想法。例如，建立一個政策給 IAM 使用者管理、一個給自我管理，另一個給 S3 儲存貯體管理。無論多個陳述式和多個政策的組合為何， 都會以相同的方式 AWS [評估](reference_policies_evaluation-logic.md)您的政策。
例如，以下政策具有三個陳述式，每一個定義單一帳戶內不同組的許可。陳述式定義下列動作：
+ 第一種陳述式具有 `Sid` 的 `FirstStatement` (陳述式 ID)，可讓具有連接政策的使用者變更自己的密碼。此陳述式的 `Resource` 元素是 `*` (其表示「所有資源」)。但事實上 `ChangePassword`API 操作 (或同等 `change-password` CLI 命令) 只對提出請求的使用者的密碼有影響。
+ 第二個陳述式可讓使用者在其 AWS 帳戶列出所有的 Amazon S3 儲存貯體。此陳述式的 `Resource` 元素是 `"*"` (其表示「所有資源」)。但是，因為政策不授予其他帳戶的資源存取權，使用者只能列出自己的 AWS 帳戶中的儲存貯體。
+ 第三個陳述式可讓使用者列出並擷取儲存貯體中的任何物件，名為 `amzn-s3-demo-bucket-confidential-data`，但前提是使用者必須是以 多重要素驗證 (MFA) 驗證。政策中的 `Condition` 元素強制執行 MFA 身分驗證。
當政策陳述式包含 `Condition` 元素，陳述式僅於 `Condition` 元素評估為 true 是生效。在這種情況下，當使用者經過 MFA 身分驗證，`Condition` 評估為 true。如果使用者未經過 MFA 身分驗證，這項 `Condition` 評估設為 false。在這種情況下，此政策的第三個陳述式將不適用，而且使用者無法存取 `amzn-s3-demo-bucket-confidential-data` 儲存貯體。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "FirstStatement",
"Effect": "Allow",
"Action": ["iam:ChangePassword"],
"Resource": "*"
},
{
"Sid": "SecondStatement",
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Sid": "ThirdStatement",
"Effect": "Allow",
"Action": [
"s3:List*",
"s3:Get*"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket-confidential-data",
"arn:aws:s3:::amzn-s3-demo-bucket-confidential-data/*"
],
"Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
}
]
}
```
------
### JSON 政策語法的範例
以下身分型政策允許暗示的主體列出單一 Amazon S3 儲存貯體，其名稱是 `amzn-s3-demo-bucket`：
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
}
}
```
------
以下資源型政策可以連接到 Amazon S3 儲存貯體。此政策允許特定 的成員 AWS 帳戶 在名為 的儲存貯體中執行任何 Amazon S3 動作`amzn-s3-demo-bucket`。它允許可在儲存貯體或其中的物件上執行的任何動作。(由於政策僅對帳戶授予信任，帳戶中的個別使用者仍必須被授予特定 Amazon S3 動作的許可)。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:root"
]
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}
```
------
若要檢視常見案例的範例政策，請參閱[以身分為基礎的 IAM 政策範例](access_policies_examples.md)。
## 授予最低權限
當您建立 IAM 政策時，請遵循授予*最低權限*的標準安全建議，或者只授予執行任務所需的許可。決定使用者和角色需要執行哪些任務，然後為他們制定政策，讓使用者*只*執行這些任務。
從一組最低許可開始，並視需要授予其他許可。這比一開始使用太寬鬆的許可，稍後再嘗試將他們限縮更為安全。
作為最低權限的替代方案，您可以使用 [AWS 受管政策](access_policies_managed-vs-inline.md#aws-managed-policies)或具有萬用字元 `*` 許可的政策，以開始使用政策。若授與主體的許可超出執行任務所需的許可，需考量其相關的安全性風險。監控這些主體，以了解他們正在使用的許可。然後寫入最低權限政策。
IAM 提供數個選項，協助您精簡您授予的許可。
+ **了解存取層級群組** – 您可以使用存取層級的方法進行分組，以了解政策授予的存取層級。[政策動作](reference_policies_elements_action.md)分為 `List`、`Read`、`Write`、`Permissions management` 或 `Tagging`。例如，您可以從 `List` 和 `Read` 存取層級選擇動作以授予唯讀存取權給您的使用者。若要了解如何使用政策摘要，以理解存取層級許可，請參閱[政策摘要中的存取層級](access_policies_understand-policy-summary-access-level-summaries.md)。
+ **驗證您的政策** – 您可以在建立和編輯 JSON 政策時，使用 IAM Access Analyzer 執行政策驗證。我們建議您檢閱並驗證所有現有政策。IAM Access Analyzer 提供超過 100 項的政策檢查，以驗證您的政策。當您政策中的聲明允許我們認為過度寬鬆的存取權時，即會產生安全性警告。在授予最低權限時，您可以使用透過安全性警告提供的可操作建議。若要進一步了解有關 IAM Access Analyzer 所提供的政策檢查，請參閱 [IAM Access Analyzer 政策驗證](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)。
+ **根據存取活動產生政策** – 為了協助您精簡所授予的許可，您可以根據 IAM 實體 (使用者或角色) 的存取活動產生 IAM 政策。IAM Access Analyzer 會檢閱您的 AWS CloudTrail 日誌，並產生政策範本，其中包含實體在指定時間範圍內已使用的許可。您可以使用範本建立具有精細許可的受管政策，然後將其連接至 IAM 實體。如此一來，您只授予使用者或角色與特定使用案例 AWS 的資源互動所需的許可。若要進一步了解，請參閱 [IAM Access Analyzer 政策產生](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)。
+ **使用上次存取的資訊** – 另一個有助於實現最低權限的功能是*最近存取的資訊*。在 IAM 主控台詳細資訊頁面的 **Access Advisor** (存取 Advisor) 索引標籤上檢視 IAM 使用者、群組、角色或政策的此資料。上次存取的資訊也包括最近存取某些服務之動作的相關資訊，例如 Amazon EC2、IAM、Lambda 和 Amazon S3。如果您使用 AWS Organizations 管理帳戶登入資料登入，您可以在 IAM 主控台的 **AWS Organizations**區段中檢視服務上次存取的資訊。您也可以使用 AWS CLI 或 AWS API，擷取 IAM 或 中實體或政策上次存取資訊的報告 AWS Organizations。您可以使用此資訊來識別不必要的許可，以便精簡您的 IAM 或 AWS Organizations 政策，以更好地遵守最低權限原則。如需詳細資訊，請參閱[AWS 使用上次存取的資訊在 中精簡許可](access_policies_last-accessed.md)。
+ 在 **中檢閱帳戶事件 AWS CloudTrail** – 若要進一步減少許可，您可以在事件歷史記錄中 AWS CloudTrail 檢視帳戶的事件。 ****CloudTrail 事件日誌包含可供您用來縮減政策之許可的詳細事件資訊。此日誌只包含 IAM 實體所需的動作和資源。如需詳細資訊，請參閱《AWS CloudTrail 使用者指南》**中的[在 CloudTrail 主控台中檢視 CloudTrail 事件](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events-console.html)。
如需詳細資訊，請參閱下列適用於個別服務的政策主題，其中提供如何為服務特定的資源撰寫政策的範例。
+ 《Amazon DynamoDB 開發人員指南》**中的 [Using resource-based policies for DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/access-control-resource-based.html)
+ 《Amazon Simple Storage Service 使用者指南》**中的 [Bucket policies for Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html)
+ 《Amazon Simple Storage Service 使用者指南》**中的 [Access Control List (ACL) overview](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html)