23.2 Audit avec XDASv2

La spécification XDASv2 fournit une classification standardisée pour les événements d’audit. Elle définit un ensemble d’événements génériques à un niveau système distribué global. XDASv2 offre un format d’enregistrement d’audit portable courant pour faciliter la fusion et l’analyse d’informations d’audit provenant de plusieurs composants au niveau système distribué. Les événements XDASv2 sont encapsulés dans un système de notation hiérarchique qui permet d’étendre l’ensemble d’identificateurs d’événements standard ou existants. La taxonomie XDASv2 définit un ensemble de champs, les plus importants étant Observer (Observateur), Initiator (Initiateur) et Target (Cible). Les événements XDASv2 facilitent la compréhension des suivis d'audit d'applications hétérogènes.

Configurer l'annuaire eDirectory pour qu'il utilise XDASv2 offre les avantages suivants :

  • fournit des services d'audit sécurisés pour un système distribué ;

  • définit un ensemble d'événements génériques au niveau d'un système distribué global ;

  • définit un format d'enregistrement d'audit portable commun, qui facilite la fusion et l'analyse des informations d'audit provenant de plusieurs composants d'un système distribué ;

  • définit un format commun pour les événements d'audit que les applications d'analyse peuvent utiliser ;

  • enregistre le suivi d'audit XDASv2 ;

  • configure des critères de présélection d'événements et des actions d'organisation des événements ;

  • fournit un format d'audit commun, indépendamment de la plate-forme sur laquelle le service XDASv2 est exécuté ;

  • prend en charge des environnements hétérogènes, sans avoir à remanier le système d'exploitation actuel ni les implémentations de service d'audit spécifiques des applications ;

  • prend en charge la séparation adéquate des tâches pour les utilisateurs ;

  • protège le journal d'audit en le rendant accessible uniquement aux principaux remplissant des rôles d'administration ou de sécurité bien déterminés ;

  • met éventuellement en cache les événements d'audit localement sur l'agent en cas d'interruption de la communication entre l'agent et le serveur d'audit, et renvoie les événements une fois la communication rétablie.

23.2.1 Configuration de XDASv2

Le paquetage de téléchargement du kit d'installation d'eDirectory inclut un client XDAS pour Linux et un autre pour Windows. Le programme d'installation d'eDirectory installe les paquetages XDASv2 sur votre système d'exploitation. Le paquetage XDASv2 contient les fichiers suivants :

  • Linux

    • novell-edirectory-xdaslog

    • novell-edirectory-xdaslog-conf

    • novell-edirectory-xdasinstrument

  • Windows

    • xdasauditds.dlm

    • xdaslog.dll

REMARQUE :à partir d'OES 11 SP2, les RPM XDAS sont fournis avec Open Enterprise Server.

Configuration système requise

L'installation et l'utilisation du plug-in NetIQ Audit pour iManager requièrent iManager 3.0 ou version ultérieure. Pour en savoir plus sur la configuration requise et obtenir les instructions de téléchargement, reportez-vous à la page du produit NetIQ iManager.

Installation ou mise à niveau du plug-in iManager pour XDASv2

Le plug-in iManager pour XDASv2 est fourni avec les plug-ins eDirectory. Ces derniers peuvent également être téléchargés à partir du site de téléchargement NetIQ.

Procédez comme suit pour mettre à niveau le plug-in vers la version la plus récente.

  1. Ouvrez iManager à partir d'un navigateur Web, à l'aide de l'URL suivante :

    https://ip_address_or_DNS/nps/iManager.html
    

    adresse_ip_ou_DNS représente l’adresse IP ou le nom DNS de votre serveur iManager.

    Par exemple :

    http://111.111.1.1/nps/iManager.html
    
  2. Connectez-vous à iManager à l'aide de votre nom d'utilisateur et de votre mot de passe.

    Dans iManager, vous avez accès uniquement aux rôles pour lesquels des droits vous ont été assignés. Pour avoir accès à toutes les fonctions de NetIQ iManager, vous devez vous connecter avec les références d'un utilisateur disposant de droits d'administrateur sur l'arborescence.

    Pour plus d'informations, reportez-vous au Guide d'administration de NetIQ iManager.

  3. Sélectionnez Configuration de l'audit dans le menu Rôles et tâches.

  4. Cliquez sur le lien Mettre à niveau la configuration de XDAS.

    iManager affiche un message d'alerte à propos du processus de mise à niveau.

  5. Cliquez sur OK.

    Pendant la mise à niveau, les nouveaux fichiers iManager sont installés et la configuration est modifiée. Une fois la mise à niveau terminée, un message indiquant si l'installation a réussi ou échoué s'affiche.

Configuration du fichier de propriétés de XDASv2

Un exemple de fichier de propriétés (xdasconfig.properties.template) est inclus dans le répertoire configdir (n4u.server.configdir) sur le support d'eDirectory.

Le Tableau 23-1 indique l'emplacement par défaut du fichier xdasconfig.properties sur les systèmes d'exploitation Linux et Windows.

Tableau 23-1 Fichier de configuration de XDAS

Système d'exploitation

Emplacement du fichier de propriétés

Linux

/etc/opt/novell/eDirectory/conf/
xdasconfig.properties

Pour les installations non-root, le fichier de propriétés de XDASv2 se trouve dans le répertoire conf.

Windows

<Install Path>/novell/nds/xdasconfig
 

Le fichier de propriétés se trouve généralement dans le répertoire d'installation d'eDirectory.

Si vous configurez le fichier de propriétés, puis mettez à niveau votre environnement vers eDirectory 9.0, le programme d'installation ne remplace pas le fichier de propriétés. Le cas échéant, le processus de mise à niveau met à jour le fichier (xdasconfig.properties.template) de manière à conserver la personnalisation.

Après avoir installé iManager, vous pouvez configurer XDAS. Les paramètres de configuration de XDAS sont stockés dans un simple fichier de configuration au format texte (xdasconfig.properties), que vous pouvez personnaliser en fonction de vos besoins.

Le fichier de propriétés de XDASv2 contient les informations suivantes :

Linux

