Planification de l'audit (tâches)

Vous voulez sélectionner avec soin les types d'activités auditées. Dans le même temps, vous voulez collecter des informations d'audit utiles. Vous devez également planifier soigneusement les utilisateurs et objets audités. Si vous utilisez le plug-in audit_binfile par défaut, les fichiers d'audit peuvent rapidement augmenter de volume et remplir l'espace disponible, de sorte que vous devez leur allouer suffisamment d'espace disque.

La liste suivante présente les principales tâches à effectuer pour planifier l'espace disque et définir les événements à enregistrer.

Planification de l'audit par zone

Si votre système comporte des zones non globales, elles peuvent être auditées simultanément avec la zone globale ou bien vous pouvez configurer, activer et désactiver le service d'audit de chaque zone non globale séparément. Par exemple, vous êtes libre de soumettre à l'audit uniquement les zones non globales, pas la zone globale.

Pour une description des compromis, reportez-vous à la section Audit sur un système à zones Oracle Solaris.

• Procédez de l'une des manières suivantes :
  • OPTION 1 : configuration d'un service d'audit pour toutes les zones.

    L'audit de toutes les zones de façon identique peut créer une piste d'audit à image unique. Une piste d'audit à image unique est créée lorsque vous utilisez le plug-in audit_binfile ou audit_remote et que toutes les zones sur un système font partie d'un même domaine d'administration. Les enregistrements d'audit peuvent ensuite être facilement comparés, car les enregistrements de chaque zone sont présélectionnés avec des paramètres identiques.

    Cette configuration traite toutes les zones comme faisant partie d'un système. La zone globale exécute l'unique service d'audit sur un système et recueille les enregistrements d'audit pour chaque zone. Vous pouvez personnaliser les fichiers audit_class et audit_event uniquement dans la zone globale, puis copier ces fichiers pour chaque zone non globale.

    1. Utilisez le même service de noms pour chaque zone.

       ---

       Remarque - Si les fichiers du service de noms sont personnalisés dans des zones non globales, et la stratégie perzone n'est pas définie, une utilisation soigneuse des outils d'audit est requise pour sélectionner des enregistrements utilisables. Un ID d'utilisateur dans une zone peut se rapporter à un autre utilisateur du même ID dans une autre zone.

       ---

    2. Activez les enregistrements d'audit, y compris le nom de la zone.

       Pour placer le nom de la zone dans le cadre de l'enregistrement d'audit, définissez la stratégie zonename dans la zone globale. La commande auditreduce peut alors sélectionner les événements d'audit par zone dans la piste d'audit. Pour un exemple, reportez-vous à la page de manuel auditreduce(1M).

    Pour planifier une piste d'audit à image unique, reportez-vous à la section Planification des personnes et objets à auditer. Commencez à la première étape. L'administrateur de la zone globale doit également réserver du stockage, comme décrit dans la section Planification de l'espace disque pour les enregistrements d'audit.

  • OPTION 2 : configuration d'un service d'audit par zone

    Sélectionnez l'option de configuration d'audit par zone si différentes zones utilisent différentes bases de données de service de noms ou si les administrateurs de zone souhaitent contrôler l'audit dans leurs zones.

    ---

    Remarque - Pour auditer les zones non globales, la stratégie perzone doit être définie, mais il n'est pas nécessaire que le service d'audit soit activé dans la zone globale. L'audit de la zone non globale est configuré, et son service d'audit est activé et désactivé séparément à partir de la zone globale.

    ---

    • Lors de la configuration de l'audit par zone, vous configurez la stratégie d'audit perzone dans la zone globale. Si une zone non globale n'a pas encore été initialisée au moment de la définition de l'audit par zone, son audit commence à son initialisation initiale. Pour définir la stratégie d'audit, reportez-vous à la section Configuration de l'audit par zone.

    • Chaque administrateur configure l'audit de la zone qu'il gère.

      Un administrateur de zone non globale peut définir toutes les options de stratégie à l'exception de perzone et ahlt.

    • Chaque administrateur de zone peut activer ou désactiver l'audit dans la zone.

    • Pour générer des enregistrements qui peuvent être retracés jusqu'à leur zone d'origine lors de la révision, définissez la stratégie d'audit zonename.

    Pour planifier l'audit par zone, reportez-vous à la section Planification des personnes et objets à auditer. Vous pouvez ignorer la première étape. Si le plug-in audit_binfile est actif, chaque administrateur de zones doit également réserver du stockage pour chaque zone, comme décrit dans la section Planification de l'espace disque pour les enregistrements d'audit.

