Autorisation

Au cours du processus d'autorisation, le gestionnaire de base de données obtient des informations sur l'ID d'autorisation de l'utilisateur authentifié. L'ID d'autorisation indique les opérations de base de données que l'utilisateur peut effectuer, y compris les objets de base de données auxquels il peut accéder. Les autorisations, qui sont déclarées explicitement dans Db2, permettent aux utilisateurs d'effectuer des actions spécifiques.

Pour un ID d'autorisation, les autorisations peuvent être accordées à différents niveaux :

• Primaire — Les autorisations principales sont accordées directement à l'ID d'autorisation.

• Secondaire : les autorisations secondaires sont accordées aux groupes et aux rôles dont l'ID d'autorisation est membre.

• Public — Le niveau public est un groupe Db2 spécial qui représente tous les membres de l'organisation.

• Sensible au contexte : ces autorisations sont accordées à un rôle contextuel fiable.

Niveaux d'autorité DB2

Db2 gère les autorités aux niveaux suivants :

• Niveau de l'instance ou du système :SYSADM,SYSCTRL,SYSMAINT, SYSMON

  • Niveau de base de données : DBADM SQLADM ((EXPLAINWLMADM),), SECADM (ACCESSCTRL), DATAACCESS

    • Niveau du schéma : SCHEMAADM (LOAD)ACCESSCTRL, DATAACCES S

    • Privilèges supplémentaires au niveau du schéma

Db2 prend en charge les privilèges supplémentaires suivants au niveau du schéma :

• SELECTINpermet à l'utilisateur de récupérer des lignes de toutes les tables ou vues définies dans le schéma.

• INSERTINpermet à l'utilisateur d'insérer des lignes et d'exécuter l'IMPORTutilitaire sur toutes les tables ou vues définies dans le schéma.

• UPDATEINpermet à l'utilisateur d'exécuter l'Updateinstruction sur toutes les tables ou vues actualisables définies dans le schéma.

• DELETEINpermet à l'utilisateur de supprimer des lignes de toutes les tables ou de toutes les vues actualisables définies dans le schéma.

• EXECUTEINpermet à l'utilisateur d'exécuter toutes les fonctions, méthodes, procédures, packages ou modules définis par l'utilisateur dans le schéma.

• CREATEINpermet à l'utilisateur de créer des objets dans le schéma.

• ALTERINpermet à l'utilisateur de modifier des objets dans le schéma.

• DROPINpermet à l'utilisateur de supprimer des objets depuis le schéma.

ID d'autorisation

Un ID d'autorisation Db2 est composé des éléments suivants :

• Type d'identifiant d'autorisation

  • Utilisateur individuel (U)

  • Groupe (G)

  • Rôle (R)

  • Publique (P)

• Valeur de l'ID d'autorisation

Un identifiant d'autorisation, auquel les autorités et les privilèges peuvent être associés, est utilisé pour l'identification et pour vérifier l'autorisation DB2.

Les termes d'identifiant d'autorisation principal suivants sont couramment utilisés dans Db2 :

• ID d'autorisation système : ID d'autorisation utilisé pour effectuer toute vérification d'autorisation initiale, telle que la vérification des CONNECT privilèges pendant CONNECT le traitement.

• ID d'autorisation de session : ID d'autorisation utilisé pour toute vérification d'autorisation de session à la suite des vérifications initiales effectuées pendant le CONNECT traitement. Pour voir la valeur actuelle de l'ID d'autorisation de session, utilisez le registre SESSION_USER spécial.

