Control de acceso basado en roles (descripción general)

El control de acceso basado en roles (RBAC) es una función de seguridad para controlar el acceso de usuarios a tareas que normalmente están restringidas al superusuario. Mediante la aplicación de atributos de seguridad a procesos y usuarios, RBAC puede dividir las capacidades de superusuario entre varios administradores. La gestión de derechos de procesos se implementa a través de privilegios. La gestión de derechos de usuarios se implementa a través de RBAC.

• Para ver una explicación de la gestión de derechos de procesos, consulte Privilegios (descripción general).

• Para obtener información sobre las tareas de RBAC, consulte el Capítulo 9Uso del control de acceso basado en roles (tareas).

• Para obtener información de referencia, consulte el Capítulo 10Control de acceso basado en roles (referencia).

RBAC: una alternativa al modelo de superusuario

En los sistemas UNIX convencionales, el usuario root, también conocido como superusuario, es omnipotente. Los programas que se ejecutan como root, o los programas setuid, son omnipotentes. El usuario root puede leer y escribir en cualquier archivo, ejecutar todos los programas y enviar señales de terminación a cualquier proceso. De hecho, cualquier persona que puede convertirse en superusuario puede modificar el cortafuegos de un sitio, modificar la pista de auditoría, leer registros confidenciales y apagar toda la red. Un programa setuid usurpado puede realizar cualquier tarea en el sistema.

El control de acceso basado en roles (RBAC) ofrece una alternativa más segura al modelo de superusuario del tipo "todo o nada". Con RBAC, puede aplicar una política de seguridad en un nivel más específico. RBAC utiliza el principio de seguridad del privilegio mínimo. Privilegio mínimo significa que un usuario dispone exactamente de la cantidad de privilegios necesaria para realizar un trabajo. Los usuarios comunes tienen privilegios suficientes para utilizar sus aplicaciones, comprobar el estado de sus trabajos, imprimir archivos, crear archivos nuevos, etc. Las capacidades que van más allá de las capacidades de los usuarios comunes se agrupan en perfiles de derechos. Los usuarios que realizarán trabajos que requieren algunas de las capacidades de superusuario asumen un rol que incluye el perfil de derechos adecuado.

RBAC recopila las capacidades de superusuario en perfiles de derechos. Estos perfiles de derechos se asignan a cuentas de usuario especiales denominadas roles. Luego, un usuario puede asumir un rol para realizar un trabajo que requiere algunas de las capacidades de superusuario. Se incluyen perfiles de derechos predefinidos con el software Oracle Solaris. Usted crea los roles y asigna los perfiles.

Los perfiles de derechos pueden proporcionar capacidades amplias. Por ejemplo, el perfil de derechos de administrador principal es equivalente al superusuario. Los perfiles de derechos también se pueden definir de manera limitada. Por ejemplo, el perfil de derechos de gestión de cron se encarga de los trabajos at y cron. Al crear roles, puede optar por crear roles con capacidades amplias o roles con capacidades limitadas, o ambos.

En el modelo RBAC, el superusuario crea uno o más roles. Los roles se basan en perfiles de derechos. El superusuario luego asigna los roles a los usuarios en los que confía para realizar las tareas del rol. Los usuarios inician sesión con su nombre de usuario. Después del inicio de sesión, los usuarios asumen roles que pueden ejecutar comandos administrativos restringidos y herramientas de la interfaz gráfica de usuario (GUI).

La flexibilidad en la configuración de los roles posibilita una variedad de políticas de seguridad. Aunque se incluyen pocos roles con Oracle Solaris, es posible configurar fácilmente tres roles recomendados. Los roles se basan en perfiles de derechos con el mismo nombre:

• Administrador principal: un rol poderoso que es equivalente al usuario root o superusuario.

• root: un rol poderoso que es equivalente al usuario root. Sin embargo, este usuario root no puede iniciar sesión. Un usuario común debe iniciar sesión y, a continuación, asumir el rol root asignado.

