AWS Identity and Access Management
Guía del usuario

Políticas y permisos

Puede administrar el acceso en AWS creando políticas y asignándoselas a identidades de IAM (usuarios, grupos de usuarios o roles) o a recursos de AWS. Una política es un objeto de AWS que, cuando se asocia a una identidad o un recurso, define sus permisos. AWS evalúa estas políticas cuando una entidad principal (usuario o rol) realiza una solicitud. Los permisos en las políticas determinan si la solicitud se permite o se deniega. La mayoría de políticas se almacenan en AWS como documentos JSON. AWS admite seis tipos de políticas: basadas en identidad, basadas en recursos, límites de permisos, SCP de Organizaciones, ACL y políticas de sesión.

Las políticas de IAM definen permisos para una acción independientemente del método que se utilice para realizar la operación. Por ejemplo, si una política permite la acción GetUser, un usuario con dicha política puede obtener información de los usuarios desde la Consola de administración de AWS, la AWS CLI o la API de AWS. Cuando se crea un usuario de IAM, se le puede permitir el acceso a la consola o el acceso mediante programación. Si se permite el acceso a la consola, el usuario de IAM pueden iniciar sesión en la consola con un nombre de usuario y una contraseña. Si se permite acceso mediante programación, el usuario puede utilizar claves de acceso para trabajar con la CLI o la API.

Tipos de políticas

Los tipos de políticas siguientes, que se muestran por orden de frecuencia, están disponibles para su uso en AWS. Para obtener más información, consulte las secciones siguientes para cada tipo de política.

  • Políticas basadas en identidad: las políticas administradas e insertadas se asocian a identidades de IAM (usuarios, grupos de usuarios o roles). Las políticas basadas en identidad, conceder permisos a una identidad.

  • Políticas basadas en recursos – Asocie políticas insertadas a los recursos. Los ejemplos más comunes de políticas basadas en recursos son las políticas de bucket de Amazon S3 y las políticas de confianza de roles de IAM. Las políticas basadas en recursos conceden permisos a una entidad principal que se especifica en la política. Las entidades principales pueden estar en la misma cuenta que el recurso o en cuentas distintas.

  • Límites de permisos: una política administrada se usa como límite de permisos para una entidad de IAM (usuario o rol). Esa política define los permisos máximos que las políticas basadas en identidad pueden conceder a una entidad, pero no concede permisos por sí misma. Los límites de permisos no definen los permisos máximos que una política basada en recursos puede conceder a una entidad.

  • SCP de organizaciones: con una política de control de servicios (SCP) de AWS Organizations puede definir los permisos máximos de los miembros de la cuenta de una organización o unidad organizativa (OU). Las SCP limitan los permisos que las políticas basadas en identidad o en recursos conceden a las entidades (usuarios o roles) dentro de la cuenta, pero no conceden permisos por sí mismas.

  • Listas de control de acceso (ACL): una ACL le permite controlar qué entidades principales de otras cuentas tienen acceso al recurso al que la ACL está asociada. Las ACL son similares a las políticas basadas en recursos, aunque son el único tipo de política que no utiliza la estructura de los documentos de política JSON. Las ACL son políticas de permisos para varias cuentas que conceden permisos a la entidad principal especificada. Las ACL no pueden conceder permisos a entidades dentro de una misma cuenta.

  • Políticas de sesión: puede especificar políticas de sesión avanzadas al usar la AWS CLI o la API de AWS para asumir un rol o un usuario federado. Las políticas de sesión limitan los permisos que las políticas basadas en identidad aplicadas al rol o al usuario conceden a la sesión. Las políticas de sesión limitan los permisos para una sesión creada, pero no conceden permisos por sí mismas. Para obtener más información, consulte Políticas de sesión.

Políticas basadas en la identidad

Las políticas basadas en identidad son documentos JSON de políticas de permisos que puede asociar a una identidad (usuario, grupo de usuarios o rol). Estas políticas determinan qué acciones puede realizar una entidad (usuario o rol), sobre qué recursos y en qué condiciones. Las políticas basadas en la identidad pueden clasificarse así:

  • Políticas administradas – Políticas independientes basadas en la identidad que puede conectar a varios usuarios, grupos y funciones en su cuenta de AWS. Puede utilizar dos tipos de políticas administradas:

    • Políticas administradas de AWS – Políticas administradas creadas y administradas por AWS. Si es la primera vez que utiliza políticas, le recomendamos que empiece a utilizar las políticas administradas por AWS.

    • Políticas administradas por el cliente – Políticas administradas que crea y administra en su cuenta de AWS. Las políticas administradas por el cliente ofrecen un control más preciso sobre las políticas que las políticas administradas por AWS. Puede crear y editar una política de IAM en el editor visual o mediante la creación del documento de política de JSON directamente. Para obtener más información, consulte Crear políticas de IAM y Edición de políticas de IAM.

  • Políticas insertadas – Políticas que crea y administra y que están integradas directamente en un único usuario, grupo o función. En la mayoría de los casos no es recomendable el uso de políticas insertadas.

