SEC03-BP03 Establecer un proceso de acceso de emergencia - AWS Well-Architected Framework
Guía para la implementación Recursos

SEC03-BP03 Establecer 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) 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. Puede que las preguntas y las prácticas recomendadas en el Pilar de fiabilidad le resulten útiles para identificar los modos de error y diseñar sistemas más resilientes para minimizar la probabilidad de que se produzcan errores.

  • Ha documentado los pasos que se deben seguir para confirmar que la avería 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 de error. La especificidad puede reducir la tentación de los usuarios de abusar de un proceso general para todo tipo de emergencias. Sus 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 guías de estrategia que se pueden seguir de forma rápida y eficiente. Recuerde que un evento de emergencia puede resultar estresante para sus usuarios, ya que 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 ensayados. Sus usuarios no están preparados para emergencias y siguen procesos improvisados cuando estas se producen.

  • Sus procesos de acceso de emergencia dependen 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 repercutir en su capacidad para recuperarse del error.

  • Sus procesos de acceso de emergencia se utilizan 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 realizar cambios directamente que enviarlos a través de una canalización.

  • Sus procesos de acceso de emergencia no generan registros suficientes para auditar los procesos, o los registros no se supervisan para alertar de un posible uso indebido de los procesos.

Beneficios de establecer esta práctica recomendada:

  • Si cuenta con procesos de acceso de emergencia bien documentados y ensayados, 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 realizar un seguimiento de cada solicitud de acceso de emergencia y detectar y alertar sobre intentos no autorizados de utilizar indebidamente el proceso para eventos que no sean de emergencia.

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 desplegadas 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 supone 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). Por ejemplo, cree de antemano el acceso de emergencia a la Cuenta de AWS con roles y IAM users, y los roles de IAM entre cuentas en todas las cuentas de la carga de trabajo. Esto asegura que estos recursos estén listos y disponibles cuando ocurra una emergencia. Al crear de antemano los recursos, no depende de las API del plano de control de AWS (utilizadas para crear y modificar los recursos de AWS) que podrían no estar disponibles en caso de emergencia. Además, al crear de antemano los recursos de IAM, no es necesario tener en cuenta los posibles retrasos debido a una coherencia eventual.

  • Incluya los procesos de acceso de emergencia como parte de sus planes de administración de incidentes (SEC10-BP02). Documente cómo se realiza 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, realizar un seguimiento de la solicitud en cada etapa del flujo de trabajo y añadir 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 realizar un seguimiento de esas solicitudes en un solo sistema, analizar las tendencias de uso y mejorar sus procesos.

  • Compruebe que solo los 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 las solicitudes de aprobación admiten aprobadores secundarios si los principales no están disponibles y cómo se escalan en la cadena de administración hasta la aprobación.

  • Compruebe que el proceso genere registros y eventos de auditoría detallados para los intentos correctos e infructuosos de obtener acceso de emergencia. Supervise tanto el proceso de solicitud como el mecanismo de acceso de emergencia para detectar el uso indebido o los accesos no autorizados. Correlacione la actividad con los eventos de emergencia en curso de su sistema de administración de incidentes y alerte cuando se produzcan acciones fuera de los períodos de tiempo esperados. Por ejemplo, debe supervisar y alertar si se produce actividad en la Cuenta de AWS de acceso de emergencia, ya que nunca debe usarse en operaciones normales.

  • Pruebe los procesos de acceso de emergencia de manera periódica para comprobar que los pasos estén claros y para 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 ante incidentes (SEC10-BP07) y pruebas de recuperación de desastres (REL13-BP03).

Modo de error 1: el proveedor de identidades utilizado para federarse en AWS no está disponible

Como se describe en SEC02-BP04 Recurrir a un proveedor de identidades centralizado, recomendamos confiar en un proveedor de identidades centralizado para federar a los usuarios de su plantilla y concederles acceso a las Cuentas de AWS. Puede federar varias Cuentas de AWS en su organización de AWS con IAM Identity Center, o puede federar Cuentas de AWS individuales con 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 realizar 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 período, 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 realizar 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 roles de IAM y IAM users) 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 de antemano un conjunto de IAM users para los administradores de emergencias de la cuenta de acceso de emergencia con contraseñas seguras y tokens de MFA asociados. Estos IAM users 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 realizar la acción de cambio de emergencia. La ventaja de este enfoque es que cada IAM user se asigna a un administrador de emergencias y usted puede saber qué usuario inició sesión revisando los eventos de CloudTrail. La desventaja es que hay que mantener varios IAM users con sus contraseñas de larga duración y los tokens de MFA asociados.

  • Puede utilizar el usuario raíz de la Cuenta de AWS 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 el IAM Identity Center con un proveedor de identidades externo o crear un proveedor de identidades de IAM (SEC02-BP04). Por lo general, se configuran importando un documento XML de metadatos de SAML proporcionado por el proveedor de identidades. El documento XML de metadatos incluye un certificado X.509 correspondiente 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. Ambos escenarios 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 importando 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 realicen 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 un 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 AWS Management Console.

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 la sección sobre la configuración del acceso de emergencia a la AWS Management Console.

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 IAM users, y opcionalmente, proveedores de identidades de IAM. Además, cree de antemano roles de IAM entre cuentas en la 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 el AWS CloudFormation StackSets con AWS Organizations para crear dichos recursos en las cuentas de los miembros de su organización.

  • Cree políticas de control de servicios (SCP) de AWS Organizations para denegar la eliminación y modificación de los roles de IAM entre cuentas en las Cuentas de AWS miembro.

  • 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:

    • Con IAM users: cree de antemano los IAM users con contraseñas seguras y los dispositivos MFA asociados.

    • Con el 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

  • Como se detalla en la configuración del acceso de emergencia a la AWS Management Console, 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 por Well-Architected:

Documentos relacionados:

Vídeos relacionados:

Ejemplos relacionados: