Terminologie et concepts de l'audit

Les termes suivants sont utilisés pour décrire le service d'audit. Certaines définitions incluent des pointeurs vers des descriptions plus complètes.

classe d'audit

Groupe d'événements d'audit. Les classes d'audit permettent de sélectionner un groupe d'événements à auditer.

Pour plus d'informations, reportez-vous à la section Classes d'audit et présélection et aux pages de manuel audit_flags(5), audit_class(4) et audit_event(4).

système de fichiers d'audit

Référentiel de fichiers d'audit au format binaire.

Pour plus d'informations, reportez-vous à la section Journaux d'audit et à la page de manuel audit.log(4).

événement d'audit

Action du système ayant trait à la sécurité et pouvant faire l'objet d'un audit. Pour faciliter la sélection, les événements sont regroupés en classes d'audit.

Pour plus d'informations, reportez-vous à la section Evénements d'audit et à la page de manuel audit_event(4).

indicateur d'audit

Classe d'audit fournie comme argument d'une commande ou d'un mot-clé. Un indicateur peut être précédé d'un signe plus ou moins pour indiquer que la classe fait l'objet d'un audit portant respectivement sur la réussite (+) ou l'échec (-). Un caret (^) précédant les symboles plus ou moins indique qu'une réussite ne doit pas faire l'objet d'un audit (^+) ou qu'un échec ne doit pas faire l'objet d'un audit (^-).

Pour plus d'informations, reportez-vous à la page de manuel audit_flags(5) et à la section Syntaxe de classe d'audit.

plug-in d'audit

Module transférant les enregistrements d'audit placés dans la file d'attente vers un emplacement spécifié. Le plug-in audit_binfile crée des fichiers d'audit binaires. Les fichiers binaires constituent la piste d'audit, qui est stockée sur les systèmes de fichiers d'audit. Le plug-in audit_remote envoie les enregistrements d'audit binaires à un référentiel distant. Le plug-in audit_syslog récapitule les enregistrements d'audit sélectionnés dans les journaux syslog.

Pour plus d'informations, reportez-vous à la section Modules plug-in d'audit et aux pages de manuel de module, audit_binfile(5), audit_remote(5) et audit_syslog(5).

stratégie d'audit

Ensemble d'options d'audit que vous pouvez activer ou désactiver sur votre site. Ces options permettent notamment d'indiquer si certains types de données d'audit doivent être enregistrés ou pas. Elles permettent aussi de préciser si les actions auditables doivent être suspendues ou pas lorsque la file d'attente d'audit est saturée.

Pour plus d'informations, reportez-vous à la section Assimilation des concepts de stratégie d'audit et à la page de manuel auditconfig(1M).

enregistrement d'audit

Données d'audit recueillies dans la file d'attente d'audit. Un enregistrement d'audit décrit un événement d'audit unique. Chaque enregistrement d'audit est constitué de jetons d'audit.

Pour plus d'informations, reportez-vous à la section Enregistrements d'audit et jetons d'audit et à la page de manuel audit.log(4).

jeton d'audit

Champ d'un enregistrement ou événement d'audit. Chaque jeton d'audit décrit un attribut d'un événement d'audit, tel qu'un utilisateur, un programme ou un autre objet.

Pour plus d'informations, reportez-vous à la section Formats de jeton d'audit et à la page de manuel audit.log(4).

piste d'audit

Ensemble composé d'un ou de plusieurs fichiers d'audit, stockant les données d'audit de tous les systèmes soumis à l'audit qui exécutent le plug-in par défaut audit_binfile.

Pour plus d'informations, reportez-vous à la section Piste d'audit.

postsélection

Sélection des événements d'audit à examiner dans la piste d'audit. Le plug-in actif par défaut audit_binfile crée la piste d'audit. Un outil de postsélection, la commande auditreduce, sélectionne les enregistrements dans la piste d'audit.

Pour plus d'informations, reportez-vous aux pages de manuel auditreduce(1M) and praudit(1M).

présélection

