Configurez une journalisation centralisée à l'échelle de l'entreprise à l'aide de Terraform - Recommandations AWS
RécapitulatifConditions préalables et limitationsArchitectureOutilsBonnes pratiquesÉpopéesRésolution des problèmesRessources connexes

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Configurez une journalisation centralisée à l'échelle de l'entreprise à l'aide de Terraform

Créée par Aarti Rajput (AWS), Yashwant Patel (AWS) et Nishtha Yadav (AWS)

Récapitulatif

La journalisation centralisée est vitale pour l'infrastructure cloud d'une entreprise, car elle fournit une visibilité sur ses opérations, sa sécurité et sa conformité. Au fur et à mesure que votre entreprise adapte son AWS environnement à plusieurs comptes, une stratégie structurée de gestion des journaux devient fondamentale pour exécuter les opérations de sécurité, répondre aux exigences d'audit et atteindre l'excellence opérationnelle.

Ce modèle fournit un cadre évolutif et sécurisé pour centraliser les journaux provenant de multiples services, afin de permettre la gestion Comptes AWS des journaux à l'échelle de l'entreprise dans le cadre de déploiements complexes. AWS La solution est automatisée à l'aide de Terraform, un outil d'infrastructure en tant que code (IaC) HashiCorp qui garantit des déploiements cohérents et répétables et minimise la configuration manuelle. En combinant Amazon CloudWatch Logs, Amazon Data Firehose et Amazon Simple Storage Service (Amazon S3), vous pouvez mettre en œuvre un pipeline robuste d'agrégation et d'analyse des journaux qui fournit :

  • Gestion centralisée des journaux au sein de votre organisation dans AWS Organizations

  • Collecte de journaux automatisée avec contrôles de sécurité intégrés

  • Traitement évolutif des journaux et stockage durable

  • Rapports de conformité et pistes d'audit simplifiés

  • Informations opérationnelles et surveillance en temps réel

La solution collecte les journaux à partir des AWS Lambda conteneurs, des fonctions et des instances de base de données Amazon Elastic Kubernetes Service (Amazon EKS) via Logs. CloudWatch Il transmet automatiquement ces journaux vers un compte de journalisation dédié à l'aide de filtres CloudWatch d'abonnement. Firehose gère le pipeline de streaming de journaux à haut débit vers Amazon S3 pour un stockage à long terme. Amazon Simple Queue Service (Amazon SQS) est configuré pour recevoir des notifications d'événements Amazon S3 lors de la création d'un objet. Cela permet l'intégration avec les services d'analyse, notamment :

  • Amazon OpenSearch Service pour la recherche dans les journaux, la visualisation et les analyses en temps réel

  • Amazon Athena pour les requêtes basées sur SQL

  • Amazon EMR pour le traitement à grande échelle

  • Lambda pour une transformation personnalisée

  • Amazon QuickSight pour les tableaux de bord

Toutes les données sont cryptées à l'aide de AWS Key Management Service (AWS KMS), et l'ensemble de l'infrastructure est déployée à l'aide de Terraform pour une configuration cohérente dans tous les environnements.

Cette approche de journalisation centralisée permet aux entreprises d'améliorer leur niveau de sécurité, de respecter les exigences de conformité et d'optimiser l'efficacité opérationnelle de leur AWS infrastructure.

Conditions préalables et limitations

Prérequis

Pour obtenir des instructions sur la configuration AWS Control Tower des comptes AFT et Application, consultez la section Epics.

Comptes obligatoires

Votre organisation AWS Organizations doit inclure les comptes suivants :

  • Compte d'application : un ou plusieurs comptes sources sur lesquels Services AWS (Amazon EKS, Lambda et Amazon RDS) s'exécutent et génèrent des journaux

  • Compte Log Archive : un compte dédié pour le stockage et la gestion centralisés des journaux

Versions du produit

Architecture

