Une entreprise utilise une application collaborative. L'ingénieur de sécurité a besoin que les alertes automatisées d'AWS Security Hub dans la région us-west-2 apparaissent dans un canal chaque fois que Security Hub reçoit une nouvelle découverte. Une fonction Lambda reformate le message et l'envoie à l'API de l'application. Une règle Amazon EventBridge cible la fonction Lambda. Après avoir activé la règle, le canal est inondé d'alertes, dont beaucoup proviennent d'Amazon Inspector et ne nécessitent aucune action. Avec le moins d'effort opérationnel, comment l'ingénieur peut-il arrêter les alertes Amazon Inspector ?

La bonne réponse est de définir l'attribut ProductArn sur anything-but: ["arn:aws:securityhub:us-west-2::product/aws/inspector"] dans le modèle d'événement de la règle EventBridge. Cette approche filtre les événements directement à la source, avant qu'ils n'atteignent la fonction Lambda, ce qui minimise les efforts opérationnels. Mettre à jour le code de la fonction Lambda est une option, mais cela ajoute une logique de filtrage à la fonction, ce qui augmente sa complexité et nécessite des tests supplémentaires. Créer une action personnalisée Security Hub est inutile car EventBridge peut déjà filtrer les événements de Security Hub. Publier des messages sur une rubrique Amazon SNS avec une politique de filtre d'abonnement est une solution viable, mais elle introduit un composant supplémentaire (SNS) dans l'architecture, ce qui est moins direct que le filtrage natif d'EventBridge.