Para obtener información sobre cómo decidir si utilizar una política administrada o una política insertada, consulte Políticas administradas y políticas insertadas.

Políticas basadas en recursos

Las políticas basadas en recursos son documentos de política JSON que puede asociar a un recurso como, por ejemplo, un bucket de Amazon S3. Estas políticas conceden a la entidad principal especificada permiso para ejecutar acciones concretas en el recurso y definen en qué condiciones son aplicables. Las políticas basadas en recursos son políticas insertadas. No existen políticas basadas en recursos que sean administradas.

Para hacer posible el acceso entre cuentas, puede especificar toda una cuenta o entidades de IAM de otra cuenta como entidad principal de la política basada en recursos. Añadir a una política basada en recursos una entidad principal entre cuentas es solo una parte del establecimiento de una relación de confianza. Cuando la entidad principal y el recurso se encuentran en cuentas de AWS distintas, también debe utilizar una política basada en identidad para conceder a la entidad principal acceso al recurso. Sin embargo, si la política basada en recursos concede el acceso a una entidad principal de la misma cuenta, no es necesaria una política basada en identidad adicional.

El servicio IAM solo admite un tipo de política basada en recursos, el llamado política de confianza de rol, que se asocia a un rol de IAM. Un rol de IAM es tanto una identidad como un recurso que admite políticas basadas en recursos. Por este motivo, debe asociar una política de confianza y una política basada en identidades al rol de IAM. Las políticas de confianza definen qué entidades principales (cuentas, usuarios, roles y usuarios federados) puede asumir el rol. Para obtener información sobre cómo difieren los roles de IAM con respecto a otras políticas basadas en recursos, consulte Cómo los roles de IAM difieren de las políticas basadas en recursos.

Para saber qué otros servicios admiten políticas basadas en recursos, consulte Servicios de AWS que funcionan con IAM. Para obtener más información sobre las políticas basadas en recursos, consulte Políticas basadas en identidad y políticas basadas en recursos.

Límites de permisos de IAM

Un límite de permisos es una característica avanzada que le permite definir los permisos máximos que una política basada en identidad puede conceder a una entidad de IAM. Al establecer un límite de permisos para una entidad, esta solo puede realizar las acciones que le permitan tanto sus políticas basadas en identidad como sus límites de permisos. Las políticas basadas en recursos que especifiquen el usuario o rol como entidad principal no estarán restringidas por el límite de permisos. Una denegación explícita en cualquiera de estas políticas anulará el permiso. Para obtener más información sobre los límites de permisos, consulte Límites de permisos para las entidades de IAM.

Políticas de control de servicios (SCP)

AWS Organizations es un servicio que le permite agrupar y administrar de forma centralizada las cuentas de AWS que posee su negocio. Si habilita todas las funciones en una organización, entonces podrá aplicar políticas de control de servicio (SCP) a una o todas sus cuentas. Las SCP son políticas JSON que especifican los permisos máximos para una organización o unidad organizativa (OU). Una SCP limita los permisos para las entidades de las cuentas de miembros, incluido cada Usuario de la cuenta raíz de AWS. Una denegación explícita en cualquiera de estas políticas anulará el permiso.

Para obtener más información acerca de Organizaciones y las SCP, consulte Funcionamiento de las SCP en la Guía del usuario de AWS Organizations.

Listas de control de acceso (ACL)

Las listas de control de acceso (ACL) son políticas de servicio que le permiten controlar qué entidades principales de otra cuenta pueden obtener acceso a un recurso. Las ACL no se pueden utilizar para controlar el acceso de una entidad principal de la misma cuenta. Las ACL son similares a las políticas basadas en recursos, aunque son el único tipo de política que no utiliza el formato de documento de política JSON. Amazon S3, AWS WAF y Amazon VPC son ejemplos de servicios compatibles con las ACL. Para obtener más información sobre las ACL, consulte Información general de las Access Control Lists (ACL, Listas de control de acceso) en la Guía para desarrolladores de Amazon Simple Storage Service.

Políticas de sesión

Las políticas de sesión son políticas avanzadas que se pasan como un parámetro cuando se crea una sesión temporal mediante programación para un rol o un usuario federado. Los permisos de una sesión son la intersección de las políticas basadas en identidades aplicadas a la entidad de IAM (usuario o rol) utilizada para crear la sesión y las políticas de sesión. Los permisos también pueden proceder de una política basada en recursos. Una denegación explícita en cualquiera de estas políticas anulará el permiso.

