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.
Security OU — Compte Log Archive
| Influencez le futur de l'architecture de référence de AWS sécurité (AWSSRA) en répondant à une courte enquête |
Le schéma suivant illustre les services de sécurité AWS configurés dans le compte Log Archive.
Le compte Log Archive est dédié à l'ingestion et à l'archivage de tous les journaux et sauvegardes liés à la sécurité. Avec les journaux centralisés en place, vous pouvez surveiller, auditer et émettre des alertes en cas d'accès aux objets Amazon S3, d'activité non autorisée par identité, de modification de la politique IAM et d'autres activités critiques effectuées sur des ressources sensibles. Les objectifs de sécurité sont simples : il doit s'agir d'un stockage immuable, accessible uniquement par des mécanismes contrôlés, automatisés et surveillés, et conçu dans un souci de durabilité (par exemple, en utilisant les processus de réplication et d'archivage appropriés). Des contrôles peuvent être mis en œuvre en profondeur pour protéger l'intégrité et la disponibilité des journaux et du processus de gestion des journaux. Outre les contrôles préventifs, tels que l'attribution de rôles de moindre privilège à utiliser pour l'accès et le chiffrement des journaux à l'aide d'une clé AWS KMS contrôlée, utilisez des contrôles de détection tels qu'AWS Config pour surveiller (et alerter et corriger) cet ensemble d'autorisations en cas de modifications inattendues.
Considération de conception
-
Les données du journal opérationnel utilisées par vos équipes chargées de l'infrastructure, des opérations et de la charge de travail recoupent souvent les données du journal utilisées par les équipes chargées de la sécurité, de l'audit et de la conformité. Nous vous recommandons de consolider les données de vos journaux opérationnels dans le compte Log Archive. En fonction de vos exigences spécifiques en matière de sécurité et de gouvernance, vous devrez peut-être filtrer les données du journal opérationnel enregistrées sur ce compte. Vous devrez peut-être également spécifier qui a accès aux données du journal opérationnel dans le compte Log Archive.
Types de journaux
Les principaux journaux affichés dans l'AWS SRA incluent CloudTrail (suivi de l'organisation), les journaux de flux Amazon VPC, les journaux d'accès d' CloudFront Amazon et d'AWS WAF, et les journaux DNS d'Amazon Route 53. Ces journaux fournissent un audit des actions entreprises (ou tentées) par un utilisateur, un rôle, un service AWS ou une entité réseau (identifié, par exemple, par une adresse IP). D'autres types de journaux (par exemple, les journaux d'applications ou les journaux de base de données) peuvent également être capturés et archivés. Pour plus d'informations sur les sources de journalisation et les meilleures pratiques de journalisation, consultez la documentation de sécurité de chaque service.
Amazon S3 en tant que magasin de journaux central
De nombreux services AWS enregistrent des informations dans Amazon S3, par défaut ou exclusivement. AWS CloudTrail, Amazon VPC Flow Logs, AWS Config et Elastic Load Balancing sont quelques exemples de services qui enregistrent des informations dans Amazon S3. Cela signifie que l'intégrité des journaux est assurée par l'intégrité des objets S3 ; la confidentialité des journaux est assurée par les contrôles d'accès aux objets S3 ; et la disponibilité des journaux est assurée par le biais du verrouillage des objets S3, des versions des objets S3 et des règles de cycle de vie S3. En enregistrant les informations dans un compartiment S3 dédié et centralisé qui réside dans un compte dédié, vous pouvez gérer ces journaux dans quelques compartiments et appliquer des contrôles de sécurité stricts, un accès et une séparation des tâches.
Dans l'AWS SRA, les principaux journaux stockés dans Amazon S3 proviennent CloudTrail. Cette section décrit donc comment protéger ces objets. Ce guide s'applique également à tout autre objet S3 créé par vos propres applications ou par d'autres services AWS. Appliquez ces modèles chaque fois que vous avez des données dans Amazon S3 qui nécessitent une intégrité élevée, un contrôle d'accès renforcé et une conservation ou une destruction automatisées.
Tous les nouveaux objets (y compris les CloudTrail journaux) chargés dans des compartiments S3 sont chiffrés par défaut à l'aide du chiffrement côté serveur Amazon avec des clés de chiffrement gérées par Amazon S3 (SSE-S3). Cela permet de protéger les données au repos, mais le contrôle d'accès est contrôlé exclusivement par les politiques IAM. Pour fournir une couche de sécurité gérée supplémentaire, vous pouvez utiliser le chiffrement côté serveur avec les clés AWS KMS que vous gérez (SSE-KMS) sur tous les compartiments de sécurité S3. Cela ajoute un deuxième niveau de contrôle d'accès. Pour lire les fichiers journaux, un utilisateur doit disposer à la fois des autorisations de lecture Amazon S3 pour l'objet S3 et d'une stratégie ou d'un rôle IAM lui permettant de déchiffrer selon la politique de clé associée.
Deux options vous permettent de protéger ou de vérifier l'intégrité des objets de CloudTrail journal stockés dans Amazon S3. CloudTrail fournit une validation de l'intégrité du fichier journal afin de déterminer si un fichier journal a été modifié ou supprimé après CloudTrail sa livraison. L'autre option est S3 Object Lock.
Outre la protection du compartiment S3 lui-même, vous pouvez respecter le principe du moindre privilège pour les services de journalisation (par exemple CloudTrail) et le compte Log Archive. Par exemple, les utilisateurs disposant d'autorisations accordées par la politique IAM gérée par AWS AWSCloudTrail_FullAccess peuvent désactiver ou reconfigurer les fonctions d'audit les plus sensibles et les plus importantes de leurs comptes AWS. Limitez l'application de cette politique IAM au moins de personnes possible.
Utilisez des contrôles de détection, tels que ceux fournis par AWS Config et AWS IAM Access Analyzer, pour surveiller (et alerter et corriger) cet ensemble plus large de contrôles préventifs en cas de changements inattendus.
Pour en savoir plus sur les meilleures pratiques de sécurité pour les compartiments S3, consultez la documentation Amazon S3, les conférences techniques en ligne
Exemple de mise en œuvre
La bibliothèque de code AWS SRA
Amazon Security Lake
AWS SRA vous recommande d'utiliser le compte Log Archive comme compte d'administrateur délégué pour Amazon Security Lake. Dans ce cas, Security Lake collecte les journaux pris en charge dans des compartiments S3 dédiés sur le même compte que les autres journaux de sécurité recommandés par la SRA.
Pour protéger la disponibilité des journaux et le processus de gestion des journaux, les compartiments S3 pour Security Lake ne doivent être accessibles que par le service Security Lake ou par les rôles IAM gérés par Security Lake pour les sources ou les abonnés. Outre l'utilisation de contrôles préventifs, tels que l'attribution de rôles dotés de privilèges d'accès minimaux et le chiffrement des journaux à l'aide d'une clé contrôlée AWS Key Management Services (AWS KMS), utilisez des contrôles de détection tels qu'AWS Config pour surveiller (et alerter et corriger) cet ensemble d'autorisations en cas de modifications inattendues.
L'administrateur de Security Lake peut activer la collecte de journaux au sein de votre organisation AWS. Ces journaux sont stockés dans des compartiments S3 régionaux du compte Log Archive. En outre, pour centraliser les journaux et faciliter le stockage et l'analyse, l'administrateur de Security Lake peut choisir une ou plusieurs régions cumulatives dans lesquelles les journaux de tous les compartiments S3 régionaux sont consolidés et stockés. Les journaux des services AWS pris en charge sont automatiquement convertis en un schéma open source standardisé appelé Open Cybersecurity Schema Framework (OCSF) et enregistrés au format Apache Parquet dans des compartiments Security Lake S3. Grâce au support OCSF, Security Lake normalise et consolide efficacement les données de sécurité provenant d'AWS et d'autres sources de sécurité d'entreprise afin de créer un référentiel unifié et fiable d'informations relatives à la sécurité.
Security Lake peut collecter des journaux associés aux événements de CloudTrail gestion AWS et aux événements de CloudTrail données pour Amazon S3 et AWS Lambda. Pour collecter les événements CloudTrail de gestion dans Security Lake, vous devez disposer d'au moins un journal d'organisation CloudTrail multirégional qui collecte les événements de CloudTrail gestion en lecture et en écriture. La journalisation doit être activée pour le parcours. Un suivi multirégional fournit des fichiers journaux provenant de plusieurs régions vers un seul compartiment S3 pour un seul compte AWS. Si les régions se trouvent dans des pays différents, tenez compte des exigences en matière d'exportation de données pour déterminer si les sentiers multirégionaux peuvent être activés.
AWS Security Hub est une source de données native prise en charge dans Security Lake, et vous devez ajouter les résultats de Security Hub à Security Lake. Security Hub génère des résultats à partir de nombreux services AWS et d'intégrations tierces. Ces résultats vous permettent d'avoir une vue d'ensemble de votre niveau de conformité et de savoir si vous suivez les recommandations de sécurité pour AWS et les solutions de ses partenaires.
Pour obtenir de la visibilité et des informations exploitables à partir des journaux et des événements, vous pouvez interroger les données à l'aide d'outils tels qu'Amazon Athena, OpenSearch Amazon Service, Amazon Quicksight et de solutions tierces. Les utilisateurs qui ont besoin d'accéder aux données du journal Security Lake ne doivent pas accéder directement au compte Log Archive. Ils ne doivent accéder aux données qu'à partir du compte Security Tooling. Ils peuvent également utiliser d'autres comptes AWS ou des sites sur site qui fournissent des outils d'analyse tels que OpenSearch Service QuickSight, ou des outils tiers tels que des outils de gestion des informations et des événements de sécurité (SIEM). Pour donner accès aux données, l'administrateur doit configurer les abonnés Security Lake dans le compte Log Archive et configurer le compte qui a besoin d'accéder aux données en tant qu'abonné à accès aux requêtes. Pour plus d'informations, consultez Amazon Security Lake dans la section Security OU — Security Tooling account de ce guide.
Security Lake fournit une politique gérée par AWS pour vous aider à gérer l'accès des administrateurs au service. Pour plus d'informations, consultez le guide de l'utilisateur de Security Lake. Comme bonne pratique, nous vous recommandons de restreindre la configuration de Security Lake par le biais de pipelines de développement et d'empêcher les modifications de configuration via les consoles AWS ou l'interface de ligne de commande (AWS CLI) AWS. En outre, vous devez définir des politiques IAM et des politiques de contrôle des services (SCP) strictes afin de fournir uniquement les autorisations nécessaires à la gestion de Security Lake. Vous pouvez configurer les notifications pour détecter tout accès direct à ces compartiments S3.
