PCI DSS 4.0.1 en IBM i (AS/400): requisitos, controles y checklist de auditoría

PCI DSS 4.0.1 en IBM i (AS/400): Guía y Checklist

Las organizaciones que almacenan, procesan o transmiten datos de tarjetas mediante aplicaciones ejecutadas en IBM i deben incluir esta plataforma dentro del alcance de PCI DSS.

Aunque IBM i cuenta con una arquitectura de seguridad sólida, esto no significa que el sistema cumpla automáticamente con PCI DSS. El cumplimiento depende de cómo se configuren los perfiles de usuario, las autoridades, la auditoría, el cifrado, las conexiones externas y las aplicaciones que acceden a la información.

En esta guía explicamos los principales controles que deben revisarse para proteger datos de titulares de tarjetas y preparar un entorno IBM i para una evaluación de cumplimiento PCI DSS 4.0.1.

¿Qué es PCI DSS 4.0.1?

PCI DSS, Payment Card Industry Data Security Standard, es el estándar de seguridad utilizado para proteger los datos de tarjetas de pago.

Su objetivo es reducir el riesgo de:

• Robo de información financiera.

• Accesos no autorizados.

• Exposición de números de tarjetas.

• Fraude electrónico.

• Modificación indebida de aplicaciones.

• Ataques contra sistemas de pago.

  
  

PCI DSS 4.0.1 establece controles relacionados con protección de redes, administración de accesos, cifrado, desarrollo seguro, monitoreo, pruebas de seguridad y respuesta ante incidentes.

El cumplimiento no debe tratarse como una revisión que se realiza una vez al año. Debe convertirse en un proceso continuo de control, monitoreo y generación de evidencias.

¿Cuándo está IBM i dentro del alcance de PCI DSS?

Un servidor IBM i puede estar dentro del alcance cuando almacena, procesa o transmite información relacionada con tarjetas de pago.

También puede estar incluido cuando sus aplicaciones o usuarios pueden afectar la seguridad del entorno de datos de tarjetas.

Esto puede ocurrir cuando IBM i participa en procesos como:

• Facturación.

• Cobros electrónicos.

• Procesamiento de pagos.

• Aplicaciones financieras.

• Sistemas bancarios.

• Plataformas de comercio electrónico.

• Integraciones con procesadores de pago.

• Almacenamiento de información de clientes.

• Transferencias mediante APIs, archivos, ODBC o JDBC.

Para determinar el alcance deben identificarse las aplicaciones, tablas, archivos, interfaces, perfiles de usuario y servicios que tienen acceso directo o indirecto a los datos protegidos.

Controles PCI DSS que deben revisarse en IBM i

1. Configuración de seguridad del sistema

Los valores del sistema IBM i determinan una parte importante del nivel de protección de la plataforma.

La organización debe revisar, documentar y controlar cualquier modificación realizada sobre valores relacionados con:

• Nivel de seguridad del sistema.

• Contraseñas.

• Intentos fallidos de autenticación.

• Bloqueo de perfiles.

• Auditoría de seguridad.

• Restauración de objetos.

• Acceso remoto.

• Firma digital de objetos.

• Servicios de red.

  
  

Uno de los valores más importantes es QSECURITY, que define el nivel general de seguridad del sistema.

No debe asumirse que un valor de seguridad elevado resuelve todos los riesgos. También deben revisarse las autoridades sobre objetos, las aplicaciones, los perfiles y los servicios activos.

2. Perfiles de usuario y autoridades especiales

Los usuarios deben recibir solamente las autoridades necesarias para realizar su trabajo.

Debe prestarse especial atención a perfiles que tengan autoridades como:

• *ALLOBJ

• *SECADM

• *AUDIT

• *IOSYSCFG

• *SERVICE

• *SPLCTL

• *JOBCTL

La autoridad *ALLOBJ permite acceder ampliamente a los recursos del sistema y representa uno de los privilegios más sensibles dentro de IBM i.

Las organizaciones deben:

• Identificar todos los usuarios con autoridades especiales.

• Documentar por qué necesitan esos privilegios.

• Eliminar autoridades innecesarias.

• Revisar periódicamente los perfiles privilegiados.

• Evitar el uso de perfiles compartidos.

• Desactivar perfiles inactivos.

• Separar cuentas administrativas de cuentas de uso cotidiano.

• Registrar las actividades realizadas por usuarios privilegiados.

• 
  

