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é (AWS SRA) en répondant à une courte enquête |
Le schéma suivant illustre les services AWS de sécurité 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 modifications de IAM politique 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 des rôles les moins privilégiés à utiliser pour l'accès et le chiffrement des journaux à l'aide d'une AWS KMS clé contrôlée, utilisez des contrôles de détection tels que AWS Config pour surveiller (et alerter et corriger) cet ensemble d'autorisations en cas de modifications inattendues.
Considération relative à la 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 le journal AWS SRA incluent CloudTrail (historique de l'organisation), les journaux de VPC flux Amazon, les journaux d'accès d'Amazon CloudFront et AWS WAF DNS les journaux d'Amazon Route 53. Ces journaux fournissent un audit des actions entreprises (ou tentées) par un utilisateur, un rôle, un AWS service 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 AWS services enregistrent les informations dans Amazon S3, par défaut ou exclusivement. AWS CloudTrail, Amazon VPC Flow Logs, AWS Config et Elastic Load Balancing sont des 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 le AWSSRA, 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 AWS services. 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 (-S3). SSE Cela permet de protéger les données au repos, mais le contrôle d'accès est contrôlé exclusivement par IAM des politiques. Pour fournir une couche de sécurité gérée supplémentaire, vous pouvez utiliser le chiffrement côté serveur avec des AWS KMS clés 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 IAM politique ou d'un rôle lui permettant de déchiffrer selon la politique 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 IAM politique AWS gérée AWSCloudTrail_FullAccess peuvent désactiver ou reconfigurer les fonctions d'audit les plus sensibles et les plus importantes de leurs AWS comptes. Limitez l'application de cette IAM politique 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 AWS SRA code
Amazon Security Lake
AWSSRAvous 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é SRA recommandés.
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 IAM des rôles 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 du moindre privilège d'accès et le chiffrement des journaux à l'aide d'une AWS clé contrôlée des services de gestion des clés (AWSKMS), utilisez des contrôles de détection tels que 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 AWS organisation. 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 AWS services 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 OCSF support, Security Lake normalise et consolide efficacement les données de sécurité provenant AWS d'autres sources de sécurité de l'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 à des événements de AWS CloudTrail gestion et à des é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 les fichiers journaux de plusieurs régions vers un seul compartiment S3 pour un seul AWS compte. Si les régions se trouvent dans des pays différents, tenez compte des exigences en matière d'exportation des données pour déterminer si les sentiers multirégionaux peuvent être activés.
AWSSecurity 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 AWS services et 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é AWS et les solutions proposées par les AWS 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, Amazon Service, OpenSearch 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 AWS comptes ou sites sur site qui fournissent des outils d'analyse tels que le OpenSearch service QuickSight, ou des outils tiers tels que les informations de sécurité et les outils de gestion des événements (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 AWS gérée 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. Il est recommandé de limiter la configuration de Security Lake via les pipelines de développement et d'empêcher les modifications de configuration via les AWS consoles ou l'interface de ligne de AWS commande (AWSCLI). En outre, vous devez définir des IAM politiques strictes et des politiques de contrôle des services (SCPs) afin de ne fournir que les autorisations nécessaires à la gestion de Security Lake. Vous pouvez configurer les notifications pour détecter tout accès direct à ces compartiments S3.
