PLAN DE CONFIGURACIÓN Y RECUPERACIÓN ANTE DESATRES

PARA SMDB [SQL SERVER]

PRESENTADO POR:

SANTANDER JOSÉ ACUÑA POLO

NATALIA MONTOYA AGUDELO
CINDY VILLARREAL ALONSO
(1881795)

Presentado a:

FERNANDO LÓPEZ TRUJILLO

PAOLA ANDREA OCAMPO AMAYA

SENA
Gestión Y Seguridad De Bases De Datos (1881795)
 INTRODUCCIÓN

Hoy en día cualquier sistema de red de computadores y dispositivos de red, está

expuesto a diferentes tipos de riesgos que pueden causar daños irreversibles en las
entidades. El software, el hardware y las bases de datos están expuestos a diversos
factores de riesgo humano y físico. El propósito de este plan que se describe es
detectar a tiempo cuales son las amenazas y/o vulnerabilidades que existen, con el
fin de determinar la gravedad al ocurrir un evento negativo y cómo actuar ante un
desastre natural hacen parte del desarrollo de un plan de recuperación ante
desastres.
En primera instancia se realiza un análisis de todas las condiciones y características
actuales de la infraestructura física de la entidad y se identifican cuáles son los
factores que podrían ocasionar un desastre, para reducir y prevenir en gran medida
eventos negativos, dejando claro que estas acciones no garantizan que los eventos
negativos no llegasen a ocurrir, pero si se cuenta con una plan debidamente
detallado se puede afrontar mejor las adversidades. Además se definen cuáles son
los procedimientos y acciones que se deben realizar en caso de producirse un
eventual daño. Todo en función de reducir los riesgos y proteger la seguridad y la
integridad de los datos y la información confidencial de la entidad; esto a su vez
implica la participación de todos los funcionarios y la capacitación de los usuarios
en diversos aspectos como implementación de sistemas y protocolos de seguridad,
definir líderes en diversos aspectos y ejecutar todo lo estipulado que se menciona
en el plan de recuperación.
Los SGBD deben suministran herramientas para impedir o corregir error o fallos,
siempre que se lleve a cabo una actualización se debe contar con la certeza de que
la base de datos restaurada quede sin errores. El objetivo de un plan de
configuración ante desastres de un sistema es restaurar la base de datos en el
estado que no se tengan errores, es decir, un estado óptimo. Las bases de datos
brindan ciertas posibilidades de respaldo y recuperación, dadas mediante una
configuración la cual se basa en características de operatividad y de disponibilidad,
por otro lado se deben tener presentes los requerimientos de las entidades y áreas
de la misma. La recuperación y los respaldos sirve para valorar la instancia en la
que particularmente se encuentra cada base, seguidamente en este plan se expone
y propone el mejor modelo de respaldo que se pueda brindar para cada usuario o
entidad y garantizando un porcentaje mínimo de perdida de información.
 1. OBJETIVOS
OBJETIVO GENERAL:
 Elaborar un plan de configuración para SQL SERVER de acuerdo con los
parámetros de la plataforma seleccionada.

OBJETIVOS ESPECIFICOS:
 Definir el conjunto de actividades, roles y responsabilidades que permitan
mantener la seguridad de la información de la ALCALDIA DE SAN ANTONIO
DEL SENA, en caso de la ocurrencia de un evento de desastre, interrupción
mayor o un evento contingente.
 Detallar en las especificaciones de la configuración del SMDB escogido los
ajustes de memoria, gestión de usuarios, instancias, almacenamiento y tipos
de archivos, servicios, gestión de conexiones y manejo en red, sistema
operativo.
 Involucrar las acciones de recuperación de información ante posibles
desastres informáticos.

2. RESPONSABLE EN EL PROCESO DE CONFIGURACIÓN Y

RECUPERACIÓN
Líder de Seguridad de la información.

3. ALCANCE

En este plan se menciona la protección de las bases de datos y

aplicaciones utilizadas en la ALCALDIA DE SAN ANTONIO DEL
SENA.

Servicios Tecnológicos:
 Correo Electrónico
 Intranet
 Internet
 Portal WEB
 VPN
 Telefonía
 4. DEFINICIONES:
Activos tecnológicos: Recursos del sistema de información o relacionados con
éste, necesarios para que la entidad funcione correctamente y alcance los
objetivos propuestos por su Dirección. Se pueden estructurar en las siguientes
categorías: Software, Hardware, Servicios, Datos, Personal, Proveedores,
instalaciones físicas, Comunicaciones, Equipamiento auxiliar.
CCP: Centro de Computo Principal. Hace referencia a las instalaciones físicas
donde se procesa normalmente la información y donde se encuentra la
infraestructura tecnológica en funcionamiento normal.
DRP: Sigla en inglés (Disaster Recovery Plan), que hace referencia al Plan de
Recuperación ante Desastres de Tecnología, el cual define los
procedimientos, estrategias, y roles y responsabilidades establecidos para
recuperar y mantener el servicio de tecnología ante un evento de
interrupción.
ERA: Sigla en inglés (Environment Risk Analisys), Análisis de Riesgos
Ambientales, y hace referencia a un documento que relaciona los riesgos
que pueden afectar la continuidad de las bases de datos y la plataforma
tecnológica de la entidad.
Evento: Suceso imprevisto que puede ocurrir en un espacio y tiempo específico,
generando impactos sobre los activos tecnológicos y activos del negocio.
Plataforma tecnológica crítica: Hace referencia a los sistemas de información,
servidores, bases de datos, sistemas de almacenamiento y respaldo,
equipos y enlaces de comunicación que son críticos para soportar los
procesos y servicios de la entidad.
Recuperación: Un sistema de recuperación consiste en restaurar la BD a un
estado que sea correcto, de algún fallo que la deje en estado incorrecto. Ejemplo:
Recuperación de una base de datos “reestablecer la BD a un estado seguro y
estable”
Respaldo: Consiste en la generación de un backup o copia de los datos en un
medio magnético o en la nube, de tal modo que partiendo de ese respaldo es
factible restaurar el sistema al momento en que se realizó el respaldo. Los
respaldos se deben generar regularmente y mediante un cronograma
prestablecido, de manera responsable y veraz.
SCA: Servidor Central Alterno. Hace referencia al sitio donde operará la entidad
en caso de que exista un evento que impida la operación en las
instalaciones normales.
 5. CONDICIONES GENERALES
La entidad debe establecer su capacidad real para recuperar información crítica
en un periodo de tiempo aceptable. Otro aspecto importante del plan de
recuperación es identificar el equipo de recuperación, los nombres, números de
teléfono, asignaciones específicas, necesidades de formación y otra información
esencial, para cada miembro del equipo que participa en el plan de recuperación.

La Red de la Alcaldía de San Antonio cuenta con Tecnologías de la

información y las comunicaciones en lo referente a: sistemas de
comunicación, sistemas de información, conectividad y servicios Informáticos
que se brinda de forma interna y externa a las diferentes Oficinas, y
dependencias adscrita a la Alcaldía.

Se resume que la Administración de Red está dividida en dos partes:

Conectividad: se encargada de la conexión alámbrica e inalámbrica de la

infraestructura tecnológica.

Manejo de servidores: Se encarga de alojar todos los servicios y sistemas de

comunicación e información. Los servicios de Red implementados en la
Alcaldía son implementados en sus servidores y computadores.

