Cours Concepts du cloud — modèles de service, responsabilité partagée, coûts, réseau, stockage et souveraineté

Objectifs d'apprentissage

À la fin de ce cours, l'apprenant peut :

1. définir le cloud selon le NIST et situer IaaS, PaaS, SaaS, puis FaaS ;
2. expliquer régions, zones de disponibilité et ce que chacune protège (ou non) ;
3. dire, pour un service donné, qui du client ou du fournisseur est responsable de quoi ;
4. comparer les modèles de facturation et repérer les postes de coût cachés (sortie de données, adresses IP publiques) ;
5. appliquer les principes d'identité (moindre privilège, comptes d'accès temporaires) et de réseau virtuel ;
6. distinguer stockage objet, bloc et fichier ;
7. évaluer la réversibilité et le verrouillage fournisseur d'une solution ;
8. distinguer localisation, résidence et souveraineté des données.

Prérequis

• Notions de réseau IP (adresse, sous-réseau, pare-feu) et de système d'exploitation.
• Notions de virtualisation (machine virtuelle) ; le cours « VMware ESXi » aide mais n'est pas obligatoire.
• Aucun compte cloud n'est requis. Si Stéphane veut pratiquer plus tard : un compte jetable, des alertes de coût posées avant toute création de ressource (chapitre 5).

Parcours et chapitres

1. Définition du cloud (NIST SP 800-145)

Le NIST définit le cloud computing comme un modèle d'accès réseau à la demande à un réservoir partagé de ressources configurables (réseaux, serveurs, stockage, applications, services), qui peuvent être mises à disposition et libérées rapidement avec un effort de gestion ou une interaction avec le fournisseur minimaux.

Le document liste cinq caractéristiques essentielles :

Il décrit aussi trois modèles de service (SaaS, PaaS, IaaS) et quatre modèles de déploiement (public, privé, communautaire, hybride). La page web consultée ne donnait pas les définitions fines ; la liste ci-dessus vient d'un résumé du PDF et reste à reconfronter au texte intégral avant validation (les quatre modèles de déploiement ont même été restitués de façon approximative : non vérifié).

2. IaaS, PaaS, SaaS et FaaS

La page « Shared responsibility in the cloud » de Microsoft Learn range Azure Functions parmi les exemples de PaaS : FaaS est donc, dans cette documentation, une forme de PaaS (serverless). La frontière entre modèles n'est pas nette : beaucoup de solutions mélangent plusieurs modèles.

3. Régions, zones et responsabilité partagée

Régions et zones.

• Chez AWS, une région est un lieu physique dans le monde qui contient plusieurs zones de disponibilité ; une zone est faite d'un ou plusieurs centres de données distincts, avec alimentation, réseau et connectivité redondants, dans des bâtiments séparés (livre blanc « Overview of AWS », section « Global infrastructure »).
• Chez Azure, de nombreuses régions proposent des zones de disponibilité : groupes de centres de données séparés, chacun avec alimentation, refroidissement et réseau indépendants. Elles sont en général distantes de plusieurs kilomètres et dans un rayon d'environ 100 km. Certaines régions n'ont pas de zones.
• Une zone protège d'une panne locale. Elle ne protège pas d'une panne de région entière : pour cela, il faut une conception multi-région. La page Azure le dit explicitement.

Responsabilité partagée. Le fournisseur assure la sécurité du cloud (matériel, logiciel de base, réseau, bâtiments) ; le client assure la sécurité dans le cloud (données, accès, configuration, et selon le service système et applications) : formulation d'AWS. Microsoft donne une matrice par modèle :

Microsoft précise : quel que soit le modèle, vous restez responsable de vos données, de vos terminaux, de vos comptes et de la gestion des accès. AWS ajoute que plus le service est « géré » (S3 plutôt qu'une machine EC2), plus le fournisseur prend en charge, mais le client garde les données et le contrôle d'accès.

4. Modèles de facturation et maîtrise des coûts

Pour le calcul (machines virtuelles), AWS décrit les options d'achat suivantes (page « Amazon EC2 billing and purchasing options ») :

Azure propose des mécanismes équivalents (paiement à l'usage, réservations, plans d'économies, capacité excédentaire) ; leur description détaillée n'a pas été lue : non vérifié.

Postes de coût souvent oubliés (cités par les pages lues) :

• la sortie de données (egress) : Azure Storage facture tout transfert hors d'une région ;
• les adresses IPv4 publiques : AWS précise que des frais s'appliquent (avec une dotation gratuite limitée dans le cadre du Free Tier) ;
• certains composants réseau (passerelles NAT, journaux, analyse de trafic) ;
• les ressources oubliées (disques détachés, adresses réservées, copies) qui continuent d'être facturées.

Paliers gratuits. AWS décrit, à la date de consultation, un « Free account plan » (jusqu'à six mois ou jusqu'à épuisement des crédits) et un plan payant, avec des crédits à l'inscription. Ces conditions changent : à relire sur la page officielle, et à ne pas considérer comme acquises.

Maîtrise des coûts, par ordre de priorité :

1. poser budget et alerte avant de créer quoi que ce soit ;
2. étiqueter (tags) chaque ressource par projet et par responsable ;
3. suivre la facture chaque semaine au début ;
4. supprimer les ressources de test dès la fin de l'exercice ;
5. n'envisager un engagement (réservation, plan d'économies) qu'après avoir observé un usage stable.

