Políticas y permisos en IAM

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 de IAM (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 Organizations, 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 AWS Management Console, 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 puede iniciar sesión en la consola con sus credenciales de inicio de sesión. Si se permite el acceso programático, 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 desde los que se utilizan con más frecuencia hasta los que se utilizan con menos 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.

• Identity-based policies (Políticas basadas en identidad): asocie políticas administradas e insertadas a identidades de IAM (usuarios, grupos a los que pertenecen los 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 la 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 – Puede utilizar políticas administradas para definir el límite de permisos de 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 Organizations— Utilice una política de control de servicio (SCP) de AWS Organizations para definir los permisos máximos de para los miembros de cuentas 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) - Utilice ACL para controlar qué entidades principales de otras cuentas pueden tener 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 — Pase las políticas de sesión avanzadas cuando utilice el 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 identidad

Las políticas basadas en identidad son documentos de políticas de permisos JSON que controlan qué acciones puede realizar una identidad (usuarios, grupos de usuarios y roles), en 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 adjuntar a varios usuarios, grupos y funciones en su Cuenta de AWS. Existen dos tipos de políticas administradas:

  • Políticas administradas de AWS – Políticas administradas creadas y 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.

• Políticas insertadas: políticas que agrega directamente a un único usuario, grupo o rol. Las políticas insertadas mantienen una relación estricta de uno a uno entre una política y una identidad. Se eliminan cuando se elimina la identidad.

Para obtener información sobre cómo elegir entre una política administrada o una insertada, consulte Elegir entre 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 habilitar el acceso entre cuentas, puede especificar toda una cuenta o entidades de IAM de otra cuenta como la entidad principal de una 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 Cuentas de AWS distintas, también debe utilizar una política basada en identidades para conceder a la entidad principal el 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. Para obtener instrucciones paso a paso para conceder acceso entre servicios, consulte Tutorial de IAM: delegación del acceso entre cuentas de AWS mediante roles de IAM.

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 Acceso a recursos entre cuentas en IAM.

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. Consulte ¿Qué es IAM Access Analyzer? para saber si las entidades principales de las cuentas fuera de su zona de confianza (cuenta u organización de confianza) tienen acceso para asumir sus roles.

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 Cuentas de AWS que posee su negocio. Si habilita todas las características 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 raíz de la cuenta de AWS. Una denegación explícita en cualquiera de estas políticas anulará el permiso.

Para obtener más información acerca de Organizations 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 que admiten las ACL. Para obtener más información sobre las ACL, consulte Información general de Lista de control de acceso (ACL) 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 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 utilizando el parámetro Policy. Puede utilizar el parámetro PolicyArns para especificar hasta 10 políticas de sesión administrada. 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 del usuario de IAM para llamar de manera programática 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 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 las políticas basadas en recursos más la intersección de las políticas de sesión y las políticas basadas en identidades.

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.

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.

Las políticas y el usuario raíz

A la Usuario raíz de la cuenta 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 mismo. Sin embargo, es posible especificar el usuario raíz como la entidad principal en un política basada en identidad o una ACL. Un usuario raíz aún sigue siendo miembro de una cuenta. Si una cuenta es miembro de una organización en AWS Organizations, 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 adjuntan 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 AWS Management Console 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 utilizar el editor visual, consulte Crear políticas de IAM y Edición de políticas de IAM.

Cuando usted crea o edita una política JSON, IAM puede realizar la validación de políticas para ayudarle a crear una política eficaz. IAM identifica errores de sintaxis JSON, mientras que IAM Access Analyzer proporciona verificaciones de políticas adicionales con recomendaciones para ayudarle a perfeccionar aún más las políticas. Para obtener más información acerca la validación de políticas, consulte Validación de políticas de IAM. Para obtener más información acerca de las verificaciones de políticas de IAM Access Analyzer y las recomendaciones procesables, consulte Validación de políticas de IAM Access Analyzer.

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.

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. Le recomendamos que utilice la última versión de 2012-10-17. Para obtener más información, consultar Elementos de política JSON de IAM: Version

• 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 únicamente en algunas circunstancias): si crea una política basada en recursos, debe indicar la cuenta, el usuario, 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 (usuario o 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. Le recomendamos que separe 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 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 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 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",
  "Statement": [{
    "Sid": "1",
    "Effect": "Allow",
    "Principal": {"AWS": ["arn:aws:iam::account-id: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.

Conceder privilegios mínimos

Al crear políticas de IAM, siga los consejos de seguridad estándar de concesión de privilegios mínimos o garantizando solo los permisos necesarios para realizar una tarea. Determine las tareas que tienen que realizar los usuarios y roles, y luego elabore políticas que les permitan realizar solo esas tareas.

Comience con un conjunto mínimo de permisos y conceda permisos adicionales según sea necesario. Por lo general, es más seguro que comenzar con permisos que son demasiado tolerantes e intentar hacerlos más estrictos más adelante.

Como alternativa a los privilegios mínimos, puede utilizar las políticas administradas de AWS o las políticas con comodín de permisos de * para empezar a utilizar políticas. Considere el riesgo de seguridad de conceder a sus entidades principales más permisos de los que necesitan para realizar su trabajo. Supervise esas entidades principales para saber qué permisos están utilizando. A continuación, escriba políticas de privilegios mínimos.

IAM proporciona varias opciones para ayudarle a refinar los permisos que concede.

• Comprender las agrupaciones a nivel de acceso - Puede utilizar las agrupaciones de nivel de acceso para conocer el nivel de acceso que concede una política. Las acciones de política se clasifican como List, Read, Write, Permissions management o Tagging. Por ejemplo, puede elegir acciones de los niveles de acceso List y Read para a conceder acceso de solo lectura a los usuarios. Para obtener información sobre cómo utilizar los resúmenes de políticas para entender los permisos de nivel de acceso, consulte Descripción de los niveles de acceso en los resúmenes de políticas.

• Valide las políticas: puede realizar la validación de políticas mediante IAM Access Analyzer cuando cree y edite políticas JSON. Le recomendamos que revise y valide todas las políticas existentes. IAM Access Analyzer proporciona más de 100 verificaciones de políticas para validar sus políticas. Genera advertencias de seguridad cuando una declaración de su política permite el acceso que consideramos excesivamente permisivo. Puede utilizar las recomendaciones procesables que se proporcionan a través de las advertencias de seguridad mientras trabaja para conceder privilegios mínimos. Para obtener más información sobre las verificaciones de políticas proporcionadas por IAM Access Analyzer, consulte Validación de políticas de IAM Access Analyzer.

• Generar una política basada en la actividad de acceso - Para ayudarle a refinar los permisos que concede, puede generar una política de IAM que esté basada en la actividad de acceso de una entidad de IAM (usuario o rol). El analizador de acceso de IAM revisa los registros de AWS CloudTrail y genera una plantilla de política que contiene los permisos que ha utilizado la entidad en el intervalo de tiempo especificado. Puede utilizar la plantilla para crear una política administrada con permisos detallados y, a continuación, adjuntarla a la entidad de IAM. De esta forma, solo concede los permisos que el usuario o rol necesita para interactuar con los recursos de AWS para su caso de uso específico. Para obtener más información, consulte Generar políticas basadas en la actividad de acceso.

• Utilizar la información de acceso reciente — Otra característica que puede ayudarle con menos privilegios es Información de acceso reciente. Encontrará esta información en la pestaña Asesor de acceso de la página de detalles de la consola de IAM de un usuario, grupo, rol o política de IAM. La información del último acceso también incluye información sobre algunas acciones a las que se accedió por última vez para algunos servicios como Amazon EC2, IAM, Lambda y Amazon S3. Si inicia sesión con las credenciales de cuenta administración de AWS Organizations, podrá ver la información de acceso reciente del servicio en la sección AWS Organizations de la consola de IAM. También puede utilizar AWS CLI o la API de AWS para recuperar un informe con información de acceso reciente de las entidades o políticas de IAM o de Organizations. Puede utilizar esta información para identificar permisos innecesarios, de modo que pueda perfeccionar sus políticas de IAM o de Organizations para que cumplan mejor con el principio de privilegio mínimo. Para obtener más información, consulte Perfeccionar los permisos con la información sobre los últimos accesos en AWS.

• Revisar eventos de cuenta en AWS CloudTrail: para reducir aún más los permisos, puede observar los eventos de su cuenta en el Historial de eventos de AWS CloudTrail. Los registros de eventos de CloudTrail de incluyen información detallada que usted puede utilizar para reducir los permisos de la política. Los registros solo incluyen las acciones y los recursos que sus entidades de IAM necesitan. Para obtener más información, consulte Ver eventos de CloudTrail en la consola de CloudTrail en la Guía del usuario de AWS CloudTrail.

Para obtener más información, consulte los siguientes temas de políticas para servicios individuales, en los que se ofrecen ejemplos sobre cómo redactar políticas para recursos específicos de servicios.

• Autenticación y control de acceso para Amazon DynamoDB en la Guía para desarrolladores de Amazon DynamoDB

• Uso de políticas de bucket y políticas de usuario en la Guía del usuario de Amazon Simple Storage Service.

• Información general de las listas de control de acceso en la Guía del usuario de Amazon Simple Storage Service.