Comptes d'utilisateurs et groupes

Les comptes d'utilisateurs identifient les connexions à la base de données. Les privilèges de base de données ou de jeu de données accordés ou refusés à un compte utilisateur déterminent ce à quoi l'utilisateur peut accéder. Les comptes d'utilisateurs peuvent être regroupés en fonction des tâches qu'ils doivent accomplir afin de simplifier la gestion des privilèges.

Comptes d'utilisateurs

Les comptes d'utilisateurs sont des noms et des mots de passe uniques utilisés pour identifier une personne ou une application cliente qui se connecte à votre base de données. Dans ArcGIS, les comptes d'utilisateurs déterminent qui possède quelles données. Les comptes d'utilisateurs offrent également un moyen de contrôler quel type d'accès (le cas échéant) une personne ou une application cliente a sur une base de données ou une géodatabase et ses jeux de données.

Les comptes d’utilisateurs pour IBM Db2 sont créés au niveau du système d’exploitation ou du réseau.

N'utilisez pas de délimiteurs (points d'interrogation, par exemple) pour forcer la création d'un compte utilisateur ou d'un nom de groupe contenant des caractères ou une casse non pris en charge par la base de données sous-jacente. Si un objet de base de données, par exemple un nom d'utilisateur, est créé avec des délimiteurs, ces derniers doivent être utilisés lorsque la base de données est interrogée au sujet de cet objet. ArcGIS n'entoure pas les noms d'objets de délimiteurs lors de l'interrogation de la base de données. Par conséquent, si la base de données ne prend pas en charge les caractères dans votre nom d'utilisateur ou nom de groupe sans délimiteurs, votre connexion à la base de données depuis ArcGIS échouera.

Propriété des données

Pour ArcGIS, l'utilisateur qui crée des tables, des classes d'entités et des vues dans une géodatabase ou une base de données possède ces jeux de données. Par exemple, l'administrateur de géodatabase crée la géodatabase : il est donc propriétaire des tables système de la géodatabase, créées dans la base de données. De même, un utilisateur qui crée une classe d'entités en est propriétaire.

L'utilisateur, dont le nom sert à établir la connexion à la géodatabase lors de la création des jeux de données, est le propriétaire des données.

Les utilisateurs propriétaires des données doivent aussi avoir des structures de base de données présentant le même nom que le nom d'utilisateur.

Par exemple, les membres de personnel à mi-temps Boris et Basil sont autorisés à créer des jeux de données dans la géodatabase. Boris et Basil utilisent le même ordinateur. Si tous deux utilisent le compte de Basil pour se connecter à la géodatabase dans ArcGIS, tous les jeux de données créés par Boris ou Basil appartiendront à Basil et seront stockés dans sa structure.

Si Boris veut stocker les données qu'il crée dans sa structure, il doit modifier les propriétés de la connexion à la base de données et se connecter à la base de données avec son propre nom d'utilisateur avant de commencer à créer des données.

Il est important de savoir qui est propriétaire des données car vous ne pouvez pas supprimer de compte d'utilisateur de la base de données si l'utilisateur est propriétaire des données, et c'est l'utilisateur qui a créé le jeu de données qui contrôle le niveau d'accès des autres utilisateurs au jeu de données.

Accès utilisateur

Votre base de données doit être en mesure de vérifier les comptes d'utilisateurs qui essaient de se connecter. Autrement dit, l'administrateur de base de données doit ajouter des utilisateurs à la base de données. La base de données vérifie la liste d'utilisateurs pour s'assurer qu'un utilisateur est autorisé à établir une connexion. Ce processus s'appelle l'authentification.

Deux types d’authentification sont utilisés avec les bases de données Db2 : l’authentification du système d’exploitation et l’authentification de la base de données.

L'authentification du système d'exploitation indique qu'un utilisateur se connecte à un ordinateur, et les références pour l'autorisation sont fournies à la base de données par le système d'exploitation de l'ordinateur de l'utilisateur. Pour l'utilisateur se connectant, cela signifie qu'il doit seulement se connecter sur son ordinateur et qu'il n'a pas besoin de se connecter séparément à la base de données. Pour l'administrateur de base de données, cela signifie que la connexion existante doit être ajoutée à la base de données et que la base de données doit être configurée pour reconnaître la connexion existante de l'utilisateur.

Si vous utilisez l'authentification de la base de données, les utilisateurs se connectent au serveur, puis doivent se connecter à la base de données.

Remarque :

Bien que Db2 ne comporte pas de comptes d’utilisateurs de base de données, vous conservez la possibilité d’utiliser l’authentification de la base de données lorsque vous vous connectez à partir d’ArcGIS. Vous pouvez ainsi enregistrer le nom d'utilisateur et le mot de passe spécifiques d'un utilisateur.

Une fois que les utilisateurs sont ajoutés, l'administrateur de base de données doit également accorder des privilèges spécifiques aux utilisateurs pour déterminer ce qu'ils peuvent et ne peuvent pas faire dans la base de données. La base de données vérifie ces privilèges lorsqu'un utilisateur authentifié essaie d'accéder à la base de données ou de la modifier. Ce processus s'appelle l'autorisation. Dans ArcGIS, les propriétaires des données peuvent également accorder des privilèges sur leurs données aux autres utilisateurs ou groupes.

