Faites un essai de conduite de la sécurité de l’OS/400

Vous le savez probablement, la sécurité est
inhérente à  l’OS/400, c’est-à -dire qu’elle y
est intégrée. Nul besoin d’acquérir un logiciel
tierce partie pour posséder un système
sécurisé. La sécurité fait partie intégrante
de tout le système d’exploitation. Des
contrôles d’autorisation sont effectués aux niveaux les plus bas du système, rendant
la sécurité OS/400 omniprésente
et très difficile – voire impossible – à 
contourner.
L’OS/400 est muni de toutes les
fonctions de sécurité qu’exige un système
informatique de gestion :

Identification. Pour chaque utilisateur,
l’OS/400 permet de créer un profil
individuel sous lequel tous les jobs
et les opérations de suivi sont effectués.
Authentification. L’OS/400 oblige
les utilisateurs à  prouver l’identité
qu’ils annoncent. Le mécanisme d’authentification
OS/400 le plus répandu
et le mieux connu est l’ID et mot de
passe utilisateur.
Autorisation. La sécurité au niveau
objet permet de contrôler (avec beaucoup
de granularité) qui peut accéder
à  quoi.

Audit. Il joue un rôle important
dans la sécurité, pourtant peu d’utilisateurs
s’en servent. On peut auditer les
actions relevant de la sécurité pour
tout le système ou au niveau de chaque
utilisateur, y compris quand et comment
on a accédé à  un objet.
En V5R2, le journal d’audit contient
encore plus d’informations, y
compris le pool de stockage auxiliaire
de l’objet audité et l’adresse TCP/IP de
l’utilisateur qui adresse une requête.
Les entrées d’audit appartenant à  des
objets utilisant un nom de chemin sont
également plus faciles à  déchiffrer. Par
le passé, on n’obtenait que l’identification
fichier (FID, file ID) de l’objet,
puis il fallait appliquer le FID par l’intermédiaire
d’une API pour obtenir le
nom de chemin de l’objet. Désormais,
les 5 002 premiers caractères du nom
de chemin se trouvent à  la fin de l’entrée
du journal d’audit.

Intégrité. L’OS/400 est conçu (et
possède les mécanismes) pour s’assurer
qu’aucun programme valide ne
peut contourner l’intégrité système.
Autrement dit, si l’on exclut quelqu’un
d’un fichier, on est sûr que l’accès lui
sera refusé, quelle que soit la méthode
qu’il utilise pour ledit accès.