En esta entrega analizaremos varios aspectos que nos ayudarán a definir si la operación de la carga de trabajo es segura. Aquí debemos cubrir varios aspectos, pero iniciaré con un tema sencillo como la separación de cuentas.
Separación de Cuentas
Es posible que, desde la conversación inicial podamos detectar al vuelo que en una misma cuenta se alberga el ambiente de desarrollo, pruebas y la carga productiva. O bien, tal vez no sea un tema de ambientes, sino que nos enteramos de que en la misma cuenta conviven el sistema de recursos humanos, la tienda virtual y el CRM, todos esos sistemas de naturalezas distintas, y a cargo de áreas de responsabilidad distintas e independientes.
Al ingresar a la consola, materializamos lo conversado, en la misma cuenta conviven un variopinto de cargas de trabajo, allí queda evidenciado que el diseño cayó en el error de no organizar las cuentas de forma separada, ya sea por función o ambiente.
En este punto, ya somos conscientes de que no se hizo uso de AWS Organizations, por lo tanto, nos encontramos ante el primer punto de mejora:
Cargas o ambientes diversos deben ser trabajados de manera separada y administrados por medio de AWS Organizations.
¿Por qué? En términos prácticos: aislamiento, gobernabilidad, manejo estándar de políticas, facturación y control de costos, entre otros. Esta recomendación ofrece los beneficios anteriores sin necesidad de gastar un dólar adicional.
Ahora bien, tal vez me adelante un poco, pero ya que entramos en este tema, verifiquemos si se hace uso de Control Tower. Esta herramienta nos da la confianza de que se respetan las buenas prácticas. Entre otros muchos beneficios, nos asegura que la incorporación de nuevas cuentas estará sujeta a un conjunto básico de protecciones, y su seguridad estará normada y no dependerá de la conciencia o pericia de quien sea designado para la apertura de la cuenta.
Retomando el punto de la naturaleza de las cargas, la recomendación general es: Use múltiples cuentas de AWS para reducir el impacto.
La información correspondiente a "Logs" y "Audit" debe mantenerse en cuentas separadas; esto protege la información de diagnóstico, valoración, etc., y facilita el manejo de roles y responsabilidades. En este punto ahondaré en la sección relacionada con el monitoreo, pero es importante resaltar en este momento que esta información se encuentre aislada y bajo un esquema de accesos distinta.
Recomendación:
- Naturalezas distintas: cuentas distintas
- Ambientes distintos: cuentas distintas
- Delegue a Control Tower el landing zone; esto le asegura buenas prácticas al generar nuevas cuentas.
Cómo promover esta mejora:
Algunas veces es complicado promover este tipo de cambios, planteemos al responsable los siguientes beneficios:
- Aislamiento de recursos
- Control granular
- Cumplimiento normativo
- Gestión de costos
- En caso de impacto, este se limita a la cuenta afectada, protegiendo los recursos en otras cuentas y probablemente de unidades independientes a la directamente afectada o causante.
Protección de las identidades
Quizás este es el más obvio de los puntos, sin embargo, en la vida real es muy muy común observar que se tiene una definición laxa de roles, grupos, usuarios y controles de acceso.
Definición y Protección de Identidades
En la teoría se refiere al proceso de administrar de manera segura y eficiente las identidades de usuarios y sistemas que interactúan con los recursos existentes. Esta definición contempla el planteamiento de políticas detalladas que controlan quién y a qué se puede acceder, contempla el doble factor de autenticación y monitoreo. Una correcta gestión además de proteger facilita auditoria y cumplimiento de normativa.
Nuestra misión aquí es: verificar que existan las medidas adecuadas para autenticar y autorizar usuarios y sistemas. En otras palabras, verifiquemos que solamente ingresa quien lo requiera y a lo que requiera, es decir, a lo estrictamente necesario.
Por lo tanto, procedamos a ubicar a los usuarios todopoderosos: cuántos, quiénes y por qué. Posteriormente el usuario más importante de todos, el usuario root. ¿Quién (o peor aún, quiénes) y para qué lo usan?
El usuario root es tan poderoso que no es una buena práctica su uso diario y continuo. Si al revisar logs corroboramos su uso constante, tenemos un hallazgo peligroso. Recordemos que este usuario se usa solamente para:
- Creación de cuenta
- Temas de pago y facturación
- Cerrar la cuenta
- Cambios de organización
Adicionalmente, debe estar protegido por un doble factor de autenticación; esto es indispensable y generalmente no es así.
Con respecto a los administradores, un recorrido breve es probable que identifique "miles" de usuarios (me perdonan la exageración) con privilegios de administrador, ¿ cuánto apostamos a que no ocupan esos superpoderes?
En síntesis, busquemos que existan roles con los permisos mínimos necesarios. Este es el momento para una charla con el cliente; necesitamos saber por qué están configurados esos privilegios, qué tareas deben ejecutar, y verificar que todos tienen el permiso mínimo necesario para atender sus tareas.
Beneficios de este Enfoque
- Evitamos tentaciones o accidentes
- Reducimos el riesgo de acceso no autorizado
- En caso de que las credenciales de un usuario se vean comprometidas, el impacto será reducido.
Hagamos memoria, ¿ cuántos casos se han escuchado de consecuencias graves para una empresa por el compromiso de unas credenciales?
Recomendación
El acceso de todos los usuarios debe ser asegurado mediante estos factores:
- ¿Quién soy? (mi identidad única)
- Lo que sé (mi contraseña)
- Lo que tengo (mi método de doble factor de autenticación) Esto garantiza que cada acceso esté autenticado, autorizado y registrado para un monitoreo exhaustivo y seguro.
Políticas de definición de Passwords
Otra arista de la protección de identidades corresponde a qué tan robustas son las políticas de passwords. Tal vez les resulte irónico, pero de las revisiones que he ejecutado, quizá el 80% de las cuentas no tienen una política robusta, a saber:
- Tamaño mínimo de 14 caracteres alfanuméricos con caracteres especiales
- Rotación periódica cada 30 días
- Prohibida la repetición
- MFA obligatorio: por hardware para root y administradores, y por software para el resto.
Generalmente he encontrado MFA inexistente, contraseñas de 6 caracteres y sin rotación. Todas las anteriores suelen ser hallazgos comunes en un WAR, todas exponiendo la cuenta y fáciles de corregir.
En la próxima entrega abordaré los temas relacionados con monitoreo y detección de incidentes.
Top comments (0)