Auditoria de bases de datos - dit.ing.unp.edu.ar · La Auditoria de Bases de Datos es una temática...

Auditoria de bases de datos GAVA: Soporte para registración y análisis de cambios en los datos

Tesis de Licenciatura

Ingravallo, Héctor Gabriel

Entraigas, Valeria Elizabeth

Tutor: Lic. Carlos Buckle

Universidad Nacional de la Patagonia

Facultad de Ingeniería

Departamento de Informática

Licenciatura en Informática

Trelew, 19 de marzo de 2007

Auditorías en Base de Datos. Herramienta para rastros de actividad Activity Log

Ingravallo Gabriel – Entraigas Valeria Página: I

Agradecimientos

De Gabriel:

A mi madre por su incesante empuje, apoyo y paciencia.

A Carlos, Laura, Pablo y Verónica por la constante preocupación, ánimo y aliento.

A mi familia y amigos por interiorizarse en mis estudios en cada oportunidad que les

era posible.

De Valeria:

A mis padres, hermano y abuela por su apoyo incondicional.

A Sergio por toda su paciencia.

A mis amigos por su aliento.

Antecedentes

Antecedentes de Gabriel:

He sido docente de la UNPSJB desde el año 1987 en distintas materias como

Introducción a la Computación, Lógica y Programación, Diagramación y Programación. A

partir de 1991 me comienzo a desempeñar como docente de Bases de Datos en el cargo de

Auxiliar Docente, en 1993 como Jefe de Trabajos Prácticos, en 1994 como JTP a cargo de la

cátedra, en 1995 como Profesor Adjunto Interino y a partir del 2000 hasta la actualidad

como Adjunto Ordinario.

Además he sido Analista Funcional y Lider de Proyecto desde 1988 a 1990 en

trabajos en la orbita pública dependiente de la Dirección General de Informática de la

Provincia del Chubut, realizando cursos de especialización en Bases de Datos sobre sistemas

Unysis A2 durante 1 año. En la orbita privada como Analista Programador y Líder de


Ingravallo Gabriel – Entraigas Valeria Página: II

Proyecto desde 1991 hasta 2003, de Sistemas de Salud Pública Hospitalaria y Sistema de

Salud para Obras Sociales Prepagas desarrollando y administrando Bases de Datos.

Actualmente me desempeño como Analista Funcional desde 2004 en el ámbito de la

Tesorería del Consejo de Administración de la Cooperativa Eléctrica de Trelew integrante de

la comisión de implementación y adquisición del Sistema de Servicios Públicos sobre Bases

de Datos Relacional SQL-Server/Oracle/DB2.

Antecedentes De Valeria:

Me desempeño como ayudante de cátedra en la materia Base de Datos en la UNPSJB

desde 2005. Desarrolle sistemas en Cobol en el año 2004 en la empresa Perren y CIA. Estoy

a cargo de la Jefatura de Desarrollo y mantenimiento de Sistemas de la Municipalidad de la

cuidad de Trelew. a.C. desarrollamos y mantenemos sistemas en varios lenguajes; Clipper,

Visual Basic 6.0, C, Visual Basic .Net; de programación. Los sistemas en desarrollo utilizan

como motor de base de datos MS SQL Server 2000, uno de los dos motores de base de

datos elegidos en el trabajo.


Ingravallo Gabriel – Entraigas Valeria Página: III

Resumen

La Auditoria de Bases de Datos es una temática relativamente nueva si consideramos

que las Bases de Datos y los motores que las manejan se han popularizado en estos últimos

15 años, no obstante la necesidad del control y registración del cambio de datos es un

hecho que muchos profesionales siempre pensaron en poner en práctica.

Este trabajo presenta una introducción teórica a la Auditoria Informática como marco

general describiendo los diferentes conceptos de los objetos que la integran tanto como sus

componentes y el marco legal argentino en el que se haya inmerso.

Y como resultado práctico final se ofrece una herramienta que permite en forma

sencilla, intuitiva y sobre todo centralizada mantener una registración sobre el cambio de

los datos y su posterior análisis. Tal herramienta tiene la capacidad de interactuar con

cualquier DBMS y Base de Datos desarrollada siempre que esté previamente configurada.

Summary

The Data Base Auditing is a relatively new topic, considering that Data Bases and

Data Base Management Systems have become popular fifteen years ago.

However, is a fact that many professional always have had in mind the

implementation of data changes activity registration systems.

This work introduce Informatic Auditing concepts describing their objects,

components and the Argentine legal framework.

As a final result, we offer one simple, intuitive and centralized tool that allows keep

data change logging and its later analysis. This tool can connect to any DBMS and Data

Base previously configured.


Ingravallo Gabriel – Entraigas Valeria Página: IV

Agradecimientos ...................................................................................... I

De Gabriel: ......................................................................................................... I

De Valeria: .......................................................................................................... I

Antecedentes ........................................................................................... I

Antecedentes de Gabriel: ...................................................................................... I

Antecedentes De Valeria: ..................................................................................... II

Resumen _______________________________________________________ III

Summary _______________________________________________________ III

Capítulo 1 INTRODUCCION ___________________________________________ 1

Motivación ............................................................................................... 2

Objetivos ................................................................................................. 4

Generales .......................................................................................................... 4

Particulares ........................................................................................................ 5

Beneficiarios ............................................................................................ 5

Primarios ........................................................................................................... 6

Secundarios ....................................................................................................... 6

Alcances .................................................................................................. 7

Capítulo 2 FUNDAMENTACION TEORICA _________________________________ 8

Auditoria .................................................................................................. 8

Definición........................................................................................................... 8

Objetivo............................................................................................................. 8

Clases de Auditoria ............................................................................................. 8

Control Interno versus Auditoria Interna ................................................................ 9

Auditoria y su Marco Legal ..................................................................... 10

Ley de Protección de Datos Personales ................................................................ 10

Sanciones previstas por Ley ............................................................................... 10

Órgano de Control ............................................................................................. 10

Ley de Control interno y Auditoria ....................................................................... 11

Auditoria y Sistemas de Información ..................................................... 12

Auditoria Informática ......................................................................................... 12

Control Interno Informático ................................................................................ 13


Ingravallo Gabriel – Entraigas Valeria Página: V

Posibles problemas............................................................................................ 14

El Auditor Informático ....................................................................................... 15

Sistemas de Bases de Datos Auditables ................................................. 16

Objetivos de la auditoria en DB ........................................................................... 16

Capas auditables............................................................................................... 17

Capítulo 3 INVESTIGACION DE ACTIVITY LOGS EN DIFERENTES DBMS ________ 18

Oracle .................................................................................................... 18

DB2 ........................................................................................................ 18

SQLServer .............................................................................................. 19

Postgres ................................................................................................ 19

MySQL ................................................................................................... 20

Informix ................................................................................................ 20

Mecanismos de conexión y Triggers....................................................... 21

Capítulo 4 CARACTERIZACION DE LA HERRAMIENTA ______________________ 22

Libertad de entorno ............................................................................... 22

Autoconfiguración de Administradores de Datos ................................... 22

Registración de actividad centralizada .................................................. 23

Almacenamiento descentralizado .......................................................... 23

Control Post-creación centralizado ........................................................ 23

Análisis centralizado de cambios ........................................................... 23

Seguridad de cambios ............................................................................ 23

Libertad de Aplicación ........................................................................... 24

No Intrusivo .......................................................................................... 24

Extensible .............................................................................................. 24

Capítulo 5 DESARROLLO ____________________________________________ 25

Introducción .......................................................................................... 25

Descripción del producto desarrollado ................................................... 27


Ingravallo Gabriel – Entraigas Valeria Página: VI

Descripción del funcionamiento ............................................................. 27

Arquitectura GAVA ................................................................................. 29

Funciones de Negocio ............................................................................ 30

Solución ................................................................................................. 31

Variantes en el diseño de la solución .................................................................. 31

Solución de la creación de trazas ........................................................................ 34

Solución de diseño ............................................................................................ 36

Estructura del Sistema ........................................................................... 38

Diseño ............................................................................................................. 38

Modelado de Datos ............................................................................................ 38

Modelo Funcional .............................................................................................. 38

Interface con el usuario ..................................................................................... 40

Bases de datos ................................................................................................. 41

Capítulo 6 INFRAESTRUCTURA UTILIZADA ______________________________ 44

Arquitectura .......................................................................................... 44

Consideraciones..................................................................................... 44

Seguridad .............................................................................................. 44

Capítulo 7 SELECCIÓN DE HERRAMIENTAS ______________________________ 45

DBMS ..................................................................................................... 45

Programación ........................................................................................ 46

Lenguaje ......................................................................................................... 46

Diseñador de Reportes ...................................................................................... 46

Capítulo 8 CONCLUSIONES __________________________________________ 47

Componentes no incluidos y posibles extensiones ................................. 47

Comentarios finales ............................................................................... 48

Conclusiones .......................................................................................... 49

Apéndice I DESARROLLO DEL PROYECTO _______________________________ 50

Plan de Trabajo ...................................................................................... 50

Cronograma ........................................................................................... 52

Previsto ........................................................................................................... 52


Ingravallo Gabriel – Entraigas Valeria Página: VII

Ejecutado ........................................................................................................ 54

Apéndice II: MANUAL DE USUARIO ____________________________________ 56

Formularios ........................................................................................... 56

Principal .......................................................................................................... 56

Parámetros ...................................................................................................... 57

Trazas ............................................................................................................. 57

Generación ...................................................................................................... 62

Reportes .......................................................................................................... 63

Información ..................................................................................................... 64

Requerimientos mínimos ....................................................................... 65

Instalación ............................................................................................ 66

Configuración ................................................................................................... 66

Inicio de la aplicación ........................................................................................ 66

Funciones del Administrador ................................................................. 68

Apéndice III: INCORPORACION DE NUEVOS DBMS ________________________ 69

Apéndice IV: PRUEBAS _____________________________________________ 70

Apéndice V: APLICACIONES DE PRUEBA ________________________________ 71

Calles ..................................................................................................... 71

Juguetería ............................................................................................. 73

Apéndice VI: TRIGGERS _____________________________________________ 76

Postgres ................................................................................................ 76

SQL Server ............................................................................................. 77

Apéndice VII: LEYES y DECRETOS _____________________________________ 78

Ley 25.326 - Protección de los datos personales ................................... 78

Decreto 1558/2001 - Reglamentación Ley 25.326 ................................. 90

Disposición 11/2006 - Dirección Nacional de Protección de Datos

Personales ............................................................................................. 99

GLOSARIO ______________________________________________________104

BIBLIOGRAFIA ___________________________________________________106


Ingravallo Gabriel – Entraigas Valeria Página: 1

Capítulo 1 INTRODUCCION

El término Auditoria según donde se esté aplicando puede tener diferentes

connotaciones. Una de ellas es “Proceso analítico que consiste en el examen de los libros,

cuentas, comprobantes y registros de una empresa con el objeto de precisar si son

correctos los estados financieros, de acuerdo con principios de contabilidad generalmente

aceptados”.

También podemos encontrar otras definiciones posibles como «un proceso

sistemático para obtener y evaluar de manera objetiva las evidencias relacionadas con

informes sobre actividades económicas y otros acontecimientos relacionados, cuyo fin

consiste en determinar el grado de correspondencia del contenido informativo con las

evidencias que le dieron origen, así como establecer si dichos informes se han elaborado

observando los principios establecidos para el caso»1.

Un elemento no tenido en cuenta en lo antes dicho es el aspecto tecnológico que ha

modificado sustancialmente la manera de procesar y por ende de evaluar toda esta

información generada. Es de este aspecto que se deriva puntualmente la Auditoria de los

Sistemas de Información o también llamadas Auditorias Informáticas.

Los términos anteriores involucran a sistemas automáticos de procesamiento,

procesamiento no automático y sus correspondiente interfaces, tal cual se expresa en

diferentes trabajos monográficos2.

Los sistemas automáticos de procesamiento son uno de los elementos que

intervienen en la auditoria y tienen dos grandes componentes que son el hardware y el

software. Si tomamos esta segunda opción y la explotamos, veremos nuevamente una

buena cantidad de temas a considerar.

1 La auditoria en el contexto actual. Catalina Rivas de las Casas - Gerente de Auditoria - Sucursal Ciudad Habana,

CIMEX, Cuba.

2 Auditoria de Sistemas. Carmen D'Sousa



Sin ser exhaustivos y con el solo ánimo de ser ejemplificadores podemos considerar

allí al Sistema Operativo como el puntapié inicial, a los DBMS, cualquiera sean ellos, a los

Sistemas de Comunicación y a los Sistemas de Aplicación en General.

Hasta aquí hemos presentado una serie de elementos que desarrollaremos en los

siguientes puntos y cuyo objetivo es permitir al profesional o estudiante del tema ir

avanzando desde los conceptos más simples hasta arribar a un software de auditoria sobre

bases de datos que maneja trazas de actividad.

Motivación

Es bien conocido o debería serlo por parte de los profesionales en Sistemas el

aspecto relevante del control interno en todas las áreas relacionadas a la informática y en

particular a los sistemas de información y al ciclo de vida de los mismos. Además de ello

hay que tener en cuenta que este se encuentra inmerso dentro de una organización en la

cual tiene sentido, ya que su objetivo es aportar al desarrollo de la misma, permitiéndole

alcanzar su finalidad empresarial a través del crecimiento administrativo, financiero y de

gestión.

En particular los datos manejados por un sistema de información de la organización

son el activo más importante en la toma de decisión para la consecución de los objetivos

brevemente planteados en el párrafo anterior. Y continuando con más detalle podemos

establecer que las operaciones que nos permiten su administración son las que determinan

su fiabilidad.

Ahora bien, el hecho de que esos datos y sus operaciones sean manipulados por

seres humanos les agrega una componente de error, voluntario o no, que implica un riesgo

para la organización.

Se desprende de aquí la necesidad de realizar Auditorias Informáticas y como parte

de ellas la de poder analizar trazas de actividad de los usuarios sobre los datos de las

aplicaciones. Tanto desde el punto de vista legal como desde el punto de vista de auditoria

es requerido que los sistemas de bases de datos puedan registrar la actividad sobre datos



claves, para posteriormente poder rastrear el momento y el usuario que ha realizado una

determinada modificación, incorporación o eliminación de datos.

Por tal, prevenir, evitar y/o restringir tales riesgos se convierte en una tarea y un

reto profesional difícil de relegar para aquellos que trabajamos cotidianamente con Bases de

Datos y nos interesa garantizar su integridad, confidencialidad y fiabilidad en el mayor

grado posible.

Por este motivo sería importante poder contar con herramientas integrales que sean

capaces de interactuar con diferentes gestores de bases de datos y que permitan definir que

datos se deben auditar permitiendo explotar la información de trazas de actividad de

manera fácil y segura.

Hay además de las distintas consideraciones hechas en los párrafos anteriores otras

que no tenemos que dejar de lado, tal es el hecho que actualmente en las organizaciones de

mediano a gran porte los datos aunque puedan estar administrados, están esparcidos en

diferentes bases de datos implementadas sobre diferentes gestores de datos, lo que implica

una dificultad a la hora de establecer controles sobre los mismos.

Si bien varios de los diferentes motores de bases de datos ofrecen como parte de su

funcionalidad una herramienta capaz de establecer trazas de auditoria para el seguimiento

de los cambios sobre un conjunto de datos previamente seleccionados mientras que otros

no las poseen, esto no alcanza para establecer un control total sobre los mismos.

Determinan si, una característica necesaria por no decir imprescindible a la hora de tener

que administrar datos que aunque estén reunidos en una base de datos se encuentran

dispersos respecto de otros con los cuales tienen relación pero que son manejados en otras

bases implementadas sobre otros motores de bases de datos. De allí que se presenta la

necesidad de contar con una única herramienta que permita interactuar de manera sencilla

con diferentes gestores de bases de datos a los cuales se pueda acceder de forma conjunta

y se les puedan definir, habilitar y deshabilitar mecanismos de control de datos y usuarios,

y se puedan realizar un estudio sobre las datos accedidos y/o modificados en forma

conjunta y la emisión de los reportes necesarios.



De todos lo antes expuesto podemos resumir que nuestro principal interés es contar

con una herramienta que nos permita cubrir tres aspectos relevantes a la hora de querer

administrar datos ubicados en diferentes bases de datos implementadas sobre distintos

gestores de datos:

� El mantenimiento de logs que registren la actividad de los usuarios (user

activity logs).

� El mantenimiento de logs que registren la modificación de los datos hecha por

los usuarios (data-changes logs).

� El análisis centralizado y global de los cambios realizados por los usuarios a los

datos en diferentes gestores de bases de datos.

Objetivos

Generales

� Realizar un estudio amplio del tema Auditoria como punto focal y función

relevante en el desarrollo de las organizaciones.

� Determinar y/o acotar la influencia de la tecnología informática en la Auditoria.

� Establecer el punto de interacción entre el profesional de sistemas informáticos

y aquellos otros intervinientes en una Auditoria.

� Establecer el/los elementos esenciales dentro de la Auditoria Informática.

� Establecer un mecanismo de control sobre los datos de la organización que

permita prevenir los riesgos de administración de los mismos.

� Diseñar un software independiente del gestor de bases de datos relacional que

permita administrar y analizar la actividad sobre tablas residentes en los

RDBMS mas utilizados en la región.

� Desarrollar una herramienta que permitirá definir la/s tabla/s y la/s columna/s

que se desean auditar y qué operaciones se desean auditar.



� Generar diferentes reportes para que un usuario autorizado pueda analizar los

activity logs.

Particulares

� Realizar un estudio de varios entornos de Base de Datos y sus capacidades de

registración de auditoria, como así también las posibilidades de conectividad

genérica y disparadores automáticos que permitan implementar activity logs.

� Establecer los mecanismos brindados por los distintos DBMS, existentes en el

mercado, que apoyen y/o permitan el control sobre un conjunto de datos

almacenados.

� Seleccionar un par de DBMS operativos en el mercado que sirvan de guías de

control de desarrollo.

� Modelizar una estrategia que permita registrar los cambios de los datos

almacenados en una Base de Datos.

� Desarrollar una herramienta de control que permita:

� seleccionar un conjunto de datos a controlar,

� especificar un conjunto de mecanismos de control de acceso a la

herramienta para su administración y reporting,

� reportar los cambios detectados en un período sobre un determinado

conjunto de datos.

Beneficiarios

El presente trabajo permite a quien lo aborde utilizar su ingenio y pericia para crear

mecanismos que realicen auditoria de cambios sobre los datos; de allí que los destinatarios

más beneficiados serán profesionales en sistemas y auditoria que requieran una

herramienta especifica y sencilla que les brinde la capacidad de registrar y controlar la

actividad de los usuarios sobre los cambios a datos.



Primarios

� permite a profesionales auditores trabajar sobre datos reales de una

organización y extrapolar información de manipulación de datos (acceso,

autorizados o no; inserción, modificación y/o eliminación) en distintos

administradores de bases de datos, de forma transparente y sencilla.

� ofrece a los DBA la capacidad de abstraerse de la definición y administración de

trazas de auditorias sobre diferentes RDBMS sin perder el control de conocer los

triggers generados, estén habilitados o no.

� permite a los DBA liberarse de las consideraciones de la plataforma sobre las

que residen los distintos motores de Bases de Datos y/o la red sobre las que

residen las distintas bases de datos sobre las que se definen las trazas de

actividad.

� permite a los desarrolladores de aplicaciones de bases de datos liberarse de la

implementación de complicados mecanismos de control de cambios de datos y

de generación de reportes para el análisis de los mismos.

� ofrece a Administradores de datos la facultad de generar políticas de control de

datos que pueden ser transformadas en mecanismos de control de datos en

forma sencilla, ejecutadas en forma inmediata y analizadas rápidamente para

evaluar su efectividad.

No obstante también puede ser utilizado por profesionales en general y estudiantes

para introducirse en los aspectos relevantes de la auditoria por ser un campo interesante en

si mismo.

Secundarios

� permite a docentes introducirse en el tema y profundizarlo, basándose en los

elementos presentados y en la bibliografía especificada utilizada por

profesionales, nacionales y extranjeros, que han encarado este mismo tema

desde diversas perspectivas. Además pueden utilizar el software desarrollado

como ejemplo guía de uno de los aspectos de la auditoria sobre Bases de Datos



� permite a alumnos de carreras informáticas conocer el tema de auditorias y

tener una guía sobre conexión a diferentes bases de datos algunos mecanismos

de control de datos

Alcances

Es interés de esta tesis plasmar un documento que sin ser exhaustivo sea una guía

para la introducción al estudio del tema de auditoria, en particular al de auditoria

informática y más puntualmente al estudio de auditoria en Bases de Datos en lo referente a

trazas de actividad generadas en el uso de datos sobre cualquier DBMS relacional.

Como carácter distintivo y para no solo quedarnos con una mera investigación del

tema nos propusimos dar un paso más, que no encontramos reflejado en el material que

