SEGURIDAD
Seguridad
Con el fin de evitar :
◦ Pérdida de integridad de la información
◦ Pérdida de disponibilidad
◦ Pérdida de confidencialidad de la información
El DBA junto con la ayuda de su DBMS debe
ser capaz de establecer algún mecanismo para
proteger los datos.
Seguridad
El modelo de seguridad de un DBMS consta
de 2 partes: Autentificación y Autorización.
Autentificación: es el proceso por el cual el
DBMS valida y establece la identidad de la
persona que se quiere conectar al servidor.
Autorización es el proceso por el cual el
DBMS decide si la entidad autentificada tiene
acceso a usar ciertos recursos del servidor.
Autentificación
Elmodo de autentificación indica de qué
manera se va a identificar a un usuario que
quiere conectarse al servidor
SQL Server 2019 ofrece 2 modos de
autentificación.
Autentificación controlada por Windows
Autentificación mixta (SQL Server y
Windows)
Autentificación x Windows
En este caso SQL Server cede la verificación del usuario al Sistema
Operativo, siempre y cuando este sea Windows NT, Windows Server,
en pocas palabras, SO de Microsoft.
Establece una “conexión de confianza” al servidor basada en el Sistema
Operativo. Todo el trabajo de la seguridad queda controlado por el
sistema Operativo.
Para que un usuario/grupo entre con autentificación de Windows, su
cuenta de Windows se debe dar de alta dentro del grupo de Logins en
SQL Server.
Ventajas:
◦ Un usuario puede cambiar su password frecuentemente si así se dispone
◦ El usuario no necesita dar 2 passwords para poder conectarse (Windows y SQL Server)
◦ Se puede dar acceso a todos los miembros de un grupo de Windows.
Desventajas:
◦ Sólo podrán entrar aquellos usuarios con una cuenta de Windows.
Autentificación Mixta
En este caso se maneja la autentificación
por Windows y la autentificación por SQL
Server. En el caso de la autentificación
hecha por SQL Server, este controla el
acceso a la base de datos y verifica el
password del usuario.
Se utiliza este tipo de autentificación
cuando los usuarios no trabajan en un
dominio de Windows.
Logins
Un Login es una cuenta que permite a un
usuario entrada al servidor.
Para cada login hay que indicar el tipo de
autentificación con la cual va a trabajar, si
es Windows o Mixta.
Ejercicio
Mostrar donde se puede modificar la
forma de autentificación por servidor en
Management Studio.
Creación de un Login en Management
Studio, crearemos el login llamado
Sistema con password 123.
Securable, Principal,Schema
Securable (Asegurable): Un asegurable es
una entidad sobre la cual se dan permisos
de acceso, estos asegurables pueden ser
bases de datos, schemas y objetos de la
base de datos como una tabla.
Principals
Principal: Es una entidad que puede hacer uso de los asegurables.
◦ Un principal primario representa a un usuario de la BD (User).
◦ Un principal secundario representa a un grupo de varios usuarios (tal
como un rol o un grupo de windows).
Podríamos decir que un principal es una persona o usuario que ya
ha sido autentificado y que ahora va a ser uso de los objetos
(securables) de una base de datos a los que tiene derecho.
Es importante hacer notar que un principal primario dentro de una
base de datos se conoce como User, este nombre de User no
necesariamente tiene que ser igual al Login con el que se
autentificó.
Schema
Schema: Un Schema se define como una colección de objetos de
una base de datos que pertenecen a un User (que puede ser
Primario o Secundario ) de la base de datos. Se podría visualizar
un Schema como un contenedor de objetos.
En general, a menos que se indique algo diferente, los objetos que
existen en el Schema también pertenecen al User que creó el
schema.
Pordefault en cada base de datos nueva existen 4 schemas: dbo,
INFORMATION_SCHEMA, guest y sys.
Cuando se crea un User dentro de la base de datos se puede definir
un schema para el mismo, si no se define, el default es dbo.
Ejercicio
Al usuario Sistema le daremos permiso de
entrar a la base de datos Escolar.
Crearemos un schema llamado General
cuyo duenio será Sistema
Asignaremos el schema General como
default al usuario Sistema.
Roles
Roles
Un rol es un grupo de funciones que son
asignadas a un usuario en particular.
Existen 2 tipos de roles:
◦ De operaciones sobre el servidor
◦ De operaciones sobre una base de datos
Roles del servidor
Estas funciones ya están predefinidas y cada una
de ellas realiza tareas muy específicas. A un
usuario se le pueden asignar estas funciones o
roles.
Un rol en SQL Server 2019 sería un principal
secundario ya que puede agrupar a varios
usuarios.
A partir de la versión 2014 se pueden crear
nuevos roles de servidor.
Un Login puede pertenecer a uno o más roles de
servidor.
Roles del Servidor
Buscar en internet cuales son los
diferentes Server Roles que existen.
Ver donde se encuentran en Management
Studio.
Roles de Bases de Datos
Los roles de operación solo trabajan sobre
la base de datos, cada base de datos tiene
estos mismos roles.
Se pueden crear nuevos roles a nivel de
Base de Datos.
Ejercicio
Buscar cuales son los diferentes roles a nivel de
Base de Datos que existen y para que sirve cada
uno de ellos.
Asignaral usuario Sistema en la BD Escolar el rol
de db_ddladmin, asi como db_datareader y
db_datawriter.
Conectarse como usuario Sistema y crear una
tabla en la BD Escolar, vea en que schema se
creó dicha tabla.
Control de Permisos
Una vez que un User entra a una base de
datos se le pueden asignar permisos sobre
la base de datos.
Los permisos son de 2 tipos:
◦ Permisos de operación sobre objeto
◦ Permisos de ejecución de instrucciones
Permisos
Permisos de operación sobre objetos de la BD
Este tipo de permiso dice que podemos hacer sobre los
objetos de la base de datos.
SELECT,INSERT,UPDATE,DELETE,EXEC
Permisos de ejecución de instrucciones
Este tipo de permiso indica que tipo de instrucciones
podemos ejecutar sobre los objetos de las bases de datos y
el servidor en general, algunas de estas instrucciones son:
CREATE TABLE, CREATE VIEW, CREATE SP,
CREATE RULE, CREATE DEFAULT, BACKUP DB,
BACKUP LOG.
Estado de los permisos
Estados de los Permisos
Un permiso puede estar en cualquiera de estos
3 estados:
◦ Concedido (Grant): Se otorga el permiso
◦ Revocado(Revoke): Se elimina un permiso
otorgado o negado anteriormente.
◦ Denegado (Deny): Se niega explícitamente un
permiso.
Los permisos sobre objetos y sobre
instrucciones se pueden otorgar a los
principales.
Ejemplo de manejo de permisos
Para asignar un permiso al usuario Sistema:
Grant Select, Insert,Delete on Alumno to
Sistema
Grant execute on Up_Consulta to Sistema
Para negar un permiso
Deny select on Alumno to Sistema
Deny Insert,Delete on Programa to Sistema
Para quitar un permiso
Revoke Select on Alumno to Sistema
Revoke Insert,Delete on Programa to Sistema
Permisos finales
Los permisos finales de un usuario se dan
en base a la combinación de permisos que
tenga el usuario y el o los roles a los que
pertenece dicho usuario.
Ejemplo
Supongamos que existe la tabla Alumno y existe un rol de base de
datos que se llama Escolar, ahí van todos los empleados del Depto
Escolar.
Existe un usuario que se llama Maru, es la persona que casi puede
hacer de todo en la base de datos Escolar y pertenece al rol Escolar.
Insert Delete Update Select
Rol X X X Ok
Escolar
Maru Ok Ok Ok Ok
El permiso final de Maru sobre la tabla Alumno es solo hacer Select
porque los otros están negados por el Rol Escolar
Ejercicio
Crear un nuevo login llamado Sistema2 con
pwd 123
Darle permiso de entrar a la BD Escolar
Darle permiso explicito de consultar la table
Alumno
Recomendaciones
Crear roles por tareas que tengan en común un grupo de usuarios. Por ejemplo: crear
un rol para los usuarios que pertenecen al departamento de Recursos Humanos, otro
para el departamento de Contabilidad.
Dar los permisos necesarios a cada uno de los roles creados.
Asignar usuarios a los roles creados.
Si un usuario requiere un acceso en particular, hay que otorgárselo en forma
particular.
Cuando sea posible utilizar vistas, ya que las vistas esconden información
confidencial. En lugar de dar acceso a las tablas directamente, dar acceso a las vistas.
Si existen procesos de actualización críticos, estos podrían resolverse con el uso de
Stored Procedures, crear el stored procedure que tenga acceso a las tablas deseadas, y
asignar a los usuarios la posibilidad de ejecución del Stored Procedure, con esto se
asegura de no asignarle permisos directamente a cada usuario sobre las tablas
críticas.
Al momento de crear los roles hay que asignarle derechos en forma general teniendo
en cuenta los usuarios que van a pertenecer a dicho rol.
Una vez hecho esto se puede trabajar en forma más particular, negando dicho
permiso a aquellos usuario específicos que no lo requieran.
