SEC10-BP05 Acceso previo a la provisión - AWS Marco Well-Architected

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

SEC10-BP05 Acceso previo a la provisión

Compruebe que los equipos de respuesta a incidentes dispongan del acceso correcto previamente aprovisionado AWS para reducir el tiempo necesario desde la investigación hasta la recuperación.

Patrones comunes de uso no recomendados:

  • Usar la cuenta raíz para la respuesta ante incidentes.

  • Alterar las cuentas existentes.

  • Manipular IAM los permisos directamente al proporcionar una elevación de privilegios. just-in-time

Nivel de riesgo expuesto si no se establece esta práctica recomendada: medio

Guía para la implementación

AWS recomienda reducir o eliminar la dependencia de credenciales de larga duración siempre que sea posible, en favor de las credenciales temporales y los mecanismos de escalamiento de just-in-timeprivilegios. Las credenciales de larga duración están expuestas a riesgos de seguridad y aumentan la carga operativa. Para la mayoría de las tareas de administración, así como para las tareas de respuesta ante incidentes, le recomendamos que implemente la federación de identidades junto con el escalado temporal para el acceso administrativo. En este modelo, un usuario solicita el aumento a un nivel superior de privilegios (como un rol de respuesta ante incidentes) y, siempre que el usuario reúna los requisitos para el aumento, se envía una solicitud a un aprobador. Si se aprueba la solicitud, el usuario recibe un conjunto de credenciales de AWS temporales que puede utilizar para completar sus tareas. Una vez que caducan estas credenciales, el usuario debe enviar una nueva solicitud de aumento.

Recomendamos el uso del escalado temporal de privilegios en la mayoría de las situaciones de respuesta ante incidentes. La forma correcta de hacerlo es utilizar AWS Security Token Service y las políticas de sesión para limitar el acceso.

Hay situaciones en las que las identidades federadas no están disponibles; por ejemplo:

  • Interrupción relacionada con un proveedor de identidades (IdP) comprometido.

  • Una configuración deficiente o un error humano provocan la ruptura del sistema de administración de acceso federado.

  • Actividades malintencionadas, como un evento de denegación de servicio (DDoS) distribuido o que haga que el sistema deje de estar disponible.

En los casos anteriores, debe haber un acceso de emergencia break glass configurado para permitir la investigación y la reparación oportuna de los incidentes. Se recomienda utilizar un usuario, grupo o rol con los permisos adecuados para realizar tareas y acceder a AWS los recursos. Utilice el usuario raíz únicamente para llevar a cabo tareas que requieran credenciales de usuario raíz. Para comprobar que los equipos de respuesta a incidentes tienen el nivel de acceso correcto a AWS y a otros sistemas pertinentes, recomendamos el aprovisionamiento previo de cuentas dedicadas. Las cuentas requieren un acceso con privilegios y se deben controlar y supervisar de forma estricta. Las cuentas deben crearse con el menor número de privilegios requeridos para llevar a cabo las tareas necesarias y el nivel de acceso debe basarse en las guías de estrategias creadas como parte del plan de administración de incidentes.

La práctica recomendada es crear usuarios y roles personalizados y exclusivos. Si se amplía temporalmente el acceso de los usuarios o los roles mediante la adición de IAM políticas, no queda claro qué tipo de acceso tenían los usuarios durante el incidente y se corre el riesgo de que los privilegios incrementados no se revoquen.

Es importante eliminar tantas dependencias como sea posible para verificar que se puede acceder en el mayor número posible de escenarios de error. Para respaldarlo, cree un manual para comprobar que los usuarios que responden a incidentes se crean como usuarios de una cuenta de seguridad dedicada y no se administran a través de ninguna solución existente de federación o inicio de sesión único (). SSO Cada miembro del equipo de intervención debe tener su propia cuenta con nombre. La configuración de la cuenta debe aplicar una política de contraseñas seguras y una autenticación multifactorial (). MFA Si los manuales de respuesta a incidentes solo requieren acceso a ellos AWS Management Console, el usuario no debe tener configuradas las claves de acceso y se le debe impedir explícitamente crear claves de acceso. Esto se puede configurar con IAM políticas o políticas de control de servicios (SCPs), tal como se menciona en las prácticas recomendadas AWS de seguridad para. AWS Organizations SCPs Los usuarios solo deben tener el privilegio de poder asumir roles de respuesta ante incidentes en otras cuentas.

