Achetez une limite de contrôle prouvée
Une plateforme d'authentification peut annoncer les rôles, les journaux d'audit et l'isolation des locataires, mais ces étiquettes n'établissent pas comment les contrôles se comportent dans les flux de travail prévus par l'acheteur. Une évaluation des achats doit déterminer qui peut lire, exporter, modifier et administrer les données de quel client, comment les changements du cycle de vie affectent l'accès et quelles preuves enregistrent ces actions. Une démonstration réussie par un administrateur ne constitue pas un test négatif d'accès non autorisé.
Conseils sur les identités mutualisées d'Azure fait la distinction entre l'authentification, l'autorisation et les droits commerciaux. Utilisez ces distinctions pour structurer les questions des acheteurs plutôt que d'assumer qu'un rôle de connexion couvre chaque ressource et action. Cet article est un cadre d'exigences et non une affirmation selon laquelle EmailAuth ou une autre plate-forme nommée implémente les contrôles proposés. Aucun locataire n’a été consulté, aucune autorisation n’a été modifiée ou aucun produit n’a été acheté.
Définir d'abord la matrice d'accès de l'acheteur
Répertoriez les rôles d'utilisateur et de service attendus, les relations avec les locataires et les ressources avant de passer en revue les noms de rôle d'un fournisseur. Incluez la configuration du domaine, les rapports d'authentification, les données brutes, les exportations, les intégrations, l'administration des utilisateurs et les paramètres commerciaux, le cas échéant. Pour chaque combinaison, indiquez si la lecture, la création, la modification, la suppression ou l'exportation doivent être autorisées. La limite prévue par l'acheteur est la référence par rapport à laquelle le comportement du produit peut être évalué.
Ne présumez pas que « lecture seule » exclut l’exportation ou que « administrateur de locataire » se limite à un seul locataire sans preuve. Les équipes de services partagés peuvent légitimement avoir besoin de plusieurs clients, tandis que les utilisateurs de clients individuels ne devraient voir que leur périmètre approuvé. Enregistrez ces exceptions explicitement. Le rôle général accepté pour un essai ne devrait pas devenir silencieusement la conception de l'accès à la production. Exigez du fournisseur qu'il mappe les rôles réels à la matrice de l'acheteur et identifie les distinctions non prises en charge.
Vérifier la liaison du locataire au-delà de l'interface
Un locataire sélecteur ou un élément de navigation masqué ne constitue pas une preuve suffisante d’isolement. L'identité authentifiée doit être autorisée pour la ressource demandée au niveau de la limite côté serveur. Les exigences doivent couvrir les lectures directes, les recherches, les exportations, les écritures et les tâches en arrière-plan, y compris les références aux ressources appartenant à un autre locataire. Utilisez des appareils synthétiques avec des données visiblement différentes afin qu'un résultat accidentel entre locataires soit détectable.
Les conseils d'Azure avertissent qu'une mauvaise configuration de la fédération peut accorder l'accès à des locataires non désirés. L'examen doit donc inclure la manière dont les identités sont associées aux locataires, qui peut modifier cette association et comment un utilisateur appartenant à plusieurs locataires sélectionne la portée. Ne déduisez pas la propriété à partir d’un seul suffixe de courrier électronique et ne supposez pas qu’un identifiant de locataire fourni par le client autorise son utilisation. Le fournisseur réel doit expliquer et démontrer son modèle pris en charge.
Demandez ce que le journal d'audit enregistre réellement
Documentation du journal d'audit de Microsoft Entra décrit les enregistrements d'activité pour les changements dans cet environnement d'identité. Il s’agit d’un exemple utile de modèle de journal d’audit officiel, et non d’une preuve qu’une autre plateforme enregistre les mêmes événements. Un acheteur doit demander le catalogue exact d'événements de produits, les définitions de champs, les contrôles d'accès, le comportement de rétention et les options d'exportation correspondant à ses propres besoins.
Demandez-vous si les enregistrements identifient suffisamment l’acteur, la cible, l’action, le moment, le résultat et le contexte pour enquêter sur un changement. Distinguez l’activité des utilisateurs de l’activité d’identité de service et les actions réussies des tentatives refusées. Ne présumez pas que chaque tentative d'autorisation échouée est enregistrée simplement parce que des modifications administratives apparaissent. De même, un journal indiquant qu'une demande a été soumise peut ne pas indiquer si la modification résultante a été effectuée. Exigez des exemples réels avec des données sensibles expurgées et des limitations indiquées.
Examiner l'accès et l'intégrité des journaux en tant que contrôles
Un journal d’audit peut lui-même contenir des informations sensibles sur les clients et l’identité. Définissez qui peut le consulter, effectuez des recherches parmi les locataires, exportez-le et configurez sa conservation. Un administrateur qui peut modifier un paramètre et effacer les seules preuves présente un modèle de responsabilité différent de celui avec des enregistrements conservés de manière indépendante. Demandez au fournisseur comment fonctionnent ces contrôles, mais n'affirmez pas l'immuabilité ou la résistance à la falsification sans preuves actuelles.
La conservation doit être spécifiée par les conditions réelles du produit et les obligations de l'acheteur, et non par une période universelle inventée. Clarifiez quels événements sont disponibles dans l'interface, l'API et les archives exportées et si ces vues ont la même couverture. Examinez la gestion des fuseaux horaires et les identifiants afin que les enregistrements puissent être corrélés sans compter sur des noms susceptibles de changer. Aucun enregistrement d'audit n'a été récupéré pour ce manuscrit.
Modifications du cycle de vie des tests et accès aux services
Une réduction de rôle, une désactivation d'utilisateur et une révocation d'informations d'identification sont des événements distincts. RFC 7643 décrit l'attribut actif SCIM tout en laissant sa signification définitive au fournisseur de services. Cela illustre pourquoi un acheteur ne peut pas supposer qu’une mise à jour de provisionnement révoque toutes les sessions existantes ou les informations d’identification d’intégration. Exiger une explication actuelle de la session du produit et du comportement d'accès non interactif.
Le plan d'acceptation doit inclure un utilisateur dont le rôle est réduit pendant qu'une session existe, une identité désactivée, une intégration à portée limitée et un administrateur autorisé. Vérifiez le résultat de l'accès prévu dans chaque cas, y compris les exportations et les opérations directes sur les ressources. Il s'agit de contrôles proposés pour un environnement isolé autorisé, et non d'autorisation de tester le service de production d'un fournisseur ou du locataire d'un autre client. Aucune action de ce type n’a été effectuée ici.
Une feuille de travail d'acceptation de l'acheteur
Créez une feuille de travail avec l'exigence, la raison commerciale, la réclamation du fournisseur, la configuration prise en charge, l'identité du luminaire, le locataire, l'action, le résultat attendu, les preuves réelles et les limitations non résolues. Conservez les preuves des actions autorisées séparément des preuves des actions refusées. Incluez la version du produit, la date du test et l'environnement afin que le résultat reste interprétable après une version. Si une fonctionnalité est planifiée plutôt que mise en œuvre, enregistrez ce statut sans la traiter comme une couverture actuelle.
Pour les journaux d'audit, ajoutez l'événement attendu et la référence d'enregistrement observée pour chaque action pour laquelle la journalisation est requise. Un test qui refuse à juste titre l’accès mais ne produit aucun élément probant attendu a un résultat différent de celui qui satisfait aux deux critères. Enregistrez qui accepte toute limitation et si un contrôle compensatoire est approuvé. Ne transformez pas le score d’une liste de contrôle d’approvisionnement en une garantie de sécurité future.
Diagnostic fictionnel : un spectateur qui peut exporter
Un acheteur fictif voit une démonstration d'un fournisseur dans laquelle un spectateur ne peut pas modifier les paramètres de domaine. L'acheteur marque initialement le rôle en lecture seule comme satisfaisant. Cependant, la matrice prévue interdit également les exportations massives de données brutes sur les clients. La démonstration n'a jamais testé les exports, les demandes directes de ressources ou l'accès au rapport d'un autre locataire. La restriction observée ne couvre qu’une seule action.
La réponse proposée consiste à demander des preuves autorisées basées sur les montages pour les opérations manquantes et à examiner les enregistrements d'audit qui en résultent. Si le produit ne peut pas séparer la visualisation de l'exportation, l'acheteur doit décider si cette limitation est acceptable plutôt que de renommer le rôle et d'assumer que le risque a disparu. Il s'agit d'un exercice d'approvisionnement fictif, et non d'une découverte sur EmailAuth ou sur un fournisseur nommé.
Gardez la conclusion d'achat limitée
Une conclusion utile identifie les exigences satisfaites par les preuves, les exigences non satisfaites, les limitations acceptées par un propriétaire et les tests encore ouverts. Il distingue les choix de configuration du comportement inhérent du produit et ne promet pas une isolation parfaite d'un ensemble de tests fini. La décision peut être éclairée sans prétendre que chaque version ou configuration future est couverte.
Le catalogue nécessite une matrice d’accès et des tests négatifs pour les lectures, exportations, écritures et modifications du cycle de vie entre locataires. Ces tests originaux restent ouverts. L'examen par un spécialiste humain, l'applicabilité des sources, les itinéraires de production, l'accessibilité et la libération par le propriétaire restent également ouverts. Ce projet fournit la méthode d'évaluation, et non une recommandation d'achat basée sur des preuves signées, et aucun engagement commercial ou autorisation d'accès n'a été pris.