Puede crear una sesión de rol y pasar políticas de sesión mediante programación con las operaciones de API AssumeRole, AssumeRoleWithSAML o AssumeRoleWithWebIdentity. Puede transferir un único documento de política de sesión insertada JSON mediante el parámetro Policy. Puede utilizar el parámetro PolicyArns para especificar hasta 10 políticas de sesión administradas. Para obtener más información sobre cómo crear una sesión de un rol, consulte Solicitud de credenciales de seguridad temporales.

Al crear una sesión de un usuario federado, se usan las claves de acceso de un usuario de IAM para llamar mediante programación a la operación de API GetFederationToken. Asimismo, debe transferir las políticas de sesión. Los permisos de la sesión resultantes son la intersección de la política basada en identidades del usuario de IAM y la política de sesión. Para obtener más información sobre cómo crear una sesión de un usuario federado, consulte GetFederationToken — Federación a través de un agente de identidades personalizadas.

Una política basada en recursos puede especificar el ARN del usuario o el rol como una entidad principal. En ese caso, los permisos de la política basada en recursos se añaden a la política basada en identidades del usuario o rol antes de crear la sesión. La política de sesión limita los permisos totales concedidos por la política basada en recursos y la política basada en identidad. Los permisos de la sesión resultantes son la intersección de las políticas de sesión y la política basada en recursos o la política basada en identidades.


          Evaluación de la política de sesión con una política basada en recursos que especifica el ARN de la entidad

Una política basada en recursos puede especificar el ARN de la sesión como una entidad principal. En ese caso, los permisos de la política basada en recursos se añaden después de crear la sesión. Los permisos de la política basada en recursos no están limitados por la política de sesión. La sesión resultante tiene todos los permisos de la política basada en recursos más la intersección de la política basada en identidades y la política de sesión.


          Evaluación de la política de sesión con una política basada en recursos que especifica el ARN de la sesión

Un límite de permisos puede establecer el número de permisos máximo de un usuario o un rol que se utiliza para crear una sesión. En ese caso, los permisos de la sesión resultantes son la intersección de la política de sesión, el límite de permisos y la política basada en identidades. Sin embargo, un límite de permisos no restringe los permisos concedidos por una política basada en recursos que especifica el ARN de la sesión resultante.


          Evaluación de la política de sesión con un límite de permisos

Las políticas y el usuario raíz

A la Usuario de la cuenta raíz de AWS le afectan algunos tipos de políticas, pero no todos. No se pueden asociar políticas basadas en identidad al usuario raíz, así como tampoco establecer el límite de permisos para el usuario raíz. Sin embargo, es posible especificar el usuario raíz como la entidad principal en un política basada en identidad o una ACL. Como miembro de una cuenta, el usuario raíz se ve afectado por las SCP definidas para la cuenta.

Información general de políticas de JSON

Las mayoría de las políticas se almacenan en AWS como documentos JSON. Las políticas basadas en identidad y las políticas que se utilizan para establecer límites de permisos son documentos de política JSON que se asocian a un usuario o un rol. Las políticas basadas en recursos son documentos de política JSON que se asocian a un recurso. Las SCP son documentos de política JSON con sintaxis restringida que se asocian a una unidad organizativa de (OU) de AWS Organizations. Las ACL también se asocian a un recurso, pero se debe utilizar una sintaxis diferente. Las políticas de sesión son políticas JSON que se proporcionan al asumir una sesión de rol o usuario federado.

No es necesario que comprenda la sintaxis JSON. Puede utilizar el editor visual en la Consola de administración de AWS para crear y editar políticas administradas por el cliente sin utilizar JSON. No obstante, si decide utilizar las políticas insertadas para grupos o las políticas complejas, seguirá siendo necesario crear y editar esas políticas en el editor de JSON mediante la consola. Para obtener información sobre cómo usar el editor visual, consulte Crear políticas de IAM y Edición de políticas de IAM.

Estructura de los documentos de política JSON

Tal y como se muestra en la siguiente figura, un documento de política JSON incluye estos elementos:

  • Información opcional aplicable a toda la política en la parte superior del documento

  • Una o varias instrucciones individuales

Cada instrucción incluye información sobre un único permiso. Si una política incluye varias instrucciones, AWS aplica un OR lógico a todas las instrucciones al evaluarlas. Si varias políticas son aplicables a una solicitud, AWS aplica un OR lógico a todas esas políticas al evaluarlas.


          Estructura de los documentos de política JSON

