La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Seguridad: Inicios de sesión y permisos

Presentaciones similares


Presentación del tema: "Seguridad: Inicios de sesión y permisos"— Transcripción de la presentación:

1 Seguridad: Inicios de sesión y permisos

2 Modos de seguridad SQL Server presenta 2 modos de seguridad:
1.- Modo Windows Integrado. 2.- Modo Mixto: - Windows Integrado. - Autenticación SQL Server.

3 1.- Modo Windows Integrado.
Este modo de seguridad, después de llegar a SQL Server a través de la red, debe presentarle sus credenciales de seguridad de Windows en red, estas credenciales de seguridad se le pasan a SQL Server de manera silenciosa, así que no necesita hacer algo el administrador de la BD para validar al usuario. Ventajas: 1.- Los usuarios no tiene que preocuparse por iniciar sesiones en el servidor de BD en forma separada. 2.- Puede aprovechar el hecho de que probablemente la mayoría de usuarios tengan cuenta de Windows, lo que reduce la carga administrativa de manejar cuentas de inicio de sesión para el servidor.

4 2.- Modo de autenticación SQL Server
Este modo acepta una clave de inicio de sesión y una contraseña generadas en SQL Server, y determina si las credenciales son válidas sin ninguna ayuda de Windows. La información acerca de los inicios de sesión se mantienen dentro de SQL Server, esto es en la BD master y en la tabla SysLogins. Para administrar este modo de autenticación se tienen que seguir los pasos siguientes: 1.- Creación de Inicios de sesión para accesar el servidor. 2.- Acceso de usuarios a las bases de datos.

5 grafica

6 1.- Creación de inicios de sesión
Inicio de sesión Son cuentas de control de acceso a SQL Server, sin un inicio de sesión válido no se puede conectar al servidor SQL Server y usar alguna BD. El primer paso para configurar la seguridad en el servidor es crear los inicios de sesión mediante las siguientes instrucciones.

7 SQL Server 2005: autenticación SQL Server
CREATE LOGIN login_name WITH PASSWORD = 'password' [ HASHED ] [ MUST_CHANGE ] , SID = sid | DEFAULT_DATABASE = database | DEFAULT_LANGUAGE = language | CHECK_EXPIRATION = { ON | OFF} | CHECK_POLICY = { ON | OFF}

8 SQL Server 2005: autenticación SQL Server
loginName Especifica el nombre del inicio de sesión que se va a crear. Hay cuatro tipos de inicio de sesión: de SQL Server, de Windows, asignado a un certificado y asignado a una clave asimétrica. PASSWORD ='password' Sólo se aplica a inicios de sesión de SQL Server. Especifica la contraseña del inicio de sesión que se está creando. PASSWORD =hashed_password Solo se aplica a la palabra clave HASHED. Especifica el valor con hash de la contraseña para el inicio de sesión que se está creando. HASHED Sólo se aplica a inicios de sesión de SQL Server. Especifica que la contraseña especificada después del argumento PASSWORD ya tiene aplicado el algoritmo hash. Si no se selecciona esta opción, se aplicará el algoritmo hash a la cadena especificada como contraseña antes de almacenarla en la base de datos. Esta opción sólo se debería utilizar para migrar las bases de datos de un servidor a otro. No utilice la opción HASHED para crear nuevos inicios de sesión.

9 SQL Server 2005: autenticación SQL Server
MUST_CHANGE Sólo se aplica a inicios de sesión de SQL Server. Si se incluye esta opción, SQL Server pide al usuario la contraseña nueva la primera vez que se utilice el inicio de sesión nuevo. SID = sid Sólo se aplica a inicios de sesión de SQL Server. Especifica el GUID del inicio de sesión de SQL Server nuevo. Si esta opción no se selecciona, SQL Server asigna automáticamente un GUID. DEFAULT_DATABASE =database Especifica la base de datos predeterminada que debe asignarse al inicio de sesión. Si no se incluye esta opción, el valor predeterminado es master.

