7 Control de acceso

El control de acceso proporciona lo siguiente:

• El control de acceso de volúmenes permite asignar volúmenes a una aplicación de cliente. Se puede permitir el acceso de otros clientes a los volúmenes de ese cliente.

• El control de acceso de comandos permite a los administradores asignar comandos de ACSLS específicos a clientes específicos.

Tanto el control de acceso de volúmenes como el control de acceso de comandos son aplicables a los usuarios de las aplicaciones de cliente que envían solicitudes por medio de ACSAPI.

El control de acceso no restringe el acceso de los usuarios administrativos que envían las solicitudes de biblioteca mediante cmd_proc o la GUI de ACSLS.

Control de acceso de volúmenes

Cuando está activado, los volúmenes que pertenecen a un usuario específico son accesibles solo para ese usuario u otros usuarios de confianza.

Al configurar ACSLS por primera vez para el control de acceso de volúmenes, siga estos pasos:

1. Active el control de acceso de volúmenes en ACSLS.

2. Asocie una aplicación de cliente con un nombre de usuario.

3. Defina qué otros usuarios pueden tener acceso a los volúmenes de ese usuario.

4. Establezca el propietario de los volúmenes.

Activación del control de acceso de volúmenes

Para activar el control de acceso de volúmenes en ACSLS:

1. Ejecute la utilidad de configuración, acsss_config.

   Aparecerá el menú principal.

2. Seleccione la opción 4, "Set Access Control Variables" (Configurar variables de control de acceso).

   Las variables se muestran de a una por vez, junto con su configuración actual.

3. Haga clic en Enter (Intro) para aceptar el valor actual o por defecto.

4. Seleccione [TRUE] ([VERDADERO]) y haga clic en Enter (Intro) cuando la utilidad muestre el mensaje Access control is active for volumes (El control de acceso está activo para los volúmenes).

5. Seleccione una de las siguientes opciones cuando la utilidad muestre el mensaje Default access for volumes [ACCESS/NOACCESS] (Acceso por defecto para volúmenes [ACCESO/SIN ACCESO]):

   • Seleccione [ACCESS] ([ACCESO]) si desea no permitir el acceso a usuarios específicos y permitir el acceso a todos los demás.

     Para ello, se deben incluir los usuarios específicos en una lista, en el archivo users.ALL.disallow o un archivo users.COMMAND.disallow específico. Consulte Definición de otros usuarios a los que se permite el acceso a los volúmenes del usuario.

   • Seleccione [NOACCESS] ([SIN ACCESO]) si desea permitir el acceso a usuarios específicos y no permitir el acceso a todos los demás.

     Para ello, se deben incluir los usuarios específicos en una lista en el archivo users.ALL.allow o un archivo users.COMMAND.allow específico. Consulte Definición de otros usuarios a los que se permite el acceso a los volúmenes del usuario.

     Si desea registrar las instancias en las que se deniega el acceso a volúmenes, seleccione [TRUE] ([VERDADERO]) en respuesta a esa petición de datos.

     Cuando activa o desactiva el acceso de volúmenes, debe reiniciar ACSLS para que los cambios se apliquen.

     
     Associating a client identity with a user name 
     

No todas las aplicaciones de cliente pasan un ID de usuario único con los paquetes de solicitudes de ACSLS. En los casos en los que el cliente no se identifica mediante un nombre de usuario, puede asignar un ID de usuario.

1. Vaya al directorio de configuración access_control:

   $ACS_HOME/data/external/access_control.  
   

2. Cree un archivo llamado internet.addresses o copie el archivo internet.addresses.SAMPLE.

