D’un monde fermé et quelque peu élitiste, l’univers de la cybersécurité s’est aujourd’hui largement étendu, et plus aucun CIO ou CEO ne peut ignorer sa criticité. Être victime d’une cyberattaque qui empêcherait tout fonctionnement opérationnel de la société et l’exposerait en Une des médias à la moindre perte de données n’est plus envisageable pour les Directions Générales. La sécurité des données est donc devenue la priorité n°1.
Du point de vue de la donnée, les avantages intrinsèques du Cloud sont d’apporter la simplicité et la flexibilité nécessaires pour que les données de l’entreprise puissent être partagées avec l’extérieur de façon simple et surtout rapide. La difficulté ici est que cela n’enlève en rien toutes les mesures relatives à la sécurité qui doivent être prises par les DSIs. Elles devraient même être en augmentation du fait du nouveau contexte sanitaire mondial.
Sécuriser un SI rapidement évolutif
Lorsqu’il fallait 2 mois pour provisionner une machine, cela donnait plus de temps pour prendre en compte l’arrivée de ladite machine et la sécuriser. Aujourd’hui, quand un développeur a besoin d’une vingtaine de systèmes pour un test, voire de plusieurs milliers, il lui suffit de cliquer sur un bouton. Et ce sont autant de nouveaux environnements qui viennent d’apparaître, tous à sécuriser en appliquant la politique de sécurité en cours. La difficulté est donc d’avoir les moyens d’appliquer les mesures de sécurité adéquates, de manière opérationnelle avec tout l’audit nécessaire, et avec la même rapidité. Le risque ici est grand : une mauvaise configuration des services Cloud expose l’entreprise à des vols de données, à la mise à disposition publique de données de façon accidentelle, à être victime de hack simple du fait d’un niveau de sécurité insuffisant …
Une responsabilité partagée entre Entreprise et Fournisseur de Services Cloud
Mais attention, cette flexibilité et cette agilité obtenues grâce au Cloud n’annulent en rien la responsabilité en termes de sécurité d’entreprise. Le modèle de la responsabilité partagée autour de la sécurité du Cloud reste d’actualité. Un fournisseur de services, que ce soit des solutions type Infrastructure-as-a-Service (IaaS), Plateforme-as-a-Service (PaaS) ou Applicatives (SaaS), partage dans tous ces cas avec l’entreprise la responsabilité de la sécurité du SI éclaté.
En effet, lorsqu’une société souscrit à un service, elle reste toujours responsable de la sécurité dudit service, même si c’est dans une moindre mesure. Si elle s’abonne à une offre SaaS, il lui restera certainement beaucoup moins de responsabilité en termes de sécurité que si elle souscrit à une offre IaaS pour installer elle-même ses systèmes d’exploitation et sera donc responsable de les mettre à jour avec les patchs de sécurité des éditeurs. Mais dans tous les cas, la gestion des identités et des accès des utilisateurs (IAM) restera à la charge de la DSI, ainsi que la décision du type et de la criticité des données qui pourront être utilisées dans un service Cloud.
Mauvaise configuration = Trou de sécurité
Si l’on considère l’ensemble des cas de pertes de données répertoriées et souvent médiatisées, aucune entreprise concernée ne s’est retournée contre les fournisseurs de services Cloud majeurs étant donné que l’origine du problème provient, dans la majorité des cas, d’une mauvaise configuration côté client. A tel point que le Gartner Group prédit que d’ici 2025 99% des problèmes de sécurité dans le Cloud seront dus aux clients principalement du fait d’une mauvaise configuration des services.
Il est fondamental qu’une entreprise soit consciente de sa posture de sécurité dans le Cloud. Un point suffisamment important pour voir l’apparition d’un nouvel outil (sorte d’évolution d’un CASB, Cloud Access Security Broker), le CSPM pour Cloud Security Posture Management. Il permet de vérifier, en prenant en compte l’évolution des menaces cyber, que l’environnement cible ne souffre pas d’options de configuration qui le mettrait à risque.
Configurer un service : Des centaines d’options à vérifier
Aujourd’hui, une entreprise standard dispose de nombreux service dans le Cloud, comme la messagerie, des outils de collaboration et stockage de documents, également des applications métiers (RH, ERP, HCM etc.) et la plupart du temps un système IaaS ... Une flopée de services généralement souscrits chez différents prestataires et qui, pour chacun, nécessite une gestion propre des utilisateurs, des droits d’accès et de toutes les options de sécurité. Soit, en additionnant toutes les instances de chaque service, des centaines d’options qui déterminent si une donnée est publique ou non, qui indiquent comment réaliser le partage de données, comment gérer le chiffrement et sa clé, le DLP etc. Elles permettent de s’assurer que le service Cloud considéré est dans une posture de sécurité correcte avant même de l’utiliser.
Multiplicité de services difficile à sécuriser
A quand remonte la dernière fois où vous avez vérifié si les options de configuration ayant trait à la sécurité de tous les « tenants » (services) de vos fournisseurs de services Cloud étaient positionnés à une valeur optimale, ou tout du moins, sont restés à la valeur que vous aviez choisi au début du projet ? La réponse à cette question débute toujours par un petit moment de silence côté DSI.
Si l’on considère les petites structures, il reste compliqué pour ces dernières d’avoir une personne en interne qui ait la capacité, la connaissance et le temps pour réaliser ces vérifications. Quant aux grandes entreprises, elles buteront également sur le sujet même si c’est pour différentes raisons. En définitive, quelle que soit leur taille, toutes les sociétés sont confrontées au problème de cette multiplicité soudaine de services. Même si la sécurité est pratiquée depuis des décennies et que les préceptes pour sécuriser restent identiques dans le Cloud, on ne peut plus la mettre en place de la même manière en raison d’un facteur d’échelle. Provisionner en un claquement de doigt 1000 machines est possible grâce à des scripts mais les sécuriser aussi rapidement (appliquer des correctifs, réaliser des sauvegardes ...), c’est un peu plus compliqué.
Appliquer une Sécurité spécifique au Cloud
Même si une entreprise n’est plus entièrement responsable de la sécurité de son infrastructure dans le Cloud, elle doit prendre conscience qu’elle le reste encore pour certaines choses. Désormais il ne lui faut plus penser DevOps mais DevSecOps : automatiser, « scripter » et industrialiser la sécurité de ses applications, et non plus en faire une option. De la même manière, elle doit résoudre son problème de connaissance des spécificités du Cloud par rapport à la sécurité pour pouvoir protéger tout le SI. Également apprendre toutes les particularités des services qu’elle utilise dans le Cloud, qu’ils soient SaaS, PaaS ou IaaS. Elle doit tenir compte en permanence de la question d’échelle induite par le Cloud ainsi que de la question d’outils adaptés. Même si elle possède un SoC (Security Operation Center), et qu’elle utilise déjà un SIEM (Security Incident and Event Management), est-il réellement bien calibré et adapté pour alerter à bon escient des évènements en provenance des services Cloud qui pourraient générer un problème de sécurité ? Aujourd’hui, il existe des outils taillés pour le Cloud, adaptés pour supporter une problématique de volume comme pour tenir compte des spécificités d’un service.
Une entreprise met elle-même en place ses multiples services dans le Cloud et ce, malencontreusement souvent, sans réellement savoir comment tous ces services peuvent interagir ensemble. Dans ce cas, difficile pour elle d’obtenir des postures de sécurité satisfaisantes. C’est également à l’entreprise de veiller à ce que l’usage de ces services ne génère pas de nouveaux risques. Elle doit donc réaliser une surveillance permanente pour détecter toute utilisation suspecte.
Un Cloud public, Security Inside
C’est en tenant compte de ce contexte qu’Oracle a lancé la seconde génération de son Cloud public baptisé OCI, Oracle Cloud Infrastructure. A l’époque, le constat était que les entreprises conservaient leurs « workloads » critiques on premise du fait de l’image d’un Cloud public insuffisamment sécurisé. Mais aujourd’hui les choses ont évolué car il devient difficile pour une entreprise d’avoir les moyens matériel et humain de conserver en interne ces applications critiques de façon aussi sécurisée qu’un des grands acteurs du Cloud pourrait le faire pour ses clients.
Oracle vise à fournir un niveau de sécurité et de performance maximale avec OCI afin de permettre aux entreprises d’y déplacer leurs usages critiques. Son architecture a été pensée afin de pouvoir garantir des performances équivalentes ou supérieures à ce que l’on peut attendre d’une infrastructure On-Premise, sans les phénomènes de collisions classiquement liés aux IaaS de première génération.
Récemment, trois nouveaux services de sécurité ont été ajouté à l’offre OCI : « Maximum Security Zone », « Cloud Guard » et « Security Advisor ». Le premier crée une zone de sécurité maximum où des règles prédéfinies s’appliquent automatiquement afin de conserver une posture de sécurité maximale. Ce sont des compartiments mis constamment sous surveillance. C’est là que « Cloud Guard » entre en action en générant des alertes et des actions de remédiation de façon guidée ou automatique (enlever les IP publics, rendre privé un « bucket » public, etc). Il possède des détecteurs au niveau de la configuration des services mais aussi au niveau de l’activité : la façon dont est utilisée le service. « Cloud Guard » suit des protocoles comme on le ferait avec une recette de cuisine, et connaît tous les points sensibles à surveiller. Cette expertise embarquée dans OCI est précieuse et permet de fournir avec des tableaux de bord une visibilité réelle sur le niveau de sécurité du service. « Security Advisor » enfin permet, lors de la mise en place d’un nouveau service, d’alerter l’utilisateur si un niveau de sécurité plus avancée que ce qu’il avait prévu est disponible. « Security Advisor » guide pas à pas le responsable de projet pour sécuriser au mieux un environnement. Par ailleurs, OCI dispose du système d’exploitation autonome « Autonomous Linux » et de la base de donnée autonome « Autonomous DB », qui se mettent à jour automatiquement avec les derniers correctifs de sécurité, sans interrompre les services, adressant ainsi un autre grand casse-tête du monde de la sécurité, la gestion des correctifs.
La prise en compte de tous ces éléments permettra aux entreprises de bénéficier d’une protection optimale de leurs données dans le Cloud, renforcée par l’expertise et les moyens de protection de leurs fournisseurs de services Cloud.
Par Damien Rilliard, EMEA Cloud Security and Systems Management Business Development Manager Oracle
