Afin de se prémunir des risques, les DSI sont tenues de suivre des ensembles de bonnes pratiques, les référentiels, internes ou externes. La conformité consiste à s’assurer du respect de ces règles. Dans cet article, nous aborderons principaux challenges d’une politique de conformité sur le Cloud: le choix des référentiels, leur valeur, et les règles de remédiation à adopter.

Le principe de la conformité est d’évaluer si un composant cible est configuré en accord avec les règles définies par un référentiel, interne ou externe, et, en cas d’écart, de déterminer le pourcentage de déviance . 

Parmi les référentiels externes, certains peuvent être obligatoires, comme le RGPD, la directive européenne NIS, ou la LPM. D’autres référentiels sont reconnus comme étant de bonnes pratiques; ici afin de minimiser les risques, et en fonction de son environnement et de ses contraintes, l’entreprise choisira de suivre ces recommandations ou non. Enfin, certains sont attachés à une certification, comme par exemple la norme ISO 27 001 : pour maintenir son niveau de certification, l’entreprise devra là aussi se conformer aux règles propres à cette norme.

Les référentiels internes suivent le même principe (ex. : politique de sécurité, d’achat, code d’éthique…) : il s’agit de l’ensemble de règles dont l’entreprise s’est dotée, afin de se prémunir notamment de risques opérationnels, légaux  ou d’un dysfonctionnement des opérations. 

Dans les deux cas, que le référentiel soit externe ou interne, le travail de la conformité est de s’assurer du bon respect de ces règles. La première étape du travail de conformité est donc d’identifier les référentiels externes ou internes auxquels elle est soumise.

Le challenge de la mise en place de la conformité

Au-delà de la question de la charge posée par les contrôles de conformité – cela suppose d’avoir des personnes dédiées, qui comprennent les référentiels et déclinent des contrôles adaptés – la mise en place d’un dispositif de conformité amène souvent à se questionner en amont ou a posteriori sur deux sujets : quelle est la valeur du référentiel choisi, et quelles règles de remédiation adopter?

La remédiation

Le premier enjeu est la remédiation : quelles actions prendre si le contrôle est défaillant ? Faut-il immédiatement bloquer l’action incriminée ? Comment communiquer pour s’assurer que les situations déviantes ne soient pas reproduites ?

Pour que la remédiation soit efficace, il faut comprendre ce qui s’est passé pour s’assurer que cela ne se reproduise pas. Si le comportement d’un utilisateur est défaillant , il faut le sensibiliser. Si une règle cible est mauvaise, il faut la changer.

La valeur des règles

Le second enjeu est donc celui de la légitimité de la règle. S’il n’est pas possible de challenger le RGPD ou toute autre référentiel légal, le dispositif de contrôle peut permettre de discuter les règles non obligatoires : pourquoi ce référentiel, quelle est la valeur de la règle choisie ? Si une règle est sans cesse contournée ça peut être parce que l’organisation n’est pas assez mature ou outillée pour se mettre en conformité; mais ça peut être aussi parce que la règle est elle-même contre-productive.

Il faut garder à l’esprit que l’objectif d’un dispositif de conformité n’est pas tant d’appliquer un contrôle, mais d’aider à améliorer le fonctionnement et la protection de l’organisation. Le contrôle est un moyen et non une finalité, et faire des contrôles basés sur un référentiel inadapté, qui empêche les équipes de travailler, ne garantit pas de se prémunir des menaces. L’intelligence est portée par la règle (ou par la remédiation si la règle est mauvaise), pas par le contrôle. D’où la nécessité d’établir un référentiel permettant d’adresser des risques et des problèmes qui sont bien réels, de façon à ensuite faire des contrôles utiles. Dans le cas contraire, l’utilisateur blâmera les contrôles et les comportements n’évolueront pas.

S’adapter aux nouveaux cycles de développement

Suite à l’arrivée des cycles de développement itératifs, il n’est aujourd’hui plus possible de positionner des jalons de contrôle sécurité de la même manière qu’auparavant. Nous sommes désormais dans une logique où développement et mises en production se font en parallèle après l’étape du most viable product (MVP).

