AA11-Evidencia1: Características y funciones de

seguridad del SGBD

JOEL RODELO GORDILLO

ESPECIALIZACIÓN TECNOLÓGICA EN GESTIÓN Y

SEGURIDAD DE BASES DE DATOS (1881791)

SERVICIO NACIONAL DE APRENDIZAJE SENA

Centro Nacional Colombo Alemán / Regional Atlántico /
Barranquilla -Colombia
AA11-Evidencia1: Características y funciones de
seguridad del SGBD

JOEL RODELO GORDILLO

EVIDENCIAS DE LA ACTIVIDAD DE APRENDIZAJE 11

Director: CANDELARIA VICTORIA SUAREZ BELEÑO

Ingeniera de Sistemas, Con maestría por certificar en Educación y Ambientes
virtuales
cvsuarez@misena.edu.co

ESPECIALIZACIÓN TECNOLÓGICA EN GESTIÓN Y

SEGURIDAD DE BASES DE DATOS (1881791)

SERVICIO NACIONAL DE APRENDIZAJE SENA

Centro Nacional Colombo Alemán / Regional Atlántico /
Barranquilla -Colombia Pamplona, mes día de año
 TABLA DE CONTENIDO

1. INTRODUCCION ............................................................................................ 04
2. OBJETIVOS .................................................................................................... 05
2.1 Objetivo general ........................................................................................ 05
2.2 Objetivos específicos ................................................................................ 05
3. CONTEXTUALIZACIÓN .................................................................................. 06
4. CARACTERISTICAS ................................................................................. 06-24
5. CONCLUSIONES ............................................................................................ 25
6. BIBLIOGRAFIA ............................................................................................... 26
 1. INTRODUCCION

Cuando se piensa en la información esencial de una organización, uno de los

términos más importantes es la de seguridad. Si los datos no están protegidos, es
posible que pierdan su valor si se permite la manipulación o los datos se modifican
sin intención o de forma malintencionada con valores incorrectos o se eliminan por
completo. Cuando estos datos se encuentran en una base de datos de SQL Server,
las entidades de seguridad son parte indispensable en el manejo de la información,
permitiendo proteger lo más importante que son los datos. Además, a menudo
existen requisitos legales que se deben cumplir, como el almacenamiento correcto
de la información confidencial.
 2. OBJETIVOS

2.1 OBJETIVO GENERAL

Documentar las características y funcionalidades que proporciona el SMBD

seleccionado, para asegurar los datos desde la perspectiva de usuarios, objetos e
integridad sobre los datos.

2.2 OBJETIVOS ESPECÍFICOS

 Describir las características de seguridad del SMBD seleccionado.

 Establecer las opciones a ser configuradas para acceder a estas
funcionalidades.
 Identificar la estructura de privilegios y cuentas de usuarios disponibles por
el SMBD.
 Describir los mecanismos de Autenticación que posee el SMBD.
 Presentar las funciones asociadas a la Integridad de los datos.
 3. CONTEXTUALIZACION

Es importante comprender que las características de seguridad no pueden

garantizar por sí solas que la base de datos sea segura. Cada aplicación de base
de datos es única en lo que respecta a los requisitos, el entorno de ejecución, el
modelo de implementación, la ubicación física y el rellenado por parte del usuario.
Algunas aplicaciones que son locales en cuanto al ámbito pueden necesitar una
seguridad mínima, en tanto que otras aplicaciones locales o las aplicaciones
implementadas en Internet pueden precisar medidas estrictas de seguridad y
supervisión y evaluación continuas.

Los requisitos de seguridad de una aplicación de base de datos de SQL Server se

deben tener en cuenta en tiempo de diseño, no a posteriori. La evaluación de las
amenazas en las primeras fases del ciclo de desarrollo permite reducir al mínimo
los posibles daños cuando se detecte una vulnerabilidad. Sin embargo, a pesar de
que el diseño inicial de la aplicación resulte adecuado, pueden surgir nuevas
amenazas a medida que evoluciona el sistema. La creación de varias líneas de
defensa en torno a la base de datos permite reducir al mínimo los daños producidos
por una infracción de seguridad.

La protección de la seguridad en SQL Server conlleva una serie de pasos que

afectan a cuatro áreas: la plataforma, la autenticación, los objetos (incluidos los
datos) y las aplicaciones que tienen acceso al sistema.

4. CARACTERISTICAS

La plataforma de SQL Server incluye el hardware físico y los sistemas de redes que
conectan los clientes con los servidores de bases de datos, así como los archivos
binarios que se utilizan para procesar solicitudes de base de datos.

Seguridad física

Las recomendaciones de seguridad física limitan de forma estricta el acceso al

servidor físico y a los componentes de hardware. Por ejemplo, use salas cerradas
de acceso restringido para el hardware de servidor de base de datos y los
dispositivos de red. Además, limite el acceso a los medios de copia de seguridad
almacenándolos en una ubicación segura fuera de las instalaciones. La
implementación de la seguridad de la red física comienza por mantener a los
usuarios no autorizados fuera de la red.
También se debe considerar la seguridad de la red, el robo de datos o el vandalismo.
Los firewalls también proporcionan formas eficaces de implementar la seguridad,
separando o limitando el tráfico de la red, configurándose para aplicar la directiva
de seguridad de datos de su organización, aumentando la seguridad del sistema
operativo.

