Auditer et suivre l’usage de STRSQL

La commande STRSQL (Start SQL Interactive Session) peut apporter de bonnes et de mauvaises nouvelles. Son bon côté est de fournir une interface qui permet d’exécuter rapidement des instructions SQL. On l’utilise souvent pour consulter le contenu de la base de données et pour éliminer d’éventuelles erreurs de données injectées par un bogue de programme ou par une erreur d’utilisateur. Côté négatif ? STRSQL peut être porteuse de mauvaises nouvelles quand un auditeur inspecte votre système et désire voir la liste des modifications de la base de données effectuées à partir de l’interface STRSQL et quels sont leurs auteurs. Pour la plupart des départements IT, l’activité de STRSQL participe normalement et simplement à l’exploitation : le problème est de suivre son usage.

Auditer et suivre l’usage de STRSQL

Avant la version IBM i 6.1, il n’y avait pas de bonnes solutions. La seule solution consistait à démarrer un moniteur de base de données pour tous les jobs actifs sur le système. Ce genre de moniteur capture toutes les requêtes SQL exécutées à partir de STRSQL, y compris les données pour chaque instruction SQL active. Cette situation n’est pas acceptable en cas de forte activité SQL, parce que le moniteur de base de données DB2 sollicitera trop le disque : activité et stockage.

DB2 for i 6.1 offre une solution adaptée à ce problème, à grand renfort de registres spéciaux client et de filtres de moniteur de base de données. Les registres spéciaux ne sont pas une nouveauté en SQL. D’ailleurs peut-être en utilisez-vous déjà quelques-uns comme CURRENT DATE ou USER. IBM a introduit les registres spéciaux client pour permettre aux applications de fournir des tags (ou attributs) pour décrire l’environnement client ou applicatif qui utilise des instructions SQL. En outre, des outils IBM comme le moniteur de base de données collectent les valeurs de registres client en même temps que le texte d’instruction SQL : il est donc très facile de savoir quelle interface ou application a soumis une instruction SQL. Voici les registres spéciaux client existants en 6.1 :

•    CLIENT ACCTNG
•    CLIENT APPLNAME
•    CLIENT PROGRAMID
•    CLIENT USERID
•    CLIENT WRKSTNNAME

Au lancement de la version IBM i 6.1, le système d’exploitation IBM i attribuait des valeurs par défaut aux registres client pour les interfaces client de base de données « à distance » comme le driver Toolbox JDBC et System i Navigator. Avec les récents PTF sur l’IBM i 6.1, les interfaces côté serveur DB2 telles que STRSQL et Run SQL Statement (RUNSQLSTM) définissent aussi désormais les valeurs de registres client. La valeur de ces registres spéciaux peut être extraite à tout moment par une simple instruction SQL comme la suivante, à partir de n’importe quelle interface SQL :

VALUES(CLIENT PROGRAMID)

Si cette instruction SQL émanait de l’interface STRSQL, la valeur renvoyée serait la chaîne ‘STRSQL’. On voit donc comment le support du registre client DB2 for i 6.1 permet de marquer (flag) facilement les instructions SQL exécutées avec la commande STRSQL.

On l’a vu, les valeurs de registres client sont également collectées par le moniteur de base de données. Ce genre de collecte est l’autre composante de la solution IBM i 6.1 pour suivre l’usage de STRSQL. Les valeurs de registres client sont attribuées aux colonnes suivantes dans une table de sortie du moniteur de base de données :

•    CLIENT ACCTNG – Column QVC3005 within the 1000 record (QQRID=1000)
•    CLIENT APPLNAME – Column QVC3001 within the 1000 record
•    CLIENT PROGRAMID – Column QVC3006 within the 1000 record
•    CLIENT USERID – Column QVC3002 within the 1000 record
•    CLIENT WRKSTNNAME – Column QVC3003 within the 1000 record

Voici un exemple qui explique comment le moniteur de base de données suit la valeur des registres client. La commande STRDBMON (Start Database Monitor) suivante est utilisée pour initier le moniteur de tous les jobs du système.

STRDBMON OUTFILE(KMILL/SQLTEST) JOB(*ALL/*ALL/*ALL)

Le moniteur de base de données est arrêté (ENDDBMON JOB(*ALL) ) après une durée de collecte de 10 minutes. Le moment est venu de déterminer si quelqu’un était en train d’utiliser l’interface STRSQL pendant la collecte du moniteur. Cela peut se faire en appliquant la requête de la figure 1 à la table de sortie du moniteur de base de données, à partir de n’importe quelle interface SQL.
À noter que cette requête ne demande que les enregistrements de moniteur collectés à partir de l’interface STRSQL en spécifiant une chaîne de recherche de ‘STRSQL’ pour le qvc3006. Le critère de recherche de qqrid=1000 n’extrait que les enregistrements contenant le texte des instructions SQL collectées.

La sortie de cette requête d’analyse du moniteur se trouve dans la figure 2. Les colonnes QVC102 et QQ1000 contiennent le profil utilisateur et l’instruction SQL soumis à partir de l’interface STRSQL pendant la période de collecte du moniteur de base de données.

Peut-être pensez-vous que la collecte par le moniteur des valeurs de registres spéciaux client ne résout pas le problème de suivi de STRSQL parce que l’exemple précédent nécessite encore un moniteur de base de données collectant des données pour tous les jobs du système. Vous avez raison de penser ainsi puisque l’élément final de la solution complète n’a pas encore été évoqué, à savoir les filtres de moniteur de base de données