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
  • ASMonitoringDbAdmin
  • ASMonitoringDbReader
  • ASMonitoringDbWriter
  • public
  • Microsoft.ApplicationServer.DurableInstancing.WorkflowAdministrators
  • Microsoft.ApplicationServer.DurableInstancing.WorkflowManagementServiceUsers
  • System.Activities.DurableInstancing.InstanceStoreObservers
  • System.Activities.DurableInstancing.WorkflowActivationUsers
AS_Observers
LOCALHOST\AS_Observers
  • ASMonitoringDbReader
  • public
  • System.Activities.DurableInstancing.InstanceStoreObservers
IIS_IUSRS
BUILTIN\IIS_IUSRS
  • public
  • System.Activities.DurableInstancing.InstanceStoreUsers


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.







 

La primera página de este cuadro de diálogo multipágina nos permite rellenar los siguientes datos:
- 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.


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.



Esto nos abre un cuadro de diálogo con tres pestañas.



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

Entradas populares de este blog

Cursores en Sql Server