# Identity and Access Management
**Topics**
+ [SEC 2. ¿Cómo administra la autenticación para personas y máquinas?](sec-02.md)
+ [SEC 3. ¿Cómo se gestionan los permisos de las personas y las máquinas?](sec-03.md)
# SEC 2. ¿Cómo administra la autenticación para personas y máquinas?
Hay dos tipos de identidades que debe administrar al abordar la operación de cargas de trabajo de AWS seguras.
+ **Identidades humanas:** las identidades humanas que requieren acceso a sus entornos y aplicaciones de AWS se pueden clasificar en tres grupos: personal, terceros y usuarios.
El grupo de *personal* incluye administradores, desarrolladores y operadores que forman parte de su organización. Necesitan acceso para administrar, crear y operar sus recursos de AWS.
Los *terceros* son colaboradores externos, como contratistas, proveedores o socios. Interactúan con sus recursos de AWS como parte de su compromiso con su organización.
Los *usuarios* son quienes utilizan sus aplicaciones. Acceden a los recursos de AWS a través de navegadores web, aplicaciones de cliente, aplicaciones móviles o herramientas de línea de comandos interactivas.
+ **Identidades de máquinas**: las aplicaciones de carga de trabajo, las herramientas operativas y los componentes requieren una identidad para hacer solicitudes a los servicios de AWS, por ejemplo, para leer datos. Estas identidades incluyen máquinas que se ejecutan en su entorno de AWS, como instancias de Amazon EC2 o funciones de AWS Lambda. También se podrían administrar identidades de máquina para las partes externas a AWS que necesiten acceso a su entorno de AWS.
**Topics**
+ [SEC02-BP01 Uso de mecanismos de inicio de sesión sólidos](sec_identities_enforce_mechanisms.md)
+ [SEC02-BP02 Uso de credenciales temporales](sec_identities_unique.md)
+ [SEC02-BP03 Almacenamiento y uso seguros de secretos](sec_identities_secrets.md)
+ [SEC02-BP04 Uso de un proveedor de identidades centralizado](sec_identities_identity_provider.md)
+ [SEC02-BP05 Auditoría y rotación periódicas de las credenciales](sec_identities_audit.md)
+ [SEC02-BP06 Uso de grupos y atributos de usuarios](sec_identities_groups_attributes.md)
# SEC02-BP01 Uso de mecanismos de inicio de sesión sólidos
Los inicios de sesión (autenticación mediante credenciales de inicio de sesión) pueden presentar riesgos si no se utilizan mecanismos como la autenticación multifactor (MFA), especialmente en situaciones en las que las credenciales de inicio de sesión se han revelado de forma inadvertida o son fáciles de adivinar. Utilice mecanismos de inicio de sesión sólidos para reducir estos riesgos. Para ello, exija que se cumplan políticas de contraseñas sólidas y se utilice MFA.
**Resultado deseado:** reduzca los riesgos de acceso no deseado a las credenciales en AWS mediante el uso de mecanismos de inicio de sesión sólidos para los usuarios de [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/), el [usuario raíz de la Cuenta de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html), [AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) y los proveedores de identidades de terceros. Esto significa exigir que se use MFA, aplicar políticas de contraseñas sólidas y detectar comportamientos de inicio de sesión anómalos.
**Patrones comunes de uso no recomendados:**
+ No aplicar una política de contraseñas segura para sus identidades que incluya contraseñas complejas y MFA.
+ Compartir las mismas credenciales entre diferentes usuarios.
+ No utilizar controles de detección de inicios de sesión sospechosos.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Existen muchas formas en que las identidades humanas puedan iniciar sesión en AWS. Una práctica recomendada de AWS es confiar en un proveedor de identidades centralizado que utilice la federación (federación directa SAML 2.0 entre AWS IAM y el IdP centralizado o usando AWS IAM Identity Center) a la hora de autenticarse en AWS. En ese caso, deberá establecer un proceso de inicio de sesión seguro con su proveedor de identidades o Microsoft Active Directory.
Cuando abre una Cuenta de AWS por primera vez, comienza con un usuario raíz de la Cuenta de AWS. Solo debe usar el usuario raíz de la cuenta para configurar el acceso de los usuarios (y para las [tareas que requieren el usuario raíz](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)). Es importante activar la autenticación multifactor (MFA) para el usuario raíz de la cuenta inmediatamente después de abrir la Cuenta de AWS y proteger al usuario raíz según la [guía de prácticas recomendadas de AWS](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_aws_account.html).
AWS IAM Identity Center está diseñado para usuarios de la plantilla, y puede crear y administrar las identidades de los usuarios dentro del servicio y proteger el proceso de inicio de sesión con MFA. AWS Cognito, por otro lado, está diseñado para la gestión de la identidad y el acceso de los clientes (CIAM), que proporciona grupos de usuarios y proveedores de identidad para las identidades de los usuarios externos en sus aplicaciones.
Si crea usuarios en el AWS IAM Identity Center, proteja el proceso de inicio de sesión en ese servicio y [active la MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html). Para las identidades de los usuarios externos en sus aplicaciones, puede utilizar [grupos de usuarios de Amazon Cognito](https://docs.aws.amazon.com/cognito/index.html) y proteger el proceso de inicio de sesión en ese servicio, o bien utilizar uno de los proveedores de identidades compatibles con los grupos de usuarios de Amazon Cognito.
Además, en el caso de los usuarios del Centro de Identidad de AWS IAM, se puede utilizar [Acceso verificado de AWS](https://docs.aws.amazon.com/verified-access/latest/ug/what-is-verified-access.html) para proporcionar un nivel de seguridad adicional mediante la verificación de la identidad del usuario y la posición del dispositivo antes de que se les conceda acceso a los recursos de AWS.
Si utiliza usuarios de [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/), debe proteger el proceso de inicio de sesión mediante IAM.
Puede utilizar tanto AWS IAM Identity Center y la federación de IAM directa de forma simultánea para gestionar el acceso a AWS. Puede utilizar la federación de IAM para administrar el acceso a la Consola de administración de AWS y a los servicios e IAM Identity Center para administrar el acceso a aplicaciones empresariales como Quick o Amazon Q Business.
Independientemente del método de inicio de sesión que se utilice, es fundamental aplicar una política de inicio de sesión sólida.
### Pasos para la implementación
Estas son recomendaciones generales para un inicio de sesión sólido. Los ajustes reales que configure deben estar establecidos por la política de la empresa o utilizar un estándar como [NIST 800-63.](https://pages.nist.gov/800-63-3/sp800-63b.html)
+ Require MFA (Requerir MFA): Es [práctica recomendada de IAM exigir la MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#enable-mfa-for-privileged-users) para las identidades humanas y las cargas de trabajo. Si se activa MFA, habrá una capa adicional de seguridad que exigirá que los usuarios proporcionen credenciales de inicio de sesión y una contraseña de un solo uso (OTP) o una cadena que se verifica criptográficamente y se genera desde un dispositivo físico.
+ Imponga una longitud mínima para la contraseña. Esto es un factor fundamental para la seguridad de la contraseña.
+ Imponga una complejidad de las contraseñas para que sean más difíciles de adivinar.
+ Permita que los usuarios cambien sus contraseñas.
+ Cree identidades individuales en lugar de credenciales compartidas. Si crea identidades individuales, puede dar a cada usuario un conjunto único de credenciales de seguridad. Tener usuarios individuales permite auditar la actividad de cada uno de ellos.
Recomendaciones de IAM Identity Center:
+ IAM Identity Center proporciona una [política de contraseñas](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html) predefinida cuando se utiliza el directorio predeterminado, que establece la longitud, la complejidad y los requisitos de reutilización de las contraseñas.
+ [Active la MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/mfa-enable-how-to.html) y configure los ajustes contextuales o permanentes para la MFA cuando el origen de la identidad sea el directorio predeterminado, AWS Managed Microsoft AD, o AD Connector.
+ Permita a los usuarios [registrar sus propios dispositivos MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/how-to-allow-user-registration.html).
Recomendaciones del directorio de grupos de usuarios de Amazon Cognito:
+ Configurar los ajustes de [Seguridad de la contraseña](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html).
+ [Requiera MFA](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-mfa.html) para los usuarios.
+ Utilizar la [configuración de seguridad avanzada](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-advanced-security.html) de grupos de usuarios de Amazon Cognito para las características, como la [autenticación adaptativa](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-adaptive-authentication.html), que puede bloquear los inicios de sesión sospechosos.
Recomendaciones de usuarios de IAM:
+ Lo ideal es que utilice IAM Identity Center o la federación directa. Sin embargo, es posible que necesite usuarios de IAM. En ese caso, [establezca una política de contraseñas](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) para los usuarios de IAM. Puede usar una política de contraseñas para definir requisitos, tales como la longitud mínima o si deben contener caracteres no alfanuméricos.
+ Cree una política de IAM para [imponer el inicio de sesión con MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_users-self-manage-mfa-and-creds.html#tutorial_mfa_step1) de modo que los usuarios puedan administrar sus propias contraseñas y dispositivos MFA.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [SEC02-BP03 Almacenamiento y uso seguros de secretos](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html)
+ [SEC02-BP04 Uso de un proveedor de identidades centralizado](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)
+ [SEC03-BP08 Uso compartido de recursos de forma segura en su organización](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_share_securely.html)
**Documentos relacionados:**
+ [Política de contraseñas del AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html)
+ [ Política de contraseñas para usuarios de IAM ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)
+ [Configuración de la contraseña del usuario raíz de la Cuenta de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)
+ [Política de contraseñas de Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html)
+ [Credenciales de AWS](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html)
+ [Prácticas recomendadas de seguridad de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
**Videos relacionados:**
+ [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E)
+ [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC02-BP02 Uso de credenciales temporales
Al llevar a cabo cualquier tipo de autenticación, es mejor utilizar credenciales temporales en lugar de credenciales de larga duración para reducir o eliminar riesgos. Por ejemplo, que las credenciales se divulguen, compartan o roben de forma inadvertida.
**Resultado deseado:** para reducir el riesgo de credenciales a largo plazo, utilice credenciales temporales siempre que sea posible para las identidades humanas y de máquinas. Las credenciales de larga duración entrañan muchos riesgos. Por ejemplo, podrían subirse a repositorios públicos y quedar expuestas. Al utilizar credenciales temporales, reducirá enormemente las posibilidades de que las credenciales se vean comprometidas.
**Patrones comunes de uso no recomendados:**
+ Desarrolladores que utilizan claves de acceso de larga duración de usuarios de IAM en lugar de obtener credenciales temporales de la CLI mediante federación.
+ Desarrolladores que incrustan claves de acceso de larga duración en su código y suben ese código a repositorios de Git públicos.
+ Desarrolladores que incrustan claves de acceso de larga duración en aplicaciones móviles que luego se ponen a disposición de todo el mundo en las tiendas de aplicaciones.
+ Usuarios que comparten claves de acceso de larga duración con otros usuarios, o empleados que abandonan la empresa con claves de acceso de larga duración aún en su poder.
+ Utilizar claves de acceso de larga duración para identidades de máquinas cuando podrían utilizarse credenciales temporales.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Utilice credenciales de seguridad temporales en lugar de credenciales de larga duración para todas las solicitudes de la API y la AWS CLI. Las solicitudes de la API y la CLI a los servicios de AWS deben, en casi todos los casos, firmarse mediante [claves de acceso de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html). Estas solicitudes pueden firmarse con credenciales temporales o de larga duración. La única vez que debe utilizar credenciales de larga duración, también conocidas como claves de acceso a largo plazo, es si utiliza un [usuario de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) o un [usuario raíz de la Cuenta de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html). Al federarse en AWS o asumir un [rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) mediante otros métodos, se generan credenciales temporales. Incluso cuando accede a la Consola de administración de AWS mediante credenciales de inicio de sesión, se generan credenciales temporales para que pueda hacer llamadas a los servicios de AWS. Hay pocas situaciones en las que necesite credenciales de larga duración, y casi todas las tareas se pueden llevar a cabo mediante credenciales temporales.
Evitar el uso de credenciales de larga duración en favor de credenciales temporales debería acompañarse de una estrategia de reducción del uso de usuarios de IAM a favor de la federación y los roles de IAM. Aunque en el pasado se han utilizado usuarios de IAM tanto para identidades humanas como de máquinas, ahora recomendamos no utilizarlos para evitar los riesgos que conlleva el uso de claves de acceso de larga duración.
### Pasos para la implementación
#### Identidades humanas
Para identidades de la plantilla, como las de empleados, administradores, desarrolladores, operadores y clientes:
+ Debería [basarse en un proveedor de identidades centralizado](https://docs.aws.amazon.com//wellarchitected/latest/security-pillar/sec_identities_identity_provider.html) y [exigir que los usuarios humanos utilicen la federación con un proveedor de identidades para acceder a AWS con credenciales temporales](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp). La federación de los usuarios se puede efectuar mediante la [federación directa a cada Cuenta de AWS](https://aws.amazon.com/identity/federation/) o con [AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) y el proveedor de identidades que prefiera. La federación tiene una serie de ventajas con respecto a los usuarios de IAM, además de eliminar las credenciales de larga duración. Los usuarios también pueden solicitar credenciales temporales desde la línea de comandos para la [federación directa](https://aws.amazon.com/blogs/security/how-to-implement-federated-api-and-cli-access-using-saml-2-0-and-ad-fs/) o mediante [IAM Identity Center](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html). Esto significa que hay pocos casos de uso que requieran usuarios de IAM o credenciales de larga duración para los usuarios.
Para identidades de terceros:
+ Al conceder a terceros, como a proveedores de software como servicio (SaaS), acceso a los recursos en su Cuenta de AWS, puede utilizar [roles entre cuentas](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) y [políticas basadas en recursos](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html). Además, puede utilizar el flujo de concesión de credenciales de cliente de [Amazon Cognito OAuth 2.0](https://docs.aws.amazon.com/cognito/latest/developerguide/federation-endpoints-oauth-grants.html) para clientes o socios de SaaS B2B.
Las identidades de usuario que acceden a los recursos de AWS a través de navegadores web, aplicaciones de cliente, aplicaciones móviles o herramientas de línea de comando interactivas:
+ Si necesita conceder a las aplicaciones para consumidores o clientes acceso a los recursos de su AWS, puede utilizar [grupos de identidades de Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html) o [grupos de usuarios de Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html) para proporcionar credenciales temporales. Los permisos de las credenciales se controlan mediante los roles de IAM que cree. También puede definir un rol de IAM independiente con permisos limitados para los usuarios invitados que no estén autenticados.
#### Identidades de máquina
En el caso de las identidades de máquina, puede que necesite utilizar credenciales de larga duración. En estos casos, puede [exigir que las cargas de trabajo utilicen credenciales temporales con roles de IAM para acceder a AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-workloads-use-roles).
+ Para [Amazon Elastic Compute Cloud](https://aws.amazon.com/pm/ec2/) (Amazon EC2), puede utilizar [roles para Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html).
+ [AWS Lambda](https://aws.amazon.com/lambda/) permite configurar un [rol de ejecución de Lambda para conceder al servicio permisos](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) para llevar a cabo acciones de AWS mediante credenciales temporales. Existen muchos otros modelos similares para que los servicios de AWS concedan credenciales temporales con roles de IAM.
+ En el caso de los dispositivos de IoT, puede utilizar el [proveedor de credenciales de AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html) para solicitar credenciales temporales.
+ Para los sistemas en las instalaciones o los que se ejecutan fuera de AWS que necesitan acceso a los recursos de AWS, puede utilizar [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html).
Hay escenarios en los que no se admiten credenciales temporales, pero requieren el uso de credenciales de larga duración. En estas situaciones, [audite y rote las credenciales periódicamente](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html) y [rote las claves de acceso periódicamente](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials). En el caso de las claves de acceso de los usuarios de IAM muy restringidas, tenga en cuenta las siguientes medidas de seguridad adicionales:
+ Otorgue permisos muy restringidos:
+ Cumpla con el principio de privilegio mínimo (sea específico en cuanto a las acciones, los recursos y las condiciones).
+ Plantéese la opción de conceder al usuario de IAM solo la operación AssumeRole para un rol específico. En función de la arquitectura local, este enfoque ayuda a aislar y proteger las credenciales de IAM a largo plazo.
+ Limite las fuentes de red y las direcciones IP permitidas en la política de confianza de roles de IAM.
+ Supervise el uso y configure alertas para detectar permisos no utilizados o mal uso (mediante alarmas y filtros de métricas de AWS CloudWatch Logs).
+ Exija el cumplimiento de los [límites de los permisos](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) (las políticas de control de servicios [SCP]) y los límites de permisos se complementan entre sí: las SCP son muy generales, mientras que los límites de los permisos son más precisos).
+ Implemente un proceso para aprovisionar y almacenar de forma segura (en un almacén local) las credenciales.
Entre las opciones para los escenarios que requieren credenciales a largo plazo también se incluyen:
+ Crear su propia API de venta de tokens (mediante Amazon API Gateway).
+ En situaciones en las que deba utilizar credenciales de larga duración o para credenciales distintas de las claves de acceso de AWS (como los inicios de sesión en bases de datos), puede utilizar un servicio diseñado para gestionar los secretos, como [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/). Secrets Manager simplifica la administración, la rotación y el almacenamiento seguro de los secretos cifrados. Muchos servicios de AWS admiten la [integración directa](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating.html) con Secrets Manager.
+ [Para las integraciones multinube, puede utilizar la federación de identidades en función de las credenciales del proveedor de servicios de credenciales (CSP) de origen (consulte AWS STS AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)).
Para obtener más información sobre cómo cambiar las credenciales de larga duración, consulte cómo [rotar las claves de acceso](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey).
## Recursos
**Prácticas recomendadas relacionadas:**
+ [SEC02-BP03 Almacenamiento y uso seguros de secretos](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html)
+ [SEC02-BP04 Uso de un proveedor de identidades centralizado](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)
+ [SEC03-BP08 Uso compartido de recursos de forma segura en su organización](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_share_securely.html)
**Documentos relacionados:**
+ [Credenciales de seguridad temporales](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
+ [Credenciales de AWS](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html)
+ [Prácticas recomendadas de seguridad de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Roles de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)
+ [IAM Identity Center](https://aws.amazon.com/iam/identity-center/)
+ [Federación y proveedores de identidades](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)
+ [Rotación de las claves de acceso](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)
+ [Soluciones de socios de seguridad: acceso y control de acceso](https://aws.amazon.com/security/partner-solutions/#access-control)
+ [El usuario raíz de la cuenta de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)
+ [Access AWS using a Google Cloud Platform native workload identity](https://aws.amazon.com/blogs/security/access-aws-using-a-google-cloud-platform-native-workload-identity/)
+ [How to access AWS resources from Microsoft Entra ID tenants using AWS Security Token Service](https://aws.amazon.com/blogs/security/how-to-access-aws-resources-from-microsoft-entra-id-tenants-using-aws-security-token-service/)
**Videos relacionados:**
+ [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E)
+ [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC02-BP03 Almacenamiento y uso seguros de secretos
Una carga de trabajo necesita una capacidad automatizada para demostrar su identidad a bases de datos, recursos y servicios de terceros. Para ello, se utilizan credenciales de acceso secretas, como claves de acceso a API, contraseñas y tokens OAuth. El uso de un servicio creado específicamente para almacenar, administrar y rotar estas credenciales ayuda a reducir la probabilidad de que dichas credenciales se vean comprometidas.
**Resultado deseado:** implementación de un mecanismo de administración segura de las credenciales de las aplicaciones que logre los siguientes objetivos:
+ Identificar qué secretos son necesarios para la carga de trabajo.
+ Reducir el número de credenciales de larga duración necesarias y sustituirlas por credenciales de corta duración cuando sea posible.
+ Establecer un almacenamiento seguro y una rotación automatizada de las credenciales restantes de larga duración.
+ Auditar el acceso a los secretos que existen en la carga de trabajo.
+ Supervisar de forma continua para verificar que no se incruste ningún secreto en el código fuente durante el proceso de desarrollo.
+ Reduzca la probabilidad de que las credenciales se divulguen por accidente.
**Patrones comunes de uso no recomendados:**
+ No rotar las credenciales.
+ Almacenar credenciales a largo plazo en el código fuente o en archivos de configuración.
+ Almacenar credenciales en reposo sin cifrar.
**Beneficios de establecer esta práctica recomendada:**
+ Los secretos se almacenan cifrados en reposo y en tránsito.
+ El acceso a las credenciales se controla a través de una API (considérela como una *máquina expendedora de credenciales*).
+ El acceso a una credencial (tanto de lectura como de escritura) se audita y registra.
+ Separación de preocupaciones: la rotación de credenciales la hace un componente independiente, que puede separarse del resto de la arquitectura.
+ Los secretos se distribuyen automáticamente bajo demanda a los componentes de software, y la rotación se produce en una ubicación central.
+ El acceso a las credenciales puede controlarse de forma detallada.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada**: alto
## Guía para la implementación
En el pasado, las credenciales que se utilizaban para autenticarse en bases de datos, API de terceros, tokens y otros secretos podían estar incrustadas en el código fuente o en archivos del entorno. AWS proporciona varios mecanismos para almacenar estas credenciales de forma segura, rotarlas automáticamente y auditar su uso.
La mejor manera de abordar la administración de secretos es seguir la norma de eliminar, sustituir y rotar. La credencial más segura es aquella que no se tiene que almacenar, administrar ni manejar. Es posible que haya credenciales que ya no sean necesarias para el funcionamiento de la carga de trabajo y que, por tanto, puedan eliminarse de forma segura.
En el caso de las credenciales que siguen siendo necesarias para el correcto funcionamiento de la carga de trabajo, podría existir la oportunidad de sustituir una credencial de larga duración por una credencial temporal o de corta duración. Por ejemplo, en lugar de codificar rígidamente una clave de acceso secreta de AWS, considere la posibilidad de sustituir esa credencial de larga duración por una credencial temporal a través de roles de IAM.
Es posible que algunos secretos de larga duración no puedan eliminarse ni sustituirse. Estos secretos se pueden almacenar en un servicio, como [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html), donde se pueden almacenar, administrar y rotar de forma centralizada periódicamente.
Una auditoría del código fuente y de los archivos de configuración de la carga de trabajo puede revelar muchos tipos de credenciales. La siguiente tabla resume las estrategias para manejar los tipos comunes de credenciales:
| Tipo de credenciales | Descripción | Estrategia sugerida |
| --- | --- | --- |
| claves de acceso de IAM | Claves de acceso y secretas de AWS IAM que se utilizan para asumir roles de IAM dentro de una carga de trabajo | Reemplazo: utilice los [roles de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios.html) asignados a las instancias de cómputo (como [Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) o [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)) en su lugar. Para garantizar la interoperabilidad con terceros que tengan que acceder a los recursos en la Cuenta de AWS, pregunte si admiten el [acceso entre cuentas de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html). En el caso de aplicaciones móviles, considere la posibilidad de usar credenciales temporales a través de [grupos de identidades de Amazon Cognito (identidades federadas](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html)). Para las cargas de trabajo que se ejecutan fuera de AWS, considere [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) o [Activaciones híbridas de AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html). Para los contenedores, consulte el [rol de IAM de la tarea de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html) o el [rol de IAM del nodo de Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html). |
| Claves de SSH | Las claves privadas de Secure Shell se utilizan para iniciar sesión en las instancias de EC2 de Linux, de forma manual o como parte de un proceso automatizado | Reemplazo: utilice [AWS Systems Manager](https://aws.amazon.com/blogs/mt/vr-beneficios-session-manager/) o [EC2 Instance Connect](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html) para proporcionar acceso mediante programación y humano a las instancias de EC2 mediante roles de IAM. |
| Credenciales de aplicaciones y bases de datos | Contraseñas: cadena de texto sin formato | Rotación: almacene las credenciales en [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) y establezca una rotación automatizada si es posible. |
| Credenciales de Amazon RDS y Aurora Admin Database | Contraseñas: cadena de texto sin formato | Reemplazo: utilice la [integración de Secrets Manager en Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-secrets-manager.html) o [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-secrets-manager.html). Además, algunos tipos de bases de datos de RDS pueden utilizar roles de IAM en lugar de contraseñas en algunos casos de uso (para obtener más información, consulte [Autenticación de bases de datos de IAM](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html)). |
| Tokens OAuth | Tokens secretos: cadena de texto sin formato | Rotación: almacene los tokens en [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) y configure la rotación automatizada. |
| Tokens y claves de API | Tokens secretos: cadena de texto sin formato | Rotación: almacénelas en [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) y establezca una rotación automatizada si es posible. |
Un patrón común de uso no recomendado es incrustar claves de acceso de IAM dentro del código fuente, los archivos de configuración o las aplicaciones móviles. Cuando se necesite una clave de acceso de IAM para comunicarse con un servicio de AWS, utilice [credenciales de seguridad temporales (a corto plazo)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html). Estas credenciales a corto plazo se pueden proporcionar mediante [roles de IAM para instancias de EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html), [roles de ejecución](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) para funciones de Lambda, [roles de IAM de Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html) para el acceso de usuarios móviles y [políticas de IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/iot-policies.html) para dispositivos de IoT. Al interactuar con terceros, dé prioridad a [delegar el acceso a un rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) con el acceso necesario a los recursos de su cuenta en lugar de configurar un usuario de IAM y enviar al tercero la clave de acceso secreta de ese usuario.
Hay muchos casos en los que la carga de trabajo requiere el almacenamiento de los secretos necesarios para interoperar con otros servicios y recursos. [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) está diseñado específicamente para administrar estas credenciales de forma segura, así como para el almacenamiento, el uso y la rotación de los tokens de API, las contraseñas y otras credenciales.
AWS Secrets Manager proporciona cinco funciones clave para garantizar el almacenamiento y la administración seguros de las credenciales confidenciales: [cifrado en reposo](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html), [cifrado en tránsito](https://docs.aws.amazon.com/secretsmanager/latest/userguide/data-protection.html), [auditoría exhaustiva](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html), [control de acceso detallado](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access.html) y [rotación de credenciales ampliable](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html). También son aceptables otros servicios de administración de secretos de socios de AWS o soluciones desarrolladas localmente que proporcionen capacidades y garantías similares.
Cuando recupera un secreto, puede utilizar el componente de almacenamiento en caché del cliente de Secrets Manager para utilizarlo más adelante. Recuperar un secreto almacenado en la memoria caché es más rápido que recuperarlo desde Secrets Manager. Asimismo, dado que la llamada a las API de Secrets Manager conlleva un coste, el uso de una caché puede reducirlo. Para conocer todas las formas en las que puede recuperar secretos, consulte [Obtener secretos](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html).
**nota**
Algunos lenguajes pueden pedirle que implemente su propio cifrado en memoria para el almacenamiento en caché del cliente.
### Pasos para la implementación
1. Identifique las rutas de código que contienen credenciales con codificación rígida mediante herramientas automatizadas, como [Amazon CodeGuru](https://aws.amazon.com/codeguru/features/).
1. Utilice Amazon CodeGuru para analizar los repositorios de código. Una vez finalizada la revisión, filtre por Type=Secrets en CodeGuru para encontrar líneas de código que presentan problemas.
1. Identifique las credenciales que pueden eliminarse o sustituirse.
1. Identifique las credenciales que ya no sean necesarias y márquelas para eliminarlas.
1. En el caso de las claves secretas de AWS que estén incrustadas en el código fuente, sustitúyalas por roles de IAM asociados a los recursos necesarios. Si parte de la carga de trabajo se encuentra fuera de AWS, pero requiere credenciales de IAM para acceder a los recursos de AWS, considere la posibilidad de usar [IAM Roles Anywhere](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/) o [Activaciones híbridas de AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html).
1. Para otros secretos de terceros de larga duración que requieran el uso de la estrategia de rotación, integre Secrets Manager en el código para recuperar secretos de terceros en tiempo de ejecución.
1. La consola de CodeGuru puede [crear automáticamente un secreto en Secrets Manager](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/) con las credenciales detectadas.
1. Integre la recuperación de secretos desde Secrets Manager en el código de la aplicación.
1. Las funciones de Lambda sin servidor pueden utilizar una [extensión de Lambda](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets_lambda.html) independiente del lenguaje.
1. Para las instancias o contenedores de EC2, AWS proporciona un ejemplo de [código del lado del cliente para recuperar secretos de Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html) en varios lenguajes de programación populares.
1. Revise periódicamente la base de código y vuelva a analizarla para verificar que no se hayan agregado nuevos secretos al código.
1. Considere la posibilidad de utilizar una herramienta, como [git-secrets](https://github.com/awslabs/git-secrets), para evitar confirmar nuevos secretos en el repositorio del código fuente.
1. [Supervisión de la actividad de Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html) para detectar indicios de uso inesperado, acceso inapropiado a secretos o intentos de eliminar secretos.
1. Reduzca la exposición humana a las credenciales. Restrinja el acceso para leer, escribir y modificar credenciales a un rol de IAM dedicado a este fin, y solo proporcione acceso para asumir el rol a un pequeño subconjunto de usuarios operativos.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [SEC02-BP02 Uso de credenciales temporales](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC02-BP05 Auditoría y rotación periódicas de las credenciales](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html)
**Documentos relacionados:**
+ [Introducción a AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html)
+ [Federación y proveedores de identidades](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)
+ [Amazon CodeGuru presenta el detector de secretos](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/)
+ [Cómo AWS Secrets Manager utiliza AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/services-secrets-manager.html)
+ [Cifrado y descifrado de secretos en Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html)
+ [Entradas del blog de Secrets Manager](https://aws.amazon.com/blogs/security/tag/aws-secrets-manager/)
+ [Amazon RDS presenta la integración con AWS Secrets Manager](https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-rds-integration-aws-secrets-manager/)
**Videos relacionados:**
+ [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale](https://youtu.be/qoxxRlwJKZ4)
+ [Find Hard-Coded Secrets Using Amazon CodeGuru Secrets Detector](https://www.youtube.com/watch?v=ryK3PN--oJs)
+ [Securing Secrets for Hybrid Workloads Using AWS Secrets Manager](https://www.youtube.com/watch?v=k1YWhogGVF8)
**Talleres relacionados:**
+ [Store, retrieve, and manage sensitive credentials in AWS Secrets Manager](https://catalog.us-east-1.prod.workshops.aws/workshops/92e466fd-bd95-4805-9f16-2df07450db42/en-US)
+ [Activaciones híbridas de AWS Systems Manager](https://mng.workshop.aws/ssm/capability_hands-on_labs/hybridactivations.html)
# SEC02-BP04 Uso de un proveedor de identidades centralizado
Para las identidades de la plantilla (empleados y contratistas), recurra a un proveedor de identidades que le permita administrar las identidades desde un lugar centralizado. De este modo se facilita la administración del acceso en varias aplicaciones y sistemas, pues crea, asigna, administra, revoca y audita el acceso desde un único lugar.
**Resultado deseado:** tiene un proveedor de identidades centralizado en el que administra de forma centralizada los usuarios de la plantilla, las políticas de autenticación (como la exigencia de la autenticación multifactor [MFA]) y la autorización de los sistemas y las aplicaciones (como la asignación del acceso en función de la pertenencia o los atributos del grupo del usuario). Los usuarios de la plantilla inician sesión en el proveedor de identidades central y se federan (inicio de sesión único) en aplicaciones internas y externas, lo que elimina la necesidad de que los usuarios recuerden varias credenciales. El proveedor de identidades está integrado en sus sistemas de recursos humanos (RR. HH.) para que los cambios de personal se sincronicen automáticamente con su proveedor de identidades. Por ejemplo, si alguien abandona la organización, puede revocar automáticamente el acceso a las aplicaciones y sistemas federados (incluido AWS). Ha habilitado el registro de auditoría detallado en su proveedor de identidades y supervisa estos registros para detectar comportamientos inusuales de los usuarios.
**Patrones comunes de uso no recomendados:**
+ No utiliza la federación ni el inicio de sesión único. Los usuarios de la plantilla crean cuentas de usuario y credenciales independientes en diversas aplicaciones y sistemas.
+ No ha automatizado el ciclo de vida de las identidades de los usuarios de la plantilla, por ejemplo, no ha integrado su proveedor de identidades en sus sistemas de recursos humanos. Cuando un usuario abandona la organización o cambia de rol, se sigue un proceso manual para eliminar o actualizar sus registros en varias aplicaciones y sistemas.
**Beneficios de establecer esta práctica recomendada:** al usar un proveedor de identidades centralizado, hay un único lugar en el que se administran las identidades y políticas de los usuarios en plantilla, la capacidad de asignar acceso a aplicaciones a los usuarios y grupos y la capacidad de supervisar la actividad de inicio de sesión de los usuarios. Al integrarse en sus sistemas de recursos humanos (RR. HH.), cuando un usuario cambia de rol, estos cambios se sincronizan con el proveedor de identidades, y las aplicaciones y permisos asignados se actualizan automáticamente. Cuando un usuario abandona la organización, su identidad se inhabilita automáticamente en el proveedor de identidades, lo que revoca su acceso a las aplicaciones y sistemas federados.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada**: alto
## Guía para la implementación
**Orientaciones para los usuarios de la plantilla que acceden a AWS** Es posible que los usuarios de la plantilla, como empleados y contratistas de su organización, tengan que acceder a AWS mediante la Consola de administración de AWS o la AWS Command Line Interface (AWS CLI) para trabajar. Para conceder acceso a AWS, puede federar a los usuarios en plantilla desde su proveedor de identidades centralizado en AWS en dos niveles: federación directa a cada Cuenta de AWS o federación de varias cuentas en su [organización de AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html).
Para federar a los usuarios en plantilla directamente con cada Cuenta de AWS, puede utilizar un proveedor de identidades centralizado para federar a [AWS Identity and Access Management](https://aws.amazon.com/iam/) en esa cuenta. La flexibilidad de IAM le permite habilitar un proveedor de identidades [SAML 2.0](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html) u [Open ID Connect (OIDC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html) por separado para cada Cuenta de AWS y utilizar atributos de usuario federado para el control de acceso. Para iniciar sesión en el proveedor de identidades, los usuarios en plantilla utilizarán su navegador web y proporcionarán sus credenciales (como contraseñas y códigos de token de MFA). El proveedor de identidades envía una aserción SAML a su navegador que se envía a la URL de inicio de sesión de la Consola de administración de AWS para permitir que el usuario haga un inicio de sesión único en la [Consola de administración de AWS al asumir un rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html). Los usuarios también pueden obtener credenciales temporales de la API de AWS para usarlas en la [AWS CLI](https://aws.amazon.com/cli/) o los [SDK de AWS](https://aws.amazon.com/developer/tools/) desde [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) si [asumen el rol de IAM mediante una aserción de SAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) del proveedor de identidades.
Para federar a los usuarios en plantilla con varias cuentas en su organización de AWS, puede utilizar [https://aws.amazon.com/single-sign-on/](https://aws.amazon.com/single-sign-on/) para administrar de forma centralizada el acceso de los usuarios en plantilla a las Cuentas de AWS y a las aplicaciones. Puede habilitar Identity Center para su organización y configurar el origen de las identidades. IAM Identity Center proporciona un directorio predeterminado de orígenes de identidad que puede utilizar para administrar usuarios y grupos. Como alternativa, puede elegir un origen de identidades externo mediante la [https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html) con SAML 2.0 y el [aprovisionamiento automático](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html) de usuarios y grupos con SCIM, o mediante la [https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html) a través de [Directory Service](https://aws.amazon.com/directoryservice/). Una vez configurado un origen de identidades, puede asignar acceso a Cuentas de AWS a usuarios y grupos al definir políticas de privilegios mínimos en los [conjuntos de permisos](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html). Los usuarios en plantilla pueden autenticarse a través de su proveedor de identidades central para iniciar sesión en el [portal de acceso de AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/using-the-portal.html) e iniciar sesión de forma única en Cuentas de AWS y en las aplicaciones en la nube que tengan asignadas. Los usuarios pueden configurar la [AWS CLI v2](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html) para autenticarse en IAM Identity Center y obtener credenciales para ejecutar comandos de la AWS CLI. Identity Center también permite el acceso mediante inicio de sesión único a aplicaciones de AWS, como [Amazon SageMaker AI Studio](https://docs.aws.amazon.com/sagemaker/latest/dg/onboard-sso-users.html) y [portales de AWS IoT Sitewise Monitor](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/monitor-getting-started.html).
Tras seguir las instrucciones anteriores, los usuarios en plantilla ya no tendrán que usar grupos y usuarios de IAM para las operaciones normales al administrar las cargas de trabajo en AWS. En cambio, los usuarios y grupos se administran fuera de AWS, y los usuarios pueden acceder a los recursos de AWS como una *identidad federada*. Las identidades federadas utilizan los grupos definidos por el proveedor de identidades centralizado. Debe identificar y eliminar los grupos de IAM, los usuarios de IAM y las credenciales de usuario de larga duración (contraseñas y claves de acceso) que ya no sean necesarios en sus Cuentas de AWS. Puede [encontrar las credenciales sin usar](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html) mediante los [informes de credenciales de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html), [eliminar los usuarios de IAM correspondientes](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html) y [eliminar los grupos de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_delete.html). En su organización, puede aplicar una [política de control de servicio (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) que ayude a evitar la creación de nuevos usuarios y grupos de IAM, y exigir que el acceso a AWS se haga mediante identidades federadas.
**nota**
Es su responsabilidad gestionar la rotación de los tokens de acceso de SCIM, tal como se describe en la documentación de [Aprovisionamiento automático](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html). Además, es responsable de rotar los certificados que respaldan su federación de identidades.
**Orientaciones para los usuarios de sus aplicaciones** Puede administrar las identidades de los usuarios de sus aplicaciones, como una aplicación móvil, mediante [https://aws.amazon.com/cognito/](https://aws.amazon.com/cognito/) como proveedor de identidades centralizado. Amazon Cognito permite la autenticación, autorización y administración de usuarios para sus aplicaciones móviles y web. Amazon Cognito proporciona un almacén de identidades que se escala a millones de usuarios, admite la federación de identidades sociales y empresariales, y ofrece características de seguridad avanzadas para ayudar a proteger a sus usuarios y a su empresa. Puede integrar su aplicación web o móvil personalizada en Amazon Cognito para agregar autenticación de usuarios y control de acceso a sus aplicaciones en cuestión de minutos. Basado en estándares de identidad abiertos, como SAML y Open ID Connect (OIDC), Amazon Cognito es compatible con varias normativas de cumplimiento y se integra en los recursos de desarrollo de frontend y backend.
### Pasos para la implementación
**Pasos para los usuarios em plantilla que acceden a AWS**
+ Federe a los usuarios en plantilla en AWS mediante un proveedor de identidades centralizado con uno de los siguientes enfoques:
+ Utilice IAM Identity Center para habilitar el inicio de sesión único en varias Cuentas de AWS de su organización de AWS mediante la federación con su proveedor de identidades.
+ Utilice IAM para conectar su proveedor de identidades directamente a cada Cuenta de AWS, lo que permite un acceso federado y detallado.
+ Identifique y elimine los grupos y usuarios de IAM que se sustituyan por identidades federadas.
**Pasos para los usuarios de sus aplicaciones**
+ Utilice Amazon Cognito como proveedor de identidades centralizado para sus aplicaciones.
+ Integre sus aplicaciones personalizadas en Amazon Cognito mediante OpenID Connect y OAuth. Puede desarrollar sus aplicaciones personalizadas mediante las bibliotecas de Amplify, que proporcionan interfaces sencillas para integrarse con una variedad de servicios de AWS, como Amazon Cognito, para la autenticación.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [SEC02-BP06 Uso de grupos y atributos de usuarios](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_groups_attributes.html)
+ [SEC03-BP02 Concesión de acceso con privilegios mínimos](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_least_privileges.html)
+ [SEC03-BP06 Administración del acceso en función del ciclo de vida](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_lifecycle.html)
**Documentos relacionados:**
+ [Federación de identidades en AWS](https://aws.amazon.com/identity/federation/)
+ [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) (Prácticas recomendadas de seguridad en IAM)
+ [Prácticas recomendadas de AWS Identity and Access Management](https://aws.amazon.com/iam/resources/best-practices/)
+ [Getting started with IAM Identity Center delegated administration](https://aws.amazon.com/blogs/security/getting-started-with-aws-sso-delegated-administration/)
+ [How to use customer managed policies in IAM Identity Center for advanced use cases](https://aws.amazon.com/blogs/security/how-to-use-customer-managed-policies-in-aws-single-sign-on-for-advanced-use-cases/)
+ [AWS CLI v2: proveedor de credenciales de IAM Identity Center](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sso-credentials.html)
**Videos relacionados:**
+ [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive](https://youtu.be/YMj33ToS8cI)
+ [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center](https://youtu.be/TvQN4OdR_0Y)
+ [AWS re:Invent 2018: Mastering Identity at Every Layer of the Cake](https://youtu.be/vbjFjMNVEpc)
**Ejemplos relacionados:**
+ [Workshop: Using AWS IAM Identity Center to achieve strong identity management](https://catalog.us-east-1.prod.workshops.aws/workshops/590f8439-42c7-46a1-8e70-28ee41498b3a/en-US)
**Herramientas relacionadas:**
+ [Socios con competencia en seguridad de AWS: Identity and Access Management](https://aws.amazon.com/security/partner-solutions/)
+ [saml2aws](https://github.com/Versent/saml2aws)
# SEC02-BP05 Auditoría y rotación periódicas de las credenciales
Audite y rote las credenciales periódicamente para limitar el tiempo que pueden utilizarse para acceder a los recursos. Las credenciales de larga duración entrañan muchos riesgos, pero estos riesgos pueden reducirse con una rotación frecuente.
**Resultado deseado:** implemente la rotación de credenciales para ayudar a reducir los riesgos asociados al uso de credenciales a largo plazo. Audita regularmente y corrige la no conformidad con las políticas de rotación de credenciales.
**Patrones comunes de uso no recomendados:**
+ No auditar el uso de credenciales.
+ Utilizar credenciales de larga duración de forma innecesaria.
+ Utilizar credenciales de larga duración y no rotarlas regularmente.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Cuando no pueda confiar en credenciales temporales y necesite credenciales de larga duración, audítelas para verificar que los controles definidos, por ejemplo, la [autenticación multifactor](https://aws.amazon.com/iam/features/mfa/) (MFA), se aplican, se rotan periódicamente y tienen el nivel de acceso adecuado.
Es necesario llevar a cabo una validación periódica, preferiblemente mediante una herramienta automatizada, para verificar que se están aplicando los controles correctos. En el caso de las identidades humanas, debe exigir a los usuarios que cambien sus contraseñas periódicamente y retirar las claves de acceso para sustituirlas por credenciales temporales. Al pasar de usuarios de AWS Identity and Access Management (IAM) a identidades centralizadas, puede [generar un informe de credenciales](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html) para auditar a los usuarios.
También recomendamos que aplique y supervise una configuración de MFA en su proveedor de identidades. Puede configurar [Reglas de AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) o utilizar [estándares de seguridad de AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html#fsbp-iam-3) para supervisar si los usuarios han configurado la MFA. Si lo considera oportuno, puede utilizar [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) para proporcionar credenciales temporales para identidades de máquinas. En situaciones en las que no sea posible utilizar roles de IAM y credenciales temporales, es necesario llevar a cabo auditorías frecuentes y rotar las claves de acceso.
### Pasos para la implementación
+ **Auditoría periódica de las credenciales:** auditar las identidades que están configuradas en el proveedor de identidades e IAM le permite asegurarse de que las únicas identidades que pueden acceder a su carga de trabajo son aquellas que estén autorizadas. Dichas identidades pueden incluir, entre otras, usuarios de IAM, usuarios de AWS IAM Identity Center, usuarios de Active Directory o usuarios de un proveedor de identidades ascendente diferente. Por ejemplo, elimine las personas que abandonen la organización y los roles entre cuentas que ya no sean necesarios. Implante un proceso para auditar periódicamente los permisos a los servicios a los que accede una entidad de IAM. Esto le ayudará a identificar las políticas que debe modificar para eliminar los permisos que no se utilizan. Utilice los informes de credenciales e [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) para auditar las credenciales y los permisos de IAM. Puede usar [Amazon CloudWatch para configurar alarmas para llamadas específicas a las API](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html) dentro de su entorno de AWS. [Además, Amazon GuardDuty puede avisarle de una actividad inesperada](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html), que podría indicar un acceso demasiado permisivo o no intencionado a las credenciales de IAM.
+ **Rotación periódica de las credenciales:** si no puede utilizar credenciales temporales, rote periódicamente las claves de acceso a IAM de larga duración (como máximo cada 90 días). Si se revela una clave de acceso de forma involuntaria sin su conocimiento, esto limita el tiempo durante el que se pueden utilizar las credenciales para acceder a los recursos. Si desea obtener información sobre la rotación de las claves de acceso de los usuarios de IAM, consulte [Rotación de las claves de acceso](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey).
+ **Revisión de los permisos de IAM:** para mejorar la seguridad de su Cuenta de AWS, debe revisar y supervisar periódicamente cada una de sus políticas de IAM. Verifique que las políticas sigan el principio del privilegio mínimo.
+ **Si lo estima oportuno, puede automatizar la creación y las actualizaciones de los recursos de IAM:** [IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) automatiza muchas tareas de IAM, como la administración de roles y políticas. Como alternativa, se puede utilizar AWS CloudFormation para automatizar la implementación de los recursos de IAM, incluidos los roles y las políticas, para reducir la posibilidad de que se produzcan errores humanos, ya que las plantillas se pueden verificar y controlar por versiones.
+ **Uso de IAM Roles Anywhere para sustituir los usuarios de IAM por identidades de máquinas:** [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) le permite utilizar roles en áreas que antes no podía utilizar, como en servidores locales. IAM Roles Anywhere utiliza un [certificado X.509](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/trust-model.html#signature-verification) de confianza para autenticarse en AWS y recibir credenciales temporales. El uso de IAM Roles Anywhere evita la necesidad de rotar estas credenciales, ya que las credenciales de larga duración ya no se almacenan en el entorno en las instalaciones. Tenga en cuenta que deberá supervisar y rotar el certificado X.509 a medida que se acerque su fecha de vencimiento.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [SEC02-BP02 Uso de credenciales temporales](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC02-BP03 Almacenamiento y uso seguros de secretos](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html)
**Documentos relacionados:**
+ [Introducción a AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html)
+ [Prácticas recomendadas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Federación y proveedores de identidades](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)
+ [Soluciones de socios de seguridad: acceso y control de acceso](https://aws.amazon.com/security/partner-solutions/#access-control)
+ [Credenciales de seguridad temporales](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
+ [ Generación de informes de credenciales para su Cuenta de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)
**Videos relacionados:**
+ [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale](https://youtu.be/qoxxRlwJKZ4)
+ [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E)
+ [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC02-BP06 Uso de grupos y atributos de usuarios
Definir los permisos según los grupos y los atributos de usuarios ayuda a reducir la cantidad y la complejidad de las políticas, lo que facilita la aplicación del principio de privilegio mínimo. Puede emplear los grupos de usuarios para administrar los permisos de muchas personas en un solo lugar según la función que desempeñen en su organización. Los atributos, como el departamento, el proyecto o la ubicación, pueden proporcionar un nivel adicional en el ámbito de los permisos si hay personas que hacen una función similar, pero para diferentes subconjuntos de recursos.
**Resultado deseado:** puede aplicar cambios en los permisos según la función a todos los usuarios que desempeñen esa función. La pertenencia a grupos y los atributos determinan los permisos de los usuarios, lo que reduce la necesidad de administrar los permisos para cada usuario individual. Los grupos y atributos que defina en su proveedor de identidades (IdP) se propagan automáticamente a sus entornos de AWS.
**Patrones comunes de uso no recomendados:**
+ Administrar los permisos de usuarios individuales y duplicarlos para muchos usuarios.
+ Definir grupos en un nivel demasiado alto y conceder permisos demasiado amplios.
+ Definir grupos en un nivel demasiado detallado, lo que crea duplicación y confusión en torno a la pertenencia a dichos grupos.
+ Usar grupos con permisos duplicados en diversos subconjuntos de recursos cuando, en su lugar, se pueden usar atributos.
+ No administrar grupos, atributos y pertenencias a grupos con un proveedor de identidades estandarizado integrado con sus entornos de AWS.
+ Usar encadenamiento de roles al utilizar las sesiones del AWS IAM Identity Center.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
Los permisos de AWS se definen en documentos denominados *políticas* que están asociados a una entidad principal, como un usuario, grupo, rol o recurso. Puede escalar la gestión de permisos organizando las asignaciones de permisos (grupo, permisos o cuenta) dependiendo de la función del trabajo, la carga de trabajo y el entorno de SDLC. En el caso de su plantilla, esto le permite definir grupos según la función que desempeñen los usuarios en su organización, en lugar de en virtud de los recursos a los que se accede. Por ejemplo, un grupo de desarrolladores de aplicaciones web puede tener una política adjunta para configurar servicios como Amazon CloudFront dentro de una cuenta de desarrollo. Es posible que un grupo de `AutomationDeveloper` tenga algunos permisos que coincidan con los del grupo de `WebAppDeveloper`. Estos permisos pueden recopilarse en una política independiente y asociarse a ambos grupos, en lugar de permitir que los usuarios de ambas funciones pertenezcan a un grupo de `CloudFrontAccess`.
Además de los grupos, puede utilizar *atributos* para ampliar el acceso al ámbito. Por ejemplo, puede tener un atributo Proyecto para los usuarios del grupo de `WebAppDeveloper` para limitar el acceso a los recursos específicos de su proyecto. El uso de esta técnica elimina la necesidad de tener diferentes grupos para los desarrolladores de aplicaciones que trabajen en diferentes proyectos si, por lo demás, sus permisos son los mismos. La forma de hacer referencia a los atributos en las políticas de permisos se basa en su origen, ya sea que estén definidos como parte de su protocolo de federación (como SAML, OIDC o SCIM), como aserciones SAML personalizadas o que se hayan configurado en IAM Identity Center.
### Pasos para la implementación
1. Establezca dónde definirá los grupos y los atributos:
1. Al seguir las instrucciones que se indican en [SEC02-BP04 Uso de un proveedor de identidades centralizado](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html), puede determinar si tiene que definir grupos y atributos en el proveedor de identidades, en IAM Identity Center o usar grupos de usuarios de IAM en una cuenta específica.
1. Defina grupos:
1. Determine los grupos según la función y el ámbito del acceso requerido. Puede utilizar una estructura jerárquica o convenciones de nomenclatura para organizar los grupos de forma eficaz.
1. Si especifica la definición en IAM Identity Center, cree grupos y asocie el nivel de acceso deseado mediante conjuntos de permisos.
1. Si especifica la definición con un proveedor de identidades externo, determine si el proveedor admite el protocolo SCIM y plantéese la posibilidad de habilitar el aprovisionamiento automático en IAM Identity Center. Esta capacidad sincroniza la creación, la pertenencia y la eliminación de grupos entre su proveedor e IAM Identity Center.
1. Defina los atributos:
1. Si utiliza un proveedor de identidades externo, los protocolos SCIM y SAML 2.0 proporcionan ciertos atributos de forma predeterminada. Los atributos adicionales se pueden definir y transferir mediante aserciones de SAML que utilizan el nombre del atributo `https://aws.amazon.com/SAML/Attributes/PrincipalTag`. Consulte la documentación de su proveedor de identidades a fin de conocer las instrucciones necesarias para definir y configurar atributos personalizados.
1. Si define roles en IAM Identity Center, active la característica de control de acceso basado en atributos (ABAC) y defina los atributos como desee. Debería usar atributos que vayan en consonancia con la estructura o la estrategia de etiquetado de recursos de su organización.
Si necesita encadenar los roles de IAM a partir de los roles de IAM asumidos a través del centro de identidad de IAM, los valores como `source-identity` y `principal-tags` no se propagarán. Para obtener información más detallada, consulte [Habilitación y configuración de atributos para el control de acceso](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html).
1. Los permisos de ámbito se basan en grupos y atributos:
1. Plantéese la posibilidad de incluir condiciones en las políticas de permisos que comparen los atributos de su entidad principal con los atributos de los recursos a los que se accede. Por ejemplo, puede definir una condición para permitir el acceso a un recurso solo si el valor de una clave de condición `PrincipalTag` coincide con el valor de una clave `ResourceTag` del mismo nombre.
1. Al definir las políticas de la ABAC, siga las instrucciones de las prácticas recomendadas y ejemplos de [autorización de la ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html).
1. Revise y actualice periódicamente su estructura de grupos y atributos a medida que evolucionen las necesidades de su organización para garantizar una gestión óptima de los permisos.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [SEC02-BP04 Uso de un proveedor de identidades centralizado](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)
+ [SEC03-BP02 Concesión de acceso con privilegios mínimos](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_least_privileges.html)
+ [COST02-BP04 Implementación de grupos y roles](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_groups_roles.html)
**Documentos relacionados:**
+ [Prácticas recomendadas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Manage Identities in IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html)
+ [What Is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [ABAC In IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html)
+ [Ejemplos de políticas ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_abac.html)
**Videos relacionados:**
+ [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E)
+ [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC 3. ¿Cómo se gestionan los permisos de las personas y las máquinas?
Administre permisos para controlar el acceso a identidades humanas y de máquinas que requieran acceso a AWS y sus cargas de trabajo. Los permisos le permiten controlar a qué puede acceder cada usuario y en qué condiciones. Al establecer permisos para identidades específicas humanas y de máquinas, concede acceso a acciones de servicio específicas en determinados recursos. Asimismo, puede especificar condiciones que deben cumplirse para que se conceda el acceso.
**Topics**
+ [SEC03-BP01 Definición de los requisitos de acceso](sec_permissions_define.md)
+ [SEC03-BP02 Concesión de acceso con privilegios mínimos](sec_permissions_least_privileges.md)
+ [SEC03-BP03 Establecimiento de un proceso de acceso de emergencia](sec_permissions_emergency_process.md)
+ [SEC03-BP04 Reducción continua de los permisos](sec_permissions_continuous_reduction.md)
+ [SEC03-BP05 Definición de las barreras de protección de los permisos para una organización](sec_permissions_define_guardrails.md)
+ [SEC03-BP06 Administración del acceso en función del ciclo de vida](sec_permissions_lifecycle.md)
+ [SEC03-BP07 Análisis del acceso público y entre cuentas](sec_permissions_analyze_cross_account.md)
+ [SEC03-BP08 Uso compartido de recursos de forma segura en su organización](sec_permissions_share_securely.md)
+ [SEC03-BP09 Uso compartido seguro de recursos con terceros](sec_permissions_share_securely_third_party.md)
# SEC03-BP01 Definición de los requisitos de acceso
Los administradores, los usuarios finales u otros componentes deben acceder a cada componente o recurso de la carga de trabajo. Establezca una definición clara de quién o qué debe tener acceso a cada componente y elija el tipo de identidad y el método de autenticación y autorización adecuados.
**Patrones comunes de uso no recomendados:**
+ Codificar de forma rígida o almacenar secretos en la aplicación.
+ Conceder permisos personalizados para cada usuario.
+ Utilizar credenciales de larga duración.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Los administradores, los usuarios finales u otros componentes deben acceder a cada componente o recurso de la carga de trabajo. Establezca una definición clara de quién o qué debe tener acceso a cada componente y elija el tipo de identidad y el método de autenticación y autorización adecuados.
El acceso periódico a las Cuentas de AWS dentro de una organización debe proporcionarse mediante [acceso federado](https://aws.amazon.com/identity/federation/) o un proveedor de identidades centralizado. También debe centralizar la administración de identidades y asegurarse de que existe una práctica establecida para integrar el acceso de AWS al ciclo de vida de los empleados. Por ejemplo, cuando un empleado cambia a un cargo con un nivel de acceso distinto, su pertenencia al grupo también debe cambiar para reflejar los nuevos requisitos de acceso.
Al definir los requisitos de acceso para las identidades que no son humanas, determine qué aplicaciones y componentes necesitan acceso y cómo se conceden los permisos. El enfoque recomendado es utilizar roles de IAM creados con el modelo de acceso de privilegio mínimo. [AWS Las políticas administradas](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html) proporcionan políticas de IAM predefinidas que cubren los casos de uso más comunes.
Los servicios de AWS, como [AWS Secrets Manager](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/) y el [Almacén de parámetros de AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html), pueden ayudar a desvincular los secretos de la aplicación o la carga de trabajo de forma segura. En Secrets Manager, puede establecer una rotación automática de las credenciales. Puede utilizar Systems Manager para hacer referencia a los parámetros en los scripts, comandos, documentos SSM, configuración y flujos de trabajo de automatización con el nombre único que especificó al crear el parámetro.
Puede utilizar [AWS IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) para obtener [credenciales de seguridad temporales en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) para cargas de trabajo que se ejecutan fuera de AWS. Las cargas de trabajo pueden usar las mismas [políticas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) y [roles de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que utiliza con las aplicaciones de AWS para acceder a los recursos de AWS.
Siempre que sea posible, se deben preferir las credenciales temporales a corto plazo en lugar de las credenciales estáticas a largo plazo. En aquellas situaciones en las que necesite usuarios con acceso programático y credenciales de larga duración, utilice la [información de la última clave de acceso utilizada](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) para rotar y eliminar las claves de acceso.
Los usuarios necesitan acceso programático si desean interactuar con AWS fuera de la Consola de administración de AWS. La forma de conceder el acceso programático depende del tipo de usuario que acceda a AWS.
Para conceder acceso programático a los usuarios, seleccione una de las siguientes opciones.
****
| ¿Qué usuario necesita acceso programático? | Para | Mediante |
| --- | --- | --- |
| IAM | (Recomendado) Use credenciales de consola como credenciales temporales para firmar las solicitudes programáticas a la AWS CLI, los AWS SDK y las API de AWS. | Siga las instrucciones de la interfaz que desea utilizar: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/framework/sec_permissions_define.html) |
| Identidad del personal (Usuarios administrados en el IAM Identity Center) | Utiliza credenciales temporales para firmar las solicitudes programáticas a la AWS CLI, los AWS SDK y las API de AWS. | Siga las instrucciones de la interfaz que desea utilizar: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/framework/sec_permissions_define.html) |
| IAM | Utiliza credenciales temporales para firmar las solicitudes programáticas a la AWS CLI, los AWS SDK y las API de AWS. | Siguiendo las instrucciones de [Uso de credenciales temporales con recursos de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html) de la Guía del usuario de IAM. |
| IAM | (No recomendado)Utilizar credenciales a largo plazo para firmar las solicitudes programáticas a la AWS CLI, los AWS SDK o las API de AWS. | Siga las instrucciones de la interfaz que desea utilizar: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/framework/sec_permissions_define.html) |
## Recursos
**Documentos relacionados:**
+ [Control de acceso basado en atributos (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/)
+ [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)
+ [AWS Managed policies for IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html)
+ [AWS IAM policy conditions](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)
+ [IAM use cases](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UseCases.html)
+ [Revisar y eliminar periódicamente usuarios, roles, permisos, políticas y credenciales no utilizados](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials)
+ [Uso de políticas de](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)
+ [How to control access to AWS resources based on Cuenta de AWS, OU, or organization](https://aws.amazon.com/blogs/security/how-to-control-access-to-aws-resources-based-on-aws-account-ou-or-organization/)
+ [Identify, arrange, and manage secrets easily using enhanced search in AWS Secrets Manager](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/)
**Videos relacionados:**
+ [Become an IAM Policy Master in 60 Minutes or Less](https://youtu.be/YQsK4MtsELU)
+ [Separation of Duties, Least Privilege, Delegation, and CI/CD](https://youtu.be/3H0i7VyTu70)
+ [Streamlining identity and access management for innovation](https://www.youtube.com/watch?v=3qK0b1UkaE8)
# SEC03-BP02 Concesión de acceso con privilegios mínimos
Conceda exclusivamente el acceso que las identidades necesitan para efectuar acciones concretas en recursos específicos en determinadas condiciones. Utilice atributos de grupo y de identidad para configurar dinámicamente los permisos en función de las necesidades en lugar de configurarlos para cada usuario. Por ejemplo, puede conceder acceso a un grupo de desarrolladores para que solamente puedan administrar recursos de su proyecto. De este modo, si un desarrollador abandona el proyecto, su acceso se revoca automáticamente sin cambiar las políticas de acceso subyacentes.
**Resultado deseado:** los usuarios solo tienen los permisos mínimos necesarios para el trabajo específico que desempeñan. Utiliza Cuentas de AWS independientes para aislar a los desarrolladores de los entornos de producción. Cuando los desarrolladores necesitan acceder a los entornos de producción para realizar tareas específicas, solo se les concede un acceso limitado y controlado durante el tiempo que se necesita para esas tareas. Su acceso a la producción se revoca inmediatamente después de completar el trabajo necesario. Realiza revisiones periódicas de los permisos y los revoca de inmediato cuando ya no son necesarios; por ejemplo, cuando un usuario cambia de rol o deja la organización. Restringe los privilegios de administrador a un grupo pequeño y de confianza para reducir la exposición al riesgo. Concede a las cuentas de máquinas o sistemas los permisos mínimos necesarios para realizar las tareas previstas.
**Patrones comunes de uso no recomendados:**
+ Concede permisos de administrador a los usuarios de forma predeterminada.
+ Utiliza la cuenta de usuario raíz para tareas cotidianas.
+ Crea políticas demasiado permisivas sin un alcance adecuado.
+ Revisa sus permisos con poca frecuencia, lo que provoca un aumento excesivo de los permisos.
+ Aísla el entorno o gestiona los permisos basándose exclusivamente en un control de acceso basado en atributos.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
El principio del [privilegio mínimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) establece que a las identidades solo se les debe permitir llevar a cabo el conjunto más reducido de acciones necesarias para efectuar una tarea específica. De este modo, se equilibra la facilidad de uso, la eficiencia y la seguridad. Operar según este principio contribuye a limitar el acceso involuntario y a hacer el seguimiento de quién tiene acceso a determinados recursos. Los usuarios y los roles de IAM no tienen permisos de forma predeterminada. De forma predeterminada, el usuario raíz tiene acceso total y debe controlarse y supervisarse rigurosamente, y utilizarse únicamente para [las tareas que requieren acceso raíz](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html).
Las políticas de IAM se usan para conceder permisos a roles de IAM o recursos específicos. Por ejemplo, las políticas basadas en la identidad se pueden adjuntar a grupos de IAM, mientras que los buckets de S3 se pueden controlar mediante políticas basadas en recursos.
Al crear una política de IAM, puede especificar las acciones de servicio, los recursos y las condiciones que se deben cumplir para que AWS permita o deniegue el acceso. AWS es compatible con una amplia variedad de condiciones que lo ayudarán a acotar el acceso. Por ejemplo, al usar la [clave de condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) PrincipalOrgID, puede denegar acciones si el solicitante no forma parte de su organización de AWS.
También puede controlar las solicitudes que hagan los servicios de AWS en su nombre, como que AWS CloudFormation cree una función de AWS Lambda, mediante la clave de condición CalledVia. Puede estratificar los diferentes tipos de políticas para establecer una defensa en profundidad y limitar los permisos generales de sus usuarios. También puede restringir qué permisos se pueden conceder y en qué condiciones. Por ejemplo, puede permitir que sus equipos de carga de trabajo creen sus propias políticas de IAM para los sistemas que creen, pero solo si aplican también un [límite de permisos](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) para determinar el número máximo de permisos que el sistema puede recibir.
### Pasos para la implementación
+ **Implementación de políticas de privilegio mínimo**: asigne políticas de acceso con privilegio mínimo a los grupos y roles de IAM para reflejar el rol o la función del usuario que haya definido.
+ **Aísle los entornos de desarrollo y de producción separando las Cuentas de AWS**: utilice Cuentas de AWS distintas para los entornos de desarrollo y los de producción y controle el acceso entre ellos mediante políticas de [control de servicios](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html), políticas de recursos y políticas de identidad.
+ **Uso de las API como base de las políticas**: una forma de determinar los permisos necesarios consiste en revisar los registros de AWS CloudTrail. Esta revisión le permite crear permisos adaptados a las acciones que el usuario lleva a cabo en AWS. El [Analizador de acceso de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) puede [generar automáticamente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) una política de IAM basada en la actividad de acceso. Puede utilizar el asesor de acceso de IAM en la organización o en la cuenta para [hacer un seguimiento de la información a la que se accedió por última vez en relación con una política concreta](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html).
+ **Puede usar [políticas administradas por AWS para funciones de trabajo](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)**: cuando empiece a crear políticas de permisos detalladas, puede ser útil usar políticas administradas por AWS para funciones de trabajo comunes, como facturación, administradores de bases de datos y científicos de datos. Estas políticas pueden servir para limitar el acceso que tienen los usuarios al mismo tiempo que se determina cómo implementar las políticas de privilegio mínimo.
+ **Elimine los permisos innecesarios:** detecte y elimine las entidades, credenciales y permisos de IAM no utilizados para cumplir con el principio de privilegios mínimos. Puede utilizar [Analizador de acceso de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html) para identificar el acceso externo y el no utilizado, y la [generación de políticas de Analizador de acceso de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) puede ayudar a afinar las políticas de permisos.
+ **Garantía de que los usuarios tengan un acceso limitado a los entornos de producción:** los usuarios solo deben tener acceso a los entornos de producción con un caso de uso válido. Después de que el usuario lleve a cabo las tareas específicas que requieren el acceso a producción, se debe revocar el acceso. La limitación del acceso a los entornos de producción previene los eventos involuntarios que afectan a la producción y reduce el ámbito de las consecuencias del acceso involuntario.
+ **Plantéese utilizar límites de permisos**: un [límite de permisos](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) es una característica avanzada que permite utilizar una política administrada para establecer los permisos máximos que una política basada en identidades puede conceder a una entidad de IAM. Un límite de permisos para una entidad le posibilita realizar las acciones que le permitan tanto sus políticas basadas en identidad como sus límites de permisos.
+ **Limite el acceso mediante el control de acceso basado en atributos y las etiquetas de recursos**: el [control de acceso basado en atributos (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) que utiliza etiquetas de recursos se puede utilizar para refinar los permisos cuando es compatible. Puede utilizar un modelo ABAC que compare las etiquetas principales con las etiquetas de recursos para refinar el acceso en función de las dimensiones personalizadas que defina. Este método puede simplificar y reducir la cantidad de políticas de permisos en su organización.
+ Se recomienda utilizar ABAC únicamente para el control de accesos cuando tanto las entidades principales como los recursos sean propiedad de su organización de AWS. Las partes externas pueden usar los mismos nombres y valores de etiqueta que su organización para sus propias entidades principales y recursos. Si concede acceso a las entidades principales o los recursos de terceros basándose únicamente en estos pares de nombre-valor, podría conceder permisos que no desea conceder.
+ **Utilizar políticas de control de servicios para AWS Organizations**: las [políticas de control de servicios](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) controlan de forma centralizada el máximo de permisos disponibles para las cuentas de los miembros de su organización. Es importante destacar que puede utilizar las políticas de control de servicios para restringir los permisos del usuario raíz en las cuentas de los miembros. Considere también la posibilidad de utilizar AWS Control Tower, que proporciona controles prescriptivos administrados que enriquecen AWS Organizations. También puede definir sus propios controles en Control Tower.
+ **Establecimiento de una política de ciclo de vida de los usuarios para su organización:** las políticas de ciclo de vida de los usuarios definen las tareas que deben llevarse a cabo cuando los usuarios se incorporan a AWS, cuando cambian de rol o ámbito de trabajo, o cuando ya no necesitan acceder a AWS. Realice revisiones de permisos en cada paso del ciclo de vida de un usuario para verificar si son restrictivos de forma correcta y para evitar la acumulación de permisos.
+ **Establecimiento de una programación periódica para revisar los permisos y eliminar los que no sean necesarios:** debe revisar periódicamente el acceso de los usuarios para comprobar que no tengan un acceso demasiado permisivo. [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) y el Analizador de acceso de IAM pueden ayudarlo durante las auditorías de permisos.
+ **Establecimiento de una matriz de roles de trabajo:** una matriz de roles de trabajo permite visualizar las distintas funciones y niveles de acceso necesarios en su entorno de AWS. Con una matriz de roles de trabajo, puede definir y separar los permisos según las responsabilidades de usuario en su organización. Utilice grupos en lugar de aplicar los permisos directamente a los usuarios o roles individuales.
## Recursos
**Documentos relacionados:**
+ [Aplicar permisos de privilegios mínimos](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
+ [Límites de permisos para las entidades de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)
+ [Techniques for writing least privilege IAM policies](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/)
+ [IAM Access Analyzer makes it easier to implement least privilege permissions by generating IAM policies based on access activity](https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/)
+ [Delegate permission management to developers by using IAM permissions boundaries](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/)
+ [Perfeccionar los permisos con la información sobre los últimos accesos](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)
+ [Tipos de políticas de IAM y cuándo usarlas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)
+ [Probar las políticas de IAM con el simulador de política de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html)
+ [Guardrails in AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)
+ [Zero Trust architectures: An AWS perspective](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/)
+ [How to implement the principle of least privilege with CloudFormation StackSets](https://aws.amazon.com/blogs/security/how-to-implement-the-principle-of-least-privilege-with-cloudformation-stacksets/)
+ [Control de acceso basado en atributos (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [Reducción del ámbito de las políticas mediante la consulta de la actividad de los usuarios](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)
+ [Visualización del acceso a los roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_delete.html)
+ [Utilizar el etiquetado para organizar el entorno e impulsar la responsabilidad](https://docs.aws.amazon.com/aws-technical-content/latest/cost-optimization-laying-the-foundation/tagging.html)
+ [AWS Tagging Strategies](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)
+ [Etiquetado de recursos de AWS](https://aws.amazon.com/premiumsupport/knowledge-center/tagging-resources/)
**Videos relacionados:**
+ [Next-generation permissions management](https://www.youtube.com/watch?v=8vsD_aTtuTo)
+ [Zero Trust: An AWS perspective](https://www.youtube.com/watch?v=1p5G1-4s1r0)
# SEC03-BP03 Establecimiento de un proceso de acceso de emergencia
Cree un proceso que permita el acceso de emergencia a sus cargas de trabajo en el caso improbable de que se produzca un problema con su proveedor de identidades centralizado.
Debe diseñar procesos para diferentes modos de error que puedan provocar un evento de emergencia. Por ejemplo, en circunstancias normales, los usuarios de la plantilla se federan en la nube mediante un proveedor de identidades centralizado ([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)) para administrar sus cargas de trabajo. Sin embargo, si su proveedor de identidades centralizado no responde o se modifica la configuración de la federación en la nube, es posible que los usuarios de la plantilla no puedan federarse en esta. Un proceso de acceso de emergencia permite a los administradores autorizados acceder a los recursos de la nube a través de medios alternativos (como una forma alternativa de federación o acceso directo de los usuarios) para solucionar problemas con la configuración de la federación o las cargas de trabajo. El proceso de acceso de emergencia se utiliza hasta que se restablezca el mecanismo de federación normal.
**Resultado deseado:**
+ Ha definido y documentado los modos de error que se consideran una emergencia: tenga en cuenta sus circunstancias normales y los sistemas de los que dependen los usuarios para administrar sus cargas de trabajo. Considere cómo cada una de estas dependencias puede no funcionar y provocar una situación de emergencia. Es posible que las preguntas y las prácticas recomendadas del [pilar de fiabilidad](https://docs.aws.amazon.com/wellarchitected/latest/framework/a-reliability.html) resulten útiles para identificar los modos de error y diseñar sistemas más resilientes para minimizar la probabilidad de errores.
+ Ha documentado los pasos que se deben seguir para confirmar que el error se trata de un caso de emergencia. Por ejemplo, puede solicitar a sus administradores de identidades que comprueben el estado de sus proveedores de identidades principales y en espera y, si ninguno estuviera disponible, declarar un evento de emergencia por error en el proveedor de identidades.
+ Ha definido un proceso de acceso de emergencia concreto para cada tipo de modo de emergencia o error. La especificidad puede reducir la tentación de los usuarios de abusar de un proceso general para todo tipo de emergencias. Los procesos de acceso de emergencia describen las circunstancias en las que se debe utilizar cada proceso y, por otra parte, las situaciones en las que no se debe utilizar el proceso y señala los procesos alternativos que podrían aplicarse.
+ Sus procesos están bien documentados con instrucciones detalladas y manuales de estrategias que se pueden seguir de forma rápida y eficiente. Recuerde que un evento de emergencia puede resultar estresante para sus usuarios, ya que pueden estar sometidos a una fuerte presión de plazos, por lo que debe diseñar su proceso de la manera más sencilla posible.
**Patrones comunes de uso no recomendados:**
+ No tiene procesos de acceso de emergencia bien documentados y probados. Cuando los usuarios no están preparados para emergencias, siguen procesos improvisados cuando estas se producen.
+ Tener procesos de acceso de emergencia que dependan de los mismos sistemas (como un proveedor de identidades centralizado) que sus mecanismos de acceso normales. Esto significa que el error de un sistema de este tipo podría afectar tanto a sus mecanismos de acceso normales como a los de emergencia y, por lo tanto, repercutir en la capacidad para recuperarse del error.
+ Se utilizan los procesos de acceso de emergencia en situaciones que no son de emergencia. Por ejemplo, los usuarios suelen hacer un uso inapropiado de los procesos de acceso de emergencia, ya que les resulta más fácil hacer cambios directamente que enviarlos a través de una canalización.
+ Tener procesos de acceso de emergencia que no generan registros suficientes para auditar los procesos o no supervisar los registros para alertar de un posible uso indebido de los procesos.
**Beneficios de establecer esta práctica recomendada:**
+ Contar con procesos de acceso de emergencia bien documentados y probados puede reducir el tiempo que tardan los usuarios en responder y resolver un evento de emergencia. Esto puede reducir el tiempo de inactividad y aumentar la disponibilidad de los servicios que presta a sus clientes.
+ Puede hacer un seguimiento de cada solicitud de acceso de emergencia y detectar intentos no autorizados de uso indebido de los procesos para eventos que no sean de emergencia y alertar sobre estos.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada**: medio
## Guía para la implementación
Esta sección proporciona guías para crear procesos de acceso de emergencia para varios modos de error relacionados con las cargas de trabajo implementadas en AWS, comenzando con una guía común que se aplica a todos los modos de error y siguiendo con una guía específica basada en el tipo de modo de error.
**Guía común para todos los modos de error**
Tenga en cuenta lo siguiente al diseñar un proceso de acceso de emergencia para un modo de error:
+ Documente las condiciones previas y los supuestos del proceso, es decir, cuándo el proceso debe o no debe aplicarse. Esto ayuda a detallar el modo de error y a documentar los supuestos, como el estado de otros sistemas relacionados. Por ejemplo, el proceso del modo de error 2 da por sentado que el proveedor de identidades está disponible, pero que la configuración activada en AWS se ha modificado o ha caducado.
+ Cree de antemano los recursos necesarios para el proceso de acceso de emergencia ([SEC10-BP05](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_pre_provision_access.html)). Por ejemplo, cree de antemano el acceso de emergencia a la Cuenta de AWS con roles y usuarios de IAM, y los roles de IAM entre cuentas en todas las cuentas de la carga de trabajo. Esto asegurará que estos recursos estén listos y disponibles cuando ocurra una emergencia. Al crear previamente los recursos, no dependerá de las API del [plano de control](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/control-planes-and-data-planes.html) de AWS (que se utilizan para crear y modificar recursos de AWS) que pueden no estar disponibles en caso de emergencia. Además, al crear previamente los recursos de IAM, no es necesario tener en cuenta los [posibles retrasos debidos a una posible coherencia.](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency)
+ Incluya los procesos de acceso de emergencia como parte de sus planes de administración de incidentes ([SEC10-BP02](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_develop_management_plans.html)). Documente cómo se hace el seguimiento de los eventos de emergencia y cómo se comunican a otros miembros de su organización, como los equipos de compañeros o la dirección y, cuando corresponda, externamente a sus clientes y socios comerciales.
+ Defina el proceso de solicitud de acceso de emergencia en su sistema de flujo de trabajo de solicitudes de servicio existente, si dispone de uno. Por lo general, estos sistemas de flujo de trabajo le permiten crear formularios de entrada para recopilar información sobre la solicitud, hacer un seguimiento de la solicitud en cada etapa del flujo de trabajo y agregar pasos de aprobación automatizados y manuales. Relacione cada solicitud con el correspondiente evento de emergencia registrado en su sistema de administración de incidentes. Disponer de un sistema uniforme para los accesos de emergencia le permite hacer un seguimiento de esas solicitudes en un solo sistema, analizar las tendencias de uso y mejorar sus procesos.
+ Compruebe que solo los usuarios autorizados puedan iniciar los procesos de acceso de emergencia y que estos procesos requieran la aprobación de los compañeros del usuario o de la dirección, según corresponda. El proceso de aprobación debe funcionar de manera eficaz, tanto dentro como fuera del horario laboral. Defina cómo admiten las solicitudes de aprobación aprobadores secundarios si los principales no están disponibles y cómo se escalan en la cadena de administración hasta la aprobación.
+ Implemente mecanismos sólidos de registro, monitoreo y alerta para el proceso y los mecanismos de acceso de emergencia. Genere registros y eventos de auditoría detallados para los intentos correctos e infructuosos de obtener acceso de emergencia. Correlacione la actividad con los eventos de emergencia en curso de su sistema de administración de incidentes e inicie alertas cuando se produzcan acciones fuera de los periodos de tiempo esperados o cuando se use la cuenta de acceso de emergencia durante las operaciones normales. Solo se debe acceder a la cuenta de acceso de emergencia durante las emergencias, ya que los procedimientos acceso excepcional pueden considerarse una puerta trasera. Intégrela con su herramienta de gestión de eventos e información de seguridad (SIEM) o [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) para informar y auditar todas las actividades durante el periodo de acceso de emergencia. Al volver al funcionamiento normal, cambie automáticamente las credenciales de acceso de emergencia y avise a los equipos pertinentes.
+ Pruebe los procesos de acceso de emergencia de manera periódica para verificar que los pasos estén claros y garantizar el nivel de acceso correcto de manera rápida y eficiente. Sus procesos de acceso de emergencia deben probarse como parte de las simulaciones de respuesta a incidentes ([SEC10-BP07](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_run_game_days.html)) y las pruebas de recuperación de desastres ([REL13-BP03](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)).
**Modo de error 1: el proveedor de identidades utilizado para federarse en AWS no está disponible**
Tal como se describe en [SEC02-BP04 Uso de un proveedor de identidades centralizado](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html), recomendamos confiar en un proveedor de identidades centralizado para federar a los usuarios de su plantilla y concederles acceso a las Cuentas de AWS. La federación se puede configurar a varias Cuentas de AWS de su organización de AWS con IAM Identity Center, o bien puede configurar la federación a Cuentas de AWS individuales mediante IAM. En ambos casos, los usuarios de la plantilla se autentican con su proveedor de identidades centralizado antes de que se les redirija a un punto de conexión de inicio de sesión de AWS para el inicio de sesión único.
En el caso poco probable de que su proveedor de identidades centralizado no esté disponible, los usuarios de la plantilla no podrán federarse en las Cuentas de AWS ni administrar sus cargas de trabajo. En este caso de emergencia, puede proporcionar un proceso de acceso de emergencia para que un pequeño grupo de administradores acceda a las Cuentas de AWS con el fin de llevar a cabo tareas cruciales que no puedan esperar a que sus proveedores de identidades centralizados vuelvan a estar disponibles. Por ejemplo, su proveedor de identidades no estará disponible durante 4 horas y, durante ese periodo, necesita modificar los límites superiores de un grupo de Amazon EC2 Auto Scaling en una cuenta de producción para gestionar un aumento inesperado en el tráfico de clientes. Los administradores de emergencias deben seguir el proceso de acceso de emergencia para acceder a la Cuenta de AWS de producción específica y hacer los cambios necesarios.
El proceso de acceso de emergencia se basa en una Cuenta de AWS de acceso de emergencia creada de antemano que se utiliza únicamente para el acceso de emergencia y dispone de recursos de AWS (como los usuarios y roles de IAM) para respaldar el proceso de acceso de emergencia. Durante las operaciones normales, nadie debe acceder a la cuenta de acceso de emergencia y usted debe supervisar y alertar sobre el uso indebido de esta cuenta (para obtener más información, consulte la sección anterior de guía común).
La cuenta de acceso de emergencia tiene roles de IAM de acceso de emergencia con permisos para asumir roles entre cuentas en las Cuentas de AWS que requieran acceso de emergencia. Estos roles de IAM se crean de antemano y se configuran con políticas de confianza que confían en los roles de IAM de la cuenta de emergencia.
El proceso de acceso de emergencia puede utilizar uno de los siguientes enfoques:
+ Puede crear previamente un conjunto de [usuarios de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) para sus administradores de emergencia en la cuenta de acceso de emergencia con contraseñas seguras y tokens de MFA asociados. Estos usuarios de IAM tienen permisos para asumir los roles de IAM que, entonces, permiten el acceso entre cuentas a la Cuenta de AWS donde se requiere el acceso de emergencia. Recomendamos crear el menor número posible de usuarios y asignar cada usuario a un único administrador de emergencias. Durante una emergencia, un usuario administrador de emergencias inicia sesión en la cuenta de acceso de emergencia con su contraseña y el código de token de MFA, cambia el rol de IAM de acceso de emergencia en la cuenta de emergencia y, finalmente, cambia el rol de IAM de acceso de emergencia en la cuenta de carga de trabajo para llevar a cabo la acción de cambio de emergencia. La ventaja de este enfoque es que cada usuario de IAM se asigna a un administrador de emergencias y usted puede saber qué usuario inició sesión al revisar los eventos de CloudTrail. La desventaja es que hay que mantener varios usuarios de IAM con sus contraseñas de larga duración y tokens de MFA asociados.
+ Puede usar el [usuario raíz de Cuenta de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) de acceso de emergencia para iniciar sesión en la cuenta de acceso de emergencia, asumir el rol de IAM de acceso de emergencia y asumir el rol entre cuentas en la cuenta de carga de trabajo. Recomendamos configurar una contraseña segura y varios tokens de MFA para el usuario raíz. También recomendamos almacenar la contraseña y los tokens de MFA en un almacén de credenciales empresarial seguro que aplique una autenticación y una autorización sólidas. Debe proteger los factores de restablecimiento de la contraseña y el token de MFA. Para ello, establezca la dirección de correo electrónico de la cuenta en una lista de distribución de correo electrónico supervisada por los administradores de seguridad en la nube y el número de teléfono de la cuenta en un número de teléfono compartido también supervisado por los administradores de seguridad. La ventaja de este enfoque es que solo hay que administrar un conjunto de credenciales de usuario raíz. La desventaja es que, dado que se trata de un usuario compartido, es posible que varios administradores inicien sesión como usuario raíz. Debe auditar los eventos de registro del almacén empresarial para identificar qué administrador extrajo la contraseña del usuario raíz.
**Modo de error 2: la configuración del proveedor de identidades en AWS se ha modificado o ha caducado**
Para permitir que los usuarios de la plantilla se federen en Cuentas de AWS, puede configurar IAM Identity Center con un proveedor de identidades externo o crear un proveedor de identidades de IAM ([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)). Por lo general, estos se configuran al importar un documento XML de metadatos de SAML que proporciona el proveedor de identidades. El documento XML de metadatos incluye un certificado X.509 que corresponde a una clave privada que el proveedor de identidades utiliza para firmar sus aserciones SAML.
Un administrador podría modificar o eliminar estas configuraciones de AWS de forma accidental. En otro escenario, el certificado X.509 importado a AWS podría caducar cuando aún no se ha importado a AWS un nuevo XML de metadatos con un certificado nuevo. Ambas situaciones pueden desbaratar la federación a AWS de los usuarios de la plantilla y provocar una emergencia.
En un caso de emergencia de este tipo, puede proporcionar a sus administradores de identidades acceso a AWS para solucionar los problemas de federación. Por ejemplo, el administrador de identidades utiliza el proceso de acceso de emergencia para iniciar sesión en la Cuenta de AWS de acceso de emergencia, cambia a un rol en la cuenta de administrador del centro de identidades y actualiza la configuración del proveedor de identidades externo al importar el último documento XML de metadatos SAML de su proveedor de identidades para volver a habilitar la federación. Una vez que se corrija la federación, los usuarios de la plantilla seguirán utilizando el proceso operativo normal para federarse en sus cuentas de carga de trabajo.
Puede seguir los enfoques detallados en el modo de error 1 anterior para crear un proceso de acceso de emergencia. Puede conceder permisos con privilegios mínimos a sus administradores de identidades para que accedan únicamente a la cuenta de administrador del centro de identidades y lleven a cabo acciones en el centro de identidades en esa cuenta.
**Modo de error 3: interrupción del centro de identidades**
En el caso poco probable de que se produzca una interrupción en IAM Identity Center o en una Región de AWS, le recomendamos que establezca una configuración que pueda utilizar para proporcionar acceso temporal a la Consola de administración de AWS.
El proceso de acceso de emergencia utiliza la federación directa desde su proveedor de identidades a IAM en una cuenta de emergencia. Para obtener información detallada sobre el proceso y las consideraciones de diseño, consulte [Set up emergency access to the Consola de administración de AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html).
### Pasos para la implementación
**Pasos comunes para todos los modos de error**
+ Cree una Cuenta de AWS dedicada a los procesos de acceso de emergencia. Cree de antemano los recursos de IAM necesarios en la cuenta, como roles de IAM o usuarios de IAM, y opcionalmente, proveedores de identidades de IAM. Además, cree de antemano roles de IAM entre cuentas en las Cuentas de AWS de la carga de trabajo con relaciones de confianza con los roles de IAM correspondientes en la cuenta de acceso de emergencia. Puede usar [CloudFormation StackSets con AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudformation.html) para crear dichos recursos en las cuentas de los miembros de su organización.
+ Cree [políticas de control de servicio](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCP) de AWS Organizations para denegar la eliminación y modificación de los roles de IAM entre cuentas en las Cuentas de AWS de miembros.
+ Habilite CloudTrail para la Cuenta de AWS de acceso de emergencia y envíe los eventos de ruta a un bucket de S3 central en su Cuenta de AWS de recopilación de registros. Si utiliza AWS Control Tower para configurar y gobernar su entorno multicuenta de AWS, cada cuenta que cree con AWS Control Tower o inscriba en AWS Control Tower tendrá CloudTrail habilitado de forma predeterminada y se enviará a un bucket de S3 en una Cuenta de AWS de archivo de registro dedicada.
+ Supervise la actividad de la cuenta de acceso de emergencia mediante la creación de reglas de EventBridge que concuerden con el inicio de sesión de la consola y la actividad de la API por parte de los roles de IAM de emergencia. Envíe notificaciones a su centro de operaciones de seguridad cuando se produzca actividad fuera de un evento de emergencia continuo registrado en su sistema de administración de incidentes.
**Pasos adicionales para el modo de error 1: el proveedor de identidades utilizado para federarse en AWS no está disponible y el modo de error 2: la configuración del proveedor de identidades en AWS se ha modificado o ha caducado**
+ Cree de antemano los recursos en función del mecanismo que elija para el acceso de emergencia:
+ **Uso de usuarios de IAM:** cree de antemano los usuarios de IAM con contraseñas seguras y los dispositivos MFA asociados.
+ **Uso del usuario raíz de la cuenta de emergencia:** configure el usuario raíz con una contraseña segura y almacene la contraseña en el almacén de credenciales de su empresa. Asocie varios dispositivos MFA físicos al usuario raíz y almacene los dispositivos en lugares a los que puedan acceder rápidamente los miembros de su equipo de administradores de emergencias.
**Pasos adicionales para el modo de error 3: interrupción del centro de identidades**
+ Tal como se describe en [Set up emergency access to the Consola de administración de AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html), en la Cuenta de AWS de acceso de emergencia, cree un proveedor de identidades de IAM para habilitar la federación SAML directa desde su proveedor de identidades.
+ Cree grupos de operaciones de emergencia en su IdP sin miembros.
+ Cree los roles de IAM correspondientes a los grupos de operaciones de emergencia en la cuenta de acceso de emergencia.
## Recursos
**Prácticas recomendadas de Well-Architected relacionadas:**
+ [SEC02-BP04 Uso de un proveedor de identidades centralizado](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_identities_identity_provider.html)
+ [SEC03-BP02 Concesión de acceso con privilegios mínimos](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_least_privileges.html)
+ [SEC10-BP02 Desarrollo de planes de administración de incidentes](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_develop_management_plans.html)
+ [SEC10-BP07 Ejecución de simulaciones](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_run_game_days.html)
**Documentos relacionados:**
+ [Set up emergency access to the Consola de administración de AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html)
+ [Concesión de acceso a la a los usuarios federados SAML Consola de administración de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html)
+ [Break glass access](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html)
**Videos relacionados:**
+ [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center](https://youtu.be/TvQN4OdR_0Y)
+ [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive](https://youtu.be/YMj33ToS8cI)
**Ejemplos relacionados:**
+ [AWS Break Glass Role](https://github.com/awslabs/aws-break-glass-role)
+ [AWS customer playbook framework](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [AWS incident response playbook samples](https://github.com/aws-samples/aws-incident-response-playbooks)
# SEC03-BP04 Reducción continua de los permisos
A medida que los equipos determinen qué acceso es necesario, elimine los permisos innecesarios y establezca procesos de revisión para conseguir permisos con privilegios mínimos. Supervise y elimine continuamente las identidades y los permisos que no se utilicen, tanto para el acceso humano como para el de las máquinas.
**Resultado deseado:** las políticas de permisos deben cumplir con el principio de privilegio mínimo. A medida que se definan mejor las responsabilidades y los roles del trabajo, debe revisar sus políticas de permisos para eliminar los permisos innecesarios. Este enfoque reduce el alcance del impacto en caso de que las credenciales se expongan de forma inadvertida o se acceda a ellas sin autorización.
**Patrones comunes de uso no recomendados:**
+ Conceder permisos de administrador a los usuarios de forma predeterminada.
+ Crear políticas excesivamente permisivas, pero sin todos los privilegios de administrador.
+ Mantener políticas de permisos después de que ya no son necesarias.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
Cuando los equipos y los proyectos están dando sus primeros pasos, utilizar unas políticas de permisos permisivas sirve para fomentar la innovación y la agilidad. Por ejemplo, en un entorno de desarrollo o de pruebas, se puede dar acceso a los desarrolladores a un amplio conjunto de servicios de AWS. Recomendamos que evalúe el acceso continuamente y lo restrinja únicamente a aquellos servicios y acciones de servicio que sean necesarios para llevar a cabo el trabajo actual. Recomendamos llevar a cabo esta evaluación tanto para las identidades humanas como para las de máquina. Las identidades de máquina, que a veces se denominan cuentas del sistema o del servicio, son identidades que dan acceso a AWS a aplicaciones o servidores. Este acceso es especialmente importante en un entorno de producción, donde unos permisos demasiado permisivos pueden tener un impacto enorme y el potencial de exponer los datos de los clientes.
AWS tiene numerosos métodos para ayudar a identificar a los usuarios, roles, permisos y credenciales no utilizados. AWS también puede ayudar a analizar la actividad de acceso de los usuarios y roles de IAM, incluidas las claves de acceso asociadas, y el acceso a recursos de AWS, como los objetos de los buckets de Amazon S3. La generación de políticas de AWS Identity and Access Management Access Analyzer puede ayudarle a crear políticas de permisos restrictivas basadas en los servicios y acciones reales con los que interactúa una entidad principal. El [control de acceso basado en atributos (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) puede ayudar a simplificar la administración de permisos, ya que permite proporcionar permisos a los usuarios mediante sus atributos en lugar de asociar las políticas de permisos directamente a cada usuario.
### Pasos para la implementación
+ **Uso de [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html):** el Analizador de acceso de IAM le ayuda a identificar los recursos de su organización y sus cuentas, como los buckets de Amazon Simple Storage Service (Amazon S3) o los roles de IAM, que [se comparten con una entidad externa](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html).
+ **Uso de la [generación de políticas del Analizador de acceso de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html):** la generación de políticas del Analizador de acceso de IAM le ayuda a [crear políticas de permisos detalladas basadas en la actividad de acceso de un usuario o rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html#access-analyzer-policy-generation-howitworks).
+ **Pruebe los permisos en los entornos inferiores antes de la producción:** comience por utilizar los [entornos de pruebas y de desarrollo menos críticos](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/understanding-the-devops-environments.html) a fin de probar los permisos necesarios para diversas funciones de trabajo con IAM Access Analyzer. A continuación, ajuste y valide progresivamente estos permisos en los entornos de pruebas, control de calidad y ensayo antes de aplicarlos a la producción. Los entornos más bajos pueden tener permisos más flexibles al principio, ya que las políticas de control de servicios (SCP) imponen barreras de protección al limitar el número máximo de permisos concedidos.
+ **Determinación de un marco temporal y una política de uso aceptables para los usuarios y roles de IAM:** use la [marca de tiempo del último acceso](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data.html) para [identificar los usuarios y roles no utilizados](https://aws.amazon.com/blogs/security/identify-unused-iam-roles-remove-confidently-last-used-timestamp/) y eliminarlos. Revise la información del último acceso a servicios y acciones para identificar y [establecer el alcance de los permisos para usuarios y roles específicos](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html). Por ejemplo, puede utilizar la información sobre el último acceso para identificar las acciones específicas de Amazon S3 necesarias para el rol de su aplicación y restringir el acceso únicamente a dichas acciones. Estas características de información sobre el último acceso están disponibles en la Consola de administración de AWS y permiten de manera programática incorporarlas en sus flujos de trabajo de infraestructura y sus herramientas automatizadas.
+ **Consideración de la posibilidad de [registrar eventos de datos en AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html):** de manera predeterminada, CloudTrail no registra los eventos de datos, como la actividad de nivel de objeto de Amazon S3 (por ejemplo, `GetObject` y `DeleteObject`) o las actividades de las tablas de Amazon DynamoDB (por ejemplo `PutItem` y `DeleteItem`). Considere la posibilidad de habilitar el registro de estos eventos para determinar qué usuarios y roles necesitan acceder a objetos de Amazon S3 o elementos de tabla de DynamoDB específicos.
## Recursos
**Documentos relacionados:**
+ [Aplicar permisos de privilegios mínimos](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
+ [Revisar y eliminar periódicamente usuarios, roles, permisos, políticas y credenciales no utilizados](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials)
+ [ What is AWS CloudTrail? ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)
+ [Uso de políticas de](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)
+ [ Registro y supervisión en DynamoDB ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/MonitoringDynamoDB.html)
+ [ Habilitación del registro de eventos de CloudTrail para buckets y objetos de Amazon S ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html)
+ [ Generación de informes de credenciales para su Cuenta de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)
**Videos relacionados:**
+ [Become an IAM Policy Master in 60 Minutes or Less](https://youtu.be/YQsK4MtsELU)
+ [Separation of Duties, Least Privilege, Delegation, and CI/CD](https://youtu.be/3H0i7VyTu70)
+ [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive ](https://www.youtube.com/watch?v=YMj33ToS8cI)
# SEC03-BP05 Definición de las barreras de protección de los permisos para una organización
Utilice las barreras de protección de permisos para reducir el ámbito de los permisos disponibles que se pueden conceder a las entidades principales. La cadena de evaluación de la política de permisos incluye sus barreras de protección para determinar los *permisos efectivos* de una entidad principal al tomar decisiones de autorización. Puede definir barreras de protección mediante un enfoque basado en capas. Aplique algunas barreras de protección de manera generalizada en toda la organización y aplique otras de forma específica a las sesiones de acceso temporal.
**Resultado deseado:** cuenta con un aislamiento claro de los entornos mediante el uso de Cuentas de AWS separadas. Las políticas de control de servicios (SCP) se utilizan para definir las barreras de protección de permisos en toda la organización. Las barreras de protección más amplias se establecen en los niveles jerárquicos más cercanos a la raíz de la organización, y las más estrictas se establecen más cerca del nivel de las cuentas individuales.
En los casos en los que se pueden utilizar, las políticas de recursos definen las condiciones que debe cumplir una entidad principal para tener acceso a un recurso. Las políticas de recursos también acotan el conjunto de acciones permitidas cuando corresponde. Los límites de permisos se aplican a entidades principales que administran permisos de las cargas de trabajo y delegan la administración de permisos a los propietarios individuales de las cargas de trabajo.
**Patrones comunes de uso no recomendados:**
+ Crear Cuentas de AWS de miembros dentro de una [organización de AWS](https://aws.amazon.com/organizations/), pero no usar SCP para restringir el uso y los permisos disponibles para sus credenciales raíz.
+ Asignar permisos según el principio de privilegio mínimo, pero sin aplicar barreras de protección al conjunto máximo de permisos que se pueden conceder.
+ *Confiar en el principio de *denegación implícita* de AWS IAM para restringir los permisos y esperar que las políticas no concedan un permiso explícito* no deseado.
+ Ejecutar varios entornos de carga de trabajo en la misma Cuenta de AWS y, a continuación, recurrir a mecanismos como las VPC, las etiquetas o las políticas de recursos para hacer cumplir los límites de los permisos.
**Beneficios de establecer esta práctica recomendada:** las barreras de protección de permisos ayudan a generar confianza en que no se van a conceder permisos no deseados, incluso cuando una política de permisos intente hacerlo. Esto puede simplificar la definición y la administración de los permisos al reducir el ámbito máximo de los permisos que deben tenerse en cuenta.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
Le recomendamos que utilice un enfoque basado en capas para definir las barreras de protección de permisos para su organización. Este enfoque reduce sistemáticamente el conjunto máximo de permisos posibles a medida que se aplican capas adicionales. Esto le ayuda a conceder acceso según el principio de privilegios mínimos, lo que reduce el riesgo de accesos no deseados debidos a una configuración errónea de las políticas.
El primer paso para establecer barreras de protección de permisos es aislar las cargas de trabajo y los entornos en Cuentas de AWS separadas. Las entidades principales de una cuenta no pueden acceder a los recursos de otra cuenta sin un permiso explícito para hacerlo, incluso aunque ambas cuentas se encuentren en la misma organización de AWS o en la misma [unidad organizativa (OU)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html). Puede usar las unidades organizativas para agrupar las cuentas que prefiera administrar como una sola unidad.
El siguiente paso consiste en reducir el conjunto máximo de permisos que puede conceder a las entidades principales dentro de las cuentas de los miembros de su organización. Para ello, puede usar las [políticas de control de servicios (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html), que puede aplicar a una unidad organizativa o a una cuenta. Las SCP pueden aplicar controles de acceso comunes, como restringir el acceso a determinadas Regiones de AWS, ayudar a evitar que se eliminen recursos o deshabilitar acciones de servicio potencialmente arriesgadas. Las SCP que se apliquen a la raíz de su organización solo afectan a las cuentas de los miembros, no a la cuenta de administración. Las SCP solo controlan las entidades principales de su organización. Las SCP no controlan las entidades principales externas a su organización que accedan a sus recursos.
Si está utilizando [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html), puede aprovechar sus [controles](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#how-controls-work) y [zonas de aterrizaje](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html) como base para sus barreras de protección de permisos y su entorno de múltiples cuentas. Las zonas de aterrizaje proporcionan un entorno básico seguro y preconfigurado con cuentas independientes para diferentes cargas de trabajo y aplicaciones. Las barreras de protección imponen controles obligatorios en materia de seguridad, operaciones y cumplimiento mediante una combinación de políticas de control de servicios (SCP), reglas de AWS Config y otras configuraciones. Sin embargo, cuando se utilizan las barreras de protección y las zonas de aterrizaje de Control Tower junto con los SCP personalizados de las organizaciones, es fundamental seguir las prácticas recomendadas descritas en la documentación de AWS para evitar conflictos y garantizar un gobierno adecuado. Consulte la [guía de AWS Control Tower para AWS Organizations](https://docs.aws.amazon.com/controltower/latest/userguide/orgs-guidance.html) a fin de obtener recomendaciones detalladas sobre la administración de los SCP, las cuentas y las unidades organizativas (OU) en un entorno de Control Tower.
Si sigue estas directrices, podrá aprovechar de forma eficaz las barreras de protección, las zonas de aterrizaje y los SCP personalizados de Control Tower, a la vez que mitigará los posibles conflictos y garantizará el gobierno y el control adecuados de su entorno de múltiples cuentas de AWS.
Otro paso consiste en usar [políticas de recursos de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based) para determinar el ámbito de las acciones disponibles que se pueden llevar a cabo con respecto a los recursos que controlan, junto con cualquier condición que deba cumplir la entidad principal activa. El ámbito puede ser tan amplio como para permitir todas las acciones siempre que la entidad principal forme parte de su organización (mediante la [clave de condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) PrincipalOrgID), o tan detallado como para permitir solo acciones específicas para un rol de IAM específico. Puede adoptar un enfoque similar con las condiciones de las políticas de confianza para un rol de IAM. Si una política de confianza de recursos o roles nombra explícitamente una entidad principal en la misma cuenta que el rol o el recurso que controla, esa entidad principal no necesita una política de IAM asociada que otorgue los mismos permisos. Si la entidad principal está en una cuenta diferente a la del recurso, esa entidad principal necesita una política de IAM asociada que otorgue esos permisos.
A menudo, un equipo de carga de trabajo querrá administrar los permisos que requiere su carga de trabajo. Esto podría exigirles la creación de nuevos roles de IAM y políticas de permisos. Puede definir el alcance máximo de los permisos que el equipo puede conceder dentro en un [límite de permisos de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) y asociar este documento a un rol de IAM que el equipo pueda utilizar posteriormente para gestionar sus permisos y roles de IAM. Este método puede proporcionarles la capacidad de completar su trabajo y, al mismo tiempo, mitigar los riesgos de disponer de acceso administrativo a IAM.
Un paso más detallado consiste en implementar técnicas de *administración de acceso privilegiado* (PAM) y *administración de acceso elevado temporal* (TEAM). Un ejemplo de PAM consiste en exigir a las entidades principales que lleven a cabo una autenticación multifactor antes de tomar medidas privilegiadas. Para obtener más información, consulte [Configuring MFA-protected API access](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html). TEAM requiere una solución que administre la aprobación y el plazo en el que se permite que una entidad principal tenga acceso de alto nivel. Un enfoque consiste en agregar temporalmente la entidad principal a la política de confianza del rol para un rol de IAM que tenga un acceso de alto nivel. Otro enfoque consiste, en condiciones normales, en reducir los permisos que un rol de IAM concede a una entidad principal mediante una [política de sesión](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) y, a continuación, eliminar temporalmente esta restricción durante el periodo de tiempo aprobado. Para obtener más información sobre las soluciones que AWS y determinados socios han validado, consulte [Temporary elevated access](https://docs.aws.amazon.com/singlesignon/latest/userguide/temporary-elevated-access.html).
### Pasos para la implementación
1. Aísle las cargas de trabajo y los entornos en Cuentas de AWS separadas.
1. Use las SCP para reducir el conjunto máximo de permisos que se pueden conceder a las entidades principales dentro de las cuentas de los miembros de su organización.
1. Al definir las SCP para reducir el conjunto máximo de permisos que se pueden conceder a las entidades principales dentro de las cuentas de los miembros de su organización, puede elegir entre una estrategia de *lista de permitidos* o de *lista de denegaciones*. La estrategia de listas de permisos especifica de forma explícita el acceso permitido y bloquea de forma implícita todos los demás accesos. La estrategia de listas de permisos especifica de forma explícita el acceso permitido y permite de forma predeterminada todos los demás accesos. Ambas estrategias tienen sus ventajas y desventajas, y la elección adecuada depende de los requisitos específicos y del modelo de riesgo de su organización. Para obtener más información, consulte [Strategy for using SCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_strategies.html).
1. Además, revise los [ejemplos de políticas de control de servicios](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html) para comprender cómo construir los SCP de manera eficaz.
1. Utilice las políticas de recursos de IAM para acotar y especificar las condiciones para las acciones permitidas en los recursos. Use las condiciones de las políticas de confianza en roles de IAM para crear restricciones a la hora de asumir roles.
1. Asigne límites de permisos de IAM a los roles de IAM que los equipos de carga de trabajo puedan usar para administrar sus propios roles y permisos de IAM en las cargas de trabajo.
1. Evalúe las soluciones de PAM y TEAM en función de sus necesidades.
## Recursos
**Documentos relacionados:**
+ [Data perimeters on AWS](https://aws.amazon.com/identity/data-perimeters-on-aws/)
+ [Establecimiento de barreras de protección de permisos mediante perímetros de datos](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_data-perimeters.html)
+ [Lógica de evaluación de políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)
**Ejemplos relacionados:**
+ [Service control policy examples](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
**Herramientas relacionadas:**
+ [AWS Solution: Temporary Elevated Access Management](https://aws-samples.github.io/iam-identity-center-team/)
+ [Validated security partner solutions for TEAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/temporary-elevated-access.html#validatedpartners)
# SEC03-BP06 Administración del acceso en función del ciclo de vida
Supervise y ajuste los permisos otorgados a sus entidades principales (usuarios, cargos y grupos) a lo largo de su ciclo de vida dentro de su organización. Ajuste la pertenencia a grupos a medida que los usuarios cambien de cargo y elimine el acceso cuando un usuario abandone la organización.
**Resultado deseado:** supervisa y ajusta los permisos a lo largo del ciclo de vida de los directores de la organización, lo que reduce el riesgo de privilegios innecesarios. Concede el acceso pertinente al crear un usuario. Modifica el acceso a medida que cambien las responsabilidades del usuario y elimina el acceso cuando el usuario ya no está activo o ha abandonado la organización. Administra de forma centralizada los cambios en los usuarios, los cargos y los grupos. Utiliza la automatización para propagar los cambios en sus entornos de AWS.
**Patrones comunes de uso no recomendados:**
+ Concede privilegios de acceso excesivos o amplios a las identidades por adelantado, más allá de lo que se requiere inicialmente.
+ No revisa ni ajusta los privilegios de acceso, a medida que los cargos y las responsabilidades cambian con el tiempo.
+ Deja identidades inactivas o terminadas con privilegios de acceso activos. Esto aumenta el riesgo de acceso no autorizado.
+ No aprovecha la automatización para gestionar el ciclo de vida de las identidades.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
Administre y ajuste cuidadosamente los privilegios de acceso que otorga a las identidades (como usuarios, cargos y grupos) a lo largo de su ciclo de vida. Este ciclo de vida incluye la fase de incorporación inicial, los cambios continuos en los cargos y las responsabilidades y, en última instancia, la baja o el despido. Gestione el acceso de forma proactiva en función de la etapa del ciclo de vida para mantener el nivel de acceso adecuado. Respete el principio de privilegio mínimo para reducir el riesgo de privilegios de acceso excesivos o innecesarios.
Puede administrar el ciclo de vida de los usuarios de IAM directamente dentro de la Cuenta de AWS, o mediante la federación del proveedor de identidades de su personal con [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/). Para los usuarios de IAM, puede crear, modificar y eliminar usuarios y sus permisos asociados dentro de la Cuenta de AWS. En el caso de los usuarios federados, puede utilizar IAM Identity Center para administrar su ciclo de vida mediante la sincronización de la información de usuarios y grupos del proveedor de identidades de su organización mediante el protocolo del sistema de administración de identidades entre dominios ([System for Cross-domain Identity Management](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html) o SCIM).
El SCIM es un protocolo estándar abierto para el aprovisionamiento y desaprovisionamiento automatizados de identidades de usuario en diferentes sistemas. Al integrar su proveedor de identidades con IAM Identity Center mediante SCIM, puede sincronizar automáticamente la información de los usuarios y los grupos, lo que ayuda a validar que los privilegios de acceso se concedan, modifiquen o revoquen en función de los cambios en la fuente de identidad autorizada de su organización.
A medida que cambien los cargos y responsabilidades de los empleados dentro de su organización, ajuste sus privilegios de acceso en consecuencia. Puede usar los conjuntos de permisos de IAM Identity Center para definir diferentes cargos o responsabilidades laborales y asociarlos a las políticas y los permisos de IAM correspondientes. Cuando cambia el cargo de un empleado, puede actualizar su conjunto de permisos asignado para que refleje sus nuevas responsabilidades. Verifique que tenga el acceso necesario y, al mismo tiempo, cumpla el principio de privilegio mínimo.
### Pasos para la implementación
1. Defina y documente un proceso del ciclo de vida de la administración de accesos, incluidos los procedimientos para conceder el acceso inicial, las revisiones periódicas y la baja.
1. Implemente [límites de roles, grupos y permisos de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) para administrar el acceso de manera colectiva y aplicar los niveles de acceso máximos permitidos.
1. Integre con un [proveedor de identidades federado](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) (como Microsoft Active Directory, Okta o Ping Identity) como fuente autorizada de la información de usuarios y grupos mediante IAM Identity Center.
1. Utilice el protocolo [SCIM](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html) para sincronizar la información de usuarios y grupos del proveedor de identidades con el Almacén de identidades de IAM Identity Center.
1. Cree [conjuntos de permisos](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) en IAM Identity Center que representen diferentes cargos o responsabilidades laborales dentro de su organización. Defina las políticas y los permisos de IAM adecuados para cada conjunto de permisos.
1. Implemente revisiones del acceso periódicas, medidas de revocación rápida del acceso y mejora continua del proceso del ciclo de vida de la administración accesos.
1. Proporcione formación y concienciación a los empleados sobre las prácticas recomendadas de administración de accesos.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [SEC02-BP04 Uso de un proveedor de identidades centralizado](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_identities_identity_provider.html)
**Documentos relacionados:**
+ [Manage your identity source ](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source.html)
+ [Manage identities in IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html)
+ [Uso de AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
+ [Generación de políticas del Analizador de acceso de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)
**Videos relacionados:**
+ [AWS re:Inforce 2023 - Manage temporary elevated access with AWS IAM Identity Center](https://www.youtube.com/watch?v=a1Na2G7TTQ0)
+ [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center](https://www.youtube.com/watch?v=TvQN4OdR_0Y&t=444s)
+ [AWS re:Invent 2022 - Harness power of IAM policies & rein in permissions w/Access Analyzer](https://www.youtube.com/watch?v=x-Kh8hKVX74&list=PL2yQDdvlhXf8bvQJuSP1DQ8vu75jdttlM&index=11)
# SEC03-BP07 Análisis del acceso público y entre cuentas
Supervise continuamente los resultados que pongan en relieve el acceso público y entre cuentas. Reduzca el acceso público y el acceso entre cuentas solo a los recursos que requieran este tipo de acceso.
**Resultado deseado:** sepa cuáles de los recursos de AWS se comparten y con quién. Supervise y audite continuamente sus recursos compartidos para verificar que solo se compartan con las entidades principales autorizadas.
**Patrones comunes de uso no recomendados:**
+ No mantener un inventario de los recursos compartidos.
+ No seguir un proceso para aprobar el acceso público o entre cuentas a los recursos.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** bajo
## Guía para la implementación
Si su cuenta pertenece a AWS Organizations, puede conceder acceso a los recursos a toda la organización, a unidades organizativas específicas o a cuentas individuales. Si su cuenta no es miembro de una organización, puede compartir recursos con cuentas individuales. Puede conceder acceso entre cuentas mediante políticas basadas en recursos (por ejemplo, las [políticas de buckets de Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html), o si permite que la entidad principal de otra cuenta asuma un rol de IAM en su cuenta. Cuando utilice políticas de recursos, compruebe que solo se concede acceso a las entidades principales autorizadas. Defina un proceso para aprobar todos los recursos que deban estar disponibles públicamente.
[AWS Identity and Access Management Access Analyzer](https://aws.amazon.com/iam/features/analyze-access/) usa la [seguridad comprobable](https://aws.amazon.com/security/provable-security/) para identificar todas las rutas de acceso a un recurso desde fuera de su cuenta. Revisa continuamente las políticas de recursos e informa de los resultados del acceso público y entre cuentas para facilitarle el análisis de un acceso potencialmente amplio. Considere la posibilidad de configurar el Analizador de acceso de IAM con AWS Organizations para verificar que tiene visibilidad en todas sus cuentas. El Analizador de acceso de IAM también permite obtener una [vista previa de los resultados](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-access-preview.html) antes de implementar los permisos de recursos. Esto le permite validar que sus cambios de política conceden solo el acceso público y entre cuentas previsto a sus recursos. Al diseñar el acceso a varias cuentas, puede utilizar [políticas de confianza](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/) para controlar en qué casos se puede asumir un rol. Por ejemplo, puede usar la [clave de condición `PrincipalOrgId` para denegar un intento de asumir un rol desde fuera de AWS Organizations](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/).
[AWS Config puede informar de los recursos](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-Publicly-Accessible-Resources.html) que están mal configurados y, mediante comprobaciones de políticas de AWS Config, puede detectar los recursos que tienen configurado el acceso público. Los servicios como [AWS Control Tower](https://aws.amazon.com/controltower/) y [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html) simplifican la implementación de controles y barreras de protección en AWS Organizations para identificar y corregir los recursos expuestos públicamente. Por ejemplo, AWS Control Tower tiene una barrera de protección administrada que puede detectar si Cuentas de AWS puede restaurar alguna [instantánea de Amazon EBS](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html).
### Pasos para la implementación
+ **Planteamiento de uso de [AWS Config para AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html):** AWS Config permite agregar los resultados de varias cuentas de una AWS Organizations cuenta de administrador delegado. Esto proporciona una visión completa y le permite [implementar Reglas de AWS Config en todas las cuentas para detectar los recursos de acceso público](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html).
+ **Configuración de AWS Identity and Access Management Access Analyzer:** el Analizador de acceso de IAM lo ayuda a identificar los recursos y cuentas de su organización, como los buckets de Amazon S3 o los roles de IAM que se [comparten con una entidad externa](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html).
+ **Uso de la corrección automática de AWS Config para responder a los cambios en la configuración de acceso público de los buckets de Amazon S3:** [puede activar automáticamente la configuración de bloqueo de acceso público para los buckets de Amazon S3](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/).
+ **Implementación de la supervisión y las alertas para identificar si los buckets de Amazon S3 se han convertido en públicos:** debe disponer de [supervisión y alertas](https://aws.amazon.com/blogs/aws/amazon-s3-update-cloudtrail-integration/) para identificar cuándo está desactivado el bloqueo de acceso público de Amazon S3 y si los buckets de Amazon S3 pasan a ser públicos. Además, si utiliza AWS Organizations, puede crear una [política de control de servicios](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) que impida cambios en las políticas de acceso público de Amazon S3. [AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor.html) comprueba los buckets de Amazon S3 que tienen permisos de acceso abierto. Los permisos del bucket que otorgan, suben o eliminan el acceso para todo el mundo crean posibles vulnerabilidades de seguridad, ya que permiten que cualquiera agregue, modifique o elimine elementos en un bucket. La comprobación de Trusted Advisor examina los permisos explícitos del bucket y las políticas asociadas que podrían anular los permisos del bucket. También puede utilizar AWS Config para supervisar si sus buckets de Amazon S3 tienen acceso público. Para obtener más información, consulte el blog [How to Use AWS Config to Monitor for and Respond to Amazon S3 Buckets Allowing Public Access](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/).
Al revisar los controles de acceso de los buckets de Amazon S3, es importante tener en cuenta la naturaleza de los datos almacenados en ellos. [Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/findings-types.html) es un servicio diseñado para ayudarlo a descubrir y proteger datos confidenciales, como la información de identificación personal (PII), la información de salud protegida (PHI) y las credenciales, como las claves privadas o las claves de acceso de AWS.
## Recursos
**Documentos relacionados:**
+ [Uso de AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html?ref=wellarchitected)
+ [AWS Control Tower controls library ](https://docs.aws.amazon.com/controltower/latest/userguide/controls-reference.html)
+ [AWS Foundational Security Best Practices standard](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html)
+ [AWS Config Reglas de administradas](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html)
+ [AWS Trusted Advisor check reference](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor-check-reference.html)
+ [ Monitoring AWS Trusted Advisor check results with Amazon EventBridge ](https://docs.aws.amazon.com/awssupport/latest/user/cloudwatch-events-ta.html)
+ [ Managing AWS Config Rules Across All Accounts in Your Organization ](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html)
+ [AWS Config y AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html)
+ [ Publicación de la AMI para utilizarla en Amazon EC2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-intro.html#block-public-access-to-amis)
**Videos relacionados:**
+ [Best Practices for securing your multi-account environment](https://www.youtube.com/watch?v=ip5sn3z5FNg)
+ [Dive Deep into IAM Access Analyzer](https://www.youtube.com/watch?v=i5apYXya2m0)
# SEC03-BP08 Uso compartido de recursos de forma segura en su organización
A medida que el número de cargas de trabajo va aumentando, es posible que necesite compartir el acceso a los recursos de esas cargas de trabajo o aprovisionar los recursos varias veces entre varias cuentas. Es posible que disponga de constructos para compartimentar el entorno, como, por ejemplo, entornos de desarrollo, pruebas y producción. Sin embargo, disponer de constructos de separación no le impide compartir de forma segura. Al compartir componentes que se solapan, puede reducir la sobrecarga operativa y conseguir una experiencia uniforme sin tener que adivinar qué podría haber pasado por alto al crear el mismo recurso varias veces.
**Resultado deseado:** minimice el acceso no deseado mediante el uso de métodos seguros para compartir los recursos dentro de su organización y ayudar con su iniciativa de prevención de la pérdida de datos. Reduzca la sobrecarga operativa en comparación con la administración de componentes individuales, reduzca los errores derivados de la creación manual del mismo componente varias veces y aumentar la escalabilidad de las cargas de trabajo. Puede disminuir el tiempo de resolución en situaciones con varios puntos de fallo y aumentar su confianza a la hora de determinar cuándo un componente ya no es necesario. Para obtener una guía prescriptiva sobre el análisis de los recursos compartidos externamente, consulte [SEC03-BP07 Análisis del acceso público y entre cuentas](sec_permissions_analyze_cross_account.md).
**Patrones comunes de uso no recomendados:**
+ Falta de un proceso para supervisar continuamente y alertar automáticamente sobre un uso compartido externo inesperado.
+ Falta de una referencia sobre lo que se debe compartir y lo que no.
+ Adoptar de manera predeterminada una política muy abierta en lugar de compartir explícitamente cuando es necesario.
+ Crear manualmente recursos fundamentales que se solapan cuando es necesario.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
Diseñe sus controles y patrones de acceso para que rijan el consumo de recursos compartidos de forma segura y solo con entidades de confianza. Supervise los recursos compartidos y revise el acceso a ellos de forma continua; además, reciba alertas sobre un uso compartido inapropiado o inesperado. Revise [Analizar el acceso público y entre cuentas](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html) para que le sirva de ayuda para establecer una gobernanza que reduzca el acceso externo únicamente a los recursos que lo requieran, y para establecer un proceso de monitoreo continuo y alertas automáticas.
[Servicios de AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html) como, por ejemplo, [AWS Security Hub CSPM](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-securityhub.html), [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_organizations.html) y [AWS Backup](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-backup.html), permiten el uso compartido entre cuentas en AWS Organizations. Estos servicios permiten compartir datos con una cuenta central, acceder a ellos desde una cuenta central o administrar recursos y datos desde una cuenta central. Por ejemplo, AWS Security Hub CSPM puede transferir resultados desde cuentas individuales a una cuenta central en la que podrá verlos todos. AWS Backup puede hacer una copia de seguridad de un recurso y compartirlo entre varias cuentas. Puede usar [AWS Resource Access Manager](https://aws.amazon.com/ram/) (AWS RAM) para compartir otros recursos comunes, como [subredes de VPC y conexiones de puerta de enlace de tránsito](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-vpc), [AWS Network Firewall](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-network-firewall) o [canalizaciones de Amazon SageMaker AI](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-sagemaker).
Para restringir su cuenta y compartir solo los recursos de su organización, utilice las [políticas de control de servicios (SCP)](https://docs.aws.amazon.com/ram/latest/userguide/scp.html) para impedir el acceso a entidades principales externas. Al compartir recursos, combine los controles basados en la identidad y los controles de red para [crear un perímetro de datos para su organización](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html) que ofrezca protección frente al acceso no deseado. Un perímetro de datos es un conjunto de barreras de protección preventivas para ayudar a verificar que solo sus identidades de confianza accedan a los recursos de confianza desde las redes previstas. Estos controles ponen límites apropiados a los recursos que se pueden compartir y evitan que se compartan o expongan recursos que no deberían permitirse. Por ejemplo, como parte de su perímetro de datos, puede utilizar las políticas de punto de conexión de VPC y la condición de `AWS:PrincipalOrgId` para garantizar que las identidades que acceden a sus buckets de Amazon S3 pertenezcan a su organización. Es importante tener en cuenta que los [SCP no se aplican a los roles o entidades principales de AWS vinculados al servicio](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html#scp-effects-on-permissions).
Cuando utilice Amazon S3, [desactive las ACL de su bucket de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) y utilice las políticas de IAM para definir el control de acceso. Para [restringir el acceso a un origen de Amazon S3](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html) desde [Amazon CloudFront](https://aws.amazon.com/cloudfront/), migre desde la identidad de acceso de origen (OAI) al control de acceso de origen (OAC), que admite características adicionales como el cifrado del servidor con [AWS Key Management Service](https://aws.amazon.com/kms/).
En algunos casos, es posible que desee permitir compartir recursos fuera de su organización o conceder a un tercero acceso a sus recursos. Para obtener una guía prescriptiva sobre la administración de permisos para compartir recursos de forma externa, consulte [Administración de permisos](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html).
### Pasos para la implementación
1. **Utilice AWS Organizations:** AWS Organizations es un servicio de administración de cuentas que le permite unificar varias Cuentas de AWS en una organización que crea y administra de forma centralizada. Puede agrupar sus cuentas en unidades organizativas (OU) y asociar diferentes políticas a cada OU para ayudarle a satisfacer sus necesidades presupuestarias, de seguridad y de conformidad. También puede controlar cómo los servicios de inteligencia artificial (IA) y machine learning (ML) de AWS pueden recopilar y almacenar datos, y utilizar la administración de varias cuentas de los servicios de AWS integrada con las organizaciones.
1. **Integre AWS Organizations con los servicios de AWS:** cuando utiliza un servicio de AWS para efectuar tareas en su nombre en las cuentas de los miembros de su organización, AWS Organizations crea un rol vinculado al servicio (SLR) de IAM para ese servicio en cada cuenta miembro. Debe administrar el acceso de confianza mediante la Consola de administración de AWS, las API de AWS o la AWS CLI. Para obtener instrucciones prescriptivas sobre cómo activar el acceso de confianza, consulte [Uso de AWS Organizations con otros servicios de AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services.html) y [Servicios de AWS que puede usar con las organizaciones](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html).
1. **Establezca un perímetro de datos:** un perímetro de datos proporciona un límite claro de confianza y propiedad. En AWS, se suele representar como su organización de AWS administrada por AWS Organizations, junto con cualquier red o sistema local que acceda a sus recursos de AWS. El objetivo del perímetro de datos es verificar que se permite el acceso si la identidad es de confianza, el recurso es de confianza y la red es la que se espera. Sin embargo, establecer un perímetro de datos no es una estrategia universal. Evalúe y adopte los objetivos de control descritos en el documento técnico [Construir un perímetro en AWS](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/welcome.html) a partir de sus requisitos y modelos de riesgo de seguridad específicos. Debe plantearse detenidamente su postura de riesgo única e implementar los controles perimetrales que se ajusten a sus necesidades de seguridad.
1. **Use los recursos compartidos de los servicios de AWS y aplique las restricciones pertinentes:** muchos servicios de AWS le permiten compartir recursos con otra cuenta o dirigirse a un recurso de otra cuenta, como [Imágenes de máquina de Amazon (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) y [AWS Resource Access Manager (AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html). Restrinja la API de `ModifyImageAttribute` para especificar las cuentas de confianza con las que compartir la AMI. Especifique la condición `ram:RequestedAllowsExternalPrincipals` cuando se utilice AWS RAM para restringir el uso compartido únicamente a su organización y, de este modo, evitar el acceso desde identidades que no sean de confianza. Para obtener consideraciones e instrucciones prescriptivas, consulte [Uso compartido de recursos y objetivos externos](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/perimeter-implementation.html).
1. **Utilice AWS RAM para compartir de forma segura en una cuenta o con otras Cuentas de AWS:** [AWS RAM](https://aws.amazon.com/ram/) lo ayuda a compartir de forma segura los recursos que ha creado con roles y usuarios de su cuenta y con otras Cuentas de AWS. En un entorno de varias cuentas, AWS RAM le permite crear un recurso una vez y compartirlo con otras cuentas. Este enfoque ayuda a reducir su sobrecarga operativa a la vez que proporciona coherencia, visibilidad y auditabilidad en integraciones con Amazon CloudWatch y AWS CloudTrail, algo que no tiene cuando utiliza el acceso entre cuentas.
Si tiene recursos que ha compartido anteriormente mediante una política basada en recursos, puede usar la [API de `PromoteResourceShareCreatedFromPolicy`](https://docs.aws.amazon.com/ram/latest/APIReference/API_PromoteResourceShareCreatedFromPolicy.html) o una equivalente para convertir el uso compartido de recursos en un uso compartido de recursos de AWS RAM completo.
En algunos casos, puede que tenga que dar pasos adicionales para compartir recursos. Por ejemplo, para compartir una instantánea cifrada, debe [compartir una clave de AWS KMS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html#share-kms-key).
## Recursos
**Prácticas recomendadas relacionadas:**
+ [SEC03-BP07 Análisis del acceso público y entre cuentas](sec_permissions_analyze_cross_account.md)
+ [SEC03-BP09 Uso compartido seguro de recursos con terceros](sec_permissions_share_securely_third_party.md)
+ [SEC05-BP01 Creación de capas de red](sec_network_protection_create_layers.md)
**Documentos relacionados:**
+ [Propietario de bucket que concede permisos entre cuentas para objetos que no le pertenecen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [How to use Trust Policies with IAM](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [Building Data Perimeter on AWS](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html)
+ [Cómo utilizar un ID externo al conceder a un tercero el acceso a sus recursos de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
+ [AWS services you can use with AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)
+ [ Establishing a data perimeter on AWS: Allow only trusted identities to access company data ](https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-only-trusted-identities-to-access-company-data/)
**Videos relacionados:**
+ [Granular Access with AWS Resource Access Manager](https://www.youtube.com/watch?v=X3HskbPqR2s)
+ [Securing your data perimeter with VPC endpoints](https://www.youtube.com/watch?v=iu0-o6hiPpI)
+ [ Establishing a data perimeter on AWS](https://www.youtube.com/watch?v=SMi5OBjp1fI)
**Herramientas relacionadas:**
+ [ Data Perimeter Policy Examples ](https://github.com/aws-samples/data-perimeter-policy-examples)
# SEC03-BP09 Uso compartido seguro de recursos con terceros
La seguridad de su entorno en la nube no se limita a su organización. Su organización puede recurrir a terceros para administrar una parte de sus datos. La administración de permisos para el sistema administrado por terceros debe seguir la práctica del acceso justo a tiempo mediante el principio del privilegio mínimo con credenciales temporales. Si colabora estrechamente con un tercero, podrán reducir juntos el alcance del impacto y el riesgo de un acceso no intencionado.
**Resultado deseado:** evita el uso de credenciales a largo plazo de AWS Identity and Access Management (IAM), como claves de acceso y claves secretas, ya que representan un riesgo para la seguridad si se utilizan indebidamente. En su lugar, utiliza los roles de IAM y las credenciales temporales para mejorar su posición de seguridad y minimizar la sobrecarga operativa que implica la administración de credenciales a largo plazo. Al conceder acceso a terceros, utiliza un identificador único universal (UUID) como ID externo en la política de confianza de IAM y mantiene bajo su control las políticas de IAM asociadas al rol para garantizar acceso con privilegios mínimos. Para obtener orientaciones prescriptivas sobre el análisis de recursos compartidos externamente, consulte [SEC03-BP07 Análisis del acceso público y entre cuentas](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html).
**Patrones comunes de uso no recomendados:**
+ Utilizar la política de confianza de IAM predeterminada sin ninguna condición.
+ Utilizar claves de acceso y credenciales de IAM a largo plazo.
+ Reutilizar ID externos.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
Es posible que desee permitir que se compartan recursos fuera de AWS Organizations o conceder a un tercero acceso a su cuenta. Por ejemplo, es posible que un tercero le proporcione una solución de supervisión que necesite acceder a los recursos de su cuenta. En esos casos, cree un rol entre cuentas de IAM con solo los privilegios que necesite el tercero. Defina, además, una política de confianza mediante la [condición de ID externo](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html). Cuando utilice un ID externo, usted o el tercero podrán generar un ID único para cada cliente, tercero o tenencia. El ID único no debe controlarlo nadie más que usted después de crearlo. El tercero debe implementar un proceso para relacionar el ID externo con el cliente de una forma segura, auditable y reproducible.
También puede utilizar [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) para administrar los roles de IAM para aplicaciones externas a AWS que usan las API de AWS.
Si el tercero ya no necesita acceder a su entorno, elimine el rol. Procure no proporcionar credenciales a largo plazo a terceros. Conozca otros servicios de AWS que permiten el uso compartido, como AWS Well-Architected Tool, que permite [compartir una carga de trabajo](https://docs.aws.amazon.com/wellarchitected/latest/userguide/workloads-sharing.html) con otras Cuentas de AWS, y [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html), que lo ayuda a compartir de forma segura un recurso de AWS de su propiedad con otras cuentas.
### Pasos para la implementación
1. **Utilice roles entre cuentas para permitir el acceso a cuentas externas.** Los [roles entre cuentas](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) reducen la cantidad de información confidencial que almacenan las cuentas externas y los terceros para atender a sus clientes. Los roles entre cuentas le permiten conceder acceso a los recursos de AWS de su cuenta de forma segura a terceros, como Socios de AWS u otras cuentas de su organización, al tiempo que mantiene la capacidad de administrar y auditar dicho acceso. El tercero podría estar prestando servicio desde una infraestructura híbrida o extrayendo datos a una ubicación externa. [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) lo ayuda a permitir que las cargas de trabajo de terceros interactúen de forma segura con sus cargas de trabajo de AWS y a reducir aún más la necesidad de credenciales a largo plazo.
No debe utilizar credenciales a largo plazo ni claves de acceso asociadas a usuarios para proporcionar acceso a cuentas externas. En su lugar, utilice roles entre cuentas para proporcionar el acceso entre cuentas.
1. **Actúe con la diligencia debida y garantice el acceso seguro para los proveedores de SaaS de terceros.** Al compartir recursos con proveedores de SaaS externos, actúe estrictamente con la diligencia debida para garantizar que ofrezca una estrategia segura y responsable de acceso a sus recursos de AWS. Evalúe su modelo de responsabilidad compartida para comprender qué medidas de seguridad ofrecen y cuáles son de su responsabilidad. Asegúrese de que el proveedor de SaaS cuente con un proceso seguro y auditable de acceder a sus recursos, incluido el uso de [identificadores externos](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html) y los principios de acceso con privilegios mínimos. El uso de ID externos ayuda a resolver el [problema de la sustitución confusa](https://aws.amazon.com/blogs/security/how-to-use-external-id-when-granting-access-to-your-aws-resources/).
Implemente controles de seguridad para garantizar un acceso seguro y el cumplimiento del principio de privilegios mínimos al conceder acceso a proveedores de SaaS externos. Esto puede incluir el uso de identificadores externos, identificadores únicos universales (UUID) y políticas de confianza de IAM que limitan el acceso únicamente a lo estrictamente necesario. Trabaje en estrecha colaboración con el proveedor de SaaS para establecer mecanismos de acceso seguro, revise periódicamente su acceso a sus recursos de AWS y lleve a cabo auditorías para garantizar el cumplimiento de sus requisitos de seguridad.
1. **Declare obsoletas las credenciales a largo plazo proporcionadas por el cliente.** Declare obsoleto el uso de credenciales a largo plazo y utilice roles de cuentas cruzadas o IAM Roles Anywhere. Si debe utilizar credenciales a largo plazo, establezca un plan para migrar al acceso basado en roles. Para obtener más información sobre la administración de claves, consulte [Administración de identidades.](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-management.html) Reúnase también con su equipo de Cuenta de AWS y el tercero para establecer un manual de procedimientos de mitigación de riesgos. Para obtener orientación normativa sobre cómo responder y mitigar el impacto potencial de un incidente de seguridad, consulte [Respuesta ante incidentes](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html).
1. **Compruebe que la configuración cuente con una guía prescriptiva o que esté automatizada.** El ID externo no debe tratarse como un secreto, pero no debe ser un valor fácil de adivinar, como un número de teléfono, un nombre o un ID de cuenta. Convierta el ID externo en un campo de solo lectura para que no pueda modificarse con el fin de suplantar la configuración.
El ID externo puede generarlo usted o el tercero. Defina un proceso para determinar quién es el responsable de generar el ID. Independientemente de la entidad que cree el ID externo, el tercero aplica la unicidad y los formatos de manera uniforme en todos los clientes.
La política que se cree para el acceso entre cuentas en sus cuentas debe seguir el [principio del privilegio mínimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege). El tercero debe proporcionarle un documento de políticas de roles o un mecanismo de configuración automatizado que utilice una plantilla de AWS CloudFormation o algo equivalente. Esto reduce la posibilidad de que se produzcan errores asociados a la creación manual de políticas y ofrece un registro de seguimiento auditable. Para obtener más información sobre el uso de una plantilla de AWS CloudFormation para crear roles entre cuentas, consulte [Cross-Account Roles](https://aws.amazon.com/blogs/apn/tag/cross-account-roles/).
El tercero debe proporcionar un mecanismo de configuración automatizado y auditable. Sin embargo, debería automatizar la configuración del rol mediante el documento de la política de roles que describe el acceso necesario. Con una plantilla de AWS CloudFormation o un elemento equivalente, debe supervisar los cambios y utilizar la detección de desviaciones como parte de la práctica de auditoría.
1. **Tenga en cuenta los cambios.** La estructura de su cuenta, su necesidad de utilizar al tercero o la oferta de servicios que este presta pueden cambiar. Debe anticiparse a los cambios y a los fallos, y planificar en consecuencia las personas, los procesos y la tecnología adecuados. Audite de forma periódica el nivel de acceso que proporciona e implemente métodos de detección que lo alerten de cambios inesperados. Monitoree y audite el uso del rol y el almacén de datos de los ID externos. Debe tenerlo todo preparado para revocar el acceso del tercero, de forma temporal o permanente, a causa de cambios o patrones de acceso inesperados. Asimismo, mida el impacto en su operación de revocación, incluido el tiempo que lleva hacerla, las personas implicadas, el costo y el impacto en otros recursos.
Para obtener una guía prescriptiva sobre los métodos de detección, consulte las [prácticas recomendadas de detección](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html).
## Recursos
**Prácticas recomendadas relacionadas:**
+ [SEC02-BP02 Uso de credenciales temporales](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC03-BP05 Definición de las barreras de protección de los permisos para una organización](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_define_guardrails.html)
+ [SEC03-BP06 Administración del acceso en función del ciclo de vida](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_lifecycle.html)
+ [SEC03-BP07 Análisis del acceso público y entre cuentas](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)
+ [SEC04 Detección](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)
**Documentos relacionados:**
+ [Propietario de bucket que concede permisos entre cuentas para objetos que no le pertenecen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [How to use trust policies with IAM roles](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [Delegación del acceso entre Cuentas de AWS mediante roles de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)
+ [¿Cómo accedo a los recursos de otra Cuenta de AWS mediante IAM?](https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-iam/)
+ [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) (Prácticas recomendadas de seguridad en IAM)
+ [Lógica de evaluación de políticas entre cuentas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)
+ [Cómo utilizar un ID externo al otorgar acceso a los recursos de AWS a terceros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
+ [Collecting Information from AWS CloudFormation Resources Created in External Accounts with Custom Resources](https://aws.amazon.com/blogs/apn/collecting-information-from-aws-cloudformation-resources-created-in-external-accounts-with-custom-resources/)
+ [Securely Using External ID for Accessing AWS Accounts Owned by Others](https://aws.amazon.com/blogs/apn/securely-using-external-id-for-accessing-aws-accounts-owned-by-others/)
+ [Extend IAM roles to workloads outside of IAM with IAM Roles Anywhere](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/)
**Videos relacionados:**
+ [How do I allow users or roles in a separate Cuenta de AWS access to my Cuenta de AWS?](https://www.youtube.com/watch?v=20tr9gUY4i0)
+ [AWS re:Invent 2018: Become an IAM Policy Master in 60 Minutes or Less](https://www.youtube.com/watch?v=YQsK4MtsELU)
+ [AWS Knowledge Center Live: IAM Best Practices and Design Decisions ](https://www.youtube.com/watch?v=xzDFPIQy4Ks)
**Ejemplos relacionados:**
+ [Configurar el acceso entre cuentas a Amazon DynamoDB](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/configure-cross-account-access-to-amazon-dynamodb.html)
+ [AWS STS Network Query Tool](https://github.com/aws-samples/aws-sts-network-query-tool)