Workloads OU — Compte d'application

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 d'application (ainsi que l'application elle-même).

Le compte Application héberge l'infrastructure et les services principaux permettant d'exécuter et de gérer une application d'entreprise. Le compte d'application et l'unité d'organisation Workloads répondent à quelques objectifs de sécurité principaux. Tout d'abord, vous créez un compte distinct pour chaque application afin de définir des limites et des contrôles entre les charges de travail afin d'éviter les problèmes liés au mélange des rôles, des autorisations, des données et des clés de chiffrement. Vous souhaitez fournir un conteneur de comptes distinct dans lequel l'équipe chargée de l'application peut bénéficier de droits étendus pour gérer sa propre infrastructure sans affecter les autres. Ensuite, vous ajoutez une couche de protection en fournissant un mécanisme permettant à l'équipe des opérations de sécurité de surveiller et de collecter les données de sécurité. Utilisez un suivi organisationnel et des déploiements locaux de services de sécurité des comptes (Amazon GuardDuty, AWS Config, AWS Security Hub, Amazon EventBridge, AWS IAM Access Analyzer), qui sont configurés et surveillés par l'équipe de sécurité. Enfin, vous permettez à votre entreprise de configurer les contrôles de manière centralisée. Vous alignez le compte d'application sur la structure de sécurité globale en le faisant membre de l'unité d'organisation Workloads, grâce à laquelle il hérite des autorisations de service, des contraintes et des garde-fous appropriés.

Considération de conception

• Dans votre organisation, il est probable que vous possédiez plusieurs applications métiers. L'UO Workloads est conçue pour héberger la plupart des charges de travail spécifiques à votre entreprise, y compris les environnements de production et de non-production. Ces charges de travail peuvent être une combinaison d'applications commerciales off-the-shelf (COTS) et d'applications personnalisées et de services de données développés en interne. Il existe peu de modèles d'organisation des différentes applications métiers ainsi que de leurs environnements de développement. L'un des modèles consiste à avoir plusieurs unités d'organisation enfants en fonction de votre environnement de développement, tel que la production, la mise en scène, les tests et le développement, et à utiliser des comptes AWS enfants distincts pour les unités d'organisation relatives à différentes applications. Un autre schéma courant consiste à avoir des unités d'organisation enfants distinctes par application, puis à utiliser des comptes AWS enfants distincts pour les environnements de développement individuels. La structure exacte de l'unité d'organisation et du compte dépend de la conception de votre application et des équipes qui gèrent ces applications. Réfléchissez aux contrôles de sécurité que vous souhaitez appliquer, qu'ils soient spécifiques à l'environnement ou à l'application, car il est plus facile de mettre en œuvre ces contrôles en tant que SCP sur les unités d'organisation. Pour plus d'informations sur l'organisation des unités d'organisation axées sur la charge de travail, consultez la section Organisation des unités d'organisation axées sur la charge de travail du livre blanc AWS Organizing Your AWS Environment Using Multiple Accounts.

VPC d'application

Le cloud privé virtuel (VPC) du compte d'application nécessite à la fois un accès entrant (pour les services Web simples que vous modélisez) et un accès sortant (pour les besoins des applications ou des services AWS). Par défaut, les ressources d'un VPC sont routables les unes vers les autres. Il existe deux sous-réseaux privés : l'un pour héberger les instances EC2 (couche application) et l'autre pour Amazon Aurora (couche base de données). La segmentation du réseau entre les différents niveaux, tels que le niveau application et le niveau base de données, est réalisée par le biais de groupes de sécurité VPC, qui limitent le trafic au niveau de l'instance. Pour des raisons de résilience, la charge de travail couvre au moins deux zones de disponibilité et utilise deux sous-réseaux par zone.

Considération de conception

• Vous pouvez utiliser Traffic Mirroring pour copier le trafic réseau à partir d'une interface réseau élastique d'instances EC2. Vous pouvez ensuite envoyer le trafic vers des dispositifs de out-of-band sécurité et de surveillance à des fins d'inspection du contenu, de surveillance des menaces ou de résolution des problèmes. Par exemple, vous souhaiterez peut-être surveiller le trafic qui quitte votre VPC ou le trafic dont la source est extérieure à votre VPC. Dans ce cas, vous refléterez tout le trafic, à l'exception du trafic passant par votre VPC, et vous l'enverrez à une seule appliance de surveillance. Les journaux de flux Amazon VPC ne capturent pas le trafic en miroir ; ils capturent généralement les informations provenant uniquement des en-têtes de paquets. La mise en miroir du trafic fournit des informations plus approfondies sur le trafic réseau en vous permettant d'analyser le contenu réel du trafic, y compris la charge utile. Activez la mise en miroir du trafic uniquement pour l'interface réseau élastique des instances EC2 susceptibles de fonctionner dans le cadre de charges de travail sensibles ou pour lesquelles vous pensez avoir besoin de diagnostics détaillés en cas de problème.

