Control de Acceso sobre Archivos de Spool
Conozca en detalle los pasos a seguir para proteger la información confidencial de los archivos en spool en AS400
Toda la información que se deposita en forma de archivos de spool también necesita estar protegida de los accesos no debidos por parte de usuarios no autorizados. A pesar de utilizar comúnmente la denominación “archivos de spool”, es importante aclarar que los mismos no son objetos de tipo *FILE, sino items o elementos que se encuentran almacenados en objetos de tipo *OUTQ o colas de salida. Cada vez que desde un job se genera una salida impresa, ésta se almacena dentro de una cola de salida.
A las colas de salida (objetos tipo *OUTQ) como a cualquier otro objeto del sistema, se les aplican las autorizaciones específicas ya conocidas como *ALL, *CHANGE, *USE, *EXCLUDE y User Defined. Sin embargo, debido a la complejidad estructural de este tipo de objeto y a la exposición que recibe en su manipuleo, existen parámetros de seguridad adicionales que deben considerarse.
Asimismo, hay que tener en cuenta que el acceso al spool está MUY relacionado con la concesión de autorizaciones especiales, esto es, las colas de salida suelen estar muy expuestas ante los usuarios operadores, administradores, etc.
El presente tip, permitirá conocer qué relación existe entre las autorizaciones específicas, los parámetros de seguridad de las colas de salida y las autorizaciones especiales que los usuarios poseen.
Estructura básica de la seguridad de spool
Contrariamente a lo que muchos suponen, no es necesario poseer autorizaciones especiales de operador (*JOBCTL) para poder manipular spool. Cualquier usuario “raso”, en caso de tener acceso a las funciones/comandos de manejo de colas de salida puede gestionarlas dentro de las limitaciones que le impone la seguridad de las colas de salida.
De acuerdo a los valores por defecto del sistema, un usuario sin autorizaciones especiales (*USER y *PGMR) puede visualizar, imprimir, cambiar o eliminar un listado mientras éste le pertenezca, es decir, si el listado fue generado por un job bajo su propio perfil. Si hubiera otros listados en la misma cola de salida, este usuario podrá detectar que existen, pero sin posibilidad de operar con ellos. En otras palabras, cualquier usuario puede ser “operador” de sus propios listados.
Si además este usuario es propietario del objeto cola de salida, puede también dentro de los parámetros de seguridad establecidos por default, operar sobre todos los listados de la cola.
En la mayoría de los casos, no es necesario hacer una administración especial de la seguridad de spool para este tipo de usuarios “rasos”. Puede requerirse alguna acción en el caso de que se quiera darle acceso a los listados de otros, por ejemplo, o vedarle la visualización de sus propios listados. Desde ya, las restricciones más fuertes (*EXCLUDE) que se apliquen sobre cualquier cola de salida afectan a esta categoría de usuario, que no tiene atribuciones especiales que le permitan sortear la limitación.
Para conocer con más detalle el comportamiento del sistema hacia estos usuarios y cómo modificarlo, es necesario analizar (además de la seguridad del objeto *OUTQ) los parámetros Autorización a comprobar (palabra clave AUTCHK) y Visualizar cualquier archivo (palabra clave DSPDTA). Estos forman parte de los atributos de la cola de salida, y se visualizan al crearla o modificarla (ver pantalla).:
Cuando el valor AUTCHK está en *OWNER (default), OS/400 chequea si el usuario que accede a la cola de salida es el propietario de la misma. Si es así, cualquier operación está permitida si los valores para el parámetro DSPDTA son *YES o *NO. En cambio, si el valor de DSPDTA es *OWNER, el propietario de la cola de salida sólo podrá realizar la gestión operativa aunque sea el dueño de la OUTQ. Si el usuario que quiere trabajar con los archivos de spool no es el propietario de la cola de salida, sólo se podrá visualizar el contenido cuando DSPDTA valga *YES. En los demás valores de este parámetro, ninguna operación estará permitida.
Si el valor de AUTCHK es *DTAAUT, se considerarán exclusivamente los permisos del usuario sobre el objeto cola de salida. Para tener permiso a la mayor parte de las operaciones sobre la misma, se necesitará autorización específica *CHANGE. Es importante observar que la autorización pública por default que posee una cola de salida es *USE y no *CHANGE como ocurre para la mayor parte de los objetos (si fuera *CHANGE, los permisos a cualquier usuario serían excesivos para este tipo de objeto).
Ejemplo:
Utilizando los parámetros anteriormente explicados, es posible plantear combinaciones muy interesantes que nos permiten generar colas de salida sobre las cuales los usuarios posean diferentes tipos de accesos. Por ejemplo, se necesita una cola de salida para un grupo de programadores. Cualquiera de los archivos de spool deberá ser accedido por los diferentes integrantes del grupo, independientemente quién fue el que lo generó. Para cumplir con este requerimiento, la cola de salida debe tener como propietario a un usuario externo al grupo, y los parámetros de seguridad, a saber, AUTCHK y DSPDTA deberán valer *OWNER y *YES respectivamente. Al grupo en cuestión se le otorgará la autorización *CHANGE sobre la cola de salida. De esta manera, todos podrán visualizar el contenido de los archivos de spool de los demás.
Acceso con autorización especial *JOBCTL: La zona peligrosa
Los operadores y muchas veces también los programadores son usuarios que gozan de la autorización especial *JOBCTL. Esta autorización le permite al que la posee, entre otras cosas, gestionar listados propios y ajenos de cualquier cola de salida del sistema, siempre y cuando sus parámetros de seguridad estén en sus valores por defecto, independientemente de las autorizaciones específicas del objeto (observar el recorrido en rojo en la Figura 1).
Un usuario *JOBCTL, cuando accede al spool, está en situación de efectuar “casi” cualquier operación sobre los archivos, aunque se hubiera especificado *EXCLUDE para la cola de salida en forma pública o privada. El tipo de gestión que se puede llevar a cabo sobre el spool es dependiente del parámetro Visualizar cualquier archivo (palabra clave DSPDTA). Si este último está en *YES o *NO (observar que *NO es el default) entonces cualquier operación puede efectuarse. De aquí se deduce que si un usuario es *JOBCTL y los parámetros de seguridad de la *OUTQ están en sus defaults, el acceso es total. En caso contrario, si el valor es *OWNER, las operaciones permitidas son aquellas relacionadas con operación (retener, liberar, cambiar atributos y suprimir). La combinación de los parámetros OPRCTL = *YES y DSPDTA = *OWNER está orientada a permitir a los operadores la gestión de las entradas sin que tengan permiso a visualizar su contenido.
En caso de querer modificar este default, existe la posibilidad de alterar el parámetro OPRCTL (Controlable por operador) de la cola que se desea proteger, colocándolo en *NO en lugar del valor por defecto, *YES. Cualquier usuario con autoridad *JOBCTL que acceda a la misma, lo hará en las condiciones de cualquier otro usuario que no posea autorizaciones especiales, es decir se inhibirá el valor *JOBCTL para esa cola en particular y el sistema efectuará los chequeos de seguridad que se aplican a un usuario sin autorizaciones especiales.
Por todo lo hasta aquí expuesto, poseer la autoridad *JOBCTL proporciona accesos respecto al spool que pueden llegar a ser más amplios de lo necesario. Por lo tanto el otorgamiento de *JOBCTL debería estar estrictamente controlado. Antes de la V3R7 del OS/400, cada vez que se creaba un perfil de usuario de clase *SECADM, *SYSOPR o *PGMR se otorgaban las autorizaciones especiales *JOBCTL y *SAVSYS (el administrador además gozaba de la autorización *SECADM). Desde la V3R7 en adelante, OS/400 comenzó a restringir la asignación automática de autorizaciones especiales. El administrador de seguridad conserva solamente la autorización *SECADM, el operador del sistema posee las mismas y el programador directamente no posee autorizaciones especiales. Para efectuar tareas netamente de programación, un perfil de usuario no necesita autorizaciones especiales.
Ejemplos:
- El oficial de seguridad necesita una cola de salida donde volcar los archivos de spool que se generan con información confidencial de seguridad. Para cumplir con este objetivo, crear el objeto *OUTQ con el oficial de seguridad como propietario. Los parámetros de seguridad deberían establecerse en los siguientes valores: OPRCTL en *NO (acceso no permitido a los usuarios con *JOBCTL), AUTCHK en *DTAAUT (se necesita autorización específica sobre el objeto *OUTQ) y DSPDTA en *OWNER (ninguna operación permitida). La autorización pública del objeto en *EXCLUDE cierra el acceso a cualquier otro usuario.
- Para la impresión de archivos confidenciales se necesita una cola de salida donde los usuarios puedan volcar esa información y los operadores puedan realizar la gestión operativa de los mismos sin visualizar su contenido. Los parámetros de seguridad deben establecerse de la siguiente forma: OPRCTL en *YES (habilita a los usuarios con *JOBCTL), AUTCHK en *OWNER (chequea si el que accede es el propietario de la *OUTQ) y DSPDTA en *OWNER ( los usuarios sólo pueden trabajar con su propio spool y el operador podrá retener, liberar, cambiar y eliminar). La autorización pública debería valer *USE.
Acceso con autorización especial *SPLTCL: Acceso absoluto
Los perfiles poseedores de este permiso, tienen acceso completo a los archivos de spool de cualquier cola de salida para efectuar todo tipo de operación. Si un perfil goza de esta autorización, es imposible evitar su acceso a una determinada cola de salida. La autorización especial *SPLCTL sólo es concedida por OS/400 a los usuarios de clase oficial de seguridad (*SECOFR), aunque también puede otorgarse individualmente.
Resumen de parámetros de seguridad de las colas de salida
El siguiente esquema en la Figura 1 representa el chequeo de autorizaciones que efectúa el sistema para acceder a archivos de spool considerando las autorizaciones especiales del usuario, los parámetros anteriormente mencionados de las colas de salida y las autorizaciones específicas sobre el objeto:
Para tener en cuenta...
- Recuerde que cuando un usuario genera un archivo de spool, es el propietario del listado. Por lo tanto, siempre podrá verlos y manipularlos sin tener en cuenta como se definió la seguridad para la cola de salida que utilice.
- El texto “Controlable por operador” del parámetro de palabra clave OPRCTL puede conducir a confusiones. Recordar que no se refiere a la clase de usuario, sino al hecho de poseer la autorizaciónespecial *JOBCTL. La acción de este parámetro involucraría también a un usuario de clase *PGMR, si él también posee dicho permiso especial.
- Los parámetros de las colas de salida pueden indicarse tanto en el momento de su creación (comando CRTOUTQ), o con un cambio posterior (comando CHGOUTQ). Para visualizar los valores en uso se utiliza el mandato WRKOUTQD.
- La autorización especial *ALLOBJ sobre colas de salida no se comporta de la misma manera que sobre otros tipos de objetos.
- La autorización especial *SPLCTL puede interpretarse como el *ALLOBJ de las colas de salida.
- Para determinar donde se almacena un archivo de spool generado por un job, se efectúan una serie de consultas en la siguiente secuencia: “printer file”, atributos del trabajo, perfil de usuario, descripción de dispositivo de pantalla y por último el valor de sistema QPRTDEV.
Copyright - Teknoda S.A. -
IMPORTANTE:
“Notas técnicas de AS/400 - IBM i" se envía con frecuencia variable y sin cargo como servicio a nuestros clientes IBM i - AS/400. Contiene notas/tutoriales/artículos técnicos desarrollados en forma totalmente objetiva e independiente. NS iTech - Teknoda es una organización de servicios de tecnología informática y NO comercializa hardware, software ni otros productos.
Si desea suscribir otra dirección de e-mail para que comience a recibir las Notas Técnicas AS400 - IBM i, envíe un mensaje desde esa dirección a info@nsitech.com.ar o a letter400@nsitech.com.ar, aclarando nombre, empresa, cargo y país del suscriptor.
AS400 , iSeries, System i, IBM Power Systems, IBM i son marcas registradas de IBM. IBM no es el editor de esta publicación y no es responsable de la misma en ningún aspecto. La información contenida en esta publicación ha sido generada por nuestros especialistas a partir de fuentes consideradas confiables y del ejercicio profesional cotidiano. No obstante, por la posibilidad de error humano, mecánico, cambio de versión u otro, NS iTech - Teknoda no garantiza la exactitud o completud de la misma.
COPYRIGHT NS iTech - TEKNODA S.A. PROHIBIDA SU REPRODUCCION TOTAL O PARCIAL SIN CONSENTIMIENTO DE NS iTech - TEKNODA
