Tema 6
En esta unidad se aborda la administración práctica de identidades dentro del sistema operativo. Se estudia cómo crear, organizar, revisar y proteger usuarios, grupos y privilegios administrativos para evitar abuso, pérdida de trazabilidad y escalamiento innecesario de poder.
La seguridad de un sistema operativo depende tanto de sus mecanismos técnicos como de la forma en que se administran las identidades que lo utilizan. Usuarios mal creados, grupos mal definidos o privilegios administrativos concedidos sin control pueden convertir un sistema aparentemente seguro en un entorno fácilmente explotable.
La gestión de identidades no consiste solo en crear cuentas cuando alguien entra a la organización. También implica revisar acceso, retirar permisos innecesarios, registrar cambios, controlar grupos privilegiados y mantener trazabilidad sobre quién tiene poder sobre qué recursos.
Un usuario representa una identidad individual o funcional. Un grupo reúne identidades con necesidades de acceso similares. Un rol expresa una función dentro de la organización o del sistema, y puede traducirse en membresías, permisos y responsabilidades.
La administración madura de identidades parte de esa diferencia. No conviene asignar todo directamente a usuarios. Es más seguro y más escalable estructurar acceso según roles y reflejar esos roles mediante grupos bien definidos.
Crear una cuenta no debería ser una acción informal. Cada cuenta nueva debería responder a una necesidad concreta, tener un responsable identificable y quedar asociada a una función legítima. Además, desde el inicio deben definirse sus permisos, grupo de pertenencia, método de autenticación y fecha de revisión.
Una creación descuidada suele ser el inicio de problemas posteriores: cuentas con acceso excesivo, nombres ambiguos, credenciales temporales que nadie cambia o membresías agregadas por comodidad.
La forma de nombrar cuentas también influye en la seguridad. Una cuenta con nombre claro, propósito definido y propietario identificable es más fácil de auditar. En cambio, cuentas genéricas, ambiguas o heredadas complican la revisión y favorecen el olvido administrativo.
Esto es especialmente importante en cuentas de servicio, cuentas temporales y accesos administrativos. La claridad nominal no reemplaza los controles, pero sí mejora notablemente la capacidad de gobernarlos.
Los grupos permiten centralizar permisos y simplificar administración. En lugar de conceder acceso recurso por recurso a cada usuario, se asignan permisos al grupo y luego se administra quién pertenece a él. Esta práctica reduce errores manuales y hace más visible la relación entre función y acceso.
Sin embargo, un grupo mal diseñado puede transformarse en una caja negra de privilegios acumulados. Por eso conviene que los grupos respondan a funciones claras, tengan nombres comprensibles y se mantengan acotados en alcance.
Con el tiempo, algunos grupos comienzan a incorporar miembros “por excepción”, “por urgencia” o “porque siempre se hizo así”. Cuando eso ocurre, dejan de representar un rol coherente y pasan a ser contenedores de privilegios difíciles de justificar.
La sobreacumulación de grupos genera varios riesgos:
Los privilegios administrativos son capacidades que permiten modificar el estado del sistema, instalar software, cambiar permisos, crear cuentas, alterar configuraciones, administrar servicios o intervenir en otros procesos. Por su alcance, son algunos de los poderes más sensibles dentro del sistema operativo.
Un error clásico consiste en tratarlos como una comodidad para resolver tareas diarias. En realidad, cada privilegio administrativo debería considerarse una excepción controlada y no un atributo normal del trabajo cotidiano.
Una práctica fundamental consiste en separar la cuenta de uso diario de la cuenta administrativa. La cuenta cotidiana sirve para correo, navegación, documentos y tareas habituales. La cuenta administrativa se reserva para acciones de gestión del sistema.
Esta separación reduce riesgos porque evita que cualquier incidente en la actividad diaria herede automáticamente permisos elevados. También mejora la trazabilidad de acciones administrativas y ayuda a limitar el abuso accidental.
No siempre es necesario que un usuario mantenga privilegios elevados de forma permanente. En muchos entornos es más seguro usar modelos de elevación temporal, acceso just-in-time o autorización puntual para tareas específicas.
Este enfoque reduce el tiempo de exposición de privilegios sensibles y permite registrar mejor cuándo se usaron, para qué y bajo qué contexto. Cuanto menos tiempo permanezca activo un acceso poderoso, menor será la superficie disponible para abuso.
Linux y Windows ofrecen mecanismos distintos para elevar privilegios de manera controlada. En Linux, `sudo` permite ejecutar comandos con permisos elevados bajo reglas específicas. En Windows, mecanismos como UAC buscan separar contexto estándar de contexto elevado y pedir confirmación o credenciales cuando una tarea requiere mayor poder.
Estas herramientas no garantizan seguridad por sí solas. Su eficacia depende de cómo se configuran, qué cuentas pueden elevar privilegios y si se revisan regularmente las reglas asociadas.
Las cuentas compartidas son una fuente constante de problemas de seguridad. Cuando varias personas usan la misma identidad, desaparece la trazabilidad individual, se vuelve difícil atribuir acciones y la revocación de acceso se complica enormemente.
Además, las credenciales compartidas tienden a circular por canales inseguros, quedan almacenadas en múltiples lugares y suelen sobrevivir a cambios de personal sin revisión adecuada. En la medida de lo posible, deben evitarse.
La gestión segura de identidades debe contemplar todo el ciclo de vida:
Cuando este ciclo no se gobierna bien, aparecen cuentas huérfanas, grupos obsoletos y privilegios residuales que ya no responden a ninguna necesidad real.
Los momentos de cambio organizacional son especialmente sensibles. Un ingreso apresurado puede crear cuentas con permisos excesivos. Un cambio de puesto puede dejar privilegios antiguos vigentes. Una baja mal gestionada puede conservar acceso a sistemas críticos.
Por eso conviene tener procesos claros para ingreso, movilidad interna y desvinculación. La seguridad de identidad no depende solo de la tecnología; también depende de coordinación entre áreas técnicas, recursos humanos y responsables de cada sector.
Los grupos administrativos, de operadores, de respaldo o de acceso sensible deben revisarse con especial atención. No basta con auditar permisos sobre recursos; también hay que auditar quién está en los grupos que otorgan esos permisos.
Una revisión efectiva debería responder preguntas como:
En entornos complejos es habitual delegar ciertas tareas administrativas. Esa delegación debe estar cuidadosamente acotada. No todos los administradores necesitan poder total, y no todos los operadores deben tener las mismas capacidades.
Delegar bien significa definir alcances, registrar acciones, separar funciones y evitar privilegios excesivos “por si acaso”. El objetivo es que cada rol administrativo tenga exactamente el poder que requiere y no uno superior.
No todo el poder administrativo se presenta como “administrador del sistema”. Existen grupos, capacidades y permisos aparentemente secundarios que permiten modificar rutas de ejecución, alterar configuraciones críticas o acceder a información muy sensible.
Por eso la gestión de privilegios debe ir más allá de revisar solo las cuentas claramente administrativas. También hay que analizar poderes indirectos, membresías heredadas y permisos aparentemente inofensivos que, combinados, pueden facilitar escalamiento.
Cada alta de usuario, cambio de grupo, asignación de privilegio o modificación administrativa relevante debería dejar trazabilidad suficiente. Esto permite investigar incidentes, detectar abusos y reconstruir decisiones que afectan la seguridad del sistema.
La auditoría no debe limitarse al acceso exitoso. También conviene registrar intentos de elevación, cambios rechazados, incorporaciones a grupos sensibles y alteraciones en configuraciones relacionadas con identidad o privilegios.
En Windows, la gestión de grupos y privilegios suele apoyarse en cuentas locales, grupos integrados, Active Directory, políticas de grupo y mecanismos de elevación. En Linux, el foco suele estar en cuentas locales, grupos del sistema, `sudo`, PAM y herramientas de control adicionales.
Aunque la implementación varía, los problemas son muy similares: cuentas administrativas demasiado amplias, membresías sin revisión, accesos persistentes innecesarios y dificultades para distinguir entre identidad, rol y privilegio real.
La mayoría de estos errores no surge por falta de herramientas, sino por falta de disciplina de administración y revisión.
Supongamos una organización donde, para evitar demoras, casi todos los técnicos reciben privilegios administrativos locales y varios usuarios avanzados también pertenecen a grupos elevados. Las tareas se resuelven rápido, pero la superficie de riesgo se dispara.
En ese escenario, una sola cuenta comprometida puede modificar configuraciones críticas, instalar software malicioso, desactivar controles o moverse lateralmente con facilidad. La aparente eficiencia operativa termina generando una debilidad estructural.
Responder estas preguntas ayuda a transformar la gestión de identidades en una práctica continua de reducción de riesgo.
Administrar usuarios, grupos y privilegios administrativos es una de las tareas más sensibles dentro de la seguridad de sistemas operativos. De su calidad depende buena parte del control real que la organización tiene sobre su propia infraestructura.
En el próximo tema se estudiará la seguridad del sistema de archivos, el cifrado y la protección de datos, para avanzar desde la administración de identidades hacia la defensa de uno de los activos más valiosos del entorno: la información almacenada.