CARACTERÍSTICAS Y FUNCIONES DE SEGURIDAD DEL SGBD

MARÍA CLAUDIA ACEVEDO

ESPECIALIZACIÓN TECNOLÓGICA GESTIÓN Y SEGURIDAD DE BASE DE

DATOS
MODALIDAD VIRTUAL

SERVICIO NACIONAL DE APRENDIZAJE

2019
 INTRODUCCIÓN
Un SGBD (Sistema Gestor de Base de Datos) es un conjunto de programas que
nos permiten gestionar bases de datos. Es decir, realiza las funciones de modificar,
extraer y almacenar información de una base de datos, además de poseer
herramientas con funciones de eliminar, modificar, analizar, etc… datos de estas.
Realiza la función concreta de interfaz entre la base de datos y los usuarios finales
o los programas correspondientes, organizando los datos y permitiendo su acceso.
El éxito del SGBD reside en mantener la seguridad e integridad de los datos. El
problema de la seguridad consiste en lograr que los recursos de un sistema sean,
bajo toda circunstancia, utilizados para los fines previstos. En este taller, vamos a
ver cuáles son las características en cuanto a seguridad en SQL Server.
 SEGURIDAD EN MICROSOFT SQL SERVER

Una estrategia de defensa exhaustiva, con niveles superpuestos de seguridad, es

la mejor manera de enfrentarse a las amenazas a la seguridad. SQL Server
proporciona una arquitectura de seguridad diseñada para permitir a los
administradores de bases de datos y desarrolladores crear aplicaciones de base de
datos seguras y contrarrestar las amenazas. En cada versión de SQL Server se han
introducido mejoras a las versiones anteriores con nuevas características y
funcionalidades. No obstante, la seguridad no es una característica integrada más.
Cada aplicación tiene requisitos de seguridad propios. Los desarrolladores tienen
que saber cuál es la combinación de características y funcionalidades más
apropiada para contrarrestar las amenazas conocidas, así como anticiparse a las
que puedan ir apareciendo en el futuro.
Una instancia de SQL Server contiene un conjunto jerárquico de entidades,
empezando por el servidor. Cada servidor contiene varias bases de datos y, a su
vez, cada base de datos contiene un conjunto de objetos susceptibles de ser
protegidos. Cada SQL Server protegible tiene permisos asociados que se pueden
conceder a una entidad de seguridad, que es una persona, grupo o proceso al que
se concede acceso a SQL Server. El marco de seguridad de SQL Server administra
el acceso a las entidades protegibles a través de la autenticación y la autorización.
La autenticación es el proceso de inicio de sesión en SQL Server por el que una
entidad de seguridad solicita el acceso mediante el envío de credenciales que el
servidor evalúa. La autenticación establece la identidad del usuario o proceso que
se autentica.
La autorización es el proceso con el que se determinan los recursos susceptibles
de protegerse a los que tiene acceso una entidad de seguridad, así como las
operaciones que les están permitidas a dichos recursos.
Autenticación en SQL Server
SQL Server admite dos modos de autenticación, el modo de autenticación de
Windows y el modo mixto.
La autenticación de Windows es el modo predeterminado, y a menudo se denomina
seguridad integrada debido a que este modelo de seguridad de SQL Server está
estrechamente integrado con Windows. Para iniciar sesión en SQL Server, se confía
en las cuentas de usuario y grupo específicas de Windows. Los usuarios de
Windows que ya hayan sido autenticados no tienen que presentar credenciales
adicionales.
El modo mixto admite la autenticación tanto de Windows como de SQL Server. Los
pares de nombre de usuario y contraseña se mantienen en SQL Server.
Nota: Se recomienda utilizar la autenticación de Windows siempre que sea posible.
Este modo de autenticación usa una serie de mensajes cifrados para autenticar
usuarios en SQL Server. Cuando se usan SQL Server inicios de sesión, SQL Server
los nombres de inicio de sesión y las contraseñas cifradas se transmiten a través de
la red, lo que hace que sean menos seguros.
Los inicios de sesión son distintos de los usuarios de base de datos. Los inicios de
sesión o grupos de Windows se deben asignar a usuarios o roles de base de datos
en una operación independiente. A continuación, se conceden permisos a los
usuarios o los roles para obtener acceso a los objetos de base de datos.
Escenarios de autenticación
Por lo general la autenticación de Windows es la mejor opción en las siguientes
situaciones:
 Existe un controlador de dominio.
 La aplicación y la base de datos se encuentran en el mismo equipo.
 Está utilizando una instancia de SQL Server Express o LocalDB.
 Los inicios de sesión de SQL se usan habitualmente en las siguientes
