Notions de base de la sécurité

Lorsque vous créez un compte AWS, vous commencez par ce que l'on appelle l'utilisateur root. Il s'agit du premier utilisateur AWS qui existe dans votre compte AWS. AWS vous recommande de ne pas utiliser ce compte pour les opérations quotidiennes, car il dispose d'un accès et d'un contrôle complets sur le compte, et doit suivre les meilleures pratiques recommandées pour sécuriser l'utilisateur root. Cela implique le verrouillage de vos clés d'accès utilisateur root, l'utilisation d'un mot de passe fort, l'activation de l'authentification multifactorielle AWS et la création d'un utilisateur IAM pour accéder à votre compte. Ce compte peut se voir attribuer des privilèges d'administrateur et doit être utilisé pour toutes les tâches administratives futures.

Ensuite, vous devez attribuer des contacts de sécurité alternatifs à votre compte. Ceux-ci recevront des notifications relatives à la sécurité, notamment de la part de l'équipe AWS Trust & Safety. Pour en savoir plus sur l'importance de définir ces informations de contact dès le début de la configuration de votre compte, consultez l'article de blog Mettre à jour le contact de sécurité alternatif sur l'ensemble de vos comptes AWS pour recevoir des notifications de sécurité en temps opportun.

Une fois que vous avez confirmé vos contacts de sécurité, vous devez prendre en compte les régions AWS dans lesquelles vos charges de travail doivent être exécutées et celles dans lesquelles elles ne doivent pas être exécutées. Vous pouvez ensuite verrouiller les régions non utilisées pour vous assurer qu'aucune charge de travail ne peut être exécutée à partir de ces régions. En plus d'optimiser les coûts, cela permet de renforcer la sécurité. Comment ? En verrouillant les régions dans lesquelles vous ne prévoyez pas d'exécuter de charges de travail, vous pouvez concentrer vos efforts de surveillance sur les régions que vous utilisez activement.