10 SQL Server 2005: autenticación SQL Server
DEFAULT_LANGUAGE =language Especifica el idioma predeterminado que debe asignarse al inicio de sesión. Si no se incluye esta opción, el idioma predeterminado es el del servidor. Si el idioma predeterminado del servidor se cambia más tarde, el del inicio de sesión se mantiene igual. CHECK_EXPIRATION = { ON | OFF } Sólo se aplica a inicios de sesión de SQL Server. Especifica si debe aplicarse la directiva de expiración de contraseñas en este inicio de sesión. El valor predeterminado es OFF. CHECK_POLICY = { ON | OFF } Sólo se aplica a inicios de sesión de SQL Server. Especifica que se deben aplicar las directivas de contraseñas de Windows en el equipo que ejecuta SQL Server para este inicio de sesión. El valor predeterminado es ON.

11 SQL Server 2005: Autenticación Windows
CREATE LOGIN login_name FROM WINDOWS [WITH DEFAULT_DATABASE = database , DEFAULT_LANGUAGE = language [CERTIFICATE certname | ASYMMETRIC KEY asym_key_name ]] WINDOWS Especifica que el inicio de sesión se asigna a un inicio de sesión de Windows. CERTIFICATE certname Especifica el nombre de un certificado al que asociar este inicio de sesión. Este certificado debe existir en la base de datos master. ASYMMETRIC KEY asym_key_name Especifica el nombre de una clave asimétrica a la que asociar este inicio de sesión. Esta clave debe existir en la base de datos master.

