Cet article présente des exemples concrets d’implémentation des bonnes pratiques de sécurité sur le cloud AWS issus de projets réalisés auprès de certains de nos clients grands comptes. Il fait suite à l’article Sécurité sur le Cloud : quelles sont les bonnes pratiques ?

Article écrit en collaboration avec Andres Ortiz

Sécuriser les accès aux ressources

Au coeur de l’infrastructure IaaS, les instances EC2 sont des éléments clés dont l’accès doit être contrôlé et l’exposition limitée. Pour ces raisons, les entreprises cherchent à mettre en place un “bastion d’accès” : un point de passage obligé, fortement sécurisé, permettant de “rebondir” vers les autres instances EC2.

Deux alternatives s’offrent alors aux entreprises :

• Les solutions éditeurs dédiées : souvent très perfectionnés, elles offrent de nombreuses fonctionnalités : opérabilité avec de nombreux outils tiers, possibilité de mutualiser les services (bastion, gestion de l’authentification, audit des accès, etc), environnement d’administrateur convivial…Revers de la médaille : elles sont relativement complexe et leur déploiement impose également des contraintes : impossibilité à automatiser (alors même que l’automatisation est la pierre angulaire d’une philosophie DevSecOps efficiente), coût d’acquisition élevé (à l’opposé du modèle financier “à la demande” d’une stratégie cloud) et difficultés d’intégration dans un environnement cloud. C’est pour cela que certaines entreprises se tournent vers la solution des “bastions maison”.

• Les “bastions maison” : plus simples, ils reposent sur des instances redondées et des AMI (souvent Linux) personnalisées et durcies en interne. Elles assurent la fonction le rebond et imposent un ensemble minimum de contrôles. Moins riches en fonctionnalités que les solutions du marché, ils sont peu coûteux et plus faciles à automatiser. Ils sont aussi plus facilement adaptables à un environnement Cloud/on premise. Par exemple, certaines organisations ont connecté ce type de bastion et leur système de gestion des accès et des identités maison afin de simplifier le processus d’authentification tout en assurer le respect des règles de leur politique de sécurité.

Notons toutefois que ce débat entre bastions du marché ou “maison” va sans doute être très vite dépassé suite à l’apparition du service “Session Manager”, qui pourrait tendre à faire disparaître le besoin de bastion. Session Manager s’appuie sur l’agent SSM et permet d’accéder aux instances depuis une CLI ou directement la console AWS (bash sur une instance Linux, Powershell sur une instance Windows). Les droits d’accès sont basés sur des policies IAM, ce qui permet par exemple d’utiliser le principe des tags pour les définir. Pour le moment, le service est encore jeune et souffre de quelques limitations : il n’offre que l’accès en administration aux instances (impossible de limiter les droits) et il n’est pas possible de l’utiliser pour se connecter en RDP à une instance Windows. Mais on peut supposer qu’il s’améliorera très vite, une affaire à suivre donc !

Mettre en place le filtrage réseau

En terme de filtrage réseau, les plateformes cloud mettent à disposition un vaste choix d’outils. Le mieux étant l’ennemi du bien, le danger est de multiplier les couches inutilement : par exemple en dupliquant les règles de filtrage des Security Group sur les NACL.

La meilleure stratégie est d’envisager les différents services de filtrage comme des outils complémentaires et non redondants. Par exemple, utiliser les NACLs pour autoriser certains flux vers un ensemble de machines (comme par ex. la connexion SSH sur les machines depuis les IP des bastions ou des réseaux spécifiques) ou bloquer certaines IPs source. En parallèle, réserver les Security Groups pour autoriser les connexions depuis des ressources spécifiques (par ex. en autorisant les ressources toolings à se connecter sur des instances d’un répertoire de code, de type Gitlab).

Gérer les comptes et les accès

La gestion des accès à la console et à l’API AWS peut se révéler complexe dès lors qu’une entreprise utilise plusieurs comptes AWS. Afin d’anticiper ces difficultés, il est préférable de construire dès le début son architecture de comptes en créant un compte AWS dédié à l’authentification, compte qui ne contiendra que des utilisateurs et groupes IAM (et sera idéalement le seul à en contenir). Tous les autres comptes AWS de l’entreprise ne contiendront que des rôles IAM qui pourront être assumés depuis le compte dédié à l’authentification. Par la suite, les utilisateurs se verront affectés dans un ou plusieurs groupes, qui leur donneront le droit d’assumer tel ou tel rôle (Admin, DevOps, ReadOnly, …) dans tel ou tel compte AWS (Appli A, Appli B, …).

