Sécurité SQL

Pour en juger, voyons comment accorder des privilèges à une table SQL, en sachant bien que ces tables sont mises en oeuvre en tant que fichiers physiques i5/OS monomembres. Supposons que nous voulions accorder au profil de groupe INVGRP l’accès complet aux données de la table PARTMAST. Pour cela, utilisez l’instruction SQL suivante :

Grant Select,
Insert,
Delete,
Update,
On PartMast
To InvGrp

Cette instruction accorde au profil INVGRP les autorités i5/OS *OBJOPR, *READ, *ADD, *DLT et *UPD, au fichier physique PARTMAST. La figure 1 montre les autorités i5/OS correspondantes octroyées et révoquées par les instructions SQL GRANT et REVOKE, quand on les applique à une table de base de données. Il y a des correspondances similaires quand vous utilisez GRANT et REVOKE sur d’autres types d’objets base de données, y compris vues, types distincts, procédures stockées, fonctions définies par l’utilisateur, séquences et packages SQL.

Les instructions GRANT et REVOKE permettent le mot-clé ALL en raccourci pour tous les privilèges, mais sachez que le fait d’exécuter une instruction GRANT ALL n’a pas le même effet qu’une commande GRTOBJAUT…Aut(*All), parce qu’une instruction GRANT ALL n’accorde pas l’autorité *ObjExist. Par conséquent, une instruction GRANT ALL n’accorde pas à l’utilisateur l’autorité d’abandonner la table (c’est-à-dire de supprimer le fichier). De même qu’une instruction GRANT ALL n’accorde pas l’autorité *OBJMGT à moins de spécifier aussi With Grant Option sur l’instruction GRANT, comme dans l’exemple suivant :

Grant All
On PartMast
To InvGrp
With Grant Option

L’instruction REVOKE supprime des privilèges, ce qui revient à révoquer des autorités i5/OS sur un objet. Par exemple, pour révoquer le droit du profil INVGRP de supprimer des lignes dans la table PARTMAST, utilisez l’instruction suivante pour supprimer l’autorité objet *DLT du fichier physique sous-jacent :

Revoke Delete
On PartMast
From InvGrp

L’instruction REVOKE et la commande Revoke Object Authority (RVKOBJAUT) présentent quelques différences importantes. En premier lieu, une instruction REVOKE ALL ne révoque pas l’autorité *OBJEXIST i5/OS (si le profil utilisateur ou public avait déjà cette autorité). Sachant cela, s’il est nécessaire de révoquer une autorité *OBJEXIST existante, vous devriez utiliser RVKOBJAUT ou une autre commande CL ou interface i5/OS.

Le mécanisme d’autorité i5/OS donne le moyen de refuser explicitement à un profil utilisateur toute autorité sur un objet. Mais cette fonction n’est disponible qu’avec la commande CL Grant Object Authority (GRTOBJAUT), comme dans l’exemple suivant :

GRTOBJAUT
OBJ(PAYMAST)
OBJTYPE(*FILE)
USER(INVGRP)
AUT(*EXCLUDE)

Outre la sécurisation des tables, les commandes de sécurité SQL peuvent aussi limiter l’accès aux vues, index et autres objets SQL. Les vues SQL complexes font souvent référence à plus d’un objet. Ainsi, une vue créée avec la syntaxe suivante fait référence à deux tables :

CREATE VIEW POVIEW AS
SELECT * FROM POHEADER INNER JOIN PODETAIL
ON POHONO = PODONO

Cette vue fait référence aux données provenant de deux tables différentes et toute instruction GRANT appliquée à cette vue fournit l’autorité *READ sur toutes les tables (c’està- dire les fichiers physiques) référencées par la vue. Toutefois, les autorités *UPD, *DLT et *ADD ne sont accordées que sur la première table référencée dans la vue, c’està- dire le fichier POHEADER dans le cas présent. Les instructions REVOKE appliquées à des vues ne suppriment que les droits sur le fichier logique sous-jacent et jamais sur le(s) fichier(s) physique(s) sous-jacent(s). Par conséquent, après avoir exécuté une instruction GRANT sur une vue et après avoir accordé implicitement l’autorité *UPD à une table référencée, vous ne pouvez pas supprimer cette autorité *UPD sur la table simplement en exécutant une instruction REVOKE sur la vue. Pour supprimer l’autorité *UPD sur la table, exécutez une instruction REVOKE UPDATE sur la table elle-même.