La información de una instrucción se incluye en una serie de elementos.

  • Version: especifica la versión del idioma de la política que desea utilizar. Como práctica recomendada, utilice la versión 2012-10-17 más reciente.

  • Statement: utilice este elemento de política principal como contenedor de los siguientes elementos. Puede incluir varias instrucciones en una política.

  • Sid (opcional): incluye un ID de instrucción opcional para diferenciar entre las instrucciones.

  • Effect: utilice Allow o Deny para indicar si la política permite o deniega el acceso.

  • Principal (obligatorio solo en algunas circunstancias): si crea una política basada en recursos, debe indicar la cuenta, el usuario de, el rol o el usuario federado al que desea permitir o denegar el acceso. Si va a crear una política de permisos de IAM para asociarla a un usuario o un rol, no puede incluir este elemento. La entidad principal está implícita como ese usuario o rol.

  • Action: incluye una lista de acciones que la política permite o deniega.

  • Resource (obligatorio solo en algunas circunstancias): si crea una política de permisos de IAM, debe especificar una lista de recursos a los que se aplican las acciones. Si crea una política basada en recursos, este elemento es opcional. Si no incluye este elemento, el recurso al que se aplica la acción es el recurso al que está asociada la política.

  • Condition (opcional): especifica las circunstancias bajo las cuales la política concede permisos.

Para obtener más información sobre estos y otros elementos más avanzados de las políticas, consulte Referencia de los elementos de las políticas de JSON de IAM.

Varias instrucciones y varias políticas

Si desea definir varios permisos para una entidad principal (un usuario, un grupo o un rol), puede utilizar varias instrucciones en una única política. También puede asociar varias políticas. Si intenta definir varios permisos en una única instrucción, es posible que la política no conceda el acceso previsto. Como práctica recomendada, divida las políticas por tipo de recurso.

Debido al tamaño limitado de las políticas, podría ser necesario utilizar varias políticas para permisos más complejos. También es buena idea crear agrupaciones funcionales de permisos en una política independiente administrada por el cliente. Por ejemplo, crear una política para la administración de usuarios de IAM, una para la autoadministración y otra para la administración de buckets de S3. Independientemente de la combinación de varias instrucciones y varias políticas, AWS evalúa las políticas de la misma manera.

Por ejemplo, la siguiente política tiene tres instrucciones, cada una de las cuales define un conjunto de permisos independiente dentro de una única cuenta. Las instrucciones definen lo siguiente:

  • La primera instrucción, con un Sid (ID de instrucción) FirstStatement, permite al usuario que tiene la política asociada cambiar su propia contraseña. El elemento Resource de esta instrucción es "*" (lo que significa "todos los recursos"). Sin embargo, en la práctica, la operación de la API ChangePassword (o el comando de la CLI equivalente change-password) solo afecta a la contraseña del usuario que realiza la solicitud.

  • La segunda instrucción permite al usuario obtener una lista de todos los buckets de Amazon S3 en su cuenta de AWS. El elemento Resource de esta instrucción es "*" (lo que significa "todos los recursos"). Pero debido a que las políticas no conceden acceso a los recursos de otras cuentas, el usuario puede obtener únicamente la lista de los buckets de su propia cuenta de AWS.

  • La tercera instrucción permite al usuario enumerar y recuperar cualquier objeto que se encuentre en un bucket denominado confidential-data, pero solo cuando el usuario se autentica con la autenticación multifactor (MFA). El elemento Condition de la política aplica la autenticación MFA.

    Si la instrucción de una política incluye un elemento Condition, la instrucción solo entra en vigor cuando el elemento Condition se evalúa como true. En este caso, la Condition se evalúa como true cuando el usuario se autentica mediante MFA. Si el usuario no se autentica mediante MFA, esta Condition se evalúa como false. En ese caso, la tercera instrucción de esta política no se aplica y el usuario no tendrá acceso al bucket confidential-data.

{ "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:::confidential-data", "arn:aws:s3:::confidential-data/*" ], "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}} } ] }

Ejemplos de sintaxis de las políticas JSON

La política basada en identidad siguiente permite a la entidad principal enumerar un único bucket de Amazon S3 denominado example_bucket:

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::example_bucket" } }

La política basada en recursos siguiente se puede asociar a un bucket de Amazon S3. La política permite a los miembros de una cuenta de AWS específica realizar cualquier acción de Amazon S3 en el bucket denominado mybucket. Permite realizar cualquier acción que pueda llevarse a cabo en un bucket o en los objetos que contiene. (dado que la política concede confianza únicamente a la cuenta, se debe seguir concediendo permisos a los usuarios individuales de la cuenta para realizar las acciones especificadas de Amazon S3).

{ "Version": "2012-10-17", "Id": "S3-Account-Permissions", "Statement": [{ "Sid": "1", "Effect": "Allow", "Principal": {"AWS": ["arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:root"]}, "Action": "s3:*", "Resource": [ "arn:aws:s3:::mybucket", "arn:aws:s3:::mybucket/*" ] }] }

Para ver políticas de ejemplo que contemplan situaciones comunes, consulte Ejemplos de políticas basadas en identidad de IAM.