documento de recomendaciones de sostenibilidad del sistema de aseguramiento electrÓnico – sae

DOCUMENTO DE RECOMENDACIONES DE SOSTENIBILIDAD DEL

SISTEMA DE ASEGURAMIENTO ELECTRÓNICO – SAE

Noviembre de 2013

Documento de Recomendaciones de Sostenibilidad del SAE

FORMATO PRELIMINAR AL DOCUMENTO

Título: DOCUMENTO DE RECOMENDACIONES DE SOSTENIBILIDAD DEL

SISTEMA DE ASEGURAMIENTO ELECTRÓNICO – SAE

Fecha elaboración

aaaa-mm-dd: 2013-11-07

Sumario: Información respecto de las recomendaciones para la sostenibilidad a largo

plazo del Sistema de Aseguramiento Electrónico – SAE.

Palabras Claves: Documento, Recomendaciones, Sostenibilidad, Mejoramiento, SAE,

Aseguramiento Electrónico.

Formato: DOC Lenguaje: Español

Dependencia: Oficina de Sistemas e Informática de la Contraloría General de la República

Código: Versión: 1.0 Estado: Generado

Categoría: Documento Técnico

Autor (es): Oportunidad Estratégica

Contrato Nº 291 de 2013

Firmas:

Revisó: Oficina de Sistemas e Informática de la

Contraloría General de la República

Aprobó: Supervisor del contrato Nº 291 de 2013

Información

Adicional:

Ubicación:

Esta copia impresa del presente documento y sus anexos, tiene un archivo

magnético asociado al documento y está localizado bajo el nombre

12_SAE_Documento_Recomendaciones_Sostenibilidad.pdf, en disco

adjunto.


CONTROL DE CAMBIOS

VERSIÓN FECHA RESPONSABLE DESCRIPCIÓN

1.0 2013-11-07 Oportunidad Estratégica Elaboración del documento


TABLA DE CONTENIDO

DERECHOS DE AUTOR ............................................................................................................. 1

CRÉDITOS .................................................................................................................................. 2

1. INTRODUCCIÓN ................................................................................................................. 3

2. PROCESOS ......................................................................................................................... 3

2.1 SITUACIÓN ACTUAL .................................................................................................. 3

2.2 RECOMENDACIONES ................................................................................................ 5

3. RECURSO HUMANO .......................................................................................................... 6


3.2 RECOMENDACIONES ................................................................................................ 8

4. TECNOLOGÍA ...................................................................................................................... 9


4.2 RECOMENDACIONES .............................................................................................. 10

5. SEGURIDAD ...................................................................................................................... 11

5.1 SITUACIÓN ACTUAL ................................................................................................ 11


6. ADMINISTRACIÓN DE DATOS ......................................................................................... 13

6.1 SITUACIÓN ACTUAL ................................................................................................ 13

6.2 ANÁLISIS DE LA BASE DE DATOS DE SAE ............................................................ 14


7. ASPECTOS JURÍDICOS SOBRE SAE, FIRMA ELECTRÓNICA Y LAS ENTIDADES DE

CERTIFICACIÓN CERRADAS .................................................................................................. 46

ANEXO. MODELO RELACIONAL BASE DE DATOS SAE ....................................................... 58

Documento de Recomendaciones de Sostenibilidad del SAE 1

DERECHOS DE AUTOR

La autoría de lo consignado en este documento es de Oportunidad Estratégica, quien a través

de un equipo de profesionales interdisciplinario, lo elaboró, presentó y obtuvo su aprobación

por parte de la Contraloría General de la República, en el marco de ejecución del contrato Nº

291 de 2013, suscrito con el objeto de: Prestación de servicios profesionales especializados

para el acompañamiento al proceso de implementación del Sistema de Aseguramiento

Electrónico – SAE. La Contraloría General de la República y Oportunidad Estratégica,

autorizan a que éste sea reproducido gratuitamente, en cualquier formato o medio sin requerir

un permiso expreso para ello, bajo las siguientes condiciones:

1. La copia no se hace con el fin de distribuirla comercialmente.

2. Los materiales no se deben utilizar en un contexto engañoso.

3. Las copias serán acompañadas por las palabras "copiado/distribuido con permiso de

la Contraloría General de la República. Todos los derechos reservados."

4. El título del documento y el autor (Oportunidad Estratégica) deben ser incluidos al ser

reproducidos como parte de otra publicación o servicio.

Si se desea copiar o distribuir el documento con otros propósitos, debe solicitar el permiso

entrando en contacto con la Oficina de Sistemas e Informática de la Contraloría General de la

República.


CRÉDITOS

Dentro del marco de implantación del Sistema de Aseguramiento Electrónico – SAE de la

Contraloría General de la República - CGR, se han generado por parte de la Oficina de

Sistemas e Informática, Oficina de Capacitación Producción de Tecnología y Cooperación

Internacional, Dirección de Impresión, Archivo y Correspondencia, Contraloría Delegada de

Investigaciones, Juicios Fiscales y Jurisdicción Coactiva, Contraloría Auxiliar para el Sistema

General de Regalías, Unidad de Investigaciones Especiales contra la Corrupción, Unidad de

Seguridad y Aseguramiento Tecnológico e Informático y del Equipo de Trabajo que ha venido

liderando la implementación e implantación del Sistema de Aseguramiento Electrónico - SAE,

un conjunto de ideas, lineamientos y/o parámetros que han contribuido para la elaboración de

este documento y en especial en lo que respecta a las recomendaciones de sostenibilidad del

SAE.


1. INTRODUCCIÓN

En los últimos dos años la Contraloría General de la República (CGR) ha realizado dos

proyectos informáticos que dan soporte a procesos misionales de la entidad: el Proceso

General de Auditoría, mediante la aplicación SICA (Sistema Integrado de Control de Auditoría),

y el Proceso de Control Fiscal, mediante SAE (Sistema de Aseguramiento Electrónico), el cual

permite tener un repositorio de información de los Procesos de Responsabilidad Fiscal,

asegurando a través de la firma digital y el estampado de tiempo, la autenticidad de las

actuaciones.

Además de lo anterior hay otros aplicativos que dan apoyo a procesos importantes de la

entidad, como es el caso de SIPAR (Sistema de Apoyo a la Participación Ciudadana),

SIGEDOC (Sistema de Control Documental), Kactus (Sistema de recursos humanos), y SIREF

(Sistema de Responsabilidad Fiscal), entre otros.

Lo anterior ha conducido a la necesidad de fortalecer el área informática en todos sus aspectos,

para poder responder a las exigencias que trae consigo la implantación de este tipo de

aplicaciones. A pesar de los logros que se han obtenido al respecto en los últimos tiempos, se

requiere todavía trabajar en algunos aspectos para darle sostenibilidad a los importantes

avances que se han hecho con la implantación de las mencionadas aplicaciones. Esto también

permitirá darle una mayor institucionalidad al área informática, haciéndola menos vulnerable a

los vaivenes de personal que a veces se presentan, y contribuirá a darle una mayor estabilidad

al uso de herramientas automatizadas para soportar los procesos de la CGR.

Además de lo anterior, la introducción en la entidad de algunas tecnologías complejas como los

certificados y firmas digitales, así como el estampado cronológico, aumentan aún más las

exigencias sobre la Oficina de Sistemas e Informática, teniendo en cuenta que si se hace la

solicitud para acreditarse como entidad de certificación cerrada, esto va a implicar un análisis de

los procesos por parte de una entidad externa: la ONAC (Organismo Nacional de Acreditación

de Colombia).

En particular, en lo que tiene que ver con la aplicación SAE, hay algunas condiciones que

contribuirán a darle una mayor sostenibilidad a su implantación en la entidad. En el presente

documento se hace una presentación de las mismas, clasificándolas en seis aspectos:

procesos, recurso humano, tecnología, seguridad, administración de datos y aspectos jurídicos.

2. PROCESOS

2.1 SITUACIÓN ACTUAL

A medida que las instituciones evolucionan y que su área informática maneja servicios cada vez

más complejos, surge la necesidad de que sus procesos sean más maduros y formalizados. No


basta únicamente con que el área informática maneje los artefactos tecnológicos, sino que se

requiere que esto sea hecho siguiendo unos ciertos principios, los cuales garantizan la

confiabilidad y seguridad de los servicios prestados. Además de lo anterior, en la medida en

que las empresas son cada vez más dependientes de los servicios informáticos, los

requerimientos sobre la calidad, por ejemplo la disponibilidad, se vuelven mayores. Para

enfrentar esta situación se acude a la formalización de los procesos del área de Sistemas, la

cual da una mayor garantía de la calidad del servicio prestado.

El estándar más conocido con respecto a la formalización de los procesos informáticos es ITIL

(Information Technology Infrastructure Library), el cual es una buena guía con respecto a los

procesos que deben ser manejados en el área informática. El ideal para una empresa es que,

por medio de un marco de referencia como el anterior, se puedan definir unos procesos

informáticos que se adecúen a sus particularidades, con el nivel de profundidad que sea

requerido. Actualmente, existe una gran distancia entre lo planteado por ITIL y lo existente en la

CGR.

Un primer aspecto que convendría resaltar es que para ITIL lo que maneja el área informática

son servicios, y no únicamente tecnología. Esto, más que un cambio de terminología, constituye

una nueva perspectiva sobre el tema, la cual se debe difundir en toda la organización. No se

trata simplemente de manejar unos artefactos tecnológicos como el hardware o las

aplicaciones, sino de prestar servicios a la empresa, los cuales deben tener una cierta calidad,

y por lo tanto deben poder ser evaluados y tener un proceso de mejoramiento continuo.

Con respecto a los servicios informáticos, ITIL establece que se deben establecer procesos

relacionados con su estrategia, su diseño, su transición, su operación, y su mejoramiento

continuo. Al analizar el caso de la CGR se ve que las actividades de la Oficina de Sistemas e

Informática han sido manejadas de una manera informal, lo cual ha llevado a que muchos de

los procesos planteados por ITIL no existan y a que otros tengan debilidades. Es así como, por

ejemplo, en muchos casos el nivel de disponibilidad de los servicios como el soporte al Proceso

de Responsabilidad Fiscal a través de SAE es incierto (en muchos casos ni siquiera se sabe

cuál es). Otro ejemplo sería con respecto al manejo de incidentes, los cuales son tratados

según el criterio de quien fue informado del mismo, y no siguiendo un proceso formal que

garantice un buen manejo. Es el caso, por ejemplo, de algunos incidentes en los que los

usuarios acuden al grupo de redes sin haber hecho una verificación básica de que las

conexiones físicas están debidamente realizadas. En otros casos hay debilidades en los

procesos, como es el caso de los servicios relacionados con certificados y firmas digitales, en

los cuales, si no se siguen ciertas formalidades, los procesos pierden una parte importante de

su legitimidad.

Últimamente la Oficina de Sistemas e Informática ha tomado conciencia de la debilidad en el

área de procesos y ha constituido un grupo denominado Control de Calidad, el cual ha venido

trabajando en el tema, y ha iniciado el proceso de formalización de los procesos, como es el

caso del relacionado con el control de cambios, pero con algunas limitaciones importantes: es


un grupo reducido, que no cuenta con el tiempo suficiente pues tiene asignadas otras

responsabilidades, y además requiere una mayor capacitación sobre el tema.

Los procesos del área informática a veces se relacionan con toda la organización, por lo cual es

conveniente tener una visión global de los mismos. Es el caso, por ejemplo, de los procesos

relacionados con el manejo de certificados y firmas digitales y estampado cronológico, los

cuales afectan a todos los funcionarios de la CGR. Por esta razón sería conveniente que la

labor de definición e implantación de los procesos sea liderada por una dependencia que tenga

una mayor visibilidad y empoderamiento en la institución, como es el caso de la Oficina de

Planeación, con el apoyo de la Oficina de Sistemas e Informática.

2.2 RECOMENDACIONES

En cuanto al aspecto de los procesos de la Oficina de Sistemas e Informática, se presentan las

siguientes recomendaciones:

- Sería conveniente que la CGR se concientice de la dependencia de las actividades de la

entidad del área informática, por lo que es necesario reforzar los procesos relacionados con

ésta. Sin embargo hay que tener presente que las labores de implantación de procesos en

cualquier entidad son dispendiosas, puesto que en muchos casos son vistas por los

funcionarios como un obstáculo para el desempeño de sus funciones. Esto requiere todo un

cambio cultural que permitirá que puedan llevarse a cabo satisfactoriamente, exigiendo una

labor continuada que toma un período considerable de tiempo.

- Generar los mecanismos requeridos para crear en la entidad, la perspectiva de que la labor

del área informática no consiste únicamente en manejar tecnología, sino en crear servicios,

los cuales deben tener una calidad y un proceso de evaluación y mejoramiento continuo.

- Estudiar el proceso seguido en otras entidades similares para la implantación de procesos

en el área informática, y con base en esa experiencia iniciar un proyecto formal que permita

darle un mayor alcance al tema dentro de la CGR. En el contexto de la actual consultoría de

Oportunidad Estratégica se ha establecido contacto con entidades como el Banco de la

República y el Ministerio de Hacienda, quienes han manifestado su disposición a apoyar a la

CGR en este aspecto.

- Para obtener el aval como entidad certificadora cerrada se requiere que los procesos

relacionados con la administración de certificados y firmas digitales, y estampado

cronológico sean muy sólidos. Por consiguiente, es muy importante trabajar en la

consolidación de los mismos, para lo cual pueden servir como guía las experiencias de

entidades certificadoras como el Banco de la República, el cual, en el desarrollo de la actual

consultoría con Oportunidad Estratégica, manifestó su disposición a apoyar a la CGR en

este tema.


- Fortalecer el equipo de trabajo de la Oficina de Sistemas e Informática que trabaja en el

área de procesos, dándoles más tiempo y capacitación para trabajar en el tema. Esto podría

estar acompañado de una consultoría especializada, dentro de la cual se podría capacitar a

los empleados de la CGR y darle una mayor vitalidad al proceso.

- Constituir un grupo de trabajo, liderado por la Oficina de Planeación, para trabajar en la

definición e implantación de los procesos informáticos. Esto podría implicar fortalecer el

grupo de la Oficina de Planeación que trabaja en el área de procesos.

3. RECURSO HUMANO


El avance vertiginoso que ha ocurrido en la CGR con respecto a la implantación de aplicaciones

que apoyan procesos misionales de la entidad, como es el caso de SICA y SAE, ha llevado a

que exista un desajuste entre la organización y la composición de la Oficina de Sistemas e

Informática; al igual que la magnitud de los desafíos que debe asumir. Uno de los aspectos en

los que esto es evidente es en lo relacionado con el recurso humano.

De un área informática en donde las personas desarrollan y/o mantienen aplicaciones por

solicitud de las diferentes dependencias, y se tienen unas labores de apoyo para actividades

como la administración de redes y bases de datos, a un nivel muy operativo; se debe pasar a

una en la que haya un mayor grado de especialización y en donde cada persona debe tener un

conocimiento más profundo de su tema.

Es por eso que no basta con que la persona sea capaz de administrar la red o la base de datos

de una aplicación, siguiendo las indicaciones del proveedor de la misma, sino que se requiere

un conocimiento más profundo que le permita asumir los retos que implica una nueva

concepción en donde la Oficina de Sistemas e Informática proporciona servicios a las demás

áreas, con un alto nivel de calidad, que debe ser evaluado permanentemente. Al analizar el

nivel de desarrollo de la CGR con respecto al aspecto anteriormente mencionado se encuentra

que hay debilidades.

Si bien el área de desarrollo y mantenimiento de aplicaciones cuenta con alguna solidez por

haber participado en el pasado en otros proyectos, en el caso específico de SAE podría

enfrentar dificultades por el desconocimiento que tiene del framework Procesa, que constituye

la base de SAE. De acuerdo con lo anterior, en este momento la dependencia de la CGR con

respecto a al proveedor Mnemo es muy grande. Es urgente entonces, que haya un proceso de

transferencia de conocimiento con respecto a este framework, a los funcionarios de la Oficina

de Sistemas e Informática que van a asumir la labor de mantenimiento de la aplicación.

De igual forma, sería muy conveniente que otros funcionarios de la Oficina de Sistemas e

Informática puedan tener un conocimiento adecuado del framework Procesa para poder


emprender el proyecto de integración de aplicaciones de la CGR usando como base este bus

empresarial.

Recientemente se han presentado algunos problemas de desempeño de SAE por el acceso

simultáneo de varios usuarios a la aplicación. El diagnóstico de problemas de esta naturaleza

es complejo y requiere un amplio conocimiento de la aplicación, del framework Procesa, de

bases de datos y de técnicas de afinamiento de las mismas. Es muy importante por lo tanto que

Mnemo pueda resolver el problema antes de que la aplicación sea recibida por la CGR. Pero

surge además la pregunta de hasta dónde los funcionarios de la Oficina de Sistemas e

Informática pueden enfrentar problemas de esta naturaleza, o para contratar a un consultor

especializado que los resuelva.

Un aspecto que se introdujo con la implantación de SAE, que va a ser extendido a otras

aplicaciones como SICA y el correo electrónico, fue el uso de certificados y firmas digitales para

la autenticación segura de los funcionarios y para garantizar la autenticidad de sus actuaciones.

Sin embargo, esto no estuvo acompañado de un proceso de capacitación sobre los principios

básicos y las implicaciones del uso de este tipo de mecanismos, para todos los funcionarios de

la CGR.

Tampoco hubo una capacitación a los funcionarios del SOC, de la Oficina de Sistemas e

Informática, con respecto a los conceptos básicos y la administración de los mismos. Lo que se

realizó fue una inducción a los encargados con respecto a cómo usar la herramienta para la

