Auditoría de IBM Power Systems (AS/400). Parte 1. Introducción

Buenas,

Comienzo aquí una serie de algunas entradas sobre auditoría de seguridad en entornos AS/400. Me váis a permitir que emplee la nomenclatura de AS/400, incorrecta por obsolescencia, pero es la que todo el mundo comprende. Realmente, AS/400 ya no existe como tal, puesto que esta nomenclatura dejó de usarse para pasar a utilizar eServer iSeries, IBM System i, y por último, IBM Power Systems.

En cuanto al sistema operativo, más de lo mismo. Lo que en su día era OS/400 se pasó a llamar i5/OS, y hoy en día se llama IBM i. Para facilitar la comprensión de este batiburrillo de nomenclaturas he confeccionado esta tabla, que recoge para cada producto el año de introducción. No he podido confirmar al 100% el año de introducción de la nomenclatura i5/OS, motivo por el cual aparece asteriscado:

evolucion nomenclaturas as400

as400
Algunos IBM System i (AS/400)

A pesar de que las nomenclaturas han sido cambiantes a lo largo del tiempo, en la jerga lo usual es que se hable de auditoría de un AS/400, aunque nos refiramos a la auditoría de seguridad del sistema operativo que corre en ese AS/400, siendo comunes otras acepciones coloquiales, como Análisis de la Seguridad de un 400 y expresiones similares. En adelante, y espero que nadie se ofenda, yo emplearé la nomenclatura a la antigua usanza :)

Hechas estas matizaciones, introducimos un poco qué es un 400, para qué se utiliza y cuál será el ámbito de estudio al que circunscribiremos estos artículos.

El AS/400 (IBM Power Systems)

Para introducir un poco este tipo de máquina, podemos decir que un AS/400 es una máquina intermedia que cubre el hueco existente entre un mainframe (también conocido como host) y los pequeños servidores que normalmente operan en clúster atendiendo servicios distribuídos. En la literatura es habitual hablar de estas máquinas intermedias como máquinas mid-range, y son frecuentemente utilizadas para procesado de transacciones, con lo que es usual ver máquinas AS/400 al cargo de la transaccionalidad de empresas de seguros, entidades financieras, sistemas gubernamentales, etc., siempre con el permiso de los hermanos mayores del AS/400: los mainframes.

Teniendo en cuenta que la brecha entre los mainframes y las máquinas mid-range se ha reducido drásticamente en los últimos años, a pesar de seguir existiendo, los 400 gozan de una gran ventaja, que deriva de su menor capacidad: costes menores de adquisición y mantenimiento, lo que los hace ideales cuando la transaccionalidad es fuerte en ambientes donde no se requiere una computadora central.

Modo normal de funcionamiento

Los AS/400 están pensados para funcionar de muchas maneras, siendo el modo más frecuente la existencia de un hardware común compartido que da servicio a un número determinado de distintos LPAR o particiones lógicas. En el caso de máquinas IBM, los LPARes pueden funcionar con distintos sistemas operativos: z/OS, z/VM, z/VSE, z/TPF, AIX, Linux e IBM i y cada LPAR puede cubrir distintos objetivos (desarrollo, QA, producción). En el caso de AS/400, lo normal es que funcionen con IBM i (recordad: lo que en su día era OS/400), aunque no necesariamente tiene por qué ser así.

Seguridad en IBM i

Hoy en día no es descabellado catalogar a IBM i como uno de los sistemas operativos más seguros de la industria, debido, entre otras cosas, a que:

  • Es un sistema que requiere un conocimiento muy específico para ser administrado y operado, y por tanto, también para ser atacado.
  • Es un sistema en el que la seguridad ha ido de la mano de su desarrollo desde prácticamente sus orígenes, otorgándole una más que merecida relevancia.
  • Aunque es un sistema que atiende entornos complejos, no deja de ser un sistema concebido desde la simplicidad. Y la simplicidad es siempre un aliado de la seguridad.
  • El sistema operativo tiene una comunión perfecta con las características de seguridad que puede ofrecer el hardware (por ejemplo, el cifrado de datos) y la integración con otras plataformas.
  • Aunque no tiene necesariamente que ser así, es frecuente que los 400 estén en el back de una instalación. Esto implica que la relación con el exterior y sus ataques es muy limitada y está fuertemente controlada, conviertiendo a los ataques internos en principales candidatos.

La seguridad en IBM i se basa en el concepto del diseño basado en objetos. Esto abre la veda para poder implementar la seguridad en diversas capas, como por ejemplo, la utilización de perfiles de usuario, permisos de los objetos, firma de los objetos y verificaciones de integridad de los mismos.

Los objetos se empaquetan en contenedores que agrupan objetos consistentes entre sí, así como con el contenedor. Los objetos están siempre encapsulados en estos contenedores, lo que tiene una implicación vital para la seguridad. Un objeto nunca puede ser usado si el uso requiere que se pierda consistencia con el tipo de objeto y su contenedor.

Esto hace fácil articular que los datos no sean tratados como código ejecutable y viceversa, lo que hace muy complicado, en un ambiente de administración adecuado, que los objetos puedan ser usados de modo incorrecto. Este modo de confinamiento tiene como principal ventaja no cohibir la flexibilidad del sistema, pero tiene como principal inconveniente la necesidad de una puesta en marcha y una administración de seguridad exigente que entraña complejidad.

En síntesis, la seguridad estará principalmente basada en relaciones entre usuarios y recursos:

  • Desde la óptica de los usuarios, en sentido creciente, los perfiles de usuario, las descripciones de tareas, los perfiles de grupo y los valores de sistema
  • Desde la óptica de los recursos, también en sentido creciente, los objetos individuales, las librerías y directorios, las listas de autorización y los valores del sistema.

Material de estudio y libro de referencia

Todo, o prácticamente todo lo que comentemos estará alineado con los manuales del fabricante. Son completos y suficientes, y ellos son los que mejor conocen su producto. Es por tanto que para sacarle el mayor provecho a estos artículos, una lectura y comprensión de este material es aconsejable.

Para no inundaros con una lista extensa de PDFs, creo que lo mejor que podemos hacer es basarnos en el propio manual del fabricante. La última edición que he podido encontrar es Security Guide for IBM i V6.1, que data de finales de mayo de 2009. Os recomiendo tenerlo a mano, ya que en él podréis encontrar información extensa sobre lo que veremos en esta serie de artículos.

En la próxima entrega hablaremos del análisis de los valores del sistema (WRKSYSVAL), donde prestaremos atención a los valores generales relacionados con la seguridad.

Un saludo,

4 comentarios sobre “Auditoría de IBM Power Systems (AS/400). Parte 1. Introducción

  1. buenísmo el artículo, ahora ya tengo más idea de qué esperar cuando haga revisiones a equipos AS400. Espero la siguiente entrega!

Comentarios cerrados.