Letra Chica — Qué cambió en la letra chica

[Corregido] [AWS] CloudTrail crea el trail de organización en las cuentas miembro aunque falle la validación del bucket o de la clave

2026-10-24T00:00:00Z

CloudTrail crea el trail de organización en las cuentas miembro aunque falle la validación de un recurso; la documentación da como ejemplos una bucket policy incorrecta y permisos insuficientes para cifrar con una clave KMS. Que el apply termine bien no prueba que haya entrega. Revisá get-trail-status: si hay un problema con el bucket, el campo LatestDeliveryError muestra el error de S3 (solo aparece por problemas del bucket de destino, no por requests que expiran). Corregilo con la bucket policy, o creando otro bucket y llamando a update-trail.

[Corregido] [AWS] En el ejemplo oficial, la bucket policy de un trail de organización necesita su propia sentencia y los logs son accesibles solo para management

2026-10-24T00:00:00Z

Alcance de la fuente: el ejemplo oficial es de un bucket que pertenece a la cuenta de management de la organización; la documentación no cubre un bucket en otra cuenta (como la de log archive de este módulo), así que probalo en un entorno de prueba. El bucket de un trail de organización necesita una policy que deje a CloudTrail escribir los logs de la organización: el ejemplo oficial tiene tres sentencias (GetBucketAcl, PutObject en el prefijo de la cuenta de management y PutObject en el prefijo AWSLogs/o-<id de la organización>/). El aws:SourceArn tiene que ser el ARN de un trail de la cuenta de management, con el ID de esa cuenta. Esa policy no da acceso a usuarios de las cuentas miembro: por defecto, los logs de la organización son accesibles solo para la cuenta de management. Listá de forma explícita a quién querés dar lectura y no asumas que las cuentas miembro leen.

[Corregido] [AWS] Si la home Region de un trail multi-región es opt-in, solo envían actividad las cuentas que habilitaron esa región

2026-10-24T00:00:00Z

Si el trail de organización es multi-región y su home Region es una región opt-in, las cuentas miembro no envían actividad al trail a menos que habiliten esa región; el ejemplo de la documentación es Europe (Spain): solo las cuentas que la habilitaron envían su actividad. Los trails de organización creados desde la consola son multi-región. Elegí como home Region una región habilitada por defecto, o verificá que cada cuenta habilitó la región; si una cuenta no aparece en el bucket, revisá este punto.

[Corregido] [AWS] Un trail mal configurado reintenta la entrega durante 30 días y esos intentos se cobran

2026-10-24T00:00:00Z

Si el trail está mal configurado (por ejemplo, el bucket no es alcanzable), CloudTrail intenta reentregar los logs al bucket durante 30 días, y esos intentos de entrega se cobran como CloudTrail estándar. Para evitar los cargos de un trail mal configurado hay que borrarlo. Corregí la bucket policy y la key policy antes de crear el trail (en Terraform, con depends_on del trail sobre ambas) y revisá get-trail-status después.

[Corregido] [AWS] Probá las SCP y las RCP en una OU o en cuentas de prueba antes de subir a la raíz; quitar FullAWSAccess sin reemplazo corta todas las acciones

2026-10-24T00:00:00Z

AWS recomienda con énfasis no adjuntar una SCP a la raíz sin probar su impacto en las cuentas: crear una OU y mover las cuentas de a una, o en grupos chicos, para no dejar a nadie sin acceso a servicios clave. Para las RCP recomienda empezar por cuentas de prueba, subir por las OU y revisar en CloudTrail los errores de acceso denegado. Además, no hay que quitar la política FullAWSAccess sin modificarla o reemplazarla por otra con las acciones permitidas: si no, fallan todas las acciones de AWS de las cuentas miembro. Para una S3 policy, después de cada cambio revisá la política efectiva de cuentas representativas con DescribeEffectivePolicy.

[Corregido] [Azure] Con Private Link al storage, un contenedor sin acceso anónimo requiere autorizar los pedidos, por ejemplo con SAS

2026-10-24T00:00:00Z

La guía de Front Door para un origen de Storage indica que, si el blob o el contenedor no permiten acceso anónimo, los pedidos contra ellos deben autorizarse, por ejemplo con shared access signatures, y lista como error común no usar SAS contra una cuenta que no permite acceso anónimo. Según la misma guía, el acceso desde internet público a la cuenta queda deshabilitado una vez que se habilita el private endpoint. ~~Entonces hay que~~Si ~~elegir:~~el contenedor ~~con lectura anónima de blobs,~~no ~~que~~permite ~~solo~~acceso seanónimo, ~~alcanza~~no ~~por~~conectes el ~~private endpoint, o~~origen ~~SAS~~sin enautorizar los pedidos. ~~Decidilo de forma explícita y no dejes el contenedor privado sin SAS.~~

[Corregido] [GCP] Si el bucket sigue siendo público, las URLs firmadas no protegen el contenido

2026-10-24T00:00:00Z

Para que las URLs firmadas protejan el contenido, el origen no debe dar acceso público: la documentación indica sacar los permisos de lectura de allUsers (y allAuthenticatedUsers, si aplica) del bucket, que es habitual dejar públicos durante las pruebas. Aun sin acceso público, quien ya tiene permiso sobre el bucket, por ejemplo OWNER, puede acceder a Cloud Storage sin URL firmada. Y una URL firmada da acceso por tiempo limitado a cualquiera que la tenga, sea o no usuario de Google. La misma página advierte que Cloud CDN no bloquea los pedidos sin parámetro Signature ni cookie Cloud-CDN-Cookie (rechaza los de parámetros inválidos) y que el origen debe validar las firmas y aceptar o rechazar los pedidos sin firma. Revisá que el bucket no tenga allUsers ni allAuthenticatedUsers antes de dar la entrada por cerrada, y firmá solo URLs HTTPS.

[Nuevo] [Azure] El Activity Log se borra a los 90 días; para conservarlo más hay que exportarlo con un diagnostic setting

2026-10-24T00:00:00Z

Azure Monitor recolecta el Activity Log sin configuración, pero retiene los eventos 90 días y después los borra. Para conservarlos más tiempo hay que crear un diagnostic setting que los envíe a otro destino (un workspace de Log Analytics, un storage account o Event Hubs). Importa por un dato en particular: el Activity Log es el único lugar donde se guarda quién creó un recurso. Si ya exportabas con log profiles (el método heredado), deshabilitá esa configuración al crear el diagnostic setting.