expedición de certificados y firmas. Sin embargo, el manejo de una entidad certificadora cerrada

requiere mucho más que lo anterior. En otras entidades con más experiencia en el manejo de

este tema, se cuenta con una unidad de seguridad informática en donde se manejan dichos

temas, con gente especializada en estos aspectos. La experiencia de estas empresas puede

ser de gran valor para la CGR.

Con el uso masivo de aplicaciones como SICA y SAE surgió la necesidad de tener un mejor

control de la calidad prestada por estos servicios. Uno de los aspectos que se volvió crítico fue

el de la atención adecuada a los usuarios funcionales, a través de una mesa de ayuda, la cual

va a ser muy importante en los inicios del uso masivo de SAE. Esto conduce a la necesidad de

contar con un grupo de apoyo que pueda ayudar a los usuarios a resolver sus problemas a nivel

funcional y técnico, lo cual es especialmente crítico en las Gerencias Departamentales

Colegiadas, en donde hay menos recursos de ayuda para los usuarios funcionales.

Por ahora este requerimiento se está supliendo por parte de los funcionarios del grupo SAE, por

medio del correo electrónico, pero esto no parece suficiente.

Otra de las necesidades que surge con el uso masivo de aplicaciones como SICA y SAE, es la

de contar con el personal adecuado para soportar la infraestructura de apoyo a estas

aplicaciones, y poder resolver problemas técnicos en lo referente a temas como redes, bases

de datos y hardware. Actualmente, algunos de estos aspectos están siendo asumidos por


Mnemo, pero se requiere que, cuando termine el contrato con esta compañía, la Oficina de

Sistemas e Informática pueda asumir estas funciones.

Algunos funcionarios manifestaron que han recibido una buena capacitación con respecto a

aspectos operativos, usualmente con los proveedores de los productos, sobre el manejo de las

herramientas, pero que requieren una mayor formación en aspectos más conceptuales. Según

ellos se requeriría una mayor capacitación en aspectos como diseño y administración de redes

y aspectos conceptuales de bases de datos. También se requeriría una mayor apropiación por

parte de los encargados, de la estructura de la base de datos de SAE, para poderle dar un

apoyo técnico adecuado al proceso de mantenimiento y eventual modificación del aplicativo.

3.2 RECOMENDACIONES

Con respecto a los recursos humanos de la Oficina de Sistemas e Informática, Oportunidad

Estratégica presenta las siguientes recomendaciones:

- Es muy importante que los encargados de SAE tengan una muy buena capacitación en el

framework Procesa, para que puedan darle un soporte adecuado a la aplicación; y

adicionalmente, porque esta herramienta podrá servir de base para hacer una integración

de las aplicaciones de la CGR.

- Adelantar las actividades requeridas para que todos los funcionarios de la CGR reciban una

buena capacitación con respecto al manejo de certificados y firmas digitales, y estampado

cronológico, teniendo en cuenta que éstos están siendo usados en SAE, y muy pronto

también en aplicaciones como SICA y el correo electrónico.

- Sería muy recomendable que los funcionarios del Centro de Operaciones de Seguridad

(SOC), quienes están a cargo del manejo de la expedición de certificados y firmas digitales,

reciban una capacitación a este respecto, que cubra aspectos conceptuales y no

únicamente lo referente al uso de la herramienta para expedirlos. Esta podría ser una

exigencia del Organismo Nacional de Acreditación de Colombia – ONAC, para la

acreditación de la CGR como una entidad de certificación cerrada.

- Convendría reforzar la mesa de ayuda de SAE, con el fin de darle un apoyo adecuado a los

usuarios de SAE en aspectos funcionales y técnicos, lo cual es especialmente crítico en el

caso de las Gerencias Departamentales Colegiadas. También se requiere que los usuarios

de SICA y de correo electrónico puedan tener un soporte adecuado, con respecto al uso de

certificados y firmas digitales. Esto implicaría revisar la organización de la mesa de ayuda,

su conformación, la dedicación de las personas a esta labor y el tipo de canal(es) que

es(son) más conveniente(s). La experiencia de SICA en este tema puede ser de gran valor.

- Es muy importante que algunos funcionarios de la Oficina de Sistemas e Informática puedan

conocer muy bien la estructura de la base de datos de SAE para poder dar un soporte


adecuado. Esto requiere un proceso de capacitación de Mnemo con respecto a la última

versión de la misma.

- Sería muy recomendable reforzar el grupo de apoyo técnico de la Oficina de Sistemas e

Informática en aspectos conceptuales relacionados con redes y bases de datos. Esto podría

lograrse a través de la capacitación de los funcionarios actuales. También, podría pensarse

en contratar una consultoría especializada que, además de realizar la labor de soporte,

capacite a los funcionarios de la CGR para asumir esta labor.

4. TECNOLOGÍA


Con el fin de evitar dificultades en la implantación de aplicaciones como SICA y SAE, la Oficina

de Sistemas e Informática tuvo en cuenta las recomendaciones de los proveedores, con

respecto a sus requerimientos de hardware y de software básico. Esto ha llevado a que en

general la infraestructura de apoyo a estas aplicaciones haya respondido adecuadamente. Han

existido, sin embargo, algunas dificultades que es conveniente señalar.

El tiempo de respuesta de SAE ha sido en general bueno, pero últimamente, a raíz del uso

simultáneo de la aplicación por los usuarios, se han presentado problemas de desempeño, a

pesar de que la CGR siguió las indicaciones de Mnemo con respecto a la infraestructura

requerida. Lo más recomendable al respecto sería hacer pruebas de carga de la aplicación con

el fin de garantizar que se va a comportar adecuadamente ante su uso masivo y hacer los

correctivos del caso, con el apoyo de Mnemo.

En algunas Gerencias Departamentales Colegiadas, especialmente en las que se tiene

comunicación a través de satélite, se han presentado algunas dificultades que han hecho que la

comunicación no funcione adecuadamente. Esto se ha producido, debido en parte, a que los

requerimientos de comunicación de SAE son muy grandes, puesto que se transmiten

documentos voluminosos, y en algunos casos videos, que consumen un ancho de banda muy

grande.

Lo más recomendable para enfrentar esta situación sería hacer un seguimiento a las eventuales

dificultades de comunicación con las Gerencias Departamentales Colegiadas, especialmente

las que tienen comunicación satelital, hacer un dimensionamiento del ancho de banda

requerido; aumentarlo si se encuentra que es necesario y es posible, o fijar reglas que impidan

que el canal pueda ser saturado. Por ejemplo, en alguna ocasión se detectó que el canal de

una Gerencia Departamental Colegiada se saturó porque muchos funcionarios estaban

descargando el antivirus simultáneamente. Habría que fijar reglas que impidan que ocurran este

tipo de incidentes.


Otra dificultad que se ha tenido, es que los usuarios funcionales de SAE no siempre cuentan

con una estación de trabajo adecuada para poder trabajar con SAE. La CGR ha hecho un

esfuerzo importante últimamente para modernizar las estaciones de trabajo de sus funcionarios.

Habría que verificar que este problema ya ha sido resuelto satisfactoriamente, especialmente

en las Gerencias Departamentales Colegiadas.

Se ha presentado otra problemática relacionada con la configuración de las estaciones de

trabajo de los funcionarios, debido a que existe alguna heterogeneidad al respecto. Lo más

recomendable para enfrentar esta situación sería analizar la posibilidad de usar la tecnología de

clientes virtuales, la cual facilitaría la homogeneización de la estructura de las estaciones de

trabajo y daría un mayor nivel de seguridad.

Por otra parte, a raíz de la implantación de aplicaciones como SICA y SAE, ha surgido la

necesidad de que exista una integración de las diferentes aplicaciones que se usan en la CGR,

para poder tener una visión más consistente de la información que se maneja en la entidad y

para facilitar la labor de los funcionarios, evitando que tengan que introducir más de una vez la

misma información a diferentes aplicaciones. Esto plantea un problema, que puede ser

enunciado como la definición de una arquitectura, que permita una interacción adecuada entre

las diferentes aplicaciones de la entidad.

El ideal sería que, más que un conjunto de aplicaciones aisladas, haya una plataforma común a

la cual se integran las diferentes aplicaciones para poder interactuar con otras. La realización

de un proyecto de esta naturaleza puede ser compleja, pero conviene ir tomando decisiones

que permitan que se avance en esta dirección. Algunas medidas que se podrían ir trabajando a

este respecto serían: (i) la unificación de la codificación de las entidades sujetos de control de

la CGR en todas las aplicaciones, (ii) el establecimiento de reglas que se deben cumplir cuando

se desarrolla o adquiere una nueva aplicación, y (iii) la definición de un mecanismo de

integración. Contar en la actualidad con Procesa, que es una herramienta para lograr este

propósito, puede ser de utilidad al respecto.

4.2 RECOMENDACIONES

Con respecto a la tecnología en la Oficina de Sistemas e Informática, se presentan las


- Realizar pruebas de carga a SAE para detectar eventuales problemas de tiempos de

respuesta muy grandes, cuando es usada simultáneamente por un número alto de usuarios,

y conjuntamente con Mnemo, tomar los correctivos del caso.

- Hacerle seguimiento al comportamiento de los canales de comunicación con las Gerencias

Departamentales Colegiadas, con el fin de analizar si son adecuados, si requieren ser

aumentados, o si es necesario fijar reglas de utilización para evitar que se bloqueen.


- Verificar que todos los funcionarios de la CGR tengan una estación de trabajo, que les

permita trabajar adecuadamente con SAE.

- Analizar la posibilidad de usar la tecnología de clientes virtuales, para facilitar la

homogeneización de la configuración de las estaciones de trabajo, y contribuir a dar un

mayor nivel de seguridad.

- Empezar a trabajar en la definición de una arquitectura que permita la integración de las

diferentes aplicaciones existentes, y de las que se desarrollen/adquieran en el futuro. Para

ello se puede aprovechar las facilidades que ofrece Procesa.

5. SEGURIDAD


En los últimos tiempos, y a un paso acelerado, la CGR ha venido avanzando hacia el reemplazo

de los documentos físicos por documentos electrónicos. Pero, a diferencia del mundo físico, en

donde la experiencia de muchos años le ha permitido crear mecanismos de protección

adecuados, en el ámbito electrónico tiene poca experiencia. Además, los cambios han ocurrido

en forma tan veloz, que la Entidad no ha tenido tiempo de adaptarse a los nuevos

requerimientos de seguridad que implica el mundo electrónico. De igual forma, en la medida en

que siga avanzando en la eliminación de los documentos físicos, se volverá cada vez más

dependiente de los electrónicos, y por lo tanto de su seguridad.

A veces se piensa que la seguridad informática tiene que ver con artefactos tecnológicos, pero

la realidad es que es mucho más que eso. Se trata de mantener la confidencialidad, la

integridad y la disponibilidad de la información almacenada en medio electrónicos. Y para

garantizarlas se requiere trabajar en los tres frentes que conforman todo proyecto informático: la

tecnología, los procesos y el recurso humano.

Desde hace algún tiempo, y principalmente en los últimos dos años, la CGR ha venido

desarrollando actividades encaminadas a fortalecer la seguridad informática. El desarrollo de

una infraestructura física con altos estándares de seguridad, la conformación de un grupo de

trabajo en informática forense, la constitución de un grupo de seguridad, el SOC, dentro de la

Oficina de Sistemas e Informática, vienen a complementar otra iniciativa anterior, la existencia

de una Unidad de Seguridad Informática en la entidad, la USATI, con un alto empoderamiento

dentro de la organización. Todo lo anterior representa un gran avance con respecto a la

seguridad informática, pero se requiere seguir trabajando en su fortalecimiento.

Usualmente, las empresas modernas con una complejidad y dimensión como las de la CGR,

cuentan con una unidad de seguridad informática, a cargo de un oficial de seguridad (CSO, o

Chef Security Officer). En la CGR existe la USATI, la cual tiene esa misión, pero habría que

fortalecerla y hacer una mejor integración con la Oficina de Sistemas e Informática, a través del


grupo SOC. Los funcionarios de esta última, que están encargados de aspectos de seguridad

como el análisis de vulnerabilidades o la administración de certificados y firmas digitales, tienen

poca comunicación con la USATI, hasta el punto de que no están muy enterados de lo que ésta

hace.

Por otra parte, no se ha desarrollado un plan de seguridad informática para la entidad, el cual

debería estar dirigido a enfrentar los problemas de seguridad de una manera sistemática: definir

cuáles son los recursos electrónicos que conviene proteger de acuerdo con su importancia y el

riesgo de ser atacados; y definir un plan para protegerlos.

Una dificultad que se enfrenta para realizar lo anterior, es la falta de un grupo humano con las

calificaciones requeridas para enfrentar un proyecto de esa magnitud. Convendría reforzar al

equipo actual.

La seguridad informática depende de muchos factores: las instalaciones físicas, la red, las

aplicaciones, los datos, los procesos y las personas. En algunos de ellos, la CGR ha hecho

avances importantes, pero en otros no tanto. Por ejemplo, no existen normas con respecto a la

seguridad que deben tener las aplicaciones para evitar ataques, sólo recientemente se ha

hecho el primer estudio de vulnerabilidades. Adicionalmente, los procesos del área informática

que pueden afectar la seguridad son muy informales y no se ha trabajado mucho en crear una

cultura de seguridad de la información entre todos los funcionarios de la organización. Para

enfrentar las debilidades anteriores convendría trabajar en el fortalecimiento de los procesos

que tienen que ver con la seguridad.

La introducción del uso de certificados y firmas digitales, al igual que la solicitud que piensa

hacer la CGR, para ser reconocida como una entidad de certificación cerrada, implica que tiene

que hacer un gran esfuerzo por robustecer los procesos relacionados con este tema. Existen

todavía debilidades que convendría superar.

Otro aspecto que vale la pena mencionar, es la falta de un plan de continuidad de negocio que

permita reanudar las actividades en el caso de fallas mayores. Uno de los componentes de este

plan es la existencia de un sitio alterno, el cual permitiría la recuperación en un tiempo menor,

pero no es el único.

5.2 RECOMENDACIONES

Con respecto a la seguridad en la Oficina de Sistemas e Informática, se presentan las


- Es muy importante que la CGR tome consciencia de la importancia que reviste el tema de la

seguridad informática, teniendo en cuenta la dependencia cada vez mayor que tiene la

entidad con respecto a los recursos informáticos.


- Es igualmente deseable crear una cultura de seguridad de la información entre todos los

funcionarios de la entidad.

- Si bien podría tomar algún tiempo, se recomienda que la CGR, con ayuda de guías como el

estándar 27001 relacionado con la seguridad de la información, pueda ir fortaleciendo la

seguridad informática. El ideal sería obtener esta certificación, pero si no se logra, al menos

convendría que se haga un análisis de los aspectos críticos para la entidad y se trabaje en

enfrentarlos. Dentro de esta actividad convendría reforzar los procesos relacionados con la

seguridad.

- Para poder obtener el reconocimiento como una entidad de certificación cerrada, se

requiere que los procesos relacionados con la administración de firmas y certificados

electrónicos, así como de estampado cronológico, sean muy robustos. Es muy importante

entonces trabajar en la consolidación de los mismos, para lo cual pueden servir como guía

las experiencias de entidades certificadoras como el Banco de la República, quien durante

el desarrollo de la actual consultoría con Oportunidad Estratégica manifestó su disposición a

apoyar a la CGR en este tema.

- Es muy conveniente que haya una mayor integración entre la USATI y el grupo SOC.

- Se recomienda reforzar el grupo de apoyo técnico de la Oficina de Sistemas e Informática,

en aspectos conceptuales relacionados con seguridad. Esto se puede lograr a través de la

capacitación de los funcionarios actuales. También, es conveniente considerar la

contratación de una consultoría especializada que, además de realizar la labor de soporte,

capacite a los funcionarios de la CGR para asumir esta labor.

- Se recomienda contar con un plan de continuidad de negocio.

6. ADMINISTRACIÓN DE DATOS


Cuando las instituciones desarrollan o adquieren aplicaciones sin una visión integradora, con el

tiempo empiezan a surgir problemas de consistencia de los datos. Esto es algo relativamente

frecuente en las empresas, puesto que la visión de una arquitectura empresarial, y dentro de

ella de una arquitectura da datos, es relativamente reciente.

En el caso de la CGR existen aplicaciones que apoyan actividades importantes de la entidad

como SIPAR, SIGEDOC, SIREF, y últimamente SICA y SAE. Sin embargo, no se ha tenido en

cuenta la conveniencia de que en todas ellas la codificación y el nombre de las entidades, los

municipios y otros elementos que se manejan, sea idéntica, e igual también a la utilizada por el

Estado. Esto puede conducir a inconsistencias, puesto que dos aplicaciones podrían arrojar

información diferente sobre el mismo tema, y además se dificultaría el proceso de realizar


análisis de información sobre los datos, el cual es uno de los valores agregados más

importantes del manejo de información en forma electrónica.

La necesidad de agilizar el proceso de implantación de aplicaciones como SICA y SAE ha

conducido al fenómeno anterior, pero, una vez realizada ésta de forma exitosa, conviene ir

pensando hacia el futuro próximo en enfrentar esta problemática.

El ideal sería que una dependencia dentro de la CGR, la Oficina de Planeación, se encargara

de definir cuál es la nomenclatura, codificación y el nombre que debería dársele a cada entidad,

municipio, y otros elementos que utilizan las aplicaciones, y que esta fuera utilizada en todas las

aplicaciones, y en general en toda la documentación que haga referencia a ellos. Además

debería coincidir con la asignada por el Estado.

El proceso para que la situación ideal anterior pueda llevarse a la práctica es relativamente