Sélection des classes d'audit à surveiller. Les événements d'audit des classes d'audit présélectionnées sont recueillis dans la file d'attente d'audit. Les classes d'audit non présélectionnées ne sont pas soumises à l'audit. Les événements correspondants n'apparaissent donc pas dans la file d'attente.

Pour plus d'informations, reportez-vous à la section Classes d'audit et présélection et aux pages de manuel audit_flags(5) et auditconfig(1M).

objet public

Fichier appartenant à l'utilisateur root et lisible par tout le monde. Par exemple, les fichiers des répertoires /etc et /usr/bin sont des objets publics. Les objets publics ne font pas l'objet d'un audit pour les événements en lecture seule. Par exemple, même si la classe d'audit file_read (fr) est présélectionnée, la lecture des objets publics n'est pas auditée. Vous pouvez écraser la valeur par défaut en modifiant l'option de stratégie d'audit public.

Evénements d'audit

Actions système pouvant être auditées. Les événements d'audit sont répertoriés dans le fichier /etc/security/audit_event. Chaque événement d'audit est connecté à un appel système ou une commande utilisateur et est affecté à une ou plusieurs classes d'audit. Pour obtenir une description du format du fichier audit_event, reportez-vous à la page de manuel audit_event(4).

Par exemple, l'événement d'audit AUE_EXECVE soumet à l'audit l'appel système execve(). La commande auditrecord -e execve affiche cette entrée :

execve
  system call execve               See execve(2)
  event ID    23                   AUE_EXECVE
  class       ps,ex                (0x0000000040100000)
      header
      path
      [attribute]                  omitted on error
      [exec_arguments]             output if argv policy is set
      [exec_environment]           output if arge policy is set
      subject
      [use_of_privilege]
      return

Lorsque vous présélectionnez la classe d'audit ps ou ex, chaque appel système execve() est enregistré dans la file d'attente de l'audit.

L'audit gère les événements attribuables et non attribuables. La stratégie d'audit répartit les événements en événements synchrones et asynchrones, comme suit :

• Evénements attribuables : événements pouvant être attribués à un utilisateur. L'appel système execve() peut être attribué à un utilisateur, de sorte qu'il est considéré comme un événement attribuable. Tous les événements attribuables sont des événements synchrones.

• Evénements non attribuables : événements se produisant au niveau d'interruption du noyau ou avant l'authentification d'un utilisateur. La classe d'audit na gère les événements d'audit non attribuables. Par exemple, l'initialisation du système est un événement non attribuable. La plupart des événements non attribuables sont des événements asynchrones. Cependant, les événements non attribuables auxquels sont associés des processus, tels qu'un échec de connexion, sont des événements synchrones.

• Evénements synchrones : événements associés à un processus dans le système. Les événements synchrones constituent la majorité des événements système.

• Evénements asynchrones : événements associés à aucun processus, de sorte qu'aucun processus ne peut être bloqué puis réactivé ultérieurement. L'initialisation système initiale et les événements d'entrée et de sortie PROM sont des exemples d'événements asynchrones.

Outre les événements d'audit définis par le service d'audit, des événements d'audit peuvent également être générés par des applications tierces. Les numéros d'événements d'audit compris entre 32768 et 65535 sont disponibles pour les applications tierces. Les fournisseurs doivent contacter leur représentant Oracle Solaris pour réserver des numéros d'événements et obtenir l'accès aux interfaces d'audit.

Classes d'audit et présélection

Chaque événement d'audit appartient à une ou plusieurs classes d'audit. Les classes d'audit sont des conteneurs pratiques pour les grands nombres d'événements d'audit. Lorsque vous présélectionnez une classe pour la soumettre à un audit, tous les événements de cette classe sont enregistrés dans la file d'attente de l'audit. Par exemple, lorsque vous présélectionnez la classe d'audit ps, les appels système execve(), fork() et autres sont enregistrés.

Vous pouvez effectuer une présélection pour des événements sur un système et pour des événements initiés par un utilisateur particulier.