Esta Alcaldía debe preparar un análisis de riesgo y crear una lista de posibles
desastres naturales o causados por errores humanos, y clasificarlos según sus
probabilidades. Una vez terminada la lista, cada departamento debe analizar las
posibles consecuencias y el impacto relacionado con cada tipo de desastre. Esto
servirá como referencia para identificar lo que se necesita incluir en el plan. Un
plan completo considera una pérdida total del centro de datos y eventos de
larga duración de más de una semana.

Una vez definidas las necesidades de cada dependencia, se les asigna una
prioridad. Los procesos y operaciones son analizados para determinar la máxima
cantidad de tiempo que la organización puede sobrevivir sin ellos. Se establece
un orden de recuperación según el grado de importancia. Esto se define como
él, TIEMPO DE RECUPERACIÓN O PUNTO DE RECUPERACIÓN.

Los posibles daños pueden referirse a:

 Imposibilidad de acceso a los recursos debido a problemas físicos en las
instalaciones, naturales o humanas.
 Imposibilidad de acceso a los recursos informáticos, sean estos por
cambios involuntarios o intencionales, tales como cambios de claves de
acceso, eliminación o borrado físico/lógico de información clave, proceso
de información no deseado.
 Divulgación de información a instancias fuera de la institución y que
afecte su Patrimonio estratégico, sea mediante Robo o Infidencia.
Riesgos: Las posibles fuentes de daño que pueden causar la no operación normal
de la entidad lo son:

Riesgos Humanos:
 Acceso no autorizado
 Ruptura de las claves de acceso al sistema computacionales
 Fallas de Personal Clave: por los siguientes inconvenientes, Enfermedad,
Accidentes, Renuncias, abandono de sus puestos de trabajo entre otros.

Riesgos Ambientales:
 Desastres Naturales
 Movimientos telúricos Inundaciones

Riesgos Tecnológicos:
 Fallas en los equipos de soporte (causadas por el ambiente, la red de energía
eléctrica, no acondicionamiento atmosférico necesario)
 Fallas de Hardware
 Falla en los Servidores.
 Falla en el hardware de Red (Switches, cableado de la Red, Router,
Firewalls)

6. PLAN DE RECUPERACION ANTE DESASTRES (Disaster Recovery

Plan)
El DRP está enfocado a la protección de las bases de datos y los aplicativos que
soportan los procesos misionales de la ALCALDIA DE SAN ANTONIO DEL SENA.

6.1. Supuestos:
La efectividad en la ejecución de este plan se da ante la ocurrencia de un evento
de desastre, interrupción mayor o un evento contingente que afecte las bases de
datos y las aplicaciones de la alcaldía, se fundamenta en los siguientes supuestos:
 Se dispone de la infraestructura y recursos que soportan las estrategias de
contingencia y recuperación para los sistemas críticos.
 Los funcionarios que ejecutan este plan, o sus suplentes, se encuentran
disponibles y no ha sido afectados por el desastre.
 El desastre no afectara simultáneamente los servidores principales que se
encuentran ubicados en la oficina de sistemas y el Servidor Central Alterno.
 El Servidor Central Alterno de la oficina de sistemas estará habilitado para
un promedio de 100 usuarios concurrentes.
 Solo el funcionario responsable activará el DRP.
 Se realizarán las pruebas de las estrategias y procedimientos al menos 1
vez al año.
 Los funcionarios deben participar en las pruebas y capacitaciones a realizar.
 La realización de respaldos de las bases de datos e información se realiza
de acuerdo a los procedimientos y frecuencias establecidas.
6.2. Importancia de los respaldos.
Son muchas las ventajas al realizar copias de seguridad de las bases de datos de
SQL Server:
 El SGBD posee un componente de copias de seguridad y restauración de
SQL, el cual ofrece un resguardo fundamental para los datos críticos
almacenados en las bases de datos.
 Para minimizar el riesgo de pérdida información es necesario realizar copias
de seguridad de las bases de datos, almacenando actualizaciones o
modificaciones de los datos periódicamente.
 Un buen programa de respaldo y la correcta restauración favorece
enormemente la protección de las bases de datos ante la pérdida de
información causada por diferentes tipos de errores
 Con los respaldos validos de una BD es factible recuperar la información en
caso de que se produzcan errores, por ejemplo:
o Errores de usuario Ejemplo quitar una tabla por error.
o Errores de hardware Ejemplo, una unidad de disco dañada o la
pérdida permanente de un servidor.
o Errores de medios. Corrupción en los medios utilizados para el
respaldo.
o Desastres naturales.

6.3. Análisis en las fallas en la Seguridad

En este se abarca el estudio del hardware, software, la ubicación física de

la estación, su utilización, con el objeto de identificar los posibles resquicios
en la seguridad que pudieran suponer un peligro.

Las fallas en la seguridad de la información y por consiguiente de los equipos

informáticos, es una cuestión que llega a afectar la seguridad de la información
donde vemos dos aspectos importantes como:

 Negar el acceso a los datos a aquellas personas que no tengan derecho a

ellos.
 Garantizar el acceso a todos los datos importantes a las personas que
ejercen adecuadamente su privilegio de acceso, las cuales tienen la
responsabilidad de proteger los datos que se les ha confiado.

6.4. Estrategias de recuperación

Se dispone las alternativas más prácticas para proceder en caso de un desastre.

Todos los aspectos de la organización son analizados, incluyendo hardware,
software, comunicaciones, archivos, bases de datos, instalaciones, etc. Las
alternativas a considerar varían según la función del equipo y pueden incluir
duplicación de centros de datos, alquiler de equipos e instalaciones, contratos de
almacenamiento.

6.5. Componentes esenciales

Entre los datos y documentos que se debe proteger se encuentran listas,

inventarios, copias de seguridad de software y datos, cualquier otra lista importante
de materiales y documentación.

7. IDENTIFICACIÓN DE LAS AMENAZAS Y RIESGOS

Los escenarios de desastre, interrupción mayor o un evento contingente que

podrían afectar a la alcaldía son:

AMENAZAS RIESGOS
NATURALES ACCIDENTALES PROVOCADAS NATURALES ACCIDENTALES PROVOCADOS

Averías en los Sabotajes en la Errores en la Difusión mal

Terremotos equipos administración Inundación introducción intencionada
de la de datos de la
información información

7.1. Oficina de Sistemas:

No disponibilidad de los servidores por:

 Atentado terrorista
 Incendio
 Inundación
 Daño sistema aire acondicionado
 Daño en suministro eléctrico

7.2. Infraestructura de comunicaciones:

No disponibilidad de los servicios de comunicaciones por fallas en:

 Switch principal de servidores.
 Fibras ópticas de conexión con centros de cableado.
 Router principal de la oficina del alcalde
 Router de cada dependencia.
 Switch de comunicación con dependencias.
 Switches de cada una de las dependencias.
 Switch del firewall principal
 Firewall
7.3. Infraestructura de Servidores:
No disponibilidad de los servidores por fallas en:
o Servidor dedicado para el uso de: controlador de dominio, Directorio
activo.
o Servidor de base de Datos SQL Server.
o Servidor de Internet Firewall.
o Servidor de correo electrónico.
o Servidor de archivos.
o Servidor de impresión.
o Servidor de comunicaciones.
o Servidor de seguridad.
o Servidor de Backups de usuarios.
o Servidor de aplicaciones en donde estarán las aplicaciones
administrativas de las dependencias
o Servidor VNC.

7.4. Infraestructura de Bases de datos, Almacenamiento y Respaldo

No disponibilidad de datos e información por:
 Corrupción de la base de datos.
 Borrado o pérdida de datos.
 Falla en switch de servidores.
 Falla total o parcial del Servidor de respaldo.

