6. Administración de cuentas de usuarios y accesos 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 cómo 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.) 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: Efectué 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 particularmente 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.
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
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.) Como puede ver, el número de contraseñas posibles incrementa dramáticamente a medida que se incrementa el largo.
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.
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.
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 recursos creados 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.
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 ustedes 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 están 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.
6.2. Administración de recursos de usuarios
La creación de cuentas de usuario solamente es una parte del trabajo de un administrador de sistemas. La administración de recursos también es esencial. Por lo tanto, debe considerar tres puntos:
¿Quién puede acceder a los datos compartidos?
¿Dónde los usuarios acceden a esos datos?
¿Qué barreras se colocan para prevenir el abuso de los recursos?
Las secciones siguientes revisan brevemente cada uno de estos tópicos.
6.2.1. ¿Quién puede acceder a los datos compartidos?
El acceso de un usuario a una aplicación dada, archivo o directorio es determinado por los permisos aplicados a esa aplicación, archivo o directorio. Además, a menudo es útil si se pueden aplicar diferentes permisos para diferentes clases de usuarios. Por ejemplo, el almacenamiento compartido debería se capaz de prevenir la eliminación accidental (o maliciosa) de archivos de usuarios por otros usuarios, a la vez que se permite que el propietario de los archivos tenga acceso completo a los mismos.
Otro ejemplo es el acceso asignado al directorio principal de un usuario. Solamente el propietario del directorio principal debería poder crear y ver los archivos que se encuentran allí. Se debería negar el acceso a todos los otros usuarios (a menos que el usuario desee lo contrario). Esto incrementa la privacidad del usuario y previene de la posible apropiación incorrecta de archivos personales.
Pero hay muchas situaciones en las que múltiples usuarios pueden necesitar acceso al mismo conjunto de recursos en una máquina. En este caso, puede ser necesaria la creación de grupos compartidos.
6.2.1.1. Grupos y datos compartidos
Como se mencionó en la introducción, los grupos son construcciones lógicas que se pueden usar para vincular cuentas de usuario para un propósito específico.
Cuando se administran grupos dentro de una organización, es prudente identificar los datos a los que ciertos departamentos deben tener acceso, los datos que se deben negar a otros y que datos deberían ser compartidos por todos. Esto ayuda en la creación de una estructura de grupos adecuada, junto con los permisos apropiados para los datos compartidos.
Por ejemplo, asuma que el departamento de cuentas por cobrar debe mantener una lista de las cuentas morosas. Esta lista debe ser compartida con el departamento de cobros. Si el personal de cuentas por cobrar y el personal de cobranzas se colocan como miembros de un grupo llamado cuentas, esta información se puede colocar entonces en un directorio compartido (propiedad del grupo cuentas) con permisos de grupo para leer y escribir en el directorio.
6.2.1.2. Determinar la estructura de un grupo
Algunos de los retos con los que se encuentra un administrador de sistemas cuando crean grupos son:
¿Qué grupos crear?
¿A quién colocar en un grupo determinado?
¿Qué tipo de permisos deberian tener estos recursos compartidos?
Para estas preguntas se necesita un enfoque con sentido común. Una posibilidad es reflejar la estructura de su compañía cuando se creen grupos. Por ejemplo, si hay un departamento de finanzas, cree un grupo llamado finanzas y haga a todo el personal de finanzas parte de ese grupo. Si la información financiera es muy confidencial para toda la compañía, pero es vital para los empleados senior, entonces otorgue a estos permisos a nivel de grupo para el acceso a los directorios y los datos utilizados por el departamento de finanzas añadiendolos al grupo finanzas.
También es bueno pecar por el lado de la precaución cuando se otorguen permisos para los usuarios. De esta forma, hay menos probabilidades de que los datos confidenciales caigan en las manos incorrectas.
Enfocando la creación de la estructura de grupos de su organización de esta manera, se puede satisfacer de forma segura y efectiva la necesidad de datos compartidos dentro de la organización.
6.2.2. ¿Donde los usuarios acceden a los datos compartidos?
Cuando se comparten datos entre usuarios, es un práctica común tener un servidor central (o grupo de servidores) que hacen ciertos directorios disponibles a otras máquinas en la red. De esta forma los datos son almacenados en un lugar; no es necesario sincronizar los datos entre múltiples máquinas.
Antes de asumir este enfoque, primero debe determinar cuáles son los sistemas a acceder a los datos almacenados centralmente. Al hacer esto, tome nota de los sistemas operativos utilizados por los sistemas. Esta información tienen un peso en su habilidad de implementar este enfoque, pues su servidor de almacenamiento debe ser capaz de servir sus datos a cada uno de los sistemas operativos en uso en su organización.
Lamentablemente, una vez que los datos son compartidos entre múltiples computadores en una red, puede surgir el potencial para conflictos en la propiedad de un archivo.
6.2.2.1. Problemas globales de propiedad
El tener los datos almacenados centralmente y accesibles por múltiples computadores sobre la red tiene sus ventajas. No obstante, asuma por un momento que cada una de esas computadoras tiene una lista mantenida localmente de las cuentas de usuarios. ¿Qué tal si las listas de usuarios en cada uno de estos sistemas no son consistentes con la lista de usuarios en el servidor central? Peor aún, ¿qué pasa si la lista de usuarios en cada uno de esos sistemas no son ni siquiera consistentes unas con otras?
Mucho de esto depende sobre cómo se implementen los usuarios y los permisos de acceso en cada sistema, pero en algunos casos es posible que el usuario A en un sistema pueda ser conocido como B en otro. Esto se vuelve un verdadero problema cuando los datos son compartidos entre sistemas, pues los datos que el usuario A tiene permitido acceder desde un sistema también puede ser leído por el usuario B desde otro sistema.
Por esta razón, muchas organizaciones utilizan algún tipo de base de datos central de usuarios. Esto asegura que no haya solapamientos entre las listas de usuarios en sistemas diferentes.
6.2.2.2. Directorios principales
Otro problema que enfrentan los administradores de sistemas es si los usuarios deberían tener directorios principales centralizados.
La ventaja principal de tener un directorio principal centralizado en un servidor conectado a la red es que si un usuario se conecta a cualquier máquina en la red, podrá acceder a los archivos en su directorio principal.
La desventaja es que, si la red se cae, los usuarios a lo largo de la organización no podrán acceder a sus archivos. En algunas situaciones (tales como organizaciones que hacen gran uso de portátiles), el tener directorios principales centralizados no es recomendable. Pero si tiene sentido para su organización, la implementación de directorios principales puede hacer la vida de un administrador mucho más fácil.
6.2.3. ¿Qué barreras se colocan para prevenir el abuso de los recursos?
La organización cuidadosa de recursos y la asignación de permisos para los recursos compartidos es una de las cosas más importantes que un administrador de sistemas puede hacer para prevenir el abuso de recursos entre usuarios dentro de la organización. De esta forma, aquellos que no deberían tener acceso a recursos confidenciales, se les niega el acceso.
Pero no importa cómo su organización haga las cosas, la mejor guardia contra el abuso de recursos siempre es la vigilancia permanente por parte del administrador del sistema. Mantener los ojos abiertos a menudo es la única manera de evitar que una sorpresa desagradable esté esperando por usted a la mañana siguiente.
FUENTE:http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-isa-es-4/ch-acctsgrps.html
0 comentarios:
Publicar un comentario