Las cuentas de usuario identifican las conexiones a la base de datos. Los privilegios que se otorgan o deniegan a un usuario o grupo sobre una base de datos o un dataset, determinan a qué puede acceder el usuario. Las cuentas de usuario se pueden agrupar en función de las tareas que necesitan realizar para simplificar la gestión de los privilegios.
Cuentas de usuario
Las cuentas de usuario son nombres y contraseñas únicos que se utilizan para identificar a una persona o una aplicación cliente que se conecta a la base de datos. En ArcGIS, las cuentas de usuario determinan quién es propietario de qué datos. Las cuentas de usuario también proporcionan una forma de controlar qué tipo de acceso (si lo tiene) tiene una persona o una aplicación cliente a una base de datos o una geodatabase y sus datasets.
Las cuentas de usuario de IBM Db2 se crearon en el nivel de sistema operativo o red.
No utilice separadores, como comillas, para forzar la creación de un nombre de cuenta de usuario o grupo que contenga caracteres o mayúsculas y minúsculas incompatibles con la base de datos subyacente. Si un objeto de base de datos, como un nombre de usuario, se crea con delimitadores, se deben emplear delimitadores cuando la base de datos se consulte para ver si contiene ese objeto. ArcGIS no coloca delimitadores alrededor de los nombres de objeto cuando consulta la base de datos. Por tanto, si la base de datos no admite los caracteres del nombre de cuenta de usuario o grupo sin entrecomillar, no se podrá realizar la conexión a la base de datos desde ArcGIS.
Propiedad de los datos
Para ArcGIS, el usuario que crea las tablas, clases de entidades y vistas de una geodatabase o base de datos es propietario de dichos datasets. Por ejemplo, el administrador de la geodatabase crea la geodatabase; por lo tanto, las tablas de sistema de la geodatabase que se crearon en la base de datos en ese momento son propiedad del administrador de la geodatabase. Del mismo modo, un usuario que crea una clase de entidad posee esa clase de entidad.
El nombre de usuario utilizado para realizar la conexión a la geodatabase en el momento en que se crean los datasets es el propietario de los datos.
Los usuarios propietarios de datos deben tener esquemas en la base de datos con el mismo nombre que el del usuario.
Por ejemplo, los miembros del personal a tiempo parcial Boris y Basil pueden crear datasets en la geodatabase. Boris y Basil utilizan el mismo equipo. Si ambos utilizan la cuenta de Basil para conectarse a la geodatabase en ArcGIS, todos los datasets que hayan creado Boris o Basil pertenecerán a Basil y se almacenarán en su esquema.
Si Boris desea que los datos que él crea se almacenen en su esquema, debe alterar las propiedades de conexión de la base de datos y conectarse a la base de datos con su propio nombre de usuario para poder comenzar a crear datos.
Es importante conocer quién posee los datos ya que usted no puede quitar una cuenta de usuario de la base de datos si el usuario posee datos, y es el usuario quien creó el dataset que controla el nivel de acceso al dataset que tienen otros usuarios.
Acceso de usuario
Su geodatabase debe poder verificar las cuentas de usuarios que intentan conectarse a ella. Lo que significa que el administrador de base de datos tiene que agregar a los usuarios a la base de datos. La base de datos verifica la lista de usuarios para asegurarse de que un usuario puede conectarse. Este proceso se denomina autenticación.
Existen dos tipos de autenticación que se utilizan con las bases de datos Db2: la autenticación de sistema operativo y la autenticación de base de datos.
La autenticación del sistema operativo (SO) indica que un usuario inicia sesión en el equipo y el sistema operativo del equipo del usuario proporciona las credenciales de autorización a la base de datos. Para el usuario que se conecta, eso significa que únicamente tiene que iniciar sesión en su equipo y no tiene que iniciar sesión por separado en la base de datos. Para el administrador de base de datos, eso significa que se debe agregar el inicio de sesión existente a la base de datos, y la base de datos se debe configurar para que reconozca el inicio de sesión existente del usuario.
Si utiliza la autenticación de la base de datos, los usuarios inician sesión en el servidor y luego deben iniciar sesión de forma separada en la base de datos.
Nota:
Aunque Db2 no disponga de cuentas de usuario de base de datos, todavía existe la posibilidad de usar la autenticación de base de datos al conectarse desde ArcGIS. Si lo hace, le permite guardar el nombre de usuario específico y la contraseña de un usuario.Una vez que se agregan los usuarios, el administrador de la base de datos también debe otorgar privilegios específicos a los usuarios para determinar lo que pueden hacer y lo que no en la base de datos. La base de datos verifica estos privilegios cuando un usuario autenticado intenta acceder o alterar la base de datos. Este proceso se denomina autorización. En ArcGIS, los propietarios de los datos también pueden conceder privilegios sobre sus datos a otros usuarios o grupos.
Los tipos de privilegios que se otorgan a un usuario se basan en el tipo de trabajo que el usuario debe realizar. Algunos usuarios solo necesitan conectarse a la base de datos y ver los datos específicos. Otros usuarios necesitan crear nuevos datasets. En la siguiente sección se explica cómo se pueden agrupar las cuentas de usuario para simplificar la administración de privilegios.
Grupos o roles
La mayoría de los sistemas de administración de bases de datos proporcionan formas para que el administrador de bases de datos agrupe a los usuarios según las necesidades de acceso a los datos y asigne privilegios al grupo. Esto reduce el tiempo dedicado a modificar los privilegios individuales de cada usuario y simplifica la administración de grandes números de privilegios para grandes números de usuarios. Por lo tanto, puede utilizar grupos (también denominados roles, tipos, o autoridades, según el sistema de administración de bases de datos) que otorguen derechos a los usuarios de acuerdo con las funciones comunes.
Las categorías o los grupos de usuarios comunes son los que visualizan los datos, los que editan los datos y los que crean lo datos.
En la mayoría de los casos, otorgar derechos a grupos no impide otorgar derechos a usuarios individuales en geodatabases corporativas. Por ejemplo, puede otorgar los privilegios mínimos necesarios para crear datos en la base de datos para el grupo que crea datos (que puede incluir al administrador de la geodatabase) y otorgar privilegios adicionales sólo al usuario administrador de la geodatabase. Sin embargo, cada sistema de gestión de bases de datos trata la precedencia de privilegios de forma distinta, así que deberá consultar la documentación de su sistema de administración de bases de datos para ver los detalles del comportamiento de los privilegios asociados a los roles y los usuarios individuales.
Además, la mayoría de los sistemas de administración de bases de datos proporcionan grupos predefinidos. Uno de ellos es el rol PUBLIC.
Esencialmente, el grupo o rol PUBLIC es una variable que equipara a cualquier persona conectada a la base de datos; por lo tanto, cualquier derecho otorgado al grupo PUBLIC también se otorga a todos los que se conectan a la base de datos. Puede haber casos en los cuales todos los usuarios necesitan un privilegio determinado. Por ejemplo, para conectarse a las bases de datos de SQL Server o Db2, los usuarios deben contar con el privilegio CONNECT. Puesto que todos los usuarios necesitan este privilegio para conectarse, SQL Server y Db2 otorgan este privilegio a PUBLIC de forma predeterminada.
En algunos casos, se otorgan privilegios de alto nivel a PUBLIC por defecto cuando se crea la base de datos. Sin embargo, por motivos de seguridad, sólo se deben otorgar privilegios a PUBLIC cuando sea absolutamente necesario.
Para obtener información sobre otros grupos predefinidos, consulte la documentación de su sistema de administración de bases de datos.
Sugerencias para agrupar usuarios
A continuación se presentan algunas sugerencias para agrupar usuarios en el sistema de administración de bases de datos.
- Cree grupos separados (roles) para los privilegios de sistema y de objeto. Esto permite al administrador de la base de datos gestionar los privilegios de la base de datos concediéndolos a los grupos del sistema, y a los propietarios de los datos conceder privilegios sobre sus datasets otorgándolos a grupos de objetos.
- Elija una convención de nomenclatura que refleje cada tipo de grupo (rol) para lograr una referencia fácil. Por ejemplo, para un grupo que puede editar todos los datos sobre el suelo, puede nombrar al grupo LANDBASE_EDITORS.
- Otorgue privilegios directamente al administrador de la geodatabase y otorgue privilegios mediante grupos (roles) para todos los demás usuarios. El administrador de la geodatabase es una entidad única. En la mayoría de los casos, existe sólo un usuario de este tipo para cualquier tipo de geodatabase y no es parte de un grupo lógico de usuarios mayor. Los administradores de bases de datos con experiencia consideran que otorgar privilegios directamente a tales cuentas del administrador de la aplicación es un buen diseño. Por el contrario, las cuentas para usuarios no administradores deben recibir privilegios mediante grupos que representen la descripción del trabajo, las responsabilidades del proyecto u otra clasificación lógica en la organización.
- Evite mezclar los roles con los privilegios otorgados directamente a las cuentas de usuarios no administradores. Cuando las cuentas de usuarios no administradores reciben privilegios mediante ambos roles y otorgamientos directos, un modelo de seguridad bien planificado puede transformarse rápidamente en un desorden imposible de manejar que requiere un tiempo y un esfuerzo considerables para volver a un estado organizado. Establezca políticas para que los propietarios de los datos sigan cuando otorguen acceso a sus datos.
En el improbable caso de que un usuario no administrador posea requisitos de seguridad realmente únicos, considere la posibilidad de otorgarle algunos privilegios directamente para evitar complicar el modelo de seguridad basado en roles. Documente estos casos, ya que deben ser la excepción y no la regla.