Avant de commencer
Si vous implémentez des zones non globales, consultez la section Planification de l'audit dans les zones avant d'utiliser cette procédure.
Par défaut, seule la stratégie cnt est activée.
Utilisez la commande auditconfig -lspolicy pour afficher une description des options de stratégie disponibles.
Pour connaître les effets des options de stratégie, reportez-vous à la section Principes de la stratégie d'audit.
Pour connaître l'effet de la stratégie cnt, reportez-vous à la section Stratégies d'audit des événements asynchrones et synchrones.
Pour définir la stratégie d'audit, reportez-vous à la section Modification de la stratégie d'audit.
Dans la majorité des cas, le mappage par défaut est suffisant. Cependant, si vous ajoutez de nouvelles classes, modifiez des définitions de classe ou déterminez qu'un enregistrement d'un appel système spécifique n'est pas utile, il est conseillé de modifier les mappages entre les événements et les classes.
La section Modification de l'appartenance à une classe d'un événement d'audit présente un exemple.
Le meilleur moment pour ajouter des classes d'audit ou modifier des classes par défaut est avant la connexion des utilisateurs au système.
Les classes d'audit que vous présélectionnez avec les options –setflags et – setnaflags pour la commande auditconfig s'appliquent à tous les utilisateurs et processus. Vous pouvez présélectionner une classe pour la réussite, l'échec ou les deux.
Pour obtenir la liste des classes d'audit, lisez le fichier /etc/security/audit_class.
Si vous décidez que certains utilisateurs doivent faire l'objet d'un audit différent de celui du système, vous pouvez modifier l'attribut de sécurité audit_flags pour des utilisateurs individuels ou un profil de droits. Le masque de présélection utilisateur est modifié pour les utilisateurs dont les indicateurs d'audit sont définis de manière explicite ou auxquels est affecté un profil de droits avec des indicateurs d'audit explicites.
Pour obtenir cette procédure, reportez-vous à la section Configuration des caractéristiques d'audit d'un utilisateur. Pour connaître les valeurs d'indicateur d'audit en vigueur, reportez-vous à la section Ordre de recherche pour Assigned Rights du manuel Sécurisation des utilisateurs et des processus dans Oracle Solaris 11.2 .
Le script audit_warn est exécuté chaque fois que le système d'audit détecte une situation qui requiert l'attention du service d'administration. Par défaut, le script audit_warn envoie un e-mail à un alias audit_warn et un message à la console.
Pour configurer l'alias, reportez-vous à la section Configuration de l'alias de messagerie audit_warn .
Vous disposez de trois possibilités.
Par défaut, stockez les enregistrements d'audit binaire localement. Le répertoire par défaut de stockage est /var/audit. Pour continuer à configurer le plug-in audit_binfile, reportez-vous à la section Création de systèmes de fichiers ZFS pour les fichiers d'audit.
Diffusez les enregistrements d'audit binaires vers un référentiel protégé distant à l'aide du plug-in audit_remote. Vous devez disposer d'un récepteur pour les enregistrements. Pour la configuration requise, reportez-vous à la section Gestion d'un référentiel distant. Pour obtenir cette procédure, reportez-vous à la section Envoi des fichiers d'audit à un référentiel distant.
Envoyez les résumés d'enregistrement d'audit à syslog à l'aide du plug-in audit_syslog. Pour obtenir cette procédure, reportez-vous à la section Configuration des journaux d'audit syslog.
Pour obtenir une comparaison des formats binaire et syslog, reportez-vous à la section Journaux d'audit.
Lorsque l'espace disque disponible sur un système de fichiers d'audit passe en dessous du pourcentage d'espace libre minimal, ou limite dépassable, le service d'audit bascule vers le répertoire d'audit disponible suivant. Le service envoie alors un message d'avertissement indiquant que cette limite a été dépassée.
Pour savoir comment régler un pourcentage d'espace libre minimal, voir l'Example 4–7.
Dans la configuration par défaut, le plug-in audit_binfile est actif et la stratégie –cnt est définie. Dans cette configuration, lorsque la file d'attente d'audit du noyau est saturée, le système continue à fonctionner. Le système comptabilise les enregistrements d'audit qui sont supprimés, mais n'enregistre pas les événements. Pour plus de sécurité, vous pouvez désactiver la stratégie –cnt et activer la stratégie –ahlt. La stratégie –ahlt arrête le système lorsqu'un événement asynchrone ne peut pas être placé dans la file d'attente de l'audit.
Toutefois, si la file d'attente audit_binfile est complète alors que la file d'attente d'un autre plug-in actif ne l'est pas, la file d'attente du noyau continue à envoyer des enregistrements vers le plug-in qui n'est pas complet. Lorsque la file d'attente audit_binfile peut accepter à nouveau des enregistrements, le service d'audit recommence à lui envoyer des enregistrements.
Pour une description des options de stratégie –cnt et –ahlt, reportez-vous à la section Stratégies d'audit des événements asynchrones et synchrones. Pour savoir comment configurer ces options de stratégie, voir l'Example 3–10.