dispendioso, debido a que implica modificar las bases de datos de las aplicaciones y se podría

presentar un conflicto entre la nomenclatura anterior y la nueva, que habría que entrar a

resolver. Con respecto a las nuevas aplicaciones que se desarrollen o adquieran, se

recomienda velar por la utilización de la nomenclatura definida por la Oficina de Planeación.

A largo plazo, lo ideal sería que los diferentes datos y servicios que se manejan en la entidad

puedan organizarse en una Arquitectura Orientada a Servicios - SOA (Service Oriented

Architecture). Así como el directorio activo es un servicio que es utilizado por todas las

aplicaciones para la autenticación de los usuarios, podrían existir otros servicios como consultar

información sobre auditorías, que podría ser suministrada por SICA y utilizable por las demás

aplicaciones, o consultar información sobre Procesos de Responsabilidad Fiscal, la cual podría

ser proporcionada por SAE o SIREF, y usada por las demás aplicaciones. Un primer paso para

lograr esto, sería trabajar en la unificación de la nomenclatura de entidades, municipios y

elementos afines. Esto facilitaría enormemente la integración entre las diferentes aplicaciones.

6.2 ANÁLISIS DE LA BASE DE DATOS DE SAE

El análisis que se desarrolla a continuación es un análisis preliminar sobre la Base de Datos

que actualmente está funcionando en la CGR. Éste análisis se ha desarrollado mediante la

comparación entre el documento de la Estructura de Base de Datos elaborado por MNEMO1 y

la estructura de Base de Datos entregada el día 16 de Octubre por la CGR a Oportunidad

Estratégica. Esta estructura es la que soporta actualmente el Sistema de Aseguramiento

Electrónico de Expedientes – SAE.

El documento de la Estructura de Base de Datos elaborado por MNEMO2, fue entregado por

MNEMO DE COLOMBIA S.A.S. a la Contraloría General de la Republica (CGR) en agosto de

2013 y al equipo de Oportunidad Estratégica, el día 17 de Septiembre.

1 (Sistema de Aseguramiento de Expedientes Electrónico - Estructura de Base de Datos - Contraloría General de la

República de Colombia V4.0, 16 de Julio de 2013) 2 Ibíd.


Para realizar el análisis del que se hace mención, se realizó un proceso de ingeniera inversa en

la reconstrucción del modelo de datos, haciendo uso de la técnica Entidad – Relación, modelo

que se adjunta al presente documento (Ver Anexo).

De este ejercicio se evidenció que:

a. La arquitectura de datos que funciona actualmente dentro de la CGR, contempla la

definición de 7 esquemas o módulos de datos principales, asociados a igual número de

usuarios, los cuales son mencionados a continuación.

Tabla 1. Esquemas Base de Datos SAE - Elaboración Oportunidad Estratégica

ESQUEMA - USUARIO DESCRIPCIÓN

1. KEYONECA Esquema que contempla la gestión de datos asociado con las actividades de la Autoridad Certificadora.

2. PROCESA_ENGINE Esquema que contempla la gestión de datos asociados al motor PROCESA3

3. PROCESA_GESTEXP No fue suministrada ésta información por parte de MNEMO.

4. PROCESA_PROC Esquema que contempla la gestión de datos asociada con el Proceso de Responsabilidad Fiscal dentro de la CGR.

5. PROCESA_REPO No fue suministrada ésta información por parte de MNEMO.

6. PROCESA_WD No fue suministrada ésta información por parte de MNEMO.

7. TRUSTEDX

Esquema en el que se describe y administra la estructura de datos del Hardware Security Module (HSA). Este esquema soporta la plataforma donde generan, almacenan y donde se protegen las claves criptográficas generadas para la firma digital.

El análisis que se presenta se centrará en los objetos (Tablas, Vistas, Índices, Paquetes,

Procedimientos, Funciones, Disparadores y Secuencias), que hacen parte del esquema

PROCESA_PROC.

3 Plataforma que permite que diferentes procesos desplegados se integren de forma sencilla con los procesos,

servicios, aplicaciones y arquitecturas existentes dentro de la CGR como lo son SICA, SIREF, SIGEDOC, SIPAR, entre otros.


6.2.1 Análisis de las Tablas

Oportunidad Estratégica identifico a partir de la información suministrada por la CGR, que en el esquema PROCESA_PROC, existen

139 entidades, sin embargo en el documento Estructura de Base de Datos V4.0 entregado por MNEMO a la CGR solo se hace mención

de 124 entidades, y son estas 124 las que son objeto de análisis, dado que de las 15 restantes MNEMO no ha entregado

documentación.

A continuación se presentan algunas observaciones y recomendaciones sobre las entidades que presentan algunas oportunidades de

mejora dentro del modelo de datos.

Tabla 2. Tabla comparativa entre la estructura de base de datos que funciona en la CGR y lo documentado por MNEMO.

ANALISIS COMPARATIVO ENTRE: LA ESTRUCTURA DE BASE DE DATOS QUE FUNCIONA A OCTUBRE 16 DE 2013 EN LA CGR Y LA ESTRUCTURA DOCUMENTADA Y ENTREGADA A LA CGR POR MNEMO, EN EL DOCUMENTO “ESTRUCTURA BASE DE DATOS PRF v4.0 ”.

Número de la

Entidad Entidad

Descripción de la entidad e Información de los atributos

Inconsistencias u observaciones encontradas Recomendación

1 ACCION_TIPO_PRF

Tabla maestra que almacena todas las acciones que se pueden realizar para el Expediente de Responsabilidad Fiscal en función de si el PRF es ordinario o verbal.

ID_TIPO (NUMBER): Almacena el tipo de PRF.

1 á Ordinario.

o 2 á Verbal.

ID_ACCION (VARCHAR2 200 BYTE): Almacena la acción que se puede realizar. Estas acciones corresponden con las acciones definidas en la entidad 4. En esta entidad están todas las acciones de menú posibles.

Está definido como VARCHAR de 100 Byte en la base de datos que está funcionando en el CGR

2 ACCIONES_ESTADO_ANTIP

Tabla maestra que almacena las acciones que se pueden realizar en función del estado en el que se encuentre el expediente de Antecedentes e Indagación Preliminar

ID_STATE_INFO (VARCHAR2 400 BYTE): estado en el que se encuentra el expediente.



Número de la

Entidad Entidad



ID_ACCION (VARCHAR2 200 BYTE): Almacena la acción que se puede realizar. Estas acciones corresponden con las acciones definidas en la entidad 4. En esta entidad están todas las acciones de menú posibles.

Está definido como VARCHAR de 100 Byte en la base de datos que está funcionando en el CGR

Solicitar a MNEMO realizar la actualización de este campo en la documentación correspondiente .

MENSAJE_CAMBIO_ETAPA (VARCHAR2 4000 BYTE): Almacena el mensaje a mostrar en los cambios de etapas donde se pueden introducir múltiples autos.

4 ACCIONES_MENU

Tabla maestra que almacena todas las acciones que se pueden ejecutar desde el proceso de menú, independientemente del tipo de expediente y del estado.

ID_ACCION (VARCHAR2 100 BYTE): Acción a realizar. Tiene que tener coherencia con las acciones puestas en los puntos 1, 2.y 3.

DESCRIPCION (VARCHAR2 1000 BYTE): Descripción de la acción, y que aparece en el proceso de menú para que el usuario elija una tanto para el expediente de Antecedentes e Indagación Preliminar como para el Procedimiento de Responsabilidad Fiscal.

DESCRIPCION_I18N (VARCHAR2 1000 BYTE):

Este atributo no se encuentra documentado en la estructura que SAE entrega a la CGR, sin embargo en la base de datos que actualmente está funcionado en la CGR este atributo hace parte de esta entidad. No existe un documento de control de cambios donde se documenten éstas modificaciones en la Base de Datos.

Revisar la pertinencia de este campo. Solicitar a MNEMO realizar la actualización de la documentación correspondiente o en su defecto proceder con la eliminación del campo de la estructura.

5 ACTUACIONES

Tabla que almacena todas las actuaciones tanto procesales (PRF Ordinario) como de la etapa de pruebas (PRF Ordinario) como de la Audiencia de Descargos (PRF Verbal) para todos los expedientes generados, sin asociarlas a ninguna etapa de ningún expediente (en los siguientes puntos están las relaciones con el



Número de la

Entidad Entidad



expediente).

ID_ACTUACION (NUMBER): Identificador de la actuación. Es un número autogenerado.

N_AUTO (VARCHAR2 200 BYTE): Número de auto (PRF Ordinario).

FECHA (DATE): Fecha de la actuación (PRF Ordinario).

CUANTIA (FLOAT): Cuantía de la actuación (PRF Ordinario).

ID_TIPO_ACTUACION (NUMBER): Identificador del tipo de actuación elegida. Tiene una referencia con la entidad 115.

TIMESTAMP (DATE): Fecha interna de inserción del registro en la tabla.

ACTUACION (VARCHAR2 500 BYTE): Descripción del tipo de actuación elegida. Tiene una referencia con la entidad 115.

Según la documentación entregada por MNEMO, la entidad ACTUACIONES cuenta con dos IDs, uno es la llave primaria de la entidad “id_actuacion”, y el

otro hace referencia a una llave foránea “id_tipo_actuacion”. La llave foránea “id_tipo_actuacion” es la llave primaria de la entidad TIPOS_ACTUACIONES.

Por consiguiente, es en ésta entidad en dónde se debe hacer la descripción correspondiente al registro “Actuacion”, puesto que es una característica propia de la entidad TIPOS_ACTUACIONES y no de la entidad ACTUACIONES.

Se recomienda hacer la corrección de este registro dentro de la base de datos, porque es un dato que se está capturando en dos lugares, lo que provocaría redundancia de información.

N_SESION (VARCHAR2 200 BYTE): Número de sesión (PRF Verbal).

FECHA_ACTA (DATE): Fecha del acta (PRF Verbal).

FECHA_SESION (DATE): Fecha de la sesión (PRF Verbal).

ACTA (VARCHAR2 4000 BYTE): Descripción del acta (PRF Verbal).



Número de la

Entidad Entidad



N_PROCESO (VARCHAR2 100 BYTE): Número de proceso (PRF Ordinario).

FECHA_ULT_NOT (DATE): Fecha de la última modificación.

NUM_PROVIDENCIA (VARCHAR2 200 BYTE) Estos atributos no se encuentran documentados en la estructura que SAE entrega a la CGR, sin embargo en la base de datos que actualmente está funcionado en la CGR estos atributos hacen parte de esta entidad. No existe un documento de control de cambios donde se documenten éstas modificaciones en la Base de Datos.

Revisar la pertinencia de estos campos. Solicitar a MNEMO realizar la actualización de la documentación correspondiente o en su defecto proceder con la eliminación de estos campos dentro de la estructura.

FECHA_PROVIDENCIA (DATE)

HORA_INICIO_SESION (VARCHAR2 20 BYTE)

HORA_FIN_SESION (VARCHAR2 20 BYTE)

10 ACUSES

Tabla que almacena todas las notificaciones a todos los destinatarios enviadas. Esta tabla también almacena si el sistema ha recibido el acuse de recibo y la fecha del acuse.

ID_ACUSE (NUMBER): Identificador del acuse. Es un número autogenerado.

REMITENTE (VARCHAR2 200 BYTE): Correo del usuario remitente del acuse, que es el mismo que el destinatario de la notificación.

No existe una estandarización en la definición de la longitud de los campos. Hay entidades en las que se define el campo correo con una longitud de hasta 4000 bytes

Establecer que todos los campos asociados con el registro de direcciones de correo electrónico cuenten con la misma longitud.

ACUSE (VARCHAR2 20 BYTE): Indica con Sí/No si se ha recibido el acuse por parte del remitente.

Si el campo se está utilizando para el registro de un indicador de Si o No, se debe considerar como con campo tipo CHAR y de una longitud menor.

FECHA_ACUSE (TIMESTAMP): Fecha en la que se envía el acuse de recibo.

11 ACUSES_NOTIFICACIONES

Tabla que almacena la relación de todos los envíos para esperar el acuse y la notificación que se ha creado en el sistema.

ID_NOTIFICACION (NUMBER): Identificador de la notificación creada.

ID_ACUSE (NUMBER): Identificador del acuse. No es clara la diferencia en término de longitud con el campo ID_ACUSE de la estructura ACUSES



Número de la

Entidad Entidad



12 ANTECEDENTES

Tabla que almacena todos los antecedentes para todos los expedientes. Las relaciones con las diferentes etapas tanto del expediente de Antecedentes e Indagación Preliminar como del PRF se ven en los puntos siguientes.

ID_ANTECEDENTE (NUMBER): Identificador del antecedente. Es un número autogenerado.

CODIGO_SIGEDOC (VARCHAR2 200 BYTE): Código SIGEDOC del antecedente.

Establecer a nivel de un servicio con SIGEDOC, la validación de esté código de manera conjunta con el campo FECHA_SIGEDOC.

FECHA_SIGEDOC (DATE): Fecha SIGEDOC del antecedente.

Establecer a nivel de un servicio con SIGEDOC, la validación de esta fecha de manera conjunta con el campo CÓDIGO_SIGEDOC.

ORIGEN_ANTECEDE (VARCHAR2 200 BYTE): Descripción del Origen del antecedente. Tiene relación con la tabla de la entidad 89.

La descripción del campo “origen_antecedente” no es un dato que

dependa de la clave primaria “id_antecedente”.

Este es un atributo que depende de la llave primaria de la entidad ORIGEN_APERTURA.

Es recomendable contemplar la posibilidad de retirar éste campo de esta entidad, dado que al existir ya en la entidad ORIGEN_APERTURA se

estaría generando redundancia en la información registrada.

DESTINO_ANTECEDENTE (VARCHAR2 200 BYTE): Destinatario del antecedente.

TIMESTAMP (DATE): Fecha interna de creación del registro en la tabla.

ID_ORIGEN_ANTECEDENTE (NUMBER): Identificador del origen del antecedente. Tiene relación con la tabla de la entidad 89.

REMITENTE_ANTECEDENTE (VARCHAR2 200 BYTE): Remitente del antecedente.

15 APODERADOS

Tabla que almacena todos los apoderados registrados en el sistema.

ID_APODERADO (NUMBER): Identificador del apoderado. Es un número autogenerado.

Se está generando un identificador dentro de la entidad cuando se puede utilizar uno de sus atributos como identificador.

Verificar que la identificación de los apoderados sea a partir del número de su documento de identificación o número de tarjeta profesional.



Número de la

Entidad Entidad



N_CEDULA (VARCHAR2 200 BYTE): Número de cédula del apoderado.

Este puede ser el Identificador de la entidad apoderados.

NOMBRE (VARCHAR2 200 BYTE): Nombre del apoderado.

TARJETA_PROFESIONAL (VARCHAR2 200 BYTE): Número de tarjeta profesional del apoderado.

EMAIL (VARCHAR2 400 BYTE): Dirección de correo electrónico del apoderado.

Está definido como (VARCHAR DE 4000) en el modelo que está funcionando en la CGR.

Establecer que todos los campos asociados con el registro de direcciones de correo electrónico cuente con la misma longitud y denominación para la identificación de la columna.

17 AUTOS_AAINDP

Tabla que almacena todos los autos de apertura de la indagación preliminar para todos los expedientes, independientemente de si corresponden a los expedientes de Antecedentes e Indagación Preliminar o al PRF. Las relaciones del auto de apertura con los expedientes tanto del expediente de Antecedentes e Indagación Preliminar como del PRF se ven en los puntos siguientes.

ID_AUTO (NUMBER): Identificador del auto de apertura de indagación preliminar. Es un número autogenerado.

El identificador de esta entidad está declarado como un número autogenerado pero los autos de apertura de Indagación Preliminar ya cuentan con un número generado desde SIREF.

Para mantener la integridad entre los diferentes sistemas de la entidad e incrementar el nivel de trazabilidad, es recomendable que el identificador no sea un valor autogenerado sino que se aproveche el valor generado desde el SIREF.


NUM_IP (VARCHAR2 60 BYTE): Número de indagación preliminar.

NUM_AUTO_IP (VARCHAR2 60 BYTE): Número de auto.

FECHA_APERTURA (DATE): Fecha de apertura de la indagación preliminar.

CUANTIA (FLOAT): Cuantía del auto de apertura de la indagación preliminar.



Número de la

Entidad Entidad



18 AUTOS_AAINDP_ANIP

Tabla que almacena la relación entre el auto de apertura de la indagación preliminar realizado (entidad 17) y el expediente con el que se está trabajando. Esta tabla está destinada a guardar las relaciones de la etapa del auto de apertura de la indagación preliminar del tipo de expediente Antecedentes e Indagación Preliminar.

ID_REQUEST: Identificador interno del expediente.

No definen el tipo de dato en el Documento Esquema de la base de datos.

Actualizar documentación entregada por parte de MNEMO

ID_AUTO: Identificador del auto. No definen el tipo de dato en el Documento Esquema de la base de datos.

Actualizar documentación entregada por parte de MNEMO

20 AUTOS_ACINDP

Tabla que almacena todos los autos de cierre de la indagación preliminar para todos los expedientes, independientemente de si corresponden a los expedientes de Antecedentes e Indagación Preliminar o al PRF. Las relaciones del auto de cierre con los expedientes tanto del expediente de Antecedentes e Indagación Preliminar como del PRF se ven en los puntos siguientes.

ID_AUTO (NUMBER): Identificador del auto de cierre de indagación preliminar. Es un número autogenerado.


NUM_IP (VARCHAR2 60 BYTE): Número de indagación preliminar.

NUM_AUTO (VARCHAR2 60 BYTE): Número de auto.

