NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
Linuxtopia - CentOS Enterprise Linux 4: Introduccion a la administracion de sistemas - Administraci�n de cuentas de usuarios y acceso a recursos
Red Hat Enterprise Linux 4: Introducci�n a la administraci�n de sistemas
Cap�tulo 6. Administraci�n de cuentas de usuarios y acceso a recursos
La administraci�n de cuentas de usuario y grupos es una parte esencial de la administraci�n de sistemas dentro de una organizaci�n. Pero para hacer esto efectivamente, un buen administrador de sistemas primero debe entender lo que son las cuentas de usuario y los grupos y como funcionan.
La raz�n principal para las cuentas de usuario es verificar la identidad de cada individuo utilizando un computador. Una raz�n secundaria (pero a�n importante) es la de permitir la utilizaci�n personalizada de recursos y privilegios de acceso.
Los recursos incluyen archivos, directorios y dispositivos. El control de acceso a estos dispositivos forma una gran parte de la rutina diaria de un administrador de sistemas; a menudo el acceso a un recurso es controlado por grupos. Los grupos son construcciones l�gicas que se pueden utilizar para enlazar a usuarios para un prop�sito com�n. Por ejemplo, si una organizaci�n tiene varios administradores de sistemas, todos ellos se pueden colocar en un grupo administrador de sistema. Luego se le pueden dar permisos al grupo para acceder a recursos claves del sistema. De esta forma, los grupos pueden ser una herramienta poderosa para la administraci�n de recursos y acceso.
Las secciones siguientes discuten las cuentas de usuario y grupos en m�s detalles.
6.1. Administraci�n de cuentas de usuarios
Como se indic� anteriormente, las cuentas de usuarios es la forma a trav�s de la cual se identifica y autentifica a un individuo con el sistema. Las cuentas de usuarios tienen diferentes componentes. Primero, esta el nombre de usuario. Luego, est� la contrase�a, seguida de la informaci�n de control de acceso.
Las secciones siguientes exploran cada uno de estos componentes en m�s detalles.
6.1.1. El nombre de usuario
Desde el punto de vista del sistema, el nombre de usuario es la respuesta a la pregunta "qui�n es usted?". Como tal, los nombres de usuarios tienen un requerimiento principal — deben ser �nicos. En otras palabras, cada usuario debe tener un nombre de usuario que sea diferente a todos los otros usuarios en ese sistema.
Debido a este requerimiento, es vital determinar — por adelantado — c�mo se crean los nombres de usuario. De lo contrario, puede encontrarse en la posici�n de ser forzado a reaccionar cada vez que un nuevo usuario solicita una cuenta.
Lo que necesita es una convenci�n de nombres para sus cuentas de usuarios.
6.1.1.1. Convenio de nombres
Mediante la creaci�n de un convenio de nombres para los usuarios, puede ahorrarse varios problemas. En vez de inventar nombres cada vez (y darse cuenta de que cada vez se hace m�s dif�cil crear un nombre razonable), haga un poco de trabajo de antemano para preparar una convenci�n a utilizar para todas las cuentas siguientes. Su convenio de nombres puede ser muy simple, o solamente su descripci�n puede tomar muchas p�ginas.
La naturaleza exacta de su convenio de nombres debe tomar varios factores en cuenta:
El tama�o de su organizaci�n
La estructura de su organizaci�n
La naturaleza de su organizaci�n
El tama�o de su organizaci�n importa, pues dicta cu�ntos usuarios puede soportar su convenci�n para nombres. Por ejemplo, una compa��a muy peque�a quiz�s pueda permitir que todo el mundo utilice su primer nombre. Para una organizaci�n mucho m�s grande, este convenio no funciona.
La estructura de la organizaci�n tambi�n puede tener influencia sobre el convenio de nombres m�s apropiado. Para organizaciones con una estructura bien definida puede ser adecuado incluir elementos de esa estructura en la convenci�n de nombres. Por ejemplo, puede incluir los c�digos de los departamentos como parte del nombre de usuario.
La naturaleza completa de su organizaci�n tambi�n puede significar que algunas convenciones son m�s apropiadas que otras. Una organizaci�n que maneja datos confidenciales puede decidirse por una convenici�n que no indica ning�n tipo de informaci�n personal que pueda vincular al individuo con su nombre. En una organizaci�n de este tipo, el nombre de usuario de Maggie McOmie podr�a ser LUH3417.
He aqu� algunas convenciones de nombres que otras organizaciones han utilizado:
Primer nombre (jorge, carlos, pedro, etc.)
Apellido (perez, obregon, ramirez, etc)
Primera inicial, seguido del apellido (jperez, cobregon, pramirez, etc.)
Apellido, seguido del c�digo del departamento (perez029, obregon454, ramirez191, etc.)
Sugerencia
Tenga en cuenta que si su convenci�n de nombres incluye a�adir datos diferentes para formar un nombre de usuario, existe el potencial de que el resultado sea gracioso u ofensivo. Por lo tanto, a�n si crea los nombres de usuario de forma autom�tica, es recomendable que lleve a cabo alguna forma de revisi�n.
Una cosa com�n con la convenci�n de nombres descrita aqu� es que es posible que eventualmente existan dos individuos que, de acuerdo a la convenci�n, obtendr�an el mismo nombre de usuario. Esto se conoce como una colisi�n.
6.1.1.1.1. Manejar colisione
Las colisiones son un hecho — no importa cuanto lo intente, eventualmente se encontrar� tratando con colisiones. Debe planear para las colisiones en su convenci�n de nombres. Hay muchas formas de hacer esto:
A�adiendo n�meros en secuencia al nombre de usuario en colisi�n (perez, perez1, perez2, etc.)
A�adiendo datos espec�ficos al usuario al nombre de usuario en colisi�n (perez, eperez, ekperez, etc.)
A�adiendo informaci�n adicional de la organizaci�n al nombre de usuario (perez, perez029, perez454, etc.)
Es necesario tener un m�todo para resolver las colisiones como parte de cualquier convenci�n de nombres. Sin embargo, hace m�s dificil para alguien fuera de la organizaci�n determinar el nombre de usuario de un individuo. Por lo tanto, la desventaja de las convenciones de nombres es que hace m�s probable el envio de correos electr�nicos a las direcciones equivocadas.
6.1.1.2. Manejo de cambios de nombres
Si su organizaci�n utiliza una convenci�n de nombres que est� basada en el nombre de cada usuario, es de esperarse que eventualmente tendr� que enfrentarse a cambios de nombres. A�n si el nombre de la persona realmente no cambia, de vez en cuando se le pedir� que modifique el nombre de usuario. Las razones pueden variar desde un usuario que no le gusta su nombre de usuario hasta un empleado con m�s jerarqu�a en la organizaci�n que prefiere un nombre de usuario "m�s acorde".
No importa cual sea la raz�n, hay muchos aspectos a tener en mente cuando se cambie un nombre de usuario:
Efectue el cambio en todos los sistemas afectados
Mantenga constante toda la informaci�n subyacente del usuario
Cambien la propiedad de todos los archivos y otros recursos espec�ficos al usuario (si es necesario)
Maneje los problemas relacionados con el correo electr�nico
Primero que nada, es importante asegurarse de que el nuevo nombre de usuario es propagado a todos los sistemas donde se utilizaba el nombre original. De lo contrario, cualquier funci�n del sistema operativo que est� vinculado con el nombre de usuario, funcionar� en algunos sistemas y en otros no. Ciertos sistemas operativos utilizan t�cnicas de control de acceso basadas en nombres de usuarios; tales sistemas son paticularmente vulnerables a problemas derivados de un cambio de nombre de usuario.
Muchos sistemas operativos utilizan alg�n tipo de n�mero de identificaci�n de usuarios para la mayor�a de los procesamientos espec�ficos al usuario. Para minimizar los problemas generados a partir de un cambio de nombre de usuario, trate de mantener este n�mero de identificaci�n constante entre el nuevo y el viejo nombre de usuario. Si no se hace esto, puede producir un escenario en el que el usuario ya no puede acceder a sus archivos y otros recursos que ellos pose�an anteriormente bajo el nombre de usuario original.
Si se debe cambiar el n�mero de identificaci�n del usuario, es necesario cambiar la propiedad para todos los archivos y recursos espec�ficos al usuario para reflejar la nueva identificaci�n del usuario. Este puede ser un proceso muy susceptible a errores, ya que pareciera que siempre hay algo en alguna esquina olvidada del sistema que se ignora al final.
Los problemas relacionados al correo electr�nico probablemente sean donde el cambio de un nombre de usuario es m�s dif�cil. La raz�n para esto es que a menos que se tomen las medidas para evitarlo, los correos electr�nicos dirigidos al viejo nombre de usuario no se entregaran al nuevo.
Lamentablemente, los problemas alrededor del impacto de los cambios de nombres de usuario en el correo electr�nico tienen m�ltiples dimensiones. En su forma m�s b�sica, un cambio de nombre de usuario implica que la gente ya no conoce el nombre de usuario correcto de esa persona. A primera vista, esto puede parecer como que no es gran cosa — notificar a todo el mundo en su organizaci�n. Pero que hay de las personas fuera de la organizaci�n que han enviado correo a esta persona? �C�mo se les deber�a notificar?�Qu� hay de las listas de correo (tanto internas como externas)? �C�mo se pueden actualizar?
No hay una respuesta f�cil a esta pregunta. La mejor respuesta puede ser la de crear un alias para el correo electr�nico de manera que todo el correo enviado al viejo nombre de usuario sea redirigido al nuevo nombre. Se le puede indicar al usuario que debe alertar a todas las personas que su nombre de usuario ha sido modificado. A medida que el tiempo pasa, menos y menos mensajes ser�n entregados usando el alias y eventualmente podr� eliminarlo.
Mientras que el uso de alias, a cierto nivel, continua la asunci�n incorrecta (de que el usuario conocido ahora como mperez todav�a se conoce como jperez), es la �nica forma de garantizar que el correo llegue a la persona adecuada.
Importante
Si utiliza un alias para el correo electr�nico, asegurese de tomar todos los pasos necesarios para proteger el viejo nombre de usuario de un reuso potencial. Si no hace esto y un nuevo usuario recibe el viejo nombre de usuario, la entrega de correo (tanto para el usuario original como para el nuevo) ser� interrumpida. La naturaleza exacta de la interrupci�n depende de c�mo se implementa la entrega de correo en su sistema operativo, pero los dos s�ntomas m�s probables son:
El nuevo usuario nunca recibe ning�n correo - todo se va al usuario original.
Repentinamente el usuario original deja de recibir correo - todo se va al nuevo usuario.
6.1.2. Contrase�as
Si el nombre de usuario responde a la pregunta "�Qui�n es usted?", la contrase�a es la respuesta a la pregunta que inevitablemente sigue:
"Demu�stralo!"
En t�rminos m�s pr�cticos, una contrase�a proporciona una forma de probar la autenticidad de la persona que dice ser el usuario con ese nombre de usuario. La efectividad de un esquema basado en contrase�as recae en gran parte sobre varios aspectos de la contrase�a:
La confidencialidad de la contrase�a
La resistencia de adivinar la contrase�a
La resistencia de la contrase�a ante un ataque de fuerza bruta
Las contrase�as que efectivamente toman en cuenta estos problemas se conocen como contrase�as robustas, mientras que aquellas que no, se les llama d�biles. Es importante para la seguridad de la organizaci�n crear contrase�as robustas, mientras m�s robustas sean las contrase�as, hay menos chances de que estas sean descubiertas o que se adivinen. Hay dos opciones disponibles para reforzar el uso de contrase�as robustas:
El administrador del sistema puede crear contrase�as para todos los usuarios.
El administrador del sistema puede dejar que los usuarios creen sus propias contrase�as, a la vez que se verifica que las contrase�as sean lo suficientemente robustas.
Al crear contrase�as para todos los usuarios asegura que estas sean robustas, pero se vuelve una tarea pesada a medida que crece la organizaci�n. Tambi�n incrementa el riesgo de que los usuarios escriban sus contrase�as.
Por estas razones, la mayor�a de los administradores de sistemas prefieren dejar que los usuarios mismos creen sus contrase�as. Sin embargo, un buen administrador de sistemas tomar� los pasos adecuados para verificar que las contrase�as sean robustas.
Para leer sobre las pautas para la creaci�n de contrase�as robustas, vea el cap�tulo llamado Seguridad de las Estaciones de trabajo en el Manual de seguridad de Red Hat Enterprise Linux.
La necesidad de mantener secretas las contrase�as deber�a ser una parte arraigada en la mente de un administrador de sistemas. Sin embargo, este punto se pierde con frecuencia en muchos usuarios. De hecho, muchos usuarios ni siquiera entienden la diferencia entre nombres de usuarios y contrase�as. Dado este hecho, es de vital importancia proporcionar cierta cantidad de educaci�n para los usuarios, para que as� estos puedan entender que sus contrase�as se deber�an mantener tan secretas como su sueldo.
Las contrase�as deber�an ser tan dif�ciles de adivinar como sea posible. Una contrase�a robusta es aquella que un atacante no podr� adivinar, a�n si el atacante conoce bien al usuario.
Un ataque de fuerza bruta sobre una contrase�a implica el intento met�dico (usualmente a trav�s de un programa conocido como password-cracker) de cada combinaci�n de caracteres posible con la esperanza de que se encontrar� la contrase�a correcta eventualmente. Una contrase�a robusta se deber�a construir de manera tal que el n�mero de contrase�as potenciales a probar sea muy grande, forzando al atacante a tomarse un largo tiempo buscando la contrase�a.
Las contrase�as d�biles y robustas se exploran con m�s detalles en las secciones siguientes.
6.1.2.1. Contrase�as d�biles
Como se estableci� anteriormente, una contrase�a d�bil es una que no pasa alguna de estas tres pruebas:
Es secreta
Es resistente a ser adivinada
Es resistente a un ataque de fuerza bruta
Las secciones siguientes muestran c�mo pueden ser d�biles las contrase�as.
6.1.2.1.1. Contrase�as cortas
Una contrase�a corta es d�bil porque es mucho m�s susceptible a un ataque de fuerza bruta. Para ilustrar esto, considere la tabla siguiente, en el que se muestran el n�mero de contrase�as potenciales que deben ser evaluadas en un ataque de fuerza bruta. (Se asume que las contrase�as consisten solamente de letras en min�sculas.)
Largo de la contrase�a
Contrase�as potenciales
1
26
2
676
3
17,576
4
456,976
5
11,881,376
6
308,915,776
Tabla 6-1. El largo de la contrase�a contra el n�mero de contrase�as potenciales
Como puede ver, el n�mero de contrase�as posibles incrementa dram�ticamente a medida que se incrementa el largo.
Nota
A�n cuando esta tabla termina en seis caracteres, esto no se deber�a tomar como que se recomienda contrase�as de seis caracteres de largo como lo suficientemente largas para una buena seguridad. En general, mientras m�s larga la contrase�a mejor.
6.1.2.1.2. Conjunto de car�cteres limitado
El n�mero de car�cteres diferentes que comprenden una contrase�a tiene un gran impacto en la habilidad de un atacante de conducir un ataque de fuerza bruta. Por ejemplo, en vez de 26 car�cteres diferentes que se pueden utilizar en una contrase�a de solamente min�sculas, que tal si usamos n�meros? Esto significa que cada car�cter en una contrase�a es uno de 36 en vez de uno de 26. En el caso de contrase�as de seis caracteres de largo, esto representa un incremento de contrase�as posibles de 308,915,776 a 2,176,782,336.
A�n hay m�s que se puede hacer. Si tambi�n inclu�mos contrase�as alfanum�ricas con may�sculas y min�sculas (para aquellos sistemas operativos que lo soporten), el n�mero posible de contrase�as de seis car�cteres se incrementa a 56,800,235,584. A�adiendo otros caracteres (tales como s�mbolos de puntuaci�n) aumenta a�n m�s los n�meros posibles, haciendo un ataque de fuerza bruta mucho m�s dif�cil.
Sin embargo, un punto a tener en mente es que no todos los ataques contra una contrase�a son de fuerza bruta. Las secciones siguientes describen otros atributos que pueden hacer una contrase�a d�bil.
6.1.2.1.3. Palabras reconocibles
Muchos ataques contra contrase�as est�n basados en el hecho de que la gente generalmente se siente m�s c�moda con contrase�as que pueden recordar. Y para la mayor�a de la gente, las contrase�as m�s f�ciles de recordar son las que contienen palabras. Por lo tanto, muchos ataques a contrase�as est�n basados en el diccionario. En otras palabras, el atacante utiliza diccionarios de palabras en un intento de encontrar la palabra o palabras que forman la contrase�a.
Nota
Muchos programas de ataque a contrase�as basados en diccionario utilizan diccionarios de diferentes idiomas. Por lo tanto, no piense que su contrase�a es m�s robusta simplemente porque est� utilizando una palabra que no es en Espa�ol.
6.1.2.1.4. Informaci�n personal
Las contrase�as que contienen informaci�n personal (el nombre o fecha de nacimiento de un ser querido, una mascota o un n�mero de identificaci�n personal) puede o puede que no sean encontradas a trav�s de un ataque basado en contrase�as de diccionario. Sin embargo, si el atacante lo conoce personalmente (o est� lo suficientemente motivado para investigar su vida personal), puede ser capaz de adivinar su contrase�a con poca o ninguna dificultad.
Adem�s de los diccionarios, muchos descifradores de contrase�as tambi�n incluyen nombres comunes, fechas y otro tipo de informaci�n en su b�squeda de contrase�as. Por lo tanto, a�n si el atacante no conoce que el nombre de su perro es Howard, todav�a pueden descubrir que su contrase�a es "MiperrosellamaHoward", con un buen descifrador de contrase�as.
6.1.2.1.5. Trucos simples de palabras
Usando cualquiera de la informaci�n discutida anteriormente como la base para una contrase�a, pero invirtiendo el orden de las letras, tampoco hace una contrase�a d�bil en una robusta. La mayor�a de los descifradores de contrase�as hacen estos trucos en todas las contrase�as posibles. Esto incluye sustituir cierto n�meros por letras en palabras comunes. He aqu� algunos ejemplos:
drowssaPdaB1
R3allyP00r
6.1.2.1.6. La misma palabra para m�ltiples sistemas
A�n si su contrase�a es robusta, no es una buena idea utilizar la misma contrase�a en m�s de un sistema. Obviamente se puede hacer muy poco si los sistemas son configurados para utilizar un servidor central de alg�n tipo, pero en cualquier otro caso, se deben utilizar contrase�as diferentes para sistemas diferentes.
6.1.2.1.7. Contrase�as en papel
Otra forma de hacer una contrase�a robusta en una d�bil es escribi�ndola. Al colocar su contrase�a en papel, ya usted no tiene un problema de confidencialidad, pero de seguridad f�sica - ahora usted debe mantener seguro ese pedazo de papel. Esto obviamente no es una buena idea.
Sin embargo, algunas organizaciones tienen una necesidad leg�tima para escribir contrase�as. Por ejemplo, algunas organizaciones tienen contrase�as escritas como parte de un procedimiento para recuperarse de la p�rdida de un empleado clave (tales como un administrador de sistemas). En estos casos, el papel conteniendo las contrase�as es almacenado en una ubicaci�n f�sicamente segura que requiere la cooperaci�n de varias personas para tener acceso al papel. Usualmente se utilizan cajas de seguridad acorazadas y con m�tiples cerrojos.
Cualquier organizaci�n que explore este m�todo de almacenar contrase�as para prop�sitos de emergencia debe estar consciente de que la existencia de contrase�as escritas a�ade un elemento de riesgo a la seguridad de sus sistemas, no importa cuan seguro sea el almacenamiento de las contrase�as. Esto es particularmente cierto si es de conocimiento general que las contrase�as se encuentran escritas (y donde se encuentran).
Lamentablemente, a menudo las contrase�as escritas no forman parte de un plan de recuperaci�n y no son almacenadas en una b�veda, y estas son las contrase�as de los usuarios comunes y son almacenadas en sitios como:
En la gaveta (cerrada con llave o no)
Bajo el teclado
En la cartera
Pegada al lado del monitor
Ninguna de estas ubicaciones son lugares apropiados para una contrase�a escrita.
6.1.2.2. Contrase�as robustas
Hemos visto c�mo son las contrase�as d�biles; las secciones siguientes describen funcionalidades que todas las contrase�as robustas tienen.
6.1.2.2.1. Contrase�as largas
Mientras m�s larga la contrase�a, menos es la probabilidad de que tenga �xito un ataque de fuerza bruta. Por lo tanto, si su sistema operativo lo soporta, establezca un largo m�nimo para las contrase�as de sus usuarios relativamente largo.
6.1.2.2.2. Conjunto de caracteres expandido
Promocione el uso de contrase�as alfanum�ricas que combinen el uso de may�sculas y min�sculas y m�s a�n, anime la adici�n de un car�cter no-alfanum�rico a todas las contrase�as:
t1Te-Bf,te
Lb@lbhom
6.1.2.2.3. Memorizables
Una contrase�a es robusta solamente si se puede recordar. Sin embargo, usualmente el ser f�cil de memorizar y f�cil de adivinar a menudo van juntos. Por lo tanto, dele a su comunidad de usuarios algunos consejos sobre la creaci�n de contrase�as f�ciles de recordar pero que no sean f�ciles de adivinar.
Por ejemplo, tome una frase favorita o dicho y utilice las primeras letras de cada palabra como el punto de comienzo para la creaci�n de la nueva contrase�a. El resultado es f�cil de memorizar (pues la frase en la cual est� basado es, en s� misma, recordable), sin embargo el resultado no contiene ninguna palabra.
Nota
Tenga en cuenta que el usar las primeras letras de cada palabra en una frase no es suficiente para crear una contrase�a robusta. Siempre aseg�rese de incrementar el conjunto de caracteres incluyendo la combinaci�n de car�cteres alfanum�ricos y tambi�n al menos un car�cter especial.
6.1.2.3. Caducidad de las contrase�as
Si es posible implemente per�odos de vigencia para las contrase�as. La caducidad de las contrase�as es una funcionalidad (disponible en muchos sistemas operativos) que coloca l�mites en el tiempo que una contrase�a dada es considerada v�lida. Al final del tiempo de vida de la contrase�a, se le pide al usuario que introduzca una nueva contrase�a, que se puede utilizar hasta que, igualmente, expire.
La pregunta clave con respecto a la caducidad de las contrase�as con la que se enfrentan muchos administradores de sistemas es sobre el tiempo de vida de una contrase�a: �Cu�l es el m�s adecuado?
Hay dos problemas diametricalmente opuestos con respecto al tiempo de vida de las contrase�as:
Conveniencia del usuario
Seguridad
Por un lado, un tiempo de vida de una contrase�a de 99 a�os presentar� muy pocos problemas (si es que llega a presentar alguno). Sin embargo, proporcionar� muy poco en t�rminos de mejorar la seguridad.
En el otro extremo, un tiempo de vida de una contrase�a de 99 minutos ser� un gran inconveniente para los usuarios. Sin embargo, la seguridad mejorar� en extremo.
La idea es encontrar un balance entre la conveniencia para sus usuarios y la necesidad de seguridad de su organizaci�n. Para la mayor�a de las organizaciones, los tiempos de vida de las contrase�as dentro del rango de semanas - meses, son los m�s comunes.
6.1.3. Informaci�n de control de acceso
Junto con un nombre de usuario y contrase�a, las cuentas de usuario tambi�n contienen informaci�n de acceso. Esta informaci�n toma formas diferentes de acuerdo al sistema operativo utilizado. Sin embargo, los tipos de informaci�n a menudo incluyen:
Identificaci�n espec�fica al usuario global al sistema
Identificaci�n espec�fica al grupo global al sistema
Lista de los grupos/capacidades adicionales a los cuales el usuario es miembro
Informaci�n de acceso por defecto a aplicar para todos los archivos y recursoscreados por el usuario
En algunas organizaciones, la informaci�n de control de acceso quiz�s nunca se necesite tocar. Este caso es m�s frecuente con estaciones de trabajo personales y sistemas independientes, por ejemplo. Otras organizaciones, particularmente aquellas que hacen uso extensivo de los recursos compartidos a los largo de la red entre diferentes grupos de usuarios, requieren que la informaci�n de control de acceso se modifique con frecuencia.
La carga de trabajo requerida para mantener apropiadamente la informaci�n de control de acceso de sus usuarios var�a de acuerdo a cuan intensivamente su organizaci�n utiliza las funcionalidades de control de acceso. Mientras que no esta mal contar con estas funcionalidades (de hecho, quiz�s sea inevitable), implica que su entorno de sistema puede requerir m�s esfuerzo para ser mantenido y que cada cuenta de usuario pueda tener m�s formas en las cuales pueda ser mal configurada.
Por lo tanto, si su organizaci�n requiere de este tipo de entorno, deber�a documentar los pasos exactos requeridos para crear y correctamente configurar una cuenta de usuario. De hecho, si hay diferentes tipos de cuentas de usuario, deber�a documentar cada una (creando una nueva cuenta de usuario de finanzas, una nueva cuenta de usuario de operaciones, etc.).
6.1.4. Administraci�n d�a a d�a de cuentas y acceso a recursos
Como dice el viejo dicho, lo �nico constante es el cambio. Es lo mismo cuando se trata de su comunidad de usuarios. Gente viene, se v� y tambi�n hay gente que se mueve de un grupo de responsabilidades a otro. Por lo tanto, los administradores de sistemas deben ser capaces de responder a los cambios que son una parte normal de la vida diaria de su organizaci�n.
6.1.4.1. Nuevos empleados
Cuando una nueva persona entra a la organizaci�n, normalmente se les da acceso a varios recursos (dependiendo de sus responsabilidades). Quiz�s se les facilite un lugar para trabajar, un tel�fono y una llave para la puerta de entrada.
Probablemente tambi�n se les da acceso a uno o m�s computadoras en su organizaci�n. Como administrador del sistema, es su responsabilidad verificar que esto se haga r�pidamente y de la forma adecuada. �C�mo hacerlo?
Antes de hacer algo, primero debe estar al tanto de la llegada de la nueva persona. Esto se maneja de diferentes formas en varias organizaciones. He aqu� algunas posibilidades:
Cree un procedimiento donde el departamento de personal de su organizaci�n le notifica cuando llega una nueva persona.
Cree una forma que el supervisor de la nueva persona debe llenar y utilizar para solicitar la creaci�n de una cuenta de usuario.
Diferentes organizaciones tienen enfoques diferentes. No importa como se lleve a cabo, es vital que tenga un procedimiento confiable que pueda alertar de cualquier trabajo relacionado a las cuentas que se necesite hacer.
6.1.4.2. Terminaciones
Es conocido el hecho de que habr� personas que dejen la organizaci�n. Algunas veces esto puede ser bajo circunstancias felices y otras quiz�s no tan felices. En cualquier caso, es vital que se le informe de la situaci�n para que as� pueda tomar las acciones adecuadas.
Como m�nimo, las acciones apropiadas deben incluir:
Inhabilitar el acceso del usuario a todos los sistemas y recursos relacionados (usualmente mediante el cambio o bloqueo de la contrase�a)
Hacer una copia de seguridad de los archivos del usuario, en caso de que contengan algo que se pueda necesitar en un futuro.
Coordinar el acceso a los archivos del usuario para el supervisor
La principal prioridad es asegurar sus sistemas contra un usuario que ha dejado de trabajar con la organizaci�n recientemente. Esto es particularmente importante si el usuario fue terminado bajo condiciones que pueden haberlo dejado con un poco de malicia hacia la organizaci�n. Sin embargo, a�n si las circunstancias no son tan graves, le conviene a la organizaci�n desactivar r�pidamente el acceso a una persona que ya no pertenece a la compa��a.
Esto indica la necesidad de un proceso que lo alerte sobre las terminaciones - preferiblemente antes de que estas sean efectivas. Esto implica que usted deber�a trabajar con el departamento de personal de su organizaci�n para asegurarse de que se le notifique sobre cualquier terminaci�n futura.
Sugerencia
Cuando se manejen los "bloqueos" en respuesta a una liquidaci�n, es de suma importancia que las cosas se hagan en el momento correcto. Si el bloqueo ocurre despu�s de completarse el proceso de liquidaci�n, hay potencial para el acceso no autorizado de la persona recientemente terminada. Por otro lado, si el bloqueo ocurre antes de que se inicie el proceso de liquidaci�n, esto puede alertar a la persona sobre el despido inminente y hacer el proceso m�s dif�cil para ambas partes.
El proceso de liquidaci�n usualmente se inicia a trav�s de una reuni�n entre la persona a ser liquidada, el supervisor de la persona y un representante del departamento de personal de la organizaci�n. Por lo tanto, establecer un proceso que lo alerte sobre cuando esta reuni�n comenzar� le dar� las indicaciones sobre el momento correcto para hacer el bloqueo.
Una vez desactivado el acceso, es el momento para hacer una copia de seguridad de los archivos de esta persona. Este respaldo puede ser parte de los respaldos est�ndares de su organizaci�n, o puede ser un procedimiento dedicado a hacer copias de seguridad de viejas cuentas de usuario. Aspectos tales como regulaciones sobre la retenci�n de datos, guardar evidencia en casos de demandas por liquidaciones err�neas y otras parecidas, todas forman parte en determinar la forma m�s apropiada de manejar las copias de seguridad.
En cualquier caso, un respaldo en este momento siempre es un buen h�bito, pues el pr�ximo paso (cuando el supervisor accede a los datos de la persona liquidada) puede resultar en la eliminaci�n accidental de los archivos. En tales circunstancias, el tener una copia de seguridad reciente hace posible recuperarse f�cilmente de este tipo de accidentes, haciendo el proceso m�s f�cil tanto para el supervisor como para usted.
En este punto, debe determinar que tipo de acceso requiere el supervisor de la persona recientemente terminada a los archivos de esta. Dependiendo de su organizaci�n y la naturaleza de las responsabilidades de la persona, es posible que no se requiera ningun acceso, o que se necesite acceso completo.
Si la persona utiliz� los sistemas para cosas m�s all� que simplemente correo electr�nico, es posible que el supervisor tenga que revisar y colar un poco los archivos, determinar lo que se deber�a mantener y qu� se puede desechar. Al concluir este proceso, al menos algunos de estos archivos seran entregados a la persona que tomar� las responsabilidades de la persona liquidada. Quiz�s se le solicite su asistencia para este paso final o puede que el supervisor est� en una posici�n de manejar esto �l mismo. Todo depende de los archivos y de la naturaleza del trabajo que realiza su organizaci�n.
6.1.4.3. Cambios de trabajo
Responder a las peticiones de crear cuentas para los nuevos usuarios y el manejo de la secuencia de eventos necesarios para bloquear una cuenta de un empleado liquidado son procesos relativamente directos. Sin embargo, la situaci�n no es tan clara cuando la persona cambia de responsabilidades dentro de su organizaci�n. Algunas veces la persona puede requerir cambios a su cuenta y algunas veces no.
Habr� al menos tres personas relacionadas en asegurarse de que la cuenta del usuario sea configurada adecuadamente para coincidir con las nuevas responsabilidades:
Usted
El supervisor original del usuario
El nuevo supervisor del usuario
Entre uds tres deber�a ser posible determinar qu� se debe hacer para cerrar limpiamente las responsabilidades anteriores del empleado y qu� se debe hacer para preparar la cuenta para sus nuevas responsabilidades. En muchos casos, este proceso se puede pensar como el equivalente de cerrar un usuario existente y crear una nueva cuenta de usuario. De hecho, algunas organizaciones hacen esto para todos los cambios de responsabilidades.
No obstante, es m�s probable que se mantenga la cuenta del usuario y que se modifique para adaptarse a las nuevas responsabilidades. Este enfoque implica que usted debe revisar cuidadosamente la cuenta para asegurarse de que no se estan dejando recursos o privilegios de acceso en la cuenta y que esta tiene solamente los recursos y privilegios adecuados para las nuevas responsabilidades de la persona.
Para complicar las cosas a�n m�s, est� la situaci�n en que hay un per�odo de transici�n donde la persona realiza tareas relacionadas a ambos grupos de responsabilidades. Es aqu� donde los supervisores original y el nuevo, lo pueden ayudar d�ndole una ventana de tiempo para este per�odo de transici�n.
