Restreindre les colonnes et les lignes accessibles

Une vue contient un sous-ensemble des colonnes des tables parents et peut éliminer des enregistrements de la vue en imposant des critères de sélection d’enregistrement. Soit une table nommée Orders avec une ligne par commande client et des colonnes Name, BillTo, ShipTo, TotalAmt, et PayMethod. L’employé travaillant dans l’entrepôt n’a rien à savoir sur le paiement : vous pouvez donc bloquer l’accès à ces colonnes avec ce genre de vue :

CREATE VIEW WHview AS
SELECT Name, BillTo, ShipTo, TotalAmt
FROM Orders;

Les applications servant au personnel de l’entrepôt utiliseraient cette vue plutôt que l’accès complet aux tables. Cela limiterait les risques d’erreur de coding ou de références utilisateurs compromises. Si le langage applicatif est un de ceux qui, comme RPG, ne supporte pas facilement les vues qui excluent des colonnes, vous pouvez remplacer ces colonnes par des masques de position, par exemple :

CREATE VIEW WHview AS
SELECT Name, BillTo, ShipTo, TotalAmt,
‘xxxx-xxxx-xxxx-‘||SUBSTR(PayMethod,-4)
FROM Orders;

Cela remplace un numéro de carte de crédit à 16 chiffres par des X, à l’exception des quatre derniers chiffres, généralement suffisants pour la plupart des vérifications mais insuffisants pour dévoiler le numéro de compte d’un client.

Pour restreindre encore davantage l’ensemble d’enregistrements accessibles à une application ou un utilisateur, vous pouvez ajouter une clause WHERE à la vue, avec des critères de sélection chargés d’exclure les enregistrements indésirables. Par exemple vous pourriez exclure les commandes de plus de 10 000 dollars en ajoutant WHERE TotalAmt < 10,001 à l’instruction CREATE VIEW.

La restriction d’accès par les vues est une bonne mesure de sécurité, mais pas sûre à 100 % contre des acteurs malveillants et rusés. Bien que vous puissiez coder votre application pour utiliser une vue spécifique, si cette application peut être compromise au point d’exécuter des instructions SQL arbitraires, et si l’assaillant peut découvrir ou deviner les noms des tables sous-jacentes aux vues, il peut contourner les contrôles des vues en accédant tout simplement aux tables originales. Vous pouvez empêcher cela en révoquant l’autorité sur ces vues sous-jacentes pour les utilisateurs non concernés.

REVOKE ALL on Orders FROM WHuser1;
GRANT INSERT, UPDATE, DELETE, SELECT on Orders to WHuser1;

Parfois, peu importe qui lit une colonne particulière, mais il faut limiter ceux qui peuvent la mettre à jour. C’est possible grâce au privilège de colonnes SQL GRANT UPDATE, qui permet aux utilisateurs de ne mettre à jour que les colonnes figurant dans l’instruction GRANT UPDATE. Soit l’instruction suivante :

GRANT UPDATE(Name,ShipTo), SELECT ON Orders to WHuser1;

Cela permet à l’utilisateur WHuser1 de mettre à jour seulement les colonnes Name et ShipTo dans la table Order. Ce n’est peut-être pas évident, mais il existe un moyen de bloquer les mises à jour sur toutes les colonnes : en révoquant simplement les droits UPDATE, plutôt que d’utiliser une liste null (par exemple GRANT UPDATE()…).