7.5. Infraestructura de aplicaciones

No disponibilidad de la aplicación por:

 No conexión con otras aplicaciones
 Borrado o pérdida de datos.
 Integridad de los datos.

7.6. Servicios tecnológicos:

No disponibilidad de la aplicación por:

 Bloqueo de puertos.
 Fallas en servidores de aplicaciones.
 Virus informativos.
 Ataques de denegación.
8. PRIORIDAD DE LA INFORMACIÓN

Teniendo en cuenta los procesos institucionales y los recursos de cada proceso de

la Alcaldía de San Antonio del SENA, según las dependencias la prioridad seria así:

PRIORIDAD DEPEDENCIA PROCESO RECURSO

1 SEC. HACIENDA ACTUALIZACION DE COPIA DE SEGURIDAD
PAGOS DE IMPUESTO EN DISCO DURO
PREDIAL ESPEJO CADA 12
HORAS
2 SEC. PLANEACIÓN Y OBRAS ACTUALIZACIÓN COPIA DE SEGURIDAD
PÚBLICAS CATASTRAL EN DISCO DURO
ESPEJO CADA HORA
3 SEC. EDUCACIÓN ACTUALIZACION DE COPIA DE SEGURIDAD
INFORMACION DE EN DISCO DURO
MATRICULAS/TRASLADOS ESPEJO CADA HORA
Y GESTION DE ALIANZAS COPIA DE SEGURIDAD
ES EN SOFTWARE CADA
DIA
4 SEC. GOBIERNO ACTUALIZACION DE COPIA DE SEGURIDAD
INFORMACION DE EN DISCO DURO
COMERCIANTES ESPEJO CADA DIA
5 SEC. GENERAL PROCESO DOCUMENTAL COPIA DE SEGURIDAD
EN DISCO DURO
ESPEJO CADA DIA
6 SEC. SALUD ACTUALIZACION DEL SIIS COPIA DE SEGURIDAD
EN DISCO DURO
ESPEJO CADA HORA
7 SEC. AMBIENTAL Y PROTECCIÓN RECURSOS COPIA DE SEGURIDAD
MINERÍA NATURALES EN SOFTWARE CADA
DIA
8 SEC. DE DEPORTES, FORMULACION DE COPIA DE SEGURIDAD
RECREACION Y CULTURA PLANES, PROGRAMAS Y EN SERVIDOR CADA
PROYECTOS SEMANA
9 OFC. ASESORA CONTROL DOCUMENTACION COPIA DE SEGURIDAD
INTERNO NORMALIZADA Y EN DISCO DURO
ESTANDARIZADA ESPEJO CADA HORA
CADA 8 HORAS
10 OFC. DEL ALCALDE DOCUMENTACION COPIA DE SEGURIDAD
PERSONAL EN SERVIDOR CADA
DIA
 9. ROLES Y RESPONSABILIDADES:

Los roles y responsabilidades definidos en este plan deberán ser ejercidos por el
personal seleccionado, de forma tal que se minimice el impacto y se actúe de forma
adecuada.

Las responsabilidades definidas para cada rol son:

Antes del evento de Después del evento
Rol Durante el evento de interrupción
interrupción de interrupción
- Evaluar y activar el DRP y las
- Velar por la actualización estrategias de recuperación y - Velar por la
del DRP y recursos contingencia. actualización del
requeridos. DRP acorde con los
- Comunicar a la Secretaria inconvenientes y
- Velar por la General sobre el estado de la oportunidades de
actualización, operación de Contingencia. mejora visualizados
distribución y pruebas
- Informar el momento en que opera durante el evento de
del DRP
en contingencia y que puede interrupción.
Líder del DRP - Gestionar la suceder con la prestación del - Informar a la
consecución de los Servicio Secretaria General
recursos para el DRP.
- Liderar la operación bajo sobre el retorno a la
- Comunicar a las contingencia. normalidad y
personas que agradecer la
- Comunicar al Alcalde el
corresponda sobre la comprensión y apoyo
desastre, interrupción o evento
situación de de todos en esta
contingente.
contingencia. situación.
- Liderar el retorno a la normalidad.

Líder de
infraestructura,
- Comunicar necesidades
Líder de Redes y
de ajuste
Comunicaciones,
- Participar en la ejecución
y Líder de Mesa
de las pruebas al DRP
de ayuda
Antes del evento de
Rol
interrupción
- Coordinar actividades de
entrenamiento,
documentación y
actualización del DRP.
- Coordinar las
Líder de Seguridad
actividades de pruebas
del DRP.
- Identificar los recursos
requeridos para la
operación del DRP.
Apoyo Logístico
(Secretaria General. - Participar en la ejecución
de las pruebas al DRP
Grupo
Administrativa)
- Evaluar el desastre, interrupción o
evento contingente.
- En caso de no contar con un
contrato de mantenimiento vigente
se debe tener un listado de
posibles proveedores de acciones
correctivas de solución.
- Comunicar el evento al Líder del
DRP
- Verificar disponibilidad y notificar
al personal requerido para atender
el evento.
- Ejecutar las guías de contingencia
- Reportar los
y recuperación.
inconvenientes y
- Comunicar a los proveedores la
oportunidades de
activación del DRP.
mejora del DRP
- Gestionar el alistamiento y
disponibilidad del Servidor
de Backups de usuarios.
- Solicitar la corrección del
componente afectado y realizar
seguimiento de la solución.
- Estar atentos para dar una
correcta información a las
personas que lo requieran.
- Mantener informado al Líder del
DRP
- Coordinar con los responsables el
desplazamiento al Servidor de
Backups de Usuarios, de los
funcionarios que activarán la
infraestructura. (Si aplica)
Después del evento
Durante el evento de interrupción
de interrupción
- Verificar si se
actualizó el DRP, de
- Verificar ejecución del plan de acuerdo con los
recuperación de desastres. inconvenientes y
- Participar en la toma de oportunidades de
mejora encontrados.
decisiones que se den pro ajustes
durante la ejecución del plan. - Verificar que las
- Coordinar que todo el personal lecciones aprendidas
están siendo
involucrado este participando.
actualizadas en la
herramienta definida.
En sitio
- Apoyar a los involucrados en el
DRP, en actividades
administrativas y logísticas ante
- Reportar los
una contingencia, entre otras.
inconvenientes y
- Suministro de información de oportunidades de
contrato
mejora del DRP
- Logística de desplazamiento, si es
requerido
- Contacto de proveedores, si es
requerido
 9.1. ARBOL DE LLAMADAS
Cuando se presente un desastre, interrupción o evento tecnológico, se debe
seguir la siguiente cadena de llamadas:

MEDIOS DE COMUNICACIÓN
Usuarios, Personal
Administrativo Persona a Persona

Comunica a: Telefonía fija o Celular

Mesa de ayuda Celular a celular

Correo Electrónico
Comunica a:

Comunica a:

Líder de Líder de Redes y

Infraestructura Comunicaciones

Comunica a:
Comunica a:

Proveedores Director de informática

y desarrollo

Comunica a: Comunica a:

Líder de seguridad ALCALDE

Comunica a:

Apoyo Logístico

Los datos de contacto para los funcionarios que ejercen estos roles se
encuentra en los documentos de la Dirección de Informática y Desarrollo.
10. PROCEDIMIENTOS A EJECUTAR
10.1. ACTIVIDADES DE NOTIFICACIÓN, EVALUACIÓN Y ACTIVACIÓN DEL
DRP
Actividades previas al desastre.

Se considera las actividades de planteamiento, preparación, entrenamiento y