3. En este archivo, cree un registro para cada cliente. Cada registro tiene por lo menos dos campos: la dirección IP del cliente seguida por un nombre de usuario correspondiente. Puede incluir campos adicionales para comentarios.

   Separe los campos con espacios o tabulaciones, como se muestra en el siguiente ejemplo:

   192.0.2.1  ulyssis   payroll department 
   

   Puede crear tantas asociaciones cliente-usuario como las aplicaciones de cliente que tenga.

   • En los casos en los que las aplicaciones de cliente incluyen el nombre de usuario con la solicitud de ACSLS, el archivo internet.addresses autentica el nombre de usuario con la dirección IP designada y deniega el acceso si ambos campos no coinciden con los valores incluidos en el paquete de la solicitud. Cuando una plataforma común aloja varios clientes, la misma dirección IP puede estar incluida varias veces en este archivo, y esa dirección puede estar asociada con tantos nombres de usuario como correspondan a esa dirección IP.

   • En los casos en los que las aplicaciones de cliente no incluyan el nombre de usuario con la solicitud, el archivo internet.addresses establece un nombre de usuario para ese cliente. En este caso, puede haber solo un nombre de usuario asociado con la dirección IP del cliente.

4. Guarde las actualizaciones realizadas en el archivo internet.addresses:

   • Ejecute acsss_config.

   • Seleccione la opción 6, "Rebuild Access Control Information" (Recompilar información de control de acceso).

   ACSLS reconoce dinámicamente el cambio.

   En el caso de clientes SNA y OSLAN que no usen TCP/IP, consulte el archivo lu62.names o el archivo adi.names en el directorio access_control.

Definición de otros usuarios a los que se permite el acceso a los volúmenes del usuario

Para otorgar acceso a otros usuarios a los volúmenes que pertenecen a un usuario:

1. Cree un archivo users.ALL.allow o users.ALL.disallow en el directorio access_control.

   Puede copiar las plantillas users.SAMPLE.allow o users.SAMPLE.disallow.

2. En el archivo, agregue un registro por cada propietario, colocando el ID de usuario del propietario en el margen izquierdo.

3. Especifique los usuarios afectados en la misma línea con cada propietario.

4. Separe los nombres de usuario con espacios o tabulaciones, como se muestra en el siguiente ejemplo:

   owner_john   user-Allie   user-andre  
   

   Los nombres de usuario que se incluyen en los archivos users.allow y users.disallow deben ser únicos, sin distinción entre mayúsculas y minúsculas. El uso de mayúsculas y minúsculas en el nombre de usuario se omite.

   A los usuarios que no están incluidos en la misma línea con el propietario se les asigna la relación por defecto (ACCESS [ACCESO] o NOACCESS [SIN ACCESO]) para los volúmenes del propietario.

   Nota:

   No puede tener el mismo par de owner_ID y user_ID en los archivos users.COMMAND.allow y users.COMMAND.disallow para el mismo comando o la opción ALL. Tampoco puede tener el par owner_ID y user_ID duplicado en los mismos archivos users.COMMAND.allow y users.COMMAND.disallow. Esto incluye repetir el mismo user_ID en una línea.

   Si hay más usuarios autorizados para un propietario que los que entran en una línea, la lista de usuarios autorizados puede continuar en líneas subsiguientes. Cada línea debe comenzar con el ID del propietario.

5. De manera opcional, puede establecer excepciones para la política de acceso de volúmenes que haya definido.

   Por lo general, los usuarios tienen permitido el acceso total o no se les permite el acceso a los volúmenes que tienen control de acceso. Sin embargo, es posible permitir a los usuarios un acceso restringido a los volúmenes de otros usuarios.

   Por ejemplo, se puede definir una política que permita a cualquier usuario hacer consultas en los volúmenes que pertenecen a un usuario específico, aunque no tengan permitido montar ni desmontar esos volúmenes. Se pueden aplicar excepciones a cualquiera de los comandos que se ven afectados por el control de acceso:

   Para configurar excepciones de políticas de acceso de volúmenes para ciertos comandos:

   • Debe crear un archivo users.COMMAND.allow o un archivo users.COMMAND.disallow (donde COMMAND se reemplaza por el comando específico que desea otorgar o restringir).

     Los archivos users.COMMAND.allow y users.COMMAND.disallow deben tener un componente de comando en el que se especifique el nombre exactamente como se muestra a continuación, con el nombre del comando en mayúsculas. No se admite el control del acceso a otras variantes de comandos (como QUERY_VOLUME).

     DISMOUNT 
     EJECT 
     LOCK 
     MOUNT (1) 
     MOUNT_READONLY (2) 
     QUERY 
     REGISTER 
     SET_CLEAN 
     SET_SCRATCH 
     UNLOCK 
     

     Notas:

     • MOUNT (1): las políticas de MOUNT son aplicables también al montaje de volúmenes reutilizables. Las políticas no son aplicables a montajes de solo lectura.

     • MOUNT_READOLNY (2): las políticas para montajes de solo lectura se definen independientemente de las de montaje.

     • Las consideraciones anteriores acerca de no usar pares duplicados de ID de propietario e ID de usuario autorizado y acerca de la continuación de listas de usuarios autorizados en líneas subsiguientes se aplican también a las listas de usuarios no autorizados.

   • Para cada propietario, coloque el nombre del propietario en el margen izquierdo, seguido por los usuarios a los que se aplica la política.