El identificador de esta entidad está declarado como un número autogenerado, pero los autos ya cuentan con un número generado desde SIREF.

Para mantener la integridad entre los diferentes sistemas de la entidad e incrementar el nivel de trazabilidad, es recomendable que el identificador no sea un valor autogenerado sino que se aproveche el valor generado desde el SIREF.

FECHA_AUTO (DATE): Fecha de cierre de la indagación preliminar.



Número de la

Entidad Entidad



CUANTIA (FLOAT): Cuantía del auto de cierre de la indagación preliminar.

EMAIL_DESTINATARIO (VARCHAR2 200 BYTE): Dirección de correo electrónico del destinatario.

Se define e-mail como un VARCHAR de 200 byte, es una declaración que no guarda ninguna correspondencia en longitud con la declaración de este mismo campo en otras entidades.


26 COMP_SEGUROS

Tabla maestra que almacena todas las compañías de seguros utilizados en el proceso de la aplicación SAE.

ID_COMP (NUMBER): Identificador de la compañía de seguros. Es un valor numérico autogenerado.

DESCRIPCION (VARCHAR2 200 BYTE): Nombre de la compañía de seguros.

NIT (VARCHAR2 200 BYTE): Código NIT. Este podría ser el identificado de la entidad PK

Se recomienda el contemplar la posibilidad de analizar éste campo como el identificador de la entidad, teniendo en cuenta que las compañías cuentan con un identificador Único (NIT).

EMAIL (VARCHAR2 2000 BYTE): Dirección de correo electrónico de la compañía aseguradora.

Definición del correo como un campo de 2000 byte


27 CONSULTAS

Tabla que almacena todas las segundas instancias / consultas para todos los expedientes. Las relaciones de la segunda instancia / consulta con el expediente del PRF están descritas en el siguiente punto.

ID_CONSULTA (NUMBER): Identificador de la consulta. Es un valor numérico autogenerado.

FECHA (DATE): Fecha de la consulta.

ID_TIPO_ACTUACION (NUMBER): Identificador del tipo de actuación. Está relacionado con el identificador de la tabla de la entidad 116.

DESC_TIPO_ACTUACION (VARCHAR2 200 Problemas de Normalización, 2da Forma Esta descripción se debe realizar en la



Número de la

Entidad Entidad



BYTE): Nombre del tipo de actuación realizada para la consulta. Está relacionado con la tabla de la entidad 116.

Normal entidad TIPOS_ACTUACIONES, habría

que validar si las actuaciones definidas en esa entidad son las misma que se describen en esta entidad

N_AUTO (VARCHAR2 200 BYTE): Número de auto correspondiente a la segunda instancia.

NUM_PROVIDENCIA (VARCHAR 200 BYTE) Estos atributos no se encuentran documentados en la estructura que SAE entrega a la CGR, sin embargo en la base de datos que actualmente está funcionado en la CGR estos atributos hacen parte de esta entidad. No existe un documento de control de cambios donde se documenten éstas modificaciones en la Base de Datos.



29 DECISIONES

Tabla que almacena todas las decisiones realizadas sobre recursos interpuestos para todos los expedientes. Las relaciones entre las decisiones realizadas y los recursos interpuestos están descritas en el siguiente punto.

ID_DECISION (NUMBER): Identificador de la decisión. Es un valor autogenerado.

N_AUTO (VARCHAR2 200 BYTE): Número de auto.

FECHA (DATE): Fecha de la decisión.

ID_TIPO_ACTUACION (NUMBER): Identificador del tipo de actuación. Está relacionado con el identificador de la tabla de la entidad 117.

Problemas de normalización en su segunda forma normal, esta descripción ya está definida en la entidad TIPOS_ACTUACIONES

DESC_TIPO_ACTUACION (VARCHAR2 200 BYTE): Nombre del tipo de actuación realizada para la decisión. Está relacionado con la tabla de la entidad 117.

Problemas con la 2da Forma Normal, este es un registro que se debe definir en una entidad que administre Tipos de Actuaciones.

Esta es una característica que ya se está ingresando en la entidad TIPOS_ACTUACIONES por medio del atributo Actuacion.

FECHA_ULT_NOT (DATE): Fecha de la última notificación.



Número de la

Entidad Entidad



NUM_PROVIDENCIA (VARCHAR 200) Estos atributos no se encuentran documentados en la estructura que SAE entrega a la CGR, sin embargo en la base de datos que actualmente está funcionado en la CGR estos atributos hacen parte de esta entidad. No existe un documento de control de cambios donde se documenten éstas modificaciones en la Base de Datos.



37 DOCUMENTOS_ACTUACIONES

Tabla que almacena la relación entre el identificador del auto de las actuaciones (Audiencia de Descargos, Etapa de pruebas del PRF Ordinario o Actuaciones Procesales) (entidad 5) y el identificador del documento (entidad 32).

En la base de datos que está funcionando en la CGR el identificador o la llave primaria de esta entidad es ID_ACTUACION (NUMBER) y ID_DOC

(NUMBER)

Es recomendable que la CGR, haga una solicitud del documento de la estructura de datos actualizado por parte de MNEMO y que además, éste sea consistente con la información que registra, ya que de ello depende la correcta administración a futuro.

ID_AUTO (NUMBER): Identificador del auto. No es un campo de esta entidad por ende hace parte del identificador en esta entidad.

ID_DOC (NUMBER): Identificador del documento.

58 ENTIDADES

Tabla maestra que almacena todas las entidades existentes para el proceso de la aplicación SAE. Cada entidad queda asociada al municipio que corresponde.

ID_ENTIDAD (NUMBER): Identificador de la entidad. Es un valor numérico autogenerado.

ID_EXTERNO (VARCHAR2 20 BYTE): Identificador externo de la entidad.

NOMBRE (VARCHAR2 4000 BYTE): Nombre de la entidad.

DIRECCION (VARCHAR2 4000 BYTE): Dirección de la entidad.

ACTIVO (NUMBER): Flag para indicar un activo lógico.

1 Activo.

0 Desactivo.

El usuario puede ingresar un valor de hasta 38 dígitos, perdiéndose de esta forma la garantía sobre la información almacenada.

Si el campo se está utilizando para el registro de un indicador de 1 o 0, se debe considerar como campo tipo CHAR y de una longitud menor.

NIT (VARCHAR2 200 BYTE): Código NIT.

Se recomienda contemplar la posibilidad de establecer éste atributo como el



Número de la

Entidad Entidad



identificador de la entidad, dado que el NIT de las Entidades en Colombia es Únicos e irrepetible.

ID_MUNICIPIO (NUMBER): Identificador del municipio al que corresponde. Corresponde con el identificador de la tabla de la entidad 84.

ID_ORDEN (NUMBER)



70 EXPEDIENTES

Tabla maestra donde se guarda el identificador de los dos tipos de expedientes que hay, junto con un número que indica el próximo a utilizar y el año. Se utiliza junto con un procedimiento almacenado que posteriormente se explica en la entidad 1 para construir el código de expediente “TIPO-AÑO-NUMERO”.

Este procedimiento almacenado no se encuentra documentado en el documento Estructura de Bases de Datos PRF V4.0 entregado por MNEMO a la CGR.

Es recomendable que la CGR, solicite a MNEMO la documentación de este procedimiento.

TIPO (VARCHAR2 10 BYTE): Identificador del tipo de expediente.

NUMERO (NUMBER): Número del próximo expediente que se genere.

ANOEXP (NUMBER): Año actual. De esta manera cada vez que cambia el año se resetea la columna NUMERO a 1.

No es claro cómo se realiza esta tarea. Este procedimiento almacenado no se encuentra documentado en el documento Estructura de Bases de Datos PRF V4.0 entregado por MNEMO a la CGR.

Es recomendable que la CGR, solicite a MNEMO la documentación de este procedimiento.

73 GARANTES

Tabla que almacena los datos de todos los garantes existentes en la aplicación. Las tablas de relación con el PRF Ordinario y Verbal se muestran a continuación de esta.

ID_GARANTE (NUMBER): Identificador del garante introducido.



Número de la

Entidad Entidad



COMP_ASEGURADORA (VARCHAR2 200 BYTE): Nombre de la compañía aseguradora.

N_POLIZA_VIGENCIA (VARCHAR2 200 BYTE): Número de póliza – vigencia.

Numero de póliza y el tiempo de vigencia son dos atributos diferentes

Se recomienda crear un atributo para el número de la póliza y otro para la vigencia, puesto que ningún atributo dentro de una entidad debe depender más que de la entidad misma.

FECHA_VINCULACION (DATE): Fecha de vinculación.

FECHA_COMUNICACION (DATE): Fecha de comunicación.

VALOR_AMPARADO (FLOAT): Valor amparado.

TIMESTAMP (DATE): Fecha interna en el momento del registro del garante.

ID_COMP (NUMBER): Identificador de la compañía aseguradora seleccionado.

EMAIL_COMP_ASEGURADORA (VARCHAR 2000 BYTE)

Este campo no se encuentra definido dentro de la documentación de la estructura de datos entregado por MNEMO a la CGR, pero si es un campo que se encuentra dentro de la entidad que aparecen en la estructura de base de datos que funciona en la CGR. No existe un documento de control de cambios donde se documenten éstas modificaciones en la Base de datos

Revisar la pertinencia del campo para realizar la actualización de la documentación correspondiente o en su defecto proceder con la eliminación del campo de la estructura.

76 GRUPOS_FALLOS

Tabla que guarda la relación entre los grupos intervinientes desde que se finaliza el fallo de primera instancia, pasando por el grupo intermedio, que decide un usuario del grupo de segunda instancia para que sea el propietario de ejecutar la segunda instancia del expediente. Estructura de datos sin identificador de

llave primaria.

Teniendo en cuenta el nombre de esta entidad, se deduciría que es una entidad de rompimiento entre las entidades GRUPOS y FALLOS, pero como el modelo no contempla la existencia de la entidad GRUPOS, se puede concluye que no lo es, por consiguiente su llave privada no es compuesta una opción sería Id_grupos_fallos (NUMERIC)”.

Se recomienda hacer las observaciones correspondientes a MNEMO, teniendo en

ORIGEN (VARCHAR2 200 BYTE): Se almacena el grupo que realiza la primera instancia.

INTERMEDIO (VARCHAR2 200 BYTE): Grupos que deciden quién ejecuta la segunda instancia del expediente.



Número de la

Entidad Entidad



DESTINO (VARCHAR2 200 BYTE): Grupo que se encarga de realizar la segunda instancia del expediente.

cuenta que en la CGR se ha presentado “Perdida de Documentos” cuando el proceso pasa de primera a segunda instancia. Según aquí lo descrito, ésta es la entidad que guarda la relación entre los grupos intervinientes desde que se finaliza el fallo de primera instancia, pasando por el grupo intermedio, que decide un usuario del grupo de segunda instancia para que sea el propietario de ejecutar la segunda instancia del expediente.

77 GRUPOS_ROL

Tabla que relaciona el nombre del grupo con su DN existente en el LDAP.

Estructura de datos sin identificador de llave primaria.

El identificador de esta entidad podría ser ID_GRUPO_ROL.

GRUPO (VARCHAR2 200 BYTE): Nombre del grupo.

ROL_DN (VARCHAR2 200 BYTE): DN existente en el LDAP.

No es claro a que se hace referencia cuando se habla del DN.

Es recomendable que la CGR solicite la documentación de

PERMISOS_TRAMITACION (VARCHAR2 4000 BYTE): Grupos que tienen potestad para tramitar los expedientes de algún propietario del campo GRUPO.

TIPO_GRUPO (NUMERIC)



82 MEDIDAS_CAUTELARES

Tabla que almacena todas las medidas cautelares creadas para todos los expedientes generados del PRF. La relación de la medida cautelar con el expediente en cuestión se muestra en el siguiente punto.

ID_MEDIDA (NUMBER): Identificador de la medida cautelar. Es un valor numérico



Número de la

Entidad Entidad



autogenerado.

FECHA_MEDIDA_DECRETADA (DATE): Fecha de la medida decretada.

FECHA_MEDIDA_PRACTICADA (DATE): Fecha de la medida practicada.

ID_TIPO_MEDIDA (NUMBER): Identificador del tipo de medida. Está relacionado con el identificador de la tabla de la entidad 120.

DESC_MEDIDA (VARCHAR2 500 BYTE): Nombre del tipo de medida seleccionado. Está relacionado con la tabla de la entidad 120.

Problema de normalización: 2da Forma Normal, este campo es un atributo que pertenece a la entidad TIPOS_MEDIDAS_CAUTELARES

Esta descripción se debería hacer en una entidad llamada TIPOS_MEDIDAS_CAUTELARES

CUANTIA_MEDIDA (FLOAT): Cuantía de la medida.


FECHA_MEDIDA_REGISTRADA (DATE) Estos atributos no se encuentran documentados en la estructura que SAE entrega a la CGR, sin embargo en la base de datos que actualmente está funcionado en la CGR estos atributos hacen parte de esta entidad. No existe un documento de control de cambios donde se documenten éstas modificaciones en la Base de Datos.


NUM_PROVIDENCIA (VARCHAR 200)


84 MUNICIPIOS_DEPARTAMENTO

Tabla maestra que guarda los municipios que intervienen en el proceso de la aplicación SAE y la relación con su departamento. Se utiliza de filtro en función del departamento elegido (entidad 31) y para filtrar las entidades que se pueden seleccionar (entidad 58).

ID_DEPARTAMENTO (NUMBER): Identificador del departamento.

ID_MUNICIPIO (NUMBER): Identificador del municipio.

De no haberse tenido en cuenta, se podría contemplar el incluir los códigos de Departamento y Municipio, que tienen establecidos el Departamento



Número de la

Entidad Entidad



Administrativo Nacional de Estadísticas – DANE.

DESC_MUNICIPIO (NUMBER): Nombre del municipio.

Se pueden tener en cuenta los códigos y nombres que el Departamento Administrativo Nacional de Estadísticas DANE tiene para los Departamentos y Municipios.

ACTIVO (NUMERIC)

Este campo no se encuentra definidos dentro de la documentación de la estructura de datos entregado por MNEMO a la CGR, pero si es un campo que se encuentra dentro de la entidad de la estructura de base de datos que funciona en la CGR. No existe un documento de control de cambios donde se documenten éstas modificaciones en la Base de datos

Revisar la pertinencia del campo para realizar la actualización de la documentación correspondiente o en su defecto proceder con la eliminación del campo de la estructura.

87 NOTIFICACIONES_ELECTRONICAS

Tabla que almacena todas las notificaciones electrónicas creadas para todas las etapas en las que existen notificaciones electrónicas.

ID_NOTIFICACION (NUMBER): Identificador de la notificación. Es un número autogenerado.

FECHA_ENVIO (TIMESTAMP): Fecha en la que se envía la notificación.

TIMESTAMP_IN (DATE): Fecha en la que se registra en el sistema la notificación.

EXPEDIENTE (VARCHAR2 200 BYTE): Código del expediente al que se asocia la notificación.

CUERPO (VARCHAR2 4000 BYTE): Cuerpo del texto que se envía en la notificación.

LUGAR_NOTIFICACION (VARCHAR 200) Estos campos no se encuentran definidos dentro de la documentación de la estructura de datos entregado por MNEMO a la CGR, pero si son campos que se encuentran dentro de la entidad de la estructura de base de datos que funciona actualmente en la CGR.

Estos campos no se encuentran definidos dentro de la documentación de la estructura de datos entregado por MNEMO a la CGR, pero si es un campo que se encuentra dentro de la entidad de la estructura de base de datos que funciona en la CGR.

NUM_PROCESO (VARCHAR 200)

FECHA_ENVIO_SUSTANCIADOR (TIMESTAMP 6)

NOMBRE_SUSTANCIADOR (VARCHAR 4000) 1. Este dato se puede incorporar en ésta 1. Si esta información no está siendo



Número de la

Entidad Entidad



Entidad a partir del identificador del sustanciador, lo ideal sería que fuera el documento de identidad (Cédula). 2. Este campo no se encuentra definido dentro de la documentación de la estructura de datos que MNEMO entrega a la CGR. 3. No existe un documento de control de cambios donde se documenten éstas modificaciones en la Base de Datos.

inferida desde el Directorio Activo Es recomendable la creación de una entidad SUSTANCIADORES, para identificar al

sustanciador con el documento de identidad, no con el nombre ya que ésta es una característica propia de otra entidad no de la entidad NOTIFICACIONES_ELECTRONICAS.

2. Verificar la pertinencia de los campos para realizar la actualización de la documentación correspondiente o en su defecto proceder con la eliminación de los campos de la estructura.

GRUPO_SUSTANCIADOR (VARCHAR 4000 BYTE)

1. El sustanciador debe pertenecer a un grupo, atributo que idealmente se debería asignar al Sustanciador en la Entidad SUSTANCIADORES si ésta se define dentro del modelo de datos. 2. Este campo no se encuentra definido dentro de la documentación de la estructura de datos que MNEMO entrega a la CGR. 3. No existe un documento de control de cambios donde se documenten éstas modificaciones en la Base de Datos.

1. Si esta información no está siendo inferida desde el Directorio Activo. Es recomendable la creación de la entidad GRUPO_SUSTANCIADORES, se

podrían definir aspectos como id_grupo_sustanciador, nombre_grupo_sustanciador, entre los

demás que se requieran para poder desarrollar de la mejor manera el PRF. 2. Verificar la pertinencia de los campo para realizar la actualización de la documentación correspondiente o en su defecto proceder con la eliminación de los campos de la estructura.

