SCS-Lab1 — CloudTrail: Trail + S3 + KMS + Log Validation

Región: us-east-1

Duración estimada: 35–55 minutos

Costo-riesgo: Medio

Certificación: AWS Certified Security - Specialty (SCS-C03)

Dominio: Detection

Tarea 1.2: Design and implement logging solutions

Caso de uso

Digital Cafe Luna ya superó sus primeros tropiezos operativos. La aplicación que apoya facturación e inventario funciona mejor, el negocio va creciendo y ahora más personas interactúan en la plataforma. Robert, compañero de estudio de Camilo, también está colaborando con algunos ajustes técnicos.

Un día, la Sra. Blanca nota un comportamiento extraño en el aplicativo y hace la pregunta incómoda:

“¿Quién cambió qué y cuándo?”

Camilo duda. No sabe si el cambio lo hizo él, Robert o algún proceso de la cuenta. Ahí entiende algo clave: no basta con tener recursos funcionando, se necesita trazabilidad para investigar cambios, responder con evidencia y proteger los registros que cuentan la historia de lo ocurrido.

Sin auditoría, investigar se vuelve opinión.

En este laboratorio vamos a construir un baseline de auditoría en una sola cuenta AWS usando AWS CloudTrail, Amazon S3, AWS KMS y log file validation. No es una estrategia multi-account todavía; es la base para registrar actividad, almacenar logs, cifrarlos y validar su integridad.

¿Qué vamos a construir?

En este laboratorio vas a crear:

Un CloudTrail Trail multi-region.
Un bucket S3 dedicado para logs.
Bloqueo de acceso público y versioning en S3.
Una KMS key administrada por el cliente.
Una key policy para permitir uso desde CloudTrail.
Log file validation.
Una prueba controlada para buscar evidencia en CloudTrail.
Cleanup completo.

Figura 1 — CloudTrail registra actividad, entrega logs en S3, los protege con KMS y habilita validación de integridad.

Nota de alcance

Este laboratorio se ejecuta en una sola cuenta AWS. Más adelante puede evolucionar hacia un Organization Trail, pero aquí nos enfocamos en el fundamento: crear el trail, enviar logs a S3, cifrarlos y validar integridad.

Convención de nombres

Recurso	Nombre
CloudTrail Trail	`scs-lab1-trail`
S3 Bucket	`scs-lab1-cloudtrail-logs-<tu-alias>-<4digitos>`
KMS Key Alias	`alias/scs-lab1-cloudtrail`
S3 Prefix	`cloudtrail/`

Nota práctica: el bucket de S3 debe tener un nombre único globalmente, por eso usamos <tu-alias>-<4digitos>.

Requisitos previos

Cuenta AWS con permisos para CloudTrail, S3 y KMS.
Región us-east-1.
Acceso a AWS Console y CloudShell o AWS CLI local.
Un sufijo único para el bucket. Ejemplo: camilo-4721.
Entender que este lab es single account.

Ojo: este laboratorio toca KMS. Si tu cuenta tiene políticas restrictivas, lo más común es fallar por permisos en la key policy.

Paso 1 — Crear el bucket S3 para los logs

CloudTrail necesita un destino para entregar logs. Usaremos un bucket dedicado, con acceso público bloqueado y versioning habilitado.

Crear el bucket desde la consola

En AWS Console:

Ve a S3 → Buckets.
Selecciona Create bucket.
Usa el nombre scs-lab1-cloudtrail-logs-<tu-alias>-<4digitos>.
Región: us-east-1.
Deja Block Public Access habilitado.
En Bucket Versioning, selecciona Enable.
Crea el bucket.

CLI opcional

REGION="us-east-1"
LAB_ID="scs-lab1"
ALIAS="camilo"
SUFFIX="4721"

BUCKET="${LAB_ID}-cloudtrail-logs-${ALIAS}-${SUFFIX}"

aws s3api create-bucket \
  --region "$REGION" \
  --bucket "$BUCKET"

aws s3api put-public-access-block \
  --region "$REGION" \
  --bucket "$BUCKET" \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

aws s3api put-bucket-versioning \
  --region "$REGION" \
  --bucket "$BUCKET" \
  --versioning-configuration Status=Enabled

aws s3api put-bucket-tagging \
  --region "$REGION" \
  --bucket "$BUCKET" \
  --tagging "TagSet=[{Key=Name,Value=${LAB_ID}-cloudtrail-logs},{Key=Lab,Value=${LAB_ID}}]"

aws s3api get-bucket-versioning \
  --region "$REGION" \
  --bucket "$BUCKET"

aws s3api get-public-access-block \
  --region "$REGION" \
  --bucket "$BUCKET"

Checkpoint

Valida que:

El bucket existe en us-east-1.
Block Public Access está activo.
Bucket Versioning está en Enabled.
El bucket tiene el tag Lab=scs-lab1.

Paso 2 — Crear la KMS key

Ahora crearemos una KMS key administrada por el cliente para cifrar los logs de CloudTrail con SSE-KMS.

Crear la KMS key desde la consola

En AWS Console:

Ve a KMS → Customer managed keys.
Selecciona Create key.
Tipo: Symmetric.
Uso: Encrypt and decrypt.
Alias: alias/scs-lab1-cloudtrail.
En Key administrators, selecciona tu usuario o rol administrador.
En Key users, agrega también tu usuario o rol administrador.
Crea la key.

Agregar permiso para CloudTrail

En la key:

Entra a Key policy.
Selecciona Edit.
Agrega este statement sin eliminar los permisos administrativos existentes.

{
  "Sid": "AllowCloudTrailToUseTheKey",
  "Effect": "Allow",
  "Principal": {
    "Service": "cloudtrail.amazonaws.com"
  },
  "Action": [
    "kms:GenerateDataKey*",
    "kms:Encrypt",
    "kms:Decrypt",
    "kms:DescribeKey"
  ],
  "Resource": "*"
}

Ojo: el principal debe ser cloudtrail.amazonaws.com como Service principal.

CLI opcional para validar

REGION="us-east-1"

aws kms describe-key \
  --region "$REGION" \
  --key-id "alias/scs-lab1-cloudtrail" \
  --query "{KeyId:KeyMetadata.KeyId,Arn:KeyMetadata.Arn,State:KeyMetadata.KeyState,Usage:KeyMetadata.KeyUsage}" \
  --output table

aws kms list-aliases \
  --region "$REGION" \
  --query "Aliases[?AliasName=='alias/scs-lab1-cloudtrail'].[AliasName,TargetKeyId]" \
  --output table

Checkpoint

Valida que:

La key está en estado Enabled.
El alias existe.
Tu usuario o rol conserva permisos.
La key policy permite uso desde CloudTrail.

Paso 3 — Crear el CloudTrail Trail multi-region

Ahora vamos a crear el trail para registrar actividad de la cuenta y conservar evidencia en S3.

Crear el trail desde la consola

En AWS Console:

Ve a CloudTrail → Trails.
Selecciona Create trail.
Nombre: scs-lab1-trail.
En Storage location, selecciona Use existing S3 bucket.
Elige el bucket del lab.
Si usas prefijo, coloca cloudtrail.
Habilita Log file SSE-KMS encryption.
Selecciona alias/scs-lab1-cloudtrail.
Habilita Log file validation.
Asegúrate de que sea multi-region.

En eventos:

Management events: habilitado.
Read: habilitado.
Write: habilitado.
Data events: deshabilitado.
Insights events: deshabilitado.
Network activity events: deshabilitado.

CLI opcional para validar

REGION="us-east-1"

aws cloudtrail describe-trails --region "$REGION" \
  --query "trailList[?Name=='scs-lab1-trail'].[Name,S3BucketName,IsMultiRegionTrail,KmsKeyId,LogFileValidationEnabled]" \
  --output table

aws cloudtrail get-trail-status --region "$REGION" \
  --name "scs-lab1-trail" \
  --query "{IsLogging:IsLogging,LatestDeliveryTime:LatestDeliveryTime,LatestDigestDeliveryTime:LatestDigestDeliveryTime,LatestDeliveryError:LatestDeliveryError}" \
  --output table

Checkpoint

Valida que:

IsMultiRegionTrail aparece como true.
LogFileValidationEnabled aparece como true.
IsLogging aparece como true.
LatestDeliveryError está vacío o sin errores relevantes.

Paso 4 — Generar un evento y confirmar entrega

Crear CloudTrail no basta. Hay que validar que registra eventos y entrega logs en S3.

Acción en AWS → CloudTrail → S3 bucket → Evidencia disponible

Generar un evento desde la consola

Puedes crear una access key temporal solo como evento de prueba:

Ve a IAM → Users.
Selecciona tu usuario.
Entra a Security credentials.
En Access keys, selecciona Create access key.
Crea la key solo para generar el evento.
No la uses para nada productivo.

Ojo: elimina esta access key en el cleanup.

También puedes usar un cambio menor, como agregar un tag no crítico.

Validar entrega por CLI

REGION="us-east-1"

aws cloudtrail get-trail-status --region "$REGION" \
  --name "scs-lab1-trail" \
  --query "{IsLogging:IsLogging,LatestDeliveryTime:LatestDeliveryTime,LatestDeliveryError:LatestDeliveryError}" \
  --output table

Ajusta BUCKET con tu bucket real:

REGION="us-east-1"
BUCKET="scs-lab1-cloudtrail-logs-camilo-4721"
ACCOUNT_ID="$(aws sts get-caller-identity --query Account --output text)"

aws s3 ls "s3://$BUCKET/cloudtrail/AWSLogs/$ACCOUNT_ID/" \
  --recursive \
  --human-readable \
  --summarize | tail -n 20

Si no usaste prefijo:

aws s3 ls "s3://$BUCKET/AWSLogs/$ACCOUNT_ID/" \
  --recursive \
  --human-readable \
  --summarize | tail -n 20

Paso 5 — Verificar cifrado y log file validation

Ahora validamos que los logs estén cifrados con SSE-KMS y que CloudTrail genere archivos digest para integridad.

Validar desde la consola

En AWS Console:

Ve a CloudTrail → Trails.
Abre scs-lab1-trail.
Valida:
- Log file SSE-KMS encryption: Enabled.
- AWS KMS key: alias/scs-lab1-cloudtrail.
- Log file validation: Enabled.

Confirmar por CLI

REGION="us-east-1"

aws cloudtrail describe-trails --region "$REGION" \
  --query "trailList[?Name=='scs-lab1-trail'].[Name,IsMultiRegionTrail,LogFileValidationEnabled,KmsKeyId,S3BucketName,S3KeyPrefix]" \
  --output table

Verifica objetos digest:

BUCKET="scs-lab1-cloudtrail-logs-camilo-4721"
ACCOUNT_ID="$(aws sts get-caller-identity --query Account --output text)"

aws s3 ls "s3://$BUCKET/cloudtrail/AWSLogs/$ACCOUNT_ID/CloudTrail-Digest/" \
  --recursive | tail -n 10

Verifica cifrado en un objeto real:

BUCKET="scs-lab1-cloudtrail-logs-camilo-4721"
ACCOUNT_ID="$(aws sts get-caller-identity --query Account --output text)"

OBJ_KEY=$(aws s3api list-objects-v2 \
  --bucket "$BUCKET" \
  --prefix "cloudtrail/AWSLogs/$ACCOUNT_ID/CloudTrail/" \
  --query "reverse(sort_by(Contents,&LastModified))[0].Key" \
  --output text)

echo "$OBJ_KEY"

aws s3api head-object \
  --bucket "$BUCKET" \
  --key "$OBJ_KEY" \
  --query "{SSE:ServerSideEncryption,KMSKey:SSEKMSKeyId}" \
  --output table

Salida esperada:

SSE     aws:kms
KMSKey  arn:aws:kms:...

Paso 6 — Buscar el cambio en CloudTrail

Ahora usamos CloudTrail para responder con evidencia:

“¿Quién cambió qué y cuándo?”

Buscar desde la consola

En AWS Console:

Ve a CloudTrail → Event history.
En Lookup attributes, filtra según la acción.
Si creaste una access key, busca:
- Event name: CreateAccessKey.
- Event name: DeleteAccessKey, si ya la eliminaste.
Abre el evento y revisa:
- Event name
- Event time
- User name / ARN
- Source IP address
- AWS Region
- User agent

Buscar por CLI

REGION="us-east-1"

START_TIME=$(date -u -d '60 minutes ago' +"%Y-%m-%dT%H:%M:%SZ")

aws cloudtrail lookup-events --region "$REGION" \
  --start-time "$START_TIME" \
  --max-results 10 \
  --query "Events[].{Time:EventTime,Name:EventName,User:Username,EventId:EventId}" \
  --output table

Por evento específico:

REGION="us-east-1"

aws cloudtrail lookup-events --region "$REGION" \
  --lookup-attributes AttributeKey=EventName,AttributeValue=CreateAccessKey \
  --max-results 5 \
  --query "Events[].{Time:EventTime,Name:EventName,User:Username,EventId:EventId}" \
  --output table

Detalle del evento:

REGION="us-east-1"

aws cloudtrail lookup-events --region "$REGION" \
  --lookup-attributes AttributeKey=EventName,AttributeValue=CreateAccessKey \
  --max-results 1 \
  --query "Events[0].CloudTrailEvent" \
  --output text

Ojo: si estás en Mac y date -d no funciona, ejecuta esa parte desde CloudShell o ajusta el cálculo de tiempo.

Clean up completo — SCS-Lab1

Elimina los recursos para evitar costos y mantener la cuenta limpia.

Recursos a eliminar

CloudTrail Trail: scs-lab1-trail
S3 Bucket: scs-lab1-cloudtrail-logs-<tu-alias>-<4digitos>
KMS Key: alias/scs-lab1-cloudtrail
Access key temporal: si la creaste

Orden recomendado

Elimina la access key temporal.
Elimina el CloudTrail Trail.
Vacía y elimina el S3 Bucket.
Agenda la eliminación de la KMS Key.

