Qu’est-ce qu’un ingénieur cloud en 2026 ?

Définition du métier

Un ingénieur cloud est un expert technique dont le rôle est de concevoir, bâtir et administrer des infrastructures IT dématérialisées. Contrairement à l’administrateur système classique, l’ingénieur cloud ne manipule plus de matériel physique : il transforme l’infrastructure en logiciel (Infrastructure as Code).

Son objectif est de garantir que les applications d’une entreprise soient toujours disponibles, sécurisées et capables de supporter des pics de charge instantanés. Il agit comme le pont critique entre les besoins métier (agilité, rapidité) et les contraintes techniques (stabilité, coût).

L’actualité du marché : une tension record

En 2026, le marché de l’emploi pour l’ingénieur cloud est marqué par trois dynamiques :

• La pénurie de talents spécialisés : malgré l’automatisation croissante, la demande de compétences sur AWS, Azure, GCP ou des cloud souverains dépasse largement l’offre. C’est cette rareté qui fait de l’ingénieur cloud l’un des profils les plus chassés par les recruteurs et les ESN.
• L’explosion du multicloud : les entreprises ne veulent plus dépendre d’un seul fournisseur. L’ingénieur cloud doit être polyglotte techniquement, capable de faire communiquer un cluster Kubernetes sur Google Cloud avec une base de données sur Azure.
• L’intégration de l’IA : aujourd’hui, l’ingénieur cloud doit savoir utiliser l’IA pour surveiller les infrastructures, prédire les pannes et automatiser la rédaction de scripts Terraform, ce qui déplace sa valeur ajoutée vers l’architecture de haut niveau et la stratégie de données.

Le constat de notre ESN : aujourd’hui, posséder une infrastructure cloud ne suffit plus, l’enjeu est d’avoir un ingénieur cloud capable de la rendre rentable et souveraine.

Le rôle et les missions de l’ingénieur cloud

Au sein d’une organisation, l’ingénieur cloud occupe une position transversale. C’est un facilitateur qui permet aux équipes de dev de livrer plus vite et aux directions financières de mieux maîtriser leurs budgets cloud. Son rôle consiste à transformer des besoins business en solutions technologiques scalables et résilientes.

Conception et architecture (Design)

Avant de déployer, l’ingénieur cloud dessine les plans. Il doit choisir les services les plus adaptés (calcul, stockage, Réseau) parmi les catalogues AWS, Azure ou GCP.

• Mission : définir si l’application doit être hébergée en Serverless, en conteneurs (Kubernetes) ou sur des machines virtuelles classiques.
• Objectif : garantir la haute disponibilité (SLA) et la tolérance aux pannes.

Automatisation via l’Infrastructure as Code (IaC)

C’est la marque de fabrique de l’ingénieur cloud moderne. Il ne configure plus les serveurs à la main dans une console web ; il écrit du code qui génère l’infrastructure.

• Mission : utiliser des outils comme Terraform, Ansible ou Pulumi pour versionner et automatiser le déploiement des environnements.
• Objectif : éliminer l’erreur humaine et permettre de reconstruire une infrastructure complète en quelques minutes.

Déploiement continu et culture DevOps

L’ingénieur cloud travaille main dans la main avec les développeurs pour fluidifier la chaîne de production.

• Mission : mettre en place et maintenir des pipelines de CI/CD (Intégration et Déploiement Continus).
• Objectif : faire en sorte que chaque mise à jour de logiciel soit testée et déployée automatiquement sans interruption de service.

Sécurité et gouvernance (DevSecOps)

Dans un monde où les cyberattaques se multiplient, l’ingénieur cloud est le premier rempart de l’entreprise.

• Mission : gérer les identités et les accès (IAM), configurer les pare-feu applicatifs (WAF), et s’assurer que les données sont chiffrées au repos comme en transit.
• Objectif : atteindre un niveau de sécurité maximal et répondre aux exigences de conformité (RGPD, SecNumCloud).

Lire aussi : comment évaluer sa maturité DevSecOps ?

Optimisation des coûts (FinOps) et observabilité

Une infrastructure cloud mal gérée peut devenir un gouffre financier. L’ingénieur cloud peut avoir un rôle de gestionnaire.

• Mission : monitorer les performances via des outils comme Grafana ou Prometheus et ajuster les ressources en temps réel (Right-sizing).
• Objectif : réduire le gaspillage de ressources et maximiser le retour sur investissement (ROI) du cloud.

Les compétences clés de l’ingénieur cloud

Les Hard Skills

• Maîtrise des fournisseurs de services (CSP) : Une connaissance approfondie d’au moins l’un des « Big Three » (AWS, Azure, GCP) est la base. L’ingénieur cloud doit comprendre les spécificités des services de calcul, de stockage et de base de données propres à chaque acteur.
• Maîtrise de l’Infrastructure as Code (IaC) : Savoir coder l’infrastructure est impératif. La maîtrise de Terraform est devenue le standard, complétée par Ansible pour la gestion de configuration ou Bicep pour les environnements 100% Azure.
• Conteneurisation et orchestration : L’ingénieur cloud doit impérativement maîtriser Docker et Kubernetes (K8s). Ces technologies sont aujourd’hui le moteur de la portabilité des applications.
• Scripting et développement : Sans être un développeur pur, l’ingénieur cloud doit savoir automatiser ses tâches via Python, Go ou des scripts Bash/PowerShell.
• Réseautage et sécurité : Comprendre les VPC, les sous-réseaux, le routage DNS et les protocoles de sécurité (SSL/TLS, IAM) est vital pour construire des architectures étanches.

Les Soft Skills

• Esprit d’analyse et résolution de problèmes : Face à une panne critique sur un cluster de production, l’ingénieur cloud doit faire preuve de sang-froid et d’une logique implacable pour isoler l’incident.
• Vulgarisation et Communication : En tant qu’ingénieur cloud en ESN, il est souvent amené à expliquer des choix d’architecture complexes à des clients ou des décideurs non techniques. Savoir traduire la technique en enjeux business est un atout majeur.
• Curiosité et veille technologique : L’ingénieur cloud doit être dans une démarche d’apprentissage continu pour ne pas être dépassé par les nouvelles offres (IA générative native, GreenOps, etc.).
• Sens de l’organisation : Gérer plusieurs environnements (Dev, Staging, Prod) demande une rigueur méthodologique sans faille pour éviter toute régression ou faille de sécurité.

Le choix des plateformes AWS, Azure et GCP

AWS (Amazon Web Services)

Leader historique, AWS reste la plateforme la plus vaste avec plus de 200 services. L’ingénieur cloud AWS évolue dans un écosystème où l’innovation est constante.

• Forces : Une granularité de configuration inégalée et une avance technologique sur le Serverless (AWS Lambda).
• Focus de l’ingénieur : Il doit maîtriser le Well-Architected Framework pour garantir que l’infrastructure est optimisée en termes de coût et de performance.
• Profil type : Idéal pour les architectures microservices à haute disponibilité et les projets nécessitant une scalabilité mondiale.

Microsoft Azure

Azure s’est imposé comme le choix naturel des grandes entreprises et du secteur public. L’ingénieur cloud Azure est le garant de la continuité entre le monde « On-Premise » (serveurs physiques) et le cloud.

• Forces : Une intégration parfaite avec l’écosystème Microsoft (Active Directory, Office 365, SQL Server) et une avance majeure sur le cloud hybride via Azure Arc.
• Focus de l’ingénieur : Une expertise pointue sur la gestion des identités (Entra ID) et sur la migration de workloads Windows massifs.
• Profil type : Parfait pour les entreprises cherchant une transition sécurisée et une gouvernance centralisée.

Google Cloud Platform (GCP)

