Seguridad en mainframe: Introducción al RACF

El artículo de hoy abordará a un nivel general el sistema de seguridad que todo mainframe con MVS posee: El Security Server o el tradicionalmente llamado RACF (Resource Access Control Facility).

Aunque pueda parecer que todos los sistemas de seguridad al final se basen en lo mismo, en el caso del mainframe es un caso aparte, ya que el sistema de seguridad de un mainframe se desarrolló junto con el desarrollo del sistema operativo y por tanto, es intrínseco y esta fuertemente acoplado al mismo.

En cambio, en otros sistemas tipo Unix y demás, la seguridad fue un desarrollo posterior y por tanto, sigue otras directrices. Pero vamos a lo que interesa.

RACF es un compendio de reglas de seguridad que se crean en base a unas clases. Una clase es un grupo de objetos los cuales queremos otorgarle un determinado acceso, por lo que todo objeto perteneciente a la misma clase tendrá el mismo nivel de seguridad. Por objeto se entiende desde un fichero, hasta un slot de proceso o abstracción funcional de software, por llamarlo de alguna manera.

Existen dos tipos de clases: Las denominadas "normales", es decir, clases de acceso, facilitys, logging y demás. Y luego existen las clases "especiales", que son dos: Las clases Usuario y las clases Dataset. Estas clases se denominan especiales porque pueden ser gobernadas por clases "normales" que les conferirán un cierto acceso, vamos, que estas clases pueden ser regidas por otras clases.

Evidentemente, la clase Usuario es muy importante porque se hace cargo de la seguridad referente al tipo de usuario, tipo de acceso a los elementos mainframe y que facilities tiene otorgado para realizar su trabajo.

Y la clase dataset es una clase especial que sirve para tener el control total sobre todo elemento susceptible de grabarse en disco o cinta.

Por tanto, se podría decir que RACF controla TODO el sistema internamente (procesos, subprocesos, schedulers, dispatchers, el núcleo, etcétera), controla los usuarios, el acceso de los usuarios a los datos, el acceso de los mecanismos de acceso a los datos, la interacción de los mecanismos de acceso con los procesos, vamos, es la leche.

Tanta complejidad tiene explicar los entresijos del RACF, que lo único que se me ocurre para explicar como funciona es poner ejemplos que me encuentro en instalaciones con problemas que surgen de autorizaciones y como solucionarlos para que vayáis haciéndoos una ligera idea de hasta donde llegan los tentáculos de este magnifico pero complejísimo sistema de seguridad.

Ejemplo de error de autorización

Por lo general, los errores de acceso suelen aparecer en el LOG del sistema y suelen tener la misma estructura. Únicamente cambian los tipos de campos en cada caso. Por tanto, debemos saber interpretarlos para saber que es lo que está sucediendo:

17.09.55 STC00098  ICH408I USER(START2  ) GROUP(SYS1    )
NAME(ÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑ)
SYS1.CPAC.HZSPDATA CL(DATASET ) VOL(OSWORK)
INSUFFICIENT ACCESS AUTHORITY
FROM SYS1.* (G)
ACCESS INTENT(UPDATE )  ACCESS ALLOWED(READ   )
17.09.55 STC00098  IEC150I 913-38,IFG0194E,HZSPROC,HZSSTEP,HZSPDATA,1014,OSWORK,SYS1.CPAC.HZSPDATA
17.09.55 STC00098 *HZS0015E PROBLEM WITH HZSPDATA DATA SET:
COULD NOT OPEN

Significa que el usuario START2 del Grupo SYS1 respecto a la clase DATASET pretende hacer un UPDATE cuando solo tiene permitido un READ al fichero SYS1.CPAC.HZSPDATA. Por tanto, se pueden hacer dos cosas: Si ese usuario no debe tener permiso, no se lo damos y que se joda, o debemos darle permisos para que pueda hacer lo que necesita. En nuestra instalación el usuario START2 es un usuario que se encarga principalmente de arrancar STARTED TASKS, ya que lo hemos configurado así en el RACF a menos que creemos un usuario específico para esa started task específica (que suele ser así en la mayoría de los casos, pero yo soy un dejado y un irresponsable y uso el mismo usuario para arrancar cualquier started-task, ¿pasa algo? xDDD).

