Suivi des droits

Depuis Domino 12.0, un nouveau mécanisme interne est fourni pour collecter les droits les plus élevés dont disposent les utilisateurs individuels sur un domaine Domino. Lorsqu'un utilisateur apparaît dans l'ACL d'une base de données avec un accès Lecteur ou supérieur et que cette personne a le droit d'accéder au serveur, l'utilisateur est dit être un utilisateur autorisé .

Par exemple, Dana Smith/Renovations dispose d'un accès Auteur à une application de notes de frais, dépenses.nsf . Le paramètre de sécurité Autoriser l’accès du serveur autorise l’autorisation */Renovations pour accéder au serveur. Par conséquent, Dana Smith/Renovations est considérée comme un utilisateur autorisé disposant d'un accès Auteur.

Environ une fois par jour, chaque serveur Domino 12 analyse chaque base de données du serveur et collecte le niveau d'accès le plus élevé pour chaque utilisateur autorisé. Par exemple, sur le serveur A :
  • Dana Smith/Renovations dispose : d'un accès auteur à dépenses.nsf , d'un accès lecteur à AcmeSales.nsf et d'un accès éditeur à son fichier courrier, DanaSmith.nsf .
  • Richard Smith/Renovations dispose : d'un accès auteur à dépenses.nsf et d'un accès concepteur à AcmeSales.nsf .
  • Gary Smith/GS Consulting dispose d'un accès lecteur à AcmeSales.nsf .
Une fois son analyse terminée, le serveur A suit :
  • Dana Smith/Renovations est une utilisatrice autorisée avec Editor comme niveau d'accès le plus élevé.
  • Richard Smith/Renovations est un utilisateur autorisé avec Designer comme niveau d'accès le plus élevé.
  • Gary Smith/GS Consulting n'est pas un utilisateur autorisé car, bien qu'il apparaisse dans une ACL de base de données avec accès Lecteur, il n'a pas accès au serveur.

Comment les serveurs suivent les droits

Le programme d'installation de Domino installe le modèle : entitlementtrack.ntf . La tâche de mise à jour du serveur Domino fonctionne avec le serveur pour créer et gérer une base de données système cachée entitlementtrack.ncf sur le serveur. entitlementtrack.ncf dispose d'un document pour chaque utilisateur dans l'annuaire Domino du serveur afin de suivre le niveau d'accès autorisé le plus élevé de chaque utilisateur. En plus du niveau d'accès autorisé le plus élevé d'un utilisateur, chaque document contient des faits corroborants tels que la première base de données dans laquelle cet utilisateur a été trouvé et comment un utilisateur obtient le niveau d'accès autorisé le plus élevé. Par exemple : « L'utilisateur Dana Smith/Renovations dispose d'un accès Editeur à la base de données DanaSmith.nsf car elle est explicitement nommée dans l'ACL. » Ou : "L'utilisateur Richard Smith/Renovations dispose d'un accès Designer dans la base de données AcmeSales.nsf car il est membre du groupe AppDesigners qui dispose d'un accès Designer à cette base de données." Depuis la version 12.0.2, la base de données suit également la dernière date/heure à laquelle un utilisateur s'est authentifié auprès d'un serveur suivi et le protocole avec lequel cet utilisateur s'est connecté au serveur, comme le montre l'exemple suivant.

Tableau 1 . Exemples de données dans les données de suivi des droits
Nom Accès le plus élevé Accordé dans la base de données Accordé par l'entrée ACL Dernier accès Taper
Aaliyah Click/Guitares Éditeur mail3/aclick.nsf (MusicMan) Aaliyah Click/Guitares (Explicit) 8/10/2022 16:14 HTTP
École Alexander/Guitares Directeur cscancfg.nsf (Gibson) Administrateurs de domaine local (groupe) 7/28/2022 9:03 HTTP
Alexis Rose/Guitares Éditeur mail2/arose.nsf (MusicMan) Alexis Rose/Guitares (Explicit) 8/10/2022 8:54 CNRP
Amy Andrews/Guitares Directeur specs/NewFeatures.nsf (Aile) Administrateurs de domaine local (groupe) 7/24/2022 0:00 CNRP
Automne Blakely/Guitares Éditeur mail4/arose.nsf (Gibson) Autumn Blakely/Guitares (Explicit) 8/4/2022 19:39 LDAP
Mur de Barack/Guitares Éditeur mail1/bwall.nsf (Gibson) Barack Wall/Guitares (Explicit) 7/24/2022 0:00 CNRP
Boyd Webber/Guitares Éditeur mail1/bwebber.nsf (Fender) Boyd Webber/Guitares (Explicite) 8/10/2022 8:54 CNRP