Bien que challenger en parts de marché, Google Cloud attire pour son excellence technologique. L’ingénieur cloud GCP est souvent un profil tourné vers les données et l’innovation logicielle.

• Forces : Une supériorité reconnue sur l’orchestration de conteneurs (natif de Kubernetes) et des outils d’analyse de données et d’IA (BigQuery, Vertex AI) extrêmement performants.
• Focus de l’ingénieur : Il se concentre sur l’automatisation avancée et l’exploitation de la donnée à grande échelle.
• Profil type : Préféré par les entreprises « Data-Driven » et les équipes tech souhaitant une infrastructure simple, performante et ouverte.

Le cloud souverain

Le rôle de l’ingénieur cloud dans le cloud souverain

L’ingénieur cloud moderne peut être amené à se spécialiser sur des cloud souverains à travers une expertise sur :

• Le choix des acteurs locaux : Maîtriser les environnements de champions européens comme OVHcloud, Scaleway ou Outscale (Dassault Systèmes).
• Le déploiement de « Clouds de Confiance » : Savoir orchestrer des solutions hybrides comme S3NS (basé sur la technologie Google Cloud mais opéré par Thales) ou Bleu (technologie Microsoft Azure opérée par Orange et Capgemini).
• L’isolation des données : Mettre en œuvre des stratégies de chiffrement dont les clés sont détenues exclusivement par le client, et non par l’hébergeur.
• La mise en conformité NIS2 : Accompagner les Entités Essentielles (EE) et Importantes (EI) dans la sécurisation de leurs infrastructures cloud pour répondre aux nouvelles directives européennes de 2026.

Pourquoi choisir une approche souveraine ?

1. Protéger son patrimoine informationnel contre l’espionnage industriel et les saisies de données étrangères.
2. Faire de la protection des données un argument commercial majeur pour vos propres utilisateurs.
3. Réduire la dépendance vis-à-vis d’un fournisseur unique et garantir une maîtrise totale de ses actifs numériques.

L’avis de notre ESN : Un ingénieur cloud performant en 2026 est celui qui sait concilier la puissance d’innovation des outils mondiaux avec la rigueur de la souveraineté française. Nous aidons nos clients à placer chaque donnée au bon endroit, selon son niveau de sensibilité.

Les formations pour devenir ingénieur cloud

La voie académique

Le diplôme d’ingénieur ou le Master universitaire reste la référence pour accéder aux postes d’ingénieur cloud dans les grands groupes et les ESN.

• Des établissements comme l’ESILV, l’EPSI ou l’ENSITECH proposent des majeures dédiées au Cloud Computing et à la Cybersécurité. Ces cursus permettent d’obtenir un titre RNCP de niveau 7 (Expert en système d’information).
• Les Masters en informatique spécialisés « Cloud, Réseaux et Infrastructures » offrent un bagage théorique indispensable sur la virtualisation, le calcul distribué et la sécurité des données.
• L’alternance permet à l’apprenti ingénieur cloud de confronter ses connaissances aux réalités du terrain (gestion d’incidents, déploiements réels sur Azure ou AWS) tout en finançant ses études.

La reconversion

Pour les profils déjà issus de l’IT (développeurs, sysadmins) ou les profils scientifiques en reconversion, des formats courts et intensifs (3 à 9 mois) ont fait leurs preuves :

• Bootcamps Cloud & DevOps : Des organismes comme Ironhack, Diginamic ou O’clock proposent des programmes « commando » pour devenir ingénieur cloud junior. Ces formations se concentrent sur la pratique : Linux, Docker, Kubernetes et le scripting Python.
• POEI (Préparation Opérationnelle à l’Emploi Individuelle) : Souvent financés par France Travail en partenariat avec des ESN, ces parcours forment des ingénieurs cloud sur une stack spécifique pour une embauche immédiate en CDI.

L’auto-formation et le « Learning by Doing »

Le cloud évoluant plus vite que les programmes scolaires, l’ingénieur cloud doit cultiver une curiosité permanente via :

• Les plateformes d’apprentissage : Coursera, DataCamp ou EAZYTraining pour rester à jour sur les dernières nouveautés (IA Générative, FinOps).
• Les Labs : Créer ses propres infrastructures sur les paliers gratuits (Free Tiers) des fournisseurs pour tester des déploiements réels.

Le conseil de notre ESN : Au-delà du cursus choisi, ce qui définit un bon ingénieur cloud en 2026, c’est sa capacité d’apprentissage continu. Le diplôme vous donne les bases, mais c’est votre capacité à décrocher de nouvelles certifications chaque année qui fera de vous un expert incontournable.

Les certifications à obtenir

Les certifications AWS (Amazon Web Services)

Le catalogue AWS est le plus reconnu mondialement. L’ingénieur cloud débute généralement par le niveau Associate avant de viser l’expertise.

• AWS Certified Solutions Architect (Associate) : Le passage obligé pour prouver que l’on sait concevoir et déployer des systèmes robustes sur AWS.
• AWS Certified Solutions Architect (Professional) : Le graal pour l’ingénieur cloud senior. Elle valide la capacité à gérer des architectures complexes, multi-comptes et à haute disponibilité.
• Spécialités : Des certifications comme AWS Certified Security ou Advanced Networking sont idéales pour les profils souhaitant se nicher sur des enjeux critiques.

Lire aussi : Les certifications DevOps et cloud les plus recherchées

Les certifications Microsoft Azure

Incontournables pour l’ingénieur cloud travaillant avec des grands comptes ou des environnements hybrides.

• AZ-104 (Azure Administrator Associate) : Valide la gestion quotidienne des ressources (calcul, stockage, réseau).
• AZ-305 (Azure Solutions Architect Expert) : La certification de référence pour l’ingénieur cloud qui conçoit des solutions d’entreprise, incluant la sécurité et la continuité d’activité.
• AZ-500 (Azure Security Engineer Associate) : Cruciale pour répondre aux exigences croissantes de cybersécurité en 2026.

Les certifications Google Cloud Platform (GCP)

GCP est réputé pour avoir les examens les plus techniques et les plus difficiles.

• Associate Cloud Engineer : Pour démontrer sa capacité à déployer des applications et surveiller des opérations sur Google Cloud.
• Professional Cloud Architect : Reconnue comme l’une des certifications les mieux rémunérées au monde. Elle prouve que l’ingénieur cloud sait transformer des objectifs business en solutions cloud sécurisées et dynamiques.

Les certifications « Agnostiques »

Un ingénieur cloud complet ne s’arrête pas aux plateformes. Il doit certifier sa maîtrise des outils qui font le lien entre elles.

• CKA (Certified Kubernetes Administrator) : Indispensable. Elle prouve que l’ingénieur cloud sait orchestrer des conteneurs, que ce soit sur AWS, Azure ou un serveur on-premise.
• HashiCorp Certified (Terraform Associate) : La certification clé pour l’Infrastructure as Code (IaC), prouvant que l’expert sait automatiser n’importe quel cloud via du code.
• FinOps Practitioner : De plus en plus demandée en 2026, elle certifie la capacité de l’ingénieur cloud à maîtriser et optimiser les coûts de consommation.

Au sein de notre ESN, nous considérons que les certifications sont un gage de qualité pour nos clients. C’est pourquoi nous finançons le passage de ces examens pour chaque ingénieur cloud qui rejoint nos équipes, garantissant ainsi un niveau d’excellence constant sur le terrain.

Les évolutions de carrière pour un ingénieur cloud

L’architecte cloud

C’est l’évolution naturelle la plus fréquente. Là où l’ingénieur cloud déploie et administre, l’architecte cloud conçoit la vision globale.

