# Ejemplos de escenarios sobre el uso de información de acceso reciente Puede utilizar la información de acceso reciente para tomar decisiones sobre los permisos que se conceden a las entidades de IAM o a las entidades de AWS Organizations. Para obtener más información, consulte [Ajuste de permisos en AWS con información sobre los últimos accesos](access_policies_last-accessed.md). **nota** Antes de consultar la información de acceso de una entidad o política de IAM o AWS Organizations, asegúrese de que entiende el período del informe, las entidades consultadas y los tipos de política evaluados. Para obtener más información, consulte [Cosas que debe saber sobre la información de acceso reciente](access_policies_last-accessed.md#access_policies_last-accessed-know). Es responsabilidad del administrador elegir la accesibilidad y el principio de privilegios mínimos apropiado para su empresa. ## Uso de información para reducir los permisos de un grupo de IAM Puede utilizar la información de acceso reciente para reducir los permisos de un grupo de IAM e incluir exclusivamente aquellos servicios que necesitan los usuarios. Este método es un importante paso en la [concesión de privilegios mínimos](best-practices.md#grant-least-privilege) en un nivel de servicio. Por ejemplo, Paulo Santos es el administrador encargado de definir los permisos de usuarios de AWS para Example Corp. Esta empresa acaba de comenzar a utilizar AWS, y el equipo de desarrollo de software aún no ha definido qué servicios de AWS que utilizarán. Paulo quiere dar el equipo permiso para obtener acceso solo a los servicios que necesitan, pero como aún no se ha definido, les proporciona temporalmente permisos de usuario avanzado. Decide utilizar la información de acceso reciente para reducir los permisos del grupo. Paulo crea una política administrada denominada `ExampleDevelopment` utilizando el siguiente texto JSON. A continuación, lo asocia a un grupo denominado `Development` y añade todos los desarrolladores al grupo. **nota** Es posible que los usuarios avanzados de Paulo necesiten permisos de `iam:CreateServiceLinkedRole` para utilizar algunos servicios y características. Él entiende que agregar este permiso los habilitará para crear cualquier rol vinculado al servicio. Acepta este riesgo para sus usuarios avanzados. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "FullAccessToAllServicesExceptPeopleManagement", "Effect": "Allow", "NotAction": [ "iam:*", "organizations:*" ], "Resource": "*" }, { "Sid": "RequiredIamAndOrgsActions", "Effect": "Allow", "Action": [ "iam:CreateServiceLinkedRole", "iam:ListRoles", "organizations:DescribeOrganization" ], "Resource": "*" } ] } ``` ------ Paulo decide esperar 90 días antes de [ver la información de acceso reciente](access_policies_last-accessed-view-data.md#access_policies_last-accessed-viewing) del grupo `Development` a través de Consola de administración de AWS. Ve la lista de servicios a los que han accedido los miembros del grupo. Se entera de que los usuarios accedieron a cinco servicios en la última semana: AWS CloudTrail, Amazon CloudWatch Logs, Amazon EC2, AWS KMS y Amazon S3. Accedieron a otros servicios cuando estaban evaluando por primera vez AWS y desde entonces no lo hicieron. Paulo decide reducir los permisos de la política para incluir solo los cinco servicios y las acciones de IAM y AWS Organizations necesarias. Edita la política de `ExampleDevelopment` con el siguiente texto JSON. **nota** Es posible que los usuarios avanzados de Paulo necesiten permisos de `iam:CreateServiceLinkedRole` para utilizar algunos servicios y características. Él entiende que agregar este permiso los habilitará para crear cualquier rol vinculado al servicio. Acepta este riesgo para sus usuarios avanzados. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "FullAccessToListedServices", "Effect": "Allow", "Action": [ "s3:*", "kms:*", "cloudtrail:*", "logs:*", "ec2:*" ], "Resource": "*" }, { "Sid": "RequiredIamAndOrgsActions", "Effect": "Allow", "Action": [ "iam:CreateServiceLinkedRole", "iam:ListRoles", "organizations:DescribeOrganization" ], "Resource": "*" } ] } ``` ------ Para reducir aún más los permisos, Paulo puede ver los eventos de la cuenta en el **historial de eventos** de AWS CloudTrail. Allí puede ver información de eventos detallada que puede utilizar para reducir los permisos de la política para incluir solo las acciones y los recursos que los desarrolladores necesitan. Para obtener más información, consulte [Ver eventos de CloudTrail en la consola de CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events-console.html) en la *Guía del usuario de AWS CloudTrail*. ## Uso de información para reducir los permisos de un usuario de IAM Puede utilizar la información de acceso reciente para reducir los permisos de un usuario específico de IAM. Por ejemplo, Martha Rivera es una administradora de TI responsable de garantizar que las personas de su empresa no tengan demasiados permisos de AWS. En el marco de una comprobación de seguridad periódica, revisa los permisos de todos los usuarios de IAM. Uno de ellos es un desarrollador de aplicaciones llamado Nikhil Jayashankar, que previamente trabajaba como ingeniero de seguridad. Debido al cambio en los requisitos de trabajo, Nikhil es miembro del grupo `app-dev` y del grupo `security-team`. El grupo de `app-dev` por su nuevo trabajo concede permisos a varios servicios, como Amazon EC2, Amazon EBS, Auto Scaling, Amazon S3, Route 53 y Elastic Transcoder. El grupo `security-team` para su trabajo anterior concede permisos para IAM y CloudTrail. Como administradora, Martha inicia sesión en la consola de IAM y elige **Usuarios**, selecciona el nombre `nikhilj` y elige la pestaña **Último acceso**. Martha revisa la columna **Último acceso** y se da cuenta de que Nikhil no ha accedido recientemente a IAM, CloudTrail, Route 53, Amazon Elastic Transcoder ni a una serie de otros servicios de AWS. Nikhil ha accedido a Amazon S3. Martha elige **S3** en la lista de servicios y se entera de que Nikhil ha realizado algunas acciones `List` de Amazon S3 en las últimas dos semanas. Dentro de la empresa, Martha confirma que Nikhil ya no necesita acceder a IAM y CloudTrail porque ya no es miembro del equipo de seguridad interna. Martha ahora está lista para actuar con arreglo a la información sobre los últimos accesos al servicio o la acción. Sin embargo, a diferencia del grupo del ejemplo anterior, un usuario de IAM como `nikhilj` podría estar sujeto a varias políticas y ser miembro de varios grupos. Martha debe continuar con precaución para evitar interrumpir de forma inadvertida el acceso de `nikhilj` u otros los miembros del grupo. Además de descubrir el acceso que Nikhil debe tener, debe determinar *cómo* está recibiendo estos permisos. Martha elige la pestaña **Permissions (Permisos)**, donde ve qué políticas están asociadas directamente a `nikhilj` y las asociadas desde un grupo. Amplía cada política y ve el resumen de la política para saber qué política permite el acceso a los servicios que Nikhil no está utilizando: + IAM: la política administrada `IAMFullAccess` AWS se asigna directamente a `nikhilj` y se asigna al grupo `security-team`. + CloudTrail: la política administrada de `AWSCloudTrailReadOnlyAccess` AWS se asigna al grupo `security-team`. + Route 53: la política administrada por el cliente `App-Dev-Route53` se asocia al grupo `app-dev`. + Elastic Transcoder: la política administrada por el cliente `App-Dev-ElasticTranscoder` se asocia al grupo `app-dev`. Martha decide eliminar la política administrada `IAMFullAccess` AWS asociada directamente a `nikhilj`. También elimina la pertenencia de Nikhil al grupo `security-team`. Estas dos acciones eliminan el acceso innecesarios a IAM y CloudTrail. Los permisos de Nikhil para acceder a Route 53 y Elastic Transcoder los concede el grupo `app-dev`. Aunque Nikhil no está utilizando dichos servicios, otros miembros del grupo podrían. Martha consulta la información de acceso reciente del grupo `app-dev` y ve que varios miembros accedieron recientemente a Route 53 y Amazon S3. Sin embargo, ningún miembro del grupo ha accedido a Elastic Transcoder en el último año. Elimina política administrada por el cliente `App-Dev-ElasticTranscoder` del grupo. A continuación, Martha revisa la información de acceso reciente de la política `App-Dev-ElasticTranscoder` administrada por el cliente. Descubre que la política no está asociada a ninguna otra entidad de IAM. Investiga dentro de su empresa para asegurarse de que la política no se necesitará en el futuro y, a continuación, la elimina. ## Uso de información antes de eliminar recursos de IAM Puede utilizar la información de acceso reciente antes de eliminar un recurso de IAM para asegurarse de que ha transcurrido una determinada cantidad de tiempo desde que alguien utilizó el recurso por última vez. Esto se aplica a usuarios, grupos, roles y políticas. Para obtener más información acerca de estas acciones, consulte los siguientes temas: + **Usuarios de IAM**: [Remove or deactivate an IAM user](id_users_remove.md) + **Grupos**: [Eliminación de un grupo de usuarios de IAM](id_groups_manage_delete.md) + **Roles**: [Eliminar roles o perfiles de instancia](id_roles_manage_delete.md) + **Políticas**: [Eliminación de políticas de IAM (esta también desasocia la política de las identidades)](access_policies_manage-delete.md) ## Uso de información antes de editar políticas de IAM Puede revisar la información de acceso reciente de una identidad de IAM (usuario, grupo o rol) o de una política de IAM antes de editar una política que afecte a dicho recurso. Esto es importante porque no desea eliminar el acceso de alguien que lo está utilizando. Por ejemplo, Arnav Desai es desarrollador y administrador de AWS de Example Corp. Cuando su equipo comenzó a utilizar AWS, le dieron acceso a todos los desarrolladores de usuarios avanzados que les permitían acceso completo a todos los servicios, excepto IAM y AWS Organizations. Como primer paso hacia la [concesión de privilegios mínimos](best-practices.md#grant-least-privilege), Arnav quiere utilizar la AWS CLI para revisar las políticas administradas de su cuenta. Para ello, Arnav primero lista las políticas de permisos administrados por el cliente de su cuenta asociadas a una identidad, utilizando el comando siguiente: ``` aws iam list-policies --scope Local --only-attached --policy-usage-filter PermissionsPolicy ``` De la respuesta, captura el ARN de cada política. Arnav, a continuación, genera un informe con la información de acceso reciente de cada política utilizando el siguiente comando. ``` aws iam generate-service-last-accessed-details --arn arn:aws:iam::123456789012:policy/ExamplePolicy1 ``` De esa respuesta, captura el ID del informe generado desde el campo `JobId`. Arnav a continuación, sondea el siguiente comando hasta que el campo `JobStatus` devuelva un valor de `COMPLETED` o `FAILED`. Si se produjo un error en el trabajo, captura el error. ``` aws iam get-service-last-accessed-details --job-id 98a765b4-3cde-2101-2345-example678f9 ``` Cuando el trabajo tiene un estado de `COMPLETED`, Arnav analiza el contenido de la matriz `ServicesLastAccessed` con formato JSON. ``` "ServicesLastAccessed": [ { "TotalAuthenticatedEntities": 1, "LastAuthenticated": 2018-11-01T21:24:33.222Z, "ServiceNamespace": "dynamodb", "LastAuthenticatedEntity": "arn:aws:iam::123456789012:user/IAMExampleUser", "ServiceName": "Amazon DynamoDB" }, { "TotalAuthenticatedEntities": 0, "ServiceNamespace": "ec2", "ServiceName": "Amazon EC2" }, { "TotalAuthenticatedEntities": 3, "LastAuthenticated": 2018-08-25T15:29:51.156Z, "ServiceNamespace": "s3", "LastAuthenticatedEntity": "arn:aws:iam::123456789012:role/IAMExampleRole", "ServiceName": "Amazon S3" } ] ``` A partir de esta información, Arnav descubre que la política `ExamplePolicy1` permite el acceso a tres servicios, Amazon DynamoDB, Amazon S3, y Amazon EC2. El usuario de IAM llamado `IAMExampleUser` intentó accede por última vez a DynamoDB el 1 de noviembre y alguien utilizó el rol `IAMExampleRole` para intentar acceder a Amazon S3 el 25 de agosto. También hay dos entidades más que han intentado acceder a Amazon S3 en el último año. Sin embargo, nadie ha intentado acceder a Amazon EC2 en el último año. Esto significa que Arnav puede eliminar de forma segura las acciones de Amazon EC2 de la política. Arnav desea revisar el documento JSON actual de la política. En primer lugar, debe determinar el número de versión de la política utilizando el siguiente comando. ``` aws iam list-policy-versions --policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy1 ``` De la respuesta, Arnav recopila los número de versión predeterminada actual de la matriz `Versions`. A continuación, utiliza ese número de versión (`v2`) para solicitar el documento de política JSON utilizando el siguiente comando. ``` aws iam get-policy-version --policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy1 --version-id v2 ``` Arnav almacena el documento de política de JSON devuelto en el campo `Document` de la matriz `PolicyVersion`. Dentro del documento de política, Arnav busca acciones con el espacio de nombres `ec2`. Si no hay acciones de otros espacios de nombres restantes en la política, desasociará la política de las identidades afectadas (usuarios, grupos y roles). A continuación, elimina la política. En este caso, la política no incluye los servicios Amazon DynamoDB y Amazon S3. Por lo tanto, Arnav elimina las acciones de Amazon EC2 del documento y guarda los cambios. A continuación, utiliza el siguiente comando para actualizar la política utilizando la nueva versión del documento y establecer que dicha versión es la versión de política predeterminada. ``` aws iam create-policy-version --policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy1 --policy-document file://UpdatedPolicy.json --set-as-default ``` La política `ExamplePolicy1` ahora está actualizada para eliminar el acceso al servicio de Amazon EC2 innecesario. ## Otros escenarios de IAM La información sobre cuando un recurso de IAM (usuario, grupo, rol o política) ha intentado por última vez acceder a un servicio puede ser de ayuda al completar cualquiera de las siguientes tareas: + **Políticas**: [Edición de una política administrada por el cliente o insertada existente para eliminar permisos](access_policies_manage-edit.md) + **Políticas**: [Conversión de una política insertada en una política administrada y su eliminación a continuación](access_policies-convert-inline-to-managed.md) + **Políticas**: [adición de una denegación explícita a una política existente](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md) + **Políticas**: [desconexión de una política administrada de una identidad (usuario, grupo o rol)](access_policies_manage-attach-detach.md#detach-managed-policy-console) + **Entidades**: [Establecer un límite de permisos para controlar los permisos máximos que una entidad (usuario o rol) puede tener](access_policies_manage-attach-detach.md) + **Grupos**: [Eliminación de usuarios de un grupo](id_groups_manage_add-remove-users.md) ## Uso de información para perfeccionar los permisos de una unidad organizativa Puede utilizar la información de acceso reciente para perfeccionar los permisos de una unidad organizativa de AWS Organizations. Por ejemplo, John Stiles es un administrador de AWS Organizations. Es responsable de garantizar que las personas de las cuentas de Cuentas de AWS de la empresa no tengan demasiados permisos. En el marco de una auditoría de seguridad periódica, revisa los permisos de la organización. Su unidad organizativa `Development` incluye cuentas que se suelen utilizar para probar nuevos servicios de AWS. John decide revisar periódicamente el informe de los servicios a los que no se ha accedido en más de 180 días. Luego elimina los permisos de los miembros de la unidad organizativa para acceder a dichos servicios. John inicia sesión en la consola de IAM con sus credenciales de cuenta de administración. En la consola de IAM, localiza los datos de AWS Organizations de la unidad organizativa `Development`. Revisa la tabla **Service access report (Informe de acceso a servicios)** y ve dos servicios de AWS a los que no se ha accedido en más de su período preferido de 180 días. Recuerda que añadió permisos para que los equipos de desarrollo accedieran a Amazon Lex y AWS Database Migration Service. John se pone en contacto con los equipos de desarrollo y confirma que ya no tienen una necesidad comercial de probar estos servicios. Ahora John está listo para actuar con arreglo a la información de acceso reciente. Elije **Editar en AWS Organizations** y se le recuerda que la SCP está asociada a varias entidades. Elije **Continue (Continuar)**. En AWS Organizations, revisa los destinos para averiguar a qué entidades de AWS Organizations está asociada la SCP. Todas las entidades se encuentran dentro de la unidad organizativa `Development`. John decide denegar el acceso a las acciones de Amazon Lex y AWS Database Migration Service en la SCP `NewServiceTest`. Esta acción elimina el acceso innecesario a los servicios.