AWS Identity and Access Management
Guía del usuario

Casos de uso empresariales

Un caso de uso empresarial sencillo para IAM puede ayudarle a comprender formas básicas de implementar el servicio para controlar el acceso a AWS que los usuarios tienen. El caso de uso se describe en términos generales, sin los mecanismos de cómo utilizaría la API de IAM para lograr los resultados que desea.

Este caso de uso se centra en dos formas habituales en las que una compañía ficticia, llamada Example Corp, podría usar IAM. El primer caso se centra en Amazon Elastic Compute Cloud (Amazon EC2). El segundo se centra en Amazon Simple Storage Service (Amazon S3).

Para obtener más información sobre cómo utilizar IAM con otros servicios de AWS, consulte Servicios de AWS que funcionan con IAM.

Configuración inicial de Example Corp

John es el fundador de Ejemplo Corp. Al iniciar la empresa, crea su propia cuenta de AWS y él mismo utiliza los productos de AWS. A continuación, contrata empleados para trabajar como desarrolladores, administradores, evaluadores, gestores y administradores del sistema.

John utiliza la Consola de administración de AWS con credenciales de Usuario de la cuenta raíz de AWS para crear un usuario para sí mismo denominado John, y un grupo denominado Admins. Concede los permisos al grupo Admins para realizar todas las acciones en todos los recursos de la cuenta de AWS con la política administrada por AWS AdministratorAccess. A continuación, añade el usuario John al grupo de administradores. Para ver una guía paso a paso para la creación de un grupo de administradores y un usuario de IAM para usted y, a continuación, añadir el usuario al grupo de administradores, consulte Creación del primer grupo y usuario administrador de IAM.

En este momento, John puede dejar de utilizar las credenciales de usuario raíz para interactuar con AWS y, en su lugar, comenzar a usar solo sus credenciales de usuario.

Asimismo, John crea un grupo denominado AllUsers para poder aplicar fácilmente los permisos de ámbito de la cuenta a todos los usuarios de la cuenta de AWS. Se agrega a sí mismo al grupo. Luego crea un grupo denominado Developers, un grupo denominado Testers, un grupo denominado Managers y un grupo denominado SysAdmins. Crea usuarios para cada uno de los empleados y los coloca en sus respectivos grupos. También los agrega a todos al grupo AllUsers. Para obtener información sobre cómo crear grupos, consulte Creación de grupos de IAM. Para obtener información sobre cómo crear usuarios, consulte Creación de un usuario de IAM en su cuenta de AWS. Para obtener información sobre cómo agregar usuarios a grupos, consulte Administración de grupos de IAM.

Caso de uso de IAM con Amazon EC2

Una compañía como Example Corp suele usar IAM para interactuar con servicios como Amazon EC2. Para comprender esta parte del caso de uso, necesita tener unos conocimientos básicos de Amazon EC2. Para obtener más información sobre Amazon EC2, diríjase a la Guía del usuario de Amazon EC2 para instancias de Linux.

Permisos de Amazon EC2 para los grupos

Para proporcionar un control del "perímetro", John asocia una política al grupo AllUsers. Esta política deniega cualquier solicitud de AWS de un usuario si la dirección IP de origen se encuentra fuera de la red corporativa de Example Corp.

En Example Corp, los distintos grupos requieren permisos diferentes:

  • Administradores del sistema – Necesitan permiso para crear y administrar imágenes AMI, instancias, instantáneas, volúmenes, grupos de seguridad, etc. John asocia una política al grupo SysAdmins que concede a sus miembros permiso para utilizar todas las acciones de Amazon EC2.

  • Desarrolladores – Necesitan la capacidad de trabajar únicamente con instancias. Por lo tanto, John asocia al grupo de desarrolladores una política que permite a estos llamar a DescribeInstances, RunInstances, StopInstances, StartInstances y TerminateInstances.

    nota

    Amazon EC2 utiliza claves SSH, contraseñas de Windows y grupos de seguridad para controlar quién tiene acceso al sistema operativo de determinadas instancias Amazon EC2. No existe ningún método en el sistema de IAM para permitir o denegar el acceso al sistema operativo de una determinada instancia.

  • Administradores – No deberían realizar ninguna acción de Amazon EC2 excepto la enumeración de los recursos de Amazon EC2 actualmente disponibles. Por lo tanto, John asocia al grupo de administradores una política que solo les permite invocar operaciones de API "Describe" de Amazon EC2.