# Set the level of the root logger to DEBUG and attach appenders.
#log4j.rootLogger=debug, S, R
# Defines appender S to be a SyslogAppender. 
#log4j.appender.S=org.apache.log4j.net.SyslogAppender
# Defines location of Syslog server.
#log4j.appender.S.Host=localhost
#log4j.appender.S.Port=port
# Specify protocol to be used (UDP/TCP/SSL)
#log4j.appender.S.Protocol=UDP
# Specify SSL certificate file for SSL connection.
# File path should be given with double backslash.
#log4j.appender.S.SSLCertFile=/etc/opt/novell/mycert.pem
# Minimum log-level allowed in syslog.
#log4j.appender.S.Threshold=INFO
# Defines the type of facility.
#log4j.appender.S.Facility=USER
# Defines caching for SyslogAppender.
# Inputs should be yes/no
#log4j.appender.S.CacheEnabled=no
# Cache location directory
# Directory should be available for creating cache files
#log4j.appender.S.CacheDir=/var/opt/novell/eDirectory
# Cache File Size
# Cache File Size should be in the range of 50MB to 4000MB
#log4j.appender.S.CacheMaxFileSize=500MB
# Layout definition for appender Syslog S.
#log4j.appender.S.layout=org.apache.log4j.PatternLayout
#log4j.appender.S.layout.ConversionPattern=%c : %p%m%n
# Defines appender R to be a Rolling File Appender.
#log4j.appender.R=org.apache.log4j.RollingFileAppender
# Log file for appender R.
#log4j.appender.R.File=/var/opt/novell/eDirectory/log/xdas-events.log
# Max size of log file for appender R.
#log4j.appender.R.MaxFileSize=100MB
# Set the maximum number of backup files to keep for appender R.
# Max can be 13. If set to zero, then there will be no backup files.
#log4j.appender.R.MaxBackupIndex=10
# Layout definition for appender Rolling log file R.
#log4j.appender.R.layout=org.apache.log4j.PatternLayout
#log4j.appender.R.layout.ConversionPattern=%d{MMM dd HH:mm:ss} %c : %p%m%n

Windows

# Set the level of the root logger to DEBUG and attach appenders.
#log4j.rootLogger=debug, S, R
# Defines appender S to be a SyslogAppender. 
#log4j.appender.S=org.apache.log4j.net.SyslogAppender
# Defines location of Syslog server.
#log4j.appender.S.Host=localhost
#log4j.appender.S.Port=port
# Specify protocol to be used (UDP/TCP/SSL)
#log4j.appender.S.Protocol=UDP
# Specify SSL certificate file for SSL connection.
# File path should be given with double backslash.
#log4j.appender.S.SSLCertFile=C:\\Novell\\mycert.pem
# Minimum log-level allowed in syslog.
#log4j.appender.S.Threshold=INFO
# Defines the type of facility.
#log4j.appender.S.Facility=USER
# Defines caching for SyslogAppender.
# Inputs should be yes/no
#log4j.appender.S.CacheEnabled=no
# Cache location directory
# Directory should be available for creating cache files
#log4j.appender.S.CacheDir=C:\\Novell\\NDS
# Cache File Size
# Cache File Size should be in the range of 50MB to 4000MB
#log4j.appender.S.CacheMaxFileSize=500MB
# Layout definition for appender Syslog S.
#log4j.appender.S.layout=org.apache.log4j.PatternLayout
#log4j.appender.S.layout.ConversionPattern=%c : %p%m%n
# Defines appender R to be a Rolling File Appender.
#log4j.appender.R=org.apache.log4j.RollingFileAppender
# Log file for appender R.
#log4j.appender.R.File=/var/opt/novell/eDirectory/log/xdas-events.log
# Max size of log file for appender R.
#log4j.appender.R.MaxFileSize=100MB
# Set the maximum number of backup files to keep for appender R.
# Max can be 13. If set to zero, then there will be no backup files.
#log4j.appender.R.MaxBackupIndex=10
# Layout definition for appender Rolling log file R.
#log4j.appender.R.layout=org.apache.log4j.PatternLayout
#log4j.appender.R.layout.ConversionPattern=%d{MMM dd HH:mm:ss} %c : %p%m%n

