Tema 5
En esta unidad se analiza qué ocurre después de la autenticación: cómo decide el sistema operativo qué puede hacer cada identidad, qué recursos puede usar y bajo qué condiciones. La autorización correcta es el núcleo del control de acceso y una defensa esencial para limitar el daño.
Autenticar a un usuario no resuelve el problema de seguridad. Solo confirma su identidad. La pregunta siguiente es mucho más delicada: ¿qué está autorizado a hacer? Si el sistema responde de forma demasiado amplia, cualquier cuenta comprometida tendrá un poder desproporcionado. Si responde de forma demasiado restrictiva, la operación diaria se vuelve ineficiente o directamente inviable.
La autorización es, por lo tanto, el punto en el que seguridad y operatividad se encuentran. El sistema operativo debe conceder acceso suficiente para trabajar, pero no tanto como para convertir cada usuario o proceso en un vector de riesgo sistémico.
Ambos conceptos están relacionados, pero cumplen roles distintos. La autenticación valida identidad. La autorización asigna capacidades. Un error frecuente es pensar que una buena autenticación compensa una mala política de permisos. No es así.
Un usuario puede autenticarse correctamente y, sin embargo, no debería tener acceso a ciertos archivos, comandos, servicios o configuraciones. Del mismo modo, un servicio automatizado puede funcionar legítimamente, pero no necesita permiso para modificar recursos ajenos a su tarea.
Un permiso es una capacidad concreta concedida por el sistema sobre un recurso determinado. Ese recurso puede ser un archivo, un directorio, un proceso, un dispositivo, una clave de configuración, una impresora, un socket o una función administrativa.
Los permisos pueden incluir acciones como leer, escribir, ejecutar, eliminar, cambiar atributos, tomar posesión, crear objetos o administrar configuraciones. No todos los sistemas expresan estos permisos del mismo modo, pero la idea de fondo es común: controlar el tipo y el alcance de las operaciones permitidas.
Para entender el control de acceso conviene pensar en tres elementos:
La autorización consiste en decidir si un sujeto puede ejecutar una operación sobre un objeto específico. Esta formulación simple ayuda a analizar problemas de acceso con mayor claridad.
Los sistemas operativos suelen aplicar permisos básicos sobre archivos y directorios. Aunque la implementación exacta cambia entre plataformas, las categorías tradicionales son bastante estables:
En directorios, la semántica puede variar respecto de archivos. Por ejemplo, listar contenido, crear nuevos elementos o atravesar una ruta no siempre significan lo mismo. Por eso administrar permisos requiere comprender el comportamiento real y no solo memorizar nombres.
Asignar permisos de forma individual a cada usuario no suele ser escalable. Por eso los sistemas operativos permiten agrupar cuentas y conceder permisos a grupos en lugar de hacerlo persona por persona. Esta estrategia simplifica la administración y reduce errores.
Sin embargo, también introduce complejidad. Un usuario puede pertenecer a múltiples grupos, heredar permisos por distintas vías y acumular privilegios que nadie evaluó de manera integral. Por eso la revisión periódica de membresías es tan importante como la revisión de las reglas de acceso.
Las listas de control de acceso, o ACL, permiten definir permisos de manera más granular. En lugar de limitarse a un esquema simple de propietario, grupo y otros, una ACL puede indicar con más detalle qué sujetos tienen qué tipos de acceso sobre un recurso.
Este mecanismo aporta flexibilidad, pero también aumenta el riesgo de configuraciones difíciles de entender. Una ACL mal diseñada puede conceder acceso por caminos indirectos o acumular excepciones que terminan debilitando el modelo completo.
Windows utiliza ampliamente ACL detalladas sobre archivos, servicios, procesos, objetos del sistema y numerosos recursos administrativos. Linux, además del esquema clásico de permisos, también puede apoyarse en ACL extendidas y mecanismos complementarios.
La diferencia más importante no es solo técnica, sino operativa. En ambos entornos, los problemas más frecuentes aparecen cuando la complejidad del modelo hace que los administradores dejen de entender quién tiene acceso a qué y por qué lo tiene.
En algunos modelos de control de acceso existen reglas de denegación explícita que prevalecen sobre permisos concedidos. Esto puede ser útil para bloquear casos puntuales, pero también puede volver más difícil el análisis si se abusa del mecanismo.
Comprender precedencias, herencias y conflictos entre reglas es fundamental. Un sistema seguro no es solo uno con muchas reglas, sino uno cuyas reglas pueden ser interpretadas con claridad y sin ambigüedades.
No todo acceso se expresa mediante permisos sobre objetos. Existen también privilegios del sistema, que habilitan capacidades más amplias, como apagar el equipo, cargar controladores, depurar procesos, cambiar la hora del sistema o tomar posesión de archivos.
Desde la seguridad, estos privilegios son especialmente delicados porque no se limitan a un solo recurso. Un privilegio mal concedido puede abrir camino a escalamiento, evasión de controles o abuso administrativo.
El principio de mínimo privilegio establece que cada usuario, cuenta de servicio, proceso o aplicación debe recibir solo los permisos estrictamente necesarios para cumplir su función, y no más. Este principio es una de las bases más sólidas de la seguridad en sistemas operativos.
Su valor está en limitar consecuencias. Si una cuenta es comprometida, el daño potencial será menor si esa cuenta solo accede a lo que realmente necesita. Si una aplicación vulnerable corre con privilegios mínimos, el atacante también parte de un margen más estrecho.
Un error habitual consiste en asignar permisos administrativos a usuarios que solo los necesitan de manera ocasional o que, en realidad, nunca los necesitaron. Esta práctica aumenta la exposición del sistema sin aportar valor real.
Aplicar mínimo privilegio a usuarios implica:
Los servicios automáticos y las aplicaciones también deberían operar con el nivel de acceso más bajo posible. Si un servicio web corre con permisos excesivos sobre archivos, procesos o credenciales, cualquier vulnerabilidad explotada en ese servicio hereda ese poder.
Esto hace especialmente importante revisar:
En muchos entornos no basta con aplicar permisos mínimos. También conviene separar funciones para que una sola identidad no concentre todo el poder operativo. Esta idea se conoce como segregación o separación de funciones.
Por ejemplo, quien administra usuarios no necesariamente debería aprobar sus propios accesos críticos. Quien opera respaldos no necesariamente debería tener permisos para borrar evidencia de auditoría. La separación de funciones reduce fraude, error y abuso interno.
Muchos problemas de seguridad no nacen en una vulnerabilidad sofisticada, sino en permisos mal concedidos. Carpetas compartidas demasiado abiertas, scripts ejecutables por cuentas no previstas, servicios con derechos administrativos o directorios críticos modificables por usuarios estándar son ejemplos frecuentes.
Los permisos excesivos no siempre generan un incidente inmediato. Precisamente por eso son peligrosos: permanecen invisibles hasta que alguien los explota, ya sea por error, abuso interno o intrusión externa.
Con el tiempo, los sistemas tienden a acumular excepciones. Un acceso se concede “por urgencia”, otro nunca se retira, un grupo crece sin revisión, una herencia de ACL se mantiene aunque ya no tenga sentido. Este desorden acumulado es una de las causas más comunes de pérdida de control sobre la autorización.
La seguridad madura no depende solo de definir permisos correctos al principio. También depende de revisar, simplificar y depurar permisos heredados o históricos que ya no responden a una necesidad actual.
Una buena práctica consiste en revisar periódicamente qué acceso tiene cada identidad y justificarlo. Esto incluye usuarios, grupos, cuentas de servicio y permisos sobre recursos críticos.
Las revisiones deberían buscar al menos:
Controlar acceso no es suficiente si luego no se puede reconstruir qué uso se hizo de ese acceso. Por eso la autorización debe complementarse con auditoría. No solo interesa saber quién puede modificar un recurso, sino también quién lo modificó realmente, cuándo y desde qué contexto.
Esto resulta especialmente importante en recursos administrativos, información sensible, configuraciones del sistema y acciones de alto impacto operativo.
Linux suele apoyarse fuertemente en su esquema clásico de propietario, grupo y otros, complementado con ACL, sudo y mecanismos adicionales como SELinux o AppArmor. Windows, por su parte, utiliza modelos de ACL más detallados sobre múltiples tipos de objetos y un enfoque muy granular para privilegios y herencias.
En ambos sistemas, el problema real no está solo en la herramienta, sino en la administración. Un modelo potente mal entendido puede generar más riesgo que uno simple pero bien mantenido.
Supongamos que una cuenta de usuario está correctamente protegida con MFA y contraseña robusta. Sin embargo, pertenece por error a un grupo con permisos de escritura sobre scripts de inicio del sistema y acceso innecesario a un directorio compartido crítico. Aunque la autenticación sea buena, la autorización sigue siendo insegura.
Este ejemplo muestra por qué la seguridad de acceso no puede evaluarse solo en el punto de login. También debe analizarse en el punto de acción: qué puede hacer esa identidad una vez dentro.
Este tipo de preguntas ayuda a convertir la autorización en un proceso de revisión continua y no en una configuración fija e intocable.
La seguridad de un sistema operativo no depende solo de quién entra, sino de lo que cada identidad puede hacer una vez autenticada. Por eso la autorización, los permisos y el principio de mínimo privilegio son mecanismos centrales para contener fallos, limitar intrusiones y reducir daños.
En el próximo tema se profundizará en la gestión de usuarios, grupos y privilegios administrativos, abordando la administración práctica de identidades con foco en cómo se asignan, revisan y controlan estos poderes dentro del sistema.