MFA et opérations sensibles

MFA obligatoire sur les actions destructrices

L'authentification multifacteur (MFA) n'est pas seulement encouragée à la connexion : elle est obligatoire pour déclencher une action destructrice. Révoquer un membre, désactiver le network lock, supprimer un réseau — ces gestes qui ne se rattrapent pas exigent un second facteur, pas seulement une session déjà ouverte.

Le raisonnement est celui du moindre privilège dans le temps : une session peut avoir été laissée ouverte, un poste momentanément accessible. Exiger le second facteur au moment précis de l'action destructrice ramène la preuve d'identité à l'instant du danger, et non à celui, parfois lointain, de la connexion.

Ré-authentification sudo

Au-delà du MFA, les opérations les plus critiques déclenchent une ré-authentification « sudo » : juste avant l'exécution, le système redemande de prouver votre identité, comme la commande sudo redemande un mot de passe avant une action privilégiée. La preuve d'identité est ainsi fraîche, rattachée à l'opération précise que vous vous apprêtez à lancer.

Concrètement, cela ferme la fenêtre où une session ouverte suffirait : même authentifié, même avec un MFA validé plus tôt, il faut confirmer à nouveau au moment d'agir. Cette élévation est de courte durée et ciblée sur l'opération en cours — elle n'ouvre pas un blanc-seing pour la suite de la session.

Clés API : hachées et scoppées

Les clés API sont traitées comme des secrets, pas comme des identifiants ordinaires. Elles sont stockées hachées : le serveur conserve une empreinte permettant de vérifier une clé présentée, jamais la clé en clair. Une fuite de la base ne livre donc pas de clés utilisables telles quelles.

Elles sont aussi scoppées : chaque clé porte un périmètre de droits limité à ce dont elle a besoin, plutôt qu'un accès total. Une clé compromise n'expose alors que la portée qui lui était attribuée. C'est la même logique de moindre privilège que pour les actions destructrices, appliquée aux accès automatisés.

• Stockage haché : la clé en clair n'est visible qu'une fois, à sa création — conservez-la aussitôt à l'abri.
• Périmètre restreint : n'accordez à chaque clé que les droits strictement nécessaires à son usage.
• Cycle de vie : révoquez sans attendre une clé qui n'est plus utilisée ou dont vous doutez.

Traçabilité

Ces protections ne valent que si l'on peut vérifier, après coup, qui a fait quoi. Les actions sensibles laissent une trace consultable : la console d'audit, décrite sur /docs/console-audit, permet de suivre les opérations critiques, les révocations et les élévations de privilège. La prévention exige un second facteur ; la traçabilité fournit la preuve.