Le schéma suivant illustre une architecture de journalisation AWS centralisée qui fournit une solution évolutive pour collecter, traiter et stocker les journaux de plusieurs comptes d'applications dans un compte Log Archive dédié. Cette architecture gère efficacement les journaux provenant Services AWS notamment d'Amazon RDS, Amazon EKS et Lambda, et les achemine via un processus rationalisé vers les compartiments S3 régionaux du compte Log Archive.

Architecture de journalisation centralisée AWS pour collecter des journaux à partir de plusieurs comptes d'applications.

Le flux de travail comprend cinq processus :

  1. Processus de journalisation

    • Le processus de flux de journaux commence dans les comptes de l'application, où sont Services AWS générés différents types de journaux, tels que les journaux généraux, les journaux d'erreurs, les journaux d'audit, les journaux de requêtes lentes d'Amazon RDS, les journaux du plan de contrôle d'Amazon EKS et les journaux d'exécution et d'erreur de Lambda.

    • CloudWatch sert de point de collecte initial. Il rassemble ces journaux au niveau du groupe de journaux au sein de chaque compte d'application.

    • Dans CloudWatch, les filtres d'abonnement déterminent quels journaux doivent être transférés au compte central. Ces filtres vous permettent de contrôler de manière précise le transfert des journaux, afin que vous puissiez spécifier des modèles de journal exacts ou des flux de journaux complets à des fins de centralisation.

  2. Transfert de journaux entre comptes

    • Les journaux sont transférés vers le compte Log Archive. CloudWatch les filtres d'abonnement facilitent le transfert entre comptes et préservent le contexte régional.

    • L'architecture établit plusieurs flux parallèles pour gérer efficacement différentes sources de journaux, afin de garantir des performances et une évolutivité optimales.

  3. Traitement des journaux dans le compte Log Archive

    • Dans le compte Log Archive, Firehose traite les flux de journaux entrants.

    • Chaque région gère des flux de diffusion Firehose dédiés qui peuvent transformer, convertir ou enrichir les logs selon les besoins.

    • Ces flux Firehose fournissent les journaux traités aux compartiments S3 du compte Log Archive, qui se trouve dans la même région que les comptes de l'application source (région A dans le schéma) afin de respecter les exigences de souveraineté des données.

  4. Notifications et flux de travail supplémentaires

    • Lorsque les logs atteignent leurs compartiments S3 de destination, l'architecture implémente un système de notification à l'aide d'Amazon SQS.

    • Les files d'attente SQS régionales permettent un traitement asynchrone et peuvent déclencher des flux de travail, des analyses ou des systèmes d'alerte supplémentaires en fonction des journaux stockés.

  5. AWS KMS pour la sécurité

    L'architecture intègre des éléments AWS KMS de sécurité. AWS KMS fournit des clés de chiffrement pour les compartiments S3. Cela garantit que tous les journaux stockés maintiennent le chiffrement au repos tout en conservant le chiffrement régional pour répondre aux exigences de résidence des données.

Outils