ejecución de actividades de resguardo de la información, que aseguraran un
proceso de recuperación con el menor costo posible para la institución.

10.1.1. ¿Quién reporta un incidente, interrupción mayor o un evento

contingente?

A. Los usuarios deben reportar el incidente a la mesa de ayuda cuando:

• NO se pueden utilizar los sistemas de información.
• NO hay red de comunicaciones.
• NO hay servicio de correo electrónico.
• NO hay acceso a los archivos electrónicos centralizados
• CUALQUIER otro evento de tecnología que afecte la prestación del
servicio.

B. El personal administrativo (vigilancia, servicios generales) debe reportar

el incidente a Mesa de Ayuda o Líder de Sistemas cuando:
• SUENA la alarma de la oficina de sistemas,
• HAY inundación en cualquier piso,
• HAY un conato de incendio en el piso donde se encuentre ubicado
oficina de sistemas y
• CUALQUIER otro evento que afecte o pueda afectar la oficina de
sistemas.

C. El personal de tecnología encargado de monitoreo de servidores y

plataforma (infraestructura de técnica, infraestructura de
comunicaciones, infraestructura de datos) deben reportar el incidente a
Mesa de Ayuda o Líder de Sistemas cuando:
• Se detecta caída de servicios,
• Se detecta mal funcionamiento de infraestructura
critica (servidores, dispositivos de comunicaciones, bases de
datos) y
• Se disparen alarmas ambientales.

D. La mesa de ayuda debe atender el incidente de acuerdo a lo establecido

en este plan en cuanto a Mantenimiento preventivo, soporte técnico y
mantenimiento correctivo de la infraestructura tecnológica, y se continúa
con la ejecución de esta plan si:
• El incidente afecta la disponibilidad de los sistemas, a nivel general.
• El incidente afecta la disponibilidad de la red de comunicaciones a
 nivel general.
• Ningún usuario tiene acceso al correo electrónico.
• Ningún usuario puede acceder a sus archivos electrónicos centralizados.

En cualquiera de los casos, debe escalarlo a los funcionarios responsables.

10.1.2. ¿Quién evalúa la magnitud e impacto del incidente?

El profesional especializado de la plataforma afectada, debe realizar un
diagnóstico sobre el incidente presentado, teniendo en cuenta:
 Naturaleza e impacto del incidente.
 Estrategias definidas en el DRP aplicables u otras soluciones potenciales
 Tiempo estimado de solución del incidente.

Finalmente, comunicarse con el Director de Informática y Desarrollo para informar

los resultados del diagnóstico.

10.1.3. ¿Cuándo se debe activar el Servidor Central Alterno?

A. El Director de Informática y Desarrollo, define si se activa o no el Servidor
Central Alterno, teniendo en cuenta los siguientes aspectos:
o Si el evento afectó considerablemente el Centro de Cómputo Principal
ubicado en la oficina de sistemas.
o Si la solución en sitio dura más del tiempo definido en el punto (Alcance,
Aplicaciones).
B. En caso de que se active, el líder de infraestructura debe comunicar la
activación al proveedor, teniendo en cuenta:
o Fecha y hora a partir de la cual se da inicio a la activación.
o Funcionarios de la entidad que estarían en el proceso de activación, para
que se tramiten los permisos de acceso correspondientes.
C. El Líder de Infraestructura, coordina la ejecución de las actividades para
recuperar el servicio de las aplicaciones en el Servidor Central Alterno,
teniendo en cuenta:
o Enrutamiento y activación de las comunicaciones hacia el Servidor
Central Alterno
o Detención de la replicación de datos.
o Verificación de la disponibilidad de información en el Servidor Central
Alterno.
o Activación servicio de controladores de dominio y sistema operativo
en servidores
o Activación servicio de bases de datos y aplicaciones
D. El Líder de infraestructura, verifica la disponibilidad del servicio y de las
aplicaciones desde el Servidor Central Alterno, teniendo en cuenta:
 o Acceder a los sistemas de información
o Realizar pruebas sobre los sistemas de información
El Director de Informática y Desarrollo, comunica el incidente al Alcalde, caso en el
cual se realizarían las actividades de manejo de crisis.

10.1.4. ¿Qué actividades paralelas se deben realizar, luego de activado el

Servidor Central Alterno?
A. El Líder de infraestructura, activa las estrategias de contingencia locales,
teniendo en cuenta los siguientes aspectos:
Si es un evento que afectó las comunicaciones.
 Configurar el Switch de contingencia, en caso de falla en el switch de
servidores.
 Contactar al proveedor de comunicaciones, en caso de falla en router de
conexión con dependencias, falla en router ubicado en cada dependencia,
o falla en enlace con las dependencias.
 Enrutar el tráfico por los demás switch que componen el stack, en caso
de una falla de la fibra óptica de uno de ellos.
 Utilizar el switch de piso como contingencia ante falla de un switch de piso
en un centro de cableado.
 Configurar el firewall de contingencia, en caso de falla del equipo principal.
Si es un evento que afectó la infraestructura de servidores,
 Configurar el servidor de contingencia en el BladeServer utilizando la
plantilla predefinida, en caso de falla de alguno de los siguientes
servidores: DOCSERVER, DOCUMENTSERVER, SQLSERVER,
SUPERWEB, WEBLINUX, Y SUPERCORREO.
 Configurar el servidor de contingencia en el BladeServer utilizando la
plantilla predefinida, en caso de falla de alguno de los siguientes
servidores: DSA_Super y WAS.
 Activar el servidor de contingencia, ante falla del servidor
SUPERDOMINIO.
Si es un evento que afectó Infraestructura de Bases de datos,
almacenamiento y Respaldo:
 Recuperación de información y bases de datos desde los respaldos, en
caso de corrupción de la base de datos, y borrado o pérdida de datos.
 Utilizar los discos de contingencia ante una falla en la SAN.
 Configurar el servidor de contingencia el servidor de Backup de usuarios
como servidor de respaldo, en caso de falla del principal.
B. En caso que la falla afecte un equipo que no se encuentra en garantía o
mantenimiento correctivo, el Líder de infraestructura solicita la contratación
urgente de los servicios y equipos necesarios para solucionar el incidente.
 C. El Director de Informática y Desarrollo realiza la gestión para la contratación
o compra de los servicios y/o equipos necesarios para solucionar el incidente.
D. El Líder de infraestructura coordina la solución con el proveedor contratado.
E. El Director de Informática y Desarrollo comunica la solución del incidente a
la entidad.
F. El Director de Informática y Desarrollo, en conjunto con los profesionales
especializados, definen la estrategia de retorno a la normalidad, teniendo en
cuenta:
 Fecha del retorno a operación normal.
 Consideraciones especiales a aplicar en el proceso de retorno.
 Consideraciones especiales con respectos a la
recuperación de la información y mantener la integridad de los
datos, cuando aplique.
 Sincronización entre los centros de cómputo, cuando se operó en el
Servidor Central Alterno, si aplica.
G. El Líder de Seguridad, en conjunto con los funcionarios que participaron en
la atención del incidente, documentan el incidente e identifican oportunidades
de mejora para fortalecer el DRP.
H. Se realiza el cierre del incidente, interrupción mayor o evento contingente, y
se continúa con la ejecución del procedimiento de acciones preventivas y
correctivas del SGSI.

10.2. ACTIVIDADES DE MANEJO DE CRISIS