Planification des personnes et objets à auditer

Avant de commencer

Si vous mettez en oeuvre des zones non globales, consultez la section Planification de l'audit par zone avant d'utiliser cette procédure.

1. Déterminez si vous souhaitez une piste d'audit d'image système unique.

   ---

   Remarque - Cette étape s'applique uniquement au plug-in audit_binfile.

   ---

   Des systèmes au sein d'un même domaine administratif peuvent créer une piste d'audit d'image système unique. Si vos systèmes utilisent différents services de noms, commencez par l'Étape 2. Ensuite, effectuez le reste des étapes de planification pour chaque système.

   Pour créer une piste d'audit d'image système unique pour un site, chaque système dans l'installation doit être configuré comme suit :

   • Utilisez le même service de noms pour tous les systèmes.

     Pour une interprétation correcte des enregistrements d'audit, les fichiers passwd, group et hosts doivent être cohérents.

   • Configurez un service d'audit identique sur tous les systèmes. Pour obtenir des informations sur l'affichage et la modification des paramètres du service, reportez-vous à la page de manuel auditconfig(1M).

   • Utilisez les mêmes fichiers audit_warn, audit_event et audit_class pour tous les systèmes.

2. Déterminez la stratégie d'audit.

   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 Assimilation des concepts de 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.

3. Déterminez si vous souhaitez modifier les mappages des événements aux classes.

   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.

4. Déterminez les classes d'audit à présélectionner.

   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 de 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, consultez le fichier /etc/security/audit_class.

5. Déterminez les modifications utilisateur à apporter aux présélections à l'échelle du système.

   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 les attributs de sécurité affectés.

6. Déterminez la façon de gérer les alias de messagerie audit_warn.

   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 .

7. Décidez du format et de l'emplacement de collecte des enregistrements d'audit.

   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.

8. Déterminez à quel moment avertir l'administrateur de la réduction de l'espace disque.

   ---

   Remarque - Cette étape s'applique uniquement au plug-in audit_binfile.

   ---

   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 définir un pourcentage d'espace libre minimal, reportez-vous à l'Exemple 28-17.

9. Déterminez la mesure à prendre lorsque tous les répertoires d'audit sont pleins.

   ---

   Remarque - Cette étape s'applique uniquement au plug-in audit_binfile.

   ---

   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.

   Pour une description de ces options de stratégie, reportez-vous à la section Stratégies d'audit des événements asynchrones et synchrones. Pour configurer ces options de stratégie, reportez-vous à l'Exemple 28-6.

   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.

   ---

   Remarque - La stratégie cnt ou ahlt n'est pas déclenchée si la file d'attente d'au moins un plug-in accepte des enregistrements d'audit.

   ---

Planification de l'espace disque pour les enregistrements d'audit

Le plug-in audit_binfile crée une piste d'audit. La piste d'audit requiert un espace de fichiers dédié. Cet espace doit être disponible et sécurisé. Le système utilise le système de fichiers /var/audit pour le stockage initial. Vous êtes libre de configurer d'autres systèmes de fichiers d'audit pour les fichiers d'audit. La procédure suivante décrit les problèmes à résoudre lorsque vous planifiez le stockage de la piste d'audit.

Avant de commencer

Si vous mettez en oeuvre des zones non globales, effectuez la Planification de l'audit par zone avant d'utiliser cette procédure.

Vous utilisez le plug-in audit_binfile.

