Entrazure
Ce que la norme exige réellement d’une architecture
Les clauses 4 à 10 définissent le système de management : périmètre, méthode d’appréciation du risque, objectifs, compétences, audit interne, revue de direction, actions correctives. Cette moitié relève de la documentation et de la gouvernance, et ce n’est pas à nous de l’écrire.
L’annexe A est l’autre moitié. La révision 2022 l’a restructurée en 93 mesures réparties en quatre thèmes : 37 organisationnelles, 8 relatives aux personnes, 14 physiques, 34 technologiques. Votre déclaration d’applicabilité indique lesquelles s’appliquent, et l’organisme de certification échantillonne à partir de là. Les mesures physiques du centre de données relèvent de Microsoft dans le modèle de responsabilité partagée. Le thème technologique est presque entièrement à vous, et c’est de l’architecture.
Les mesures qui décident d’un audit d’étape 2 en contexte infonuagique sont constantes :
- A.5.15 à A.5.18 et A.8.2 à A.8.5, la famille du contrôle d’accès : cycle de vie des identités, droits privilégiés, restriction d’accès à l’information, authentification sécurisée.
- A.8.9 gestion des configurations, nouvelle comme mesure nommée en 2022. L’auditeur demande votre référence de configuration et la façon dont vous détectez les écarts.
- A.8.15 journalisation et A.8.16 activités de surveillance, la seconde également nouvelle. Journaliser sans surveiller est une mesure à moitié mise en œuvre, et c’est consigné comme tel.
- A.8.20 sécurité des réseaux et A.8.22 cloisonnement des réseaux. La topologie est ce qu’un auditeur technique examine en premier, parce qu’elle est difficile à simuler.
- A.8.24 utilisation de la cryptographie. Notez la formulation : une politique d’utilisation de la cryptographie, qui nomme les algorithmes, les longueurs et la durée de vie des clés. Le chiffrement activé n’est pas la mesure.
- A.8.10 suppression d’informations et A.8.11 masquage des données, toutes deux nouvelles, et le point le plus faible de la plupart des parcs : des environnements hors production remplis de copies de la production que personne ne sait supprimer sur demande.
- A.8.32 gestion des changements et A.8.28 codage sécurisé, auxquels le pipeline répond ou non.
- A.5.23 sécurité de l’information pour l’utilisation de services infonuagiques, qui est une question sur la façon dont les souscriptions sont provisionnées, gouvernées et retirées.
- A.5.30 préparation des TIC pour la continuité, testée et non affirmée.
Ce que nous concevons et imposons dans Azure
Une initiative de politiques dessinée d’après votre déclaration d’applicabilité. Nous ne déployons pas une base générique en l’appelant conformité. Chaque mesure applicable ayant une expression technique reçoit une assignation Azure Policy au niveau du groupe d’administration, et chaque assignation porte la référence de la mesure, pour que la cartographie survive au roulement de personnel.
L’identité comme famille de contrôle d’accès. Microsoft Entra ID avec accès conditionnel, Privileged Identity Management pour que les droits privilégiés soient activés plutôt que détenus, des revues d’accès planifiées produisant des enregistrements datés, et des identités de charge de travail à identifiants fédérés plutôt que des secrets à longue durée de vie.
L’infrastructure en code comme référence de configuration. Terraform ou Bicep dans un dépôt avec protection de branche et réviseurs obligatoires. La référence, c’est le dépôt ; l’écart est détectable par une vérification de dérive planifiée ; A.8.9 et A.8.32 cessent d’être un récit. C’est la même fondation que celle décrite sur la page landing zone Azure.
Un cloisonnement qui répond à A.8.20 et A.8.22. Hub-and-spoke, Azure Firewall ou équipement équivalent, groupes de sécurité réseau avec justification documentée, points de terminaison privés sur les services de données, zones DNS privées. Le schéma est la preuve.
Journalisation et surveillance comme deux mesures, pas une. Diagnostics vers Log Analytics avec une rétention assumée, règles Microsoft Sentinel et une garde réelle pour A.8.16, Microsoft Defender for Cloud pour la gestion des vulnérabilités sous A.8.8, et le renseignement sur les menaces alimentant les détections pour A.5.7.
Une politique cryptographique, écrite et imposée. Key Vault ou Managed HSM, algorithmes et durées de vie nommés, calendriers de rotation, et Azure Policy refusant les ressources qui n’utilisent pas les clés que la politique désigne.
La suppression et le masquage pris au sérieux. Règles de cycle de vie sur le stockage, rétention par catégorie, jeux de données dépersonnalisés hors production, et un chemin de suppression testé. A.8.10 est là où nous trouvons le plus de surprises, et là où passe l’essentiel du temps de correction.
Une continuité qui a été testée. Politiques de sauvegarde en code, objectifs de reprise écrits, restaurations planifiées et consignées, et des runbooks de bascule que quelqu’un a réellement exécutés.
La preuve que produit le pipeline
- Votre déclaration d’applicabilité, augmentée d’une colonne nommant l’assignation Azure qui met en œuvre la mesure et la requête qui la prouve.
- L’état de conformité Azure Policy par assignation, exportable par référence de mesure.
- Le tableau de conformité réglementaire Defender for Cloud pour l’initiative ISO 27001, suivi sur tout le cycle de surveillance.
- Les revues d’accès, l’historique PIM et les rapports d’accès conditionnel.
- L’historique des demandes de tirage et des déploiements, comme registre du changement sous A.8.32.
- Les vulnérabilités et leurs dates de correction, contre les délais que vous avez annoncés.
- Les tests de restauration et de bascule pour A.5.30 et A.8.13.
- Les alertes de dérive et leur résolution, qui alimentent les actions correctives de la clause 10 avec du contenu réel plutôt qu’inventé.
Ce que vous gardez
- La cartographie déclaration d’applicabilité vers Azure, maintenue comme un fichier dans votre dépôt et non comme un tableur sur un portable.
- L’initiative de politiques en code, annotée des références de mesures.
- Une politique cryptographique écrite et le cycle de vie des clés qu’elle décrit.
- Le jeu de requêtes de preuve et le runbook qui nomme qui exécute quel export.
- Les enregistrements des tests de continuité et le calendrier qui continue après notre départ.
- Un registre de risques aligné sur votre méthode de clause 6.1, risques acceptés compris.
Pour qui
Les organisations dont un client européen ou grand compte a fait du certificat une condition contractuelle. Les entreprises déjà certifiées sur un périmètre sur place dont l’audit de surveillance atteint maintenant Azure. Les équipes passées à la révision 2022 qui n’ont pas encore traité les mesures qu’elle ajoute. Les entreprises détenant un SOC 2 qui veulent le second cadre sans payer une seconde construction.
Pour qui ce n’est pas
Si vous voulez faire rédiger la documentation du SMSI, nous sommes le mauvais cabinet : nous faisons la moitié architecture, et il vous faut un auditeur principal ou un consultant SMSI pour le système de management. Si vous voulez un certificat en huit semaines, la séquence étape 1 et étape 2 ne se comprime pas à ce point. Et si personne ne réclame ISO 27001, vérifiez d’abord si un SOC 2 satisfait le client, parce qu’il coûte généralement moins cher à atteindre.
Aller plus loin
- Architecture de conformité, la mission qui livre ce travail.
- SOC 2 sur Azure, le référentiel qui se recoupe le plus.
- RGPD et HDS, où ISO 27001 est un prérequis plutôt qu’une option.
- Landing zone Azure, où l’initiative de politiques s’applique.
- Conformité, le pilier.
Questions fréquentes
Êtes-vous certifiés ISO 27001 ?
Non, et nous ne le laisserons pas croire. Notre architecture de sécurité est dirigée par des architectes certifiés en sécurité de l’information et nous construisons vers la norme, mais Entrazure ne détient pas de certificat ISO 27001. Demandez à tout fournisseur qui en revendique un le numéro du certificat et l’organisme accrédité qui l’a émis.
Pouvez-vous nous certifier ?
Non. Les certificats sont émis par des organismes accrédités pour le schéma, après un audit d’étape 1 sur la documentation et un audit d’étape 2 sur la mise en œuvre. Nous construisons le système qu’ils auditent. Un cabinet qui corrige et certifie à la fois ne vous offre pas un certificat indépendant.
ISO 27001 ou SOC 2 ?
Demandez-le au client qui bloque l’entente. Les achats européens et grands comptes nomment généralement ISO 27001. Les équipes de sécurité nord-américaines nomment généralement SOC 2. Le travail Azure sous-jacent se recoupe largement, donc le second cadre relève surtout de la cartographie et du format de preuve.
Quelle part de la norme relève de l’architecture ?
L’annexe A de la révision 2022 compte 93 mesures réparties en quatre thèmes. Les 34 mesures technologiques sont presque entièrement architecturales, et une bonne part des 37 mesures organisationnelles exige une preuve architecturale. Les clauses du système de management (périmètre, méthode de risque, audit interne, revue de direction) ne sont pas à nous d’écrire.
Qu’est-ce que la révision 2022 change pour un parc infonuagique ?
Elle nomme ce qui était implicite. Gestion des configurations, activités de surveillance, suppression d’informations, masquage des données, prévention de fuite, codage sécurisé, renseignement sur les menaces et sécurité pour l’usage de services infonuagiques deviennent des mesures explicites. L’infrastructure en code répond à la gestion des configurations mieux qu’aucun document.
Nous sommes déjà certifiés. Pourquoi revoir le parc Azure ?
Parce qu’un certificat a un périmètre et qu’un parc infonuagique dérive. Le cas typique : un certificat rédigé quand tout était sur place, un audit de surveillance qui interroge maintenant Azure, et aucun jeu de politiques derrière la réponse. Corriger avant la visite coûte moins cher qu’une non-conformité.
Une question sur ce mandat ?
Trois champs. Un architecte le lit et répond en un jour ouvrable.