Seguridad de SQL Server
Seguridad de SQL Server
SQL Server incluye diferentes
características que admiten la creación de aplicaciones de
base de datos seguras.
Las consideraciones comunes de
seguridad, como el robo de datos o el vandalismo, se aplican independientemente
de la versión de SQL Server que se utilice. La integridad de los datos
también se debe considerar como un problema de seguridad. Si los datos no están
protegidos, es posible que acaben perdiendo su valor si se permite la
manipulación de datos ad hot y los datos se modifican sin intención o de forma
malintencionada con valores incorrectos o bien se eliminan por
completo. Además, a menudo existen requisitos legales que se deben
cumplir, como el almacenamiento correcto de información confidencial. El
almacenamiento de determinados tipos de datos personales está totalmente
prohibido, en función de las leyes que se apliquen en una jurisdicción determinada.
Cada versión de SQL Server incluye
diferentes características de seguridad, al igual que cada versión de Windows,
y las versiones posteriores cuentan con funcionalidad mejorada con respecto a
las anteriores. Es importante comprender que las características de
seguridad no pueden garantizar por sí solas una aplicación de base de datos
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 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.
Las cuentas y roles de SQL Server
tienen un papel fundamental en la seguridad de Windows Server AppFabric.
AppFabric usa estas entidades de SQL Server para controlar el acceso a
almacenes y tablas que contienen datos de operaciones de seguimiento, así como
datos de control de estado relacionados con la persistencia de flujo de
trabajo. AppFabric no ofrece herramientas para la administración de la
seguridad de base de datos. Si desea crear cuentas y roles y ver, manipular y
asignar los permisos adecuados a los objetos de base de datos, use las
herramientas de ayuda que se incluyen con la instalación de la base de datos.
Para SQL Server, use SQL Server Management Studio.
AppFabric usa los inicios de sesión y
roles de SQL Server para administrar el acceso a activos como los almacenes de
seguimiento y persistencia y los procedimientos almacenados. Se usan permisos
para aplicar directivas de seguridad a tablas y procedimientos almacenados para
determinar quién puede leer, escribir y realizar operaciones administrativas en
los esquemas de seguimiento y persistencia. Cada esquema se protege mediante su
propio grupo de directivas de seguridad.
Modos de autenticación de SQL Server y AppFabric
SQL Server ofrece dos métodos para
proteger la autenticación en sus servidores de bases de datos AppFabric:
Autenticación de Windows. Modo de
autenticación de Windows predeterminado. Es el más seguro para SQL Server. Si
se configura el modo de autenticación de Windows, SQL Server usa la seguridad
de Windows para validar la cuenta y la contraseña de la cuenta de usuario
solicitante con el sistema operativo Windows.
Autenticación de SQL Server. Modo de
autenticación de SQL Server. Su finalidad es ofrecer compatibilidad con
versiones anteriores a aplicaciones y usuarios que necesiten acceso a SQL
Server con una cuenta de usuario y contraseña específicas. Es el modo menos
seguro.
Aunque AppFabric también funciona con
la autenticación de SQL Server, no es recomendable pasar nombres de cuentas de
usuario y contraseñas integradas en una cadena de conexión de un archivo de
configuración. Se recomienda configurar SQL Server para que use el modo de
autenticación de Windows y evitar el modo de autenticación de SQL Server.
Si necesita usar el modo de
autenticación de SQL Server o si usa un proveedor distinto de SQL Server que
requiere el almacenamiento de contraseñas en la cadena de conexión, es
recomendable que use cadenas de conexión cifradas. AppFabric no puede procesar
las secciones cifradas de un archivo de configuración, de modo que no podrá
usar las herramientas de AppFabric para ver o agregar cadenas de conexión
cifradas.
Si necesita proteger los archivos de
configuración en un equipo con AppFabric cifrando partes de un archivo de
configuración, use la herramienta de registro de IIS en ASP.NET
(Aspnet_regiis.exe). Esta herramienta permite cifrar (opción -pe)
cualquier sección crítica para la seguridad de un archivo de configuración
fuera de la interfaz de usuario de AppFabric. Si más adelante necesita ver o
modificar dicha sección, puede descifrarla mediante la opción –pd.
Descifrar estas secciones permite verlas en las herramientas de AppFabric,
aplicar cambios, guardar los cambios en el archivo de configuración y volver a
cifrarlas usando la herramienta fuera de AppFabric.
Inicios de sesión de SQL Server
Un inicio de sesión de SQL Server
requiere una cuenta de usuario y contraseña para iniciar sesión en el equipo
con SQL Server. En la terminología de seguridad de Windows, puede verlo como
derecho de acceso o autenticación. SQL Server usa la autenticación integrada de
Windows para identificar los principios de seguridad para el acceso o la
administración de los recursos de la base de datos de AppFabric. Para conectar
a SQL Server con la autenticación integrada de Windows, debe proporcionar la
identidad de Windows con la que se ejecuta la aplicación. También debe estar
seguro de que esta identidad dispone del acceso adecuado a la base de datos de
SQL Server.
Para realizar acciones de configuración
o funcionamiento sobre los esquemas o datos de la base de datos, la cuenta de
inicio de sesión debe estar asignada a un rol de SQL Server con los permisos
adecuados. Un rol de SQL Server funciona como un grupo de Windows. La
asignación de una cuenta de inicio de sesión a un rol de SQL determina el
control de dicha cuenta sobre las actividades administrativas y las operaciones
en la base de datos. Una cuenta de inicio de sesión puede estar asignada a más
de un rol de base de datos.
Estos inicios de sesión de SQL Server
se crean al instalar AppFabric.
Nombre de inicio de sesión
|
Cuenta de Windows
|
Miembros de la función de la base de datos
|
AS_Administrators
|
LOCALHOST\AS_Administrators
|
|
AS_Observers
|
LOCALHOST\AS_Observers
|
|
IIS_IUSRS
|
BUILTIN\IIS_IUSRS
|
|
Roles de base de datos de SQL Server
SQL Server tiene tres tipos
de roles de bases de datos: servidor, aplicación y base de datos. A fin de
ofrecer una información exhaustiva, a continuación se describen detalladamente.
AppFabric usa el modelo de rol de base de datos de forma exclusiva para la
mayoría de su seguridad en SQL Server.
- Rol de “servidor”
de SQL Server. Un
rol de “servidor” de SQL Server se define a nivel de servidor fuera de
cualquier almacén. Los roles de SQL Server están predefinidos y su número
y su contenido no se pueden modificar. Un ejemplo de rol de servidor común
es sysadmin. Este rol ofrece a la cuenta de inicio de sesión un control
total sobre todas las operaciones de la base de datos y la capacidad de
realizar cualquier operación sobre los datos de SQL Server de cualquier
almacén. El modelo de seguridad de AppFabric no usa ningún rol de servidor
explícitamente.
- Rol de
“aplicación” de SQL Server. Los roles de aplicación satisfacen las
necesidades de seguridad más complejas y personalizadas de una aplicación
particular. Varias aplicaciones pueden usar un almacén con la necesidad
común de proteger la seguridad de sus datos durante el acceso de una de
las aplicaciones. El modelo de seguridad de AppFabric no usa roles de
aplicación explícitamente.
- Rol de
“base de datos” de SQL Server. AppFabric usa el rol de base de datos de
forma generalizada. Existen tres tipos de roles de base de datos:
públicos, definidos por el usuario y fijos. A fin de ofrecer una
información exhaustiva, a continuación se describen detalladamente.
AppFabric usa el modelo de rol de base de datos definido por el usuario de
forma exclusiva para gran parte de su seguridad en SQL Server.
Existen tres tipos de roles de base de datos de SQL Server: - Público. El rol de base de
datos público contiene un permiso de acceso predeterminado para todos los
usuarios de base de datos. Por lo tanto, todas las cuentas de inicio de
sesión que se crean a través de AppFabric son miembros de este rol.
- Fijo. Del mismo modo que
los roles de “servidor” de SQL Server (por ejemplo, sysadmin), los roles
de base de datos fijos no se pueden modificar. Al contrario de lo que
sucede con los roles de servidor, que existen a nivel de servidor, los
roles de base de datos existen a nivel de base de datos para cada
almacén. Un ejemplo de rol de base de datos fijo es db_owner. Se pueden
agregar o quitar cuentas de usuario de inicio de sesión de SQL Server a
roles de base de datos fijos.
- Definido
por el usuario. AppFabric
crea roles de base de datos definidos por el usuario específicos en
blanco durante la instalación. El programa de instalación de AppFabric no
inserta explícitamente ninguna cuenta de Windows o cuenta de inicio de
sesión de SQL Server en los roles de base de datos definidos por el
usuario. Para agregar cuentas, es necesario usar las herramientas de
administración de SQL Server.
AppFabric usa roles de base
de datos de SQL Server para controlar el acceso a sus almacenes de datos de
seguimiento y persistencia. Cuando se inicia un nuevo almacén de datos de
seguimiento o persistencia de AppFabric, se crean varios roles de seguridad de base
de datos definidos por el usuario durante la instalación. La tabla siguiente
muestra la asignación de estos roles a los inicios de sesión de SQL Server que
se describen en la sección anterior.
Rol de SQL Server definido por el
usuario
|
Esquema
|
Inicios de sesión asignados
|
Derechos
|
ASMonitoringDbAdmin
|
Seguimiento
|
AS_Administrators
|
Escribir en la tabla de ensayo, leer en vistas de eventos e invocar
procedimientos almacenados de purga y archivado
|
ASMonitoringDbReader
|
Seguimiento
|
AS_Administrators y AS_Observers
|
Leer en vistas de eventos
|
ASMonitoringDbWriter
|
Seguimiento
|
AS_Administrators
|
Escribir en la tabla de ensayo e invocar el procedimiento de
importación
|
Microsoft.ApplicationServer.DurableInstancing.WorkflowAdministrators
|
Persistencia
|
AS_Administrators
|
Poner comandos de control en la cola de comandos del almacén
|
System.Activities.DurableInstancing.InstanceStoreObservers
|
Persistencia
|
AS_Administrators y AS_Observers
|
Leer en vistas de almacén de instancias
|
System.Activities.DurableInstancing.InstanceStoreUsers
|
Persistencia
|
BUILTIN\IIS_IUSRS
|
Invocar procedimientos almacenados que pertenecen a la persistencia
|
Microsoft.ApplicationServer.DurableInstancing.WorkflowManagementServiceUsers
|
Persistencia
|
AS_Administrators
|
Sacar los comandos de control de la cola de comandos del almacén
|
System.Activities.DurableInstancing.WorkflowActivationUsers
|
Persistencia
|
AS_Administrators
|
Consultar las instancias de flujo de trabajo que se pueden activar en
el almacén de instancias
|
EJEMPLO
Identificadores de inicio de sesión: Creación
Crear inicios de sesión, sólo será necesario si vamos a utilizar autenticación
de SQL Server. Cuando se añade el nuevo usuario, SQL Server escribe una
nueva fila en la tabla syslogins de la base de datos master. Esta
tarea puede llevarse a cabo utilizando comandos SQL o a través del
Administrador Corporativo.
Creación de identificadores mediante el Administrador Corporativo
Para añadir un identificador de inicio de sesión desde el Administrador
Corporativo, seleccionamos la carpeta seguridad y dentro de esta, inicios de
sesión que deseemos crearlo, y pulsamos botón derecho del ratón y elegimos
Nuevo inicio de sesión.
A continuación, especificamos la información de
autenticación del identificador a crear.
- Nombre del identificador.
- Tipo de autenticación: Debe marcarse autenticación de SQL Server.
- La contraseña para el identificador.
- La base de datos por defecto para el identificador, en la que se colocará por defecto al usuario.
- El idioma predeterminado para el inicio de sesión.
En la segunda página, Roles del servidor permite
especificar en qué funciones de servidor preestablecidas se incluirá el
identificador de inicio de sesión que va a crearse.
En la página Asignación de usuarios, podremos indicar a qué
bases de datos tendrá acceso el identificador de inicio de sesión y al
usuario de bases de datos a la que se asociará.
La siguiente pestaña es la de elementos protegibles, aquí
podemos dar o denegar
Finalmente en la carpeta Estado podemos conceder o denegar permiso de conexión al motor de base de datos y habilitar o deshabilitar el inicio de sesión.
Creación de inicios de
sesión a través de comandos
Podemos crear inicios de sesión ejecutando el procedimiento almacenado sp_addlogin.
sp_addlogin identificador [, contraseña [, password [, base de datos por defecto, [, lenguaje [, id numérico [, opción de encriptación ]]]]]]
Algunas consideraciones sobre este procedimiento almacenado.
- Puede omitirse la contraseña.
- Si no se especifica la base de datos por defecto, se considerará la master como tal.
- El identificador numérico tiene sentido cuando existe un usuario en la tabla sysusers de una base de datos cuyo id apunte a un identificador de inicio de sesión inexistente, desee crear un nuevo inicio de sesión con el id del usuario de base de datos en cuestión.
- El parámetro opción de encriptación permite especificar si la contraseña se almacena o no encriptada. Si se omite, la contraseña se encriptará. Si ponemos como parámetro skip_encription, la contraseña no se encriptará.
Identificadores de inicio de sesión: Modificación y eliminación
Mediante el Administrador Corporativo
Para modificar las propiedades de un identificador de inicio de sesión desde el
Administrador Corporativo, seleccionamos el inicio de sesión y con el botón
derecho del ratón elegimos propiedades.
Esto nos abre de nuevo las pantallas explicadas anteriormente
con lo que podemos modificar los parámetros elegidos. Si elegimos eliminar
eliminaremos el inicio de sesión.
Modificación y eliminación de inicios de sesión a través de comandos SQL
La información de configuración de un identificador de inicio de sesión puede modificarse con los siguientes procedimientos almacenados.
Base de datos por defecto: sp_defaultdb
Facilita al sistema el nombre de la base de datos a la que un identificador de inicio de sesión accederá al entrar en el sistema.
La sintaxis de uso es:
sp_defaultdb nombre de usuario, base de datos
Idioma por defecto: sp_defaultlanguage
Este procedimiento almacenado facilita al sistema el lenguaje con el que el identificador accederá al iniciar una sesión en el sistema. Su sintaxis es:
sp_defaultlanguage ‘nombre de usuario’ [, ‘lenguaje’]
Cambio de contraseña: sp_password
Este procedimiento almacenado permite cambiar la contraseña de acceso al servidor de un identificador de inicio de sesión.
La sintaxis de uso es:
sp_password ‘contraseña antigua’, ‘contraseña nueva’, [,’usuario’]
Para eliminar un identificador de acceso utilizaremos el procedimiento almacenado sp_droplogin. La ejecución del procedimiento eliminará la línea correspondiente al identificador, en la tabla syslogins. Sólo el administrador del sistema puede ejecutar este procedimiento almacenado.
sp_droplogin nombre de usuario
Usuarios de bases de datos: Creación de usuarios de bases de datos
Crear usuarios de bases de datos significa, en realidad, habilitar identificadores de inicio de sesión para su acceso a una o varias bases de datos.
En función del modo de autenticación del usuario, esto significa habilitar el acceso a una cuenta o grupo de Windows o a un identificador de acceso de SQL Server.
A través del Administrador Corporativo
Posicionados sobre la base de datos, abrimos la carpeta seguridad y debajo de esta aparece la de usuarios, sobre esta carpeta botón derecho del ratón Nuevo usuario.
Esto abre un cuadro de diálogo con varias pestañas. En la primera podremos especificar:
- Tipo de Usuario, a escoger entre los que ya están dados de alta para el acceso al servidor.
- Nombre de usuario. El nombre que deseamos asignar al usuario en la base de datos.
- Nombre de inicio de sesión. Que debe elegir entre los que ya estén creados
- Esquema predeterminado. También se elegirá entre los ya creados.
En el resto de pestañas podemos elegir las funciones de la base
de datos para las que se da acceso o a las que se desea que pertenezca.
Añadiendo usuarios mediante comandos SQL
El procedimiento almacenado de SQL Server permite habilitar a un identificador de acceso o a una cuenta Windows para su acceso a una base de datos:
sp_grantdbaccess o sp_adduser.
sp_grantdbaccess id inicio sesión [,’nombre de usuario’]
id inicio sesión es un identificador de inicio de SQL Server o una cuenta de Windows. Si se omite el nombre de usuario, el usuario en la base de datos utilizará la misma denominación que el identificador de inicio de sesión.
Eliminación de usuarios mediante el Administrador Corporativo
Para eliminar un usuario en el Administrador Corporativo basta con hacer clic en el botón derecho del ratón situados encima del usuario y eliminar.
Eliminación de usuarios mediante
comandos
Para ello se utiliza el método sp_revokedbaccess que elimina un usuario de una base de datos.
sp_revokedbaccess 'usuario'
No pueden eliminarse los usuarios dbo ni el information_schema ni el guest en la base de datos master ni tempdb.
Obteniendo información sobre usuarios
Es posible obtener información sobre los usuarios existentes en una base de datos mediante el procedimiento almacenado sp_helpuser.
sp_helpuser [ ‘nombre de usuario’ ]
Si se omite el nombre del usuario se obtendrá información sobre todos los usuarios de la base de datos.
Roles de base de datos (database roles)
Es posible agrupar a los usuarios para otorgarles conjuntamente permisos de
acceso a base de datos utilizando los Roles de base de datos. Un rol de base de
datos representa un tipo de usuarios, desde el punto de vista de las labores
que pueden realizar, al que se asignarán los permisos necesarios para llevar a
cabo esa tarea.
Este Procedimiento simplifica la gestión al administrador de los aspectos de seguridad, pues permite otorgar conjuntamente permisos a usuarios de perfil similar. Lo más lógico es crear primero los roles de base de datos, y añadir posteriormente los usuarios particulares que se adapten a ese grupo. Existen roles de bases de datos predefinidos.
Este Procedimiento simplifica la gestión al administrador de los aspectos de seguridad, pues permite otorgar conjuntamente permisos a usuarios de perfil similar. Lo más lógico es crear primero los roles de base de datos, y añadir posteriormente los usuarios particulares que se adapten a ese grupo. Existen roles de bases de datos predefinidos.
Gestión de roles de bases de datos: Mediante el Administrador Corporativo
En el Administrador Corporativo, para crear un rol de base a datos de usuario
deberemos acceder a la base de datos en cuestión y desplegando la carpeta
Seguridad y debajo de ella nos colocamos en la carpeta Roles y con el botón
derecho del ratón elegimos Nuevo, esto nos da la opción de elegir entre nuevo
rol de base de datos o de aplicación. Elegimos rol de base de datos.
En el cuadro de diálogo podremos especificar
El nombre del rol, el propietario y los esquemas propiedad del rol.
En las otras pestañas al igual que hicimos anteriormente podemos elegir los elementos de la base de datos a los que se proporcionan permisos. Los esquemas a los que pertenecen, y el tipo de permiso que se proporciona.
Creación de Roles de bases de datos mediante comandos SQL
El procedimiento almacenado que permite añadir un nuevo rol una base de datos es sp_addrole.
sp_addrole 'nombre de rol’ [ 'propietario']
El parámetro propietario permite especificar el usuario de la base de datos propietaria del rol que podrá, por tanto, modificarla. Por defecto será dbo.
sp_addrole 'db_owner’
Adición de usuarios a un rol de servidor
El procedimiento almacenado que permite añadir usuarios a un rol de base de datos es sp_addrolemember:
sp_addrolemember 'nombre función' [, id de inicio de sesión]
Un ejemplo de uso: sp_addrolemember 'Especialistas', 'Conchi'
Información sobre las funciones existentes
Es posible obtener información sobre los roles existentes mediante el procedimiento almacenado sp_helprole.
sp_helprole [ nombre de función ]
RESUMEN
Seguridad de SQL Server
Si los datos no estan protegidos, es
posible que acaben perdiendo su valor si se permite la manipulacion de datos ad
hot y los datos se modifican sin intencion o de forma malintencionada con
valores incorrectos o bien se eliminan por completo.
Es importante comprender que las caracteristicas
de seguridad no pueden garantizar por si solas una aplicacion de base de datos
segura.
Algunas aplicaciones que son locales en
cuanto al ambito pueden necesitar una seguridad minima, 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.
Modos de autenticación de SQL Server y AppFabric
SQL Server ofrece dos métodos para
proteger la autenticación en sus servidores de bases de datos AppFabric:
Autenticación de Windows. Modo de
autenticación de Windows predeterminado. Es el más seguro para SQL Server. Si
se configura el modo de autenticación de Windows, SQL Server usa la seguridad
de Windows para validar la cuenta y la contraseña de la cuenta de usuario
solicitante con el sistema operativo Windows.
Autenticación de SQL Server. Modo de autenticación
de SQL Server. Su finalidad es ofrecer compatibilidad con versiones anteriores
a aplicaciones y usuarios que necesiten acceso a SQL Server con una cuenta de
usuario y contraseña específicos. Es el modo menos seguro.
Inicios de sesión de SQL Server
Un inicio de sesión de SQL Server
requiere una cuenta de usuario y contraseña para iniciar sesión en el equipo
con SQL Server.
Para realizar acciones de configuración
o funcionamiento sobre los esquemas o datos de la base de datos, la cuenta de
inicio de sesión debe estar asignada a un rol de SQL Server con los permisos
adecuados.
Roles de base de datos de SQL Server
SQL Server tiene tres tipos de roles de
bases de datos: servidor, aplicación y base de datos.
Este rol ofrece a la cuenta de inicio
de sesión un control total sobre todas las operaciones de la base de datos y la
capacidad de realizar cualquier operación sobre los datos de SQL Server de
cualquier almacén.
App Fabric usa el modelo de rol de base
de datos definido por el usuario de forma exclusiva para gran parte de su
seguridad en SQL Server.
Del mismo modo que los roles de
servidor de SQL Server, los roles de base de datos fijos no se pueden
modificar.
Al contrario de lo que sucede con los
roles de servidor, que existen a nivel de servidor, los roles de base de datos
existen a nivel de base de datos para cada almacén.
SUMMARY
SQL Server security
If the data is not protected, they may
end up losing their value if the ad hot data manipulation is allowed and the
data is unintentionally or maliciously modified with incorrect values or
deleted completely.
It is important to understand that
security features alone can not guarantee a secure database application.
Some applications that are local in
scope may require minimal security, while other local applications or
applications deployed on the Internet may require strict security measures and
continuous monitoring and evaluation.
The security requirements of a SQL
Server database application must be taken into account at design time, not a
posteriori.
SQL Server and AppFabric authentication
modes
SQL Server offers two methods to
protect authentication on your AppFabric database servers:
Windows authentication. Default Windows
authentication mode. It is the most secure for SQL Server. If Windows
authentication mode is configured, SQL Server uses Windows security to validate
the account and password of the requesting user account with the Windows
operating system.
SQL Server authentication. SQL Server
authentication mode. Its purpose is to offer compatibility with previous
versions of applications and users that need access to SQL Server with a
specific user account and password. It is the least safe mode.
SQL Server session starts
A SQL Server logon requires a user
account and password to log on to the computer with SQL Server.
To perform configuration or operation
actions on the schemas or data of the database, the login account must be
assigned to a SQL Server role with the appropriate permissions.
SQL Server database roles
SQL Server has three types of database
roles: server, application, and database.
This role offers the login account full
control over all database operations and the ability to perform any operation
on the SQL Server data of any store.
App Fabric uses the database role model
defined by the user exclusively for much of its security in SQL Server.
In the same way as SQL Server server
roles, fixed database roles can not be modified.
Contrary to what happens with server
roles, which exist at the server level, database roles exist at the database
level for each store.
RECOMENDACIONES
Si usa Active Directory, es
recomendable que diseñe sus roles de seguridad de AppFabric mediante cuentas de
dominio para simplificar la seguridad entre varios equipos. Como administrador
de AppFabric, puede usar Active Directory para crear explícitamente dos cuentas
de grupo personalizadas para los roles de administrador y observador.
CONCLUSIONES
Durante la realización de este trabajo
descubrimos que la seguridad en las bases de datos es muy importante debido a
que garantiza la integridad física y lógica de los datos.
Concluimos que gracias a la
autenticación que nos permite realizar el lenguaje SQL server, por medio de
inicio de sesión que te brinda que no cualquier persona puede ingresar ya que
lo tendrá que hacer mediante un usuario y contraseña.
APRECIACION DEL EQUIPO
Consideramos a SQL Server como un
gestor muy importante y eficiente en el control y almacenamiento de datos, su
utilización es sencilla y practica además facilita las diferentes operaciones
que queramos realizar así como también la seguridad de los datos es muy importante
para que la información o datos registrados en la BD sean confiables y seguras,
pero tenemos que tener en cuenta que constantemente surgen nuevas versiones y
actualizaciones que van mejorando los diferentes procesos con el fin de ser de
mejor ayuda para usuarios.
GLOSARIO
AppFabric. Es un componente de la plataforma Azure que proporciona diversos
servicios empresariales.
AppFabric Access Control. El usuario debe proporcionar datos que
le permitan ser autenticado para así poder otorgarle autorización de recursos.
Proveedores como Active Directory, Windows Live o Facebook están admitidos en
este servicio.
AppFabric Service Bus. Permite el uso de varios protocolos de
comunicación y mensajería de forma segura, podemos conectar aplicaciones y
bases de datos en la nube con otras aplicaciones dentro de la nube Azure o
fuera de ella, es decir, en ambientes on-premise y off-premise.
AppFabric Caching Service. Proporciona a las aplicaciones alta
velocidad de acceso y escalabilidad en los datos, con este servicio podemos
administrar el estado de las sesiones ASP .NET o memoria temporal para objetos
.NET
DMF. Función de administración dinámica
LINKOGRAFIA
Comentarios
Publicar un comentario