Seguimos con la serie de artículos dedicados a la construcción de una landing zone corporativa sobre AWS, y tras un primer escrito de introducción, seguido de los textos enfocados en el accounting y networking, le llega el turno al logging centralizado.
Si bien puede parecer un aspecto trivial, comprender cuál es el propósito real del mismo y la solución adecuada para llevarlo a cabo se vuelve fundamental para garantizar el éxito del journey to cloud de la organización a medio-largo plazo. Puede que ahora os parezca algo pretencioso, pero a medida que el volumen de negocio en la nube crece, tener estas cosas bajo control ayudan a evitar futuros dolores de cabeza, tanto en el ámbito legal como de seguridad.
Log Archive Account
A modo de resumen, en el artículo de accounting se describía la log-archive account como esa cuenta encargada de custodiar de forma centralizada, segura, duradera e inmutable, todos los logs generados a lo largo de todas las cuentas de la organización, forjando así una fuente de la verdad sobre la que los equipos de seguridad y auditoria pueden realizar análisis forenses o de cumplimiento legal.
Dada su importancia, se establecía como regla de oro la prohibición de desplegar cargas de trabajo sobre la misma, tratando de preservar así la inmutabilidad y confidencialidad del dato, junto a unas medidas de acceso extremadamente limitadas, con alarmas incluidas en cada incisión de sesión.
A estas alturas sobra repetir que no se trata de una cuenta de obervabilidad centralizada, y que si alguna aplicación o herramienta requiere consumir datos de la misma, lo deberá realizar desde su propia cuenta, mediante un cross-account-role de solo lectura y sobre aquellos registros estrictamente necesarios.
Una vez entendido a la perfección el propósito de la cuenta, es el momento de detallar donde y como debe ser almacenada toda esta información.
Single source of truth
Como no podía ser de otra forma, el producto de Amazon más adecuado para salvaguardar esta maraña de logs es AWS S3, un servicio de almacenamiento de objetos creado para almacenar y recuperar cualquier volumen de datos desde cualquier ubicación.
¿Que por qué es el más adecuado? Vaya pregunta…
- Porque se integra de forma nativa con la mayoría de los servicios de AWS para el almacenamiento de los logs.
- Porque garantiza un 99,99% de disponibilidad para los objetos almacenados, o lo que es lo mismo, el tiempo de inactividad no planeado asciende a un máximo de 4.38 minutos/mes o 52.6 minutos/año.
- Porque garantiza un 99,999999999% de durabilidad para los objetos almacenamos. Es decir, en caso de almacenar 10,000 objetos, garantiza que, de media, solo se pierde uno cada 10,000,000 años.
- Porque se integra con el sistema IAM (Identity and Access Management) para poder gestionar tanto la autenticación como autorización a grano fino de los objetos almacenados.
- Porque su modalidad Glacier, específicamente diseñada para el almacenamiento de datos de larga duración, tiene un coste irrisorio de 0,0036 USD por GB almacenado.
Ahora bien, un bucket S3 vanilla no garantiza de por si la seguridad, durabilidad e inmutabilidad de los datos, por lo que es imprescindible configurar al menos los siguientes aspectos:
- Establecer políticas de acceso extremadamente limitadas a nivel de bucket, y no solo a nivel de cuenta, para no exponer accidentalmente datos confidenciales de los clientes.
- Configurar el cifrado de datos en reposo para evitar que si atacante obtiene una unidad de disco duro, no pueda acceder al contenido del mismo. En este sentido, no queda otra que emplear una clave KMS de tipo SSE-S3, ya que las SSE-KMS no son compatibles con servicios como CloudFront o ALB. Es decir, en caso de aplicar este tipo de cifrado, no son capaces de almacenar su access-logs en el bucket.
- Establecer el multi-factor authentication para un borrado accidental de los datos.
- Configurar el versionado de los objetos para recuperar los datos en caso de sobre-escritura o borrado accidental de la información.
Una vez entendido a la perfección el propósito de la cuenta, así como el medio de almacenamiento, es el momento de detallar cómo debe ser almacenada toda esta información.
Solution Overview
El siguiente diagrama de arquitectura muestra el diseño de solución de logging centralizado que da respuesta a las necesidades previamente comentadas.
Tal y como se puede observar, la estrategia pasa por almacenar todos los logs de todos los servicios de cada cuenta en un bucket s3 local, que posteriormente es replicado de forma asíncrona sobre el bucket s3 centralizado de la cuenta log-archive-account.
Dado que el objetivo es almacenar esta información durante varios años y no disponibilizarla de inmediato (no se pretende realizar análisis en near-real-time de esta información), este delay carece de importancia, y permite homogeneizar la ingesta de datos (todos los servicios escriben directamente sobre el S3), simplificar la solución (bye bye kinesis firehose, stream y cia) y ahorrar un puñado de dólares a final de mes.
Sencillo, ¿no?
Conclusiones
En conclusión, se ha descrito un diseño de solución de logging encargado de aglutinar todos los logs generados a lo largo de todas las cuentas de la organización, de forma, segura, duradera e inmutable, para que los equipos de seguridad y auditoria pueden realizar análisis forenses o de cumplimiento legal, en caso de que sea necesario.
Para ello, se opta por almacenar los logs de todos los servicios de cada cuenta en un bucket s3 local y posteriormente replicarlo de forma asíncrona sobre el bucket s3 centralizado de la cuenta log-archive-account.
Como siempre, estad atentos al último artículo pendiente sobre cómo construir una Landing Zone corporativa sobre AWS, en el que se ahondará en el single sign-on.
Referencias
Se recomienda encarecidamente leer los siguientes artículos que han servido de base para el escrito:
- https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html#access-logs-choosing-s3-bucket
- https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html
- https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/query-logs.html
- https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-s3.html
Mikel's TechBlog 