A continuación se listan las actividades y consideraciones necesarias para el
manejo de una crisis que afecte o pueda afectar la reputación, imagen u
operación de la Alcaldía de San Antonio SENA.
a. El Director de Informática y Desarrollo comunica a el Alcalde,
teniendo en cuenta los siguientes aspectos:
• Sistemas y servicios afectados
• Resultados del diagnóstico
• Acciones realizadas
• Tiempo estimado para normalización
• Riesgos a los que está expuesta la entidad por el desastre
presentado, y las alternativas disponibles
• Decisiones que debe tomar la Alcaldia.

b. El Alcalde (Equipo de Manejo de Crisis) evalúa la crisis y el impacto

que puede tener para la reputación, imagen u operación de la entidad,
al igual que define las acciones para afrontar la crisis.
c. El Alcalde, a través de los voceros o funcionarios delegados,
comunicará la crisis a nivel interno y externo, en caso de ser
requerido, teniendo en cuenta los siguientes aspectos:

• ¿Qué información concreta se tiene sobre la crisis (incidente

presentado, diagnóstico, tiempo de solución)?
• ¿Qué información está en proceso de verificación e
investigación?
• ¿Qué información válida se puede comunicar inmediatamente
(mensaje)?
• ¿Qué información se debe manejar al interior de la entidad?
• ¿Quiénes fueron afectados por la crisis (audiencia)?
• ¿Qué otras audiencias deberían saber sobre la crisis?
• ¿Cómo se comunicará la información a los interesados o
afectados (medio)?

La comunicación de la crisis deberá considerar los siguientes

principios:

Informar rápida y periódicamente: Ante una situación de crisis

de alto impacto, la entidad debe establecerse como fuente primaria
de información, asimismo, debe comunicar periódicamente la
evolución de la atención de la crisis para evitar malos entendidos,
especulaciones y rumores. Estos elementos le permitirán generar
confianza y credibilidad con sus audiencias.

Decir la verdad: Ser honestos en los comunicados, sin embargo

no significa transmitir TODA la información, sólo aquella que es
suficiente para generar confianza y tranquilidad en la audiencia.
Podrá existir información confidencial que deberá ser tratada como
tal y no se necesite transmitir a los interesados.

Emitir reportes lo más exactos posible: Publicar la información

que se tiene disponible, siempre y cuando ésta haya sido validada.
No especular, adivinar ni presentar situaciones hipotéticas.

Las audiencias a considerar en la comunicación de la crisis son:

 Usuarios externos de los servicios de la entidad.
 Funcionarios
 Gobierno y Autoridades
 Contratistas y Proveedores

d. El Alcalde, o los funcionarios designados por esta, deberá realizar

monitoreo permanente de la crisis y tomar las decisiones que
 correspondan para continuar con la mitigación del mismo. Se debe
tener en cuenta:
 ¿Qué información circula en los medios de comunicación?
 ¿Qué información circula a nivel interno?
 ¿Qué impacto sobre la crisis tiene la información que está
circulando en los medios?
 ¿Se requerirá realizar nuevos comunicados?

10.3. ACTIVIDADES DE MANTENIMIENTO

Es responsabilidad del Líder de Seguridad la actualización de las nuevas

versiones al DRP, y la comunicación de las mismas a todos los
funcionarios involucrados en el mismo.
La actualización y mantenimiento al DRP se debe realizar:
 Cuando ha transcurrido un año desde la última actualización.
 Cuando han ocurrido cambios en la infraestructura tecnológica y/o
aplicativos objeto del alcance de este plan.
 Cuando los resultados de las pruebas requieren actualización del
DRP o sus procedimientos.
 Cuando hay cambios en el personal que operaría el DRP.
 Cuando los resultados de auditorías así lo indican.

Algunas actividades a realizar para mantener vigente el DRP, son:

No Actividad Responsable Frecuencia

Cada vez que se realice un

Actualización de los procedimientos de
1. recuperación y contingencia de la
infraestructura tecnológica
cambio a la infraestructura de
Líderes de los procesos
producción o se realice una
prueba de contingencia

Sincronización de la configuración de Líder de Infraestructura

la infraestructura respaldada en el
2. Permanente
Servidor Central Alterno (Incluyendo Líder de redes y
replicación de data) comunicaciones
Monitoreo de la infraestructura
respaldada en el Servidor Central
Alterno, para verificar su disponibilidad
3. Líder de Infraestructura Permanente
en caso de que se presente un evento,
dependiendo del criterio definido de
recuperación (prendido o apagado)
Ejecución de pruebas periódicas para
Profesionales Cada semestre y sobre
4. verificar el correcto funcionamiento de
Especializados aplicativos específicos.
los sistemas respaldados
No Actividad Responsable Frecuencia

Ejecución del procedimiento de

5. respaldo de datos de la infraestructura Líder de Infraestructura Permanente
tecnológica

Semestral o cada vez que se

Obtener imagen del sistema de
6.
servidores y equipos de red.
Líder de Infraestructura
realice un cambio a la
infraestructura de producción
Líder de redes y
o se realice una prueba de
comunicaciones
contingencia

10.4. ACTIVIDADES DE PRUEBA

La programación y metodología a utilizar en la realización de pruebas al DRP

están relacionadas en el Procedimiento de Gestión al Plan de Recuperación
ante Desastres. Estas pruebas deben incluir:
Escenarios específicos a fallas de:
 Respaldo de la información teniendo en cuenta los medios en que se
encuentren.
 Infraestructura de comunicaciones.
 Infraestructura de bases de datos.
 Infraestructura técnica (servidores)

Pruebas generales fallas de:

 Centros de cómputo en cada dependencia.
 Aplicaciones.

10.5. DISTRIBUCIÓN: PLAN DE RECUPERACIÓN ANTE DESASTRES

Se debe entregar una copia final COMPLETA del DRP a:

 Director de Informática y Desarrollo
 Líder de Seguridad de la Información
 Líder de Infraestructura.
 Administrador de Redes y Comunicaciones
 Proveedor de Centro de custodia.

Las diferentes copias del documento deben ser controladas, y cada que se cambie
de versión, se deberá recoger las versiones anteriores.
11. ACTIVIDADES DE RECUPERACIÓN Y CONTINGENCIA

A continuación se definen los pasos a seguir para recuperar los

componentes de la infraestructura tecnológica:

11.1. ¿Cómo configurar el switch de contingencia en caso de falla del switch

de servidores?

a) Desconectar de cada uno de los centros de cableado los cables de fibra de

los dos switch y si hay otros en stack.
b) Obtener la documentación de operación en contingencia del Switch de
servidores.
c) Encendido de los switch de contingencia.
d) Desconexión de servidores y fibras No.1 de conexión de los centros de
cableado del switch de servidores y conexión al switch de contingencia, de
acuerdo a la documentación.
e) Reinicio de servidores en este caso todos.
f) Orden de mantenimiento correctivo del switch de servidores.
g) Comunicación a los funcionarios y personas correspondientes sobre la
operación en contingencia.
h) Una vez corregida la falla del Switch de servidores y cuando este se
encuentre en operación normal.
i) Obtener la documentación de retorno a la normalidad del Switch de
servidores.
j) Programar la fecha de retorno y las consideraciones necesarias para
garantizar la disponibilidad de las comunicaciones.
k) Apagar los servidores y otros equipos con sus respectivos servicios.
l) Conectar y prender el Switch de servidores y verificar su funcionamiento.
m) Conectar los cables de fibra del otro switch y otros del Stack en cada centro
de cableado
n) Volver a conectar los servidores y las fibras No. 1 de los centros de cableado
al switch, de acuerdo a la documentación.
o) Verificar su funcionalidad.
p) Comunicar a los funcionarios y personas correspondientes del retorno a la
operación normal y el agradecimiento por su comprensión y apoyo.

