Le modèle de sécurité cloud, généralement appelé modèle de responsabilité partagée, répartit les obligations en matière de sécurité entre le fournisseur cloud et le client. Le fournisseur sécurise les centres de données physiques, le matériel et la plateforme principale. Le client sécurise ses propres données, les accès des utilisateurs et la configuration des services qu'il utilise. Cette répartition varie selon que vous utilisez IaaS, PaaS ou SaaS.
Qui sécurise quoi dans le cloud ?
Le fournisseur est responsable de la sécurité du cloud, c'est-à-dire des bâtiments, du matériel, du réseau et de la couche de virtualisation. Vous êtes responsable de la sécurité dans le cloud, c'est-à-dire de ce que vous y exécutez et de la façon dont vous le configurez. Aucun modèle de service ne transfère au fournisseur la responsabilité de vos données ou de vos comptes utilisateurs.
Comment la répartition évolue-t-elle selon le type de service ?
Plus le fournisseur gère, moins vous avez à sécuriser vous-même.
| Couche | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physique et réseau | Prestataire | Prestataire | Prestataire |
| Système d'exploitation | Vous | Prestataire | Prestataire |
| Environnement d'exécution et application | Vous | Vous | Prestataire |
| Données et accès | Vous | Vous | Vous |
Votre part de responsabilité sur les données et les accès ne tombe jamais à zéro, c'est pourquoi l'identité et les permissions doivent être prises en compte dans chaque modèle.
Quelles sont les défaillances les plus fréquentes
La plupart des incidents proviennent de problèmes de configuration, et non d'attaques contre le fournisseur. Les buckets de stockage publics, les permissions trop larges, les clés d'accès inutilisées et l'absence de journalisation reviennent régulièrement. Les secrets présents dans les dépôts de code en sont une autre cause fréquente.
Quels contrôles chaque équipe devrait-elle mettre en place
Une liste courte couvre l'essentiel des risques.
- Authentification unique et authentification multifacteur pour tous les utilisateurs.
- Permissions selon le principe du moindre privilège, révisées selon un calendrier défini.
- Chiffrement des données au repos et en transit, avec des clés gérées.
- Journalisation centralisée et alertes en cas d'activité inhabituelle.
- Infrastructure définie en tant que code, afin que les paramètres soient examinés comme toute autre modification.
- Sauvegardes régulières avec une restauration testée.
Quel est le lien avec une migration
Une migration déplace des systèmes vers un modèle où ces responsabilités s'appliquent dès le premier jour. Planifiez la structure des comptes, les règles d'accès et la journalisation avant le déplacement de la première charge de travail, comme le décrit le guide sur la migration cloud. Le choix entre les différentes formes d'hébergement modifie également votre part de responsabilité, ce qui est abordé dans les avantages et inconvénients des formes d'hébergement web.
Par où commencer pour sécuriser un nouveau compte cloud
Commencez par la structure des comptes. Séparez la production des environnements de test, attribuez à chacun ses propres comptes ou projets et activez la journalisation avant tout démarrage. Créez des rôles pour les personnes et pour les services, et supprimez les clés d'accès à longue durée de vie partout où un rôle peut les remplacer.
Ajoutez ensuite des garde-fous applicables à l'ensemble du système, tels que le blocage par défaut du stockage public et l'exigence de chiffrement. Ces garde-fous empêchent qu'une erreur n'atteigne la production, ce qui est moins coûteux que de la détecter lors d'un audit ultérieur.
Comment savoir si cela fonctionne
Testez vos contrôles selon un calendrier établi. Essayez de restaurer une sauvegarde, vérifiez qui détient les droits d'administrateur, lancez une analyse des ressources publiques et entraînez-vous à suivre les étapes en cas d'identifiants compromis. Un contrôle qui n'a jamais été testé n'est qu'une hypothèse.
Rédigez un runbook court pour la première heure d'un incident, indiquant qui prend les décisions, quelles clés révoquer et où se trouvent les journaux.
Qu'est-ce que cela implique lorsque vous recrutez des ingénieurs
La sécurité dans le cloud nécessite des ingénieurs qui traitent la configuration comme du code et l'examinent avec soin. Miyagami place des ingénieurs seniors via les pages ingénieurs DevOps et ingénieurs AWS, à temps plein à partir de €5 600 par mois avec un engagement minimum de trois mois. Chaque ingénieur est évalué par un tech lead AI-native qui travaille avec l'IA au quotidien, comme expliqué sur notre processus de sélection. Nous sommes certifiés ISO 27001 et travaillons dans le respect du RGPD avec hébergement des données dans l'UE.
Réponses courtes
Qu'est-ce que le modèle de responsabilité partagée ?
Il s'agit de la répartition des responsabilités en matière de sécurité entre le fournisseur cloud et le client. Le fournisseur sécurise la plateforme et le client sécurise ce qu'il y déploie.
Qui est responsable des données dans le cloud ?
Le client, quel que soit le modèle de service. Le fournisseur ne gère pas qui, au sein de votre entreprise, peut accéder à vos données.
Quelles sont les causes les plus fréquentes des incidents de sécurité dans le cloud ?
Les erreurs de configuration et les contrôles d'accès insuffisants, comme les buckets de stockage publics et les permissions trop larges.
Le modèle varie-t-il selon le type de service ?
Oui. Vous portez la plus grande part de responsabilité avec l'IaaS et la moindre avec le SaaS.
