AUDITORÍA IBM i (AS400)

¡Claro que sí! Realizar una auditoría completa de un sistema IBM AS/400 (ahora conocido como IBM i) es crucial para mantener la seguridad, la integridad de los datos y el cumplimiento normativo. Es un proceso que requiere conocimiento técnico y metodológico. Esta guía te llevará paso a paso por los aspectos clave de una auditoría, desde la configuración hasta la interpretación y las mejores prácticas.

1. ¿Qué es una Auditoría al AS/400?

Una auditoría al AS/400 (IBM i) es un examen sistemático y objetivo de los controles de seguridad, la configuración del sistema, los patrones de uso y la gestión de datos dentro de la plataforma IBM i. Su objetivo principal es asegurar que el sistema esté configurado y se utilice de manera segura y eficiente, cumpliendo con las políticas internas y las regulaciones externas.

• Definición de auditoría técnica y de seguridad en entornos IBM i:

• Auditoría Técnica: Se enfoca en la revisión de la configuración del sistema operativo (IBM i), la gestión de recursos (CPU, disco), el rendimiento, la gestión de copias de seguridad y recuperación, y la operación general del sistema. Busca eficiencia y estabilidad.
• Auditoría de Seguridad: Esta es la más crítica. Se centra en identificar vulnerabilidades, evaluar la efectividad de los controles de acceso, rastrear actividades sospechosas, asegurar la integridad de los datos y garantizar que solo los usuarios autorizados tengan acceso a los recursos adecuados. Esto incluye revisar perfiles de usuario, autorizaciones a objetos, configuraciones de red, logs de auditoría y políticas de contraseñas.

• ¿Por qué es importante auditar regularmente el sistema?

1. Detección de Vulnerabilidades: Identifica debilidades en la configuración que podrían ser explotadas por atacantes internos o externos.
2. Prevención de Fraudes: Ayuda a detectar y prevenir actividades maliciosas, uso indebido de recursos o manipulación de datos por parte de usuarios internos.
3. Cumplimiento Normativo: Es esencial para cumplir con regulaciones como ISO 27001, SOX, HIPAA, PCI-DSS, GDPR, entre otras, que exigen controles estrictos sobre la seguridad de la información.
4. Integridad de los Datos: Asegura que los datos críticos no sean modificados o accedidos sin autorización.
5. Optimización del Rendimiento: A veces, las auditorías técnicas pueden revelar configuraciones ineficientes que afectan el rendimiento.
6. Control de Cambios: Permite verificar que los cambios en el sistema se realicen de manera controlada y autorizada.
7. Preparación ante Incidentes: Los logs de auditoría son vitales para investigar y responder a incidentes de seguridad.

2. Requisitos Previos

Antes de iniciar una auditoría, es fundamental tener los permisos y herramientas adecuadas.

• ¿Qué perfil o autoridad necesita el auditor? Para realizar una auditoría completa, el auditor necesita privilegios elevados para acceder a toda la información del sistema. Los perfiles con estas capacidades son:

• *SECADM (Security Administrator): Permite gestionar la seguridad del sistema, incluyendo perfiles de usuario, políticas de contraseñas y el control de auditoría. Es indispensable para configurar y desactivar la auditoría.
• *AUDIT: Autoridad de auditoría. Permite acceder y manipular los datos del journal de auditoría (QAUDJRN). Un auditor NO debe tener *ALLOBJ si el objetivo es solo auditoría de logs, para evitar potenciales conflictos de interés o riesgos de seguridad.
• *ALLOBJ (All Object Authority): Autoridad para acceder a todos los objetos del sistema, independientemente de sus autorizaciones específicas. Es una autoridad muy potente y debe usarse con extrema precaución y solo si es estrictamente necesario. Un auditor externo NUNCA debería tener *ALLOBJ de forma permanente. Para una auditoría inicial, puede ser requerido para revisar configuraciones sensibles de objetos, pero debe ser revocado inmediatamente después.

Recomendación: Lo ideal es que el auditor tenga un perfil con *SECADM y *AUDIT, y se le conceda temporalmente acceso a *ALLOBJ solo cuando sea indispensable para revisar configuraciones muy específicas, siempre con supervisión.

