UNIDAD V SEGURIDAD

INTRODUCCIÓN

En la realización de la investigación del tema de la Seguridad de la base de datos se mostrará la manera de realizado de respaldos, restauración, lo requerimientos que se necesita para la realización de la migración con el modelo usando: “side-by-side”  y algunos métodos para una mayor seguridad de la base de la base de  datos. También saber la manera de cómo activar el espejeo  de la base de datos, los beneficios que este atrae, ¿Qué es?, su funcionamiento y lo mucho que nos ayudará la realización de este.

Se verá los tipos de réplicas que hay su funcionamiento de cada una de ellas, características y el cuándo usarlas; además de los beneficios que contrae la realización de la réplica.

Otro tema que se describirá será la auditoria en el que se definirá: ¿Qué es?, restricciones, limitaciones, permisos y como realizarla.

 

5.1 RESPALDO Y RECUPERACIÓN

5.1.1 Espejeo (mirroring).

Es una configuración donde dos o tres servidores de base de datos, ejecutándose en equipos independientes, cooperan para mantener copias de la base de datos y archivo de registro de transacciones (log).

Tanto el servidor primario como el servidor espejo mantienen una copia de la base de datos y el registro de transacciones, mientras que el tercer servidor, llamado el servidor árbitro, es usado cuando es necesario determinar cuál de los otros dos servidores puede tomar la propiedad de la base de datos. El árbitro no mantiene una copia de la base de datos. La configuración de los tres servidores de base de datos (el primario, el espejo y el árbitro) es llamado Sistema Espejo (Mirroring System), y el servidor primario y espejo juntos son llamados Servidores Operacionales (Operational Servers) o Compañeros (Partners).

5.1.1.1 Beneficios del espejeo de Datos en un DBMS.

Además de proporcionar una copia adicional de los datos con el fin de redundancia en caso de fallo de hardware, la duplicación de disco puede permitir que cada disco se acceda por separado para los propósitos de lectura. En determinadas circunstancias esto puede mejorar significativamente el rendimiento ya que el sistema puede elegir para cada lectura que disco puede buscar más rápidamente a los datos requeridos. Esto es especialmente importante cuando hay varias tareas que compiten por los datos en el mismo disco, y el "trashing" (donde el cambio entre tareas ocupa más tiempo que la tarea en sí) se puede reducir. Esta es una consideración importante en las configuraciones de hardware que frecuentemente tienen acceso a los datos en el disco.

En algunas implementaciones, el disco reflejado se puede dividir fuera y se utiliza para la copia de seguridad de datos, permitiendo que el primer disco para permanecer activos. Sin embargo, la fusión de los dos discos se puede requerir un período de sincronización en su caso escribir la actividad I/O ha ocurrido con el disco duplicado.

La creación de reflejo de la base de datos es una estrategia sencilla que ofrece las siguientes ventajas:

Incrementa la disponibilidad de una base de datos.

Si se produce un desastre en el modo de alta seguridad con conmutación automática por error, la conmutación por error pone en línea rápidamente la copia en espera de la base de datos, sin pérdida de datos. En los demás modos operativos, el administrador de bases de datos tiene la alternativa del servicio forzado (con una posible pérdida de datos) para la copia en espera de la base de datos. Para obtener más información, vea Conmutación de roles, más adelante en este tema.

 

 

Aumenta la protección de los datos.

La creación de reflejo de la base de datos proporciona una redundancia completa o casi completa de los datos, en función de si el modo de funcionamiento es el de alta seguridad o el de alto rendimiento. Para obtener más información, vea Modos de funcionamiento, más adelante en este tema.

Un asociado de creación de reflejo de la base de datos que se ejecute en SQL Server 2008 Enterprise o en versiones posteriores intentará resolver automáticamente cierto tipo de errores que impiden la lectura de una página de datos. El socio que no puede leer una página, solicita una copia nueva al otro socio. Si la solicitud se realiza correctamente, la copia sustituirá a la página que no se puede leer, de forma que se resuelve el error en la mayoría de los casos. Para obtener más información, vea Reparación de página automática (grupos de disponibilidad/creación de reflejo de base de datos).

