6 GESTIÓN DE OPERACIONES DE DATOS

Data Operations Management es la cuarta función de administración de datos en

el marco de administración de datos que se muestra en las figuras 1.3 y 1.4. Es la
tercera función de gestión de datos que interactúa con y está influenciada por la
función de gobernabilidad de datos. El Capítulo 6 define la función de
administración de operaciones de datos y explica los conceptos y actividades
involucrados en la administración de operaciones de datos.

6.1 Introducción

La administración de operaciones de datos es el desarrollo, mantenimiento y

soporte de datos estructurados para maximizar el valor de los recursos de datos
para la empresa. La gestión de operaciones de datos incluye dos subfunciones:
soporte de base de datos y gestión de tecnología de datos.

Los objetivos de la gestión de operaciones de datos incluyen: 1. Proteger y

garantizar la integridad de los activos de datos estructurados. 2. Gestionar la
disponibilidad de los datos a lo largo de su ciclo de vida. 3. Optimizar el
rendimiento de las transacciones de base de datos.

El diagrama de contexto para la gestión de operaciones de datos se muestra

en la Figura 6.1.

6.2 Conceptos y actividades

El Capítulo 1 declaró que la administración de operaciones de datos es la función

de brindar soporte desde la adquisición de datos hasta la depuración de datos.
Los administradores de bases de datos (DBA) desempeñan un papel clave en esta
función crítica. Los conceptos y actividades relacionados con la administración de
operaciones de datos y los roles de los administradores de bases de datos se
presentan en esta sección.

6.2.1 Soporte de base de datos

El soporte de la base de datos se encuentra en el corazón de la gestión de datos,

y lo proporcionan los DBA. El rol de DBA es el rol de profesional de datos más
establecido y más ampliamente adoptado, y las prácticas de administración de
bases de datos son quizás las más maduras de todas las prácticas de manejo de
datos. Los DBA desempeñan el papel dominante en la gestión de operaciones de
datos, así como en la gestión de la seguridad de datos (ver Capítulo 7). Como se
discutió en el Capítulo 5, los DBA también desempeñan roles críticos en el
desarrollo de datos, particularmente en el modelado físico de datos y el diseño de
bases de datos, así como el soporte para entornos de bases de datos de
desarrollo y pruebas.

De hecho, muchos DBA se especializan como DBA de desarrollo o DBA de

producción. Los DBA de desarrollo se centran en las actividades de desarrollo de
datos, mientras que los DBA de producción realizan actividades de gestión de
operaciones de datos. En algunas organizaciones, cada rol especializado reporta
a diferentes organizaciones dentro de TI. Los DBA de producción pueden formar
parte de una infraestructura de producción y un grupo de soporte de operaciones.
Los DBA de desarrollo y / o los DBA de producción a veces se integran en las
organizaciones de desarrollo de aplicaciones.

Gestión de operaciones de datos

Definición: Planificación, control y soporte para activos de datos estructurados a

lo largo del ciclo de vida de los datos.

Desde la creación y adquisición hasta el archivo y la purga. .

Metas:

1. Proteger y garantizar la integridad de los activos de datos estructurados.

2. Gestionar la disponibilidad de datos a lo largo de su ciclo de vida.

3. Optimizar el rendimiento de las transacciones de base de datos.

Entradas:

• Requerimientos de datos

• Arquitectura de datos

• Modelos de datos

• Datos heredados

• Acuerdos de Nivel de Servicio

Proveedores:

• ejecutivos

• Comité de Dirección de TI

• Consejo de Gobierno de Datos

• Administradores de datos

• Arquitectos de datos y modeladores

• Desarrolladores de software

Participantes:

• Administradores de bases de datos

• Desarrolladores de software

• Gerentes de Proyecto

• Administradores de datos

• Arquitectos de datos y analistas

• Ejecutivos de DM y otras TI

administración

• Operadores de TI

Herramientas:

• Sistemas de gestión de bases de datos

• Herramientas de desarrollo de datos

• Herramientas de administración de base de datos

• Herramientas de productividad de oficina

Ocupaciones:

1. Soporte de base de datos

1.Implementación y control de entornos de base de datos (C)

2. Obtener datos de origen externo (O)

3. Plan de recuperación de datos (P)

4.Backup y Recuperar Datos (O)

5. Ajuste los niveles de servicio de la base de datos (P)

6.Monitor and Tune Database Performance (C)

7. Plan de retención de datos (P)

8. Archivar, retener y purgar datos (O)

9.Soporte de bases de datos especializadas (O)

2. Gestión de la tecnología de datos

1.Comprender los requisitos de tecnología de datos (P)

2. Definir la arquitectura de tecnología de datos (P)

3.Evaluar la tecnología de datos (P)

4.Instalar y administrar tecnología de datos (C)

5. Licencias de tecnología de datos de seguimiento e inventario (C)

6.Soporte al uso y problemas de la tecnología de datos (O)

Entregables primarios:

• Entornos técnicos DBMS

• Dev / Test, QA, DR, y Producción

Bases de datos
• Datos de origen externo

• Base de datos de rendimiento

• Planes de recuperación de datos

• Continuidad del negocio

• Plan de retención de datos

• Datos archivados y depurados

Consumidores:

• Creadores de datos

• Consumidores de información

• Clientes empresariales

• Profesionales de datos

• Otros profesionales de TI

Actividades: (P) - Planificación (C) - Control (D) - Desarrollo (O) - Operacional

Métrica

• Disponibilidad

• Actuación

Figura 6.1 Diagrama de contexto de gestión de operaciones de datos

Los DBA de producción asumen la responsabilidad principal de la gestión de las

operaciones de datos,

incluso:

 Garantizar el rendimiento y la fiabilidad de la base de datos, incluido el

rendimiento.

ajuste, seguimiento y notificación de errores.

 Implementar mecanismos adecuados de copia de seguridad y recuperación

para garantizar la

Recuperabilidad de los datos en cualquier circunstancia.

 Implementación de mecanismos para la agrupación en clúster y la conmutación
por error de la base de datos, si

La disponibilidad continua de datos es un requisito.

 Implementación de mecanismos para archivar la gestión de operaciones de

datos.

El DBA de producción es responsable de los siguientes resultados principales:

1. Un entorno de base de datos de producción, incluida una instancia del DBMS y

su Servidor de soporte, de un tamaño y capacidad suficiente para asegurar una
adecuada rendimiento, configurado para el nivel adecuado de seguridad,
confiabilidad y disponibilidad. La administración del sistema de base de datos es
responsable del DBMS ambiente.

2. Mecanismos y procesos de implementación controlada y cambios a Bases de

datos en el entorno de producción.

3. Mecanismos apropiados para garantizar la disponibilidad, integridad y

capacidad de recuperación de los datos en respuesta a todas las circunstancias
posibles que podrían resultar en la pérdida o corrupción de los datos.

4. Mecanismos apropiados para detectar e informar cualquier error que ocurra en

la base de datos, el DBMS o el servidor de datos.

5. Disponibilidad, recuperación y rendimiento de la base de datos de acuerdo con

los acuerdos de nivel de servicio.

Los DBA no realizan todas las actividades de la gestión de operaciones de datos

exclusivamente. Los administradores de datos, los arquitectos de datos y los
analistas de datos participan en la planificación de la recuperación, la retención y
el rendimiento. Los administradores de datos, los arquitectos de datos y los
analistas de datos también pueden participar en la obtención y procesamiento de
datos de fuentes externas

6.2.1.1 Implementar y controlar entornos de bases de datos

La administración de sistemas de bases de datos incluye las siguientes tareas:

 Actualización del software DBMS: los DBA instalan nuevas versiones del
software DBMS y aplican correcciones de mantenimiento proporcionadas por el
proveedor de DBMS en todos los entornos, desde el desarrollo hasta la
producción.
 Mantenimiento de múltiples instalaciones, incluidas diferentes versiones de
DBMS: los DBA instalan y mantienen múltiples instancias del software DBMS en
entornos de desarrollo, pruebas y producción, y administran la migración de las
versiones de software DBMS a través de los entornos.

 Instalar y administrar tecnología de datos relacionada, incluido el software de

integración de datos y herramientas de administración de datos de terceros.

 Configuración y ajuste de los parámetros del sistema DBMS.

 Administración de la conectividad de la base de datos: además de los

problemas de seguridad de los datos (consulte el Capítulo 7), el acceso a las
bases de datos en toda la empresa requiere experiencia técnica. Los DBA
proporcionan orientación técnica y soporte para los usuarios de TI y de negocios
que requieren conectividad de base de datos.

 Trabajar con programadores de sistemas y administradores de red para ajustar

los sistemas operativos, las redes y el middleware de procesamiento de
transacciones para trabajar con el DBMS.

 Dedicar el almacenamiento adecuado para el DBMS y permitir que el DBMS

funcione con dispositivos de almacenamiento y software de administración de
almacenamiento. La administración del almacenamiento optimiza el uso de
diferentes tecnologías de almacenamiento para el almacenamiento rentable de
datos más antiguos, con menos frecuencia de referencia. El software de
administración de almacenamiento migra los datos de referencia con menor
frecuencia a dispositivos de almacenamiento menos costosos, lo que resulta en un
tiempo de recuperación más lento. Algunas bases de datos funcionan con el
software de administración de almacenamiento para que las tablas de bases de
datos particionadas puedan migrarse a un almacenamiento más lento y menos
costoso. Los DBA trabajan con los administradores de almacenamiento para
configurar y monitorear procedimientos efectivos de administración de
almacenamiento.

Prepare listas de verificación para garantizar que estas tareas se realicen con un
alto nivel de calidad. Estas listas de verificación establecen los pasos
involucrados. El trabajo de un DBA debe ser auditado por otro DBA antes de que
los cambios entren en producción.

El DBA es el custodio de todos los cambios en la base de datos. Si bien muchas

partes pueden solicitar cambios, el DBA define los cambios precisos que se deben
realizar en la base de datos, implementa los cambios y controla los cambios. Los
DBA deben usar un proceso controlado, documentado y auditable para mover los
cambios de la base de datos de la aplicación a los entornos de Aseguramiento o
Certificación de Calidad (QA) y Producción, en parte debido a Sarbanes-Oxley y
otros requisitos normativos. Una solicitud de servicio o solicitud de cambio
aprobada por el gerente generalmente inicia el proceso. En la mayoría de los
casos, el DBA debe tener un plan de retroceso para revertir los cambios en caso
de problemas.

Pruebe primero todos los cambios en el entorno de control de calidad en el

entorno de desarrollo / prueba, y pruebe todos los cambios en la producción,
excepto los cambios de emergencia, en el entorno de control de calidad. Mientras
que los DBA de desarrollo controlan los cambios en los entornos de desarrollo /
prueba, los DBA de producción controlan los cambios en los entornos de
producción, y también controlan los entornos de control de calidad.

6.2.1.2 Obtener datos de fuentes externas

La mayoría de las organizaciones obtienen algunos datos de fuentes externas de

terceros, como listas de clientes potenciales comprados a un agente de
información o datos de productos proporcionados por un proveedor. Los datos
tienen licencia o se proporcionan de forma gratuita; se proporciona en varios
formatos diferentes (CD, DVD, EDI, XML, fuentes RSS, archivos de texto); y es de
una sola vez o se actualiza regularmente a través de un servicio de suscripción.
Algunas adquisiciones requieren acuerdos legales.

Un enfoque administrado para la adquisición de datos centraliza la responsabilidad

de los servicios de suscripción de datos con analistas de datos. El analista de
datos deberá documentar la fuente de datos externa en el modelo de datos lógicos
y en el diccionario de datos. Un desarrollador puede diseñar y crear scripts o
programas para leer los datos y cargarlos en una base de datos. El DBA será
responsable de implementar los procesos necesarios para cargar los datos en la
base de datos y / o ponerlos a disposición de la aplicación.

6.2.1.3 Plan para la recuperación de datos

Los consejos de gobernabilidad de datos deben establecer acuerdos de nivel de

servicio (SLA) con las organizaciones de servicios de administración de datos de
TI para la disponibilidad y recuperación de datos. Los acuerdos de nivel de
servicio establecen las expectativas de disponibilidad, permitiendo tiempo para el
mantenimiento y la copia de seguridad de la base de datos, y establecen las
expectativas de tiempo de recuperación para diferentes escenarios de
recuperación, incluidos los posibles desastres.
Los DBA deben asegurarse de que exista un plan de recuperación para todas las
bases de datos y servidores de bases de datos, que cubra todos los escenarios
posibles que podrían resultar en la pérdida o corrupción de los datos. Esto incluye,
pero no se limita a:

 Pérdida del servidor físico de la base de datos.

 Pérdida de uno o más dispositivos de almacenamiento en disco.

 Pérdida de una base de datos, incluida la base de datos maestra DBMS, la base
de datos de almacenamiento temporal, el segmento de registro de transacciones,
etc.

 Corrupción del índice de la base de datos o páginas de datos.

 Pérdida de la base de datos o del sistema de archivos del segmento de registro.

 Pérdida de archivos de copia de seguridad de la base de datos o del registro de

transacciones.

La administración y el grupo de continuidad del negocio de la organización, si