Il est à noter que cette approche nécessite une gestion automatique du provisionning des comptes AWS pour s’assurer de toujours garder une synchronisation entre d’une part les groupes et droits du compte d’authentification et d’autre part les rôles définis dans les autres comptes AWS.

Autre point important : il est nécessaire d’éviter de tomber dans le travers de la “sur-granularité” des accès. Un utilisateur ne peut être placé que dans 10 groupes maximum ! Il faut donc éviter l’approche “1 groupe pour 1 rôle dans 1 compte” et préférer “1 groupe = 1 profil = plusieurs rôles dans plusieurs comptes”.

Bien que nécessitant une certaine rigueur et une réflexion en amont, les avantages de cette approche sont multiples :

• Disposer d’une gestion centralisée des utilisateurs nativement dans AWS
• Optimiser l’intégration avec Active Directory via un AD connector (grâce au compte d’authentification centralisant les accès, un seul AD connector suffit)
• Faciliter l’intégration avec un produit de type SSO tel que ADFS ou n’importe quel autre provider SAML (du fait que des accès par rôles ont déjà été définis dans tous les comptes de l’entreprise).

Assurer le chiffrement et la gestion des clés

La protection des données clients fait partie des enjeux clés des services Cloud. A ce titre, AWS offre des services de chiffrement disposant d’une grande facilité d’utilisation. Par exemple, le KMS (Key Management Service) s’intègre nativement avec plus de 45 autres services et permet de gérer des clefs de chiffrement pour un coût dérisoire (voir ici un exemple d’usage de KMS).

On constate chez certains clients l’absence totale de chiffrement des volumes EBS ou des buckets S3 : c’est une aberration. Les clefs que KMS génère par défaut pour les autres services ne sont pas facturées. Un client n’ayant pas de contraintes particulières sur le chiffrement peut donc simplement utiliser les clefs par défaut. Il lui suffira juste de cocher une case lors de l’utilisation d’un des services intégrés avec KMS, pour 0$ de facture (on peut ignorer le coût des appels au KMS, 0.03$/10 000 requêtes).
Pour les entreprises ayant des contraintes spécifiques ou désirant simplement avoir une gestion fine des clefs de chiffrement, il est possible de créer des CMK (Customer Master Key). Là encore, KMS (utilisé en sous-jacent) reste très compétitif : 1$ par CMK par mois.

Les CMK offrent diverses possibilités, les plus notables étant :

• le contrôle total des droits d’utiliser la clef via la “Key Policy” (similaire à une policy IAM ou une “Bucket Policy” sur S3)
• la possibilité d’importer soi-même la clef (la CMK est créée comme une enveloppe vide dans laquelle on dépose la véritable clef AES de 256 bits générée par nos soins).

Depuis novembre 2018, il est également possible d’utiliser la fonctionnalité Custom Key Store. Dans ce cas, KMS utilise le service CloudHSM comme backend (au lieu de ses propres HSM). Cela permet notamment un meilleur contrôle sur les clefs, mais au prix d’un cluster CloudHSM, soit environ 2000$ / mois au minimum.

Sécuriser la chaîne CI/CD

Vaste sujet que la sécurisation des pipelines CI/CD : c’est un domaine à part entière. Toutefois, la mise en place de quelques bonnes pratiques relativement simples permettent déjà de se protéger d’une grande partie des attaques les plus classiques. Parmi les mesures les plus habituellement déployées au sein des organisations, on peut en citer deux :

• L’application stricto sensu du principe de least privilege, à travers notamment l’assignation d’un rôle de déploiement à chaque projet plutôt que l’utilisation d’un rôle générique pour l’ensemble des projets (sachant que ce dernier finit malencontreusement souvent par disposer du droit AdministratorAccess).
• L’activation des options de configuration des machines/runners (instances EC2 ou containers) permettant d’imposer un nettoyage automatique des données d’un projet après chaque exécution par la pipeline.