Points de terminaison d'un VPC

Les points de terminaison VPC fournissent une couche supplémentaire de contrôle de sécurité, ainsi que d'évolutivité et de fiabilité. Utilisez-les pour connecter le VPC de votre application à d'autres services AWS. (Dans le compte d'application, l'AWS SRA utilise des points de terminaison VPC pour AWS KMS, AWS Systems Manager et Amazon S3.) Les points de terminaison sont des périphériques virtuels. Il s'agit de composants VPC mis à l’à échelle horizontalement, redondants et hautement disponibles. Ils permettent la communication entre des instances de votre VPC et de vos services sans imposer de risques de disponibilité ou de contraintes de bande passante sur votre trafic réseau. Vous pouvez utiliser un point de terminaison VPC pour connecter de manière privée votre VPC aux services AWS pris en charge et aux services de point de terminaison VPC optimisés par AWS PrivateLink sans avoir besoin d'une passerelle Internet, d'un appareil NAT, d'une connexion VPN ou d'une connexion AWS Direct Connect. Les instances de votre VPC n'ont pas besoin d'adresses IP publiques pour communiquer avec d'autres services AWS. Le trafic entre votre VPC et l'autre service AWS ne quitte pas le réseau Amazon. 

Un autre avantage de l'utilisation des points de terminaison VPC est de permettre la configuration des politiques des points de terminaison. Une stratégie de point de terminaison d'un VPC est une stratégie de ressource IAM que vous attachez à un point de terminaison lorsque vous le créez ou le modifiez. Si vous n'attachez pas de politique IAM lorsque vous créez un point de terminaison, AWS attache pour vous une politique IAM par défaut qui permet un accès complet au service. Une politique de point de terminaison ne remplace ni ne remplace les politiques IAM ou les politiques spécifiques au service (telles que les politiques de compartiment S3). Il s'agit d'une politique IAM distincte permettant de contrôler l'accès du point de terminaison au service spécifié. Cela ajoute ainsi un niveau de contrôle supplémentaire sur lequel les responsables d'AWS peuvent communiquer avec les ressources ou les services.

Amazon EC2

Les instances Amazon EC2 qui composent notre application utilisent la version 2 du service de métadonnées d'instance (IMDSv2). IMDSv2 protège quatre types de vulnérabilités susceptibles d'être utilisées pour tenter d'accéder à l'IMDS : les pare-feux d'applications Web, les proxys inverses ouverts, les vulnérabilités de falsification de requêtes côté serveur (SSRF), les pare-feux ouverts de couche 3 et les NAT. Pour plus d'informations, consultez le billet de blog Ajoutez une défense approfondie contre les pare-feux ouverts, les proxys inverses et les vulnérabilités SSRF grâce aux améliorations apportées au service de métadonnées d'instance EC2.

Utilisez des VPC distincts (en tant que sous-ensemble des limites de compte) pour isoler l'infrastructure par segments de charge de travail. Utilisez des sous-réseaux pour isoler les niveaux de votre application (par exemple, web, application et base de données) dans un VPC unique. Utilisez des sous-réseaux privés pour vos instances si elles ne doivent pas être accessibles directement à partir d'Internet. Pour appeler l'API Amazon EC2 depuis votre sous-réseau privé sans passer par une passerelle Internet, utilisez AWS. PrivateLink Limitez l'accès à vos instances en utilisant des groupes de sécurité. Utilisez des journaux de flux VPC pour surveiller la trafic atteignant vos instances. Utilisez le gestionnaire de session, une fonctionnalité d'AWS Systems Manager, pour accéder à vos instances à distance au lieu d'ouvrir des ports SSH entrants et de gérer des clés SSH. Utilisez des volumes Amazon Elastic Block Store (Amazon EBS) distincts pour le système d'exploitation et vos données. Vous pouvez configurer votre compte AWS pour appliquer le chiffrement des nouveaux volumes EBS et des copies instantanées que vous créez. 

Exemple de mise en œuvre

La bibliothèque de code AWS SRA fournit un exemple d'implémentation du chiffrement Amazon EBS par défaut dans Amazon EC2. Il montre comment activer le chiffrement Amazon EBS par défaut au niveau du compte au sein de chaque compte AWS et de chaque région AWS de l'organisation AWS.

Application Load Balancers