• ¿Qué herramientas nativas se utilizan (por ejemplo, comandos como DSPAUDJRNE, DSPUSRPRF)? IBM i provee una suite robusta de comandos y objetos para la auditoría:

• DSPAUDJRNE (Display Audit Journal Entry): Muestra las entradas del journal de auditoría. Es la herramienta principal para revisar eventos de seguridad.
• CPYAUDJRNE (Copy Audit Journal Entry): Copia entradas del journal de auditoría a un archivo de base de datos para un análisis más profundo. Es crucial para generar informes.
• DSPUSRPRF (Display User Profile): Muestra información detallada de un perfil de usuario.
• WRKUSRPRF (Work with User Profiles): Permite listar y trabajar con perfiles de usuario.
• DSPJOB (Display Job), WRKJOB (Work with Job): Para revisar trabajos y sesiones activas.
• DSPLOG (Display Log): Muestra el historial del sistema (QHST).
• WRKSYSLOG (Work with System Log): Si el syslog está configurado.
• DSPOBJAUT (Display Object Authority): Muestra las autorizaciones a un objeto específico.
• WRKAUTL (Work with Authorization List): Para revisar listas de autorización.
• WRKSYSVAL (Work with System Values): Para revisar y configurar parámetros del sistema.
• WRKOBJPDM (Work with Objects by PDM): Permite trabajar con objetos en una biblioteca, útil para listar objetos por tipo, fecha de cambio, etc.
• DSPFD (Display File Description), DSPDBR (Display Database Relations): Para revisar información de archivos de base de datos.
• IBM Navigator for i: Una interfaz gráfica web que simplifica el acceso a mucha de esta información y permite exportarla.

• ¿Cómo activar el sistema de auditoría (QAUDCTL, QAUDLVL, QAUDLVL2)? El sistema de auditoría de IBM i se controla mediante valores de sistema:

• QAUDCTL (Audit Control): Controla si la auditoría del sistema está activa.

• *NONE: Auditoría inactiva.
• *AUDIT: Auditoría activa, registros escritos en QAUDJRN.
• *NOQTEMP: La auditoría no se detiene si no hay espacio para el receptor de journal.
• *NOJOBEND: Un trabajo no termina si la auditoría está llena.

• QAUDLVL (Audit Level): Define qué tipos de eventos se auditarán a nivel global (sistema, seguridad, acceso a objetos).
• QAUDLVL2 (Audit Level 2): Añade categorías de auditoría más granulares, especialmente para eventos de bases de datos.

3. Pasos para Configurar la Auditoría del Sistema

Una auditoría efectiva comienza con una configuración adecuada. Asegúrate de tener los permisos *SECADM.

1. Activar el sistema de auditoría con CHGSECAUD: Este comando es el punto de inicio para la auditoría de seguridad.
   CHGSECAUD AUDLVL(*AUDIT)
   Este comando asegura que el sistema esté configurado para enviar eventos de auditoría al journal de auditoría.
2. Configurar los niveles de auditoría (QAUDLVL, QAUDLVL2): Estos valores de sistema determinan qué tipos de eventos se registran. Debes ser muy selectivo, ya que un nivel de auditoría muy alto puede generar un volumen excesivo de datos.
   WRKSYSVAL QAUDLVL     -- Para ver el valor actual
   WRKSYSVAL QAUDLVL2    -- Para ver el valor actual
   Para cambiarlos:
   CHGSYSVAL SYSVAL(QAUDLVL) VALUE('*ALL') -- Audita casi todo (¡Precaución!)
   CHGSYSVAL SYSVAL(QAUDLVL2) VALUE('*ATADAP *AUTFAIL *PGMFAIL *SYSCFG *ALL *NONE')
   Valores de QAUDLVL comunes para auditoría de seguridad:

• *AUDIT: Eventos de auditoría de seguridad del sistema (cambios de perfil, etc.).
• *AUTFAIL: Fallos de autorización a objetos.
• *CREATE: Creación de objetos.
• *DELETE: Eliminación de objetos.
• *DLOCTL: Control de objetos de biblioteca de documentos.
• *PGMFAIL: Fallos de ejecución de programas.
• *SECURITY: Eventos relacionados con seguridad (cambios de contraseña, perfiles).
• *SERVICE: Uso de comandos de servicio (debug, etc.).
• *SPLFDAT: Acceso a datos de spool.
• *SYSCTL: Cambios en valores de sistema críticos.
• *SAVRST: Eventos de salvar y restaurar objetos.
• *NETSECURE: Eventos de seguridad de red.
• *DIRSRV: Eventos de servidor de directorio.

