, , Sécuriser le SQL embarqué

SQL prend une place de plus en plus importante dans les développements

il faudrait donc prendre des mesures de protection spécifiques sur le SQL embarqué qu’on ne prennait 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 decryptage , même si vous utilisez une variable host c’est facile à voir.

La solution, c’est quand vous compiler votre programme le paramétre DBGENCKEY(‘Votre_clé’)

Vous devrez désormais indiquer votre clé pour debuguer

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 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 des packages SQL sont dus à l’utilisation du Extended Dynamic SQL, c’est des objets qui sont crées essentiellement pour des accès ODBC et dynamiques, c’est 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érieurs quand il en aura besoin, il est difficile de voir le contenu des ces objets , cependant vous pouvez faire un dump de cette objet, par la commande DMPOBJ comme si 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 changer version d’ibmi ou quand il occupe trop de place, attention cependant il en existe certain qui font partie de SQL comme

QSQLPKG2 de QSYS
QSQXDPKG de QSYS

En règle générale ne pas toucher à ceux qui commence par Q ni les objets qui sont dans QSYS

Ci dessous un lien pour en savoir plus ses 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érer 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 un idée de ce que vous devrez mettre en œuvre