Mejora la disponibilidad de la base de datos de producción durante las actualizaciones.

Para minimizar el tiempo de inactividad para una base de datos reflejada, puede actualizar secuencialmente las instancias de SQL Server que hospedan los asociados de creación de reflejo de la base de datos. Esto incurrirá en el tiempo de inactividad de solo una conmutación por error única. Esta forma de actualización se denomina actualización gradual. Para obtener más información, vea Instalar un Service Pack en un sistema con un tiempo de inactividad mínimo para bases de datos reflejadas.

 

 

 

 

 

5.1.1.2 Activación de espejeo en un DBMS.

MySQL

Lo primero que debemos hacer es checar si ambos servidores se encuentran en red

Caso Windows

 

 

5.1.1.3 Creación de espacios de disco con espejo.

Una vez preparados los discos, para crear el RAID, usaremos las siguientes órdenes, suponiendo que los discos nos los ha identificado como sda, sdb, sdc y sdd:

mdadm --create --level=raid1 --raid-devices=2 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1

mdadm --create --level=raid5 --raid-devices=4 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3

La primera orden nos creará un RAID de tipo RAID1 con sólo 2 componentes activos, empleando para ello la primera partición de cada disco. Como le indicamos menos dispositivos de raid (2) que dispositivos físicos, lo que hace es poner los otros dos como pares.

La segunda orden nos creará un RAID5 con la tercera partición de todos los discos indicados. En este caso, el parámetro --raid-devices=4 es superfluo y se podría omitir, ya que si no decimos nada sobreentiende que queremos usar todos los discos.

5.1.2 Replica (replication).

La Réplica de Mezcla, además de hacer el back-up de la Base de Datos del Servidor (comúnmente por razones de seguridad), es capaz de brindar el mismo servicio que ofrece el Servidor  a los clientes, cuando éste por cualquier motivo se encuentre de baja en las conexiones.

La réplica además de suplirlo en la conexión de una forma completamente invisible para el Cliente, es a la vez, totalmente capaz de enviarle todas las modificaciones que la base de datos haya sufrido en su ausencia, cuando éste entra de nuevo a su papel de servidor central.

Tipos de replicación

  1. Replicación de Instantáneas

También conocida como replicación estática. Copia y distribuye datos y objetos de base  de datos exactamente como aparecen en el momento en el que ocurren.

Características

  • Los cambios de datos en el subscritor no son actualizados continuamente.
  • El Subscritor actualiza los datos de forma completa y no de forma transaccional.

¿Cuándo usarla?

  • Datos/objetos son estáticos o no cambian con frecuencia.
  • La cantidad de datos a ser replicados es pequeña.
  • Los usuarios trabajan desconectados, no siempre interesa la última información. 
  1. Replicación Transaccional

También conocida como replicación dinámica.  Las modificaciones de la publicación en el publicador son propagadas al subscritor de forma incremental.

Características

  • Publicador y subscritor siempre están sincronizados.
  • Las Transacciones son preservadas; Ej. si son modificados 5 registros de datos, siempre serán los 5 registros propagados al subscriptor o no serán propagados.
  • El publicador y el suscriptor deberán siempre estar conectados.

¿Cuándo usar la Replicación Transaccional?

La información que se replica será utilizada solo de lectura.  La información de ventas e inventarios de una Central son replicados a las Sucursales.

El subscriptor siempre necesita la última información

  1. Replicación de Mezcla

Provee las ventajas de ambas replicaciones anteriores. La instantánea inicial se aplica a los suscriptores; se hace un seguimiento de los cambios realizados en los datos publicados en el publicador y en los suscriptores. Los datos se sincronizan entre los servidores a una hora programada o a petición.

Características

  • Actualiza los datos haciendo independiente a más de un servidor.
  • Los datos son mezclados basados en un calendario o en la demanda.
  • Permite a los usuarios trabajar online/offline y sincronizar más adelante las modificaciones de datos realizadas en un resultado único y uniforme.