Al tratarse de una clase DATASET, es una clase ESPECIAL que tiene su propio menú en el RACF. Por tanto, para dar el acceso es algo diferente. Los pasos a seguir son los siguientes:

1. Acceder al Interfaz de RACF y teclear la opción 1 DATA SET PROFILES. Esto nos llevará al submenú de seguridad a nivel de datasets, en la imagen la pantalla principal de RACF:
   

   

2. Lo primero que haremos será elegir la opción "S" o "9" de SEARCH, para comprobar si la clase dataset de la que se queja, existe (que debería existir). Esta clase es la SYS1.* (G). En la imagen se ve la parte de "Seguridad de DATASETS":
   

   
   

3. En la pantalla de la siguiente imagen no añadiremos ninguna máscara especial, simplemente daremos a Enter.
   

   
   

4. En la siguiente imagen (_Tipos de Datasets) escribiremos ALL en la opción TYPE para que nos liste todo lo que tiene controlado.
   

   
   

5. Al dar enter, nos saldrá una lista de todos los datasets que están controlados en la instalación. Y efectivamente, el dataset SYS1.* (G) existe.
   

   
   

6. Pulsaremos sobre PF3 y volveremos a la pantalla de la segunda imagen. En ella, elegiremos la opción 4 ACCESS, lo que nos llevará a la "configuración de acceso" (imagen siguiente).
   

   
   

7. En PROFILE NAME, escribiremos el dataset al que queremos tener más acceso. En nuestro caso, SYS1.* y pulsaremos sobre la tecla Enter.
   

8. Añadiremos un usuario para darle acceso, por lo que daremos a 1 ADD. En la imagen siguiente, la lista de accesos.
   

   
   

9. En la siguiente imagen, como no queremos copiar ningún perfil predefinido, vamos a poner SPECIFY como YES.
   

   
   

10. Y para cambiar el acceso que tenia de READ, pondremos AUTHORITY a UPDATE para decirle a que usuarios le daremos esa autoridad, en este caso a uno, START2.
    

    
    

11. Una vez dado a Enter, aparecerá un PROFILE CHANGED. Pero todavía falta hacer un último paso: "Refrescar el RACF". Para ello, daremos a PF3 tantas veces como sea necesario hasta llegar al menú principal del RACF. Para refrescar los datos, elegiremos la opción 5 SYSTEM OPTIONS y nos aparecerá un menú como el de la siguiente imagen, llamado "Menú de opciones de seguridad RACF" y las "Opciones de Refresh":
    

    
    

    
    

12. Marcaremos la opción 6 REFRESH y eso nos llevara a otra ventana con las opciones de refresh, de acuerdo a la imagen anterior. Lo mas sencillo es elegir la última opción, la de PROFILES FOR SPECIFIC CLASSES a YES y eso nos permitirá refrescar únicamente la clase a la que hemos cambiado las opciones, de acuerdo a la siguiente imagen.

13. En esa ventana escribiremos la clase específica (DATASET) y actualizaremos la zona GLOBAL a RACLIST, pero nos ha salido un error de RACF diciendo que esa clase no toca la RACLIST, así que hemos quitado el YES de esa columna y hemos vuelto a aplicar los cambios.

14. En este momento, si volvemos a lanzar el proceso que daba fallo, ya no debería darlo más.
    

    
    

Como habéis podido comprobar, es un sistema bastante completo y son muchos pasos los que hay que dar para simplemente asignar un permiso concreto a un usuario concreto a un grupo de ficheros concreto. Pero ahi radica el control del sistema, es decir, tener todo controlado y todo auditado por RACF.

Cualquier purista de Unix dirá que con hacer un simple chown y un chmod tienes solucionado el problema, pero no hay que olvidar que, a pesar de lo que pueda decir la gente, la seguridad de los sistemas Unix no deja de ser de juguete comparado con este sistema, de ahi su simplicidad, y en cambio la robustez de un mainframe esta marcada sobre todo por una seguridad eficiente, no en vano es una de las maquinas mas seguras del mundo.