Services AWS

  • Amazon CloudWatch est un service de surveillance et d'observabilité qui collecte des données opérationnelles et de surveillance sous forme de journaux, de mesures et d'événements. Il fournit une vue unifiée des AWS ressources, des applications et des services qui s'exécutent sur AWS et sur des serveurs sur site.

  • CloudWatch Les filtres d'abonnement aux journaux sont des expressions qui correspondent à un modèle des événements de journal entrants et fournissent les événements de journal correspondants à la AWS ressource spécifiée pour un traitement ou une analyse ultérieurs.

  • AWS Control Tower Account Factory For Terraform (AFT) met en place un pipeline Terraform pour vous aider à approvisionner et à personnaliser des comptes dans. AWS Control Tower AFT fournit un provisionnement de comptes basé sur Terraform tout en vous permettant de gérer vos comptes avec. AWS Control Tower

  • Amazon Data Firehose fournit des données de streaming en temps réel vers des destinations telles qu'Amazon S3, Amazon Redshift et Amazon Service. OpenSearch Il s'adapte automatiquement au débit de vos données et ne nécessite aucune administration continue.

  • Amazon Elastic Kubernetes Service (Amazon EKS) est un service d'orchestration de conteneurs géré qui facilite le déploiement, la gestion et le dimensionnement d'applications conteneurisées à l'aide de Kubernetes. Il gère automatiquement la disponibilité et l'évolutivité des nœuds du plan de contrôle Kubernetes.

  • AWS Key Management Service (AWS KMS) crée et contrôle les clés de chiffrement pour chiffrer vos données. AWS KMS s'intègre Services AWS à d'autres services pour vous aider à protéger les données que vous stockez avec ces services.

  • AWS Lambdaest un service de calcul sans serveur qui vous permet d'exécuter du code sans provisionner ni gérer de serveurs. Il adapte automatiquement vos applications en exécutant du code en réponse à chaque déclencheur, et ne facture que le temps de calcul que vous utilisez.

  • Amazon Relational Database Service (Amazon RDS) est un service de base de données relationnelle géré qui facilite la configuration, l'exploitation et le dimensionnement d'une base de données relationnelle dans le cloud. Il fournit une capacité rentable et redimensionnable tout en automatisant les tâches d'administration fastidieuses.

  • Amazon Simple Queue Service (Amazon SQS) est un service de mise en file d'attente de messages qui vous permet de découpler et de dimensionner les microservices, les systèmes distribués et les applications sans serveur. Il élimine la complexité de la gestion et de l'exploitation d'un intergiciel orienté message.

  • Amazon Simple Storage Service (Amazon S3) est un service de stockage d'objets basé sur le cloud qui offre évolutivité, disponibilité des données, sécurité et performances. Il peut stocker et récupérer n'importe quelle quantité de données n'importe où sur le Web.

Autres outils

  • Terraform est un outil d'infrastructure en tant que code (IaC) HashiCorp qui vous aide à créer et à gérer des ressources cloud et sur site.

Code

Le code de ce modèle est disponible dans le référentiel de journalisation GitHub centralisé.

Bonnes pratiques

Épopées

TâcheDescriptionCompétences requises

Configurez un AWS Control Tower environnement avec AFT.

  1. Déployez AWS Control Tower en suivant les instructions de la AWS Control Tower documentation.

  2. Déployez AFT en suivant les instructions de la AWS Control Tower documentation.

Administrateur AWS

Activez le partage des ressources pour l'organisation.

  1. Configurez AWS Command Line Interface (AWS CLI) avec les informations d'identification du compte de gestion, qui fournissent les autorisations administratives nécessaires à la gestion AWS Control Tower.

  2. Exécutez la AWS CLI commande suivante dans n'importe laquelle Région AWS :

    aws ram enable-sharing-with-aws-organization

    Cela permet le partage des ressources au sein de votre organisation dans toutes les AWS Organizations régions qui prennent en charge AWS Resource Access Manager (AWS RAM).

Administrateur AWS

Vérifiez ou approvisionnez les comptes de l'application.

Pour configurer de nouveaux comptes d'application pour votre cas d'utilisation, créez-les via AFT. Pour plus d'informations, voir Provisionner un nouveau compte avec AFT dans la AWS Control Tower documentation.

Administrateur AWS
TâcheDescriptionCompétences requises