existe, deben revisar y aprobar el plan de recuperación de datos. El grupo de DBA
debe tener acceso fácil a todos los planes de recuperación de datos. Guarde una
copia del plan, junto con todo el software necesario, como el software necesario
para instalar y configurar el DBMS, las instrucciones y los códigos de seguridad,
como la contraseña del administrador, en una ubicación segura, fuera del sitio, en
el caso de una desastre. Las copias de seguridad de todas las bases de datos
deben mantenerse en un lugar seguro, fuera del sitio.

6.2.1.4 Copia de seguridad y recuperación de datos

Haga copias de seguridad periódicas de las bases de datos y, para las bases de
datos OLTP, los registros de transacciones de la base de datos. El SLA para la
base de datos debe incluir un acuerdo con los propietarios de los datos sobre la
frecuencia con la que se realizan estas copias de seguridad. Equilibre la
importancia de los datos con el costo de protegerlos. Para bases de datos
grandes, las copias de seguridad frecuentes pueden consumir grandes cantidades
de almacenamiento en disco y recursos del servidor. Al menos una vez al día,
haga una copia de seguridad completa de cada base de datos.
Además, las bases de datos deben residir en algún tipo de área de
almacenamiento administrado, idealmente una matriz RAID en una red de área de
almacenamiento o SAN, con una copia de seguridad diaria en cinta. Para las
bases de datos OLTP, la frecuencia de las copias de seguridad del registro de
transacciones dependerá de la frecuencia de actualización y la cantidad de datos
involucrados. Para las bases de datos actualizadas con frecuencia, los volcados
de registros más frecuentes no solo brindarán una mayor protección, sino que
también reducirán el impacto de las copias de seguridad en los recursos y
aplicaciones del servidor. Los archivos de copia de seguridad se deben guardar en
un sistema de archivos separado de las bases de datos, y se debe hacer una
copia de seguridad en cinta, o en algún medio de almacenamiento separado,
diariamente. Almacene copias de las copias de seguridad diarias en una
instalación segura fuera del sitio.

Para datos extremadamente críticos, el DBA deberá implementar algún tipo de

esquema de replicación en el que los datos se muevan a otra base de datos en un
servidor remoto. En el caso de una falla en la base de datos, las aplicaciones
pueden "fallar" a la base de datos remota y continuar el procesamiento. Existen
varios esquemas de replicación diferentes, incluidos la creación de reflejo y el
envío de registros. En la creación de reflejo, las actualizaciones de la base de
datos primaria se replican inmediatamente (en términos relativos) en la base de
datos secundaria, como parte de un proceso de confirmación de dos fases. En el
envío de registros, un servidor secundario recibe y carga copias de los registros de
transacciones de la base de datos primaria a intervalos regulares. La elección del
método de replicación depende de la importancia de los datos y de la importancia
de que la conmutación por error al servidor secundario sea inmediata. La
duplicación suele ser una opción más cara que el envío de registros. Para un
servidor secundario, use reflejo; usar el envío de registros para actualizar
servidores secundarios adicionales.

Otras opciones de protección de datos incluyen la agrupación de servidores, en la

que las bases de datos en una matriz de discos compartida pueden conmutar por
error de un servidor físico a otro, y la virtualización del servidor, donde se produce
la conmutación por error entre instancias de servidores virtuales que residen en
dos o más máquinas físicas.

La mayoría de los DBMS son compatibles con las copias de seguridad en caliente
de la base de datos: se realizan copias de seguridad mientras se ejecutan las
aplicaciones. Cuando se producen algunas actualizaciones en tránsito, se
reenviarán hasta su finalización o se revertirán cuando se vuelva a cargar la copia
de seguridad. La alternativa es una copia de seguridad en frío tomada cuando la
base de datos está fuera de línea. Sin embargo, esto puede no ser una opción
viable si las aplicaciones necesitan estar continuamente disponibles. El DBA
también, cuando sea necesario, recuperará las bases de datos perdidas o
dañadas al volver a cargarlas desde la base de datos necesaria y las copias de
seguridad del registro de transacciones para recuperar la mayor cantidad de datos
posible.

6.2.1.5 Establecer niveles de servicio de base de datos

El rendimiento de la base de datos tiene dos facetas: la disponibilidad y el

rendimiento. El rendimiento no se puede medir sin disponibilidad. Una base de
datos no disponible tiene una medida de rendimiento de cero.

Los acuerdos de nivel de servicio entre las organizaciones de servicios de gestión

de datos y los propietarios de datos definen las expectativas de rendimiento de la
base de datos. Por lo general, el acuerdo identificará un período de tiempo
esperado para la disponibilidad de la base de datos y una selección de pocas
transacciones de aplicaciones (una combinación de consultas complejas y
actualizaciones), cada una con un tiempo de ejecución máximo permitido
específico durante los períodos de disponibilidad identificados. Si los tiempos de
ejecución del proceso superan sistemáticamente el SLA, o la disponibilidad de la
base de datos no cumple de manera consistente con el SLA, los propietarios de
los datos le pedirán al DBA que identifique la fuente del problema y tome las
medidas correctivas apropiadas. La disponibilidad es el porcentaje de tiempo que
un sistema o base de datos puede usarse para un trabajo productivo. Los
requisitos de disponibilidad aumentan constantemente, lo que aumenta los riesgos
comerciales y los costos de los datos no disponibles. Las actividades para
garantizar la disponibilidad se realizan cada vez más en la reducción de las
ventanas de mantenimiento.

Cuatro factores relacionados afectan la disponibilidad:

 Capacidad de administración: la capacidad de crear y mantener un entorno

eficaz.

 Recuperabilidad: la capacidad de restablecer el servicio después de la

interrupción y corregir los errores causados por eventos imprevistos o fallas de
componentes.

 Confiabilidad: la capacidad de brindar servicio a niveles específicos por un

período establecido.

 Capacidad de servicio: la capacidad para determinar la existencia de

problemas, diagnosticar sus causas y reparar / resolver los problemas.
Muchas cosas pueden causar una pérdida de disponibilidad de la base de datos,
incluyendo:

 Interrupciones planificadas y no planificadas.

 Pérdida del hardware del servidor.

 Fallo de hardware del disco.

 Fallo del sistema operativo.

 Fallo del software DBMS.

 Problemas de aplicación.

 Fallo de red.

 Pérdida del sitio del centro de datos.

 Problemas de seguridad y autorización.

 Corrupción de datos (debido a errores, diseño deficiente o error del usuario).

 Pérdida de objetos de la base de datos.

 Pérdida de datos.

 Fallo en la replicación de datos.

 Problemas graves de rendimiento.

 Fallos de recuperación.

 Error humano.

Los DBA son responsables de hacer todo lo posible para garantizar que las bases
de datos permanezcan en línea y operativas, incluyendo:

 Ejecutar utilidades de copia de seguridad de base de datos.

 Ejecución de utilidades de reorganización de base de datos.

 Ejecución de estadísticas de recolección de utilidades.

 Ejecución de utilidades de comprobación de integridad.

 Automatizar la ejecución de estas utilidades.

 Explotación de agrupamiento de espacios de tabla y partición.

 Replicar datos a través de bases de datos espejo para garantizar una alta
disponibilidad.

6.2.1.6 Monitorear y ajustar el rendimiento de la base de datos

Los DBA optimizan el rendimiento de la base de datos de manera proactiva y

reactiva, al monitorear el desempeño y al responder a los problemas de manera
rápida y competente. La mayoría de los DBMS proporcionan la capacidad de
monitorear el desempeño, permitiendo a los DBA generar informes de análisis. La
mayoría de los sistemas operativos de servidor tienen un monitoreo y reporte de
capacidades similar.

Los DBA deben ejecutar informes de actividad y rendimiento tanto en el DBMS

como en el servidor de forma regular, incluso durante períodos de gran actividad.
Deben comparar estos informes con informes anteriores para identificar
tendencias negativas y guardarlas para ayudar a analizar problemas a lo largo del
tiempo.

El movimiento de datos puede ocurrir en tiempo real a través de transacciones en

línea. Sin embargo, muchas actividades de movimiento y transformación de datos
se realizan a través de programas por lotes, que pueden ser programas de
extracción por transformación o carga (ETL) o estar limitados a un sistema
internamente. Estos trabajos por lotes deben completarse dentro de las ventanas
especificadas en el programa operativo. Los DBA y los especialistas en integración
de datos monitorean el rendimiento de los trabajos de datos por lotes, observando
tiempos de finalización y errores excepcionales, determinando la causa raíz de los
errores y resolviendo estos problemas.

Cuando se producen problemas de rendimiento, el DBA debe usar las

herramientas de supervisión y administración del DBMS para ayudar a identificar
la fuente del problema. Algunas de las razones más comunes posibles para el bajo
rendimiento de la base de datos son:

 Asignación de memoria (buffer / caché para datos).

 Bloqueo y bloqueo: en algunos casos, un proceso que se ejecuta en la base de

datos puede bloquear recursos de la base de datos, como tablas o páginas de
datos, y bloquear otro proceso que los necesite. Si el problema persiste durante un
intervalo de tiempo demasiado largo, el DBA puede detener el proceso de
bloqueo. En algunos casos, dos procesos pueden "bloqueo", y cada proceso
bloquea los recursos que necesita el otro. La mayoría de los DBMS terminarán
automáticamente uno de estos procesos después de un cierto intervalo de tiempo.
Estos tipos de problemas suelen ser el resultado de una codificación deficiente, ya
sea en la base de datos o en la aplicación.

 Error al actualizar las estadísticas de la base de datos: la mayoría de los DBMS

relacionales tienen un optimizador de consultas integrado, que se basa en
estadísticas almacenadas sobre los datos e índices para tomar decisiones sobre
cómo ejecutar una consulta determinada de la manera más efectiva. Actualice
estas estadísticas regularmente y con frecuencia, especialmente en bases de
datos que son muy activas. El no hacerlo resultará en consultas de bajo
rendimiento.

 Codificación de SQL deficiente: tal vez la causa más común de un rendimiento

deficiente de la base de datos es la codificación SQL deficiente. Los codificadores
de consultas necesitan una comprensión básica de cómo funciona el optimizador
de consultas SQL, y deberían codificar SQL de una manera que aproveche al
máximo las capacidades del optimizador. Encapsule el SQL complejo en
procedimientos almacenados, que pueden precompilarse y optimizarse
previamente, en lugar de incrustarlo en el código de la aplicación. Utilice vistas
para predefinir combinaciones de tablas complejas. Además, evite utilizar SQL
complejo, incluidas las combinaciones de tablas, en las funciones de la base de
datos, que, a diferencia de los procedimientos almacenados, son opacas para el
optimizador de consultas.

 Indización insuficiente: codifique las consultas complejas y las consultas que

involucran tablas grandes para usar índices construidos en las tablas. Crea los
índices necesarios para soportar estas consultas. Tenga cuidado al crear
demasiados índices en tablas muy actualizadas, ya que esto ralentizará el proceso
de actualización.

 Actividad de la aplicación: lo ideal es que las aplicaciones se ejecuten en un

servidor separado del DBMS, para que no compitan por los recursos. Configurar y
Ajustar los servidores de bases de datos para obtener el máximo rendimiento.
Además, los nuevos DBMS permiten que los objetos de la aplicación, como las
clases Java y .NET, se encapsulen en los objetos de la base de datos y se
ejecuten en el DBMS. Tenga cuidado al hacer uso de esta capacidad. Puede ser
muy útil en ciertos casos, pero la ejecución del código de la aplicación en el
servidor de la base de datos puede afectar el rendimiento de los procesos de la
base de datos.

 Aumento del número, tamaño o uso de las bases de datos: para los DBMS que
admiten varias bases de datos y múltiples aplicaciones, puede haber un "punto de
ruptura" en el que la adición de más bases de datos tenga un efecto adverso en el
rendimiento de las bases de datos existentes. En este caso, crea un nuevo
servidor de base de datos. Además, reubique las bases de datos que han crecido
mucho, o que se están usando más que nunca, en un servidor diferente. En
algunos casos, resuelva los problemas con grandes bases de datos archivando los
datos menos utilizados en otra ubicación, o eliminando los datos caducados u
obsoletos.

 Volatilidad de la base de datos: en algunos casos, un gran número de

inserciones y eliminaciones de tablas en poco tiempo puede crear estadísticas de
distribución de base de datos inexactas. En estos casos, desactive la actualización
de las estadísticas de la base de datos para estas tablas, ya que las estadísticas
incorrectas afectarán negativamente al optimizador de consultas.

Una vez que se identifica la causa del problema, el DBA tomará las medidas
necesarias para resolver el problema, lo que incluye trabajar con los
desarrolladores de aplicaciones para mejorar y optimizar el código de la base de
datos, y archivar o eliminar datos que los procesos de aplicaciones ya no
necesitan de forma activa. En casos excepcionales, el DBA puede considerar
trabajar con el modelador de datos para des-normalizar la parte afectada de la
base de datos. Haga esto solo después de que se hayan intentado otras medidas,
como la creación de vistas e índices y la reescritura de código SQL; y solo
después de una cuidadosa consideración de las posibles consecuencias, como la
pérdida de integridad de los datos y el aumento de la complejidad de las consultas
de SQL en comparación con las tablas des-normalizadas. Esta advertencia se
aplica sólo a las bases de datos OLTP. Para las bases de datos analíticas y de
informes de solo lectura, la normalización para el rendimiento y la facilidad de
acceso es la regla y no la excepción, y no representa una amenaza o riesgo.

