Seguridad

Niveles de seguridad del sistema, perfiles de usuario, autoridades sobre objetos, listas de autorización, adopted authority y auditoría.

Modelo de seguridad

La seguridad en IBM i es integrada al sistema operativo, no es un producto aparte. Cada objeto tiene un propietario y una lista de permisos. Cada usuario tiene un perfil que define qué puede y qué no puede hacer.

x86 / Linux

  • Permisos rwx por archivo (owner, group, others)
  • SELinux/AppArmor como capa adicional
  • root tiene acceso total sin restricción
  • Seguridad del SO separada de la BD
  • Cada aplicación gestiona su propia autenticación
  • Filesystem no distingue tipos de objeto

IBM i

  • Autoridades por objeto (granulares por tipo)
  • Seguridad integrada en el kernel (SLIC)
  • QSECOFR ≈ root, pero puede restringirse
  • Seguridad del SO = seguridad de la BD
  • Autenticación centralizada por perfil de usuario
  • Cada tipo de objeto tiene operaciones específicas protegidas

Niveles de seguridad (QSECURITY)

IBM i tiene niveles de seguridad configurables con el System Value QSECURITY. Cada nivel agrega protecciones sobre el anterior:

Nivel 20

Seguridad por contraseña

(No recomendado)

Solo requiere contraseña para iniciar sesión. Una vez dentro, el usuario tiene acceso a todo. No se verifica autoridad sobre objetos.

Nivel 30

Seguridad por recursos

(Mínimo legacy)

Se verifican las autoridades sobre objetos. Los usuarios solo pueden acceder a lo que tienen permiso. Sin embargo, no protege contra manipulación directa de punteros.

Nivel 40

Protección de integridad

(Recomendado mínimo)

Protege contra modificación directa de punteros del sistema. Los programas no pueden acceder a áreas de memoria protegidas. Previene bypasses de seguridad.

Nivel 50

Protección reforzada

(Más seguro)

Máxima protección. Previene que interfaces no soportadas accedan a objetos del sistema. Bloques de control internos del SO están protegidos. Requerido para C2 security.

Importante: El nivel se sube con CHGSYSVAL SYSVAL(QSECURITY) VALUE('40') y requiere un IPL (restart) para aplicarse. Subir de nivel es sencillo; bajar puede romper la seguridad configurada. La mayoría de los sistemas en producción usan nivel 40 o 50.

Perfiles de usuario

Cada usuario tiene un User Profile (*USRPRF) que es un objeto del sistema. Contiene toda la información de identidad, permisos, configuración de sesión y preferencias.

Un perfil de usuario define:

Nombre (hasta 10 chars)

Identificador del usuario en el sistema

Clase de usuario

*USER, *PGMR, *SYSOPR, *SECADM, *SECOFR

Autoridades especiales

Permisos globales del sistema

Current Library

Biblioteca de trabajo por defecto

Initial Program/Menu

Qué se ejecuta al hacer sign-on

Job Description

Template de configuración para sus trabajos

Output Queue

Cola de salida para spool files

Group Profile

Perfil de grupo al que pertenece

Password rules

Expiración, largo mínimo, composición

Límite de almacenamiento

Máximo de disco que puede usar

Perfiles especiales del sistema

QSECOFR

Security Officer — equivalente a root. Tiene todas las autoridades. Es el perfil más poderoso del sistema.

QSYSOPR

System Operator — recibe mensajes del sistema, gestiona subsistemas y dispositivos.

QPGMR

Programmer — perfil para desarrollo. Tiene autoridades para compilar y depurar.

QUSER

Default user — perfil básico para usuarios finales.

QSRV

Service — usado por IBM para servicio técnico. Normalmente deshabilitado.

Group Profiles

Los perfiles de grupo funcionan como grupos de Linux. Un usuario puede pertenecer a hasta 16 grupos. Las autoridades se heredan del grupo: si el grupo tiene acceso a un objeto, todos sus miembros también.

Clases de usuario

Cada perfil tiene una clase que determina un conjunto base de capacidades. De menor a mayor poder:

ClaseRolAutoridades especiales por defecto
*USERUsuario finalNinguna
*PGMRProgramadorNinguna (pero puede compilar)
*SYSOPROperador del sistema*JOBCTL, *SAVSYS
*SECADMAdministrador de seguridad*SECADM (gestiona perfiles)
*SECOFROficial de seguridadTodas las autoridades especiales

Autoridades sobre objetos

Cada objeto en IBM i tiene una lista de control de acceso que define qué usuarios o grupos pueden hacer qué con él. Hay autoridades predefinidas (shortcuts) y autoridades individuales.

Autoridades predefinidas (shortcuts)

*ALL

Control total (todas las operaciones)

*CHANGE

Leer, agregar, modificar, eliminar datos

*USE

Solo leer / ejecutar

*EXCLUDE

Sin acceso (denegación explícita)

Autoridades individuales

Los shortcuts se componen de autoridades individuales. Las principales son:

*OBJOPR

Object operational — necesaria para cualquier operación con el objeto

*OBJMGT

Object management — mover, renombrar, cambiar autoridades

*OBJEXIST

Object existence — borrar el objeto, liberar storage

*READ

Leer datos del objeto

*ADD

Agregar registros/datos

*UPD

Modificar registros/datos existentes

*DLT

Eliminar registros/datos

*EXECUTE

Ejecutar programa o recorrer directorio

Public Authority

Cada objeto tiene una public authority que define el acceso por defecto para usuarios que no están listados explícitamente. Si creás una tabla con PUBLIC *CHANGE, cualquier usuario puede modificar sus datos a menos que tenga un *EXCLUDE explícito.

Buena práctica: Crear objetos con AUT(*EXCLUDE) y luego otorgar permisos específicos a usuarios o grupos. Es más seguro que empezar permisivo y restringir después.

Autoridades especiales

Son permisos globales del sistema (no sobre un objeto específico). Se asignan al perfil del usuario y le dan capacidades amplias:

*ALLOBJ

Acceso a todos los objetos del sistema, sin importar sus autoridades individuales. Es el más peligroso.

*SECADM

Gestionar perfiles de usuario (crear, modificar, eliminar). No incluye acceso a datos.

*JOBCTL

Controlar cualquier trabajo del sistema (pausar, cancelar, cambiar prioridad).

*SAVSYS

Hacer backups (SAVLIB, SAVOBJ, SAV). Necesaria para operadores.

*SPLCTL

Controlar todos los spool files, no solo los propios.

*AUDIT

Gestionar la configuración de auditoría del sistema.

*SERVICE

Acceso a funciones de servicio y diagnóstico avanzado.

*IOSYSCFG

Configurar dispositivos de comunicaciones y líneas.

Cuidado con *ALLOBJ: Un usuario con *ALLOBJ puede leer y modificar cualquier dato del sistema, incluyendo datos de otros usuarios, configuración de seguridad y programas. Solo debe asignarse a perfiles administrativos de confianza.

Listas de autorización (*AUTL)

En vez de asignar permisos objeto por objeto, podés crear una lista de autorización y asociarla a múltiples objetos. Cuando cambiás los permisos en la lista, se aplican automáticamente a todos los objetos asociados.

Es como un role-based access group pero a nivel de objetos del SO:

AUTL: MIAPP_DATOS

FERNANDO → *CHANGE

GRP_CONSULTA → *USE

*PUBLIC → *EXCLUDE

protege →
CLIENTES
FACTURAS
PRODUCTOS
PEDIDOS
CL — Listas de autorización
CRTAUTL AUTL(MIAPP_DATOS)               Crear lista
ADDAUTLE AUTL(MIAPP_DATOS) USER(FERNANDO) AUT(*CHANGE)  Agregar usuario
GRTOBJAUT OBJ(MILIB/CLIENTES) OBJTYPE(*FILE) AUTL(MIAPP_DATOS)  Asociar
DSPAUTL AUTL(MIAPP_DATOS)              Ver contenido de la lista
EDTAUTL AUTL(MIAPP_DATOS)              Editor interactivo

Adopted Authority

Un programa puede adoptar la autoridad de su propietario durante la ejecución. Esto permite que un usuario sin permisos directos sobre una tabla pueda acceder a ella a través de un programa controlado.