¿Cuándo usar la Replicación de Mezcla?

  • La autonomía del sitio es un factor crucial.
  • Múltiples subscriptores necesitan actualizar datos en diferentes ocasiones y propagar los cambios al publicador y a otros suscriptores; los suscriptores necesitan recibir datos, realizar cambios sin conexión y sincronizar más adelante los cambios con el publicador y otros suscriptores

Requisitos y consideraciones para el uso de la replicación con la creación de reflejo de la base de datos

Se deben tener en cuenta los siguientes requisitos y consideraciones al utilizar la replicación con la creación de reflejo de la base de datos:

  • Las entidades de seguridad y reflejada deben compartir un distribuidor. Se recomienda que éste sea un distribuidor remoto, ya que proporciona mayor tolerancia a errores si se produce una conmutación por error imprevista en el publicador.
  • La replicación admite la creación de reflejo de la base de datos de publicación en la replicación de mezcla y en la replicación transaccional con suscriptores de solo lectura o suscriptores de actualización en cola. No se admiten suscriptores de actualización inmediata, publicadores de Oracle, publicadores en una topología punto a punto ni republicación.
  • Los metadatos y los objetos que existen fuera de la base de datos, incluidos inicios de sesión, trabajos, servidores vinculados, etc., no se copian en la entidad reflejada. Si se requieren los metadatos y los objetos en la entidad reflejada, se deben copiar manualmente. Para obtener más información, vea Administración de inicios de sesión y trabajos tras la conmutación de roles (SQL Server).

Configurar la replicación con la creación de reflejo de la base de datos

La configuración de la replicación y la creación de reflejo de la base de datos implican cinco pasos. Cada paso se describe en detalle en la siguiente sección.

  1. Configurar el publicador
  2. Configurar la creación de reflejo de la base de datos
  3. Configurar la entidad reflejada de manera que utilice el mismo distribuidor que la entidad de seguridad
  4. Configurar los agentes de replicación para la conmutación por error
  5. Agregar las entidades de seguridad y reflejada al Monitor de replicación

El orden de los pasos 1 y 2 se puede invertir.

  • Crear una base de datos en la máquina –replica (Practica)

Se crea una base de datos en la máquina que se utilizara como Réplica, la cual debe dejarse, totalmente vacía, ya que es, en esta Base de Datos en donde se replicaran todas las tablas de la BD del Servidor.

  • Suscripción al servidor

Teniendo la publicación creada, se debe dar paso a crear la suscripción local. Clic derecho sobre Suscripciones Locales, y elegir la opción Nuevas suscripciones.

Se ejecuta el asistente para las suscripciones.

Se selecciona la publicación dentro del Servidor a la cual se le agregara la suscripción.

Se debe elegir la opción Ejecutar cada agente en su suscriptor.

Buscar la máquina que será nuestro suscriptor local para la Replicación. Para el ejemplo, la maquina suscriptora será DAFNE-PC\REPLICA

Se debe conectar al suscriptor, mediante la autenticación de la cuenta de SQL Server.

Se selecciona la Base de Datos vacía que se creó previamente en el suscriptor.

 

Se llenan los campos para la seguridad del Agente de Mezcla, mediante la autenticación de la cuenta SQL.

La sincronización del agente entre el Servidor y la Replica debe programarse de forma continua.

 

Se debe elegir al suscriptor, en este caso, como Servidor, pues al caer el servidor central, la réplica debe ser capaz de suplirlo en su totalidad.

La suscripción si ha sido exitosa, debería mostrar lo siguiente.

 

  • Replicación de la base de datos del servidor a la réplica.

Con la publicación y la suscripción se debe poder visualizar las tablas replicadas de la base de datos que se encuentra en el Servidor, para el ejemplo, se debe visualizar la tabla personal y sus tuplas, dentro de la base REPLICACION en la réplica.

 

Se dispone a ver los datos en la base de datos REPLICACION, de la maquina réplica.

 