Copiez Application_account le contenu du dossier dans le aft-account-customizations référentiel.

  1. Créez un dossier nommé Application_account dans le chemin racine du aft-account-customizations référentiel. Ce dépôt est créé automatiquement lorsque vous configurez AFT (voir l'épopée précédente).

  2. Accédez au répertoire racine du scale-using-terraform référentiel centralised-logging-at-enterprise-, copiez le contenu du aft/account répertoire, puis collez-le dans le Application_account répertoire que vous avez créé à l'étape 1 du aft-account-customizations référentiel.

  3. À partir du répertoire racine du centralised-logging-at-enterprise-scale-using-terraform référentiel, copiez le contenu du Application_account répertoire dans le Application_account/terraform répertoire du aft-account-customizations référentiel.

  4. Dans le aft-account-customizations/Application_account/terraform.tfvars fichier, vérifiez que tous les paramètres sont transmis en tant qu'arguments dans les fichiers de configuration Terraform correspondants.

DevOps ingénieur

Vérifiez et modifiez les paramètres d'entrée pour configurer le compte de l'application.

Au cours de cette étape, vous configurez le fichier de configuration pour créer des ressources dans les comptes d'applications, notamment les groupes de CloudWatch journaux, les filtres CloudWatch d'abonnement, les rôles et politiques IAM, ainsi que les détails de configuration pour les fonctions Amazon RDS, Amazon EKS et Lambda.

Dans votre aft-account-customizations référentiel, dans le Application_account dossier, configurez les paramètres d'entrée du terraform.tfvars fichier en fonction des exigences de votre organisation :

  • environment: nom de l'environnement (par exemple,, proddev,staging) dans lequel les ressources seront déployées.

  • account_name: nom de l' Compte AWS endroit où les ressources seront créées.

  • log_archive_account_id: Compte AWS ID dans lequel les journaux seront archivés.

  • admin_role_name: nom du rôle administratif qui sera utilisé pour gérer les ressources.

  • tags: carte de paires clé-valeur représentant des balises communes à appliquer à toutes les ressources.

  • rds_config: objet contenant les détails de configuration des instances Amazon RDS.

  • allowed_cidr_blocks: liste des blocs CIDR autorisés à accéder aux ressources.

  • destination_name:Variable utilisée pour créer le nom de ressource Amazon (ARN) de la CloudWatch destination où les journaux seront diffusés.

  • rds_parameters:Objet contenant les paramètres du groupe de paramètres Amazon RDS.

  • vpc_config: objet contenant les détails de configuration du VPC.

  • eks_config: objet contenant les détails de configuration des clusters Amazon EKS.

  • lambda_config: objet contenant les détails de configuration des fonctions Lambda.

  • restrictive_cidr_range: liste de plages CIDR restrictives pour les règles des groupes de sécurité.

  • target_account_id: Compte AWS ID du compte Log Archive cible sur lequel les ressources seront déployées.

DevOps ingénieur
TâcheDescriptionCompétences requises

Copiez Log_archive_account le contenu du dossier dans le aft-account-customizations référentiel.

  1. Créez un dossier nommé Log_archive_account dans le chemin racine du aft-account-customizations dépôt. Ce dépôt est créé automatiquement lorsque vous configurez AFT.

  2. Accédez au répertoire racine du centralised-logging-at-enterprise-scale-using-terraform référentiel, copiez le contenu du aft/account répertoire, puis collez-le dans le Log_archive_account répertoire que vous avez créé à l'étape précédente dans le aft-account-customizations référentiel.

  3. À partir du répertoire racine du centralised-logging-at-enterprise-scale-using-terraform référentiel, copiez le contenu du Log_archive_account répertoire dans le Log_archive_account/terraform répertoire du aft-account-customizations référentiel.

  4. Dans le aft-account-customizations/Log_archive_account/terraform.tfvars fichier, vérifiez que tous les paramètres sont transmis en tant qu'arguments dans les fichiers de configuration Terraform correspondants.

DevOps ingénieur

Vérifiez et modifiez les paramètres d'entrée pour configurer le compte Log Archive.

Au cours de cette étape, vous configurez le fichier de configuration pour créer des ressources dans le compte Log Archive, notamment les flux de diffusion Firehose, les compartiments S3, les files d'attente SQS, ainsi que les rôles et politiques IAM.

Dans le Log_archive_account dossier de votre aft-account-customizations référentiel, configurez les paramètres d'entrée dans le terraform.tfvars fichier en fonction des exigences de votre organisation :

  • environment: nom de l'environnement (par exemple,, proddev,staging) dans lequel les ressources seront déployées.

  • destination_name: variable utilisée pour créer l'ARN de la CloudWatch destination où les journaux seront diffusés.

  • source_account_ids: une liste de ceux Compte AWS IDs qui sont autorisés à placer des filtres d'abonnement sur la destination du journal. Vous pouvez saisir autant de comptes IDs que vous souhaitez activer pour une journalisation centralisée.

DevOps ingénieur
TâcheDescriptionCompétences requises

Option 1 - Déployez les fichiers de configuration Terraform depuis AFT.

Dans AFT, le pipeline AFT est déclenché une fois que vous avez envoyé le code contenant les modifications de configuration dans le GitHub aft-account-customizations référentiel. AFT détecte automatiquement les modifications et lance le processus de personnalisation du compte.

Après avoir apporté des modifications à vos fichiers Terraform (terraform.tfvars), validez et transférez vos modifications dans votre référentiel : aft-account-customizations

$ git add *
$ git commit -m "update message"
$ git push origin main
Note

Si vous utilisez une autre branche (par exempledev), remplacez-la main par le nom de votre succursale.

DevOps ingénieur

Option 2 - Déployez le fichier de configuration Terraform manuellement.

Si vous n'utilisez pas AFT ou si vous souhaitez déployer la solution manuellement, vous pouvez utiliser les commandes Terraform suivantes à partir des dossiers Application_account et Log_archive_account :

  1. Clonez le GitHub référentiel et configurez les paramètres d'entrée dans le terraform.tfvars fichier.

  2. Exécutez la commande suivante :

    $ terraform init

  3. Aperçu des modifications :

    $ terraform plan

    Cette commande évalue la configuration Terraform pour déterminer l'état souhaité des ressources et le compare à l'état actuel de votre infrastructure.

  4. Appliquer les modifications :

    $ terraform apply

  5. Passez en revue les modifications prévues et tapez « oui » à l'invite pour poursuivre le traitement de la demande.

DevOps ingénieur
TâcheDescriptionCompétences requises

Vérifiez les filtres d'abonnement.

Pour vérifier que les filtres d'abonnement transfèrent correctement les journaux des groupes de journaux du compte de l'application vers le compte Log Archive :

  1. Dans le compte de l'application, ouvrez la CloudWatch console.

  2. Dans le volet de navigation de gauche, choisissez Groupes de journaux.

  3. Sélectionnez chaque groupe de journaux (/aws/rds,/aws/eks,/aws/lambda) et choisissez l'onglet Filtres d'abonnement.

    Vous devriez voir des filtres d'abonnement actifs pointant vers l'ARN de destination, en fonction du nom que vous avez spécifié dans le fichier de configuration Terraform.

  4. Choisissez n'importe quel filtre d'abonnement pour vérifier sa configuration et son statut.

DevOps ingénieur

Vérifiez les streams Firehose.

Pour vérifier que les streams Firehose contenus dans le compte Log Archive traitent correctement les journaux de l'application :

  1. Dans le compte Log Archive, ouvrez la console Firehose.

  2. Dans le volet de navigation de gauche, choisissez Firehose streams.

  3. Choisissez n'importe quel stream Firehose et vérifiez les points suivants :

    • La destination indique le compartiment S3 approprié.

    • L'onglet Surveillance affiche les indicateurs de livraison réussis.

    • L'horodatage de livraison récent est à jour.

DevOps ingénieur

Validez les compartiments S3 centralisés.

Pour vérifier que les compartiments S3 centralisés reçoivent et organisent correctement les journaux :

  1. Dans le compte Log Archive, ouvrez la console Amazon S3.

  2. Sélectionnez chaque compartiment de journalisation central.

  3. Naviguez dans la structure des dossiers : AWSLogs/AccountID/Region/Service.

    Vous devriez voir les fichiers journaux organisés par timestamp () YYYY/MM/DD/HH.

  4. Choisissez n'importe quel fichier journal récent et vérifiez son format et l'intégrité des données.

DevOps ingénieur

Validez les files d'attente SQS.

Pour vérifier que les files d'attente SQS reçoivent des notifications pour les nouveaux fichiers journaux :

  1. Dans le compte Log Archive, ouvrez la console Amazon SQS.

  2. Dans le volet de navigation de gauche, choisissez Files d'attente.

  3. Sélectionnez chaque file d'attente configurée et choisissez Envoyer et recevoir des messages.

    Vous devriez voir des messages contenant des notifications d'événements S3 pour les nouveaux fichiers journaux.

  4. Choisissez un message pour vérifier qu'il contient les informations correctes sur l'objet S3.

DevOps ingénieur
TâcheDescriptionCompétences requises

Option 1 - Désaffecter le fichier de configuration Terraform d'AFT.

Lorsque vous supprimez les fichiers de configuration Terraform et que vous appliquez les modifications, AFT lance automatiquement le processus de suppression des ressources.

  1. Accédez au aft-account-customizations référentiel.

  2. Accédez au répertoire terraform.

  3. Supprimez les fichiers suivants :

    • modulesannuaire

    • iam.tf

    • versions.tf

    • variables.tf

    • outputs.tf

    • terraform.tfvars

  4. Effacez le contenu du main.tf fichier.

  5. Transférez vos modifications au dépôt :

    # Stage all changes
$ git add *

# Commit cleanup changes
$ git commit -m "Remove AFT customizations"

# Push to repository
$ git push origin main
    Note

    Si vous utilisez une autre branche (par exempledev), remplacez-la main par le nom de votre succursale.

DevOps ingénieur

Option 2 — Nettoyez les ressources Terraform manuellement.

Si vous n'utilisez pas AFT ou si vous souhaitez nettoyer les ressources manuellement, utilisez les commandes Terraform suivantes à partir des dossiers Application_account et Log_archive_account :

  1. Initialisez la configuration Terraform :

    $ terraform init

    Cette commande initialise Terraform et garantit l'accès à l'état actuel.

  2. Prévisualisez les modifications apportées lors du nettoyage :

    $ terraform destroy

    Cette commande évalue les ressources qui seront détruites et compare l'état souhaité avec l'état actuel de votre infrastructure.

  3. Exécutez le nettoyage. Lorsque vous y êtes invité, tapez oui pour confirmer et exécuter le plan de destruction.

DevOps ingénieur

Résolution des problèmes

ProblèmeSolution

La destination CloudWatch Logs n'a pas été créée ou est inactive.

Validez les éléments suivants :

  1. Dans le compte Log Archive, vérifiez que la politique de destination inclut :

    • Le principal du compte source correct.

    • L'action correcte (logs:PutSubscriptionFilter).

    • Un ARN de destination valide.

  2. Vérifiez que le stream Firehose existe et qu'il est actif.

  3. Vérifiez que le rôle IAM associé à la destination dispose d'autorisations pour Firehose.

Le filtre d'abonnement a échoué ou est bloqué en attente.

Vérifiez les éléments suivants :

  1. Dans le compte d'application, vérifiez que le rôle IAM possède :

    • Autorisations d'appelPutSubscriptionFilter.

    • Une relation de confiance avec CloudWatch Logs.

  2. Vérifiez que l'ARN de destination est correct.

  3. Consultez les CloudWatch journaux pour voir s'il existe des messages d'erreur spécifiques.

Le flux de livraison Firehose n'affiche aucun enregistrement entrant.

Vérifiez les paramètres suivants :

  1. Vérifiez que le rôle Firehose IAM possède les caractéristiques suivantes :

    • Autorisations pour écrire sur Amazon S3.

    • Accès à la AWS KMS clé si le chiffrement est activé.

  2. Passez en revue CloudWatch les métriques pour :

    • IncomingRecords

    • DeliveryToS3.Records

  3. Vérifiez les paramètres de la mémoire tampon et les configurations de livraison.

Ressources connexes