Nouveautés DB2 de la version 7.2

 

DB2

 

 




L' option 47 de 5770SS1 (non facturable) apporte RCAC


Row and Column Access Control


Il s'agit de pouvoir indiquer des « droits » à la colonne ou à la ligne qui s'appliquent y compris aux personnes ayant les droits d'administrateur


Ces deux nouvelles options sont accessibles via System i Navigator ou Navigator for i (version Web).

 

•CREATE MASK indique si une colonne est retournée tel que ou totalement/partiellement masquée ('xxx-xxx-xxx-1234' pour un n° de CB)

CREATE [or REPLACE] MASK tel_MASK ON bdvin1/producteurs
 FOR COLUMN pr_tel RETURN
  CASE
    WHEN SESSION_USER = 'QSECOFR'                                          
                                               THEN PR_TEL
    WHEN SESSION_USER = 'CM'
                                               THEN left(pr_tel , 3) concat 'XXXXXXXXXXXXX'
    ELSE NULL
END
ENABLE


Sous System i Navigator


Puis
ALTER TABLE bdvin1/producteurs
  ACTIVATE COLUMN ACCESS CONTROL


Vu par System i Navigator




Attention vous devez avoir les droits QIBM_DB_SECADM (même QSECOFR !)
sinon vous recevrez SQL0552

 

Pour donner ces droits WRKFCNUSG

Option 2 pour modifier

Indiquez

la restriction étant posée, vous pouvez la modifer, retrouver le source et la supprimer, toujours pas System i Navigator




Les restrictions RCAC s'appliquent dans tous les contextes :

DSPPFM du fichier sous QSECOFR ->

DSPPFM sous le profil CM ->

 

Bien sûr la valeur retournée doit être compatible avec le type de la colonne (sinon vous recevez SQL0678)

ICI avec la colonne CAV_PRIX qui est numérique

•1er test refusé : la valeur de remplacement est caractère (xxxxxxxxxx)



•2eme test accepté : la valeur de remplacement est 0


Un MASK n'empêche pas les insertions (par contre vous ne retrouvez pas forcement la donnée telle que vous l'avez insérée, mais masquée)

 

Le problème se pose éventuellement lors des mises à jour :

Exemple , le pgm suivant lit et modifie le producteur 1 en RPG ( fichier qui possède un MASK sur PR_TEL)

lors de l'Update RPG, il met à jour la ligne suivant les données qu'il a lui même reçu.