Valores de QAUDLVL2 para una auditoría más profunda (desde V6R1):

• *ATADAP: Acceso a datos de archivos físicos/lógicos. Muy granular y puede generar mucho volumen.
• *AUTFAIL: Fallos de autorización (duplicado de QAUDLVL).
• *PGMFAIL: Fallos de ejecución de programas (duplicado de QAUDLVL).
• *SYSCFG: Cambios en la configuración del sistema.
• *ALL: Todas las categorías de QAUDLVL2 (¡genera un volumen inmenso!).
• *NONE: Ninguna.

Recomendación de inicio para auditoría (selecciona cuidadosamente): QAUDLVL: *AUDIT *AUTFAIL *SECURITY *SYSCTL *SAVRST *CREATE *DELETE QAUDLVL2: *ATADAP (solo si necesitas auditoría de acceso a datos a nivel de registro, lo que genera muchísimo journal), *SYSCFG

3. Crear y asignar el journal receptor (QAUDJRN, QSYS/QAUDRCV): Todos los eventos de auditoría se escriben en el Journal QAUDJRN en la librería QSYS. Este journal usa "receptores de journal" (journal receivers) para almacenar los datos. Es vital gestionarlos correctamente para evitar que el disco se llene.

• Crear un nuevo receptor de journal (si el actual está lleno o quieres rotar):
  CRTJRNRCV JRNRCV(QGPL/AUDRCV0001) THRESHOLD(250000) TEXT('Receptor de Journal de Auditoria')
  THRESHOLD define el tamaño en MB antes de que el sistema advierta que está casi lleno.
• Cambiar al nuevo receptor (si ya hay uno activo):
  CHGJRN JRN(QSYS/QAUDJRN) JRNRCV(QGPL/AUDRCV0001)
  
  
• Ver el estado del journal:
  WRKJRN JRN(QSYS/QAUDJRN)
  Aquí puedes ver los receptores activos y adjuntos.
• Guardar y borrar receptores antiguos: Los receptores de journal deben ser salvados regularmente y luego borrados del sistema para liberar espacio.
  SAVOBJ OBJ(AUDRCV0001) LIB(QGPL) DEV(*TAP) SAVF(*LIBL/MYSAVF) +
         OPTION(*ALL)
  DLTJRNRCV JRNRCV(QGPL/AUDRCV0001)
  ¡Advertencia! Nunca borres un receptor sin haberlo salvado y verificado que no está siendo usado por el journal.

4. Activar auditoría para perfiles específicos con CHGUSRAUD: Además de la auditoría a nivel de sistema, puedes auditar específicamente las acciones de usuarios individuales o grupos de usuarios, sin importar la configuración global de QAUDLVL.
   CHGUSRAUD USRPRF(JOHNDOE) USRPRFMSG(*AUDIT) OBJAUD(*ALL)
   
   

• USRPRFMSG(*AUDIT): Audita los accesos de este usuario al sistema.
• OBJAUD(*ALL): Audita todos los accesos del usuario a objetos.
• AUDITING(*USRPRF): Indica que las configuraciones de auditoría para este perfil son específicas del perfil.
• Valores de USRPRFMSG: *NONE, *AUDIT (éxito/fallo), *CHANGE (cambios en el perfil).
• Valores de OBJAUD: *NONE, *ALL (acceso a todos los objetos), *CHANGE (solo cambios), *USRPRF (usa la configuración del valor de sistema QAUDLVL).

Esto es útil para un seguimiento detallado de usuarios de alto privilegio o sospechosos.

4. Auditoría de Seguridad de Usuarios

Los perfiles de usuario son la primera línea de defensa.

• Detectar perfiles inactivos, sin contraseña, con privilegios innecesarios (DSPUSRPRF, WRKUSRPRF):
  WRKUSRPRF *ALL -- Lista todos los perfiles
  Para cada perfil (o un subconjunto):
  DSPUSRPRF USRPRF(PERFIL_USUARIO) OUTPUT(*PRINT)
  Revisa:

• STATUS: *DISABLED (deshabilitado) o *ENABLED (habilitado).
• PASSWORD: Si no hay contraseña (*NONE en algunos reportes), es una vulnerabilidad grave.
• MAXSIGNON: Número máximo de intentos de acceso fallidos.
• PWDEXP: Fecha de expiración de contraseña.
• TEXT: Descripción del perfil (debería ser clara y útil).
• ATTENTION: Si el perfil está siendo auditado a nivel de usuario.
• LMTCPB (Limit capabilities): Si es *YES, el usuario está restringido a un menú específico. Si es *NO, tiene acceso completo a la línea de comandos. Los usuarios comunes deben tener *YES o estar limitados por un menú.

• Revisar autoridad del perfil (*ALLOBJ, *IOSYSCFG, etc.): La autoridad especial de un perfil es crítica.
  DSPUSRPRF USRPRF(PERFIL_USUARIO) TYPE(*BASIC) OUTPUT(*PRINT)
  Busca Special authority y los valores:

• *ALLOBJ: Acceso a todos los objetos. MUY CRÍTICO. Solo administradores de sistema clave y con auditoría estricta.
• *SECADM: Administrador de seguridad.
• *AUDIT: Acceso a logs de auditoría.
• *IOSYSCFG: Configuración de I/O (dispositivos, comunicaciones).
• *JOBCTL: Control de trabajos.
• *SAVSYS: Salvado del sistema.
• *SPLCTL: Control de spool.
• Práctica recomendada: El principio de "mínimo privilegio" debe aplicarse rigurosamente. Los usuarios solo deben tener las autoridades que necesiten para realizar sus funciones.

• Auditoría de sesiones activas y comandos ejecutados:

• Sesiones activas:
  WRKACTJOB -- Muestra trabajos activos (incluyendo sesiones)
  Puedes filtrar por usuario (WRKACTJOB JOB(USER*)).
• Comandos ejecutados: Para un trabajo específico (por ejemplo, una sesión de usuario):
  DSPJOBLOG JOB(NOMBRE_TRABAJO/USUARIO/NUM_TRABAJO) OUTPUT(*PRINT)
  El joblog muestra los mensajes y comandos ejecutados por ese trabajo. Esto es muy útil para investigar actividades sospechosas en tiempo real o recientes.

5. Auditoría de Accesos y Uso del Sistema

La revisión de logs es el corazón de la auditoría.

• ¿Quién accedió y cuándo? Esta información se encuentra en el journal de auditoría.
• Accesos exitosos vs. Intentos fallidos: Eventos como PW (intento de inicio de sesión) y CP (inicio de sesión exitoso) son clave.

• PW - Failure to Validate Password (fallo de contraseña)
• CP - Profile Switched (cambio de perfil de trabajo)

• Revisión de logs: DSPAUDJRNE, DSPLOG, WRKSYSLOG

• DSPAUDJRNE (Display Audit Journal Entry): Es el comando principal.
  DSPAUDJRNE JRN(QSYS/QAUDJRN) JRNCDE((T)) ENTTYP(PW CP) +
             FROMTIME('080000') TOTIME('170000') +
             FROMDATE('070725') TODATE('070725') +
             OUTPUT(*PRINT)
  
  

• JRNCDE((T)): Para entradas de trabajo.
• ENTTYP(PW CP): Tipos de entrada (Password Validation, Change Profile).
• FROMTIME/TOTIME, FROMDATE/TODATE: Filtrado por fecha y hora.
• OUTPUT(*PRINT): Imprime el resultado. También puede ser *OUTFILE para analizarlo con SQL.

• DSPLOG (Display Log): Muestra el historial del sistema (QHST). No es tan detallado como el journal de auditoría para seguridad, pero contiene mensajes importantes del sistema.
  DSPLOG PERIOD((*AVAIL *BEGIN)) MSGID(CPF*) OUTPUT(*PRINT)
  Para ver mensajes de seguridad (ej. errores de acceso).
• WRKSYSLOG: Si tienes un syslog externo configurado, es una forma centralizada de recolectar logs de múltiples sistemas. IBM i puede enviar eventos de journal al syslog.