situaciones:
 Si se tiene un grupo de trabajo.
 Los usuarios se conectan desde diferentes dominios que no son de
confianza.
 Aplicaciones de Internet, como ASP.NET.
Tipos de inicios de sesión
SQL Server admite tres tipos de inicios de sesión:
Una cuenta de usuario de Windows local o una cuenta de dominio de confianza.
SQL Server se basa en Windows para autenticar las cuentas de usuario de
Windows.
Grupo de Windows. Cuando se concede acceso a un grupo de Windows, se
concede acceso a todos los inicios de sesión de usuario de Windows miembros de
dicho grupo.
Inicio de sesión de SQL Server. SQL Server almacena el nombre de usuario y un
valor hash de la contraseña en la base de datos maestra, y usa métodos internos
de autenticación para comprobar los intentos de inicio de sesión.
Nota: SQL Server proporciona inicios de sesión creados a partir de certificados o
claves asimétricas que solo se usan para la firma de código. No se pueden utilizar
para conectarse a SQL Server.
Modo mixto de autenticación
Si tiene que usar el modo mixto de autenticación, debe crear inicios de sesión de
SQL Server, que se almacenan en SQL Server. A continuación, debe proporcionar
el nombre de usuario y la contraseña de SQL Server en tiempo de ejecución.
Importante: SQL Server se instala con un inicio de sesión de SQL Server
denominado sa (como abreviatura de "system administrator", administrador de
sistema). Asigne una contraseña segura al inicio de sesión sa y no use el inicio de
sesión sa en la aplicación. El inicio de sesión sa se asigna al rol fijo de servidor
sysadmin, que dispone de credenciales administrativas irrevocables en todo el
servidor. Si un atacante obtiene acceso como administrador de sistema, los daños
pueden ser incalculables. Todos los miembros del grupo BUILTIN\Administrators de
Windows (el grupo de administradores locales) son miembros del rol sysadmin de
forma predeterminada, pero se pueden quitar de este rol.
SQL Server proporciona mecanismos de directiva de contraseñas de Windows para
los inicios de Windows Server 2003 sesión de SQL Server cuando se ejecuta en o
versiones posteriores. Las directivas de complejidad de contraseñas están
diseñadas para impedir ataques por fuerza bruta mediante el aumento del número
de contraseñas posibles. SQL Server puede aplicar las mismas directivas de
complejidad y expiración Windows Server 2003 que se usan en a las contraseñas
que se usan dentro de SQL Server.
Importante: Cuando se utiliza la concatenación de cadenas de conexión a partir
de la entrada de usuario, el sistema se hace vulnerable ante los ataques de
inyección de cadenas de conexión. Utilice SqlConnectionStringBuilder para crear
cadenas de conexión sintácticamente válidas en tiempo de ejecución. Para obtener
más información, vea Generadores de cadenas de conexión.

Roles de servidor y base de datos en SQL Server:

Todas las versiones de SQL Server usan la seguridad basada en roles, que permite
asignar permisos a un rol, o grupo de usuarios, en lugar de asignarlos a usuarios
individuales. Los roles fijos de servidor y base de datos cuentan con un conjunto fijo
de permisos asignados.
Roles fijos de servidor
Los roles fijos de servidor cuentan con un conjunto fijo de permisos y ámbito de
servidor. Están pensadas para su uso en la administración de SQL Server y los
permisos asignadas a ellas no se pueden modificar. Se pueden asignar inicios de
sesión a los roles fijos de servidor sin necesidad de disponer de una cuenta de
usuario en una base de datos.
 Importante: El rol fijo de servidor sysadmin incluye a todos los demás roles y