Avant d'examiner le contenu du fichier xdasconfig.properties, NetIQ recommande de passer en revue les points suivants :

  • Les lettres S et R correspondent respectivement à l'appender Syslog et à l'appender RollingFile.

  • Les entrées ne respectent pas la casse.

  • Les entrées peuvent apparaître dans n'importe quel ordre.

  • Les lignes vides dans le fichier sont valides.

  • Toute ligne commençant par un signe dièse (#) est commentée.

Le tableau ci-dessous fournit des informations à propos des paramètres du fichier xdasconfig.properties.

IMPORTANT :vous devez redémarrer eDirectory à chaque fois que vous apportez une modification à la configuration.

Valeur

Description

log4j.rootLogger=debug, S, R

Définit le niveau de l'enregistreur racine sur Débogage et y associe un appender nommé R ou S, S correspondant à Syslog et R à Rolling File.

log4j.appender.S=org.apache.log4j.net.SyslogAppender

Indique que l'appender S doit être un appender Syslog.

log4j.appender.S.Host=localhost

Indique à quel emplacement du serveur Syslog les événements XDAS sont consignés.

Par exemple : log4j.appender.S.Host=192.168.0.1

log4j.appender.S.Port=port

Port au niveau duquel XDAS se connecte au serveur Syslog.

Le numéro de port peut être compris entre 1 et 65535. Si vous spécifiez une valeur non valide, le numéro de port est défini par défaut sur 514.

En cas d'échec de la connexion entre XDAS et le serveur Syslog, Identity Manager ne peut pas consigner les événements tant que la connexion n'a pas été rétablie.

log4j.appender.S.Protocol=UDP

Indique le protocole à utiliser. Par exemple : UDP, TCP ou SSL.

log4j.appender.S.SSLCertFile=/etc/opt/novell/mycert.pem

Spécifie le fichier de certificat SSL pour la connexion SSL. Utilisez deux barres obliques inverses pour spécifier le chemin d'accès au fichier. Ce paramètre est facultatif.

log4j.appender.S.Threshold=INFO

Spécifie le niveau de consignation minimal autorisé dans l'appender Syslog. Actuellement, le niveau de consignation INFO est pris en charge.

log4j.appender.S.Facility=USER

Indique le type d'installation. L'installation est utilisée pour tenter de classer le message. Actuellement, l'installation USER est prise en charge. Ces valeurs peuvent être spécifiées en majuscules ou en minuscules.

log4j.appender.S.layout=org.apache.log4j.PatternLayout

Paramètre d'agencement de l'appender Syslog.

log4j.appender.S.layout.ConversionPattern=%c : %p%m%n

Paramètre d'agencement de l'appender Syslog. Pour plus d'informations sur les schémas de conversion et leur description, consultez le site logging.apache.org.

log4j.appender.R=org.apache.log4j.RollingFileAppender

Indique que l'appender R doit être un appender RollingFile.

log4j.appender.R.File=/var/opt/novell/eDirectory/log/xdas-events.log

Emplacement du fichier journal pour l'appender RollingFile.

log4j.appender.R.MaxFileSize=100MB

Taille maximale, en Mo, du fichier journal pour l'appender RollingFile. Définissez cette valeur sur la taille maximale autorisée par le client.

log4j.appender.R.MaxBackupIndex=10

Spécifiez le nombre maximal de fichiers de sauvegarde pour l'appender RollingFile. Le nombre maximal de fichiers de sauvegarde peut être 10. Une valeur zéro signifie qu'aucun fichier de sauvegarde n'est présent.

log4j.appender.R.layout=org.apache.log4j.PatternLayout

Paramètre d'agencement de l'appender RollingFile.

log4j.appender.R.layout.ConversionPattern=%d{MMM dd HH:mm:ss} %c : %p%m%n

Paramètre d'agencement de l'appender RollingFile. Pour des modèles de format de date simples, reportez-vous au Tableau 23-2.

Pour plus d'informations sur les schémas de conversion et leur description, consultez le site logging.apache.org.

Le Tableau 23-2 donne des exemples de modèles de date et d'heure interprétés aux États-Unis. Les date et heure en question sont le 04/07/2012, 12 h 8 min 56 s, heure du Pacifique aux États-Unis.

Tableau 23-2 Exemples de modèles de date et d'heure

Modèle de date et d'heure

Résultat

"aaaa.MM.jj G 'à' HH:mm:ss z"

2012.07.04 AD at 12:08:56 PDT (04.07.2012 ap. J-C à 12:08:56 HAP)

"EEE, MMM j, ''aa"

Wed, Jul 4, '01 (Mer, 4 juil. 2001)

"h:mm a"

12:08 PM (12:08)

"hh 'heures' a, zzzz"

12 o'clock PM, Pacific Daylight Time (12 heures, heure avancée du Pacifique)

"K:mm a, z"

12:08 PM, PDT (12:08, HAP)

"aaaaa.MMMMM.jj GGG hh:mm aaa"

02012.July.24 AD 12:08 PM (02012.Juillet.24 ap. J-C 12:08)

"EEE, j MMM aaaa HH:mm:ss Z"

Wed, 24 Jul 2012 12:08:56 -0700 (Mer, 24 juil. 2012 12:08:56 -0700)

"aaMMjjHHmmssZ"

120724120856-0700

"aaaa-MM-jj'T'HH:mm:ss.SSSZ"

2012-07-04T12:08:56.235-0700 (2012-07-04T12:08:56.235-0700)

Activation de l'appender Syslog

Si vous souhaitez centraliser les messages d'audit à un seul emplacement, vous pouvez utiliser l'appender Syslog. Par ailleurs, un serveur Syslog offre une meilleure prise en charge des sauvegardes en cas de sinistre.

Pour activer l'appender Syslog, apportez les modifications suivantes dans le fichier xdasxconfig.properties :

  1. Remplacez la valeur de l'entrée ci-dessous par S pour joindre un appender Syslog :

    log4j.rootLogger=debug, S

  2. Supprimez les marques de commentaire des entrées suivantes :

    log4j.appender.S=org.apache.log4j.net.SyslogAppender
    
    log4j.appender.S.Host=localhost
    
    log4j.appender.S.Port=port
    
    log4j.appender.S.Protocol=UDP
    
    log4j.appender.S.SSLCertFile=/etc/opt/novell/mycert.pem
    
    #log4j.appender.S.Threshold=INFO
    
    #log4j.appender.S.Facility=USER
    
    #log4j.appender.S.layout=org.apache.log4j.PatternLayout
    
    #log4j.appender.S.layout.ConversionPattern=%c : %p%m%n
    
  3. Connectez-vous à iManager et modifiez les événements de journal. Pour plus d'informations sur la configuration des événements XDAS, reportez-vous à la section Configuration des événements XDAS pour l'audit.

Génération d'un certificat pour la connexion SSL Syslog

Pour générer un certificat pour la connexion Syslog :

  1. Créez le certificat à l'aide de la commande OpenSSL suivante :

    openssl s_client -host LOG_SERVER  -port 1443 -showcerts
    
  2. Copiez le certificat que vous avez créé dans le fichier /etc/opt/novell/eDirectory/conf/xdasconfig.properties.

Activation de l'appender RollingFile

Si la solution d'audit est limitée à un seul serveur, il est préférable d'opter pour l'appender File. Le nombre de composants à configurer étant limité, cette solution est également facile à mettre en oeuvre et plus adaptée aux démonstrations.

Pour activer l'appender RollingFile, apportez les modifications suivantes dans le fichier xdasxconfig.properties :

  1. Remplacez la valeur de l'entrée ci-dessous par R pour joindre l'appender RollingFile :

    log4j.rootLogger=debug, R

  2. Supprimez les marques de commentaire des entrées suivantes :

    log4j.appender.R=org.apache.log4j.RollingFileAppender
    
    log4j.appender.R.File=/var/opt/novell/eDirectory/log/xdas-events.log
    
    log4j.appender.R.MaxFileSize=100MB
    
    log4j.appender.R.MaxBackupIndex=10
    
    log4j.appender.R.layout=org.apache.log4j.PatternLayout
    
    log4j.appender.R.layout.ConversionPattern=%d{MMM dd HH:mm:ss} %c : %p%m%n
    
  3. Sélectionnez l'événement souhaité dans iManager.

    Pour plus d'informations sur la configuration des événements XDAS, reportez-vous à la section Configuration des événements XDAS pour l'audit.

Configuration de XDASv2 pour l'audit

Configuration de XDASv2 à l'aide du plug-in iManager

  1. Ouvrez iManager à partir d'un navigateur Web, à l'aide de l'URL suivante :

    https://ip_address_or_DNS/nps/iManager.html
    

    adresse_ip_ou_DNS représente l’adresse IP ou le nom DNS de votre serveur iManager.

    Par exemple :

    http://111.111.1.1/nps/iManager.html
    
  2. Connectez-vous en entrant votre nom d'utilisateur et votre mot de passe.

    Dans iManager, vous avez accès uniquement aux rôles pour lesquels des droits vous ont été assignés. Pour avoir accès à toutes les fonctions de NetIQ iManager, vous devez vous connecter avec les références d'un utilisateur disposant de droits d'administrateur sur l'arborescence.

    Pour plus d'informations, reportez-vous au Guide d'administration de NetIQ iManager.

  3. Sélectionnez Configuration de l'audit dans le menu Rôles et tâches.

  4. Spécifiez le nom de votre serveur eDirectory dans Serveur NCP, puis cliquez sur l'icône Sélecteur d'objet pour rechercher le serveur eDirectory.

  5. Cliquez sur OK.

    La page XDASv2 Audit (Audit de XDASv2) s'affiche. Passez à la Section 23.2.1, Configuration de XDASv2.

Configuration des événements XDAS pour l'audit

  1. Connectez-vous à iManager à l'aide de votre nom d'utilisateur et de votre mot de passe.

  2. Sélectionnez Configuration de l'audit dans le menu Rôles et tâches.

  3. Sélectionnez l'onglet XDAS.

  4. Configurez les événements XDASv2.

    • Global : vous pouvez sélectionner ou désélectionner les paramètres globaux pour les entrées en double.

      • Ne pas envoyer d'événement répliqué : sélectionnez cette option pour ne plus recevoir d'entrées répliquées, telles que les connexions pour eDirectory.

    • Consigner les grandes valeurs d'événements : les événements sont consignés dans un fichier texte. Les valeurs d'événements de plus de 768 octets sont considérées comme de « grandes valeurs ». Vous pouvez consigner des événements de n'importe quelle taille.

      • Consigner de grandes valeurs : sélectionnez cette option pour consigner les événements dont la taille est supérieure à 768 octets.

      • Ne pas consigner de grandes valeurs : sélectionnez cette option pour consigner les événements dont la taille est inférieure à 768 octets. Si l'événement est plus volumineux, sa valeur est tronquée et enregistrée dans le fichier journal.

    • Composants : vous pouvez sélectionner l'un des deux composants, ou les deux, pour configurer les événements XDASv2.

      • DS : spécifie un objet eDirectory. Pour chaque objet DS, il existe un objet LDAP correspondant.

      • LDAP : spécifie un objet LDAP.

        REMARQUE :vous pouvez sélectionner les composants DS et LDAP à un niveau granulaire pour les événements XDAS. En fonction de l'événement choisi, les composants adéquats qui sont pris en charge pour cet événement sont sélectionnés. Par exemple, si vous sélectionnez l'événement Supprimer le compte, les composants DS et LDAP sont sélectionnés.

    • Configuration des événements XDAS : spécifiez des valeurs pour les options ci-dessous, en fonction des événements requis pour votre environnement :

      Options

      Description

      Événements de gestion de compte

      Sélectionnez les événements de gestion de compte pour lesquels vous souhaitez consigner des événements. Vous pouvez consigner des événements pour créer, supprimer, activer, désactiver et interroger des comptes, mais aussi pour modifier le jeton de sécurité d'un compte.

      Événements de gestion de session

      Sélectionnez les événements de gestion de session pour lesquels vous souhaitez consigner des événements. Vous pouvez consigner des événements pour créer, quitter et modifier des sessions.

      Événements de gestion d'élément de ressources ou de données

      Sélectionnez les événements de gestion d'élément de ressources ou de données pour lesquels vous souhaitez consigner des événements. Vous pouvez consigner des événements pour créer et supprimer des éléments de données ainsi que pour modifier et interroger des attributs d'éléments de données.

      Événements de gestion de service ou d'application

      Sélectionnez les événements de gestion de service ou d'application pour lesquels vous souhaitez consigner des événements. Vous pouvez consigner des événements pour activer et désactiver des services.

      Événements d'utilisation de service ou d'application

      Sélectionnez les événements d'utilisation de service ou d'application pour lesquels vous souhaitez consigner des événements. Vous pouvez consigner des événements pour démarrer et arrêter des services ainsi que pour modifier des contextes de processus.

      Événements de gestion d'association homologue

      Sélectionnez les événements d'association homologue pour lesquels vous souhaitez consigner des événements. Vous pouvez consigner des événements pour créer et arrêter des associations homologues.

      Événements d'accès de contenu d'élément de ressources ou de données

      Sélectionnez les événements d'accès de contenu d'élément de ressources ou de données pour lesquels vous souhaitez consigner des événements. Vous pouvez consigner des événements pour créer, arrêter et modifier des associations d'élément de données.

      Événements de gestion de rôle

      Sélectionnez les événements de gestion de rôle pour lesquels vous souhaitez consigner des événements. Vous pouvez consigner des événements pour créer, supprimer, interroger et modifier des attributs ou des objets eDirectory.

      Événements de gestion exceptionnels

      Sélectionnez les événements de gestion exceptionnels pour lesquels vous souhaitez consigner des événements. Vous pouvez consigner des événements pour démarrer et arrêter des systèmes ainsi que pour sauvegarder et restaurer des zones de stockage de données.

      Événements de gestion d'authentification

      Sélectionnez les événements de gestion d'authentification pour lesquels vous souhaitez consigner des événements. Vous pouvez consigner des événements pour authentifier des sessions et créer des jetons d'accès.

      Événements opérationnels

      Sélectionnez les événements de gestion opérationnels pour lesquels vous souhaitez consigner des événements. Vous pouvez consigner des événements pour générer des ID d'opération eDirectory.

      Pour plus d'informations sur les événements internes eDirectory assignés aux événements XDAS correspondants, reportez-vous à la section Assignation d'événements eDirectory à des événements XDAS.

      REMARQUE :une fois l'événement sélectionné, l'application des modifications de configuration sur le serveur NCP peut prendre jusqu'à 3 minutes. Si vous voulez que les modifications apportées à la configuration soient mises en oeuvre immédiatement sur le serveur NCP, vous pouvez décharger et charger le module xdasauditds.

Chargement et déchargement des modules

Une fois les événements XDASv2 configurés, exécutez les commandes ci-dessous pour charger et décharger les modules XDASv2.

Pour charger automatiquement le module xdasauditds à chaque démarrage du serveur ndsd :

  • Linux

    Ajoutez xdasauditds au fichier /etc/opt/novell/eDirectory/conf/ndsmodules.conf.

  • Windows

    Exécutez le fichier ndscons.exe, sélectionnez xdasauditds dans la liste des modules disponibles, cliquez sur Démarrage, puis définissez l'option Type de démarrage sur Automatique.

Pour charger et décharger manuellement le module xdasauditds :

  • Linux

    Pour charger le module, exécutez ndstrace -c "load xdasauditds".

    Pour décharger le module, exécutez ndstrace -c "unload xdasauditds".

  • Windows

    Pour charger le module, exécutez le fichier ndscons.exe, sélectionnez xdasauditds dans la liste des modules disponibles, puis cliquez sur Démarrer.

    Pour décharger le module, exécutez le fichier ndscons.exe, sélectionnez xdasauditds dans la liste des modules disponibles, puis cliquez sur Arrêter.

Si vous avez installé NMAS et activé l'audit de NMAS, le serveur NMAS charge automatiquement la bibliothèque XDASv2.

Activation du caching des événements XDAS

eDirectory 9.0 inclut une option permettant de stocker localement les événements XDAS sur l'agent dans un cache d'appender Syslog. Lorsque les événements sont mis en cache, si l'agent ne peut pas communiquer avec le serveur d'audit, les événements d'audit générés sont conservés, ce qui permet d'éviter toute perte des données d'audit. Une fois la communication rétablie entre l'ordinateur de l'agent et le serveur d'audit, l'agent tente de renvoyer les événements mis en cache.

Le caching des événements XDAS est désactivé par défaut. Pour activer le caching des événements, procédez comme suit :

  1. Sur l'ordinateur de l'agent, accédez à l'emplacement du fichier de propriétés de XDASv2. Par défaut, le fichier xdasconfig.properties se trouve dans /etc/opt/novell/eDirectory/conf/xdasconfig.properties. Pour les installations non-root, le fichier de propriétés de XDASv2 se trouve par défaut dans le répertoire conf.

  2. Utilisez un éditeur de texte pour ouvrir le fichier xdasconfig.properties.

  3. Dans le fichier de propriétés, accédez à la propriété log4j.appender.S.CacheEnabled et définissez sa valeur sur yes.

  4. Si vous souhaitez mettre en cache les événements dans un répertoire spécifique, définissez la valeur de la propriété log4j.appender.S.CacheDir sur le chemin d'accès à ce répertoire. Le chemin d'accès par défaut est /var/opt/novell/eDirectory. Si vous spécifiez un répertoire, assurez-vous que son chemin est un emplacement valide sur le serveur. Si le chemin d'accès spécifié n'existe pas, l'appender Syslog consigne les événements à l'emplacement par défaut.

  5. Si vous souhaitez spécifier une taille de fichier personnalisée pour le cache, modifiez la valeur de la propriété log4j.appender.S.CacheMaxFileSize. La valeur par défaut est 500 Mo. La valeur minimale est 50 Mo et la valeur maximale, 4 Go.

  6. Enregistrez, puis fermez le fichier xdasconfig.properties.

Utilisation de collecteurs d'événements XDAS

Pour plus d'informations sur l'utilisation de collecteurs d'événements XDAS, consultez la page des plug-ins Sentinel .

Filtrage des événements d'audit XDASv2

À l'aide de filtres et de notifications d'événement, XDASv2 est capable de signaler la survenue ou la non-survenue d'un type d'événement spécifique. Vous pouvez également filtrer les événements pour un(e) ou plusieurs classes ou attributs d’objet spécifiques, selon le type d’événement. XDASv2 évalue tous les événements générés par rapport aux filtres configurés sur le serveur eDirectory et enregistre uniquement les événements répondant aux critères de ces filtres. Si plusieurs filtres sont configurés, ils filtrent les événements XDASv2 séparément. Par exemple, si vous filtrez les événements à la fois sur la base d'une classe d'objet spécifique et d'un ou de plusieurs attributs, XDASv2 consigne les événements répondant uniquement aux critères des filtres que vous avez configurés pour la classe d'objet. Vous ne pouvez pas configurer le filtrage de sorte que XDASv2 n'envoie que les événements d'une certaine classe d'objet et de certains attributs au client. Vous pouvez sélectionner plusieurs classes d'objet ou attributs sur la base desquels vous souhaitez filtrer les événements XDASv2.

Vous pouvez configurer des filtres et des notifications d'événement pour les comptes et les rôles XDASv2.

Ce chapitre fournit les informations dont vous avez besoin pour configurer des filtres et des notifications pour votre système.

Filtrage des comptes XDASv2

Vous pouvez configurer le filtrage des comptes de manière à ne rechercher qu'un ou plusieurs types d'événements spécifiques. Par exemple, si vous souhaitez être informé dès que quelqu'un crée un compte utilisateur dans eDirectory, vous pouvez créer un filtre afin de rechercher uniquement les événements Créer un objet qui créent un objet Utilisateur et de les consigner.

Pour configurer le filtrage des comptes, cliquez sur le lien Événements de gestion de compte, sélectionnez la classe, puis cliquez sur OK pour quitter l'application.

Notez que pour les événements de gestion de compte, vous pouvez configurer le filtrage sur des classes d'objet uniquement.

Pour configurer des filtres pour les événements qui créent un objet Utilisateur et consigner ces événements :

  1. Dans iManager, accédez à Rôles et tâches > Audit > Configuration de l'audit.

  2. Sélectionnez le serveur NCP à surveiller, puis cliquez sur OK.

    Par défaut, l'onglet Événements XDAS est sélectionné.

  3. Cliquez sur Événements de gestion de compte.

    La fenêtre Filtrage de la configuration des comptes XDAS s'affiche.

  4. Dans la liste Classes disponibles, sélectionnez Utilisateur, cliquez sur la flèche droite pour déplacer Utilisateur dans la liste Classes sélectionnées, puis cliquez sur OK.

    Le filtre pour l'événement Créer un compte est configuré.

Une fois ce filtre configuré, XDASv2 recherche et consigne tous les événements de création d'utilisateur générés.

Filtrage des rôles XDASv2

Cliquez sur le lien Événements de gestion de rôle lien pour configurer le filtrage des rôles XDASv2. Vous pouvez configurer des rôles XDASv2 pour les objets pour lesquels vous souhaiter collecter des événements XDASv2. Vous pouvez sélectionner des classes d'objet et leur définir des attributs.

Pour configurer le filtrage des rôles XDAS :

  1. Dans iManager, accédez à Rôles et tâches > Audit > Configuration de l'audit.

  2. Sélectionnez le serveur NCP à surveiller, puis cliquez sur OK.

    Par défaut, l'onglet Événements XDAS est sélectionné.

  3. Cliquez sur Événements de gestion de rôle.

    La fenêtre Filtrage de la configuration des rôles XDAS s'affiche.

  4. Dans la liste Classes disponibles, sélectionnez les classes d'objet pour lesquelles vous souhaitez collecter des événements, puis cliquez sur la flèche droite pour les déplacer dans la liste Classes sélectionnées.

  5. Dans la liste Attribut(s) disponible(s), sélectionnez le nombre souhaité d'attributs pour les classes d'objet que vous avez sélectionnées. Sélectionnez les attributs, puis cliquez sur la flèche pour les ajouter à la liste des attributs sélectionné.

    REMARQUE :si vous sélectionnez une classe d'objet, tous les événements de rôle pour l'ensemble des attributs de cette classe d'objet sont sélectionnés, même si vous n'avez sélectionné que quelques attributs. Si vous souhaitez uniquement spécifier certains attributs, vous ne devez sélectionner que ces attributs et non une classe d'objet. Le cas échéant, tous les événements de rôle pour les attributs sélectionnés sur toutes les classes d'objet seront consignés.

  6. Cliquez sur OK.

Une fois ce filtre configuré, XDASv2 recherche et consigne tous les événements générés pour les attributs.

Schéma XDASv2

Le schéma XDAS est défini comme suit :

Schéma XDASv2 JSON

{
    "id":"XDASv2",
    "title":"XDAS Version 2 JSON Schema",
    "description":"A JSON representation of an XDASv2 event record.",
    "type":"objectr",
    "properties":{
      "Source":{
        "description":"The original source of the event, if applicable.",
        "type":"string",
        "optional":true
      },
      "Observer":{
        "description":"The recorder (ie., the XDASv2 service) of the event.",
        "type":"object",
        "optional":false,
        "properties":{
          "Account":{"$ref":"account"},
          "Entity":{"$ref":"entity"}
        }
      },
      "Initiator":{
        "description":"The authenticated entity or access token that causes an event.",
        "type":"object",
        "optional":false,
        "properties":{
          "Account":{"$ref":"account","optional":true},
          "Entity":{"$ref":"entity"},
          "Assertions":{
            "description":"Attribute/value assertions about an identity.",
            "type":"object",
            "optional":true
          }
        }
      },
      "Target":{
        "description":"The target object, account, data item, etc of the event.",
        "type":"object",
        "optional":true,
        "properties":{
          "Account":{"$ref":"account"},
          "Entity":{"$ref":"entity"},
          "Data":{                           
            "description":"A set attribute/value pairs describing the target object.",        * 
            "type":"object",        
            "optional":true
          }  
        }
      },
      "Action":{
        "description":"The action describes the event in a uniform manner.",
        "type":"object",
        "optional":false,
        "properties":{
          "Event":{
            "description":"The event identifier in standard XDASv2 taxonomy.",
            "type":"object",
            "optional":false,
            "properties":{
              "Id":{
                "description":"The XDASv2 taxonomy event identifier.",
                "type":"string",
                "optional":false,
                "pattern":"/^[0-9]+(\.[0-9]+)*$/" 
              },
              "Name":{
                "description":"A short descriptive name for the specific event.", eg. a new replica is added 
                "type":"string",
                "optional":true
              },
      "CorrelationID":{
          "description":"Correlation ID, source#uniqueID#connID",
                 "type":"string",
                 "optional":true
      }
     },
     "SubEvent":{
      "type":object
      "description": "Describes the actual domain specific event that has occured.",
      "optional":true,
      "properties":{
        "Name"":{
                    "description":"A short descriptive name for this event.",
                    "type":"string",
                    "optional":true
                  },
      }
            }  
          }
          "Log":{
            "description":"Client-specified logging attributes.",
            "optional":true,
            "properties":{
              "Severity":{"type":"integer", "optional":true},
              "Priority":{"type":"integer", "optional":true},
              "Facility":{"type":"integer", "optional":true}
            }
          }
          "Outcome":{
            "description":"The XDASv2 taxonomy outcome identifier.",
            "type":"string",
            "optional":false,
            "pattern":"/^[0-9]+(\.[0-9]+)*$/"
          }
          "Time":{
            "description":"The time the event occurred.",
            "type":"object",
            "optional":false,
            "properties":{
              "Offset":{
                "description":"Seconds since Jan 1, 1970.",
                "type":"integer"
              },
              "Sequence":{
                "description":"Milliseconds since last integral second.",
                "type":"integer",
                "optional":true
              },
              "Tolerance":{
                "description":"A tolerance value in milliseconds.",
                "type":"integer",
                "optional":true
              },
              "Certainty":{
                "description":"Percentage certainty of tolerance.",
                "type":"integer",
                "optional":true,
                "minimum":0,
                "maximum":100,
                "default":100,
              },
              "Source":{
                "description":"The time source (eg., ntp://time.nist.gov).",
                "type":"string",
                "optional":true
              },
              "Zone":{
                "description":"A valid timezone symbol (eg., MST/MDT).",
                "type":"string",
                "optional":true
              }
            }
      "ExtendedOutcome":{
            "description":"The XDASv2 taxonomy outcome identifier.",
            "type":"string",
            "optional":false,
            "pattern":"/^[0-9]+(\.[0-9]+)*$/"
           }
        }
      }
    }
  },
  {
    "id":"account",
    "description":"A representation of an XDAS account.",
    "type":"object",
    "properties":{
      "Domain":{
        "description":"A (URL) reference to the authority managing this account.",    /* lets take it as the partition?
        "type":"string"
      },
      "Name":{
        "description":"A human-readable account name.",        - DN
        "type":"string",
        "optional":true
      },
      "Id":{
        "description":"A machine-readable unique account identifier value.",  - EntryID
        "type":"integer"
      }
    }
  },
  {
    "id":"entity",                    - Server details for Target, client address details for the initiator
    "description":"A representation of an addressable entity.",
    "type":"object",
    "properties":{
      "SysAddr":{"type":"string","optional":true},  
      "SysName":{"type":"string","optional":true},
      "SvcName":{"type":"string","optional":true},
      "SvcComp":{"type":"string","optional":true},
    }
  }

Définitions des champs XDAS

Les champs inclus dans le schéma sont les champs XDASv2 définis spécifiquement pour les événements d'audit. Certains ou l'ensemble de ces champs peuvent également être pertinents pour d'autres types d'événement, mais des informations de ce type sont requises pour les services d'audit. Le format d'enregistrement XDASv2 JSON est un format ouvert. Cela signifie que d'autres champs peuvent être ajoutés à n'importe quel endroit de l'enregistrement, du moment qu'ils ne sont pas en conflit avec les valeurs de champ définies pour l'audit par la norme XDASv2. Autrement dit, en présence d'un certain type de données de corrélation, telles qu'un identificateur de workflow ou un identificateur de session, qui peuvent servir de points de données de corrélation entre des événements au sein d'un workflow ou d'une session cliente, vous pouvez ajouter ces champs. Choisissez simplement un nom non conflictuel pour votre champ.

Tableau 23-3 Définitions des champs XDAS

Champ XDAS

Description

Source (facultatif)

La source d'un événement identifie le service d'événements d'un autre système à partir duquel cet événement a été initialement défini et converti en événement XDAS. Dans la mesure où de nombreux événements sont générés directement par les clients XDAS, le champ Source est facultatif.

Initiator

L'initiateur d'un événement est l'entité authentifiée qui a initialement déclenché la création de l'événement. Notez qu'un initiateur ne doit pas être identifié. Si l'entité ne peut pas être identifiée (il se peut qu'une entité tente de se connecter, entraînant la génération d'un événement de connexion par un observateur), il convient de spécifier autant d'informations que possible à propos de l'origine de l'événement. REMARQUE : dans le cas particulier d'un événement de connexion, l'identité authentifiée de l'initiateur reste inconnue jusqu'à ce que la tentative de connexion ait réussi. C'est pourquoi un événement d'échec de connexion ne permet pas d'identifier l'identité du compte cible comme l'identité de l'initiateur.

Un initiateur est défini par un compte et une entité (décrits ci-dessous), ainsi que par un ensemble d'assertions facultatif. Ces assertions décrivent les attributs de l'identité de l'initiateur sous la forme d'un ensemble de paires nom/valeur. Certains initiateurs ne sont pas associés à un compte spécifique, mais seulement à un ensemble d'assertions (SAML2, par exemple) qui décrivent les droits de l'intervenant. Aucun schéma n'est défini pour ces assertions, car elles varient d'une classe à l'autre et parfois même d'un objet à l'autre.

Action

L'action correspond à l'événement enregistré. Ce champ indique l'identificateur d'événement XDASv2 ainsi qu'un code de résultat (réussite ou classe d'échec), et affiche le plus précisément possible l'heure à laquelle l'événement s'est produit.

Event

Le champ Event est le champ clé pour les événements XDAS. Il encapsule un identificateur taxonomique ainsi qu'un court descriptif pour favoriser la lisibilité.

Id

Le code Id représente l'identificateur d'événement, défini par la taxinomie standard des événements XDASv2, et les extensions définies par le produit Novell CSS.

Name

Le nom de l'événement est une représentation lisible de l'identificateur d'événement. Le nom de l'événement est facultatif, mais recommandé pour une meilleure lisibilité.

Data

Les données d'événement fournissent des informations descriptives supplémentaires à propos de l'événement.

Log

Le champ Log contient des valeurs de niveau de consignation de type syslog standard, exprimées sous la forme d'identificateurs numériques pour les éléments Severity et Facility. Le champ Log et tous les sous-champs qu'il contient sont facultatifs. Ces valeurs ne doivent être utilisées qu'en cas d'absolue nécessité, car elles représentent généralement l'avis personnel de l'instrumenteur. Il est préférable de laisser les ingénieurs ou les logiciels d'analyse déterminer ces valeurs une fois les données d'événement collectées.

Outcome

Pour plus d'informations sur les codes de résultat, reportez-vous à la section Codes de résultat.

Time

L'heure de l'événement est l'heure enregistrée par l'observateur au moment où l'événement a été transmis au service d'événements. Les valeurs d'heure sont collectées par la bibliothèque auxiliaire du client XDAS. Il est donc inutile de s'inquiéter à propos des valeurs stockées dans ce champ, dans la mesure où la bibliothèque auxiliaire tente d'être aussi précise que possible lorsqu'elle génère les informations d'heure.

Offset

Le champ Offset (Décalage) contient une valeur qui représente le nombre de secondes écoulées depuis le 1er janvier 1970 à minuit, autrement dit l'epoch Linux.

Sequence

Le champ Sequence (Séquence) contient une valeur numérique unique qui distingue cet événement d'un autre événement qui a pu être enregistré au cours de la même seconde. Globalement, cette valeur doit être considérée comme une valeur numérique à croissance monolithique qui commence à zéro et continue jusqu'à ce qu'elle atteigne la limite de la seconde suivante, puis recommence à zéro.

Tolerance

Ce champ contient une valeur comprise entre 0 et 100, qui indique la tolérance de l'horloge utilisée pour enregistrer l'heure en termes de décalage. La valeur 0 indique que l'horloge est très précise. La valeur 100 indique qu'il ne faut pas se fier à l'horloge.

Certainty

Ce champ contient une valeur comprise entre 0 et 100, qui correspond au pourcentage de fiabilité de la valeur du champ Tolerance. La valeur 0 signifie qu'il n'existe aucune certitude quant à la tolérance et qu'il ne faut donc en aucun cas s'y fier. La valeur 100 indique que la valeur de tolérance est très précise.

Source

Ce champ spécifie la source de temps du système de l'observateur. Il peut s'agir de l'URL d'un serveur de temps ou simplement d'une source de temps locale, comme une horloge matérielle.

Zone

Ce champ contient la nouvelle chaîne de fuseau horaire représentant le fuseau horaire de cette horloge.

Target (facultatif)

La cible d'un événement est la ressource protégée ou le compte sur lequel l'initiateur tente d'agir, entraînant de ce fait la génération d'un événement. Une cible est définie par un compte et une entité (décrits ci-dessous), ainsi que par un objet Données facultatif et non spécifié. L'objet Données est un ensemble de paires nom/valeur qui décrivent les attributs spécifiques de la classe de l'intervenant. Le schéma ne définit pas les champs réels, car les différentes classes comportent un ensemble unique d'attributs de données (le cas échéant).

Observer

L'observateur d'un événement est l'identité authentifiée d'une entité (service) qui surveille le système et génère des événements en fonction des actions de l'initiateur. Un observateur est défini par un compte et une entité (décrits ci-dessous).

Referenced Classes

Les champs Observer (Observateur), Initiator (Initiateur) et Target (Cible) contiennent des références aux classes de compte et d'entité définies séparément dans le schéma. Ces autres classes identifient les attributs clés des trois principaux intervenants au sein d'un événement d'audit.

Account Class

La classe de compte représente l'identité de l'intervenant. Cette identité est relative à un domaine d'authentification. Un nom et un ID de compte sont fournis, mais seul l'ID est vraiment nécessaire. Le nom est juste spécifié à des fins de lisibilité.

Account Domain

Le domaine de compte définit l'autorité d'authentification de l'intervenant. Sans autorité d'authentification, les identificateurs de compte sont peu pertinents.

Account Name

Ce champ facultatif favorise la lisibilité.

Account Id

Ce champ contient l'identificateur unique du compte au sein du domaine d'authentification.

Entity Class

Ce champ décrit l'emplacement de l'intervenant. Cet emplacement est défini par une adresse (réseau IP) et un nom (d'hôte/de domaine) de noeud d'extrémité d'accès système. D'autres champs sont disponibles pour décrire les noms de service et de composant au sein du logiciel qui gère les noeuds d'extrémité susmentionnés.

Entity SysAddr

Adresse IP décrivant le noeud d'extrémité d'accès de l'intervenant logiciel. Cette adresse est affichée au format adresse IP:port. Par exemple :

  • IPv4 : 194.99.188.103:34564

  • IPv6 : [2015::15]:43333

Notez que l'adresse IP d'événement interne se présente comme suit : 0.0.0.0:0.

Entity SysName

Nom de domaine ou d'hôte décrivant le noeud d'extrémité d'accès de l'intervenant logiciel.

Entity SvcName

Nom apportant un complément d'information à propos du service qui gère le noeud d'extrémité susmentionné.

Entity SvcComp

Nom de composant de service décrivant le composant au sein du service susmentionné.

Codes de résultat

Le code de résultat est une valeur numérique hiérarchique comparable au code d'événement. Il indique si l'opération a réussi ou échoué et pour quelle raison. La hiérarchie de réussite est encapsulée par le sous-arc 0.x. Les classes d'échec sont représentées par la hiérarchie 1.x. Les codes de refus sont représentés par la hiérarchie 2.x.

Exemple d'événement

Vous trouverez ci-dessous un exemple d'événement :

Sep 12 14:51:26 eDirectory : INFO {"Source" : "eDirectory#DS","Observer" : {"Account" : {"Domain" : "DEMOTREE","Name" : "CN=demo-host,O=org"},"Entity" : {"SysAddr" : "192.168.0.15","SysName" : "demo-host"}},"Initiator" : {"Account" : {"Domain" : "DEMOTREE"},"Entity" : {"SysAddr" : "192.168.0.10:18408"}},"Target" : {"Data" : {"Name" : "CN=demo-host,O=org"}},"Action" : {"Event" : {"Id" : "0.0.2.2","Name" : "QUERY_DATA_ITEM_ATTRIBUTE","CorrelationID" : "eDirectory#5#","SubEvent" : "DSE_DSA_READ"},"Time" : {"Offset" : 1378977686},"Log" : {"Severity" : 7},"Outcome" : "0","ExtendedOutcome" : "0"}}

Événements XDASv2

Pour plus d'informations sur les événements XDASv2, reportez-vous à l'Section H.0, Assignation d'événements eDirectory à des événements XDAS.

Dépannage de XDASv2

Pour plus d'informations sur la résolution des problèmes d'installation et de configuration, reportez-vous à la Section I.1, Dépannage de XDASv2.