Terminologie et concept 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.

Tableau 28-1 Termes liés à l'audit Oracle Solaris

Événements d'audit

Les actions système ayant trait à la sécurité peuvent être auditées. Ces actions auditables sont qualifiées d'événements d'audit. Les événements d'audit sont répertoriés dans le fichier /etc/security/audit_event . Chaque événement d'audit est défini dans le fichier par un numéro, un nom symbolique, une brève description et l'ensemble des classes d'audit auxquelles il appartient. Pour plus d'informations sur le fichier audit_event, reportez-vous à la page de manuel audit_event(4).

Par exemple, l'entrée suivante définit l'événement d'audit pour l'appel système exec() :

7:AUE_EXEC:exec(2):ps,ex

Lorsque vous présélectionnez la classe d'audit ps ou ex pour l'audit, les appels système exec() sont enregistrés dans la piste d'audit.

L'audit Oracle Solaris 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 de la manière suivante :

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

• Évé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 dotés de processus associés, tels qu'un échec de connexion, sont des événements synchrones.

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

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

Lorsque la classe à laquelle un événement d'audit appartient est présélectionnée pour l'audit, l'événement est enregistré dans la piste d'audit. Par exemple, lorsque vous présélectionnez les classes d'audit ps et na pour l'audit, les appels système exec() et les actions d'initialisation du système, entre autres événements, sont enregistrés dans la piste d'audit.

Outre les événements d'audit définis par le service d'audit Oracle Solaris, 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.

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 à auditer, vous spécifiez que tous les événements de cette classe doivent être enregistrés dans la piste d'audit. 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. Une fois le service d'audit en cours d'exécution, vous pouvez ajouter de façon dynamique des classes d'audit à la présélection, ou en supprimer.

• Présélection système : spécifie des valeurs par défaut à l'échelle du système pour l'audit des lignes flags, naflags et plugin du fichier audit_control. Le fichier audit_control est décrit à la section Fichier audit_control. Reportez-vous également à la page de manuel audit_control(4).

• Présélection utilisateur : spécifie des ajouts aux valeurs par défaut du contrôle système pour des utilisateurs individuels dans la base de données audit_user.

  Le masque de présélection d'audit détermine les classes d'événements auditées pour un utilisateur. Le masque de présélection d'audit de l'utilisateur est une combinaison de valeurs système par défaut et de classes d'audit spécifiées pour l'utilisateur. Pour plus d'informations, reportez-vous à la section Caractéristiques de l'audit des processus.

  La base de données audit_user peut être gérée localement ou par un service de nommage. La console de gestion Solaris fournit l'interface graphique pour l'administration de la base de données. Pour plus d'informations, reportez-vous à la page de manuel audit_user(4).

• Présélection dynamique : spécifie des classes d'audit en tant qu'arguments à la commande auditconfig pour ajouter ou supprimer ces classes d'audit d'un processus ou d'une session. Pour plus d'informations, reportez-vous à la page de manuel auditconfig(1M).

Une commande de postsélection, auditreduce, vous permet de sélectionner des enregistrements parmi les enregistrements d'audit présélectionnés. Pour plus d'informations, reportez-vous à la section Examen de la piste d'audit et à la page de manuel auditreduce(1M).

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 ps et na s'affichent dans le fichier audit_class comme suit :

0x00100000:ps:process start/stop
0x00000400:na:non-attribute

Il existe 32 classes d'audit possibles. Les classes comprennent les deux classes globales : all et no. Les classes d'audit sont décrites à la page de manuel audit_class(4).

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 Modification de l'appartenance à une classe d'un événement d'audit.

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,81,2,login - local,,2003-10-13 11:23:31.050 -07:00
subject,root,root,other,root,other,378,378,0 0 example_system
text,successful login
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. Ensemble, les quatre jetons d'audit comprennent l'enregistrement d'audit login.

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 des modules plug-in d'audit pour gérer les enregistrements placés par votre présélection dans la file d'attente d'audit. Les plug-ins sont des entrées du fichier audit_control.

• Plug-in audit_binfile.so : gère la distribution de la file d'attente d'audit aux fichiers d'audit binaires. Dans le fichier audit_control, si aucun plug-in n'est spécifié et l'entrée dir a une valeur, alors le démon d'audit utilise ce plug-in.

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

La syntaxe du fichier audit_control est décrite à la page de manuel audit_control(4). Pour consulter des exemples, reportez-vous aux tâches dans la section Configuration des fichiers d'audit (liste des tâches) .

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

Journaux d'audit

Les enregistrements d'audit sont collectés dans des journaux d'audit. L'audit Oracle Solaris fournit deux modes de sortie pour les journaux 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.

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

Oct 13  11:24:11 example_system auditd: [ID 6472 audit.notice] \
        login - login ok session 378 by root as root:other

Un site peut stocker des enregistrements d'audit dans les deux formats. Vous pouvez configurer les systèmes de votre site afin d'utiliser le mode binaire, le mode syslog ou les deux modes. Le tableau suivant compare les enregistrements d'audit binaires et les enregistrements syslog.

Tableau 28-2 Comparaison d'enregistrements d'audit binaires aux enregistrements d'audit 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 critères communs du profil de protection Accès contrôlé (CAPP). Les enregistrements sont écrits 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 GMT dans les journaux binaires permet une comparaison exacte lorsque des systèmes d'une piste d'audit sont répartis entre 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.

En revanche, les enregistrements syslog garantissent 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 baser sur l'horodatage pour construire une piste d'audit pour plusieurs systèmes.

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

• la page de manuel audit_syslog(5)

• la page de manuel audit.log(4)

• Configuration des journaux d'audit syslog

Stockage de la piste d'audit

Un répertoire d'audit contient des fichiers d'audit au format binaire. L'installation standard utilise de nombreux répertoires d'audit. Le contenu de tous les répertoires d'audit constitue la piste d'audit. Les enregistrements d'audit sont stockés dans des répertoires d'audit selon l'ordre suivant :

• Répertoire d'audit principal : répertoire dans lequel les fichiers d'audit d'un système sont placés dans des conditions normales d'utilisation.

• Répertoire d'audit secondaire : répertoire dans lequel les fichiers d'audit d'un système sont placés si le répertoire d'audit principal est plein ou pas disponible.

• Répertoire de dernier recours : répertoire d'audit local utilisé si le répertoire d'audit principal et tous les répertoires d'audit secondaires ne sont pas disponibles.

Les répertoires sont spécifiés dans le fichier audit_control. Un répertoire n'est pas utilisé tant qu'un répertoire occupant une position supérieure dans la liste n'est pas plein. Pour obtenir un fichier audit_control annoté avec une liste des entrées de répertoire, reportez-vous à l'Exemple 30-3.

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 root d'audit par défaut est /etc/security/audit. Ce répertoire est symboliquement lié à /var/audit. Les fichiers d'audit se trouvant dans les répertoires nommés /var/audit/ hostname/files sont facilement localisés par la commande auditreduce. Pour plus d'informations, reportez-vous à la section Commande auditreduce.

Examen de la piste d'audit

Le service d'audit fournit des commandes pour combiner et réduire 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.