, La valeur de sécurité QSECURITY

La valeur de sécurité QSECURITY

ㅤ

La valeur QSECURITY permet de connaître le niveau de sécurité appliqué au système.

Il y a 5 niveaux de sécurité, 10 – 20 – 30 – 40 – 50.

10 étant la sécurité la plus faible et 50 la plus élevé.

Pour connaître la valeur du niveau de sécurité de votre système, vous devez vous rendre dans les valeurs système en utilisant la commande WRKSYSVAL.

Au vu du nombre de valeurs de notre système, on va trier par sous-ensemble.

On va rentrer *SEC pour aller voir les valeurs système de sécurité.

On affiche ensuite la valeur système QSECURITY.

Sur la ligne rouge on peut voir le niveau de sécurité de notre système.

Dans le carré bleu, on peut voir les 5 niveaux de sécurité avec une courte description.

Depuis la version V7R5, le niveau de sécurité minimal est de 30.

Tableau des valeurs de QSECURITY depuis la V7R5

IBM recommande le niveau de sécurité 40 en raison des vulnérabilités trouvées au niveau 30.

La plupart des entreprises possédant un IBM i travaillent avec un niveau de sécurité 40.

Seuls les services financiers et quelques autres entreprises utilisent le niveau de sécurité 50 pour se conformer aux normes de défense américaine.

Voyons maintenant en détails, les 5 niveaux de sécurité :

ㅤ

Niveau 10 → Pas de mot de passe requis, des profils sont créés à chaque fois qu’un utilisateur essaie de se connecter. Les utilisateurs créés ont accès à tout car l’autorité *ALLOBJ leur est attribuée automatiquement. Ce niveau n’est plus entretenu par IBM.

Niveau 20 → À ce niveau l’autorité *ALLOBJ est toujours attribuée à chaque utilisateur. En plus du niveau 10, un identifiant et un mot de passe sont nécessaires pour se connecter. Seul un profil *SECADM peut créer des nouveaux profils utilisateur. Ce niveau n’est plus admis depuis la V7R5.

Niveau 30 → En plus du niveau 20, ce niveau peut gérer les autorisations des utilisateurs au cas par cas. Les profils ayant l’autorité *ALLOBJ sont forcément créés avec la classe de sécurité *SECOFR, les autres n’ont pas cette autorité.

Niveau 40 → Protection de l’intégrité du système d’exploitation. Signature et sécurité des ressources. Le système empêche les tentatives d’appeler directement des programmes système non reconnus.

Niveau 50 → Protection renforcée de l’intégrité du système d’exploitation. Signature et sécurité des ressources. Avant de passer à ce niveau, la mise en place du journal d’audit est obligatoire. Ce niveau a été créé pour répondre à la norme C2 (Norme de département de défense Américain). Une meilleure protection des blocs de contrôle interne est appliquée.

/par
, , Droits et génération SQL script

Vous devez moderniser votre base de données, pour cela vous pouvez commencer par extraire le source de votre PF,
par exemple en passant par Générations d’instructions SQL dans ACS , ou en utilisant la procédure SQL de QSYS2 GENERATE_SQL Ou GENERATE_SQL_OBJECT ,


La plus part du temps on obtient un scripte SQL qui vous permettra de générer votre nouvelle table , ici un exemple ou on a enlevé les commentaires.

Que ce passe t’il au niveau des droits ?

Avant par DSPOBJAUT

par DROITS dans ACS

La liste d’autorisations

Premier effet vous pouvez avoir des différences sur les droits publics

exemple ici

Après

Vous vous retrouvez avec un droit USER DEF au lieu de *CHANGE et vous avez perdu le droit exécute, on est d’accord ca ne change rien sur une table, c’est juste un peu moins lisible quand on analyse au niveau du système

le plus gênant c’est la liste d’autorisation que vous perdez
et la cela peux changer complètement puisque vous perdez 1 voir 2 niveaux de recherches

Dans notre cas FORM06 se retrouve avec des droits *PUBLIC

Conclusion :


Après avoir modernisé vos tables, vous devez réappliquer vos droits le plus simple est de généré un objet de référence

une autre solution est de vous affranchir des listes d’autorisation qui ne sont pas générées dans SQL

/par
, , , Tuez les jobs SSH dans QINTER