• Son rôle : Transformer les besoins métier complexes en schémas techniques haute disponibilité. Il choisit les fournisseurs, définit les politiques de sécurité globales et anticipe la scalabilité à long terme.
• Valeur ajoutée : Une vision 360° qui intègre les enjeux de coûts (FinOps) et de souveraineté.

Le Site Reliability Engineer (SRE)

Inspiré par la culture Google, le SRE est un ingénieur cloud qui traite les problématiques d’exploitation comme des problèmes logiciels.

• Son rôle : Garantir la fiabilité maximale des systèmes critiques. Il passe une grande partie de son temps à coder des outils d’auto-réparation (self-healing) et à automatiser la réponse aux incidents.
• Valeur ajoutée : Une expertise pointue en développement et en performance système.

Le Platform Engineer

C’est la grande tendance de 2026. Le Platform Engineer crée une plateforme interne « en libre-service » pour les développeurs.

• Son rôle : Masquer la complexité du cloud pour les équipes de dev. Il bâtit des portails internes où un développeur peut, en un clic, provisionner un environnement complet sans solliciter l’ingénieur cloud.
• Valeur ajoutée : Une productivité décuplée pour l’ensemble de la DSI.

L’Expert cybersécurité cloud

Face à la recrudescence des cybermenaces, de nombreux ingénieurs cloud se spécialisent dans le DevSecOps.

• Son rôle : Auditer les infrastructures, mettre en place des politiques « Zero Trust » et assurer la conformité aux normes (ISO 27001, NIS2).
• Valeur ajoutée : Une protection vitale du patrimoine numérique de l’entreprise.

Le CTO / Head of Cloud

Pour ceux qui souhaitent s’éloigner de la technique pure pour diriger des hommes et des budgets.

• Son rôle : Piloter la stratégie cloud globale d’une entreprise, gérer les partenariats avec les fournisseurs (AWS, Azure, GCP) et manager les équipes d’ingénieurs cloud.

Le salaire d’un ingénieur cloud en 2026

En 2026, la tension sur le marché des talents IT reste forte, et l’ingénieur cloud figure au sommet des profils les plus convoités. Sa rémunération reflète la rareté de ses compétences, notamment lorsqu’il maîtrise des stacks hybrides ou des enjeux de cybersécurité. Le salaire d’un ingénieur cloud varie principalement selon trois critères : l’expérience, la localisation géographique et le niveau de certification.

Grille des salaires annuels

Note : Ces chiffres correspondent aux moyennes constatées en Île-de-France. En régions (Lyon, Nantes, Bordeaux), une décote de 10 à 15 % peut être observée, bien que le télétravail tende à réduire cet écart.

Le marché du freelance : Le Tarif Journalier Moyen (TJM)

De nombreux ingénieurs cloud optent pour l’indépendance. Le TJM est un excellent indicateur de la « valeur temps » de l’expert en 2026.

• Ingénieur Cloud Junior : 450€ — 550€ / jour.
• Ingénieur Cloud Confirmé : 650€ — 850€ / jour.
• Ingénieur Cloud Expert : Jusqu’à 1 200€ / jour pour des missions de conseil stratégique ou de sécurisation critique.

Les leviers d’augmentation : certifications et spécialisations

Le salaire d’un ingénieur cloud ne dépend pas que de son ancienneté. En 2026, certains facteurs boostent immédiatement la fiche de paie :

• Certifications « Professional » : Posséder un titre AWS Certified Solutions Architect – Professional ou Azure Solutions Architect Expert peut générer une prime annuelle ou une augmentation de 10 à 20 %.
• Expertise Cloud Souverain : La maîtrise des environnements SecNumCloud est devenue une compétence rare et premium, très recherchée par les entreprises du secteur public et de la défense.
• Double compétence Cloud & Data : L’ingénieur cloud capable d’optimiser des pipelines d’IA (MLOps) sur Google Cloud voit sa valeur marchande s’envoler.

Faire appel à un ingénieur cloud en ESN

Recruter un ingénieur cloud en interne est un défi de taille en 2026 : entre la pénurie de profils et l’évolution fulgurante des technologies, les entreprises peinent à maintenir leur expertise à jour. Passer par une Entreprise de Services du Numérique (ESN) permet de bénéficier d’un savoir-faire de pointe sans les contraintes liées au recrutement direct.

Bénéficier d’une intelligence collective multi-cloud

Contrairement à un profil interne parfois isolé face à ses problématiques, un ingénieur cloud en ESN évolue au cœur d’une communauté d’experts. Il capitalise sur les retours d’expérience de dizaines de projets menés simultanément sur AWS, Azure et GCP.

Cette vision transversale lui permet de ne jamais être « enfermé » dans une seule technologie : il est en mesure de proposer la solution la plus rentable et la plus performante, parfaitement adaptée au besoin spécifique de chaque contexte client.

Garantir des compétences certifiées et à jour

Le paysage technologique de 2026 évolue à un rythme que peu d’entreprises peuvent suivre en interne. Les ingénieurs cloud en cabinet de conseil consacrent une partie importante de leur temps à la formation continue et au passage de certifications de haut niveau (Solutions Architect Professional, CKA, SecNumCloud).

Cette organisation garantit que les infrastructures sont conçues selon les dernières « best practices » mondiales en matière de sécurité, d’automatisation et de FinOps.

FAQ : tout savoir sur le métier d’ingénieur cloud

Quelle est la différence entre un Ingénieur Cloud et un Ingénieur DevOps ?

L’ingénieur cloud se concentre principalement sur la conception, la sécurité et la robustesse de l’infrastructure (le contenant). L’ingénieur DevOps, lui, se focalise sur le cycle de vie des applications et l’automatisation de la chaîne de production (le contenu).

En 2026, ces deux rôles sont très proches, mais l’ingénieur cloud reste l’expert ultime des services managés et du réseau virtualisé.

Un Ingénieur Cloud doit-il savoir coder ?

Oui, impérativement. L’époque où l’on configurait des serveurs à la main est révolue. Un ingénieur cloud doit maîtriser l’Infrastructure as Code (IaC) avec des langages comme Terraform ou HCL, et savoir scripter en Python, Go ou Bash pour automatiser les tâches répétitives.

Quelle est la certification la plus demandée en 2026 ?

La certification AWS Certified Solutions Architect – Professional reste la référence absolue. Cependant, pour les profils orientés conteneurs, la certification CKA (Certified Kubernetes Administrator) est devenue un passage obligé pour prouver sa capacité à gérer des architectures agnostiques et multi-cloud.

Quel est le salaire d’un Ingénieur Cloud débutant ?

En 2026, un ingénieur cloud junior (0-2 ans d’expérience) peut espérer un salaire compris entre 45 000 € et 52 000 € brut annuel en Île-de-France, selon son école et ses certifications initiales.

Pourquoi choisir le Cloud Souverain plutôt qu’AWS ou Azure ?

Le choix du cloud souverain est avant tout une question de conformité et de sécurité juridique. Il permet aux entreprises stratégiques de protéger leurs données contre les lois extraterritoriales et de répondre aux exigences de l’ANSSI (qualification SecNumCloud), ce qui est crucial pour les secteurs de la défense, de la santé et de la finance.

Peut-on devenir Ingénieur Cloud en autodidacte ?

C’est possible, mais difficile sans un socle technique solide en systèmes et réseaux. La plupart des profils autodidactes passent par des certifications reconnues et des projets personnels (labs) pour prouver leur valeur sur le marché. En 2026, les ESN privilégient les profils certifiés ou issus de formations spécialisées.

Quel est le rôle d’un Ingénieur Cloud en matière de FinOps ?