• Administrador del sistema: un rol menos poderoso para la administración que no está relacionado con la seguridad. Este rol puede gestionar sistemas de archivos, correo e instalación de software. Sin embargo, este rol no puede definir contraseñas.

• Operador: rol de administrador junior para operaciones como copias de seguridad y gestión de impresoras.

  ---

  Nota - El perfil de derechos de copia de seguridad de medios proporciona acceso a todo el sistema de archivos raíz. Por lo tanto, si bien los perfiles de derechos de copia de seguridad de medios y operador están diseñados para un administrador junior, debe asegurarse de que el usuario es de confianza.

  ---

No es necesario implementar estos tres roles. Los roles representan una función de las necesidades de seguridad de una organización. Los roles se pueden configurar para administradores con fines especiales en áreas como administración de cortafuegos, redes o seguridad. Otra estrategia es crear un rol de administrador poderoso único junto con un rol de usuario avanzado. El rol de usuario avanzado sería para los usuarios que tienen permiso para corregir partes de sus propios sistemas.

El modelo de superusuario y el modelo RBAC pueden coexistir. La siguiente tabla resume las gradaciones de superusuario a usuario común restringido que son posibles en el modelo RBAC. La tabla incluye las acciones administrativas que se pueden supervisar en ambos modelos. Para obtener un resumen del efecto de los privilegios solamente en un sistema, consulte la Tabla 8-2.

Tabla 8-1 Modelo de superusuario y modelo RBAC con privilegios

Elementos y conceptos básicos de RBAC en Oracle Solaris

El modelo RBAC en Oracle Solaris introduce los siguientes elementos:

• Autorización: un permiso para que un usuario o un rol realice una clase de acciones que requieren derechos adicionales. Por ejemplo, la política de seguridad en la instalación otorga a los usuarios comunes la autorización solaris.device.cdrw. Esta autorización permite a los usuarios leer y escribir en un dispositivo de CD-ROM. Para obtener una lista de autorizaciones, consulte el archivo /etc/security/auth_attr.

• Privilegio: un derecho perfectamente definido que se puede otorgar a un comando, un usuario, un rol o un sistema. Los privilegios permiten que un proceso se realice correctamente. Por ejemplo, el privilegio proc_exec permite a un proceso llamar execve(). Los usuarios comunes tienen privilegios básicos. Para ver sus privilegios básicos, ejecute el comando ppriv -vl basic.

• Atributos de seguridad: un atributo que permite a un proceso efectuar una operación. En un entorno UNIX típico, un atributo de seguridad permite a un proceso efectuar una operación que, de lo contrario, está prohibida para los usuarios comunes. Por ejemplo, los programas setuid y setgid tienen atributos de seguridad. En el modelo RBAC, las operaciones que los usuarios comunes realizan pueden requerir atributos de seguridad. Además de los programas setuid y setgid, las autorizaciones y los privilegios también son atributos de seguridad en el modelo RBAC. Por ejemplo, un usuario con la autorización solaris.device.allocate puede asignar un dispositivo para uso exclusivo. Un proceso con el privilegio sys_time puede manipular la hora del sistema.

• Aplicación con privilegios: una aplicación o un comando que puede anular los controles del sistema mediante la comprobación de atributos de seguridad. En un entorno UNIX típico y en el modelo RBAC, los programas que usan setuid y setgid son aplicaciones con privilegios. En el modelo RBAC, los programas que necesitan privilegios o autorizaciones para ejecutarse correctamente también son aplicaciones con privilegios. Para obtener más información, consulte Aplicaciones con privilegios y RBAC.

• Perfil de derechos: una recopilación de capacidades administrativas que se pueden asignar a un rol o a un usuario. Un perfil de derechos puede constar de autorizaciones, comandos con atributos de seguridad y otros perfiles de derechos. Los perfiles de derechos ofrecen una forma práctica de agrupar los atributos de seguridad.