• Présélection à l'échelle du système : spécifiez les paramètres d'audit par défaut du système à l'aide des options -setflags et -setnaflags de la commande auditconfig.

  ---

  Remarque - Si la stratégie perzone est définie, les classes d'audit par défaut peuvent être spécifiées dans chaque zone. Pour l'audit perzone, les paramètres par défaut sont à l'échelle d'une zone, et non à l'échelle du système.

  ---

• Présélection spécifique à l'utilisateur : spécifiez les différences par rapport aux paramètres d'audit par défaut du système en configurant les indicateurs d'audit spécifiques à l'utilisateur concerné. Les commandes useradd, roleadd, usermod et rolemod placent l'attribut de sécurité audit_flags dans la base de données user_attr. La commande profiles place les indicateurs d'audit pour les profils de droits dans la base de données prof_attr.

  Le masque de présélection d'audit détermine les classes d'événements auditées pour un utilisateur. Pour obtenir une description du masque de présélection utilisateur, reportez-vous à la section Caractéristiques de l'audit de processus. Pour connaître quels indicateurs d'audit configurés sont utilisés, reportez-vous à la section Ordre de recherche pour les attributs de sécurité affectés.

Les classes d'audit sont définies dans le fichier /etc/security/audit_class. Chaque entrée contient le masque d'audit pour la classe, le nom de la classe et un nom descriptif de la classe. Par exemple, les définitions de classe lo et ps s'affichent dans le fichier audit_class comme suit :

0x0000000000001000:lo:login or logout
0x0000000000100000:ps:process start/stop

Les classes d'audit comprennent les deux classes globales : all et no. Les classes d'audit sont décrites à la page de manuel audit_class(4). Pour obtenir la liste des classes, consultez le fichier /etc/security/audit_class.

Le mappage entre les événements d'audit et les classes peut être configuré. Vous pouvez supprimer des événements à partir d'une classe, ajouter des événements à une classe et créer une nouvelle classe destinée à contenir des événements sélectionnés. Pour plus d'informations sur cette procédure, reportez-vous à la section Procédure de modification de l'appartenance à une classe d'un événement d'audit. Pour afficher les événements associés à une classe, utilisez la commande auditrecord -c class.

Enregistrements d'audit et jetons d'audit

Chaque enregistrement d'audit consigne l'occurrence d'un seul événement audité. L'enregistrement inclut des informations telles que l'auteur de l'action, les fichiers affectés, l'action tentée, ainsi que l'endroit et l'heure à laquelle l'action s'est produite. L'exemple suivant montre un enregistrement d'audit login  :

header,69,2,login - local,,example_system,2010-10-10 10:10:10.020 -07:00
subject,jdoe,jdoe,staff,jdoe,staff,1210,4076076536,69 2 example_system
return,success,0

Le type d'informations enregistrées pour chaque événement d'audit est défini par un ensemble de jetons d'audit. Chaque fois qu'un enregistrement d'audit est créé pour un événement, l'enregistrement contient certains ou tous les jetons définis pour l'événement. La nature de l'événement détermine quels jetons sont enregistrés. Dans l'exemple ci-dessus, chaque ligne commence par le nom du jeton d'audit. Le contenu du jeton d'audit suit le nom du jeton. Ensemble, les jetons d'audit header, subject et return constituent l'enregistrement d'audit login - local. Pour afficher les jetons qui constituent un enregistrement d'audit, utilisez la commande auditrecord -e event.

Pour une description détaillée de la structure de chaque jeton d'audit avec un exemple de sortie praudit, reportez-vous à la section Formats de jeton d'audit. Pour une description du flux binaire des jetons d'audit, reportez-vous à la page de manuel audit.log(4).

Modules plug-in d'audit

Vous pouvez spécifier les modules enfichables (plug-ins) d'audit qui gèrent les enregistrements placés par votre présélection dans la file d'attente d'audit. Au moins un plug-in doit être actif. Par défaut, le plug-in audit_binfile est actif. Vous pouvez configurer les plug-ins à l'aide de la commande auditconfig -setplugin plug-in-name .

Le service d'audit fournit les plug-ins suivants :

• Plug-in audit_binfile : gère la distribution de la file d'attente d'audit aux fichiers d'audit binaires. Pour plus d'informations, reportez-vous à la page de manuel audit.log(4).

