Tras explorar una serie de blogs sobre seguridad, hemos adquirido un conocimiento en torno a CloudTrail y S3. Hemos aprendido paso a paso cómo configurar y descargar registros de CloudTrail desde un bucket de S3, entendiendo la importancia cardinal de garantizar la integridad de esos logs.
Además, exploramos la configuración de la Autenticación de Múltiples Factores (MFA), acentuando su relevancia para la seguridad, y profundizamos en las consideraciones clave al emplear MFA Delete. Ahora, equipados con esta información, es el momento oportuno para abordar el siguiente capítulo: cómo verificar efectivamente el estado de nuestros logs almacenados en S3 y garantizar que todo esté en perfecto orden.
Verificando nuestros logs de CloudTrail en S3
Para determinar si tus trails de AWS CloudTrail están utilizando los buckets de S3 que han sido asignados para tal tarea, realiza las siguientes acciones:
1. Inicia sesión en tu cuenta AWS , Asumiendo que ya tienes la AWS CLI instalada y configurada, deberías poder realizar operaciones de CLI sin necesidad de iniciar sesión de nuevo. Si aún no has configurado la AWS CLI, puedes hacerlo con:
aws configure
2. Accede a la configuración de la regla del Nombre del Bucket del Trail e identifica el nombre del bucket de S3 designado para recibir y almacenar datos de CloudTrail. En este paso identificaremos el bucket de S3 que está asociado con nuestro trail de CloudTrail.
Ejecuta el comando list-trails con filtros de consulta para listar los nombres de todos los trails de CloudTrail creados en tu cuenta.
aws cloudtrail list-trails
--region eu-south-1
--query 'Trails[*].Name'
La salida del comando debería devolver un array con los nombres de trails de CloudTrail solicitados.
[
"ctaws-podcast-trail",
"ctaws-youtube-api-trail",
"ctaws-data-events-trail",
"ctaws-metrics-trail"
]
Ejecuta el comando describe-trails utilizando el nombre del trail que deseas examinar y filtros de consulta para obtener el nombre del bucket S3 configurado para almacenar registros para el rastro seleccionado (es decir, bucket objetivo):
aws cloudtrail describe-trails
--region eu-south-1
--trail-name-list ctaws-podcast-trail
--query 'trailList[*].S3BucketName'
La salida del comando debería devolver el nombre del bucket asociado:
[
"ctaws-podcast-cloudtrail-logs"
]
Verifica el nombre del bucket S3 devuelto por la salida del comando describe-trails. Si el nombre del bucket no coincide con el nombre del bucket S3 identificado tenemos un pequeño problema.
¿Qué hacer si nuestro bucket no coincide o no existe?
Si el bucket S3 que queremos ya existe, podemos actualizar la configuración y asociarlo al trail específico:
Ejecuta el comando update-trail utilizando el nombre del trail que deseas reconfigurar y actualiza la configuración de almacenamiento disponible para el trail seleccionado con el fin de aplicar el bucket designado:
aws cloudtrail update-trail
--region eu-south-1
--name ctaws-podcast-trail
--s3-bucket-name ctaws-podcast-trail-logs-bucket
La salida del comando debería mostrar los metadatos disponibles para el trail reconfigurado:
{
"IncludeGlobalServiceEvents": true,
"IsOrganizationTrail": false,
"Name": "ctaws-podcast-trail",
"TrailARN": "arn:aws:cloudtrail:eu-south-1:123456789012:trail/ctaws-podcast-trail",
"LogFileValidationEnabled": true,
"IsMultiRegionTrail": true,
"S3BucketName": "ctaws-podcast-trail-logs-bucket"
}
Si por el contrario el bucket no existe , podemos realizar las siguientes acciones:
Ejecuta el comando create-bucket para crear el bucket S3. Utiliza el nombre del bucket S3 designado (en nuestro ejemplo ctaws-podcast-trail-logs-bucket) como valor para el parámetro del comando –bucket:
aws s3api create-bucket
--bucket ctaws-podcast-trail-logs-bucket
--region eu-south-1
--acl private
Nota: Debes tener permiso WRITE_ACP para establecer la ACL de un objeto.
La salida del comando debería devolver el nombre del bucket S3 recién creado:
{
"Location": "/ctaws-podcast-trail-logs-bucket"
}
Ejecuta el comando put-public-access-block para habilitar la función de Bloqueo de Acceso Público de S3 para el nuevo bucket de S3 (el comando no debería producir una salida):
aws s3api put-public-access-block
--region eu-south-1
--bucket ctaws-podcast-trail-log-bucket
--public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
Nota: Si ya tienes una configuración de bloqueo de acceso público para el bucket y usas este comando nuevamente, esta configuración reemplazará la anterior.
Ejecuta el comando update-trail utilizando el nombre del recorrido de CloudTrail que deseas reconfigurar, para asociar el nuevo bucket de S3 (es decir, bucket objetivo) con el recorrido seleccionado:
aws cloudtrail update-trail
--region eu-south-1
--name ctaws-podcast-cloud-trail
--s3-bucket-name ctaws-podcast-trail-log-bucket
Y ya lo tendríamos. La salida del comando debería devolver los metadatos disponibles para el trail reconfigurado.
{
"IncludeGlobalServiceEvents": true,
"IsOrganizationTrail": false,
"Name": "ctaws-podcast-cloud-trail",
"TrailARN": "arn:aws:cloudtrail:eu-south-1:123456789012:trail/ctaws-podcast-trail",
"LogFileValidationEnabled": true,
"IsMultiRegionTrail": true,
"S3BucketName": "ctaws-podcast-trail-logs-bucket"
}
Conclusiones
En este blog hemos visto cómo verificar los registros de CloudTrail almacenados en un bucket de S3. Es importante verificar que el bucket destino sea el correcto. Si no es el bucket que deberíamos tener para la auditoría, podemos crear uno nuevo o modificar uno existente para asegurarnos que nuestra auditoría es correcta, y así ahorrarnos más de un quebradero de cabeza.
Top comments (0)