Les 14 principaux référentiels de normes de sécurité dans le cloud en 2026

Principaux enseignements

• Les normes de sécurité du cloud se répartissent en cinq types de mise en œuvre, allant des certifications et attestations aux réglementations, contrats et cadres de contrôle.
• La norme ISO/IEC 27017 a fait l'objet de sa première refonte complète depuis 2015, le FedRAMP a réécrit son règlement et la CSA a publié la version 4.1 du CCM.
• La correction des failles figure dans presque toutes les normes, mais seules quelques-unes fixent une date limite stricte à cet égard.
• La plupart des difficultés liées à l'audit s'accumulent entre deux évaluations, tandis que le retard dans l'application des correctifs s'accroît et que les configurations dérivent.

Une grande partie des activités d’une entreprise moderne repose désormais sur une infrastructure qui ne lui appartient pas, et cette évolution a modifié la répartition des responsabilités en matière de sécurité. Elle a également multiplié le nombre de référentiels de règles d’une équipe de sécurité doit respecter simultanément. Les normes de sécurité du cloud sont la concrétisation écrite de ces règles.

Cet article explique ce que sont les normes de sécurité dans le cloud, pourquoi le type de norme est important, et quelles sont les 14 normes les plus importantes pour les programmes de conformité dans le cloud en 2026.

Qu'est-ce que la sécurité dans le cloud ?

La sécurité dans le cloud désigne l'ensemble des mesures de contrôle qui protègent les charges de travail, les identités et les données dans les environnements cloud, c'est-à-dire généralement des serveurs gérés par un tiers. Elle couvre la configuration, le chiffrement, la gestion des accès, l'application des correctifs et la surveillance dans les modèles IaaS, PaaS et SaaS. Dans le modèle IaaS, le fournisseur gère les hôtes physiques et l' hyperviseur, tandis que vous êtes propriétaire de presque tout ce qui se trouve au-dessus du système d’exploitation invité. En SaaS, le fournisseur gère la majeure partie de la pile ; votre rôle se limite donc à la gestion des identités, à la configuration des locataires et au contrôle de l’utilisation des données par les utilisateurs. Le PaaS se situe entre les deux.

Qu'est-ce que les normes de sécurité dans le cloud ?

Les normes de sécurité dans le cloud sont des exigences publiées qui définissent ce que signifie « suffisamment sécurisé » dans le cloud, et elles fournissent aux auditeurs et aux régulateurs des critères concrets à vérifier. Certaines s’accompagnent d’un véritable certificat qui expire et doit être renouvelé. D’autres donnent lieu à un rapport d’attestation plutôt qu’à une certification de conformité ou de non-conformité. Certaines ont force de loi et sont assorties d’amendes. D’autres encore constituent des recommandations volontaires que les organisations adoptent parce qu’un client, un auditeur ou leur propre évaluation des risques les y incite.

Cette dernière catégorie recoupe ce que l'on appelle généralement les cadres de sécurité du cloud: le NIST CSF, la matrice de contrôles cloud (CCM) de la CSA, ainsi que d’autres référentiels similaires conçus à des fins d’orientation plutôt que de certification. Ce chevauchement est bien réel, et il va dans les deux sens. De nombreux recueils de « normes » incluent le NIST CSF et la CCM, même si ces deux référentiels se définissent comme facultatifs.

Ce guide utilise le terme « standard » comme terme générique pour désigner les exigences de sécurité en matière de informatique en nuage au sens large, et classe chaque entrée en fonction de la manière dont elle est effectivement mise en œuvre (certification, attestation, réglementation, exigence contractuelle ou cadre de contrôle) plutôt que d’établir une distinction stricte entre les « normes » et les « cadres ».

Pourquoi les normes de sécurité dans le cloud sont-elles importantes ?

Il y a deux raisons à cela : cela garantit les revenus et limite les risques. De nombreux acheteurs professionnels ne signeront pas tant qu’un rapport SOC 2 ou un certificat ISO ne sera pas en leur possession. Et les autorités de régulation peuvent vous poursuivre pour des infractions au RGPD ou à la loi HIPAA, que vous disposiez ou non d’un certificat.

Pour les organisations soucieuses de conformité, les normes vont au-delà d'une simple déclaration d'intention. Elles traduisent le message « nous prenons la sécurité au sérieux » en un langage de contrôle qu'un régulateur, un auditeur ou une équipe chargée des achats peut réellement vérifier.

Retour à la réalité : Le fait de réussir un audit ne prouve pas que vos contrôles fonctionnent au quotidien entre deux audits. Les audits de surveillance ISO 27001 ont généralement lieu une fois par an, et une période d’observation SOC 2 de type II peut s’étendre sur la majeure partie de l’année. Entre ces points de contrôle, les retards de correctifs s’accumulent, les configurations dérivent et de nouveaux services sont mis en place en dehors du périmètre couvert par le dernier audit. Sans surveillance continue, bon nombre de ces problèmes ne seront pas détectés avant la prochaine évaluation. Notre liste des menaces de sécurité dans le cloud recense ce qui a tendance à s’accumuler pendant cette période.

Les 14 principales normes de sécurité dans le cloud

C'est la norme que vous visez qui détermine les mesures concrètes que vous devez prendre. C'est en confondant ces cinq types de normes que certaines équipes finissent par promettre à un client un « certificat ISO 27017 » qui n'existe pas en tant que tel, ou par affirmer à un auditeur qu'elles sont « certifiées NIST CSF », alors que le CSF ne propose aucune voie de certification.

1. ISO/IEC 27017 (édition 2026)

L'ISO et la CEI assurent conjointement la gestion de cette norme par le biais de leur comité technique mixte sur la sécurité de l'information, et l' édition 2026 constitue une véritable refonte, et non une simple mise à jour mineure. Publiée en juillet 2026, elle remplace intégralement la version originale de 2015 et aligne la norme sur la structure de contrôle ISO/IEC 27002:2022, en remplacement de la structure de 2013 sur laquelle elle reposait.

L' édition 2015 comportait sept contrôles supplémentaires liés au cloud, accompagnés de numéros CLD, portant notamment sur le renforcement de la sécurité des machines virtuelles et la restitution des actifs du client à l’expiration du contrat. L’édition 2026 réduit à quatre le nombre d’ajouts spécifiques au cloud : la répartition de base des responsabilités entre le fournisseur et le client, un accord sur les rôles et responsabilités de tout partenaire de services cloud impliqué, tel qu’un courtier ou un auditeur intervenant au sein de la chaîne d’approvisionnement, la ségrégation dans les environnements informatiques virtuels, ainsi que la détection et la prévention de toute utilisation non autorisée du cloud.

La plupart des recommandations restantes concernant le cloud se présentent désormais sous la forme de notes spécifiques au cloud, associées aux contrôles concernés de la norme ISO/IEC 27002:2022.

Comme auparavant, il n’existe pas de certificat distinct pour cette norme. Elle fait l’objet d’un audit dans le cadre d’une certification ISO/IEC 27001 dont le périmètre inclut les services cloud. Si votre documentation de conformité cite encore l’ancien ensemble de sept contrôles par leurs numéros CLD, elle fait référence à une structure obsolète, et un auditeur travaillant selon l’édition 2026 pourrait bien le signaler.

Ce document s'avère particulièrement utile pour les fournisseurs de services cloud qui souhaitent démontrer leur niveau de maturité en matière de contrôle aux entreprises clientes, ainsi que pour les clients qui souhaitent que la répartition des responsabilités dans le cadre d'une relation de cloud computing soit consignée de manière plus concrète qu'un simple entretien commercial.

2. SOC 2

La norme SOC 2 émane de l'AICPA et fonctionne différemment de la plupart des éléments figurant sur cette liste. Un cabinet d'expertise comptable agréé examine vos contrôles et émet un rapport d'avis. Il n'existe pas de label officiel « certifié SOC 2 », quoi qu'en laisse entendre la page d'accueil d'un fournisseur.

L'examen s'inscrit dans le cadre des critères des services de confiance de 2017, avec des points d’attention révisés publiés par l’AICPA en 2022 afin d’actualiser les recommandations à la lumière des nouvelles technologies et menaces. Les critères sous-jacents eux-mêmes n’ont pas changé depuis 2017. Il existe cinq catégories : la sécurité, la disponibilité, l’intégrité du traitement, la confidentialité et la protection de la vie privée. La sécurité est obligatoire dans chaque rapport SOC 2, et vous ajoutez les autres catégories en fonction de ce que vous vous êtes engagé à fournir à vos clients.

Les rapports de type I décrivent la conception des contrôles à un moment donné. Les rapports de type II décrivent l’efficacité opérationnelle sur une période donnée, généralement comprise entre trois et douze mois, et c’est ce type de rapport que les acheteurs d’entreprise demandent le plus souvent. Notre guide pour atteindre et maintenir la la conformité SOC 2 aborde le dilemme entre les engagements de disponibilité et les fenêtres de correction.

3. RGPD

RGPD, officiellement le règlement (UE) 2016/679, s’applique aux organisations établies dans l’UE, ainsi qu’aux organisations situées en dehors de l’UE qui proposent des biens ou des services à des personnes résidant dans l’UE ou qui surveillent le comportement de ces dernières. En ce qui concerne spécifiquement le cloud, la distinction entre le responsable du traitement et le sous-traitant revêt une importance capitale. Vous devez disposer d’un accord de traitement des données, de garanties documentées pour les transferts en dehors de l’Espace économique européen, ainsi que d’un processus permettant au responsable du traitement d’informer l’autorité de contrôle sans retard injustifié et, dans la mesure du possible, dans les 72 heures suivant la prise de connaissance d’une violation devant faire l’objet d’une notification. Les sous-traitants, quant à eux, doivent en informer les responsables du traitement sans retard injustifié.

Les amendes maximales peuvent atteindre 20 millions d’euros ou 4 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu.

4. HIPAA

La loi sur la portabilité et la responsabilité en matière d’assurance maladie (HIPAA) établit les principes fondamentaux de la protection des informations de santé aux États-Unis ; son application est assurée par le Bureau des droits civils du ministère américain de la Santé et des Services sociaux (HHS). À l’instar du RGPD, il s’agit d’une loi et non d’un cadre volontaire. Elle s’applique aux entités concernées (prestataires de soins de santé, régimes d’assurance maladie et centres d’échange d’informations de santé) ainsi qu’à leurs partenaires commerciaux. Un fournisseur de services cloud qui crée, reçoit, conserve ou transmet des informations de santé protégées sous forme électronique (ePHI) pour le compte d’une entité concernée est considéré comme un partenaire commercial, même s’il n’accède jamais à ces données.

Un accord de partenariat commercial (BAA) définit les responsabilités de chaque partie et impose contractuellement au prestataire de protéger les données de santé électroniques protégées (ePHI). Un prestataire de services cloud occupant ce rôle est également directement responsable du respect des exigences applicables de la loi HIPAA, et cette responsabilité ne dépend pas du BAA.

Les exigences techniques sont définies dans la règle de sécurité : contrôle d’accès, contrôles d’audit, intégrité, sécurité des transmissions et analyse des risques. Une proposition de mise à jour supprimerait la distinction actuelle entre les spécifications « obligatoires » et « facultatives » et rendrait obligatoires le chiffrement, l’authentification multifactorielle et un inventaire documenté des actifs technologiques, avec seulement quelques exceptions limitées. En octobre 2026, cette règle définitive n’avait toujours pas été publiée. Le programme réglementaire du HHS fixe désormais juillet 2027 comme date cible, après que la date initialement prévue de mai 2026 soit passée sans résultat.

5. PCI DSS

Le Conseil des normes de sécurité PCI en est l'éditeur, et la version actuelle est la v4.0.1. Bien que le terme « norme » figure dans son intitulé, son application relève d’un engagement contractuel. Ce sont votre banque acquéreuse et les réseaux de cartes qui veillent à son respect, et non une autorité de régulation gouvernementale.

Les dates importantes dans ce contexte sont déjà dépassées. La version 4.0 a introduit une série de nouvelles exigences, et les 51 d'entre elles dont la date d'entrée en vigueur était reportée sont devenues obligatoires le 31 mars 2025. Elles sont désormais toutes en vigueur, sans aucun délai de grâce sur lequel s'appuyer.

La norme PCI DSS comporte également l’une des exigences les plus explicites de cette liste en matière d’application des correctifs. L’exigence 6.3.3 stipule que les correctifs relatifs aux vulnérabilités critiques doivent être appliqués dans un délai d’un mois à compter de leur publication, tandis que tous les autres correctifs applicables doivent respecter un délai fixé par l’entité en fonction de sa propre évaluation des risques. La formulation initiale de la version 4.0 étendait brièvement ce délai d’un mois pour inclure également les correctifs de gravité élevée. Le Conseil est revenu à une application réservée aux vulnérabilités critiques dans la version 4.0.1, ce qui constitue l'exigence actuelle, plus restrictive. L'exigence 11.3.1 impose par ailleurs la réalisation de scans internes de vulnérabilités au moins une fois tous les trois mois et après tout changement significatif.

6. ISO/IEC 27001 (édition 2022)

Contrairement aux normes ISO/IEC 27017 et 27018, la norme ISO/IEC 27001 vous permet d'obtenir un véritable certificat à part entière. Un organisme de certification accrédité audite votre système de gestion de la sécurité de l'information et délivre un certificat valable trois ans, assorti d'audits de surveillance annuels visant à garantir sa conformité pendant cette période.

La révision de 2022 a profondément remanié l'annexe A, en ramenant le nombre de mesures de contrôle de 114 à 93 et en les regroupant en quatre thèmes. Onze nouvelles mesures de contrôle ont été introduites dans le cadre de cette restructuration, notamment celles relatives au renseignement sur les menaces, à la sécurité de l'information pour les services cloud et à la prévention des fuites de données.

La période de transition depuis l'édition 2013 a pris fin le 31 octobre 2025, et les certificats encore basés sur l'édition 2013 ne sont plus valides. Si votre organisation n'a pas effectué la transition, elle devra se soumettre à un nouvel audit de certification initial plutôt qu'à un audit de transition allégé.

7. ISO/IEC 27018 (édition 2025)

Gérée par le même comité ISO/IEC que la norme ISO/IEC 27017, cette norme présente une structure similaire. Elle ne donne pas lieu à une certification indépendante. Il s'agit d'un guide qui vient compléter un SMSI basé sur la norme ISO/IEC 27001, et certains organismes de certification l'évaluent parallèlement à un audit ISO/IEC 27001. Il en est désormais à sa troisième édition, publiée en août 2025 pour remplacer la version de 2019, avec des mesures de contrôle alignées sur la norme ISO/IEC 27002:2022 et l'ajout d'une nouvelle annexe B.

Alors que la norme 27017 traite de la sécurité du cloud de manière générale, la norme 27018 traite en profondeur un aspect précis : la protection des informations à caractère personnel (ICP) dans les clouds publics où le fournisseur agit en tant que sous-traitant de ces données. Cela inclut donc le consentement, la limitation de la finalité, la divulgation de tout sous-traitant, la transparence quant au lieu de traitement et de stockage des données, ainsi que leur suppression à la fin de la relation.

C'est la solution idéale pour les fournisseurs de cloud public qui recherchent un ensemble de mesures de protection de la vie privée reconnues, correspondant parfaitement aux obligations des sous-traitants prévues par le RGPD.

8. CSA STAR et la matrice des contrôles du cloud

La Cloud Security Alliance gère ces deux éléments, qu’il est facile de confondre. La « Cloud Controls Matrix » correspond au cadre de contrôle lui-même. STAR est le programme d’assurance qui s’appuie sur ce cadre. La version 4.1 de la CCM est sortie fin janvier 2026 avec 11 nouveaux contrôles, portant le total à 207 répartis sur les mêmes 17 domaines.

STAR comporte trois niveaux. Le niveau 1 consiste en une auto-évaluation gratuite s’appuyant sur le questionnaire CAIQ, dont les résultats sont publiés dans un registre public accessible à tous. Le niveau 2 ajoute une évaluation indépendante réalisée par un tiers, souvent menée parallèlement à une mission ISO 27001 ou SOC 2 déjà en cours. La CSA décrit également un niveau 3 fondé sur un audit continu, mais les entrées du registre que vous rencontrerez concrètement correspondent aux niveaux 1 et 2.

L'intérêt pratique réside dans le registre lui-même. Si vous évaluez un fournisseur de services cloud ayant publié des informations dans le cadre du référentiel STAR, ses réponses au questionnaire CAIQ sont accessibles au public et suffisamment précises pour permettre de les recouper avec le reste de ses justificatifs. N'oubliez pas toutefois que les réponses de niveau 1 sont déclarées par les entreprises elles-mêmes.

9. NIST SP 800-53 (version 5.2.0)

Le NIST publie ce document sous la forme d'un catalogue de contrôles plutôt que d'une certification, et il sert de référence pour les lignes directrices du programme FedRAMP ainsi que pour de nombreuses correspondances entre contrôles du secteur privé.

La version 5.2.0 a été publiée le 27 août 2025, et toute personne chargée de la gestion des correctifs devrait en prendre connaissance. Publiée en réponse à un décret fédéral sur la sécurité des mises à jour logicielles, elle apporte une amélioration de l'analyse des causes profondes des problèmes et défaillances du système, qui couvre les mises à jour ayant échoué (SI-02(07)), une amélioration de la syntaxe de journalisation (SA-15(13)) et un nouveau contrôle de conception en matière de cyber-résilience (SA-24).

Cette mise à jour considère le processus de déploiement des correctifs lui-même comme une surface d'attaque qu'il convient de sécuriser, et pas seulement les vulnérabilités que ce processus est censé corriger.

10. Cadre de cybersécurité 2.0 du NIST

Le NIST publie également ce document, dont la version 2.0 est parue en février 2024. Il s'agit d'un guide à caractère volontaire, sans parcours de certification ni auditeur à satisfaire.

CSF 2.0 a ajouté une sixième fonction, « Govern », aux cinq fonctions initiales : « Identify », « Protect », « Detect », « Respond » et « Recover ». Il a également élargi son champ d'application au-delà de l'accent mis sur les infrastructures critiques qui caractérisait la version 1.1, et s'adresse désormais aux organisations de toute taille et de tout secteur.

Considérez-le comme l'organigramme de votre programme de sécurité, avec les contrôles détaillés issus des normes 800-53, CIS ou CCM qui y sont associés. Le CSF n'est pas très efficace pour vous indiquer ce qu'il faut configurer, mais il est très utile pour vous signaler les éléments auxquels vous avez oublié d'attribuer un responsable.

11. FedRAMP

Géré par le bureau de gestion de projet (PMO) FedRAMP relevant de la GSA, FedRAMP autorise l'utilisation de services cloud par les agences fédérales américaines, et l'année 2026 a marqué sa plus grande refonte depuis des années.

FedRAMP a publié les Règles consolidées pour 2026 fin juin. Celles-ci sont entrées en vigueur le 4 juillet 2026, marquant le début d’une phase d’adoption anticipée, et FedRAMP 20x est appelé à remplacer progressivement la version Rev5. Le vocabulaire a évolué en même temps que la structure. Le terme « autorisation » est devenu « certification FedRAMP », les niveaux d’impact ont cédé la place aux classes de certification A à D, et les prestataires ne tiennent plus de plans d’action et de jalons (POA&M). Ils tiennent désormais à jour des registres de vulnérabilités et une liste des faiblesses acceptées, tandis que les agences peuvent toujours établir leurs propres POA&M pour les actions et les décisions en matière de risques qui leur sont propres.

Les dates à retenir dépendent de votre situation. Si vous êtes déjà titulaire d’une certification Rev5, les règles consolidées deviendront obligatoires le 1er janvier 2027, bien que certains ensembles de règles aient leurs propres dates d’entrée en vigueur et périodes de grâce, la dernière de ces périodes de grâce prenant fin le 1er février 2028. Si vous envisagez encore de déposer une demande Rev5, sachez que FedRAMP cessera d’accepter les nouvelles demandes le 11 juin 2027 ; après cette date, la seule voie possible sera la certification 20x. Si votre documentation mentionne encore « FedRAMP Moderate ATO », il s’agit de la terminologie Rev5, et la date limite qui s’applique à vous est le 1er janvier 2027, date à laquelle les règles consolidées deviendront obligatoires. Il reste du temps, mais pas beaucoup. 

La cryptographie certifiée FIPS reste d’actualité, même si les nouvelles règles en restreignent le champ d’application. FedRAMP exige désormais que le chiffrement FIPS 140 soit utilisé pour protéger les données sensibles et demande aux fournisseurs de préciser où ils l’utilisent, afin que les agences puissent évaluer son adéquation avec leurs propres systèmes. Sur AlmaLinux, le support TuxCare Enterprise fournit des mises à jour conformes à la norme FIPS pour l’ensemble complet des composants FIPS (noyau, OpenSSL, libgcrypt, NSS et GnuTLS) via les « Extended Security Updates » pour certaines versions mineures. AlmaLinux 9.2 et 9.6 disposent toutes deux de certificats CMVP actifs pour les cinq modules, le plus récent ayant été délivré en août 2026. 

12. Directive NIS 2

La NIS2, officiellement la directive (UE) 2022/2555, fonctionne différemment d’un règlement, car il s’agit d’une directive. La directive lie les États membres, mais les obligations qui incombent aux entreprises ne prennent effet qu’une fois que chaque État l’a transposée dans sa législation nationale, et ce processus s’est déroulé de manière inégale au sein de l’Union.

La date limite de transposition était fixée au 17 octobre 2024. En juillet 2026, la Commission européenne a saisi la Cour de justice de l’Union européenne à l’encontre de l’Irlande, de l’Espagne, de la France et des Pays-Bas pour ne pas avoir notifié la transposition complète de la directive, et a demandé à la Cour d’imposer des sanctions financières. Les Pays-Bas ont mis en vigueur leur loi sur la cybersécurité le 15 août 2026, tandis qu’à la mi-septembre, l’Irlande, l’Espagne et la France travaillaient encore sur la leur. La directive NIS2 étant une directive, les obligations des entités privées dépendent de la loi nationale de transposition de chaque État membre ; il convient donc de vérifier la législation nationale applicable plutôt que de supposer un effet direct uniforme. La directive NIS2 impose aux États membres de rendre les organes de direction responsables en vertu du droit national, et les règles nationales doivent prévoir des amendes pour les entités essentielles d’au moins 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu.

La directive NIS2 s'applique aux entités de 18 secteurs, notamment les fournisseurs de services de cloud computing, les prestataires de services de centres de données et les fournisseurs de services de sécurité gérés.

13. DORA

La loi sur la résilience opérationnelle numérique, le règlement (UE) n° 2022/2554, est entré en vigueur en janvier 2023 et est devenu pleinement applicable le 17 janvier 2025. Les autorités européennes de surveillance coordonnent sa mise en œuvre.

La directive DORA s'applique directement aux entités financières de l'ensemble de l'Union européenne et s'articule autour de cinq piliers : la gestion des risques liés aux technologies de l'information et de la communication (TIC), le signalement des incidents, les tests de résilience opérationnelle numérique, la gestion des risques liés aux tiers dans le domaine des TIC et le partage d'informations.

Le volet « tiers » est celui que les fournisseurs de services cloud ont tendance à négliger. Les entités financières doivent intégrer les exigences du règlement DORA dans leurs contrats informatiques, et tout fournisseur désigné comme « fournisseur tiers de services informatiques critiques » est placé sous la supervision directe d’un « superviseur principal » issu des autorités européennes de surveillance (AES). Cela signifie que le fait de vendre des infrastructures à des banques de l’UE peut vous faire entrer dans le champ d’application du règlement DORA, même si vous n’êtes pas vous-même une entité financière.

14. Référentiels CIS et contrôles CIS, version 8.1

Le Center for Internet Security publie ici deux ressources connexes : les « Controls », un ensemble de mesures de sécurité classées par ordre de priorité, et les « Benchmarks », qui constituent des références de configuration spécifiques à chaque plateforme. Aucune de ces deux ressources ne donne lieu à une certification au sens traditionnel du terme.

CIS Controls v8.1, publiée en juin 2024, regroupe 18 contrôles classés par ordre de priorité en trois groupes de mise en œuvre en fonction du risque, des ressources et de la complexité, afin qu’une petite équipe et une grande entreprise ne soient pas soumises aux mêmes attentes de départ. Les références CIS constituent l’équivalent au niveau de la configuration : il s’agit de guides de renforcement de la sécurité rédigés pour des plateformes spécifiques, notamment AWS Foundations, Azure Foundations, GCP, Kubernetes et principales distributions Linux.

Les benchmarks sont le moment où les normes cessent d'être abstraites et commencent à vous indiquer quels paramètres modifier. De nombreux outils de gestion de la sécurité dans le cloud intègrent d'emblée des contrôles basés sur les benchmarks CIS, ce qui en fait l'un des points de départ les plus simples de cette liste.

Pour AlmaLinux, le support TuxCare Enterprise comprend une assistance au renforcement de la sécurité qui met en correspondance les contrôles CIS et STIG avec des référentiels de conformité tels que PCI DSS et ISO 27001.

Meilleures pratiques pour la sécurité de l'informatique dématérialisée

Les normes vous indiquent ce que vous devez démontrer. Ces cinq pratiques constituent les moyens par lesquels les équipes produisent concrètement ces preuves.

Évaluations régulières de la sécurité

Réalisez des évaluations selon une fréquence définie, plutôt que de les limiter aux visites d'un auditeur. La fréquence varie selon les normes : certaines prévoient des cycles annuels, d'autres sont basées sur les risques et ne fixent pas d'intervalle précis. L'exigence 12.5.2 de la norme PCI DSS ajoute un exercice annuel de confirmation du périmètre, en plus de la fréquence que vous choisissez.

Les arguments économiques plaident en faveur de la poursuite de cette démarche. Le rapport 2026 d’IBM sur le coût des fuites de données estime le coût moyen d’une violation de données à l’échelle mondiale à 4,99 millions de dollars, soit une hausse de 12 % et un nouveau record qui inverse la brève tendance à la baisse observée l’année précédente.

La dérive de périmètre est le mode de défaillance à surveiller de près. Imaginez une équipe SaaS de 40 personnes qui met en place un environnement de test pour une migration, oublie de le désactiver et le laisse hors des limites définies pendant des mois.

Si une évaluation ne met en évidence aucun problème, c'est probablement que son champ d'application est trop restreint. Si elle identifie les trois mêmes problèmes chaque trimestre, le problème réside davantage dans la prise en charge des mesures correctives que dans la détection elle-même.

Analyse de la vulnérabilité

Effectuez des analyses authentifiées depuis l'intérieur de l'environnement, en complément de toute analyse externe. Les analyses externes non authentifiées ne détectent pas les vulnérabilités au niveau des paquets dans les charges de travail en cours d'exécution, alors que c'est là que se trouvent en réalité la plupart des failles exploitables.

La fréquence minimale varie considérablement selon la norme. La norme PCI DSS exige des analyses internes et externes tous les trois mois et après tout changement significatif ; les analyses externes requises doivent être effectuées par un prestataire d’analyse agréé. Les normes techniques de la DORA prévoient des analyses automatisées de vulnérabilité au moins une fois par semaine sur les actifs TIC prenant en charge des fonctions critiques ou importantes, des tests annuels des systèmes sous-jacents à ces fonctions, ainsi que des tests d’intrusion axés sur les menaces au moins tous les trois ans pour les entités désignées par leurs régulateurs. La mise à jour proposée de la loi HIPAA imposerait des analyses automatisées au moins tous les six mois et des tests d’intrusion au moins une fois par an. La version 8.1 des contrôles CIS exige des analyses automatisées des actifs internes au moins une fois par trimestre (mesure de protection 7.5) et des actifs exposés à l’extérieur au moins une fois par mois (mesure de protection 7.6). La directive NIS2 reste axée sur les risques et laisse à chaque État membre le soin de définir les modalités spécifiques.

Recouper les résultats avec le catalogue des vulnérabilités connues et exploitées de la CISA avant de hiérarchiser les mesures correctives. Un score CVSS pris isolément risque de faire passer inaperçue une vulnérabilité de 7,5 activement exploitée, noyée parmi une multitude de vulnérabilités théoriques notées 9,8 pour lesquelles aucune exploitation n'est connue.

Les règles de cadence ci-dessus partent du principe qu’un scanner signale avec précision ce qui a déjà été corrigé, mais sous Linux, cette hypothèse s’avère souvent erronée. Les distributions rétroportent les correctifs de sécurité sans modifier le numéro de version en amont, et un correctif appliqué en mémoire sans redémarrage peut ne pas apparaître du tout lors d’une vérification de la version d’un paquet. TuxCare Radar vérifie l’état réel des correctifs, y compris les correctifs sans redémarrage et ceux couverts par ELS qu’une simple vérification de version ne détecterait pas, afin qu’un cycle d’analyse ne se transforme pas en un rapprochement manuel entre les informations fournies par le scanner et celles de vos journaux de correctifs.

Contrôles d'accès stricts

Appliquer l'authentification multifactorielle sur tous les comptes humains disposant d’un accès à la console, sans exception pour les propriétaires de services ou les prestataires. La norme PCI DSS v4.x a étendu l’authentification multifactorielle au-delà des administrateurs à tous les accès à l’environnement de données des titulaires de carte, avec une exception limitée pour les comptes utilisant une authentification résistante au phishing, et la mise à jour proposée de la norme HIPAA va dans le même sens.

Au-delà de l'authentification multifactorielle (MFA), adoptez par défaut un modèle d'accès basé sur les rôles et le principe du « privilège minimal », et réexaminez-le au moins une fois par trimestre. Séparez les identités humaines et celles des machines, en veillant à ce qu'aucun identifiant de compte de service partagé ne figure dans les pipelines CI. Privilégiez les identifiants à durée de vie courte aux clés API à durée de vie longue dès lors que le fournisseur les prend en charge. Et documentez votre processus de gestion des arrivées, des mutations et des départs, car les auditeurs le vérifient systématiquement par échantillonnage.

Cryptage des données

Le chiffrement des données au repos et en transit doit constituer une exigence minimale. C'est la gestion des clés qui pose le plus souvent problème lors des audits : qui détient les clés, à quelle fréquence sont-elles renouvelées, et êtes-vous en mesure de préciser exactement ce que le fournisseur peut ou ne peut pas déchiffrer ?

