3 Fonctions de sécurité

Cette section décrit les mécanismes de sécurité spécifiques qu'offre ACSLS.

Modèle de sécurité

L'objectif principal des fonctions de sécurité d'ACSLS est d'assurer la protection des données : il s'agit d'une part de se prémunir contre les pertes et l'altération accidentelles de données, et d'autre part de lutter contre les tentatives délibérées et non autorisées d'accéder ou de modifier ces données. Dans un second temps, elles servent également à lutter contre les délais excessifs lors de l'accès ou de l'utilisation des données ou à protéger les données contre les interférences pouvant mener à des dénis de service.

Les principales fonctions de sécurité qui assurent ces protections sont les suivantes :

  • Authentification – garantit que seules les personnes autorisées ont accès au système et aux données.

  • Autorisation – fournit un contrôle d'accès aux privilèges du système et aux données. Cette protection s'appuie sur l'authentification pour garantir que les utilisateurs ne disposent que d'un accès correspondant à leurs besoins.

  • Audit – permet aux administrateurs de détecter les tentatives de violation du mécanisme d'authentification et les tentatives réussies ou non de violation du contrôle d'accès.

Configuration et utilisation de l'authentification

Par défaut sous Linux ou Solaris, les utilisateurs ACSLS sont authentifiés par des modules PAM (Pluggable Authentication Modules). Reportez-vous aux pages de manuel Solaris ou au manuel Linux-PAM System Administrators Guide.

Les utilisateurs de l'interface graphique ACSLS sont authentifiés par le serveur LDAP intégré dans WebLogic. Consultez le document, Managing the Embedded LDAP Server:

http://docs.oracle.com/cd/E13222_01/wls/docs81/secmanage/ldap.html

Authentification des utilisateurs d'ACSLS par les systèmes d'exploitation Solaris ou Linux

Les utilisateurs d'ACSLS acsss et acssa doivent se connecter à Solaris ou Linux et être authentifiés par le système d'exploitation avant de pouvoir utiliser cmd_proc ou, pour l'utilisateur acsss, avant de pouvoir exécuter les utilitaires et les commandes de configuration d'ACSLS. L'ID utilisateur acsdb est également utilisé pour les opérations de la base de données. Dans le cadre du processus d'installation d'ACSLS, les clients doivent définir des mots de passe pour ces ID la première fois qu'ils se connectent. Pour plus d'informations, reportez-vous au Guide d'installation d'ACSLS.

Authentification des utilisateurs de l'interface graphique d'ACSLS par WebLogic

Les utilisateurs de l'interface graphique d'ACSLS doivent se connecter et être authentifiés par WebLogic. L'ID acsls_admin est créé pendant l'installation d'ACSLS et les clients doivent définir son mot de passe. Les clients peuvent, s'ils le souhaitent, ajouter d'autres utilisateurs de l'interface graphique à l'aide de l'utilitaire userAdmin.sh. Pour plus d'informations, reportez-vous au guide d'installation d'ACSLS et à la section userAdmin.sh du chapitre relatif aux utilitaires du guide de l'administrateur d'ACSLS.

Considérations relatives à l'audit

Cette section énumère des considérations générales relatives à l'audit qui s'appliquent à ACSLS.

Gestion des informations auditées

Même si l'exécution d'un audit est relativement peu onéreuse, essayez de limiter autant que possible les événements audités. Vous minimisez ainsi l'impact sur les performances de l'exécution des instructions d'audit et la taille de la piste d'audit, ce qui facilite l'analyse, la compréhension et la gestion.

Suivez les recommandations générales suivantes lorsque vous élaborez une stratégie d'audit :

Evaluez les raisons d'effectuer un audit

Une fois que vous avez bien cerné les raisons d'effectuer un audit, vous pouvez élaborer une stratégie d'audit appropriée et éviter les audits inutiles.

Effectuez un audit ciblé

Ne soumettez à l'audit que le nombre d'instructions, d'utilisateurs et d'objets strictement nécessaires pour obtenir les informations ciblées.

Configuration et utilisation des journaux d'audit d'ACSLS

ACSLS propose plusieurs journaux d'informations dans lesquels vous pouvez enregistrer et examiner les activités d'ACSLS.

  • Vous pouvez utiliser vi ou d'autres éditeurs pour les afficher. Les événements système ne peuvent être affichés qu'à l'aide de l'interface graphique d'ACSLS.

  • La plupart de ces journaux peuvent être automatiquement archivés lorsqu'ils atteignent une taille définie par le client, et le système conserve le nombre de journaux spécifiés par le client. Pour éviter de remplir le système de fichiers d'ACSLS, le nombre de journaux conservés est soumis à une limite configurable. Si vous souhaitez conserver un plus grand nombre de fichiers journaux ou si vous souhaitez les conserver sur un autre système, vous devez développer votre propre procédure pour les archiver dans un emplacement qui dispose d'un espace suffisant.

  • La taille, le nombre de journaux archivés à conserver et d'autres caractéristiques de ces fichiers sont définis par les variables dynamiques ou statiques d'ACSLS.