Desde la máquina réplica, se agregaran nuevos datos, los cuales tienen que verse reflejados en el servidor. Para lo cual se deben esperar 60 segundos, en lo que las actualizaciones  se hacen efectivas entre ambos servidores.

 

Ahora se pueden comprobar los datos en la maquina servidor.

 

Como se puede observar los códigos entre las tuplas agregadas desde el servidor  y de la réplica no llevan un orden correlativo, pero esta característica es propia entre la replicación de SQL.

El mismo procedimiento se debe de seguir para el caso de cuando se quiere eliminar datos de la  base de datos, e igualmente se deben reflejar los cambios entre ambos servidores. Los cuales también han sido eliminados de la maquina replica.

5.1.2.1 Beneficios de la réplica de Datos en un DBMS

  • Disponibilidad.- El modo en que la replicación incrementa la disponibilidad de los datos para los usuarios y aplicaciones.
  • Fiabilidad.- Al haber múltiples copias de los datos disponibles en el sistema, se dispone de un mecanismo excelente de recuperación cuando existan fallos en nodos.
  • Rendimiento.- Se mejora para las transacciones de consulta cuando se introduce la replicación en un sistema que estuviera aquejado de sobrecarga de recursos centralizados.
  • Reducción de la carga.- Modo en q se utiliza la replicación para distribuir datos en ubicaciones remotas.
  • Procesamiento Desconectado.- Modo en que la replicación puede implementarse mediante mecanismo instantáneas.
  • Soporta muchos usuarios.- Se puede crear múltiples instantáneas personalizadas que satisfagan los requisitos de cada usuario o grupo de usuarios del sistema.
  • Soporta Aplicaciones Avanzadas.- Para OLPT(Online transaction Processing),  OLAP(Online Analitical Processing)

5.1.3 Métodos de respaldo de un DBMS.

BACKUP (Transact-SQL)

Hace copia de seguridad de una base de datos completa de SQL Server para crear una copia de seguridad de la base de datos, o uno o más archivos o grupos de archivos de la base de datos para crear una copia de seguridad de archivo (BACKUP DATABASE). Además, con el modelo de recuperación completa o con el modelo de recuperación optimizado para cargas masivas de registros, realiza la copia de seguridad del registro de transacciones de la base de datos para crear una copia de seguridad de registros (BACKUP LOG).

Sintaxis

Backing Up a Whole Database 

BACKUP DATABASE { database_name | @database_name_var }

  TO [ ,...n ]

  [  ] [ next-mirror-to ]

  [ WITH { DIFFERENTIAL | [ ,...n ] } ]

[;]

 

Backing Up Specific Files or Filegroups

BACKUP DATABASE { database_name | @database_name_var }

  [ ,...n ]

  TO [ ,...n ]

  [  ] [ next-mirror-to ]

  [ WITH { DIFFERENTIAL | [ ,...n ] } ]

[;]

 

Creating a Partial Backup

BACKUP DATABASE { database_name | @database_name_var }

 READ_WRITE_FILEGROUPS [ , [ ,...n ] ]

  TO [ ,...n ]

  [  ] [ next-mirror-to ]

  [ WITH { DIFFERENTIAL | [ ,...n ] } ]

[;]

 

Backing Up the Transaction Log (full and bulk-logged recovery models)

BACKUP LOG { database_name | @database_name_var }

  TO [ ,...n ]

  [  ] [ next-mirror-to ]

  [ WITH { | } [ ,...n ] ]

[;]

 

::=

 {

   { logical_device_name | @logical_device_name_var }

 | { DISK | TAPE | URL} =

     { 'physical_device_name' | @physical_device_name_var }

 }

Note: URL is the format used to specify the location and the file name for the Windows Azure Blob. Although Windows Azure storage is a service, the implementation is similar to disk and tape to allow for a consistent and seemless backup experince for all the three devices. This option requires WITH CREDENTIAL argument. 

 

::=

 MIRROR TO [ ,...n ]

 