El principio que debe aplicarse es el de mínimo privilegio: cada usuario debe tener únicamente el acceso estrictamente necesario.

3. Protección de datos almacenados

Los datos de titulares de tarjetas no deben almacenarse sin una necesidad comercial claramente definida.

Cuando sea necesario conservarlos, deben aplicarse controles como:

• Cifrado.

• Tokenización.

• Enmascaramiento.

• Truncamiento.

• Eliminación segura.

• Restricción de acceso.

• Separación de funciones.

• Administración segura de llaves criptográficas.

  
  

El número completo de una tarjeta no debe aparecer innecesariamente en pantallas, archivos de impresión, reportes, registros de aplicaciones, archivos temporales o ambientes de prueba.

También deben revisarse copias de seguridad, archivos históricos, bibliotecas duplicadas y ambientes de desarrollo que puedan contener información real.

El cifrado pierde efectividad si la llave se almacena junto a los datos o si cualquier administrador puede acceder a ella. Por esta razón, las llaves deben protegerse mediante controles independientes, rotación, registros de uso y acceso restringido.

4. Seguridad de Db2 for i

Db2 for i puede ser accedido desde aplicaciones RPG, COBOL, Java, .NET, Python, herramientas de análisis, APIs y conexiones externas.

No basta con proteger el menú de una aplicación. También debe controlarse el acceso directo a las tablas y objetos de la base de datos.

La revisión debe incluir:

• Autoridad pública de archivos y tablas.

• Permisos privados asignados a usuarios.

• Perfiles de grupo.

• Listas de autorización.

• Acceso mediante SQL.

• Acceso desde ODBC y JDBC.

• Procedimientos almacenados.

• Triggers.

• Programas con autoridad adoptada.

• Interfaces externas.

• Consultas ejecutadas por usuarios privilegiados.

  
  

Una aplicación puede impedir que un usuario consulte cierta información desde el menú, pero ese mismo usuario podría acceder directamente a Db2 si conserva autoridad sobre los objetos.

La seguridad debe aplicarse tanto en la aplicación como en el sistema operativo y la base de datos.

5. Auditoría de seguridad con QAUDJRN

IBM i dispone del diario de auditoría QAUDJRN para registrar eventos relevantes de seguridad.

La configuración depende principalmente de:

• QAUDCTL

• QAUDLVL

• QAUDLVL2

• Auditoría específica de usuarios.

• Auditoría específica de objetos.

Estos controles permiten registrar eventos como:

• Fallos de autorización.

• Cambios en perfiles de usuario.

• Modificaciones de valores del sistema.

• Creación y eliminación de objetos.

• Cambios de autoridades.

• Uso de funciones administrativas.

• Acciones sobre objetos sensibles.

• Restauraciones.

• Fallos de programas.

• Actividades relacionadas con seguridad.

Activar la auditoría no es suficiente.

La organización también debe:

• Revisar regularmente los eventos.

• Detectar comportamientos anormales.

• Generar alertas.

• Conservar los registros.

• Proteger los receptores del diario.

• Limitar quién puede modificar la configuración.

• Documentar las investigaciones realizadas.

• Integrar los eventos con una plataforma de monitoreo cuando sea posible.

  
  

Una auditoría que registra información, pero nunca es revisada, ofrece una protección limitada.

6. Protección de datos en tránsito

Toda información sensible transmitida entre IBM i y otros sistemas debe protegerse mediante conexiones cifradas.

Deben revisarse especialmente:

• ODBC.

• JDBC.

• APIs.

• Servicios web.

• FTP.

• Transferencias de archivos.

• Aplicaciones móviles.

• Conexiones con procesadores de pago.

• Interfaces con sistemas bancarios.

• Herramientas administrativas.

  
  

Las conexiones deben utilizar protocolos seguros como TLS y certificados administrados correctamente.

También deben eliminarse o restringirse servicios inseguros que transmitan credenciales o datos sin cifrado.

La revisión debe comprobar no solamente que TLS esté habilitado, sino también:

• Qué versiones están permitidas.

• Qué certificados se utilizan.

• Cuándo vencen.

• Quién puede administrarlos.

• Qué aplicaciones continúan usando conexiones no cifradas.

  
  

7. Programas que adoptan autoridad

IBM i permite que determinados programas adopten la autoridad de su propietario durante la ejecución.