Para obtener ejemplos de cómo podrían parecer estas políticas, consulte Ejemplos de políticas basadas en identidad de IAM y Utilización de AWS Identity and Access Management en la Guía del usuario de Amazon EC2 para instancias de Linux.

Cambio del rol del usuario

En algún momento, uno de los desarrolladores, Paulo, cambia de puesto y se convierte en administrador. John traslada a Paulo desde el grupo de desarrolladores al grupo de administradores. Ahora que está en el grupo de administradores, Paulo tiene una capacidad limitada para interactuar con las instancias Amazon EC2. No puede lanzar ni iniciar instancias. Tampoco puede detener o terminar las instancias existentes, aunque fue el usuario que lanzó o inició la instancia. Solo puede enumerar las instancias que los usuarios de Example Corp han lanzado.

Caso de uso de IAM con Amazon S3

Las compañías como Example Corp normalmente también utilizarían IAM con Amazon S3. John ha creado un bucket de Amazon S3 para la empresa denominado example_bucket.

Creación de otros usuarios y grupos

Como empleados, Zhang y Mary deben poder crear sus propios datos en el bucket de la empresa. También necesitan leer y escribir datos compartidos en los que trabajan todos los desarrolladores. Para ello, John organiza de forma lógica los datos de example_bucket con un esquema de prefijo de clave de Amazon S3 como el que se muestra en la siguiente figura.

/example_bucket /home /zhang /mary /share /developers /managers

John divide el /example_bucket principal en un conjunto de directorios principales para cada empleado y un área compartida para los grupos de desarrolladores y administradores.

Ahora, John crea un conjunto de políticas para asignar permisos a los usuarios y grupos:

  • Acceso al directorio principal de Zhang – John asocia una política a Zhang que le permite leer, escribir y enumerar cualquier objeto con el prefijo de clave /example_bucket/home/Zhang/ de Amazon S3

  • Acceso al directorio principal de Mary – John asocia una política a Mary que le permite leer, escribir y enumerar cualquier objeto con el prefijo de clave /example_bucket/home/mary/ de Amazon S3

  • Acceso al directorio compartido para el grupo de desarrolladores – John asocia una política al grupo que permite a los desarrolladores leer, escribir y enumerar cualquier objeto de /example_bucket/share/developers/

  • Acceso al directorio compartido para el grupo de administradores – John asocia una política al grupo que permite a los administradores leer, escribir y enumerar objetos de /example_bucket/share/managers/

nota

Amazon S3 no concede automáticamente a un usuario que crea un bucket u objeto permiso para realizar otras acciones en dicho bucket u objeto. Por lo tanto, en sus políticas de IAM debe conceder de forma explícita a los usuarios permiso para usar los recursos de Amazon S3 que creen.

Para obtener ejemplos de cómo podrían parecer estas políticas, consulte Control de acceso en la Guía para desarrolladores de Amazon Simple Storage Service. Para obtener información sobre cómo las políticas se evalúan en tiempo de ejecución, consulte Lógica de evaluación de políticas.

Cambio del rol del usuario

En algún momento, uno de los desarrolladores, Zhang, cambia de puesto y se convierte en administrador. Supongamos que ya no necesita acceso a los documentos del directorio share/developers. John, como administrador, traslada a Zhang al grupo Managers desde el grupo Developers. Con tan solo una sencilla reasignación, Zhang consigue automáticamente todos los permisos concedidos al grupo Managers, pero ya no puede obtener acceso a los datos del directorio share/developers.

Integración con un negocio de terceros

Las organizaciones suelen trabajar con compañías asociadas, asesores y contratistas. Example.Corp tiene un socio denominado Widget Company y una empleada de esta empresa llamada Shirley necesita colocar datos en un bucket para que los use Example Corp. John crea un grupo denominado WidgetCo y un usuario denominado Shirley y añade a Shirley al grupo WidgetCo. John también crea un bucket especial denominado example_partner_bucket para que lo use Shirley.

John actualiza las políticas existentes o añade otras nuevas para integrar al socio Widget Company. Por ejemplo, John puede crear una política nueva que deniega a los miembros del grupo WidgetCo la posibilidad de utilizar acciones que no sean de escritura. Esta política solo sería necesaria si hubiera una política amplia que ofreciera a todos los usuarios acceso a un amplio conjunto de acciones de Amazon S3.