Les équilibreurs de charge des applications distribuent le trafic applicatif entrant sur plusieurs cibles, telles que les instances EC2, dans plusieurs zones de disponibilité. Dans l'AWS SRA, le groupe cible de l'équilibreur de charge est constitué des instances EC2 de l'application. L'AWS SRA utilise des écouteurs HTTPS pour s'assurer que le canal de communication est chiffré. L'Application Load Balancer utilise un certificat de serveur pour mettre fin à la connexion frontale, puis pour déchiffrer les demandes des clients avant de les envoyer aux cibles.

AWS Certificate Manager (ACM) s'intègre nativement aux équilibreurs de charge d'application, et AWS SRA utilise ACM pour générer et gérer les certificats publics X.509 (serveur TLS) nécessaires. Vous pouvez appliquer le protocole TLS 1.2 et des chiffrements forts pour les connexions frontales grâce à la politique de sécurité Application Load Balancer. Pour de plus amples informations, veuillez consulter la documentation relative à Elastic Load Balancing. 

Considérations relatives à la conception

• Pour les scénarios courants tels que les applications strictement internes qui nécessitent un certificat TLS privé sur l'Application Load Balancer, vous pouvez utiliser ACM dans ce compte pour générer un certificat privé à partir de. Autorité de certification privée AWS Dans l'AWS SRA, l'autorité de certification privée racine d'ACM est hébergée dans le compte Security Tooling et peut être partagée avec l'ensemble de l'organisation AWS ou avec des comptes AWS spécifiques pour émettre des certificats d'entité finale, comme décrit précédemment dans la section relative au compte Security Tooling. 

• Pour les certificats publics, vous pouvez utiliser ACM pour générer ces certificats et les gérer, y compris la rotation automatique. Vous pouvez également générer vos propres certificats en utilisant les outils SSL/TLS pour créer une demande de signature de certificat (CSR), faire signer la CSR par une autorité de certification (CA) pour produire un certificat, puis importer le certificat dans ACM ou le télécharger sur IAM pour l'utiliser avec Application Load Balancer. Si vous importez un certificat dans ACM, vous devez surveiller sa date d'expiration et le renouveler avant son expiration. 

• Pour des niveaux de défense supplémentaires, vous pouvez déployer des politiques AWS WAF afin de protéger l'Application Load Balancer. Le fait de disposer de politiques périphériques, de politiques d'application et même de couches d'application des politiques privées ou internes améliore la visibilité des demandes de communication et permet une application unifiée des politiques. Pour plus d'informations, consultez le billet de blog Deploying defense in depth using AWS Managed Rules for AWS WAF.

Autorité de certification privée AWS

AWS Private Certificate Authority(Autorité de certification privée AWS) est utilisé dans le compte Application pour générer des certificats privés à utiliser avec un Application Load Balancer. Il est courant que les équilibreurs de charge d'application diffusent du contenu sécurisé via le protocole TLS. Cela nécessite l'installation de certificats TLS sur l'Application Load Balancer. Pour les applications strictement internes, les certificats TLS privés peuvent fournir le canal sécurisé.

Dans l'AWS SRA, Autorité de certification privée AWS il est hébergé dans le compte Security Tooling et partagé avec le compte d'application à l'aide de la RAM AWS. Cela permet aux développeurs d'un compte d'application de demander un certificat à une autorité de certification privée partagée. Le partage des autorités de certification au sein de votre organisation ou entre des comptes AWS permet de réduire le coût et la complexité liés à la création et à la gestion des autorités de certification dupliquées dans tous vos comptes AWS. Lorsque vous utilisez ACM pour émettre des certificats privés à partir d'une autorité de certification partagée, le certificat est généré localement dans le compte demandeur, et ACM assure la gestion complète du cycle de vie et le renouvellement.

Amazon Inspector

L'AWS SRA utilise Amazon Inspector pour détecter et analyser automatiquement les instances EC2 et les images de conteneur qui se trouvent dans l'Amazon Elastic Container Registry (Amazon ECR) afin de détecter les vulnérabilités logicielles et les expositions involontaires sur le réseau.

Amazon Inspector est placé dans le compte d'application, car il fournit des services de gestion des vulnérabilités aux instances EC2 de ce compte. En outre, Amazon Inspector signale les chemins réseau indésirables vers et depuis les instances EC2.

Amazon Inspector dans les comptes membres est géré de manière centralisée par le compte d'administrateur délégué. Dans l'AWS SRA, le compte Security Tooling est le compte d'administrateur délégué. Le compte d'administrateur délégué peut gérer les données des résultats et certains paramètres pour les membres de l'organisation. Cela inclut l'affichage des détails des résultats agrégés pour tous les comptes membres, l'activation ou la désactivation des scans des comptes membres et l'examen des ressources numérisées au sein de l'organisation AWS. 

Considération de conception