• Comandos críticos ejecutados por usuarios (CPYAUDJRNE): Para un análisis detallado, se deben copiar las entradas del journal a un archivo de base de datos.
  CPYAUDJRNE JRN(QSYS/QAUDJRN) JRNCDE((T)) ENTTYP(CD) +
             OUTFILE(QGPL/AUDIT_COMMANDS) +
             FROMDATE('070725') TODATE('070725')
  
  

• ENTTYP(CD): Indica "Comandos Ejecutados".
• OUTFILE(QGPL/AUDIT_COMMANDS): Crea un archivo DB donde se copiarán los datos.

Una vez copiado, puedes usar SQL para analizar:SELECT JSUSER, JSTIME, JSJOB, JSLIB, JSCPGM, JSDATA
FROM QGPL.AUDIT_COMMANDS
WHERE JSUSER = 'ADMINUSER' AND JSDATA LIKE '%DLT%'
ORDER BY JSTIME DESC;
Esto buscaría todos los comandos ejecutados por 'ADMINUSER' que contengan 'DLT' (por ejemplo, DLTLIB, DLTF).

6. Auditoría de Objetos del Sistema

Los objetos (programas, archivos, librerías) son los recursos que se deben proteger.

• Identificar cambios no autorizados en objetos: El journal de auditoría registra eventos como CO (cambio de autoridad de objeto), EO (cambio de objeto), DO (borrado de objeto), CR (creación de objeto).
  CPYAUDJRNE JRN(QSYS/QAUDJRN) JRNCDE((T O)) ENTTYP(CO EO DO CR) +
             OUTFILE(QGPL/AUDIT_OBJECTS) +
             FROMDATE('070725')
  Luego, usa SQL para filtrar por objetos críticos o usuarios no autorizados.
• Revisión de objetos sensibles: programas, archivos, bibliotecas (DSPOBJAUT, WRKOBJPDM):

• Objetos con autoridad pública excesiva (*PUBLIC *ALL o *CHANGE):
  WRKOBJPDM LIB(MYSENSITIVELIB) OBJTYPE(*ALL)
  Luego, usa la opción 5 para ver (DSPOBJD) y la opción 8 para ver la autoridad (DSPOBJAUT). Puedes usar DSPAUT para un objeto específico.
  DSPAUT OBJ(MYSENSITIVELIB/MYPGM) OBJTYPE(*PGM)
  Busca autorizaciones excesivas para *PUBLIC. Idealmente, *PUBLIC debería tener *EXCLUDE o *USE mínimo para objetos críticos.
• Autorización excesiva a bibliotecas del sistema (ej. QSYS, QGPL): Las bibliotecas del sistema deben estar protegidas rigurosamente.
  DSPAUT OBJ(QSYS) OBJTYPE(*LIB)
  DSPAUT OBJ(QGPL) OBJTYPE(*LIB)
  Verifica que *PUBLIC no tenga más de *USE en estas bibliotecas, y que solo usuarios específicos tengan autoridades como *ALL o *CHANGE.

• Revisar autorización pública (*PUBLIC) y listas de autorización (WRKAUTL):

• WRKAUTL *ALL: Muestra todas las listas de autorización.
• DSPAUTL AUTL(MYAUTHLIST): Muestra los usuarios y sus autorizaciones dentro de una lista específica.
• Las listas de autorización son una forma eficiente de gestionar la seguridad. Asegúrate de que las listas asignadas a objetos críticos estén bien definidas.

7. Auditoría de Bibliotecas y Programas Críticos

Aquí se busca integridad y control sobre el código ejecutable.

• Bibliotecas del sistema (QSYS, QGPL, QUSRSYS): Ya lo mencionamos, pero la auditoría debe verificar la inmutabilidad de estas bibliotecas y que no haya objetos no estándar o modificados.
  WRKOBJPDM LIB(QSYS) -- Para navegar y revisar objetos
  Es crucial que los usuarios no puedan crear ni modificar objetos en QSYS o QUSRSYS.