L’ingénieur cloud a un rôle clé dans la maîtrise des coûts. Il doit concevoir des architectures qui s’adaptent à la demande (auto-scaling) et supprimer les ressources inutilisées (zombie assets). Son objectif est de maximiser la performance pour chaque euro dépensé chez le fournisseur cloud.

Quelles sont les technologies indispensables à maîtriser absolument ?

Outre les plateformes (AWS, Azure ou GCP), un ingénieur cloud doit maîtriser :

• Terraform (IaC)
• Kubernetes (Orchestration)
• Docker (Conteneurisation)
• GitLab CI / GitHub Actions (CI/CD)
• Prometheus / Grafana (Observabilité)

Est-il préférable d’être généraliste multi-cloud ou expert d’un seul Cloud ?

Le marché de 2026 valorise les profils « T-Shaped » : une connaissance générale du multi-cloud (comprendre les trois grands acteurs) mais une expertise profonde et certifiée sur une plateforme spécifique (ex: Expert Azure). Cela permet de s’adapter à toutes les missions tout en étant référent sur une stack.

Comment l’IA générative impacte-t-elle le métier d’Ingénieur Cloud ?

L’IA ne remplace pas l’ingénieur cloud, elle l’augmente. Elle aide à générer des scripts d’infrastructure plus rapidement, à détecter des failles de sécurité dans le code et à prédire les besoins en ressources. L’expert cloud de demain est celui qui sait piloter ces IA pour gagner en productivité.

Les certifications DevOps / cloud sont devenues un atout essentiel pour les ingénieurs et architectes qui cherchent à valider leurs compétences et à progresser dans leur carrière. En 2024, plusieurs certifications se démarquent comme particulièrement précieuses.

Effectivement, dans cet article, nous vous proposons un tour d’horizon des certifications DevOps et cloud les plus recherchées par l’industrie IT :

• HashiCorp Certified : Terraform Associate Certification
• Docker Certified Associate (DCA)
• Certified Kubernetes Administrator (CKA) et Certified Kubernetes Application Developer (CKAD)
• AWS Certified Solutions Architect (Associate/Professional)
• AWS Certified Advanced Networking
• AWS Certified Security – Specialty Certification
• Microsoft Certified : Azure Administrator Associate
• Google Cloud Professional Cloud Architect

HashiCorp Certified : Terraform Associate Certification

La certification Terraform Associate valide les compétences en Infrastructure as Code (IaC) avec Terraform. Elle couvre les concepts de base de Terraform, son utilisation pour provisionner et gérer des ressources cloud, ainsi que les meilleures pratiques. 

Si vous utilisez déjà l’IaC, cela devrait être l’une des certifications les plus faciles à obtenir. Elle est à choix multiples et couvre à la fois les concepts d’IaC et les commandes spécifiques de Terraform.

Quelques points importants sur la certification Terraform Associate : 

• Format de l’examen : L’examen consiste en 57-60 questions à choix multiples, réponses multiples, vrai/faux et correspondance de texte. 
• Durée : L’examen dure 1 heure. 
• Validité : La certification Terraform Associate est valable pendant 2 ans. 
• Prérequis : Il n’y a pas de prérequis officiels, mais il est recommandé d’avoir une connaissance de base d’au moins un fournisseur de cloud public et des compétences de base en terminal. 
• Sujets abordés : L’examen couvre les concepts d’IaC, l’objectif de Terraform, les concepts de base, l’utilisation de la CLI, l’interaction avec les modules, le flux de travail, la gestion de l’état, la lecture et la modification des configurations, et les fonctionnalités de Terraform Cloud et Enterprise. 
• Préparation : Il est recommandé d’étudier la documentation officielle de HashiCorp, de suivre des cours en ligne (il y en a plusieurs gratuits sur YouTube), de pratiquer avec des laboratoires pratiques et de passer des examens blancs. 
• Importance : La certification Terraform Associate est valorisée sur le marché et peut aider à mettre en valeur vos compétences en automatisation d’infrastructure. 

Docker Certified Associate (DCA)

La certification DCA démontre une expertise dans l’utilisation de Docker pour créer, déployer et exécuter des applications conteneurisées. Elle couvre l’architecture Docker, la sécurité, le stockage et les réseaux.

La structure de l’examen de la certification Docker Certified Associate est très différente des autres, ils utilisent un système différent de questions à choix multiples où vous ne pouvez pas revoir certaines questions. Il est très axé sur les commandes, moins sur la théorie, donc il est important que vous ayez déjà une certaine expérience avec Docker et une familiarité avec les conteneurs. C’est une certification intéressante à passer avant Kubernetes, car elle a beaucoup en commun et sert de base. Par ailleurs, vous payez et n’avez qu’une seule tentative pour l’examen. 

Stratégie de préparation: 

• Acquérir une expérience pratique avec Docker dans divers scénarios 
• Pratiquer intensivement les commandes Docker CLI 
• Comprendre la syntaxe des fichiers Docker et les meilleures pratiques 
• Étudier les concepts de réseau Docker et leurs implémentations 
• Apprendre les fonctionnalités de sécurité Docker et leur application 

Certified Kubernetes Administrator (CKA) et Certified Kubernetes Application Developer (CKAD)

La certification CKA (Certified Kubernetes Administrator) valide les compétences pour déployer et gérer des clusters Kubernetes en production. Elle couvre l’installation, la configuration, et la gestion de Kubernetes, ainsi que les concepts de base des applications cloud-native.

Entre la CKA et la CKAD (Certified Kubernetes Application Developer), vous pouvez choisir d’en faire une seule des deux. Elles sont très similaires, donc si vous choisissez seulement la CKA par exemple (puisqu’elle est plus généraliste), cela couvre déjà une grande partie du contenu englobé dans la CKAD.

Les certifications CKA et CKAD sont très intéressantes à passer, car, contrairement aux précédentes, elles sont 100% pratiques. Vous recevez un environnement Kubernetes et devez réaliser environ 15 tâches différentes qui seront évaluées de manière programmatique. Elles font partie des plus apprenantes, car elles mélangent connaissances théoriques et pratiques. 

Lorsque vous payez pour passer une de ces certifications CKA ou CKAD, vous obtenez automatiquement une reprise gratuite en cas d’échec à la première tentative. Quelques points importants à considérer : 

• Validité : Les certifications CKA et CKAD sont valables pendant 3 ans à partir de la date d’obtention.
• Environnement d’examen : L’examen est basé sur la version la plus récente de Kubernetes. 
• Durée et format : L’examen dure 2 heures et consiste en des tâches pratiques à réaliser dans un environnement de ligne de commande. 
• Sujets abordés : Le CKA couvre des sujets tels que l’architecture de cluster, l’installation, la configuration, les workloads, le scheduling, les services, le networking, le stockage et le troubleshooting. 

Lire aussi : Certification CKA : préparez sa certification efficacement

Zoom sur les certifications AWS

Elles font partie des certifications les plus intéressantes pour les ingénieurs et architectes cloud. Ce sont donc celles sur lesquelles je me concentre le plus en termes de temps d’étude et de préparation. Je pense que les suivantes sont les plus intéressantes à avoir.

AWS Certified Solutions Architect (Associate/Professional) ou DevOps Engineer Professional

Cette certification valide les compétences pour concevoir et déployer des systèmes évolutifs, hautement disponibles et tolérants aux pannes sur AWS. Elle couvre des sujets comme le calcul, le stockage, la mise en réseau et les bases de données sur AWS. 

AWS Certified Solutions Architect et DevOps Engineer Professional sont les deux certifications « généralistes » de haut niveau. Elles couvrent une grande majorité des services AWS, ce qui vous donnera une exposition aux services les plus utiles. 

AWS Certified Advanced Networking