• ID d'autorisation de déclaration : ID d'autorisation (ainsi que l'autorisation secondaire associée IDs pour les groupes ou les rôles) utilisé pour les exigences d'autorisation d'une instruction SQL. Ceci est également utilisé pour déterminer la propriété de l'objet, le cas échéant. Elle peut varier en fonction du type d'instruction SQL et du contexte dans lequel elle est émise.

Les pouvoirs et les privilèges sont acquis par le biais de mécanismes explicites, tels que GRANT des REVOKE déclarations, ou de mécanismes implicites, tels que le privilège obtenu par le biais de la propriété d'objets. Ils peuvent également être acquis temporairement par le biais de multiples contextes de traitement. Par exemple, vous avez obtenu l'accès à une vue, ce qui vous donne implicitement accès aux objets contenus dans cette définition de vue. De plus, un EXECUTE privilège sur un package vous donnera accès à n'importe quel code SQL statique de ce package. L'autre moyen d'obtenir une autorité et des privilèges temporaires consiste à utiliser un contexte fiable.

Contexte fiable

Un contexte sécurisé est un objet de base de données qui définit une relation de confiance entre la base de données et un serveur d'applications externe ou un autre serveur de base de données. La relation de confiance repose sur les attributs de confiance suivants :

• Adresse IP

• ID d'autorisation du système

• Niveau de cryptage pour la communication de données

Si une connexion correspond aux attributs de confiance d'un objet de contexte sécurisé défini, une connexion sécurisée est établie. Il existe deux types de connexion sécurisée :

• Connexion sécurisée implicite : une connexion sécurisée implicite permet à un utilisateur d'hériter d'un rôle auquel il n'a pas accès en dehors du cadre de cette définition de connexion sécurisée. L'ID d'autorisation de session de la connexion est attribué à une adhésion temporaire à un rôle déclaré dans la définition du contexte sécurisé.

  Le schéma suivant montre un exemple de connexion sécurisée implicite dans laquelle la connexion à partir d'une seule adresse IP est autorisée.

   

  

  1. Le rôle dbconnrole est créé et la connexion à la base de données est accordée. Le contexte sécurisé ctximpl est créé en fonction de la connexion à l'authidABCaide de l'adresse IP 10.10.10.1 et du rôle par défautdbconnrole.

  2. L'utilisateur ABC peut se connecter à la base de données à partir de l'adresse IP10.10.10.1.

  3. L'utilisateur ne ABC peut pas se connecter à partir de l'adresse IP10.10.10.2.

• Connexion sécurisée explicite : une connexion sécurisée explicite permet à un serveur d'applications sécurisé ou à un autre serveur de base de données DB2 de changer l'ID utilisateur actuel sur la connexion existante de manière efficace. Un serveur d'applications établit la connexion d'origine à l'aide d'une demande de confiance explicite. Une fois la confiance établie, le serveur d'applications peut envoyer des demandes au serveur de base de données pour modifier l'ID d'autorisation de session pour toute nouvelle unité de travail. L'ID utilisé pour effectuer la demande de connexion initiale ne nécessite que des CONNECT privilèges sur le serveur.

  Les connexions fiables explicites sont utiles lorsqu'un serveur de niveau intermédiaire doit émettre des demandes de base de données pour le compte de plusieurs utilisateurs ayant différents ensembles de modèles d'accès à différents objets de base de données tels que des tables. L'objet de contexte sécurisé créé sur le serveur de base de données permet au serveur de niveau intermédiaire d'établir une connexion sécurisée explicite à la base de données, puis de remplacer l'ID utilisateur actuel de la connexion par l'ID utilisateur correspondant sans qu'il soit nécessaire de s'authentifier à nouveau auprès du serveur de base de données. Sur la base des privilèges accordés aux objets de base de données pour l'ID d'autorisation utilisateur, l'utilisateur peut continuer à effectuer des opérations, en conservant la véritable identité de l'utilisateur qui exécute des tâches spécifiques.

  Le schéma suivant montre un exemple de connexion sécurisée explicite dans laquelle USER1USER2, et USER3 toutes se connectent via le authidAPPID.

  

  1. Le contexte sécurisé ctxexpl est créé sur la base de la connexion authid APPID à l'aide de 10.10.10.1 l'adresse IP des utilisateurs USER1USER2, etUSER3.

  2. Les utilisateurs se connectent à un serveur de niveau intermédiaire.

  3. La connexion sécurisée est établie à l'aide deAPPID.