Omitir V�nculos de navegaci�n | |
Salir de la Vista de impresi�n | |
Guía de administración del sistema: servicios de seguridad |
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. Control de acceso a dispositivos (tareas)
5. Uso de la herramienta básica de creación de informes de auditoría (tareas)
6. Control de acceso a archivos (tareas)
7. Uso de la herramienta automatizada de mejora de la seguridad (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. Control de acceso basado en roles (referencia)
Parte IV Servicios criptográficos
13. Estructura criptográfica de Oracle Solaris (descripción general)
14. Estructura criptográfica de Oracle Solaris (tareas)
15. Estructura de gestión de claves de Oracle Solaris
Parte V Servicios de autenticación y comunicación segura
16. Uso de servicios de autenticación (tareas)
19. Uso de Oracle Solaris Secure Shell (tareas)
20. Oracle Solaris Secure Shell (referencia)
21. Introducción al servicio Kerberos
22. Planificación del servicio Kerberos
23. Configuración del servicio Kerberos (tareas)
24. Mensajes de error y resolución de problemas de Kerberos
25. Administración de las políticas y los principales de Kerberos (tareas)
26. Uso de aplicaciones Kerberos (tareas)
27. El servicio Kerberos (referencia)
Terminología específica de Kerberos
Terminología específica de la autenticación
Nombres de principales de Kerberos
Cómo funciona el sistema de autenticación Kerberos
Cómo interactúa el servicio Kerberos con el DNS y el archivo nsswitch.conf
Obtención de acceso a un servicio con Kerberos
Obtención de una credencial para el servicio de otorgamiento de tickets
Obtención de una credencial para un servidor
Obtención de acceso a un servicio específico
Diferencias importantes entre Oracle Solaris Kerberos y MIT Kerberos
Parte VII Auditoría de Oracle Solaris
28. Auditoría de Oracle Solaris (descripción general)
29. Planificación de la auditoría de Oracle Solaris
30. Gestión de la auditoría de Oracle Solaris (tareas)
Los tipos de cifrado identifican los algoritmos criptográficos y el modo en que se deben usar cuando se realizan las operaciones criptográficas. Los tipos de cifrado aes, des3-cbc-sha1 y rc4–hmac permiten la creación de claves que se pueden utilizar para las operaciones criptográficas más resistentes. Estas operaciones más resistentes mejoran la seguridad general del servicio Kerberos.
Nota - En las versiones anteriores a la versión Solaris 10 8/07, el tipo de cifrado aes256-cts-hmac-sha1-96 se puede utilizar con el servicio Kerberos si los paquetes de criptografía resistente que están desempaquetados se encuentran instalados.
Cuando un cliente solicita un ticket del KDC, el KDC debe usar claves cuyo tipo de cifrado sea compatible tanto con el cliente como con el servidor. Mientras que el protocolo Kerberos permite al cliente solicitar que el KDC utilice determinados tipos de cifrado para la parte del cliente de la respuesta de ticket, el protocolo no permite que el servidor especifique tipos de cifrado para el KDC.
Nota - Si tiene instalado un KDC maestro que no ejecuta la versión Solaris 10, los KDC esclavos deben actualizarse a la versión Solaris 10 antes de actualizar el KDC maestro. Un KDC maestro de Solaris 10 utilizará lo nuevos tipos de cifrado, que un esclavo anterior no podrá manejar.
A continuación se enumeran algunos de los problemas que deben tenerse en cuenta antes de cambiar los tipos de cifrado.
El KDC supone que el servidor admite el primer conjunto de claves y tipos de cifrado asociados a la entrada del principal de servidor en la base de datos del principal.
En el KDC, debe asegurarse de que las claves generadas para el principal sean compatibles con los sistemas en los que se autenticará el principal. De manera predeterminada, el comando kadmin crea claves para todos los tipos de cifrado admitidos. Si los sistemas en los que se utiliza el principal no admiten este conjunto de tipos de cifrado predeterminado, debe restringir los tipos de cifrado cuando crea un principal. Puede restringir los tipos de cifrado mediante el uso del indicador -e en kadmin addprinc o la definición del parámetro supported_enctypes en el archivo kdc.conf de este subconjunto. El parámetro supported_enctypes debe utilizarse cuando la mayoría de los sistemas de un dominio Kerberos admiten un subconjunto del conjunto predeterminado de tipos de cifrado. Al definir supported_enctypes, se especifica el conjunto predeterminado de tipos de cifrado que kadmin addprinc utiliza cuando crea un principal para un dominio en particular. Como regla general, es mejor controlar los tipos de cifrado utilizados por Kerberos con alguno de estos dos métodos.
Cuando vaya a determinar los tipos de cifrado que admite un sistema, tenga en cuenta la versión de Kerberos que se ejecuta en el sistema y los algoritmos criptográficos que admite la aplicación de servidor para la que se crea un principal de servidor. Por ejemplo, cuando se crea un principal de servicio nfs/hostname, debe restringir los tipos de cifrado para los tipos que admite el servidor NFS en ese host. Tenga en cuenta que, en la versión Solaris 10, el servidor NFS también admite todos los tipos de cifrado de Kerberos.
El parámetro master_key_enctype del archivo kdc.conf se puede utilizar para controlar el tipo de cifrado de la clave maestra que cifra las entradas de la base de datos del principal. No utilice este parámetro si la base de datos del principal del KDC ya se ha creado. El parámetro master_key_enctype se puede usar en el momento de la creación de la base de datos para cambiar el tipo de cifrado predeterminado para la clave maestra, de des-cbc-crc a un tipo de cifrado más resistente. Cuando configure los KDC esclavos, asegúrese de que todos admitan el tipo de cifrado seleccionado y tengan una entrada master_key_enctype idéntica en su archivo kdc.conf. Asimismo, asegúrese de que master_key_enctype se encuentre definido en uno de los tipos de cifrado en supported_enctypes si supported_enctypes está definido en kdc.conf. Si alguno de estos problemas no se trata adecuadamente, es posible que el KDC maestro no pueda trabajar con los KDC esclavos.
En el cliente, puede controlar qué tipos de cifrado el cliente solicita cuando obtiene los tickets procedentes del KDC mediante algunos parámetros de krb5.conf. El parámetro default_tkt_enctypes especifica los tipos de cifrado que el cliente está dispuesto a utilizar cuando el cliente solicita un ticket de otorgamiento de tickets (TGT) desde el KDC. El cliente utiliza el TGT para adquirir otros tickets del servidor con más eficacia. Se define default_tkt_enctypes a fin de otorgarle al cliente un poco de control sobre los tipos de cifrado que se utilizan para proteger la comunicación entre el cliente y el KDC cuando el cliente solicita un ticket de servidor con el TGT (esto se llama solicitud TGS). Tenga en cuenta que los tipos de cifrado especificados en default_tkt_enctypes deben coincidir, al menos, con uno de los tipos de cifrado de la clave de principal en la base de datos del principal que se almacena en el KDC. De lo contrario, la solicitud TGT fallará. En la mayoría de las situaciones, es mejor no definir default_tkt_enctypes, porque este parámetro puede generar problemas de interoperabilidad. De manera predeterminada, el código de cliente pide que todos los tipos de cifrado admitidos y el KDC seleccionen los tipos de cifrado en función de las claves que el KDC encuentre en la base de datos del principal.
El parámetro default_tgs_enctypes restringe los tipos de cifrado que el cliente solicita en sus solicitudes TGS, que se utilizan para adquirir tickets de servidor. Este parámetro también restringe los tipos de cifrado que el KDC utiliza cuando crea la clave de sesión que el cliente y el servidor comparten. Por ejemplo, si un cliente quiere usar solamente el cifrado 3DES cuando emplea NFS seguro, debe definir default_tgs_enctypes = des3-cbc-sha1. Asegúrese de que los principales de servidor y de cliente tengan una clave des-3-cbc-sha1 en la base de datos del principal. Al igual que con default_tkt_enctype, probablemente sea mejor, en la mayoría de los casos, no establecer esto, ya que puede provocar problemas de interoperabilidad si las credenciales no están configuradas correctamente en el KDC o en el servidor.
En el servidor, puede controlar los tipos de cifrado aceptados por el servidor con permitted_enctypes en kdc.conf. Además, puede especificar los tipos de cifrado utilizados en la creación de entradas keytab. Por lo general, es mejor no utilizar ninguno de estos métodos para controlar los tipos de cifrado y, en su lugar, dejar que el KDC determine los tipos de cifrado que se usarán, porque el KDC no se comunica con la aplicación del servidor para determinar qué clave o tipo de cifrado se usarán.