7 Contrôle d'accès

Le contrôle d'accès fournit les éléments suivants :

  • Le contrôle de l'accès aux volumes permet d'attribuer des volumes à une application client. D'autres clients peuvent être autorisés à accéder aux volumes du client.

  • Le contrôle de l'accès aux commandes permet aux administrateurs d'attribuer des commandes ACSLS spécifiques à certains clients.

Le contrôle de l'accès aux volumes et le contrôle de l'accès aux commandes s'appliquent aux utilisateurs des applications client qui envoient des demandes par le biais de l'ACSAPI.

Le contrôle d'accès ne restreint pas l'accès des utilisateurs administratifs qui soumettent des demandes à la bibliothèque à l'aide de cmd_proc ou de la GUI ACSLS.

Contrôle de l'accès aux volumes

Lorsqu'ils sont activés, les volumes qui appartiennent à un utilisateur spécifique sont accessibles uniquement par ce dernier ou par d'autres utilisateurs approuvés.

Lors de la première configuration d'ACSLS pour le contrôle de l'accès aux volumes, précédez comme suit :

  1. Activez le contrôle de l'accès aux volumes dans ACSLS.

  2. Associez une application client à un nom d'utilisateur.

  3. Définissez les autres utilisateurs qui peuvent accéder aux volumes de l'utilisateur.

  4. Etablissez la propriété des volumes.

Activation du contrôle de l'accès aux volumes

Pour activer le contrôle de l'accès aux volumes dans ACSLS, procédez comme suit :

  1. Exécutez l'utilitaire de configuration acsss_config.

    Le menu principal s'affiche.

  2. Sélectionnez l'option 4 - Set Access Control Variables.

    Chaque variable est répertoriée individuellement et leur paramètre actuel est affiché.

  3. Cliquez sur Enter pour accepter le paramètre actuel ou celui par défaut.

  4. Sélectionnez [TRUE] et cliquez sur Enter lorsque l'utilitaire affiche le message Access control is active for volumes (Le contrôle d'accès est actif pour les volumes).

  5. Sélectionnez l'une des options suivantes lorsque l'utilitaire affiche le message Default access for volumes [ACCESS/NOACCESS] (Accès par défaut pour les volumes [ACCESS/NOACCESS])...

    • Sélectionnez [ACCESS] si vous voulez refuser l'accès à des utilisateurs spécifiques et l'accorder à tous les autres.

      Cela requiert que des utilisateurs spécifiques soient répertoriés dans un fichier users.ALL.disallow ou un fichier users.COMMAND.disallow spécifique. Voir Définition d'autres utilisateurs autorisés à accéder aux volumes de l'utilisateur.

    • Sélectionnez [NOACCESS] si vous voulez autoriser l'accès à des utilisateurs spécifiques et l'interdire à tous les autres.

      Cela requiert que certains utilisateurs soient répertoriés dans un fichier users.ALL.allow ou users.COMMAND.allow spécifique. Voir Définition d'autres utilisateurs autorisés à accéder aux volumes de l'utilisateur.

      Si vous voulez consigner les instances où l'accès à des volumes est refusé, sélectionnez [TRUE] en réponse à cette invite.

      Lors de chaque activation ou désactivation de l'accès aux volumes, vous devez redémarrer ACSLS pour appliquer la modification.

      
Associating a client identity with a user name