Si vous commencez à faire du SSH (en tant que client), par exemple pour faire du GitHub, vous avez des jobs qui vont rester et que vous devrez tuer par un kill ou un ENDJOB.

C’est des jobs BCI qui restent après avoir arrêté vos JOBs interactifs.

Voici un petit script CLP qui permet de faire ça, il vous suffit de le planifier tous les soirs à 23 heures par exemples.

Ici on a utiliser la fonction table QSYS2.ACTIVE_JOB_INFO et la fonction QSYS2.QCMDEXC et on packagé le tout dans un CLP …

PGM
/* Suppression des jobs SSH dans QINTER */
dcl &NBRCURRCD *dec 10
/*  Exécution de la requete SQL */
             RUNSQL     SQL('Create table qtemp/sortie as(SELECT +
                          QSYS2.QCMDEXC(''ENDJOB '' CONCAT +
                          JOB_NAME)  as resultat FROM +
                          TABLE(QSYS2.ACTIVE_JOB_INFO(SUBSYSTEM_LIST_+
                          FILTER => ''QINTER'')) X  where job_type +
                          = ''BCI'') with data') COMMIT(*NONE)
             MONMSG     MSGID(SQL0000) exec(do)
             SNDUSRMSG  MSG('Erreur dans l''exécution de la requête +
                          SQL d''épuration des jobs SSH') +
                          MSGTYPE(*INFO)
             Return
             enddo
  /* Envoi d'un message de fin */
             RTVMBRD    FILE(QTEMP/SORTIE) NBRCURRCD(&NBRCURRCD)
             if cond(&NBRCURRCD > 0) then(do)
             SNDUSRMSG  MSG(%CHAR(&NBRCURRCD) *TCAT ', job(s) SSH +
                          arrêté(s)') MSGTYPE(*INFO)
             enddo
             else do
             SNDUSRMSG  MSG('Pas de Job SSH à Supprimer ') +
                          MSGTYPE(*INFO)
             enddo
ENDPGM

Sur les job de ssh-agent vous pouvez demander le kill directement comme ceci, merci à Julien …

La commande QSH lancer par votre CL qui vous permet de soumettre se présente donc comme ça : 

eval "$(ssh-agent -s)" ; // Démarrage de l'agent 
SSH ssh-add /home/jl/.ssh/github ; // Ajout de la clé à l'agent 
ssh -T git@github.com ; // Test de connexion à GitHub 
ssh-agent -k // Arrêter l'agent
/par
, , Droits SQL sur les Zones

On m’a récemment demandé comment savoir si un fichier était couvert par des droits SQL sur les zones

J’ai d’abord pensé que la fonction table QSYS2.OBJECT_PRIVILEGES allait me rendre ce service !

donc j’ai lancé cette requête pour analyser mon fichier

Exemple :

SELECT *
FROM TABLE(QSYS2.OBJECT_PRIVILEGES(‘MABASESQL’, ‘CLIENTS’, ‘*FILE’));

et je n’ai pas trouvé l’information dans les zones renvoyées

puis j’ai essayé avec les commandes historiques en sortie de fichier ici DSPOBJAUT

Exemple :

DSPOBJAUT OBJ(MABASESQL/CLIENTS)
OBJTYPE(FILE) OUTPUT(OUTFILE)
OUTFILE(MABASESQL/LSTAUT)

Select * from MABASESQL.lstaut

et la on a le résultat qui l’indique
ZONE OAOBJA à ‘USER DEF’ et une ZONE des DATA ici OAUPD à ‘/’

En résumé

On ne sait pas par SQL, mais on sait faire par une sortie fichier historique


Oui je sais , on peut trouver l’information par des vues spécifiques dans QSYS2 et SYSIBM

Vous avez d’abord la vue SYSIBM.SQLCOLPRIVILEGES mais attention, vous avez toutes les autorisations sur la zone y compris celles qui correspondent à un *CHANGE sur le fichier par exemple.


exemple :
Select * from SYSIBM.SQLCOLPRIVILEGES
where TABLE_SCHEM = ‘MABASESQL’ and TABLE_NAME = ‘CLIENTS’

order by column_name, grantee


Ou mieux la vue QSYS2.COLUMN_PRIVILEGES qui ne contient que les zones avec des autorisations spécifiques

exemple

Select * from QSYS2.COLUMN_PRIVILEGES
where TABLE_SCHEMA = ‘MABASESQL’ and TABLE_NAME = ‘CLIENTS’

j’ai donc fait une RFE pour avoir l’information dans la fonction table QSYS2.OBJECT_PRIVILEGES

Si vous êtes intéressés votez pour moi c’est ici https://2e4ccba981d63ef83a875dad7396c9a0.ideas.aha.io/ideas/RIRP-I-1260

Je vous indiquerais la réponse d’IBM sur le sujet

/par
, Les extensions ACS

Une petite explication sur les fichiers ACS et leur extension, et les migrations possibles à partir des fichiers de Client Access

Pour les fichiers de définition de session

Les fichiers, KMP, PMP, BAR, MAC ont la même extension, mais ne sont pas compatibles, vous devrez les migrer par l’outil de migration .

Gestionnaire de sessions / fichier / importer

Pour les transferts de fichiers

Vous pouvez ouvrir un fichier DTF par ACS et l’enregistrer en DTFX, la migration est automatique

On n’a pas d’outil pour migrer les descriptions de fichier FDX, vous devrez les recréer ou modifier le source, il y a peu de différences

Résumé

On sait migrer les sessions, les claviers, les transferts les macros **

Pour les fichiers macros, vous ne pourrez migrer que ce qui a été enregistré et non codé

Mais ca peut être l’occasion de faire le ménage de reprendre propre.

**

/par
, , Utilisation du catalogue DB2

Il existe de nombreuses tables dans QSYS qui constituent le catalogue DB2,
Ces tables sont accessibles par des vues qui se trouvent dans QSYS2 de manière globale et dans les bibliothèques de vos collections SQL.

On utilise pas assez ces informations pour analyser la base de données, elles contiennent une multitude d’informations

On va faire une petit exemple:

Imaginons que nous voulons savoir ou est utilisée une zone


Nous fixerons la database par set schema , pour éviter les qualifications

exemple de manière globale
SET SCHEMA QSYS2

On va utiliser une vue qui s’appelle SYSCOLUMNS qui contient les zones de votre database

SELECT
A.SYSTEM_COLUMN_NAME,
A.SYSTEM_TABLE_NAME,
A.SYSTEM_TABLE_SCHEMA
FROM SYSCOLUMNS A
WHERE COLUMN_NAME = ‘NUMCLI’

Vous obtenez une liste de tous les fichiers (tables, vue, PF, LF) etc …

Imaginons ensuite que vous ne vouliez que les tables ou PF vous pouvez utiliser la vue SYSTABLES

SELECT a.SYSTEM_COLUMN_NAME,
A.SYSTEM_TABLE_NAME,
A.SYSTEM_TABLE_SCHEMA
FROM SYSCOLUMNS a join SYSTABLES b on A.SYSTEM_TABLE_NAME=b.SYSTEM_TABLE_NAME
and a.SYSTEM_TABLE_SCHEMA = b.SYSTEM_TABLE_SCHEMA and B.TABLE_TYPE in(‘T’ , ‘P’)
WHERE COLUMN_NAME = ‘NUMCLI’

Vous limitez ainsi votre recherche aux tables et PF

Imaginons maintenant que vous ne vouliez que les tables et PF qui ont été utilisées sur l’année flottante (13 mois), on va utiliser la vue SYSTABLESTAT

SELECT a.SYSTEM_COLUMN_NAME,
A.SYSTEM_TABLE_NAME,
A.SYSTEM_TABLE_SCHEMA
FROM SYSCOLUMNS a join SYSTABLES b on A.SYSTEM_TABLE_NAME=b.SYSTEM_TABLE_NAME
and a.SYSTEM_TABLE_SCHEMA = b.SYSTEM_TABLE_SCHEMA and B.TABLE_TYPE in( ‘T’ , ‘P’)
join SYSTABLESTAT c on A.SYSTEM_TABLE_NAME=c.SYSTEM_TABLE_NAME
and a.SYSTEM_TABLE_SCHEMA = c.SYSTEM_TABLE_SCHEMA and c.LAST_USED_TIMESTAMP >
(current date – 13 months)
WHERE COLUMN_NAME = ‘NUMCLI’

Cette exemple n’est pas parfait, mais il vous montre qu’avec le catalogue db2 et un peu de SQL vous pouvez avoir de nombreuses informations pertinentes sur cette dernière .
Vous pouvez par exemple avoir des informations statistiques sur vos colonnes par la vue SYSCOLUMNSTAT et une vue globale avec la vue SYSFILES qui permet d’avoir un bon résumé de vos fichiers

https://www.ibm.com/support/pages/node/6486897


Voici un lien qui vous présente les vues disponibles,

https://www.ibm.com/docs/en/i/7.5?topic=views-i-catalog-tables

/par
, 2 requêtes pour gérer vos récepteurs de journaux

Pour faire un peu de place il peut être important de supprimer certains récepteurs de journaux inutiles

D’abord la liste des récepteurs détachés de plus de 30 jours

SELECT JOURNAL_RECEIVER_LIBRARY, JOURNAL_RECEIVER_NAME FROM
QSYS2.JOURNAL_RECEIVER_INFO WHERE ATTACH_TIMESTAMP < current date –
30 days and DETACH_TIMESTAMP is not null

A partir de cette liste vous pouvez faire une DLTJRNRCV de ces recepteurs

Liste des journaux qui n’éffacent pas les récepteurs après détachement
SELECT JOURNAL_NAME, JOURNAL_LIBRARY FROM qsys2/JOURNAL_INFO WHERE
DELETE_RECEIVER_OPTION = ‘NO’

A partir de cette liste vous pouvez modifier le récepteur en indiquant de supprimer les recepteurs après détachement !

CHGJRN DLTRCV(*YES)

Attention :

Il ne faut pas supprimer des récepteurs de votre base de données de production
mais il y a souvent une multitude de bases de tests qui n’ont pas besoin de leurs récepteurs détachés pour permettre de faire des tests

/par
, Outil pour gérer les outqs

Un nouvel outil dans GTOOLS

Nous avons développé une petite commande pour un client, elle facilite la gestion des remotes Outqs
par exemple pour changer une adresse IP
La commande est WRKOUTQIP

Vous pouvez
Arrêter le travail d’édition
Supprimer une outq
Changer une outq


Les sources sont ici
https://github.com/Plberthoin/PLB/tree/master/GTOOLS

Il y a une commande, un programme et un écran

Cet outil est un peu brut, vous pouvez l’améliorer, par exemple, un 3 dupliquer pourrait intéresser tout le monde

/par
, Amélioration du scheduler IBMi en V7R5

En une seule commande vous pouvez holder tous les travaux en suspendant le scheduler lui même, vous voyez le status dans la commande wrkjobscde, bien utile pour les installations , les machines de backups etc..

.

HLDJOBSCDE JOB(JOBSCD) ENTRYNBR(ALL)

pour libérer

HLDJOBSCDE JOB(JOBSCD) ENTRYNBR(ALL)

Vous pouvez désormais soumettre une tâche annuellement

ADDJOBSCDE
…
FRQ(*YEARLY)
…

exemple épuration de fin d’années

/par
, Texte dynamique dans vos commandes

Vous pouvez demander à générer le texte des commandes que vous allez créer à l’utilisation non à la compilation !

Vous devez créer un fichier de message avec vos messages

Vous pouvez ensuite coder votre commande ici LSTFIC

CMD PROMPT(TXT0001) PMTFILE(CMDTXT DYNAMIC)

PARM KWD(BIBLIO) TYPE(NAME) LEN(10) PROMPT(TXT0002)

le fichier message peut être indiqué de 2 manières dans la commande CMD paramètre PMTFILE()
ou
à la compile dans la commande de génération CRTCMD
CRTCMD … PMTFILE()

c’est le paramètre dynamic qui permet cette possiblité

Utilisation

==>LSTFIC <F4>

Exemple pour gérer votre traduction
vous créer
Un fichier message en anglais dans une bibliothèque


vous mettez votre bibliothèque avant l’autre dans la liste des bibliothèques et voila

Utilisation

==>LSTFIC <F4>

Remarque :


Je n’ai pas mis ici le programme de traitement, il reçoit un paramètre char de 10
Ca ne concerne pas les messages d’erreur c’est le paramètre MSGF()
Attention s’il ne trouve pas votre message il ne plante pas vous aurez l’ID du message affiché, exemple TXT0001

/par