Identity & Access Management
La gestion des identités et des accès (IAM) constitue le plan de contrôle qui détermine qui existe sur la plateforme et ce que chacun est autorisé à faire. Elle prend en charge l'intégralité du cycle de vie d'un principal, depuis le provisionnement d'un compte jusqu'à sa désactivation, en passant par l'authentification, l'attribution des rôles et l'activité des sessions, et elle applique ces décisions de manière uniforme à travers chaque module de la suite. Parce que Nashua 360 traite aussi bien les personnes que les AI Workers comme des utilisateurs à part entière, ce module gouverne les employés humains et les agents autonomes au moyen d'une autorité unique et cohérente.
Le problème métier dont il a la charge est celui de la confiance : prouver qu'une requête provient bien de celui qu'elle prétend être, et confirmer que l'acteur est habilité à l'opération avant qu'aucune donnée ne soit lue ou modifiée. Il se situe au fondement de la plateforme, en dessous des modules métier plutôt qu'à leurs côtés. Chaque écriture comptable, chaque mouvement de flotte, chaque devis commercial et chaque modification de la base de connaissances passe par le même contrôle d'identité et la même évaluation des permissions, si bien que la sécurité devient une propriété de la plateforme elle-même plutôt qu'une fonction que chaque module réimplémente.
Ce que fait le module
La gestion des identités et des accès offre l'ensemble complet des capacités qu'une entreprise attend d'une autorité d'accès centrale. Elle provisionne et gère les comptes utilisateurs, conserve les détails de profil, les coordonnées et l'état du compte, et distingue clairement l'administration de n'importe quel compte de l'édition en libre-service de son propre profil. L'authentification repose sur des identifiants avec un hachage robuste des mots de passe, complétée par une authentification à deux facteurs basée sur le temps et par un jeu de codes de récupération à usage unique conservés sous chiffrement pour le cas où le second facteur serait perdu.
Au-delà du point de connexion, le module maintient un contrôle en direct des sessions, de sorte que les sessions actives soient visibles, attribuables à un principal, bornées par une expiration et révocables individuellement. L'autorisation s'exprime au moyen de rôles nommés porteurs de permissions à granularité fine, et ces permissions atteignent chaque sujet exposé par la plateforme. L'authentification unique (SSO) est disponible via des connecteurs vers des fournisseurs d'identité, ce qui permet à l'organisation de fédérer l'authentification avec son annuaire existant tout en conservant les décisions d'autorisation locales à la suite. La gestion des rôles et des permissions fait partie de ce module, offrant aux administrateurs un lieu unique pour définir ce que chaque catégorie d'utilisateur peut faire.
Le domaine et le modèle de données
Au centre du domaine se trouve le principal : un acteur vérifié sur la plateforme, qu'il s'agisse d'un employé nommé ou d'un AI Worker, détenteur d'une identité unique, de coordonnées et d'un état de compte qui détermine s'il peut agir. Chaque principal est rattaché à exactement un rôle, et c'est le rôle, et non l'individu, qui porte les habilitations. Cette séparation délibérée maintient les décisions d'accès cohérentes et auditables : modifiez un rôle et tous les principaux qui le détiennent évoluent ensemble, plutôt que de dériver vers une mosaïque d'exceptions individuelles.
Un rôle se définit par son ensemble de permissions, une expression structurée des actions que le rôle peut mener sur telles ou telles parties de la plateforme. Des actions telles que lire, créer, mettre à jour, supprimer et accéder sont associées aux sujets métier auxquels elles s'appliquent, et la plateforme reconnaît des sujets pour chaque domaine fonctionnel qu'elle couvre. Les rôles intégrés vont d'un administrateur sans restriction aux responsables fonctionnels et techniques, jusqu'à un utilisateur standard en lecture seule, et ces rôles fondamentaux sont protégés contre la suppression afin que le système conserve toujours une base cohérente. Le dernier concept est la session, l'enregistrement de la présence authentifiée d'un principal, portant son propre jeton, son propriétaire et son expiration. Ensemble, ces quatre notions décrivent, de façon claire et complète, qui est quelqu'un, ce qu'il peut faire, et s'il est actuellement connecté.
Flux de travail des principaux
Le flux de travail le plus fréquent est le provisionnement. Un administrateur crée un compte, en définit le profil initial et lui attribue un rôle, et le nouveau principal est immédiatement régi par les habilitations de ce rôle, sans configuration supplémentaire. Les réinitialisations de mot de passe suivent le même chemin administratif, tandis que les utilisateurs ordinaires gèrent leur propre profil et enregistrent leur second facteur en libre-service. La configuration à deux facteurs associe une application d'authentification au compte et émet des codes de récupération, et le titulaire du compte peut régénérer ces codes ou reconfigurer le facteur à mesure que les circonstances évoluent.
La revue des accès constitue un flux de travail à part entière. Les administrateurs examinent qui détient quel rôle, ajustent l'ensemble de permissions d'un rôle au moyen d'un éditeur qui regroupe les sujets sous leur module d'appartenance, et voient ces changements prendre effet sur l'ensemble de la plateforme sans avoir à redéployer quoi que ce soit. La supervision des sessions permet à un administrateur de visualiser les sessions actives et de révoquer toute session qui ne devrait plus subsister, ce qui constitue la réponse immédiate à un appareil perdu ou au départ d'un employé. La désactivation ferme la boucle : un compte peut être désactivé de sorte qu'il conserve son historique et sa piste d'audit tout en perdant la capacité de s'authentifier, préservant ainsi l'enregistrement sans préserver l'accès.
Une profondeur fonctionnelle qui compte
Le modèle d'autorisation est fondé sur les attributs plutôt que sur une liste grossière de privilèges. Les permissions sont conservées sous forme de règles explicites associant une action à un sujet, et la plateforme comporte un registre riche de sujets couvrant chaque module, si bien que les habilitations peuvent être aussi larges que le contrôle complet d'un domaine fonctionnel ou aussi étroites que la visibilité en lecture seule d'un unique sujet. Cette granularité est précisément ce qui permet à un responsable technique et à un responsable fonctionnel de coexister, chacun disposant d'une autorité sur son propre domaine et d'une vue en lecture seule sur celui de l'autre. Lorsqu'un principal s'authentifie, l'ensemble de permissions effectif est résolu et transporté dans un jeton signé, et ce jeton est renouvelé sur un cycle court, de sorte qu'une modification d'un rôle se propage aux sessions en service en quelques minutes plutôt que de rester en attente jusqu'à la prochaine connexion.
Le module est conçu selon des contrôles de sécurité établis. Les identifiants ne sont jamais stockés en clair, le matériel de récupération est chiffré au repos, et les cookies de session sont émis avec les indicateurs de protection qui empêchent l'accès côté client et la transmission intersites. La connexion est soumise à une limitation de débit pour contrer les tentatives par force brute, et chaque décision d'accès est appliquée à la frontière de l'interface, de sorte qu'un contrôle de permission ne puisse être contourné en appelant directement une opération. Parce que la même porte d'application couvre à la fois l'usage interactif et l'accès programmatique, les garanties tiennent qu'une requête provienne d'un navigateur, d'une intégration ou d'un agent autonome.
Comment elle s'intègre dans la suite Nashua 360
La gestion des identités et des accès est la dépendance que partagent tous les autres modules. Elle fonctionne main dans la main avec la Gestion de la sécurité, qui audite la posture de la plateforme et exploite le modèle d'accès pour raisonner sur l'exposition, ainsi qu'avec la Gestion de la confidentialité et la Gestion de la conformité, qui s'appuient sur elle pour prouver que l'accès aux données personnelles et réglementées est réservé aux principaux habilités. La Gestion des connecteurs fournit les intégrations avec les fournisseurs d'identité qui rendent l'authentification unique possible, fédérant l'authentification avec l'annuaire de l'organisation. Le moteur de notifications achemine les événements pertinents pour la sécurité que ce module génère, tels qu'une nouvelle session ou un changement de rôle, vers les personnes qui doivent en avoir connaissance.
Chaque module métier, de la Comptabilité et du contrôle au Marketing et ventes, en passant par la Gestion de flotte, la Gestion des ressources humaines et la Base de connaissances, exprime ses propres règles d'accès sous forme de sujets au sein du modèle de permissions de ce module, si bien qu'il existe une seule autorité et un seul vocabulaire d'habilitation pour l'ensemble de la suite. La Gestion des modules et, plus largement, le domaine de l'Administration système traitent l'identité comme le substrat sur lequel toute activité administrative est autorisée.
Comment les AI Workers y opèrent
Les AI Workers sont ici des principaux au même titre que les autres, provisionnés avec leur propre identité, rattachés à un rôle et contraints par exactement les permissions que ce rôle accorde, ce qui signifie qu'un agent ne peut jamais agir au-delà de l'autorité qui lui a été conférée. En travaillant de manière conversationnelle, un administrateur peut demander à un AI Worker de signaler qui détient un rôle particulier, quels comptes ont l'authentification à deux facteurs activée ou quelles sessions sont actuellement actives, et le Worker répond en interrogeant les données propres au module. Doté de l'habilitation appropriée, il exécute également des actions : provisionner un compte, attribuer ou ajuster un rôle, réinitialiser un identifiant ou révoquer une session à la demande.
Les Workers observent tout autant qu'ils agissent. Ils font remonter les anomalies et les exceptions, en signalant les comptes dépourvus de second facteur, les sessions au comportement inhabituel ou les rôles dont les habilitations se sont écartées de la politique, et ils les portent à l'attention humaine via le canal de notification. Ils extraient de la structure à partir de documents justificatifs, transformant une liste d'arrivées et de départs ou un formulaire de demande d'accès en propositions concrètes de provisionnement et de déprovisionnement, et ils offrent une aide à la décision lorsqu'un changement de rôle est envisagé, en expliquant ce qu'un ensemble de permissions donné autoriserait. Plus important encore, un AI Worker peut se poser comme nœud d'approbation ou de revue dans un flux de travail d'accès, de sorte qu'une attribution de rôle sensible ou une demande de provisionnement privilégié marque une pause pour son examen, chaque jugement étant consigné au nom de la propre identité du Worker dans la piste d'audit.