Pour les charges de travail réglementées, la mise en œuvre est tout aussi importante que le choix de l’algorithme lui-même. Les systèmes fédéraux américains exigent généralement des modules cryptographiques validés selon la norme FIPS 140-3 dès lors qu’une cryptographie agréée est obligatoire, et les contrats commerciaux les exigent de plus en plus souvent également. TLS 1.2 constitue le minimum requis, et TLS 1.3 est l’objectif à atteindre dès lors que votre pile le prend en charge.

Attention : Le chiffrement au repos avec des clés gérées par le fournisseur répond à de nombreux critères de conformité, mais ce contre quoi il protège réellement, c’est l’exposition au niveau de la couche de stockage, comme le vol d’un disque ou la mise au rebut inappropriée d’un support. Il ne protège en rien contre la compromission d’un identifiant au sein de votre propre compte qui permet de déchiffrer les données. Les auditeurs insistent rarement sur cette distinction. Les attaquants l’exploitent systématiquement.

Corrections et mises à jour régulières

C'est là que la plupart des programmes de conformité dans le cloud s'effondrent discrètement. Les mesures de contrôle semblent simples sur le papier, mais s'avèrent difficiles à mettre en œuvre dans la pratique, car l'application d'un correctif sur un noyau en production implique généralement un redémarrage, et un redémarrage nécessite de négocier une fenêtre de maintenance avec tous ceux qui dépendent de la disponibilité du système.

L'horloge est explicitement mentionnée dans plusieurs normes :

Un délai de 30 jours peut sembler généreux, jusqu’à ce que l’on passe en revue toutes les étapes nécessaires : triage, test, planification, notification, redémarrage, vérification, documentation. Sur un parc de plusieurs centaines de serveurs soumis à des accords de niveau de service (SLA) en matière de disponibilité, cela peut prendre la majeure partie du mois avant même que le correctif ne soit déployé en production.

Réflexions finales

Choisissez d'abord vos normes en fonction des obligations légales, puis en fonction de la demande des clients, et arrêtez-vous là. Mettre en œuvre simultanément les normes ISO 27001, SOC 2 et CSA STAR simplement parce que la page « Confiance » d'un concurrent les mentionne toutes les trois, c'est ainsi que les petites équipes de sécurité perdent une année entière à rédiger de la documentation au lieu de se consacrer aux contrôles.

Une chose reste constante, quelles que soient les normes qui s'appliquent à vous. Presque toutes exigent que vous identifiiez et corrigez les vulnérabilités connues, et que vous disposiez de preuves que vous pouvez fournir sur simple demande. Le type de certification varie. La manière dont ces exigences sont appliquées varie également. Mais pour la plupart de ces programmes, c'est au niveau des opérations de correction que ces preuves sont soit fournies dans les délais, soit négligées.

Prise en charge illimitée tout au long du cycle de vie assure la continuité des mises à jour de sécurité pour les systèmes d’exploitation, les environnements d’exécution de langages et les bibliothèques en fin de vie après la fin du support du fournisseur. Ainsi, un composant non pris en charge peut continuer à bénéficier de correctifs au lieu de devenir une lacune de conformité persistante. Pour les dépendances open source utilisées par vos charges de travail cloud, SecureChain met à la disposition des équipes des registres privés filtrés pour les paquets JavaScript, Python, Java, Go, Rust et PHP, ce qui permet de mettre en œuvre les contrôles de chaîne d’approvisionnement décrits dans les normes ISO/IEC 27017 et CCM v4.1. TuxCare Enterprise Support couvre la cryptographie validée FIPS et le renforcement de la conformité souvent exigés par les environnements fédéraux et autres environnements réglementés. Et KernelCare applique les correctifs du noyau sans redémarrage ; ainsi, le respect des délais fixés par la norme PCI DSS et d’autres normes similaires ne dépend plus de l’approbation d’une fenêtre de maintenance. Vous continuez à tester, vérifier et documenter ces correctifs comme n’importe quel autre, mais le redémarrage n’est plus nécessaire.

Vous vous demandez quelles sont les normes applicables à votre environnement ou où se situent réellement les lacunes en matière de preuves dans votre programme de conformité ? Contactez un expert en sécurité de TuxCare.

Résumé

Nom de l'article

Les 14 principaux référentiels de normes de sécurité dans le cloud en 2026

Description

ISO 27017, SOC 2, FedRAMP, NIS2, DORA, et bien d'autres encore. Ce que chaque norme de sécurité du cloud vous impose en 2026 et comment elle est réellement appliquée.

Auteur

Rohan Timalsina

Nom de l'éditeur

de TuxCare

Logo de l'éditeur