estudiamos y que consideramos que facilita el trabajo del profesional auditor. Ese paso más

involucra la creación de una herramienta que le permite al auditor crear diferentes trazas de

actividad sobre diferentes RDBMS comerciales y no comerciales que interactúan en forma

conjunta en una organización y almacenar los activity logs en una base de auditoria. Esta

herramienta reúne en uno único aplicativo la conexión a diferentes RDBMS, el acceso a sus

datos, el almacenamiento de aquellos datos que cumplen con la definición de diferentes

controles sobre ellos y la posterior evaluación de los mismos por parte del profesional.

La herramienta ha pretendido ser lo suficientemente modular como para ir

incorporando cualquier RDBMS no considerado hasta el presente mediante un conjunto de

pasos puntuales pero conocidos por un profesional especializado o con conocimientos

avanzados en Bases de Datos.



Capítulo 2 FUNDAMENTACION TEORICA

Auditoria

Retomamos los párrafos iniciales vertidos en la introducción de la presente para

describirlos, ampliarlos y dejar al lector algunas premisas sobre el tema.

Definición

Según Piattini es la actividad consistente en la emisión de una opinión profesional

sobre si el objeto sometido a análisis presenta adecuadamente la realidad que pretende

reflejar y/o cumple con las condiciones que le han sido prescritas.

Objetivo

Al estudiar, analizar diferentes definiciones dadas por la mayoría de los autores

dedicados al tema tanto como las definiciones vertidas en diferentes trabajos y habiendo

observado diferentes documentos donde se plasman los resultados de auditorias llegamos a

la conclusión que se destacan dos objetivos fundamentales:

� La verificación de la fiabilidad de los elementos auditados respecto de los

hechos que le dieron origen.

� La calidad de la información auditada.

Clases de Auditoria

Diferentes autores coinciden en afirmar que se pueden distinguir diferentes clases de

auditorias, clasificándolas de acuerdo a:

� personal que la desempeña

� objeto de análisis

� profundidad del análisis

� frecuencia del análisis



A su vez la clasificación enumerada anteriormente la podemos subclasificar en:

� personal que la desempeña

� Auditoria Interna

� Auditoria Externa

� objeto de análisis

� Auditoria de Gestión

� Auditoria Operativa

� Auditoria Financiera

� Auditoria Contable

� Auditoria Informática

� profundidad del análisis

� Auditoria Total

� Auditoria Parcial

� frecuencia del análisis

� Auditoria Continua

� Auditoria Ocasional

Control Interno versus Auditoria Interna

Control Interno: es un sistema que interrelaciona controles financieros,

administrativos, contables, etc. ideados y puestos en práctica por los directivos de la

organización con el objetivo de que su gestión sea ordenada, sus activos sean preservados

y sus registros sean correctos. Su desventaja es que no garantiza una administración

eficiente ni evita el fraude dado por la complicidad entre los directivos con cargos de

confianza.



Auditoria Interna: es la actividad dedicada a realizar una revisión de operaciones

contables, financieras, operativas, etc., aplicadas por la gerencia de la empresa con el

objetivo de evaluar la eficacia del control interno. Es desempeñada por un departamento

dependiente directamente de la gerencia de la empresa, con un staff ubicado en la

estructura jerárquica del organigrama.

Auditoria y su Marco Legal

Ley de Protección de Datos Personales

Dentro de la Republica Argentina se ha promulgado la ley 25326 denominada Ley de

Protección de los Datos Personales. Esta ley establece en su artículo 93 las condiciones que

sobre seguridad y confidencialidad deben cumplir cualquier registración pública o privada de

datos y la prohibición de realizar registraciones que no las cumplan.

Se fijo también en el artículo 29 el órgano de control que se encargará del

cumplimiento de la presente ley y su reglamentación establecida como Decreto 1558/20014.

Sanciones previstas por Ley

Además se establecen en la misma ley mediante el artículo 32 sanciones penales que

se incluyen en el Código Penal en los artículos 117 bis y 157 bis. Este último habla sobre la

pena de un mes a dos años cuando se viole la confidencialidad y/o seguridad de los datos.

Órgano de Control

Tal órgano es denominado Dirección Nacional de Protección de Datos Personales

(DNPDP) y se encuentra en la orbita del Ministerio de Justicia y Derechos Humanos y su

titular es nombrado directamente por el Presidente de la Nación en acuerdo con el Senado

tal como lo especifica el inciso 2 y 3 del artículo 29.

3 Apéndice VII – Leyes y Decretos – Ley 25.326 4 Apéndice VII – Leyes y Decretos – Decreto 1558/2001



La DNPDP ha emitido en el mes de septiembre del año 2006 la Disposición Nº 11 en

la que mediante su artículo 1 aprueba las “Medidas de Seguridad para el Tratamiento y

Conservación de los Datos Personales Contenidos en Archivos, Registros, Bancos y Bases de

Datos Públicos no estatales y Privados”5.

En el anexo I de esta disposición se clasifican en tres niveles los datos registrados en

bases de datos no estatales y privadas. Específicamente consideramos las descriptas como

Medidas de Nivel Medio en los puntos 1 y 2 que hablan sobre auditorias internas y

externas.

Ley de Control interno y Auditoria

Contribuyendo al conjunto de leyes emitidas en el país, existe también la ley 24.156

denominada Ley de Administración Financiera y de los Sistemas de Control del Sector

Público Nacional que es una modificación de la ley 23.354, Ley de Contabilidad y que tal

como dice en su artículo 1: “establece y regula la administración financiera y los Sistemas

de Control del Sector Público Nacional”. En particular nosotros nos enfocamos en los

sistemas de control que están específicamente determinados en su artículo 3 y en los

objetivos que persigue esta ley, específicamente en el enunciado en su articulo 4 inciso d

subinciso ii y en el inciso e.

Tales sistemas de control son llevados a cabo por dos estructuras denominadas

Sindicatura General de la Nación dependiente directamente del Presidente y la Auditoria

General de la Nación dependiente del Congreso Nacional. Cada una de ellas se encarga del

sistema de control interno y del sistema de control externo respectivamente. Todo esto se

haya especificado en el articulo 7 de la ley.

El detalle del Sistema de Control Interno se haya especificado en esta ley dentro del

título VI, en los artículos 96 al 115. Puntualmente en los artículos 101 y 102 establece y

define el concepto de Auditoria Interna y de las unidades de auditoria interna que las

llevarán a cabo.

5 Apéndice VII – Leyes y Decretos – Disposición 11/2006



El detalle del Sistema de Control Externo se haya especificado en esta ley dentro del

título VII, en los artículos 116 al 131.

La Sindicatura General de la Nación ha establecido un conjunto de Normas de Control

Interno para Tecnologías de Información que deben ser puestas en práctica por los

organismos del sector público siguiendo el objetivo de la ley 24.156.

Auditoria y Sistemas de Información

Auditoria Informática

Las siguientes son varias definiciones expresadas en los apuntes de Coltell:

Norma ANSI N45.2.10.1973:

Actividad para determinar por medio de la investigación, la adecuación de y la

adhesión a, los procedimientos establecidos, instrucciones, especificaciones, códigos y

estándares, u otros requisitos aplicables contractuales o de licencia, así como la eficacia de

su implantación.

P. van der Ghinst - CEGOS.

Conjunto de técnicas y actividades destinadas .a analizar, evaluar, verificar y

recomendar sobre el control, la planificación, la adecuación, eficacia y seguridad de la

función informática de la Empresa.

Examen discontinuo de un sistema informático, o del servicio informático, a petición

de su dirección. Para mejorar la calidad, la seguridad y la eficacia.

Acha Iturmendi J.J. Auditoria Informática en la Empresa:

Conjunto de procedimientos y técnicas para evaluar y controlar total o parcialmente

un Sistema Informático, con el fin de proteger sus activos y recursos, verificar si sus

actividades se desarrollan eficientemente y de acuerdo con la normativa informática y



general existentes en cada empresa, y para conseguir la eficiencia exigida en el marco de la

organización correspondiente.

Alonso Rivas G. Auditoria Informática:

Es un examen metódico del servicio informático, o de un sistema informático en

particular, realizado de una forma puntual y de modo discontinuo, a instancias de la

Dirección, con la intención de ayudar a mejorar conceptos como la seguridad, la eficacia, y

la rentabilidad del servicio, o del sistema, que resultan auditados.

Weber R. EDP Auditing. Conceptual Foundations and Practice:

Es el proceso de reunir y evaluar evidencia para determinar si un sistema informático

protege su patrimonio, mantiene la integridad de los datos, alcanza los objetivos de la

organización con efectividad, y consume los recursos con eficiencia.

Control Interno Informático

El control interno y la auditoria son facetas que nos son conocidas en general en

otros ambientes, tales como en el ámbito contable y/o en el financiero pero no lo son tanto

en el informático dada la relativa corta vida de esta disciplina. Y mucho menos lo son

teniendo en cuenta que algunos componentes tecnológicos actuales que permiten el

almacenamiento, procesamiento y administración de los datos se han desarrollado hace no

mas de veinte o treinta años y solo han alcanzado su masificación en estos últimos veinte

años, con lo que han permitido una evolución del software gradual pero acelerada. Esa

misma evolución es la que ha proporcionado distintos mecanismos para agrupar, compartir

y asegurar la consistencia y baja redundancia de los datos de una organización.

Es a partir de conseguir estos objetivos que anteriormente eran críticos para esa

misma organización es que comenzó a surgir la necesidad de verificar y controlar la validez,

integridad y seguridad de los datos acumulados como así también de las operaciones que

los manipulan.



Componentes auditables

� Auditoria Física

� Auditoria Ofimática

� Auditoria de la Dirección

� Auditoria de la Explotación

� Auditoria del Desarrollo

� Auditoria del Mantenimiento

� Auditoria de Bases de datos

� Auditoria de técnicas de Sistemas

� Auditoria de Calidad

� auditorias de la Seguridad

� Auditoria de Redes

� Auditoria de Aplicaciones

Posibles problemas

Es bien conocido o debería serlo por parte de los profesionales en Sistemas el

aspecto relevante del control interno en todas las áreas relacionadas a la informática y en

particular a los sistemas de información y al ciclo de vida de los mismos. Además de ello

hay que tener en cuenta que este se encuentra inmerso dentro de una organización en la

cual tiene sentido, ya que su objetivo es aportar al desarrollo de la misma, permitiéndole

alcanzar su finalidad empresarial a través del crecimiento administrativo, financiero y de

gestión.



En particular los datos manejados por un sistema de información de la organización

son el activo más importante en la toma de decisión para la consecución de los objetivos

brevemente planteados en el párrafo anterior. Y continuando con más detalle podemos

establecer que las operaciones que nos permiten su administración son las que determinan

su fiabilidad.

Ahora bien, el hecho de que esos datos y sus operaciones sean manipulados por

seres humanos les agrega una componente de error, voluntario o no, que implica un riesgo

para la organización.

Se desprende de aquí la necesidad de realizar Auditorias Informáticas y como parte

de ellas la de poder analizar trazas de actividad de los usuarios sobre los datos de las

aplicaciones.

El Auditor Informático

Existen aspectos contrapuestos entre los auditores actuales que quieren

desempeñarse dentro de la auditoria informática ya que los auditores dedicados a la

auditoria financiera y/o contable que poseen amplia experiencia en esas áreas no la poseen

en tecnologías de información, debido a que estas no se hallaban presentes en su formación

básica mientras que los profesionales informáticos adolecen de materias cuyos contenidos

contengan temas sobre organización, planificación y administración de recursos como

tampoco de técnicas de auditoria de administración de datos.

Además estos últimos tampoco podrían auditar cualquier tipo de sistema de

información dado que su variedad junto a las diferentes tecnologías que los pueden integrar

hacen difícil que un mismo profesional pueda especializarse en todas ellas.



Sistemas de Bases de Datos Auditables

Objetivos de la auditoria en DB

Tanto el control interno como la auditoria empezaron a prosperar en la informática

pero especializándose en ella teniendo en cuenta no tanto el concepto y/o objetivo de la

función sino el objeto que se controla o audita, el Sistema de Información y sus

componentes. En nuestro caso las Bases de Datos y los DBMS utilizados. Haciendo alusión

al primero, tendríamos que considerar la recolección de trazas de auditoria que es vital para

la tarea del auditor o el perito y está soportada nativamente solo por algunos gestores de

bases de datos.

Aquí entra en consideración el segundo elemento enunciado anteriormente, los

cuales contienen diferentes criterios de registración y organización de la información

recogida a través de las trazas. En este sentido, no se conocen soluciones integrales que

sean capaces de interactuar con cualquier gestor de bases de datos relacional y que

permitan definir el mundo de cambios a auditar. Eso hace que los auditores deban

seleccionar diferentes soluciones dependiendo de la infraestructura de datos del modelo

auditado.

Tanto desde el punto de vista legal como desde el punto de vista de auditoria es

requerido que los sistemas de bases de datos puedan registrar la actividad sobre datos

claves, para posteriormente poder rastrear el momento y el usuario que ha realizado una

determinada modificación, incorporación o eliminación de datos.

Por tal, prevenir, evitar y/o restringir tales riesgos se convierte en una tarea y un

reto profesional difícil de relegar para aquellos que trabajamos cotidianamente con Bases de

Datos y nos interesa garantizar su integridad, confidencialidad y fiabilidad en el mayor

grado posible.

Por este motivo sería importante poder contar con herramientas integrales que sean

capaces de interactuar con diferentes gestores de bases de datos y que permitan definir que



datos se deben auditar permitiendo explotar la información de trazas de actividad de

manera fácil y segura.

Capas auditables

� DBMS, componentes auditables

� políticas de administración de datos

� políticas de actualización del soft

� políticas de tuning

� Bases de Datos, componentes auditables:

� esquemas

� bases

� tablas

� restricciones

Estos últimos componentes son objeto del estudio y desarrollo de la presente tesis.



Capítulo 3 INVESTIGACION DE ACTIVITY LOGS EN

DIFERENTES DBMS

En nuestras investigaciones sobre páginas oficiales sobre distintos DBMS comerciales

y no comerciales hemos encontrado que algunos de ellos hacen referencia a algunas

herramientas que permiten un cierto grado de auditoria informática sobre los cambios de

datos mientras que otras no presentan ninguna descripción especifica sobre el tratamiento

de modificación sobre los datos.

Tal es el caso de Oracle en su versión 8 y el motor DB2 que presentan logs donde se

registran información de cambios de datos mientras que no ocurre lo mismo para MySQL e

Informix.

Oracle

Aquí existe un log donde se registran distintas clases de información clasificada por

tipo, uno de esos tipos especifica el control de cambio de datos. Cabe expresar que a

nuestra opinión el sistema de registración y consulta se vuelve complejo para cualquier

persona que no sea un profesional informático con conocimiento de mecanismos de

consultas que le permita entender la información registrada y volcarla en un reporte

inteligible.

DB2

En este caso es más sencillo en cuanto que posee una herramienta especifica

llamada DB2 Log Analysis Tool for z/OS V2.3 que permite un control completo sobre la

integridad de datos, monitoreo de cambios de datos y construcción automática de reportes

de cambios. Estos reportes pueden ser implementados sobre diferentes criterios tales como

fecha, usuario o tabla. Además permite aislar cambios accidentales y no deseados.



SQLServer

Tanto SQL Server en su versión 2000 como en la versión 2005 ofrece la posibilidad

de crear las trazas por medio de procedimientos almacenados de sistemas denominado

Transact-SQL o por medio de una herramienta del entorno del DBMS denominada SQL

Server Profiler en la versión 2005 y Analizer en la versión 2000.6

Transact-SQL puede ser utilizado dentro de una aplicación para crear trazas

manualmente.

SQL Server Profiler permite ver como se resuelven las consultas internamente por

parte del motor. Entre sus funciones esta:

� crear una traza;

� observar el resultado de la ejecución de una traza;

� almacenar el resultado de una traza en una tabla;

� iniciar, parar, pausar y modificar los resultados de una traza;

� reejecutar una traza;

En la versión 2005 una consideración a tener en cuenta es que el tamaño del

resultado de una traza no debe superar el Gigabyte porque produce un error y entonces

trunca la salida resultante.7

Postgres

Permite realizar trazas de actividad denominadas trazas dinámicas. Para ello utiliza

en alguna versiones el utilitario DTrace, disponible en Solaris Express y Solaris 10+. Según

documentación de la página oficial se espera que esta esté disponible en próximas versiones

en FreBSD y en Mac OS X.

No obstante se puede realizar trazas dinámicas cambiando las definiciones de la

macro PG_TRACE incluidas en el archivo src/include/pg_trace.h.

6 Datos extraidos de:www.msdn2.microsoft.com/en-us/library/bb418499.aspx

7 Datos extraidos de:www.msdn2.microsoft.com/en-us/library/ms187929.aspx



Posee un conjunto de puntos de traza predefinidos que están inicialmente

deshabilitados por defecto y deben ser habilitados en el script de configuración para que la

información este disponible en Postgresql. Se lo hace mediante el comando:

--enable-dtrace

También para trabajar con el programa dtrace se requiere setear la variable de

ambiente DTrace para encontrar su ubicación y para pasarle opciones adicionales se debe

setear la variable de ambiente DTRACEFLAGS.

Por ejemplo utilizando el compilador GCC con soporte para 64 bits sería:

./configure CC='gcc -m64' --enable-dtrace DTRACEFLAGS='-64' ...

Requiere de conocimientos previos de uso y definición de puntos de traza. Estos

últimos se pueden definir en el código a través de macros de traza.

Existen dos mecanismos para definición de un punto de traza:

� con una macro: PG_TRACE (my__new__trace__point);

� con una macro y con tres variables de inspección PG_TRACEn: PG_TRACE3

(my__complex__event, varX, varY, varZ);8

MySQL

No posee en la página oficial ninguna referencia al control de cambios y manejo de

trazas de auditoría.

Informix

No posee en la página oficial ninguna referencia al control de cambios y manejo de

trazas de auditoría.

8 Datos extraidos de: www.postgresql.org/docs/8.2/static/dynamic-trace.html



Mecanismos de conexión y Triggers

Es destacable mencionar que todos los motores investigados ofrecían al menos un

mecanismo de conexión relativamente sencillo desde el punto de vista de la programación,

que nos permitió establecer una serie de parámetros genéricos para enlazarnos con las

bases. Sucedió lo mismo cuando profundizamos en el tema de los triggers (disparadores),

ya que la estructura general y la forma de manejarlos es similar.



Capítulo 4 CARACTERIZACION DE LA HERRAMIENTA

En este punto es relevante para el presente proyecto descender desde los estadios

eminentemente teóricos con sus consabidas abstracciones, fundamentaciones e ideales a un

punto que nos acerque a las bondades del producto que hemos desarrollado y que

detallaremos en la siguiente sección.

Es así que partimos de destacar una de las características más distintivas del

trabajo: libertad de entorno, autoconfiguración de administradores de datos, registración de

actividad centralizada, almacenamiento descentralizado, control post-creación centralizado,

análisis centralizado de cambios, seguridad de cambios, libertad de aplicación, no intrusivo,

extensible.

Libertad de entorno

Gava, tal como hemos denominado nuestra herramienta no esta unida a ningún

DBMS relacional en particular sino que trabaja con cualquiera de ellos y con todos a la vez si

es necesario y siempre que las componentes de configuración estén actualizadas. Esto es se

identifique puntualmente cada uno de los administradores sobre los cuales se desean crear

trazas de auditoria.

Autoconfiguración de Administradores de Datos

Cualquier servidor que se una a la LAN será automáticamente reconocido e

incorporado a la lista de servidores siempre que en ellos se halle instalado algún DBMS. A

partir de allí se identificará todos las Bases de Datos y/o Esquemas creados con ese

administrador.



Registración de actividad centralizada

La capacidad de libertad de entorno agrega una nueva capacidad que implica la

posibilidad de unificar en un único componente la definición de todas las trazas de actividad

de usuarios necesarias para el control de un conjunto de datos y/o operaciones y la

asociación de ellas a alguno de los administradores predefinidos.

Almacenamiento descentralizado

La definición de los scripts de todas las trazas de auditoria creadas pueden ser

almacenadas en cualquier repositorio donde el administrador considere conveniente por

cuestiones de seguridad, performance y capacidad de almacenamiento.

Control Post-creación centralizado

La consulta, deshabilitación y/o eliminación de las trazas creadas son accedidas por

el auditor en forma sencilla.

Análisis centralizado de cambios

Gava posee un conjunto de filtros predefinidos que permiten extraer información

mediante reportes que seleccionan valores característicos que desea controlar el auditor.

Los mismos se hallan almacenados en la base de datos Auditoria.

Seguridad de cambios

Toda traza es controlada por el acceso de seguridad de su creador.



Libertad de Aplicación

Gava no requiere que ninguna aplicación de base de datos defina en si misma ningún

mecanismo de control para poder establecer una traza de auditoria sobre los datos que ella

manipula.