11.2. ¿Cómo utilizar el switch de contingencia ante una falla del switch de
dependencias en el centro de cableado?
a) Ubicar el switch de contingencia en el centro de cableado correspondiente.
b) Conectar el switch de contingencia en el Centro de Cableado.
c) Conectar con un patchcore un punto de un switch funcional por el frente y
desconectar el cable de fibra del switch dañado.
 d) Verificar la conectividad con la operación de los lets.
e) Desconectar el cable de stack de la parte posterior del Switch.
f) Conectar todos los puntos del switch que está fallando al switch de
contingencia.
g) Verificar conectividad.
h) Tramitar el arreglo o compra del switch defectuoso.
i) Ubicar y configurar el switch nuevo o ajustado.
j) Conectar el stack, y la fibra óptica.
k) Mover los parch core del switch de contingencia al switch
l) Verificar conectividad.
m)Comunicar el restablecimiento del servicio en contingencia.
n) Programar la fecha de retorno y las consideraciones necesarias para
garantizar la disponibilidad de las comunicaciones
o) Ubicar y conectar el nuevo switch de dependencia.
p) Conectar el cable de stack de la parte posterior del switch.
q) Verificar conectividad.
r) Desconectar y conectar todos los puntos del switch de contingencia al
switch.
s) Comunicar del restablecimiento del servicio.

11.3. ¿Cómo utilizar el switch de contingencia ante una falla de un switch de

una dependencia?

a) Conectar el cable del Router del equipo de comunicaciones de la empresa

contratada.
b) Verificar el servicio de comunicaciones.
c) Mover los patc core del switch dañado al de contingencia.
d) Verificar los servicios de comunicaciones
e) Retirar y Enviar el switch para el arreglo.
f) Configurar el nuevo switch.
g) Tramitar el arreglo o compra del switch defectuoso.
h) Realizar el retorno a la operación normal de acuerdo con las
recomendaciones correspondientes

11.4. ¿Cómo utilizar el switch de contingente como contingencia ante una

falla del switch del firewall?

a) Obtener la documentación de operación del switch de contingencia para

el switch de firewall
b) Desconectar la salida de Internet.
c) Ubicar y conectar el switch de contingencia.
d) Verificar que este operativo el firewall
e) Retirar el switch del firewall que falló y reemplazarlo por el switch de
contingencia.
 f) Verificar conectividad hacia Internet.
g) Tramitar el arreglo o compra del switch defectuoso.
h) Realizar el retorno a la operación normal de acuerdo con las
recomendaciones correspondientes.

12. CONFIGURACION DE LOS SISTEMAS

Antes de poner en funcionamiento el servicio del servidor SQL y hacerlo accesible

para todos los usuarios, es importante realizar cierto número de operaciones de
configuración del servidor y de las herramientas de administración cliente con el
objetivo de protegerse contra cualquier operación delicada.

12.1. Verificar la instalación

Como para todos los productos, es importante asegurarse de que la instalación se

ha ejecutado correctamente y de que el servidor está operativo.

a. Verificar los elementos instalados

Con el explorador de archivos se puede verificar si está bien definida la

arborescencia que reagrupa todos los archivos necesarios para el correcto
funcionamiento del motor de base de datos. Si la instalación se ha hecho utilizando
los parámetros predeterminados, esta arborescencia es c:\Program
Files\Microsoft SQL Server\110. Los archivos de datos se encuentran en el
directorio c:\Program Files\Microsoft SQL
Server\MSSQL11.MSSQLSERVER\MSSQL\DATA, excepto si se ha definido otra
ruta durante la instalación.
 A nivel de archivos, se puede consultar el diario de instalación (summary.txt), que
está en el directorioc:\Program Files\Microsoft SQL Server\110\Setup
Bootstrap\LOG . La documentación es útil cuando el proceso de ejecución termina
con algún error. Así, se podrá entender mejor el origen del problema. Este archivo
de resumen se gestiona por cada ejecución del programa de instalación. Una
nueva ejecución del programa de instalación va a renombrar (con fecha y hora) el
archivo resumen existente para conservar la traza de todas las instalaciones.

b. Verificar el arranque de los servicios

Para un uso clásico de la base, los dos servicios MS SQL Server y SQL Server.

12.2. Configuración de instancia

Cuando una base de datos se implementa en producción a menudo hay un contrato

de nivel de servicio (SLA) que define áreas como los niveles de rendimiento
requeridos a partir de la base de datos y el nivel de disponibilidad necesario de la
base de datos. Los términos del SLA controlan normalmente los requisitos de
configuración para la instancia.

Una instancia se configura normalmente inmediatamente después de que ha

instalado. La configuración inicial se determina normalmente por los requisitos del
SLA de los tipos de bases de datos planeadas para implementarse en la
instancia. Una vez implementadas las bases de datos, los administradores de bases
de datos supervisan el rendimiento de la instancia y ajustan la configuración según
sea necesaria si las métricas de rendimiento muestran que la instancia no cumple
los requisitos del SLA.

SQL Server Management Studio

Se trata de la herramienta principal de SQL Server y está destinada a los

desarrolladores y administradores.

SQL Server Management Studio (SSMS) es la consola gráfica de administración de

las instancias de SQL Server. Con esta herramienta es posible administrar varias
instancias locales o remotas. SQL Server Management Studio también es la
herramienta principal de los desarrolladores de bases de datos, que la usan para
definir scripts de creación de tablas, vistas, procedimientos, funciones, triggers de
base de datos...

Esta herramienta se puede iniciar desde línea de comandos ...

12.3. Los servicios

Los diferentes componentes del servidor se ejecutan en forma de servicios. Por lo

tanto, es necesario que estos servicios sean iniciados para poder trabajar con el
servidor. Estos servicios se pueden gestionar con el administrador de configuración
de SQL Server, aunque también se pueden gestionar como todos los servicios de
Windows.

Desde el administrador de configuración, es sencillo visualizar el estado del servicio

y modificar sus propiedades.

Como todos los servicios de Windows, se pueden gestionar de manera centralizada

en el servidor Windows.
 Por último, es posible actuar sobre estos servicios directamente en línea de
comandos por medio de los comandos net start y net stop. En el momento de un
inicio por medio de línea de comandos, es posible anular la configuración por
defecto del servicio especificando la configuración que se debe utilizar en forma
de parámetros. Por ejemplo, la opción m (net start mssqlserver m) permite iniciar
el servidor en modo monousuario.

En caso de problemas de inicio, es posible iniciar el servidor SQL Server como

una aplicación con la ayuda de sqlservr.exe.

12.4. Gestión de los accesos al servidor

Antes de poder trabajar con los datos gestionados por las bases de datos, es
necesario en primer lugar conectarse al servidor SQL. Esta etapa permite hacerse
identificar por el servidor SQL y utilizar posteriormente todos los derechos que se
asignan a la conexión. En SQL existen dos modos de gestión de los accesos al
servidor de base de datos.

 Modo de seguridad de Windows

Este tipo de gestión de seguridad permite apoyarse sobre los usuarios y los grupos
de Windows para el dominio y el puesto local. SQL Server utiliza la gestión de los
usuarios de Windows (gestión de las contraseñas...) y recupera únicamente los
nombres para crear conexiones al servidor.

Una funcionalidad muy importante de SQL Server es poder autorizar a los grupos
de Windows a conectarse. La gestión de los grupos permite realizar una
administración más flexible.

12.5. Gestión de los usuarios de la base de datos

Después de la definición de las conexiones (login) a nivel del servidor, es necesario

