Directrices de evaluación de políticas
AWS evaluará las políticas enviadas en función de un conjunto de directrices. Las mismas directrices de evaluación se aplican tanto a las plantillas de políticas como a los límites de permisos, con pequeñas diferencias cuando procede.
A efectos de la evaluación, separamos los servicios en grupos distintos. La distinción más importante es para los servicios sensibles a la seguridad, que administran el acceso, las credenciales y las claves. Las políticas que otorgan acceso a estos servicios deben centrarse estrictamente en el trabajo que se está llevando a cabo. Entre los servicios sensibles a la seguridad se incluyen los siguientes: AWS Identity and Access Management (IAM), AWS Key Management Service (KMS), AWS Resource Access Manager (RAM), AWS IAM Identity Center, AWS Organizations y AWS Secrets Manager.
Una distinción secundaria son los servicios que pueden acceder a los datos más allá de los límites de las cuentas. Las políticas de estos servicios deben incluir protecciones para evitar el acceso entre cuentas no intencionado.
Validaciones comunes
Todas las instrucciones de políticas deben seguir estas directrices:
Todas las instrucciones deben incluir los campos Effect, Action (o NotAction), Resource y Condition en ese orden.
Todas las acciones de una sola instrucción deben estar ordenadas alfabéticamente.
Todos los ARN incluidos en la política deben seguir la sintaxis definida en la documentación pública para los servicios pertinentes.
Los campos NotAction solo se pueden usar en las instrucciones Deny.
Las acciones de las instrucciones Allow deben incluir un código de servicio. No se permiten caracteres comodín genéricos (“*”).
Restricciones de los servicios sensibles a la seguridad
Las siguientes restricciones se aplican a los servicios sensibles a la seguridad mencionados anteriormente:
Las acciones de las instrucciones Allow deben ser más específicas que las de [service]:*.
Las acciones de las instrucciones Allow para las plantillas de políticas de acceso temporal no deben contener caracteres comodín.
Las acciones sensibles, como iam:PassRole o iam:CreateServiceLinkedRole, requieren un ámbito adicional, como recursos específicos o comprobaciones condicionales. Estas acciones son:
Transferencia de roles de IAM
Acciones de modificación de roles de IAM
Acciones de modificación de políticas de IAM
Operaciones criptográficas o de escritura de AWS KMS
Operaciones de uso compartido o escritura de AWS RAM
Operaciones de AWS Secrets Manager para recuperar o modificar secretos o modificar políticas de recursos
Otras acciones pueden utilizar un recurso comodín, como iam:ListUsers o iam:GetPolicy.
Las acciones que administran credenciales, como iam:CreateAccessKey, están bloqueadas.
Restricciones específicas de IAM
En el caso de IAM:
Solo se permiten operaciones de escritura limitadas para los roles y las políticas de IAM. No puede solicitar permisos en otros recursos de IAM, como usuarios, grupos y certificados.
Las acciones de asociación de políticas o de administración de políticas insertadas se limitan a los roles con un límite de permisos. Los límites de permisos deben proporcionarlos los socios o figurar en una lista de políticas administradas de AWS permitidas. Las políticas administradas de AWS pueden permitirse si no conceden permisos administrativos o con privilegios elevados. Por ejemplo, las políticas administradas de AWS para funciones de trabajo específicas o la política SecurityAudit pueden ser aceptables. AWS revisará cada política administrada de AWS caso por caso durante el proceso de incorporación.
La administración de políticas solo está permitida para las políticas con una ruta específica del socio: arn:aws:iam::@{AccountId}:policy/partner_domain.com/[feature]*.
Las etiquetas solo se pueden aplicar durante la creación de los recursos y solo para los roles y las políticas.
Las comprobaciones de iam:PassRole deben coincidir con un nombre o un prefijo de ruta específicos.
Restricciones específicas de AWS STS
Para AWS STS:
sts:AssumeRole debe estar limitado al ARN de un rol específico, el prefijo de ARN de un rol, o estar limitado a un conjunto de cuentas o ID de organización/unidad organizativa.
Restricciones de IAM Identity Center
En el caso de AWS IAM Identity Center, se bloquean las siguientes acciones:
Todas las acciones relacionadas con la administración de permisos (por ejemplo, sso:AttachCustomerManagedPolicyReferenceToPermissionSet).
Modificaciones de usuarios, grupos y membresías para el Almacén de identidades de AWS.
Administración de etiquetas.
Restricciones de AWS Organizations
En el caso de AWS Organizations, solo se permitirán acciones de lectura.
Validaciones adicionales específicas de los servicios
Las acciones que adquieren secretos o credenciales, como glue:GetConnection o redshift:GetClusterCredentials, deben tener condiciones que coincidan con los ARN completos, los prefijos de ARN o las etiquetas.
En el caso de Amazon Redshift: redshift:GetClusterCredentials solo se permite en el nombre de una base de datos específica y redshift:GetClusterCredentialsWithIAM solo se permite en el nombre de un grupo de trabajo específico.
nota
Al administrar los recursos de IAM de la cuenta, se recomienda utilizar una ruta que indique su nombre, por ejemplo: arn:aws:iam::111122223333:role/partner.com/rolename. Esto ayudará a diferenciar los recursos asociados a su integración y facilitará a los clientes la detección, la auditoría y el análisis.
Requisitos de acceso entre cuentas
Las instrucciones que puedan permitir el acceso entre cuentas deben incluir al menos uno de los siguientes elementos:
Una condición que especifique la cuenta o la organización del recurso (por ejemplo, que aws:ResourceOrgId coincida con uno o más valores esperados).
Un campo Resource que incluya una cuenta específica (por ejemplo, arn:aws:sqs:*:111122223333:*).
Un campo Resource que incluya una cuenta no comodín y el nombre completo de un recurso (por ejemplo, arn:aws:s3:::full-bucket-name).
nota
El acceso entre cuentas es una funcionalidad sensible que requiere una justificación empresarial clara. AWS estudiará detenidamente la necesidad del acceso entre cuentas durante el proceso de incorporación.