• Rol: una identidad especial para ejecutar aplicaciones con privilegios. Sólo los usuarios asignados pueden asumir la identidad especial. En un sistema que se ejecuta por roles, el superusuario resulta innecesario. Las capacidades de superusuario se distribuyen en roles diferentes. Por ejemplo, en un sistema de dos roles, las tareas de seguridad serían gestionadas por un rol de seguridad. El segundo rol se ocuparía de las tareas de administración del sistema que no están relacionadas con la seguridad. Los roles pueden ser más específicos. Por ejemplo, un sistema podría incluir roles administrativos independientes para gestionar la estructura criptográfica, las impresoras, la hora del sistema, los sistemas de archivos y la auditoría.

La siguiente figura muestra cómo trabajan juntos los elementos de RBAC.

Figura 8-1 Relaciones entre elementos de RBAC en Oracle Solaris

En RBAC, se asignan roles a los usuarios. Cuando un usuario asume un rol, las capacidades del rol están disponibles. Los roles obtienen sus capacidades de los perfiles de derechos. Los perfiles de derechos pueden contener autorizaciones, privilegios asignados directamente, comandos con privilegios y otros perfiles de derechos complementarios. Los comandos con privilegios son comandos que se ejecutan con atributos de seguridad.

La siguiente figura utiliza el rol de seguridad de la red y el perfil de derechos de seguridad de la red para demostrar las relaciones de RBAC.

Figura 8-2 Ejemplo de relaciones entre elementos de RBAC en Oracle Solaris

El rol de seguridad de la red se utiliza para la gestión de IPsec, wifi y enlaces de red. El rol se asigna al usuario jdoe. Para asumir el rol, jdoe puede cambiar a dicho rol y, a continuación, suministrar la contraseña del rol.

El perfil de derechos de seguridad de la red se asignó al rol de seguridad de la red. El perfil de derechos de seguridad de la red contiene perfiles complementarios que se evalúan en orden: seguridad de wifi de red, seguridad de enlaces de red y gestión de IPsec de red. Estos perfiles complementarios desempeñan las principales tareas del rol.

El perfil de derechos de seguridad de la red tiene tres autorizaciones asignadas directamente, ningún privilegio asignado directamente y dos comandos con atributos de seguridad. Los perfiles de derechos complementarios tienen autorizaciones asignadas directamente y dos de ellas tienen comandos con atributos de seguridad. En el rol de seguridad de la red, jdoe tiene todas las autorizaciones asignadas en estos perfiles y puede ejecutar todos los comandos con atributos de seguridad en estos perfiles. jdoe puede administrar la seguridad de la red.

Escalada de privilegios

Oracle Solaris proporciona a los administradores mucha flexibilidad al configurar la seguridad. Tal como está instalado, el software no permite la escalonamiento de privilegios. La escalada de privilegios se produce cuando un usuario o un proceso obtienen más derechos administrativos de los que inicialmente se les iban a otorgar. En este sentido, un privilegio comprende cualquier atributo de seguridad, no sólo privilegios.

El software Oracle Solaris incluye atributos de seguridad que están asignados al usuario root únicamente. Con otras protecciones de seguridad implementadas, es posible que un administrador asigne atributos que están diseñados para el usuario root en otras cuentas, pero dicha asignación se debe realizar con cuidado.

Por ejemplo, el perfil de derechos de restauración de medios existe, pero no es parte de ningún otro perfil de derechos. Debido a que la restauración de medios proporciona acceso a todo el sistema de archivos raíz, su uso constituye una posible escalada de privilegios. Se podrían restaurar medios alternativos o archivos modificados deliberadamente. De manera predeterminada, sólo el usuario root tiene este perfil de derechos.

Para conocer las escaladas que afectan el atributo de seguridad del privilegio, consulte Cómo evitar la escalada de privilegios.

Autorizaciones RBAC

Una autorización es un derecho perfectamente definido que se puede otorgar a un rol o a un usuario. Las autorizaciones aplican políticas en el nivel de aplicación del usuario.