Les applications client ne transmettent pas toutes un ID utilisateur avec leurs paquets de demande ACSLS. Lorsque le client n'est pas identifié par un nom d'utilisateur, vous pouvez lui attribuer un ID utilisateur.

  1. Accédez au répertoire de configuration access_control :

    $ACS_HOME/data/external/access_control.

  2. Créez un fichier appelé internet.addresses ou copiez le fichier internet.addresses.SAMPLE.

  3. Dans ce fichier, créez un enregistrement pour chaque client. Chaque enregistrement contient au moins deux champs : l'adresse IP du client suivie d'un nom d'utilisateur correspondant. Vous pouvez inclure des champs supplémentaires destinés à des commentaires.

    Séparez les champs par des espaces ou des tabulations, tel qu'indiqué dans l'exemple suivant :

    192.0.2.1  ulyssis   payroll department

    Vous pouvez créer autant s'associations client-utilisateur que vous disposez d'applications client.

    • Lorsque des applications client transmettent le nom d'utilisateur avec la demande ACSLS, le fichier internet.addresses l'authentifie à l'aide de l'adresse IP désignée et refuse l'accès lorsque les deux champs ne correspondent pas aux valeurs du paquet de demande. Lorsque plusieurs clients sont hébergés sur une plate-forme commune, la même adresse IP peut être incluse plusieurs fois dans ce fichier et elle peut être associée à autant de noms d'utilisateur qu'il y a d'utilisateurs à cette adresse IP.

    • Lorsque des applications client ne transmettent pas le nom d'utilisateur avec la demande, le fichier internet.addresses établit un nom d'utilisateur pour le client. Dans ce cas, un seul nom d'utilisateur peut être associé à une adresse IP de client.

  4. Enregistrez toutes les mises à jour dans le fichier internet.addresses :

    • Exécutez acsss_config.

    • Sélectionnez l'option 6 - Rebuild Access Control Information.

    ACSLS reconnaît la modification de manière dynamique.

    Pour les clients SNA et OSLAN qui n'utilisent pas TCP/IP, reportez-vous au fichier lu62.names ou adi.names dans le répertoire access_control.

Définition d'autres utilisateurs autorisés à accéder aux volumes de l'utilisateur