• Vous pouvez utiliser Patch Manager, une fonctionnalité d'AWS Systems Manager, pour déclencher l'application de correctifs à la demande afin de corriger les failles de sécurité critiques d'Amazon Inspector, notamment les failles de sécurité « zero-day ». Le gestionnaire de correctifs vous permet de corriger ces vulnérabilités sans avoir à attendre le calendrier normal d'application des correctifs. La correction est effectuée à l'aide du runbook Systems Manager Automation. Pour plus d'informations, consultez la série de blogs en deux parties Automatisez la gestion et la correction des vulnérabilités dans AWS à l'aide d'Amazon Inspector et d'AWS Systems Manager.

Amazon Systems Manager

AWS Systems Manager est un service AWS que vous pouvez utiliser pour consulter les données opérationnelles de plusieurs services AWS et automatiser les tâches opérationnelles sur l'ensemble de vos ressources AWS. Grâce aux flux de travail d'approbation et aux runbooks automatisés, vous pouvez réduire les erreurs humaines et simplifier les tâches de maintenance et de déploiement sur les ressources AWS.

Outre ces fonctionnalités d'automatisation générales, Systems Manager prend en charge un certain nombre de fonctionnalités de sécurité préventives, détectives et réactives. L'agent AWS Systems Manager (agent SSM) est un logiciel Amazon qui peut être installé et configuré sur une instance EC2, un serveur sur site ou une machine virtuelle (VM). SSM Agent permet à Systems Manager de mettre à jour, gérer et configurer ces ressources. Systems Manager vous aide à maintenir la sécurité et la conformité en scannant ces instances gérées et en signalant (ou en prenant des mesures correctives) les violations détectées dans vos correctifs, configurations et politiques personnalisées. 

AWS SRA utilise le gestionnaire de session, une fonctionnalité de Systems Manager, pour fournir une expérience de shell et de CLI interactive basée sur un navigateur. Cela permet une gestion d'instance sécurisée et vérifiable sans qu'il soit nécessaire d'ouvrir les ports entrants, de gérer les hôtes Bastion ou de gérer les clés SSH. L'AWS SRA utilise le Patch Manager, une fonctionnalité de Systems Manager, pour appliquer des correctifs aux instances EC2 à la fois pour les systèmes d'exploitation et les applications. 

L'AWS SRA utilise également l'automatisation, une fonctionnalité de Systems Manager, pour simplifier les tâches courantes de maintenance et de déploiement des instances Amazon EC2 et des autres ressources AWS. L'automatisation peut simplifier les tâches informatiques courantes, telles que la modification de l'état d'un ou plusieurs nœuds (à l'aide d'une automatisation de l'approbation) et la gestion des états des nœuds en fonction d'un calendrier. Systems Manager inclut des fonctions qui vous permettent de cibler de grands groupes d'instances à l'aide de balises, et des contrôles de rapidité qui vous aident à déployer les modifications selon les limites que vous définissez. L'automatisation propose des automatisations en un clic pour simplifier des tâches complexes telles que la création d'images Amazon Machine (AMI) dorées et la restauration d'instances EC2 inaccessibles. En outre, vous pouvez améliorer la sécurité opérationnelle en donnant aux rôles IAM l'accès à des runbooks spécifiques pour exécuter certaines fonctions, sans accorder directement d'autorisations à ces rôles. Par exemple, si vous souhaitez qu'un rôle IAM soit autorisé à redémarrer des instances EC2 spécifiques après des mises à jour de correctifs, mais que vous ne souhaitez pas accorder l'autorisation directement à ce rôle, vous pouvez créer un runbook d'automatisation et autoriser le rôle à exécuter uniquement le runbook.

Considérations relatives à la conception

• Systems Manager s'appuie sur les métadonnées d'instance EC2 pour fonctionner correctement. Systems Manager peut accéder aux métadonnées des instances en utilisant la version 1 ou la version 2 du service de métadonnées d'instance (IMDSv1 et IMDSv2). 

• L'agent SSM doit communiquer avec différents services et ressources AWS tels que les messages Amazon EC2, Systems Manager et Amazon S3. Pour que cette communication ait lieu, le sous-réseau nécessite soit une connectivité Internet sortante, soit le provisionnement de points de terminaison VPC appropriés. L'AWS SRA utilise des points de terminaison VPC pour que l'agent SSM établisse des chemins réseau privés vers divers services AWS. 