Optimiser les contrôles de conformité

A chaque entreprise son socle de règles de sécurité et donc ses campagnes de vérification de la conformité. Historiquement, une équipe restreinte (les ops) s’occupait de fournir le matériel et les applicatifs au métier et cette équipe était garante de la bonne conformité de ce qu’elle livrait. Le cloud public et le DevOps rendent cette approche caduque car les métiers ont maintenant la possibilité d’avoir directement accès aux services cloud. Comment alors s’assurer du respect des règles de l’entreprise ?

Certaines entreprises tentent de résoudre le problème via l’utilisation des policies IAM : elles construisent des politiques extrêmement complexes pour tenter d’empêcher a priori l’apparition d’une situation non désirée.
C’est une approche relativement limitative. Les politiques IAM ont un langage riche permettant d’exprimer des limitations très granulaires, mais restent complètement insuffisantes pour exprimer précisément une situation donnée à éviter. Les organisations allant dans cette voie se retrouvent donc forcée d’imposer des interdictions beaucoup plus larges que nécessaires, ce qui entraîne une perte importante de souplesse alors même que c’est une des toutes premières raisons d’aller vers le Cloud. Un autre problème de taille de cette approche est la frustration engendrée auprès des Métiers : lorsqu’un utilisateur obtient un “Access Denied” lors de la création d’une instance EC2, la console ne lui explique pas la raison (Oubli d’un tag ? Utilisation de la mauvaise version d’AMI ? Erreur dans la configuration du Security Group ?). Il est donc probable que cela engendre énervement, frustration, appels au support de l’entreprise et finalement desserve l’image de la fonction sécurité, vue comme un acteur bloquant plutôt qu’un support à l’organisation.

Une approche plus raisonnable est celle de la mise en place d’un système de gestion de la conformité qui va empêcher a posteriori la persistance d’une situation non désirée. La limite de cette approche est que le système de conformité n’est pas applicable pour tout : il ne peut par exemple pas empêcher un utilisateur A d’agir sur les ressources d’un utilisateur B (dans ce cas la meilleure approche est d’avoir des comptes AWS séparés). En revanche, il permet de couvrir l’essentiel, à savoir les cas d’usage relatifs aux risques identifiés en amont par les organisations. Ce système peut être arbitrairement souple, granulaire et flexible : si les produits comme AWS Config ou Cloud Custodian se révèlent trop limités pour couvrir un besoin spécifique, il est toujours possible d’écrire des lambdas ! De fait on peut interdire ou corriger précisément les situations cibles. Par ailleurs, il est possible de configurer le système de surveillance de la conformité pour envoyer un mail d’explication à chaque utilisateur qui verra son instance EC2 fraîchement créée être terminée. Cet élément pédagogique limitera l‘incompréhension, et donc la frustration, et permettra de guider pas à pas l’utilisateur vers une mise en oeuvre des meilleures pratiques sécurité.

Pour conclure

Un environnement cloud public tel qu’AWS permet de déployer un ensemble de services natifs de sécurité opérationnelle et de bénéficier d’une intégration très simplifiée par rapport à l’univers on-premise, c’est en cela une avancé importante.

Pour en tirer tous les bénéfices, il est primordial non seulement de s’informer le plus tôt possible des avantages et limites de chaque service et les mettre en rapport avec votre propre stratégie sécurité (objectifs, politique, règles opérationnelles…) mais aussi d’éviter de calquer les modèles de sécurité on-premise. La mise en oeuvre de contrôles automatiques validera la bonne utilisation de ces services et pourra avoir un rôle pédagogique auprès des équipes. La sécurisation des plateformes cloud doit être menée de concert avec celle des chaînes CI/CD, qui deviennent encore plus sensibles.

Dernière question : peut on complètement se passer des solutions éditeurs grâce aux services de sécurité natifs des PF cloud? La question mérite d’être soulevée car AWS innove en permanence (cf notre article Re:invent, la sécurité un pas plus loin) et sa politique tarifaire peut sembler plus attractive. La voie du salut pour les éditeurs sécurité repose sur leur capacité à rester à la pointe de la technologie, à apporter une simplicité d’utilisation et d’intégration, et surtout la capacité à gérer les environnements hybrides et multi cloud.