cuenta con un ámbito ilimitado. No agregue entidades de seguridad a este rol a
menos que sean de total confianza. Los miembros del rol sysadmin disponen de
permisos administrativos irrevocables en todas las bases de datos y recursos del
servidor.
Sea selectivo a la hora de agregar usuarios a los roles fijos de servidor. Por ejemplo,
el rol bulkadmin permite a los usuarios insertar el contenido de cualquier archivo
local en una tabla, lo que puede poner en peligro la integridad de los datos. Consulte
Libros en pantalla de SQL Server para obtener la lista completa de los permisos y
roles fijos de servidor.
Roles fijos de base de datos
Los roles fijos de base de datos incluyen un conjunto predefinido de permisos
diseñados para permitir administrar grupos de permisos con facilidad. Los miembros
del rol db_owner pueden realizar todas las actividades de configuración y
mantenimiento de la base de datos.
Roles y usuarios de base de datos
Para trabajar con objetos de base de datos, se deben asignar inicios de sesión a
cuentas de usuario de base de datos. Estos usuarios de base de datos se podrán
agregar entonces a roles de base de datos y heredarán los conjuntos de permisos
asociados con estos roles. Se pueden conceder todos los permisos.
A la hora de diseñar la seguridad para la aplicación, también debe tener en cuenta
el rol public, la cuenta de usuario dbo y la cuenta guest.
Rol public
El rol public está contenido en todas las bases de datos, incluidas las bases de datos
del sistema. No se puede eliminar y no se pueden agregar ni quitar usuarios de ella.
Todos los usuarios y los demás roles heredan los permisos concedidos al rol public,
ya que pertenecen de forma predeterminada al rol public. Por tanto, solo debe
conceder al rol public los permisos que desee que tengan todos los usuarios.
Cuenta de usuario dbo
dbo, o propietario de base de datos, es una cuenta de usuario con permisos
implícitos para realizar todas las actividades en la base de datos. Los miembros del
rol fijo del servidor sysadmin se asignan automáticamente a dbo.
La cuenta de usuario dbo se confunde a menudo con el rol fijo de base de datos
db_owner. El ámbito de db_owner es una base de datos y el ámbito de sysadmin
es el servidor completo. La pertenencia al rol db_owner no proporciona privilegios
de usuario dbo.
Cuenta de usuario guest
Después de que un usuario se haya autenticado y se le haya permitido iniciar sesión
en una instancia de SQL Server, debe existir una cuenta de usuario independiente
en cada base de datos a la que tenga acceso el usuario. Si se exige una cuenta de
usuario en cada base de datos, se impide que los usuarios se conecten a una
instancia de SQL Server y puedan tener acceso a todas las bases de datos de un
servidor. La existencia de una cuenta de usuario guest en la base de datos evita
este requisito, ya que permite que un inicio de sesión sin cuenta de usuario de base
de datos tenga acceso a una base de datos.
La cuenta guest es una cuenta integrada en todas las versiones de SQL Server. De
forma predeterminada, está deshabilitada en las bases de datos nuevas. Si está
habilitada, se puede deshabilitar mediante la revocación de su permiso CONNECT,
que se lleva a cabo con la ejecución de la instrucción REVOKE CONNECT FROM
GUEST de Transact-SQL.
Propiedad y separación de esquemas de usuario en SQL Server
Un concepto básico en la seguridad de SQL Server es que los propietarios de los
objetos disponen de permisos irrevocables para administrarlos. No puede quitar
privilegios de un propietario del objeto y no puede eliminar usuarios de una base de
datos si en ella existen objetos que les pertenezcan.
Separación usuario-esquema
La separación del esquema de usuario permite disponer de más flexibilidad en la
administración de los permisos de objeto de base de datos. Un esquema es un
contenedor con nombre para los objetos de base de datos, que permite agrupar los
objetos. La sintaxis de asignación de nombres de cuatro partes para hacer
referencia a los objetos especifica el nombre de esquema.
Propietarios y permisos de esquemas
Los esquemas pueden pertenecer a cualquier entidad de seguridad de base de
datos y una entidad de seguridad puede ser propietaria de varios esquemas. Puede
aplicar reglas de seguridad a un esquema, que heredan todos los objetos incluidos
en él. Después de configurar los permisos de acceso de un esquema, estos
permisos se aplican automáticamente a medida que se agregan nuevos objetos al
esquema. Se puede asignar un esquema predeterminado a los usuarios y varios
usuarios de base de datos pueden compartir el mismo esquema.
De forma predeterminada, cuando los programadores crean objetos en un
esquema, éstos pertenecen a la entidad de seguridad a la que pertenece el
esquema y no al programador. La propiedad del objeto se puede transferir con la
instrucción ALTER AUTHORIZATION de Transact-SQL. Un esquema también
puede contener objetos que pertenecen a diferentes usuarios y disponer de más
permisos granulares que los asignados al esquema, si bien esto no resulta
recomendable ya que agrega complejidad a la administración de permisos. Los
objetos se pueden mover entre los esquemas y la propiedad del esquema se puede
transferir entre entidades de seguridad. Se pueden quitar usuarios de base de datos
sin que esto afecte a los esquemas.
Esquemas integrados
SQL Server incluye diez esquemas predefinidos que usan el mismo nombre que los
usuarios y los roles de base de datos integrados. Estos esquemas se han creado
principalmente por compatibilidad con versiones anteriores. No puede quitar los
esquemas con el mismo nombre que las funciones fijas de base de datos, aunque
no los necesite. No puede colocar los siguientes esquemas:
dbo, guest, sys , INFORMATION_SCHEMA
Si los quita de la base de datos modelo, no aparecerán en las nuevas bases de
datos.
Nota: Los esquemas sys y INFORMATION_SCHEMA están reservados para los
objetos del sistema. No puede crear objetos en ellos ni quitarlos.
Esquema dbo
dbo es el esquema predeterminado en una base de datos recién creada. El
esquema dbo pertenece a la cuenta de usuario dbo. De forma predeterminada, los
usuarios creados con el comando CREATE USER de Transact-SQL usan dbo como
esquema predeterminado.
Los usuarios a los que se asigna el esquema dbo no heredan los permisos de la
cuenta de usuario dbo. Los usuarios no heredan ningún permiso de un esquema;
los permisos de esquema se heredan en los objetos de base de datos incluidos en
el esquema.
Nota: Cuando se hace referencia a objetos de base de datos con un nombre de una
sola parte, SQL Server busca en primer lugar en el esquema predeterminado del
usuario. Si no se encuentra el objeto, SQL Server busca a continuación en el
esquema dbo. Si el objeto tampoco se encuentra en el esquema dbo, se muestra
un error.
Autorización y permisos en SQL Server
Al crear objetos de base de datos, se deben conceder permisos de forma explícita
para que los usuarios tengan acceso a ellos. Cada objeto susceptible de protegerse
tiene permisos que se pueden otorgar a una entidad de seguridad mediante
instrucciones de permiso.
Principio de los privilegios mínimos
Desarrollar una aplicación utilizando un enfoque basado en cuenta de usuario de
privilegios mínimos (LUA) constituye una parte importante de una estrategia de
defensa exhaustiva contra las amenazas a la seguridad. El enfoque LUA garantiza
que los usuarios siguen el principio de los privilegios mínimos y siempre inician
sesión con cuentas de usuario limitadas. Las tareas administrativas se realizan
utilizando roles fijos del servidor y el uso del rol fijo del servidor sysadmin es muy
restringido.
Cuando conceda permisos a usuarios de base de datos, siga siempre el principio
de los privilegios mínimos. Otorgue a usuarios y roles los mínimos permisos
necesarios para que puedan realizar una tarea concreta.
Permisos basados en roles
Otorgar permisos a roles en lugar de a usuarios simplifica la administración de la
seguridad. Los conjuntos de permisos asignados a roles los heredan todos los
miembros del rol. Es más fácil agregar o quitar usuarios de un rol que volver a crear
conjuntos de permisos distintos para cada usuario. Los roles se pueden anidar. Sin
embargo, la existencia de demasiados niveles de anidamiento puede reducir el
rendimiento. También puede agregar usuarios a roles fijos de bases de datos para
simplificar los permisos de asignación.
Puede conceder permisos en el nivel de esquema. Los usuarios heredan
automáticamente los permisos en todos los objetos nuevos creados en el esquema;
no es necesario otorgar permisos cuando se crean objetos nuevos.
Permisos a mediante código basado en procedimiento
El encapsulamiento del acceso a los datos a través de módulos tales como
procedimientos almacenados y funciones definidas por el usuario brinda un nivel de
protección adicional a la aplicación. Se puede evitar que los usuarios interactúen
directamente con objetos de la base de datos otorgando permisos solo a
procedimientos almacenados o funciones, y denegando permisos a objetos
subyacentes tales como tablas. SQL Server lo consigue mediante encadenamiento
de propiedad.
Instrucciones de permiso
En la siguiente tabla se describen las tres instrucciones de permiso de Transact-
SQL.
GRANT: Concede un permiso.
REVOKE: Revoca un permiso. Este es el estado predeterminado de un objeto
nuevo. Un permiso revocado a un usuario o rol se puede heredar de otros grupos o
roles a los que está asignada la entidad de seguridad.
DENY DENY: revoca un permiso de manera que no pueda ser heredado. DENY
tiene prioridad sobre todos los permisos, pero no se aplica a propietarios de objeto
o miembros de sysadmin. Si deniega permisos a un objeto en el rol public, se los
deniega igualmente a todos los usuarios y roles excepto a los propietarios del objeto
y a los miembros de sysadmin.
La instrucción GRANT puede asignar permisos a un grupo o rol que puede ser
heredada por los usuarios de la base de datos. No obstante, la instrucción DENY
tiene prioridad sobre el resto de las instrucciones de permiso. Por ello, un usuario al
que se le ha denegado un permiso no puede heredarlo de otro rol.
Cadenas de propiedad
SQL Server garantiza que solamente puedan tener acceso a los objetos las
entidades de seguridad a las que se les han concedido permisos. Cuando varios
objetos de base de datos tienen acceso el uno al otro, la secuencia se conoce como
"cadena". Cuando SQL Server atraviesa los vínculos de la cadena, evalúa los
permisos de manera diferente a como lo haría si estuviera obteniendo acceso a
cada elemento separadamente. Cuando se obtiene acceso a un objeto a través de
una cadena, SQL Server primero compara al propietario del objeto con el propietario
del objeto de llamada (el vínculo anterior de la cadena). Si ambos objetos tienen el
mismo propietario, los permisos del objeto al que se hace referencia no se
comprueban. Siempre que un objeto obtiene acceso a otro objeto que tiene un
propietario distinto, la cadena de propiedad se rompe y SQL Server debe comprobar
el contexto de seguridad del llamador.
Código basado en procedimiento y encadenamiento de propiedad
Suponga que a un usuario se le otorgan permisos para ejecutar en un procedimiento
almacenado que selecciona datos desde una tabla. Si el procedimiento almacenado
y la tabla tienen el mismo propietario, el usuario no necesita ningún permiso en la
tabla y se le pueden incluso denegar permisos. Sin embargo, si el procedimiento
almacenado y la tabla tienen distintos propietarios, SQL Server debe comprobar los
permisos del usuario en la tabla antes de permitirle el acceso a los datos.
Nota: El encadenamiento de propiedad no se aplica en el caso de las instrucciones
de SQL dinámico. Para llamar a un procedimiento que ejecuta una instrucción SQL,
el llamador debe tener permiso de acceso a las tablas subyacentes, lo que deja a
su aplicación expuesta a posibles ataques de inyección SQL. SQL Server
proporciona nuevos mecanismos, como suplantación y módulos de firma con
certificados, que no requieren otorgar permisos en las tablas subyacentes. Estos
mecanismos se pueden utilizar también con procedimientos almacenados CLR.
Cifrado de datos en SQL Server
SQL Server proporciona funciones para cifrar y descifrar datos con un certificado,
una clave asimétrica o una clave simétrica. El programa administra estas opciones
en un almacén de certificados interno. El almacén usa una jerarquía de cifrado que
protege los certificados y las claves en un nivel, con la capa por encima de él en la
jerarquía. Esta área de características de SQL Server se denomina almacenamiento
secreto.
El modo más rápido de cifrado que admiten las funciones de cifrado es el cifrado de
clave simétrica. Este modo resulta adecuado para controlar grandes volúmenes de
datos. Las claves simétricas se pueden cifrar mediante certificados, contraseñas u
otras claves simétricas.
Claves y algoritmos
SQL Server admite varios algoritmos de cifrado de clave simétrica, incluidos DES,
Triple DES, RC2, RC4, RC4 de 128 bits, DESX, AES de 128 bits, AES de 192 bits
y AES de 256 bits. Los algoritmos se implementan con la API Windows Crypto.
En el ámbito de una conexión de base de datos, SQL Server puede mantener varias
claves simétricas abiertas. Las claves abiertas se recuperan del almacén y están
disponibles para descifrar datos. Cuando se descifra un elemento de datos, no es
necesario especificar la clave simétrica que se debe usar. Cada valor cifrado
contiene el identificador de clave (GUID de clave) de la clave usada para cifrarlo. Si
se descifra la clave correcta y está abierta, el motor crea una correspondencia entre
la secuencia de bytes cifrada y la clave simétrica abierta. Esta clave se utiliza para
realizar el descifrado y devolver los datos. Si no está abierta la clave correcta, se
devuelve NULL.
Seguridad de integración de CLR en SQL Server
Microsoft SQL Server proporciona la integración del componente Common
Language Runtime (CLR) de .NET Framework. La integración de CLR permite
escribir procedimientos almacenados, desencadenadores, tipos definidos por el
usuario, funciones definidas por el usuario, agregados definidos por el usuario y
funciones con valores de tabla de secuencias, mediante el uso de cualquier lenguaje
de .NET Framework, como Microsoft Visual Basic .NET o Microsoft Visual C#.
El CLR admite un modelo de seguridad llamado seguridad de acceso del código
(CAS) para el código administrado. En este modelo, se conceden permisos a los
ensamblados en función de la evidencia que proporciona el código en los
metadatos. SQL Server integra el modelo de seguridad basado en usuario de SQL
Server con el modelo de seguridad basado en el acceso del código de CLR.
Escenarios de seguridad de aplicaciones en SQL Server
No hay una única forma correcta de crear una aplicación cliente segura de SQL
Server. Cada aplicación tiene unas necesidades, un entorno de implementación y
un grupo de usuarios específicos. Una aplicación que es razonablemente segura en
el momento en que se implementa puede volverse menos segura con el tiempo. Es
imposible predecir con ninguna seguridad qué amenazas pueden surgir en el futuro.
SQL Server, como producto, ha ido evolucionando a lo largo de muchas versiones
para incorporar las últimas características de seguridad que permiten a los
desarrolladores crear aplicaciones de base de datos seguras. Sin embargo, la
seguridad no debe darse por sentada; es necesario realizar una supervisión y
actualizaciones continuas.
Amenazas comunes
Los desarrolladores han de saber cuáles son las amenazas a la seguridad, las
herramientas con las que cuentan para enfrentarse a ellas y cómo evitar las
vulnerabilidades de seguridad provocadas por los propios usuarios. Se puede
pensar en la seguridad como en una cadena, en la que, si se rompe un vínculo, se
pone en peligro la fortaleza de toda ella. En la siguiente lista se incluyen algunas de
las amenazas a la seguridad más comunes:
inyección de código SQL
La inyección de SQL es el proceso por el cual un usuario malintencionado escribe
instrucciones de Transact-SQL en lugar de entradas válidas. Si la entrada se pasa
directamente al servidor sin haber sido validada y la aplicación ejecuta el código
inyectado por error, el ataque podría dañar o destruir datos. Para frustrar los ataques
por inyección de SQL Server, puede utilizar procedimientos almacenados y
comandos parametrizados, evitar el SQL dinámico y restringir los permisos de todos
los usuarios.
Elevación de privilegios
Los ataques por elevación de privilegios se producen cuando un usuario es capaz
de asumir los privilegios de una cuenta de confianza, como un propietario o un
administrador. Trabaje siempre en cuentas de usuario con los privilegios mínimos y
asigne sólo los permisos necesarios. Evite utilizar cuentas administrativas o de
propietario para ejecutar código. De esta forma se limita el daño que se podría sufrir
en caso de que un ataque tenga éxito. Cuando realice tareas que requieran
permisos adicionales, utilice la firma de procedimientos o la suplantación
únicamente mientras dure la tarea. Puede firmar procedimientos almacenados con
certificados o usar la suplantación para asignar permisos temporalmente.
Sondeos y observación inteligente
Un ataque por sondeo puede utilizar mensajes de error generados por una
aplicación para buscar puntos vulnerables en la seguridad. Implemente el control de
errores en todo el código de procedimiento para evitar que se devuelva la
información de error al usuario final.
Autenticación
Cuando se utilizan inicios de sesión de SQL Server, se pueden producir ataques por
inyección a la cadena de conexión si durante la ejecución se genera una cadena de
conexión basada en los datos introducidos por el usuario. Si en la cadena de
conexión no se comprueba la validez de los pares de palabras clave, un agresor
puede insertar caracteres de más y así podría tener acceso a datos confidenciales
o a otros recursos del servidor. Utilice la autenticación de Windows siempre que sea
posible. Si tiene que utilizar inicios de sesión de SQL Server, use el
SqlConnectionStringBuilder para crear y validar cadenas de conexión durante la
ejecución.
Contraseñas
Muchos ataques tienen éxito porque un intruso es capaz de obtener o adivinar la
contraseña de un usuario con muchos privilegios. Las contraseñas constituyen su
primera línea de defensa contra los intrusos, así que establecer contraseñas
seguras es esencial para la seguridad del sistema. Cree y aplique directivas de
contraseñas para la autenticación en modo mixto.
Asigne siempre una contraseña segura a la cuenta de sa, incluso cuando utilice la
autenticación de Windows.
Administrar permisos con procedimientos almacenados en SQL Server
Un modo de establecer varias líneas de defensa en torno a su base de datos
consiste en implementar el acceso a todos los datos usando procedimientos
almacenados o roles definidos por el usuario. Debe revocar o denegar todos los
permisos a los objetos subyacentes, como tablas, y conceder permisos a los
procedimientos almacenados. Esto crea un perímetro de seguridad en torno a sus
datos y objetos de base de datos.
Ventajas de los procedimientos almacenados
Los procedimientos almacenados ofrecen las siguientes ventajas:
La lógica de datos y las reglas de negocios se pueden encapsular de forma que los
usuarios sólo puedan tener acceso a los datos y objetos tal y como dispongan los
desarrolladores y los administradores de las bases de datos.
Se pueden usar procedimientos almacenados parametrizados que validen todos los
datos introducidos por lo usuarios para frustrar ataques de inyección de SQL. Si
utiliza SQL dinámico, asegúrese de parametrizar los comandos y no incluya nunca
directamente valores de parámetros en la cadena de la consulta.
Se pueden rechazar las consultas ad hoc y las modificaciones de datos. Esto evita
que los usuarios puedan destruir datos de forma malintencionada o por error, o que
ejecuten consultas que perjudiquen al rendimiento del servidor o la red.
Los errores se pueden controlar en el código de procedimiento sin que tengan que
pasar directamente a las aplicaciones cliente. De esta forma, se evita que se
devuelvan los mensajes de error, lo que podría resultar una ayuda para un ataque
por sondeo. Registre los errores y contrólelos en el servidor.
Es posible escribir los procedimientos almacenados una vez y que después tengan
acceso a ellos muchas aplicaciones.
Las aplicaciones cliente no tienen por qué saber nada de las estructuras de datos
subyacentes. El código de procedimiento almacenado se puede cambiar sin
necesidad de hacer cambios en las aplicaciones cliente, siempre y cuando los
cambios no afectan a listas de parámetros ni a tipos de datos devueltos.
Los procedimientos almacenados pueden reducir el tráfico en la red combinando
varias operaciones en una llamada a procedimiento.