::=

 {

   FILE = { logical_file_name | @logical_file_name_var }

 | FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

 }

 

::=

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

 

[ ,...n ]::= 

--Backup Set Options

   COPY_ONLY

 | { COMPRESSION | NO_COMPRESSION }

 | DESCRIPTION = { 'text' | @text_variable }

 | NAME = { backup_set_name | @backup_set_name_var }

 | { EXPIREDATE = { 'date' | @date_var }

        | RETAINDAYS = { days | @days_var } }

 

--Media Set Options

   { NOINIT | INIT }

 | { NOSKIP | SKIP }

 | { NOFORMAT | FORMAT }

 | MEDIADESCRIPTION = { 'text' | @text_variable }

 | MEDIANAME = { media_name | @media_name_variable }

 | BLOCKSIZE = { blocksize | @blocksize_variable }

 

--Data Transfer Options

   BUFFERCOUNT = { buffercount | @buffercount_variable }

 | MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

 

--Error Management Options

   { NO_CHECKSUM | CHECKSUM }

 | { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

 

--Compatibility Options

   RESTART

 

--Monitoring Options

   STATS [ = percentage ]

 

--Tape Options

   { REWIND | NOREWIND }

 | { UNLOAD | NOUNLOAD }

 

--Log-specific Options

   { NORECOVERY | STANDBY = undo_file_name }

 | NO_TRUNCATE

 

--Encryption Options

 ENCRYPTION (ALGORITHM = { AES_128 | AES_192 | AES_256 | TRIPLE_DES_3KEY } , encryptor_options )

::=

   SERVER CERTIFICATE = Encryptor_Name | SERVER ASYMMETRIC KEY = Encryptor_Name

 

5.1.4 Comandos para recuperación.

 

5.2 MIGRACIÓN DE LA BASE DE DATOS

  • Modelo de Migración usado: “side-by-side”

Se trata del modelo de migración más común y más versátil puesto que el destino final es una nueva instancia de SQL Server 2012, bien sea en la misma máquina donde reside la antigua, o un nuevo servidor preparado especialmente para la migración.

Las ventajas frente al modelo de actualización “in-place” son:

Se pueden migrar componentes de forma atómica. Esto quiere decir, que podemos migrar únicamente el motor relacional, dejando que el resto de servicios permanezcan funcionando en la antigua instancia de SQL Server

Se permite la migración de 32 a 64 bits

Se permite la actualización de la versión del Sistema Operativo (normalmente viene asociado a un nuevo servidor en el que se instala la última versión de Windows Server pasando por ejemplo de un Windows Server 2003 con SQL Server 2005 a Windows Server 2008 R2 con SQL Server 2008/2008 R2/2012)

Se permite la migración a un servidor más potente. Al no estar ligados a la actualización del servicio, se puede comprar nuevo hardware destinado para SQL Server, y migrar los datos de la antigua instancia al nuevo servidor.

Se puede migrar un conjunto de bases de datos, en lugar de todas las bases de datos: escenario apropiado en instancias de SQL Server que tienen aplicaciones de diferentes proveedores y alguno de ellos no soporta “todavía” la migración a SQL Server 2005-2008-2008R2-2012.

Pasos para una migración: “side-by-side”

  1. Instalar una nueva instancia SQL Server 2012.
  2. Ejecutar el programa Microsoft SQL Server 2012 Upgrade Advisor contra la instancia (SQL Server 2005, 2008, 2008 R2) a migrar y resolver todas las advertencias.
  3. Parar toda actividad de la instancia SQL Server a migrar (desconexión de usuarios incluida).
  4. Transferir los datos a la nueva instancia (mover backups, paquetes DTS, etc.)
  5. Restaurar los objetos sobre la nueva instancia
  6. Una vez validado que todo funciona con normalidad, desconectar o desinstalar la instancia de SQL Server migrada si es necesario.

Tareas de la migración: “side-by-side”

  1. Ejecución del SQL Upgrade Advisor.
  2. Interpretación y explicación del resultado del SQL Upgrade Advisor.
  3. Instalación de SQL Server 2012 siguiendo buenas prácticas.
  4. Plantear migración de paquetes DTS a SSIS o ejecución en modo compatibilidad.
  5. Plantear migración de Cubos SQL 2005, 2008 y 2008 R2 regenerándolos desde 0, actualizándolos automáticamente con el asistente o simplemente manteniendo la instancia de SQL 2005, 2008, 2008 R2 pero accediendo desde SQL 2012.
  6. Creación de un script de migración para el día de paso a producción y realizar las pruebas correspondientes en pre-producción.

Plan de pruebas y validación

El mejor escenario para cualquier migración es aquella donde se puedan realizar pruebas, ya que ahí será donde validemos si todo se puede realizar correctamente, y en el caso de que no, poder ver los potenciales errores para poder proporcionar una solución.

Bajo este escenario los pasos a seguir son:

  • Revisar los problemas de migración
  • Corregirlos
  • Aplicarlos
  • Ejecutar nuevamente Microsoft SQL Server 2012 Upgrade Advisor (SSUA) y corroborar que ya no exista error alguno.

Una vez resueltos los problemas de migración en código. Ahora nosotros debemos de llevarnos la base de datos a la nueva versión los pasos a seguir son:

  1. Restaurar la base de datos en el servidor SQL Server 2012
  2. Cambiar compatibilidad de 2005, 2008, 2008 R2 a 2012

--Primero ponemos la base de datos a modo mono-usuario

ALTER DATABASE [BDMigrar] SET SINGLE_USER

GO

--Cambiamos el nivel de compatibilidad de 2005/08/08R2 a 2012

EXEC sp_dbcmptlevel [BDMigrar], 110;

GO

--Por ultimo regresamos la base de datos a modo multi-usuario

ALTER DATABASE [BDMigrar] SET MULTI_USER

GO

  1. Ejecutar DBCC CHECKDB para validar la salud de nuestra BD

USE [BDMigrar]

GO

DBCC CHECKDB;

GO

  1. Ejecutar DBCC UPDATEUSAGE para actualizar paginas

USE [BDMigrar]

GO

DBCC UPDATEUSAGE ([BDMigrar])

GO

  1. Reconstruir índices

USE [BDMigrar]

GO

ALTER INDEX [NombreIndice] ON [dbo].[TablaMigrada] REBUILD

PARTITION = ALL WITH ( PAD_INDEX = OFF,

STATISTICS_NORECOMPUTE = OFF, ALLOW_ROW_LOCKS = ON,

ALLOW_PAGE_LOCKS = ON, ONLINE = OFF, SORT_IN_TEMPDB = OFF

)

GO

  1. Actualizar Estadísticas

use [BDMigrar]

GO

UPDATE STATISTICS [dbo].[TablaMigrada]

WITH FULLSCAN

GO

5.3 MONITOREO Y AUDITORÍA DE LA BASE DE DATOS

5.3.1 Monitoreo

SQL SERVER nos ofrece diversas opciones para realizar la tarea de monitoreo a continuación se muestro una recopilación de scripts:

  • Para monitorear el estado de los jobs que fallaron en su última ejecución:
    SELECT name FROM msdb.dbo.sysjobs A, msdb.dbo.sysjobservers B
    WHERE A.job_id = B.job_id AND B.last_run_outcome = 0
  • Espacio en cada disco para la instancia SQL:

EXEC master..xp_fixeddrives

No es necesario que entres al servidor donde tienes tu instancia para inspeccionar el espacio disponible puedes hacerlo con este script.

  • Para ver un listado de Jobs Deshabilitados:

SELECT name FROM msdb.dbo.sysjobs            WHERE enabled = 0

ORDER BY name

  • Para ver un listado de los jobs que están actualmente en ejecución:

msdb.dbo.sp_get_composite_job_info           NULL, NULL, NULL, NULL, NULL, NULL, 1, NULL, NULL

Un script te permite revisar simultaneamente cuáles son los jobs o trabajos que están siendo ejecutados en tiempo real.

  • Para ver logines que son miembros de los roles de servidor:

SELECT ‘ServerRole’ = A.name, ‘MemberName’ =  B.name

FROM master.dbo.spt_values A, master.dbo.sysxlogins B

WHERE A.low = 0            AND A.type = ‘SRV’ AND B.srvid IS NULL

Te muestra que usuarios son miembros de algún rol a nivel servidor actualmente.

  • Para ver la última vez que las bases de datos fueron backupeadas:

SELECT  B.name as Database_Name,

ISNULL(STR(ABS(DATEDIFF(day,

GetDate(), MAX(Backup_finish_date)))), ‘NEVER’) as DaysSinceLastBackup,

ISNULL(Convert(char(10), MAX(backup_finish_date), 101), ‘NEVER’) as LastBackupDate

FROM master.dbo.sysdatabases B LEFT OUTER JOIN msdb.dbo.backupset A

ON A.database_name = B.name AND A.type = ‘D’ GROUP BY B.Name ORDER BY B.name

Investiga cuando fue la última vez que se realizó respaldo de tu base de datos.

5.3.2 Auditoría

La auditoría de una instancia de SQL Server o de una base de datos de SQL Server implica el seguimiento y registro de los eventos que se producen en el sistema. El objeto SQL Server Audit recopila una única instancia de acciones y grupos de acciones de nivel de servidor o de base de datos para su supervisión.

La auditoría se realiza en el nivel de instancia de SQL Server. Es posible tener varias auditorías por cada instancia de SQL Server. El objeto Especificación de auditoría de base de datos pertenece a una auditoría. Puede crear una única especificación de auditoría de base de datos para cada base de datos de SQL Server y cada auditoría.

 

Limitaciones y restricciones

Las especificaciones de auditoría de base de datos son objetos no protegibles que residen en una base de datos determinada. Cuando se crea una especificación de auditoría de servidor de base de datos, está en un estado deshabilitado.

Cuando cree o modifique una especificación de auditoría de base de datos en una base de datos de usuario, no incluya acciones de auditoría en objetos del ámbito de servidor, como las vistas del sistema. Si los objetos del ámbito de servidor están incluidos, se creará la auditoría. Sin embargo, los objetos del ámbito de servidor no están incluidos y no se devolverá ningún error. Para auditar objetos del ámbito de servidor, utilice una especificación de auditoría de base de datos en la base de datos maestra.

Las especificaciones de auditoría de base de datos residen en la base de datos en la que se crearon, con la excepción de la base de datos del sistema tempdb.

Permisos

Los usuarios con el permiso ALTER ANY DATABASE AUDITpueden crear las especificaciones de auditoría de base de datos y enlazarlas a cualquier auditoría.

Después de crearse una especificación de auditoría de base de datos, la pueden ver las entidades de seguridad que cuenten con los permisos CONTROL SERVER, ALTER ANY DATABASE AUDIT o la cuenta sysadmin.

Para crear una especificación de auditoría de nivel de base de datos

  1. En el Explorador de objetos, expanda la base de datos donde desea crear una especificación de auditoría.
  2. Expanda la carpeta Seguridad.
  3. Haga clic con el botón secundario en la carpeta Especificaciones de auditoría de base de datos y seleccione Nueva especificación de auditoría de base de datos.

 

Las siguientes opciones están disponibles en el cuadro de diálogo Crear especificación de auditoría de base de datos.

  • Nombre

El nombre de la especificación de auditoría de base de datos. Se genera automáticamente al crear una nueva especificación de auditoría de servidor, pero se puede modificar.

  • Auditoría

El nombre de una auditoría de base de datos existente. Escriba el nombre de la auditoría o selecciónelo en la lista.

  • Tipo de acción de auditoría

Especifica los grupos de acciones de auditoría y las acciones de auditoría en el nivel de base de datos que se desean capturar. Para obtener la lista de grupos de acciones de auditoría y de acciones de auditoría de nivel de base de datos, así como una descripción de los eventos que contienen, vea Grupos de acciones y acciones de SQL Server Audit.

  • Esquema de objeto

Muestra el esquema para el Nombre de objeto especificado.

  • Nombre de objeto

Nombre del objeto que se va a auditar. Este valor solo está disponible para las acciones de auditoría, no se aplica a los grupos de auditoría.

  • Nombre de la entidad

La cuenta por la que se va filtrar la auditoría para el objeto que se va a auditar.

  • Puntos suspensivos (…)

Abre el cuadro de diálogo Seleccionar objetos para buscar y seleccionar un objeto disponible, basándose en el Nombre de objeto especificado.

Cuando termine de seleccionar opciones, haga clic en Aceptar.

Para crear una especificación de auditoría de nivel de base de datos

En el Explorador de objetos, conéctese a una instancia del Motor de base de datos.

En la barra Estándar, haga clic en Nueva consulta.

Copie y pegue el siguiente ejemplo en la ventana de consulta y haga clic en Ejecutar. En el ejemplo se crea una especificación de auditoría de base de datos denominada Audit_Pay_Tables que audita las instrucciones SELECT e INSERT por el usuario dbo, para la tabla HumanResources.EmployeePayHistory basándose en la auditoría de servidor definida anteriormente.

USE AdventureWorks2012 ; 
GO
-- Create the database audit specification. 
CREATE DATABASE AUDIT SPECIFICATION Audit_Pay_Tables
FOR SERVER AUDIT Payrole_Security_Audit
ADD (SELECT , INSERT
     ON HumanResources.EmployeePayHistory BY dbo ) 
WITH (STATE = ON) ; 
GO
 

5.4 HERRAMIENTAS DE SOFTWARE Y HARDWARE PARA MONITOREO Y ADMINISTRACIÓN AUTOMÁTICA

Monitoreo

  • Task manager
  • Performance monitor

Múltiples recursos

  • Data collector, extended events
  • Activity monitor, Execution plans, profiler, vistas dinámicas

Herramientas de terceros

  • SQL Sentry (Plan explorer)
  • Idera (Solo usen los trials)

 

Task Manager

Performance monitor

Vistas dinámicas

Devuelven infromacion referente al estado del servidor de base de datos para diagnosticar problemas y resolver problemas de rendimiento.

Funciones y viatas de administracion dinamiac con ambito en el servidor. Se requiere el permiso VIEW SERVER STATE en el servidor.

Funciones y vistas de administracion dinamica con el ambito en la base de atos. Se requiere permiso VIEW SATABASE STATE en la base de datos.

CONCLUSIÓN

Todo lo que se plasmó en esta investigación es de suma importancia ya que ayuda cómo saber asegurar una base de datos mediante algunos métodos ya sean como respaldos, espejeos replicas, monitoreo, migración entre otros y los beneficios que este conlleva consigo cada una de ellas, de los cuales optamos por  el que nos brinde mayor seguridad, fácil comprensión y manejo.

 


BIBLIOGRAFÍA

  1. https://dbasqlserver.wordpress.com/2012/03/07/monitoreando-sql-server/

Publicado por Ownerdba el 7 de marzo de 2012

  1. https://microsoftsqlsecret.fullblog.com.ar/migrando-sql-server-2005-2008-2008-r2-a-sql-server-2012.html

Publicado por Normanmpardell a las 18:07

  1. https://dev.mysql.com/doc/refman/5.0/es/replication-howto.html
  2. https://elblogdelbeto.com/codigo-en-c-para-crear-un-respaldo-de-una-base-de-datos-en-sql-server-y-restaurarla/
  3. https://theorybender.wordpress.com/2012/06/15/tips-sql-server-espejado-de-base-de-datos-mirroring/
  4. https://amartido.wordpress.com/2012/09/04/mirroring-sql-server/
  5. ftp://ftp.software.ibm.com/software/pdf/mx/2_El_monitoreo_de_la_actividad_en_bases_de_datos_esta_evolucionando_hacia_la_auditoria_y_la_proteccion_de_bases_de_datos.pdf