Estructura para auditoria interna

[jllinas]

Hola a tod@s,

He estado buscando un poco sobre como mejorar las actuales facilidades de auditoría interna que tienen nuestros sistemas, y la verdad es que lo que tengo me ha apoyado mucho, pero siempre busco mejorarlo.

Todas las actividades que hace todo usuario son almacenadas en un archivo LOG, con la siguiente estructura:

Code: Select all  Expand view

Structure for database: C:\db3\db3p\ss\conta1\datos\coopmad\logact.dbf
Number of data records:      29
Date of last update   : 04/14/10
Field  Field Name  Type       Width    Dec
    1  IDENTIF     Character      4
    2  FECHAC      Date           8
    3  HORA        Character     10
    4  OPC         Character     60
** Total **                      83

Donde IDENTIF es el código del usuario que hace la actividad, FECHAC es la fecha en la cual lo realiza, HORA es lo evidente y OPC es la descripción o resumen de la accion que realiza el usuario, tal como "AGREGAR el Cliente No. 883", o "MODIFICAR el Ahorrante No. 138", etc.

Con una pequeña función que se llama al final exitoso de cada operacion, se abre esta tabla, se crea un nuevo registro y se cierra.

La pregunta es: Alquien ha trabajado o tiene esto?, que otras variables han considerado como importantes para incluir en esta estructura? El IP de la maquina?, el usuario del equipo?.... no se quiero escuchar a los gurus...

Abrazos a todos,

[MauroArevalo]

Julio:

Yo le agregaria un campo adicional (tipo caracter .. 100 o 150 ) en donde guarde el dato anterior del registro en caso de modificación y asi se podria comparar el dato modificado con el original.

Yo utilizo mucho ese control pero a diferencia tuya, no tengo un DBF aparte, si no que se le agrego a todas mis DBFs los campos de control de usuarios.

Saludos

[Ariel]

Julio,

yo guardo en una dbf x dia 1 registro, y tengo un memo dnd voy escribiendo cada accion q hacen en ese dia, cada usuario, ahora estoy migrando a mysql y voy a convertir en 1 registro x operacion. cada renglon del memo tiene : hora, terminal, usuario, accion.

espero te sirva.

Salu2, Ariel.

[jllinas]

Hola,

Gracias Mauro. Aún me parece mejor guardar todo en una tabla aparte, y no en la misma que se ha modificado.

Ariel: ¿Como obtengo la identificacion de la terminal que ejecutó la acción?

Abrazos,

[Manuel Valdenebro]

Julio,

En cada estacion, yo tengo una dbf (estacion.dbf) con un solo registro y varios campos (path servidor, nombre maquina, codigo usuario,....)

Cuando un usuario entra en la aplicación y autentifica su codigo/clave en el servidor, cambio en la dbf local (que esta abierta en exclusive) el código del usuario.

Tengo una sola dbf para llevar el control del usuario. Uno de los campos es el codigo del usuario otro la máquina, ambas informaciones las saca del fichero estacion.dbf.-

En el fichero de control, incluso anoto los intentos de entrar en la aplicación, porque en alguna ocasión un usuario ha intentado entrar con la clave de otro.

Cambiando de tema. Me gustaria contactar directamente contigo para hablar del tema del GPRS. ¿Puedes enviarme un correo a valdenebro arroba mixmail.com ?

[Marcelo Via Giglio]

Hola,

como todos tengo algo similar, como siempre aqui en el trabajo tienden a decir que debe ser un error del sistema, entonces hice algo similar

usuario
ip
fecha
hora
operacion
tabla
id (odentificador del reg, llave primaria)
informacion

en la informacion se guarda, cierta informacion que es la mas critica del registro, esta informacion esta en un diccionario donde se definen los campos importantes para cada tabla, la forma de guardar la informacion es:

para una alta o eliminacion

campo1 : valor
campo2 : valor
....
campon : valor

para una modificacion

campo1 : valor_ant => valor_nuevo
campo2 : valor_ant => valor_nuevo
.....
campon : valor_ant => valor_nuevo

puede resultar redundante en el caso de las modificaciones, ya que se puede hilar toda la historia del registro y saber sus valores historicos
pero por ahora esta asi

Intente hacer algo mejor y automatico con ADS ya que maneja triggers incluso en modo local, pero el problema es como saber la informacion del usuario dentro el trigger, todo lo demas se tienes, el registro la fecha y hora, pero no supe como meter el nombre del usuario, si eso seria posible tendriamos un logging system sin hacer casi nada

