Sécurité z/OS avec RACF : profils d'utilisateur, de groupe et de dataset, et pourquoi les agents requièrent le moindre privilège

Ce que c'est

La System Authorization Facility (SAF) est l'interface que les composants z/OS appellent pour demander « cet utilisateur est-il autorisé à effectuer cette action ? ». RACF (Resource Access Control Facility, composant de z/OS Security Server) est le produit de sécurité le plus couramment branché derrière cette interface pour répondre à la question, même s'il existe d'autres produits compatibles SAF. RACF organise les accès autour de profils : un profil utilisateur par identifiant, des profils de groupe pour des ensembles d'utilisateurs, et des profils de ressources — dont les profils de dataset — qui désignent ce qui est protégé et qui peut y accéder, à quel niveau (lecture, mise à jour, alter, etc.).

LISTUSER userid affiche les attributs d'un profil utilisateur et les groupes auxquels il est connecté ; LISTDSD liste les profils de dataset, y compris les profils génériques qui couvrent tout un modèle de nommage plutôt qu'un nom de dataset exact. Les accès sont accordés avec PERMIT une fois le profil créé (avec ADDSD pour les datasets, RDEFINE pour les ressources générales) : par exemple, PERMIT profile-name CLASS(CSFSERV) ID(groupID) ACCESS(READ) accorde l'accès en lecture sur une ressource définie à un identifiant de groupe, ce qui est généralement préférable à l'octroi de droits à des identifiants utilisateur pris un par un. Dans une classe conservée en mémoire (RACLISTée, comme l'est généralement CSFSERV), les modifications ne prennent effet qu'après SETROPTS RACLIST(class) REFRESH ; pour les profils génériques de dataset modifiés, un SETROPTS GENERIC(DATASET) REFRESH peut être nécessaire pour les traitements déjà en cours.

Les recommandations d'IBM sont explicites : les commandes de listage de RACF — LISTUSER, LISTDSD, LISTGROUP, RLIST — sont conçues pour être lancées par une personne et lues par une personne ; leur format de sortie n'est pas une interface de programmation prise en charge, n'est pas garanti stable d'une version à l'autre, et IBM ne prend pas en charge l'analyse de cette sortie par un programme. Les programmes doivent plutôt utiliser les interfaces documentées qu'IBM indique : le fichier de sortie de l'utilitaire de déchargement de la base de données IRRDBU00, RACROUTE REQUEST=EXTRACT ou ICHEINTY.

Pourquoi c'est important

Un agent d'automatisation est précisément le type d'acteur que l'administration RACF doit contraindre étroitement : il doit s'authentifier avec son propre identifiant dédié, aux droits strictement limités, n'ayant que l'accès requis par sa tâche, et non réutiliser un identifiant d'administrateur largement privilégié. Tout script qui analyse le texte produit par LISTUSER/LISTDSD s'appuie sur une interface qu'IBM indique ne pas être destinée aux programmes.

Comment l'appliquer

• Créer un identifiant RACF distinct par tâche automatisée ou par agent, connecté au minimum de groupes, autorisé au minimum d'accès aux ressources, et sans les attributs système SPECIAL, OPERATIONS ou AUDITOR.
• Accorder les accès via des profils de groupe et PERMIT plutôt qu'à des identifiants individuels, afin que la revue des accès se fasse au niveau du groupe.
• Privilégier une interface de reporting prise en charge plutôt que l'analyse de la sortie de LISTUSER/LISTDSD lorsqu'un programme a besoin de ces données.
• Passer périodiquement en revue les profils de dataset et de ressources générales pour repérer les niveaux d'ACCESS plus larges que ne l'exige la tâche (ALTER là où READ suffirait, par exemple).

Pièges

• Exécuter l'automatisation sous un identifiant TSO partagé ou très privilégié « pour éviter les problèmes de permissions », ce qui nuit à la traçabilité et viole le principe du moindre privilège.
• Considérer LISTUSER * ou des listages tout aussi non bornés comme un appel d'automatisation ordinaire ; IBM signale qu'une telle sortie peut épuiser la mémoire de l'espace d'adressage et renvoie à IRRDBU00.