Usuario MARIA

Sin acceso a CLIENTES

PGM: CONSULTA

USRPRF(*OWNER)

Owner: ADMIN

Tabla CLIENTES

ADMIN tiene *CHANGE

MARIA ejecuta el programa CONSULTA, que adopta las autoridades de ADMIN para acceder a CLIENTES.

Comparación x86: Es similar al bit setuidde Linux, donde un programa se ejecuta con los permisos de su propietario. La diferencia es que en IBM i esto es un mecanismo estándar y controlado por el sistema, no un hack de permisos.

Auditoría

IBM i tiene un sistema de auditoría integrado que registra eventos de seguridad en un journal especial (QAUDJRN). Se configura con system values y atributos de objeto/perfil.

System Values de auditoría

QAUDCTL

Activa/desactiva la auditoría (*AUDLVL, *OBJAUD, *NOQTEMP)

QAUDLVL

Nivel de auditoría del sistema (qué eventos registrar)

QAUDENDACN

Qué hacer si el journal de auditoría falla

QCRTOBJAUD

Auditoría por defecto para objetos nuevos

Eventos que se pueden auditar

Sign-on/Sign-offFallos de autorizaciónCambios de perfilCambios de autoridadCreación/eliminación de objetosRestauración de objetosUso de comandos sensiblesCambios de system valuesOperaciones de red
SQL — Consultar auditoría
-- Ver intentos fallidos de login
SELECT TIMESTAMP, USER_NAME, REMOTE_ADDRESS
FROM QSYS2.AUDIT_JOURNAL_VA
WHERE ENTRY_TYPE = 'VA' AND AUDIT_VIOLATION_TYPE = 'A'
ORDER BY TIMESTAMP DESC
FETCH FIRST 20 ROWS ONLY;

Comandos de seguridad

CL — Perfiles de usuario
CRTUSRPRF USRPRF(NUEVO) PASSWORD(xxx) USRCLS(*USER)  Crear perfil
CHGUSRPRF USRPRF(NUEVO) CURLIB(MILIB)    Cambiar biblioteca actual
DSPUSRPRF USRPRF(NUEVO) TYPE(*ALL)       Ver detalle del perfil
WRKUSRPRF USRPRF(*ALL)                   Listar todos los perfiles
DLTUSRPRF USRPRF(VIEJO) OWNOBJOPT(*CHGOWN)  Eliminar perfil
CHGPWD                                    Cambiar tu propia contraseña
CL — Autoridades sobre objetos
GRTOBJAUT OBJ(MILIB/CLIENTES) OBJTYPE(*FILE) USER(FERNANDO) AUT(*CHANGE)
RVKOBJAUT OBJ(MILIB/CLIENTES) OBJTYPE(*FILE) USER(FERNANDO) AUT(*ALL)
DSPOBJAUT OBJ(MILIB/CLIENTES) OBJTYPE(*FILE)    Ver autoridades
EDTOBJAUT OBJ(MILIB/CLIENTES) OBJTYPE(*FILE)    Editor interactivo
CHGOBJOWN OBJ(MILIB/CLIENTES) OBJTYPE(*FILE) NEWOWN(ADMIN)  Cambiar dueño
SQL — Seguridad vía SQL
-- Otorgar permisos SQL (funciona igual que en cualquier BD)
GRANT SELECT, INSERT, UPDATE ON MILIB.CLIENTES TO FERNANDO;
GRANT ALL ON MILIB.CLIENTES TO ADMIN WITH GRANT OPTION;
REVOKE DELETE ON MILIB.CLIENTES FROM FERNANDO;

-- Ver permisos de una tabla
SELECT * FROM QSYS2.OBJECT_PRIVILEGES
WHERE SYSTEM_OBJECT_SCHEMA = 'MILIB'
  AND SYSTEM_OBJECT_NAME = 'CLIENTES';

-- Ver perfiles con *ALLOBJ (riesgo de seguridad)
SELECT USER_NAME, SPECIAL_AUTHORITIES
FROM QSYS2.USER_INFO
WHERE SPECIAL_AUTHORITIES LIKE '%*ALLOBJ%';