No Intrusivo

La lógica de registración de cambios agregada por GAVA no afecta el normal

funcionamiento de las aplicaciones que manejen los datos auditados.

Extensible

Si bien GAVA en su versión original permite configurar auditoria de cambios sobre un

par de gestores de bases de datos, su diseño abierto y su orientación a componentes

permite extender su funcionalidad agregando “cartuchos” programables que soporten la

conexión a cualquier gestor de bases de datos que se pueda conectar vía controles ADO

(Visual Basic utiliza ADO para crear conexiones).



Capítulo 5 DESARROLLO

Introducción

Ya fundamentada la importancia de la auditoria, entonces encontramos útil

desarrollar un una herramienta que sirva de apoyo para el seguimiento de actualización de

datos y de los usuarios. El sistema logra independizar al usuario de los informáticos. El

objetivo más importante que busca el sistema es poder hacer un seguimiento de

modificación de datos. Este seguimiento se logra en función de los reportes que se puedan

generar a través de los datos que se han ido guardando en las distintas bases en

consecuencia de las acciones realizadas de los usuarios finales de los sistemas, que

actualizan datos sobre las tablas de las bases a las cuales se les aplico un activity log.

Reporte



Los componentes mínimos del sistema son: la aplicación y la Base de Datos de SQL

Server. Esta base de datos es la que guarda información sobre las trazas que han sido

configuradas por el auditor. Por otro lado en cada servidor de DBMS que se requiera realizar

auditorias, es necesario crear una Base de Datos (Auditorias) donde se guarde el registro

de cada cambio sobre los datos.

Servidor Servidor ServidorPostgres SQL SQL Server MySQL Otros

Gava

config. de

trazas

Reporte

BasesAuditadas

BasesAuditadas

BasesAuditadas

BasesAuditadas



Descripción del producto desarrollado

GAVA es un sistema especialmente diseñado para mantener y administrar logs de

actividad de usuarios y cambios de datos. Analiza de manera centralizada y global esos

cambios y controla al usuario que tuvo acceso. Todo ello en un marco de múltiple gestores

de Bases de Datos.

� Está desarrollado en Visual Basic 6.0 y SQL Server 2000.

� Posee mecanismos de seguridad.

� Permite realizar las funciones con mínimo esfuerzo.

� Permite analizar datos estadísticos desde distintos puntos de vista.

� Es fácil de usar.

Descripción del funcionamiento

El funcionamiento se puede describir en cuatro grandes etapas que se describen a

continuación;

� 1ra. Etapa: Generación de la traza.9

El usuario debe brindarle información básica al sistema para poder general la traza.

Ellas son: el servidor, la base, el esquema, la tabla, los campos, la operación sobre la cual

se necesita auditar, entre otros.

� 2da. Etapa: Generación del script10

Una vez que la traza tiene todos los datos y puede ser guardada, ya esta en

condiciones de generar el script en función de los datos ingresados. Para ello se le pide al

usuario el lugar donde se debe dejar el script.

� 3da. Etapa: Ejecución del script en la base.

9 Apéndice II: Manual de usuario - Trazas

10 Apéndice II: Manual de usuario - Trazas, Generación



Queda en manos del administrador de Base de Datos ejecutar el script en la base

indicada para poder comenzar la recolección de datos.

� 4 ta. Etapa: Generación de reportes.

Luego de un tiempo, cuando los datos ya han tenido modificaciones se pueden

comenzar a generar reportes sobre los cambios o los seguimientos de los usuarios.



Arquitectura GAVA

Reporte

BasesAuditadas

BasesAuditadas

BasesAuditadas

CLIENTE

Aplicación GAVA

Formularios

Módulos

Módulosde clase

Tablas

Proc

Repositorio GAVA

AuditoriaAuditoriaAuditoria

BasesAuditadas

Auditoria



Funciones de Negocio11

En cumplimiento de los requisitos funcionales, el sistema permite realizar las

siguientes tareas:

� Permite configurar diferentes orígenes de datos

� Permite configurar las tablas y columnas sobre las cuales se desea rastrear

cambios.

� Lleva un control sobre los distintos triggers que se crearon en las bases

� Permite generar triggers de forma fácil

� Permite ver las distintas bases en los distintos servidores de distintos DBMS

� Permite ver la estructura de las tablas en la base

� Permite generar reportes con una amplia variedad de criterios.12

11 Apéndice II: Manual de usuario- Trazas 12 Apéndice II: Manual de usuario- Reportes



Solución

Variantes en el diseño de la solución

Diseño de formularios.

Presupusimos que los datos(nombre, descripción, tipo de servidor, servidor, usuario,

contraseña, base de datos, tablas, campos y operación a auditar.) necesarios para crear

trazas en los distintos motores. Al investigar sobre los motores nos dimos cuenta de que era

necesario hacer cambios del diseño para poder pedir el esquema en el case de Postgres.

Elección de la herramienta para mostrar la información.

Primeramente pensamos en diseñar un reporte en Crystal Report, una herramienta

ampliamente difundida y utilizada. Luego de ver las herramientas de Visual Basic,

recordamos que tenia un diseñador de reportes incorporada, Data Report.

Entender la estructura de DBMS

SQL Server, maneja el concepto de bases de datos mientras que Postgres maneja el

concepto de bases de datos y esquemas. Este ultimo utiliza los esquemas dentro de las

bases con el fin de organizar lógicamente su estructura. El beneficio de manejar esquemas

es que los usuarios pueden trabajar sin interferirse entre si, y por otro, se mantiene una

sola conexión desde la aplicación que permite manejarse por todos los esquemas.

Cadena de conexión.

Dada la experiencia que tenemos con programas desarrollados en Visual Basic y SQL

Server, la creación de la cadena de conexión entre el entorno de desarrollo y el motor de

Base de Datos no nos llevo tiempo. Ahora desconocíamos como seria la forma de

relacionarnos con un motor nuevo como Postgres. Presupusimos que era de la misma

manera. Esto nos llevo a tener que investigar la estructura y los componentes que maneja

Postgres. Esta estructura es similar en algunos puntos a SQL Server, solo que Postgres

además de manejar lo mismo que SQL Server, maneja el concepto de esquema. Una vez



entendido esto, pudimos armar la conexión. Cada vez que necesitábamos conectarnos a

postgres, nos conectábamos a un servidor y una base, mientras que para hacer consultas

sobre los distintos objetos debían anteponer al objeto, el esquema al que pertenecía.

Forma de obtener los objetos de la base de datos.

Presupusimos que tanto SQL como Postgres tenían información sobre su catalogo de

manera accesible desde una aplicación. Y así fue, SQL tiene información que la brinda

mediante los procedimientos almacenados de sistema y Postgres posee tablas de sistema

de las cuales se extrae la información sobre su catalogo.

En el caso de SQL Server, encontramos una definición de variable

‘SQLDMO.Application’ que nos permitía listar los servidores de SQL Server que se

encontraban conectados a la red donde estaba la aplicación. Una vez seleccionado el

servidor, encontramos también otra definición de variable ‘SQLDMO.SQLServer’ la cual se

conectaba al servidor y a través de ella podíamos ver las bases del servidor, las tablas, los

campos, los usuarios, los triggers, los procedimientos almacenados y todo sobre el servidor.

En cambio Postgres posee en su catalogo tablas donde almacena información sobre

los objetos. Entonces, una vez establecida la cadena de conexión invocábamos a estas

tablas solicitando información sobre los componentes.

Forma de armar las consultas con fechas.

Conocíamos la forma de armar una consulta con SQL Server con fechas. Nos

encontramos con la dificultad de que para Postgres no era la de la misma manera.

Entonces nos quedo de la siguiente forma:

SQL Server

cadena = cadena & " and Fecha between '" & dtpDesde.Value & "' and '" &

dtpHasta.Value & "'"

Postgres

cadena = cadena & " and Fecha > '" & dtpDesde.Year & "-" & dtpDesde.Month & "-"

& dtpDesde.Day & "'"



cadena = cadena & " and Fecha < '" & dtpHasta.Year & "-" & dtpHasta.Month & "-" &

dtpHasta.Day & "'"

Sintaxis de creación de los trigger.

Ya conocíamos el funcionamiento de los triggers en SQL Server, tuvimos que

investigación los triggers en postgres. Llegamos a la conclusión de que debía especificarse

una componente mas, no presente en el anterior.

En SQL Server la creación de una traza se resume en la modificación de la estructura

de una tabla. El trigger contiene la/s sentencia/s que se deben ejecutar cuando se realiza la

operación que se intenta auditar. Por el contrario, para Postgres es una modificación de la

estructura de la tabla mas la creación de una función de tipo trigger. Esta función contiene

la/s sentencia/s que se ejecutarían cuando se realiza la operación que se intenta auditar.

Por lo tanto la generación del script para los DBMS era distinta.



Solución de la creación de trazas

Es importante destacar que en el caso de SQL Server definimos dos variables que

utilizamos a lo largo de la creación de las trazas que nos permitieron obtener información

sobre los servidores y estructura lógica de cada uno. Las variables son de tipo:

A- SQLDMO.Application para realizar una inspección sobre los servidores

conectados,

B- SQLDMO.SQLServer, para poder obtener información de la estructura del servidor

seleccionado

En el caso de Postgres invocamos a objetos del sistema para obtener información

sobre la estructura lógica de cada base y esquema en particular.

A continuación se definen los pasos para crear una traza y por cada tarea, si esta tiene una

complicación extra, entonces describimos la manera de obtener los datos:

1- Solicitud de datos de la traza

a. Solicitud de nombre

b. Solicitud de descripción

c. Solicitud de tipo de servidor

i. Por medio de la invocación del método Recuperar en el módulo

cclTipoServidor obtuvimos todos los DMBS de los cuales se pueden

generar trazas.

2- Solicitud de datos de conexión

a. Solicitud del servidor

i. Selección de servidores

1. SQL Server: por medio de la variable A obtuvimos la lista de

servidores conectados a la PC. El método para realizar esto fue

ListAvailableSQLServers

2. Postgres: se debe escribir el servidor al cual se desea

conectar.

b. Solicitud de usuario

c. Solicitud de contraseña

Una vez que se obtuvo una conexión satisfactoria, a la variable B se le setea la

conexión, así de ahora en mas por medio de sus propiedades podemos obtener el conjunto

de datos lógicos que iremos necesitando a media que incorporamos datos.

3- Solicitud de datos lógicos y operación a auditar



a. Solicitud de la base a Auditar

i. SQL Server: la variable B posee un método que devuelve una

colección de bases de datos relacionadas al servidor, este método es

Database.

ii. Postgres: invocamos a un objeto llamado pg_database, el cual nos da

la lista de bases de un servidor.

b. Solicitud del esquema, solo para el caso de postgres

i. Postgres: invocamos a un objeto llamado

information_schema.columns, el cual nos da la lista de esquemas de

una base en particular.

c. Solicitud de tablas

i. SQL Server: la variable B posee un método que devuelve una

colección de tablas relacionadas a una base en particular, este método

es Database.

ii. Postgres: invocamos a un objeto llamado

information_schema.columns, el cual nos da la lista tablas de un

esquema en particular.

d. Solicitud de operación

e. Solicitud de campos

i. SQL Server: utilizamos el método Database para poder obtener un

objeto de base de datos en particular. Este nuevo objeto posee

métodos por los cuales se puede obtener información de los objetos de

esa base en particular. El método en particular que utilizamos fue

Tables, y en su llamada le indicamos la tabla de la cual necesitábamos

recuperar información.

ii. Postgres: invocamos a un objeto llamado

information_schema.columns, pasándole por parámetro el esquema y

la tabla de la cual necesitábamos información.

4- Solicitud de datos para la generación del script

a. Solicitud del nombre del archivo

b. Solicitud de la ubicación del archivo



Solución de diseño

El proyecto se compone de dos partes, el proyecto en Visual Basic y la base de datos en

SQL Server. Las dos componentes antes mencionadas se organizaron de tal forma que

queden ordenadas lógicamente y modularizadas. El proyecto se compone de formularios,

módulos y módulos de clase, mientras que la base de datos se compone de tablas y

procedimientos para acceder a ellas. A continuación se detallan todas las componentes:

Componentes del proyecto en Visual Basic:

Formularios frmAbout

frmAltaTrazas

frmElimiarTraza

frmHabilitacionTrazas

frmLogin

frmParametros

frmPrincipal

frmRegeneracionScriptAlta

frmReporteGeneral

frmSplash

frmTrazaPostgres

frmTrazaSQLSever

frmUbicacionScriptAlta

frmUbicacionScripEliminacion

frmVerTraza

Módulos Funciones

Variables



Módulos de clase cclCampos

cclObjetoGenerico

cclTipoServidor

cclTrigger

clsAplicacion

clsCampo

clsObjetoGenerico

clsTipoServidor

clsTrigger

Componentes en la base de datos GAVA:

Tablas TColumna

TColumna

TTipoServidor

Ttraza

Procedimientos almacenados pColumnaAgregar

pColumnaRecuperar

pOperacionListar

pTipoServidorListar

pTipoServidorRecuperar

pTrazaAgregar

pTrazaEliminar

pTrazaModificar

pTrazaRecuperarTodos

pTrazaRecuperarUno



Estructura del Sistema

Diseño

Lista de eventos que se pueden disparar:

� El auditor genera una traza

� El auditor solicita reportes

Modelado de Datos

Modelo Funcional

Este modelo realiza un diagrama de las operaciones más importantes indicando que

tablas de la base de datos se ven involucradas y que entidades solicitan el cambio en el

sistema.

Notación:

Entidad

Almacenes de la base



� generación de trazas

Actualizacióntrazas

ColumnasTrazas

Auditor Tipo de servidor1

4

3

2

1- El auditor brinda información sobre las trazas, entre los datos están: el

nombre de la traza, una breve descripción, el tipo de servidor, nombre del

servidor, usuario, contraseña, Base de Datos, nombre de la tabla, campos

de los cuales se requiere guardar información, operación a auditar,

nombre del archivo a generar y lugar donde se deja el archivo que

contiene el script

2- Brinda información sobre las trazas existentes13

3- Retorna los tipos de DBMS existentes para poder seleccionar alguno

4- Guarda las columnas a auditar de las distintas tablas

� generación de reportes

GenerarReporte

Auditor

Trazas

Tipo de servidor

2

1 3

1- El auditor da los criterios con los cuales se va a generar el reporte

2- Brinda información sobre las trazas existentes

3- Brinda información sobre Tipos de DBMS existentes

13 Apéndice II: Manual de usuario- Trazas – Ver Trazas



Interface con el usuario

Existen dos tipos de pantallas a describir el funcionamiento general:

� Pantalla principal, posee una barra superior y una barra inferior. La barra

superior contiene todas las actividades que se pueden realizar en el sistema,

agrupadas por características comunes. También posee botones los cuales se

reservaron para las tareas mas frecuentes. Y por ultimo, en la parte inferior de

la pantalla se encuentra información sobre la conexión, usuario conectado,

servidor y Base de Datos a la cual se conecta y la fecha actual.14

� Pantallas de trabajo, todas las pantallas de trabajo contienen en la parte

superior una X para poder salir, en la parte inferior una pequeño descripción de

la tarea a realizar y un botón salir o cancelar para terminar la operación.

14 Apéndice II: Manual de usuario- Formularios-Principal



Bases de datos

La aplicación GAVA se sustenta con una base de datos principal y bases alternativas,

una en cada los distintos servidores de DBMS. La base GAVA se utiliza para almacenar

información sobre las trazas que se generan, mientras que las bases de auditorias, se utiliza

como repositorio de las acciones generadas por los usuarios. Las bases se describen a

continuación, comenzando por GAVA y luego Auditoria.

GAVA

Consta de una tabla principal donde se almacena información de las trazas y dos

tablas que dependen de ella. Tipo de servidor que guarda los tipos de servidores que

soporta la aplicación y columna que almacena información sobre los campos a auditar en

una traza en particular. Primero se muestra un diagrama general de la base y luego se hace

una breve descripción de las tablas y los campos de cada una.



Esquema general

Tablas

� Parámetros: guarda información de conexión con la base de datos GAVA y esta

relacionada con el archivo de configuración .ini.

� tTraza: guarda información sobre las trazas generadas por el auditor. Por cada

traza entre otras cosas se guarda el tipo de servidor, el usuario, la contraseña,

para poder reconstruir la conexión cuando se solicitan reportes sobre una traza

en particular.

� identificador,

� nombre,

� descripción,

� servidor,

� tipo de servidor,

� usuario,

� contraseña,

� base de datos,

� esquema,

� tabla,

� habilitada,

� operación.



� tTipoServidor: almacena todos los tipos de DBMS que permite usar la

aplicación.

� Identificador,

� Descripción, DBMS.

� tcolumnas: son todas las columnas de las trazas de las cuales interesa guardar

información de cambio.

� Identificador de la traza,

� Descripción, nombre de la columna.

Auditorias

Existe una base de datos Auditorias en cada servidor de DBMS. La base Auditorias

contiene una sola tabla, tdatos, que mantiene la estructura para todos los tipos de DBMS,

salvando las particularidades de cada uno. La estructura es:

� tdatos

� traza, nombre de la traza que generó el registro,

� tabla, tabla a la cual se realizo la modificación de registros,

� usuario, usuario que realizo el cambio,

� operación, operación que se realizo,

� datos, cadena de texto que guarda los nombres de los campos y el valor

de cada uno,

� base de datos, base donde se albergada la traza,

� esquema, para el caso particular de Postgres,

� fecha, fecha de registro de movimiento.



Capítulo 6 INFRAESTRUCTURA UTILIZADA

El sistema se desarrollo utilizando como herramientas las siguientes:

� Base de datos: SQL Server 2000.

� Lenguaje de programación: Visual Basic 6.0.

Arquitectura

� Arquitectura: cliente-servidor.

� Reporting Web: Aunque no ha sido incorporado en la versión original, la

arquitectura permite utilizar herramientas que generen reporting en una

arquitectura web, de manera que puedan obtenerse reportes desde cualquier

punto de la red utilizando simplemente un navegador.

Consideraciones

Restricciones de nombres:

� La Base de Datos donde se guarda información de las traza se debe llamar

GAVA.

� La Base de Datos que alberga datos sobre las actualizaciones de los usuarios en

los distintos servidores, se debe llamar Auditoria.

� La única tabla que contiene la Base de Datos Auditoria se debe llamar tdatos.

Seguridad

El usuario de la aplicación debe contar con un identificador de usuario y una clave

para poder conectarse a un servidor y sacar información sobre todo lo que el servidor

posee.



Capítulo 7 SELECCIÓN DE HERRAMIENTAS

DBMS

Se seleccionaron dos DBMS por distintas razones.

� La primera, por el uso de la herramienta en la zona

� La segunda, porque uno es una herramienta de código abierto y el otro no.

Los dos motores seleccionados fueron PostgreSQ y SQL Server.

Tanto PostgreSQL como SQL son productos de base de datos distintos y que

pertenecen a distintos proveedores, a ello se debe entonces que uno sea comercial y el otro

no.

PostgreSQL es un proyecto open source, o de código abierto. Código Abierto por

definición significa que se puede obtener el código fuente, usar el programa, y modificarlo

libremente sin las limitaciones del software propietario. En el ambiente de las bases de

datos, código abierto significa que se tiene estadísticas de rendimiento y datos que otras

compañías como Oracle no facilitan. Código abierto también significa que se es libre de

modificar PostgreSQL para adaptarlo a las necesidades particulares.

Sin embargo, hay un malentendido en cuanto a que si bien el software de código

abierto está libre de restricciones del distribuidor, no deja de tener costos para la

organización que lo utilice. Es cierto en cuanto a que se puede, sin costo alguno, descargar

e instalar software de código abierto, pero siempre existirán costos asociados con el tiempo

y esfuerzo que la organización dedique a desarrollar y/o adaptar las aplicaciones necesarias.

No hay que dejar de considerar que si no se dispone de esos recursos, existen varias

distribuciones comerciales, así como consultores que trabajan específicamente con

PostgreSQL.

El principal factor a la hora de decidir si usar una versión de código abierto de

PostgreSQL o bien una versión comercial del paquete debería ser los requerimientos del

negocio.



PostgreSQL está ampliamente considerado como el sistema de bases de datos de

código abierto más avanzado del mundo.

En lo que se refiere a SQL SERVER, este producto ha agregado un conjunto

convincente de características que permite la creación de aplicaciones verdaderamente

globales y constituye la mejor opción en cuanto a base de datos para las organizaciones

globales. Este es un motor de base de datos comercial pero tan potente como Postgres y

uno de los mas usados en la zona.

Programación

Lenguaje

VISUAL BASIC 6.0

Para realizar el programa se eligió como entorno de programación a Visual Basic 6.0

debido a que cumplía con todos los requisitos establecidos. Visual Basic 6 nos permite:

� crear de manera fácil y rápida una interface de usuario adecuada

Diseñador de Reportes

DATA REPORT(VISUAL BASIC 6.0)