6.2.1.7 Plan para la retención de datos

Una parte importante del diseño físico de la base de datos es el plan de retención
de datos. Discuta la retención de datos con los propietarios en el momento del
diseño y llegue a un acuerdo sobre cómo tratar los datos durante su vida útil. Es
incorrecto suponer que todos los datos residirán para siempre en el
almacenamiento primario. Los datos que no se necesitan activamente para
respaldar los procesos de la aplicación deben archivarse en algún tipo de
almacenamiento secundario en un disco o cinta menos costoso, o en un CD / DVD
jukebox, tal vez en un servidor separado. Purgue los datos que sean obsoletos e
innecesarios, incluso con fines reglamentarios. Algunos datos pueden convertirse
en una responsabilidad si se mantienen más tiempo del necesario. Recuerde que
uno de los objetivos principales de la administración de datos es que el costo de
mantener los datos no debe exceder su valor para la organización.

6.2.1.8 Archivar, retener y purgar datos

Los DBA trabajarán con los desarrolladores de aplicaciones y otro personal de
operaciones, incluidos los administradores de servidores y de almacenamiento,
para implementar el plan de retención de datos aprobado. Esta puede requerir la
creación de un área de almacenamiento secundario, la construcción de un
servidor de base de datos secundario, la replicación de datos menos necesarios
en una base de datos separada, la partición de las tablas de base de datos
existentes, la organización de copias de seguridad en cinta o disco, y la creación
de trabajos de base de datos que borran periódicamente los datos innecesarios.

6.2.1.9 Soporte de bases de datos especializadas

No asuma que un solo tipo de arquitectura de base de datos o DBMS funciona

para cada necesidad. Algunas situaciones especializadas requieren tipos
especializados de bases de datos. Gestione estas bases de datos especializadas
de forma diferente a las bases de datos relacionales tradicionales. Por ejemplo, la
mayoría de las aplicaciones de Diseño y Fabricación Asistidas por Computadora
(CAD / CAM) requerirán una base de datos de Objetos, al igual que la mayoría de
las aplicaciones incrustadas en tiempo real. Las aplicaciones geoespaciales, como
MapQuest, hacen uso de bases de datos geoespaciales especializadas. Otras
aplicaciones, como las aplicaciones de carrito de compras que se encuentran en la
mayoría de los sitios web minoristas en línea, utilizan las bases de datos XML para
almacenar inicialmente los datos de los pedidos de los clientes. Estos datos luego
se copian en una o más bases de datos o almacenes de datos OLTP tradicionales.
Además, muchas aplicaciones de proveedores estándar pueden usar sus propias
bases de datos propietarias. Como mínimo, sus esquemas serán propietarios y en
su mayoría ocultos, incluso si se ubican por encima de los DBMS relacionales
tradicionales. La administración de bases de datos utilizadas solo para soportar
una aplicación en particular no debe presentar ninguna gran dificultad. El DBA
será mayormente responsable de garantizar copias de seguridad periódicas de las
bases de datos y realizar pruebas de recuperación. Sin embargo, si los datos de
estas bases de datos deben combinarse con otros datos existentes, por ejemplo,
en una o más bases de datos relacionales, puede presentar un desafío de
integración de datos. Estas consideraciones deben discutirse y resolverse cada
vez que se propongan o se introduzcan dichas bases de datos en la organización.

6.2.2 Gestión de la tecnología de datos

Los DBA y otros profesionales de datos gestionan la tecnología relacionada con su

campo. La administración de la tecnología de datos debe seguir los mismos
principios y estándares para administrar cualquier tecnología.
El modelo de referencia líder para la gestión de la tecnología es la Biblioteca de
infraestructura de tecnología de la información (ITIL), un modelo de proceso de
gestión de la tecnología desarrollado en el Reino Unido. Los principios de ITIL se
aplican a la gestión de la tecnología de datos. Para obtener más información,
consulte el sitio web de ITIL, http://www.itil-officialsite.com.

6.2.2.1 Comprender los requisitos de la tecnología de datos

Es importante comprender no solo cómo funciona la tecnología, sino también

cómo puede proporcionar valor en el contexto de un negocio en particular. El DBA,
junto con el resto de la organización de servicios de datos, debe trabajar en
estrecha colaboración con los usuarios y administradores de negocios para
comprender los datos y las necesidades de información del negocio. Esto les
permitirá sugerir las mejores aplicaciones posibles de tecnología para resolver
problemas de negocios y aprovechar nuevas oportunidades de negocios.

Los profesionales de datos deben comprender primero los requisitos de una

tecnología de datos antes de determinar qué solución técnica elegir para una
situación particular. Estas preguntas son un punto de partida para comprender la
idoneidad de una tecnología de datos y no son exhaustivas.

1. ¿Qué problema tiene que resolver esta tecnología de datos?

2. ¿Qué hace esta tecnología de datos que no está disponible en otras tecnologías
de datos?

3. ¿Qué hace esta tecnología de datos que no está disponible en otras tecnologías
de datos?

4. ¿Existen requisitos de hardware específicos para esta tecnología de datos?

5. ¿Existen requisitos específicos del sistema operativo para esta tecnología de

datos?

6. ¿Se requieren requisitos de software específicos o aplicaciones adicionales

para que esta tecnología de datos funcione como se anuncia?

7. ¿Existen requisitos de almacenamiento específicos para esta tecnología de

datos?

8. ¿Existen requisitos específicos de red o conectividad para esta tecnología de

datos?
9. ¿Esta tecnología de datos incluye funcionalidad de seguridad de datos? Si no
es así, ¿con qué otras herramientas funciona esta tecnología que proporciona
funcionalidad de seguridad de datos?

10. ¿Se requieren habilidades específicas para poder soportar esta tecnología de
datos? ¿Tenemos esas habilidades en casa o debemos adquirirlas?

6.2.2.2 Definir la arquitectura de tecnología de datos

La tecnología de datos forma parte de la arquitectura tecnológica general de la

empresa, pero a menudo también se la considera parte de su arquitectura de
datos.

La arquitectura de la tecnología de datos responde a tres preguntas básicas:

1. ¿Qué tecnologías son estándar (que son requeridas, preferidas o aceptables)?

2. ¿Qué tecnologías se aplican a qué propósitos y circunstancias?

3. En un entorno distribuido, ¿qué tecnologías existen dónde y cómo se mueven

los datos de un nodo a otro?

Las tecnologías de datos que se incluirán en la arquitectura tecnológica incluyen:

 Software de sistemas de gestión de bases de datos (DBMS).

 Utilidades de gestión de bases de datos relacionadas.

 Software de modelado de datos y gestión de modelos.

 Software de inteligencia de negocios para informes y análisis.

 Extraer-transformar-carga (ETL) y otras herramientas de integración de datos.

 Análisis de calidad de datos y herramientas de limpieza de datos.

 Software de gestión de metadatos, incluidos los repositorios de metadatos.

Los componentes de la arquitectura tecnológica a veces se denominan "ladrillos".

Varias categorías o vistas que representan facetas de ladrillos de tecnología de
datos son:

 Actual: Productos actualmente soportados y usados.

 Período de implementación: productos que se implementarán para su uso en los

próximos 1 o 2 años.
 Período estratégico: productos que se espera estén disponibles para su uso en
los próximos 2 años o más.

 Jubilación: productos que la organización ha retirado o pretende retirar este año.

 Preferido: productos preferidos para el uso de la mayoría de las aplicaciones.

 Contención: Productos limitados a usar por ciertas aplicaciones.

 Emergente: productos que se están investigando y probando para un posible

despliegue futuro.

La hoja de ruta tecnológica para la organización consiste en estos ladrillos

revisados, aprobados y publicados, y esto ayuda a gobernar las decisiones de
tecnología futuras. Es importante entender varias cosas acerca de la tecnología:

 Nunca es gratis. Incluso la tecnología de código abierto requiere cuidado y

alimentación.

 Siempre debe considerarse como el medio para un fin, en lugar del fin en sí
mismo.

 Lo más importante es que comprar la misma tecnología que todos los demás
están usando y usarla de la misma manera, no crea valor comercial ni ventaja
competitiva para la empresa.

Después de las discusiones necesarias con los usuarios y gerentes de negocios,

el grupo de servicios de datos puede resumir los objetivos de tecnología de datos
para el negocio en forma de una hoja de ruta estratégica que puede usarse para
informar y dirigir la investigación de tecnología de datos y el trabajo del proyecto.

6.2.2.3 Evaluar la tecnología de datos

La selección de la tecnología apropiada relacionada con los datos, particularmente

la tecnología apropiada de administración de bases de datos, es una
responsabilidad importante de la administración de datos. La administración
selecciona la tecnología de datos para satisfacer las necesidades del negocio,
incluido el costo total, la confiabilidad y la integración.

La selección de tecnología de datos implica administradores de datos comerciales,

administradores de bases de datos, arquitectos de datos, analistas de datos, otros
profesionales de la gestión de datos y otros profesionales de TI. Las tecnologías
de datos que se investigarán y evaluarán incluyen:

 Software de sistemas de gestión de bases de datos (DBMS).

 Utilidades de base de datos, como herramientas de copia de seguridad y
recuperación, y monitores de rendimiento.

 Software de modelado de datos y gestión de modelos.

 Herramientas de administración de bases de datos, como editores, generadores

de esquemas y generadores de objetos de bases de datos.

 Software de inteligencia de negocios para informes y análisis.

 Extract-transfer-load (ETL) y otras herramientas de integración de datos.

 Análisis de calidad de datos y herramientas de limpieza de datos.

 Tecnología de virtualización de datos.

 Software de gestión de metadatos, incluidos los repositorios de metadatos.

Además, los profesionales de datos pueden tener requisitos únicos para las
herramientas utilizadas en otros campos, que incluyen:

 Herramientas de gestión de cambios (biblioteca de código fuente y

configuración).

 Herramientas de gestión de problemas y problemas.

 Herramientas de gestión de pruebas.

 Generadores de datos de prueba.

Tome decisiones de selección utilizando un proceso de evaluación de tecnología

estándar y aplicando los conceptos de análisis de decisión definidos por Kepner y
Tregoe en The Rational Manager. Enumere las alternativas y compárelas con un
conjunto definido de criterios de decisión ponderados, incluidos los requisitos de
funciones y los objetivos funcionales.

El método básico incluye los siguientes pasos:

1. Comprender las necesidades del usuario, los objetivos y los requisitos

relacionados.

2. Comprender la tecnología en general.

3. Identificar alternativas tecnológicas disponibles.

4. Identificar las características requeridas.

5. Pese la importancia de cada característica.

6. Comprender cada alternativa tecnológica.

7. Evaluar y calificar la capacidad de cada alternativa tecnológica para cumplir con

los requisitos.

8. Calcule los puntajes totales y clasifique las alternativas tecnológicas por

puntaje.

9. Evaluar los resultados, incluyendo los criterios ponderados.

10. Presente el caso para seleccionar la alternativa de mayor rango.

La selección de software DBMS estratégico es particularmente importante. El

software DBMS tiene un gran impacto en la integración de datos, el rendimiento de
las aplicaciones y la productividad de DBA. Algunos de los factores a considerar al
seleccionar el software DBMS incluyen:

 Arquitectura y complejidad del producto.

 Perfil de la aplicación, como procesamiento de transacciones, inteligencia

empresarial y perfiles personales.

 El apetito organizacional por el riesgo técnico.

 Soporte de plataforma hardware y sistema operativo.

 Disponibilidad de herramientas de soporte de software.

 Puntos de referencia de rendimiento.

 Escalabilidad.

 Requisitos de software, memoria y almacenamiento.

 Oferta disponible de profesionales técnicos capacitados.

 Costo de propiedad, como licencias, mantenimiento y recursos informáticos.

 Reputación del vendedor.

 Política de soporte al proveedor y calendario de lanzamiento.

 Referencias de clientes.
El DBA tendrá que ayudar en la evaluación de alternativas tecnológicas. Una serie
de factores entran en juego aquí:

 La disponibilidad, estabilidad, madurez y costo de los productos actuales.

 La idoneidad de un producto determinado para satisfacer la necesidad /

problema actual del negocio.

 La extensibilidad de un producto dado para satisfacer otras necesidades

comerciales.

 El "conjunto" del producto con la hoja de ruta de la tecnología y la arquitectura

de la organización (consulte la sección 4.2.2.4).

 El "producto" del producto con otros productos y tecnología utilizados por la

organización.

 La reputación, la estabilidad y la longevidad esperada del proveedor: ¿es este

un proveedor con el que la empresa querrá y podrá hacer negocios durante un
período prolongado?

 El grado de soporte esperado del proveedor: ¿Las actualizaciones estarán

