Seguridad

Por qué el usuario root de una cuenta AWS es peligroso - Filosofía de diseño de separación de privilegios y práctica de sellado

Explicamos por qué el usuario root de AWS tiene privilegios que IAM no puede restringir, la lista de operaciones que solo el usuario root puede realizar, cómo configurar MFA y la estrategia de sellado mediante la gestión de acceso root de Organizations.

約 5 分で読めます

Los privilegios del usuario root - IAM no puede restringirlos

El usuario root de una cuenta AWS tiene acceso completo a todos los recursos dentro de esa cuenta. No puede restringirse con políticas IAM. Ni las políticas Deny de IAM ni las Service Control Policies (SCP) pueden limitar los permisos del usuario root. Las SCP se aplican al usuario root de cuentas miembro, pero no al usuario root de la cuenta de gestión. Esta es una decisión de diseño intencional. El usuario root es el "propietario" de la cuenta y debe poder recuperar el control incluso cuando las políticas IAM están mal configuradas. Sin embargo, este mismo poder lo convierte en el mayor riesgo de seguridad de la cuenta.

Operaciones que solo el usuario root puede realizar

La razón por la que el usuario root no puede sellarse completamente es que existen operaciones que solo él puede ejecutar. Los cambios de configuración de la cuenta (nombre de cuenta, dirección de correo electrónico, cambio de contraseña) solo pueden realizarse con el usuario root. El cambio de plan de soporte de AWS también requiere el usuario root. Si se deniega explícitamente el acceso de todos en una política de bucket de S3, solo el usuario root puede modificar esa política de bucket. El cierre de la cuenta AWS también es una operación exclusiva del root. La restauración de permisos cuando una política IAM se configura incorrectamente y bloquea a todos los usuarios también requiere el usuario root. Estas operaciones son poco frecuentes pero críticas, por lo que el usuario root debe mantenerse disponible pero estrictamente protegido.

MFA del usuario root - La llave de hardware es la más fuerte

Es obligatorio configurar MFA (autenticación multifactor) para el usuario root. Un usuario root sin MFA puede iniciar sesión solo con dirección de correo electrónico y contraseña, siendo vulnerable a phishing y ataques de listas de contraseñas. Hay 3 tipos de dispositivos MFA. Los dispositivos MFA virtuales (Google Authenticator, Authy, etc.) son los más convenientes pero conllevan el riesgo de perder acceso por pérdida o avería del smartphone. Las llaves de seguridad FIDO2 (YubiKey, etc.) son dispositivos de hardware que proporcionan la autenticación más fuerte y son resistentes a phishing. Los dispositivos MFA de hardware (tipo token) generan códigos de un solo uso sin conexión a red. Para el usuario root, se recomienda una llave de seguridad FIDO2 como MFA principal y un dispositivo MFA virtual como respaldo, almacenados en una caja fuerte física.

Gestión centralizada de acceso root mediante Organizations

Si se utiliza AWS Organizations, la función de "gestión centralizada de acceso root" introducida en 2024 permite eliminar las credenciales del usuario root de las cuentas miembro. Al habilitar esta función, se eliminan la contraseña y MFA del usuario root de las cuentas miembro, haciendo imposible el inicio de sesión como usuario root. Cuando se necesita una operación que solo el root puede realizar (como la corrección de una política de bucket de S3), se puede ejecutar una "sesión root privilegiada" temporal desde la cuenta de gestión. Esta sesión tiene un tiempo de expiración y se registra en CloudTrail, proporcionando auditabilidad. Esta función es la mejor práctica actual para el sellado del usuario root.

Monitoreo del usuario root - Detección inmediata si se usa

Si se usa el usuario root, eso en sí mismo es una situación anormal. Si se ha establecido una operación donde el usuario root no se usa en el trabajo diario, un inicio de sesión del usuario root sugiere la posibilidad de acceso no autorizado. CloudTrail registra todas las llamadas API del usuario root. Se configura un filtro de métricas en CloudWatch Logs para detectar llamadas API del usuario root, y se configura una alarma de CloudWatch para notificación inmediata vía SNS. EventBridge también puede detectar eventos de inicio de sesión del usuario root y activar una función Lambda para respuesta automática. Se recomienda configurar alertas para que cualquier uso del usuario root se notifique inmediatamente al equipo de seguridad. Para aprender mejores prácticas de seguridad de AWS, los libros especializados (Amazon) son una buena referencia.

Servicios relacionados

AWS IAMServicio de autenticación y autorización para gestionar de forma segura el acceso a los recursos de AWSAWS OrganizationsServicio para gestionar centralmente múltiples cuentas de AWS