Répertoire des journaux d'ACSLS

Le répertoire des journaux d'ACSLS est contrôlé par la variable statique LOG_PATH. La valeur par défaut est le répertoire $ACS_HOME/log. Ce répertoire comprend les journaux suivants :

acsss_event.log

Il enregistre les messages d'erreurs, d'événements système et d'événements de bibliothèques ACSLS importants.

Lorsque le journal acsss_event.log atteint une taille limite définie par la variable dynamique LOG_SIZE, il est copié dans event0.log puis effacé. Pendant le processus de copie, les journaux d'événements conservés sont copiés dans des journaux conservés portant un numéro supérieur. Le journal conservé portant le numéro le plus élevé est remplacé. Par exemple : le journal event8.log est copié sur le journal event9.log, le journal event7.log est copié sur le journal event8.log, …, le journal event0.log est copié sur le journal event1.log, le journal acsss_event.log est copié sur le journal event0.log, et le journal acsss_event.log est effacé. Ce processus est contrôlé par les variables suivantes :

  • EVENT_FILE_NUMBER spécifie le nombre de journaux d'événements à conserver.

  • LOG_SIZE spécifie la taille limite à laquelle le journal d'événements est copié sur un journal d'événements conservé, puis tronqué.

Servez-vous de l'utilitaire greplog pour filtrer le journal acsss_event en incluant ou en excluant les messages contenant des mots-clés donnés. Pour plus d'informations, reportez-vous au chapitre relatif aux utilitaires du guide de l'administrateur d'ACSLS.

Journaux de configuration

