5 conseils pour sécuriser ses données critiques dans un cloud public
En ouvrant son système d'information sur le cloud public, une organisation augmente mécaniquement sa surface d'exposition aux risques de sécurité des données. Pour 68% des entreprises, les erreurs de configuration représentent la première menace pour les applications en mode cloud. Une configuration incorrecte peut en effet exposer un système à une attaque potentielle et à une fuite de données. Viennent ensuite les accès non-autorisés (58%), les interfaces non-sécurisées (52%) et les détournements de compte (50%). C'est ce qui ressort du rapport 2020 de Check Point sur la sécurité du cloud
1. Bien délimiter les responsabilités
Il convient tout d'abord de bien cerner quelle responsabilité incombe à l'entreprise utilisatrice, sachant que cette responsabilité est nettement plus élevée en mode IaaS (infrastructure as a service) qu'avec les approches PaaS (platform as a service) et, surtout, SaaS (software as a service). Sur sa page dédiée à la responsabilité partagée, Amazon Web Services (AWS) a le sens de la formule. Pour le numéro un du cloud public, le provider est responsable de "la sécurité du cloud", tandis que l'entreprise est responsable de "la sécurité dans le cloud". A la charge d'AWS de sécuriser les "couches basses", et à celle du client de protéger les données et charges de travail.
Conseiller en sécurité chez Sophos, John Shier compare le IaaS à la "la location d'un espace dans un bâtiment préfabriqué." Il rappelle que le fournisseur de cloud est responsable de l'alimentation et de la sécurité physique du datacenter, de la sécurisation du réseau (commutateurs, pare-feu…), des serveurs et des hyperviseurs. Le client doit, de son côté, assurer la sécurité de tout ce qui installé sur les machines virtuelles (données, applications, systèmes d'exploitation…) et de l'accès à ces dernières.
"Les comptes admin doivent être utilisés de façon parcimonieuse"
Une entreprise est par conséquent responsable d'une mauvaise configuration des serveurs virtuels. A sa charge par conséquent de bien paramétrer le firewall protégeant chaque instance et de cloisonner le réseau en créant autant de clouds privés virtuels (VPC) que nécessaire. Un provider émet des recommandations et des alertes mais le client reste libre de sa politique de sécurité.
Pour décharger les entreprises d'une partie de cet effort, les providers proposent des services managés, par exemple sur le front des bases de données ou des architectures Kubernetes. Les mises à jour, les configurations de sécurité et les sauvegardes sont alors assurées par les fournisseurs. C'est aussi l'assurance d'utiliser un protocole de communication SSL/TLS à l'état de l'art.
2. Limiter les accès au strict minimum
Si les données sont conservées en toute sécurité dans le cloud, l'entreprise doit surveiller qui y les consultent et les éditent. Un outil de gestion des identités et des accès (IAM) permet de configurer les contrôles d'accès en fonction des rôles définis, de l'emplacement de l'utilisateur voire du type de terminal connecté. Plutôt que de personnaliser l'accès pour chaque nouvel utilisateur. On ajoutera ce dernier à des groupes de salariés prédéfinis. Selon les rôles rattachés à ces groupes, seules les ressources associées lui seront ouvertes. L'authentification multiple (MFA) renforce, par ailleurs, les contrôles d'identification.
Pour Stephan Hadinger, directeur de la technologie d'AWS France, il convient de limiter la délivrance de ces accès au strict nécessaire. "Les comptes 'admin' doivent être utilisés de façon parcimonieuse", souligne-t-il. Il préconise aussi un double contrôle pour valider les opérations effectuées. En poussant le curseur encore plus loin, une entreprise peut décider, dans une approche tolérance zéro, de créer un sas d'étanchéité en limitant les interactions humaines. "Les correctifs et les mises à jour seront alors pilotés par des scripts automatisés", poursuit Stephan Hadinger. "Une entreprise peut également décider de redéployer une nouvelle version d'une application plutôt que de modifier la version en place."
Là encore, les providers mettent en avant leurs services dédiés. Cloud IAM de Google Cloud a recours au machine learning pour détecter automatiquement les autorisations d'accès trop permissives et les réajuster en fonction de profils d'utilisateurs similaires dans l'entreprise. IAM Access Analyzer d'AWS identifie les ressources accessibles en dehors d'un compte Amazon en déterminant les chemins d'accès possibles et en analysant les autorisations octroyées.
3. Assurer un chiffrement de bout en bout
Le chiffrement reste un moyen incontournable pour se protéger des fuites de données critiques ou encore d'attaques de type "man In the middle" (un cas où le canal de communication entre l'expéditeur et le destinataire est compromis). Le cryptage s'applique de la création de la donnée à son stockage en passant par son transit. Cette dernière étape a longtemps été considérée, à tort, comme sécurisée par défaut.
"Le chiffrement est devenu quasiment gratuit et il n'y a pas d'impact sur la performance"
Stephan Hadinger chez AWS France conseille de ne pas se poser la question et de tout chiffrer quelle que soit la sensibilité des données. "Cela peut faire peur, le chiffrement étant encore souvent perçu comme synonyme de surcoût et de perte de performances. La situation a changé. Le chiffrement est devenu quasiment gratuit et il n'y a pas d'impact sur la performance grâce aux accélérateurs de chiffrement installés dans les serveurs de dernière génération."
AWS gère le chiffrement automatique des données au repos, propose des services additionnels ou, à défaut, redirige vers des éditeurs tiers partenaires. Les données en transit sont, elles, échangés à travers des tunnels SSL/TLS ou via une connexion VPN de type IPsec.
Les fournisseurs peuvent aussi fournir des services de type BYOK (Bring your own key) ou BYOE (Bring your own encryptions) permettant aux entreprises de gérer elles-mêmes le chiffrement des données stockées dans le cloud. Des services qui ont pour noms Cloud Key Management chez Google ou Key Management Service chez AWS.
Un cran encore plus loin on trouve le HSM (Hardware security module), un module physique pour générer, stocker et protéger les clés cryptographiques. Le dispositif nécessitant des compétences ad hoc, des providers proposent des HSM managés. C'est le cas de CloudHSM chez AWS ou d'Azure Key Vault Managed HSM chez Microsoft.
4. Détecter automatiquement les menaces
En matière de détection des menaces, John Shier estime qu'il faut apporter le même niveau de protection dans les environnements IaaS et que pour les systèmes hébergés en interne. A ses yeux, non seulement les logiciels malveillants ne font pas de différence entre une machine physique et une machine virtuelle, mais les cybercriminels exploitent le manque de visibilité des entreprises entre leurs différents environnements cloud. "Nous avons constaté une augmentation des activités ciblant les déploiements cloud pendant la pandémie", observe-t-il.
Tous les acteurs du cloud proposent des outils de détection automatique des menaces comme GuardDuty chez AWS, Advanced Threat Protection pour Microsoft Azure ou Security Command Center pour Google Cloud. Reposant sur des mécanismes de machine learning, ils identifient les attaques avancées ou détectent les comportements suspects comme tels un compte administrateur qui se connecte à 3h du matin depuis un pays étranger.
Côté client, une entreprise peut mettre en place un SIEM (pour security information and event management) dédiée à la gestion des informations et des événements de sécurité. Ce type de solution est proposée par Splunk, LogPoint, Securonix ou Alert Logic.
5. Sensibiliser les équipes IT aux bonnes pratiques
Comme dans toute politique de sécurité, l'homme reste le maillon faible et la menace peut venir de l'intérieur. Par négligence, méconnaissance voire malveillance, un collaborateur de la DSI peut ouvrir ou créer des failles de sécurité. Il convient de sensibiliser les équipes IT sur les enjeux de sécurité spécifiques aux technologies cloud avec un focus particulier pour la population des développeurs. Ces derniers vont être amenés à manipuler des éléments d'infrastructure sans avoir le vernis sécurité de leurs collègues de la production IT. Une démarche DevSecOps permet de les amener à réfléchir à cet enjeu dès la conception d'une application selon une logique de security by design.
"Les équipes informatiques disposent déjà de la connaissance, de la technologie et des politiques pour faire face aux menaces existantes", rappelle John Shier. "Elles peuvent facilement les adapter aux environnements cloud." Pour les aider dans cette voie, ils peuvent puiser dans le vaste fonds documentaire des fournisseurs. Google Cloud propose notamment des livres blancs, Microsoft Azure des bonnes pratiques, AWS des cours d'autoformation dédiés au sujet.