• Plug-in audit_remote : gère la distribution des enregistrements d'audit binaires de la file d'attente d'audit au serveur distant configuré. Le plug-in audit_remote utilise la bibliothèque libgss() pour authentifier le serveur. La transmission est protégée en matière de confidentialité et d'intégrité.

• Plug-in audit_syslog : gère la distribution des enregistrements sélectionnés de la file d'attente d'audit aux journaux syslog.

Pour configurer un plug-in, reportez-vous à la page de manuel auditconfig(1M) Pour obtenir des exemples de configuration de plug-in, reportez-vous aux tâches décrites dans la section Configuration des journaux d'audit (tâches).

Pour plus d'informations sur les plug-ins, reportez-vous aux pages de manuel audit_binfile(5), audit_remote(5) et audit_syslog(5).

Journaux d'audit

Les enregistrements d'audit sont collectés dans des journaux d'audit. Le service d'audit propose trois modes de sortie pour les enregistrements d'audit.

• Les journaux appelés fichiers d'audit stockent des enregistrements d'audit au format binaire. L'ensemble des fichiers d'audit d'un système ou d'un site constitue un enregistrement d'audit complet. L'enregistrement d'audit complet est appelé la piste d'audit. Ces journaux sont créés par le plug-in audit_binfile et peuvent être révisés par les commandes de postsélection praudit et auditreduce.

• Le plug-in audit_remote diffuse les enregistrements d'audit à un référentiel distant. Le référentiel est chargé de tenir à jour une piste d'audit et de fournir les outils de postsélection.

• L'utilitaire syslog collecte et stocke des résumés d'enregistrements d'audit au format texte. Un enregistrement syslog n'est pas complet. L'exemple suivant montre une entrée syslog pour un d'enregistrement d'audit login :

  Oct 10  10:10:20 example_system auditd: [ID 6472 audit.notice] \
          login - login ok session 4076172534 by root as root:other

Un site peut configurer l'audit de manière à recueillir les enregistrements d'audit dans tous les formats. Vous pouvez configurer les systèmes de votre site de manière à ce qu'ils utilisent le mode binaire localement, qu'ils envoient les fichiers binaires à un référentiel distant, qu'ils utilisent le mode syslog, ou qu'ils utilisent n'importe quelle combinaison de ces modes. Le tableau suivant compare les enregistrements d'audit binaires et les enregistrements syslog.

Tableau 26-1 Comparaison des enregistrements d'audit binaires, distants et syslog

Des enregistrements binaires offrent la plus grande sécurité et la meilleure couverture. La sortie binaire répond aux exigences de certifications de sécurité, telles que les exigences d'audit Critères communs.

Le plug-in audit_binfile écrit les enregistrements dans un système de fichiers protégé contre le vol. Sur un seul système, tous les enregistrements binaires sont collectés et affichés dans l'ordre. L'horodatage UTC dans les journaux binaires permet une comparaison exacte lorsque des systèmes d'une piste d'audit sont répartis sur différents fuseaux horaires. La commande praudit -x vous permet de visualiser les enregistrements dans un navigateur au format XML. Vous pouvez également utiliser des scripts pour analyser la sortie XML.

Le plug-in audit_remote écrit les enregistrements d'audit dans un référentiel distant. Le référentiel gère le stockage et la postsélection.

En revanche, les enregistrements syslog peuvent offrir une plus grande commodité et flexibilité. Par exemple, vous pouvez collecter les données syslog à partir de plusieurs sources. En outre, lorsque vous surveillez des événements audit.notice dans le fichier syslog.conf, l'utilitaire syslog consigne un résumé des enregistrements d'audit avec l'horodatage actuel. Vous pouvez utiliser les mêmes outils d'analyse et de gestion que vous avez développés pour les messages syslog à partir de plusieurs sources, y compris les stations de travail, serveurs, pare-feux et routeurs. Les enregistrements peuvent être affichés en temps réel et stockés sur un système distant.