12 Modificación de inicios de sesión
ALTER LOGIN login_name ENABLE | DISABLE | WITH PASSWORD = 'password' | hashed_password HASHED [ OLD_PASSWORD = 'oldpassword' | MUST_CHANGE | UNLOCK DEFAULT_DATABASE = database | LANGUAGE_DEFAULT = language | NAME = login_name | CHECK_POLICY = { ON | OFF } | CHECK_EXPIRATION = { ON | OFF }

13 Modificación de inicios de sesión
login_name Especifica el nombre del inicio de sesión de SQL Server que se está cambiando. ENABLE | DISABLE Habilita o deshabilita este inicio de sesión. PASSWORD = 'password' Sólo se aplica a inicios de sesión de SQL Server. Especifica la contraseña del inicio de sesión que se está cambiando. En las contraseñas se distingue entre mayúsculas y minúsculas. PASSWORD =hashed_password Sólo se aplica a la palabra clave HASHED. Especifica el valor con algoritmo hash para la contraseña del inicio de sesión que se crea.

14 Modificación de inicios de sesión
HASHED Sólo se aplica a inicios de sesión de SQL Server. Especifica que la contraseña especificada después del argumento PASSWORD ya tiene aplicado el algoritmo hash. Si no se selecciona esta opción, se aplica un algoritmo hash a la contraseña antes de almacenarla en la base de datos. OLD_PASSWORD ='oldpassword' Sólo se aplica a inicios de sesión de SQL Server. La contraseña actual del inicio de sesión al que se va a asignar una contraseña nueva. En las contraseñas se distingue entre mayúsculas y minúsculas. MUST_CHANGE Sólo se aplica a inicios de sesión de SQL Server. Si se incluye esta opción, SQL Server pedirá la contraseña actualizada la primera vez que se utilice el inicio de sesión modificado. UNLOCK Sólo se aplica a inicios de sesión de SQL Server. Especifica que un inicio de sesión bloqueado debe desbloquearse.

15 Modificación de inicios de sesión
DEFAULT_DATABASE =database Especifica una base de datos predeterminada que debe asignarse al inicio de sesión. DEFAULT_LANGUAGE =language Especifica el idioma predeterminado que debe asignarse al inicio de sesión. NAME = login_name Especifica el nombre nuevo del inicio de sesión al que se está cambiando el nombre. Si se trata de un inicio de sesión de Windows, el SID de la entidad de seguridad de Windows correspondiente al nombre nuevo debe coincidir con el SID asociado al inicio de sesión en SQL Server. El nombre nuevo de un inicio de sesión de SQL Server no puede contener un carácter de barra diagonal inversa (\). CHECK_EXPIRATION = { ON | OFF } Sólo se aplica a inicios de sesión de SQL Server. Especifica si debe cumplirse la directiva de caducidad de contraseñas en este inicio de sesión. El valor predeterminado es OFF. CHECK_POLICY = { ON | OFF } Sólo se aplica a inicios de sesión de SQL Server. Especifica que se deben aplicar las directivas de contraseñas de Windows en el equipo que ejecuta SQL Server para este inicio de sesión. El valor predeterminado es ON.

16 2.- Usuarios de Base de datos
Después de configurar la seguridad de inicio de sesión y establecer su contraseña, se continua con la configuración de acceso a las base de datos. Tener una clave de inicio de sesión a SQL Server no le proporciona acceso a ninguna BD en el servidor. Cada base de datos tiene su ruta de acceso, la cual se almacena en la tabla de sistema Sysusers de cada BD. En escencia, las claves de inicio de sesión se mapean a un nombre de usuario en cada BD que requiere accesar el inicio de sesión.

17 Darle acceso a un Inicio de Sesión como usuario de una base de datos: USE NombreDB CREATE USER user_name FOR LOGIN login_name Es recomendable tener el mismo nombre de Inicio de sersión como usuario de Base de datos: CREATE USER login_name

18 Eliminación de un usuario en una base de datos: USE nombreDB
DROP USER user_name Listar los usuarios de una BD: USE NombreBD sp_HelpUser [‘NombreUsuarioBD‘]

19 Nombre de usuario GUEST (Invitado)
Este nombre de usuario existe en todas las BD, se usa para que se conecten todos los inicios de sesión del servidor sin tener que darle acceso individual a cada uno de ellos, como su nombre lo indica, es para usuarios invitados. Es necesario activarlo en cada base de datos para que empiece a funcionar. USE NombreBD GRANT CONNECT TO GUEST Para desactivarlo es necesario revocar los permisos al usuario GUEST, solo se desactiva pero no se elimina: REVOKE CONNECT FROM GUEST

20 Funciones Las funciones de SQL Server permiten agrupar a usuarios de BD o a inicios de sesión para desarrollar ciertas operaciones a nivel BD o a nivel servidor. Los miembros de cada función tendrán derecho a realizar ciertas tareas o permisos sobre ciertos objetos de acuerdo con las caracteristicas de la función. Existen 3 tipos de funciones: 1.- Funciones fijas a nivel servidor. 2.- Funciones fijas a nivel BD. 3.- Funciones creadas por usuarios a nivel BD.

21 1.- Funciones fijas a nivel servidor.
Se cuenta con 8 funciones a nivel servidor. En cualquier momento se puede agregar un inicio de sesión como miembro de una o más funciones a nivel servidor. No puede, sin embargo, agregar o quitar propiedad a la lista de propiedades de cada función. El unico inicio de sesión que no se puede eliminar de la función SysAdmin es el inicio de sesión SA.

22 1.- Funciones fijas a nivel servidor.
Las funciones a nivel servidor son: - SysAdmin - ServerAdmin - SetupAdmin - SecurityAdmin - ProccessAdmin - DbCreator - DiskAdmin - BulkAdmin

23 1.- Funciones fijas a nivel servidor.
Las funciones a nivel servidor son: - SysAdmin: Los miembros de esta función pueden hacer TODO en el servidor. Aparecen como el DBO de cada BD. En esencia, pasan por alto los permisos y sistemas de seguridad, el inicio de sesión SA pertenece a esta función. - ServerAdmin: Los miembros pueden asignar opciones de configuración con el proc. Alm. De sistema SP_CONFIGURE y pueden apagar el servidor con el comando SHUTDOWN. Los operadores del servidor se deben agregarse a esta función. - SetupAdmin: Los miembros pueden instalar y configurar servidores vinculados y marcar un procedimiento almacenado para su ejecución durante el arranque.

24 1.- Funciones fijas a nivel servidor.
Las funciones a nivel servidor son: - SecurityAdmin: Los miembros pueden crear y controlar claves de inicio de sesión al servidor, así como permisos para crear BD y poder leer el registro de errores del servidor. Los operadores y su personal auxiliar se deben agregar a esta función. - ProccessAdmin: Los miembros controlan los procesos en ejecución en el servidor de datos. Por lo regular, esto comprende eliminar las consultas descarriadas y proceso bloqueados. El personal auxiliar de los operadores deben agregarse a esta función. - DbCreator: Los miembros pueden crear y alterar base de datos en el servidor. Los administradores de BD se deben incluir en esta función.

25 1.- Funciones fijas a nivel servidor.
- DiskAdmin: Los miembros pueden manejar los archivos y su incremento en el servidor. Los DBA deben agregarse a esta función. BulkAdmin: Los miembros pueden ejecutar inserciones masivas con el comando bullcopy desde MS-DOS. Public : Esta función no tiene ninguna propiedad, las cuales se les puede agregar posteriormente. Todos los inicios de sesión creados se agregan automáticamente a esta función.

26 1.- Funciones fijas a nivel servidor.
Asignación de un inicio de sesión a funciones fijas a nivel de servidor: sp_AddSRVRoleMember ‘InicioSesion‘ , ‘NombreFunción‘ Eliminación de un inicio de sesión a una función: sp_DropSRVRoleMember ‘InicioSesion‘ , ‘NombreFunción‘ Muestra los inicios de sesión en una función: sp_HelpsrvRoleMember ‘NombreFunción‘ Muestra las propiedades de una ´función: sp_HelpsrvRole ‘NombreFunción‘

27 2.- Funciones fijas a nivel BD.
Cada BD contiene funciones, algunas son fijas y además tendrá la capacidad de agregar sus propias funciones. Cada función creada es exclusiva a cada BD, por lo tanto, puede crear la misma función en cada BD. Estas funciones son: - db_owner. - db_AccessAdmin. - db_SecurityAdmin. - db_ddlAdmin. - db_BackupOperator. - db_DataReader. - db_DataWriter. - db_DenyDataReader. - db_DenyDataWriter. - Public.

28 2.- Funciones fijas a nivel BD.
- db_owner: Los miembros pueden hacer TODO, pero sólo dentro de su base de datos. - db_AccessAdmin: Los miembros pueden agregar o quitar usuarios el acceso a la BD. - db_SecurityAdmin: Los miembros pueden controlar todos los permisos, funciones, membresía de funciones y propietarios de objetos en la BD. - db_ddlAdmin: Los miembros pueden crear, modificar y eliminar todos los objetos de BD (tablas, vistas, proc. Alm.). - db_BackupOperator: Los miembros pueden emitir los comandos DBCC, CHECKPOINT, BACKUP y RESTORE.

29 2.- Funciones fijas a nivel BD.
- db_DataReader: Los miembros tienen permisos de selección sobre cualquier tabla o vista de la BD. - db_DataWriter: Los miembros tienen permisos de inserción, actualización y eliminación sobre cualquier tabla o vista de la BD. - db_DenyDataReader: Los miembros no pueden seleccionar datos de ninguna tabla o vista de la BD. - db_DenyDataWriter: Los miembros no pueden modificar ningún dato con las instrucciones insert, update o delete sobre cualquier tabla o vista de la BD. - Public: En esta función se agregan automáticamente todos los usuarios de BD que se van dando de alta.

30 2.- Funciones fijas a nivel BD.
Agregar un usuario de BD a una función : Use NombreDB sp_AddRoleMember ‘Función‘ , ‘NombreUsuario’ Eliminar un usuario de BD a una función : sp_DropRoleMember ‘Función‘ , ‘NombreUsuario’ Muestra las propiedades de una función : sp_HelpRole ‘Función‘ Muestra los usuarios de una función : sp_HelpRoleMember ‘Función‘

31 Función PUBLIC Es una función fija a nivel de BD. En esta función se agregan automáticamente todos los usuarios de BD que se van dando de alta. Generalmente se utiliza para dar permisos globales a la función y no a los usuarios de una BD sin tener que darle permisos individuales o mediante una función creada por el usuario. Un usuario de BD no se puede eliminar de esta función.

32 3.- Funciones creadas por usuarios a nivel BD.
Además de las funciones fijas de BD se pueden crear funciones por cualquiera de los usuarios y asignarle usuarios o funciones a dicha función. No hay restricciones para la creación de funciones, ni tampoco sobre de cuantas funciones puede ser miembro un usuario.

33 3.- Funciones creadas por usuarios a nivel BD.
Crear una función de usuario : sp_AddRole ‘NombreFunción‘ [, ‘Propietario’ ] Eliminación una función de usuario : sp_DropRole ‘NombreFunción‘ Los miembros de la función de servidor sysadmin o de las funciones de BD db_owner o db_SecurityAdmin pueden agregar una nueva función a una BD. Para agregar o eliminar usuarios a estas funciones de usuarios se usan las instrucciones sp_AddRoleMember y sp_DropRoleMember respectivamente.

34 ¿Por qué usar los permisos?
Mediante el diseño e implementación de un buen plan de seguridad para SQL Server se pueden eliminar muchos problemas antes de que sucedan, en vez de pasar el tiempo tratando de imaginar la manera en que se dañaron los datos. Es posible restringir satisfactoriamente las modificaciones que se pueden hacer a los datos, así como qué datos puede ver un usuario. También puede restringir que un usuario pueda respaldar una base de datos o registro de transacciones o pueda crear o eliminar tablas. Otro beneficio de la activación de IS, usuarios y permisos multiples es que puede llevar cuenta lo que se permite hacer a usuarios individuales y auditar su actividad.

35 ¿Por qué usar los permisos?
Debe quedar claro que todos los permisos en SQL Server se dan a usuarios de BD. Por lo tanto, cuando se examinan los permisos siempre se esta viendo los permisos de un usuario de BD y no los permisos para el inicio de sesión. Esto significa que los permisos son especificos para una BD.

36 Permisos de funciones fijas de servidor
Cada función tiene permisos implícitos asociados, y se les puede ver ejecutando el procedimiento almacenado de sistema: Sp_srvRolePermission NomFuncionServidor. Checar páginas

37 Permisos funciones fijas de BD
A los miembros de las funciones fijas de BD se les dan permisos específicos dentro de cada BD. Sin embargo, a diferencia de las funciones fijas de servidor, son específicas a cada BD. El ser miembro de una función fija de BD no tiene efecto sobre los permisos de cualquier otra BD. Se puede utilizar el siguiente procedimiento para checar los permisos : Sp_dbFixedRolePermission NomFunción Páginas

38 El propietario de la BD El usuario DBO tiene todos los derechos que tienen los miembros de la función DB_OWNER. Puede haber solamente un DBO para cada BD y es el único usuario de la BD que puede añadir un usuario a la función DB_OWNER. Además, si un usuario es el DBO, cuando crea un objeto, el propietario del objeto será el DBO de ese objeto, como podría esperarse. Es no se cumple par los miembros de la función fija DB_OWNER. A menos que al momento de crear los objeto se especifique el propietario DBO, el propietario del objeto será su nombre de usuario.

39 El propietario de la BD Se considera que alguien es el DBO de una BD en cualquiera de las siguientes cuatro situaciones: 1.- Es el creador de la BD. 2.- Está asignado como propietario de la BD. El propietario de una BD puede ser asignado posteriormente usando el proc SP_CHANGEOBJECTOWNER. 3.- Se conecta con el SQL Server como cualquier miembro de la función fija de servidor SYSADMIN. Si se conecta a SQL Server usando el inicio de sesión sa, o el de cualquier otro miembro de la función SYSADMIN, tiene todos los permisos en todas las BD, debido a que emula al DBO en cada BD. 4.- Se conecta a una BD, con un inicio de sesión que tiene alias hacia el dbo de una BD. Solamente un usuario puede ser el dbo en cualquier momento.

40 Permisos del propietario del objeto de BD
En forma predeterminada, un usuario que crea un objeto es el propietario del objeto. Los miembros de la función fija de BD DB_OWNER y DB_DDLADMIN pueden crear objetos con su mismo nombre o pueden nombrar el objeto con el nombre DBO. Es recomendable que todos los objetos de una BD tengan como propietario solamente al usuario DBO. A un usuario que posee un objeto de BD se le otorgan todos los permisos sobre ese objeto. Los permisos adecuados para cada tipo de objeto se otorgan al usuario.

41 Permisos del propietario del objeto de BD
La propiedad de un objeto se puede cambiar con: SP_CHANGEOBJECTOWNER ‘propietario.nomObj’ , ‘propietarionuevo’ Para evitar que el propietario no sea el DBO, se aconseja que al momento de crear objetos se incluya en el nombre del objeto, el nombre del propietario: Create table DBO.Clientes(

42 Permisos La implementación de los permisos se realiza a nivel de usuario de BD, por lo tanto, cuando se examinan los permisos siempre se estan viendo los permisos de un usuario de BD y no los permisos para el inicio de sesión. Los permisos que se otorgan a los usuarios se clasifican en: 1.- Permisos de instrucción. 1.- Permisos de Objetos.

43 1.- Permisos de instrucción.
Estos permisos permiten que los usuarios creen nuevos objetos en una BD. Los permisos de instrucción dan la habilidad para ejecutar un comando en particular en vez de operar sobre objetos particulares. Estos permisos no se deben otorgar indiscriminadamente debido a que deja a la BD con objetos innecesarios y hasta inutlies.

44 1.- Permisos de instrucción.
Los permisos de instrucción que se otorgan o se niegan son : CREATE DATABASE CREATE TABLE CREATE PROC CREATE VIEW CREATE DEFAULT CREATE RULE BACKUP DATABASE BACKUP LOG

45 1.- Permisos de instrucción.
Asignación de permisos: grant {all | lista_permisos } to { usuarios|funciones_bd } Quitar permisos : revoke {all | lista_permisos } to {usuarios|funciones_bd } Eliminar permisos explicitamente: deny {all | lista_permisos } to { usuarios|funciones_bd }

46 2.- Permisos de Objetos. Permiten que los usuarios realicen acciones sobre objetos individuales, por ejemplo que puede insertar datos a una tabla o ejecute un procedimiento almacenado. Los permisos se aplican solo a los objetos epecificos que se nombran cuando se otorga el permiso y no a todos los objetos de la BD. Los permisos de objetos son : select insert update delete execute reference

47 2.- Permisos de Objetos. Asignacion de permisos de objetos:
grant {all [privileges] | lista_permisos } on {tabla|vista} [( lista_columnas ) ] to { usuarios|funciones_bd } Quitar permisos que han sido otorgados: revoke {all [privileges] | lista_permisos } from { usuarios|funciones_bd } Eliminar permisos explicitamente: deny {all [privileges] | lista_permisos }

48 2.- Permisos de Objetos. 1.- Crear la BD 2.- Crear las tablas
3.- Dar de alta los inicios de sesión 4.- Dar acceso a las BD a los inicios de sesión 5.- Dar de alta las funciones 6.- Dar permisos a las funciones 7.- Agregar los usuarios a las funciones

49 Permisos sobre vistas y procedimientos almacenados
Las vistas y procedimientos almacenados pueden ayudar a la administración de permisos permitiendo que se otorguen menos de ellos directamente a las tablas que guardan los datos. Esto también puede ayudar a evitar los permisos a nivel columna, debido a que pueden complicar en gran forma el modelo de administración de seguridad.

50 Permisos sobre vistas Una vista se puede considerar como una consulta almacenada que aparece como tabla ante los usuarios. La consulta almacenada aparece como una instrucción SELECT. Para restringir que ciertos usuarios accesen columnas o filas particulares de una tabla, puede crear una vista que haga referencia solamente a las columnas seleccionadas de dicha tabla. Después puede asignar los permisos a la vista para los usuarios sin ningún derecho para ver la tabla subyacente, por lo tanto, solo puede ver los datos de la tabla a través de la vista.

51 Permisos sobre vistas Las vistas se pueden utilizar para:
1.- Restingir las columnas que puede consultar un usuario. 2.- Para asignar permisos solo a la vista y no a todas las tablas que se utilizan dentro de la vista. Aunque una vista puede hacer referencia a dos o mas tablas, no se pueden insertar, actualizar o borrar datos por medio de una vista.

52 Permisos sobre procedimientos almacenados
En forma muy similar a los permisos sobre vistas, los permisos sobre procedimientos almacenados le permiten abstraer a los usuarios de las tablas y no otorgar permisos directos sobre las tablas. Sin embargo, a diferencia de las vistas, los procedimientos almacenados pueden contener muchas instrucciones y operaciones de muchas tablas. El unico permiso que necesita un usuario es el permiso EXECUTE sobre el procedimiento almacenado.

53 Cadena de propiedad En SQL Server todos los objetos tienen un propietario asignado. Aunque lo mejor es que solamente el usuario DBO posea todos los objetos de la base de datos, los usuarios ordinarios pueden poseer objetos en una base de datos si se les permite.

54 Cadena de propiedad Por lo tanto, el nombre de un objeto en SQL Server 2000 es: Servidor.BaseDatos.Propietario.NOmbreObjeto Por ejemplo, la tabla products de la BD northwind en el servidor Esparza seria: Esparza.northwind.dbo.products Para SQL Server 2005, el nombre del objeto es: Servidor.BaseDatos.Esquema.NOmbreObjeto

55 Esquemas en SQL Server 2005 Los esquemas (schemas) son objetos de base de datos que facilitan la resolución de nombres (namespace). Con esto, ahora podemos eliminar un usuario sin que impacte en las aplicaciones y consultas existentes, puesto que la eliminación de un usuario (una cuestión de seguridad) no implica la eliminación del esquema (una cuestión de resolución de nombres). Es evidente, que todo objeto de base de datos (ej: tabla, vista, procedimiento almacenado, etc.) tiene asociado uno y sólo un esquema. Además, todo usuario tiene asignado un esquema por defecto (default schema), en su defecto, el esquema dbo. De hecho, múltiples usuarios pueden tener asignado el mismo esquema por defecto, si nos resulta de utilidad.

56 Asignar un esquema al crear un usuario:
CREATE USER nombreUsuario WITH DEFAULT_SCHEMA = nombreEsquema Asignar un esquema a un usuario existente: ALTER USER nombreUsuario WITH DEFAULT_SCHEMA = nombreEsquema El nombre de esquema puede no existir, se puede crear antes o despues con el comando: CREATE SCHEMA nombreEsquema AUTHORIZATION UsuarioProp

57 Cadena de propiedad Un usuario puede crear una vista con base en otras tablas y vistas de otros usuarios. Los usuarios también pueden crear procedimientos almacenados que usen otras tablas, vistas y procedimientos almacenados de usuarios. A estos tipos de objetos se le llama objetos dependientes. En una base de datos grande puede haber una serie larga de dependencias y propietarios. Esta serie es la cadena de propiedad. Hay dos tipos de cadenas de propiedad: 1.- La cadena de un solo propietario. 2.- La cadena de propiedad rota, en donde mas de un usuario posee objetos en una cadena de dependencia.

58 1.- Cadena de un solo propietario
Se crea cuando el mismo usuario posee todos los objetos dependientes que están dentro de una cadena. En este caso SQL Server revisará el permiso del primer objeto de la cadena que se está accesando, y no revisará los permisos sobre los objetos que están en la parte posterior de la cadena. Dbo.tabla1 Dbo.tabla2 Dbo.Vista1 Ana tiene permiso de SELECT sobre la vista1,

59 2.- Cadena de propiedad Rota
Cuando un objeto es dependiente de otros objetos que son propiedad de usuarios diferentes hay una cadena de propiedad rota. Los permisos se revisan en el primer objeto y en cada uno de los objetos en donde hay cambio de propiedad. Dbo.tabla1 Dbo.tabla2 Carlos.Vista1 Ana tiene permiso de SELECT sobre la vista1, pero el servidor revisará los permisos sobre tabla1 y tabla2 porque son de diferente usuario.

60 2.- Cadena de propiedad Rota
Las cadenas de propiedad rota pueden llegar a hacerse muy complejas rapidamente. Si permite que los usuario creen objetos, la seguridad de la base de datos pronto se parecerá a un plato de espaguetti.Por esta razón, todos los objetos deben ser creados por el DBO o por los usuarios que sean miembros de la función db_owner o db_ddladmin, quienes tienen que especificar el propietario DBO en las instrucciones CREATE

61 Diseño de una estategia de permisos
SQL Server permite una seguridad muy flexible, la cual puede presentar problemas cuando trata de encontrar la mejor forma para asegurar el sistema. Hay varias reglas que debe seguir y también lineamientos generales para la asignación de permisos. 1.- Si una persona esta a cargo por completo del servidor, necesitará conectarse como miembro de la función fija de servidor sysadmin o con el inicio de sesión SA. 2.- Si un usuario esta a cargo de una base de datos, deberá estar asignado como DBO de esa base de datos en particular o como miembro de la funcion db_owner. 3.- Si un usuario no necesita permisos especiales para hacer trabajo deberá ser tratado como usuario normal de base de datos y obtener permisos para la función public, para una o mas funciones de los cuales sea miembro el usuario o tener permisos adignados directamente a él.

62 Diseño de una estategia de permisos
Cuandos se asignan permisos, es mas facil mantener y documentar la implementación de la seguridad si: 1.- Se asignan los permisos que necesitan todos los usuarios a la función PUBLIC. 2.- Se asignan permisos que necesitan todos los miembros de un grupo de personas hacia un grupo, o se crea una función y se otorgan permisos a la función. 3.- Se asignan permisos individuales solo si los permisos que necesitan no se pueden asignar a una función fija.

63 Debe hacer Debe otorgar a los usuarios los permisos que necesita par ahacer su trabajo. No otorgue permisos a menos que sea necesario. A los usuarios les gusta tener permisos aunque no los necesiten. Debe llevar cuenta de los permisos que se han otorgado. Mantenga un registro de lo que hace en el servidor. Otra opción es generar una secuancia de comandos que documenten todos los objetos y permisos contenidos en la base de datos. Debe designar a un usuario para que sea el DBO de una base de datos si el usuario es responsable de esa base de datos.

64 No debe No debe otorgar a los usuario todos los permisos para resolver un problema. Tomese su tiempo para saber con exactitud cuales permisos realmente necesitan y otorgar esos permisos. No debe permitir que los usuarios ordinarios creen base de dato u objetos dentro de la base de datos. Si permite que los usuarios hagan BD y objetos, no solo pierde el control sobre lo que contiene el servidor y el lugar donde reside la BD y los objetos, también deberá manejar cadenas de propiedad rota.


Descargar ppt "Seguridad: Inicios de sesión y permisos"

Presentaciones similares


Anuncios Google