Par Jean-Jacques Quisquater, Gaël Hachez et Charles Cuvelliez (*) | Publié originellement le 11/01/2021, 11:08
Le Cybersecurity Act qui nous vient de la commission européenne (Regulation 2019/881) se propose, on le sait, d’uniformiser la certification des produits et services IT au niveau de toute l’Europe. C’est sur cette base que l’ENISA a mis à consultation, deux jours avant Noël, un projet de certification des fournisseurs de cloud. Il décrit à quelles contraintes un fournisseur de cloud doit se soumettre pour l’obtenir. Il y aura pour ceux-ci trois niveaux de certification possible : « basic », « substantial » ou « high », calqué sur le Cybersecurity Act lui-même.
Le fournisseur de cloud peut décider de se faire certifier auprès d’un organisme national accrédité ou se déclarer conforme. Dans sa proposition, l’ENISA fait la synthèse d’une série de normes déjà en vigueur dans différents pays comme SecNumCloud en France ou C5 en Allemagne pour les contrôles à mettre en place. Pour la certification il utilise un mélange de gouvernance de la sécurité informatique venant de la norme ISO 27001 avec un cadre de contrôle inspiré des standards internationaux d’audit (famille ISAE 3000) agnostique sur ce qui doit être contrôlé. C’est une approche qui brasse large pour obtenir l’adhésion des Etats membres qui auront tôt fait de prétendre que leurs normes nationales sont plus sûres et plus complètes que le plus petit commun dénominateur auquel l’Europe nous habitue.
L’ENISA a le chic dans sa proposition d’appuyer là où cela fait mal en mettant en évidence quand un risque « normal » acquiert une dimension inattendue chez un fournisseur de cloud qui ne gère pas que ses propres données mais celles de tant de clients.
Risques humains
Et de commencer par les risques liés au personnel qu’utilise le fournisseur de cloud. On n’a plus l’habitude mais voilà le grand retour des procédures disciplinaires. On ne rigole plus : la négligence ne fait pas que mettre en péril la société qui n’a pas bien recruté mais tous ses clients surtout ! Les fonctions doivent être classifiées selon leur degré d’accès aux données des clients ou si l’employé gère ne fût-ce que les capacités « cloud » attribuées aux clients.
La compétence et l’intégrité du personnel ne peuvent pas être laissées au hasard : elles doivent être vérifiées au moins une fois par an pour les fonctions les plus sensibles. En général, quand il a lieu, un tel contrôle se tient à l’engagement une fois pour toute. Même l’éventualité d’être sujet à du chantage (blackmailing) doit être scruté, une manière polie de dire qu’il faut vérifier les comportements privés à risque. Ce n’est pas gagné : les employeurs sont frileux sur ces vérifications, tétanisés par la protection de la vie privée.
Formation
Sensibiliser et former le personnel à la sécurité surtout pour les opérations délicates dans un cloud (comment mettre des équipements en production, comment gérer les données des clients, comment réagir en cas d’incident) sont d’autres recommandations fortes. Ces formations doivent être revues chaque année. Et il faut des tests, des exercices pratiques, des simulations. Bien sûr, la fin de contrat doit être scrupuleusement mise au point et suivie quand l’employé quitte la société. C’est un must mais attention à la mobilité interne où, dans une autre fonction, on garde tout de même les privilèges d’accès liés à l’ancienne fonction, ce qui donne une accumulation de droits risquée. Tous ces risques liés aux employés, reconnaissons-le, on les néglige parfois car on se fait confiance entre collègues, il y a le contrôle social mais un seul de ces risques qui se matérialise chez un fournisseur de cloud aurait un tel impact qu’on doit placer la barre bien plus haut.
L’inventaire du matériel
Autre point d’attention crucial : l’inventaire des équipements. Le périmètre d’un cloud est si flou par rapport aux murs d’un bon vieux centre de données (surtout si le cloud est dupliqué entre plusieurs localisations dans le monde avec des politiques de réplication variables entre clients) qu’on a intérêt à compenser tout cela par un inventaire précis des équipements du cloud qui contiennent les données des clients. Sait-on bien où se trouve vraiment, en dur, tout ce qui peut stocker des données clients, ou les transmettre ? Où sont les données clients quand il faut les détruire sans laisser aucune trace ? Décommissionner les appareils qui hébergeaient des données de clients, c’est critique. Mais les commissionner aussi, en fait ! Il est si facile de mal paramétrer les équipements qu’on met dans le cloud pour la première fois.
La gestion des capacités doit monter d’un cran en rigueur : si on peut supporter de son propre centre de données des lenteurs et des ruptures en capacité, un fournisseur de cloud ne peut se le permettre vu la responsabilité qui lui incombe. Il est un point de rupture systémique.
L’ENISA insiste aussi très fort sur les backups mais dans certains systèmes de clouds où les données sont distribuées dans plusieurs centres de données de manière automatique, les backups sont moins relevants.
Les connexions des clients à protéger aussi
Les données d’accès des clients au cloud – quand ils y ont accédé et comment – sont une donnée déjà précieuse en soi : ce n’est pas de ses propres données d’accès de ses employés dont on parle mais celles de toutes les sociétés qui sont clientes. Sont-elles aussi bien protégées, aussi bien que leurs données ? Sont-elles univoques en cas de litige ou de problème ? On mettra aussi des registres de vulnérabilités en ligne pour les clients qui gèrent eux-mêmes le cloud mis à disposition par le fournisseur, par exemple pour des raisons de sécurité. Car comment un client peut-il être au fait du détail des équipements techniques sous-jacents et des vulnérabilités à patcher ?
Chiffrement
Intéressant est aussi tout ce qui concerne le chiffrement : pour avoir la certification haute, le client du cloud ne devrait jamais partager la clé de chiffrement de ses données avec son fournisseur quitte à se priver de beaucoup de fonctionnalités « standards » de ce dernier. Les données de chaque client sont-elles bien séparées quand elles sont stockées mais aussi quand elles se déplacent dans le cloud ? Enfin, il y a intérêt à avoir une bonne cartographie du réseau avec cet objectif en tête.
Enfin viennent les demandes d’accès des gouvernements : l’ENISA recommande que chaque demande soit challengée, fasse l’objet d’une analyse juridique, que le client soit mis au courant de la demande et s’il faut obtempérer, de ne donner que le strict minimum au services gouvernementaux. Pas de béni oui oui donc, quel que soit le pays.
C’est étonnant que l’ENISA ne propose pas la publication de rapports de transparence auquel nous ont habitués les GAFAs : ils offrent au public toutes les statistiques de demandes d’accès des gouvernements aux données qu’ils hébergent, une pratique saine qui met la pression sur les pays.
Qui trop embrasse…
C’est beaucoup, et encore ce n’est que ce qui distingue les clouds d’un service ou produit IT standard en termes de certification. Le risque avec un tel pensum est que cette certification ne soit jamais appliquée car trop lourde, à force de ratisser large ou que seuls les plus gros soient à même d’obtenir la certification la plus haute. Ceci pourrait renforcer l’hégémonie des Google, Amazon et Microsoft.
Cela illustre le difficile équilibre à trouver entre créer une certification qui permet qu’une entreprise puisse utiliser des services d’un fournisseur cloud pour son informatique critique sans pour autant mettre une barrière à l’entrée trop importante pour des nouveaux acteurs. Une bonne approche serait de saucissonner l’atteinte de ces objectifs, avec, chaque année, un petit ensemble d’entre eux atteint, un peu plus l’année suivante mais en gagnant déjà une certification la première année. On voudra la garder et l’effort sera maintenu pour tout atteindre.
_______
Pour en savoir plus :
- EUCS – CLOUD SERVICES SCHEMEEUCS, a candidate cybersecurity certification scheme for cloud services, DECEMBER 2020
- Pour répondre à la consultation jusqu’au 7 février :
https://ec.europa.eu/eusurvey/runner/Public_Consultation_EUCS