Ejecución de procedimiento almacenado

Los procedimientos almacenados aprovechan el encadenamiento de propiedad
para proporcionar acceso a los datos de forma que los usuarios no necesiten tener
permiso explícito para obtener acceso a los objetos de bases de datos. Hay una
cadena de conexión cuando los objetos que tienen acceso los unos a los otros
secuencialmente son propiedad del mismo usuario. Por ejemplo, un procedimiento
almacenado puede llamar a otros procedimientos almacenados o un procedimiento
almacenado puede tener acceso a varias tablas. Si todos los objetos de la cadena
de ejecución tienen el mismo propietario, SQL Server sólo comprueba el permiso
EXECUTE para el autor de la llamada, no los permisos del autor de la llamada sobre
los demás objetos. Por eso, sólo necesita conceder permisos EXECUTE para los
procedimientos almacenados; puede revocar o denegar todos los permisos para las
tablas subyacentes.
Procedimientos recomendados
No basta con escribir procedimientos almacenados para proteger correctamente
una aplicación. También se deberían tener en cuenta las siguientes vulnerabilidades
de seguridad potenciales.
Conceda permisos EXECUTE para los procedimientos almacenados a los roles de
base de datos que quiere que puedan tener acceso a los datos.
Revoque o deniegue todos los permisos a las tablas subyacentes para todas los
roles y usuarios de la base de datos, incluido el rol public. Todos los usuarios
heredan permisos de public. Por eso, denegar permisos a public supone que sólo
los propietarios y los miembros sysadmin tendrán acceso; todos los demás usuarios
no podrán heredar permisos de su pertenencia a otros roles.
No agregue usuarios ni roles a los roles sysadmin o db_owner. Los administradores
del sistema y los propietarios de bases de datos pueden tener acceso a todos los
objetos de base de datos.
Deshabilite la cuenta guest. Esto evitará que usuarios anónimos se conecten a la
base de datos. La cuenta de invitado está deshabilitada por defecto en las nuevas
bases de datos.
Implemente el control de errores y registre los errores.
Cree procedimientos almacenados parametrizados que validen todos los datos
introducidos por los usuarios. Trate todos los datos introducidos por los usuarios
como si no fueran de confianza.
Evite el SQL dinámico a menos que sea absolutamente necesario. Utilice la función
Transact-SQL QUOTENAME() para delimitar un valor de cadena y evite usar el
delimitador en la cadena de entrada.
 CIBERGRAFÍA

https://emigrar2016.wordpress.com/2016/10/25/tabla-campos-
registros/#targetText=Un%20sistema%20gestor%20de%20bases,en%20una%20b
ase%20de%20datos.
http://gplsi.dlsi.ua.es/bbdd/bd1/lib/exe/fetch.php?media=bd1:0910:trabajos:segurid
adbd.pdf
http://webdiis.unizar.es/asignaturas/BD/transparenciasBD/PDFs_1x1/leccion_2.pdf
http://webdiis.unizar.es/asignaturas/BD/transparenciasBD/PDFs_1x1/leccion_2.pdf
https://docs.microsoft.com/es-es/dotnet/framework/data/adonet/sql/overview-of-sql-
server-security
http://gestionyseguridadbd.blogspot.es/1460086267/caracteristicas-y-funciones-
de-seguridad-sql-server/