Es una herramienta que provee Visual Basic para diseñar reportes, el reporte queda

incluido dentro del exe de la aplicación.

Es una herramienta sencilla y fácil de usar

Visual Basic 6.0

Data Report

Aplicación



Capítulo 8 CONCLUSIONES

Componentes no incluidos y posibles extensiones

� Reportes15

� Actualmente, el sistema muestra un solo reporte genérico

� Sugerencias, se podrían agregar mas reportes y utilizar otra

herramienta para mostrar los datos en distintos formatos (gráficos)

� Seguimiento de un usuario a través de los distintos DBMS:

� Actualmente, se tendrían que generar distintos reportes, uno por cada

DBMS

� Sugerencia, se podrían importar todos los datos a la base GAVA y emitir

un solo reporte que contenga todas las acciones que realizo un usuario

sin importar el DBMS.

� Generación de trazas condicionales 16

� Actualmente, el sistema genera acciones sin tener en cuanta posibles

valores de los campos

� Sugerencia, el sistema podría pedir valores para los campos que se

desean guardar y solo si cumplen la condición disparar una acción.

� Forma de ejecución de los script

� Actualmente, la creación de la traza permite la generación de un

archivo que contiene el script y es el administrador de base de Datos el

que debe ejecutarlo en el servidor y la base correspondiente

15 Apéndice II: Manual de usuario- Reportes 16 Apéndice II: Manual de usuario- Trazas



� Sugerencia, el script se podría ejecutar directamente desde el

programa.

No se realizo de esta manera por razones de seguridad. El

administrador de base de datos es el encargado de realizar los cambios.

Si se diera la citación donde una tabla dada tenga una traza generada, al

modificar los datos de la tabla, los programas podrían generar error en

tiempo de ejecución. La traza debe ser conocida por al administrador

para no perjudicar el normal funcionamiento de los sistemas.

� Habilitación del trigger 17

� Actualmente, cada vez que por la aplicación GAVA se habilita y

deshabilita una traza, es función del auditor poner en conocimiento al

administrador de base de datos para que elimine o agregue nuevamente

la traza.

� Sugerencia, se podría agregar a los triggers algún tipo de verificación

donde cada vez que se disparan preguntarse a si mismos si están

activados.

Comentarios finales

Al iniciar nuestra búsqueda para seleccionar un proyecto para la tesina estábamos

seguros que se enfocaría al ambiente de Bases de Datos debido a nuestra predilección por

el significado de los datos y por su forma de representarlos. No obstante ello, descubrimos

una área que aunque era conocida por nosotros no había sido profundizada más de alguna

breve lectura en alguna revista actual. Estamos hablando específicamente de la Auditoria

Informática. 17 Apéndice II: Manual de usuario- Trazas – Habilitación de Trazas



Es así que al ir interiorizándonos del tema nos atrajo y lo profundizamos lo suficiente

como para hallar su punto de interacción con las Bases de Datos. Esto unido a la elección de

nuestro tutor y su propuesta de enfocarnos en encontrar una herramienta global para la

auditoria centralizada sobre bases de datos determinó el trabajo presente.

Conclusiones

Consideramos haber alcanzado los objetivos propuestos de este trabajo, el cual ha

significado desde el punto de vista de investigación una duración de 45 días y desde el

punto de vista de desarrollo otros 45 días completándose los 120 días totales con el diseño,

edición y presentación del informe final. Respecto de la planificación del proyecto logramos

reducir el tiempo estimado prácticamente en un mes debido a que los elementos necesarios

para el desarrollo fueron obtenidos y puestos en uso sin mayores complicaciones. Es

destacable que nos ayudo los conocimientos y experiencia previos, que ambos como

docentes y profesionales poseemos, a la hora de entender y utilizar los nuevos conceptos

adquiridos.

Creemos que GAVA, por ser una herramienta resultante de una tesis de alumnos

cumple con los requerimientos necesarios para ser utilizada en forma profesional, por ese

motivo queda disponible para ser evaluada por quienes estén interesados.



Apéndice I DESARROLLO DEL PROYECTO

Plan de Trabajo

1- Búsqueda y selección de información sobre auditorias,

a. Recopilación de información en Internet.

b. Recopilación de información de libros.

c. Lectura y selección de todo el material.

2- Investigación de la situación actual de las organizaciones con respecto a la auditoria,

a. Seleccionar dos organizaciones del medio.

b. Establecer la forma en que las organizaciones antes seleccionadas,

desarrollan auditorias Informáticas.

c. Determinar aspectos ausentes que se deberían incorporar en materia de

auditorias Informáticas.

3- Análisis metodológico de los RDBMS existentes,

a. Relevamiento de los distintos RDBMS utilizados en el medio.

b. Selección de los dos RDBMS con mayor porcentaje de uso.

c. Recopilación de documentación en Internet.

d. Recopilación de libros.

e. Clasificación y análisis del material relevante a las auditorias.

f. Adquisición del software de los gestores de base de datos seccionados.

g. Instalación del software adquirido.

h. Evaluación y pruebas generales del entorno.

i. Evaluación y pruebas de mecanismos provistos por el RDBMS, útiles para

realizar auditorias Informáticas.

4- Modelización y diseño de la herramienta de auditoria,

a. Determinar las necesidades a cubrir por la herramienta.

b. Formular las especificaciones generales de la herramienta.



c. Seleccionar un lenguaje para la implementación y traducción del modelo.

d. Seleccionar un RDBMS para almacenar los datos de los trace.

5- Implementación de la herramienta de apoyo

a. Formular un esquema de Base de Datos para almacenar la información de los

trace.

b. Formular esquema de las bases de auditorias para cada RDBMS a auditar.

c. Diseño y codificación de formularios para conectarse con los distintos RDBMS.

d. Diseño y codificación de formularios para interactuar con los trace.

e. Diseño y codificación de formularios de invocación de reportes sobre todos

los registros de actividad.

f. Pruebas.



Cronograma

Previsto

- Búsqueda y selección de información sobre auditorías 32 días 01/12/2006 15/01/2007

Recopilación de información en Internet 26 días 01/12/2006 05/01/2007

Recopilación de información de libros 26 días 01/12/2006 05/01/2007

Lectura y selección de todo el material 22 días 15/12/2006 15/01/2007

- Investigación de la situación actual de las organizaciones con respecto a la Auditoría 11 días 15/12/2006 29/12/2006

Seleccionar dos organizaciones del medio. 2 días 15/12/2006 18/12/2006

Establecer la forma en que las organizaciones antes seleccionadas, desarrollan Auditorías Informáticas. 4 días 19/12/2006 22/12/2006

Determinar aspectos ausentes que se deberían incorporar en materia de Auditorías Informáticas. 4 días 26/12/2006 29/12/2006

- Análisis metodológico de los RDBMS existentes, 50 días 11/12/2006 16/02/2007

Relevamiento de los distintos RDBMS utilizados en el medio. 3 días 11/12/2006 13/12/2006

Selección de los dos RDBMS con mayor porcentaje de uso. 4 días 14/12/2006 19/12/2006

Recopilación de documentación en Internet. 16 días 20/12/2006 10/01/2007

Recopilación de libros. 16 días 20/12/2006 10/01/2007

Clasificación y análisis del material relevante a las auditorías. 10 días 02/01/2007 15/01/2007

Adquisición del software de los gestores de base de datos seccionados. 3 días 20/12/2006 22/12/2006

Instalación del software adquirido. 1 día? 22/12/2006 22/12/2006

Evaluación y pruebas generales del entorno. 30 días 04/01/2007 14/02/2007

Evaluación y pruebas de mecanismos provistos por el RDBMS, útiles para realizar Auditorías Informáticas. 30 días 08/01/2007 16/02/2007

- Modelización y diseño de la herramienta de auditoría, 12 días 01/02/2007 16/02/2007

Determinar las necesidades a cubrir por la herramienta. 5 días 01/02/2007 07/02/2007

Formular las especificaciones generales de la herramienta. 3 días 08/02/2007 12/02/2007

Seleccionar un lenguaje para la implementación y traducción del modelo. 4 días 13/02/2007 16/02/2007



Seleccionar un RDBMS para almacenar los datos de los trace. 3 días 14/02/2007 16/02/2007

- Implementación de la herramienta de apoyo 22 días 16/02/2007 15/03/2007

Formular un esquema de Base de Datos para almacenar la información de los trace. 3 días 16/02/2007 19/02/2007

Formular esquema de las bases de auditorías para cada RDBMS a auditar. 3 días 20/02/2007 22/02/2007

Diseño y codificación de formularios para conectarse con los distintos RDBMS. 5 días 23/02/2007 01/03/2007

Diseño y codificación de formularios para interactuar con los trace. 13 días 26/02/2007 13/03/2007

Diseño y codificación de formularios de invocación de reportes sobre todos los registros de actividad. 4 días 26/02/2007 01/03/2007

Pruebas. 6 días 09/03/2007 15/03/2007

- Generación de informe y presentación 43 días 05/03/2007 30/04/2007

Generación de informe 28 días 05/03/2007 10/04/2007

Edición de presentación 9 días 11/04/2007 20/04/2007

Preparación para la defensa 7 días 20/04/2007 30/04/2007



Ejecutado

- Búsqueda y selección de información sobre auditorías 22 días 05/12/2006 02/01/2007

Recopilación de información en Internet 20 días 05/12/2006 29/12/2006

Recopilación de información de libros 20 días 05/12/2006 29/12/2006

Lectura y selección de todo el material 13 días 16/12/2006 02/01/2007

- Investigación de la situación actual de las organizaciones con respecto a la Auditoría 3 días 16/12/2006 19/12/2006

Seleccionar dos organizaciones del medio. 1 día? 16/12/2006 16/12/2006

Establecer la forma en que las organizaciones antes seleccionadas, desarrollan Auditorías Informáticas. 3 días 16/12/2006 19/12/2006

Determinar aspectos ausentes que se deberían incorporar en materia de Auditorías Informáticas. 3 días 16/12/2006 19/12/2006

- Análisis metodológico de los RDBMS existentes, 16 días 11/12/2006 30/12/2006

Relevamiento de los distintos RDBMS utilizados en el medio. 1 día? 11/12/2006 11/12/2006

Selección de los dos RDBMS con mayor porcentaje de uso. 1 día? 12/12/2006 12/12/2006

Recopilación de documentación en Internet. 11 días 13/12/2006 26/12/2006

Recopilación de libros. 11 días 13/12/2006 26/12/2006

Clasificación y análisis del material relevante a las auditorías. 10 días 18/12/2006 30/12/2006

Adquisición del software de los gestores de base de datos seccionados. 3 días 13/12/2006 15/12/2006

Instalación del software adquirido. 2 días 16/12/2006 18/12/2006

Evaluación y pruebas generales del entorno. 10 días 18/12/2006 29/12/2006

Evaluación y pruebas de mecanismos provistos por el RDBMS, útiles para realizar Auditorías Informáticas. 7 días 21/12/2006 29/12/2006

- Modelización y diseño de la herramienta de auditoría, 9 días 02/01/2007 13/01/2007

Determinar las necesidades a cubrir por la herramienta. 4 días 02/01/2007 05/01/2007

Formular las especificaciones generales de la herramienta. 3 días 08/01/2007 10/01/2007



Seleccionar un lenguaje para la implementación y traducción del modelo. 1 día? 11/01/2007 11/01/2007

Seleccionar un RDBMS para almacenar los datos de los trace. 1 día? 12/01/2007 13/01/2007

- Implementación de la herramienta de apoyo 25 días 15/01/2007 17/02/2007

Formular un esquema de Base de Datos para almacenar la información de los trace. 2 días 15/01/2007 16/01/2007

Formular esquema de las bases de auditorías para cada RDBMS a auditar. 1 día? 17/01/2007 17/01/2007

Diseño y codificación de formularios para conectarse con los distintos RDBMS. 5 días 18/01/2007 24/01/2007

Diseño y codificación de formularios para interactuar con los trace. 13 días 23/01/2007 08/02/2007

Diseño y codificación de formularios de invocación de reportes sobre todos los registros de actividad. 3 días 09/02/2007 13/02/2007

Pruebas. 12 días 01/02/2007 17/02/2007

- Generación de informe y presentación 31 días 19/02/2007 30/03/2007

Generación de informe 18 días 19/02/2007 13/03/2007

Edición de presentación 6 días 14/03/2007 21/03/2007

Preparación para la defensa 7 días 22/03/2007 30/03/2007



Apéndice II: MANUAL DE USUARIO

Formularios

Principal

En la barra se muestran todas las operaciones que se pueden realizar. En los botones

se encuentran las operaciones mas frecuentes.

En la parte inferior de la pantalla se muestra el usuario conectado, el nombre del

servidor, la base de datos y la fecha.

La estructura de la barra:

� Parámetros

� Trazas

� Nueva Traza

� Eliminar Traza

� Ver Traza

� Generación

� Generar Script Alta

� Generar script Eliminación

� Reportes

� Información



� Ayuda

� Información General

� Salir

Parámetros

Esta es una pantalla de configuración para poder generar un .ini y cambiar los datos

cada vez que se cambie alguna configuración del servidor. En este archivo se guarda el

servidor, la base, el usuario y la contraseña.

Trazas

a) Nueva traza

Pasos a seguir para dar de alta una traza

i. Selección de Tipo Servidor



Es el primer paso para dar de alta una traza. Se debe indicar el

nombre de la traza para luego poder identificarla. El nombre no debe

comenzar con números ni contener espacios ya que este va a ser el nombre

del trigger que se va a guardar en la base. En la lista desplegable ( Tipo de

Servidor) se muestran todos los motores de base de datos para los cuales el

sistema esta preparado para generar un script.

ii. Petición de servidor, usuario y contraseña

Una vez que se tiene el tipo de servidor, en la lista desplegable

(Servidor) se muestran todos los servidores de ese motor de base de datos

que se encuentran conectados a la maquina. Luego, se debe indicar un

usuario y contraseña para poder conectarse al servidor. Una vez ingresados

los datos, se debe intentar conectar al servidor. En caso de que la conexión

no sea satisfactoria no se puede avanzar.



iii. Petición de Base, Tabla y Operación

Lista en forma automática todas las bases de datos que se encuentran

en el servidor. Luego en el caso de Postgres se debe seleccionar el esquema.

Una vez que se tienen estos datos se listan las tablas y las

operaciones(inserción, modificación, eliminación) de las cuales se quiere

registrar un cambio.



iv. Petición de campos

Se listan todos los campos de la tabla, permitiendo chequear aquellos

que se desean guardar cuando en la tabla hay un cambio.

v. Generación de archivo

vi. Petición de lugar de generación



Se debe seleccionar el lugar donde se deja el script e indicar el nombre

con el cual se va a guardar el archivo para después ser levantado por el

administrador para ser ejecutado en la base.

b) Eliminación de Trazas

c) Habilitación de Trazas

Lista todas las trazas creadas. Cuando se selecciona alguna y se

presiona eliminar, se elimina de la tabla y de todas las tablas donde se

encuentra referenciada. Por otro lado permite generar el script de eliminación

de trazas para que el administrador lo ejecute en la base de datos y elimine la

traza.

d) Ver Trazas



Permite seleccionar una traza y ver toda la información relacionada a

ella.

Generación

El menú, permite regenerar el script de eliminación o de nueva traza. Depende de

que opción del menú se seleccione, el botón regenerar archivo va a generar uno u otro tipo

de script.



Reportes

Permite realizar una selección sobre los datos que registraron las distintas trazas. En

base a la selección se imprime en pantalla los resultados de la búsqueda.



Información

Brinda información general sobre el sistema.



Requerimientos mínimos

Gava se puede utilizar en una red Wan o simplemente un una maquina que se

comporte como servidor. Los requerimientos mínimos son: tener la aplicación Gava

instalado, un servidor SQL Server con la base GAVA restaurada, bases de datos de auditoria

y una aplicación de usuario que acceda a una base de datos auditable.

Servidor

Aplicación GAVA

SERVIDOR DE SQL

GAVA

BasesAuditables

AuditoriaSQL Server



Instalación

En el cd se encuentra:

- backup de la base GAVA para el servidor de SQL Server

- backup de la base de auditoria para los DBMS de SQL Server

- script de la base de datos Auditorias para los DBMS de postgres

- script de la tabla tdatos de la base de auditoria en los DBMS de Postgres

La instalación deja por defecto en el directorio un .ini que debe ser configurado por el

administrador. Este indica la ubicación de la base de datos Gava junto con el usuario y la

contraseña para conectarse a ella.

Configuración

Una vez instalada la aplicación, seria conveniente que el administrador genere el

archivo registro.ini en donde se encuentra el ejecutable de la aplicación, donde conste el

usuario, contraseña, base de datos y servidor en donde se encuentra la base GAVA.

Inicio de la aplicación

Cuando la aplicación se inicia verifica la existencia de un archivo, registro.ini, que

contiene información del usuario, contraseña, base de datos y servidor donde el usuario se

conecta. El usuario que se usa para ingresar en la aplicación, debe ser usuario de la base de

datos GAVA. En caso de no existir el archivo, registro.ini, la aplicación despliega el

formulario de parámetros para completar los datos necesarios para poder realizar las

operaciones de consulta y actualización sobre la Base de Datos GAVA. Una vez ingresados

los datos, la aplicación los verifica, si son correctos solicita que se reinicie la misma para

poder tomar los cambios; en caso de no serlos no permite continuar.



Funciones del Administrador

El primer paso que debe realizar el administrador GAVA es restaurar el backup de la

base Gava en el servidor. El segundo paso seria brindarle un usuario y una contraseña al

auditor por cada DBMS, con la cual él pueda consultar las bases del servidor, las tablas y

sus campos de las bases que requiera auditar. Una vez que el auditor genera los script, el

administrador debe ejecutarlos en la base, con antes previa restauración de la base de

datos Auditoría. Una vez ejecutados los script el auditor puede comenzar la recolección de

datos en los distintos DBMS y bases de los cuales solicito la el registro de actividades.



Apéndice III: INCORPORACION DE NUEVOS DBMS

El sistema se encuentra parametrizado para poder incorporar un nuevo DMBS sin

realizar mayores cambios. Los pasos a seguir para agregar un DBMS son:

En la base de datos GAVA

1- En la tabla tTipoServidor, agregar en registro mas para identificar el nuevo DBMS

En la aplicación

1- Modificar el módulo Variables agregando una constante que identifique el DBMS

2- Modificar el modulo Funciones agregando una opción mas a cada cláusula case

la nueva opción.

3- Agregar un formulario nuevo para dar de alta la nueva traza. Se puede tomar

como modelo alguno de los ya desarrollados para SQL Server o Postgres.

4- Modificar el formulario frmReporteGeneral en la función EstablecerConexion

agregando una opción mas en la cláusula case.



Apéndice IV: PRUEBAS

Para realizar las pruebas y poder hacer una demostración entretenida y llevadera, se

generaron dos programas, calles y juguetería. Cada uno de ellos se conecta con uno de los

dos tipos de DBMS existentes y modifican los registros de la única tabla que posee la Basse.

Estos programas realizan alta de registros y eliminación, así como una simple consulta

sobre los datos que contiene la tabla.

Para comenzar con la prueba se debe realizar:

� Un vaciado general de las tablas de las bases. Limpiar contenido de la tabla de

trazas y columnas de las trazas.

� También se deben limpiar el contenido de la tabla datos en las bases de

auditorias en cada servidor.

� Crear una nueva traza conectándose al servidor de Postgres donde se

encuentra el esquema juguetería, seleccionar la tabla juguetería, la operación

de eliminación y chequear los campos de la tabla que se quieren guardar. Una

vez que se tienen esos datos generar el archivo para el administrador.

� Crear una nueva traza conectándose al servidor de SQL Server donde se

encuentra el la base Calles, seleccionar la tabla calle, la operación de inserción

y chequear los campos de la tabla que se quieren guardar. Una vez que se

tienen esos datos generar el archivo para el administrador.

� El administrador de la base levanta los archivos y ejecuta los script.

� Ejecutar el programa Calles. Insertar un par de calles. Después eliminar una

calle.

� Ejecutar el programa Juguetería. Insertar un par de juguetes. Después eliminar

un juguete.

� Desde la aplicación GAVA generar los reportes bajo distintos criterios.



Apéndice V: APLICACIONES DE PRUEBA

Calles

Esta aplicación se conecta con un servidor de SQL Server

El menú principal

Formulario de ingreso



Formulario de visualización

Formulario de eliminación



Juguetería

Esta aplicación se conecta con un servidor de SQL Server

El menú principal



Formulario de ingreso

Formulario de eliminación



Formulario de visualización



Apéndice VI: TRIGGERS

A continuación se muestran dos script de generación de triggers de inserción, uno de

para un servidor de Postrgres y a continuación uno de SQL Server

Postgres

CREATE FUNCTION jugueteria.inserciondejuguetes() returns trigger AS

$cuerpo$

BEGIN