Qui est suivi

Les utilisateurs suivants sont suivis :
  • Utilisateurs authentifiés dans un annuaire. Chaque utilisateur de tous les répertoires approuvés pour l'authentification est suivi. Cela peut être aussi simple que tous les utilisateurs de l'annuaire Domino, les utilisateurs définis dans un annuaire LDAP ou une combinaison des deux. Étant donné que chaque serveur peut avoir une configuration d'annuaire unique, chaque serveur peut avoir un ensemble unique d'utilisateurs.
  • Utilisateurs authentifiés qui ne sont pas dans un répertoire. Si un utilisateur qui ne figure pas dans l'annuaire s'est connecté avec succès au serveur et a accédé à une base de données, il est ajouté à la liste des utilisateurs suivis. Un exemple de ceci est un utilisateur à certification croisée qui accède au serveur via HTTP.
  • Utilisateurs de l'ACL qui ne sont pas dans l'annuaire. Si le paramètre de sécurité du serveur n'est pas restrictif (par exemple « Autoriser n'importe qui à accéder à ce serveur »), alors tout utilisateur disposant d'un niveau d'accès éligible à une base de données est considéré comme un utilisateur autorisé et suivi en conséquence.

Qui n'est pas suivi

Les entités suivantes ne sont pas suivies :
  • Les serveurs.
  • Utilisateurs qui ne peuvent pas accéder au serveur parce qu'ils ne sont pas inclus dans une liste « autorisés à accéder au serveur » ou parce que l'accès leur est explicitement refusé dans la liste « non autorisé à accéder au serveur ».
  • Documents personne destinés uniquement à des fins de routage, par exemple ceux sans certificat Notes ni mot de passe HTTP.

Quand les utilisateurs sont-ils suivis

Bien que le serveur recherche quotidiennement les utilisateurs autorisés, les documents de suivi des utilisateurs ne sont mis à jour dans la base de données de suivi que lorsque leurs droits changent. Par exemple, si l'accès de Dana Smith/Renovations à son fichier courrier passe de Editeur à Gestionnaire, son document de suivi est mis à jour lors de l'analyse suivante pour refléter le changement d'autorisation.

Groupes, caractères génériques et accès par défaut

Les droits sont suivis au niveau de l'utilisateur individuel, mais les administrateurs Domino utilisent généralement des groupes Domino ou LDAP et des caractères génériques pour contrôler l'accès des utilisateurs aux serveurs et aux bases de données. Le collecteur de droits développe de manière récursive les « groupes de groupes » et/ou les « caractères génériques correspondant aux utilisateurs » pour projeter les droits du groupe ou du caractère générique sur un ensemble d'utilisateurs individuels. L'utilisation de groupes et de caractères génériques autorise explicitement un ensemble d'utilisateurs.

L'utilisation de l'accès -Default-, en revanche, peut implicitement autoriser de nombreux utilisateurs car le paramètre d'accès -Default- est projeté sur "tout le monde". Par exemple, si le groupe RenovationsManagers avec cinq membres a un accès Manager à une base de données, l'utilisateur Richard Smith/Renovations a un accès explicite en tant qu'éditeur et l'accès -par défaut- est Lecteur, alors toutes les personnes ayant accès au serveur autres que ces six utilisateurs sont avec accès Lecteur. Si le serveur permet à toute personne disposant de */Renovations d'accéder au serveur et que le répertoire configuré compte 1 705 utilisateurs Renovations, cette ACL par défaut autorise 1 700 utilisateurs avec un accès Lecteur. En général, l'accès -Default- doit être utilisé avec beaucoup de précautions.

Remarque : Si l'entrée ACL -Default- fournie avec une base de données système Domino autorise l'accès, cette entrée n'est pas considérée comme un droit et est exclue du traitement. Par exemple, les bases de données d'aide Domino sont livrées avec des entrées -Default-ACL qui autorisent l'accès en lecteur et, par conséquent, ces entrées -Default-ACL sont exclues du traitement.

Résumer les droits au niveau du domaine