Les types des privilèges accordés à un utilisateur reposent sur le type de travail que l'utilisateur doit effectuer. Certains utilisateurs doivent uniquement se connecter à la base de données et afficher des données spécifiques. Les autres utilisateurs doivent créer des jeux de données. La section ci-dessous explique comment les comptes d’utilisateurs peuvent être regroupés afin de simplifier la gestion des privilèges.

Groupes ou rôles

La plupart des systèmes de gestion de bases de données permettent à l'administrateur de base de données de regrouper les utilisateurs par besoins d'accès aux données et d'attribuer des privilèges au groupe. Cela peut réduire le temps passé à modifier les privilèges de chaque utilisateur individuel et simplifie l'administration d'un grand nombre de privilèges pour un plus grand nombre d'utilisateurs. Vous pouvez donc utiliser des groupes (aussi nommés rôles, types ou autorités selon le système de gestion de base de données) pour accorder aux utilisateurs des droits correspondant à leur fonction commune.

Les catégories ou groupes d'utilisateurs courants correspondent à la consultation, à la modification et à la création de données.

Dans la plupart des cas, les droits accordés aux groupes n'empêchent pas l'attribution de droits aux utilisateurs individuels dans les géodatabases d'entreprise. Vous pouvez, par exemple, accorder les privilèges minimum requis pour créer des données dans la base de données au groupe de créateurs de données (qui peut comprendre l'administrateur de la géodatabase), et accorder des privilèges supplémentaires au seul administrateur de la géodatabase. Toutefois, chaque système de gestion de base de données gère différemment les priorités de privilèges ; reportez-vous à la documentation de votre système de gestion de base de données pour en savoir plus sur le comportement des privilèges pour les rôles et les utilisateurs individuels.

De plus, la plupart des systèmes de gestion de bases de données proposent des groupes prédéfinis. Parmi ceux-ci, citons le rôle PUBLIC.

Le groupe ou rôle PUBLIC est essentiellement une variable qui équivaut à l'ensemble des personnes connectées à la base de données ; par conséquent, tout droit accordé à PUBLIC est accordé à toute personne connectée à la base de données. Dans certains cas, tous les utilisateurs peuvent avoir besoin d'un privilège donné. Par exemple, pour se connecter aux bases de données SQL Server ou Db2, les utilisateurs doivent bénéficier du privilège CONNECT. Comme tous les utilisateurs ont besoin de ce privilège pour se connecter, SQL Server et Db2 accordent ce privilège à PUBLIC par défaut.

Quelquefois, des privilèges de niveau élevé sont attribués par défaut au rôle PUBLIC lors de la création de la base de données. Toutefois, pour des raisons de sécurité, il est recommandé de n'accorder au rôle PUBLIC que les privilèges absolument nécessaires.

Pour les autres groupes prédéfinis, reportez-vous à la documentation de votre système de gestion de base de données.

Astuces pour le regroupement d'utilisateurs

Voici quelques astuces de regroupement des utilisateurs dans le système de gestion de base de données :

• Création de groupes (rôles) distincts pour les privilèges système et objet. Ceci permet à l'administrateur de base de données de gérer les privilèges de base de données en les octroyant sur les groupes système et aux propriétaires de données sur leurs jeux de données en les octroyant aux groupes d'objets.
• Choix d'une convention d'affectation de noms indiquant le type de chaque groupe (rôle) afin de faciliter leur consultation. Par exemple, le groupe pouvant modifier l'ensemble des données foncières peut être nommé LANDBASE_EDITORS.
• Accordez des privilèges directs à l'administrateur de géodatabase et par l'intermédiaire de groupes (rôles) pour tous les autres utilisateurs. L'administrateur de géodatabase est une entité unique. Dans la plupart des cas, il n'existe qu'un seul utilisateur de ce type pour toute géodatabase, et il ne fait pas partie d'un regroupement logique d'utilisateurs plus important. Les administrateurs de base de données expérimentés encouragent l'octroi de privilèges directs à ce type de comptes d'administrateurs d'application. Par contre, les comptes non administrateurs doivent recevoir leurs privilèges par l'intermédiaire de groupes représentant leur description de poste, leurs responsabilités au sein du projet ou une autre classification logique de l'organisation.
• Gestion séparée des rôles et des privilèges directs pour les comptes non administrateurs. Lorsque les comptes non administrateurs se voient accorder des privilèges directement et par l'intermédiaire de rôles, un modèle de sécurité bien planifié peut rapidement évoluer vers un désordre ingérable, dont la restauration vers un état organisé peut demander du temps et des efforts considérables. Il est utile de définir des stratégies à suivre pour les propriétaires de données lors de l'attribution de droits d'accès à leurs données.

  Si exceptionnellement un compte non administrateur a des exigences de sécurité vraiment uniques, envisagez d'accorder certains privilèges directement pour éviter de compliquer le modèle de sécurité basé sur les rôles. Gardez une trace de ces cas ; ils doivent rester l'exception plutôt que la règle.