Aunque las autorizaciones pueden asignarse directamente a un rol o a un usuario, se recomienda incluirlas en un perfil de derechos. El perfil de derechos luego se agrega a un rol, y el rol se asigna a un usuario. Para ver un ejemplo, consulte la Figura 8-2.

Las aplicaciones compatibles con RBAC pueden comprobar las autorizaciones de un usuario antes de otorgar acceso a la aplicación o a operaciones específicas dentro de la aplicación. Esta comprobación reemplaza la verificación en las aplicaciones UNIX convencionales para UID=0. Para obtener más información sobre las autorizaciones, consulte las siguientes secciones:

• Denominación y delegación de autorizaciones

• Base de datos auth_attr

• Comandos que requieren autorizaciones

Autorizaciones y privilegios

Los privilegios aplican la política de seguridad en el núcleo. La diferencia entre las autorizaciones y los privilegios reside en el nivel en el que se aplica la política de seguridad. Sin el privilegio adecuado, el núcleo puede evitar que un proceso realice operaciones con privilegios. Sin las autorizaciones adecuadas, es posible que se le impida a un usuario utilizar una aplicación con privilegios o realizar operaciones que conllevan riesgos de seguridad dentro de una aplicación con privilegios. Para ver una explicación más detallada de los privilegios, consulte Privilegios (descripción general).

Aplicaciones con privilegios y RBAC

Las aplicaciones y los comandos que pueden anular los controles del sistema se consideran aplicaciones con privilegios. Los atributos de seguridad, como UID=0, los privilegios y las autorizaciones hacen que una aplicación sea una aplicación con privilegios.

Aplicaciones que comprueban UID y GID

Las aplicaciones con privilegios que comprueban la existencia de root (UID=0) o algún otro UID o GID especial han estado presentes en el entorno UNIX desde hace tiempo. El mecanismo de perfiles de derechos permite aislar comandos que requieren un ID específico. En lugar de cambiar el ID de un comando al que cualquiera puede acceder, puede colocar el comando con atributos de seguridad de ejecución en un perfil de derechos. Un usuario o un rol con ese perfil de derechos luego pueden ejecutar el programa sin tener que convertirse en superusuario.

Los ID se pueden especificar como reales o efectivos. Se prefiere la asignación de ID efectivos en lugar de la asignación de ID reales. Los ID efectivos son equivalentes a la función setuid en los bits de permisos de archivo. Los ID efectivos también identifican el UID para auditoría. Sin embargo, dado que algunos programas y secuencias de comandos de shell requieren un UID real de root, también es posible definir UID reales. Por ejemplo, el comando pkgadd requiere un UID real en lugar de uno efectivo. Si un ID efectivo no es suficiente para ejecutar un comando, debe cambiar el ID por un ID real. Para conocer el procedimiento, consulte Cómo crear o modificar un perfil de derechos.

Aplicaciones que comprueban privilegios

Las aplicaciones con privilegios pueden comprobar el uso de privilegios. El mecanismo de perfiles de derechos de RBAC permite especificar los privilegios para comandos específicos. En lugar de requerir capacidades de superusuario para utilizar una aplicación o un comando, puede aislar el comando con atributos de seguridad de ejecución en un perfil de derechos. Un usuario o un rol con ese perfil de derechos luego pueden ejecutar el comando sólo con los privilegios que el comando necesita para una ejecución correcta.

Entre los comandos que comprueban la existencia de privilegios, se incluyen los siguientes:

• Comandos de Kerberos, como kadmin, kprop y kdb5_util.

• Comandos de redes, como ifconfig, routeadm y snoop.

• Comandos de archivos y sistemas de archivos, como chmod, chgrp y mount.

• Comandos que controlan procesos, como kill, pcred y rcapadm.

Para agregar comandos con privilegios en un perfil de derechos, consulte Cómo crear o modificar un perfil de derechos. Para determinar los comandos que comprueban privilegios en un perfil concreto, consulte Determinación de los privilegios asignados.

