96050513 apuntes de racf

Apuntes de RACF

Juan Mautalen

2

Apuntes de RACF Juan Mautalen

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 (RRSF-Racf 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

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.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.2 - Posit Value de una clase ........................................................................................................... 56

5.3 - Listado de la SETROPTS ......................................................................................................... 56

5.4 - Estadísticas iniciales ................................................................................................................ 59

4


5.5 - Control de programas ............................................................................................................... 60

5.6 - Terminales no protegidas ......................................................................................................... 60

5.7 - Auditoría de usuarios con atributo SPECIAL ........................................................................... 60

5.8 - Auditoría de violación de comandos ......................................................................................... 61

5.9 - Auditoría de usuarios con atributo OPERATIONS ................................................................... 61

5.10 - Clases con estadísticas ........................................................................................................... 62

5.11 - Clases auditadas ..................................................................................................................... 62

5.12 - Clases activas ......................................................................................................................... 63

5.13 - Clases con perfiles genéricos .................................................................................................. 64

5.14 - Clases con comandos genéricos .............................................................................................. 65

5.15 - Clases con perfiles genéricos compartidos en memoria (GENLISTeadas) .............................. 65

5.16 - Clases en la GLOBAL ........................................................................................................... 66

5.17 - Clases con perfiles genéricos y discretos compartidos en memoria –RACLISTeadas- ............ 66

5.18 - Clases RACLISTeadas vía RACROUTE REQUEST=LIST, GLOBAL=YES ........................ 67

5.19 - Opciones de logging para clases ............................................................................................. 68

5.20 - Protección automática de datasets .......................................................................................... 69

5.21 - Uso del ** en perfiles genéricos de dataset ............................................................................. 69

5.22 - Nombres reales de dataset ...................................................................................................... 70

5.23 - Opciones relativas a JES ........................................................................................................ 70

5.24 - Protect-all .............................................................................................................................. 71

5.25 - Protección de archivos en cartucho ......................................................................................... 72

5.26 - Período de retención para archivos en cartucho ...................................................................... 72

5.27 - Borrado físico de archivos ...................................................................................................... 73

5.28 - Archivos de un único calificador ............................................................................................ 74

5.29 - Lista de grupos ....................................................................................................................... 74

5.30 - Revocación automática por inactividad .................................................................................. 75

5.31 - Modelización de perfiles de dataset ........................................................................................ 75

5.32 - Opciones relativas a PASSWORD ......................................................................................... 76

5.33 - Passwords del RVARY .......................................................................................................... 81

5.34 - Opciones de auditoría relativas a security levels y security labels ........................................... 81

5.35 - Restricción para la creación de perfiles más específicos que perfiles existentes ...................... 81

5.36 - Otras opciones vinculadas a security levels y security labels .................................................. 82

5.37 - Acceso a datasets no catalogados ........................................................................................... 83

5.38 - Máximo global y default para la validez de la clave de una sesión .......................................... 84

5.39 - Auditoría de transacciones APPC ........................................................................................... 84

5.40 - Opción ADDCREATOR ........................................................................................................ 85

5.41 - Lenguaje ................................................................................................................................ 85

5.42 - Comandos de REFRESH ....................................................................................................... 85

6 - PROTECCIÓN DE RECURSOS GENERALES ........................................................................ 88

6.1 - Recursos generales y perfiles ................................................................................................... 88

6.2 - Clases de miembros y agrupadoras ........................................................................................... 88

6.3 - Perfiles genéricos ..................................................................................................................... 90

6.4 - Niveles de acceso ..................................................................................................................... 91

6.5 - Cómo determina RACF la protección de un recurso general ..................................................... 91

6.6 - Definición de un perfil de recursos generales ........................................................................... 92

6.7 - Modificación de un perfil de recursos generales ....................................................................... 94

6.8 - Eliminación de un perfil de recursos generales ......................................................................... 94

6.9 - Listado de un perfil de recursos generales ................................................................................ 95

6.10 - Permisos sobre perfiles de recursos generales ......................................................................... 96

6.11 - Comando SEARCH ............................................................................................................... 97

5


7 - CLASES PARTICULARES ....................................................................................................... 101

7.1 - Consideraciones generales ..................................................................................................... 101

7.2 - Clase GLOBAL ..................................................................................................................... 101

7.3 - Clase STARTED ................................................................................................................... 103

7.4 - Clase PROGRAM .................................................................................................................. 106

7.5 - Clase FACILITY ................................................................................................................... 109

8 – PROCESO DE CHEQUEO DE AUTORIDAD ........................................................................ 113


8.2 - Autoridad de un usuario sobre un recurso ............................................................................... 113

9 - PROGRAMAS UTILITARIOS ................................................................................................. 116


9.2 - IRRUT100 ............................................................................................................................. 116

9.3 - IRRUT200 ............................................................................................................................. 118

9.4 - IRRUT400 ............................................................................................................................. 121

9.5 - IRRDBU00 ............................................................................................................................ 124

9.6 - IRRRID00 ............................................................................................................................. 125

9.7 - IRRMIN00 ............................................................................................................................. 128

9.8 - Otros Utilitarios ..................................................................................................................... 130

10 - COMANDO RVARY ................................................................................................................ 132

10.1 - Consideraciones generales ................................................................................................... 132

10.2 - Listado de la configuración de las bases ............................................................................... 133

10.3 - Switch de las bases ............................................................................................................... 133

10.4 - Activación/inactivación de las bases..................................................................................... 134

10.5 - Procedimientos de recuperación de bases de RACF .............................................................. 135

6


1 - INTRODUCCIÓN

1.1 - Consideraciones generales

RACF (Resource Access Control Facility) es el componente del sistema operativo z/OS, provisto por IBM, para brindar seguridad en el entorno mainframe. Si bien el z/OS permite la utilización de otros ESM (External Security Manager) en lugar de RACF, como TOP/SECRET o ACF2, ambos de la empresa Computer Associates, vamos a asumir en todo la presente guía que el ESM utilizado es RACF.

Básicamente, 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.2 - Identificación y autenticación de usuarios

Todo usuario que requiera acceso al entorno del z/OS (subsistemas, aplicaciones, etc.) debe poseer un identificador de usuario (userid) y una clave de acceso (normalmente una password, aunque existen otros medios soportados). RACF se ocupa de identificar al usuario, comprobando que el userid exista en su base. Asimismo, se encarga de autenticarlo, controlando que la password ingresada sea la que corresponde.

Además, RACF controla en el momento del logon ciertos aspectos de seguridad adicionales. Por ejemplo, verifica que el usuario no se encuentre revocado (esto es, que no tenga sus derechos de acceso bloqueados), que esté habilitado a ingresar en ese día y horario o que se encuentre autorizado a ingresar desde esa terminal.

1.3 - Control de acceso a recursos

Cuando un usuario intenta acceder a un recurso protegido por RACF, la aplicación dentro de la cual surge el requerimiento se comunica con RACF enviándole, básicamente, la siguiente información:

o Identificador del usuario

o Nombre del recurso

o Clase a la que pertenece el recurso

o Nivel de autoridad requerido (por ejemplo, lectura o grabación, en el caso de un dataset)

En base a la información recibida, RACF consulta dentro de su base cómo se encuentra protegido el recurso, y devuelve a la aplicación solicitante un código de retorno que indica si el acceso está permitido (RC=00), denegado (RC=08), o si no posee la información necesaria para responder el requerimiento (RC=04). Es la aplicación la que finalmente otorga o rechaza el acceso solicitado, basándose naturalmente en la respuesta recibida de RACF.

1.4 - Herramientas de auditoría

RACF provee una flexible gama de opciones de auditoría, a través de las cuales se pueden detectar, entre otros, los siguientes eventos:

o Día y hora en que un usuario ingresó por última vez al sistema

o Intentos fallidos de ingreso al sistema

o Intentos de acceso a recursos (fallidos y exitosos)

o Intentos fallidos de ejecución de comandos de RACF

7


o Ejecución exitosa de comandos de RACF

o Cantidad de veces en que determinado recurso ha sido accedido

La información relativa a accesos (exitosos o fallidos) se graba en registros tipo 80 del SMF (System

Management Facility). Otro tipo de información, de carácter estadístico, como ser la fecha y hora del último ingreso exitoso de un determinado usuario, o la cantidad de veces que se logueó al sistema, se graba directamente en la base de RACF.

1.5 - Seguridad externa para aplicaciones

RACF, conjuntamente con un componente básico del sistema operativo denominado SAF (System

Authorization Facility), brinda la posibilidad de desarrollar aplicaciones cuya seguridad esté controlada externamente por RACF. En este sentido, es cada vez 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.

Contar con un producto como RACF que centralice la seguridad de todas las aplicaciones, no solo facilita y simplifica enormemente las tareas administrativas, sino que robustece la seguridad global de la plataforma.

8


2 - LA BASE DE RACF


Describiremos, de manera muy básica, la estructura de una base de RACF:

Toda LPAR (Logical Partition) con un sistema operativo z/OS instalado exige la existencia de una base de RACF primaria y de una base de backup (opcional, aunque absolutamente recomendable), que deben residir en disco. La base de backup, que por cuestiones obvias de seguridad conviene que resida en un disco distinto al de la primaria, se actualizará automáticamente cada vez que se efectúen modificaciones (siempre y cuando estén configurados los parámetros necesarios para que esto suceda). De este modo, si la base primaria presenta algún error (situación realmente muy poco frecuente, pero posible), se puede switchear fácilmente a la base de backup y seguir operando normalmente, como veremos en el capítulo que trata el comando RVARY.

La base primaria de RACF puede consistir de un único dataset, o puede estar distribuida en más de uno. El nombre de la base es de libre elección por parte de la organización, aunque naturalmente debe adecuarse a las reglas que rigen la nomenclatura de cualquier dataset dentro del entorno z/OS. Idénticas consideraciones se aplican a la base de backup (si la base primaria esta particionada en más de un dataset, la base de backup debe estar particionada exactamente de la misma manera). 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, el cual se describirá en detalle en el capítulo referido a programas utilitarios. Los datasets que constituyen las bases de RACF deben ser definidos con características específicas, que mencionamos a continuación.

2.2 - Características

Organization PSU Archivo secuencial Unamovable (inamovible) Record format F Registros de longitud fija Record lenght 4096 Longitud de registro de 4K (4096 bytes) Block size 4096 Bloqueo de 4K Secondary cylinders 0 Debe ocupar un único extent

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

SYS1.RACF.PRIM1

BASE PRIMARIA BASE BACKUP

Actualización automática

SYS1.RACF.PRIM2

SYS1.RACF.BACK1

SYS1.RACF.BACK2

9


efectivamente sea sobrescrito con nueva información el área de disco correspondiente a la ubicación original). Debido a esta recomendación, es conveniente que los datasets que conforman las bases de RACF (primaria y backup) residan en discos que no se encuentren bajo SMS (Storage Management

Subsystem), para que puedan alocarse como PSU. De no ser posible, deben alocarse como PS y tomarse todas las precauciones necesarias para que los datasets no sean movidos (mientras se encuentren activos en alguna LPAR).

Es obligatorio que tengan su espacio alocado en forma contigua, o sea que ocupen un único extent.

El tamaño de la base depende, naturalmente, del volumen de información que cada organización tenga almacenada (lo cual no solo involucra la cantidad de usuarios definidos, sino muchos otros factores adicionales). En cualquier caso, desde el punto de vista de storage, el espacio ocupado por las bases de RACF es realmente pequeño. Es habitual y recomendable que la base de backup esté alocada con idéntico tamaño que la primaria.

2.3 - Estructura

La base de RACF tiene una estructura propia bastante compleja. Sólo daremos una idea básica de cómo está organizada, ya que una descripción detallada está más allá de los objetivos de este manual introductorio.

La base de RACF está conformada, esencialmente, por entidades denominadas “perfiles” (profiles), que pueden pensarse como registros que contienen distintos campos. Todo perfil pertenece a una “clase” (class), que está identificada con un nombre de hasta 8 caracteres. Las clases, por lo tanto, agrupan lógicamente a los perfiles. En el RACF que viene con el sistema operativo z/OS 1.11, IBM provee 230 clases predefinidas, cada una con un propósito específico, cuyos nombres son fijos e inalterables. Si fuese necesario, existe la posibilidad de definir clases adicionales. Sin embargo, en la presente guía, solo haremos referencia a las clases predefinidas por IBM, que suelen ser suficientes para satisfacer los requerimientos de seguridad habituales de una organización.

Clase Descripción USER Cada perfil en esta clase representa un usuario GROUP Cada perfil en esta clase representa un grupo DATASET Los perfiles en esta clase son reglas que protegen archivos

Clases de Recursos Generales (solo se enumeran muy pocas, a modo de ejemplo)

TERMINAL Protege el uso de terminales APPL Protege el acceso a aplicaciones VTAM TCICSTRN Protege la ejecución de transacciones CICS PROGRAM Protege la invocación de programas TSOPROC Protege el uso de procedimientos de logon a TSO ACCTNUM Protege el uso de códigos de cuenta OPERCMDS Protege los comandos de consola CONSOLE Protege el uso de las consolas SDSF Protege el uso del SDSF STARTED Reglas que asignan usuarios a Started Task

2.4 - 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.

Los comandos de RACF solo se pueden ejecutar desde una interfaz que los admita, siendo la más usual el entorno TSO. Pueden ser ejecutados en foreground (opción preferible, si se trata de pocos comandos), o batchground (mejor opción si se tiene que ejecutar una gran cantidad).

10


Existe también la posibilidad de ejecutar comandos de RACF utilizando una serie de paneles accesibles desde una sesión de TSO. Estos proporcionan una interfaz amigable para el usuario, evitándole tener que recordar los comandos de RACF y su sintaxis. Sin embargo, el administrador de RACF memorizará rápidamente la sintaxis de los comandos básicos, en cuyo caso la utilización de los paneles resulta lenta y tediosa, siendo mucho más práctico y veloz ejecutar los comandos tipeándolos directamente. Por lo tanto, no haremos referencia en el futuro a la utilización de los paneles, ya que no suelen ser muy utilizados.

Aunque no suele resultar necesario en la operatoria habitual, también se pueden ejecutar comandos de RACF desde una consola del sistema. Esta facilidad cobra especial importancia cuando, por algún motivo, no se disponga de sesiones de TSO.

Es de destacar que un usuario final, que solo tenga acceso a regiones CICS, no tendrá la posibilidad de ejecutar ningún comando de RACF.

Los comandos actúan siempre sobre la base primaria, y son replicados inmediatamente en la base de backup (asumiendo que RACF esté configurado para mantener sincronizadas ambas bases).

Se listan a continuación los comandos de RACF que consideramos más relevantes:

Comando Abreviación Descripción ADDUSER AU Define un usuario nuevo ALTUSER ALU Modifica características de un usuario existente DELUSER DU Borra un usuario LISTUSER LU Lista las características de un usuario ADDGROUP AG Define un nuevo grupo de usuarios ALTGROUP ALG Modifica características de un grupo existente DELGROUP DG Borra un grupo LISTGRP LG Lista las características de un grupo ADDSD AD Define un nuevo “perfil de dataset” ALTDSD ALD Modifica características de un “perfil de dataset” existente DELDSD DD Borra un “perfil de dataset” LISTDSD LD Lista las características de un “perfil de dataset” RDEFINE RDEF Define un nuevo perfil de recursos generales RALTER RALT Modifica características de un perfil de recursos generales existente RDELETE RDEL Borra un perfil de recursos generales RLIST RL Lista las características de un perfil de recursos generales PERMIT PE Modifica las listas de acceso de un perfil PASSWORD PW Cambia la password de un usuario CONNECT CO Conecta un usuario a un grupo REMOVE RE Desconecta un usuario de un grupo SEARCH SR Permite realizar búsquedas en la base de RACF RACDCERT RACDCERT Permite la administración de certificados digitales SETROPTS SETR Lista o modifica opciones de la SETROPTS RVARY RVARY Lista, intercambia y activa/inactiva bases de RACF

Los comandos requieren operandos, algunos posicionales y otros no. A lo largo de la presente guía analizaremos la mayoría de los comandos y describiremos sus operandos más relevantes. A modo de ejemplo, mostramos a continuación un comando que da de alta un usuario en la base de RACF:

11


AU rh3472 NAME(‘juan’) DFLTGRP(rrhh) PASSWORD(abc123)

AU Comando básico, abreviación de ADDUSER. rh3472 Identificador del usuario. Variable posicional que debe seguir al comando AU. NAME Operando no posicional que define el nombre. juan Valor del nombre. DFLTGRP Operando no posicional que define el grupo default. rrhh Valor del grupo default. PASSWORD Operando no posicional que define la password inicial. abc123 Valor de la password inicial –expirada-.

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

12


3 - USUARIOS Y GRUPOS


Toda persona que deba ingresar a alguna aplicación dentro del entorno z/OS necesita tener un identificador de usuario (userid). El mismo consiste en una cadena de caracteres alfanuméricos (incluyendo los caracteres #, $ y @, conocidos como nacionales), con una longitud mínima de 1, máxima de 8 y con la restricción de que el primer carácter no sea numérico. En el caso de usuarios de TSO, la máxima longitud admisible es de 7 caracteres, debido a una restricción propia del TSO.

RACF solo permite el uso de mayúsculas para identificadores de usuarios y grupos (y, en general, para casi todos los demás perfiles). De todos modos, si se ingresa información en minúsculas, la misma es usualmente transformada automáticamente a mayúsculas, de modo que para el administrador resulta como si RACF no distinguiera entre ambas.

Cada organización debe elegir una convención para los identificadores de sus usuarios, de acuerdo a sus necesidades y preferencias. Conviene recalcar la importancia de la adopción de una buena nomenclatura, ya que eso facilita en gran medida la administración posterior (y resulta particularmente trabajoso renombrar gran cantidad de usuarios, si se descubre que la convención elegida inicialmente no es adecuada).

Todo usuario debe ser definido en la base como miembro de un grupo de RACF, que pasa a constituir su "grupo default" (default group). Adicionalmente, el usuario puede estar conectado a otros grupos. Dicho de otro modo, si bien un usuario está eventualmente conectado a varios grupos, uno y solo uno de ellos es su grupo default.

Los grupos son pues conjuntos de usuarios. Todo grupo de RACF tiene un identificador único (grupid), que al igual que en el caso de usuarios, consiste en una cadena de caracteres alfanuméricos (incluyendo #, $ y @); de longitud mínima 1 y máxima 8 y que no debe empezar con un número). 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.

Los grupos de RACF se distribuyen de acuerdo a una estructura de árbol, que surge del hecho de que todo grupo nuevo debe ser definido como subgrupo de otro existente. En lo más alto del árbol se encuentra el grupo SYS1, que viene predefinido por IBM (no es posible cambiar su nombre). SYS1 resulta ser pues el único grupo que no tiene grupo superior (o sea, no es subgrupo de ningún otro).

3.2 - Administración de grupos de RACF

Todas las características de un grupo de RACF se encuentran almacenadas en un “perfil de grupo”. Este perfil tiene distintos campos, de los cuáles solo describiremos los más relevantes.

NOMBRE Nombre del grupo. DATA Información sobre el grupo, con una longitud máxima de 255 caracteres. SUPGROUP Nombre del grupo superior. OWNER Owner del grupo.

Con respecto al nombre, ya señalamos las condiciones que debe cumplir.

La Installation Data, como su nombre completo lo indica, es un campo dónde la organización almacena información administrativa sobre el grupo que considere relevante. Normalmente, este campo contiene una breve descripción del grupo.

El grupo superior es imprescindible, 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).

13


El concepto de owner es particularmente importante, y se aplica a cualquier tipo de perfil en la base de RACF. Todo perfil debe tener un owner, que puede ser un usuario o un grupo. En este caso particular, esto es el owner de un grupo, el valor que puede tomar debe ser un usuario o bien el grupo superior. Dicho de otro modo, no puede establecerse como owner de un grupo a otro que no sea su grupo superior.

3.3 - Alta de un grupo

Sintaxis:

ADDGROUP|AG nombre [DATA(‘installation-data’)] [SUPGROUP(grupo)] [OWNER(usuario/grupo)] [OMVS([GID(valor)])]

El nombre del grupo es requerido y debe estar a continuación del comando ADDGROUP.

Si no se especifica SUPGROUP, el valor que asume por defecto es el “actual grupo de conexión” del usuario que ejecuta el comando.

Si se omite OWNER, el valor por defecto es el usuario que ejecuta el comando.

El operando OMVS solo debe codificarse si se quiere proveer al grupo de un segmento de OMVS. El GID (Group IDentifier) debe ser un número comprendido entre 0 y 2147483647. Si se especifica OMVS y se omite GID, el valor por defecto es 0000000000. Si se omite el operando OMVS, el grupo simplemente queda definido sin este segmento.

Es frecuente, dada la cantidad de operandos que es necesario codificar en algunos casos, que los comandos no entren en una única línea. Si se ejecutan desde un dataset o embebidos en un job, un guión (-) al final de la línea indica que el comando continúa en la siguiente. 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.

Ejemplo:

AG conta DATA(‘Subgerencia de Contabilidad’) SUPGROUP(finanzas) OWNER(finanzas)

Este comando define un nuevo grupo de nombre CONTA. El mismo se define como subgrupo del grupo FINANZAS, que debe existir previamente (sino el comando falla). En este caso, se eligió definir como owner a un grupo, que por lo tanto debe ser el grupo FINANZAS.

Autoridad requerida

Para definir un nuevo grupo, quien ejecuta el comando debe satisfacer alguna de las siguientes condiciones:

� Tener el atributo SPECIAL a nivel de sistema.

� Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de acción al grupo superior del que se intenta definir.

� Ser el owner del grupo superior.

� Estar conectado al grupo superior con nivel de autoridad JOIN.

Para poder definir al grupo con algún “segmento no base” (por ejemplo, el segmento OMVS), el usuario tiene que cumplir alguna de las siguientes condiciones:


� Tener autoridad a través de perfiles apropiados en la clase FIELDS.

14


3.4 - Modificación de un grupo

Sintaxis:

ALTGROUP|ALG nombre [DATA(‘installation-data’)|NODATA] [SUPGROUP(grupo)] [OWNER(usuario/grupo)] [OMVS([GID(valor)|NOGID])|NOOMVS]

Naturalmente, solo es necesario incluir aquellos operandos que correspondan a los campos que se desee modificar. No se aplica, en este caso, ningún valor por defecto.

Ejemplo:

ALG conta DATA(‘Sector de Contabilidad - Jefatura’)

Este comando modifica la Installation Data del grupo CONTA.

Consideraciones:

� Hacemos notar que el nuevo valor especificado en DATA reemplaza íntegramente al valor anterior. No se puede modificar parcialmente este campo. Si se pretende agregar algo a continuación de la DATA existente, debe ejecutarse el comando retipeando toda la DATA. Esto no solo es válido para grupos, sino para la Installation Data de cualquier perfil en la base de RACF.

� No existe la opción de modificar el nombre de un grupo. La única forma que prevé RACF para renombrar un grupo consiste en darlo de baja para luego redefinirlo con el nuevo nombre. Esto es trabajoso, ya que antes de borrar el grupo viejo, debe tomarse debida nota de los usuarios que tiene conectados, así como también de todas sus autorizaciones, de modo que el nuevo grupo resulte un clon del anterior. Al no ser una tarea sencilla, conviene establecer desde el comienzo una buena nomenclatura, de modo a evitar, dentro de lo posible, tener que rebautizar grupos en el futuro.

Autoridad requerida

Para poder modificar el grupo superior, quien ejecuta el comando debe cumplir con alguna de las condiciones siguientes:


� Tanto para el actual grupo superior como para el futuro, satisfacer alguna de las opciones que se enumeran:

- Ser el owner.

- Estar conectado con nivel de autoridad JOIN.

- Tener el atributo SPECIAL a nivel de un grupo que lo tenga dentro de su campo de acción.

Observemos que si el owner del grupo era su grupo superior, no podrá cambiarse el grupo superior sin modificar asimismo el owner (ya que el único grupo que se admite como owner es el grupo superior)

Para poder especificar cualquier otro operando del comando ALTGROUP (con excepción del manejo de segmentos no base), quien ejecuta el comando debe satisfacer alguna de las siguientes condiciones:


� Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de acción al grupo que se modifica.

� Ser el owner del grupo.

Para poder agregar, modificar o deletear “segmentos no base” del grupo, quien ejecuta el comando debe satisfacer alguna de las siguientes condiciones:


15



3.5 - Eliminación de un grupo

Sintaxis:

DELGROUP|DG nombre

Consideraciones:

� RACF no permite borrar un grupo que tenga usuarios conectados. En consecuencia, como paso previo al comando DELGROUP, deben ser removidos todos sus usuarios.

� RACF no permite borrar un grupo que tenga subgrupos. Por lo tanto, debe modificarse el grupo superior de todos aquellos grupos que sean subgrupos del que se quiere borrar.

� RACF no permite borrar un grupo si existen en la base perfiles de dataset cuyo primer calificador (High level Qualifier, o HLQ) coincida con el nombre del grupo. Los mismos deben deletearse previamente a la ejecución de comando DELGROUP, ya que en caso contrario el comando falla.

� La ejecución exitosa del comando DELGROUP no elimina las referencias al grupo que puedan existir en otros perfiles de la base (por ejemplo, el grupo puede figurar en la lista de acceso de perfiles de dataset o de recursos generales). Por esta razón, con el objeto de mantener la base prolija (sin referencias a grupos inexistentes), el borrado del grupo debe ser acompañado de la eliminación de todas las referencias al mismo que existan en la base. Mas adelante veremos que IBM provee, a tal efecto, el utilitario IRRRID00.

Autoridad requerida

Para poder borrar un grupo, quien ejecuta el comando debe cumplir con alguna de las condiciones siguientes:


� Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de acción al grupo que se pretende borrar.

� Ser el owner del grupo superior.

� Estar conectado al grupo superior con nivel de autoridad JOIN.

� Ser el owner del grupo que se pretende deletear.

3.6 - Listado de un grupo

Sintaxis:

LISTGRP|LG nombre [OMVS]

Este comando, a diferencia de los anteriores, no efectúa ninguna modificación sobre la base de RACF. Unicamente lista (en la pantalla de la terminal, si se ejecuta en foreground, o con salida a un dataset o al spool, si se ejecuta en batchground) información relativa al grupo.

Ejemplo:

LG conta OMVS

La salida tendría el siguiente aspecto:

INFORMATION FOR GROUP CONTA

SUPERIOR GROUP=FINANZAS OWNER=FINANZAS CREATED=10.245 INSTALLATION DATA=SECTOR DE CONTABILIDAD - JEFATURA NO MODEL DATA SET TERMUACC

16


SUBGROUP(S)= PAGOS SUELDOS

USER(S)= ACCESS= ACCESS COUNT= UNIVERSAL ACCESS=

CONJF01 USE 001475 NONE CONNECT ATTRIBUTES=NONE REVOKE DATE=NONE RESUME DATE=NONE

CONFJ02 USE 002487 NONE CONNECT ATTRIBUTES=NONE REVOKE DATE=NONE RESUME DATE=NONE

OMVS INFORMATION GID= 0000000015

Del listado precedente, se desprende claramente la siguiente información sobre el grupo CONTA:

� El grupo superior es el grupo FINANZAS.

� El owner del grupo CONTA es el grupo FINANZAS.

� El grupo fue creado el día 245 del año 2010.

� El grupo CONTA tiene 2 subgrupos, cuyos nombres son PAGOS y SUELDOS.

� El grupo CONTA tiene 2 usuarios conectados, de identificadores CONFJ01 y CONFJ02.

� El grupo CONTA tiene segmento de OMVS con un GID igual 15.

No describiremos, en este punto, el resto de la información listada, ya que para comprender ciertos campos específicos se requieren nociones que se verán más adelante (MODEL y TERMUACC, por ejemplo).

Autoridad requerida

Para listar el segmento base de un perfil de grupo, quien ejecuta el comando debe cumplir con alguna de las condiciones siguientes:


� Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de acción al grupo que se pretende listar.

� Tener el atributo AUDITOR a nivel de sistema.

� Tener el atributo AUDITOR a nivel de un grupo que tenga dentro de su campo de acción al grupo que se pretende listar.


� Estar conectado al grupo con nivel de autoridad CONNECT o JOIN.

Para poder listar “segmentos no base” del grupo, quien ejecuta el comando debe satisfacer alguna de las siguientes condiciones:



3.7 - Administración de usuarios de RACF

Todas las características de un usuario de RACF se encuentran almacenadas en un perfil de usuario, que consta de un segmento base (obligatorio), más, opcionalmente, algunos segmentos no base (por ejemplo, segmentos de TSO, OMVS, etc.). Todos los segmentos se componen de campos, de los cuales nos ocuparemos en este punto únicamente de los más relevantes.

17


Segmento Base

USERID Identificador del usuario. NAME Nombre asociado con el usuario, de longitud máxima 20. DATA Información sobre el usuario, con una longitud máxima de 255 caracteres. DFLTGRP Nombre del grupo default del usuario. PASSWORD Password que se otorga usuario. OWNER Owner del usuario.

Segmento de TSO PROC Nombre del procedimiento de logon a TSO (default) para el usuario ACCTNUM Código de cuenta (default) para el usuario COMMAND Comando a ejecutarse durante el logon a TSO SIZE Tamaño mínimo de la región, expresado en Kbytes, default para el usuario MAXSIZE Tamaño máximo que el usuario puede requerir en el momento de logon

Segmento de OMVS UID UID del usuario. Número entre 0 y 2147483647. 0 indica superusuario. HOME Home directory del usuario. PROGRAM Shell asignado.

Con respecto al identificador del usuario, ya señalamos anteriormente las condiciones que debe cumplir.

En el campo NAME, si se trata de una persona física, se pone usualmente su nombre y apellido. En el caso de usuarios asociados a procesos, se puede colocar un nombre que identifique la tarea para la que es utilizado.

En la DATA, la organización guarda información administrativa que considere importante sobre el usuario. Por ejemplo, se puede incluir su número de documento y el sector de la empresa dónde desempeña sus tareas.

El grupo default debe ser un grupo que exista previamente en la base de RACF.

La password inicial es una clave expirada, lo cual significa que el usuario es forzado a cambiarla en el momento del logon inicial. Por esta razón, 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). Debe tener una longitud máxima de 8 caracteres.

Es de destacar que RACF permite también la autenticación a través de Password Phrases, que son cadenas de caracteres alfanuméricos y especiales (incluyendo blancos), de longitud mínima 9 y máxima 100. Presentan una posibilidad más robusta que las passwords tradicionales, dada su mayor longitud. Sin embargo, por el momento son de utilidad limitada ya que existen aplicaciones que no las soportan, algunas de uso muy difundido. CICS, por ejemplo, acaba de anunciar el soporte de Password Phrases para su versión 4.2, que recién estará disponible a mediados del 2011. También debemos señalar que, aún cuando el usuario tenga asignada una Password Phrase, debe también obligatoriamente contar con una password tradicional (que podría ser desconocida por el usuario, para que se vea obligado a autenticarse usando su Password Phrase). Por lo tanto, si bien creemos importante mencionar su existencia y entendemos que en el futuro van seguramente a desempeñar un rol relevante, no haremos más referencias a ellas en el presente manual.

El OWNER del usuario puede ser cualquier otro grupo o usuario existente en la base de RACF.

El segmento de TSO solo debe definirse para usuarios que tengan que usar esta facilidad. La mayoría de los parámetros especificados se convierten en los valores default para el usuario, quien puede cambiarlos, de ser necesario, en la pantalla de logon a TSO.

18


El segmento de OMVS solo debe definirse para usuarios que lo necesiten. Existe incluso, a partir del z/OS 1.11, la posibilidad de configurar RACF de forma que este segmento se le agregue automáticamente a los usuarios la primera vez que invoquen algún servicio Unix que lo requiera.

3.8 - Alta de un usuario

Sintaxis:

ADDUSER|AU userid [NAME(‘nombre’)] [DFLTGRP(grupo)] [DATA(‘installation-data’)] [PASSWORD(clave-inicial)|NOPASSWORD] [OWNER(usuario/grupo)] [AUTHORITY(nivel)] [UACC(nivel)] [SPECIAL|NOSPECIAL] [OPERATIONS|NOOPERATIONS] [AUDITOR|NOAUDITOR] [RESTRICTED|NORESTRICTED] [GRPACC|NOGRPACC] [ADSP|NOADSP] [CLAUTH(clase)|NOCLAUTH] [WHEN(DAYS(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 codifica NAME, este campo aparece como UNKNOWN cuando se lista el usuario a través del comando LISTUSER.

Si no se especifica DFLTGRP, el valor que asume por defecto es el “actual grupo de conexión” del usuario que ejecuta el comando.

Si no se especifica DATA, este campo queda vacío y al listar el usuario se muestra la leyenda “NO-INSTALLATION_DATA”.

Si no se codifica PASSWORD, asume por defecto como password inicial el grupo especificado en el operando DFLTGRP. Esto no es para nada recomendable desde el punto de vista de la seguridad, ya que los nombres de los grupos suelen ser públicos. Por lo tanto, es aconsejable siempre especificar una password, de modo a evitar que asuma el valor por defecto.

Si se especifica NOPASSWORD, y el usuario tiene también NOOIDCARD (que es el defecto), el usuario adquiere el atributo PROTECTED, del cual hablaremos en más adelante.

Los atributos SPECIAL, OPERATIONS, AUDITOR, RESTRICTED, GRPACC, ADSP y CLAUTH no se otorgan, salvo que se los codifique explícitamente.

Si se omite OWNER, el valor por defecto es el usuario que ejecuta el comando.

AUTHORITY indica el nivel de autoridad que tendrá el usuario como miembro de su grupo default. El valor por defecto es USE. Más adelante se verán en detalle los posibles valores y su significado.

UACC indica el acceso universal del usuario para su grupo default. El valor por defecto es NONE. Mas adelante, al analizar un ejemplo del comando LISTUSER, se verán en detalle los posibles valores y su significado.

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. Este chequeo se realiza únicamente en el momento en que RACF procesa el pedido de logon. Por lo tanto, si el usuario ingresó en un día y horario válidos, pero su sesión se extendió más allá de los límites permitidos, no será forzado a salir del sistema (naturalmente, en tal caso, si cierra la sesión, ya no podrá reingresar). Estas restricciones no se aplican para la ejecución de trabajos batch (o sea, un job del usuario puede iniciarse y ejecutarse fuera de los días y horarios permitidos). Si no se especifica el operando WHEN, el valor por defecto es ANYDAY/ANYTIME, lo cual autoriza al usuario a ingresar en cualquier día y horario. Por ejemplo, podría establecerse que el usuario solo esté habilitado para ingresar al sistema lunes, miércoles y viernes de 8 a 19:30 horas. En tal caso, debería codificarse el operando WHEN del siguiente modo:

WHEN(DAYS(monday wednesday friday) TIME(0800:1930))

19


Para los operandos TSO y OMVS, solo se indicaron los suboperandos más frecuentes, existiendo varios otros. Si no se especifica TSO u OMVS, el usuario simplemente queda definido sin tal segmento.

Autoridad requerida

Para definir un nuevo usuario, quien ejecuta el comando debe cumplir con alguna de las condiciones siguientes:


� Tener CLAUTH en la clase USER y verificar además alguno de los siguientes requisitos:

- Ser el owner del grupo default especificado en el comando ADDUSER.

- Estar conectado con nivel de autoridad JOIN al grupo default especificado en el comando ADDUSER.

- Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de acción al grupo default especificado en el comando ADDUSER.

Para poder definir al usuario con algún segmento no base (por ejemplo, segmentos de TSO u OMVS), quien ejecuta el comando tiene que cumplir alguna de las siguientes condiciones:



3.9 - 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, solo es necesario incluir los operandos que corresponden a los campos que se quiere modificar .No se aplica ningún valor por defecto en este caso.

DFLTGRP indica el nombre del nuevo grupo default del usuario, al cual debe encontrarse conectado previamente. Observemos que el usuario continúa conectado a su antiguo grupo default.

EXPIRED|NOEXPIRED solo surte efecto si ha sido codificado el operando PASSWORD.

El valor por defecto es EXPIRED, el cual indica que el usuario está obligado a cambiar su password por una nueva en el momento de su próximo logon. Por ello, en este caso, no es necesario que la password otorgada cumpla con las reglas fijadas por la organización, que se encuentran especificadas en la SETROPTS. Debe, de todos modos, tener una longitud máxima de 8 caracteres.

NOEXPIRED indica que el usuario no estará forzado a cambiar su password en el momento de su próximo logon (aunque naturalmente puede hacerlo, si así lo desea y la aplicación lo permite). De todos modos, ello no significa que su password nunca venza. El usuario, 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. Toda password dada con NOEXPIRED debe adecuarse a las reglas fijadas en la SETROPTS.

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 se omite GROUP, pero se codifica AUTHORITY o UACC, 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, actúan sobre viejo).

REVOKE(mm/dd/aa) especifica una fecha futura a partir de la cual el usuario no podrá acceder al sistema. Si la fecha ingresada no es posterior a la fecha actual, RACF informa que la fecha no es válida, y envía al usuario que ejecuta el comando un mensaje para que especifique una fecha futura (esto último, suponiendo que el comando se ejecuta en foreground. Si la ejecución es en batch, simplemente se ignora el operando, por fecha inválida). Mientras el usuario tenga una fecha de revocación futura, se considera que tiene un REVOKE pendiente. Si se codifica REVOKE sin especificar fecha, el REVOKE toma efecto la próxima vez que el usuario ingrese al sistema. En este caso, el usuario adquiere el atributo REVOKED (más adelante veremos en detalle todos los atributos de usuario).

NOREVOKE tiene como efecto quitar la fecha de revocación futura, si el usuario la tuviera.

RESUME(mm/dd/aa) especifica una fecha futura a partir de la cual el usuario podrá acceder al sistema nuevamente. Usualmente, se utiliza este operando para anular el efecto del REVOKE. En el caso en que el usuario no tenga un REVOKE pendiente, o no tenga el atributo REVOKED, el RESUME(mm/dd/aa) es ignorado. Mientras el usuario tenga una fecha de resume futura, se considera que tiene un RESUME pendiente. Si se codifica RESUME sin especificar fecha, el RESUME toma efecto inmediatamente (o sea, habilita al usuario a ingresar al sistema de inmediato) y le saca el atributo REVOKED, si lo tuviera.

NORESUME tiene como efecto quitar la fecha de resume futura, si el usuario la tuviera.

Si se especifican ambos operandos REVOKE(mm/dd/aa) y RESUME(mm/dd/aa), las fechas no deben entrar en conflicto (básicamente, la fecha especificada en RESUME debe ser posterior a la fecha del REVOKE). Por ejemplo, el siguiente comando inhabilita al usuario fin7632 a usar el sistema desde el 1/1/2010 hasta el 31/1/2010.

ALU fin7632 REVOKE(1/1/10) RESUME(31/1/10)

Con respecto al formato de la fecha, el mismo debe ser mes/día/año. Los ceros a la izquierda, para mes y día, pueden ser omitidos (1/1/03 equivale a 01/01/03). El año debe ser siempre de 2 dígitos, 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. Si el grupo especificado en DFLTGRP no es un grupo al cual esté conectado, el grupo default no es alterado. Esto no evita que el resto del comando se procese. Es posible y frecuente que un comando de RACF solo resulte exitoso parcialmente.

� No existe la opción de modificar el identificador de un usuario. La única forma prevista por RACF para renombrar un usuario consiste en deletearlo y darlo de alta nuevamente con el nuevo identificador. Esto es trabajoso, ya que antes de borrar el usuario viejo, debe tomarse debida nota de los grupos a los que se encuentra conectado, así como también de todas las autorizaciones que tiene, de modo que el nuevo usuario resulte un clon del anterior. Al no ser una tarea sencilla, conviene establecer desde el comienzo una buena nomenclatura de usuarios, de modo a evitar, dentro de lo posible, tener que rebautizar en el futuro.

Autoridad requerida

El nivel de autoridad requerido depende del campo del perfil de usuario que se pretenda modificar. Mencionamos a continuación algunos casos, que consideramos los más relevantes. La lista no pretende de ningún modo ser exhaustiva.

21


� El atributo SPECIAL a nivel de sistema permite especificar cualquier operando, con excepción de UAUDIT/NOUAUDIT.

� Si el owner del usuario está dentro del campo de acción de un grupo en el cual el usuario tiene el atributo SPECIAL, entonces puede especificar cualquier operando, con excepción de SPECIAL, AUDITOR, OPERATIONS y UAUDIT/NOUAUDIT.

� Si es el owner del usuario, entonces básicamente puede especificar cualquier operando, con excepción de SPECIAL, AUDITOR, OPERATIONS y UAUDIT/NOUAUDIT. Para otorgar CLAUTH sobre una clase debe además tener él mismo CLAUTH sobre ella.

� Todo usuario puede cambiar su NAME y DFLTGRP. Naturalmente, si decide cambiar su grupo default, debe encontrarse previamente conectado al nuevo grupo que especifique.

� Para poder otorgar los atributos SPECIAL, AUDITOR y OPERATIONS a nivel de sistema se requiere el atributo SPECIAL a nivel de sistema.

� Para especificar UAUDIT/NOUAUDIT, es necesario tener el atributo AUDITOR a nivel de sistema, o bien a nivel de un grupo que tenga al usuario dentro de su campo de acción.

� Para agregar, modificar o deletear información de “segmentos no base” del usuario, se requiere el atributo SPECIAL a nivel de sistema o bien tener suficiente autoridad en perfiles apropiados de la clase FIELDS.

� Si tiene autorización sobre el recurso IRR.PASSWORD.RESET de la clase FACILITY puede otorgar una nueva password para cualquier usuario (ver 7.5).

3.10 - Eliminación de un usuario

Sintaxis:

DELUSER|DU userid

Este comando borra de la base de RACF el perfil del usuario, así como también elimina las conexiones que el usuario pueda tener a distintos grupos. Por lo tanto, no solo deletea el perfil del usuario, sino que también modifica los perfiles de los grupos a los cuales se encuentra conectado. Es habitual, como se ve en este ejemplo, que un comando de RACF impacte sobre más de un perfil de la base.

Sin embargo, el comando DELUSER no elimina al usuario de otros perfiles de la base dónde pueda figurar. Por ejemplo, el usuario puede estar en listas de acceso, o puede ser owner de algún otro perfil de la base. Si bien la existencia de tales referencias no impide la ejecución exitosa del comando DELUSER, no es una buena práctica dejar en la base referencias a usuarios inexistentes. Por lo tanto, del mismo modo que en el caso de la eliminación de grupos, es apropiado identificarlas y borrarlas.

Consideraciones:

� No es posible borrar un usuario si existen en la base perfiles de dataset cuyo HLQ sea igual al identificador del usuario. Los mismos deben borrarse previamente, ya que en caso contrario el comando DELUSER falla.

� En concordancia con lo anterior, también deben renombrarse (o deletearse, si no fuese necesario conservarlos) los datasets cuyo HLQ coincida con el identificador del usuario. Esto hay que hacerlo antes de borrar los perfiles de dataset, para evitar, por un lado, tener que manipular archivos “no protegidos”, así como también para preservar su nivel de protección, si alguno de ellos tuviera un perfil discreto. Esto quedará claro en el capítulo siguiente, cuando tratemos específicamente la protección de datasets.

� Si el usuario a eliminar se encuentra trabajando dentro del sistema en el momento en que se ejecuta el comando de baja, es muy posible que pueda seguir haciéndolo normalmente hasta que cierre su sesión. Obviamente, una vez que salga del sistema, ya no podrá ingresar nuevamente. Si resultara imprescindible que cese de inmediato toda actividad, se puede solicitar a los operadores del equipo que cancelen todas las sesiones que pueda tener activas.

22


� Como dar de baja a un usuario de manera adecuada puede llevar algo de tiempo, resulta útil, como medida inicial, revocarle su acceso al sistema ejecutando el comando:

ALTUSER userid REVOKE

De este modo, el usuario queda imposibilitado de ingresar al sistema (si ya está adentro, corresponden las mismas consideraciones que en el punto anterior) durante el tiempo que insuman los pasos previos a la baja. Incluso, en algunas organizaciones, se va revocando diariamente a los usuarios a ser dados de baja, hasta que al cabo de una semana, por ejemplo, se ejecuta un proceso que los borra efectivamente.

Autoridad requerida

Para poder deletear un usuario, quien ejecuta el comando debe cumplir con alguna de las condiciones siguientes:


� Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de acción al usuario que se pretende eliminar.

� Ser el owner del usuario.

Estar conectado a su grupo default con nivel de autoridad JOIN no es suficiente para poder deletear el usuario.

3.11 - Listado de un usuario

Sintaxis:

LISTUSER|LU userid [TSO] [OMVS]

Este comando no efectúa ninguna modificación sobre la base de RACF. Únicamente lista información relativa al usuario. Si se especifica el operando TSO u OMVS, se lista también tal segmento. Si no se especifican especialmente, los segmentos no base no son listados (existen varios más que los dos mencionados, pero no nos ocuparemos de ellos en esta guía).

Ejemplo:

LU fin7632 TSO OMVS


USER= FIN7632 NAME= PEREZ ALEJANDRA OWNER= FINADM CREATED= 10.158 DEFAULT-GROUP= FINANZAS PASSDATE= 10.308 PASS-INTERVAL= 30 PHRASEDATE=N/A ATTRIBUTES= NONE REVOKE DATE= NONE RESUME DATE= NONE LAST-ACCESS= 10.309/09:48:25 CLASS AUTHORIZATIONS= NONE INSTALLATION-DATA= DNI:24857632 NO-MODEL-NAME LOGON ALLOWED (DAYS) (TIME) --------------------------------------------------------------- ANYDAY ANYTIME

GROUP= FINANZAS AUTH= USE CONNECT-OWNER= FINADM CONNECT-DATE= 10.158 CONNECTS= 857 UACC= NONE LAST-CONNECT= 10.309/09:48:25 CONNECT ATTRIBUTES= NONE REVOKE DATE= NONE RESUME DATE= NONE

GROUP= COBROS AUTH= USE CONNECT-OWNER= FINADM CONNECT-DATE= 10.184 CONNECTS= 00 UACC= NONE LAST-CONNECT= UNKNOWN CONNECT ATTRIBUTES= NONE REVOKE DATE= NONE RESUME DATE= NONE

SECURITY-LEVEL= NONE SPECIFIED

23


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

Del listado precedente, se obtiene gran cantidad de información sobre el usuario FIN7632, entre la que destacamos la siguiente:

� El grupo default es el grupo FINANZAS.

� El campo CREATED indica la fecha de creación del usuario, en formato juliano. En el ejemplo expuesto, el usuario fue dado de alta el 7 de junio del año 2010 (día 158 del año 10).

� El OWNER es FINADM, que en principio podría ser un grupo o un usuario. En caso de ser un usuario, esto no significa que sea FINADM quién ejecutó el comando de alta. 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, dónde se loguea información sobre los comandos de RACF ejecutados).

� PASSDATE indica la fecha en la que el usuario cambió su password por última vez. Todo usuario puede cambiar su password en cualquier momento, si así lo desea, ya sea a través del comando PASSWORD, o bien mediante los paneles de logon de ciertas aplicaciones (TSO o CICS, por ejemplo). El valor 00.000 significa que el usuario tiene una password expirada. Esto indica que aún no ha ingresado desde que el administrador se la otorgó.

� PASS-INTERVAL establece la cantidad de días que la password de este usuario permanecerá válida, contados a partir del día en que se cambió por última vez. El valor debe estar comprendido entre 1 y 254. De todos modos, 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. Por ejemplo, si el usuario tiene PASS-INTERVAL=45 en su perfil, pero el valor de la SETROPTS es 30, tendrá que cambiar su password obligatoriamente cada 30 días.

PASS-INTERVAL=N/A indica que el usuario tiene una password que nunca vence. Desde el punto de vista de seguridad, esta es una opción poco recomendable. Es útil, sin embargo, para usuarios que no corresponden a personas físicas (siempre y cuando se pueda tener certeza de que nadie conoce su password). Si ambos campos PASSDATE y PASS-INTERVAL tienen el valor N/A, entonces el usuario tiene el atributo PROTECTED, al cual nos referiremos más adelante.

� 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.

� El campo LAST-ACCESS indica fecha y hora en que el usuario ingresó al sistema por última vez, con ciertas salvedades:

- Si al usuario se le da un RESUME, los valores del campo LAST-ACCESS son actualizados con la fecha y hora en que se ejecutó el comando.

24


- Si se cambia la password del usuario, ya sea con el comando ALTUSER o PASSWORD, los valores del campo LAST-ACCESS son actualizados con la fecha y hora en que se ejecutó el comando.

- Si un job se ejecuta bajo la identidad del usuario, los valores del campo LAST-ACCESS son igualmente actualizados con la fecha y hora de iniciación del job.

- Si el usuario nunca ingresó, el campo LAST-ACCESS muestra el valor UNKNOWN.

Es importante tener en cuenta estos detalles, para no interpretar erróneamente la información brindada por el campo LAST-ACCESS.

� LOGON ALLOWED (anyday anytime) significa que el usuario no tiene ninguna restricción de día y horario para ingresar al sistema.

A continuación, en la salida del comando LU, figuran todos los grupos a los cuales el usuario está conectado, mostrando varios parámetros que caracterizan cada conexión. El primer grupo listado es siempre el grupo default del usuario (recordemos que todo usuario está conectado, como mínimo, a su grupo default). Para cada uno de los grupos, la información mostrada tiene idénticos campos, que describimos a continuación:

� Un usuario es conectado a un grupo con un determinado nivel de autoridad. Este se muestra en el campo AUTH, y sus posibles valores son: USE, CREATE, CONNECT y JOIN (enumerados en orden jerárquico, o sea que cada uno incluye los privilegios del anterior). El valor por defecto es USE, suficiente para la casi totalidad de los casos. Más adelante discutiremos en detalle los alcances de cada uno de estos niveles.

� CONNECT-OWNER es un campo que se mantiene por razones de compatibilidad con versiones anteriores de RACF, pero que actualmente es totalmente irrelevante desde el punto de vista de seguridad. El valor que asume por defecto es el usuario que conectó el usuario al grupo.

� CONNECT-DATE muestra la fecha en que el usuario fue conectado al grupo.

� El campo CONNECTS indica la cantidad de veces que el usuario ingresó al sistema especificando este grupo en el momento de logon (tanto CICS como TSO permiten, por ejemplo, especificar un grupo en la pantalla de logon). Como actualmente es muy habitual que la opción GRPLIST esté activa en la SETROPTS (esto se analizará en detalle más adelante, en el capítulo dedicado a la SETROPTS), no suele especificarse un grupo distinto del default en la pantalla de logon. En virtud de ello, es frecuente que solo se incremente la cuenta del campo CONNECTS para el grupo default del usuario, quedando el mismo en 00 para los otros grupos. Así, en el ejemplo mostrado, el usuario FIN7632 se conectó 857 veces usando su grupo default, de nombre FINANZAS, mientras que la cuenta para el otro grupo al que está conectado, llamado COBROS, permanece en 00. Esto no significa, de ninguna manera, que el usuario no esté haciendo uso de su conexión al grupo COBROS. Obtener acceso a un recurso protegido gracias d pertenecer a un cierto grupo no incrementa el valor del campo CONNECTS para ese grupo. Solo se incrementa el contador cuando el usuario se loguea a una aplicación especificando al grupo como “grupo de conexión”.

� El campo UACC en la conexión de un usuario a un grupo puede tomar los valores NONE, READ, UPDATE, CONTROL o ALTER, siendo NONE el valor por defecto. Este parámetro, que se especifica a nivel de grupo, determina el UACC de los perfiles de dataset o de recursos generales que el usuario eventualmente defina en la base de RACF, siempre y cuando haya iniciado la sesión especificando este grupo como “grupo de conexión”, y se cumpla que:

- El usuario no codifica explícitamente el operando UACC en la definición del perfil. En caso contrario, este valor prevalece.

- Para perfiles de recursos generales, la clase de RACF correspondiente no debe tener DFTUACC especificado en la CDT (Class Descriptor Table), pues de otro modo el perfil toma por defecto ese valor.

25


Por ejemplo, si un usuario tiene UACC(READ) especificado en su conexión a su grupo default, (y se loguea a TSO sin cambiar el grupo en el panel de logon, de modo que su grupo de conexión sea efectivamente su grupo default), entonces si define un perfil de dataset y no especifica UACC, el perfil quedará definido con UACC(READ).

La enorme mayoría de los usuarios no define perfiles en la base de RACF, por lo cual el UACC de la conexión no tiene mayor relevancia. Para los usuarios administradores, que deben definir nuevos perfiles en la base de RACF, conviene de todos modos conservar el valor default UACC=NONE en la conexión a cada uno de sus grupos. De este modo, los perfiles de RACF que definan tendrán por defecto UACC(NONE), lo cual es conveniente desde el punto de vista de seguridad. Si necesitaran crear un perfil con un UACC distinto de NONE, no tienen más que codificar dicho operando con el valor deseado en el comando de definición del perfil.

� El campo LAST-CONNECT muestra fecha y hora en la que el usuario ingresó por última vez al sistema con este grupo como "grupo de conexión". Recordemos que si el usuario no especifica grupo en la pantalla de logon (TSO, CICS, etc.), el grupo de conexión resulta ser su grupo default. Por lo tanto, es muy frecuente que el campo LAST-CONNECT solo esté actualizado para el grupo default del usuario (tal como sucede con el campo CONNECTS). Si el usuario nunca inició una sesión con determinado grupo, el LAST-CONNECT para este grupo muestra el valor UNKNOWN.

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, a diferencia del campo LAST-ACCESS, no se actualiza si se le da al usuario un RESUME o una nueva password (pero si es actualizado cuando se inicia un job bajo su identidad). De todos modos, es frecuente que los valores de los campos LAST-ACCESS y LAST-CONNECT para el grupo default coincidan.

� CONNECT-ATTRIBUTES muestra los atributos del usuario relativos a su conexión al grupo. Los usuarios se dividen en atributos a nivel de sistema, que figuran en el campo ATTRIBUTES, y atributos a nivel de grupo. Más adelante los analizaremos en detalle.

� REVOKE DATE y RESUME DATE funcionan, a nivel de grupo, de modo similar a como lo hacen a nivel global. Sin embargo, a nivel grupal, se establecen a través del comando CONNECT, que veremos cuándo analicemos las conexiones de usuarios a grupos.

� SECURITY-LEVEL, CATEGORY-AUTHORIZATION y SECURITY-LABEL son campos relacionados con un nivel extra de seguridad que provee RACF, realmente poco utilizado. Básicamente, 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. Si la organización no usa esta seguridad adicional, los 3 campos deben mostrar NONE SPECIFIED para todos los usuarios de la base de RACF.

Autoridad requerida

Todo usuario puede listar el segmento base de su propio perfil. Para listar el segmento base del perfil de otro, debe cumplir con alguna de las condiciones siguientes:



� Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de acción al usuario a listar.

� Tener el atributo AUDITOR a nivel de sistema.

� Tener el atributo AUDITOR a nivel de un grupo que tenga dentro de su campo de acción al usuario a listar.

� Tener acceso READ sobre el recurso IRR.LISTUSER de la clase FACILITY (ver 7.5).

26


Para poder listar “segmentos no base”, debe satisfacer alguna de las siguientes condiciones:



3.12 - Comando PASSWORD

Sintaxis:

PASSWORD|PW [USER(userid)] [PASSWORD(clave-actual clave-nueva)] [INTERVAL(valor)|NOINTERVAL]

El comando PASSWORD permite a un usuario cambiar su clave, así como también su INTERVAL.

USER indica el usuario cuya password se va a modificar. Si se codifica USER y no se establece la opción INTERVAL|NOINTERVAL, la password del usuario es reseteada al valor de su grupo default y queda expirada (el usuario deberá forzosamente cambiarla en el momento de logon). Si, por el contrario, se codifica USER junto con alguna de las opciones INTERVAL|NOINTERVAL, la password del usuario no se altera, siendo modificado únicamente su intervalo de validez. El operando PASSWORD es ignorado si se ha especificado USER.

El operando PASSWORD permite cambiar la clave propia en cualquier momento. Para ello, no debe especificarse el operando USER. Resulta conveniente ingresar PASSWORD sin especificar los valores de las passwords, ya que en tal caso RACF promptea al usuario para que los introduzca por pantalla y no resultan visibles mientras se los tipea.

INTERVAL establece el valor del campo PASS-INTERVAL del usuario especificado en el operando USER (si éste se omitiera, el cambio afecta al usuario que ejecuta el comando). El valor debe estar comprendido entre 1 y 254, no pudiendo exceder el máximo global fijado en la SETROPTS. Si se codifica INTERVAL sin especificar valor, se toma por defecto el máximo global de la SETROPTS.

NOINTERVAL establece que la clave del usuario nunca vence, en cuyo caso el campo PASS-INTERVAL muestra el valor N/A. Tal cual indicáramos anteriormente, debe usarse esta opción solo en contados casos que lo justifiquen.

El comando PASSWORD es realmente poco usado, ya que lo habitual es que los usuarios cambien su password a través de la pantalla de logon de las aplicaciones (TSO, CICS, etc.), y no se preocupen en modificar su INTERVAL. Es imprescindible, sin embargo, para otorgar a un usuario una password que nunca venza.

Autoridad requerida

Todo usuario está autorizado a modificar su propia password y el intervalo de validez de la misma (no puede, sin embargo, usar la opción NOINTERVAL, salvo que tenga la autoridad suficiente).

Para resetear la password de otro usuario al valor de su grupo default, quien ejecuta el comando debe cumplir con alguna de las siguientes condiciones:


� Tener el atributo SPECIAL a nivel de un grupo que tenga al usuario dentro de su campo de acción.


Para cambiar el intervalo de validez de la password de otro usuario, o especificar NOINTERVAL, quien ejecuta el comando debe cumplir con alguna de las siguientes condiciones:



27


3.13 - Atributos de usuario

Los atributos son facultades extraordinarias, o restricciones, que se le pueden otorgan a un usuario. Como ya mencionáramos anteriormente, se pueden dar tanto a nivel de sistema (system level attributes), en cuyo caso de denominan simplemente atributos del usuario, como a nivel de la conexión del usuario con un grupo, en cuyo caso se llaman atributos relativos a grupos. Cuando son especificados a nivel de sistema, actúan en todo momento. En cambio, cuando se otorgan a nivel de grupo, dependiendo del atributo, o actúan de manera más acotada, o bien solo lo hacen cuando el usuario ingresó especificando ese grupo en la pantalla de logon. En un principio, analizaremos los “atributos a nivel de sistema”. Luego indicaremos de que manera actúan cuando se los especifica a nivel de grupo.

Atributos a nivel de sistema

Los atributos que se pueden otorgar a nivel de sistema son los siguientes:

o SPECIAL

o AUDITOR

o OPERATIONS

o CLAUTH

o REVOKE

o GRPACC

o ADSP

o RESTRICTED

o PROTECTED

o UAUDIT

En general, se otorgan, ya sea en el momento de la creación del usuario (comando ADDUSER), o bien con posterioridad (comando ALTUSER), especificando como parámetro no posicional el nombre del atributo (con excepción de CLAUTH, que debe ir acompañado del nombre de una clase, y de PROTECTED). Los atributos REVOKE y UAUDIT solo pueden otorgarse con el comando ALTUSER, es decir con posterioridad a la creación del usuario.

Para quitarlos, debe ejecutarse el comando ALU, poniendo como parámetro el nombre del atributo antecedido por el prefijo NO, con las siguientes excepciones:

- El atributo REVOKE se quita especificando el operando RESUME.

- El atributo PROTECTED se quita otorgando una password al usuario.

Ejemplos:

1) ALTUSER jefa524 AUDITOR Este comando le da al usuario JEFA524 el atributo AUDITOR a nivel de sistema.

2) ALTUSER jefa524 SPECIAL NOOPERATIONS Este comando le otorga al usuario JEFA524 el atributo SPECIAL a nivel de sistema, y le saca el atributo OPERATIONS a nivel de sistema, si lo tuviera.

3) ALTUSER jefa524 CLAUTH(tsoproc) RESUME Este comando le otorga al usuario JEFA524 el atributo CLAUTH en la clase TSOPROC a nivel de sistema, y le saca el atributo REVOKE (si lo tuviera a nivel de sistema).

Atributo SPECIAL

El atributo SPECIAL a nivel de sistema confiere al usuario la autoridad para ejecutar cualquier comando de RACF. Por lo tanto, el atributo SPECIAL otorga un absoluto control sobre la base de

28


RACF, pudiendo los usuarios que lo tienen, definir, modificar y deletear cualquier perfil, así como también modificar las opciones de configuración de RACF establecidas en la SETROPTS, con la siguiente importante excepción: El atributo SPECIAL no permite listar ni modificar opciones relativas a auditoría (que quedan, por lo tanto, reservadas a los usuarios con atributo AUDITOR). Más específicamente, un usuario con atributo SPECIAL (y sin atributo AUDITOR) no podrá listar ni modificar:

o Parámetros SAUDIT, CMDVIOL, OPERAUDIT, AUDIT CLASSES, LOGOPTIONS, SECLABELAUDIT, SECLEVELAUDIT, APPLAUDIT de la SETROPTS.

o Atributo UAUDIT en perfiles de usuario.

o Campo GLOBALAUDIT en perfiles de dataset o de recursos generales.

Solo un usuario con atributo SPECIAL a nivel de sistema puede dar o quitar este atributo a otro usuario. En una base de RACF recién inicializada, el usuario IBMUSER, provisto por IBM, tiene el atributo SPECIAL. Ingresando con este usuario, debe otorgarse el atributo SPECIAL a los administradores de RACF de la organización. A continuación, luego de verificar que los nuevos administradores pueden trabajar normalmente, resulta muy recomendable, desde el punto de vista de seguridad, quitarle al usuario IBMUSER el atributo SPECIAL y darle los atributos REVOKE, RESTRICTED y PROTECTED (no es posible eliminarlo). En efecto, como el usuario IBMUSER existe en toda base de RACF, es un blanco ideal de hackeo, razón por la cual mantenerlo inutilizable es lo más aconsejable.

El atributo SPECIAL no brinda acceso alguno a los recursos del sistema protegidos por RACF (con 2 excepciones particulares, que son el acceso a “datasets no catalogados” y “datasets no protegidos”). Sin embargo, el usuario con atributo SPECIAL tiene la posibilidad de otorgarse a sí mismo el acceso a cualquier perfil de la base con el máximo nivel de autoridad. Por lo tanto, indirectamente, tiene acceso irrestricto a los recursos protegidos del sistema.

Debido al enorme poder que confiere el atributo SPECIAL a nivel de sistema, solo un muy reducido conjunto de usuarios -encargados de la administración centralizada de RACF- deben tenerlo. No es sencillo recomendar una cantidad óptima, ya que ello depende de la complejidad de la base (la cantidad total de usuarios es solo uno de los aspectos a considerar) y de la organización. Sin embargo, podemos señalar que, siempre que ello no comprometa la eficiencia de la administración, cuantos menos usuarios con atributo SPECIAL existan, mejor. Normalmente, deberían sobrar los dedos de las manos para contar la cantidad de usuarios con atributo SPECIAL a nivel de sistema. Es por cierto recomendable, para su uso en una situación de emergencia, conservar bajo sobre y en lugar seguro un usuario con este atributo.

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), 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). Pueden, asimismo, modificar las opciones de logging para usuarios, perfiles de dataset, perfiles de recursos generales y las opciones de auditoría globales establecidas en la SETROPTS. Fuera de las opciones relativas a auditoría, el atributo AUDITOR no confiere autoridad para modificar ningún dato en la base de RACF. Tampoco otorga acceso a ningún recurso protegido.

El utilitario DSMON brinda importante información para auditar el sistema. Sólo los usuarios con atributo AUDITOR pueden utilizarlo (salvo que el programa ICHDSM00, invocado por la herramienta, se encuentre protegido en la clase PROGRAM, en cuyo caso es necesario tener acceso al mismo).

El atributo AUDITOR debe ser otorgado criteriosamente, y únicamente a los usuarios que desempeñen tareas globales de auditoría. Resulta aconsejable que los usuarios con atributo SPECIAL no tengan el atributo AUDITOR, de modo de no concentrar excesivo poder en una única persona.

29


El atributo AUDITOR a nivel de sistema solo puede ser otorgado o quitado por un usuario con atributo SPECIAL a nivel de sistema. Por lo tanto, con respecto a la observación anterior, si se pretende una buena separación de funciones en la organización, debe controlarse que los usuarios administradores de RACF que tienen el atributo SPECIAL no se otorguen a sí mismos el atributo AUDITOR. Para ello, basta con analizar el logging de los comandos de RACF ejecutados, que se obtiene de los registros tipo 80 del SMF.

Atributo OPERATIONS

Este atributo, a diferencia de los anteriores, otorga al usuario acceso a gran cantidad de recursos protegidos por RACF. En efecto, un usuario con atributo OPERATIONS a nivel de sistema tiene acceso ALTER -el máximo posible- a todos los perfiles en las clases DATASET, DASDVOL, GDASDVOL, TAPEVOL, PSFMPL, VMBATCH, VMCMD, VMMDISK, VMNODE, VMRDR (las últimas cinco totalmente irrelevantes para z/OS, ya que se relacionan con VM), con las siguientes importantes salvedades:

1) Si el usuario figura explícitamente en la lista de acceso del perfil con un nivel de autoridad menor, entonces ése será su nivel de acceso. En efecto, a la hora de determinar el nivel de acceso de un usuario sobre un perfil, la presencia del identificador del usuario en la lista de acceso es mandatoria y toma preeminencia por sobre los eventuales grupos a los que está conectado o el nivel de autoridad implícito dado por el atributo OPERATIONS. 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.

2) Si el usuario no está en la lista de acceso del perfil, 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, lo cual es la configuración habitual hoy en día), entonces su nivel de autoridad será el más permisivo dado por sus grupos.

Ejemplo:

Supongamos que el usuario FIN5214 tiene el atributo OPERATIONS a nivel de sistema, que está conectado únicamente a los grupos FINANZAS y CONTA, y que existe en la base un perfil de dataset CUIL.** con la siguiente lista de acceso FINANZAS UPDATE CONTA READ COBROS ALTER

En este caso, el nivel de autoridad del usuario FIN5214 sobre el perfil CUIL.** será UPDATE, es decir el más permisivo dado por sus grupos (ya que no figura explícitamente FIN5214 en la lista de acceso). El atributo OPERATIONS no entra en juego ya que existen en la lista de acceso del perfil grupos a los cuales el usuario está conectado.

3) Security levels, categories y security labels también pueden limitar el acceso implícito a un perfil dado por el atributo OPERATIONS. Sin embargo, ya mencionamos que son opciones poco utilizadas que no analizaremos.

En virtud de las salvedades expuestas concluimos que, para un usuario con el atributo OPERATIONS, la presencia de su identificador de usuario o de alguno de sus grupos en la lista de acceso de un perfil (de una clase dónde actúe el atributo OPERATIONS) solo sirve para eventualmente reducir su nivel de autoridad.

El atributo OPERATIONS a nivel de sistema solo puede ser otorgado o quitado por un usuario con atributo SPECIAL a nivel de sistema. Se trata de un atributo que brinda gran poder de acceso, razón por la cual debe ser otorgado con suma cautela, y en contadísimos casos. Más aún, es perfectamente posible (e incluso recomendable) no tener usuarios con atributo OPERATIONS a nivel de sistema. Por ejemplo, para los usuarios de administración de storage, existen mecanismos alternativos al atributo OPERATIONS para brindarles acceso a los recursos que requieren sus funciones. En cualquier caso,

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.

Atributo CLAUTH

Este atributo, que significa Class Authority, se otorga para una (o varias) clases de RACF, y solo es aplicable a nivel de sistema. Las clases para las cuáles es válido son la clase USER o cualquier otra clase definida en la CDT (GROUP y DATASET quedan pues excluidas).

Básicamente, 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), teniendo en cuenta las siguientes salvedades:

1) La opción GENERICOWNER de la SETROPTS, que veremos en el capítulo correspondiente, puede limitar la posibilidad de crear perfiles en una clase dada por el atributo CLAUTH.

2) Tener únicamente CLAUTH en la clase USER no autoriza a dar de alta un nuevo usuario en la base de RACF. Adicionalmente, se debe ser el owner del grupo default del usuario a definir, o bien estar conectado al mismo con nivel de autoridad JOIN.

El atributo CLAUTH sobre una clase brinda una bastante limitada capacidad de administración sobre sus perfiles. En efecto, si bien permite definir nuevos perfiles, no permite modificar, borrar, o listar perfiles ya existentes (siempre y cuando estas acciones no estén posibilitadas por algún otro tipo de autoridad). Si el usuario con el atributo CLAUTH define un nuevo perfil sin especificar owner, queda por defecto como dueño del perfil y por lo tanto con poder de administración casi total sobre el mismo. En cambio, si especifica un owner distinto de su usuario, ya no podrá actuar sobre él una vez creado.

CLAUTH resulta, de todos modos, útil como herramienta de descentralización de ciertas tareas de administración de RACF, y es bastante utilizado en muchas organizaciones. Para estar autorizado a otorgarlo sobre una determinada clase, debe cumplirse alguna de las siguientes condiciones:


� Tener CLAUTH sobre esa clase, y además estar autorizado a modificar el perfil del usuario (por ejemplo, siendo su owner).

Atributo REVOKE

El atributo REVOKE a nivel de sistema impide al usuario el logon a cualquier aplicación (TSO, CICS, IMS, etc.), así como también la ejecución de trabajos batch. Únicamente las Started Task pueden arrancar con un usuario revocado, aunque es posible que experimenten inconvenientes posteriores, dependiendo de lo que hagan.

El atributo REVOKE, a diferencia de los anteriores, no solo puede ser otorgado por un usuario con la suficiente autoridad (atributo SPECIAL u owner del usuario), sino que 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”, entonces al (N+1) intento consecutivo de password inválida el usuario es revocado. Naturalmente, un ingreso válido vuelve la cuenta a 0.

2) Si en la SETROPTS está especificado que “el usuario será automáticamente revocado después de N días de inactividad”, y transcurrieron al menos (N+1) días desde su último ingreso al sistema, el usuario será revocado por RACF en el momento del intento de logon. Cabe aclarar que, aunque se haya excedido el tiempo de inactividad estipulado, hasta tanto el usuario no intente loguearse al sistema no adquirirá el atributo REVOKE, ya que RACF lo otorga al procesar la solicitud de logon.

Con respecto a las situaciones recién descriptas, merecen una consideración particular los usuarios con atributo SPECIAL a nivel de sistema. En efecto, RACF no los revoca automáticamente, sino que emite un mensaje por consola solicitando al operador, o bien que confirme la revocación, o bien que otorgue

31


un intento adicional de ingreso de password u omita la inactividad, según sea el caso. Sin este tratamiento diferenciado, 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, generando una situación delicada de la cual no es sencillo recuperarse.

Atributo GRPACC

El atributo GRPACC (Group Access) a nivel de sistema funciona del siguiente modo: Si un usuario con GRPACC se encuentra conectado a un grupo A y define un perfil de dataset cuyo HLQ es A (suponiendo que tenga autoridad suficiente para hacerlo), automáticamente se agregará en la lista de acceso al grupo A con autoridad UPDATE. Se trata de un atributo poco utilizado, y para otorgarlo o quitarlo es necesario tener el atributo SPECIAL, o bien ser el owner del perfil del usuario.

Atributo ADSP

ADSP significa Automatic Data Set Protection. Si un usuario tiene este atributo a nivel de sistema, cada vez que cree un dataset permanente en disco (o en cartucho, si la clase TAPEVOL está activa y la opción TAPEDSN está especificada en la SETROPTS), RACF automáticamente le definirá un perfil discreto de dataset.

Siendo la tendencia actual la de utilizar solo perfiles de dataset genéricos, pues son más sencillos de administrar y presentan varias ventajas sobre los discretos, el atributo ADSP ha caído francamente en desuso. Existe la opción NOADSP a nivel de la SETROPTS que inhibe el eventual atributo ADSP que puedan tener los usuarios.

Para otorgar o quitar el atributo ADSP es necesario, o bien tener el atributo SPECIAL, o bien ser el owner del perfil del usuario. Para setear ADSP|NOADSP a nivel de la SETROPTS es necesario tener el atributo SPECIAL a nivel de sistema.

Atributo RESTRICTED

Este atributo es solo aplicable a nivel de sistema. Se trata de un atributo de carácter limitativo, que restringe casi completamente los recursos a los cuáles puede acceder el usuario. En efecto, un usuario con el atributo RESTRICTED no puede obtener acceso a un recurso protegido por RACF ni por una regla en la clase GLOBAL, ni por el UACC del perfil protector, ni por la presencia de “*” en las listas de acceso. Dicho de otro modo, un usuario con atributo RESTRICTED solo puede acceder a aquellos recursos para los cuales se encuentre explícitamente autorizado, ya sea porque su identificador de usuario, o alguno de los grupos a los que está conectado, figura en las listas de acceso del perfil con el nivel de autoridad requerido.

El atributo RESTRICTED es útil en situaciones dónde se requiere tener un absoluto control de los recursos a los que debe acceder el usuario. Antes de otorgarlo, es vital realizar un detallado relevamiento de todos los recursos a los que necesita acceder y con qué nivel de autoridad, de modo de no provocar una interrupción en las tareas operativas.

Para otorgar o quitar el atributo RESTRICTED a un usuario, es necesario, o bien tener el atributo SPECIAL, o bien ser el owner de su perfil.

Atributo PROTECTED

Un usuario con atributo PROTECTED (protegido) no puede loguearse a ninguna aplicación del sistema que requiera el uso de una password. Por ejemplo, no puede iniciar sesiones de TSO, CICS, NETVIEW, etc. Si alguien intenta loguearse con un usuario que tenga el atributo PROTECTED, RACF directamente rechaza el pedido de logon sin considerarlo ni siquiera un intento fallido por password inválida. Se trata de usuarios sin password que resultan inmunes a la revocación automática por ingresos consecutivos de passwords erróneas. Sin embargo, sí están sujetos a la eventual revocación automática por inactividad.

32


Básicamente, se trata de un atributo muy útil para aquellos usuarios asociados con started tasks que no necesiten loguearse a ninguna aplicación. Para estos usuarios, el atributo PROTECTED asegura no solo que no se puedan utilizar para ingresar a ninguna aplicación, sino que también elimina la posibilidad de que se los revoque (voluntaria o involuntariamente) por ingresos consecutivos de passwords inválidas. Los usuarios de las regiones CICS, por ejemplo, son excelentes candidatos para este atributo.

Se otorga a un usuario el atributo PROTECTED, ya sea en el momento de su creación (comando ADDUSER) o con posterioridad (comando ALTUSER), especificando el operando NOPASSWORD.

Ejemplo: ALTUSER userid NOPASSWORD

Cuando un usuario tiene este atributo, los campos PASSDATE y PASS-INTERVAL de la salida del comando LISTUSER muestran el valor N/A.

Para quitar el atributo PROTECTED, basta con darle al usuario una password, ejecutando el comando:

ALTUSER userid PASSWORD(password)

Para otorgar el atributo PROTECTED, se debe cumplir alguna de las siguientes condiciones:




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, LISTGROUP, LISTDSD, RLIST y SEARCH, que nunca se registran dada su baja criticidad).

� Intente acceder a un recurso protegido, resulte el acceso fallido o exitoso (independientemente de la configuración de auditoría que tenga el perfil protector del recurso), excepto en el caso en que el acceso haya sido autorizado por una regla en la clase GLOBAL.

� Defina algún nuevo recurso cuya creación esté controlada por RACF (la alocación de un nuevo dataset, por ejemplo).

Para poder otorgar o quitar el atributo UAUDIT, se debe tener el atributo AUDITOR a nivel de sistema, o bien a nivel de un grupo que tenga al usuario dentro de su campo de acción. El atributo SPECIAL, incluso a nivel de sistema, no permite listar -y mucho menos dar o quitar- este atributo.

No se debe abusar del atributo UAUDIT ya que puede provocar un aumento muy considerable de la cantidad de registros SMF grabados por RACF, con los consiguientes problemas de tipo operativo que ello acarrea. Es conveniente otorgarlo solo cuando se requiera un monitoreo estricto de la actividad de un determinado usuario, y por un período limitado de tiempo.

Atributos a nivel de grupo

Los atributos que se pueden otorgar a nivel de grupo son los siguientes:

o SPECIAL

o AUDITOR

o OPERATIONS

o REVOKE

o GRPACC

o ADSP

33


Se otorgan a través de comando CONNECT, que se verá en detalle más adelante.

Ejemplos:

1) CO fina857 GROUP(finanzas) AUDITOR

Este comando conecta al usuario FINA857 al grupo FINANZAS con atributo AUDITOR a nivel de grupo. Si el usuario FINA857 ya se encontrara conectado al grupo FINANZAS, solo modifica la conexión agregando el atributo AUDITOR.

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, sería irrelevante). En tal caso, 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.

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), el cual ya ha sido mencionado repetidas veces pero aún no explicado.

Campo de acción de un grupo

El campo de acción de un grupo está compuesto por una serie de grupos, perfiles de usuario, perfiles de dataset y perfiles de recursos generales, de acuerdo al siguiente criterio:

Aparte del grupo en cuestión, se encuentran dentro de su campo de acción todos sus subgrupos, los subgrupos de sus subgrupos, y así sucesivamente, siempre y cuándo se cumpla que el owner de un grupo sea su grupo superior. Si el owner de un grupo dentro de la rama del inicial es un usuario (en lugar de su grupo superior), este grupo (y todos los que se desprendan de él en el árbol) queda fuera del campo de acción. Es decir, si se cumple que cada grupo tenga como owner su grupo superior, 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.

Ejemplo:

En el diagrama anterior, la flecha significa “tiene como subgrupo a”. Por lo tanto, se tiene que:

o GRUPO1 tiene 2 subgrupos: GRUPO2 y GRUPO3.

o GRUPO2 tiene un único subgrupo: GRUPO4.

o GRUPO3 tiene 2 subgrupos: GRUPO5 y GRUPO6.

o GRUPO4, GRUPO5 y GRUPO6 no tienen subgrupos.

Los grupos que forman parte del campo de acción del GRUPO1 son:

GRUPO1, GRUPO2, GRUPO3, GRUPO4 y GRUPO5.

GRUPO1 Owner: GRUPOA

GRUPO2 Owner: GRUPO1



GRUPO6 Owner: USU1


34


GRUPO6 no forma parte del campo de acción de GRUPO1 ya que el owner no es su grupo superior, sino el usuario USU1.

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. No están dentro del campo de acción aquellos usuarios cuyo owner sea otro usuario. 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 otras palabras, 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 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.

� Su owner es un usuario dentro del campo de acción.

� Su HLQ es un usuario o grupo dentro del campo de acción.

En lo referido a perfiles de recursos generales, 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.

� Su owner es un usuario dentro del campo de acción.

Por ejemplo, volviendo al caso del diagrama, perfiles de recursos generales cuyo owner es GRUPO5 están dentro del campo de acción de GRUPO1, mientras que aquellos cuyo owner es GRUPO6 no lo están. Asimismo, si USU2 es un usuario cuyo owner es GRUPO2 y USU22 es un usuario cuyo owner es USU2, entonces USU2 está dentro del campo de acción de GRUPO1, mientras que USU22 no. En consecuencia, todo perfil de recursos generales cuyo owner sea USU2 está dentro del campo de acción de GRUPO1, mientras que aquellos cuyo owner sea USU22 están afuera.

Atributo SPECIAL a nivel de grupo

Básicamente, 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. 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.

En cuanto a la definición de nuevos perfiles, se tiene que:

o Puede definir nuevos perfiles de dataset cuyo HLQ sea un grupo o un usuario dentro de su campo de acción.

o Para crear nuevos perfiles de recursos generales debe tener CLAUTH sobre la clase correspondiente.

o Para crear nuevos usuarios debe tener CLAUTH en la clase USER.

Limitaciones:

o Un usuario con atributo SPECIAL a nivel de grupo no puede modificar opciones que afecten globalmente al sistema. Por lo tanto, no tiene autoridad suficiente para modificar la configuración global de RACF establecida en la SETROPTS.

o No puede otorgar los atributos SPECIAL, AUDITOR ni OPERATIONS a "nivel de sistema" (aunque si puede otorgarlos a nivel de grupo, para grupos que se encuentren dentro del campo de acción). Para otorgar CLAUTH sobre una clase debe tener él mismo CLAUTH sobre esa misma clase.

o Aún dentro del campo de acción del grupo, 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".

35


Atributo AUDITOR a nivel de grupo

Un usuario con atributo AUDITOR a nivel de grupo tiene las mismas autoridades que uno con atributo AUDITOR a nivel de sistema, pero restringida a los recursos (grupos, usuarios, perfiles de dataset y de recursos generales) que se encuentran dentro de su campo de acción. No está habilitado a modificar opciones globales de auditoría, aunque si está autorizado a listar la información completa de la SETROPTS.

Atributo OPERATIONS a nivel de grupo

Un usuario con atributo OPERATIONS a nivel de grupo tiene las mismas autoridades que uno con atributo OPERATIONS a nivel de sistema, pero restringida a los recursos (perfiles de dataset y de recursos generales) que están dentro de su campo de acción.

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. En definitiva, estar conectado a un grupo con la conexión revocada es similar, desde el punto de vista de seguridad, a no pertenecer al mismo.

Con respecto al uso del REVOKE con fecha, ya se analizó previamente cómo funciona a "nivel de usuario", siendo el comportamiento a nivel de grupo análogo.

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. Su funcionamiento es entonces igual al del atributo GRPACC a nivel de sistema (afectará a todos los “perfiles de dataset de grupo” que defina el usuario, siempre y cuando esté conectado al grupo dado por el HLQ, aún cuando éste no se encuentre dentro del campo de acción del grupo sobre el que tiene efectivamente el atributo GRPACC).

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 tal caso, funciona igual que el atributo ADSP a nivel de sistema. Se trata, como ya hemos observado, de un atributo muy poco utilizado.

3.14 - Conexión de un usuario a un grupo

Un usuario queda conectado automáticamente a su grupo default al ser dado de alta. Para conectarlo a otro grupo, o bien para modificar características de una conexión ya existente, debe usarse el comando CONNECT, en tanto que para desconectarlo debe emplearse el comando REMOVE. A continuación, analizaremos en detalle ambos comandos.

Comando CONNECT

Sintaxis:

CONNECT|CO userid [GROUP(nombre)] [OWNER(usuario/grupo)] [AUTHORITY(nivel)] [REVOKE(mm/dd/aa)] [RESUME(mm/dd/aa)] [ADSP|NOADSP] [AUDITOR|NOAUDITOR] [GRPACC|NOGRPACC] [OPERATIONS|NOOPERATIONS] [SPECIAL|NOSPECIAL] UACC(nivel)

Como ya señalamos, 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). Si la conexión ya existe, el comando solo modifica los parámetros especificados (no se aplica ningún valor por defecto).

El userid es requerido y debe estar inmediatamente a continuación del comando CONNECT.

36


Si no se codifica GROUP, 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). Debe tenerse cuidado con esto, ya que muchas veces no es el efecto buscado, sino que simplemente se omite el grupo por distracción.

El OWNER de la conexión es totalmente irrelevante. Su valor por defecto es el identificador del usuario que ejecuta el comando CONNECT.

AUTHORITY indica el nivel de autoridad del usuario como miembro del grupo, que analizaremos en detalle más adelante en este mismo capítulo. USE es el valor por defecto.

Por defecto, no se le asigna al usuario ningún atributo a nivel del grupo.

UACC asume por defecto el valor NONE.

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, el usuario que ejecuta el comando debe cumplir alguna de las condiciones siguientes:


� Tener el atributo SPECIAL a nivel de grupo, y el grupo al cual se pretende conectar al usuario encontrarse dentro de su campo de acción.


� Estar conectado al grupo con nivel de autoridad CONNECT o JOIN. En caso de tener nivel de autoridad CONNECT, no puede conectar al usuario con nivel de autoridad JOIN (suponiendo que no detente otro tipo de atributo que se lo permita, como SPECIAL a nivel de sistema).

Para otorgar o quitar los atributos SPECIAL, AUDITOR u OPERATIONS a “nivel del grupo”, el usuario que ejecuta el comando debe tener el atributo SPECIAL, ya sea a nivel de sistema, o a nivel de un grupo que tenga al grupo en cuestión dentro de su campo de acción.

Comando REMOVE

Sintaxis:

REMOVE|RE userid [GROUP(nombre)] [OWNER(usuario/grupo)]

Este comando desconecta un usuario de un grupo. No permite modificar parámetros de la conexión (esto debe hacerse con el comando CONNECT).

El userid es requerido y debe estar inmediatamente a continuación del comando REMOVE.

GROUP indica el nombre del grupo del cual se desea desconectar al usuario. Si se omite, asume por defecto el nombre del “actual grupo de conexión” de quien ejecuta el comando REMOVE.

Con respecto al operando OWNER, funciona del siguiente modo: supongamos que se pretende desconectar al usuario A del grupo B.

� Si A es owner de perfiles de dataset cuyo HLQ es B, RACF no permite la desconexión, 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. Si se pone un usuario como OWNER, debe estar conectado al grupo.

� Si A no es owner de ningún perfil de dataset cuyo HLQ es B, entonces el operando OWNER es irrelevante y puede omitirse.

Observación:

No se puede desconectar a un usuario de su grupo default. Por lo tanto, suponiendo que el usuario USUA está conectado únicamente al grupo GRPB (que por lo tanto es su grupo default) y que se

37


pretende que USUA quede conectado únicamente al grupo GRPC, debería ejecutarse una secuencia de comandos similar a la siguiente:

1. CONNECT USUA GROUP(GRPC) conecta USUA a GRPC

2. ALTUSER USUA DFLTGRP(GRPC) cambia el grupo default de USUA por GRPC

3. REMOVE USUA GROUP(GRPB) 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). Sólo restan por analizar los posibles niveles de autoridad de un usuario dentro de un grupo.

Autoridad requerida

Para desconectar un usuario de un grupo, el usuario que ejecuta el comando debe cumplir alguna de las condiciones siguientes:


� Tener el atributo SPECIAL a nivel de grupo, y el grupo del cual se pretende desconectar al usuario encontrarse dentro de su campo de acción.


� Estar conectado al grupo con nivel de autoridad CONNECT o JOIN.

Niveles de autoridad de un usuario en un grupo

Los posibles niveles son:

1. USE

2. CREATE

3. CONNECT

4. JOIN

Se enumeraron de modo que cada nivel de autoridad incluye (y excede) los privilegios del anterior.

Nivel USE

Un usuario conectado a un grupo con nivel de autoridad USE está habilitado a:

o Ingresar al sistema especificando ese grupo como “grupo de conexión”.

o Acceder a recursos protegidos a los cuáles el grupo se encuentre autorizado.

Se trata del nivel de autoridad suficiente para la casi totalidad de los casos.

Nivel CREATE

Adicionalmente, el nivel de autoridad CREATE permite:

o Alocar nuevos datasets cuyo HLQ sea el grupo.

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

Sin embargo, salvo que se encuentre autorizado por otro motivo, el nivel de autoridad CREATE no permite deletear datasets cuyo HLQ sea el grupo en cuestión.

Nivel CONNECT

Adicionalmente, el nivel de autoridad CONNECT permite:

o Conectar al grupo usuarios ya existentes en la base de RACF, otorgándoles nivel de autoridad USE, CREATE o CONNECT.

38


o Modificar parámetros de la conexión al grupo de usuarios ya conectados.

o Desconectar usuarios del grupo con el comando REMOVE.

o Listar la información del grupo con el comando LISTGRP.

En el caso de ejecutar el comando CONNECT al grupo, puede especificar cualquier operando, con excepción de SPECIAL|NOSPECIAL, AUDITOR|NOAUDITOR y OPERATIONS|NOOPERATIONS.

Nivel JOIN

Adicionalmente, el nivel de autoridad JOIN permite:

o Si tiene el atributo CLAUTH(USER), definir nuevos usuarios dentro del grupo, con nivel de autoridad USE, CREATE, CONNECT o JOIN.

o Conectar al grupo usuarios ya existentes en la base de RACF, con nivel de autoridad JOIN.

o Crear nuevos grupos de RACF que sean subgrupos del grupo en cuestión.

o Borrar subgrupos del grupo con el comando DELGROUP.

39


4 - PROTECCIÓN DE DATASETS


Los datasets son, por excelencia, el tipo de recurso que permite proteger RACF. Más aún, en sus primeras versiones, que datan de la década del 70, los archivos eran los únicos recursos sobre los cuáles RACF controlaba el acceso. Con el correr del tiempo y la aparición de nuevas versiones, tanto RACF como los distintos componentes del sistema operativo (y productos) fueron evolucionando, de modo que hoy en día RACF permite proteger una enorme variedad de recursos aparte de los datasets.

Conceptualmente, es de suma importancia distinguir un “dataset” de un “perfil de dataset”.

� Un dataset es simplemente un archivo, cuya existencia es absolutamente independiente de RACF. Utilizaremos indistintamente los términos dataset y archivo.

� Un “perfil de dataset” es una entidad que existe en la base de RACF y se crea, modifica y elimina a través del uso de comandos de RACF. La clase de RACF que los agrupa es la clase DATASET.

Ambos se vinculan del siguiente modo: los perfiles de dataset contienen información que emplea RACF para responder los requerimientos que reciba de acceso a archivos. Dicho más sencillamente, los perfiles de dataset son una suerte de reglas que protegen el acceso a datasets.

Datasets

En el entorno z/OS, los archivos pueden residir en disco o en cartucho, y vienen identificados por un nombre cuya longitud máxima es de 44 caracteres. La cadena de caracteres que lo conforma se divide en calificadores, de longitud mínima 1 y máxima 8, separados entre sí por un punto (.) (los puntos forman parte del nombre, o sea que cuentan con respecto al máximo de 44).

El primer carácter de cada calificador debe ser alfabético (A hasta Z) o nacional (#, @, $). Los restantes pueden ser alfabéticos, numéricos (0 a 9), nacionales o un guión (-). No se distinguen mayúsculas de minúsculas.

No existe un límite para la cantidad de calificadores que pueda tener un dataset, más allá del que surge obviamente de la longitud máxima permitida en el nombre. El primer calificador se abrevia HLQ (High

level Qualifier).

Ejemplos:

PROD1.FINANZAS.A2009 Nombre válido, con 3 calificadores. PROD1 es el HLQ. BASEPERS Nombre válido, de un único calificador. TEST1.2010 Nombre inválido, pues el segundo calificador empieza con

un número, lo que no está permitido.

Perfiles de Dataset

Los perfiles de dataset se dividen en 2 tipos:

• Discretos

• Genéricos.

Más adelante analizaremos en detalle las diferencias entre unos y otros. Por el momento digamos que, en sus primeras versiones, los únicos perfiles de dataset que admitía RACF eran los discretos, que protegen un único archivo. Con posterioridad, surgieron los perfiles de dataset genéricos, que resultaron más prácticos y fáciles de administrar. A diferencia de los discretos, dónde debía existir un perfil por cada dataset protegido, un único perfil genérico permite proteger una cantidad ilimitada de archivos de nombres similares. La tendencia actual es a utilizar casi exclusivamente perfiles de dataset genéricos, aunque para ciertas situaciones muy particulares los perfiles discretos continúan siendo una mejor opción.

40


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

o Deben tener 2 o más calificadores.

o El HLQ debe coincidir con un usuario o grupo existente en la base de RACF. Los denominaremos “perfil de dataset de usuario” o “perfil de dataset de grupo”, según sea el caso.

o Con excepción del HLQ, pueden utilizarse en los siguientes calificadores los caracteres comodín: %, *, **. El doble asterisco solo puede usarse si la opción EGN (Enhanced Generic

Naming) está activa en la SETROPTS. Estos 3 símbolos también se denominan caracteres genéricos o variables.

En todo lo que sigue, vamos a asumir que la clase DATASET está seteada como GENERIC y GENCMD, y que la opción EGN -que habilita el uso del ** en los perfiles de dataset- está activa, lo cual es lo habitual en todas las organizaciones. Estas opciones se establecen en la SETROPTS y se analizarán en detalle en el capítulo correspondiente. Por otro lado, salvo que aclaremos lo contrario, supondremos que todos los archivos residen en disco (también llamados DASD, sigla de Direct Access

Storage Device).

4.2 - Perfiles discretos

Un perfil discreto de dataset debe tener idéntico nombre que el archivo que pretende proteger. Por lo tanto, los caracteres %, * y ** no están permitidos.

Los perfiles discretos de dataset guardan una íntima relación con el archivo que protegen. Por ejemplo, solo es posible definir un perfil discreto de dataset si realmente existe un archivo con ese nombre en el volumen indicado. Más aún, al proteger un archivo discretamente, ya sea en la VTOC del disco para los NOVSAM, o en la entrada del catálogo para los VSAM, un bit se activa indicando que el archivo está protegido por un perfil discreto. Se dice en tal caso que el archivo está RACF-indicado.

Si se deletea un archivo protegido por un perfil discreto, automáticamente se borra de la base de RACF el perfil de dataset correspondiente.

4.3 - Perfiles genéricos

Los perfiles genéricos, ampliamente más usados que los discretos, pueden o no tener en sus nombres los caracteres %, * y **. Cuándo no tienen ningún carácter genérico, se los conoce como “perfiles genéricos completos” y solo protegen al archivo de idéntico nombre, si existiera (lo cual no es requisito para que se pueda definir el perfil, como en el caso de los discretos). Si, en cambio, tienen alguno de los caracteres comodín, entonces “cubren” una gran cantidad de eventuales datasets, en virtud del significado que posee cada uno de los caracteres genéricos, que detallamos a continuación. Como ya señaláramos, suponemos la opción EGN activa en la SETROPTS. En caso contrario, el ** no es válido en perfiles de dataset y el * cambia ligeramente su significado.

Signo porcentual (%)

Variable que indica un único carácter cualquiera en esa posición (con excepción del “.”) Ejemplo: TEST.FINAN.A200%

Asterisco (*)

Para esta variable, caben distintas posibilidades:

� Si forma parte de un calificador que contiene otros caracteres, debe ser el carácter final. En tal caso indica que en esa posición puede haber 0 o más caracteres hasta completar el calificador. Ejemplo: TEST.FIN*

41


� Si constituye un calificador completo, indica que en esa posición puede existir cualquier calificador pero que debe necesariamente existir uno. Ejemplo: TEST.*.A2002

Doble asterisco (**)

Esta variable debe usarse como un calificador entero, y no puede utilizarse más de una vez por perfil. Indica la presencia de 0 o más calificadores en esa posición. Ejemplo: TEST.**.A2002

Recordemos que el HLQ de todo perfil de dataset debe ser un usuario o grupo definido en la base de RACF. Por lo tanto, no está permitido el uso de caracteres genéricos en el primer calificador.

4.4 - 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.

Ejemplo:

Perfiles:

1. TEST.FINANZAS.A2002 discreto

2. TEST.FINANZAS.A2002 genérico completo

3. TEST.FINANZAS.**

4. TEST.FINAN%%%.* 5. TEST.FINAN*.*

6. TEST.*.A*

7. TEST.FINANZAS.A%

8. TEST.*.A2002.*

Los 6 primeros perfiles cubren al archivo TEST.FINANZAS.A2002, 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, mientras que el * final en el 8 exige la existencia de un cuarto calificador).

Por lo tanto, como muestra el ejemplo, muchos perfiles de dataset pueden cubrir al mismo archivo. Sin embargo, a la hora de determinar la protección, RACF se guía por el principio del perfil más específico. Esto significa que, dado un archivo, o bien RACF no lo encuentra protegido, o bien determina un único perfil que lo protege (que puede resultar discreto o genérico), que llamamos “perfil protector”.

Para determinar el perfil protector, RACF procede del siguiente modo:

Si existe un perfil discreto para el archivo, entonces éste será su perfil protector.

Si no existe un perfil discreto, RACF busca todos los perfiles genéricos que lo cubren (si no existiera ninguno, simplemente el archivo no estaría protegido), y procede a compararlos, de izquierda a derecha. En el primer carácter en que encuentre alguna diferencia, se descartan aquellos más genéricos, de acuerdo al siguiente criterio:

- Los caracteres “no genéricos” son más específicos que las variables.

- Para las variables, el orden, desde el menos al más genérico, es %, * y **.

Siguiendo este procedimiento, RACF siempre determina, a lo sumo, un único perfil protector para un dataset. Si volvemos al ejemplo anterior, notamos que los perfiles del 1 al 6 están ordenados del más al menos específico. En este caso, el perfil discreto actúa como perfil protector del archivo TEST.FINANZAS.A2002

Un perfil discreto se distingue de un genérico completo de igual nombre por no presentar, cuando se lo lista, el símbolo (G) característico de los perfiles genéricos (ver 4.10).

42


Si el dataset no tiene un perfil discreto, el comando:

LISTDSD DATASET(‘nombre-del-archivo’) GENERIC ALL

lista el perfil protector del dataset codificado en el operando DATASET (o sea, el genérico más específico que lo cubre). Mas adelante analizaremos el comando LISTDSD en detalle.

Consideraciones importantes:

� RACF no brinda la posibilidad de proteger datasets particionados a nivel de miembros (members). Solo se puede proteger una biblioteca de manera global, a través de un único perfil de dataset. Por lo tanto, si un miembro particular requiriera un tratamiento diferenciado en cuanto a su seguridad, se lo debería aislar en otra biblioteca y protegerla de manera adecuada.

� En el caso de archivos VSAM, solo es necesario proteger el nombre del cluster. Los nombres de los restantes componentes del VSAM (data e index) no intervienen en el momento de resolver sobre una solicitud de acceso.

4.5 - Niveles de autoridad para perfiles de dataset

Tanto en el UACC, como en las listas de acceso, existen distintos niveles de autoridad que se pueden especificar para perfiles de dataset. Estos son los siguientes:

o NONE

o EXECUTE

o READ

o UPDATE

o CONTROL

o ALTER

Se enumeraron desde el más restrictivo al más permisivo. Cada nivel incluye y excede los privilegios del anterior. Su significado se muestra en la tabla siguiente:

NONE No permite acceder al dataset.

EXECUTE Se utiliza exclusivamente para bibliotecas de módulos. Este nivel de autoridad permite ejecutar programas de la librería, pero no autoriza a copiarlos. Su implementación suele ser problemática. Aconsejamos usar READ en lugar de EXECUTE.

READ Permite acceder al dataset únicamente para lectura. Cabe señalar que READ es suficiente para copiar o imprimir el archivo.

UPDATE Permite tanto leer como modificar el dataset. No autoriza, sin embargo, a deletearlo, renombrarlo o moverlo. Sobre archivos VSAM, permite las operaciones normales de I/O.

CONTROL Para archivos NOVSAM, es equivalente a UPDATE. Sobre archivos VSAM, permite un nivel de acceso más amplio que UPDATE (improved

control interval processing).

ALTER Permite leer, modificar, renombrar, mover y deletear el dataset. Sobre perfiles discretos, otorga además la posibilidad de administrar el perfil, modificando casi cualquier campo -incluida la lista de acceso. También permite borrar el perfil de la base. Sobre perfiles genéricos no otorga ningún privilegio administrativo. Autoriza asimismo a alocar nuevos datasets que queden protegidos por este perfil.

43


4.6 - Administración de perfiles de dataset

Ya señalamos anteriormente las restricciones que existen con respecto al nombre de estos perfiles. Analizaremos ahora en detalle los comandos necesarios para su administración. A diferencia de los perfiles de grupo y usuarios, los perfiles de dataset tienen listas de acceso (access lists). Existen 2 tipos:

Lista de acceso estándar

Es la que se utiliza en la enorme mayoría de los casos. Contiene un listado de grupos y usuarios, acompañados cada uno de un determinado nivel de autoridad. Puede eventualmente también figurar una entrada *.

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, naturalmente). Por ejemplo, puede autorizarse a un usuario a acceder a un archivo únicamente cuando se encuentre logueado en una determinada terminal o consola. No analizaremos en detalle todas las condiciones manejables a nivel de la lista de acceso condicional, ya que ello escapa al objetivo de este texto introductorio. De todos modos, para los requerimientos usuales de seguridad, la lista de acceso estándar suele ser suficiente.

4.7 - 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. Si contiene caracteres genéricos (%, *, o **), entonces el perfil creado resulta genérico, aún cuando se omita el operando GENERIC. Si el nombre no contiene estos caracteres, entonces se creará un perfil discreto, a menos que se codifique explícitamente el operando GENERIC, en cuyo caso resultará un “perfil genérico completo”.

La DATA del perfil es un campo de uso administrativo, de longitud máxima 255 caracteres.

El OWNER del perfil debe ser un usuario o grupo existente. Si es un “perfil de dataset de grupo” y se especifica un usuario como owner, debe necesariamente estar conectado al grupo. Si no se codifica OWNER, queda como tal el usuario que ejecutó el comando (salvo que el HLQ sea un usuario distinto, en cuyo caso éste queda como owner). Notemos que ser dueño de un perfil de dataset no otorga acceso a los eventuales archivos que proteja. Para poder acceder a ellos, debe agregarse al usuario en la lista de acceso a través del comando PERMIT.

El operando UACC es sumamente importante y establece el “nivel de acceso universal” (Universal

Access) del perfil. Puede tomar los valores NONE, EXECUTE, READ, UPDATE, CONTROL y ALTER, que ya se analizaron previamente. Básicamente, 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, por ejemplo). 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. Si no se especifica UACC, el valor por defecto es el UACC que tiene el usuario que ejecuta el comando en su “actual grupo de conexión” (que, como señaláramos anteriormente, conviene que sea NONE, por motivos de seguridad).

44


GENERIC debe obligatoriamente especificarse si se pretende definir un “perfil genérico completo”. Si el nombre del perfil contiene algún carácter genérico, no es necesario codificar GENERIC (aunque puede hacerse).

MODEL indica que se va a definir un perfil discreto que luego será utilizado como modelo para la definición de futuros perfiles de dataset. Si en el nombre del perfil figura algún carácter genérico, el operando MODEL es ignorado. Si no existen en el nombre tales caracteres, los operando GENERIC y MODEL son incompatibles, siendo el último codificado el que prevalece. Cuando se especifica MODEL, no es necesario que exista realmente un archivo cuyo nombre coincida con el del perfil (como sí es requisito para perfiles discretos comunes), y pueden omitirse los operandos UNIT y VOLUME. Volveremos sobre la creación de perfiles basados en un modelo en el capítulo dónde analicemos las opciones de la SETROPTS, ya que allí es dónde se establece que tipo de perfiles de dataset se pretende modelizar.

TAPE indica que se va a definir un perfil discreto que protege un archivo en cartucho (debe estar la opción TAPEDSN activa en la SETROPTS, ya que en caso contrario el comando falla). Si el nombre del perfil contiene algún carácter genérico, el operando TAPE es ignorado.

Cuando se define un perfil discreto, el operando NOSET|SET|SETONLY establece cómo se desea manejar el “bit indicador” del archivo:

El valor por defecto es SET, que activa el bit indicador dejando al archivo RACF-indicado.

NOSET establece que se cree un perfil discreto pero sin alterar el estado del bit indicador del archivo. En consecuencia, si el dataset ya estaba RACF-indicado, el operando NOSET lo deja en la misma condición (en este caso, el valor SET provocaría un error, ya que intentaría activar un bit que ya se encontraba activado). Es importante tener en cuenta que si el archivo no estaba RACF-indicado y se codifica NOSET, el perfil creado no lo protegerá.

SETONLY es una 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). En la presente guía no trataremos en detalle la protección de archivos en cartuchos.

Para cualquiera de las opciones -SET, NOSET y SETONLY-, si se especificó GENERIC, o bien el nombre-del-perfil contiene caracteres genéricos, el operando de seteo es ignorado.

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 perfil. Este operando prevalece sobre la eventual modelización de perfiles que pueda existir para el usuario o grupo dado por el HLQ. Todas las características del perfil especificado en el operando FROM son replicadas en el nuevo (OWNER, UACC, WARNING, AUDITING, NOTIFY, DATA, Listas de acceso, etc.), excepto que se codifique explícitamente un valor distinto para alguno de estos operandos en el comando ADDSD. Puede existir una mínima diferencia en la lista de acceso del nuevo perfil con respecto al tomado como modelo, en los casos siguientes:

- Si se crea un “perfil de dataset de grupo”, y quien lo hace tiene el atributo GRPACC y está conectado a él, entonces el grupo se agrega a la lista de acceso con autoridad UPDATE, independientemente de que figure o no en la lista de acceso del perfil modelo.

- Si la opción ADDCREATOR está activa en la SETROPTS, el usuario que crea el nuevo perfil se agrega a la lista de acceso con autoridad ALTER, independientemente de que figure o no en la lista de acceso del perfil modelo.

FCLASS indica la clase de RACF a la que pertenece el perfil especificado en el operando FROM (DATASET o cualquier clase definida en la CDT son admisibles). El valor por defecto es DATASET. RACF ignora el operando FCLASS si no se codificó FROM.

FGENERIC indica a RACF que el perfil especificado en el operando FROM es genérico, aún cuando no contenga caracteres genéricos. RACF ignora el operando FGENERIC si no se codificó FROM.

Si el operando FROM especifica un perfil discreto de DATASET, el operando FVOLUME debe indicar el volumen correspondiente del perfil modelo. Si se codifica FVOLUME con un valor distinto al que

45


corresponde, o si se omite y existe más de un perfil discreto con ese nombre, el comando falla. Si no se especificó el operando FROM, o se codificó con un perfil genérico, o con un perfil de una clase que no sea DATASET, el operando FVOLUME es ignorado.

Los operandos UNIT y VOLUME son requeridos únicamente en el caso de perfiles discretos que correspondan a archivos no-vsam y no catalogados. En tal caso, UNIT debe indicar el tipo de dispositivo dónde reside el archivo mientras que VOLUME especifica el volumen. Si el perfil es genérico, o se especificó el operando MODEL, UNIT y VOLUME son ignorados.

El operando WARNING establece que el perfil se define en modo warning. Esto significa que, si un usuario requiere acceso a un recurso protegido por el perfil, y RACF determina que no está autorizado, en lugar de denegar el acceso lo autoriza pero 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. En ciertas ocasiones, cuando aún no se logró determinar exactamente que usuarios deben acceder a los archivos protegidos por un perfil, puede resultar útil definirlo en modo warning, de modo a no provocar una interrupción en alguna tarea crítica. Sin embargo, 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, o sea que se encuentran básicamente desprotegidos. Por lo tanto, debe usarse esta facilidad con sumo cuidado, y normalmente por un período muy corto de tiempo.Si se omite el operando WARNING, el perfil queda definido como NOWARNING, que llamamos modo fail. Este debe ser el modo en que se encuentren usualmente todos los perfiles de la base.

NOTIFY especifica un usuario que será notificado cada vez que el perfil sea usado para denegar un acceso. Hacemos notar que si el perfil es utilizado para rechazar la creación o eliminación de un archivo, no se envía notificación alguna. Si el usuario especificado en el operando NOTIFY se encuentra con una sesión activa de TSO, recibirá las notificaciones en tiempo real. 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 usuario debe loguearse frecuentemente a TSO de modo de liberar el espacio que ocupan sus mensajes pendientes en el archivo SYS1.BRODCAST. De todos modos, no es conveniente tener en forma permanente un usuario en el campo NOTIFY de un perfil, si se supone que el mismo denegará gran cantidad de accesos. NOTIFY no admite más de un usuario, ni un grupo de RACF. Si se lo codifica sin especificar usuario, queda como usuario a ser notificado quien ejecutó el comando ADDSD. Si se lo omite, ningún usuario será notificado, que es lo más habitual.

El operando AUDIT indica a qué nivel se pretende auditar el uso de este perfil. La información se graba en registros tipo 80 del SMF. Se distinguen 2 conceptos diferentes, a saber: “tipo de acceso” y “nivel de acceso”:

Los posibles tipos de acceso son los siguientes:

o NONE indica que ningún intento de acceso será grabado.

o SUCCESS indica que se grabarán accesos exitosos.

o FAILURES indica que se grabarán intentos de acceso fallidos.

o ALL indica que se grabará todo intento de acceso, sea fallido o exitoso.

Los posibles niveles de acceso son los siguientes:

o READ

o UPDATE

o CONTROL

o ALTER

En el operando AUDIT se pueden especificar uno (o más) tipos de acceso acompañados del nivel de acceso deseado (obviamente NONE no requiere un nivel de acceso asociado). EXECUTE no es un nivel factible de ser auditado.

46


FAILURES(READ) es el valor por defecto, y provoca que se registre todo intento de acceso denegado por el perfil (intentos de acceso fallidos superiores a READ también son registrados). Debe tenerse cuidado en no especificar un nivel de auditoría que genere un volumen grande e inútil de información. Por ejemplo, SUCCESS(READ), en el caso de un perfil que proteja recursos muy utilizados, generaría una enorme cantidad de registros tipo 80 de SMF que probablemente no sean necesarios en absoluto. 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.

Ejemplos

1) AD ‘conta.balance.a2010’ DATA(‘balance del 2010’) OWNER(conta) UACC(none) -AUDIT(SUCCESS(update) FAILURES(read))

Define un perfil discreto de dataset para el archivo de nombre CONTA.BALANCE.A2010. Tal dataset debe estar catalogado, pues en caso contrario el comando fallaría ya que no se especificó UNIT ni VOLSER. Se decidió auditar todo acceso fallido más los accesos exitosos de nivel UPDATE (o superior).

2) AD ‘conta.pagos.a2010’ GENERIC DATA(‘pagos del 2010’) UACC(none) -OWNER(jef254) NOTIFY(jef254)

Define un perfil “genérico completo” para el archivo de nombre CONTA.PAGOS.A2010, ya que se codificó el operando GENERIC. A diferencia del caso anterior, tal archivo ni siquiera tiene necesidad de existir en el momento de la creación del perfil. Se decidió establecer como owner y usuario a ser notificado a JEF254.

3) AD ‘prod.public.**’ DATA(‘archivos de uso publico’) UACC(read)

Define un perfil genérico, dado que el nombre contiene el carácter genérico **.

4) AD ‘conta.provee.a200%.**’ FROM(‘conta.pagos.a2010’) FGENERIC - DATA(‘pagos a proveedores’)

Define un perfil genérico, basado en el modelo dado por el perfil genérico completo CONTA.PAGOS.A2010. Como se especificó DATA, este valor prevalece por sobre la Installation Data que tiene el perfil modelo.

Autoridad requerida para definir perfiles de dataset

Para definir un “perfil de dataset de usuario”, quien ejecuta el comando debe cumplir con alguno de los siguientes requisitos:

� Su identificador de usuario debe coincidir con el HLQ del perfil que pretende definir.


� Tener el atributo SPECIAL a nivel de un grupo que tenga al usuario dado por el HLQ del perfil dentro de su campo de acción.

Para definir un “perfil de dataset de grupo”, el usuario que ejecuta el comando debe cumplir con alguno de los siguientes requisitos:

� Estar conectado al grupo dado por el HLQ con nivel de autoridad CREATE o superior.


� Tener el atributo SPECIAL a nivel de un grupo que tenga al grupo dado por el HLQ del perfil dentro de su campo de acción.

� Tener el atributo OPERATIONS a nivel de sistema y no estar conectado al grupo dado por el HLQ.

� Tener el atributo OPERATIONS a nivel de un grupo que tenga dentro de su campo de acción al grupo dado por el HLQ, y no estar conectado a ese grupo.

47


Para poder usar el operando FROM, que permite crear un nuevo perfil de dataset basándose en uno ya existente, RACF exige además que el usuario que ejecuta el comando satisfaga alguno de los siguientes requisitos:


� Tener el atributo SPECIAL a nivel de un grupo que tenga al perfil tomado como modelo dentro de su campo de acción.

� Ser el owner del perfil tomado como modelo.

� Tener un identificador de usuario que coincida con el HLQ del perfil tomado como modelo.

� Si el perfil modelo es discreto, tener autoridad ALTER sobre el perfil.

4.8 - 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, solo es necesario codificar los operandos que se desee modificar. Los no especificados mantienen sus valores previos (no se aplican valores por defecto).

No es posible modificar un perfil discreto para convertirlo en “genérico completo”, o viceversa. Si se pretende realizar esto, debe deletearse el perfil y definirlo nuevamente de la manera deseada.

El operando GENERIC indica simplemente que debe considerarse al perfil como genérico, aún cuando no contenga tales caracteres en su nombre.

Autoridad requerida

Para modificar un perfil de dataset, quien ejecuta el comando debe cumplir con alguno de los siguientes requisitos:


� Tener el atributo SPECIAL a nivel de un grupo que tenga al perfil dentro de su campo de acción.

� Ser el owner del perfil.

� Su identificador de usuario debe coincidir con el HLQ del perfil.

� Si el perfil es discreto, tener autoridad ALTER sobre el perfil.

4.9 - 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. Fuera de la base de RACF, lo único que este comando puede eventualmente modificar es el “bit indicador” de protección de un dataset (que, recordemos, no forma parte del archivo).

GENERIC indica que debe considerarse al perfil como genérico, aún cuando no contenga caracteres comodín en su nombre.

NOSET se aplica exclusivamente para perfiles discretos. Indica que no se modifique el estado del “bit indicador” del archivo. Salvo situaciones particulares que así lo justifiquen, debe evitarse el uso de esta opción, pues no es conveniente dejar marcados como protegidos discretamente archivos que ya no lo están, pues es fuente de confusión e inconvenientes. El archivo, en este caso, quedaría protegido

48


genéricamente, en caso de que existiera alguno perfil genérico apropiado, o simplemente desprotegido en caso contrario.

SET es el valor por defecto, y también se aplica exclusivamente a perfiles discretos. Este operando desactiva el bit de protección del archivo, y requiere que el volumen donde reside esté en línea. Si el archivo tuviera su bit de protección desactivado, y se especifica SET, el comando falla. En tal caso, debería codificarse NOSET para poder borrar el perfil.

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. En efecto, en tal caso, VOLUME es requerido por RACF para saber cuál es exactamente el perfil discreto que debe borrar de la base.

Autoridad requerida

Para eliminar un perfil de dataset, quien ejecuta el comando debe cumplir con alguno de los siguientes requisitos:






4.10 - Listado de un perfil de dataset

Sintaxis:

LISTDSD|LD [{DATASET(‘nombre’)|ID(usuario/grupo)|PREFIX(cadena-de-caracteres)}] [GENERIC|NOGENERIC] [AUTHUSER] [ALL] [DSNS] [VOLUME(volumen)...]

Este comando no efectúa ninguna modificación sobre la base de RACF. Unicamente lista (en la pantalla de la terminal, si se ejecuta en foreground, o con salida a un dataset o al spool, si se ejecuta en batchground) información relativa a perfiles de dataset.

DATASET|ID|PREFIX

El operando DATASET especifica el nombre del perfil a listar.

o Si el nombre no presenta caracteres comodín y no se especifica ni GENERIC ni NOGENERIC, RACF lista la información del perfil discreto y del “genérico completo”. Si ninguno existiese, lo informa.

o Si el nombre no presenta caracteres comodín y se especifica NOGENERIC, RACF lista la información del perfil discreto correspondiente. Si no existiese, lo informa.

o Si el nombre no tiene caracteres comodín y se especifica GENERIC, RACF lista la información del perfil genérico que más se ajusta al nombre del archivo (o sea, de su perfil protector, siempre y cuando no esté protegido de manera discreta).

o Si el nombre tiene algún carácter comodín, RACF ignora el operando [GENERIC|NOGENERIC] y lista el perfil genérico que coincide exactamente con el nombre especificado. Si no existiese, lo informa.

ID debe especificar un usuario o grupo. En tal caso, el comando lista los perfiles cuyo HLQ coincide con este valor. Se listarán solo discretos, solo genéricos, o todos, según se especifique NOGENERIC, GENERIC, o se omita este operando.

Si se especifica PREFIX, el comando lista los perfiles cuyos primeros caracteres coincidan exactamente con el valor especificado. Se listarán solo discretos, solo genéricos, o todos, según como se codifique el

49


operando correspondiente. La cadena de caracteres especificada puede extenderse a más de un calificador.

En caso de no especificar ni DATASET, ni ID ni PREFIX, el valor que asume por defecto es ID con el valor del identificador del usuario que ejecuta el comando.

GENERIC indica que deben listarse únicamente perfiles genéricos, mientras que NOGENERIC indica que solo deben listarse los discretos. Si se omite este operando, y se codificó DATASET, ya se señaló qué perfiles son listados. En cambio, si se especificó ID o PREFIX, se listan todos los perfiles (discretos y genéricos) que cumplan con el criterio de selección correspondiente.

AUTHUSER especifica que se debe incluir en la salida del comando la siguiente información:

o Security level, 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. Si no se especifica, el listado no muestra ni las estadísticas ni las listas de acceso.

El operando DSNS indica que se listen todos los archivos catalogados protegidos por el perfil. Si la cantidad es muy grande, esta búsqueda cruzada es costosa y puede demorar considerablemente la ejecución del comando.

El operando VOLUME limita la información listada a los perfiles discretos asociados con estos volúmenes (se pueden especificar varios). Excepto que se haya codificado NOGENERIC, también se listan los perfiles genéricos que correspondan.

Observación importante:

Los perfiles genéricos, al ser listados (ya sea con el comando LISTDSD o SEARCH), siempre tienen a continuación de su nombre el símbolo (G). Por lo tanto, la ausencia de la (G) indica sin lugar a dudas que se trata de un perfil discreto.

Ejemplo:

LD DA(‘conta.pagos.**’) ALL DSNS

Este comando lista toda la información del perfil genérico CONTA.PAGOS.**, siempre y cuando exista. La salida tendría el siguiente aspecto:

INFORMATION FOR DATASET CONTA.PAGOS.** (G)

LEVEL OWNER UNIVERSAL ACCESS WARNING ERASE 00 CONTA NONE NO NO

AUDITING FAILURES(READ)

NOTIFY CON587

YOUR ACCESS CREATION GROUP DATASET TYPE NONE ADMIN NON-VSAM

GLOBALAUDIT NONE

INSTALLATION DATA AREA DE CONTABILIDAD - PAGOS

SECURITY LEVEL NO SECURITY LEVEL

CATEGORIES NO CATEGORIES

SECLABEL

50


NO SECLABEL

CREATION DATE LAST REFERENCE DATE LAST CHANGE DATE (DAY) (YEAR) (DAY) (YEAR) (DAY) (YEAR) 295 10 NOT APPLICABLE FOR GENERIC PROFILE

ALTER COUNT CONTROL COUNT UPDATE COUNT READ COUNT NOT APPLICABLE FOR GENERIC PROFILE

ID ACCESS CONTA ALTER FINAN READ FIN2514 UPDATE

ID ACCESS CLASS ENTITY NAME NO ENTRIES IN CONDITIONAL ACCESS LIST

CATALOGUED DATA SETS AFFECTED BY PROFILE CHANGE CONTA.PAGOS.A2007 CONTA.PAGOS.A2008 CONTA.PAGOS.A2009 CONTA.PAGOS.PROVEE CONTA.PAGOS.PROVEE.DATA (D) CONTA.PAGOS.PROVEE.INDEX (I)

Del listado precedente, se desprende la siguiente información sobre el perfil:

� Se trata efectivamente de un perfil genérico, ya que figura el símbolo (G) a continuación del nombre.

� LEVEL es un campo para uso administrativo, que puede tomar cualquier valor entre 00 y 99, siendo 00 el valor por defecto. No tiene ninguna relevancia en el chequeo de autoridad, y cada organización lo maneja como desea (aunque es realmente poco utilizado). Un posible uso consiste en asignarle a todos los perfiles con un cierto grado de sensibilidad un mismo LEVEL, de modo de disponer de un criterio de selección para la elaboración de informes de auditoría. No debe confundirse LEVEL con “SECURITY LEVEL”.

� El OWNER es CONTA. Suponemos que es un grupo, aunque en general no es posible determinar con solo mirar un identificador si se trata de un usuario o de un grupo. De todos modos, cada organización tiene usualmente una nomenclatura bastante diferente para ambos, con lo cual suele ser mas o menos evidente para los administradores cuando se trata de un usuario y cuando de un grupo.

� El UACC del perfil es NONE.

� WARNING en NO indica que el perfil está en modo fail. Esto significa que se denegará todo acceso no autorizado. Salvo casos excepcionales, todos los perfiles deben estar en modo fail.

� El valor YES en campo ERASE a nivel del perfil, combinado con una configuración apropiada del ERASE a nivel de la SETROPTS, especifica que cuando se deletea un archivo protegido por este perfil, los datos deben ser físicamente borrados en el disco dónde reside (sobrescribiendo todos los extents con ceros binarios). Este requerimiento extra de seguridad, que impide cualquier intento de recuperación de los datos, no suele ser necesario.El valor por defecto es NO.

� FAILURES(READ) en el campo AUDITING indica que se pretende loggear en el SMF únicamente los intentos de acceso denegados por el perfil. Los accesos exitosos no serán grabados, cualquiera sea el nivel (excepto que exista algún otro seteo de auditoría que indique lo contrario, a nivel de la SETROPTS o del GLOBALAUDIT del perfil).

� El usuario CON587 recibirá una notificación cada vez que el perfil CONTA.PAGOS.** sea utilizado para denegar una solicitud de acceso. En este caso, podemos estar seguros que CON587 es un usuario, ya que el campo NOTIFY no admite grupos.

51


� El campo YOUR ACCESS muestra el nivel de autoridad que tiene sobre el perfil el usuario que ejecuta el comando LISTDSD.

� CREATION GROUP indica el “grupo de conexión” que tenía el usuario que definió el perfil en el momento de la creación.

� DATASET TYPE puede tomar los valores NON-VSAM, VSAM, MODEL o TAPE.

� GLOBALAUDIT funciona de manera similar al campo AUDIT, pero es únicamente visible y modificable por usuarios con el atributo AUDITOR a nivel de sistema, o a nivel de un grupo que tenga al perfil dentro de su campo de acción.

� La INSTALLATION DATA es opcional, pero es una buena costumbre usar este campo para describir brevemente el perfil.

� SECURITY-LEVEL, CATEGORIES y SECLABEL son campos relacionados con un nivel extra de seguridad que brinda RACF y es realmente muy poco utilizado. Si la organización no usa esta seguridad adicional, los 3 campos deben indicar que no tienen información.

� CREATION DATE indica el día y el año en que se definió el perfil. En este caso, el perfil se creó el día 295 del año 2010.

� LAST REFERENCE DATE y LAST CHANGE DATE no se aplican a perfiles genéricos. Solamente se mantienen estos campos para perfiles discretos.

� ALTER COUNT, CONTROL COUNT, UPDATE COUNT y READ COUNT no se aplican a perfiles genéricos. En el caso de perfiles discretos, solo se mantienen actualizados si está especificado en la SETROPTS que se mantengan estadísticas para la clase DATASET.

� La lista de acceso estándar del perfil tiene entradas constituidas por usuarios o grupos, con su nivel de acceso correspondiente. En el ejemplo, existen 3 entradas en la lista de acceso estándar (vale la misma aclaración que se hizo previamente, en el sentido en que no se puede distinguir a priori si se trata de usuarios o grupos). Eventualmente, también puede figurar en la lista de acceso una entrada *, que tiene un significado similar -pero no idéntico- al del UACC.

� La lista de acceso condicional se encuentra vacía (no contiene ninguna entrada). No nos ocuparemos en la presente guía de analizar la lista de acceso condicional de un perfil (no es muy frecuente su uso, por otro lado).

� Al haber especificado el operando DSNS en el comando LISTDSD, la salida incluye una lista de los archivos catalogados que se encuentran protegidos por el perfil. En nuestro caso, existen 4datasets, uno de los cuáles es VSAM (y por eso genera 3 entradas en el listado, correspondientes a sus distintos componentes).

Es posible que un usuario pueda ejecutar el comando del ejemplo pero que algunos campos no le sean mostrados por carecer de la autoridad suficiente (por ejemplo, GLOBALAUDIT o listas de acceso).

Autoridad requerida

Para listar un perfil de dataset, quien ejecuta el comando debe cumplir con alguno de los siguientes requisitos:

� Tener el atributo SPECIAL, AUDITOR u OPERATIONS a nivel de sistema.

� Tener el atributo SPECIAL, AUDITOR u OPERATIONS a nivel de un grupo que tenga al perfil dentro de su campo de acción.



� Tener autoridad READ o superior sobre el perfil.

52


� Existir una regla en la GLOBAL que coincida con el perfil y otorgue autoridad READ o superior.

Para que se liste el campo GLOBALAUDIT se debe tener el atributo AUDITOR (ya sea a nivel de sistema, o a nivel de grupo para un grupo que tenga al perfil dentro de su campo de acción).

Para ver las listas de acceso del perfil, quien ejecuta el comando debe satisfacer alguna de las siguientes condiciones:





� Existir una regla en la GLOBAL que coincida con el perfil y otorgue autoridad ALTER.

� Si el perfil es discreto, tener autoridad ALTER.

4.11 - Permisos sobre perfiles de dataset

Las listas de acceso de un perfil de dataset, tanto la estándar como la condicional, se modifican a través del comando PERMIT. Más aún, con este mismo comando se manejan también las listas de acceso de cualquier perfil de recursos generales.

Sintaxis:

PERMIT|PE ‘nombre-del-perfil’ [CLASS(clase)] [GENERIC] [ID({usuario/grupo...|*})] [ACCESS(nivel)|DELETE] [VOLUME(volumen)] [FROM(‘perfil2’)] [FCLASS] [FGENERIC] [FVOLUME(volumen)] [RESET(ALL|STANDARD|WHEN)] [WHEN([APPCPORT({partner-luname|*})] [CONSOLE({consola|*})] [JESINPUT({nombre-input-device|*})] [PROGRAM({programa|*})] [SYSID({sysid|*})] [TERMINAL({terminal|*})])]

El nombre-del-perfil es requerido y debe estar inmediatamente a continuación del comando PERMIT.

CLASS indica la clase a la que pertenece el perfil. El valor por defecto es DATASET, por lo cual, en el caso particular que nos ocupa, puede omitirse.

GENERIC especifica que el perfil es genérico. Debe necesariamente codificarse si se trata de un “genérico completo”, pues de lo contrario RACF supondrá que el perfil es discreto. Si el nombre contiene caracteres comodín, GENERIC puede omitirse.

ID indica el usuario o grupo cuya entrada en la lista de acceso se desea agregar, modificar o eliminar. Separados por espacios pueden ingresarse más de un usuario/grupo. También se acepta el valor *, que representa un usuario cualquiera existente en la base de RACF.

ACCESS especifica el nivel de autoridad a otorgarle al usuario/grupo especificado en el operando ID. Los posibles valores son NONE, EXECUTE, READ, UPDATE, CONTROL y ALTER. Si se codifica ACCESS sin poner ningún valor, se asume READ.

DELETE indica que se pretende borrar de la lista de acceso la entrada correspondiente al usuario/grupo codificado en el operando ID.

Si se especificó ID pero se omitió tanto ACCESS como DELETE, se asume por defecto ACCESS(READ). En ambos casos, ya sea con ACCESS o DELETE, RACF actúa sobre la lista de acceso estándar, excepto que se codifique explícitamente el operando WHEN, en cuyo caso se modifica la lista de acceso condicional.

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, genérico o discreto, del cual se quieren copiar las listas de acceso (estándar y condicional). Las entradas en las listas de acceso del perfil2 son agregadas a las listas de acceso correspondiente. Por lo tanto, el operando FROM no convierte en idénticas las listas de acceso de ambos perfiles. Más aún, si una entrada que figura en la lista de acceso del perfil2 ya se encuentra en la del perfil en cuestión, entonces la misma no se modifica.

FCLASS indica la clase a la que pertenece el perfil especificado en el operando FROM. Si omite FCLASS y se codificó FROM, se asume por defecto que perfil2 pertenece a la misma que clase que el perfil en cuestión (DATASET, en nuestro caso).

FGENERIC indica a RACF que el perfil especificado en el operando FROM es genérico, aún cuando no contenga caracteres genéricos. RACF ignora el operando FGENERIC si no se codificó FROM.

Si el operando FROM especifica un perfil discreto de DATASET, el operando FVOLUME indica el volumen correspondiente. Si se codificara FVOLUME con un valor distinto al que corresponde al perfil2, o si se omite y existe más de un perfil discreto con ése nombre, el comando falla. Si no se especificó el operando FROM, o se codificó con un perfil genérico, o con un perfil de una clase que no sea DATASET, el operando FVOLUME es ignorado.

El operando RESET indica que se quiere vaciar una o ambas listas de acceso, es decir eliminar todas las entradas. RESET(STANDARD) vacía únicamente la lista de acceso estándar, en tanto que RESET(WHEN) hace lo propio con la condicional. RESET(ALL) vacía ambas listas de acceso. Si se codifica RESET sin ningún valor, se asume por defecto ALL.

El operando WHEN indica que se quiere modificar la lista de acceso condicional. No describiremos los distintos suboperandos que admite. Si se omite WHEN, las modificaciones se efectúan sobre la lista de acceso estándar (aunque los operandos FROM o RESET pueden impactar igualmente sobre la lista de acceso condicional).

Ejemplos:

1) PE ‘conta.balance.a2010’ ID(conta) ACCESS(update)

Otorga UPDATE en la lista de acceso estándar del perfil discreto CONTA.BALANCE.A2002 al grupo CONTA. Si el grupo ya figuraba, modifica su nivel a UPDATE, mientras que si no estaba, lo incorpora con este nivel de acceso.

2) PE ‘conta.pagos.a2010.**’ FROM(‘conta.provee.a2010’) FGENERIC - ID(jef234 jef587) ACCESS(ALTER)

Copia al perfil genérico CONTA.PAGOS.A2010.** las entradas de las listas de acceso del perfil “genérico completo” de nombre CONTA.PROVEE.A2010. Independientemente de las entradas que se copien, la presencia de ID y ACCESS indica que los usuario JEF234 y JEF587 serán incorporados a la lista de acceso estándar del perfil CONTA.PAGOS.A2010.** con nivel de autoridad ALTER.

3) PE ‘conta.a2010.**’ RESET ID(*) ACCESS(READ)

Vacía las listas de acceso (estándar y condicional) del perfil genérico CONTA.A2010.** e incorpora en la lista estándar la entrada * con nivel de acceso READ. El orden de los operandos no tiene importancia en este caso, pudiendo haberse especificado RESET al final (si se codifican ambos operandos -RESET y ID-, primero se vacía la lista de acceso y luego se procesa el ID).

Autoridad requerida

Para ejecutar exitosamente el comando PERMIT sobre un perfil de dataset, el usuario debe satisfacer alguna de las siguientes condiciones:

54







Para poder especificar el operando FROM, quien ejecuta el comando necesita adicionalmente autoridad sobre el perfil del cual se pretende copiar las listas de acceso.

4.12 - Perfiles de dataset: discretos versus genéricos

Como ya se ha señalado, originalmente los únicos perfiles de dataset que admitía RACF eran los que hoy se conocen como discretos. Posteriormente, con la aparición de la posibilidad de definir perfiles de dataset genéricos, la mayoría de las organizaciones fueron abandonando paulatinamente la utilización de los perfiles discretos, llegando en muchos casos a su eliminación total. Esto es entendible, y hasta aconsejable, teniendo en cuenta que los perfiles genéricos son más sencillos de administrar, y es necesaria una menor cantidad de los mismos para proteger la totalidad de los archivos.

Sin embargo, debe tenerse cuidado de no abusar en este sentido, ya que la existencia de una gran cantidad de perfiles genéricos con idéntico HLQ puede traer aparejado importantes problemas de performance. En efecto, dado un archivo, 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, ya que en este último caso RACF debe realizar una búsqueda de tipo secuencial hasta dar con el perfil más ajustado. Por lo tanto, si bien es muy aconsejable el uso de perfiles de dataset genéricos, no debe caerse en el extremo de definir una cantidad tal que impacte negativamente en la performance (por ejemplo, 500 perfiles genéricos con igual HLQ no parece apropiado).

Los perfiles discretos tienen pues aún su lugar, y en algunos casos particulares continúan siendo una mejor opción. Por otro lado, IBM no tiene previsto discontinuarlos en un futuro cercano, de modo que no hay ninguna razón para no utilizarlos si resultan mas apropiados para resolver una determinada situación. Por ejemplo, si existieran 2 datasets de idéntico nombre (uno de ellos necesariamente descatalogado) que requirieran distinta protección, solo sería posible lograrlo mediante el uso de perfiles discretos.

4.13 - Creación de nuevos datasets

Ya hemos visto, al analizar el comando ADDSD, la autoridad que se requiere para definir un nuevo perfil de dataset. Veremos ahora que autoridad exige RACF para definir un nuevo archivo. Supondremos, para simplificar, que la opción PROTECTALL de la SETROPTS está activa en modo FAIL. Básicamente, esto significa que los archivos no protegidos por un perfil en la clase DATASET resultan inaccesibles. Volveremos sobre este punto en el capítulo dónde estudiemos en detalle las opciones de la SETROPTS. Recordemos que un archivo, para poder estar efectivamente protegido por RACF, debe tener como HLQ un usuario o grupo (pues esto es requisito insalvable para perfiles). Por lo tanto, los datasets se dividen en “datasets de usuario” y “datasets de grupo”.

Para crear un “dataset de usuario”, quien lo hace debe satisfacer alguna de las condiciones que se enumeran a continuación:

� El dataset quedará protegido por un perfil genérico y, se cumple alguno de los requisitos siguientes:

- Tiene autoridad ALTER sobre tal perfil.

- Tiene autoridad ALTER a través de una regla en la GLOBAL.

- El HLQ del archivo coincide con su identificador de usuario.

55


� Tener el atributo ADSP y el HLQ del dataset coincidir con su identificador de usuario. En este caso, se le creará automáticamente un perfil discreto.

Para crear un “dataset de grupo”, 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, se cumple alguno de los requisitos siguientes:

- Tiene autoridad ALTER sobre tal perfil.

- Tiene autoridad ALTER a través de una regla en la GLOBAL.

- Está conectado al grupo dado por el HLQ con autoridad CREATE o superior.

� Tener el atributo ADSP y el HLQ ser un grupo al cual esté conectado con autoridad CREATE o superior. En este caso, se le creará automáticamente un perfil discreto.

� Tener el atributo OPERATIONS a nivel de sistema y no cumplir simultáneamente:

- Estar conectado al grupo dado por el HLQ con nivel USE

- Tener autoridad menor que ALTER sobre el perfil genérico que lo protegerá.

� Tener el atributo OPERATIONS a nivel de grupo, 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

- Tener autoridad menor que ALTER sobre el perfil genérico que lo protegerá. Es importante recalcar que si se pretende que el dataset se catalogue, el usuario que lo define debe asimismo tener autoridad UPDATE sobre el catálogo correspondiente (USERCAT o MASTERCAT, dependiendo de la existencia o no del ALIAS apropiado).

56


5 - OPCIONES GLOBALES DE RACF


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. Esta configuración se encuentra almacenada dentro de la base de RACF (en el primer bloque, llamado ICB –Inventory

Control Block-), y puede ser modificada dinámicamente. Con excepción de las opciones globales relativas a auditoría, que requieren el atributo AUDITOR a nivel de sistema, el resto de los parámetros exige el atributo SPECIAL a nivel de sistema para ser modificados.

Una adecuada configuración de la SETROPTS es fundamental para dotar a la organización de un adecuado nivel de seguridad. A lo largo del presente capítulo vamos a examinar en detalle las opciones de la SETROPTS, indicando en muchos casos la configuración que consideramos más conveniente, tanto desde el punto de vista administrativo como desde el de la seguridad del sistema.

Cuando RACF se instala por primera vez, la SETROPTS provista por IBM es a todas luces insuficiente para brindar una seguridad razonable a un entorno productivo. La configuración global por defecto es totalmente abierta y permisiva, lo cual es entendible para cuando se afrontan las primeras etapas de la construcción de un sistema. Sin embargo, antes de empezar a utilizarlo productivamente, el administrador de RACF debe configurar adecuadamente la SETROPTS, para lo cual debe tener bien en claro el significado e impacto de cada una de sus opciones.

5.2 - Posit Value de una clase

Toda clase de RACF, ya sea provista por IBM o definida por la organización, tiene asociado un número comprendido entre 0 y 1023, denominado posit value. Varias clases pueden compartir el mismo número. En efecto, IBM otorga igual posit value a clases que están íntimamente relacionadas, como ser todas aquellas vinculadas con un mismo producto. Los rangos 0-18, 57-127 y 528-1023 están reservados para uso exclusivo de IBM, por lo cual no debe utilizarse ningún número en alguno de estos rangos para una clase definida por la organización.

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.

Por ejemplo, todas las siguientes clases, relacionadas con CICS, comparten el posit value 5:

TCICSTRN, GCICSTRN, PCICSPSB, QCICSPSB, FCICSFCT, HCICSFCT, JCICSJCT, KCICSJCT, DCICSDCT, ECICSDCT, SCICSTST, UCICSTST, MCICSPPT, NCICSPPT, ACICSPCT, BCICSPCT.

En consecuencia, el comando “SETROPTS AUDIT(TCICSTRN)” no solo auditará la clase TCICSTRN sino que automáticamente hará lo propio con el resto de las clases mencionadas.

5.3 - Listado de la SETROPTS

Para listar el contenido de la SETROPTS se requiere tener el atributo SPECIAL o AUDITOR, ya sea a nivel de sistema o a nivel de grupo. Como ya indicáramos, los usuarios con atributo SPECIAL no pueden visualizar las opciones relativas a auditoría.

Sintaxis:

SETROPTS|SETR LIST

No existe la posibilidad de listar parcialmente información de la SETROPTS. Para ver la configuración de un determinado parámetro, no queda mas remedio que buscarlo dentro del listado completo que brinda el comando “SETR LIST”. Mostramos a continuación, a modo de ejemplo, el listado de la SETROPTS que podría tener una organización típica.

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

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.

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 30 DAYS. 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

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).

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)


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)


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

61


SAUDIT, que significa special audit, indica que para todos los usuarios con atributo SPECIAL (tanto a nivel de sistema como a nivel de grupo) se grabarán registros tipo 80 de SMF cada vez que ejecuten exitosamente comandos de RACF (con excepción de los comandos LISTUSER, LISTGROUP, LISTDSD, RLIST y SEARCH, que nunca se registran ya que no se consideran críticos pues no realizan ninguna modificación).

SAUDIT es la opción en efecto en una base recién inicializada. Como los usuarios con atributo SPECIAL tienen un enorme poder dentro de la organización, y deben ser pocos, resulta aconsejable monitorear detalladamente su actividad, por lo cual aconsejamos especificar SAUDIT.

5.8 - Auditoría de violación de comandos

Sintaxis: SETROPTS|SETR CMDVIOL|NOCMDVIOL


Opción sugerida: CMDVIOL

CMDVIOL, que significa command violation, 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, LISTGROUP, LISTDSD, RLIST y SEARCH, cuyas ejecuciones fallidas no se registran).

CMDVIOL es la opción en efecto en una base recién inicializada. Los intentos fallidos de ejecución de comandos de RACF deben ser analizados. Si se trata de un comando que corresponde, debe otorgarse al usuario la autoridad necesaria para que pueda ejecutarlo exitosamente. Si, en cambio, se trata de un usuario que intenta ejecutar un comando de RACF que no le compete, deben tomarse las medidas que se consideren convenientes. En cualquier caso, la cantidad de comandos fallidos de RACF no debería ser elevada.

5.9 - Auditoría de usuarios con atributo OPERATIONS

Sintaxis: SETROPTS|SETR OPERAUDIT|NOOPERAUDIT


Opción sugerida: sin sugerencia

OPERAUDIT, que significa operations audit, indica que para todos los usuarios con atributo OPERATIONS (tanto a nivel de sistema como a nivel de grupo) se grabarán registros tipo 80 de SMF en las siguientes situaciones:

� Acceso exitoso a un recurso protegido posibilitado por el atributo OPERATIONS.

� Ejecución exitosa de los comandos ADDSD y RDEFINE posibilitada por el atributo OPERATIONS.

� Definición de un nuevo recurso cuya creación esté controlada por RACF (la alocación de un nuevo dataset, por ejemplo) y que resulte exitosa gracias al atributo OPERATIONS.

Por ejemplo, supongamos que está OPERAUDIT en efecto, que el usuario USUA tiene el atributo OPERATIONS a nivel de sistema y que intenta modificar un archivo protegido por el perfil PROD.** que tiene UACC(NONE).

- Si USUA figura en la lista de acceso de PROD.** con autoridad UPDATE (o superior), el acceso resulta exitoso, no por el atributo OPERATIONS, sino por su presencia en la lista de acceso. Por lo tanto, en este caso, el parámetro OPERAUDIT no provocará la grabación de un registro de auditoría.

62


- Si ni USUA ni ninguno de los grupos a los que está conectado figura en la lista de acceso de PROD.** (ni existe una regla en la GLOBAL que posibilite el acceso), entonces el acceso resultará exitoso debido a la autoridad ALTER que otorga implícitamente el atributo OPERATIONS sobre el perfil PROD.**. Por lo tanto, el parámetro OPERAUDIT provocará la grabación de un registro de auditoría reflejando el evento.

NOOPERAUDIT es la opción en efecto en una base recién inicializada. Como ya hemos señalado, no es aconsejable tener en la base usuarios con el atributo OPERATIONS. Sin embargo, si la organización decide lo contrario, debe tenerse en cuenta que un usuario con este atributo y una intensa actividad (por ejemplo, el usuario asociado al DFHSM), puede generar un volumen enorme de registros de SMF. En tal caso, NOOPERAUDIT sería lo más apropiado. En cambio, si existen pocos usuarios con el atributo OPERATIONS y su actividad es reducida, monitorearlos a través de la opción OPERAUDIT puede ser una buena idea.

5.10 - Clases con estadísticas

Sintaxis: SETROPTS|SETR {STATISTICS|NOSTATISTICS}(clase…|*)


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. Si se codifica *, todas las clases resultan afectadas (con excepción de las clases USER y GROUP).

Si una clase está bajo STATISTICS, RACF mantendrá un determinado conjunto de estadísticas para sus perfiles discretos. En tal caso, en cada perfil discreto se almacenará la siguiente información:

- Cantidad de veces que se accedió al recurso para cada nivel de autoridad.

- Fecha de la última referencia.

- Fecha de la última modificación.

- Para cada entrada en la lista de acceso, la cantidad de veces que se otorgó acceso al recurso.

Tales estadísticas nunca se mantienen para perfiles genéricos.

No deben confundirse estas estadísticas con aquellas a las que se refiere la opción INITSTATS que analizamos previamente.

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.

El mantenimiento de estadísticas, cuando la cantidad de perfiles discretos es importante, afecta la performance negativamente. Por lo tanto, salvo que exista una fuerte necesidad de contar con dicha información, resulta aconsejable no tener ninguna clase bajo STATISTICS.

5.11 - Clases auditadas

Sintaxis: SETROPTS|SETR {AUDIT|NOAUDIT}(clase…|*)


Opción sugerida: AUDIT para todas las clases, activas o no, con excepciones muy puntuales

Se puede especificar con el operando AUDIT|NOAUDIT las clases USER, GROUP, DATASET o cualquier otra clase definida en la CDT. Si se codifica *, todas las clases resultan afectadas.

Si una clase tiene AUDIT, entonces se 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

63


información). También grabarán registros las solicitudes de DEFINE para esa clase (por ejemplo, si está la clase DATASET bajo AUDIT, toda alocación de un nuevo archivo).

Para los usuarios con atributo SPECIAL, el ya mencionado parámetro SAUDIT provoca la generación de registros de SMF toda vez que ejecutan comandos de RACF. Si la clase a la que pertenece el perfil afectado está bajo AUDIT, no se generarán dos registros distintos por el mismo evento, sino que se grabará un único registro. No debe pues temerse la redundancia que pueden presentar los parámetros SAUDIT, OPERAUDIT y AUDIT usados conjuntamente, ya que no aumentan la cantidad de registros de grabados.

Los operandos AUDIT y NOAUDIT afectan no solo a la clase especificada sino también a todas aquellas otras que eventualmente compartan el mismo posit value.

Recomendamos tener bajo AUDIT a todas las clases de RACF. Recordemos que, si una determinada clase no se encuentra activa, RACF no la utiliza para controlar accesos a recursos, pero ello no significa de ninguna manera que no se puedan definir, modificar o borrar perfiles. Por lo tanto, con el objeto de monitorear toda modificación sobre la base de RACF, es conveniente auditar todas las clases, lo cual se logra de manera sencilla ejecutando el comando: SETROPTS AUDIT(*)

La única 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), pues pueden generar un gran volumen de registros de poca utilidad (Ej: FSOBJ, IPCOBJ y PROCESS). Para ellas, luego de ejecutado el comando anterior, puede sacárselas de la categoría AUDIT mediante el comando “SETROPTS NOAUDIT(clase)”.

En una base de RACF recién inicializada, está en efecto la opción NOAUDIT(*), lo cual significa que ninguna clase está bajo AUDIT. Esto debería modificarse antes de empezar a utilizar el sistema para tareas productivas.

5.12 - Clases activas

Sintaxis: SETROPTS|SETR {CLASSACT|NOCLASSACT}(clase…|*)


Opción sugerida: depende de cada organización

Se puede especificar con el operando CLASSACT|NOCLASSACT cualquier clase de recursos generales. Las clases USER, GROUP y DATASET se encuentran siempre activas y no se las puede desactivar.

Únicamente si una determinada clase se encuentra activa RACF utilizará sus perfiles para controlar el acceso a recursos. Es decir, a los efectos del chequeo de autoridad de un usuario sobre un recurso, una clase inactiva no cumple ninguna función.

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.

Es recomendable tener activas solo las clases que resulten importantes para la organización, las cuáles son usualmente muchas menos que las más de 230 provistas por IBM. Alrededor de 60 clases activas suele ser suficiente para una organización promedio.

Toda clase tiene asociado un DFTRETC (Default Return Code) especificado en la CDT, que puede ser 0, 4 u 8. Este valor indica el 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). Su significado es el siguiente:

64


0 El requerimiento de acceso se acepta

4 Se informa a la aplicación que no existe perfil protector

8 El requerimiento de acceso se rechaza

En cualquier caso, recordemos que es siempre la aplicación la que autoriza o rechaza una solicitud de acceso. 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).

La mayoría de las clases tienen un DFTRETC igual a 4, con lo cual la inexistencia de un perfil protector del recurso deja en manos de la aplicación la decisión de otorgar o rechazar el pedido de acceso.

Existen algunas clases cuyo DFTRETC es 8 (JESSPOOL, por ejemplo). En tales casos, si la clase está activa, aquellos recursos no protegidos resultan inaccesibles. Activar una clase con DFTRETC igual a 8, sin antes definir adecuadamente todos los perfiles necesarios, puede acarrear graves inconvenientes de acceso. Por tal motivo, RACF emite el siguiente mensaje informativo al momento de su activación:

“ICH14073I WARNING: Class class-name was activated by the SETROPTS command. Authorization checks might fail.”

El comando “SETROPTS CLASSACT(*)” activa todas las clases con excepción de aquellas cuyo DFTRETC sea igual a 8. En cambio, el comando “SETROPTS NOCLASSACT(*)” inactiva todas las clases, independientemente de su DFTRETC (con excepción de USER, GROUP y DATASET).

En cualquier caso, activar una clase es una acción de suma importancia, y no debe hacerse sin tener bien en claro su funcionamiento y alcance.

En una base recién inicializada, está en efecto la opción NOCLASSACT(*), lo cual significa que ninguna clase está activa (con excepción, claro está, de USER, GROUP y DATASET). Por lo tanto, antes de empezar a utilizar el sistema para tareas productivas, deben definirse los perfiles apropiados y activar las clases necesarias.

5.13 - Clases con perfiles genéricos

Sintaxis: SETROPTS|SETR {GENERIC|NOGENERIC}(clase…|*)



Se puede especificar con el operando GENERIC|NOGENERIC la clase DATASET o cualquier clase de recursos generales, excepto las clases agrupadoras (GDASDVOL o GTERMINL, por ejemplo) y aquellas que, según su definición en la CDT, no admitan perfiles genéricos (SECLABEL, por ejemplo).

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. Naturalmente, también utilizará los perfiles discretos que existan.

En cambio, la opción NOGENERIC significa que RACF no considerará sus perfiles genéricos a la hora de decidir sobre un requerimiento de acceso. Por lo tanto, en este caso, los eventuales perfiles genéricos de la clase no cumplen función alguna en el momento de otorgar o denegar una solicitud de acceso.

Los operandos GENERIC y NOGENERIC afectan no solo a la clase especificada sino también a todas aquellas otras que eventualmente compartan el mismo posit value (con excepción de las eventuales clases agrupadoras).

En una base de RACF recién inicializada, está en efecto la opción NOGENERIC(*), lo cual significa que para ninguna clase se toman en cuenta perfiles genéricos para decidir sobre requerimientos de

65


acceso. Siempre que sea posible utilizarlos, los perfiles genéricos facilitan la administración. Por lo tanto, se aconseja especificar GENERIC para todas las clases activas que admitan perfiles genéricos.

5.14 - Clases con comandos genéricos

Sintaxis: SETROPTS|SETR {GENCMD|NOGENCMD}(clase…|*)


Opción sugerida: depende de cada organización, pero las mismas que bajo GENERIC

Se puede especificar con el operando GENCMD|NOGENCMD la clase DATASET o cualquier clase de recursos generales, excepto las clases agrupadoras (GDASDVOL o GTERMINL, por ejemplo) y aquellas que, según su definición en la CDT, no admitan perfiles genéricos (SECLABEL, por ejemplo).

La opción GENCMD para una clase indica que RACF permitirá procesar comandos que afecten a sus perfiles genéricos. A veces resulta necesario desactivar momentáneamente el chequeo de perfiles genéricos para determinada clase, pero mantener al mismo tiempo la posibilidad de definir, modificar o deletear perfiles genéricos existentes. En tal caso, el comando “SETROPTS NOGENERIC(clase) GENCMD(clase)” permite realizar las tareas de mantenimiento deseadas. Si se especifica GENERIC para una clase, automáticamente se le aplica también el operando GENCMD. Por el contrario, si se codifica la opción NOGENERIC, NOGENCMD no se aplica de manera automática. En una situación normal, el listado de clases bajo GENERIC y GENCMD debería ser idéntico.

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).

En una base de RACF recién inicializada, está en efecto la opción NOGENCMD(*). Se aconseja especificar GENCMD para todas las clases activas que admitan perfiles genéricos.

5.15 - Clases con perfiles genéricos compartidos en memoria (GENLISTeadas)

Sintaxis: SETROPTS|SETR {GENLIST|NOGENLIST}(clase…)


Opción sugerida: ninguna clase

La opción GENLIST establece que los perfiles genéricos de la clase se cargarán en memoria, en un espacio compartido accesible por las distintas aplicaciones. En efecto, en lugar de existir una copia del perfil genérico en cada address space que lo requiera, se lo copiará a un sector común de la memoria la primera vez que se lo necesite, y permanecerá allí de modo que cualquier otra aplicación pueda utilizarlo sin tener que extraerlo nuevamente de la base. Esto no solo ahorra espacio en memoria sino que eventualmente mejora la performance, ya que resulta mucho 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 contrapartida, cada vez que se modifique un perfil genérico de la clase bajo GENCMD, 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, y la misma es excluyente con la opción RACLIST que veremos a continuación. En la CDT está indicado qué clases admiten este parámetro. Usualmente, las clases tienen definidos tanto perfiles genéricos como discretos, en cuyo caso suele ser mas ventajoso, si es posible, RACLISTearlas en lugar de ponerlas bajo GENLIST. En virtud de esto, resulta frecuente no tener ninguna clase GENLISTeada.

66


Los operandos GENLIST y NOGENLIST afectan no solo a la clase especificada, sino también a todas las otras que tengan el mismo posit value y sean pasibles de ser GENLISTeadas.

En una base de RACF recién inicializada, está en efecto la opción NOGENLIST(*), es decir que ninguna clase se encuentra bajo GENLIST.

5.16 - Clases en la GLOBAL

Sintaxis: SETROPTS|SETR {GLOBAL|NOGLOBAL}(clase…|*)


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, excepto las clases agrupadoras (GDASDVOL o GTERMINL, por ejemplo).

Si una clase está bajo GLOBAL en la SETROPTS, ello significa que RACF utilizará la información del perfil correspondiente de la clase GLOBAL para eventualmente otorgar un acceso solicitado. 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.

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).

En una base de RACF recién inicializada, está en efecto la opción NOGLOBAL(*), es decir que para ninguna clase RACF procesa la información de la GLOBAL. Es altamente recomendable tener al menos la clase DATASET bajo GLOBAL, ya que existen seguramente archivos de uso público muy frecuente (catálogos de usuario, por ejemplo), en cuyo caso una regla apropiada en la GLOBAL puede mejorar sensiblemente la performance.

5.17 - Clases con perfiles genéricos y discretos compartidos en memoria –RACLISTeadas-

Sintaxis: SETROPTS|SETR {RACLIST|NORACLIST}(clase…)


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, en un sector compartido (data space) que estará disponible para las distintas aplicaciones. Como ya mencionáramos, para una clase dada, RACLIST y GENLIST son operandos excluyentes.

Sólo las clases que tienen RACLIST=ALLOWED especificado en la CDT pueden ser RACLISTeadas. No se puede especificar RACLIST para una clase agrupadora (GCICSTRN o VCICSCMD, por ejemplo). De todos modos, si la correspondiente “clase de miembros” (member class) está RACLISTeada, al cargarse la información de sus perfiles en memoria ésta se combina con la contenida en los perfiles de la clase agrupadora. Esto se analizará en detalle en un capítulo posterior.

Cada vez que se modifique un perfil -genérico o discreto- de una clase RACLISTeada, será necesario actualizar la información almacenada en memoria ejecutando el comando:

SETROPTS RACLIST(clase) REFRESH

De todos modos, RACF informa con un mensaje por pantalla que los cambios no serán reflejados hasta que el comando de REFRESH haya sido ejecutado.

Aún si se modificó información de un perfil de una clase agrupadora, el comando de REFRESH debe ejecutarse especificando la “clase de miembros”.

67


Los operandos RACLIST y NORACLIST afectan no solo a la clase especificada, sino también a todas las otras que eventualmente compartan el mismo posit value (y sean pasibles de ser RACLISTeadas).

Las siguientes clases provistas por IBM, en caso de estar activas, deben obligatoriamente estar RACLISTeadas:

APPCSERV DEVICES NODES PTKTDATA STARTED

APPCTP DIGTNMAP OPERCMDS RACFVARS SYSMVIEW

CSFKEYS FIELD PROPCNTL SECLABEL UNIXPRIV

CSFSERV IDIDMAP PSFMPL SERVAUTH VTAMAPPL

Adicionalmente, IBM recomienda RACLISTear las siguientes clases, suponiendo que estén activas:

ACCTNUM DIGTCERT JESJOBS PTKTVAL SURROGAT

APPL DIGTCRIT JESPOOL PRINTSRV TERMINAL

CDT DIGTRING LDAPBIND RRSFDATA TSOAUTH

CONSOLE DSNR MGMTCLAS SDSF TSOPROC

DASDVOL FACILITY PERFGRP STORCLAS WRITER

En cuanto al resto de las clases activas y factibles de ser RACLISTeadas, el hacerlo o no es una decisión que debe tomar cada organización. Si se trata de una clase con muy poca actividad, no se gana demasiado RACLISTeándola (aunque tampoco resultaría perjudicial hacerlo, de no ser por la necesidad de refrescar los perfiles cada vez que se efectúa alguna modificación). En cambio, si se trata de una clase con perfiles utilizados con relativa frecuencia, resulta sin duda conveniente RACLISTearla.

En una base de RACF recién inicializada ninguna clase está RACLISTeada. Esta configuración inicial debe cambiarse de acuerdo a lo señalado en el párrafo anterior.

5.18 - Clases RACLISTeadas vía RACROUTE REQUEST=LIST, GLOBAL=YES

Si observamos la salida del comando “SETROPTS LIST”, vemos que a continuación del listado de las clases RACLISTeadas con el comando “SETROPTS RACLIST(clase)”, aparece un listado de clases bajo el rótulo “GLOBAL=YES RACLIST ONLY”. En el ejemplo que nos ocupa, figuran allí las clases TCICSTRN y CCICSCMD, ambas relacionadas con CICS.

Estas clases no han sido RACLISTeadas por un administrador de RACF con atributo SPECIAL, sino que las ha RACLISTeado alguna aplicación que las utiliza. En nuestro ejemplo, la primera región CICS que se levanta se encarga de RACLISTear ambas clases. Si se ejecutara el comando “SETROPTS LIST” en un momento en que ninguna región CICS se encuentre activa, entonces ninguna de estas clases aparecería RACLISTeada.

Mas allá de esta diferencia, 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)”. Una diferencia que vale la pena mencionar es que, para las clases bajo “GLOBAL=YES RACLIST ONLY”, RACF no informa la necesidad de ejecutar el comando de REFRESH si se quiere que tome efecto una modificación, como sí lo hace en el caso de aquellas RACLISTeadas por comando.

68


5.19 - Opciones de logging para clases

Sintaxis: SETROPTS|SETR LOGOPTIONS(nivel(clase…)...)


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. Los posibles niveles son:

� ALLWAYS

� NEVER

� SUCCESSES

� FAILURES

� DEFAULT

El nivel especificado determina qué tipo de intentos de acceso se pretende registrar en SMF. Su significado es el siguiente:

� ALLWAYS indica que todo acceso a un recurso, exitoso o fallido, que involucre la consulta de un perfil de la clase, generará un registro de auditoría. ALLWAYS tiene prioridad sobre la configuración de auditoría que tenga cada perfil. Por lo tanto, aunque un determinado perfil tenga especificado únicamente FAILURES(READ) como opción de auditoría, si la clase se encuentra bajo LOGOPTIONS(ALLWAYS), se grabarán registros aún para los accesos exitosos (a cualquier nivel).

� NEVER establece que ningún acceso que involucre la consulta de un perfil de la clase generará un registro de auditoría. NEVER tiene prioridad sobre la configuración de auditoría a nivel de perfil. Por lo tanto, no se grabará ningún registro, aún cuando los perfiles tengan opciones de auditoría que indiquen lo contrario.

� SUCCESSES indica que se generará un registro auditoríapor cada acceso exitoso que involucre la consulta de un perfil de la clase. En este caso, este nivel de auditoría se agrega al que ya tiene especificado el perfil. Por ejemplo, si un perfil tiene especificado únicamente FAILURES(UPDATE) y la clase está bajo LOGOPTIONS(SUCCESSES), se generarán registros para todo acceso exitoso y los intentos fallidos de UPDATE (o superior).

� FAILURES determina que se generará un registro de auditoría por cada acceso fallido que involucre la consulta de un perfil de la clase. En este caso, al igual que para SUCCESSES, este nivel de auditoría se agrega al propio del perfil. Por ejemplo, si un perfil tiene especificado únicamente SUCCESS(UPDATE) y la clase está bajo LOGOPTIONS(FAILURES), se generarán registros para todo acceso fallido y todo intento exitoso de UPDATE (o superior).

� DEFAULT indica que el nivel de auditoría sobre un recurso estará dado por el establecido en su perfil protector.

Cada clase puede tener un único nivel de LOGOPTIONS. Por lo tanto, para cambiar el nivel de una determinada clase, basta con asignarle el nuevo.

El operando LOGOPTIONS afecta no solo a la clase especificada, sino también a todas aquellas otras que eventualmente compartan el mismo posit value.

En una base recién inicializada, todas las clases se encuentran bajo LOGOPTIONS(DEFAULT). Recomendamos mantener esta configuración, y controlar el nivel de auditoría a través de las opciones propias de los perfiles.

Una excepción son ciertas clases relacionadas con z/OS USS, que si bien no admiten perfiles, permiten controlar, a través de la SETROPTS, el nivel de auditoría sobre ciertos eventos (en algunos casos al

69


ponerlas bajo AUDIT, y en otros mediante LOGOPTIONS). Por ejemplo, la clase FSSEC permite auditar las modificaciones sobre los permisos de archivos y directorios del z/OS USS. Especificar LOGOPTIONS(ALLWAYS) para FSSEC podría ser, por lo tanto, una opción a considerar.

5.20 - Protección automática de datasets

Sintaxis: SETROPTS|SETR ADSP|NOADSP


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). En este caso, el listado de la SETROPTS muestra la leyenda: AUTOMATIC DATASET PROTECTION IS NOT IN EFFECT

Por el contrario, la opción ADSP en la SETROPTS indica que la “protección automática de datasets” está globalmente activa, pero solo será aplicada para los usuarios que tengan efectivamente el atributo ADSP. Por lo tanto, si ningún usuario tiene el atributo ADSP, las opciones ADSP|NOADSP a nivel de la SETROPTS resultan equivalentes.

En una base recién inicializada, se encuentra activa la opción ADSP. Debido a la ya comentada tendencia a utilizar exclusivamente perfiles genéricos de dataset, recomendamos cambiarla por NOADSP. Esto elimina de raíz la posibilidad de que algún usuario genere de manera automática perfiles discretos.

5.21 - Uso del ** en perfiles genéricos de dataset

Sintaxis: SETROPTS|SETR EGN|NOEGN


Opción sugerida: EGN

EGN significa Enhanced Generic Naming, 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 EGN|NOEGN afecta únicamente a la clase DATASET. El uso del ** en perfiles de recursos generales está siempre permitido y no guarda ninguna relación con este parámetro.

Como ya hemos señalado, el uso del ** hace realmente más cómoda la administración de perfiles genéricos de dataset, por lo cual recomendamos activar la opción EGN. En el caso de estar en efecto la opción NOEGN, 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). En cualquier caso, si se han definido perfiles conteniendo ** (con la opción EGN activa, naturalmente), debe tenerse cuidado en no cambiar con posterioridad a la opción NOEGN, ya que ello provocaría sin duda problemas y confusión en la protección de datasets.

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, se encuentra en efecto la opción NOEGN. Resulta conveniente modificar esta opción.

70


5.22 - Nombres reales de dataset

Sintaxis: SETROPTS|SETR REALDSN|NOREALDSN


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, se puede convertir el nombre real de un archivo antes de que sea pasado a RACF. Esto permite, por ejemplo, proteger archivos cuyos nombres reales no tengan una nomenclatura admitida por RACF.

La opción REALDSN establece que, tanto en los registros de SMF como en los mensajes de operador, se mostrará el nombre real del archivo, aún cuando el mismo haya sido modificado a los efectos del chequeo de autoridad. Por el contrario, si la opción en efecto es NOREALDSN, el nombre mostrado en ambos casos no será el real sino el modificado que recibe RACF.

A menos que exista una fuerte necesidad al respecto, no se aconseja de ninguna manera convertir los nombres de los archivos que se le comunican a RACF, ya que ello complica la administración.

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, se encuentra en efecto la opción NOREALDSN. Aconsejamos cambiar por la opción REALDSN, aún cuando esto resulta irrelevante si la organización, tal como recomendamos, no utiliza una “tabla de convención de nombres” o exits que modifiquen, con miras al chequeo de seguridad, el nombre real de los archivos.

5.23 - Opciones relativas a JES

Sintaxis: SETROPTS|SETR JES([BATCHALLRACF|NOBATCHALLRACF]

[EARLYVERIFY|NOEARLYVERIFY]

[XBMALLRACF|NOXBMALLRACF]

[NJEUSERID(userid)]

[UNDEFINEDUSER(userid)])


Opciones sugeridas: BATCHALLRACF, EARLYVERIFY, XBMALLRACF, usuarios por defecto

Existen varias opciones en la SETROPTS relativas a JES, que describimos brevemente a continuación:

BATCHALLRACF exige que todo job batch tenga una identidad válida. A tal efecto, caben las siguientes posibilidades:

� La tarjeta job contiene explícitamente usuario y password. Esta opción es poco recomendable, ya que debe evitarse la exposición de passwords en texto claro.

� Las credenciales se reciben propagadas, por ejemplo al utilizar el comando SUBMIT de TSO. Se trata de la opción más frecuente.

� La tarjeta job solo tiene especificado usuario, y quién submite tiene la autorización apropiada en la clase SURROGAT para ejecutar jobs en nombre del usuario de ejecución.

Si el job no tiene una identidad válida de RACF, entonces cancela.

Si NOBATCHALLRACF está en efecto, la ausencia de un usuario no impide que el job se ejecute. Naturalmente, es probable que encuentre problemas de autorización si trata de acceder a recursos

71


protegidos para los cuales ni la GLOBAL ni el UACC del perfil protector son suficientes para otorgar el acceso solicitado.

EARLYVERIFY hace referencia a un control de usuario, password y grupo que efectúa JES invocando a la SAF en caso de no recibir información propagada. Con las versiones actuales de JES esto se realiza siempre, independientemente de la codificación de este parámetro en la SETROPTS. Por lo tanto, EARLYVERIFY|NOEARLYVERIFY se ha convertido en una opción irrelevante.

XBMALLRACF es idéntico a BATCHALLRACF pero para jobs que se ejecutan bajo el Execution

Batch Monitor.

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. El valor por defecto en una base recién inicializada es ????????, el cual sugerimos conservar. En cualquier caso, si se desea cambiarlo, el usuario que se especifique no debe existir en la base de RACF.

La opción UNDEFINEDUSER establece el usuario que se asignará a los jobs locales que ingresen al sistema sin un usuario asociado. El valor por defecto en una base recién inicializada es ++++++++, el cual sugerimos conservar. En cualquier caso, si se desea cambiarlo, el usuario que se especifique no debe existir en la base de RACF.

En una base recién inicializada, se encuentran en efecto las opciones NOBATCHALLRACF, NOEARLYVERIFY y NOXBMALLRACF. Recomendamos activar los 3 tipos de control (aunque en el caso de EARLYVERIFY, es actualmente irrelevante). En el listado de la SETROPTS, las leyendas:

JES-BATCHALLRACF OPTION IS ACTIVE

JES-XBMALLRACF OPTION IS ACTIVE

JES-EARLYVERIFY OPTION IS ACTIVE

USER-ID FOR JES NJEUSERID IS : ????????

USER-ID FOR JES UNDEFINEDUSER IS : ++++++++

indican que los 3 tipos de control se encuentran activos y que se mantuvo el valor default para ambos usuarios.

5.24 - Protect-all

Sintaxis: SETROPTS|SETR PROTECTALL(FAILURES|WARNING)|NOPROTECTALL


Opción sugerida: PROTECTALL(FAILURES)

Se trata de una opción sumamente importante, que establece cómo se comportará RACF cuando se pretenda definir o acceder a archivos no protegidos por ningún perfil de dataset. Este parámetro solo afecta a la clase DATASET. Existen 3 seteos posibles, 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). Con esta configuración, los datasets “no protegidos” resultan inaccesibles, salvo en alguna de las situaciones siguientes:

� El usuario tiene el atributo SPECIAL a nivel de sistema. En este caso, si bien se autoriza el acceso, se envía un mensaje al usuario informando que el archivo se encuentra desprotegido. El usuario no puede, sin embargo, definir archivos desprotegidos.

� El acceso lo solicita una started task que está marcada como TRUSTED o PRIVILEGED. En este caso, se autoriza el acceso pero no se envía ningún mensaje informativo.

� Existe una entrada en la GLOBAL que autoriza el acceso.

72


PROTECTALL en WARNING funciona de manera similar al modo FAILURES, pero con una diferencia fundamental. RACF, en lugar de rechazar el pedido, lo autoriza y remite, tanto al usuario como al SYSLOG, un mensaje informando que archivo no se encuentra protegido. Se debe ser cuidadoso, ya que mientras RACF tiene PROTECTALL en modo WARNING, los archivos “no protegidos” pueden ser accedidos por cualquier usuario con el máximo nivel de autoridad. Sin embargo, esta opción resulta sumamente útil en las etapas iniciales de la construcción de la base de RACF, pues permite identificar e ir protegiendo paulatinamente los archivos en uso que se encuentran desprotegidos, sin causar interrupciones en las tareas. Luego de un tiempo prudencial, pasado el cual se estima que ya se han identificado todos los archivos en uso, se debe cambiar al modo FAILURES.

NOPROTECTALL implica que cualquier usuario puede acceder a archivos “no protegidos” con el máximo nivel de autoridad, así como también definir nuevos archivos desprotegidos. A diferencia del modo WARNING, ningún mensaje de alerta es generado. Esta opción es totalmente desaconsejada para un entorno productivo.

En nuestro ejemplo, la leyenda: PROTECT-ALL IS ACTIVE, CURRENT OPTIONS:

PROTECT-ALL FAIL OPTION IS IN EFFECT

indica que está activa la opción PROTECTALL en modo FAILURES.

En una base recién inicializada, se encuentra vigente la opción NOPROTECTALL. Se recomienda la opción PROTECTALL en modo FAILURES, que robustece notablemente la seguridad del sistema.

5.25 - Protección de archivos en cartucho

Sintaxis: SETROPTS|SETR TAPEDSN|NOTAPEDSN


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, de manera similar a como lo hace para datasets en disco. Existe una importante relación entre esta opción y la clase TAPEVOL, que debe estudiarse cuidadosamente para comprender exactamente su alcance. Sin embargo, no ahondaremos en ello en la presente guía.

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). De todos modos, si el chequeo en la clase DATASET está inhibido, pueden protegerse globalmente los volúmenes mediante perfiles en la clase TAPEVOL.

En nuestro ejemplo, se encuentra establecida la opción NOTAPEDSN, como muestra la siguiente leyenda en el listado de la SETROPTS: TAPE DATA SET PROTECTION IS INACTIVE

En una base recién inicializada, se encuentra en efecto la opción NOTAPEDSN. Recomendamos NOTAPEDSN, 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.

5.26 - Período de retención para archivos en cartucho

Sintaxis: SETROPTS|SETR RETPD(valor)


Opción sugerida: depende de la organización

73


El período de retención, solo aplicable a datasets en cartucho, determina la cantidad de días en que la protección permanecerá vigente, contados desde el día de creación del archivo. El valor establecido en la SETROPTS se aplicará por defecto, siempre que no se establezca un valor específico para el archivo. Se puede codificar cualquier valor comprendido entre 0 y 65533, 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. En caso contrario, resulta irrelevante. Si se activa TAPEDSN, y no se especifica un RETPD, el valor por defecto es 0.

5.27 - Borrado físico de archivos

Sintaxis: SETROPTS|SETR ERASE(ALL|SECLEVEL(nivel)|NOSECLEVEL)|NOERASE


Opción sugerida: ERASE(NOSECLEVEL)

En general, cuando se elimina un archivo en disco, el sistema borra la entrada correspondiente de la VTOC del volumen dónde reside, al mismo tiempo que lo descataloga (o sea, elimina su entrada del catálogo dónde se esté catalogado). El espacio ocupado por el archivo queda entonces disponible para un futuro dataset, o la extensión de uno existente. Sin embargo, hasta que efectivamente se grabe allí nueva información, los datos del archivo deleteado siguen presentes, solo que no resultan accesibles por los medios habituales.

Existe la posibilidad de tomar una medida de seguridad adicional, que garantice la irrecuperabilidad de los datos luego del borrado lógico del archivo, que consiste en físicamente sobrescribirlo con ceros binarios. Sin embargo, esto resulta costoso, y puede degradar la performance, por lo cual solo estaría justificado para el caso de información altamente sensible.

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). Veremos a continuación las distintas opciones posibles:

ALL establece que se deben borrar físicamente todos los archivos que se borren, independientemente de lo que indique el campo ERASE del perfil protector. Esto incluye también a los datasets temporarios. Se trata de una medida de seguridad extrema, que realmente no se justifica en absoluto y puede impactar negativamente en la performance del sistema.

ERASE(SECLEVEL(nivel)) indica que se debe proceder al borrado físico de todos aquellos archivos que se deletean y cuyo perfil protector tenga un SECLEVEL (security level) mayor o igual al especificado. En este caso, también resulta irrelevante el valor del campo ERASE del perfil de dataset. Si el perfil protector tiene especificado ERASE=YES pero su SECLEVEL es inferior al valor de la SETROPTS, el archivo no es borrado físicamente al ser deleteado. Como no aconsejamos, para no complicar la administración, el uso de “niveles de seguridad”, no recomendamos tampoco la implementación de esta opción.

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, el factor determinante para esta decisión pasa a ser el valor del campo ERASE del perfil. Recomendamos establecer esta opción, y únicamente codificar ERASE=YES para perfiles de dataset que protejan archivos altamente confidenciales. Si se especifica ERASE sin ningún parámetro, el valor que asume por defecto es NOSECLEVEL.

En nuestro ejemplo, ésta es la opción establecida, como lo muestra la leyenda: ERASE-ON-SCRATCH IS ACTIVE, CURRENT OPTIONS:

ERASE-ON-SCRATCH BY SECURITY LEVEL IS INACTIVE

74


NOERASE indica que en ningún caso se procederá al borrado físico de los archivos, independientemente del valor del campo ERASE del perfil protector. NOERASE es el valor que se encuentra vigente en una base de RACF recién inicializada.

5.28 - Archivos de un único calificador

Sintaxis: SETROPTS|SETR PREFIX(grupo)|NOPREFIX


Opción sugerida: NOPREFIX

Si la opción NOEGN se encuentra activa, RACF no permite proteger archivos que tengan un único calificador. En tal caso, si la organización tiene tales archivos, existe la posibilidad de protegerlos especificando un PREFIX en la SETROPTS.

Si la opción EGN está activa, el dataset ARCH1 puede protegerse por el perfil genérico ARCH1.**, por lo cual no tiene sentido especificar un PREFIX en la SETROPTS.

La opción PREFIX(grupo) establece un prefijo que se antepondrá como HLQ, solo a los efectos del chequeo por parte de RACF, para aquellos archivos que tengan un único calificador. El valor especificado en el operando PREFIX debe ser un grupo existente en la base de RACF, y no deben existir ni archivos ni perfiles de dataset cuyo HLQ sea ese grupo.

NOPREFIX no establece ningún prefijo. Como recomendamos tener la opción EGN activa, sugerimos asimismo establecer NOPREFIX. En cualquier caso, no parece conveniente hacer uso de archivos que tengan un único calificador, para evitar este tipo de disquisiciones. Esta es la opción vigente en nuestro ejemplo, como lo muestra la leyenda: SINGLE LEVEL NAMES NOT ALLOWED

NOPREFIX es asimismo el valor que se encuentra en efecto en una base de RACF recién inicializada.

5.29 - Lista de grupos

Sintaxis: SETROPTS|SETR GRPLIST|NOGRPLIST


Opción sugerida: GRPLIST

GRPLIST establece que, para determinar la autoridad de un usuario sobre un recurso, 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). Con esta opción activa, el “grupo de conexión”, a los efectos del chequeo de autoridad, se vuelve básicamente irrelevante. En consecuencia, el usuario no debe preocuparse por el grupo que especifica en la pantalla de logon a las aplicaciones.

Es la opción ampliamente preferida en la actualidad, ya que simplifica la tarea al usuario, sin resignar en absoluto aspectos de seguridad del sistema.

En nuestro ejemplo, GRPLIST se encuentra en efecto, como se deduce de la leyenda siguiente: LIST OF GROUPS ACCESS CHECKING IS ACTIVE

Si la opción NOGRPLIST está activa, entonces solo el “actual grupo de conexión” del usuario es tenido en cuenta por RACF en el proceso de chequeo de autoridad.

Antiguamente no existía la opción GRPLIST, por lo que considero que se mantiene la posibilidad de establecer NOGRPLIST únicamente para mantener una compatibilidad hacia atrás, ya que realmente presenta varios inconvenientes y ninguna ventaja evidente.

NOGRPLIST es la opción que se encuentra en efecto en una base de RACF recién inicializada.

75


5.30 - Revocación automática por inactividad

Sintaxis: SETROPTS|SETR INACTIVE(valor)|NOINACTIVE


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.

El chequeo que lleva a cabo RACF es el siguiente: Cada vez que un usuario se loguea a alguna aplicación (TSO, CICS, IMS, etc.), o se inicia la ejecución de un job, RACF compara la fecha actual del sistema con la fecha que figura en el campo LAST-ACCESS del perfil del usuario. Si la diferencia entre ambas fechas excede el valor especificado para revocación automática por inactividad en la SETROPTS, entonces RACF revoca al usuario. Recordemos que el campo LAST-ACCESS del perfil del usuario puede modificarse, no solo mediante el logon efectivo del usuario, sino también en otras circunstancias, como ya viéramos en el capítulo de administración de usuarios.

RACF revoca al usuario por inactividad cuando efectivamente intenta acceder al sistema. Por ejemplo, si el parámetro INACTIVE especifica 30 días y un usuario lleva 31 días de inactividad, hasta tanto no intente ingresar no será efectivamente revocado. Podríamos decir que tal usuario se encuentra “pendiente de revocación”.

Para los usuarios que nunca ingresaron al sistema (el comando LISTUSER muestra LAST-ACCESS = UNKNOWN), la inactividad se calcula en relación a la fecha de creación.

En nuestro ejemplo, el valor fijado es de 40 días, tal cual lo muestra la siguiente leyenda: INACTIVE USERIDS ARE BEING AUTOMATICALLY REVOKED AFTER 40 DAYS.

NOINACTIVE establece que RACF no revocará usuarios automáticamente por inactividad. Esta es la opción vigente en una base recién inicializada.

Recomendamos especificar la opción INACTIVE, con una cantidad que sea adecuada a las necesidades de la organización. Un valor entre 30 y 60 días suele ser razonable.

5.31 - Modelización de perfiles de dataset

Sintaxis: SETROPTS|SETR MODEL([GDG|NOGDG] [GROUP|NOGROUP] [USER|NOUSER])|NOMODEL



Mediante el operando MODEL, se establece en qué casos se desea utilizar la modelización de perfiles de dataset. Esto permite que nuevos perfiles, al ser definidos, tomen las características de un “perfil modelo” existente.

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. Recomendamos la opción NOGDG y proteger todos los GDG-datasets mediante un único perfil genérico.

MODEL(NOGDG) indica que RACF no tendrá un tratamiento especial para los GDG-datasets, sino que los tratará del mismo modo que a cualquier otro archivo.

MODEL(GROUP) establece que cada vez que se defina un “perfil de dataset de grupo”, RACF examirará el perfil del grupo para ver si tiene especificado un perfil modelo. En caso afirmativo, el nuevo perfil de dataset será creado en base al modelo existente.

76


MODEL(NOGROUP) indica que no se aplicarán modelos para “perfiles de dataset de grupo”, aún cuando el perfil del grupo correspondiente tenga un perfil modelo especificado.

MODEL(USER) indica que cada vez que se defina un “perfil de dataset de usuario”, RACF examinará el perfil del usuario para ver si tiene especificado un perfil modelo. En tal caso, el nuevo perfil de dataset será creado en base al modelo existente.

MODEL(NOUSER) indica que no se aplicarán modelos para “perfiles de dataset de usuario”, aún cuando el perfil del usuario correspondiente tenga un perfil modelo especificado.

En nuestro ejemplo, establecimos que únicamente se aplique la modelización para “perfiles de dataset de usuario”, tal cual indica la leyenda siguiente: DATA SET MODELLING NOT BEING DONE FOR GDGS.

USER DATA SET MODELLING IS BEING DONE.

GROUP DATA SET MODELLING NOT BEING DONE.

NOMODEL establece que no se aplicará modelización de perfiles de dataset en ninguno de los 3 casos (GDG, GROUP y USER). Esta es la opción en efecto en una base recién inicializada.

5.32 - Opciones relativas a PASSWORD

Sintaxis: SETROPTS|SETR PASSWORD([HISTORY(valor)|NOHISTORY]

[INTERVAL(valor)]

[MINCHANGE(valor)]

.[MIXEDCASE)|NOMIXEDCASE]

[REVOKE(valor)|NOREVOKE]

[RULEn(LENGTH(min:max) tipo(posición))|NORULEn|NORULES]

[WARNING(valor)|NOWARNING]


Opciones sugeridas: HISTORY(15), INTERVAL(30), MINCHANGE(1), MIXEDCASE, REVOKE(5) LLLLLLLL, WARNING(5)

La password de un usuario se almacena en su perfil, no en texto claro sino encriptado. Este campo no es visible en la salida del comando LISTUSER. Tampoco está presente en la bajada plana de la base que se obtiene a través del utilitario IRRDBU00. Sin embargo, debe destacarse que RACF no encripta la password propiamente dicha. El valor guardado es el resultado de encriptar, vía DES (Data Encryption

Standard), el identificador de usuario, usando como clave de encriptación su password. En el momento de autenticación, RACF reencripta el usuario con la password recibida, y si el valor resultante coincide con el almacenado la autenticación es exitosa. Este mecanismo tiene una consecuencia interesante: 2 usuarios con idéntica password tendrán distintos valores guardados en la base de RACF. Por lo tanto, crackear la password de un usuario no significa que se haya igualmente crackeado a otros que puedan eventualmente tener su misma password.

Vamos a describir a continuación en detalle el significado de cada uno de los suboperandos del operando PASSWORD.

Historial

HISTORY establece la cantidad de passwords previas del usuario que se almacenan en la base con el objeto de que no las pueda reusar. Esto es -suponiendo que se tenga esta opción en 15, como en nuestro ejemplo-, un usuario, al cambiar su password (ya sea voluntariamente, o porque RACF se lo exige), no podrá especificar, ni la actual, ni ninguna de las últimas 15 que haya utilizado. El valor del operando HISTORY debe estar comprendido entre 1 y 32.

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

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.

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 A Caracteres alfabéticos en mayúscula + caracteres nacionales (#, &, @).

CONSONANT C Consonantes en mayúscula.

ALPHANUM L Caracteres alfabéticos en mayúscula + caracteres nacionales (#, &, @) + caracteres numéricos (0 al 9).

NUMERIC N Caracteres numéricos (0 al 9)

VOWEL V Vocales en mayúscula: A, E, I, O, U.

NOVOWEL W Consonantes en mayúscula + caracteres nacionales (#, &, @) + caracteres numéricos (0 al 9).

MIXEDCONSONANT c Consonantes en mayúscula o minúscula.

MIXEDNUM m Caracteres alfabéticos en mayúscula o minúscula + caracteres nacionales (#, &, @) + caracteres numéricos (0 al 9).

MIXEDVOWEL v Vocales en mayúscula o minúscula: A, E, I, O, U, a, e, i, o, u.

NATIONAL $ 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.

80


Los tipos c, m y v, que involucran caracteres alfabéticos en minúsculas, solo deben usarse si la opción MIXEDNUM está en efecto.

La longitud admisible de la password para cada regla se establece a través del parámetro LENGHT(min:max), dónde min indica la longitud mínima y max la máxima (max puede ser a lo sumo igual a 8). Naturalmente, min debe ser menor o igual a max. Si se omite max, se asume max=min por lo que la regla impone una longitud exacta.

Asimismo, para cada regla, se establece qué tipo de carácter es admisible en cada posición. 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; tener caracteres alfanuméricos de la posición 2 a la 6 inclusive, y un carácter “no vocal” en la última posición. En la posición 7, no existiendo ninguna exigencia explícita, cualquier carácter alfanumérico es aceptado. Por ejemplo, la password T4RUJY4@ cumple con la regla establecida. Por el contrario, YHGTRF8 no la satisface, ya que entre las posiciones 2 y 6 no hay 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.

De todos modos, no recomendamos complicarse fijando reglas sofisticadas que seguramente serán frecuentemente olvidadas por lo usuarios. Es conveniente, en la medida de lo posible, habilitar la opción MIXEDCASE. En caso de no poner en práctica esta opción, la única regla establecida en nuestra SETROPTS de ejemplo suele ser satisfactoria desde el punto de vista de seguridad. INSTALLATION PASSWORD SYNTAX RULES:

RULE 1 LENGTH(6:8) LLLLLLLL

Observaciones:

� Cuando se otorga una password expirada (lo cual sucede siempre que un administrador la otorga, salvo que especifique explícitamente lo contrario), la misma no tiene necesidad de satisfacer las reglas sintácticas. En cambio, si se otorga una clave no expirada, entonces debe cumplir con las reglas globales de la organización fijadas en la SETROPTS.

� Los eventuales cambio en las reglas para passwords de la SETROPTS toman efecto inmediatamente. Sin embargo, esto no significa que un usuario cuya password vigente no cumple con las nuevas reglas esté forzado a cambiarla de inmediato. Solo cuando cambie voluntariamente su password, o sea forzado por RACF a hacerlo por haberse excedido el tiempo de validez, deberá establecer una nueva que cumpla con las reglas actuales.

En una base recién inicializada no hay ninguna regla establecida. Como ya indicáramos, una única regla estableciendo passwords de 6 a 8 caracteres alfanuméricos es una opción simple y por lo general satisfactoria.

Warning

Existe la posibilidad de informar con determinada anticipación a un usuario de TSO (en el momento del logon), o en el log del job en el caso de un trabajo batch, que su password está próxima a vencer y tendrá que cambiarla. La cantidad de días antes del vencimiento en que el usuario recibirá los mensajes se establece con el parámetro WARNING. El valor especificado debe estar comprendido entre 1 y 255.

En la práctica, no resulta una opción de gran utilidad. De todos modos, ya que está disponible, recomendamos usarla. No debe fijarse un valor superior al especificado en INTERVAL, ya que ello provocaría mensajes de advertencia al inicio de cada sesión, lo cual sería sumamente molesto. Un valor de 5 días resulta razonable, como tenemos en nuestro ejemplo, tal cual indica la siguiente leyenda: PASSWORD EXPIRATION WARNING LEVEL IS 5 DAYS.

81


NOWARNING, que es la opción por defecto en una base recién inicializada, indica que no se avisará anticipadamente a los usuarios sobre el vencimiento de su password.

5.33 - Passwords del RVARY

Sintaxis: SETROPTS|SETR RVARYPW([SWITCH(password)] [STATUS(password)])


Opción sugerida: establecer passwords para ambos comandos (no dejar el valor default)

No analizaremos en este capítulo el comando RVARY, que merece un estudio detallado que haremos más adelante. Tanto la función SWITCH como ACTIVE|INACTIVE del comando RVARY exigen el ingreso de una password para ejecutarse exitosamente. Estas passwords, una para SWITCH (operando SWITCH) y otra para STATUS (operando ACTIVE|INACTIVE) se especifican en la SETROPTS. Naturalmente, no se muestran en el listado.

Si no se establecen estas passwords, el valor por defecto es la palabra YES. Es absolutamente recomendable que la organización fije passwords para estos comandos, y las almacene bajo sobre en algún lugar seguro.

En nuestro ejemplo se han establecido ambas passwords, tal cual se desprende de la siguiente leyenda que aparece en el listado de la SETROPTS: INSTALLATION DEFINED RVARY PASSWORD IS IN EFFECT FOR THE SWITCH FUNCTION.

INSTALLATION DEFINED RVARY PASSWORD IS IN EFFECT FOR THE STATUS FUNCTION.

En una base recién inicializada, las claves en efecto son las default, o sea YES, en ambos casos.

5.34 - Opciones de auditoría relativas a security levels y security labels

Sintaxis: SETROPTS|SETR [SECLABELAUDIT|NOSECLABELAUDIT]

[SECLEVELAUDIT(nivel)|NOSECLEVELAUDIT]


Opciones sugeridas: NOSECLABELAUDIT y NOSECLEVELAUDIT

Ambas opciones solo cobran sentido en organizaciones que usen security levels, categories o security

labels.

SECLABELAUDIT y SECLEVELAUDIT incorporan un nivel extra de auditoría, basado en security

labels y security levels. Ambas opciones requieren el atributo AUDITOR a nivel de sistema para ser modificadas.

Como ya hemos comentado, no consideramos necesario adoptar este nivel extra de seguridad, por lo cual recomendamos tener estas opciones inactivas. Este es el default en una base recién inicializada, y así se encuentran en nuestro ejemplo, como se deduce de la siguiente leyenda: SECLEVELAUDIT IS INACTIVE

SECLABEL AUDIT IS NOT IN EFFECT

5.35 - Restricción para la creación de perfiles más específicos que perfiles existentes

Sintaxis: SETROPTS|SETR GENERICOWNER|NOGENERICOWNER



82


GENERICOWNER limita la posibilidad de crear perfiles más específicos que otros ya existentes, en cualquier clase de recursos generales, con excepción de la clase PROGRAM.

Si la opción GENERICOWNER está en efecto, un usuario solo puede crear un perfil más específico que uno existente si, además de tener autoridad para definir perfiles en la clase (ver atributo CLAUTH), cumple alguna de las siguientes condiciones:

� Tiene el atributo SPECIAL a nivel de sistema.

� Es el owner del perfil inmediatamente superior.

� Tiene el atributo SPECIAL a nivel de un grupo que tenga al perfil inmediatamente superior dentro de su campo de acción.

GENERICOWNER solo limita la creación de perfiles cuando existe un perfil menos específico que el que se pretende definir. 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, suponiendo que la clase en cuestión la tenga.

A modo de ejemplo, supongamos la siguiente situación:

o El usuario JEF2574 tiene el atributo CLAUTH(OPERCMDS) y no tiene el atributo SPECIAL, ni a nivel de sistema ni a “nivel de ningún grupo”.

o OPERA es un grupo de RACF.

o Los perfiles existentes en la clase OPERCMDS, con sus respectivos owner, están dados por la siguiente tabla:

Perfil Owner

MVS.** OPERA

MVS.START.** JEF2574

JES2.** JEF2574

En esta situación, el usuario JEF2574 podría definir los perfiles JES2.CANCEL.** y MVS.START.STC.**, pues en ambos casos es el owner del perfil genérico existente que más se ajusta al perfil que está definiendo (JES2.** y MVS.START.**, respectivamente). También podría definir el perfil RACF.**, pues no existe ningún perfil menos específico. Sin embargo, no podría definir el perfil MVS.STOP.**, ya que no es el owner de MVS.** y tampoco tiene el atributo SPECIAL a nivel de sistema o a nivel de un grupo que tenga al perfil MVS.** dentro de su campo de acción.

NOGENERICOWNER no establece la limitación anterior para la creación de perfiles más específicos que otros existentes. Es la opción en efecto en una base recién inicializada, y es asimismo la vigente en nuestro ejemplo tal como indica la leyenda: GENERIC OWNER ONLY IS NOT IN EFFECT

5.36 - Otras opciones vinculadas a security levels y security labels

Sintaxis: SETROPTS|SETR [COMPATMODE|NOCOMPATMODE]

[MLACTIVE[(FAILURES|WARNING)]|NOMLACTIVE]

[MLQUIET|NOMLQUIET]

[MLS[(FAILURES|WARNING)]|NOMLS]

[MLSTABLE|NOMLSTABLE]

[SECLABELCONTROL|NOSECLABELCONTROL]


83


Opciones sugeridas: NOCOMPATMODE, NOMLACTIVE, NOMLQUIET, NOMLS, NOMLSTABLE NOSECLABELCONTROL

Estas opciones, excepto MLQUIET|NOMLQUIET, solo tienen sentido en organizaciones que usen security labels. No vamos a analizar su significado en esta guía, ya que no nos ocupamos de analizar este nivel extra de seguridad.

La opción MLQUIET, mientras se encuentra vigente, permite únicamente a las started task, los operadores de consola y los usuarios con atributo SPECIAL loguearse, ejecutar jobs o acceder a recursos protegidos. Es una opción que reduce al mínimo la actividad, y solo tendría sentido para alguna tarea específica de mantenimiento. En cualquier caso, es extremadamente raro que deba recurrirse a ella. NOMLQUIET no establece las citadas restricciones.

En una base recién inicializada, todas estas opciones están en NO, al igual que en nuestro ejemplo, tal cual se ve en las siguientes leyendas del listado de la SETROPTS: SECLABEL CONTROL IS NOT IN EFFECT

(...)

COMPATIBILITY MODE IS NOT IN EFFECT

MULTI-LEVEL QUIET IS NOT IN EFFECT

MULTI-LEVEL STABLE IS NOT IN EFFECT

NO WRITE-DOWN IS NOT IN EFFECT

MULTI-LEVEL ACTIVE IS NOT IN EFFECT

5.37 - Acceso a datasets no catalogados

Sintaxis: SETROPTS|SETR CATDSNS(FAILURES|WARNING)|NOCATDSNS


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”. Este seteo afecta igualmente a datasets no catalogados residentes en cartucho, si se habilitó para ellos el control en la clase DATASET mediante la apropiada configuración el miembro DEVSUPxx de la PARMLIB.

CATDSNS en FAILURES indica que RACF no permitirá acceder a archivos que no se encuentren catalogados (o temporarios generados por el sistema). Con esta configuración, estos datasets resultan inaccesibles, salvo en alguna de las situaciones siguientes:

� Si un job define un archivo y no lo cataloga, puede accederlo mientras dure la ejecución.

� Archivos protegidos por perfiles discretos pueden ser accedidos aún cuando no estén catalogados, siempre y cuando el perfil protector lo permita.

� Para datasets no catalogados y no protegidos discretamente, se construye un recurso de nombre ICHUNCAT.dsname, dónde dsname es el nombre del archivo (solo los 30 primeros caracteres se consideran). RACF chequea a continuación la autoridad del usuario sobre este recurso en la clase FACILITY, y si es READ (o superior), entonces no rechaza el acceso por “dataset no catalogado”.

� Si el usuario tiene el atributo SPECIAL a nivel de sistema, no se rechaza el acceso por “dataset no catalogado”, pero se envía al usuario (y al SYSLOG) un mensaje informando que el archivo no está catalogado. Se graba asimismo un registro de SMF reflejando el evento.

� Si el acceso lo solicita una started task definida como TRUSTED o PRIVILEGED, entonces no se rechaza el requerimiento por “dataset no catalogado”.

En los casos mencionados, la condición de “no catalogado” del archivo no impide el acceso, pero el usuario debe de todos modos tener acceso al dataset a través de los canales habituales.

84


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

CATDSNS FAIL OPTION IS IN EFFECT

CATDSNS en WARNING funciona de manera similar al modo FAILURES, pero con una diferencia fundamental: RACF, en lugar de rechazar el pedido por “dataset no catalogado”, continúa con su chequeo habitual pero envía, tanto al usuario como al SYSLOG, un mensaje informando que el archivo no se encuentra en catálogo. Se graba asimismo un registro de SMF reflejando el evento. Esta opción resulta útil en las etapas iniciales de la construcción de un sistema, ya que permite identificar los archivos en uso que no se encuentran catalogados, sin causar interrupciones en las tareas por problemas de falta de autoridad. Luego de un tiempo prudencial, se sugiere cambiar al modo FAILURES.

NOCATDSNS establece que RACF no rechazará el acceso a un archivo por no estar catalogado. Esta es la opción vigente en una base recién inicializada.

5.38 - Máximo global y default para la validez de la clave de una sesión

Sintaxis: SETROPTS|SETR SESSIONINTERVAL(n)|NOSESSIONINTERVAL



SESSIONINTERVAL(n) establece el máximo valor para el operando INTERVAL, medido en días, que se puede especificar en el segmento SESSION en un perfil de la clase APPCLU. Este valor resulta también el defecto cuando se define un nuevo perfil en esta clase con segmento SESSION pero no se codifica INTERVAL. El valor n debe estar comprendido entre 1 y 32767 inclusive.

En una base recién inicializada, el valor por defecto es 30, que es asimismo el vigente en nuestro ejemplo, lo cual se desprende de la siguiente leyenda: PARTNER LU-VERIFICATION SESSIONKEY INTERVAL MAXIMUM/DEFAULT IS 30 DAYS.

La opción NOSESSIONINTERVAL no establece ningún máximo global.

5.39 - Auditoría de transacciones APPC

Sintaxis: SETROPTS|SETR APPLAUDIT|NOAPPLAUDIT



APPLAUDIT habilita globalmente la auditoría para transacciones APPC (registra inicio y fin). Sin embargo, para que efectivamente se grabe esta información, debe auditarse el correspondiente perfil de la clase APPL.

NOAPPLAUDIT inhabilita globalmente este tipo de auditoría. 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. Esta es la opción por defecto en una base recién inicializada, y es asimismo la vigente en nuestro ejemplo, como muestra la leyenda: APPLAUDIT IS NOT IN EFFECT

85


5.40 - Opción ADDCREATOR

Sintaxis: SETROPTS|SETR ADDCREATOR|NOADDCREATOR


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.

En la práctica, más que una ventaja resulta una molestia, ya que es sumamente frecuente que el creador del perfil no necesite acceso a los recursos que protege. Por lo tanto, recomendamos la opción NOADDCREATOR, que no coloca automáticamente al usuario creador del perfil en la lista de acceso.

En una base recién inicializada, la opción en efecto es NOADDCREATOR. En nuestro ejemplo, esta es la opción elegida, como se ve en la leyenda: ADDCREATOR IS NOT IN EFFECT

5.41 - Lenguaje

Sintaxis: SETROPTS|SETR LANGUAJE([PRIMARY(lenguaje)] [SECONDARY(lenguaje)])


Opción sugerida: ENU para ambos

A nivel de la SETROPTS, pueden establecerse los lenguajes globales que usará el sistema (uno primario y otro secundario, que pueden coincidir o ser diferentes). Naturalmente, solo pueden especificarse lenguajes que estén disponibles en la instalación, para lo cual debe consultarse a los responsables del sistema operativo.

El valor por defecto para ambos lenguajes, en una base recién inicializada, viene identificado por la sigla ENU, que significa inglés americano. Esta es la opción vigente en nuestro ejemplo, tal cual muestra la leyenda: PRIMARY LANGUAGE DEFAULT : ENU

SECONDARY LANGUAGE DEFAULT : ENU

5.42 - Comandos de REFRESH

Los comandos de RACF que definen, modifican o borran perfiles, actúan directamente sobre la base RACF (residente en disco). Sin embargo, con el propósito de optimizar la performance, reduciendo lo más posible la cantidad de operaciones de I/O sobre la base –muy costosas–, en muchos casos RACF carga información en memoria virtual y la reutiliza tantas veces como le sea requerida, evitando extraerla nuevamente de la base. Esto mejora sensiblemente el tiempo de respuesta, ya que es muchísimo más rápido el acceso a memoria que a disco. Ahora bien, como contrapartida, toda vez que se modifique información de un perfil que RACF mantiene en memoria, será necesario una actualización. Esta operación, conocida como REFRESH (refrescamiento), se logra ejecutando el comando SETROPTS con los operandos adecuados. No existe un único comando de REFRESH, ya que el mismo 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.

Clases RACLISTeadas

Una clase puede estar RACLISTeada mediante alguna de las siguientes maneras:

86


• A través del comando “SETROPTS RACLIST(clase)”, en cuyo caso aparece bajo RACLIST en el listado de la SETROPTS.

• Por una aplicación, en cuyo caso aparece bajo “GLOBAL=YES RACLIST ONLY” en el listado de la SETROPTS.

En ambos casos, RACF carga en un data space en memoria la información de todos los perfiles (discretos y genéricos) de la clase. 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.

Si la clase RACLISTeada tiene una clase agrupadora, RACF realiza una operación de merge cuando carga en memoria los perfiles, con el objeto de combinar adecuadamente la información de ambas clases –la de miembros y la agrupadora–. En estos casos, por lo tanto, la información en el data space es una versión procesada de los perfiles existentes en la base.

Toda modificación que se efectúe sobre perfiles (discretos o genéricos) de una clase RACLISTeada, o sobre aquellos de su eventual clase agrupadora, solo tomarán efecto una vez que se haya refrescado la información del data space, para lo cual es necesario ejecutar el comando:

SETROPTS RACLIST(clase) REFRESH

La clase especificada no debe ser una clase agrupadora. Si se modificó información de perfiles de una clase agrupadora (y la clase de miembros asociada se encuentra RACLISTeada), el comando de REFRESH debe ejecutarse siempre sobre la clase de miembros.

Este comando genera un nuevo data space. Hasta tanto concluya su creación, las aplicaciones seguirán usando la información del antiguo. Una vez que el comando se complete exitosamente, las distintas aplicaciones empezarán inmediatamente a apuntar al nuevo data space, y el antiguo es borrado.

Es importante destacar que no solo se refresca la información de los perfiles de la clase especificada, sino también de todas aquellas otras clases que eventualmente compartan el mismo posit value.

Autoridad requerida

Para ejecutar el comando anterior sobre una determinada clase, el usuario debe satisfacer alguna de las siguientes condiciones:

� Tener el atributo SPECIAL a nivel de sistema

� Tener el atributo AUDITOR a nivel de sistema

� Tener CLAUTH sobre la clase

Clases no RACLISTeadas que tienen perfiles genéricos

Si una clase no se encuentra RACLISTeada, pero tiene perfiles genéricos definidos, estos se cargan en memoria cuando son referenciados (en un espacio común, en algunos casos, o en cada address space, en otros). Por lo tanto, 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, por ejemplo, información del perfil cargada en su propia memoria). En tal caso, 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, el usuario debe satisfacer alguna de las siguientes condiciones:

87


� Tener el atributo SPECIAL, AUDITOR u OPERATIONS, ya sea a nivel de sistema o a nivel de grupo.

� Tener CLAUTH sobre la clase.

Observación:

Para una clase no GENLISTeada, el comando “SETROPTS GENERIC(clase) REFRESH” se ejecuta casi instantáneamente. Esto se debe a que RACF simplemente modifica un contador, residente en memoria y específico de la clase. Sin embargo, 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. En efecto, éstos saben qué valor tenía el contador la última vez que se cargaron en su memoria de perfiles de la clase y, antes de reusarlos, verifican que el contador no haya cambiado. Si lo hizo, los perfiles son invalidados y será necesario volver a cargarlos. En consecuencia, se trata de un comando de ejecución inmediata pero que puede resultar costoso en términos de procesamiento, si muchos address space tienen almacenados perfiles de la clase.

Un ejemplo típico es la clase DATASET. El comando “SETROPTS GENERIC(DATASET) REFRESH” finaliza inmediatamente, pero su impacto negativo en la performance puede ser importante. Si un usuario de TSO reporta que intentó acceder a un dataset y no pudo por falta de autoridad, en caso de que se le otorgue la autorización, será normalmente preferible pedirle que vuelva iniciar sesión antes que ejecutar el comando de REFRESH.

Clase GLOBAL

La información de las tablas de la clase GLOBAL se encuentra siempre cargada en memoria. Toda modificación, para tomar efecto, requiere la ejecución de un comando de REFRESH. Si se tiene una clase bajo GLOBAL en la SETROPTS, y se modifica información de la correspondiente tabla, 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, el usuario debe satisfacer alguna de las siguientes condiciones:


� Tener CLAUTH sobre la clase.

Clase PROGRAM

La clase PROGRAM es muy particular en varios aspectos, y la forma de refrescarla es uno de ellos. Si se efectúan modificaciones en sus perfiles, 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, el usuario debe satisfacer alguna de las siguientes condiciones:


� Tener CLAUTH en la clase PROGRAM.

88


6 - PROTECCIÓN DE RECURSOS GENERALES

6.1 - Recursos generales y perfiles

Todos los recursos que no sean archivos son considerados recursos generales, y su protección se establece a través de perfiles en clases de recursos generales. Todas las clases, provistas por IBM o definidas por la organización, con excepción de USER, GROUP y DATASET, son consideradas clases de recursos generales.

No debe confundirse un “recurso general” con un “perfil de recursos generales”, del mismo modo que no debe confundirse un dataset con un perfil de dataset..

El nombre de un recurso general lo establece la aplicación o subsistema correspondiente, y simboliza un objeto -tangible o intangible- de muy variada naturaleza. Posibles ejemplos son: discos; comandos de operador; procedimientos de logon a TSO o la facilidad de acceder a cierto archivo no catalogado. La aplicación, al derivar a RACF el requerimiento de chequeo de autoridad, debe informar a qué clase de recursos generales (definida en la CDT) pertenece el recurso.

Un perfil de recursos generales, en cambio, es una entidad que existe únicamente en la base de RACF. Se crea, modifica o borra a través de comandos. Es una regla usada para controlar el acceso a los recursos propiamente dichos. Está constituido por un segmento base, también llamado “segmento de RACF”, más eventuales segmentos no base, que varían de acuerdo a la clase a la que pertenece el perfil.

Por ejemplo, el comando de operador “START PROC1”, que inicia una started task llamada PROC1, se asocia con el nombre de recurso MVS.START.STC.PROC1 en la clase OPERCMDS, que a su vez podría estar protegido por el perfil genérico MVS.START.**.

Los nombres de los recursos generales son muy variados, al igual que los de los perfiles que los protegen. Toda clase definida en la CDT tiene especificado el tipo de caracteres que admite y la longitud máxima permitida. En cualquier caso, los nombres se componen de cadenas de caracteres llamadas calificadores, separados por puntos (.). A diferencia de los nombres de archivos, la longitud de un calificador puede exceder los 8 caracteres.

6.2 - Clases de miembros y agrupadoras

Ciertas clases de recursos generales vienen asociadas de a pares, siendo una de ellas la “clase de miembros” (member class) y la otra la “clase agrupadora” (grouping class). Ambas sirven para proteger el mismo tipo de recurso.

Un ejemplo típico son las clases TCICSTRN y GCICSTRN, utilizadas para controlar la ejecución de transacciones CICS. TCICSTRN es la clase de miembros mientras que GCICSTRN es su correspondiente clase agrupadora.

Los perfiles de la clase de miembros deben tener un nombre que matchee con el del recurso que pretendan proteger. Por lo tanto, solo permiten proteger un único recurso o varios distintos pero de nombres similares. Se admiten normalmente perfiles genéricos, suponiendo que la clase se encuentre bajo GENERIC en la SETROPTS.

Ejemplo:

Supongamos que los perfiles definidos en la clase TCICSTRN son los siguientes:

1. ABC1 2. HYT6 3. ABC% 4. AB* 5. F*

1 y 2 son perfiles discretos, mientras que 3, 4 y 5 son perfiles genéricos.

89


Dentro de la clase de miembros, todo recurso tiene (a lo sumo) un único perfil que más se le ajusta, que puede ser discreto o genérico. En nuestro ejemplo, para la transacción ABC1 sería el perfil discreto de idéntico nombre, mientras que para la transacción ABFT, el perfil más ajustado sería el genérico AB*. La transacción RY54, por otro lado, no estaría cubierta por ningún perfil de la clase TCICSTRN.

En cualquier caso, la protección de un determinado recurso surge de combinar la información almacenada en ambas clases, la de miembros y la agrupadora, tal cual veremos a continuación.

Los perfiles en la clase agrupadora, a diferencia de lo que sucede con los de la clase de miembros, tienen nombres de libre elección. Pero poseen una “lista de miembros” cuyos nombres deben matchear con el nombre del recurso que pretendan proteger. En consecuencia, estos perfiles permiten proteger recursos de nombres disímiles pero con idéntica necesidad de acceso. No se permiten perfiles genéricos, aunque sí pueden los perfiles tener “miembros genéricos”. Un mismo miembro puede existir en varios perfiles.

Ejemplo:

Supongamos que los perfiles definidos en la clase GCICSTRN son los siguientes:

Nombre del perfil Miembros

GRUPOA A*

SISTAB ABC1, ABC2, ABY6, AB*

SISTCONT FTR1, FTR2, FTR3, ABC1, ABC2, VGT8

Los 3 perfiles son discretos (recordemos que no están tolerados los perfiles genéricos para clases agrupadoras). Los nombres de los perfiles -GRUPOA, SISTAB y SISTCONT- son arbitrarios y no son chequeados por RACF contra ningún nombre de recurso. En cambio, los miembros que tienen definidos son los que deben matchear con los nombres de los recursos.

GRUPOA tiene un único miembro, que es genérico.

SISTAB tiene 4 miembros. 3 de ellos discretos (ABC1, ABC2 y ABY6) y el restante genérico (AB*).

SISTCONT tiene 5 miembros, todos ellos discretos.

Dentro de una clase agrupadora, un recurso puede tener más de un perfil de máximo ajuste. Por ejemplo, para la transacción ABC1, éstos serían SISTAB y SISTCONT, pues ambos tienen al miembro discreto ABC1. Por otro lado, para la transacción ABC8, el más ajustado sería SISTAB, mientras que para AX56 sería GRUPOA. La transacción VGT2, en cambio, no estaría protegida por ningún perfil de la clase GCICSTRN.

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. Intentaremos describirla con cierto detalle, apoyándonos en los ejemplos dados para las clases TCICSTRN y GCICSTRN.

Dado un recurso, RACF busca en principio determinar si está protegido discretamente. Para ello examina ambas clases. En la clase de miembros, puede encontrar a lo sumo un único perfil discreto para el recurso, mientras que en la clase agrupadora podrían existir eventualmente varios (que tengan al recurso como miembro discreto). Si RACF efectivamente encontró al recurso protegido de manera discreta, se pueden presentar los 2 casos siguientes:

RACF encontró un único perfil que cubre discretamente al recurso (que podría estar en la clase de miembros o en la clase agrupadora). En este caso, este perfil es el que establece la protección del recurso. Es el caso, en nuestro ejemplo, para las transacciones HYT6 (perfil de igual nombre en la clase TCICSTRN) y VGT8 (perfil SISTCONT en la clase GCICSTRN).

RACF encontró más de un perfil que cubre discretamente al recurso. Es decir, halló uno en la clase de miembros y uno o más en la clase agrupadora, o bien no encontró ninguno en la clase de

90


miembros pero encontró 2 o más en la clase agrupadora. Sería el caso, en nuestro ejemplo, de las transacciones ABC1 (perfil de igual nombre en la clase TCICSTRN junto con perfiles SISTAB y SISTCONT en la clase GCICSTRN) y ABC2 (perfiles SISTAB y SISTCONT en la clase GCICSTRN). En este caso, la protección efectiva del recurso surge de combinar la información de todos los perfiles que lo cubren discretamente, proceso conocido como merge. No describiremos en detalle este algoritmo, pero mencionaremos los aspectos más relevantes:

Para determinar la lista de acceso del recurso, RACF combina las listas de acceso de todos los perfiles involucrados, manejándose, en caso de repeticiones, en base al criterio del “nivel más permisivo”. Esto significa que si un grupo (o usuario) figura en más de una de las listas de acceso, su nivel de autorización efectivo sobre recurso será el más alto de todos.

En lo que se refiere al UACC del recurso, RACF opera de manera opuesta. El UACC efectivo será el más restrictivo de los UACC de los perfiles involucrados.

Si RACF no encuentra al recurso cubierto de manera discreta, entonces busca en ambas clases perfiles que lo cubran de forma genérica. En tal caso, siguiendo un criterio análogo al empleado para perfiles genéricos de dataset, los compara hasta determinar los que más se ajustan al nombre del recurso.

Si RACF llega a establecer un único perfil que cubre genéricamente al recurso de la manera más ajustada posible, entonces éste perfil será el protector. Es el caso, en nuestro ejemplo, de la transacción ABC3. En efecto, 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, el más ajustado es el perfil ABC% (pues tanto A* como AB* son menos específicos).

Si RACF encuentra más de un perfil que cubre genéricamente al recurso de la manera más ajustada posible, entonces la protección efectiva surge de un proceso de merge idéntico al mencionado en el caso discreto. Este sería el caso, siempre en nuestro ejemplo, de la transacción ABX9. 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). Por lo tanto, la protección de la transacción ABX9 se establece combinando los perfiles AB* y SISTAB.

Finalmente, si RACF no encuentra al recurso cubierto ni discreta ni genéricamente en ninguna de ambas clases, entonces concluye que no lo tiene protegido y devuelve a la aplicación solicitante el DFTRETC especificado para la clase en la CDT. Tal sería el caso, en nuestro ejemplo, para la transacción MKL7. En el caso concreto de CICS, cabe señalar que el producto deniega el acceso si la transacción no está protegida, suponiendo que CICS esté efectivamente configurado para que se controle la ejecución de transacciones.

Recomendaciones:

En virtud de lo expuesto, 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, dentro de lo posible. Esto es, usar solo la clase de miembros o, mejor aún, solo la clase agrupadora.

� No definir el mismo recurso en más de un perfil.

� No definir miembros genéricos en perfiles de la clase agrupadora. Es preferible, si fuese necesario, crear un perfil genérico en la clase de miembros.

6.3 - Perfiles genéricos

La mayoría de las clases de recursos generales admiten perfiles genéricos. Se identifican por la presencia de algún carácter comodín en su nombre (%, * y **), cuyo significado es similar –aunque no exactamente idéntico- al que tienen en el caso de perfiles de dataset. No están permitidos, a diferencia de la clase DATASET, los perfiles genéricos completos. En consecuencia, todo perfil que no contenga en su nombre al menos un carácter genérico, resulta un perfil discreto. Recordemos que si una clase de

91


recursos generales admite perfiles genéricos, el uso del ** está permitido independientemente del seteo de la opción EGN de la SETROPTS (que solo afecta a la clase DATASET).

Otras diferencias importantes son las siguientes:

� Los perfiles genéricos de recursos generales admiten caracteres comodín en cualquier calificador, incluso en el primero.

� El * al final de un perfil indica la presencia de 0 o mas caracteres, incluyendo eventuales “puntos”, por lo cual contempla la existencia de calificadores enteros.

Siempre que resulte posible, conviene usar perfiles genéricos, ya que una poca cantidad permite proteger un gran número de recursos. Valen consideraciones similares a las que se hicieron respecto a perfiles de dataset. Un abuso en la cantidad de perfiles genéricos, dónde exista casi una relación biunívoca con los recursos, desvirtúa su naturaleza y puede ocasionar problemas de performance. Los recursos que necesiten un tratamiento de seguridad particular deben ser protegidos mediante un perfil discreto. En cualquier caso, a diferencia de la clase DATASET, el uso de perfiles discretos en clases de recursos generales es muy frecuente (incluso, a veces, obligatorio) y está perfectamente justificado.

6.4 - Niveles de acceso

Los perfiles de recursos generales, como sucede con los perfiles de dataset, tienen un UACC y listas de acceso -estándar y condicional-, dónde figuran niveles de acceso. Los posibles valores son los siguientes:

o NONE

o EXECUTE

o READ

o UPDATE

o CONTROL

o ALTER

Están enumerados en orden jerárquico, de manera que cada nivel incluye y muchas veces excede los privilegios del anterior. Cabe señalar que los nombres de los niveles tienen su origen en los existentes para perfiles de dataset, dónde tienen un significado claro. Sin embargo, para perfiles de recursos generales, debe entenderse que se trata simplemente de una escala jerárquica, dónde el alcance de cada nivel de autoridad lo establece la aplicación correspondiente. NONE tiene obviamente un significado claro, ya que indica que no se tiene ningún acceso al recurso. EXECUTE, por otro lado, solo es válido para perfiles en la clase PROGRAM.

Por ejemplo, dentro de CICS, los comandos invocados vía la transacción CEMT se encuentran protegidos en la clase CCICSCMD (o en la clase agrupadora asociada, VCICSCMD). En particular, la autoridad para ejecutar comandos sobre terminales se chequea contra el recurso de nombre TERMINAL. Dependiendo del tipo de comando que se ejecute, el nivel de autoridad requerido por CICS varía. Así, para hacer un INQUIRE, el usuario debe tener READ, para hacer un SET se requiere UPDATE y para efectuar un DISCARD se exige ALTER. Cabe indicar que estos niveles de autoridad requeridos para cada comando los establece CICS y no RACF, que solo se limita a contestar requerimientos que le son remitidos.

6.5 - Cómo determina RACF la protección de un recurso general

Si el recurso está asociado con una clase que tenga clase agrupadora, ya se describió el proceso que lleva a cabo RACF para determinar su protección.

92


En caso contrario, o sea para recursos no relacionados con clases de miembros y agrupadoras, RACF determina a lo sumo un único perfil -discreto o genérico- que protege al recurso, de manera análoga a como lo hace en el caso de archivos. RACF procede del siguiente modo:

Si el recurso está protegido discretamente, entonces este perfil discreto será su perfil protector.

Si no está protegido discretamente, RACF busca todos los perfiles genéricos que lo alcanzan (si no existiera ninguno, el recurso simplemente no estaría protegido) y procede a compararlos, de izquierda a derecha. En el primer carácter en que encuentre alguna diferencia, se descartan aquellos más genéricos, de acuerdo al siguiente criterio:

- Los caracteres “no genéricos” son más específicos que los genéricos.

- Para las genéricos, el orden, desde el menos al más genérico, es %, * y **.

6.6 - 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. Los segmentos no base se verán en el análisis particular de cada clase.

La clase es un parámetro posicional requerido que debe estar inmediatamente a continuación del comando RDEFINE.

El nombre-del-perfil es un parámetro posicional requerido que debe estar inmediatamente a continuación de la clase. Los nombres válidos dependen de cada clase. No debe especificarse el nombre del perfil entre apóstrofes, ya que los mismos se considerarían parte integrante del nombre (si la clase los soportara).

La DATA es un campo de uso administrativo, de longitud máxima 255 caracteres.

El OWNER debe ser un usuario o grupo existente. Si no se codifica explícitamente, queda como OWNER el usuario que ejecutó el comando. Recordemos que ser el dueño de un perfil no otorga acceso a los recursos que proteja. Para poder acceder a ellos, debe agregarse al usuario en la lista de acceso a través del comando PERMIT.

El operando UACC es sumamente importante y establece el “nivel de acceso universal” (Universal

Access) del perfil. Puede tomar los valores NONE, EXECUTE, READ, UPDATE, CONTROL y ALTER, que ya mencionamos previamente (EXECUTE solo es válido si la clase es PROGRAM). Si se omite, el valor por defecto es el DFTUACC que tiene la clase en la CDT o, en caso de que no lo tuviera especificado, el UACC que tiene el usuario que ejecuta el comando en su “actual grupo de conexión” (que, como ya señalamos, conviene que sea NONE por motivos de seguridad).

El operando WARNING establece que el perfil se define en modo warning. Esto significa que si un usuario requiere acceso a un recurso protegido por el perfil y RACF determina que no está autorizado, en lugar de rechazar el acceso, lo autoriza pero 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. En ciertas ocasiones, cuando aún no se logró determinar exactamente qué usuarios deben acceder a los recursos protegidos por un perfil, puede resultar útil definirlo en modo warning, de modo a no provocar una interrupción en alguna tarea crítica. Sin embargo, 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), es decir que están básicamente sin protección. Por lo tanto, debe usarse esta facilidad con sumo cuidado y normalmente por un período

93


corto de tiempo. Si se omite WARNING, el perfil queda definido como NOWARNING, que llamamos modo fail. Este es el modo en que deben encontrarse normalmente todos los perfiles de la base. Las clases PROGRAM y NODES no admiten perfiles en modo warning.

NOTIFY especifica un usuario a ser notificado cada vez que el perfil sea usado para denegar el acceso a un recurso. Si el usuario especificado se encuentra con una sesión de TSO activa, recibirá las notificaciones en tiempo real. 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 usuario debería loguearse frecuentemente a TSO afín de liberar el espacio que ocupan sus mensajes pendientes en el archivo SYS1.BRODCAST. De todos modos, no es conveniente tener en forma permanente un usuario en el NOTIFY de un perfil, si se supone que rechazará gran cantidad de accesos. NOTIFY no admite más de un usuario ni un grupo de RACF. Si se lo codifica sin especificar usuario, queda como usuario a ser notificado quien ejecutó el comando RDEFINE. Si se lo omite, ningún usuario será notificado y el campo muestra, en la salida del comando RLIST, la leyenda “NO USER TO BE NOTIFIED”.

Con el operando ADDMEM se agregan miembros al perfil, siempre y cuando se trate de una clase cuyos perfiles los admitan (clases agrupadoras o GLOBAL y PROGRAM, por ejemplo). El significado y formato de estos miembros varía según la clase.

El operando AUDIT indica a qué nivel se quiere auditar el uso del perfil. La información se graba en registros tipo 80 del SMF. Se distinguen 2 conceptos diferentes: tipo de acceso y nivel de acceso.

Los posibles tipos de acceso son:

o NONE ningún intento de acceso será grabado.

o SUCCESS se grabarán accesos exitosos.

o FAILURES se grabarán intentos de acceso fallidos.

o ALL se grabará todo intento de acceso, sea fallido o exitoso.

Los posibles niveles de acceso son:

o READ

o UPDATE

o CONTROL

o ALTER

En el operando AUDIT se pueden especificar uno (o más) tipos de acceso acompañados del nivel de acceso correspondiente. Naturalmente, NONE no requiere un nivel de acceso asociado.

FAILURES(READ) es el valor por defecto, y establece que se registre todo intento de acceso denegado por el perfil. Intentos de acceso superiores a READ que resulten fallidos son también registrados.

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. Todas las características del perfil especificado en el operando FROM son replicadas en el nuevo (OWNER, UACC, WARNING, AUDITING, NOTIFY, DATA, Listas de acceso, etc.), excepto que se codifique explícitamente un valor distinto para alguno de estos operandos en el comando RDEFINE. Si el perfil modelo tiene miembros, éstos no son copiados al nuevo perfil. En cuanto a las listas de acceso, puede existir una mínima diferencia en las del nuevo perfil con respecto al tomado como modelo, en el caso siguiente: Si la opción ADDCREATOR está activa en la SETROPTS, el usuario que crea el nuevo perfil se agrega a la lista de acceso estándar con autoridad ALTER, independientemente de que figure o no en la lista de acceso del perfil modelo.

FCLASS indica la clase de RACF a la que pertenece el perfil especificado en el operando FROM (DATASET o cualquier clase definida en la CDT son admisibles). Si se omite, RACF asume que el perfil modelo pertenece a la misma clase que el que se está definiendo.

94


FGENERIC indica a RACF que el perfil especificado en el operando FROM es genérico, aún cuando no contenga caracteres genéricos. Sólo es necesario si FCLASS es DATASET y perfil2 es un “genérico completo”. RACF ignora el operando FGENERIC si no se codificó FROM.

Si el operando FROM especifica un perfil discreto de DATASET, el operando FVOLUME debe indicar el volumen correspondiente del perfil modelo. Si se codifica FVOLUME con un valor distinto al que corresponde, o si se omite y existe más de un perfil discreto con ese nombre, el comando falla. Si no se especificó el operando FROM, o se codificó con un perfil genérico, o con un perfil de una clase que no sea DATASET, el operando FVOLUME es ignorado.

Autoridad requerida

La autoridad requerida depende de varios factores, como ser:

o Clase a la que pertenece el perfil

o Operandos especificados en el comando RDEFINE

o 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. A grandes rasgos, digamos que los usuarios autorizados a definir nuevos perfiles son aquellos con el atributo SPECIAL o con CLAUTH sobre la clase.

6.7 - 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, como sucede con todos los comandos de modificación de perfiles, solo es necesario codificar los operandos a modificar. Aquellos no especificados mantienen sus valores previos (no se cambian a valores por defecto).

Con el operando DELMEM se borra un miembro del perfil. Si se codifican ambos operandos -ADDMEM y DELMEM- en el mismo comando, solo se procesa el especificado en último término.

Autoridad requerida

Para modificar un perfil de recursos generales, quien ejecuta el comando debe, básicamente, cumplir alguno de los siguientes requisitos:





Para ciertos operandos, como ADDMEM, existen restricciones adicionales, pero no entraremos en detalle sobre las mismas.

6.8 - Eliminación de un perfil de recursos generales

Sintaxis:

RDELETE|RDEL clase nombre-del-perfil

95


Autoridad requerida

Para deletear un perfil de recursos generales, quien ejecuta el comando debe, básicamente, cumplir alguno de los siguientes requisitos:





6.9 - Listado de un perfil de recursos generales

Sintaxis:

RLIST|RL clase nombre-del-perfil|*

[GENERIC|NOGENERIC] [AUTHUSER] [ALL] [RESGROUP]

Si se codifica * luego de clase, se listarán todos los perfiles de la clase que el usuario esté autorizado a ver. En caso de existir el perfil genérico *, no hay manera de listarlo individualmente. Por lo tanto, si se quiere definir un “perfil abarcativo” (backstop profile) en la clase (o sea, un perfil que proteja a todos los recursos que no se encuentren protegidos por uno más específico), es preferible crear el perfil ** en lugar de * pues, a diferencia de este último, sí es factible listarlo por separado con el comando “RLIST clase **”.

Si se codifica el operando GENERIC, la información listada dependerá de lo que se especifique como nombre de recurso, de acuerdo al siguiente criterio:

o Si nombre-del-perfil no contiene ningún caracter genérico, RACF listará el perfil genérico que más se ajuste al nombre de recurso especificado. Sin embargo, si existiese un perfil discreto, no se mostrará (y, sin embargo, resulta ser efectivamente el perfil protector).

o Si nombre-del-perfil contiene algún carácter comodín, entonces RACF listará únicamente el perfil que coincida exactamente con el nombre especificado, si existiese. En caso contrario, informa sencillamente que el perfil requerido no existe.

o Si en lugar de nombre-del-perfil se codificó *, serán listados todos los perfiles genéricos de la clase.

NOGENERIC indica que se debe listar el perfil discreto que coincida con el nombre especificado. Si tal perfil no existiese, RACF lo informa. Si en lugar de nombre-del-perfil se codificó *, serán listados todos los perfiles discretos de la clase.

Si no se codifica GENERIC o NOGENERIC, la información listada dependerá de lo que se especifique como nombre de recurso, de acuerdo al siguiente criterio:

o Si nombre-del-perfil no contiene ningún caracter genérico, RACF listará el perfil protector del recurso, que podrá ser discreto o genérico.

o Si nombre-del-perfil contiene algún carácter comodín, entonces RACF listará únicamente el perfil que coincida exactamente con el nombre especificado, si existiese. En caso contrario, informa sencillamente que el perfil no existe.

o Si en lugar de nombre-del-perfil se codificó *, serán listados todos los perfiles (discretos y genéricos) de la clase.

AUTHUSER indica que se debe incluir en la salida del comando la siguiente información:

o Security level, categories y security label

o Lista de acceso estándar

o Lista de acceso condicional

96


ALL establece que se liste toda la información del segmento base. Si no se especifica, el listado no muestra ni las estadísticas ni las listas de acceso. Para listar los eventuales segmentos no base, debe especificarse el parámetro correspondiente.

Si la clase tiene una clase agrupadora, RESGROUP indica que se genere una lista de todos los perfiles de la clase que tengan al recurso especificado dentro de sus miembros. En caso contrario, el operando RESGROUP es ignorado.

Autoridad requerida

Para listar un perfil de recursos generales, quien ejecuta el comando debe, básicamente, cumplir con alguno de los siguientes requisitos:




� Tener autoridad READ (o superior) sobre el perfil.

� Existir una entrada en la GLOBAL para el perfil que otorgue autoridad READ (o superior).

Para que se liste el campo GLOBALAUDIT, quien ejecuta el comando debe tener el atributo AUDITOR (ya sea a nivel de sistema, o a nivel de un grupo que tenga al perfil dentro de su campo de acción).

Para ver las listas de acceso, se debe satisfacer alguna de las siguientes condiciones:


� Tener el atributo SPECIAL, AUDITOR u OPERATIONS a nivel de un grupo que tenga al perfil de su campo de acción.


� Existir una entrada en la GLOBAL para el perfil que otorgue autoridad ALTER.


6.10 - Permisos sobre perfiles de recursos generales

Las listas de acceso de perfiles de recursos generales, tanto la estándar como la condicional, se modifican a través del comando PERMIT. Para ciertas clases, las listas de acceso son irrelevantes (STARTED o GLOBAL, por ejemplo), aunque debe tenerse siempre presente que el nivel de autoridad ALTER, sobre un perfil discreto, confiere autoridad administrativa (generalmente no deseada).

Sintaxis:

PERMIT|PE ‘nombre-del-perfil’ CLASS(clase) [ID({usuario/grupo...|*})] ACCESS(nivel)|DELETE] [FROM(‘perfil2’)] [FCLASS] [FGENERIC] [FVOLUME(volumen)] [RESET(ALL|STANDARD|WHEN)] [WHEN([APPCPORT({partner-luname|*})] [CONSOLE({consola|*})] [JESINPUT({nombre-input-device|*})] [PROGRAM({programa|*})] [SYSID({sysid|*})] [TERMINAL({terminal|*})])]

El nombre-del-perfil es requerido y debe estar inmediatamente a continuación del comando PERMIT.

CLASS indica la clase a la que pertenece el perfil. Como ya hemos visto, el valor por defecto es DATASET, por lo cual debe codificarse obligatoriamente para una clase de recursos generales.

97


ID indica el usuario o grupo cuya entrada en la lista de acceso se desea agregar, modificar o eliminar. Separados por espacios pueden ingresarse más de un usuario/grupo. También se acepta el valor *, que representa un usuario cualquiera existente en la base de RACF.

ACCESS establece el nivel de autoridad que se quiere otorgar al usuario/grupo especificado en el operando ID. Los posibles valores son NONE, EXECUTE, READ, UPDATE, CONTROL y ALTER. Si se codifica ACCESS sin poner ningún valor, se asume READ.

DELETE indica que se pretende borrar de la lista de acceso la entrada correspondiente al usuario/grupo codificado en el operando ID.

En ambos casos, ya sea con ACCESS o DELETE, RACF actúa sobre la lista de acceso estándar, excepto que se codifique explícitamente el operando WHEN, que indica que se pretende modificar la lista de acceso condicional. Si se especificó ID, pero se omitió tanto ACCESS como DELETE, se asume por defecto ACCESS(READ).

FROM especifica el nombre de otro perfil (discreto o genérico) del cual se quieren copiar las listas de acceso (estándar y condicional). Las entradas en las listas de acceso del perfil2 son agregadas a las listas de acceso correspondientes. Es decir, el operando FROM no convierte en idénticas las listas de acceso de ambos perfiles. Más aún, si una entrada que figura en la lista de acceso del perfil2 ya se encuentra en la del perfil en cuestión, entonces la misma no se modifica.

FCLASS indica la clase a la que pertenece el perfil especificado en el operando FROM. Si omite FCLASS y se codificó FROM, se asume por defecto que perfil2 pertenece a la misma clase que el perfil en cuestión.

FGENERIC indica a RACF que el perfil especificado en el operando FROM es genérico, aún cuando no contenga caracteres genéricos. Por lo tanto, solo tiene sentido si perfil2 es un perfil de dataset. RACF ignora el operando FGENERIC si no se codificó FROM.

Si el operando FROM especifica un perfil discreto de DATASET, el operando FVOLUME debe indicar el volumen correspondiente. Si se codificara FVOLUME con un valor distinto al que corresponde al perfil2, o si se omite y existe más de un perfil discreto con ese nombre, el comando falla. Si no se especificó el operando FROM, o se codificó con un perfil genérico, o con un perfil de una clase que no sea DATASET, el operando FVOLUME es ignorado.

El operando RESET indica que se pretende vaciar una o ambas listas de acceso (es decir, eliminar todas las entradas). RESET(STANDARD) vacía únicamente la lista de acceso estándar, en tanto que RESET(WHEN) hace lo propio con la condicional. RESET(ALL) vacía ambas. Si se codifica RESET sin ningún valor, se asume por defecto ALL.

El operando WHEN indica que se quiere modificar la lista de acceso condicional. No describiremos los distintos suboperandos que admite. Si se omite WHEN, las modificaciones se efectúan sobre la lista de acceso estándar (aunque los operandos FROM o RESET pueden impactar igualmente sobre la lista de acceso condicional).

6.11 - Comando SEARCH

Sintaxis:

SEARCH|SR [CLASS({DATASET|clase})] [{ALL|GENERIC|NOGENERIC|MODEL|TAPE|VSAM|NOVSAM}] [CATEGORY(categoría)|EXPIRES(valor)|LEVEL(valor)| SECLABEL(label)|SECLEVEL(level)|WARNING] [FILTER(cadena)] [{MASK({cadena1|*}[,cadena2])|NOMASK}] [USER(usuario)] [AGE(valor)] [CLIST[(‘cadena1’[‘cadena2’])]]

El comando SEARCH permite obtener una lista de los nombres de los perfiles de la base que cumplan con determinados criterios.

98


CLASS especifica la clase dentro de la cual se buscan los perfiles. Se puede codificar DATASET, USER, GROUP o cualquier otra clase definida en la CDT. Si se omite, el valor por defecto es DATASET.

ALL indica que se listen todos los perfiles –genéricos o discretos- que satisfagan los demás criterios fijados por los restantes parámetros del comando SEARCH. GENERIC restringe la búsqueda a perfiles genéricos, mientras que NOGENERIC la limita a perfiles discretos. Las opciones MODEL|TAPE|VSAM|NOVSAM solo tienen sentido para la clase DATASET (son directamente ignoradas si la clase especificada es otra). El valor por defecto es ALL.

CATEGORY|EXPIRES|LEVEL|SECLABEL|SECLEVEL|WARNING Mediante estos operandos se establecen criterios de búsqueda. No nos ocuparemos de CATEGORY, SECLABEL y SECLEVEL.

o EXPIRES solo se aplica a la clase TAPEVOL. El valor debe estar comprendido entre 0 y 65533, o bien ser 99999 (archivos que nunca expiran). Si se codifica, solo se listarán los volúmenes tales que todos sus archivos, o bien ya se encuentren expirados, o bien lo harán dentro de la cantidad de días especificados.

o LEVEL establece que se listen los perfiles cuyo LEVEL coincida con el especificado. Recordemos que se trata de un campo de uso administrativo, cuyo valor está comprendido entre 00 y 99. Si la clase es USER o GROUP, este operando es ignorado.

o WARNING indica que se listen los perfiles que se encuentre en modo warning. Si la clase es USER o GROUP, este operando es ignorado.

FILTER permite indicar una cadena de caracteres (incluyendo los caracteres comodín %, * y **), de modo que sean listados únicamente los perfiles cuyos nombres estén alcanzados por el patrón establecido. El significado de los caracteres genéricos es similar al que tienen en el caso de perfiles, y pueden codificarse en cualquier calificador (incluso en el primero):

- % indica un único carácter cualquiera (inclusive % y *)

- * indica la presencia de 0 más caracteres (inclusive genéricos) hasta concluir el calificador. Si es usado como un calificador completo, exige la existencia de ese calificador en los nombres que abarca.

- ** indica la presencia de 0 o más calificadores. Sólo puede usarse como un calificador completo.

Ejemplo:

FILTER(a%%.xy*.*.**) alcanzaría a los siguientes nombres de perfiles:

a21.xyzw.asdf.qwe.fin

aa*.xyz%%%.qwe

Sin embargo, no alcanzaría a: ab23.xyz.efgh.qwe (tiene 4 caracteres en el primer calificador) a21.xyw* (no tiene un tercer calificador, que es exigido)

El operando MASK, excluyente con el operando FILTER, brinda un medio alternativo para filtrar perfiles:

o Cadena1 indica una secuencia de caracteres con la que deben empezar los nombres de los perfiles buscados. Se admiten caracteres genéricos, pero pierden su significado comodín y son exigidos literalmente. Si se codifica * y la clase es DATASET, el identificador del usuario que ejecuta el comando se toma como máscara.

o Cadena2 establece, opcionalmente, una segunda cadena de caracteres que debe contener el nombre del perfil en cualquier lugar a continuación de cadena1. También en este caso se

99


admiten caracteres genéricos, pero no tienen su significado usual sino que son tomados literalmente.

NOMASK establece que se listen todos los perfiles de la clase que cumplan con el resto de los criterios. En realidad, solo son listados aquellos que el usuario está autorizado a ver.

Si no se codifica MASK|NOMASK (ni FILTER), entonces el defecto es MASK(*). Notemos que para todas las clases excepto DATASET, NOMASK y MASK(*) son equivalentes, ya que no fijan restricciones sobre los nombres de los perfiles.

El operando FILTER es más flexible que MASK, pues permite criterios de búsqueda más sofisticados.

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, o bien sea el owner. Si la clase especificada es GROUP, serán listados los grupos para los cuales el usuario codificado esté conectado con autoridad CONNECT o JOIN, esté conectado con atributo SPECIAL o AUDITOR, o sea el owner.

AGE establece que se listen únicamente los perfiles que no han sido referenciados dentro de la cantidad de días especificados (contados hacia atrás desde el actual). El valor codificado debe estar comprendido entre 0 y 99999. Esta opción funciona únicamente para perfiles discretos de clases para las cuales se mantengan estadísticas.

Si la clase es USER, 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. En el caso en que LAST-ACCESS tenga el valor UNKNOWN, se toma la fecha de creación del usuario como referencia.

Si la clase es GROUP, 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.

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). La lista se graba en un archivo de nombre PREFIX.EXEC.RACF.CLIST, dónde PREFIX indica el prefix de TSO del usuario que ejecuta el comando SEARCH (si tuviera noprefix en su profile de TSO, su identificador de usuario se usaría como HLQ del dataset). Es importante recalcar que el comando solo genera la CLIST. No la ejecuta.

o Cadena1, que debe codificarse entre apóstrofes simples, establece el texto que se antepondrá en cada registro al nombre del perfil.

o Cadena2, que debe estar igualmente entre apóstrofes simples, establece el texto que se agregará en cada registro inmediatamente a continuación del nombre del perfil.

Adicionalmente, un número de secuencia de 8 posiciones es colocado al principio de cada registro. El operando CLIST es útil cuando se quiere ejecutar idénticos comandos de RACF sobre los perfiles que resulten de la búsqueda.

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. Para ello, 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, de modo que los comandos resulten sintácticamente correctos. El archivo grabado podría tener los siguientes registros: 00000010RLIST FACILITY STGADMIN.ADR.** ALL 00000020RLIST FACILITY STGADMIN.IDC.** ALL 00000030RLIST FACILITY STGADMIN.IGG.** ALL 00000040RLIST FACILITY STGADMIN.** ALL

100


Luego, bastaría ejecutarlos a través del comando EXEC de TSO.

Autoridad requerida

Todo usuario está autorizado a ejecutar el comando SEARCH, solo que únicamente le serán mostrados los nombres de los perfiles que este autorizado a ver. Básicamente, para poder ver el nombre de un perfil, quien ejecuta el comando debe cumplir con alguna de las condiciones siguientes:

� Tener el atributo SPECIAL o AUDITOR a nivel de sistema o a nivel de un grupo que tenga al perfil dentro de su campo de acción.

� 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.

� Tener autoridad READ (o superior) sobre el perfil.

Para poder usar SEARCH con el operando USER, quien ejecuta el comando debe cumplir con alguna de las condiciones siguientes:

� Tener el atributo SPECIAL o AUDITOR a nivel de sistema o a nivel de un grupo que tenga al usuario del operando USER dentro de su campo de acción.

� Ser el owner del usuario codificado en el operando USER

� El usuario codificado en el operando USER debe coincidir con el propio.

101


7 - CLASES PARTICULARES


Existe una gran cantidad de clases de recursos generales, que permiten proteger recursos de muy variada naturaleza. Como ya comentáramos, una organización puede normalmente manejar satisfactoriamente su seguridad activando solo una cantidad limitada de ellas. Un administrador de RACF debe conocer perfectamente el funcionamiento y alcance de las clases que se utilizan efectivamente en su organización. Algunas de estas clases están descriptas en detalle en la bibliografía de RACF, mientras que otras son tratadas en profundidad en la documentación del producto que las utiliza.

Analizaremos a continuación algunas clases de recursos generales que consideramos particularmente importantes y cuyo uso es muy frecuente.

7.2 - Clase GLOBAL

Podemos imaginar a la “tabla de acceso global”, que abreviaremos GAC (Global Access Checking

Table), como una tabla que contiene una lista de “recursos” asociados con un determinado “nivel de acceso”. La GAC permite autorizar el acceso a un recurso a cualquier usuario (con excepción únicamente de aquellos con el atributo RESTRICTED), sin que RACF analice el perfil protector. En efecto, durante el proceso de chequeo de autorización que lleva a cabo RACF, que estudiaremos en forma precisa en un capítulo posterior, la GAC se consulta en primera instancia. Si la información que contiene indica que el acceso debe otorgarse, RACF responde favorablemente sin continuar con el chequeo habitual de perfiles. Es importante recalcar que la GAC puede autorizar un requerimiento de acceso, pero nunca rechazarlo. Si no contiene información que autorice el requerimiento, RACF continúa con su chequeo habitual. Por lo tanto, la GAC solo puede utilizarse para responder favorablemente solicitudes de acceso.

Únicamente actúa la GAC para aquellas clases que tienen GLOBAL especificado en la SETROPTS. Por lo tanto, si se pretende definir reglas en la GAC para una determinada clase, debe activarse su chequeo de la GLOBAL, ejecutando el comando:

SETROPTS GLOBAL(clase)

Recordemos que la clase especificada no puede ser una clase agrupadora.

Construcción y mantenimiento de la GAC

GLOBAL es, en realidad, una clase de RACF. Para definir reglas en la GAC para una determinada clase, debe definirse en principio un perfil en la clase GLOBAL cuyo nombre coincida con el de la clase. Las reglas se definen luego como miembros del perfil, a través del operando ADDMEM. 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, con las siguientes importantes flexibilidades adicionales:

o Si la clase en cuestión tiene GENCMD especificado en la SETROPTS, los caracteres genéricos pueden usarse en cualquier calificador, incluso el primero.

o Los nombres de recurso pueden contener las variables &RACUID y &RACGPID como calificadores. &RACUID se reemplaza por el usuario actual mientras que la variable &RACGPID indica su “actual grupo de conexión”.

o Los nombres de recurso pueden incluir variables definidas en la clase RACFVARS.

El nivel de acceso puede ser NONE, READ, UPDATE, CONTROL o ALTER (EXECUTE no está permitido en la GAC).

Los siguientes comandos muestran como incorporar una regla en la GAC para una determinada clase:

102


RDEFINE GLOBAL clase

RALTER GLOBAL clase ADDMEM(‘nombre-del-recurso’/nivel de acceso)

Para borrar una regla existente, el comando sería:

RALTER GLOBAL clase DELMEM(‘nombre-del-recurso’/nivel-de-acceso)

Debe tenerse cuidado, ya que si en lugar de RALTER se especifica RDELETE, el comando no solo borraría la regla en cuestión sino que deletearía el perfil, con lo cual se eliminarían todas las reglas de la GAC para la clase.

En cualquier caso, luego de efectuar una modificación en la GAC para cierta clase, la misma solo entra en vigencia luego de ejecutar el siguiente comando de refresh:

SETROPTS GLOBAL(clase) REFRESH

Ejemplo:

Vamos a mostrar una secuencia de comandos que define una serie de reglas en la GAC para la clase DATASET. En este ejemplo, se pretende que todos los archivos cuyo HLQ es SYS1 sean accedidos por todos los usuarios con autoridad READ, con excepción del dataset SYS1.UADS. Asimismo, se pretende otorgar UPDATE a todos los usuarios a los catálogos de usuario, cuyos nombres suponemos tienen HLQ igual a USRCAT (y son los únicos con este HLQ). Asumimos que en la SETROPTS la clase DATASET está bajo GENCMD y que la opción EGN está activa. Asimismo, suponemos que no existe el perfil DATASET en la clase GLOBAL y que la misma no está bajo GLOBAL en la SETROPTS.

1) SETROPTS GLOBAL(dataset)

2) RDEFINE GLOBAL DATASET

3) RALTER GLOBAL DATASET ADDMEM(‘sys1.**’/read)

4) RALTER GLOBAL DATASET ADDMEM(‘sys1.uads’/none)

5) RALTER GLOBAL DATASET ADDMEM(‘usrcat.**’/update)

6) SETROPTS GLOBAL(dataset) REFRESH

Cuando RACF analiza el contenido de la GAC para resolver sobre una solicitud de acceso, procede de manera similar a como lo hace con perfiles. Esto es, RACF detecta la entrada que mas se ajusta al recurso solicitado y en base a ella decide si debe otorgar el acceso inmediatamente, o bien debe seguir con el proceso de chequeo habitual. En nuestro ejemplo, si un usuario intenta leer el archivo SYS1.UADS, RACF consulta las reglas para la clase DATASET en la GAC (ya que DATASET está bajo GLOBAL en la SETROPTS), y encuentra que la entrada que más se ajusta es SYS1.UADS, cuyo nivel de acceso asociado es NONE. Por lo tanto, la GAC no permite otorgar el acceso solicitado, y RACF continúa con el análisis de los perfiles correspondientes (recordemos que la GAC nunca rechaza por sí misma un requerimiento de acceso).

Consideraciones:

� Los usuarios con el atributo RESTRICTED son los únicos que no pueden obtener acceso a un recurso a través de la GAC.

� Aún cuando exista en la GAC una regla que permita acceder a un recurso bajo cierto nivel de autoridad, es conveniente garantizar idéntico acceso a través del UACC del perfil protector. Esto evita problemas si involuntariamente se borra la regla de la GAC, o se inhabilita en la SETROPTS la opción GLOBAL para la clase. Por ejemplo, si tenemos la siguiente regla en la GAC:

USRCAT.**/UPDATE

resulta conveniente tener asimismo un perfil de dataset ‘USRCAT.**’ con UACC(UPDATE).

103


� Para ciertas aplicaciones que utilizan la macro RACROUTE REQUEST=FASTAUTH, la GAC no actúa. CICS es un ejemplo de ello.

� Si el acceso a un recurso es otorgado por la GAC, RACF no actualiza las eventuales estadísticas que pudiera tener el perfil protector. Mas aún, RACF ni siquiera determina qué perfil protege efectivamente al recurso.

� Si el acceso a un recurso es otorgado por la GAC, RACF no tendrá en cuenta el nivel de auditoría del perfil protector (ya que dicho perfil no es ni siquiera determinado). Actúa, sin embargo, la opción global de auditoría para la clase establecida en la SETROPTS a través del operando LOGOPTIONS.

� Una regla en la GAC con nivel de autoridad NONE solo tiene sentido si existe otra regla para la misma clase con autoridad superior y que sea mas permisiva (ver el ejemplo anterior).

� Cuando se listan las reglas existentes en la GAC para una determinada clase, con el comando “RLIST GLOBAL clase”, las mismas se muestran ordenadas según el criterio de mayor especificidad.

� El uso de la GAC puede mejorar la performance al evitarse, en muchos casos, costosos I/O sobre la base de RACF. Son excelentes candidatos para la GAC recursos de uso muy frecuente que deban ser accedidos en forma universal.

7.3 - Clase STARTED

Una started task, también conocida como STC, en un procedimiento que se arranca con el comando de operador START (o bien asociada directamente con un componente del sistema operativo, como DFSMS). Reside en bibliotecas de procedimientos declaradas en la parametrización del JES (SYS1.PROCLIB, por ejemplo).

Las STC, a diferencia de los trabajos batch, no tienen una tarjeta job dónde figure usuario y grupo (o que se reciban propagados). Por lo tanto, como básicamente solo usuarios o grupos definidos en RACF pueden acceder a recursos protegidos, es necesario que las STC tengan una identidad asignada. Naturalmente, el usuario debe estar conectado al grupo especificado.

Si la opción GRPLIST no está activa en la SETROPTS –opción improbable en la actualidad-, entonces solo se tendrá en cuenta el grupo especificado al momento de resolver solicitudes de acceso del usuario a recursos protegidos. En cambio, si como recomendamos, está activa la opción GRPLIST, entonces el grupo de conexión resulta irrelevante y el usuario tendrá acceso a los recursos a través de cualquiera de sus grupos.

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). Si la clase STARTED está activa, RACF busca en principio un perfil en esta clase que asigne una identidad válida al procedimiento. Si no lo encuentra, recién entonces examina la ICHRIN03.

La ICHRIN03 es una tabla residente en la LPA (Link Pack Area) o en la MLPA (Modified Link Pack

Area). Debe compilarse y linkeditarse como si se tratara de un programa assembler, aún cuando solo contenga definiciones de constantes y carezca de instrucciones propiamente dichas. Más aún, luego de modificado, para que el nuevo módulo entre en vigencia es necesario dar IPL, ya que no es posible refrescarlo dinámicamente dado el sector de memoria donde se aloja. Estos inconvenientes hacen que la utilización de esta tabla estática de asignación sea muy poco práctica, razón por la cual IBM introdujo la clase STARTED, que permite un manejo dinámico. De todos modos, tengamos presente que el módulo ICHRIN03 debe existir, ya que en caso contrario RACF no inicializa. Recomendamos tener una ICHRIN03 mínima, con entradas únicamente para ciertas started task críticas del sistema operativo. Esto permitirá que inicie el sistema operativo ante una eventual inactivación involuntaria de la clase

104


STARTED. No entraremos en detalles en esta guía sobre la construcción de la ICHRIN03, pero ejemplos concretos se pueden consultar en la documentación de IBM.

Recursos y perfiles de la clase STARTED

En lo que sigue, vamos a suponer que la clase STARTED está activa, RACLISTeada y que admite perfiles genéricos. Esto se logra ejecutando el siguiente comando:

SETR CLASSACT(STARTED) RACLIST(STARTED) GENERIC(STARTED)

Con las versiones actuales del z/OS, el comando START de MVS permite startear no solo una STC sino también un job. Para simplificar, vamos a ocuparnos exclusivamente del caso de procedimientos, ya que es lo más frecuente.

Al arrancarse una STC, si no se especifica en el comando START un jobname distinto, se construye el nombre de recurso miembro.miembro, dónde miembro indica el miembro de la biblioteca dónde se encuentra el procedimiento (el nombre del procedimiento propiamente dicho, establecido en la primer sentencia del JCL, no entra en juego). Si, por el contrario, se especificara el parámetro JOBNAME en el comando START, el recurso correspondiente sería miembro.jobname. 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.

Ejemplo:

Supongamos que se ejecuta el siguiente comando de operador:

START cnmproc

RACF, para asignar identidad al procedimiento, busca en la clase STARTED el perfil que más se ajuste al nombre cnmproc.cnmproc, que podría ser, por ejemplo, el perfil genérico cnmproc.*.

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, al no tratarse de perfiles que protejan acceso a recursos, los campos UACC, AUDIT y listas de acceso, entre otros, resultan irrelevantes. La información determinante de los perfiles de la clase STARTED se encuentra en el segmento no base denominado STDATA, cuyos campos describiremos a continuación

USER establece el usuario que se asociará con el procedimiento. Si el usuario codificado no existe en la base, RACF alerta sobre la situación emitiendo un mensaje, pero la definición se realiza de todos modos. Existe la opción de codificar el valor “=MEMBER” en lugar de un identificador de usuario, en cuyo caso RACF asignará el usuario que coincida con el nombre del miembro -si existiera.

GROUP establece el grupo que se asociará con el procedimiento. Si el grupo codificado no existe, o si el usuario especificado en el operando USER no se encuentra conectado a él, RACF alerta sobre la situación enviando un mensaje, pero también aquí la definición se realiza de todos modos. Existe la opción de codificar el valor “=MEMBER” en lugar del nombre de un grupo, en cuyo caso RACF asignará al procedimiento el grupo que coincida con el nombre del miembro -si existiera.

PRIVILEGED=YES indica que todos los accesos que solicite el procedimiento (salvo contadísimas excepciones, muy poco frecuentes y que no vale la pena mencionar) serán otorgados, sin efectuar el chequeo correspondiente. Tales accesos exitosos no actualizarán estadísticas ni generarán registros de SMF, aún cuando la configuración de auditoría lo requiera. El valor por defecto es PRIVILEGED=NO.

105


TRUSTED=YES se comporta de manera similar a PRIVILEGED=YES, con la diferencia de que sí se generarán registros de SMF de acuerdo a la configuración de auditoría correspondiente. El valor por defecto es TRUSTED=NO.

La mayoría de las STC no deben estar marcadas ni TRUSTED ni PRIVILEGED, tal cual es el defecto. Deben tener un usuario asignado que tenga solo los accesos necesarios. Sin embargo, existen ciertos procedimientos críticos del sistema operativo para los cuáles IBM recomienda estos atributos, para evitar que una eventual falta de autorización cause serios trastornos operativos, o incluso que el sistema no inicie o funcione correctamente. En estos casos, recomendamos usar TRUSTED en lugar de PRIVILEGED, para contar eventualmente con alguna información de auditoría grabada en registros SMF. Debe señalarse, de todos modos, que la posibilidad de auditar una tarea marcada TRUSTED es bastante limitada y poco flexible. En efecto, al otorgarse los accesos sin consulta a los perfiles protectores, las opciones de auditoría que éstos tengan configuradas no son tomadas en cuenta. Por lo tanto, sólo se generarán registros de auditoría si el usuario tuviera el atributo UAUDIT, o si la clase a la que pertenece el recurso estuviera auditada a nivel de la SETROPTS. En el primer caso, se grabaría información para todos los accesos de la STC, sin posibilidad de discriminación alguna. Si, por el contrario, se audita una clase específica, no solo se grabaría información para esta STC sino para todos los accesos a recursos protegidos en la clase, pudiéndose generar un volumen muy grande de información innecesaria. En definitiva, la auditoría de una STC indicada como TRUSTED, si bien posible, suele ser problemática. JES2 es un ejemplo de un procedimiento que se aconseja ejecutar como TRUSTED. Más adelante damos una lista de STC que IBM sugiere ejecutar como TRUSTED.

TRACE=YES indica que RACF informará, mediante un mensaje por consola, toda vez que el perfil sea usado para la asignación de usuario. Esta opción puede resultar útil como herramienta de diagnóstico para resolver ciertos problemas. El valor por defecto es TRACE=NO.

Para modificar, borrar o listar perfiles de la clase STARTED se utilizan los comandos habituales de manejo de perfiles de clases de recursos generales, a saber: RALTER; RDELETE y RLIST.

Para cambiar el valor de un campo del segmento STDATA, debe codificarse el operando STDATA en el comando RALTER especificando solo el suboperando a modificar.

Para listar la información completa de un perfil de la clase STARTED debe ejecutarse el comando “RLIST STARTED nombre-del-perfil STDATA”. Si se omite STDATA, solo se mostrará la información del segmento base y no se visualizará la información determinante para la asignación de identidad.

Consideraciones:

� Si una started task no adquiere una identidad válida, corre bajo un usuario indefinido, y solo puede acceder a los recursos cuyo UACC sea lo suficientemente permisivo. Estando la clase STARTED activa –como es absolutamente recomendable-, solo en los casos siguientes RACF consultará la ICHRIN03:

o No existe un perfil en la clase STARTED

o Existe un perfil pero sin segmento STDATA.

o Existe un perfil con segmento STDATA pero sin usuario especificado.

En cambio, en cualquiera de los casos siguientes, no se consultará la ICHRIN03 y la STC ejecutará con usuario indefinido:

o Existe un perfil con segmento STDATA pero el usuario especificado no existe en la base.

o Existe un perfil con segmento STDATA pero el grupo especificado no existe en la base.

o Existe un perfil con segmento STDATA, con usuario y grupo válidos, pero el usuario no está conectado al grupo.

106


� En el inicio de una STC, RACF no chequea la eventual revocación del usuario asignado. Esto determina que el procedimiento efectivamente arrancará, aún cuando el usuario se encuentre revocado. Sin embargo, es probable que la tarea tenga problemas posteriormente, si alguna acción que lleve a cabo controle efectivamente esta condición (por ejemplo, si la STC submite un job al internal reader). Por lo tanto, es aconsejable verificar regularmente que los usuarios asociados con las STC no se encuentren revocados.

� Si un usuario es utilizado exclusivamente para ser asignado a una started task, entonces es un excelente candidato para otorgarle el atributo PROTECTED. De esta manera se evitan usos indebidos del usuario, así como también revocaciones maliciosas por intentos de logon fallidos ingresando passwords incorrectas.

� La asignación del usuario a la STC se realiza en el momento de su inicio. En consecuencia, tanto si se cambia el usuario asignado como si se le otorga (o quita) algún atributo, la modificación solo tomará efecto una vez que se recicle la STC (es decir, que se pare y reinicie).

� Con el objeto de mantener un adecuado control de las STC en el sistema, recomendamos definir un perfil de contención ** en la clase STARTED, cuyo usuario asignado no tenga ninguna autorización explícita sobre ningún perfil. De este modo, 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), lo cual no debería ser peligroso desde la perspectiva de la seguridad. Una opción aún más radical consistiría en otorgarle a tal usuario el atributo RESTRICTED, en cuyo caso el procedimiento no podría acceder a ningún recurso protegido. Es de destacar que estando correctamente definido este backstop en la clase STARTED, RACF nunca revertirá a la ICHRIN03 en su proceso de asignación de identidad.

En cualquier caso, lo realmente importante es que toda STC se encuentre perfectamente identificada y con un usuario debidamente asignado a través de la clase STARTED, que detente únicamente las autorizaciones necesarias para sus tareas. Asimismo, y de manera complementaria, deben estar adecuadamente protegidas las bibliotecas de procedimientos declaradas en JES.

� La clase STARTED debe necesariamente estar RACLITeada. Sin embargo, en este caso particular, RACF no carga en memoria toda la información de sus perfiles sino solo sus nombres. Una vez que determina el perfil que usará para asignar identidad (operación rápida, pues tiene los nombres en memoria virtual) hará un I/O sobre la base para extraer el segmento STDATA correspondiente. Una consecuencia de esto es que, si solo se modifica un campo del segmento STDATA de un perfil existente, no será normalmente necesario ejecutar el comando de REFRESH.

� IBM recomienda que los siguientes procedimientos se ejecuten como TRUSTED:

CATALOG, DUMPSRV, DFHSM, DFS, GPMSERVE, IEEVMPCR, IOSAS, IXGLOGR, JES2 o JES3, JESXCF, LLA, NFS, OMVSKERN, RACF, RMF, RMFGAT, SMSVSAM, SMF, TCPIP, VLF, VTAM, XCFAS.

Aconsejo fuertemente seguir las recomendaciones de IBM y asignar TRUSTED siempre que se lo sugiera.

7.4 - Clase PROGRAM

El funcionamiento de la clase PROGRAM es ciertamente complejo, y exponerlo en detalle está fuera de los objetivos de este curso introductorio. Por ejemplo, no discutiremos en esta guía ninguno de los siguientes temas:

� Modo de protección ENHANCED. Aporta un nivel de protección mayor que el modo BASIC. Su implementación requiere un importante esfuerzo de configuración de perfiles en la clase PROGRAM (y sólidos conocimientos en la materia). No resulta habitualmente necesario. En la

107


primera línea del listado de la SETROPTS se visualiza claramente si el control de programas está activo y en qué modo.

� Acceso a archivos condicionado a la ejecución de determinado programa, esquema conocido como PADS (Program Access to Data Sets).

� Nivel de autoridad EXECUTE y “entorno limpio” (clean environment).

Nos limitaremos pues a exponer ciertas nociones básicas relacionadas con la clase PROGRAM que todo administrador de RACF debe conocer.

En la gran mayoría de los casos, más que proteger un determinado medio de acceso, como es en definitiva un programa, deberían centrarse los esfuerzos en proteger adecuadamente los recursos a los que permite acceder. Así, por ejemplo, no tiene mayor sentido proteger el programa invocado por el FTP (que no deja de ser uno de los tantos posibles métodos de transferencia), sino que lo fundamental consiste en proteger los datos, con perfiles de dataset adecuados.

Como ya hemos señalado, la clase PROGRAM presenta ciertas particularidades que ya hemos mencionado, pero conviene recordar en este punto:

� A diferencia de las otras clases, para activar el control de programas bajo RACF no es necesario activar la clase PROGRAM, sino que debe especificarse WHEN(PROGRAM) como opción en la SETROPTS.

� Si se modifica información de perfiles en la clase PROGRAM, debe ejecutarse el comando “SETROPTS WHEN(PROGRAM) REFRESH” para que los cambios tomen efecto.

� Los perfiles de la clase PROGRAM no soportan el modo warning.

Protección de programas

Todo programa reside en una biblioteca particionada, que puede ser pública, como aquellas que figuran en la LINKLIST, o de uso privado. Es posible, y realmente frecuente aunque poco recomendable, que el mismo nombre de programa exista en más de una biblioteca, pudiendo tratarse de distintas o idénticas versiones, o bien de programas francamente diferentes.

Un programa que se encuentra protegido por un perfil en la clase PROGRAM se denomina programa

controlado. RACF solo permite proteger un programa dentro de una biblioteca específica. El nombre del perfil debe matchear con el nombre del programa a proteger, mientras que la biblioteca dónde reside específicamente la versión en cuestión debe definirse como miembro del perfil.

Un programa puede controlarse bajo RACF con diversos objetivos, entre los que podemos mencionar:

� Para controlar qué usuarios/grupos están autorizados a ejecutarlo.

� Porque es una exigencia del sistema que el programa esté controlado (usualmente, para mantener lo que se conoce como “entorno limpio”).

� Para hacer uso de la funcionalidad PADS.

En lo referente al segundo punto, es altamente recomendable, tal cual veremos en los ejemplos subsiguientes, definir un perfil ** en la clase PROGRAM con UACC=READ y una lista de bibliotecas asociadas cuyos programas necesiten estar controlados.

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, al tener que matchear con el nombre del programa, debe constar de un único calificador y no exceder los 8 caracteres. Si bien la clase PROGRAM no admite perfiles genéricos, es

108


posible usar el caracter * al final del nombre del perfil, que indica la presencia de 0 o más caracteres (hasta una longitud máxima de 8). También es posible definir un perfil **. Sin embargo, al listarlos, como se trata realmente de perfiles discretos, no aparecerá la característica (G) a continuación del nombre del perfil, como sí sucede con los perfiles genéricos genuinos.

A través del operando ADDMEM se especifica la biblioteca dónde reside el programa a controlar, junto con ciertos parámetros adicionales. Con posterioridad a la creación del perfil, pueden agregarse o eliminarse bibliotecas de la lista usando el comando RALTER con los operandos ADDMEM o DELMEM, según corresponda.

El nombre de la biblioteca debe ponerse entre apóstrofes simples, ya que en caso contrario RACF antepone automáticamente como HLQ el PREFIX de TSO del usuario que ejecuta el comando.

El volumen es opcional, y especifica el disco dónde reside la biblioteca. Existe la posibilidad de codificar el valor ‘******’ (incluidos los apóstrofes), lo cual indica que la biblioteca se encuentra alocada en el SYSRES (disco residente). En caso de no especificarse volumen, que es lo más habitual, la biblioteca puede existir en cualquier disco.

La opción PADCHK|NOPADCHK hace referencia a la funcionalidad PADS, que no trataremos en esta guía. Si no se utiliza PADS, es conveniente codificar explícitamente NOPADCHK (el valor por defecto es PADCHK).

Ejemplos:

1. RDEFINE PROGRAM adrdssu UACC(none) ADDMEM(‘sys1.linklib’//NOPADCHK)

2. RDEFINE PROGRAM fin* UACC(none) ADDMEN(‘finanzas.loadlib’//NOPADCHK)

3. RDEFINE PROGRAM ** UACC(read) ADDMEN(‘sys1.linklib’//NOPADCHK)

En ningún caso se codificó volumen, con lo cual la biblioteca especificada puede residir en cualquiera.

El perfil definido en (1) protege exclusivamente al programa ADRDSSU residente en la biblioteca SYS1.LINKLIB. Este perfil no protege a otros programas de nombre ADRDSSU que pudieran existir en otras bibliotecas. Como el UACC del perfil es NONE, solo estarían en condición de ejecutarlo aquellos usuarios o grupos autorizados vía la lista de acceso correspondiente.

El perfil definido en (2) protege todos los programas cuyo nombre empiece con la cadena FIN y residan en la biblioteca FINANZAS.LOADLIB, con excepción de aquellos que pudieran estar protegidos por un perfil más específico.

El perfil definido en (3) es, como ya señalamos, sumamente útil para simplemente controlar –sin restringir su ejecución- los programas de determinadas bibliotecas (generalmente, del sistema operativo). Como ya hemos comentamos, conviene definirlo como ** en lugar de *, de modo de poder listarlo individualmente. En este caso particular, el perfil protege a todos los programas de la biblioteca SYS1.LINKLIB, con excepción de aquellos que pudieran estar protegidos por un perfil más específico (como sería el caso de ADRDSSU, en nuestro ejemplo). Obsérvese que este perfil se definió con UACC=READ, lo cual muestra que su objetivo no es restringir la ejecución de los respectivos programas sino simplemente convertirlos en controlados. Se le pueden agregar más bibliotecas a través del comando RALTER, que mencionamos a continuación.

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])

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.

Para eliminar una biblioteca de la lista, basta con usar el operando DELMEM especificando el nombre y el volumen correspondiente (no hace falta codificar PADCHK|NOPADCHK). Si se especifica únicamente el nombre de la biblioteca, se borrará la entrada que no tenga volumen especificado, si ésta existiese (en caso contrario, se informa que no existe).

Ejemplo:

RALTER PROGRAM ** ADDMEN(‘tcpip.sezalink’//NOPADCHK)

Este comando agrega a la lista de datasets del perfil ** la biblioteca TCPIP.SEZALINK. En consecuencia, todos los programas de esta biblioteca pasan a ser programas controlados -pero ejecutables por todos los usuarios en virtud del UACC(READ) del perfil.

7.5 - Clase FACILITY

La clase FACILITY tiene la particularidad de no estar dedicada a la protección de un tipo de recurso específico, sino que es utilizada por gran cantidad de aplicaciones, productos y componentes del sistema operativo para efectuar chequeos de autoridad sobre recursos de la más diversa naturaleza. Es incluso frecuente, aunque a veces no del todo recomendable, 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.

Usualmente, la clase FACILITY se encuentra activa. En tal caso, es altamente recomendable que esté RACLISTeada y configurada de modo que admita el uso de perfiles genéricos. Los perfiles deben tener una longitud máxima de 39 caracteres y los nombres están determinados por la aplicación que los utiliza. Todas las consideraciones hechas previamente sobre clases de recursos generales se aplican para la clase FACILITY.

Dada la gran variedad de recursos factibles de ser protegidos, no es posible realizar un análisis exhaustivo de los perfiles en esta clase. Mas aún, considerando que cualquier producto (sea de IBM, de otra empresa proveedora de software, 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, sino que debe recabarse separadamente en la propia de cada producto.

En virtud de lo anterior, no es en absoluto recomendable definir un perfil abarcativo ** en la clase FACILITY. En general, los productos tienen comportamientos dispares frente a la condición de “recurso no protegido” (RC=04). Algunos, frente a la ausencia de un perfil protector, autorizan el acceso. Otros, en cambio, lo rechazan. Si se definiese el perfil **, todos los recursos pasarían a estar efectivamente protegidos, lo que significaría un cambio cuyas consecuencias –presentes y futuras- serían difíciles de prever.

Nos limitaremos pues a mencionar, a modo de ejemplo, algunas facilidades de uso frecuente que pueden ser protegidas en esta clase.

Facilidad para listar perfiles de usuario

Normalmente, la posibilidad de listar el segmento base de cualquier usuario está reservada a aquellos con el atributo SPECIAL o AUDITOR a nivel de sistema. Ambos atributos, claro está, brindan autorizaciones mucho más amplias y sensibles que las de simplemente listar la información de un perfil de usuario. Por lo tanto, dada la necesidad operativa de dotar a ciertos usuarios con la facilidad de ejecutar el comando LISTUSER (típicamente personal del Helpdesk), RACF brinda la posibilidad de delegar esta autorización a través de perfiles apropiados de la clase FACILITY. Concretamente, para otorgar a un usuario la facilidad de listar el segmento base de cualquier otro, se debe proceder del siguiente modo:

110


1) Definir el perfil IRR.LISTUSER en la clase FACILITY, con UACC=NONE.

2) Darle al usuario nivel de autoridad READ.

3) Ejecutar el comando “SETR RACLIST(FACILITY) REFRESH” (suponemos que la clase FACILITY se encuentra activa y RACLISTeada).

Observaciones:

� Por motivos de seguridad, están explícitamente excluidos del alcance de la autoridad dada por el recurso IRR.LISTUSER los usuarios con atributo SPECIAL, AUDITOR u OPERATIONS a nivel de sistema.

� Con excepción de los usuarios mencionados en el ítem anterior, la autorización sobre este recurso permite listar cualquier usuario de la base de RACF. Existe, desde la versión 1.10 del z/OS, la posibilidad de darle mucha más granularidad a esta facilidad. Por ejemplo, es factible otorgar a un usuario la posibilidad de listar únicamente aquellos que tengan un determinado owner, o que se encuentren dentro del campo de acción de determinado grupo. E incluso la posibilidad de excluir, de este universo, ciertos usuarios específicos. No ahondaremos, sin embargo, en los detalles de una implementación de este tipo en el presente texto, no por considerarla innecesaria, sino por estimar que excede los objetivos planteados.

� Si el perfil IRR.LISTUSER existe, solo agrega una posibilidad adicional en relación a la autoridad necesaria para listar perfiles de usuario. Los privilegios habituales siguen siendo suficientes. Por ejemplo, un usuario con atributo AUDITOR a nivel de sistema no requiere estar autorizado a este perfil.

� Si el perfil IRR.LISTUSER no se encuentra definido, rigen los chequeos de autoridad habituales para el uso del comando LISTUSER.

� En lugar del perfil discreto mencionado, sería posible definir un perfil genérico que proteja al recurso (ej: IRR.**). Sin embargo, esto no me parece recomendable, ya que este perfil estaría abarcando a otros recursos que pueden tener una necesidad de acceso diferente (ver ejemplo posterior).

� UACC=NONE es apropiado, ya que solo los usuarios cuyas tareas lo justifiquen deben contar con esta facilidad.

� Niveles de autoridad superiores a READ son equivalentes a READ, y por lo tanto totalmente innecesarios, con la siguiente salvedad: si el perfil es discreto, autoridad ALTER otorga privilegios administrativos sobre el perfil, lo cual probablemente constituya un efecto no buscado.

� Este recurso no autoriza a listar segmentos no base (TSO, OMVS, etc.). Para ello, deben definirse perfiles adecuados en la clase FIELDS.

Facilidad para rehabilitar usuarios y otorgar nuevas passwords

Del mismo modo que surgió la necesidad de permitir listar perfiles de usuario (sin necesidad de otorgar privilegios excesivos), 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. Para ello, debe procederse del siguiente modo:

1) Definir el perfil IRR.PASSWORD.RESET en la clase FACILITY, con UACC=NONE.

2) Darle al usuario el nivel de autoridad deseado, de acuerdo al siguiente detalle:

111


READ Permite rehabilitar un usuario revocado mediante el operando RESUME del comando ALTUSER. También autoriza a otorgar una nueva password (expirada).

UPDATE Aparte de lo que otorga READ, permite también la posibilidad de dar una nueva password no expirada.

CONTROL Aparte de lo que otorga UPDATE, permite asimismo dar una nueva password aún sin que haya pasado el tiempo de vida mínimo.

3) Ejecutar el comando “SETR RACLIST(FACILITY) REFRESH” (suponemos que la clase FACILITY se encuentra activa y RACLISTeada).

Observaciones:

� Por motivos de seguridad, están explícitamente excluidos del alcance de la autoridad dada por el recurso IRR.PASSWORD.RESET los usuarios con atributo SPECIAL, AUDITOR u OPERATIONS a nivel de sistema.

� Con excepción de los usuarios mencionados en el ítem anterior, la autorización sobre este recurso permite actuar sobre cualquier usuario de la base de RACF. Existe también en este caso la posibilidad de darle mucha más granularidad a esta facilidad. Por ejemplo, es factible otorgar a un usuario la posibilidad de rehabilitar únicamente aquellos que tengan un determinado owner, o que se encuentren dentro del campo de acción de determinado grupo. E incluso la posibilidad de excluir, de este universo, ciertos usuarios específicos. No ahondaremos, sin embargo, en los detalles de una implementación de este tipo.

� Si el perfil IRR.PASSWORD.RESET existe, solo agrega una posibilidad extra respecto a la autoridad necesaria para la rehabilitación de usuarios. Los privilegios habituales siguen siendo suficientes. Por ejemplo, un usuario con atributo SPECIAL a nivel de sistema no necesita autorización sobre este perfil.

� Si el perfil IRR.PASSWORD.RESET no se encuentra definido, rigen los chequeos de autoridad habituales para el uso del comando ALTUSER.

� El nivel de autoridad ALTER resulta equivalente a CONTROL, con la siguiente salvedad: si el perfil es discreto, otorga privilegios administrativos sobre el perfil, lo cual probablemente constituya un efecto no deseado.

Facilidad para acceder a datasets no catalogados

Es frecuente, y recomendable, que la organización tenga la opción CATDSNS en modo FAIL seteada en la SETROPTS. De este modo, queda fuertemente restringida la posibilidad de acceder a archivos que no se encuentren catalogados (lo cual debería constituir una situación de excepción).

Sin embargo, suele suceder que usuarios responsables del mantenimiento del sistema operativo necesiten acceder a datasets no catalogados (por ejemplo, abriendo desde una partición un archivo catalogado en otra). A tal efecto, es factible definir perfiles apropiados en la clase FACILITY que brinden esta facilidad, sin necesidad de dar al usuario el atributo SPECIAL (que permite, asimismo, el acceso a datasets no catalogados).

Como ya hemos comentado en un capítulo anterior, para datasets no catalogados (y no protegidos por un perfil discreto), RACF construye el recurso de nombre ICHUNCAT.dsname, dónde dsname es el nombre del archivo (solo los 30 primeros caracteres se consideran). RACF chequea entonces la autoridad del usuario sobre este recurso en la clase FACILITY, y si es READ (o superior), entonces no rechaza el acceso por la condición de no catalogado. Niveles de autoridad superiores a READ en este tipo de perfiles son equivalentes a READ, y por lo tanto innecesarios (este nivel de autoridad no tiene relación alguna con el nivel de autoridad requerido sobre el perfil de dataset protector del archivo, que

112


depende obviamente del tipo de operación que se pretende realizar). Naturalmente, sortear el chequeo de “no catalogado” no elimina de ninguna manera los habituales chequeos posteriores (normalmente, en la clase DATASET).

Ejemplo:

Supongamos que el usuario SYSPRG1 debe acceder a datasets no catalogados cuyos nombres son de la forma TEST.CONFIG.**, y que éstos están protegidos por perfiles de dataset sobre los cuales el usuario tiene suficiente autoridad. Para ello, basta definir el perfil genérico ICHUNCAT.TEST.CONFIG.** en la clase FACILITY y otorgarle al usuario SYSPRG1 autoridad READ.

Si no es requerido este nivel de granularidad, puede definirse únicamente el perfil genérico ICHUNCAT.**, que brinda a los usuarios autorizados la posibilidad de acceder a cualquier archivo no catalogado. Sin que ello exceptúe, recalquémoslo nuevamente, los chequeos usuales de acceso a archivos.

113


8 – PROCESO DE CHEQUEO DE AUTORIDAD


RACF no otorga ni rechaza solicitudes de acceso a recursos. Se limita a responder los requerimientos que recibe de las distintas aplicaciones, subsistemas y demás componentes del sistema operativo mediante la devolución de un código de retorno, que puede ser 0, 4 u 8, y cuyo significado es el siguiente:

0 RACF considera que la solicitud de acceso debe aceptarse

4 RACF no posee información para responder sobre la solicitud de acceso

8 RACF considera que la solicitud de acceso debe rechazarse

En cualquier caso, es finalmente la aplicación la que decide aceptar o rechazar el requerimiento de acceso. Por ejemplo, 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. De todos modos, salvo casos excepcionales, 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. Hecha esta importante aclaración, en lo que sigue, 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.

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.

8.2 - Autoridad de un usuario sobre un recurso

Recordemos que la solicitud de acceso que recibe RACF consta, esencialmente, de la siguiente información:

� Nombre de la clase

� Nombre del recurso

� Nivel de acceso requerido (EXECUTE, READ, UPDATE, CONTROL o ALTER)

� Identificador del usuario

RACF procesa la solicitud de acceso siguiendo en orden, básicamente, los pasos que enumeramos a continuación. Si en alguno de ellos RACF autoriza el requerimiento, lo rechaza, o bien devuelve el código de retorno 4 (código de no protegido), el proceso termina y los pasos subsiguientes son omitidos. Para simplificar, obviamos toda mención de security levels, categories y security labels, así como también suponemos no se han implementado exits de RACF (ni del SAF).

Pasos del proceso de chequeo

1. Si RACF no está activo en el sistema, se devuelve el código de “no protegido”.

2. Si se trata de una clase de recursos generales que no se encuentra activa en la SETROPTS, RACF devuelve el código de “no protegido”.

3. Si la clase debería estar RACLISTeada de acuerdo a lo que especifica la CDT, pero no lo está, RACF devuelve el código de “no protegido”.

4. Si el requerimiento proviene de una STC marcada TRUSTED o PRIVILEGED, RACF lo autoriza.

114


5. Si la clase está bajo GLOBAL en la SETROPTS, y la información de la GAC indica que debe accederse a la solicitud, se autoriza el acceso, excepto que el usuario tenga el atributo RESTRICTED, en cuyo caso el proceso continúa.

6. RACF busca el perfil protector del recurso. Si no encuentra al recurso protegido y se trata de una clase de recursos generales, devuelve como código de retorno el DEFRETC de la clase especificado en la CDT. Si la clase es DATASET y no existe perfil protector, continúa en el paso 19.

7. Si el recurso es considerado propiedad del usuario, RACF autoriza el requerimiento. Un ejemplo típico son datasets cuyo HLQ coincida con el identificador del usuario. Notemos que esto no tiene ninguna relación con el concepto de owner del perfil.

8. RACF busca el identificador del usuario en la lista de acceso estándar del perfil protector del recurso. Si el usuario figura en ella con un nivel igual o superior al solicitado, RACF autoriza el requerimiento. Si el usuario figura en ella pero con un nivel inferior al solicitado, RACF continúa en el paso 14 (por lo tanto, ID(*), UACC y atributo OPERATIONS no cuentan).

9. Si la opción GRPLIST no está activa en la SETROPTS, RACF busca el “actual grupo de conexión” del usuario en la lista de acceso estándar del perfil protector. Si el grupo figura en ella con un nivel igual o superior al solicitado, RACF autoriza el requerimiento. Si el grupo figura en ella pero con un nivel inferior al solicitado, RACF continúa en el paso 14 (por lo tanto, ID(*), UACC y atributo OPERATIONS no cuentan).

10. Si la opción GRPLIST está activa en la SETROPTS, 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. Si uno o más de estos grupos figuran en ella, RACF selecciona el nivel de autoridad más elevado. Si tal nivel es igual o superior al solicitado, RACF autoriza el requerimiento. Si, por el contrario, el nivel resultante es inferior, RACF continúa en el paso 14 (por lo tanto, ID(*), UACC y atributo OPERATIONS no cuentan).

11. RACF busca si existe una entrada * en la lista de acceso estándar del perfil protector. En caso afirmativo, si el nivel de autoridad asociado es igual o superior al solicitado, y el usuario existe en la base de RACF y no tiene el atributo RESTRICTED, RACF autoriza el requerimiento. Si el nivel asociado a la entrada * es, en cambio, inferior al solicitado, RACF continúa en el paso 13 (por lo tanto el UACC no cuenta en este caso).

12. Si el UACC del perfil protector es igual o superior al nivel solicitado, y el usuario no tiene el atributo RESTRICTED, RACF autoriza el requerimiento.

13. Si la clase está alcanzada por el atributo OPERATIONS y el usuario lo posee, ya sea a nivel de sistema o a nivel de un grupo que tenga al perfil protector dentro de su campo de acción, entonces RACF autoriza el requerimiento.

14. RACF busca el identificador del usuario en la lista de acceso condicional del perfil protector del recurso. Si el usuario figura en ella con un nivel igual o superior al solicitado y se cumple la condición correspondiente, RACF autoriza el requerimiento.

15. Si la opción GRPLIST no está activa en la SETROPTS, RACF busca el “actual grupo de conexión” del usuario en la lista de acceso condicional del perfil protector. Si el grupo figura en ella con un nivel igual o superior al solicitado y se cumple la condición correspondiente, RACF autoriza el requerimiento.

115


16. Si la opción GRPLIST está activa en la SETROPTS, RACF busca en la lista de acceso condicional del perfil protector la presencia de los eventuales grupos a los que el usuario está conectado. Si uno o más de estos grupos figuran en ella para la condición dada, RACF selecciona el nivel de autoridad más elevado. Si tal nivel es igual o superior al solicitado, RACF autoriza el requerimiento.

17. RACF busca si existe una entrada * en la lista de acceso condicional del perfil protector. En caso afirmativo, si el nivel de autoridad asociado es igual o superior al solicitado, se cumple la condición correspondiente, el usuario existe en la base de RACF y no tiene el atributo RESTRICTED, RACF autoriza el requerimiento.

18. Si el perfil protector está en modo WARNING, RACF autoriza el requerimiento.

19. Si se está intentando acceder a un archivo no protegido y la opción PROTECT-ALL está activa en la SETROPTS en modo FAILURES, RACF rechaza el requerimiento, excepto que el usuario tenga el atributo SPECIAL a nivel de sistema, en cuyo caso lo autoriza. Si la opción PROTECT-ALL no está activa, o lo está pero en modo WARNING, RACF autoriza el requerimiento.

20. RACF finalmente rechaza el requerimiento.

Observaciones:

� Si la solicitud de acceso es sobre un dataset no catalogado, RACF toma en cuenta además el seteo de la opción CATDSNS en la SETROPTS, que ya analizamos en el capítulo correspondiente.

� La lista de acceso estándar se chequea siempre antes que la condicional.

� La presencia del usuario, 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, ID(*) o atributo OPERATIONS.

� Salvo casos puntuales (acceso a archivos “no catalogados” o “no protegidos”), el atributo SPECIAL no es chequeado en ningún paso durante el proceso. Esto es coherente con lo que ya hemos señalado, en el sentido de que tal atributo no otorga acceso a recursos.

116


9 - PROGRAMAS UTILITARIOS


RACF provee varios programas utilitarios que permiten manipular, diagnosticar problemas y extraer información de la base de RACF. En este capítulo expondremos los que consideramos más importantes. Los que analizaremos deben ejecutarse en forma batch, por lo cual mostraremos un job a modo de ejemplo y, en ciertos casos, una salida típica del utilitario. Naturalmente, la tarjeta job debe ser personalizada de acuerdo a las exigencias de cada organización (nombre del job; código de cuenta; clase; prioridad; etc.). Los programas invocados por los distintos utilitarios residen en la biblioteca SYS1.LINKLIB, por lo cual el sistema los localizará sin necesidad de codificar JOBLIB o STEPLIB en el job.

9.2 - IRRUT100

Este utilitario permite localizar en la base todas las ocurrencias de un usuario o grupo dado. Al ser un programa que debe examinar todos los perfiles de la base, es recomendable ejecutarlo fuera de horarios pico de actividad, para no impactar negativamente en la performance del sistema.

Hacemos notar que no existe un comando de RACF que permita, dado un usuario o grupo, listar todos los perfiles dónde figure en las listas de acceso. El utilitario IRRUT100 puede ser usado para obtener esta información (aunque también existen otros métodos, que mencionaremos más adelante).

Este utilitario siempre toma la información de la base de RACF activa en la LPAR dónde se ejecuta. No es posible correr el IRRUT100 especificando una base de RACF distinta de la activa.

Ejemplo de IRRUT100:

//REFX100 JOB cuenta,programmer,

// MSGLEVEL=(1,1),MSGCLASS=clase,CLASS=clase,PRTY=valor

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

//PASO1 EXEC PGM=IRRUT100

//SYSPRINT DD DSN=RACF.IRRUT100.SALIDA,DISP=OLD

//SYSUT1 DD UNIT=SYSDA,SPACE=(TRK,(20,4))

//SYSIN DD *

jef2514 conta

/*

//

El programa invocado debe ser IRRUT100.

La DD SYSPRINT es obligatoria y define dónde el utilitario grabará la información de salida. Puede tratarse de un archivo secuencial (en disco o en cartucho), o bien puede especificarse un dispositivo de salida. En nuestro ejemplo, esta información se grabará en el dataset de nombre RACF.IRRUT100.SALIDA, que suponemos prealocado.

La DD SYSUT1 es obligatoria y define un dataset de trabajo, que debe residir en disco.

La DD SYSIN es obligatoria e indica el dataset de control del utilitario. Consiste de un listado de usuarios o grupos sobre los que se pretende buscar referencias. Esta información de entrada puede estar embebida en el mismo jobstream (usando DD *) o bien residir en un archivo (secuencial o particionado). En nuestro ejemplo, la SYSIN está inserta dentro del jobstream y establece que se busque toda referencia en la base respecto al usuario JEF2514 y el grupo CONTA (en rigor, tan solo mirando los identificadores, no es posible distinguir si se trata de grupos o usuarios).

117



Occurrences of JEF2514

In notify field of general resource profile PROGRAM FTPDNS

In standard access list of general resource profile PROGRAM FTPDNS

In standard access list of dataset profile CONTA.** (G)

In standard access list of dataset profile JEF2514.** (G)

First qualifier of profile JEF2514.** (G)

In access list of group CONTA

In access list of group PAGOS

User entry exists

Owner of user CON001

(G) - Entity name is generic

Occurrences of CONTA

In standard access list of general resource profile ACCTNUM CONTABILIDAD

In standard access list of general resource profile TSOPROC IKJCONTA

In standard access list of general resource profile TERMINAL FINA* (G)

In standard access list of general resource profile TAPEVOL CON* (G)

In standard access list of dataset profile CONTA.** (G)

First qualifier of profile CONTA.** (G)

In standard access list of dataset profile CONTA.A200%.** (G)

First qualifier of profile CONTA.A200%.** (G)

In standard access list of dataset profile PAGOS.PROVEE.** (G)

In standard access list of dataset profile PUBLIC.** (G)

Group name exists

In subgroup list of group FINANZAS

Connect group for user CONJF01

Default group for user CONJF01

Connect group for user CONJF02

Default group for user CONJF02

Connect group for user JEF2514

(G) - Entity name is generic.

Observemos que la salida no solo muestra la presencia del usuario o grupo en las listas de acceso, sino también en cualquier otro campo de los perfiles, como ser OWNER o NOTIFY. Incluso informa si el usuario o grupo especificado es el HLQ de algún perfil de dataset.

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. Por ejemplo, nos informa, en nuestro caso, que el usuario JEF2514 está en la lista de acceso estándar del perfil de dataset CONTA.**, pero no especifica si figura con nivel de autoridad NONE, EXECUTE, READ, UPDATE, CONTROL o ALTER. En consecuencia, si se pretende definir un nuevo usuario o grupo que tenga exactamente las mismas autorizaciones que otro existente, no es suficiente la información suministrada por el IRRUT100.

Autoridad requerida

Para ejecutar el IRRUT100 especificando un determinado usuario o grupo, se debe tener el atributo SPECIAL o AUDITOR a nivel de sistema o a nivel de un grupo que tenga al usuario o grupo en cuestión dentro de su campo de acción.

118


9.3 - IRRUT200

Este utilitario tiene los siguientes usos básicos:

� Identifica inconsistencias en la organización interna de la base de RACF. Es solo una herramienta de diagnóstico, ya que en caso de detectar errores no realiza ninguna reparación.

� Informa el porcentaje de utilización efectiva del espacio en la base de RACF. Esta información es útil para decidir si es necesario un redimensionamiento.

� Permite realizar una copia exacta (bloque a bloque) de la base de RACF. Es pues una herramienta extremadamente útil para realizar un backup en disco de la base.

� Permite sincronizar las bases de uso primario y backup.

Ejemplo de IRRUT200 para diagnóstico:

//DIAG200 JOB cuenta,programmer,


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


//SYSRACF DD DSN=SYS1.BASERACF,DISP=SHR

//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(20)),DCB=(LRECL=4096,RECFM=F)

//SYSUT2 DD SYSOUT=clase

//SYSPRINT DD SYSOUT=clase

//SYSIN DD *

INDEX [FORMAT]

MAP [ALL]

END

/*

//


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 dataset activo o no. En cualquier caso, si SYSUT1 ya contiene una copia del archivo a analizar, entonces la DD SYSRACF puede omitirse.

La DD SYSUT1 define un archivo de trabajo que debe residir en disco y tener idénticas características que el dado por SYSRACF (en nuestro ejemplo asumimos que SYS1.BASERACF tiene un tamaño de 20 cilindros). El utilitario IRRUT200 procede, como primera medida, a copiar el dataset definido en SYSRACF al especificado en SYSUT1 (para ello utiliza internamente el programa IEBGENER). Terminada la copia, se libera SYSRACF y el programa prosigue realizando las verificaciones pertinentes sobre la copia recién obtenida. De esta manera se minimiza el tiempo en que el utilitario mantiene la reserva sobre la base de RACF. SYSUT1 debe ser distinto a SYSRACF, sino el utilitario falla. Tampoco SYSUT1 puede especificar un dataset de RACF activo, pues también el job fallaría. Este control del utilitario evita que, por error, se corrompa un dataset activo usándolo como archivo de salida.

Si no se codifica SYSUT1, se usa el dataset definido en SYSRACF durante todo el proceso. Si es un dataset activo, esto no es aconsejable pues se mantendría la reserva hasta la finalización del job, pudiendo causar problemas operativos.

La DD SYSUT2 define dónde el utilitario grabará ciertos mensajes de salida. Puede tratarse de un archivo secuencial (en disco o en cartucho), o bien puede especificarse un dispositivo de salida.

119


La DD SYSPRINT define dónde el utilitario grabará la información de diagnóstico generada. Puede tratarse de un archivo secuencial (en disco o en cartucho), o bien puede especificarse un dispositivo de salida.

La DD SYSIN es obligatoria e indica el dataset de control del utilitario. La información puede estar en el mismo jobstream (lo más frecuente, usando DD *), o bien residir en un archivo. Las sentencias de control admitidas son:

� INDEX [FORMAT]

� MAP [ALL]

� END

INDEX especifica que se lleve a cabo la función de escaneo de índice. El parámetro FORMAT, en caso de codificarse, debe estar separado de INDEX por un único espacio en blanco, e indica que se muestre en la salida un listado formateado de todos los bloques de índice.

MAP establece que se lleve a cabo una verificación a nivel de BAM (Block Availability Mask). El parámetro ALL, en caso de codificarse, debe estar separado de MAP por un único espacio en blanco, e indica que se muestre en la salida un mapa de todos los bloques BAM de la base.

END indica el final del proceso.

Para interpretar en su totalidad la información de diagnóstico suministrada por el IRRUT200 es necesario conocer profundamente la organización interna de una base de RACF, tema complejo que escapa completamente a los objetivos de la presente guía. De todos modos, es recomendable correr esta herramienta de diagnóstico con cierta regularidad (semanalmente, o mensualmente, por ejemplo), con el propósito de verificar que el utilitario no encuentre inconsistencias lógicas en la organización interna de la base. Si el IRRUT200 detectara algún tipo de problema, será necesario corregirlo, para lo cual deberá consultarse la documentación correspondiente que brinda IBM. Mencionemos asimismo que no todos los posibles problemas internos de una base de RACF son detectados por el IRRUT200. De todos modos, RACF es un producto sumamente estable y probado, y con un manejo adecuado, es realmente poco probable que aparezcan errores lógicos.

Si se ejecuta el IRRUT200 con la opción MAP, en la salida SYSPRINT aparece una serie de estadísticas interesantes, entre las que se incluyen la cantidad de perfiles existentes en cada clase y el porcentaje de ocupación de la base. Para evitar problemas repentinos por falta de espacio, es conveniente controlar que este valor no supere, digamos, el 75%. Si se estuviera por encima, sería conveniente programar una ampliación y reorganización de la base (ver el utilitario IRRUT400).

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 - RBA 00000000D000 RACF DATA SET IS 41 PERCENT FULL. TOTAL NUMBER OF INDEX BLOCKS IN RACF DATA SET 00000198 TOTAL NUMBER OF LEVEL 01 BLOCKS IN RACF DATA SET 00000190 NUMBER OF GROUP ENTRIES - 0000173 NUMBER OF USER ENTRIES - 0004305 NUMBER OF DATASET ENTRIES - 0000428 NUMBER OF RACFVARS ENTRIES - 0000001 NUMBER OF SECLABEL ENTRIES - 0000003 NUMBER OF DASDVOL ENTRIES - 0000004 NUMBER OF TERMINAL ENTRIES – 0000086 NUMBER OF APPL ENTRIES – 00000021 NUMBER OF TCICSTRN ENTRIES - 0000002 NUMBER OF GCICSTRN ENTRIES - 000092 NUMBER OF GLOBAL ENTRIES - 0000003

120


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

Observemos, como dato importante, que se informa que el dataset está ocupado en un 41%. Esta es la única forma de determinar el porcentaje de ocupación efectivo de una base de RACF. Los datasets de RACF están formateados íntegramente. Por lo tanto, si se listaran sus características de alocación (por ejemplo, con el comando S en la opción 3.4 Dslist del ISPF), se vería un uso del 100%, que de ninguna manera refleja su ocupación real.

En la salida SYSUT2 se tendrían, por ejemplo, los siguientes mensajes:

DATA SET UTILITY - GENERATE

PROCESSING ENDED AT EOD IRR62065I - IEBGENER copied SYSRACF to the work dataset SYSUT1, IEBGENER RC=0000

Ejemplo de IRRUT200 para hacer una copia de backup:

//BACK200 JOB cuenta,programmer,


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



//SYSUT1 DD DSN=RACF.COPIA,DISP=OLD



//SYSIN DD DUMMY

//

En este ejemplo el programa utilitario IRRUT200 se emplea para realizar una copia exacta, bloque a bloque, del dataset de RACF especificado en la DD SYSRACF. La copia se generará en el dataset RACF.COPIA especificado en SYSUT1, que suponemos prealocado y con idénticas características y tamaño que la entrada SYS1.BASERACF.

La DD SYSIN definida como DUMMY en este ejemplo establece que no se lleve a cabo ninguna función de diagnóstico.

En su uso como herramienta de backup, el IRRUT200 solo sirve para realizar una copia de la base a una que resida en un disco de igual geometría que la original y tenga igual tamaño. El dataset especificado en SYSUT1 no debe ser nunca una base de RACF activa (en este u otro sistema), ya que el utilitario

121


podría corromperlo durante la copia. Si se pretende copiar una base a otra de distinto tamaño, debe usarse el utilitario IRRUT400, que veremos más adelante.

Ejemplo de IRRUT200 para sincronizar las bases:



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

//PASO1 EXEC PGM=IRRUT200,PARM=’ACTIVATE’

//SYSRACF DD DSN=SYS1.RACF.PRIM,DISP=SHR

//SYSUT1 DD DSN=SYS1.RACF.BACK,DISP=OLD


//

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, si la base estuviera distribuida en más de uno). RACF verificará que SYSRACF especifique efectivamente la base primaria de RACF y SYSUT1 la de backup. Se comprobará asimismo que el backup se encuentre inactivo (recordemos que nunca el destino de una copia debe ser un dataset de RACF activo). Finalizada la copia de SYSRACF (base primaria activa) sobre SYSUT1 (base de backup inactiva), se activará la base de backup antes de liberarse la base primaria. Solo de este modo queda garantizado que la base de backup resulte idéntica a la primaria. En efecto, si en lugar de activar el backup el mismo IRRUT200 lo hiciera un administrador con el comando RVARY, las eventuales modificaciones sobre la base primaria ocurridas entre la finalización del job y la ejecución del comando de activación no se verían replicadas el backup.

Con PARM=ACTIVATE, las DD SYSPRINT y SYSIN, si estuvieran presentes, son ignoradas.

Autoridad requerida

Para ejecutar el utilitario IRRUT200, basta con tener autoridad READ sobre el dataset especificado en SYSRACF y UPDATE sobre el dado por SYSUT1 (o ALTER, si es alocado dinámicamente por el job como archivo permanente). Naturalmente, si los programas IRRUT200 o IEBGENER estuviesen protegidos en la clase PROGRAM, se necesita asimismo autoridad para ejecutarlos.

9.4 - IRRUT400

Este utilitario tiene varias funciones:

� Permite copiar la base de RACF a otra de tamaño distinto, que puede incluso residir en un disco de distinta geometría.

� Permite distribuir un dataset de la base de RACF en varios datasets. Asimismo, también puede utilizarse para consolidar varios datasets de la base en una menor cantidad. Recordemos que RACF admite un máximo de 90 datasets para su base primaria, e idéntica cantidad para la base de backup.

� Identifica cierto tipo de inconsistencias en los datasets de la base, como ser la presencia de perfiles duplicados.

� Reorganiza físicamente la base, juntando los eventuales segmentos de un mismo perfil.

En cualquiera de sus usos, es recomendable ejecutar este utilitario fuera de los horarios pico de actividad, de modo de no afectar negativamente la performance del sistema.

En la presente guía no analizaremos la funcionalidad del IRRUT400 respecto a la posibilidad de distribuir (split) o consolidar (merge) los datasets que conforman la base. Nos ocuparemos exclusivamente del uso del utilitario como herramienta de copia y reorganización. Tampoco

122


describiremos todos los parámetros que admite el programa, sino el único cuya especificación es obligatoria.

Si se quiere obtener una copia idéntica, es preferible emplear el utilitario IRRUT200 pues se encarga de serializar adecuadamente el uso de la base de origen, garantizando una copia completamente fiel de la original. En cambio, si la copia desea hacerse a una base de distinto tamaño, o residente en un disco de distinta geometría (de 3380 a 3390, por ejemplo), entonces debe necesariamente utilizarse el IRRUT400.

El IRRUT400, a diferencia del IRRUT200, no solo copia sino que reorganiza la base. Para comprender exactamente el alcance del proceso de reorganización, es necesario tener un conocimiento acabado de la estructura interna de la base de RACF, lo cual excede los objetivos de esta guía. Mencionemos simplemente que se trata, esencialmente, de una especie de desfragmentación, consistente en reubicar físicamente contiguos aquellos segmentos correspondientes a un mismo perfil. Si la base se encuentra muy fragmentada (lo cual puede diagnosticarse a través del IRRUT200), esta reorganización puede mejorar la performance de RACF, al disminuir la cantidad de lecturas de bloques que RACF debe realizar para obtener la información completa de un determinado perfil.

Del mismo modo que para el IRRUT200, la base de destino no debe nunca estar activa en ningún sistema. Más aún, si estuviera activa en el mismo sistema dónde se ejecuta el job, el utilitario falla. En cambio, la base de origen (esto es, la que se pretende copiar) puede o no estar activa. Si se encuentra activa, el IRRUT400 permite manejar el bit de lockeo de la base, que establece si la misma se encuentra lockeada o no-lockeada.

Base lockeada

En este estado, no se permite ninguna actualización sobre la base, con excepción de cierta información estadística. En consecuencia, no pueden definirse, modificarse o deletearse perfiles, así como tampoco modificarse opciones de la SETROPTS. Más aún, algunos usuarios no podrán loguearse. Esto sucederá, por ejemplo, si se trata de su primer logon del día, si intentan cambiar su password, o si han ingresado su password correcta luego de algún intento inválido.

Estando la base lockeada, el chequeo de autoridad de usuarios sobre recursos se lleva a cabo normalmente. Por lo tanto, los usuarios que se encuentran logueados a alguna aplicación no deberían notar ninguna diferencia, excepto naturalmente que intenten modificar información de la base de RACF. En cualquier caso, solo se justifica tener la base lockeada durante alguna tarea de mantenimiento específica y por un período muy breve.

Base no-lockeada

Se trata del estado natural de la base, en el cual todas las actualizaciones están permitidas. Las bases de RACF, tanto la primaria como la backup, deben estar no-lockeadas, salvo que exista una situación que requiera explícitamente lo contrario, lo cual es poco frecuente y por un período corto de tiempo.

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. No existe ningún valor por defecto, por lo cual debe necesariamente codificarse alguna de las 3 opciones, cuyo significado analizamos a continuación.

LOCKINPUT lockea la base de origen antes de iniciar el proceso de copia. De este modo, se garantiza que la copia tenga idéntica información que la original, al no permitirse actualizaciones durante el proceso. Se trata de la opción más recomendable, aunque tiene la desventaja de mantener lockeada la base de origen durante el tiempo que insume el utilitario, lo cual puede, si se trata de una base activa, acarrear ciertas dificultades operativas. Si se especificó LOCKINPUT, la base de origen quedará lockeada aún luego de terminado el proceso de copiado. Si se trata de una base activa que se seguirá utilizando, es imprescindible deslockearla. Para ello basta con agregar al job un paso adicional, que invoque nuevamente el programa IRRUT400 pero con el parámetro UNLOCKINPUT.

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



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

//COPIA EXEC PGM=IRRUT400,PARM=’LOCKINPUT’

//INDD1 DD DSN=SYS1.BASERACF,DISP=OLD

//OUTDD1 DD DSN=RACF.COPIA,DISP=OLD


//UNLOCK EXEC PGM=IRRUT400,PARM=’UNLOCKINPUT’

//INDD1 DD DSN=SYS1.BASERACF,DISP=OLD


//


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ó

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 JOB cuenta,programmer,


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

//BAJADA EXEC PGM=IRRDBU00,PARM=’NOLOCKINPUT’

//INDD1 DD DSN=SYS1.BASERACF.COPIA,DISP=SHR

//OUTDD DD DSN=RACF.PLANO,DISP=OLD


//

El programa invocado debe ser IRRDBU00.

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.

126


El IRRRID00 utiliza como entrada la bajada plana de la base de RACF generada por el IRRDBU00. Es pues necesario ejecutar el utilitario IRRDBU00 como paso previo a la utilización del IRRRID00, salvo que ya se disponga de una bajada plana de la base suficientemente actualizada.

Ejemplo de IRRRID00

//IRRRID JOB cuenta,programmer,


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

//PASO EXEC PGM=IRRRID00,REGION=25M


//SYSOUT DD SYSOUT=clase

//SORTOUT DD UNIT=SYSDA,SPACE=(CYL,(10,2))

//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(10,2))

//INDD DD DSN=RACF.PLANO,DISP=SHR

//OUTDD DD DSN=RACF.IRRRID.SALIDA,DISP=OLD

//SYSIN DD *

jef2514

/*

//

El programa invocado debe ser IRRRID00.

La DD SYSPRINT determina 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.

La DD SYSOUT define dónde el DFSORT (o programa equivalente) invocado internamente por el utilitario grabará los mensajes de salida. Puede tratarse de un archivo secuencial (en disco o en cartucho), o bien puede especificarse un dispositivo de salida.

La DD SORTOUT define un archivo de trabajo, cuyo tamaño debe ser similar al especificado en INDD. Lo más adecuado es dejar que el sistema lo aloque como un dataset temporario, que será en consecuencia automáticamente eliminado al finalizar el job.

La DD SYSUT1 define otro archivo de trabajo, cuyo tamaño debe ser también similar al especificado en INDD. Lo más adecuado es dejar que el sistema lo defina como un dataset temporario.

La DD INDD define el dataset de entrada del utilitario, que debe obligatoriamente ser una bajada plana generada por el IRRDBU00.

La DD OUTDD especifica el dataset de salida del IRRRID00 dónde se generarán los comandos necesarios para eliminar las referencias residuales correspondientes. Debe tener las siguientes características:

RECFM=VB (registros de longitud variable y bloqueados)

LRECL=259 (como mínimo)

En nuestro ejemplo, se supone que el dataset RACF.IRRRID.SALIDA está prealocado.

La DD SYSIN define el listado de usuarios y/o grupos sobre los que se quiere buscar las referencias residuales. La información puede estar embebida en el mismo jobstream (usando DD *), o bien residir en un dataset (secuencial o particionado). Cada usuario o grupo debe estar en un registro separado, y si se especifica un “ID de reemplazo”, debe estar a continuación, separado exactamente por un espacio en blanco.

El “ID de reemplazo” funciona del siguiente modo:

127


Si el usuario o grupo del cual se buscan referencias figura en un campo del cual no puede eliminarse, como es el caso si es el owner de un perfil, entonces el utilitario generará en la salida el comando necesario para cambiar esta ocurrencia por el ID de reemplazo especificado. En caso de no codificarse un “ID de reemplazo”, en el comando de salida figurará en tal caso el usuario/grupo precedido de un ?, de modo que pueda editarse con un valor apropiado.

Si no se define SYSIN, o bien se aloca como DUMMY o vacía de contenido, el utilitario busca todas las referencias en la base de usuarios y grupos que ya no existen. Es saludable ejecutar regularmente el IRRRID00 de esta manera, de modo a detectar y borrar información residual que pueda haber quedado al no borrarse adecuadamente un usuario o grupo de la base.

En nuestro ejemplo, la SYSIN está inserta dentro del jobstream y establece que se busque toda referencia en la base respecto al usuario JEF2514.

La salida podría tener el siguiente aspecto:

/****************************************************************************************/ /* */ /* The RACF Remove ID Utility (IRRRID00) was executed on */ /* 2011-09-10 at 14:05:03. */ /* */ /* This file contains RACF commands that can be used to */ /* identify references to user IDs and group IDs. Residual */ /* references on an access list are deleted with the PERMIT */ /* command. For all other references, commands are created to */ /* change the reference to another value. The default value */ /* is ?id. This allows all references to a particular ID to */ /* be easily changed to another value using a text editor. */ /* */ /* Commands to alter ROLE definitions will be created within */ /* comments for informational purposes, though the actual */ /* updates should be made from TME. The ROLE will not be */ /* updated with a replacement value for a group name. */ /* */ /****************************************************************************************/

CONNECT CONJF01 GROUP(CONTA) OWNER(?JEF2514 ) PERMIT 'CONTA.**' GENERIC ID(JEF2514) DELETE PERMIT 'FINAN.**' GENERIC ID(JEF2514) DELETE PERMIT FTPDNS CLASS(PROGRAM) ID(JEF2514) DELETE RALTER PROGRAM FTPDNS NONOTIFY RALTER PROGRAM FTPDNS OWNER(?JEF2514 )

*****************************************************************************************/ * The following commands delete profiles. You must review */ * these commands, editing them if necessary, and then remove */ * the EXIT statement to allow the execution of the commands. */ *****************************************************************************************/

EXIT

DELDSD 'JEF2514.** ' DELUSER JEF2514

*****************************************************************************************/ * IRRRID00 has successfully completed */ *****************************************************************************************/

Observaciones:

De acuerdo a la información generada, el usuario JEF2514 figura como owner de 1 perfil y de la conexión de un usuario a un grupo. Por lo tanto, el IRRRID00 genera los correspondientes comandos de cambio de owner, debiéndose reemplazar ?JEF2514 por el nuevo owner elegido. Si se hubiese codificado en la SYSIN in “ID de reemplazo” para JEF2514, este ID aparecería en la salida en lugar de ?JEF2514.

128


Si el usuario figura en el campo NOTIFY de un perfil, como es el caso en nuestro ejemplo, el utilitario genera directamente el comando de eliminación. No se ofrece reemplazo en este caso, pues se trata de un campo opcional.

Los comandos que borran perfiles están agrupados al final del archivo de salida, a continuación de una sentencia EXIT que corta el procesamiento en caso de ejecutarse la Clist generada. Esto es intencional, ya que al tratarse de comandos más críticos, se evita de esta manera que la ejecución inmediata del archivo de salida los ejecute. Una vez revisado y editado adecuadamente el archivo de salida, basta con borrar la sentencia EXIT para que también sean ejecutados estos comandos.

Como uso marginal, puede ejecutarse el IRRRID00 solo con el objeto de hallar todas las referencias en la base de un determinado usuario/grupo, sin tener la intención de borrarlo. En este caso, el archivo de salida se usa únicamente como fuente de consulta, y no se ejecuta ninguno de los comandos generados. La información recabada es similar a la que brinda el IRRUT100. Tampoco se tiene, al igual que sucede con el IRRUT100, el nivel de autoridad del usuario/grupo sobre los perfiles en cuyas listas de acceso figura. Aunque esto es perfectamente entendible en el caso del IRRRID00, pues se trata de un uso del utilitario para el que no fue específicamente desarrollado. No perdamos de vista, sin embargo, que existe una diferencia importante: mientras que el IRRUT100 lee la base de RACF activa, el IRRRID00 extrae la información de una bajada plana (que puede estar desactualizada respecto de la base real). Ambos métodos presentan pues ventajas y desventajas, debiendo decidir el administrador cual es el más apropiado para cada situación.

Autoridad requerida

Para ejecutar el utilitario IRRRID00, basta con tener autoridad READ sobre el dataset especificado en INDD y UPDATE sobre el definido por OUTDD (o ALTER, si es alocado dinámicamente por el job). Naturalmente, para poder ejecutar los comandos generados se requiere la autoridad administrativa correspondiente. De todos modos, el IRRRID00 es básicamente una herramienta para los administradores de RACF, que deberían tener la autoridad suficiente para ejecutar exitosamente estos comandos.

9.7 - IRRMIN00

Este utilitario tiene los siguientes posibles usos:

� Inicializar un dataset en disco para ser usado como base de RACF

� Actualizar los templates de una base de RACF

� Reemplazar los templates residentes en memoria por los de la base

Toda base de RACF tiene grabado un cierto tipo de información -de uso interno por parte de RACF- denominada templates. Se trata, básicamente, de una descripción de los distintos campos de cada tipo de perfil. La información de los templates, indispensable para el funcionamiento de RACF, es cargada en memoria en tiempo de IPL. Por lo tanto, aún si se actualizan los templates de la base, 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, residente en SYS1.LINKLIB. Como una CSECT del programa figuran los templates. En consecuencia, si se actualizan los templates de una base usando –por ejemplo- el IRRMIN00 del z/OS 1.11, entonces se grabarán en la base los templates correspondientes a este release del sistema operativo.

A tiempo de IPL, cuando se cargan los templates en memoria, el sistema determina el nivel de los templates de la base primaria. Si se trata de templates anteriores a los propios del release del sistema operativo, entonces no se cargan en memoria los de la base sino los que efectivamente corresponden. En tal caso, en el SYSLOG se graba el mensaje ICH579E, informando que los templates de la base están

129


downlevel (desactualizados). No se trata de un error serio pues RACF va a funcionar sin problemas. Conviene, sin embargo, seguir la sugerencia dada en el mensaje y actualizar los templates de la base.

Si una base de RACF es compartida por varias LPAR con distintas versiones del z/OS, se le deben instalar los templates que correspondan a la versión más actualizada. Por ejemplo, si una base es compartida por 3 LPAR, 2 de las cuales tienen z/OS 1.9 y la restante z/OS 1.11, la base debe tener los templates del release 1.11 (las particiones que tienen 1.9 funcionarán sin problemas, ya que RACF mantiene compatibilidad hacia atrás).

Inicialización de una nueva base de RACF

Para poder utilizar un dataset como base de RACF, no solo es necesario alocarlo con las características apropiadas (detalladas en un capítulo anterior), sino que debe ser inicializado ejecutando el IRRMIN00 con PARM=NEW. Esto no solo debe hacerse para la base primaria, sino también para la base de backup. Más aún, si las bases estuvieran particionadas en más de un dataset, debe ejecutarse el utilitario para cada uno de ellos. Un dataset inicializado de este modo queda preparado para ser usado como base de RACF. Sin embargo, al estar esencialmente vacía, difícilmente pueda utilizarse directamente en forma satisfactoria. Lo usual es alocar una base con el IRRMIN00 y a continuación copiarle el contenido de otra existente, que ya tenga cierta información mínima que la torne efectivamente usable.

Debe tenerse sumo cuidado, ya que el IRRMIN00 con PARM=NEW efectivamente destruye toda la información existente en la base. Por lo tanto, no debe jamás ejecutarse el utilitario con PARM=NEW para actualizar los templates de una base, pues se perderá toda la información.

Ejemplo de IRRMIN00 para alocar e inicializar una nueva base de RACF:

//IRRMIN JOB cuenta,programmer,


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

//ALOCINI EXEC PGM=IRRMIN00,PARM=NEW


//SYSRACF DD DSN=SYS1.BASERACF.NUEVA,DISP=(NEW,CATLG),

SPACE=(CYL,(50),,CONTIG),DSORG=PSU,UNIT=SYSDA,VOL=SER=MVSRES

//

El programa invocado debe ser IRRMIN00, con PARM=NEW en este caso.

La DD SYSPRINT define 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.

La DD SYSRACF indica el dataset a inicializar como base de RACF. En nuestro caso, el archivo es alocado dinámicamente por el mismo job con el nombre SYS1.BASERACF.NUEVA, con las características adecuadas para una base de RACF. Observemos dos detalles de suma importancia: el espacio debe ser alocado contiguo y el archivo debe ser PSU (Physical Secuencial Unamovable). Las restantes características del dataset, como por ejemplo el tipo y longitud de registro, no es necesario especificarlas pues el mismo utilitario setea los valores correctos. Naturalmente, el nombre de la base, su tamaño y el disco dónde se aloca que hemos especificado son meros ejemplos, y deben ser determinados por la organización.

Actualización de los templates de una base existente

Cuando se migra el sistema operativo, por ejemplo de z/OS 1.9 a z/OS 1.11, como el nuevo release trae nuevos templates, es necesario actualizarlos. Para ello debe ejecutarse el IRRMIN00 con PARM=UPDATE (obviamente se pretende mantener intacta toda la información existente en la base). No solo deben actualizarse los templates de la base primaria sino también los de la base de backup. Más aún, si las bases estuvieran particionadas en más de un dataset, debe ejecutarse el utilitario para cada

130


uno de ellos. La base puede estar activa en el sistema cuando se usa PARM=UPDATE, en cuyo caso RACF obtiene una “reserva exclusiva” sobre ella durante el tiempo que insume la ejecución (mínimo).

Ejemplo de IRRMIN00 para actualizar los templates:



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

//TEMPUPD EXEC PGM=IRRMIN00,PARM=UPDATE



//

El significado de las DD es análogo al visto en el ejemplo anterior.

El IRRMIN00 con PARM=UPDATE solo actualiza los templates de la base especificada en SYSRACF, manteniendo intacta la información de los perfiles y de la SETROPTS.

Activación de los templates de la base

Ya comentamos que, si los templates de la base fueran de nivel inferior a los del release del sistema operativo, se cargan en memoria estos últimos. Ahora bien, existe la posibilidad de que la aplicación de mantenimiento del sistema (PTFs –Program Temporary Fix) eleve la versión de los templates. En tal caso, si la base de RACF ya tiene aplicados los nuevos templates, es posible cargarlos en memoria sin necesidad de recurrir a un IPL. Esto se logra ejecutando el IRRMIN00 con PARM=ACTIVATE, tal cual se muestra a continuación:

Ejemplo de IRRMIN00 para activar los templates de la base:



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

//TEMPACT EXEC PGM=IRRMIN00,PARM=ACTIVATE



//

El significado de las DD es análogo al visto en los ejemplos anteriores de IRRMIN00.

Si los templates en uso fueran de un nivel superior a los de la base especificada en SYSRACF, el job falla y la activación no se produce. Esto evita que accidentalmente se carguen en memoria templates inadecuados.

Autoridad requerida

Para ejecutar el utilitario IRRMIN00 se debe tener autoridad UPDATE sobre el dataset especificado en SYSRACF (o ALTER, si se lo está alocando dinámicamente, como en nuestro primer ejemplo). Si el programa IRRMIN00 se encontrara protegido en la clase PROGRAM, el usuario necesitaría asimismo estar autorizado para su ejecución.

9.8 - Otros Utilitarios

Describimos brevemente a continuación otros programas utilitarios que no vamos a exponer en detalle en esta guía, pero que resultan sin duda de interés para el administrador de RACF:

131


Nombre Función

BLKUPD Su nombre proviene de Block Update. Se trata de un comando que permite manipular directamente la base de RACF, con el objeto de resolver problemas internos. Sólo debe emplearse en situaciones dónde no sea posible reparar los errores mediante comandos de RACF. Antes de ejecutarlo, es necesario tener un acabado conocimiento de la estructura interna de la base, ya que un mal uso puede dañarla irreparablemente. En el libro “Security Server RACF Diagnosis Guide” se puede encontrar toda la información necesaria sobre el BLKUPD.

IRRADU00 Este utilitario formatea amigablemente los registros de SMF relevantes para la tarea de auditoría de RACF (tipos 30, 80, 81 y 83). Reemplaza al ya obsoleto, aunque aún soportado, RACFRW (RACF Report Writer). Técnicamente, este programa funciona como una exit del IFASMFDP, utilitario estándar de IBM para el resguardo de los registros de SMF. En el libro “Security Server RACF Auditor’s Guide” se puede encontrar información detallada sobre este utilitario.

DSMON Su nombre proviene de Data Security Monitor. Se trata de una herramienta sumamente útil, en particular para los auditores, ya que brinda gran cantidad de información relativa a la seguridad global del sistema. Por ejemplo:

� Exits de RACF activas � Usuarios con atributos SPECIAL, OPERATIONS o AUDITOR � Perfiles en la clase STARTED y entradas en la ICHRIN03 � Estado de las clases de RACF � Entradas en la Global Access Table � Bibliotecas APF autorizadas y en LINKLIST � Árbol de grupos.

En el libro “Security Server RACF Auditor’s Guide” se puede encontrar información detallada sobre este utilitario.

132


10 - COMANDO RVARY


El comando RVARY permite llevar a cabo las siguientes acciones, sin necesidad de un IPL:

� Listar la configuración actual de las bases de RACF vigentes en el sistema.

� Hacer un switch de las bases, operación que intercambia el uso de la base primaria y la de backup. Esto puede hacerse incluso a nivel de dataset, en el caso en que la base se encuentre distribuida en más de uno.

� Activar o inactivar una base de RACF, incluso a nivel de dataset, en el caso en que se encuentre distribuida en más de uno.

� Cambiar entre los modos data sharing y non data sharing, suponiendo que RACF esté habilitado para sysplex communication.

Los nombres de los datasets de las bases de RACF (primaria y backup) se definen en el módulo de nombre ICHRDSNT (Data Set Name Table). El orden en que están definidos determina su número de secuencia. Si las bases estuvieran divididas en varios datasets, será necesario indicar de qué manera se quiere distribuir la información entre los distintos archivos. Para ello es necesario configurar una tabla de rangos, que reside en el módulo de nombre ICHRRNG (Range Table). Ambas tablas deben compilarse y linkeditarse a partir de un módulo fuente en lenguaje assembler. No describiremos en esta guía su configuración. Solo destacamos que, al no tener instrucciones sino simplemente definiciones de constantes, no es necesario recompilarlos al migrar el sistema operativo. Son compatibles hacia arriba, y se pueden simplemente copiar. En cualquier caso, toda la información necesaria sobre ambas tablas está en el libro “Security Server RACF System Programmer’s Guide”.

Para simplificar, supondremos en este capítulo lo siguiente:

- La base de RACF no está compartida entre varios sistemas. No trataremos, en consecuencia, ningún aspecto relativo a sysplex communication o data sharing mode.

- El sistema tiene una base de backup activa y sincronizada con la primaria.

- El “subsistema RACF” se encuentra activo (lo cual es altamente recomendable, por cierto). Esto posibilita, entre otras cosas, ejecutar el comando RVARY desde una consola como comando de operador. No debe confundirse el “subsistema RACF” con el producto RACF propiamente dicho, que puede funcionar aún cuándo no se encontrara activo el subsistema. Toda la información necesaria sobre el “subsistema RACF”·se encuentra disponible en el libro “Security Server RACF

System Programmer’s Guide”.

No daremos la sintaxis completa del comando RVARY, sino que analizaremos por separado los comandos necesarios para cada una de las funciones que describiremos en esta guía. Estos pueden ejecutarse interactivamente desde una sesión de TSO, en forma batch, o bien por consola como comandos de operador.

Observación:

Aún cuando la organización haya definido passwords para ambas funciones del RVARY, el sistema seguirá aceptando la password por defecto YES para los operandos ACTIVE, SWITCH y DATASHARE|NODATASHARE, siempre y cuando se ejecute el comando desde una consola con autoridad MASTER (notemos que el operando INACTIVE está expresamente excluido de esta posibilidad). En tal caso, la respuesta YES puede ingresarse desde cualquier consola (lo fundamental es que tenga autoridad MASTER aquella dónde se ejecuta el comando RVARY). Esta flexibilización tiene por objeto permitir una recuperación de emergencia, aún si no se dispone de las passwords del RVARY.

133


De todos modos, un usuario con atributo SPECIAL tiene siempre la posibilidad de cambiar ambas passwords, aún sin conocer sus valores actuales.

Resulta por lo tanto de suma importancia controlar adecuadamente todas las consolas del sistema con autoridad MASTER, de modo que solo usuarios debidamente autorizados estén en condiciones de ejecutar comandos en ellas. Sobre este punto, conviene recalcar que los usuarios con acceso a TSO pueden habitualmente, desde el SDSF, acceder a una consola con autoridad MASTER a través del comando ULOG. Resulta pues fundamental limitar la posibilidad de ejecutar comandos de operador desde SDSF, controlando el uso de la “/” mediante un perfil apropiado en la clase SDSF (o GSDSF, su correspondiente clase agrupadora).

10.2 - Listado de la configuración de las bases

Sintaxis: RVARY LIST

Autoridad requerida: ninguna

Este comando es meramente informativo y no efectúa modificación alguna. 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 USE NUMBER VOLUME DATASET

YES PRIM 1 MVSRES SYS1.BASERACF.PRIM1 YES BACK 1 MVSPR1 SYS1.BASERACF.BACK1 YES PRIM 2 MVSRES SYS1.BASERACF.PRIM2 YES BACK 2 MVSPR1 SYS1.BASERACF.BACK2

ICH15020I RVARY COMMAND HAS FINISHED PROCESSING.

En este ejemplo, observamos que:

Ambas bases de RACF, primaria y backup, se encuentran distribuidas en 2 datasets. Los nombres de estos datasets, definidos en la ICHRDSNT, son de libre elección por parte de la organización, no teniendo necesidad alguna de tener a SYS1 como HLQ.

Los 4 datasets de encuentran activos.

La base primaria reside en un disco distinto que la de backup. Esto es altamente recomendable, pues evita que ambas queden inutilizables en caso de fallo de un único disco. Sin embargo, dada la tecnología actual de dispositivos de almacenamiento, es probable que distintos discos lógicos correspondan en realidad al mismo disco físico, con lo cual esta precaución puede no resultar del todo efectiva.

Es aconsejable que la base primaria resida en el “disco residente”.

10.3 - Switch de las bases

Sintaxis: RVARY SWITCH [DATASET(nombre…|*)]

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. En efecto, los datasets pertinentes de la base de backup pasan a tener uso primario, mientras que los originalmente primarios pasan a ser de uso backup, siendo también inactivados y desalocados.

Si se codifica DATASET(*), o se omite el operando DATASET, el switch actúa para todos los datasets que conforman la base primaria.

Observaciones:

Para poder switchear, el dataset de backup, que pasará a tener uso primario, debe necesariamente estar activo. En caso contrario, RACF ignora el comando y emite un mensaje de error.

Como la función de SWITCH intercambia y deja inactivo el nuevo backup, si se pretende volver a la configuración original mediante la ejecución de un nuevo SWITCH, es necesario previamente reactivar el backup.

El comando RVARY SWITCH actúa siempre sobre datasets de uso primario. Si se codifica en el operando DATASET un archivo cuyo uso es de backup, RACF ignora el comando y emite un mensaje de error.

Ejemplo:

Supongamos que, en el sistema con la configuración dada en el ejemplo anterior, el dataset de nombre SYS1.BASERACF.PRIM2 se encuentra dañado, por lo cual es necesario trasladar el procesamiento a su correspondiente dataset de backup. Para ello, debe ejecutarse el siguiente comando:

RVARY SWITCH DATASET(sys1.baseracf.prim2)

Completada la ejecución exitosa del comando, el listado de la nueva configuración arrojaría el siguiente resultado:

ICH15013I RACF DATABASE STATUS:

ACTIVE USE NUMBER VOLUME DATASET

YES PRIM 1 MVSRES SYS1.BASERACF.PRIM1 YES BACK 1 MVSPR1 SYS1.BASERACF.BACK1 NO BACK 2 *DEALLOC SYS1.BASERACF.PRIM2 YES PRIM 2 MVSPR1 SYS1.BASERACF.BACK2

ICH15020I RVARY COMMAND HAS FINISHED PROCESSING.

En esta situación, debería repararse lo antes posible el dataset dañado (al estar desalocado, es posible manipularlo), activarlo, switchear nuevamente y finalmente activar el backup para retornar a la configuración normal.

10.4 - 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, si se encontraran particionadas. En una situación normal, todos los datasets de las bases deben estar activos.

Si un dataset de la base primaria está inactivo, RACF no puede procesar requerimientos para los que precise información que reside en él (excepto que la tenga disponible en memoria). Por lo tanto, en esta

135


situación, es de esperar que se produzcan errores (abends). El correspondiente dataset de backup, aún cuando se encontrara activo, no reemplaza automáticamente al primario. Para ello, debe ejecutarse el comando de switch adecuado. 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.

Cuando todos los datasets de la base primaria se encuentran inactivos, se produce una situación, bastante molesta por cierto, conocida como failsoft processing. En estas condiciones, el sistema resulta prácticamente inoperable, ya que el operador debe aprobar por consola todo intento de acceso a datasets. Para otro tipo de recursos, el otorgamiento o el rechazo de un requerimiento de acceso queda en manos de la aplicación o subsistema que lo requiera. Son de esperar, de todos modos, innumerables inconvenientes. Si el sistema se encuentra en failsoft processing, situación por cierto de emergencia, debe disminuirse la actividad al mínimo indispensable y tomarse inmediatamente las acciones necesarias para volver a la normalidad.

Si un dataset de la base de backup está inactivo, RACF continúa procesando de manera normal, solo que eventualmente no podrá replicar en la base de backup las modificaciones que involucren al correspondiente dataset primario. Si bien esto no origina ninguna situación crítica, en tanto no impacta directamente en la seguridad del sistema, tener desactualizada la base de backup no es en absoluto aconsejable. Si fuera el caso, se debe proceder cuanto antes a resincronizarla con la base primaria, usando el IRRUT200.

El operando ACTIVE indica que se quiere reactivar los datasets especificados en DATASET. Si se codifica ACTIVE y se omite DATASET, RACF activará todos los datasets de la base primaria.

El operando INACTIVE indica que se quiere inactivar (y desalocar) los datasets especificados en DATASET. Si se codifica INACTIVE y se omite DATASET, RACF inactivará todos los datasets de la base primaria, provocando la entrada del sistema en failsoft processing.

La opción NOCLASSACT del operando INACTIVE permite establecer una lista de clases de la CDT (o todas, si se codifica *) para las cuales la protección de RACF no estará en efecto mientras se encuentre la base inactiva.

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.

En cualquier caso, la protección vuelve a tomar efecto inmediatamente al reactivar la base. 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.

10.5 - Procedimientos de recuperación de bases de RACF

Si bien es muy poco frecuente, es posible que algún dataset de las bases de RACF se dañe y sea necesario repararlo o reemplazarlo. Como paso previo a cualquier intento de manipulación, es necesario inactivarlo y desalocarlo, para lo cual debe ejecutarse el comando RVARY con el operando INACTIVE. Vamos a analizar 3 posibles escenarios de fallos, describiendo para cada uno un posible proceso de recuperación. Supondremos que la base no se encuentra particionada. En caso de estarlo, solo deberá aplicarse el procedimiento para los datasets que experimenten problemas.

La base primaria funciona correctamente pero falla la base de backup

1. Inactivar la base de backup ejecutando el comando: RVARY INACTIVE DATASET(nombre-base-backup)

2. Analizar qué tipo de problema presenta la base de backup. Si fuese necesario, deletearla, realocarla con el mismo nombre en un disco adecuado y copiarle la base primaria utilizando el utilitario IRRUT200 con PARM=ACTIVATE.

136


La base primaria falla y la base de backup funciona correctamente

1. Switchear las bases ejecutando el comando: RVARY SWITCH

2. Analizar qué tipo de problema presenta la base de backup actual (primaria original, que estaba fallando). Si fuese necesario, deletearla, realocarla con el mismo nombre en un disco adecuado y copiarle la base primaria actual (backup original) utilizando el utilitario IRRUT200 con PARM=ACTIVATE.

3. Switchear las bases nuevamente ejecutando el comando: RVARY SWITCH

4. Activar la base de backup actual (backup original) ejecutando el comando: RVARY ACTIVE DATASET(nombre-base-backup)

Ambas bases -primaria y backup- 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.

2. Analizar qué tipo de problema presenta la base de primaria. Si fuese necesario, deletearla, realocarla con el mismo nombre en un disco adecuado y copiarle un backup de la base de RACF lo más actualizado posible y que se encuentre en buenas condiciones. Si se dispone de uno en disco, utilizar el utilitario IRRUT200 (si el backup es de igual tamaño y reside en un disco de igual geometría) o el IRRUT400. Si el único backup utilizable está en cartucho, copiarlo usando el programa utilitario IEBGENER.

3. Activar la base primaria ejecutando el comando: RVARY ACTIVE DATASET(nombre-base-primaria) El sistema deja pues de estar en failsoft processing.

3. Inactivar la base de backup ejecutando el comando: RVARY INACTIVE DATASET(nombre-base-backup)

4. Copiar la base primaria sobre la de backup utilizando el utilitario IRRUT200 con PARM=ACTIVATE.

En este escenario, las modificaciones hechas en la base de RACF desde el momento en que se tomó el backup utilizado para la recuperación y el de la falla de ambas bases activas se habrán perdido. De todos modos, este período debería ser breve (si existe una correcta frecuencia de backups), y un análisis de los registros 80 del SMF correspondientes a este lapso permitiría reconstruir los cambios.

96050513 apuntes de racf

Documents