Politique de sécurité
et IBM i
Commencons par un peu de théorie :
La gestion de la sécurité s'appuie sur la notion de
profil utilisateur (objet *USRPRF dans QSYS)
Un profil est rattaché à une des Classes d'utilisateur
Chaque classe engendre des droits spéciaux
La gestion des droits par objet est la base de la sécurité sur
un IBM i
tout objet possède des droits publics
(indiquant les droits par défaut pour un utilisateur "lambda"
indiqué par *PUBLIC)
et des droits
nominatifs ou privés.
les droits sont révisables par EDTOBJAUT en indiquant le type d'objet
F11 permet de voir le détail.
Droits sur un objet (EDTOBJAUT) |
(1) Utilisateur
*PUBLIC définit les droits de tous les utilisateurs non spécifiquement désignés
et ne figurant pas sur la liste d'autorisation protégeant l'objet.
*GROUP indique le groupe auquel vous appartenez
(2) Types de droits standards
correspond en fait à un ensemble de droits élémentaires ou USER DEF
*USE : *OBJOPER + *READ|*EXECUTE *CHANGE : *OBJOPER + *READ|*ADD|*UPDATE|*DELETE|*EXECUTE *ALL : *OBJOPER|*OBJMGT|*OBJEXIST|*OBJALTER
+ *READ|*ADD|*UPDATE|*DELETE|*EXECUTE *EXCLUDE: aucun
(3) Droits sur l'objet
Opér (*OBJOPER)
Droits d'intervention sur l'objet : Permet d'utiliser un objet
et de consulter ses attributs dans les limites des droits sur
les données détenus par l'utilisateur.
Gest (*OBJMGT)
Droits sur la gestion des objets : permet de définir le niveau
de sécurité d'un objet, de le déplacer ou de le rebaptiser.
Permet également d'ajouter des membres à un objet, si ce dernier
est un fichier base de données.
Exist (*OBJEXIST)
Droits sur l'existence des objets : Permet de contrôler
l'existence et la propriété d'un objet.
Modif (*OBJALTER)
Les droits de modification des attributs permettent de modifier les
attributs d'un objet (par exemple, l'ajout ou le retrait de
déclenchements [trigger] pour un fichier base de données).
Réf (*OBJREF)
Les droits de référence permettent d'indiquer que l'objet constitue
le premier niveau [parent] d'une contrainte référentielle.
(4) Droits sur les données
Lect (*READ)
Droit de lecture : Permet d'accéder au contenu d'un objet.
Ajt (*ADD)
Droit d'ajout : Permet d'ajouter des données à un objet.
MàJ (*UPDATE)
Droit de mise à jour : Permet de modifier les données d'un objet.
Sup (*DELETE)
Droit de suppression : Permet de supprimer les données d'un objet.
Exécut (*EXECUTE)
Les droits d'exécution permettent de lancer un programme ou
d'effectuer une recherche dans une bibliothèque (ou un répertoire).
Ils peuvent aussi être indiqués en syntaxe SQL :
ACCORDER DES DROITS
I ---ALL------(tous les droits)---I
I ---ALTER----(*OBJALTER)---------I
I ---DELETE---(*OBJOPR + *DELETE)-I
GRANT ---I ---INDEX----(*OBJALTER)---------I-------->
I ---INSERT---(*OBJOPR + *ADD)----I
I ---SELECT---(*OBJOPR + *READ)---I
I ---UPDATE---(*OBJOPR + *UPD)----I I--(col1,col2*)----I I ---REFERENCE(*OBJREF)-----------I
----- ON nom(de table ou de vue)------------------->
----- TO -nomprofil------(1 nom de profil)--------->
I-PUBLIC----I (*PUBLIC)
-------------------------------------------------.
I---WITH GRANT AUTORITY(*OBJMGT)---I
(donne le droit de gérer les droits)
* pour le droit UPDATE on peut restreindre le droit de mise à jour à certaines colonnes
RETIRER DES DROITS
I ---ALL------(tous les droits)---I
I ---ALTER----(*OBJALTER)---------I
I ---DELETE---(*OBJOPR + *DELETE)-I
REVOKE ---I ---INDEX----(*OBJMGT)-----------I-------->
I ---INSERT---(*OBJOPR + *ADD)----I
I ---SELECT---(*OBJOPR + *READ)---I
I ---UPDATE---(*OBJOPR + *UPD)----I I ---REFERENCE(*OBJREF)-----------I
----- ON nom(de table ou de vue)------------------->
----- TO -nomprofil------(1 nom de profil)-------.
I-PUBLIC----I (*PUBLIC)
Là encore, vous pouvez utiliser Navigator for i
Pour protéger certaines colonnes, vous pouvez :
L' option 47 de 5770SS1 (non facturable) est disponible depuis la version 7.2 : RCAC
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).
 |
 |
