Anexo de seguridad — IBM i y AIX

Este anexo agrupa los conceptos de seguridad que aparecen en los módulos en uno solo, para que sirva como referencia rápida y como insumo para auditorías internas. Toda recomendación está sourceada a la documentación oficial de IBM o a estándares públicos (DISA STIG, CIS).

Parte 1 — IBM i

QSECURITY (nivel de seguridad del sistema)

QSECURITY define el nivel de seguridad que el OS aplica. Valores posibles: 10, 20, 30, 40, 50.

•Niveles 10 y 20 — no recomendados por IBM. El nivel 10 no provee la protección de los niveles superiores y representa riesgo de seguridad e integridad. El nivel 20 tampoco se recomienda.
•Nivel 40 — protección completa de integridad. Mínimo aceptable para producción.
•Nivel 50 — máxima protección de integridad. Recomendado para sistemas con exposición externa (Internet-facing) o regulatorios (banca, salud).

(Fuente: IBM Documentation — Using QSecurity system value (7.4), IBM i Security Reference SC41-5302 (7.4))

Cambio de nivel: pasar de 30 a 40 o de 40 a 50 requiere planning y testing — algunas aplicaciones legacy fallan en niveles superiores. IBM recomienda probar primero en un sistema no productivo.

QPWDLVL (nivel de password)

Define el formato y reglas de contraseñas:

•0 — passwords cortas (hasta 10), legacy.
•1 — eliminó las contraseñas en formato NetServer simple, manteniendo compatibilidad.
•2 — long passwords (hasta 128 caracteres) con preservación de compatibilidad.
•3 — long passwords sin compatibilidad legacy.
•4 — nuevo en IBM i 7.5 — esquema de encriptación más fuerte. (Fuente: IBM i 7.5 — Base Enhancements)

Recomendación general: el valor más alto que la base instalada de aplicaciones tolere, idealmente 3 o 4.

Otros system values relevantes para seguridad

| System Value | Para qué | Recomendación general | |---|---|---| | QCRTAUT | Autoridad pública por defecto en objetos nuevos | *USE o *EXCLUDE (nunca *ALL) | | QMAXSIGN | Intentos de login fallidos antes de deshabilitar | 3 o 5 | | QMAXSGNACN | Acción tras alcanzar QMAXSIGN | 3 (desactivar device + perfil) | | QINACTITV | Timeout por inactividad (minutos) | 15-30 | | QINACTMSGQ | Cola para sesiones inactivas | *DSCJOB (desconectar) | | QAUDLVL / QAUDLVL2 | Niveles de auditoría | Habilitado, según política | | QAUDCTL | Control de auditoría | *AUDLVL *OBJAUD | | QPWDEXPITV | Vencimiento de password en días | 60-90 | | QPWDRQDDIF | Diferencia requerida con passwords previas | 5 (5 distintas antes de reusar) | | QPWDMINLEN / QPWDMAXLEN | Longitud mínima / máxima | 8 / 128 (en QPWDLVL alto) | | QPWDRULES | Reglas (caracteres requeridos, etc.) | Configurable por organización | | QLMTSECOFR | Restringir QSECOFR a ciertas devices | 1 (restringido) |

(Fuente: IBM i Security Reference SC41-5302 (7.5), IBM i 7.4 Security Reference SC41-5302)

Modelo de autoridad sobre objetos

IBM i tiene autoridad por objeto, no solo por filesystem. Tipos de autoridad:

•Autoridad pública — la que ven todos los usuarios sin autoridad específica.
•Autoridad privada — específica de un usuario sobre un objeto.
•Listas de autorización (*AUTL) — agrupan autoridades reusables.
•Roles del perfil — *USER, *PGMR, *SYSOPR, *SECADM, *SECOFR.

Comandos clave:

•DSPOBJAUT OBJ(LIB/OBJ) OBJTYPE(*FILE) — ver autoridades.
•GRTOBJAUT / RVKOBJAUT — otorgar / revocar.
•EDTOBJAUT — editar interactivamente.
•WRKAUTL — listas de autorización.

Auditoría

•Journal de auditoría QAUDJRN — registra eventos de seguridad.
•Configurar con QAUDLVL y QAUDCTL.
•Consultar con DSPJRN JRN(QAUDJRN).
•IBM i Services tiene vistas SQL (QSYS2.JOURNAL_INFO, etc.) para reportar.

Seguridad en aplicativos del portafolio

Quick EDD

•Perfil de servicio con autoridades suficientes para leer journals y crear/modificar objetos en target.
•Buenas prácticas: NO usar QSECOFR para Quick EDD; perfil dedicado con *ALLOBJ solo si imprescindible.
•Autoridades específicas sobre objetos replicados — auditar al alta.

