SQL prend une place de plus en plus importante dans les développements.
Il faut donc prendre des mesures de protection spécifiques sur le SQL embarqué qu’on ne prenait pas forcément en RPGLE.
Par exemple si vous utilisez du cryptage avec les fonctions ENCRYPT et DECRYPT il est important de ne pas afficher la clé de cryptage.
1) Le debug
Le premier risque c’est le debug : vous allez voir la clé de décryptage, même si vous utilisez une variable host c’est facile à voir.
La solution, c’est quand vous compilez votre programme le paramètre DBGENCKEY(‘Votre_clé’)
Vous devrez désormais indiquer votre clé pour débuguer.
Attention bien à ne pas perdre cette clé qui vous sera demandée à chaque de bug !
2) Informations sur les instructions SQL embarquées
Vous avez des vues qui vous permettent de voir le code sql embarqué dans vos programmes RPGLE
exemple :
la vue QSYS2.SYSPROGRAMSTMTSTAT
Pour vous prémunir vous devrez utiliser une variable host et ainsi vous n’aurez pas la valeur de décryptage dans l’instruction …
3) Le cache sql
Vous avez l’instruction exécutée que vous pouvez consulter dans le cache SQL, par exemple par ACS
Comment faire pour que la valeur ne soit pas affichée et pas affichable dans la requête avec les variables ?
Vous avez une procédure SYSPROC.SET_COLUMN_ATTRIBUTE
CALL SYSPROC.SET_COLUMN_ATTRIBUTE(‘GENVOI’, ‘GPARAM’, ‘PWORD’, ‘SECURE YES’);
plus de detail ici
Vous avez :h dans le cache et quand vous faites <gestion instruction SQL et variables>
la zone apparait en sécure
Vous devrez faire cette opérations sur toutes les zones !
https://www.ibm.com/docs/en/i/7.4?topic=services-set-column-attribute-procedure
4) Les SQL packages
Le SQL package est un objet qui stocke des informations pour en tirer partie au cours d’une future utilisation, depuis l’arrivée du moteur SQE, ils sont utilisés en second par rapport au cache SQL
Il faut différencier 2 types de SQL PACKAGE :
- Les sql packages qui font partie de votre programme pour les SQL statiques, vous pouvez les consulter par la commande PRTSQLINF de votre programme sqlrpgle qui produira un spool comme celui ci :
On voit que également en ayant utilisé une variable hôte que l’information n’apparait pas en claire
- Il existe une deuxième catégorie de packages SQL qui sont dus à l’utilisation du Extended Dynamic SQL, ce sont des objets qui sont créés essentiellement pour des accès ODBC et dynamiques, ce sont des objets de type *SQLPKG, ils sont en principe créés dans la bibliothèque qui contient la base de données. SQL utilisera les informations qui sont stockées à l’intérieur quand il en aura besoin. Il est difficile de voir le contenu des ces objets , cependant vous pouvez faire un dump de cet objet, par la commande DMPOBJ comme ci-dessous , mais encore une fois pas de contenu des variables hôtes.
Ces objets peuvent être supprimés, le système les recréera automatiquement quand, par exemple, vous changez de version d’IBM i ou quand il occupe trop de place. Attention cependant, il en existe certains qui font partie de SQL comme
QSQLPKG2 de QSYS
QSQXDPKG de QSYS
En règle générale, il ne faut pas toucher à ceux dont le nom commence par Q, ni aux objets qui sont dans QSYS.
Ci dessous un lien pour en savoir plus ces objets
https://www.ibm.com/support/pages/sql-package-questions-and-answers
Complément sur la procédure SET_COLUMN_ATTRIBUTE
Merci Christian
la procédure SET_COLUMN_ATTRIBUTE cache aussi :
- la valeur des marqueurs qui sont dans les lignes QQRID=3010 des moniteurs de performance et images instantanées de cache de plan.
- la valeur des marqueurs qui sont dans les attributs d’un graphe Visual Explain (voir image).
- la valeur des marqueurs dans le pseudo SQL des nœuds de VE (voir image).
Conclusion :
SQL change la donne sur certains points, vous devrez adapter votre sécurité en fonction.
Dans tous les cas, préférez une variable host à un hardcoding qui apparait en clair.
Il y a certainement d’autres choses à mettre en œuvre, mais ces quelques astuces vous donnent une idée de ce que vous devrez mettre en œuvre