Comme le networking est toujours intéressant dans les architectures, la certification AWS Certified Advanced Networking peut s’avérer très utile. Elle entre beaucoup dans les détails du Networking AWS. D’après l’expérience de nos consultants, il s’agit de la certification la plus difficile de toutes. 

AWS Certified Security – Specialty Certification

La sécurité est toujours importante, cette certification aide à plonger dans la plupart des services qui aident à créer une architecture sécurisée sur AWS. 

Microsoft Certified : Azure Administrator Associate 

Cette certification démontre la capacité à gérer les services cloud Azure, y compris le stockage, la sécurité, les réseaux et la gestion des identités.

Elle est idéale pour les ingénieurs et architectes cloud qui implémentent, gèrent et surveillent l’environnement Azure d’une organisation. 

Google Cloud Professional Cloud Architect 

La certification Cloud Profesionnal Cloud Architect valide les compétences pour concevoir, développer et gérer des solutions robustes, sécurisées, évolutives et dynamiques sur la plateforme Google Cloud.

Elle couvre l’infrastructure cloud, la sécurité et la conformité.

Conseils d’experts pour passer ses certifications DevOps et cloud 

Voici quelques conseils pour passer ses certifications DevOps et cloud :

• Valeur du processus : La véritable valeur ne réside pas seulement dans le certificat final, mais dans le processus d’apprentissage et de préparation. Chaque certification permet d’approfondir ses connaissances et combler des lacunes dont on n’a pas conscience. 
• Complémentarité : Les certifications se complètent de manière intéressante. Par exemple, la connaissance de Docker sert de base pour Kubernetes, tandis que les certifications AWS couvrent une gamme plus large de services cloud. 
• La pratique est fondamentale : Surtout pour les certifications pratiques comme CKA et CKAD, l’expérience hands-on est irremplaçable. Il est fortement recommandé de combiner l’étude théorique avec des projets pratiques. 
• Stratégie d’étude : Adapter la stratégie d’étude pour chaque certification est crucial. Certaines exigent plus de pratique des commandes, d’autres plus de compréhension conceptuelle. Tout dépend de la façon dont vous aimez étudier, chacun étudie différemment. 
• Impact sur la carrière : Ces certifications ne valident pas seulement des connaissances, mais ouvrent également des portes vers de nouvelles opportunités de carrière et des projets plus stimulants. 
• Apprentissage continu : Le domaine de la technologie est en constante évolution. Les certifications sont un excellent moyen de rester à jour et de continuer à apprendre. 

Pour aller plus loin

Article – AWS pour le DevOps : tour d’horizon des outils et services

Article – AWS Bedrock : comment l’utiliser ?

Article – Kubernetes Deployment : comment faire ? 

Vincent Strubel, Directeur Général de l’ANSSI, a récemment alerté sur le fait que la France est une cible privilégiée des cyberattaques. Avec l’accélération des stratégies go-to-cloud, et la sophistication croissante des menaces, la sécurité cloud est devenue un enjeu central pour les entreprises. Il est donc essentiel d’adopter une approche structurée et proactive pour protéger les infrastructures et les données.

La sécurité cloud par défaut et le modèle de responsabilité partagée

Les principaux fournisseurs de cloud sécurité comme AWS, Azure, Google Cloud Platform (GCP) et AliCloud ont développé des solutions avancées pour garantir une protection robuste. Ces acteurs appliquent un modèle de sécurité par défaut, qui repose sur des protections natives activées automatiquement et sur un modèle de responsabilité partagée (Shared Responsibility Model). Ce modèle définit clairement les rôles :

• Le fournisseur cloud assure la sécurité de l’infrastructure sous-jacente : accès physique aux datacenters, application des correctifs de sécurité et intégrité globale de la plateforme.
• Le client est responsable de la configuration et de la sécurité de ses données, applications et accès.

Cloud et Zero Trust : une approche indispensable

Une idée reçue répandue consiste à croire que le cloud est moins sécurisé qu’un environnement on-premise. En réalité, c’est l’utilisation du cloud sécurisé qui détermine son niveau de protection. Le concept de Zero Trust est essentiel : il repose sur le principe du « Ne jamais faire confiance, toujours vérifier ».

Les quatre piliers du Zero Trust sont :

• Sécurité périmétrique : contrôle strict des accès aux ressources.
• Certificats et authentification multi-facteurs : renforcement de la vérification d’identité.
• Gestion des droits et des utilisateurs : application du principe du moindre privilège.
• Chiffrement des données : protection des flux de données et stockage sécurisé.

La comparaison entre un château fort et un aéroport illustre bien les différences d’approche. Alors que la sécurité on-premise repose sur un unique périmètre fortifié, le cloud adopte une stratégie en couches multiples, offrant des niveaux de protection adaptatifs.

L’approche Zero Trust consiste à trouver le niveau de sécurité attendu en fonction des attentes et de la criticité des données ou du service utilisé. Tous les fournisseurs de cloud fournissent l’intégralité des outils pour pouvoir mettre en place tout type de défenses. 

Les piliers de la sécurité cloud

La sécurité cloud repose sur plusieurs fondements stratégiques :

• Conformité et réglementation : respect des normes ISO 27001, GDPR, SOC 2, etc.
• Gestion des identités et des accès (IAM) : contrôler qui peut accéder à quoi et sous quelles conditions.
• Détection et réponse aux menaces : outils comme Microsoft Defender for Cloud ou AWS GuardDuty permettent une surveillance continue.
• Protection des infrastructures : pare-feu, Network Security Groups (Azure), Security Groups (AWS), segmentation réseau.
• Chiffrement des données : chiffrer les données en transit, au repos et en utilisation.
• Gestion des incidents : développement de plans de réponse à incident et simulations d’attaques.

Lorsqu’une entreprise amorce sa migration vers le cloud, une équipe dédiée est généralement constituée.

Cette équipe peut avoir diverses appellations : Cloud Team, CCoE, etc. 

Gouvernance et responsabilités dans un environnement cloud

Lors de la migration vers le cloud, une gouvernance claire est essentielle. Une équipe spécifique, souvent appelée Cloud Center of Excellence (CCoE) ou Cloud Team, doit intégrer des experts en sécurité, notamment des DevSecOps et des RSSI Cloud. Cette gouvernance repose sur une collaboration entre les équipes IT, DevOps et cybersécurité pour garantir un usage sécurisé et conforme aux bonnes pratiques.

Coût et optimisation de la sécurité cloud

Les fournisseurs de services cloud mettent à disposition des outils de sécurité de base, comme les Network Security Groups chez Azure ou les Security Groups chez AWS, généralement sans frais supplémentaires. Cependant, les fonctionnalités avancées comme l’analyse et la surveillance, capables de générer des métriques précises et de détecter activement des attaques ou intrusions, s’accompagnent d’un coût additionnel. 

La subtilité de la sécurité dans le cloud réside dans le fait que les composants essentiels tels que les pare-feu et la gestion des identités sont souvent fournis à des coûts minimaux ou nuls. En revanche, pour des fonctionnalités plus sophistiquées, telles que les tableaux de bord consolidés offrant une vue d’ensemble, les coûts s’appliquent. 

Le véritable enjeu est de déterminer quel est l’investissement minimal requis pour une sécurité efficace dans le cloud. Au-delà de la sécurité, tout aspect lié au cloud doit envisager un volet FinOps pour une gestion optimale des coûts. 

Il est donc crucial, lors de l’évaluation de la maturité de l’entreprise, de bien comprendre quels outils sont utilisés, leur usage et leur finalité. Cela aide à orienter l’usage stratégique de ces outils et à anticiper les implications financières y afférentes. 

Mise en place d’une stratégie de sécurité cloud

Mettre en œuvre une stratégie de sécurité dans le cloud implique plusieurs étapes clés :

