La forma excesivamente compleja en que CloudTrail y CloudWatch Events funcionan juntos

Uno de los problemas más desconcertantes en mi trayectoria en el cloud ha sido entender cómo funcionan juntos CloudTrail y CloudWatch Events. Por alguna razón me tomó años (y muchas pruebas) comprender cómo funciona realmente la conexión; y en especial cómo funciona con el concepto de trails multirregión y de AWS Organization. Luego, una vez que lo entendí todo, supuse que ya todos lo sabían, pero conversaciones recientes han dejado claro que esta confusión es bastante común. Así que este es mi mejor intento por simplificar las cosas.

Primero, el problema que intentamos resolver: crear CloudWatch Rules basadas en CloudTrail Events y usarlas para enviar notificaciones o activar funciones Lambda.

Eso es todo: quiero enviar una notificación por algo tan simple como la llamada de API que abre una nueva regla de grupo de seguridad (AuthorizeSecurityGroupIngress, por si se lo preguntaba).

Para que esto funcione, necesita tener lo siguiente:

• CloudTrail habilitado en la región donde se realiza la llamada de API.
• CloudTrail transmitiendo a CloudWatch.
• Una CloudWatch Rule en la región de la llamada de API que busque esa llamada de API específica, o todas las llamadas de API de CloudTrail.

Ahora viene la confusión:

• Cuando crea un CloudTrail multirregión o un trail de Organization, tras bambalinas AWS en realidad configura trails en cada una de las regiones (y en cada cuenta, en el caso de un trail de Organization). Todos son trails independientes, pero cada uno está configurado para enviar sus resultados a un bucket S3 compartido, y solo puede administrar cada uno en su cuenta y región de origen.
• Sin embargo, los eventos de CloudWatch para llamadas de API solo se crean en la región de la llamada de API.
• Así que, si crea un trail multirregión, los datos se recopilan de forma centralizada, pero los eventos solo aparecen localmente. Una CloudWatch Rule en la región del trail de origen solo se activará por llamadas de API realizadas en esa región (la de origen). Por lo tanto, si crea una alarma para cambios en grupos de seguridad, solo funcionará en la región de origen, no en las demás regiones, aunque CloudTrail esté activado.
• El Log Group/Stream de CloudWatch aparecerá en la región principal, no en las otras regiones, pero cada Event se crea en la región que desencadenó el evento.
• Si quiere recopilar todos los eventos de llamadas de API, necesita usar una definición de evento no documentada (que he pegado abajo).
• Si lee la documentación de Amazon… nunca explica nada de esto con claridad. Al menos no he podido encontrarlo. De hecho, una vez estuve en una llamada de soporte donde lo descubrí, y el representante de AWS seguía murmurando: “No creo que funcione así”, mientras mis eventos empezaban a llegar. Tuvo una noche difícil.

Por alguna razón, esto me resultó muy poco intuitivo. Yo había supuesto que, si centralizaba el trail, podría centralizar la CloudWatch Rule para activarse con los eventos de llamadas de API. Lamentablemente eso era totalmente incorrecto y, incluso cuando centraliza el trail, aún debe crear la Rule en cada región que le interese. Incluso si usa Event Bus para recopilar eventos de varias cuentas, igual necesita crear una CloudWatch Rule en cada región de cada cuenta para enviar el evento al Bus, y luego debe crear Rules en cada región del Event Bus para activar la notificación o acción que desee.

Así es como recomiendo abordar esto si quiere las capacidades de alertas casi en tiempo real o la corrección y acciones automáticas que admiten las CloudWatch Rules:

• Active un trail multirregión. Solo necesita hacerlo una vez, y un trail de Organization es suficiente.
• Esto crea todos los trails regionales que necesita. Parece un único trail central, pero en realidad es un conjunto de trails regionales que envían sus datos a un receptor central.
• Opción 1: cree una CloudWatch Rule en cada región para la que quiera alertas casi en tiempo real. CloudFormation y Terraform son sus aliados aquí.
• Opción 2: centralice todos sus eventos. Dentro de cada región, cree una Rule para enviar todos los eventos de CloudTrail a una función Lambda o a un tema de SNS, que luego los reenvíe a su destino. Nosotros mismos usamos esta técnica; enviamos mediante un endpoint de API personalizado, pero usted puede transmitir a Kinesis o a casi cualquier cosa.

Para empezar, aquí hay dos ejemplos de código.

El patrón de filtro secreto para que su CloudWatch Rule recopile todos los eventos de CloudTrail:

{

"detail-type": [

"AWS API Call via CloudTrail"

] }

Y aquí hay un ejemplo de código Lambda para reenviar eventos, en este caso, a Kinesis:

import json

import boto3

def lambda_handler(event, context):

kinesis = boto3.client('kinesis', region_name='us-west-2')

data = json.dumps(event)

print(data)

response = kinesis.put_record(

StreamName='cloudsec_prod_stream_alert_kinesis',

Data=data,

PartitionKey='test-client-id'

)

print(response)

return {

'statusCode': 200,

'body': json.dumps('Record added')

}