6. Guarde las actualizaciones de las políticas que defina:

   • Ejecute acsss_config

   • Seleccione la opción 6, "Rebuild Access Control Information" (Recompilar información de control de acceso).

   ACSLS reconoce dinámicamente el cambio.

Establecimiento del propietario de los volúmenes

El control de acceso de volúmenes es aplicable solo a los volúmenes que tienen un propietario explícito. Los volúmenes de la biblioteca que no tienen un propietario son accesibles para todos los usuarios. Para definir explícitamente el propietario de un volumen, use la interfaz cmd_proc:

ACSSA>set owner "daffy" volume V00100-V00199 
Set: owner set for volumes V00100-V00199 
Set: Set completed, Success. 

Puede eliminar propietarios de manera similar mediante una cadena vacía:

ACSSA> set owner "" volume V00100-V00199 
Set: owner set for volumes V00100-V00199 

Esta operación borra el propietario de todos los volúmenes del rango. Para obtener más información, consulte set owner.

Se puede usar la utilidad watch_vols para configurar automáticamente los propietarios de volúmenes. Para obtener más información, consultewatch_vols .

Políticas de propiedad

En ACSLS también se puede definir una política para establecer y eliminar propietarios automáticamente. Por ejemplo, puede establecer una política en la que todos los volúmenes reutilizables que se monten pasen a ser propiedad del usuario que los montó. De allí en adelante, ese usuario será el propietario del volumen. La misma política se puede ampliar para eliminar la propiedad cuando se asigne el estado de reutilizable al volumen. Se puede escribir una política que indique que todos los volúmenes introducidos se asignen a un usuario por defecto, al usuario que solicitó la introducción o, si el volumen ya tuvo un propietario, al propietario anterior. Esta función ofrece una flexibilidad considerable.

Las políticas de propiedad se definen en el archivo ownership.assignments, que reside en el directorio access_control. Puede establecer una política en este archivo para asignar propietarios, o anular su asignación, automáticamente con cada operación enter, automatic enter, set scratch o mount scratch. El archivo ownership.assignments le permite definir un propietario por defecto. Cuando se ejecute alguna de estas operaciones para un volumen, la propiedad se puede asignar a:

• Owner_default (el propietario por defecto)

• Same (el propietario anterior)

• Requestor (el usuario que envía la solicitud actual)

• Unowned (se elimina la propiedad del volumen)

  Nota:

  Las instrucciones para definir las políticas de propiedad se describen en detalle en el archivo ownership.assignments. Este archivo incluye una lista completa de los comandos que se pueden usar para establecer la propiedad de los volúmenes.

• Guarde las actualizaciones de las políticas que defina:

  • Ejecute acsss_config

  • Seleccione la opción 6, Rebuild Access Control Information (Recompilar información de control de acceso).

  ACSLS reconoce dinámicamente el cambio.

Verificación de la propiedad

Para verificar la propiedad, puede ejecutar volrpt con la plantilla owner_id.volrpt.

cd ~acsss/data/external/volrpt 
volrpt -f owner_id.volrpt 

Esto genera una lista de todos los volúmenes de la biblioteca con el propietario asociado a cada uno.

Resumen del acceso de volúmenes

El control de acceso de volúmenes admite los siguientes comandos:

dismount* 
display 
eject 
enter 
lock 
set_clean 
set_scratch 
mount 
query_mount 
query_scratch 
query_volume 
unlock 