INSERT INTO auditoria.tdatos SELECT 'inserciondejuguetes',

'juguete',

user,

'Insertar',

' cantidad=' || TRIM ( new.cantidad) ||

' codigo=' || TRIM ( new.codigo) ||

' color=' || TRIM ( new.color) ||

' descripcion=' || TRIM ( new.descripcion) ,

'Escuela',

'jugueteria',

now();

RETURN NEW;

END;

$cuerpo$

LANGUAGE plpgsql;

CREATE TRIGGER inserciondejuguetes BEFORE INSERT ON jugueteria.juguete

FOR EACH ROW EXECUTE PROCEDURE jugueteria.inserciondejuguetes();



SQL Server

CREATE TRIGGER inserciondecalle ON GraCalle FOR Insert AS

DECLARE @FechaActual DATETIME

DECLARE @Usuario VARCHAR(20)

DECLARE @Aplicacion VARCHAR(20)

SET @FechaActual = GETDATE()

SET @Usuario = CURRENT_USER

SET @Aplicacion = APP_NAME()

Begin

INSERT INTO [Auditoria].[dbo].[tDatos] (

traza, datos,

Usuario, Fecha,

Tabla, BaseDatos,

Operacion )

SELECT 'inserciondecalle', ' Codigo=' + LTRIM ( RTRIM( convert

(VARCHAR(100), Codigo))) +

' descripcion=' + LTRIM ( RTRIM( convert (VARCHAR(100), descripcion))) ,

@Usuario, @FechaActual ,'GraCalle', 'Calles','Insertar'

FROM INSERTED

End



Apéndice VII: LEYES y DECRETOS

Ley 25.326 - Protección de los datos personales

Disposiciones Generales. Principios generales relativos a la protección de datos. Derechos de los titulares de datos. Usuarios y responsables de archivos, registros y bancos de datos. Control. Sanciones. Acción de protección de los datos personales. Sancionada: Octubre 4 de 2000. Promulgada Parcialmente: Octubre 30 de 2000. El Senado y Cámara de Diputados de la Nación Argentina reunidos en Congreso, etc. sancionan con fuerza de Ley: Ley de Protección de los Datos Personales

CAPÍTULO I DISPOSICIONES GENERALES ARTICULO 1° — (Objeto).

La presente ley tiene por objeto la protección integral de los datos personales asentados en archivos, registros, bancos de datos, u otros medios técnicos de tratamiento de datos, sean éstos públicos, o privados destinados a dar informes, para garantizar el derecho al honor y a la intimidad de las personas, así como también el acceso a la información que sobre las mismas se registre, de conformidad a lo establecido en el artículo 43, párrafo tercero de la Constitución Nacional.

Las disposiciones de la presente ley también serán aplicables, en cuanto resulte pertinente, a los datos relativos a personas de existencia ideal.

En ningún caso se podrán afectar la base de datos ni las fuentes de información periodísticas. ARTICULO 2° — (Definiciones).

A los fines de la presente ley se entiende por: — Datos personales: Información de cualquier tipo referida a personas físicas o de

existencia ideal determinadas o determinables. — Datos sensibles: Datos personales que revelan origen racial y étnico, opiniones

políticas, convicciones religiosas, filosóficas o morales, afiliación sindical e información referente a la salud o a la vida sexual.

— Archivo, registro, base o banco de datos: Indistintamente, designan al conjunto organizado de datos personales que sean objeto de tratamiento o procesamiento, electrónico o no, cualquiera que fuere la modalidad de su formación, almacenamiento, organización o acceso.

— Tratamiento de datos: Operaciones y procedimientos sistemáticos, electrónicos o no, que permitan la recolección, conservación, ordenación, almacenamiento, modificación, relacionamiento, evaluación, bloqueo, destrucción, y en general el procesamiento de datos personales, así como también su cesión a terceros a través de comunicaciones, consultas, interconexiones o transferencias.



— Responsable de archivo, registro, base o banco de datos: Persona física o de existencia ideal pública o privada, que es titular de un archivo, registro, base o banco de datos.

— Datos informatizados: Los datos personales sometidos al tratamiento o procesamiento electrónico o automatizado.

— Titular de los datos: Toda persona física o persona de existencia ideal con domicilio legal o delegaciones o sucursales en el país, cuyos datos sean objeto del tratamiento al que se refiere la presente ley.

— Usuario de datos: Toda persona, pública o privada que realice a su arbitrio el tratamiento de datos, ya sea en archivos, registros o bancos de datos propios o a través de conexión con los mismos.

— Disociación de datos: Todo tratamiento de datos personales de manera que la información obtenida no pueda asociarse a persona determinada o determinable.

CAPÍTULO II PRINCIPIOS GENERALES RELATIVOS A LA PROTECCIÓN DE DATOS ARTICULO 3° — (Archivos de datos – Licitud).

La formación de archivos de datos será lícita cuando se encuentren debidamente inscriptos, observando en su operación los principios que establece la presente ley y las reglamentaciones que se dicten en su consecuencia.

Los archivos de datos no pueden tener finalidades contrarias a las leyes o a la moral pública. ARTICULO 4° — (Calidad de los datos).

1. Los datos personales que se recojan a los efectos de su tratamiento deben ser ciertos, adecuados, pertinentes y no excesivos en relación al ámbito y finalidad para los que se hubieren obtenido.

2. La recolección de datos no puede hacerse por medios desleales, fraudulentos o en forma contraria a las disposiciones de la presente ley.

3. Los datos objeto de tratamiento no pueden ser utilizados para finalidades distintas o incompatibles con aquellas que motivaron su obtención.

4. Los datos deben ser exactos y actualizarse en el caso de que ello fuere necesario. 5. Los datos total o parcialmente inexactos, o que sean incompletos, deben ser

suprimidos y sustituidos, o en su caso completados, por el responsable del archivo o base de datos cuando se tenga conocimiento de la inexactitud o carácter incompleto de la información de que se trate, sin perjuicio de los derechos del titular establecidos en el artículo 16 de la presente ley.

6. Los datos deben ser almacenados de modo que permitan el ejercicio del derecho de acceso de su titular.

7. Los datos deben ser destruidos cuando hayan dejado de ser necesarios o pertinentes a los fines para los cuales hubiesen sido recolectados. ARTICULO 5° — (Consentimiento).

1. El tratamiento de datos personales es ilícito cuando el titular no hubiere prestado su consentimiento libre, expreso e informado, el que deberá constar por escrito, o por otro medio que permita se le equipare, de acuerdo a las circunstancias.

El referido consentimiento prestado con otras declaraciones, deberá figurar en forma expresa y destacada, previa notificación al requerido de datos, de la información descrita en el artículo 6° de la presente ley.

2. No será necesario el consentimiento cuando:



a) Los datos se obtengan de fuentes de acceso público irrestricto; b) Se recaben para el ejercicio de funciones propias de los poderes del Estado o

en virtud de una obligación legal; c) Se trate de listados cuyos datos se limiten a nombre, documento nacional de

identidad, identificación tributaria o previsional, ocupación, fecha de nacimiento y domicilio;

d) Deriven de una relación contractual, científica o profesional del titular de los datos, y resulten necesarios para su desarrollo o cumplimiento;

e) Se trate de las operaciones que realicen las entidades financieras y de las informaciones que reciban de sus clientes conforme las disposiciones del artículo 39 de la Ley 21.526.

ARTICULO 6° — (Información).

Cuando se recaben datos personales se deberá informar previamente a sus titulares en forma expresa y clara:

a) La finalidad para la que serán tratados y quiénes pueden ser sus destinatarios o clase de destinatarios;

b) La existencia del archivo, registro, banco de datos, electrónico o de cualquier otro tipo, de que se trate y la identidad y domicilio de su responsable;

c) El carácter obligatorio o facultativo de las respuestas al cuestionario que se le proponga, en especial en cuanto a los datos referidos en el artículo siguiente;

d) Las consecuencias de proporcionar los datos, de la negativa a hacerlo o de la inexactitud de los mismos;

e) La posibilidad del interesado de ejercer los derechos de acceso, rectificación y supresión de los datos. ARTICULO 7° — (Categoría de datos).

1. Ninguna persona puede ser obligada a proporcionar datos sensibles. 2. Los datos sensibles sólo pueden ser recolectados y objeto de tratamiento cuando

medien razones de interés general autorizadas por ley. También podrán ser tratados con finalidades estadísticas o científicas cuando no puedan ser identificados sus titulares.

3. Queda prohibida la formación de archivos, bancos o registros que almacenen información que directa o indirectamente revele datos sensibles. Sin perjuicio de ello, la Iglesia Católica, las asociaciones religiosas y las organizaciones políticas y sindicales podrán llevar un registro de sus miembros.

4. Los datos relativos a antecedentes penales o contravencionales sólo pueden ser objeto de tratamiento por parte de las autoridades públicas competentes, en el marco de las leyes y reglamentaciones respectivas. ARTICULO 8° — (Datos relativos a la salud).

Los establecimientos sanitarios públicos o privados y los profesionales vinculados a las ciencias de la salud pueden recolectar y tratar los datos personales relativos a la salud física o mental de los pacientes que acudan a los mismos o que estén o hubieren estado bajo tratamiento de aquéllos, respetando los principios del secreto profesional. ARTICULO 9° — (Seguridad de los datos).

1. El responsable o usuario del archivo de datos debe adoptar las medidas técnicas y organizativas que resulten necesarias para garantizar la seguridad y confidencialidad de los datos personales, de modo de evitar su adulteración, pérdida, consulta o tratamiento no autorizado, y que permitan detectar desviaciones, intencionales o no, de información, ya sea que los riesgos provengan de la acción humana o del medio técnico utilizado.



2. Queda prohibido registrar datos personales en archivos, registros o bancos que no reúnan condiciones técnicas de integridad y seguridad. ARTICULO 10. — (Deber de confidencialidad).

1. El responsable y las personas que intervengan en cualquier fase del tratamiento de datos personales están obligados al secreto profesional respecto de los mismos. Tal obligación subsistirá aun después de finalizada su relación con el titular del archivo de datos.

2. El obligado podrá ser relevado del deber de secreto por resolución judicial y cuando medien razones fundadas relativas a la seguridad pública, la defensa nacional o la salud pública. ARTICULO 11. — (Cesión).

1. Los datos personales objeto de tratamiento sólo pueden ser cedidos para el cumplimiento de los fines directamente relacionados con el interés legítimo del cedente y del cesionario y con el previo consentimiento del titular de los datos, al que se le debe informar sobre la finalidad de la cesión e identificar al cesionario o los elementos que permitan hacerlo.

2. El consentimiento para la cesión es revocable. 3. El consentimiento no es exigido cuando:

a) Así lo disponga una ley; b) En los supuestos previstos en el artículo 5° inciso 2; c) Se realice entre dependencias de los órganos del Estado en forma directa, en la

medida del cumplimiento de sus respectivas competencias; d) Se trate de datos personales relativos a la salud, y sea necesario por razones

de salud pública, de emergencia o para la realización de estudios epidemiológicos, en tanto se preserve la identidad de los titulares de los datos mediante mecanismos de disociación adecuados;

e) Se hubiera aplicado un procedimiento de disociación de la información, de modo que los titulares de los datos sean inidentificables.

4. El cesionario quedará sujeto a las mismas obligaciones legales y reglamentarias del cedente y éste responderá solidaria y conjuntamente por la observancia de las mismas ante el organismo de control y el titular de los datos de que se trate. ARTICULO 12. — (Transferencia internacional).

1. Es prohibida la transferencia de datos personales de cualquier tipo con países u organismos internacionales o supranacionales, que no propocionen niveles de protección adecuados.

2. La prohibición no regirá en los siguientes supuestos: a) Colaboración judicial internacional; b) Intercambio de datos de carácter médico, cuando así lo exija el tratamiento del

afectado, o una investigación epidemiológica, en tanto se realice en los términos del inciso e) del artículo anterior;

c) Transferencias bancarias o bursátiles, en lo relativo a las transacciones respectivas y conforme la legislación que les resulte aplicable;

d) Cuando la transferencia se hubiera acordado en el marco de tratados internacionales en los cuales la República Argentina sea parte;

e) Cuando la transferencia tenga por objeto la cooperación internacional entre organismos de inteligencia para la lucha contra el crimen organizado, el terrorismo y el narcotráfico.

CAPÍTULO III



DERECHOS DE LOS TITULARES DE DATOS ARTICULO 13. — (Derecho de Información).

Toda persona puede solicitar información al organismo de control relativa a la existencia de archivos, registros, bases o bancos de datos personales, sus finalidades y la identidad de sus responsables.

El registro que se lleve al efecto será de consulta pública y gratuita. ARTICULO 14. — (Derecho de acceso).

1. El titular de los datos, previa acreditación de su identidad, tiene derecho a solicitar y obtener información de sus datos personales incluidos en los bancos de datos públicos, o privados destinados a proveer informes.

2. El responsable o usuario debe proporcionar la información solicitada dentro de los diez días corridos de haber sido intimado fehacientemente.

Vencido el plazo sin que se satisfaga el pedido, o si evacuado el informe, éste se estimara insuficiente, quedará expedita la acción de protección de los datos personales o de hábeas data prevista en esta ley.

3. El derecho de acceso a que se refiere este artículo sólo puede ser ejercido en forma gratuita a intervalos no inferiores a seis meses, salvo que se acredite un interés legítimo al efecto.

4. El ejercicio del derecho al cual se refiere este artículo en el caso de datos de personas fallecidas le corresponderá a sus sucesores universales. ARTICULO 15. — (Contenido de la información).

1. La información debe ser suministrada en forma clara, exenta de codificaciones y en su caso acompañada de una explicación, en lenguaje accesible al conocimiento medio de la población, de los términos que se utilicen.

2. La información debe ser amplia y versar sobre la totalidad del registro perteneciente al titular, aun cuando el requerimiento sólo comprenda un aspecto de los datos personales. En ningún caso el informe podrá revelar datos pertenecientes a terceros, aun cuando se vinculen con el interesado.

3. La información, a opción del titular, podrá suministrarse por escrito, por medios electrónicos, telefónicos, de imagen, u otro idóneo a tal fin. ARTICULO 16. — (Derecho de rectificación, actualización o supresión).

1. Toda persona tiene derecho a que sean rectificados, actualizados y, cuando corresponda, suprimidos o sometidos a confidencialidad los datos personales de los que sea titular, que estén incluidos en un banco de datos.

2. El responsable o usuario del banco de datos, debe proceder a la rectificación, supresión o actualización de los datos personales del afectado, realizando las operaciones necesarias a tal fin en el plazo máximo de cinco días hábiles de recibido el reclamo del titular de los datos o advertido el error o falsedad.

3. El incumplimiento de esta obligación dentro del término acordado en el inciso precedente, habilitará al interesado a promover sin más la acción de protección de los datos personales o de hábeas data prevista en la presente ley.

4. En el supuesto de cesión, o transferencia de datos, el responsable o usuario del banco de datos debe notificar la rectificación o supresión al cesionario dentro del quinto día hábil de efectuado el tratamiento del dato.

5. La supresión no procede cuando pudiese causar perjuicios a derechos o intereses legítimos de terceros, o cuando existiera una obligación legal de conservar los datos.

6. Durante el proceso de verificación y rectificación del error o falsedad de la información que se trate, el responsable o usuario del banco de datos deberá o bien



bloquear el archivo, o consignar al proveer información relativa al mismo la circunstancia de que se encuentra sometida a revisión.

7. Los datos personales deben ser conservados durante los plazos previstos en las disposiciones aplicables o en su caso, en las contractuales entre el responsable o usuario del banco de datos y el titular de los datos. ARTICULO 17. — (Excepciones).

1. Los responsables o usuarios de bancos de datos públicos pueden, mediante decisión fundada, denegar el acceso, rectificación o la supresión en función de la protección de la defensa de la Nación, del orden y la seguridad públicos, o de la protección de los derechos e intereses de terceros.

2. La información sobre datos personales también puede ser denegada por los responsables o usuarios de bancos de datos públicos, cuando de tal modo se pudieran obstaculizar actuaciones judiciales o administrativas en curso vinculadas a la investigación sobre el cumplimiento de obligaciones tributarias o previsionales, el desarrollo de funciones de control de la salud y del medio ambiente, la investigación de delitos penales y la verificación de infracciones administrativas. La resolución que así lo disponga debe ser fundada y notificada al afectado.

3. Sin perjuicio de lo establecido en los incisos anteriores, se deberá brindar acceso a los registros en cuestión en la oportunidad en que el afectado tenga que ejercer su derecho de defensa. ARTICULO 18. — (Comisiones legislativas).

Las Comisiones de Defensa Nacional y la Comisión Bicameral de Fiscalización de los Organos y Actividades de Seguridad Interior e Inteligencia del Congreso de la Nación y la Comisión de Seguridad Interior de la Cámara de Diputados de la Nación, o las que las sustituyan, tendrán acceso a los archivos o bancos de datos referidos en el artículo 23 inciso 2 por razones fundadas y en aquellos aspectos que constituyan materia de competencia de tales Comisiones. ARTICULO 19. — (Gratuidad).

La rectificación, actualización o supresión de datos personales inexactos o incompletos que obren en registros públicos o privados se efectuará sin cargo alguno para el interesado. ARTICULO 20. — (Impugnación de valoraciones personales).

1. Las decisiones judiciales o los actos administrativos que impliquen apreciación o valoración de conductas humanas, no podrán tener como único fundamento el resultado del tratamiento informatizado de datos personales que suministren una definición del perfil o personalidad del interesado.

2. Los actos que resulten contrarios a la disposición precedente serán insanablemente nulos.

CAPÍTULO IV USUARIOS Y RESPONSABLES DE ARCHIVOS, REGISTROS Y BANCOS DE DATOS ARTICULO 21. — (Registro de archivos de datos. Inscripción).

1. Todo archivo, registro, base o banco de datos público, y privado destinado a proporcionar informes debe inscribirse en el Registro que al efecto habilite el organismo de control.



2. El registro de archivos de datos debe comprender como mínimo la siguiente información:

a) Nombre y domicilio del responsable; b) Características y finalidad del archivo; c) Naturaleza de los datos personales contenidos en cada archivo; d) Forma de recolección y actualización de datos; e) Destino de los datos y personas físicas o de existencia ideal a las que pueden

ser transmitidos; f) Modo de interrelacionar la información registrada; g) Medios utilizados para garantizar la seguridad de los datos, debiendo detallar la

categoría de personas con acceso al tratamiento de la información; h) Tiempo de conservación de los datos; i) Forma y condiciones en que las personas pueden acceder a los datos referidos a

ellas y los procedimientos a realizar para la rectificación o actualización de los datos.

3) Ningún usuario de datos podrá poseer datos personales de naturaleza distinta a los declarados en el registro.

El incumplimiento de estos requisitos dará lugar a las sanciones administrativas previstas en el capítulo VI de la presente ley. ARTICULO 22. — (Archivos, registros o bancos de datos públicos).

1. Las normas sobre creación, modificación o supresión de archivos, registros o bancos de datos pertenecientes a organismos públicos deben hacerse por medio de disposición general publicada en el Boletín Oficial de la Nación o diario oficial.

2. Las disposiciones respectivas, deben indicar: a) Características y finalidad del archivo; b) Personas respecto de las cuales se pretenda obtener datos y el carácter

facultativo u obligatorio de su suministro por parte de aquéllas; c) Procedimiento de obtención y actualización de los datos; d) Estructura básica del archivo, informatizado o no, y la descripción de la

naturaleza de los datos personales que contendrán; e) Las cesiones, transferencias o interconexiones previstas; f) Organos responsables del archivo, precisando dependencia jerárquica en su

caso; g) Las oficinas ante las que se pudiesen efectuar las reclamaciones en ejercicio de

los derechos de acceso, rectificación o supresión. 3. En las disposiciones que se dicten para la supresión de los registros informatizados

se esta establecerá el destino de los mismos o las medidas que se adopten para su destrucción. ARTICULO 23. — (Supuestos especiales).

1. Quedarán sujetos al régimen de la presente ley, los datos personales que por haberse almacenado para fines administrativos, deban ser objeto de registro permanente en los bancos de datos de las fuerzas armadas, fuerzas de seguridad, organismos policiales o de inteligencia; y aquellos sobre antecedentes personales que proporcionen dichos bancos de datos a las autoridades administrativas o judiciales que los requieran en virtud de disposiciones legales.

2. El tratamiento de datos personales con fines de defensa nacional o seguridad pública por parte de las fuerzas armadas, fuerzas de seguridad, organismos policiales o inteligencia, sin consentimiento de los afectados, queda limitado a aquellos supuestos y categoría de datos que resulten necesarios para el estricto cumplimiento de las misiones legalmente asignadas a aquéllos para la defensa nacional, la seguridad pública o para la represión de los delitos. Los archivos, en tales casos, deberán ser específicos y establecidos al efecto, debiendo clasificarse por categorías, en función de su grado de fiabilidad.