Esta función puede ser necesaria en algunas aplicaciones, pero también puede convertirse en un riesgo si el programa pertenece a un perfil con privilegios elevados.

Deben identificarse y revisar los programas que:

• Adoptan autoridad.

• Pertenecen a perfiles con *ALLOBJ.

• Ejecutan comandos dinámicos.

• Acceden a datos de tarjetas.

• Modifican autoridades.

• Llaman programas externos.

• Reciben parámetros sin validación.

  
  

El código debe impedir que un usuario utilice el programa para ejecutar acciones diferentes a las autorizadas.

8. Desarrollo seguro de aplicaciones

Las aplicaciones desarrolladas para IBM i también forman parte del cumplimiento.

Los programas RPG, COBOL, CL, Java, PHP, Python, Node.js o .NET conectados al sistema deben seguir prácticas de desarrollo seguro.

Las revisiones deben buscar problemas como:

• Inyección SQL.

• Comandos construidos dinámicamente.

• Parámetros sin validar.

• Contraseñas escritas dentro del código.

• Llaves criptográficas almacenadas en fuentes.

• Exposición de datos en logs.

• Mensajes de error con información sensible.

• Falta de control de autoridades.

• Uso inseguro de APIs.

• Dependencias vulnerables.

• Acceso excesivo a tablas.

• 
  

Las organizaciones deben aplicar revisión de código, pruebas SAST, pruebas DAST y análisis de vulnerabilidades según el tipo de aplicación.

Los cambios realizados en producción también deben contar con autorización, pruebas, separación de funciones y mecanismos de reversión.

9. Monitoreo continuo y respuesta ante incidentes

PCI DSS requiere mantener capacidad para detectar y responder ante eventos de seguridad.

En IBM i deben monitorearse situaciones como:

• Fallos repetidos de autenticación.

• Uso inesperado de perfiles privilegiados.

• Cambios en valores del sistema.

• Modificaciones de autoridades.

• Creación de nuevos usuarios.

• Acceso masivo a información.

• Transferencias inusuales.

• Ejecución de comandos administrativos.

• Cambios no autorizados en programas.

• Eliminación o alteración de registros.

  
  

La empresa debe contar con un procedimiento de respuesta que indique:

• Quién recibe la alerta.

• Quién investiga.

• Cómo se contiene el incidente.

• Cómo se conservan las evidencias.

• Cuándo se informa a responsables internos.

• Cómo se recuperan los sistemas.

• Cómo se documentan las acciones realizadas.

  
  

Evidencias necesarias para una auditoría PCI DSS

El auditor no solamente necesita conocer los controles implementados. También necesita evidencias que demuestren que se encuentran activos y son revisados regularmente.

Algunas evidencias importantes en IBM i son:

• Configuración de valores del sistema.

• Listado de perfiles con autoridades especiales.

• Revisiones periódicas de usuarios.

• Configuración de QAUDJRN.

• Eventos de auditoría.

• Reportes de cambios de autoridades.

• Evidencias de revisión de accesos.

• Configuración de conexiones TLS.

• Inventario de certificados.

• Listado de programas con autoridad adoptada.

• Resultados de pruebas de vulnerabilidad.

• Resultados de pruebas de penetración.

• Revisiones de código.

• Registros de cambios en producción.

• Procedimientos de respuesta ante incidentes.

• Evidencias de capacitación del personal.

  
  

Las evidencias deben conservarse de manera organizada, protegida y accesible para los responsables de cumplimiento.

Errores frecuentes en seguridad PCI DSS para IBM i

Pensar que IBM i es seguro por defecto

IBM i cuenta con controles avanzados, pero una mala configuración, autoridades excesivas o aplicaciones vulnerables pueden exponer datos sensibles.

Excluir IBM i de las evaluaciones

Algunas empresas concentran sus revisiones en Windows, Linux, firewalls y estaciones de trabajo, mientras ignoran el servidor donde realmente se procesan o almacenan las transacciones.

Tener demasiados usuarios con *ALLOBJ

La acumulación de privilegios incrementa el impacto de una cuenta comprometida y dificulta demostrar el principio de mínimo privilegio.

Proteger solamente el menú de la aplicación

Un usuario puede no tener acceso mediante el menú, pero conservar autoridad directa sobre las tablas de Db2 for i.

Activar QAUDJRN sin revisar sus eventos

Registrar eventos sin analizarlos no permite detectar oportunamente ataques, abusos o cambios no autorizados.