Pour accorder à d'autres utilisateurs l'accès à des volumes appartenant à un utilisateur :

  1. Créez un fichier users.ALL.allow ou users.ALL.disallow dans le répertoire access_control.

    Vous pouvez copier les modèles users.SAMPLE.allow ou users.SAMPLE.disallow.

  2. Ajoutez un enregistrement dans le fichier pour chaque propriétaire, en plaçant leur ID d'utilisateur dans la marge gauche.

  3. Spécifiez les utilisateurs concernés sur la même ligne avec chaque propriétaire.

  4. Séparez les noms d'utilisateur par des espaces ou des tabulations, tel qu'indiqué dans l'exemple suivant :

    owner_john   user-Allie   user-andre

    Les noms d'utilisateur répertoriés dans les fichiers users.allow et users.disallow doivent être uniques, sans tenir compte de la casse. Le type de casse des caractères utilisés dans le nom d'utilisateur est ignoré.

    Les utilisateurs qui ne figurent pas sur la même ligne que le propriétaire sont affectés du lien par défaut (ACCESS ou NOACCESS) avec les volumes du propriétaire.

    Remarque :

    Vous ne pouvez pas indiquer une même paire owner_ID et user_ID à la fois dans les fichiers users.COMMAND.allow et users.COMMAND.disallow pour la même commande ou pour ALL. Vous ne pouvez pas non plus indiquer la paire owner_ID et user_ID dans les mêmes fichiers users.COMMAND.allow et users.COMMAND.disallow. Le même user_ID ne peut pas non plus figurer plusieurs fois sur une ligne.

    Si l'énumération des utilisateurs autorisés pour un propriétaire ne tient pas sur une ligne, la liste peut continuer sur les lignes suivantes. Chaque ligne doit commencer par l'ID du propriétaire.

  5. Le cas échéant, vous pouvez établir des exceptions au niveau de la stratégie d'accès aux volumes définie.

    Généralement, les utilisateurs se voient accorder l'accès total ou sont interdits d'accès aux volumes soumis au contrôle d'accès. Néanmoins, il est possible d'accorder aux utilisateurs certains accès limités aux volumes d'autres utilisateurs.

    Par exemple, vous pouvez définir une stratégie qui permet à tout utilisateur d'interroger des volumes qui appartiennent à un utilisateur spécifique, sans avoir à monter ou démonter ces volumes. Il est possible d'appliquer des exceptions à une des commandes affectées par le contrôle d'accès :

    Pour configurer des exceptions de stratégie d'accès aux volumes pour certaines commandes, procédez comme suit :

    • Créez un fichier users.COMMAND.allow ou users.COMMAND.disallow (où la variable COMMAND est remplacée par la commande spécifique dont vous voulez accorder ou interdire l'accès).

      Les fichiers users.COMMAND.allow et users.COMMAND.disallow doivent contenir un composant de commande portant le nom exact indiqué dans la liste ci-après, en lettres majuscules. Le contrôle de l'accès à d'autres variantes des commandes (telles que QUERY_VOLUME) n'est pas pris en charge.

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

      Remarques :

      • MOUNT (1) : les stratégies MOUNT s'appliquent également au montage des volumes de travail. Les stratégies ne s'appliquent pas au montage des volumes en lecture seule

      • MOUNT_READOLNY (2) : les stratégies de montage pour les volumes en lecture seule sont définies à part.

      • Les considérations ci-dessus concernant l'impossibilité de dupliquer une paire ID de propriétaire et ID d'utilisateur et la possibilité de continuer les listes d'utilisateurs autorisés sur les lignes suivantes concernent aussi les listes d'utilisateurs interdits.

    • Placez le nom de chaque propriétaire dans la marge de gauche, suivi de celui des utilisateurs auxquels la stratégie s'applique.

  6. Enregistrez toutes les mises à jour des stratégies définies :

    • Exécutez acsss_config

    • Sélectionnez l'option 6 - Rebuild Access Control Information.

    ACSLS reconnaît la modification de manière dynamique.

Etablissement de la propriété des volumes

Le contrôle de l'accès aux volumes s'applique uniquement à ceux dont la propriété est explicite. Le volumes de la bibliothèque qui n'ont pas de propriétaire sont accessibles par n'importe quel utilisateur. Pour définir explicitement la propriété des volumes, utilisez l'interface cmd_proc :

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

Vous pouvez supprimer une propriété de la même façon en utilisant une chaîne vide :

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

Cette opération efface la propriété de tous les volumes de la plage. Pour plus d'informations, voir set owner.

Il est possible de définir automatiquement la propriété des volumes à l'aide de l'utilitaire watch_vols. Pour plus d'informations, voir watch_vols .

Stratégies de propriété

Il est également possible de créer une stratégie pour définir et supprimer des propriétés automatiquement dans ACSLS. Par exemple, vous pouvez définir une stratégie dans laquelle tout volume de travail monté devient la propriété de l'utilisateur ayant effectué le montage. Le volume appartient ensuite à cet utilisateur. La même stratégie peut être améliorée pour supprimer la propriété à chaque fois que le volume reprend son statut de volume de travail. Il est possible d'écrire une stratégie de sorte que tous les volumes insérés soient assignés à un utilisateur par défaut, ou à l'utilisateur ayant demandé l'insertion, ou à leur propriétaire précédent (s'ils en avaient un). Cette fonctionnalité offre une grande flexibilité.

Les stratégies de propriété sont définies dans le fichier ownership.assignments qui se trouve dans le répertoire access_control. Vous pouvez définir une stratégie dans ce fichier afin d'attribuer automatiquement un propriétaire à chaque opération d'insertion, d'insertion automatique, de définition de volume de travail ou de montage de volume de travail, ou de le retirer. Le fichier ownership.assignments vous permet de définir un propriétaire par défaut. Lorsqu'un volume rencontre l'une de ces opérations, sa propriété peut être attribuée à :

  • Owner_default (le propriétaire par défaut)

  • Identique (le propriétaire précédent)

  • Demandeur (l'utilisateur émettant la demande actuelle)

  • Pas de propriétaire (retrait de la propriété du volume)

    Remarque :

    Des instructions pour définir des stratégies de propriété sont décrites en détail dans le fichier ownership.assignments. Il inclut une liste complète de commandes permettant de définir des propriétés de volume.

  • Enregistrez toutes les mises à jour des stratégies définies :

    • Exécutez acsss_config

    • Sélectionnez l'option 6 - Rebuild Access Control Information.

    ACSLS reconnaît la modification de manière dynamique.

Vérification de la propriété

Pour vérifier la propriété, vous pouvez exécuter volrpt à l'aide du modèle owner_id.volrpt.

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

Cette procédure génère l'affichage de tous les volumes de la bibliothèque répertoriés avec leur propriétaire associé.

Synthèse des accès aux volumes

Les commandes suivantes sont prises en charge par le contrôle de l'accès aux volumes :

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

Le contrôle d'accès ne s'applique pas à dismount force, car l'option "force" indique à StorageTek ACSLS d'ignorer l'ID de volume et de démonter le volume sans condition.

Le tableau suivant récapitule les contextes qui s'appliquent lorsque volume access control est activé.

Tableau 7-1 L'accès aux volumes est activé

L'accès par défaut pour les volumes est ACCESS Accès
autorisé		 Accès
refusé

L'accès s'effectue via cmd_proc

X

  

Le volume indiqué n'a pas de propriétaire

X

  

L'utilisateur est le propriétaire du volume

X

  

L'utilisateur est associé au propriétaire
dans users.ALL.disallow

  

X

Si l'utilisateur n'est pas associé au propriétaire
dans users.ALL.disallow

X

  

Tableau 7-2 L'accès aux volumes est activé

L'accès aux volumes par défaut est NOACCESS Accès
autorisé		 Accès
refusé

L'accès s'effectue via cmd_proc

X

  

Le volume indiqué n'a pas de propriétaire

X

  

L'utilisateur est le propriétaire du volume

X

  

L'utilisateur est associé au propriétaire
dans users.ALL.allow

X

  

Si l'utilisateur n'est pas associé au propriétaire
dans users.ALL.allow

  

X

Contrôle de l'accès aux commandes

Le contrôle de l'accès aux commandes permet à un administrateur ACSLS de restreindre certaines classes de commandes à des applications client ou à des utilisateurs spécifiques sur le réseau. L'accès contrôlé s'applique uniquement aux commandes utilisateur exécutées via l'ACSAPI et ne concerne pas les utilisateurs locaux qui exécute les commandes à l'aide de cmd_proc.

Le processus de configuration d'ACSLS pour le contrôle de l'accès aux commandes comprend trois étapes.

Lors de la première configuration d'ACSLS pour le contrôle de l'accès aux commandes, précédez comme suit :

  1. Activez le contrôle de l'accès aux commandes dans ACSLS.

  2. Associez une identité de client à un nom d'utilisateur.

  3. Définissez quelles commandes sont disponibles et pour quels utilisateurs.

Activation du contrôle de l'accès aux commandes

Pour activer le contrôle de l'accès aux commandes dans ACSLS, procédez comme suit :

  1. Exécutez l'utilitaire de configuration acsss_config.

    Le menu principal s'affiche.

  2. Sélectionnez l'option 4 - Set Access Control Variables.

    Chaque variable est répertoriée individuellement et leur paramètre actuel est affiché.

  3. Cliquez sur Enter pour accepter le paramètre actuel ou celui par défaut.

  4. Sélectionnez TRUE et cliquez sur Entrée lorsque l'utilitaire affiche le message Access control is active for commands.

  5. Lorsque le message "Default access for commands" (Accès par défaut pour les commandes) est affiché :

    • Sélectionnez ACCESS si vous voulez autoriser tous les utilisateurs à accéder à toutes les commandes.

      Pour empêcher certains utilisateurs d'exécuter des commandes, ils doivent figurer dans un fichier command.ALL.disallow ou command.XXX.disallow spécifique, où :

      XXX est la commande à laquelle le contrôle d'accès est destiné.

    • Sélectionnez [NOACCESS] si vous voulez refuser à l'utilisateur l'accès aux commandes.

      Pour autoriser certains utilisateurs à exécuter des commandes, ils doivent figurer dans un fichier command.ALL.allow ou command.XXX.allow spécifique.

      Remarque :

      Si vous voulez consigner les instances où l'accès à des commandes est refusé, entrez TRUE en réponse à cette invite.

      Remarque :

      Lors de chaque activation ou désactivation de l'accès aux commandes, vous devez redémarrer ACSLS pour appliquer la modification.

Association d'une identité de client à un nom d'utilisateur

Reportez-vous aux procédures sous Associating a client identity with a user name.

Définition des commandes disponibles et des utilisateurs autorisés

Ce processus dépend du comportement par défaut sélectionné lors de l'activation du contrôle de l'accès aux commandes. Vous devez créer un fichier de stratégie dans le répertoire $ACS_HOME/data/external/access_control.

  • Si le comportement par défaut défini ci-dessus est [NOACCESS], vous devez créer un fichier command.ALL.allow contenant l'ID utilisateur de chaque client qui doit avoir accès à toutes les commandes ACSLS. Chaque ID utilisateur doit figurer sur une ligne distincte dans le fichier.

    Si vous voulez uniquement accorder l'accès à des commandes spécifiques à certains utilisateurs, vous devez créer des fichiers command.XXX.allow pour chaque commande que les utilisateurs sont autorisés à exécuter. Par exemple, pour autoriser des utilisateurs spécifiques à insérer des volumes dans la bibliothèque, il est nécessaire de créer un fichier appelé command.ENTER.allow et d'y indiquer l'ID de tous les utilisateurs autorisés à effectuer une insertion, sur une ligne distincte.

  • Si le comportement par défaut défini ci-dessus est [ACCESS], vous devez créer un fichier command.ALL disallow contenant l'ID utilisateur de chaque client qui ne doit avoir accès à toutes les commandes ACSLS. Chaque ID utilisateur doit figurer sur une ligne distincte dans le fichier.

    Remarque :

    Vous ne pouvez pas indiquer le même user_ID à la fois dans les fichiers command.XXX.allow et command.XXX.disallow command.XXX pour la même commande ou pour ALL.

Noms de commande pour les fichiers allow et disallow du contrôle de l'accès aux commandes

Les fichiers command.XXX.allow et command.XXX.disallow doivent contenir un composant de commande portant le nom exact indiqué dans la liste ci-après, en majuscules. Le contrôle de l'accès à d'autres variantes des commandes (telles que QUERY_VOLUME) n'est pas pris en charge.

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

Remarque :

ENTER (1) - Les stratégies s'appliquent aux insertions virtuelles et manuelles, mais pas aux insertions automatiques. MOUNT (2) - Les stratégies s'appliquent aussi à mount scratch et mount readonly.

Utilisez le tableau suivant comme guide de référence rapide pour déterminer dans quels cas l'accès aux commandes est autorisé.

Tableau 7-3 L'accès aux commandes est activé

L'accès par défaut pour les commandes est NOACCESS Accès
autorisé		 Accès
refusé

La demande est saisie à partir de cmd_proc

X

  

L'ID utilisateur figure dans command.COMMAND.allow

X

  

L'ID utilisateur figure dans command.ALL.allow

X

  

- - Toutes les autres conditions - -

  

X

Tableau 7-4 L'accès aux commandes est activé

L'accès par défaut pour les commandes est ACCESS Accès
autorisé		 Accès
refusé

La demande est saisie à partir de cmd_proc

X

  

L'ID utilisateur figure dans command.COMMAND.disallow

  

X

L'ID utilisateur figure dans command.ALL.disallow

  

X

- - Toutes les autres conditions - -

X

  

  • Enregistrez toutes les mises à jour des stratégies définies :

    • Exécutez acsss_config

    • Sélectionnez l'option 6 - Rebuild Access Control Information.

    ACSLS reconnaît la modification de manière dynamique.

Journalisation des messages relatifs au contrôle d'accès

Vous pouvez définir une stratégie pour consigner tous les échecs de transaction en raison d'un refus d'accès à l'utilisateur. Le message affiche le nom d'utilisateur et la commande concernée.

Pour activer la journalisation du contrôle d'accès :

  1. Exécutez acsss_config et sélectionnez l'option 4 - Set Access Control Variables

  2. Remplacez [FALSE] par [TRUE] dans l'invite suivante : "Messages will be logged when access to commands or volumes is denied" (Les messages seront consignés dans un journal lors d'un refus d'accès à des commandes ou des volumes).

  3. Sélectionnez l'option 6 - Rebuild access control information.

ACSLS reconnaît la modification et commence à consigner tous les refus d'accès aux commandes.