ID_TIPO_NOTIFICACION (NUMERIC) 1. Problema de normalización, por no contemplarse la 2da Forma Normal. 2. Este campo no se encuentra definidos dentro de la documentación de la estructura de datos. 3. No existe un documento de control de cambios donde se documenten éstas modificaciones en la Base de Datos.

1. Se deberían administrar estos tipos desde otra entidad lo ideal sería la creación de una entidad llamada TIPO_NOTIFICACIONES, entidad desde donde se pueden administrar el Id_Tipo_Notificacion y el Tipo_notificación.

2. Verificar la pertinencia de los campos para realizar la actualización de la documentación correspondiente o en su

TIPO_NOTIFICACION (VARCHAR 200 BYTE)



Número de la

Entidad Entidad



defecto proceder con la eliminación de los campos de la estructura.

ETAPA (VARCHAR 200 BYTE)

Problema de Normalización, incurren en la 2da Forma Normal, este registro deberá ser una entidad aparte.

Este campo no se encuentra documentado dentro de la estructura entregada por MNEMO a la CGR

Sería recomendable la existencia de una entidad llamada ETAPAS donde se

haga la clasificación y se asigne un identificador para cada una de las etapas definidas dentro del PRF.

Realizar la actualización del documento Estructura Base de Datos PRF V4.0

FECHA_ASIG_COMPETENTE (TIMESTAMP 6)



91 RECURSOS

Tabla que almacena todos los recursos interpuestos a los fallos para todos los expedientes generados del PRF. La relación del recurso interpuesto con el fallo se muestra en los siguientes puntos.

ID_RECURSO (NUMBER): Identificador del recurso. Es un valor numérico autogenerado.

FECHA (DATE): Fecha del recurso interpuesto.


ID_TIPO_RECURSO (NUMBER): Identificador del tipo de recurso seleccionado. Está relacionado con el identificador de la tabla de la entidad 122.

DESC_TIPO_RECURSO (VARCHAR2 200 BYTE): Nombre del tipo de recurso seleccionado. Está relacionado con la tabla de la entidad 122.

Problemas con la 2da Forma Normal, este es un registro que se debe definir en una entidad que administre Tipos de Recursos.

Esta es una característica que se debe ingresar desde la entidad RIA_TIPOS_RECURSOS o en la entidad TIPOS_RECURSOS, no en ésta entidad.

Ésta descripción no se encuentra dentro de ninguna de la entidades



Número de la

Entidad Entidad



mencionadas.

N_AUTO (VARCHAR2 200 BYTE): Número de auto del recurso interpuesto.

N_FALLO (VARCHAR2 200 BYTE): Número de fallo asociado al recurso.

NUM_PROVIDENCIA (VARCHAR 200) Estos atributos no se encuentran documentados en la estructura que SAE entrega a la CGR, sin embargo en la base de datos que actualmente está funcionado en la CGR estos atributos hacen parte de esta entidad. No existe un documento de control de cambios donde se documenten éstas modificaciones en la Base de Datos.



92 RECURSOS_APE_FALLO

Tabla que relaciona el identificador del recurso interpuesto (entidad 91) con el fallo (entidad 71). En esta tabla únicamente se almacenan aquellas relaciones correspondientes a los recursos de apelación del PRF.

Son los mismos identificadores de la entidad RECURSOS_REPO_FALLO, lo

que indica que más de una entidad esta almacenando la misma información. La clave de estas entidades es conformada por los mismos campos de las entidades RECURSOS y FALLOS

Es recomendable validar cuales son los tipos de recursos existentes en la entidad TIPOS_RECURSOS ya que estos dos

identificadores son los mismos de la entidad RECURSOS_REPO_FALLO.

Sería importante realizar un análisis de los datos que se están consignando en ésta entidad.

ID_FALLO (NUMBER): Identificador del fallo.

ID_RECURSO (NUMBER): Identificador del recurso.

93 RECURSOS_REPO_FALLO

Tabla que relaciona el identificador del recurso interpuesto (entidad 91) con el fallo (entidad 71). En esta tabla únicamente se almacenan aquellas relaciones correspondientes a los recursos de reposición del PRF.

Son los mismos identificadores de la entidad RECURSOS_APE_FALLO, lo que

indica que más de una entidad esta almacenando la misma información. La clave de estas entidades es conformada por los mismos campos de las entidades RECURSOS y FALLOS

Es recomendable validar cuales son los tipos de recursos existentes en la entidad TIPOS_RECURSOS ya que estos dos

identificadores son los mismos de la entidad RECURSOS_APE_FALLO

Sería importante realizar un análisis de los datos que se están consignando en ésta entidad.

ID_FALLO (NUMBER): Identificador del fallo.

ID_RECURSO (NUMBER): Identificador del recurso.

94 RESPONSABLES

Tabla que almacena todos los presuntos responsables que intervienen para todos los expedientes de todas las etapas (Auto de Apertura de la Indagación Preliminar, Auto de Cierre de la Indagación Preliminar y Auto de Apertura del PRF Ordinario). Las relaciones con



Número de la

Entidad Entidad



cada etapa se muestran en los siguientes puntos.

ID_PRESPONSABLE (NUMBER): Identificador del presunto responsable. Es un valor numérico autogenerado.

Si es un número autogenerado, cual es la relación con la estructura RESPONDSABLES.

Una mejor práctica sería el hacer uso del número de identificación del Responsable (NIT o Cédula), como identificador de ésta estructura.

MOTIVO_IMPUTACION (VARCHAR2 4000 BYTE): Motivo de la imputación.

NOMBRE (VARCHAR2 200 BYTE): Nombre del presunto responsable.

N_CEDULA (VARCHAR2 200 BYTE): Número de cédula.

CARGO (VARCHAR2 200 BYTE): Cargo del presunto responsable.

DIRECCION (VARCHAR2 200 BYTE): Dirección del presunto responsable.

EMAIL (VARCHAR2 200 BYTE): Dirección de correo del presunto responsable.


RECIBIR_NOTIFICACIONES (NUMBER): Indica si el presunto responsable da autorización a recibir notificaciones en el sistema.

Está definido como un valor numérico, dando la opción de ingresar por lo menos a nivel de base de datos un valor compuesto hasta por 38 dígitos.

Una mejor opción es definir éste campo como un valor lógico 1-0, se pueden presentar inconvenientes si se ingresan valores diferentes al 1-0

95 RESPONSABLES_AAINDP_ANIP

Tabla que relaciona el identificador del responsable (entidad 94) con el expediente al que va asociado. Esta tabla está destinada a guardar las relaciones para el auto de apertura de la indagación preliminar para el expediente de Antecedentes e Indagación Preliminar.

Son los mismos identificadores de las entidades RESPONSABLES_ACINDP_PRF, RESPONSABLES_AAINDP_ANIP lo que

indica que más de una entidad esta almacenando la misma información. La clave de estas entidades es conformada por los mismos campos de las entidades RESPONSABLES.

Se puede estar presentando la siguiente situación, teniendo en cuenta que el identificador de un RESPONSABLES no

es la cédula sino un valor autogenerado

Es recomendable validar como se hace la validación de la información que debe almacenarse esta entidad, ya que el identificador es el mismo de las entidades según la documentación entregada por MNEMO. RESPONSABLES_AAINDP_PRF, RESPONSABLES_AAPRF, RESPONSABLES_ACINDP_ANIP RESPONSABLES_ACINDP_PRF.

ID_REQUEST (NUMBER): Identificador interno del expediente.

ID_PRESPONSABLE (NUMBER): Identificador del presunto responsable.



Número de la

Entidad Entidad



entonces la combinación de los registros ID_REQUEST e ID_PRESPONSABLE,

nunca van a generar un error de identificador, pero en términos de información si se pueden presentar inconsistencias.

96 RESPONSABLES_AAINDP_PRF

Tabla que relaciona el identificador del responsable (entidad 94) con el expediente al que va asociado. Esta tabla está destinada a guardar las relaciones para el auto de apertura de la indagación preliminar para el expediente de PRF.


indica que más de una entidad esta almacenando la misma información. La clave de estas entidades es conformada por los mismos campos de las entidades RESPONSABLES

Es recomendable validar como se hace la validación de la información que debe almacenarse esta entidad, ya que el identificador es el mismo de las entidades, según la documentación entregada por MNEMO. RESPONSABLES_AAPRF, RESPONSABLES_AAINDP_ANIP , RESPONSABLES_ACINDP_ANIP RESPONSABLES_ACINDP_PRF.



97 RESPONSABLES_AAPRF

Tabla que relaciona el identificador del responsable (entidad 94) con el expediente al que va asociado. Esta tabla está destinada a guardar las relaciones para el auto de apertura del PRF Ordinario para el expediente de PRF.




es la cédula sino un valor autogenerado entonces la combinación de los registros ID_REQUEST e ID_PRESPONSABLE,


Es recomendable validar como se hace la validación de la información que debe almacenarse esta entidad, ya que el identificador es el mismo de las entidades, según documentación entregada por MNEMO. RESPONSABLES_AAPRF, RESPONSABLES_AAINDP_ANIP , RESPONSABLES_ACINDP_ANIP RESPONSABLES_ACINDP_PRF.



RECIBIR_NOTIFICACIONES (NUMBER): Indica si el presunto responsable da autorización a recibir notificaciones en el expediente.

Está definido como un valor numérico, dando la opción de ingresar por lo menos a nivel de base de datos un valor compuesto

Una mejor opción es definir éste campo como un valor lógico 1-0, se pueden presentar inconvenientes si se ingresan



Número de la

Entidad Entidad



hasta por 38 dígitos. valores diferentes al 1-0

98 RESPONSABLES_ACINDP_ANIP

Tabla que relaciona el identificador del responsable (entidad 94) con el expediente al que va asociado. Esta tabla está destinada a guardar las relaciones para el auto de cierre de la indagación preliminar para el expediente de Antecedentes e Indagación Preliminar.






Es recomendable validar como se hace la validación de la información que debe almacenarse esta entidad, ya que el identificador es el mismo de las entidades, según documentación entregada por MNEMO. RESPONSABLES_AAINDP_PRF, RESPONSABLES_AAPRF, RESPONSABLES_AAINDP_ANIP , RESPONSABLES_ACINDP_PRF.



99 RESPONSABLES_ACINDP_PRF

Tabla que relaciona el identificador del responsable (entidad 94) con el expediente al que va asociado. Esta tabla está destinada a guardar las relaciones para el auto de cierre de la indagación preliminar para el expediente de PRF.





nunca van a generar un error de identificador, pero en términos de información si se pueden presentar

Es recomendable validar como se hace la validación de la información que debe almacenarse esta entidad, ya que el identificador es el mismo de las entidades, según documentación entregada por MNEMO. RESPONSABLES_AAINDP_PRF, RESPONSABLES_AAPRF, RESPONSABLES_AAINDP_ANIP , RESPONSABLES_ACINDP_ANIP.





Número de la

Entidad Entidad



inconsistencias.

100 RIA_DECISIONES

Decisiones que se realizan sobre recursos de actuaciones realizadas, en las etapas de Actuaciones Procesales, Autos de Pruebas, Auto de imputación fiscal o Audiencia de Descargos. La tabla de relación con los recursos aparece seguidamente.

ID_DECISION (NUMBER): Identificador de la decisión creada.

ID_TIPO_DECISION (NUMBER): Tipo de decisión tomada.

DESC_TIPO_DECISION (VARCHAR2 200 BYTE): Descripción de la decisión tomada.

Problema de normalización con la 2da forma normal

Ésta descripción debe ser la misma que se ingresa en la entidad RIA_TIPOS_DECISION, habría que

mirar si se trata de las mismas Decisiones. De no ser así sería recomendable la existencia de una entidad TIPO_DECISIONES donde se

registre el identificador de éstas, el tipo de decisión y la descripción de ésta.

N_AUTO (VARCHAR2 200 BYTE): Número de auto de la decisión.

FECHA (DATE): Fecha en la que se toma la decisión.

OBSERVACIONES (VARCHAR2 4000 BYTE): Observaciones.

TIMESTAMP (DATE): Fecha interna de la creación de la decisión.

102 RIA_RECURSOS

Tabla que almacena los recursos realizados sobre actuaciones, en las etapas de Actuaciones Procesales, Autos de Pruebas, Auto de Imputación Fiscal o Audiencia de Descargos. Las tablas de relación con las diferentes etapas de actuaciones aparecen seguidamente.

De tener consignada la misma información en estas entidades RECURSOS y RIA_RECURSOS

Es recomendable hacer uso de una sola entidad. ID_RECURSO (NUMBER): Identificador del



Número de la

Entidad Entidad



recurso realizado. Sería importante realizar un análisis de los datos que se están consignando en éstas entidades.

ID_TIPO_RECURSO (NUMBER): Tipo de recurso realizado.

Verificar si los tipos de recursos son los mismos de las entidades TIPOS_RECURSOS o RIA_TIPOS_RECURSOS.

DESC_TIPO_RECURSO (VARCHAR2 200 BYTE): Descripción del recurso realizado.

N_AUTO (VARCHAR2 200 BYTE): Número de auto del recurso realizado.

FECHA (DATE): Fecha en la que se realiza el recurso.

OBSERVACIONES (VARCHAR2 4000): Observaciones.

TIMESTAMP (DATE): Fecha interna de registro del recurso realizado.

107 RIA_SEGUNDA

Tabla que almacena la segunda instancia realizada sobre actuaciones, en las etapas de Actuaciones Procesales, Autos de Pruebas, Auto de Imputación Fiscal o Audiencia de Descargos. Las tablas de relación con las diferentes etapas de actuaciones aparecen seguidamente.

ID_SEGUNDA (NUMBER): Identificador de la segunda instancia realizada.

ID_TIPO_ SEGUNDA (NUMBER): Tipo de actuación realizado.

DESC_TIPO_SEGUNDA (VARCHAR2 200 BYTE): Descripción de la actuación realizada.

Problemas sobre la normalización en su 2da forma.

Esta descripción no debe hacerse en ésta entidad. Se sugiere hacer uso del identificador de la entidad RIA_TIPOS_SEGUNDA, esto evitaría

N_AUTO (VARCHAR2 200 BYTE): Número de auto de la segunda instancia realizada.

FECHA (DATE): Fecha en la que se realiza la segunda instancia.

OBSERVACIONES (VARCHAR2 4000): Observaciones.

TIMESTAMP (DATE): Fecha interna de registro de la segunda instancia realizada.



Número de la

Entidad Entidad



108 RIA_SEGUNDA_ACTPROC

Tabla de relación entre el recurso realizado de la tabla RIA_SEGUNDA y la actuación de la etapa de Actuaciones Procesales.

En el modelo implantado en la CGR, el identificador de ésta entidad está compuesto por los registros de ID_SEGUNDA y ID_ACTUACION Es recomendable que MNEMO debe

realizar la actualización del documento Estructura de base de Datos V4.0 que entrego a la CGR.

ID_RECURSO (NUMBER): Identificador de la

segunda instancia.

No es un identificador válido. Dentro de esta entidad, está mal definido en el documento entregado por MENEMO a la CGR.

ID_ACTUACION (NUMBER): Identificador de la actuación.

109 RIA_SEGUNDA_AIMPF

Tabla de relación entre el recurso realizado de la tabla RIA_ SEGUNDA y la actuación de la etapa de Auto de imputación fiscal.

En el modelo implantado en la CGR, el identificador de ésta entidad está compuesto por los registros de ID_SEGUNDA y ID_REQUEST Es recomendable que MNEMO debe


ID_RECURSO (NUMBER): Identificador de la

segunda instancia.

No es un identificador válido. Dentro de esta entidad, está mal definido en el documento entregado por MENEMO a la CGR.

ID_REQUEST (NUMBER): Identificador del expediente.

110 RIA_SEGUNDA_APPRF

Tabla de relación entre el recurso realizado de la tabla RIA_ SEGUNDA y la actuación de la etapa de Autos de Pruebas.

En el modelo implantado en la CGR, el identificador de ésta entidad está compuesto por los registros de ID_SEGUNDA y ID_ACTUACION Es recomendable que MNEMO debe


ID_RECURSO (NUMBER): Identificador de la segunda instancia.

No es un identificador válido.


111 RIA_SEGUNDA_AUDDESC

Tabla de relación entre el recurso realizado de la tabla RIA_ SEGUNDA y la actuación de la etapa de Audiencia de Descargos.

En el modelo implantado en la CGR, el identificador de ésta entidad está compuesto por los registros de ID_SEGUNDA y ID_ACTUACION

Es recomendable que MNEMO debe realizar la actualización del documento Estructura de base de Datos V4.0 que

entrego a la CGR. ID_RECURSO (NUMBER): Identificador de la segunda instancia.

No es un identificador válido. Se encuentra mal documentado en el documento entregado por MNEMO a la CGR.



Número de la

Entidad Entidad




112 RIA_TIPOS_DECISION

Tipos de decisiones a realizar sobre la tabla RIA_DECISIONES, sobre las decisiones de los recursos realizados de las actuaciones correspondientes.

Esta estructura no se está relacionado con ninguna otra estructura dentro del modelo de datos, posiblemente se debería relacionar con la estructura RIA_DECISIONES

Hacer un análisis del modelo de negocio para identificar por qué ésta estructura aun cuando fue creada dentro del modelo, actualmente no se relacione con ninguna otra estructura.

ID_TIPO_DECISION (NUMBER): Identificador del tipo de decisión.

DESC_TIPO_DECISION (VARCHAR2 200 BYTE): Descripción del tipo de decisión.

113 RIA_TIPOS_RECURSOS

Tipos de decisiones a realizar sobre la tabla RIA_RECURSOS, sobre los recursos realizados de las actuaciones correspondientes.

Esta estructura no se está relacionado con ninguna otra estructura dentro del modelo de datos, posiblemente se debería relacionar con la estructura RIA_RECURSOS