disponibles con frecuencia y con un costo mínimo? ¿La ayuda del proveedor
estará disponible cuando sea necesario?

El DBA deberá probar cuidadosamente cada producto candidato para determinar

sus fortalezas y debilidades, la facilidad de implementación y uso, la aplicabilidad
a las necesidades y problemas comerciales actuales y futuros, y si está a la altura
de las exageraciones del proveedor.

6.2.2.4 Instalar y administrar tecnología de datos

Los DBA se enfrentan al trabajo de implementar productos de nueva tecnología en

entornos de desarrollo / prueba, control de calidad / certificación y producción.
Deberán crear y documentar procesos y procedimientos para administrar el
producto con la menor cantidad de esfuerzo y gastos. Recuerde que el costo del
producto, incluida la administración, las licencias y el soporte, no debe exceder el
valor del producto para la empresa. Recuerde también que la compra de nuevos
productos y la implementación de nuevas tecnologías probablemente no vayan
acompañadas de un aumento de personal, por lo que la tecnología deberá ser, en
la medida de lo posible, auto-monitoreada y auto-administrada.

Además, recuerde que el costo y la complejidad de implementar una nueva

tecnología generalmente se subestiman, y las características y los beneficios
generalmente se sobrestiman. Es una buena idea comenzar con proyectos piloto
pequeños e implementaciones de prueba de concepto (POC), para obtener una
buena idea de los costos y beneficios reales antes de continuar con una
implementación de producción completa.

6.2.2.5 Licencias de Inventario y Tecnología de Datos de Rastreo

Las organizaciones deben cumplir con todos los acuerdos de licencia y los
requisitos reglamentarios. Realice un seguimiento cuidadoso y realice auditorías
anuales de la licencia del software y los costos de soporte anual, así como los
acuerdos de arrendamiento del servidor y otros costos fijos. El incumplimiento de
los acuerdos de licencia conlleva serios riesgos financieros y legales para una
organización.

Estos datos también pueden determinar el costo total de propiedad (TCO) para
cada tipo de tecnología y producto tecnológico. Evalúe periódicamente las
tecnologías y los productos que están quedando obsoletos, no son compatibles,
menos útiles o demasiado caros.

6.2.2.6 Uso de la tecnología de datos de soporte y problemas

Cuando una necesidad comercial requiera nueva tecnología, los DBA trabajarán
con usuarios empresariales y desarrolladores de aplicaciones para garantizar el
uso más efectivo de la tecnología, para explorar nuevas aplicaciones de la
tecnología y para abordar cualquier problema o problema que surja de su uso. Los
DBA y otros profesionales de la información sirven como soporte técnico de Nivel
2, trabajando con los escritorios de ayuda y el soporte del proveedor de tecnología
para comprender, analizar y resolver los problemas de los usuarios.

La clave para la comprensión y el uso efectivo de cualquier tecnología es la

capacitación. Las organizaciones deben asegurarse de contar con un plan de
capacitación y un presupuesto efectivos para todos los involucrados en la
implementación, el soporte y el uso de la tecnología de datos y bases de datos.
Los planes de capacitación deben incluir niveles adecuados de capacitación
cruzada para respaldar mejor el desarrollo de aplicaciones, especialmente el
desarrollo ágil. Los DBA deben tener, y aprovechar la oportunidad de aprender,
habilidades de desarrollo de aplicaciones como modelado de clases, casos de uso
Análisis, y acceso a datos de aplicaciones. ¡Los desarrolladores deben
aprender algunas habilidades de base de datos, especialmente la
codificación SQL!

6.3 Resumen

A continuación se resumen los principios rectores para implementar la

administración de operaciones de datos en una organización, una tabla de
resumen de los roles para cada actividad de administración de operaciones de
datos y los problemas culturales y de organización que pueden surgir durante la
administración de operaciones de datos.

6.3.1 Principios Rectores

En su libro Administración de base de datos, Craig Mullins ofrece a los

administradores de bases de datos las siguientes reglas básicas para la
administración de operaciones de datos:

1. Anote todo.

2. Mantener todo.

3. Siempre que sea posible, automatice un procedimiento.

4 Enfóquese en comprender el propósito de cada tarea, administre el alcance,

simplifique, haga una cosa a la vez.

5. Medir dos veces, cortar una vez.

6. No te asustes; Reacciona con calma y racionalidad, porque el pánico causa

más errores.

7. Entender el negocio, no solo la tecnología.

8. Trabajen juntos para colaborar, ser accesibles, auditar el trabajo de cada uno,
compartir sus conocimientos.

9. Usa todos los recursos a tu disposición.

10. Mantente al día.

6.3.2 Resumen del proceso

El resumen del proceso para la función de gestión de operaciones de datos se

muestra en la Tabla 6.1. Los entregables, roles responsables, roles de aprobación
y roles contribuyentes se muestran para cada actividad en la función de
administración de operaciones de datos. La Tabla también se muestra en el
Apéndice A9.
6.3.3 Temas organizacionales y culturales

P1: ¿Cuáles son los obstáculos organizativos y culturales comunes a la

administración de bases de datos?

A1: Los DBA a menudo no promueven efectivamente el valor de su trabajo para la

organización. Deben reconocer las preocupaciones legítimas de los propietarios
de datos y los consumidores de datos, equilibrar las necesidades de datos a corto
y largo plazo, educar a otros en la organización sobre la importancia de las buenas
prácticas de gestión de datos y optimizar las prácticas de desarrollo de datos para
garantizar el máximo beneficio para el Organización y mínimo impacto en los
consumidores de datos. Al considerar el trabajo de datos como un conjunto
abstracto de principios y prácticas, y sin tener en cuenta los elementos humanos
involucrados, los DBA corren el riesgo de propagar una mentalidad de "frente a
ellos" y ser considerados como dogmáticos, poco prácticos, inútiles y
obstruccionistas.

Muchas desconexiones, en su mayoría choques en marcos de referencia,

contribuyen a este problema. Las organizaciones generalmente consideran la
tecnología de la información en términos de aplicaciones específicas, no de datos,
y generalmente ven datos desde un punto de vista centrado en la aplicación. El
valor a largo plazo para las organizaciones de datos seguros, reutilizables y de
alta calidad, como los datos como un recurso corporativo, no es tan fácil de
reconocer o apreciar. El desarrollo de aplicaciones a menudo ve la administración
de datos como un impedimento para el desarrollo de aplicaciones, como algo que
hace que los proyectos de desarrollo tomen más tiempo y cuesten más sin
proporcionar un beneficio adicional. Los DBA han tardado en adaptarse a los
cambios en la tecnología, como XML, objetos y arquitecturas orientadas a
servicios, y a nuevos métodos de desarrollo de aplicaciones, como Agile
Development, XP y Scrum. Los desarrolladores, por otro lado, a menudo no
reconocen cómo las buenas prácticas de administración de datos pueden
ayudarlos a lograr sus objetivos a largo plazo de reutilización de objetos y
aplicaciones, y la verdadera arquitectura de aplicaciones orientada a servicios.
Hay varias cosas que los DBA y otros profesionales de la gestión de datos pueden
hacer para ayudar a superar estos obstáculos organizativos y culturales, y
promover un enfoque más útil y colaborativo para satisfacer las necesidades de
información y datos de la organización:

 Automatice los procesos de desarrollo de la base de datos, desarrollando

herramientas y procesos que acorten cada ciclo de desarrollo, reduzcan los
errores y las modificaciones, y minimicen el impacto en el equipo de desarrollo. De
esta manera, los DBA pueden adaptarse a enfoques más iterativos (ágiles) para el
desarrollo de aplicaciones.

 Desarrollar y promover el uso de objetos de datos abstraídos y reutilizables que

evitan que las aplicaciones se acoplen estrechamente a los esquemas de base de
datos; el llamado desajuste de impedancia relacional de objeto. Existen varios
mecanismos para hacer esto, incluyendo vistas de bases de datos, activadores,
funciones y procedimientos almacenados, objetos de datos de aplicaciones y
capas de acceso a datos, XML y XSLT, conjuntos de datos tipificados de ADO.NET
y servicios web. El DBA debe estar familiarizado con todos los medios disponibles
de virtualización de datos y ser capaz de recomendar el mejor enfoque para
cualquier situación. El objetivo final es hacer que el uso de la base de datos sea lo
más rápido, fácil e indoloro posible.
 Promover los estándares de la base de datos y las mejores prácticas como
requisitos, pero ser lo suficientemente flexible como para desviarse de ellos si se
dan razones aceptables para estas desviaciones. Los estándares de la base de
datos nunca deben ser una amenaza para el éxito de un proyecto.

 Vincular los estándares de la base de datos a varios niveles de soporte en el

SLA. Por ejemplo, el SLA puede reflejar métodos recomendados por el DBA y
aceptados por el desarrollador para garantizar la integridad de los datos y la
seguridad de los mismos. El SLA debe reflejar la transferencia de responsabilidad
de los DBA al equipo de desarrollo si el equipo de desarrollo codificará sus propios
procedimientos de actualización de la base de datos o la capa de acceso a datos.
Esto evita un enfoque de "todo o nada" a los estándares.

 Establezca las necesidades del proyecto y los requisitos de soporte por

adelantado, para reducir los malentendidos sobre lo que el equipo del proyecto
quiere y no quiere del grupo de datos. Asegúrese de que todos tengan claro qué
trabajo harán y no harán los DBA, la forma en que se realizará el trabajo, los
estándares que se seguirá o no se seguirá el cronograma del proyecto, la cantidad
de horas y recursos involucrados y el nivel de soporte que se requerirá durante el
desarrollo y después de la implementación. Esto ayudará a evitar sorpresas
desagradables a mitad del proceso de desarrollo.

 Comunicarse constantemente con el equipo del proyecto, tanto durante el

desarrollo como después de la implementación, para detectar y resolver cualquier
problema lo antes posible. Esto incluye la revisión del código de acceso a los
datos, los procedimientos almacenados, las vistas y las funciones de la base de
datos escritas por el equipo de desarrollo. Esto también ayudará a descubrir
cualquier problema o malentendido sobre el diseño de la base de datos.

 Manténgase enfocado en el negocio. El objetivo es cumplir con los requisitos

comerciales y obtener el valor comercial máximo del proyecto. No ayuda a ganar
las batallas y perder la guerra.

 Adopte una actitud de "puede hacer" y sea lo más útil posible. Si siempre le
dices a la gente "no", no te sorprendas cuando elijan ignorarte y encuentren otro
camino. Reconozca que las personas deben hacer lo que sea necesario y, si no
los ayuda a tener éxito, pueden ayudarlo a fallar.

 Acepte todas las derrotas y fallas encontradas durante un proyecto como

"tiempos aprendidos", y aplíquelo a proyectos futuros. No tienes que ganar todas
las batallas. Si surgen problemas por haber hecho las cosas mal, siempre puede
señalarlos más tarde como razones para hacer las cosas bien en el futuro.
 Comunicarse con las personas en su nivel y en sus términos. Es mejor hablar
con la gente de negocios en términos de necesidades de negocio y ROI, y con los
desarrolladores en términos de orientación a objetos, acoplamiento suelto y
facilidad de desarrollo.

 Concéntrese en resolver los problemas de otras personas, no en los suyos.

Para resumir, debemos entender quiénes son nuestras partes interesadas y cuáles
son sus necesidades y preocupaciones. Necesitamos desarrollar un conjunto de
estándares claros, concisos, prácticos y centrados en el negocio para hacer el
mejor trabajo posible de la mejor manera posible. Además, debemos enseñar e
implementar esos estándares de una manera que proporcione el máximo valor a
nuestros grupos de interés y se gane su respeto como facilitadores, contribuyentes
y proveedores de soluciones.

P2: ¿Cuántos DBA necesita una organización?

A2: La respuesta a esta pregunta varía según la organización. No hay una regla
general de personal. Sin embargo, puede haber un costo de negocio significativo
para la falta de personal. Un personal de DBA con exceso de trabajo puede
cometer errores que cuestan mucho más en tiempo de inactividad y problemas
operacionales de los que podrían ahorrarse en la reducción de los costos
salariales al minimizar el personal de DBA. Se deben considerar muchos factores
al determinar el número óptimo de DBA para la organización. Estos factores
incluyen:

 El número de bases de datos.

 El tamaño y complejidad de las bases de datos.

 El número de plataformas y entornos DBMS.

 El número de usuarios.

 El número de aplicaciones soportadas.

 El tipo y complejidad de las aplicaciones.

 Requisitos de disponibilidad.

 El riesgo de negocio y el impacto del tiempo de inactividad.

 Requisitos de desempeño.

 Acuerdos de nivel de servicio y expectativas de clientes relacionadas.

 El número de solicitudes de cambio de base de datos realizadas.

 Experiencia del personal de DBA.

 Experiencia de desarrollador de software con bases de datos.

 Experiencia del usuario final.

 La madurez de las herramientas DBA.

 El alcance de las responsabilidades de DBA para la lógica de la base de datos

(procedimientos almacenados, activadores, funciones definidas por el usuario),
integración, interfaces de acceso y productos de información.

P3: ¿Qué es una aplicación DBA?

A3: El DBA de una aplicación es responsable de una o más bases de datos en