• Automation vous permet de partager les bonnes pratiques avec le reste de votre organisation. Vous pouvez créer les meilleures pratiques pour la gestion des ressources dans les runbooks et partager les runbooks entre les régions et les groupes AWS. Vous pouvez également restreindre les valeurs autorisées pour les paramètres du runbook. Dans ces cas d'utilisation, vous devrez peut-être créer des runbooks d'automatisation dans un compte central tel que Security Tooling ou Shared Services et les partager avec le reste de l'organisation AWS. Les cas d'utilisation courants incluent la capacité de mettre en œuvre de manière centralisée les correctifs et les mises à jour de sécurité, de remédier aux dérives liées aux configurations VPC ou aux politiques relatives aux compartiments S3, et de gérer les instances EC2 à grande échelle. Pour plus de détails sur la mise en œuvre, consultez la documentation de Systems Manager.

Amazon Aurora

Dans l'AWS SRA, Amazon Aurora et Amazon S3 constituent le niveau de données logique. Aurora est un moteur de base de données relationnelle entièrement géré compatible avec MySQL et PostgreSQL. Une application exécutée sur les instances EC2 communique avec Aurora et Amazon S3 selon les besoins. Aurora est configuré avec un cluster de base de données au sein d'un groupe de sous-réseaux de base de données. 

Considération de conception

• Comme dans de nombreux services de base de données, la sécurité d'Aurora est gérée à trois niveaux. Pour contrôler qui peut effectuer des actions de gestion Amazon Relational Database Service (Amazon RDS) sur les clusters de base de données et les instances de base de données Aurora, vous utilisez IAM. Pour contrôler quels appareils et instances EC2 peuvent ouvrir des connexions au point de terminaison du cluster et au port de l'instance de base de données pour les clusters de base de données Aurora dans un VPC, vous utilisez un groupe de sécurité VPC. Pour authentifier les connexions et les autorisations pour un cluster de base de données Aurora, vous pouvez adopter la même approche qu'avec une instance de base de données autonome de MySQL ou PostgreSQL, ou vous pouvez utiliser l'authentification de base de données IAM pour Aurora MySQL Compatible Edition. Avec cette dernière approche, vous vous authentifiez auprès de votre cluster de base de données compatible Aurora MySQL à l'aide d'un rôle IAM et d'un jeton d'authentification.

Amazon S3