Seguridad del sistema operativo

Los Service Packs y las actualizaciones del sistema operativo y del SMDB SQL
Server, que incluyen mejoras de seguridad importantes, por lo que se deben aplicar
todas las revisiones y actualizaciones.

Seguridad de los archivos del sistema operativo de SQL Server

SQL Server usa archivos del sistema operativo para el funcionamiento y el

almacenamiento de datos, por lo tanto, se debe restringir el acceso a estos archivos.

Administración de la seguridad de SQL Server

Modos de autentificación en SQL Server

La autentificación es el proceso por el cual se comprueba que la identidad del
usuario es válida, y es quien dice ser. Para ello, se distinguen dos tipos de
autentificación:

 Autentificación de Windows: Los usuarios se conectan a través de una

conexión de confianza y se autentican mediante una cuenta de usuario de
Windows, obteniendo acceso a SQL Server.
 Autentificación de Windows y SQL Server (Modo mixto): Los usuarios se
conectan mediante una conexión que no es de confianza, proporcionando un
nombre de inicio de sesión con una contraseña válida. En todos servidores
SQL Server existirá un inicio de sesión llamado "sa", que se deshabilitará en
caso de iniciar sesión con Windows.

Directivas de contraseña

Se aplican a un inicio de sesión que utiliza la autentificación SQL Server, y la

contraseña utiliza las mismas directivas de contraseña que Windows (complejidad
y expiración). Las contraseñas deben de cumplir algunas de las siguientes
directrices:

 La contraseña no debe de contener el nombre de la cuenta de usuario.

 Debe contener 8 caracteres como mínimo.
  Deben utilizarse letras en mayúsculas, minúsculas, números y caracteres no
alfanuméricos (almohadilla, signos de admiración, signo de moneda,
porcentaje).
 Hasta 128 caracteres. Se recomienda utilizar las más largas posible.

Las aplicaciones de las directivas de contraseña se pueden configurar

independientemente para cada inicio de sesión de SQL Server mediante Transact-
SQL (ALTER LOGIN) o mediante Management Studio.

Administrar los inicios de sesión

La administración de los inicios de sesión, puede realizarse mediante la herramienta

Management Studio, o mediante Transact-SQL (CREATE LOGIN, ALTER LOGIN,
DROP LOGIN).

Autorizar el acceso a las bases de datos

Es necesario distinguir entre autenticación y autorización:

 Autenticación: Es la verificación de la entidad de seguridad. Es la

comprobación de ser, quien dice ser.
 Autorización: Es la asignación de permisos a una entidad de seguridad sobre
un protegible o asegurable.

Entidades de seguridad y seguridad de objetos de base de datos

Las entidades de seguridad son los individuos, grupos y procesos que tienen acceso
a SQL Server. Los "elementos protegibles" son el servidor, la base de datos y los
objetos incluidos en la base de datos. Cada uno de estos elementos dispone de un
conjunto de permisos que pueden configurarse para reducir el área expuesta de
SQL Server.

Entidad de seguridad son aquellas entidades autenticadas en un sistema SQL

Server que pueden solicitar recursos de SQL Server y se pueden organizar en
jerarquías que dependen del ámbito de la definición de la entidad de seguridad
(Windows, servidor, base de datos). Toda entidad de seguridad tiene un
identificador de seguridad (SID), pero hay algunas restricciones en las entidades de
seguridad de nivel de servidor de SQL Database o SQL Data Warehouse.

Cualquier identidad autenticada a la que se puede conceder permiso para poder

tener acceso a un objeto del sistema de datos se pueden distinguir asi:
  Entidades de seguridad principal indivisible. Son identidades únicas. Como,
por ejemplo, los inicios de sesión.
 Entidades de seguridad de colección. Son colecciones de identidades.
Como, por ejemplo, las funciones de servidor o un Grupo de Windows.

Existen tres niveles de entidades de seguridad: a nivel de Windows, a nivel de SQL

Server y a nivel de base de datos.

Entidades de seguridad a nivel de Windows

Cuentas de usuario local, cuentas de usuario de dominio y los grupos de Windows.

Entidades de seguridad a nivel de SQL Server

Inicios de sesión de SQL Server y funciones de servidor.

 Inicio de sesión con autenticación de SQL Server

 Inicio de sesión con autenticación de Windows para un usuario de Windows
 Inicio de sesión con autenticación de Windows para un grupo de Windows
 Inicio de sesión con autenticación de Azure Active Directory para un usuario
de AD
 Inicio de sesión con autenticación de Azure Active Directory para un grupo
de AD
 Rol del servidor

Entidades de seguridad a nivel de Base de Datos

Usuarios de la base de datos, las funciones de base de datos y las funciones de