El control de acceso no se aplica a dismount force, ya que la opción force indica a StorageTek ACSLS que omita el ID del volumen y lo desmonte incondicionalmente.

En la siguiente tabla, se resumen los contextos aplicables cuando se activa volume access control.

Tabla 7-1 Acceso de volúmenes activado

El acceso por defecto para los volúmenes es ACCESS (ACCESO)	Acceso permitido	Acceso denegado
Acceso mediante cmd_proc	X
El volumen especificado no tiene propietario	X
El usuario es el propietario del volumen	X
El usuario está asociado con el propietario en users.ALL.disallow		X
Si el usuario no está asociado con el propietario en users.ALL.disallow	X

Tabla 7-2 Acceso de volúmenes activado

El acceso por defecto para los volúmenes es NOACCESS (SIN ACCESO)	Acceso permitido	Acceso denegado
Acceso mediante cmd_proc	X
El volumen especificado no tiene propietario	X
El usuario es el propietario del volumen	X
El usuario está asociado con el propietario en users.ALL.allow	X
Si el usuario no está asociado con el propietario en users.ALL.allow		X

Control de acceso de comandos

El control de acceso de comandos permite a un administrador de ACSLS restringir ciertas clases de comandos a aplicaciones de cliente específicas o a usuarios específicos en toda la red. El acceso controlado es aplicable solo a los comandos de usuario que se ejecutan por medio de ACSAPI y no es aplicable a los usuarios locales que ejecutan comandos con cmd_proc.

El proceso para configurar ACSLS para el control de acceso de comandos tiene tres pasos.

Al configurar ACSLS por primera vez para el control de acceso de comandos, siga estos pasos:

1. Active el control de acceso de comandos en ACSLS.

2. Asocie una identidad de cliente con un nombre de usuario.

3. Defina qué comandos están disponibles para qué usuarios.

Activación del control de acceso de comandos

Para activar el control de acceso de comandos en ACSLS:

1. Ejecute la utilidad de configuración, acsss_config.

   Aparecerá el menú principal.

2. Seleccione la opción 4, "Set Access Control Variables" (Configurar variables de control de acceso).

   Las variables se muestran de a una por vez, junto con su configuración actual.

3. Haga clic en Enter (Intro) para aceptar el valor actual o por defecto.

4. Seleccione TRUE (VERDADERO) y haga clic en Enter (Intro) cuando la utilidad muestre el mensaje Access control is active for commands (El control de acceso está activo para los comandos).

5. Cuando aparezca el mensaje "Default access for commands" (Acceso por defecto para comandos):

   • Seleccione ACCESS (ACCESO) si desea permitir el acceso a todos los comandos para todos los usuarios.

     Para bloquear usuarios específicos a fin de que no puedan ejecutar comandos, se los debe incluir en un archivo command.ALL.disallow o un archivo command.XXX.disallow específico, donde:

     XXX es el comando para el que se desea establecer el control de acceso.

   • Seleccione [NOACCESS] ([SIN ACCESO]) si desea denegar el acceso a los comandos para los usuarios.

     Para autorizar la ejecución de comandos a usuarios específicos, estos se deben incluir en un archivo command.ALL.allow o un archivo command.XXX.allow específico.

     Nota:

     Si desea registrar las instancias en las que se deniega el acceso a comandos, introduzca "TRUE" (VERDADERO) en respuesta a esa petición de datos.

     Nota:

     Cuando activa o desactiva el acceso de comandos, debe reiniciar ACSLS para que los cambios se apliquen.

Asociación de una identidad de cliente con un nombre de usuario

Consulte los procedimientos que se describen en Associating a client identity with a user name.

Definición de qué comandos están disponibles para qué usuarios

Este proceso depende del comportamiento por defecto que haya seleccionado al activar el control de acceso de comandos. Debe crear un archivo de política en el directorio $ACS_HOME/data/external/access_control.

