Autorización en AWS

¿En qué consiste el concepto de Autorization (Autorización) en AWS?

El proceso de especificar exactamente que acciones un principal puede o no realizar es llamado autorization (autorización). Este es manejado en IAM definiendo privilegios específicos y políticas, y asociando estas políticas con los principals.

¿Qué son las Policies?

Una policy es un documento JSON que define un grupo de permisos para acceder y manipular recursos de AWS. Los policy documents contienen una o mas permisos, y cada permiso define.

Effect (Efecto): Allow or Deny (Permitir o Denegar).
Service (Service): Para que permiso aplica?
Resource (Recurso): Especifica la infraestructura AWS para la cual el permiso aplica. Este se especifica como Amazon Resource Name (ARN).

arn:sws:service:region:account-id:[resource-type:]resource

Para algunos servicios, el asterisco es permitido; por ejemplo para S3 puede tener un resource nombreDelDirectorio* para indicar que todos los objetos que se encuentran en el folder.

Ejemplos de tipos de ARN

Bucket de S3: arn:aws:s3:us-east-1:123456789012:my_corporate_bucket/*
IAM User: arn:aws:iam:us-east-1:123456789012:user/David
Tabla en DynamoDB: arn:aws:dynamodb:us-east-1:123456789012:table/tablename

Action (Acción)

Específica el subgrupo de acciones dentro del servicio a las cuales se otorga o niega permiso. Por ejemplo, un permiso puede ser concedido a cualquier acción de lectura para S3. Un grupo de acciones puede ser asignado utilizando un wildcard () por ejemplo (Read).

Condition (Condición)

Define uno o mas restricciones adicionales que limitan las acciones permitidas por el permiso. Por ejemplo, el permiso puede contener una condición que limite la habilidad de acceder a un recurso desde llamadas que vengan desde un rango de IPs, un intervalo de tiempo, u otras condiciones que varían de acuerdo a los servicios.

¿Cómo asociar policies con principals?

Una policy puede ser asociada con un usuario de IAM de dos diferentes formas.

User Policy.: Existen unicamente en el contexto del usuario al cual se asocian. En la consola, una policy de usuario es ingresada desde la interface de usuario en la pagina del usuario.
Managed Policies.: Son creadas en la tab de policies, en la pagina de IAM, o mediante CLI, y existen independientemente de cualquier usuario. Esta policy puede ser asociado con muchos usuarios o grupos de usuarios. Existen muchas de estas y también se pueden crear nuevas.

Utilizar managed policies asegura que cuando aparezcan nuevos permisos para nuevas características o funcionalidades, los usuarios seguirán manteniendo acceso correcto.

El otro método de asociación de policies con usuarios es a mediante los grupos. Los grupos simplifican el manejo de permisos para largos números de usuarios. Cuando una policy es asignada a un grupo, cualquier usuario que es un miembro de ese grupo asume esos permisos. Esto hace mas sencillo el asignar policies a un grupo completo en su organización.

Esta es una forma mas sencilla de manejar los procesos asociados a las policies, y de no tener que estar añadiendo manualmente estas policías a cada usuario.

¿Cuáles son las formas en las que un policy puede ser asociado a un grupo?

Group Policy (Política de grupo).: Estas policies existen únicamente en el contexto del grupo al cual están asociadas.
Managed Policies (Políticas Administradas): En la misma forma que las policies manejadas pueden ser asociadas con los usuarios pueden serlo con los grupos.

Como recomendación utilice la cuenta del root para crear un grupo llamado Administradores, y asignar la managed policy “IAMFullAccess”. Después cree un nuevo usuario llamado Administrador, asigna un password y añádale al grupo Administradores. En este punto, puede terminar la sesión del root y realizar las actividades futuras como administrador.

Roles: La última forma en que un actor puede asociarse a una policy es mediante un role. En este caso el actor puede.

Estar autenticado como usuario (persona o proceso) con los permisos del role asumido.
Una persona o proceso autenticado por un servicio en el cual se confía fuera de AWS, como un LDAP dentro de las instalaciones de la organización.

Después de que el usuario asumió el role, un token temporal es asignado y asociado con las policies del role. El token contiene información requerida para hacer llamadas a la API. Este token contiene el standard key ademas de un token adicional de sesión requerido para realizar llamadas con privilegios del role.