Apuntes de RACF

Apuntes de RACFJuan Mautalen 2 PREFACIO Este texto intenta ser una guía básica de RACF (Resource Access Control Facility), dirigida principalmente a aquellas personas que quieran iniciarse como administradores del producto. De todos modos, la información 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 mínimos. Una cierta familiaridad con el entorno z/OS, sumada a un manejo básico de TSO, ISPF y JCL, son suficientes para comprender sin problemas los temas expuestos. La información que se brinda está basada en la versión de RACF provista por la versión 1.11 del z/OS. Sin embargo, salvo contadas excepciones, también es válida 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 están mas allá del contenido que debe abarcar un texto básico (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 más frecuente. La sintaxis completa puede consultarse en línea desde una sesión de TSO mediante el comando HELP, o bien en el manual de IBM “RACF - Command Languaje Reference”. En cualquier caso, toda información sobre RACF que el lector no encuentre en la presente guía, o que pretenda ampliar, puede hallarla en la documentación oficial del producto. En lo relativo al alcance, tampoco he incursionado en el análisis de la protección dada por RACF a ciertos “productos de base”, como ser: DB2, CICS o IMS. Para ello, debe no solo debe recabarse información en la bibliografía específica de RACF sino principalmente en la documentación propia de cada producto. En la siguiente dirección 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 sería leer la presente guía junto a una terminal con acceso a TSO, disponiendo de un usuario con atributo SPECIAL, para poder probar en la práctica los comandos y opciones que se van describiendo. Naturalmente, las opciones críticas deben siempre experimentarse en un entorno no productivo, a menos que se pretenda adquirir una rápida popularidad -y no de la mejor manera- dentro de la organización. En ciertas ocasiones notarán que se hace referencia, en determinado capítulo, a algún tema que recién se trata en detalle en uno posterior. Esto me resultó inevitable, más allá de mis esfuerzos por organizar el material lo más posible. A lo largo de esta guía he optado, en muchos casos, por dar recomendaciones respecto a la configuración y políticas de seguridad que estimo más convenientes. Estas deben entenderse como mi opinión personal, producto de mi propia experiencia. En ningún caso se trata de sugerencias de IBM, salvo que ello se indique explícitamente. En cualquier caso, toda organización debe determinar sus necesidades particulares de seguridad y decidir qué opciones le resultan las más apropiadas para satisfacerlas. Juan Guillermo Mautalen Buenos Aires, julio 2011 Apuntes de RACF Juan Mautalen 3 TABLA DE CONTENIDOS 1 - INTRODUCCIÓN ..........................................................................................................................6 1.1 - Consideraciones generales .........................................................................................................6 1.2 - Identificación y autenticación de usuarios ..................................................................................6 1.3 - Control de acceso a recursos ......................................................................................................6 1.4 - Herramientas de auditoría ..........................................................................................................6 1.5 - Seguridad externa para aplicaciones ...........................................................................................7 2 - LA BASE DE RACF .......................................................................................................................8 2.1 - Consideraciones generales .........................................................................................................8 2.2 - Características............................................................................................................................8 2.3 - Estructura...................................................................................................................................9 2.4 - Actualización de la base .............................................................................................................9 3 - USUARIOS Y GRUPOS .............................................................................................................. 12 3.1 - Consideraciones generales ....................................................................................................... 12 3.2 - Administración de grupos de RACF ......................................................................................... 12 3.3 - Alta de un grupo ...................................................................................................................... 13 3.4 - Modificación de un grupo ........................................................................................................ 14 3.5 - Eliminación de un grupo .......................................................................................................... 15 3.6 - Listado de un grupo ................................................................................................................. 15 3.7 - Administración de usuarios de RACF ...................................................................................... 16 3.8 - Alta de un usuario .................................................................................................................... 18 3.9 - Modificación de un usuario ...................................................................................................... 19 3.10 - Eliminación de un usuario ...................................................................................................... 21 3.11 - Listado de un usuario ............................................................................................................. 22 3.12 - Comando PASSWORD.......................................................................................................... 26 3.13 - Atributos de usuario ............................................................................................................... 27 3.14 - Conexión de un usuario a un grupo ........................................................................................ 35 4 - PROTECCIÓN DE DATASETS ................................................................................................. 39 4.1 - Consideraciones generales ....................................................................................................... 39 4.2 - Perfiles discretos ...................................................................................................................... 40 4.3 - Perfiles genéricos ..................................................................................................................... 40 4.4 - Cómo determina RACF el perfil protector de un dataset ........................................................... 41 4.5 - Niveles de autoridad para perfiles de dataset ............................................................................ 42 4.6 - Administración de perfiles de dataset ....................................................................................... 43 4.7 - Definición de un perfil de dataset ............................................................................................. 43 4.8 - Modificación de un perfil de dataset ......................................................................................... 47 4.9 - Eliminación 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 genéricos ........................................................................ 54 4.13 - Creación 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 - Estadísticas iniciales ................................................................................................................ 59 Apuntes de RACF Juan Mautalen ...................................21 ...............................41 .........................................................Auditoría de usuarios con atributo OPERATIONS .....................Niveles de acceso .. 74 5... 66 5...............Auditoría de usuarios con atributo SPECIAL .............10 .....................33 ..............................12 ..................................25 ..............36 ....................................................... 60 5............................................................Clases con perfiles genéricos.........Clases con perfiles genéricos compartidos en memoria (GENLISTeadas) ..........................Restricción para la creación de perfiles más específicos que perfiles existentes .................Protect-all ..................................... 70 5..........Clases activas .............................................Recursos generales y perfiles ..Clases en la GLOBAL ............ 62 5...............Modelización de perfiles de dataset ............. 84 5........................ 88 6......................................................... 81 5.............9 ..Protección automática de datasets .Revocación automática por inactividad . 96 6........................ 91 6.......Lista de grupos ......... 72 5...................................................................................................26 ...............6 .................................................35 ....................9 .....37 ....................................................................................................................Permisos sobre perfiles de recursos generales ........................1 .................................................... 66 5.............................16 .................................................... 62 5. 65 5...................Archivos de un único calificador ........................ 64 5................................................ 61 5............ 84 5...... 81 5...................................28 ....Auditoría de transacciones APPC ....................................................34 ..............Opciones de logging para clases .........Clases de miembros y agrupadoras ...............Lenguaje .....................................19 ...........................................5 ....................................Clases RACLISTeadas vía RACROUTE REQUEST=LIST...........................6 .........Control de programas ............................ 65 5................................................................................................................ 75 5................Comandos de REFRESH ....17 .32 ............Opción ADDCREATOR ..............................Borrado físico de archivos ........... 60 5......................7 ............ 85 5....................................... 88 6.......Opciones de auditoría relativas a security levels y security labels ...............................................Clases con perfiles genéricos y discretos compartidos en memoria –RACLISTeadas.........................Listado de un perfil de recursos generales ..........................................................................................................................................................................................................30 ............................................................Auditoría de violación de comandos......Uso del ** en perfiles genéricos de dataset .....................23 .....31 .................Definición de un perfil de recursos generales ............................................................ 94 6............... 97 Apuntes de RACF Juan Mautalen ...... 73 5.............................................................Opciones relativas a PASSWORD .....Clases con comandos genéricos......20 .................. 71 5...................................42 .................................................Período de retención para archivos en cartucho . 60 5.............................................................18 ............................29 ...................4 ........................... 69 5. 63 5...........................................................Modificación de un perfil de recursos generales .15 ........................... 67 5...........................39 .............................Otras opciones vinculadas a security levels y security labels ..................................10 ........ 68 5........................................................24 ..Perfiles genéricos ....... 90 6............3 .....................................PROTECCIÓN DE RECURSOS GENERALES . 82 5........ 85 5.................... 74 5.. 85 6 ......................................................................................................... 69 5....Protección de archivos en cartucho.........Clases auditadas ......7 .......................... 88 6..................Clases con estadísticas .................. 76 5................................................4 5................................Máximo global y default para la validez de la clave de una sesión ....11 ...................Cómo determina RACF la protección de un recurso general ................... 61 5........................Passwords del RVARY ........................................................5 .........................................................................................8 .................................................... 70 5...............Terminales no protegidas ..........................................................................Eliminación de un perfil de recursos generales ............................................. 91 6..................................................11 ......................13 ..........................................................................................Opciones relativas a JES ................ 95 6.......................................22 ............................2 ....14 ..............................................................................40 .. 81 5........................................... 92 6............38 ................. GLOBAL=YES ....Comando SEARCH .................................................................................... 72 5....................................8 .............................................................................................. 75 5........ 94 6.... 83 5....27 ...Nombres reales de dataset .........................................................Acceso a datasets no catalogados ...................................................................... .................................................. 101 7.............................................................................................................. 116 9.................IRRDBU00 ...................................................... 101 7........................................................................................... 109 8 – PROCESO DE CHEQUEO DE AUTORIDAD .........................................4 .............................................................................................................6 .1 ........2 ..................................................................IRRRID00 ....................................................................PROGRAMAS UTILITARIOS ...............................................................5 ................. 130 10 ......................IRRUT400 ............................................................Clase FACILITY ..............................................1 .......................... 133 10.........................................................................................................................3 ............................... 133 10.4 ............4 .CLASES PARTICULARES .........................IRRMIN00.....1 ....... 121 9... 113 9 .... 125 9................3 ...................................Clase STARTED ..................................7 ....IRRUT200 .......... 116 9...........5 ................... 106 7................................................................... 118 9......IRRUT100 .................................................................................................................................................................................................................................2 ...............Clase GLOBAL .........8 .............. 124 9...............2 .................3 ...................................................2 ...............................................Procedimientos de recuperación de bases de RACF......................... 132 10............... 116 9.................................................................................... 113 8..............Clase PROGRAM .............................5 ........Consideraciones generales ..................................................................................... 128 9................................Consideraciones generales ..........Activación/inactivación de las bases....................................................... 103 7...................... 132 10........................Otros Utilitarios .................................................................................................Switch de las bases ..Listado de la configuración de las bases .Consideraciones generales ..........................................................................................5 7 ..Autoridad de un usuario sobre un recurso .................................................... 134 10............................................................ 113 8........................................................... 101 7.............. 135 Apuntes de RACF Juan Mautalen ..Consideraciones generales ......................................................COMANDO RVARY.........1 .......................................................................... 3 .2 . RACF consulta dentro de su base cómo se encuentra protegido el recurso. los siguientes eventos: o o o o Día 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 ejecución de comandos de RACF Apuntes de RACF Juan Mautalen . y devuelve a la aplicación solicitante un código de retorno que indica si el acceso está permitido (RC=00). RACF controla en el momento del logon ciertos aspectos de seguridad adicionales. Por ejemplo.4 .1 . se encarga de autenticarlo. en el caso de un dataset) En base a la información recibida.Control de acceso a recursos Cuando un usuario intenta acceder a un recurso protegido por RACF. la aplicación dentro de la cual surge el requerimiento se comunica con RACF enviándole. básicamente.) debe poseer un identificador de usuario (userid) y una clave de acceso (normalmente una password. para brindar seguridad en el entorno mainframe. comprobando que el userid exista en su base. lectura o grabación.6 1 . Es la aplicación la que finalmente otorga o rechaza el acceso solicitado. vamos a asumir en todo la presente guía que el ESM utilizado es RACF. etc.INTRODUCCIÓN 1. aplicaciones.Identificación y autenticación de usuarios Todo usuario que requiera acceso al entorno del z/OS (subsistemas. provisto por IBM.Consideraciones generales RACF (Resource Access Control Facility) es el componente del sistema operativo z/OS. que no tenga sus derechos de acceso bloqueados). entre otros. a través de las cuales se pueden detectar. 1. que esté habilitado a ingresar en ese día y horario o que se encuentre autorizado a ingresar desde esa terminal. como TOP/SECRET o ACF2. Si bien el z/OS permite la utilización de otros ESM (External Security Manager) en lugar de RACF. Básicamente. aunque existen otros medios soportados). la siguiente información: o o o o Identificador del usuario Nombre del recurso Clase a la que pertenece el recurso Nivel de autoridad requerido (por ejemplo. basándose naturalmente en la respuesta recibida de RACF. verifica que el usuario no se encuentre revocado (esto es. Además. controlando que la password ingresada sea la que corresponde. ambos de la empresa Computer Associates. Asimismo. o si no posee la información necesaria para responder el requerimiento (RC=04). denegado (RC=08). RACF se ocupa de identificar al usuario. 1.Herramientas de auditoría RACF provee una flexible gama de opciones de auditoría. RACF provee los siguientes servicios: Identificación y autenticación de usuarios Control de acceso a recursos Herramientas de auditoría Seguridad externa para aplicaciones 1. sino que robustece la seguridad global de la plataforma.7 Ejecución exitosa de comandos de RACF Cantidad de veces en que determinado recurso ha sido accedido o o La información relativa a accesos (exitosos o fallidos) se graba en registros tipo 80 del SMF (System Management Facility). se graba directamente en la base de RACF. conjuntamente con un componente básico del sistema operativo denominado SAF (System Authorization Facility). En este sentido. brinda la posibilidad de desarrollar aplicaciones cuya seguridad esté controlada externamente por RACF. es cada vez más frecuente que los proveedores independientes de software que desarrollan productos para z/OS diseñen sus aplicaciones de modo que la seguridad sea controlada externamente por RACF. 1. Otro tipo de información.5 . no solo facilita y simplifica enormemente las tareas administrativas. Contar con un producto como RACF que centralice la seguridad de todas las aplicaciones. o la cantidad de veces que se logueó al sistema.Seguridad externa para aplicaciones RACF. como ser la fecha y hora del último ingreso exitoso de un determinado usuario. Apuntes de RACF Juan Mautalen . de carácter estadístico. RACF. siendo las consecuencias impredecibles (puede incluso que los problemas no se noten inmediatamente. 2.RACF. de los datasets que conforman sus bases. se puede switchear fácilmente a la base de backup y seguir operando normalmente. pero posible). el cual se describirá en detalle en el capítulo referido a programas utilitarios. 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. que mencionamos a continuación.BACK1 SYS1.8 2 . se actualizará automáticamente cada vez que se efectúen modificaciones (siempre y cuando estén configurados los parámetros necesarios para que esto suceda). de manera muy básica. BASE PRIMARIA BASE BACKUP SYS1.2 . sino que solo aparezcan cuando Apuntes de RACF Juan Mautalen . cualquier movimiento posterior implicará que los datasets ya no se encuentren dónde RACF tiene registrado.PRIM1 SYS1. Por lo tanto. La base de backup. la base de backup debe estar particionada exactamente de la misma manera).RACF. si la base primaria presenta algún error (situación realmente muy poco frecuente. aunque absolutamente recomendable). Idénticas consideraciones se aplican a la base de backup (si la base primaria esta particionada en más de un dataset. La base primaria de RACF puede consistir de un único dataset. o puede estar distribuida en más de uno. que por cuestiones obvias de seguridad conviene que resida en un disco distinto al de la primaria. que deben residir en disco. Los datasets que constituyen las bases de RACF deben ser definidos con características específicas. como veremos en el capítulo que trata el comando RVARY.LA BASE DE RACF 2.RACF.BACK2 El diagrama muestra una configuración de una base de RACF particionada en 2 datasets La alocación e inicialización de las bases de RACF se realiza a través del utilitario IRRMIN00. dentro de los discos.Características 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 organización sea PSU (Physical Secuencial Unamovable). en el momento de IPL RACF toma registro de la ubicación absoluta. de modo que una eventual desfragmentación del disco dónde esté alocado no mueva el dataset de lugar. En efecto.PRIM2 Actualización automática SYS1.Consideraciones generales Describiremos.1 . El nombre de la base es de libre elección por parte de la organización. De este modo. aunque naturalmente debe adecuarse a las reglas que rigen la nomenclatura de cualquier dataset dentro del entorno z/OS. 4 . naturalmente. que pueden pensarse como registros que contienen distintos campos. para que puedan alocarse como PSU. Es habitual y recomendable que la base de backup esté alocada con idéntico tamaño que la primaria.Estructura La base de RACF tiene una estructura propia bastante compleja. Todo perfil pertenece a una “clase” (class). Sin embargo. siendo la más usual el entorno TSO. cada una con un propósito específico. ya que una descripción detallada está más allá de los objetivos de este manual introductorio. si se trata de pocos comandos).11. Los comandos de RACF solo se pueden ejecutar desde una interfaz que los admita. agrupan lógicamente a los perfiles. Debido a esta recomendación. desde el punto de vista de storage. que está identificada con un nombre de hasta 8 caracteres. por lo tanto. deben alocarse como PS y tomarse todas las precauciones necesarias para que los datasets no sean movidos (mientras se encuentren activos en alguna LPAR). IBM provee 230 clases predefinidas. sino muchos otros factores adicionales). De no ser posible. por entidades denominadas “perfiles” (profiles). esencialmente. La base de RACF está conformada. el espacio ocupado por las bases de RACF es realmente pequeño. 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). 2.9 efectivamente sea sobrescrito con nueva información el área de disco correspondiente a la ubicación original). Apuntes de RACF Juan Mautalen . o sea que ocupen un único extent. en la presente guía. solo haremos referencia a las clases predefinidas por IBM. Sólo daremos una idea básica de cómo está organizada. del volumen de información que cada organización tenga almacenada (lo cual no solo involucra la cantidad de usuarios definidos. Si fuese necesario. En cualquier caso. 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 ejecución de transacciones CICS Protege la invocación de programas Protege el uso de procedimientos de logon a TSO Protege el uso de códigos 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. o batchground (mejor opción si se tiene que ejecutar una gran cantidad). El tamaño de la base depende.Actualización de la base La base de RACF debe modificarse únicamente (salvo casos excepcionales) a través de la ejecución de comandos de RACF. Las clases. Es obligatorio que tengan su espacio alocado en forma contigua. En el RACF que viene con el sistema operativo z/OS 1. Clase USER GROUP DATASET Descripción 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.3 . existe la posibilidad de definir clases adicionales. Pueden ser ejecutados en foreground (opción preferible. que suelen ser suficientes para satisfacer los requerimientos de seguridad habituales de una organización. cuyos nombres son fijos e inalterables. Estos proporcionan una interfaz amigable para el usuario. y son replicados inmediatamente en la base de backup (asumiendo que RACF esté configurado para mantener sincronizadas ambas bases). Esta facilidad cobra especial importancia cuando. Aunque no suele resultar necesario en la operatoria habitual. mostramos a continuación un comando que da de alta un usuario en la base de RACF: Apuntes de RACF Juan Mautalen . Sin embargo. siendo mucho más práctico y veloz ejecutar los comandos tipeándolos directamente. no haremos referencia en el futuro a la utilización de los paneles. no tendrá la posibilidad de ejecutar ningún comando de RACF. que solo tenga acceso a regiones CICS. evitándole tener que recordar los comandos de RACF y su sintaxis. A modo de ejemplo. Se listan a continuación los comandos de RACF que consideramos más 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 Abreviación AU ALU DU LU AG ALG DG LG AD ALD DD LD RDEF RALT RDEL RL PE PW CO RE SR RACDCERT SETR RVARY Descripción Define un usuario nuevo Modifica características de un usuario existente Borra un usuario Lista las características de un usuario Define un nuevo grupo de usuarios Modifica características de un grupo existente Borra un grupo Lista las características de un grupo Define un nuevo “perfil de dataset” Modifica características de un “perfil de dataset” existente Borra un “perfil de dataset” Lista las características de un “perfil de dataset” Define un nuevo perfil de recursos generales Modifica características de un perfil de recursos generales existente Borra un perfil de recursos generales Lista las características 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 búsquedas en la base de RACF Permite la administración de certificados digitales Lista o modifica opciones de la SETROPTS Lista. A lo largo de la presente guía analizaremos la mayoría de los comandos y describiremos sus operandos más relevantes. por algún motivo. Los comandos actúan siempre sobre la base primaria. Es de destacar que un usuario final. ya que no suelen ser muy utilizados. también se pueden ejecutar comandos de RACF desde una consola del sistema. algunos posicionales y otros no. el administrador de RACF memorizará rápidamente la sintaxis de los comandos básicos.10 Existe también la posibilidad de ejecutar comandos de RACF utilizando una serie de paneles accesibles desde una sesión de TSO. intercambia y activa/inactiva bases de RACF Los comandos requieren operandos. Por lo tanto. en cuyo caso la utilización de los paneles resulta lenta y tediosa. no se disponga de sesiones de TSO. Ciertos operandos. al no haberse codificado explícitamente OWNER. Operando no posicional que define el nombre. Operando no posicional que define el grupo default. Valor del nombre. toman un valor por defecto. quedará por defecto como OWNER del nuevo usuario aquel que ejecute el comando ADDUSER. En el caso anterior. abreviación de ADDUSER. Valor del grupo default. Valor de la password inicial –expirada-. Identificador del usuario.11 AU rh3472 NAME(‘juan’) DFLTGRP(rrhh) PASSWORD(abc123) AU rh3472 NAME juan DFLTGRP rrhh PASSWORD abc123 Comando básico. Apuntes de RACF Juan Mautalen . por ejemplo. Operando no posicional que define la password inicial. Variable posicional que debe seguir al comando AU. si se omiten. la misma es usualmente transformada automáticamente a mayúsculas. de modo que para el administrador resulta como si RACF no distinguiera entre ambas. Nombre del grupo superior. debido a una restricción propia del TSO. no es subgrupo de ningún otro).USUARIOS Y GRUPOS 3. Owner del grupo. La Installation Data. RACF solo permite el uso de mayúsculas para identificadores de usuarios y grupos (y. la máxima longitud admisible es de 7 caracteres.12 3 . que pasa a constituir su "grupo default" (default group). el usuario puede estar conectado a otros grupos. ya que eso facilita en gran medida la administración posterior (y resulta particularmente trabajoso renombrar gran cantidad de usuarios. Normalmente.2 . como su nombre completo lo indica. $ y @). de acuerdo a sus necesidades y preferencias. Con respecto al nombre.1 . $ y @. consiste en una cadena de caracteres alfanuméricos (incluyendo #. SYS1 resulta ser pues el único grupo que no tiene grupo superior (o sea. de los cuáles solo describiremos los más relevantes. conocidos como nacionales). si bien un usuario está eventualmente conectado a varios grupos. que surge del hecho de que todo grupo nuevo debe ser definido como subgrupo de otro existente. De todos modos. que al igual que en el caso de usuarios. uno y solo uno de ellos es su grupo default. si se ingresa información en minúsculas. ya señalamos las condiciones que debe cumplir. es un campo dónde la organización almacena información administrativa sobre el grupo que considere relevante. Apuntes de RACF Juan Mautalen . 3. Todo grupo de RACF tiene un identificador único (grupid). NOMBRE DATA SUPGROUP OWNER Nombre del grupo. de longitud mínima 1 y máxima 8 y que no debe empezar con un número).Administración de grupos de RACF Todas las características de un grupo de RACF se encuentran almacenadas en un “perfil de grupo”. Adicionalmente. Los grupos de RACF se distribuyen de acuerdo a una estructura de árbol. En el caso de usuarios de TSO. máxima de 8 y con la restricción de que el primer carácter no sea numérico. Información sobre el grupo. que viene predefinido por IBM (no es posible cambiar su nombre). ya que todo grupo (excepto SYS1) debe ser subgrupo de algún otro (“B tiene como grupo superior a A” o “B es un subgrupo de A” son 2 formas distintas de expresar lo mismo). En lo más alto del árbol se encuentra el grupo SYS1. si se descubre que la convención elegida inicialmente no es adecuada). para casi todos los demás perfiles). con una longitud mínima de 1.Consideraciones generales Toda persona que deba ingresar a alguna aplicación dentro del entorno z/OS necesita tener un identificador de usuario (userid). 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 ningún usuario. El mismo consiste en una cadena de caracteres alfanuméricos (incluyendo los caracteres #. Todo usuario debe ser definido en la base como miembro de un grupo de RACF. con una longitud máxima de 255 caracteres. Los grupos son pues conjuntos de usuarios. Conviene recalcar la importancia de la adopción de una buena nomenclatura. en general. Cada organización debe elegir una convención para los identificadores de sus usuarios. Dicho de otro modo. este campo contiene una breve descripción del grupo. El grupo superior es imprescindible. Este perfil tiene distintos campos. el valor por defecto es el usuario que ejecuta el comando. Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de acción al grupo superior del que se intenta definir. y se aplica a cualquier tipo de perfil en la base de RACF. En este caso. el grupo simplemente queda definido sin este segmento.3 . el valor que asume por defecto es el “actual grupo de conexión” del usuario que ejecuta el comando.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 continuación del comando ADDGROUP. También existe una opción dentro del menú del ISPF que permite ingresar comandos en foreground que ocupen más de un renglón. Tener autoridad a través de perfiles apropiados en la clase FIELDS. Si se ejecutan desde un dataset o embebidos en un job. Si no se especifica SUPGROUP. dada la cantidad de operandos que es necesario codificar en algunos casos. Autoridad requerida Para definir un nuevo grupo. que por lo tanto debe ser el grupo FINANZAS. el valor que puede tomar debe ser un usuario o bien el grupo superior. Estar conectado al grupo superior con nivel de autoridad JOIN. Ejemplo: AG conta DATA(‘Subgerencia de Contabilidad’) SUPGROUP(finanzas) OWNER(finanzas) Este comando define un nuevo grupo de nombre CONTA. Es frecuente. el usuario tiene que cumplir alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema. no puede establecerse como owner de un grupo a otro que no sea su grupo superior. 3. el valor por defecto es 0000000000. Apuntes de RACF Juan Mautalen . que puede ser un usuario o un grupo. Si se omite OWNER. Si se omite el operando OMVS. que debe existir previamente (sino el comando falla). Dicho de otro modo. quien ejecuta el comando debe satisfacer alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema. Para poder definir al grupo con algún “segmento no base” (por ejemplo. El operando OMVS solo debe codificarse si se quiere proveer al grupo de un segmento de OMVS. Todo perfil debe tener un owner. un guión (-) al final de la línea indica que el comando continúa en la siguiente. En este caso particular. esto es el owner de un grupo. el segmento OMVS). que los comandos no entren en una única línea. El GID (Group IDentifier) debe ser un número comprendido entre 0 y 2147483647. Ser el owner del grupo superior.13 El concepto de owner es particularmente importante. Si se especifica OMVS y se omite GID. El mismo se define como subgrupo del grupo FINANZAS. se eligió definir como owner a un grupo. Jefatura’) Este comando modifica la Installation Data del grupo CONTA.Tener el atributo SPECIAL a nivel de un grupo que lo tenga dentro de su campo de acción. solo es necesario incluir aquellos operandos que correspondan a los campos que se desee modificar. ya que antes de borrar el grupo viejo. Si se pretende agregar algo a continuación de la DATA existente. No existe la opción de modificar el nombre de un grupo. . en este caso. quien ejecuta el comando debe satisfacer alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema. Al no ser una tarea sencilla.Estar conectado con nivel de autoridad JOIN.Ser el owner. Apuntes de RACF Juan Mautalen .4 .14 3. de modo que el nuevo grupo resulte un clon del anterior. ningún valor por defecto. Para poder agregar. conviene establecer desde el comienzo una buena nomenclatura. debe ejecutarse el comando retipeando toda la DATA. de modo a evitar. Consideraciones: Hacemos notar que el nuevo valor especificado en DATA reemplaza íntegramente al valor anterior. 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 excepción del manejo de segmentos no base). . Esto es trabajoso. Ser el owner del grupo. No se puede modificar parcialmente este campo. Ejemplo: ALG conta DATA(‘Sector de Contabilidad .Modificación de un grupo Sintaxis: ALTGROUP|ALG nombre [DATA(‘installation-data’)|NODATA] [SUPGROUP(grupo)] [OWNER(usuario/grupo)] [OMVS([GID(valor)|NOGID])|NOOMVS] Naturalmente. satisfacer alguna de las opciones que se enumeran: . Esto no solo es válido para grupos. modificar o deletear “segmentos no base” del grupo. así como también de todas sus autorizaciones. No se aplica. dentro de lo posible. Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de acción al grupo que se modifica. Tanto para el actual grupo superior como para el futuro. Observemos que si el owner del grupo era su grupo superior. quien ejecuta el comando debe cumplir con alguna de las condiciones siguientes: Tener el atributo SPECIAL a nivel de sistema. sino para la Installation Data de cualquier perfil en la base de RACF. La única forma que prevé RACF para renombrar un grupo consiste en darlo de baja para luego redefinirlo con el nuevo nombre. debe tomarse debida nota de los usuarios que tiene conectados. quien ejecuta el comando debe satisfacer alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema. Autoridad requerida Para poder modificar el grupo superior. tener que rebautizar grupos en el futuro. Ejemplo: LG conta OMVS La salida tendría el siguiente aspecto: INFORMATION FOR GROUP CONTA SUPERIOR GROUP=FINANZAS OWNER=FINANZAS INSTALLATION DATA=SECTOR DE CONTABILIDAD . no efectúa ninguna modificación sobre la base de RACF. Autoridad requerida Para poder borrar un grupo.JEFATURA NO MODEL DATA SET TERMUACC Apuntes de RACF CREATED=10. La ejecución exitosa del comando DELGROUP no elimina las referencias al grupo que puedan existir en otros perfiles de la base (por ejemplo.6 . o HLQ) coincida con el nombre del grupo. deben ser removidos todos sus usuarios. RACF no permite borrar un grupo si existen en la base perfiles de dataset cuyo primer calificador (High level Qualifier. ya que en caso contrario el comando falla. si se ejecuta en foreground. Estar conectado al grupo superior con nivel de autoridad JOIN.Eliminación de un grupo Sintaxis: DELGROUP|DG nombre Consideraciones: RACF no permite borrar un grupo que tenga usuarios conectados. con el objeto de mantener la base prolija (sin referencias a grupos inexistentes).245 Juan Mautalen . quien ejecuta el comando debe cumplir con alguna de las condiciones siguientes: Tener el atributo SPECIAL a nivel de sistema.Listado de un grupo Sintaxis: LISTGRP|LG nombre [OMVS] Este comando. el grupo puede figurar en la lista de acceso de perfiles de dataset o de recursos generales). o con salida a un dataset o al spool. Unicamente lista (en la pantalla de la terminal. a tal efecto. 3. Los mismos deben deletearse previamente a la ejecución de comando DELGROUP.15 Tener autoridad a través de perfiles apropiados en la clase FIELDS. si se ejecuta en batchground) información relativa al grupo. Por esta razón. a diferencia de los anteriores. RACF no permite borrar un grupo que tenga subgrupos. Ser el owner del grupo superior. debe modificarse el grupo superior de todos aquellos grupos que sean subgrupos del que se quiere borrar.5 . Ser el owner del grupo que se pretende deletear. el borrado del grupo debe ser acompañado de la eliminación de todas las referencias al mismo que existan en la base. Por lo tanto. como paso previo al comando DELGROUP. En consecuencia. 3. Mas adelante veremos que IBM provee. Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de acción al grupo que se pretende borrar. el utilitario IRRRID00. algunos segmentos no base (por ejemplo. de los cuales nos ocuparemos en este punto únicamente de los más relevantes. El grupo fue creado el día 245 del año 2010. etc. El grupo CONTA tiene segmento de OMVS con un GID igual 15. en este punto. de identificadores CONFJ01 y CONFJ02. quien ejecuta el comando debe satisfacer alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema.Administración de usuarios de RACF Todas las características de un usuario de RACF se encuentran almacenadas en un perfil de usuario.7 . Ser el owner del grupo. Tener el atributo AUDITOR a nivel de un grupo que tenga dentro de su campo de acción al grupo que se pretende listar.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. Tener el atributo AUDITOR a nivel de sistema. segmentos de TSO. El owner del grupo CONTA es el grupo FINANZAS.). quien ejecuta el comando debe cumplir con alguna de las condiciones siguientes: Tener el atributo SPECIAL a nivel de sistema. Tener autoridad a través de perfiles apropiados en la clase FIELDS. 3. Para poder listar “segmentos no base” del grupo. cuyos nombres son PAGOS y SUELDOS. se desprende claramente la siguiente información sobre el grupo CONTA: El grupo superior es el grupo FINANZAS. el resto de la información listada. El grupo CONTA tiene 2 usuarios conectados. No describiremos. Todos los segmentos se componen de campos. ya que para comprender ciertos campos específicos se requieren nociones que se verán más adelante (MODEL y TERMUACC. OMVS. Autoridad requerida Para listar el segmento base de un perfil de grupo. Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de acción al grupo que se pretende listar. El grupo CONTA tiene 2 subgrupos. más. Apuntes de RACF Juan Mautalen . Estar conectado al grupo con nivel de autoridad CONNECT o JOIN. que consta de un segmento base (obligatorio). por ejemplo). opcionalmente. Nombre del grupo default del usuario. CICS. la organización guarda información administrativa que considere importante sobre el usuario. Presentan una posibilidad más robusta que las passwords tradicionales. se puede colocar un nombre que identifique la tarea para la que es utilizado. El grupo default debe ser un grupo que exista previamente en la base de RACF. se puede incluir su número de documento y el sector de la empresa dónde desempeña sus tareas. Es de destacar que RACF permite también la autenticación a través de Password Phrases. Por ejemplo. El segmento de TSO solo debe definirse para usuarios que tengan que usar esta facilidad. lo cual significa que el usuario es forzado a cambiarla en el momento del logon inicial. expresado en Kbytes. En el campo NAME. que recién estará disponible a mediados del 2011. 0 indica superusuario. La mayoría de los parámetros especificados se convierten en los valores default para el usuario. Por lo tanto. Sin embargo. El OWNER del usuario puede ser cualquier otro grupo o usuario existente en la base de RACF. ya señalamos anteriormente las condiciones que debe cumplir. default para el usuario Tamaño máximo que el usuario puede requerir en el momento de logon Segmento de OMVS UID UID del usuario. no es necesario que cumpla con las reglas para passwords fijadas por la organización en la SETROPTS (esto se verá en detalle en el capítulo correspondiente). en la pantalla de logon a TSO. Nombre del procedimiento de logon a TSO (default) para el usuario Código de cuenta (default) para el usuario Comando a ejecutarse durante el logon a TSO Tamaño mínimo de la región. Número entre 0 y 2147483647. aún cuando el usuario tenga asignada una Password Phrase. no haremos más referencias a ellas en el presente manual. Password que se otorga usuario. Owner del usuario. de longitud máxima 20. Debe tener una longitud máxima de 8 caracteres. Nombre asociado con el usuario. por el momento son de utilidad limitada ya que existen aplicaciones que no las soportan. Apuntes de RACF Juan Mautalen . si bien creemos importante mencionar su existencia y entendemos que en el futuro van seguramente a desempeñar un rol relevante.17 Segmento Base USERID NAME DATA DFLTGRP PASSWORD OWNER Segmento de TSO PROC ACCTNUM COMMAND SIZE MAXSIZE Identificador del usuario. de longitud mínima 9 y máxima 100. acaba de anunciar el soporte de Password Phrases para su versión 4. dada su mayor longitud. con una longitud máxima de 255 caracteres. También debemos señalar que. Por esta razón. debe también obligatoriamente contar con una password tradicional (que podría ser desconocida por el usuario. de ser necesario. para que se vea obligado a autenticarse usando su Password Phrase). La password inicial es una clave expirada. si se trata de una persona física. quien puede cambiarlos. por ejemplo. algunas de uso muy difundido. PROGRAM Shell asignado. Información sobre el usuario.2. Con respecto al identificador del usuario. En la DATA. que son cadenas de caracteres alfanuméricos y especiales (incluyendo blancos). HOME Home directory del usuario. En el caso de usuarios asociados a procesos. se pone usualmente su nombre y apellido. Más adelante se verán en detalle los posibles valores y su significado. Si no se especifica el operando WHEN. un job del usuario puede iniciarse y ejecutarse fuera de los días y horarios permitidos). Estas restricciones no se aplican para la ejecución de trabajos batch (o sea. Por lo tanto. de modo a evitar que asuma el valor por defecto. UACC indica el acceso universal del usuario para su grupo default. Si no se codifica PASSWORD.18 El segmento de OMVS solo debe definirse para usuarios que lo necesiten. El parámetro WHEN especifica los días de la semana y las horas del día en los cuales el usuario está autorizado a ingresar al sistema. la posibilidad de configurar RACF de forma que este segmento se le agregue automáticamente a los usuarios la primera vez que invoquen algún servicio Unix que lo requiera. ADSP y CLAUTH no se otorgan. salvo que se los codifique explícitamente. en tal caso. del cual hablaremos en más adelante. Si no se especifica DFLTGRP. asume por defecto como password inicial el grupo especificado en el operando DFLTGRP. Existe incluso. el valor por defecto es ANYDAY/ANYTIME. el usuario adquiere el atributo PROTECTED. El valor por defecto es USE. y el usuario tiene también NOOIDCARD (que es el defecto). Este chequeo se realiza únicamente en el momento en que RACF procesa el pedido de logon. no será forzado a salir del sistema (naturalmente. ya que los nombres de los grupos suelen ser públicos. Por lo tanto. Si se especifica NOPASSWORD. Esto no es para nada recomendable desde el punto de vista de la seguridad. lo cual autoriza al usuario a ingresar en cualquier día y horario. ya no podrá reingresar). este campo aparece como UNKNOWN cuando se lista el usuario a través del comando LISTUSER. al analizar un ejemplo del comando LISTUSER.8 . En tal caso. se verán en detalle los posibles valores y su significado. Por ejemplo. el valor que asume por defecto es el “actual grupo de conexión” del usuario que ejecuta el comando. a partir del z/OS 1. debería codificarse el operando WHEN del siguiente modo: WHEN(DAYS(monday wednesday friday) TIME(0800:1930)) Apuntes de RACF Juan Mautalen . miércoles y viernes de 8 a 19:30 horas. pero su sesión se extendió más allá de los límites permitidos. es aconsejable siempre especificar una password. 3. si el usuario ingresó en un día y horario válidos.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(días) TIME(hora-inicio:hora-fin))] [TSO(PROC(nombre-del-procedimiento-de-TSO) ACCTNUM(código-de-cuenta))] [OMVS(UID(valor) PROGRAM(nombre-del-programa) HOME(directorio-inicial))] El userid es requerido y debe estar inmediatamente a continuación del comando ADDUSER. Si no se especifica DATA. Mas adelante. OPERATIONS.11. AUDITOR. Si se omite OWNER. Los atributos SPECIAL. AUTHORITY indica el nivel de autoridad que tendrá el usuario como miembro de su grupo default. si cierra la sesión. RESTRICTED. Si no se codifica NAME. este campo queda vacío y al listar el usuario se muestra la leyenda “NOINSTALLATION_DATA”. el valor por defecto es el usuario que ejecuta el comando. GRPACC. El valor por defecto es NONE. podría establecerse que el usuario solo esté habilitado para ingresar al sistema lunes. El usuario. solo es necesario incluir los operandos que corresponden a los campos que se quiere modificar . quien ejecuta el comando tiene que cumplir alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema.No se aplica ningún valor por defecto en este caso. el cual indica que el usuario está obligado a cambiar su password por una nueva en el momento de su próximo logon. . Por ello. si así lo desea y la aplicación lo permite).Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de acción al grupo default especificado en el comando ADDUSER. solo se indicaron los suboperandos más frecuentes. Autoridad requerida Para definir un nuevo usuario. Toda password dada con NOEXPIRED debe adecuarse a las reglas fijadas en la SETROPTS. quien ejecuta el comando debe cumplir con alguna de las condiciones siguientes: Tener el atributo SPECIAL a nivel de sistema. Si no se especifica TSO u OMVS. EXPIRED|NOEXPIRED solo surte efecto si ha sido codificado el operando PASSWORD. . Para poder definir al usuario con algún segmento no base (por ejemplo. de todos modos. Debe. al cual debe encontrarse conectado previamente.19 Para los operandos TSO y OMVS. Tener CLAUTH en la clase USER y verificar además alguno de los siguientes requisitos: . Apuntes de RACF Juan Mautalen . segmentos de TSO u OMVS). no es necesario que la password otorgada cumpla con las reglas fijadas por la organización. El valor por defecto es EXPIRED.9 . que se encuentran especificadas en la SETROPTS.Estar conectado con nivel de autoridad JOIN al grupo default especificado en el comando ADDUSER.Modificación 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(días) TIME(hora-inicio:hora-fin))] [TSO(PROC(nombre-del-proc)|NOPROC ACCTNUM(código)|NOACCTNUM))|NOTSO] [OMVS([UID(valor)|NOUID] [PROGRAM(nombre-del-programa)|NOPROGRAM] [HOME(directorio-inicial)|NOHOME])|NOOMVS] Naturalmente. De todos modos. ello no significa que su password nunca venza. 3. tener una longitud máxima de 8 caracteres. Tener autoridad a través de perfiles apropiados en la clase FIELDS. a menos que se le haya dado NOINTERVAL a través del comando PASSWORD. se encuentra sujeto a la política usual de cambio periódico de password establecida por la organización. DFLTGRP indica el nombre del nuevo grupo default del usuario. en este caso. el usuario simplemente queda definido sin tal segmento.Ser el owner del grupo default especificado en el comando ADDUSER. existiendo varios otros. NOEXPIRED indica que el usuario no estará forzado a cambiar su password en el momento de su próximo logon (aunque naturalmente puede hacerlo. Observemos que el usuario continúa conectado a su antiguo grupo default. El año debe ser siempre de 2 dígitos. ALU fin7632 REVOKE(1/1/10) RESUME(31/1/10) Con respecto al formato de la fecha. Autoridad requerida El nivel de autoridad requerido depende del campo del perfil de usuario que se pretenda modificar. Si se codifica REVOKE sin especificar fecha. La lista no pretende de ningún modo ser exhaustiva. Los ceros a la izquierda. el grupo default no es alterado. se considera que tiene un REVOKE pendiente. REVOKE(mm/dd/aa) especifica una fecha futura a partir de la cual el usuario no podrá acceder al sistema. Es posible y frecuente que un comando de RACF solo resulte exitoso parcialmente. RESUME(mm/dd/aa) especifica una fecha futura a partir de la cual el usuario podrá acceder al sistema nuevamente. En el caso en que el usuario no tenga un REVOKE pendiente. En este caso. habilita al usuario a ingresar al sistema de inmediato) y le saca el atributo REVOKED. Mientras el usuario tenga una fecha de revocación futura. Apuntes de RACF Juan Mautalen . el usuario adquiere el atributo REVOKED (más adelante veremos en detalle todos los atributos de usuario). se considera que tiene un RESUME pendiente. No existe la opción de modificar el identificador de un usuario. pero se codifica AUTHORITY o UACC. el RESUME toma efecto inmediatamente (o sea. el RESUME(mm/dd/aa) es ignorado. dentro de lo posible. Esto no evita que el resto del comando se procese. si el usuario la tuviera. Si la ejecución es en batch. Si se omite GROUP. por fecha inválida). la fecha especificada en RESUME debe ser posterior a la fecha del REVOKE). Si se especifican ambos operandos REVOKE(mm/dd/aa) y RESUME(mm/dd/aa). el siguiente comando inhabilita al usuario fin7632 a usar el sistema desde el 1/1/2010 hasta el 31/1/2010. si el usuario la tuviera. 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: Sólo puede cambiarse el grupo default de un usuario por otro grupo al cual se encuentre previamente conectado. y envía al usuario que ejecuta el comando un mensaje para que especifique una fecha futura (esto último. el REVOKE toma efecto la próxima vez que el usuario ingrese al sistema. conviene establecer desde el comienzo una buena nomenclatura de usuarios. Al no ser una tarea sencilla. simplemente se ignora el operando. de modo que el nuevo usuario resulte un clon del anterior. así como también de todas las autorizaciones que tiene. o no tenga el atributo REVOKED. Mientras el usuario tenga una fecha de resume futura. suponiendo que el comando se ejecuta en foreground. ya que antes de borrar el usuario viejo. Si el grupo especificado en DFLTGRP no es un grupo al cual esté conectado. tener que rebautizar en el futuro. Mencionamos a continuación algunos casos. debe tomarse debida nota de los grupos a los que se encuentra conectado. Si se codifica RESUME sin especificar fecha. que consideramos los más relevantes. NORESUME tiene como efecto quitar la fecha de resume futura. RACF informa que la fecha no es válida. Esto es trabajoso. pueden ser omitidos (1/1/03 equivale a 01/01/03). se utiliza este operando para anular el efecto del REVOKE.20 GROUP indica el nombre de un grupo al cual el usuario se encuentra previamente conectado y sobre el cual actuarán los nuevos valores especificados en los operandos AUTHORITY y UACC. Si la fecha ingresada no es posterior a la fecha actual. NOREVOKE tiene como efecto quitar la fecha de revocación futura. Por ejemplo. actúan sobre viejo). si lo tuviera. de modo a evitar. las fechas no deben entrar en conflicto (básicamente. el mismo debe ser mes/día/año. La única forma prevista por RACF para renombrar un usuario consiste en deletearlo y darlo de alta nuevamente con el nuevo identificador. para mes y día. Usualmente. los mismos actúan sobre del grupo default del usuario (aún en el caso en que se haya especificado DFLTGRP para cambiar el grupo default del usuario. OPERATIONS y UAUDIT/NOUAUDIT. AUDITOR y OPERATIONS a nivel de sistema se requiere el atributo SPECIAL a nivel de sistema. tener que manipular archivos “no protegidos”. es apropiado identificarlas y borrarlas. no es una buena práctica dejar en la base referencias a usuarios inexistentes. OPERATIONS y UAUDIT/NOUAUDIT. Para otorgar CLAUTH sobre una clase debe además tener él mismo CLAUTH sobre ella. si decide cambiar su grupo default. AUDITOR. Para agregar. con excepción de SPECIAL. no solo deletea el perfil del usuario. cuando tratemos específicamente la protección de datasets. también deben renombrarse (o deletearse. Para poder otorgar los atributos SPECIAL. Los mismos deben borrarse previamente. con excepción de UAUDIT/NOUAUDIT. así como también para preservar su nivel de protección. es muy posible que pueda seguir haciéndolo normalmente hasta que cierre su sesión. así como también elimina las conexiones que el usuario pueda tener a distintos grupos. con excepción de SPECIAL. Si el usuario a eliminar se encuentra trabajando dentro del sistema en el momento en que se ejecuta el comando de baja. o bien a nivel de un grupo que tenga al usuario dentro de su campo de acción. ya no podrá ingresar nuevamente. Apuntes de RACF Juan Mautalen .RESET de la clase FACILITY puede otorgar una nueva password para cualquier usuario (ver 7. Por lo tanto.PASSWORD. Si el owner del usuario está dentro del campo de acción de un grupo en el cual el usuario tiene el atributo SPECIAL. AUDITOR. entonces puede especificar cualquier operando.Eliminación de un usuario Sintaxis: DELUSER|DU userid Este comando borra de la base de RACF el perfil del usuario. Es habitual. Por ejemplo. Por lo tanto. del mismo modo que en el caso de la eliminación de grupos. 3. si alguno de ellos tuviera un perfil discreto. para evitar. Esto quedará claro en el capítulo siguiente.5). Consideraciones: No es posible borrar un usuario si existen en la base perfiles de dataset cuyo HLQ sea igual al identificador del usuario. Si tiene autorización sobre el recurso IRR. el comando DELUSER no elimina al usuario de otros perfiles de la base dónde pueda figurar. Sin embargo. que un comando de RACF impacte sobre más de un perfil de la base. ya que en caso contrario el comando DELUSER falla. es necesario tener el atributo AUDITOR a nivel de sistema. En concordancia con lo anterior. por un lado. Naturalmente. si no fuese necesario conservarlos) los datasets cuyo HLQ coincida con el identificador del usuario.21 El atributo SPECIAL a nivel de sistema permite especificar cualquier operando. se requiere el atributo SPECIAL a nivel de sistema o bien tener suficiente autoridad en perfiles apropiados de la clase FIELDS. como se ve en este ejemplo. se puede solicitar a los operadores del equipo que cancelen todas las sesiones que pueda tener activas. Para especificar UAUDIT/NOUAUDIT. modificar o deletear información de “segmentos no base” del usuario. Obviamente. una vez que salga del sistema. Si es el owner del usuario. el usuario puede estar en listas de acceso. Si bien la existencia de tales referencias no impide la ejecución exitosa del comando DELUSER. Todo usuario puede cambiar su NAME y DFLTGRP. sino que también modifica los perfiles de los grupos a los cuales se encuentra conectado. entonces básicamente puede especificar cualquier operando.10 . debe encontrarse previamente conectado al nuevo grupo que especifique. Esto hay que hacerlo antes de borrar los perfiles de dataset. o puede ser owner de algún otro perfil de la base. Si resultara imprescindible que cese de inmediato toda actividad. resulta útil. Estar conectado a su grupo default con nivel de autoridad JOIN no es suficiente para poder deletear el usuario.11 . quien ejecuta el comando debe cumplir con alguna de las condiciones siguientes: Tener el atributo SPECIAL a nivel de sistema. hasta que al cabo de una semana. Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de acción al usuario que se pretende eliminar.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 . revocarle su acceso al sistema ejecutando el comando: ALTUSER userid REVOKE De este modo.22 Como dar de baja a un usuario de manera adecuada puede llevar algo de tiempo. Si no se especifican especialmente. el usuario queda imposibilitado de ingresar al sistema (si ya está adentro. Autoridad requerida Para poder deletear un usuario.309/09:48:25 CONNECT ATTRIBUTES= NONE REVOKE DATE= NONE RESUME DATE= NONE GROUP= COBROS AUTH= USE CONNECT-OWNER= FINADM CONNECT-DATE= 10. pero no nos ocuparemos de ellos en esta guía). Si se especifica el operando TSO u OMVS. los segmentos no base no son listados (existen varios más que los dos mencionados. en algunas organizaciones. Incluso. se ejecuta un proceso que los borra efectivamente. Ejemplo: LU fin7632 TSO OMVS La salida tendría el siguiente aspecto: USER= FIN7632 NAME= PEREZ ALEJANDRA OWNER= FINADM CREATED= 10. se lista también tal segmento.308 PASS-INTERVAL= 30 PHRASEDATE=N/A ATTRIBUTES= NONE REVOKE DATE= NONE RESUME DATE= NONE LAST-ACCESS= 10. Ser el owner del usuario. corresponden las mismas consideraciones que en el punto anterior) durante el tiempo que insuman los pasos previos a la baja.158 CONNECTS= 857 UACC= NONE LAST-CONNECT= 10.158 DEFAULT-GROUP= FINANZAS PASSDATE= 10. Únicamente lista información relativa al usuario. se va revocando diariamente a los usuarios a ser dados de baja.Listado de un usuario Sintaxis: LISTUSER|LU userid [TSO] [OMVS] Este comando no efectúa ninguna modificación sobre la base de RACF. por ejemplo. 3.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. como medida inicial. contados a partir del día en que se cambió por última vez. el usuario fue dado de alta el 7 de junio del año 2010 (día 158 del año 10). la cantidad de días pasados los cuáles el usuario es forzado a cambiar su password surge del mínimo entre el valor del PASS-INTERVAL del usuario y el valor global seteado en la SETROPTS. Es útil. El campo LAST-ACCESS indica fecha y hora en que el usuario ingresó al sistema por última vez. por ejemplo). al cual nos referiremos más adelante. El valor debe estar comprendido entre 1 y 254.000 significa que el usuario tiene una password expirada. El valor 00.Si al usuario se le da un RESUME. En ningún lugar de la base de RACF está guardada la información sobre quién dio el alta (este dato debería rastrearse en los registros tipo 80 del SMF. tendrá que cambiar su password obligatoriamente cada 30 días. pero el valor de la SETROPTS es 30. entonces el usuario tiene el atributo PROTECTED. Por ejemplo. sin embargo. El campo CREATED indica la fecha de creación del usuario. En caso de ser un usuario. con ciertas salvedades: . ATTRIBUTES= NONE muestra que el usuario no posee ningún atributo particular a nivel de sistema. Examinaremos posteriormente en detalle los posibles atributos que se le pueden otorgar a un usuario. para usuarios que no corresponden a personas físicas (siempre y cuando se pueda tener certeza de que nadie conoce su password). si el usuario tiene PASS-INTERVAL=45 en su perfil. si así lo desea. entre la que destacamos la siguiente: El grupo default es el grupo FINANZAS. De todos modos. o bien mediante los paneles de logon de ciertas aplicaciones (TSO o CICS. El OWNER es FINADM. PASS-INTERVAL establece la cantidad de días que la password de este usuario permanecerá válida. se obtiene gran cantidad de información sobre el usuario FIN7632. los valores del campo LAST-ACCESS son actualizados con la fecha y hora en que se ejecutó el comando. dónde se loguea información sobre los comandos de RACF ejecutados). En el ejemplo expuesto. PASSDATE indica la fecha en la que el usuario cambió su password por última vez.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. en formato juliano. Apuntes de RACF Juan Mautalen . esta es una opción poco recomendable. que en principio podría ser un grupo o un usuario. Todo usuario puede cambiar su password en cualquier momento. Desde el punto de vista de seguridad. Esto indica que aún no ha ingresado desde que el administrador se la otorgó. PASS-INTERVAL=N/A indica que el usuario tiene una password que nunca vence. esto no significa que sea FINADM quién ejecutó el comando de alta. ya sea a través del comando PASSWORD. Si ambos campos PASSDATE y PASS-INTERVAL tienen el valor N/A. y se cumpla que: . en el capítulo dedicado a la SETROPTS). como mínimo. Obtener acceso a un recurso protegido gracias d pertenecer a un cierto grupo no incrementa el valor del campo CONNECTS para ese grupo. CONNECT y JOIN (enumerados en orden jerárquico. Apuntes de RACF Juan Mautalen . CONTROL o ALTER. Es importante tener en cuenta estos detalles. . la información mostrada tiene idénticos campos. en el ejemplo mostrado. Este se muestra en el campo AUTH. UPDATE. El primer grupo listado es siempre el grupo default del usuario (recordemos que todo usuario está conectado. siendo NONE el valor por defecto. no suele especificarse un grupo distinto del default en la pantalla de logon. Solo se incrementa el contador cuando el usuario se loguea a una aplicación especificando al grupo como “grupo de conexión”. .Si se cambia la password del usuario. el campo LAST-ACCESS muestra el valor UNKNOWN. El valor por defecto es USE. suficiente para la casi totalidad de los casos. CONNECT-DATE muestra la fecha en que el usuario fue conectado al grupo.Si el usuario nunca ingresó. de nombre FINANZAS. LOGON ALLOWED (anyday anytime) significa que el usuario no tiene ninguna restricción de día y horario para ingresar al sistema. que describimos a continuación: Un usuario es conectado a un grupo con un determinado nivel de autoridad.El usuario no codifica explícitamente el operando UACC en la definición del perfil. la clase de RACF correspondiente no debe tener DFTUACC especificado en la CDT (Class Descriptor Table). Más adelante discutiremos en detalle los alcances de cada uno de estos niveles. mientras que la cuenta para el otro grupo al que está conectado. El campo UACC en la conexión de un usuario a un grupo puede tomar los valores NONE. determina el UACC de los perfiles de dataset o de recursos generales que el usuario eventualmente defina en la base de RACF. 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. A continuación. mostrando varios parámetros que caracterizan cada conexión. que el usuario no esté haciendo uso de su conexión al grupo COBROS. los valores del campo LAST-ACCESS son igualmente actualizados con la fecha y hora de iniciación del job. Como actualmente es muy habitual que la opción GRPLIST esté activa en la SETROPTS (esto se analizará en detalle más adelante. permanece en 00. ya sea con el comando ALTUSER o PASSWORD. a su grupo default). En virtud de ello. CREATE. o sea que cada uno incluye los privilegios del anterior). Este parámetro. READ. figuran todos los grupos a los cuales el usuario está conectado. . pero que actualmente es totalmente irrelevante desde el punto de vista de seguridad. especificar un grupo en la pantalla de logon). y sus posibles valores son: USE. por ejemplo. que se especifica a nivel de grupo. para no interpretar erróneamente la información brindada por el campo LAST-ACCESS. siempre y cuando haya iniciado la sesión especificando este grupo como “grupo de conexión”. quedando el mismo en 00 para los otros grupos. los valores del campo LAST-ACCESS son actualizados con la fecha y hora en que se ejecutó el comando. Esto no significa. El valor que asume por defecto es el usuario que conectó el usuario al grupo. en la salida del comando LU. pues de otro modo el perfil toma por defecto ese valor. de ninguna manera.24 .Si un job se ejecuta bajo la identidad del usuario. En caso contrario. Para cada uno de los grupos.Para perfiles de recursos generales. CONNECT-OWNER es un campo que se mantiene por razones de compatibilidad con versiones anteriores de RACF. es frecuente que solo se incremente la cuenta del campo CONNECTS para el grupo default del usuario. este valor prevalece. llamado COBROS. Así. el usuario FIN7632 se conectó 857 veces usando su grupo default. debe cumplir con alguna de las condiciones siguientes: Ser el owner del usuario. Tener acceso READ sobre el recurso IRR. los perfiles de RACF que definan tendrán por defecto UACC(NONE). es frecuente que los valores de los campos LASTACCESS y LAST-CONNECT para el grupo default coincidan. el perfil quedará definido con UACC(READ). Básicamente. Si necesitaran crear un perfil con un UACC distinto de NONE. entonces si define un perfil de dataset y no especifica UACC.5). De este modo.LISTUSER de la clase FACILITY (ver 7. De todos modos. los 3 campos deben mostrar NONE SPECIFIED para todos los usuarios de la base de RACF. Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de acción al usuario a listar. CONNECT-ATTRIBUTES muestra los atributos del usuario relativos a su conexión al grupo. Para los usuarios administradores. de modo que su grupo de conexión sea efectivamente su grupo default). el grupo de conexión resulta ser su grupo default. de modo similar a como lo hacen a nivel global. Tener el atributo AUDITOR a nivel de un grupo que tenga dentro de su campo de acción al usuario a listar. es muy frecuente que el campo LAST-CONNECT solo esté actualizado para el grupo default del usuario (tal como sucede con el campo CONNECTS). conviene de todos modos conservar el valor default UACC=NONE en la conexión a cada uno de sus grupos. y atributos a nivel de grupo. que figuran en el campo ATTRIBUTES. 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 conexión". Autoridad requerida Todo usuario puede listar el segmento base de su propio perfil. (y se loguea a TSO sin cambiar el grupo en el panel de logon. realmente poco utilizado. a nivel de grupo. Recordemos que si el usuario no especifica grupo en la pantalla de logon (TSO. Si la organización no usa esta seguridad adicional.25 Por ejemplo.). no tienen más que codificar dicho operando con el valor deseado en el comando de definición del perfil. REVOKE DATE y RESUME DATE funcionan. CATEGORY-AUTHORIZATION y SECURITY-LABEL son campos relacionados con un nivel extra de seguridad que provee RACF. CICS. que deben definir nuevos perfiles en la base de RACF. que veremos cuándo analicemos las conexiones de usuarios a grupos. Los usuarios se dividen en atributos a nivel de sistema. 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). El campo LAST-CONNECT suele ser un indicador más fiable respecto del día y hora del último ingreso del usuario al sistema ya que. Tener el atributo SPECIAL a nivel de sistema. Si el usuario nunca inició una sesión con determinado grupo. La enorme mayoría de los usuarios no define perfiles en la base de RACF. se establecen a través del comando CONNECT. Más adelante los analizaremos en detalle. Por lo tanto. Para listar el segmento base del perfil de otro. Sin embargo. a diferencia del campo LAST-ACCESS. SECURITY-LEVEL. fue implementado por IBM para que RACF cumpla con los requisitos que establece el gobierno de los EEUU para obtener la calificación B1 en materia de seguridad. Tener el atributo AUDITOR a nivel de sistema. si un usuario tiene UACC(READ) especificado en su conexión a su grupo default. a nivel grupal. por lo cual el UACC de la conexión no tiene mayor relevancia. el LAST-CONNECT para este grupo muestra el valor UNKNOWN. lo cual es conveniente desde el punto de vista de seguridad. etc. Apuntes de RACF Juan Mautalen . CICS. El valor debe estar comprendido entre 1 y 254. etc. sin embargo. sin embargo. quien ejecuta el comando debe cumplir con alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema. INTERVAL establece el valor del campo PASS-INTERVAL del usuario especificado en el operando USER (si éste se omitiera. o especificar NOINTERVAL. Tal cual indicáramos anteriormente. ya que lo habitual es que los usuarios cambien su password a través de la pantalla de logon de las aplicaciones (TSO. en cuyo caso el campo PASSINTERVAL muestra el valor N/A. Ser el owner del usuario. quien ejecuta el comando debe cumplir con alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema. salvo que tenga la autoridad suficiente).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. Si. Para ello. Tener el atributo SPECIAL a nivel de un grupo que tenga al usuario dentro de su campo de acción. la password del usuario no se altera. siendo modificado únicamente su intervalo de validez. ya que en tal caso RACF promptea al usuario para que los introduzca por pantalla y no resultan visibles mientras se los tipea. 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). Resulta conveniente ingresar PASSWORD sin especificar los valores de las passwords. USER indica el usuario cuya password se va a modificar. así como también su INTERVAL. Si se codifica INTERVAL sin especificar valor. El operando PASSWORD permite cambiar la clave propia en cualquier momento. Para cambiar el intervalo de validez de la password de otro usuario. Tener el atributo SPECIAL a nivel de un grupo que tenga al usuario dentro de su campo de acción. Tener autoridad a través de perfiles apropiados en la clase FIELDS. Autoridad requerida Todo usuario está autorizado a modificar su propia password y el intervalo de validez de la misma (no puede. usar la opción NOINTERVAL. El comando PASSWORD es realmente poco usado. El operando PASSWORD es ignorado si se ha especificado USER. Es imprescindible.).12 . Para resetear la password de otro usuario al valor de su grupo default. debe satisfacer alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema. para otorgar a un usuario una password que nunca venza. NOINTERVAL establece que la clave del usuario nunca vence. Apuntes de RACF Juan Mautalen . Si se codifica USER y no se establece la opción INTERVAL|NOINTERVAL. por el contrario. el cambio afecta al usuario que ejecuta el comando). debe usarse esta opción solo en contados casos que lo justifiquen. y no se preocupen en modificar su INTERVAL.26 Para poder listar “segmentos no base”. se codifica USER junto con alguna de las opciones INTERVAL|NOINTERVAL. no pudiendo exceder el máximo global fijado en la SETROPTS. 3. no debe especificarse el operando USER. se toma por defecto el máximo global de la SETROPTS. en cuyo caso se llaman atributos relativos a grupos. como a nivel de la conexión del usuario con un grupo. con las siguientes excepciones: . es decir con posterioridad a la creación del usuario. actúan en todo momento. y de PROTECTED). Ejemplos: 1) ALTUSER jefa524 AUDITOR Este comando le da al usuario JEFA524 el atributo AUDITOR a nivel de sistema. y le saca el atributo OPERATIONS a nivel de sistema. 2) ALTUSER jefa524 SPECIAL NOOPERATIONS Este comando le otorga al usuario JEFA524 el atributo SPECIAL a nivel de sistema. o restricciones. Cuando son especificados a nivel de sistema. Luego indicaremos de que manera actúan cuando se los especifica a nivel de grupo. o actúan de manera más acotada. y le saca el atributo REVOKE (si lo tuviera a nivel de sistema). analizaremos los “atributos a nivel de sistema”. Los atributos REVOKE y UAUDIT solo pueden otorgarse con el comando ALTUSER.Atributos de usuario Los atributos son facultades extraordinarias.13 . en cuyo caso de denominan simplemente atributos del usuario. 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. especificando como parámetro no posicional el nombre del atributo (con excepción de CLAUTH. ya sea en el momento de la creación del usuario (comando ADDUSER).El atributo PROTECTED se quita otorgando una password al usuario. Para quitarlos. el atributo SPECIAL otorga un absoluto control sobre la base de Apuntes de RACF Juan Mautalen . que debe ir acompañado del nombre de una clase. En un principio. poniendo como parámetro el nombre del atributo antecedido por el prefijo NO.27 3. Atributo SPECIAL El atributo SPECIAL a nivel de sistema confiere al usuario la autoridad para ejecutar cualquier comando de RACF. dependiendo del atributo. se otorgan. En cambio. o bien solo lo hacen cuando el usuario ingresó especificando ese grupo en la pantalla de logon. o bien con posterioridad (comando ALTUSER). debe ejecutarse el comando ALU. cuando se otorgan a nivel de grupo.El atributo REVOKE se quita especificando el operando RESUME. que se le pueden otorgan a un usuario. se pueden dar tanto a nivel de sistema (system level attributes). si lo tuviera. Como ya mencionáramos anteriormente. . 3) ALTUSER jefa524 CLAUTH(tsoproc) RESUME Este comando le otorga al usuario JEFA524 el atributo CLAUTH en la clase TSOPROC a nivel de sistema. Por lo tanto. para su uso en una situación de emergencia. perfiles de dataset. cuantos menos usuarios con atributo SPECIAL existan. con la siguiente importante excepción: El atributo SPECIAL no permite listar ni modificar opciones relativas a auditoría (que quedan. Normalmente. Por lo tanto. desde el punto de vista de seguridad. un usuario con atributo SPECIAL (y sin atributo AUDITOR) no podrá listar ni modificar: o o o Parámetros SAUDIT. reservadas a los usuarios con atributo AUDITOR). el atributo AUDITOR no confiere autoridad para modificar ningún dato en la base de RACF. como el usuario IBMUSER existe en toda base de RACF.deben tenerlo. definir. luego de verificar que los nuevos administradores pueden trabajar normalmente. LOGOPTIONS. Tampoco otorga acceso a ningún recurso protegido. Sin embargo. Solo un usuario con atributo SPECIAL a nivel de sistema puede dar o quitar este atributo a otro usuario. Es por cierto recomendable. SECLEVELAUDIT. No es sencillo recomendar una cantidad óptima. tiene el atributo SPECIAL. que son el acceso a “datasets no catalogados” y “datasets no protegidos”). Resulta aconsejable que los usuarios con atributo SPECIAL no tengan el atributo AUDITOR. Sólo los usuarios con atributo AUDITOR pueden utilizarlo (salvo que el programa ICHDSM00. RESTRICTED y PROTECTED (no es posible eliminarlo). En una base de RACF recién inicializada. conservar bajo sobre y en lugar seguro un usuario con este atributo. podemos señalar que. razón por la cual mantenerlo inutilizable es lo más aconsejable. El utilitario DSMON brinda importante información para auditar el sistema. El atributo SPECIAL no brinda acceso alguno a los recursos del sistema protegidos por RACF (con 2 excepciones particulares. de modo de no concentrar excesivo poder en una única persona.28 RACF. Fuera de las opciones relativas a auditoría. A continuación. OPERAUDIT. AUDIT CLASSES. debe otorgarse el atributo SPECIAL a los administradores de RACF de la organización. mejor. modificar y deletear cualquier perfil. asimismo. Atributo UAUDIT en perfiles de usuario. Ingresando con este usuario. es un blanco ideal de hackeo. El atributo AUDITOR debe ser otorgado criteriosamente. el usuario IBMUSER. por lo tanto. siempre que ello no comprometa la eficiencia de la administración. quitarle al usuario IBMUSER el atributo SPECIAL y darle los atributos REVOKE. y únicamente a los usuarios que desempeñen tareas globales de auditoría. Atributo AUDITOR Los usuarios con atributo AUDITOR pueden listar la información 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). 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 organización. Más específicamente. modificar las opciones de logging para usuarios. En efecto. APPLAUDIT de la SETROPTS. así como también utilizar el comando SEARCH de búsqueda y el utilitario IRRUT100 (permite buscar y listar las ocurrencias de un usuario o grupo en la base de RACF). provisto por IBM. así como también modificar las opciones de configuración de RACF establecidas en la SETROPTS. Apuntes de RACF Juan Mautalen . Pueden. Debido al enorme poder que confiere el atributo SPECIAL a nivel de sistema. tiene acceso irrestricto a los recursos protegidos del sistema. indirectamente. SECLABELAUDIT. el usuario con atributo SPECIAL tiene la posibilidad de otorgarse a sí mismo el acceso a cualquier perfil de la base con el máximo nivel de autoridad. pudiendo los usuarios que lo tienen. invocado por la herramienta. perfiles de recursos generales y las opciones de auditoría globales establecidas en la SETROPTS. solo un muy reducido conjunto de usuarios -encargados de la administración centralizada de RACF. resulta muy recomendable. deberían sobrar los dedos de las manos para contar la cantidad de usuarios con atributo SPECIAL a nivel de sistema. Sin embargo. en cuyo caso es necesario tener acceso al mismo). Campo GLOBALAUDIT en perfiles de dataset o de recursos generales. se encuentre protegido en la clase PROGRAM. CMDVIOL. el nivel de autoridad del usuario FIN5214 sobre el perfil CUIL. es perfectamente posible (e incluso recomendable) no tener usuarios con atributo OPERATIONS a nivel de sistema. si se pretende una buena separación de funciones en la organización. y que existe en la base un perfil de dataset CUIL.** será UPDATE. VMMDISK. pero figuran en la misma uno o más grupos a los cuales se encuentra conectado (asumimos que la instalación tiene la opción List of Groups Checking Active en la SETROPTS.a todos los perfiles en las clases DATASET. debe controlarse que los usuarios administradores de RACF que tienen el atributo SPECIAL no se otorguen a sí mismos el atributo AUDITOR. En efecto. basta con analizar el logging de los comandos de RACF ejecutados. categories y security labels también pueden limitar el acceso implícito a un perfil dado por el atributo OPERATIONS. Atributo OPERATIONS Este atributo. un usuario con atributo OPERATIONS a nivel de sistema tiene acceso ALTER -el máximo posible. para un usuario con el atributo OPERATIONS. otorga al usuario acceso a gran cantidad de recursos protegidos por RACF. VMRDR (las últimas cinco totalmente irrelevantes para z/OS. Apuntes de RACF Juan Mautalen . PSFMPL. la presencia de su identificador de usuario o de alguno de sus grupos en la lista de acceso de un perfil (de una clase dónde actúe el atributo OPERATIONS) solo sirve para eventualmente reducir su nivel de autoridad. que está conectado únicamente a los grupos FINANZAS y CONTA. Se trata de un atributo que brinda gran poder de acceso. VMNODE. 2) Si el usuario no está en la lista de acceso del perfil.** con la siguiente lista de acceso FINANZAS CONTA COBROS UPDATE READ ALTER En este caso. a diferencia de los anteriores. entonces su nivel de autoridad será el más permisivo dado por sus grupos. lo cual es la configuración habitual hoy en día).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. y en contadísimos casos. razón por la cual debe ser otorgado con suma cautela. 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. a la hora de determinar el nivel de acceso de un usuario sobre un perfil. VMBATCH. existen mecanismos alternativos al atributo OPERATIONS para brindarles acceso a los recursos que requieren sus funciones. VMCMD. Más aún. 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 implícito dado por el atributo OPERATIONS. es decir el más permisivo dado por sus grupos (ya que no figura explícitamente FIN5214 en la lista de acceso). 3) Security levels. En un capítulo posterior analizaremos en detalle el proceso de chequeo de autoridad de un usuario sobre un recurso que lleva a cabo RACF. Ejemplo: Supongamos que el usuario FIN5214 tiene el atributo OPERATIONS a nivel de sistema. Sin embargo. con las siguientes importantes salvedades: 1) Si el usuario figura explícitamente en la lista de acceso del perfil con un nivel de autoridad menor. En cualquier caso. En virtud de las salvedades expuestas concluimos que. Por ejemplo. GDASDVOL. ya que se relacionan con VM). Para ello. con respecto a la observación anterior. ya mencionamos que son opciones poco utilizadas que no analizaremos. que se obtiene de los registros tipo 80 del SMF. para los usuarios de administración de storage. DASDVOL. En efecto. entonces ése será su nivel de acceso. El atributo OPERATIONS a nivel de sistema solo puede ser otorgado o quitado por un usuario con atributo SPECIAL a nivel de sistema. TAPEVOL. se otorga para una (o varias) clases de RACF. o listar perfiles ya existentes (siempre y cuando estas acciones no estén posibilitadas por algún otro tipo de autoridad). CLAUTH resulta. si bien permite definir nuevos perfiles. útil como herramienta de descentralización de ciertas tareas de administración de RACF. sino que también puede ser dado automáticamente por RACF en alguna de las siguientes situaciones: 1) Si en la SETROPTS está especificado que “el usuario será revocado después de N intentos consecutivos y fallidos de password”. así como también la ejecución de trabajos batch. y es bastante utilizado en muchas organizaciones. poseer el atributo CLAUTH para una determinada clase autoriza al usuario a definir nuevos perfiles en ella (y el cualquier otra con idéntico POSIT number). merecen una consideración particular los usuarios con atributo SPECIAL a nivel de sistema. y además estar autorizado a modificar el perfil del usuario (por ejemplo. siendo su owner). Tener CLAUTH sobre esa clase. Las clases para las cuáles es válido son la clase USER o cualquier otra clase definida en la CDT (GROUP y DATASET quedan pues excluidas). Para estar autorizado a otorgarlo sobre una determinada clase. sino que emite un mensaje por consola solicitando al operador. que veremos en el capítulo correspondiente. no solo puede ser otorgado por un usuario con la suficiente autoridad (atributo SPECIAL u owner del usuario). entonces al (N+1) intento consecutivo de password inválida el usuario es revocado. puede limitar la posibilidad de crear perfiles en una clase dada por el atributo CLAUTH. Atributo REVOKE El atributo REVOKE a nivel de sistema impide al usuario el logon a cualquier aplicación (TSO. teniendo en cuenta las siguientes salvedades: 1) La opción GENERICOWNER de la SETROPTS. Únicamente las Started Task pueden arrancar con un usuario revocado. borrar. En efecto. y transcurrieron al menos (N+1) días desde su último ingreso al sistema. dependiendo de lo que hagan. CICS. IMS. se debe ser el owner del grupo default del usuario a definir. En efecto. aunque se haya excedido el tiempo de inactividad estipulado. el usuario será revocado por RACF en el momento del intento de logon. En cambio.30 otorgar el atributo OPERATIONS no suele ser más que una solución fácil (que se paga a expensas de la seguridad) para evitar identificar exactamente los recursos a los que precisa acceder el usuario. de todos modos. o bien estar conectado al mismo con nivel de autoridad JOIN. Con respecto a las situaciones recién descriptas. El atributo REVOKE. Básicamente. El atributo CLAUTH sobre una clase brinda una bastante limitada capacidad de administración sobre sus perfiles. RACF no los revoca automáticamente. ya que RACF lo otorga al procesar la solicitud de logon. Naturalmente. debe cumplirse alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema. Cabe aclarar que.). no permite modificar. a diferencia de los anteriores. 2) Si en la SETROPTS está especificado que “el usuario será automáticamente revocado después de N días de inactividad”. Atributo CLAUTH Este atributo. queda por defecto como dueño del perfil y por lo tanto con poder de administración casi total sobre el mismo. o bien que confirme la revocación. un ingreso válido vuelve la cuenta a 0. Adicionalmente. si especifica un owner distinto de su usuario. 2) Tener únicamente CLAUTH en la clase USER no autoriza a dar de alta un nuevo usuario en la base de RACF. aunque es posible que experimenten inconvenientes posteriores. o bien que otorgue Apuntes de RACF Juan Mautalen . ya no podrá actuar sobre él una vez creado. etc. que significa Class Authority. hasta tanto el usuario no intente loguearse al sistema no adquirirá el atributo REVOKE. y solo es aplicable a nivel de sistema. Si el usuario con el atributo CLAUTH define un nuevo perfil sin especificar owner. Para otorgar o quitar el atributo ADSP es necesario. cada vez que cree un dataset permanente en disco (o en cartucho. Existe la opción NOADSP a nivel de la SETROPTS que inhibe el eventual atributo ADSP que puedan tener los usuarios. Sin este tratamiento diferenciado. NETVIEW. de modo de no provocar una interrupción en las tareas operativas. Por ejemplo. Se trata de un atributo de carácter limitativo. o bien ser el owner del perfil del usuario. o bien ser el owner del perfil del usuario. automáticamente se agregará en la lista de acceso al grupo A con autoridad UPDATE. o bien ser el owner de su perfil. Atributo PROTECTED Un usuario con atributo PROTECTED (protegido) no puede loguearse a ninguna aplicación del sistema que requiera el uso de una password. o alguno de los grupos a los que está conectado. ni por el UACC del perfil protector. y para otorgarlo o quitarlo es necesario tener el atributo SPECIAL. el atributo ADSP ha caído francamente en desuso. RACF automáticamente le definirá un perfil discreto de dataset. Atributo RESTRICTED Este atributo es solo aplicable a nivel de sistema. Si un usuario tiene este atributo a nivel de sistema. En efecto. Sin embargo. según sea el caso. Antes de otorgarlo. un usuario con atributo RESTRICTED solo puede acceder a aquellos recursos para los cuales se encuentre explícitamente autorizado. El atributo RESTRICTED es útil en situaciones dónde se requiere tener un absoluto control de los recursos a los que debe acceder el usuario. pues son más sencillos de administrar y presentan varias ventajas sobre los discretos. o bien tener el atributo SPECIAL. Se trata de usuarios sin password que resultan inmunes a la revocación automática por ingresos consecutivos de passwords erróneas. un usuario con el atributo RESTRICTED no puede obtener acceso a un recurso protegido por RACF ni por una regla en la clase GLOBAL. ya sea porque su identificador de usuario. Dicho de otro modo. Para setear ADSP|NOADSP a nivel de la SETROPTS es necesario tener el atributo SPECIAL a nivel de sistema. es vital realizar un detallado relevamiento de todos los recursos a los que necesita acceder y con qué nivel de autoridad. CICS. sería perfectamente posible que una persona revocara intencionalmente (mediante ingresos consecutivos de passwords incorrectas) a todos los usuarios con atributo SPECIAL de la organización.31 un intento adicional de ingreso de password u omita la inactividad. o bien tener el atributo SPECIAL. Apuntes de RACF Juan Mautalen . no puede iniciar sesiones de TSO. Atributo ADSP ADSP significa Automatic Data Set Protection. ni por la presencia de “*” en las listas de acceso. que restringe casi completamente los recursos a los cuáles puede acceder el usuario. Siendo la tendencia actual la de utilizar solo perfiles de dataset genéricos. Para otorgar o quitar el atributo RESTRICTED a un usuario. RACF directamente rechaza el pedido de logon sin considerarlo ni siquiera un intento fallido por password inválida. Si alguien intenta loguearse con un usuario que tenga el atributo PROTECTED. generando una situación delicada de la cual no es sencillo recuperarse. si la clase TAPEVOL está activa y la opción TAPEDSN está especificada en la SETROPTS). sí están sujetos a la eventual revocación automática por inactividad. figura en las listas de acceso del perfil con el nivel de autoridad requerido. etc. Se trata de un atributo poco utilizado. 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). es necesario. resulte el acceso fallido o exitoso (independientemente de la configuración de auditoría que tenga el perfil protector del recurso). se debe tener el atributo AUDITOR a nivel de sistema. con los consiguientes problemas de tipo operativo que ello acarrea. El atributo SPECIAL. basta con darle al usuario una password. el atributo PROTECTED asegura no solo que no se puedan utilizar para ingresar a ninguna aplicación. no permite listar -y mucho menos dar o quitar. Intente acceder a un recurso protegido. Para poder otorgar o quitar el atributo UAUDIT. 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 . los campos PASSDATE y PASS-INTERVAL de la salida del comando LISTUSER muestran el valor N/A. Se otorga a un usuario el atributo PROTECTED. por ejemplo). por ejemplo. especificando el operando NOPASSWORD. Defina algún nuevo recurso cuya creación esté controlada por RACF (la alocación de un nuevo dataset. se debe cumplir alguna de las siguientes condiciones: Tener el atributo SPECIAL a nivel de sistema. que nunca se registran dada su baja criticidad). ya sea en el momento de su creación (comando ADDUSER) o con posterioridad (comando ALTUSER). incluso a nivel de sistema. Para estos usuarios.este atributo. sino que también elimina la posibilidad de que se los revoque (voluntaria o involuntariamente) por ingresos consecutivos de passwords inválidas. y por un período limitado de tiempo. ejecutando el comando: ALTUSER userid PASSWORD(password) Para otorgar el atributo PROTECTED. Atributo UAUDIT El atributo UAUDIT (User Audit) indica que RACF grabe registros tipo 80 del SMF toda vez que el usuario efectúe alguna de las siguientes acciones: Ejecute un comando de RACF (con excepción de los comandos LISTUSER. LISTDSD. Para quitar el atributo PROTECTED. Tener el atributo SPECIAL a nivel de un grupo que tenga al usuario dentro de su campo de acción. RLIST y SEARCH. Ser el owner del usuario. No se debe abusar del atributo UAUDIT ya que puede provocar un aumento muy considerable de la cantidad de registros SMF grabados por RACF. o bien a nivel de un grupo que tenga al usuario dentro de su campo de acción. Los usuarios de las regiones CICS. excepto en el caso en que el acceso haya sido autorizado por una regla en la clase GLOBAL. se trata de un atributo muy útil para aquellos usuarios asociados con started tasks que no necesiten loguearse a ninguna aplicación. Es conveniente otorgarlo solo cuando se requiera un monitoreo estricto de la actividad de un determinado usuario. LISTGROUP. son excelentes candidatos para este atributo.32 Básicamente. Ejemplo: ALTUSER userid NOPASSWORD Cuando un usuario tiene este atributo. En tal caso. la flecha significa “tiene como subgrupo a”. sería irrelevante). Ejemplo: GRUPO1 Owner: GRUPOA GRUPO2 Owner: GRUPO1 GRUPO3 Owner: GRUPO1 GRUPO4 Owner: GRUPO2 GRUPO5 Owner: GRUPO3 GRUPO6 Owner: USU1 En el diagrama anterior. Si el usuario FINA857 ya se encontrara conectado al grupo FINANZAS. Campo de acción de un grupo El campo de acción de un grupo está compuesto por una serie de grupos. o GRUPO2 tiene un único subgrupo: GRUPO4.33 Se otorgan a través de comando CONNECT. Si el owner de un grupo dentro de la rama del inicial es un usuario (en lugar de su grupo superior). GRUPO4 y GRUPO5. o GRUPO3 tiene 2 subgrupos: GRUPO5 y GRUPO6. el cual ya ha sido mencionado repetidas veces pero aún no explicado. GRUPO5 y GRUPO6 no tienen subgrupos. solo modifica la conexión agregando el atributo AUDITOR. Por lo tanto. se tiene que: o GRUPO1 tiene 2 subgrupos: GRUPO2 y GRUPO3. Los grupos que forman parte del campo de acción del GRUPO1 son: GRUPO1. perfiles de usuario. de acuerdo al siguiente criterio: Aparte del grupo en cuestión. o GRUPO4. que se verá en detalle más adelante. GRUPO2. siempre y cuándo se cumpla que el owner de un grupo sea su grupo superior. 2) CO fina857 GROUP(finanzas) SPECIAL RESUME La presencia del parámetro RESUME hace presuponer que el usuario FINA857 ya se encuentra conectado al grupo FINANZAS (si no fuese el caso. se encuentran dentro de su campo de acción todos sus subgrupos. este grupo (y todos los que se desprendan de él en el árbol) queda fuera del campo de acción. perfiles de dataset y perfiles de recursos generales. Es decir. el comando modifica la conexión. eliminando el atributo REVOKE a nivel de grupo (si lo tuviere) y otorgando al usuario FINA857 el atributo SPECIAL a nivel del grupo FINANZAS. si se cumple que cada grupo tenga como owner su grupo superior. los subgrupos de sus subgrupos. Apuntes de RACF Juan Mautalen . Para comprender cómo funcionan los atributos a nivel de grupo. es fundamental explicar el concepto de “campo de acción de un grupo” (scope of the group). los grupos dentro del campo de acción de un grupo son exactamente todos aquellos que pertenecen a su rama en el árbol de grupos. y así sucesivamente. Ejemplos: 1) CO fina857 GROUP(finanzas) AUDITOR Este comando conecta al usuario FINA857 al grupo FINANZAS con atributo AUDITOR a nivel de grupo. GRUPO3. Limitaciones: o Un usuario con atributo SPECIAL a nivel de grupo no puede modificar opciones que afecten globalmente al sistema. Atributo SPECIAL a nivel de grupo Básicamente. para grupos que se encuentren dentro del campo de acción). La eventual pertenencia de un usuario a un grupo dentro del campo de acción no implica que el usuario se encuentre dentro del campo de acción. En cuanto a la definición de nuevos perfiles. volviendo al caso del diagrama. un usuario con atributo SPECIAL a nivel de un grupo tiene total autoridad para administrar los recursos que están dentro de su campo de acción. mientras que aquellos cuyo owner sea USU22 están afuera. Su owner es un usuario dentro del campo de acción. Su owner es un usuario dentro del campo de acción. entonces USU2 está dentro del campo de acción de GRUPO1. mientras que USU22 no. se enfrenta con restricciones similares con respecto a las opciones de auditoría a las que tiene un usuario con atributo SPECIAL a "nivel de sistema". Su HLQ es un usuario o grupo dentro del campo de acción. Por lo tanto. mientras que aquellos cuyo owner es GRUPO6 no lo están. si USU2 es un usuario cuyo owner es GRUPO2 y USU22 es un usuario cuyo owner es USU2. perfiles de recursos generales cuyo owner es GRUPO5 están dentro del campo de acción de GRUPO1. AUDITOR ni OPERATIONS a "nivel de sistema" (aunque si puede otorgarlos a nivel de grupo. sino el usuario USU1. o No puede otorgar los atributos SPECIAL. En cuanto a perfiles de dataset. se encuentran dentro del campo de acción del grupo aquellos que cumplen con alguna de las siguientes condiciones: Su owner es un grupo que está dentro del campo de acción. En consecuencia. o Para crear nuevos usuarios debe tener CLAUTH en la clase USER. Asimismo. En lo referido a perfiles de recursos generales. no tiene autoridad suficiente para modificar la configuración global de RACF establecida en la SETROPTS. o Para crear nuevos perfiles de recursos generales debe tener CLAUTH sobre la clase correspondiente. el factor determinante para establecer si determinado usuario está o no dentro del campo de acción de un grupo es su owner y no sus conexiones. En otras palabras. Los usuarios dentro del campo de acción de un grupo son todos aquellos cuyo owner es un grupo que se encuentre a su vez dentro del campo de acción. se tiene que: o Puede definir nuevos perfiles de dataset cuyo HLQ sea un grupo o un usuario dentro de su campo de acción. Se trata pues de un usuario SPECIAL pero cuya injerencia se ve restringida al campo de acción del grupo al cual se encuentra conectado con el atributo SPECIAL. se encuentran dentro del campo de acción del grupo aquellos que cumplen con alguna de las siguientes condiciones: Su owner es un grupo que está dentro del campo de acción.34 GRUPO6 no forma parte del campo de acción de GRUPO1 ya que el owner no es su grupo superior. todo perfil de recursos generales cuyo owner sea USU2 está dentro del campo de acción de GRUPO1. o Aún dentro del campo de acción del grupo. Por ejemplo. Apuntes de RACF Juan Mautalen . No están dentro del campo de acción aquellos usuarios cuyo owner sea otro usuario. Para otorgar CLAUTH sobre una clase debe tener él mismo CLAUTH sobre esa misma clase. Con respecto al uso del REVOKE con fecha. aún cuando éste no se encuentre dentro del campo de acción del grupo sobre el que tiene efectivamente el atributo GRPACC). pero restringida a los recursos (perfiles de dataset y de recursos generales) que están dentro de su campo de acción. estar conectado a un grupo con la conexión revocada es similar. siempre y cuando esté conectado al grupo dado por el HLQ. ya se analizó previamente cómo funciona a "nivel de usuario". El userid es requerido y debe estar inmediatamente a continuación del comando CONNECT. Si la conexión ya existe. el comando solo modifica los parámetros especificados (no se aplica ningún valor por defecto). perfiles de dataset y de recursos generales) que se encuentran dentro de su campo de acción. aunque si está autorizado a listar la información completa de la SETROPTS. 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. de un atributo muy poco utilizado. 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 conexión" ni puede obtener acceso a un recurso protegido como miembro del grupo. No está habilitado a modificar opciones globales de auditoría. este comando también se utiliza para modificar algún parámetro de una conexión ya existente (no existe un comando exclusivo de modificación de conexión).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. En tal caso. analizaremos en detalle ambos comandos. siendo el comportamiento a nivel de grupo análogo. Para conectarlo a otro grupo. Atributo GRPACC a nivel de grupo Sólo actúa si el grupo en cuestión es el “actual grupo de conexión” del usuario. o bien para modificar características de una conexión ya existente. desde el punto de vista de seguridad.14 . En definitiva. 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. Apuntes de RACF Juan Mautalen . a no pertenecer al mismo. usuarios. debe usarse el comando CONNECT. como ya hemos observado. Atributo ADSP a nivel de grupo Sólo actúa si el grupo en cuestión es el “actual grupo de conexión” del usuario. en tanto que para desconectarlo debe emplearse el comando REMOVE. A continuación. 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 señalamos. pero restringida a los recursos (grupos. 3. funciona igual que el atributo ADSP a nivel de sistema.Conexión de un usuario a un grupo Un usuario queda conectado automáticamente a su grupo default al ser dado de alta. Se trata. no puede conectar al usuario con nivel de autoridad JOIN (suponiendo que no detente otro tipo de atributo que se lo permita.36 Si no se codifica GROUP. No permite modificar parámetros de la conexión (esto debe hacerse con el comando CONNECT). Si se omite. Observación: No se puede desconectar a un usuario de su grupo default. y el grupo al cual se pretende conectar al usuario encontrarse dentro de su campo de acción. o a nivel de un grupo que tenga al grupo en cuestión dentro de su campo de acción. ya que muchas veces no es el efecto buscado. salvo que se codifique el operando OWNER a través del cual se especifica un usuario o grupo que se convertirá en el nuevo owner de estos perfiles. Con respecto al operando OWNER. el usuario que ejecuta el comando debe tener el atributo SPECIAL. ya sea a nivel de sistema. El OWNER de la conexión es totalmente irrelevante. 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 . Su valor por defecto es el identificador del usuario que ejecuta el comando CONNECT. entonces el operando OWNER es irrelevante y puede omitirse. AUTHORITY indica el nivel de autoridad del usuario como miembro del grupo. Ser el owner del grupo. AUDITOR u OPERATIONS a “nivel del grupo”. Si A es owner de perfiles de dataset cuyo HLQ es B. sino que simplemente se omite el grupo por distracción. Por lo tanto. debe estar conectado al grupo. como SPECIAL a nivel de sistema). USE es el valor por defecto. Tener el atributo SPECIAL a nivel de grupo. UACC asume por defecto el valor NONE. el comando conecta por defecto al usuario al “actual grupo de conexión” de quién ejecuta el comando (que suele ser su grupo default). El userid es requerido y debe estar inmediatamente a continuación del comando REMOVE. Debe tenerse cuidado con esto. En caso de tener nivel de autoridad CONNECT. Si A no es owner de ningún perfil de dataset cuyo HLQ es B. Estar conectado al grupo con nivel de autoridad CONNECT o JOIN. no se le asigna al usuario ningún atributo a nivel del grupo. Si se pone un usuario como OWNER. Autoridad requerida Para conectar un usuario a un grupo (o modificar parámetros de una conexión ya existente) a través del comando CONNECT. asume por defecto el nombre del “actual grupo de conexión” de quien ejecuta el comando REMOVE. RACF no permite la desconexión. GROUP indica el nombre del grupo del cual se desea desconectar al usuario. funciona del siguiente modo: supongamos que se pretende desconectar al usuario A del grupo B. Comando REMOVE Sintaxis: REMOVE|RE userid [GROUP(nombre)] [OWNER(usuario/grupo)] Este comando desconecta un usuario de un grupo. Para otorgar o quitar los atributos SPECIAL. el usuario que ejecuta el comando debe cumplir alguna de las condiciones siguientes: Tener el atributo SPECIAL a nivel de sistema. que analizaremos en detalle más adelante en este mismo capítulo. Por defecto. Acceder a recursos protegidos a los cuáles el grupo se encuentre autorizado. Sólo restan por analizar los posibles niveles de autoridad de un usuario dentro de un grupo. CONNECT USUA GROUP(GRPC) 2. el nivel de autoridad CREATE permite: o o Alocar nuevos datasets cuyo HLQ sea el grupo. Estar conectado al grupo con nivel de autoridad CONNECT o JOIN. el nivel de autoridad CONNECT permite: o Conectar al grupo usuarios ya existentes en la base de RACF. el usuario que ejecuta el comando debe cumplir alguna de las condiciones siguientes: Tener el atributo SPECIAL a nivel de sistema. el nivel de autoridad CREATE no permite deletear datasets cuyo HLQ sea el grupo en cuestión. REMOVE USUA GROUP(GRPB) al grupo GRPC. 2. ALTUSER USUA DFLTGRP(GRPC) 3. Definir nuevos perfiles de dataset cuyo HLQ sea el grupo. Observemos que si queda el usuario como owner. y el grupo del cual se pretende desconectar al usuario encontrarse dentro de su campo de acción. Ser el owner del grupo. debería 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 parámetros de la conexión (ver ejemplo del comando LISTUSER y parámetros a nivel de grupo). 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 conexión”. Nivel CREATE Adicionalmente. Se trata del nivel de autoridad suficiente para la casi totalidad de los casos. Tener el atributo SPECIAL a nivel de grupo. otorgándoles nivel de autoridad USE. 4. CREATE o CONNECT. Niveles de autoridad de un usuario en un grupo Los posibles niveles son: 1. USE CREATE CONNECT JOIN Se enumeraron de modo que cada nivel de autoridad incluye (y excede) los privilegios del anterior.37 pretende que USUA quede conectado únicamente comandos similar a la siguiente: 1. Sin embargo. Juan Mautalen Apuntes de RACF . salvo que se encuentre autorizado por otro motivo. 3. puede posteriormente administrarlos. Nivel CONNECT Adicionalmente. Autoridad requerida Para desconectar un usuario de un grupo. Borrar subgrupos del grupo con el comando DELGROUP. Conectar al grupo usuarios ya existentes en la base de RACF. Listar la información del grupo con el comando LISTGRP. el nivel de autoridad JOIN permite: o o o o Si tiene el atributo CLAUTH(USER). con nivel de autoridad USE. Desconectar usuarios del grupo con el comando REMOVE. puede especificar cualquier operando. CREATE. definir nuevos usuarios dentro del grupo. con nivel de autoridad JOIN. Apuntes de RACF Juan Mautalen . Nivel JOIN Adicionalmente. CONNECT o JOIN. AUDITOR|NOAUDITOR y OPERATIONS|NOOPERATIONS. con excepción de SPECIAL|NOSPECIAL. Crear nuevos grupos de RACF que sean subgrupos del grupo en cuestión.38 Modificar parámetros de la conexión al grupo de usuarios ya conectados. o o o En el caso de ejecutar el comando CONNECT al grupo. Nombre válido. Ejemplos: PROD1.1 . No existe un límite para la cantidad de calificadores que pueda tener un dataset. lo que no está permitido. No se distinguen mayúsculas de minúsculas. separados entre sí por un punto (.2010 Perfiles de Dataset Los perfiles de dataset se dividen en 2 tipos: • • Discretos Genéricos. numéricos (0 a 9). de longitud mínima 1 y máxima 8. Con el correr del tiempo y la aparición de nuevas versiones. Un “perfil de dataset” es una entidad que existe en la base de RACF y se crea. con 3 calificadores. Con posterioridad. Por el momento digamos que. pues el segundo calificador empieza con un número. Nombre válido. Los restantes pueden ser alfabéticos. La clase de RACF que los agrupa es la clase DATASET. cuya existencia es absolutamente independiente de RACF.Consideraciones generales Los datasets son. que resultaron más prácticos y fáciles de administrar. @. El primer calificador se abrevia HLQ (High level Qualifier). Ambos se vinculan del siguiente modo: los perfiles de dataset contienen información que emplea RACF para responder los requerimientos que reciba de acceso a archivos. el tipo de recurso que permite proteger RACF.PROTECCIÓN DE DATASETS 4. Conceptualmente. de un único calificador. que protegen un único archivo. los archivos pueden residir en disco o en cartucho. Datasets En el entorno z/OS. aunque para ciertas situaciones muy particulares los perfiles discretos continúan siendo una mejor opción. más allá del que surge obviamente de la longitud máxima permitida en el nombre. $). Utilizaremos indistintamente los términos dataset y archivo. dónde debía existir un perfil por cada dataset protegido. La tendencia actual es a utilizar casi exclusivamente perfiles de dataset genéricos. nacionales o un guión (-).39 4 . un único perfil genérico permite proteger una cantidad ilimitada de archivos de nombres similares. en sus primeras versiones. o sea que cuentan con respecto al máximo de 44). en sus primeras versiones. que datan de la década del 70. El primer carácter de cada calificador debe ser alfabético (A hasta Z) o nacional (#. Apuntes de RACF Juan Mautalen . A diferencia de los discretos.A2009 BASEPERS TEST1. y vienen identificados por un nombre cuya longitud máxima es de 44 caracteres. Más aún. los archivos eran los únicos recursos sobre los cuáles RACF controlaba el acceso. de modo que hoy en día RACF permite proteger una enorme variedad de recursos aparte de los datasets. Más adelante analizaremos en detalle las diferencias entre unos y otros. los perfiles de dataset son una suerte de reglas que protegen el acceso a datasets. surgieron los perfiles de dataset genéricos. Nombre inválido.) (los puntos forman parte del nombre. La cadena de caracteres que lo conforma se divide en calificadores. modifica y elimina a través del uso de comandos de RACF. tanto RACF como los distintos componentes del sistema operativo (y productos) fueron evolucionando. por excelencia.FINANZAS. es de suma importancia distinguir un “dataset” de un “perfil de dataset”. Un dataset es simplemente un archivo. PROD1 es el HLQ. Dicho más sencillamente. los únicos perfiles de dataset que admitía RACF eran los discretos. salvo que aclaremos lo contrario. Los perfiles discretos de dataset guardan una íntima relación con el archivo que protegen. suponemos la opción EGN activa en la SETROPTS. o en la entrada del catálogo para los VSAM. tienen alguno de los caracteres comodín. Estas opciones se establecen en la SETROPTS y se analizarán en detalle en el capítulo correspondiente.Perfiles genéricos Los perfiles genéricos. pueden o no tener en sus nombres los caracteres %. en virtud del significado que posee cada uno de los caracteres genéricos. y que la opción EGN -que habilita el uso del ** en los perfiles de dataset. 4. En tal caso indica que en esa posición puede haber 0 o más caracteres hasta completar el calificador. Estos 3 símbolos también se denominan caracteres genéricos o variables. según sea el caso. como en el caso de los discretos). lo cual es lo habitual en todas las organizaciones. Por otro lado. se los conoce como “perfiles genéricos completos” y solo protegen al archivo de idéntico nombre. Por ejemplo. * y ** no están permitidos. ya sea en la VTOC del disco para los NOVSAM. El doble asterisco solo puede usarse si la opción EGN (Enhanced Generic Naming) está activa en la SETROPTS. **. si existiera (lo cual no es requisito para que se pueda definir el perfil. el ** no es válido en perfiles de dataset y el * cambia ligeramente su significado. Ejemplo: TEST. los caracteres %.3 . o En todo lo que sigue.FIN* Apuntes de RACF Juan Mautalen . caben distintas posibilidades: Si forma parte de un calificador que contiene otros caracteres.Perfiles discretos Un perfil discreto de dataset debe tener idéntico nombre que el archivo que pretende proteger. Signo porcentual (%) Variable que indica un único carácter cualquiera en esa posición (con excepción del “. solo es posible definir un perfil discreto de dataset si realmente existe un archivo con ese nombre en el volumen indicado. * y **. que detallamos a continuación. entonces “cubren” una gran cantidad de eventuales datasets.está activa. Más aún. en cambio. un bit se activa indicando que el archivo está protegido por un perfil discreto. sigla de Direct Access Storage Device). El HLQ debe coincidir con un usuario o grupo existente en la base de RACF. En caso contrario. Con excepción del HLQ.A200% Asterisco (*) Para esta variable. vamos a asumir que la clase DATASET está seteada como GENERIC y GENCMD.40 Los perfiles de dataset siguen las mismas convenciones para sus nombres que los archivos. Como ya señaláramos. Si se deletea un archivo protegido por un perfil discreto. *. con las siguientes salvedades: o o Deben tener 2 o más calificadores.”) Ejemplo: TEST. Por lo tanto.2 . Cuándo no tienen ningún carácter genérico. supondremos que todos los archivos residen en disco (también llamados DASD. automáticamente se borra de la base de RACF el perfil de dataset correspondiente. al proteger un archivo discretamente. 4. Los denominaremos “perfil de dataset de usuario” o “perfil de dataset de grupo”. Se dice en tal caso que el archivo está RACF-indicado.FINAN. debe ser el carácter final. Si. ampliamente más usados que los discretos. pueden utilizarse en los siguientes calificadores los caracteres comodín: %. el perfil discreto actúa como perfil protector del archivo TEST. RACF busca todos los perfiles genéricos que lo cubren (si no existiera ninguno. el símbolo (G) característico de los perfiles genéricos (ver 4.Para las variables. de acuerdo al siguiente criterio: . RACF se guía por el principio del perfil más específico.FINANZAS. RACF procede del siguiente modo: Si existe un perfil discreto para el archivo.FINAN%%%. Por lo tanto. Si volvemos al ejemplo anterior. Ejemplo: TEST. TEST.A* 7.*. Ejemplo: Perfiles: 1. Siguiendo este procedimiento. Indica la presencia de 0 o más calificadores en esa posición. En este caso.FINANZAS.** 4. muchos perfiles de dataset pueden cubrir al mismo archivo. TEST.A2002. TEST.A2002 Un perfil discreto se distingue de un genérico completo de igual nombre por no presentar. * y **. Sin embargo. no está permitido el uso de caracteres genéricos en el primer calificador. simplemente el archivo no estaría protegido). TEST. o bien determina un único perfil que lo protege (que puede resultar discreto o genérico). a lo sumo.Los caracteres “no genéricos” son más específicos que las variables.*.FINANZAS. TEST. mientras que los números 7 y 8 no lo hacen (el 7 solo contempla un único carácter luego de la “A” del último calificador. y procede a compararlos. como muestra el ejemplo. dado un archivo. TEST. Si no existe un perfil discreto.A2002. es %.* 5. TEST. a la hora de determinar la protección.FINAN*. un único perfil protector para un dataset. Esto significa que.**.41 Si constituye un calificador completo. Ejemplo: TEST.10). TEST. de izquierda a derecha.Cómo 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. 4. En el primer carácter en que encuentre alguna diferencia. Para determinar el perfil protector. o bien RACF no lo encuentra protegido.FINANZAS. Por lo tanto. . cuando se lo lista. que llamamos “perfil protector”.*. mientras que el * final en el 8 exige la existencia de un cuarto calificador). el orden. se descartan aquellos más genéricos.A% 8.FINANZAS.FINANZAS.4 . RACF siempre determina.A2002 3.A2002 2.* discreto genérico completo Los 6 primeros perfiles cubren al archivo TEST.A2002 Recordemos que el HLQ de todo perfil de dataset debe ser un usuario o grupo definido en la base de RACF. Apuntes de RACF Juan Mautalen . entonces éste será su perfil protector. notamos que los perfiles del 1 al 6 están ordenados del más al menos específico. indica que en esa posición puede existir cualquier calificador pero que debe necesariamente existir uno. y no puede utilizarse más de una vez por perfil.A2002 Doble asterisco (**) Esta variable debe usarse como un calificador entero.* 6. desde el menos al más genérico. 4. Su significado se muestra en la tabla siguiente: NONE No permite acceder al dataset. Su implementación suele ser problemática. existen distintos niveles de autoridad que se pueden especificar para perfiles de dataset. Cabe señalar que READ es suficiente para copiar o imprimir el archivo. renombrar. Este nivel de autoridad permite ejecutar programas de la librería.5 . EXECUTE Se utiliza exclusivamente para bibliotecas de módulos.Niveles de autoridad para perfiles de dataset Tanto en el UACC. Sobre perfiles discretos. Consideraciones importantes: RACF no brinda la posibilidad de proteger datasets particionados a nivel de miembros (members). solo es necesario proteger el nombre del cluster. Sobre archivos VSAM. READ UPDATE Permite acceder al dataset únicamente para lectura. Estos son los siguientes: o o o o o o NONE EXECUTE READ UPDATE CONTROL ALTER Se enumeraron desde el más restrictivo al más permisivo. el genérico más específico que lo cubre). Solo se puede proteger una biblioteca de manera global. permite las operaciones normales de I/O. Apuntes de RACF Juan Mautalen . se lo debería aislar en otra biblioteca y protegerla de manera adecuada. mover y deletear el dataset. Permite tanto leer como modificar el dataset. renombrarlo o moverlo. ALTER Permite leer. Cada nivel incluye y excede los privilegios del anterior. si un miembro particular requiriera un tratamiento diferenciado en cuanto a su seguridad. También permite borrar el perfil de la base. sin embargo. Sobre perfiles genéricos no otorga ningún privilegio administrativo. Sobre archivos VSAM. Los nombres de los restantes componentes del VSAM (data e index) no intervienen en el momento de resolver sobre una solicitud de acceso. a través de un único perfil de dataset. a deletearlo. En el caso de archivos VSAM. Por lo tanto. otorga además la posibilidad de administrar el perfil. modificando casi cualquier campo -incluida la lista de acceso. Autoriza asimismo a alocar nuevos datasets que queden protegidos por este perfil. es equivalente a UPDATE. como en las listas de acceso. Mas adelante analizaremos el comando LISTDSD en detalle. CONTROL Para archivos NOVSAM. No autoriza. Aconsejamos usar READ en lugar de EXECUTE. modificar. el comando: LISTDSD DATASET(‘nombre-del-archivo’) GENERIC ALL lista el perfil protector del dataset codificado en el operando DATASET (o sea. pero no autoriza a copiarlos. permite un nivel de acceso más amplio que UPDATE (improved control interval processing).42 Si el dataset no tiene un perfil discreto. Si el nombre no contiene estos caracteres. o **). el UACC establece el nivel de acceso que tendrá sobre los archivos protegidos por el perfil todo usuario que no se encuentre explícitamente en la lista de acceso (ni ninguno de sus grupos) ni que tenga algún nivel de acceso particular por otro motivo (atributo OPERATIONS. No analizaremos en detalle todas las condiciones manejables a nivel de la lista de acceso condicional. de longitud máxima 255 caracteres. El operando UACC es sumamente importante y establece el “nivel de acceso universal” (Universal Access) del perfil. READ. que ya se analizaron previamente. la lista de acceso estándar suele ser suficiente. Por ejemplo. a menos que se codifique explícitamente el operando GENERIC. puede autorizarse a un usuario a acceder a un archivo únicamente cuando se encuentre logueado en una determinada terminal o consola. El OWNER del perfil debe ser un usuario o grupo existente.Definición 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 continuación del comando ADDSD. Puede eventualmente también figurar una entrada *. acompañados cada uno de un determinado nivel de autoridad.43 4. queda como tal el usuario que ejecutó el comando (salvo que el HLQ sea un usuario distinto. UPDATE. Básicamente.6 . aún cuando se omita el operando GENERIC. entonces el perfil creado resulta genérico. conviene que sea NONE. Existen 2 tipos: Lista de acceso estándar Es la que se utiliza en la enorme mayoría de los casos. Contiene un listado de grupos y usuarios. A diferencia de los perfiles de grupo y usuarios. como señaláramos anteriormente. Para poder acceder a ellos.Administración de perfiles de dataset Ya señalamos anteriormente las restricciones que existen con respecto al nombre de estos perfiles. Si es un “perfil de dataset de grupo” y se especifica un usuario como owner. para los requerimientos usuales de seguridad. Lista de acceso condicional A través de esta lista se puede otorgar acceso a un dataset siempre y cuando se cumplan ciertas condiciones (que se encuentren previstas. por ejemplo). Si no se especifica UACC. Notemos que ser dueño de un perfil de dataset no otorga acceso a los eventuales archivos que proteja. en cuyo caso éste queda como owner). debe agregarse al usuario en la lista de acceso a través del comando PERMIT. En un capítulo posterior estudiaremos con todo detalle el proceso que sigue RACF para determinar el nivel de autoridad de un usuario sobre un recurso. debe necesariamente estar conectado al grupo. Analizaremos ahora en detalle los comandos necesarios para su administración. el valor por defecto es el UACC que tiene el usuario que ejecuta el comando en su “actual grupo de conexión” (que. Puede tomar los valores NONE. De todos modos. en cuyo caso resultará un “perfil genérico completo”. Apuntes de RACF Juan Mautalen . *. los perfiles de dataset tienen listas de acceso (access lists). Si contiene caracteres genéricos (%. CONTROL y ALTER. La DATA del perfil es un campo de uso administrativo. entonces se creará un perfil discreto. ya que ello escapa al objetivo de este texto introductorio.7 . EXECUTE. naturalmente). Si no se codifica OWNER. por motivos de seguridad). 4. ).44 GENERIC debe obligatoriamente especificarse si se pretende definir un “perfil genérico completo”. FGENERIC indica a RACF que el perfil especificado en el operando FROM es genérico. Es importante tener en cuenta que si el archivo no estaba RACF-indicado y se codifica NOSET. los operando GENERIC y MODEL son incompatibles. Todas las características del perfil especificado en el operando FROM son replicadas en el nuevo (OWNER. o bien el nombre-del-perfil contiene caracteres genéricos. El valor por defecto es DATASET. Para cualquiera de las opciones -SET. NOSET establece que se cree un perfil discreto pero sin alterar el estado del bit indicador del archivo. independientemente de que figure o no en la lista de acceso del perfil modelo. si el dataset ya estaba RACF-indicado. Si el operando FROM especifica un perfil discreto de DATASET. si se especificó GENERIC. DATA. el operando MODEL es ignorado.Si la opción ADDCREATOR está activa en la SETROPTS. no es necesario que exista realmente un archivo cuyo nombre coincida con el del perfil (como sí es requisito para perfiles discretos comunes). En la presente guía no trataremos en detalle la protección de archivos en cartuchos. 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). en el cual se va a basar RACF para la creación del nuevo perfil. ya que en caso contrario el comando falla). En consecuencia. el perfil creado no lo protegerá. NOSET y SETONLY-. SETONLY es una opción 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). el operando NOSET|SET|SETONLY establece cómo se desea manejar el “bit indicador” del archivo: El valor por defecto es SET. en los casos siguientes: . el operando de seteo es ignorado. el usuario que crea el nuevo perfil se agrega a la lista de acceso con autoridad ALTER. Si en el nombre del perfil figura algún carácter genérico. Si el nombre del perfil contiene algún carácter genérico. El operando FROM especifica el nombre de un perfil. entonces el grupo se agrega a la lista de acceso con autoridad UPDATE. que activa el bit indicador dejando al archivo RACF-indicado. Cuando se especifica MODEL. y pueden omitirse los operandos UNIT y VOLUME. etc. AUDITING.Si se crea un “perfil de dataset de grupo”. discreto o genérico. TAPE indica que se va a definir un perfil discreto que protege un archivo en cartucho (debe estar la opción TAPEDSN activa en la SETROPTS. MODEL indica que se va a definir un perfil discreto que luego será utilizado como modelo para la definición de futuros perfiles de dataset. Este operando prevalece sobre la eventual modelización de perfiles que pueda existir para el usuario o grupo dado por el HLQ. ya que intentaría activar un bit que ya se encontraba activado). Cuando se define un perfil discreto. . Puede existir una mínima diferencia en la lista de acceso del nuevo perfil con respecto al tomado como modelo. ya que allí es dónde se establece que tipo de perfiles de dataset se pretende modelizar. no es necesario codificar GENERIC (aunque puede hacerse). RACF ignora el operando FGENERIC si no se codificó FROM. el operando TAPE es ignorado. Listas de acceso. y quien lo hace tiene el atributo GRPACC y está conectado a él. WARNING. Si se codifica FVOLUME con un valor distinto al que Apuntes de RACF Juan Mautalen . el operando NOSET lo deja en la misma condición (en este caso. el operando FVOLUME debe indicar el volumen correspondiente del perfil modelo. excepto que se codifique explícitamente un valor distinto para alguno de estos operandos en el comando ADDSD. NOTIFY. Si el nombre del perfil contiene algún carácter genérico. siendo el último codificado el que prevalece. el valor SET provocaría un error. Volveremos sobre la creación de perfiles basados en un modelo en el capítulo dónde analicemos las opciones de la SETROPTS. aún cuando no contenga caracteres genéricos. UACC. RACF ignora el operando FCLASS si no se codificó FROM. Si no existen en el nombre tales caracteres. independientemente de que figure o no en la lista de acceso del perfil modelo. Esto significa que. a saber: “tipo de acceso” y “nivel de acceso”: Los posibles tipos de acceso son los siguientes: o NONE indica que ningún intento de acceso será grabado. o con un perfil de una clase que no sea DATASET. o sea que se encuentran básicamente desprotegidos. En ciertas ocasiones. en lugar de denegar el acceso lo autoriza pero envía un mensaje a la terminal del usuario (y graba uno similar en el SYSLOG) indicando que el acceso no correspondía pero fue otorgado por estar el perfil protector en modo warning. UNIT y VOLUME son ignorados. EXECUTE no es un nivel factible de ser auditado. Los operandos UNIT y VOLUME son requeridos únicamente en el caso de perfiles discretos que correspondan a archivos no-vsam y no catalogados. NOTIFY no admite más de un usuario. o ALL indica que se grabará todo intento de acceso. De todos modos. En caso contrario las recibirá en el momento de su próximo logon (no se pierden).Si se omite el operando WARNING. de modo a no provocar una interrupción en alguna tarea crítica. ni un grupo de RACF. ningún usuario será notificado. y normalmente por un período muy corto de tiempo. sea fallido o exitoso. Si se lo omite. debe tenerse presente que aquellos recursos protegidos por un perfil en modo warning se encuentran accesibles por cualquier usuario con el máximo nivel de autoridad. Si la cantidad de notificaciones esperadas es elevada. Se distinguen 2 conceptos diferentes. 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 más) tipos de acceso acompañados del nivel de acceso deseado (obviamente NONE no requiere un nivel de acceso asociado). puede resultar útil definirlo en modo warning. debe usarse esta facilidad con sumo cuidado. y RACF determina que no está autorizado. el usuario debe loguearse frecuentemente a TSO de modo de liberar el espacio que ocupan sus mensajes pendientes en el archivo SYS1. Este debe ser el modo en que se encuentren usualmente todos los perfiles de la base. si un usuario requiere acceso a un recurso protegido por el perfil. La información se graba en registros tipo 80 del SMF. o se codificó con un perfil genérico. el operando FVOLUME es ignorado. queda como usuario a ser notificado quien ejecutó el comando ADDSD. que es lo más habitual. Sin embargo. Si no se especificó el operando FROM. Si se lo codifica sin especificar usuario. El operando WARNING establece que el perfil se define en modo warning. Apuntes de RACF Juan Mautalen . o FAILURES indica que se grabarán intentos de acceso fallidos. El operando AUDIT indica a qué nivel se pretende auditar el uso de este perfil. o SUCCESS indica que se grabarán accesos exitosos. NOTIFY especifica un usuario que será notificado cada vez que el perfil sea usado para denegar un acceso. no se envía notificación alguna. recibirá las notificaciones en tiempo real. o si se omite y existe más de un perfil discreto con ese nombre. Por lo tanto. En tal caso. el comando falla. cuando aún no se logró determinar exactamente que usuarios deben acceder a los archivos protegidos por un perfil. Hacemos notar que si el perfil es utilizado para rechazar la creación o eliminación de un archivo.BRODCAST. si se supone que el mismo denegará gran cantidad de accesos. UNIT debe indicar el tipo de dispositivo dónde reside el archivo mientras que VOLUME especifica el volumen. no es conveniente tener en forma permanente un usuario en el campo NOTIFY de un perfil.45 corresponde. o se especificó el operando MODEL. Si el usuario especificado en el operando NOTIFY se encuentra con una sesión activa de TSO. Si el perfil es genérico. que llamamos modo fail. el perfil queda definido como NOWARNING. Tener el atributo SPECIAL a nivel de sistema.BALANCE. Para definir un “perfil de dataset de grupo”. Tener el atributo OPERATIONS a nivel de sistema y no estar conectado al grupo dado por el HLQ.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. pues en caso contrario el comando fallaría ya que no se especificó UNIT ni VOLSER.46 FAILURES(READ) es el valor por defecto.pagos. ya que se codificó el operando GENERIC. y no estar conectado a ese grupo. Tal dataset debe estar catalogado. Ejemplos 1) AD ‘conta.provee. 3) AD ‘prod.PAGOS. Debe tenerse cuidado en no especificar un nivel de auditoría que genere un volumen grande e inútil de información. en el caso de un perfil que proteja recursos muy utilizados.A2010.a200%. 4) AD ‘conta. Tener el atributo OPERATIONS a nivel de un grupo que tenga dentro de su campo de acción al grupo dado por el HLQ. Apuntes de RACF Juan Mautalen . este valor prevalece por sobre la Installation Data que tiene el perfil modelo. SUCCESS(READ). Se decidió auditar todo acceso fallido más los accesos exitosos de nivel UPDATE (o superior). Tener el atributo SPECIAL a nivel de un grupo que tenga al usuario dado por el HLQ del perfil dentro de su campo de acción. 2) AD ‘conta.**’ FROM(‘conta.**’ DATA(‘archivos de uso publico’) UACC(read) Define un perfil genérico. 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. y provoca que se registre todo intento de acceso denegado por el perfil (intentos de acceso fallidos superiores a READ también son registrados). Como se especificó DATA. Tener el atributo SPECIAL a nivel de sistema. Autoridad requerida para definir perfiles de dataset Para definir un “perfil de dataset de usuario”. Se decidió establecer como owner y usuario a ser notificado a JEF254.A2010. basado en el modelo dado por el perfil genérico completo CONTA. Más adelante veremos cómo interactúa el nivel de auditoría del perfil con los seteos globales de auditoría que se establecen en la SETROPTS. Tener el atributo SPECIAL a nivel de un grupo que tenga al grupo dado por el HLQ del perfil dentro de su campo de acción.PAGOS.public. A diferencia del caso anterior.balance.pagos. tal archivo ni siquiera tiene necesidad de existir en el momento de la creación del perfil. 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. dado que el nombre contiene el carácter genérico **.a2010’) FGENERIC DATA(‘pagos a proveedores’) Define un perfil genérico. Por ejemplo.A2010.a2010’ GENERIC DATA(‘pagos del 2010’) UACC(none) OWNER(jef254) NOTIFY(jef254) Define un perfil “genérico completo” para el archivo de nombre CONTA. generaría una enorme cantidad de registros tipo 80 de SMF que probablemente no sean necesarios en absoluto. 8 . Salvo situaciones particulares que así lo justifiquen. en este caso. NOSET se aplica exclusivamente para perfiles discretos. 4. no forma parte del archivo).Eliminación de un perfil de dataset Sintaxis: DELDSD|DD ‘nombre-del-perfil’ [GENERIC|NOSET|SET] [VOLUME(volumen)] La eliminación de un perfil de dataset nunca borra ningún archivo. No es posible modificar un perfil discreto para convertirlo en “genérico completo”. Fuera de la base de RACF. Ser el owner del perfil tomado como modelo. Si el perfil es discreto. quien ejecuta el comando debe cumplir con alguno de los siguientes requisitos: Tener el atributo SPECIAL a nivel de sistema. aún cuando no contenga caracteres comodín en su nombre. recordemos. Tener un identificador de usuario que coincida con el HLQ del perfil tomado como modelo. Ser el owner del perfil. lo único que este comando puede eventualmente modificar es el “bit indicador” de protección de un dataset (que. o viceversa. RACF exige además que el usuario que ejecuta el comando satisfaga alguno de los siguientes requisitos: Tener el atributo SPECIAL a nivel de sistema. GENERIC indica que debe considerarse al perfil como genérico. tener autoridad ALTER sobre el perfil. Tener el atributo SPECIAL a nivel de un grupo que tenga al perfil tomado como modelo dentro de su campo de acción. debe deletearse el perfil y definirlo nuevamente de la manera deseada. Si el perfil modelo es discreto.Modificación 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 modificación de perfiles. Indica que no se modifique el estado del “bit indicador” del archivo. Si se pretende realizar esto.47 Para poder usar el operando FROM. 4. pues es fuente de confusión e inconvenientes. debe evitarse el uso de esta opción. pues no es conveniente dejar marcados como protegidos discretamente archivos que ya no lo están. solo es necesario codificar los operandos que se desee modificar. quedaría protegido Apuntes de RACF Juan Mautalen . Autoridad requerida Para modificar un perfil de dataset. que permite crear un nuevo perfil de dataset basándose en uno ya existente. Tener el atributo SPECIAL a nivel de un grupo que tenga al perfil dentro de su campo de acción. El archivo. tener autoridad ALTER sobre el perfil. aún cuando no contenga tales caracteres en su nombre. Los no especificados mantienen sus valores previos (no se aplican valores por defecto).9 . El operando GENERIC indica simplemente que debe considerarse al perfil como genérico. Su identificador de usuario debe coincidir con el HLQ del perfil. ID debe especificar un usuario o grupo. según como se codifique el Apuntes de RACF Juan Mautalen . RACF lista la información del perfil discreto correspondiente. o todos. o todos. en caso de que existiera alguno perfil genérico apropiado. el comando falla. Autoridad requerida Para eliminar un perfil de dataset. 4. VOLUME solo es necesario para perfiles discretos. siempre y cuando existan en la base de RACF más de un perfil discreto con el nombre en cuestión pero con distintos volúmenes asociados. o con salida a un dataset o al spool. solo genéricos. Se listarán solo discretos. En tal caso. y requiere que el volumen donde reside esté en línea. Se listarán solo discretos. o Si el nombre no tiene caracteres comodín y se especifica GENERIC.10 . Su identificador de usuario debe coincidir con el HLQ del perfil. En efecto. si se ejecuta en batchground) información relativa a perfiles de dataset. y también se aplica exclusivamente a perfiles discretos. En tal caso.48 genéricamente. DATASET|ID|PREFIX El operando DATASET especifica el nombre del perfil a listar. en tal caso. lo informa. Si no existiese. Unicamente lista (en la pantalla de la terminal. debería codificarse NOSET para poder borrar el perfil. GENERIC. solo genéricos. según se especifique NOGENERIC. Si ninguno existiese. el comando lista los perfiles cuyo HLQ coincide con este valor. quien ejecuta el comando debe cumplir con alguno de los siguientes requisitos: Tener el atributo SPECIAL a nivel de sistema. o simplemente desprotegido en caso contrario.] Este comando no efectúa ninguna modificación sobre la base de RACF.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). Ser el owner del perfil. o se omita este operando. lo informa. de su perfil protector. lo informa. o Si el nombre tiene algún carácter comodín. o Si el nombre no presenta caracteres comodín y se especifica NOGENERIC. SET es el valor por defecto. o Si el nombre no presenta caracteres comodín y no se especifica ni GENERIC ni NOGENERIC. siempre y cuando no esté protegido de manera discreta). RACF lista la información del perfil genérico que más se ajusta al nombre del archivo (o sea. Si el perfil es discreto. Si no existiese. Si se especifica PREFIX. si se ejecuta en foreground. RACF ignora el operando [GENERIC|NOGENERIC] y lista el perfil genérico que coincide exactamente con el nombre especificado.. el comando lista los perfiles cuyos primeros caracteres coincidan exactamente con el valor especificado. Si el archivo tuviera su bit de protección desactivado. RACF lista la información del perfil discreto y del “genérico completo”. y se especifica SET. Tener el atributo SPECIAL a nivel de un grupo que tenga al perfil dentro de su campo de acción. Este operando desactiva el bit de protección del archivo. VOLUME es requerido por RACF para saber cuál es exactamente el perfil discreto que debe borrar de la base. tener autoridad ALTER sobre el perfil.. PAGOS. El operando VOLUME limita la información listada a los perfiles discretos asociados con estos volúmenes (se pueden especificar varios). si se especificó ID o PREFIX. GENERIC indica que deben listarse únicamente perfiles genéricos. mientras que NOGENERIC indica que solo deben listarse los discretos. ni ID ni PREFIX. La cadena de caracteres especificada puede extenderse a más de un calificador. siempre tienen a continuación de su nombre el símbolo (G). Por lo tanto. Si no se especifica. En cambio. esta búsqueda cruzada es costosa y puede demorar considerablemente la ejecución del comando.pagos. el valor que asume por defecto es ID con el valor del identificador del usuario que ejecuta el comando. ya se señaló qué perfiles son listados.PAGOS. siempre y cuando exista.**. AUTHUSER especifica que se debe incluir en la salida del comando la siguiente información: o Security level. La salida tendría el siguiente aspecto: INFORMATION FOR DATASET CONTA.49 operando correspondiente. el listado no muestra ni las estadísticas ni las listas de acceso. En caso de no especificar ni DATASET. categories y security label o Lista de acceso estándar o Lista de acceso condicional ALL indica que se liste toda la información del perfil. Excepto que se haya codificado NOGENERIC. El operando DSNS indica que se listen todos los archivos catalogados protegidos por el perfil.PAGOS SECURITY LEVEL NO SECURITY LEVEL CATEGORIES NO CATEGORIES SECLABEL Apuntes de RACF Juan Mautalen CREATION GROUP ADMIN DATASET TYPE NON-VSAM . al ser listados (ya sea con el comando LISTDSD o SEARCH). Si se omite este operando. también se listan los perfiles genéricos que correspondan. Si la cantidad es muy grande. Ejemplo: LD DA(‘conta.** (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 . y se codificó DATASET. se listan todos los perfiles (discretos y genéricos) que cumplan con el criterio de selección correspondiente. la ausencia de la (G) indica sin lugar a dudas que se trata de un perfil discreto. Observación importante: Los perfiles genéricos.**’) ALL DSNS Este comando lista toda la información del perfil genérico CONTA. Esto significa que se denegará todo acceso no autorizado.PAGOS. a nivel de la SETROPTS o del GLOBALAUDIT del perfil). cada organización tiene usualmente una nomenclatura bastante diferente para ambos. cualquiera sea el nivel (excepto que exista algún otro seteo de auditoría que indique lo contrario. aunque en general no es posible determinar con solo mirar un identificador si se trata de un usuario o de un grupo.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. ya que figura el símbolo (G) a continuación del nombre. los datos deben ser físicamente borrados en el disco dónde reside (sobrescribiendo todos los extents con ceros binarios).PAGOS. y cada organización lo maneja como desea (aunque es realmente poco utilizado). Suponemos que es un grupo.INDEX (I) Del listado precedente. El OWNER es CONTA. Este requerimiento extra de seguridad.PROVEE. Apuntes de RACF Juan Mautalen . No debe confundirse LEVEL con “SECURITY LEVEL”. se desprende la siguiente información sobre el perfil: Se trata efectivamente de un perfil genérico.PAGOS. podemos estar seguros que CON587 es un usuario. De todos modos. todos los perfiles deben estar en modo fail.PAGOS. no suele ser necesario. Los accesos exitosos no serán grabados.** sea utilizado para denegar una solicitud de acceso.A2009 CONTA. Un posible uso consiste en asignarle a todos los perfiles con un cierto grado de sensibilidad un mismo LEVEL. No tiene ninguna relevancia en el chequeo de autoridad. que impide cualquier intento de recuperación de los datos. de modo de disponer de un criterio de selección para la elaboración de informes de auditoría. ya que el campo NOTIFY no admite grupos. LEVEL es un campo para uso administrativo. En este caso. FAILURES(READ) en el campo AUDITING indica que se pretende loggear en el SMF únicamente los intentos de acceso denegados por el perfil. que puede tomar cualquier valor entre 00 y 99. siendo 00 el valor por defecto. especifica que cuando se deletea un archivo protegido por este perfil. con lo cual suele ser mas o menos evidente para los administradores cuando se trata de un usuario y cuando de un grupo.PROVEE CONTA.PROVEE.PAGOS.PAGOS.El valor por defecto es NO. El usuario CON587 recibirá una notificación cada vez que el perfil CONTA. Salvo casos excepcionales.DATA (D) CONTA.A2007 CONTA. combinado con una configuración apropiada del ERASE a nivel de la SETROPTS. El UACC del perfil es NONE. WARNING en NO indica que el perfil está en modo fail.A2008 CONTA. El valor YES en campo ERASE a nivel del perfil. por otro lado). pero es únicamente visible y modificable por usuarios con el atributo AUDITOR a nivel de sistema. No nos ocuparemos en la presente guía de analizar la lista de acceso condicional de un perfil (no es muy frecuente su uso. MODEL o TAPE. correspondientes a sus distintos componentes). también puede figurar en la lista de acceso una entrada *. o a nivel de un grupo que tenga al perfil dentro de su campo de acción. el perfil se creó el día 295 del año 2010. CATEGORIES y SECLABEL son campos relacionados con un nivel extra de seguridad que brinda RACF y es realmente muy poco utilizado.al del UACC. Tener autoridad READ o superior sobre el perfil. quien ejecuta el comando debe cumplir con alguno de los siguientes requisitos: Tener el atributo SPECIAL. En nuestro caso. La lista de acceso estándar del perfil tiene entradas constituidas por usuarios o grupos. En el ejemplo. GLOBALAUDIT funciona de manera similar al campo AUDIT. AUDITOR u OPERATIONS a nivel de un grupo que tenga al perfil dentro de su campo de acción. Al haber especificado el operando DSNS en el comando LISTDSD. existen 3 entradas en la lista de acceso estándar (vale la misma aclaración que se hizo previamente. los 3 campos deben indicar que no tienen información. LAST REFERENCE DATE y LAST CHANGE DATE no se aplican a perfiles genéricos. CREATION DATE indica el día y el año en que se definió el perfil. existen 4datasets. La INSTALLATION DATA es opcional. pero es una buena costumbre usar este campo para describir brevemente el perfil. Si la organización no usa esta seguridad adicional. que tiene un significado similar -pero no idéntico. uno de los cuáles es VSAM (y por eso genera 3 entradas en el listado. Su identificador de usuario debe coincidir con el HLQ del perfil. en el sentido en que no se puede distinguir a priori si se trata de usuarios o grupos). VSAM. Autoridad requerida Para listar un perfil de dataset. Ser el owner del perfil. ALTER COUNT. En el caso de perfiles discretos. Solamente se mantienen estos campos para perfiles discretos. Apuntes de RACF Juan Mautalen . CONTROL COUNT. solo se mantienen actualizados si está especificado en la SETROPTS que se mantengan estadísticas para la clase DATASET. GLOBALAUDIT o listas de acceso). CREATION GROUP indica el “grupo de conexión” que tenía el usuario que definió el perfil en el momento de la creación. Eventualmente. 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. SECURITY-LEVEL. En este caso. con su nivel de acceso correspondiente. la salida incluye una lista de los archivos catalogados que se encuentran protegidos por el perfil. AUDITOR u OPERATIONS a nivel de sistema. Tener el atributo SPECIAL. UPDATE COUNT y READ COUNT no se aplican a perfiles genéricos.51 El campo YOUR ACCESS muestra el nivel de autoridad que tiene sobre el perfil el usuario que ejecuta el comando LISTDSD. DATASET TYPE puede tomar los valores NON-VSAM. La lista de acceso condicional se encuentra vacía (no contiene ninguna entrada). se asume READ. Sintaxis: PERMIT|PE ‘nombre-del-perfil’ [CLASS(clase)] [GENERIC] [ID({usuario/grupo. 4. o a nivel de grupo para un grupo que tenga al perfil dentro de su campo de acción). AUDITOR u OPERATIONS a nivel de un grupo que tenga al perfil dentro de su campo de acción. Si se codifica ACCESS sin poner ningún valor. Si el nombre contiene caracteres comodín. por lo cual. Para que se liste el campo GLOBALAUDIT se debe tener el atributo AUDITOR (ya sea a nivel de sistema. en el caso particular que nos ocupa. puede omitirse. CLASS indica la clase a la que pertenece el perfil.Permisos sobre perfiles de dataset Las listas de acceso de un perfil de dataset. El valor por defecto es DATASET. ID indica el usuario o grupo cuya entrada en la lista de acceso se desea agregar. RACF actúa sobre la lista de acceso estándar. GENERIC especifica que el perfil es genérico. modificar o eliminar. en cuyo caso se modifica la lista de acceso condicional. tener autoridad ALTER. Existir una regla en la GLOBAL que coincida con el perfil y otorgue autoridad ALTER. AUDITOR u OPERATIONS a nivel de sistema. Más aún.|*})] [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 continuación del comando PERMIT. UPDATE. Si el perfil es discreto. Los posibles valores son NONE. ACCESS especifica el nivel de autoridad a otorgarle al usuario/grupo especificado en el operando ID. ya sea con ACCESS o DELETE. También se acepta el valor *. pues de lo contrario RACF supondrá que el perfil es discreto. En ambos casos. Apuntes de RACF Juan Mautalen . se modifican a través del comando PERMIT. Debe necesariamente codificarse si se trata de un “genérico completo”. Separados por espacios pueden ingresarse más de un usuario/grupo. quien ejecuta el comando debe satisfacer alguna de las siguientes condiciones: Tener el atributo SPECIAL. DELETE indica que se pretende borrar de la lista de acceso la entrada correspondiente al usuario/grupo codificado en el operando ID... Su identificador de usuario debe coincidir con el HLQ del perfil. Ser el owner del perfil.11 . EXECUTE. GENERIC puede omitirse. que representa un usuario cualquiera existente en la base de RACF. READ.52 Existir una regla en la GLOBAL que coincida con el perfil y otorgue autoridad READ o superior. Tener el atributo SPECIAL. CONTROL y ALTER. se asume por defecto ACCESS(READ). tanto la estándar como la condicional. con este mismo comando se manejan también las listas de acceso de cualquier perfil de recursos generales. Si se especificó ID pero se omitió tanto ACCESS como DELETE. excepto que se codifique explícitamente el operando WHEN. Para ver las listas de acceso del perfil. No describiremos los distintos suboperandos que admite. si una entrada que figura en la lista de acceso del perfil2 ya se encuentra en la del perfil en cuestión. Independientemente de las entradas que se copien. o se codificó con un perfil genérico. modifica su nivel a UPDATE. el usuario debe satisfacer alguna de las siguientes condiciones: Apuntes de RACF Juan Mautalen . en tanto que RESET(WHEN) hace lo propio con la condicional. El orden de los operandos no tiene importancia en este caso.A2010. Más aún.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. El operando RESET indica que se quiere vaciar una o ambas listas de acceso. pudiendo haberse especificado RESET al final (si se codifican ambos operandos -RESET y ID-.provee. del cual se quieren copiar las listas de acceso (estándar y condicional). o con un perfil de una clase que no sea DATASET. Si no se especificó el operando FROM. o si se omite y existe más de un perfil discreto con ése nombre. Si se omite WHEN. Si el operando FROM especifica un perfil discreto de DATASET. el comando falla. las modificaciones se efectúan sobre la lista de acceso estándar (aunque los operandos FROM o RESET pueden impactar igualmente sobre la lista de acceso condicional).BALANCE.A2010.**’ RESET ID(*) ACCESS(READ) Vacía las listas de acceso (estándar y condicional) del perfil genérico CONTA. Si se codificara FVOLUME con un valor distinto al que corresponde al perfil2.** con nivel de autoridad ALTER. FGENERIC indica a RACF que el perfil especificado en el operando FROM es genérico. el operando FROM no convierte en idénticas las listas de acceso de ambos perfiles. mientras que si no estaba.a2010. 2) PE ‘conta. RESET(ALL) vacía ambas listas de acceso. el operando FVOLUME es ignorado. Las entradas en las listas de acceso del perfil2 son agregadas a las listas de acceso correspondiente.PROVEE.A2010.** las entradas de las listas de acceso del perfil “genérico completo” de nombre CONTA.A2002 al grupo CONTA. Por lo tanto. El operando WHEN indica que se quiere modificar la lista de acceso condicional. genérico o discreto.A2010. primero se vacía la lista de acceso y luego se procesa el ID).a2010’ ID(conta) ACCESS(update) Otorga UPDATE en la lista de acceso estándar del perfil discreto CONTA. Si omite FCLASS y se codificó FROM.** e incorpora en la lista estándar la entrada * con nivel de acceso READ.a2010’) FGENERIC ID(jef234 jef587) ACCESS(ALTER) Copia al perfil genérico CONTA. es decir eliminar todas las entradas.balance. 3) PE ‘conta. RESET(STANDARD) vacía únicamente la lista de acceso estándar.PAGOS. FCLASS indica la clase a la que pertenece el perfil especificado en el operando FROM.**’ FROM(‘conta. Autoridad requerida Para ejecutar exitosamente el comando PERMIT sobre un perfil de dataset. Si se codifica RESET sin ningún valor. lo incorpora con este nivel de acceso.PAGOS.pagos. la presencia de ID y ACCESS indica que los usuario JEF234 y JEF587 serán incorporados a la lista de acceso estándar del perfil CONTA. aún cuando no contenga caracteres genéricos. el operando FVOLUME indica el volumen correspondiente. Si el grupo ya figuraba. se asume por defecto ALL. Ejemplos: 1) PE ‘conta. se asume por defecto que perfil2 pertenece a la misma que clase que el perfil en cuestión (DATASET. entonces la misma no se modifica. en nuestro caso).a2010. RACF ignora el operando FGENERIC si no se codificó FROM. llegando en muchos casos a su eliminación total. Si el perfil es discreto. . Su identificador de usuario debe coincidir con el HLQ del perfil.54 Tener el atributo SPECIAL a nivel de sistema. solo sería posible lograrlo mediante el uso de perfiles discretos. originalmente los únicos perfiles de dataset que admitía RACF eran los que hoy se conocen como discretos.Creación de nuevos datasets Ya hemos visto. Para poder especificar el operando FROM. y es necesaria una menor cantidad de los mismos para proteger la totalidad de los archivos. la localización de su perfil protector es más rápida en el caso de estar protegido discretamente que en el caso de estarlo genéricamente. si existieran 2 datasets de idéntico nombre (uno de ellos necesariamente descatalogado) que requirieran distinta protección. 4. los datasets se dividen en “datasets de usuario” y “datasets de grupo”. Esto es entendible.Tiene autoridad ALTER sobre tal perfil. esto significa que los archivos no protegidos por un perfil en la clase DATASET resultan inaccesibles.12 .Tiene autoridad ALTER a través de una regla en la GLOBAL. no debe caerse en el extremo de definir una cantidad tal que impacte negativamente en la performance (por ejemplo. ya que la existencia de una gran cantidad de perfiles genéricos con idéntico HLQ puede traer aparejado importantes problemas de performance. dado un archivo. debe tenerse cuidado de no abusar en este sentido. con la aparición de la posibilidad de definir perfiles de dataset genéricos. debe tener como HLQ un usuario o grupo (pues esto es requisito insalvable para perfiles). que la opción PROTECTALL de la SETROPTS está activa en modo FAIL.13 . 500 perfiles genéricos con igual HLQ no parece apropiado). y hasta aconsejable. teniendo en cuenta que los perfiles genéricos son más sencillos de administrar. la mayoría de las organizaciones fueron abandonando paulatinamente la utilización de los perfiles discretos. Por ejemplo. quien ejecuta el comando necesita adicionalmente autoridad sobre el perfil del cual se pretende copiar las listas de acceso. 4. la autoridad que se requiere para definir un nuevo perfil de dataset. Veremos ahora que autoridad exige RACF para definir un nuevo archivo. Para crear un “dataset de usuario”. Posteriormente. Por otro lado. tener autoridad ALTER sobre el perfil. al analizar el comando ADDSD. Los perfiles discretos tienen pues aún su lugar. para poder estar efectivamente protegido por RACF. Supondremos. Apuntes de RACF Juan Mautalen . . y en algunos casos particulares continúan siendo una mejor opción. se cumple alguno de los requisitos siguientes: . Ser el owner del perfil. quien lo hace debe satisfacer alguna de las condiciones que se enumeran a continuación: El dataset quedará protegido por un perfil genérico y. si bien es muy aconsejable el uso de perfiles de dataset genéricos. Por lo tanto. Recordemos que un archivo. En efecto. IBM no tiene previsto discontinuarlos en un futuro cercano. Por lo tanto. de modo que no hay ninguna razón para no utilizarlos si resultan mas apropiados para resolver una determinada situación. Básicamente.El HLQ del archivo coincide con su identificador de usuario. Volveremos sobre este punto en el capítulo dónde estudiemos en detalle las opciones de la SETROPTS.Perfiles de dataset: discretos versus genéricos Como ya se ha señalado. Tener el atributo SPECIAL a nivel de un grupo que tenga al perfil dentro de su campo de acción. para simplificar. ya que en este último caso RACF debe realizar una búsqueda de tipo secuencial hasta dar con el perfil más ajustado. Sin embargo. Para crear un “dataset de grupo”.55 Tener el atributo ADSP y el HLQ del dataset coincidir con su identificador de usuario. En este caso. . el HLQ del archivo ser un grupo dentro del campo de acción y no cumplir simultáneamente: .Estar conectado al grupo dado por el HLQ con nivel USE . . quien lo hace debe satisfacer alguna de las condiciones que se enumeran a continuación: El dataset quedará protegido por un perfil genérico y.Está conectado al grupo dado por el HLQ con autoridad CREATE o superior. se le creará automáticamente un perfil discreto. dependiendo de la existencia o no del ALIAS apropiado). Es importante recalcar que si se pretende que el dataset se catalogue. Apuntes de RACF Juan Mautalen . En este caso. Tener el atributo OPERATIONS a nivel de grupo. se le creará automáticamente un perfil discreto.Tener autoridad menor que ALTER sobre el perfil genérico que lo protegerá. Tener el atributo ADSP y el HLQ ser un grupo al cual esté conectado con autoridad CREATE o superior.Tiene autoridad ALTER sobre tal perfil. se cumple alguno de los requisitos siguientes: . Tener el atributo OPERATIONS a nivel de sistema y no cumplir simultáneamente: .Tiene autoridad ALTER a través de una regla en la GLOBAL. el usuario que lo define debe asimismo tener autoridad UPDATE sobre el catálogo correspondiente (USERCAT o MASTERCAT.Estar conectado al grupo dado por el HLQ con nivel USE .Tener autoridad menor que ALTER sobre el perfil genérico que lo protegerá. BCICSPCT. La importancia del posit value radica en el hecho de que todos los operandos del comando SETROPTS que se aplican a una clase resultan automáticamente aplicados a todas aquellas otras que comparten el mismo posit value. los usuarios con atributo SPECIAL no pueden visualizar las opciones relativas a auditoría. FCICSFCT. Para ver la configuración de un determinado parámetro. ACICSPCT. A lo largo del presente capítulo vamos a examinar en detalle las opciones de la SETROPTS. Por ejemplo.3 .OPCIONES GLOBALES DE RACF 5. Apuntes de RACF Juan Mautalen . lo cual es entendible para cuando se afrontan las primeras etapas de la construcción de un sistema. para lo cual debe tener bien en claro el significado e impacto de cada una de sus opciones. IBM otorga igual posit value a clases que están íntimamente relacionadas.Consideraciones generales Resultan de vital importancia para el funcionamiento de RACF ciertas opciones globales de configuración que se establecen y modifican a través del comando SETROPTS. Cuando RACF se instala por primera vez. DCICSDCT. Los rangos 0-18. En consecuencia. como ser todas aquellas vinculadas con un mismo producto. y puede ser modificada dinámicamente. Mostramos a continuación. comparten el posit value 5: TCICSTRN. a modo de ejemplo. SCICSTST. PCICSPSB. el comando “SETROPTS AUDIT(TCICSTRN)” no solo auditará la clase TCICSTRN sino que automáticamente hará lo propio con el resto de las clases mencionadas. ya sea provista por IBM o definida por la organización. todas las siguientes clases. MCICSPPT. KCICSJCT. relacionadas con CICS. Esta configuración se encuentra almacenada dentro de la base de RACF (en el primer bloque. no queda mas remedio que buscarlo dentro del listado completo que brinda el comando “SETR LIST”. indicando en muchos casos la configuración que consideramos más conveniente. el listado de la SETROPTS que podría tener una organización típica. HCICSFCT. JCICSJCT. UCICSTST. el administrador de RACF debe configurar adecuadamente la SETROPTS. por lo cual no debe utilizarse ningún número en alguno de estos rangos para una clase definida por la organización. En efecto.1 .Posit Value de una clase Toda clase de RACF. NCICSPPT. llamado ICB –Inventory Control Block-).56 5 . ya sea a nivel de sistema o a nivel de grupo. Sin embargo. Una adecuada configuración de la SETROPTS es fundamental para dotar a la organización de un adecuado nivel de seguridad. 5. 5. tanto desde el punto de vista administrativo como desde el de la seguridad del sistema. ECICSDCT. La configuración global por defecto es totalmente abierta y permisiva. GCICSTRN. la SETROPTS provista por IBM es a todas luces insuficiente para brindar una seguridad razonable a un entorno productivo. Varias clases pueden compartir el mismo número. el resto de los parámetros exige el atributo SPECIAL a nivel de sistema para ser modificados. Con excepción de las opciones globales relativas a auditoría. QCICSPSB. Sintaxis: SETROPTS|SETR LIST No existe la posibilidad de listar parcialmente información de la SETROPTS.Listado de la SETROPTS Para listar el contenido de la SETROPTS se requiere tener el atributo SPECIAL o AUDITOR. tiene asociado un número comprendido entre 0 y 1023. antes de empezar a utilizarlo productivamente. denominado posit value. que requieren el atributo AUDITOR a nivel de sistema. 57-127 y 528-1023 están reservados para uso exclusivo de IBM.2 . Como ya indicáramos. 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 continuación el significado de las distintas opciones. 5.4 - Estadísticas iniciales Sintaxis: SETROPTS|SETR INITSTATS|NOINITSTATS Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: INITSTATS. El parámetro INITSTATS indica que RACF guardará, en el perfil de cada usuario, las siguientes estadísticas básicas: Día y hora de la última vez que RACF verificó la identidad del usuario, valor que normalmente coincide con el día y la hora de su último logon (campo LAST-ACCESS en la salida del comando LISTUSER). Día 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 aplicación –si lo permitiera-. Varias otras opciones de la SETROPTS solo funcionan si INITSTATS está vigente (INACTIVE, REVOKE, HISTORY, WARNING). Es absolutamente recomendable tener la opción INITSTATS, que por otro lado es la que viene por defecto en una base recién inicializada. NOINITSTATS establece que RACF no guardará la información detallada previamente. 5.5 - Control de programas Sintaxis: SETROPTS|SETR WHEN(PROGRAM)|NOWHEN(PROGRAM) Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: WHEN(PROGRAM) El operando WHEN(PROGRAM) especifica que RACF activará el control de programas a través 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 más. NOWHEN(PROGRAM) es la opción por defecto en una base recién inicializada. Sin embargo, es conveniente cambiar este parámetro 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 capítulo posterior analizaremos con un poco más 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 Opción sugerida: TERMINAL(READ) Esta opción establece el UACC que asignará RACF a terminales que no estén protegidas por ningún perfil en la clase TERMINAL (o su agrupadora, GTERMINL). Sólo tiene efecto si la clase TERMINAL se encuentra activa, es decir si RACF está verificando efectivamente la autorización de usuarios sobre el uso de terminales. El valor por defecto en una base recién 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 - Auditoría de usuarios con atributo SPECIAL Sintaxis: SETROPTS|SETR SAUDIT|NOSAUDIT Autoridad requerida: AUDITOR a nivel de sistema Opción sugerida: SAUDIT Apuntes de RACF Juan Mautalen que significa special audit. cuyas ejecuciones fallidas no se registran). SAUDIT es la opción en efecto en una base recién inicializada. Por lo tanto. LISTGROUP. Por ejemplo. que nunca se registran ya que no se consideran críticos pues no realizan ninguna modificación). Definición de un nuevo recurso cuya creación esté controlada por RACF (la alocación de un nuevo dataset. sino por su presencia en la lista de acceso. que significa command violation.61 SAUDIT. se trata de un usuario que intenta ejecutar un comando de RACF que no le compete. indica que para todos los usuarios con atributo OPERATIONS (tanto a nivel de sistema como a nivel de grupo) se grabarán registros tipo 80 de SMF en las siguientes situaciones: Acceso exitoso a un recurso protegido posibilitado por el atributo OPERATIONS. Apuntes de RACF Juan Mautalen .Auditoría de usuarios con atributo OPERATIONS Sintaxis: SETROPTS|SETR OPERAUDIT|NOOPERAUDIT Autoridad requerida: AUDITOR a nivel de sistema Opción sugerida: sin sugerencia OPERAUDIT. supongamos que está OPERAUDIT en efecto. Si. por ejemplo) y que resulte exitosa gracias al atributo OPERATIONS.** que tiene UACC(NONE). debe otorgarse al usuario la autoridad necesaria para que pueda ejecutarlo exitosamente. Los intentos fallidos de ejecución de comandos de RACF deben ser analizados. CMDVIOL es la opción en efecto en una base recién inicializada. 5. LISTDSD. LISTGROUP. RLIST y SEARCH.Auditoría de violación de comandos Sintaxis: SETROPTS|SETR CMDVIOL|NOCMDVIOL Autoridad requerida: AUDITOR a nivel de sistema Opción sugerida: CMDVIOL CMDVIOL. que significa operations audit. y deben ser pocos. 5. RLIST y SEARCH. la cantidad de comandos fallidos de RACF no debería ser elevada.** con autoridad UPDATE (o superior).9 . deben tomarse las medidas que se consideren convenientes. En cualquier caso. Como los usuarios con atributo SPECIAL tienen un enorme poder dentro de la organización. que el usuario USUA tiene el atributo OPERATIONS a nivel de sistema y que intenta modificar un archivo protegido por el perfil PROD. . en este caso. indica que para todos los usuarios con atributo SPECIAL (tanto a nivel de sistema como a nivel de grupo) se grabarán registros tipo 80 de SMF cada vez que ejecuten exitosamente comandos de RACF (con excepción de los comandos LISTUSER.8 . en cambio. no por el atributo OPERATIONS. el parámetro OPERAUDIT no provocará la grabación de un registro de auditoría. Si se trata de un comando que corresponde. por lo cual aconsejamos especificar SAUDIT.Si USUA figura en la lista de acceso de PROD. LISTDSD. el acceso resulta exitoso. indica que se grabarán 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 excepción de los comandos LISTUSER. Ejecución exitosa de los comandos ADDSD y RDEFINE posibilitada por el atributo OPERATIONS. resulta aconsejable monitorear detalladamente su actividad. Si se codifica *. salvo que exista una fuerte necesidad de contar con dicha información. puede generar un volumen enorme de registros de SMF.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). todas las clases resultan afectadas (con excepción de las clases USER y GROUP). 5. Si una clase tiene AUDIT. Como ya hemos señalado. En tal caso. en cada perfil discreto se almacenará la siguiente información: . Por lo tanto. el parámetro OPERAUDIT provocará la grabación de un registro de auditoría reflejando el evento. . resulta aconsejable no tener ninguna clase bajo STATISTICS. NOOPERAUDIT sería lo más apropiado. monitorearlos a través de la opción OPERAUDIT puede ser una buena idea. Los operandos STATISTICS y NOSTATISTICS afectan no solo a la clase especificada sino también a todas aquellas otras que eventualmente compartan el mismo posit value.Fecha de la última modificación. En tal caso.**. afecta la performance negativamente. En cambio. El mantenimiento de estadísticas. activas o no.Fecha de la última referencia. si existen pocos usuarios con el atributo OPERATIONS y su actividad es reducida. No deben confundirse estas estadísticas con aquellas a las que se refiere la opción INITSTATS que analizamos previamente. Si se codifica *.Para cada entrada en la lista de acceso.Clases con estadísticas Sintaxis: SETROPTS|SETR {STATISTICS|NOSTATISTICS}(clase…|*) Autoridad requerida: SPECIAL a nivel de sistema Opción 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.10 . Sin embargo.Cantidad de veces que se accedió al recurso para cada nivel de autoridad. el usuario asociado al DFHSM). NOOPERAUDIT es la opción en efecto en una base recién inicializada. con excepciones muy puntuales Se puede especificar con el operando AUDIT|NOAUDIT las clases USER.11 . la cantidad de veces que se otorgó acceso al recurso.Clases auditadas Sintaxis: SETROPTS|SETR {AUDIT|NOAUDIT}(clase…|*) Autoridad requerida: AUDITOR a nivel de sistema Opción sugerida: AUDIT para todas las clases. Si una clase está bajo STATISTICS. RACF mantendrá un determinado conjunto de estadísticas para sus perfiles discretos. cuando la cantidad de perfiles discretos es importante. entonces se generarán registros de SMF cada vez que se ejecute un comando de RACF que afecte perfiles de esa clase (con excepción de los comandos que únicamente listan Apuntes de RACF Juan Mautalen . debe tenerse en cuenta que un usuario con este atributo y una intensa actividad (por ejemplo. todas las clases resultan afectadas. GROUP. Por lo tanto. no es aconsejable tener en la base usuarios con el atributo OPERATIONS. . 5. . DATASET o cualquier otra clase definida en la CDT. Tales estadísticas nunca se mantienen para perfiles genéricos. si la organización decide lo contrario.62 . entonces el acceso resultará exitoso debido a la autoridad ALTER que otorga implícitamente el atributo OPERATIONS sobre el perfil PROD. Si la clase a la que pertenece el perfil afectado está bajo AUDIT. Es recomendable tener activas solo las clases que resulten importantes para la organización. si una determinada clase no se encuentra activa. está en efecto la opción NOAUDIT(*). puede sacárselas de la categoría AUDIT mediante el comando “SETROPTS NOAUDIT(clase)”. las cuáles son usualmente muchas menos que las más de 230 provistas por IBM. RACF no la utiliza para controlar accesos a recursos.Clases activas Sintaxis: SETROPTS|SETR {CLASSACT|NOCLASSACT}(clase…|*) Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: depende de cada organización Se puede especificar con el operando CLASSACT|NOCLASSACT cualquier clase de recursos generales. GROUP y DATASET se encuentran siempre activas y no se las puede desactivar. lo cual se logra de manera sencilla ejecutando el comando: SETROPTS AUDIT(*) La única excepción que creemos debería valorarse es el caso de las clases relacionadas con auditoría de actividad en z/OS USS (Unix System Services). ya que no aumentan la cantidad de registros de grabados. Toda clase tiene asociado un DFTRETC (Default Return Code) especificado en la CDT. el ya mencionado parámetro SAUDIT provoca la generación de registros de SMF toda vez que ejecutan comandos de RACF. Es decir.63 información). Recomendamos tener bajo AUDIT a todas las clases de RACF. Los operandos CLASSACT y NOCLASSACT afectan no solo a la clase especificada sino también a todas aquellas otras que eventualmente compartan el mismo posit value. IPCOBJ y PROCESS). Su significado es el siguiente: Apuntes de RACF Juan Mautalen . 4 u 8. OPERAUDIT y AUDIT usados conjuntamente. Únicamente si una determinada clase se encuentra activa RACF utilizará sus perfiles para controlar el acceso a recursos. No debe pues temerse la redundancia que pueden presentar los parámetros SAUDIT. sino que se grabará un único registro. En una base de RACF recién inicializada. Para ellas. Recordemos que. luego de ejecutado el comando anterior. si está la clase DATASET bajo AUDIT. Esto debería modificarse antes de empezar a utilizar el sistema para tareas productivas. a los efectos del chequeo de autoridad de un usuario sobre un recurso. con el objeto de monitorear toda modificación sobre la base de RACF. 5. Este valor indica el código de retorno que RACF devolverá a la aplicación solicitante en caso de no encontrar un perfil que proteja el recurso en cuestión (suponiendo que la clase se encuentre activa). Las clases USER. que puede ser 0. pero ello no significa de ninguna manera que no se puedan definir. una clase inactiva no cumple ninguna función. no se generarán dos registros distintos por el mismo evento. lo cual significa que ninguna clase está bajo AUDIT.12 . es conveniente auditar todas las clases. También grabarán registros las solicitudes de DEFINE para esa clase (por ejemplo. toda alocación de un nuevo archivo). Para los usuarios con atributo SPECIAL. Alrededor de 60 clases activas suele ser suficiente para una organización promedio. Los operandos AUDIT y NOAUDIT afectan no solo a la clase especificada sino también a todas aquellas otras que eventualmente compartan el mismo posit value. Por lo tanto. modificar o borrar perfiles. pues pueden generar un gran volumen de registros de poca utilidad (Ej: FSOBJ. recordemos que es siempre la aplicación la que autoriza o rechaza una solicitud de acceso. con lo cual la inexistencia de un perfil protector del recurso deja en manos de la aplicación la decisión de otorgar o rechazar el pedido de acceso. independientemente de su DFTRETC (con excepción de USER. la opción NOGENERIC significa que RACF no considerará sus perfiles genéricos a la hora de decidir sobre un requerimiento de acceso. deben definirse los perfiles apropiados y activar las clases necesarias. Por lo tanto. Activar una clase con DFTRETC igual a 8. lo cual significa que para ninguna clase se toman en cuenta perfiles genéricos para decidir sobre requerimientos de Apuntes de RACF Juan Mautalen . En una base recién inicializada. La mayoría de las clases tienen un DFTRETC igual a 4. el comando “SETROPTS NOCLASSACT(*)” inactiva todas las clases.” El comando “SETROPTS CLASSACT(*)” activa todas las clases con excepción de aquellas cuyo DFTRETC sea igual a 8. los eventuales perfiles genéricos de la clase no cumplen función alguna en el momento de otorgar o denegar una solicitud de acceso. si la clase está activa. no admitan perfiles genéricos (SECLABEL.64 0 4 8 El requerimiento de acceso se acepta Se informa a la aplicación que no existe perfil protector El requerimiento de acceso se rechaza En cualquier caso. Por tal motivo. está en efecto la opción NOCLASSACT(*). En cambio. excepto las clases agrupadoras (GDASDVOL o GTERMINL.13 . activar una clase es una acción de suma importancia. 5. sin antes definir adecuadamente todos los perfiles necesarios. Authorization checks might fail. está en efecto la opción NOGENERIC(*). GROUP y DATASET). Existen algunas clases cuyo DFTRETC es 8 (JESSPOOL. puede acarrear graves inconvenientes de acceso. Naturalmente. por ejemplo). claro está. En una base de RACF recién inicializada. Por lo tanto. GROUP y DATASET). por ejemplo). también utilizará los perfiles discretos que existan. En cualquier caso. La opción GENERIC para una clase indica que RACF tendrá en cuenta sus eventuales perfiles genéricos para responder sobre un requerimiento de acceso. RACF emite el siguiente mensaje informativo al momento de su activación: “ICH14073I WARNING: Class class-name was activated by the SETROPTS command.Clases con perfiles genéricos Sintaxis: SETROPTS|SETR {GENERIC|NOGENERIC}(clase…|*) Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: depende de cada organización Se puede especificar con el operando GENERIC|NOGENERIC la clase DATASET o cualquier clase de recursos generales. por ejemplo) y aquellas que. Aún cuando reciba un código de retorno 0 u 8. la aplicación puede no cumplir con las directivas de RACF (aunque esto es muy poco frecuente). de USER. lo cual significa que ninguna clase está activa (con excepción. Los operandos GENERIC y NOGENERIC afectan no solo a la clase especificada sino también a todas aquellas otras que eventualmente compartan el mismo posit value (con excepción de las eventuales clases agrupadoras). según su definición en la CDT. En tales casos. aquellos recursos no protegidos resultan inaccesibles. En cambio. y no debe hacerse sin tener bien en claro su funcionamiento y alcance. en este caso. antes de empezar a utilizar el sistema para tareas productivas. Apuntes de RACF Juan Mautalen . en un espacio compartido accesible por las distintas aplicaciones. excepto las clases agrupadoras (GDASDVOL o GTERMINL.15 . las clases tienen definidos tanto perfiles genéricos como discretos. modificar o deletear perfiles genéricos existentes. no admitan perfiles genéricos (SECLABEL. si se codifica la opción NOGENERIC. en lugar de existir una copia del perfil genérico en cada address space que lo requiera. A veces resulta necesario desactivar momentáneamente el chequeo de perfiles genéricos para determinada clase. ya que resulta mucho más rápido acceder a un perfil en memoria que buscarlo en la base de RACF residente en disco a través de un costoso I/O. En una situación normal. 5. En virtud de esto. La opción GENCMD para una clase indica que RACF permitirá procesar comandos que afecten a sus perfiles genéricos. será necesario reemplazar la versión desactualizada almacenada en memoria mediante la ejecución del comando: SETROPTS GENERIC(clase) REFRESH No todas las clases admiten esta opción. si es posible. Se aconseja especificar GENCMD para todas las clases activas que admitan perfiles genéricos. y permanecerá allí de modo que cualquier otra aplicación pueda utilizarlo sin tener que extraerlo nuevamente de la base. Siempre que sea posible utilizarlos. Los operandos GENCMD y NOGENCMD afectan no solo a la clase especificada sino también a todas las otras que eventualmente compartan el mismo posit value (con excepción de las eventuales clases agrupadoras). Usualmente. Por lo tanto.14 . por ejemplo). automáticamente se le aplica también el operando GENCMD. Esto no solo ahorra espacio en memoria sino que eventualmente mejora la performance. pero las mismas que bajo GENERIC Se puede especificar con el operando GENCMD|NOGENCMD la clase DATASET o cualquier clase de recursos generales. pero mantener al mismo tiempo la posibilidad de definir. y la misma es excluyente con la opción RACLIST que veremos a continuación. los perfiles genéricos facilitan la administración. el comando “SETROPTS NOGENERIC(clase) GENCMD(clase)” permite realizar las tareas de mantenimiento deseadas. por ejemplo) y aquellas que. NOGENCMD no se aplica de manera automática. 5. En la CDT está indicado qué clases admiten este parámetro.Clases con comandos genéricos Sintaxis: SETROPTS|SETR {GENCMD|NOGENCMD}(clase…|*) Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: depende de cada organización. Por el contrario. el listado de clases bajo GENERIC y GENCMD debería ser idéntico. en cuyo caso suele ser mas ventajoso. se lo copiará a un sector común de la memoria la primera vez que se lo necesite. según su definición en la CDT. está en efecto la opción NOGENCMD(*). En efecto. En tal caso.65 acceso. RACLISTearlas en lugar de ponerlas bajo GENLIST. se aconseja especificar GENERIC para todas las clases activas que admitan perfiles genéricos. En una base de RACF recién inicializada. En contrapartida. resulta frecuente no tener ninguna clase GENLISTeada.Clases con perfiles genéricos compartidos en memoria (GENLISTeadas) Sintaxis: SETROPTS|SETR {GENLIST|NOGENLIST}(clase…) Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: ninguna clase La opción GENLIST establece que los perfiles genéricos de la clase se cargarán en memoria. Si se especifica GENERIC para una clase. cada vez que se modifique un perfil genérico de la clase bajo GENCMD. en un sector compartido (data space) que estará disponible para las distintas aplicaciones. Esto se analizará en detalle en un capítulo posterior. para una clase dada. Apuntes de RACF Juan Mautalen . En una base de RACF recién inicializada. ya que existen seguramente archivos de uso público muy frecuente (catálogos de usuario.Clases en la GLOBAL Sintaxis: SETROPTS|SETR {GLOBAL|NOGLOBAL}(clase…|*) Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: DATASET + otras que la organización considere apropiadas Se puede especificar con el operando GLOBAL|NOGLOBAL la clase DATASET o cualquier clase de recursos generales. Cada vez que se modifique un perfil -genérico o discreto. al cargarse la información de sus perfiles en memoria ésta se combina con la contenida en los perfiles de la clase agrupadora. será necesario actualizar la información almacenada en memoria ejecutando el comando: SETROPTS RACLIST(clase) REFRESH De todos modos. Como ya mencionáramos. En una base de RACF recién inicializada. Los operandos GLOBAL y NOGLOBAL afectan no solo a la clase especificada sino también a todas aquellas otras que tengan idéntico posit value (con excepción de las eventuales clases agrupadoras). 5. por ejemplo).16 .17 . es decir que para ninguna clase RACF procesa la información de la GLOBAL.Clases con perfiles genéricos y discretos compartidos en memoria –RACLISTeadasSintaxis: SETROPTS|SETR {RACLIST|NORACLIST}(clase…) Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: todas las clases activas que lo admitan (salvo que sean de muy poco uso) La opción RACLIST establece que los perfiles genéricos y discretos de la clase se cargarán en memoria. es decir que ninguna clase se encuentra bajo GENLIST. si la correspondiente “clase de miembros” (member class) está RACLISTeada. está en efecto la opción NOGENLIST(*). sino también a todas las otras que tengan el mismo posit value y sean pasibles de ser GENLISTeadas. Veremos de manera precisa en un capítulo posterior de qué manera actúa la clase GLOBAL en el proceso de chequeo de autoridad de un usuario sobre un recurso. RACF informa con un mensaje por pantalla que los cambios no serán reflejados hasta que el comando de REFRESH haya sido ejecutado. por ejemplo). en cuyo caso una regla apropiada en la GLOBAL puede mejorar sensiblemente la performance. Sólo las clases que tienen RACLIST=ALLOWED especificado en la CDT pueden ser RACLISTeadas. RACLIST y GENLIST son operandos excluyentes.de una clase RACLISTeada.66 Los operandos GENLIST y NOGENLIST afectan no solo a la clase especificada. excepto las clases agrupadoras (GDASDVOL o GTERMINL. el comando de REFRESH debe ejecutarse especificando la “clase de miembros”. está en efecto la opción NOGLOBAL(*). Es altamente recomendable tener al menos la clase DATASET bajo GLOBAL. por ejemplo). Si una clase está bajo GLOBAL en la SETROPTS. Aún si se modificó información de un perfil de una clase agrupadora. ello significa que RACF utilizará la información del perfil correspondiente de la clase GLOBAL para eventualmente otorgar un acceso solicitado. De todos modos. 5. No se puede especificar RACLIST para una clase agrupadora (GCICSTRN o VCICSCMD. la primera región CICS que se levanta se encarga de RACLISTear ambas clases. aparece un listado de clases bajo el rótulo “GLOBAL=YES RACLIST ONLY”. sino que las ha RACLISTeado alguna aplicación que las utiliza.67 Los operandos RACLIST y NORACLIST afectan no solo a la clase especificada. 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. Si se ejecutara el comando “SETROPTS LIST” en un momento en que ninguna región CICS se encuentre activa. RACF no informa la necesidad de ejecutar el comando de REFRESH si se quiere que tome efecto una modificación. En una base de RACF recién inicializada ninguna clase está RACLISTeada. Apuntes de RACF Juan Mautalen .18 . En el ejemplo que nos ocupa. de no ser por la necesidad de refrescar los perfiles cada vez que se efectúa alguna modificación). ambas relacionadas con CICS. suponiendo que estén 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. En cambio. como sí lo hace en el caso de aquellas RACLISTeadas por comando. Mas allá de esta diferencia. el hacerlo o no es una decisión que debe tomar cada organización. en caso de estar activas. GLOBAL=YES Si observamos la salida del comando “SETROPTS LIST”. resulta sin duda conveniente RACLISTearla. Las siguientes clases provistas por IBM. no se gana demasiado RACLISTeándola (aunque tampoco resultaría perjudicial hacerlo. las clases RACLISTeadas de este modo se comportan de manera idéntica a aquellas que lo han sido a través del comando “SETROPTS RACLIST(clase)”. vemos que a continuación del listado de las clases RACLISTeadas con el comando “SETROPTS RACLIST(clase)”. si se trata de una clase con perfiles utilizados con relativa frecuencia. para las clases bajo “GLOBAL=YES RACLIST ONLY”. 5. En nuestro ejemplo. figuran allí las clases TCICSTRN y CCICSCMD. Esta configuración inicial debe cambiarse de acuerdo a lo señalado en el párrafo anterior.Clases RACLISTeadas vía RACROUTE REQUEST=LIST. sino también a todas las otras que eventualmente compartan el mismo posit value (y sean pasibles de ser RACLISTeadas). Estas clases no han sido RACLISTeadas por un administrador de RACF con atributo SPECIAL. Una diferencia que vale la pena mencionar es que. Si se trata de una clase con muy poca actividad. entonces ninguna de estas clases aparecería RACLISTeada. aunque un determinado perfil tenga especificado únicamente FAILURES(READ) como opción de auditoría. Por lo tanto. no se grabará ningún registro. el nivel de auditoría sobre ciertos eventos (en algunos casos al Apuntes de RACF Juan Mautalen . a través de la SETROPTS. Por ejemplo. En este caso. se generarán registros para todo acceso exitoso y los intentos fallidos de UPDATE (o superior). que si bien no admiten perfiles.68 5. NEVER establece que ningún acceso que involucre la consulta de un perfil de la clase generará un registro de auditoría. aún cuando los perfiles tengan opciones de auditoría que indiquen lo contrario. si un perfil tiene especificado únicamente SUCCESS(UPDATE) y la clase está bajo LOGOPTIONS(FAILURES). basta con asignarle el nuevo.. y controlar el nivel de auditoría a través de las opciones propias de los perfiles. se grabarán registros aún para los accesos exitosos (a cualquier nivel). Una excepción son ciertas clases relacionadas con z/OS USS.Opciones de logging para clases Sintaxis: SETROPTS|SETR LOGOPTIONS(nivel(clase…). Cada clase puede tener un único nivel de LOGOPTIONS. En este caso. que involucre la consulta de un perfil de la clase. generará un registro de auditoría. si un perfil tiene especificado únicamente FAILURES(UPDATE) y la clase está bajo LOGOPTIONS(SUCCESSES). al igual que para SUCCESSES.19 . sino también a todas aquellas otras que eventualmente compartan el mismo posit value. ALLWAYS tiene prioridad sobre la configuración de auditoría que tenga cada perfil. exitoso o fallido. Recomendamos mantener esta configuración. Por ejemplo. FAILURES determina que se generará un registro de auditoría por cada acceso fallido que involucre la consulta de un perfil de la clase. Su significado es el siguiente: ALLWAYS indica que todo acceso a un recurso. permiten controlar. todas las clases se encuentran bajo LOGOPTIONS(DEFAULT). para cambiar el nivel de una determinada clase. este nivel de auditoría se agrega al propio del perfil. Por lo tanto. NEVER tiene prioridad sobre la configuración de auditoría a nivel de perfil. El operando LOGOPTIONS afecta no solo a la clase especificada. Los posibles niveles son: ALLWAYS NEVER SUCCESSES FAILURES DEFAULT El nivel especificado determina qué tipo de intentos de acceso se pretende registrar en SMF.) Autoridad requerida: AUDITOR a nivel de sistema Opción 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. si la clase se encuentra bajo LOGOPTIONS(ALLWAYS). este nivel de auditoría se agrega al que ya tiene especificado el perfil. se generarán registros para todo acceso fallido y todo intento exitoso de UPDATE (o superior). Por lo tanto.. SUCCESSES indica que se generará un registro auditoríapor cada acceso exitoso que involucre la consulta de un perfil de la clase. En una base recién inicializada. DEFAULT indica que el nivel de auditoría sobre un recurso estará dado por el establecido en su perfil protector. se encuentra en efecto la opción NOEGN. Resulta conveniente modificar esta opción. una opción a considerar. En una base recién inicializada. Esto elimina de raíz la posibilidad de que algún usuario genere de manera automática perfiles discretos. el significado del * en perfiles genéricos de dataset varía con respecto al que tiene cuando EGN está activa (no entraremos en detalles al respecto). recomendamos cambiarla por NOADSP. 5. la clase FSSEC permite auditar las modificaciones sobre los permisos de archivos y directorios del z/OS USS. 5. Por ejemplo. y en otros mediante LOGOPTIONS). Como ya hemos señalado. las opciones ADSP|NOADSP a nivel de la SETROPTS resultan equivalentes.Protección automática de datasets Sintaxis: SETROPTS|SETR ADSP|NOADSP Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: NOADSP La opción NOADSP de la SETROPTS establece que RACF no aplicará la “protección automática de datasets” aún para aquellos usuarios que tengan el atributo ADSP (a nivel de sistema o a nivel de grupo). pero solo será aplicada para los usuarios que tengan efectivamente el atributo ADSP. Por lo tanto.20 . Especificar LOGOPTIONS(ALLWAYS) para FSSEC podría ser. Apuntes de RACF Juan Mautalen . y se refiere a la posibilidad de emplear el símbolo ** en perfiles de dataset (y entradas en la GLOBAL para reglas de DATASET). la opción ADSP en la SETROPTS indica que la “protección automática de datasets” está globalmente activa. el uso del ** hace realmente más cómoda la administración de perfiles genéricos de dataset. si se han definido perfiles conteniendo ** (con la opción EGN activa. En este caso. ya que ello provocaría sin duda problemas y confusión en la protección de datasets. El uso del ** en perfiles de recursos generales está siempre permitido y no guarda ninguna relación con este parámetro. se encuentra activa la opción ADSP. el listado de la SETROPTS muestra la leyenda: AUTOMATIC DATASET PROTECTION IS NOT IN EFFECT Por el contrario. por lo cual recomendamos activar la opción EGN. por lo tanto. En cualquier caso. naturalmente). La opción EGN|NOEGN afecta únicamente a la clase DATASET.21 . Debido a la ya comentada tendencia a utilizar exclusivamente perfiles genéricos de dataset.Uso del ** en perfiles genéricos de dataset Sintaxis: SETROPTS|SETR EGN|NOEGN Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: EGN EGN significa Enhanced Generic Naming. La opción EGN activa en la SETROPTS se manifiesta a través de la siguiente leyenda: ENHANCED GENERIC NAMING IS IN EFFECT En una base recién inicializada. debe tenerse cuidado en no cambiar con posterioridad a la opción NOEGN.69 ponerlas bajo AUDIT. En el caso de estar en efecto la opción NOEGN. si ningún usuario tiene el atributo ADSP. se encuentra en efecto la opción NOREALDSN. ya que debe evitarse la exposición de passwords en texto claro. Esto permite. A menos que exista una fuerte necesidad al respecto. Por el contrario. tanto en los registros de SMF como en los mensajes de operador.70 5. la ausencia de un usuario no impide que el job se ejecute.Nombres reales de dataset Sintaxis: SETROPTS|SETR REALDSN|NOREALDSN Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: REALDSN Ya sea a través de la implementación de una “tabla de convención de nombres” (naming convention table) o mediante la implementación de una exit apropiada. caben las siguientes posibilidades: La tarjeta job contiene explícitamente usuario y password. usuarios por defecto Existen varias opciones en la SETROPTS relativas a JES. La opción REALDSN establece que. entonces cancela. si la opción en efecto es NOREALDSN. Se trata de la opción más frecuente. el nombre real de los archivos. ya que ello complica la administración.22 . EARLYVERIFY. no utiliza una “tabla de convención de nombres” o exits que modifiquen.23 . Si NOBATCHALLRACF está en efecto. tal como recomendamos. por ejemplo al utilizar el comando SUBMIT de TSO. se puede convertir el nombre real de un archivo antes de que sea pasado a RACF. proteger archivos cuyos nombres reales no tengan una nomenclatura admitida por RACF. La opción REALDSN activa en la SETROPTS se manifiesta a través de la siguiente leyenda: REAL DATA SET NAMES OPTION IS ACTIVE En una base recién inicializada. A tal efecto. 5. con miras al chequeo de seguridad. aún cuando el mismo haya sido modificado a los efectos del chequeo de autoridad.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. Esta opción es poco recomendable. Naturalmente. el nombre mostrado en ambos casos no será el real sino el modificado que recibe RACF. por ejemplo. que describimos brevemente a continuación: BATCHALLRACF exige que todo job batch tenga una identidad válida. Aconsejamos cambiar por la opción REALDSN. Las credenciales se reciben propagadas. es probable que encuentre problemas de autorización si trata de acceder a recursos Apuntes de RACF Juan Mautalen . y quién submite tiene la autorización apropiada en la clase SURROGAT para ejecutar jobs en nombre del usuario de ejecución. La tarjeta job solo tiene especificado usuario. se mostrará el nombre real del archivo. XBMALLRACF. Si el job no tiene una identidad válida de RACF. no se aconseja de ninguna manera convertir los nombres de los archivos que se le comunican a RACF. aún cuando esto resulta irrelevante si la organización. La opción NJEUSERID define el usuario que se asignará a los jobs o sysouts que reciba el sistema y no tengan RTOKEN u UTOKEN.Protect-all Sintaxis: SETROPTS|SETR PROTECTALL(FAILURES|WARNING)|NOPROTECTALL Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: PROTECTALL(FAILURES) Se trata de una opción sumamente importante. definir archivos desprotegidos. salvo en alguna de las situaciones siguientes: El usuario tiene el atributo SPECIAL a nivel de sistema. Existe una entrada en la GLOBAL que autoriza el acceso. NOEARLYVERIFY y NOXBMALLRACF. EARLYVERIFY hace referencia a un control de usuario. sin embargo. En cualquier caso. El acceso lo solicita una started task que está marcada como TRUSTED o PRIVILEGED. se encuentran en efecto las opciones NOBATCHALLRACF. El usuario no puede. independientemente de la codificación de este parámetro en la SETROPTS. password y grupo que efectúa JES invocando a la SAF en caso de no recibir información propagada. Recomendamos activar los 3 tipos de control (aunque en el caso de EARLYVERIFY. En una base recién inicializada. se autoriza el acceso pero no se envía ningún mensaje informativo. Existen 3 seteos posibles. El valor por defecto en una base recién inicializada es ????????. Por lo tanto. que describimos a continuación: PROTECTALL en FAILURES indica que RACF no permitirá definir ni acceder a archivos que no se encuentre protegidos por algún perfil de dataset (los archivos temporarios generados por el sistema quedan exceptuados). el usuario que se especifique no debe existir en la base de RACF. Apuntes de RACF Juan Mautalen . si se desea cambiarlo. se envía un mensaje al usuario informando que el archivo se encuentra desprotegido. si bien se autoriza el acceso. el usuario que se especifique no debe existir en la base de RACF. 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. si se desea cambiarlo. EARLYVERIFY|NOEARLYVERIFY se ha convertido en una opción irrelevante. En este caso. el cual sugerimos conservar. La opción UNDEFINEDUSER establece el usuario que se asignará a los jobs locales que ingresen al sistema sin un usuario asociado. los datasets “no protegidos” resultan inaccesibles.24 . el cual sugerimos conservar. 5. que establece cómo se comportará RACF cuando se pretenda definir o acceder a archivos no protegidos por ningún perfil de dataset. XBMALLRACF es idéntico a BATCHALLRACF pero para jobs que se ejecutan bajo el Execution Batch Monitor. En cualquier caso. es actualmente irrelevante). El valor por defecto en una base recién inicializada es ++++++++. En este caso. Este parámetro solo afecta a la clase DATASET. Con esta configuración.71 protegidos para los cuales ni la GLOBAL ni el UACC del perfil protector son suficientes para otorgar el acceso solicitado. En el listado de la SETROPTS. Con las versiones actuales de JES esto se realiza siempre. Esta opción es totalmente desaconsejada para un entorno productivo. esta opción resulta sumamente útil en las etapas iniciales de la construcción de la base de RACF. si el chequeo en la clase DATASET está inhibido. lo autoriza y remite. RACF. pues permite identificar e ir protegiendo paulatinamente los archivos en uso que se encuentran desprotegidos. tener la clase TAPEVOL inactiva y habilitar el chequeo de autoridad sobre archivos en cartucho en la clase DATASET a través de la configuración del miembro DEVSUPxx residente en la PARMLIB. NOTAPEDSN establece que RACF no controlará el acceso a archivos en cartuchos mediante perfiles de dataset (excepto que se habilite este chequeo a través del miembro DEVSUPxx de la PARMLIB). 5. Se recomienda la opción PROTECTALL en modo FAILURES. Existe una importante relación entre esta opción y la clase TAPEVOL. pueden protegerse globalmente los volúmenes mediante perfiles en la clase TAPEVOL. NOPROTECTALL implica que cualquier usuario puede acceder a archivos “no protegidos” con el máximo nivel de autoridad. sin causar interrupciones en las tareas.26 . Recomendamos NOTAPEDSN. CURRENT OPTIONS: PROTECT-ALL FAIL OPTION IS IN EFFECT indica que está activa la opción PROTECTALL en modo FAILURES. de manera similar a como lo hace para datasets en disco. se encuentra en efecto la opción NOTAPEDSN. se encuentra vigente la opción NOPROTECTALL.25 . que debe estudiarse cuidadosamente para comprender exactamente su alcance. pero con una diferencia fundamental. Luego de un tiempo prudencial. ya que mientras RACF tiene PROTECTALL en modo WARNING. Se debe ser cuidadoso. En nuestro ejemplo. A diferencia del modo WARNING. así como también definir nuevos archivos desprotegidos. tanto al usuario como al SYSLOG. Sin embargo. se debe cambiar al modo FAILURES. un mensaje informando que archivo no se encuentra protegido. En nuestro ejemplo. no ahondaremos en ello en la presente guía. la leyenda: PROTECT-ALL IS ACTIVE. que robustece notablemente la seguridad del sistema.72 PROTECTALL en WARNING funciona de manera similar al modo FAILURES. los archivos “no protegidos” pueden ser accedidos por cualquier usuario con el máximo nivel de autoridad. De todos modos.Período de retención para archivos en cartucho Sintaxis: SETROPTS|SETR RETPD(valor) Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: depende de la organización Apuntes de RACF Juan Mautalen . Sin embargo. como muestra la siguiente leyenda en el listado de la SETROPTS: TAPE DATA SET PROTECTION IS INACTIVE En una base recién inicializada. pasado el cual se estima que ya se han identificado todos los archivos en uso.Protección de archivos en cartucho Sintaxis: SETROPTS|SETR TAPEDSN|NOTAPEDSN Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: NOTAPEDSN La opción TAPEDSN indica que RACF controlará el acceso a archivos en cartuchos a través de perfiles en la clase DATASET. se encuentra establecida la opción NOTAPEDSN. ningún mensaje de alerta es generado. en lugar de rechazar el pedido. En una base recién inicializada. 5. Si se especifica ERASE sin ningún parámetro. y puede degradar la performance. al mismo tiempo que lo descataloga (o sea. los datos del archivo deleteado siguen presentes. ERASE(NOSECLEVEL) indica que RACF no tendrá en cuenta el SECLEVEL del perfil protector para determinar si debe procederse o no al borrado físico del archivo. En cambio. cuando se elimina un archivo en disco. o el valor reservado 99999 que indica que la protección nunca expira. El RETPD especificado en la SETROPTS solo actúa si se encuentra activa la opción TAPEDSN. Sin embargo. CURRENT OPTIONS: ERASE-ON-SCRATCH BY SECURITY LEVEL IS INACTIVE Apuntes de RACF Juan Mautalen . En este caso. El espacio ocupado por el archivo queda entonces disponible para un futuro dataset. y únicamente codificar ERASE=YES para perfiles de dataset que protejan archivos altamente confidenciales. En caso contrario. el valor que asume por defecto es NOSECLEVEL. para no complicar la administración. Como no aconsejamos. Si el perfil protector tiene especificado ERASE=YES pero su SECLEVEL es inferior al valor de la SETROPTS. que consiste en físicamente sobrescribirlo con ceros binarios. Se trata de una medida de seguridad extrema. el sistema borra la entrada correspondiente de la VTOC del volumen dónde reside. contados desde el día de creación del archivo. solo que no resultan accesibles por los medios habituales. o la extensión de uno existente. 5. el archivo no es borrado físicamente al ser deleteado. En nuestro ejemplo. resulta irrelevante. el valor por defecto es 0. Si se activa TAPEDSN. el uso de “niveles de seguridad”. Sin embargo. Se puede codificar cualquier valor comprendido entre 0 y 65533. esto resulta costoso. elimina su entrada del catálogo dónde se esté catalogado). que garantice la irrecuperabilidad de los datos luego del borrado lógico del archivo. y no se especifica un RETPD. solo aplicable a datasets en cartucho. el factor determinante para esta decisión pasa a ser el valor del campo ERASE del perfil. ésta es la opción establecida. determina la cantidad de días en que la protección permanecerá vigente.73 El período de retención. El valor establecido en la SETROPTS se aplicará por defecto. por lo cual solo estaría justificado para el caso de información altamente sensible. independientemente de lo que indique el campo ERASE del perfil protector. no recomendamos tampoco la implementación de esta opción. también resulta irrelevante el valor del campo ERASE del perfil de dataset. Esto incluye también a los datasets temporarios. Recomendamos establecer esta opción. como lo muestra la leyenda: ERASE-ON-SCRATCH IS ACTIVE. Veremos a continuación las distintas opciones posibles: ALL establece que se deben borrar físicamente todos los archivos que se borren. siempre que no se establezca un valor específico para el archivo. que realmente no se justifica en absoluto y puede impactar negativamente en la performance del sistema. hasta que efectivamente se grabe allí nueva información.Borrado físico de archivos Sintaxis: SETROPTS|SETR ERASE(ALL|SECLEVEL(nivel)|NOSECLEVEL)|NOERASE Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: ERASE(NOSECLEVEL) En general. La opción ERASE de la SETROPTS permite establecer en qué casos se desea un borrado físico de un archivo (solo se aplica a datasets en disco).27 . ERASE(SECLEVEL(nivel)) indica que se debe proceder al borrado físico de todos aquellos archivos que se deletean y cuyo perfil protector tenga un SECLEVEL (security level) mayor o igual al especificado. Existe la posibilidad de tomar una medida de seguridad adicional. no parece conveniente hacer uso de archivos que tengan un único calificador. Con esta opción activa. y no deben existir ni archivos ni perfiles de dataset cuyo HLQ sea ese grupo.29 .28 . En cualquier caso. Apuntes de RACF Juan Mautalen . se vuelve básicamente irrelevante. RACF no solo considerará el “actual grupo de conexión” del usuario sino todos los grupos a los cuales se encuentre conectado (con una conexión no revocada). independientemente del valor del campo ERASE del perfil protector. Esta es la opción vigente en nuestro ejemplo. La opción PREFIX(grupo) establece un prefijo que se antepondrá como HLQ. solo a los efectos del chequeo por parte de RACF. En tal caso. Es la opción ampliamente preferida en la actualidad. sugerimos asimismo establecer NOPREFIX.74 NOERASE indica que en ningún caso se procederá al borrado físico de los archivos. ya que simplifica la tarea al usuario. El valor especificado en el operando PREFIX debe ser un grupo existente en la base de RACF. 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 recién inicializada. para evitar este tipo de disquisiciones. 5. Si la opción EGN está activa. En consecuencia. RACF no permite proteger archivos que tengan un único calificador. 5. a los efectos del chequeo de autoridad. si la organización tiene tales archivos.**. ya que realmente presenta varios inconvenientes y ninguna ventaja evidente. sin resignar en absoluto aspectos de seguridad del sistema. entonces solo el “actual grupo de conexión” del usuario es tenido en cuenta por RACF en el proceso de chequeo de autoridad. como se deduce de la leyenda siguiente: LIST OF GROUPS ACCESS CHECKING IS ACTIVE Si la opción NOGRPLIST está activa.Archivos de un único calificador Sintaxis: SETROPTS|SETR PREFIX(grupo)|NOPREFIX Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: NOPREFIX Si la opción NOEGN se encuentra activa. NOPREFIX no establece ningún prefijo. para aquellos archivos que tengan un único calificador.Lista de grupos Sintaxis: SETROPTS|SETR GRPLIST|NOGRPLIST Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: GRPLIST GRPLIST establece que. En nuestro ejemplo. existe la posibilidad de protegerlos especificando un PREFIX en la SETROPTS. Como recomendamos tener la opción EGN activa. el dataset ARCH1 puede protegerse por el perfil genérico ARCH1. GRPLIST se encuentra en efecto. NOERASE es el valor que se encuentra vigente en una base de RACF recién inicializada. por lo que considero que se mantiene la posibilidad de establecer NOGRPLIST únicamente para mantener una compatibilidad hacia atrás. por lo cual no tiene sentido especificar un PREFIX en la SETROPTS. para determinar la autoridad de un usuario sobre un recurso. el “grupo de conexión”. el usuario no debe preocuparse por el grupo que especifica en la pantalla de logon a las aplicaciones. Antiguamente no existía la opción GRPLIST. NOGRPLIST es la opción que se encuentra en efecto en una base de RACF recién inicializada. la inactividad se calcula en relación a la fecha de creación. el nuevo perfil de dataset será creado en base al modelo existente. Un valor entre 30 y 60 días suele ser razonable. Por ejemplo. MODEL(NOGDG) indica que RACF no tendrá un tratamiento especial para los GDG-datasets. NOINACTIVE establece que RACF no revocará usuarios automáticamente por inactividad. o se inicia la ejecución de un job. RACF examirará el perfil del grupo para ver si tiene especificado un perfil modelo. Si la diferencia entre ambas fechas excede el valor especificado para revocación automática por inactividad en la SETROPTS. Recomendamos la opción NOGDG y proteger todos los GDG-datasets mediante un único perfil genérico. Esta es la opción vigente en una base recién inicializada. no solo mediante el logon efectivo del usuario. se establece en qué casos se desea utilizar la modelización de perfiles de dataset. si el parámetro INACTIVE especifica 30 días y un usuario lleva 31 días de inactividad. 5.). entonces RACF revoca al usuario. Para los usuarios que nunca ingresaron al sistema (el comando LISTUSER muestra LAST-ACCESS = UNKNOWN). hasta tanto no intente ingresar no será efectivamente revocado.30 .Revocación automática por inactividad Sintaxis: SETROPTS|SETR INACTIVE(valor)|NOINACTIVE Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: INACTIVE(40) El valor codificado en el operando INACTIVE establece la cantidad consecutiva de días de inactividad pasados los cuales RACF revoca automáticamente al usuario. Debe estar comprendido entre 1 y 255. con una cantidad que sea adecuada a las necesidades de la organización. El chequeo que lleva a cabo RACF es el siguiente: Cada vez que un usuario se loguea a alguna aplicación (TSO. IMS. tal cual lo muestra la siguiente leyenda: INACTIVE USERIDS ARE BEING AUTOMATICALLY REVOKED AFTER 40 DAYS.Modelización de perfiles de dataset Sintaxis: SETROPTS|SETR MODEL([GDG|NOGDG] [GROUP|NOGROUP] [USER|NOUSER])|NOMODEL Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: depende de cada organización Mediante el operando MODEL. RACF compara la fecha actual del sistema con la fecha que figura en el campo LASTACCESS del perfil del usuario. CICS. sino que los tratará del mismo modo que a cualquier otro archivo.75 5. Recordemos que el campo LAST-ACCESS del perfil del usuario puede modificarse. como ya viéramos en el capítulo de administración de usuarios. MODEL(GROUP) establece que cada vez que se defina un “perfil de dataset de grupo”. En nuestro ejemplo. RACF revoca al usuario por inactividad cuando efectivamente intenta acceder al sistema. el valor fijado es de 40 días. sino también en otras circunstancias. MODEL(GDG) establece que RACF intentará proteger miembros de un GDG (Generation Data Group) que estén RACF-indicados usando un perfil de dataset cuyo nombre coincida con el nombre base del GDG. Podríamos decir que tal usuario se encuentra “pendiente de revocación”. Esto permite que nuevos perfiles.31 . etc. En caso afirmativo. tomen las características de un “perfil modelo” existente. al ser definidos. Apuntes de RACF Juan Mautalen . Recomendamos especificar la opción INACTIVE. crackear la password de un usuario no significa que se haya igualmente crackeado a otros que puedan eventualmente tener su misma password. RACF examinará el perfil del usuario para ver si tiene especificado un perfil modelo. WARNING(5) La password de un usuario se almacena en su perfil. MINCHANGE(1). el nuevo perfil de dataset será creado en base al modelo existente. ni ninguna de las últimas 15 que haya utilizado. NOMODEL establece que no se aplicará modelización de perfiles de dataset en ninguno de los 3 casos (GDG. y si el valor resultante coincide con el almacenado la autenticación es exitosa. 5. no podrá especificar.Opciones relativas a PASSWORD Sintaxis: SETROPTS|SETR PASSWORD([HISTORY(valor)|NOHISTORY] [INTERVAL(valor)] [MINCHANGE(valor)] . USER DATA SET MODELLING IS BEING DONE. REVOKE(5) LLLLLLLL.76 MODEL(NOGROUP) indica que no se aplicarán modelos para “perfiles de dataset de grupo”. En tal caso. El valor del operando HISTORY debe estar comprendido entre 1 y 32. debe destacarse que RACF no encripta la password propiamente dicha. GROUP y USER). Esto es -suponiendo que se tenga esta opción en 15. RACF reencripta el usuario con la password recibida. INTERVAL(30). Tampoco está presente en la bajada plana de la base que se obtiene a través del utilitario IRRDBU00.32 . En el momento de autenticación. vía DES (Data Encryption Standard). 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. Este mecanismo tiene una consecuencia interesante: 2 usuarios con idéntica password tendrán distintos valores guardados en la base de RACF. aún cuando el perfil del usuario correspondiente tenga un perfil modelo especificado. un usuario. Este campo no es visible en la salida del comando LISTUSER. tal cual indica la leyenda siguiente: DATA SET MODELLING NOT BEING DONE FOR GDGS. MODEL(USER) indica que cada vez que se defina un “perfil de dataset de usuario”. Esta es la opción en efecto en una base recién inicializada. o porque RACF se lo exige). aún cuando el perfil del grupo correspondiente tenga un perfil modelo especificado. Vamos a describir a continuación en detalle el significado de cada uno de los suboperandos del operando PASSWORD. GROUP DATA SET MODELLING NOT BEING DONE. al cambiar su password (ya sea voluntariamente.[MIXEDCASE)|NOMIXEDCASE] [REVOKE(valor)|NOREVOKE] [RULEn(LENGTH(min:max) tipo(posición))|NORULEn|NORULES] [WARNING(valor)|NOWARNING] Autoridad requerida: SPECIAL a nivel de sistema Opciones sugeridas: HISTORY(15). establecimos que únicamente se aplique la modelización para “perfiles de dataset de usuario”. como en nuestro ejemplo-. el identificador de usuario. MIXEDCASE. Por lo tanto. ni la actual. El valor guardado es el resultado de encriptar. Apuntes de RACF Juan Mautalen . MODEL(NOUSER) indica que no se aplicarán modelos para “perfiles de dataset de usuario”. no en texto claro sino encriptado. En nuestro ejemplo. Sin embargo. usando como clave de encriptación su password. 77 Por una cuestión de seguridad, es importante utilizar esta opción 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 máximo). 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 fácilmente burlado, es importante establecer asimismo un valor apropiado para el operando MINCHANGE, que analizamos más 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 seguirán utilizándose en la comparación con la nueva, aún cuando el HISTORY se encuentre en 10. Por lo tanto, como nunca serán descartadas, quedarán 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 página 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 condición de que sea diferente de la vigente. Por lo tanto, con esta opción en efecto, un usuario podría alternar permanentemente entre 2 passwords. NOHISTORY es la opción en efecto en una base recién inicializada. Como ya señalamos, 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 máxima INTERVAL establece la cantidad máxima de días en que la password del usuario permanecerá válida. Superada esa cantidad, RACF fuerza al usuario a cambiarla. El valor especificado globalmente en la SETROPTS, de mínimo 1 y máximo 254, en realidad fija un límite superior. En efecto, para cada usuario, el intervalo pasado el cual estará obligado a cambiar su password surge del mínimo 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 mínimo anteriormente mencionado, se obliga al usuario a cambiar su password. El valor por defecto en una base recién 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 mínima MINCHANGE establece el tiempo de vida mínimo, medido en días, que debe regir la password. El usuario no podrá cambiarla hasta tanto hayan transcurrido, como mínimo y contados desde la fecha del último cambio (almacenada en el campo PASSDATE del perfil), la cantidad de días especificados. El valor debe estar comprendido entre 0 y 254. 0 indica que los usuarios podrán cambiar su password tantas veces como quieran, sin restricción alguna. Como ya señalamos, 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 debería cambiar inmediatamente su password si supone que está en conocimiento de un tercero, razón por la cual un valor alto del MINCHANGE sería contraproducente. Es importante observar que la restricción fijada por el parámetro MINCHANGE no aplica para usuarios con capacidad administrativa que cambian la password de otro mediante el comando ALTUSER. Por ejemplo, aún 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 día como considere necesario. El valor por defecto en una base recién 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 mayúsculas y minúsculas en los caracteres de una password. Esta opción, de implementarse, amplía enormemente el universo de posibles passwords, tornando un intento de crackeo por fuerza bruta prácticamente 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 mayúsculas y minúsculas. Es fundamental comprender que el soporte de passwords sensitivas tiene dos puntas, por un lado la aplicación dónde se loguea el usuario (CICS, TSO, FTP, etc.) y por otro RACF. No alcanza con que se habilite en RACF esta opción si la aplicación no la soporta (por ejemplo, convirtiendo a mayúsculas la password antes de presentársela a RACF). En la actualidad, todas las aplicaciones de IBM para z/OS soportan passwords sensitivas, pero es posible que la organización use algún 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 aplicación. NOMIXEDCASE establece que RACF no distinguirá entre mayúsculas y minúsculas. Independientemente de cómo reciba la password, RACF la convertirá a mayúsculas antes de verificarla. Con esta opción se logra un comportamiento análogo al existente antes del z/OS 1.7, y es la que está en efecto en una base recién inicializada. Advertencia: Una vez que se habilita la opción MIXEDCASE, la vuelta atrás es problemática y debe evitarse. Si esto sucediera, aquellos usuarios cuya password contenga algún carácter en minúscula no podrán loguearse. En efecto, al tener por un lado RACF almacenada la versión con minúsculas y por otro convertir a mayúsculas la password recibida antes de proceder a su verificación – producto del seteo NOMIXEDCASE -, ésta siempre resultará fallida. La única salida, en esta situación, es que el usuario solicite a un administrador una nueva password. En nuestro ejemplo está habilitada la opción MIXEDCASE, tal como se observa en la siguiente leyenda del listado de la SETROPTS: MIXED CASE PASSWORD SUPPORT IS IN EFFECT. Revocación automática por intentos fallidos REVOKE establece la cantidad máxima de intentos consecutivos de passwords incorrectas que RACF tolerará antes de proceder a la revocación automática del usuario. Si el valor especificado es N, entonces en el (N+1) intento consecutivo de ingreso especificando una password incorrecta el usuario será automáticamente revocado. Naturalmente, un ingreso válido 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 opinión, 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á automáticamente a los usuarios por intentos consecutivos de ingreso con passwords incorrectas (o sea, no hay límite para la cantidad de intentos). Esta es la opción en efecto en una base recién inicializada. Resulta, sin embargo, inadmisible desde el punto de vista de la seguridad. Reglas sintácticas Con el suboperando RULE se establecen las reglas sintácticas que deben cumplir las passwords. Se puede especificar hasta un máximo de 8 reglas, que se denominan RULEx, dónde x varía de 1 a 8. Una password resulta sintácticamente admisible si cumple con alguna de las reglas establecidas. Para cada regla debe definirse la longitud (mínima y máxima) y el tipo de caracteres permitidos en cada posición. Los posibles tipos de caracteres son: ALPHA CONSONANT ALPHANUM NUMERIC VOWEL NOVOWEL MIXEDCONSONANT MIXEDNUM MIXEDVOWEL NATIONAL A C L N V Caracteres alfabéticos en mayúscula + caracteres nacionales (#, &, @). Consonantes en mayúscula. Caracteres alfabéticos en mayúscula + caracteres nacionales (#, &, @) + caracteres numéricos (0 al 9). Caracteres numéricos (0 al 9) Vocales en mayúscula: A, E, I, O, U. W Consonantes en mayúscula + caracteres nacionales (#, &, @) + caracteres numéricos (0 al 9). c m v $ Consonantes en mayúscula o minúscula. Caracteres alfabéticos en mayúscula o minúscula + caracteres nacionales (#, &, @) + caracteres numéricos (0 al 9). Vocales en mayúscula o minúscula: A, E, I, O, U, a, e, i, o, u. Caracteres nacionales: #, &, @). El tipo ALPHANUM exige lo siguiente: Si existe más de un carácter de este tipo, entonces la password debe tener en esas posiciones al menos un carácter alfabético en mayúsculas y uno numérico. El tipo MIXEDNUM exige lo siguiente: • Si existe un único carácter de este tipo, entonces puede ser cualquiera • Si existen 2, la password debe tener en esas posiciones alguna de las siguientes combinaciones: - Carácter alfabético en mayúscula o nacional + carácter alfabético en minúscula - Carácter alfabético en mayúscula o nacional + carácter numérico - Carácter alfabético en minúscula + carácter numérico • Si existen 3 o más, la password debe tener en esas posiciones al menos un carácter alfabético en mayúsculas o nacional, uno alfabético en minúsculas y uno numérico. Apuntes de RACF Juan Mautalen ya que entre las posiciones 2 y 6 no hay ningún carácter numérico y ALPHANUM(2:6) exige que haya por lo menos un carácter alfabético y uno numérico en el rango. la password T4RUJY4@ cumple con la regla establecida. Asimismo. Apuntes de RACF Juan Mautalen . no recomendamos complicarse fijando reglas sofisticadas que seguramente serán frecuentemente olvidadas por lo usuarios. ya que ello provocaría mensajes de advertencia al inicio de cada sesión. min debe ser menor o igual a max. Solo cuando cambie voluntariamente su password. habilitar la opción MIXEDCASE. Si se omite max. o sea forzado por RACF a hacerlo por haberse excedido el tiempo de validez. Como ya indicáramos. No debe fijarse un valor superior al especificado en INTERVAL. o en el log del job en el caso de un trabajo batch. salvo que especifique explícitamente lo contrario). esto no significa que un usuario cuya password vigente no cumple con las nuevas reglas esté forzado a cambiarla de inmediato. no resulta una opción de gran utilidad. La cantidad de días antes del vencimiento en que el usuario recibirá los mensajes se establece con el parámetro WARNING. la misma no tiene necesidad de satisfacer las reglas sintácticas. 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. como tenemos en nuestro ejemplo. En una base recién inicializada no hay ninguna regla establecida. De todos modos. y un carácter “no vocal” en la última posición. Sin embargo. que involucran caracteres alfabéticos en minúsculas. Un valor de 5 días resulta razonable. deberá establecer una nueva que cumpla con las reglas actuales. En la posición 7. para cada regla. La sintaxis quedará clara a través del siguiente ejemplo: RULE1(LENGTH(6:8) CONSONANT(1) ALPHANUM(2:6) NOVOWEL(8) Esta regla establece que la password debe: tener una longitud mínima de 6 y máxima de 8. empezar con una consonante. se asume max=min por lo que la regla impone una longitud exacta. no existiendo ninguna exigencia explícita. tal cual indica la siguiente leyenda: PASSWORD EXPIRATION WARNING LEVEL IS 5 DAYS. Por el contrario. lo cual sería sumamente molesto. solo deben usarse si la opción MIXEDNUM está en efecto. tener caracteres alfanuméricos de la posición 2 a la 6 inclusive. una única regla estableciendo passwords de 6 a 8 caracteres alfanuméricos es una opción simple y por lo general satisfactoria. cualquier carácter alfanumérico es aceptado. La longitud admisible de la password para cada regla se establece a través del parámetro LENGHT(min:max). En la práctica. dónde min indica la longitud mínima y max la máxima (max puede ser a lo sumo igual a 8). YHGTRF8 no la satisface. entonces debe cumplir con las reglas globales de la organización fijadas en la SETROPTS. Warning Existe la posibilidad de informar con determinada anticipación a un usuario de TSO (en el momento del logon). m y v. ya que está disponible. De todos modos. Por ejemplo. que su password está próxima a vencer y tendrá que cambiarla. si se otorga una clave no expirada. Es conveniente. recomendamos usarla.80 Los tipos c. Los eventuales cambio en las reglas para passwords de la SETROPTS toman efecto inmediatamente. En caso de no poner en práctica esta opción. El valor especificado debe estar comprendido entre 1 y 255. Naturalmente. se establece qué tipo de carácter es admisible en cada posición. en la medida de lo posible. la única regla establecida en nuestra SETROPTS de ejemplo suele ser satisfactoria desde el punto de vista de seguridad. En cambio. SECLABELAUDIT y SECLEVELAUDIT incorporan un nivel extra de auditoría. En una base recién inicializada. el valor por defecto es la palabra YES. que merece un estudio detallado que haremos más adelante. por lo cual recomendamos tener estas opciones inactivas. Es absolutamente recomendable que la organización fije passwords para estos comandos. y las almacene bajo sobre en algún lugar seguro. en ambos casos.Restricción para la creación de perfiles más específicos que perfiles existentes Sintaxis: SETROPTS|SETR GENERICOWNER|NOGENERICOWNER Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: depende de la organización Apuntes de RACF Juan Mautalen . no consideramos necesario adoptar este nivel extra de seguridad. y así se encuentran en nuestro ejemplo. Estas passwords. o sea YES. Como ya hemos comentado. Ambas opciones requieren el atributo AUDITOR a nivel de sistema para ser modificadas. las claves en efecto son las default.Passwords del RVARY Sintaxis: SETROPTS|SETR RVARYPW([SWITCH(password)] [STATUS(password)]) Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: establecer passwords para ambos comandos (no dejar el valor default) No analizaremos en este capítulo el comando RVARY. 5.35 . indica que no se avisará anticipadamente a los usuarios sobre el vencimiento de su password. 5. no se muestran en el listado.81 NOWARNING. una para SWITCH (operando SWITCH) y otra para STATUS (operando ACTIVE|INACTIVE) se especifican en la SETROPTS. 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. basado en security labels y security levels. Si no se establecen estas passwords. categories o security labels. Este es el default en una base recién inicializada. que es la opción por defecto en una base recién inicializada. Naturalmente. En nuestro ejemplo se han establecido ambas passwords. Tanto la función SWITCH como ACTIVE|INACTIVE del comando RVARY exigen el ingreso de una password para ejecutarse exitosamente. como se deduce de la siguiente leyenda: SECLEVELAUDIT IS INACTIVE SECLABEL AUDIT IS NOT IN EFFECT 5.34 .33 . INSTALLATION DEFINED RVARY PASSWORD IS IN EFFECT FOR THE STATUS FUNCTION.Opciones de auditoría 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. STC.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 . con sus respectivos owner. OPERA es un grupo de RACF.**. además de tener autoridad para definir perfiles en la clase (ver atributo CLAUTH). Sin embargo.** JEF2574 En esta situación. También podría definir el perfil RACF. y es asimismo la vigente en nuestro ejemplo tal como indica la leyenda: GENERIC OWNER ONLY IS NOT IN EFFECT 5. Tengamos presente que esta opción tampoco limita la creación de una protección más específica a través de un perfil en una clase agrupadora. ya que no es el owner de MVS.** JES2. con excepción de la clase PROGRAM.36 . pues en ambos casos es el owner del perfil genérico existente que más se ajusta al perfil que está definiendo (JES2.START. están dados por la siguiente tabla: Perfil MVS. pues no existe ningún perfil menos específico.** Owner OPERA JEF2574 o o MVS. GENERICOWNER solo limita la creación de perfiles cuando existe un perfil menos específico que el que se pretende definir.** dentro de su campo de acción. respectivamente).**. no podría definir el perfil MVS. Es la opción en efecto en una base recién inicializada. Los perfiles existentes en la clase OPERCMDS. Tiene el atributo SPECIAL a nivel de un grupo que tenga al perfil inmediatamente superior dentro de su campo de acción.** y MVS. el usuario JEF2574 podría definir los perfiles JES2.STOP.**.START.** y MVS. un usuario solo puede crear un perfil más específico que uno existente si. A modo de ejemplo. suponiendo que la clase en cuestión la tenga. en cualquier clase de recursos generales.82 GENERICOWNER limita la posibilidad de crear perfiles más específicos que otros ya existentes. NOGENERICOWNER no establece la limitación anterior para la creación de perfiles más específicos que otros existentes. ni a nivel de sistema ni a “nivel de ningún grupo”. supongamos la siguiente situación: o El usuario JEF2574 tiene el atributo CLAUTH(OPERCMDS) y no tiene el atributo SPECIAL.** y tampoco tiene el atributo SPECIAL a nivel de sistema o a nivel de un grupo que tenga al perfil MVS. cumple alguna de las siguientes condiciones: Tiene el atributo SPECIAL a nivel de sistema. Si la opción GENERICOWNER está en efecto.**. Es el owner del perfil inmediatamente superior.CANCEL.START. Es una opción que reduce al mínimo la actividad.) 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. CATDSNS en FAILURES indica que RACF no permitirá acceder a archivos que no se encuentren catalogados (o temporarios generados por el sistema). Se graba asimismo un registro de SMF reflejando el evento.Acceso a datasets no catalogados Sintaxis: SETROPTS|SETR CATDSNS(FAILURES|WARNING)|NOCATDSNS Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: CATDSNS(FAILURES) Se trata de una opción importante que determina cómo se comportará RACF cuando se intente acceder a archivos “no catalogados”. ya que no nos ocupamos de analizar este nivel extra de seguridad.83 Opciones sugeridas: NOCOMPATMODE. NOMLSTABLE NOSECLABELCONTROL Estas opciones. puede accederlo mientras dure la ejecución. Apuntes de RACF Juan Mautalen . RACF chequea a continuación la autoridad del usuario sobre este recurso en la clase FACILITY. Si el usuario tiene el atributo SPECIAL a nivel de sistema. La opción MLQUIET. y si es READ (o superior). Si el acceso lo solicita una started task definida como TRUSTED o PRIVILEGED. si se habilitó para ellos el control en la clase DATASET mediante la apropiada configuración el miembro DEVSUPxx de la PARMLIB. no se rechaza el acceso por “dataset no catalogado”. No vamos a analizar su significado en esta guía. Archivos protegidos por perfiles discretos pueden ser accedidos aún cuando no estén catalogados. ejecutar jobs o acceder a recursos protegidos. y solo tendría sentido para alguna tarea específica de mantenimiento. entonces no se rechaza el requerimiento por “dataset no catalogado”.. la condición de “no catalogado” del archivo no impide el acceso. estos datasets resultan inaccesibles. excepto MLQUIET|NOMLQUIET. Para datasets no catalogados y no protegidos discretamente. pero el usuario debe de todos modos tener acceso al dataset a través de los canales habituales.37 . En los casos mencionados. Este seteo afecta igualmente a datasets no catalogados residentes en cartucho. NOMLQUIET no establece las citadas restricciones. En una base recién inicializada. En cualquier caso.dsname. salvo en alguna de las situaciones siguientes: Si un job define un archivo y no lo cataloga. siempre y cuando el perfil protector lo permita. entonces no rechaza el acceso por “dataset no catalogado”. NOMLS. es extremadamente raro que deba recurrirse a ella. solo tienen sentido en organizaciones que usen security labels. se construye un recurso de nombre ICHUNCAT. los operadores de consola y los usuarios con atributo SPECIAL loguearse. pero se envía al usuario (y al SYSLOG) un mensaje informando que el archivo no está catalogado. NOMLACTIVE. mientras se encuentra vigente. dónde dsname es el nombre del archivo (solo los 30 primeros caracteres se consideran). permite únicamente a las started task. NOMLQUIET. todas estas opciones están en NO.. Con esta configuración. 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 (. Auditoría de transacciones APPC Sintaxis: SETROPTS|SETR APPLAUDIT|NOAPPLAUDIT Autoridad requerida: AUDITOR a nivel de sistema Opción sugerida: depende de la organización APPLAUDIT habilita globalmente la auditoría para transacciones APPC (registra inicio y fin). sin causar interrupciones en las tareas por problemas de falta de autoridad. para que efectivamente se grabe esta información. 5. como muestra la leyenda: APPLAUDIT IS NOT IN EFFECT Apuntes de RACF Juan Mautalen . Esta es la opción vigente en una base recién inicializada. Sin embargo. ya que permite identificar los archivos en uso que no se encuentran catalogados. lo cual se desprende de la siguiente leyenda: PARTNER LU-VERIFICATION SESSIONKEY INTERVAL MAXIMUM/DEFAULT IS 30 DAYS. en lugar de rechazar el pedido por “dataset no catalogado”. el valor por defecto es 30. un mensaje informando que el archivo no se encuentra en catálogo. pero con una diferencia fundamental: RACF. medido en días. Con esta opción en efecto no se graba la información correspondiente aún cuando el perfil en la clase APPL esté debidamente auditado. CURRENT OPTIONS: CATDSNS FAIL OPTION IS IN EFFECT CATDSNS en WARNING funciona de manera similar al modo FAILURES. la opción en efecto es CATDSNS(FAILURES). que es asimismo el vigente en nuestro ejemplo.84 En nuestro ejemplo.Máximo global y default para la validez de la clave de una sesión Sintaxis: SETROPTS|SETR SESSIONINTERVAL(n)|NOSESSIONINTERVAL Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: depende de la organización SESSIONINTERVAL(n) establece el máximo valor para el operando INTERVAL. 5. NOAPPLAUDIT inhabilita globalmente este tipo de auditoría. debe auditarse el correspondiente perfil de la clase APPL. Esta es la opción por defecto en una base recién inicializada. que se puede especificar en el segmento SESSION en un perfil de la clase APPCLU. Luego de un tiempo prudencial. El valor n debe estar comprendido entre 1 y 32767 inclusive. se sugiere cambiar al modo FAILURES. Se graba asimismo un registro de SMF reflejando el evento. continúa con su chequeo habitual pero envía. y es asimismo la vigente en nuestro ejemplo.39 . En una base recién inicializada. Este valor resulta también el defecto cuando se define un nuevo perfil en esta clase con segmento SESSION pero no se codifica INTERVAL. tal cual se desprende de la siguiente leyenda: CATALOGUED DATA SETS ONLY. tanto al usuario como al SYSLOG. Esta opción resulta útil en las etapas iniciales de la construcción de un sistema.38 . NOCATDSNS establece que RACF no rechazará el acceso a un archivo por no estar catalogado. IS IN EFFECT. La opción NOSESSIONINTERVAL no establece ningún máximo global. Comandos de REFRESH Los comandos de RACF que definen.41 . Sin embargo. como contrapartida.42 . Esto mejora sensiblemente el tiempo de respuesta.Lenguaje Sintaxis: SETROPTS|SETR LANGUAJE([PRIMARY(lenguaje)] [SECONDARY(lenguaje)]) Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: ENU para ambos A nivel de la SETROPTS.85 5. ya que el mismo varía de acuerdo al tipo de información a actualizar y a las características de la clase a la que pertenecen los perfiles. como se ve en la leyenda: ADDCREATOR IS NOT IN EFFECT 5. solo pueden especificarse lenguajes que estén disponibles en la instalación. evitando extraerla nuevamente de la base.40 . actúan directamente sobre la base RACF (residente en disco). en muchos casos RACF carga información en memoria virtual y la reutiliza tantas veces como le sea requerida. ya que es muchísimo más rápido el acceso a memoria que a disco. se logra ejecutando el comando SETROPTS con los operandos adecuados. En una base recién inicializada. Clases RACLISTeadas Una clase puede estar RACLISTeada mediante alguna de las siguientes maneras: Apuntes de RACF Juan Mautalen . pueden establecerse los lenguajes globales que usará el sistema (uno primario y otro secundario. con el propósito de optimizar la performance. El valor por defecto para ambos lenguajes. para lo cual debe consultarse a los responsables del sistema operativo. la opción en efecto es NOADDCREATOR. toda vez que se modifique información de un perfil que RACF mantiene en memoria. Ahora bien. conocida como REFRESH (refrescamiento).Opción ADDCREATOR Sintaxis: SETROPTS|SETR ADDCREATOR|NOADDCREATOR Autoridad requerida: SPECIAL a nivel de sistema Opción sugerida: NOADDCREATOR La opción ADDCREATOR establece que toda vez que un usuario defina un perfil de dataset o de recursos generales automáticamente se agregará su identificador en la lista de acceso estándar con nivel de autoridad ALTER. Naturalmente. modifican o borran perfiles. ya que es sumamente frecuente que el creador del perfil no necesite acceso a los recursos que protege. en una base recién inicializada. será necesario una actualización. esta es la opción elegida. que pueden coincidir o ser diferentes). recomendamos la opción NOADDCREATOR. viene identificado por la sigla ENU. reduciendo lo más posible la cantidad de operaciones de I/O sobre la base –muy costosas–. Esta operación. que significa inglés americano. En nuestro ejemplo. En la práctica. No existe un único comando de REFRESH. que no coloca automáticamente al usuario creador del perfil en la lista de acceso. tal cual muestra la leyenda: PRIMARY LANGUAGE DEFAULT : ENU SECONDARY LANGUAGE DEFAULT : ENU 5. Esta es la opción vigente en nuestro ejemplo. Por lo tanto. más que una ventaja resulta una molestia. para actualizar la información existente debe ejecutarse el comando: SETROPTS GENERIC(clase) REFRESH Este comando no solo refresca la información de los perfiles genéricos de la clase especificada sino también los de aquellas otras que eventualmente compartan el mismo posit value. Autoridad requerida Para poder ejecutar el comando anterior sobre una determinada clase. estos se cargan en memoria cuando son referenciados (en un espacio común. las distintas aplicaciones empezarán inmediatamente a apuntar al nuevo data space. Es importante destacar que no solo se refresca la información de los perfiles de la clase especificada. Este comando genera un nuevo data space. Hasta tanto concluya su creación. Si se modificó información de perfiles de una clase agrupadora (y la clase de miembros asociada se encuentra RACLISTeada). RACF realiza una operación de merge cuando carga en memoria los perfiles. La información de este data space es consultada toda vez que una aplicación requiera que RACF resuelva una solicitud de acceso que involucre a esta clase. la información en el data space es una versión procesada de los perfiles existentes en la base. para lo cual es necesario ejecutar el comando: SETROPTS RACLIST(clase) REFRESH La clase especificada no debe ser una clase agrupadora. sino también de todas aquellas otras clases que eventualmente compartan el mismo posit value. RACF carga en un data space en memoria la información de todos los perfiles (discretos y genéricos) de la clase. en cuyo caso aparece bajo RACLIST en el listado de la SETROPTS. y el antiguo es borrado. Por lo tanto.86 • • A través del comando “SETROPTS RACLIST(clase)”. en cuyo caso aparece bajo “GLOBAL=YES RACLIST ONLY” en el listado de la SETROPTS. el usuario debe satisfacer alguna de las siguientes condiciones: Apuntes de RACF Juan Mautalen . 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 genéricos Si una clase no se encuentra RACLISTeada. Por una aplicación. o sobre aquellos de su eventual clase agrupadora. el comando de REFRESH debe ejecutarse siempre sobre la clase de miembros. Una vez que el comando se complete exitosamente. solo tomarán efecto una vez que se haya refrescado la información del data space. Toda modificación que se efectúe sobre perfiles (discretos o genéricos) de una clase RACLISTeada. con el objeto de combinar adecuadamente la información de ambas clases –la de miembros y la agrupadora–. por ejemplo. en otros). por lo tanto. información del perfil cargada en su propia memoria). las aplicaciones seguirán usando la información del antiguo. una modificación efectuada sobre un perfil genérico de la clase puede no tomar efecto inmediatamente (si el address space que lo requiere tiene. En tal caso. En estos casos. Si la clase RACLISTeada tiene una clase agrupadora. pero tiene perfiles genéricos definidos. en algunos casos. Autoridad requerida Para ejecutar el comando anterior sobre una determinada clase. En ambos casos. o en cada address space. en caso de que se le otorgue la autorización. los perfiles son invalidados y será necesario volver a cargarlos. AUDITOR u OPERATIONS a nivel de sistema. ya sea a nivel de sistema o a nivel de grupo. Observación: Para una clase no GENLISTeada. Un ejemplo típico es la clase DATASET. El comando “SETROPTS GENERIC(DATASET) REFRESH” finaliza inmediatamente. Sin embargo. residente en memoria y específico de la clase. AUDITOR u OPERATIONS. para tomar efecto. Toda modificación. requiere la ejecución de un comando de REFRESH. Si se tiene una clase bajo GLOBAL en la SETROPTS. pero su impacto negativo en la performance puede ser importante. Esto se debe a que RACF simplemente modifica un contador. el comando “SETROPTS GENERIC(clase) REFRESH” se ejecuta casi instantáneamente. Tener CLAUTH sobre la clase. los cambios solo quedarán vigentes si se ejecuta el comando: SETROPTS GLOBAL(clase) REFRESH Este comando no solo afecta la clase especificada sino también a todas aquellas otras que eventualmente compartan el mismo posit value (y estén bajo GLOBAL en la SETROPTS) Autoridad requerida Para ejecutar el comando anterior sobre una clase. su efecto concreto es el de invalidar todas las copias de perfiles genéricos de la clase que puedan existir en los distintos address space. y la forma de refrescarla es uno de ellos. antes de reusarlos. el usuario debe satisfacer alguna de las siguientes condiciones: Tener el atributo SPECIAL. Clase GLOBAL La información de las tablas de la clase GLOBAL se encuentra siempre cargada en memoria. Si lo hizo. los cambios solo tomarán efecto una vez que se haya ejecutado el comando: SETROPTS WHEN(PROGRAM) REFRESH Autoridad requerida Para ejecutar el comando anterior. Tener CLAUTH sobre la clase. se trata de un comando de ejecución inmediata pero que puede resultar costoso en términos de procesamiento. En efecto. Clase PROGRAM La clase PROGRAM es muy particular en varios aspectos. y se modifica información de la correspondiente tabla. AUDITOR u OPERATIONS a nivel de sistema.87 Tener el atributo SPECIAL. el usuario debe satisfacer alguna de las siguientes condiciones: Tener el atributo SPECIAL. Tener CLAUTH en la clase PROGRAM. será normalmente preferible pedirle que vuelva iniciar sesión antes que ejecutar el comando de REFRESH. En consecuencia. Apuntes de RACF Juan Mautalen . si muchos address space tienen almacenados perfiles de la clase. Si se efectúan modificaciones en sus perfiles. Si un usuario de TSO reporta que intentó acceder a un dataset y no pudo por falta de autoridad. éstos saben qué valor tenía el contador la última vez que se cargaron en su memoria de perfiles de la clase y. verifican que el contador no haya cambiado. y simboliza un objeto -tangible o intangible. Un ejemplo típico son las clases TCICSTRN y GCICSTRN. Un perfil de recursos generales. siendo una de ellas la “clase de miembros” (member class) y la otra la “clase agrupadora” (grouping class). modifica o borra a través de comandos..). utilizadas para controlar la ejecución de transacciones CICS. HYT6 3. Está constituido por un segmento base. Ambas sirven para proteger el mismo tipo de recurso. Posibles ejemplos son: discos. ABC1 2. ABC% 4. Se admiten normalmente perfiles genéricos.PROTECCIÓN DE RECURSOS GENERALES 6. 4 y 5 son perfiles genéricos. TCICSTRN es la clase de miembros mientras que GCICSTRN es su correspondiente clase agrupadora. Toda clase definida en la CDT tiene especificado el tipo de caracteres que admite y la longitud máxima permitida. separados por puntos (. que varían de acuerdo a la clase a la que pertenece el perfil.START. La aplicación.**. El nombre de un recurso general lo establece la aplicación o subsistema correspondiente. Se crea.STC. En cualquier caso. A diferencia de los nombres de archivos. en cambio. y su protección se establece a través de perfiles en clases de recursos generales. provistas por IBM o definidas por la organización. Apuntes de RACF Juan Mautalen . es una entidad que existe únicamente en la base de RACF. más eventuales segmentos no base. Los nombres de los recursos generales son muy variados. 6. Ejemplo: Supongamos que los perfiles definidos en la clase TCICSTRN son los siguientes: 1.de muy variada naturaleza. suponiendo que la clase se encuentre bajo GENERIC en la SETROPTS. F* 1 y 2 son perfiles discretos. mientras que 3. al igual que los de los perfiles que los protegen. los nombres se componen de cadenas de caracteres llamadas calificadores. No debe confundirse un “recurso general” con un “perfil de recursos generales”. debe informar a qué clase de recursos generales (definida en la CDT) pertenece el recurso. la longitud de un calificador puede exceder los 8 caracteres. Por lo tanto. comandos de operador. GROUP y DATASET. que a su vez podría estar protegido por el perfil genérico MVS.START. que inicia una started task llamada PROC1. Los perfiles de la clase de miembros deben tener un nombre que matchee con el del recurso que pretendan proteger. solo permiten proteger un único recurso o varios distintos pero de nombres similares.2 .88 6 . también llamado “segmento de RACF”.Recursos generales y perfiles Todos los recursos que no sean archivos son considerados recursos generales. el comando de operador “START PROC1”. AB* 5. procedimientos de logon a TSO o la facilidad de acceder a cierto archivo no catalogado.Clases de miembros y agrupadoras Ciertas clases de recursos generales vienen asociadas de a pares. se asocia con el nombre de recurso MVS. con excepción de USER. Por ejemplo.1 .PROC1 en la clase OPERCMDS. Es una regla usada para controlar el acceso a los recursos propiamente dichos. del mismo modo que no debe confundirse un dataset con un perfil de dataset. Todas las clases. al derivar a RACF el requerimiento de chequeo de autoridad. son consideradas clases de recursos generales. tienen nombres de libre elección. VGT8 Los 3 perfiles son discretos (recordemos que no están tolerados los perfiles genéricos para clases agrupadoras). Es el caso. aunque sí pueden los perfiles tener “miembros genéricos”. Es decir. estos perfiles permiten proteger recursos de nombres disímiles pero con idéntica necesidad de acceso. para la transacción ABC1 sería el perfil discreto de idéntico nombre. los miembros que tienen definidos son los que deben matchear con los nombres de los recursos. o bien no encontró ninguno en la clase de Apuntes de RACF Juan Mautalen . AB* FTR1. En nuestro ejemplo. Un mismo miembro puede existir en varios perfiles. por otro lado. ABY6. un recurso puede tener más de un perfil de máximo ajuste. mientras que para AX56 sería GRUPOA. GRUPOA tiene un único miembro. SISTAB y SISTCONT. que puede ser discreto o genérico. tal cual veremos a continuación. mientras que en la clase agrupadora podrían existir eventualmente varios (que tengan al recurso como miembro discreto). en nuestro ejemplo. La transacción RY54. Pero poseen una “lista de miembros” cuyos nombres deben matchear con el nombre del recurso que pretendan proteger. para las transacciones HYT6 (perfil de igual nombre en la clase TCICSTRN) y VGT8 (perfil SISTCONT en la clase GCICSTRN). se pueden presentar los 2 casos siguientes: RACF encontró un único perfil que cubre discretamente al recurso (que podría estar en la clase de miembros o en la clase agrupadora). la protección de un determinado recurso surge de combinar la información almacenada en ambas clases. Dado un recurso. ABC2.son arbitrarios y no son chequeados por RACF contra ningún nombre de recurso. no estaría cubierta por ningún perfil de la clase TCICSTRN. En este caso. Dentro de una clase agrupadora. RACF encontró más de un perfil que cubre discretamente al recurso. En consecuencia. En cualquier caso. ABC2 y ABY6) y el restante genérico (AB*). ABC1. no estaría protegida por ningún perfil de la clase GCICSTRN. el más ajustado sería SISTAB.89 Dentro de la clase de miembros. a diferencia de lo que sucede con los de la clase de miembros. SISTCONT tiene 5 miembros. este perfil es el que establece la protección del recurso. la de miembros y la agrupadora. Los perfiles en la clase agrupadora. halló uno en la clase de miembros y uno o más en la clase agrupadora. 3 de ellos discretos (ABC1. en cambio. puede encontrar a lo sumo un único perfil discreto para el recurso. todo recurso tiene (a lo sumo) un único perfil que más se le ajusta. Por ejemplo. todos ellos discretos. ABC2. mientras que para la transacción ABFT. Si RACF efectivamente encontró al recurso protegido de manera discreta. que es genérico. para la transacción ABC1. pues ambos tienen al miembro discreto ABC1. Determinación de la protección de un recurso La manera en que RACF determina la protección de un recurso en el caso de clases de miembros y agrupadoras es relativamente compleja. para la transacción ABC8. Los nombres de los perfiles -GRUPOA. No se permiten perfiles genéricos. SISTAB tiene 4 miembros. apoyándonos en los ejemplos dados para las clases TCICSTRN y GCICSTRN. el perfil más ajustado sería el genérico AB*. Ejemplo: Supongamos que los perfiles definidos en la clase GCICSTRN son los siguientes: Nombre del perfil Miembros GRUPOA A* SISTAB SISTCONT ABC1. FTR3. Intentaremos describirla con cierto detalle. éstos serían SISTAB y SISTCONT. La transacción VGT2. En la clase de miembros. Para ello examina ambas clases. Por otro lado. RACF busca en principio determinar si está protegido discretamente. FTR2. En cambio. usar solo la clase de miembros o. dentro de lo posible. RACF combina las listas de acceso de todos los perfiles involucrados.3 . Este sería el caso. crear un perfil genérico en la clase de miembros. No definir miembros genéricos en perfiles de la clase agrupadora. Si RACF encuentra más de un perfil que cubre genéricamente al recurso de la manera más ajustada posible. Por lo tanto. siempre en nuestro ejemplo. En el caso concreto de CICS. No están permitidos. RACF opera de manera opuesta. resulta un perfil discreto. Tanto el perfil AB* en la clase TCICSTRN como el perfil SISTAB en la clase GCICSTRN cubren lo más ajustadamente posible al recurso ABX9 (GRUPOA no entra en juego ya que A* es menos específico). si RACF no encuentra al recurso cubierto ni discreta ni genéricamente en ninguna de ambas clases. solo la clase agrupadora. si bien tanto el perfil ABC% en la clase TCICSTRN como los perfiles GRUPOA y SISTAB en la clase GCICSTRN cubren genéricamente al recurso. a diferencia de la clase DATASET. en nuestro ejemplo. 6. y con el objetivo de establecer una protección clara de los recursos en el caso de clases de miembros y agrupadoras. aconsejamos lo siguiente: No utilizar ambas clases.al que tienen en el caso de perfiles de dataset. su nivel de autorización efectivo sobre recurso será el más alto de todos. el más ajustado es el perfil ABC% (pues tanto A* como AB* son menos específicos). No describiremos en detalle este algoritmo. * y **). siguiendo un criterio análogo al empleado para perfiles genéricos de dataset. Es el caso. de la transacción ABX9. Tal sería el caso. cabe señalar que el producto deniega el acceso si la transacción no está protegida. Esto es. la protección efectiva del recurso surge de combinar la información de todos los perfiles que lo cubren discretamente. pero mencionaremos los aspectos más relevantes: Para determinar la lista de acceso del recurso. Esto significa que si un grupo (o usuario) figura en más de una de las listas de acceso. No definir el mismo recurso en más de un perfil. En consecuencia. la protección de la transacción ABX9 se establece combinando los perfiles AB* y SISTAB. En efecto. El UACC efectivo será el más restrictivo de los UACC de los perfiles involucrados.Perfiles genéricos La mayoría de las clases de recursos generales admiten perfiles genéricos. Finalmente.90 miembros pero encontró 2 o más en la clase agrupadora. 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 base al criterio del “nivel más permisivo”. Sería el caso. si fuese necesario. todo perfil que no contenga en su nombre al menos un carácter genérico. en caso de repeticiones. mejor aún. entonces la protección efectiva surge de un proceso de merge idéntico al mencionado en el caso discreto. Recordemos que si una clase de Apuntes de RACF Juan Mautalen . En tal caso. Es preferible. Se identifican por la presencia de algún carácter comodín en su nombre (%. los compara hasta determinar los que más se ajustan al nombre del recurso. los perfiles genéricos completos. para la transacción MKL7. Recomendaciones: En virtud de lo expuesto. En este caso. En lo que se refiere al UACC del recurso. en nuestro ejemplo. entonces concluye que no lo tiene protegido y devuelve a la aplicación solicitante el DFTRETC especificado para la clase en la CDT. entonces éste perfil será el protector. proceso conocido como merge. cuyo significado es similar –aunque no exactamente idéntico. manejándose. suponiendo que CICS esté efectivamente configurado para que se controle la ejecución de transacciones. Si RACF llega a establecer un único perfil que cubre genéricamente al recurso de la manera más ajustada posible. entonces busca en ambas clases perfiles que lo cubran de forma genérica. de la transacción ABC3. Si RACF no encuentra al recurso cubierto de manera discreta. dentro de CICS. Así. Los posibles valores son los siguientes: o o o o o o NONE EXECUTE READ UPDATE CONTROL ALTER Están enumerados en orden jerárquico. ya que indica que no se tiene ningún acceso al recurso. conviene usar perfiles genéricos. para perfiles de recursos generales. Un abuso en la cantidad de perfiles genéricos.4 . Apuntes de RACF Juan Mautalen . VCICSCMD). por otro lado. la autoridad para ejecutar comandos sobre terminales se chequea contra el recurso de nombre TERMINAL. desvirtúa su naturaleza y puede ocasionar problemas de performance. Valen consideraciones similares a las que se hicieron respecto a perfiles de dataset. ya que una poca cantidad permite proteger un gran número de recursos. NONE tiene obviamente un significado claro. como sucede con los perfiles de dataset. que solo se limita a contestar requerimientos que le son remitidos. EXECUTE. de manera que cada nivel incluye y muchas veces excede los privilegios del anterior. el uso de perfiles discretos en clases de recursos generales es muy frecuente (incluso. incluso en el primero.91 recursos generales admite perfiles genéricos. Cabe indicar que estos niveles de autoridad requeridos para cada comando los establece CICS y no RACF. el uso del ** está permitido independientemente del seteo de la opción EGN de la SETROPTS (que solo afecta a la clase DATASET). dónde tienen un significado claro. solo es válido para perfiles en la clase PROGRAM. para hacer un SET se requiere UPDATE y para efectuar un DISCARD se exige ALTER. En particular. Cabe señalar que los nombres de los niveles tienen su origen en los existentes para perfiles de dataset. Dependiendo del tipo de comando que se ejecute.5 . Los recursos que necesiten un tratamiento de seguridad particular deben ser protegidos mediante un perfil discreto. debe entenderse que se trata simplemente de una escala jerárquica. por lo cual contempla la existencia de calificadores enteros. los comandos invocados vía la transacción CEMT se encuentran protegidos en la clase CCICSCMD (o en la clase agrupadora asociada. Siempre que resulte posible. incluyendo eventuales “puntos”. En cualquier caso. para hacer un INQUIRE.Cómo determina RACF la protección de un recurso general Si el recurso está asociado con una clase que tenga clase agrupadora. Otras diferencias importantes son las siguientes: Los perfiles genéricos de recursos generales admiten caracteres comodín en cualquier calificador. 6. el usuario debe tener READ. dónde figuran niveles de acceso. tienen un UACC y listas de acceso -estándar y condicional-. El * al final de un perfil indica la presencia de 0 o mas caracteres. dónde el alcance de cada nivel de autoridad lo establece la aplicación correspondiente. dónde exista casi una relación biunívoca con los recursos. Por ejemplo. Sin embargo. ya se describió el proceso que lleva a cabo RACF para determinar su protección. a diferencia de la clase DATASET. 6. a veces.Niveles de acceso Los perfiles de recursos generales. obligatorio) y está perfectamente justificado. el nivel de autoridad requerido por CICS varía. RACF procede del siguiente modo: Si el recurso está protegido discretamente. Recordemos que ser el dueño de un perfil no otorga acceso a los recursos que proteja. entonces este perfil discreto será su perfil protector. desde el menos al más genérico.Los caracteres “no genéricos” son más específicos que los genéricos. en caso de que no lo tuviera especificado. El nombre-del-perfil es un parámetro posicional requerido que debe estar inmediatamente a continuación de la clase. debe usarse esta facilidad con sumo cuidado y normalmente por un período Apuntes de RACF Juan Mautalen .6 . ya que los mismos se considerarían parte integrante del nombre (si la clase los soportara). cuando aún no se logró determinar exactamente qué usuarios deben acceder a los recursos protegidos por un perfil. como ya señalamos. El OWNER debe ser un usuario o grupo existente. CONTROL y ALTER.Definición 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 más relevantes relativos al segmento base del perfil. lo autoriza pero envía un mensaje a la terminal del usuario (y graba uno similar en el SYSLOG) indicando que el acceso no correspondía pero fue otorgado por estar el perfil protector en modo warning. debe agregarse al usuario en la lista de acceso a través del comando PERMIT. El operando WARNING establece que el perfil se define en modo warning. o sea para recursos no relacionados con clases de miembros y agrupadoras. Esto significa que si un usuario requiere acceso a un recurso protegido por el perfil y RACF determina que no está autorizado. Por lo tanto. En ciertas ocasiones. Los segmentos no base se verán en el análisis particular de cada clase.que protege al recurso. * y **. Sin embargo. UPDATE. de longitud máxima 255 caracteres. 6. EXECUTE. La DATA es un campo de uso administrativo. de acuerdo al siguiente criterio: . puede resultar útil definirlo en modo warning. La clase es un parámetro posicional requerido que debe estar inmediatamente a continuación del comando RDEFINE. el recurso simplemente no estaría protegido) y procede a compararlos. RACF determina a lo sumo un único perfil -discreto o genérico.Para las genéricos. Los nombres válidos dependen de cada clase. el orden. el valor por defecto es el DFTUACC que tiene la clase en la CDT o. de izquierda a derecha. debe tenerse presente que aquellos recursos protegidos por un perfil en warning se encuentran accesibles por cualquier usuario con el máximo nivel de autoridad (ALTER). se descartan aquellos más genéricos. de modo a no provocar una interrupción en alguna tarea crítica. de manera análoga a como lo hace en el caso de archivos. . Si no se codifica explícitamente. en lugar de rechazar el acceso. READ. En el primer carácter en que encuentre alguna diferencia. que ya mencionamos previamente (EXECUTE solo es válido si la clase es PROGRAM). queda como OWNER el usuario que ejecutó el comando. es %.92 En caso contrario. Si se omite. No debe especificarse el nombre del perfil entre apóstrofes. Si no está protegido discretamente. el UACC que tiene el usuario que ejecuta el comando en su “actual grupo de conexión” (que. RACF busca todos los perfiles genéricos que lo alcanzan (si no existiera ninguno. Para poder acceder a ellos. Puede tomar los valores NONE. conviene que sea NONE por motivos de seguridad). El operando UACC es sumamente importante y establece el “nivel de acceso universal” (Universal Access) del perfil. es decir que están básicamente sin protección. Los posibles niveles de acceso son: o READ o UPDATE o CONTROL o ALTER En el operando AUDIT se pueden especificar uno (o más) tipos de acceso acompañados del nivel de acceso correspondiente. Si se lo codifica sin especificar usuario. UACC. El operando AUDIT indica a qué nivel se quiere auditar el uso del perfil. éstos no son copiados al nuevo perfil. NOTIFY. El significado y formato de estos miembros varía según la clase. que llamamos modo fail. Todas las características del perfil especificado en el operando FROM son replicadas en el nuevo (OWNER. RACF asume que el perfil modelo pertenece a la misma clase que el que se está definiendo. El operando FROM especifica el nombre de un perfil (discreto o genérico) en el cual se va a basar RACF para la creación del nuevo. NOTIFY especifica un usuario a ser notificado cada vez que el perfil sea usado para denegar el acceso a un recurso. en la salida del comando RLIST. Se distinguen 2 conceptos diferentes: tipo de acceso y nivel de acceso. ningún usuario será notificado y el campo muestra. puede existir una mínima diferencia en las del nuevo perfil con respecto al tomado como modelo. Con el operando ADDMEM se agregan miembros al perfil. Apuntes de RACF Juan Mautalen . Las clases PROGRAM y NODES no admiten perfiles en modo warning. Si se omite WARNING. el usuario que crea el nuevo perfil se agrega a la lista de acceso estándar con autoridad ALTER. el usuario debería loguearse frecuentemente a TSO afín de liberar el espacio que ocupan sus mensajes pendientes en el archivo SYS1. En cuanto a las listas de acceso. AUDITING. NONE no requiere un nivel de acceso asociado. la leyenda “NO USER TO BE NOTIFIED”. si se supone que rechazará gran cantidad de accesos. sea fallido o exitoso. excepto que se codifique explícitamente un valor distinto para alguno de estos operandos en el comando RDEFINE. WARNING. NOTIFY no admite más de un usuario ni un grupo de RACF. siempre y cuando se trate de una clase cuyos perfiles los admitan (clases agrupadoras o GLOBAL y PROGRAM. FAILURES(READ) es el valor por defecto. Naturalmente. Si se omite. o SUCCESS se grabarán accesos exitosos. en el caso siguiente: Si la opción ADDCREATOR está activa en la SETROPTS. 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 lo omite. o ALL se grabará todo intento de acceso. independientemente de que figure o no en la lista de acceso del perfil modelo.BRODCAST. Los posibles tipos de acceso son: o NONE ningún intento de acceso será grabado. etc. no es conveniente tener en forma permanente un usuario en el NOTIFY de un perfil. En caso contrario las recibirá en el momento de su próximo logon (no se pierden). Si la cantidad de notificaciones esperadas es elevada. el perfil queda definido como NOWARNING. queda como usuario a ser notificado quien ejecutó el comando RDEFINE. La información se graba en registros tipo 80 del SMF.). recibirá las notificaciones en tiempo real. por ejemplo). o FAILURES se grabarán intentos de acceso fallidos. De todos modos. Listas de acceso. Intentos de acceso superiores a READ que resulten fallidos son también registrados. Si el usuario especificado se encuentra con una sesión de TSO activa. Este es el modo en que deben encontrarse normalmente todos los perfiles de la base. y establece que se registre todo intento de acceso denegado por el perfil. Si el perfil modelo tiene miembros. DATA.93 corto de tiempo. el operando FVOLUME debe indicar el volumen correspondiente del perfil modelo. pero no entraremos en detalle sobre las mismas. Sólo es necesario si FCLASS es DATASET y perfil2 es un “genérico completo”. como ser: o o o Clase a la que pertenece el perfil Operandos especificados en el comando RDEFINE Seteo de la opción GENERICOWNER de la SETROPTS No vamos a efectuar un análisis detallado y exhaustivo de todas las situaciones que se pueden presentar. solo se procesa el especificado en último término.8 . o se codificó con un perfil genérico. 6. RACF ignora el operando FGENERIC si no se codificó FROM. Si el operando FROM especifica un perfil discreto de DATASET. como sucede con todos los comandos de modificación de perfiles.94 FGENERIC indica a RACF que el perfil especificado en el operando FROM es genérico.en el mismo comando. o con un perfil de una clase que no sea DATASET. básicamente. Si se codifican ambos operandos -ADDMEM y DELMEM.Eliminación de un perfil de recursos generales Sintaxis: RDELETE|RDEL clase nombre-del-perfil Apuntes de RACF Juan Mautalen . A grandes rasgos.7 . Si el perfil es discreto. existen restricciones adicionales. Para ciertos operandos. Tener el atributo SPECIAL a nivel de un grupo que tenga al perfil dentro de su campo de acción. Ser el owner del perfil. digamos que los usuarios autorizados a definir nuevos perfiles son aquellos con el atributo SPECIAL o con CLAUTH sobre la clase. Con el operando DELMEM se borra un miembro del perfil. el operando FVOLUME es ignorado. tener autoridad ALTER sobre el perfil. Autoridad requerida La autoridad requerida depende de varios factores. aún cuando no contenga caracteres genéricos. cumplir alguno de los siguientes requisitos: Tener el atributo SPECIAL a nivel de sistema.Modificación 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. Autoridad requerida Para modificar un perfil de recursos generales. quien ejecuta el comando debe. o si se omite y existe más de un perfil discreto con ese nombre. Si se codifica FVOLUME con un valor distinto al que corresponde. 6. como ADDMEM. solo es necesario codificar los operandos a modificar. Si no se especificó el operando FROM. Aquellos no especificados mantienen sus valores previos (no se cambian a valores por defecto). el comando falla. Por lo tanto. RACF lo informa. si existiese. a diferencia de este último. no hay manera de listarlo individualmente. Si tal perfil no existiese. serán listados todos los perfiles discretos de la clase. Ser el owner del perfil. Si el perfil es discreto. Si en lugar de nombre-del-perfil se codificó *. AUTHUSER indica que se debe incluir en la salida del comando la siguiente información: o Security level. básicamente. En caso contrario. informa sencillamente que el perfil requerido no existe. categories y security label o Lista de acceso estándar o Lista de acceso condicional Apuntes de RACF Juan Mautalen . tener autoridad ALTER sobre el perfil. resulta ser efectivamente el perfil protector). quien ejecuta el comando debe. Sin embargo. un perfil que proteja a todos los recursos que no se encuentren protegidos por uno más específico). la información listada dependerá de lo que se especifique como nombre de recurso. la información listada dependerá de lo que se especifique como nombre de recurso. si se quiere definir un “perfil abarcativo” (backstop profile) en la clase (o sea. Si no se codifica GENERIC o NOGENERIC. Si se codifica el operando GENERIC. si existiese.9 . En caso contrario. NOGENERIC indica que se debe listar el perfil discreto que coincida con el nombre especificado. entonces RACF listará únicamente el perfil que coincida exactamente con el nombre especificado. si existiese un perfil discreto. se listarán todos los perfiles de la clase que el usuario esté autorizado a ver. En caso de existir el perfil genérico *. de acuerdo al siguiente criterio: o o o Si nombre-del-perfil no contiene ningún caracter genérico. no se mostrará (y. serán listados todos los perfiles (discretos y genéricos) de la clase. 6.95 Autoridad requerida Para deletear un perfil de recursos generales. RACF listará el perfil genérico que más se ajuste al nombre de recurso especificado.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. sí es factible listarlo por separado con el comando “RLIST clase **”. Tener el atributo SPECIAL a nivel de un grupo que tenga al perfil dentro de su campo de acción. Si nombre-del-perfil contiene algún carácter comodín. de acuerdo al siguiente criterio: o o o Si nombre-del-perfil no contiene ningún caracter genérico. informa sencillamente que el perfil no existe. sin embargo. Si en lugar de nombre-del-perfil se codificó *. entonces RACF listará únicamente el perfil que coincida exactamente con el nombre especificado. es preferible crear el perfil ** en lugar de * pues. Si nombre-del-perfil contiene algún carácter comodín. cumplir alguno de los siguientes requisitos: Tener el atributo SPECIAL a nivel de sistema. RACF listará el perfil protector del recurso. serán listados todos los perfiles genéricos de la clase. que podrá ser discreto o genérico. Si en lugar de nombre-del-perfil se codificó *. básicamente. el operando RESGROUP es ignorado.|*})] 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 continuación del comando PERMIT. Ser el owner del perfil.96 ALL establece que se liste toda la información del segmento base. Autoridad requerida Para listar un perfil de recursos generales. Tener autoridad READ (o superior) sobre el perfil. sobre un perfil discreto. 6. quien ejecuta el comando debe. En caso contrario. debe especificarse el parámetro correspondiente. Existir una entrada en la GLOBAL para el perfil que otorgue autoridad ALTER.. se modifican a través del comando PERMIT. Si no se especifica. Para que se liste el campo GLOBALAUDIT. tener autoridad ALTER sobre el perfil. Existir una entrada en la GLOBAL para el perfil que otorgue autoridad READ (o superior). Para ver las listas de acceso. por lo cual debe codificarse obligatoriamente para una clase de recursos generales.10 . quien ejecuta el comando debe tener el atributo AUDITOR (ya sea a nivel de sistema. aunque debe tenerse siempre presente que el nivel de autoridad ALTER. las listas de acceso son irrelevantes (STARTED o GLOBAL. Como ya hemos visto. se debe satisfacer alguna de las siguientes condiciones: Tener el atributo SPECIAL. Si el perfil es discreto.Permisos sobre perfiles de recursos generales Las listas de acceso de perfiles de recursos generales. Para ciertas clases. Ser el owner del perfil. confiere autoridad administrativa (generalmente no deseada). o a nivel de un grupo que tenga al perfil dentro de su campo de acción). CLASS indica la clase a la que pertenece el perfil. Sintaxis: PERMIT|PE ‘nombre-del-perfil’ CLASS(clase) [ID({usuario/grupo. RESGROUP indica que se genere una lista de todos los perfiles de la clase que tengan al recurso especificado dentro de sus miembros. AUDITOR u OPERATIONS a nivel de un grupo que tenga al perfil dentro de su campo de acción. el valor por defecto es DATASET. cumplir con alguno de los siguientes requisitos: Tener el atributo SPECIAL. Si la clase tiene una clase agrupadora. el listado no muestra ni las estadísticas ni las listas de acceso. tanto la estándar como la condicional. AUDITOR u OPERATIONS a nivel de sistema. Para listar los eventuales segmentos no base. AUDITOR u OPERATIONS a nivel de un grupo que tenga al perfil de su campo de acción. Tener el atributo SPECIAL. Apuntes de RACF Juan Mautalen . Tener el atributo SPECIAL.. por ejemplo). AUDITOR u OPERATIONS a nivel de sistema. las modificaciones se efectúan sobre la lista de acceso estándar (aunque los operandos FROM o RESET pueden impactar igualmente sobre la lista de acceso condicional). eliminar todas las entradas). el operando FVOLUME es ignorado. Separados por espacios pueden ingresarse más de un usuario/grupo. aún cuando no contenga caracteres genéricos. o si se omite y existe más de un perfil discreto con ese nombre. o se codificó con un perfil genérico. Es decir. que indica que se pretende modificar la lista de acceso condicional. Más aún. el operando FVOLUME debe indicar el volumen correspondiente. solo tiene sentido si perfil2 es un perfil de dataset.11 . CONTROL y ALTER. 6. que representa un usuario cualquiera existente en la base de RACF. EXECUTE. RESET(ALL) vacía ambas.Comando SEARCH Sintaxis: SEARCH|SR [CLASS({DATASET|clase})] [{ALL|GENERIC|NOGENERIC|MODEL|TAPE|VSAM|NOVSAM}] [CATEGORY(categoría)|EXPIRES(valor)|LEVEL(valor)| SECLABEL(label)|SECLEVEL(level)|WARNING] [FILTER(cadena)] [{MASK({cadena1|*}[. Si se codifica RESET sin ningún valor. Si se codificara FVOLUME con un valor distinto al que corresponde al perfil2.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. Si no se especificó el operando FROM. En ambos casos. El operando WHEN indica que se quiere modificar la lista de acceso condicional. entonces la misma no se modifica. Si se codifica ACCESS sin poner ningún valor. RESET(STANDARD) vacía únicamente la lista de acceso estándar. FROM especifica el nombre de otro perfil (discreto o genérico) del cual se quieren copiar las listas de acceso (estándar y condicional). se asume por defecto ALL. Las entradas en las listas de acceso del perfil2 son agregadas a las listas de acceso correspondientes. se asume por defecto ACCESS(READ). Por lo tanto. No describiremos los distintos suboperandos que admite. modificar o eliminar. en tanto que RESET(WHEN) hace lo propio con la condicional. Apuntes de RACF Juan Mautalen . si una entrada que figura en la lista de acceso del perfil2 ya se encuentra en la del perfil en cuestión. ACCESS establece el nivel de autoridad que se quiere otorgar al usuario/grupo especificado en el operando ID. Si se omite WHEN. RACF ignora el operando FGENERIC si no se codificó FROM. pero se omitió tanto ACCESS como DELETE. Los posibles valores son NONE. FGENERIC indica a RACF que el perfil especificado en el operando FROM es genérico. UPDATE. DELETE indica que se pretende borrar de la lista de acceso la entrada correspondiente al usuario/grupo codificado en el operando ID. READ. se asume por defecto que perfil2 pertenece a la misma clase que el perfil en cuestión. Si omite FCLASS y se codificó FROM. el comando falla. ya sea con ACCESS o DELETE. Si el operando FROM especifica un perfil discreto de DATASET. excepto que se codifique explícitamente el operando WHEN. Si se especificó ID. También se acepta el valor *. se asume READ. o con un perfil de una clase que no sea DATASET. FCLASS indica la clase a la que pertenece el perfil especificado en el operando FROM. el operando FROM no convierte en idénticas las listas de acceso de ambos perfiles.97 ID indica el usuario o grupo cuya entrada en la lista de acceso se desea agregar. El operando RESET indica que se pretende vaciar una o ambas listas de acceso (es decir. RACF actúa sobre la lista de acceso estándar. o bien ya se encuentren expirados. Si se codifica * y la clase es DATASET.*. * y **).xyw* (no tiene un tercer calificador. cuyo valor está comprendido entre 00 y 99.qwe. de modo que sean listados únicamente los perfiles cuyos nombres estén alcanzados por el patrón establecido.que satisfagan los demás criterios fijados por los restantes parámetros del comando SEARCH.xyzw. opcionalmente. o EXPIRES solo se aplica a la clase TAPEVOL.98 CLASS especifica la clase dentro de la cual se buscan los perfiles. Las opciones MODEL|TAPE|VSAM|NOVSAM solo tienen sentido para la clase DATASET (son directamente ignoradas si la clase especificada es otra). y pueden codificarse en cualquier calificador (incluso en el primero): . este operando es ignorado. Ejemplo: FILTER(a%%.% indica un único carácter cualquiera (inclusive % y *) . Si se omite. LEVEL establece que se listen los perfiles cuyo LEVEL coincida con el especificado. Cadena2 establece. este operando es ignorado.xyz. mientras que NOGENERIC la limita a perfiles discretos. SECLABEL y SECLEVEL. USER. Si la clase es USER o GROUP.** indica la presencia de 0 o más calificadores. También en este caso se o Apuntes de RACF Juan Mautalen . .* indica la presencia de 0 más caracteres (inclusive genéricos) hasta concluir el calificador. No nos ocuparemos de CATEGORY. exige la existencia de ese calificador en los nombres que abarca. Si se codifica. pero pierden su significado comodín y son exigidos literalmente. Si es usado como un calificador completo.qwe (tiene 4 caracteres en el primer calificador) a21. GENERIC restringe la búsqueda a perfiles genéricos. GROUP o cualquier otra clase definida en la CDT. el identificador del usuario que ejecuta el comando se toma como máscara.efgh. El valor por defecto es ALL.qwe Sin embargo. ALL indica que se listen todos los perfiles –genéricos o discretos.xyz%%%.fin aa*. una segunda cadena de caracteres que debe contener el nombre del perfil en cualquier lugar a continuación de cadena1.**) alcanzaría a los siguientes nombres de perfiles: a21. El valor debe estar comprendido entre 0 y 65533. 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. o bien ser 99999 (archivos que nunca expiran).xy*. solo se listarán los volúmenes tales que todos sus archivos. Se admiten caracteres genéricos. Se puede codificar DATASET. WARNING indica que se listen los perfiles que se encuentre en modo warning. o bien lo harán dentro de la cantidad de días especificados. no alcanzaría a: ab23. el valor por defecto es DATASET. o o FILTER permite indicar una cadena de caracteres (incluyendo los caracteres comodín %. El significado de los caracteres genéricos es similar al que tienen en el caso de perfiles. CATEGORY|EXPIRES|LEVEL|SECLABEL|SECLEVEL|WARNING Mediante estos operandos se establecen criterios de búsqueda. Si la clase es USER o GROUP. que es exigido) El operando MASK. excluyente con el operando FILTER. Recordemos que se trata de un campo de uso administrativo. Sólo puede usarse como un calificador completo.asdf. Esta opción funciona únicamente para perfiles discretos de clases para las cuales se mantengan estadísticas. de modo que los comandos resulten sintácticamente correctos. debería 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. El valor codificado debe estar comprendido entre 0 y 99999. establece el texto que se antepondrá en cada registro al nombre del perfil. que debe estar igualmente entre apóstrofes simples.EXEC. El operando FILTER es más flexible que MASK. La lista se graba en un archivo de nombre PREFIX. Para ello. o Cadena1.IGG. se toma la fecha de creación del usuario como referencia.99 admiten caracteres genéricos. El archivo grabado podría tener los siguientes registros: 00000010RLIST FACILITY STGADMIN. o sea el owner. se listarán los grupos que hayan sido creados con anterioridad a la fecha que resulte de sustraer a la actual la cantidad de días especificados. Si la clase es USER.RACF. El operando USER(usuario) indica que se deben listar los perfiles que cumplan con los criterios de selección establecidos y sobre los cuales el usuario codificado tenga autoridad READ o superior. Notemos que para todas las clases excepto DATASET. En el caso en que LAST-ACCESS tenga el valor UNKNOWN. Ejemplo: Supongamos que se pretende listar la información completa de todos los perfiles de la clase FACILITY cuyo nombre empiece con la cadena de caracteres STGADMIN. NOMASK y MASK(*) son equivalentes. pero no tienen su significado usual sino que son tomados literalmente.** ALL Apuntes de RACF Juan Mautalen . Adicionalmente. su identificador de usuario se usaría como HLQ del dataset).** ALL 00000020RLIST FACILITY STGADMIN.CLIST. El operando CLIST es útil cuando se quiere ejecutar idénticos comandos de RACF sobre los perfiles que resulten de la búsqueda. pues permite criterios de búsqueda más sofisticados. ya que no fijan restricciones sobre los nombres de los perfiles. o Cadena2.IDC. El operando CLIST determina que se genere una CLIST (command list) con los nombres de los perfiles que resulten de la búsqueda (1 registro por cada perfil encontrado).** ALL 00000040RLIST FACILITY STGADMIN. entonces el defecto es MASK(*). que debe codificarse entre apóstrofes simples. esté conectado con atributo SPECIAL o AUDITOR. o bien sea el owner.ADR. NOMASK establece que se listen todos los perfiles de la clase que cumplan con el resto de los criterios. establece el texto que se agregará en cada registro inmediatamente a continuación del nombre del perfil. AGE establece que se listen únicamente los perfiles que no han sido referenciados dentro de la cantidad de días especificados (contados hacia atrás desde el actual). Es importante recalcar que el comando solo genera la CLIST. Si la clase es GROUP. Si no se codifica MASK|NOMASK (ni FILTER). dónde PREFIX indica el prefix de TSO del usuario que ejecuta el comando SEARCH (si tuviera noprefix en su profile de TSO. No la ejecuta. En realidad. un número de secuencia de 8 posiciones es colocado al principio de cada registro. Si la clase especificada es GROUP. solo son listados aquellos que el usuario está autorizado a ver. se listarán los usuarios cuyo LAST-ACCESS sea anterior a la fecha que resulte de sustraer a la actual la cantidad de días especificados. serán listados los grupos para los cuales el usuario codificado esté conectado con autoridad CONNECT o JOIN.** ALL 00000030RLIST FACILITY STGADMIN. solo que únicamente le serán mostrados los nombres de los perfiles que este autorizado a ver. 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 acción. bastaría ejecutarlos a través del comando EXEC de TSO.100 Luego. Para poder usar SEARCH con el operando USER. Tener autoridad READ (o superior) sobre el perfil. Autoridad requerida Todo usuario está autorizado a ejecutar el comando SEARCH. Ser el owner del usuario codificado en el operando USER El usuario codificado en el operando USER debe coincidir con el propio. Tener el atributo OPERATIONS a nivel de sistema o a nivel de un grupo que tenga al perfil dentro de su campo de acción y la clase estar alcanzada por este atributo. Básicamente. para poder ver el nombre de un perfil. Apuntes de RACF Juan Mautalen . 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 acción. CONTROL o ALTER (EXECUTE no está permitido en la GAC). la GAC se consulta en primera instancia. debe activarse su chequeo de la GLOBAL. 7. &RACUID se reemplaza por el usuario actual mientras que la variable &RACGPID indica su “actual grupo de conexión”. en realidad. Por lo tanto. una organización puede normalmente manejar satisfactoriamente su seguridad activando solo una cantidad limitada de ellas.101 7 . La GAC permite autorizar el acceso a un recurso a cualquier usuario (con excepción únicamente de aquellos con el atributo RESTRICTED).Consideraciones generales Existe una gran cantidad de clases de recursos generales. durante el proceso de chequeo de autorización que lleva a cabo RACF. la GAC solo puede utilizarse para responder favorablemente solicitudes de acceso.CLASES PARTICULARES 7. si se pretende definir reglas en la GAC para una determinada clase. Las reglas se componen de un “nombre de recurso” acompañado del correspondiente nivel de acceso. El “nombre de recurso” debe seguir los mismos lineamientos que los perfiles de la clase. o Los nombres de recurso pueden incluir variables definidas en la clase RACFVARS. RACF continúa con su chequeo habitual.2 . que estudiaremos en forma precisa en un capítulo posterior. Para definir reglas en la GAC para una determinada clase. UPDATE. que abreviaremos GAC (Global Access Checking Table). Algunas de estas clases están descriptas en detalle en la bibliografía de RACF. que permiten proteger recursos de muy variada naturaleza. Las reglas se definen luego como miembros del perfil. ejecutando el comando: SETROPTS GLOBAL(clase) Recordemos que la clase especificada no puede ser una clase agrupadora. Únicamente actúa la GAC para aquellas clases que tienen GLOBAL especificado en la SETROPTS. Los siguientes comandos muestran como incorporar una regla en la GAC para una determinada clase: Apuntes de RACF Juan Mautalen . READ. debe definirse en principio un perfil en la clase GLOBAL cuyo nombre coincida con el de la clase. mientras que otras son tratadas en profundidad en la documentación del producto que las utiliza.Clase GLOBAL Podemos imaginar a la “tabla de acceso global”. una clase de RACF. los caracteres genéricos pueden usarse en cualquier calificador. a través del operando ADDMEM. Si no contiene información que autorice el requerimiento.1 . como una tabla que contiene una lista de “recursos” asociados con un determinado “nivel de acceso”. incluso el primero. El nivel de acceso puede ser NONE. En efecto. pero nunca rechazarlo. Es importante recalcar que la GAC puede autorizar un requerimiento de acceso. Construcción y mantenimiento de la GAC GLOBAL es. sin que RACF analice el perfil protector. Analizaremos a continuación algunas clases de recursos generales que consideramos particularmente importantes y cuyo uso es muy frecuente. RACF responde favorablemente sin continuar con el chequeo habitual de perfiles. Por lo tanto. con las siguientes importantes flexibilidades adicionales: o Si la clase en cuestión tiene GENCMD especificado en la SETROPTS. o Los nombres de recurso pueden contener las variables &RACUID y &RACGPID como calificadores. Como ya comentáramos. Si la información que contiene indica que el acceso debe otorgarse. Un administrador de RACF debe conocer perfectamente el funcionamiento y alcance de las clases que se utilizan efectivamente en su organización. con excepción del dataset SYS1. Asumimos que en la SETROPTS la clase DATASET está bajo GENCMD y que la opción EGN está activa. Apuntes de RACF Juan Mautalen . Esto evita problemas si involuntariamente se borra la regla de la GAC. RACF consulta las reglas para la clase DATASET en la GAC (ya que DATASET está bajo GLOBAL en la SETROPTS). el comando no solo borraría la regla en cuestión sino que deletearía el perfil.UADS.UADS. es conveniente garantizar idéntico acceso a través del UACC del perfil protector. y RACF continúa con el análisis de los perfiles correspondientes (recordemos que la GAC nunca rechaza por sí misma un requerimiento de acceso). Asimismo. si tenemos la siguiente regla en la GAC: USRCAT. En cualquier caso. el comando sería: RALTER GLOBAL clase DELMEM(‘nombre-del-recurso’/nivel-de-acceso) Debe tenerse cuidado. En nuestro ejemplo. o se inhabilita en la SETROPTS la opción GLOBAL para la clase. se pretende que todos los archivos cuyo HLQ es SYS1 sean accedidos por todos los usuarios con autoridad READ. En este ejemplo.**’ con UACC(UPDATE). ya que si en lugar de RALTER se especifica RDELETE. la GAC no permite otorgar el acceso solicitado. Por lo tanto. 1) SETROPTS GLOBAL(dataset) 2) RDEFINE GLOBAL DATASET 3) RALTER GLOBAL DATASET ADDMEM(‘sys1. Por ejemplo. con lo cual se eliminarían todas las reglas de la GAC para la 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.**’/update) 6) SETROPTS GLOBAL(dataset) REFRESH Cuando RACF analiza el contenido de la GAC para resolver sobre una solicitud de acceso.uads’/none) 5) RALTER GLOBAL DATASET ADDMEM(‘usrcat. se pretende otorgar UPDATE a todos los usuarios a los catálogos de usuario. luego de efectuar una modificación en la GAC para cierta clase. o bien debe seguir con el proceso de chequeo habitual. RACF detecta la entrada que mas se ajusta al recurso solicitado y en base a ella decide si debe otorgar el acceso inmediatamente. Asimismo.**’/read) 4) RALTER GLOBAL DATASET ADDMEM(‘sys1. suponemos que no existe el perfil DATASET en la clase GLOBAL y que la misma no está bajo GLOBAL en la SETROPTS. procede de manera similar a como lo hace con perfiles.**/UPDATE resulta conveniente tener asimismo un perfil de dataset ‘USRCAT. Consideraciones: Los usuarios con el atributo RESTRICTED son los únicos que no pueden obtener acceso a un recurso a través de la GAC. Esto es. Aún cuando exista en la GAC una regla que permita acceder a un recurso bajo cierto nivel de autoridad. y encuentra que la entrada que más se ajusta es SYS1.102 RDEFINE GLOBAL clase RALTER GLOBAL clase ADDMEM(‘nombre-del-recurso’/nivel de acceso) Para borrar una regla existente.UADS. cuyo nivel de acceso asociado es NONE. cuyos nombres suponemos tienen HLQ igual a USRCAT (y son los únicos con este HLQ). si un usuario intenta leer el archivo SYS1. las mismas se muestran ordenadas según el criterio de mayor especificidad. recién entonces examina la ICHRIN03. en muchos casos. con entradas únicamente para ciertas started task críticas del sistema operativo. luego de modificado. es necesario que las STC tengan una identidad asignada. Si la clase STARTED está activa. Si no lo encuentra. La asignación de usuario y grupo puede realizarse a través de la definición de un perfil en la clase STARTED o mediante una entrada apropiada en una tabla assembler de nombre ICHRIN03 (Started Procedures Tables). Cuando se listan las reglas existentes en la GAC para una determinada clase. por ejemplo). está activa la opción GRPLIST. Debe compilarse y linkeditarse como si se tratara de un programa assembler. en un procedimiento que se arranca con el comando de operador START (o bien asociada directamente con un componente del sistema operativo. si como recomendamos. Si la opción GRPLIST no está activa en la SETROPTS –opción improbable en la actualidad-. entonces el grupo de conexión resulta irrelevante y el usuario tendrá acceso a los recursos a través de cualquiera de sus grupos. Actúa. RACF no tendrá en cuenta el nivel de auditoría del perfil protector (ya que dicho perfil no es ni siquiera determinado). no tienen una tarjeta job dónde figure usuario y grupo (o que se reciban propagados). con el comando “RLIST GLOBAL clase”. tengamos presente que el módulo ICHRIN03 debe existir. sin embargo. CICS es un ejemplo de ello.PROCLIB. la GAC no actúa. En cambio. razón por la cual IBM introdujo la clase STARTED. 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). Si el acceso a un recurso es otorgado por la GAC. De todos modos. ya que no es posible refrescarlo dinámicamente dado el sector de memoria donde se aloja. Esto permitirá que inicie el sistema operativo ante una eventual inactivación involuntaria de la clase Apuntes de RACF Juan Mautalen . costosos I/O sobre la base de RACF. como básicamente solo usuarios o grupos definidos en RACF pueden acceder a recursos protegidos. a diferencia de los trabajos batch. El uso de la GAC puede mejorar la performance al evitarse. La ICHRIN03 es una tabla residente en la LPA (Link Pack Area) o en la MLPA (Modified Link Pack Area). como DFSMS). Naturalmente. Recomendamos tener una ICHRIN03 mínima. que permite un manejo dinámico.103 Para ciertas aplicaciones que utilizan la macro RACROUTE REQUEST=FASTAUTH. la opción global de auditoría para la clase establecida en la SETROPTS a través del operando LOGOPTIONS. aún cuando solo contenga definiciones de constantes y carezca de instrucciones propiamente dichas. Las STC. Son excelentes candidatos para la GAC recursos de uso muy frecuente que deban ser accedidos en forma universal. Mas aún.Clase STARTED Una started task. Si el acceso a un recurso es otorgado por la GAC. RACF ni siquiera determina qué perfil protege efectivamente al recurso.3 . también conocida como STC. ya que en caso contrario RACF no inicializa. para que el nuevo módulo entre en vigencia es necesario dar IPL. Reside en bibliotecas de procedimientos declaradas en la parametrización del JES (SYS1. entonces solo se tendrá en cuenta el grupo especificado al momento de resolver solicitudes de acceso del usuario a recursos protegidos. Más aún. el usuario debe estar conectado al grupo especificado. 7. RACF busca en principio un perfil en esta clase que asigne una identidad válida al procedimiento. RACF no actualiza las eventuales estadísticas que pudiera tener el perfil protector. Por lo tanto. Estos inconvenientes hacen que la utilización de esta tabla estática de asignación sea muy poco práctica. resultan irrelevantes. Para simplificar. 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 contadísimas excepciones.jobname. los campos UACC. el perfil genérico cnmproc. vamos a ocuparnos exclusivamente del caso de procedimientos. ya que es lo más frecuente. No entraremos en detalles en esta guía sobre la construcción de la ICHRIN03. muy poco frecuentes y que no vale la pena mencionar) serán otorgados. La información determinante de los perfiles de la clase STARTED se encuentra en el segmento no base denominado STDATA. busca en la clase STARTED el perfil que más se ajuste al nombre cnmproc. pero también aquí la definición se realiza de todos modos. o si el usuario especificado en el operando USER no se encuentra conectado a él. Definición 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. pero la definición se realiza de todos modos. Esto se logra ejecutando el siguiente comando: SETR CLASSACT(STARTED) RACLIST(STARTED) GENERIC(STARTED) Con las versiones actuales del z/OS. si no se especifica en el comando START un jobname distinto. entre otros. para asignar identidad al procedimiento. el recurso correspondiente sería miembro. al no tratarse de perfiles que protejan acceso a recursos. Si el grupo codificado no existe. por ejemplo. en cuyo caso RACF asignará el usuario que coincida con el nombre del miembro -si existiera. Existe la opción de codificar el valor “=MEMBER” en lugar de un identificador de usuario. Al arrancarse una STC. El valor por defecto es PRIVILEGED=NO. dónde miembro indica el miembro de la biblioteca dónde se encuentra el procedimiento (el nombre del procedimiento propiamente dicho.*. AUDIT y listas de acceso. aún cuando la configuración de auditoría lo requiera. establecido en la primer sentencia del JCL. vamos a suponer que la clase STARTED está activa. que podría ser. Apuntes de RACF Juan Mautalen .miembro.cnmproc. Tales accesos exitosos no actualizarán estadísticas ni generarán registros de SMF. RACLISTeada y que admite perfiles genéricos. Recursos y perfiles de la clase STARTED En lo que sigue. Ejemplo: Supongamos que se ejecuta el siguiente comando de operador: START cnmproc RACF.104 STARTED. se construye el nombre de recurso miembro. Si. por el contrario. cuyos campos describiremos a continuación USER establece el usuario que se asociará con el procedimiento. RACF busca entonces el perfil en la clase STARTED (discreto o genérico) que más se ajuste a este nombre y lo usa para la asignación de identidad. RACF alerta sobre la situación enviando un mensaje. GROUP establece el grupo que se asociará con el procedimiento. Existe la opción de codificar el valor “=MEMBER” en lugar del nombre de un grupo. se especificara el parámetro JOBNAME en el comando START. pero ejemplos concretos se pueden consultar en la documentación de IBM. no entra en juego). RACF alerta sobre la situación emitiendo un mensaje. sin efectuar el chequeo correspondiente. el comando START de MVS permite startear no solo una STC sino también un job. Si el usuario codificado no existe en la base. por el contrario. que la posibilidad de auditar una tarea marcada TRUSTED es bastante limitada y poco flexible. con usuario y grupo válidos. TRACE=YES indica que RACF informará. El valor por defecto es TRACE=NO. no solo se grabaría información para esta STC sino para todos los accesos a recursos protegidos en la clase. de todos modos. Debe señalarse. con la diferencia de que sí se generarán registros de SMF de acuerdo a la configuración de auditoría correspondiente. se audita una clase específica. Estando la clase STARTED activa –como es absolutamente recomendable-. Consideraciones: Si una started task no adquiere una identidad válida. debe codificarse el operando STDATA en el comando RALTER especificando solo el suboperando a modificar. mediante un mensaje por consola. 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. La mayoría de las STC no deben estar marcadas ni TRUSTED ni PRIVILEGED. al otorgarse los accesos sin consulta a los perfiles protectores. a saber: RALTER. o incluso que el sistema no inicie o funcione correctamente. sólo se generarán registros de auditoría si el usuario tuviera el atributo UAUDIT. Más adelante damos una lista de STC que IBM sugiere ejecutar como TRUSTED. para evitar que una eventual falta de autorización cause serios trastornos operativos. pudiéndose generar un volumen muy grande de información innecesaria. y solo puede acceder a los recursos cuyo UACC sea lo suficientemente permisivo.105 TRUSTED=YES se comporta de manera similar a PRIVILEGED=YES. En estos casos. 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. En efecto. o si la clase a la que pertenece el recurso estuviera auditada a nivel de la SETROPTS. si bien posible. existen ciertos procedimientos críticos del sistema operativo para los cuáles IBM recomienda estos atributos. Si. En el primer caso. Sin embargo. suele ser problemática. se grabaría información para todos los accesos de la STC. o Existe un perfil con segmento STDATA pero el grupo especificado no existe en la base. Existe un perfil con segmento STDATA pero sin usuario especificado. para contar eventualmente con alguna información de auditoría grabada en registros SMF. RDELETE y RLIST. Para modificar. Para cambiar el valor de un campo del segmento STDATA. Para listar la información completa de un perfil de la clase STARTED debe ejecutarse el comando “RLIST STARTED nombre-del-perfil STDATA”. sin posibilidad de discriminación alguna. Esta opción puede resultar útil como herramienta de diagnóstico para resolver ciertos problemas. Por lo tanto. En cambio. la auditoría de una STC indicada como TRUSTED. o Existe un perfil con segmento STDATA. JES2 es un ejemplo de un procedimiento que se aconseja ejecutar como TRUSTED. borrar o listar perfiles de la clase STARTED se utilizan los comandos habituales de manejo de perfiles de clases de recursos generales. tal cual es el defecto. pero el usuario no está conectado al grupo. recomendamos usar TRUSTED en lugar de PRIVILEGED. toda vez que el perfil sea usado para la asignación de usuario. En definitiva. Apuntes de RACF Juan Mautalen . las opciones de auditoría que éstos tengan configuradas no son tomadas en cuenta. Si se omite STDATA. corre bajo un usuario indefinido. solo se mostrará la información del segmento base y no se visualizará la información determinante para la asignación de identidad. Deben tener un usuario asignado que tenga solo los accesos necesarios. El valor por defecto es TRUSTED=NO. es aconsejable verificar regularmente que los usuarios asociados con las STC no se encuentren revocados. De esta manera se evitan usos indebidos del usuario. Sin embargo. La asignación del usuario a la STC se realiza en el momento de su inicio. Su implementación requiere un importante esfuerzo de configuración de perfiles en la clase PROGRAM (y sólidos conocimientos en la materia). Por ejemplo. VTAM. DUMPSRV. IBM recomienda que los siguientes procedimientos se ejecuten como TRUSTED: CATALOG. si la STC submite un job al internal reader). JESXCF. entonces es un excelente candidato para otorgarle el atributo PROTECTED. DFS. lo cual no debería ser peligroso desde la perspectiva de la seguridad. Es de destacar que estando correctamente definido este backstop en la clase STARTED. RACF no chequea la eventual revocación del usuario asignado. Una opción aún más radical consistiría en otorgarle a tal usuario el atributo RESTRICTED. TCPIP. en cuyo caso el procedimiento no podría acceder a ningún recurso protegido. XCFAS.Clase PROGRAM El funcionamiento de la clase PROGRAM es ciertamente complejo. lo realmente importante es que toda STC se encuentre perfectamente identificada y con un usuario debidamente asignado a través de la clase STARTED. Una consecuencia de esto es que. La clase STARTED debe necesariamente estar RACLITeada. es probable que la tarea tenga problemas posteriormente. OMVSKERN. De este modo. si solo se modifica un campo del segmento STDATA de un perfil existente. No resulta habitualmente necesario. la modificación solo tomará efecto una vez que se recicle la STC (es decir. y de manera complementaria. Una vez que determina el perfil que usará para asignar identidad (operación rápida. Aconsejo fuertemente seguir las recomendaciones de IBM y asignar TRUSTED siempre que se lo sugiera. así como también revocaciones maliciosas por intentos de logon fallidos ingresando passwords incorrectas. Asimismo. cuyo usuario asignado no tenga ninguna autorización explícita sobre ningún perfil. Con el objeto de mantener un adecuado control de las STC en el sistema. RMF. no discutiremos en esta guía ninguno de los siguientes temas: Modo de protección ENHANCED. 7. En cualquier caso. RMFGAT. JES2 o JES3. Sin embargo. RACF. tanto si se cambia el usuario asignado como si se le otorga (o quita) algún atributo. GPMSERVE. VLF. pues tiene los nombres en memoria virtual) hará un I/O sobre la base para extraer el segmento STDATA correspondiente. NFS. Esto determina que el procedimiento efectivamente arrancará.106 En el inicio de una STC. Si un usuario es utilizado exclusivamente para ser asignado a una started task. IXGLOGR. RACF nunca revertirá a la ICHRIN03 en su proceso de asignación de identidad. recomendamos definir un perfil de contención ** en la clase STARTED. SMF. DFHSM. En consecuencia. En la Apuntes de RACF Juan Mautalen . Aporta un nivel de protección mayor que el modo BASIC. que detente únicamente las autorizaciones necesarias para sus tareas. que se pare y reinicie). IEEVMPCR. en este caso particular. IOSAS. RACF no carga en memoria toda la información de sus perfiles sino solo sus nombres. Por lo tanto. LLA. deben estar adecuadamente protegidas las bibliotecas de procedimientos declaradas en JES. no será normalmente necesario ejecutar el comando de REFRESH. toda STC que no tenga un perfil más específico solo podrá acceder a recursos vía UACC (o * en la lista de acceso). SMSVSAM. si alguna acción que lleve a cabo controle efectivamente esta condición (por ejemplo. aún cuando el usuario se encuentre revocado.4 . y exponerlo en detalle está fuera de los objetivos de este curso introductorio. Un programa puede controlarse bajo RACF con diversos objetivos. es Apuntes de RACF Juan Mautalen . que puede ser pública. Así. En lo referente al segundo punto.107 primera línea del listado de la SETROPTS se visualiza claramente si el control de programas está activo y en qué modo. El nombre del perfil debe matchear con el nombre del programa a proteger. Como ya hemos señalado. Nivel de autoridad EXECUTE y “entorno limpio” (clean environment). mientras que la biblioteca dónde reside específicamente la versión en cuestión debe definirse como miembro del perfil. Porque es una exigencia del sistema que el programa esté controlado (usualmente. por ejemplo. pudiendo tratarse de distintas o idénticas versiones. Para hacer uso de la funcionalidad PADS. entre los que podemos mencionar: Para controlar qué usuarios/grupos están autorizados a ejecutarlo. Nos limitaremos pues a exponer ciertas nociones básicas relacionadas con la clase PROGRAM que todo administrador de RACF debe conocer. al tener que matchear con el nombre del programa. más que proteger un determinado medio de acceso. debe constar de un único calificador y no exceder los 8 caracteres. pero conviene recordar en este punto: A diferencia de las otras clases. Los perfiles de la clase PROGRAM no soportan el modo warning. no tiene mayor sentido proteger el programa invocado por el FTP (que no deja de ser uno de los tantos posibles métodos de transferencia). para activar el control de programas bajo RACF no es necesario activar la clase PROGRAM. la clase PROGRAM presenta ciertas particularidades que ya hemos mencionado. Si bien la clase PROGRAM no admite perfiles genéricos. definir un perfil ** en la clase PROGRAM con UACC=READ y una lista de bibliotecas asociadas cuyos programas necesiten estar controlados. RACF solo permite proteger un programa dentro de una biblioteca específica. Es posible. debe ejecutarse el comando “SETROPTS WHEN(PROGRAM) REFRESH” para que los cambios tomen efecto. tal cual veremos en los ejemplos subsiguientes. En la gran mayoría de los casos. o bien de programas francamente diferentes. deberían centrarse los esfuerzos en proteger adecuadamente los recursos a los que permite acceder. Acceso a archivos condicionado a la ejecución de determinado programa. esquema conocido como PADS (Program Access to Data Sets). como es en definitiva un programa. es altamente recomendable. para mantener lo que se conoce como “entorno limpio”). con perfiles de dataset adecuados. como aquellas que figuran en la LINKLIST. que el mismo nombre de programa exista en más de una biblioteca. sino que lo fundamental consiste en proteger los datos. Un programa que se encuentra protegido por un perfil en la clase PROGRAM se denomina programa controlado. y realmente frecuente aunque poco recomendable. o de uso privado. Protección de programas Todo programa reside en una biblioteca particionada. Si se modifica información de perfiles en la clase PROGRAM. sino que debe especificarse WHEN(PROGRAM) como opción en la SETROPTS. Definición 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. con lo cual la biblioteca especificada puede residir en cualquiera. Ejemplos: 1. Como ya hemos comentamos. con excepción de aquellos que pudieran estar protegidos por un perfil más específico. conviene definirlo como ** en lugar de *. la biblioteca puede existir en cualquier disco. RDEFINE PROGRAM ** UACC(read) ADDMEN(‘sys1. en nuestro ejemplo). según corresponda. solo estarían en condición de ejecutarlo aquellos usuarios o grupos autorizados vía la lista de acceso correspondiente. Obsérvese que este perfil se definió con UACC=READ. RDEFINE PROGRAM fin* UACC(none) ADDMEN(‘finanzas. Sin embargo.108 posible usar el caracter * al final del nombre del perfil.LINKLIB. que indica la presencia de 0 o más caracteres (hasta una longitud máxima de 8). que mencionamos a continuación. Este perfil no protege a otros programas de nombre ADRDSSU que pudieran existir en otras bibliotecas. al listarlos. Como el UACC del perfil es NONE. lo cual muestra que su objetivo no es restringir la ejecución de los respectivos programas sino simplemente convertirlos en controlados. de modo de poder listarlo individualmente. como sí sucede con los perfiles genéricos genuinos. el perfil protege a todos los programas de la biblioteca SYS1. RDEFINE PROGRAM adrdssu UACC(none) ADDMEM(‘sys1. lo cual indica que la biblioteca se encuentra alocada en el SYSRES (disco residente). es conveniente codificar explícitamente NOPADCHK (el valor por defecto es PADCHK). Modificación 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 . como se trata realmente de perfiles discretos. que es lo más habitual. El perfil definido en (3) es. ya que en caso contrario RACF antepone automáticamente como HLQ el PREFIX de TSO del usuario que ejecuta el comando. como ya señalamos. que no trataremos en esta guía. Si no se utiliza PADS. del sistema operativo). Con posterioridad a la creación del perfil.loadlib’//NOPADCHK) 3. También es posible definir un perfil **. sumamente útil para simplemente controlar –sin restringir su ejecución.LOADLIB.LINKLIB.los programas de determinadas bibliotecas (generalmente. Se le pueden agregar más bibliotecas a través del comando RALTER. El perfil definido en (1) protege exclusivamente al programa ADRDSSU residente en la biblioteca SYS1. Existe la posibilidad de codificar el valor ‘******’ (incluidos los apóstrofes).linklib’//NOPADCHK) 2. A través del operando ADDMEM se especifica la biblioteca dónde reside el programa a controlar. pueden agregarse o eliminarse bibliotecas de la lista usando el comando RALTER con los operandos ADDMEM o DELMEM. junto con ciertos parámetros adicionales. con excepción de aquellos que pudieran estar protegidos por un perfil más específico (como sería el caso de ADRDSSU. El perfil definido en (2) protege todos los programas cuyo nombre empiece con la cadena FIN y residan en la biblioteca FINANZAS. El volumen es opcional. El nombre de la biblioteca debe ponerse entre apóstrofes simples.linklib’//NOPADCHK) En ningún caso se codificó volumen. La opción PADCHK|NOPADCHK hace referencia a la funcionalidad PADS. y especifica el disco dónde reside la biblioteca. En este caso particular. no aparecerá la característica (G) a continuación del nombre del perfil. En caso de no especificarse volumen. sino que es utilizada por gran cantidad de aplicaciones. sino que debe recabarse separadamente en la propia de cada producto. basta con usar el operando DELMEM especificando el nombre y el volumen correspondiente (no hace falta codificar PADCHK|NOPADCHK). algunas facilidades de uso frecuente que pueden ser protegidas en esta clase. dada la necesidad operativa de dotar a ciertos usuarios con la facilidad de ejecutar el comando LISTUSER (típicamente personal del Helpdesk). en cambio. Nos limitaremos pues a mencionar.Clase FACILITY La clase FACILITY tiene la particularidad de no estar dedicada a la protección de un tipo de recurso específico. 7. los productos tienen comportamientos dispares frente a la condición de “recurso no protegido” (RC=04). Si se especifica únicamente el nombre de la biblioteca. lo que significaría un cambio cuyas consecuencias –presentes y futurasserían difíciles de prever. de otra empresa proveedora de software. Por lo tanto. productos y componentes del sistema operativo para efectuar chequeos de autoridad sobre recursos de la más diversa naturaleza. Dada la gran variedad de recursos factibles de ser protegidos. Para eliminar una biblioteca de la lista. a modo de ejemplo. Ejemplo: RALTER PROGRAM ** ADDMEN(‘tcpip. Facilidad para listar perfiles de usuario Normalmente. Concretamente. se debe proceder del siguiente modo: Apuntes de RACF Juan Mautalen . que una organización desarrolle una aplicación propia cuya seguridad se establezca vía RACF a través de perfiles en la clase FACILITY. si ésta existiese (en caso contrario.SEZALINK. Si se definiese el perfil **. la clase FACILITY se encuentra activa. En general. se borrará la entrada que no tenga volumen especificado. aunque a veces no del todo recomendable. autorizan el acceso. o desarrollado por la organización) puede potencialmente chequear recursos en la clase FACILITY. la información sobre esta clase no aparece centralizada en ninguna documentación.5 . lo rechazan. En tal caso. Es incluso frecuente. Usualmente. Algunos.109 En la lista de datasets del perfil pueden eventualmente existir varias entradas con el mismo nombre de archivo pero con distintos volúmenes asociados. brindan autorizaciones mucho más amplias y sensibles que las de simplemente listar la información de un perfil de usuario. todos los programas de esta biblioteca pasan a ser programas controlados -pero ejecutables por todos los usuarios en virtud del UACC(READ) del perfil. es altamente recomendable que esté RACLISTeada y configurada de modo que admita el uso de perfiles genéricos. todos los recursos pasarían a estar efectivamente protegidos. En consecuencia. considerando que cualquier producto (sea de IBM. no es posible realizar un análisis exhaustivo de los perfiles en esta clase. frente a la ausencia de un perfil protector. En virtud de lo anterior. Otros. Los perfiles deben tener una longitud máxima de 39 caracteres y los nombres están determinados por la aplicación que los utiliza. Mas aún. no es en absoluto recomendable definir un perfil abarcativo ** en la clase FACILITY. RACF brinda la posibilidad de delegar esta autorización a través de perfiles apropiados de la clase FACILITY. se informa que no existe). 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. para otorgar a un usuario la facilidad de listar el segmento base de cualquier otro. claro está.sezalink’//NOPADCHK) Este comando agrega a la lista de datasets del perfil ** la biblioteca TCPIP. Todas las consideraciones hechas previamente sobre clases de recursos generales se aplican para la clase FACILITY. solo agrega una posibilidad adicional en relación a la autoridad necesaria para listar perfiles de usuario.LISTUSER no se encuentra definido. rigen los chequeos de autoridad habituales para el uso del comando LISTUSER. también apareció naturalmente el requerimiento de dotar a ciertos usuarios de la posibilidad de rehabilitar a cualquier otro y eventualmente otorgarle una nueva password. Sin embargo. lo cual probablemente constituya un efecto no buscado. sería posible definir un perfil genérico que proteja al recurso (ej: IRR.RESET en la clase FACILITY.LISTUSER existe. Los privilegios habituales siguen siendo suficientes. En lugar del perfil discreto mencionado. 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). la posibilidad de darle mucha más granularidad a esta facilidad. de este universo. con UACC=NONE.).LISTUSER los usuarios con atributo SPECIAL. debe procederse del siguiente modo: 1) Definir el perfil IRR. desde la versión 1. ya que solo los usuarios cuyas tareas lo justifiquen deben contar con esta facilidad. Para ello. ya que este perfil estaría abarcando a otros recursos que pueden tener una necesidad de acceso diferente (ver ejemplo posterior). AUDITOR u OPERATIONS a nivel de sistema.10 del z/OS. autoridad ALTER otorga privilegios administrativos sobre el perfil. 2) Darle al usuario el nivel de autoridad deseado. Niveles de autoridad superiores a READ son equivalentes a READ. OMVS. Por ejemplo. sin embargo. 2) Darle al usuario nivel de autoridad READ.**). deben definirse perfiles adecuados en la clase FIELDS. Este recurso no autoriza a listar segmentos no base (TSO. en los detalles de una implementación de este tipo en el presente texto.LISTUSER en la clase FACILITY. o que se encuentren dentro del campo de acción de determinado grupo. con la siguiente salvedad: si el perfil es discreto. un usuario con atributo AUDITOR a nivel de sistema no requiere estar autorizado a este perfil. sino por estimar que excede los objetivos planteados. la autorización sobre este recurso permite listar cualquier usuario de la base de RACF. etc. E incluso la posibilidad de excluir. esto no me parece recomendable. de acuerdo al siguiente detalle: Apuntes de RACF Juan Mautalen . Con excepción de los usuarios mencionados en el ítem anterior. 3) Ejecutar el comando “SETR RACLIST(FACILITY) REFRESH” (suponemos que la clase FACILITY se encuentra activa y RACLISTeada). Existe. No ahondaremos. Por ejemplo. Si el perfil IRR. y por lo tanto totalmente innecesarios. ciertos usuarios específicos. Para ello. están explícitamente excluidos del alcance de la autoridad dada por el recurso IRR. Si el perfil IRR. con UACC=NONE. no por considerarla innecesaria. UACC=NONE es apropiado.PASSWORD. es factible otorgar a un usuario la posibilidad de listar únicamente aquellos que tengan un determinado owner. Observaciones: Por motivos de seguridad.110 1) Definir el perfil IRR. y por lo tanto innecesarios (este nivel de autoridad no tiene relación alguna con el nivel de autoridad requerido sobre el perfil de dataset protector del archivo. que Apuntes de RACF Juan Mautalen . un usuario con atributo SPECIAL a nivel de sistema no necesita autorización sobre este perfil. E incluso la posibilidad de excluir. entonces no rechaza el acceso por la condición de no catalogado. es factible definir perfiles apropiados en la clase FACILITY que brinden esta facilidad. de este universo. Existe también en este caso la posibilidad de darle mucha más granularidad a esta facilidad. suele suceder que usuarios responsables del mantenimiento del sistema operativo necesiten acceder a datasets no catalogados (por ejemplo. y si es READ (o superior). sin embargo. es factible otorgar a un usuario la posibilidad de rehabilitar únicamente aquellos que tengan un determinado owner. 3) Ejecutar el comando “SETR RACLIST(FACILITY) REFRESH” (suponemos que la clase FACILITY se encuentra activa y RACLISTeada). el acceso a datasets no catalogados).RESET existe. A tal efecto. permite asimismo dar una nueva password aún sin que haya pasado el tiempo de vida mínimo. Facilidad para acceder a datasets no catalogados Es frecuente. Aparte de lo que otorga READ. dónde dsname es el nombre del archivo (solo los 30 primeros caracteres se consideran). Si el perfil IRR. con la siguiente salvedad: si el perfil es discreto. No ahondaremos.PASSWORD. para datasets no catalogados (y no protegidos por un perfil discreto). Como ya hemos comentado en un capítulo anterior. asimismo. ciertos usuarios específicos.RESET los usuarios con atributo SPECIAL. rigen los chequeos de autoridad habituales para el uso del comando ALTUSER. otorga privilegios administrativos sobre el perfil. Por ejemplo. y recomendable.RESET no se encuentra definido. Si el perfil IRR. Sin embargo. en los detalles de una implementación de este tipo. o que se encuentren dentro del campo de acción de determinado grupo. queda fuertemente restringida la posibilidad de acceder a archivos que no se encuentren catalogados (lo cual debería constituir una situación de excepción). abriendo desde una partición un archivo catalogado en otra). permite también la posibilidad de dar una nueva password no expirada.PASSWORD.111 READ UPDATE Permite rehabilitar un usuario revocado mediante el operando RESUME del comando ALTUSER. Observaciones: Por motivos de seguridad. De este modo. CONTROL Aparte de lo que otorga UPDATE. la autorización sobre este recurso permite actuar sobre cualquier usuario de la base de RACF. que la organización tenga la opción CATDSNS en modo FAIL seteada en la SETROPTS. solo agrega una posibilidad extra respecto a la autoridad necesaria para la rehabilitación de usuarios. RACF construye el recurso de nombre ICHUNCAT.PASSWORD. Por ejemplo. están explícitamente excluidos del alcance de la autoridad dada por el recurso IRR. AUDITOR u OPERATIONS a nivel de sistema. Los privilegios habituales siguen siendo suficientes. RACF chequea entonces la autoridad del usuario sobre este recurso en la clase FACILITY. Con excepción de los usuarios mencionados en el ítem anterior. lo cual probablemente constituya un efecto no deseado. También autoriza a otorgar una nueva password (expirada). El nivel de autoridad ALTER resulta equivalente a CONTROL. Niveles de autoridad superiores a READ en este tipo de perfiles son equivalentes a READ. sin necesidad de dar al usuario el atributo SPECIAL (que permite.dsname. Para ello.112 depende obviamente del tipo de operación que se pretende realizar).TEST.**. Sin que ello exceptúe. Apuntes de RACF Juan Mautalen . en la clase DATASET). puede definirse únicamente el perfil genérico ICHUNCAT.** en la clase FACILITY y otorgarle al usuario SYSPRG1 autoridad READ. Ejemplo: Supongamos que el usuario SYSPRG1 debe acceder a datasets no catalogados cuyos nombres son de la forma TEST. Si no es requerido este nivel de granularidad. los chequeos usuales de acceso a archivos. y que éstos están protegidos por perfiles de dataset sobre los cuales el usuario tiene suficiente autoridad. recalquémoslo nuevamente. basta definir el perfil genérico ICHUNCAT.**.CONFIG. que brinda a los usuarios autorizados la posibilidad de acceder a cualquier archivo no catalogado.CONFIG. sortear el chequeo de “no catalogado” no elimina de ninguna manera los habituales chequeos posteriores (normalmente. Naturalmente. que puede ser 0. 4. diremos que RACF autoriza una solicitud de acceso cuando el código de retorno sea 0. y que la rechaza cuando sea igual a 8. subsistemas y demás componentes del sistema operativo mediante la devolución de un código de retorno. Pasos del proceso de chequeo 1. y cuyo significado es el siguiente: 0 4 8 RACF considera que la solicitud de acceso debe aceptarse RACF no posee información para responder sobre la solicitud de acceso RACF considera que la solicitud de acceso debe rechazarse En cualquier caso. Hecha esta importante aclaración. Para simplificar. RACF devuelve el código de “no protegido”. De todos modos. el proceso termina y los pasos subsiguientes son omitidos. En este capítulo describiremos en detalle el proceso que lleva a cabo RACF para determinar el código de retorno que devolverá a la aplicación solicitante frente a un requerimiento de acceso. Se limita a responder los requerimientos que recibe de las distintas aplicaciones. lo rechaza. o bien devuelve el código de retorno 4 (código de no protegido). así como también suponemos no se han implementado exits de RACF (ni del SAF). UPDATE. es de esperar que toda aplicación que maneje su seguridad externamente vía RACF actúe en forma compatible con el código de retorno que reciba.Consideraciones generales RACF no otorga ni rechaza solicitudes de acceso a recursos. una exit propia de la aplicación podría perfectamente denegar una solicitud de acceso aún cuando reciba de RACF un código de retorno 0. en lo que sigue. Si el requerimiento proviene de una STC marcada TRUSTED o PRIVILEGED. 8. 3. los pasos que enumeramos a continuación.1 . Si la clase debería estar RACLISTeada de acuerdo a lo que especifica la CDT. Si RACF no está activo en el sistema.2 . Si en alguno de ellos RACF autoriza el requerimiento. se devuelve el código de “no protegido”. básicamente. CONTROL o ALTER) Identificador del usuario RACF procesa la solicitud de acceso siguiendo en orden.113 8 – PROCESO DE CHEQUEO DE AUTORIDAD 8. obviamos toda mención de security levels. Si se trata de una clase de recursos generales que no se encuentra activa en la SETROPTS. es finalmente la aplicación la que decide aceptar o rechazar el requerimiento de acceso. 2. Apuntes de RACF Juan Mautalen .Autoridad de un usuario sobre un recurso Recordemos que la solicitud de acceso que recibe RACF consta. salvo casos excepcionales. Por ejemplo. pero no lo está. READ. RACF lo autoriza. de la siguiente información: Nombre de la clase Nombre del recurso Nivel de acceso requerido (EXECUTE. categories y security labels. RACF devuelve el código de “no protegido”. 4 u 8. esencialmente. y el usuario no tiene el atributo RESTRICTED. Si el grupo figura en ella con un nivel igual o superior al solicitado. 15. inferior al solicitado. En caso afirmativo. 10. Si el usuario figura en ella con un nivel igual o superior al solicitado y se cumple la condición correspondiente. RACF autoriza el requerimiento. RACF autoriza el requerimiento. Si el grupo figura en ella pero con un nivel inferior al solicitado. por el contrario. RACF busca el “actual grupo de conexión” del usuario en la lista de acceso condicional del perfil protector. 6. y el usuario existe en la base de RACF y no tiene el atributo RESTRICTED. 11. Si la opción GRPLIST está activa en la SETROPTS. UACC y atributo OPERATIONS no cuentan). Si tal nivel es igual o superior al solicitado. Un ejemplo típico son datasets cuyo HLQ coincida con el identificador del usuario. en cuyo caso el proceso continúa. continúa en el paso 19. Si no encuentra al recurso protegido y se trata de una clase de recursos generales. Si la opción GRPLIST no está activa en la SETROPTS. Si la clase está bajo GLOBAL en la SETROPTS. y la información de la GAC indica que debe accederse a la solicitud. excepto que el usuario tenga el atributo RESTRICTED. Si el nivel asociado a la entrada * es. el nivel resultante es inferior. RACF selecciona el nivel de autoridad más elevado. en cambio. ID(*). entonces RACF autoriza el requerimiento. RACF autoriza el requerimiento. 13. RACF autoriza el requerimiento. RACF busca si existe una entrada * en la lista de acceso estándar del perfil protector. Si el usuario figura en ella pero con un nivel inferior al solicitado. 14. Si el UACC del perfil protector es igual o superior al nivel solicitado. RACF continúa en el paso 13 (por lo tanto el UACC no cuenta en este caso).114 5. RACF autoriza el requerimiento. RACF busca el perfil protector del recurso. UACC y atributo OPERATIONS no cuentan). 8. Notemos que esto no tiene ninguna relación con el concepto de owner del perfil. RACF busca el identificador del usuario en la lista de acceso estándar del perfil protector del recurso. ID(*). devuelve como código de retorno el DEFRETC de la clase especificado en la CDT. RACF continúa en el paso 14 (por lo tanto. Si la opción GRPLIST no está activa en la SETROPTS. Si la clase está alcanzada por el atributo OPERATIONS y el usuario lo posee. RACF busca en la lista de acceso estándar del perfil protector del recurso la presencia de los eventuales grupos a los que el usuario está conectado. Apuntes de RACF Juan Mautalen . Si el recurso es considerado propiedad del usuario. si el nivel de autoridad asociado es igual o superior al solicitado. RACF autoriza el requerimiento. 12. 9. Si el grupo figura en ella con un nivel igual o superior al solicitado y se cumple la condición correspondiente. se autoriza el acceso. RACF autoriza el requerimiento. 7. ya sea a nivel de sistema o a nivel de un grupo que tenga al perfil protector dentro de su campo de acción. RACF busca el “actual grupo de conexión” del usuario en la lista de acceso estándar del perfil protector. Si el usuario figura en ella con un nivel igual o superior al solicitado. RACF continúa en el paso 14 (por lo tanto. RACF autoriza el requerimiento. Si la clase es DATASET y no existe perfil protector. RACF continúa en el paso 14 (por lo tanto. Si. ID(*). Si uno o más de estos grupos figuran en ella. UACC y atributo OPERATIONS no cuentan). RACF busca el identificador del usuario en la lista de acceso condicional del perfil protector del recurso. Salvo casos puntuales (acceso a archivos “no catalogados” o “no protegidos”). Si uno o más de estos grupos figuran en ella para la condición dada. Si tal nivel es igual o superior al solicitado. RACF autoriza el requerimiento. La lista de acceso estándar se chequea siempre antes que la condicional. el atributo SPECIAL no es chequeado en ningún paso durante el proceso. Observaciones: Si la solicitud de acceso es sobre un dataset no catalogado. 19. Si el perfil protector está en modo WARNING. Si la opción GRPLIST está activa en la SETROPTS. RACF rechaza el requerimiento. RACF selecciona el nivel de autoridad más elevado. que ya analizamos en el capítulo correspondiente. RACF busca si existe una entrada * en la lista de acceso condicional del perfil protector. Si la opción PROTECTALL no está activa.115 16. La presencia del usuario. si el nivel de autoridad asociado es igual o superior al solicitado. Apuntes de RACF Juan Mautalen . RACF finalmente rechaza el requerimiento. Esto es coherente con lo que ya hemos señalado. RACF toma en cuenta además el seteo de la opción CATDSNS en la SETROPTS. 17. el usuario existe en la base de RACF y no tiene el atributo RESTRICTED. o lo está pero en modo WARNING. RACF autoriza el requerimiento. en el sentido de que tal atributo no otorga acceso a recursos. 18. en cuyo caso lo autoriza. ID(*) o atributo OPERATIONS. Si se está intentando acceder a un archivo no protegido y la opción PROTECT-ALL está activa en la SETROPTS en modo FAILURES. o de alguno de sus grupos de conexión (suponiendo que la opción GRPLIST está activa en la SETROPTS) en la lista de acceso estándar del perfil protector del recurso previene el eventual acceso que se pueda obtener vía UACC. RACF autoriza el requerimiento. se cumple la condición correspondiente. 20. RACF autoriza el requerimiento. En caso afirmativo. RACF busca en la lista de acceso condicional del perfil protector la presencia de los eventuales grupos a los que el usuario está conectado. excepto que el usuario tenga el atributo SPECIAL a nivel de sistema. La DD SYSIN es obligatoria e indica el dataset de control del utilitario. por lo cual mostraremos un job a modo de ejemplo y.(20.). esta información se grabará en el dataset de nombre RACF. Consiste de un listado de usuarios o grupos sobre los que se pretende buscar referencias.LINKLIB.programmer. para no impactar negativamente en la performance del sistema.2 .Consideraciones generales RACF provee varios programas utilitarios que permiten manipular. Puede tratarse de un archivo secuencial (en disco o en cartucho).DISP=OLD DD UNIT=SYSDA. listar todos los perfiles dónde figure en las listas de acceso.IRRUT100. una salida típica del utilitario. Los que analizaremos deben ejecutarse en forma batch.CLASS=clase. etc. Ejemplo de IRRUT100: //REFX100 // //PASO1 //SYSPRINT //SYSUT1 //SYSIN jef2514 conta /* // JOB cuenta. En nuestro ejemplo. Naturalmente. código de cuenta.PRTY=valor EXEC PGM=IRRUT100 DD DSN=RACF.IRRUT100 Este utilitario permite localizar en la base todas las ocurrencias de un usuario o grupo dado.IRRUT100. No es posible correr el IRRUT100 especificando una base de RACF distinta de la activa. Hacemos notar que no existe un comando de RACF que permita. clase. MSGLEVEL=(1. es recomendable ejecutarlo fuera de horarios pico de actividad. que mencionaremos más adelante). 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. La DD SYSUT1 es obligatoria y define un dataset de trabajo. La DD SYSPRINT es obligatoria y define dónde el utilitario grabará la información de salida.SALIDA. que debe residir en disco. por lo cual el sistema los localizará sin necesidad de codificar JOBLIB o STEPLIB en el job. no es posible distinguir si se trata de grupos o usuarios). la tarjeta job debe ser personalizada de acuerdo a las exigencias de cada organización (nombre del job. prioridad. en ciertos casos. diagnosticar problemas y extraer información de la base de RACF.MSGCLASS=clase. Al ser un programa que debe examinar todos los perfiles de la base. dado un usuario o grupo.116 9 . 9.1). Los programas invocados por los distintos utilitarios residen en la biblioteca SYS1. que suponemos prealocado.1 . Apuntes de RACF Juan Mautalen .SPACE=(TRK. En nuestro ejemplo. Este utilitario siempre toma la información de la base de RACF activa en la LPAR dónde se ejecuta.PROGRAMAS UTILITARIOS 9.4)) DD * //********************************************************************** El programa invocado debe ser IRRUT100.SALIDA. o bien puede especificarse un dispositivo de salida. Esta información de entrada puede estar embebida en el mismo jobstream (usando DD *) o bien residir en un archivo (secuencial o particionado). tan solo mirando los identificadores. El utilitario IRRUT100 puede ser usado para obtener esta información (aunque también existen otros métodos. En este capítulo expondremos los que consideramos más importantes. Por ejemplo. nos informa.117 La salida tendría 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. 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 cuestión dentro de su campo de acción. no es suficiente la información suministrada por el IRRUT100.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. CONTROL o ALTER.PROVEE.** (G) First qualifier of profile CONTA. Una desventaja importante de la información 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.** (G) In standard access list of dataset profile CONTA.** (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) . Incluso informa si el usuario o grupo especificado es el HLQ de algún perfil de dataset.Entity name is generic. UPDATE.** (G) In standard access list of dataset profile PUBLIC. EXECUTE. como ser OWNER o NOTIFY.** (G) First qualifier of profile JEF2514.** (G) In standard access list of dataset profile PAGOS.A200%. sino también en cualquier otro campo de los perfiles. pero no especifica si figura con nivel de autoridad NONE. Autoridad requerida Para ejecutar el IRRUT100 especificando un determinado usuario o grupo. READ. Observemos que la salida no solo muestra la presencia del usuario o grupo en las listas de acceso.A200%. si se pretende definir un nuevo usuario o grupo que tenga exactamente las mismas autorizaciones que otro existente.** (G) In access list of group CONTA In access list of group PAGOS User entry exists Owner of user CON001 (G) .**. que el usuario JEF2514 está en la lista de acceso estándar del perfil de dataset CONTA. en nuestro caso.** (G) First qualifier of profile CONTA. En consecuencia. Apuntes de RACF Juan Mautalen . IRRUT200 Este utilitario tiene los siguientes usos básicos: Identifica inconsistencias en la organización interna de la base de RACF. si SYSUT1 ya contiene una copia del archivo a analizar. MSGLEVEL=(1. Es solo una herramienta de diagnóstico. En cualquier caso. La DD SYSRACF define el dataset de la base de RACF sobre el que se pretende efectuar la verificación (recordemos que la base de RACF puede estar particionada en más de un dataset). Puede tratarse de un archivo secuencial (en disco o en cartucho).programmer. Permite realizar una copia exacta (bloque a bloque) de la base de RACF. Este control del utilitario evita que.RECFM=F) DD SYSOUT=clase DD SYSOUT=clase DD * //********************************************************************** INDEX [FORMAT] El programa invocado debe ser IRRUT200.BASERACF tiene un tamaño de 20 cilindros).DISP=SHR DD UNIT=SYSDA. entonces la DD SYSRACF puede omitirse.118 9.DCB=(LRECL=4096. Esta información es útil para decidir si es necesario un redimensionamiento.SPACE=(CYL. Tampoco SYSUT1 puede especificar un dataset de RACF activo. como primera medida. Informa el porcentaje de utilización efectiva del espacio en la base de RACF. El utilitario IRRUT200 procede. SYSUT1 debe ser distinto a SYSRACF. esto no es aconsejable pues se mantendría la reserva hasta la finalización del job. se libera SYSRACF y el programa prosigue realizando las verificaciones pertinentes sobre la copia recién obtenida. Ejemplo de IRRUT200 para diagnóstico: //DIAG200 // //PASO1 //SYSRACF //SYSUT1 //SYSUT2 //SYSPRINT //SYSIN MAP [ALL] END /* // JOB cuenta. o bien puede especificarse un dispositivo de salida. La DD SYSUT2 define dónde el utilitario grabará ciertos mensajes de salida.3 . De esta manera se minimiza el tiempo en que el utilitario mantiene la reserva sobre la base de RACF. Terminada la copia. Puede tratarse de un dataset activo o no. se corrompa un dataset activo usándolo como archivo de salida. Si es un dataset activo. sino el utilitario falla. Permite sincronizar las bases de uso primario y backup. Si no se codifica SYSUT1. a copiar el dataset definido en SYSRACF al especificado en SYSUT1 (para ello utiliza internamente el programa IEBGENER). La DD SYSUT1 define un archivo de trabajo que debe residir en disco y tener idénticas características que el dado por SYSRACF (en nuestro ejemplo asumimos que SYS1.CLASS=clase. pudiendo causar problemas operativos. se usa el dataset definido en SYSRACF durante todo el proceso.BASERACF.1). pues también el job fallaría. por error. Apuntes de RACF Juan Mautalen .PRTY=valor EXEC PGM=IRRUT200 DD DSN=SYS1. ya que en caso de detectar errores no realiza ninguna reparación. Es pues una herramienta extremadamente útil para realizar un backup en disco de la base.(20)).MSGCLASS=clase. o bien residir en un archivo. entre las que se incluyen la cantidad de perfiles existentes en cada clase y el porcentaje de ocupación de la base. o mensualmente. y con un manejo adecuado. es recomendable correr esta herramienta de diagnóstico con cierta regularidad (semanalmente. e indica que se muestre en la salida un listado formateado de todos los bloques de índice. con el propósito de verificar que el utilitario no encuentre inconsistencias lógicas en la organización interna de la base. sería conveniente programar una ampliación y reorganización de la base (ver el utilitario IRRUT400). para lo cual deberá consultarse la documentación correspondiente que brinda IBM. tema complejo que escapa completamente a los objetivos de la presente guía.0000003 NUMBER OF DASDVOL ENTRIES . El parámetro ALL. en caso de codificarse. Puede tratarse de un archivo secuencial (en disco o en cartucho). Si se ejecuta el IRRUT200 con la opción MAP.0000004 NUMBER OF TERMINAL ENTRIES – 0000086 NUMBER OF APPL ENTRIES – 00000021 NUMBER OF TCICSTRN ENTRIES .RBA 00000000D000 RACF DATA SET IS 41 PERCENT FULL. RACF es un producto sumamente estable y probado.0004305 NUMBER OF DATASET ENTRIES . debe estar separado de INDEX por un único espacio en blanco. 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 . es realmente poco probable que aparezcan errores lógicos. El parámetro FORMAT. De todos modos. usando DD *). La información puede estar en el mismo jobstream (lo más frecuente. es conveniente controlar que este valor no supere. Las sentencias de control admitidas son: INDEX [FORMAT] MAP [ALL] END INDEX especifica que se lleve a cabo la función de escaneo de índice. digamos. END indica el final del proceso. De todos modos. e indica que se muestre en la salida un mapa de todos los bloques BAM de la base. MAP establece que se lleve a cabo una verificación a nivel de BAM (Block Availability Mask). Mostramos a continuación un ejemplo de la SYSPRINT: **** BAM BLOCK VERIFICATION **** **** MAP FUNCTION STATISTICS **** NUMBER OF BAM BLOCKS DEFINED 004 LAST BAM THAT DEFINES USED SPACE . Si se estuviera por encima. por ejemplo). Mencionemos asimismo que no todos los posibles problemas internos de una base de RACF son detectados por el IRRUT200. debe estar separado de MAP por un único espacio en blanco.119 La DD SYSPRINT define dónde el utilitario grabará la información de diagnóstico generada. Para evitar problemas repentinos por falta de espacio. o bien puede especificarse un dispositivo de salida. Si el IRRUT200 detectara algún tipo de problema. La DD SYSIN es obligatoria e indica el dataset de control del utilitario.0000001 NUMBER OF SECLABEL ENTRIES .0000428 NUMBER OF RACFVARS ENTRIES . en caso de codificarse.0000002 NUMBER OF GCICSTRN ENTRIES .0000003 Apuntes de RACF Juan Mautalen .0000173 NUMBER OF USER ENTRIES . será necesario corregirlo. el 75%. Para interpretar en su totalidad la información de diagnóstico suministrada por el IRRUT200 es necesario conocer profundamente la organización interna de una base de RACF. en la salida SYSPRINT aparece una serie de estadísticas interesantes.000092 NUMBER OF GLOBAL ENTRIES . se vería un uso del 100%.programmer.0000157 NUMBER OF DIGTCERT ENTRIES . IEBGENER RC=0000 Ejemplo de IRRUT200 para hacer una copia de backup: //BACK200 // //PASO1 //SYSRACF //SYSUT1 //SYSUT2 //SYSPRINT //SYSIN // JOB cuenta.CLASS=clase.00000014 NUMBER OF CCICSCMD ENTRIES . En su uso como herramienta de backup. si se listaran sus características de alocación (por ejemplo.4 Dslist del ISPF).MSGCLASS=clase.BASERACF. el IRRUT200 solo sirve para realizar una copia de la base a una que resida en un disco de igual geometría que la original y tenga igual tamaño. como dato importante. que de ninguna manera refleja su ocupación real.0000009 NUMBER OF FACILITY ENTRIES . El dataset especificado en SYSUT1 no debe ser nunca una base de RACF activa (en este u otro sistema). Los datasets de RACF están formateados íntegramente. Por lo tanto.PRTY=valor EXEC PGM=IRRUT200 DD DSN=SYS1. que suponemos prealocado y con idénticas características y tamaño que la entrada SYS1. los siguientes mensajes: DATA SET UTILITY . En la salida SYSUT2 se tendrían. bloque a bloque.GENERATE PROCESSING ENDED AT EOD IRR62065I . MSGLEVEL=(1.0000020 NUMBER OF TSOAUTH ENTRIES – 0000004 NUMBER OF MGMTCLAS ENTRIES – 0000008 NUMBER OF STORTCLAS ENTRIES – 0000031 NUMBER OF FIELD ENTRIES . por ejemplo.0000043 NUMBER OF PROGRAM ENTRIES . La copia se generará en el dataset RACF.0000020 NUMBER OF ACCTNUM 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 .00000012 NUMBER OF SDSF ENTRIES .DISP=OLD DD SYSOUT=clase DD SYSOUT=clase DD DUMMY //********************************************************************** En este ejemplo el programa utilitario IRRUT200 se emplea para realizar una copia exacta.COPIA.IEBGENER copied SYSRACF to the work dataset SYSUT1.120 NUMBER OF DSNR ENTRIES . La DD SYSIN definida como DUMMY en este ejemplo establece que no se lleve a cabo ninguna función de diagnóstico. Esta es la única forma de determinar el porcentaje de ocupación efectivo de una base de RACF. del dataset de RACF especificado en la DD SYSRACF.1).BASERACF.0000018 NUMBER OF TSOPROC ENTRIES .COPIA especificado en SYSUT1.0000011 Observemos. ya que el utilitario Apuntes de RACF Juan Mautalen . que se informa que el dataset está ocupado en un 41%. con el comando S en la opción 3.00000018 NUMBER OF STARTED ENTRIES .DISP=SHR DD DSN=RACF.0000008 NUMBER OF SURROGAT ENTRIES . 9. Asimismo. Identifica cierto tipo de inconsistencias en los datasets de la base. Ejemplo de IRRUT200 para sincronizar las bases: //BACK200 // //PASO1 //SYSRACF //SYSUT1 //SYSUT2 // JOB cuenta.BACK.4 . si la base estuviera distribuida en más de uno).programmer. En la presente guía no analizaremos la funcionalidad del IRRUT400 respecto a la posibilidad de distribuir (split) o consolidar (merge) los datasets que conforman la base.DISP=SHR DD DSN=SYS1. Si se pretende copiar una base a otra de distinto tamaño. si los programas IRRUT200 o IEBGENER estuviesen protegidos en la clase PROGRAM.IRRUT400 Este utilitario tiene varias funciones: Permite copiar la base de RACF a otra de tamaño distinto. se necesita asimismo autoridad para ejecutarlos.DISP=OLD DD SYSOUT=clase //********************************************************************** El parámetro PARM=ACTIVATE indica que se quiere copiar la base primaria sobre la de backup (o a nivel de un dataset específico. Finalizada la copia de SYSRACF (base primaria activa) sobre SYSUT1 (base de backup inactiva). que veremos más adelante.PARM=’ACTIVATE’ DD DSN=SYS1. Autoridad requerida Para ejecutar el utilitario IRRUT200. se activará la base de backup antes de liberarse la base primaria. Recordemos que RACF admite un máximo de 90 datasets para su base primaria. Con PARM=ACTIVATE. Se comprobará asimismo que el backup se encuentre inactivo (recordemos que nunca el destino de una copia debe ser un dataset de RACF activo). es recomendable ejecutar este utilitario fuera de los horarios pico de actividad. juntando los eventuales segmentos de un mismo perfil.PRIM. En cualquiera de sus usos. también puede utilizarse para consolidar varios datasets de la base en una menor cantidad. Tampoco Apuntes de RACF Juan Mautalen .RACF. Solo de este modo queda garantizado que la base de backup resulte idéntica a la primaria. En efecto. MSGLEVEL=(1.CLASS=clase. Nos ocuparemos exclusivamente del uso del utilitario como herramienta de copia y reorganización. como ser la presencia de perfiles duplicados. Naturalmente. son ignoradas.121 podría corromperlo durante la copia.PRTY=valor EXEC PGM=IRRUT200.MSGCLASS=clase. basta con tener autoridad READ sobre el dataset especificado en SYSRACF y UPDATE sobre el dado por SYSUT1 (o ALTER.RACF. las DD SYSPRINT y SYSIN. debe usarse el utilitario IRRUT400. si es alocado dinámicamente por el job como archivo permanente). si en lugar de activar el backup el mismo IRRUT200 lo hiciera un administrador con el comando RVARY. Reorganiza físicamente la base. las eventuales modificaciones sobre la base primaria ocurridas entre la finalización del job y la ejecución del comando de activación no se verían replicadas el backup. e idéntica cantidad para la base de backup. Permite distribuir un dataset de la base de RACF en varios datasets.1). que puede incluso residir en un disco de distinta geometría. RACF verificará que SYSRACF especifique efectivamente la base primaria de RACF y SYSUT1 la de backup. si estuvieran presentes. de modo de no afectar negativamente la performance del sistema. Base lockeada En este estado. En consecuencia. la base de origen quedará lockeada aún luego de terminado el proceso de copiado. solo se justifica tener la base lockeada durante alguna tarea de mantenimiento específica y por un período muy breve. esta reorganización puede mejorar la performance de RACF. Para comprender exactamente el alcance del proceso de reorganización. Más aún. Si se encuentra activa. consistente en reubicar físicamente contiguos aquellos segmentos correspondientes a un mismo perfil. En cambio. Más aún. que establece si la misma se encuentra lockeada o no-lockeada. con excepción de cierta información estadística. la que se pretende copiar) puede o no estar activa. Si la base se encuentra muy fragmentada (lo cual puede diagnosticarse a través del IRRUT200). de una especie de desfragmentación. si intentan cambiar su password. entonces debe necesariamente utilizarse el IRRUT400. lo cual excede los objetivos de esta guía. por lo cual debe necesariamente codificarse alguna de las 3 opciones. si se trata de su primer logon del día. tanto la primaria como la backup. LOCKINPUT lockea la base de origen antes de iniciar el proceso de copia. Las bases de RACF. o residente en un disco de distinta geometría (de 3380 a 3390. Del mismo modo que para el IRRUT200. Mencionemos simplemente que se trata. Se trata de la opción más recomendable. Si se especificó LOCKINPUT. el utilitario falla. no solo copia sino que reorganiza la base. es preferible emplear el utilitario IRRUT200 pues se encarga de serializar adecuadamente el uso de la base de origen. El IRRUT400. No existe ningún valor por defecto. deben estar no-lockeadas. aunque tiene la desventaja de mantener lockeada la base de origen durante el tiempo que insume el utilitario. Base no-lockeada Se trata del estado natural de la base. al no permitirse actualizaciones durante el proceso. salvo que exista una situación que requiera explícitamente lo contrario. En cambio. cuyo significado analizamos a continuación. es necesario tener un conocimiento acabado de la estructura interna de la base de RACF. Si se quiere obtener una copia idéntica. De este modo. Por lo tanto. es imprescindible deslockearla. si la copia desea hacerse a una base de distinto tamaño. Apuntes de RACF Juan Mautalen . que invoque nuevamente el programa IRRUT400 pero con el parámetro UNLOCKINPUT. lo cual puede. en el cual todas las actualizaciones están permitidas. acarrear ciertas dificultades operativas. al disminuir la cantidad de lecturas de bloques que RACF debe realizar para obtener la información completa de un determinado perfil. esencialmente. garantizando una copia completamente fiel de la original. modificarse o deletearse perfiles. el chequeo de autoridad de usuarios sobre recursos se lleva a cabo normalmente. la base de origen (esto es. los usuarios que se encuentran logueados a alguna aplicación no deberían notar ninguna diferencia. El IRRUT400 permite manejar el bit de lockeo de la base a través de un parámetro obligatorio que debe tomar alguno de los valores siguientes: LOCKINPUT/NOLOCKINPUT/UNLOCKINPUT.122 describiremos todos los parámetros que admite el programa. excepto naturalmente que intenten modificar información de la base de RACF. algunos usuarios no podrán loguearse. Para ello basta con agregar al job un paso adicional. no se permite ninguna actualización sobre la base. Estando la base lockeada. la base de destino no debe nunca estar activa en ningún sistema. si se trata de una base activa. sino el único cuya especificación es obligatoria. el IRRUT400 permite manejar el bit de lockeo de la base. se garantiza que la copia tenga idéntica información que la original. por ejemplo. no pueden definirse. si estuviera activa en el mismo sistema dónde se ejecuta el job. así como tampoco modificarse opciones de la SETROPTS. lo cual es poco frecuente y por un período corto de tiempo. En cualquier caso. a diferencia del IRRUT200. Esto sucederá. o si han ingresado su password correcta luego de algún intento inválido. por ejemplo). Si se trata de una base activa que se seguirá utilizando. 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 opción aconsejable cuando la base de origen está activa, excepto que se tenga la seguridad de que la actividad de actualización es nula. Si la base de origen no está activa en ningún sistema, entonces no es pasible de ser modificada, por lo cual la opción NOLOCKINPUT sería perfectamente apropiada. UNLOCKINPUT deslockea la base de origen. Como ya mencionamos, si se ejecutó el IRRUT400 con el parámetro LOCKINPUT y se pretende seguir usando como base activa a la base de origen, debe necesariamente deslockearse invocando nuevamente el mismo utilitario con el parámetro 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 dónde se copiará el dataset definido en INDD1. Si se requiere más 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 tamaño que la de origen. La DD SYSPRINT establece dónde 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 había quedado lockeada en el paso anterior (por haberse especificado el parámetro 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 dinámicamente 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 modificación. Aún 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 parámetro. 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 observarán datos distribuidos de manera aparentemente caótica, no interpretables. Se presenta entonces la necesidad de contar con un programa utilitario que convierta la información de la base a un formato plano, factible de ser fácilmente interpretado y explotado programáticamente. El utilitario IRRDBU00 (DBU viene de Data Base Unload.) permite justamente esto. Transfiere, a un archivo secuencial, la información de todos los perfiles de la base. El archivo plano generado puede usarse con diversos fines: Se puede leer directamente, ya que el diseño de sus registros se encuentra plenamente documentado en la bibliografía de IBM, más precisamente en el libro “Security Server RACF Macros and Interfaces”. Se puede formatear con algún programa propio, para extraer y organizar la información de una forma conveniente. Se puede usar para cargar tablas de DB2, para luego poder usar este motor de base de datos para extraer información. Se puede transferir a PC y formatearlo con algún programa de este entorno. Sirve como archivo de entrada a otro utilitario importante que veremos más 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 recién 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 sería obtener una copia actual de la base usando IRRUT200 y a continuación ejecutar el IRRDBU00 sobre la copia recién obtenida. La gran ventaja de este método en 2 pasos radica en el hecho de que la reserva del IRRUT200 sobre la base activa es mucho más 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 información de la SETROPTS, ni ningún 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 información 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 dónde se transferirá la información de los perfiles de los archivos definidos en las INDDn. Debe tener las siguientes características: RECFM=VB (registros de longitud variable y bloqueados) LRECL=4096 (longitud de registro sugerida) Con respecto al tamaño, una estimación inicial consiste en calcular el doble del espacio efectivamente utilizado en la base de entrada. Por ejemplo, si la base de entrada tiene un tamaño 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 debería 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 dónde 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 codificación del parámetro que indica cómo se pretende que el utilitario maneje el bit de lockeo de la base. El significado de las opciones LOCKINPUT, NOLOCKINPUT y UNLOCKINPUT es análogo 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á automáticamente 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 información. Cumple, en este punto, una función idéntica al IRRUT400 con UNLOCKINPUT. Sugerimos siempre ejecutar el IRRDBU00 sobre una base que no se encuentre activa. En tal caso, el parámetro 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 dinámicamente 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 capítulo 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 podría 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 eliminación. 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 señalar que el IRRRID00 no ejecuta ningún comando. Simplemente genera, en un archivo de salida, los comandos necesarios para la eliminación de las referencias residuales. Es tarea del administrador de RACF examinar cuidadosamente (y eventualmente editar) los comandos respectivos, para luego decidir cuáles de ellos se ejecutaran. Apuntes de RACF Juan Mautalen Lo más adecuado es dejar que el sistema lo defina como un dataset temporario. que debe obligatoriamente ser una bajada plana generada por el IRRDBU00. o bien puede especificarse un dispositivo de salida.DISP=OLD DD * //********************************************************************** El programa invocado debe ser IRRRID00. La DD SYSOUT define dónde el DFSORT (o programa equivalente) invocado internamente por el utilitario grabará los mensajes de salida. Ejemplo de IRRRID00 //IRRRID // //PASO //SYSPRINT //SYSOUT //SORTOUT //SYSUT1 //INDD //OUTDD //SYSIN jef2514 /* // JOB cuenta. Es pues necesario ejecutar el utilitario IRRDBU00 como paso previo a la utilización del IRRRID00. Lo más adecuado es dejar que el sistema lo aloque como un dataset temporario. y si se especifica un “ID de reemplazo”. salvo que ya se disponga de una bajada plana de la base suficientemente actualizada.REGION=25M DD SYSOUT=clase DD SYSOUT=clase DD UNIT=SYSDA.IRRRID. Puede tratarse de un archivo secuencial (en disco o en cartucho). MSGLEVEL=(1.2)) DD UNIT=SYSDA. El “ID de reemplazo” funciona del siguiente modo: Apuntes de RACF Juan Mautalen .CLASS=clase.PLANO.DISP=SHR DD DSN=RACF. debe estar a continuación. La DD OUTDD especifica el dataset de salida del IRRRID00 dónde se generarán los comandos necesarios para eliminar las referencias residuales correspondientes.(10. o bien residir en un dataset (secuencial o particionado).SALIDA está prealocado.SALIDA.2)) DD DSN=RACF. La DD SYSPRINT determina dónde el utilitario grabará los mensajes de salida. cuyo tamaño debe ser también similar al especificado en INDD.(10.SPACE=(CYL.MSGCLASS=clase.PRTY=valor EXEC PGM=IRRRID00. Debe tener las siguientes características: RECFM=VB (registros de longitud variable y bloqueados) LRECL=259 (como mínimo) En nuestro ejemplo. La DD SYSUT1 define otro archivo de trabajo. Cada usuario o grupo debe estar en un registro separado.1). se supone que el dataset RACF.SPACE=(CYL.126 El IRRRID00 utiliza como entrada la bajada plana de la base de RACF generada por el IRRDBU00. o bien puede especificarse un dispositivo de salida. cuyo tamaño debe ser similar al especificado en INDD. La DD INDD define el dataset de entrada del utilitario. La información puede estar embebida en el mismo jobstream (usando DD *). La DD SYSIN define el listado de usuarios y/o grupos sobre los que se quiere buscar las referencias residuales. La DD SORTOUT define un archivo de trabajo. separado exactamente por un espacio en blanco. Puede tratarse de un archivo secuencial (en disco o en cartucho).programmer. que será en consecuencia automáticamente eliminado al finalizar el job.IRRRID. **' GENERIC ID(JEF2514) DELETE PERMIT 'FINAN. The default value /* is ?id. o bien se aloca como DUMMY o vacía de contenido. Si se hubiese codificado en la SYSIN in “ID de reemplazo” para JEF2514. de modo que pueda editarse con un valor apropiado. entonces el utilitario generará en la salida el comando necesario para cambiar esta ocurrencia por el ID de reemplazo especificado. debiéndose reemplazar ?JEF2514 por el nuevo owner elegido. el IRRRID00 genera los correspondientes comandos de cambio de owner. En nuestro ejemplo. This allows all references to a particular ID to /* be easily changed to another value using a text editor. el utilitario busca todas las referencias en la base de usuarios y grupos que ya no existen.**' 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. Si no se define SYSIN. *****************************************************************************************/ EXIT DELDSD 'JEF2514. Es saludable ejecutar regularmente el IRRRID00 de esta manera. /* /* Commands to alter ROLE definitions will be created within /* comments for informational purposes. En caso de no codificarse un “ID de reemplazo”. el usuario JEF2514 figura como owner de 1 perfil y de la conexión de un usuario a un grupo. la SYSIN está inserta dentro del jobstream y establece que se busque toda referencia en la base respecto al usuario JEF2514. commands are created to /* change the reference to another value. de modo a detectar y borrar información residual que pueda haber quedado al no borrarse adecuadamente un usuario o grupo de la base. Por lo tanto. este ID aparecería en la salida en lugar de ?JEF2514. though the actual /* updates should be made from TME. /* /* This file contains RACF commands that can be used to /* identify references to user IDs and group IDs. editing them if necessary. /* /****************************************************************************************/ CONNECT CONJF01 GROUP(CONTA) OWNER(?JEF2514 ) PERMIT 'CONTA. Residual /* references on an access list are deleted with the PERMIT /* command. The ROLE will not be /* updated with a replacement value for a group name. Apuntes de RACF Juan Mautalen . en el comando de salida figurará en tal caso el usuario/grupo precedido de un ?. and then remove * the EXIT statement to allow the execution of the commands. For all other references.** ' DELUSER JEF2514 *****************************************************************************************/ * IRRRID00 has successfully completed *****************************************************************************************/ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ Observaciones: De acuerdo a la información generada.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. La salida podría tener el siguiente aspecto: /****************************************************************************************/ /* /* The RACF Remove ID Utility (IRRRID00) was executed on /* 2011-09-10 at 14:05:03. You must review * these commands. No se ofrece reemplazo en este caso. que deberían tener la autoridad suficiente para ejecutar exitosamente estos comandos.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 información -de uso interno por parte de RACFdenominada templates. se evita de esta manera que la ejecución inmediata del archivo de salida los ejecute. basta con borrar la sentencia EXIT para que también sean ejecutados estos comandos. En tal caso. solo entrarán en vigencia luego del próximo IPL o si explícitamente se los activa mediante la opción PARM=ACTIVATE del IRRMIN00. Con cada release del z/OS se distribuye una nueva versión del programa utilitario IRRMIN00. puede ejecutarse el IRRRID00 solo con el objeto de hallar todas las referencias en la base de un determinado usuario/grupo. Esto es intencional. Naturalmente. La información recabada es similar a la que brinda el IRRUT100. Como una CSECT del programa figuran los templates.el IRRMIN00 del z/OS 1. En este caso. indispensable para el funcionamiento de RACF.7 . Aunque esto es perfectamente entendible en el caso del IRRRID00. el archivo de salida se usa únicamente como fuente de consulta. A tiempo de IPL. No perdamos de vista.11. el IRRRID00 extrae la información de una bajada plana (que puede estar desactualizada respecto de la base real). En consecuencia. Como uso marginal. Ambos métodos presentan pues ventajas y desventajas. Por lo tanto. aún si se actualizan los templates de la base. 9. que existe una diferencia importante: mientras que el IRRUT100 lee la base de RACF activa. entonces se grabarán en la base los templates correspondientes a este release del sistema operativo. pues se trata de un uso del utilitario para el que no fue específicamente desarrollado. Los comandos que borran perfiles están agrupados al final del archivo de salida. al igual que sucede con el IRRUT100. informando que los templates de la base están Apuntes de RACF Juan Mautalen . De todos modos. básicamente. sin tener la intención de borrarlo. a continuación de una sentencia EXIT que corta el procesamiento en caso de ejecutarse la Clist generada. Se trata. es cargada en memoria en tiempo de IPL. residente en SYS1. Tampoco se tiene. ya que al tratarse de comandos más críticos.LINKLIB. si se actualizan los templates de una base usando –por ejemplo. 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. y no se ejecuta ninguno de los comandos generados. basta con tener autoridad READ sobre el dataset especificado en INDD y UPDATE sobre el definido por OUTDD (o ALTER. en el SYSLOG se graba el mensaje ICH579E. Una vez revisado y editado adecuadamente el archivo de salida. entonces no se cargan en memoria los de la base sino los que efectivamente corresponden. el utilitario genera directamente el comando de eliminación. Autoridad requerida Para ejecutar el utilitario IRRRID00. para poder ejecutar los comandos generados se requiere la autoridad administrativa correspondiente.128 Si el usuario figura en el campo NOTIFY de un perfil. pues se trata de un campo opcional. sin embargo. el IRRRID00 es básicamente una herramienta para los administradores de RACF. de una descripción de los distintos campos de cada tipo de perfil. si es alocado dinámicamente por el job). La información de los templates. como es el caso en nuestro ejemplo. debiendo decidir el administrador cual es el más apropiado para cada situación. el nivel de autoridad del usuario/grupo sobre los perfiles en cuyas listas de acceso figura. cuando se cargan los templates en memoria. 11. no debe jamás ejecutarse el utilitario con PARM=NEW para actualizar los templates de una base.NUEVA. En nuestro caso. Naturalmente. Ejemplo de IRRMIN00 para alocar e inicializar una nueva base de RACF: //IRRMIN // //ALOCINI //SYSPRINT //SYSRACF // JOB cuenta. Más aún. ya que el IRRMIN00 con PARM=NEW efectivamente destruye toda la información existente en la base. Para ello debe ejecutarse el IRRMIN00 con PARM=UPDATE (obviamente se pretende mantener intacta toda la información existente en la base). Esto no solo debe hacerse para la base primaria. si las bases estuvieran particionadas en más de un dataset. SPACE=(CYL. Lo usual es alocar una base con el IRRMIN00 y a continuación copiarle el contenido de otra existente. pues se perderá toda la información.9 a z/OS 1. Puede tratarse de un archivo secuencial (en disco o en cartucho).MSGCLASS=clase.CLASS=clase. La DD SYSRACF indica el dataset a inicializar como base de RACF. su tamaño y el disco dónde se aloca que hemos especificado son meros ejemplos.CONTIG). Debe tenerse sumo cuidado. sino también para la base de backup.9 funcionarán sin problemas.programmer. al estar esencialmente vacía. debe ejecutarse el utilitario para cada Apuntes de RACF Juan Mautalen . el nombre de la base. la base debe tener los templates del release 1. como por ejemplo el tipo y longitud de registro. Sin embargo. No se trata de un error serio pues RACF va a funcionar sin problemas.CATLG). es necesario actualizarlos.VOL=SER=MVSRES //********************************************************************** El programa invocado debe ser IRRMIN00. el archivo es alocado dinámicamente por el mismo job con el nombre SYS1.129 downlevel (desactualizados). Por ejemplo. por ejemplo de z/OS 1.UNIT=SYSDA. si las bases estuvieran particionadas en más de un dataset. no solo es necesario alocarlo con las características apropiadas (detalladas en un capítulo anterior). 2 de las cuales tienen z/OS 1.PARM=NEW DD SYSOUT=clase DD DSN=SYS1. Más aún.BASERACF. MSGLEVEL=(1. Las restantes características del dataset. con las características adecuadas para una base de RACF. Por lo tanto. seguir la sugerencia dada en el mensaje y actualizar los templates de la base. Actualización de los templates de una base existente Cuando se migra el sistema operativo. Conviene. sin embargo.9 y la restante z/OS 1. La DD SYSPRINT define dónde el utilitario grabará los mensajes de salida. o bien puede especificarse un dispositivo de salida. se le deben instalar los templates que correspondan a la versión más actualizada.1).11. que ya tenga cierta información mínima que la torne efectivamente usable. y deben ser determinados por la organización. Un dataset inicializado de este modo queda preparado para ser usado como base de RACF.(50).BASERACF. Observemos dos detalles de suma importancia: el espacio debe ser alocado contiguo y el archivo debe ser PSU (Physical Secuencial Unamovable). con PARM=NEW en este caso. difícilmente pueda utilizarse directamente en forma satisfactoria.DISP=(NEW. si una base es compartida por 3 LPAR. Si una base de RACF es compartida por varias LPAR con distintas versiones del z/OS. sino que debe ser inicializado ejecutando el IRRMIN00 con PARM=NEW.PRTY=valor EXEC PGM=IRRMIN00. no es necesario especificarlas pues el mismo utilitario setea los valores correctos.. ya que RACF mantiene compatibilidad hacia atrás). debe ejecutarse el utilitario para cada uno de ellos.11 (las particiones que tienen 1. Inicialización de una nueva base de RACF Para poder utilizar un dataset como base de RACF.NUEVA. como el nuevo release trae nuevos templates. No solo deben actualizarse los templates de la base primaria sino también los de la base de backup.DSORG=PSU. en cuyo caso RACF obtiene una “reserva exclusiva” sobre ella durante el tiempo que insume la ejecución (mínimo).PRTY=valor EXEC PGM=IRRMIN00. 9.programmer.CLASS=clase.programmer.DISP=SHR //********************************************************************** El significado de las DD es análogo al visto en el ejemplo anterior.Otros Utilitarios Describimos brevemente a continuación otros programas utilitarios que no vamos a exponer en detalle en esta guía.1). MSGLEVEL=(1. como en nuestro primer ejemplo). existe la posibilidad de que la aplicación de mantenimiento del sistema (PTFs –Program Temporary Fix) eleve la versión de los templates.MSGCLASS=clase.8 . tal cual se muestra a continuación: Ejemplo de IRRMIN00 para activar los templates de la base: //IRRMIN // //TEMPACT //SYSPRINT //SYSRACF // JOB cuenta. si la base de RACF ya tiene aplicados los nuevos templates. Si el programa IRRMIN00 se encontrara protegido en la clase PROGRAM.PRTY=valor EXEC PGM=IRRMIN00. Esto se logra ejecutando el IRRMIN00 con PARM=ACTIVATE. Ahora bien. si los templates de la base fueran de nivel inferior a los del release del sistema operativo. es posible cargarlos en memoria sin necesidad de recurrir a un IPL.MSGCLASS=clase.PARM=ACTIVATE DD SYSOUT=clase DD DSN=SYS1. Activación de los templates de la base Ya comentamos que. manteniendo intacta la información de los perfiles y de la SETROPTS. Ejemplo de IRRMIN00 para actualizar los templates: //IRRMIN // //TEMPUPD //SYSPRINT //SYSRACF // JOB cuenta. Esto evita que accidentalmente se carguen en memoria templates inadecuados.PARM=UPDATE DD SYSOUT=clase DD DSN=SYS1. si se lo está alocando dinámicamente.CLASS=clase. se cargan en memoria estos últimos.BASERACF. el usuario necesitaría asimismo estar autorizado para su ejecución. MSGLEVEL=(1. Autoridad requerida Para ejecutar el utilitario IRRMIN00 se debe tener autoridad UPDATE sobre el dataset especificado en SYSRACF (o ALTER. En tal caso. el job falla y la activación no se produce.130 uno de ellos.BASERACF. Si los templates en uso fueran de un nivel superior a los de la base especificada en SYSRACF. pero que resultan sin duda de interés para el administrador de RACF: Apuntes de RACF Juan Mautalen . El IRRMIN00 con PARM=UPDATE solo actualiza los templates de la base especificada en SYSRACF. La base puede estar activa en el sistema cuando se usa PARM=UPDATE.1).DISP=SHR //********************************************************************** El significado de las DD es análogo al visto en los ejemplos anteriores de IRRMIN00. ya que brinda gran cantidad de información relativa a la seguridad global del sistema. en particular para los auditores. utilitario estándar de IBM para el resguardo de los registros de SMF.131 Nombre BLKUPD Función Su nombre proviene de Block Update. IRRADU00 DSMON Apuntes de RACF Juan Mautalen . este programa funciona como una exit del IFASMFDP. Se trata de un comando que permite manipular directamente la base de RACF. Reemplaza al ya obsoleto. RACFRW (RACF Report Writer). 80. Sólo debe emplearse en situaciones dónde no sea posible reparar los errores mediante comandos de RACF. es necesario tener un acabado conocimiento de la estructura interna de la base. En el libro “Security Server RACF Diagnosis Guide” se puede encontrar toda la información necesaria sobre el BLKUPD. En el libro “Security Server RACF Auditor’s Guide” se puede encontrar información detallada sobre este utilitario. Este utilitario formatea amigablemente los registros de SMF relevantes para la tarea de auditoría de RACF (tipos 30. 81 y 83). con el objeto de resolver problemas internos. En el libro “Security Server RACF Auditor’s Guide” se puede encontrar información detallada sobre este utilitario. Se trata de una herramienta sumamente útil. Su nombre proviene de Data Security Monitor. Técnicamente. Antes de ejecutarlo. 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. ya que un mal uso puede dañarla irreparablemente. Por ejemplo: Exits de RACF activas Usuarios con atributos SPECIAL. aunque aún soportado. El orden en que están definidos determina su número de secuencia. Para ello es necesario configurar una tabla de rangos. Para simplificar. Hacer un switch de las bases. el sistema seguirá aceptando la password por defecto YES para los operandos ACTIVE. aún si no se dispone de las passwords del RVARY. . Si las bases estuvieran divididas en varios datasets. por cierto). Ambas tablas deben compilarse y linkeditarse a partir de un módulo fuente en lenguaje assembler. . Son compatibles hacia arriba. No describiremos en esta guía su configuración. sin necesidad de un IPL: Listar la configuración actual de las bases de RACF vigentes en el sistema. al no tener instrucciones sino simplemente definiciones de constantes.Consideraciones generales El comando RVARY permite llevar a cabo las siguientes acciones. SWITCH y DATASHARE|NODATASHARE. ejecutar el comando RVARY desde una consola como comando de operador. Los nombres de los datasets de las bases de RACF (primaria y backup) se definen en el módulo de nombre ICHRDSNT (Data Set Name Table). Apuntes de RACF Juan Mautalen . toda la información necesaria sobre ambas tablas está en el libro “Security Server RACF System Programmer’s Guide”.El “subsistema RACF” se encuentra activo (lo cual es altamente recomendable.COMANDO RVARY 10. en el caso en que se encuentre distribuida en más de uno. suponiendo que RACF esté habilitado para sysplex communication. en consecuencia. ningún aspecto relativo a sysplex communication o data sharing mode. en el caso en que la base se encuentre distribuida en más de uno. Solo destacamos que. No debe confundirse el “subsistema RACF” con el producto RACF propiamente dicho. Toda la información necesaria sobre el “subsistema RACF”·se encuentra disponible en el libro “Security Server RACF System Programmer’s Guide”. Esto puede hacerse incluso a nivel de dataset. Observación: Aún cuando la organización haya definido passwords para ambas funciones del RVARY. sino que analizaremos por separado los comandos necesarios para cada una de las funciones que describiremos en esta guía. En cualquier caso. la respuesta YES puede ingresarse desde cualquier consola (lo fundamental es que tenga autoridad MASTER aquella dónde se ejecuta el comando RVARY). No daremos la sintaxis completa del comando RVARY. supondremos en este capítulo lo siguiente: .El sistema tiene una base de backup activa y sincronizada con la primaria. En tal caso. Esta flexibilización tiene por objeto permitir una recuperación de emergencia. Activar o inactivar una base de RACF.132 10 . operación que intercambia el uso de la base primaria y la de backup. No trataremos. Cambiar entre los modos data sharing y non data sharing.La base de RACF no está compartida entre varios sistemas. en forma batch. que puede funcionar aún cuándo no se encontrara activo el subsistema. o bien por consola como comandos de operador. y se pueden simplemente copiar. no es necesario recompilarlos al migrar el sistema operativo.1 . incluso a nivel de dataset. Esto posibilita. que reside en el módulo de nombre ICHRRNG (Range Table). será necesario indicar de qué manera se quiere distribuir la información entre los distintos archivos. siempre y cuando se ejecute el comando desde una consola con autoridad MASTER (notemos que el operando INACTIVE está expresamente excluido de esta posibilidad). Estos pueden ejecutarse interactivamente desde una sesión de TSO. entre otras cosas. es probable que distintos discos lógicos correspondan en realidad al mismo disco físico. En este ejemplo. Los 4 datasets de encuentran activos. Lista la siguiente información sobre todos los datasets que conforman las bases de RACF vigentes en el sistema: Nombre del dataset Número de secuencia Disco dónde reside Estado (activo o inactivo) Uso (primario o backup) Una salida de este comando tendría 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. desde el SDSF. se encuentran distribuidas en 2 datasets.133 De todos modos. aún sin conocer sus valores actuales. un usuario con atributo SPECIAL tiene siempre la posibilidad de cambiar ambas passwords.2 . Es aconsejable que la base primaria resida en el “disco residente”.PRIM1 SYS1. definidos en la ICHRDSNT.PRIM2 SYS1.BACK2 ICH15020I RVARY COMMAND HAS FINISHED PROCESSING. 10. dada la tecnología actual de dispositivos de almacenamiento.BASERACF.3 . son de libre elección por parte de la organización. observamos que: Ambas bases de RACF.Switch de las bases Sintaxis: RVARY SWITCH [DATASET(nombre…|*)] Apuntes de RACF Juan Mautalen . Resulta pues fundamental limitar la posibilidad de ejecutar comandos de operador desde SDSF. primaria y backup. no teniendo necesidad alguna de tener a SYS1 como HLQ. 10.Listado de la configuración de las bases Sintaxis: RVARY LIST Autoridad requerida: ninguna Este comando es meramente informativo y no efectúa modificación alguna.BACK1 SYS1.BASERACF. La base primaria reside en un disco distinto que la de backup. controlando el uso de la “/” mediante un perfil apropiado en la clase SDSF (o GSDSF. Resulta por lo tanto de suma importancia controlar adecuadamente todas las consolas del sistema con autoridad MASTER. su correspondiente clase agrupadora).BASERACF. Sin embargo. Esto es altamente recomendable. con lo cual esta precaución puede no resultar del todo efectiva. conviene recalcar que los usuarios con acceso a TSO pueden habitualmente. de modo que solo usuarios debidamente autorizados estén en condiciones de ejecutar comandos en ellas. Sobre este punto. pues evita que ambas queden inutilizables en caso de fallo de un único disco. Los nombres de estos datasets. acceder a una consola con autoridad MASTER a través del comando ULOG. debería repararse lo antes posible el dataset dañado (al estar desalocado. activarlo.baseracf.BASERACF. o se omite el operando DATASET.Activación/inactivación de las bases Sintaxis: RVARY ACTIVE|INACTIVE[NOCLASSACT(clase…|*) (NOTAPE)] [DATASET(nombre…|*)] Autoridad requerida: requiere ingreso por consola de la password para la función STATUS Este comando permite activar o inactivar tanto la base primaria como la de backup. incluso a nivel de dataset.PRIM2 SYS1. el switch actúa para todos los datasets que conforman la base primaria. Si se codifica DATASET(*). si se pretende volver a la configuración original mediante la ejecución de un nuevo SWITCH. el dataset de nombre SYS1. que pasará a tener uso primario.134 Autoridad requerida: requiere ingreso por consola de la password para la función SWITCH Este comando intercambia el uso de los datasets de la base primaria especificados en el operando DATASET con sus correspondientes archivos de bakup. si se encontraran particionadas. Si un dataset de la base primaria está inactivo. En caso contrario. El comando RVARY SWITCH actúa siempre sobre datasets de uso primario. el dataset de backup. RACF ignora el comando y emite un mensaje de error. Por lo tanto. debe ejecutarse el siguiente comando: RVARY SWITCH DATASET(sys1. Observaciones: Para poder switchear. por lo cual es necesario trasladar el procesamiento a su correspondiente dataset de backup.prim2) Completada la ejecución exitosa del comando.4 .BACK2 ICH15020I RVARY COMMAND HAS FINISHED PROCESSING. En efecto. En esta situación. los datasets pertinentes de la base de backup pasan a tener uso primario. RACF ignora el comando y emite un mensaje de error.BASERACF. debe necesariamente estar activo.BACK1 SYS1.PRIM2 se encuentra dañado. mientras que los originalmente primarios pasan a ser de uso backup. siendo también inactivados y desalocados. en esta Apuntes de RACF Juan Mautalen . el listado de la nueva configuración arrojaría 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. 10. En una situación normal.PRIM1 SYS1.BASERACF. es posible manipularlo). en el sistema con la configuración dada en el ejemplo anterior. switchear nuevamente y finalmente activar el backup para retornar a la configuración normal. Para ello. RACF no puede procesar requerimientos para los que precise información que reside en él (excepto que la tenga disponible en memoria). es necesario previamente reactivar el backup. Ejemplo: Supongamos que.BASERACF. Como la función de SWITCH intercambia y deja inactivo el nuevo backup.BASERACF. Si se codifica en el operando DATASET un archivo cuyo uso es de backup. todos los datasets de las bases deben estar activos. ya que el operador debe aprobar por consola todo intento de acceso a datasets. aún cuando se encontrara activo. Si se codifica ACTIVE y se omite DATASET. Cuando todos los datasets de la base primaria se encuentran inactivos. Solamente ocurre un switch automático a la base de backup si un error de I/O sobre la base primaria pone offline el disco dónde reside. el otorgamiento o el rechazo de un requerimiento de acceso queda en manos de la aplicación o subsistema que lo requiera. deletearla. En estas condiciones. Como paso previo a cualquier intento de manipulación. se produce una situación. en tanto no impacta directamente en la seguridad del sistema. Para ello. En caso de estarlo. debe disminuirse la actividad al mínimo indispensable y tomarse inmediatamente las acciones necesarias para volver a la normalidad. La opción NOCLASSACT del operando INACTIVE permite establecer una lista de clases de la CDT (o todas. Apuntes de RACF Juan Mautalen .135 situación. de todos modos. Inactivar la base de backup ejecutando el comando: RVARY INACTIVE DATASET(nombre-base-backup) 2. bastante molesta por cierto. si se codifica *) para las cuales la protección de RACF no estará en efecto mientras se encuentre la base inactiva. solo que eventualmente no podrá replicar en la base de backup las modificaciones que involucren al correspondiente dataset primario. No debe confundirse esta “inactivación de clases” al momento de inactivar la base con la inactivación habitual de clases que se establece a nivel de la SETROPTS. RACF activará todos los datasets de la base primaria. provocando la entrada del sistema en failsoft processing. Supondremos que la base no se encuentra particionada. situación por cierto de emergencia.Procedimientos de recuperación de bases de RACF Si bien es muy poco frecuente. conocida como failsoft processing. El correspondiente dataset de backup. La opción NOTAPE del operando INACTIVE indica que la protección para cartuchos establecida en la clase TAPEVOL no estará en efecto mientras se encuentre la base inactiva. la protección vuelve a tomar efecto inmediatamente al reactivar la base. Si fuera el caso. tener desactualizada la base de backup no es en absoluto aconsejable. El operando INACTIVE indica que se quiere inactivar (y desalocar) los datasets especificados en DATASET. Analizar qué tipo de problema presenta la base de backup. es necesario inactivarlo y desalocarlo. RACF inactivará todos los datasets de la base primaria. Si un dataset de la base de backup está inactivo. solo deberá aplicarse el procedimiento para los datasets que experimenten problemas. innumerables inconvenientes. usando el IRRUT200. no reemplaza automáticamente al primario. describiendo para cada uno un posible proceso de recuperación. Vamos a analizar 3 posibles escenarios de fallos. se debe proceder cuanto antes a resincronizarla con la base primaria. realocarla con el mismo nombre en un disco adecuado y copiarle la base primaria utilizando el utilitario IRRUT200 con PARM=ACTIVATE. El operando ACTIVE indica que se quiere reactivar los datasets especificados en DATASET. Si fuese necesario. Son de esperar. debe ejecutarse el comando de switch adecuado. Para otro tipo de recursos. En cualquier caso. para lo cual debe ejecutarse el comando RVARY con el operando INACTIVE. RACF continúa procesando de manera normal. Si el sistema se encuentra en failsoft processing. Si se codifica INACTIVE y se omite DATASET. La base primaria funciona correctamente pero falla la base de backup 1. 10. el sistema resulta prácticamente inoperable.5 . es posible que algún dataset de las bases de RACF se dañe y sea necesario repararlo o reemplazarlo. es de esperar que se produzcan errores (abends). Si bien esto no origina ninguna situación crítica. 3. realocarla con el mismo nombre en un disco adecuado y copiarle un backup de la base de RACF lo más actualizado posible y que se encuentre en buenas condiciones. utilizar el utilitario IRRUT200 (si el backup es de igual tamaño y reside en un disco de igual geometría) o el IRRUT400. Apuntes de RACF Juan Mautalen . Switchear las bases ejecutando el comando: RVARY SWITCH 2. Si fuese necesario. Copiar la base primaria sobre la de backup utilizando el utilitario IRRUT200 con PARM=ACTIVATE. deletearla. Switchear las bases nuevamente ejecutando el comando: RVARY SWITCH 4. y un análisis de los registros 80 del SMF correspondientes a este lapso permitiría reconstruir los cambios. que estaba fallando).están fallando 1. Inactivar la base primaria ejecutando el comando: RVARY INACTIVE DATASET(nombre-base-primaria) El sistema entra pues momentáneamente en failsoft processing. 3. Analizar qué tipo de problema presenta la base de backup actual (primaria original. realocarla con el mismo nombre en un disco adecuado y copiarle la base primaria actual (backup original) utilizando el utilitario IRRUT200 con PARM=ACTIVATE. Si fuese necesario. las modificaciones hechas en la base de RACF desde el momento en que se tomó el backup utilizado para la recuperación y el de la falla de ambas bases activas se habrán perdido. Activar la base primaria ejecutando el comando: RVARY ACTIVE DATASET(nombre-base-primaria) El sistema deja pues de estar en failsoft processing. 3. Si el único backup utilizable está en cartucho. Activar la base de backup actual (backup original) ejecutando el comando: RVARY ACTIVE DATASET(nombre-base-backup) Ambas bases -primaria y backup. Inactivar la base de backup ejecutando el comando: RVARY INACTIVE DATASET(nombre-base-backup) 4.136 La base primaria falla y la base de backup funciona correctamente 1. este período debería ser breve (si existe una correcta frecuencia de backups). 2. deletearla. De todos modos. Si se dispone de uno en disco. Analizar qué tipo de problema presenta la base de primaria. copiarlo usando el programa utilitario IEBGENER. En este escenario.