Tema 4
En esta unidad se estudia cómo el sistema operativo identifica a los sujetos que acceden, cómo valida su identidad y cómo debe proteger las credenciales que permiten entrar al entorno. Las cuentas y la autenticación constituyen uno de los puntos más explotados en incidentes reales y, por eso, merecen un tratamiento riguroso.
En muchos incidentes de seguridad no se necesita explotar una vulnerabilidad compleja del kernel ni comprometer directamente un servicio técnico. Basta con obtener credenciales válidas. Si un atacante consigue usuario y contraseña, una clave privada, un token de acceso o una sesión activa, puede ingresar al sistema con apariencia legítima.
Por eso las cuentas de usuario y sus credenciales deben ser vistas como activos de alto valor. Una credencial comprometida no solo afecta a quien la posee, sino también a todos los recursos a los que esa identidad puede acceder. En entornos corporativos, el robo de una sola cuenta privilegiada puede desencadenar incidentes de gran alcance.
Una cuenta de usuario es una identidad reconocida por el sistema operativo. Permite asociar acciones, permisos, configuración, historial de acceso y recursos a un sujeto determinado. Aunque muchas veces se piensa en personas, una cuenta también puede representar servicios, procesos automáticos, tareas programadas o integraciones entre sistemas.
Desde la seguridad, lo importante es que cada cuenta introduce una relación entre identidad y capacidad de acción. El sistema necesita saber quién es el sujeto, qué puede hacer y cómo se registran sus acciones. Sin cuentas bien gestionadas, no hay trazabilidad ni control efectivo.
No todas las cuentas cumplen la misma función. Diferenciarlas correctamente es esencial para aplicar controles adecuados.
| Tipo de cuenta | Uso principal | Riesgo si se gestiona mal |
|---|---|---|
| Cuenta personal | Uso diario de un usuario humano | Acceso indebido a información, movimientos laterales, suplantación |
| Cuenta administrativa | Tareas de gestión del sistema | Control total del equipo o del entorno |
| Cuenta de servicio | Ejecución de aplicaciones o servicios automáticos | Persistencia silenciosa, abuso de permisos elevados |
| Cuenta temporal | Accesos por soporte, pruebas o terceros | Olvido de desactivación, acceso residual |
| Cuenta compartida | Uso por varias personas | Pérdida de trazabilidad y de responsabilidad individual |
Una práctica segura exige minimizar cuentas innecesarias, evitar cuentas compartidas y separar claramente el uso cotidiano del uso administrativo.
Estos tres conceptos están estrechamente relacionados, pero no son equivalentes:
Un sistema puede autenticar correctamente una cuenta y, sin embargo, ser inseguro si esa cuenta posee permisos excesivos. Del mismo modo, puede tener una buena política de permisos, pero fallar si la autenticación es débil. Por eso la seguridad del acceso depende de tratar estas capas como un conjunto.
La autenticación suele basarse en una o varias pruebas de identidad. Tradicionalmente se agrupan en categorías:
Combinar factores independientes mejora considerablemente la seguridad. Esto es lo que da origen a la autenticación multifactor, una de las defensas más efectivas frente al robo de credenciales.
Las contraseñas siguen siendo uno de los mecanismos más extendidos, pero también uno de los más débiles cuando se gestionan mal. El problema no es solo técnico. Muchas personas reutilizan claves, eligen combinaciones predecibles, las comparten entre servicios o las almacenan en lugares inseguros.
En sistemas operativos, una contraseña comprometida puede abrir acceso local, remoto o lateral. Por eso la política de contraseñas debe contemplar longitud, unicidad, resistencia al guessable passwording, protección frente a reutilización y mecanismos seguros de cambio y recuperación.
La calidad de una contraseña no depende solo de su complejidad visual. También depende de si fue expuesta, reutilizada o elegida a partir de patrones fáciles de adivinar.
Un sistema operativo o un servicio no debería almacenar contraseñas en texto plano. La práctica correcta consiste en almacenar representaciones derivadas mediante funciones diseñadas para resistir ataques de cracking, idealmente con sal y parámetros adecuados de costo.
Desde la seguridad operativa importa comprender que una contraseña bien elegida pierde valor si el sistema la guarda de forma insegura. La protección de credenciales no se limita al momento del ingreso; también incluye su tratamiento interno, su transmisión y sus copias de respaldo.
La autenticación multifactor, o MFA, exige al menos dos factores distintos para validar la identidad. Su ventaja principal es que reduce el valor de una contraseña robada. Aunque el atacante obtenga una clave por phishing, fuga o reutilización, todavía necesita superar un segundo control.
No todas las variantes de MFA ofrecen el mismo nivel de protección. Los códigos por SMS, por ejemplo, pueden ser mejores que nada, pero presentan riesgos conocidos. Las aplicaciones autenticadoras, llaves físicas y mecanismos resistentes al phishing suelen ofrecer mejores garantías.
Una vez autenticado, el usuario no suele ingresar su contraseña en cada acción. El sistema crea una sesión o emite un token que representa el estado autenticado. Esa sesión también debe protegerse, porque si un atacante la roba puede evitar el paso de autenticación inicial.
Esto es relevante tanto en sistemas locales como en accesos remotos, aplicaciones conectadas o entornos federados. La seguridad de la autenticación no termina con el login; continúa durante toda la vida de la sesión.
Las cuentas administrativas permiten cambiar configuraciones, instalar software, modificar permisos, gestionar usuarios y, en muchos casos, desactivar controles de seguridad. Por eso requieren medidas especiales de protección.
Entre las prácticas más importantes se encuentran:
Las cuentas de servicio suelen pasar desapercibidas porque no representan a personas visibles, pero pueden tener permisos elevados y funcionar de manera continua. Si sus credenciales están embebidas en scripts, configuraciones o tareas automatizadas, se convierten en un vector de alto riesgo.
Una gestión madura exige rotación controlada, almacenamiento seguro de secretos, mínimo privilegio y monitoreo específico. Las cuentas de servicio no deben quedar fuera del modelo de identidad solo porque no inician sesión de forma interactiva.
Cuando el acceso ocurre por RDP, SSH, VPN, consolas remotas o herramientas de administración, el riesgo aumenta porque la superficie de exposición es mayor. En estos escenarios conviene reforzar la autenticación, restringir orígenes, limitar intentos fallidos y usar mecanismos resistentes al robo de credenciales.
Muchos incidentes comienzan por accesos remotos mal protegidos: contraseñas débiles, cuentas expuestas a Internet, falta de MFA o puertos abiertos sin controles adicionales.
Una cuenta no debe existir para siempre por defecto. El ciclo de vida de identidad incluye creación, uso, revisión, suspensión y eliminación o desactivación. Las cuentas que ya no cumplen una función son una carga de riesgo innecesaria.
Esto aplica especialmente a usuarios que cambiaron de rol, proveedores que ya no trabajan con la organización, cuentas de pruebas y accesos temporales. La higiene de cuentas es una medida básica pero muy efectiva.
Todo sistema necesita mecanismos para recuperar acceso cuando un usuario olvida su contraseña o pierde un factor de autenticación. Sin embargo, estos procesos deben ser tan seguros como el acceso mismo. Si la recuperación es débil, se convierte en una vía alternativa de intrusión.
Las preguntas de seguridad triviales, los correos de recuperación sin protección o los procedimientos de soporte sin validación fuerte pueden anular el valor del resto de los controles.
La identidad no solo sirve para permitir acceso. También permite saber quién hizo qué. Si varias personas usan la misma cuenta o si el sistema no registra adecuadamente eventos de autenticación y cambios sensibles, se pierde capacidad de atribución.
Esto afecta tanto a la seguridad como a la auditoría. Sin responsabilidad individual, investigar un incidente se vuelve más difícil, detectar abuso interno es más complejo y la disciplina operativa se debilita.
La mayoría de estos riesgos no se soluciona con una sola herramienta. Requieren políticas, hábitos de administración y controles complementarios.
Windows y Linux gestionan identidades de manera distinta, pero comparten desafíos similares. En Windows suele destacarse la integración con dominios, políticas de grupo y credenciales centralizadas. En Linux tienen mucho peso las cuentas locales, el modelo de permisos, SSH, sudo y herramientas de endurecimiento adicionales.
En ambos casos hay preguntas críticas: dónde se almacenan las credenciales, cómo se protegen los accesos administrativos, cómo se registran los eventos de autenticación y qué mecanismos existen para reducir el abuso de identidad.
Supongamos una organización que separa cuentas administrativas de cuentas normales, pero no aplica MFA, mantiene contraseñas reutilizadas y conserva cuentas de antiguos empleados activas. Aunque el modelo aparente ser razonable, la autenticación sigue siendo débil.
Este ejemplo muestra una idea importante: tener cuentas diferenciadas no basta. La seguridad real depende de cómo se protegen las credenciales, cómo se revisa su vigencia y cómo se limita el valor operativo de cada identidad.
Estas preguntas ayudan a pasar de una visión estática de “usuarios y contraseñas” a una visión de seguridad de identidad mucho más completa.
La seguridad de un sistema operativo depende en gran medida de cómo identifica a los sujetos y cómo protege los medios con los que esos sujetos acceden. Una autenticación débil o una gestión descuidada de credenciales pueden anular controles técnicos muy sofisticados.
En el próximo tema se estudiarán la autorización, los permisos, las ACL y el principio de mínimo privilegio, para profundizar en lo que ocurre después de la autenticación: qué puede hacer realmente cada identidad dentro del sistema.