Fondamentaux cloud
5 pages
Réseaux virtuels, CDN, informatique en périphérie et multi-cloud : les bases sur lesquelles tout repose.
Cloud, plateformes & exploitation
Rubrique 04 sur 13
Le SI d'aujourd'hui : déclaratif, éphémère, et facturé à la seconde.
Rubrique · 26 pages · 6 sous-sections
Cloud, plateformes & exploitation
Conteneurs & orchestration
7 pages
Kubernetes, service mesh, fonctions serverless, montée en charge et déploiements progressifs, avec leurs contrôles.
- Docker ou Podman en auto-hébergement : root, rootless, isolation
- Conteneurs, Kubernetes, CNI et service mesh
- Réduire RBAC Kubernetes et bloquer les pods dangereux
- Sécuriser l’auto-scaling des instances éphémères
- Sécuriser les fonctions serverless FaaS
- Auditer la couverture réelle du mTLS service mesh
- Sécuriser le rollback blue-green et canary cloud
IAM & identifiants cloud
2 pages
Rôles et fédération des charges de travail : qui a le droit de faire quoi dans un compte.
Réseau & isolation
3 pages
Isolation entre clients, chiffrement des flux internes et terminaison TLS sur les répartiteurs de charge.
Données & calcul confidentiel
3 pages
Bases managées, données en mémoire et flux entre fournisseurs : où vivent vraiment les données.
Gouvernance & incidents cloud
6 pages
Inventaire IaC, responsabilité partagée, quotas, coûts et crises : tenir un environnement cloud dans la durée.
Par où commencer
- Fondamentaux cloud
Poser les bases du cloud
- IAM & identifiants cloud
Verrouiller qui fait quoi
- Conteneurs & orchestration
Encadrer Kubernetes et le serverless
- Gouvernance & incidents cloud
Tenir l’environnement dans la durée
Cloud, plateformes & exploitation
Section intitulée « Cloud, plateformes & exploitation »Le cloud a changé une chose fondamentale : l’infrastructure n’est plus un objet qu’on visite, c’est une déclaration qu’on soumet, et personne ne sait plus vraiment ce qui tourne tant que la facture ne le rappelle pas. Le modèle de responsabilité partagée promet une frontière nette entre ce que le fournisseur sécurise et ce qui reste à la charge du client ; en pratique, cette frontière est le premier endroit où les incidents se cachent, précisément parce que chacun pense que c’est à l’autre de vérifier.
→ Lire l’explication complète de la marmotte
L’IAM cloud pousse cette logique encore plus loin que l’IAM classique : des rôles qu’on assume en chaîne, des permissions accordées « pour aller vite » et jamais retirées, des comptes de service qui dorment avec des droits qu’ils n’utilisent plus. Chaque permission ajoutée est un pari sur le fait que personne ne l’exploitera avant qu’on pense à la retirer.
Les conteneurs et l’orchestration ajoutent leur propre terrain de jeu : RBAC Kubernetes mal calibré, admission control absent, un service mesh qui promet du mTLS partout et qui, en réalité, laisse passer ce qu’on n’a pas explicitement bloqué. Le serverless et l’infrastructure as code déplacent encore le problème sans le résoudre : un événement mal filtré devient un vecteur, une dérive de configuration silencieuse finit par ressembler à une politique qu’on n’a jamais écrite.
Ce qui reste, au bout du compte, c’est la question de la posture : ce qu’un outil de conformité voit vraiment, face à ce qui tourne réellement. L’inventaire déclaré et l’inventaire réel ne coïncident presque jamais, et c’est dans cet écart que vit la majorité des angles morts cloud.
🐝 Ce qui arrive si on s’en passe
Section intitulée « 🐝 Ce qui arrive si on s’en passe »Négliger ce domaine revient à laisser la configuration tenir lieu de politique de sécurité. Une permission accordée « pour aller vite » continue d’ouvrir les mêmes portes des années plus tard, et un compte de service endormi se réveille aussi bien pour un intrus que pour son créateur. Faute d’inventaire réel, une activité anormale se découvre d’abord sur la facture, sous forme de ressources que personne n’a déclarées ; le jour de l’enquête, il faut reconstituer ce qui tournait avant de pouvoir dire ce qui a été touché. Et comme la frontière de responsabilité n’a été vérifiée par personne, fournisseur et client découvrent en même temps que chacun comptait sur l’autre.
🦫 Explication de la marmotte 🍫
Section intitulée « 🦫 Explication de la marmotte 🍫 »Dans le cloud, une organisation ne possède plus ses machines : elle loue de la puissance de calcul et du stockage à un fournisseur, et décrit dans des fichiers ce qu’elle veut obtenir. Le fournisseur crée alors les machines, les réseaux et les droits d’accès demandés, et facture à l’usage. La sécurité est partagée : le fournisseur protège ses bâtiments, son matériel et ses services de base ; le client reste responsable de ses données, de ses réglages et de la question de savoir qui a le droit de faire quoi. Les incidents naissent souvent à cette frontière, chacun pensant que l’autre vérifie. Les droits sont gérés par des rôles, c’est-à-dire des ensembles de permissions qu’une personne ou un programme peut endosser, parfois en chaîne. Des permissions ajoutées pour aller vite et jamais retirées, ou des comptes de programmes oubliés, laissent des accès ouverts. Les applications tournent souvent dans des conteneurs, des programmes isolés qu’un orchestrateur démarre et répartit automatiquement ; si ses règles d’accès sont trop larges, tout circule. Les fichiers de description dérivent aussi : la configuration réelle s’éloigne peu à peu de celle qui était écrite. Enfin, l’inventaire déclaré et ce qui tourne vraiment diffèrent presque toujours, et les outils de contrôle ne voient que ce qu’on leur montre. La rubrique explique ces mécanismes et la manière de réduire cet écart.