lunes, 28 de mayo de 2018

Administración de la Seguridad en SQL SERVER



UNIVERSIDAD POLITECNICA AMAZONICA




INGENIERÍA DE SISTEMAS Y TELEMÁTICAS


                       Docente         : Marco Aurelio Porro Chulli

                       Asignatura     :BASE DE DATOS II.

                       Ciclo               : VIII  "A"

                       Integrantes     : Yanina Bustamante Jibaja.

                                                  Yenny Isabel Cuello Morón.



ADMINISTRACIÓN DE LA SEGURIDAD DE SQL SERVER

1.   Contenido

Ø Definición

Las cuentas y roles de SQL SERVER tienen un papel fundamental en la seguridad de Windows usa estas entidades de SQL Server para el acceso a almacenes y tablas que contienen datos de operaciones de seguimiento, como datos de control de estado relacionados con la persistencia de flujo de trabajo. 
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. 
SQL Server usa los inicios de sesión y roles de SQL Server para administrar el acceso a activos los almacenes de seguimiento y persistencia y los procedimientos almacenados. Se usan permisos para   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.
El servidor debe proporcionar al administrador de sistema los medios necesarios para que este conozca quién accede a los datos y así encontrarse en disposición de limitar dicho acceso a las personas adecuadas, y para realizar estrictamente las operaciones que se estimen oportunas. Esta tarea de preservar de deterioros o usos indeseados los datos de la base es decir, de gestionar la seguridad del servidor, es una de las más importantes labores que debe realizar el administrador del sistema.

Ø  Autentificación

Es el proceso que debe seguir un usuario para tener acceso a los recursos de un sistema o de una red de computadores. Este proceso implica identificación (decirle al sistema quién es) y autenticación (demostrar que el usuario es quien dice ser)
SQL Server ofrece dos métodos para proteger la autenticación en sus servidores de bases de datos:

A. 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. 

B. 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 cuenta de usuario y contraseña específicos. Es el modo menos seguro.

Ø  Inicios de Sesión – Roles

Inicios de sesión de SQL Server