ID_TIPO_RECURSO (NUMBER): Identificador del tipo de recurso.

DESC_TIPO_RECURSO (VARCHAR2 200 BYTE): Descripción del tipo de recurso.

114 RIA_TIPOS_SEGUNDA

Tipos de actuaciones de la segunda instancia a realizar sobre la tabla RIA_DECISIONES, sobre las actuaciones correspondientes.

Esta estructura no se está relacionado con ninguna otra estructura dentro del modelo de datos, posiblemente se debería relacionar con la estructura RIA_SEGUNDA


ID_TIPO_SEGUNDA (NUMBER): Identificador del tipo de actuación.

DESC_TIPO_SEGUNDA (VARCHAR2 200 BYTE): Descripción del tipo de actuación.

116 TIPOS_ACTUACIONES_CONSULTAS

Tabla maestra que almacena todos los tipos de actuaciones que intervienen en el proceso de la aplicación SAE. Son utilizadas en la etapa de consulta del PRF.

Esta estructura no se está relacionado con ninguna otra estructura dentro del modelo de datos, posiblemente se debería relacionar con la estructura ACTUACIONES. Además el campo

ACTUACION ya está definido en la entidad a la cual le corresponde capturar este dato, la definición de este campo en esta entidad TIPOS_ACTUACIONES genera

problemas de Normalización de la 2da forma normal.


ID_TIPO_ACTUACION: Identificador del tipo de actuación. Es un valor numérico autogenerado.

ACTUACION (VARCHAR2 200 BYTE): Nombre del tipo de actuación.

ID_TIPO_EXTERNO (VARCHAR2 200 BYTE): Identificador del tipo de actuación externo.



Número de la

Entidad Entidad



117 TIPOS_ACTUACIONES_DECISION

Tabla maestra que almacena todos los tipos de actuaciones que intervienen en el proceso de la aplicación SAE. Son utilizadas en la etapa de decisión de los recursos interpuestos del PRF.

ID_TIPO_ACTUACION (NUMBER): Identificador del tipo de actuación. Es un valor numérico autogenerado.


Problemas de normalización en la 2da forma. Este campo ya se ha definido en la estructura a la cual corresponde hacer la descripción, TIPOS_ACTUACIONES


118 TIPOS_ACTUACIONES_FALLOS

Tabla maestra que almacena todos los tipos de actuaciones que intervienen en el proceso de la aplicación SAE. Son utilizadas en la etapa de fallos de primera instancia del PRF.

ID_TIPO_ACTUACION (NUMBER): Identificador del tipo de actuación. Es un valor numérico autogenerado.


Problemas de normalización 2da Forma. Este campo ya se ha definido en la estructura a la cual corresponde hacer la descripción TIPOS_ACTUACIONES.


122 TIPOS_RECURSOS

Tabla maestra que almacena todos los tipos de recursos interpuestos que intervienen en el proceso de la aplicación SAE. Son utilizados en la etapa de recursos interpuestos del PRF.

Existencia de otra estructura en donde también se definen tipos de recursos.

Verificar si los tipos de recurso descritos en ésta entidad son los mismos que se definen en la entidad RIA_TIPO_RECURSOS.

ID_TIPO_RECURSO (NUMBER): Identificador del tipo de recurso. Es un valor numérico autogenerado.

RECURSO (VARCHAR2 200 BYTE): Nombre del recurso.

ID_TIPO_EXTERNO (VARCHAR2 200 BYTE):



Número de la

Entidad Entidad



Identificador del tipo de recurso externo.

123 TRAMITES_POSTERIORES

Tabla que almacena todos los trámites posteriores para todos los del PRF. Las relaciones con el expediente se muestran en la entidad siguiente.

ID_TRAMITE (NUMBER): Identificador del trámite posterior. Es un valor numérico autogenerado.


FECHA_EJECUTORIA (DATE): Fecha ejecutoria del trámite.

FECHA_TRASLADO (DATE): Fecha de traslado del trámite.

CUANTIA (FLOAT): Cuantía del trámite.

RECAUDACION (FLOAT): Recaudación.

NUM_PROVIDENCIA (VARCHAR 200 BYTE) Estos atributos no se encuentran documentados en la estructura que SAE entrega a la CGR, sin embargo en la base de datos que actualmente está funcionado en la CGR estos atributos hacen parte de esta entidad. No existe un documento de control de cambios donde se documenten éstas modificaciones en la Base de Datos.




6.2.2 Análisis de Vistas

Dentro del documento Estructura de Base de Datos PRF v4.0 entregado por MNEMO a la

CGR, se realiza la documentación de un total de 46 vistas, sin embrago el modelo que

actualmente funciona dentro de la CGR cuenta con un total de 102 vistas.

Se presenta a continuación el listado de las vistas que no se encuentran documentadas

dentro de la información que MNEMO ha documentado en Estructura Base de Datos del

PRF v4.0 y entregado a la CGR.

Tabla 3. Vistas que no se encuentran documentadas en el Documento Esquema Base de Datos PRF v4.0

No Nombre de Vista No Nombre de Vista No Nombre de Vista

1 VIEW_ENTIDADES_AFECT_FALLO_P 20 VIEW_IDX_DOC_CONSULTAS_PRF 39 VIEW_IDX_DOC_RIA_DEC_AIMPF

2 VIEW_ENTIDADES_AFECT_FALLO_S 21 VIEW_IDX_DOC_DECREC_FALLO1 40 VIEW_IDX_DOC_RIA_DEC_APPRF

3 VIEW_ENTIDADES_MUNI_DEP 22 VIEW_IDX_DOC_FALLO1 41 VIEW_IDX_DOC_RIA_DEC_AUDDESC

4 VIEW_GRUPOS_ROL_TIPO 23 VIEW_IDX_DOC_MEDIDA_CAUTELAR 42 VIEW_IDX_DOC_RIA_REC_ACTPROC

5 VIEW_IDX_DOC_AAIMPF 24 VIEW_IDX_DOC_NOTIF_AAIMPF 43 VIEW_IDX_DOC_RIA_REC_AIMPF

6 VIEW_IDX_DOC_AAINDP_ANIP 25 VIEW_IDX_DOC_NOTIF_AAPRF 44 VIEW_IDX_DOC_RIA_REC_APPRF

7 VIEW_IDX_DOC_AAINDP_PRF 26 VIEW_IDX_DOC_NOTIF_AIMPF 45 VIEW_IDX_DOC_RIA_REC_AUDDESC

8 VIEW_IDX_DOC_AAPRF 27 VIEW_IDX_DOC_NOTIF_AUD_DEC 46 VIEW_IDX_DOC_RIA_SEG_ACTPROC

9 VIEW_IDX_DOC_ACINDP_ANIP 28 VIEW_IDX_DOC_NOTIF_AUDDESC 47 VIEW_IDX_DOC_RIA_SEG_AIMPF

10 VIEW_IDX_DOC_ACINDP_PRF 29 VIEW_IDX_DOC_NOTIF_CONSULTAS 48 VIEW_IDX_DOC_RIA_SEG_APPRF

11 VIEW_IDX_DOC_ACTUACIONES_DESC 30 VIEW_IDX_DOC_NOTIF_DECISIONES 49 VIEW_IDX_DOC_RIA_SEG_AUDDESC

12 VIEW_IDX_DOC_ACTUACIONES_PPRF 31 VIEW_IDX_DOC_NOTIF_FALLO_P 50 VIEW_IDX_DOC_TRAMITE_POST

13 VIEW_IDX_DOC_ACTUACIONES_PRF 32 VIEW_IDX_DOC_NOTIF_MEDIDAS 51 VIEW_INDICE_DOC_ANIP

14 VIEW_IDX_DOC_AIMPF 33 VIEW_IDX_DOC_NOTIF_PPRF 52 VIEW_INDICE_DOC_PRF

15 VIEW_IDX_DOC_ANTECEDENTES_ANIP 34 VIEW_IDX_DOC_NOTIF_PRF 53 VIEW_INFORME_APODERADOS

16 VIEW_IDX_DOC_ANTECEDENTES_PRF 35 VIEW_IDX_DOC_NOTIF_RECURSOS 54 VIEW_INFORME_GARANTES

17 VIEW_IDX_DOC_APINDP_ANIP 36 VIEW_IDX_DOC_NOTIF_TRAMITES 55 VIEW_INFORME_RESPONSABLES

18 VIEW_IDX_DOC_APINDP_PRF 37 VIEW_IDX_DOC_REC_FALLO1 56 VIEW_NUMERO_DOCS_EXPEDIENTE

19 VIEW_IDX_DOC_AUD_DECISION 38 VIEW_IDX_DOC_RIA_DEC_ACTPROC

6.2.3 Análisis de Índices

El modelo solo tiene creados los índices de llave primaria generados a partir de la creación de

las entidades, aunque se evidencia que entidades como GRUPOS_ROL y GRUPOS_FALLOS

carecen de estos índices dentro del modelo.

Es recomendable la implementación o el desarrollo de más índices ya que los índices en una

base de datos permiten el mejoramiento en cuanto a la velocidad de las operaciones que se

desarrollen dentro de la misma.

Para algunos inconvenientes que se han presentado en cuanto a la velocidad de la Base de

Datos la creación de índices ayudaría a mitigar este inconveniente.


6.2.4 Análisis de Paquetes

Con respecto al modelo de datos de la solución, no hay uso de paquetes. Dentro de la

información y documentación suministrada se observó que no existen definidos ni

documentados paquetes para la Base de Datos del SAE.

Es recomendable la definición de paquetes dentro del modelo, puesto que estos permiten el

agrupamiento de procesos y funciones de forma lógica. También permiten agrupar en un único

objeto “el paquete definido”, que comprende todo lo asociado a un determinado tipo de tarea.

Al ser cargado en memoria este proceso o tarea se tendrán que realizar menos llamados a

disco, lo que también se convierte en un factor favorable para el desempeño de la Base de

Datos.

6.2.5 Análisis de Procedimientos

Dentro del modelo de datos solo se hace la definición del procedimiento,

“IDENTIFICADOR_EXPEDIENTE” este procedimiento se utiliza para generar el código del

expediente que se va a crear. El formato que se genera es TIPO-EXPEDIENTE-AÑO-

NUMERO.

Se recomienda ampliar los procesos almacenados actualmente dentro de la base de datos. Por

ejemplo, se podrían diseñar procesos de búsqueda para los autos por un nombre específico.

Esto ayudaría al funcionario a interactuar más fácilmente con la herramienta porque optimizaría

no solo la búsqueda, sino la precisión de la misma.

La ventaja de un procedimiento almacenado es que al ser ejecutado, lo hace directamente

sobre el motor de Base de Datos. En el caso de la CGR los procedimientos se ejecutarían sobre

el motor de Oracle, y si el procedimiento es de búsqueda, no se tendrá que volver a crear una

tabla temporal como cuando se realiza una búsqueda convencional.

6.2.6 Análisis de Funciones

Dentro de la información suministrada por parte de MNEMO y por parte de la CGR, no hay

definidas funciones para el modelo de datos del SAE.

Sería muy favorable para el rendimiento de la base de datos del SAE, la definición y creación

de tareas como: la búsqueda de hallazgos, búsqueda de responsables, paso de primera a

segunda instancia, para la asignación de un sustanciador a un proceso que pase de primera a

segunda instancia, para la captura del código asignado a cada auto desde SIREF y para los

que la CGR estime conveniente.


6.2.7 Análisis de Disparadores

Dentro del modelo de datos establecido, existe un total de 21 disparadores o triggers asociados

directamente a cada una de las secuencias.

6.2.8 Análisis de Secuencias

Dentro de la definición del Modelo de Datos del SAE existen un total de 21 Secuencias. Dentro

de éstas, se encuentran secuencias para estructuras como:

ENTIDADES: No es pertinente la definición de secuencias para esta entidad, dado que

la DIAN ya le ha asignado a éstas un identificador único.

APODERADOS y RESPONSABLES: No es pertinente la definición de secuencias en

esta entidad dado que las personas (para el caso de responsables y/o apoderados)

tienen un número de identificación, que es el número de la cédula.

AUTOS: Sería recomendable que éste fuera el número con el que se crea el auto en el

SIREF y su asociación fuera uno de los procesos definidos dentro de la base de datos.

No es pertinente la definición de secuencias en las entidades anteriores, ya que son entidades

que almacenarán información que ya cuentan con identificadores únicos.

6.3 RECOMENDACIONES

Con respecto a la administración de datos, además de las presentadas en la Tabla 2, se

recomienda:

- Definir una nomenclatura común para identificar a las entidades, municipios y otros

elementos que se manejan en las diferentes aplicaciones. Igualmente, generar las acciones

requeridas para que todas las aplicaciones, y en general la documentación usada en la

entidad, lo utilicen. Esto podría tomar un tiempo relativamente largo, pero entre más tarde

se haga, más dispendioso va a ser hacerlo, y las inconsistencias entre la información

suministrada por las diferentes aplicaciones van a ser mayores.

- Una vez lograda la meta anterior, se podría empezar a trabajar en la definición de una

arquitectura SOA, que facilite la integración entre las aplicaciones y le dé una mayor

consistencia a la información manejada.


7. ASPECTOS JURÍDICOS SOBRE SAE, FIRMA ELECTRÓNICA Y

LAS ENTIDADES DE CERTIFICACIÓN CERRADAS

A continuación se rinde un concepto jurídico sobre el SAE, con relación a los aspectos más

relevantes de la firma electrónica y las principales implicaciones de constituirse como una

entidad de certificación cerrada.

CONCEPTO JURÍDICO

Contextualización

La Contraloría General de la República se encuentra en la etapa de implementación del

Sistema de Aseguramiento Electrónico, denominado SAE, que tiene como finalidad administrar

a través de una plataforma informática, los procesos de responsabilidad fiscal. Anterior a la

adquisición del SAE, el Proceso de Responsabilidad Fiscal se llevaba de manera física, y la

entidad no contaba con un sistema que permitiera optimizar el flujo del Proceso de

Responsabilidad Fiscal. Actualmente la entidad ha iniciado dicha transición, enfocándose

primordialmente en cargar los expedientes de los procesos existentes al sistema, al igual que

los nuevos procesos.

Por otro lado, la Contraloría General de la República ha tomado la iniciativa de convertirse en

una entidad de certificación cerrada4, lo que se traduce en ofrecer servicios propios de las

entidades de certificación sólo para el intercambio de mensajes entre la entidad y el suscriptor,

sin exigir remuneración por ello5. La doctrina establece que "las entidades de certificación son

aquellas personas jurídicas y privadas, incluidas las cámaras de comercio, que poseen el

hardware y software necesarios para la generación de firmas digitales, la emisión de

certificados sobre la autenticidad de las mismas y la conservación y archivo de documentos

soportados en mensajes de datos6."

Organismo Nacional de Acreditación de Colombia (ONAC)

El ONAC es una entidad creada en ejecución de las políticas adoptadas en el CONPES 3446,

en noviembre de 2007 y cumple funciones desde el año 2008 como Organismo Nacional de

Acreditación de Colombia. El mismo ONAC se ha definido como la opción de país para obtener

el reconocimiento internacional de la acreditación.

4 Ley 527 de 1999, artículo 2. “Está facultada para emitir certificados en relación con las firmas digitales de las

personas, ofrecer o facilitar los servicios de registro y estampado cronológico de la transmisión y recepción de mensajes de datos, así como cumplir otras funciones relativas a las comunicaciones basadas en las firmas digitales." 5 Decreto 1747 de 2000, artículo 1.

6 HENAO RESTREPO, Darío. Ley de Comercio Electrónico en Colombia - Ley 527 de 1999. Artículo incluido en la

obra Nuevos Retos del Derecho Comercial del Colegio de Abogados de Medellín. Edición 2000. Biblioteca Jurídica Dike. Pág. 171.


El ONAC7 es una entidad creada en ejecución de las políticas adoptadas en el CONPES 34468,

en noviembre de 2007 y cumple funciones desde el año 2008 como Organismo Nacional de

Acreditación de Colombia. La misma ONAC se ha definido como la opción del país para obtener

el reconocimiento internacional de la acreditación, continuando con las labores que venía

ejerciendo la Superintendencia de Industria y Comercio - en adelante SIC-.

El ONAC se creó como consecuencia de la problemática que surgió cuando la SIC fue sometida

a dos (2) pre-evaluaciones a nivel internacional. Si bien evidenciaron el desarrollo de su

capacidad técnica, observaron que condiciones estructurales afectaban su independencia y

autonomía e impedían su reconocimiento a nivel internacional como organismo internacional de

acreditación 9 . Así surgió este Organismo, como entidad de naturaleza mixta, de carácter

técnico, con aplicación de estándares internacionales, independiente e imparcial y con

autonomía financiera y administrativa.

Fundamento Jurídico

A continuación se presenta el marco legal nacional e internacional que enmarca el presente

análisis.

Marco legal internacional

Éste marco legal internacional es creado para armonizar y estandarizar la normatividad

existente en relación a las firmas electrónicas:

• International Organization for Standardization / International Electrotechnical Commission-

ISO/IEC 17011.

• International Organization for Standardization / International Electrotechnical Commission-

ISO/IEC 7498-2: (Arquitectura de Seguridad de OSI) sobre la que descansan todos los

desarrollos normativos posteriores, regula los servicios de seguridad sobre

confidencialidad, integridad, autenticidad, control de accesos y no repudio.

• Comisión de las Naciones Unida para el derecho mercantil internacional. Ley Modelo de la

CNUDMI sobre Firmas Electrónicas de 5 de julio de 2001, artículos 3 y 6.

El marco legal colombiano

