Niveles de seguridad del sistema, perfiles de usuario, autoridades sobre objetos, listas de autorización, adopted authority y auditoría.
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
IBM i
IBM i tiene niveles de seguridad configurables con el System Value QSECURITY. Cada nivel agrega protecciones sobre el anterior:
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.
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.
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.
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.
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.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
QSECOFRSecurity Officer — equivalente a root. Tiene todas las autoridades. Es el perfil más poderoso del sistema.
QSYSOPRSystem Operator — recibe mensajes del sistema, gestiona subsistemas y dispositivos.
QPGMRProgrammer — perfil para desarrollo. Tiene autoridades para compilar y depurar.
QUSERDefault user — perfil básico para usuarios finales.
QSRVService — usado por IBM para servicio técnico. Normalmente deshabilitado.
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.
Cada perfil tiene una clase que determina un conjunto base de capacidades. De menor a mayor poder:
*USERUsuario finalNinguna*PGMRProgramadorNinguna (pero puede compilar)*SYSOPROperador del sistema*JOBCTL, *SAVSYS*SECADMAdministrador de seguridad*SECADM (gestiona perfiles)*SECOFROficial de seguridadTodas las autoridades especialesCada 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.
*ALLControl total (todas las operaciones)
*CHANGELeer, agregar, modificar, eliminar datos
*USESolo leer / ejecutar
*EXCLUDESin acceso (denegación explícita)
Los shortcuts se componen de autoridades individuales. Las principales son:
*OBJOPRObject operational — necesaria para cualquier operación con el objeto
*OBJMGTObject management — mover, renombrar, cambiar autoridades
*OBJEXISTObject existence — borrar el objeto, liberar storage
*READLeer datos del objeto
*ADDAgregar registros/datos
*UPDModificar registros/datos existentes
*DLTEliminar registros/datos
*EXECUTEEjecutar programa o recorrer directorio
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.
AUT(*EXCLUDE) y luego otorgar permisos específicos a usuarios o grupos. Es más seguro que empezar permisivo y restringir después.Son permisos globales del sistema (no sobre un objeto específico). Se asignan al perfil del usuario y le dan capacidades amplias:
*ALLOBJAcceso a todos los objetos del sistema, sin importar sus autoridades individuales. Es el más peligroso.
*SECADMGestionar perfiles de usuario (crear, modificar, eliminar). No incluye acceso a datos.
*JOBCTLControlar cualquier trabajo del sistema (pausar, cancelar, cambiar prioridad).
*SAVSYSHacer backups (SAVLIB, SAVOBJ, SAV). Necesaria para operadores.
*SPLCTLControlar todos los spool files, no solo los propios.
*AUDITGestionar la configuración de auditoría del sistema.
*SERVICEAcceso a funciones de servicio y diagnóstico avanzado.
*IOSYSCFGConfigurar dispositivos de comunicaciones y líneas.
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
CLIENTESFACTURASPRODUCTOSPEDIDOSCRTAUTL 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
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.
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.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.
QAUDCTLActiva/desactiva la auditoría (*AUDLVL, *OBJAUD, *NOQTEMP)
QAUDLVLNivel de auditoría del sistema (qué eventos registrar)
QAUDENDACNQué hacer si el journal de auditoría falla
QCRTOBJAUDAuditoría por defecto para objetos nuevos
-- 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;
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
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
-- 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%';