par Carol Woodbury, Mis en ligne le 19/04/2006 - Publié en Novembre 2005
A maintes occasions, j’ai souligné la nécessité de sécuriser l’IFS (integrated file system), sans entrer dans le détail des modalités. Cet article décrit ma méthode pour aider nos clients dans cette sécurisation. Tout d’abord, précisons la partie du système qui fait l’objet de cet article. L’IFS est composé d’un ensemble de systèmes de fichiers existants sur l’OS/400. On y trouve le système de fichiers QSYS.LIB (qui est le système de fichiers OS/400 « traditionnel »), QDLS, QNTC et d’autres. Cependant, les systèmes de fichiers que je désigne par le terme « IFS » sont ceux qui suivent un schéma de sécurité basé sur Unix. Ils incluent les systèmes de fichiers root (/), QopenSys, et définis par l’utilisateur (UDF, user-defined file system). Cet article traite précisément du répertoire racine et des répertoires en-dessous.
Comment sécuriser l’IFS
Avant d’entamer le processus, il convient de rappeler les autorités que la racine utilise. Rappelons que ce sont les concepts de sécurité Unix qui prévalent.
*R (Read) – nécessaire pour lire le contenu d’un objet, y compris la liste du contenu d’un répertoire
*W (Write) – nécessaire pour ajouter un objet à un répertoire ou pour mettre à jour un objet
*X (Execute) – nécessaire pour traverser un répertoire (c’est-à-dire pour afficher un fichier stream présent dans le chemin de répertoire suivant, il faudrait appliquer *X à tous les répertoires et sous-répertoires qui se trouvent sur le chemin : /Directory /Subdirectory_1/ /Subdirectory_2/ /Subdirectory_3/ File_name.stmf)
*RX – équivalent de l’autorité *USE en termes OS/400. *RWX est l’équivalent de l’autorité *CHANGE
Les autorités donnée sur les objets IFS sont de type Unix, alors que les autorités objet ne le sont pas. Par conséquent, la plupart des utilisateurs qui ont l’habitude de manipuler des répertoires oublient (ou ne savent pas) qu’il faut gérer deux ensembles d’autorités sur un objet IFS : DTAAUT (Data Authorities) et OBJAUT (Object Authorities). Les autorités objet vous sont probablement familières : *OBJMGT est nécessaire pour octroyer à autrui une autorité sur l’objet et *OBJEXIST est nécessaire pour supprimer l’objet. *OBJALTER et *OBJREF ne signifient rien pour un objet IFS mais elles sont quand même présentes. La figure 1 montre un exemple d’utilisation de la commande CHGAUT (Change Authority) pour spécifier de nouvelles valeurs pour les paramètres d’autorité donnée et objet.
Téléchargez cette ressource
Guide de Cyber-résilience pour Microsoft 365
La violation de votre tenant M365 va au-delà d’un simple incident de cybersécurité. Elle peut entraîner une interruption opérationnelle généralisée, des perturbations commerciales et une exposition de vos données sensibles. Découvrez les méthodes et technologies pour évaluer, comparer et renforcer votre posture de sécurité Microsoft 365.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Gouvernance, cybersécurité et agents IA : trois défis clés à relever pour réussir la transition en 2026
- Top 5 des évolutions technologiques impactant la sécurité 2026
- Tendances 2026 : l’IA devra prouver sa rentabilité
- L’identité numérique : clé de voûte de la résilience et de la performance en 2026
Articles les + lus
CES 2026 : l’IA physique et la robotique redéfinissent le futur
Les 3 prédictions 2026 pour Java
Semi-conducteurs : comment l’Irlande veut contribuer à atténuer la pénurie mondiale de puces
Face à l’urgence écologique, l’IT doit faire sa révolution
D’ici 2030, jusqu’à 90 % du code pourrait être écrit par l’IA, pour les jeunes développeurs, l’aventure ne fait que commencer
À la une de la chaîne Tech
- CES 2026 : l’IA physique et la robotique redéfinissent le futur
- Les 3 prédictions 2026 pour Java
- Semi-conducteurs : comment l’Irlande veut contribuer à atténuer la pénurie mondiale de puces
- Face à l’urgence écologique, l’IT doit faire sa révolution
- D’ici 2030, jusqu’à 90 % du code pourrait être écrit par l’IA, pour les jeunes développeurs, l’aventure ne fait que commencer