El marco legal a continuación comprende la regulación existente a la fecha en relación a la

firma electrónica en Colombia:

7 Decreto 4738 de 2008. Art. 3. “Designase como Organismo Nacional de Acreditación al Organismo Nacional de

Acreditación de Colombia, ONAC, corporación de carácter privado, de naturaleza mixta, sin ánimo de lucro, constituida mediante documento privado del 20 de noviembre de 2007, debidamente autenticado por la Notaría Sexta de Bogotá, dentro del marco de la Ley 489 de 1998 y las normas sobre ciencia y tecnología”. 8 En él se contienen los lineamientos para el desarrollo de una política nacional que: i) reorganice el marco

institucional del Sistema Nacional de Normalización, Certificación y Metrología (SNNCM); ii) fortalezca las actividades de expedición de reglamentos técnicos, normalización, acreditación, designación, evaluación de la conformidad y metrología; y iii ) permita obtener el reconocimiento internacional del Subsistema Nacional de la Calidad. 9 (ISO/IEC 17000, 5.2). La acreditación es un servicio de atestación y declaración de tercera parte sobre la

competencia técnica y la imparcialidad de los organismos que evalúan la conformidad de productos y procesos con normas técnicas de mercado o con requisitos técnicos de exigencia legal.


• Ley 527 de Agosto de 1999: Define y reglamenta el acceso y uso de los mensajes de

datos, del comercio electrónico y de las firmas digitales, se establecen las entidades de

certificación (parte de una PKI) y se dictan otras disposiciones.

• Decreto 1747 de Septiembre de 2000: Se reglamenta parcialmente la ley 527 en lo

relacionado con las entidades de certificación, los certificados y las firmas digitales.

• Resolución 26930 de Octubre de 2000: Estándares para la autorización y funcionamiento

de las entidades de certificación y sus auditores

• Decreto 19 de 2012: Por el cual se dictan normas para suprimir o reformar regulaciones,

procedimientos y trámites innecesarios existentes en la Administración Pública.

• Decreto 2364 de 2012: Por medio del cual se reglamenta el artículo 7 de la Ley 527 de

1999.

Problemas jurídicos

Con base en lo anterior, se definen los siguientes problemas jurídicos:

1. ¿Cuáles son los medios de identificación que engloban el concepto de firma

electrónica en Colombia?

La Real Academia de la Lengua define la firma como: “nombre y apellido o título de una

persona que ésta pone con rúbrica al pie de un documento escrito de mano propia o ajena, para

darle autenticidad, para expresar que se aprueba su contenido o para obligarse a lo que en él

se dice”. A partir de la definición expresada se establecen las siguientes características: (i)

Identificativa: sirve para identificar quién es el autor del documento; (ii) Declarativa: Significa la

asunción del contenido del documento por el autor de la firma; (iii) Probatorio: Permite identificar

si el autor de la firma es efectivamente aquél que ha sido identificado como tal en el acto de la

propia firma10.

Las firmas electrónica 11 son instrumentos mediante los cuales una persona autentica un

mensaje de datos, es decir, se identifica como suscriptor, sea o no el creador del mismo. Así

mismo, ésta se caracteriza por permitir la identificación del signatario, sólo puede ser generada

por el emisor del documento, y las informaciones que se generen a partir de la signatura deben

ser suficientes para poder validarlas.

Debe entenderse la “firma electrónica” como el género y la “firma digital” como la especie. De

esta forma se entiende que existen diversos medios de identificación que podrían tener cabida

dentro del concepto de firma electrónica, sin embargo se debe aclarar que si bien es cierto que

10

Rincón Cárdenas, Erick. Aproximación jurídica a la firma digital. Cámara de Comercio. Certicamara. Uniempresarial. Bogotá 2008. pg. 78. 11

Ortega Díaz. Juan Francisco. La firma y el contrato de certificación electrónicos. 2008. España. Thomson Arazandi. pg. 37. “Una firma electrónica sería simplemente cualquier método o símbolo basado en medios electrónicos utilizados o adoptados por una parte con la intención actual de vincularse o autenticar un documento, cumpliendo todas o algunas de las funciones características de la firma manuscrita”.


todo dato en forma electrónica que cumpla con una función identificativa puede ser considerado

como firma electrónica, no todos estos medios de identificación cuentan con el mismo nivel de

seguridad 12. Dentro de estos medios se encuentran los siguientes: medios biométricos 13 ,

contraseña o password14, la criptografía15, los acuerdos EDI16 y la firma digital17.

En la legislación colombiana, también prima el principio de neutralidad tecnológica e igualdad

de tratamiento de las tecnologías para la firma electrónica; el cual establece que ninguna de las

disposiciones contenidas en el decreto 2364 de 2012 será aplicada de modo que excluya,

restrinja o prive de efecto jurídico cualquier método, procedimiento, dispositivo o tecnología

para crear una firma electrónica que cumpla con los requisitos que establece el artículo 7 de la

Ley 527 de 1999.

Actualmente en Colombia existen tres tipos de firmas digitales: 1. La firma digital sin certificar

pero verificable18, 2. La firma digital avalada por una Entidad de Certificación Cerrada19 - ECC, y

3. La firma digital certificada por una Entidad de Certificación Abierta20. Actualmente la CGR

está haciendo uso de la firma digital, sin certificar pero verificable.

2. El hecho de que la CGR a la fecha no haya sido avalada por una entidad de

certificación, ¿Tiene incidencia en la autenticidad de las firmas expedidas por la

entidad?

12

Decreto 264 de 2012. Artículo 8. Criterios para establecer el grado de seguridad de las firmas electrónicas. Para

determinar si los procedimientos, métodos o dispositivos electrónicos que se utilicen como firma electrónica son seguros, y en qué medida lo son, podrán tenerse en cuenta, entre otros, los siguientes factores: 1) El concepto técnico emitido por un perito o un órgano independiente. y especializado. 2) La existencia de una auditoría especializada, periódica e independiente sobre los procedimientos, métodos o dispositivos electrónicos que una parte suministra a sus clientes o terceros como mecanismo electrónico de identificación personal. 13

Ortega Díaz, JF. La firma y el Contrato de Certificación Electrónicos. Madrid, España. 2008. Thomson. “Medios biométricos: las firmas biométricas consisten en la comparación de algún fenómeno corporal con una muestra o una información almacenada. De entre ellas sirvan como ejemplo: Las exploraciones de retina, los sistemas de identificación a través de huellas dactilares, los procesos de verificación de voz, los sistemas de quirogeometría, consistentes en el registro y en la comparación de alguna parte del cuerpo, entre otras.” 14

Ortega Díaz, JF. La firma y el Contrato de Certificación Electrónicos. Madrid, España. 2008. Thomson. “La contraseña es una clave que permite el acceso a una información determinada. Más que una firma es un elemento identificativo, pues, si bien identifica al autor, no garantiza la integridad del documento.” 15

Ortega Díaz, JF. La firma y el Contrato de Certificación Electrónicos. Madrid, España. 2008. Thomson. “La criptografía basada en algoritmos simétricos o de clave secreta: Como es sabido, la criptografía es el arte de cifrar la información. En la criptografía basada en algoritmos simétricos, la información es cifrada y descifrada a partir de una clave, que se ha acordado con anterioridad. 16

“El EDI (Electronic Data Interchange) intercambio electrónico de datos de computadora a computadora entre Socios Comerciales (cadenas), con la finalidad de ahorrar tiempo al eliminar los tradicionales métodos de preparación y envío de documentos a través de mensajería. A la vez, tiene la ventaja de ser un método más seguro y confiable para el manejo de información.” 17

Rincón Cárdenas, Erick. Aproximación jurídica a la firma digital. Cámara de Comercio. Certicamara. Uniempresarial. Bogotá 2008. “La firma digital es una de las especies de la firma electrónica y consiste en un conjunto de caracteres que acompaña a un documento o texto y dos claves, una pública y otra privada, por medio de las cuales se encripta el contenido. 18

Ley 527 de 1999, artículo 28. 19

Decreto 1747 de 2000. Artículo 1. Las Entidades de Certificación Cerradas ofrecen servicios propios de las

entidades de certificación sólo para el intercambio de mensajes entre la entidad y el suscriptor, sin exigir remuneración por ello. 20

Certicamara. Información de certificación digital. Las Entidades de Certificación Abiertas emiten certificados que le

permiten a sus dueños identificarse ante cualquier contraparte nacional o internacional.


Con fin de dar respuesta al anterior problema jurídico, se deben analizar los siguientes

elementos: autenticidad, validez, certificaciones, valor probatorio y los requisitos de

acreditación.

a) Autenticidad

La autenticidad se predica en relación al autor del documento firmado y se entiende que el

suscriptor tenía la intención de vincularse al mismo. Se establece que hay dos formas para

lograr la autenticidad del documento electrónico, la primera, consiste en suscribirse a una

entidad de certificación y firmarlo digitalmente; la otra será utilizar un “método adecuado” por

medio del que se pueda identificar a quien ha enviado un mensaje de datos.

A su vez, la Ley Modelo de Firmas Electrónicas de la CNUDMI, la cual fue incorporada al

ordenamiento jurídico colombiano, adopta el principio de “neutralidad tecnológica”, consagrando

que ninguna disposición podrá privar, restringir o excluir de efectos jurídicos a cualquier método

para crear firmas electrónicas que sea fiable y apropiado de acuerdo al entorno del mensaje de

datos21.

Además, debe tomarse en cuenta que conforme al principio de la hermenéutica jurídica, si la ley

no distingue no es permitido al intérprete hacerlo, es decir, si el electrónico es un documento y

ni el artículo 252 del Código de Procedimiento Civil ni la Ley 527 de 1999 lo excluyeron de esa

presunción, no hay razón para que el intérprete lo haga22. Así mismo, la doctrina representada

por el profesor Hernán Fabio López Blanco, citado por el profesor Jairo Parra Quijano, sostiene

lo mismo con base en el principio citado y señalan que la autenticidad de un documento no

puede partir de si es escrito o electrónico, sino de la certeza de su autoría23.

Además el Código General del Proceso en su artículo 24424 adoptado mediante Ley 1564 de

2012 consagra que se presumen auténticos los documentos electrónicos siempre y cuando sea

posible identificar al suscriptor del mismo.

21

Comisión de las Naciones Unida para el derecho mercantil internacional. Ley Modelo de la CNUDMI sobre Firmas Electrónicas de 5 de julio de 2001, artículos 3 y 6. 22

Instituto Colombiano de Derecho Procesal. LA PRESUNCIÓN DE AUTENTICIDAD DEL DOCUMENTO ELECTRÓNICO. Dra. CINDY CHARLOTTE REYES SINISTERRA. 1 de julio de 2009. 23

Se debe analizar conforme al artículo 7 de la Ley 527/99. 24

Ley 1564 de 2012. ARTÍCULO 244. DOCUMENTO AUTÉNTICO. Es auténtico un documento cuando existe

certeza sobre la persona que lo ha elaborado, manuscrito, firmado, o cuando exista certeza respecto de la persona a quien se atribuya el documento. Los documentos públicos y los privados emanados de las partes o de terceros, en original o en copia, elaborados, firmados o manuscritos, y los que contengan la reproducción de la voz o de la imagen, se presumen auténticos, mientras no hayan sido tachados de falso o desconocidos, según el caso. También se presumirán auténticos los memoriales presentados para que formen parte del expediente, incluidas las demandas, sus contestaciones, los que impliquen disposición del derecho en litigio y los poderes en caso de sustitución. Así mismo se presumen auténticos todos los documentos que reúnan los requisitos para ser título ejecutivo. La parte que aporte al proceso un documento, en original o en copia, reconoce con ello su autenticidad y no podrá impugnarlo, excepto cuando al presentarlo alegue su falsedad. Los documentos en forma de mensaje de datos se presumen auténticos. Lo dispuesto en este artículo se aplica en todos los procesos y en todas las jurisdicciones.


En aras de concluir, es fundamental señalar que el documento electrónico firmado digitalmente

se presume auténtico, así las cosas, se puede inferir que quien emitió el documento tenía la

intención de acreditarlo y de ser vinculado a su contenido25. Esto es fundamental pues le

confiere un mayor grado de seguridad a los documentos y brinda confianza a terceros.

b) Validez

El concepto de validez tiene varias acepciones: un concepto normativo y otro descriptivo. El

primero, debe asociarse con la validez de la normas y su fuerza vinculante, el segundo, se

asocia con la pertinencia de un sistema jurídico o su aplicabilidad26.

En el caso concreto, la validez jurídica será predicada por cualquier “método adecuado” 27 que

permita establecer el autor del documento electrónico o iniciador de los mensajes de datos. Es

decir, toda forma apropiada para identificar al iniciador de un mensaje de datos es una firma

electrónica y, por ende, equivalente a la firma manuscrita, como sucede también con las firmas

digitales28.

Es falso aseverar que la validez de una firma digital depende de la intervención de una entidad

de certificación conforme a lo que establece el artículo 7 de la ley 527 de 1999. El artículo 28 de

la ley 527 de 1999 exige que la firma digital sea “susceptible de ser verificada”, pero en ninguna

parte ordena que para que tenga validez deba ser certificada por una entidad de certificación

(EC), pues ésta se puede realizar con la clave pública sin que sea necesaria la intervención de

una EC29.

Ahora bien, la Corte Constitucional ha señalado que las entidades de certificación30 prestan un

servicio público que busca proporcionar seguridad jurídica a las transacciones comerciales por

vía informática, actuando la entidad de certificación como tercero de absoluta confianza, para lo

cual la ley le atribuye importantes prerrogativas de certificación técnica. La certificación técnica

busca dar certeza a las partes que utilizan medios tecnológicos para el intercambio de

información, en cuanto a la identidad y origen de los mensajes intercambiados. No busca dar

mayor jerarquía ni validez a los mensajes de datos de los que pretende un documento

25

Superintendencia de Industria y Comercio. Concepto 11065828, junio 23 de 2011. 26

Pérez-Sauquillo Munoz,C. Papeles de Teoría y Filosofía del Derecho. Instituto de Derechos Humanos Bartolomé de las Casas. Universidad Carlos III de Madrid. 27

Decreto 2364 de 2012, artículo 3 y 5. 28

EL PAPEL DE LAS ENTIDADES DE CERTIFICACIÓN Y LA SEGURIDAD DE LA INFORMACIÓN Y LOS DERECHOS PERSONALES EN EL COMERCIO ELECTRÓNICO. Dr. MARCOS QUIROZ GUTIÉRREZ. Cfr. Colombia, Congreso de la República, Ley 527 de 18 de agosto de 1999, artículo 7. Cfr. también Peña Valenzuela, Daniel. “El Contrato Electrónico y los Medios Probatorios”. El Contrato por Medios Electrónicos. Primera Edición. Bogotá. Universidad Externado de Colombia. 2003, pp. 194-198. 29

Remolina, N. ¿PENSAR EN LAS NECESIDADES DEL PAÍS O MANTENER A ULTRANZA UN STATU QUO PARA LA FIRMA DIGITAL DE LAS EN TIDADES DE CERTIFICACIÓN ABIERTA -ECA-?. Revista de Derecho Comunicaciones y Nuevas Tecnologías. Marzo 2010. 30

Ley 527 de 1999


tradicional31. A su vez, aseguran la autenticidad32, integridad33 y no repudio34 de los mensajes

de datos.

A modo de conclusión, es pertinente establecer que las entidades de certificación buscan dar

certeza en cuanto a los medios tecnológicos empleados para el intercambio de información, es

decir, en relación a quien inicia el mensaje de datos, mas no busca dar mayor jerarquía ni

validez a los mensajes de datos, ya que como consagra el artículo 7 de la ley 527 de 1999 de

cumplirse los requisitos de confiabilidad señalados en la norma se predicará que la firma digital

es válida35, es decir, acorde a derecho.

c) Certificaciones: actividades propias de las entidades de certificación36

Se entiende por certificados digitales: El “mensaje de datos firmado por la entidad de

certificación que identifica, tanto a la entidad de certificación que lo expide, como al suscriptor y

contiene la clave pública de éste”37.

La ley 527 de 1999 señala que las entidades prestadoras de servicios de certificación buscan

garantizar la confidencialidad 38 , integridad 39 , identificación 40 y no rechazo de las firmas 41 .

31

Corte Constitucional. Sentencia C-662/00. MP. Fabio Morón Díaz. 32

Rincón Cárdenas, Erick. Aproximación jurídica a la firma digital. “En el mismo contexto de la firma manuscrita, se presume que la firma digital pertenece exclusivamente a la persona que consta como titular de un certificado digital. 33

Castro Cifuentes, Marcela. Fundamentos de derecho de los negocios para no abogados. Capítulo de Comercio Electrónico, Remolina Nelson. “Garantizar que los documentos electrónicos no son alterados, modificados, falsificados o manipulados”. 34

Castro Cifuentes, Marcela. Fundamentos de derecho de los negocios para no abogados. Capítulo de Comercio Electrónico, Remolina Nelson. “Tener la certeza jurídica de que los mensajes de datos son una forma válida de manifestar la voluntad un medio de prueba”. 35

Remolina, N. GECTI. Primera Reglamentación de la Firma Electrónica. Universidad de los Andes.Diciembre 12 de 2012. “La seguridad no la otorga la ley por obra de magia. Esta dependerá, como mínimo, de dos cosas: (i) El producto o tecnología que se utilice como firma –grado de seguridad tecnológica intrínseca- y (ii) la diligencia, custodia y cuidado que tenga el usuario de los datos de creación de la firma electrónica. El firmante debe cumplir las obligaciones señaladas en el artículo 6 del decreto pues no puede olvidarse que en ciertas ocasiones las fallas de seguridad obedecen a factores humanos.” 36