Amazon S3 est un service de stockage d'objets qui offre une évolutivité, une disponibilité des données, une sécurité et des performances de pointe. Il s'agit de l'épine dorsale de nombreuses applications basées sur AWS, et les autorisations et contrôles de sécurité appropriés sont essentiels pour protéger les données sensibles. Pour connaître les meilleures pratiques de sécurité recommandées pour Amazon S3, consultez la documentation, les conférences techniques en ligne et des informations plus détaillées dans les articles de blog. La meilleure pratique la plus importante consiste à bloquer l'accès trop permissif (en particulier l'accès public) aux compartiments S3.

AWS KMS

L'AWS SRA illustre le modèle de distribution recommandé pour la gestion des clés, dans lequel la clé KMS réside dans le même compte AWS que la ressource à chiffrer. Pour cette raison, AWS KMS est utilisé dans le compte d'application en plus d'être inclus dans le compte Security Tooling. Dans le compte d'application, AWS KMS est utilisé pour gérer les clés spécifiques aux ressources de l'application. Vous pouvez mettre en œuvre une séparation des tâches en utilisant des politiques clés pour accorder des autorisations d'utilisation clés aux rôles d'application locaux et pour restreindre les autorisations de gestion et de surveillance à vos principaux dépositaires. 

Considération de conception

• Dans un modèle distribué, la responsabilité de la gestion des clés AWS KMS incombe à l'équipe chargée de l'application. Toutefois, votre équipe de sécurité centrale peut être chargée de la gouvernance et de la surveillance d'événements cryptographiques importants tels que les suivants :

  • Les éléments de clé importés dans une clé KMS approchent de leur date d'expiration.

  • Les éléments de clé dans une clé KMS ont effectué automatiquement une rotation.

  • Une clé KMS a été supprimée.

  • Le taux d'échec du déchiffrement est élevé.

AWS CloudHSM

AWS CloudHSM fournit des modules de sécurité matériels gérés (HSM) dans le cloud AWS. Il vous permet de générer et d'utiliser vos propres clés de chiffrement sur AWS en utilisant des HSM validés FIPS 140-2 de niveau 3 auxquels vous contrôlez l'accès. Vous pouvez utiliser CloudHSM pour décharger le traitement SSL/TLS de vos serveurs Web. Cela réduit la charge du serveur Web et renforce la sécurité en stockant la clé privée du serveur Web dans CloudHSM. Vous pouvez également déployer un HSM depuis CloudHSM dans le VPC entrant du compte réseau pour stocker vos clés privées et signer les demandes de certificat si vous devez agir en tant qu'autorité de certification émettrice. 

Considération de conception

• Si vous avez des exigences strictes en matière de norme FIPS 140-2 de niveau 3, vous pouvez également choisir de configurer AWS KMS pour utiliser le cluster CloudHSM comme magasin de clés personnalisé plutôt que d'utiliser le magasin de clés KMS natif. Ce faisant, vous bénéficiez de l'intégration entre AWS KMS et les services AWS qui chiffrent vos données, tout en étant responsable des HSM qui protègent vos clés KMS. Cela combine les HSM à locataire unique sous votre contrôle avec la facilité d'utilisation et d'intégration d'AWS KMS. Pour gérer votre infrastructure CloudHSM, vous devez utiliser une infrastructure à clé publique (PKI) et disposer d'une équipe expérimentée dans la gestion des HSM.

AWS Secrets Manager

AWS Secrets Manager vous aide à protéger les informations d'identification (secrets) dont vous avez besoin pour accéder à vos applications, services et ressources informatiques. Le service vous permet de faire pivoter, de gérer et de récupérer efficacement les informations d'identification de base de données, les clés d'API et autres secrets tout au long de leur cycle de vie. Vous pouvez remplacer les informations d'identification codées en dur dans votre code par un appel d'API à Secrets Manager pour récupérer le secret par programmation. Cela permet de garantir que le secret ne peut pas être compromis par quelqu'un qui examine votre code, car le secret n'existe plus dans le code. Secrets Manager vous aide également à déplacer vos applications entre les environnements (développement, pré-production, production). Au lieu de modifier le code, vous pouvez vous assurer qu'un secret correctement nommé et référencé est disponible dans l'environnement. Cela favorise la cohérence et la réutilisabilité du code d'application dans différents environnements, tout en nécessitant moins de modifications et d'interactions humaines une fois le code testé. 

Avec Secrets Manager, vous pouvez gérer l'accès aux secrets en utilisant des politiques IAM précises et des politiques basées sur les ressources. Vous pouvez contribuer à sécuriser les secrets en les chiffrant à l'aide de clés de chiffrement que vous gérez à l'aide d'AWS KMS. Secrets Manager s'intègre également aux services de journalisation et de surveillance AWS pour un audit centralisé. 

Secrets Manager utilise le chiffrement des enveloppes avec des clés AWS KMS et des clés de données pour protéger chaque valeur secrète. Lorsque vous créez un secret, vous pouvez choisir n'importe quelle clé symétrique gérée par le client dans le compte et la région AWS, ou vous pouvez utiliser la clé gérée par AWS pour Secrets Manager. 

La meilleure pratique consiste à surveiller vos secrets pour enregistrer toute modification apportée à ceux-ci. Cela vous permet de vous assurer que toute utilisation ou modification imprévue peut être étudiée. Les modifications indésirables peuvent être annulées. Secrets Manager prend actuellement en charge deux services AWS qui vous permettent de surveiller votre organisation et votre activité : AWS CloudTrail et AWS Config. CloudTrail capture tous les appels d'API pour Secrets Manager sous forme d'événements, y compris les appels depuis la console Secrets Manager et les appels de code vers les API de Secrets Manager. En outre, CloudTrail capture d'autres événements connexes (non liés à l'API) susceptibles d'avoir un impact sur la sécurité ou la conformité de votre compte AWS ou de vous aider à résoudre des problèmes opérationnels. Il s'agit notamment de certains événements de rotation de secrets et de suppression de versions secrètes. AWS Config peut fournir des contrôles de détection en suivant et en surveillant les modifications apportées aux secrets dans Secrets Manager. Ces modifications incluent la description d'un secret, la configuration de rotation, les balises et la relation avec d'autres sources AWS, telles que la clé de chiffrement KMS ou les fonctions AWS Lambda utilisées pour la rotation des secrets. Vous pouvez également configurer Amazon EventBridge, qui reçoit les notifications de modification de configuration et de conformité d'AWS Config, pour acheminer des événements secrets particuliers à des fins de notification ou de mesures correctives. 

Dans l'AWS SRA, Secrets Manager est situé dans le compte de l'application pour prendre en charge les cas d'utilisation des applications locales et pour gérer les secrets proches de leur utilisation. Ici, un profil d'instance est attaché aux instances EC2 dans le compte d'application. Des secrets distincts peuvent ensuite être configurés dans Secrets Manager pour permettre à ce profil d'instance de récupérer des secrets, par exemple pour rejoindre le domaine Active Directory ou LDAP approprié et pour accéder à la base de données Aurora. Secrets Manager s'intègre à Amazon RDS pour gérer les informations d'identification des utilisateurs lorsque vous créez, modifiez ou restaurez une instance de base de données Amazon RDS ou un cluster de base de données multi-AZ. Cela vous permet de gérer la création et la rotation des clés et de remplacer les informations d'identification codées en dur dans votre code par des appels d'API programmatiques à Secrets Manager.