Deux journaux enregistrent des informations lorsqu'ACSLS met à jour la configuration de bibliothèque stockée dans la base de données d'ACSLS. Ils consignent les modifications apportées à la configuration provenant de acsss_config et de Dynamic Config (l'utilitaire config).

acsss_config.log

Enregistre les informations relatives à toutes les configurations ou reconfigurations de la bibliothèque ou des bibliothèques prises en charge par ACSLS. La dernière modification de configuration est ajoutée à la liste des configurations antérieures.

acsss_config_event.log

Enregistre les événements lors des processus de configuration ou de reconfiguration.

rpTrail.log

Enregistre les réponses à toutes les demandes adressées à ACSLS émanant de cmd_proc ou de clients ACSAPI, ainsi que toutes les demandes adressées à l'interface graphique ou à l'interface client SCSI aux bibliothèques logiques, à l'exception des requêtes à la base de données. Sont consignées les informations relatives au demandeur, à la demande et à l'horodatage de la demande.

rpTrail.log est géré par les variables suivantes :

  • LM_RP_TRAIL active cette piste d'audit d'événements ACSLS. La valeur par défaut est TRUE.

  • RP_TRAIL_LOG_SIZE indique la taille limite à laquelle le journal rpTrail.log est compressé et archivé.

  • RP_TRAIL_FILE_NUM indique le nombre de journaux rpTrail archivés à conserver.

  • RP_TRAIL_DIAG indique si les messages rpTrail doivent inclure des informations de diagnostic supplémentaires. La valeur par défaut est FALSE.

Statistiques des volumes de bibliothèques

Enregistre tous les événements qui ont une incidence sur les volumes (cartouches) d'une bibliothèque de bandes, y compris le montage, le démontage, le déplacement, l'insertion et l'éjection des volumes ainsi que la détection des volumes par l'audit ou par Cartridge Recovery. Si l'option Library Volume Statistics est activée, ces informations sont enregistrées dans le journal acsss_stats.log.

Les statistiques des volumes de bibliothèques sont gérées par les variables suivantes :

  • LIB_VOL_STATS active l'option Library Volume Statistics. La valeur par défaut est OFF.

  • VOL_STATS_FILE_NUM indique le nombre de fichiers acsss_stats.log archivés à conserver.

  • VOL_STATS_FILE_SIZE indique la taille limite à laquelle le journal acsss_stats.log est archivé.

Répertoire Log/sslm d'ACSLS

A l'intérieur du répertoire des journaux d'ACSLS, des informations concernant l'interface graphique d'ACSLS et l'interface client SCSI aux bibliothèques logiques sont enregistrées dans le répertoire sslm. Ce répertoire contient des liens vers des journaux d'audit WebLogic. Le répertoire sslm comprend les journaux suivants :

slim_event.g#.log[.pp#]

Ce journal consigne des événements provenant de l'interface graphique d'ACSLS et de l'interface client SCSI. Il inclut les messages relatifs aux modifications apportées à la configuration de bibliothèques logiques et les événements des clients SCSI.

  • .g# correspond au numéro de génération de ce journal.

  • .pp# correspond au numéro de processus parallèle de ce journal. Si plusieurs processus sont consignés simultanément, un numéro de processus parallèle est attribué aux journaux des processus supplémentaires.

smce_trace.log

Ce journal assure le suivi des activités entre les clients SCSI et les bibliothèques logiques d'ACSLS à l'aide de l'émulation de l'interface de changeur de média SCSI.

guiAccess.log

Il s'agit d'un lien vers le journal access.log de WebLogic. Voir Configuration et utilisation des journaux d'audit de WebLogic.

AcslsDomain.log

Il s'agit d'un lien vers le journal AcslsDomain.log de Weblogic. Voir Configuration et utilisation des journaux d'audit de WebLogic.

AdminServer.log

Il s'agit d'un lien vers le journal AdminServer.log de WebLogic. Voir Configuration et utilisation des journaux d'audit de WebLogic.

Affichage des pistes d'audit d'ACSLS sur le visionneur de journaux de l'interface graphique

Accédez au visionneur de journaux à partir de la section Configuration and Administration de l'arborescence de navigation de l'interface graphique. Le visionneur de journaux affiche les informations combinées des journaux acsss_event.log et smce_trace.log.

Affichage des événements système sur l'interface graphique

Vous pouvez également afficher les événements système à partir de la section Configuration and Administration de l'arborescence de navigation de l'interface graphique. Toute les activités individuelles de la bibliothèque sont enregistrées dans le journal d'événements système. Chaque enregistrement de ce journal contient un horodatage des événements, le type d'événement et une description de l'événement.

Configuration et utilisation des journaux d'audit de Solaris

Déterminez votre stratégie d'audit Solaris. Reportez-vous à la section "Audit dans Oracle Solaris" du manuel Administration d'Oracle Solaris : Services de sécurité pour savoir quels événements soumettre à un audit, où enregistrer les journaux d'audit et comme passer en revue les journaux d'audit.

Si vous n'avez pas activé de piste d'audit Solaris personnalisée, vous disposez des pistes d'audit de connexions et commandes Unix émises par les utilisateurs acsss, acsdb, et acssa suivantes :

  • Les utilisateurs actuellement connectés à Unix sont enregistrés dans la base de données utmpx d'Unix et les anciens accès utilisateur sont enregistrés dans la base de données wtmpx.

  • Utilisez la commande last pour afficher tous les accès d'un ID utilisateur (par exemple : last acsss). Pour plus d'informations, reportez-vous aux pages de manuel de wtmpx, last et getutxent.

  • Les fichiers .*_history (c'est-à-dire [point]*_history) dans le répertoire personnel d'un utilisateur enregistrent les commandes émises par cet utilisateur.

    Pour l'utilisateur acsss, il peut s'agir des fichiers :

    • .bash_history

    • .psql_history

    • .sh_history

    Dans Solaris, /var/adm/sulog enregistre les tentatives réussies ou non d'exécuter su afin de devenir superutilisateur ou un autre utilisateur.

Configuration et utilisation des journaux d'audit de Linux

Pour plus d'informations sur la collecte et l'analyse des journaux d'audit et des journaux système, reportez-vous à la section relative à la configuration et à l'utilisation de l'audit et à la section relative à la configuration et à l'utilisation de la connexion au système du guide de sécurité de la version 6 d'Oracle Linux.

Configuration et utilisation des journaux d'audit de WebLogic

Reportez-vous à Oracle Fusion Middleware; Understanding Security for Oracle WebLogic Server 11g Release 1 (10.3.6) pour connaître les options permettant de sécuriser un serveur WebLogic ainsi que les possibilités de pistes d'audit avec WebLogic.

WebLogic enregistre les accès à l'interface graphique d'ACSLS dans le répertoire suivant :

/export/home/SSLM/AcslsDomain/servers/AdminServer/logs

Ce répertoire contient les fichiers suivants :

  • access.log

    • Il existe des versions archivées appelées access.log##### (par exemple access.log00001)

    • Ce fichier fournit une piste d'audit détaillée de l'activité des utilisateurs de l'interface graphique.

    • Pour les connexions, recherchez "AcslsLoginForm".

      Remarque :

      $ACS_HOME/logs/sslm/guiAccess.log contient un lien vers le journal des accès.
  • AcslsDomain.log

    • Ce journal consigne les opérations de WebLogic et de l'interface graphique d'ACSLS.

      Remarque :

      $ACS_HOME/logs/sslm/AcslsDomain.log contient un lien vers le journal des accès.
  • AdminServer.log

    • Ce journal consigne les opérations de WebLogic et de l'interface graphique d'ACSLS.

      Remarque :

      $ACS_HOME/logs/sslm/AdminServer.log contient un lien vers le journal des accès.