todos los entornos (desarrollo / prueba, control de calidad y producción), a
diferencia de la administración de sistemas de bases de datos para cualquiera de
estos entornos. A veces, los DBA de aplicaciones informan a las unidades
organizativas responsables del desarrollo y mantenimiento de las aplicaciones
compatibles con sus bases de datos. Hay ventajas y desventajas para la dotación
de personal de DBA de aplicaciones. Los DBA de aplicaciones se ven como
miembros integrales de un equipo de soporte de aplicaciones y, al centrarse en
una base de datos específica, pueden brindar un mejor servicio a los
desarrolladores de aplicaciones. Sin embargo, los DBA de aplicaciones pueden
aislarse fácilmente y perder de vista las necesidades de datos generales de la
organización y las prácticas comunes de DBA. La colaboración constante entre los
DBA y los analistas de datos, modeladores y arquitectos es necesaria para evitar
el aislamiento y la desconexión de los DBA.

P4: ¿Qué es un DBA procesal?

A4: Un DBA de procedimiento se especializa en el desarrollo y soporte de la lógica

de procedimiento controlada y ejecutada por el DBMS: procedimientos
almacenados, activadores y funciones definidas por el usuario (UDF). El DBA de
procedimiento garantiza que esta lógica de procedimiento se planifica,
implementa, prueba y comparte (reutiliza). Los DBA procesales lideran la revisión
y administración de objetos de bases de datos de procedimientos.
6.4 Lectura recomendada

Las referencias enumeradas a continuación proporcionan lecturas adicionales que

apoyan el material presentado en el Capítulo 6. Estas lecturas recomendadas
también se incluyen en la Bibliografía al final de la Guía.

Dunham, Jeff. Manual de ajuste de rendimiento de base de datos. McGraw-Hill,

1998. ISBN 0-07-018244-2.

Hackathorn, Richard D. Enterprise Database Connectivity. Wiley Professional

Computing, 1993. ISBN 0-4761-57802-9. 352 páginas.

Hoffer, Jeffrey, Mary Prescott y Fred McFadden. Gestión moderna de bases de

datos, 7ª edición. Prentice Hall, 2004. ISBN 0-131-45320-3. 736 páginas.

Kepner, Charles H. y Benjamin B. Tregoe. El nuevo gerente racional. Princeton

Research Press, 1981. 224 páginas.

Kroenke, D. M. Procesamiento de bases de datos: Fundamentos, diseño e

implementación, 10ª edición. Pearson Prentice Hall, 2005. ISBN 0-131-67626-3.
696 páginas.

Martin, James. Libro de Ingeniería de la Información II: Planificación y Análisis.

Prentice-Hall, Inc., 1990. Englewoood Cliffs, Nueva Jersey.

Mattison, Rob. Entendiendo los sistemas de gestión de bases de datos, 2ª edición.

McGraw-Hill, 1998. ISBN 0-07-049999-3. 665 páginas.

Mullins, Craig S. Administración de bases de datos: la guía completa de prácticas

y procedimientos. Addison-Wesley, 2002. ISBN 0-201-74129-6. 736 páginas.

Parsaye, Kamran y Mark Chignell. Herramientas y aplicaciones de base de datos

inteligentes: acceso a hiperinformación, calidad de datos, visualización,
descubrimiento automático. John Wiley & Sons, 1993. ISBN 0-471-57066-4. 560
páginas.

Pascal, Fabian, problemas prácticos en la gestión de bases de datos: una

referencia para el practicante del pensamiento. Addison-Wesley, 2000. ISBN 0-
201-48555-9. 288 páginas.

Piedad, Floyd, y Michael Hawkins. Alta disponibilidad: Diseño, Técnicas y

Procesos. Prentice Hall, 2001. ISBN 0-13-096288-0.
Rob, Peter y Carlos Coronel. Sistemas de bases de datos: diseño, implementación
y gestión, 7ª edición. Curso de Tecnología, 2006. ISBN 1-418-83593-5. 688
páginas.

7 GESTIÓN DE SEGURIDAD DE DATOS

Data Security Management es la quinta función de administración de datos en el

marco de administración de datos que se muestra en las Figuras 1.3 y 1.4. Es la
cuarta función de administración de datos que interactúa con y está influenciada
por la función de gobernabilidad de datos. El Capítulo 7 define la función de
administración de seguridad de datos y explica los conceptos y actividades
involucrados en la administración de operaciones de datos.

7.1 Introducción

Data Security Management es la planificación, desarrollo y ejecución de políticas y

procedimientos de seguridad para proporcionar la autenticación, autorización,
acceso y auditoría adecuados de los datos y activos de información. Las políticas
y procedimientos de seguridad de datos efectivos aseguran que las personas
adecuadas puedan usar y actualizar los datos de la manera correcta, y que todo
acceso y actualización inapropiados estén restringidos. Entender y cumplir con los
intereses y necesidades de privacidad y confidencialidad de todas las partes
interesadas es lo mejor para cualquier organización. Todas las relaciones con los
clientes, proveedores y constituyentes confían y dependen del uso responsable de
los datos. El tiempo invertido para comprender mejor los intereses y
preocupaciones de las partes interesadas generalmente demuestra ser una
inversión inteligente.

Una función eficaz de gestión de la seguridad de los datos establece mecanismos

de gobernanza juiciosos que son lo suficientemente fáciles de cumplir de forma
operativa diaria por todos los interesados. El contexto para Data Security
Management se muestra en la Figura 7.1.

7.2 Conceptos y actividades

El objetivo final de la gestión de la seguridad de datos es proteger los activos de

información en línea con las regulaciones de privacidad y confidencialidad y los
requisitos comerciales. Estos requisitos provienen de varias fuentes diferentes,
muy importantes:

 Preocupaciones de las partes interesadas: las organizaciones deben reconocer

las necesidades de privacidad y confidencialidad de sus partes interesadas,
incluidos clientes, pacientes, estudiantes, ciudadanos, proveedores o socios
comerciales. Las partes interesadas son los dueños finales de los datos sobre
ellos, y todos los miembros de la organización deben ser un fideicomisario
responsable de estos datos.

 Regulaciones gubernamentales: las regulaciones gubernamentales protegen

algunos de los intereses de seguridad de las partes interesadas. Algunas
regulaciones restringen el acceso a la información, mientras que otras garantizan
la apertura, la transparencia y la responsabilidad.

 Problemas comerciales propietarios: cada organización tiene sus propios datos

propietarios para proteger; Asegurar la ventaja competitiva proporcionada por la
propiedad intelectual y el conocimiento íntimo de las necesidades del cliente y las
relaciones con los socios comerciales es una piedra angular en cualquier plan de
negocios.

 Necesidades de acceso legítimas: los implementadores de seguridad de datos

también deben comprender las necesidades legítimas de acceso a datos.
Estrategia de negocio, reglas y procesos requieren individuos en ciertos roles para
asumir la responsabilidad de acceso y mantenimiento de ciertos datos.

5. Gestión de seguridad de datos

Definición: Planificación, desarrollo y ejecución de políticas y procedimientos de
seguridad para proporcionar

Autenticación adecuada, autorización, acceso y auditoría de datos e información.

Metas:

1. Habilite el acceso apropiado, y evite el acceso inadecuado, y cambie a los

activos de datos.

2. Cumplir con los requisitos reglamentarios de privacidad y confidencialidad.

3. Asegurar que se cumplan las necesidades de privacidad y confidencialidad de

todas las partes interesadas.

Entradas:

• Objetivos de negocio

• Estrategia de negocios

• Reglas del negocio

• Procesos de negocio

• Estrategia de datos

• Problemas de privacidad de datos

• Políticas de TI relacionadas

y normas

Entregables primarios:

• Políticas de seguridad de datos

• Privacidad de datos y

Estándares de confidencialidad

• Perfiles de usuario, contraseñas y

Membresías

• Permisos de seguridad de datos

• Controles de seguridad de datos

• Vistas de acceso a datos

• Clasificaciones de documentos

• Autenticación y acceso

Historia

• Auditorías de seguridad de datos

Proveedores:

• Administradores de datos

• Comité de Dirección de TI

• Administración de datos

Consejo

• Gobierno

• Clientes

Consumidores:

• Productores de datos

• Trabajadores del conocimiento

• Gerentes

• ejecutivos

• Clientes

• Profesionales de datos

Participantes:

• Administradores de datos

• Administradores de seguridad de datos

• Administradores de bases de datos

• Analistas de BI
• Arquitectos de datos

• Líder de DM

• CIO / CTO

• Analistas de la mesa de ayuda

Herramientas:

• Sistema de administración de base de datos

• Herramientas de inteligencia de negocios

• Marcos de aplicación

• Tecnologías de gestión de identidad

• Sistemas de control de cambio

Ocupaciones:

1. Entender las necesidades de seguridad de datos y reglamentario

Requisitos (P)

2. Definir la política de seguridad de datos (P)

3. Definir estándares de seguridad de datos (P)

4. Definir los controles y procedimientos de seguridad de datos (D)

5. Administrar usuarios, contraseñas y membresía de grupo (C)

6. Gestionar vistas de acceso a datos y permisos (C)

7. Supervisar la autenticación del usuario y el comportamiento de acceso (C)

8. Clasificar la confidencialidad de la información (C)

9. Auditoría de seguridad de datos (C)

Actividades: (P) - Planificación (C) - Control (D) - Desarrollo (O) – Operacional

Los requisitos de seguridad de datos y los procedimientos para cumplir estos
requisitos pueden ser

categorizados en cuatro grupos básicos (los cuatro A):

 Autenticación: Valide que los usuarios son quienes dicen ser.

 Autorización: identificar a las personas adecuadas y otorgarles los privilegios

adecuados

a puntos de vista específicos, apropiados de los datos.

 Acceso: habilite a estos individuos y sus privilegios de manera oportuna.

 Auditoría: revise las acciones de seguridad y la actividad del usuario para

garantizar el cumplimiento con

Normativa y conformidad con la política y normas.

7.2.1 Comprender las necesidades de seguridad de los datos y los requisitos

reglamentarios

Es importante distinguir entre las reglas y procedimientos comerciales y las reglas

Impuestos por productos de software de aplicación. Mientras que los sistemas de

aplicación sirven como vehículos.

Para hacer cumplir las reglas y procedimientos comerciales, es común que estos
sistemas tengan su

un conjunto único de requisitos de seguridad de datos por encima de los

requeridos para

Procesos de negocios. Estos requisitos únicos son cada vez más comunes con

Sistemas empaquetados y disponibles en el mercado.

7.2.1.1 Requisitos del negocio

La implementación de la seguridad de datos dentro de una empresa comienza con

una comprensión profunda de los requisitos comerciales. La misión comercial y la
estrategia que se filtran a través de la estrategia de datos deben ser el factor guía
en la planificación de la política de seguridad de datos. Aborde los objetivos a
corto y largo plazo para lograr una función de seguridad de datos equilibrada y
efectiva. Las necesidades comerciales de una empresa definen el grado de rigidez
requerido para la seguridad de los datos. El tamaño de la empresa y la industria a
la que pertenece influye enormemente en este grado. Por ejemplo, una empresa
financiera o de valores en los Estados Unidos está altamente regulada y,
independientemente de su tamaño, debe mantener estrictos estándares de
seguridad de los datos. Por otro lado, una empresa minorista de pequeña escala
no puede optar por tener una función de administración de seguridad de datos
extendida en comparación con un minorista de gran tamaño, aunque ambos
puedan estar involucrados en actividades comerciales centrales similares. Las
reglas y procesos de negocio definen los puntos de contacto de seguridad. Cada
evento en el flujo de trabajo empresarial tiene sus propios requisitos de seguridad.
Las matrices de relación de datos a proceso y de datos a rol son herramientas
útiles para mapear estas necesidades y guiar la definición de grupos de roles de
seguridad de datos, parámetros y permisos. Además, los administradores de
seguridad de datos también deben evaluar los requisitos administrativos de las
herramientas de software, los paquetes de aplicaciones y los sistemas de TI
utilizados por la empresa. Identifique los requisitos detallados de seguridad de la
aplicación en la fase de análisis de cada proyecto de desarrollo de sistemas.

7.2.1.2 Requisitos reglamentarios

El entorno global y rápidamente cambiante de hoy requiere que las organizaciones

cumplan con un conjunto creciente de regulaciones. Los problemas éticos y
legales que enfrentan las organizaciones en la era de la información están
llevando a los gobiernos a establecer nuevas leyes y estándares. Los requisitos de
varias regulaciones más recientes, como la Ley Sarbanes-Oxley de 2002, la Ley
Canadiense 198 y la Ley CLERP de Australia, han impuesto estrictos controles de
seguridad en la gestión de la información. El Acuerdo de Basilea II de la Unión
Europea impone controles de información para todas las instituciones financieras
que hacen negocios en sus países relacionados. En la sección 7.5.1 aparece una
lista de las principales normas de privacidad y seguridad.

7.2.2 Definir la política de seguridad de datos

La definición de la política de seguridad de datos basada en los requisitos de

