AGOV dans le Business Continuity Management : l’authentification en situation de crise
Une solution d’authentification hautement disponible est importante. Pour les tâches étatiques particulièrement critiques, la haute disponibilité ne suffit toutefois pas à elle seule. Voir aussi la vidéo « Dégradation d’AGOV pour les exigences en dehors de la situation normale ».
Lorsqu’une application spécialisée doit continuer à fonctionner même pendant une crise grave, il ne suffit pas de savoir dans quelle mesure son authentification est fiable. Il faut également déterminer ce qui se passe lorsque :
- certaines infrastructures de communication ne sont plus disponibles,
- AGOV lui-même est indisponible ou
- le système de destination ne peut finalement plus être exploité.
AGOV permet donc de mettre en place un modèle de résilience à plusieurs niveaux.
Son principe de base est simple :
AGOV doit pouvoir fournir aussi longtemps que possible une authentification sûre aux systèmes de destination critiques, même dans des conditions défavorables. En même temps, les systèmes particulièrement critiques ne doivent pas dépendre d’une disponibilité permanente d’AGOV.
AGOV ne devient ainsi pas un point de défaillance unique, mais un élément d’une architecture plus globale d’IT Service Continuity Management et de Business Continuity Management.
Il faut d’abord déterminer ce qui est réellement critique
Toutes les applications n’ont pas besoin d’une telle architecture.
Le point de départ est donc l’analyse des besoins de protection et de la criticité du système de destination. Pour chaque service, il faut déterminer :
combien de temps il est possible de s’en passer ;
- combien de temps il est possible de s’en passer ;
- quelles seraient les conséquences d’une interruption prolongée ;
- quelles dépendances doivent continuer à fonctionner même en situation de crise.
Il en résulte des exigences différentes.
Pour de nombreuses applications spécialisées, il suffit qu’AGOV lui-même soit exploité avec une haute disponibilité. Pour certains systèmes particulièrement critiques, il faut en revanche partir du principe que des composants centraux de l’infrastructure peuvent eux aussi tomber en panne.
Ce n’est que pour ces systèmes qu’une architecture à plusieurs niveaux, telle que décrite ci-après, est nécessaire.
Modèle de résilience à plusieurs niveaux
Niveau 1 : maintenir AGOV disponible aussi longtemps que possible
La première ligne de défense est la résilience d’AGOV lui-même.
Une infrastructure centrale d’authentification ne doit pas dépendre d’un seul centre de calcul ou d’un seul domaine d’infrastructure.
L’architecture cible prévoit donc un fonctionnement active-active séparé sur les plans géographique et infrastructurel, dans lequel une partie de l’infrastructure AGOV peut être exploitée en dehors de l’infrastructure régulière de l’administration fédérale.
La défaillance d’un domaine d’infrastructure ne doit ainsi pas entraîner automatiquement la défaillance de l’authentification.
Cette approche protège contre les pannes techniques classiques, mais elle a également une dimension de politique de sécurité : en situation extraordinaire, les infrastructures centrales de la Confédération peuvent elles-mêmes devenir la cible de cyberattaques.
La résilience ne signifie donc pas seulement la redondance au sein d’un même environnement, mais aussi, dans la mesure du possible, l’évitement de causes de défaillance communes.
Niveau 2 : l’authentification ne doit pas dépendre du téléphone mobile
En fonctionnement normal, AGOV est souvent utilisé avec un appareil mobile personnel. Pour les fonctions particulièrement critiques, celui-ci ne devrait cependant pas constituer le seul moyen d’authentification disponible.
Les personnes concernées enregistrent donc en plus une clé de sécurité FIDO physique dans leur compte AGOV.
La connexion reste ainsi possible, par exemple, lorsque :
- a téléphonie mobile est perturbée ;
- l’appareil mobile personnel ne peut plus être utilisé ;
- le moyen d’authentification mobile n’est plus disponible pour une autre raison.
L’enregistrement technique ne suffit toutefois pas.
La clé de sécurité doit réellement être :
- disponible ;
- retrouvable ;
- fonctionnelle.
Un contrôle organisationnel fait donc nécessairement partie d’un tel concept.
Lors d’exercices périodiques, les personnes concernées se connectent avec leur clé de sécurité. Une clé enregistrée plusieurs années auparavant, mais introuvable ou défectueuse aujourd’hui, n’a aucune valeur dans le cadre du BCM.
Niveau 3 : le système de destination doit pouvoir authentifier même sans AGOV
C’est ici que se situe l’étape architecturale décisive.
Pour les systèmes de destination particulièrement critiques, la haute disponibilité d’AGOV ne suffit pas. Le système de destination doit disposer en plus de sa propre couche d’authentification, indépendante d’AGOV.
Une possibilité consiste à prendre directement en charge FIDO dans le système de destination.
Fonctionnement normal
En fonctionnement normal, l’authentification continue de passer par AGOV.
En parallèle, la clé de sécurité FIDO enregistrée pour la personne concernée est également enregistrée dans la couche FIDO du système de destination.
Le système de destination connaît ainsi lui-même l’association entre la personne et la clé de sécurité.
Fonctionnement en cas d’indisponibilité d’AGOV
Si AGOV est indisponible, la même personne peut utiliser directement la même clé physique auprès du système de destination.
Le principe essentiel est le suivant :
En fonctionnement normal, AGOV prépare déjà les conditions nécessaires à un fonctionnement sans AGOV.
L’infrastructure centrale d’identité ne crée donc pas uniquement une dépendance ; elle contribue activement à rendre sa propre indisponibilité maîtrisable.
Niveau 4 : la solution de repli doit être utilisée régulièrement en pratique
Une couche de repli techniquement disponible n’est pas encore une couche de repli opérationnelle.
La connexion directe au système de destination doit donc être testée périodiquement dans la pratique.
Dans le même temps, les éléments suivants doivent être recertifiés régulièrement :
- les personnes autorisées ;
- les autorisations ;
- les clés de sécurité enregistrées.
Une solution de repli qui n’a jamais été testée n’est pas une solution de repli.
Un test BCM ne devrait donc pas se limiter à vérifier si un serveur est accessible. Il devrait couvrir l’ensemble du processus :
- personne ;
- clé de sécurité physique ;
- terminal disponible ;
- connexion réseau ;
- authentification directe ;
- accès à la fonction métier effectivement nécessaire.
Ce n’est que lorsque cette chaîne complète fonctionne que la solution de repli est réellement fiable.
Niveau 5 : l’Internet public peut lui aussi tomber en panne
L’indépendance vis-à-vis d’AGOV ne suffit pas à elle seule.
Si le système de destination peut certes authentifier directement au moyen de FIDO, mais n’est accessible que par l’Internet public, une dépendance centrale subsiste.
Pour les systèmes correspondants, des connexions réseau dédiées ou particulièrement résilientes peuvent donc être nécessaires.
En situation de crise, l’objectif est de réduire la chaîne technique au nombre minimum de composants :
utilisateur final → clé de sécurité FIDO → terminal → réseau spécialisé → système de destination
Moins il y a de composants nécessaires, moins il y a de composants susceptibles de tomber en panne.
L’alimentation électrique fait elle aussi partie du BCM
L’alimentation électrique doit elle aussi être prise en compte.
Un centre de calcul plusieurs fois redondant est de peu d’utilité si, sur le lieu d’utilisation prévu, ni le terminal ni l’infrastructure de communication ne peuvent être alimentés en énergie.
Le BCM ne s’arrête donc pas à la limite du centre de calcul.
Niveau 6 : une crise grave nécessite des identités d’urgence préparées
Une couche de repli supplémentaire va encore plus loin.
Dans la couche FIDO directe d’un système de destination particulièrement critique, un nombre limité de clés de sécurité physiques peut être enregistré à l’avance sans être durablement attribué à une personne déterminée.
Ces clés sont conservées de manière décentralisée, contrôlée et sûre.
Si, en situation de crise, une personne autorisée ne peut plus agir avec son identité électronique régulière, une telle clé préparée peut lui être remise conformément à un processus d’urgence défini.
L’association entre la personne réelle et l’identité technique d’urgence s’effectue alors en dehors du système, par exemple au moyen d’une documentation sur papier.
Exigences relatives aux identités d’urgence
Un tel mécanisme ne doit évidemment pas devenir un passe-partout improvisé.
Il exige notamment :
- un cercle précisément défini de cas d’utilisation ;
- un cercle clairement défini de personnes autorisées ;
- une conservation sûre et, si possible, géographiquement répartie ;
- un inventaire des clés de sécurité ;
- une procédure réglementée de remise et de restitution ;
- si possible, un contrôle selon le principe des quatre yeux ;
- une documentation traçable de chaque attribution ;
- des tests réguliers ;
- un processus obligatoire de remise en ordre ultérieure.
Après le rétablissement du fonctionnement normal, les attributions temporaires sont reconstituées à partir de cette documentation et corrigées dans le système de destination.
La procédure est délibérément analogique.
C’est précisément son objectif : elle doit aussi fonctionner lorsque les dépendances numériques habituelles ne sont plus disponibles.
Niveau 7 : il faut pouvoir, à un moment donné, renoncer également au système de destination
L’IT Service Continuity Management répond à la question de savoir comment un service informatique peut continuer à fonctionner ou être rétabli malgré de graves perturbations.
Le Business Continuity Management doit aller encore plus loin.
Il faut également prévoir un scénario dans lequel non seulement AGOV, mais aussi le système de destination lui-même n’est plus disponible.
La solution ne peut alors plus être un autre procédé d’authentification. Les processus métier doivent eux-mêmes pouvoir basculer vers d’autres moyens.
La dernière couche de repli peut notamment comprendre :
- des moyens de communication autonomes ;
- une alimentation électrique indépendante ;
- des informations disponibles physiquement ;
- des processus sur papier ;
- des compétences et pouvoirs de décision définis à l’avance.
En dernier ressort, l’État doit rester capable d’agir même sans :
- AGOV ;
- les systèmes de destination concernés ;
- Internet ;
- la téléphonie mobile ;
- l’alimentation électrique ordinaire.
Quatre états de fonctionnement plutôt qu’une seule solution d’urgence
Pour la mise en œuvre pratique, le modèle peut être ramené à quatre états de fonctionnement clairement distincts.
1. Fonctionnement normal
La personne s’authentifie normalement par AGOV.
AGOV assure l’authentification centrale et fournit au système de destination :
- l’identité nécessaire ;
- les informations requises.
2. Fonctionnement dégradé
Certaines parties de l’infrastructure – par exemple la téléphonie mobile – ne sont plus disponibles.
Les personnes particulièrement importantes peuvent continuer à utiliser AGOV au moyen de leur clé de sécurité FIDO physique.
3. Fonctionnement sans AGOV
AGOV lui-même n’est plus disponible.
Le système de destination particulièrement critique est atteint par une connexion réseau alternative et authentifie directement les clés de sécurité FIDO enregistrées au préalable.
Pour les cas extraordinaires, des identités d’urgence préparées peuvent être utilisées selon une procédure strictement réglementée.
4. Fonctionnement sans système de destination
Le système métier lui-même n’est plus disponible.
Le processus BCM défini à l’avance prend le relais.
L’organisation poursuit son activité avec les moyens :
- techniques ;
- organisationnels ;
- analogiques
préparés pour ce cas précis.
Cette distinction évite d’activer immédiatement le mode d’urgence le plus radical pour chaque incident.
La véritable force réside dans le découplage
L’idée déterminante de ce modèle n’est pas un produit technique particulier.
C’est le découplage contrôlé des dépendances.
En fonctionnement normal, une solution centrale comme AGOV offre de grands avantages :
- vérification centrale de l’identité ;
- authentification forte ;
- processus uniformes ;
- infrastructure de confiance commune.
Ces fonctions ne doivent ainsi pas être reconstruites par chaque application spécialisée.
Pour quelques systèmes particulièrement critiques, cette centralisation est toutefois complétée par des couches de repli ciblées.
Il ne s’agit pas de créer un deuxième IAM parallèle pour le fonctionnement quotidien.
La couche FIDO supplémentaire reste une fonction d’urgence volontairement limitée. Les identités, clés de sécurité et autorisations sont préparées et vérifiées régulièrement en fonctionnement normal, mais ne sont utilisées directement que dans le cas de perturbation défini.
Cette approche évite deux erreurs opposées :
- chaque système spécialisé ne redevient pas son propre système IAM complet ;
- on ne part pas non plus du principe qu’une plateforme centrale d’authentification pourra rester disponible dans toutes les circonstances imaginables.
La résilience doit être ancrée dans l’organisation
La technique seule ne suffit pas.
Pour chaque système de destination particulièrement critique, il faut donc définir au minimum :
- les responsabilités ;
- les critères d’activation ;
- les intervalles d’exercice ;
- la recertification ;
- la gestion des clés ;
- les voies de communication ;
- le retour au fonctionnement normal.
Ce dernier point est souvent sous-estimé.
Après une crise, les éléments suivants doivent pouvoir être ramenés de manière contrôlée dans l’état régulier :
- les identités temporaires ;
- les autorisations particulières ;
- les attributions manuelles.
Le BCM nécessite donc non seulement un chemin vers le fonctionnement d’urgence, mais aussi un chemin contrôlé pour en sortir.
Conclusion
AGOV peut jouer un rôle central dans la résilience des services étatiques critiques. La bonne approche ne consiste cependant pas à considérer AGOV comme indestructible.
Le modèle plus robuste accepte dès le départ que tout composant technique puisse tomber en panne.
Par conséquent :
- AGOV lui-même est construit avec une haute disponibilité et une redondance d’infrastructure ;
- les personnes particulièrement importantes disposent d’un facteur FIDO indépendant du téléphone mobile ;
- certains systèmes de destination critiques peuvent, si nécessaire, authentifier directement les mêmes clés de sécurité ;
- les dépendances réseau et électriques sont réduites ;
- des identités d’urgence préparées et des processus manuels documentés sont prévus pour les crises graves ;
- une dernière couche BCM fonctionne même sans le système numérique de destination.
Ainsi comprise, la résilience n’est pas une solution de remplacement unique.
C’est une chaîne de niveaux de dégradation préparés consciemment, dans laquelle chaque niveau nécessite moins d’infrastructure que le précédent.
C’est précisément pour cette raison qu’AGOV peut être à la fois une infrastructure centrale d’authentification et un élément d’une architecture conçue pour pouvoir continuer à fonctionner, si nécessaire, même sans AGOV.