Managed Identity — le passwordless par application

Vous êtes ici : Référence — l’identité des applications elles-mêmes. Comment les apps se connectent à SQL et au Storage sans aucun secret — une identité par unité de déploiement. Lecture 8 min. Audience : devs, auditeurs sécurité. Date : 2026-07-07 | Version : 1.0 — remplace le stub (matière : code @gs/db/@gs/storage, bicep, migrations, docs/standards/AUTH.md, ADR-033/057/060/065)

Le principe central

Un mot de passe, ça se copie, ça se colle dans une config, ça fuit. Une Managed Identity, c’est une identité que la plateforme Azure attache à l’unité de déploiement elle-même : l’app est quelqu’un, prouvé par la plateforme — rien à stocker, rien à faire tourner, rien à faire fuiter. GS-Apps applique ce principe à toute la flotte : une identité par app, et des jetons renouvelés automatiquement.

TL;DR

Question	Réponse
Un mot de passe SQL quelque part ?	Non — SQL_USE_MANAGED_IDENTITY=true posé par l’infrastructure, connexion azure-active-directory-default
Qui renouvelle les jetons ?	Le driver (tedious + DefaultAzureCredential) à chaque connexion physique du pool — zéro code maison
Quelle identité pour qui ?	Apps web : system-assigned (une chacune) ; worker ETL : user-assigned dédiée ; Storage : même principe, SAS user-delegation
Et côté base ?	CREATE USER … FROM EXTERNAL PROVIDER versionné en migrations — permissions as code
Tout est en MI ?	Non — trois exceptions assumées : SOFI (système externe, compte dédié lecture seule), le CI d’initialisation BD, le dev local

1. Le problème réglé à la racine

Historiquement, les applications partageaient un compte SQL à privilèges élevés, mot de passe en clair dans la configuration — l’anti-pattern classique des premiers déploiements (rotation pénible, fuite possible par logs ou capture d’écran, aucune traçabilité par application). La migration Managed Identity (ADR-033, avril 2026) a remplacé ce partage : chaque application se présente à la base sous son propre nom, et les journaux SQL savent qui fait quoi.

2. Comment ça marche

1. L’infrastructure (module Bicep unique des apps) crée l’App Service avec son identité (SystemAssigned) et pose SQL_USE_MANAGED_IDENTITY=true — c’est une convention d’infrastructure, pas un choix par app.
2. Le connecteur SQL (@gs/db) ouvre le pool en mode azure-active-directory-default : le driver obtient un jeton Entra via DefaultAzureCredential à chaque connexion physique du pool, et le renouvelle tout seul.
3. En développement local, la même config retombe sur un compte SQL classique — branche explicitement étiquetée dev only.

La chaîne passwordless, rejouée à chaque connexion du pool : le driver demande un jeton frais (1-2-3) et l’ouverture SQL s’ensuit (4) — rien à faire tourner à la main.

Le piège du jeton statique — verrouillé par l'outillage

La première tentative de migration utilisait un jeton acquis au démarrage (azure-active-directory-access-token) : les jetons Entra expirant, le pool plantait après quelques heures (ELOGIN: Token is expired, observé en production en avril 2026). Depuis, un audit statique automatisé (npm run audit:mi-auth) interdit ce pattern dans le code — la leçon est outillée, pas seulement documentée.

3. Qui a quelle identité

Unité	Identité	Pourquoi
Apps web (hub, admin, ug, inv, mcp, api-portail)	System-assigned, une par app	Cycle de vie lié à l’app ; provisionnée par le module Bicep unique (ADR-065)
Worker ETL (gs-etl-worker)	User-assigned dédiée, partagée par ses deux jobs (file + horaire) et par le déclencheur de file	L’ETL a sa propre identité — jamais celle d’une app web (fin du cumul de privilèges historique de l’app admin)
Accès Storage (@gs/storage)	Même identité que l’app appelante, via DefaultAzureCredential	Aucune clé de compte ; URLs signées en SAS user-delegation (dérivées du jeton Entra, plafonnées à 7 jours) — ADR-057

4. Côté base — permissions as code

L’identité ne suffit pas ; il faut lui accorder des droits, et ces droits sont du code (ADR-060) :

• Chaque identité est créée en base par une migration versionnée — CREATE USER … FROM EXTERNAL PROVIDER idempotent, suivie de GRANT explicites (exemple : la Console UG reçoit SELECT, INSERT, UPDATE sur son schéma — pas DELETE, le soft delete étant la règle).
• Un manifeste canonique décrit qui a le droit de toucher quel schéma, avec les exceptions documentées et justifiées (ex. : l’outil MCP reste lecteur global par conception — il consulte tout schéma présent et futur, borné en lecture seule par un garde SQL).
• Un contrôle de dérive en CI compare l’état réel de la base au manifeste.

État réel vs cible — dit honnêtement

Le modèle cible est le moindre privilège par schéma. L’état déployé actuel des identités runtime est encore aux rôles globaux lecture/écriture ; la bascule fine est en cours, et le contrôle de dérive tourne en mode avertissement d’ici là. Autrement dit : le passwordless est fait, le per-schema est versionné et en déploiement — pas encore accompli partout.

5. Ce qui n’est pas en Managed Identity (assumé)

Exception	Pourquoi
SOFI (ERP source)	Système externe hors d’Azure — compte dédié lecture seule, secrets injectés par l’infrastructure, jamais dans le dépôt
CI d’initialisation BD	Le pipeline db:init utilise un compte SQL dédié (le DDL exige des privilèges qu’aucune MI runtime ne doit porter) ; la cible versionnée est un principal fédéré OIDC — pas encore provisionné
Dev local	Compte SQL classique, branche explicitement dev only

Parité infra ↔ code, prouvée par un test

Un test de contrat (@gs/standards) compile le module Bicep des apps et vérifie que les App Settings posés satisfont exactement le schéma de configuration du code (@gs/config) — y compris SQL_USE_MANAGED_IDENTITY=true et la simulation d’un démarrage réel. Une dérive infra/code casse le CI avant de casser la production.

Pour aller plus loin

• Stratégie d’authentification — le Cas 4 (service-to-service) dans le paysage global.
• Sécurité — la posture passwordless dans son ensemble.
• Architecture de données — la convention de connexion unique et son test de contrat.
• ADR-033 — Managed Identity SQL