Durante un incidente, podría ser necesario conceder acceso a otras personas internas o externas para respaldar las actividades de investigación, reparación o recuperación. En este caso, utilice el mecanismo de guía de estrategias mencionado anteriormente. Debe haber un proceso para verificar que cualquier acceso adicional se revoque inmediatamente después de que finalice el incidente.

Para comprobar que el uso de las funciones de respuesta a incidentes se puede supervisar y auditar adecuadamente, es esencial que las IAM cuentas creadas con este fin no se compartan entre personas y que no Usuario raíz de la cuenta de AWS se utilicen a menos que sean necesarias para una tarea específica. Si se requiere el usuario raíz (por ejemplo, si el IAM acceso a una cuenta específica no está disponible), utilice un proceso independiente con un manual disponible para comprobar la disponibilidad de las credenciales de inicio de sesión y el token del usuario raíz. MFA

Para configurar las IAM políticas de las funciones de respuesta a incidentes, considere la posibilidad de utilizar IAMAccess Analyzer para generar políticas basadas en los registros. AWS CloudTrail Para ello, conceda acceso de administrador al rol de respuesta ante incidentes en una cuenta que no sea de producción y ejecute las guías de estrategias. Una vez completado, se puede crear una política que únicamente permita las acciones hechas. Esta política se puede aplicar a los roles de respuesta ante incidentes en todas las cuentas. Es posible que desee crear una IAM política independiente para cada manual de estrategias a fin de facilitar la administración y la auditoría. Entre los ejemplos de manuales de estrategias se podrían incluir planes de respuesta para ransomware, vulneraciones de datos, pérdida de acceso a la producción y otras situaciones.

Utilice las cuentas de respuesta a incidentes para asumir IAMfunciones específicas de respuesta a incidentes en otras Cuentas de AWS cuentas. Estas funciones deben configurarse para que solo las puedan asumir los usuarios de la cuenta de seguridad, y la relación de confianza debe requerir que la persona que realiza la llamada se haya autenticado mediante ellas. MFA Los roles deben usar políticas de amplio alcance para controlar el accesoIAM. Asegúrese de que todas las AssumeRole solicitudes de estas funciones estén iniciadas y se hayan recibido alertas, CloudTrail y de que se registre cualquier acción que se lleve a cabo con estas funciones.

Se recomienda encarecidamente que tanto las IAM cuentas como los IAM roles tengan un nombre claro para poder encontrarlos fácilmente en CloudTrail los registros. Un ejemplo de ello sería asignar un nombre a las IAM cuentas <USER_ID>-BREAK-GLASS y los IAM rolesBREAK-GLASS-ROLE.

CloudTrailse usa para registrar API la actividad en sus AWS cuentas y debe usarse para configurar alertas sobre el uso de las funciones de respuesta a incidentes. Consulte la publicación del blog sobre la configuración de alertas cuando se utilizan claves de usuario raíz. Las instrucciones se pueden modificar para configurar la CloudWatch métrica de Amazon filter-to-filter sobre AssumeRole los eventos relacionados con la IAM función de respuesta a incidentes:

{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "<INCIDENT_RESPONSE_ROLE_ARN>" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }

Como es probable que los roles de respuesta ante incidentes tengan un nivel de acceso alto, es importante que estas alertas lleguen a un grupo amplio y se actúe con rapidez.

Durante un incidente, es posible que un respondedor necesite acceder a sistemas que no están protegidos directamente por ellosIAM. Estas podrían incluir instancias de Amazon Elastic Compute Cloud, bases de datos de Amazon Relational Database Service software-as-a-service o plataformas (SaaS). Se recomienda encarecidamente que, en lugar de utilizar protocolos nativos, como SSH oRDP, AWS Systems Manager Session Managerse utilice para todos los accesos administrativos a las EC2 instancias de Amazon. Este acceso se puede controlar medianteIAM, que es seguro y está auditado. También es posible automatizar partes de sus guías de estrategias mediante documentos de ejecución de comandos de AWS Systems Manager, lo que puede reducir los errores de los usuarios y mejorar el tiempo de recuperación. Para acceder a bases de datos y herramientas de terceros, recomendamos almacenar las credenciales de acceso AWS Secrets Manager y conceder el acceso a las funciones de respuesta a incidentes.

Por último, la gestión de las IAM cuentas de respuesta a incidentes debe añadirse a sus procesos de registro, traslado y abandono, y revisarse y probarse periódicamente para comprobar que solo se permite el acceso previsto.

Recursos

Documentos relacionados:

Videos relacionados:

Ejemplos relacionados: