Entrazure
Ce que le SOC 2 exige réellement d’une architecture
Les critères des services de confiance ne sont pas une spécification technique. Ce sont des énoncés de résultat, et c’est un cabinet comptable qui juge si votre système les atteint. En pratique, le poids se concentre à quelques endroits.
L’accès logique (CC6). Comment les identités sont créées, accordées, revues et retirées. Comment l’accès privilégié est restreint. Si l’authentification est imposée partout, y compris pour les principaux de service et les comptes de secours. Ce critère génère plus d’exceptions que tous les autres, et presque toutes sont architecturales.
La gestion du changement (CC8). Si les changements d’infrastructure et d’application sont autorisés, testés, approuvés et consignés avant d’atteindre la production. L’auditeur échantillonne des changements dans la fenêtre et demande la trace. Si la trace est un billet rédigé après coup, l’échantillon échoue.
L’exploitation et la surveillance (CC7). Si vous détectez les vulnérabilités et les anomalies, si les alertes atteignent un humain, et si les incidents sont traités selon un processus qui existait avant l’incident.
L’évaluation des risques et le suivi des contrôles (CC3, CC4). Si quelqu’un vérifie entre deux audits que les contrôles fonctionnent toujours. Le mode de défaillance ici, c’est la dérive.
Si vous ajoutez le critère de disponibilité, la sauvegarde et la restauration deviennent des affirmations vérifiables. Si vous ajoutez la confidentialité, la classification et la destruction entrent dans la portée. Chaque critère optionnel ajoute du travail réel : choisissez-les en fonction de ce que vos clients demandent, pas en cochant les cinq.
Le point structurant : le type II atteste l’efficacité opérationnelle sur une durée. Le système doit se comporter correctement pendant des mois sans que personne n’ait à y penser. C’est un problème de conception, pas de documentation.
Ce que nous concevons et imposons dans Azure
L’identité, pour que CC6 cesse de produire des exceptions. Microsoft Entra ID avec accès conditionnel imposant l’authentification multifacteur et l’état de l’appareil, Privileged Identity Management pour qu’aucun rôle d’administration ne soit détenu en permanence (l’accès est demandé, justifié, limité dans le temps et journalisé), des revues d’accès planifiées sur les groupes privilégiés, et des identités de charge de travail à identifiants fédérés plutôt que des secrets clients dans une variable de pipeline. Les comptes de secours existent, sont exclus des politiques qui pourraient vous verrouiller dehors, et déclenchent une alerte à chaque usage.
Un jeu de politiques qui refuse au lieu de constater. Azure Policy assigné au groupe d’administration : version minimale de TLS, aucun accès réseau public sur le stockage, SQL et Key Vault, paramètres de diagnostic obligatoires, étiquettes de propriétaire et de classification requises, régions autorisées. Auditer une violation, c’est préparer une constatation ; la refuser, c’est un contrôle.
Le contrôle du changement dans le pipeline. Infrastructure en Terraform ou Bicep dans un dépôt avec protection de branche, réviseurs obligatoires, sortie du plan attachée à la demande de tirage, et approbations d’environnement pour la production. L’écriture dans le portail de production est retirée, pas déconseillée. Une vérification de dérive s’exécute périodiquement, donc un changement manuel devient une alerte au lieu d’une constatation six mois plus tard.
Une surveillance qui atteint quelqu’un. Diagnostics vers Log Analytics avec une rétention assumée, Microsoft Defender for Cloud pour la posture et les vulnérabilités avec un délai de correction convenu par sévérité, et des règles Microsoft Sentinel acheminées vers une véritable rotation de garde plutôt que vers une boîte partagée.
La disponibilité, si elle est dans la portée. Politiques de sauvegarde en code, objectifs de reprise écrits, et tests de restauration planifiés et consignés. Une sauvegarde non testée est un contrôle non testé.
C’est le même socle que celui décrit sur la page conformité et appliqué sur la landing zone Azure. Le travail SOC 2, c’est la cartographie et la preuve, pas une construction parallèle.
La preuve que produit le pipeline
- L’état de conformité Azure Policy par assignation et par ressource, horodaté, rattaché au critère qu’il satisfait.
- Le tableau de conformité réglementaire Defender for Cloud pour le SOC 2, suivi sur toute la fenêtre plutôt que capturé un seul jour.
- L’historique d’activation PIM : qui a élevé ses droits, vers quel rôle, combien de temps, avec quelle justification. Cet export à lui seul répond à une large part des demandes CC6.
- Les résultats des revues d’accès par trimestre, avec le réviseur et les décisions.
- Les journaux de connexion et d’accès conditionnel, y compris les échecs d’authentification multifacteur.
- L’historique des demandes de tirage et des déploiements : auteur, réviseur, horodatage d’approbation, exécution du pipeline, résultat des tests, environnement.
- Les chronologies d’alertes et d’incidents, avec les délais de prise en charge.
- Les vulnérabilités et leurs dates de correction, mesurées contre le délai que vous avez annoncé.
- Les journaux de sauvegarde et les tests de restauration, si la disponibilité est visée.
Ce que vous gardez
- Une matrice de contrôles reliant chaque critère à la configuration Azure qui le satisfait et à la requête qui le prouve.
- Le jeu de politiques et la landing zone en code, dans votre dépôt.
- Un jeu de requêtes KQL enregistré dans votre espace Log Analytics, une requête par demande de preuve.
- Un runbook d’audit : quel export répond à quelle demande, qui l’exécute, en combien de temps.
- Un registre écrit des risques acceptés et des contrôles compensatoires, pour que la discussion avec l’auditeur parte de votre position.
Pour qui
Les éditeurs de logiciels, les entreprises de santé numérique et de technologie financière bloqués par la revue de sécurité d’un client grand compte. Les organisations qui détiennent un type I et doivent traverser la fenêtre de type II. Les équipes dont le deuxième audit a coûté autant que le premier, ce qui signifie que la preuve était manuelle.
Pour qui ce n’est pas
S’il vous faut un rapport de type II dans soixante jours et que le parc n’a ni jeu de politiques, ni modèle d’identité, ni pipeline, nous ne pouvons pas aider dans ce délai et nous le dirons au premier appel. Si vous voulez déployer une plateforme GRC en laissant l’architecture intacte, vous obtiendrez un tableau de bord qui affiche des contrôles inexistants. Et si vous souhaitez que le même cabinet construise les contrôles et les atteste, personne ne devrait vous vendre ça.
Aller plus loin
- Architecture de conformité, la mission qui livre ce travail.
- ISO 27001 sur Azure, où le même socle se rattache à l’annexe A.
- HIPAA sur Azure, quand la donnée visée est de santé.
- Landing zone Azure, où vit le jeu de politiques.
- Conformité, le pilier.
Questions fréquentes
Pouvez-vous nous rendre certifiés SOC 2 ?
Le certificat SOC 2 n’existe pas. Un cabinet comptable agréé émet un rapport d’attestation, et lui seul peut le faire. Nous construisons le système que le rapport décrit et nous produisons la preuve que l’auditeur échantillonne. Nous ne touchons aucune commission d’un cabinet d’audit, et c’est délibéré.
Type I ou type II d’abord ?
Le type I atteste la conception à un moment donné et peut être émis quelques semaines après la correction. Le type II atteste l’efficacité opérationnelle sur une fenêtre, généralement de trois à douze mois. Si un client bloque une entente, le type I achète du temps. Si personne n’attend, visez directement une courte fenêtre de type II plutôt que de payer deux audits.
Quand ouvrir la fenêtre d’observation ?
Après la correction, jamais pendant. Chaque contrôle qui échoue à l’intérieur de la fenêtre devient une exception échantillonnée dans votre rapport, et les exceptions sont ce que l’équipe de sécurité d’un prospect lit en premier. Deux mois de plus avant l’ouverture coûtent bien moins cher qu’un rapport avec réserve.
La moitié de notre production a été bâtie à la main dans le portail. Est-ce un problème ?
Oui, et c’est le plus fréquent. Les critères de gestion du changement demandent qui a approuvé un changement et quand. Une ressource créée dans le portail à 23 h n’a ni auteur, ni réviseur, ni trace. Nous réconcilions d’abord le parc dans le code, ensuite le registre du changement existe par construction.
Travaillez-vous avec notre plateforme GRC et notre auditeur ?
Oui. Nous construisons vers le référentiel sur lequel vous êtes mesurés et nous exportons dans le format attendu par votre plateforme ou votre auditeur. Nous n’avons pas de cabinet d’audit favori.
Combien coûte la deuxième année ?
C’est la vraie question. Si la preuve est exportée depuis Azure Policy, PIM et l’historique du pipeline, l’effort récurrent se compte en jours. Si elle est assemblée à partir de captures d’écran, la deuxième année coûte ce qu’a coûté la première, et ainsi de suite chaque année.
Une question sur ce mandat ?
Trois champs. Un architecte le lit et répond en un jour ouvrable.