| Elles sont aussi désormais intégrées à l'option Schémas d'ACS, que nous utiliserons pour ce cours |  |
Pour administrer ces deux droits particluiers (à la colonne et à la ligne), vous devez être autorisé à la fonction QIBM_DB_SECADM (même QSECOFR)
Pour donner ces droits à la fonction : WRKFCNUSG
Option 2 pour modifier
Indiquez
*USED face à Droits spécial *ALLOBJ pour que toute personne de type QSECOFR puisse manipuler ces notions
*ALLOWED face à Droits par défaut pour que TOUT LE MONDE puisse manipuler ces notions (déconseillé !)
sinon indiquez un profil à ajouter (Utilisateur) et *ALLOWED (Utilisation) pour autoriser un profil ou un groupe
OU utilisez Administration d'applications sous Navigator for i
Pour retrouver les utilisateurs autorisés :
SELECT function_id, user_name, usage, user_type
FROM function_usage
WHERE function_id='QIBM_DB_SECADM'
ORDER BY user_name
•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 |
| WHEN CURRENT DATE IN (SELECT C.DATEREF FROM CALENDRIER C WHERE C.OUVRABLE = 'O') |
| WHEN SESSION_USER = ( SELECT U . USERNAME FROM USEROK U WHERE U . USERNAME = SESSION_USER AND ( U . INFO_AUT = '1' OR U . INFO_AUT = '2' ) .... ) |
Sous ACS
Puis
| ALTER TABLE bdvin1/producteurs ACTIVATE COLUMN ACCESS CONTROL |
Définition de la table, vue par ACS
Attention vous devez avoir les droits QIBM_DB_SECADM (même QSECOFR !)
sinon vous recevrez SQL0552 
la restriction étant posée, vous pouvez la modifer, la supprimer et en retrouver le source, toujours par ACS
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 :
|
En effet, la 7.2 apporte cette nouvelle clause VIOLATION sur les Check constraint
ON INSERT VIOLATION SET column-name = DEFAULT
L'erreur n'est pas signalée, la valeur par défaut est insérée
ON UPDATE VIOLATION PRESERVE column-name
L'erreur n'est pas signalée, la valeur précédente est conservée
Exemple
Vu par ACS
suite à deux INSERT, dont l'un ne renseignant pas la colonne Verifok, nous avons bien les valeurs attendues
select * from VERIF
Mais suite à cet INSERT qui aurait du être refusé
Nous voyons
Enfin, suite à cet UPDATE, lui aussi invalide
Nous voyons toujours
NB : aucun message dans la LOG pour signaler les "remplacement" de valeur
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 | ||||||||||||
|
|
•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 ACS
la restriction étant posée, vous pouvez toujours la modifier, retrouver le source et la supprimer, avec ACS
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
• activer les droits, avant d'avoir défini MASK ou PERMISSION rend l'accès à cette table compliqué (tout est masqué)
C'est pourquoi les ordres de création et le nouvel ordre ALTER TRIGGER ont été modifiés.
ALTER TRIGGER, nouveau en 7.2, permet de modifier certains paramètres d'un TRIGGER :
SECURED ce trigger est sécurisé (compatible) avec les droits RCAC
NOT SECURED ce trigger n'est pas compatible avec les droits RCAC (le défaut)
Il est impossible de modifier cet attribut quand des droits RCAC sont actifs
ENABLE, le trigger est actif (dft)
DISABLE, le trigger n'est plus actif
il est impossible de créer un trigger NOT SECURED quand des droits RCAC sont actifs
Détail du message SQ20470
par contre, cet ordre fonctionne
Lors d'un insert, le trigger est lancé sans problème
->
Les mêmes paramètres sont proposés sur les assistants de création :
| Navigator for I | ACS |
 |
 |
 |
 |
La version 1.3 de Omnifind (5733OMF) est la seule compatible RCAC
Vous trouverez sur les procédures
et des enregistrements dans le journal de la table, de code D, type :
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) |
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 INSERT INTO USEROK VALUES('CM', 13); |
| 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)
- vous subissez les MASK
- vous ne copiez que les lignes autorisées par les permissions
- les lignes copiées doivent être valides dans la table cible (si elle même possède des droits RCAC)
- SQE fait une jointure, le cas échéant : si le droit RCAC référence une autre table (cas d'utilisation de notre table USEROK)
ici, sous VISUAL Explain, mais aussi dans les moniteurs SQL
Il signale qu'il y a des droits RCAC
il peut recommander des index
Commandes système :
Enfin attention
Pour plus de détails et plus d'exemples, voyez ce redbook chez IBM.
Copyright © 2020 VOLUBIS
