C'est un classique : devant la nécessité de protéger votre infrastructure cloud AWS, vous consultez la documentation dédiée sur les bonnes pratiques de sécurité, appliquez ce que vous y trouvez, puis laissez tout ça derrière vous. Mais qu'en est-il si vous avez besoin d'une configuration plus poussée ? Ou lorsque les recommandations ne s'appliquent pas à votre cas ?

Cet article se penche sur les suggestions d'Amazon et vous explique pourquoi il ne suffit pas toujours de suivre aveuglément les bonnes pratiques de sécurité qu'elle recommande.

Bonnes pratiques – Ce qu'elles ne vous disent pas

Nous savons par expérience qu'il existe une multitude de ressources accessibles sur les bonnes pratiques en matière de sécurité. Pourtant, elles se concentrent généralement toutes sur les mêmes points et sur les premières étapes de la protection de l'infrastructure cloud.

Elles vous guident entre autres pour la configuration des éléments de base, comme les utilisateurs/rôles IAM et l'authentification multifacteur (MFA), et vous avertissent de la nécessité de disposer de mots de passe forts et de les chiffrer (en utilisant par exemple KMS). Ces conseils avisés sont utiles au début, mais ils peinent souvent à évoluer et n'offrent certainement pas une sécurité suffisamment complète et solide. Si c'est effectivement ce à quoi vous aspirez, il vous faudra creuser davantage.

Méfiance envers l'adjoint confus

Le problème de l'adjoint confus est un problème de sécurité dans lequel une entité qui n'a pas accès aux ressources de votre compte AWS en contraint une autre, plus privilégiée, à y accéder. Cette situation, qui n'intervient que lorsqu'un tiers doit être autorisé à accéder à vos ressources, est toutefois une pratique devenue courante dans l'univers du cloud computing et du SaaS.

Si vous n'y faites pas attention, vous pourriez finir par octroyer à un acteur malveillant un accès illimité à votre infrastructure. Pour éviter ce problème, utilisez un ID externe lors de la définition de vos rôles dans AWS. Cet ID n'est en fait qu'un simple champ (voyez-le comme un mot de passe) que chaque entité doit remplir lors de la prise en charge d'un rôle donné.

L'utilisation de cette option ne doit cependant pas être prise à la légère, car il existe de nombreuses manœuvres pour attaquer ce champ par force brute. Lorsqu'il est configuré, il doit par conséquent être associé à un mot de passe complexe qu'il faudra transmettre chiffré aux prestataires tiers. Pour renforcer encore votre sécurité, vous pouvez alterner périodiquement ces ID externes.

Utilisation de politiques simples, concises et évolutives

Comme vous le savez, AWS utilise des politiques pour accorder ou empêcher l'accès des mandataires aux ressources. D'après leurs instructions, c'est ainsi qu'il vous faut définir qui a accès à quoi. Toutefois, si vous aspirez à vous développer davantage, il vous faut absolument un plan qui vous permettra de conserver ces politiques sur le long terme. Conservez des politiques simples, qui vont à l'essentiel.

Par exemple, si vous avez besoin d'autoriser l'accès à un service en particulier comme AWS Lambda, vous pouvez créer une politique personnalisée dédiée à cette action, et exclusivement à celle-ci. Vous éviterez ainsi les interactions non souhaitées entre les utilisateurs et les services. Par ailleurs, il est préférable d'appliquer plusieurs politiques pour accomplir une action plutôt que d'appliquer une seule politique polyvalente qui sera plus difficile à lire, à préserver, mais aussi à adapter.

Utilisation des groupes IAM plutôt que des utilisateurs et des rôles

Pour en revenir aux politiques, soulignons qu'il est préférable de passer par des groupes IAM plutôt que de les appliquer directement aux utilisateurs ou aux rôles. Cette approche vous permettra de créer plusieurs politiques applicables à de multiples sous-ensembles d'utilisateurs, comme les développeurs, administrateurs système, testeurs, ingénieurs qualité, etc.

Une fois ces politiques établies, elles pourront être appliquées à des groupes, en les répartissant soit par responsabilité, soit par rôle dans votre entreprise. L'avantage est que vous pouvez ici rédiger en ensemble de politiques et les appliquer en une seule fois. Et si vous avez besoin d'une plus grande granularité pour un collaborateur donné, il vous suffit de lui appliquer l'une de vos politiques simples et de configurer les autorisations nécessaires.

S'il vous faut par ailleurs apporter des modifications pour un ensemble d'utilisateurs (les développeurs, par exemple), une simple modification des politiques de leur groupe actualisera toutes celles appliquées aux utilisateurs du groupe en question.

Pourquoi utiliser une solution de gestion comme AWS Systems Manager ?

AWS Systems Manager est un service de sécurité et de synthèse qui permet de centraliser au sein d'une interface unique l'ensemble de vos ressources et flux de travail AWS de façon à explorer librement votre infrastructure. Il vous permet de vérifier et de corriger les vulnérabilités tout en bénéficiant d'un espace unique depuis lequel gérer les données de configuration des applications de l'ensemble de votre environnement.

Grâce à ce service, vous pouvez créer des groupes de ressources dans différents services AWS, puis en consulter les données agrégées. Les renseignements obtenus vous orienteront sur les mesures à prendre et les opérations à automatiser dans ces groupes.

AWS Systems Manager offre également d'autres fonctionnalités sous la forme de petits services comme Incident Manager et Change Manager. Le premier sert à créer des plans d'intervention qui sont déployés à chaque fois que vos applications ou flux de travail présentent des problèmes de disponibilité, de performance ou de sécurité. Vous êtes ainsi averti dès qu'un changement dans votre environnement crée une faille de sécurité qui nécessite d'être réparée au plus vite. Incident Manager exécute les plans dès lors qu'ils sont déclenchés et en informe par e-mail ou SMS les intervenants de première ligne, tout en annulant en parallèle les changements cassants et en fournissant les renseignements post-incidents pertinents.

De son côté, Change Manager facilite la modification de l'infrastructure et de la configuration de votre compte. Il vous offre ainsi la possibilité de créer des « modèles de modification » qui vous évitent les résultats non souhaités lors de certains changements, notamment au niveau des politiques IAM. Il s'avère très utile pour s'assurer qu'aucun changement cassant ne se retrouve dans le flux de travail prédéfini, ce qui écarte les problèmes de sécurité avant même qu'ils n'aient lieu.

Toute cette approche s'intègre parfaitement à une solution de protection axée sur les politiques, ce qui correspond à la manière dont AWS conseille de procéder.

Résumé

Si toutes ces mesures ne s'appliquent pas nécessairement à votre infrastructure, il est intéressant de disposer, pour la protéger, de moyens autres que les cinq conseils d'AWS qui reviennent presque systématiquement. Bien qu'utile, le modèle de responsabilité partagée d'Amazon ne fournit pas réellement d'outils de protection et se contente d'indiquer les éléments de notre environnement auxquels faire attention.

Le fait de chiffrer ses données et les clés d'accès de sécurité n'est pas une nouveauté en soi, et la planification d'une stratégie de sécurité devrait constituer une évidence pour ceux qui gèrent et travaillent avec une infrastructure cloud étendue.

Si ces suggestions ont pour objectif de vous aider à améliorer votre sécurité, ceux qui recherchent une solution davantage managée peuvent aussi tester CrowdStrike Falcon for AWS. Ce service fournit une protection de bout en bout — de l'hôte jusqu'au cloud, en passant par tous les maillons intermédiaires — tout en vous offrant une totale visibilité sur l'ensemble de vos ressources, comptes et instances.