definir los usuarios en las diferentes bases de datos.

Los permisos de uso de los objetos definidos en la base de datos se asignan a

nivel de los usuarios de base de datos. Cuando se define una conexión, la base
de datos predeterminada permite situar la cuenta de conexión sobre una base de
datos para comenzar a trabajar. Sin embargo, la conexión solo podrá trabajar
sobre la base de datos si existe una cuenta de usuario definida a nivel de la base
de datos y asociada a la conexión. Este es un punto de paso obligatorio, salvo si
se asigna a la conexión los privilegios de alto nivel.

Si no se define ninguna base de datos predeterminada a nivel de la conexión,

entonces la base Master se considera como base de datos predeterminada, lo
que no es una buena elección.
 Los usuarios de base de datos se asocian a una conexión a nivel del servidor. Sin
embargo, algunos usuarios, como guest, sys e INFORMATION_SCHEMA, no se
mapean a ninguna conexión.

Si un usuario tiene una conexión a SQL Server pero no existe usuario de base de
datos que le permita trabajar sobre las bases de datos, el usuario solo puede
realizar operaciones muy limitadas:

 Seleccionar la información contenida en las tablas de sistema y ejecutar

algunos procedimientos almacenados.
 Acceder a todas las bases de datos de usuario con una cuenta de
usuario guest.
 Ejecutar las instrucciones.

13. POLÍTICAS DE COPIAS DE SEGURIDAD

La gestión de las copias de seguridad es una de las tareas más importantes que
debe realizar el administrador de bases de datos. Si las operaciones de copia de
seguridad se planifican con exactitud y rigor, es perfectamente posible realizarlas
en forma de trabajos automatizados y el responsable será avisado por correo
electrónico del correcto desarrollo de las operaciones.

Las copias de seguridad se realizan para prevenir las posibles pérdidas de datos
como consecuencia de:

 Un problema de soporte.
 Errores de usuario.
 Una pérdida permanente del servidor.

Las copias de seguridad SQL Server permiten hacer una copia de seguridad de la
base de datos incluso cuando los usuarios están conectados. Esta copia de
seguridad va a tener en cuenta todos los archivos que forman la base de datos y
va a registrar su ubicación. El proceso de copia de seguridad asegura la
coherencia de los datos y los diarios, capturando todas las actividades que se
producen durante dicho proceso.

Aunque la base de datos permanece accesible durante la copia de seguridad,

algunas operaciones son imposibles, a saber:

 Crear o modificar una base de datos (fundamentalmente la extensión

automática del diario (o registro) de transacciones).
 Crear un índice.
  Ejecutar operaciones que no están trazadas por un fichero de log, ya que el
proceso de copia de seguridad utiliza el diario para garantizar la coherencia
de los datos.

13.1. PLANIFICACION.

La planificación de las operaciones de copia de seguridad implica también

las de restauración, porque la una no se hace sin la otra. Son las exigencias
en materia de disponibilidad de datos las que van a determinar los criterios
para el establecimiento de las copias de seguridad. Para realizar esta
planificación, es necesario reflexionar sobre todos los incidentes que pueden
surgir y saber cuáles son las necesidades de copia de seguridad para
restaurar lo mejor posible la información. Será posible automatizar todos
estos trabajos de copia de seguridad y probar la restauración, validando el
buen funcionamiento de los procedimientos de copia de seguridad.

Las principales preguntas que es necesario plantearse para planificar lo mejor

posible las copias de seguridad son:

 ¿Cuál es el tamaño de cada base de datos?

 ¿Cuál es el volumen de las modificaciones de datos?
 ¿Algunas tablas están sujetas a más modificaciones que otras?
 ¿Cuánto tiempo puede permanecer no operativa la base de datos?
 ¿La pérdida de modificaciones es crucial?
 ¿Es fácil recrear los datos perdidos?
 ¿Cuáles son los periodos importantes de utilización de la base de datos?
 ¿La base sufre sobrecargas de trabajo puntuales durante las que no es
posible lanzar una copia de seguridad?
 ¿Los usuarios deben continuar accediendo a los datos durante las
operaciones de copia de seguridad?

13.1.1. ESTABLECIMIENTO DEL PLAN DE ACCIÓN.

En esta fase de planificación se establece los procedimientos relativos a:

 Sistemas e Información.
 Equipos de Cómputo.
 Obtención y almacenamiento de los Respaldos de Información (BACKUPS).
Políticas (Normas y Procedimientos de Backups).
 Sistemas de Información.

La Alcaldía deberá tener una relación de los Sistemas de Información con

los que cuenta.
Se debe tener en cuenta en caso de catástrofe el Hardware, impresoras, lectoras,
scanner, módems, fax y otros, detallando su ubicación (software que usa, ubicación
y nivel de uso institucional).

Se debe emplear los siguientes criterios sobre identificación y protección de

equipos:
 Pólizas de seguros comerciales, como parte de la protección de los activos
institucionales y considerando una restitución por equipos de mayor
potencia, teniendo en cuenta la depreciación tecnológica.
 Señalización o etiquetamiento de las computadoras de acuerdo a la
importancia de su contenido y valor de sus componentes, para dar
prioridad en caso de evacuación. Por ejemplo, etiquetar de color rojo los
servidores, color amarillo a los PC con información importante o
estratégica, y color verde a las demás estaciones (normales, sin disco duro
o sin uso).
 Mantenimiento actualizado del inventario de los equipos de cómputo
requerido como mínimo para el funcionamiento permanente de cada sistema
en la institución.
 Obtención y almacenamiento de Copias de Seguridad (Backups) se debe
contar con procedimientos para la obtención de las copias de seguridad de
todos los elementos de software necesarios para asegurar la correcta
ejecución de los sistemas en la institución.

13.2. ESTABLECIMIENTO DE COPIAS DE SEGURIDAD.

Las operaciones de copia de seguridad pueden ponerse en práctica bien mediante

SQL Server Management Studio, o bien con la ayuda de procedimientos
almacenados en Transact SQL. Como siempre, la solución gráfica ofrece facilidad
de aplicación, pero los comandos Transact SQL permiten acceder a la totalidad de
las opciones propuestas.

13.2.1. Los modos de recuperación

Las posibilidades que se ofrecen en materia de copia de seguridad, y por lo tanto
de la restauración, están directamente asociadas al modo de configuración definido
en cada base de datos. Los tres modos de recuperación que es posible configurar
son:

 El modo de recuperación simple: el diario se utiliza únicamente para

garantizar la persistencia de las operaciones realizadas sobre los datos. Se
trunca en cada punto de sincronización.
 El modo de recuperación completo: en este modo, todas las transacciones
se registran en el diario y permanecen almacenadas incluso después del
punto de sincronización. En caso de error, la perdida de datos se reduce, ya
que la operación de restauración es posible hasta el punto de fallo (si se ha
 adoptado una política correcta de copia de seguridad). Se trata del modo de
recuperación por defecto definido en las bases de datos de usuario.
 El modo de recuperación de registro masivo: en este modo de
recuperación ...

13.2.2. Creación de copia en espejo

La copia en espejo de las bases de datos permite garantizar una solución de

alta disponibilidad conservando una inversión material razonable. En este tipo de
alta disponibilidad, una base se copia en espejo con otra instancia de SQL Server.
La base de datos inicial tiene el calificativo de principal, mientras que la base de
datos de destino se llama espejo. El papel desempeñado por cada una de las
bases de datos es específico de cada relación de copia en espejo. El simple hecho
de que una instancia contenga bases de datos que desempeñen el papel de
principal en una copia en espejo no significa que no pueda contener bases de
datos espejo en otras relaciones de copia en espejo.

