¿Te gustaría aprender Amazon Web Services Desde Cero?
Tenemos los cursos que necesitas. ¡Haz clic aquí!
Cuando los clientes operan su infraestructura en su propio centro de datos, en sus premisas o en una de terceros, son responsables de la seguridad en todos los niveles: desde el ambiente físico (servidores, almacenamiento, redes, bases de datos, etc) hasta los datos introducidos en la aplicación. Y también de las capas intermedias: de la administración de identidad y control de acceso, instalación del sistema operativo y aplicaciones, así como parches y otras configuraciones de seguridad.
Sin embargo, cuando los clientes inician su camino en AWS, utilizando aplicaciones de negocios existentes o desarrollando nuevas aplicaciones en la nube, pasan a adoptar un Modelo de Responsabilidad Compartida. En este modelo, AWS implementa, opera, administra y controla los componentes de seguridad desde las instalaciones físicas hasta la capa del host de virtualización en que operan los servicios, reduciendo así una parte significativa del peso operativo del lado del cliente.
En este escenario, AWS es responsable de la seguridad DE la nube y el cliente es responsable de la seguridad EN la nube. Para tener más detalles sobre el Modelo de Responsabilidad Compartida se puede ingresar a este sitio web o al documento de AWS Security Best Practices. Este documento detalla el Modelo de Responsabilidad Compartida, dividiendo los servicios en tres categorías: servicios de infraestructura, servicios autocontenidos y servicios abstractos.
Los servicios de seguridad ofrecidos por AWS permiten que empresas altamente reguladas en diversas partes del mundo adopten las prácticas recomendadas de protección de la información y datos sensibles, para que puedan cumplir sus obligaciones de protección de secretos y privacidad de datos. Estos servicios son desarrollados por ingenieros con conocimiento de las prácticas recomendadas de seguridad y con una amplia visión de las tendencias globales y evolución de las amenazas cibernéticas. De esta forma, los clientes de AWS pueden adoptar prácticas proactivas de gestión de riesgos cibernéticos emergentes, prácticamente en tiempo real, pagando sólo por lo que consumen.
Esto significa que el cliente puede elegir e implementar la seguridad que mejor se adapte a su necesidad en cada etapa de su trayecto en la nube, sin preocuparse de gastos iniciales y con una sobrecarga operacional significativamente menor, comparada con la de un entorno implementado con infraestructura propia.
Los servicios de seguridad en la nube AWS se dividen en 5 pilares fundamentales. En cada uno de ellos existen múltiples servicios que se pueden adoptar con el objetivo de aumentar el nivel de seguridad en términos de protección de datos y adaptación operativa en la nube AWS. Para mayor información sobre los servicios de seguridad el sitio del mismo contiene la información necesaria para su uso.
Una vez definida la estrategia de adopción de la nube AWS, es muy importante establecer cual será la de seguridad, basándose en servicios, prácticas y controles, insertándola como pieza fundamental de este trayecto. En esta definición es posible conciliar la agilidad en atender las necesidades del negocio, con la implementación de un ambiente seguro: es posible ser ágil y seguro al mismo tiempo.
Con el objetivo de establecer requisitos mínimos y deseables basados en la experiencia y las mejores prácticas, diversos frameworks y estándares pueden ser considerados: por ejemplo, NIST Cybersecurity Framework (CSF), PCI Data Security Standard (DSS), Well-Architected Framework o Cloud Adoption Framework (CAF), entre otros. En base a estos frameworks y estándares, las empresas pueden definir sus prácticas y controles de seguridad. Y a partir de ellos, elegir qué servicios de seguridad se adoptarán, y en qué momento.
En esta serie de 3 artículos, trataremos un modelo de evolución de seguridad EN la nube, que puede ser utilizado como ejemplo para la implementación de los servicios de seguridad de AWS, permitiendo escalar rápidamente el nivel de madurez de seguridad de su ambiente a medida que se adopta la nube AWS.
Los bloques son los siguientes:
- Etapa de Accesos – Adopción de mejores prácticas y servicios para controlar el acceso a los recursos en AWS.
- Etapa de Visibilidad y Control – Adopción de mejores prácticas y servicios para aumentar la visibilidad y el control en AWS.
- Etapa de Automatización – Adopción de mejores prácticas y servicios para automatización de seguridad e implementación de principios de DevSecOps, Security by Design y Security as Code.
Las tres etapas se pueden realizar paralelamente, brindando agilidad en la adopción de controles de seguridad a su entorno.
Abordaremos las mejores prácticas de gestión de identidad y accesos, considerando la adopción de los servicios AWS Organizations, IAM, SSO, Session Manager (Systems Manager) y Directory Services.
1.Uso de AWS Organizations
- Es fundamental definir un modelo de múltiples cuentas utilizando AWS Organizations para separar los entornos de producción, desarrollo, pruebas (sandbox), auditoría, seguridad y otros que tengan sentido para su modelo de negocio, creando así una capa de aislamiento lógico entre las diferentes cuentas utilizando también la función de SCP (Service Control Policies) para permitir, por ejemplo, limitar el uso sólo a servicios y regiones autorizados, así como la limitación de los cambios en la configuración de seguridad de los buckets de S3.
A continuación, presentamos algunas políticas de ejemplo que se aplicaron en el escenario de cuentas anteriormente presentado. Es importante destacar que estos son ejemplos de políticas de SCP. Para más información y personalización para su entorno es importante evaluar la documentación de AWS Organizations y de SCP.
- Ejemplo de SCP para denegación de servicios de seguridad: bloquea el acceso a los servicios de seguridad en la cuenta de producción. Incluso si un usuario tiene permisos administrativos en la cuenta de producción, no tendrá acceso a deshabilitar, por ejemplo, CloudTrail o acceder a GuardDuty, Inspector y SecurityHub:
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “Stmt1548170128000”,
“Effect”: “Deny”,
“Action”: [
“cloudtrail:*”
],
“Resource”: [
“*”
]
},
{
“Sid”: “Stmt1548170142000”,
“Effect”: “Deny”,
“Action”: [
“guardduty:*”
],
“Resource”: [
“*”
]
},
{
“Sid”: “Stmt1548170151000”,
“Effect”: “Deny”,
“Action”: [
“inspector:*”
],
“Resource”: [
“*”
]
},
{
“Sid”: “Stmt1548170170000”,
“Effect”: “Deny”,
“Action”: [
“securityhub:*”
],
“Resource”: [
“*”
]
}
]
}
- Ejemplo de SCP para habilitar el acceso a una lista de servicios: habilitación sólo de servicios autorizados en producción, en cuyo caso se ha configurado el RDS, EC2, ECR, S3 y Autoscaling.
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “Stmt1550329049000”,
“Effect”: “Allow”,
“Action”: [
“rds:*”
],
“Resource”: [
“*”
]
},
{
“Sid”: “Stmt1550329060000”,
“Effect”: “Allow”,
“Action”: [
“ec2:*”
],
“Resource”: [
“*”
]
},
{
“Sid”: “Stmt1550329065000”,
“Effect”: “Allow”,
“Action”: [
“autoscaling:*”
],
“Resource”: [
“*”
]
},
{
“Sid”: “Stmt1550329071000”,
“Effect”: “Allow”,
“Action”: [
“ecr:*”
],
“Resource”: [
“*”
]
},
{
“Sid”: “Stmt1550329080000”,
“Effect”: “Allow”,
“Action”: [
“s3:*”
],
“Resource”: [
“*”
]
}
]
}
- Ejemplo de denegación de acceso público a S3: fuerza el bloqueo de cambio de configuración de buckets S3 utilizando la característica Amazon S3 Block Public Access.
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “Stmt1548173791000”,
“Effect”: “Deny”,
“Action”: [
“s3:GetAccountPublicAccessBlock”,
“s3:GetBucketPublicAccessBlock”,
“s3:PutAccountPublicAccessBlock”,
“s3:PutBucketPublicAccessBlock”
],
“Resource”: [
“*”
]
}
]
}
Otras políticas de SCP y modelo de múltiples cuentas pueden y deben ser consideradas para satisfacer sus necesidades de controles de seguridad. Para mayor información, existen dos webinars que pueden facilitar esta tarea: Applying AWS Organizations to Complex Account Structures y AWS re:Invent 2018: Architecting Security & Governance across your AWS Landing Zone.
2. Uso de Session Manager para controlar el acceso de usuarios con privilegios administrativos a entornos de servidores Windows y Linux.
- Controlar el acceso de usuarios con privilegios administrativos es fundamental y la capacidad de utilizar un segundo factor de autenticación para estos usuarios de forma integrada es aún más relevante. Session Manager permite registrar todos los comandos ejecutados por los usuarios administradores en las máquinas virtuales, la entrada de los comandos y la salida de los mismos. Además, permite proteger estos registros contra su eliminación utilizando una capa de encripción.
3. Uso del AWS SSO + AWS AD + AWS Organizations Mapping para administrar perfiles de acceso en el entorno de múltiples cuentas.
Una vez que se adopta el modelo de múltiples cuentas para separar entornos como práctica de seguridad, es posible también utilizar el Servicio AWS SSO junto con el servicio AWS Directory Services, con el objetivo de optimizar el la asignación de permisos en múltiples cuentas AWS agregando usuarios a grupos de AD con un conjunto de permisos (permission sets) previamente definidos. Esto permite controlar el acceso a múltiples cuentas del mismo cliente.
En el siguiente ejemplo se muestra un escenario donde los usuarios admin1, dba1, security1 y auditor1, cuando se insertan en grupos de AD, reciben permisos definidos previamente para el grupo y que permiten acceder a roles a cada una de las cuentas AWS (Prod, Dev, Test, Sandbox). En este escenario, por ejemplo, el usuario admin1 tiene acceso del administrador del sistema en las cuentas de Prod, Dev, Test y Sandbox.
Esta configuración permite una integración simplificada con bases autoritativas ya existentes en un ambiente tradicional y que pueden popular usuarios de forma automatizada en grupos de AD en base a sus funciones. Por ejemplo: un dba se inserta al grupo AWS_DBA del AD y automáticamente obtiene el acceso previamente definido en los ambientes correctos.
De la misma forma, cuando un usuario se remueve de la base autoritativa y, por consiguiente, del grupo de AD, perderá el acceso a los entornos y a cuentas AWS automáticamente.
4. Prácticas Recomendadas de Gestión de Acceso – Además de la utilización de los servicios presentados anteriormente es importante considerar la adopción de prácticas como las siguientes:
- Definir un proceso de administración de las cuentas de AWS. Adopte un modelo de gobierno que permita crear de forma coherente todas las configuraciones iniciales de las cuentas y deje clara la responsabilidad y la propiedad de las cuentas, utilizando, por ejemplo, el servicio Control Tower para la aplicación de guardrails de forma automática durante la creación de nuevas cuentas.
- Configurar correctamente la información de contacto (especialmente el contacto de seguridad) de cada una de las cuentas que se actualizará utilizando la consola AWS.
- Considerar el uso de listas de distribución en lugar de correos de usuarios individuales como contactos de las cuentas AWS. Esto permite que un grupo de personas reciba las comunicaciones. Además, permite seguir utilizando el mismo contacto cuando se producen cambios internos y minimiza los tiempos para atender comunicaciones sensibles.
- Requerir autenticación fuerte (token/múltiple factor de autenticación) de todos los usuarios de IAM con credenciales y contraseñas de acceso a la consola de AWS. Considere también el uso de MFA cuando se integra con AD y SSO.
- Definir una política de contraseña para las cuentas de AWS, que requiera tamaño mínimo, cierto nivel de complejidad para contraseñas asociadas a los usuarios y una política de rotación obligatoria que requiera a los usuarios que las cambien a intervalos regulares.
- Restringir el uso de cuentas con acceso privilegiado, especialmente la primera cuenta creada en el entorno de AWS. La cuenta root, como se conoce, sólo se debe utilizar para crear otro conjunto inicial de usuarios y grupos de IAM que se utilizarán en la operación diaria. Esta cuenta debe estar debidamente protegida y sus credenciales de acceso almacenadas de forma segura, incluyendo la creación de un segundo factor de autenticación (MFA).
- Evaluar el establecimiento de confianza con proveedores de identidad, ya existentes en su organización. El uso de la federación reduce la necesidad de crear usuarios manualmente en el servicio IAM de AWS y además permite aprovechar usuarios e identidades ya existentes, además de roles y responsabilidades ya asignados en su organización. El uso del SSO como presentado anteriormente debe ser considerado.
- Adoptar el principio de mínimo privilegio, garantizando que las identidades autenticadas sólo tendrán permiso para realizar el conjunto mínimo de funciones necesarias para cumplir con tareas específicas. La granularidad de accesos en AWS se implementa a través de la definición de roles y políticas definidas en el IAM.
- Considerar la adopción del servicio AWS Organizations para administrar de forma centralizada varias cuentas de AWS. Además del agrupamiento de cuentas en unidades organizativas (OUs), permite la aplicación de políticas de seguridad y control centralizado de costos de varias cuentas y/o departamentos que usen los servicios de AWS.
- Utilice la función de Secrets Manager para proteger las credenciales de acceso de las aplicaciones, evitando así la exposición de credenciales de acceso a archivos de configuración o sitios desprotegidos, además de rotar periódicamente estas credenciales de acceso de forma automatizada.
- Realizar revisiones de acceso periódicas por lo menos cada 3 meses, o según lo determinado en su política de seguridad, evaluando posibles accesos concedidos y no utilizados, a través de recursos como el IAM Access Advisor disponible en la herramienta AWS IAM.
- En el modelo Organizations, considerar el uso de cuentas dedicadas para el equipo de seguridad, almacenando registros de auditoría y otra información sensible y relevante para la Seguridad de la Información.
- Siempre que sea posible utilizar los mecanismos de roles para dar acceso a los recursos en servidores/instancias EC2 y otros recursos en AWS.