1. Audit de sécurité cloud (cloud assessment) : évaluer la maturité de l’organisation.
2. Cartographie des outils de sécurité : identifier les solutions en place.
3. Définition des besoins par profil utilisateur : RSSI, développeur, admin cloud.
4. Plan de remédiation et audits réguliers : mise en place de correctifs continus.
5. Tests et simulations d’incidents : validation des procédures de réponse aux cyberattaques.

Conclusion

La sécurité cloud ne repose pas uniquement sur la technologie, mais aussi sur une bonne gouvernance, une compréhension du modèle de responsabilité partagée et une adoption des meilleures pratiques, notamment le Zero Trust. Une stratégie efficace allie protection proactive, surveillance continue et optimisation des coûts pour garantir un environnement cloud sécurisé et performant.

Pour aller plus loin

Article – Les 6 stratégies de migration vers le cloud (6R)

Article – Lift and Shift, Replatform ou Cloud Native : quelle stratégie de migration cloud ?

Les fondements de la stratégie de la migration cloud 

Comprendre les objectifs business et la vision stratégique de l’entreprise est crucial pour une transition réussie vers le cloud. L’un des premiers défis consiste donc à se poser les bonnes questions. 

Quels sont les objectifs business de votre entreprise ? Quelle est votre vision stratégique à court et à long terme ? Comment pouvez vous utiliser le cloud pour renforcer la collaboration avec vos partenaires et stimuler l’innovation au sein de votre catalogue d’offre ? 

En effet, les enjeux du passage vers le cloud pour votre entreprise sont triples :

• Le cloud est un investissement important tant en termes de temps, que de coûts. Il est donc important de s’assurer que le cloud est bien la solution qui correspond aux besoins de l’entreprise.  
• Le cloud aura un impact significatif sur votre entreprise. Il peut vous aider à améliorer votre efficacité, optimiser vos coûts, réduire votre empreinte carbone ou accélérer l’innovation. 
• Le cloud est un environnement complexe. Il existe de nombreux fournisseurs de cloud différents, chacun offrant justement une gamme de services plus ou moins similaire. Il faut faire attention à ne pas s’y perdre et à faire les bons choix. 

L’assessment approfondi : la clé de la réussite 

La migration vers le cloud ne se limite pas à une simple opération technique ; c’est un investissement significatif en termes de temps et de coûts. Avant de prendre des décisions, réaliser un assessment approfondi est impératif. Celui-ci permet d’évaluer la maturité de l’organisation dans différents domaines tels que la sécurité, la gouvernance, les opérations, et la culture DevOps. 

L’étape de l’assessment permet de définir une stratégie globale, de cartographier votre paysage technologique actuel, et de vous guider dans le choix du fournisseur cloud. Cette phase préliminaire, souvent négligée, est pourtant la clé d’une migration réussie. 

Ainsi, plusieurs aspects devront être mesurés dans le cadre de cet assessment :

• La stratégie globale de l’entreprise : objectifs business, vision stratégique, vision avec les partenaires, par ligne de produits…
• La gouvernance : niveau d’interaction avec les directions métiers, organisation de la DSI…
• Le niveau de maturité en matière de sécurité
• Les opérations : politique de sauvegarde, historique en termes d’infrastructure…
• Les plateformes et écosystèmes technologiques
• L’usage et la maturité des équipes en matière de cloud

Une fois cette cartographie complète réalisée, vous serez à même de prendre des décisions plus éclairées pour définir votre méthodologie de migration et faire le choix du cloud provider. 

La formation continue : un pilier essentiel de la migration cloud

Une fois la vision stratégique clarifiée, il est essentiel de former vos équipes. La migration cloud est bien plus qu’une transition technique ; c’est un changement de modèle organisationnel. La mise en place de plans de formation continue, adaptés à tous les niveaux de l’entreprise, sera indispensable pour assurer une adoption réussie des services cloud au sein de vos équipes. 

En effet, la migration vers le cloud implique le passage d’un modèle traditionnel à un modèle plus agile. Les équipes doivent délaisser les approches conventionnelles de gestion des infrastructures et embrasser une approche plus automatisée 

De plus, le paysage du cloud computing évolue rapidement, avec de nouveaux services et fonctionnalités introduits régulièrement par les fournisseurs. De ce fait, les plans de formation doivent être itératifs et capables de s’adapter à ces changements technologiques. Les équipes doivent rester agiles, prêtes à intégrer de nouvelles compétences au fur et à mesure de l’évolution du projet. 

Vos équipes ne sont pas seulement des utilisateurs compétents des services cloud, mais aussi des moteurs d’innovation et des garants de la sécurité et de la performance de votre infrastructure cloud. 

Conclusion : le cloud, une transformation radicale de l’entreprise 

En résumé, une migration cloud réussie nécessite une approche stratégique, une préparation minutieuse, une formation continue et une adaptation agile tout au long du projet. Une transition vers le cloud est un engagement à long terme qui, lorsqu’il est bien orchestré, peut rapidement améliorer l’efficacité opérationnelle et accélérer l’innovation au sein de votre entreprise. 

Pour aller plus loin

Article – Comment maîtriser l’architecture de vos données cloud ?

Article – La sécurité dans le cloud : stratégie du Zero Trust

Article – Cloud privé : pourquoi et comment le déployer ?

C’est ici que Terraform, un outil d’automatisation puissant d’infrastructure as code (IaC) développé par HashiCorp, se positionne pour redéfinir la manière dont les entreprises créent, modifient et gèrent leurs déploiements d’infrastructures sur les différents cloud providers.

Quand adopter Terraform ?

Il existe plusieurs raisons d’adopter Terraform :

• Lorsqu’il faut automatiser la création de ressources, comme la création de clusters ou bien le provisionnement de tout un écosystème d’une application (serveur, base de données, autorisations IAM…). Terraform va permettre de réaliser toutes ces actions simultanément, ce qui sera beaucoup plus rapide et efficace à effectuer.
• Pour mettre en place un système de versions d’infrastructure, l’association avec Git permet de gérer plusieurs versions en utilisant les commit et les branches de Git.
• En phase de développement et de test, Terraform peut être associé à un outil d’administration à distance comme Ansible ou Chef, et cela va permettre de construire un environnement de test et de le supprimer à n’importe quel moment. L’objectif serait de provisionner un environnement pendant le développement, tout en optimisant un maximum de coûts, car il pourrait être supprimé lorsque les développeurs ou architectes Cloud ne travaillent plus dessus.
• Pour des raisons d’audit, si tout est limité à l’utilisation de Terraform, on peut facilement construire des audits sur les actions qui ont été mis en place via l’outil, ce qui pourrait être plus difficile via les consoles Web.

Terraform & Azure ?

Terraform et Azure partagent une philosophie commune : simplifier la gestion des infrastructures en les codifiant. Terraform peut agir comme un orchestrateur, qui va permettre aux utilisateurs de définir leur infrastructure sous forme de code en langage HCL, tandis qu’Azure fournit une gamme très étendue de services cloud.

Configuration de l’environnement Terraform pour Azure

Avant de déployer des ressources sur Azure avec Terraform, l’initialisation du projet est obligatoire. Utilisez la commande terraform init pour configurer l’environnement et télécharger les plugins nécessaires, y compris ceux spécifiques à Azure.

De plus, configurez votre fournisseur Azure en spécifiant tous les détails d’authentification, tels que l’ID du client, la clé secrète, et l’ID du tenant.

Cette configuration établit la connexion entre Terraform et votre abonnement Azure.

Déclaration d’infrastructure Azure avec Terraform

La déclaration d’infrastructure sur Azure avec Terraform est simple et efficace. Utilisez le langage HCL pour décrire vos ressources (en code), comme dans cet exemple de création d’une machine virtuelle :