bueno esta es mi experiencia

saludos

Marcelo

[Patricio Avalos Aguirre]

Hola Marcelo

Podrias explicar un poco de los triggers en ADS, me interesa saber como funcionan

desde ya muchas gracias...

[mmercado]

Hola Julio

Ariel: ¿Como obtengo la identificacion de la terminal que ejecutó la acción?

Abundando un poco a otras sugerencias, en mis logs de auditoría yo uso dos datos que resultan de gran utilidad (cWinUserName y cComputerName), para obtenerlos agrega el siguiente código a tu programa principal:

Code: Select all  Expand view

#pragma BEGINDUMP
#include <tchar.h>
#include <hbapi.h>
#include <windows.h>
#define MAX_USER_NAME 128

HB_FUNC( CCOMPUTERNAME )
{
   DWORD lwMax = MAX_COMPUTERNAME_LENGTH ;
   TCHAR hostname[ MAX_COMPUTERNAME_LENGTH + 1 ] ;
   GetComputerName( hostname, &lwMax ) ;
   hb_retc( hostname ) ;
}

HB_FUNC( CWINUSERNAME )
{
   TCHAR cusername[ MAX_USER_NAME + 1 ] ;
   DWORD wLen = MAX_USER_NAME ;
   GetUserName( cusername, &wLen ) ;
   hb_retc( cusername ) ;
}
#pragma ENDDUMP
 

Un abrazo.

[wmormar]

amigos,

con:

Code: Select all  Expand view

? netname()
? netname(.t.)

te muestra el usuario de windows o el nombre dado a la computadora

esto en xharbour

[Ariel]

Estimados,

Como dice William, simplemente con NETNAME() obtenemos el nombre de la pc, con esto me es + q suficiente.

Salu2, Ariel.

[Marcelo Via Giglio]

Patricio,

casi todas las DB tienes triggers, incluso con FIVEDB si no me equivoco se implementaron para los DBF, dek manual que viene en ARC, copio lo siguiente

A trigger is a piece of code (similar to a stored procedure) that is executed on the server. Triggers differ from stored procedures because triggers are not called by the client, but instead are executed automatically in response to an insert, update, or delete operation.
Triggers are supported for both SQL and navigational update operations. Throughout this documentation the update operations will be specified using uppercase notation (for example, INSERT), but this does not imply an SQL-only limitation.

When a trigger is "fired" it contains some state information, which can be used inside the body of the trigger. Two in-memory tables are available inside a trigger; a __new table and an __old table. The __new table contains new field values that were, or are about to be, inserted into the table. The __old table contains old field values for the record in question.
Triggers can provide a very powerful means to maintain business rules inside of a database.
Triggers can be defined for any supported table type, and are not limited to the proprietary ADT format.

Both the Advantage Database Server and the Advantage Local Server support triggers. Implicit Transactions are the only trigger functionality that differ depending on server type.
Trigger support is a server-side feature. Any Advantage client version 6.0 or greater capable of opening a dictionary-bound table can utilize triggers. This can be beneficial if you want to add trigger support to your application, but don’t want to upgrade your client applications. Only the database server needs to be upgraded (to Advantage version 7.0 or greater) in order to start using triggers.

La idea para el logging system es por cada operacion de alta, baja, modificacion tengas definido un trigger que pase la informacion del registro a otra tabla marcando si era nuevo, modificado, eliminado, todo ok, pero el problema seria mandar el usuario del sistema (no el de la base de datos).

La idea de un trigger es que se dispare antes, depues o en lugar de la operacion, asi puedes automatizar muchas operaciones como borrado en cascada, etc.

COn ek ARC, oprimes boton derecho sobre la tabla de una DB y podras definir los triggers para esa tabla.

Espero sirva de inicio para lo que buscas

saludos

Marcelo

[jllinas]

Bueno.... voy con lo mio:

- Gracias Maestro Mercado.

- Ya agregué los dos campos a la estructura de mas arriba: UAN (User Account Name) y CN (Computer name). Para los interesados, busque en Google, y para ambos está bien definirlos como campos Character de 20 (aunque CN puede ser de 15).

- Agregue el uso de estos valores con la función NetName() y NetName(.T.) de xharbour, a mi función de Auditoría Interna.

- Todo resultó perfectamente bien. Gracias a todo por su apoyo !

Abrazos,