aplicación y grupos de base de datos (este último por compatibilidad con versiones
anteriores).

 Usuario de base de datos (hay 12 tipos de usuarios. Para obtener más

información.
 Rol de base de datos
 Rol de aplicación

Los protegibles son aquellos objetos cuyo acceso está regulado por el sistema de
autorización de SQL Server. Los protegibles se organizan en jerarquías anidadas
llamadas ámbitos (que también se pueden proteger).
Los protegibles a nivel de Windows son:

 Archivos
 Claves de registro

Los ámbitos protegibles a nivel de SQL Server son:

 Ámbito de Servidor: Inicios de sesión, Extremos y Bases de Datos.

 Ámbito de Base de datos: Usuarios, Funciones, Funciones de aplicación,
Certificados, Claves simétricas y asimétricas, Eventos DDL y Esquemas.
 Ámbito de Esquema: Tablas, Vistas, Funciones, Procedimientos, Tipos,
Sinónimos y Agregados.

Hay que tener en cuenta, que una entidad de seguridad puede ser también un
protegible. Por ejemplo, un inicio de sesión puede tener permisos sobre otro inicio
de sesión.

Funciones de Servidor

Los inicios de sesión nos permiten establecer conexión con el servidor en lo que se
conoce como proceso de autentificación.
Mediante las cuentas de usuario, podemos acceder a las bases de datos bajo una
serie de permisos concretos.
Tanto los inicios de sesión como las cuentas de usuario están sujetos a permisos
que limitan el margen de actuación de manera controlada.
Estos permisos se pueden asignar directamente sobre el inicio de sesión o cuenta
de usuario, o también pueden asignarse mediante el uso de las funciones de
servidor.
Las funciones de servidor permiten agrupar usuarios en una misma unidad, a la cual
es posible aplicar permisos.
Existen una serie de funciones conocidas como funciones fijas de servidor y tienen
una serie de permisos establecidos a nivel de servidor que no se pueden modificar.

Funciones fijas de servidor:

 Sysadmin: Permite realizar cualquier actividad, es decir, aquellos inicios de

sesión que pertenezcan a Sysadmin, tendrán permisos de administrador a
nivel de servidor.
 Dbcreator: Permite crear y modificar bases de datos.
 Diskadmin: Asigna permisos para poder administrar archivos de disco.
 Serveradmin: Permite configurar las opciones de servidor.
 Securityadmin: Permite administrar y auditar inicios de sesión en el servidor.
 Processadmin: Realizar la administración de procesos de SQL Server.
  Bulkadmin: Permite ejecutar la instrucción BULK INSERT de inserción
masiva de datos.
 Setupadmin: Configura servidores de réplica y servidores vinculados.

Con estas funciones, lo único que es posible realizar es agregar o eliminar inicios
de sesión asociadas a las mismas.
Existe una función de servidor especial llamada "Public", que permite especificar los
permisos que interesa que tenga. Todos los inicios de sesión pertenecen a la
función "Public", por tanto, los permisos especificados para esta función serán
asignadas a todos los inicios de sesión.

Los permisos que tiene asignados por defecto son:

 VIEW ANY DATABASE: Cualquiera puede listar las bases de datos.

 CONNECT en los extremos predeterminados. Permite conectarse mediante
cualquiera de los protocolos predeterminados de SQL Server (TSQL Local
Machine, TSQL Named Pipes, TSQL Default TCP, TSQL Default VIA).

Permisos

La primera línea de defensa consiste en reducir el área de ataque; para ello, no se

deben conceder más permisos que los estrictamente necesarios.

Los permisos son las reglas que gobiernan el nivel de acceso de las entidades de
seguridad a los protegibles. SQL Server usa permisos para controlar el acceso a los
protegibles por parte de entidades de seguridad. Todos los protegibles tienen
permisos asociados que pueden otorgarse a cada entidad de seguridad. Estos
permisos se pueden administrar mediante la herramienta Management Studio o
mediante instrucciones Transact-SQL y se pueden otorgar, revocar o denegar
mediante GRANT, REVOKE o DENY.

Los permisos concretos asociados a cada protegible varían según los tipos de
acciones compatibles con cada protegible.
Determinados permisos se pueden heredar a través de un permiso concedido en un
nivel más alto en la jerarquía del protegible.
Una entidad de seguridad puede realizar una determina acción si el permiso se ha
concedido explícitamente a la entidad o a una colección a la que pertenece la
entidad de seguridad, y, además, el permiso no se ha denegado explícitamente a
dicha entidad.

Algunos de los permisos que se pueden conceder, revocar o denegar sobre los
diferentes objetos existentes (a nivel de servidor, de base de datos o esquema) son:
CREATE, ALTER DROP, CONTROL, CONNECT, SELECT, EXECUTE, UPDATE,
DELETE, INSERT, TAKE OWNERSHIP, VIEW DEFINITION y BACKUP.

Permisos de servidor

Es posible asignar permisos a nivel de servidor, sin utilizar las funciones fijas de
servidor, las funciones de usuario o la función Public (añadiendo inicios de sesión a
las mismas). Es decir, es posible asignar permisos directamente a nivel de servidor.

Los permisos asignados comúnmente a nivel de servidor son a tres protegibles

concretos, el propio servidor, los inicios de sesión y las bases de datos, así:

 CONNECT SQL (Servidor): Permite conectarse al servidor.

 CREATE LOGIN (Servidor): Crea un inicio de sesión.
 CREATE DATABASE (Servidor): Permite crear bases de datos.
 ALTER ANY DATABASE (Servidor): Modifica cualquier base de datos.
 CONTROL SERVER (Servidor): Permite realizar un control administrativo de
todo el sistema.
 SHUTDOWN (Servidor): Permite realizar paradas del servidor.
 VIEW SERVER STATE (Servidor): Muestra el estado del servidor.
 ALTER (Inicio de sesión): Permite modificar un inicio de sesión.
 IMPERSONATE (Inicio de sesión): Permite suplantar la identidad de un inicio
de sesión.
 CREATE TABLE (Base de datos): Habilita la posibilidad de crear tablas en la
base de datos.
 ALTER ANY USER (Base de datos): Modifica cualquier usuario en la base
de datos.
 CONTROL (Base de datos): Asigna control completo sobre la base de datos.
 CREATE SCHEMA (Base de datos): Permite crear esquemas en la base de
datos.
 CREATE USER (Base de datos): Habilita la creación de usuarios en la base
de datos.
 VIEW DATABASES STATE (Base de datos): Permite ver el estado de la base
de datos.
 BACKUP DATABASE (Base de datos): Permite realizar copias de seguridad
de la base de datos.

Las asignaciones de estos permisos a nivel de servidor se pueden hacer desde la

herramienta SQL Server Management Studio o mediante sentencias Transact-SQL.
Para ello se utiliza la palabra clave GRANT con la siguiente sintaxis:

GRANT {securable_permission [,...n]}

[ON securable_type :: securable_name]
TO login [,...n]
[WITH GRANT OPTION]
[AS {group | role}]

Los parámetros configurables son los siguientes:

 Securable_permission: Es el permiso específico que se concede al

protegible.
 Securable_type: Es el tipo de protegible del ámbito de servidor al que se le
aplica el
 permiso. Esta cláusula se omite si se aplica al propio servidor.
 Securable_name: Es el nombre del protegible del ámbito de servidor.
 Inicio de sesión: Al que se le otorga el permiso.
 With GRANT Option: Opción que permite que el cesionario conceda el mismo
permiso a otros.
 AS group | role: Es una especificación de una entidad de seguridad con los
permisos
 necesarios para conceder este permiso del ámbito de servidor. Se requiere
en escenarios en los que el otorgante no tiene todos los permisos necesarios
para conceder el permiso, pero es miembro de una función o grupo que sí
los tiene.

Para los permisos de protegibles del ámbito de servidor, la instrucción GRANT debe
de ejecutarse en la base de datos MASTER.

Funciones definidas por el usuario

Permiten especificar los permisos asociados para cada una de las funciones de
usuario creadas (Disponible a partir de SQL Server 2012). Es decir, se pueden crear
funciones de usuario personalizadas con una serie de permisos concretos, y asignar
los inicios de sesión que interese.

Una función de usuario es posible crearla desde la herramienta SQL Server

Management Studio, o mediante Trantact-SQL.

CREATE SERVER ROLE NOMBRE_FUNCION

A partir de aquí se asignarán los permisos correspondientes y se añadirán los inicios

de sesión que interesan.

Funciones de Base de Datos

Para administrar con facilidad los permisos sobre las bases de datos, SQL Server
proporciona una serie de funciones similares en concepto a las funciones de
servidor. Estas funciones se aplican a toda la base de datos en lo que respecta al
ámbito de permisos asi:

Funciones fijas de base de datos.

Proporcionan a las agrupaciones, privilegios administrativos sobre la base de datos,

para las tareas comunes.

 "Db_accessadmin" permite agregar o quitar usuarios, grupos y funciones de

base
 de datos.
 "Db_backupoperator" realizar una copia de seguridad de la base de datos.
 "Db_datareader" lee datos desde cualquier tabla.
 "Db_datawriter" agrega, cambia o elimina datos de cualquier tabla.
 "Db_ddladmin" agrega, modifica o elimina objetos de la base de datos.
 "Db_denydatareader" no permite la lectura de datos de ninguna tabla.
 "Db_denydatawriter" elimina el permiso de poder cambiar los datos de
cualquier tabla.
 "Db_owner" permite realizar cualquier actividad en la base de datos.
 "Db_securityadmin" posibilita el cambiar las funciones de la base de datos,
cambiar las funciones de aplicación o crear esquemas.
 "Public" permite mantener los permisos predeterminados. Es una función de
base de datos especial, a la que pertenece cada usuario de la base de datos
(no se puede eliminar). Un usuario posee como mínimo los permisos
recogidos en la función Public (p.e. ejecutar instrucciones que no requieren
de permisos como la instrucción Print, puede visualizar información de las
tablas del sistema, ejecutar ciertos procedimientos almacenados en la base
de datos Master y las bases de datos que tenga acceso y podrá obtener
acceso a cualquier base de datos con la cuenta de usuario Guest si está
habilitada.

Funciones de base de datos definidas por el usuario

Si las funciones de base de datos no se ajustan a nuestras necesidades, es posible

utilizar una función de usuario personalizada. De esta manera se permite crear un
grupo de usuarios con un conjunto de permisos comunes.

Ejemplos de sentencias para gestionar funciones de datos de usuario, donde se una

función de usuario, se añade una cuenta de usuario y después se elimina:

USE Nombre_BBDD
CREATE ROLE Nombre_Funcion
 USE Nombre_BBDD
ALTER ROLE Nombre_Funcion ADD MEMBER Usuario

USE Nombre_BBDD
ALTER ROLE Nombre_Funcion DROP MEMBER Usuario

Funciones de aplicación

Las funciones de aplicación permiten cumplir con la seguridad para una aplicación
determinada y proporcionan un contexto de seguridad alternativo para que un
usuario tenga acceso a una base de datos. El usuario ejecuta una aplicación
asociada a una función de aplicación, y el contexto de seguridad de la función de
aplicación se usa en lugar de la del usuario individual. Las funciones de aplicación
difieren del resto de funciones de la base de datos así:

 Las funciones de aplicación no tienen miembros. Se activan para los usuarios

cuando éstos ejecutan la aplicación.
 Las funciones de aplicación permiten que los usuarios dispongan de
permisos especiales cuando usan la aplicación y evitan la necesidad de
conceder permisos directamente a los usuarios.
 Las funciones de aplicación exigen activar una contraseña. Esta contraseña
se utiliza para activar la función de aplicación

Al activar una función de aplicación, los usuarios:

 Pierden todos los permisos existentes en la base de datos actual para sus
cuentas de usuario y cualquier función a la que pertenezcan, salvo los
permisos que se aplican a la función Public.
 Heredan todos los permisos concedidos a la función de aplicación en la base
de datos actual.

Solamente los miembros de las funciones "Db_owner", "Db_securityadmin" y

"sysadmin" pueden crear funciones de aplicación.

Transact-SQL para crear funciones de aplicación:

CREATE APPLICATION ROLE Nombre_Funcion

WITH PASSWORD='contraseña'

Para activar la función de aplicación se realizará de la siguiente manera:

EXEC SP_SETAPPROLE 'Nombre_Funcion", 'contraseña

Permisos de ámbito de base de datos

En relación a los permisos que distintas a tener en cuenta:

 Permisos de base de datos: son permisos para que una entidad de seguridad
pueda ejecutar ciertas tareas dentro de la base de datos.
 Permisos del ámbito de base de datos: son permisos que pueden aplicarse
a protegibles en el ámbito de base de datos, como usuarios, esquemas,
funciones, procedimientos, tablas.

Algunos permisos del ámbito de base de datos son:

 ALTER para protegibles tipo Usuario, con el que se modifica el usuario

especificado.
 SELECT para protegibles de tipo Esquema, con el que se permite
seleccionar filas de cualquier objeto del esquema.
 ALTER para protegibles tipo Esquema, con el que se permite modificar
cualquier objeto del esquema.
 TAKE OWNERSHIP para protegibles tipo Esquema, con el que se puede
hacerse con la propiedad del esquema.

Para conceder permisos a una base de datos, puede realizarse mediante el uso de
la herramienta SQL Server Management Studio, o por medio de instrucciones
Transact-SQL con la sintaxis siguiente:

GRANT {database_permission [,...n]}

TO security_account [,...n]
[WITH GRANT OPTION]
[AS {group | role}]

Los parámetros configurables son los siguientes:

 Database_permission: Es el permiso específico que se concede a la base

de datos.
 Security_account: Entidad de seguridad en nivel de base de datos a la cual
se otorga el permiso. Esta entidad de seguridad puede ser un usuario, una
función de base de datos o una función de aplicación.
 With GRANT Option: Opción que permite que el cesionario conceda el
mismo permiso a otros.
 AS group | role: Es una especificación de una entidad de seguridad con los
permisos necesarios para conceder este permiso del ámbito de base de
datos. Se requiere en escenarios en los que, el otorgante no tiene todos los
 permisos necesarios para conceder el permiso, pero es miembro de una
función o grupo que sí los tiene.

Para conceder permisos del ámbito de la base de datos, la sentencia GRANT a

utilizar es la siguiente:

GRANT {securable_permission [,...n]}

ON securable_type :: -securable_name
TO security_account [,...n]
[WITH GRANT OPTION]
[AS {group | role}]

Los parámetros configurables son los siguientes:

 Securable_permission: Es el permiso específico que se concede al

protegible.
 Securable_type: El tipo de protegible del ámbito de base de datos al que se
aplica el permiso.
 Securable_name: El nombre del protegible del ámbito de base de datos.
 Security_account: Entidad de seguridad en nivel de base de datos a la cual
se otorga el permiso. Esta entidad de seguridad puede ser un usuario, una
función de base de datos o una función de aplicación.
 With GRANT Option: Opción que permite que el usuario al que se le ha
concedido el permiso, conceda el mismo permiso a otros.
 AS group | role: Es una especificación de una entidad de seguridad con los
permisos necesarios para conceder este permiso del ámbito de base de
datos. Se requiere en escenarios en los que, el otorgante no tiene todos los
permisos necesarios para conceder el permiso, pero es miembro de una
función o grupo que sí los tiene.

ENTIDAD DE USUARIO

Hay varias entidades de seguridad en SQL Server, pero una de las más importantes
es la entidad de usuario de una base de datos. A diferencia de las entidades login
de SQL Server que son usadas para acceder a una instancia SQL Server (una
entidad de seguridad a nivel de servidor), una entidad de usuario de base de datos
(una entidad de seguridad a nivel de base de datos) es usada para definir el acceso
a una base de datos particular que pertenece a la instancia de SQL Server.

Usuarios

Existen diversos tipos de usuarios que se diferencian segun las funciones que
pueden realizar en la base de datos, y se pueden clasificar asi:
Inicio de sesión sa

El inicio de sesión sa de SQL Server es una entidad de seguridad a nivel de servidor.

Se crea de forma predeterminada cuando se instala una instancia y la base de datos
predeterminada de sa es la master. El inicio de sesión sa es miembro del rol fijo de
nivel de servidorsysadmin. Este inicio de sesión sa tiene todos los permisos en el
servidor y no puede limitarse. Además, sa no se puede quitar, pero puede
deshabilitarse para que nadie lo emplee.

Usuario y esquema dbo

El usuario dbo es una entidad de seguridad de usuario especial que hay en cada
base de datos. Todos inicios de sesión con permisos de administrador acceden a la
base de datos con esta cuenta de usuario (todos los administradores de SQL
Server, los miembros de rol fijo de servidor sysadmin, el inicio de sesión sa y los
propietarios de la base de datos especifican las bases de datos como el usuario
dbo). El usuario dbo tiene todos los permisos en la base de datos y no se puede
limitar ni quitar. dbo representa el propietario de la base de datos, pero la cuenta de
usuario dbo no es lo mismo que el rol fijo de base de datos db_owner, mientras que
el rol fijo de base de datos db_owner no es lo mismo que la cuenta de usuario que
se registra como el propietario de la base de datos.

El usuario dbo tiene la propiedad del esquema dbo. El esquema dbo es el

predeterminado para todos los usuarios, salvo que se especifique otro. El esquema
dbo no puede quitarse.

Rol público de base de datos y de servidor

Cada inicio de sesión pertenece al rol fijo de servidor public y cada usuario de base
de datos pertenece al rol de base de datos public. Cuando a un usuario o inicio de
sesión no se le han concedido ni denegado permisos concretos para un elemento
protegible, hereda los permisos para ese elemento concedidos a public. El rol fijo
de servidor public y el de base de datos public no pueden quitarse. Sin embargo, se
puede revocar los permisos de los roles public. Hay muchos de los permisos que se
asignan a los roles public de forma predeterminada, la mayoría de estos permisos
son necesarios para realizar operaciones rutinarias en la base de datos (el tipo de
tareas que todo el mundo debe poder hacer). Tenga cuidado al revocar permisos
desde el usuario o el inicio de sesión público, ya que afectará a todos los inicios de
sesión y usuarios. Normalmente, no debe denegar permisos a public, ya que la
instrucción deny invalida cualquier instrucción grant que podrían crear para los
usuarios.
INFORMATION_SCHEMA y usuarios y esquemas sys

Todas las bases de datos incluyen dos entidades que aparecen como usuarios en
las vistas de catálogo: INFORMATION_SCHEMA y sys. Estas entidades son
necesarias para uso interno por parte del motor de base de datos y no se pueden
modificar ni quitar.

Inicios de sesión de SQL Server basados en certificados

Las entidades de seguridad de servidor con nombres incluidos entre signos de

número dobles (##) son exclusivamente para uso interno del sistema. Las siguientes
entidades de seguridad se crean a partir de certificados cuando se instala SQL
Server y no deben eliminarse.

 ##MS_SQLResourceSigningCertificate##
 ##MS_SQLReplicationSigningCertificate##
 ##MS_SQLAuthenticatorCertificate##
 ##MS_AgentSigningCertificate##
 ##MS_PolicyEventProcessingLogin##
 ##MS_PolicySigningCertificate##
 ##MS_PolicyTsqlExecutionLogin##

Estas cuentas principales no tienen contraseñas que los administradores puedan

cambiar, ya que se basan en certificados emitidos a Microsoft.

Usuario guest (invitado)

Cada base de datos incluye un usuario guest, aunque se encuentra deshabilitada

de forma predeterminada, excepto en la base de datos "master" y "tempdb", en las
que se encuentra siempre habilitado. Es el usuario que permite que aquellos inicios
de sesión que no tienen cuenta de usuario en una base de datos, puedan realizar
el acceso. Los permisos que se pueden aplicar a este usuario son los mismos que
al resto. Los permisos concedidos al usuario guest se aplican a todos los usuarios
que tienen acceso a la base de datos, pero no disponen de una cuenta en la base
de datos. No se puede quitar el usuario guest, pero se puede deshabilitar si se
revoca su permiso CONNECT. El permiso CONNECT se puede revocar si se
ejecuta REVOKE CONNECT FROM GUEST; en cualquier base de datos que no
sea master ni tempdb.

Junto con las preocupaciones generales de seguridad de SQL Server, es muy

importante rastrear y documentar cualquier cambio aplicado a una base de datos
en relación con el cumplimiento de las regulaciones. Todas las regulaciones de
cumplimiento (por ejemplo, Basel II, HIPAA, PCI, FERPA, GLBA y SOX) requieren
auditoría de cualquier cambio en entidades de datos y usuarios que tienen acceso
a los datos. Las soluciones de auditoría deben proveer una documentación
apropiada, como un rastro de evidencia que muestra si la precisión y confiabilidad
de datos importantes no está comprometida.

Las siguientes entidades de usuario están relacionadas a la seguridad de bases de

datos SQL Server:

 Database role membership. SQL Server provee muchos roles como

entidades de seguridad para administrar fácilmente los permisos en base de
datos
 Securables. una lista de los asegurables a los cuales permisos específicos
han sido otorgados o negados a esta entidad de usuario, tales como varios
permisos de alterar, crear, eliminar y ver.

Cualquiera de las propiedades puede ser modificada vía T-SQL (usando la

operación GRANT, REVOKE o DENY) o SQL Server Management Studio.

Para cumplir con los requerimientos de cumplimiento de SQL Server y mantener la

seguridad de la base de datos SQL Server, es necesario auditar los cambios en
entidades de usuario y sus propiedades.

Auditar cambios de seguridad de SQL Server usando desencadenadores DDL

Como una solución nativa, disponible en todas las ediciones SQL Server, los
desencadenadores DDL pueden ser usados para auditar cambios de seguridad en
entidades de usuarios de bases de datos. Para mostrar cómo hacer eso,
rastrearemos los eventos a nivel de base de datos.

CREATE_USER, ALTER_USER y DROP_USER.

CREATE TRIGGER DatabaseUserChange
ON DATABASE
FOR CREATE_USER, ALTER_USER, DROP_USER
AS
SET NOCOUNT ON;
DECLARE
@AuditTable TABLE (
AType nvarchar(max),
AObject varchar(100),
ADate datetime,
AWho varchar(100),
ACommand nvarchar(max)
);
DECLARE
@AType nvarchar(max);
 DECLARE
@AObject varchar(100);
DECLARE
@ATSQL nvarchar(max);
SELECT
@AType = EVENTDATA().value(
'(/EVENT_INSTANCE/EventType)[1]', 'nvarchar(max)')
, @AObject = EVENTDATA().value(
'(/EVENT_INSTANCE/ObjectName)[1]', 'nvarchar(max)')
, @ATSQL = EVENTDATA().value(
'(/EVENT_INSTANCE/TSQLCommand/CommandText)[1]',
'nvarchar(max)');
INSERT INTO @AuditTable
SELECT
@AType, @AObject, GETDATE(), SUSER_SNAME(), @ATSQL;
SET NOCOUNT OFF;
GO

Los desencadenadores DDL de SQL Server pueden ser una solución muy eficiente
y efectiva respecto del costo para rastrear cambios en entidades de usuarios de
bases de datos. De todas maneras, son fáciles de traspasar (un usuario malicioso
con suficientes permisos puede fácilmente deshabilitar el desencadenador, aplicar
cambios en la entidad de usuario y volver a habilitar el desencadenador después).
Algunas desventajas adicionales de este método de auditoría son que no hay un
repositorio de auditoría de evidencia de manipulación y un requerimiento de
conocimiento de T-SQL. T-SQL es requerido no sólo para la configuración, sino para
proveer la información capturada para cualquier tipo de revisión de cumplimiento de
normas o auditoría.

Rastrear cambios en las entidades de usuarios de base de datos SQL Server

usando la característica SQL Server Audit

Otra solución nativa de SQL Server es rastrear los cambios en las entidades de
usuarios de la base de datos usando la característica SQL Serer Audit. Auditar a
nivel de base de datos es soportado por las ediciones de SQL Server Enterprise y
Developer solamente.

Para configurar la característica SQL Server Audit, T-SQL y SQL Management

Studio pueden ser usados.

Para configurar la característica SQL Server Audit para rastrear cambios en las
entidades de usuario de la base de datos:

1. Expanda la carpeta Security en el panel Object Explorer

 2. Seleccione New Audit desde el menú contextual de carpetas Audits y
establezca Audit name (por ejemplo, AuditDatabaseUsers) y File path (donde
la información capturada será grabada en un archivo .sqlaudit)
3. Haga clic en OK para confirmar la creación del objeto de auditoría SQL
Server
4. Seleccione la opción Enable Audit desde el menú contextual del objeto de
auditoría creado

Después de que el objeto de auditoría es creado o habilitado, es necesario definir

la auditoría en la base de datos creando una especificación de auditoría de base de
datos. Los siguientes pasos deben ser realizados para cada base de datos que será
monitoreada para cambios en entidades de usuarios de base de datos. En el
siguiente ejemplo, usaremos SQL Server Management Studio. Note que el
correspondiente T-SQL para cada paso puede ser creado usando la opción
CREATE TO en el panel de vista de árbol Object Explorer.

1. Expanda la base de datos en Object Explorer

2. Expanda la carpeta Security3. Seleccione New Database Audit Specification
en el menú contextual de la carpeta Database Audit Specification
3. Establezca el nombre de la nueva especificación de auditoría de base de
datos (por ejemplo, DatabaseAuditUsersSpecification) y usando el menú
desplegable Audit,
4. seleccione la auditoría SQL Server previamente creada. Para afinar la
auditoría, en nuestro caso, para especificar los cambios auditados en las
entidades de usuarios de base de datos, establezca las siguientes filas de
Audit Action Type:
DATABASE_ROLE_MEMBER_CHANGE_GROUP,
DATABASE_PERMISSION_CHANGE_GROUP,
and DATABASE_PRINCIPAL_CHANGE_GROUP
5. Grabe la especificación de auditoria de la base de datos, y habilítela desde
su menú contextual seleccionando la opción Enable Database Audit
Specification

Después de que las especificaciones de auditoría de la base de datos y objetos

fueron configuradas, cada cambio en las entidades de usuarios será rastreado y
grabado en el archivo .sqlaudit. Aunque el archivo .sqlaudit puede ser abierto desde
el menú contextual del objeto de auditoría AuditDatabaseUsers (la opción View
Audit Logs), ese no es un método conveniente, como tampoco es una buena forma
para proveer datos auditados.

Otra forma de proveer información capturada es usar la función fn_get_file_audit

que lee los archivos *.sqlaudit creados por la característica SQL Server Audit. El
siguiente script recupera la información relacionada con las sentencias DDL y las
acciones que cambiaron las entidades de usuarios:
SELECT
event_time ,
session_server_principal_name AS UserName ,
server_instance_name AS ServerName,
database_name ,
object_name ,
statement
FROM
sys.fn_get_audit_file('C:\AUDITs\AuditDatabaseUsers*.sqlaudit',
DEFAULT, DEFAULT);

Similar a los desencadenadores DDL, las características SQL Server Audit no

provee un repositorio de evidencia de manipulación, puede ser fácilmente
deshabilitado por un usuario con suficientes permisos y requiere T-SQL para
reportes y análisis exhaustivos de la información capturada.

Solución de auditoría por defecto para cambios en la seguridad de bases de

datos SQL Server

ApexSQL Audit es una herramienta de cumplimiento de normas de SQL Server que

provee un amplio rango de características de monitoreo y reportes de una manera
fácil como apuntar y hacer clic. Asegura la seguridad de SQL Server y los
requerimientos de cumplimiento auditando el acceso y los cambios a múltiples
instancias SQL Server y sus objetos.

Para auditar cambios en las entidades de usuario de la base de datos en una base
de datos específica SQL Server:

1. Inicie el GUI de ApexSQL Audit GUI

2. Seleccione la instancia SQL Server y seleccione la base de datos que desea
rastrear por cambios
3. Para afinar el rastreo hacia capturar cambios en las entidades de usuarios
de la base de datos, seleccione las opciones DDL y Security en la sección
Operation types Si usted necesita auditar múltiples instancias SQL Server o
bases de datos, repita los pasos 2 y 3 de acuerdo a las instancias y bases de
datos deseadas.
4. Para confirmar la selección de configuraciones, haga clic en la opción Apply
en la cinta pop-up amarilla

Los reportes integrados que proveen información acerca de cambios en las

entidades de usuarios de la base de datos son Security configuration history, Role
history, y User history. Estas plantillas de reportes difieren en los campos de
parámetros usados para filtrar la información capturada y los tipos de columna
usados para presentar la información.
Para ver la información, haga clic en el botón View reports en la barra de
herramientas principal y use cualquiera de los reportes previamente listados.
También, en el caso de requerimientos adicionales en proveer documentación de
auditoría, lo cual es común en caso de revisiones de cumplimiento, ApexSQL Audit
provee un diseñador de reportes personalizado e integrado.

El proceso de rastrear la seguridad de una base de datos SQL Server vía ApexSQL
Audit provee:

 Monitoreo y reportes sin uso ni conocimiento de T-SQL

 Configuración de apuntar y hacer clic
 Auditoría automática de todos los cambios de seguridad, sin importar el rol
SQL al que pertenece el usuario que hizo el cambio
 Identificación de riesgos de seguridad y problemas de cumplimiento
potenciales
 Un repositorio centralizado con la característica de archivar
 Evidencia precisa de manipulación y reportes personalizables y exhaustivos
para análisis y revisiones
 Soporte para todas las ediciones de SQL Server, excepto la edición SQL
Server Express

La seguridad y el cumplimiento de normas para bases de datos SQL Server pueden

ser hechos vía características nativas de SQL Server o usando herramientas de
terceros como ApexSQL Audit. pero incluso los métodos nativos no proveen
repositorios de evidencia de manipulación y requieren conocimientos avanzados de
T-SQL para configurar, monitorear y reportar. ApexSQL Audit proveyendo un
método de auditoría y reporte amigable para el usuario y eficiente, junto con la
solución todo en uno para múltiples instancias SQL Server y sus bases de datos.
 5. CONCLUSIONES

Según en el análisis efectuado sobre el SMBD, se pudo determinar y detallar en

este documento todo lo relacionado con las características y funciones de seguridad
del SMBD, esto con el fin de identificar las fortalezas y beneficios que nos brinda
este tipo de aplicaciones para la gestión y seguridad de la información.
 6. BIBLIOGRAFIA

https://docs.microsoft.com/es-es/sql/relational-databases/security/securing-sql-
server?view=sqlserver-2017

https://solutioncenter.apexsql.com/es/seguridad-y-cumplimiento-de-normas-para-
bases-de-datos-sqlserver/

http://cessor.blogspot.com/2016/11/administracion-de-sql-server-2014.html