IBM i 7.6: el cambio en llaves maestras que puede dejar tu IPL esperando una llave que nadie tiene a mano
Más allá del BYOK vía IBM Key Protect que ya cubrimos, el Technology Refresh de julio tocó algo más profundo: cómo IBM i gestiona sus llaves maestras internas, con una opción que puede bloquear el arranque del sistema hasta que un administrador entregue una llave. Vale la pena entender el mecanismo antes de activarlo.
Cuando cubrimos el Technology Refresh de verano de IBM i 7.6/7.5 a comienzos de agosto, nos quedamos en la superficie de una de sus piezas: Bring Your Own Key (BYOK) vía IBM Cloud Key Protect, pensado para quien corre su partición en PowerVS y necesita demostrarle a un auditor que controla sus propias llaves de cifrado. El 10 de agosto, IT Jungle publicó una cobertura más profunda que muestra que el cambio real va más allá de esa integración con la nube: IBM también tocó cómo se administran las llaves maestras dentro del propio sistema operativo, y una de las opciones nuevas puede literalmente dejar una partición sin poder completar el IPL hasta que alguien le entregue una llave a mano. Es el tipo de cambio que conviene entender antes de tocarlo, no después de un desastre.
Qué es una llave maestra en IBM i, en términos simples
Según la propia documentación de IBM, Cryptographic Services en IBM i mantiene ocho llaves maestras de uso general más tres de propósito especial que ni siquiera el oficial de seguridad puede tocar directamente: la llave maestra de Save/Restore (usada para cifrar el resto de las llaves maestras cuando se guardan en disco o en una operación SAVSYS), la llave maestra de ASP (para el cifrado de pools de almacenamiento independientes) y la llave remota, que usa la función de Remote Key Agent para enviarle a otro sistema la llave que ese sistema necesita como su propia llave de Save/Restore. Todas son llaves AES de 256 bits, guardadas de forma segura dentro del Licensed Internal Code.
Cada llave maestra tiene, además, cinco versiones — nueva, actual, anterior, pendiente y pendiente-anterior — pero solo la actual y la anterior se guardan en disco, y siempre cifradas bajo la llave de Save/Restore. Las demás nunca tocan el disco. Es un diseño en capas: perder la llave de Save/Restore no borra datos directamente, pero sí deja inaccesibles las demás llaves maestras que dependen de ella, y por transitividad, todo lo que esas llaves protegen. La propia documentación de IBM lo dice sin rodeos: si se pierde una llave maestra, se pierden todas las llaves cifradas bajo ella y, en consecuencia, todos los datos cifrados bajo esas llaves.
Dos cambios operativos acompañan al TR2, según recoge IT Jungle: ya no se puede dejar la llave maestra en su valor por defecto — hay que fijarla explícitamente la primera vez que se configura o se modifica — y la gestión de llaves maestras desde Navigator for i ahora exige TLS, para reducir el riesgo de exponer el valor de una llave en tránsito. Ninguno de los dos es dramático por sí solo, pero ambos apuntan en la misma dirección: cerrar configuraciones implícitas que hasta ahora quedaban en manos de quien instalaba el sistema y nunca volvía a revisarlas.
La pieza que cambia el IPL: BYOK a nivel de sistema operativo
La parte más consecuente, y la que le da título a la nota de IT Jungle, es distinta de la integración con IBM Cloud Key Protect: es un régimen de BYOK a nivel de sistema operativo que, si se activa, envuelve las llaves maestras con la llave de Save/Restore de tal forma que quedan inaccesibles hasta que esa llave se entrega durante o después del IPL. Combinado con cifrado de ASP1 (el pool de sistema), esto puede llegar a impedir que la partición complete el arranque hasta que un administrador la entregue.
Hay dos formas de resolver esa entrega, y elegir entre ellas es la decisión de arquitectura que de verdad importa. La primera es el Platform KeyStore (PKS), una función de PowerVM que le da a cada partición lógica un almacenamiento cifrado y no volátil dentro del procesador de servicio del propio hardware; si la llave está cacheada ahí, el proceso de arranque la recupera solo, sin intervención humana. La segunda es el Remote Key Agent (RKA): cualquier LPAR de IBM i, distinta de la partición de producción, que tiene almacenada la información necesaria para actuar como agente remoto — en este caso, un administrador tiene que entregar la llave de Save/Restore a mano durante el IPL.
La diferencia entre las dos opciones no es cosmética. PKS depende del hardware físico específico donde vive la partición: si esa partición se restaura en otro servidor —exactamente lo que pasa en un evento de recuperación ante desastres— el PKS del hardware original no viaja con ella. Si no hay un RKA preconfigurado en el sitio de DR, o si nadie documentó dónde vive la llave y quién puede entregarla, el sistema queda con el IPL a mitad de camino, esperando una llave que en ese momento nadie tiene a mano. No es un escenario hipotético raro: es exactamente el momento — un failover real, con presión de tiempo y gente que no necesariamente es la que configuró el cifrado meses o años atrás — donde este tipo de fricción sale más cara.
Por qué esto conecta con la conversación de cumplimiento que ya veníamos siguiendo
Vale la pena leer este cambio junto con el BYOK vía Key Protect que cubrimos hace unas semanas, porque ambos responden al mismo impulso: los marcos de cumplimiento —SOC 2, PCI DSS, requisitos sectoriales— cada vez exigen con más frecuencia que el cliente, no el proveedor de nube ni el fabricante del sistema operativo, controle sus propias llaves de cifrado. El BYOK a nivel de sistema operativo es la versión de ese mismo requisito aplicada puertas adentro: ya no alcanza con que IBM i cifre los datos por defecto con una llave que el sistema gestiona solo; para ciertos perfiles de riesgo, el propio arranque del sistema tiene que depender de una llave que la organización controla explícitamente. Es una postura de seguridad más estricta, y el costo de esa postura es procedimental: alguien tiene que estar en condiciones de entregar esa llave, en cualquier sitio donde la partición pueda terminar corriendo.
Qué hacer con esto en tu shop
Antes de activar el régimen de BYOK a nivel de sistema operativo en una partición productiva, valen tres pasos concretos. Primero, decidí explícitamente entre PKS y RKA en función de dónde puede terminar corriendo la partición en un escenario de DR real — si hay más de un sitio de recuperación posible, probablemente necesités RKA configurado en cada uno, no solo PKS en el hardware primario. Segundo, documentá y probá el procedimiento de entrega de la llave como parte del runbook de DR, no como una nota al margen: un IPL bloqueado a mitad de un failover es el peor momento para que el único que sabe dónde está la llave esté de vacaciones. Tercero, seguí al pie la recomendación de IBM de guardar por separado, en un lugar seguro, las passphrases o la información necesaria para recuperar cada llave maestra, y ejecutá un SAVSYS después de fijarlas — porque el diseño en capas que protege tus datos es el mismo que, sin ese respaldo, puede hacerlos irrecuperables. Ninguna de estas tareas es glamorosa, pero es exactamente el tipo de trabajo de fontanería que separa un control de cifrado que funciona en el papel de uno que funciona el día que de verdad lo necesitás.