1. Déterminez le niveau d'audit requis par votre site.

   Définissez les besoins de sécurité de votre disque en tenant compte de l'espace disque disponible pour la piste d'audit.

   Pour obtenir des instructions sur la manière de réduire l'espace requis tout en maintenant la sécurité du site, ainsi que sur la conception du stockage d'audit, reportez-vous aux sections Contrôle des coûts d'audit et Gestion efficace de l'audit.

   Les sections Atténuation du volume des enregistrements d'audit produits, Compression des fichiers d'audit sur un système de fichiers dédié et Exemple 28-30 décrivent les étapes à suivre.

2. Déterminez les systèmes à soumettre à l'audit et configurez leurs systèmes de fichiers d'audit.

   Créez une liste de tous les systèmes de fichiers que vous prévoyez d'utiliser. La section Stockage et gestion de la piste d'audit et la page de manuel auditreduce(1M) contiennent des instructions pour la configuration. Pour spécifier les systèmes de fichiers d'audit, reportez-vous à la section Affectation de l'espace d'audit pour la piste d'audit.

3. Synchronisez les horloges de tous les systèmes.

   Pour plus d'informations, reportez-vous à la section Garantie de la fiabilité de l'horodatage.

Préparation de la diffusion des enregistrements d'audit vers le stockage distant

Le plug-in audit_remote envoie la piste d'audit binaire à un serveur ARS dans le même format que celui utilisé par le plug-in audit_binfile pour écrire dans les fichiers d'audit locaux. Le plug-in audit_remote utilise la bibliothèque libgss pour authentifier le serveur ARS, et un mécanisme GSS-API pour assurer la confidentialité et l'intégrité de la transmission. Pour des références, reportez-vous aux sections Description du service Kerberos et Composants Kerberos.

Le seul mécanisme GSS-API actuellement pris en charge est kerberosv5. Pour plus d'informations, reportez-vous à la page de manuel mech(4).

Avant de commencer

Vous prévoyez d'utiliser le plug-in audit_remote.

1. Créez un domaine Kerberos pour vos systèmes audités.
   1. Installez le package KDC principal.

      Vous pouvez utiliser le système qui servira de serveur ARS, ou utiliser un système situé à proximité. Le serveur ARS envoie un volume considérable de trafic d'authentification au package KDC principal.

      Si les packages Kerberos sont déjà présents sur le système, la sortie est semblable à ce qui suit :

      # pkg search -l kerberos-5
      INDEX      ACTION       VALUE                  PACKAGE
      pkg.summary   set  Kerberos version 5 support  pkg:/service/security/kerberos-5@vn
      pkg.summary   set  Kerberos V5 Master KDC      pkg:/system/security/kerberos-5@vn

      La première commande vérifie si le package KDC maître Kerberos V5 a été installé. La seconde commande installe le package.

      # pkg info system/security/kerberos-5
      pkg: info: no packages matching these patterns are installed on the system.
      # pkg install pkg:/system/security/kerberos-5

      Sur le package KDC maître, vous devez utiliser les commandes kdcmgr et kadmin Kerberos pour gérer le domaine. Pour des références, reportez-vous aux pages de manuel kdcmgr(1M) et kadmin(1M).

2. Sur chaque système audité qui envoie des enregistrements d'audit au serveur ARS, installez le package KDC maître.

   # pkg install pkg:/system/security/kerberos-5

   Ce package inclut la commande kclient. Sur ces systèmes, vous devez exécuter la commande kclient pour vous connecter au package KDC. Pour des références, reportez-vous à la page de manuel kclient(1M).

3. Synchronisez les horloges avec le domaine KDC.

   Si l'écart d'horloge est trop grand entre les systèmes audités et le serveur ARS, la tentative de connexion échoue. Une fois la connexion établie, l'heure locale du serveur ARS détermine les noms des fichiers d'audit stockés, comme décrit à la section Conventions relatives aux noms de fichiers d'audit binaires.

   Pour plus d'informations sur les horloges, reportez-vous à la section Garantie de la fiabilité de l'horodatage.