seguridad de datos es un esfuerzo de colaboración que involucra a
administradores de seguridad de TI, administradores de datos, equipos de
auditoría interna y externa y el departamento legal. Los profesionales de la
seguridad de datos a veces adoptan un enfoque sólido para la seguridad, y en el
proceso pueden causar impedimentos inconvenientes para los consumidores de
datos. Desarrolle políticas de seguridad de datos para que el cumplimiento sea
más fácil que el incumplimiento. El consejo de gobierno de datos debe revisar y
aprobar la política de seguridad de datos de alto nivel.
La estrategia y los estándares de TI de la empresa generalmente dictan políticas
de alto nivel para el acceso a los activos de datos empresariales. Es común tener
la Política de Seguridad de TI y Seguridad de Datos

La política será parte de una política de seguridad combinada. La preferencia, sin

embargo, debe ser separarlos. Las políticas de seguridad de datos son de
naturaleza más granular y tienen un enfoque muy centrado en los datos en
comparación con una política de seguridad de TI. La definición de estructuras de
directorios y un marco de administración de identidades puede ser el componente
de la Política de seguridad de TI, mientras que la definición de la aplicación
individual, los roles de la base de datos, los grupos de usuarios y los estándares
de contraseña pueden ser parte de la Política de seguridad de datos.

7.2.3 Definir estándares de seguridad de datos

No hay una forma prescrita de implementar la seguridad de datos para cumplir con
los requisitos de privacidad y confidencialidad. Las regulaciones generalmente se
centran en asegurar el logro del "final", aunque rara vez definen los "medios" para
lograrlo. Las organizaciones deben diseñar sus propios controles de seguridad,
demostrar que los controles cumplen con los requisitos de la ley o los reglamentos
y documentar la implementación de esos controles. La estrategia y los estándares
de la tecnología de la información también pueden influir en:

 Herramientas utilizadas para gestionar la seguridad de los datos.

 Normas y mecanismos de cifrado de datos.

 Directrices de acceso a proveedores externos y contratistas.

 Protocolos de transmisión de datos a través de internet.

 Requisitos de documentación.

 Estándares de acceso remoto.

 Procedimientos para reportar incidentes de violación de seguridad.

Considere la seguridad física, especialmente con la explosión de dispositivos y

medios portátiles, para formular una estrategia de seguridad de datos efectiva. Los
estándares de seguridad física, como parte de las políticas de TI de la empresa,
proporcionan pautas que incluyen:

 Acceso a datos mediante dispositivos móviles.

 Almacenamiento de datos en dispositivos portátiles como computadoras
portátiles, DVD, CD o unidades USB.

 Eliminación de estos dispositivos en cumplimiento con las políticas de gestión

de registros.

Una organización, sus partes interesadas y sus reguladores tienen necesidades

relacionadas con el acceso a los datos, la privacidad y la confidencialidad. Usando
estos como requisitos, una organización puede desarrollar una política de
seguridad práctica e implementable, incluidos los principios rectores de seguridad
de datos. El enfoque debe estar en la calidad y la consistencia, no en la creación
de un cuerpo voluminoso de pautas. La política de seguridad de datos debe estar
en un formato que sea fácilmente accesible para los proveedores, consumidores y
partes interesadas. Una organización podría publicar esta política en la intranet de
su empresa o en un portal de colaboración similar. El Consejo de Gobierno de
Datos revisa y aprueba la política. La responsabilidad de la propiedad y el
mantenimiento de la política de seguridad de datos recae en el administrador de
datos y los administradores de seguridad de TI.

La ejecución de la política requiere que se cumplan los cuatro requisitos de

seguridad de los activos de información: autenticación, autorización, acceso y
auditoría. La clasificación de la información, los derechos de acceso, los grupos de
roles, los usuarios y las contraseñas son los medios para implementar la política y
satisfacer los cuatro A´s.

7.2.4 Definir controles y procedimientos de seguridad de datos

La implementación y administración de la política de seguridad de datos es

principalmente responsabilidad de los administradores de seguridad. La seguridad
de la base de datos es a menudo una responsabilidad de los administradores de
bases de datos (DBA).

Las organizaciones deben implementar controles adecuados para cumplir con los
objetivos de las leyes pertinentes. Por ejemplo, un objetivo de control puede leer,
‗Revisar derechos y privilegios de DBA y de usuario mensualmente ‘. El control de
la organización para satisfacer este objetivo podría estar implementando un
proceso para validar los permisos asignados en comparación con un sistema de
administración de cambios utilizado para rastrear todas las solicitudes de permisos
de los usuarios. Además, el control también puede requerir un proceso de
aprobación del flujo de trabajo o un formulario en papel firmado para registrar y
documentar cada solicitud.
7.2.5 Gestionar usuarios, contraseñas y pertenencia a grupos

Se pueden otorgar privilegios de acceso y actualización a cuentas de usuarios

individuales, pero este enfoque resulta en un gran esfuerzo redundante. Los
grupos de funciones permiten a los administradores de seguridad definir privilegios
por función y otorgar estos privilegios a los usuarios inscribiéndolos en el grupo de
funciones adecuado. Si bien puede ser técnicamente posible inscribir usuarios en
más de un grupo, esta práctica puede dificultar la comprensión de los privilegios
específicos otorgados a un usuario específico. Siempre que sea posible, intente
asignar a cada usuario un solo grupo de roles. Construya definiciones de grupo a
nivel de grupo de trabajo o unidad de negocio. Organice los roles en una jerarquía,
de modo que los roles secundarios restrinjan aún más los privilegios de los roles
principales. El mantenimiento continuo de estas jerarquías es una operación
compleja que requiere sistemas de informes capaces de desglosar granularmente
a privilegios de usuarios individuales. Los ejemplos de jerarquía de roles de
seguridad se muestran en la Figura 7.2. Los administradores de seguridad crean,
modifican y eliminan cuentas de usuario y grupos. Los cambios realizados en la
taxonomía y la membresía del grupo deben requerir cierto nivel de aprobación y
seguimiento mediante el uso de un sistema de gestión de cambios.

La consistencia de los datos en la administración de usuarios y grupos es un

desafío en un entorno heterogéneo. La información del usuario, como el nombre,
el título y el número, debe almacenarse de manera redundante en varias
ubicaciones. Estas islas de datos a menudo entran en conflicto, representando
múltiples versiones de la "verdad". Para evitar problemas de integridad de los
datos, administre los datos de identidad del usuario y los datos de membresía del
grupo de roles de manera centralizada.
7.2.5.1 Normas y procedimientos de contraseña

Las contraseñas son la primera línea de defensa para proteger el acceso a los
datos. Cada cuenta de usuario

debe requerirse que el usuario (propietario de la cuenta) establezca una

contraseña con una contraseña suficiente

El nivel de complejidad de las contraseñas definido en los estándares de

seguridad, comúnmente conocido como

Las contraseñas "fuertes". No permita contraseñas en blanco. Complejidad típica

de la contraseña

Los requisitos requieren una contraseña para:

 Contener al menos 8 caracteres.

 Contener una letra mayúscula y un número.

 No ser el mismo que el nombre de usuario.

 No será el mismo que las 5 contraseñas anteriores utilizadas.

 No contiene palabras completas del diccionario en ningún idioma.

 No será incremental (Contraseña1, Contraseña2, etc.).

 No tener dos personajes repetidos secuencialmente.

 Evite usar caracteres adyacentes del teclado.

 Si el sistema admite un espacio en las contraseñas, entonces se puede usar

una 'frase de paso'.

Tradicionalmente, los usuarios han tenido diferentes cuentas y contraseñas para

cada recurso individual, plataforma, sistema de aplicación y / o estación de trabajo.
Este enfoque requiere que los usuarios administren varias contraseñas y cuentas.
Las organizaciones con directorios de usuarios empresariales pueden tener un
mecanismo de sincronización establecido entre los recursos heterogéneos para
facilitar la administración de la contraseña del usuario. En tales casos, se requiere
que el usuario ingrese la contraseña solo una vez, generalmente al iniciar sesión
en la estación de trabajo, después de lo cual toda la autenticación y autorización
se realiza a través de una referencia al directorio de usuarios de la empresa. Un
sistema de administración de identidades implementa esta capacidad,
comúnmente conocida como el "inicio de sesión único". El mantenimiento continuo
de las contraseñas normalmente es responsabilidad del usuario, ya que requiere
que los usuarios cambien sus contraseñas cada 45 a 60 días. Al crear una nueva
cuenta de usuario, la contraseña generada debe configurarse para que caduque
inmediatamente, de modo que los usuarios puedan configurar sus contraseñas
para su uso posterior. Los administradores de seguridad y los analistas de la mesa
de ayuda ayudan a resolver problemas y resolver problemas relacionados con las
contraseñas.

7.2.6 Gestionar vistas de acceso a datos y permisos

La gestión de la seguridad de los datos implica no solo evitar el acceso

inapropiado, sino también permitir el acceso válido y apropiado a los datos. La
mayoría de los conjuntos de datos no tienen requisitos de acceso restringido.
Controle el acceso a datos confidenciales otorgando permisos (habilitar). Sin
permiso, un usuario no puede hacer nada.

Controle el acceso a los datos a nivel individual o grupal. Las organizaciones más
pequeñas pueden encontrar aceptable administrar el acceso a datos a nivel
individual. Las organizaciones más grandes se beneficiarán enormemente del
control de acceso basado en roles, otorgando permisos a grupos de roles y, por lo
tanto, a cada miembro del grupo. Independientemente del enfoque, otorgar
privilegios requiere un análisis cuidadoso de las necesidades de datos y las
responsabilidades de administración. Las vistas de bases de datos relacionales
proporcionan otro mecanismo importante para la seguridad de los datos,
permitiendo restricciones de datos en tablas a ciertas filas basadas en valores de
datos. Las vistas también pueden restringir el acceso a ciertas columnas,
permitiendo un acceso más amplio a algunas columnas y un acceso limitado a
campos más confidenciales.

El control de acceso se degrada cuando se logra a través de cuentas compartidas

o de servicio. Diseñadas como una conveniencia para los administradores, estas
cuentas a menudo vienen con privilegios mejorados y no son rastreables para
ningún usuario o administrador en particular. Las empresas que utilizan cuentas
compartidas o de servicio corren el riesgo de violaciones de seguridad de datos.
Algunas organizaciones configuran los sistemas de monitoreo para ignorar las
alertas relacionadas con estas cuentas, lo que mejora aún más este riesgo. Evalúe
el uso de dichas cuentas con cuidado y nunca las use con frecuencia o por
defecto.
7.2.7 Supervisar la autenticación del usuario y el comportamiento de acceso

El monitoreo de la autenticación y el comportamiento de acceso es crítico porque:

 Proporciona información sobre quién se conecta y accede a los activos de

información, que es un requisito básico para la auditoría de cumplimiento.

 Alerta a los administradores de seguridad ante situaciones imprevistas,

compensando los descuidos en la planificación, el diseño y la implementación de
la seguridad de datos.

El monitoreo ayuda a detectar transacciones inusuales o sospechosas que pueden

justificar una mayor investigación y resolución de problemas. Realizar el
seguimiento de forma activa o pasiva. Los sistemas automatizados con controles
humanos y balances implementados cumplen mejor ambos métodos. Los
sistemas que contienen información confidencial, como salarios, datos financieros,
etc. comúnmente implementan un monitoreo activo en tiempo real. En tales casos,
la supervisión en tiempo real puede alertar al administrador de seguridad o al
administrador de datos cuando el sistema observa una actividad sospechosa o un
acceso inadecuado. El sistema envía una notificación al administrador de datos,
generalmente en forma de alertas por correo electrónico u otros mecanismos de
notificación configurables. El monitoreo pasivo rastrea los cambios a lo largo del
tiempo tomando instantáneas del estado actual de un sistema a intervalos
regulares y comparando tendencias con un punto de referencia o un conjunto
definido de criterios. El sistema envía informes a los administradores de datos
responsables de los datos. Si bien el monitoreo activo es más un mecanismo de
detección, considere el monitoreo pasivo como un mecanismo de evaluación. La
supervisión automatizada impone una sobrecarga en los sistemas subyacentes. Si
bien los avances en tecnología han reducido las preocupaciones sobre el
consumo de recursos en los últimos años, el monitoreo todavía puede afectar el
rendimiento del sistema. Decidir qué es lo que se debe monitorear, por cuánto
tiempo y qué acciones se deben tomar en caso de una alerta, requiere un análisis
cuidadoso. Es posible que se requieran cambios de configuración iterativos para
lograr los parámetros óptimos para una supervisión adecuada. Exigir el monitoreo
en varias capas o puntos de contacto de datos. El monitoreo puede ser:

 Aplicación específica.

 Implementado para ciertos usuarios y / o grupos de roles.

 Implementado para ciertos privilegios.

 Utilizado para validación de integridad de datos.

 Implementado para la configuración y validación de metadatos centrales.

 Implementado en sistemas heterogéneos para verificar dependencias.

7.2.8 Clasificar información confidencial

Clasifique los productos de datos e información de una empresa utilizando un

