Lextedit por su gran capacidad de ejecución que tiene de comandos y uso de conexiones directas a los servidores sin importar la arquitectura es contemplado en muchas organizaciones como un software de alto riesgo, y por tal motivo ha llegado a ser bloqueado en muchas organizaciones, incluso me he encontrado en donde puede llegar a ocasionar una multa con penalización financiera el uso de dicho software.
Siendo este un programa tercero no certificado para su uso con JDA y no recomendado por JDA no se encuentra de manera estándar auditado en la tabla de sys_audit.
En una instalación nueva del WMS de JDA la herramienta solo audita las siguientes aplicaciones en ejecución de queries: MSQL, server command operations y WINMSQL, por lo tanto todo aquel usuario que se conecte desde lextedit y ejecute comandos, queries, etc no será auditado y los administradores de la herramienta no podrán dar trazabilidad y seguimiento sobre todo aquello que sea ejecutado desde la herramienta.
Imagen 1: Extracto de la tabla sys_audit sin auditoria de lextedit
Como podemos observar en la imagen 1 mi usuario se encuentra conectado desde lextedit y se encuentra realizando consultas a la base de datos, en este caso a la tabla de sys_audit, y en el registro que se tiene de auditoria solo se encuentran registros de Login succeeded pudiendo esto ser un problema de seguridad en caso de que el usuario ejecute un Delete o un Update no deseado no será auditado e identificado desde la aplicación.
Activación de la auditoria a LextEdit
La auditoria a lextedit puede ser habilitada de 2 maneras, desde query o desde la aplicación, mostraré ambas opciones.
1.- Desde la aplicación:
Para continuar con el aprendizaje es necesario realizar una donación a patreon por medio del siguiente link:
Auditar las ejecuciones de Lextedit | Dave Toledo on Patreon
Saludos.
theworldofmoca.wordpress.com 
Super conocer esta configuración
Me gustaMe gusta
Excelente blog ,espero y siga en pie tu interes por compartir este conocimiento :)))
Me gustaLe gusta a 1 persona
Seguire subiendo información, solo que por el momento no he encontrado nada interesante para compartir, igual si tienes un tema de interés hazmelo saber y hablo de ese tema. Saludos
Me gustaLe gusta a 1 persona
David buen día. Esta configuración también se puede realizar para auditar las acciones que realice el usuario desde la WEB o el Cliente? Por ejemplo: “El usuario registra un nuevo proveedor o actualiza atributos de Item?
Me gustaMe gusta
Cuando alguien modifica o crea datos haciendo uso de la aplicación los nombres de usuario de quien modifico dichos registros se almacenan en la base de datos en las columnas de last updated user y de ins user junto con la fecha de modificación y creación.
Me gustaMe gusta
Si correcto, en ello tienes razón. La inteción de la pregunta es que si la política APPS-TO-AUDIT se podía personalizar también en el uso de la web y cliente. Muchas gracias por el aporte, ya lo tengo implementado.
Me gustaMe gusta
El uso de la politica es solo para monitorear ejecuciones de comandos moca y de SQL que se hacen desde aplicaciones conectadas a la base de datos por medio de la URL de servicio, ejecuciones desde el cliente en «Server Command Operations» son auditadas al igual que todas las herramientas que se conectan con dicha URL como lo son WinSql y LextEdit, segun mi experiencia
aún no existe un «Server Command Operations» o algun cliente Web que permita la ejecución de queries y comandos moca si en un futuro no muy lejano llegara a existir se podrá auditar con su identificador de aplicación.
Me gustaMe gusta
Muchas gracias David!!!
Me gustaMe gusta
Hola David, Como se puede identificar la applicacion? Como por ejemplo si estoy utilizando Oracular. (appl_id) y quiero crear la poliza?
Me gustaMe gusta