Aplicaciones que comprueban autorizaciones

Oracle Solaris proporciona además comandos que comprueban autorizaciones. Por definición, el usuario root tiene todas las autorizaciones. Por lo tanto, el usuario root puede ejecutar cualquier aplicación. Entre las aplicaciones que comprueban la existencia de autorizaciones, se incluyen las siguientes:

• Todo el conjunto de herramientas de Solaris Management Console.

• Comandos de administración de auditoría, como auditconfig y auditreduce.

• Comandos de administración de impresoras, como lpadmin y lpfilter.

• Comandos relacionados con trabajos por lotes, como at, atq, batch y crontab.

• Comandos orientados a dispositivos, como allocate, deallocate, list_devices y cdrw.

Para probar las autorizaciones de una secuencia de comandos o un programa, consulte el Ejemplo 9-24. Para escribir un programa que requiere autorizaciones, consulte About Authorizations de Developer’s Guide to Oracle Solaris Security.

Perfiles de derechos de RBAC

Un perfil de derechos es una recopilación de valores de sustitución del sistema que se pueden asignar a un rol o a un usuario. Un perfil de derechos puede incluir autorizaciones, comandos con atributos de seguridad asignados y otros perfiles de derechos. La información del perfil de derechos se divide entre las bases de datos prof_attr y exec_attr. El nombre y las autorizaciones del perfil de derechos están en la base de datos prof_attr. El nombre y los comandos del perfil de derechos con atributos de seguridad asignados están en la base de datos exec_attr.

Para obtener más información sobre los perfiles de derechos, consulte las siguientes secciones:

• Contenido de los perfiles de derechos

• Base de datos prof_attr

• Base de datos exec_attr

Roles de RBAC

Un rol es un tipo especial de cuenta de usuario desde la que puede ejecutar aplicaciones con privilegios. Los roles se crean del mismo modo general que las cuentas de usuario. Los roles tiene un directorio principal, una asignación de grupo, una contraseña, etc. Los perfiles de derechos y las autorizaciones otorgan al rol capacidades administrativas. Los roles no pueden heredar capacidades de otros roles u otros usuarios. Los roles discretos dividen las capacidades de superusuario y, por lo tanto, permiten prácticas administrativas más seguras.

Cuando un usuario asume un rol, los atributos del rol reemplazan todos los atributos de usuario. La información del rol se almacena en las bases de datos passwd, shadow y user_attr. La información del rol se puede agregar a la base de datos audit_user. Para obtener información detallada acerca de cómo configurar roles, consulte las siguientes secciones:

• Cómo planificar la implementación de RBAC

• Cómo crear un rol desde la línea de comandos

• Cómo cambiar las propiedades de un rol

Un rol se puede asignar a más de un usuario. Todos los usuarios que pueden asumir el mismo rol tienen el mismo directorio principal, trabajan en el mismo entorno y tienen acceso a los mismos archivos. Los usuarios pueden asumir roles desde la línea de comandos. Para ello, deben ejecutar el comando su y proporcionar el nombre del rol y la contraseña. Los usuarios también pueden asumir un rol en la herramienta de Solaris Management Console.

Un rol no puede iniciar sesión directamente. Un usuario inicia sesión y, a continuación, asume un rol. Tras asumir un rol, el usuario no puede asumir otro rol sin salir primero de su rol actual. Tras salir del rol, el usuario puede asumir otro rol.

Para impedir el inicio de sesión anónimo de root puede cambiar el usuario root a un rol, tal como se muestra en Cómo convertir el usuario root en un rol. Si se audita el comando de shell de perfil, pfexec, la pista de auditoría contiene el UID real del usuario que inició sesión, los roles que el usuario asumió y las acciones que el rol realizó. Para auditar operaciones de roles en el sistema o un usuario concreto, consulte Cómo auditar roles.

No se incluyen roles predefinidos con el software Oracle Solaris. Sin embargo, los perfiles de derechos que se envían con el software están diseñados para asignarlos a roles. Por ejemplo, el perfil de derechos de administrador principal se puede utilizar para crear el rol de administrador principal.

