Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Linuxtopia - Red Hat Enterprise Linux 4: Introduccion a la administracion de sistemas - Administraci�n de recursos de usuarios

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.

 
 
  Published under the terms of the GNU General Public License Design by Interspire