Utilizar perfiles compartidos

Los perfiles compartidos dificultan identificar quién realizó una acción y reducen la trazabilidad exigida durante una investigación.

Usar datos reales en desarrollo

Copiar información de tarjetas o clientes hacia ambientes de pruebas amplía innecesariamente el alcance y el riesgo.

No revisar integraciones externas

ODBC, JDBC, APIs, servicios web y transferencias de archivos pueden permitir acceso directo a información sensible fuera de los controles tradicionales de la aplicación.

Checklist de PCI DSS para IBM i

Utilice esta lista como punto inicial de evaluación:

• ¿IBM i está correctamente incluido en el alcance PCI DSS?

• ¿Se encuentran identificadas las tablas que contienen datos sensibles?

• ¿Los datos de tarjetas están cifrados, tokenizados o truncados?

• ¿Las llaves criptográficas están protegidas?

• ¿Se revisan los valores de seguridad del sistema?

• ¿Existe un inventario de usuarios privilegiados?

• ¿Se justifican los perfiles con *ALLOBJ?

• ¿Los perfiles inactivos son deshabilitados?

• ¿Se utilizan cuentas individuales?

• ¿Está configurado QAUDJRN?

• ¿Los eventos de auditoría son revisados?

• ¿Se generan alertas ante actividades críticas?

• ¿Las conexiones ODBC y JDBC utilizan cifrado?

• ¿Las APIs utilizan TLS?

• ¿Se revisan los certificados y sus vencimientos?

• ¿Se controlan las autoridades sobre Db2 for i?

• ¿Se revisan programas con autoridad adoptada?

• ¿Se realizan pruebas de vulnerabilidad?

• ¿Se revisa la seguridad del código?

• ¿Existe un procedimiento de respuesta ante incidentes?

• ¿Se conservan evidencias para la auditoría?

  
  

Preguntas frecuentes

¿IBM i cumple automáticamente con PCI DSS?

No. IBM i proporciona herramientas y controles de seguridad, pero el cumplimiento depende de la configuración, las aplicaciones, los procesos y la revisión continua realizada por la organización.

¿AS/400 e IBM i son lo mismo?

AS/400 es el nombre histórico utilizado para una plataforma que ha evolucionado con el tiempo. Actualmente, el sistema operativo y la plataforma se conocen como IBM i, aunque muchas empresas continúan utilizando el término AS/400 en sus búsquedas y conversaciones.

¿QAUDJRN es suficiente para cumplir PCI DSS?

No. QAUDJRN es una fuente fundamental de eventos de seguridad, pero debe estar correctamente configurado, protegido, monitoreado y acompañado por otros controles técnicos y administrativos.

¿Debe revisarse el acceso directo a Db2 for i?

Sí. Deben evaluarse tanto los permisos utilizados por las aplicaciones como el acceso directo mediante SQL, ODBC, JDBC, herramientas administrativas y otras interfaces.

¿Se pueden almacenar números de tarjetas en IBM i?

Solamente cuando exista una necesidad válida y se apliquen los controles requeridos de protección, cifrado, restricción de acceso, retención y eliminación segura.

Conclusión

El cumplimiento de PCI DSS 4.0.1 en IBM i requiere mucho más que instalar un firewall o activar una opción de auditoría.

Es necesario revisar de forma integral:

• Perfiles y autoridades.

• Valores del sistema.

• Acceso a Db2 for i.

• Auditoría de seguridad.

• Protección criptográfica.

• Conexiones externas.

• Desarrollo de aplicaciones.

• Monitoreo continuo.

• Evidencias de cumplimiento.

  
  

IBM i puede ofrecer un entorno altamente seguro cuando sus controles se configuran, supervisan y documentan correctamente.

Evaluación de seguridad PCI DSS para IBM i

EXSYSTEM ayuda a las organizaciones a evaluar y fortalecer la seguridad de sus entornos IBM i.

Nuestros servicios pueden incluir revisión de autoridades especiales, perfiles de usuario, configuración de auditoría, acceso a Db2 for i, cifrado, aplicaciones, conexiones externas y evidencias de cumplimiento.

Solicite una evaluación inicial para identificar riesgos, desviaciones y oportunidades de mejora en su plataforma IBM i.

Autor: Yober Jiménez

Especialidad: Desarrollo, seguridad y servicios IBM i

Empresa: EXSYSTEM LLC

Última revisión: 28 de julio de 2026