• Para configurar el rol de administrador principal, consulte Uso de las herramientas de gestión de Solaris con RBAC (mapa de tareas) de Guía de administración del sistema: administración básica.

• Para configurar otros roles, consulte Cómo crear y asignar un rol con la interfaz gráfica de usuario.

• Para crear roles en la línea de comandos, consulte Gestión de RBAC (mapa de tareas).

Shells de perfil y RBAC

Los roles pueden ejecutar aplicaciones con privilegios desde el programa de ejecución de Solaris Management Console o desde un shell de perfil. Un shell de perfil es un shell especial que reconoce los atributos de seguridad que se incluyen en un perfil de derechos. Los shells de perfil se inician cuando el usuario ejecuta el comando su para asumir un rol. Los shells de perfil son pfsh, pfcsh y pfksh. Los shells se corresponden con el shell Bourne (sh), el shell C (csh) y el shell Korn (ksh), respectivamente.

Los usuarios a los que se asignó directamente un perfil de derechos deben invocar un shell de perfil para ejecutar los comandos con atributos de seguridad. Para conocer las consideraciones de seguridad y facilidad de uso, consulte Consideraciones de seguridad al asignar directamente atributos de seguridad.

Todos los comandos que se ejecutan en un shell de perfil pueden auditarse. Para obtener más información, consulte Cómo auditar roles.

Ámbito de servicio de nombres y RBAC

El ámbito de servicio de nombres es un concepto importante para comprender RBAC. El ámbito de un rol puede estar limitado a un host individual. El ámbito también puede incluir todos los hosts gestionados por un servicio de nombres, como NIS, NIS+ o LDAP. El ámbito de servicio de nombres de un sistema se especifica en el archivo /etc/nsswitch.conf. Las consultas se detienen en la primera coincidencia. Por ejemplo, si un perfil de derechos existe en dos ámbitos de servicio de nombres, sólo se utilizan las entradas del primer ámbito de servicio de nombres. Si files es la primera coincidencia, el ámbito del rol se limita al host local.

Consideraciones de seguridad al asignar directamente atributos de seguridad

Por lo general, un usuario obtiene capacidades administrativas a través de un rol. Las autorizaciones y los comandos con privilegios se agrupan en un perfil de derechos. El perfil de derechos se incluye en un rol, y el rol se asigna a un usuario.

La asignación directa de perfiles de derechos y atributos de seguridad también es posible:

• Se pueden asignar directamente perfiles de derechos, privilegios y autorizaciones a usuarios.

• Se pueden asignar directamente privilegios y autorizaciones a usuarios y roles.

Sin embargo, la asignación directa de privilegios no es una práctica segura. Los usuarios y los roles con un privilegio asignado directamente pueden anular la política de seguridad cada vez que el núcleo necesite este privilegio. Una práctica más segura es asignar el privilegio como atributo de seguridad de un comando en un perfil de derechos. Luego, ese privilegio sólo estará disponible para ese comando y un usuario que tenga ese perfil de derechos.

Dado que las autorizaciones funcionan en el nivel de usuario, la asignación directa de autorizaciones puede resultar menos riesgosa que la asignación directa de privilegios. Sin embargo, las autorizaciones pueden permitir a un usuario realizar tareas de seguridad elevada, por ejemplo, asignar indicadores de auditoría.

Un perfil de derechos que se asigna directamente a un usuario presenta problemas de facilidad de uso más que problemas de seguridad. Los comandos con atributos de seguridad en el perfil de derechos sólo se pueden ejecutar correctamente en un shell de perfil. El usuario no se debe olvidar de abrir un shell de perfil y, a continuación, debe escribir los comandos en ese shell. Un rol al cual se asigna un perfil de derechos obtiene un shell de perfil automáticamente. Por lo tanto, los comandos se ejecutan correctamente en el shell del rol.