Dans ce contexte il est difficile d’anticiper les besoins des développeurs, et a fortiori de contrôler la mise en oeuvre de ce besoin : par exemple, il est plus difficile d’anticiper de façon exhaustive les accès et autorisations qui seront nécessaires pour permettre les développements futurs, ou les services à activer. Par ailleurs, il est nécessaire de ne pas bloquer l’agilité amenée par le Cloud avec des règles de sécurité trop contraignantes. Des erreurs étant toujours possibles, comment rester agile tout en maintenant un niveau de sécurité acceptable ? 

Le rôle de l’automatisation

L’automatisation permet de réaliser les contrôles de façon différente. Plutôt que de maximiser les interdictions et de contrôler de façon intermittente, on laisse plus de libertés aux utilisateurs mais en échange on définit des contrôles qui se déroulent en continu. De cette façon, on s’assure de limiter la période d’exposition à un risque potentiel. 

De plus, l’automatisation assure aussi la reproductibilité des contrôles : on est sûr de contrôler toujours la même chose, et de la même façon.

Côté remédiation, l’intégration des principes d’automatisation est un peu plus délicate. On risquerait de réagir à des faux positifs et de couper des flux, services ou accès nécessaires au métier. Mais on peut, et on doit, automatiser l’alerting, qui sera suivi de vérifications manuelles. 

Alerter sur certaines actions présente également une valeur pédagogique. Par exemple, un développement “non conforme” sera accepté en environnement de staging, avec un rappel sur ce qui n’est pas conforme, cela laisse le temps au développeur de comprendre et corriger les erreurs sans bloquer le cycle projet. En complément, on peut indiquer que, dans une logique donnant/donnant, on demande la mise en oeuvre de correctifs sans toutefois bloquer le projet, mais que si ces corrections ne sont pas faites à temps, le passage en production, lui, sera interdit. 

Ce qu’il faut retenir : en matière de conformité, il n’y a pas de règle absolue. L’objectif est de s’assurer que les modes de fonctionnement de l’organisation ne la mettent pas en danger. Il faut donc mettre de l’intelligence à la fois dans les règles, dans le dispositif de contrôles et dans dans les actions de remédiation.

Cas d’usage : conformité dans la chaîne CI/CD

Dans ce cas d’usage nous avons utilisé CFN, outil open source en Ruby, afin de vérifier la conformité des ressources à certaines règles internes avant déploiement dans le pipeline Code Commit : restriction des droits, accès aux services, ouverture des Security Group, ou des règles liées au policy, à SNS, SQS, IAM, EC2. 

A titre d’exemples des contrôles réalisés :

• Vérifier que les ressources auditées sont bien tagguées (le tagging est important car il permet notamment de ventiler les coûts des ressources engagées).
• Vérifier qu’il n’y a pas de déploiement sur des services non maîtrisés.
• Contrôler les règles SSH et RDP dans les Security Groups dans les espaces publics, de façon à empêcher les connexions externes via ces services.
• Vérifier que les mots de passe sont stockés dans SSM ou Secret Manager plutôt qu’en clair dans le code (ici on contrôle le type d’insertion du password).

Quand ces règles sont respectées, on peut déployer le code et les ressources sont créées. Dans le cas contraire, le pipeline est stoppé. 

Cas d’usage : Cloud Custodian pour le contrôle des ressources déjà déployées

Pour tester la conformité des ressources déployées, nous avons utilisé Cloud Custodian. En cas de non conformité, la remédiation est déclenchée par Stepfunction, qui créé un ticket Service Now pour identifier le problème de conformité. La machine EC2 concernée est ensuite capturée et sauvegardée par Guard Duty, puis détruite et recréée dans un compte isolé, à des fins d’analyse . Enfin, quand la remédiation a réussie, une notification est émise sur Service Now à partir de l’API Gateway, puis le ticket est clôturé.