Artículos relacionados

Lógica de evaluación de políticas IAM explicada - Cómo la denegación implícita pierde ante la autorización explícitaUna explicación paso a paso de cómo IAM evalúa las solicitudes para permitirlas o denegarlas, cubriendo la prioridad de denegación implícita, autorización explícita y denegación explícita, así como la lógica de intersección para SCPs, límites de permisos y políticas de sesión.La estructura oculta de los 12 dígitos del ID de cuenta de AWS - Por qué son 12 dígitos y qué se puede inferirUna exploración curiosa de por qué los ID de cuenta de AWS son números de 12 dígitos, la intención de diseño incorporada en la estructura ARN, y las consideraciones de seguridad sobre lo que se puede inferir a partir de un ID de cuenta.Capacidad de diseño de gobernanza multi-cuenta en AWS - Gobernanza organizacional con Organizations, Control Tower y SCPComparamos el mecanismo de gobernanza multi-cuenta centrado en AWS Organizations, Control Tower y SCP (Service Control Policies) con Azure Management Groups, explicando la diferencia en capacidad de diseño de gobernanza empresarial.

Más sobre este tema

Detección de permisos excesivos con IAM Access Analyzer - Análisis de acceso externo y permisos no utilizadosDetecta permisos no utilizados en roles IAM mediante análisis basado en CloudTrail y genera automáticamente políticas de mínimo privilegio. Cubre la detección de acceso externo y la integración de verificaciones de políticas personalizadas en pipelines CI/CD.Automatización de la gestión de certificados SSL/TLS con AWS Certificate Manager - Desde la emisión hasta la rotaciónExplicamos la emisión gratuita de certificados públicos con ACM, la validación DNS, la renovación automática y el despliegue en ALB y CloudFront.Obtención de informes de cumplimiento con AWS Artifact - Respuesta a auditorías y gestión de contratosPresenta cómo obtener informes de auditoría SOC, PCI DSS e ISO bajo demanda, y aplicar BAA y GDPR DPA de forma masiva a toda la organización con Organizations.Automatización de auditorías - Recopilación continua de evidencias de cumplimiento con AWS Audit ManagerExplica la recopilación automática de evidencias de auditoría con AWS Audit Manager. Presenta la evaluación automática basada en frameworks (SOC 2, PCI DSS, GDPR, etc.), gestión centralizada de evidencias y generación de informes de auditoría.La estructura oculta de los 12 dígitos del ID de cuenta de AWS - Por qué son 12 dígitos y qué se puede inferirUna exploración curiosa de por qué los ID de cuenta de AWS son números de 12 dígitos, la intención de diseño incorporada en la estructura ARN, y las consideraciones de seguridad sobre lo que se puede inferir a partir de un ID de cuenta.Gestión de certificados y HTTPS - Operaciones automatizadas de certificados TLS con AWS Certificate ManagerAprenda sobre la emisión de certificados TLS/SSL, renovación automática y despliegue usando AWS Certificate Manager (ACM). Cubre la integración con CloudFront, ALB y API Gateway, validación DNS y uso de Private CA.Gestión dedicada de claves con AWS CloudHSM - Cifrado compatible con FIPS 140-2 Level 3Logre gestión de claves compatible con FIPS 140-2 Level 3 con instancias HSM dedicadas. Aprenda cuándo elegir CloudHSM sobre KMS y cómo integrar ambos mediante almacenes de claves personalizados de KMS.CloudTrail lo ve todo - Mecanismo de registro de llamadas API y práctica de investigación forenseExplicamos cómo CloudTrail registra las llamadas a la API de AWS, las diferencias entre eventos de administración y eventos de datos, el análisis SQL con CloudTrail Lake y las técnicas de investigación forense ante incidentes de seguridad.

Artículos y servicios similares

Amazon CognitoServicio completamente administrado que añade funcionalidad de autenticación y autorización a aplicaciones web y móviles, compatible con login social y federación SAMLAWS ConfigUn servicio que registra y evalúa cambios de configuración de recursos AWS y monitorea el cumplimiento continuamenteAWS Trusted AdvisorServicio que proporciona recomendaciones en tiempo real para optimizar su entorno de AWSDiseño de gestión de identidad y acceso - Lograr seguridad Zero Trust con IAMAprende técnicas de diseño de gestión de acceso con AWS IAM, incluyendo el principio de mínimo privilegio, diseño de políticas y lograr seguridad Zero Trust mediante integración con Cognito.