Après de longues négociations, tant avec l’exécutif qu’avec la sécurité, ça y est, le projet cloud démarre ! La landing zone est enfin en place. Elle définit les rôles principaux et la politique de journalisation tout en hébergeant les services partagés. Les équipes de développement brûlent d’inaugurer leur nouveau produit digital.

De belles promesses ont été faites à la sécurité ! Pas de fuite de données, pas de porte restée grande ouverte : le service en charge du cloud est constitué de professionnels responsables.

Quelques règles basiques ont été définies, collectées et publiées dans l’Intranet… au fin fond d’une sous-section du service chargé de la Gestion des Risques et de la conformité.

Cela est-il suffisant ? Non, l’adoption de la plateforme cloud et, ensuite, son passage à l’échelle, nécessitent un certain nombre d’étapes complémentaires.

Appliquer une politique de conformité pertinente

Dans un premier temps, il s’agit de définir ce qui doit être contrôlé.

En premier lieu, bien sûr, les aspects liés à la sécurité : les permissions définies sont-elles suffisamment restreintes ? Existe-t-il des espaces de stockage ouverts au public, sans contrôle ? Quelles sont les règles firewall régissant l’accès au réseau privé chez le fournisseur cloud ? Les journaux sont-ils bien remontés dans l’agrégateur de la landing zone ? Les bonnes pratiques, par exemple de mise à niveau des systèmes et de respect des coûts, ne doivent pas être négligées pour autant.

De manière peut-être contre-intuitive, l’ensemble de ces règles offre davantage de liberté aux équipes de développement. Et oui ! Auparavant, lorsqu’une équipe de développement avait besoin de déployer son application, elle ouvrait un ticket auprès de l’équipe d’infrastructure, qui provisionnait un serveur, selon ses propres règles de conformité, et selon son agenda.

Reproduire ce mode de fonctionnement dans le cloud serait une hérésie : autant laisser les équipes de développement le plus autonome possible et utiliser au maximum les capacités des fournisseurs cloud. You build it, you run it ! Leurs règles ont l’avantage d’offrir des fondations saines et responsabilisantes, plutôt que de dessiner un environnement figé à la façon d’une forteresse.

L’absence de règles et de contrôle, d’un autre côté, risquerait fort de mener à l’édification d’une infrastructure cloud bancale. Une fois le mal fait, le temps que les règles arrivent et soient respectées, mettre en conformité une telle infrastructure deviendrait une entreprise considérable. Tout comme changer les fondations d’un édifice, changer le fonctionnement d’une couche d’infrastructure n’est pas chose aisée.

Une fois les règles pertinentes définies, reste à vérifier qu’elles sont bien respectées.

Mettre en place la détection

Les principaux fournisseurs cloud offrent un service de mise en place de contrôles de conformité: AWS Config, Azure Policy, GCP Policy Intelligence. L’avantage de ces services maison : facilité de mise en œuvre et agrégation des résultats. Des règles standard sont proposées et l’état de conformité est présenté dans un tableau de bord. Vous pouvez ajouter vos propres règles, mais celles-ci resteront dépendantes des évènements de conformité remontés par votre fournisseur cloud.

Pour une détection plus fine, il est possible de s’appuyer sur les services d’audit : AWS Cloudtrail, Azure Monitor, GCP Cloud Audit Logs. Sur un événement de création ou modification d’une ressource, il est possible de déterminer si cette ressource est conforme ou non. Dans le cas où le fournisseur n’offre pas de remontée d’évènement, il est possible de planifier des tâches récurrentes de détection.

Le risque posé par une ressource non conforme déterminera quel mode de détection privilégier. Par exemple, la création d’une ressource pouvant permettre l’exfiltration de données doit être détectée immédiatement. Un port ouvert ou une ressource non mise à jour, peuvent, quant à eux, être repérés grâce à une tâche planifiée chaque nuit.

Répondre aux ressources non conformes

Une fois la ressource non conforme détectée, il faut agir et corriger/détruire la ressource. Ou pas... Certaines requièrent des accès particuliers et peuvent donc être non conformes by design. Une liste d’exception est alors établie pour les identifier et ne pas lever d’alertes les concernant.

Pour les autres ressources, cette remédiation doit être automatisée pour limiter les risques, d’autant plus si elles sont critiques pour la sécurité. Des outils tiers peuvent aider à la mise en place de ces mécanismes.

Pour la remédiation manuelle, l’enjeu est organisationnel. Elle se base sur un processus établi en amont, compris et accepté par des équipes faisant partie de services distincts. En effet, de qui la correction relève-t-elle ? Du développeur qui a provisionné la ressource en question ou du service en charge de la plateforme cloud ? Autant de questions auxquelles il faudra répondre.

Une fois les responsabilités déterminées, il s’agit de prendre en compte les horaires et niveaux de service attendus. Est-ce que l’on souhaite envoyer une alerte en pleine nuit à la personne d’astreinte pour une réaction rapide ? Ou la non-conformité peut-elle attendre le lendemain matin ?

Aussi, router les alertes aux bonnes personnes et permettre leur traçabilité est un enjeu majeur : plus la plateforme est vaste, plus il devient nécessaire d’identifier immédiatement qui est responsable de quelle ressource. Enfin, tracer les occurrences des ressources non conformes permet d’identifier les raisons de leur création : erreur honnête ou tentative d’accès malveillant ?

Pour conclure

La gestion de la conformité est donc mise en place pas à pas, dans le contexte de l’entreprise :

• Identifier les ressources cloud et comment les utiliser
• Définir le périmètre de responsabilité de chaque équipe
• Etablir les règles et bonnes pratiques à respecter, le mode de remédiation et le degré d’urgence des tâches de remédiation manuelles
• Implémenter la solution de détection et de remédiation
• Mettre en place les règles d’assignation

Sur les 5 points ci-dessus, seule la solution de détection et de remédiation est adressée par une solution technique, les autres relèvent de la gouvernance et de l’organisation. Des règles trop rigides freinent l’autonomie ; des règles trop lâches mènent au chaos. Pour faciliter l’adoption, définir le chemin à parcourir avec l’ensemble des acteurs - développeurs, infrastructure, sécurité - une piste est de commencer petit, avec les règles indispensables, sans forcément toutes les automatiser. Ici, la communication entre les équipes techniques et les décideurs constitue la clé du succès. Les premiers fourniront le savoir-faire, et les seconds agiront en tant que facilitateurs transverses.