Le fonctionnement excessivement complexe de CloudTrail et CloudWatch Events ensemble

L'un des problèmes les plus déroutants de mon parcours dans le cloud a été de comprendre comment CloudTrail et CloudWatch Events fonctionnent ensemble. Pour une raison ou une autre, il m'a fallu des années (et beaucoup de tests) pour bien saisir le fonctionnement réel de cette connexion, et en particulier son fonctionnement avec la notion de trails multirégions et de trails AWS Organization. Puis, une fois que j'ai tout compris, j'ai supposé que tout le monde le savait déjà, mais des échanges récents ont montré que cette confusion est assez répandue. Voici donc ma meilleure tentative pour simplifier les choses.

D'abord, le problème que nous cherchons à résoudre : créer des règles CloudWatch à partir des événements CloudTrail et les utiliser pour envoyer des notifications ou déclencher des fonctions Lambda.

C'est tout : je veux envoyer une notification pour quelque chose d'aussi simple que l'appel d'API qui ouvre une nouvelle règle de groupe de sécurité (AuthorizeSecurityGroupIngress, au cas où vous vous poseriez la question).

Pour que cela fonctionne, les éléments suivants doivent être en place :

• CloudTrail activé dans la région où l'appel d'API est effectué.
• CloudTrail diffusant vers CloudWatch.
• Une règle CloudWatch dans la région de l'appel d'API qui recherche cet appel d'API précis, ou tous les appels d'API CloudTrail.

Vient maintenant la confusion :

• Lorsque vous créez un trail CloudTrail multirégion ou un trail Organization, AWS met en réalité en place, en coulisses, des trails dans chaque région (et dans chaque compte, dans le cas d'un trail Organization). Ce sont tous des trails distincts, mais chacun est configuré pour envoyer ses résultats vers un bucket S3 partagé, et vous ne pouvez gérer chacun d'eux que dans son compte et sa région d'origine.
• Cependant, les événements CloudWatch relatifs aux appels d'API ne sont créés que dans la région de l'appel d'API.
• Ainsi, si vous créez un trail multirégion, les données sont toutes collectées de manière centralisée, mais les événements n'apparaissent que localement. Une règle CloudWatch dans la région du trail principal ne se déclenchera que pour les appels d'API effectués dans cette région (principale). Donc, si vous créez une alarme pour les modifications de groupes de sécurité, elle ne fonctionnera que dans la région principale, pas dans les autres régions, même si CloudTrail est activé.
• Le groupe de logs / flux CloudWatch apparaîtra dans la région principale, pas dans les autres régions, mais chaque événement est créé dans la région qui l'a déclenché.
• Si vous souhaitez collecter tous les événements liés aux appels d'API, vous devez utiliser une définition d'événement non documentée (que j'ai collée ci-dessous).
• Si vous lisez la documentation d'Amazon… rien de tout cela n'est expliqué clairement. Du moins, je n'ai rien trouvé de tel. En fait, j'ai un jour été en communication avec le support au moment où j'ai compris, et le représentant AWS répétait à voix basse « je ne crois pas que ça fonctionne comme ça » pendant que mes événements commençaient à arriver. Il passait une mauvaise nuit.

Pour une raison ou une autre, cela m'a semblé vraiment contre-intuitif. J'avais supposé que si l'on centralisait le trail, on pouvait centraliser la règle CloudWatch pour la déclencher à partir des événements d'appels d'API. Malheureusement, c'était totalement faux : même lorsque vous centralisez le trail, vous devez encore créer la règle dans chaque région qui vous intéresse. Même si vous utilisez Event Bus pour collecter les événements de plusieurs comptes, vous devez quand même créer une règle CloudWatch dans chaque région de chaque compte pour envoyer l'événement vers le bus, puis créer des règles dans chaque région de l'Event Bus pour déclencher la notification ou l'action souhaitée.

Voici l'approche que je recommande si vous souhaitez bénéficier des capacités d'alerte en quasi-temps réel ou des actions/corrections automatiques prises en charge par les règles CloudWatch :

• Activez un trail multirégion. Vous n'avez à le faire qu'une seule fois, et un trail Organization suffit.
• Cela crée tous les trails régionaux dont vous avez besoin. Cela ressemble à un trail central unique, mais il s'agit en réalité d'un ensemble de trails régionaux qui envoient leurs données vers un récepteur central.
• Option 1 : créez une règle CloudWatch dans chaque région pour laquelle vous souhaitez une alerte en quasi-temps réel. CloudFormation et Terraform sont vos alliés ici.
• Option 2 : centralisez tous vos événements. Dans chaque région, créez une règle pour envoyer tous les événements CloudTrail vers une fonction Lambda ou un topic SNS, qui les transmet ensuite à votre destination. Nous utilisons nous-mêmes cette technique ; nous envoyons via un point de terminaison d'API personnalisé, mais vous pouvez diffuser vers Kinesis ou presque n'importe quoi d'autre.

Pour vous lancer, voici deux exemples de code.

Le modèle de filtre secret permettant à votre règle CloudWatch de collecter tous les événements de CloudTrail :

{

"detail-type": [

"AWS API Call via CloudTrail"

] }

Et voici un exemple de code Lambda pour transférer les événements, dans ce cas vers 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')

}