Sécurité cloud AWS et Azure : une gouvernance cloud intégrée dès la conception

Les enjeux : la sécurité cloud se joue dans la configuration

Dans le cloud, l’infrastructure physique est sécurisée par le fournisseur. Ce qui reste de votre ressort, c’est tout ce que vous configurez : identités et permissions, exposition réseau, chiffrement, journalisation, sauvegardes. C’est le modèle de responsabilité partagée, et c’est là que se situent la plupart des risques : une clé d’accès oubliée dans un dépôt, un stockage rendu public pour un test, un rôle administrateur attribué « temporairement » il y a deux ans.

La difficulté augmente avec la croissance. Un compte AWS ou un abonnement Azure se gère à la main ; dix ou cinquante, avec plusieurs équipes, ne se gèrent plus sans règles automatiques. La gouvernance cloud consiste à poser ces règles une fois, centralement, pour que chaque nouvel environnement naisse conforme.

Ce que nous mettons en place

Identités et accès (IAM)

• Authentification centralisée via votre annuaire (AWS IAM Identity Center, Microsoft Entra ID), MFA obligatoire, suppression des utilisateurs et clés d’accès permanents.
• Rôles par métier et par environnement, au moindre privilège, avec des accès d’urgence tracés.
• Identités de charge de travail (rôles pour les applications et les pipelines CI/CD) plutôt que des secrets stockés.
• Revue périodique des accès, outillée.

Garde-fous centraux

• Organisation des comptes AWS (AWS Organizations, unités organisationnelles) ou des abonnements Azure (groupes d’administration), séparant production, hors production, sécurité et journalisation.
• Service Control Policies côté AWS et Azure Policy côté Azure : régions autorisées, interdiction de désactiver la journalisation, chiffrement obligatoire, blocage de l’accès public au stockage, tags requis.
• Ces fondations relèvent de la landing zone, que nous construisons avec vous lors d’un projet AWS ou Azure.

Protection des données

• Chiffrement au repos et en transit par défaut, clés gérées (AWS KMS, Azure Key Vault) avec politique de rotation et séparation des rôles.
• Gestion des secrets dans un coffre dédié, jamais dans le code ni dans les variables de pipeline en clair.
• Sauvegardes isolées du compte de production, testées par restauration.

Journalisation et détection

• Journaux d’API (AWS CloudTrail, journal d’activité Azure) centralisés dans un compte ou un espace dédié, protégés en écriture et conservés selon vos obligations.
• Services de détection natifs (Amazon GuardDuty, AWS Security Hub, Microsoft Defender for Cloud) activés et reliés à un circuit de traitement : qui reçoit l’alerte, qui décide, dans quel délai.
• Contrôles de configuration en continu plutôt qu’un audit annuel.

Sécurité dans le cycle de livraison

Les règles sont écrites en code et versionnées avec l’infrastructure. Les plans d’infrastructure sont analysés avant application (détection de ressources publiques, de chiffrement manquant, de permissions trop larges). C’est le prolongement naturel de notre travail en Terraform et Infrastructure as Code.

Conformité : HDS, RGPD, NIS2

La conformité ne se plaque pas après coup ; elle découle d’une architecture qui produit les preuves attendues (traces, chiffrement, contrôle d’accès, réversibilité).

• Hébergement de données de santé (HDS) : le fondateur de Feekr a conçu et opéré des infrastructures AWS en Infrastructure as Code dans ce contexte réglementé. Nous savons où s’arrête la certification de l’hébergeur et ce qui reste à votre charge.
• RGPD : localisation des données, minimisation des accès, journalisation, durée de conservation.
• NIS2 : la directive (UE) 2022/2555 élargit les obligations de cybersécurité à de nombreuses entités. Son application en France dépend de la loi de transposition et des textes d’application : à la date de publication (octobre 2026), vérifiez votre statut et vos obligations auprès de l’ANSSI. Texte de la directive : EUR-Lex, directive (UE) 2022/2555. Nous vous aidons à traduire les mesures techniques en configuration cloud ; nous ne remplaçons pas un conseil juridique.
• Réversibilité : formats ouverts, infrastructure décrite en code, procédures de sortie documentées, pour ne pas dépendre d’un fournisseur sans plan B.