3. Los datos personales registrados con fines policiales se cancelarán cuando no sean necesarios para las averiguaciones que motivaron su almacenamiento. ARTICULO 24. — (Archivos, registros o bancos de datos privados).

Los particulares que formen archivos, registros o bancos de datos que no sean para un uso exclusivamente personal deberán registrarse conforme lo previsto en el artículo 21. ARTICULO 25. — (Prestación de servicios informatizados de datos personales).

1. Cuando por cuenta de terceros se presten servicios de tratamiento de datos personales, éstos no podrán aplicarse o utilizarse con un fin distinto al que figure en el contrato de servicios, ni cederlos a otras personas, ni aun para su conservación.

2. Una vez cumplida la prestación contractual los datos personales tratados deberán ser destruidos, salvo que medie autorización expresa de aquel por cuenta de quien se prestan tales servicios cuando razonablemente se presuma la posibilidad de ulteriores encargos, en cuyo caso se podrá almacenar con las debidas condiciones de seguridad por un período de hasta dos años. ARTICULO 26. — (Prestación de servicios de información crediticia).

1. En la prestación de servicios de información crediticia sólo pueden tratarse datos personales de carácter patrimonial relativos a la solvencia económica y al crédito, obtenidos de fuentes accesibles al público o procedentes de informaciones facilitadas por el interesado o con su consentimiento.

2. Pueden tratarse igualmente datos personales relativos al cumplimiento o incumplimiento de obligaciones de contenido patrimonial, facilitados por el acreedor o por quien actúe por su cuenta o interés.

3. A solicitud del titular de los datos, el responsable o usuario del banco de datos, le comunicará las informaciones, evaluaciones y apreciaciones que sobre el mismo hayan sido comunicadas durante los últimos seis meses y el nombre y domicilio del cesionario en el supuesto de tratarse de datos obtenidos por cesión.

4. Sólo se podrán archivar, registrar o ceder los datos personales que sean significativos para evaluar la solvencia económico-financiera de los afectados durante los últimos cinco años. Dicho plazo se reducirá a dos años cuando el deudor cancele o de otro modo extinga la obligación, debiéndose hace constar dicho hecho.

5. La prestación de servicios de información crediticia no requerirá el previo consentimiento del titular de los datos a los efectos de su cesión, ni la ulterior comunicación de ésta, cuando estén relacionados con el giro de las actividades comerciales o crediticias de los cesionarios. ARTICULO 27. — (Archivos, registros o bancos de datos con fines de publicidad).

1. En la recopilación de domicilios, reparto de documentos, publicidad o venta directa y otras actividades análogas, se podrán tratar datos que sean aptos para establecer perfiles determinados con fines promocionales, comerciales o publicitarios; o permitan establecer hábitos de consumo, cuando éstos figuren en documentos accesibles al público o hayan sido facilitados por los propios titulares u obtenidos con su consentimiento.

2. En los supuestos contemplados en el presente artículo, el titular de los datos podrá ejercer el derecho de acceso sin cargo alguno.

3. El titular podrá en cualquier momento solicitar el retiro o bloqueo de su nombre de los bancos de datos a los que se refiere el presente artículo. ARTICULO 28. — (Archivos, registros o bancos de datos relativos a encuestas).



1. Las normas de la presente ley no se aplicarán a las encuestas de opinión, mediciones y estadísticas relevadas conforme a Ley 17.622, trabajos de prospección de mercados, investigaciones científicas o médicas y actividades análogas, en la medida que los datos recogidos no puedan atribuirse a una persona determinada o determinable.

2. Si en el proceso de recolección de datos no resultara posible mantener el anonimato, se deberá utilizar una técnica de disociación, de modo que no permita identificar a persona alguna.

CAPÍTULO V CONTROL ARTICULO 29. — (Órgano de Control).

1. El órgano de control deberá realizar todas las acciones necesarias para el cumplimiento de los objetivos y demás disposiciones de la presente ley. A tales efectos tendrá las siguientes funciones y atribuciones:

a) Asistir y asesorar a las personas que lo requieran acerca de los alcances de la presente y de los medios legales de que disponen para la defensa de los derechos que ésta garantiza;

b) Dictar las normas y reglamentaciones que se deben observar en el desarrollo de las actividades comprendidas por esta ley;

c) Realizar un censo de archivos, registros o bancos de datos alcanzados por la ley y mantener el registro permanente de los mismos;

d) Controlar la observancia de las normas sobre integridad y seguridad de datos por parte de los archivos, registros o bancos de datos. A tal efecto podrá solicitar autorización judicial para acceder a locales, equipos, o programas de tratamiento de datos a fin de verificar infracciones al cumplimiento de la presente ley;

e) Solicitar información a las entidades públicas y privadas, las que deberán proporcionar los antecedentes, documentos, programas u otros elementos relativos al tratamiento de los datos personales que se le requieran. En estos casos, la autoridad deberá garantizar la seguridad y confidencialidad de la información y elementos suministrados;

f) Imponer las sanciones administrativas que en su caso correspondan por violación a las normas de la presente ley y de las reglamentaciones que se dicten en su consecuencia;

g) Constituirse en querellante en las acciones penales que se promovieran por violaciones a la presente ley;

h) Controlar el cumplimiento de los requisitos y garantías que deben reunir los archivos o bancos de datos privados destinados a suministrar informes, para obtener la correspondiente inscripción en el Registro creado por esta ley.

2. El órgano de control gozará de autonomía funcional y actuará como órgano descentralizado en el ámbito del Ministerio de Justicia y Derechos Humanos de la Nación.

3. El órgano de control será dirigido y administrado por un Director designado por el término de cuatro (4) años, por el Poder Ejecutivo con acuerdo del Senado de la Nación, debiendo ser seleccionado entre personas con antecedentes en la materia.

El Director tendrá dedicación exclusiva en su función, encontrándose alcanzado por las incompatibilidades fijadas por ley para los funcionarios públicos y podrá ser removido por el Poder Ejecutivo por mal desempeño de sus funciones. ARTICULO 30. — (Códigos de conducta).



1. Las asociaciones o entidades representativas de responsables o usuarios de bancos de datos de titularidad privada podrán elaborar códigos de conducta de práctica profesional, que establezcan normas para el tratamiento de datos personales que tiendan a asegurar y mejorar las condiciones de operación de los sistemas de información en función de los principios establecidos en la presente ley.

2. Dichos códigos deberán ser inscriptos en el registro que al efecto lleve el organismo de control, quien podrá denegar la inscripción cuando considere que no se ajustan a las disposiciones legales y reglamentarias sobre la materia.

CAPÍTULO VI SANCIONES ARTICULO 31. — (Sanciones administrativas).

1. Sin perjuicio de las responsabilidades administrativas que correspondan en los casos de responsables o usuarios de bancos de datos públicos; de la responsabilidad por daños y perjuicios derivados de la inobservancia de la presente ley, y de las sanciones penales que correspondan, el organismo de control podrá aplicar las sanciones de apercibimiento, suspensión, multa de mil pesos ($ 1.000.-) a cien mil pesos ($ 100.000.-), clausura o cancelación del archivo, registro o banco de datos.

2. La reglamentación determinará las condiciones y procedimientos para la aplicación de las sanciones previstas, las que deberán graduarse en relación a la gravedad y extensión de la violación y de los perjuicios derivados de la infracción, garantizando el principio del debido proceso. ARTICULO 32. — (Sanciones penales).

1. Incorpórase como artículo 117 bis del Código Penal, el siguiente: "1°. Será reprimido con la pena de prisión de un mes a dos años el que insertara

o hiciera insertar a sabiendas datos falsos en un archivo de datos personales. 2°. La pena será de seis meses a tres años, al que proporcionara a un tercero a

sabiendas información falsa contenida en un archivo de datos personales. 3°. La escala penal se aumentará en la mitad del mínimo y del máximo, cuando

del hecho se derive perjuicio a alguna persona. 4°. Cuando el autor o responsable del ilícito sea funcionario público en ejercicio de

sus funciones, se le aplicará la accesoria de inhabilitación para el desempeño de cargos públicos por el doble del tiempo que el de la condena".

2. Incorpórase como artículo 157 bis del Código Penal el siguiente: "Será reprimido con la pena de prisión de un mes a dos años el que: 1°. A sabiendas e ilegítimamente, o violando sistemas de confidencialidad y

seguridad de datos, accediere, de cualquier forma, a un banco de datos personales;

2°. Revelare a otro información registrada en un banco de datos personales cuyo secreto estuviere obligado a preservar por disposición de una ley.

Cuando el autor sea funcionario público sufrirá, además, pena de inhabilitación especial de uno a cuatro años".

CAPÍTULO VII ACCIÓN DE PROTECCIÓN DE LOS DATOS PERSONALES ARTICULO 33. — (Procedencia).

1. La acción de protección de los datos personales o de hábeas data procederá:



a) para tomar conocimiento de los datos personales almacenados en archivos, registros o bancos de datos públicos o privados destinados a proporcionar informes, y de la finalidad de aquéllos;

b) en los casos en que se presuma la falsedad, inexactitud, desactualización de la información de que se trata, o el tratamiento de datos cuyo registro se encuentra prohibido en la presente ley, para exigir su rectificación, supresión, confidencialidad o actualización.

ARTICULO 34. — (Legitimación activa).

La acción de protección de los datos personales o de hábeas data podrá ser ejercida por el afectado, sus tutores o curadores y los sucesores de las personas físicas, sean en línea directa o colateral hasta el segundo grado, por sí o por intermedio de apoderado.

Cuando la acción sea ejercida por personas de existencia ideal, deberá ser interpuesta por sus representantes legales, o apoderados que éstas designen al efecto.

En el proceso podrá intervenir en forma coadyuvante el Defensor del Pueblo. ARTICULO 35. — (Legitimación pasiva).

La acción procederá respecto de los responsables y usuarios de bancos de datos públicos, y de los privados destinados a proveer informes. ARTICULO 36. — (Competencia).

Será competente para entender en esta acción el juez del domicilio del actor; el del domicilio del demandado; el del lugar en el que el hecho o acto se exteriorice o pudiera tener efecto, a elección del actor.

Procederá la competencia federal: a) cuando se interponga en contra de archivos de datos públicos de organismos

nacionales, y b) cuando los archivos de datos se encuentren interconectados en redes

interjurisdicciones, nacionales o internacionales. ARTICULO 37. — (Procedimiento aplicable).

La acción de hábeas data tramitará según las disposiciones de la presente ley y por el procedimiento que corresponde a la acción de amparo común y supletoriamente por las normas del Código Procesal Civil y Comercial de la Nación, en lo atinente al juicio sumarísimo. ARTICULO 38. — (Requisitos de la demanda).

1. La demanda deberá interponerse por escrito, individualizando con la mayor precisión posible el nombre y domicilio del archivo, registro o banco de datos y, en su caso, el nombre del responsable o usuario del mismo.

En el caso de los archivos, registros o bancos públicos, se procurará establecer el organismo estatal del cual dependen.

2. El accionante deberá alegar las razones por las cuales entiende que en el archivo, registro o banco de datos individualizado obra información referida a su persona; los motivos por los cuales considera que la información que le atañe resulta discriminatoria, falsa o inexacta y justificar que se han cumplido los recaudos que hacen al ejercicio de los derechos que le reconoce la presente ley.

3. El afectado podrá solicitar que mientras dure el procedimiento, el registro o banco de datos asiente que la información cuestionada está sometida a un proceso judicial.



4. El Juez podrá disponer el bloqueo provisional del archivo en lo referente al dato personal motivo del juicio cuando sea manifiesto el carácter discriminatorio, falso o inexacto de la información de que se trate.

5. A los efectos de requerir información al archivo, registro o banco de datos involucrado, el criterio judicial de apreciación de las circunstancias requeridas en los puntos 1 y 2 debe ser amplio. ARTICULO 39. — (Trámite).

1. Admitida la acción el juez requerirá al archivo, registro o banco de datos la remisión de la información concerniente al accionante. Podrá asimismo solicitar informes sobre el soporte técnico de datos, documentación de base relativa a la recolección y cualquier otro aspecto que resulte conducente a la resolución de la causa que estime procedente.

2. El plazo para contestar el informe no podrá ser mayor de cinco días hábiles, el que podrá ser ampliado prudencialmente por el juez. ARTICULO 40. — (Confidencialidad de la información).

1. Los registros, archivos o bancos de datos privados no podrán alegar la confidencialidad de la información que se les requiere salvo el caso en que se afecten las fuentes de información periodística.

2. Cuando un archivo, registro o banco de datos público se oponga a la remisión del informe solicitado con invocación de las excepciones al derecho de acceso, rectificación o supresión, autorizadas por la presente ley o por una ley específica; deberá acreditar los extremos que hacen aplicable la excepción legal. En tales casos, el juez podrá tomar conocimiento personal y directo de los datos solicitados asegurando el mantenimiento de su confidencialidad. ARTICULO 41. — (Contestación del informe).

Al contestar el informe, el archivo, registro o banco de datos deberá expresar las razones por las cuales incluyó la información cuestionada y aquellas por las que no evacuó el pedido efectuado por el interesado, de conformidad a lo establecido en los artículos 13 a 15 de la ley. ARTICULO 42. — (Ampliación de la demanda).

Contestado el informe, el actor podrá, en el término de tres días, ampliar el objeto de la demanda solicitando la supresión, rectificación, confidencialidad o actualización de sus datos personales, en los casos que resulte procedente a tenor de la presente ley, ofreciendo en el mismo acto la prueba pertinente. De esta presentación se dará traslado al demandado por el término de tres días. ARTICULO 43. — (Sentencia).

1. Vencido el plazo para la contestación del informe o contestado el mismo, y en el supuesto del artículo 42, luego de contestada la ampliación, y habiendo sido producida en su caso la prueba, el juez dictará sentencia.

2. En el caso de estimarse procedente la acción, se especificará si la información debe ser suprimida, rectificada, actualizada o declarada confidencial, estableciendo un plazo para su cumplimiento.

3. El rechazo de la acción no constituye presunción respecto de la responsabilidad en que hubiera podido incurrir el demandante.

4. En cualquier caso, la sentencia deberá ser comunicada al organismo de control, que deberá llevar un registro al efecto.



ARTICULO 44. — (Ámbito de aplicación).

Las normas de la presente ley contenidas en los Capítulos I, II, III y IV, y artículo 32 son de orden público y de aplicación en lo pertinente en todo el territorio nacional.

Se invita a las provincias a adherir a las normas de esta ley que fueren de aplicación exclusiva en jurisdicción nacional.

La jurisdicción federal regirá respecto de los registros, archivos, bases o bancos de datos interconectados en redes de alcance interjurisdiccional, nacional o internacional. ARTICULO 45. — El Poder Ejecutivo Nacional deberá reglamentar la presente ley y establecer el organismo de control dentro de los ciento ochenta días de su promulgación. ARTICULO 46. — (Disposiciones transitorias).

Los archivos, registros, bases o bancos de datos destinados a proporcionar informes, existentes al momento de la sanción de la presente ley, deberán inscribirse en el registro que se habilite conforme a lo dispuesto en el artículo 21 y adecuarse a lo que dispone el presente régimen dentro del plazo que al efecto establezca la reglamentación. ARTICULO 47. — Los bancos de datos prestadores de servicios de información crediticia deberán suprimir, o en su caso, omitir asentar, todo dato referido al incumplimiento o mora en el pago de una obligación, si ésta hubiere sido cancelada al momento de la entrada en vigencia de la presente ley. ARTICULO 48. — Comuníquese al Poder Ejecutivo.

DADA EN LA SALA DE SESIONES DEL CONGRESO ARGENTINO, EN BUENOS AIRES, A LOS CUATRO DIAS DEL MES DE OCTUBRE DEL AÑO DOS MIL.

— REGISTRADO BAJO EL N° 25.326 — —

RAFAEL PASCUAL. — JOSE GENOUD. — Guillermo Aramburu. — Mario L. Pontaquarto. NOTA: Los textos en negrita fueron observados.

Decreto 1558/2001 - Reglamentación Ley 25.326

Apruébase la reglamentación de la Ley Nº 25.326. Principios generales relativos a la protección de datos. Derechos de los titulares de los datos. Usuarios y responsables de archivos, registros y bancos de datos. Control. Sanciones.

Bs. As., 29/11/2001 VISTO el expediente Nº 128.949/01 del registro del MINISTERIO DE JUSTICIA Y DERECHOS HUMANOS, la Ley Nº 25.326, y CONSIDERANDO:

Que el artículo 45 de la mencionada Ley establece que el PODER EJECUTIVO NACIONAL deberá reglamentar la misma y establecer el órgano de control a que se refiere su artículo 29 dentro de los CIENTO OCHENTA (180) días de su promulgación.

Que el artículo 46 de la Ley citada establece que la reglamentación fijará el plazo dentro del cual los archivos de datos destinados a proporcionar informes existentes al



momento de la sanción de dicha Ley deberán inscribirse en el Registro a que se refiere su artículo 21 y adecuarse a lo que dispone el régimen establecido en dicha norma.

Que el artículo 31, inciso 2, de la Ley Nº 25.326 dispone que la reglamentación determinará las condiciones y procedimientos para la aplicación de sanciones, en los términos que dicha norma establece.

Que la DIRECCION GENERAL DE ASUNTOS JURIDICOS del MINISTERIO DE JUSTICIA Y DERECHOS HUMANOS, la DIRECCION GENERAL DE ASUNTOS JURIDICOS de la SUBSECRETARIA DE ASUNTOS LEGALES de la SECRETARIA LEGAL Y TECNICA de la PRESIDENCIA DE LA NACION y la PROCURACION DEL TESORO DE LA NACION han tomado la intervención que les compete.

Que la presente medida se dicta en uso de las facultades conferidas por el artículo 99, inciso 2) de la CONSTITUCION NACIONAL.

Por ello, EL PRESIDENTE DE LA NACION ARGENTINA DECRETA:

Art. 1º — Apruébase la reglamentación de la Ley Nº 25.326 de Protección de los Datos Personales, que como anexo I forma parte del presente.

Art. 2º — Establécese en CIENTO OCHENTA (180) días el plazo previsto en el artículo 46 de la Ley Nº 25.326.

Art. 3º — Invítase a las Provincias y a la CIUDAD AUTONOMA DE BUENOS AIRES a adherir a las normas de exclusiva aplicación nacional de esta reglamentación.

Art. 4º — Comuníquese, publíquese, dése a la Dirección Nacional del Registro Oficial y archívese. —DE LA RUA. — Chrystian G. Colombo. — Jorge E. De La Rúa. ANEXO I REGLAMENTACION DE LA LEY Nº 25.326 CAPITULO I DISPOSICIONES GENERALES

ARTICULO 1º.- A los efectos de esta reglamentación, quedan comprendidos en el concepto de archivos, registros, bases o bancos de datos privados destinados a dar informes, aquellos que exceden el uso exclusivamente personal y los que tienen como finalidad la cesión o transferencia de datos personales, independientemente de que la circulación del informe o la información producida sea a título oneroso o gratuito.

ARTICULO 2º.- Sin reglamentar. CAPITULO II PRINCIPIOS GENERALES RELATIVOS A LA PROTECCION DE DATOS

ARTICULO 3º.- Sin reglamentar.

ARTICULO 4º.- Para determinar la lealtad y buena fe en la obtención de los datos personales, así como el destino que a ellos se asigne, se deberá analizar el procedimiento efectuado para la recolección y, en particular, la información que se haya proporcionado al titular de los datos de acuerdo con el artículo 6º de la Ley Nº 25.326.

Cuando la obtención o recolección de los datos personales fuese lograda por interconexión o tratamiento de archivos, registros, bases o bancos de datos, se deberá analizar la fuente de información y el destino previsto por el responsable o usuario para los datos personales obtenidos.

El dato que hubiera perdido vigencia respecto de los fines para los que se hubiese obtenido o recolectado debe ser suprimido por el responsable o usuario sin necesidad de que lo requiera el titular de los datos.

La DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES efectuará controles de oficio sobre el cumplimiento de este principio legal, y aplicará las sanciones pertinentes al responsable o usuario en los casos que correspondiere.



La DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES procederá, ante el pedido de un interesado o de oficio ante la sospecha de una ilegalidad, a verificar el cumplimiento de las disposiciones legales y reglamentarias en orden a cada una de las siguientes etapas del uso y aprovechamiento de datos personales:

a) legalidad de la recolección o toma de información personal; b) legalidad en el intercambio de datos y en la transmisión a terceros o en la

interrelación entre ellos; c) legalidad en la cesión propiamente dicha; d) legalidad de los mecanismos de control interno y externo del archivo, registro,

base o banco de datos.

ARTICULO 5º.- El consentimiento informado es el que está precedido de una explicación, al titular de los datos, en forma adecuada a su nivel social y cultural, de la información a que se refiere el artículo 6º de la Ley Nº 25.326.

La DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES establecerá los requisitos para que el consentimiento pueda ser prestado por un medio distinto a la forma escrita, el cual deberá asegurar la autoría e integridad de la declaración.

El consentimiento dado para el tratamiento de datos personales puede ser revocado en cualquier tiempo. La revocación no tiene efectos retroactivos.

A los efectos del artículo 5º, inciso 2 e), de la Ley Nº 25.326 el concepto de entidad financiera comprende a las personas alcanzadas por la Ley Nº 21.526 y a las empresas emisoras de tarjetas de crédito, los fideicomisos financieros, las exentidades financieras liquidadas por el BANCO CENTRAL DE LA REPUBLICA ARGENTINA y los sujetos que expresamente incluya la Autoridad de Aplicación de la mencionada Ley.

No es necesario el consentimiento para la información que se describe en los incisos a), b), c) y d) del artículo 39 de la Ley Nº 21.526.

En ningún caso se afectará el secreto bancario, quedando prohibida la divulgación de datos relativos a operaciones pasivas que realicen las entidades financieras con sus clientes, de conformidad con lo dispuesto en los artículos 39 y 40 de la Ley Nº 21.526.

ARTICULOS 6, 7 y 8.- Sin reglamentar.

ARTICULO 9º.- La DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES promoverá la cooperación entre sectores públicos y privados para la elaboración e implantación de medidas, prácticas y procedimientos que susciten la confianza en los sistemas de información, así como en sus modalidades de provisión y utilización.

ARTICULO 10.- Sin reglamentar.

ARTICULO 11.- Al consentimiento para la cesión de los datos le son aplicables las disposiciones previstas en el artículo 5º de la Ley Nº 25.326 y el artículo 5º de esta reglamentación.

En el caso de archivos o bases de datos públicas dependientes de un organismo oficial que por razón de sus funciones específicas estén destinadas a la difusión al público en general, el requisito relativo al interés legítimo del cesionario se considera implícito en las razones de interés general que motivaron el acceso público irrestricto.

La cesión masiva de datos personales de registros públicos a registros privados sólo puede ser autorizada por ley o por decisión del funcionario responsable, si los datos son de acceso público y se ha garantizado el respeto a los principios de protección establecidos en la Ley Nº 25.326. No es necesario acto administrativo alguno en los casos en que la ley disponga el acceso a la base de datos pública en forma irrestricta. Se entiende por cesión masiva de datos personales la que comprende a un grupo colectivo de personas.

La DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES fijará los estándares de seguridad aplicables a los mecanismos de disociación de datos.



El cesionario a que se refiere el artículo 11, inciso 4, de la Ley Nº 25.326, podrá ser eximido total o parcialmente de responsabilidad si demuestra que no se le puede imputar el hecho que ha producido el daño.

ARTICULO 12.- La prohibición de transferir datos personales hacia países u organismos internacionales o supranacionales que no proporcionen niveles de protección adecuados, no rige cuando el titular de los datos hubiera consentido expresamente la cesión.

No es necesario el consentimiento en caso de transferencia de datos desde un registro público que esté legalmente constituido para facilitar información al público y que esté abierto a la consulta por el público en general o por cualquier persona que pueda demostrar un interés legítimo, siempre que se cumplan, en cada caso particular, las condiciones legales y reglamentarias para la consulta.

Facúltase a la DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES a evaluar, de oficio o a pedido de parte interesada, el nivel de protección proporcionado por las normas de un Estado u organismo internacional. Si llegara a la conclusión de que un Estado u organismo no protege adecuadamente a los datos personales, elevará al PODER EJECUTIVO NACIONAL un proyecto de decreto para emitir tal declaración. El proyecto deberá ser refrendado por los Ministros de Justicia y Derechos Humanos y de Relaciones Exteriores, Comercio Internacional y Culto.

El carácter adecuado del nivel de protección que ofrece un país u organismo internacional se evaluará atendiendo a todas las circunstancias que concurran en una transferencia o en una categoría de transferencias de datos; en particular, se tomará en consideración la naturaleza de los datos, la finalidad y la duración de tratamiento o de los tratamientos previstos, el lugar de destino final, las normas de derecho, generales o sectoriales, vigentes en el país de que se trate, así como las normas profesionales, códigos de conducta y las medidas de seguridad en vigor en dichos lugares, o que resulten aplicables a los organismos internacionales o supranacionales.

Se entiende que un Estado u organismo internacional proporciona un nivel adecuado de protección cuando dicha tutela se deriva directamente del ordenamiento jurídico vigente, o de sistemas de autorregulación, o del amparo que establezcan las cláusulas contractuales que prevean la protección de datos personales. CAPITULO III DERECHOS DE LOS TITULARES DE DATOS

ARTICULO 13.- Sin reglamentar.

ARTICULO 14.- La solicitud a que se refiere el artículo 14, inciso 1, de la Ley Nº 25.326, no requiere de fórmulas específicas, siempre que garantice la identificación del titular. Se puede efectuar de manera directa, presentándose el interesado ante el responsable o usuario del archivo, registro, base o banco de datos, o de manera indirecta, a través de la intimación fehaciente por medio escrito que deje constancia de recepción. También pueden ser utilizados otros servicios de acceso directo o semidirecto como los medios electrónicos, las líneas telefónicas, la recepción del reclamo en pantalla u otro medio idóneo a tal fin. En cada supuesto, se podrán ofrecer preferencias de medios para conocer la respuesta requerida.

Si se tratara de archivos o bancos de datos públicos dependientes de un organismo oficial destinados a la difusión al público en general, las condiciones para el ejercicio del derecho de acceso podrán ser propuestas por el organismo y aprobadas por la DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES, la cual deberá asegurar que los procedimientos sugeridos no vulneren ni restrinjan en modo alguno las garantías propias de ese derecho.

El derecho de acceso permitirá: a) conocer si el titular de los datos se encuentra o no en el archivo, registro, base o

banco de datos;



b) conocer todos los datos relativos a su persona que constan en el archivo; c) solicitar información sobre las fuentes y los medios a través de los cuales se

obtuvieron sus datos; d) solicitar las finalidades para las que se recabaron; e) conocer el destino previsto para los datos personales; f) saber si el archivo está registrado conforme a las exigencias de la Ley Nº 25.326. Vencido el plazo para contestar fijado en el artículo 14, inciso 2 de la Ley Nº 25.326,

el interesado podrá ejercer la acción de protección de los datos personales y denunciar el hecho ante la DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES a los fines del control pertinente de este organismo.

En el caso de datos de personas fallecidas, deberá acreditarse el vínculo mediante la declaratoria de herederos correspondiente, o por documento fehaciente que verifique el carácter de sucesor universal del interesado.

ARTICULO 15.- El responsable o usuario del archivo, registro, base o banco de datos deberá contestar la solicitud que se le dirija, con independencia de que figuren o no datos personales del afectado, debiendo para ello valerse de cualquiera de los medios autorizados en el artículo 15, inciso 3, de la Ley Nº 25.326, a opción del titular de los datos, o las preferencias que el interesado hubiere expresamente manifestado al interponer el derecho de acceso.

La DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES elaborará un formulario modelo que facilite el derecho de acceso de los interesados.

Podrán ofrecerse como medios alternativos para responder el requerimiento, los siguientes:

a) visualización en pantalla; b) informe escrito entregado en el domicilio del requerido; c) informe escrito remitido al domicilio denunciado por el requirente; d) transmisión electrónica de la respuesta, siempre que esté garantizada la identidad

del interesado y la confidencialidad, integridad y recepción de la información; e) cualquier otro procedimiento que sea adecuado a la configuración e implantación

material del archivo, registro, base o banco de datos, ofrecido por el responsable o usuario del mismo.

ARTICULO 16.- En las disposiciones de los artículos 16 a 22 y 38 a 43 de la Ley Nº 25.326 en que se menciona a algunos de los derechos de rectificación, actualización, supresión y confidencialidad, se entiende que tales normas se refieren a todos ellos.

En el caso de los archivos o bases de datos públicas conformadas por cesión de información suministrada por entidades financieras, administradoras de fondos de jubilaciones y pensiones y entidades aseguradoras, de conformidad con el artículo 5º, inciso 2, de la Ley Nº 25.326, los derechos de rectificación, actualización, supresión y confidencialidad deben ejercerse ante la entidad cedente que sea parte en la relación jurídica a que se refiere el dato impugnado. Si procediera el reclamo, la entidad respectiva debe solicitar al BANCO CENTRAL DE LA REPUBLICA ARGENTINA, a la SUPERINTENDENCIA DE ADMINISTRADORAS DE FONDOS DE JUBILACIONES Y PENSIONES o a la SUPERINTENDENCIA DE SEGUROS DE LA NACION, según el caso, que sean practicadas las modificaciones necesarias en sus bases de datos.

Toda modificación debe ser comunicada a través de los mismos medios empleados para la divulgación de la información.

Los responsables o usuarios de archivos o bases de datos públicos de acceso público irrestricto pueden cumplir la notificación a que se refiere el artículo 16, inciso 4, de la Ley Nº 25.326 mediante la modificación de los datos realizada a través de los mismos medios empleados para su divulgación.

ARTICULOS 17, 18, 19 y 20.- Sin reglamentar. CAPITULO IV



USUARIOS Y RESPONSABLES DE ARCHIVOS, REGISTROS Y BANCOS DE DATOS

ARTICULO 21.- El registro e inscripción de archivos, registros, bases o bancos de datos públicos, y privados destinados a dar información, se habilitará una vez publicada esta reglamentación en el Boletín Oficial.

Deben inscribirse los archivos, registros, bases o bancos de datos públicos y los privados a que se refiere el artículo 1º de esta reglamentación.

A los fines de la inscripción de los archivos, registros, bases y bancos de datos con fines de publicidad, los responsables deben proceder de acuerdo con lo establecido en el artículo 27, cuarto párrafo, de esta reglamentación.

ARTICULOS 22, 23 y 24.- Sin reglamentar.

ARTICULO 25.- Los contratos de prestación de servicios de tratamiento de datos personales deberán contener los niveles de seguridad previstos en la Ley Nº 25.326, esta reglamentación y las normas complementarias que dicte la DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES, como así también las obligaciones que surgen para los locatarios en orden a la confidencialidad y reserva que deben mantener sobre la información obtenida.

La realización de tratamientos por encargo deberá estar regulada por un contrato que vincule al encargado del tratamiento con el responsable o usuario del tratamiento y que disponga, en particular:

a) que el encargado del tratamiento sólo actúa siguiendo instrucciones del responsable del tratamiento;

b) que las obligaciones del artículo 9º de la Ley Nº 25.326 incumben también al encargado del tratamiento.

ARTICULO 26.- A los efectos del artículo 26, inciso 2, de la Ley Nº 25.326, se consideran datos relativos al cumplimiento o incumplimiento de obligaciones los referentes a los contratos de mutuo, cuenta corriente, tarjetas de crédito, fideicomiso, leasing, de créditos en general y toda otra obligación de contenido patrimonial, así como aquellos que permitan conocer el nivel de cumplimiento y la calificación a fin de precisar, de manera indubitable, el contenido de la información emitida.

En el caso de archivos o bases de datos públicos dependientes de un organismo oficial destinadas a la difusión al público en general, se tendrán por cumplidas las obligaciones que surgen del artículo 26, inciso 3, de la Ley Nº 25.326 en tanto el responsable de la base de datos le comunique al titular de los datos las informaciones, evaluaciones y apreciaciones que sobre el mismo hayan sido difundidas durante los últimos SEIS (6) meses.

Para apreciar la solvencia económico-financiera de una persona, conforme lo establecido en el artículo 26, inciso 4, de la Ley Nº 25.326, se tendrá en cuenta toda la información disponible desde el nacimiento de cada obligación hasta su extinción. En el cómputo de CINCO (5) años, éstos se contarán a partir de la fecha de la última información adversa archivada que revele que dicha deuda era exigible. Si el deudor acredita que la última información disponible coincide con la extinción de la deuda, el plazo se reducirá a DOS (2) años. Para los datos de cumplimiento sin mora no operará plazo alguno para la eliminación.

A los efectos del cálculo del plazo de DOS (2) años para conservación de los datos cuando el deudor hubiere cancelado o extinguido la obligación, se tendrá en cuenta la fecha precisa en que se extingue la deuda.

A los efectos de dar cumplimiento a lo dispuesto por el artículo 26, inciso 5, de la Ley Nº 25.326, el BANCO CENTRAL DE LA REPUBLICA ARGENTINA deberá restringir el acceso a sus bases de datos disponibles en Internet, para el caso de información sobre personas físicas, exigiendo el ingreso del número de documento nacional de identidad o código único de identificación tributaria o laboral del titular de los datos, obtenidos por el cesionario a través de una relación contractual o comercial previa.



ARTICULO 27.- Podrán recopilarse, tratarse y cederse datos con fines de publicidad sin consentimiento de su titular, cuando estén destinados a la formación de perfiles determinados, que categoricen preferencias y comportamientos similares de las personas, siempre que los titulares de los datos sólo se identifiquen por su pertenencia a tales grupos genéricos, con más los datos individuales estrictamente necesarios para formular la oferta a los destinatarios.

Las cámaras, asociaciones y colegios profesionales del sector que dispongan de un Código de Conducta homologado por la DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES, al que por estatuto adhieran obligatoriamente todos sus miembros, junto con la Autoridad de Aplicación, implementarán, dentro de los NOVENTA (90) días siguientes a la publicación de esta reglamentación, un sistema de retiro o bloqueo a favor del titular del dato que quiera ser excluido de las bases de datos con fines de publicidad. El retiro podrá ser total o parcial, bloqueando exclusivamente, a requerimiento del titular, el uso de alguno o algunos de los medios de comunicación en particular, como el correo, el teléfono, el correo electrónico u otros.

En toda comunicación con fines de publicidad que se realice por correo, teléfono, correo electrónico, Internet u otro medio a distancia a conocer, se deberá indicar, en forma expresa y destacada, la posibilidad del titular del dato de solicitar el retiro o bloqueo, total o parcial, de su nombre de la base de datos. A pedido del interesado, se deberá informar el nombre del responsable o usuario del banco de datos que proveyó la información. A los fines de garantizar el derecho de información del artículo 13 de la Ley Nº 25.326, se inscribirán únicamente las cámaras, asociaciones y colegios profesionales del sector que dispongan de un Código de Conducta homologado por la DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES, al que por estatuto adhieran obligatoriamente todos sus miembros. Al inscribirse, las cámaras, asociaciones y colegios profesionales deberán acompañar una nómina de sus asociados indicando nombre, apellido y domicilio.

Los responsables o usuarios de archivos, registros, bancos o bases de datos con fines de publicidad que no se encuentren adheridos a ningún Código de Conducta, cumplirán el deber de información inscribiéndose en el Registro a que se refiere el artículo 21 de la Ley Nº 25.326.

Los datos vinculados a la salud sólo podrán ser tratados, a fin de realizar ofertas de bienes y servicios, cuando hubieran sido obtenidos de acuerdo con la Ley Nº 25.326 y siempre que no causen discriminación, en el contexto de una relación entre el consumidor o usuario y los proveedores de servicios o tratamientos médicos y entidades sin fines de lucro. Estos datos no podrán transferirse a terceros sin el consentimiento previo, expreso e informado del titular de los datos. A dicho fin, este último debe recibir una noticia clara del carácter sensible de los datos que proporciona y de que no está obligado a suministrarlos, junto con la información de los artículos 6º y 11, inciso 1, de la Ley Nº 25.326 y la mención de su derecho a solicitar el retiro de la base de datos.

ARTICULO 28.- Los archivos, registros, bases o bancos de datos mencionados en el artículo 28 de la Ley Nº 25.326 son responsables y pasibles de las multas previstas en el artículo 31 de la ley citada cuando infrinjan sus disposiciones. CAPITULO V CONTROL

ARTICULO 29. - Créase la DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES, en el ámbito de la SECRETARIA DE JUSTICIA Y ASUNTOS LEGISLATIVOS del MINISTERIO DE JUSTICIA Y DERECHOS HUMANOS, como órgano de control de la Ley Nº 25.326.

El Director tendrá dedicación exclusiva en su función, ejercerá sus funciones con plena independencia y no estará sujeto a instrucciones.

La DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES se integrará con un Director Nacional, Nivel "A" con Función Ejecutiva I, designado por el PODER EJECUTIVO NACIONAL, por el plazo de CUATRO (4) años, debiendo ser seleccionado entre personas con



antecedentes en la materia, a cuyo fin facúltase al Ministro de Justicia y Derechos Humanos, o a quien lo sustituya en sus funciones, a efectuar la designación correspondiente, como excepción a lo dispuesto por el ANEXO I del Decreto Nº 993/91 y sus modificatorios. La Dirección contará con el personal jerárquico y administrativo que designe el Ministro de Justicia y Derechos Humanos aprovechando los recursos humanos existentes en la ADMINISTRACIÓN PUBLICA NACIONAL. El personal estará obligado a guardar secreto respecto de los datos de carácter personal de los que tome conocimiento en el desarrollo de sus funciones.

En el plazo de TREINTA (30) días hábiles posteriores a la asunción de su cargo, el Director Nacional presentará un proyecto de estructura organizativa y reglamentación interna, para su aprobación por el PODER EJECUTIVO NACIONAL y publicación en el Boletín Oficial.

La DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES se financiará a través de:

a) lo que recaude en concepto de tasas por los servicios que preste; b) el producido de las multas previstas en el artículo 31 de la Ley Nº 25.326; c) las asignaciones presupuestarias que se incluyan en la Ley de Presupuesto de la

Administración Nacional a partir del año 2002. Transitoriamente, desde la entrada en vigencia de la presente reglamentación y hasta el 31 de diciembre de 2001, el costo de la estructura será afrontado con el crédito presupuestario correspondiente

al MINISTERIO DE JUSTICIA Y DERECHOS HUMANOS para el año 2001, sin perjuicio de lo dispuesto en los subincisos a) y c) b) del párrafo anterior.

La DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES contará con un Consejo Consultivo, que se desempeñará "ad honorem", encargado de asesorar al Director Nacional en los asuntos de importancia, integrado por:

a) un representante del MINISTERIO DE JUSTICIA Y DERECHOS HUMANOS; b) un magistrado del MINISTERIO PUBLICO FISCAL con especialidad en la materia; c) un representante de los archivos privados destinados a dar información designado

por la Cámara que agrupe a las entidades nacionales de información crediticia; d) un representante de la FEDERACION DE ENTIDADES EMPRESARIAS DE

INFORMACIONES COMERCIALES DE LA REPUBLICA ARGENTINA; e) un representante del BANCO CENTRAL DE LA REPUBLICA ARGENTINA;

f) un representante de las empresas dedicadas al objeto previsto en el artículo 27 de la Ley Nº 25.326, designado por las Cámaras respectivas de común acuerdo, unificando en una persona la representación;

g) un representante del CONSEJO FEDERAL DEL CONSUMO; h) un representante del IRAM, Instituto Argentino de Normalización, con

especialización en el campo de la seguridad informática; i) un representante de la SUPERINTENDENCIA DE SEGUROS DE LA NACION; j) un representante de la Comisión Bicameral de Fiscalización de los Organos y

Actividades de Seguridad Interior e Inteligencia del HONORABLE CONGRESO DE LA NACION.

Invítase a las entidades mencionadas en el presente inciso a que designen los representantes que integrarán el Consejo Consultivo.

Son funciones de la DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES, además de las que surgen de la Ley Nº 25.326:

a) dictar normas administrativas y de procedimiento relativas a los trámites registrales y demás funciones a su cargo, y las normas y procedimientos técnicos relativos al tratamiento y condiciones de seguridad de los archivos, registros y bases o bancos de datos públicos y privados;

b) atender las denuncias y reclamos interpuestos en relación al tratamiento de datos personales en los términos de la Ley Nº 25.326;

c) percibir las tasas que se fijen por los servicios de inscripción y otros que preste; d) organizar y proveer lo necesario para el adecuado funcionamiento del Registro de

archivos, registros, bases o bancos de datos públicos y privados previsto en el artículo 21 de la Ley Nº 25.326;



e) diseñar los instrumentos adecuados para la mejor protección de los datos personales de los ciudadanos y el mejor cumplimiento de la legislación de aplicación;

f) homologar los códigos de conducta que se presenten de acuerdo a lo establecido por el artículo 30 de la Ley Nº 25.326, previo dictamen del Consejo Consultivo, teniendo en cuenta su adecuación a los principios reguladores del tratamiento de datos personales, la representatividad que ejerza la asociación y organismo que elabora el código y su eficacia ejecutiva con relación a los operadores del sector mediante la previsión de sanciones o mecanismos adecuados.

ARTICULO 30.- La DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES alentará la elaboración de códigos de conducta destinados a contribuir, en función de las particularidades de cada sector, a la correcta aplicación de las disposiciones nacionales adoptadas por la Ley Nº 25.326 y esta reglamentación.