Esta solución de alta disponibilidad no permite obviar las operaciones de copia de

seguridad. Es preferible tener una copia en espejo como solución complementaria
para garantizar la mejor disponibilidad posible de los datos.

La copia en espejo de las bases se efectúa mediante el registro de transacciones.

Todas las transacciones efectuadas en la base de datos principal se recogen en
el registro de transacciones. Esta información se registra inicialmente en memoria
y luego se registra lo antes posible en disco. Es en el momento de esta escritura
en disco cuando la información se envía a sus espejos. La base espejo registra
esta información en disco. Las transacciones se recrean posteriormente a las dos
bases (principal y espejo).

13.2.3 Planificación de copias de seguridad.

N° ACTIVIDAD FRECUENCIA RESPONSABLES MEDIDAS DE

CONTROL
1 Copias de seguridad Período: Anual de Todos los Verificación anual
de la información y todos los funcionarios de de la aplicación de
documentos de los documentos de la cada uno de los los procedimientos
discos duros de los Alcaldía de San procesos de la establecidos.
computadores de la Antonio del SENA. Alcaldía de San Custodia según
Alcaldía de San Medio: DVD o CD – Antonio del SENA. tabla de retención
Antonio del SENA BD, USB, DD, DD documental.
(Incluye archivos de espejo, Registro en el libro
Word, Excel, PDF, almacenamiento en de control de
Power Point y de la nube. Backups.
edición gráfica) NOTA: No incluye
archivos de uso
personal
Las copias de seguridad son las siguientes:

Backup del Sistema Operativo: Todas las versiones de sistema operativo

instalados en la Red.

Backup de Software Base: (Lenguajes de Programación utilizados en el desarrollo

de los aplicativos institucionales).

Backup del software aplicativo: Backups de los programas fuente y los

programas ejecutables.

Backup de los datos (Base de datos, password y todo archivo necesario para
la correcta ejecución del software aplicativos de la institución).

Backup del Hardware, se puede implementar bajo dos modalidades:

Modalidad Externa: mediante el convenio con otra institución que tenga equipos
similares o mejores y que brinden la capacidad y seguridad de procesar
nuestra información y ser puestos a nuestra disposición al ocurrir una
continencia mientras se busca una solución definitiva al siniestro producido.

Modalidad Interna: Si se dispone de más de una Edificación, en ambos se debe

tener señalado los equipos, que por sus capacidades técnicas son susceptibles de
ser usados como equipos de emergencia.

Es importante mencionar que en ambos casos se debe probar y asegurar que los
procesos de restauración de información posibiliten el funcionamiento adecuado de
los sistemas.

14. POLÍTICAS DE SEGURIDAD DE LA INFORMACIÓN.

 Se debe establecer procedimientos, normas y de terminación de

responsabilidades en la obtención de los "Backups" o Copias de Seguridad.

 Se debe considerar la periodicidad de cada tipo de Backups: los Backups de

los sistemas informáticos se realizan de manera diferente:
o Sistema Integrado de Gestión Académico [Sec. De Educación]: en los
procesos académicos de Inscripción de curso y registro de Actas se
realiza Backup diario, para los demás periodos se realiza el Backup
semanal.
o Sistema de Ingresos: Backup diario.
o Sistema de Tramite Documentario [Sec. de Hacienda]: Backup diario.
o Sistema de Abastecimientos: Backup semanal
o Sistema de Control de Asistencia del personal: Backup semanal.
o Sistema de Banco de Preguntas [Sec. De Educación]: Backup cada
periodo de examen.
 Respaldo de información de movimiento entre los periodos que no se sacan
Backups: días no laborales, feriados, etc. en estos días es posible programar
un Backup automático.

 Almacenamiento de los Backups en condiciones ambientales optimas,

dependiendo del medio magnético empleando.

 Reemplazo de los Backups, en forma periódica, antes que el medio

magnético de soporte se pueda deteriorar. No se realiza reemplazos, pero se
realiza copias de las mismas, considerando que no se puede determinar
exactamente el periodo de vida útil del dispositivo donde se ha realizado el
Backup.
 Almacenamiento de los Backups en locales diferentes donde reside la
información primaria (evitando la pérdida si el desastre alcanzo todo el
edificio o local). Esta norma se cumple con la información histórica, es decir
se tiene distribuidos los Backups de la siguiente manera:

1. Una copia debe almacenarse en las instalaciones del Oficina

de Sistemas de la Alcaldía.
2. Una segunda copia reside en la Oficina del Alcalde que genera
la información Pruebas periódicas de los Backups (Restore),
verificando su funcionalidad, a través de los sistemas
comparando contra resultados anteriormente confiables.
 Criterios y procedimientos de prueba del plan. La destreza indica que los
planes de recuperación deben ser probados en su totalidad por lo menos una
vez al año.
 La documentación debe especificar los procedimientos y la frecuencia
con que se realizan las pruebas.
CONCLUSIONES

El costo de la Recuperación en caso de desastres severos, como los de un

terremoto que destruya completamente el interior de edificios e
instalaciones, estará directamente relacionado con el valor de los equipos
de cómputo e información que no fueron informados oportunamente y
actualizados en la relación de equipos informáticos asegurados que
obra en poder de la compañía de seguros.

El Costo de Recuperación en caso de desastres de proporciones menos

severos, como los de un terremoto de grado inferior a 7 o un incendio
controlable, estará dado por el valor no asegurado de equipos informáticos
e información más el Costo de Oportunidad, que significa, el costo del menor
tiempo de recuperación estratégica, si se cuenta con parte de los equipos e
información recuperados.

El paso inicial siempre en el desarrollo del plan contra desastres DRP, es la

identificación de las personas que serán las responsables de crear el plan y
coordinar las funciones. Típicamente las personas pueden ser: SOLO
personal del departamento de TI o personal de Seguridad de la entidad que
tengan un conocimiento amplio y físico de toda la infraestructura de la
entidad.

RECOMENDACIONES

 La protección de la información es vital ante la posible pérdida, destrucción,

robo y otras amenazas de una empresa. El Plan de Contingencia es la
preparación de un plan de copias de seguridad, elemento primordial y
necesario para la recuperación, el cual indica las acciones que deben
tomarse inmediatamente tras el desastre. Lo importante del plan es la
organización, la responsabilidad y el compromiso de cada integrante
conscientes de su rol.

 Se debe contar con procedimientos específicos y puntuales para la obtención

de las copias de seguridad de todos los elementos de software necesarios
para asegurar la correcta ejecución de los aplicativos en la institución.
BIBLIOGRAFIA

 AA2-Ev4-Plan de Configuración y Recuperación Ante Desastres para el

SMDB.
 SUPERINTENDENCIA DE SOCIEDADES. GESTIÓN DE
INFRAESTRUCTURA Y TECNOLOGIAS DE INFORMACION. GINT-G-005
Guía Plan de Recuperación ante Desastres DRP.(19 Febrero 2018)
 https://docs.oracle.com/cd/E65192_01/ELSDR/drintro.htm#CHDEAIDE
 https://docs.microsoft.com/es-es/sql/database-engine/sql-server-business-
continuity-dr?view=sql-server-2017
 https://docs.microsoft.com/es-es/sql/database-engine/configure-
windows/configure-database-engine-instances-sql-server?view=sql-server-
2017
 https://www.ediciones-
eni.com/open/mediabook.aspx?idR=f8e8fdc4b346dab8ce446b9b992f1d6d