Apuntes de RACF

Juan Mautalen

PREFACIO Este texto intenta ser una gua bsica de RACF (Resource Access Control Facility), dirigida principalmente a aquellas personas que quieran iniciarse como administradores del producto. De todos modos, la informacin que contiene, aunque sea parcialmente, puede resultar de gran utilidad tanto para los system programmers como para los system operators (o cualquier otro usuario con inquietudes en el plano de la seguridad en plataforma mainframe). Los requisitos previos para abordar su lectura son realmente mnimos. Una cierta familiaridad con el entorno z/OS, sumada a un manejo bsico de TSO, ISPF y JCL, son suficientes para comprender sin problemas los temas expuestos. La informacin que se brinda est basada en la versin de RACF provista por la versin 1.11 del z/OS. Sin embargo, salvo contadas excepciones, tambin es vlida para versiones anteriores de RACF, o incluso posteriores. Al tratarse de un manual introductorio, he omitido intencionalmente el tratamiento de varios temas que, si bien importantes, considero que estn mas all del contenido que debe abarcar un texto bsico (RRSFRacf Remote Sharing Facility- o Certificados Digitales, por ejemplo). Otros temas tampoco son tratados, pero por considerar, en estos casos, que se trata de facilidades raramente utilizadas (security labels, por ejemplo). Con respecto a los comandos de RACF, solo he descripto los operandos de uso ms frecuente. La sintaxis completa puede consultarse en lnea desde una sesin de TSO mediante el comando HELP, o bien en el manual de IBM RACF - Command Languaje Reference. En cualquier caso, toda informacin sobre RACF que el lector no encuentre en la presente gua, o que pretenda ampliar, puede hallarla en la documentacin oficial del producto. En lo relativo al alcance, tampoco he incursionado en el anlisis de la proteccin dada por RACF a ciertos productos de base, como ser: DB2, CICS o IMS. Para ello, debe no solo debe recabarse informacin en la bibliografa especfica de RACF sino principalmente en la documentacin propia de cada producto. En la siguiente direccin web se pueden consultar y descargar gratuitamente todos los manuales oficiales de IBM vinculados al entorno z/OS: http://www-03.ibm.com/systems/z/os/zos/bkserv/r11pdf/#secserv Lo ideal sera leer la presente gua junto a una terminal con acceso a TSO, disponiendo de un usuario con atributo SPECIAL, para poder probar en la prctica los comandos y opciones que se van describiendo. Naturalmente, las opciones crticas deben siempre experimentarse en un entorno no productivo, a menos que se pretenda adquirir una rpida popularidad -y no de la mejor manera- dentro de la organizacin. En ciertas ocasiones notarn que se hace referencia, en determinado captulo, a algn tema que recin se trata en detalle en uno posterior. Esto me result inevitable, ms all de mis esfuerzos por organizar el material lo ms posible. A lo largo de esta gua he optado, en muchos casos, por dar recomendaciones respecto a la configuracin y polticas de seguridad que estimo ms convenientes. Estas deben entenderse como mi opinin personal, producto de mi propia experiencia. En ningn caso se trata de sugerencias de IBM, salvo que ello se indique explcitamente. En cualquier caso, toda organizacin debe determinar sus necesidades particulares de seguridad y decidir qu opciones le resultan las ms apropiadas para satisfacerlas. Juan Guillermo Mautalen Buenos Aires, julio 2011

Apuntes de RACF

Juan Mautalen

3 TABLA DE CONTENIDOS 1 - INTRODUCCIN ..........................................................................................................................6 1.1 - Consideraciones generales .........................................................................................................6 1.2 - Identificacin y autenticacin de usuarios ..................................................................................6 1.3 - Control de acceso a recursos ......................................................................................................6 1.4 - Herramientas de auditora ..........................................................................................................6 1.5 - Seguridad externa para aplicaciones ...........................................................................................7 2 - LA BASE DE RACF .......................................................................................................................8 2.1 - Consideraciones generales .........................................................................................................8 2.2 - Caractersticas............................................................................................................................8 2.3 - Estructura...................................................................................................................................9 2.4 - Actualizacin de la base .............................................................................................................9 3 - USUARIOS Y GRUPOS .............................................................................................................. 12 3.1 - Consideraciones generales ....................................................................................................... 12 3.2 - Administracin de grupos de RACF ......................................................................................... 12 3.3 - Alta de un grupo ...................................................................................................................... 13 3.4 - Modificacin de un grupo ........................................................................................................ 14 3.5 - Eliminacin de un grupo .......................................................................................................... 15 3.6 - Listado de un grupo ................................................................................................................. 15 3.7 - Administracin de usuarios de RACF ...................................................................................... 16 3.8 - Alta de un usuario .................................................................................................................... 18 3.9 - Modificacin de un usuario ...................................................................................................... 19 3.10 - Eliminacin de un usuario ...................................................................................................... 21 3.11 - Listado de un usuario ............................................................................................................. 22 3.12 - Comando PASSWORD.......................................................................................................... 26 3.13 - Atributos de usuario ............................................................................................................... 27 3.14 - Conexin de un usuario a un grupo ........................................................................................ 35 4 - PROTECCIN DE DATASETS ................................................................................................. 39 4.1 - Consideraciones generales ....................................................................................................... 39 4.2 - Perfiles discretos ...................................................................................................................... 40 4.3 - Perfiles genricos ..................................................................................................................... 40 4.4 - Cmo determina RACF el perfil protector de un dataset ........................................................... 41 4.5 - Niveles de autoridad para perfiles de dataset ............................................................................ 42 4.6 - Administracin de perfiles de dataset ....................................................................................... 43 4.7 - Definicin de un perfil de dataset ............................................................................................. 43 4.8 - Modificacin de un perfil de dataset ......................................................................................... 47 4.9 - Eliminacin de un perfil de dataset........................................................................................... 47 4.10 - Listado de un perfil de dataset ................................................................................................ 48 4.11 - Permisos sobre perfiles de dataset .......................................................................................... 52 4.12 - Perfiles de dataset: discretos versus genricos ........................................................................ 54 4.13 - Creacin de nuevos datasets ................................................................................................... 54 5 - OPCIONES GLOBALES DE RACF ........................................................................................... 56 5.1 - Consideraciones generales ....................................................................................................... 56 5.2 - Posit Value de una clase ........................................................................................................... 56 5.3 - Listado de la SETROPTS ......................................................................................................... 56 5.4 - Estadsticas iniciales ................................................................................................................ 59
Apuntes de RACF Juan Mautalen

4 5.5 - Control de programas ............................................................................................................... 60 5.6 - Terminales no protegidas ......................................................................................................... 60 5.7 - Auditora de usuarios con atributo SPECIAL ........................................................................... 60 5.8 - Auditora de violacin de comandos......................................................................................... 61 5.9 - Auditora de usuarios con atributo OPERATIONS ................................................................... 61 5.10 - Clases con estadsticas ........................................................................................................... 62 5.11 - Clases auditadas ..................................................................................................................... 62 5.12 - Clases activas ......................................................................................................................... 63 5.13 - Clases con perfiles genricos.................................................................................................. 64 5.14 - Clases con comandos genricos.............................................................................................. 65 5.15 - Clases con perfiles genricos compartidos en memoria (GENLISTeadas) .............................. 65 5.16 - Clases en la GLOBAL ........................................................................................................... 66 5.17 - Clases con perfiles genricos y discretos compartidos en memoria RACLISTeadas- ............ 66 5.18 - Clases RACLISTeadas va RACROUTE REQUEST=LIST, GLOBAL=YES ........................ 67 5.19 - Opciones de logging para clases ............................................................................................. 68 5.20 - Proteccin automtica de datasets .......................................................................................... 69 5.21 - Uso del ** en perfiles genricos de dataset ............................................................................. 69 5.22 - Nombres reales de dataset ...................................................................................................... 70 5.23 - Opciones relativas a JES ........................................................................................................ 70 5.24 - Protect-all .............................................................................................................................. 71 5.25 - Proteccin de archivos en cartucho......................................................................................... 72 5.26 - Perodo de retencin para archivos en cartucho ...................................................................... 72 5.27 - Borrado fsico de archivos ...................................................................................................... 73 5.28 - Archivos de un nico calificador ............................................................................................ 74 5.29 - Lista de grupos ....................................................................................................................... 74 5.30 - Revocacin automtica por inactividad .................................................................................. 75 5.31 - Modelizacin de perfiles de dataset ........................................................................................ 75 5.32 - Opciones relativas a PASSWORD ......................................................................................... 76 5.33 - Passwords del RVARY .......................................................................................................... 81 5.34 - Opciones de auditora relativas a security levels y security labels ........................................... 81 5.35 - Restriccin para la creacin de perfiles ms especficos que perfiles existentes ...................... 81 5.36 - Otras opciones vinculadas a security levels y security labels .................................................. 82 5.37 - Acceso a datasets no catalogados ........................................................................................... 83 5.38 - Mximo global y default para la validez de la clave de una sesin .......................................... 84 5.39 - Auditora de transacciones APPC ........................................................................................... 84 5.40 - Opcin ADDCREATOR ........................................................................................................ 85 5.41 - Lenguaje ................................................................................................................................ 85 5.42 - Comandos de REFRESH ....................................................................................................... 85 6 - PROTECCIN DE RECURSOS GENERALES ........................................................................ 88 6.1 - Recursos generales y perfiles ................................................................................................... 88 6.2 - Clases de miembros y agrupadoras ........................................................................................... 88 6.3 - Perfiles genricos ..................................................................................................................... 90 6.4 - Niveles de acceso ..................................................................................................................... 91 6.5 - Cmo determina RACF la proteccin de un recurso general ..................................................... 91 6.6 - Definicin de un perfil de recursos generales ........................................................................... 92 6.7 - Modificacin de un perfil de recursos generales ....................................................................... 94 6.8 - Eliminacin de un perfil de recursos generales ......................................................................... 94 6.9 - Listado de un perfil de recursos generales ................................................................................ 95 6.10 - Permisos sobre perfiles de recursos generales ......................................................................... 96 6.11 - Comando SEARCH ............................................................................................................... 97

Apuntes de RACF

Juan Mautalen

5 7 - CLASES PARTICULARES ....................................................................................................... 101 7.1 - Consideraciones generales ..................................................................................................... 101 7.2 - Clase GLOBAL ..................................................................................................................... 101 7.3 - Clase STARTED ................................................................................................................... 103 7.4 - Clase PROGRAM .................................................................................................................. 106 7.5 - Clase FACILITY ................................................................................................................... 109 8 PROCESO DE CHEQUEO DE AUTORIDAD ........................................................................ 113 8.1 - Consideraciones generales ..................................................................................................... 113 8.2 - Autoridad de un usuario sobre un recurso ............................................................................... 113 9 - PROGRAMAS UTILITARIOS ................................................................................................. 116 9.1 - Consideraciones generales ..................................................................................................... 116 9.2 - IRRUT100 ............................................................................................................................. 116 9.3 - IRRUT200 ............................................................................................................................. 118 9.4 - IRRUT400 ............................................................................................................................. 121 9.5 - IRRDBU00 ............................................................................................................................ 124 9.6 - IRRRID00 ............................................................................................................................. 125 9.7 - IRRMIN00............................................................................................................................. 128 9.8 - Otros Utilitarios ..................................................................................................................... 130 10 - COMANDO RVARY................................................................................................................ 132 10.1 - Consideraciones generales ................................................................................................... 132 10.2 - Listado de la configuracin de las bases ............................................................................... 133 10.3 - Switch de las bases ............................................................................................................... 133 10.4 - Activacin/inactivacin de las bases..................................................................................... 134 10.5 - Procedimientos de recuperacin de bases de RACF.............................................................. 135

Apuntes de RACF

Juan Mautalen

6 1 - INTRODUCCIN 1.1 - Consideraciones generales RACF (Resource Access Control Facility) es el componente del sistema operativo z/OS, provisto por IBM, para brindar seguridad en el entorno mainframe. Si bien el z/OS permite la utilizacin de otros ESM (External Security Manager) en lugar de RACF, como TOP/SECRET o ACF2, ambos de la empresa Computer Associates, vamos a asumir en todo la presente gua que el ESM utilizado es RACF. Bsicamente, RACF provee los siguientes servicios: Identificacin y autenticacin de usuarios Control de acceso a recursos Herramientas de auditora Seguridad externa para aplicaciones 1.2 - Identificacin y autenticacin de usuarios Todo usuario que requiera acceso al entorno del z/OS (subsistemas, aplicaciones, etc.) debe poseer un identificador de usuario (userid) y una clave de acceso (normalmente una password, aunque existen otros medios soportados). RACF se ocupa de identificar al usuario, comprobando que el userid exista en su base. Asimismo, se encarga de autenticarlo, controlando que la password ingresada sea la que corresponde. Adems, RACF controla en el momento del logon ciertos aspectos de seguridad adicionales. Por ejemplo, verifica que el usuario no se encuentre revocado (esto es, que no tenga sus derechos de acceso bloqueados), que est habilitado a ingresar en ese da y horario o que se encuentre autorizado a ingresar desde esa terminal. 1.3 - Control de acceso a recursos Cuando un usuario intenta acceder a un recurso protegido por RACF, la aplicacin dentro de la cual surge el requerimiento se comunica con RACF envindole, bsicamente, la siguiente informacin:
o o o o

Identificador del usuario Nombre del recurso Clase a la que pertenece el recurso Nivel de autoridad requerido (por ejemplo, lectura o grabacin, en el caso de un dataset)

En base a la informacin recibida, RACF consulta dentro de su base cmo se encuentra protegido el recurso, y devuelve a la aplicacin solicitante un cdigo de retorno que indica si el acceso est permitido (RC=00), denegado (RC=08), o si no posee la informacin necesaria para responder el requerimiento (RC=04). Es la aplicacin la que finalmente otorga o rechaza el acceso solicitado, basndose naturalmente en la respuesta recibida de RACF. 1.4 - Herramientas de auditora RACF provee una flexible gama de opciones de auditora, a travs de las cuales se pueden detectar, entre otros, los siguientes eventos:
o o o o

Da y hora en que un usuario ingres por ltima vez al sistema Intentos fallidos de ingreso al sistema Intentos de acceso a recursos (fallidos y exitosos) Intentos fallidos de ejecucin de comandos de RACF

Apuntes de RACF

Juan Mautalen

7 Ejecucin exitosa de comandos de RACF Cantidad de veces en que determinado recurso ha sido accedido

o o

La informacin relativa a accesos (exitosos o fallidos) se graba en registros tipo 80 del SMF (System Management Facility). Otro tipo de informacin, de carcter estadstico, como ser la fecha y hora del ltimo ingreso exitoso de un determinado usuario, o la cantidad de veces que se logue al sistema, se graba directamente en la base de RACF. 1.5 - Seguridad externa para aplicaciones RACF, conjuntamente con un componente bsico del sistema operativo denominado SAF (System Authorization Facility), brinda la posibilidad de desarrollar aplicaciones cuya seguridad est controlada externamente por RACF. En este sentido, es cada vez ms frecuente que los proveedores independientes de software que desarrollan productos para z/OS diseen sus aplicaciones de modo que la seguridad sea controlada externamente por RACF. Contar con un producto como RACF que centralice la seguridad de todas las aplicaciones, no solo facilita y simplifica enormemente las tareas administrativas, sino que robustece la seguridad global de la plataforma.

Apuntes de RACF

Juan Mautalen

8 2 - LA BASE DE RACF 2.1 - Consideraciones generales Describiremos, de manera muy bsica, la estructura de una base de RACF: Toda LPAR (Logical Partition) con un sistema operativo z/OS instalado exige la existencia de una base de RACF primaria y de una base de backup (opcional, aunque absolutamente recomendable), que deben residir en disco. La base de backup, que por cuestiones obvias de seguridad conviene que resida en un disco distinto al de la primaria, se actualizar automticamente cada vez que se efecten modificaciones (siempre y cuando estn configurados los parmetros necesarios para que esto suceda). De este modo, si la base primaria presenta algn error (situacin realmente muy poco frecuente, pero posible), se puede switchear fcilmente a la base de backup y seguir operando normalmente, como veremos en el captulo que trata el comando RVARY. La base primaria de RACF puede consistir de un nico dataset, o puede estar distribuida en ms de uno. El nombre de la base es de libre eleccin por parte de la organizacin, aunque naturalmente debe adecuarse a las reglas que rigen la nomenclatura de cualquier dataset dentro del entorno z/OS. Idnticas consideraciones se aplican a la base de backup (si la base primaria esta particionada en ms de un dataset, la base de backup debe estar particionada exactamente de la misma manera).

BASE PRIMARIA

BASE BACKUP

SYS1.RACF.PRIM1 SYS1.RACF.PRIM2

Actualizacin automtica

SYS1.RACF.BACK1 SYS1.RACF.BACK2

El diagrama muestra una configuracin de una base de RACF particionada en 2 datasets La alocacin e inicializacin de las bases de RACF se realiza a travs del utilitario IRRMIN00, el cual se describir en detalle en el captulo referido a programas utilitarios. Los datasets que constituyen las bases de RACF deben ser definidos con caractersticas especficas, que mencionamos a continuacin. 2.2 - Caractersticas Organization Record format Record lenght Block size Secondary cylinders PSU F 4096 4096 0 Archivo secuencial Unamovable (inamovible) Registros de longitud fija Longitud de registro de 4K (4096 bytes) Bloqueo de 4K Debe ocupar un nico extent

Es altamente recomendable que la organizacin sea PSU (Physical Secuencial Unamovable), de modo que una eventual desfragmentacin del disco dnde est alocado no mueva el dataset de lugar. En efecto, en el momento de IPL RACF toma registro de la ubicacin absoluta, dentro de los discos, de los datasets que conforman sus bases. Por lo tanto, cualquier movimiento posterior implicar que los datasets ya no se encuentren dnde RACF tiene registrado, siendo las consecuencias impredecibles (puede incluso que los problemas no se noten inmediatamente, sino que solo aparezcan cuando
Apuntes de RACF Juan Mautalen

9 efectivamente sea sobrescrito con nueva informacin el rea de disco correspondiente a la ubicacin original). Debido a esta recomendacin, es conveniente que los datasets que conforman las bases de RACF (primaria y backup) residan en discos que no se encuentren bajo SMS (Storage Management Subsystem), para que puedan alocarse como PSU. De no ser posible, deben alocarse como PS y tomarse todas las precauciones necesarias para que los datasets no sean movidos (mientras se encuentren activos en alguna LPAR). Es obligatorio que tengan su espacio alocado en forma contigua, o sea que ocupen un nico extent. El tamao de la base depende, naturalmente, del volumen de informacin que cada organizacin tenga almacenada (lo cual no solo involucra la cantidad de usuarios definidos, sino muchos otros factores adicionales). En cualquier caso, desde el punto de vista de storage, el espacio ocupado por las bases de RACF es realmente pequeo. Es habitual y recomendable que la base de backup est alocada con idntico tamao que la primaria. 2.3 - Estructura La base de RACF tiene una estructura propia bastante compleja. Slo daremos una idea bsica de cmo est organizada, ya que una descripcin detallada est ms all de los objetivos de este manual introductorio. La base de RACF est conformada, esencialmente, por entidades denominadas perfiles (profiles), que pueden pensarse como registros que contienen distintos campos. Todo perfil pertenece a una clase (class), que est identificada con un nombre de hasta 8 caracteres. Las clases, por lo tanto, agrupan lgicamente a los perfiles. En el RACF que viene con el sistema operativo z/OS 1.11, IBM provee 230 clases predefinidas, cada una con un propsito especfico, cuyos nombres son fijos e inalterables. Si fuese necesario, existe la posibilidad de definir clases adicionales. Sin embargo, en la presente gua, solo haremos referencia a las clases predefinidas por IBM, que suelen ser suficientes para satisfacer los requerimientos de seguridad habituales de una organizacin. Clase USER GROUP DATASET Descripcin Cada perfil en esta clase representa un usuario Cada perfil en esta clase representa un grupo Los perfiles en esta clase son reglas que protegen archivos

Clases de Recursos Generales (solo se enumeran muy pocas, a modo de ejemplo) TERMINAL APPL TCICSTRN PROGRAM TSOPROC ACCTNUM OPERCMDS CONSOLE SDSF STARTED Protege el uso de terminales Protege el acceso a aplicaciones VTAM Protege la ejecucin de transacciones CICS Protege la invocacin de programas Protege el uso de procedimientos de logon a TSO Protege el uso de cdigos de cuenta Protege los comandos de consola Protege el uso de las consolas Protege el uso del SDSF Reglas que asignan usuarios a Started Task

2.4 - Actualizacin de la base La base de RACF debe modificarse nicamente (salvo casos excepcionales) a travs de la ejecucin de comandos de RACF. Los comandos de RACF solo se pueden ejecutar desde una interfaz que los admita, siendo la ms usual el entorno TSO. Pueden ser ejecutados en foreground (opcin preferible, si se trata de pocos comandos), o batchground (mejor opcin si se tiene que ejecutar una gran cantidad).
Apuntes de RACF Juan Mautalen

10 Existe tambin la posibilidad de ejecutar comandos de RACF utilizando una serie de paneles accesibles desde una sesin de TSO. Estos proporcionan una interfaz amigable para el usuario, evitndole tener que recordar los comandos de RACF y su sintaxis. Sin embargo, el administrador de RACF memorizar rpidamente la sintaxis de los comandos bsicos, en cuyo caso la utilizacin de los paneles resulta lenta y tediosa, siendo mucho ms prctico y veloz ejecutar los comandos tipendolos directamente. Por lo tanto, no haremos referencia en el futuro a la utilizacin de los paneles, ya que no suelen ser muy utilizados. Aunque no suele resultar necesario en la operatoria habitual, tambin se pueden ejecutar comandos de RACF desde una consola del sistema. Esta facilidad cobra especial importancia cuando, por algn motivo, no se disponga de sesiones de TSO. Es de destacar que un usuario final, que solo tenga acceso a regiones CICS, no tendr la posibilidad de ejecutar ningn comando de RACF. Los comandos actan siempre sobre la base primaria, y son replicados inmediatamente en la base de backup (asumiendo que RACF est configurado para mantener sincronizadas ambas bases). Se listan a continuacin los comandos de RACF que consideramos ms relevantes: Comando ADDUSER ALTUSER DELUSER LISTUSER ADDGROUP ALTGROUP DELGROUP LISTGRP ADDSD ALTDSD DELDSD LISTDSD RDEFINE RALTER RDELETE RLIST PERMIT PASSWORD CONNECT REMOVE SEARCH RACDCERT SETROPTS RVARY Abreviacin AU ALU DU LU AG ALG DG LG AD ALD DD LD RDEF RALT RDEL RL PE PW CO RE SR RACDCERT SETR RVARY Descripcin Define un usuario nuevo Modifica caractersticas de un usuario existente Borra un usuario Lista las caractersticas de un usuario Define un nuevo grupo de usuarios Modifica caractersticas de un grupo existente Borra un grupo Lista las caractersticas de un grupo Define un nuevo perfil de dataset Modifica caractersticas de un perfil de dataset existente Borra un perfil de dataset Lista las caractersticas de un perfil de dataset Define un nuevo perfil de recursos generales Modifica caractersticas de un perfil de recursos generales existente Borra un perfil de recursos generales Lista las caractersticas de un perfil de recursos generales Modifica las listas de acceso de un perfil Cambia la password de un usuario Conecta un usuario a un grupo Desconecta un usuario de un grupo Permite realizar bsquedas en la base de RACF Permite la administracin de certificados digitales Lista o modifica opciones de la SETROPTS Lista, intercambia y activa/inactiva bases de RACF

Los comandos requieren operandos, algunos posicionales y otros no. A lo largo de la presente gua analizaremos la mayora de los comandos y describiremos sus operandos ms relevantes. A modo de ejemplo, mostramos a continuacin un comando que da de alta un usuario en la base de RACF:

Apuntes de RACF

Juan Mautalen

11 AU rh3472 NAME(juan) DFLTGRP(rrhh) PASSWORD(abc123) AU rh3472 NAME juan DFLTGRP rrhh PASSWORD abc123 Comando bsico, abreviacin de ADDUSER. Identificador del usuario. Variable posicional que debe seguir al comando AU. Operando no posicional que define el nombre. Valor del nombre. Operando no posicional que define el grupo default. Valor del grupo default. Operando no posicional que define la password inicial. Valor de la password inicial expirada-.

Ciertos operandos, si se omiten, toman un valor por defecto. En el caso anterior, por ejemplo, al no haberse codificado explcitamente OWNER, quedar por defecto como OWNER del nuevo usuario aquel que ejecute el comando ADDUSER.

Apuntes de RACF

Juan Mautalen

12 3 - USUARIOS Y GRUPOS 3.1 - Consideraciones generales Toda persona que deba ingresar a alguna aplicacin dentro del entorno z/OS necesita tener un identificador de usuario (userid). El mismo consiste en una cadena de caracteres alfanumricos (incluyendo los caracteres #, $ y @, conocidos como nacionales), con una longitud mnima de 1, mxima de 8 y con la restriccin de que el primer carcter no sea numrico. En el caso de usuarios de TSO, la mxima longitud admisible es de 7 caracteres, debido a una restriccin propia del TSO. RACF solo permite el uso de maysculas para identificadores de usuarios y grupos (y, en general, para casi todos los dems perfiles). De todos modos, si se ingresa informacin en minsculas, la misma es usualmente transformada automticamente a maysculas, de modo que para el administrador resulta como si RACF no distinguiera entre ambas. Cada organizacin debe elegir una convencin para los identificadores de sus usuarios, de acuerdo a sus necesidades y preferencias. Conviene recalcar la importancia de la adopcin de una buena nomenclatura, ya que eso facilita en gran medida la administracin posterior (y resulta particularmente trabajoso renombrar gran cantidad de usuarios, si se descubre que la convencin elegida inicialmente no es adecuada). Todo usuario debe ser definido en la base como miembro de un grupo de RACF, que pasa a constituir su "grupo default" (default group). Adicionalmente, el usuario puede estar conectado a otros grupos. Dicho de otro modo, si bien un usuario est eventualmente conectado a varios grupos, uno y solo uno de ellos es su grupo default. Los grupos son pues conjuntos de usuarios. Todo grupo de RACF tiene un identificador nico (grupid), que al igual que en el caso de usuarios, consiste en una cadena de caracteres alfanumricos (incluyendo #, $ y @); de longitud mnima 1 y mxima 8 y que no debe empezar con un nmero). El identificador de un grupo de usuarios lo llamaremos simplemente nombre del grupo. El nombre de un grupo no puede coincidir con el identificador de ningn usuario. Los grupos de RACF se distribuyen de acuerdo a una estructura de rbol, que surge del hecho de que todo grupo nuevo debe ser definido como subgrupo de otro existente. En lo ms alto del rbol se encuentra el grupo SYS1, que viene predefinido por IBM (no es posible cambiar su nombre). SYS1 resulta ser pues el nico grupo que no tiene grupo superior (o sea, no es subgrupo de ningn otro). 3.2 - Administracin de grupos de RACF Todas las caractersticas de un grupo de RACF se encuentran almacenadas en un perfil de grupo. Este perfil tiene distintos campos, de los cules solo describiremos los ms relevantes. NOMBRE DATA SUPGROUP OWNER Nombre del grupo. Informacin sobre el grupo, con una longitud mxima de 255 caracteres. Nombre del grupo superior. Owner del grupo.

Con respecto al nombre, ya sealamos las condiciones que debe cumplir. La Installation Data, como su nombre completo lo indica, es un campo dnde la organizacin almacena informacin administrativa sobre el grupo que considere relevante. Normalmente, este campo contiene una breve descripcin del grupo. El grupo superior es imprescindible, ya que todo grupo (excepto SYS1) debe ser subgrupo de algn otro (B tiene como grupo superior a A o B es un subgrupo de A son 2 formas distintas de expresar lo mismo).

Apuntes de RACF

Juan Mautalen

13 El concepto de owner es particularmente importante, y se aplica a cualquier tipo de perfil en la base de RACF. Todo perfil debe tener un owner, que puede ser un usuario o un grupo. En este caso particular, esto es el owner de un grupo, el valor que puede tomar debe ser un usuario o bien el grupo superior. Dicho de otro modo, no puede establecerse como owner de un grupo a otro que no sea su grupo superior. 3.3 - Alta de un grupo Sintaxis: ADDGROUP|AG nombre [DATA(installation-data)] [SUPGROUP(grupo)] [OWNER(usuario/grupo)] [OMVS([GID(valor)])] El nombre del grupo es requerido y debe estar a continuacin del comando ADDGROUP. Si no se especifica SUPGROUP, el valor que asume por defecto es el actual grupo de conexin del usuario que ejecuta el comando. Si se omite OWNER, el valor por defecto es el usuario que ejecuta el comando. El operando OMVS solo debe codificarse si se quiere proveer al grupo de un segmento de OMVS. El GID (Group IDentifier) debe ser un nmero comprendido entre 0 y 2147483647. Si se especifica OMVS y se omite GID, el valor por defecto es 0000000000. Si se omite el operando OMVS, el grupo simplemente queda definido sin este segmento. Es frecuente, dada la cantidad de operandos que es necesario codificar en algunos casos, que los comandos no entren en una nica lnea. Si se ejecutan desde un dataset o embebidos en un job, un guin (-) al final de la lnea indica que el comando contina en la siguiente. Tambin existe una opcin dentro del men del ISPF que permite ingresar comandos en foreground que ocupen ms de un rengln. Ejemplo: AG conta DATA(Subgerencia de Contabilidad) SUPGROUP(finanzas) OWNER(finanzas) Este comando define un nuevo grupo de nombre CONTA. El mismo se define como subgrupo del grupo FINANZAS, que debe existir previamente (sino el comando falla). En este caso, se eligi definir como owner a un grupo, que por lo tanto debe ser el grupo FINANZAS. Autoridad requerida Para definir un nuevo grupo, quien ejecuta el comando debe satisfacer alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema. Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de accin al grupo superior del que se intenta definir. Ser el owner del grupo superior. Estar conectado al grupo superior con nivel de autoridad JOIN. Para poder definir al grupo con algn segmento no base (por ejemplo, el segmento OMVS), el usuario tiene que cumplir alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema. Tener autoridad a travs de perfiles apropiados en la clase FIELDS.

Apuntes de RACF

Juan Mautalen

14 3.4 - Modificacin de un grupo Sintaxis: ALTGROUP|ALG nombre [DATA(installation-data)|NODATA] [SUPGROUP(grupo)] [OWNER(usuario/grupo)] [OMVS([GID(valor)|NOGID])|NOOMVS] Naturalmente, solo es necesario incluir aquellos operandos que correspondan a los campos que se desee modificar. No se aplica, en este caso, ningn valor por defecto. Ejemplo: ALG conta DATA(Sector de Contabilidad - Jefatura) Este comando modifica la Installation Data del grupo CONTA. Consideraciones: Hacemos notar que el nuevo valor especificado en DATA reemplaza ntegramente al valor anterior. No se puede modificar parcialmente este campo. Si se pretende agregar algo a continuacin de la DATA existente, debe ejecutarse el comando retipeando toda la DATA. Esto no solo es vlido para grupos, sino para la Installation Data de cualquier perfil en la base de RACF. No existe la opcin de modificar el nombre de un grupo. La nica forma que prev RACF para renombrar un grupo consiste en darlo de baja para luego redefinirlo con el nuevo nombre. Esto es trabajoso, ya que antes de borrar el grupo viejo, debe tomarse debida nota de los usuarios que tiene conectados, as como tambin de todas sus autorizaciones, de modo que el nuevo grupo resulte un clon del anterior. Al no ser una tarea sencilla, conviene establecer desde el comienzo una buena nomenclatura, de modo a evitar, dentro de lo posible, tener que rebautizar grupos en el futuro. Autoridad requerida Para poder modificar el grupo superior, quien ejecuta el comando debe cumplir con alguna de las condiciones siguientes: Tener el atributo SPECIAL a nivel de sistema. Tanto para el actual grupo superior como para el futuro, satisfacer alguna de las opciones que se enumeran: - Ser el owner. - Estar conectado con nivel de autoridad JOIN. - Tener el atributo SPECIAL a nivel de un grupo que lo tenga dentro de su campo de accin. Observemos que si el owner del grupo era su grupo superior, no podr cambiarse el grupo superior sin modificar asimismo el owner (ya que el nico grupo que se admite como owner es el grupo superior) Para poder especificar cualquier otro operando del comando ALTGROUP (con excepcin del manejo de segmentos no base), quien ejecuta el comando debe satisfacer alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema. Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de accin al grupo que se modifica. Ser el owner del grupo. Para poder agregar, modificar o deletear segmentos no base del grupo, quien ejecuta el comando debe satisfacer alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema.

Apuntes de RACF

Juan Mautalen

15 Tener autoridad a travs de perfiles apropiados en la clase FIELDS. 3.5 - Eliminacin de un grupo Sintaxis: DELGROUP|DG nombre Consideraciones: RACF no permite borrar un grupo que tenga usuarios conectados. En consecuencia, como paso previo al comando DELGROUP, deben ser removidos todos sus usuarios. RACF no permite borrar un grupo que tenga subgrupos. Por lo tanto, debe modificarse el grupo superior de todos aquellos grupos que sean subgrupos del que se quiere borrar. RACF no permite borrar un grupo si existen en la base perfiles de dataset cuyo primer calificador (High level Qualifier, o HLQ) coincida con el nombre del grupo. Los mismos deben deletearse previamente a la ejecucin de comando DELGROUP, ya que en caso contrario el comando falla. La ejecucin exitosa del comando DELGROUP no elimina las referencias al grupo que puedan existir en otros perfiles de la base (por ejemplo, el grupo puede figurar en la lista de acceso de perfiles de dataset o de recursos generales). Por esta razn, con el objeto de mantener la base prolija (sin referencias a grupos inexistentes), el borrado del grupo debe ser acompaado de la eliminacin de todas las referencias al mismo que existan en la base. Mas adelante veremos que IBM provee, a tal efecto, el utilitario IRRRID00. Autoridad requerida Para poder borrar un grupo, quien ejecuta el comando debe cumplir con alguna de las condiciones siguientes: Tener el atributo SPECIAL a nivel de sistema. Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de accin al grupo que se pretende borrar. Ser el owner del grupo superior. Estar conectado al grupo superior con nivel de autoridad JOIN. Ser el owner del grupo que se pretende deletear. 3.6 - Listado de un grupo Sintaxis: LISTGRP|LG nombre [OMVS] Este comando, a diferencia de los anteriores, no efecta ninguna modificacin sobre la base de RACF. Unicamente lista (en la pantalla de la terminal, si se ejecuta en foreground, o con salida a un dataset o al spool, si se ejecuta en batchground) informacin relativa al grupo. Ejemplo: LG conta OMVS La salida tendra el siguiente aspecto:
INFORMATION FOR GROUP CONTA SUPERIOR GROUP=FINANZAS OWNER=FINANZAS INSTALLATION DATA=SECTOR DE CONTABILIDAD - JEFATURA NO MODEL DATA SET TERMUACC Apuntes de RACF CREATED=10.245

Juan Mautalen

16
SUBGROUP(S)= USER(S)= PAGOS SUELDOS ACCESS COUNT= 001475 RESUME DATE=NONE 002487 RESUME DATE=NONE NONE UNIVERSAL ACCESS= NONE

ACCESS=

CONJF01 USE CONNECT ATTRIBUTES=NONE REVOKE DATE=NONE CONFJ02 USE CONNECT ATTRIBUTES=NONE REVOKE DATE=NONE OMVS INFORMATION GID= 0000000015

Del listado precedente, se desprende claramente la siguiente informacin sobre el grupo CONTA: El grupo superior es el grupo FINANZAS. El owner del grupo CONTA es el grupo FINANZAS. El grupo fue creado el da 245 del ao 2010. El grupo CONTA tiene 2 subgrupos, cuyos nombres son PAGOS y SUELDOS. El grupo CONTA tiene 2 usuarios conectados, de identificadores CONFJ01 y CONFJ02. El grupo CONTA tiene segmento de OMVS con un GID igual 15. No describiremos, en este punto, el resto de la informacin listada, ya que para comprender ciertos campos especficos se requieren nociones que se vern ms adelante (MODEL y TERMUACC, por ejemplo). Autoridad requerida Para listar el segmento base de un perfil de grupo, quien ejecuta el comando debe cumplir con alguna de las condiciones siguientes: Tener el atributo SPECIAL a nivel de sistema. Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de accin al grupo que se pretende listar. Tener el atributo AUDITOR a nivel de sistema. Tener el atributo AUDITOR a nivel de un grupo que tenga dentro de su campo de accin al grupo que se pretende listar. Ser el owner del grupo. Estar conectado al grupo con nivel de autoridad CONNECT o JOIN. Para poder listar segmentos no base del grupo, quien ejecuta el comando debe satisfacer alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema. Tener autoridad a travs de perfiles apropiados en la clase FIELDS. 3.7 - Administracin de usuarios de RACF Todas las caractersticas de un usuario de RACF se encuentran almacenadas en un perfil de usuario, que consta de un segmento base (obligatorio), ms, opcionalmente, algunos segmentos no base (por ejemplo, segmentos de TSO, OMVS, etc.). Todos los segmentos se componen de campos, de los cuales nos ocuparemos en este punto nicamente de los ms relevantes.

Apuntes de RACF

Juan Mautalen

17 Segmento Base USERID NAME DATA DFLTGRP PASSWORD OWNER Segmento de TSO PROC ACCTNUM COMMAND SIZE MAXSIZE Identificador del usuario. Nombre asociado con el usuario, de longitud mxima 20. Informacin sobre el usuario, con una longitud mxima de 255 caracteres. Nombre del grupo default del usuario. Password que se otorga usuario. Owner del usuario. Nombre del procedimiento de logon a TSO (default) para el usuario Cdigo de cuenta (default) para el usuario Comando a ejecutarse durante el logon a TSO Tamao mnimo de la regin, expresado en Kbytes, default para el usuario Tamao mximo que el usuario puede requerir en el momento de logon

Segmento de OMVS UID UID del usuario. Nmero entre 0 y 2147483647. 0 indica superusuario. HOME Home directory del usuario. PROGRAM Shell asignado. Con respecto al identificador del usuario, ya sealamos anteriormente las condiciones que debe cumplir. En el campo NAME, si se trata de una persona fsica, se pone usualmente su nombre y apellido. En el caso de usuarios asociados a procesos, se puede colocar un nombre que identifique la tarea para la que es utilizado. En la DATA, la organizacin guarda informacin administrativa que considere importante sobre el usuario. Por ejemplo, se puede incluir su nmero de documento y el sector de la empresa dnde desempea sus tareas. El grupo default debe ser un grupo que exista previamente en la base de RACF. La password inicial es una clave expirada, lo cual significa que el usuario es forzado a cambiarla en el momento del logon inicial. Por esta razn, no es necesario que cumpla con las reglas para passwords fijadas por la organizacin en la SETROPTS (esto se ver en detalle en el captulo correspondiente). Debe tener una longitud mxima de 8 caracteres. Es de destacar que RACF permite tambin la autenticacin a travs de Password Phrases, que son cadenas de caracteres alfanumricos y especiales (incluyendo blancos), de longitud mnima 9 y mxima 100. Presentan una posibilidad ms robusta que las passwords tradicionales, dada su mayor longitud. Sin embargo, por el momento son de utilidad limitada ya que existen aplicaciones que no las soportan, algunas de uso muy difundido. CICS, por ejemplo, acaba de anunciar el soporte de Password Phrases para su versin 4.2, que recin estar disponible a mediados del 2011. Tambin debemos sealar que, an cuando el usuario tenga asignada una Password Phrase, debe tambin obligatoriamente contar con una password tradicional (que podra ser desconocida por el usuario, para que se vea obligado a autenticarse usando su Password Phrase). Por lo tanto, si bien creemos importante mencionar su existencia y entendemos que en el futuro van seguramente a desempear un rol relevante, no haremos ms referencias a ellas en el presente manual. El OWNER del usuario puede ser cualquier otro grupo o usuario existente en la base de RACF. El segmento de TSO solo debe definirse para usuarios que tengan que usar esta facilidad. La mayora de los parmetros especificados se convierten en los valores default para el usuario, quien puede cambiarlos, de ser necesario, en la pantalla de logon a TSO.

Apuntes de RACF

Juan Mautalen

18 El segmento de OMVS solo debe definirse para usuarios que lo necesiten. Existe incluso, a partir del z/OS 1.11, la posibilidad de configurar RACF de forma que este segmento se le agregue automticamente a los usuarios la primera vez que invoquen algn servicio Unix que lo requiera. 3.8 - Alta de un usuario Sintaxis: ADDUSER|AU userid [NAME(nombre)] [DFLTGRP(grupo)] [DATA(installation-data)] [PASSWORD(clave-inicial)|NOPASSWORD] [OWNER(usuario/grupo)] [AUTHORITY(nivel)] [UACC(nivel)] [SPECIAL|NOSPECIAL] [OPERATIONS|NOOPERATIONS] [AUDITOR|NOAUDITOR] [RESTRICTED|NORESTRICTED] [GRPACC|NOGRPACC] [ADSP|NOADSP] [CLAUTH(clase)|NOCLAUTH] [WHEN(DAYS(das) TIME(hora-inicio:hora-fin))] [TSO(PROC(nombre-del-procedimiento-de-TSO) ACCTNUM(cdigo-de-cuenta))] [OMVS(UID(valor) PROGRAM(nombre-del-programa) HOME(directorio-inicial))] El userid es requerido y debe estar inmediatamente a continuacin del comando ADDUSER. Si no se codifica NAME, este campo aparece como UNKNOWN cuando se lista el usuario a travs del comando LISTUSER. Si no se especifica DFLTGRP, el valor que asume por defecto es el actual grupo de conexin del usuario que ejecuta el comando. Si no se especifica DATA, este campo queda vaco y al listar el usuario se muestra la leyenda NOINSTALLATION_DATA. Si no se codifica PASSWORD, asume por defecto como password inicial el grupo especificado en el operando DFLTGRP. Esto no es para nada recomendable desde el punto de vista de la seguridad, ya que los nombres de los grupos suelen ser pblicos. Por lo tanto, es aconsejable siempre especificar una password, de modo a evitar que asuma el valor por defecto. Si se especifica NOPASSWORD, y el usuario tiene tambin NOOIDCARD (que es el defecto), el usuario adquiere el atributo PROTECTED, del cual hablaremos en ms adelante. Los atributos SPECIAL, OPERATIONS, AUDITOR, RESTRICTED, GRPACC, ADSP y CLAUTH no se otorgan, salvo que se los codifique explcitamente. Si se omite OWNER, el valor por defecto es el usuario que ejecuta el comando. AUTHORITY indica el nivel de autoridad que tendr el usuario como miembro de su grupo default. El valor por defecto es USE. Ms adelante se vern en detalle los posibles valores y su significado. UACC indica el acceso universal del usuario para su grupo default. El valor por defecto es NONE. Mas adelante, al analizar un ejemplo del comando LISTUSER, se vern en detalle los posibles valores y su significado. El parmetro WHEN especifica los das de la semana y las horas del da en los cuales el usuario est autorizado a ingresar al sistema. Este chequeo se realiza nicamente en el momento en que RACF procesa el pedido de logon. Por lo tanto, si el usuario ingres en un da y horario vlidos, pero su sesin se extendi ms all de los lmites permitidos, no ser forzado a salir del sistema (naturalmente, en tal caso, si cierra la sesin, ya no podr reingresar). Estas restricciones no se aplican para la ejecucin de trabajos batch (o sea, un job del usuario puede iniciarse y ejecutarse fuera de los das y horarios permitidos). Si no se especifica el operando WHEN, el valor por defecto es ANYDAY/ANYTIME, lo cual autoriza al usuario a ingresar en cualquier da y horario. Por ejemplo, podra establecerse que el usuario solo est habilitado para ingresar al sistema lunes, mircoles y viernes de 8 a 19:30 horas. En tal caso, debera codificarse el operando WHEN del siguiente modo: WHEN(DAYS(monday wednesday friday) TIME(0800:1930))

Apuntes de RACF

Juan Mautalen

19 Para los operandos TSO y OMVS, solo se indicaron los suboperandos ms frecuentes, existiendo varios otros. Si no se especifica TSO u OMVS, el usuario simplemente queda definido sin tal segmento. Autoridad requerida Para definir un nuevo usuario, quien ejecuta el comando debe cumplir con alguna de las condiciones siguientes: Tener el atributo SPECIAL a nivel de sistema. Tener CLAUTH en la clase USER y verificar adems alguno de los siguientes requisitos: - Ser el owner del grupo default especificado en el comando ADDUSER. - Estar conectado con nivel de autoridad JOIN al grupo default especificado en el comando ADDUSER. - Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de accin al grupo default especificado en el comando ADDUSER. Para poder definir al usuario con algn segmento no base (por ejemplo, segmentos de TSO u OMVS), quien ejecuta el comando tiene que cumplir alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema. Tener autoridad a travs de perfiles apropiados en la clase FIELDS. 3.9 - Modificacin de un usuario Sintaxis: ALTUSER|ALU userid [NAME(nombre)] [DFLTGRP(grupo)] [DATA(installation-data)|NODATA] [PASSWORD(clave-inicial)|NOPASSWORD] [EXPIRED|NOEXPIRED] [OWNER(usuario/grupo)] [UAUDIT|NOUAUDIT] [GROUP(nombre)] [AUTHORITY(nivel)] [UACC(nivel)] [SPECIAL|NOSPECIAL] [OPERATIONS|NOOPERATIONS] [AUDITOR|NOAUDITOR] [RESTRICTED|NORESTRICTED] [GRPACC|NOGRPACC] [ADSP|NOADSP] [RESUME(mm/dd/aa) |NORESUME] [REVOKE(mm/dd/aa) |NOREVOKE] [WHEN(DAYS(das) TIME(hora-inicio:hora-fin))] [TSO(PROC(nombre-del-proc)|NOPROC ACCTNUM(cdigo)|NOACCTNUM))|NOTSO] [OMVS([UID(valor)|NOUID] [PROGRAM(nombre-del-programa)|NOPROGRAM] [HOME(directorio-inicial)|NOHOME])|NOOMVS] Naturalmente, solo es necesario incluir los operandos que corresponden a los campos que se quiere modificar .No se aplica ningn valor por defecto en este caso. DFLTGRP indica el nombre del nuevo grupo default del usuario, al cual debe encontrarse conectado previamente. Observemos que el usuario contina conectado a su antiguo grupo default. EXPIRED|NOEXPIRED solo surte efecto si ha sido codificado el operando PASSWORD. El valor por defecto es EXPIRED, el cual indica que el usuario est obligado a cambiar su password por una nueva en el momento de su prximo logon. Por ello, en este caso, no es necesario que la password otorgada cumpla con las reglas fijadas por la organizacin, que se encuentran especificadas en la SETROPTS. Debe, de todos modos, tener una longitud mxima de 8 caracteres. NOEXPIRED indica que el usuario no estar forzado a cambiar su password en el momento de su prximo logon (aunque naturalmente puede hacerlo, si as lo desea y la aplicacin lo permite). De todos modos, ello no significa que su password nunca venza. El usuario, a menos que se le haya dado NOINTERVAL a travs del comando PASSWORD, se encuentra sujeto a la poltica usual de cambio peridico de password establecida por la organizacin. Toda password dada con NOEXPIRED debe adecuarse a las reglas fijadas en la SETROPTS.
Apuntes de RACF Juan Mautalen

20 GROUP indica el nombre de un grupo al cual el usuario se encuentra previamente conectado y sobre el cual actuarn los nuevos valores especificados en los operandos AUTHORITY y UACC. Si se omite GROUP, pero se codifica AUTHORITY o UACC, los mismos actan sobre del grupo default del usuario (an en el caso en que se haya especificado DFLTGRP para cambiar el grupo default del usuario, actan sobre viejo). REVOKE(mm/dd/aa) especifica una fecha futura a partir de la cual el usuario no podr acceder al sistema. Si la fecha ingresada no es posterior a la fecha actual, RACF informa que la fecha no es vlida, y enva al usuario que ejecuta el comando un mensaje para que especifique una fecha futura (esto ltimo, suponiendo que el comando se ejecuta en foreground. Si la ejecucin es en batch, simplemente se ignora el operando, por fecha invlida). Mientras el usuario tenga una fecha de revocacin futura, se considera que tiene un REVOKE pendiente. Si se codifica REVOKE sin especificar fecha, el REVOKE toma efecto la prxima vez que el usuario ingrese al sistema. En este caso, el usuario adquiere el atributo REVOKED (ms adelante veremos en detalle todos los atributos de usuario). NOREVOKE tiene como efecto quitar la fecha de revocacin futura, si el usuario la tuviera. RESUME(mm/dd/aa) especifica una fecha futura a partir de la cual el usuario podr acceder al sistema nuevamente. Usualmente, se utiliza este operando para anular el efecto del REVOKE. En el caso en que el usuario no tenga un REVOKE pendiente, o no tenga el atributo REVOKED, el RESUME(mm/dd/aa) es ignorado. Mientras el usuario tenga una fecha de resume futura, se considera que tiene un RESUME pendiente. Si se codifica RESUME sin especificar fecha, el RESUME toma efecto inmediatamente (o sea, habilita al usuario a ingresar al sistema de inmediato) y le saca el atributo REVOKED, si lo tuviera. NORESUME tiene como efecto quitar la fecha de resume futura, si el usuario la tuviera. Si se especifican ambos operandos REVOKE(mm/dd/aa) y RESUME(mm/dd/aa), las fechas no deben entrar en conflicto (bsicamente, la fecha especificada en RESUME debe ser posterior a la fecha del REVOKE). Por ejemplo, el siguiente comando inhabilita al usuario fin7632 a usar el sistema desde el 1/1/2010 hasta el 31/1/2010. ALU fin7632 REVOKE(1/1/10) RESUME(31/1/10) Con respecto al formato de la fecha, el mismo debe ser mes/da/ao. Los ceros a la izquierda, para mes y da, pueden ser omitidos (1/1/03 equivale a 01/01/03). El ao debe ser siempre de 2 dgitos, y se extiende a 4 de acuerdo al siguiente criterio: aa se traduce en 20aa si aa es menor a 71 aa se traduce en 19aa si aa es mayor o igual a 71 Consideraciones: Slo puede cambiarse el grupo default de un usuario por otro grupo al cual se encuentre previamente conectado. Si el grupo especificado en DFLTGRP no es un grupo al cual est conectado, el grupo default no es alterado. Esto no evita que el resto del comando se procese. Es posible y frecuente que un comando de RACF solo resulte exitoso parcialmente. No existe la opcin de modificar el identificador de un usuario. La nica forma prevista por RACF para renombrar un usuario consiste en deletearlo y darlo de alta nuevamente con el nuevo identificador. Esto es trabajoso, ya que antes de borrar el usuario viejo, debe tomarse debida nota de los grupos a los que se encuentra conectado, as como tambin de todas las autorizaciones que tiene, de modo que el nuevo usuario resulte un clon del anterior. Al no ser una tarea sencilla, conviene establecer desde el comienzo una buena nomenclatura de usuarios, de modo a evitar, dentro de lo posible, tener que rebautizar en el futuro. Autoridad requerida El nivel de autoridad requerido depende del campo del perfil de usuario que se pretenda modificar. Mencionamos a continuacin algunos casos, que consideramos los ms relevantes. La lista no pretende de ningn modo ser exhaustiva.
Apuntes de RACF Juan Mautalen

21 El atributo SPECIAL a nivel de sistema permite especificar cualquier operando, con excepcin de UAUDIT/NOUAUDIT. Si el owner del usuario est dentro del campo de accin de un grupo en el cual el usuario tiene el atributo SPECIAL, entonces puede especificar cualquier operando, con excepcin de SPECIAL, AUDITOR, OPERATIONS y UAUDIT/NOUAUDIT. Si es el owner del usuario, entonces bsicamente puede especificar cualquier operando, con excepcin de SPECIAL, AUDITOR, OPERATIONS y UAUDIT/NOUAUDIT. Para otorgar CLAUTH sobre una clase debe adems tener l mismo CLAUTH sobre ella. Todo usuario puede cambiar su NAME y DFLTGRP. Naturalmente, si decide cambiar su grupo default, debe encontrarse previamente conectado al nuevo grupo que especifique. Para poder otorgar los atributos SPECIAL, AUDITOR y OPERATIONS a nivel de sistema se requiere el atributo SPECIAL a nivel de sistema. Para especificar UAUDIT/NOUAUDIT, es necesario tener el atributo AUDITOR a nivel de sistema, o bien a nivel de un grupo que tenga al usuario dentro de su campo de accin. Para agregar, modificar o deletear informacin de segmentos no base del usuario, se requiere el atributo SPECIAL a nivel de sistema o bien tener suficiente autoridad en perfiles apropiados de la clase FIELDS. Si tiene autorizacin sobre el recurso IRR.PASSWORD.RESET de la clase FACILITY puede otorgar una nueva password para cualquier usuario (ver 7.5). 3.10 - Eliminacin de un usuario Sintaxis: DELUSER|DU userid Este comando borra de la base de RACF el perfil del usuario, as como tambin elimina las conexiones que el usuario pueda tener a distintos grupos. Por lo tanto, no solo deletea el perfil del usuario, sino que tambin modifica los perfiles de los grupos a los cuales se encuentra conectado. Es habitual, como se ve en este ejemplo, que un comando de RACF impacte sobre ms de un perfil de la base. Sin embargo, el comando DELUSER no elimina al usuario de otros perfiles de la base dnde pueda figurar. Por ejemplo, el usuario puede estar en listas de acceso, o puede ser owner de algn otro perfil de la base. Si bien la existencia de tales referencias no impide la ejecucin exitosa del comando DELUSER, no es una buena prctica dejar en la base referencias a usuarios inexistentes. Por lo tanto, del mismo modo que en el caso de la eliminacin de grupos, es apropiado identificarlas y borrarlas. Consideraciones: No es posible borrar un usuario si existen en la base perfiles de dataset cuyo HLQ sea igual al identificador del usuario. Los mismos deben borrarse previamente, ya que en caso contrario el comando DELUSER falla. En concordancia con lo anterior, tambin deben renombrarse (o deletearse, si no fuese necesario conservarlos) los datasets cuyo HLQ coincida con el identificador del usuario. Esto hay que hacerlo antes de borrar los perfiles de dataset, para evitar, por un lado, tener que manipular archivos no protegidos, as como tambin para preservar su nivel de proteccin, si alguno de ellos tuviera un perfil discreto. Esto quedar claro en el captulo siguiente, cuando tratemos especficamente la proteccin de datasets. Si el usuario a eliminar se encuentra trabajando dentro del sistema en el momento en que se ejecuta el comando de baja, es muy posible que pueda seguir hacindolo normalmente hasta que cierre su sesin. Obviamente, una vez que salga del sistema, ya no podr ingresar nuevamente. Si resultara imprescindible que cese de inmediato toda actividad, se puede solicitar a los operadores del equipo que cancelen todas las sesiones que pueda tener activas.
Apuntes de RACF Juan Mautalen

22 Como dar de baja a un usuario de manera adecuada puede llevar algo de tiempo, resulta til, como medida inicial, revocarle su acceso al sistema ejecutando el comando: ALTUSER userid REVOKE De este modo, el usuario queda imposibilitado de ingresar al sistema (si ya est adentro, corresponden las mismas consideraciones que en el punto anterior) durante el tiempo que insuman los pasos previos a la baja. Incluso, en algunas organizaciones, se va revocando diariamente a los usuarios a ser dados de baja, hasta que al cabo de una semana, por ejemplo, se ejecuta un proceso que los borra efectivamente. Autoridad requerida Para poder deletear un usuario, quien ejecuta el comando debe cumplir con alguna de las condiciones siguientes: Tener el atributo SPECIAL a nivel de sistema. Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de accin al usuario que se pretende eliminar. Ser el owner del usuario. Estar conectado a su grupo default con nivel de autoridad JOIN no es suficiente para poder deletear el usuario. 3.11 - Listado de un usuario Sintaxis: LISTUSER|LU userid [TSO] [OMVS] Este comando no efecta ninguna modificacin sobre la base de RACF. nicamente lista informacin relativa al usuario. Si se especifica el operando TSO u OMVS, se lista tambin tal segmento. Si no se especifican especialmente, los segmentos no base no son listados (existen varios ms que los dos mencionados, pero no nos ocuparemos de ellos en esta gua). Ejemplo: LU fin7632 TSO OMVS La salida tendra el siguiente aspecto:
USER= FIN7632 NAME= PEREZ ALEJANDRA OWNER= FINADM CREATED= 10.158 DEFAULT-GROUP= FINANZAS PASSDATE= 10.308 PASS-INTERVAL= 30 PHRASEDATE=N/A ATTRIBUTES= NONE REVOKE DATE= NONE RESUME DATE= NONE LAST-ACCESS= 10.309/09:48:25 CLASS AUTHORIZATIONS= NONE INSTALLATION-DATA= DNI:24857632 NO-MODEL-NAME LOGON ALLOWED (DAYS) (TIME) --------------------------------------------------------------ANYDAY ANYTIME GROUP= FINANZAS AUTH= USE CONNECT-OWNER= FINADM CONNECT-DATE= 10.158 CONNECTS= 857 UACC= NONE LAST-CONNECT= 10.309/09:48:25 CONNECT ATTRIBUTES= NONE REVOKE DATE= NONE RESUME DATE= NONE GROUP= COBROS AUTH= USE CONNECT-OWNER= FINADM CONNECT-DATE= 10.184 CONNECTS= 00 UACC= NONE LAST-CONNECT= UNKNOWN CONNECT ATTRIBUTES= NONE REVOKE DATE= NONE RESUME DATE= NONE SECURITY-LEVEL= NONE SPECIFIED Apuntes de RACF Juan Mautalen

23
CATEGORY-AUTHORIZATION NONE SPECIFIED SECURITY-LABEL= NONE SPECIFIED TSO INFORMATION ----------------------------ACCTNUM= FINA01 PROC= IKJFIN SIZE= 00008192 MAXSIZE= 00000000 USERDATA= 0000 COMMAND= NO OMVS INFORMATION

Del listado precedente, se obtiene gran cantidad de informacin sobre el usuario FIN7632, entre la que destacamos la siguiente: El grupo default es el grupo FINANZAS. El campo CREATED indica la fecha de creacin del usuario, en formato juliano. En el ejemplo expuesto, el usuario fue dado de alta el 7 de junio del ao 2010 (da 158 del ao 10). El OWNER es FINADM, que en principio podra ser un grupo o un usuario. En caso de ser un usuario, esto no significa que sea FINADM quin ejecut el comando de alta. En ningn lugar de la base de RACF est guardada la informacin sobre quin dio el alta (este dato debera rastrearse en los registros tipo 80 del SMF, dnde se loguea informacin sobre los comandos de RACF ejecutados). PASSDATE indica la fecha en la que el usuario cambi su password por ltima vez. Todo usuario puede cambiar su password en cualquier momento, si as lo desea, ya sea a travs del comando PASSWORD, o bien mediante los paneles de logon de ciertas aplicaciones (TSO o CICS, por ejemplo). El valor 00.000 significa que el usuario tiene una password expirada. Esto indica que an no ha ingresado desde que el administrador se la otorg. PASS-INTERVAL establece la cantidad de das que la password de este usuario permanecer vlida, contados a partir del da en que se cambi por ltima vez. El valor debe estar comprendido entre 1 y 254. De todos modos, la cantidad de das pasados los cules el usuario es forzado a cambiar su password surge del mnimo entre el valor del PASS-INTERVAL del usuario y el valor global seteado en la SETROPTS. Por ejemplo, si el usuario tiene PASS-INTERVAL=45 en su perfil, pero el valor de la SETROPTS es 30, tendr que cambiar su password obligatoriamente cada 30 das. PASS-INTERVAL=N/A indica que el usuario tiene una password que nunca vence. Desde el punto de vista de seguridad, esta es una opcin poco recomendable. Es til, sin embargo, para usuarios que no corresponden a personas fsicas (siempre y cuando se pueda tener certeza de que nadie conoce su password). Si ambos campos PASSDATE y PASS-INTERVAL tienen el valor N/A, entonces el usuario tiene el atributo PROTECTED, al cual nos referiremos ms adelante. ATTRIBUTES= NONE muestra que el usuario no posee ningn atributo particular a nivel de sistema. Examinaremos posteriormente en detalle los posibles atributos que se le pueden otorgar a un usuario. El campo LAST-ACCESS indica fecha y hora en que el usuario ingres al sistema por ltima vez, con ciertas salvedades: - Si al usuario se le da un RESUME, los valores del campo LAST-ACCESS son actualizados con la fecha y hora en que se ejecut el comando.

Apuntes de RACF

Juan Mautalen

24 - Si se cambia la password del usuario, ya sea con el comando ALTUSER o PASSWORD, los valores del campo LAST-ACCESS son actualizados con la fecha y hora en que se ejecut el comando. - Si un job se ejecuta bajo la identidad del usuario, los valores del campo LAST-ACCESS son igualmente actualizados con la fecha y hora de iniciacin del job. - Si el usuario nunca ingres, el campo LAST-ACCESS muestra el valor UNKNOWN. Es importante tener en cuenta estos detalles, para no interpretar errneamente la informacin brindada por el campo LAST-ACCESS. LOGON ALLOWED (anyday anytime) significa que el usuario no tiene ninguna restriccin de da y horario para ingresar al sistema. A continuacin, en la salida del comando LU, figuran todos los grupos a los cuales el usuario est conectado, mostrando varios parmetros que caracterizan cada conexin. El primer grupo listado es siempre el grupo default del usuario (recordemos que todo usuario est conectado, como mnimo, a su grupo default). Para cada uno de los grupos, la informacin mostrada tiene idnticos campos, que describimos a continuacin: Un usuario es conectado a un grupo con un determinado nivel de autoridad. Este se muestra en el campo AUTH, y sus posibles valores son: USE, CREATE, CONNECT y JOIN (enumerados en orden jerrquico, o sea que cada uno incluye los privilegios del anterior). El valor por defecto es USE, suficiente para la casi totalidad de los casos. Ms adelante discutiremos en detalle los alcances de cada uno de estos niveles. CONNECT-OWNER es un campo que se mantiene por razones de compatibilidad con versiones anteriores de RACF, pero que actualmente es totalmente irrelevante desde el punto de vista de seguridad. El valor que asume por defecto es el usuario que conect el usuario al grupo. CONNECT-DATE muestra la fecha en que el usuario fue conectado al grupo. El campo CONNECTS indica la cantidad de veces que el usuario ingres al sistema especificando este grupo en el momento de logon (tanto CICS como TSO permiten, por ejemplo, especificar un grupo en la pantalla de logon). Como actualmente es muy habitual que la opcin GRPLIST est activa en la SETROPTS (esto se analizar en detalle ms adelante, en el captulo dedicado a la SETROPTS), no suele especificarse un grupo distinto del default en la pantalla de logon. En virtud de ello, es frecuente que solo se incremente la cuenta del campo CONNECTS para el grupo default del usuario, quedando el mismo en 00 para los otros grupos. As, en el ejemplo mostrado, el usuario FIN7632 se conect 857 veces usando su grupo default, de nombre FINANZAS, mientras que la cuenta para el otro grupo al que est conectado, llamado COBROS, permanece en 00. Esto no significa, de ninguna manera, que el usuario no est haciendo uso de su conexin al grupo COBROS. Obtener acceso a un recurso protegido gracias d pertenecer a un cierto grupo no incrementa el valor del campo CONNECTS para ese grupo. Solo se incrementa el contador cuando el usuario se loguea a una aplicacin especificando al grupo como grupo de conexin. El campo UACC en la conexin de un usuario a un grupo puede tomar los valores NONE, READ, UPDATE, CONTROL o ALTER, siendo NONE el valor por defecto. Este parmetro, que se especifica a nivel de grupo, determina el UACC de los perfiles de dataset o de recursos generales que el usuario eventualmente defina en la base de RACF, siempre y cuando haya iniciado la sesin especificando este grupo como grupo de conexin, y se cumpla que: - El usuario no codifica explcitamente el operando UACC en la definicin del perfil. En caso contrario, este valor prevalece. - Para perfiles de recursos generales, la clase de RACF correspondiente no debe tener DFTUACC especificado en la CDT (Class Descriptor Table), pues de otro modo el perfil toma por defecto ese valor.
Apuntes de RACF Juan Mautalen

25 Por ejemplo, si un usuario tiene UACC(READ) especificado en su conexin a su grupo default, (y se loguea a TSO sin cambiar el grupo en el panel de logon, de modo que su grupo de conexin sea efectivamente su grupo default), entonces si define un perfil de dataset y no especifica UACC, el perfil quedar definido con UACC(READ). La enorme mayora de los usuarios no define perfiles en la base de RACF, por lo cual el UACC de la conexin no tiene mayor relevancia. Para los usuarios administradores, que deben definir nuevos perfiles en la base de RACF, conviene de todos modos conservar el valor default UACC=NONE en la conexin a cada uno de sus grupos. De este modo, los perfiles de RACF que definan tendrn por defecto UACC(NONE), lo cual es conveniente desde el punto de vista de seguridad. Si necesitaran crear un perfil con un UACC distinto de NONE, no tienen ms que codificar dicho operando con el valor deseado en el comando de definicin del perfil. El campo LAST-CONNECT muestra fecha y hora en la que el usuario ingres por ltima vez al sistema con este grupo como "grupo de conexin". Recordemos que si el usuario no especifica grupo en la pantalla de logon (TSO, CICS, etc.), el grupo de conexin resulta ser su grupo default. Por lo tanto, es muy frecuente que el campo LAST-CONNECT solo est actualizado para el grupo default del usuario (tal como sucede con el campo CONNECTS). Si el usuario nunca inici una sesin con determinado grupo, el LAST-CONNECT para este grupo muestra el valor UNKNOWN. El campo LAST-CONNECT suele ser un indicador ms fiable respecto del da y hora del ltimo ingreso del usuario al sistema ya que, a diferencia del campo LAST-ACCESS, no se actualiza si se le da al usuario un RESUME o una nueva password (pero si es actualizado cuando se inicia un job bajo su identidad). De todos modos, es frecuente que los valores de los campos LASTACCESS y LAST-CONNECT para el grupo default coincidan. CONNECT-ATTRIBUTES muestra los atributos del usuario relativos a su conexin al grupo. Los usuarios se dividen en atributos a nivel de sistema, que figuran en el campo ATTRIBUTES, y atributos a nivel de grupo. Ms adelante los analizaremos en detalle. REVOKE DATE y RESUME DATE funcionan, a nivel de grupo, de modo similar a como lo hacen a nivel global. Sin embargo, a nivel grupal, se establecen a travs del comando CONNECT, que veremos cundo analicemos las conexiones de usuarios a grupos. SECURITY-LEVEL, CATEGORY-AUTHORIZATION y SECURITY-LABEL son campos relacionados con un nivel extra de seguridad que provee RACF, realmente poco utilizado. Bsicamente, fue implementado por IBM para que RACF cumpla con los requisitos que establece el gobierno de los EEUU para obtener la calificacin B1 en materia de seguridad. Si la organizacin no usa esta seguridad adicional, los 3 campos deben mostrar NONE SPECIFIED para todos los usuarios de la base de RACF. Autoridad requerida Todo usuario puede listar el segmento base de su propio perfil. Para listar el segmento base del perfil de otro, debe cumplir con alguna de las condiciones siguientes: Ser el owner del usuario. Tener el atributo SPECIAL a nivel de sistema. Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de accin al usuario a listar. Tener el atributo AUDITOR a nivel de sistema. Tener el atributo AUDITOR a nivel de un grupo que tenga dentro de su campo de accin al usuario a listar. Tener acceso READ sobre el recurso IRR.LISTUSER de la clase FACILITY (ver 7.5).

Apuntes de RACF

Juan Mautalen

26 Para poder listar segmentos no base, debe satisfacer alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema. Tener autoridad a travs de perfiles apropiados en la clase FIELDS. 3.12 - Comando PASSWORD Sintaxis: PASSWORD|PW [USER(userid)] [PASSWORD(clave-actual clave-nueva)] [INTERVAL(valor)|NOINTERVAL] El comando PASSWORD permite a un usuario cambiar su clave, as como tambin su INTERVAL. USER indica el usuario cuya password se va a modificar. Si se codifica USER y no se establece la opcin INTERVAL|NOINTERVAL, la password del usuario es reseteada al valor de su grupo default y queda expirada (el usuario deber forzosamente cambiarla en el momento de logon). Si, por el contrario, se codifica USER junto con alguna de las opciones INTERVAL|NOINTERVAL, la password del usuario no se altera, siendo modificado nicamente su intervalo de validez. El operando PASSWORD es ignorado si se ha especificado USER. El operando PASSWORD permite cambiar la clave propia en cualquier momento. Para ello, no debe especificarse el operando USER. Resulta conveniente ingresar PASSWORD sin especificar los valores de las passwords, ya que en tal caso RACF promptea al usuario para que los introduzca por pantalla y no resultan visibles mientras se los tipea. INTERVAL establece el valor del campo PASS-INTERVAL del usuario especificado en el operando USER (si ste se omitiera, el cambio afecta al usuario que ejecuta el comando). El valor debe estar comprendido entre 1 y 254, no pudiendo exceder el mximo global fijado en la SETROPTS. Si se codifica INTERVAL sin especificar valor, se toma por defecto el mximo global de la SETROPTS. NOINTERVAL establece que la clave del usuario nunca vence, en cuyo caso el campo PASSINTERVAL muestra el valor N/A. Tal cual indicramos anteriormente, debe usarse esta opcin solo en contados casos que lo justifiquen. El comando PASSWORD es realmente poco usado, ya que lo habitual es que los usuarios cambien su password a travs de la pantalla de logon de las aplicaciones (TSO, CICS, etc.), y no se preocupen en modificar su INTERVAL. Es imprescindible, sin embargo, para otorgar a un usuario una password que nunca venza. Autoridad requerida Todo usuario est autorizado a modificar su propia password y el intervalo de validez de la misma (no puede, sin embargo, usar la opcin NOINTERVAL, salvo que tenga la autoridad suficiente). Para resetear la password de otro usuario al valor de su grupo default, quien ejecuta el comando debe cumplir con alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema. Tener el atributo SPECIAL a nivel de un grupo que tenga al usuario dentro de su campo de accin. Ser el owner del usuario. Para cambiar el intervalo de validez de la password de otro usuario, o especificar NOINTERVAL, quien ejecuta el comando debe cumplir con alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema. Tener el atributo SPECIAL a nivel de un grupo que tenga al usuario dentro de su campo de accin.

Apuntes de RACF

Juan Mautalen

27 3.13 - Atributos de usuario Los atributos son facultades extraordinarias, o restricciones, que se le pueden otorgan a un usuario. Como ya mencionramos anteriormente, se pueden dar tanto a nivel de sistema (system level attributes), en cuyo caso de denominan simplemente atributos del usuario, como a nivel de la conexin del usuario con un grupo, en cuyo caso se llaman atributos relativos a grupos. Cuando son especificados a nivel de sistema, actan en todo momento. En cambio, cuando se otorgan a nivel de grupo, dependiendo del atributo, o actan de manera ms acotada, o bien solo lo hacen cuando el usuario ingres especificando ese grupo en la pantalla de logon. En un principio, analizaremos los atributos a nivel de sistema. Luego indicaremos de que manera actan cuando se los especifica a nivel de grupo. Atributos a nivel de sistema Los atributos que se pueden otorgar a nivel de sistema son los siguientes:
o o o o o o o o o o

SPECIAL AUDITOR OPERATIONS CLAUTH REVOKE GRPACC ADSP RESTRICTED PROTECTED UAUDIT

En general, se otorgan, ya sea en el momento de la creacin del usuario (comando ADDUSER), o bien con posterioridad (comando ALTUSER), especificando como parmetro no posicional el nombre del atributo (con excepcin de CLAUTH, que debe ir acompaado del nombre de una clase, y de PROTECTED). Los atributos REVOKE y UAUDIT solo pueden otorgarse con el comando ALTUSER, es decir con posterioridad a la creacin del usuario. Para quitarlos, debe ejecutarse el comando ALU, poniendo como parmetro el nombre del atributo antecedido por el prefijo NO, con las siguientes excepciones: - El atributo REVOKE se quita especificando el operando RESUME. - El atributo PROTECTED se quita otorgando una password al usuario. Ejemplos: 1) ALTUSER jefa524 AUDITOR Este comando le da al usuario JEFA524 el atributo AUDITOR a nivel de sistema. 2) ALTUSER jefa524 SPECIAL NOOPERATIONS Este comando le otorga al usuario JEFA524 el atributo SPECIAL a nivel de sistema, y le saca el atributo OPERATIONS a nivel de sistema, si lo tuviera. 3) ALTUSER jefa524 CLAUTH(tsoproc) RESUME Este comando le otorga al usuario JEFA524 el atributo CLAUTH en la clase TSOPROC a nivel de sistema, y le saca el atributo REVOKE (si lo tuviera a nivel de sistema). Atributo SPECIAL El atributo SPECIAL a nivel de sistema confiere al usuario la autoridad para ejecutar cualquier comando de RACF. Por lo tanto, el atributo SPECIAL otorga un absoluto control sobre la base de
Apuntes de RACF Juan Mautalen

28 RACF, pudiendo los usuarios que lo tienen, definir, modificar y deletear cualquier perfil, as como tambin modificar las opciones de configuracin de RACF establecidas en la SETROPTS, con la siguiente importante excepcin: El atributo SPECIAL no permite listar ni modificar opciones relativas a auditora (que quedan, por lo tanto, reservadas a los usuarios con atributo AUDITOR). Ms especficamente, un usuario con atributo SPECIAL (y sin atributo AUDITOR) no podr listar ni modificar:
o

o o

Parmetros SAUDIT, CMDVIOL, OPERAUDIT, AUDIT CLASSES, LOGOPTIONS, SECLABELAUDIT, SECLEVELAUDIT, APPLAUDIT de la SETROPTS. Atributo UAUDIT en perfiles de usuario. Campo GLOBALAUDIT en perfiles de dataset o de recursos generales.

Solo un usuario con atributo SPECIAL a nivel de sistema puede dar o quitar este atributo a otro usuario. En una base de RACF recin inicializada, el usuario IBMUSER, provisto por IBM, tiene el atributo SPECIAL. Ingresando con este usuario, debe otorgarse el atributo SPECIAL a los administradores de RACF de la organizacin. A continuacin, luego de verificar que los nuevos administradores pueden trabajar normalmente, resulta muy recomendable, desde el punto de vista de seguridad, quitarle al usuario IBMUSER el atributo SPECIAL y darle los atributos REVOKE, RESTRICTED y PROTECTED (no es posible eliminarlo). En efecto, como el usuario IBMUSER existe en toda base de RACF, es un blanco ideal de hackeo, razn por la cual mantenerlo inutilizable es lo ms aconsejable. El atributo SPECIAL no brinda acceso alguno a los recursos del sistema protegidos por RACF (con 2 excepciones particulares, que son el acceso a datasets no catalogados y datasets no protegidos). Sin embargo, el usuario con atributo SPECIAL tiene la posibilidad de otorgarse a s mismo el acceso a cualquier perfil de la base con el mximo nivel de autoridad. Por lo tanto, indirectamente, tiene acceso irrestricto a los recursos protegidos del sistema. Debido al enorme poder que confiere el atributo SPECIAL a nivel de sistema, solo un muy reducido conjunto de usuarios -encargados de la administracin centralizada de RACF- deben tenerlo. No es sencillo recomendar una cantidad ptima, ya que ello depende de la complejidad de la base (la cantidad total de usuarios es solo uno de los aspectos a considerar) y de la organizacin. Sin embargo, podemos sealar que, siempre que ello no comprometa la eficiencia de la administracin, cuantos menos usuarios con atributo SPECIAL existan, mejor. Normalmente, deberan sobrar los dedos de las manos para contar la cantidad de usuarios con atributo SPECIAL a nivel de sistema. Es por cierto recomendable, para su uso en una situacin de emergencia, conservar bajo sobre y en lugar seguro un usuario con este atributo. Atributo AUDITOR Los usuarios con atributo AUDITOR pueden listar la informacin completa de cualquier perfil de la base de RACF y de la SETROPTS (incluidas aquellas opciones que no se le muestran a un usuario con atributo SPECIAL), as como tambin utilizar el comando SEARCH de bsqueda y el utilitario IRRUT100 (permite buscar y listar las ocurrencias de un usuario o grupo en la base de RACF). Pueden, asimismo, modificar las opciones de logging para usuarios, perfiles de dataset, perfiles de recursos generales y las opciones de auditora globales establecidas en la SETROPTS. Fuera de las opciones relativas a auditora, el atributo AUDITOR no confiere autoridad para modificar ningn dato en la base de RACF. Tampoco otorga acceso a ningn recurso protegido. El utilitario DSMON brinda importante informacin para auditar el sistema. Slo los usuarios con atributo AUDITOR pueden utilizarlo (salvo que el programa ICHDSM00, invocado por la herramienta, se encuentre protegido en la clase PROGRAM, en cuyo caso es necesario tener acceso al mismo). El atributo AUDITOR debe ser otorgado criteriosamente, y nicamente a los usuarios que desempeen tareas globales de auditora. Resulta aconsejable que los usuarios con atributo SPECIAL no tengan el atributo AUDITOR, de modo de no concentrar excesivo poder en una nica persona.

Apuntes de RACF

Juan Mautalen

29 El atributo AUDITOR a nivel de sistema solo puede ser otorgado o quitado por un usuario con atributo SPECIAL a nivel de sistema. Por lo tanto, con respecto a la observacin anterior, si se pretende una buena separacin de funciones en la organizacin, debe controlarse que los usuarios administradores de RACF que tienen el atributo SPECIAL no se otorguen a s mismos el atributo AUDITOR. Para ello, basta con analizar el logging de los comandos de RACF ejecutados, que se obtiene de los registros tipo 80 del SMF. Atributo OPERATIONS Este atributo, a diferencia de los anteriores, otorga al usuario acceso a gran cantidad de recursos protegidos por RACF. En efecto, un usuario con atributo OPERATIONS a nivel de sistema tiene acceso ALTER -el mximo posible- a todos los perfiles en las clases DATASET, DASDVOL, GDASDVOL, TAPEVOL, PSFMPL, VMBATCH, VMCMD, VMMDISK, VMNODE, VMRDR (las ltimas cinco totalmente irrelevantes para z/OS, ya que se relacionan con VM), con las siguientes importantes salvedades: 1) Si el usuario figura explcitamente en la lista de acceso del perfil con un nivel de autoridad menor, entonces se ser su nivel de acceso. En efecto, a la hora de determinar el nivel de acceso de un usuario sobre un perfil, la presencia del identificador del usuario en la lista de acceso es mandatoria y toma preeminencia por sobre los eventuales grupos a los que est conectado o el nivel de autoridad implcito dado por el atributo OPERATIONS. En un captulo posterior analizaremos en detalle el proceso de chequeo de autoridad de un usuario sobre un recurso que lleva a cabo RACF. 2) Si el usuario no est en la lista de acceso del perfil, pero figuran en la misma uno o ms grupos a los cuales se encuentra conectado (asumimos que la instalacin tiene la opcin List of Groups Checking Active en la SETROPTS, lo cual es la configuracin habitual hoy en da), entonces su nivel de autoridad ser el ms permisivo dado por sus grupos. Ejemplo: Supongamos que el usuario FIN5214 tiene el atributo OPERATIONS a nivel de sistema, que est conectado nicamente a los grupos FINANZAS y CONTA, y que existe en la base un perfil de dataset CUIL.** con la siguiente lista de acceso
FINANZAS CONTA COBROS UPDATE READ ALTER

En este caso, el nivel de autoridad del usuario FIN5214 sobre el perfil CUIL.** ser UPDATE, es decir el ms permisivo dado por sus grupos (ya que no figura explcitamente FIN5214 en la lista de acceso). El atributo OPERATIONS no entra en juego ya que existen en la lista de acceso del perfil grupos a los cuales el usuario est conectado. 3) Security levels, categories y security labels tambin pueden limitar el acceso implcito a un perfil dado por el atributo OPERATIONS. Sin embargo, ya mencionamos que son opciones poco utilizadas que no analizaremos. En virtud de las salvedades expuestas concluimos que, para un usuario con el atributo OPERATIONS, la presencia de su identificador de usuario o de alguno de sus grupos en la lista de acceso de un perfil (de una clase dnde acte el atributo OPERATIONS) solo sirve para eventualmente reducir su nivel de autoridad. El atributo OPERATIONS a nivel de sistema solo puede ser otorgado o quitado por un usuario con atributo SPECIAL a nivel de sistema. Se trata de un atributo que brinda gran poder de acceso, razn por la cual debe ser otorgado con suma cautela, y en contadsimos casos. Ms an, es perfectamente posible (e incluso recomendable) no tener usuarios con atributo OPERATIONS a nivel de sistema. Por ejemplo, para los usuarios de administracin de storage, existen mecanismos alternativos al atributo OPERATIONS para brindarles acceso a los recursos que requieren sus funciones. En cualquier caso,
Apuntes de RACF Juan Mautalen

30 otorgar el atributo OPERATIONS no suele ser ms que una solucin fcil (que se paga a expensas de la seguridad) para evitar identificar exactamente los recursos a los que precisa acceder el usuario. Atributo CLAUTH Este atributo, que significa Class Authority, se otorga para una (o varias) clases de RACF, y solo es aplicable a nivel de sistema. Las clases para las cules es vlido son la clase USER o cualquier otra clase definida en la CDT (GROUP y DATASET quedan pues excluidas). Bsicamente, poseer el atributo CLAUTH para una determinada clase autoriza al usuario a definir nuevos perfiles en ella (y el cualquier otra con idntico POSIT number), teniendo en cuenta las siguientes salvedades: 1) La opcin GENERICOWNER de la SETROPTS, que veremos en el captulo correspondiente, puede limitar la posibilidad de crear perfiles en una clase dada por el atributo CLAUTH. 2) Tener nicamente CLAUTH en la clase USER no autoriza a dar de alta un nuevo usuario en la base de RACF. Adicionalmente, se debe ser el owner del grupo default del usuario a definir, o bien estar conectado al mismo con nivel de autoridad JOIN. El atributo CLAUTH sobre una clase brinda una bastante limitada capacidad de administracin sobre sus perfiles. En efecto, si bien permite definir nuevos perfiles, no permite modificar, borrar, o listar perfiles ya existentes (siempre y cuando estas acciones no estn posibilitadas por algn otro tipo de autoridad). Si el usuario con el atributo CLAUTH define un nuevo perfil sin especificar owner, queda por defecto como dueo del perfil y por lo tanto con poder de administracin casi total sobre el mismo. En cambio, si especifica un owner distinto de su usuario, ya no podr actuar sobre l una vez creado. CLAUTH resulta, de todos modos, til como herramienta de descentralizacin de ciertas tareas de administracin de RACF, y es bastante utilizado en muchas organizaciones. Para estar autorizado a otorgarlo sobre una determinada clase, debe cumplirse alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema. Tener CLAUTH sobre esa clase, y adems estar autorizado a modificar el perfil del usuario (por ejemplo, siendo su owner). Atributo REVOKE El atributo REVOKE a nivel de sistema impide al usuario el logon a cualquier aplicacin (TSO, CICS, IMS, etc.), as como tambin la ejecucin de trabajos batch. nicamente las Started Task pueden arrancar con un usuario revocado, aunque es posible que experimenten inconvenientes posteriores, dependiendo de lo que hagan. El atributo REVOKE, a diferencia de los anteriores, no solo puede ser otorgado por un usuario con la suficiente autoridad (atributo SPECIAL u owner del usuario), sino que tambin puede ser dado automticamente por RACF en alguna de las siguientes situaciones: 1) Si en la SETROPTS est especificado que el usuario ser revocado despus de N intentos consecutivos y fallidos de password, entonces al (N+1) intento consecutivo de password invlida el usuario es revocado. Naturalmente, un ingreso vlido vuelve la cuenta a 0. 2) Si en la SETROPTS est especificado que el usuario ser automticamente revocado despus de N das de inactividad, y transcurrieron al menos (N+1) das desde su ltimo ingreso al sistema, el usuario ser revocado por RACF en el momento del intento de logon. Cabe aclarar que, aunque se haya excedido el tiempo de inactividad estipulado, hasta tanto el usuario no intente loguearse al sistema no adquirir el atributo REVOKE, ya que RACF lo otorga al procesar la solicitud de logon. Con respecto a las situaciones recin descriptas, merecen una consideracin particular los usuarios con atributo SPECIAL a nivel de sistema. En efecto, RACF no los revoca automticamente, sino que emite un mensaje por consola solicitando al operador, o bien que confirme la revocacin, o bien que otorgue
Apuntes de RACF Juan Mautalen

31 un intento adicional de ingreso de password u omita la inactividad, segn sea el caso. Sin este tratamiento diferenciado, sera perfectamente posible que una persona revocara intencionalmente (mediante ingresos consecutivos de passwords incorrectas) a todos los usuarios con atributo SPECIAL de la organizacin, generando una situacin delicada de la cual no es sencillo recuperarse. Atributo GRPACC El atributo GRPACC (Group Access) a nivel de sistema funciona del siguiente modo: Si un usuario con GRPACC se encuentra conectado a un grupo A y define un perfil de dataset cuyo HLQ es A (suponiendo que tenga autoridad suficiente para hacerlo), automticamente se agregar en la lista de acceso al grupo A con autoridad UPDATE. Se trata de un atributo poco utilizado, y para otorgarlo o quitarlo es necesario tener el atributo SPECIAL, o bien ser el owner del perfil del usuario. Atributo ADSP ADSP significa Automatic Data Set Protection. Si un usuario tiene este atributo a nivel de sistema, cada vez que cree un dataset permanente en disco (o en cartucho, si la clase TAPEVOL est activa y la opcin TAPEDSN est especificada en la SETROPTS), RACF automticamente le definir un perfil discreto de dataset. Siendo la tendencia actual la de utilizar solo perfiles de dataset genricos, pues son ms sencillos de administrar y presentan varias ventajas sobre los discretos, el atributo ADSP ha cado francamente en desuso. Existe la opcin NOADSP a nivel de la SETROPTS que inhibe el eventual atributo ADSP que puedan tener los usuarios. Para otorgar o quitar el atributo ADSP es necesario, o bien tener el atributo SPECIAL, o bien ser el owner del perfil del usuario. Para setear ADSP|NOADSP a nivel de la SETROPTS es necesario tener el atributo SPECIAL a nivel de sistema. Atributo RESTRICTED Este atributo es solo aplicable a nivel de sistema. Se trata de un atributo de carcter limitativo, que restringe casi completamente los recursos a los cules puede acceder el usuario. En efecto, un usuario con el atributo RESTRICTED no puede obtener acceso a un recurso protegido por RACF ni por una regla en la clase GLOBAL, ni por el UACC del perfil protector, ni por la presencia de * en las listas de acceso. Dicho de otro modo, un usuario con atributo RESTRICTED solo puede acceder a aquellos recursos para los cuales se encuentre explcitamente autorizado, ya sea porque su identificador de usuario, o alguno de los grupos a los que est conectado, figura en las listas de acceso del perfil con el nivel de autoridad requerido. El atributo RESTRICTED es til en situaciones dnde se requiere tener un absoluto control de los recursos a los que debe acceder el usuario. Antes de otorgarlo, es vital realizar un detallado relevamiento de todos los recursos a los que necesita acceder y con qu nivel de autoridad, de modo de no provocar una interrupcin en las tareas operativas. Para otorgar o quitar el atributo RESTRICTED a un usuario, es necesario, o bien tener el atributo SPECIAL, o bien ser el owner de su perfil. Atributo PROTECTED Un usuario con atributo PROTECTED (protegido) no puede loguearse a ninguna aplicacin del sistema que requiera el uso de una password. Por ejemplo, no puede iniciar sesiones de TSO, CICS, NETVIEW, etc. Si alguien intenta loguearse con un usuario que tenga el atributo PROTECTED, RACF directamente rechaza el pedido de logon sin considerarlo ni siquiera un intento fallido por password invlida. Se trata de usuarios sin password que resultan inmunes a la revocacin automtica por ingresos consecutivos de passwords errneas. Sin embargo, s estn sujetos a la eventual revocacin automtica por inactividad.

Apuntes de RACF

Juan Mautalen

32 Bsicamente, se trata de un atributo muy til para aquellos usuarios asociados con started tasks que no necesiten loguearse a ninguna aplicacin. Para estos usuarios, el atributo PROTECTED asegura no solo que no se puedan utilizar para ingresar a ninguna aplicacin, sino que tambin elimina la posibilidad de que se los revoque (voluntaria o involuntariamente) por ingresos consecutivos de passwords invlidas. Los usuarios de las regiones CICS, por ejemplo, son excelentes candidatos para este atributo. Se otorga a un usuario el atributo PROTECTED, ya sea en el momento de su creacin (comando ADDUSER) o con posterioridad (comando ALTUSER), especificando el operando NOPASSWORD. Ejemplo: ALTUSER userid NOPASSWORD Cuando un usuario tiene este atributo, los campos PASSDATE y PASS-INTERVAL de la salida del comando LISTUSER muestran el valor N/A. Para quitar el atributo PROTECTED, basta con darle al usuario una password, ejecutando el comando: ALTUSER userid PASSWORD(password) Para otorgar el atributo PROTECTED, se debe cumplir alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema. Tener el atributo SPECIAL a nivel de un grupo que tenga al usuario dentro de su campo de accin. Ser el owner del usuario. Atributo UAUDIT El atributo UAUDIT (User Audit) indica que RACF grabe registros tipo 80 del SMF toda vez que el usuario efecte alguna de las siguientes acciones: Ejecute un comando de RACF (con excepcin de los comandos LISTUSER, LISTGROUP, LISTDSD, RLIST y SEARCH, que nunca se registran dada su baja criticidad). Intente acceder a un recurso protegido, resulte el acceso fallido o exitoso (independientemente de la configuracin de auditora que tenga el perfil protector del recurso), excepto en el caso en que el acceso haya sido autorizado por una regla en la clase GLOBAL. Defina algn nuevo recurso cuya creacin est controlada por RACF (la alocacin de un nuevo dataset, por ejemplo). Para poder otorgar o quitar el atributo UAUDIT, se debe tener el atributo AUDITOR a nivel de sistema, o bien a nivel de un grupo que tenga al usuario dentro de su campo de accin. El atributo SPECIAL, incluso a nivel de sistema, no permite listar -y mucho menos dar o quitar- este atributo. No se debe abusar del atributo UAUDIT ya que puede provocar un aumento muy considerable de la cantidad de registros SMF grabados por RACF, con los consiguientes problemas de tipo operativo que ello acarrea. Es conveniente otorgarlo solo cuando se requiera un monitoreo estricto de la actividad de un determinado usuario, y por un perodo limitado de tiempo. Atributos a nivel de grupo Los atributos que se pueden otorgar a nivel de grupo son los siguientes:
o o o o o o

SPECIAL AUDITOR OPERATIONS REVOKE GRPACC ADSP

Juan Mautalen

Apuntes de RACF

33 Se otorgan a travs de comando CONNECT, que se ver en detalle ms adelante. Ejemplos: 1) CO fina857 GROUP(finanzas) AUDITOR Este comando conecta al usuario FINA857 al grupo FINANZAS con atributo AUDITOR a nivel de grupo. Si el usuario FINA857 ya se encontrara conectado al grupo FINANZAS, solo modifica la conexin agregando el atributo AUDITOR. 2) CO fina857 GROUP(finanzas) SPECIAL RESUME La presencia del parmetro RESUME hace presuponer que el usuario FINA857 ya se encuentra conectado al grupo FINANZAS (si no fuese el caso, sera irrelevante). En tal caso, el comando modifica la conexin, eliminando el atributo REVOKE a nivel de grupo (si lo tuviere) y otorgando al usuario FINA857 el atributo SPECIAL a nivel del grupo FINANZAS. Para comprender cmo funcionan los atributos a nivel de grupo, es fundamental explicar el concepto de campo de accin de un grupo (scope of the group), el cual ya ha sido mencionado repetidas veces pero an no explicado. Campo de accin de un grupo El campo de accin de un grupo est compuesto por una serie de grupos, perfiles de usuario, perfiles de dataset y perfiles de recursos generales, de acuerdo al siguiente criterio: Aparte del grupo en cuestin, se encuentran dentro de su campo de accin todos sus subgrupos, los subgrupos de sus subgrupos, y as sucesivamente, siempre y cundo se cumpla que el owner de un grupo sea su grupo superior. Si el owner de un grupo dentro de la rama del inicial es un usuario (en lugar de su grupo superior), este grupo (y todos los que se desprendan de l en el rbol) queda fuera del campo de accin. Es decir, si se cumple que cada grupo tenga como owner su grupo superior, los grupos dentro del campo de accin de un grupo son exactamente todos aquellos que pertenecen a su rama en el rbol de grupos. Ejemplo:
GRUPO1 Owner: GRUPOA

GRUPO2 Owner: GRUPO1

GRUPO3 Owner: GRUPO1

GRUPO4 Owner: GRUPO2

GRUPO5 Owner: GRUPO3

GRUPO6 Owner: USU1

En el diagrama anterior, la flecha significa tiene como subgrupo a. Por lo tanto, se tiene que: o GRUPO1 tiene 2 subgrupos: GRUPO2 y GRUPO3. o GRUPO2 tiene un nico subgrupo: GRUPO4. o GRUPO3 tiene 2 subgrupos: GRUPO5 y GRUPO6. o GRUPO4, GRUPO5 y GRUPO6 no tienen subgrupos. Los grupos que forman parte del campo de accin del GRUPO1 son: GRUPO1, GRUPO2, GRUPO3, GRUPO4 y GRUPO5.
Apuntes de RACF Juan Mautalen

34 GRUPO6 no forma parte del campo de accin de GRUPO1 ya que el owner no es su grupo superior, sino el usuario USU1. Los usuarios dentro del campo de accin de un grupo son todos aquellos cuyo owner es un grupo que se encuentre a su vez dentro del campo de accin. No estn dentro del campo de accin aquellos usuarios cuyo owner sea otro usuario. La eventual pertenencia de un usuario a un grupo dentro del campo de accin no implica que el usuario se encuentre dentro del campo de accin. En otras palabras, el factor determinante para establecer si determinado usuario est o no dentro del campo de accin de un grupo es su owner y no sus conexiones. En cuanto a perfiles de dataset, se encuentran dentro del campo de accin del grupo aquellos que cumplen con alguna de las siguientes condiciones: Su owner es un grupo que est dentro del campo de accin. Su owner es un usuario dentro del campo de accin. Su HLQ es un usuario o grupo dentro del campo de accin. En lo referido a perfiles de recursos generales, se encuentran dentro del campo de accin del grupo aquellos que cumplen con alguna de las siguientes condiciones: Su owner es un grupo que est dentro del campo de accin. Su owner es un usuario dentro del campo de accin. Por ejemplo, volviendo al caso del diagrama, perfiles de recursos generales cuyo owner es GRUPO5 estn dentro del campo de accin de GRUPO1, mientras que aquellos cuyo owner es GRUPO6 no lo estn. Asimismo, si USU2 es un usuario cuyo owner es GRUPO2 y USU22 es un usuario cuyo owner es USU2, entonces USU2 est dentro del campo de accin de GRUPO1, mientras que USU22 no. En consecuencia, todo perfil de recursos generales cuyo owner sea USU2 est dentro del campo de accin de GRUPO1, mientras que aquellos cuyo owner sea USU22 estn afuera. Atributo SPECIAL a nivel de grupo Bsicamente, un usuario con atributo SPECIAL a nivel de un grupo tiene total autoridad para administrar los recursos que estn dentro de su campo de accin. Se trata pues de un usuario SPECIAL pero cuya injerencia se ve restringida al campo de accin del grupo al cual se encuentra conectado con el atributo SPECIAL. En cuanto a la definicin de nuevos perfiles, se tiene que: o Puede definir nuevos perfiles de dataset cuyo HLQ sea un grupo o un usuario dentro de su campo de accin. o Para crear nuevos perfiles de recursos generales debe tener CLAUTH sobre la clase correspondiente. o Para crear nuevos usuarios debe tener CLAUTH en la clase USER. Limitaciones: o Un usuario con atributo SPECIAL a nivel de grupo no puede modificar opciones que afecten globalmente al sistema. Por lo tanto, no tiene autoridad suficiente para modificar la configuracin global de RACF establecida en la SETROPTS. o No puede otorgar los atributos SPECIAL, AUDITOR ni OPERATIONS a "nivel de sistema" (aunque si puede otorgarlos a nivel de grupo, para grupos que se encuentren dentro del campo de accin). Para otorgar CLAUTH sobre una clase debe tener l mismo CLAUTH sobre esa misma clase. o An dentro del campo de accin del grupo, se enfrenta con restricciones similares con respecto a las opciones de auditora a las que tiene un usuario con atributo SPECIAL a "nivel de sistema".

Apuntes de RACF

Juan Mautalen

35 Atributo AUDITOR a nivel de grupo Un usuario con atributo AUDITOR a nivel de grupo tiene las mismas autoridades que uno con atributo AUDITOR a nivel de sistema, pero restringida a los recursos (grupos, usuarios, perfiles de dataset y de recursos generales) que se encuentran dentro de su campo de accin. No est habilitado a modificar opciones globales de auditora, aunque si est autorizado a listar la informacin completa de la SETROPTS. Atributo OPERATIONS a nivel de grupo Un usuario con atributo OPERATIONS a nivel de grupo tiene las mismas autoridades que uno con atributo OPERATIONS a nivel de sistema, pero restringida a los recursos (perfiles de dataset y de recursos generales) que estn dentro de su campo de accin. Atributo REVOKE a nivel de grupo Un usuario con atributo REVOKE a nivel de un determinado grupo no puede acceder al sistema especificando ese grupo como "grupo de conexin" ni puede obtener acceso a un recurso protegido como miembro del grupo. En definitiva, estar conectado a un grupo con la conexin revocada es similar, desde el punto de vista de seguridad, a no pertenecer al mismo. Con respecto al uso del REVOKE con fecha, ya se analiz previamente cmo funciona a "nivel de usuario", siendo el comportamiento a nivel de grupo anlogo. Atributo GRPACC a nivel de grupo Slo acta si el grupo en cuestin es el actual grupo de conexin del usuario. Su funcionamiento es entonces igual al del atributo GRPACC a nivel de sistema (afectar a todos los perfiles de dataset de grupo que defina el usuario, siempre y cuando est conectado al grupo dado por el HLQ, an cuando ste no se encuentre dentro del campo de accin del grupo sobre el que tiene efectivamente el atributo GRPACC). Atributo ADSP a nivel de grupo Slo acta si el grupo en cuestin es el actual grupo de conexin del usuario. En tal caso, funciona igual que el atributo ADSP a nivel de sistema. Se trata, como ya hemos observado, de un atributo muy poco utilizado. 3.14 - Conexin de un usuario a un grupo Un usuario queda conectado automticamente a su grupo default al ser dado de alta. Para conectarlo a otro grupo, o bien para modificar caractersticas de una conexin ya existente, debe usarse el comando CONNECT, en tanto que para desconectarlo debe emplearse el comando REMOVE. A continuacin, analizaremos en detalle ambos comandos. Comando CONNECT Sintaxis: CONNECT|CO userid [GROUP(nombre)] [OWNER(usuario/grupo)] [AUTHORITY(nivel)] [REVOKE(mm/dd/aa)] [RESUME(mm/dd/aa)] [ADSP|NOADSP] [AUDITOR|NOAUDITOR] [GRPACC|NOGRPACC] [OPERATIONS|NOOPERATIONS] [SPECIAL|NOSPECIAL] UACC(nivel) Como ya sealamos, este comando tambin se utiliza para modificar algn parmetro de una conexin ya existente (no existe un comando exclusivo de modificacin de conexin). Si la conexin ya existe, el comando solo modifica los parmetros especificados (no se aplica ningn valor por defecto). El userid es requerido y debe estar inmediatamente a continuacin del comando CONNECT.

Apuntes de RACF

Juan Mautalen

36 Si no se codifica GROUP, el comando conecta por defecto al usuario al actual grupo de conexin de quin ejecuta el comando (que suele ser su grupo default). Debe tenerse cuidado con esto, ya que muchas veces no es el efecto buscado, sino que simplemente se omite el grupo por distraccin. El OWNER de la conexin es totalmente irrelevante. Su valor por defecto es el identificador del usuario que ejecuta el comando CONNECT. AUTHORITY indica el nivel de autoridad del usuario como miembro del grupo, que analizaremos en detalle ms adelante en este mismo captulo. USE es el valor por defecto. Por defecto, no se le asigna al usuario ningn atributo a nivel del grupo. UACC asume por defecto el valor NONE. Autoridad requerida Para conectar un usuario a un grupo (o modificar parmetros de una conexin ya existente) a travs del comando CONNECT, el usuario que ejecuta el comando debe cumplir alguna de las condiciones siguientes: Tener el atributo SPECIAL a nivel de sistema. Tener el atributo SPECIAL a nivel de grupo, y el grupo al cual se pretende conectar al usuario encontrarse dentro de su campo de accin. Ser el owner del grupo. Estar conectado al grupo con nivel de autoridad CONNECT o JOIN. En caso de tener nivel de autoridad CONNECT, no puede conectar al usuario con nivel de autoridad JOIN (suponiendo que no detente otro tipo de atributo que se lo permita, como SPECIAL a nivel de sistema). Para otorgar o quitar los atributos SPECIAL, AUDITOR u OPERATIONS a nivel del grupo, el usuario que ejecuta el comando debe tener el atributo SPECIAL, ya sea a nivel de sistema, o a nivel de un grupo que tenga al grupo en cuestin dentro de su campo de accin. Comando REMOVE Sintaxis: REMOVE|RE userid [GROUP(nombre)] [OWNER(usuario/grupo)] Este comando desconecta un usuario de un grupo. No permite modificar parmetros de la conexin (esto debe hacerse con el comando CONNECT). El userid es requerido y debe estar inmediatamente a continuacin del comando REMOVE. GROUP indica el nombre del grupo del cual se desea desconectar al usuario. Si se omite, asume por defecto el nombre del actual grupo de conexin de quien ejecuta el comando REMOVE. Con respecto al operando OWNER, funciona del siguiente modo: supongamos que se pretende desconectar al usuario A del grupo B. Si A es owner de perfiles de dataset cuyo HLQ es B, RACF no permite la desconexin, salvo que se codifique el operando OWNER a travs del cual se especifica un usuario o grupo que se convertir en el nuevo owner de estos perfiles. Si se pone un usuario como OWNER, debe estar conectado al grupo. Si A no es owner de ningn perfil de dataset cuyo HLQ es B, entonces el operando OWNER es irrelevante y puede omitirse. Observacin: No se puede desconectar a un usuario de su grupo default. Por lo tanto, suponiendo que el usuario USUA est conectado nicamente al grupo GRPB (que por lo tanto es su grupo default) y que se

Apuntes de RACF

Juan Mautalen

37 pretende que USUA quede conectado nicamente comandos similar a la siguiente: 1. CONNECT USUA GROUP(GRPC) 2. ALTUSER USUA DFLTGRP(GRPC) 3. REMOVE USUA GROUP(GRPB) al grupo GRPC, debera ejecutarse una secuencia de conecta USUA a GRPC cambia el grupo default de USUA por GRPC desconecta USUA de GRPB

Ya se describi detalladamente en secciones anteriores el significado de los parmetros de la conexin (ver ejemplo del comando LISTUSER y parmetros a nivel de grupo). Slo restan por analizar los posibles niveles de autoridad de un usuario dentro de un grupo. Autoridad requerida Para desconectar un usuario de un grupo, el usuario que ejecuta el comando debe cumplir alguna de las condiciones siguientes: Tener el atributo SPECIAL a nivel de sistema. Tener el atributo SPECIAL a nivel de grupo, y el grupo del cual se pretende desconectar al usuario encontrarse dentro de su campo de accin. Ser el owner del grupo. Estar conectado al grupo con nivel de autoridad CONNECT o JOIN. Niveles de autoridad de un usuario en un grupo Los posibles niveles son: 1. 2. 3. 4. USE CREATE CONNECT JOIN

Se enumeraron de modo que cada nivel de autoridad incluye (y excede) los privilegios del anterior. Nivel USE Un usuario conectado a un grupo con nivel de autoridad USE est habilitado a:
o o

Ingresar al sistema especificando ese grupo como grupo de conexin. Acceder a recursos protegidos a los cules el grupo se encuentre autorizado.

Se trata del nivel de autoridad suficiente para la casi totalidad de los casos. Nivel CREATE Adicionalmente, el nivel de autoridad CREATE permite:
o o

Alocar nuevos datasets cuyo HLQ sea el grupo. Definir nuevos perfiles de dataset cuyo HLQ sea el grupo. Observemos que si queda el usuario como owner, puede posteriormente administrarlos.

Sin embargo, salvo que se encuentre autorizado por otro motivo, el nivel de autoridad CREATE no permite deletear datasets cuyo HLQ sea el grupo en cuestin. Nivel CONNECT Adicionalmente, el nivel de autoridad CONNECT permite:
o

Conectar al grupo usuarios ya existentes en la base de RACF, otorgndoles nivel de autoridad USE, CREATE o CONNECT.
Juan Mautalen

Apuntes de RACF

38 Modificar parmetros de la conexin al grupo de usuarios ya conectados. Desconectar usuarios del grupo con el comando REMOVE. Listar la informacin del grupo con el comando LISTGRP.

o o o

En el caso de ejecutar el comando CONNECT al grupo, puede especificar cualquier operando, con excepcin de SPECIAL|NOSPECIAL, AUDITOR|NOAUDITOR y OPERATIONS|NOOPERATIONS. Nivel JOIN Adicionalmente, el nivel de autoridad JOIN permite:
o

o o o

Si tiene el atributo CLAUTH(USER), definir nuevos usuarios dentro del grupo, con nivel de autoridad USE, CREATE, CONNECT o JOIN. Conectar al grupo usuarios ya existentes en la base de RACF, con nivel de autoridad JOIN. Crear nuevos grupos de RACF que sean subgrupos del grupo en cuestin. Borrar subgrupos del grupo con el comando DELGROUP.

Apuntes de RACF

Juan Mautalen

39 4 - PROTECCIN DE DATASETS 4.1 - Consideraciones generales Los datasets son, por excelencia, el tipo de recurso que permite proteger RACF. Ms an, en sus primeras versiones, que datan de la dcada del 70, los archivos eran los nicos recursos sobre los cules RACF controlaba el acceso. Con el correr del tiempo y la aparicin de nuevas versiones, tanto RACF como los distintos componentes del sistema operativo (y productos) fueron evolucionando, de modo que hoy en da RACF permite proteger una enorme variedad de recursos aparte de los datasets. Conceptualmente, es de suma importancia distinguir un dataset de un perfil de dataset. Un dataset es simplemente un archivo, cuya existencia es absolutamente independiente de RACF. Utilizaremos indistintamente los trminos dataset y archivo. Un perfil de dataset es una entidad que existe en la base de RACF y se crea, modifica y elimina a travs del uso de comandos de RACF. La clase de RACF que los agrupa es la clase DATASET. Ambos se vinculan del siguiente modo: los perfiles de dataset contienen informacin que emplea RACF para responder los requerimientos que reciba de acceso a archivos. Dicho ms sencillamente, los perfiles de dataset son una suerte de reglas que protegen el acceso a datasets. Datasets En el entorno z/OS, los archivos pueden residir en disco o en cartucho, y vienen identificados por un nombre cuya longitud mxima es de 44 caracteres. La cadena de caracteres que lo conforma se divide en calificadores, de longitud mnima 1 y mxima 8, separados entre s por un punto (.) (los puntos forman parte del nombre, o sea que cuentan con respecto al mximo de 44). El primer carcter de cada calificador debe ser alfabtico (A hasta Z) o nacional (#, @, $). Los restantes pueden ser alfabticos, numricos (0 a 9), nacionales o un guin (-). No se distinguen maysculas de minsculas. No existe un lmite para la cantidad de calificadores que pueda tener un dataset, ms all del que surge obviamente de la longitud mxima permitida en el nombre. El primer calificador se abrevia HLQ (High level Qualifier). Ejemplos: PROD1.FINANZAS.A2009 BASEPERS TEST1.2010 Perfiles de Dataset Los perfiles de dataset se dividen en 2 tipos: Discretos Genricos.

Nombre vlido, con 3 calificadores. PROD1 es el HLQ. Nombre vlido, de un nico calificador. Nombre invlido, pues el segundo calificador empieza con un nmero, lo que no est permitido.

Ms adelante analizaremos en detalle las diferencias entre unos y otros. Por el momento digamos que, en sus primeras versiones, los nicos perfiles de dataset que admita RACF eran los discretos, que protegen un nico archivo. Con posterioridad, surgieron los perfiles de dataset genricos, que resultaron ms prcticos y fciles de administrar. A diferencia de los discretos, dnde deba existir un perfil por cada dataset protegido, un nico perfil genrico permite proteger una cantidad ilimitada de archivos de nombres similares. La tendencia actual es a utilizar casi exclusivamente perfiles de dataset genricos, aunque para ciertas situaciones muy particulares los perfiles discretos continan siendo una mejor opcin.
Apuntes de RACF Juan Mautalen

40 Los perfiles de dataset siguen las mismas convenciones para sus nombres que los archivos, con las siguientes salvedades:
o o

Deben tener 2 o ms calificadores. El HLQ debe coincidir con un usuario o grupo existente en la base de RACF. Los denominaremos perfil de dataset de usuario o perfil de dataset de grupo, segn sea el caso. Con excepcin del HLQ, pueden utilizarse en los siguientes calificadores los caracteres comodn: %, *, **. El doble asterisco solo puede usarse si la opcin EGN (Enhanced Generic Naming) est activa en la SETROPTS. Estos 3 smbolos tambin se denominan caracteres genricos o variables.

En todo lo que sigue, vamos a asumir que la clase DATASET est seteada como GENERIC y GENCMD, y que la opcin EGN -que habilita el uso del ** en los perfiles de dataset- est activa, lo cual es lo habitual en todas las organizaciones. Estas opciones se establecen en la SETROPTS y se analizarn en detalle en el captulo correspondiente. Por otro lado, salvo que aclaremos lo contrario, supondremos que todos los archivos residen en disco (tambin llamados DASD, sigla de Direct Access Storage Device). 4.2 - Perfiles discretos Un perfil discreto de dataset debe tener idntico nombre que el archivo que pretende proteger. Por lo tanto, los caracteres %, * y ** no estn permitidos. Los perfiles discretos de dataset guardan una ntima relacin con el archivo que protegen. Por ejemplo, solo es posible definir un perfil discreto de dataset si realmente existe un archivo con ese nombre en el volumen indicado. Ms an, al proteger un archivo discretamente, ya sea en la VTOC del disco para los NOVSAM, o en la entrada del catlogo para los VSAM, un bit se activa indicando que el archivo est protegido por un perfil discreto. Se dice en tal caso que el archivo est RACF-indicado. Si se deletea un archivo protegido por un perfil discreto, automticamente se borra de la base de RACF el perfil de dataset correspondiente. 4.3 - Perfiles genricos Los perfiles genricos, ampliamente ms usados que los discretos, pueden o no tener en sus nombres los caracteres %, * y **. Cundo no tienen ningn carcter genrico, se los conoce como perfiles genricos completos y solo protegen al archivo de idntico nombre, si existiera (lo cual no es requisito para que se pueda definir el perfil, como en el caso de los discretos). Si, en cambio, tienen alguno de los caracteres comodn, entonces cubren una gran cantidad de eventuales datasets, en virtud del significado que posee cada uno de los caracteres genricos, que detallamos a continuacin. Como ya sealramos, suponemos la opcin EGN activa en la SETROPTS. En caso contrario, el ** no es vlido en perfiles de dataset y el * cambia ligeramente su significado. Signo porcentual (%) Variable que indica un nico carcter cualquiera en esa posicin (con excepcin del .) Ejemplo: TEST.FINAN.A200% Asterisco (*) Para esta variable, caben distintas posibilidades: Si forma parte de un calificador que contiene otros caracteres, debe ser el carcter final. En tal caso indica que en esa posicin puede haber 0 o ms caracteres hasta completar el calificador. Ejemplo: TEST.FIN*

Apuntes de RACF

Juan Mautalen

41 Si constituye un calificador completo, indica que en esa posicin puede existir cualquier calificador pero que debe necesariamente existir uno. Ejemplo: TEST.*.A2002 Doble asterisco (**) Esta variable debe usarse como un calificador entero, y no puede utilizarse ms de una vez por perfil. Indica la presencia de 0 o ms calificadores en esa posicin. Ejemplo: TEST.**.A2002 Recordemos que el HLQ de todo perfil de dataset debe ser un usuario o grupo definido en la base de RACF. Por lo tanto, no est permitido el uso de caracteres genricos en el primer calificador. 4.4 - Cmo determina RACF el perfil protector de un dataset Diremos que un perfil de dataset cubre a un determinado archivo si el nombre del archivo est alcanzado por el molde establecido por el perfil. Ejemplo: Perfiles: 1. TEST.FINANZAS.A2002 2. TEST.FINANZAS.A2002 3. TEST.FINANZAS.** 4. TEST.FINAN%%%.* 5. TEST.FINAN*.* 6. TEST.*.A* 7. TEST.FINANZAS.A% 8. TEST.*.A2002.*

discreto genrico completo

Los 6 primeros perfiles cubren al archivo TEST.FINANZAS.A2002, mientras que los nmeros 7 y 8 no lo hacen (el 7 solo contempla un nico carcter luego de la A del ltimo calificador, mientras que el * final en el 8 exige la existencia de un cuarto calificador). Por lo tanto, como muestra el ejemplo, muchos perfiles de dataset pueden cubrir al mismo archivo. Sin embargo, a la hora de determinar la proteccin, RACF se gua por el principio del perfil ms especfico. Esto significa que, dado un archivo, o bien RACF no lo encuentra protegido, o bien determina un nico perfil que lo protege (que puede resultar discreto o genrico), que llamamos perfil protector. Para determinar el perfil protector, RACF procede del siguiente modo: Si existe un perfil discreto para el archivo, entonces ste ser su perfil protector. Si no existe un perfil discreto, RACF busca todos los perfiles genricos que lo cubren (si no existiera ninguno, simplemente el archivo no estara protegido), y procede a compararlos, de izquierda a derecha. En el primer carcter en que encuentre alguna diferencia, se descartan aquellos ms genricos, de acuerdo al siguiente criterio: - Los caracteres no genricos son ms especficos que las variables. - Para las variables, el orden, desde el menos al ms genrico, es %, * y **. Siguiendo este procedimiento, RACF siempre determina, a lo sumo, un nico perfil protector para un dataset. Si volvemos al ejemplo anterior, notamos que los perfiles del 1 al 6 estn ordenados del ms al menos especfico. En este caso, el perfil discreto acta como perfil protector del archivo TEST.FINANZAS.A2002 Un perfil discreto se distingue de un genrico completo de igual nombre por no presentar, cuando se lo lista, el smbolo (G) caracterstico de los perfiles genricos (ver 4.10).
Apuntes de RACF Juan Mautalen

42 Si el dataset no tiene un perfil discreto, el comando: LISTDSD DATASET(nombre-del-archivo) GENERIC ALL lista el perfil protector del dataset codificado en el operando DATASET (o sea, el genrico ms especfico que lo cubre). Mas adelante analizaremos el comando LISTDSD en detalle. Consideraciones importantes: RACF no brinda la posibilidad de proteger datasets particionados a nivel de miembros (members). Solo se puede proteger una biblioteca de manera global, a travs de un nico perfil de dataset. Por lo tanto, si un miembro particular requiriera un tratamiento diferenciado en cuanto a su seguridad, se lo debera aislar en otra biblioteca y protegerla de manera adecuada. En el caso de archivos VSAM, solo es necesario proteger el nombre del cluster. Los nombres de los restantes componentes del VSAM (data e index) no intervienen en el momento de resolver sobre una solicitud de acceso. 4.5 - Niveles de autoridad para perfiles de dataset Tanto en el UACC, como en las listas de acceso, existen distintos niveles de autoridad que se pueden especificar para perfiles de dataset. Estos son los siguientes:
o o o o o o

NONE EXECUTE READ UPDATE CONTROL ALTER

Se enumeraron desde el ms restrictivo al ms permisivo. Cada nivel incluye y excede los privilegios del anterior. Su significado se muestra en la tabla siguiente: NONE No permite acceder al dataset.

EXECUTE Se utiliza exclusivamente para bibliotecas de mdulos. Este nivel de autoridad permite ejecutar programas de la librera, pero no autoriza a copiarlos. Su implementacin suele ser problemtica. Aconsejamos usar READ en lugar de EXECUTE. READ UPDATE Permite acceder al dataset nicamente para lectura. Cabe sealar que READ es suficiente para copiar o imprimir el archivo. Permite tanto leer como modificar el dataset. No autoriza, sin embargo, a deletearlo, renombrarlo o moverlo. Sobre archivos VSAM, permite las operaciones normales de I/O.

CONTROL Para archivos NOVSAM, es equivalente a UPDATE. Sobre archivos VSAM, permite un nivel de acceso ms amplio que UPDATE (improved control interval processing). ALTER Permite leer, modificar, renombrar, mover y deletear el dataset. Sobre perfiles discretos, otorga adems la posibilidad de administrar el perfil, modificando casi cualquier campo -incluida la lista de acceso. Tambin permite borrar el perfil de la base. Sobre perfiles genricos no otorga ningn privilegio administrativo. Autoriza asimismo a alocar nuevos datasets que queden protegidos por este perfil.

Apuntes de RACF

Juan Mautalen

43 4.6 - Administracin de perfiles de dataset Ya sealamos anteriormente las restricciones que existen con respecto al nombre de estos perfiles. Analizaremos ahora en detalle los comandos necesarios para su administracin. A diferencia de los perfiles de grupo y usuarios, los perfiles de dataset tienen listas de acceso (access lists). Existen 2 tipos: Lista de acceso estndar Es la que se utiliza en la enorme mayora de los casos. Contiene un listado de grupos y usuarios, acompaados cada uno de un determinado nivel de autoridad. Puede eventualmente tambin figurar una entrada *. Lista de acceso condicional A travs de esta lista se puede otorgar acceso a un dataset siempre y cuando se cumplan ciertas condiciones (que se encuentren previstas, naturalmente). Por ejemplo, puede autorizarse a un usuario a acceder a un archivo nicamente cuando se encuentre logueado en una determinada terminal o consola. No analizaremos en detalle todas las condiciones manejables a nivel de la lista de acceso condicional, ya que ello escapa al objetivo de este texto introductorio. De todos modos, para los requerimientos usuales de seguridad, la lista de acceso estndar suele ser suficiente. 4.7 - Definicin de un perfil de dataset Sintaxis: ADDSD|AD nombre-del-perfil [DATA(installation-data)] [OWNER(usuario/grupo)] [UACC(nivel)] [{GENERIC|MODEL|TAPE}] [{NOSET|SET|SETONLY}] [FROM(perfil2)] [FCLASS(clase)] [FGENERIC] [FVOLUME(volumen)] [UNIT(unidad)] [VOLUME(volumen)] [WARNING] [NOTIFY(usuario)] [AUDIT(tipo-de-acceso(nivel-de-acceso))] El nombre-del-perfil es requerido y debe estar inmediatamente a continuacin del comando ADDSD. Si contiene caracteres genricos (%, *, o **), entonces el perfil creado resulta genrico, an cuando se omita el operando GENERIC. Si el nombre no contiene estos caracteres, entonces se crear un perfil discreto, a menos que se codifique explcitamente el operando GENERIC, en cuyo caso resultar un perfil genrico completo. La DATA del perfil es un campo de uso administrativo, de longitud mxima 255 caracteres. El OWNER del perfil debe ser un usuario o grupo existente. Si es un perfil de dataset de grupo y se especifica un usuario como owner, debe necesariamente estar conectado al grupo. Si no se codifica OWNER, queda como tal el usuario que ejecut el comando (salvo que el HLQ sea un usuario distinto, en cuyo caso ste queda como owner). Notemos que ser dueo de un perfil de dataset no otorga acceso a los eventuales archivos que proteja. Para poder acceder a ellos, debe agregarse al usuario en la lista de acceso a travs del comando PERMIT. El operando UACC es sumamente importante y establece el nivel de acceso universal (Universal Access) del perfil. Puede tomar los valores NONE, EXECUTE, READ, UPDATE, CONTROL y ALTER, que ya se analizaron previamente. Bsicamente, el UACC establece el nivel de acceso que tendr sobre los archivos protegidos por el perfil todo usuario que no se encuentre explcitamente en la lista de acceso (ni ninguno de sus grupos) ni que tenga algn nivel de acceso particular por otro motivo (atributo OPERATIONS, por ejemplo). En un captulo posterior estudiaremos con todo detalle el proceso que sigue RACF para determinar el nivel de autoridad de un usuario sobre un recurso. Si no se especifica UACC, el valor por defecto es el UACC que tiene el usuario que ejecuta el comando en su actual grupo de conexin (que, como sealramos anteriormente, conviene que sea NONE, por motivos de seguridad).

Apuntes de RACF

Juan Mautalen

44 GENERIC debe obligatoriamente especificarse si se pretende definir un perfil genrico completo. Si el nombre del perfil contiene algn carcter genrico, no es necesario codificar GENERIC (aunque puede hacerse). MODEL indica que se va a definir un perfil discreto que luego ser utilizado como modelo para la definicin de futuros perfiles de dataset. Si en el nombre del perfil figura algn carcter genrico, el operando MODEL es ignorado. Si no existen en el nombre tales caracteres, los operando GENERIC y MODEL son incompatibles, siendo el ltimo codificado el que prevalece. Cuando se especifica MODEL, no es necesario que exista realmente un archivo cuyo nombre coincida con el del perfil (como s es requisito para perfiles discretos comunes), y pueden omitirse los operandos UNIT y VOLUME. Volveremos sobre la creacin de perfiles basados en un modelo en el captulo dnde analicemos las opciones de la SETROPTS, ya que all es dnde se establece que tipo de perfiles de dataset se pretende modelizar. TAPE indica que se va a definir un perfil discreto que protege un archivo en cartucho (debe estar la opcin TAPEDSN activa en la SETROPTS, ya que en caso contrario el comando falla). Si el nombre del perfil contiene algn carcter genrico, el operando TAPE es ignorado. Cuando se define un perfil discreto, el operando NOSET|SET|SETONLY establece cmo se desea manejar el bit indicador del archivo: El valor por defecto es SET, que activa el bit indicador dejando al archivo RACF-indicado. NOSET establece que se cree un perfil discreto pero sin alterar el estado del bit indicador del archivo. En consecuencia, si el dataset ya estaba RACF-indicado, el operando NOSET lo deja en la misma condicin (en este caso, el valor SET provocara un error, ya que intentara activar un bit que ya se encontraba activado). Es importante tener en cuenta que si el archivo no estaba RACF-indicado y se codifica NOSET, el perfil creado no lo proteger. SETONLY es una opcin que se aplica al caso de archivos en cartucho e indica que no se va a crear un perfil discreto de dataset sino simplemente una entrada en la TVTOC (Tape Volume table of Contents). En la presente gua no trataremos en detalle la proteccin de archivos en cartuchos. Para cualquiera de las opciones -SET, NOSET y SETONLY-, si se especific GENERIC, o bien el nombre-del-perfil contiene caracteres genricos, el operando de seteo es ignorado. El operando FROM especifica el nombre de un perfil, discreto o genrico, en el cual se va a basar RACF para la creacin del nuevo perfil. Este operando prevalece sobre la eventual modelizacin de perfiles que pueda existir para el usuario o grupo dado por el HLQ. Todas las caractersticas del perfil especificado en el operando FROM son replicadas en el nuevo (OWNER, UACC, WARNING, AUDITING, NOTIFY, DATA, Listas de acceso, etc.), excepto que se codifique explcitamente un valor distinto para alguno de estos operandos en el comando ADDSD. Puede existir una mnima diferencia en la lista de acceso del nuevo perfil con respecto al tomado como modelo, en los casos siguientes: - Si se crea un perfil de dataset de grupo, y quien lo hace tiene el atributo GRPACC y est conectado a l, entonces el grupo se agrega a la lista de acceso con autoridad UPDATE, independientemente de que figure o no en la lista de acceso del perfil modelo. - Si la opcin ADDCREATOR est activa en la SETROPTS, el usuario que crea el nuevo perfil se agrega a la lista de acceso con autoridad ALTER, independientemente de que figure o no en la lista de acceso del perfil modelo. FCLASS indica la clase de RACF a la que pertenece el perfil especificado en el operando FROM (DATASET o cualquier clase definida en la CDT son admisibles). El valor por defecto es DATASET. RACF ignora el operando FCLASS si no se codific FROM. FGENERIC indica a RACF que el perfil especificado en el operando FROM es genrico, an cuando no contenga caracteres genricos. RACF ignora el operando FGENERIC si no se codific FROM. Si el operando FROM especifica un perfil discreto de DATASET, el operando FVOLUME debe indicar el volumen correspondiente del perfil modelo. Si se codifica FVOLUME con un valor distinto al que
Apuntes de RACF Juan Mautalen

45 corresponde, o si se omite y existe ms de un perfil discreto con ese nombre, el comando falla. Si no se especific el operando FROM, o se codific con un perfil genrico, o con un perfil de una clase que no sea DATASET, el operando FVOLUME es ignorado. Los operandos UNIT y VOLUME son requeridos nicamente en el caso de perfiles discretos que correspondan a archivos no-vsam y no catalogados. En tal caso, UNIT debe indicar el tipo de dispositivo dnde reside el archivo mientras que VOLUME especifica el volumen. Si el perfil es genrico, o se especific el operando MODEL, UNIT y VOLUME son ignorados. El operando WARNING establece que el perfil se define en modo warning. Esto significa que, si un usuario requiere acceso a un recurso protegido por el perfil, y RACF determina que no est autorizado, en lugar de denegar el acceso lo autoriza pero enva un mensaje a la terminal del usuario (y graba uno similar en el SYSLOG) indicando que el acceso no corresponda pero fue otorgado por estar el perfil protector en modo warning. En ciertas ocasiones, cuando an no se logr determinar exactamente que usuarios deben acceder a los archivos protegidos por un perfil, puede resultar til definirlo en modo warning, de modo a no provocar una interrupcin en alguna tarea crtica. Sin embargo, debe tenerse presente que aquellos recursos protegidos por un perfil en modo warning se encuentran accesibles por cualquier usuario con el mximo nivel de autoridad, o sea que se encuentran bsicamente desprotegidos. Por lo tanto, debe usarse esta facilidad con sumo cuidado, y normalmente por un perodo muy corto de tiempo.Si se omite el operando WARNING, el perfil queda definido como NOWARNING, que llamamos modo fail. Este debe ser el modo en que se encuentren usualmente todos los perfiles de la base. NOTIFY especifica un usuario que ser notificado cada vez que el perfil sea usado para denegar un acceso. Hacemos notar que si el perfil es utilizado para rechazar la creacin o eliminacin de un archivo, no se enva notificacin alguna. Si el usuario especificado en el operando NOTIFY se encuentra con una sesin activa de TSO, recibir las notificaciones en tiempo real. En caso contrario las recibir en el momento de su prximo logon (no se pierden). Si la cantidad de notificaciones esperadas es elevada, el usuario debe loguearse frecuentemente a TSO de modo de liberar el espacio que ocupan sus mensajes pendientes en el archivo SYS1.BRODCAST. De todos modos, no es conveniente tener en forma permanente un usuario en el campo NOTIFY de un perfil, si se supone que el mismo denegar gran cantidad de accesos. NOTIFY no admite ms de un usuario, ni un grupo de RACF. Si se lo codifica sin especificar usuario, queda como usuario a ser notificado quien ejecut el comando ADDSD. Si se lo omite, ningn usuario ser notificado, que es lo ms habitual. El operando AUDIT indica a qu nivel se pretende auditar el uso de este perfil. La informacin se graba en registros tipo 80 del SMF. Se distinguen 2 conceptos diferentes, a saber: tipo de acceso y nivel de acceso: Los posibles tipos de acceso son los siguientes: o NONE indica que ningn intento de acceso ser grabado. o SUCCESS indica que se grabarn accesos exitosos. o FAILURES indica que se grabarn intentos de acceso fallidos. o ALL indica que se grabar todo intento de acceso, sea fallido o exitoso. Los posibles niveles de acceso son los siguientes: o READ o UPDATE o CONTROL o ALTER En el operando AUDIT se pueden especificar uno (o ms) tipos de acceso acompaados del nivel de acceso deseado (obviamente NONE no requiere un nivel de acceso asociado). EXECUTE no es un nivel factible de ser auditado.

Apuntes de RACF

Juan Mautalen

46 FAILURES(READ) es el valor por defecto, y provoca que se registre todo intento de acceso denegado por el perfil (intentos de acceso fallidos superiores a READ tambin son registrados). Debe tenerse cuidado en no especificar un nivel de auditora que genere un volumen grande e intil de informacin. Por ejemplo, SUCCESS(READ), en el caso de un perfil que proteja recursos muy utilizados, generara una enorme cantidad de registros tipo 80 de SMF que probablemente no sean necesarios en absoluto. Ms adelante veremos cmo interacta el nivel de auditora del perfil con los seteos globales de auditora que se establecen en la SETROPTS. Ejemplos 1) AD conta.balance.a2010 DATA(balance del 2010) OWNER(conta) UACC(none) AUDIT(SUCCESS(update) FAILURES(read)) Define un perfil discreto de dataset para el archivo de nombre CONTA.BALANCE.A2010. Tal dataset debe estar catalogado, pues en caso contrario el comando fallara ya que no se especific UNIT ni VOLSER. Se decidi auditar todo acceso fallido ms los accesos exitosos de nivel UPDATE (o superior). 2) AD conta.pagos.a2010 GENERIC DATA(pagos del 2010) UACC(none) OWNER(jef254) NOTIFY(jef254) Define un perfil genrico completo para el archivo de nombre CONTA.PAGOS.A2010, ya que se codific el operando GENERIC. A diferencia del caso anterior, tal archivo ni siquiera tiene necesidad de existir en el momento de la creacin del perfil. Se decidi establecer como owner y usuario a ser notificado a JEF254. 3) AD prod.public.** DATA(archivos de uso publico) UACC(read) Define un perfil genrico, dado que el nombre contiene el carcter genrico **. 4) AD conta.provee.a200%.** FROM(conta.pagos.a2010) FGENERIC DATA(pagos a proveedores) Define un perfil genrico, basado en el modelo dado por el perfil genrico completo CONTA.PAGOS.A2010. Como se especific DATA, este valor prevalece por sobre la Installation Data que tiene el perfil modelo. Autoridad requerida para definir perfiles de dataset Para definir un perfil de dataset de usuario, quien ejecuta el comando debe cumplir con alguno de los siguientes requisitos: Su identificador de usuario debe coincidir con el HLQ del perfil que pretende definir. Tener el atributo SPECIAL a nivel de sistema. Tener el atributo SPECIAL a nivel de un grupo que tenga al usuario dado por el HLQ del perfil dentro de su campo de accin. Para definir un perfil de dataset de grupo, el usuario que ejecuta el comando debe cumplir con alguno de los siguientes requisitos: Estar conectado al grupo dado por el HLQ con nivel de autoridad CREATE o superior. Tener el atributo SPECIAL a nivel de sistema. Tener el atributo SPECIAL a nivel de un grupo que tenga al grupo dado por el HLQ del perfil dentro de su campo de accin. Tener el atributo OPERATIONS a nivel de sistema y no estar conectado al grupo dado por el HLQ. Tener el atributo OPERATIONS a nivel de un grupo que tenga dentro de su campo de accin al grupo dado por el HLQ, y no estar conectado a ese grupo.
Apuntes de RACF Juan Mautalen

47 Para poder usar el operando FROM, que permite crear un nuevo perfil de dataset basndose en uno ya existente, RACF exige adems que el usuario que ejecuta el comando satisfaga alguno de los siguientes requisitos: Tener el atributo SPECIAL a nivel de sistema. Tener el atributo SPECIAL a nivel de un grupo que tenga al perfil tomado como modelo dentro de su campo de accin. Ser el owner del perfil tomado como modelo. Tener un identificador de usuario que coincida con el HLQ del perfil tomado como modelo. Si el perfil modelo es discreto, tener autoridad ALTER sobre el perfil. 4.8 - Modificacin de un perfil de dataset Sintaxis: ALTDSD|ALD nombre-del-perfil [DATA(installation-data)|NODATA] [OWNER(usuario/grupo)] [UACC(nivel)] [GENERIC] [UNIT(unidad)] [VOLUME(volumen)] [WARNING|NOWARNING] [NOTIFY(usuario)|NONOTIFY] [AUDIT(tipo-de-acceso(nivel-de-acceso))] Como sucede con todos los comandos de modificacin de perfiles, solo es necesario codificar los operandos que se desee modificar. Los no especificados mantienen sus valores previos (no se aplican valores por defecto). No es posible modificar un perfil discreto para convertirlo en genrico completo, o viceversa. Si se pretende realizar esto, debe deletearse el perfil y definirlo nuevamente de la manera deseada. El operando GENERIC indica simplemente que debe considerarse al perfil como genrico, an cuando no contenga tales caracteres en su nombre. Autoridad requerida Para modificar un perfil de dataset, quien ejecuta el comando debe cumplir con alguno de los siguientes requisitos: Tener el atributo SPECIAL a nivel de sistema. Tener el atributo SPECIAL a nivel de un grupo que tenga al perfil dentro de su campo de accin. Ser el owner del perfil. Su identificador de usuario debe coincidir con el HLQ del perfil. Si el perfil es discreto, tener autoridad ALTER sobre el perfil. 4.9 - Eliminacin de un perfil de dataset Sintaxis: DELDSD|DD nombre-del-perfil [GENERIC|NOSET|SET] [VOLUME(volumen)] La eliminacin de un perfil de dataset nunca borra ningn archivo. Fuera de la base de RACF, lo nico que este comando puede eventualmente modificar es el bit indicador de proteccin de un dataset (que, recordemos, no forma parte del archivo). GENERIC indica que debe considerarse al perfil como genrico, an cuando no contenga caracteres comodn en su nombre. NOSET se aplica exclusivamente para perfiles discretos. Indica que no se modifique el estado del bit indicador del archivo. Salvo situaciones particulares que as lo justifiquen, debe evitarse el uso de esta opcin, pues no es conveniente dejar marcados como protegidos discretamente archivos que ya no lo estn, pues es fuente de confusin e inconvenientes. El archivo, en este caso, quedara protegido
Apuntes de RACF Juan Mautalen

48 genricamente, en caso de que existiera alguno perfil genrico apropiado, o simplemente desprotegido en caso contrario. SET es el valor por defecto, y tambin se aplica exclusivamente a perfiles discretos. Este operando desactiva el bit de proteccin del archivo, y requiere que el volumen donde reside est en lnea. Si el archivo tuviera su bit de proteccin desactivado, y se especifica SET, el comando falla. En tal caso, debera codificarse NOSET para poder borrar el perfil. VOLUME solo es necesario para perfiles discretos, siempre y cuando existan en la base de RACF ms de un perfil discreto con el nombre en cuestin pero con distintos volmenes asociados. En efecto, en tal caso, VOLUME es requerido por RACF para saber cul es exactamente el perfil discreto que debe borrar de la base. Autoridad requerida Para eliminar un perfil de dataset, quien ejecuta el comando debe cumplir con alguno de los siguientes requisitos: Tener el atributo SPECIAL a nivel de sistema. Tener el atributo SPECIAL a nivel de un grupo que tenga al perfil dentro de su campo de accin. Ser el owner del perfil. Su identificador de usuario debe coincidir con el HLQ del perfil. Si el perfil es discreto, tener autoridad ALTER sobre el perfil. 4.10 - Listado de un perfil de dataset Sintaxis: LISTDSD|LD [{DATASET(nombre)|ID(usuario/grupo)|PREFIX(cadena-de-caracteres)}] [GENERIC|NOGENERIC] [AUTHUSER] [ALL] [DSNS] [VOLUME(volumen)...] Este comando no efecta ninguna modificacin sobre la base de RACF. Unicamente lista (en la pantalla de la terminal, si se ejecuta en foreground, o con salida a un dataset o al spool, si se ejecuta en batchground) informacin relativa a perfiles de dataset. DATASET|ID|PREFIX El operando DATASET especifica el nombre del perfil a listar. o Si el nombre no presenta caracteres comodn y no se especifica ni GENERIC ni NOGENERIC, RACF lista la informacin del perfil discreto y del genrico completo. Si ninguno existiese, lo informa. o Si el nombre no presenta caracteres comodn y se especifica NOGENERIC, RACF lista la informacin del perfil discreto correspondiente. Si no existiese, lo informa. o Si el nombre no tiene caracteres comodn y se especifica GENERIC, RACF lista la informacin del perfil genrico que ms se ajusta al nombre del archivo (o sea, de su perfil protector, siempre y cuando no est protegido de manera discreta). o Si el nombre tiene algn carcter comodn, RACF ignora el operando [GENERIC|NOGENERIC] y lista el perfil genrico que coincide exactamente con el nombre especificado. Si no existiese, lo informa. ID debe especificar un usuario o grupo. En tal caso, el comando lista los perfiles cuyo HLQ coincide con este valor. Se listarn solo discretos, solo genricos, o todos, segn se especifique NOGENERIC, GENERIC, o se omita este operando. Si se especifica PREFIX, el comando lista los perfiles cuyos primeros caracteres coincidan exactamente con el valor especificado. Se listarn solo discretos, solo genricos, o todos, segn como se codifique el

Apuntes de RACF

Juan Mautalen

49 operando correspondiente. La cadena de caracteres especificada puede extenderse a ms de un calificador. En caso de no especificar ni DATASET, ni ID ni PREFIX, el valor que asume por defecto es ID con el valor del identificador del usuario que ejecuta el comando. GENERIC indica que deben listarse nicamente perfiles genricos, mientras que NOGENERIC indica que solo deben listarse los discretos. Si se omite este operando, y se codific DATASET, ya se seal qu perfiles son listados. En cambio, si se especific ID o PREFIX, se listan todos los perfiles (discretos y genricos) que cumplan con el criterio de seleccin correspondiente. AUTHUSER especifica que se debe incluir en la salida del comando la siguiente informacin: o Security level, categories y security label o Lista de acceso estndar o Lista de acceso condicional ALL indica que se liste toda la informacin del perfil. Si no se especifica, el listado no muestra ni las estadsticas ni las listas de acceso. El operando DSNS indica que se listen todos los archivos catalogados protegidos por el perfil. Si la cantidad es muy grande, esta bsqueda cruzada es costosa y puede demorar considerablemente la ejecucin del comando. El operando VOLUME limita la informacin listada a los perfiles discretos asociados con estos volmenes (se pueden especificar varios). Excepto que se haya codificado NOGENERIC, tambin se listan los perfiles genricos que correspondan. Observacin importante: Los perfiles genricos, al ser listados (ya sea con el comando LISTDSD o SEARCH), siempre tienen a continuacin de su nombre el smbolo (G). Por lo tanto, la ausencia de la (G) indica sin lugar a dudas que se trata de un perfil discreto. Ejemplo: LD DA(conta.pagos.**) ALL DSNS Este comando lista toda la informacin del perfil genrico CONTA.PAGOS.**, siempre y cuando exista. La salida tendra el siguiente aspecto:
INFORMATION FOR DATASET CONTA.PAGOS.** (G) LEVEL 00 OWNER CONTA UNIVERSAL ACCESS WARNING NONE NO ERASE NO

AUDITING FAILURES(READ) NOTIFY CON587 YOUR ACCESS NONE GLOBALAUDIT NONE INSTALLATION DATA AREA DE CONTABILIDAD - PAGOS SECURITY LEVEL NO SECURITY LEVEL CATEGORIES NO CATEGORIES SECLABEL Apuntes de RACF Juan Mautalen CREATION GROUP ADMIN DATASET TYPE NON-VSAM

50
NO SECLABEL CREATION DATE (DAY) (YEAR) 295 10 LAST REFERENCE DATE LAST CHANGE DATE (DAY) (YEAR) (DAY) (YEAR) NOT APPLICABLE FOR GENERIC PROFILE UPDATE COUNT READ COUNT

ALTER COUNT CONTROL COUNT NOT APPLICABLE FOR GENERIC PROFILE ID CONTA FINAN FIN2514 ACCESS ALTER READ UPDATE

ID ACCESS CLASS ENTITY NAME NO ENTRIES IN CONDITIONAL ACCESS LIST CATALOGUED DATA SETS AFFECTED BY PROFILE CHANGE CONTA.PAGOS.A2007 CONTA.PAGOS.A2008 CONTA.PAGOS.A2009 CONTA.PAGOS.PROVEE CONTA.PAGOS.PROVEE.DATA (D) CONTA.PAGOS.PROVEE.INDEX (I)

Del listado precedente, se desprende la siguiente informacin sobre el perfil: Se trata efectivamente de un perfil genrico, ya que figura el smbolo (G) a continuacin del nombre. LEVEL es un campo para uso administrativo, que puede tomar cualquier valor entre 00 y 99, siendo 00 el valor por defecto. No tiene ninguna relevancia en el chequeo de autoridad, y cada organizacin lo maneja como desea (aunque es realmente poco utilizado). Un posible uso consiste en asignarle a todos los perfiles con un cierto grado de sensibilidad un mismo LEVEL, de modo de disponer de un criterio de seleccin para la elaboracin de informes de auditora. No debe confundirse LEVEL con SECURITY LEVEL. El OWNER es CONTA. Suponemos que es un grupo, aunque en general no es posible determinar con solo mirar un identificador si se trata de un usuario o de un grupo. De todos modos, cada organizacin tiene usualmente una nomenclatura bastante diferente para ambos, con lo cual suele ser mas o menos evidente para los administradores cuando se trata de un usuario y cuando de un grupo. El UACC del perfil es NONE. WARNING en NO indica que el perfil est en modo fail. Esto significa que se denegar todo acceso no autorizado. Salvo casos excepcionales, todos los perfiles deben estar en modo fail. El valor YES en campo ERASE a nivel del perfil, combinado con una configuracin apropiada del ERASE a nivel de la SETROPTS, especifica que cuando se deletea un archivo protegido por este perfil, los datos deben ser fsicamente borrados en el disco dnde reside (sobrescribiendo todos los extents con ceros binarios). Este requerimiento extra de seguridad, que impide cualquier intento de recuperacin de los datos, no suele ser necesario.El valor por defecto es NO. FAILURES(READ) en el campo AUDITING indica que se pretende loggear en el SMF nicamente los intentos de acceso denegados por el perfil. Los accesos exitosos no sern grabados, cualquiera sea el nivel (excepto que exista algn otro seteo de auditora que indique lo contrario, a nivel de la SETROPTS o del GLOBALAUDIT del perfil). El usuario CON587 recibir una notificacin cada vez que el perfil CONTA.PAGOS.** sea utilizado para denegar una solicitud de acceso. En este caso, podemos estar seguros que CON587 es un usuario, ya que el campo NOTIFY no admite grupos.

Apuntes de RACF

Juan Mautalen

51 El campo YOUR ACCESS muestra el nivel de autoridad que tiene sobre el perfil el usuario que ejecuta el comando LISTDSD. CREATION GROUP indica el grupo de conexin que tena el usuario que defini el perfil en el momento de la creacin. DATASET TYPE puede tomar los valores NON-VSAM, VSAM, MODEL o TAPE. GLOBALAUDIT funciona de manera similar al campo AUDIT, pero es nicamente visible y modificable por usuarios con el atributo AUDITOR a nivel de sistema, o a nivel de un grupo que tenga al perfil dentro de su campo de accin. La INSTALLATION DATA es opcional, pero es una buena costumbre usar este campo para describir brevemente el perfil. SECURITY-LEVEL, CATEGORIES y SECLABEL son campos relacionados con un nivel extra de seguridad que brinda RACF y es realmente muy poco utilizado. Si la organizacin no usa esta seguridad adicional, los 3 campos deben indicar que no tienen informacin. CREATION DATE indica el da y el ao en que se defini el perfil. En este caso, el perfil se cre el da 295 del ao 2010. LAST REFERENCE DATE y LAST CHANGE DATE no se aplican a perfiles genricos. Solamente se mantienen estos campos para perfiles discretos. ALTER COUNT, CONTROL COUNT, UPDATE COUNT y READ COUNT no se aplican a perfiles genricos. En el caso de perfiles discretos, solo se mantienen actualizados si est especificado en la SETROPTS que se mantengan estadsticas para la clase DATASET. La lista de acceso estndar del perfil tiene entradas constituidas por usuarios o grupos, con su nivel de acceso correspondiente. En el ejemplo, existen 3 entradas en la lista de acceso estndar (vale la misma aclaracin que se hizo previamente, en el sentido en que no se puede distinguir a priori si se trata de usuarios o grupos). Eventualmente, tambin puede figurar en la lista de acceso una entrada *, que tiene un significado similar -pero no idntico- al del UACC. La lista de acceso condicional se encuentra vaca (no contiene ninguna entrada). No nos ocuparemos en la presente gua de analizar la lista de acceso condicional de un perfil (no es muy frecuente su uso, por otro lado). Al haber especificado el operando DSNS en el comando LISTDSD, la salida incluye una lista de los archivos catalogados que se encuentran protegidos por el perfil. En nuestro caso, existen 4datasets, uno de los cules es VSAM (y por eso genera 3 entradas en el listado, correspondientes a sus distintos componentes). Es posible que un usuario pueda ejecutar el comando del ejemplo pero que algunos campos no le sean mostrados por carecer de la autoridad suficiente (por ejemplo, GLOBALAUDIT o listas de acceso). Autoridad requerida Para listar un perfil de dataset, quien ejecuta el comando debe cumplir con alguno de los siguientes requisitos: Tener el atributo SPECIAL, AUDITOR u OPERATIONS a nivel de sistema. Tener el atributo SPECIAL, AUDITOR u OPERATIONS a nivel de un grupo que tenga al perfil dentro de su campo de accin. Su identificador de usuario debe coincidir con el HLQ del perfil. Ser el owner del perfil. Tener autoridad READ o superior sobre el perfil.

Apuntes de RACF

Juan Mautalen

52 Existir una regla en la GLOBAL que coincida con el perfil y otorgue autoridad READ o superior. Para que se liste el campo GLOBALAUDIT se debe tener el atributo AUDITOR (ya sea a nivel de sistema, o a nivel de grupo para un grupo que tenga al perfil dentro de su campo de accin). Para ver las listas de acceso del perfil, quien ejecuta el comando debe satisfacer alguna de las siguientes condiciones: Tener el atributo SPECIAL, AUDITOR u OPERATIONS a nivel de sistema. Tener el atributo SPECIAL, AUDITOR u OPERATIONS a nivel de un grupo que tenga al perfil dentro de su campo de accin. Su identificador de usuario debe coincidir con el HLQ del perfil. Ser el owner del perfil. Existir una regla en la GLOBAL que coincida con el perfil y otorgue autoridad ALTER. Si el perfil es discreto, tener autoridad ALTER. 4.11 - Permisos sobre perfiles de dataset Las listas de acceso de un perfil de dataset, tanto la estndar como la condicional, se modifican a travs del comando PERMIT. Ms an, con este mismo comando se manejan tambin las listas de acceso de cualquier perfil de recursos generales. Sintaxis: PERMIT|PE nombre-del-perfil [CLASS(clase)] [GENERIC] [ID({usuario/grupo...|*})] [ACCESS(nivel)|DELETE] [VOLUME(volumen)] [FROM(perfil2)] [FCLASS] [FGENERIC] [FVOLUME(volumen)] [RESET(ALL|STANDARD|WHEN)] [WHEN([APPCPORT({partner-luname|*})] [CONSOLE({consola|*})] [JESINPUT({nombre-input-device|*})] [PROGRAM({programa|*})] [SYSID({sysid|*})] [TERMINAL({terminal|*})])] El nombre-del-perfil es requerido y debe estar inmediatamente a continuacin del comando PERMIT. CLASS indica la clase a la que pertenece el perfil. El valor por defecto es DATASET, por lo cual, en el caso particular que nos ocupa, puede omitirse. GENERIC especifica que el perfil es genrico. Debe necesariamente codificarse si se trata de un genrico completo, pues de lo contrario RACF supondr que el perfil es discreto. Si el nombre contiene caracteres comodn, GENERIC puede omitirse. ID indica el usuario o grupo cuya entrada en la lista de acceso se desea agregar, modificar o eliminar. Separados por espacios pueden ingresarse ms de un usuario/grupo. Tambin se acepta el valor *, que representa un usuario cualquiera existente en la base de RACF. ACCESS especifica el nivel de autoridad a otorgarle al usuario/grupo especificado en el operando ID. Los posibles valores son NONE, EXECUTE, READ, UPDATE, CONTROL y ALTER. Si se codifica ACCESS sin poner ningn valor, se asume READ. DELETE indica que se pretende borrar de la lista de acceso la entrada correspondiente al usuario/grupo codificado en el operando ID. Si se especific ID pero se omiti tanto ACCESS como DELETE, se asume por defecto ACCESS(READ). En ambos casos, ya sea con ACCESS o DELETE, RACF acta sobre la lista de acceso estndar, excepto que se codifique explcitamente el operando WHEN, en cuyo caso se modifica la lista de acceso condicional.

Apuntes de RACF

Juan Mautalen

53 VOLUME es necesario nicamente si se trata de un perfil discreto que corresponde a un archivo no catalogado. FROM especifica el nombre de otro perfil, genrico o discreto, del cual se quieren copiar las listas de acceso (estndar y condicional). Las entradas en las listas de acceso del perfil2 son agregadas a las listas de acceso correspondiente. Por lo tanto, el operando FROM no convierte en idnticas las listas de acceso de ambos perfiles. Ms an, si una entrada que figura en la lista de acceso del perfil2 ya se encuentra en la del perfil en cuestin, entonces la misma no se modifica. FCLASS indica la clase a la que pertenece el perfil especificado en el operando FROM. Si omite FCLASS y se codific FROM, se asume por defecto que perfil2 pertenece a la misma que clase que el perfil en cuestin (DATASET, en nuestro caso). FGENERIC indica a RACF que el perfil especificado en el operando FROM es genrico, an cuando no contenga caracteres genricos. RACF ignora el operando FGENERIC si no se codific FROM. Si el operando FROM especifica un perfil discreto de DATASET, el operando FVOLUME indica el volumen correspondiente. Si se codificara FVOLUME con un valor distinto al que corresponde al perfil2, o si se omite y existe ms de un perfil discreto con se nombre, el comando falla. Si no se especific el operando FROM, o se codific con un perfil genrico, o con un perfil de una clase que no sea DATASET, el operando FVOLUME es ignorado. El operando RESET indica que se quiere vaciar una o ambas listas de acceso, es decir eliminar todas las entradas. RESET(STANDARD) vaca nicamente la lista de acceso estndar, en tanto que RESET(WHEN) hace lo propio con la condicional. RESET(ALL) vaca ambas listas de acceso. Si se codifica RESET sin ningn valor, se asume por defecto ALL. El operando WHEN indica que se quiere modificar la lista de acceso condicional. No describiremos los distintos suboperandos que admite. Si se omite WHEN, las modificaciones se efectan sobre la lista de acceso estndar (aunque los operandos FROM o RESET pueden impactar igualmente sobre la lista de acceso condicional). Ejemplos: 1) PE conta.balance.a2010 ID(conta) ACCESS(update) Otorga UPDATE en la lista de acceso estndar del perfil discreto CONTA.BALANCE.A2002 al grupo CONTA. Si el grupo ya figuraba, modifica su nivel a UPDATE, mientras que si no estaba, lo incorpora con este nivel de acceso. 2) PE conta.pagos.a2010.** FROM(conta.provee.a2010) FGENERIC ID(jef234 jef587) ACCESS(ALTER) Copia al perfil genrico CONTA.PAGOS.A2010.** las entradas de las listas de acceso del perfil genrico completo de nombre CONTA.PROVEE.A2010. Independientemente de las entradas que se copien, la presencia de ID y ACCESS indica que los usuario JEF234 y JEF587 sern incorporados a la lista de acceso estndar del perfil CONTA.PAGOS.A2010.** con nivel de autoridad ALTER. 3) PE conta.a2010.** RESET ID(*) ACCESS(READ) Vaca las listas de acceso (estndar y condicional) del perfil genrico CONTA.A2010.** e incorpora en la lista estndar la entrada * con nivel de acceso READ. El orden de los operandos no tiene importancia en este caso, pudiendo haberse especificado RESET al final (si se codifican ambos operandos -RESET y ID-, primero se vaca la lista de acceso y luego se procesa el ID). Autoridad requerida Para ejecutar exitosamente el comando PERMIT sobre un perfil de dataset, el usuario debe satisfacer alguna de las siguientes condiciones:
Apuntes de RACF Juan Mautalen

54 Tener el atributo SPECIAL a nivel de sistema. Tener el atributo SPECIAL a nivel de un grupo que tenga al perfil dentro de su campo de accin. Ser el owner del perfil. Su identificador de usuario debe coincidir con el HLQ del perfil. Si el perfil es discreto, tener autoridad ALTER sobre el perfil. Para poder especificar el operando FROM, quien ejecuta el comando necesita adicionalmente autoridad sobre el perfil del cual se pretende copiar las listas de acceso. 4.12 - Perfiles de dataset: discretos versus genricos Como ya se ha sealado, originalmente los nicos perfiles de dataset que admita RACF eran los que hoy se conocen como discretos. Posteriormente, con la aparicin de la posibilidad de definir perfiles de dataset genricos, la mayora de las organizaciones fueron abandonando paulatinamente la utilizacin de los perfiles discretos, llegando en muchos casos a su eliminacin total. Esto es entendible, y hasta aconsejable, teniendo en cuenta que los perfiles genricos son ms sencillos de administrar, y es necesaria una menor cantidad de los mismos para proteger la totalidad de los archivos. Sin embargo, debe tenerse cuidado de no abusar en este sentido, ya que la existencia de una gran cantidad de perfiles genricos con idntico HLQ puede traer aparejado importantes problemas de performance. En efecto, dado un archivo, la localizacin de su perfil protector es ms rpida en el caso de estar protegido discretamente que en el caso de estarlo genricamente, ya que en este ltimo caso RACF debe realizar una bsqueda de tipo secuencial hasta dar con el perfil ms ajustado. Por lo tanto, si bien es muy aconsejable el uso de perfiles de dataset genricos, no debe caerse en el extremo de definir una cantidad tal que impacte negativamente en la performance (por ejemplo, 500 perfiles genricos con igual HLQ no parece apropiado). Los perfiles discretos tienen pues an su lugar, y en algunos casos particulares continan siendo una mejor opcin. Por otro lado, IBM no tiene previsto discontinuarlos en un futuro cercano, de modo que no hay ninguna razn para no utilizarlos si resultan mas apropiados para resolver una determinada situacin. Por ejemplo, si existieran 2 datasets de idntico nombre (uno de ellos necesariamente descatalogado) que requirieran distinta proteccin, solo sera posible lograrlo mediante el uso de perfiles discretos. 4.13 - Creacin de nuevos datasets Ya hemos visto, al analizar el comando ADDSD, la autoridad que se requiere para definir un nuevo perfil de dataset. Veremos ahora que autoridad exige RACF para definir un nuevo archivo. Supondremos, para simplificar, que la opcin PROTECTALL de la SETROPTS est activa en modo FAIL. Bsicamente, esto significa que los archivos no protegidos por un perfil en la clase DATASET resultan inaccesibles. Volveremos sobre este punto en el captulo dnde estudiemos en detalle las opciones de la SETROPTS. Recordemos que un archivo, para poder estar efectivamente protegido por RACF, debe tener como HLQ un usuario o grupo (pues esto es requisito insalvable para perfiles). Por lo tanto, los datasets se dividen en datasets de usuario y datasets de grupo. Para crear un dataset de usuario, quien lo hace debe satisfacer alguna de las condiciones que se enumeran a continuacin: El dataset quedar protegido por un perfil genrico y, se cumple alguno de los requisitos siguientes: - Tiene autoridad ALTER sobre tal perfil. - Tiene autoridad ALTER a travs de una regla en la GLOBAL. - El HLQ del archivo coincide con su identificador de usuario.

Apuntes de RACF

Juan Mautalen

55 Tener el atributo ADSP y el HLQ del dataset coincidir con su identificador de usuario. En este caso, se le crear automticamente un perfil discreto. Para crear un dataset de grupo, quien lo hace debe satisfacer alguna de las condiciones que se enumeran a continuacin: El dataset quedar protegido por un perfil genrico y, se cumple alguno de los requisitos siguientes: - Tiene autoridad ALTER sobre tal perfil. - Tiene autoridad ALTER a travs de una regla en la GLOBAL. - Est conectado al grupo dado por el HLQ con autoridad CREATE o superior. Tener el atributo ADSP y el HLQ ser un grupo al cual est conectado con autoridad CREATE o superior. En este caso, se le crear automticamente un perfil discreto. Tener el atributo OPERATIONS a nivel de sistema y no cumplir simultneamente: - Estar conectado al grupo dado por el HLQ con nivel USE - Tener autoridad menor que ALTER sobre el perfil genrico que lo proteger. Tener el atributo OPERATIONS a nivel de grupo, el HLQ del archivo ser un grupo dentro del campo de accin y no cumplir simultneamente: - Estar conectado al grupo dado por el HLQ con nivel USE - Tener autoridad menor que ALTER sobre el perfil genrico que lo proteger. Es importante recalcar que si se pretende que el dataset se catalogue, el usuario que lo define debe asimismo tener autoridad UPDATE sobre el catlogo correspondiente (USERCAT o MASTERCAT, dependiendo de la existencia o no del ALIAS apropiado).

Apuntes de RACF

Juan Mautalen

56 5 - OPCIONES GLOBALES DE RACF 5.1 - Consideraciones generales Resultan de vital importancia para el funcionamiento de RACF ciertas opciones globales de configuracin que se establecen y modifican a travs del comando SETROPTS. Esta configuracin se encuentra almacenada dentro de la base de RACF (en el primer bloque, llamado ICB Inventory Control Block-), y puede ser modificada dinmicamente. Con excepcin de las opciones globales relativas a auditora, que requieren el atributo AUDITOR a nivel de sistema, el resto de los parmetros exige el atributo SPECIAL a nivel de sistema para ser modificados. Una adecuada configuracin de la SETROPTS es fundamental para dotar a la organizacin de un adecuado nivel de seguridad. A lo largo del presente captulo vamos a examinar en detalle las opciones de la SETROPTS, indicando en muchos casos la configuracin que consideramos ms conveniente, tanto desde el punto de vista administrativo como desde el de la seguridad del sistema. Cuando RACF se instala por primera vez, la SETROPTS provista por IBM es a todas luces insuficiente para brindar una seguridad razonable a un entorno productivo. La configuracin global por defecto es totalmente abierta y permisiva, lo cual es entendible para cuando se afrontan las primeras etapas de la construccin de un sistema. Sin embargo, antes de empezar a utilizarlo productivamente, el administrador de RACF debe configurar adecuadamente la SETROPTS, para lo cual debe tener bien en claro el significado e impacto de cada una de sus opciones. 5.2 - Posit Value de una clase Toda clase de RACF, ya sea provista por IBM o definida por la organizacin, tiene asociado un nmero comprendido entre 0 y 1023, denominado posit value. Varias clases pueden compartir el mismo nmero. En efecto, IBM otorga igual posit value a clases que estn ntimamente relacionadas, como ser todas aquellas vinculadas con un mismo producto. Los rangos 0-18, 57-127 y 528-1023 estn reservados para uso exclusivo de IBM, por lo cual no debe utilizarse ningn nmero en alguno de estos rangos para una clase definida por la organizacin. La importancia del posit value radica en el hecho de que todos los operandos del comando SETROPTS que se aplican a una clase resultan automticamente aplicados a todas aquellas otras que comparten el mismo posit value. Por ejemplo, todas las siguientes clases, relacionadas con CICS, comparten el posit value 5: TCICSTRN, GCICSTRN, PCICSPSB, QCICSPSB, FCICSFCT, HCICSFCT, JCICSJCT, KCICSJCT, DCICSDCT, ECICSDCT, SCICSTST, UCICSTST, MCICSPPT, NCICSPPT, ACICSPCT, BCICSPCT. En consecuencia, el comando SETROPTS AUDIT(TCICSTRN) no solo auditar la clase TCICSTRN sino que automticamente har lo propio con el resto de las clases mencionadas. 5.3 - Listado de la SETROPTS Para listar el contenido de la SETROPTS se requiere tener el atributo SPECIAL o AUDITOR, ya sea a nivel de sistema o a nivel de grupo. Como ya indicramos, los usuarios con atributo SPECIAL no pueden visualizar las opciones relativas a auditora. Sintaxis: SETROPTS|SETR LIST No existe la posibilidad de listar parcialmente informacin de la SETROPTS. Para ver la configuracin de un determinado parmetro, no queda mas remedio que buscarlo dentro del listado completo que brinda el comando SETR LIST. Mostramos a continuacin, a modo de ejemplo, el listado de la SETROPTS que podra tener una organizacin tpica.
Apuntes de RACF Juan Mautalen

57
ATTRIBUTES = INITSTATS WHEN(PROGRAM -- BASIC) TERMINAL(READ) SAUDIT CMDVIOL OPERAUDIT STATISTICS = NONE AUDIT CLASSES = DATASET USER GROUP ACCTNUM ACICSPCT AIMS ALCSAUTH APPCLU APPCPORT APPCSERV APPCSI APPCTP APPL BCICSPCT CACHECLS CBIND CCICSCMD CDT CFIELD CIMS CONSOLE CPSMOBJ CPSMXMP CRYPTOZ CSFKEYS CSFSERV DASDVOL DBNFORM DCEUUIDS DCICSDCT DEVICES DIGTCERT DIGTCRIT DIGTNMAP DIGTRING DIMS DIRAUTH DIRECTRY DLFCLASS DSNADM DSNR ECICSDCT EJBROLE FACILITY FCICSFCT FIELD FILE FIMS FSOBJ GCICSTRN GCPSMOBJ GCSFKEYS GDASDVOL GDSNBP GDSNCL GDSNDB GDSNJR GDSNPK GDSNPN GDSNSC GDSNSG GDSNSM GDSNSP GDSNSQ GDSNTB GDSNTS GDSNUF GDSNUT GEJBROLE GIMS GINFOMAN GLOBAL GMBR GMQADMIN GMQCHAN GMQNLIST GMQPROC GMQQUEUE GMXADMIN GMXNLIST GMXPROC GMXQUEUE GMXTOPIC GSDSF GSOMDOBJ GTERMINL GXCSFKEY GXFACILI HCICSFCT HIMS IBMOPC IDIDMAP IIMS ILMADMIN INFOMAN IPCOBJ JAVA JCICSJCT JESINPUT JESJOBS JESSPOOL JIMS KCICSJCT KERBLINK KEYSMSTR LDAPBIND LFSCLASS LIMS LOGSTRM MCICSPPT MDSNBP MDSNCL MDSNDB MDSNJR MDSNPK MDSNPN MDSNSC MDSNSG MDSNSM MDSNSP MDSNSQ MDSNTB MDSNTS MDSNUF MDSNUT MGMTCLAS MIMS MQADMIN MQCHAN MQCMDS MQCONN MQNLIST MQPROC MQQUEUE MXADMIN MXNLIST MXPROC MXQUEUE MXTOPIC NCICSPPT NDSLINK NETCMDS NETSPAN NODES NODMBR NOTELINK NVASAPDT OIMS OPERCMDS PCICSPSB PERFGRP PIMS PMBR PRINTSRV PROCESS PROGRAM PROPCNTL PSFMPL PTKTDATA PTKTVAL QCICSPSB QIMS RACFEVNT RACFHC RACFVARS RACGLIST RACHCMBR RAUDITX RCICSRES RDATALIB REALM RIMS RMTOPS RODMMGR ROLE RRSFDATA RVARSMBR SCDMBR SCICSTST SDSF SECDATA SECLABEL SECLMBR SERVAUTH SERVER SFSCMD SIMS SMESSAGE SOMDOBJS STARTED STORCLAS SUBSYSNM SURROGAT SYSMVIEW TAPEVOL TCICSTRN TEMPDSN TERMINAL TIMS TMEADMIN TSOAUTH TSOPROC UCICSTST UIMS UNIXMAP UNIXPRIV VCICSCMD VMBATCH VMBR VMCMD VMEVENT VMLAN VMMAC VMMDISK VMNODE VMPOSIX VMRDR VMSEGMT VMXEVENT VTAMAPPL VXMBR WBEM WCICSRES WIMS WRITER XCSFKEY XFACILIT ACTIVE CLASSES = DATASET USER GROUP RVARSMBR RACFVARS DASDVOL GDASDVOL TERMINAL GTERMINL TCICSTRN GCICSTRN PCICSPSB QCICSPSB GLOBAL GMBR DSNR FACILITY FCICSFCT HCICSFCT JCICSJCT KCICSJCT DCICSDCT ECICSDCT SCICSTST UCICSTST MCICSPPT NCICSPPT ACICSPCT BCICSPCT PMBR PROGRAM TSOPROC ACCTNUM TSOAUTH FIELD CCICSCMD VCICSCMD OPERCMDS CONSOLE SURROGAT SDSF GSDSF STARTED GENERIC PROFILE CLASSES = DATASET DASDVOL TERMINAL TCICSTRN PCICSPSB FACILITY FCICSFCT JCICSJCT DCICSDCT SCICSTST MCICSPPT ACICSPCT FIELD CCICSCMD OPERCMDS CONSOLE SDSF STARTED GENERIC COMMAND CLASSES = DATASET DASDVOL TERMINAL TCICSTRN PCICSPSB FACILITY FCICSFCT JCICSJCT DCICSDCT SCICSTST MCICSPPT ACICSPCT FIELD CCICSCMD OPERCMDS CONSOLE SDSF STARTED GENLIST CLASSES = NONE GLOBAL CHECKING CLASSES = DATASET SETR RACLIST CLASSES = RACFVARS TERMINAL DSNR FACILITY TSOPROC ACCTNUM TSOAUTH FIELD OPERCMDS CONSOLE SURROGAT SDSF STARTED GLOBAL=YES RACLIST ONLY = TCICSTRN CCICSCMD LOGOPTIONS "ALWAYS" CLASSES = NONE LOGOPTIONS "NEVER" CLASSES = NONE LOGOPTIONS "SUCCESSES" CLASSES = NONE LOGOPTIONS "FAILURES" CLASSES = NONE LOGOPTIONS "DEFAULT" CLASSES = DATASET ACCTNUM ACICSPCT AIMS ALCSAUTH APPCLU APPCPORT APPCSERV APPCSI APPCTP APPL BCICSPCT CACHECLS CBIND CCICSCMD Apuntes de RACF Juan Mautalen

58
CDT CFIELD CIMS CONSOLE CPSMOBJ CPSMXMP CRYPTOZ CSFKEYS CSFSERV DASDVOL DBNFORM DCEUUIDS DCICSDCT DEVICES DIGTCERT DIGTCRIT DIGTNMAP DIGTRING DIMS DIRACC DIRAUTH DIRECTRY DIRSRCH DLFCLASS DSNADM DSNR ECICSDCT EJBROLE FACILITY FCICSFCT FIELD FILE FIMS FSOBJ FSSEC GCICSTRN GCPSMOBJ GCSFKEYS GDASDVOL GDSNBP GDSNCL GDSNDB GDSNJR GDSNPK GDSNPN GDSNSC GDSNSG GDSNSM GDSNSP GDSNSQ GDSNTB GDSNTS GDSNUF GDSNUT GEJBROLE GIMS GINFOMAN GLOBAL GMBR GMQADMIN GMQCHAN GMQNLIST GMQPROC GMQQUEUE GMXADMIN GMXNLIST GMXPROC GMXQUEUE GMXTOPIC GSDSF GSOMDOBJ GTERMINL GXCSFKEY GXFACILI HCICSFCT HIMS IBMOPC IDIDMAP IIMS ILMADMIN INFOMAN IPCOBJ JAVA JCICSJCT JESINPUT JESJOBS JESSPOOL JIMS KCICSJCT KERBLINK KEYSMSTR LDAPBIND LFSCLASS LIMS LOGSTRM MCICSPPT MDSNBP MDSNCL MDSNDB MDSNJR MDSNPK MDSNPN MDSNSC MDSNSG MDSNSM MDSNSP MDSNSQ MDSNTB MDSNTS MDSNUF MDSNUT MGMTCLAS MIMS MQADMIN MQCHAN MQCMDS MQCONN MQNLIST MQPROC MQQUEUE MXADMIN MXNLIST MXPROC MXQUEUE MXTOPIC NCICSPPT NDSLINK NETCMDS NETSPAN NODES NODMBR NOTELINK NVASAPDT OIMS OPERCMDS PCICSPSB PERFGRP PIMS PMBR PRINTSRV PROCACT PROCESS PROGRAM PROPCNTL PSFMPL PTKTDATA PTKTVAL QCICSPSB QIMS RACFEVNT RACFHC RACFVARS RACGLIST RACHCMBR RAUDITX RCICSRES RDATALIB REALM RIMS RMTOPS RODMMGR ROLE RRSFDATA RVARSMBR SCDMBR SCICSTST SDSF SECDATA SECLABEL SECLMBR SERVAUTH SERVER SFSCMD SIMS SMESSAGE SOMDOBJS STARTED STORCLAS SUBSYSNM SURROGAT SYSMVIEW TAPEVOL TCICSTRN TEMPDSN TERMINAL TIMS TMEADMIN TSOAUTH TSOPROC UCICSTST UIMS UNIXMAP UNIXPRIV VCICSCMD VMBATCH VMBR VMCMD VMEVENT VMLAN VMMAC VMMDISK VMNODE VMPOSIX VMRDR VMSEGMT VMXEVENT VTAMAPPL VXMBR WBEM WCICSRES WIMS WRITER XCSFKEY XFACILIT AUTOMATIC DATASET PROTECTION IS NOT IN EFFECT ENHANCED GENERIC NAMING IS IN EFFECT REAL DATA SET NAMES OPTION IS ACTIVE JES-BATCHALLRACF OPTION IS ACTIVE JES-XBMALLRACF OPTION IS ACTIVE JES-EARLYVERIFY OPTION IS ACTIVE PROTECT-ALL IS ACTIVE, CURRENT OPTIONS: PROTECT-ALL FAIL OPTION IS IN EFFECT TAPE DATA SET PROTECTION IS INACTIVE SECURITY RETENTION PERIOD IN EFFECT IS 0 DAYS. ERASE-ON-SCRATCH IS ACTIVE, CURRENT OPTIONS: ERASE-ON-SCRATCH BY SECURITY LEVEL IS INACTIVE SINGLE LEVEL NAMES NOT ALLOWED LIST OF GROUPS ACCESS CHECKING IS ACTIVE. INACTIVE USERIDS ARE BEING AUTOMATICALLY REVOKED AFTER 40 DAYS. DATA SET MODELLING NOT BEING DONE FOR GDGS. USER DATA SET MODELLING IS BEING DONE. GROUP DATA SET MODELLING NOT BEING DONE.

Apuntes de RACF

Juan Mautalen

59
PASSWORD PROCESSING OPTIONS: PASSWORD CHANGE INTERVAL IS 30 DAYS. PASSWORD MINIMUM CHANGE INTERVAL IS 1 DAYS. MIXED CASE PASSWORD SUPPORT IS IN EFFECT. 15 GENERATIONS OF PREVIOUS PASSWORDS BEING MAINTAINED. AFTER 5 CONSECUTIVE UNSUCCESSFUL PASSWORD ATTEMPTS, A USERID WILL BE REVOKED. PASSWORD EXPIRATION WARNING LEVEL IS 5 DAYS. INSTALLATION PASSWORD SYNTAX RULES: RULE 1 LENGTH(6:8) LLLLLLLL LEGEND: A-ALPHA C-CONSONANT L-ALPHANUM N-NUMERIC V-VOWEL W-NOVOWEL *-ANYTHING c-MIXED CONSONANT m-MIXED NUMERIC v-MIXED VOWEL $-NATIONAL INSTALLATION DEFINED RVARY PASSWORD IS IN EFFECT FOR THE SWITCH FUNCTION. INSTALLATION DEFINED RVARY PASSWORD IS IN EFFECT FOR THE STATUS FUNCTION. SECLEVELAUDIT IS INACTIVE SECLABEL AUDIT IS NOT IN EFFECT SECLABEL CONTROL IS NOT IN EFFECT GENERIC OWNER ONLY IS NOT IN EFFECT COMPATIBILITY MODE IS NOT IN EFFECT MULTI-LEVEL QUIET IS NOT IN EFFECT MULTI-LEVEL STABLE IS NOT IN EFFECT NO WRITE-DOWN IS NOT IN EFFECT MULTI-LEVEL ACTIVE IS NOT IN EFFECT CATALOGUED DATA SETS ONLY, IS IN EFFECT. CURRENT OPTIONS: "CATDSNS FAIL" OPTION IS IN EFFECT USER-ID FOR JES NJEUSERID IS : ???????? USER-ID FOR JES UNDEFINEDUSER IS : ++++++++ PARTNER LU-VERIFICATION SESSIONKEY INTERVAL MAXIMUM/DEFAULT IS APPLAUDIT IS NOT IN EFFECT ADDCREATOR IS NOT IN EFFECT KERBLVL = 0 MULTI-LEVEL FILE SYSTEM IS NOT IN EFFECT MULTI-LEVEL INTERPROCESS COMMUNICATIONS IS NOT IN EFFECT MULTI-LEVEL NAME HIDING IS NOT IN EFFECT SECURITY LABEL BY SYSTEM IS NOT IN EFFECT PRIMARY LANGUAGE DEFAULT : ENU SECONDARY LANGUAGE DEFAULT : ENU 30 DAYS.

Analizaremos a continuacin el significado de las distintas opciones. 5.4 - Estadsticas iniciales Sintaxis: SETROPTS|SETR INITSTATS|NOINITSTATS Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: INITSTATS. El parmetro INITSTATS indica que RACF guardar, en el perfil de cada usuario, las siguientes estadsticas bsicas: Da y hora de la ltima vez que RACF verific la identidad del usuario, valor que normalmente coincide con el da y la hora de su ltimo logon (campo LAST-ACCESS en la salida del comando LISTUSER). Da y hora de la ltima vez que RACF verific la identidad del usuario para cada uno de los grupos a los que se encuentra conectado (campo LAST-CONNECT en la salida del comando LISTUSER).

Apuntes de RACF

Juan Mautalen

60 Cantidad de veces que RACF verific la identidad del usuario para cada grupo a los que se encuentra conectado (campo CONNECTS en la salida del comando LISTUSER). Recordemos que los campos LAST-CONNECT y CONNECTS solo se actualizan para el grupo default, salvo que se especifique uno distinto en la pantalla de logon de la aplicacin si lo permitiera-. Varias otras opciones de la SETROPTS solo funcionan si INITSTATS est vigente (INACTIVE, REVOKE, HISTORY, WARNING). Es absolutamente recomendable tener la opcin INITSTATS, que por otro lado es la que viene por defecto en una base recin inicializada. NOINITSTATS establece que RACF no guardar la informacin detallada previamente. 5.5 - Control de programas Sintaxis: SETROPTS|SETR WHEN(PROGRAM)|NOWHEN(PROGRAM) Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: WHEN(PROGRAM) El operando WHEN(PROGRAM) especifica que RACF activar el control de programas a travs de perfiles en la clase PROGRAM. Este control se activa exclusivamente de este modo, siendo irrelevante que la clase PROGRAM se encuentre o no activa. Esta es una particularidad de la clase PROGRAM, que resulta peculiar en varios aspectos ms. NOWHEN(PROGRAM) es la opcin por defecto en una base recin inicializada. Sin embargo, es conveniente cambiar este parmetro y tener activo el control de programas (solo es necesario definir perfiles en la clase PROGRAM para aquellos programas que se necesite efectivamente controlar). En un captulo posterior analizaremos con un poco ms de detalle el funcionamiento y alcance de la clase PROGRAM. 5.6 - Terminales no protegidas Sintaxis: SETROPTS|SETR TERMINAL(NONE|READ) Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: TERMINAL(READ) Esta opcin establece el UACC que asignar RACF a terminales que no estn protegidas por ningn perfil en la clase TERMINAL (o su agrupadora, GTERMINL). Slo tiene efecto si la clase TERMINAL se encuentra activa, es decir si RACF est verificando efectivamente la autorizacin de usuarios sobre el uso de terminales. El valor por defecto en una base recin inicializada es READ. Si se pretende especificar TERMINAL(NONE), debe estarse completamente seguro de que toda terminal tiene un perfil protector con una adecuada lista de acceso. Usualmente, un control tan estricto no es necesario, y el valor NONE puede resultar contraproducente. Aconsejamos el valor READ. 5.7 - Auditora de usuarios con atributo SPECIAL Sintaxis: SETROPTS|SETR SAUDIT|NOSAUDIT Autoridad requerida: AUDITOR a nivel de sistema Opcin sugerida: SAUDIT

Apuntes de RACF

Juan Mautalen

61 SAUDIT, que significa special audit, indica que para todos los usuarios con atributo SPECIAL (tanto a nivel de sistema como a nivel de grupo) se grabarn registros tipo 80 de SMF cada vez que ejecuten exitosamente comandos de RACF (con excepcin de los comandos LISTUSER, LISTGROUP, LISTDSD, RLIST y SEARCH, que nunca se registran ya que no se consideran crticos pues no realizan ninguna modificacin). SAUDIT es la opcin en efecto en una base recin inicializada. Como los usuarios con atributo SPECIAL tienen un enorme poder dentro de la organizacin, y deben ser pocos, resulta aconsejable monitorear detalladamente su actividad, por lo cual aconsejamos especificar SAUDIT. 5.8 - Auditora de violacin de comandos Sintaxis: SETROPTS|SETR CMDVIOL|NOCMDVIOL Autoridad requerida: AUDITOR a nivel de sistema Opcin sugerida: CMDVIOL CMDVIOL, que significa command violation, indica que se grabarn registros tipo 80 de SMF cada vez que se intente ejecutar un comando de RACF que resulte fallido por carecer el usuario de la autoridad necesaria (con excepcin de los comandos LISTUSER, LISTGROUP, LISTDSD, RLIST y SEARCH, cuyas ejecuciones fallidas no se registran). CMDVIOL es la opcin en efecto en una base recin inicializada. Los intentos fallidos de ejecucin de comandos de RACF deben ser analizados. Si se trata de un comando que corresponde, debe otorgarse al usuario la autoridad necesaria para que pueda ejecutarlo exitosamente. Si, en cambio, se trata de un usuario que intenta ejecutar un comando de RACF que no le compete, deben tomarse las medidas que se consideren convenientes. En cualquier caso, la cantidad de comandos fallidos de RACF no debera ser elevada. 5.9 - Auditora de usuarios con atributo OPERATIONS Sintaxis: SETROPTS|SETR OPERAUDIT|NOOPERAUDIT Autoridad requerida: AUDITOR a nivel de sistema Opcin sugerida: sin sugerencia OPERAUDIT, que significa operations audit, indica que para todos los usuarios con atributo OPERATIONS (tanto a nivel de sistema como a nivel de grupo) se grabarn registros tipo 80 de SMF en las siguientes situaciones: Acceso exitoso a un recurso protegido posibilitado por el atributo OPERATIONS. Ejecucin exitosa de los comandos ADDSD y RDEFINE posibilitada por el atributo OPERATIONS. Definicin de un nuevo recurso cuya creacin est controlada por RACF (la alocacin de un nuevo dataset, por ejemplo) y que resulte exitosa gracias al atributo OPERATIONS. Por ejemplo, supongamos que est OPERAUDIT en efecto, que el usuario USUA tiene el atributo OPERATIONS a nivel de sistema y que intenta modificar un archivo protegido por el perfil PROD.** que tiene UACC(NONE). - Si USUA figura en la lista de acceso de PROD.** con autoridad UPDATE (o superior), el acceso resulta exitoso, no por el atributo OPERATIONS, sino por su presencia en la lista de acceso. Por lo tanto, en este caso, el parmetro OPERAUDIT no provocar la grabacin de un registro de auditora.

Apuntes de RACF

Juan Mautalen

62 - Si ni USUA ni ninguno de los grupos a los que est conectado figura en la lista de acceso de PROD.** (ni existe una regla en la GLOBAL que posibilite el acceso), entonces el acceso resultar exitoso debido a la autoridad ALTER que otorga implcitamente el atributo OPERATIONS sobre el perfil PROD.**. Por lo tanto, el parmetro OPERAUDIT provocar la grabacin de un registro de auditora reflejando el evento. NOOPERAUDIT es la opcin en efecto en una base recin inicializada. Como ya hemos sealado, no es aconsejable tener en la base usuarios con el atributo OPERATIONS. Sin embargo, si la organizacin decide lo contrario, debe tenerse en cuenta que un usuario con este atributo y una intensa actividad (por ejemplo, el usuario asociado al DFHSM), puede generar un volumen enorme de registros de SMF. En tal caso, NOOPERAUDIT sera lo ms apropiado. En cambio, si existen pocos usuarios con el atributo OPERATIONS y su actividad es reducida, monitorearlos a travs de la opcin OPERAUDIT puede ser una buena idea. 5.10 - Clases con estadsticas Sintaxis: SETROPTS|SETR {STATISTICS|NOSTATISTICS}(clase|*) Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: NOSTATISTICS para todas las clases Se puede especificar con el operando STATISTICS|NOSTATISTICS la clase DATASET o cualquier otra clase definida en la CDT. Si se codifica *, todas las clases resultan afectadas (con excepcin de las clases USER y GROUP). Si una clase est bajo STATISTICS, RACF mantendr un determinado conjunto de estadsticas para sus perfiles discretos. En tal caso, en cada perfil discreto se almacenar la siguiente informacin: - Cantidad de veces que se accedi al recurso para cada nivel de autoridad. - Fecha de la ltima referencia. - Fecha de la ltima modificacin. - Para cada entrada en la lista de acceso, la cantidad de veces que se otorg acceso al recurso. Tales estadsticas nunca se mantienen para perfiles genricos. No deben confundirse estas estadsticas con aquellas a las que se refiere la opcin INITSTATS que analizamos previamente. Los operandos STATISTICS y NOSTATISTICS afectan no solo a la clase especificada sino tambin a todas aquellas otras que eventualmente compartan el mismo posit value. El mantenimiento de estadsticas, cuando la cantidad de perfiles discretos es importante, afecta la performance negativamente. Por lo tanto, salvo que exista una fuerte necesidad de contar con dicha informacin, resulta aconsejable no tener ninguna clase bajo STATISTICS. 5.11 - Clases auditadas Sintaxis: SETROPTS|SETR {AUDIT|NOAUDIT}(clase|*) Autoridad requerida: AUDITOR a nivel de sistema Opcin sugerida: AUDIT para todas las clases, activas o no, con excepciones muy puntuales Se puede especificar con el operando AUDIT|NOAUDIT las clases USER, GROUP, DATASET o cualquier otra clase definida en la CDT. Si se codifica *, todas las clases resultan afectadas. Si una clase tiene AUDIT, entonces se generarn registros de SMF cada vez que se ejecute un comando de RACF que afecte perfiles de esa clase (con excepcin de los comandos que nicamente listan
Apuntes de RACF Juan Mautalen

63 informacin). Tambin grabarn registros las solicitudes de DEFINE para esa clase (por ejemplo, si est la clase DATASET bajo AUDIT, toda alocacin de un nuevo archivo). Para los usuarios con atributo SPECIAL, el ya mencionado parmetro SAUDIT provoca la generacin de registros de SMF toda vez que ejecutan comandos de RACF. Si la clase a la que pertenece el perfil afectado est bajo AUDIT, no se generarn dos registros distintos por el mismo evento, sino que se grabar un nico registro. No debe pues temerse la redundancia que pueden presentar los parmetros SAUDIT, OPERAUDIT y AUDIT usados conjuntamente, ya que no aumentan la cantidad de registros de grabados. Los operandos AUDIT y NOAUDIT afectan no solo a la clase especificada sino tambin a todas aquellas otras que eventualmente compartan el mismo posit value. Recomendamos tener bajo AUDIT a todas las clases de RACF. Recordemos que, si una determinada clase no se encuentra activa, RACF no la utiliza para controlar accesos a recursos, pero ello no significa de ninguna manera que no se puedan definir, modificar o borrar perfiles. Por lo tanto, con el objeto de monitorear toda modificacin sobre la base de RACF, es conveniente auditar todas las clases, lo cual se logra de manera sencilla ejecutando el comando: SETROPTS AUDIT(*) La nica excepcin que creemos debera valorarse es el caso de las clases relacionadas con auditora de actividad en z/OS USS (Unix System Services), pues pueden generar un gran volumen de registros de poca utilidad (Ej: FSOBJ, IPCOBJ y PROCESS). Para ellas, luego de ejecutado el comando anterior, puede sacrselas de la categora AUDIT mediante el comando SETROPTS NOAUDIT(clase). En una base de RACF recin inicializada, est en efecto la opcin NOAUDIT(*), lo cual significa que ninguna clase est bajo AUDIT. Esto debera modificarse antes de empezar a utilizar el sistema para tareas productivas. 5.12 - Clases activas Sintaxis: SETROPTS|SETR {CLASSACT|NOCLASSACT}(clase|*) Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: depende de cada organizacin Se puede especificar con el operando CLASSACT|NOCLASSACT cualquier clase de recursos generales. Las clases USER, GROUP y DATASET se encuentran siempre activas y no se las puede desactivar. nicamente si una determinada clase se encuentra activa RACF utilizar sus perfiles para controlar el acceso a recursos. Es decir, a los efectos del chequeo de autoridad de un usuario sobre un recurso, una clase inactiva no cumple ninguna funcin. Los operandos CLASSACT y NOCLASSACT afectan no solo a la clase especificada sino tambin a todas aquellas otras que eventualmente compartan el mismo posit value. Es recomendable tener activas solo las clases que resulten importantes para la organizacin, las cules son usualmente muchas menos que las ms de 230 provistas por IBM. Alrededor de 60 clases activas suele ser suficiente para una organizacin promedio. Toda clase tiene asociado un DFTRETC (Default Return Code) especificado en la CDT, que puede ser 0, 4 u 8. Este valor indica el cdigo de retorno que RACF devolver a la aplicacin solicitante en caso de no encontrar un perfil que proteja el recurso en cuestin (suponiendo que la clase se encuentre activa). Su significado es el siguiente:

Apuntes de RACF

Juan Mautalen

64

0 4 8

El requerimiento de acceso se acepta Se informa a la aplicacin que no existe perfil protector El requerimiento de acceso se rechaza

En cualquier caso, recordemos que es siempre la aplicacin la que autoriza o rechaza una solicitud de acceso. An cuando reciba un cdigo de retorno 0 u 8, la aplicacin puede no cumplir con las directivas de RACF (aunque esto es muy poco frecuente). La mayora de las clases tienen un DFTRETC igual a 4, con lo cual la inexistencia de un perfil protector del recurso deja en manos de la aplicacin la decisin de otorgar o rechazar el pedido de acceso. Existen algunas clases cuyo DFTRETC es 8 (JESSPOOL, por ejemplo). En tales casos, si la clase est activa, aquellos recursos no protegidos resultan inaccesibles. Activar una clase con DFTRETC igual a 8, sin antes definir adecuadamente todos los perfiles necesarios, puede acarrear graves inconvenientes de acceso. Por tal motivo, RACF emite el siguiente mensaje informativo al momento de su activacin: ICH14073I WARNING: Class class-name was activated by the SETROPTS command. Authorization checks might fail. El comando SETROPTS CLASSACT(*) activa todas las clases con excepcin de aquellas cuyo DFTRETC sea igual a 8. En cambio, el comando SETROPTS NOCLASSACT(*) inactiva todas las clases, independientemente de su DFTRETC (con excepcin de USER, GROUP y DATASET). En cualquier caso, activar una clase es una accin de suma importancia, y no debe hacerse sin tener bien en claro su funcionamiento y alcance. En una base recin inicializada, est en efecto la opcin NOCLASSACT(*), lo cual significa que ninguna clase est activa (con excepcin, claro est, de USER, GROUP y DATASET). Por lo tanto, antes de empezar a utilizar el sistema para tareas productivas, deben definirse los perfiles apropiados y activar las clases necesarias. 5.13 - Clases con perfiles genricos Sintaxis: SETROPTS|SETR {GENERIC|NOGENERIC}(clase|*) Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: depende de cada organizacin Se puede especificar con el operando GENERIC|NOGENERIC la clase DATASET o cualquier clase de recursos generales, excepto las clases agrupadoras (GDASDVOL o GTERMINL, por ejemplo) y aquellas que, segn su definicin en la CDT, no admitan perfiles genricos (SECLABEL, por ejemplo). La opcin GENERIC para una clase indica que RACF tendr en cuenta sus eventuales perfiles genricos para responder sobre un requerimiento de acceso. Naturalmente, tambin utilizar los perfiles discretos que existan. En cambio, la opcin NOGENERIC significa que RACF no considerar sus perfiles genricos a la hora de decidir sobre un requerimiento de acceso. Por lo tanto, en este caso, los eventuales perfiles genricos de la clase no cumplen funcin alguna en el momento de otorgar o denegar una solicitud de acceso. Los operandos GENERIC y NOGENERIC afectan no solo a la clase especificada sino tambin a todas aquellas otras que eventualmente compartan el mismo posit value (con excepcin de las eventuales clases agrupadoras). En una base de RACF recin inicializada, est en efecto la opcin NOGENERIC(*), lo cual significa que para ninguna clase se toman en cuenta perfiles genricos para decidir sobre requerimientos de
Apuntes de RACF Juan Mautalen

65 acceso. Siempre que sea posible utilizarlos, los perfiles genricos facilitan la administracin. Por lo tanto, se aconseja especificar GENERIC para todas las clases activas que admitan perfiles genricos. 5.14 - Clases con comandos genricos Sintaxis: SETROPTS|SETR {GENCMD|NOGENCMD}(clase|*) Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: depende de cada organizacin, pero las mismas que bajo GENERIC Se puede especificar con el operando GENCMD|NOGENCMD la clase DATASET o cualquier clase de recursos generales, excepto las clases agrupadoras (GDASDVOL o GTERMINL, por ejemplo) y aquellas que, segn su definicin en la CDT, no admitan perfiles genricos (SECLABEL, por ejemplo). La opcin GENCMD para una clase indica que RACF permitir procesar comandos que afecten a sus perfiles genricos. A veces resulta necesario desactivar momentneamente el chequeo de perfiles genricos para determinada clase, pero mantener al mismo tiempo la posibilidad de definir, modificar o deletear perfiles genricos existentes. En tal caso, el comando SETROPTS NOGENERIC(clase) GENCMD(clase) permite realizar las tareas de mantenimiento deseadas. Si se especifica GENERIC para una clase, automticamente se le aplica tambin el operando GENCMD. Por el contrario, si se codifica la opcin NOGENERIC, NOGENCMD no se aplica de manera automtica. En una situacin normal, el listado de clases bajo GENERIC y GENCMD debera ser idntico. Los operandos GENCMD y NOGENCMD afectan no solo a la clase especificada sino tambin a todas las otras que eventualmente compartan el mismo posit value (con excepcin de las eventuales clases agrupadoras). En una base de RACF recin inicializada, est en efecto la opcin NOGENCMD(*). Se aconseja especificar GENCMD para todas las clases activas que admitan perfiles genricos. 5.15 - Clases con perfiles genricos compartidos en memoria (GENLISTeadas) Sintaxis: SETROPTS|SETR {GENLIST|NOGENLIST}(clase) Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: ninguna clase La opcin GENLIST establece que los perfiles genricos de la clase se cargarn en memoria, en un espacio compartido accesible por las distintas aplicaciones. En efecto, en lugar de existir una copia del perfil genrico en cada address space que lo requiera, se lo copiar a un sector comn de la memoria la primera vez que se lo necesite, y permanecer all de modo que cualquier otra aplicacin pueda utilizarlo sin tener que extraerlo nuevamente de la base. Esto no solo ahorra espacio en memoria sino que eventualmente mejora la performance, ya que resulta mucho ms rpido acceder a un perfil en memoria que buscarlo en la base de RACF residente en disco a travs de un costoso I/O. En contrapartida, cada vez que se modifique un perfil genrico de la clase bajo GENCMD, ser necesario reemplazar la versin desactualizada almacenada en memoria mediante la ejecucin del comando: SETROPTS GENERIC(clase) REFRESH No todas las clases admiten esta opcin, y la misma es excluyente con la opcin RACLIST que veremos a continuacin. En la CDT est indicado qu clases admiten este parmetro. Usualmente, las clases tienen definidos tanto perfiles genricos como discretos, en cuyo caso suele ser mas ventajoso, si es posible, RACLISTearlas en lugar de ponerlas bajo GENLIST. En virtud de esto, resulta frecuente no tener ninguna clase GENLISTeada.

Apuntes de RACF

Juan Mautalen

66 Los operandos GENLIST y NOGENLIST afectan no solo a la clase especificada, sino tambin a todas las otras que tengan el mismo posit value y sean pasibles de ser GENLISTeadas. En una base de RACF recin inicializada, est en efecto la opcin NOGENLIST(*), es decir que ninguna clase se encuentra bajo GENLIST. 5.16 - Clases en la GLOBAL Sintaxis: SETROPTS|SETR {GLOBAL|NOGLOBAL}(clase|*) Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: DATASET + otras que la organizacin considere apropiadas Se puede especificar con el operando GLOBAL|NOGLOBAL la clase DATASET o cualquier clase de recursos generales, excepto las clases agrupadoras (GDASDVOL o GTERMINL, por ejemplo). Si una clase est bajo GLOBAL en la SETROPTS, ello significa que RACF utilizar la informacin del perfil correspondiente de la clase GLOBAL para eventualmente otorgar un acceso solicitado. Veremos de manera precisa en un captulo posterior de qu manera acta la clase GLOBAL en el proceso de chequeo de autoridad de un usuario sobre un recurso. Los operandos GLOBAL y NOGLOBAL afectan no solo a la clase especificada sino tambin a todas aquellas otras que tengan idntico posit value (con excepcin de las eventuales clases agrupadoras). En una base de RACF recin inicializada, est en efecto la opcin NOGLOBAL(*), es decir que para ninguna clase RACF procesa la informacin de la GLOBAL. Es altamente recomendable tener al menos la clase DATASET bajo GLOBAL, ya que existen seguramente archivos de uso pblico muy frecuente (catlogos de usuario, por ejemplo), en cuyo caso una regla apropiada en la GLOBAL puede mejorar sensiblemente la performance. 5.17 - Clases con perfiles genricos y discretos compartidos en memoria RACLISTeadasSintaxis: SETROPTS|SETR {RACLIST|NORACLIST}(clase) Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: todas las clases activas que lo admitan (salvo que sean de muy poco uso) La opcin RACLIST establece que los perfiles genricos y discretos de la clase se cargarn en memoria, en un sector compartido (data space) que estar disponible para las distintas aplicaciones. Como ya mencionramos, para una clase dada, RACLIST y GENLIST son operandos excluyentes. Slo las clases que tienen RACLIST=ALLOWED especificado en la CDT pueden ser RACLISTeadas. No se puede especificar RACLIST para una clase agrupadora (GCICSTRN o VCICSCMD, por ejemplo). De todos modos, si la correspondiente clase de miembros (member class) est RACLISTeada, al cargarse la informacin de sus perfiles en memoria sta se combina con la contenida en los perfiles de la clase agrupadora. Esto se analizar en detalle en un captulo posterior. Cada vez que se modifique un perfil -genrico o discreto- de una clase RACLISTeada, ser necesario actualizar la informacin almacenada en memoria ejecutando el comando: SETROPTS RACLIST(clase) REFRESH De todos modos, RACF informa con un mensaje por pantalla que los cambios no sern reflejados hasta que el comando de REFRESH haya sido ejecutado. An si se modific informacin de un perfil de una clase agrupadora, el comando de REFRESH debe ejecutarse especificando la clase de miembros.

Apuntes de RACF

Juan Mautalen

67 Los operandos RACLIST y NORACLIST afectan no solo a la clase especificada, sino tambin a todas las otras que eventualmente compartan el mismo posit value (y sean pasibles de ser RACLISTeadas). Las siguientes clases provistas por IBM, en caso de estar activas, deben obligatoriamente estar RACLISTeadas: APPCSERV APPCTP CSFKEYS CSFSERV DEVICES DIGTNMAP FIELD IDIDMAP NODES OPERCMDS PROPCNTL PSFMPL PTKTDATA RACFVARS SECLABEL SERVAUTH STARTED SYSMVIEW UNIXPRIV VTAMAPPL

Adicionalmente, IBM recomienda RACLISTear las siguientes clases, suponiendo que estn activas: ACCTNUM APPL CDT CONSOLE DASDVOL DIGTCERT DIGTCRIT DIGTRING DSNR FACILITY JESJOBS JESPOOL LDAPBIND MGMTCLAS PERFGRP PTKTVAL PRINTSRV RRSFDATA SDSF STORCLAS SURROGAT TERMINAL TSOAUTH TSOPROC WRITER

En cuanto al resto de las clases activas y factibles de ser RACLISTeadas, el hacerlo o no es una decisin que debe tomar cada organizacin. Si se trata de una clase con muy poca actividad, no se gana demasiado RACLISTendola (aunque tampoco resultara perjudicial hacerlo, de no ser por la necesidad de refrescar los perfiles cada vez que se efecta alguna modificacin). En cambio, si se trata de una clase con perfiles utilizados con relativa frecuencia, resulta sin duda conveniente RACLISTearla. En una base de RACF recin inicializada ninguna clase est RACLISTeada. Esta configuracin inicial debe cambiarse de acuerdo a lo sealado en el prrafo anterior. 5.18 - Clases RACLISTeadas va RACROUTE REQUEST=LIST, GLOBAL=YES Si observamos la salida del comando SETROPTS LIST, vemos que a continuacin del listado de las clases RACLISTeadas con el comando SETROPTS RACLIST(clase), aparece un listado de clases bajo el rtulo GLOBAL=YES RACLIST ONLY. En el ejemplo que nos ocupa, figuran all las clases TCICSTRN y CCICSCMD, ambas relacionadas con CICS. Estas clases no han sido RACLISTeadas por un administrador de RACF con atributo SPECIAL, sino que las ha RACLISTeado alguna aplicacin que las utiliza. En nuestro ejemplo, la primera regin CICS que se levanta se encarga de RACLISTear ambas clases. Si se ejecutara el comando SETROPTS LIST en un momento en que ninguna regin CICS se encuentre activa, entonces ninguna de estas clases aparecera RACLISTeada. Mas all de esta diferencia, las clases RACLISTeadas de este modo se comportan de manera idntica a aquellas que lo han sido a travs del comando SETROPTS RACLIST(clase). Una diferencia que vale la pena mencionar es que, para las clases bajo GLOBAL=YES RACLIST ONLY, RACF no informa la necesidad de ejecutar el comando de REFRESH si se quiere que tome efecto una modificacin, como s lo hace en el caso de aquellas RACLISTeadas por comando.

Apuntes de RACF

Juan Mautalen

68 5.19 - Opciones de logging para clases Sintaxis: SETROPTS|SETR LOGOPTIONS(nivel(clase)...) Autoridad requerida: AUDITOR a nivel de sistema Opcin sugerida: todas las clases con LOGOPTIONS en DEFAULT Se puede especificar con el operando LOGOPTIONS la clase DATASET o cualquier otra definida en la CDT. Los posibles niveles son: ALLWAYS NEVER SUCCESSES FAILURES DEFAULT El nivel especificado determina qu tipo de intentos de acceso se pretende registrar en SMF. Su significado es el siguiente: ALLWAYS indica que todo acceso a un recurso, exitoso o fallido, que involucre la consulta de un perfil de la clase, generar un registro de auditora. ALLWAYS tiene prioridad sobre la configuracin de auditora que tenga cada perfil. Por lo tanto, aunque un determinado perfil tenga especificado nicamente FAILURES(READ) como opcin de auditora, si la clase se encuentra bajo LOGOPTIONS(ALLWAYS), se grabarn registros an para los accesos exitosos (a cualquier nivel). NEVER establece que ningn acceso que involucre la consulta de un perfil de la clase generar un registro de auditora. NEVER tiene prioridad sobre la configuracin de auditora a nivel de perfil. Por lo tanto, no se grabar ningn registro, an cuando los perfiles tengan opciones de auditora que indiquen lo contrario. SUCCESSES indica que se generar un registro auditorapor cada acceso exitoso que involucre la consulta de un perfil de la clase. En este caso, este nivel de auditora se agrega al que ya tiene especificado el perfil. Por ejemplo, si un perfil tiene especificado nicamente FAILURES(UPDATE) y la clase est bajo LOGOPTIONS(SUCCESSES), se generarn registros para todo acceso exitoso y los intentos fallidos de UPDATE (o superior). FAILURES determina que se generar un registro de auditora por cada acceso fallido que involucre la consulta de un perfil de la clase. En este caso, al igual que para SUCCESSES, este nivel de auditora se agrega al propio del perfil. Por ejemplo, si un perfil tiene especificado nicamente SUCCESS(UPDATE) y la clase est bajo LOGOPTIONS(FAILURES), se generarn registros para todo acceso fallido y todo intento exitoso de UPDATE (o superior). DEFAULT indica que el nivel de auditora sobre un recurso estar dado por el establecido en su perfil protector. Cada clase puede tener un nico nivel de LOGOPTIONS. Por lo tanto, para cambiar el nivel de una determinada clase, basta con asignarle el nuevo. El operando LOGOPTIONS afecta no solo a la clase especificada, sino tambin a todas aquellas otras que eventualmente compartan el mismo posit value. En una base recin inicializada, todas las clases se encuentran bajo LOGOPTIONS(DEFAULT). Recomendamos mantener esta configuracin, y controlar el nivel de auditora a travs de las opciones propias de los perfiles. Una excepcin son ciertas clases relacionadas con z/OS USS, que si bien no admiten perfiles, permiten controlar, a travs de la SETROPTS, el nivel de auditora sobre ciertos eventos (en algunos casos al
Apuntes de RACF Juan Mautalen

69 ponerlas bajo AUDIT, y en otros mediante LOGOPTIONS). Por ejemplo, la clase FSSEC permite auditar las modificaciones sobre los permisos de archivos y directorios del z/OS USS. Especificar LOGOPTIONS(ALLWAYS) para FSSEC podra ser, por lo tanto, una opcin a considerar. 5.20 - Proteccin automtica de datasets Sintaxis: SETROPTS|SETR ADSP|NOADSP Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: NOADSP La opcin NOADSP de la SETROPTS establece que RACF no aplicar la proteccin automtica de datasets an para aquellos usuarios que tengan el atributo ADSP (a nivel de sistema o a nivel de grupo). En este caso, el listado de la SETROPTS muestra la leyenda:
AUTOMATIC DATASET PROTECTION IS NOT IN EFFECT

Por el contrario, la opcin ADSP en la SETROPTS indica que la proteccin automtica de datasets est globalmente activa, pero solo ser aplicada para los usuarios que tengan efectivamente el atributo ADSP. Por lo tanto, si ningn usuario tiene el atributo ADSP, las opciones ADSP|NOADSP a nivel de la SETROPTS resultan equivalentes. En una base recin inicializada, se encuentra activa la opcin ADSP. Debido a la ya comentada tendencia a utilizar exclusivamente perfiles genricos de dataset, recomendamos cambiarla por NOADSP. Esto elimina de raz la posibilidad de que algn usuario genere de manera automtica perfiles discretos. 5.21 - Uso del ** en perfiles genricos de dataset Sintaxis: SETROPTS|SETR EGN|NOEGN Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: EGN EGN significa Enhanced Generic Naming, y se refiere a la posibilidad de emplear el smbolo ** en perfiles de dataset (y entradas en la GLOBAL para reglas de DATASET). La opcin EGN|NOEGN afecta nicamente a la clase DATASET. El uso del ** en perfiles de recursos generales est siempre permitido y no guarda ninguna relacin con este parmetro. Como ya hemos sealado, el uso del ** hace realmente ms cmoda la administracin de perfiles genricos de dataset, por lo cual recomendamos activar la opcin EGN. En el caso de estar en efecto la opcin NOEGN, el significado del * en perfiles genricos de dataset vara con respecto al que tiene cuando EGN est activa (no entraremos en detalles al respecto). En cualquier caso, si se han definido perfiles conteniendo ** (con la opcin EGN activa, naturalmente), debe tenerse cuidado en no cambiar con posterioridad a la opcin NOEGN, ya que ello provocara sin duda problemas y confusin en la proteccin de datasets. La opcin EGN activa en la SETROPTS se manifiesta a travs de la siguiente leyenda:
ENHANCED GENERIC NAMING IS IN EFFECT

En una base recin inicializada, se encuentra en efecto la opcin NOEGN. Resulta conveniente modificar esta opcin.

Apuntes de RACF

Juan Mautalen

70 5.22 - Nombres reales de dataset Sintaxis: SETROPTS|SETR REALDSN|NOREALDSN Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: REALDSN Ya sea a travs de la implementacin de una tabla de convencin de nombres (naming convention table) o mediante la implementacin de una exit apropiada, se puede convertir el nombre real de un archivo antes de que sea pasado a RACF. Esto permite, por ejemplo, proteger archivos cuyos nombres reales no tengan una nomenclatura admitida por RACF. La opcin REALDSN establece que, tanto en los registros de SMF como en los mensajes de operador, se mostrar el nombre real del archivo, an cuando el mismo haya sido modificado a los efectos del chequeo de autoridad. Por el contrario, si la opcin en efecto es NOREALDSN, el nombre mostrado en ambos casos no ser el real sino el modificado que recibe RACF. A menos que exista una fuerte necesidad al respecto, no se aconseja de ninguna manera convertir los nombres de los archivos que se le comunican a RACF, ya que ello complica la administracin. La opcin REALDSN activa en la SETROPTS se manifiesta a travs de la siguiente leyenda:
REAL DATA SET NAMES OPTION IS ACTIVE

En una base recin inicializada, se encuentra en efecto la opcin NOREALDSN. Aconsejamos cambiar por la opcin REALDSN, an cuando esto resulta irrelevante si la organizacin, tal como recomendamos, no utiliza una tabla de convencin de nombres o exits que modifiquen, con miras al chequeo de seguridad, el nombre real de los archivos. 5.23 - Opciones relativas a JES Sintaxis: SETROPTS|SETR JES([BATCHALLRACF|NOBATCHALLRACF] [EARLYVERIFY|NOEARLYVERIFY] [XBMALLRACF|NOXBMALLRACF] [NJEUSERID(userid)] [UNDEFINEDUSER(userid)]) Autoridad requerida: SPECIAL a nivel de sistema Opciones sugeridas: BATCHALLRACF, EARLYVERIFY, XBMALLRACF, usuarios por defecto Existen varias opciones en la SETROPTS relativas a JES, que describimos brevemente a continuacin: BATCHALLRACF exige que todo job batch tenga una identidad vlida. A tal efecto, caben las siguientes posibilidades: La tarjeta job contiene explcitamente usuario y password. Esta opcin es poco recomendable, ya que debe evitarse la exposicin de passwords en texto claro. Las credenciales se reciben propagadas, por ejemplo al utilizar el comando SUBMIT de TSO. Se trata de la opcin ms frecuente. La tarjeta job solo tiene especificado usuario, y quin submite tiene la autorizacin apropiada en la clase SURROGAT para ejecutar jobs en nombre del usuario de ejecucin. Si el job no tiene una identidad vlida de RACF, entonces cancela. Si NOBATCHALLRACF est en efecto, la ausencia de un usuario no impide que el job se ejecute. Naturalmente, es probable que encuentre problemas de autorizacin si trata de acceder a recursos
Apuntes de RACF Juan Mautalen

71 protegidos para los cuales ni la GLOBAL ni el UACC del perfil protector son suficientes para otorgar el acceso solicitado. EARLYVERIFY hace referencia a un control de usuario, password y grupo que efecta JES invocando a la SAF en caso de no recibir informacin propagada. Con las versiones actuales de JES esto se realiza siempre, independientemente de la codificacin de este parmetro en la SETROPTS. Por lo tanto, EARLYVERIFY|NOEARLYVERIFY se ha convertido en una opcin irrelevante. XBMALLRACF es idntico a BATCHALLRACF pero para jobs que se ejecutan bajo el Execution Batch Monitor. La opcin NJEUSERID define el usuario que se asignar a los jobs o sysouts que reciba el sistema y no tengan RTOKEN u UTOKEN. El valor por defecto en una base recin inicializada es ????????, el cual sugerimos conservar. En cualquier caso, si se desea cambiarlo, el usuario que se especifique no debe existir en la base de RACF. La opcin UNDEFINEDUSER establece el usuario que se asignar a los jobs locales que ingresen al sistema sin un usuario asociado. El valor por defecto en una base recin inicializada es ++++++++, el cual sugerimos conservar. En cualquier caso, si se desea cambiarlo, el usuario que se especifique no debe existir en la base de RACF. En una base recin inicializada, se encuentran en efecto las opciones NOBATCHALLRACF, NOEARLYVERIFY y NOXBMALLRACF. Recomendamos activar los 3 tipos de control (aunque en el caso de EARLYVERIFY, es actualmente irrelevante). En el listado de la SETROPTS, las leyendas:
JES-BATCHALLRACF OPTION IS ACTIVE JES-XBMALLRACF OPTION IS ACTIVE JES-EARLYVERIFY OPTION IS ACTIVE USER-ID FOR JES NJEUSERID IS : ???????? USER-ID FOR JES UNDEFINEDUSER IS : ++++++++

indican que los 3 tipos de control se encuentran activos y que se mantuvo el valor default para ambos usuarios. 5.24 - Protect-all Sintaxis: SETROPTS|SETR PROTECTALL(FAILURES|WARNING)|NOPROTECTALL Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: PROTECTALL(FAILURES) Se trata de una opcin sumamente importante, que establece cmo se comportar RACF cuando se pretenda definir o acceder a archivos no protegidos por ningn perfil de dataset. Este parmetro solo afecta a la clase DATASET. Existen 3 seteos posibles, que describimos a continuacin: PROTECTALL en FAILURES indica que RACF no permitir definir ni acceder a archivos que no se encuentre protegidos por algn perfil de dataset (los archivos temporarios generados por el sistema quedan exceptuados). Con esta configuracin, los datasets no protegidos resultan inaccesibles, salvo en alguna de las situaciones siguientes: El usuario tiene el atributo SPECIAL a nivel de sistema. En este caso, si bien se autoriza el acceso, se enva un mensaje al usuario informando que el archivo se encuentra desprotegido. El usuario no puede, sin embargo, definir archivos desprotegidos. El acceso lo solicita una started task que est marcada como TRUSTED o PRIVILEGED. En este caso, se autoriza el acceso pero no se enva ningn mensaje informativo. Existe una entrada en la GLOBAL que autoriza el acceso.

Apuntes de RACF

Juan Mautalen

72 PROTECTALL en WARNING funciona de manera similar al modo FAILURES, pero con una diferencia fundamental. RACF, en lugar de rechazar el pedido, lo autoriza y remite, tanto al usuario como al SYSLOG, un mensaje informando que archivo no se encuentra protegido. Se debe ser cuidadoso, ya que mientras RACF tiene PROTECTALL en modo WARNING, los archivos no protegidos pueden ser accedidos por cualquier usuario con el mximo nivel de autoridad. Sin embargo, esta opcin resulta sumamente til en las etapas iniciales de la construccin de la base de RACF, pues permite identificar e ir protegiendo paulatinamente los archivos en uso que se encuentran desprotegidos, sin causar interrupciones en las tareas. Luego de un tiempo prudencial, pasado el cual se estima que ya se han identificado todos los archivos en uso, se debe cambiar al modo FAILURES. NOPROTECTALL implica que cualquier usuario puede acceder a archivos no protegidos con el mximo nivel de autoridad, as como tambin definir nuevos archivos desprotegidos. A diferencia del modo WARNING, ningn mensaje de alerta es generado. Esta opcin es totalmente desaconsejada para un entorno productivo. En nuestro ejemplo, la leyenda:
PROTECT-ALL IS ACTIVE, CURRENT OPTIONS: PROTECT-ALL FAIL OPTION IS IN EFFECT

indica que est activa la opcin PROTECTALL en modo FAILURES. En una base recin inicializada, se encuentra vigente la opcin NOPROTECTALL. Se recomienda la opcin PROTECTALL en modo FAILURES, que robustece notablemente la seguridad del sistema. 5.25 - Proteccin de archivos en cartucho Sintaxis: SETROPTS|SETR TAPEDSN|NOTAPEDSN Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: NOTAPEDSN La opcin TAPEDSN indica que RACF controlar el acceso a archivos en cartuchos a travs de perfiles en la clase DATASET, de manera similar a como lo hace para datasets en disco. Existe una importante relacin entre esta opcin y la clase TAPEVOL, que debe estudiarse cuidadosamente para comprender exactamente su alcance. Sin embargo, no ahondaremos en ello en la presente gua. NOTAPEDSN establece que RACF no controlar el acceso a archivos en cartuchos mediante perfiles de dataset (excepto que se habilite este chequeo a travs del miembro DEVSUPxx de la PARMLIB). De todos modos, si el chequeo en la clase DATASET est inhibido, pueden protegerse globalmente los volmenes mediante perfiles en la clase TAPEVOL. En nuestro ejemplo, se encuentra establecida la opcin NOTAPEDSN, como muestra la siguiente leyenda en el listado de la SETROPTS:
TAPE DATA SET PROTECTION IS INACTIVE

En una base recin inicializada, se encuentra en efecto la opcin NOTAPEDSN. Recomendamos NOTAPEDSN, tener la clase TAPEVOL inactiva y habilitar el chequeo de autoridad sobre archivos en cartucho en la clase DATASET a travs de la configuracin del miembro DEVSUPxx residente en la PARMLIB. 5.26 - Perodo de retencin para archivos en cartucho Sintaxis: SETROPTS|SETR RETPD(valor) Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: depende de la organizacin
Apuntes de RACF Juan Mautalen

73 El perodo de retencin, solo aplicable a datasets en cartucho, determina la cantidad de das en que la proteccin permanecer vigente, contados desde el da de creacin del archivo. El valor establecido en la SETROPTS se aplicar por defecto, siempre que no se establezca un valor especfico para el archivo. Se puede codificar cualquier valor comprendido entre 0 y 65533, o el valor reservado 99999 que indica que la proteccin nunca expira. El RETPD especificado en la SETROPTS solo acta si se encuentra activa la opcin TAPEDSN. En caso contrario, resulta irrelevante. Si se activa TAPEDSN, y no se especifica un RETPD, el valor por defecto es 0. 5.27 - Borrado fsico de archivos Sintaxis: SETROPTS|SETR ERASE(ALL|SECLEVEL(nivel)|NOSECLEVEL)|NOERASE Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: ERASE(NOSECLEVEL) En general, cuando se elimina un archivo en disco, el sistema borra la entrada correspondiente de la VTOC del volumen dnde reside, al mismo tiempo que lo descataloga (o sea, elimina su entrada del catlogo dnde se est catalogado). El espacio ocupado por el archivo queda entonces disponible para un futuro dataset, o la extensin de uno existente. Sin embargo, hasta que efectivamente se grabe all nueva informacin, los datos del archivo deleteado siguen presentes, solo que no resultan accesibles por los medios habituales. Existe la posibilidad de tomar una medida de seguridad adicional, que garantice la irrecuperabilidad de los datos luego del borrado lgico del archivo, que consiste en fsicamente sobrescribirlo con ceros binarios. Sin embargo, esto resulta costoso, y puede degradar la performance, por lo cual solo estara justificado para el caso de informacin altamente sensible. La opcin ERASE de la SETROPTS permite establecer en qu casos se desea un borrado fsico de un archivo (solo se aplica a datasets en disco). Veremos a continuacin las distintas opciones posibles: ALL establece que se deben borrar fsicamente todos los archivos que se borren, independientemente de lo que indique el campo ERASE del perfil protector. Esto incluye tambin a los datasets temporarios. Se trata de una medida de seguridad extrema, que realmente no se justifica en absoluto y puede impactar negativamente en la performance del sistema. ERASE(SECLEVEL(nivel)) indica que se debe proceder al borrado fsico de todos aquellos archivos que se deletean y cuyo perfil protector tenga un SECLEVEL (security level) mayor o igual al especificado. En este caso, tambin resulta irrelevante el valor del campo ERASE del perfil de dataset. Si el perfil protector tiene especificado ERASE=YES pero su SECLEVEL es inferior al valor de la SETROPTS, el archivo no es borrado fsicamente al ser deleteado. Como no aconsejamos, para no complicar la administracin, el uso de niveles de seguridad, no recomendamos tampoco la implementacin de esta opcin. ERASE(NOSECLEVEL) indica que RACF no tendr en cuenta el SECLEVEL del perfil protector para determinar si debe procederse o no al borrado fsico del archivo. En cambio, el factor determinante para esta decisin pasa a ser el valor del campo ERASE del perfil. Recomendamos establecer esta opcin, y nicamente codificar ERASE=YES para perfiles de dataset que protejan archivos altamente confidenciales. Si se especifica ERASE sin ningn parmetro, el valor que asume por defecto es NOSECLEVEL. En nuestro ejemplo, sta es la opcin establecida, como lo muestra la leyenda:
ERASE-ON-SCRATCH IS ACTIVE, CURRENT OPTIONS: ERASE-ON-SCRATCH BY SECURITY LEVEL IS INACTIVE

Apuntes de RACF

Juan Mautalen

74 NOERASE indica que en ningn caso se proceder al borrado fsico de los archivos, independientemente del valor del campo ERASE del perfil protector. NOERASE es el valor que se encuentra vigente en una base de RACF recin inicializada. 5.28 - Archivos de un nico calificador Sintaxis: SETROPTS|SETR PREFIX(grupo)|NOPREFIX Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: NOPREFIX Si la opcin NOEGN se encuentra activa, RACF no permite proteger archivos que tengan un nico calificador. En tal caso, si la organizacin tiene tales archivos, existe la posibilidad de protegerlos especificando un PREFIX en la SETROPTS. Si la opcin EGN est activa, el dataset ARCH1 puede protegerse por el perfil genrico ARCH1.**, por lo cual no tiene sentido especificar un PREFIX en la SETROPTS. La opcin PREFIX(grupo) establece un prefijo que se antepondr como HLQ, solo a los efectos del chequeo por parte de RACF, para aquellos archivos que tengan un nico calificador. El valor especificado en el operando PREFIX debe ser un grupo existente en la base de RACF, y no deben existir ni archivos ni perfiles de dataset cuyo HLQ sea ese grupo. NOPREFIX no establece ningn prefijo. Como recomendamos tener la opcin EGN activa, sugerimos asimismo establecer NOPREFIX. En cualquier caso, no parece conveniente hacer uso de archivos que tengan un nico calificador, para evitar este tipo de disquisiciones. Esta es la opcin vigente en nuestro ejemplo, como lo muestra la leyenda:
SINGLE LEVEL NAMES NOT ALLOWED

NOPREFIX es asimismo el valor que se encuentra en efecto en una base de RACF recin inicializada. 5.29 - Lista de grupos Sintaxis: SETROPTS|SETR GRPLIST|NOGRPLIST Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: GRPLIST GRPLIST establece que, para determinar la autoridad de un usuario sobre un recurso, RACF no solo considerar el actual grupo de conexin del usuario sino todos los grupos a los cuales se encuentre conectado (con una conexin no revocada). Con esta opcin activa, el grupo de conexin, a los efectos del chequeo de autoridad, se vuelve bsicamente irrelevante. En consecuencia, el usuario no debe preocuparse por el grupo que especifica en la pantalla de logon a las aplicaciones. Es la opcin ampliamente preferida en la actualidad, ya que simplifica la tarea al usuario, sin resignar en absoluto aspectos de seguridad del sistema. En nuestro ejemplo, GRPLIST se encuentra en efecto, como se deduce de la leyenda siguiente:
LIST OF GROUPS ACCESS CHECKING IS ACTIVE

Si la opcin NOGRPLIST est activa, entonces solo el actual grupo de conexin del usuario es tenido en cuenta por RACF en el proceso de chequeo de autoridad. Antiguamente no exista la opcin GRPLIST, por lo que considero que se mantiene la posibilidad de establecer NOGRPLIST nicamente para mantener una compatibilidad hacia atrs, ya que realmente presenta varios inconvenientes y ninguna ventaja evidente. NOGRPLIST es la opcin que se encuentra en efecto en una base de RACF recin inicializada.
Apuntes de RACF Juan Mautalen

75 5.30 - Revocacin automtica por inactividad Sintaxis: SETROPTS|SETR INACTIVE(valor)|NOINACTIVE Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: INACTIVE(40) El valor codificado en el operando INACTIVE establece la cantidad consecutiva de das de inactividad pasados los cuales RACF revoca automticamente al usuario. Debe estar comprendido entre 1 y 255. El chequeo que lleva a cabo RACF es el siguiente: Cada vez que un usuario se loguea a alguna aplicacin (TSO, CICS, IMS, etc.), o se inicia la ejecucin de un job, RACF compara la fecha actual del sistema con la fecha que figura en el campo LASTACCESS del perfil del usuario. Si la diferencia entre ambas fechas excede el valor especificado para revocacin automtica por inactividad en la SETROPTS, entonces RACF revoca al usuario. Recordemos que el campo LAST-ACCESS del perfil del usuario puede modificarse, no solo mediante el logon efectivo del usuario, sino tambin en otras circunstancias, como ya viramos en el captulo de administracin de usuarios. RACF revoca al usuario por inactividad cuando efectivamente intenta acceder al sistema. Por ejemplo, si el parmetro INACTIVE especifica 30 das y un usuario lleva 31 das de inactividad, hasta tanto no intente ingresar no ser efectivamente revocado. Podramos decir que tal usuario se encuentra pendiente de revocacin. Para los usuarios que nunca ingresaron al sistema (el comando LISTUSER muestra LAST-ACCESS = UNKNOWN), la inactividad se calcula en relacin a la fecha de creacin. En nuestro ejemplo, el valor fijado es de 40 das, tal cual lo muestra la siguiente leyenda:
INACTIVE USERIDS ARE BEING AUTOMATICALLY REVOKED AFTER 40 DAYS.

NOINACTIVE establece que RACF no revocar usuarios automticamente por inactividad. Esta es la opcin vigente en una base recin inicializada. Recomendamos especificar la opcin INACTIVE, con una cantidad que sea adecuada a las necesidades de la organizacin. Un valor entre 30 y 60 das suele ser razonable. 5.31 - Modelizacin de perfiles de dataset Sintaxis: SETROPTS|SETR MODEL([GDG|NOGDG] [GROUP|NOGROUP] [USER|NOUSER])|NOMODEL Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: depende de cada organizacin Mediante el operando MODEL, se establece en qu casos se desea utilizar la modelizacin de perfiles de dataset. Esto permite que nuevos perfiles, al ser definidos, tomen las caractersticas de un perfil modelo existente. MODEL(GDG) establece que RACF intentar proteger miembros de un GDG (Generation Data Group) que estn RACF-indicados usando un perfil de dataset cuyo nombre coincida con el nombre base del GDG. Recomendamos la opcin NOGDG y proteger todos los GDG-datasets mediante un nico perfil genrico. MODEL(NOGDG) indica que RACF no tendr un tratamiento especial para los GDG-datasets, sino que los tratar del mismo modo que a cualquier otro archivo. MODEL(GROUP) establece que cada vez que se defina un perfil de dataset de grupo, RACF examirar el perfil del grupo para ver si tiene especificado un perfil modelo. En caso afirmativo, el nuevo perfil de dataset ser creado en base al modelo existente.
Apuntes de RACF Juan Mautalen

76 MODEL(NOGROUP) indica que no se aplicarn modelos para perfiles de dataset de grupo, an cuando el perfil del grupo correspondiente tenga un perfil modelo especificado. MODEL(USER) indica que cada vez que se defina un perfil de dataset de usuario, RACF examinar el perfil del usuario para ver si tiene especificado un perfil modelo. En tal caso, el nuevo perfil de dataset ser creado en base al modelo existente. MODEL(NOUSER) indica que no se aplicarn modelos para perfiles de dataset de usuario, an cuando el perfil del usuario correspondiente tenga un perfil modelo especificado. En nuestro ejemplo, establecimos que nicamente se aplique la modelizacin para perfiles de dataset de usuario, tal cual indica la leyenda siguiente:
DATA SET MODELLING NOT BEING DONE FOR GDGS. USER DATA SET MODELLING IS BEING DONE. GROUP DATA SET MODELLING NOT BEING DONE.

NOMODEL establece que no se aplicar modelizacin de perfiles de dataset en ninguno de los 3 casos (GDG, GROUP y USER). Esta es la opcin en efecto en una base recin inicializada. 5.32 - Opciones relativas a PASSWORD Sintaxis: SETROPTS|SETR PASSWORD([HISTORY(valor)|NOHISTORY] [INTERVAL(valor)] [MINCHANGE(valor)] .[MIXEDCASE)|NOMIXEDCASE] [REVOKE(valor)|NOREVOKE] [RULEn(LENGTH(min:max) tipo(posicin))|NORULEn|NORULES] [WARNING(valor)|NOWARNING] Autoridad requerida: SPECIAL a nivel de sistema Opciones sugeridas: HISTORY(15), INTERVAL(30), MINCHANGE(1), MIXEDCASE, REVOKE(5) LLLLLLLL, WARNING(5) La password de un usuario se almacena en su perfil, no en texto claro sino encriptado. Este campo no es visible en la salida del comando LISTUSER. Tampoco est presente en la bajada plana de la base que se obtiene a travs del utilitario IRRDBU00. Sin embargo, debe destacarse que RACF no encripta la password propiamente dicha. El valor guardado es el resultado de encriptar, va DES (Data Encryption Standard), el identificador de usuario, usando como clave de encriptacin su password. En el momento de autenticacin, RACF reencripta el usuario con la password recibida, y si el valor resultante coincide con el almacenado la autenticacin es exitosa. Este mecanismo tiene una consecuencia interesante: 2 usuarios con idntica password tendrn distintos valores guardados en la base de RACF. Por lo tanto, crackear la password de un usuario no significa que se haya igualmente crackeado a otros que puedan eventualmente tener su misma password. Vamos a describir a continuacin en detalle el significado de cada uno de los suboperandos del operando PASSWORD. Historial HISTORY establece la cantidad de passwords previas del usuario que se almacenan en la base con el objeto de que no las pueda reusar. Esto es -suponiendo que se tenga esta opcin en 15, como en nuestro ejemplo-, un usuario, al cambiar su password (ya sea voluntariamente, o porque RACF se lo exige), no podr especificar, ni la actual, ni ninguna de las ltimas 15 que haya utilizado. El valor del operando HISTORY debe estar comprendido entre 1 y 32.
Apuntes de RACF Juan Mautalen

77 Por una cuestin de seguridad, es importante utilizar esta opcin con el objeto de evitar que los usuarios mantengan siempre una misma password. Sugerimos un valor relativamente alto. Muchas organizaciones usan incluso 32 (el valor mximo). En nuestro ejemplo el HISTORY se fij en 15, como se desprende de la siguiente leyenda del listado de la SETROPTS:
15 GENERATIONS OF PREVIOUS PASSWORDS BEING MAINTAINED.

De todos modos, para que este control no sea fcilmente burlado, es importante establecer asimismo un valor apropiado para el operando MINCHANGE, que analizamos ms adelante. En caso contrario, RACF no impedir que un usuario, al verse forzado a cambiar su password, lo haga intencionalmente en forma consecutiva tantas veces como sea necesario para poder volver a usar su favorita. Por ejemplo, si se guardan 15 en el historial, basta con que el usuario cambie su password 17 veces para poder volver a especificar la actual. Es importante hacer notar la siguiente sutileza. Supongamos que se tiene HISTORY en 15, y se decide reducir el valor a 10. En tal caso, las passwords almacenadas entre la 11 y la 15 seguirn utilizndose en la comparacin con la nueva, an cuando el HISTORY se encuentre en 10. Por lo tanto, como nunca sern descartadas, quedarn eternamente prohibidas para el usuario. Existen, de todos modos, herramientas desarrolladas para limpiar esta historia residual. Una de ellas es el utilitario CUTPWHIS, que si bien no est oficialmente soportado por IBM, puede descargarse de su pgina y funciona correctamente. Una password no expirada otorgada por un usuario con capacidad administrativa mediante el comando ALTUSER no est sujeta al chequeo contra el historial. NOHISTORY establece que la nueva password solo ser comparada con la actual. El usuario puede entonces especificar cualquier password con la nica condicin de que sea diferente de la vigente. Por lo tanto, con esta opcin en efecto, un usuario podra alternar permanentemente entre 2 passwords. NOHISTORY es la opcin en efecto en una base recin inicializada. Como ya sealamos, esto no es satisfactorio desde el punto de vista de seguridad. En nuestro ejemplo, seteamos el valor en 15, como se observa en la siguiente leyenda del listado de la SETROPTS:
15 GENERATIONS OF PREVIOUS PASSWORDS BEING MAINTAINED.

Validez mxima INTERVAL establece la cantidad mxima de das en que la password del usuario permanecer vlida. Superada esa cantidad, RACF fuerza al usuario a cambiarla. El valor especificado globalmente en la SETROPTS, de mnimo 1 y mximo 254, en realidad fija un lmite superior. En efecto, para cada usuario, el intervalo pasado el cual estar obligado a cambiar su password surge del mnimo entre el INTERVAL de su perfil y el INTERVAL a nivel de la SETROPTS (salvo que el usuario tenga NOINTERVAL especificado en su perfil, en cuyo caso su password nunca vencer, independientemente del INTERVAL de la SETROPTS). Cada vez que un usuario se loguea al sistema, RACF compara la fecha actual con la fecha del campo PASSDATE del perfil. Si la diferencia entre ambas excede el mnimo anteriormente mencionado, se obliga al usuario a cambiar su password. El valor por defecto en una base recin inicializada es 30, que consideramos razonable y coincide con el fijado en nuestro ejemplo, como se sigue de la siguiente leyenda del listado de la SETROPTS:
PASSWORD CHANGE INTERVAL IS 30 DAYS.

Validez mnima MINCHANGE establece el tiempo de vida mnimo, medido en das, que debe regir la password. El usuario no podr cambiarla hasta tanto hayan transcurrido, como mnimo y contados desde la fecha del ltimo cambio (almacenada en el campo PASSDATE del perfil), la cantidad de das especificados. El valor debe estar comprendido entre 0 y 254. 0 indica que los usuarios podrn cambiar su password tantas veces como quieran, sin restriccin alguna. Como ya sealamos, no se trata de un seteo
Apuntes de RACF Juan Mautalen

78 recomendable pues permite burlar el control dado por el historial. Consideramos que 1 es un valor razonable, pues evita el reciclaje de password a la vez que permite al usuario cambiarla con la frecuencia que estime apropiada. Recordemos que un usuario debera cambiar inmediatamente su password si supone que est en conocimiento de un tercero, razn por la cual un valor alto del MINCHANGE sera contraproducente. Es importante observar que la restriccin fijada por el parmetro MINCHANGE no aplica para usuarios con capacidad administrativa que cambian la password de otro mediante el comando ALTUSER. Por ejemplo, an cuando el MINCHANGE est seteado en 1, un usuario con atributo SPECIAL a nivel de sistema podr cambiar la password de cualquier otro tantas veces al da como considere necesario. El valor por defecto en una base recin inicializada es 0, que consideramos inapropiado. En nuestro ejemplo lo establecimos en 1, como muestra la siguiente leyenda del listado de la SETROPTS:
PASSWORD MINIMUM CHANGE INTERVAL IS 1 DAYS.

Passwords sensitivas Desde el z/OS 1.7, RACF soporta la posibilidad de distinguir entre maysculas y minsculas en los caracteres de una password. Esta opcin, de implementarse, ampla enormemente el universo de posibles passwords, tornando un intento de crackeo por fuerza bruta prcticamente inviable. En cualquier caso, es de suma importancia proteger adecuadamente las bases activas de RACF (primaria y backup) y todos sus resguardos tanto en disco como en cartucho de modo que estos intentos de cracking ni siquiera puedan ocurrir. MIXEDCASE indica que RACF efectivamente distinguir entre maysculas y minsculas. Es fundamental comprender que el soporte de passwords sensitivas tiene dos puntas, por un lado la aplicacin dnde se loguea el usuario (CICS, TSO, FTP, etc.) y por otro RACF. No alcanza con que se habilite en RACF esta opcin si la aplicacin no la soporta (por ejemplo, convirtiendo a maysculas la password antes de presentrsela a RACF). En la actualidad, todas las aplicaciones de IBM para z/OS soportan passwords sensitivas, pero es posible que la organizacin use algn aplicativo propio, o de un tercero, que no lo haga. En tal caso, hay que proceder muy cuidadosamente antes de setear MIXEDCASE, evaluando detenidamente el impacto que puede ocasionar sobre la correspondiente aplicacin. NOMIXEDCASE establece que RACF no distinguir entre maysculas y minsculas. Independientemente de cmo reciba la password, RACF la convertir a maysculas antes de verificarla. Con esta opcin se logra un comportamiento anlogo al existente antes del z/OS 1.7, y es la que est en efecto en una base recin inicializada. Advertencia: Una vez que se habilita la opcin MIXEDCASE, la vuelta atrs es problemtica y debe evitarse. Si esto sucediera, aquellos usuarios cuya password contenga algn carcter en minscula no podrn loguearse. En efecto, al tener por un lado RACF almacenada la versin con minsculas y por otro convertir a maysculas la password recibida antes de proceder a su verificacin producto del seteo NOMIXEDCASE -, sta siempre resultar fallida. La nica salida, en esta situacin, es que el usuario solicite a un administrador una nueva password. En nuestro ejemplo est habilitada la opcin MIXEDCASE, tal como se observa en la siguiente leyenda del listado de la SETROPTS:
MIXED CASE PASSWORD SUPPORT IS IN EFFECT.

Revocacin automtica por intentos fallidos REVOKE establece la cantidad mxima de intentos consecutivos de passwords incorrectas que RACF tolerar antes de proceder a la revocacin automtica del usuario. Si el valor especificado es N, entonces en el (N+1) intento consecutivo de ingreso especificando una password incorrecta el usuario ser automticamente revocado. Naturalmente, un ingreso vlido vuelve la cuenta a 0.
Apuntes de RACF Juan Mautalen

79 El valor especificado debe hallarse comprendido entre 1 y 255. Recomendamos un valor bajo, para desalentar intentos maliciosos de adivinar la password de otro usuario. Sin embargo, un valor muy bajo (1 o 2, por ejemplo), ocasiona problemas operativos, ya que es frecuente que un usuario tipee involuntariamente mal su password. En nuestra opinin, 5 resulta un valor razonable, vigente en nuestro ejemplo, como indica la leyenda:
AFTER 5 CONSECUTIVE UNSUCCESSFUL PASSWORD ATTEMPTS, A USERID WILL BE REVOKED.

NOREVOKE indica que RACF no revocar automticamente a los usuarios por intentos consecutivos de ingreso con passwords incorrectas (o sea, no hay lmite para la cantidad de intentos). Esta es la opcin en efecto en una base recin inicializada. Resulta, sin embargo, inadmisible desde el punto de vista de la seguridad. Reglas sintcticas Con el suboperando RULE se establecen las reglas sintcticas que deben cumplir las passwords. Se puede especificar hasta un mximo de 8 reglas, que se denominan RULEx, dnde x vara de 1 a 8. Una password resulta sintcticamente admisible si cumple con alguna de las reglas establecidas. Para cada regla debe definirse la longitud (mnima y mxima) y el tipo de caracteres permitidos en cada posicin. Los posibles tipos de caracteres son: ALPHA CONSONANT ALPHANUM NUMERIC VOWEL NOVOWEL MIXEDCONSONANT MIXEDNUM MIXEDVOWEL NATIONAL A C L N V Caracteres alfabticos en mayscula + caracteres nacionales (#, &, @). Consonantes en mayscula. Caracteres alfabticos en mayscula + caracteres nacionales (#, &, @) + caracteres numricos (0 al 9). Caracteres numricos (0 al 9) Vocales en mayscula: A, E, I, O, U.

W Consonantes en mayscula + caracteres nacionales (#, &, @) + caracteres numricos (0 al 9). c m v $ Consonantes en mayscula o minscula. Caracteres alfabticos en mayscula o minscula + caracteres nacionales (#, &, @) + caracteres numricos (0 al 9). Vocales en mayscula o minscula: A, E, I, O, U, a, e, i, o, u. Caracteres nacionales: #, &, @).

El tipo ALPHANUM exige lo siguiente: Si existe ms de un carcter de este tipo, entonces la password debe tener en esas posiciones al menos un carcter alfabtico en maysculas y uno numrico. El tipo MIXEDNUM exige lo siguiente: Si existe un nico carcter de este tipo, entonces puede ser cualquiera Si existen 2, la password debe tener en esas posiciones alguna de las siguientes combinaciones: - Carcter alfabtico en mayscula o nacional + carcter alfabtico en minscula - Carcter alfabtico en mayscula o nacional + carcter numrico - Carcter alfabtico en minscula + carcter numrico Si existen 3 o ms, la password debe tener en esas posiciones al menos un carcter alfabtico en maysculas o nacional, uno alfabtico en minsculas y uno numrico.

Apuntes de RACF

Juan Mautalen

80 Los tipos c, m y v, que involucran caracteres alfabticos en minsculas, solo deben usarse si la opcin MIXEDNUM est en efecto. La longitud admisible de la password para cada regla se establece a travs del parmetro LENGHT(min:max), dnde min indica la longitud mnima y max la mxima (max puede ser a lo sumo igual a 8). Naturalmente, min debe ser menor o igual a max. Si se omite max, se asume max=min por lo que la regla impone una longitud exacta. Asimismo, para cada regla, se establece qu tipo de carcter es admisible en cada posicin. La sintaxis quedar clara a travs del siguiente ejemplo: RULE1(LENGTH(6:8) CONSONANT(1) ALPHANUM(2:6) NOVOWEL(8) Esta regla establece que la password debe: tener una longitud mnima de 6 y mxima de 8; empezar con una consonante; tener caracteres alfanumricos de la posicin 2 a la 6 inclusive, y un carcter no vocal en la ltima posicin. En la posicin 7, no existiendo ninguna exigencia explcita, cualquier carcter alfanumrico es aceptado. Por ejemplo, la password T4RUJY4@ cumple con la regla establecida. Por el contrario, YHGTRF8 no la satisface, ya que entre las posiciones 2 y 6 no hay ningn carcter numrico y ALPHANUM(2:6) exige que haya por lo menos un carcter alfabtico y uno numrico en el rango. De todos modos, no recomendamos complicarse fijando reglas sofisticadas que seguramente sern frecuentemente olvidadas por lo usuarios. Es conveniente, en la medida de lo posible, habilitar la opcin MIXEDCASE. En caso de no poner en prctica esta opcin, la nica regla establecida en nuestra SETROPTS de ejemplo suele ser satisfactoria desde el punto de vista de seguridad.
INSTALLATION PASSWORD SYNTAX RULES: RULE 1 LENGTH(6:8) LLLLLLLL

Observaciones: Cuando se otorga una password expirada (lo cual sucede siempre que un administrador la otorga, salvo que especifique explcitamente lo contrario), la misma no tiene necesidad de satisfacer las reglas sintcticas. En cambio, si se otorga una clave no expirada, entonces debe cumplir con las reglas globales de la organizacin fijadas en la SETROPTS. Los eventuales cambio en las reglas para passwords de la SETROPTS toman efecto inmediatamente. Sin embargo, esto no significa que un usuario cuya password vigente no cumple con las nuevas reglas est forzado a cambiarla de inmediato. Solo cuando cambie voluntariamente su password, o sea forzado por RACF a hacerlo por haberse excedido el tiempo de validez, deber establecer una nueva que cumpla con las reglas actuales. En una base recin inicializada no hay ninguna regla establecida. Como ya indicramos, una nica regla estableciendo passwords de 6 a 8 caracteres alfanumricos es una opcin simple y por lo general satisfactoria. Warning Existe la posibilidad de informar con determinada anticipacin a un usuario de TSO (en el momento del logon), o en el log del job en el caso de un trabajo batch, que su password est prxima a vencer y tendr que cambiarla. La cantidad de das antes del vencimiento en que el usuario recibir los mensajes se establece con el parmetro WARNING. El valor especificado debe estar comprendido entre 1 y 255. En la prctica, no resulta una opcin de gran utilidad. De todos modos, ya que est disponible, recomendamos usarla. No debe fijarse un valor superior al especificado en INTERVAL, ya que ello provocara mensajes de advertencia al inicio de cada sesin, lo cual sera sumamente molesto. Un valor de 5 das resulta razonable, como tenemos en nuestro ejemplo, tal cual indica la siguiente leyenda:
PASSWORD EXPIRATION WARNING LEVEL IS 5 DAYS.

Apuntes de RACF

Juan Mautalen

81 NOWARNING, que es la opcin por defecto en una base recin inicializada, indica que no se avisar anticipadamente a los usuarios sobre el vencimiento de su password. 5.33 - Passwords del RVARY Sintaxis: SETROPTS|SETR RVARYPW([SWITCH(password)] [STATUS(password)]) Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: establecer passwords para ambos comandos (no dejar el valor default) No analizaremos en este captulo el comando RVARY, que merece un estudio detallado que haremos ms adelante. Tanto la funcin SWITCH como ACTIVE|INACTIVE del comando RVARY exigen el ingreso de una password para ejecutarse exitosamente. Estas passwords, una para SWITCH (operando SWITCH) y otra para STATUS (operando ACTIVE|INACTIVE) se especifican en la SETROPTS. Naturalmente, no se muestran en el listado. Si no se establecen estas passwords, el valor por defecto es la palabra YES. Es absolutamente recomendable que la organizacin fije passwords para estos comandos, y las almacene bajo sobre en algn lugar seguro. En nuestro ejemplo se han establecido ambas passwords, tal cual se desprende de la siguiente leyenda que aparece en el listado de la SETROPTS:
INSTALLATION DEFINED RVARY PASSWORD IS IN EFFECT FOR THE SWITCH FUNCTION. INSTALLATION DEFINED RVARY PASSWORD IS IN EFFECT FOR THE STATUS FUNCTION.

En una base recin inicializada, las claves en efecto son las default, o sea YES, en ambos casos. 5.34 - Opciones de auditora relativas a security levels y security labels Sintaxis: SETROPTS|SETR [SECLABELAUDIT|NOSECLABELAUDIT] [SECLEVELAUDIT(nivel)|NOSECLEVELAUDIT] Autoridad requerida: AUDITOR a nivel de sistema Opciones sugeridas: NOSECLABELAUDIT y NOSECLEVELAUDIT Ambas opciones solo cobran sentido en organizaciones que usen security levels, categories o security labels. SECLABELAUDIT y SECLEVELAUDIT incorporan un nivel extra de auditora, basado en security labels y security levels. Ambas opciones requieren el atributo AUDITOR a nivel de sistema para ser modificadas. Como ya hemos comentado, no consideramos necesario adoptar este nivel extra de seguridad, por lo cual recomendamos tener estas opciones inactivas. Este es el default en una base recin inicializada, y as se encuentran en nuestro ejemplo, como se deduce de la siguiente leyenda:
SECLEVELAUDIT IS INACTIVE SECLABEL AUDIT IS NOT IN EFFECT

5.35 - Restriccin para la creacin de perfiles ms especficos que perfiles existentes Sintaxis: SETROPTS|SETR GENERICOWNER|NOGENERICOWNER Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: depende de la organizacin

Apuntes de RACF

Juan Mautalen

82 GENERICOWNER limita la posibilidad de crear perfiles ms especficos que otros ya existentes, en cualquier clase de recursos generales, con excepcin de la clase PROGRAM. Si la opcin GENERICOWNER est en efecto, un usuario solo puede crear un perfil ms especfico que uno existente si, adems de tener autoridad para definir perfiles en la clase (ver atributo CLAUTH), cumple alguna de las siguientes condiciones: Tiene el atributo SPECIAL a nivel de sistema. Es el owner del perfil inmediatamente superior. Tiene el atributo SPECIAL a nivel de un grupo que tenga al perfil inmediatamente superior dentro de su campo de accin. GENERICOWNER solo limita la creacin de perfiles cuando existe un perfil menos especfico que el que se pretende definir. Tengamos presente que esta opcin tampoco limita la creacin de una proteccin ms especfica a travs de un perfil en una clase agrupadora, suponiendo que la clase en cuestin la tenga. A modo de ejemplo, supongamos la siguiente situacin:
o

El usuario JEF2574 tiene el atributo CLAUTH(OPERCMDS) y no tiene el atributo SPECIAL, ni a nivel de sistema ni a nivel de ningn grupo. OPERA es un grupo de RACF. Los perfiles existentes en la clase OPERCMDS, con sus respectivos owner, estn dados por la siguiente tabla: Perfil MVS.** JES2.** Owner OPERA JEF2574

o o

MVS.START.** JEF2574

En esta situacin, el usuario JEF2574 podra definir los perfiles JES2.CANCEL.** y MVS.START.STC.**, pues en ambos casos es el owner del perfil genrico existente que ms se ajusta al perfil que est definiendo (JES2.** y MVS.START.**, respectivamente). Tambin podra definir el perfil RACF.**, pues no existe ningn perfil menos especfico. Sin embargo, no podra definir el perfil MVS.STOP.**, ya que no es el owner de MVS.** y tampoco tiene el atributo SPECIAL a nivel de sistema o a nivel de un grupo que tenga al perfil MVS.** dentro de su campo de accin. NOGENERICOWNER no establece la limitacin anterior para la creacin de perfiles ms especficos que otros existentes. Es la opcin en efecto en una base recin inicializada, y es asimismo la vigente en nuestro ejemplo tal como indica la leyenda:
GENERIC OWNER ONLY IS NOT IN EFFECT

5.36 - Otras opciones vinculadas a security levels y security labels Sintaxis: SETROPTS|SETR [COMPATMODE|NOCOMPATMODE] [MLACTIVE[(FAILURES|WARNING)]|NOMLACTIVE] [MLQUIET|NOMLQUIET] [MLS[(FAILURES|WARNING)]|NOMLS] [MLSTABLE|NOMLSTABLE] [SECLABELCONTROL|NOSECLABELCONTROL] Autoridad requerida: SPECIAL a nivel de sistema
Apuntes de RACF Juan Mautalen

83 Opciones sugeridas: NOCOMPATMODE, NOMLACTIVE, NOMLQUIET, NOMLS, NOMLSTABLE NOSECLABELCONTROL Estas opciones, excepto MLQUIET|NOMLQUIET, solo tienen sentido en organizaciones que usen security labels. No vamos a analizar su significado en esta gua, ya que no nos ocupamos de analizar este nivel extra de seguridad. La opcin MLQUIET, mientras se encuentra vigente, permite nicamente a las started task, los operadores de consola y los usuarios con atributo SPECIAL loguearse, ejecutar jobs o acceder a recursos protegidos. Es una opcin que reduce al mnimo la actividad, y solo tendra sentido para alguna tarea especfica de mantenimiento. En cualquier caso, es extremadamente raro que deba recurrirse a ella. NOMLQUIET no establece las citadas restricciones. En una base recin inicializada, todas estas opciones estn en NO, al igual que en nuestro ejemplo, tal cual se ve en las siguientes leyendas del listado de la SETROPTS:
SECLABEL CONTROL IS NOT IN EFFECT (...) COMPATIBILITY MODE IS NOT IN EFFECT MULTI-LEVEL QUIET IS NOT IN EFFECT MULTI-LEVEL STABLE IS NOT IN EFFECT NO WRITE-DOWN IS NOT IN EFFECT MULTI-LEVEL ACTIVE IS NOT IN EFFECT

5.37 - Acceso a datasets no catalogados Sintaxis: SETROPTS|SETR CATDSNS(FAILURES|WARNING)|NOCATDSNS Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: CATDSNS(FAILURES) Se trata de una opcin importante que determina cmo se comportar RACF cuando se intente acceder a archivos no catalogados. Este seteo afecta igualmente a datasets no catalogados residentes en cartucho, si se habilit para ellos el control en la clase DATASET mediante la apropiada configuracin el miembro DEVSUPxx de la PARMLIB. CATDSNS en FAILURES indica que RACF no permitir acceder a archivos que no se encuentren catalogados (o temporarios generados por el sistema). Con esta configuracin, estos datasets resultan inaccesibles, salvo en alguna de las situaciones siguientes: Si un job define un archivo y no lo cataloga, puede accederlo mientras dure la ejecucin. Archivos protegidos por perfiles discretos pueden ser accedidos an cuando no estn catalogados, siempre y cuando el perfil protector lo permita. Para datasets no catalogados y no protegidos discretamente, se construye un recurso de nombre ICHUNCAT.dsname, dnde dsname es el nombre del archivo (solo los 30 primeros caracteres se consideran). RACF chequea a continuacin la autoridad del usuario sobre este recurso en la clase FACILITY, y si es READ (o superior), entonces no rechaza el acceso por dataset no catalogado. Si el usuario tiene el atributo SPECIAL a nivel de sistema, no se rechaza el acceso por dataset no catalogado, pero se enva al usuario (y al SYSLOG) un mensaje informando que el archivo no est catalogado. Se graba asimismo un registro de SMF reflejando el evento. Si el acceso lo solicita una started task definida como TRUSTED o PRIVILEGED, entonces no se rechaza el requerimiento por dataset no catalogado. En los casos mencionados, la condicin de no catalogado del archivo no impide el acceso, pero el usuario debe de todos modos tener acceso al dataset a travs de los canales habituales.
Apuntes de RACF Juan Mautalen

84 En nuestro ejemplo, la opcin en efecto es CATDSNS(FAILURES), tal cual se desprende de la siguiente leyenda:
CATALOGUED DATA SETS ONLY, IS IN EFFECT. CURRENT OPTIONS: CATDSNS FAIL OPTION IS IN EFFECT

CATDSNS en WARNING funciona de manera similar al modo FAILURES, pero con una diferencia fundamental: RACF, en lugar de rechazar el pedido por dataset no catalogado, contina con su chequeo habitual pero enva, tanto al usuario como al SYSLOG, un mensaje informando que el archivo no se encuentra en catlogo. Se graba asimismo un registro de SMF reflejando el evento. Esta opcin resulta til en las etapas iniciales de la construccin de un sistema, ya que permite identificar los archivos en uso que no se encuentran catalogados, sin causar interrupciones en las tareas por problemas de falta de autoridad. Luego de un tiempo prudencial, se sugiere cambiar al modo FAILURES. NOCATDSNS establece que RACF no rechazar el acceso a un archivo por no estar catalogado. Esta es la opcin vigente en una base recin inicializada. 5.38 - Mximo global y default para la validez de la clave de una sesin Sintaxis: SETROPTS|SETR SESSIONINTERVAL(n)|NOSESSIONINTERVAL Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: depende de la organizacin SESSIONINTERVAL(n) establece el mximo valor para el operando INTERVAL, medido en das, que se puede especificar en el segmento SESSION en un perfil de la clase APPCLU. Este valor resulta tambin el defecto cuando se define un nuevo perfil en esta clase con segmento SESSION pero no se codifica INTERVAL. El valor n debe estar comprendido entre 1 y 32767 inclusive. En una base recin inicializada, el valor por defecto es 30, que es asimismo el vigente en nuestro ejemplo, lo cual se desprende de la siguiente leyenda:
PARTNER LU-VERIFICATION SESSIONKEY INTERVAL MAXIMUM/DEFAULT IS 30 DAYS.

La opcin NOSESSIONINTERVAL no establece ningn mximo global. 5.39 - Auditora de transacciones APPC Sintaxis: SETROPTS|SETR APPLAUDIT|NOAPPLAUDIT Autoridad requerida: AUDITOR a nivel de sistema Opcin sugerida: depende de la organizacin APPLAUDIT habilita globalmente la auditora para transacciones APPC (registra inicio y fin). Sin embargo, para que efectivamente se grabe esta informacin, debe auditarse el correspondiente perfil de la clase APPL. NOAPPLAUDIT inhabilita globalmente este tipo de auditora. Con esta opcin en efecto no se graba la informacin correspondiente an cuando el perfil en la clase APPL est debidamente auditado. Esta es la opcin por defecto en una base recin inicializada, y es asimismo la vigente en nuestro ejemplo, como muestra la leyenda:
APPLAUDIT IS NOT IN EFFECT

Apuntes de RACF

Juan Mautalen

85 5.40 - Opcin ADDCREATOR Sintaxis: SETROPTS|SETR ADDCREATOR|NOADDCREATOR Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: NOADDCREATOR La opcin ADDCREATOR establece que toda vez que un usuario defina un perfil de dataset o de recursos generales automticamente se agregar su identificador en la lista de acceso estndar con nivel de autoridad ALTER. En la prctica, ms que una ventaja resulta una molestia, ya que es sumamente frecuente que el creador del perfil no necesite acceso a los recursos que protege. Por lo tanto, recomendamos la opcin NOADDCREATOR, que no coloca automticamente al usuario creador del perfil en la lista de acceso. En una base recin inicializada, la opcin en efecto es NOADDCREATOR. En nuestro ejemplo, esta es la opcin elegida, como se ve en la leyenda:
ADDCREATOR IS NOT IN EFFECT

5.41 - Lenguaje Sintaxis: SETROPTS|SETR LANGUAJE([PRIMARY(lenguaje)] [SECONDARY(lenguaje)]) Autoridad requerida: SPECIAL a nivel de sistema Opcin sugerida: ENU para ambos A nivel de la SETROPTS, pueden establecerse los lenguajes globales que usar el sistema (uno primario y otro secundario, que pueden coincidir o ser diferentes). Naturalmente, solo pueden especificarse lenguajes que estn disponibles en la instalacin, para lo cual debe consultarse a los responsables del sistema operativo. El valor por defecto para ambos lenguajes, en una base recin inicializada, viene identificado por la sigla ENU, que significa ingls americano. Esta es la opcin vigente en nuestro ejemplo, tal cual muestra la leyenda:
PRIMARY LANGUAGE DEFAULT : ENU SECONDARY LANGUAGE DEFAULT : ENU

5.42 - Comandos de REFRESH Los comandos de RACF que definen, modifican o borran perfiles, actan directamente sobre la base RACF (residente en disco). Sin embargo, con el propsito de optimizar la performance, reduciendo lo ms posible la cantidad de operaciones de I/O sobre la base muy costosas, en muchos casos RACF carga informacin en memoria virtual y la reutiliza tantas veces como le sea requerida, evitando extraerla nuevamente de la base. Esto mejora sensiblemente el tiempo de respuesta, ya que es muchsimo ms rpido el acceso a memoria que a disco. Ahora bien, como contrapartida, toda vez que se modifique informacin de un perfil que RACF mantiene en memoria, ser necesario una actualizacin. Esta operacin, conocida como REFRESH (refrescamiento), se logra ejecutando el comando SETROPTS con los operandos adecuados. No existe un nico comando de REFRESH, ya que el mismo vara de acuerdo al tipo de informacin a actualizar y a las caractersticas de la clase a la que pertenecen los perfiles. Clases RACLISTeadas Una clase puede estar RACLISTeada mediante alguna de las siguientes maneras:

Apuntes de RACF

Juan Mautalen

86 A travs del comando SETROPTS RACLIST(clase), en cuyo caso aparece bajo RACLIST en el listado de la SETROPTS. Por una aplicacin, en cuyo caso aparece bajo GLOBAL=YES RACLIST ONLY en el listado de la SETROPTS.

En ambos casos, RACF carga en un data space en memoria la informacin de todos los perfiles (discretos y genricos) de la clase. La informacin de este data space es consultada toda vez que una aplicacin requiera que RACF resuelva una solicitud de acceso que involucre a esta clase. Si la clase RACLISTeada tiene una clase agrupadora, RACF realiza una operacin de merge cuando carga en memoria los perfiles, con el objeto de combinar adecuadamente la informacin de ambas clases la de miembros y la agrupadora. En estos casos, por lo tanto, la informacin en el data space es una versin procesada de los perfiles existentes en la base. Toda modificacin que se efecte sobre perfiles (discretos o genricos) de una clase RACLISTeada, o sobre aquellos de su eventual clase agrupadora, solo tomarn efecto una vez que se haya refrescado la informacin del data space, para lo cual es necesario ejecutar el comando: SETROPTS RACLIST(clase) REFRESH La clase especificada no debe ser una clase agrupadora. Si se modific informacin de perfiles de una clase agrupadora (y la clase de miembros asociada se encuentra RACLISTeada), el comando de REFRESH debe ejecutarse siempre sobre la clase de miembros. Este comando genera un nuevo data space. Hasta tanto concluya su creacin, las aplicaciones seguirn usando la informacin del antiguo. Una vez que el comando se complete exitosamente, las distintas aplicaciones empezarn inmediatamente a apuntar al nuevo data space, y el antiguo es borrado. Es importante destacar que no solo se refresca la informacin de los perfiles de la clase especificada, sino tambin de todas aquellas otras clases que eventualmente compartan el mismo posit value. Autoridad requerida Para ejecutar el comando anterior sobre una determinada clase, el usuario debe satisfacer alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema Tener el atributo AUDITOR a nivel de sistema Tener CLAUTH sobre la clase Clases no RACLISTeadas que tienen perfiles genricos Si una clase no se encuentra RACLISTeada, pero tiene perfiles genricos definidos, estos se cargan en memoria cuando son referenciados (en un espacio comn, en algunos casos, o en cada address space, en otros). Por lo tanto, una modificacin efectuada sobre un perfil genrico de la clase puede no tomar efecto inmediatamente (si el address space que lo requiere tiene, por ejemplo, informacin del perfil cargada en su propia memoria). En tal caso, para actualizar la informacin existente debe ejecutarse el comando: SETROPTS GENERIC(clase) REFRESH Este comando no solo refresca la informacin de los perfiles genricos de la clase especificada sino tambin los de aquellas otras que eventualmente compartan el mismo posit value. Autoridad requerida Para poder ejecutar el comando anterior sobre una determinada clase, el usuario debe satisfacer alguna de las siguientes condiciones:

Apuntes de RACF

Juan Mautalen

87 Tener el atributo SPECIAL, AUDITOR u OPERATIONS, ya sea a nivel de sistema o a nivel de grupo. Tener CLAUTH sobre la clase. Observacin: Para una clase no GENLISTeada, el comando SETROPTS GENERIC(clase) REFRESH se ejecuta casi instantneamente. Esto se debe a que RACF simplemente modifica un contador, residente en memoria y especfico de la clase. Sin embargo, su efecto concreto es el de invalidar todas las copias de perfiles genricos de la clase que puedan existir en los distintos address space. En efecto, stos saben qu valor tena el contador la ltima vez que se cargaron en su memoria de perfiles de la clase y, antes de reusarlos, verifican que el contador no haya cambiado. Si lo hizo, los perfiles son invalidados y ser necesario volver a cargarlos. En consecuencia, se trata de un comando de ejecucin inmediata pero que puede resultar costoso en trminos de procesamiento, si muchos address space tienen almacenados perfiles de la clase. Un ejemplo tpico es la clase DATASET. El comando SETROPTS GENERIC(DATASET) REFRESH finaliza inmediatamente, pero su impacto negativo en la performance puede ser importante. Si un usuario de TSO reporta que intent acceder a un dataset y no pudo por falta de autoridad, en caso de que se le otorgue la autorizacin, ser normalmente preferible pedirle que vuelva iniciar sesin antes que ejecutar el comando de REFRESH. Clase GLOBAL La informacin de las tablas de la clase GLOBAL se encuentra siempre cargada en memoria. Toda modificacin, para tomar efecto, requiere la ejecucin de un comando de REFRESH. Si se tiene una clase bajo GLOBAL en la SETROPTS, y se modifica informacin de la correspondiente tabla, los cambios solo quedarn vigentes si se ejecuta el comando: SETROPTS GLOBAL(clase) REFRESH Este comando no solo afecta la clase especificada sino tambin a todas aquellas otras que eventualmente compartan el mismo posit value (y estn bajo GLOBAL en la SETROPTS) Autoridad requerida Para ejecutar el comando anterior sobre una clase, el usuario debe satisfacer alguna de las siguientes condiciones: Tener el atributo SPECIAL, AUDITOR u OPERATIONS a nivel de sistema. Tener CLAUTH sobre la clase. Clase PROGRAM La clase PROGRAM es muy particular en varios aspectos, y la forma de refrescarla es uno de ellos. Si se efectan modificaciones en sus perfiles, los cambios solo tomarn efecto una vez que se haya ejecutado el comando: SETROPTS WHEN(PROGRAM) REFRESH Autoridad requerida Para ejecutar el comando anterior, el usuario debe satisfacer alguna de las siguientes condiciones: Tener el atributo SPECIAL, AUDITOR u OPERATIONS a nivel de sistema. Tener CLAUTH en la clase PROGRAM.

Apuntes de RACF

Juan Mautalen

88 6 - PROTECCIN DE RECURSOS GENERALES 6.1 - Recursos generales y perfiles Todos los recursos que no sean archivos son considerados recursos generales, y su proteccin se establece a travs de perfiles en clases de recursos generales. Todas las clases, provistas por IBM o definidas por la organizacin, con excepcin de USER, GROUP y DATASET, son consideradas clases de recursos generales. No debe confundirse un recurso general con un perfil de recursos generales, del mismo modo que no debe confundirse un dataset con un perfil de dataset.. El nombre de un recurso general lo establece la aplicacin o subsistema correspondiente, y simboliza un objeto -tangible o intangible- de muy variada naturaleza. Posibles ejemplos son: discos; comandos de operador; procedimientos de logon a TSO o la facilidad de acceder a cierto archivo no catalogado. La aplicacin, al derivar a RACF el requerimiento de chequeo de autoridad, debe informar a qu clase de recursos generales (definida en la CDT) pertenece el recurso. Un perfil de recursos generales, en cambio, es una entidad que existe nicamente en la base de RACF. Se crea, modifica o borra a travs de comandos. Es una regla usada para controlar el acceso a los recursos propiamente dichos. Est constituido por un segmento base, tambin llamado segmento de RACF, ms eventuales segmentos no base, que varan de acuerdo a la clase a la que pertenece el perfil. Por ejemplo, el comando de operador START PROC1, que inicia una started task llamada PROC1, se asocia con el nombre de recurso MVS.START.STC.PROC1 en la clase OPERCMDS, que a su vez podra estar protegido por el perfil genrico MVS.START.**. Los nombres de los recursos generales son muy variados, al igual que los de los perfiles que los protegen. Toda clase definida en la CDT tiene especificado el tipo de caracteres que admite y la longitud mxima permitida. En cualquier caso, los nombres se componen de cadenas de caracteres llamadas calificadores, separados por puntos (.). A diferencia de los nombres de archivos, la longitud de un calificador puede exceder los 8 caracteres. 6.2 - Clases de miembros y agrupadoras Ciertas clases de recursos generales vienen asociadas de a pares, siendo una de ellas la clase de miembros (member class) y la otra la clase agrupadora (grouping class). Ambas sirven para proteger el mismo tipo de recurso. Un ejemplo tpico son las clases TCICSTRN y GCICSTRN, utilizadas para controlar la ejecucin de transacciones CICS. TCICSTRN es la clase de miembros mientras que GCICSTRN es su correspondiente clase agrupadora. Los perfiles de la clase de miembros deben tener un nombre que matchee con el del recurso que pretendan proteger. Por lo tanto, solo permiten proteger un nico recurso o varios distintos pero de nombres similares. Se admiten normalmente perfiles genricos, suponiendo que la clase se encuentre bajo GENERIC en la SETROPTS. Ejemplo: Supongamos que los perfiles definidos en la clase TCICSTRN son los siguientes: 1. ABC1 2. HYT6 3. ABC% 4. AB* 5. F* 1 y 2 son perfiles discretos, mientras que 3, 4 y 5 son perfiles genricos.

Apuntes de RACF

Juan Mautalen

89 Dentro de la clase de miembros, todo recurso tiene (a lo sumo) un nico perfil que ms se le ajusta, que puede ser discreto o genrico. En nuestro ejemplo, para la transaccin ABC1 sera el perfil discreto de idntico nombre, mientras que para la transaccin ABFT, el perfil ms ajustado sera el genrico AB*. La transaccin RY54, por otro lado, no estara cubierta por ningn perfil de la clase TCICSTRN. En cualquier caso, la proteccin de un determinado recurso surge de combinar la informacin almacenada en ambas clases, la de miembros y la agrupadora, tal cual veremos a continuacin. Los perfiles en la clase agrupadora, a diferencia de lo que sucede con los de la clase de miembros, tienen nombres de libre eleccin. Pero poseen una lista de miembros cuyos nombres deben matchear con el nombre del recurso que pretendan proteger. En consecuencia, estos perfiles permiten proteger recursos de nombres dismiles pero con idntica necesidad de acceso. No se permiten perfiles genricos, aunque s pueden los perfiles tener miembros genricos. Un mismo miembro puede existir en varios perfiles. Ejemplo: Supongamos que los perfiles definidos en la clase GCICSTRN son los siguientes: Nombre del perfil Miembros GRUPOA A* SISTAB SISTCONT ABC1, ABC2, ABY6, AB* FTR1, FTR2, FTR3, ABC1, ABC2, VGT8

Los 3 perfiles son discretos (recordemos que no estn tolerados los perfiles genricos para clases agrupadoras). Los nombres de los perfiles -GRUPOA, SISTAB y SISTCONT- son arbitrarios y no son chequeados por RACF contra ningn nombre de recurso. En cambio, los miembros que tienen definidos son los que deben matchear con los nombres de los recursos. GRUPOA tiene un nico miembro, que es genrico. SISTAB tiene 4 miembros. 3 de ellos discretos (ABC1, ABC2 y ABY6) y el restante genrico (AB*). SISTCONT tiene 5 miembros, todos ellos discretos. Dentro de una clase agrupadora, un recurso puede tener ms de un perfil de mximo ajuste. Por ejemplo, para la transaccin ABC1, stos seran SISTAB y SISTCONT, pues ambos tienen al miembro discreto ABC1. Por otro lado, para la transaccin ABC8, el ms ajustado sera SISTAB, mientras que para AX56 sera GRUPOA. La transaccin VGT2, en cambio, no estara protegida por ningn perfil de la clase GCICSTRN. Determinacin de la proteccin de un recurso La manera en que RACF determina la proteccin de un recurso en el caso de clases de miembros y agrupadoras es relativamente compleja. Intentaremos describirla con cierto detalle, apoyndonos en los ejemplos dados para las clases TCICSTRN y GCICSTRN. Dado un recurso, RACF busca en principio determinar si est protegido discretamente. Para ello examina ambas clases. En la clase de miembros, puede encontrar a lo sumo un nico perfil discreto para el recurso, mientras que en la clase agrupadora podran existir eventualmente varios (que tengan al recurso como miembro discreto). Si RACF efectivamente encontr al recurso protegido de manera discreta, se pueden presentar los 2 casos siguientes: RACF encontr un nico perfil que cubre discretamente al recurso (que podra estar en la clase de miembros o en la clase agrupadora). En este caso, este perfil es el que establece la proteccin del recurso. Es el caso, en nuestro ejemplo, para las transacciones HYT6 (perfil de igual nombre en la clase TCICSTRN) y VGT8 (perfil SISTCONT en la clase GCICSTRN). RACF encontr ms de un perfil que cubre discretamente al recurso. Es decir, hall uno en la clase de miembros y uno o ms en la clase agrupadora, o bien no encontr ninguno en la clase de
Apuntes de RACF Juan Mautalen

90 miembros pero encontr 2 o ms en la clase agrupadora. Sera el caso, en nuestro ejemplo, de las transacciones ABC1 (perfil de igual nombre en la clase TCICSTRN junto con perfiles SISTAB y SISTCONT en la clase GCICSTRN) y ABC2 (perfiles SISTAB y SISTCONT en la clase GCICSTRN). En este caso, la proteccin efectiva del recurso surge de combinar la informacin de todos los perfiles que lo cubren discretamente, proceso conocido como merge. No describiremos en detalle este algoritmo, pero mencionaremos los aspectos ms relevantes: Para determinar la lista de acceso del recurso, RACF combina las listas de acceso de todos los perfiles involucrados, manejndose, en caso de repeticiones, en base al criterio del nivel ms permisivo. Esto significa que si un grupo (o usuario) figura en ms de una de las listas de acceso, su nivel de autorizacin efectivo sobre recurso ser el ms alto de todos. En lo que se refiere al UACC del recurso, RACF opera de manera opuesta. El UACC efectivo ser el ms restrictivo de los UACC de los perfiles involucrados. Si RACF no encuentra al recurso cubierto de manera discreta, entonces busca en ambas clases perfiles que lo cubran de forma genrica. En tal caso, siguiendo un criterio anlogo al empleado para perfiles genricos de dataset, los compara hasta determinar los que ms se ajustan al nombre del recurso. Si RACF llega a establecer un nico perfil que cubre genricamente al recurso de la manera ms ajustada posible, entonces ste perfil ser el protector. Es el caso, en nuestro ejemplo, de la transaccin ABC3. En efecto, si bien tanto el perfil ABC% en la clase TCICSTRN como los perfiles GRUPOA y SISTAB en la clase GCICSTRN cubren genricamente al recurso, el ms ajustado es el perfil ABC% (pues tanto A* como AB* son menos especficos). Si RACF encuentra ms de un perfil que cubre genricamente al recurso de la manera ms ajustada posible, entonces la proteccin efectiva surge de un proceso de merge idntico al mencionado en el caso discreto. Este sera el caso, siempre en nuestro ejemplo, de la transaccin ABX9. Tanto el perfil AB* en la clase TCICSTRN como el perfil SISTAB en la clase GCICSTRN cubren lo ms ajustadamente posible al recurso ABX9 (GRUPOA no entra en juego ya que A* es menos especfico). Por lo tanto, la proteccin de la transaccin ABX9 se establece combinando los perfiles AB* y SISTAB. Finalmente, si RACF no encuentra al recurso cubierto ni discreta ni genricamente en ninguna de ambas clases, entonces concluye que no lo tiene protegido y devuelve a la aplicacin solicitante el DFTRETC especificado para la clase en la CDT. Tal sera el caso, en nuestro ejemplo, para la transaccin MKL7. En el caso concreto de CICS, cabe sealar que el producto deniega el acceso si la transaccin no est protegida, suponiendo que CICS est efectivamente configurado para que se controle la ejecucin de transacciones. Recomendaciones: En virtud de lo expuesto, y con el objetivo de establecer una proteccin clara de los recursos en el caso de clases de miembros y agrupadoras, aconsejamos lo siguiente: No utilizar ambas clases, dentro de lo posible. Esto es, usar solo la clase de miembros o, mejor an, solo la clase agrupadora. No definir el mismo recurso en ms de un perfil. No definir miembros genricos en perfiles de la clase agrupadora. Es preferible, si fuese necesario, crear un perfil genrico en la clase de miembros. 6.3 - Perfiles genricos La mayora de las clases de recursos generales admiten perfiles genricos. Se identifican por la presencia de algn carcter comodn en su nombre (%, * y **), cuyo significado es similar aunque no exactamente idntico- al que tienen en el caso de perfiles de dataset. No estn permitidos, a diferencia de la clase DATASET, los perfiles genricos completos. En consecuencia, todo perfil que no contenga en su nombre al menos un carcter genrico, resulta un perfil discreto. Recordemos que si una clase de
Apuntes de RACF Juan Mautalen

91 recursos generales admite perfiles genricos, el uso del ** est permitido independientemente del seteo de la opcin EGN de la SETROPTS (que solo afecta a la clase DATASET). Otras diferencias importantes son las siguientes: Los perfiles genricos de recursos generales admiten caracteres comodn en cualquier calificador, incluso en el primero. El * al final de un perfil indica la presencia de 0 o mas caracteres, incluyendo eventuales puntos, por lo cual contempla la existencia de calificadores enteros. Siempre que resulte posible, conviene usar perfiles genricos, ya que una poca cantidad permite proteger un gran nmero de recursos. Valen consideraciones similares a las que se hicieron respecto a perfiles de dataset. Un abuso en la cantidad de perfiles genricos, dnde exista casi una relacin biunvoca con los recursos, desvirta su naturaleza y puede ocasionar problemas de performance. Los recursos que necesiten un tratamiento de seguridad particular deben ser protegidos mediante un perfil discreto. En cualquier caso, a diferencia de la clase DATASET, el uso de perfiles discretos en clases de recursos generales es muy frecuente (incluso, a veces, obligatorio) y est perfectamente justificado. 6.4 - Niveles de acceso Los perfiles de recursos generales, como sucede con los perfiles de dataset, tienen un UACC y listas de acceso -estndar y condicional-, dnde figuran niveles de acceso. Los posibles valores son los siguientes:
o o o o o o

NONE EXECUTE READ UPDATE CONTROL ALTER

Estn enumerados en orden jerrquico, de manera que cada nivel incluye y muchas veces excede los privilegios del anterior. Cabe sealar que los nombres de los niveles tienen su origen en los existentes para perfiles de dataset, dnde tienen un significado claro. Sin embargo, para perfiles de recursos generales, debe entenderse que se trata simplemente de una escala jerrquica, dnde el alcance de cada nivel de autoridad lo establece la aplicacin correspondiente. NONE tiene obviamente un significado claro, ya que indica que no se tiene ningn acceso al recurso. EXECUTE, por otro lado, solo es vlido para perfiles en la clase PROGRAM. Por ejemplo, dentro de CICS, los comandos invocados va la transaccin CEMT se encuentran protegidos en la clase CCICSCMD (o en la clase agrupadora asociada, VCICSCMD). En particular, la autoridad para ejecutar comandos sobre terminales se chequea contra el recurso de nombre TERMINAL. Dependiendo del tipo de comando que se ejecute, el nivel de autoridad requerido por CICS vara. As, para hacer un INQUIRE, el usuario debe tener READ, para hacer un SET se requiere UPDATE y para efectuar un DISCARD se exige ALTER. Cabe indicar que estos niveles de autoridad requeridos para cada comando los establece CICS y no RACF, que solo se limita a contestar requerimientos que le son remitidos. 6.5 - Cmo determina RACF la proteccin de un recurso general Si el recurso est asociado con una clase que tenga clase agrupadora, ya se describi el proceso que lleva a cabo RACF para determinar su proteccin.

Apuntes de RACF

Juan Mautalen

92 En caso contrario, o sea para recursos no relacionados con clases de miembros y agrupadoras, RACF determina a lo sumo un nico perfil -discreto o genrico- que protege al recurso, de manera anloga a como lo hace en el caso de archivos. RACF procede del siguiente modo: Si el recurso est protegido discretamente, entonces este perfil discreto ser su perfil protector. Si no est protegido discretamente, RACF busca todos los perfiles genricos que lo alcanzan (si no existiera ninguno, el recurso simplemente no estara protegido) y procede a compararlos, de izquierda a derecha. En el primer carcter en que encuentre alguna diferencia, se descartan aquellos ms genricos, de acuerdo al siguiente criterio: - Los caracteres no genricos son ms especficos que los genricos. - Para las genricos, el orden, desde el menos al ms genrico, es %, * y **. 6.6 - Definicin de un perfil de recursos generales Sintaxis: RDEFINE|RDEF clase nombre-del-perfil [DATA(installation-data)] [OWNER(usuario/grupo)] [UACC(nivel)] [WARNING] [NOTIFY(usuario)] [ADDMEM(miembro)] [AUDIT(tipo-de-acceso(nivel-de-acceso))] [FROM(perfil2)] [FCLASS(clase)] [FGENERIC] [FVOLUME(volumen)] Hemos incluido nicamente los operandos ms relevantes relativos al segmento base del perfil. Los segmentos no base se vern en el anlisis particular de cada clase. La clase es un parmetro posicional requerido que debe estar inmediatamente a continuacin del comando RDEFINE. El nombre-del-perfil es un parmetro posicional requerido que debe estar inmediatamente a continuacin de la clase. Los nombres vlidos dependen de cada clase. No debe especificarse el nombre del perfil entre apstrofes, ya que los mismos se consideraran parte integrante del nombre (si la clase los soportara). La DATA es un campo de uso administrativo, de longitud mxima 255 caracteres. El OWNER debe ser un usuario o grupo existente. Si no se codifica explcitamente, queda como OWNER el usuario que ejecut el comando. Recordemos que ser el dueo de un perfil no otorga acceso a los recursos que proteja. Para poder acceder a ellos, debe agregarse al usuario en la lista de acceso a travs del comando PERMIT. El operando UACC es sumamente importante y establece el nivel de acceso universal (Universal Access) del perfil. Puede tomar los valores NONE, EXECUTE, READ, UPDATE, CONTROL y ALTER, que ya mencionamos previamente (EXECUTE solo es vlido si la clase es PROGRAM). Si se omite, el valor por defecto es el DFTUACC que tiene la clase en la CDT o, en caso de que no lo tuviera especificado, el UACC que tiene el usuario que ejecuta el comando en su actual grupo de conexin (que, como ya sealamos, conviene que sea NONE por motivos de seguridad). El operando WARNING establece que el perfil se define en modo warning. Esto significa que si un usuario requiere acceso a un recurso protegido por el perfil y RACF determina que no est autorizado, en lugar de rechazar el acceso, lo autoriza pero enva un mensaje a la terminal del usuario (y graba uno similar en el SYSLOG) indicando que el acceso no corresponda pero fue otorgado por estar el perfil protector en modo warning. En ciertas ocasiones, cuando an no se logr determinar exactamente qu usuarios deben acceder a los recursos protegidos por un perfil, puede resultar til definirlo en modo warning, de modo a no provocar una interrupcin en alguna tarea crtica. Sin embargo, debe tenerse presente que aquellos recursos protegidos por un perfil en warning se encuentran accesibles por cualquier usuario con el mximo nivel de autoridad (ALTER), es decir que estn bsicamente sin proteccin. Por lo tanto, debe usarse esta facilidad con sumo cuidado y normalmente por un perodo
Apuntes de RACF Juan Mautalen

93 corto de tiempo. Si se omite WARNING, el perfil queda definido como NOWARNING, que llamamos modo fail. Este es el modo en que deben encontrarse normalmente todos los perfiles de la base. Las clases PROGRAM y NODES no admiten perfiles en modo warning. NOTIFY especifica un usuario a ser notificado cada vez que el perfil sea usado para denegar el acceso a un recurso. Si el usuario especificado se encuentra con una sesin de TSO activa, recibir las notificaciones en tiempo real. En caso contrario las recibir en el momento de su prximo logon (no se pierden). Si la cantidad de notificaciones esperadas es elevada, el usuario debera loguearse frecuentemente a TSO afn de liberar el espacio que ocupan sus mensajes pendientes en el archivo SYS1.BRODCAST. De todos modos, no es conveniente tener en forma permanente un usuario en el NOTIFY de un perfil, si se supone que rechazar gran cantidad de accesos. NOTIFY no admite ms de un usuario ni un grupo de RACF. Si se lo codifica sin especificar usuario, queda como usuario a ser notificado quien ejecut el comando RDEFINE. Si se lo omite, ningn usuario ser notificado y el campo muestra, en la salida del comando RLIST, la leyenda NO USER TO BE NOTIFIED. Con el operando ADDMEM se agregan miembros al perfil, siempre y cuando se trate de una clase cuyos perfiles los admitan (clases agrupadoras o GLOBAL y PROGRAM, por ejemplo). El significado y formato de estos miembros vara segn la clase. El operando AUDIT indica a qu nivel se quiere auditar el uso del perfil. La informacin se graba en registros tipo 80 del SMF. Se distinguen 2 conceptos diferentes: tipo de acceso y nivel de acceso. Los posibles tipos de acceso son: o NONE ningn intento de acceso ser grabado. o SUCCESS se grabarn accesos exitosos. o FAILURES se grabarn intentos de acceso fallidos. o ALL se grabar todo intento de acceso, sea fallido o exitoso. Los posibles niveles de acceso son: o READ o UPDATE o CONTROL o ALTER En el operando AUDIT se pueden especificar uno (o ms) tipos de acceso acompaados del nivel de acceso correspondiente. Naturalmente, NONE no requiere un nivel de acceso asociado. FAILURES(READ) es el valor por defecto, y establece que se registre todo intento de acceso denegado por el perfil. Intentos de acceso superiores a READ que resulten fallidos son tambin registrados. El operando FROM especifica el nombre de un perfil (discreto o genrico) en el cual se va a basar RACF para la creacin del nuevo. Todas las caractersticas del perfil especificado en el operando FROM son replicadas en el nuevo (OWNER, UACC, WARNING, AUDITING, NOTIFY, DATA, Listas de acceso, etc.), excepto que se codifique explcitamente un valor distinto para alguno de estos operandos en el comando RDEFINE. Si el perfil modelo tiene miembros, stos no son copiados al nuevo perfil. En cuanto a las listas de acceso, puede existir una mnima diferencia en las del nuevo perfil con respecto al tomado como modelo, en el caso siguiente: Si la opcin ADDCREATOR est activa en la SETROPTS, el usuario que crea el nuevo perfil se agrega a la lista de acceso estndar con autoridad ALTER, independientemente de que figure o no en la lista de acceso del perfil modelo. FCLASS indica la clase de RACF a la que pertenece el perfil especificado en el operando FROM (DATASET o cualquier clase definida en la CDT son admisibles). Si se omite, RACF asume que el perfil modelo pertenece a la misma clase que el que se est definiendo.

Apuntes de RACF

Juan Mautalen

94 FGENERIC indica a RACF que el perfil especificado en el operando FROM es genrico, an cuando no contenga caracteres genricos. Slo es necesario si FCLASS es DATASET y perfil2 es un genrico completo. RACF ignora el operando FGENERIC si no se codific FROM. Si el operando FROM especifica un perfil discreto de DATASET, el operando FVOLUME debe indicar el volumen correspondiente del perfil modelo. Si se codifica FVOLUME con un valor distinto al que corresponde, o si se omite y existe ms de un perfil discreto con ese nombre, el comando falla. Si no se especific el operando FROM, o se codific con un perfil genrico, o con un perfil de una clase que no sea DATASET, el operando FVOLUME es ignorado. Autoridad requerida La autoridad requerida depende de varios factores, como ser:
o o o

Clase a la que pertenece el perfil Operandos especificados en el comando RDEFINE Seteo de la opcin GENERICOWNER de la SETROPTS

No vamos a efectuar un anlisis detallado y exhaustivo de todas las situaciones que se pueden presentar. A grandes rasgos, digamos que los usuarios autorizados a definir nuevos perfiles son aquellos con el atributo SPECIAL o con CLAUTH sobre la clase. 6.7 - Modificacin de un perfil de recursos generales Sintaxis: RALTER|RALT clase nombre-del-perfil [DATA(installation-data)|NODATA] [OWNER(usuario/grupo)] [UACC(nivel)] [WARNING|NOWARNING] [NOTIFY(usuario)|NONOTIFY] [{ADDMEM|DELMEM}(miembro)] [AUDIT(tipo-de-acceso(nivel-de-acceso))] Naturalmente, como sucede con todos los comandos de modificacin de perfiles, solo es necesario codificar los operandos a modificar. Aquellos no especificados mantienen sus valores previos (no se cambian a valores por defecto). Con el operando DELMEM se borra un miembro del perfil. Si se codifican ambos operandos -ADDMEM y DELMEM- en el mismo comando, solo se procesa el especificado en ltimo trmino. Autoridad requerida Para modificar un perfil de recursos generales, quien ejecuta el comando debe, bsicamente, cumplir alguno de los siguientes requisitos: Tener el atributo SPECIAL a nivel de sistema. Tener el atributo SPECIAL a nivel de un grupo que tenga al perfil dentro de su campo de accin. Ser el owner del perfil. Si el perfil es discreto, tener autoridad ALTER sobre el perfil. Para ciertos operandos, como ADDMEM, existen restricciones adicionales, pero no entraremos en detalle sobre las mismas. 6.8 - Eliminacin de un perfil de recursos generales Sintaxis: RDELETE|RDEL clase nombre-del-perfil

Apuntes de RACF

Juan Mautalen

95 Autoridad requerida Para deletear un perfil de recursos generales, quien ejecuta el comando debe, bsicamente, cumplir alguno de los siguientes requisitos: Tener el atributo SPECIAL a nivel de sistema. Tener el atributo SPECIAL a nivel de un grupo que tenga al perfil dentro de su campo de accin. Ser el owner del perfil. Si el perfil es discreto, tener autoridad ALTER sobre el perfil. 6.9 - Listado de un perfil de recursos generales Sintaxis: RLIST|RL clase nombre-del-perfil|* [GENERIC|NOGENERIC] [AUTHUSER] [ALL] [RESGROUP] Si se codifica * luego de clase, se listarn todos los perfiles de la clase que el usuario est autorizado a ver. En caso de existir el perfil genrico *, no hay manera de listarlo individualmente. Por lo tanto, si se quiere definir un perfil abarcativo (backstop profile) en la clase (o sea, un perfil que proteja a todos los recursos que no se encuentren protegidos por uno ms especfico), es preferible crear el perfil ** en lugar de * pues, a diferencia de este ltimo, s es factible listarlo por separado con el comando RLIST clase **. Si se codifica el operando GENERIC, la informacin listada depender de lo que se especifique como nombre de recurso, de acuerdo al siguiente criterio:
o

Si nombre-del-perfil no contiene ningn caracter genrico, RACF listar el perfil genrico que ms se ajuste al nombre de recurso especificado. Sin embargo, si existiese un perfil discreto, no se mostrar (y, sin embargo, resulta ser efectivamente el perfil protector). Si nombre-del-perfil contiene algn carcter comodn, entonces RACF listar nicamente el perfil que coincida exactamente con el nombre especificado, si existiese. En caso contrario, informa sencillamente que el perfil requerido no existe. Si en lugar de nombre-del-perfil se codific *, sern listados todos los perfiles genricos de la clase.

NOGENERIC indica que se debe listar el perfil discreto que coincida con el nombre especificado. Si tal perfil no existiese, RACF lo informa. Si en lugar de nombre-del-perfil se codific *, sern listados todos los perfiles discretos de la clase. Si no se codifica GENERIC o NOGENERIC, la informacin listada depender de lo que se especifique como nombre de recurso, de acuerdo al siguiente criterio:
o

Si nombre-del-perfil no contiene ningn caracter genrico, RACF listar el perfil protector del recurso, que podr ser discreto o genrico. Si nombre-del-perfil contiene algn carcter comodn, entonces RACF listar nicamente el perfil que coincida exactamente con el nombre especificado, si existiese. En caso contrario, informa sencillamente que el perfil no existe. Si en lugar de nombre-del-perfil se codific *, sern listados todos los perfiles (discretos y genricos) de la clase.

AUTHUSER indica que se debe incluir en la salida del comando la siguiente informacin: o Security level, categories y security label o Lista de acceso estndar o Lista de acceso condicional

Apuntes de RACF

Juan Mautalen

96 ALL establece que se liste toda la informacin del segmento base. Si no se especifica, el listado no muestra ni las estadsticas ni las listas de acceso. Para listar los eventuales segmentos no base, debe especificarse el parmetro correspondiente. Si la clase tiene una clase agrupadora, RESGROUP indica que se genere una lista de todos los perfiles de la clase que tengan al recurso especificado dentro de sus miembros. En caso contrario, el operando RESGROUP es ignorado. Autoridad requerida Para listar un perfil de recursos generales, quien ejecuta el comando debe, bsicamente, cumplir con alguno de los siguientes requisitos: Tener el atributo SPECIAL, AUDITOR u OPERATIONS a nivel de sistema. Tener el atributo SPECIAL, AUDITOR u OPERATIONS a nivel de un grupo que tenga al perfil dentro de su campo de accin. Ser el owner del perfil. Tener autoridad READ (o superior) sobre el perfil. Existir una entrada en la GLOBAL para el perfil que otorgue autoridad READ (o superior). Para que se liste el campo GLOBALAUDIT, quien ejecuta el comando debe tener el atributo AUDITOR (ya sea a nivel de sistema, o a nivel de un grupo que tenga al perfil dentro de su campo de accin). Para ver las listas de acceso, se debe satisfacer alguna de las siguientes condiciones: Tener el atributo SPECIAL, AUDITOR u OPERATIONS a nivel de sistema. Tener el atributo SPECIAL, AUDITOR u OPERATIONS a nivel de un grupo que tenga al perfil de su campo de accin. Ser el owner del perfil. Existir una entrada en la GLOBAL para el perfil que otorgue autoridad ALTER. Si el perfil es discreto, tener autoridad ALTER sobre el perfil. 6.10 - Permisos sobre perfiles de recursos generales Las listas de acceso de perfiles de recursos generales, tanto la estndar como la condicional, se modifican a travs del comando PERMIT. Para ciertas clases, las listas de acceso son irrelevantes (STARTED o GLOBAL, por ejemplo), aunque debe tenerse siempre presente que el nivel de autoridad ALTER, sobre un perfil discreto, confiere autoridad administrativa (generalmente no deseada). Sintaxis: PERMIT|PE nombre-del-perfil CLASS(clase) [ID({usuario/grupo...|*})] ACCESS(nivel)|DELETE] [FROM(perfil2)] [FCLASS] [FGENERIC] [FVOLUME(volumen)] [RESET(ALL|STANDARD|WHEN)] [WHEN([APPCPORT({partner-luname|*})] [CONSOLE({consola|*})] [JESINPUT({nombre-input-device|*})] [PROGRAM({programa|*})] [SYSID({sysid|*})] [TERMINAL({terminal|*})])] El nombre-del-perfil es requerido y debe estar inmediatamente a continuacin del comando PERMIT. CLASS indica la clase a la que pertenece el perfil. Como ya hemos visto, el valor por defecto es DATASET, por lo cual debe codificarse obligatoriamente para una clase de recursos generales.

Apuntes de RACF

Juan Mautalen

97 ID indica el usuario o grupo cuya entrada en la lista de acceso se desea agregar, modificar o eliminar. Separados por espacios pueden ingresarse ms de un usuario/grupo. Tambin se acepta el valor *, que representa un usuario cualquiera existente en la base de RACF. ACCESS establece el nivel de autoridad que se quiere otorgar al usuario/grupo especificado en el operando ID. Los posibles valores son NONE, EXECUTE, READ, UPDATE, CONTROL y ALTER. Si se codifica ACCESS sin poner ningn valor, se asume READ. DELETE indica que se pretende borrar de la lista de acceso la entrada correspondiente al usuario/grupo codificado en el operando ID. En ambos casos, ya sea con ACCESS o DELETE, RACF acta sobre la lista de acceso estndar, excepto que se codifique explcitamente el operando WHEN, que indica que se pretende modificar la lista de acceso condicional. Si se especific ID, pero se omiti tanto ACCESS como DELETE, se asume por defecto ACCESS(READ). FROM especifica el nombre de otro perfil (discreto o genrico) del cual se quieren copiar las listas de acceso (estndar y condicional). Las entradas en las listas de acceso del perfil2 son agregadas a las listas de acceso correspondientes. Es decir, el operando FROM no convierte en idnticas las listas de acceso de ambos perfiles. Ms an, si una entrada que figura en la lista de acceso del perfil2 ya se encuentra en la del perfil en cuestin, entonces la misma no se modifica. FCLASS indica la clase a la que pertenece el perfil especificado en el operando FROM. Si omite FCLASS y se codific FROM, se asume por defecto que perfil2 pertenece a la misma clase que el perfil en cuestin. FGENERIC indica a RACF que el perfil especificado en el operando FROM es genrico, an cuando no contenga caracteres genricos. Por lo tanto, solo tiene sentido si perfil2 es un perfil de dataset. RACF ignora el operando FGENERIC si no se codific FROM. Si el operando FROM especifica un perfil discreto de DATASET, el operando FVOLUME debe indicar el volumen correspondiente. Si se codificara FVOLUME con un valor distinto al que corresponde al perfil2, o si se omite y existe ms de un perfil discreto con ese nombre, el comando falla. Si no se especific el operando FROM, o se codific con un perfil genrico, o con un perfil de una clase que no sea DATASET, el operando FVOLUME es ignorado. El operando RESET indica que se pretende vaciar una o ambas listas de acceso (es decir, eliminar todas las entradas). RESET(STANDARD) vaca nicamente la lista de acceso estndar, en tanto que RESET(WHEN) hace lo propio con la condicional. RESET(ALL) vaca ambas. Si se codifica RESET sin ningn valor, se asume por defecto ALL. El operando WHEN indica que se quiere modificar la lista de acceso condicional. No describiremos los distintos suboperandos que admite. Si se omite WHEN, las modificaciones se efectan sobre la lista de acceso estndar (aunque los operandos FROM o RESET pueden impactar igualmente sobre la lista de acceso condicional). 6.11 - Comando SEARCH Sintaxis: SEARCH|SR [CLASS({DATASET|clase})] [{ALL|GENERIC|NOGENERIC|MODEL|TAPE|VSAM|NOVSAM}] [CATEGORY(categora)|EXPIRES(valor)|LEVEL(valor)| SECLABEL(label)|SECLEVEL(level)|WARNING] [FILTER(cadena)] [{MASK({cadena1|*}[,cadena2])|NOMASK}] [USER(usuario)] [AGE(valor)] [CLIST[(cadena1[cadena2])]] El comando SEARCH permite obtener una lista de los nombres de los perfiles de la base que cumplan con determinados criterios.
Apuntes de RACF Juan Mautalen

98 CLASS especifica la clase dentro de la cual se buscan los perfiles. Se puede codificar DATASET, USER, GROUP o cualquier otra clase definida en la CDT. Si se omite, el valor por defecto es DATASET. ALL indica que se listen todos los perfiles genricos o discretos- que satisfagan los dems criterios fijados por los restantes parmetros del comando SEARCH. GENERIC restringe la bsqueda a perfiles genricos, mientras que NOGENERIC la limita a perfiles discretos. Las opciones MODEL|TAPE|VSAM|NOVSAM solo tienen sentido para la clase DATASET (son directamente ignoradas si la clase especificada es otra). El valor por defecto es ALL. CATEGORY|EXPIRES|LEVEL|SECLABEL|SECLEVEL|WARNING Mediante estos operandos se establecen criterios de bsqueda. No nos ocuparemos de CATEGORY, SECLABEL y SECLEVEL.
o

EXPIRES solo se aplica a la clase TAPEVOL. El valor debe estar comprendido entre 0 y 65533, o bien ser 99999 (archivos que nunca expiran). Si se codifica, solo se listarn los volmenes tales que todos sus archivos, o bien ya se encuentren expirados, o bien lo harn dentro de la cantidad de das especificados. LEVEL establece que se listen los perfiles cuyo LEVEL coincida con el especificado. Recordemos que se trata de un campo de uso administrativo, cuyo valor est comprendido entre 00 y 99. Si la clase es USER o GROUP, este operando es ignorado. WARNING indica que se listen los perfiles que se encuentre en modo warning. Si la clase es USER o GROUP, este operando es ignorado.

FILTER permite indicar una cadena de caracteres (incluyendo los caracteres comodn %, * y **), de modo que sean listados nicamente los perfiles cuyos nombres estn alcanzados por el patrn establecido. El significado de los caracteres genricos es similar al que tienen en el caso de perfiles, y pueden codificarse en cualquier calificador (incluso en el primero): - % indica un nico carcter cualquiera (inclusive % y *) - * indica la presencia de 0 ms caracteres (inclusive genricos) hasta concluir el calificador. Si es usado como un calificador completo, exige la existencia de ese calificador en los nombres que abarca. - ** indica la presencia de 0 o ms calificadores. Slo puede usarse como un calificador completo. Ejemplo: FILTER(a%%.xy*.*.**) alcanzara a los siguientes nombres de perfiles: a21.xyzw.asdf.qwe.fin aa*.xyz%%%.qwe Sin embargo, no alcanzara a: ab23.xyz.efgh.qwe (tiene 4 caracteres en el primer calificador) a21.xyw* (no tiene un tercer calificador, que es exigido) El operando MASK, excluyente con el operando FILTER, brinda un medio alternativo para filtrar perfiles:
o

Cadena1 indica una secuencia de caracteres con la que deben empezar los nombres de los perfiles buscados. Se admiten caracteres genricos, pero pierden su significado comodn y son exigidos literalmente. Si se codifica * y la clase es DATASET, el identificador del usuario que ejecuta el comando se toma como mscara. Cadena2 establece, opcionalmente, una segunda cadena de caracteres que debe contener el nombre del perfil en cualquier lugar a continuacin de cadena1. Tambin en este caso se

Apuntes de RACF

Juan Mautalen

99 admiten caracteres genricos, pero no tienen su significado usual sino que son tomados literalmente. NOMASK establece que se listen todos los perfiles de la clase que cumplan con el resto de los criterios. En realidad, solo son listados aquellos que el usuario est autorizado a ver. Si no se codifica MASK|NOMASK (ni FILTER), entonces el defecto es MASK(*). Notemos que para todas las clases excepto DATASET, NOMASK y MASK(*) son equivalentes, ya que no fijan restricciones sobre los nombres de los perfiles. El operando FILTER es ms flexible que MASK, pues permite criterios de bsqueda ms sofisticados. El operando USER(usuario) indica que se deben listar los perfiles que cumplan con los criterios de seleccin establecidos y sobre los cuales el usuario codificado tenga autoridad READ o superior, o bien sea el owner. Si la clase especificada es GROUP, sern listados los grupos para los cuales el usuario codificado est conectado con autoridad CONNECT o JOIN, est conectado con atributo SPECIAL o AUDITOR, o sea el owner. AGE establece que se listen nicamente los perfiles que no han sido referenciados dentro de la cantidad de das especificados (contados hacia atrs desde el actual). El valor codificado debe estar comprendido entre 0 y 99999. Esta opcin funciona nicamente para perfiles discretos de clases para las cuales se mantengan estadsticas. Si la clase es USER, se listarn los usuarios cuyo LAST-ACCESS sea anterior a la fecha que resulte de sustraer a la actual la cantidad de das especificados. En el caso en que LAST-ACCESS tenga el valor UNKNOWN, se toma la fecha de creacin del usuario como referencia. Si la clase es GROUP, se listarn los grupos que hayan sido creados con anterioridad a la fecha que resulte de sustraer a la actual la cantidad de das especificados. El operando CLIST determina que se genere una CLIST (command list) con los nombres de los perfiles que resulten de la bsqueda (1 registro por cada perfil encontrado). La lista se graba en un archivo de nombre PREFIX.EXEC.RACF.CLIST, dnde PREFIX indica el prefix de TSO del usuario que ejecuta el comando SEARCH (si tuviera noprefix en su profile de TSO, su identificador de usuario se usara como HLQ del dataset). Es importante recalcar que el comando solo genera la CLIST. No la ejecuta. o Cadena1, que debe codificarse entre apstrofes simples, establece el texto que se antepondr en cada registro al nombre del perfil. o Cadena2, que debe estar igualmente entre apstrofes simples, establece el texto que se agregar en cada registro inmediatamente a continuacin del nombre del perfil. Adicionalmente, un nmero de secuencia de 8 posiciones es colocado al principio de cada registro. El operando CLIST es til cuando se quiere ejecutar idnticos comandos de RACF sobre los perfiles que resulten de la bsqueda. Ejemplo: Supongamos que se pretende listar la informacin completa de todos los perfiles de la clase FACILITY cuyo nombre empiece con la cadena de caracteres STGADMIN. Para ello, debera ejecutarse el comando: SEARCH CLASS(facility) MASK(stgadmin) CLIST(rlist facility all) Intencionalmente se han especificado espacios al final de cadena1 y al principio de cadena2, de modo que los comandos resulten sintcticamente correctos. El archivo grabado podra tener los siguientes registros:
00000010RLIST FACILITY STGADMIN.ADR.** ALL 00000020RLIST FACILITY STGADMIN.IDC.** ALL 00000030RLIST FACILITY STGADMIN.IGG.** ALL 00000040RLIST FACILITY STGADMIN.** ALL

Apuntes de RACF

Juan Mautalen

100 Luego, bastara ejecutarlos a travs del comando EXEC de TSO. Autoridad requerida Todo usuario est autorizado a ejecutar el comando SEARCH, solo que nicamente le sern mostrados los nombres de los perfiles que este autorizado a ver. Bsicamente, para poder ver el nombre de un perfil, quien ejecuta el comando debe cumplir con alguna de las condiciones siguientes: Tener el atributo SPECIAL o AUDITOR a nivel de sistema o a nivel de un grupo que tenga al perfil dentro de su campo de accin. Tener el atributo OPERATIONS a nivel de sistema o a nivel de un grupo que tenga al perfil dentro de su campo de accin y la clase estar alcanzada por este atributo. Tener autoridad READ (o superior) sobre el perfil. Para poder usar SEARCH con el operando USER, quien ejecuta el comando debe cumplir con alguna de las condiciones siguientes: Tener el atributo SPECIAL o AUDITOR a nivel de sistema o a nivel de un grupo que tenga al usuario del operando USER dentro de su campo de accin. Ser el owner del usuario codificado en el operando USER El usuario codificado en el operando USER debe coincidir con el propio.

Apuntes de RACF

Juan Mautalen

101 7 - CLASES PARTICULARES 7.1 - Consideraciones generales Existe una gran cantidad de clases de recursos generales, que permiten proteger recursos de muy variada naturaleza. Como ya comentramos, una organizacin puede normalmente manejar satisfactoriamente su seguridad activando solo una cantidad limitada de ellas. Un administrador de RACF debe conocer perfectamente el funcionamiento y alcance de las clases que se utilizan efectivamente en su organizacin. Algunas de estas clases estn descriptas en detalle en la bibliografa de RACF, mientras que otras son tratadas en profundidad en la documentacin del producto que las utiliza. Analizaremos a continuacin algunas clases de recursos generales que consideramos particularmente importantes y cuyo uso es muy frecuente. 7.2 - Clase GLOBAL Podemos imaginar a la tabla de acceso global, que abreviaremos GAC (Global Access Checking Table), como una tabla que contiene una lista de recursos asociados con un determinado nivel de acceso. La GAC permite autorizar el acceso a un recurso a cualquier usuario (con excepcin nicamente de aquellos con el atributo RESTRICTED), sin que RACF analice el perfil protector. En efecto, durante el proceso de chequeo de autorizacin que lleva a cabo RACF, que estudiaremos en forma precisa en un captulo posterior, la GAC se consulta en primera instancia. Si la informacin que contiene indica que el acceso debe otorgarse, RACF responde favorablemente sin continuar con el chequeo habitual de perfiles. Es importante recalcar que la GAC puede autorizar un requerimiento de acceso, pero nunca rechazarlo. Si no contiene informacin que autorice el requerimiento, RACF contina con su chequeo habitual. Por lo tanto, la GAC solo puede utilizarse para responder favorablemente solicitudes de acceso. nicamente acta la GAC para aquellas clases que tienen GLOBAL especificado en la SETROPTS. Por lo tanto, si se pretende definir reglas en la GAC para una determinada clase, debe activarse su chequeo de la GLOBAL, ejecutando el comando: SETROPTS GLOBAL(clase) Recordemos que la clase especificada no puede ser una clase agrupadora. Construccin y mantenimiento de la GAC GLOBAL es, en realidad, una clase de RACF. Para definir reglas en la GAC para una determinada clase, debe definirse en principio un perfil en la clase GLOBAL cuyo nombre coincida con el de la clase. Las reglas se definen luego como miembros del perfil, a travs del operando ADDMEM. Las reglas se componen de un nombre de recurso acompaado del correspondiente nivel de acceso. El nombre de recurso debe seguir los mismos lineamientos que los perfiles de la clase, con las siguientes importantes flexibilidades adicionales: o Si la clase en cuestin tiene GENCMD especificado en la SETROPTS, los caracteres genricos pueden usarse en cualquier calificador, incluso el primero. o Los nombres de recurso pueden contener las variables &RACUID y &RACGPID como calificadores. &RACUID se reemplaza por el usuario actual mientras que la variable &RACGPID indica su actual grupo de conexin. o Los nombres de recurso pueden incluir variables definidas en la clase RACFVARS. El nivel de acceso puede ser NONE, READ, UPDATE, CONTROL o ALTER (EXECUTE no est permitido en la GAC). Los siguientes comandos muestran como incorporar una regla en la GAC para una determinada clase:

Apuntes de RACF

Juan Mautalen

102 RDEFINE GLOBAL clase RALTER GLOBAL clase ADDMEM(nombre-del-recurso/nivel de acceso) Para borrar una regla existente, el comando sera: RALTER GLOBAL clase DELMEM(nombre-del-recurso/nivel-de-acceso) Debe tenerse cuidado, ya que si en lugar de RALTER se especifica RDELETE, el comando no solo borrara la regla en cuestin sino que deleteara el perfil, con lo cual se eliminaran todas las reglas de la GAC para la clase. En cualquier caso, luego de efectuar una modificacin en la GAC para cierta clase, la misma solo entra en vigencia luego de ejecutar el siguiente comando de refresh: SETROPTS GLOBAL(clase) REFRESH Ejemplo: Vamos a mostrar una secuencia de comandos que define una serie de reglas en la GAC para la clase DATASET. En este ejemplo, se pretende que todos los archivos cuyo HLQ es SYS1 sean accedidos por todos los usuarios con autoridad READ, con excepcin del dataset SYS1.UADS. Asimismo, se pretende otorgar UPDATE a todos los usuarios a los catlogos de usuario, cuyos nombres suponemos tienen HLQ igual a USRCAT (y son los nicos con este HLQ). Asumimos que en la SETROPTS la clase DATASET est bajo GENCMD y que la opcin EGN est activa. Asimismo, suponemos que no existe el perfil DATASET en la clase GLOBAL y que la misma no est bajo GLOBAL en la SETROPTS. 1) SETROPTS GLOBAL(dataset) 2) RDEFINE GLOBAL DATASET 3) RALTER GLOBAL DATASET ADDMEM(sys1.**/read) 4) RALTER GLOBAL DATASET ADDMEM(sys1.uads/none) 5) RALTER GLOBAL DATASET ADDMEM(usrcat.**/update) 6) SETROPTS GLOBAL(dataset) REFRESH Cuando RACF analiza el contenido de la GAC para resolver sobre una solicitud de acceso, procede de manera similar a como lo hace con perfiles. Esto es, RACF detecta la entrada que mas se ajusta al recurso solicitado y en base a ella decide si debe otorgar el acceso inmediatamente, o bien debe seguir con el proceso de chequeo habitual. En nuestro ejemplo, si un usuario intenta leer el archivo SYS1.UADS, RACF consulta las reglas para la clase DATASET en la GAC (ya que DATASET est bajo GLOBAL en la SETROPTS), y encuentra que la entrada que ms se ajusta es SYS1.UADS, cuyo nivel de acceso asociado es NONE. Por lo tanto, la GAC no permite otorgar el acceso solicitado, y RACF contina con el anlisis de los perfiles correspondientes (recordemos que la GAC nunca rechaza por s misma un requerimiento de acceso). Consideraciones: Los usuarios con el atributo RESTRICTED son los nicos que no pueden obtener acceso a un recurso a travs de la GAC. An cuando exista en la GAC una regla que permita acceder a un recurso bajo cierto nivel de autoridad, es conveniente garantizar idntico acceso a travs del UACC del perfil protector. Esto evita problemas si involuntariamente se borra la regla de la GAC, o se inhabilita en la SETROPTS la opcin GLOBAL para la clase. Por ejemplo, si tenemos la siguiente regla en la GAC: USRCAT.**/UPDATE resulta conveniente tener asimismo un perfil de dataset USRCAT.** con UACC(UPDATE).

Apuntes de RACF

Juan Mautalen

103 Para ciertas aplicaciones que utilizan la macro RACROUTE REQUEST=FASTAUTH, la GAC no acta. CICS es un ejemplo de ello. Si el acceso a un recurso es otorgado por la GAC, RACF no actualiza las eventuales estadsticas que pudiera tener el perfil protector. Mas an, RACF ni siquiera determina qu perfil protege efectivamente al recurso. Si el acceso a un recurso es otorgado por la GAC, RACF no tendr en cuenta el nivel de auditora del perfil protector (ya que dicho perfil no es ni siquiera determinado). Acta, sin embargo, la opcin global de auditora para la clase establecida en la SETROPTS a travs del operando LOGOPTIONS. Una regla en la GAC con nivel de autoridad NONE solo tiene sentido si existe otra regla para la misma clase con autoridad superior y que sea mas permisiva (ver el ejemplo anterior). Cuando se listan las reglas existentes en la GAC para una determinada clase, con el comando RLIST GLOBAL clase, las mismas se muestran ordenadas segn el criterio de mayor especificidad. El uso de la GAC puede mejorar la performance al evitarse, en muchos casos, costosos I/O sobre la base de RACF. Son excelentes candidatos para la GAC recursos de uso muy frecuente que deban ser accedidos en forma universal. 7.3 - Clase STARTED Una started task, tambin conocida como STC, en un procedimiento que se arranca con el comando de operador START (o bien asociada directamente con un componente del sistema operativo, como DFSMS). Reside en bibliotecas de procedimientos declaradas en la parametrizacin del JES (SYS1.PROCLIB, por ejemplo). Las STC, a diferencia de los trabajos batch, no tienen una tarjeta job dnde figure usuario y grupo (o que se reciban propagados). Por lo tanto, como bsicamente solo usuarios o grupos definidos en RACF pueden acceder a recursos protegidos, es necesario que las STC tengan una identidad asignada. Naturalmente, el usuario debe estar conectado al grupo especificado. Si la opcin GRPLIST no est activa en la SETROPTS opcin improbable en la actualidad-, entonces solo se tendr en cuenta el grupo especificado al momento de resolver solicitudes de acceso del usuario a recursos protegidos. En cambio, si como recomendamos, est activa la opcin GRPLIST, entonces el grupo de conexin resulta irrelevante y el usuario tendr acceso a los recursos a travs de cualquiera de sus grupos. La asignacin de usuario y grupo puede realizarse a travs de la definicin de un perfil en la clase STARTED o mediante una entrada apropiada en una tabla assembler de nombre ICHRIN03 (Started Procedures Tables). Si la clase STARTED est activa, RACF busca en principio un perfil en esta clase que asigne una identidad vlida al procedimiento. Si no lo encuentra, recin entonces examina la ICHRIN03. La ICHRIN03 es una tabla residente en la LPA (Link Pack Area) o en la MLPA (Modified Link Pack Area). Debe compilarse y linkeditarse como si se tratara de un programa assembler, an cuando solo contenga definiciones de constantes y carezca de instrucciones propiamente dichas. Ms an, luego de modificado, para que el nuevo mdulo entre en vigencia es necesario dar IPL, ya que no es posible refrescarlo dinmicamente dado el sector de memoria donde se aloja. Estos inconvenientes hacen que la utilizacin de esta tabla esttica de asignacin sea muy poco prctica, razn por la cual IBM introdujo la clase STARTED, que permite un manejo dinmico. De todos modos, tengamos presente que el mdulo ICHRIN03 debe existir, ya que en caso contrario RACF no inicializa. Recomendamos tener una ICHRIN03 mnima, con entradas nicamente para ciertas started task crticas del sistema operativo. Esto permitir que inicie el sistema operativo ante una eventual inactivacin involuntaria de la clase

Apuntes de RACF

Juan Mautalen

104 STARTED. No entraremos en detalles en esta gua sobre la construccin de la ICHRIN03, pero ejemplos concretos se pueden consultar en la documentacin de IBM. Recursos y perfiles de la clase STARTED En lo que sigue, vamos a suponer que la clase STARTED est activa, RACLISTeada y que admite perfiles genricos. Esto se logra ejecutando el siguiente comando: SETR CLASSACT(STARTED) RACLIST(STARTED) GENERIC(STARTED) Con las versiones actuales del z/OS, el comando START de MVS permite startear no solo una STC sino tambin un job. Para simplificar, vamos a ocuparnos exclusivamente del caso de procedimientos, ya que es lo ms frecuente. Al arrancarse una STC, si no se especifica en el comando START un jobname distinto, se construye el nombre de recurso miembro.miembro, dnde miembro indica el miembro de la biblioteca dnde se encuentra el procedimiento (el nombre del procedimiento propiamente dicho, establecido en la primer sentencia del JCL, no entra en juego). Si, por el contrario, se especificara el parmetro JOBNAME en el comando START, el recurso correspondiente sera miembro.jobname. RACF busca entonces el perfil en la clase STARTED (discreto o genrico) que ms se ajuste a este nombre y lo usa para la asignacin de identidad. Ejemplo: Supongamos que se ejecuta el siguiente comando de operador: START cnmproc RACF, para asignar identidad al procedimiento, busca en la clase STARTED el perfil que ms se ajuste al nombre cnmproc.cnmproc, que podra ser, por ejemplo, el perfil genrico cnmproc.*. Definicin de un perfil de la clase STARTED Sintaxis: RDEFINE|RDEF STARTED nombre-del-perfil [DATA(installation-data)] [OWNER(usuario/grupo)] [STDATA([USER(usuario|=MEMBER)] [GROUP(grupo|=MEMBER)] [PRIVILEGED(NO|YES)] [TRUSTED(NO|YES)] [TRACE(NO|YES)]) Notemos que, al no tratarse de perfiles que protejan acceso a recursos, los campos UACC, AUDIT y listas de acceso, entre otros, resultan irrelevantes. La informacin determinante de los perfiles de la clase STARTED se encuentra en el segmento no base denominado STDATA, cuyos campos describiremos a continuacin USER establece el usuario que se asociar con el procedimiento. Si el usuario codificado no existe en la base, RACF alerta sobre la situacin emitiendo un mensaje, pero la definicin se realiza de todos modos. Existe la opcin de codificar el valor =MEMBER en lugar de un identificador de usuario, en cuyo caso RACF asignar el usuario que coincida con el nombre del miembro -si existiera. GROUP establece el grupo que se asociar con el procedimiento. Si el grupo codificado no existe, o si el usuario especificado en el operando USER no se encuentra conectado a l, RACF alerta sobre la situacin enviando un mensaje, pero tambin aqu la definicin se realiza de todos modos. Existe la opcin de codificar el valor =MEMBER en lugar del nombre de un grupo, en cuyo caso RACF asignar al procedimiento el grupo que coincida con el nombre del miembro -si existiera. PRIVILEGED=YES indica que todos los accesos que solicite el procedimiento (salvo contadsimas excepciones, muy poco frecuentes y que no vale la pena mencionar) sern otorgados, sin efectuar el chequeo correspondiente. Tales accesos exitosos no actualizarn estadsticas ni generarn registros de SMF, an cuando la configuracin de auditora lo requiera. El valor por defecto es PRIVILEGED=NO.

Apuntes de RACF

Juan Mautalen

105 TRUSTED=YES se comporta de manera similar a PRIVILEGED=YES, con la diferencia de que s se generarn registros de SMF de acuerdo a la configuracin de auditora correspondiente. El valor por defecto es TRUSTED=NO. La mayora de las STC no deben estar marcadas ni TRUSTED ni PRIVILEGED, tal cual es el defecto. Deben tener un usuario asignado que tenga solo los accesos necesarios. Sin embargo, existen ciertos procedimientos crticos del sistema operativo para los cules IBM recomienda estos atributos, para evitar que una eventual falta de autorizacin cause serios trastornos operativos, o incluso que el sistema no inicie o funcione correctamente. En estos casos, recomendamos usar TRUSTED en lugar de PRIVILEGED, para contar eventualmente con alguna informacin de auditora grabada en registros SMF. Debe sealarse, de todos modos, que la posibilidad de auditar una tarea marcada TRUSTED es bastante limitada y poco flexible. En efecto, al otorgarse los accesos sin consulta a los perfiles protectores, las opciones de auditora que stos tengan configuradas no son tomadas en cuenta. Por lo tanto, slo se generarn registros de auditora si el usuario tuviera el atributo UAUDIT, o si la clase a la que pertenece el recurso estuviera auditada a nivel de la SETROPTS. En el primer caso, se grabara informacin para todos los accesos de la STC, sin posibilidad de discriminacin alguna. Si, por el contrario, se audita una clase especfica, no solo se grabara informacin para esta STC sino para todos los accesos a recursos protegidos en la clase, pudindose generar un volumen muy grande de informacin innecesaria. En definitiva, la auditora de una STC indicada como TRUSTED, si bien posible, suele ser problemtica. JES2 es un ejemplo de un procedimiento que se aconseja ejecutar como TRUSTED. Ms adelante damos una lista de STC que IBM sugiere ejecutar como TRUSTED. TRACE=YES indica que RACF informar, mediante un mensaje por consola, toda vez que el perfil sea usado para la asignacin de usuario. Esta opcin puede resultar til como herramienta de diagnstico para resolver ciertos problemas. El valor por defecto es TRACE=NO. Para modificar, borrar o listar perfiles de la clase STARTED se utilizan los comandos habituales de manejo de perfiles de clases de recursos generales, a saber: RALTER; RDELETE y RLIST. Para cambiar el valor de un campo del segmento STDATA, debe codificarse el operando STDATA en el comando RALTER especificando solo el suboperando a modificar. Para listar la informacin completa de un perfil de la clase STARTED debe ejecutarse el comando RLIST STARTED nombre-del-perfil STDATA. Si se omite STDATA, solo se mostrar la informacin del segmento base y no se visualizar la informacin determinante para la asignacin de identidad. Consideraciones: Si una started task no adquiere una identidad vlida, corre bajo un usuario indefinido, y solo puede acceder a los recursos cuyo UACC sea lo suficientemente permisivo. Estando la clase STARTED activa como es absolutamente recomendable-, solo en los casos siguientes RACF consultar la ICHRIN03:
o o o

No existe un perfil en la clase STARTED Existe un perfil pero sin segmento STDATA. Existe un perfil con segmento STDATA pero sin usuario especificado.

En cambio, en cualquiera de los casos siguientes, no se consultar la ICHRIN03 y la STC ejecutar con usuario indefinido: o Existe un perfil con segmento STDATA pero el usuario especificado no existe en la base. o Existe un perfil con segmento STDATA pero el grupo especificado no existe en la base. o Existe un perfil con segmento STDATA, con usuario y grupo vlidos, pero el usuario no est conectado al grupo.

Apuntes de RACF

Juan Mautalen

106 En el inicio de una STC, RACF no chequea la eventual revocacin del usuario asignado. Esto determina que el procedimiento efectivamente arrancar, an cuando el usuario se encuentre revocado. Sin embargo, es probable que la tarea tenga problemas posteriormente, si alguna accin que lleve a cabo controle efectivamente esta condicin (por ejemplo, si la STC submite un job al internal reader). Por lo tanto, es aconsejable verificar regularmente que los usuarios asociados con las STC no se encuentren revocados. Si un usuario es utilizado exclusivamente para ser asignado a una started task, entonces es un excelente candidato para otorgarle el atributo PROTECTED. De esta manera se evitan usos indebidos del usuario, as como tambin revocaciones maliciosas por intentos de logon fallidos ingresando passwords incorrectas. La asignacin del usuario a la STC se realiza en el momento de su inicio. En consecuencia, tanto si se cambia el usuario asignado como si se le otorga (o quita) algn atributo, la modificacin solo tomar efecto una vez que se recicle la STC (es decir, que se pare y reinicie). Con el objeto de mantener un adecuado control de las STC en el sistema, recomendamos definir un perfil de contencin ** en la clase STARTED, cuyo usuario asignado no tenga ninguna autorizacin explcita sobre ningn perfil. De este modo, toda STC que no tenga un perfil ms especfico solo podr acceder a recursos va UACC (o * en la lista de acceso), lo cual no debera ser peligroso desde la perspectiva de la seguridad. Una opcin an ms radical consistira en otorgarle a tal usuario el atributo RESTRICTED, en cuyo caso el procedimiento no podra acceder a ningn recurso protegido. Es de destacar que estando correctamente definido este backstop en la clase STARTED, RACF nunca revertir a la ICHRIN03 en su proceso de asignacin de identidad. En cualquier caso, lo realmente importante es que toda STC se encuentre perfectamente identificada y con un usuario debidamente asignado a travs de la clase STARTED, que detente nicamente las autorizaciones necesarias para sus tareas. Asimismo, y de manera complementaria, deben estar adecuadamente protegidas las bibliotecas de procedimientos declaradas en JES. La clase STARTED debe necesariamente estar RACLITeada. Sin embargo, en este caso particular, RACF no carga en memoria toda la informacin de sus perfiles sino solo sus nombres. Una vez que determina el perfil que usar para asignar identidad (operacin rpida, pues tiene los nombres en memoria virtual) har un I/O sobre la base para extraer el segmento STDATA correspondiente. Una consecuencia de esto es que, si solo se modifica un campo del segmento STDATA de un perfil existente, no ser normalmente necesario ejecutar el comando de REFRESH. IBM recomienda que los siguientes procedimientos se ejecuten como TRUSTED: CATALOG, DUMPSRV, DFHSM, DFS, GPMSERVE, IEEVMPCR, IOSAS, IXGLOGR, JES2 o JES3, JESXCF, LLA, NFS, OMVSKERN, RACF, RMF, RMFGAT, SMSVSAM, SMF, TCPIP, VLF, VTAM, XCFAS. Aconsejo fuertemente seguir las recomendaciones de IBM y asignar TRUSTED siempre que se lo sugiera. 7.4 - Clase PROGRAM El funcionamiento de la clase PROGRAM es ciertamente complejo, y exponerlo en detalle est fuera de los objetivos de este curso introductorio. Por ejemplo, no discutiremos en esta gua ninguno de los siguientes temas: Modo de proteccin ENHANCED. Aporta un nivel de proteccin mayor que el modo BASIC. Su implementacin requiere un importante esfuerzo de configuracin de perfiles en la clase PROGRAM (y slidos conocimientos en la materia). No resulta habitualmente necesario. En la
Apuntes de RACF Juan Mautalen

107 primera lnea del listado de la SETROPTS se visualiza claramente si el control de programas est activo y en qu modo. Acceso a archivos condicionado a la ejecucin de determinado programa, esquema conocido como PADS (Program Access to Data Sets). Nivel de autoridad EXECUTE y entorno limpio (clean environment). Nos limitaremos pues a exponer ciertas nociones bsicas relacionadas con la clase PROGRAM que todo administrador de RACF debe conocer. En la gran mayora de los casos, ms que proteger un determinado medio de acceso, como es en definitiva un programa, deberan centrarse los esfuerzos en proteger adecuadamente los recursos a los que permite acceder. As, por ejemplo, no tiene mayor sentido proteger el programa invocado por el FTP (que no deja de ser uno de los tantos posibles mtodos de transferencia), sino que lo fundamental consiste en proteger los datos, con perfiles de dataset adecuados. Como ya hemos sealado, la clase PROGRAM presenta ciertas particularidades que ya hemos mencionado, pero conviene recordar en este punto: A diferencia de las otras clases, para activar el control de programas bajo RACF no es necesario activar la clase PROGRAM, sino que debe especificarse WHEN(PROGRAM) como opcin en la SETROPTS. Si se modifica informacin de perfiles en la clase PROGRAM, debe ejecutarse el comando SETROPTS WHEN(PROGRAM) REFRESH para que los cambios tomen efecto. Los perfiles de la clase PROGRAM no soportan el modo warning. Proteccin de programas Todo programa reside en una biblioteca particionada, que puede ser pblica, como aquellas que figuran en la LINKLIST, o de uso privado. Es posible, y realmente frecuente aunque poco recomendable, que el mismo nombre de programa exista en ms de una biblioteca, pudiendo tratarse de distintas o idnticas versiones, o bien de programas francamente diferentes. Un programa que se encuentra protegido por un perfil en la clase PROGRAM se denomina programa controlado. RACF solo permite proteger un programa dentro de una biblioteca especfica. El nombre del perfil debe matchear con el nombre del programa a proteger, mientras que la biblioteca dnde reside especficamente la versin en cuestin debe definirse como miembro del perfil. Un programa puede controlarse bajo RACF con diversos objetivos, entre los que podemos mencionar: Para controlar qu usuarios/grupos estn autorizados a ejecutarlo. Porque es una exigencia del sistema que el programa est controlado (usualmente, para mantener lo que se conoce como entorno limpio). Para hacer uso de la funcionalidad PADS. En lo referente al segundo punto, es altamente recomendable, tal cual veremos en los ejemplos subsiguientes, definir un perfil ** en la clase PROGRAM con UACC=READ y una lista de bibliotecas asociadas cuyos programas necesiten estar controlados. Definicin de un perfil de la clase PROGRAM Sintaxis: RDEFINE|RDEF PROGRAM nombre-del-perfil [DATA(installation-data)] [OWNER(usuario/grupo)] [ADDMEM(nombre-de-la-biblioteca/[volumen]/{PADCHK|NOPADCHK}] El nombre del perfil, al tener que matchear con el nombre del programa, debe constar de un nico calificador y no exceder los 8 caracteres. Si bien la clase PROGRAM no admite perfiles genricos, es
Apuntes de RACF Juan Mautalen

108 posible usar el caracter * al final del nombre del perfil, que indica la presencia de 0 o ms caracteres (hasta una longitud mxima de 8). Tambin es posible definir un perfil **. Sin embargo, al listarlos, como se trata realmente de perfiles discretos, no aparecer la caracterstica (G) a continuacin del nombre del perfil, como s sucede con los perfiles genricos genuinos. A travs del operando ADDMEM se especifica la biblioteca dnde reside el programa a controlar, junto con ciertos parmetros adicionales. Con posterioridad a la creacin del perfil, pueden agregarse o eliminarse bibliotecas de la lista usando el comando RALTER con los operandos ADDMEM o DELMEM, segn corresponda. El nombre de la biblioteca debe ponerse entre apstrofes simples, ya que en caso contrario RACF antepone automticamente como HLQ el PREFIX de TSO del usuario que ejecuta el comando. El volumen es opcional, y especifica el disco dnde reside la biblioteca. Existe la posibilidad de codificar el valor ****** (incluidos los apstrofes), lo cual indica que la biblioteca se encuentra alocada en el SYSRES (disco residente). En caso de no especificarse volumen, que es lo ms habitual, la biblioteca puede existir en cualquier disco. La opcin PADCHK|NOPADCHK hace referencia a la funcionalidad PADS, que no trataremos en esta gua. Si no se utiliza PADS, es conveniente codificar explcitamente NOPADCHK (el valor por defecto es PADCHK). Ejemplos: 1. RDEFINE PROGRAM adrdssu UACC(none) ADDMEM(sys1.linklib//NOPADCHK) 2. RDEFINE PROGRAM fin* UACC(none) ADDMEN(finanzas.loadlib//NOPADCHK) 3. RDEFINE PROGRAM ** UACC(read) ADDMEN(sys1.linklib//NOPADCHK) En ningn caso se codific volumen, con lo cual la biblioteca especificada puede residir en cualquiera. El perfil definido en (1) protege exclusivamente al programa ADRDSSU residente en la biblioteca SYS1.LINKLIB. Este perfil no protege a otros programas de nombre ADRDSSU que pudieran existir en otras bibliotecas. Como el UACC del perfil es NONE, solo estaran en condicin de ejecutarlo aquellos usuarios o grupos autorizados va la lista de acceso correspondiente. El perfil definido en (2) protege todos los programas cuyo nombre empiece con la cadena FIN y residan en la biblioteca FINANZAS.LOADLIB, con excepcin de aquellos que pudieran estar protegidos por un perfil ms especfico. El perfil definido en (3) es, como ya sealamos, sumamente til para simplemente controlar sin restringir su ejecucin- los programas de determinadas bibliotecas (generalmente, del sistema operativo). Como ya hemos comentamos, conviene definirlo como ** en lugar de *, de modo de poder listarlo individualmente. En este caso particular, el perfil protege a todos los programas de la biblioteca SYS1.LINKLIB, con excepcin de aquellos que pudieran estar protegidos por un perfil ms especfico (como sera el caso de ADRDSSU, en nuestro ejemplo). Obsrvese que este perfil se defini con UACC=READ, lo cual muestra que su objetivo no es restringir la ejecucin de los respectivos programas sino simplemente convertirlos en controlados. Se le pueden agregar ms bibliotecas a travs del comando RALTER, que mencionamos a continuacin. Modificacin de un perfil de la clase PROGRAM Sintaxis: RALTER|RALT PROGRAM nombre-del-perfil [DATA(installation-data)] [OWNER(usuario/grupo)] [ADDMEM(nombre-de-la-biblioteca/[volumen]/{PADCHK|NOPADCHK}] [DELMEM(nombre-de-la-biblioteca/[volumen])

Apuntes de RACF

Juan Mautalen

109 En la lista de datasets del perfil pueden eventualmente existir varias entradas con el mismo nombre de archivo pero con distintos volmenes asociados. Para eliminar una biblioteca de la lista, basta con usar el operando DELMEM especificando el nombre y el volumen correspondiente (no hace falta codificar PADCHK|NOPADCHK). Si se especifica nicamente el nombre de la biblioteca, se borrar la entrada que no tenga volumen especificado, si sta existiese (en caso contrario, se informa que no existe). Ejemplo: RALTER PROGRAM ** ADDMEN(tcpip.sezalink//NOPADCHK) Este comando agrega a la lista de datasets del perfil ** la biblioteca TCPIP.SEZALINK. En consecuencia, todos los programas de esta biblioteca pasan a ser programas controlados -pero ejecutables por todos los usuarios en virtud del UACC(READ) del perfil. 7.5 - Clase FACILITY La clase FACILITY tiene la particularidad de no estar dedicada a la proteccin de un tipo de recurso especfico, sino que es utilizada por gran cantidad de aplicaciones, productos y componentes del sistema operativo para efectuar chequeos de autoridad sobre recursos de la ms diversa naturaleza. Es incluso frecuente, aunque a veces no del todo recomendable, que una organizacin desarrolle una aplicacin propia cuya seguridad se establezca va RACF a travs de perfiles en la clase FACILITY. Usualmente, la clase FACILITY se encuentra activa. En tal caso, es altamente recomendable que est RACLISTeada y configurada de modo que admita el uso de perfiles genricos. Los perfiles deben tener una longitud mxima de 39 caracteres y los nombres estn determinados por la aplicacin que los utiliza. Todas las consideraciones hechas previamente sobre clases de recursos generales se aplican para la clase FACILITY. Dada la gran variedad de recursos factibles de ser protegidos, no es posible realizar un anlisis exhaustivo de los perfiles en esta clase. Mas an, considerando que cualquier producto (sea de IBM, de otra empresa proveedora de software, o desarrollado por la organizacin) puede potencialmente chequear recursos en la clase FACILITY, la informacin sobre esta clase no aparece centralizada en ninguna documentacin, sino que debe recabarse separadamente en la propia de cada producto. En virtud de lo anterior, no es en absoluto recomendable definir un perfil abarcativo ** en la clase FACILITY. En general, los productos tienen comportamientos dispares frente a la condicin de recurso no protegido (RC=04). Algunos, frente a la ausencia de un perfil protector, autorizan el acceso. Otros, en cambio, lo rechazan. Si se definiese el perfil **, todos los recursos pasaran a estar efectivamente protegidos, lo que significara un cambio cuyas consecuencias presentes y futurasseran difciles de prever. Nos limitaremos pues a mencionar, a modo de ejemplo, algunas facilidades de uso frecuente que pueden ser protegidas en esta clase. Facilidad para listar perfiles de usuario Normalmente, la posibilidad de listar el segmento base de cualquier usuario est reservada a aquellos con el atributo SPECIAL o AUDITOR a nivel de sistema. Ambos atributos, claro est, brindan autorizaciones mucho ms amplias y sensibles que las de simplemente listar la informacin de un perfil de usuario. Por lo tanto, dada la necesidad operativa de dotar a ciertos usuarios con la facilidad de ejecutar el comando LISTUSER (tpicamente personal del Helpdesk), RACF brinda la posibilidad de delegar esta autorizacin a travs de perfiles apropiados de la clase FACILITY. Concretamente, para otorgar a un usuario la facilidad de listar el segmento base de cualquier otro, se debe proceder del siguiente modo:

Apuntes de RACF

Juan Mautalen

110 1) Definir el perfil IRR.LISTUSER en la clase FACILITY, con UACC=NONE. 2) Darle al usuario nivel de autoridad READ. 3) Ejecutar el comando SETR RACLIST(FACILITY) REFRESH (suponemos que la clase FACILITY se encuentra activa y RACLISTeada). Observaciones: Por motivos de seguridad, estn explcitamente excluidos del alcance de la autoridad dada por el recurso IRR.LISTUSER los usuarios con atributo SPECIAL, AUDITOR u OPERATIONS a nivel de sistema. Con excepcin de los usuarios mencionados en el tem anterior, la autorizacin sobre este recurso permite listar cualquier usuario de la base de RACF. Existe, desde la versin 1.10 del z/OS, la posibilidad de darle mucha ms granularidad a esta facilidad. Por ejemplo, es factible otorgar a un usuario la posibilidad de listar nicamente aquellos que tengan un determinado owner, o que se encuentren dentro del campo de accin de determinado grupo. E incluso la posibilidad de excluir, de este universo, ciertos usuarios especficos. No ahondaremos, sin embargo, en los detalles de una implementacin de este tipo en el presente texto, no por considerarla innecesaria, sino por estimar que excede los objetivos planteados. Si el perfil IRR.LISTUSER existe, solo agrega una posibilidad adicional en relacin a la autoridad necesaria para listar perfiles de usuario. Los privilegios habituales siguen siendo suficientes. Por ejemplo, un usuario con atributo AUDITOR a nivel de sistema no requiere estar autorizado a este perfil. Si el perfil IRR.LISTUSER no se encuentra definido, rigen los chequeos de autoridad habituales para el uso del comando LISTUSER. En lugar del perfil discreto mencionado, sera posible definir un perfil genrico que proteja al recurso (ej: IRR.**). Sin embargo, esto no me parece recomendable, ya que este perfil estara abarcando a otros recursos que pueden tener una necesidad de acceso diferente (ver ejemplo posterior). UACC=NONE es apropiado, ya que solo los usuarios cuyas tareas lo justifiquen deben contar con esta facilidad. Niveles de autoridad superiores a READ son equivalentes a READ, y por lo tanto totalmente innecesarios, con la siguiente salvedad: si el perfil es discreto, autoridad ALTER otorga privilegios administrativos sobre el perfil, lo cual probablemente constituya un efecto no buscado. Este recurso no autoriza a listar segmentos no base (TSO, OMVS, etc.). Para ello, deben definirse perfiles adecuados en la clase FIELDS. Facilidad para rehabilitar usuarios y otorgar nuevas passwords Del mismo modo que surgi la necesidad de permitir listar perfiles de usuario (sin necesidad de otorgar privilegios excesivos), tambin apareci naturalmente el requerimiento de dotar a ciertos usuarios de la posibilidad de rehabilitar a cualquier otro y eventualmente otorgarle una nueva password. Para ello, debe procederse del siguiente modo: 1) Definir el perfil IRR.PASSWORD.RESET en la clase FACILITY, con UACC=NONE. 2) Darle al usuario el nivel de autoridad deseado, de acuerdo al siguiente detalle:

Apuntes de RACF

Juan Mautalen

111 READ UPDATE Permite rehabilitar un usuario revocado mediante el operando RESUME del comando ALTUSER. Tambin autoriza a otorgar una nueva password (expirada). Aparte de lo que otorga READ, permite tambin la posibilidad de dar una nueva password no expirada.

CONTROL Aparte de lo que otorga UPDATE, permite asimismo dar una nueva password an sin que haya pasado el tiempo de vida mnimo. 3) Ejecutar el comando SETR RACLIST(FACILITY) REFRESH (suponemos que la clase FACILITY se encuentra activa y RACLISTeada). Observaciones: Por motivos de seguridad, estn explcitamente excluidos del alcance de la autoridad dada por el recurso IRR.PASSWORD.RESET los usuarios con atributo SPECIAL, AUDITOR u OPERATIONS a nivel de sistema. Con excepcin de los usuarios mencionados en el tem anterior, la autorizacin sobre este recurso permite actuar sobre cualquier usuario de la base de RACF. Existe tambin en este caso la posibilidad de darle mucha ms granularidad a esta facilidad. Por ejemplo, es factible otorgar a un usuario la posibilidad de rehabilitar nicamente aquellos que tengan un determinado owner, o que se encuentren dentro del campo de accin de determinado grupo. E incluso la posibilidad de excluir, de este universo, ciertos usuarios especficos. No ahondaremos, sin embargo, en los detalles de una implementacin de este tipo. Si el perfil IRR.PASSWORD.RESET existe, solo agrega una posibilidad extra respecto a la autoridad necesaria para la rehabilitacin de usuarios. Los privilegios habituales siguen siendo suficientes. Por ejemplo, un usuario con atributo SPECIAL a nivel de sistema no necesita autorizacin sobre este perfil. Si el perfil IRR.PASSWORD.RESET no se encuentra definido, rigen los chequeos de autoridad habituales para el uso del comando ALTUSER. El nivel de autoridad ALTER resulta equivalente a CONTROL, con la siguiente salvedad: si el perfil es discreto, otorga privilegios administrativos sobre el perfil, lo cual probablemente constituya un efecto no deseado. Facilidad para acceder a datasets no catalogados Es frecuente, y recomendable, que la organizacin tenga la opcin CATDSNS en modo FAIL seteada en la SETROPTS. De este modo, queda fuertemente restringida la posibilidad de acceder a archivos que no se encuentren catalogados (lo cual debera constituir una situacin de excepcin). Sin embargo, suele suceder que usuarios responsables del mantenimiento del sistema operativo necesiten acceder a datasets no catalogados (por ejemplo, abriendo desde una particin un archivo catalogado en otra). A tal efecto, es factible definir perfiles apropiados en la clase FACILITY que brinden esta facilidad, sin necesidad de dar al usuario el atributo SPECIAL (que permite, asimismo, el acceso a datasets no catalogados). Como ya hemos comentado en un captulo anterior, para datasets no catalogados (y no protegidos por un perfil discreto), RACF construye el recurso de nombre ICHUNCAT.dsname, dnde dsname es el nombre del archivo (solo los 30 primeros caracteres se consideran). RACF chequea entonces la autoridad del usuario sobre este recurso en la clase FACILITY, y si es READ (o superior), entonces no rechaza el acceso por la condicin de no catalogado. Niveles de autoridad superiores a READ en este tipo de perfiles son equivalentes a READ, y por lo tanto innecesarios (este nivel de autoridad no tiene relacin alguna con el nivel de autoridad requerido sobre el perfil de dataset protector del archivo, que
Apuntes de RACF Juan Mautalen

112 depende obviamente del tipo de operacin que se pretende realizar). Naturalmente, sortear el chequeo de no catalogado no elimina de ninguna manera los habituales chequeos posteriores (normalmente, en la clase DATASET). Ejemplo: Supongamos que el usuario SYSPRG1 debe acceder a datasets no catalogados cuyos nombres son de la forma TEST.CONFIG.**, y que stos estn protegidos por perfiles de dataset sobre los cuales el usuario tiene suficiente autoridad. Para ello, basta definir el perfil genrico ICHUNCAT.TEST.CONFIG.** en la clase FACILITY y otorgarle al usuario SYSPRG1 autoridad READ. Si no es requerido este nivel de granularidad, puede definirse nicamente el perfil genrico ICHUNCAT.**, que brinda a los usuarios autorizados la posibilidad de acceder a cualquier archivo no catalogado. Sin que ello excepte, recalqumoslo nuevamente, los chequeos usuales de acceso a archivos.

Apuntes de RACF

Juan Mautalen

113 8 PROCESO DE CHEQUEO DE AUTORIDAD 8.1 - Consideraciones generales RACF no otorga ni rechaza solicitudes de acceso a recursos. Se limita a responder los requerimientos que recibe de las distintas aplicaciones, subsistemas y dems componentes del sistema operativo mediante la devolucin de un cdigo de retorno, que puede ser 0, 4 u 8, y cuyo significado es el siguiente: 0 4 8 RACF considera que la solicitud de acceso debe aceptarse RACF no posee informacin para responder sobre la solicitud de acceso RACF considera que la solicitud de acceso debe rechazarse

En cualquier caso, es finalmente la aplicacin la que decide aceptar o rechazar el requerimiento de acceso. Por ejemplo, una exit propia de la aplicacin podra perfectamente denegar una solicitud de acceso an cuando reciba de RACF un cdigo de retorno 0. De todos modos, salvo casos excepcionales, es de esperar que toda aplicacin que maneje su seguridad externamente va RACF acte en forma compatible con el cdigo de retorno que reciba. Hecha esta importante aclaracin, en lo que sigue, diremos que RACF autoriza una solicitud de acceso cuando el cdigo de retorno sea 0, y que la rechaza cuando sea igual a 8. En este captulo describiremos en detalle el proceso que lleva a cabo RACF para determinar el cdigo de retorno que devolver a la aplicacin solicitante frente a un requerimiento de acceso. 8.2 - Autoridad de un usuario sobre un recurso Recordemos que la solicitud de acceso que recibe RACF consta, esencialmente, de la siguiente informacin: Nombre de la clase Nombre del recurso Nivel de acceso requerido (EXECUTE, READ, UPDATE, CONTROL o ALTER) Identificador del usuario RACF procesa la solicitud de acceso siguiendo en orden, bsicamente, los pasos que enumeramos a continuacin. Si en alguno de ellos RACF autoriza el requerimiento, lo rechaza, o bien devuelve el cdigo de retorno 4 (cdigo de no protegido), el proceso termina y los pasos subsiguientes son omitidos. Para simplificar, obviamos toda mencin de security levels, categories y security labels, as como tambin suponemos no se han implementado exits de RACF (ni del SAF). Pasos del proceso de chequeo 1. Si RACF no est activo en el sistema, se devuelve el cdigo de no protegido. 2. Si se trata de una clase de recursos generales que no se encuentra activa en la SETROPTS, RACF devuelve el cdigo de no protegido. 3. Si la clase debera estar RACLISTeada de acuerdo a lo que especifica la CDT, pero no lo est, RACF devuelve el cdigo de no protegido. 4. Si el requerimiento proviene de una STC marcada TRUSTED o PRIVILEGED, RACF lo autoriza.

Apuntes de RACF

Juan Mautalen

114 5. Si la clase est bajo GLOBAL en la SETROPTS, y la informacin de la GAC indica que debe accederse a la solicitud, se autoriza el acceso, excepto que el usuario tenga el atributo RESTRICTED, en cuyo caso el proceso contina. 6. RACF busca el perfil protector del recurso. Si no encuentra al recurso protegido y se trata de una clase de recursos generales, devuelve como cdigo de retorno el DEFRETC de la clase especificado en la CDT. Si la clase es DATASET y no existe perfil protector, contina en el paso 19. 7. Si el recurso es considerado propiedad del usuario, RACF autoriza el requerimiento. Un ejemplo tpico son datasets cuyo HLQ coincida con el identificador del usuario. Notemos que esto no tiene ninguna relacin con el concepto de owner del perfil. 8. RACF busca el identificador del usuario en la lista de acceso estndar del perfil protector del recurso. Si el usuario figura en ella con un nivel igual o superior al solicitado, RACF autoriza el requerimiento. Si el usuario figura en ella pero con un nivel inferior al solicitado, RACF contina en el paso 14 (por lo tanto, ID(*), UACC y atributo OPERATIONS no cuentan). 9. Si la opcin GRPLIST no est activa en la SETROPTS, RACF busca el actual grupo de conexin del usuario en la lista de acceso estndar del perfil protector. Si el grupo figura en ella con un nivel igual o superior al solicitado, RACF autoriza el requerimiento. Si el grupo figura en ella pero con un nivel inferior al solicitado, RACF contina en el paso 14 (por lo tanto, ID(*), UACC y atributo OPERATIONS no cuentan). 10. Si la opcin GRPLIST est activa en la SETROPTS, RACF busca en la lista de acceso estndar del perfil protector del recurso la presencia de los eventuales grupos a los que el usuario est conectado. Si uno o ms de estos grupos figuran en ella, RACF selecciona el nivel de autoridad ms elevado. Si tal nivel es igual o superior al solicitado, RACF autoriza el requerimiento. Si, por el contrario, el nivel resultante es inferior, RACF contina en el paso 14 (por lo tanto, ID(*), UACC y atributo OPERATIONS no cuentan). 11. RACF busca si existe una entrada * en la lista de acceso estndar del perfil protector. En caso afirmativo, si el nivel de autoridad asociado es igual o superior al solicitado, y el usuario existe en la base de RACF y no tiene el atributo RESTRICTED, RACF autoriza el requerimiento. Si el nivel asociado a la entrada * es, en cambio, inferior al solicitado, RACF contina en el paso 13 (por lo tanto el UACC no cuenta en este caso). 12. Si el UACC del perfil protector es igual o superior al nivel solicitado, y el usuario no tiene el atributo RESTRICTED, RACF autoriza el requerimiento. 13. Si la clase est alcanzada por el atributo OPERATIONS y el usuario lo posee, ya sea a nivel de sistema o a nivel de un grupo que tenga al perfil protector dentro de su campo de accin, entonces RACF autoriza el requerimiento. 14. RACF busca el identificador del usuario en la lista de acceso condicional del perfil protector del recurso. Si el usuario figura en ella con un nivel igual o superior al solicitado y se cumple la condicin correspondiente, RACF autoriza el requerimiento. 15. Si la opcin GRPLIST no est activa en la SETROPTS, RACF busca el actual grupo de conexin del usuario en la lista de acceso condicional del perfil protector. Si el grupo figura en ella con un nivel igual o superior al solicitado y se cumple la condicin correspondiente, RACF autoriza el requerimiento.

Apuntes de RACF

Juan Mautalen

115 16. Si la opcin GRPLIST est activa en la SETROPTS, RACF busca en la lista de acceso condicional del perfil protector la presencia de los eventuales grupos a los que el usuario est conectado. Si uno o ms de estos grupos figuran en ella para la condicin dada, RACF selecciona el nivel de autoridad ms elevado. Si tal nivel es igual o superior al solicitado, RACF autoriza el requerimiento. 17. RACF busca si existe una entrada * en la lista de acceso condicional del perfil protector. En caso afirmativo, si el nivel de autoridad asociado es igual o superior al solicitado, se cumple la condicin correspondiente, el usuario existe en la base de RACF y no tiene el atributo RESTRICTED, RACF autoriza el requerimiento. 18. Si el perfil protector est en modo WARNING, RACF autoriza el requerimiento. 19. Si se est intentando acceder a un archivo no protegido y la opcin PROTECT-ALL est activa en la SETROPTS en modo FAILURES, RACF rechaza el requerimiento, excepto que el usuario tenga el atributo SPECIAL a nivel de sistema, en cuyo caso lo autoriza. Si la opcin PROTECTALL no est activa, o lo est pero en modo WARNING, RACF autoriza el requerimiento. 20. RACF finalmente rechaza el requerimiento. Observaciones: Si la solicitud de acceso es sobre un dataset no catalogado, RACF toma en cuenta adems el seteo de la opcin CATDSNS en la SETROPTS, que ya analizamos en el captulo correspondiente. La lista de acceso estndar se chequea siempre antes que la condicional. La presencia del usuario, o de alguno de sus grupos de conexin (suponiendo que la opcin GRPLIST est activa en la SETROPTS) en la lista de acceso estndar del perfil protector del recurso previene el eventual acceso que se pueda obtener va UACC, ID(*) o atributo OPERATIONS. Salvo casos puntuales (acceso a archivos no catalogados o no protegidos), el atributo SPECIAL no es chequeado en ningn paso durante el proceso. Esto es coherente con lo que ya hemos sealado, en el sentido de que tal atributo no otorga acceso a recursos.

Apuntes de RACF

Juan Mautalen

116 9 - PROGRAMAS UTILITARIOS 9.1 - Consideraciones generales RACF provee varios programas utilitarios que permiten manipular, diagnosticar problemas y extraer informacin de la base de RACF. En este captulo expondremos los que consideramos ms importantes. Los que analizaremos deben ejecutarse en forma batch, por lo cual mostraremos un job a modo de ejemplo y, en ciertos casos, una salida tpica del utilitario. Naturalmente, la tarjeta job debe ser personalizada de acuerdo a las exigencias de cada organizacin (nombre del job; cdigo de cuenta; clase; prioridad; etc.). Los programas invocados por los distintos utilitarios residen en la biblioteca SYS1.LINKLIB, por lo cual el sistema los localizar sin necesidad de codificar JOBLIB o STEPLIB en el job. 9.2 - IRRUT100 Este utilitario permite localizar en la base todas las ocurrencias de un usuario o grupo dado. Al ser un programa que debe examinar todos los perfiles de la base, es recomendable ejecutarlo fuera de horarios pico de actividad, para no impactar negativamente en la performance del sistema. Hacemos notar que no existe un comando de RACF que permita, dado un usuario o grupo, listar todos los perfiles dnde figure en las listas de acceso. El utilitario IRRUT100 puede ser usado para obtener esta informacin (aunque tambin existen otros mtodos, que mencionaremos ms adelante). Este utilitario siempre toma la informacin de la base de RACF activa en la LPAR dnde se ejecuta. No es posible correr el IRRUT100 especificando una base de RACF distinta de la activa. Ejemplo de IRRUT100:
//REFX100 // //PASO1 //SYSPRINT //SYSUT1 //SYSIN jef2514 conta /* // JOB cuenta,programmer, MSGLEVEL=(1,1),MSGCLASS=clase,CLASS=clase,PRTY=valor EXEC PGM=IRRUT100 DD DSN=RACF.IRRUT100.SALIDA,DISP=OLD DD UNIT=SYSDA,SPACE=(TRK,(20,4)) DD *

//**********************************************************************

El programa invocado debe ser IRRUT100. La DD SYSPRINT es obligatoria y define dnde el utilitario grabar la informacin de salida. Puede tratarse de un archivo secuencial (en disco o en cartucho), o bien puede especificarse un dispositivo de salida. En nuestro ejemplo, esta informacin se grabar en el dataset de nombre RACF.IRRUT100.SALIDA, que suponemos prealocado. La DD SYSUT1 es obligatoria y define un dataset de trabajo, que debe residir en disco. La DD SYSIN es obligatoria e indica el dataset de control del utilitario. Consiste de un listado de usuarios o grupos sobre los que se pretende buscar referencias. Esta informacin de entrada puede estar embebida en el mismo jobstream (usando DD *) o bien residir en un archivo (secuencial o particionado). En nuestro ejemplo, la SYSIN est inserta dentro del jobstream y establece que se busque toda referencia en la base respecto al usuario JEF2514 y el grupo CONTA (en rigor, tan solo mirando los identificadores, no es posible distinguir si se trata de grupos o usuarios).

Apuntes de RACF

Juan Mautalen

117 La salida tendra el siguiente aspecto:

Occurrences of JEF2514 In notify field of general resource profile PROGRAM FTPDNS In standard access list of general resource profile PROGRAM FTPDNS In standard access list of dataset profile CONTA.** (G) In standard access list of dataset profile JEF2514.** (G) First qualifier of profile JEF2514.** (G) In access list of group CONTA In access list of group PAGOS User entry exists Owner of user CON001 (G) - Entity name is generic Occurrences of CONTA In standard access list of general resource profile ACCTNUM CONTABILIDAD In standard access list of general resource profile TSOPROC IKJCONTA In standard access list of general resource profile TERMINAL FINA* (G) In standard access list of general resource profile TAPEVOL CON* (G) In standard access list of dataset profile CONTA.** (G) First qualifier of profile CONTA.** (G) In standard access list of dataset profile CONTA.A200%.** (G) First qualifier of profile CONTA.A200%.** (G) In standard access list of dataset profile PAGOS.PROVEE.** (G) In standard access list of dataset profile PUBLIC.** (G) Group name exists In subgroup list of group FINANZAS Connect group for user CONJF01 Default group for user CONJF01 Connect group for user CONJF02 Default group for user CONJF02 Connect group for user JEF2514 (G) - Entity name is generic.

Observemos que la salida no solo muestra la presencia del usuario o grupo en las listas de acceso, sino tambin en cualquier otro campo de los perfiles, como ser OWNER o NOTIFY. Incluso informa si el usuario o grupo especificado es el HLQ de algn perfil de dataset. Una desventaja importante de la informacin que brinda el IRRUT100 es que no especifica el nivel de autoridad con que figura el usuario/grupo en las listas de acceso del los perfiles. Por ejemplo, nos informa, en nuestro caso, que el usuario JEF2514 est en la lista de acceso estndar del perfil de dataset CONTA.**, pero no especifica si figura con nivel de autoridad NONE, EXECUTE, READ, UPDATE, CONTROL o ALTER. En consecuencia, si se pretende definir un nuevo usuario o grupo que tenga exactamente las mismas autorizaciones que otro existente, no es suficiente la informacin suministrada por el IRRUT100. Autoridad requerida Para ejecutar el IRRUT100 especificando un determinado usuario o grupo, se debe tener el atributo SPECIAL o AUDITOR a nivel de sistema o a nivel de un grupo que tenga al usuario o grupo en cuestin dentro de su campo de accin.
Apuntes de RACF Juan Mautalen

118 9.3 - IRRUT200 Este utilitario tiene los siguientes usos bsicos: Identifica inconsistencias en la organizacin interna de la base de RACF. Es solo una herramienta de diagnstico, ya que en caso de detectar errores no realiza ninguna reparacin. Informa el porcentaje de utilizacin efectiva del espacio en la base de RACF. Esta informacin es til para decidir si es necesario un redimensionamiento. Permite realizar una copia exacta (bloque a bloque) de la base de RACF. Es pues una herramienta extremadamente til para realizar un backup en disco de la base. Permite sincronizar las bases de uso primario y backup. Ejemplo de IRRUT200 para diagnstico:
//DIAG200 // //PASO1 //SYSRACF //SYSUT1 //SYSUT2 //SYSPRINT //SYSIN MAP [ALL] END /* // JOB cuenta,programmer, MSGLEVEL=(1,1),MSGCLASS=clase,CLASS=clase,PRTY=valor EXEC PGM=IRRUT200 DD DSN=SYS1.BASERACF,DISP=SHR DD UNIT=SYSDA,SPACE=(CYL,(20)),DCB=(LRECL=4096,RECFM=F) DD SYSOUT=clase DD SYSOUT=clase DD *

//**********************************************************************

INDEX [FORMAT]

El programa invocado debe ser IRRUT200. La DD SYSRACF define el dataset de la base de RACF sobre el que se pretende efectuar la verificacin (recordemos que la base de RACF puede estar particionada en ms de un dataset). Puede tratarse de un dataset activo o no. En cualquier caso, si SYSUT1 ya contiene una copia del archivo a analizar, entonces la DD SYSRACF puede omitirse. La DD SYSUT1 define un archivo de trabajo que debe residir en disco y tener idnticas caractersticas que el dado por SYSRACF (en nuestro ejemplo asumimos que SYS1.BASERACF tiene un tamao de 20 cilindros). El utilitario IRRUT200 procede, como primera medida, a copiar el dataset definido en SYSRACF al especificado en SYSUT1 (para ello utiliza internamente el programa IEBGENER). Terminada la copia, se libera SYSRACF y el programa prosigue realizando las verificaciones pertinentes sobre la copia recin obtenida. De esta manera se minimiza el tiempo en que el utilitario mantiene la reserva sobre la base de RACF. SYSUT1 debe ser distinto a SYSRACF, sino el utilitario falla. Tampoco SYSUT1 puede especificar un dataset de RACF activo, pues tambin el job fallara. Este control del utilitario evita que, por error, se corrompa un dataset activo usndolo como archivo de salida. Si no se codifica SYSUT1, se usa el dataset definido en SYSRACF durante todo el proceso. Si es un dataset activo, esto no es aconsejable pues se mantendra la reserva hasta la finalizacin del job, pudiendo causar problemas operativos. La DD SYSUT2 define dnde el utilitario grabar ciertos mensajes de salida. Puede tratarse de un archivo secuencial (en disco o en cartucho), o bien puede especificarse un dispositivo de salida.

Apuntes de RACF

Juan Mautalen

119 La DD SYSPRINT define dnde el utilitario grabar la informacin de diagnstico generada. Puede tratarse de un archivo secuencial (en disco o en cartucho), o bien puede especificarse un dispositivo de salida. La DD SYSIN es obligatoria e indica el dataset de control del utilitario. La informacin puede estar en el mismo jobstream (lo ms frecuente, usando DD *), o bien residir en un archivo. Las sentencias de control admitidas son: INDEX [FORMAT] MAP [ALL] END INDEX especifica que se lleve a cabo la funcin de escaneo de ndice. El parmetro FORMAT, en caso de codificarse, debe estar separado de INDEX por un nico espacio en blanco, e indica que se muestre en la salida un listado formateado de todos los bloques de ndice. MAP establece que se lleve a cabo una verificacin a nivel de BAM (Block Availability Mask). El parmetro ALL, en caso de codificarse, debe estar separado de MAP por un nico espacio en blanco, e indica que se muestre en la salida un mapa de todos los bloques BAM de la base. END indica el final del proceso. Para interpretar en su totalidad la informacin de diagnstico suministrada por el IRRUT200 es necesario conocer profundamente la organizacin interna de una base de RACF, tema complejo que escapa completamente a los objetivos de la presente gua. De todos modos, es recomendable correr esta herramienta de diagnstico con cierta regularidad (semanalmente, o mensualmente, por ejemplo), con el propsito de verificar que el utilitario no encuentre inconsistencias lgicas en la organizacin interna de la base. Si el IRRUT200 detectara algn tipo de problema, ser necesario corregirlo, para lo cual deber consultarse la documentacin correspondiente que brinda IBM. Mencionemos asimismo que no todos los posibles problemas internos de una base de RACF son detectados por el IRRUT200. De todos modos, RACF es un producto sumamente estable y probado, y con un manejo adecuado, es realmente poco probable que aparezcan errores lgicos. Si se ejecuta el IRRUT200 con la opcin MAP, en la salida SYSPRINT aparece una serie de estadsticas interesantes, entre las que se incluyen la cantidad de perfiles existentes en cada clase y el porcentaje de ocupacin de la base. Para evitar problemas repentinos por falta de espacio, es conveniente controlar que este valor no supere, digamos, el 75%. Si se estuviera por encima, sera conveniente programar una ampliacin y reorganizacin de la base (ver el utilitario IRRUT400). Mostramos a continuacin un ejemplo de la SYSPRINT:
**** BAM BLOCK VERIFICATION **** **** MAP FUNCTION STATISTICS **** NUMBER OF BAM BLOCKS DEFINED 004 LAST BAM THAT DEFINES USED SPACE - RBA 00000000D000 RACF DATA SET IS 41 PERCENT FULL. TOTAL NUMBER OF INDEX BLOCKS IN RACF DATA SET 00000198 TOTAL NUMBER OF LEVEL 01 BLOCKS IN RACF DATA SET 00000190 NUMBER OF GROUP ENTRIES - 0000173 NUMBER OF USER ENTRIES - 0004305 NUMBER OF DATASET ENTRIES - 0000428 NUMBER OF RACFVARS ENTRIES - 0000001 NUMBER OF SECLABEL ENTRIES - 0000003 NUMBER OF DASDVOL ENTRIES - 0000004 NUMBER OF TERMINAL ENTRIES 0000086 NUMBER OF APPL ENTRIES 00000021 NUMBER OF TCICSTRN ENTRIES - 0000002 NUMBER OF GCICSTRN ENTRIES - 000092 NUMBER OF GLOBAL ENTRIES - 0000003

Apuntes de RACF

Juan Mautalen

120
NUMBER OF DSNR ENTRIES - 0000009 NUMBER OF FACILITY ENTRIES - 0000043 NUMBER OF PROGRAM ENTRIES - 0000018 NUMBER OF TSOPROC ENTRIES - 0000020 NUMBER OF ACCTNUM ENTRIES - 0000020 NUMBER OF TSOAUTH ENTRIES 0000004 NUMBER OF MGMTCLAS ENTRIES 0000008 NUMBER OF STORTCLAS ENTRIES 0000031 NUMBER OF FIELD ENTRIES - 00000014 NUMBER OF CCICSCMD ENTRIES - 0000001 NUMBER OF VCICSCMD ENTRIES 00000012 NUMBER OF VTAMAPPL ENTRIES 00000008 NUMBER OF OPERCMDS ENTRIES 0000035 NUMBER OF JESSPOOL ENTRIES 0000028 NUMBER OF CONSOLE ENTRIES - 0000008 NUMBER OF SURROGAT ENTRIES - 00000012 NUMBER OF SDSF ENTRIES - 00000018 NUMBER OF STARTED ENTRIES - 0000157 NUMBER OF DIGTCERT ENTRIES - 0000011

Observemos, como dato importante, que se informa que el dataset est ocupado en un 41%. Esta es la nica forma de determinar el porcentaje de ocupacin efectivo de una base de RACF. Los datasets de RACF estn formateados ntegramente. Por lo tanto, si se listaran sus caractersticas de alocacin (por ejemplo, con el comando S en la opcin 3.4 Dslist del ISPF), se vera un uso del 100%, que de ninguna manera refleja su ocupacin real. En la salida SYSUT2 se tendran, por ejemplo, los siguientes mensajes:
DATA SET UTILITY - GENERATE PROCESSING ENDED AT EOD IRR62065I - IEBGENER copied SYSRACF to the work dataset SYSUT1, IEBGENER RC=0000

Ejemplo de IRRUT200 para hacer una copia de backup:

//BACK200 // //PASO1 //SYSRACF //SYSUT1 //SYSUT2 //SYSPRINT //SYSIN // JOB cuenta,programmer, MSGLEVEL=(1,1),MSGCLASS=clase,CLASS=clase,PRTY=valor EXEC PGM=IRRUT200 DD DSN=SYS1.BASERACF,DISP=SHR DD DSN=RACF.COPIA,DISP=OLD DD SYSOUT=clase DD SYSOUT=clase DD DUMMY

//**********************************************************************

En este ejemplo el programa utilitario IRRUT200 se emplea para realizar una copia exacta, bloque a bloque, del dataset de RACF especificado en la DD SYSRACF. La copia se generar en el dataset RACF.COPIA especificado en SYSUT1, que suponemos prealocado y con idnticas caractersticas y tamao que la entrada SYS1.BASERACF. La DD SYSIN definida como DUMMY en este ejemplo establece que no se lleve a cabo ninguna funcin de diagnstico. En su uso como herramienta de backup, el IRRUT200 solo sirve para realizar una copia de la base a una que resida en un disco de igual geometra que la original y tenga igual tamao. El dataset especificado en SYSUT1 no debe ser nunca una base de RACF activa (en este u otro sistema), ya que el utilitario

Apuntes de RACF

Juan Mautalen

121 podra corromperlo durante la copia. Si se pretende copiar una base a otra de distinto tamao, debe usarse el utilitario IRRUT400, que veremos ms adelante. Ejemplo de IRRUT200 para sincronizar las bases:
//BACK200 // //PASO1 //SYSRACF //SYSUT1 //SYSUT2 // JOB cuenta,programmer, MSGLEVEL=(1,1),MSGCLASS=clase,CLASS=clase,PRTY=valor EXEC PGM=IRRUT200,PARM=ACTIVATE DD DSN=SYS1.RACF.PRIM,DISP=SHR DD DSN=SYS1.RACF.BACK,DISP=OLD DD SYSOUT=clase

//**********************************************************************

El parmetro PARM=ACTIVATE indica que se quiere copiar la base primaria sobre la de backup (o a nivel de un dataset especfico, si la base estuviera distribuida en ms de uno). RACF verificar que SYSRACF especifique efectivamente la base primaria de RACF y SYSUT1 la de backup. Se comprobar asimismo que el backup se encuentre inactivo (recordemos que nunca el destino de una copia debe ser un dataset de RACF activo). Finalizada la copia de SYSRACF (base primaria activa) sobre SYSUT1 (base de backup inactiva), se activar la base de backup antes de liberarse la base primaria. Solo de este modo queda garantizado que la base de backup resulte idntica a la primaria. En efecto, si en lugar de activar el backup el mismo IRRUT200 lo hiciera un administrador con el comando RVARY, las eventuales modificaciones sobre la base primaria ocurridas entre la finalizacin del job y la ejecucin del comando de activacin no se veran replicadas el backup. Con PARM=ACTIVATE, las DD SYSPRINT y SYSIN, si estuvieran presentes, son ignoradas. Autoridad requerida Para ejecutar el utilitario IRRUT200, basta con tener autoridad READ sobre el dataset especificado en SYSRACF y UPDATE sobre el dado por SYSUT1 (o ALTER, si es alocado dinmicamente por el job como archivo permanente). Naturalmente, si los programas IRRUT200 o IEBGENER estuviesen protegidos en la clase PROGRAM, se necesita asimismo autoridad para ejecutarlos. 9.4 - IRRUT400 Este utilitario tiene varias funciones: Permite copiar la base de RACF a otra de tamao distinto, que puede incluso residir en un disco de distinta geometra. Permite distribuir un dataset de la base de RACF en varios datasets. Asimismo, tambin puede utilizarse para consolidar varios datasets de la base en una menor cantidad. Recordemos que RACF admite un mximo de 90 datasets para su base primaria, e idntica cantidad para la base de backup. Identifica cierto tipo de inconsistencias en los datasets de la base, como ser la presencia de perfiles duplicados. Reorganiza fsicamente la base, juntando los eventuales segmentos de un mismo perfil. En cualquiera de sus usos, es recomendable ejecutar este utilitario fuera de los horarios pico de actividad, de modo de no afectar negativamente la performance del sistema. En la presente gua no analizaremos la funcionalidad del IRRUT400 respecto a la posibilidad de distribuir (split) o consolidar (merge) los datasets que conforman la base. Nos ocuparemos exclusivamente del uso del utilitario como herramienta de copia y reorganizacin. Tampoco
Apuntes de RACF Juan Mautalen

122 describiremos todos los parmetros que admite el programa, sino el nico cuya especificacin es obligatoria. Si se quiere obtener una copia idntica, es preferible emplear el utilitario IRRUT200 pues se encarga de serializar adecuadamente el uso de la base de origen, garantizando una copia completamente fiel de la original. En cambio, si la copia desea hacerse a una base de distinto tamao, o residente en un disco de distinta geometra (de 3380 a 3390, por ejemplo), entonces debe necesariamente utilizarse el IRRUT400. El IRRUT400, a diferencia del IRRUT200, no solo copia sino que reorganiza la base. Para comprender exactamente el alcance del proceso de reorganizacin, es necesario tener un conocimiento acabado de la estructura interna de la base de RACF, lo cual excede los objetivos de esta gua. Mencionemos simplemente que se trata, esencialmente, de una especie de desfragmentacin, consistente en reubicar fsicamente contiguos aquellos segmentos correspondientes a un mismo perfil. Si la base se encuentra muy fragmentada (lo cual puede diagnosticarse a travs del IRRUT200), esta reorganizacin puede mejorar la performance de RACF, al disminuir la cantidad de lecturas de bloques que RACF debe realizar para obtener la informacin completa de un determinado perfil. Del mismo modo que para el IRRUT200, la base de destino no debe nunca estar activa en ningn sistema. Ms an, si estuviera activa en el mismo sistema dnde se ejecuta el job, el utilitario falla. En cambio, la base de origen (esto es, la que se pretende copiar) puede o no estar activa. Si se encuentra activa, el IRRUT400 permite manejar el bit de lockeo de la base, que establece si la misma se encuentra lockeada o no-lockeada. Base lockeada En este estado, no se permite ninguna actualizacin sobre la base, con excepcin de cierta informacin estadstica. En consecuencia, no pueden definirse, modificarse o deletearse perfiles, as como tampoco modificarse opciones de la SETROPTS. Ms an, algunos usuarios no podrn loguearse. Esto suceder, por ejemplo, si se trata de su primer logon del da, si intentan cambiar su password, o si han ingresado su password correcta luego de algn intento invlido. Estando la base lockeada, el chequeo de autoridad de usuarios sobre recursos se lleva a cabo normalmente. Por lo tanto, los usuarios que se encuentran logueados a alguna aplicacin no deberan notar ninguna diferencia, excepto naturalmente que intenten modificar informacin de la base de RACF. En cualquier caso, solo se justifica tener la base lockeada durante alguna tarea de mantenimiento especfica y por un perodo muy breve. Base no-lockeada Se trata del estado natural de la base, en el cual todas las actualizaciones estn permitidas. Las bases de RACF, tanto la primaria como la backup, deben estar no-lockeadas, salvo que exista una situacin que requiera explcitamente lo contrario, lo cual es poco frecuente y por un perodo corto de tiempo. El IRRUT400 permite manejar el bit de lockeo de la base a travs de un parmetro obligatorio que debe tomar alguno de los valores siguientes: LOCKINPUT/NOLOCKINPUT/UNLOCKINPUT. No existe ningn valor por defecto, por lo cual debe necesariamente codificarse alguna de las 3 opciones, cuyo significado analizamos a continuacin. LOCKINPUT lockea la base de origen antes de iniciar el proceso de copia. De este modo, se garantiza que la copia tenga idntica informacin que la original, al no permitirse actualizaciones durante el proceso. Se trata de la opcin ms recomendable, aunque tiene la desventaja de mantener lockeada la base de origen durante el tiempo que insume el utilitario, lo cual puede, si se trata de una base activa, acarrear ciertas dificultades operativas. Si se especific LOCKINPUT, la base de origen quedar lockeada an luego de terminado el proceso de copiado. Si se trata de una base activa que se seguir utilizando, es imprescindible deslockearla. Para ello basta con agregar al job un paso adicional, que invoque nuevamente el programa IRRUT400 pero con el parmetro UNLOCKINPUT.
Apuntes de RACF Juan Mautalen

123 NOLOCKINPUT no modifica el estado de lockeo de la base de origen. Esto significa que, si estaba lockeada, permanecer de este modo, y si no lo estaba (como es de esperar si se trata de una base activa) permanecer no-lockeada durante el proceso de copia. En este caso, si se produjeran modificaciones en la base de origen durante la copia, es posible que la base de destino difiera de la original, e incluso que resulte corrupta. No se trata, por lo tanto, de una opcin aconsejable cuando la base de origen est activa, excepto que se tenga la seguridad de que la actividad de actualizacin es nula. Si la base de origen no est activa en ningn sistema, entonces no es pasible de ser modificada, por lo cual la opcin NOLOCKINPUT sera perfectamente apropiada. UNLOCKINPUT deslockea la base de origen. Como ya mencionamos, si se ejecut el IRRUT400 con el parmetro LOCKINPUT y se pretende seguir usando como base activa a la base de origen, debe necesariamente deslockearse invocando nuevamente el mismo utilitario con el parmetro UNLOCKINPUT, tal cual mostramos en el ejemplo siguiente. Ejemplo de IRRUT400 para copiar una base
//BACK400 // //COPIA //INDD1 //OUTDD1 //SYSPRINT //UNLOCK //INDD1 //SYSPRINT // JOB cuenta,programmer, MSGLEVEL=(1,1),MSGCLASS=clase,CLASS=clase,PRTY=valor EXEC PGM=IRRUT400,PARM=LOCKINPUT DD DSN=SYS1.BASERACF,DISP=OLD DD DSN=RACF.COPIA,DISP=OLD DD SYSOUT=clase EXEC PGM=IRRUT400,PARM=UNLOCKINPUT DD DSN=SYS1.BASERACF,DISP=OLD DD SYSOUT=clase

//**********************************************************************

El programa invocado debe ser IRRUT400. La DD INDD1 especifica el dataset de la base de RACF a copiar. Si se quiere copiar una base de RACF particionada en varios datasets, se deben usar subsiguientes DD de nombre INDDn (n=2, 3, etc.). Como el utilitario tiene la posibilidad de modificar el bit de lockeo de la base de origen, es necesario especificar DISP=OLD. La DD OUTDD1 especifica el dataset de salida dnde se copiar el dataset definido en INDD1. Si se requiere ms de 1 dataset de salida, deben usarse subsiguientes DD de nombre OUTDDn (n=2, 3, etc.). En nuestro caso, se supone que el dataset RACF.COPIA se encuentra prealocado. Recordemos que la base de destino, de nombre RACF.COPIA en nuestro ejemplo, puede tener distinto tamao que la de origen. La DD SYSPRINT establece dnde el utilitario grabar los mensajes de salida. Puede tratarse de un archivo secuencial (en disco o en cartucho), o bien puede especificarse un dispositivo de salida. El segundo paso del job dado como ejemplo deslockea la base SYS1.BASERACF, que haba quedado lockeada en el paso anterior (por haberse especificado el parmetro LOCKINPUT). Observemos que cuando se usa el IRRUT400 para deslockear una base, como el utilitario no realiza ninguna copia, solo es necesario especificar la base de origen (INDD1). Autoridad requerida Para ejecutar el utilitario IRRUT400 se debe tener autoridad UPDATE sobre el dataset especificado en INDD1 y UPDATE sobre el definido por OUTDD1 (o ALTER, si es alocado dinmicamente por el job). Se requiere nivel de autoridad UPDATE sobre la base de origen pues el utilitario permite eventualmente alterar el bit de lockeo, lo cual es efectivamente una modificacin. An si se especific

Apuntes de RACF

Juan Mautalen

124 NOLOCKINPUT, se requiere UPDATE pues RACF chequea por este nivel de autoridad independientemente del valor puntual del parmetro. 9.5 - IRRDBU00 La base de RACF tiene un formato propio, bastante complejo, que solo interpreta RACF. Si se intenta mirar directamente la base, se observarn datos distribuidos de manera aparentemente catica, no interpretables. Se presenta entonces la necesidad de contar con un programa utilitario que convierta la informacin de la base a un formato plano, factible de ser fcilmente interpretado y explotado programticamente. El utilitario IRRDBU00 (DBU viene de Data Base Unload.) permite justamente esto. Transfiere, a un archivo secuencial, la informacin de todos los perfiles de la base. El archivo plano generado puede usarse con diversos fines: Se puede leer directamente, ya que el diseo de sus registros se encuentra plenamente documentado en la bibliografa de IBM, ms precisamente en el libro Security Server RACF Macros and Interfaces. Se puede formatear con algn programa propio, para extraer y organizar la informacin de una forma conveniente. Se puede usar para cargar tablas de DB2, para luego poder usar este motor de base de datos para extraer informacin. Se puede transferir a PC y formatearlo con algn programa de este entorno. Sirve como archivo de entrada a otro utilitario importante que veremos ms adelante, llamado IRRRID00. El IRRDBU00 puede ejecutarse sobre una base de RACF activa (primaria o backup) o inactiva. Cuando lee un perfil de la base, el IRRDBU00 serializa el acceso al perfil y recin lo libera al finalizar la transferencia al archivo secuencial. Naturalmente, debe hacer esto para todos los perfiles de la base. Por este motivo, resulta aconsejable ejecutarlo tomando como entrada una copia de la base activa, de modo a no afectar la performance de RACF. Una buena idea sera obtener una copia actual de la base usando IRRUT200 y a continuacin ejecutar el IRRDBU00 sobre la copia recin obtenida. La gran ventaja de este mtodo en 2 pasos radica en el hecho de que la reserva del IRRUT200 sobre la base activa es mucho ms breve y de menor impacto que la que demanda el IRRDBU00. Los campos encriptados de la base de RACF, como las passwords, no son transferidos por el IRRDBU00. Tampoco se copia al archivo secuencial generado la informacin de la SETROPTS, ni ningn otro dato de la base que no exista directamente en los perfiles. Ejemplo de IRRDBU00
//BAJARACF // //BAJADA //INDD1 //OUTDD //SYSPRINT // JOB cuenta,programmer, MSGLEVEL=(1,1),MSGCLASS=clase,CLASS=clase,PRTY=valor EXEC PGM=IRRDBU00,PARM=NOLOCKINPUT DD DSN=SYS1.BASERACF.COPIA,DISP=SHR DD DSN=RACF.PLANO,DISP=OLD DD SYSOUT=clase

//**********************************************************************

El programa invocado debe ser IRRDBU00.

Apuntes de RACF

Juan Mautalen

125 La DD INDD1 define el dataset de la base de RACF que se quiere bajar a un archivo secuencial. Si se quiere volcar toda la informacin de una base particionada en varios datasets, se deben usar subsiguientes DD de nombre INDDn (n=2, 3, etc). La DD OUTDD especifica el dataset secuencial de salida dnde se transferir la informacin de los perfiles de los archivos definidos en las INDDn. Debe tener las siguientes caractersticas: RECFM=VB (registros de longitud variable y bloqueados) LRECL=4096 (longitud de registro sugerida) Con respecto al tamao, una estimacin inicial consiste en calcular el doble del espacio efectivamente utilizado en la base de entrada. Por ejemplo, si la base de entrada tiene un tamao de 50 cilindros y se encuentra ocupada en un 40% (este porcentaje se puede obtener con el utilitario IRRUT200), esto significa que hay efectivamente usados 20 cilindros. Por lo tanto, el archivo de salida del IRRDBU00 debera ocupar aproximadamente el doble, es decir 40 cilindros. En nuestro caso, se supone que el dataset RACF.PLANO se encuentra prealocado. La DD SYSPRINT establece dnde el utilitario grabar los mensajes de salida. Puede tratarse de un archivo secuencial (en disco o en cartucho), o bien puede especificarse un dispositivo de salida. El IRRDBU00 requiere obligatoriamente, al igual que el IRRUT400, la codificacin del parmetro que indica cmo se pretende que el utilitario maneje el bit de lockeo de la base. El significado de las opciones LOCKINPUT, NOLOCKINPUT y UNLOCKINPUT es anlogo al visto en el caso del IRRUT400, con la siguiente importante diferencia: si se especifica LOCKINPUT y la base de entrada no se encontraba lockeada, el IRRDBU00 la deslockear automticamente al finalizar (contrariamente a lo que hace el IRRUT400, que la mantiene lockeada). UNLOCKINPUT tiene por nico objeto deslockear el dataset especificado en INDD1. No se hace en este caso ninguna bajada de informacin. Cumple, en este punto, una funcin idntica al IRRUT400 con UNLOCKINPUT. Sugerimos siempre ejecutar el IRRDBU00 sobre una base que no se encuentre activa. En tal caso, el parmetro de lockeo resulta irrelevante. Autoridad requerida Para ejecutar el utilitario IRRDBU00 se necesita autoridad UPDATE sobre el dataset especificado en INDD1, y UPDATE sobre el definido por OUTDD (o ALTER, si es alocado dinmicamente por el job). Se requiere nivel de autoridad UPDATE sobre la base de origen debido a que el utilitario permite eventualmente alterar el bit de lockeo. 9.6 - IRRRID00 Como ya vimos en el captulo correspondiente, los comandos DELUSER o DELGROUP no eliminan de la base las referencias que pudieran existir en otros perfiles respecto al usuario o grupo que se borra. Por ejemplo, un usuario que se pretende eliminar podra existir en listas de acceso, en campos NOTIFY o ser el OWNER de perfiles. El utilitario IRRRID00 es un buscador de referencias residuales, que no solo localiza las referencias en la base de un usuario o grupo dado, sino que se encarga de generar los comandos de RACF necesarios para su eliminacin. Se trata de una herramienta fundamental para el administrador de RACF, ya que posibilita la baja de usuarios y grupos en forma prolija. Es importante sealar que el IRRRID00 no ejecuta ningn comando. Simplemente genera, en un archivo de salida, los comandos necesarios para la eliminacin de las referencias residuales. Es tarea del administrador de RACF examinar cuidadosamente (y eventualmente editar) los comandos respectivos, para luego decidir cules de ellos se ejecutaran.

Apuntes de RACF

Juan Mautalen

126 El IRRRID00 utiliza como entrada la bajada plana de la base de RACF generada por el IRRDBU00. Es pues necesario ejecutar el utilitario IRRDBU00 como paso previo a la utilizacin del IRRRID00, salvo que ya se disponga de una bajada plana de la base suficientemente actualizada. Ejemplo de IRRRID00
//IRRRID // //PASO //SYSPRINT //SYSOUT //SORTOUT //SYSUT1 //INDD //OUTDD //SYSIN jef2514 /* // JOB cuenta,programmer, MSGLEVEL=(1,1),MSGCLASS=clase,CLASS=clase,PRTY=valor EXEC PGM=IRRRID00,REGION=25M DD SYSOUT=clase DD SYSOUT=clase DD UNIT=SYSDA,SPACE=(CYL,(10,2)) DD UNIT=SYSDA,SPACE=(CYL,(10,2)) DD DSN=RACF.PLANO,DISP=SHR DD DSN=RACF.IRRRID.SALIDA,DISP=OLD DD *

//**********************************************************************

El programa invocado debe ser IRRRID00. La DD SYSPRINT determina dnde el utilitario grabar los mensajes de salida. Puede tratarse de un archivo secuencial (en disco o en cartucho), o bien puede especificarse un dispositivo de salida. La DD SYSOUT define dnde el DFSORT (o programa equivalente) invocado internamente por el utilitario grabar los mensajes de salida. Puede tratarse de un archivo secuencial (en disco o en cartucho), o bien puede especificarse un dispositivo de salida. La DD SORTOUT define un archivo de trabajo, cuyo tamao debe ser similar al especificado en INDD. Lo ms adecuado es dejar que el sistema lo aloque como un dataset temporario, que ser en consecuencia automticamente eliminado al finalizar el job. La DD SYSUT1 define otro archivo de trabajo, cuyo tamao debe ser tambin similar al especificado en INDD. Lo ms adecuado es dejar que el sistema lo defina como un dataset temporario. La DD INDD define el dataset de entrada del utilitario, que debe obligatoriamente ser una bajada plana generada por el IRRDBU00. La DD OUTDD especifica el dataset de salida del IRRRID00 dnde se generarn los comandos necesarios para eliminar las referencias residuales correspondientes. Debe tener las siguientes caractersticas: RECFM=VB (registros de longitud variable y bloqueados) LRECL=259 (como mnimo) En nuestro ejemplo, se supone que el dataset RACF.IRRRID.SALIDA est prealocado. La DD SYSIN define el listado de usuarios y/o grupos sobre los que se quiere buscar las referencias residuales. La informacin puede estar embebida en el mismo jobstream (usando DD *), o bien residir en un dataset (secuencial o particionado). Cada usuario o grupo debe estar en un registro separado, y si se especifica un ID de reemplazo, debe estar a continuacin, separado exactamente por un espacio en blanco. El ID de reemplazo funciona del siguiente modo:

Apuntes de RACF

Juan Mautalen

127 Si el usuario o grupo del cual se buscan referencias figura en un campo del cual no puede eliminarse, como es el caso si es el owner de un perfil, entonces el utilitario generar en la salida el comando necesario para cambiar esta ocurrencia por el ID de reemplazo especificado. En caso de no codificarse un ID de reemplazo, en el comando de salida figurar en tal caso el usuario/grupo precedido de un ?, de modo que pueda editarse con un valor apropiado. Si no se define SYSIN, o bien se aloca como DUMMY o vaca de contenido, el utilitario busca todas las referencias en la base de usuarios y grupos que ya no existen. Es saludable ejecutar regularmente el IRRRID00 de esta manera, de modo a detectar y borrar informacin residual que pueda haber quedado al no borrarse adecuadamente un usuario o grupo de la base. En nuestro ejemplo, la SYSIN est inserta dentro del jobstream y establece que se busque toda referencia en la base respecto al usuario JEF2514. La salida podra tener el siguiente aspecto:
/****************************************************************************************/ /* /* The RACF Remove ID Utility (IRRRID00) was executed on /* 2011-09-10 at 14:05:03. /* /* This file contains RACF commands that can be used to /* identify references to user IDs and group IDs. Residual /* references on an access list are deleted with the PERMIT /* command. For all other references, commands are created to /* change the reference to another value. The default value /* is ?id. This allows all references to a particular ID to /* be easily changed to another value using a text editor. /* /* Commands to alter ROLE definitions will be created within /* comments for informational purposes, though the actual /* updates should be made from TME. The ROLE will not be /* updated with a replacement value for a group name. /* /****************************************************************************************/ CONNECT CONJF01 GROUP(CONTA) OWNER(?JEF2514 ) PERMIT 'CONTA.**' GENERIC ID(JEF2514) DELETE PERMIT 'FINAN.**' GENERIC ID(JEF2514) DELETE PERMIT FTPDNS CLASS(PROGRAM) ID(JEF2514) DELETE RALTER PROGRAM FTPDNS NONOTIFY RALTER PROGRAM FTPDNS OWNER(?JEF2514 ) *****************************************************************************************/ * The following commands delete profiles. You must review * these commands, editing them if necessary, and then remove * the EXIT statement to allow the execution of the commands. *****************************************************************************************/ EXIT DELDSD 'JEF2514.** ' DELUSER JEF2514 *****************************************************************************************/ * IRRRID00 has successfully completed *****************************************************************************************/ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */

Observaciones: De acuerdo a la informacin generada, el usuario JEF2514 figura como owner de 1 perfil y de la conexin de un usuario a un grupo. Por lo tanto, el IRRRID00 genera los correspondientes comandos de cambio de owner, debindose reemplazar ?JEF2514 por el nuevo owner elegido. Si se hubiese codificado en la SYSIN in ID de reemplazo para JEF2514, este ID aparecera en la salida en lugar de ?JEF2514.
Apuntes de RACF Juan Mautalen

128 Si el usuario figura en el campo NOTIFY de un perfil, como es el caso en nuestro ejemplo, el utilitario genera directamente el comando de eliminacin. No se ofrece reemplazo en este caso, pues se trata de un campo opcional. Los comandos que borran perfiles estn agrupados al final del archivo de salida, a continuacin de una sentencia EXIT que corta el procesamiento en caso de ejecutarse la Clist generada. Esto es intencional, ya que al tratarse de comandos ms crticos, se evita de esta manera que la ejecucin inmediata del archivo de salida los ejecute. Una vez revisado y editado adecuadamente el archivo de salida, basta con borrar la sentencia EXIT para que tambin sean ejecutados estos comandos. Como uso marginal, puede ejecutarse el IRRRID00 solo con el objeto de hallar todas las referencias en la base de un determinado usuario/grupo, sin tener la intencin de borrarlo. En este caso, el archivo de salida se usa nicamente como fuente de consulta, y no se ejecuta ninguno de los comandos generados. La informacin recabada es similar a la que brinda el IRRUT100. Tampoco se tiene, al igual que sucede con el IRRUT100, el nivel de autoridad del usuario/grupo sobre los perfiles en cuyas listas de acceso figura. Aunque esto es perfectamente entendible en el caso del IRRRID00, pues se trata de un uso del utilitario para el que no fue especficamente desarrollado. No perdamos de vista, sin embargo, que existe una diferencia importante: mientras que el IRRUT100 lee la base de RACF activa, el IRRRID00 extrae la informacin de una bajada plana (que puede estar desactualizada respecto de la base real). Ambos mtodos presentan pues ventajas y desventajas, debiendo decidir el administrador cual es el ms apropiado para cada situacin. Autoridad requerida Para ejecutar el utilitario IRRRID00, basta con tener autoridad READ sobre el dataset especificado en INDD y UPDATE sobre el definido por OUTDD (o ALTER, si es alocado dinmicamente por el job). Naturalmente, para poder ejecutar los comandos generados se requiere la autoridad administrativa correspondiente. De todos modos, el IRRRID00 es bsicamente una herramienta para los administradores de RACF, que deberan tener la autoridad suficiente para ejecutar exitosamente estos comandos. 9.7 - IRRMIN00 Este utilitario tiene los siguientes posibles usos: Inicializar un dataset en disco para ser usado como base de RACF Actualizar los templates de una base de RACF Reemplazar los templates residentes en memoria por los de la base Toda base de RACF tiene grabado un cierto tipo de informacin -de uso interno por parte de RACFdenominada templates. Se trata, bsicamente, de una descripcin de los distintos campos de cada tipo de perfil. La informacin de los templates, indispensable para el funcionamiento de RACF, es cargada en memoria en tiempo de IPL. Por lo tanto, an si se actualizan los templates de la base, solo entrarn en vigencia luego del prximo IPL o si explcitamente se los activa mediante la opcin PARM=ACTIVATE del IRRMIN00. Con cada release del z/OS se distribuye una nueva versin del programa utilitario IRRMIN00, residente en SYS1.LINKLIB. Como una CSECT del programa figuran los templates. En consecuencia, si se actualizan los templates de una base usando por ejemplo- el IRRMIN00 del z/OS 1.11, entonces se grabarn en la base los templates correspondientes a este release del sistema operativo. A tiempo de IPL, cuando se cargan los templates en memoria, el sistema determina el nivel de los templates de la base primaria. Si se trata de templates anteriores a los propios del release del sistema operativo, entonces no se cargan en memoria los de la base sino los que efectivamente corresponden. En tal caso, en el SYSLOG se graba el mensaje ICH579E, informando que los templates de la base estn

Apuntes de RACF

Juan Mautalen

129 downlevel (desactualizados). No se trata de un error serio pues RACF va a funcionar sin problemas. Conviene, sin embargo, seguir la sugerencia dada en el mensaje y actualizar los templates de la base. Si una base de RACF es compartida por varias LPAR con distintas versiones del z/OS, se le deben instalar los templates que correspondan a la versin ms actualizada. Por ejemplo, si una base es compartida por 3 LPAR, 2 de las cuales tienen z/OS 1.9 y la restante z/OS 1.11, la base debe tener los templates del release 1.11 (las particiones que tienen 1.9 funcionarn sin problemas, ya que RACF mantiene compatibilidad hacia atrs). Inicializacin de una nueva base de RACF Para poder utilizar un dataset como base de RACF, no solo es necesario alocarlo con las caractersticas apropiadas (detalladas en un captulo anterior), sino que debe ser inicializado ejecutando el IRRMIN00 con PARM=NEW. Esto no solo debe hacerse para la base primaria, sino tambin para la base de backup. Ms an, si las bases estuvieran particionadas en ms de un dataset, debe ejecutarse el utilitario para cada uno de ellos. Un dataset inicializado de este modo queda preparado para ser usado como base de RACF. Sin embargo, al estar esencialmente vaca, difcilmente pueda utilizarse directamente en forma satisfactoria. Lo usual es alocar una base con el IRRMIN00 y a continuacin copiarle el contenido de otra existente, que ya tenga cierta informacin mnima que la torne efectivamente usable. Debe tenerse sumo cuidado, ya que el IRRMIN00 con PARM=NEW efectivamente destruye toda la informacin existente en la base. Por lo tanto, no debe jams ejecutarse el utilitario con PARM=NEW para actualizar los templates de una base, pues se perder toda la informacin. Ejemplo de IRRMIN00 para alocar e inicializar una nueva base de RACF:
//IRRMIN // //ALOCINI //SYSPRINT //SYSRACF // JOB cuenta,programmer, MSGLEVEL=(1,1),MSGCLASS=clase,CLASS=clase,PRTY=valor EXEC PGM=IRRMIN00,PARM=NEW DD SYSOUT=clase DD DSN=SYS1.BASERACF.NUEVA,DISP=(NEW,CATLG), SPACE=(CYL,(50),,CONTIG),DSORG=PSU,UNIT=SYSDA,VOL=SER=MVSRES

//**********************************************************************

El programa invocado debe ser IRRMIN00, con PARM=NEW en este caso. La DD SYSPRINT define dnde el utilitario grabar los mensajes de salida. Puede tratarse de un archivo secuencial (en disco o en cartucho), o bien puede especificarse un dispositivo de salida. La DD SYSRACF indica el dataset a inicializar como base de RACF. En nuestro caso, el archivo es alocado dinmicamente por el mismo job con el nombre SYS1.BASERACF.NUEVA, con las caractersticas adecuadas para una base de RACF. Observemos dos detalles de suma importancia: el espacio debe ser alocado contiguo y el archivo debe ser PSU (Physical Secuencial Unamovable). Las restantes caractersticas del dataset, como por ejemplo el tipo y longitud de registro, no es necesario especificarlas pues el mismo utilitario setea los valores correctos. Naturalmente, el nombre de la base, su tamao y el disco dnde se aloca que hemos especificado son meros ejemplos, y deben ser determinados por la organizacin. Actualizacin de los templates de una base existente Cuando se migra el sistema operativo, por ejemplo de z/OS 1.9 a z/OS 1.11, como el nuevo release trae nuevos templates, es necesario actualizarlos. Para ello debe ejecutarse el IRRMIN00 con PARM=UPDATE (obviamente se pretende mantener intacta toda la informacin existente en la base). No solo deben actualizarse los templates de la base primaria sino tambin los de la base de backup. Ms an, si las bases estuvieran particionadas en ms de un dataset, debe ejecutarse el utilitario para cada
Apuntes de RACF Juan Mautalen

130 uno de ellos. La base puede estar activa en el sistema cuando se usa PARM=UPDATE, en cuyo caso RACF obtiene una reserva exclusiva sobre ella durante el tiempo que insume la ejecucin (mnimo). Ejemplo de IRRMIN00 para actualizar los templates:
//IRRMIN // //TEMPUPD //SYSPRINT //SYSRACF // JOB cuenta,programmer, MSGLEVEL=(1,1),MSGCLASS=clase,CLASS=clase,PRTY=valor EXEC PGM=IRRMIN00,PARM=UPDATE DD SYSOUT=clase DD DSN=SYS1.BASERACF,DISP=SHR

//**********************************************************************

El significado de las DD es anlogo al visto en el ejemplo anterior. El IRRMIN00 con PARM=UPDATE solo actualiza los templates de la base especificada en SYSRACF, manteniendo intacta la informacin de los perfiles y de la SETROPTS. Activacin de los templates de la base Ya comentamos que, si los templates de la base fueran de nivel inferior a los del release del sistema operativo, se cargan en memoria estos ltimos. Ahora bien, existe la posibilidad de que la aplicacin de mantenimiento del sistema (PTFs Program Temporary Fix) eleve la versin de los templates. En tal caso, si la base de RACF ya tiene aplicados los nuevos templates, es posible cargarlos en memoria sin necesidad de recurrir a un IPL. Esto se logra ejecutando el IRRMIN00 con PARM=ACTIVATE, tal cual se muestra a continuacin: Ejemplo de IRRMIN00 para activar los templates de la base:
//IRRMIN // //TEMPACT //SYSPRINT //SYSRACF // JOB cuenta,programmer, MSGLEVEL=(1,1),MSGCLASS=clase,CLASS=clase,PRTY=valor EXEC PGM=IRRMIN00,PARM=ACTIVATE DD SYSOUT=clase DD DSN=SYS1.BASERACF,DISP=SHR

//**********************************************************************

El significado de las DD es anlogo al visto en los ejemplos anteriores de IRRMIN00. Si los templates en uso fueran de un nivel superior a los de la base especificada en SYSRACF, el job falla y la activacin no se produce. Esto evita que accidentalmente se carguen en memoria templates inadecuados. Autoridad requerida Para ejecutar el utilitario IRRMIN00 se debe tener autoridad UPDATE sobre el dataset especificado en SYSRACF (o ALTER, si se lo est alocando dinmicamente, como en nuestro primer ejemplo). Si el programa IRRMIN00 se encontrara protegido en la clase PROGRAM, el usuario necesitara asimismo estar autorizado para su ejecucin. 9.8 - Otros Utilitarios Describimos brevemente a continuacin otros programas utilitarios que no vamos a exponer en detalle en esta gua, pero que resultan sin duda de inters para el administrador de RACF:

Apuntes de RACF

Juan Mautalen

131 Nombre BLKUPD Funcin Su nombre proviene de Block Update. Se trata de un comando que permite manipular directamente la base de RACF, con el objeto de resolver problemas internos. Slo debe emplearse en situaciones dnde no sea posible reparar los errores mediante comandos de RACF. Antes de ejecutarlo, es necesario tener un acabado conocimiento de la estructura interna de la base, ya que un mal uso puede daarla irreparablemente. En el libro Security Server RACF Diagnosis Guide se puede encontrar toda la informacin necesaria sobre el BLKUPD. Este utilitario formatea amigablemente los registros de SMF relevantes para la tarea de auditora de RACF (tipos 30, 80, 81 y 83). Reemplaza al ya obsoleto, aunque an soportado, RACFRW (RACF Report Writer). Tcnicamente, este programa funciona como una exit del IFASMFDP, utilitario estndar de IBM para el resguardo de los registros de SMF. En el libro Security Server RACF Auditors Guide se puede encontrar informacin detallada sobre este utilitario. Su nombre proviene de Data Security Monitor. Se trata de una herramienta sumamente til, en particular para los auditores, ya que brinda gran cantidad de informacin relativa a la seguridad global del sistema. Por ejemplo: Exits de RACF activas Usuarios con atributos SPECIAL, OPERATIONS o AUDITOR Perfiles en la clase STARTED y entradas en la ICHRIN03 Estado de las clases de RACF Entradas en la Global Access Table Bibliotecas APF autorizadas y en LINKLIST rbol de grupos. En el libro Security Server RACF Auditors Guide se puede encontrar informacin detallada sobre este utilitario.

IRRADU00

DSMON

Apuntes de RACF

Juan Mautalen

132 10 - COMANDO RVARY 10.1 - Consideraciones generales El comando RVARY permite llevar a cabo las siguientes acciones, sin necesidad de un IPL: Listar la configuracin actual de las bases de RACF vigentes en el sistema. Hacer un switch de las bases, operacin que intercambia el uso de la base primaria y la de backup. Esto puede hacerse incluso a nivel de dataset, en el caso en que la base se encuentre distribuida en ms de uno. Activar o inactivar una base de RACF, incluso a nivel de dataset, en el caso en que se encuentre distribuida en ms de uno. Cambiar entre los modos data sharing y non data sharing, suponiendo que RACF est habilitado para sysplex communication. Los nombres de los datasets de las bases de RACF (primaria y backup) se definen en el mdulo de nombre ICHRDSNT (Data Set Name Table). El orden en que estn definidos determina su nmero de secuencia. Si las bases estuvieran divididas en varios datasets, ser necesario indicar de qu manera se quiere distribuir la informacin entre los distintos archivos. Para ello es necesario configurar una tabla de rangos, que reside en el mdulo de nombre ICHRRNG (Range Table). Ambas tablas deben compilarse y linkeditarse a partir de un mdulo fuente en lenguaje assembler. No describiremos en esta gua su configuracin. Solo destacamos que, al no tener instrucciones sino simplemente definiciones de constantes, no es necesario recompilarlos al migrar el sistema operativo. Son compatibles hacia arriba, y se pueden simplemente copiar. En cualquier caso, toda la informacin necesaria sobre ambas tablas est en el libro Security Server RACF System Programmers Guide. Para simplificar, supondremos en este captulo lo siguiente: - La base de RACF no est compartida entre varios sistemas. No trataremos, en consecuencia, ningn aspecto relativo a sysplex communication o data sharing mode. - El sistema tiene una base de backup activa y sincronizada con la primaria. - El subsistema RACF se encuentra activo (lo cual es altamente recomendable, por cierto). Esto posibilita, entre otras cosas, ejecutar el comando RVARY desde una consola como comando de operador. No debe confundirse el subsistema RACF con el producto RACF propiamente dicho, que puede funcionar an cundo no se encontrara activo el subsistema. Toda la informacin necesaria sobre el subsistema RACFse encuentra disponible en el libro Security Server RACF System Programmers Guide. No daremos la sintaxis completa del comando RVARY, sino que analizaremos por separado los comandos necesarios para cada una de las funciones que describiremos en esta gua. Estos pueden ejecutarse interactivamente desde una sesin de TSO, en forma batch, o bien por consola como comandos de operador. Observacin: An cuando la organizacin haya definido passwords para ambas funciones del RVARY, el sistema seguir aceptando la password por defecto YES para los operandos ACTIVE, SWITCH y DATASHARE|NODATASHARE, siempre y cuando se ejecute el comando desde una consola con autoridad MASTER (notemos que el operando INACTIVE est expresamente excluido de esta posibilidad). En tal caso, la respuesta YES puede ingresarse desde cualquier consola (lo fundamental es que tenga autoridad MASTER aquella dnde se ejecuta el comando RVARY). Esta flexibilizacin tiene por objeto permitir una recuperacin de emergencia, an si no se dispone de las passwords del RVARY.

Apuntes de RACF

Juan Mautalen

133 De todos modos, un usuario con atributo SPECIAL tiene siempre la posibilidad de cambiar ambas passwords, an sin conocer sus valores actuales. Resulta por lo tanto de suma importancia controlar adecuadamente todas las consolas del sistema con autoridad MASTER, de modo que solo usuarios debidamente autorizados estn en condiciones de ejecutar comandos en ellas. Sobre este punto, conviene recalcar que los usuarios con acceso a TSO pueden habitualmente, desde el SDSF, acceder a una consola con autoridad MASTER a travs del comando ULOG. Resulta pues fundamental limitar la posibilidad de ejecutar comandos de operador desde SDSF, controlando el uso de la / mediante un perfil apropiado en la clase SDSF (o GSDSF, su correspondiente clase agrupadora). 10.2 - Listado de la configuracin de las bases Sintaxis: RVARY LIST Autoridad requerida: ninguna Este comando es meramente informativo y no efecta modificacin alguna. Lista la siguiente informacin sobre todos los datasets que conforman las bases de RACF vigentes en el sistema: Nombre del dataset Nmero de secuencia Disco dnde reside Estado (activo o inactivo) Uso (primario o backup) Una salida de este comando tendra el siguiente aspecto:
ICH15013I RACF DATABASE STATUS: ACTIVE YES YES YES YES USE PRIM BACK PRIM BACK NUMBER 1 1 2 2 VOLUME MVSRES MVSPR1 MVSRES MVSPR1 DATASET SYS1.BASERACF.PRIM1 SYS1.BASERACF.BACK1 SYS1.BASERACF.PRIM2 SYS1.BASERACF.BACK2

ICH15020I RVARY COMMAND HAS FINISHED PROCESSING.

En este ejemplo, observamos que: Ambas bases de RACF, primaria y backup, se encuentran distribuidas en 2 datasets. Los nombres de estos datasets, definidos en la ICHRDSNT, son de libre eleccin por parte de la organizacin, no teniendo necesidad alguna de tener a SYS1 como HLQ. Los 4 datasets de encuentran activos. La base primaria reside en un disco distinto que la de backup. Esto es altamente recomendable, pues evita que ambas queden inutilizables en caso de fallo de un nico disco. Sin embargo, dada la tecnologa actual de dispositivos de almacenamiento, es probable que distintos discos lgicos correspondan en realidad al mismo disco fsico, con lo cual esta precaucin puede no resultar del todo efectiva. Es aconsejable que la base primaria resida en el disco residente. 10.3 - Switch de las bases Sintaxis: RVARY SWITCH [DATASET(nombre|*)]
Apuntes de RACF Juan Mautalen

134 Autoridad requerida: requiere ingreso por consola de la password para la funcin SWITCH Este comando intercambia el uso de los datasets de la base primaria especificados en el operando DATASET con sus correspondientes archivos de bakup. En efecto, los datasets pertinentes de la base de backup pasan a tener uso primario, mientras que los originalmente primarios pasan a ser de uso backup, siendo tambin inactivados y desalocados. Si se codifica DATASET(*), o se omite el operando DATASET, el switch acta para todos los datasets que conforman la base primaria. Observaciones: Para poder switchear, el dataset de backup, que pasar a tener uso primario, debe necesariamente estar activo. En caso contrario, RACF ignora el comando y emite un mensaje de error. Como la funcin de SWITCH intercambia y deja inactivo el nuevo backup, si se pretende volver a la configuracin original mediante la ejecucin de un nuevo SWITCH, es necesario previamente reactivar el backup. El comando RVARY SWITCH acta siempre sobre datasets de uso primario. Si se codifica en el operando DATASET un archivo cuyo uso es de backup, RACF ignora el comando y emite un mensaje de error. Ejemplo: Supongamos que, en el sistema con la configuracin dada en el ejemplo anterior, el dataset de nombre SYS1.BASERACF.PRIM2 se encuentra daado, por lo cual es necesario trasladar el procesamiento a su correspondiente dataset de backup. Para ello, debe ejecutarse el siguiente comando: RVARY SWITCH DATASET(sys1.baseracf.prim2) Completada la ejecucin exitosa del comando, el listado de la nueva configuracin arrojara el siguiente resultado:
ICH15013I RACF DATABASE STATUS: ACTIVE YES YES NO YES USE PRIM BACK BACK PRIM NUMBER 1 1 2 2 VOLUME MVSRES MVSPR1 *DEALLOC MVSPR1 DATASET SYS1.BASERACF.PRIM1 SYS1.BASERACF.BACK1 SYS1.BASERACF.PRIM2 SYS1.BASERACF.BACK2

ICH15020I RVARY COMMAND HAS FINISHED PROCESSING.

En esta situacin, debera repararse lo antes posible el dataset daado (al estar desalocado, es posible manipularlo), activarlo, switchear nuevamente y finalmente activar el backup para retornar a la configuracin normal. 10.4 - Activacin/inactivacin de las bases Sintaxis: RVARY ACTIVE|INACTIVE[NOCLASSACT(clase|*) (NOTAPE)] [DATASET(nombre|*)] Autoridad requerida: requiere ingreso por consola de la password para la funcin STATUS Este comando permite activar o inactivar tanto la base primaria como la de backup, incluso a nivel de dataset, si se encontraran particionadas. En una situacin normal, todos los datasets de las bases deben estar activos. Si un dataset de la base primaria est inactivo, RACF no puede procesar requerimientos para los que precise informacin que reside en l (excepto que la tenga disponible en memoria). Por lo tanto, en esta
Apuntes de RACF Juan Mautalen

135 situacin, es de esperar que se produzcan errores (abends). El correspondiente dataset de backup, an cuando se encontrara activo, no reemplaza automticamente al primario. Para ello, debe ejecutarse el comando de switch adecuado. Solamente ocurre un switch automtico a la base de backup si un error de I/O sobre la base primaria pone offline el disco dnde reside. Cuando todos los datasets de la base primaria se encuentran inactivos, se produce una situacin, bastante molesta por cierto, conocida como failsoft processing. En estas condiciones, el sistema resulta prcticamente inoperable, ya que el operador debe aprobar por consola todo intento de acceso a datasets. Para otro tipo de recursos, el otorgamiento o el rechazo de un requerimiento de acceso queda en manos de la aplicacin o subsistema que lo requiera. Son de esperar, de todos modos, innumerables inconvenientes. Si el sistema se encuentra en failsoft processing, situacin por cierto de emergencia, debe disminuirse la actividad al mnimo indispensable y tomarse inmediatamente las acciones necesarias para volver a la normalidad. Si un dataset de la base de backup est inactivo, RACF contina procesando de manera normal, solo que eventualmente no podr replicar en la base de backup las modificaciones que involucren al correspondiente dataset primario. Si bien esto no origina ninguna situacin crtica, en tanto no impacta directamente en la seguridad del sistema, tener desactualizada la base de backup no es en absoluto aconsejable. Si fuera el caso, se debe proceder cuanto antes a resincronizarla con la base primaria, usando el IRRUT200. El operando ACTIVE indica que se quiere reactivar los datasets especificados en DATASET. Si se codifica ACTIVE y se omite DATASET, RACF activar todos los datasets de la base primaria. El operando INACTIVE indica que se quiere inactivar (y desalocar) los datasets especificados en DATASET. Si se codifica INACTIVE y se omite DATASET, RACF inactivar todos los datasets de la base primaria, provocando la entrada del sistema en failsoft processing. La opcin NOCLASSACT del operando INACTIVE permite establecer una lista de clases de la CDT (o todas, si se codifica *) para las cuales la proteccin de RACF no estar en efecto mientras se encuentre la base inactiva. La opcin NOTAPE del operando INACTIVE indica que la proteccin para cartuchos establecida en la clase TAPEVOL no estar en efecto mientras se encuentre la base inactiva. En cualquier caso, la proteccin vuelve a tomar efecto inmediatamente al reactivar la base. No debe confundirse esta inactivacin de clases al momento de inactivar la base con la inactivacin habitual de clases que se establece a nivel de la SETROPTS. 10.5 - Procedimientos de recuperacin de bases de RACF Si bien es muy poco frecuente, es posible que algn dataset de las bases de RACF se dae y sea necesario repararlo o reemplazarlo. Como paso previo a cualquier intento de manipulacin, es necesario inactivarlo y desalocarlo, para lo cual debe ejecutarse el comando RVARY con el operando INACTIVE. Vamos a analizar 3 posibles escenarios de fallos, describiendo para cada uno un posible proceso de recuperacin. Supondremos que la base no se encuentra particionada. En caso de estarlo, solo deber aplicarse el procedimiento para los datasets que experimenten problemas. La base primaria funciona correctamente pero falla la base de backup 1. Inactivar la base de backup ejecutando el comando: RVARY INACTIVE DATASET(nombre-base-backup) 2. Analizar qu tipo de problema presenta la base de backup. Si fuese necesario, deletearla, realocarla con el mismo nombre en un disco adecuado y copiarle la base primaria utilizando el utilitario IRRUT200 con PARM=ACTIVATE.

Apuntes de RACF

Juan Mautalen

136 La base primaria falla y la base de backup funciona correctamente 1. Switchear las bases ejecutando el comando: RVARY SWITCH 2. Analizar qu tipo de problema presenta la base de backup actual (primaria original, que estaba fallando). Si fuese necesario, deletearla, realocarla con el mismo nombre en un disco adecuado y copiarle la base primaria actual (backup original) utilizando el utilitario IRRUT200 con PARM=ACTIVATE. 3. Switchear las bases nuevamente ejecutando el comando: RVARY SWITCH 4. Activar la base de backup actual (backup original) ejecutando el comando: RVARY ACTIVE DATASET(nombre-base-backup) Ambas bases -primaria y backup- estn fallando 1. Inactivar la base primaria ejecutando el comando: RVARY INACTIVE DATASET(nombre-base-primaria) El sistema entra pues momentneamente en failsoft processing. 2. Analizar qu tipo de problema presenta la base de primaria. Si fuese necesario, deletearla, realocarla con el mismo nombre en un disco adecuado y copiarle un backup de la base de RACF lo ms actualizado posible y que se encuentre en buenas condiciones. Si se dispone de uno en disco, utilizar el utilitario IRRUT200 (si el backup es de igual tamao y reside en un disco de igual geometra) o el IRRUT400. Si el nico backup utilizable est en cartucho, copiarlo usando el programa utilitario IEBGENER. 3. Activar la base primaria ejecutando el comando: RVARY ACTIVE DATASET(nombre-base-primaria) El sistema deja pues de estar en failsoft processing. 3. Inactivar la base de backup ejecutando el comando: RVARY INACTIVE DATASET(nombre-base-backup) 4. Copiar la base primaria sobre la de backup utilizando el utilitario IRRUT200 con PARM=ACTIVATE. En este escenario, las modificaciones hechas en la base de RACF desde el momento en que se tom el backup utilizado para la recuperacin y el de la falla de ambas bases activas se habrn perdido. De todos modos, este perodo debera ser breve (si existe una correcta frecuencia de backups), y un anlisis de los registros 80 del SMF correspondientes a este lapso permitira reconstruir los cambios.

Apuntes de RACF

Juan Mautalen