Comprenez comment IBM RACF protège les ressources z/OS et comment un émulateur TN3270E ouvre une session mainframe sécurisée par TLS, VTAM et RACF en pratique.
IBM RACF et TN3270 : sécuriser l’accès au mainframe
Sur z/OS, deux noms apparaissent rapidement dès qu’un développeur ou un exploitant ouvre une session mainframe : RACF et TN3270. Ils sont souvent associés parce qu’un utilisateur saisit son identifiant RACF dans un écran 3270. Pourtant, ils n’ont pas le même rôle.
RACF est le gestionnaire de sécurité fourni par IBM au sein de z/OS Security Server. Il identifie les utilisateurs, décide qui peut accéder à une ressource et journalise les tentatives importantes. Un émulateur TN3270 est un client terminal : il affiche des écrans 3270 et transporte les échanges avec z/OS au-dessus d’un réseau IP.
Autrement dit, TN3270 permet d’atteindre la porte ; RACF aide le système à décider si elle doit s’ouvrir et jusqu’où l’utilisateur peut aller.
Précision de vocabulaire. Le produit IBM s’écrit RACF, pour Resource Access Control Facility. « RCAF » est une inversion fréquente. Broadcom Top Secret, souvent appelé TSS, et ACF2 sont des gestionnaires de sécurité externes comparables ; RACF est la solution IBM intégrée à z/OS Security Server.
Ce que RACF protège réellement
RACF ne se limite pas à un écran de connexion. Il conserve des profils décrivant :
- les utilisateurs et leurs attributs ;
- les groupes et leurs membres ;
- les ressources protégées ;
- les autorisations accordées à un utilisateur ou à un groupe ;
- les règles d’audit associées aux accès.
Lorsqu’un composant z/OS veut autoriser une opération, le gestionnaire de la ressource demande une décision au mécanisme de sécurité. RACF recherche le profil correspondant, calcule l’autorité effective et renvoie une décision. L’application ou le sous-système accorde ou refuse ensuite l’opération.
Les ressources peuvent être des data sets, des volumes, des commandes, des applications, des transactions CICS, des terminaux ou d’autres objets représentés dans une classe RACF. Les droits ne sont donc pas seulement « connecté » ou « refusé » : ils portent sur une ressource et un niveau d’accès précis.
Les quatre niveaux d’accès courants
Pour de nombreux profils de ressources, RACF utilise une hiérarchie familière :
| Niveau | Sens général |
|---|---|
NONE | aucun accès autorisé |
READ | consulter la ressource |
UPDATE | lire et modifier une ressource existante |
CONTROL | contrôle supplémentaire, selon la classe de ressource |
ALTER | contrôle complet du profil ou de la ressource |
La signification exacte dépend du type de ressource. Accorder ALTER par confort à une équipe applicative est rarement justifié. Les groupes, les profils génériques bien délimités et le principe du moindre privilège rendent l’administration plus prévisible.
RACF, SAF et les applications z/OS
RACF est souvent présenté comme le moteur de sécurité, mais les applications z/OS s’intègrent généralement à travers SAF, le System Authorization Facility. SAF fournit l’interface commune utilisée pour demander une authentification ou une autorisation. RACF traite la décision lorsqu’il est le gestionnaire de sécurité actif.
Cette séparation explique pourquoi un produit peut fonctionner avec RACF, Top Secret ou ACF2 sans réécrire toute sa logique. SAF est l’interface ; l’External Security Manager détient les profils et applique les règles.
Avec CICS, par exemple, la sécurité peut contrôler la connexion, l’accès à une transaction et les ressources utilisées par celle-ci. Avec TSO, RACF intervient dans l’identification de l’utilisateur et la protection de ses ressources. Db2 peut également s’appuyer sur le gestionnaire de sécurité z/OS pour certaines autorisations.
Ce que fait un émulateur TN3270
Le terminal IBM 3270 historique utilisait un protocole orienté écran. Contrairement à un terminal caractère qui envoie simplement une suite de touches, un écran 3270 manipule des champs structurés : zones protégées, zones saisissables, attributs d’affichage et touches d’action comme Enter, PF1 à PF24, PA1 ou Clear.
Un émulateur reproduit ce comportement sur un poste moderne. TN3270 transporte le flux 3270 dans Telnet sur TCP/IP. TN3270E, sa variante étendue, ajoute notamment une négociation plus riche des fonctions et de la session.
L’émulateur gère donc :
- le modèle d’écran, souvent 24 × 80 ou 27 × 132 caractères ;
- le clavier et le mapping des touches de fonction ;
- la page de codes EBCDIC adaptée à l’environnement ;
- le nom de LU demandé, si l’installation l’autorise ;
- la connexion au serveur TN3270 ou TN3270E ;
- la validation TLS lorsque le canal est chiffré.
Il ne décide pas si l’utilisateur peut lancer une transaction CICS ou lire un data set de production. Cette autorisation reste côté z/OS.
Le parcours complet d’une connexion
Une session typique suit plusieurs étapes :
- l’émulateur ouvre une connexion TCP vers le port TN3270E ;
- TLS établit un canal chiffré et le client valide le certificat du serveur ;
- le serveur TN3270 négocie les capacités et affecte une Logical Unit, ou LU ;
- VTAM achemine la session vers une application telle que TSO, CICS ou un menu d’accueil ;
- l’utilisateur présente son identité à l’application ;
- RACF vérifie l’identité puis répond aux contrôles d’accès demandés ;
- les écrans 3270 sont échangés tant que la session reste active.
Le chiffrement et l’autorisation sont complémentaires. TLS protège les données entre l’émulateur et le serveur TN3270E. RACF protège les ressources après l’arrivée dans z/OS. Une connexion chiffrée n’accorde aucun droit métier, et un mot de passe RACF solide ne protège pas une session TN3270 transmise en clair.
Configurer TN3270E sans affaiblir la sécurité
Un profil de connexion devrait au minimum préciser :
- le nom DNS du serveur, sans contourner la validation du certificat ;
- un port TLS dédié défini par l’installation ;
- TN3270E lorsque l’infrastructure le supporte ;
- TLS 1.2 ou TLS 1.3 selon la politique z/OS ;
- la page de codes et le modèle d’écran fournis par l’équipe mainframe ;
- un nom de LU uniquement si une affectation spécifique est nécessaire.
Évitez les options « accepter tous les certificats » ou « ignorer le nom d’hôte ». Elles transforment le chiffrement en tunnel sans identité fiable du serveur. Le certificat doit remonter à une autorité approuvée par l’entreprise et son nom doit correspondre au service contacté.
La documentation IBM rappelle aussi une limite importante : TLS protège le trajet IP entre le client et le serveur TN3270E. Si la session SNA continue au-delà de ce serveur vers un autre système, cette portion doit être protégée séparément lorsque le modèle de menace l’exige.
Exemples de commandes RACF
Les commandes suivantes illustrent le modèle. Elles ne doivent pas être copiées en production sans respecter les conventions de nommage, les propriétaires et le processus d’approbation de l’installation.
Créer un groupe puis connecter un utilisateur :
ADDGROUP DEVAPP OWNER(SECADMIN)
ADDUSER YVAH NAME('YVA HAJATIANA') DFLTGRP(DEVAPP)
CONNECT YVAH GROUP(DEVAPP)
Protéger un data set applicatif et accorder la lecture au groupe :
ADDSD 'APP.PROD.DATA.**' GENERIC UACC(NONE) OWNER(APPSEC)
PERMIT 'APP.PROD.DATA.**' CLASS(DATASET) ID(DEVAPP) ACCESS(READ)
SETROPTS GENERIC(DATASET) REFRESH
L’élément important n’est pas la syntaxe seule. UACC(NONE) ferme l’accès universel, PERMIT accorde un droit ciblé et le rafraîchissement rend la modification active pour la classe concernée. Dans une grande installation, ces actions passent généralement par une séparation des rôles, une demande traçable et une revue périodique.
RACF n’est pas un annuaire moderne ordinaire
Il est tentant de comparer un identifiant RACF à un compte Active Directory ou Entra ID. La comparaison aide à comprendre l’identité, mais elle devient vite incomplète. RACF modélise directement de nombreuses ressources z/OS et participe aux décisions de sous-systèmes historiques et critiques.
RACF peut authentifier avec un mot de passe, une phrase secrète, un certificat, Kerberos ou un PassTicket selon la configuration. Une entreprise peut aussi fédérer des identités distribuées vers z/OS, mais l’autorisation finale sur les ressources mainframe reste gouvernée par les profils et politiques du système.
Comparer RACF et Top Secret sans les confondre
RACF et Broadcom Top Secret répondent à une même famille de besoins : identifier, autoriser, administrer et auditer sur z/OS. Ils diffèrent dans leur modèle d’administration, leur syntaxe, leurs conventions et leur histoire produit.
| Question | RACF | Top Secret / TSS |
|---|---|---|
| Éditeur | IBM | Broadcom |
| Positionnement | composant de z/OS Security Server | External Security Manager tiers |
| Intégration applicative | principalement via SAF | principalement via SAF |
| Modèle administratif | profils utilisateurs, groupes et ressources | ACID et ownership, selon la configuration TSS |
| Commandes | syntaxe RACF | syntaxe TSS distincte |
Dire que RACF est « l’équivalent IBM de TSS » est utile pour s’orienter, à condition de ne pas supposer une correspondance commande par commande. Une migration exige une cartographie des identités, des ressources, des droits implicites, de l’audit et des interfaces applicatives.
Diagnostiquer les erreurs fréquentes
Échec avant l’écran de connexion
Si l’émulateur ne se connecte pas, cherchez d’abord le réseau, le port, TLS, le certificat, la négociation TN3270E ou l’affectation de LU. RACF n’est probablement pas encore intervenu.
Identifiant ou mot de passe refusé
Le compte peut être révoqué, le secret expiré, le nombre maximal de tentatives atteint ou la méthode d’authentification incompatible. Le message de l’application et les journaux de sécurité permettent de distinguer ces cas.
Connexion réussie, ressource refusée
Une erreur telle que ICH408I indique souvent un contrôle RACF négatif. Relevez le nom de la ressource, la classe, le niveau demandé et le contexte utilisateur. N’accordez pas SPECIAL ou ALTER pour faire disparaître rapidement l’erreur : corrigez le profil ou le groupe au niveau minimal nécessaire.
Écran illisible ou touches incorrectes
Le problème vient généralement du modèle 3270, de la page de codes ou du mapping clavier. Modifier les droits RACF ne changera rien à un caractère accentué mal décodé ou à une touche PF qui n’envoie pas le bon code.
Une architecture de moindre privilège
Une configuration saine combine plusieurs contrôles :
- accès réseau limité au service TN3270E ;
- TLS récent avec validation complète du certificat ;
- authentification forte lorsque l’écosystème le permet ;
- profils RACF génériques mais suffisamment étroits ;
- droits accordés aux groupes plutôt qu’à une succession d’utilisateurs ;
- séparation entre administration, exploitation, développement et audit ;
- journalisation des succès sensibles et des échecs ;
- revue périodique des comptes, groupes et permissions.
L’émulateur doit aussi être administré comme un outil sensible : mises à jour, configuration centralisée, verrouillage du presse-papiers si nécessaire, protection des traces locales et interdiction de stocker les mots de passe dans un profil de connexion.
Ce qu’il faut retenir
RACF et TN3270 travaillent ensemble sans être interchangeables. TN3270E donne à un poste moderne le comportement d’un terminal 3270 et transporte la session vers z/OS. TLS protège le trajet réseau. VTAM relie la session à l’application. RACF authentifie l’utilisateur et répond aux demandes d’autorisation sur les ressources protégées.
Cette séparation rend le diagnostic plus simple : un problème de certificat ou de LU se traite dans la chaîne de connexion ; un refus sur un data set ou une transaction se traite dans le modèle d’autorisation. La sécurité du mainframe repose précisément sur l’assemblage cohérent de ces couches, pas sur un seul écran de mot de passe.