Suite à un CALL par CM (c'est QSECOFR qui regarde le contenu de la table) :

Y compris un Update RPG avec la fonction %fields

résultat identique

La documentation conseille dans ce cas :

  • de faire un trigger, qui rétablisse l'ancienne valeur

    IF substr(new.PR_TEL, 4, 13) = 'XXXXXXXXXXXXX' THEN
      new.PR_TEL = old.PR_TEL;

    ... /...


  • de faire une contrainte qui refuse la valeur produite par le MASK

    CHECK substr(PR_TEL, 4, 13) <> 'XXXXXXXXXXXXX'
     

    • Ou mieux, faites une contrainte qui utilise la nouvelle clause
       ON UPDATE VIOLATION

      CHECK substr(PR_TEL, 4, 13) <> 'XXXXXXXXXXXXX'
        ON UPDATE VIOLATION PRESERVE PR_TEL

      L'ancienne valeur sera alors replacée automatiquement, sans message d'erreur

 

Seul un UPDATE SQL (toujours réalisé par CM) , ne met à jour que certains champs (donc ne touche pas aux autres)
et permet d'éviter la création d'une contrainte.



Résultat :



Enfin, les données sont masquées, juste avant l'affichage, c'est à dire après jointure et GROUP BY

par exemple, le SELECT suivant, qui donne le nombre de clients par indicatif téléphonique

SELECT LEFT(PR_TEL, 5) , count(*) as nombre
   FROM producteurs
GROUP BY LEFT(PR_TEL, 5)


Affiche :
si la colonne n'est pas masquée si la colonne est masquée
05 55 3
05 56 7
05 58 4
05 xx 3
05 xx 7
05 xx 4



•CREATE PERMISSION indique la(les) règles(s) qui font qu'une ligne peut être vue

Toute ligne ne correspondant pas à la règle n'est pas retournée :

Exemple CM ne doit pas voir l'appellation 13 :

CREATE [or REPLACE] PERMISSION VINS_ROW_ACCESS ON bdvin1/vins
FOR ROWS
 WHERE
     SESSION_USER <> 'CM'
         OR (SESSION_USER = 'CM'
                  and (appel_code <> 13 or appel_code IS NULL)
               )
ENFORCED FOR ALL ACCESS
ENABLE

rappelez vous, on indique ce qui peut être vu (une affirmation, donc)

Sous System i Navigator

la restriction étant posée, vous pouvez toujours la modifer, retrouver le source et la supprimer, avec System i Navigator



On aurait aussi pu faire deux permissions

CREATE PERMISSION VINS_ROW_ACCESS1 ON bdvin1/vins
FOR ROWS
 WHERE
     SESSION_USER <> 'CM'

ENFORCED FOR ALL ACCESS
ENABLE ;
--------------------------------------------------------------------------------------
CREATE PERMISSION VINS_ROW_ACCESS2 ON bdvin1/vins
FOR ROWS
 WHERE
     SESSION_USER = 'CM'
                  and (appel_code <> 13 or appel_code IS NULL)
ENFORCED FOR ALL ACCESS
ENABLE ;
un peu moins performant en temps de réponse...

Puis
ALTER TABLE bdvin1/vins
  ACTIVATE ROW ACCESS CONTROL

Le système ajoute alors une permission implicite QIBM_DEFAULT_nomdetable_schema où la permission est si 0=1, donc toujours fausse.

seules les permissions explicites autorisent des lignes à être vues (en bref tout ce qui n'est pas autorisé est interdit)

Donc, Attention, si vous enlever la permission sans désactiver ROW ACCESS CONTROL
 plus aucune ligne ne peut être extraite (le fichier apparaît toujours comme vide !)

 

Avec notre PERMISSION "VINS_ROW_ACCESS":

SELECT COUNT(*) from VINS , sous QSECOFR affiche 25.221

SELECT Count(*) from VINS WHERE appel_code = 13 indique un nombre de 811 vins pour cette appellation


SELECT COUNT(*) from VINS , sous CM affiche 24.410

 

Une PERMISSION, peut empécher une insertion ou une mise à jour, qui ne respecte pas la règle

Exemple avec APPEL_CODE à 13 (vous recevez SQ20471)

 

Administration :

pour modifier : ALTER MASK | PERMISSION le-nom

pour retirer : DROP MASK | PERMISSION le-nom

tant que vous n'avez pas activé les droits par ALTER TABLE, les MASK et les PERMISSIONS sont inopérants


Les mêmes paramètres sont proposés sur CREATE TRIGGER / CREATE FUNCTION, y compris sur les assistants de création :

Navigator for I System i Navigator

 

La version 1.3 de Omnifind (5733OMF) est la seule compatible RCAC

Vous trouverez sur les procédures

 

Administration

La mise en place ou le retrait des droits RCAC :

  et des enregistrements dans le journal de la table, de code D, type :




Les droits RCAC sont visibles (mais non modifiables) par EDTOBJAUT/DSPOBJAUT



L'API Retrieve Database File Description (QDBRTVFD) a été modifiée
 (nouveau format FILD0500 pour retrouver les informations RCAC)


Sinon, pour voir la liste des droits RCAC, regarder SYSCONTROLS et SYSCONTROLSDEP

• SysControls de QSYS2

RCAC_SCHEMA
RCAC_NAME
RCAC_OWNER
TABLE_SCHEMA
TABLE_NAME
TBCORRELATION
COLUMN_NAME
SYSTEM_COLUMN_NAME
SYSTEM_TABLE_NAME
SYSTEM_TABLE_SCHEMA
CONTROL_TYPE
ENFORCED
IMPLICIT
ENABLE
CREATE_TIME
LAST_ALTERED
IASP_NUMBER
LABEL
LONG_COMMENT
RULETEXT.

VARCHAR(128)
VARCHAR(128)
VARCHAR(128)
VARCHAR(128)
VARCHAR(128)
VARCHAR(128)
VARCHAR(128)
CHAR(10)
CHAR(10)
CHAR(10)
CHAR(1) M=Mask | R=Row permission
CHAR(1)
CHAR(1)
CHAR(1)
TIMESTAMP
TIMESTAMP
SMALLINT
VARCHAR(50)
VARCHAR(2000)
DBCLOB -> c'est ici qu'est la règle, en clair.

Par exemple :

SELECT RCAC_NAME , cast(RULETEXT as char(2000) ) FROM QSYS2.SYSCONTROLS
  WHERE RCAC_SCHEMA = 'BDVIN1'


• SYSCONTROLSDEP affiche les éléments dépendants, par exemple :

CREATE TABLE USEROK
(username char(10), appel_code int ) ;
---------------------------------------------------------------------------
-- l'utilisateur CM ne doit voir que les appellations 13 et 144

INSERT INTO USEROK VALUES('CM', 13);
INSERT INTO USEROK VALUES('CM', 144);

CREATE PERMISSION PROD_ROW_ACCESS1 ON producteurs
FOR ROWS
WHERE
appel_code in (select appel_code from USEROK
                        where username = SESSION_USER)
ENFORCED FOR ALL ACCESS
ENABLE ;
---------------------------------------------------------------------------
ALTER TABLE producteurs
ACTIVATE ROW ACCESS CONTROL
ENFORCED FOR ALL ACCESS
ENABLE ;

SyscontrolsDep contient :


• Impact sur les requêtes SQL :

Autant les masques ne s'appliquent que lors de l'affichage (n'ont donc pas d'impact sur les jointures, par exemple)

Autant les permissions sont plus déterminantes :

la jointure n'a lieu qu'avec les lignes autorisées.

INSERT into cible (SELECT * from SOURCE)

Commandes système :

Enfin attention


©AF400