Entrazure
Ce que « intégré à la conception » veut dire
Nous prenons la troisième voie : l’exigence est intégrée à l’architecture, et la preuve est un sous-produit du déploiement. L’architecture de sécurité est dirigée par un architecte certifié CISM.
La restriction de région est une politique, pas une préférence. Si le renseignement personnel doit rester au Canada, c’est imposé au niveau du groupe d’administration et chaque abonnement futur en hérite. Personne ne peut passer outre un vendredi après-midi. La tentative est refusée et journalisée : ce journal est la preuve.
L’accès est accordé par rôle et revu sur calendrier. Entra ID avec Privileged Identity Management : l’accès administratif permanent cesse d’exister, il est demandé, borné dans le temps, justifié et journalisé. Ce seul changement répond à une part disproportionnée de l’audit : voir cybersécurité et Entra ID.
Le changement est maîtrisé par le pipeline. Les changements arrivent en pull request, avec auteur, réviseur, résultat de test et horodatage. La gestion du changement cesse d’être un formulaire rempli après coup : c’est un enregistrement qui existe déjà.
La donnée est classifiée avant d’être protégée. Microsoft Purview pour le catalogue, les étiquettes de sensibilité et la prévention des pertes de données : on ne protège pas ce que personne n’a localisé.
La preuve s’exporte, elle ne s’assemble pas. Tableaux de conformité réglementaire de Defender for Cloud, état d’Azure Policy, requêtes Log Analytics et historique des pipelines, reliés aux contrôles de votre auditeur et exportables contrôle par contrôle.
Les cadres contre lesquels nous concevons
SOC 2 Type II. Les critères les plus coûteux : maîtrise du changement, accès logique, surveillance. Trois problèmes d’architecture. Nous relions les politiques et les barrières de pipeline au jeu de contrôles, pour que la fenêtre d’observation enregistre un système correct plutôt qu’une équipe diligente. Voir SOC 2.
HIPAA. Renseignements de santé isolés dans leur frontière d’abonnement, chiffrement en transit et au repos, points de terminaison privés, journalisation conservée pour la durée exigée, services couverts par l’entente de partenaire commercial. S’y ajoute le flux documenté : où le renseignement entre, où il repose et par où il sort. Voir HIPAA.
ISO 27001. Contrôles de l’annexe A projetés sur la configuration Azure, alignés sur votre système de management de la sécurité de l’information existant. Utile quand un client en fait une condition.
Loi 25. Résidence imposée par politique, registre des traitements, appui à l’évaluation des facteurs relatifs à la vie privée pour tout transfert hors Québec, rétention et suppression conçues plutôt qu’improvisées, détection d’incident et chemin de déclaration à la Commission d’accès à l’information défini d’avance. Détail sur Loi 25.
RGPD et HDS. Résidence européenne, transferts documentés, hébergement agréé des données de santé françaises.
Comment le mandat se déroule
Semaines 1 et 2, évaluation des écarts. Le parc actuel confronté au jeu de contrôles cible. Le livrable est une liste priorisée, avec un coût honnête par élément et une distinction entre le risqué et le désordonné : les confondre gaspille le budget.
Semaines 3 à 6, remédiation en code. Jeu de politiques, modèle d’identité, segmentation réseau, journalisation et rétention, déployés par pipelines, chaque changement relisible et réversible.
Semaines 7 et 8, la couche de preuve. Correspondance entre contrôle et artefact, requêtes d’export et tableaux de bord, procédure écrite pour l’auditeur.
Ensuite, la dérive. La conformité se dégrade. L’état des politiques et le score de sécurité sont surveillés : une dérive déclenche une alerte au lieu de resurgir au prochain audit, via l’Azure infogéré.
Ce que vous gardez
- Une matrice reliant chaque exigence à la configuration Azure qui la satisfait.
- Le jeu de politiques en code, dans votre dépôt.
- Les requêtes d’export et tableaux de bord produisant la preuve sur demande.
- Un schéma de flux des données réglementées, tenu à jour par le pipeline.
- Un registre des risques acceptés : ce que vous n’avez pas corrigé, et pourquoi. C’est la pièce que les auditeurs lisent vraiment.
Pour qui c’est
Des organisations qui affrontent un audit pour la première fois. Des entreprises de santé numérique et de technologie financière bloquées par le questionnaire de sécurité d’un grand client. Et toute organisation québécoise qui a lu la Loi 25 et compris qu’elle décrit son architecture, pas sa politique de confidentialité. La santé et les services financiers sont les plus exigeants.
Pour qui ce n’est pas
S’il vous faut un rapport SOC 2 au prochain trimestre sans architecture en place, nous ne pouvons pas vous aider dans ce délai, et nous le dirons au premier appel. Les cabinets qui le promettent vendent un document, et c’est dans l’écart entre le document et le système que naissent les incidents.
Et si votre direction refuse la friction de l’accès privilégié borné dans le temps et de la revue par pull request, la conformité restera documentaire.
Pages liées
- Landing zone Azure, là où les politiques s’appliquent.
- Cybersécurité et Entra ID, le volet identité.
- Azure et IA pour la santé, le secteur le plus exigeant.
- Vue d’ensemble de la conformité.
Questions fréquentes
Pouvez-vous nous faire certifier SOC 2 ?
Non. Seul un cabinet comptable habilité peut émettre un rapport SOC 2, et nous ne voudrions pas être à la fois le constructeur et l’auditeur. Ce que nous faisons, c’est rendre l’audit sans histoire : les contrôles sont appliqués par Azure Policy et par le pipeline, et la preuve s’exporte au lieu de se reconstituer. Nos clients arrivent à l’audit avec les artefacts déjà en main.
Combien de temps avant d’être prêts pour l’audit ?
Pour une organisation déjà sur Azure avec un parc raisonnablement propre, six à douze semaines de travail d’architecture avant l’ouverture de la fenêtre d’observation. Si l’identité n’est pas gérée ou si la maîtrise du changement est informelle, c’est plus long, et ces deux points-là sont presque toujours le vrai écart, pas le chiffrement ni les pare-feu.
Azure est-il conforme à HIPAA d’emblée ?
Aucune plateforme n’est conforme à elle seule. Microsoft signe une entente de partenaire commercial couvrant les services visés, ce qui est nécessaire mais pas suffisant. La conformité dépend de la façon dont vous segmentez les renseignements de santé, des services que vous utilisez, de l’octroi et de la revue des accès, et de ce que vous journalisez. Cette configuration, c’est le travail.
Qu’exige réellement la Loi 25 de notre architecture ?
En termes d’architecture : savoir où résident les renseignements personnels, pouvoir justifier tout transfert hors Québec par une évaluation des facteurs relatifs à la vie privée, pouvoir produire et supprimer les données d’une personne sur demande, et pouvoir détecter puis déclarer un incident de confidentialité à la Commission d’accès à l’information. Chacun se traduit par du concret : inventaire des données, politique de région, conception de la rétention, journalisation et alertes.
Nous avons déjà passé un audit. Pourquoi ceci ?
Passer une fois avec une preuve manuelle veut généralement dire que quelqu’un a passé six semaines à assembler des captures d’écran. La vraie question est de savoir si la deuxième année coûtera autant. Quand la preuve est produite par le pipeline, le coût récurrent tend vers zéro et les contrôles cessent de dériver entre deux audits.
Travaillez-vous avec notre auditeur ou notre outil de GRC ?
Oui. Nous construisons contre le jeu de contrôles sur lequel vous êtes évalués, et nous exportons dans le format qu’attend votre auditeur ou votre plateforme. Nous n’avons pas de cabinet d’audit préféré et nous ne touchons aucune commission d’apporteur d’affaires, ce qui est délibéré.
Une question sur ce mandat ?
Trois champs. Un architecte le lit et répond en un jour ouvrable.