Leçon 15 : introduction à la sécurité du cloud — l'identité est le nouveau périmètre

Jusqu'ici, on a parlé de défense en termes de réseau physique : un périmètre, un intérieur, des serveurs dans une salle de serveurs. Cette leçon passe à un domaine où la plupart de ces hypothèses ne tiennent plus — le cloud computing. Le 'serveur' n'est plus le tien, il se trouve sur le matériel de

En bref : dans le cloud, il n'y a pas de mur physique sur lequel s'appuyer, donc la nouvelle frontière est l'identité — qui tu es, pas d'où tu t'es connecté. La responsabilité se partage : le fournisseur garde le matériel et la disponibilité, et toi tes configurations, tes identités et tes données — à chaque niveau IaaS/PaaS/SaaS. Et la plupart des intrusions dans le cloud ne sont pas un piratage sophistiqué, juste une porte laissée ouverte par erreur.

Le cloud computing et le modèle à la demande: Un modèle permettant un accès distant à des ressources informatiques (serveurs, stockage, bases de données, réseaux) via internet, à la demande (On-Demand) et payé à l'usage (Pay-as-you-go) — sans avoir à posséder ni entretenir de serveurs physiques sur le site de l'organisation.
L'ancienne approche contre la nouvelle : l'identité est le nouveau périmètre: Dans l'ancienne approche, la sécurité reposait sur l'emplacement physique — celui qui est à l'intérieur du pare-feu est considéré 'de confiance', celui qui est à l'extérieur est 'suspect' ; le problème : un attaquant qui a franchi le mur peut se déplacer librement à l'intérieur. Dans la nouvelle approche, alors que les employés utilisent le SaaS, travaillent depuis chez eux et que le serveur lui-même se trouve dans le cloud — le réseau n'est plus une frontière fiable. Ce qui reste constant, c'est 'qui' essaie d'accéder à l'information, donc la défense s'est déplacée vers la protection de l'identité.
Composants du nouveau périmètre : MFA, contexte et moindre privilège: Au lieu de demander 'de quel réseau viens-tu', le système pose des questions d'identité avant chaque action : une authentification forte (MFA — un mot de passe seul ne suffit pas), un accès basé sur le contexte (Context-Based Access — est-ce l'appareil connu, un pays plausible, une heure appropriée), et le principe du moindre privilège (Least Privilege) — même après authentification, on ne reçoit que l'accès nécessaire au travail.
Zero Trust (confiance zéro): L'hypothèse selon laquelle, même à l'intérieur du réseau de l'organisation, personne n'est fiable par défaut — chaque demande d'accès est revérifiée comme si elle venait de l'internet public, sans aucune 'zone de confiance' fixe bénéficiant d'une confiance automatique.
Le modèle de responsabilité partagée : Security OF contre Security IN the Cloud: La responsabilité dans le cloud se répartit par couches — ni le fournisseur n'est responsable de tout, ni le client n'est responsable de tout. Security OF the Cloud (responsabilité du fournisseur) : sécurité physique des centres de données, alimentation électrique et refroidissement, matériel, couche de virtualisation (Hypervisor), et disponibilité mondiale (Regions/Availability Zones). Security IN the Cloud (responsabilité du client) : gestion des identités et des permissions (IAM), protection des données et chiffrement, et configuration des services.
IaaS, PaaS et SaaS : le gradient de responsabilité: IaaS (par exemple EC2) : le fournisseur donne des serveurs, du stockage et un réseau ; le client gère le système d'exploitation, les services et les applications — responsabilité client très élevée. PaaS (par exemple RDS) : le fournisseur ajoute aussi le système d'exploitation et l'environnement d'exécution ; le client se concentre sur le code et la logique métier. SaaS (par exemple Gmail) : le fournisseur fournit une application complète ; le client ne fait qu'utiliser le service — mais reste responsable de la gestion des utilisateurs, du MFA et de la prévention des fuites de données.
Types de déploiement cloud : privé, public, hybride et multi-cloud: Cloud privé : infrastructure dédiée à une seule organisation — contrôle total, mais coûteux à mettre en place et à entretenir. Cloud public : infrastructures partagées entre organisations avec séparation logique, paiement à l'usage et élasticité (montée et descente en charge selon le besoin). Cloud hybride : combinaison des deux — les données sensibles restent sur site, les charges de travail flexibles passent au cloud public. Multi-cloud : utilisation de plusieurs fournisseurs de cloud public en parallèle, pour éviter la dépendance à un seul fournisseur (Vendor Lock-in), pour la sauvegarde et pour la réglementation.
Multi-tenancy contre Single-tenancy: Dans un cloud public (Multi-tenant), sur un même serveur physique peuvent tourner des serveurs virtuels de dizaines d'organisations différentes — une séparation logique existe, mais les ressources physiques sont partagées. Dans un cloud privé (Single-tenant), l'organisation 'locataire' est la seule sur le matériel.
Misconfiguration — menace numéro 1 du cloud: La plupart des incidents de sécurité dans le cloud ne sont pas une intrusion dans une technologie sophistiquée, mais une erreur humaine de configuration — par exemple, laisser un stockage S3 ouvert à l'accès public pour le monde entier — en raison d'un manque de sensibilisation ou d'une politique de sécurité peu claire.
Réseau, données et gouvernance dans le cloud : VPC, cycle de vie des données et souveraineté: Un VPC (Virtual Private Cloud) est un réseau privé et isolé à l'intérieur du cloud public, divisé en sous-réseaux (Subnets) publics (pour les services orientés internet) et privés (pour les bases de données sensibles). À l'intérieur, un NACL fonctionne au niveau réseau (Stateless — vérifié indépendamment de l'initiateur, déjà vu à la leçon 12), par opposition à un Security Group qui fonctionne au niveau du serveur (Stateful — vérifié selon qui a initié la connexion). Le cycle de vie des données exige une protection dans trois états : At Rest (sur disque — chiffrement), In Transit (sur le réseau — SSL/TLS), In Use (en mémoire pendant le traitement). Sans journaux (comme CloudTrail) documentant qui/quoi/quand/d'où, aucune investigation n'est possible. Et le choix de la Region détermine aussi la conformité réglementaire (comme le RGPD) et la souveraineté des données.