Livrables concrets

• État des lieux de la sécurité et de la gouvernance de vos comptes ou abonnements, avec risques classés par gravité et effort de correction.
• Modèle d’organisation des comptes ou abonnements et des rôles.
• Catalogue de garde-fous (SCP, Azure Policy) en code, testé et documenté.
• Socle de journalisation et de détection centralisé, avec circuit de traitement des alertes.
• Matrice de conformité reliant vos exigences (HDS, RGPD, NIS2, politique interne) aux contrôles techniques en place.
• Runbooks : gestion d’un accès d’urgence, réponse à une alerte, revue des accès.

Pièges à éviter

Piège	Conséquence	Ce que nous faisons à la place
Garde-fous trop stricts dès le premier jour	Les équipes contournent ou réclament des exceptions permanentes	Mode audit d’abord, blocage ensuite, avec un processus d’exception
Tout le monde administrateur « pour avancer »	Aucune maîtrise du rayon d’impact d’une erreur	Rôles par métier, élévation temporaire tracée
Journaux collectés mais jamais lus	Une détection théorique	Alertes ciblées et responsable désigné
Règles configurées à la main dans la console	Dérive et impossibilité de prouver l’état	Tout en code, versionné et revu
Sécurité traitée en fin de projet	Corrections coûteuses, retards	Sécurité et gouvernance dès la conception

Comment nous travaillons avec vos équipes

Cadrer : état des lieux, exigences réglementaires, priorités. Construire : identités, organisation, garde-fous et journalisation. Industrialiser : tout passe en code et dans vos pipelines, avec des contrôles automatiques. Améliorer : revues périodiques, ajustement des règles, traitement des exceptions.

Nous travaillons avec vos équipes infrastructure, sécurité et développement, et nous documentons chaque règle avec sa raison d’être. Une règle comprise est une règle respectée.

Pour qui, et quand nous appeler

PME et ETI qui multiplient les comptes ou abonnements, préparent une exigence de conformité (HDS, NIS2, questionnaire client), sortent d’un incident ou d’un audit, ou veulent poser une gouvernance avant une migration cloud. Nous intervenons sur AWS comme sur Azure, depuis Villeneuve-d’Ascq dans la métropole lilloise, sur site ou à distance.

[ VOS QUESTIONS ]

Questions fréquentes

Qu’est-ce que la gouvernance cloud ?

C’est l’ensemble des règles, rôles et contrôles qui encadrent l’usage du cloud : qui peut créer quoi, où, avec quelles protections et à quel coût. Elle se traduit par une organisation des comptes ou abonnements, des politiques appliquées automatiquement et des processus de revue.

Qui est responsable de la sécurité dans le cloud ?

Le fournisseur sécurise l’infrastructure qu’il opère, le client reste responsable de ce qu’il y déploie : identités, configuration, données, réseau applicatif. C’est le modèle de responsabilité partagée publié par AWS comme par Microsoft. La plupart des incidents viennent de la part client, notamment de configurations trop permissives.

Quelle différence entre SCP et Azure Policy ?

Les Service Control Policies d’AWS Organizations fixent les permissions maximales autorisées dans des comptes, quel que soit le rôle utilisé. Azure Policy évalue et peut refuser ou corriger la configuration des ressources selon des règles. Les deux servent de garde-fous centraux, avec des logiques différentes à combiner avec l’IAM.

Un audit de sécurité cloud suffit-il ?

Un audit donne une photo utile pour prioriser, mais la configuration évolue chaque jour. Nous privilégions des contrôles continus et des garde-fous préventifs, complétés par des revues périodiques. L’audit devient alors un point de contrôle, pas l’unique mesure.

Peut-on héberger des données de santé sur AWS ou Azure ?

Oui, à condition de s’appuyer sur un hébergeur certifié HDS pour le périmètre concerné et de mettre en place les mesures qui relèvent de votre responsabilité : contrôle d’accès, chiffrement, traçabilité, sauvegardes. Le fondateur de Feekr a conçu des infrastructures AWS dans ce contexte.