Ignorer les liens de navigation | |
Quitter l'aperu | |
Administration d'Oracle Solaris : services de sécurité Oracle Solaris 11 Information Library (Français) |
Partie I Présentation de la sécurité
1. Services de sécurité (présentation)
Partie II Sécurité du système, des fichiers et des périphériques
2. Gestion de la sécurité de la machine (présentation)
3. Contrôle de l'accès aux systèmes (tâches)
4. Service d'analyse antivirus (tâches)
5. Contrôle de l'accès aux périphériques (tâches)
6. Utilisation de l'outil de génération de rapports d'audit de base (tâches)
7. Contrôle de l'accès aux fichiers (tâches)
Partie III Rôles, profils de droits et privilèges
8. Utilisation des rôles et des privilèges (présentation)
9. Utilisation du contrôle d'accès basé sur les rôles (tâches)
10. Attributs de sécurité dans Oracle Solaris (référence)
Partie IV Services cryptographiques
11. Structure cryptographique (présentation)
12. Structure cryptographique (tâches)
13. Structure de gestion des clés
Partie V Services d'authentification et communication sécurisée
14. Authentification des services réseau (tâches)
17. Utilisation de Secure Shell (tâches)
19. Introduction au service Kerberos
20. Planification du service Kerberos
21. Configuration du service Kerberos (tâches)
22. Messages d'erreur et dépannage de Kerberos
23. Administration des principaux et des stratégies Kerberos (tâches)
24. Utilisation des applications Kerberos (tâches)
25. Service Kerberos (référence)
Partie VII Audit dans Oracle Solaris
28. Gestion de l'audit (tâches)
Pages de manuel du service d'audit
Profils de droits pour l'administration de l'audit
Caractéristiques de l'audit de processus
Conventions relatives aux noms de fichiers d'audit binaires
Structure d'enregistrement d'audit
La stratégie d'audit détermine si des informations supplémentaires sont ajoutées à la piste d'audit.
Les stratégies suivantes ajoutent des jetons aux enregistrements d'audit : arge, argv, group, path, seq, trail, windata_down, windata_up et zonename. Les stratégies windata_down et windata_up sont utilisées par la fonction Trusted Extensions d'Oracle Solaris. Pour plus d'informations, reportez-vous au Chapitre 22, Audit de Trusted Extensions (présentation) du manuel Configuration et administration d’Oracle Solaris Trusted Extensions.
Les autres stratégies n'ajoutent pas de jetons. La stratégie public limite l'audit des fichiers publics. La stratégie perzone établit des files d'attente d'audit distinctes pour les zones non globales. Les stratégies ahlt et cnt déterminent ce qui se produit lorsque les enregistrements d'audit ne peuvent pas être remis. Pour plus de détails, reportez-vous à la section Stratégies d'audit des événements asynchrones et synchrones.
Les effets des différentes options de stratégie d'audit sont décrits à la section Assimilation des concepts de stratégie d'audit. Pour connaître les différentes options de stratégie d'audit, reportez-vous à la section sur l'option -setpolicy de la page de manuel auditconfig(1M). Pour obtenir la liste des options de stratégie disponibles, exécutez la commande auditconfig -lspolicy. Pour obtenir la stratégie en cours, exécutez la commande auditconfig -getpolicy.
Les stratégies ahlt et cnt déterminent ce qui se passe lorsque la file d'attente de l'audit est pleine et ne peut plus accepter d'événements.
Remarque - La stratégie cnt ou ahlt n'est pas déclenchée si la file d'attente d'au moins un plug-in peut accepter des enregistrements d'audit.
Les stratégies cnt et ahlt sont indépendantes et associées. Les combinaisons de ces stratégies ont les effets suivants :
-ahlt +cnt est la stratégie adoptée par défaut. Cette valeur par défaut permet à un événement audité d'être traité même s'il ne peut pas être consigné.
La stratégie -ahlt indique que si un enregistrement d'audit d'un événement asynchrone ne peut pas être placé dans la file d'attente d'audit du noyau, le système comptabilise les événements et poursuit le traitement. Dans la zone globale, le compteur as_dropped enregistre le nombre correspondant.
La stratégie +cnt indique que si un événement synchrone survient et ne peut pas être placé dans la file d'attente d'audit du noyau, le système comptabilise l'événement et poursuit le traitement. Le compteur as_dropped de la zone enregistre le nombre correspondant.
La configuration -ahlt +cnt est généralement utilisée sur les sites où le traitement doit se poursuivre, même si celui-ci peut entraîner une perte d'enregistrements d'audit. Les champs auditstatdrop indiquent le nombre d'enregistrements d'audit supprimés dans une zone.
La stratégie +ahlt -cnt indique que le traitement s'arrête lorsqu'un événement asynchrone ne peut pas être ajouté à la file d'attente d'audit du noyau.
La stratégie +ahlt indique que si un enregistrement d'audit d'un événement asynchrone ne peut pas être placé dans la file d'attente d'audit du noyau, toutes les opérations de traitement sont arrêtées. Le système panique. L'événement asynchrone ne sera pas dans la file d'attente de l'audit et doit être récupéré à partir de pointeurs sur la pile des appels.
La stratégie -cnt indique que, si un événement synchrone ne peut pas être placé dans la file d'attente d'audit du noyau, le thread tentant de fournir l'événement sera bloqué. Le thread est placé dans une file d'attente de mise en veille jusqu'à ce que de l'espace d'audit devienne disponible. Aucun compte n'est conservé. Des programmes peuvent sembler bloqués jusqu'à ce que de l'espace d'audit devienne disponible.
La configuration +ahlt -cnt est généralement utilisée dans les sites où un enregistrement de chaque événement d'audit est prioritaire sur la disponibilité du système. Des programmes semblent être bloqués jusqu'à ce que de l'espace d'audit devienne disponible. Le champ auditstat wblk indique à combien de reprises des threads ont été bloqués.
Toutefois, si un événement asynchrone se produit, le système va paniquer, entraînant une interruption de service. La file d'attente du noyau des événements d'audit peut être restaurée manuellement partir d'un vidage mémoire enregistré. L'événement asynchrone ne sera pas dans la file d'attente de l'audit et doit être récupéré à partir de pointeurs sur la pile des appels.
La stratégie -ahlt -cnt indique que si un événement asynchrone ne peut pas être placé dans la file d'attente d'audit du noyau, l'événement sera comptabilisé et le traitement poursuivi. Lorsqu'un événement synchrone ne peut pas être placé dans la file d'attente d'audit du noyau, le thread tentant de fournir l'événement sera bloqué. Le thread est placé dans une file d'attente de mise en veille jusqu'à ce que de l'espace d'audit devienne disponible. Aucun compte n'est conservé. Des programmes peuvent sembler bloqués jusqu'à ce que de l'espace d'audit devienne disponible.
La configuration -ahlt -cnt est généralement utilisée dans les sites où l'enregistrement de tous les événements d'audit synchrones est prioritaire sur la perte potentielle d'enregistrements d'audit asynchrones. Le champ auditstat wblk indique à combien de reprises des threads ont été bloqués.
La stratégie +ahlt +cnt indique que si un événement asynchrone ne peut pas être placé dans la file d'attente d'audit du noyau, le système panique. Si un événement asynchrone ne peut pas être placé dans la file d'attente d'audit du noyau, le système comptabilise l'événement et poursuit le traitement.