Les données d'autorisation collectées quotidiennement par chaque serveur Domino d'un domaine sont également regroupées pour l'ensemble du domaine sur le serveur d'administration de domaine. La tâche de catalogue d'annuaire gère le processus de synchronisation et les données combinées de suivi des droits de chaque serveur sont regroupées dans une base de données entitlements.nsf sur le serveur d'administration. Le serveur d'administration possède à la fois sa propre base de données de suivi des droits ( entitlementtrack.ncf ) et les informations de suivi globales pour tous les serveurs du domaine ( entitlements.nsf ). Le serveur d'administration identifie le niveau d'accès le plus élevé pour chaque utilisateur du domaine et stocke quel serveur a le niveau d'accès le plus élevé pour un utilisateur particulier ainsi que les autres informations corroborantes telles que la base de données et les droits de l'utilisateur.
Remarque : La vue Historique dans entitlements.nsf inclut un bouton Instantané . Cliquez sur ce bouton pour générer un document résumant le nombre total actuel de droits par niveau d'accès, sur la base des données actuelles. Domino exécute automatiquement cette même action une fois par semaine afin de conserver un historique des modifications apportées aux droits.

Comment les informations sur les droits sont utilisées

Les informations d'autorisation sont collectées pour aider les clients Domino à surveiller leurs environnements. Ces données ne sont en aucun cas collectées par HCL et ne sont en aucun cas utilisées pour contrôler l’accès au serveur. La seule information que HCL peut vous demander de fournir est le « rapport sur les droits » qui contient le nombre total de droits par niveau d'accès, par exemple :
Entitlement Summary for 3/10/2010
	Manager         13
	Designer         7
	Editor         234
	Author        1200
	Reader        2400
	==================
	Total	    3834

Comment utiliser ces informations

Les informations contenues dans le résumé des droits peuvent être extrêmement utiles pour comprendre le nombre d'utilisateurs dont vous disposez avec différents niveaux d'accès et quels serveurs, bases de données, ACL et autorisations contribuent à ces chiffres. Par défaut, l'accès à ces bases de données est limité aux LocalDomainAdmins, mais comme il s'agit de vos données, vous pouvez en gérer l'accès comme bon vous semble, avec les mises en garde suivantes :
  • Ne supprimez pas les bases de données du collecteur de droits ou la base de données récapitulative du collecteur, sauf indication contraire du support HCL.
  • Ne modifiez pas le design ni le modèle de quelque manière que ce soit.
  • La base de données et les services de collecte sont proposés « tels quels » et la structure de la base de données ainsi que le processus de collecte de données peuvent être modifiés par HCL dans les versions ultérieures du produit.

Agent d'analyse ACL

Un agent nommé ACL Scanner est fourni « tel quel », sans support, en tant qu'outil qui peut être utile aux administrateurs pour obtenir des rapports immédiats résumant qui a accès à diverses bases de données. Vous pouvez utiliser l'outil pour contribuer à « renforcer » la sécurité en limitant davantage les personnes ayant accès à ces bases de données. L'un des avantages de l'utilisation de l'outil est que vous pouvez apporter des modifications à l'ACL et réexécuter l'outil pour obtenir un retour immédiat sur les effets de vos modifications, plutôt que d'attendre le prochain cycle du suivi des droits.

Pour exécuter l'agent, ouvrez entitlementtrack.ncf et sélectionnez Actions - ACL Scanner . Une boîte de dialogue apparaît qui vous propose les options suivantes :
  • Sélectionnez un serveur à analyser.
  • Spécifiez si vous souhaitez analyser des bases de données, des modèles ou les deux.
  • Spécifiez un utilisateur ou un groupe à rechercher, ou le nom spécial -Default- pour l'accès ACL par défaut.
  • Spécifiez un niveau ACL à rechercher : il recherchera ce niveau ou un accès supérieur.
  • Spécifiez éventuellement une liste de dossiers à ignorer.

Par exemple, vous pouvez rechercher sur un serveur des bases de données dont l'entrée -Default-ACL est Editeur ou accès supérieur.

L'outil analysera l'ACL de toutes les bases de données sélectionnées sur le serveur et générera un rapport répertoriant toutes les bases de données correspondantes. Dans cet exemple, vous pouvez choisir de modifier l'ACL de certaines de ces bases de données et de réduire le niveau d'accès de l'entrée -Default-. Vous pouvez alors immédiatement réexécuter le rapport pour voir les effets de vos modifications.