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
Construire une infrastructure cloud optimisée pour l’IA avec Microsoft Azure
Les managers IT ont besoin d’une stratégie claire et de solutions concrètes pour préparer leur infrastructure cloud à l'adoption de l'IA, tout en optimisant les coûts, renforçant la sécurité et développant les compétences internes. Découvrez tous les conseils dans ce guide Insight.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Face à l’urgence écologique, l’IT doit faire sa révolution
- IoT et cybersécurité : les bases que chaque décideur doit maîtriser
- AWS re:Invent 2025 : décryptage des grandes innovations qui vont transformer le cloud
- Gouvernance et optimisation des dépenses logicielles : Comment éviter les pièges de la consommation?
Articles les + lus
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
Top 5 TechnoVision 2026 des tendances technologiques à suivre de près !
À la une de la chaîne Tech
- 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
- Top 5 TechnoVision 2026 des tendances technologiques à suivre de près !