Considération de conception

• En général, configurez et gérez Secrets Manager dans le compte le plus proche de l'endroit où les secrets seront utilisés. Cette approche tire parti de la connaissance locale du cas d'utilisation et apporte rapidité et flexibilité aux équipes de développement d'applications. Pour les informations étroitement contrôlées nécessitant un niveau de contrôle supplémentaire, les secrets peuvent être gérés de manière centralisée par Secrets Manager dans le compte Security Tooling.

Amazon Cognito

Amazon Cognito vous permet d'ajouter l'inscription, la connexion et le contrôle d'accès des utilisateurs à vos applications Web et mobiles rapidement et efficacement. Amazon Cognito s'adapte à des millions d'utilisateurs et prend en charge la connexion auprès de fournisseurs d'identité sociale, tels qu'Apple, Facebook, Google et Amazon, ainsi que de fournisseurs d'identité d'entreprise via SAML 2.0 et OpenID Connect. Les deux principaux composants d'Amazon Cognito sont les groupes d'utilisateurs et les groupes d'identités. Les groupes d'utilisateurs sont des annuaires d'utilisateurs qui fournissent des options d'inscription et de connexion aux utilisateurs de votre application. Les groupes d'identités vous permettent d'accorder à vos utilisateurs l'accès à d'autres services AWS. Vous pouvez utiliser des groupes d'identités et des groupes d'utilisateurs séparément ou conjointement. Pour les scénarios d'utilisation courants, consultez la documentation Amazon Cognito.

Amazon Cognito fournit une interface utilisateur intégrée et personnalisable pour l'inscription et la connexion des utilisateurs. Vous pouvez utiliser Android, iOS et les JavaScript kits SDK pour Amazon Cognito afin d'ajouter des pages d'inscription et de connexion utilisateur à vos applications. Amazon Cognito Sync est un service et une bibliothèque client AWS qui permettent la synchronisation entre appareils des données utilisateur relatives aux applications.  

Amazon Cognito prend en charge l'authentification multifactorielle et le chiffrement des données au repos et des données en transit. Les groupes d'utilisateurs Amazon Cognito fournissent des fonctionnalités de sécurité avancées pour protéger l'accès aux comptes de votre application. Ces fonctionnalités de sécurité avancées fournissent une authentification adaptative basée sur le risque et une protection contre l'utilisation d'informations d'identification compromises.  

Considérations relatives à la conception

• Vous pouvez créer une fonction AWS Lambda, puis la déclencher lors des opérations du groupe d'utilisateurs, telles que l'inscription, la confirmation et la connexion (authentification) des utilisateurs à l'aide d'un déclencheur AWS Lambda. Vous pouvez ajouter des stimulations d'authentification, migrer des utilisateurs et personnaliser les messages de vérification. Pour les opérations courantes et le flux d'utilisateurs, consultez la documentation Amazon Cognito. Amazon Cognito appelle les fonctions Lambda de manière synchrone. 

• Vous pouvez utiliser les groupes d'utilisateurs Amazon Cognito pour sécuriser les petites applications multi-locataires. Un cas d'utilisation courant de la conception à locataires multiples consiste à exécuter des charges de travail pour prendre en charge le test de plusieurs versions d'une application. Une conception multilocataire est également utile pour tester une application unique avec différents jeux de données, ce qui vous permet d'utiliser pleinement vos ressources de cluster. Assurez-vous toutefois que le nombre de locataires et le volume attendu correspondent aux quotas de service Amazon Cognito correspondants. Ces quotas sont partagés entre tous les locataires au sein de votre application.

Amazon Verified Permissions

Amazon Verified Permissions est un service de gestion des autorisations évolutif et précis pour les applications que vous créez. Les développeurs et les administrateurs peuvent utiliser Cedar, un langage de politique open source spécialement conçu et axé sur la sécurité, avec des rôles et des attributs pour définir des contrôles d'accès plus granulaires, sensibles au contexte et basés sur des politiques. Les développeurs peuvent créer des applications plus sécurisées plus rapidement en externalisant les autorisations et en centralisant la gestion et l'administration des politiques. Les autorisations vérifiées incluent des définitions de schéma, la grammaire des déclarations de politique et un raisonnement automatique qui s'étend à des millions d'autorisations, afin que vous puissiez appliquer les principes du refus par défaut et du moindre privilège. Le service inclut également un outil de simulation d'évaluation pour vous aider à tester vos décisions d'autorisation et vos politiques d'auteur. Ces fonctionnalités facilitent le déploiement d'un modèle d'autorisation détaillé et précis pour vous aider à atteindre vos objectifs de confiance zéro. Verified Permissions centralise les autorisations dans un magasin de politiques et aide les développeurs à utiliser ces autorisations pour autoriser les actions des utilisateurs dans leurs applications.

