2006_149info.pdf

INFORME DE AUDITORIA
Al Sr. Secretario de Hacienda del
Ministerio de Economía
En uso de las facultades conferidas por el artículo 118 de la Ley Nº 24.156, la AUDITORÍA
GENERAL DE LA NACIÓN (AGN) procedió a efectuar un examen en el ámbito de la
SECRETARÍA DE HACIENDA, con el objeto que se detalla en el apartado 1.
1. OBJETO DE LA AUDITORÍA
Evaluación general de los controles de la versión local del Sidif: Sistema Local Unificado (SLU).
2. ALCANCE DEL EXAMEN
El examen fue realizado de conformidad con normas de auditoría externa de la AUDITORÍA
GENERAL DE LA NACIÓN, aprobadas por la Resolución Nº 145/93, dictadas en virtud de las
facultades conferidas por el artículo 119, inciso d) de la Ley Nº 24.156.
La evaluación comprendió el análisis, en el período 2001-2004, de los controles informáticos del
Sistema Local Unificado durante la gestión del ciclo de vida, es decir, el planeamiento, diseño,
desarrollo e implementación hasta su actual etapa de “réplica” en los organismos de la
Administración Pública.
Para la evaluación se tomaron como referencia los estándares internacionales de auditoría, en
particular los vinculados con la tecnología de la información (TI) que disponen de amplio
consenso como COBIT (Control Objectives for Information and Related Tecnology), la norma
de seguridad ISO 17799/2000 homologada por IRAM Argentina, las guías y manuales
producidos por la UNAM-CERT de la Universidad Autónoma de México, las recomendaciones
del SANS Institute, CEPREVEN –Manual para la protección contra incendios de los
Página 1
ordenadores y centros informáticos, NFPA 75 –Protección de equipos de computación
electrónicos / Equipos procesadores de datos–, NFPA 72 –Código Nacional de alarmas contra
incendios– y Protección de archivos informáticos de la Fundación MAPFRE.
El análisis no incluyó los controles internos en cada módulo del sistema.
Las tareas de campo se realizaron en el ámbito del Ministerio de Economía, donde reside la
Unidad Informática, en el período comprendido entre el 12 de mayo de 2005 y el 17 de octubre
de 2005.
2.1 Relevamiento
Nuestro enlace para obtener de entrevistas y evidencias fue el responsable de Seguridad de la UI.
Se obtiene la documentación de los sistemas y procesos en gestión de la UI accediendo a su
biblioteca digital. Esta auditoría dispuso de permiso “solo lectura” de la documentación atinente
al sistema auditado.
Cuando esta AGN solicitó información, se le entregaron notas de la Unidad Informática,
Contaduría General de la Nación, Dirección de Auditoría de Sistemas (DAS), Centro de
Capacitación y Estudios, Área Proyecto “Informática del MECON” y la Dirección Técnica
Operativa del Ministerio de Economía.
Como medio de comunicación se utilizó el correo electrónico. Para ello se le asignaron a esta
auditoría cuentas de correo del Ministerio de Economía.
2.2 Entrevistas realizadas
Responsables y/o personal de la Unidad Informática de
•
Subcoordinación General
•
Mesa de Atención a Usuarios
•
Tecnología
•
Ingeniería
•
Desarrollo de los módulos SLU
Página 2
Otras áreas del Ministerio de Economía
•
Dirección de Auditoría de Sistemas de la Contaduría General de la Nación
•
Tesorería General de la Nación (TGN)
•
Dirección de Cuentas Bancarias – TGN
•
Dirección del Centro de Estudios y Capacitación – Subsecretaría de Presupuesto
•
Área de monitoreo cámaras de TV de la Dirección Técnica Operativa del Ministerio de
Economía.
•
Áreas contables e informáticos de organismos que adoptaron SLU seleccionados en esta
auditoría para evaluar la calidad de servicio.
2.4 Evidencias
Se obtuvieron a partir de entrevistas y procedimientos realizados al evaluar el control interno. Se
recolectaron evidencias en formato digital, físico y documental.
Las pruebas físicas se obtuvieron de la inspección personal, corroborada, en algunos casos, con
material fotográfíco.
La información adicional requerida se obtuvo mediante notas cursadas y correos electrónicos
oficiales con funcionarios de la UI y del Ministerio de Economía.
3. ACLARACIONES PREVIAS
3.1 Antecedentes del sistema SIDIF
En el marco de la Reforma Administrativa y Financiera del Sector Público (Ley Nº 24.156, del
29 de octubre de 1992) y con el financiamiento del Banco Mundial (préstamo 3362-AR) y el
Banco Interamericano de Desarrollo (préstamo 826/OC-AR), se diseña, desarrolla e implementa
Página 3
a partir de 1993 un sistema a medida denominado SIDIF (Sistema Integrado de Información
Financiera) con el objeto de gestionar la formulación del presupuesto nacional y sus
modificaciones, la programación de la ejecución presupuestaria, la ejecución presupuestaria de
gastos y recursos y la contabilidad general a nivel de transaccional, movimientos de fondos,
ordenes de pago y deuda exigible, conciliación bancaria, transferencia electrónica de pagos,
embargos y cesiones, entre otros.
El Sidif es operado por la Tesorería General de la Nación, Contaduría General de la Nación y la
Oficina Nacional de Presupuesto, oficinas dependientes de la Subsecretaría de Presupuesto,
como órganos rectores y por una centena de Servicios Administrativo-Financieros (SAF).
La Ley Nº 24.156 asigna competencia a la Contaduría General de la Nación para “Administrar
un sistema de información financiera que permanentemente permita conocer la gestión
presupuestaria, de caja y patrimonial, así como los resultados operativo, económico y financiero
de la administración central, de cada entidad descentralizada y del sector publico nacional en
su conjunto”.
Actualmente, la Unidad Informática dependiente de la Subsecretaría de Presupuesto tiene bajo su
responsabilidad la gestión de este sistema en el mantenimiento, desarrollo y operación.
Más específicamente, las funciones de la UI son las siguientes a) formular la estrategia
informática y los planes informáticos a corto y mediano plazo de la Secretaría de Hacienda, b)
dar el soporte informático a las autoridades, a los responsables del sistema de los distintos
sectores y usuarios finales, c) intervenir en el diseño, desarrollo e implementación de las
aplicaciones de administración financiera y sistemas vinculados, d) definir las metodologías
informáticas y normas de ingeniería de sistemas y documentación, e) seleccionar la plataforma
informática y el ambiente de desarrollo y ejecución de los sistemas, f) ejecutar las acciones
destinadas a asegurar el correcto funcionamiento del equipamiento informático central y su
vinculación con los de las unidades del Sector Publico Nacional que participan en el Sistema de
Administración Financiera, g) intervenir en los distintos aspectos relacionados con la plataforma
de comunicaciones que vincula a los sistemas centrales con los Servicios Administrativo-
Página 4
Financieros del Sector Publico Nacional, h) intervenir en la definición y control de las tareas
desarrolladas por proveedores externos de sistemas informáticos y servicios relacionados
3.2 El Sistema Local Unificado (SLU)
Los Servicios Administrativo-Financieros (SAF) de las distintas jurisdicciones de la
Administración Central para su gestión presupuestaria y contable han contado, en su gran
mayoría, con sistemas locales provistos desde la UI como CONPRE (Consolidación
Presupuestaria), Sidif OD –organismos descentralizados–, SIGRAC –específico para la AC
administración central o Sidif AC–. No obstante, algunos organismos adoptaron otros sistemas o
desarrollos propios. Funcionalmente, los sistemas mencionados son distintos e independientes,
pero cada uno de ellos permite realizar transacciones en conexión con el Sidif Central utilizando
para ello un sistema de transferencia de datos denominado TRANSAF.
A partir de 2001 se inicia la implementación del sistema SLU, el cual tiende a reemplazar a los
anteriores con un esquema centralizado donde las bases de datos del organismo ya no se alojan
en él sino en la Secretaría de Hacienda (servicio de hosting).
La historia inicial del proyecto SLU no pudo ser reconstruido pues no se obtuvo autorización
para acceder –en los plazos con que contaba esta auditoría– a la información técnica del SLU
relativa al préstamo BID 826 existente en el Archivo General de la Administración Nacional y
dependiente de la CGN.
De la información proporcionada por la UI se infiere que en 1997 se concibe la idea de generar
un único Sidif Local con los siguientes requisitos:
1. Brindar la funcionalidad de las versiones Sidif OD y Sidif AC,
2. interfase de usuario en ambiente gráfico y, opcionalmente,
3. rediseñar la arquitectura de manera que permita:
• Lograr la independencia del proveedor de la herramienta de desarrollo
• Costos de mantenimiento más reducidos
Se agregan nuevas características:
Página 5
La versión Sidif OD será la base del nuevo producto.
El objetivo del sistema es que sirva de soporte a:
•
La gestión de las unidades ejecutoras
•
La función de apoyo que deben ejercer los SAF a los Organismos de la Administración
Nacional.
Otro objetivo enunciado es permitir el registro de las transacciones desde su origen, produciendo
en forma simultánea los efectos presupuestarios, patrimoniales y económicos.
La información registrada debe servir para medir el desempeño de la administración y como base
para la toma de decisiones y el control interno y externo.
EL Plan de Desarrollo de Software del SLU establece un cronograma con inicio en noviembre de
1998 y finalización en octubre de 1999. El Plan estima los costos de los especialistas por
módulo, esto es, Tablas Básicas, Presupuesto, Compras, Contabilidad, Tesorería y
Administración de Bienes.
En julio de 2001 comienza la implementación de SLU en el Comité Federal de Radiodifusión
–SAF 102– y a partir de 2002 se inicia el proceso de réplicas en los restantes servicios de la
Administración Central.
El siguiente cuadro muestra la situación actual de los distintos productos empleados por los
organismos nacionales:
SLU
PROPIO
CONPRE
SDFOD
SIGRAC
SLU INSTALADOS A MAYO 2005
100 SAF
43 AC
57 OD
33 CUT
10 NO CUT
50 CUT 7 NO CUT
22
3
31
7
2
3
1
3
5
8
4
8
2
56
13
20
10
0
CUT: Cuenta Única del Tesoro.
Página 6
El proceso de réplica
La implementación del SLU en los organismos se conoce como “proceso de réplica”. Las etapas
previstas son:
•
Presentación a Autoridades
•
Planificación
•
Relevamiento Técnico y Funcional
•
Capacitación
•
Diagnóstico
•
Preimplementación
•
Puesta en Marcha
•
Soporte Técnico y Funcional
•
Cierre de la Réplica
El sistema, en la etapa de Relevamiento, se encontraba en la versión Nº 11 y abarcaba los
módulos de Compras, Presupuesto, Tesorería y Contabilidad, para lo cual contaba con un perfil
de administrador de la aplicación en el SAF.
3.3 Organización del SLU
La Secretaria e Hacienda cuenta con una organización –informal– para la implementación y
mantenimiento de SLU que incluye al secretario del presupuesto, secretario ejecutivo, una
coordinación de capacitación, un comité de dirección con coordinación y equipos de réplicas
contado con equipos multidisciplinarios de los órganos rectores la TGN, CGN, ONP y ONC y la
UI (soporte informático, desarrollo, área técnica, testing y mesa de ayuda).
El siguiente gráfico ilustra el esquema adoptado.
Página 7
PROYECTO SLU
Subsecretario
de Presupuesto
Secretario
Ejecutivo
Coordinación
Capacitación
Comité de Dirección:
Organos Rectores (OR)
Unidad Informática (UI)
Soporte
Administrativo
Coordinación
de Réplicas:
Funcional (TGN)
Informática (UI)
Equipo
Multidisciplinario
Organos Rectores:
TGN
CGN
ONP
ONC
Soporte Informático
Unidad Informática:
Desarrollo (35)
Area Técnica (20)
Testing (12)
Mesa de Ayuda (4)
Equipos
de Réplicas:
Líderes (10)
Equipo UI (14)
Equipo CGN (8)
Comité
de Usuarios
El propósito del Comité de Usuarios es
•
Proporcionar un foro estable de intercambio de información, definición y propuestas
de características generales sobre el Sistema de Administración Financiera.
•
Resolver el análisis y la priorización de nuevas soluciones, para satisfacer las
necesidades emergentes en los organismos colaborando con los Órganos Rectores y la
Unidad Informática.
Los integrantes del Comité de Usuarios serán funcionarios de los Organismos, que actuarán en
su representación con capacidad de decisión para reflejar las necesidades y acordar soluciones.
Un representante de cada Órgano Rector asistirá a la Dirección del Comité en la coordinación de
las actividades.
Los encuentros del Comité se convocan desde la Unidad Informática.
Página 8
La Unidad Informática participa a través de la Coordinación de las Réplicas y en el Soporte
Técnico e integra el Comité de Dirección de Sidif.
La estructura de la UI mostrada en su sitio Web cuenta con un organigrama funcional –informal–
que se muestra seguidamente:
Otras dependencias funcionales del Mecon intervienen en tareas relacionadas con el
funcionamiento de SLU, como ser: a) DAS (Dirección de Auditoría de Sistemas), dependiente de
Página 9
la CGN (Contaduría General de la Nación) encargada de evaluar el sistema administrativo
contable de las instituciones que integran la ADMINISTRACIÓN NACIONAL;
b) Dirección
Técnica Operativa, encargada del mantenimiento predictivo, preventivo y correctivo de las
instalaciones (electricidad, aire acondicionado y control de accesos a los CPD); c) El Proyecto
“Informática del Mecon” , encargado de la administración y soporte de la red informática del
Mecon, por la que pasa el 100% del tráfico de información entre los SAF y la Secretaría de
Hacienda.
La UI dispone de un presupuesto –en pesos– cuya evolución 2001-2005 se muestra en el
siguiente cuadro:
Créditos Presupuestarios asignados a la Unidad Informática
Períodos
Actividad 06
2002
2003
Años
2001
2004
2005
Total
Créditos
5.139.589 3.841.070 5.375.757 5.005.919
8.597.631
Crédito Presupuestario asignado a la Subsecretaría de Presupuesto: SIDIF Internet
Actividad 07
Año
2005
Total
Crédito
4.638.473
El proyecto Sidif Internet (@-Sidif) cuenta con presupuesto a partir de 2005.
El @-Sidif integraría las funcionalidades del SLU y el actual Sidif Central e incorporaría una
ampliación de su alcance y aplicación, la actualización tecnológica hacia entornos Internet y la
gestión por resultados con la revalorización del presupuesto por programas.
3.4 Esquema relevado de procesamiento
En la figura 1 se muestra el esquema relevado
Página 10
DIAGRAMA DE PROCESAMIENTO SLU
Red MECON/
Hacienda
SAF
.
Red
Hacienda
Servidores de
Aplicación
SLU
Servidores de
Base de
Datos
(Figura 1)
Red
Hacienda
Red
Hacienda
Servidores
Transaf
Servidor
Central
Desde una PC que contiene un programa (software) cliente, el SAF se conecta, por medio de un
vínculo punto a punto o módem, al servidor de aplicación –el de menor carga operativa, pues
funciona con el esquema “ carga balanceada”– y ahí se ejecuta la aplicación SLU –única para
todos los organismos– que permite almacenar las transacciones en la base del organismo
radicada en otro servidor.
El tráfico de información entre cada SAF y Hacienda se realiza a través de la red del Mecon
administrada por otra área del Ministerio, el Proyecto “Informática del Mecon” .
Para actualizar la base del sistema Sidif Central se utiliza el sistema de comunicaciones Transaf
NG, compuesto por tres servidores. Este sistema toma los datos alojados en las bases de cada
organismo y lo almacena en la base Central en un proceso de transferencia batch automático,
actualizando cada tres minutos la base local de sistema del SLU a la base central del SIDIF.
3.5 Infraestructura Tecnológica
El SLU cuenta con un conjunto de servidores y equipos, motores de base de datos, sistemas
operativos gráficos y carácter, UPS,
red cableada con UTP (Unshielded Twisted Pair),
equipamientos de control de accesos (firewall), herramientas de desarrollo, herramienta de
control de programas fuentes, discos redundantes en dispositivo RAID.
Página 11
El documento normativo NUI N 9 “Requerimiento de conexión SLU” de la UI, indica que para
instalar y usar el SLU, el SAF debe contar con una PC que como mínimo tenga 64 Mb de
memoria RAM, CPU de 200 Mhz, 100 MByte de disco rígido y una placa de red Windows
98/2000 (XP no soportado) con conexión o enlace de tipo punto a punto con el Mecon o acceso
a Internet por banda ancha o “dial up”. El organismo deberá designar personal de soporte
informático para atender cualquier inconveniente en una primera instancia.
Cabe destacar que el SLU cuenta con equipamiento (servidores, UPS y racks), software
(Windows NT TSE Linux Red Hat Solaris) y capacitación adquiridos por el proyecto FOSIP
(BIRF 3958 PNUD 97/025) adjudicados durante 2004 con garantía de mantenimiento de
hardware y actualización de software, soporte telefónico 5x8 con cuatro horas de tiempo de
respuesta, por 36 meses.
El mantenimiento de los servidores se realiza a través de contratos con proveedores externos.
3.6 Seguridad Informática
Seguridad lógica
El área de Seguridad de la UI ha elaborado normativas de acceso lógico, de sistemas operativos;
una norma para elaborar el plan de contingencia, plan de contingencia, normas de resguardo y
recuperación (backups/recovery), de seguridad física y protección ambiental, concientización a
los usuarios.
Seguridad física
Comprende la protección y aseguramiento de los activos (entre otros, servidores y equipos
dispositivos) existentes en los CPD de Hacienda, Área Proyecto “Informática del Mecon” y de
Página 12
respaldo (CCR). A la Dirección Técnica Operativa del Mecon le compete la seguridad de la
infraestructura edilicia de los CPD, y también se encarga de gestionar la recarga de los
matafuegos y su control.
Los servidores y equipos de conectividad SLU se encuentran ubicados en el CPD Hacienda y en
AFIP (CCR).
‰
Servidores SLU – Centro de Procesamiento de Datos (CPD) (Edificio Mecon)
El CPD cuenta con salas donde se encuentran instalados los servidores afectados al SLU y una
pequeña oficina contigua. Dispone de sistemas de control de acceso y
protección contra
incendios.
En las salas hay equipos de aire acondicionado. En una de ellas se encuentran el tablero eléctrico
del CPD y un equipo que controla la humedad y la temperatura de esa sala.
‰
Servidores SLU - Sitio de procesamiento anexo - Edificio AFIP
Este CPD de respaldo ubicado en el Edificio AFIP cuenta con un conjunto de servidores
afectados al SLU.
Para ello, la Secretaría de Hacienda (SH) firmó un convenio de subcesión de uso Nº 4/96 con la
DGI (actualmente, AFIP), el cual establece que la SH tiene la responsabilidad de la instalación y
operación del equipamiento del Sidif, la seguridad en el interior del recinto y los bienes que se
almacenen, y de los hechos o actos que en razón de la ocupación produzcan perjuicio al o los
ocupantes de la superficie cedida y del recinto, o que afecte a la tarea del Sidif, sus dependientes
o terceros.
Página 13
La puerta de ingreso cuenta con un sistema de control de acceso. El lugar posee equipos de aire
acondicionado y un sistema de detección y extinción de incendios. En la sala de servidores se
encuentra el tablero eléctrico y el equipo que controla la humedad y la temperatura del ambiente.
‰
Equipos afectados a la red SLU – Área Proyecto “Informática del Mecon”
El Área tiene incumbencia en temas como la seguridad de la red, accesos a Internet, correo
electrónico y enlaces punto a punto de todos los servidores Web del Ministerio de Economía.
Dicha área está a cargo exclusivamente de la administración física (seguridad física, protección y
accesos) de los equipos SLU objeto de esta auditoría.
En el local donde se ubican los equipos hay un sistema de control de acceso y un sistema de
detección de incendios.
3.7 El resguardo de la información de los organismos / SAF
El procedimiento de backup es diario, se realiza mediante cintas y sobre todas las bases. Se
almacena información histórica –un año en línea–. Las cintas con la información se resguardan
en dos lugares externos y uno interno al edificio del CPD de Hacienda. El proceso de backup
completo tarda 4 horas 20 minutos e insume entre 5 y 6 Gigabytes por organismo.
3.8 Políticas, Normas y Procedimientos
Como parte esencial del control interno, se viene recomendando en sucesivos informes la
incorporación de normativas pertinentes, en forma escrita y aprobada por la máxima autoridad
para el gobierno.
Página 14
4. COMENTARIOS Y OBSERVACIONES
Ambiente de Control
4.1 Objetivo de Control: Participación Proactiva de Auditoría
La Unidad Informática deberá obtener un análisis independiente, buscando que una auditoría
evalúe cada solución de tecnología de información desarrollada, antes de su instalación.
4.1.1 Auditoría independiente
No se tuvo evidencia –o acceso– a auditorías informáticas al producto SLU en alguna de sus
fases de desarrollo, ni que se haya recurrido a la Dirección de Auditoría de Sistemas (DAS) u
otra evaluación independiente, antes de ser implementado. Una de las misiones de la DAS es
“evaluar
el
sistema
administrativo-contable
de
las
instituciones
que
integran
la
ADMINISTRACIÓN NACIONAL”.
Se tuvo conocimiento de que algunos integrantes de la Dirección de Auditoría de Sistemas han
formado parte del equipo de implementación (Réplicas) del SLU.
Efectos: No existe una adecuada evaluación de los controles internos del sistema. La
participación de sus auditores en tareas de implementación inhibe a la DAS para cumplir su
función con objetividad sobre este sistema, puesto que el área no debe ejecutar y auditar.
4.2 Objetivo de Control: Certificación o Acreditación Independiente de Seguridad.
La Unidad Informática deberá obtener una certificación o acreditación independiente de
seguridad antes de implementar nuevos servicios de tecnología de información que resulten
críticos. Una vez puestas en marcha, estas actividades deben monitorearse en forma permanente.
4.2.1 Certificación de Seguridad
No se obtuvo evidencia de que antes de implementar el SLU se hubiera logrado una certificación
independiente de seguridad.
Efectos. Al no establecerse este recaudo, se incrementa el nivel de exposición a riesgos durante
la etapa de producción del sistema.
Página 15
Ciclo de Vida del Sistema
4.3 Objetivo de Control: Marco de Referencia para la Administración de Proyectos
La Unidad Informática deberá establecer un marco de referencia general para la administración
de proyectos que defina el alcance y los límites del mismo, así como la metodología a ser
adoptada, incluyendo como mínimo la designación de autoridades y asignación de
responsabilidades de los miembros del equipo, determinación de tareas, realización de
presupuestos de tiempo y recursos, avances, puntos de revisión y análisis de factibilidad.
4.3.1 Administración del proyecto SLU
No se tuvo evidencia de la existencia de un marco para la administración de proyectos. En
relación al proyecto SLU, se detectó que:
a) La estructura del proyecto no cuenta con el respaldo de una disposición formal a pesar de que
resulta evidente que la organización funciona de hecho.
b) El Comité de Dirección no registra formalmente las actividades y decisiones de sus reuniones.
c) Los estudios técnicos de factibilidad del sistema a los que tuvo acceso esta auditoría no
brindan alternativas de solución a los problemas planteados ni análisis costo/beneficio.
d) Las reprogramaciones del proyecto no se explican ni se informan formalmente (documentos o
disposiciones) a los interesados. La fecha prevista de finalización del desarrollo del producto era
septiembre de 1999, pero su implementación empezó en junio de 2001. Originalmente previsto
para reemplazar al Sidif OD y con arquitectura descentralizada, el SLU pasó a un esquema de
procesamiento centralizado.
e) No se conocen los gastos que demanda efectivamente el proyecto.
g) En algunos organismos (SAF), no se tuvo evidencia de que el proceso de réplica se haya
iniciado con los acuerdos formales previos de rutina: Acta Acuerdo y/o Convenio de Servicios.
Efectos. La inexistencia de este marco obliga a improvisar constantemente y provoca una
deficiente y no transparente asignación de los recursos.
4.4 Objetivo de Control: Plan de Aseguramiento de la Calidad de Sistemas
Página 16
La Unidad Informática deberá asegurar que la implementación de un sistema nuevo o
modificado incluya la preparación de un plan de calidad que se integre posteriormente al plan
maestro del proyecto y que sea formalmente revisado y acordado por todas las partes interesadas.
4.4.1 Plan de Calidad del Sidif Local Unificado
La normativa para el Plan de Desarrollo (template), vigente al inicio del proyecto, especifica que
debe existir un Plan de Calidad. No se obtuvo evidencia de la existencia ni de un plan de calidad
aprobado formalmente ni de informes de calidad del proyecto en las distintas fases del ciclo de
vida y en particular, durante el proceso de “réplicas”.
Efectos. La UI no cumple con sus propias premisas, ni siquiera con su propuesta esbozada en el
Plan Estratégico de Informática 2003-2007 v.1 – Plan de Calidad.
4.5 Objetivo de Control: Modelo de la Arquitectura de Información de las Bases SLU
La Unidad Informática deberá crear y actualizar regularmente un modelo de arquitectura de
información, abarcando el modelo corporativo de datos y los sistemas de información asociados.
El modelo de arquitectura de información deberá ser consistente con el plan estratégico de
tecnología a largo plazo.
4.5.1 Actualización del modelo de datos
Ausencia de procedimientos que aseguren la actualización del modelo lógico de datos y
procesos.
Efectos. Mayor dependencia del conocimiento de los analistas y programadores que desarrollan
las aplicaciones.
4.5.2 Documentación automática
La herramienta Designer de Oracle que ha contratado la UI:
a) No se emplea para documentar los modelos de procesos.
b) No se tuvo evidencia de que se controle la consistencia entre tablas físicas y definiciones
lógicas en cada módulo utilizando el Designer.
Efectos. La UI tiene contratada una herramienta de la cual no se obtienen beneficios relevantes a
los fines de documentación de la base y el diseño del aplicativo.
Página 17
4.6 Objetivo de Control: Niveles de Seguridad
La Unidad Informática deberá definir, implementar y mantener niveles de seguridad. Estos
niveles deben plasmarse en un conjunto de medidas de seguridad y de controles apropiados –
como mínimo– para cada una de las clasificaciones.
4.6.1 DBlinks (Enlaces a otras bases de datos)
Se encontraron seis enlaces definidos hacia otras bases (una de ellas, al Sidif central) que no
estarían en uso. Uno de esos vínculos está conectado a la base de un organismo.
Efectos. Al no ser dados de baja y mantenerse los derechos, se podrían ejecutar acciones
indebidas.
4.6.2 Otras bases instaladas
En el servidor que aloja las bases de datos de los organismos se encontraron bases que
corresponden a aplicaciones no SLU.
Efectos. El servidor fue dimensionado para alojar las bases de los organismos, por lo que la
incorporación de bases ajenas podría alterar su performance y su servicio.
4.6.3 Pistas de auditoría
El archivo de configuración de las bases de datos no habilita la función de auditoría
(Audit_Trail). No se tuvo evidencia de que haya existido alguna actividad de auditoría de las
bases.
Efectos. No hay adecuado control sobre eventos como conexiones o accesos fallidos o
actividades no autorizadas. Podrían producirse cambios en las transacciones, sin dejar huellas.
4.6.4 Generación de bases de los organismos
Se encontraron bases creadas de organismos que aún no habían aprobado formalmente la
incorporación del SLU, es decir, sin la respectiva firma del acta acuerdo.
Efectos. Generar bases sin un criterio explícitamente definido afecta el mantenimiento de
servidores.
4.6.5 Roles y Permisos en el nivel aplicativo
Página 18
No se han establecido criterios para la selección del administrador local –quien realiza la
interfase técnica con la UI– que guíe al organismo y priorice la adecuada separación de
funciones.
Efectos. Puede darse el caso de que un administrador –que otorga roles y permisos– tenga
también facultades para realizar transacciones en el sistema.
4.7 Objetivo de Control: Control de Cambios
La Unidad Informática deberá asegurar que los cambios, el control y la distribución de software
sean integrados apropiadamente en un sistema completo de administración.
4.7.1 Herramienta de gestión de fuentes
La herramienta actual gestiona el control de cambios desde el desarrollo hasta la etapa de “puesta
en línea de base” previa a la implementación en el entorno de producción. Es decir, los sistemas
para administrar tanto los requerimientos como la implementación no están integrados.
Efectos. No facilita el seguimiento –ni la auditoría– de los requerimientos a lo largo del ciclo de
vida del sistema.
4.7.2 Finalización de Fases
Las comunicaciones de finalización de fases como Implementación, Testing y Requerimientos se
asientan por correo electrónico.
Efectos. No disponen de un soporte seguro para la registración.
4.7.3 Pasaje a la línea de base
El procedimiento para el pasaje de fuentes de “testing” a la línea de base o ambiente de
preproducción puede ser realizado tanto por personal de “testing” como de Implementación.
Efectos. El procedimiento es ambiguo pues no están separadas las funciones y
responsabilidades.
4.8 Objetivo de Control: Estándares para la Documentación
La metodología del ciclo de vida de desarrollo de sistemas deberá incorporar estándares para la
documentación que hayan sido impuestos y comunicados al personal que corresponda. La
Página 19
metodología deberá asegurar que la documentación creada durante el desarrollo del sistema de
información o de los proyectos de modificación coincida con estos estándares.
4.8.1 Estándares
La normativa de documentación, aunque es consistente en sus contenidos técnicos, carece de la
definición de aspectos formales como, por ejemplo, niveles de autorización para aprobar las
normas, explicitación de los responsables de actualizarlas y de controlar su cumplimiento.
Efectos. Al no definir responsabilidades, no es posible asegurar el cumplimiento de la
normativa.
4.8.2 Documentación de desarrollo
No se relevaron procedimientos de control que aseguren la correcta generación y publicación de
documentación de desarrollo del SLU.
La publicación de la documentación interna de los sistemas –para uso del personal de la UI– se
realiza a través del repositorio –biblioteca digital– de la Unidad Informática (UI/documentación).
La biblioteca no cuenta con un responsable de controlar la coherencia de lo publicado y su
adecuada actualización. Se encontraron directorios que contienen información duplicada, así
como documentos con especificaciones de auditorías (programas de control interno) de los
módulos del sistema, desconocidas por sus propios responsables.
La responsabilidad de controlar el cumplimiento de la documentación de desarrollo estaría
asignada al responsable de cada módulo, de manera que el control se asigna al área que debe
realizar la tarea.
Del análisis de la documentación técnica de SLU disponible en la biblioteca digital surge el
siguiente cuadro, donde se pueden apreciar incumplimientos en la forma de documentar los
distintos módulos del sistema.
Página 20
MÓDULO
Análisis Análisis Especificación Manual
Manual Usuario
Detallado Global Requerimientos Procedimientos
Cajas Chicas
Compras
Conciliación
Bancaria
Contabilidad
General
Gastos
Pagos
Presupuesto
Expedientes
Informes
Gerenciales
Programación
Ejecución
Programa
Ejecución
Física
Programación
Financiera
Recursos
Tablas
Básicas
General
SI
NO
SI
SI
SI
NO
SI
SI
SI
SI
SI
SI
SI
SI
SI
NO
NO
NO
NO
NO
SI
SI
SI
SI
SI
SI
SI
SI
NO
NO
NO
NO
SI
SI
SI
SI
SI
SI
SI
SI
SI
SI
NO
NO
SI
SI
SI
SI
SI
SI
SI
SI
NO
NO
SI
SI
NO
NO
SI
SI
SI
SI
SI
SI
SI
NO
SI
SI
SI
SI
NO
NO
NO
NO
SI
Efectos. Fuerte dependencia con los expertos hoy contratados.
4.8.3 Actualización
No se obtuvo evidencia de procedimientos y/o sistemas que aseguren la adecuada actualización
de los documentos dejando registro de sus altas, bajas y modificaciones.
Efectos. Disminuye la probabilidad de mantener actualizada la documentación al no disponer de
procedimientos y controles automáticos.
Página 21
4.8.4 Documentación Técnica de las Réplicas
Durante nuestra revisión (septiembre de 2005) de las Actas Acuerdo y Convenio de Prestación
de Servicios firmadas con los organismos donde se instaló SLU, se encontró que en trece de ellas
no estaban los respectivos acuerdos y convenios, aunque el sistema se encontraba en
funcionamiento desde antes del 31 de diciembre de 2004.
En la revisión (julio de 2005) de la documentación técnica producida durante el proceso de
réplicas se detectó, en treinta organismos donde se había implementado el SLU, la ausencia de
uno o más de los siguientes documentos: Cronograma de tareas, Relevamiento Técnico, Informe
Final, Plan de Capacitación y Plan de Trabajo.
Efectos. Pérdida en los registros de auditoría y poco enriquecimiento de las experiencias propias.
4.8.5 Sitio Web
La UI dispone de un sitio Web para la comunicación digital externa con usuarios y público en
general. El sitio es poco explotado; sus contenidos brindan pocos servicios e información –no
hay descripción de los sistemas en gestión–, no apunta a las necesidades por tipo de usuario y
por sistema. En otro orden, como sitio público no provee al ciudadano de información sobre los
resultados de su propia gestión.
En relación al SLU, se destaca la ausencia de información sobre:
•
Detalle de los proyectos en curso y previstos.
•
Información sobre los gastos asignados en el presupuesto nacional.
•
Publicación de la política de ingreso de personal y las vacantes disponibles.
•
Buscadores internos que permitan explotar los contenidos y guiar mejor al visitante.
•
Mapa del sitio.
•
Respuestas a preguntas frecuentes.
•
Libro de visitas.
•
Texto alternativo o explicativo a imágenes y gráficos. Esta carencia limita la
accesibilidad de la página o sitio.
El cuadro siguiente muestra algunas características del sitio.
Página 22
SITIO DE LA UNIDAD INFORMÁTICA WWW.UNINFO.MECON.GOV.AR
1) Contenidos Básicos (Web)
Autoridades
Organigrama
Marco Normativo
Misiones y Funciones
Descripción de Proyectos en curso o
previstos
Presupuesto Nacional
Cumplimiento Resolución 97/97 y ETAP’s 10.0
Sí
Sí
Sí
Sí
No.
No. No hay características del programa a su
cargo
Compras o Contrataciones
No
Novedades
Sí
Publicaciones elaboradas por el Sí
organismo
Versiones en otros idiomas
No
Acuerdos realizados con otros Sí
organismos
Dirección (Postal, Electrónica y Sí
Teléfonos)
Dirección Electrónica Webmaster No
Dominio (gov.ar)
Sí
2) Facilidades Básicas
Cumplimiento Resolución 97/97 y ETAP’s 10.0
Mapa del Sitio
No
Buscador
No
Enlaces a otros sitios
No (sólo tiene un vínculo a la Web de Hacienda;
de la cual depende la UI)
Política de ingreso de personal/ No
vacantes disponibles
Fecha de actualización
No
Boletín Informativo
Sí
Dirección o link de consulta para el Sí (vía e-mail)
ciudadano
Libro de Visitas
No
Cumplimiento Resolución 97/97 y ETAP’s 10.0
3) Accesibilidad
Texto alternativo a imagen
No
Contraste de colores entre texto y Sí
fondo
Encabezamientos
en
filas
y Sí
columnas
Identificación del lenguaje natural No
Página 23
del documento
Marcos con títulos
Texto alternativo
Contraseña (password) de usuario
4) Trámites
Formularios de trámites
Consulta de expedientes
Sí
No
Sí
Cumplimiento Resolución 97/97 y ETAP’s 10.0
No.
Sí (Manuales y Estadísticas)
Efectos. Herramienta de gran potencial desaprovechada como medio de comunicación y en la
prestación de servicios a usuarios y ciudadanos en general.
4.9 Objetivo de Control: Prueba de Aceptación Final
Los procedimientos deberán asegurar que las Gerencias de los departamentos usuarios afectados
y de la Unidad Informática evalúen y aprueben formalmente los resultados de las pruebas de
aceptación final o las pruebas de calidad de sistemas de información nuevos o modificados.
Las pruebas deben cubrir todos los componentes del sistema de información (software de
aplicación, instalaciones, tecnología, procedimientos de usuarios).
4.9.1 Aprobación del usuario
No se obtuvo evidencia de que los usuarios –responsables operativos en los organismos– hayan
dado su aprobación formal en las etapas de implementación del SLU. Así, la aprobación de
cronogramas de tareas, cantidad de cursos, talleres de capacitación, entre otros, sería atribución
exclusiva de la SH a través de la UI.
Efectos. Es una práctica contraria a cualquier metodología del ciclo de vida del sistema.
4.10 Objetivo de Control: Convenio de Nivel de Servicio
Deberá lograrse un acuerdo explícito sobre el nivel de servicios. El convenio de nivel de
servicios deberá cubrir por lo menos los siguientes aspectos: disponibilidad, confiabilidad,
desempeño, capacidad de crecimiento, niveles de soporte proporcionados a los usuarios, plan de
contingencia/recuperación,
nivel
mínimo
aceptable
de
funcionalidad
del
sistema
satisfactoriamente liberado, restricciones (límites en la cantidad de trabajo), cargos por servicio,
Página 24
instalaciones de impresión central (disponibilidad), distribución de impresión central y
procedimientos de cambio.
4.10.1 Aspectos del Convenio
El modelo de convenio que la Unidad Informática acuerda brindar a los organismos que adoptan
el SLU no contiene aspectos del nivel de servicio a ofrecer, como disponibilidad, confiabilidad,
desempeño, capacidad de crecimiento.
Efectos. No es posible determinar de manera cuantitativa la calidad de servicio brindado, lo que
impide asegurar un nivel de compromiso previsible e incluso mejorarlo.
4.11 Objetivo de Control: Evaluación de la Satisfacción de Usuarios
A intervalos regulares, la Unidad Informática deberá medir la satisfacción de los usuarios con los
servicios brindados, para identificar deficiencias en los niveles de servicio y establecer objetivos
de mejoramiento.
4.11.1 Encuesta y Conclusiones
En el período julio de 2001- julio de 2005 se obtuvo evidencia de una encuesta de opinión
proporcionada por la Dirección del Centro de Estudios y Capacitación sobre el sistema
implementado que abarcó a cinco organismos. No se obtuvo acceso o evidencia respecto de las
conclusiones a que arribó ese trabajo.
Es decir, no se realizarían regularmente encuestas a los usuarios sobre la satisfacción del sistema.
Esta auditoría entrevistó a los responsables operativos de algunos organismos, y la opinión sobre
el SLU puede resumirse en el siguiente cuadro:
Participación en las
decisiones
Satisfacción en el
servicio
Adopción del SLU
Proceso de Réplicas
Post Implementación
Aprobación del usuario
Ninguna
Aceptable
Regular
Ninguna etapa
Por la versatilidad del sistema Aceptable
Asistencia Técnica
Buena
Capacitación
Muy Buena
Página 25
Mejoras a las necesidades del
organismo
Pobre
Como puede apreciarse, los puntos más vulnerables son la casi nula participación en las
decisiones y en la poca agilidad para adaptar el sistema a las necesidades operativas del
organismo, lo cual permitiría explotar mejor las posibilidades del SLU. Dentro del último
concepto, se pueden señalar:
1)
Rigidez para identificar transacciones ligadas o vinculadas por un expediente de uso
corriente en los organismos. La solución –precaria– adoptada por los usuarios ha sido cargar el
número del expediente en cada etapa del gasto.
2)
No permite administrar transacciones como otorgamiento y rendición de anticipos,
manejo de débitos bancarios por comisiones y gastos, y no es posible gestionar la autorización y
pago de cajas chicas secundarias.
3)
El sistema no permite la integración con sistemas estándares del organismo como
Liquidación de sueldos y el sistema BAPIN –Banco de Proyectos de Inversión.4)
Incapacidad de integración con otros sistemas de gran valor agregado como Tablero de
Comando.
Efectos. No compromete al usuario en la innovación y la mejora del SLU. Al no facilitar
interfases con los sistemas propios de los organismos, no les permite integrar sus sistemas, lo que
disminuye la prestación general y los hace incurrir en mayores costos.
4.11.2 Comité de Usuarios
Durante 2004 se habría constituido el Comité de Usuarios del SLU, el cual:
•
adolece de un respaldo formal de su creación,
•
no presenta registros formales de los acuerdos alcanzados,
•
la participación habría estado limitada a algunos organismos.
Efectos. Se desaprovechan las oportunidades que ofrece este tipo de organización para mejorar
el producto.
Seguridad Física y Lógica
Página 26
4.12 Objetivo de Control: Administrar Medidas de Seguridad
La seguridad en Tecnología de Información deberá ser administrada de tal forma que las
medidas de seguridad se encuentren en línea con los requerimientos de la administración
financiera. Esto incluye:
•
Traducir información sobre evaluación de riesgos a los planes de seguridad de
tecnología;
•
implementar el plan de seguridad de tecnología de información;
•
actualizar el plan de seguridad de tecnología de información para reflejar cambios en la
configuración de tecnología;
•
evaluar el impacto de solicitudes de cambio en la seguridad de tecnología de
información;
•
monitorear la implementación del plan de seguridad de tecnología de información; y
•
alinear los procedimientos de seguridad de tecnología de información con otras políticas
y procedimientos.
4.12.1 Aspectos del Plan de Seguridad Informática
El documento normativo
NUI Nº 7 “Plan de Seguridad Informática”, versión Nº 1 del
24/06/2003, no dispone de:
•
un diagnóstico de la situación actual de la seguridad informática, es decir del punto de
partida del plan;
•
un plan de tareas a desarrollar en el corto y mediano plazo;
•
asignación de responsabilidades a los participantes;
•
una evaluación de riesgos, amenazas y vulnerabilidades.
Ni el documento mencionado ni la “Norma de control de acceso lógico” tienen respaldo formal
o disposición de una autoridad que comprometa su cumplimiento.
Efectos. Se incrementan los riesgos y no existe obligación de cumplir los objetivos propuestos
en el “Plan de Seguridad Informática”.
Página 27
4.13 Objetivo de Control: Control de la Configuración
Los procedimientos deberán asegurar que la existencia y consistencia del registro de la
configuración sean revisadas periódicamente.
4.13.1 Configuración del Sistema Operativo del Servidor de la Base de Datos
Durante nuestra revisión se encontraron:
1. Cuatro cuentas genéricas que no cumplen con el procedimiento “ Creación Usuarios
Genéricos” contenido en la NUI Nº 7.
2. Seis cuentas por defecto habilitadas que no cumplen la norma de “ control de acceso
lógico”
3. Cinco servicios habilitados de los que no hay evidencia de su utilización.
4. Las auditorías de eventos se refieren exclusivamente a login y log out de los usuarios.
5. Está habilitado el acceso en forma remota a la cuenta “ súper usuario” .
Efectos. Estas brechas de seguridad tornan al sistema vulnerable a eventuales ataques.
4.13.2 Configuración del Sistema Operativo del Servidor de Aplicaciones
Durante nuestra revisión encontramos:
1. El proveedor ha dejado –desde el 30/11/99– de brindar soporte (actualizaciones y
arreglos, entre otros) al sistema operativo del servidor de aplicaciones.
2. Seis servicios habilitados sin restricciones en el servidor. Órganos de seguridad como
UNAM-CERT desaconsejan el uso indiscriminado.
3. Está habilitada la posibilidad de efectuar una null-session (Anonymous Logon) que
permite que un usuario obtenga información de nombres de usuarios, grupos, recursos
compartidos sobre la red –incluyendo los ocultos–, dominios y estaciones de trabajo de
confianza sin estar debidamente identificado.
4. Esta habilitado el protocolo de autenticación Lan Manager (LM).
5. El antivirus no está actualizado.
6. Una vulnerabilidad en la aplicación SLU cuando se utiliza la opción “Consulta y
listados/facturas cajas chicas secundarias”, pues permite acceder a la línea de comando
del servidor.
Página 28
Efectos. Estas brechas de seguridad tornan al sistema vulnerable a eventuales ataques.
4.13.3 Configuración del Sistema Operativo del Servidor de Acceso al Dominio
En nuestra revisión se encontraron definiciones con valores inferiores a los recomendados por
UNAM-CERT en las siguientes políticas para el dominio:
•
Longitud mínima de contraseña.
•
Limite de bloqueo de cuentas con intentos de login fallidos.
Efectos. Debilidad y vulnerabilidad del control interno informático.
4.13.4 Registros de Incidentes de Seguridad
No se tuvo evidencia de la existencia de un procedimiento formal para registrar este tipo de
incidentes.
Efectos. La posibilidad de detectar las causas de un incidente mayor disminuye por la falta de
registro de los pequeños errores.
4.14 Objetivo de Control: Respaldo y Restauración
La UI deberá implementar una estrategia y procedimientos apropiados para el respaldo y
restauración de datos y programas.
4.14.1 Resguardo y recuperación
En el sector donde se almacenan las cintas de respaldo se verifica:
•
la existencia de actas de resguardo y recuperación sin la firma del área de seguridad
informática durante 2004;
•
la inexistencia de caja ignífuga en el sector puerto de la Contaduría General donde reside
una de las copias del conjunto de cintas.
Efectos. En caso de siniestro no se podría disponer de las cintas de backup.
4.15 Objetivo de Control: Garantía de un Servicio Continuo
Se debe crear un marco de referencia que defina los roles, responsabilidades, el enfoque basado
en el riesgo, la metodología, las reglas y la estructura para documentar el plan de continuidad, así
como los procedimientos de aprobación.
Página 29
4.15.1 Norma para el Plan de Contingencias
La norma elaborada por la UI no está aprobada formalmente. Los planes de contingencia
relevados (versión 1, del 24/06/03, para la Secretaría de Hacienda con referencia al SLU, que
comprende un “Procedimiento para Contingencia Servidores de Aplicación (SLU)”, un
“Procedimiento de Contingencia Concentrador SLU – DB Server, del 30/042003” y el plan ante
desastres de la red Mecon elaborado por el área Proyecto “Informática del Mecon” ) no incluyen
casi ninguna de las Medidas de Control establecidas por la norma.
4.15.2 Riesgos de continuidad
1. Nuestra evaluación indica que no está asegurada la continuidad del SLU ante eventuales
sucesos adversos. No hay coordinación entre los actores cuando el evento compromete a
más de un área, ni estudios o documentos que identifiquen los riesgos y amenazas a que
están expuestos los procesos, el personal y los equipos.
2. No existe un plan integral de contingencia para el SLU. Se relevaron procedimientos de
contingencia que cubren eventos parciales pero no se obtuvo evidencia de
procedimientos relativos a la conectividad de las redes de la UI y del MECON, de la
infraestructura edilicia y de guías rápidas para el personal involucrado ante los distintos
escenarios de riesgos, entre otras carencias.
3. Desactualización. El procedimiento relevado de contingencia para los servidores de
aplicación SLU considera menos servidores que los efectivamente existentes.
Correlativamente, en el procedimiento de contingencia “ Concentrador SLU–DB Server” ,
se mencionan servidores inexistentes en el período de relevamiento de esta auditoría.
4. Los procedimientos mencionados no han sido aprobados formalmente.
Efectos. Las deficiencias señaladas podrían provocar, en situaciones de emergencia, graves
daños a los organismos involucrados.
Página 30
Seguridad Física
4.16 Objetivo de control: Seguridad Física
Se deben establecer medidas de seguridad física y control de ingreso en las instalaciones de
tecnología de la información de acuerdo con la política de seguridad general, incluyendo el uso
de dispositivos de información fuera de las instalaciones. Es decir, restringir el acceso a todos
aquellos que no hayan sido autorizados.
4.16.1 Registración de los Accesos en Salas de Servidores SLU - Mecon / Sitio de
procesamiento anexo Se registran los ingresos y egresos de las visitas en planillas ubicadas en una carpeta.
No se cumple con lo indicado en el punto 2, “ Políticas para acceso a zonas restringidas”, de la
UI – Secretaría de Hacienda – Normas de Seguridad Física y Ambiental (“Todos los visitantes
se registrarán en Seguridad o Recepción firmando la entrada y salida…” ).
Efectos. Si se pierde alguna planilla, se pierde el registro de las visitas.
4.16.2 Registración de los accesos en Sala de Servidores SLU - Área Proyecto “Informática
del Mecon” No se cumple el procedimiento establecido. No se registran las entradas y salidas del personal
ajeno al área.
Efectos. Ante un eventual daño a la instalación o un robo, no se dispondría de la información
que permitiría identificar al autor.
4.17 Objetivo de control: Protección contra Factores Ambientales
La UI deberá asegurar medidas para la protección contra los factores ambientales. Por ejemplo:
fuego, polvo, electricidad, calor o humedad excesiva. Es necesario instalar equipos y dispositivos
especializados para monitorear y controlar el ambiente.
4.17.1 Cerramientos en Centros de Procesamiento de Datos – UI / Área Proyecto
“Informática del Mecon” -
Página 31
Los cerramientos no son resistentes al fuego y las ventanas que están ubicadas sobre el aire-yluz no tienen paneles exteriores protectores.
Efectos. Riesgo de incendio de áreas externas al local. Peligro de propagación del fuego a
plantas superiores.
4.17.2 Bolsas de residuos - Recipientes de residuos en Centro de Procesamiento de Datos
UI Las bolsas de residuos son de color negro.
Los recipientes de residuos no poseen tapas y su superficie lateral presenta aberturas.
Efectos. No se pueden controlar los materiales que se retiran del CPD. Riesgo de incendio.
4.17.3 Cables desordenados en Centros de Procesamiento de Datos – UI / Sitio de
procesamiento anexo Los cables ubicados de debajo del escritorio (local oficina – UI – Secretaría de Hacienda) y en
la parte posterior de los gabinetes (racks) no están ordenados, y se observaron tomacorrientes y
cables sueltos.
Efectos. La desconexión involuntaria de los cables de los equipos puede interrumpir algunos
servicios y demorar la ejecución de los trabajos.
4.17.4 Interruptores eléctricos en los equipos de aire acondicionado de los Centros de
Procesamiento de Datos – UI / Sitio de procesamiento anexo / Área Proyecto “Informática
del Mecon” No se han instalado en la puerta principal controles eléctricos de emergencia –interruptores de
corte de energía eléctrica usados en casos de emergencia (equipos, iluminación, etc.) - ni para los
equipos de aire acondicionado.
Efectos. En caso de emergencia, no es posible acceder en forma rápida a las llaves de corte del
suministro eléctrico de las instalaciones.
4.17.5 Sistema de extinción en los Centros de Procesamiento de Datos – UI / Área Proyecto
“Informática del Mecon” La sala de los servidores por donde se ingresa al CPD – UI y el local correspondiente al área
Proyecto “Informática del Mecon” no cuenta con un sistema de extinción de incendios.
Página 32
Efectos. Riesgo de incendio con compromiso de los otros locales que no están separados por
cerramientos resistentes al fuego.
4.17.6 Matafuegos en los Centros de Procesamiento de Datos – UI / Sitio de procesamiento
anexo / Área Proyecto “Informática del Mecon” Los matafuegos están vencidos y no se encuentran en algunos locales ubicados en los soportes.
En el sitio de procesamiento anexo – edificio AFIP, no se ha observado ningún matafuego.
Efectos. La falta de matafuegos y la de recarga y control de los existentes podría posibilitar que
ante un conato de incendio no puedan utilizarse.
4.17.7 Simulacros en Centros de Procesamiento de Datos – UI /
Área Proyecto
“Informática del Mecon” No se realizan los simulacros de evacuación.
Efectos. Se pueden producir daños a los equipos y personas.
4.17.8 Sistema de audio en los Centros de Procesamiento de Datos – UI / Área Proyecto
“Informática del Mecon” No existe un sistema de audio para utilizarlo en caso de emergencia.
Efectos. La señal de emergencia y la evacuación no se realizan en forma rápida y eficiente.
4.17.9 Luces de emergencia en los Centros de Procesamiento de Datos – UI / Sitio de
procesamiento anexo / Área Proyecto “Informática del Mecon” No existen luces de emergencia autónomas.
Efectos. Dificulta el restablecimiento manual del sistema y el desplazamiento del personal en los
locales en caso de cortes de energía eléctrica.
4.17.10 Planos del sistema de instalación de control de temperatura y humedad de la sala
principal de servidores y del sistema de instalación de control de temperatura
correspondiente al local de ingreso - Centro de Procesamiento de Datos UI –
No existe documentación de la instalación.
Efectos. La falta de documentación impedirá tener una rápida respuesta frente a posibles daños a
la instalación y/o equipos. También impactará en el caso de realizase modificaciones.
4.17.11 Planos de la instalación eléctrica - Centro de Procesamiento de Datos UI –
Página 33
Los planos de la instalación eléctrica (esquema unifilar – tableros seccionales) entregados no
están actualizados (fecha: 5 de noviembre de 1996).
Efectos. La falta de documentación impedirá tener una rápida respuesta frente a posibles daños a
la instalación y/o equipos. También impactará en el caso de realizase modificaciones.
4.17.12 Contrato de mantenimiento de los sistemas de control de temperatura y humedad
- Centro de Procesamiento de Datos UI –
No ha sido aprobado formalmente. No se indica la empresa encargada del mantenimiento del
sistema ni la fecha de inicio y finalización del contrato.
Efectos. Riesgo de deterioro de los equipos por falta de mantenimiento.
4.17.13 Plan de mantenimiento de los sistemas de control de temperatura y humedad
- Centro de Procesamiento de Datos UI –
No se encuentra aprobado formalmente, no se indican las fechas de ejecución de las tareas.
Efectos. Riesgo de deterioro de los equipos por falta de mantenimiento en las fechas que
correspondan.
4.17.14 Tomacorrientes - Centro de Procesamiento de Datos UI –
Algunos tomacorrientes se encuentran instalados sobre bases de madera, fuera de la normativa
vigente.
Efectos. Si se produce un cortocircuito, se podrían dañar los tomacorrientes y conductos
eléctricos.
4.17.15 Humedad en paredes y cielo raso - Sitio de procesamiento anexo El cielo raso y algunas paredes presentan signos de humedad.
Efectos. Riesgo de deterioro de los equipos e instalaciones y de interrupción total del servicio.
4.17.16 Normas y procedimientos para el mantenimiento de la instalación eléctrica - Sitio
de procesamiento anexo –
No se obtuvo evidencia de las normas y procedimientos para el mantenimiento de la instalación
eléctrica.
Página 34
Efectos. La falta de normas y procedimientos genera riesgos que afectan la vida de las personas,
las instalaciones y equipos y su cumplimiento además evita averías, desgastes, deterioros y
accidentes.
4.17.17 Registros de los controles de las instalaciones eléctricas - Sitio de procesamiento
anexo No existen registros de los controles de las instalaciones eléctricas.
Efectos. Riesgo de daño en las instalaciones y equipos.
4.17.18 Instalación de la puesta a tierra y mediciones - Sitio de procesamiento anexo No se obtuvo evidencia de la existencia de la puesta a tierra del sistema eléctrico.
No se realizan mediciones.
Efectos. Riesgo de deterioro de las instalaciones y equipos informáticos. Incumplimiento de la
reglamentación y normativa de las instalaciones eléctricas (Asociación Electrotécnica Argentina,
ENRE, IRAM, etc.).
4.17.19 Orden y limpieza en el acceso - Sitio de procesamiento anexo No se encuentra el acceso siempre limpio y ordenado.
Efectos. Las vías de acceso, sucias y cubiertas de materiales combustibles, impiden un acceso
rápido y seguro.
4.17.20 Limpieza en Centro de Procesamiento de Datos – Área Proyecto “Informática del
Mecon “ El procedimiento de limpieza no está aprobado formalmente y tampoco indica las tareas a
realizar.
Efectos. Podrían limpiarse elementos sensibles y se produciría algún daño involuntario.
4.17.21 Locales linderos - Protección contra incendios – Centro de Procesamiento de Datos
del Área Proyecto “Informática del Mecon” Los locales linderos no poseen protección contra incendios.
Efectos. Si se declarase un incendio en el exterior de la sala de servidores, podría afectar el Área.
4.17.22 Plan de mantenimiento de las instalaciones eléctricas – Centro de Procesamiento
de Datos del Área Proyecto “Informática del Mecon” -
Página 35
No se ha obtenido evidencia del plan de mantenimiento de las instalaciones eléctricas.
Efectos. Riesgo de incendio y deterioro en las instalaciones.
4.17.23 Instrucciones para actuar en un incendio – Centro de Procesamiento de Datos del
Área Proyecto “Informática del Mecon”
En los locales no hay instrucciones sobre cómo actuar en caso de incendio en la sala de
servidores.
Efectos. Falta de respuesta inmediata ante un incendio.
4.17.24 Capacitación – Centro de Procesamiento de Datos del Área Proyecto “Informática
del Mecon “ El personal de la sala de servidores no está entrenado en el manejo de los matafuegos.
Efectos. Ante un conato de incendio, el personal presente no puede intervenir en forma rápida y
eficaz.
4.17.25 Plan de emergencia y evacuación – Centro de Procesamiento de Datos del Área
Proyecto “Informática del Mecon” No se ha elaborado un plan de emergencia y evacuación específico para el área.
Efectos. Se pueden producir daños a los equipos y personas.
4.17.26 Salida de emergencia – Centro de Procesamiento de Datos del Área Proyecto
“Informática del Mecon “ No existe una salida de emergencia.
Efectos. Ante un presunto frente de fuego, el personal ubicado en la parte posterior del local no
podría alcanzar la puerta de ingreso.
4.17.27 Sitio alternativo al Centro de Procesamiento de Datos del Área Proyecto
“Informática del Mecon” No se pudo obtener información sobre la existencia de un sitio de procesamiento alternativo.
Efectos. Para el caso de producirse un desastre (incendio, etc.) no existiría un lugar con las
instalaciones y equipos adecuados para poder continuar con el servicio que presta el Área
Proyecto Informática.
Página 36
4.17.28 Filtración de agua – Centro de Procesamiento de Datos del Área Proyecto
“Informática del Mecon “ Filtración y caída de agua en el cielo raso del local.
Efectos. Riesgo de deterioro de los equipos e instalaciones, y de interrupción total del servicio.
5. ANALISIS DE LA VISTA
Por Nota N° 8/06 CSGPyPE con fecha 4/04/2006, se remitió copia del Proyecto de Informe en
vista al Organismo para que formule el descargo respectivo.
Habiendo transcurrido el plazo establecido por la nota de referencia y conforme lo previsto por la
Resolución AGN N° 77/02 el Organismo no ha formulado comentarios al respecto.
6. RECOMENDACIONES
6.1 Objetivo de Control: Participación Proactiva de Auditoría
6.1.1 Auditoría independiente
Incorporar como práctica el requerimiento de auditoría antes de la entrega de cada solución
tecnológica.
Por otra parte, DAS debe mantener una adecuada separación de sus funciones.
6.2 Objetivo de Control: Certificación o Acreditación Independiente de Seguridad
6.2.1 Certificación de Seguridad
Incorporar este requerimiento de acreditación en la metodología del ciclo de vida de los sistemas
antes de la implementación.
Ciclo de Vida del Sistema
6.3 Objetivo de Control: Marco de Referencia para la Administración de Proyectos
6.3.1 Administración del proyecto SLU
Página 37
Definir formalmente el marco para la administración de proyectos de la Unidad Informática.
6.4 Objetivo de Control: Plan de Aseguramiento de la Calidad de Sistemas
6.4.1 Plan de Calidad del Sidif Local Unificado
Dotar al proyecto de mayor coherencia con relación a la mejora de la calidad de los procesos.
6.5 Objetivo de Control: Modelo de la Arquitectura de Información del SLU
6.5.1 Actualización del modelo de datos
Definir procedimientos formales que permitan asegurar la adecuada actualización del modelo
lógico de datos y procesos.
6.5.2 Documentación automática
Evaluar alternativas que permitan asegurar la documentación automática del modelo de datos y
módulos del SLU.
6.6 Objetivo de Control: Niveles de Seguridad
6.6.1 DBlinks (Enlaces a otras bases de datos)
Establecer procedimientos de monitoreo que permitan actualizar en tiempo los dblinks creados.
6.6.2 Otras bases instaladas
Revisar los criterios de diseño de bases para preservar la seguridad y performance de las bases
SLU.
6.6.3 Pistas de auditoría
Evaluar escenarios de riesgo localizando los activos más sensibles para generar auditorías
compatibles con la performance y el nivel de protección.
6.6.4 Generación de bases de los organismos
Definir un procedimiento formal para el alta (generación), la baja y la modificación de las bases
de datos de los organismos en los servidores.
6.6.5 Roles y Permisos a nivel de aplicativo
Definir un procedimiento que especifique las condiciones que deben cumplir los administradores
locales que asegure, entre otros ítems, una adecuada separación de funciones.
Página 38
6.7 Objetivo de Control: Control de Cambios
6.7.1 Herramienta de gestión de fuentes
Desarrollar una herramienta que permita integrar todas las fases del ciclo de vida del sistema
para obtener un sistema confiable y auditable de administración y adecuado al volumen de
transacciones. Complementar con los procedimientos pertinentes para su manejo.
6.7.2 Finalización de Fases
Incorporar la administración de las comunicaciones de finalización de fases en la herramienta
sugerida en 6.7.1.
6.7.3 Pasaje a la línea de base
Definir un procedimiento de control que establezca las responsabilidades. Se sugiere que la
herramienta propuesta en 6.7.1, incorpore esta definición.
6.8 Objetivo de Control: Estándares para la Documentación
6.8.1 Estándares
Definir los aspectos formales de la normativa como los niveles autorizados para aprobar las
normas, responsables de la actualización y del control de su cumplimiento.
6.8.2 Documentación de desarrollo
Desarrollar un sistema que permita gestionar la documentación en todas las etapas del ciclo de
vida y sea parte del proceso de administración de cambios –sugerido en 6.7.1– e incorporando
allí los controles.
6.8.3 Actualización
El proceso de actualización debe ser parte del sistema propuesto en 6.8.2.
6.8.4 Documentación Técnica de las Réplicas
Mejorar la gestión del ciclo de vida incorporando controles –hoy inexistentes– que permitan un
cumplimiento más acabado de la normativa.
6.8.5 Sitio Web
Página 39
Rediseñar el sitio para incorporar servicios vía Web a los organismos usuarios en forma
personalizada y proveer información sobre la propia gestión al público en general.
Ello podría ser de gran utilidad para otros centros de cómputos gubernamentales.
6.9 Objetivo de Control: Prueba de Aceptación Final
6.9.1 Aprobación del usuario
Incorporar en la metodología del ciclo de vida de los sistemas producidos por la Unidad
Informática el requisito de contar con una evaluación y aprobación formal de los usuarios,
responsables operativos, del SLU y sus eventuales modificaciones.
6.10 Objetivo de Control: Convenio de Nivel de Servicio
6.10.1 Aspectos del Convenio
Reformular los convenios de servicio comprometiendo a la UI a brindar servicios mensurables
en términos de disponibilidad, capacidad de crecimiento y especificar las eventuales
restricciones de ese servicio. Debe incluirse el modo de comunicación para informar su nivel de
cumplimiento.
6.11 Objetivo de Control: Evaluación de la Satisfacción de Usuarios
6.11.1 Encuesta y Conclusiones
Incorporar en la metodología del ciclo de vida del sistema la realización de encuestas de
satisfacción de usuarios en períodos regulares y publicarlos en el sitio Web de la UI.
6.11.2 Comité de Usuarios
Formalizar los mecanismos de funcionamiento del Comité e incentivar a los responsables
operativos para que asuman mayor compromiso. El sitio Web de la UI sería una buena
herramienta para interactuar con ellos.
Seguridad Física y Lógica
Página 40
6.12 Objetivo de Control: Administrar Medidas de Seguridad
6.12.1 Aspectos del Plan de Seguridad Informática
1. Evaluar el documento normativo NUI Nº 7 “Plan de Seguridad Informática”, versión Nº 1, del
24/06/2003; actualizarlo indicando un diagnóstico claro que contemple una perspectiva de la
situación actual de la seguridad informática y con ésta desarrollar las tareas a corto y mediano
plazo necesarias, incluyendo un cronograma de tareas y tiempos.
2. Elaborar “ Políticas de Seguridad de la Información Modelo” (Res. SGP Nº 45/2005).
3. Establecer un proceso formal de aprobación por parte de la Unidad Informática / Secretaría de
Hacienda (directiva, disposición o resolución).
6.13 Objetivo de Control: Control de la Configuración
6.13.1 Configuración del Sistema Operativo del Servidor de la Base de Datos
Se recomienda:
1. Deshabilitar las cuentas default (bin, sys, adm, uucp, finger, smmsp).
2. Deshabilitar los servicios que no justifiquen su existencia.
3. Auditar otros eventos además del login y logout de los usuarios.
4. No realizar los accesos con perfil “root” (súper usuario) en forma remota. Si es necesario
y justificado, puede utilizarse otro nombre de usuario con perfil equivalente.
6.13.2 Configuración del Sistema Operativo del Servidor de Aplicaciones
1. Evaluar la conveniencia costo-beneficio de actualizar la versión del sistema operativo
sugerida por el proveedor.
2. La UNAM-CERT (Centro de Emergencias de Redes de la Universidad Nacional
Autónoma de México) desaconseja el uso de estos servicios a menos que estén
debidamente justificados.
3. Establecer una directiva en el registro para que se deshabilite la posibilidad de efectuar
null - session (logín anónimo).
4. Establecer una directiva para deshabilitar el uso del protocolo de autenticación Lan
Manager.
Página 41
5. Actualizar el motor del Antivirus.
6. Efectuar una revisión de la seguridad de la aplicación.
6.13.3 Configuración del Sistema Operativo del Servidor de Acceso al Dominio
1. Establecer una longitud mínima de contraseña ocho caracteres.
2. Establecer un límite de bloqueo de tres intentos.
3. Establecer el reinicializador de bloqueo en 30 minutos.
Sugerimos tomar las recomendaciones de UNAM-CERT o ArCERT.
6.13.4 Registros de Incidentes de Seguridad
Se recomienda establecer un procedimiento formal que describa quien será el responsable y
como debe registrase tal situación o evento.
Tomar las recomendaciones de UNAM-CERT o ArCERT.
6.14 Objetivo de Control: Respaldo y Restauración
6.14.1 Resguardo y recuperación
1. Establecer un procedimiento y posterior cumplimiento por parte del área de seguridad
informática.
2. Depositarlo en una caja ignífuga.
6.15 Objetivo de Control: Garantía de un servicio continuo
6.15.1 Norma para el Plan de Contingencias
Aprobar formalmente la norma. Incluir en los procedimientos de contingencias, las medidas de
control establecidos en la norma.
6.15.2 Riesgos de continuidad
1. Establecer una coordinación con las áreas del Mecon, la Dirección Técnica Operativa y el
Proyecto “Informática del Mecon”. Identificar los riesgos y amenazas a que están
expuestos los procesos, el personal y la tecnología en su conjunto.
2. Generar un plan integral de contingencia, en cumplimiento de la Res. SGP 45/05.
Página 42
3. Actualizar los procedimientos de contingencias señalados de acuerdo a lo establecido en
la referida norma.
4. Aprobar formalmente los procedimientos de contingencias.
Seguridad Física
6.16 Objetivo de Control: Seguridad Física
4.16.1 Registración de los Accesos en Salas de Servidores SLU - Mecon / Sitio de
procesamiento anexo Utilizar un libro rubricado donde se detallen los datos de las visitas y firmas correspondientes.
Unificar los procedimientos de ingreso al CPD entre lo indicado en la norma (Política de acceso
a zonas restringidas) y lo cumplimentado por el área de control de acceso al organismo.
6.16.2 Registración de los accesos en Sala de Servidores SLU - Área Proyecto “Informática
del Mecon” Utilizar un libro rubricado donde se detallaran los datos de las visitas y firmas correspondientes.
6.17 Objetivo de Control: Protección contra Factores Ambientales
6.17.1 Cerramientos en Centros de Procesamiento de Datos – UI / Área Proyecto
“Informática del Mecon” Evaluar los cerramientos perimetrales del CPD, como así también las puertas y ventanas con
respecto a la resistencia al fuego e impactos.
6.17.2 Bolsas de residuos - Recipientes de residuos en Centro de Procesamiento de Datos
UI Las bolsas de residuos deben ser transparentes para que se pueda ver lo que se retira. Los
recipientes de residuos deben ser incombustibles y tener tapa.
Página 43
6.17.3 Cables desordenados en Centros de Procesamiento de Datos – UI / Sitio de
procesamiento anexo Ordenar los cables que están debajo del escritorio ubicado en el taller de reparaciones, y los que
están detrás de los equipos que se encuentran en los gabinetes (racks). Generar normas y
procedimientos para la conexión de los equipos informáticos.
6.17.4 Interruptores eléctricos en los equipos de aire acondicionado de los Centros de
Procesamiento de Datos – UI / Sitio de procesamiento anexo / Área Proyecto “Informática
del Mecon” Instalar en la puerta principal controles eléctricos de emergencia accesibles al operador –
interruptores de corte de energía eléctrica (equipos, iluminación, etc.) y de los equipos de aire
acondicionado. Además, deben estar protegidos contra posibles accionamientos accidentales y
sabotajes, entre otros.
6.17.5 Sistema de extinción en los Centros de Procesamiento de Datos – UI / Área Proyecto
“Informática del Mecon” Evaluar la instalación de un sistema de extinción de incendios en las salas de servidores
correspondientes.
6.17.6 Matafuegos en los Centros de Procesamiento de Datos – UI / Sitio de procesamiento
anexo / Área Proyecto “Informática del Mecon” Realizar un plan para controlar que los matafuegos no estén vencidos. Controlar los matafuegos
y llevar un registro eficiente. Colocarlos en el soporte correspondiente e instalar un extintor en el
Sitio de procesamiento anexo – Edificio AFIP.
6.17.7 Simulacros en Centros de Procesamiento de Datos – UI /
Área Proyecto
“Informática del Mecon” Realizar los simulacros de evacuación.
Página 44
6.17.8 Sistema de audio en los Centros de Procesamiento de Datos – UI / Área Proyecto
“Informática del Mecon” Instalar un sistema de audio para usarlo en caso de emergencia.
6.17.9 Luces de emergencia en los Centros de Procesamiento de Datos – UI / Sitio de
procesamiento anexo / Área Proyecto “Informática del Mecon” Instalar luces de emergencias autónomas.
6.17.10 Planos del sistema de instalación de control de temperatura y humedad de la sala
principal de servidores y planos del sistema de instalación de control de temperatura
correspondiente al local de ingreso - Centro de Procesamiento de Datos – UI –
Realizar y mantener actualizados los planos del sistema de instalación de control de temperatura
y humedad de la sala principal de servidores. Ídem para el sistema de instalación de temperatura
correspondiente al local de ingreso.
6.17.11 Planos de la instalación eléctrica - Centro de Procesamiento de Datos UI –
Mantener actualizados los planos de la instalación.
6.17.12 Contrato de mantenimiento de los sistemas de control de temperatura y humedad
- Centro de Procesamiento de Datos UI –
Debe estar aprobado formalmente, indicando el nombre de la empresa encargada del
mantenimiento del sistema y la fecha de inicio y finalización del servicio.
6.17.13 Plan de mantenimiento de los sistemas de control de temperatura y humedad
- Centro de Procesamiento de Datos UI –
Debe estar aprobado formalmente indicando las fechas de ejecución de las tareas.
6.17.14 Tomacorrientes - Centro de Procesamiento de Datos UI –
Los tomacorrientes deben ser incombustibles y cumplir con la reglamentación vigente de las
instalaciones eléctricas.
6.17.15 Humedad en paredes y cielo raso - Sitio de procesamiento anexo Realizar las reparaciones para evitar el ingreso de humedad en esta área.
Página 45
6.17.16 Normas y procedimientos para el mantenimiento de la instalación eléctrica - Sitio
de procesamiento anexo Respetar las normas y procedimientos para el mantenimiento de la instalación eléctrica.
6.17.17 Registros de los controles de las instalaciones eléctricas - Sitio de procesamiento
anexo Llevar un registro de los controles de las instalaciones eléctricas.
6.17.18 Instalación de la puesta a tierra y mediciones - Sitio de procesamiento anexo Verificar la instalación de la puesta a tierra y realizar las mediciones según lo establecido por la
normativa vigente (medición anual de la puesta a tierra).
6.17.19 Orden y limpieza en el acceso al sitio - Sitio de procesamiento anexo Mantener limpias y ordenadas las vías de acceso al local del sitio de procesamiento.
6.17.20 Limpieza en Centro de Procesamiento de Datos – Área Proyecto “Informática del
Mecon “ Hacer aprobar el procedimiento de limpieza por autoridad competente y comunicarlo al personal
afectado, que deberá cumplirlo.
El procedimiento debe indicar las tareas específicas para un centro de cómputo.
6.17.21 Locales linderos - Protección contra incendios – Centro de Procesamiento de Datos
del Área Proyecto “Informática del Mecon” Realizar una evaluación del riesgo de incendio en los locales linderos a la sala de servidores.
6.17.22 Plan de mantenimiento de las instalaciones eléctricas – Centro de Procesamiento de
Datos del Área Proyecto “Informática del Mecon” Elaborar un plan de mantenimiento de las instalaciones eléctricas y elevarlo a la autoridad
competente para su aprobación.
6.17.23 Instrucciones de cómo actuar en un incendio – Centro de Procesamiento de Datos
del Área Proyecto “Informática del Mecon”En la sala de servidores debe haber, a la vista, instrucciones de cómo actuar en caso de incendio.
6.17.24 Capacitación – Centro de Procesamiento de Datos del Área Proyecto “Informática
del Mecon “
Página 46
Capacitar y entrenar en forma semestral al personal de la sala de servidores en el manejo de los
matafuegos.
6.17.25 Plan de emergencia y evacuación – Centro de Procesamiento de Datos del Área
Proyecto “Informática del Mecon “ Elaborar un plan de emergencia y evacuación específico para la sala de servidores.
6.17.26 Salida de emergencia – Centro de Procesamiento de Datos del Área Proyecto
“Informática del Mecon “ El local debe tener una puerta de emergencia.
6.17.27 Sitio alternativo al Centro de Procesamiento de Datos del Área Proyecto
“Informática del Mecon “ Instalar un sitio alternativo.
6.17.28 Filtración de agua – Centro de Procesamiento de Datos del Área Proyecto
“Informática del Mecon “ Evaluación de riesgos de las instalaciones externas (agua, gas, entre otros.) a la sala de
servidores y protección del local ante eventuales siniestros (ejemplo: pérdidas de cañerías
próximas al local).
CONCLUSIONES
El Sidif Local Unificado es el último de los sistemas de gestión presupuestaria y contable de que
disponen los organismos de la administración pública nacional. El diseño y el desarrollo fueron
concebidos desde la Unidad Informática y los órganos rectores de la Subsecretaría de
Presupuesto.
El sistema en la Administración Central ha sido adoptado por 56 organismos sobre 100, a mayo
de 2005. Este nivel de aceptación está basado principalmente, a nuestro criterio, en las
funcionalidades que provee y en el compromiso en el proyecto de los principales directivos de la
Subsecretaría.
Página 47
Se encontraron fallas en la consideración al usuario durante el proceso de réplicas o
implementación, en las etapas de inicio –en algunos organismos faltaba el acta de acuerdo- y
cierre -falta de aprobación formal de los responsables operativos del sistemaNuestros hallazgos confirman la inercia de la UI para modificar falencias observadas en
anteriores auditorías. El nivel de informalidad que caracteriza la gestión se traduce en brechas
como falta de integración en algunas etapas del ciclo de vida, la falta de aprobación formal de
sus iniciativas y la carencia de asignación de responsabilidades debidamente delimitadas para
ejercer un control que garantice y/o mejore la calidad del sistema de producción, lo que le impide
controlar con eficacia todo el ciclo de producción.
Todo ello se produce en un marco de escasa inversión en herramientas de gestión –sistemas– que
faciliten la administración de los complejos sistemas de contabilidad gubernamental en su ciclo
de vida y permitan un mejor control.
A este cuadro se suma el escaso aporte en el control del SLU de la Dirección de Auditoría de
Sistemas.
En cuanto a la seguridad física, se reiteran observaciones sobre vulnerabilidad realizadas en
anteriores informes. Se relevaron procedimientos de contingencias parciales sin un marco
apropiado que asegurase la continuidad del servicio.
Por último, es de señalar que en el actual esquema de SLU (ver fig. 1, pág. 12) subsiste el viejo
modelo de procesamiento de los anteriores Sidif locales, ya que si bien el “front end” (aplicativo
y motor de la base local entre otros) se provee con tecnología actual, no ocurre lo mismo con el
“back-end” (Transaf y base de datos central, entre otros). Esto es:
1) La versión del motor de la base de datos central ya no dispone de soporte técnico.
2) Se emplea un procesamiento adicional pasando por varios servidores. La comunicación entre
Página 48
las bases local y central se realiza vía Transaf a pesar de que ambas bases están radicadas en la
SH, a diferencia de las anteriores versiones del Sidif local –que permiten al organismo remitir
sus transacciones en forma remota para la aprobación en sede central-.
3) Redundancia en el almacenamiento. Las transacciones se almacenan tanto en la base central
como en la base local.
No obstante, el viejo modelo habría demostrado un funcionamiento sólido y seguro.
A nuestro juicio, este esquema solo debe considerarse como una instancia provisoria. El nuevo
esquema debe superar las contradicciones presentadas pues se producen, cuando menos, retardos
para actualizar la BD central y costos de mantenimiento de una infraestructura innecesaria.
6. LUGAR Y FECHA DE LA EMISION DEL INFORME:
Buenos Aires, diciembre de 2005
FIRMA:
Página 49
Página 50