esquema de clasificación de confidencialidad simple. La mayoría de las
organizaciones clasifican el nivel de confidencialidad de la información que se
encuentra en los documentos, incluidos los informes. Un esquema de clasificación
típico podría incluir los siguientes cinco niveles de clasificación de
confidencialidad:

 Para audiencias generales: información disponible para cualquier persona,

incluido el público en general. El público general es la supuesta clasificación por
defecto.

 Solo uso interno: información limitada a los empleados o miembros, pero con un
riesgo mínimo si se comparte. El uso interno solo se puede mostrar o discutir, pero
no se puede copiar fuera de la organización.

 Confidencial: información que no debe compartirse fuera de la organización. La

información confidencial del cliente no se puede compartir con otros clientes.

 Confidencial restringido: información limitada a individuos que desempeñan

ciertos roles con la "necesidad de saber". La confidencialidad restringida puede
requerir que las personas califiquen a través de la autorización.

 Confidencial registrado: información tan confidencial que cualquier persona que

acceda a la información debe firmar un acuerdo legal para acceder a la
información y asumir la responsabilidad de su secreto.

Clasifique documentos e informes según el nivel más alto de confidencialidad para

cualquier información que se encuentre dentro del documento. Etiquete cada
página o pantalla con la clasificación en el encabezado o pie de página. Los
productos de información clasificados "Para el público en general" no necesitan
etiquetas. Supongamos que cualquier producto no etiquetado sea para el público
en general. Los autores de documentos y los diseñadores de productos de
información son responsables de evaluar, clasificar correctamente y etiquetar el
nivel de confidencialidad adecuado para cada documento.

Además, clasifique bases de datos, tablas relacionales, columnas y vistas. La

clasificación de la confidencialidad de la información es una característica
importante de los metadatos, que guía cómo los usuarios tienen privilegios de
acceso. Los administradores de datos son responsables de evaluar y determinar el
nivel de confidencialidad adecuado para los datos.

7.2.9 Seguridad de datos de auditoría

La auditoría de la seguridad de los datos es una actividad de control recurrente

con la responsabilidad de analizar, validar, asesorar y recomendar políticas,
estándares y actividades relacionadas con la administración de la seguridad de los
datos. La auditoría es una actividad de gestión realizada con la ayuda de analistas
que trabajan en la implementación y los detalles reales. Los auditores internos o
externos pueden realizar auditorías; sin embargo, los auditores deben ser
independientes de los datos y / o procesos involucrados en la auditoría. Los
auditores de seguridad de datos no deben tener responsabilidad directa por las
actividades que se auditan, para ayudar a garantizar la integridad de la actividad y
los resultados de la auditoría. La auditoría no es una misión de encontrar fallas. El
objetivo de la auditoría es proporcionar a la administración y al consejo de
gobernanza de datos evaluaciones objetivas e imparciales y recomendaciones
prácticas y racionales.

Las declaraciones de políticas de seguridad de datos, documentos de estándares,

guías de implementación, solicitudes de cambio, registros de monitoreo de
acceso, resultados de informes y otros registros (electrónicos o impresos) forman
la base de la auditoría. Además de examinar la evidencia existente, las auditorías
también pueden incluir la realización de pruebas y controles. La auditoría de
seguridad de datos incluye:

 Analizar las políticas y estándares de seguridad de datos en relación con las

mejores prácticas y necesidades.

 Analizar los procedimientos de implementación y las prácticas reales para

garantizar la coherencia con los objetivos de seguridad de datos, políticas,
estándares, directrices y resultados deseados.

 Evaluar si los estándares y procedimientos existentes son adecuados y están

alineados con los requisitos de negocios y tecnología.

 Verificar que la organización cumple con los requisitos reglamentarios.

 Revisar la confiabilidad y precisión de los datos de auditoría de seguridad de

datos.

 Evaluar los procedimientos de escalamiento y los mecanismos de notificación

en caso de una violación de la seguridad de los datos.
 Revisar los contratos, los acuerdos de intercambio de datos y las obligaciones
de seguridad de datos de proveedores externos y externos, asegurando que
cumplan con sus obligaciones y asegurando que la organización cumpla con sus
obligaciones para los datos de fuentes externas.

 Informar a la administración superior, a los administradores de datos y a otras

partes interesadas sobre la "Estado de la seguridad de los datos" dentro de la
organización y la madurez de sus prácticas.

 Recomendar mejoras de diseño, operacionales y de cumplimiento de seguridad

de datos.

La auditoría de la seguridad de los datos no sustituye la gestión eficaz de la

seguridad de los datos. La auditoría es un proceso de apoyo, repetible, que debe
ocurrir de manera regular, eficiente y consistente.

7.3 Seguridad de datos en un mundo subcontratado

Las organizaciones pueden optar por externalizar ciertas funciones de TI, como
las operaciones por lotes, el desarrollo de aplicaciones y / o la administración de
bases de datos. Algunos incluso pueden subcontratar la administración de
seguridad de datos. Puede subcontratar casi cualquier cosa, pero no su
responsabilidad. La externalización de las operaciones de TI presenta desafíos y
responsabilidades adicionales de seguridad de datos. La subcontratación aumenta
el número de personas que comparten la responsabilidad de los datos a través de
los límites organizativos y geográficos. Los roles y responsabilidades
anteriormente informales ahora deben definirse explícitamente como obligaciones
contractuales. Los contratos de subcontratación deben especificar las
responsabilidades y expectativas de cada rol.

Cualquier forma de subcontratación aumenta el riesgo para la organización,

incluida la pérdida de control sobre el entorno técnico y las personas que trabajan
con los datos de la organización. El riesgo de seguridad de los datos se escala
para incluir al proveedor externo, por lo que cualquier dato Las medidas y los
procesos de seguridad deben considerar el riesgo del proveedor externo, no solo
como un riesgo externo, sino también como un riesgo interno. Transferir el control,
pero no la responsabilidad, requiere mecanismos más estrictos de control y
gestión de riesgos. Algunos de estos mecanismos incluyen:

 Acuerdos de nivel de servicio.

 Disposiciones de responsabilidad limitada en el contrato de subcontratación.

 Cláusulas de derecho a auditoría en el contrato.

 Consecuencias claramente definidas por el incumplimiento de obligaciones
contractuales.

 Informes frecuentes de seguridad de datos del proveedor del servicio.

 Monitoreo independiente de la actividad del sistema de proveedores.

 Auditoría de seguridad de datos más frecuente y exhaustiva.

 Comunicación constante con el proveedor del servicio.

En un entorno subcontratado, es fundamental mantener y rastrear el linaje o flujo

de datos a través de sistemas e individuos para mantener una "cadena de
custodia". Las organizaciones de outsourcing se benefician especialmente del
desarrollo de matrices CRUD (Crear, Leer, Actualizar y Eliminar) que mapean las
responsabilidades de los datos en los procesos de negocios, aplicaciones, roles y
organizaciones, rastreando la transformación, el linaje y la cadena de custodia de
los datos.

Las matrices responsables, responsables, consultadas e informadas (RACI)

también ayudan a aclarar los roles, la separación de deberes y responsabilidades
de los diferentes roles y sus requisitos de seguridad de datos. La matriz RACI
también puede formar parte de los documentos contractuales, acuerdos y políticas
de seguridad de datos. La definición de matrices de responsabilidad como RACI
establecerá una clara responsabilidad y propiedad entre las partes involucradas en
el compromiso de subcontratación, lo que dará lugar al apoyo de las políticas
generales de seguridad de datos y su implementación. En la subcontratación de
las operaciones de tecnología de la información, la responsabilidad de mantener
los datos aún recae en la organización. Es fundamental contar con mecanismos
de cumplimiento apropiados y tener expectativas realistas de las partes que
celebran los acuerdos de subcontratación.

7.4 Resumen

A continuación se resumen los principios rectores para implementar la gestión de

seguridad de datos en una organización, una tabla de resumen de los roles para
cada actividad de gestión de seguridad de datos y los problemas de organización
y culturales que pueden surgir durante la gestión de seguridad de datos.
7.4.1 Principios Rectores

La implementación de la función de gestión de seguridad de datos en una

organización sigue quince principios rectores:

1. Ser un administrador responsable de los datos de todas las partes. Ellos son los
dueños de los datos. Comprenda y respete las necesidades de privacidad y
confidencialidad de todas las partes interesadas, ya sean clientes, pacientes,
estudiantes, ciudadanos, proveedores o socios comerciales.

2. Comprender y cumplir con todas las normas y directrices pertinentes.

3. Las matrices de datos a procesar y de relación de datos a rol (CRUD – Crear,

Leer, Actualizar, Eliminar) ayudan a asignar las necesidades de acceso a los datos
y guían la definición de los grupos de roles de seguridad de datos, parámetros y
permisos.

4. La definición de los requisitos de seguridad de datos y la política de seguridad

de datos es un esfuerzo de colaboración entre los administradores de seguridad
de TI, administradores de datos, equipos de auditoría interna y externa y el
departamento legal. El consejo de gobierno de datos debe revisar y aprobar la
política de seguridad de datos de alto nivel.

5. Identifique los requisitos detallados de seguridad de la aplicación en la fase de

análisis de cada proyecto de desarrollo de sistemas.

6. Clasifique todos los datos de la empresa y los productos de información contra

un esquema de clasificación de confidencialidad simple.

7. Cada cuenta de usuario debe tener una contraseña establecida por el usuario
siguiendo un conjunto de pautas de complejidad de contraseñas y con vencimiento
cada 45 a 60 días.

8. Crear grupos de roles; definir privilegios por rol; y otorgue privilegios a los
usuarios asignándolos al grupo de roles apropiado. Siempre que sea posible,
asigne a cada usuario solo un grupo de roles.

9. Algunos niveles de administración deben solicitar, seguir y aprobar formalmente

todas las autorizaciones iniciales y los cambios posteriores a las autorizaciones de
usuarios y grupos.

10. Para evitar problemas de integridad de datos con la información de acceso de

seguridad, administre de manera centralizada los datos de identidad del usuario y
los datos de membresía del grupo.
11. Utilice vistas de bases de datos relacionales para restringir el acceso a
columnas confidenciales y / o filas específicas.

12. Limite estrictamente y considere cuidadosamente cada uso de cuentas de

usuario compartidas o de servicio.

13. Monitoree el acceso de datos a cierta información de forma activa y tome

instantáneas periódicas de la actividad de acceso de datos para comprender las
tendencias y comparar con los criterios de los estándares.

14. Periódicamente, realice auditorías de seguridad de datos objetivas e

independientes para verificar el cumplimiento de las normas y el cumplimiento de
las normas, y para analizar la efectividad y madurez de la política y práctica de
seguridad de datos.

15. En un entorno subcontratado, asegúrese de definir claramente los roles y

responsabilidades para la seguridad de los datos y entienda la "cadena de
custodia" de los datos en todas las organizaciones y roles.
7.4.2 Resumen del proceso

El resumen del proceso para la función de administración de seguridad de datos

se muestra en la Tabla 7.1. Los entregables, roles responsables, roles de
aprobación y roles contribuyentes se muestran para cada actividad en la función
de administración de seguridad de datos. La Tabla también se muestra en el
Apéndice A9.
7.4.3 Cuestiones organizativas y culturales

P1: ¿Cómo puede tener éxito la seguridad de los datos?

A1: La seguridad exitosa de los datos está profundamente incorporada en la

cultura corporativa, pero este no es el caso en muchas compañías. Las
organizaciones a menudo terminan siendo reactivas en la gestión de seguridad de
datos en lugar de ser proactivas. El nivel de madurez en la gestión de la seguridad
de los datos ha aumentado con los años, pero todavía hay oportunidades de
mejora. Las brechas en la seguridad de los datos han demostrado que las
empresas aún están luchando y vacilando para organizarse. En el lado positivo,
las regulaciones recientemente introducidas son el aumento de la responsabilidad,
la capacidad de auditoría y el conocimiento de la importancia de la seguridad de
los datos.

P2: ¿Puede haber una buena seguridad mientras se permite el acceso?

A2: Proteger y proteger los datos sin sofocar el acceso de los usuarios a los datos
es una tarea desalentadora. A las organizaciones con una cultura de gestión de
procesos les resultará relativamente menos difícil contar con un marco formidable
para la gestión de la seguridad de los datos. Evalúe periódicamente las políticas
de seguridad de datos, procedimientos y actividades para lograr el mejor equilibrio
posible entre los requisitos de seguridad de datos de todas las partes interesadas.

P3: ¿Qué significa realmente la seguridad de los datos?

A3: La seguridad de datos significa diferentes cosas para diferentes personas.

Ciertos elementos de datos pueden considerarse sensibles en algunas
organizaciones y culturas, pero no en otras. Ciertos individuos o roles pueden
tener derechos y responsabilidades adicionales que ni siquiera existen en otras
organizaciones.

P4: ¿Las medidas de seguridad de datos se aplican a todos?

A4: la aplicación de medidas de seguridad de datos de forma inconsistente o

inadecuada dentro de una organización puede llevar a la insatisfacción y el riesgo
de los empleados para la organización. La seguridad basada en roles depende de
la organización para definir y asignar los roles, y aplicarlos de manera consistente.

P5: ¿Los clientes y empleados deben participar en la seguridad de los