Le code ci-dessus déclare une machine virtuelle nommée « example-vm » dans le groupe de ressources spécifié avec d’autres configurations comme la location et la taille de la VM.

Gestion des variables et des secrets : sécurité et flexibilité

Terraform assure une gestion efficace des variables, permettant aux équipes de paramétrer leurs configurations. De ce fait, l’utilisation des variables est recommandée pour rendre votre code plus flexible et adapté à différents environnements.

Les variables peuvent également être utilisées pour gérer des secrets sensibles, assurant ainsi une approche fiable et sécurisée.

Cycle de vie des ressources Azure avec Terraform : du plan à l’application

Le cycle de vie des ressources sur Azure avec Terraform comprend les étapes commençant du plan à l’application. La commande terraform plan permet de prévisualiser tous les changements proposés ou qui vont être planifiées, tandis que terraform apply applique effectivement ces changements. Ces commandes sont essentielles pour maintenir un meilleur contrôle sur les modifications apportées à l’infrastructure.

Modularité et réutilisabilité avec les modules Terraform

Les modules Terraform encouragent la modularité et la réutilisabilité du code. En encapsulant les configurations dans des modules, les équipes peuvent créer des composants entièrement autonomes et réutilisables en tant que templates.

Cette manière facilite la collaboration, réduit la duplication du code et accélère l’avancement du développement.

Conclusion

En résumé, l’intégration entre Terraform et le cloud Azure offre une solution efficace qui permet aux équipes de :

• concevoir des infrastructures évolutives avec précision et rapidité,
• simplifier le déploiement et la gestion d’infrastructures complexes et difficiles à mettre en place manuellement.

En combinant une approche déclarative, une prise en charge multi-cloud, une modularité et une sécurité intégrée, Terraform fait l’objet d’une solution complète que les entreprises peuvent adopter afin d’accélérer leurs déploiements, garantir l’agilité et faciliter la collaboration entre les différentes équipes intervenantes.

Pour aller plus loin

Article – Cloud Assessment : comment guider sa migration ?

Entre temps, une preview a fait son apparition courant janvier, et concerne la fonctionnalité Managed VNet.

Elle va apporter quelques options supplémentaires pour se connecter à vos ressources Azure, notamment celles qui sont privatisées, en facilitant leur mise en œuvre.

Cette preview reste limitée à date aux régions suivantes :

• Australia East
• Canada Central
• East US 2
• West Europe

https://docs.microsoft.com/en-us/azure/purview/catalog-managed-vnet#supported-regions

Managed VNet : quelle utilité ?

Déjà utilisé par plusieurs services, notamment Data Factory ou Synapse, c’est un réseau managé et intégré au service qui le porte. Pas d’adresses IP à gérer, d’interconnexion ou de peering… de toute façon vous n’avez pas la main dessus !

Une « integration runtime » cloud est instanciée sur ce réseau, et grâce à l’utilisation de private endpoints que vous provisionnerez dessus, celle-ci va pouvoir utiliser de manière totalement privée les ressources qui y seront connectées.

Quel avantage ? Ne plus déployer de self hosted integration runtime pour utiliser des ressources Azure privatisées !

Reste que les services sont pour le moment limités, mais devraient couvrir bien des cas d’usages courants :

• Azure Blob Storage
• Azure Data Lake Storage Gen 2
• Azure SQL Database
• Azure Cosmos DB
• Azure Synapse Analytics
• Azure Files
• Azure Database for MySQL
• Azure Database for PostgreSQL

Dans le portail Purview

La configuration de l’integration runtime cloud en mode « Managed Virtual Network » se fait dans la section « Data Map », comme pour le mode « Self Hosted ».

Quelques minutes après sa création, trois private endpoints sont automatiquement crées (image ci-dessous). Ce sont eux qui vont permettre l’ingestion de données dans Purview.

Ce même écran va également vous permettre d’ajouter vos private endpoints vers vos ressources Azure à scanner.

A noter que l’event hub managé de Purview est également utilisé, certainement en direct sur le backbone Azure. Il n’est pas spécifiquement protégé au niveau réseau, son niveau d’accès restant toujours en « All networks ». Rassurez-vous, les données scannées ne passent pas par ce biais !

Architecture

En reprenant une architecture classique avec accès restreint et en y intégrant le Managed VNet, cela donne le schéma suivant. Oui, cela commence à faire pas mal de tuyauterie « Private Link »!

Et encore je n’ai pas fait le cas d’usage avec Synapse et son propre Managed VNet …

Conclusion

Le fonctionnement n’est pas très éloigné de l’integration runtime en mode « Self Hosted ».

Le bonus, c’est que le système est totalement managé ! Plus besoin d’utiliser une machine virtuelle, cela simplifie grandement le déploiement.

La fonctionnalité restant en preview, elle peut bien sûr évoluer, et est déconseillée en production tant qu’elle ne passe pas le stade de la « General Availability » !

Vous trouverez plus d’information sur la documentation : https://docs.microsoft.com/en-us/azure/purview/catalog-managed-vnet

Bons tests !

L’objectif de cet article n’est pas de présenter la solution en elle-même, mais de voir comment elle s’intègre au niveau réseau dans Azure, dans un contexte sécurisé.

Je m’inspire d’une expérience d’implémentation chez un de nos clients, avec des contraintes réseau et sécurité fortes ! Ces contraintes imposent une exposition réseau limitée à l’interne, et de pouvoir se connecter à des sources de données de différents types & niveaux de classification.

Imaginez que vous ayez plusieurs coffres forts, dans différents lieux, avec une carte sur laquelle vous avez noté tous les emplacements et ce qu’ils contiennent. Est-ce que vous laissez cette carte accessible à tous ?

Vous l’avez deviné, Azure Purview, c’est cette carte !

Avec ce prérequis, je balaye dans cet article la partie réseau de Purview, trois cas d’usage illustrés pour la compréhension globale, ainsi que quelques analyses et recommandations techniques.

Configuration réseau 

Le paramétrage global est simple, basique : un firewall en mode On/Off pour l’accès public de Purview. Cela couvre l’accès au portail Purview et au compte (account), mais aussi au compte de stockage managé. Le firewall de ce dernier suit automatiquement.

Forcément dans notre cas, l’accès public est désactivé !

Configuration Firewall 

Il n’est pas possible d’utiliser un filtrage sur des ranges IP ou via des « Azure Trusted Services » par exemple. Un peu dommage, car cela va impliquer d’utiliser un VNet (réseau virtuel).

La connexion à un VNet est possible par l’utilisation de Private Enpoints, au nombre de 5 : Purview Account & Portal, Storage account Blob & Queue et l’Event Hub. Il est possible de réduire le nombre de ces endpoints, certains cas d’usage ne les requièrent pas tous.

Configuration Private Endpoints portail / compte Purview 

Configuration Private Endpoints des ressources managées (Storage Blob/Queue et Event hub) 

Cas d’usage « global » avec ressources Azure/Cloud 

Lorsque les sources de données que Purview doit analyser sont accessibles en direct, que ce soit dans Azure ou sur le Cloud, les traitements sont réalisés directement par l’intégration runtime d’Azure Purview.

L’accès au portail Purview et aux endpoints d’ingestion est possible via les Private Endpoints (PE). Que vous utilisiez un réseau local interconnecté via VPN ou ExpressRoute au VNet disposant des PE, l’accès à Purview se fait alors de manière totalement privatisée.

À noter : Microsoft ne publie pas les adresses IP utilisées par le service Purview pour initier les connexions vers les data sources, sécuriser les flux peut donc s’avérer complexe.

