Omitir V�nculos de navegaci�n | |
Salir de la Vista de impresi�n | |
![]() |
Administración de Oracle Solaris: servicios de seguridad Oracle Solaris 11 Information Library (Español) |
Parte I Descripción general de la seguridad
1. Servicios de seguridad (descripción general)
Parte II Seguridad de sistemas, archivos y dispositivos
2. Gestión de seguridad de equipos (descripción general)
3. Control de acceso a sistemas (tareas)
4. Servicio de análisis de virus (tareas)
5. Control de acceso a dispositivos (tareas)
6. Uso de la herramienta básica de creación de informes de auditoría (tareas)
7. Control de acceso a archivos (tareas)
Parte III Roles, perfiles de derechos y privilegios
8. Uso de roles y privilegios (descripción general)
9. Uso del control de acceso basado en roles (tareas)
10. Atributos de seguridad en Oracle Solaris (referencia)
Parte IV Servicios criptográficos
11. Estructura criptográfica (descripción general)
12. Estructura criptográfica (tareas)
13. Estructura de gestión de claves
Parte V Servicios de autenticación y comunicación segura
14. Autenticación de servicios de red (tareas)
17. Uso de Secure Shell (tareas)
19. Introducción al servicio Kerberos
20. Planificación del servicio Kerberos
21. Configuración del servicio Kerberos (tareas)
22. Mensajes de error y resolución de problemas de Kerberos
23. Administración de las políticas y los principales de Kerberos (tareas)
24. Uso de aplicaciones Kerberos (tareas)
25. El servicio Kerberos (referencia)
Parte VII Auditoría en Oracle Solaris
26. Auditoría (descripción general)
27. Planificación de la auditoría
28. Gestión de auditoría (tareas)
Páginas del comando man del servicio de auditoría
Perfiles de derechos para administración de auditoría
Auditoría y zonas de Oracle Solaris
Sintaxis de la clase de auditoría
Características del proceso de auditoría
Convenciones de nombres de archivos de auditoría binarios
Estructura de registro de auditoría
Análisis de registro de auditoría
La política de auditoría determina si se agrega información adicional a la pista de auditoría.
Las siguientes políticas agregan tokens a los registros de auditoría: arge, argv, group, path, seq, trail, windata_down, windata_up y zonename. Las políticas windata_down y windata_up son utilizadas por la función Trusted Extensions de Oracle Solaris. Para obtener más información, consulte el Capítulo 22, Auditoría de Trusted Extensions (descripción general) de Configuración y administración de Trusted Extensions.
Las políticas restantes no agregan tokens. La política public limita la auditoría de archivos públicos. La política perzone establece colas de auditoría independientes para zonas no globales. Las políticas ahlt y cnt determinan qué sucede cuando no se pueden enviar registros de auditoría. Para obtener más detalles, consulte Políticas de auditoría para eventos síncronos y asíncronos.
Los efectos de las diferentes opciones de políticas de auditoría se describen en Comprensión de la política de auditoría. Para obtener una descripción de las opciones de política de auditoría, consulte la opción -setpolicy en la página del comando man auditconfig(1M). Para obtener una lista de las opciones de política disponibles, ejecute el comando auditconfig -lspolicy. Para la política actual, ejecute el comando auditconfig -getpolicy.
Juntas, la política ahlt y la política cnt rigen lo que ocurre cuando la cola de auditoría está completa y no puede aceptar más eventos.
Nota - La política cnt o ahlt no se activa si la cola para al menos un complemento puede aceptar registros de auditoría.
Las políticas cnt y ahlt son independientes y están relacionadas. Las combinaciones de las políticas tienen los siguientes efectos:
-ahlt +cnt es la política predeterminada que se envía. Este valor predeterminado le permite a un evento auditado ser procesado incluso si el evento no se puede registrar.
La política -ahlt indica que si un registro de auditoría de un evento asíncrono no se puede ubicar en la cola de auditoría de núcleo, el sistema contará los eventos y continuará el procesamiento. En la zona global, el contador as_dropped registra el recuento.
La política +cnt indica que si llega un evento síncrono y el evento no se puede ubicar en la cola de auditoría de núcleo, el sistema contará el evento y continuará el procesamiento. El contador as_dropped de la zona registra el recuento.
La configuración -ahlt +cnt se usa generalmente en sitios donde el procesamiento debe continuar, incluso si continuar con el procesamiento puede producir una pérdida de registros de auditoría. El campo auditstat drop muestra el número de registros de auditoría que se descartan en una zona.
La política +ahlt -cnt indica que el procesamiento se detiene cuando un evento asíncrono no se puede agregar a la cola de auditoría de núcleo.
La política +ahlt indica que si un registro de auditoría de un evento asíncrono no se puede ubicar en la cola de auditoría de núcleo, todo el procesamiento se detiene. El sistema entrará en estado de alerta. El evento asíncrono no estará en la cola de auditoría y se debe recuperar de punteros en la pila de llamadas.
La política -cnt indica que si un evento síncrono no se puede ubicar en la cola de auditoría de núcleo, el subproceso que intenta entregar el evento se bloqueará. El subproceso se coloca en una cola inactiva hasta que el espacio de auditoría pase a estar disponible. Ningún recuento se mantiene. Los programas podrían parecer bloquearse hasta que el espacio de auditoría pase a estar disponible.
La configuración +ahlt -cnt se usa generalmente en sitios donde un registro de cada evento de auditoría tiene prioridad sobre disponibilidad del sistema. Los programas parecerán bloquearse hasta que el espacio de auditoría pase a estar disponible. El campo auditstat wblk muestra el número de veces que los subprocesos se bloquearon.
Sin embargo, si un evento asíncrono se produce, el sistema entrará en estado de alerta, lo que lleva a una interrupción. La cola de núcleo de eventos de auditoría se puede recuperar manualmente de un volcado de bloqueo guardado. El evento asíncrono no estará en la cola de auditoría y se debe recuperar de punteros en la pila de llamadas.
La política -ahlt -cnt indica que si un evento asíncrono no se puede ubicar en la cola de auditoría de núcleo, el evento se contará y continuará el procesamiento. Cuando un evento síncrono no se puede ubicar en la cola de auditoría de núcleo, el subproceso que intenta entregar el evento se bloqueará. El subproceso se coloca en una cola inactiva hasta que el espacio de auditoría pase a estar disponible. Ningún recuento se mantiene. Los programas podrían parecer bloquearse hasta que el espacio de auditoría pase a estar disponible.
La configuración -ahlt -cnt se usa generalmente en los sitios donde el registro de todos los eventos de auditoría síncronos tiene prioridad sobre alguna posible pérdida de registros de auditoría asíncronos. El campo auditstat wblk muestra el número de veces que los subprocesos se bloquearon.
La política +ahlt +cnt indica que si un evento asíncrono no se puede ubicar en la cola de auditoría de núcleo, el sistema entrará en estado de alerta. Si un evento síncrono no se puede ubicar en la cola de auditoría de núcleo, el sistema contará el evento y continuará el procesamiento.