• Objetos modificados recientemente: Una técnica importante es buscar objetos modificados fuera de las ventanas de cambio autorizadas.
  WRKOBJPDM LIB(PRODLIB) OBJTYPE(*ALL) UPDDATE(*CURRENT) UPDTIME(*ALL)
  Filtra por fecha y hora de modificación para identificar objetos que cambiaron en horarios inusuales o sin control de cambios.
• Comparar integridad de programas con DSPPGMREF y DSPPGM:

• DSPPGMREF PGM(MYPGM): Muestra los objetos a los que se hace referencia en un programa (archivos, otros programas, etc.). Esto puede ayudar a detectar cambios en las dependencias.
• DSPPGM PGM(MYPGM): Muestra atributos del programa, incluyendo la fecha de creación/última modificación y el compilador utilizado.

Para una auditoría de integridad, se pueden usar herramientas de terceros que calculan hashes (checksums) de programas y objetos y comparan estos hashes a lo largo del tiempo para detectar cualquier modificación no autorizada.

8. Auditoría de Cambios de Configuración del Sistema

Los cambios en los parámetros del sistema pueden tener un impacto masivo en la seguridad y el rendimiento.

• Parámetros de sistema (WRKSYSVAL): Los valores de sistema (SYSVAL) controlan casi todo en el IBM i. Los cambios en ciertos SYSVAL deben ser auditados.
  WRKSYSVAL *ALL -- Lista todos los valores de sistema
  Valores críticos a revisar y auditar (evento TS en journal):

• QSECURITY: Nivel de seguridad del sistema (00-50). Un nivel bajo (20 o 30) es una gran vulnerabilidad. 40 o 50 son los recomendados.
• QPWDEXPITV: Intervalo de expiración de contraseña.
• QPWDMAXLEN: Longitud máxima de contraseña.
• QMAXSIGN: Máximo de intentos de inicio de sesión.
• QCCSID: Coded Character Set Identifier (importante para la integridad de datos).
• QLMTDEVSSN: Limita sesiones por dispositivo (útil para seguridad).
• QAUDCTL, QAUDLVL, QAUDLVL2: Ya vistos, fundamentales para la auditoría misma.
• QRMTSIGN: Controla accesos remotos.
• QDSPSGNINF: Muestra información de inicio de sesión.
• QMODEL: Tipo de sistema.
• QVLDLOBJ: Si los objetos se validan al restaurar.

• Cambios en comunicaciones, colas de trabajo, dispositivos: Los cambios en estas configuraciones también se registran en el journal de auditoría con tipos de entrada específicos. Por ejemplo, la creación (CR), borrado (DO) o cambio (CO) de descripciones de línea (LIND), controladores (CTLD), dispositivos (DEVD).

• Revisa el journal de auditoría buscando tipos de entrada relacionados con la configuración de red y dispositivos.

• Revisión de perfiles de dispositivos (impresoras, terminales): Asegúrate de que los dispositivos estén configurados correctamente y no permitan accesos no autorizados.
  WRKDEVD *ALL -- Trabaja con descripciones de dispositivos
  Verifica que los perfiles de usuario por defecto en dispositivos (SIGNON) no sean de alta autoridad.

9. Auditoría de Base de Datos y Acceso a Archivos

La base de datos (DB2 for i) es el corazón de la información empresarial.

• Archivos accedidos/modificados (DSPFD, DSPDBR):

• DSPFD FILE(MYLIB/MYFILE): Muestra la descripción de un archivo (número de registros, fecha de creación/modificación, etc.).
• DSPDBR FILE(MYLIB/MYFILE): Muestra las relaciones de un archivo con otros (lógicos, físicos).
• El journal de auditoría, con QAUDLVL2 *ATADAP, puede registrar cada acceso y modificación a nivel de registro en un archivo de base de datos. Esto genera un volumen masivo, por lo que solo se activa para archivos extremadamente sensibles y por periodos cortos.
• Las entradas RI (lectura de registro), RR (lectura de registro), RM (modificación de registro), RD (borrado de registro), RC (creación de registro) en el journal (JRNCDE(D)) son cruciales para la auditoría de datos.

• Seguimiento de operaciones sobre datos confidenciales:

• Identifica los archivos (tablas) que contienen información confidencial (ej. datos de clientes, salarios, información financiera).
• Configura la auditoría de objetos (CHGUSRAUD o CHGAUD) para esos archivos, o usa el nivel de auditoría *ATADAP en QAUDLVL2 si es absolutamente necesario (¡con mucha precaución!).
• Utiliza CPYAUDJRNE para extraer estos eventos y analiza con SQL.

• Comprobación de integridad de datos: Aunque no es directamente una función de auditoría de seguridad per se, las auditorías pueden incluir:

• Validación de referencial: Asegurar que las relaciones entre tablas (claves foráneas) se mantengan.
• Detección de duplicados: Buscar registros duplicados en tablas clave.
• Comparación de datos: Si hay réplicas o backups, se pueden comparar para detectar inconsistencias.

10. Generación de Informes y Documentación

La auditoría no termina con la recopilación de datos; la interpretación y el informe son vitales.

• Cómo exportar resultados (CPYTOIMPF, CPYTOSTMF): Una vez que has copiado las entradas del journal a archivos de base de datos (CPYAUDJRNE), puedes exportarlos:

• A un archivo de texto o CSV:
  CPYTOIMPF FROMFILE(QGPL/AUDIT_COMMANDS) TOSTMF('/home/auditoria/commands_20250707.csv') +
               RCDDLM(*CRLF) DTAFMT(*DLM) STRDLM('"') RMVBLANK(*TRAILING)
  Esto copia el archivo DB AUDIT_COMMANDS a un archivo CSV en el IFS (Integrated File System).
• Directamente a spool/PDF: Muchos comandos DSP* tienen un parámetro OUTPUT(*PRINT) que envía el resultado a una cola de salida. Desde la cola de salida, puedes convertirlo a PDF.

• Cómo generar logs en PDF o Excel:

• PDF: Desde la cola de salida (WRKSPLF), selecciona la opción para convertir a PDF (requiere la licencia del producto 5770-SS1 Option 33 - Portable Application Solutions Environment (PASE) y las herramientas de PDF). También se puede usar IBM Navigator for i para esta conversión.
• Excel: La forma más común es exportar a CSV (CPYTOIMPF) y luego abrir el CSV en Excel. IBM Navigator for i también permite descargar tablas directamente a Excel.

• Recomendaciones para informes formales de auditoría: Un informe de auditoría debe incluir:

1. Resumen Ejecutivo: Los hallazgos más críticos y las recomendaciones de alto nivel.
2. Alcance de la Auditoría: Qué se auditó, qué no, fechas.
3. Metodología: Cómo se realizó la auditoría, herramientas usadas.
4. Hallazgos Detallados: Cada vulnerabilidad o problema encontrado, con evidencia (extractos de logs, capturas de pantalla, configuración). Clasifícalos por nivel de riesgo (Crítico, Alto, Medio, Bajo).
5. Recomendaciones: Para cada hallazgo, una o más acciones correctivas claras y específicas.
6. Anexos: Datos brutos, configuraciones, etc.

11. Buenas Prácticas Post-Auditoría

La auditoría no es un evento único; es parte de un ciclo continuo de mejora.

• Revisión de hallazgos críticos:

• Prioriza los hallazgos según su nivel de riesgo.
• Programa reuniones con los responsables del sistema (administradores, equipo de seguridad) para discutir los hallazgos y acordar un plan de acción.

• Recomendaciones de refuerzo de seguridad:

• Políticas de Contraseñas: Reforzar complejidad, rotación, bloqueo por intentos fallidos.
• Principio de Mínimo Privilegio: Eliminar *ALLOBJ y otras autoridades especiales de perfiles no esenciales.
• Gestión de Perfiles Inactivos: Deshabilitar o eliminar perfiles inactivos.
• Revisión de Autorizaciones: Asegurar que las autorizaciones a objetos críticos (*PUBLIC, listas de autorización) sean las adecuadas.
• Control de Cambios: Implementar un proceso estricto para todos los cambios en el sistema, con aprobación y registro.
• Monitorización: Configurar alertas para eventos de seguridad críticos en tiempo real.
• Capacitación: Educar a los usuarios sobre las políticas de seguridad.

• Implementación de control de cambios:

• Establece un proceso formal para cualquier modificación en el sistema (hardware, software, configuración, aplicaciones).
• Cada cambio debe tener una solicitud, una aprobación, pruebas, una implementación documentada y un rollback plan.
• Las auditorías deben verificar la adherencia a este proceso.

12. Herramientas Adicionales que Apoyan la Auditoría

Más allá de los comandos nativos, existen herramientas que simplifican y potencian la auditoría.

• IBM Navigator for i:

• La interfaz gráfica web moderna para IBM i.
• Proporciona una vista más intuitiva de perfiles de usuario, objetos, valores de sistema.
• Permite filtrar y exportar fácilmente los datos del journal de auditoría sin necesidad de copiar a archivos.
• Ofrece informes predefinidos y cuadros de mando.

• IBM Security Services:

• IBM ofrece servicios de consultoría y soluciones de seguridad para IBM i, incluyendo auditorías y evaluaciones de vulnerabilidades.

• Herramientas comerciales: Hay varios proveedores de software de terceros que ofrecen soluciones avanzadas de seguridad y auditoría para IBM i, que superan las capacidades nativas en términos de facilidad de uso, informes y alertas en tiempo real:

• Fortra (anteriormente HelpSystems) Powertech Security: Suite completa de seguridad, incluye herramientas de auditoría, control de acceso, gestión de contraseñas, etc.
• Raz-Lee iSecurity: Otra suite integral con módulos para auditoría, prevención de intrusiones, firewall, etc.
• Software Engineering of America (SEA): Herramientas para la gestión de seguridad, auditoría y cumplimiento.
• Estas herramientas suelen tener dashboards gráficos, generación automática de informes de cumplimiento y alertas personalizables.

• Automatización de auditorías con CL o SQL:

• Puedes escribir programas CL que automaticen la ejecución de CPYAUDJRNE a diario y luego ejecuten scripts SQL para analizar los datos y generar informes automáticos.
• SQL es una herramienta muy potente para consultar los archivos de journal copiados. Puedes crear vistas, funciones y procedimientos SQL para simplificar el análisis recurrente.

13. Normativas de Referencia

Las auditorías de IBM i deben alinearse con los marcos regulatorios y de seguridad de la información.

• ISO 27001 (Sistema de Gestión de Seguridad de la Información - SGSI):

• Exige un enfoque sistemático para gestionar la seguridad de la información.
• La auditoría de AS/400 contribuye a los controles de acceso (A.9), seguridad física y del entorno (A.11), seguridad de las operaciones (A.12), gestión de incidentes de seguridad (A.16) y cumplimiento (A.18). Los logs de auditoría son la evidencia.

• SOX (Sarbanes-Oxley Act - Estados Unidos):

• Se enfoca en la precisión de los informes financieros y la responsabilidad corporativa.
• Las auditorías de IBM i son cruciales para el cumplimiento de SOX Section 404 (controles internos sobre informes financieros) y Section 302 (certificación de informes). Requiere que los sistemas que procesan datos financieros tengan controles de acceso y auditoría robustos.

• HIPAA (Health Insurance Portability and Accountability Act - Estados Unidos):

• Regula la protección de la información de salud protegida (PHI).
• Las auditorías de IBM i son esenciales para el cumplimiento de la Regla de Seguridad de HIPAA, que exige auditorías de actividad en sistemas que manejan PHI (quién accede, qué se accede, cuándo).

• PCI-DSS (Payment Card Industry Data Security Standard):

• Un estándar global para la protección de datos de titulares de tarjetas de pago.
• La auditoría de IBM i es fundamental para varios requisitos de PCI-DSS, incluyendo:

• Requisito 10: Implementar pistas de auditoría para rastrear toda la actividad de acceso a componentes del sistema y datos de titulares de tarjetas.
• Requisito 7: Restringir el acceso a los datos de los titulares de tarjetas según la necesidad de saber.
• Requisito 8: Asignar una ID única a cada persona con acceso a los componentes del sistema.

Realizar una auditoría exhaustiva en IBM i es una tarea compleja pero indispensable. Requiere un enfoque metódico, un conocimiento profundo de la plataforma y el uso inteligente de las herramientas disponibles. Al seguir estos pasos y adoptar las mejores prácticas, puedes garantizar que tu sistema IBM i siga siendo una fortaleza en la infraestructura de tu organización.