Ley 527 de 1999. Artículo 2, literal d). “Aquella persona que, autorizada conforme a la presente Ley, está facultada para emitir certificados en relación con las firmas digitales de las personas, ofrecer o facilitar los servicios de registro y estampado cronológico de la transmisión y recepción de los mensajes de datos, así como cumplir con otras funciones relativas a las comunicaciones basadas en firmas digitales.” 37

Decreto reglamentario 1747 de 2000. 38

Gutiérrez Gómez, M.C. Consideraciones sobre el tratamiento jurídico del comercio electrónico. GECTI. (Grupo de Estudios en “Internet, Comercio Electrónico & Telecomunicaciones e Informática”). Universidad de los Andes. Legis. Bogotá, 2005. Pg. 18. “Con la confidencialidad se garantiza que los mensajes de datos lleguen exclusivamente a las personas autorizadas para ello.” 39

Gutiérrez Gómez, M.C. Consideraciones sobre el tratamiento jurídico del comercio electrónico. GECTI. (Grupo de Estudios en “Internet, Comercio Electrónico & Telecomunicaciones e Informática”). Universidad de los Andes. Legis. Bogotá, 2005. Pg. 18. “Con la integridad que el mensaje de datos no sea interceptado y modificado durante el envío” 40

Gutiérrez Gómez, M.C. Consideraciones sobre el tratamiento jurídico del comercio electrónico. GECTI. (Grupo de Estudios en “Internet, Comercio Electrónico & Telecomunicaciones e Informática”). Universidad de los Andes. Legis. Bogotá, 2005. Pg. 18. “(...) con la autenticación y mediante el uso de la firma digital que se reconozca el titular de la firma y el mensaje”. 41

Gutiérrez Gómez, M.C. Consideraciones sobre el tratamiento jurídico del comercio electrónico. GECTI. (Grupo de Estudios en “Internet, Comercio Electrónico & Telecomunicaciones e Informática”). Universidad de los Andes. Legis. Bogotá, 2005. Pg. 18. “(...) y con el no rechazo y a través del uso de los servicios de certificación digital, se podrá


Además ha señalado la jurisprudencia mediante sentencia de constitucionalidad C-662/00, que

“se prevé la existencia de entidades de certificación como aquellas personas que autorizadas

conforme a la ley, están facultadas para emitir certificados en relación a las firmas digitales”42.

Algunos autores, como Hermann Zubieta Uribe han puesto de presente la importancia de lo que

se denomina, “Entidad de Certificación Raíz”, que en el contexto colombiano se denominaría

ONAC, ésta es la encargada de dar el aval de certificación a quienes deseen aumentar el nivel

de seguridad mediante la emisión de certificaciones. Para ello, las firmas deberán permitir “a) el

acceso al certificado para verificar la firma digital y b) al certificado de la entidad de certificación

para verificar que la entidad de certificación es avalada por la entidad raíz”43. Por lo tanto, debe

entenderse que a la certificación de la certificación se le conoce como la cadena de confianza, y

si ésta cadena se rompe, no se podrá confiar en las firmas que se están avalando.

Debe tomarse en cuenta que la intervención de la ONAC en el proceso de verificación busca

proveer mayor seguridad técnica y jurídica, mas el uso de este servicio no es un requisito

impuesto por la ley. Así las cosas, los “certificados digitales” expedidos por entidades de

certificación cerrada tendrán la finalidad de elevar los niveles de seguridad y por ende de

confianza. Si la Contraloría General de la República desea emitir certificados digitales será

necesario que exista autorización previa del Organismo de Acreditación de Colombia (ONAC).

Ahora bien, esto no impide que la CGR emita “certificados asimilables”, desde sus aspectos

técnicos, a los “certificados digitales” dispuestos en la ley. Se entienden “certificados

asimilables”, porque al carecer del aval del ONAC, tendrán un “nivel de confianza” inferior. Esta

situación, en términos prácticos, no tiene mayor trascendencia, pero, en el evento de un litigio

sobre la validez de la firma, resultará relevante. Esto debido a que la firma digital, sin

certificación pero verificable, se respalda en los procesos, mientras que la firma digital

certificada, se respalda, como primera medida, en la certificación emitida por el ONAC.

d) Valor probatorio de las entidades de certificación abiertas vs. entidades de

certificación cerradas

En Colombia, en materia probatoria opera el principio de libertad de la prueba, según el cual

sirve como prueba cualquier medio útil que pueda llevar al juez al convencimiento44 conforme al

método de la sana crítica.

Ahora bien, en términos de firmas digitales el parágrafo del artículo 28 de la ley 527 de 1999

establece: “El uso de una firma digital tendrá la misma fuerza y efectos que el uso de una firma

tener claridad de que el destinatario de un mensaje no desconocerá su recepción y que el autor no negará su autoría.” 42

Gutiérrez Gómez, M.C. Comercio Electrónico. Consideraciones sobre el tratamiento jurídico del comercio electrónico. GECTI. (Grupo de Estudios en “Internet, Comercio Electrónico & Telecomunicaciones e Informática”). Universidad de los Andes. Legis. Bogotá, 2005. Pg. 19. 43

Zubieta Uribe, H. Comercio Electrónico. Los mensajes de datos y las entidades de certificación. GECTI (Grupo de Estudios en “Internet, Comercio Electrónico & Telecomunicaciones e Informática”). Universidad de los Andes. Legis. Bogotá, 2005. 44

Código de Procedimiento Civil, artículo 175.


manuscrita, si aquella incorpora los siguientes atributos: 1. Es única a la persona que la usa; 2.

Es susceptible de ser verificada; 3. Está bajo el control exclusivo de la persona que la usa; 4.

Está ligada a la información o mensaje, de tal manera que si éstos son cambiados, la firma

digital es invalidada; 5. Está conforme a las reglamentaciones adoptadas por el Gobierno

Nacional”.

Posteriormente, el artículo 15 del decreto 1747 de 2000 consagra lo siguiente: “Cuando quiera

que un suscriptor firme digitalmente un mensaje de datos con su clave privada, y la respalde

mediante un certificado digital, se darán por satisfechos los atributos exigidos para una firma

digital en el parágrafo del artículo 28 de la Ley 527 de 1999, si: 1. El certificado fue emitido

por una entidad de certificación abierta autorizada para ello por la Superintendencia de

Industria y Comercio (Ahora el ONAC); 2. Dicha firma se puede verificar con la clave pública

que se encuentra en el certificado con relación a firmas digitales, emitido por la entidad de

certificación; 3. La firma fue emitida dentro del tiempo de validez del certificado, sin que éste

haya sido revocado; 4. El mensaje de datos firmado se encuentra dentro de los usos aceptados

en la DPC, de acuerdo al tipo de certificado”.

A partir de la normatividad anterior se puede observar que el artículo 15 del decreto 1747 de

2000 reglamenta el artículo 28 de la ley 527 de 1999. Así las cosas, el artículo 15 del decreto

1747 de 2000 otorga presunción probatoria sólo a quienes pertenecen a una entidad de

certificación abierta, pues claramente éste artículo lo señala entre sus requisitos para equiparar

las firmas digitales a las manuscritas. Por lo tanto, el efecto jurídico inmediato es que la carga

de la prueba estará en cabeza de la entidad avalada como entidad de certificación cerrada. Por

ello, es necesario que los procesos y protocolos por parte de la entidad de certificación cerrada

sean muy fuertes, para evitar que se desvirtúe la firma, en caso de disputa.

e) Requisitos de acreditación para certificación como entidad cerrada ante el ONAC45

El artículo 3 del decreto 4738 de 2008 designa al ONAC como entidad competente para realizar

los procesos de acreditación conforme a los lineamientos que establece la Organización

Internacional de Normalización -ISO- y la Comisión Electrónica internacional -IEC-,

específicamente a partir de la norma ISO/IEC 17011y las distintas actividades de evaluación46.

45

Actualmente la ONAC está esperando a que se reglamente el decreto 19 de 2012, por lo tanto se podrán presentar otros requisitos adicionales. 46

La Acreditación en Colombia. ONAC. Ministerio de Comercio, Industria y Turismo. Organismos de

certificación de personas, con los requisitos de la norma NTC—ISO/IEC 17024. Organismos de certificación de producto, con los requisitos de ISO/IEC Guide 65 (GTC 38) – GTC— ISO/IEC 67. Organismos de certificación de sistema de gestión, con los requisitos de la norma NTC—ISO/IEC 17021. Organismos de inspección, con los requisitos de la norma NTC—ISO/IEC 17020. Laboratorios de calibración, con los requisitos de la norma NTC—ISO/IEC 17025. Laboratorios de ensayo o prueba, con los requisitos de la norma NTC—ISO/IEC 17025. Laboratorios médicos o clínicos, con los requisitos de la norma NTC ISO 15189.


Además en el ámbito nacional se ha legislado sobre el tema y a la fecha existe un marco legal

que define y reglamenta el acceso y uso de los mensajes de datos, del comercio electrónico y

de las firmas digitales47, así como también establece las entidades de certificación48.

En primer lugar, el artículo 29 de la ley 527 de agosto de 1999 modificado por el artículo 160 de

2012 establece que podrán ser entidades de certificación, las personas jurídicas, tanto públicas

como privadas, de origen nacional o extranjero y las cámaras de comercio que cumplan con la

reglamentación emitida por el Gobierno Nacional.

Así las cosas, la Contraloría General de la República debe demostrar que cuenta con: (i). La

capacidad económica y financiera suficiente para prestar los servicios autorizados como entidad

de certificación; (ii). La capacidad y elementos técnicos necesarios para Ia generación de firmas

digitales, Ia emisión de certificados sobre Ia autenticidad de las mismas y Ia conservación de

mensajes de datos en los términos establecidos en esta ley; (iii). Los representantes legales y

administradores no podrán ser personas que hayan sido condenadas a pena privativa de Ia

libertad, excepto por delitos políticos o culposos; o que hayan sido suspendidas en el ejercicio

de su profesión por falta grave contra Ia ética o hayan sido excluidas de aquélla. Esta

inhabilidad estará vigente por el mismo período que Ia ley penal o administrativa señale para el

efecto49.

Por otro lado, las entidades de certificación tendrán que: (i). Emitir certificados conforme a lo

solicitado o acordado con el suscriptor; (ii). Implementar los sistemas de seguridad para

garantizar la emisión y creación de firmas digitales, la conservación y archivo de certificados y

documentos en soporte de mensaje de datos; (iii). Garantizar la protección, confidencialidad y

debido uso de la información suministrada por el suscriptor; (iv). Garantizar la prestación

permanente del servicio de entidad de certificación; (v). Atender oportunamente las solicitudes y

reclamaciones hechas por los suscriptores; (vi). Efectuar los avisos y publicaciones conforme a

lo dispuesto en la ley; (vii). Suministrar la información que le requieran las entidades

administrativas competentes o judiciales en relación con las firmas digitales y certificados

emitidos y en general sobre cualquier mensaje de datos que se encuentre bajo su custodia y

administración; (viii). Permitir y facilitar Ia realización de las auditorías por parte del Organismo

Nacional de Acreditación de Colombia. Es responsabilidad de Ia entidad de certificación pagar

los costos de Ia acreditación y los de las auditorias de vigilancia, conforme con las tarifas del

Organismo Nacional de Acreditación de Colombia50.

47

Ley 527 de 1999. Artículo 2, numeral c. Firma digital. Se entenderá como un valor numérico que se adhiere a un

mensaje de datos y que, utilizando un procedimiento matemático conocido, vinculado a la clave del iniciador y al texto del mensaje permite determinar que este valor se ha obtenido exclusivamente con la clave del iniciador y que el mensaje inicial no ha sido modificado después de efectuada la transformación; 48

Ley 527 de 1999. Artículo 2, numeral d. Entidad de Certificación. Es aquella persona que, autorizada conforme

a la presente ley, está facultada para emitir certificados en relación con las firmas digitales de las personas, ofrecer o facilitar los servicios de registro y estampado cronológico de la transmisión y recepción de mensajes de datos, así como cumplir otras funciones relativas a las comunicaciones basadas en las firmas digitales; 49

Ley 527 de 1999. Artículo 29. CARACTERÍSTICAS Y REQUERIMIENTOS DE LAS ENTIDADES DE

CERTIFICACIÓN. Posteriormente modificada por el decreto 19 de 2012, artículo 160. 50

Ley 527 de 1999. Artículo 32. DEBERES DE LAS ENTIDADES DE CERTIFICACION modificado por artículo 162 del decreto 19 de 2012.


En principio, estos son los requisitos que establece el marco legal colombiano para convertirse

en una entidad de certificación cerrada, sin embargo, el ONAC, a la fecha no está ofreciendo el

servicio de acreditación puesto que el organismo está a la espera de la reglamentación del

Decreto 19 de 2012 que establecerá las reglas específicas de acreditación. Bajo esta premisa,

la Contraloría General de la República a la fecha no puede ser acreditada como una entidad de

certificación cerrada, consecuencia de la laguna jurídica existente.

Sin embargo y a pesar de que a la fecha no es posible acreditar a la Contraloría General de la

República como una entidad de certificación cerrada, el proceso de certificación se adelantará

bajo los lineamientos de la norma ISO/IEC 1701151 y el proceso que realizará el ONAC será el

siguiente: “(i) Solicitud/ Cotización (Evaluación de viabilidad y tiempo requerido); (ii) Cuenta de

cobro/Pago/Contrato; (iii) Programación (designación/ impugnación del grupo evaluador); (iv)

Evaluación documental; (v) Plan de evaluación; (vi) Evaluación In Situ52; (vii) Informe a la

comisión de acreditación; y (viii) Decisión/Recurso53”.

Conclusiones

(i) La firma electrónica representa un medio de identificación. Se entiende que la firma

electrónica corresponde al género, mientras que la firma digital constituye una de las especies

de la misma. Así mismo, se entiende que la firmas digitales pueden ser de tres tipos: sin

certificar pero verificables, avaladas por entidades de certificación abierta y avaladas por

entidades de certificación cerrada.

(ii) La normatividad establece que hay dos formas para lograr la autenticidad del

documento electrónico. La primera, consiste en suscribirse a una entidad de certificación y

firmarlo digitalmente; la otra será utilizar un “método adecuado” por medio del que se pueda

identificar a quien ha enviado un mensaje de datos.

(iii) La validez se predica en cuanto a la confiabilidad de los procesos. Los procesos

empleados deben permitir la verificación del emisor del mensaje del mensaje de datos. Es falso

aseverar que la validez en relación a las firmas electrónicas es otorgada por las entidades de

certificación, ya que las firmas son válidas si cumplen los requisitos de ley.

(iv). Para realizar la emisión de certificados digitales, es necesario estar avalada por el

ONAC como entidad de certificación. Conforme a lo consagrado por la ley, el propósito que

51

(i). Organismos de certificación de personas, con los requisitos de la norma NTC—ISO/IEC 17024; (ii). Organismos de certificación de producto, con los requisitos de ISO/IEC Guide 65 (GTC 38) – GTC— ISO/IEC 67; (iii). Organismos de certificación de sistema de gestión, con los requisitos de la norma NTC—ISO/IEC 17021. (iv). Organismos de inspección, con los requisitos de la norma NTC—ISO/IEC 17020; (v) Laboratorios de calibración, con los requisitos de la norma NTC—ISO/IEC 17025; (vi). Laboratorios de ensayo o prueba, con los requisitos de la norma NTC—ISO/IEC 17025; (vii). Laboratorios médicos o clínicos, con los requisitos de la norma NTC ISO 15189. 52

Aspectos evaluados: (a). Organización: existencia legal e imparcialidad, (b). Competencia técnica: Recurso humano; Recursos materiales (instalación/equipamentos); Recursos documentales (métodos y procedimientos); Trazabilidad; Atestación, (c). Sistema de gestión: Manual de calidad, procedimiento y documentos. 53

Informe de Gestión 2011. Organismo Nacional de Acreditación de Colombia.


tiene dicha emisión es conservar la cadena de confianza, pues se verifica “la certificación de la

certificación”.

(v) Las entidades de certificación abiertas son las únicas que gozan de la presunción

probatoria. A partir de la ley 527 de 1999 y el Decreto 1747 de 2000, quien sea una entidad de

certificación cerrada deberá asumir la carga de la prueba en caso de disputa y por lo tanto

deben existir procesos solidos y protocolos de buena praxis para evitar futuros inconvenientes.

(vii) A la fecha no es posible ser avalado como entidad de certificación ONAC. El

Organismo Nacional de Colombia (ONAC) está a la espera de la expedición de un decreto que

reglamente el Decreto 19 de 2012 para que se reglamenten las reglas de acreditación.

(viii) Es de carácter imperante que los procesos de la CGR sean sólidos. Tomando en

cuenta que a la fecha la entidad está empleando la firma digital, sin certificar pero verificable, si

se llegase a presentar una disputa, la entidad deberá demostrar cómo respaldó los procesos

empleados en las operaciones desarrolladas.

(ix) La CGR puede utilizar la plataforma SAE para firmar digitalmente sus documentos

con plena validez y efectos jurídicos. Sin embargo, al constituirse como una entidad de

certificación cerrada, como muchas otras en el país (Ej. DIAN, Banco República, etc.), deberá

asumir la carga de la prueba en el caso de una controversia relacionada con la validez de la

firma o sus procesos. De ahí la importancia de que estén bien definidos e implementados.


ANEXO. MODELO RELACIONAL BASE DE DATOS SAE54

54

Se entrega una copia en tamaño pliego

documento de recomendaciones de sostenibilidad del sistema de aseguramiento electrÓnico – sae

Government & Nonprofit