• Si el comportamiento por defecto que definió anteriormente es [NOACCESS] ([SIN ACCESO]), debe crear un archivo command.ALL.allow que incluya el ID de usuario de cada cliente al que se desea permitir el acceso a todos los comandos de ACSLS. Cada ID de usuario se debe incluir en una línea diferente del archivo.

  Si desea otorgar acceso solo a comandos específicos para usuarios específicos, debe crear un archivo command.XXX.allow para cada comando que los usuarios tienen permitido ejecutar. Por ejemplo, para otorgar permiso a usuarios específicos para que introduzcan volúmenes en la biblioteca, debe crear un archivo con el nombre command.ENTER.allow e incluir allí el ID de cada uno de los usuarios que están autorizados a ejecutar el comando 'enter', con un ID por línea.

• Si el comportamiento por defecto que definió es [ACCESS] ([ACCESO]), debe crear un archivo command.ALL.disallow que incluya el ID de usuario de cada cliente al que no se desea permitir el acceso a todos los comandos de ACSLS. Cada ID de usuario se debe incluir en una línea diferente del archivo.

  Nota:

  No puede tener el mismo user_ID en los archivos command.XXX.allow y command.XXX.disallow command.XXX para el mismo comando o para la opción ALL.

Nombres de comando para los archivos de autorización y bloqueo del control de acceso de comandos

Los archivos command.XXX.allow y command.XXX.disallow deben tener un componente de comando en el que se especifique el nombre exactamente como se muestra a continuación, con el nombre del comando en mayúsculas. No se admite el control del acceso a otras variantes de comandos (como QUERY_VOLUME).

AUDIT 
CANCEL 
CHECK_REGISTRATION 
CLEAR_LOCK 
DEFINE_POOL 
DELETE_POOL 
DISMOUNTDISMOUNT_FORCE 
DISPLAY 
EJECT 
ENTER      (1) 
IDLE 
LOCK 
MOUNT      (2) 
QUERY 
QUERY_LOCK 
REGISTER 
SET_CAP 
SET_CLEAN 
SET_OWNER 
SET_SCRATCH 
START 
UNLOCK 
UNREGISTER 
VARY  

Nota:

ENTER (1): las políticas se aplican a las operaciones de introducción virtual e introducción manual, pero no a las de introducción automática. MOUNT (2): las políticas también se aplican a mount scratch y mount readonly.

Use la siguiente tabla como referencia rápida para determinar cuándo está permitido el acceso de comandos.

Tabla 7-3 Acceso de comandos activado

El acceso de comandos por defecto es NOACCESS (SIN ACCESO)	Acceso permitido	Acceso denegado
La solicitud se introduce desde cmd_proc	X
El user_ID está incluido en command.COMMAND.allow	X
El user_ID está incluido en command.ALL.allow	X
- - Todas las demás condiciones - -		X

Tabla 7-4 Acceso de comandos activado

El acceso de comandos por defecto es ACCESS (ACCESO)	Acceso permitido	Acceso denegado
La solicitud se introduce desde cmd_proc	X
El user_ID está incluido en command.COMMAND.disallow		X
El user_ID está incluido en command.ALL.disallow		X
- - Todas las demás condiciones - -	X

• Guarde las actualizaciones de las políticas que defina:

  • Ejecute acsss_config

  • Seleccione la opción 6, "Rebuild Access Control Information" (Recompilar información de control de acceso).

  ACSLS reconoce dinámicamente el cambio.

Registro de mensajes de control de acceso

Puede establecer una política para registrar todas las transacciones que hayan generado errores porque se denegó el acceso al usuario. El mensaje muestra el nombre de usuario y el comando que se intentó ejecutar.

Para activar el registro de control de acceso:

1. Ejecute acsss_config y seleccione la opción 4, "Set Access Control Variables" (Configurar variables de control de acceso).

2. Cambie [FALSE] ([FALSO]) por [TRUE] ([VERDADERO]) cuando se muestre la siguiente petición de datos: "Messages will be logged when access to commands or volumes is denied" (Se registran mensajes cuando se deniega el acceso a comandos o volúmenes).

3. Seleccione la opción 6, "Rebuild access control information" (Recompilar información de control de acceso).

ACSLS reconoce el cambio y comienza a registrar cada caso en que se deniega una solicitud de comando.