> Tech > Sécurité SQL

Sécurité SQL

Tech - Par Kevin Forsythe - Publié le 24 juin 2010
email

IBM a intégré en douceur la sécurité SQL à la panoplie de sécurité System i existante. Ces fonctions SQL ne se contentent pas d’imiter les mesures de sécurité existantes : elles les étendent et les renforcent. SQL connaît une rapide croissance et devient un langage de plus en plus incontournable pour tous les développeurs System i. Cet article actualise vos connaissances en sécurité SQL.
La sécurité SQL repose sur deux piliers : les deux instructions GRANT et REVOKE. En termes très simples, ces instructions SQL correspondent aux commandes CL Grant Object Authority (GRTOBJAUT) et Revoke Object Authority (RVKOBJAUT). Quand vous exécutez une instruction SQL GRANT ou REVOKE, vous utilisez des mots-clés pour octroyer ou révoquer des privilèges à un objet SQL. Sous le capot, le fait d’octroyer des privilèges SQL revient à octroyer une ou plusieurs autorités i5/OS à un ou plusieurs objets i5/OS.

Contenu complémentaire :

Automatisez vos audits de sécurité
Construisez vos propres systèmes de sécurité automatisés
Sécuriser votre base de données avec le point de sortie Open Database File

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.

Téléchargez gratuitement cette ressource

Aborder la Blockchain, comprendre et démarrer

Aborder la Blockchain, comprendre et démarrer

Une véritable révolution se prépare progressivement... les entreprises doivent veiller à ne pas rester à l’écart et se faire prendre de vitesse. Tout comme la mobilité ou encore le cloud, la blockchain est une composante essentielle de la transformation numérique. Découvrez, dans ce dossier, comment aborder, comprendre et démarrer la Blockchain

Tech - Par Kevin Forsythe - Publié le 24 juin 2010