datos?

A5: La implementación de medidas de seguridad de datos sin tener en cuenta las

expectativas de los clientes y empleados puede dar como resultado la
insatisfacción de los empleados, la insatisfacción de los clientes y el riesgo
organizativo. Cualquier medida o proceso de seguridad de datos debe tener en
cuenta el punto de vista de quienes trabajarán con esas medidas y procesos para
garantizar el mayor cumplimiento.

P6: ¿Cómo realmente evitas las brechas de seguridad?

A6: La gente necesita comprender y apreciar la necesidad de seguridad de datos.

La mejor manera de evitar violaciones a la seguridad de los datos es crear
conciencia y comprensión de los requisitos, políticas y procedimientos de
seguridad. Las organizaciones pueden crear conciencia y aumentar el
cumplimiento a través de:

 Promoción de estándares a través de la capacitación en iniciativas de seguridad

en todos los niveles de la organización. Siga la capacitación con mecanismos de
evaluación, como las pruebas en línea centradas en mejorar la conciencia de los
empleados. Dicha capacitación y pruebas deben ser obligatorias y un requisito
previo para la evaluación del desempeño de los empleados.

 Definición de políticas de seguridad de datos para grupos de trabajo y

departamentos que complementan y se alinean con las políticas empresariales.
Adoptar una mentalidad de "contacto local" ayuda a las personas a participar más
activamente.

 Enlaces a la seguridad de datos dentro de las iniciativas organizativas. Las

organizaciones deben incluir métricas objetivas para las actividades de seguridad
de datos en sus mediciones de cuadro de mando integral y evaluaciones de
proyectos.

 Inclusión de requisitos de seguridad de datos en acuerdos de nivel de servicio y

obligaciones contractuales de subcontratación.

 Hacer énfasis en los requisitos legales, contractuales y regulatorios aplicables a

su industria para crear un sentido de urgencia y un marco interno para la gestión
de la seguridad de los datos.

P7: ¿Cuál es el principio guía principal para la seguridad de los datos?

A7: El éxito en la gestión de la seguridad de los datos depende de ser proactivo

para involucrar a las personas, gestionar el cambio y superar los cuellos de botella
culturales.
.5 Lectura Recomendada

Las referencias enumeradas a continuación proporcionan lecturas adicionales que

apoyan el material presentado en el Capítulo 7. Estas lecturas recomendadas
también se incluyen en la Bibliografía al final de la Guía.

7.5.1 Textos y artículos

Afyouni, Hassan A. Seguridad y auditoría de bases de datos: protección de la

integridad y accesibilidad de los datos. Curso de Tecnología, 2005. ISBN 0-619-
21559-3.

Anderson, Ross J. Ingeniería de seguridad: una guía para crear sistemas

distribuidos confiables. Wiley, 2008. ISBN 0-470-06852-6.

Axelrod, C. Warren. Externalización de la seguridad de la información. Casa

Artech, 2004. ISBN 0-58053-531-3.

Calder, Alan y Steve Watkins. Gobernanza de TI: Guía del administrador para la
seguridad de datos y BS 7799 / ISO 17799, 3ra edición. Kogan Page, 2005. ISBN
0-749-44414-2.

Castaño, Silvana, Maria Grazia Fugini, Giancarlo Martella y Pierangela Samarati.

Base de datos de seguridad. Addison-Wesley, 1995. ISBN 0-201-59375-0.

Dennis, Jill Callahan. Privacidad y Confidencialidad de la Información de Salud.

Jossey-Bass, 2000. ISBN 0-787-95278-8.

Gertz, Michael y Sushil Jajodia. Manual de Seguridad de Bases de Datos:

Aplicaciones y Tendencias. Springer, 2007. ISBN 0-387-48532-5.

Jaquith andrew Métricas de seguridad: Reemplazo del miedo, la incertidumbre y la

duda. Addison-Wesley, 2007. ISBN 0-321-349998-9.

Landoll, Douglas J. El Manual de evaluación de riesgos de seguridad: una guía

completa para realizar evaluaciones de riesgos de seguridad. CRC, 2005. ISBN 0-
849-32998-1.

Litchfield, David, Chris Anley, John Heasman y Bill Frindlay. El manual del hacker
de bases de datos: la defensa de los servidores de bases de datos. Wiley, 2005.
ISBN 0-764-57801-4.

Mullins, Craig S. Administración de bases de datos: la guía completa de prácticas

y procedimientos. Addison-Wesley, 2002. ISBN 0-201-74129-6.
Peltier, Thomas R. Políticas y procedimientos de seguridad de la información: una
referencia del profesional, 2ª edición. Auerbach, 2004. ISBN 0-849-31958-7.

Shostack, Adam y Andrew Stewart. La Nueva Escuela de Seguridad de la

Información. Addison-Wesley, 2008. ISBN 0-321-50278-7.

Thuraisingham, Bhavani. Base de datos y seguridad de aplicaciones: integración

de la seguridad de la información y la gestión de datos. Publicaciones Auerbac,
2005. ISN 0-849-32224-3.

Whitman, Michael R. y Herbert H. Mattord. Principios de Seguridad de la

Información, Tercera Edición. Curso de Tecnología, 2007. ISBN 1-423-90177-0.

7.5.2 Principales normas de privacidad y seguridad

Las principales regulaciones de privacidad y seguridad que afectan los estándares

de seguridad de datos se enumeran a continuación.

7.5.2.1 Leyes de privacidad fuera de los Estados Unidos:

 Argentina: Ley de protección de datos personales de 2000 (también conocida

como Habeas Data).

 Austria: Ley de protección de datos de 2000, Gaceta de Leyes Federales de

Austria, Parte I No. 165/1999 (DSG 2000).

 Australia: Ley de Privacidad de 1988.

 Brasil: Privacidad actualmente regulada por el artículo 5 de la Constitución de

1988.

 Canadá: Ley de privacidad - Julio de 1983, Ley de protección de información

personal y datos electrónicos (PIPEDA) de 2000 (Proyecto de ley C-6).

 Chile: Ley de protección de datos personales, agosto de 1998.

 Columbia: no existe una ley de privacidad específica, pero la constitución

colombiana otorga a cualquier persona el derecho de actualizar y acceder a su
información personal.

 República Checa: Ley de protección de datos personales (abril de 2000) Nº 101.

 Dinamarca: Ley de tratamiento de datos personales, Ley Nº 429, mayo de 2000.

 Estonia: Ley de protección de datos personales, junio de 1996, julio de 2002

consolidado.
 Unión Europea: Directiva de protección de datos de 1998.

 Unión Europea: Ley de Privacidad de Internet de 2002 (DIRECTIVA 2002/58 /

EC).

 Finlandia: Ley de modificación de la Ley de datos personales (986) 2000.

 Francia: Ley de protección de datos de 1978 (revisada en 2004).

 Alemania: Ley Federal de Protección de Datos de 2001.

 Grecia: Ley N ° 2472 sobre la protección de las personas con respecto al

procesamiento de datos personales, abril de 1997.

 Hong Kong: Ordenanza de Datos Personales (La "Ordenanza").

 Hungría: Ley LXIII de 1992 sobre la protección de datos personales y la

publicidad de datos de interés público.

 Islandia: Ley de Protección de la Persona; Procesamiento de datos personales

(enero 2000).

 Irlanda: Ley de Protección de Datos (Modificación), Número 6 de 2003.

 India: Ley de tecnología de la información de 2000.

 Italia: Código de protección de datos de 2003 Italia: Ley de procesamiento de

datos personales, enero de 1997.

 Japón: Ley de Protección de Información Personal (Ley).

 Japón: Ley para la protección de datos procesados por computadora en poder

de organizaciones administrativas, diciembre de 1988.

 Corea: Ley de protección de la información personal de las agencias públicas

Ley de uso de la red de información y comunicación.

 Letonia: Ley de protección de datos personales, 23 de marzo de 2000.

 Lituania: Ley de protección jurídica de datos personales (junio de 1996).

 Luxemburgo: Ley de 2 de agosto de 2002 sobre la protección de las personas

con respecto al tratamiento de datos personales.

 Malasia: principio de confidencialidad de ley común. Proyecto de Ley de

Protección de Datos Personales Ley de Bancos e Instituciones Financieras de
1989, disposiciones de privacidad.
 Malta: Ley de protección de datos (Ley XXVI de 2001), modificada el 22 de
marzo de 2002, el 15 de noviembre de 2002 y el 15 de julio de 2003.

 Nueva Zelanda: Ley de Privacidad, mayo de 1993; Ley de Enmienda de

Privacidad, 1993; Ley de Enmienda de Privacidad, 1994.

 Noruega: Ley de datos personales (abril de 2000) - Ley de 14 de abril de 2000

Nº 31 relativa al procesamiento de datos personales (Ley de datos personales).

 Filipinas: no existe una ley general de protección de datos, pero existe un

derecho de privacidad reconocido en el derecho civil.

 Polonia: Ley de protección de datos personales (agosto de 1997).

 Singapur: el Código de comercio electrónico para la protección de la información

personal y las comunicaciones de los consumidores del comercio por Internet.

 República Eslovaca: Ley Nº 428 de 3 de julio de 2002 sobre protección de datos

personales.

 Eslovenia: Ley de protección de datos personales, RS No. 55/99.

 Corea del Sur: La Ley de Promoción de la Utilización de Redes de Información y

Comunicaciones y Protección de Datos del 2000.

 España: LEY ORGÁNICA 15/1999, de 13 de diciembre, de Protección de Datos

Personales.

 Suiza: La Ley Federal de Protección de Datos de 1992.

 Suecia: Ley de protección de datos personales (1998: 204), 24 de octubre de

1998.

 Taiwán: Ley de protección de datos personales procesados por computadora: se

aplica solo a instituciones públicas.

 Tailandia: Ley de información oficial (1997) para agencias estatales (proyecto de

ley de protección de datos personales bajo consideración).

 Vietnam: La Ley de Transacciones Electrónicas (Proyecto: Finalizado en 2006).

7.5.2.2 Leyes de privacidad de los Estados Unidos:

 Ley de Estadounidenses con Discapacidades (ADA).

 Ley de Política de Comunicaciones de Cable de 1984 (Ley de Cable).

 Proyecto de Ley 1386 del Senado de California (SB 1386).

 Ley de protección de Internet para niños de 2001 (CIPA).

 Ley de protección de la privacidad en línea para niños de 1998 (COPPA).

 Ley de Asistencia de Comunicaciones para la Aplicación de la Ley de 1994

(CALEA).

 Ley de abuso y fraude informático de 1986 (CFAA).

 Ley de Seguridad Informática de 1987 - (Reemplazada por la Ley Federal de

Gestión de Seguridad de la Información (FISMA).

 Ley de Reforma de Informes de Crédito al Consumidor de 1996 (CCRRA) -

Modifica la Ley de Informes de Crédito Justos (FCRA).

 Control de la Ley de Asalto a la Pornografía y el Marketing No Solicitados (CAN-

SPAM) de 2003.

 Ley de Transferencia Electrónica de Fondos (AELC).

 Ley de Transacciones de Crédito Justas y Exactas (FACTA) de 2003.

 Ley de Informe de Crédito Justo.

 Ley Federal de Gestión de la Seguridad de la Información (FISMA).

 Ley de protección de la privacidad del conductor de 1994.

 Ley de Privacidad de las Comunicaciones Electrónicas de 1986 (ECPA).

 Ley de libertad electrónica de información de 1996 (E-FOIA).

 Ley de Informe de Crédito Justo de 1999 (FCRA).

 Ley de Derechos de Educación y Privacidad de la Familia de 1974 (FERPA;

también conocida como la Enmienda Buckley).

 Ley de Modernización de Servicios Financieros de Gramm-Leach-Bliley de 1999

(GLBA).

 Ley de Privacidad de 1974.

 Ley de protección de la privacidad de 1980 (PPA).

 Ley de Derecho a la Privacidad Financiera de 1978 (RFPA).

 Ley de Telecomunicaciones de 1996.

 Ley de Protección al Consumidor Telefónico de 1991 (TCPA).

 Uniendo y fortaleciendo a América proporcionando las herramientas apropiadas

necesarias para interceptar y obstruir la Ley de Terrorismo de 2001 (Ley
PATRIOTA de EE. UU.).

 Ley de protección de la privacidad de video de 1988.

7.5.2.3 Reglamentos de seguridad y privacidad específicos de la industria:

 Servicios financieros: Gramm-Leach-Bliley Act (GLBA), Estándar de seguridad

de datos PCI.

 Atención médica y productos farmacéuticos: HIPAA (Ley de responsabilidad y

portabilidad de seguros de salud de 1996) y FDA 21 CFR Parte 11.

 Infraestructura y energía: Estándares de seguridad cibernética FERC y NERC,

Programa de seguridad cibernética del sector químico y Asociación de aduanas y
comercio contra el terrorismo (C-TPAT).

 Gobierno federal de los EE. UU .: FISMA y las pautas de la NSA y el estándar

NIST relacionados.

CAN-SPAM - Ley federal sobre correo electrónico no solicitado. Ley de la

Comisión Federal de Comercio (FTCA).