5. Identité et accès (IAM de principe)

Quel que soit le fournisseur, les mêmes principes reviennent :

• Identité : qui est-ce (personne, application, machine) ?
• Authentification : prouver son identité (mot de passe, second facteur, clé de sécurité).
• Autorisation : ce que l'identité a le droit de faire, sur quelles ressources.
• Moindre privilège : n'accorder que les droits nécessaires à la tâche.
• Identifiants temporaires plutôt que clés permanentes : la documentation IAM d'AWS recommande l'accès fédéré et les rôles pour les humains et les applications, et de n'utiliser des clés d'accès longue durée que lorsque c'est inévitable.
• Compte racine : le compte créé à l'inscription a tous les pouvoirs ; AWS demande de le protéger comme une donnée personnelle sensible et d'exiger l'authentification multifacteur.

6. Réseau virtuel

Un réseau virtuel est un réseau logique isolé dans le cloud, qui ressemble à un réseau d'entreprise :

• un espace d'adresses privé découpé en sous-réseaux ;
• des tables de routage qui disent où va le trafic ;
• des filtres (groupes de sécurité, listes de contrôle) qui autorisent ou refusent des flux ;
• des passerelles vers Internet ou vers le site de l'entreprise (VPN, liaison dédiée) ;
• des points de terminaison privés pour joindre un service du fournisseur sans passer par Internet.

AWS appelle cela VPC (un sous-réseau reste dans une zone de disponibilité) ; Azure l'appelle réseau virtuel (VNet) (réseaux et sous-réseaux couvrent toutes les zones d'une région). Le service de réseau virtuel est gratuit chez les deux ; ce sont certains composants (passerelle NAT, IPv4 publique, VPN) qui sont facturés.

7. Stockage objet, bloc et fichier

Deux faits lus dans la documentation : un compartiment S3 et ses objets sont privés par défaut, et AWS recommande de laisser activé le blocage de l'accès public ; un compte de stockage Azure regroupe blobs, fichiers, files et tables, et ses données sont chiffrées côté service par défaut.

La notion de stockage bloc côté baie est traitée dans le cours « NetApp stockage bloc » ; la notion d'hôte et de datastore dans « VMware ESXi ».

8. Réversibilité, verrouillage fournisseur et souveraineté

Analyse de l'auteur de ce cours, non issue d'une source officielle : à discuter avec Stéphane.

Réversibilité : pouvoir sortir (récupérer ses données et reconstruire ailleurs) dans un délai et à un coût connus. Questions à poser avant de s'engager :

• Dans quel format et par quel outil exporter les données ? Quel est le coût de la sortie (egress) ?
• Les configurations sont-elles décrites en code (modèles déclaratifs, Terraform, Bicep) ou faites à la main ?
• Quelles fonctions sont propres au fournisseur (bases, files, identités) et quel est leur équivalent ailleurs ?

Verrouillage (lock-in) : plus on utilise de services gérés et propriétaires, plus la sortie est coûteuse. C'est un compromis et non une faute : un service géré fait gagner du temps. Le risque se décide, il ne s'ignore pas.

Souveraineté, résidence, localisation : trois notions à ne pas confondre.

Une donnée localisée en France peut malgré tout relever d'un droit étranger si le fournisseur y est soumis : cette question est juridique, hors du périmètre de ce cours et non vérifiée ici.

9. Cycle de vérification

À chaque relecture : rouvrir les pages listées en sources, noter la date, vérifier les noms d'offres et de plans gratuits, relire les conditions de facturation, et laisser le statut « brouillon » jusqu'à validation de Stéphane.

Exercices et vérifications de fin de cours

Tous sont sur papier ou en lecture seule ; aucun compte n'est nécessaire.

1. Définition. Réécrire en dix lignes les cinq caractéristiques du NIST avec un exemple concret pour chacune.
2. Classement. Pour cinq services imaginaires, indiquer IaaS, PaaS, SaaS ou FaaS et justifier par la question du correctif système.
3. Responsabilité. Remplir une matrice client / fournisseur pour une machine virtuelle et pour un stockage objet.
4. Zones. Une application tourne dans une seule zone d'une région : décrire la panne qu'elle subit si la zone tombe, puis si la région tombe.
5. Coûts. Établir la liste des postes de facture d'un petit site hébergé, y compris les coûts cachés, et fixer un budget mensuel fictif avec deux seuils d'alerte.
6. Réversibilité. Écrire un plan de sortie en cinq étapes pour des données en stockage objet.
7. Souveraineté. Expliquer en trois phrases la différence entre localisation, résidence et souveraineté.

Critères de réussite

• Employer sans erreur IaaS, PaaS, SaaS, FaaS, région, zone.
• Dire ce que le client ne délègue jamais (données, identités, accès).
• Savoir qu'un budget alerte mais n'arrête rien.
• Savoir qu'une clé d'accès ne se range ni dans un fichier, ni dans un dépôt, ni dans un prompt.
• Dire ce qui n'a pas été vérifié.