Guide d’identité et d’accès · Canada · FR / EN
Faut-il exiger l’AMF, l’authentification unique et l’accès conditionnel—et pour qui?
This guide is maintained in English as well. Conditional access decisions →
L’authentification multifacteur, l’authentification unique et l’accès conditionnel sont habituellement vendus comme des paramètres à activer. La question plus difficile est de savoir qui peut faire exception—le contractuel sans appareil de l’entreprise, le compte fournisseur incapable de soutenir l’AMF, le seul compte de secours gardé hors de toute règle—et qui approuve cet écart.
La décision à rendre possible
Décider quels contrôles d’identité s’appliquent à quelle population, qui peut obtenir une exception, et qui porte le compte d’accès d’urgence qui échappe à toutes les règles.
01 Partir de qui se connecte, pas de quelle fonction activer
L’authentification multifacteur, l’authentification unique et l’accès conditionnel sont des contrôles appliqués à des personnes et à des comptes, pas un interrupteur unique pour toute l’entreprise. Regroupez les comptes selon le risque et la conséquence—administrateurs, personnel qui traite des données clients ou financières, contractuels, comptes de service et connexions partagées—avant de décider quel contrôle s’applique à quel groupe, et pourquoi.
- Quels comptes peuvent atteindre les systèmes financiers, les données clients ou les paramètres administratifs
- Quelles connexions se font depuis un appareil non géré, un téléphone personnel ou hors du Canada
- Quels comptes sont partagés, génériques ou utilisés par plus d’une personne
Traiter chaque exception comme une décision, pas un contournement
Un contractuel incapable d’installer une application d’authentification, un système d’affaires qui ne soutient pas la connexion moderne, une direction qui trouve les invites d’AMF irritantes en déplacement—chacun est une contrainte réelle, et chacun est aussi une décision qui a besoin d’un responsable. Une exception accordée discrètement par la personne qui a configuré le locataire n’équivaut pas à une exception que la direction a réellement approuvée.
Nommer qui porte le compte de secours avant d’en avoir besoin
Un compte de secours—une connexion d’urgence gardée hors de l’accès conditionnel, de l’application de l’AMF et des flux d’approbation normaux—existe pour que les administrateurs ne soient pas exclus de leurs propres systèmes pendant une panne ou une mauvaise configuration. C’est aussi, par conception, le compte auquel aucun autre contrôle ne s’applique. Une personne précise devrait savoir qu’il existe, détenir ses identifiants sous des contrôles proportionnés à ce risque, et vérifier périodiquement qu’il n’a pas été utilisé discrètement.
- Qui détient les identifiants, et comment ils sont conservés
- Ce qui déclencherait son utilisation, et qui en est informé ensuite
- À quelle fréquence son existence et son accès sont réellement revus
Décider qui approuve une exception, et pour combien de temps
Une exception sans date d’expiration devient habituellement permanente par défaut. Précisez qui peut approuver un écart à la politique standard, quelle mesure compensatoire s’applique pendant que l’exception existe—un emplacement réseau plus restreint, une rotation de mot de passe plus courte, une revue de journaux plus étroite—et quand elle revient pour un nouveau regard.
CritèreSignal utileQuestion de direction
PopulationChaque compte est regroupé selon le risque et la conséquence, pas traité comme une seule politique.Quels comptes peuvent atteindre les systèmes financiers, les données clients ou les paramètres administratifs?
ExceptionLes écarts à la politique standard ont un responsable nommé et une raison.Qui a vraiment approuvé que ce compte soit exempté, et pourquoi?
Compte de secoursLe compte d’urgence est nommé, contrôlé et revu selon un calendrier.Qui détient les identifiants du compte auquel aucune politique ne s’applique?
ExpirationChaque exception porte une date de revue plutôt que de durer indéfiniment.Quand cette exception revient-elle pour un nouveau regard?
Scénarios pratiques
Le même cadre, appliqué à des décisions différentes.
Le système d’un fournisseur clé ne soutient pas la connexion moderne
Situation : Une application d’affaires utilisée quotidiennement par l’équipe des finances ne soutient qu’une connexion de base par nom d’utilisateur et mot de passe, sans voie vers l’authentification unique ou l’AMF.
Réponse utile : Traitez cet écart comme une exception nommée et limitée dans le temps, avec une mesure compensatoire—restriction réseau plus serrée, mot de passe unique renforcé, revue de journaux plus étroite—plutôt qu’un trou silencieux dans une politique par ailleurs cohérente, et révisez-le chaque fois que la feuille de route du fournisseur change.
Limite : Ce guide n’évalue aucune feuille de route d’authentification d’un fournisseur précis et ne promet aucune solution de contournement pour chaque système patrimonial.
Une direction demande une exemption permanente aux invites de connexion en déplacement
Situation : Une personne de direction trouve les invites d’authentification répétées dérangeantes lors de déplacements internationaux fréquents et demande aux TI de désactiver l’accès conditionnel pour son compte.
Réponse utile : Séparez la friction réelle—fréquence des invites, règles d’emplacement de confiance, durée de session—de la demande de retirer complètement le contrôle, et ramenez le compromis réel à la direction comme une décision nommée plutôt que d’affaiblir discrètement le compte qui a le plus d’accès.
Limite : Ce guide ne configure aucune politique d’accès conditionnel ni aucune plateforme d’identité précise en votre nom.