Las asociaciones de profesionales y las demás organizaciones representantes de otras categorías de responsables o usuarios de archivos, registros, bases o bancos de datos públicos o privados, que hayan elaborado proyectos de códigos éticos, o que tengan la intención de modificar o prorrogar códigos nacionales existentes, podrán someterlos a consideración de la DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES, la cual aprobará el ordenamiento o sugerirá las correcciones que se estimen necesarias para su aprobación. CAPITULO VI SANCIONES

ARTICULO 31. - Las sanciones administrativas establecidas en el artículo 31 de la Ley Nº 25.326 serán aplicadas a los responsables o usuarios de archivos, registros, bases o bancos de datos públicos, y privados destinados a dar información, se hubieren inscripto o no en el registro correspondiente.

La cuantía de las sanciones se graduará atendiendo a la naturaleza de los derechos personales afectados, al volumen de los tratamientos efectuados, a los beneficios obtenidos, al grado de intencionalidad, a la reincidencia, a los daños y perjuicios causados a las personas interesadas y a terceros, y a cualquier otra circunstancia que sea relevante para determinar el grado de antijuricidad y de culpabilidad presentes en la concreta actuación infractora. Se considerará reincidente a quien habiendo sido sancionado por una infracción a la Ley Nº 25.326 o sus reglamentaciones incurriera en otra de similar naturaleza dentro del término de TRES (3) años, a contar desde la aplicación de la sanción.

El producido de las multas a que se refiere el artículo 31 de la Ley Nº 25.326 se aplicará al financiamiento de la DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES.

El procedimiento se ajustará a las siguientes disposiciones: a) La DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES iniciará

actuaciones administrativas en caso de presuntas infracciones a las disposiciones de la Ley Nº 25.326 y sus normas reglamentarias, de oficio o por denuncia de quien invocare un interés particular, del Defensor del Pueblo de la Nación o de asociaciones de consumidores o usuarios.

b) Se procederá a labrar acta en la que se dejará constancia del hecho denunciado o verificado y de la disposición presuntamente infringida. En la misma acta se dispondrá agregar la documentación acompañada y citar al presunto infractor para que, dentro del plazo de CINCO (5) días hábiles, presente por escrito su descargo y ofrezca las pruebas que hacen a su derecho.

Si se tratare de un acta de inspección, en que fuere necesaria una comprobación técnica posterior a los efectos de la determinación de la presunta infracción y que resultare positiva, se procederá a notificar al presunto responsable la infracción verificada, intimándolo para que en el plazo de CINCO (5) días hábiles presente por escrito su descargo. En su primera presentación, el presunto infractor deberá constituir domicilio y acreditar personería.



La constancia del acta labrada conforme a lo previsto en este artículo, así como las comprobaciones técnicas que se dispusieren, constituirán prueba suficiente de los hechos así comprobados, salvo en los casos en que resultaren desvirtuados por otras pruebas.

c) Las pruebas se admitirán solamente en caso de existir hechos controvertidos y siempre que no resulten manifiestamente inconducentes. Contra la resolución que deniegue medidas de prueba sólo se concederá recurso de reconsideración. La prueba deberá producirse dentro del término de DIEZ (10) días hábiles, prorrogables cuando haya causas justificadas, teniéndose por desistidas aquellas no producidas dentro de dicho plazo por causa imputable al infractor.

Concluidas las diligencias sumariales, se dictará la resolución definitiva dentro del término de VEINTE (20) días hábiles.

ARTICULO 32.- Sin reglamentar. CAPITULO VII ACCION DE PROTECCION DE LOS DATOS PERSONALES

ARTICULOS 33 a 46.- Sin reglamentar

Disposición 11/2006 - Dirección Nacional de Protección de

Datos Personales

Apruébanse las “Medidas de Seguridad para el Tratamiento y Conservación de los

Datos Personales Contenidos en Archivos, Registros, Bancos y Bases de Datos Públicos no estatales y Privados”.

Bs. As., 19/9/2006 Publicación en B.O.: 22/9/2006 VISTO el Expediente N° 153.743/06 del registro del MINISTERIO DE JUSTICIA Y DERECHOS HUMANOS, las competencias atribuidas a esta DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES por la Ley N° 25.326 y su reglamentación aprobada por Decreto N° 1558 del 29 de noviembre de 2001, y CONSIDERANDO:

Que de conformidad con lo prescripto por el artículo 9° de la Ley N° 25.326, el responsable o usuario del archivo de datos debe adoptar las medidas técnicas y organizativas necesarias para garantizar la seguridad y confidencialidad de los datos personales, a fin de evitar su adulteración, pérdida, consulta o tratamiento no autorizado y que permitan detectar desviaciones, intencionales o no, de información, ya sea que los riesgos provengan de la acción humana o del medio técnico utilizado.

Que por su parte, entre las atribuciones asignadas a la DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES se encuentra la de dictar las normas y reglamentaciones que se deben observar en el desarrollo de las actividades comprendidas en la Ley N° 25.326 (artículo 29, inciso 1, apartado b) y específicamente la de dictar normas administrativas y de procedimientos técnicos relativos al tratamiento y condiciones de seguridad de los archivos, registros y bases o bancos de datos públicos y privados (artículo 29, inciso 5, apartado a, del Anexo al del Decreto N° 1558/01), así como la de controlar la observancia de las normas sobre integridad y seguridad de los datos por parte de los archivos, registros o bancos de datos (artículo 29, inciso 1, apartado d, de la Ley N° 25.326).

Que como consecuencia de ello y en cumplimiento de la facultad que este Órgano de Control tiene para el dictado de normas relativas a las condiciones de seguridad de los archivos, registros y bases o bancos de datos, corresponde aprobar las medidas de seguridad para el tratamiento y conservación de los datos personales, que deberán observar



los responsables y usuarios de archivos, registros, bases y bancos de datos públicos no estatales y privados.

Que a tal fin, se establece un “Documento de Seguridad de Datos Personales”, como instrumento para la especificación de la normativa de seguridad, el que deberá adecuarse en todo momento a las disposiciones vigentes en la materia dictadas por la DIRECCION NACIONAL DE PROTECCION DE DATOS PERSONALES.

Que asimismo, se establecen TRES (3) niveles de seguridad: BASICO, MEDIO y CRITICO, conforme la naturaleza de la información tratada, pautas aplicables también a los archivos no informatizados (registro manual).

Que para cada uno de los niveles antes mencionados se han previsto distintas medidas de seguridad, establecidas teniendo en cuenta la mayor o menor necesidad de garantizar la confidencialidad e integridad de la información contenida en el banco de datos respectivo; la naturaleza de los datos y la correcta administración de los riesgos a que están expuestos, así corno también el mayor o menor impacto que tendría en las personas el hecho de que la información registrada en los archivos no reúna las condiciones de integridad y confiabilidad debidas.

Que se han establecido distintos plazos para la implementación de las medidas de seguridad que se propician, teniendo en consideración el nivel de seguridad de que se trate, así corno también la posibilidad de otorgar una prórroga previa solicitud debidamente fundamentada.

Que la DIRECCION GENERAL DE ASUNTOS JURIDICOS del MINISTERIO DE JUSTICIA Y DERECHOS HUMANOS ha tomado la intervención que le compete.

Que la presente medida se dicta el uso de las facultades conferidas en el artículo 29, inciso 1, apartado b, de la Ley N° 25.326 y artículo 29, inciso 5, apartado a, del Anexo al Decreto N° 1558/01. Por ello, EL DIRECTOR NACIONAL DE PROTECCION DE DATOS PERSONALES DISPONE:

Artículo 1° — Apruébense las “Medidas de Seguridad para el Tratamiento y Conservación de los Datos Personales Contenidos en Archivos, Registros, Bancos y Bases de Datos Públicos no estatales y Privados”, cuyo texto como Anexo I forma parte del presente.

Art. 2° — Establécese que el plazo para la implementación de las medidas de seguridad a contar desde la fecha del dictado del presente acto, será de DOCE (12) meses para las de Nivel Básico, de VEINTICUATRO (24) meses para las de Nivel Medio y de TREINTA Y SEIS (36) meses para las de Nivel Crítico, los que serán prorrogables a pedido de la parte interesada y por razones debidamente fundadas.

Art. 3° — Comuníquese, publíquese, dése a la DIRECCION NACIONAL DEL REGISTRO OFICIAL y archívese. — Juan A. Travieso. ANEXO I

“MEDIDAS DE SEGURIDAD PARA EL TRATAMIENTO Y CONSERVACION DE LOS DATOS

PERSONALES CONTENIDOS EN ARCHIVOS, REGISTROS, BANCOS Y BASES DE DATOS

PUBLICOS NO ESTATALES Y PRIVADOS”

• MEDIDAS DE SEGURIDAD DE NIVEL BASICO:

Los archivos, registros, bases y bancos de datos que contengan datos de carácter personal deberán adoptar las medidas de seguridad calificadas como de Nivel Básico que a continuación se detallan:

Disponer del Documento de Seguridad de Datos Personales en el que se especifiquen, entre otros, los procedimientos y las medidas de seguridad a observar sobre los archivos, registros, bases y bancos que contengan datos de carácter personal. Deberá mantenerse en todo momento actualizado y ser revisado cuando se produzcan cambios en el sistema de información.

Deberá contener: 1. Funciones y obligaciones del personal.



2. Descripción de los archivos con datos de carácter personal y los sistemas de información que los tratan.

3. Descripción de las rutinas de control de datos de los programas de ingreso de datos y las acciones a seguir ante los errores detectados a efectos de su corrección. Todos los programas de ingreso de datos, cualquiera sea su modo de procesamiento (batch, interactivo, etc.), deben incluir en su diseño, rutinas de control, que minimicen la posibilidad de incorporar al sistema de información, datos ilógicos, incorrectos o faltantes.

4. Registros de incidentes de seguridad. 4.1. Notificación, gestión y respuesta ante los incidentes de seguridad. 5. Procedimientos para efectuar las copias de respaldo y de recuperación de datos. 6. Relación actualizada entre Sistemas de Información y usuarios de datos con

autorización para su uso. 7. Procedimientos de identificación y autenticación de los usuarios de datos

autorizados para utilizar determinados sistemas de información. La relación entre el usuario autorizado y el/los sistemas de información a los que

puede acceder debe mantenerse actualizada. En el caso en que el mecanismo de autenticación utilice contraseña, la misma será asignada por el responsable de seguridad de acuerdo a un procedimiento que garantice su confidencialidad. Este procedimiento deberá prever el cambio periódico de la contraseña (lapso máximo de vigencia) las que deberán estar almacenadas en forma ininteligible.

8. Control de acceso de usuarios a datos y recursos necesarios para la realización de sus tareas para lo cual deben estar autorizados.

9. Adoptar medidas de prevención a efectos de impedir amenazas de software malicioso (virus, troyanos, etc.) que puedan afectar archivos con datos de carácter personal. Entre otras:

1) Instalar y actualizar, con la periodicidad pertinente, software de detección y reparación de virus, ejecutándolo rutinariamente;

2) Verificar, antes de su uso, la inexistencia de virus en archivos recibidos a través de la web, correo electrónico y otros cuyos orígenes sean inciertos.

10. Procedimiento que garantice una adecuada Gestión de los Soportes que contengan datos de carácter personal (identificación del tipo de información que contienen, almacenamiento en lugares de acceso restringidos, inventarios, autorización para su salida fuera del local en que están ubicados, destrucción de la información en desuso, etc.).

Nota: Cuando los archivos, registros, bases y bancos contengan una serie de datos personales con los cuales, a través de un determinado tratamiento, se permita establecer el perfil de personalidad o determinadas conductas de la persona, se deberán garantizar las medidas de seguridad del presente nivel más las establecidas en los puntos 2, 3, 4 y 5 del siguiente. • MEDIDAS DE SEGURIDAD DE NIVEL MEDIO:

Los archivos, registros, bases y bancos de datos de las empresas privadas que desarrollen actividades de prestación de servicios públicos, así como los archivos, registros, bases y bancos de datos pertenecientes a entidades que cumplan una función pública y/o privada que, más allá de lo dispuesto por el artículo 10 de la Ley N° 25.326, deban guardar secreto de la información personal por expresa disposición legal (v.g.: secreto bancario), además de las medidas de seguridad de nivel Básico, deberán adoptar las que a continuación se detallan:

1. El Instructivo de seguridad deberá identificar al Responsable (u órgano específico) de Seguridad.

2. Realización de auditorías (internas o externas) que verifiquen el cumplimiento de los procedimientos e instrucciones vigentes en materia de seguridad para datos personales.

Los informes de auditoría pertinentes, serán presentados al Responsable del Archivo a efectos de que se adopten las medidas correctivas que correspondan. La Dirección Nacional de Protección de Datos Personales, en las inspecciones que realice, deberá



considerar obligatoriamente, con carácter no vinculante, los resultados de las auditorías referidas precedentemente, siempre que las mismas hayan sido realizadas dentro de un período máximo de un año.

3. Se limitará la posibilidad de intentar reiteradamente el acceso no autorizado al sistema de información.

4. Se establecerá un control de acceso físico a los locales donde se encuentren situados los sistemas de información con datos de carácter personal.

5. Gestión de Soportes e información contenida en ellos, 5.1. Se dispondrá de un registro de entradas y salidas de los soportes informáticos de manera de identificar, día y hora de entrada y salida del soporte, receptor, emisor, forma de envío, etc.

5.2. Se adoptarán las medidas necesarias para impedir cualquier recuperación de la información con posterioridad a que un soporte vaya a ser desechado o reutilizado, o que la información deba ser destruida, por la causa que correspondiere.

Asimismo se deberán adoptar similares medidas cuando los soportes, o la información (ej.: cuando se hacen copias de respaldo a través de una red de transmisión de datos, la información sale de un soporte local y viaja hasta otro remoto vía dicha red.), vaya a salir fuera de los locales en que se encuentren ubicados, 5.3. Deberá disponerse de un procedimiento de recuperación de la información de respaldo y de tratamiento de la misma en caso de contingencias que pongan no operativo el/los equipos de procesamiento habituales.

6. Los registros de incidentes de seguridad, en el caso de tener que recuperar datos, deberán identificar la persona que recuperó y/o modificó dichos datos. Será necesaria la autorización en forma fehaciente del responsable del archivo informatizado.

7. Las pruebas de funcionamiento de los sistemas de información, realizadas con anterioridad a su puesta operativa no se realizarán con datos/archivos reales, a menos que se aseguren los niveles de seguridad correspondientes al tipo de datos informatizados tratados. • MEDIDAS DE SEGURIDAD DE NIVEL CRITICO:

Los archivos, registros, bases y bancos de datos que contengan datos personales, definidos como “datos sensibles”, con la excepción que se señalará más abajo, además de las medidas de seguridad de nivel Básico y Medio, deberán adoptar las que a continuación se detallan:

1. Distribución de soportes: cuando se distribuyan soportes que contengan archivos con datos de carácter personal —incluidas las copias de respaldo—, se deberán cifrar dichos datos (o utilizar cualquier otro mecanismo) a fin de garantizar que no puedan ser leídos o manipulados durante su transporte.

2. Registro de accesos: se deberá disponer de un registro de accesos con información que identifique al usuario que accedió, cuando lo hizo (fecha y hora), tipo de acceso y si ha sido autorizado o denegado. En el caso que el acceso haya sido autorizado se deberá identificar el dato accedido y el tratamiento que se le dio al mismo (baja, rectificación, etc.). Este registro de accesos deberá ser analizado periódicamente por el responsable de seguridad y deberá ser conservado como minino por el término de un TRES (3) años.

3. Copias de respaldo: además de las que se mantengan en la localización donde residan los datos deberán implementarse copias de resguardo externas, situadas fuera de la localización, en caja ignífuga y a prueba de gases o bien en una caja de seguridad bancaria, cualquiera de ellas situadas a prudencial distancia de la aludida localización. Deberá disponerse de un procedimiento de recuperación de esa información y de tratamiento de la misma en caso de contingencias que pongan no operativo el/los equipos de procesamiento habituales.

4. Transmisión de datos: los datos de carácter personal que se transmitan a través de redes de comunicación1, deberán serlo cifrados o utilizando cualquier otro mecanismo que impida su lectura y/o tratamiento por parte de personas no autorizadas.



Nota: Quedan exceptuados de aplicar las medidas de seguridad de nivel crítico, los archivos, registros, bases y bancos de datos que deban efectuar el tratamiento de datos sensibles para fines administrativos o por obligación legal. No obstante, ello no excluye que igualmente deban contar con aquellas medidas de resguardo que sean necesarias y adecuadas al tipo de dato.



GLOSARIO

� Trigger

También llamados disparadores son procedimientos que se ejecutan

cuando se produce un suceso de base de datos (una operación DML: INSERT,

UPDATE o DELETE) en una tabla específica. El acto de ejecutar un disparador se

conoce como disparo.

� DBMS

Los Sistemas Gestores de Bases de Datos son un tipo de software muy

específico, dedicado a servir de interfaz entre las bases de datos y las

aplicaciones que la utilizan. En los textos que tratan este tema, o temas

relacionados, se mencionan los términos SGBD y DBMS, siendo ambos

equivalentes, y acrónimos, respectivamente, de Sistema Gestor de Bases de

Datos y DataBase Management System, su expresión inglesa.

El DBMS es un conjunto de programas que se encargan de manejar la

creación y todos los accesos a las bases de datos

� RDBMS

Un RDBMS es un Sistema Administrador de Bases de Datos

Relacionales. RDBMS viene del acrónimo en ingles Relational Data Base

Manager System.

� Auditoria

La auditoria puede definirse como el examen comprensivo y

constructivo de la estructura organizativa de una empresa de una institución o

departamento gubernamental; o de cualquier otra entidad y de sus métodos de

control, medios de operación y empleo que dé a sus recursos humanos y

materiales.

� Auditoria Informática

Auditoria en Informática es la revisión y evaluación de los controles,

sistemas, procedimientos de informática, de los equipos de cómputo, su



utilización, eficiencia y seguridad, de la organización que participan en el

procesamiento de la información, a fin de que por medio del señalamiento de

cursos alternativos se logre una utilización más eficiente y segura de la

información que servirá para la adecuada toma de decisiones.

� Activity log

Bitácora de actividad

� Data-changes log

Bitácora de cambios de datos

� User activity log

Bitácora de actividad de usuarios

� Trazas

Seguimiento de ejecución de una determinada situación u estado de un

objeto.



BIBLIOGRAFIA

� La auditoria en el contexto actual. Catalina Rivas de las Casas - Gerente de

Auditoria - Sucursal Ciudad Habana, CIMEX, Cuba.

www.gestiopolis.com/recursos/documentos/fulldocs/fin/auditcontxactual.htm

� Auditoria de Sistemas. Carmen D'Sousa.

http://www.monografias.com/trabajos

� Auditoria Informática. Un enfoque Práctico, 2º Edición ampliada y revisada.

Mario G. Piattini, Emilio del Peso y otros. Editorial Alfaomega – Ra-Ma.

� F13 Auditoria Informática. Oscar Coltell. Departamento de Lenguajes y

Sistemas Informáticos. Universitat Jaume I. Castellón.

http://www3.uji.es/~coltell/F13/OCX_F13.html

� Auditoria Informática. 2ª Edición. Paraninfo. Thomas A.J., Douglas I.J .Madrid

1988.

� Decreto 1558/2001 – Reglamentación Ley 25326.

http://www.jus.gov.ar/dnpdpnew/

� Decreto 163/2005 – Ministerio de Justicia y Derechos Humanos. Organigrama,

Misiones y Funciones.


� Disposición 7/2005 – Clasificación de Infracciones y Graduación de Sanciones.


� Disposición 11/2006 – Medidas de Seguridad para el Tratamiento y

Conservación de los Datos Personales contenidos en Archivos, registros Bancos

y Bases de Datos no estatales y Privados.


� Normas Generales de Control Interno (ngci.pdf).

http://www.sigen.gov.ar/main/index.html

� Normas de Control Interno para Tecnología de Información.

http://www.sigen.gov.ar/main/index.html



� Ayuda on-line de Visual Basic 6.0

� Ayuda on-line de Postgres

� Ayuda on-line de SQL Server

http://msdn2.microsoft.com/en-us/library/bb418499.aspx

http://msdn2.microsoft.com/en-us/library/ms187929.aspx

� Pagina Oficial MySQL

http://dev.mysql.com/doc/refman/4.1/en/myodbc-examples-

programming.html

� Página Oficial IBM

http://www-306.ibm.com/common/ssi/fcgi-bin/ssialias

� Página Oficial Oracle

http://www.oracle.com/index.html

� Página Oficial Postgres

http://www.postgresql.org/docs/8.2/static/dynamic-trace.html

Auditoria de bases de datos - dit.ing.unp.edu.ar · La Auditoria de Bases de Datos es una temática...

Documents

Transcript of Auditoria de bases de datos - dit.ing.unp.edu.ar · La Auditoria de Bases de Datos es una temática...