Connect CDC

•Perfil del agente con autoridad sobre journals en scope.
•Seguridad del canal hacia el motor Connect (TLS, certificados).
•Autenticación contra el destino — credenciales rotables, no hardcodeadas.

Flash for i

•Autoridades sobre el storage externo (FlashCopy / SnapShot).
•Coordinación con BRMS — perfil con autoridad sobre el catálogo.
•LPAR clon — debe heredar el modelo de seguridad de producción.

Parte 2 — AIX

Marco de hardening

AIX no tiene un único equivalente al QSECURITY de IBM i. La seguridad se compone por capas:

•Configuración del OS (system parameters, services).
•Archivos /etc/security/* (users, login, group).
•Filesystem permissions (clásicos UNIX + ACL).
•AIX Trusted Computing Base (TCB).
•Encriptación (LV/PV con chvg -E).
•Secure Boot y firma de kernel/módulos en hardware compatible.

Estándares públicos de hardening AIX

Dos referencias autoritativas, gratuitas y bien mantenidas:

•
DISA STIG para IBM AIX 7.x — Security Technical Implementation Guide del Departamento de Defensa de EE.UU. Define settings concretos, identificadores de control y rationale. Disponible en:
- •public.cyber.mil/stigs (público, sin CAC)
- •NCP — IBM AIX 7.X STIG checklist (NIST)
•
CIS IBM AIX Benchmarks — guías de configuración del Center for Internet Security. Cubren AIX 7.1 y 7.2 (verificar última versión vigente). Disponible en:
- •cisecurity.org/benchmark/ibm_aix

Estas dos referencias son la base para auditorías y para definir un baseline interno. No deben adoptarse 100% sin testing — algunos controls pueden romper aplicaciones legacy. Adoptar progresivamente.

Áreas de hardening AIX prioritarias

Cuentas y autenticación

•Política de password en /etc/security/user y /etc/security/login.cfg.
•Atributos: pwdwarntime, loginretries, histsize, minlen, minalpha, mindiff.
•Deshabilitar cuentas no usadas (chuser account_locked=true usuario).
•root solo vía su desde cuenta nominal con rastro en logs.

Servicios de red

•Auditar servicios escuchando: netstat -an, lssrc -a.
•Deshabilitar lo no necesario en /etc/inetd.conf y SRC.
•Forzar SSH (deshabilitar Telnet, rsh, rlogin clásicos).
•sshd_config endurecido: PermitRootLogin no, PasswordAuthentication no (key-based), Protocol 2.

Filesystem

•Permisos correctos en /, /etc/security, /var/log, /tmp.
•umask por defecto seguro (022 o 027).
•Encriptación de LV/PV con chvg -E para datos sensibles.

Auditoría

•AIX audit subsystem habilitado (audit start).
•Configurar clases en /etc/security/audit/config.
•Reportar con auditpr.
•Forwardear logs a SIEM corporativo.

Updates

•TL/SP al día — IBM publica fixes de seguridad regularmente.
•AIX Live Update (LLU) permite aplicar TL/SP sin reinicio (introducido en 7.2 y mejorado en 7.3 TL3). (Fuente: TechChannel — AIX 7.3 Live Update with TL3)

Trusted Computing Base (TCB)

AIX provee un mecanismo tcbck para verificar integridad de archivos críticos. Habilitable en la instalación o post-install. Útil para detección de tampering.

Secure Boot y trusted execution

AIX 7.3 incluye soporte para secure boot y entornos de ejecución confiables (trusted execution environments) sobre Power compatible. Reduce la superficie ante malware en niveles bajos.

(Fuente: TechChannel — A Look at the Latest AIX 7.3 Enhancements)

Parte 3 — Postura de seguridad alrededor de los aplicativos

Quick EDD

•Canal de replicación entre source y target — protegerlo (red dedicada o VPN).
•Perfiles de servicio con principio de menor privilegio.
•Logs de auditoría del producto integrados al SIEM.
•Procedimientos de switch — quien puede ejecutarlos. Aprobaciones por flujo (idealmente con ticket).

Connect CDC

•Credenciales contra destinos — vault corporativo, rotación.
•TLS entre componentes (agente → motor → destino).
•Schemas / mapping versionados — evitar drift no autorizado.
•Datos sensibles — considerar masking o tokenización en el motor antes de entregarlos a destino cloud.

Flash for i

•Perfiles con autoridad sobre storage externo y BRMS.
•Cinta / VTL — encriptación del medio.
•LPAR clon — perímetro y firewall iguales a producción; aislar de redes inseguras.
•Datos sensibles en el clon — mismo tratamiento que producción (no es un "test environment libre").