En utilisant syslog.conf pour stocker des enregistrements d'audit à distance, vous protégez les données du journal contre toute altération ou suppression malveillante. D'autre part, lorsque les enregistrements d'audit sont stockés à distance, ceux-ci sont susceptibles de faire l'objet d'attaques réseau, telles que le déni de service et l'usurpation d'adresses source. En outre, UDP peut couper des paquets ou les distribuer dans le désordre. Le nombre limite de caractères pour les entrées syslog est de 1024, de sorte que certains enregistrements d'audit peuvent être tronqués dans le journal. Sur un système, tous les enregistrements d'audit ne sont pas collectés. Les enregistrements peuvent ne pas s'afficher dans l'ordre. Dans la mesure où chaque enregistrement d'audit est indiqué avec la date et l'heure du système local, vous ne pouvez pas vous fier à l'horodatage pour créer une piste d'audit pour plusieurs systèmes.

Pour plus d'informations sur les plug-ins et les journaux d'audit, reportez-vous à :

• La page de manuel audit_binfile(5)

• La page de manuel audit_syslog(5)

• La page de manuel audit.log(4)

• Procédure d'affectation de l'espace d'audit pour la piste d'audit

• Procédure de configuration des journaux d'audit syslog

Stockage et gestion de la piste d'audit

Lorsque le plug-in audit_binfile est actif, un système de fichiers d'audit détient les fichiers d'audit au format binaire. L'installation standard utilise le système de fichiers /var/audit et peut utiliser des systèmes de fichiers supplémentaires. Le contenu de tous les systèmes de fichiers d'audit constitue la piste d'audit. Les enregistrements d'audit sont stockés dans ces systèmes de fichiers d'audit selon l'ordre suivant :

• Système de fichiers d'audit principal : système de fichiers /var/audit, système de fichiers par défaut pour les fichiers d'audit d'un système

• Systèmes de fichiers d'audit secondaires : systèmes de fichiers dans lesquels les fichiers d'audit d'un système sont placés à la discrétion de l'administrateur

Les systèmes de fichiers sont spécifiés en tant qu'arguments de l'attribut p_dir du plug-in audit_binfile. Un système de fichiers n'est pas utilisé tant qu'un système de fichiers occupant une position supérieure dans la liste n'est pas saturé. Pour obtenir un exemple de liste d'entrées de système de fichiers, reportez-vous à la section Procédure de création de systèmes de fichiers ZFS pour les fichiers d'audit.

Placer les fichiers d'audit dans le répertoire root d'audit par défaut facilite la tâche du réviseur lors de l'examen de la piste d'audit. La commande auditreduce utilise le répertoire root d'audit pour rechercher tous les fichiers de la piste d'audit. Le répertoire racine d'audit par défaut est /var/audit. L'option -M de la commande auditreduce et l'option -S peuvent être utilisées pour spécifier les fichiers d'audit à partir d'un ordinateur spécifique et un autre système de fichiers d'audit, respectivement. Pour plus d'informations, reportez-vous à la page de manuel auditreduce(1M).

Le service d'audit fournit des commandes pour combiner et filtrer les fichiers de la piste d'audit. La commande auditreduce peut fusionner des fichiers d'audit de la piste d'audit. La commande peut également filtrer les fichiers pour localiser des événements particuliers. La commande praudit lit les fichiers binaires. Les options de la commande praudit fournissent une sortie adaptée pour l'écriture de scripts et l'affichage dans le navigateur.

Garantie de la fiabilité de l'horodatage

Lorsque vous fusionnez les journaux d'audit de plusieurs systèmes, il est impératif que la date et l'heure sur ces systèmes soient exactes. De même, lorsque vous envoyez les journaux d'audit à un système distant, le système d'enregistrement et le système de référentiel doivent disposer d'horloges précises. Le protocole NTP (Network Time Protocol) assure la précision et la coordination des horloges système. Pour plus d'informations, reportez-vous au Chapitre 3, Services d’horodatage du manuel Administration d’Oracle Solaris : Services réseau et à la page de manuel xntpd(1M).

Gestion d'un référentiel distant

Lorsque le plug-in audit_remote est actif, le référentiel distant gère les enregistrements d'audit.