El Peor Escenario

Hola! Bienvenidos a Iseries Venezuela. 

Que sea un año  venturoso y lleno de dicha y progreso para todos!

En esta oportunidad veremos maneras de proteger nuestro esfuerzo y trabajo como Gerentes de Sistemas, comenzando un nuevo año con buen pie!.

Muchos millonarios una vez que han acumulado una gran masa de dinero deben pensar en alternativas para proteger y salvaguardar sus bienes. Una mala inversión puede ser desastrosa como ha ocurrido con Donald Trump. Aprendida la lección, muchos de ellos utilizan la técnica de  imaginar el peor escenario que puede ocurrir y tomar medidas preventivas contra eso. Una vez cubiertas todas las bases que comprenden el peor escenario, la operativa de los negocios continúa sin mayores riesgos financieros.

Desde el punto de vista de desarrollo de software podemos imaginar el peor escenario y protegernos contra eso.

Factores que, en mi opinión,  deben ser considerados en el Peor Escenario.

1.-Perdida, corrupción o inconsistencia de la data.

Acciones preventivas:

• ·        Revisar Periodicidad de los Backups.
• ·        Reprocesamientos recurrentes.
• ·        Revisar memoria y discos.
• ·        Definición de Journals/diarios de los archivos.
• ·        Auditoría regular de la data.

2.-Pérdida de Archivos Fuentes.

Acciones preventivas:

•  Compilar los fuentes de ILE dbgview(*ALL) o dbgview(*LIST) estos valores permiten recuperar un fuente RPGLE o SQLRPGLE. En este enlace pueden descargar las utilidades para recuperar fuentes y muchas otras utilidades más. 

Recuperación de Fuentes y otras Utilidades

3.-Reprocesamiento

Acciones preventivas:

• Mantener una estadística de procesos que fallan repetidamente y tomar las medidas correctivas lo antes posible. Un proceso inestable es una fuente de riesgo importante para la operatividad del negocio

4.-Seguridad de Acceso.

Acciones preventivas:

•  Revisar regularmente quién hace qué.

Hay empleados que se han retirado de la empresa y sin embargo, pasado cierto tiempo conservan sus claves y usuarios de acceso, así como los objetos ejecutables que dejaron en disco. Otros empleados son trasladados a distintas sucursales del negocio o a distintos puestos de trabajo con otras funciones diferentes a las que estaban haciendo anteriormente y sin embargo conservan el acceso al sistema con el cargo anterior mas la nueva clave o usuario del cargo actual.

5.-Actualización de Licencias.

Acciones preventivas:

• ·        Revisar el vencimiento de las licencias oportunamente.

Justamente al momento de realizar una entrega con carácter de urgencia aparece el mensaje de Ibm advirtiéndonos de que ciertas funciones o comandos no se pueden ejecutar. Para evitar este inconveniente, tener un calendario de vencimiento de licencia por equipo y producto instalado para renovar la licencia a tiempo.

• ·        Revisar si es necesario ampliar el número de licencias por expansión del negocio.

Nos acostumbramos a que fulano tenga acceso al uso de x producto y vamos pasándonos la clave de unos a otros, porque la tarea debe realizarse con los recursos que se tiene y “como sea”. Esto representa un riesgo innecesario de seguridad. Empleados con menos jerarquía de acceso pueden obtener información confidencial del negocio.

6.-Fraudes.

Acciones preventivas:

• ·        Monitorear los horarios de accesos del personal a los sistemas y evaluar el perfil estadístico para detectar cual acceso se ha salido del comportamiento normal.
• ·        Adquirir software especializado para detección de fraude.
• ·        Atomizar los procesos al asignarlos a los empleados de informática.

Esta “solución” tiene detractores y fanáticos. Sin embargo, la expongo aquí porque existe como opción y está siendo aplicada en varias organizaciones. Hay instituciones que fragmentan el conocimiento de un proceso en partes muy específicas a fin de que los analistas de sistemas solo vean sub-módulos o programas de distintas áreas del negocio sin conexión lógica entre sí.

Este procedimiento procura evitar el fraude interno pero tiene el inconveniente de que a la hora de resolver un problema por falla o caída del sistema,  no se cuenta con un profesional capaz de hacer frente a la situación dado el desconocimiento integral del proceso o los procesos involucrados en el problema.

Si te pareció interesante, reenvíalo a un amigo haciendo click en el sobrecito que está al final del artículo. El conocimiento es valioso, compártelo. 

Autor: Ing. Liliana Suárez