13 novembre 2019

6min

Qui a peur du grand méchant Cloud ? Partie 2

Le Cloud prend de jour en jour une place de plus en plus importante dans les entreprises. Il offre la promesse d’une plus grande agilité et d’un Time To Market sensiblement raccourci. Dans un monde de plus en plus concurrentiel ou le Time to Market est un facteur clé de succès, c’est principalement cette perspective qui motive les décideurs à aller vers le Cloud.

Cependant, pour tirer pleinement parti des bénéfices apportés par le Cloud et obtenir un réel gain en agilité, il est nécessaire de transformer les processus de gestion des infrastructures et l’organisation des projets.

En effet, ce ne sont pas les technologies mais les processus qui sont essentiellement responsables du manque d’agilité et notamment la séparation entre les équipes études en charge du développement des applications et les équipes production responsables de la fourniture et de la gestion des infrastructures.

Ainsi, pour rendre les projets plus agiles et raccourcir les cycles, il convient d’augmenter l’autonomie des équipes projets et leur permettre de créer et de gérer les infrastructures de leurs environnements (Développement, Intégration, Validation).

Pour une réelle agilité, les environnements projets doivent donc être gérés par les équipes de développement ce qui permet une réelle mise en œuvre d’une approche DevOps. On doit donc passer d’un mode « Request / Response » à un mode « Do it youself ».

De même, des environnements de prototypage ou éphémères peuvent être directement créés dans le cadre d’initiatives gérées au niveau des équipes métier (Campagne marketing, Maquettage …), favorisant ainsi l’innovation.

La répartition des responsabilités de la gestion des infrastructures sur l’ensemble des équipes de développement a des impacts forts sur la mise en œuvre de la sécurité. En effet, il devient nécessaire de cloisonner fortement les environnements de chacun des projets afin d’éviter qu’une équipe ne puisse impacter, par erreur ou volontairement, les ressources d’une autre équipe.

Concrètement, ce besoin de cloisonnement fort conduit à créer des comptes Cloud différents par environnement et par projet et notamment à séparer les comptes de production et de non-production, menant rapidement à la création de dizaines voire de centaines de comptes Cloud dans le cas de grandes organisations.

Dans la première partie de cet article j’évoquais le besoin de contrôle et de supervision des mesures de sécurité mises en œuvre dans les infrastructures Cloud afin de détecter et éliminer au plus tôt les non-conformités et de s’assurer que les règles de sécurité et de conformité sont respectées.

Le déploiement à grande échelle des environnements Cloud sur des centaines de comptes, rend nécessaire l’automatisation de ces contrôles et leur application en temps réel.

Pour ce faire, il convient de mettre en place une approche de Conformité Continue basée sur les principes suivants :

  • Mise en place des politiques de sécurité définissant pour chaque profil les actions autorisées : définition des autorisations pour chaque rôle (développeur, intégrateur, testeur, Data Scientist, administrateur, etc.) avec un principe de moindre privilège.
  • Déploiement de règles de contrôle activées en temps réel sur événement lors de la création, modification, suppression d’une ressource.
  • Analyse périodique des configurations afin de détecter les écarts par rapport aux règles définies.
  • Traçabilité : collecte et centralisation tous les logs générés par les appels d’API de la plateforme Cloud.

Lors de la détection d’une non-conformité une alerte de sécurité est levée et transmise aux équipes projets et aux référents sécurité. Deux cas peuvent se présenter : lorsque cela est possible, une remédiation automatique peut être appliquée afin de corriger immédiatement la non-conformité ; Dans le cas contraire, l’alerte de sécurité doit être traitée manuellement.

Cette approche de Conformité Continue a notamment été implémentée par la Société Générale. L’excellent article de Christophe Parisel compare les différentes stratégies d’implémentation possibles sur les plateformes AWS et Azure.

Les principales problématiques à adresser lors de la mise en œuvre des contrôles de sécurité sont :

  • La sécurité réseau
  • La gestion des identités et des accès
  • La protection des données
  • La prévention contre la fuite de données
  • La traçabilité et l’audit

Sécurité réseau :

La micro-segmentation des environnements engendre la création d’une multitude de bulles réseau et une réelle complexité dans la gestion des flux et du routage.

L’urbanisation de l’infrastructure réseau et notamment la prise en compte à grande échelle de la problématique du routage et de l’ouverture des flux entre les centaines de bulles réseau est un point très structurant devant être étudié très en amont lors du design global de la plateforme Cloud.

Gestion des identités et des accès :

La gestion des identités et des accès est également un élément crucial dans la mise en œuvre des règles et des politiques de sécurité. Il est important de centraliser l’ensemble des identités au sein d’un seul et même compte ou annuaire et d’affecter à chaque identité un ou plusieurs profils définissant les accès sur un ou plusieurs comptes Cloud.

Protection des données :

Les mécanismes de protection des données doivent être définis en fonction de la sensibilité de la donnée. Il est ainsi important de définir au préalable une classification des données et pour chaque donnée ou document d’identifier son niveau de confidentialité. En général, les classifications définissent trois ou quatre niveaux de confidentialité :

  • Niveau 1 – Données publiques : aucune mesure de protection particulière n’est nécessaire ;
  • Niveau 2 – Données internes : Ces données ne doivent être accessibles que par les personnes autorisées ;
  • Niveau 3 – Données sensibles : Ces données doivent faire l’objet de mesures de protection renforcées. Elles sont en général chiffrées et leur accès est systématiquement tracé ;
  • Niveau 4 – Données secrète : Ces données sont systématiquement chiffrées et accessibles uniquement que par un nombre très restreint de personnes internes à l’entreprise. Elles sont en général stockées dans des zones séparées dont l’accès est tracé et protégé par des mesures de sécurité renforcées.

Prévention contre la fuite de données (DLP) :

La prévention contre la fuite de données s’appuie en général sur des mécanismes empêchant la sortie des données de leur contexte d’exécution et notamment le blocage des canaux permettant la sortie de ces données sur des réseaux publics ou externes à l’entreprise. Cela n’est cependant pas toujours possible, notamment lors de l’utilisation de services PaaS managés nécessitant des ouvertures de flux vers des points d’accès externes. Dans ce cas, il convient de tracer l’ensemble des flux sortant afin de détecter à posteriori les éventuelles fuites de données et de pouvoir identifier leur source.

Traçabilité et audit :

Les logs produits par la plateforme Cloud lors de la création, modification, suppression et l’accès aux ressources sur l’ensemble des comptes doivent être collectés et centralisés dans un stockage hébergé dans un compte Cloud dédié accessible uniquement en lecture depuis les autres comptes afin de garantir l’intégrité des logs. Ces logs peuvent ensuite être analysés afin de détecter certaines actions ou bien certains comportements non conformes aux règles de sécurité.

En conclusion, la sécurité est un élément clé dans la mise en œuvre des infrastructures Cloud et la micro-segmentation des comptes, nécessaire pour isoler les différents projets, rend obligatoire l’automatisation des règles de contrôle et des actions de remédiation lorsque cela est possible.

Eric Datei

Leader Senior IT Architect - Cloud