Exiger des clés d'accès
Exigez que chaque membre possède une clé d'accès avant d'ouvrir le compte, découvrez les exemptions et ce que voient les membres, puis rétablissez l'accès de ceux qui ont perdu leurs clés.
Pourquoi c’est important
Les mots de passe et les codes d’authentification peuvent tous deux être saisis sur une fausse page de connexion convaincante. Pas les clés d’accès : le navigateur les lie au domaine de Kit, si bien que l’identifiant n’est jamais proposé au site d’un attaquant. En imposer une à l’ensemble du compte limite les accès obtenus avec des mots de passe ou des codes hameçonnés.
Activez cette règle depuis Settings → Security (Paramètres → Sécurité). La page exige l’autorisation manage security (Gérer la sécurité), détenue par les rôles Admin et Security Analyst (Analyste sécurité). Consultez Rôles de l’équipe.
Fonctionnement de l’obligation
L’obligation ne remplace pas la connexion. Elle ajoute un contrôle d’accès propre au compte, après la connexion :
- Le membre se connecte à Kit par sa méthode habituelle.
- À l’ouverture de ce compte, Kit vérifie si la session a prouvé une clé d’accès.
- Dans le cas contraire, Kit affiche un contrôle avec inscription intégrée ou confirmation d’une clé existante.
- Après confirmation, le membre revient à la page demandée.
Ce fonctionnement évite qu’une règle de sécurité propre à une entreprise n’empêche une personne d’accéder à son identité Kit ou aux autres comptes auxquels elle appartient.
Perdre une clé d’accès ne coûte donc au membre que l’accès à un compte, pas son identité Kit. Il peut toujours se connecter, atteindre son profil et travailler dans les comptes qui n’exigent pas de clé d’accès.
Avant l’activation
Vous devez vous-même posséder une clé d’accès. Le bouton Require passkeys (Exiger des clés d’accès) reste sans effet jusqu’à son inscription. Kit répond : « Commencez par inscrire une clé d’accès sur votre propre compte : personne n’est exempté de cette obligation, pas même vous. »
Le propriétaire n’est jamais exempté. L’obligation SSO l’exempte parce qu’un fournisseur d’identité peut tomber en panne côté serveur et bloquer toute l’équipe. Une clé d’accès ne présente pas ce risque. Exempter le propriétaire ferait simplement de son identifiant le maillon faible du compte, donc la meilleure cible de phishing.
Ajoutez votre clé depuis Account Settings → Passkeys, puis revenez. La page Sécurité affiche un avertissement jusque-là.
Warning
Activer la règle sans posséder de clé d’accès vous exclurait de votre propre compte dès la requête suivante. C’est précisément pourquoi Kit l’interdit.
Activer la règle
La page Sécurité affiche un tableau de conformité actualisé pour chaque membre :
| Statut | Signification |
|---|---|
| Passkey enrolled (Clé d’accès inscrite) | Le membre en possède au moins une. Rien ne lui est demandé. |
| No passkey (Aucune clé d’accès) | Le membre sera bloqué à l’entrée jusqu’à son inscription. |
| Governed by SSO (Régi par le SSO) | Le membre est exempté ; voir ci-dessous. Rien ne lui est demandé non plus. |
Cliquez sur Require passkeys. La confirmation chiffre clairement l’effet : « Exiger des clés d’accès ? Quatre membres ne pourront pas ouvrir ce compte avant d’en inscrire une. » Personne ne peut ainsi activer la règle sans savoir qui sera bloqué. Si tout le monde possède déjà une clé, la confirmation le précise.
Qui est exempté
Un seul groupe : les membres qui se connectent par SAML SSO sur une connexion où l’option « Require SSO » est activée. Pour ces personnes, Kit refuse déjà tout identifiant autre que celui du fournisseur d’identité. L’obligation n’ajouterait rien.
Important
Cette exemption dépend de l’entité qui régit l’authentification, pas de sa robustesse : si votre fournisseur d’identité accepte un mot de passe, l’exemption l’accepte également. Configurez cette politique dans l’IdP.
Rien d’autre n’est exempté :
| Non exempté | Pourquoi |
|---|---|
| Propriétaires et administrateurs | Aucune exemption de rôle. Les personnes qui ont le plus d’accès doivent fournir la preuve la plus robuste. |
| SSO sans « Require SSO » | Si les mots de passe fonctionnent encore pour le domaine, la délégation n’est pas réelle. Seule l’application obligatoire compte. |
| Connexion avec Google ou GitHub | Vous ne contrôlez ni ces fournisseurs ni leur MFA, et l’inscription OAuth de Kit laisse un mot de passe utilisable. |
| Google One Tap | Même logique : OAuth grand public, pas votre fournisseur d’identité. |
| Codes à deux facteurs | Vulnérables au phishing. Un code n’est pas une clé d’accès. |
| Navigateurs de confiance | Faire confiance à un navigateur évite un code à deux facteurs. Cela ne prouve rien au sujet des clés d’accès. |
L’exemption est évaluée en temps réel, pas figée lors de la connexion. Si vous assouplissez l’application du SSO, les membres auparavant exemptés seront soumis à l’obligation dès leur requête suivante.
Effets immédiats
La règle s’applique dès l’enregistrement. Aucun délai de grâce ni déploiement progressif : un membre dont la session est en cours rencontre le contrôle au prochain chargement de page.
| Effet | Détail |
|---|---|
| Membres bloqués | Une page intitulée « [Compte] exige une clé d’accès » apparaît, avec l’inscription intégrée, un lien Switch account (Changer de compte) et le retour vers la destination initiale. |
| Adhésion | Inchangée. Personne n’est retiré ; aucune licence, aucun rôle ni aucune invitation ne change. |
| Autres comptes | Inchangés. Le blocage ne concerne que ce compte. |
| Nouveaux membres | L’e-mail d’invitation précise qu’une clé d’accès est nécessaire. Ils le savent donc avant d’arriver, pas au moment d’entrer. |
Seules les personnes qui doivent agir reçoivent un e-mail. Le message « Ajoutez une clé d’accès pour continuer à utiliser [Compte] » leur indique le changement et son auteur, explique qu’une seule clé suffit et que le déverrouillage existant de leur appareil convient, puis fournit un lien direct vers l’inscription. Les membres qui possèdent déjà une clé et ceux exemptés par le SSO ne reçoivent rien.
Jetons d’API et connexions MCP
Un jeton ou un assistant ne peut pas toucher un capteur d’empreinte. Lorsque son créateur ne possède aucune clé d’accès, ses jetons d’API et ses connexions MCP sont refusés. Dès l’inscription, les deux reprennent avec les mêmes identifiants : aucun jeton à réémettre, aucun assistant à réautoriser, aucune donnée modifiée.
Note
Ce contrôle est moins robuste que celui du navigateur : une session doit prouver une clé d’accès, tandis qu’un jeton doit seulement appartenir à une personne qui en possède une. Un jeton ne peut pas exécuter une cérémonie WebAuthn ; c’est donc la meilleure garantie possible sur cette interface.
Lorsqu’un membre perd toutes ses clés
Ses appareils ont disparu. Il ne peut donc plus confirmer une clé ni en inscrire une nouvelle, puisque la gestion des clés exige une clé existante. Émettez un pass de réinscription depuis sa ligne du tableau de conformité.
Vous ne voyez jamais le pass. Kit l’envoie directement à la personne, dans sa langue. Il n’apparaît sur aucun écran, message flash ou journal côté émetteur. La confirmation indique seulement qu’un pass a été émis. L’émission figure dans la piste d’audit avec l’identité de l’émetteur et du destinataire.
Voici le parcours du membre :
| Son action | Conséquence |
|---|---|
| Ouvrir le lien reçu par e-mail | Aucune consommation : seule une page de confirmation s’affiche. Un analyseur de lien ou un aperçu d’e-mail ne peut pas invalider le pass. |
| Confirmer sur cette page | Le pass est consommé et ouvre une fenêtre de 15 minutes durant laquelle Kit propose l’inscription au lieu d’exiger la clé perdue. |
| Inscrire une nouvelle clé d’accès | La fenêtre se ferme et l’accès est rétabli. |
Le pass est valable une fois pendant 24 heures. En émettre un nouveau annule immédiatement celui encore en circulation pour ce membre. Un pass expiré, consommé, remplacé ou ouvert par une autre personne affiche toujours la même page neutre, sans indiquer la raison. Si un membre signale que son lien « ne fonctionne plus », il suffit d’en émettre un nouveau.
Danger
Un pass de réinscription contourne votre contrôle le plus robuste. Avant de l’émettre, vérifiez par un autre canal que vous échangez bien avec la bonne personne. Utilisez un canal indépendant, comme un appel téléphonique. Ne vous fiez pas à une simple réponse par e-mail.
Désactiver la règle
Cliquez sur Stop requiring passkeys (Ne plus exiger de clés d’accès). Les membres qui n’en possèdent pas peuvent rouvrir le compte dès leur requête suivante. Les jetons d’API et connexions MCP refusés reprennent immédiatement. Les clés déjà inscrites restent en place. Rien n’est à réémettre dans un sens comme dans l’autre.
Checklist
- Inscrivez d’abord une clé d’accès sur votre propre compte : le bouton ne fonctionnera pas avant
- Examinez le tableau de conformité et repérez les membres au statut No passkey
- Si vous comptez sur l’exemption SSO, vérifiez que la connexion applique bien Require SSO
- Activez la règle et lisez le nombre indiqué dans la confirmation avant d’accepter
- Vérifiez si les membres bloqués se sont inscrits depuis le lien direct reçu par e-mail
- Vérifiez par téléphone l’identité de toute personne demandant un pass de réinscription, jamais par e-mail uniquement
- Rappelez-vous que les jetons d’API et connexions MCP reprennent automatiquement dès que leur propriétaire inscrit une clé