Desde la consola

En CloudTrail → Trails, elimina scs-lab1-trail.
En S3 → Buckets, vacía y elimina el bucket del lab.
En KMS → Customer managed keys, selecciona la key y usa Schedule key deletion.

Ojo: si versioning está habilitado, revisa versiones y delete markers antes de eliminar el bucket.

CLI opcional para validar cleanup

REGION="us-east-1"

aws cloudtrail describe-trails --region "$REGION" \
  --query "trailList[?Name=='scs-lab1-trail'].[Name]" \
  --output table

BUCKET="scs-lab1-cloudtrail-logs-camilo-4721"

if aws s3api head-bucket --bucket "$BUCKET" 2>/dev/null; then
  echo "Bucket aún existe: $BUCKET"
else
  echo "Bucket eliminado o no accesible: $BUCKET"
fi

REGION="us-east-1"

aws kms describe-key \
  --region "$REGION" \
  --key-id "alias/scs-lab1-cloudtrail" \
  --query "{KeyId:KeyMetadata.KeyId,State:KeyMetadata.KeyState,DeletionDate:KeyMetadata.DeletionDate}" \
  --output table

Troubleshooting rápido

CloudTrail no entrega logs en S3: revisa LatestDeliveryError, bucket policy, prefijo y KMS.
KMS policy falla: valida Principal.Service = cloudtrail.amazonaws.com.
No aparecen objetos digest: espera unos minutos y confirma que ya llegan logs normales.
OBJ_KEY sale como None: revisa si usaste prefijo cloudtrail.
El bucket no se deja borrar: elimina contenido, versiones y delete markers.
No puedes agendar eliminación de la KMS key: valida que sigues siendo administrador de la key.

Well-Architected lens: ¿Qué aplicamos aquí?

Security: pasamos de sospechas a evidencia verificable.
Operational Excellence: dejamos un flujo repetible de investigación.
Reliability: reducimos cambios silenciosos sin trazabilidad.
Cost Optimization: mantenemos el lab autocontenido y con cleanup completo.
Performance Efficiency: evitamos data events e Insights para no recolectar señales innecesarias.

Resultado esperado

Al finalizar deberías poder crear un baseline de auditoría en una cuenta AWS: trail multi-region, logs en S3, cifrado con KMS, validación de integridad, búsqueda de eventos y cleanup completo.

La idea no era solo “prender CloudTrail”, sino dejar evidencia auditable, protegida y verificable.

Al final, Camilo puede responder con más claridad:

“¿Quién cambió qué y cuándo?”

Referencias oficiales

¿Qué viene en el próximo lab?

Digital Cafe Luna ya tiene una base de auditoría en una sola cuenta. El siguiente paso es prepararse para un reto real: escalar

SAA-Lab1 — Scaling en AWS (baseline): ALB + Auto Scaling + CloudFront

Montaremos un baseline de escalamiento con balanceo, escalado automático y caché en el borde, usando el dominio por defecto de CloudFront.

Nos vemos en el próximo laboratorio de Digital Cafe Luna.

SCS-Lab1 — CloudTrail: Trail + S3 + KMS + Log Validation

Caso de uso

¿Qué vamos a construir?

Nota de alcance

Convención de nombres

Requisitos previos

Paso 1 — Crear el bucket S3 para los logs

Crear el bucket desde la consola

CLI opcional

Checkpoint

Paso 2 — Crear la KMS key

Crear la KMS key desde la consola

Agregar permiso para CloudTrail

CLI opcional para validar

Checkpoint

Paso 3 — Crear el CloudTrail Trail multi-region

Crear el trail desde la consola

CLI opcional para validar

Checkpoint

Paso 4 — Generar un evento y confirmar entrega

Generar un evento desde la consola

Validar entrega por CLI

Paso 5 — Verificar cifrado y log file validation

Validar desde la consola

Confirmar por CLI

Paso 6 — Buscar el cambio en CloudTrail

Buscar desde la consola

Buscar por CLI

Clean up completo — SCS-Lab1

Recursos a eliminar

Orden recomendado

Desde la consola

CLI opcional para validar cleanup

Troubleshooting rápido

Well-Architected lens: ¿Qué aplicamos aquí?

Resultado esperado

Referencias oficiales

¿Qué viene en el próximo lab?

Tags

Author

Stats

Published

You Might Also Like

Why does AI forget what you said (and how to fix it)

Vibecoding Our First MCP Server

Getting Claude Code off my laptop and onto shared compute

I Stopped Dragging Boxes in Draw.io (Here's What I Do Instead)

Hack your AWS CLI to add CloudShell support and turn your terminal into a bastion

Securing auth in a large-scale production system: three industry-standard architectures — and why none survived a closer look