À ce stade, vous avez sécurisé l'utilisateur root, créé un ou plusieurs utilisateurs IAM, attribué des contacts de sécurité et verrouillé les régions dans lesquelles les charges de travail peuvent être exécutées. Voyons maintenant comment les utilisateurs interagiront avec les ressources AWS. Il existe deux modes principaux d'interaction : l'interface de la ligne de commande AWS (AWS CLI) et la Console de gestion AWS. Il est recommandé de configurer l'authentification unique pour la CLI AWS et la console. Consultez l'article Configuration de l'interface de ligne de commande AWS pour utiliser AWS IAM Identity Center (successeur d'AWS Single Sign-On) pour en savoir plus sur la gestion centralisée des accès avec AWS IAM Identity Center.

L'étape suivante pour sécuriser votre compte consiste à configurer des groupes d'utilisateurs AWS IAM pour contrôler l'accès. Plutôt que de contrôler l'accès de chaque utilisateur en définissant des politiques directement sur l'utilisateur, il est préférable de créer un groupe, de lui attribuer les autorisations nécessaires, puis d'affecter des utilisateurs au groupe. Les utilisateurs hériteront des autorisations de ce groupe. Il s'agit d'un moyen plus évolutif de fournir un contrôle d'accès à de multiples utilisateurs. Il est important de comprendre comment fonctionnent IAM et les groupes IAM, car ils couvrent plusieurs services. IAM est un service qui interagit avec tous les services AWS à des degrés divers. Prenez donc le temps de vous familiariser avec lui.

Si vous suivez ces pratiques dès le départ, l'accès à vos ressources AWS sera plus sécurisé. Nous allons maintenant voir comment sécuriser l'infrastructure que vous compilez sur AWS.

Au fur et à mesure que vous développez votre infrastructure cloud, vous allez commencer par créer un Amazon Virtual Private Cloud (Amazon VPC). Il s'agit d'un réseau virtuel que vous définissez (un réseau par défaut est créé dans chaque région lorsque vous créez votre compte) et qui vous permet de lancer des ressources. Un VPC ressemble à un réseau traditionnel car une plage d'adresses IP CIDR lui est attribuée et est subdivisée en créant des sous-réseaux. Vos sous-réseaux peuvent être utilisés pour isoler différents ensembles de ressources. Les sous-réseaux peuvent être publics ou privés. Les sous-réseaux publics ont une route vers une passerelle Internet, ont accès à Internet via cette passerelle et sont accessibles depuis Internet si les contrôles d'accès appropriés le permettent. Les sous-réseaux privés ont également une table de routage, mais n'ont pas de route vers une passerelle Internet. Par conséquent, par défaut, ils ne peuvent pas accéder à Internet et ne sont pas accessibles depuis Internet. Pour permettre aux ressources d'un sous-réseau privé d'accéder à Internet, une passerelle NAT est nécessaire. Au niveau du sous-réseau, une liste de contrôle d'accès réseau (ACL) autorise ou refuse un trafic entrant ou sortant spécifique. Vous pouvez utiliser la liste ACL réseau par défaut ou créer une liste ACL réseau personnalisée pour votre VPC. Les listes ACL réseau sont des listes numérotées, traitées de haut en bas, et sont statiques. Cela signifie que vous aurez besoin d'une règle de liste ACL réseau entrant et sortant pour autoriser le trafic bidirectionnel.

Lorsque vous déployez des ressources EC2 dans votre VPC, vous leur associez un groupe de sécurité. Celui-ci contrôle le trafic entrant et sortant pouvant atteindre les ressources EC2. Les groupes de sécurité sont semblables à un pare-feu, mais au lieu d'utiliser simplement une liste ou une plage d'adresses IP, ils peuvent pointer vers ce que l'on appelle une référence de ressource. Une référence de ressource est un groupe nommé qui tient à jour la liste des adresses IP attribuées à chaque ressource du groupe. Par exemple, si vous créez un groupe de scalabilité automatique pour mettre en service des instances Amazon EC2, une nouvelle adresse IP est attribuée à chaque instance lors du démarrage. En ajoutant un groupe de sécurité à ces instances, vous pouvez autoriser l'accès au groupe de sécurité de votre serveur de base de données via l'ID du groupe de sécurité des instances EC2, et toute nouvelle instance EC2 lancée aura accès à la base de données sans que son adresse IP n'ait besoin d'être ajoutée à la liste autorisée.

Les règles des groupes de sécurité sont semblables aux listes ACL réseau, car lorsque vous les créez, vous faites correspondre le port, le protocole et les adresses, mais elles sont dynamiques. Elles sont semblables aux pare-feu dynamiques. Lorsque vous créez une entrée pour autoriser un type de trafic spécifique, vous n'avez pas besoin de créer de règle correspondant au trafic de retour ; celui-ci étant dynamique, il sera autorisé. Pour mieux comprendre comment les groupes de sécurité et les ACL interagissent, cette comparaison est utile.

Pour ajouter une couche supplémentaire de sécurité à l'infrastructure, vous pouvez déployer le pare-feu réseau AWS. Il s'agit d'un service géré qui déploie la protection de votre Amazon VPC. Celui-ci fournit une protection plus précise que les groupes de sécurité, car il peut intégrer le contexte des flux de trafic, comme le suivi des connexions et l'identification des protocoles, pour appliquer des politiques telles que l'interdiction pour vos VPC d'accéder à des domaines en utilisant un protocole non autorisé. Cela se fait par la configuration de règles Suricata personnalisées. Par exemple, vous pouvez configurer le pare-feu réseau pour vous protéger contre les attaques de logiciels malveillants. Pour aller encore plus loin, vous pouvez déployer un autre service géré, AWS Shield Advanced, pour vous protéger contre les menaces DDoS.

Lorsque vous créez des ressources dans AWS, veillez à suivre les bonnes pratiques de sécurité recommandées pour le type de ressource que vous utilisez. Pour les instances EC2, la sécurité commence par le contrôle de l'accès réseau à vos instances, par exemple en configurant votre VPC et vos groupes de sécurité. (Pour plus d'informations, consultez la section « Sécurité Amazon VPC » dans la section « Sécuriser l'infrastructure que vous compilez ».)

Un autre aspect de la sécurité des instances est la gestion des informations d'identification utilisées pour la connexion à vos instances. Celle-ci concerne les autorisations utilisateur IAM que vous attribuez, mais s'étend au groupe attribué. Elle fournit un niveau de sécurité à l'utilisateur qui utilise l'instance EC2, mais pas à l'instance elle-même. Vous devez également configurer les rôles IAM qui sont attachés à l'instance et les autorisations associées à ces rôles. Pour accéder à une instance EC2, au lieu d'ouvrir le port pour SSH ou de configurer un hôte bastion/jump, vous devez utiliser EC2 Instance Connect.

Vous devez vous assurer que le système d'exploitation client et les logiciels déployés sur l'instance sont à jour avec toutes les mises à jour du système d'exploitation et les correctifs de sécurité. Pour plus de détails, consultez la section Sécurité dans Amazon EC2.

La sécurisation de votre base de données est un aspect important de votre approche de sécurité. Comme indiqué dans la section relative à la sécurité d'Amazon VPC, il est recommandé de déployer les bases de données sur un sous-réseau privé afin d'empêcher l'accès de tiers via Internet. AWS propose 15 bases de données sur mesure. Chacune est sécurisée différemment, mais elles ont toutes les caractéristiques suivantes en commun.

Pour accéder à une base de données, une certaine forme d'authentification est requise. Cela peut prendre la forme d'un nom d'utilisateur et d'un mot de passe, qui doivent être changés régulièrement. Vous pouvez également utiliser le proxy Amazon RDS pour tirer parti des rôles IAM afin de gérer l'accès à la base de données pour vous. Certains services de base de données, comme Amazon DynamoDB, utilisent des rôles IAM pour fournir l'accès. Vous n'avez donc pas besoin de gérer vous-même les informations d'identification.

SSH est l'une des méthodes les plus courantes de gestion des instances EC2. Amazon EC2 Instance Connect vous permet d'utiliser SSH pour vous connecter à vos instances EC2 à l'aide de clés SSH uniques directement dans la console. Les articles suivants expliquent comment activer Amazon EC2 Instance Connect et expliquent le cas d'utilisation typique. Vous pouvez également générer des clés SSH lorsque vous créez votre instance EC2, les télécharger localement et les utiliser pour vous connecter à votre instance. Toutefois, cela signifie que vous devez protéger ces clés, vous assurer qu'elles sont stockées à un endroit auquel vous ne perdrez pas l'accès et que vous ne pouvez vous connecter à votre instance qu'à partir d'une machine sur laquelle ces clés ont été téléchargées. EC2 Instance Connect fournit le même accès SSH simple et sécurisé sur toutes les machines depuis la console.

Restreindre l'accès à votre base de données uniquement aux services et à l'infrastructure qui nécessitent un accès est une bonne pratique recommandée. Cela peut être fait en configurant des groupes de sécurité pour vos instances RDS, vos bases de données Amazon Neptune ou pour les clusters Amazon Redshift.

Sauvegarder et tester les restaurations

Sauvegarder vos données et effectuer des restaurations fréquentes pour vérifier que les sauvegardes fonctionnent correctement devrait être une priorité. Avec AWS Backup, vous pouvez facilement configurer et gérer les sauvegardes pour des services AWS spécifiques, notamment Amazon RDS, DynamoDB, Neptune, etc.

Pour une sécurité sans serveur, vous devez connaître AWS Lambda, Amazon API Gateway, Amazon DynamoDB, Amazon SQS et IAM. Avec la sécurité sans serveur, AWS assume une plus grande responsabilité qu'avec le Modèle de responsabilité partagée, mais il faut savoir que le client a encore une certaine responsabilité. Dans un environnement sans serveur, AWS gère l'infrastructure, le calcul, l'environnement d'exécution et le langage d'exécution. Le client est responsable du code de fonction et des bibliothèques du client, de la configuration des ressources et de la gestion des identités et des accès, comme indiqué sur l'image.

Dans les sections suivantes, nous allons détailler les pratiques de sécurité qui relèvent de la responsabilité du client. Pour plus de détails, consultez la section Sécurité dans AWS Lambda.

AWS Lambda fournit des exécutions de votre code de fonction dans un environnement basé sur Amazon Linux. Toutefois, si vous utilisez des bibliothèques supplémentaires avec votre fonction, vous êtes responsable de leur mise à jour. La mise à jour de vos bibliothèques peut vous aider à maintenir votre posture de sécurité.

AWS Lambda s'intègre avec plusieurs ressources AWS telles qu'Amazon DynamoDB, Amazon EventBridge et Amazon Simple Notification Service (Amazon SNS). Suivre les pratiques de sécurité recommandées pour chaque service que vous utilisez dans le cadre de votre fonction permettra de renforcer votre posture de sécurité. La documentation de chaque service fournit des conseils supplémentaires.

L'exécution des fonctions Lambda peut nécessiter des autorisations et des rôles IAM spécifiques. Vous trouverez de plus amples informations dans la section Autorisations du guide du développeur AWS Lambda.

Votre stratégie de sécurité doit également inclure la surveillance, la journalisation et la gestion de la configuration. Par exemple, de nombreuses entreprises effectuent la comptabilisation de leurs appareils à l'aide du protocole TACACS+, de RADIUS ou de journaux Active Directory. Cela leur permet de garantir la création d'une piste d'audit pour toutes les activités administratives. Dans le Cloud AWS, vous pouvez le faire avec AWS CloudTrail. Il s'agit d'un service qui permet l'audit, la surveillance de la sécurité et le dépannage opérationnel en suivant l'activité des utilisateurs et l'utilisation des API. AWS Serverless Application Repository, qui permet aux développeurs et aux entreprises de rechercher, de déployer et de publier rapidement des applications sans serveur dans le Cloud AWS, est intégré à AWS CloudTrail. Pour plus de détails, consultez le guide du développeur d'AWS Serverless Application Repository.

Dans tous les cas, vous devrez fournir une protection contre les DoS et une protection d'infrastructure à vos environnements sans serveur. Pour cela, vous pouvez utiliser AWS Shield et AWS Shield Advanced. La surveillance et la détection des menaces sont abordées plus en détail dans la section « Surveiller votre environnement ».

Sur AWS, les données sont stockées dans Amazon S3, qui dispose de plusieurs contrôles pour protéger les données. L'article Les 10 meilleures pratiques de sécurité pour sécuriser les données dans Amazon S3 couvre les techniques les plus fondamentales. Celles-ci incluent notamment le blocage des compartiments S3 publics au niveau de l'organisation, l'utilisation de politiques relatives aux compartiments pour vérifier que tous les accès accordés sont restreints et spécifiques, ainsi que le chiffrement et la protection des données.

Pour le chiffrement, AWS Key Management Service (AWS KMS) vous permet de créer et de contrôler les clés utilisées pour chiffrer ou signer numériquement vos données. Si vous souhaitez chiffrer vos données sur AWS, plusieurs options s'offrent à vous. La première consiste à utiliser le chiffrement côté serveur avec des clés de chiffrement gérées par Amazon S3 (SSE-S3). Avec cette méthode, le chiffrement est effectué après l'envoi des données à AWS à l'aide de clés gérées par AWS.

La deuxième option consiste à chiffrer les données une fois qu'elles sont dans AWS, mais plutôt que d'utiliser des clés créées et gérées par AWS, vous pouvez effectuer un chiffrement côté serveur à l'aide de clés principales du client (CMK) stockées dans AWS KMS (SSE-KMS).

La troisième option pour stocker des données chiffrées sur AWS consiste à utiliser le chiffrement côté client. Avec cette approche, les données sont chiffrées avant d'être transférées vers AWS.

L'image illustre les avantages du chiffrement côté client et du chiffrement côté serveur pour les clients.

Les VPN peuvent englober plusieurs technologies. L'idée d'un VPN est que vos données en transit conservent leur intégrité et peuvent être échangées en toute sécurité entre deux parties. AWS propose plusieurs technologies qui garantissent la sécurité de vos données en transit. L'une d'entre elles est AWS PrivateLink, qui fournit une connectivité privée cryptée entre les VPC, les services AWS et vos réseaux locaux. Votre trafic n'est pas exposé à l'Internet public. Ce service peut être considéré comme un réseau privé virtuel.

Cependant, dans la plupart des cas, le VPN s'articule autour de l'utilisation du chiffrage des données. Selon le contexte, vous devez fournir un chiffrement entre un client et vos ressources Cloud AWS. Cette situation nécessiterait un VPN client AWS. D'un autre côté, il se peut que vous transmettiez des données entre votre centre de données ou votre filiale et vos ressources AWS. Pour ce faire, vous pouvez utiliser des tunnels IPsec entre vos ressources sur site et vos VPC Amazon ou AWS Transit Gateway. Cette connectivité sécurisée est connue sous le nom de VPN de site à site.

Enfin, vous pouvez également chiffrer les données en transit en gérant vos ressources cloud à l'aide de la console de gestion AWS. Bien que la connectivité avec la console ne fasse pas penser à un VPN en premier lieu, votre session utilise le chiffrement TLS (Transport Layer Security). Vos configurations restent confidentielles lorsque vous compilez votre architecture sécurisée. Le protocole TLS est également utilisé avec l'API AWS.

AWS propose plusieurs services gérés qui vous aident à surveiller votre environnement, ainsi que des options en libre-service. Par exemple, vous pouvez utiliser VPC Flow Logs pour enregistrer et afficher les flux de trafic réseau, ou vous pouvez utiliser Amazon CloudWatch pour analyser les journaux AWS WAF ou même créer des alarmes pour les instances EC2. Pour en savoir plus sur Amazon CloudWatch, consultez cet atelier.

En outre, AWS CloudTrail surveille et enregistre l'activité des comptes sur l'ensemble de votre infrastructure AWS, ce qui vous permet de contrôler le stockage, l'analyse et les actions correctives. Cela est essentiel pour créer une piste d'audit des activités administratives, identifier les incidents de sécurité et résoudre les problèmes opérationnels.

Enfin, Amazon GuardDuty peut être utilisé pour détecter les menaces, et même pour aller encore plus loin en faisant en sorte que les résultats publiés déclenchent des actions de correction automatique dans votre environnement AWS.

En vous attaquant à chacun de ces domaines opérationnels, vous serez sur la bonne voie pour mettre en place les fonctionnalités de sécurité essentielles à votre environnement cloud.