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
Microsoft 365 Tenant Resilience
Face aux principales failles de résilience des tenants M365 (configurations, privilèges, sauvegarde). Découvrez une approche en 5 piliers pour durcir, segmenter et surveiller vos environnements afin de limiter l’impact des attaques. Comment prioriser vos chantiers cyber et améliorer durablement la résilience de vos tenants Microsoft 365 ?
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Pourquoi les navigateurs web sont devenus la porte d’entrée des cybercriminels pour compromettre les endpoints ?
- Panorama de la cybermenace 2025 : la France sous pression constante
- La visibilité des données, rempart ultime aux dérives du « Shadow AI »
- Analyse Patch Tuesday Mars 2026
Articles les + lus
Coder vite, mais coder juste : trouver l’équilibre à l’ère de l’IA
Mixité dans la Tech : en 2026, un choix de souveraineté stratégique
Analyse Patch Tuesday Mars 2026
Confiance et curiosité : les clés pour entrer (et grandir) en tant que femme dans la tech
Portails développeurs internes : accélérer l’innovation sans alourdir les budgets
À la une de la chaîne Tech
- Coder vite, mais coder juste : trouver l’équilibre à l’ère de l’IA
- Mixité dans la Tech : en 2026, un choix de souveraineté stratégique
- Analyse Patch Tuesday Mars 2026
- Confiance et curiosité : les clés pour entrer (et grandir) en tant que femme dans la tech
- Portails développeurs internes : accélérer l’innovation sans alourdir les budgets