Vous pouvez connecter votre application au service via l'API pour autoriser les demandes d'accès des utilisateurs. Pour chaque demande d'autorisation, le service récupère les politiques pertinentes et évalue ces politiques afin de déterminer si un utilisateur est autorisé à effectuer une action sur une ressource, en fonction des entrées contextuelles telles que les utilisateurs, les rôles, l'appartenance à un groupe et les attributs. Vous pouvez configurer et connecter les autorisations vérifiées pour envoyer vos journaux de gestion des politiques et d'autorisation à AWS CloudTrail. Si vous utilisez Amazon Cognito comme banque d'identités, vous pouvez l'intégrer à Verified Permissions et utiliser l'identifiant et les jetons d'accès renvoyés par Amazon Cognito dans les décisions d'autorisation de vos applications. Vous fournissez des jetons Amazon Cognito à Verified Permissions, qui utilise les attributs qu'ils contiennent pour représenter le principal et identifier les droits du principal. Pour plus d'informations sur cette intégration, consultez le billet de blog AWS Simplifying fine authorization with Amazon Verified Permissions and Amazon Cognito.

Les autorisations vérifiées vous aident à définir le contrôle d'accès basé sur des politiques (PBAC). Le PBAC est un modèle de contrôle d'accès qui utilise des autorisations exprimées sous forme de politiques pour déterminer qui peut accéder à quelles ressources d'une application. Le PBAC réunit le contrôle d'accès basé sur les rôles (RBAC) et le contrôle d'accès basé sur les attributs (ABAC), ce qui donne un modèle de contrôle d'accès plus puissant et plus flexible. Pour en savoir plus sur le PBAC et sur la façon de concevoir un modèle d'autorisation à l'aide des autorisations vérifiées, consultez le billet de blog AWS intitulé Le contrôle d'accès basé sur des politiques dans le développement d'applications avec Amazon Verified Permissions.

Dans l'AWS SRA, les autorisations vérifiées sont situées dans le compte de l'application pour prendre en charge la gestion des autorisations pour les applications grâce à son intégration à Amazon Cognito.

Défense en couches

Le compte d'application permet d'illustrer les principes de défense à plusieurs niveaux qu'AWS met en œuvre. Prenez en compte la sécurité des instances EC2 qui constituent le cœur d'un exemple d'application simple représenté dans l'AWS SRA et vous pourrez voir comment les services AWS fonctionnent ensemble dans le cadre d'une défense à plusieurs niveaux. Cette approche s'aligne sur la vision structurelle des services de sécurité AWS, comme décrit dans la section Appliquer les services de sécurité au sein de votre organisation AWS plus haut dans ce guide.

• La couche la plus interne est constituée des instances EC2. Comme indiqué précédemment, les instances EC2 incluent de nombreuses fonctionnalités de sécurité natives par défaut ou en option. Les exemples incluent IMDSv2, le système Nitro et le chiffrement du stockage Amazon EBS.

• La deuxième couche de protection se concentre sur le système d'exploitation et les logiciels exécutés sur les instances EC2. Des services tels qu'Amazon Inspector et AWS Systems Manager vous permettent de surveiller, de signaler et de prendre des mesures correctives sur ces configurations. Inspector surveille les vulnérabilités de votre logiciel et Systems Manager vous aide à garantir la sécurité et la conformité en analysant l'état des correctifs et de la configuration des instances gérées, puis en signalant et en prenant les mesures correctives que vous spécifiez.

• Les instances et les logiciels exécutés sur ces instances sont intégrés à votre infrastructure réseau AWS. Outre les fonctionnalités de sécurité d'Amazon VPC, l'AWS SRA utilise également des points de terminaison VPC pour fournir une connectivité privée entre le VPC et les services AWS pris en charge, et pour fournir un mécanisme permettant de placer des politiques d'accès aux limites du réseau.

• L'activité et la configuration des instances EC2, du logiciel, du réseau et des rôles et ressources IAM sont également surveillées par des services axés sur les comptes AWS tels qu'AWS Security Hub, Amazon, AWS, GuardDuty AWS CloudTrail Config, AWS IAM Access Analyzer et Amazon Macie.

• Enfin, au-delà du compte d'application, la RAM AWS permet de contrôler les ressources partagées avec d'autres comptes, et les politiques de contrôle des services IAM vous aident à appliquer des autorisations cohérentes au sein de l'organisation AWS.