Le service Purview dispose d’une «  Managed identity  » de type système qui permet de s’authentifier sur d’autres ressources, voire de filtrer via cette identité pour les services le supportant via les « Azure trusted services » (par exemple, Azure storage et Data Lake Gen2 le supportent).

Cas d’usage avec ressources Azure privatisées ou locales

J’entends par ressource Azure «  privatisée  » le fait qu’elle ne soit accessible que par un VNet via un Private Endpoint.

Dans ce cas, comme pour les sources de données on premise, l’utilisation d’un composant « Self Hosted Integration Runtime » (SHIR) est nécessaire.

Ce composant, hébergé sur une machine virtuelle, est connecté à Azure Purview et va servir de relai pour se connecter aux sources de données.

Localement, il est difficile de faire autrement, sauf peut-être en conteneur ; cependant, sur Azure une intégration VNet native aurait été plus élégante… Demander un composant IaaS pour faire communiquer des services PaaS, c’est un peu «  old school  » !

Ce composant peut vous être familier, il est en effet commun à Azure Data Factory, Azure Synapse Analytics and Azure Purview.

Cas d’usage Synapse

Le cas d’usage Synapse n’est pas le plus évident, et pourtant il n’est pas beaucoup plus complexe que le précédent.

Trois scénarios d’usage entre Synapse et Purview sont possibles.

Scan des données SQL 

Ce cas est traité à l’identique du précédent, via une SHIR.

Découverte et exploration de données depuis le portail Synapse Studio 

L’accès utilisateur via les PE Account & Portal de Purview répond à ce besoin. Cela enrichit l’expérience dans Synapse studio.

Exécution de Pipeline et rapport du lignage de données

Synapse remonte à Purview les informations de transformation des données, exécution de pipelines, etc. Il nécessite 4 nouveaux PE à positionner dans le VNet managé de Synapse. Les plus observateurs auront noté qu’il en manque un, c’est normal… Synapse n’a pas besoin du portail !

Finalement, pour couvrir tous les scénarios, cela nécessite un peu de tuyauterie…

Private Endpoints : DNS & Proxy

DNS 

Comme souvent, la résolution DNS est primordiale pour privatiser des flux cloud.

En utilisant une SHIR hébergée dans Azure, utilisez de préférence les private DNS zone intégrées, soit via la résolution native Azure, qui est plus simple, ou via des redirections de zones si vous gérez votre DNS.

Une autre zone « privatelink.purviewstudio.azure.com » est mentionnée dans la doc Microsoft, mais celle-ci ne semble plus être nécessaire depuis la disponibilité générale du service ! Elle n’est plus créée avec les PE.

La redirection DNS est valable en local également, mais s’il n’est pas possible de l’utiliser, il reste l’option de créer les noms dans votre DNS interne. Voire, en dernier recours, âmes sensibles s’abstenir, d’utiliser le bon vieux fichier host. Oui, il est toujours là, et c’est même dans la documentation.

Microsoft fournit donc une liste de 21 noms à créer. Avec un mix de noms spécifiques à votre implémentation (le nom de votre compte Purview, ses ressources managées…), et de noms publics et génériques dont les flux passent via les PE.

Source : https://docs.microsoft.com/en-us/azure/purview/catalog-private-link-name-resolution 

Si vous avez plusieurs comptes Purview, ce mix privé/public peut rediriger de fait des flux publics vers un PE aléatoire si vous avez plusieurs enregistrements… Cela concerne principalement le PE « portal » et la facturation de son trafic s’en trouvera moins exacte. Enfin, elle sera aussi aléatoire que la réponse DNS !

Après analyse, les flux du Private Endpoint « portal » ne faisant passer que des résolutions publiques génériques (sans endpoint spécifique), il est possible de se passer du PE et de ses multiples résolutions.

Vous pouvez, au choix, :

• laisser sortir ce flux via Internet,
• soit via un unique PE (attention de fait à l’adhérence à celui-ci). Cela n’affecte pas le comportement du portail, celui-ci vérifiant l’accès privé via le Private Endpoint account.

Pour que ce soit plus parlant, voici les résolutions DNS depuis plusieurs emplacements.

Résolution depuis une VM dans Azure, via le DNS Azure avec les zones DNS privées (créées automatiquement avec les PE).

Deux sont étranges… Une résolution est HS et une autre publique !

Pour comparaison, la résolution publique.

Résolution publique depuis un site client (redirection DNS inconnue, visiblement quelque part au UK ?).

Résolution publique depuis un opérateur (l’Agrume) 

L’enregistrement non résolu l’est toujours, et l’enregistrement «  gateway.purview.azure.com  » est visiblement régionalisé, son IP et nom associé changent.

Avec cette analyse, à vous de voir si vous créez les 21 enregistrements de la documentation, modulo les enregistrements inutiles, si vous vous passez du PE portal… N’oubliez pas de tester et de vérifier où passent vos flux ! Attention toutefois à être dans une configuration supportée par Microsoft si vous rencontrez des problèmes.

Proxy

En théorie 

Si vous êtes dans un environnement cloisonné, où la seule porte de sortie est un proxy, il faudra bien l’utiliser pour connecter la SHIR, notamment pour qu’elle joigne Azure AD pour s’authentifier.

La déclaration du proxy se fait dans sa configuration, mais n’oublions pas que les flux privatisés doivent atteindre les PE, donc être exclus du proxy…

Donc, deux fichiers .xml spécifiques sont à peupler selon une syntaxe toute .Net-ienne !

Ces fichiers à modifier sont dans le dossier d’installation de la SHIR :

• diahost.exe.config
• diawp.exe.config

Si cela fonctionne, que vos scans Purview remontent des informations de vos sources, tant mieux !

In da Real world

En intégrant Synapse en tant que source de données, nous avons constaté qu’un job se lançait sans jamais détecter de contenu. Aucun log ne relevait clairement le problème et le support Azure n’a pas réussi à identifier un problème spécifique.

Quelques pistes ont été identifiées comme le fait d’avoir les Private Endpoints dans un autre VNet via un peering, ce cas n’étant jamais documenté et presque présenté comme prérequis. Malgré un placement des PE dans le même réseau & sous-réseau que la machine, le problème persistait.

Après une analyse un peu plus poussée sur la VM SHIR, après avoir revu de nombreuses fois les résolutions DNS, les exceptions Proxy, etc. sur la machine SHIR, un processus se lançait, et tentait désespérément une connexion directe vers des IP publiques d’Azure sans tenir compte du proxy.

En calquant le fonctionnement pour les exécutables précédents, le problème a été résolu en générant une section de configuration de proxy pour le processus en question, via un fichier de configuration (à placer dans le même répertoire que l’exe) :

• Microsoft.DataMap.Agent.Connectors.Azure.DataFactory.ServiceHost.exe.config

Visiblement ce processus a la charge d’exécuter les jobs de scan Purview dans la SHIR. Nous avons constaté une fois le problème résolu qu’il se connectait à Synapse sur le port 1433 via son propre PE, au proxy et aux PE Purview.

Scan Synapse avant / après : les assets sont peuplés ! 

Sources SHIR & Proxy :  

https://docs.microsoft.com/en-us/azure/purview/manage-integration-runtimes#configure-proxy-server-settings

https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/network/bypasslist-element-network-settings

Conclusion 

La privatisation de ressources Cloud n’est jamais simple, Purview n’échappe pas à la règle.

Selon vos sources et leur niveau de sécurisation ou d’isolation, définir une architecture cible pour couvrir les différents cas d’usage et leur intégration peut se révéler complexe.

J’espère que cet article aura permis de vous éclairer sur le fonctionnement de Purview au niveau infrastructure et d’appréhender quelques-unes de ses dépendances !