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 Threat Intelligence contextuelle
Ce guide facilitera l’adoption d’une Threat Intelligence - renseignement sur les cybermenaces, cyberintelligence - adaptée au "contexte", il fournit des indicateurs de performance clés (KPI) pour progresser d' une posture défensive vers une approche centrée sur l’anticipation stratégique
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Communication d’entreprise à l’ère de l’IA : fragmentation, Shadow AI et perte de contrôle
- Pourquoi les outils de sécurité ne suffisent plus face aux angles morts de la détection
- Rhea1 : SiPearl allume le CPU européen le plus ambitieux pour le HPC et l’IA souveraine
- L’analytique prédictive au service de la décarbonation en France
Articles les + lus
Microsoft Build 2026 : contre-offensive des modèles maison face à OpenAI et Anthropic
Rhea1 : SiPearl allume le CPU européen le plus ambitieux pour le HPC et l’IA souveraine
Analyse Patch Tuesday Mai 2026
Les coûts cachés des merge requests générées par l’IA
Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
À la une de la chaîne Tech
- Microsoft Build 2026 : contre-offensive des modèles maison face à OpenAI et Anthropic
- Rhea1 : SiPearl allume le CPU européen le plus ambitieux pour le HPC et l’IA souveraine
- Analyse Patch Tuesday Mai 2026
- Les coûts cachés des merge requests générées par l’IA
- Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