Es una entidad de seguridad o una entidad que puede ser autenticada por un sistema seguro.  Los usuarios necesitan iniciar sesión para conectarse a SQL Server. Puede crear un inicio de sesión basado en una entidad de seguridad de Windows (como un usuario de dominio o un grupo de dominio de Windows) o puede crear un inicio de sesión que no lo esté (como un inicio de sesión 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 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.

Roles SQL Server

  A. 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   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 almacén.

 B. Rol de “APLICACIÓN” de SQL Server: Los roles de aplicación satisfacen las necesidades de seguridad más compleja y personalizadas de una aplicación particular. Varias aplicaciones pueden usar un almacén con la común de proteger la de sus datos durante el acceso de una de las aplicaciones.

C. 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.

D. 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.


Permisos de los Roles Fijos de Servidor

SQL Server proporciona roles de nivel de servidor para ayudarle a administrar los permisos de un servidor. Estos roles son entidades de seguridad que agrupan otras entidades de seguridad. Los roles de nivel de servidor se aplican a todo el servidor en lo que respecta a su ámbito de permisos.



Permisos de los Roles Fijos de Base de Datos
Para administrar con facilidad los permisos en las bases de datos, SQL Server proporciona varios roles, que son las entidades de seguridad que agrupan a otras entidades de seguridad. Son como los grupos del sistema operativo Microsoft Windows. Los roles de nivel de base de datos se aplican a toda la base de datos en lo que respecta a su ámbito de permisos.




 EJEMPLOS

Los permisos en SQL Server se especifican a su vez en dos niveles: el primero a nivel de objeto, y el segundo a nivel de instrucción. Los permisos a nivel de objeto incluyen el derecho de lectura, modificación y borrado de objetos. Los permisos de instrucción se conceden sobre instrucciones SQL que crean objetos de la base de datos (bases, tablas, vistas,...).
La administración de los usuarios se puede hacer cómodamente desde el Administrador Corporativo, gestionando los permisos de usuario y las funciones.




De manera predeterminada todos los usuarios de una base de datos son miembros de la función public, pero además se puede diferenciar entre funciones de servidor, que se implementan a nivel de servidor, y por lo tanto afectan a todas las bases de datos residentes en un servidor, y funciones de base de datos, que limitan su acción a una determinada base de datos.
La realización de copias de seguridad es parte de cualquier entorno de bases de datos. Una copia de seguridad es una copia de las bases de datos (o de parte) almacenada en algún dispositivo (cinta, disco).
Una restauración es el proceso utilizado para devolver una base de datos al estado en el que estaba en el momento en que se realizó la copia de seguridad.
SQL Server permite cuatro tipos distintos de Copias de Seguridad:






Las copias de seguridad constituyen la forma más sencilla y fiable de asegurar que se podrá recuperar una base de datos. Deben realizarse tan frecuentemente como sea necesario para llevar a cabo una administración efectiva de los datos.
Generalmente las copias completas se efectuán en horas de baja o nula actividad, mientras que las diferenciales pueden efectuarse a cualquier hora.


2.   Resumen
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. Los siguientes temas le guiarán durante el proceso de creación e implementación de un plan de seguridad eficaz.
SQL Server usa los inicios de sesión y roles de SQL Server para administrar el acceso a activos los almacenes de seguimiento y persistencia y los procedimientos almacenados. Se usan permisos para   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.
3.   Sumary
The security protection in SQL Server contains a series of steps that affect four areas: the platform, the authentication, the objects and the applications that have access to the system. The following topics will guide you during the process of creating and implementing an effective security plan.
SQL Server uses logins and SQL Server roles to access stored assets and track processes and persistence. You can use the methods for the security of tables and stored procedures to determine who can read, write, and perform administrative operations in the tracking and persistence schemes. Each scheme is protected by its own group of security policies.

4.   Recomendaciones
Los administradores sólo permiten el acceso por medio de procedimientos almacenados porque: Impiden operaciones incorrectas asegurando las reglas de negocio. Permiten afinar la seguridad al mayor grado. Los usuarios no necesitan tener permiso para acceder a las tablas, sólo permiso de ejecución de los procedimientos almacenados. Cuando un usuario A ejecuta un procedimiento almacenado B.P SQL Server no comprueba los permisos de acceso de A a los objetos de B. Sólo comprueba los permisos de acceso de los objetos que no son de B. Esto es cierto sólo para las sentencias DML, para las sentencias DDL siembre se comprueban los permisos.
5.   Conclusiones
La seguridad en nuestra base de datos juega un papel muy importante en la seguridad de Windows es por ello que es fundamental que realices los pasos correctos para administrar tu seguridad en tu base de datos ya que de ello también puede depender la seguridad e integridad de tu datos e información de tu gestor de base de datos.
6.   Apreciación del Equipo
Un usuario puede pertenecer a tantas funciones de una base de datos como se desee. Esas funciones, tienen conjuntos de permisos diferentes. Esta circunstancia nos hace preguntarnos cuáles son los permisos efectivos del usuario.
Cuando un usuario pertenece a varios grupos, su conjunto de permisos resultante es la unión de los permisos asignados a todos los grupos a los que pertenezca. Excepto si una función tiene explícitamente denegado un cierto permiso, situación en la que la denegación explícita prevalece sobre los permisos otorgados en el mismo sentido en otras funciones de las que el usuario sea miembro.
7.   Glosario de Términos
sysadmin: Puede administrar el servidor en todos sus extremos. Agrupa los permisos de todas las demás funciones de servidor preestablecidas.
serveradmin: Tiene la potestad de configurar los parámetros básicos del servidor.
setupadmin: Puede instalar la duplicación de datos y crear y gestionar los p securityadmin: Administra los identificadores de inicio de sesión (logins).
processadmin: puede gestionar los procesos que se estén ejecutando en el ámbito de SQL Server.
dbcreator : Proporciona a un usuario la capacidad de crear y modificar bases de datos en SQL Server.
db_accessadmin: Proporciona a un usuario la capacidad de añadir o eliminar grupos de Windows Server y usuarios de SQL Server a la base de datos.
 AppFabric: siempre actúa en su propio contexto de seguridad. Esto facilita la administración de AppFabric y su tecnología adicional, como Windows Server, IIS y SQL Server.
administrador: Es un usuario especial que existe en todas las bases de datos, y como tal, no puede ser eliminado de la misma.
Guest (invitado)Permite iniciar una sesión sin una cuenta de usuario que de acceso a la base de datos. Se pueden añadir y eliminar cuentas de usuario invitado en cualquier base de datos, excepto en las bases master .

8.    Linkografías





domingo, 20 de mayo de 2018

ACTIVADORES


UNIVERSIDAD POLITECNICA AMAZONICA




INGENIERÍA DE SISTEMAS Y TELEMÁTICAS


                       Docente         : Marco Aurelio Porro Chulli

                       Asignatura     :BASE DE DATOS II.

                       Ciclo               : VIII  "A"

                       Integrantes     : Yanina Bustamante Jibaja.

                                                  Yenny Isabel Cuello Morón.




                                                           TRIGGER - ACTIVADORES


1.   Contenido

Ø Definición
Es una clase especial de procedimiento almacenado que se ejecuta automáticamente cuando se produce un evento en el servidor de bases de datos.
Los eventos que hacen que se ejecute un trigger son las operaciones de inserción (INSERT), borrado (DELETE) o actualización (UPDATE), ya que modifica los datos de una tabla.

Los triggers pueden:

Ø  Declarar variables locales
Ø  Invocar procedimientos almacenados

 Los triggers no pueden:

Ø  Llamarse directamente
Ø  Usar parámetros
Ø  Definirse sobre tablas temporales o vistas
Ø  Crear objetos permanentes de base de datos

Las operaciones con registro mínimo (como select into)
no disparan los triggers


CREATE [ OR ALTER ] TRIGGER [ schema_name . ]trigger_name  
ON { table | view }  
[ WITH <dml_trigger_option> [ ,...n ] ] 
{ FOR | AFTER | INSTEAD OF }  
{ [ INSERT ] [ , ] [ UPDATE ] [ , ] [ DELETE ] }  
[ WITH APPEND ] 
[ NOT FOR REPLICATION ]  
AS { sql_statement  [ ; ] [ ,...n ] | EXTERNAL NAME <method specifier [ ; ] > } 
             <dml_trigger_option> ::= 
    [ ENCRYPTION ] 
    [ EXECUTE AS Clause ] 
<method_specifier> ::= 
    assembly_name.class_name.method_name 

Administración de Activadores (Creación, Modificación y Eliminación)

Creación
sintaxis
CREATE TRIGGER [ schema_name . ]trigger_name
ON { table | view }
[ WITH <dml_trigger_option> [ ,...n ] ]
{ FOR | AFTER | INSTEAD OF }
{ [ INSERT ] [ , ] [ UPDATE ] [ , ] [ DELETE ] }
[ WITH APPEND ]
[ NOT FOR REPLICATION ]
AS { sql_statement [ ; ] [ ,...n ] | EXTERNAL NAME <method specifier [ ; ] > }

EJEMPLO:

CREATE TABLE EJ_TRIGGER (
A INT PRIMARY KEY,
B CHAR (30))
CREATE TRIGGER TR_I_EJ_TRIGGER ON EJ_TRIGGER FOR INSERT AS
IF datename(month, getdate()) = "October"
BEGIN
SELECT "En Octubre no hay inserciones"
ROLLBACK TRIGGER
END
INSERT INTO EJ_TRIGGER VALUES (2, 'Dos')
SELECT * FROM EJ_TRIGGER


Modificación

Sintaxis

CREATE TRIGGER emp_stamp BEFORE INSERT OR UPDATE ON emp
  FOR EACH ROW EXECUTE PROCEDURE emp_stamp();

Eliminación
Sintaxis

drop trigger nombre_del_trigger

  Ø  EJEMPLOS

1.-Crear dos tablas

CREATE TABLE EJ_TRIGGER_2A (
A INT PRIMARY KEY,
B CHAR (30))
CREATE TABLE EJ_TRIGGER_2B (
ID NUMERIC IDENTITY PRIMARY KEY,
FECHA DATETIME,
FILAS INT)

 2-Crear un trigger que guarde la fecha y número de filas afectadas por cada delete:

CREATE TRIGGER TR_D_EJ_TRIGGER_2 ON EJ_TRIGGER_2A FOR DELETE AS
INSERT INTO EJ_TRIGGER_2B VALUES (getdate(), @@rowcount)
RETURN

2.   Resumen
Son objetos que se asocian con tablas y se almacenan en la base de datos. Su nombre se deriva por el comportamiento que presentan en su funcionamiento, ya que se ejecutan cuando sucede algún evento sobre las tablas a las que se encuentra asociado.
Un trigger es un procedimiento almacenado asociado con una tabla, el cual se ejecuta a Hacer modificaciones en cascada sobre tablas relacionadas. Un trigger se puede definir para insert, update, o delete o cualquier combinación de ellos

Ø  Deshacer cambios que violan la integridad de los datos
Ø  Forzar restricciones que son muy complejas para reglas y restricciones
Ø  Mantener datos duplicados
Ø  Mantener columnas con datos derivados
Ø  Hacer ajustes de registros automáticamente cuando se modifica un dato de esa tabla.


3.   Summary
They are objects that are associated with tables and stored in the database. Its name is derived from the behavior they present in its operation, since they are executed when an event occurs on the tables to which it is associated.
A trigger is a stored procedure associated with a table, which is executed to make modifications in cascade on related tables. A trigger can be defined for insert, update, or delete or any combination of them

Ø  Undo changes that violate the integrity of the data
Ø  Force restrictions that are very complex for rules and restrictions
Ø   Keep duplicate data
Ø   Maintain columns with derived data
Ø   Make adjustments of records automatically when a data of that table is modified.
4.   Recomendaciones
Ø  No aceptan parámetros o argumentos (pero podrían almacenar los datos afectados en tablas temporales)
Ø  No pueden ejecutar las operaciones COMMIT o ROLLBACK por que estas son parte de la sentencia SQL del disparador (únicamente a través de transacciones autónomas)
Ø  Pueden causar errores de mutaciones en las tablas, si se han escrito de manera deficiente.
5.   Conclusiones
·        Puedes invertir la lógica. En lugar de eliminar una fila no válida después de que se haya insertado, escriba un activador, por ejemplo: INSTEAD OF para insertar solo si verifica que la fila sea válida.
·         Los activadores también pueden utilizarse para provocar actualizaciones en otras tablas, para transformar o generar valores automáticamente en las filas insertadas o actualizadas, o para invocar funciones que realicen tareas como la de emitir alertas.

6.   Apreciación del Equipo
·     La lógica centralizada que se imponen en todas las tablas facilita el mantenimiento, porque no se necesitan realizar cambios en los programas de aplicación cuando cambia la lógica.
· Los activadores son un mecanismo útil para definir e imponer reglas empresariales transicionales, que son reglas que incluyen diferentes estados de los datos (por ejemplo, un salario que no se puede aumentar más del 10 por ciento).

7.   Glosario de Términos
schema_name: Es el nombre del esquema al que pertenece un desencadenador DML. Los desencadenadores DML tienen como ámbito el esquema de la tabla o la vista donde se crean. schema_name no se puede especificar para los desencadenadores DDL o LOGON.
Trigger_name: Es el nombre del desencadenador. El parámetro trigger_name debe cumplir con las reglas de los identificadores, con la excepción de que trigger_name no puede comenzar con los símbolos # o ##.
table | view: Es la tabla o vista en que se ejecuta el desencadenador DML; algunas veces se denomina tabla del desencadenador o vista del desencadenador. Especificar el nombre completo de la tabla o vista es opcional. Solo se puede hacer referencia a una vista mediante un desencadenador INSTEAD OF. No es posible definir desencadenadores DML en tablas temporales locales o globales.
BEGÍN TRAN: Marca el punto de inicio de una transacción local explícita.
AFTER: es el valor predeterminado cuando solo se especifica la palabra clave FOR. Los desencadenadores AFTER no se pueden definir en las vistas.
DATABASE: Aplica el ámbito de un desencadenador DDL a la base de datos actual. Si se especifica, el desencadenador se activa cada vez que event_type o event_group tienen lugar en la base de datos actual.


8.   Linkografías

Link de las Diapositivas del tema