Protección de sus datos en Hyper Protect Virtual Servers para VPC
La dirección IBM Cloud Hyper Protect Virtual Servers para VPC está obsoleta. A partir del 28 de febrero de 2026, no se podrán crear nuevas instancias. Las instancias existentes se admitirán hasta el 20 de febrero de 2027. Se eliminarán todas las instancias que aún existan en esa fecha. Puede redistribuir sus cargas de trabajo utilizando IBM Confidential Computing Container Runtime(antes conocido como Hyper Protect Virtual Servers) o IBM Confidential Computing Container Runtime para soluciones de virtualización Red Hat(anteriormente conocido como Hyper Protect Container Runtime para soluciones de virtualización Red Hat). Para obtener información sobre la migración de datos, consulte la Guía de migración. Para más información, consulte el anuncio de eliminación de servicios.
El volumen de datos que adjunta a su instancia de Hyper Protect Virtual Servers para VPC está protegido por una contraseña de cifrado LUKS ( Linux Unified Key Setup). La frase de contraseña se deriva de las semillas que se proporcionaron durante la implementación. Puede añadir un mayor nivel de protección y control mediante cifrado a sus datos en reposo utilizando su propia clave de Hyper Protect Crypto Services.
Cómo se cifra el volumen de datos
Sin su propia clave, el volumen de datos que conecta a la instancia se cifra automáticamente con dos semillas que se proporcionan en las secciones workload- volumes y env-
volumes del contrato. Las semillas se convierten internamente en secuencias UTF8 y, a continuación, se concatenan. El hash ( SHA256 ) de la secuencia concatenada se calcula como un resumen hexadecimal, que se utiliza como contraseña
LUKS para cifrar el volumen de datos. Para obtener más información, consulte Acerca del contrato.
Protección de los datos confidenciales con su propia clave
A partir de ibm-hyper-protect-container-runtime-1-0-s390x-11, Hyper Protect Virtual Servers para la integración de la compatibilidad con VPC con el servicio de gestión de claves (KMS) Hyper Protect Crypto Services. Hyper Protect
Crypto Services genera un valor aleatorio como tercera semilla y lo envuelve con la CRK (clave raíz del cliente). Para obtener más información sobre CRK, consulte Claves raíz.
La semilla envuelta se almacena en la partición de metadatos del volumen de datos. La frase de contraseña LUKS se genera utilizando tres semillas-la semilla en la partición de metadatos (sin envolver primero) y las dos semillas
del contrato.
Conocimientos previos: A partir de la versión de imagen ibm-hyper-protect-container-runtime-1-0-s390x-9 HPCR, para las nuevas instancias VPC de Hyper Protect Virtual Servers, el volumen de datos se divide en dos
partes. La primera partición (100 MiB ) está reservada exclusivamente para metadatos internos ( no accesibles por una carga de trabajo). La segunda partición permanece como volumen de datos para la carga de trabajo. Sólo se
particionan los volúmenes nuevos.
Actualmente, solo se admite Hyper Protect Crypto Services como servicio de gestión de claves.
La siguiente tabla es un resumen de las semillas. La tercera semilla es la que proporciona el servicio de gestión de claves.
| Semilla | Proveedor | De | Necesario u opcional |
|---|---|---|---|
| seed1 | Persona de Deployer | env-Sección volumes del contrato |
Obligatorio |
| seed2 | Persona de carga de trabajo | workload-Sección volumes del contrato |
Obligatorio |
| seed3 | Hyper Protect Crypto Services | Hyper Protect Crypto Services Genera la tercera semilla y la envuelve con el CRK solo si se proporcionan kms detalles en el contrato. El cifrado de la envoltura se realiza llamando a una API de envoltura. La semilla envuelta
se almacena en la partición de metadatos del volumen de datos. |
Opcional |
El daemon de claves se inicia si el volumen está protegido con protección de la instancia de KMS. Es responsable de reaccionar ante los cambios de estado del CRK.
Acerca de las claves gestionadas por el cliente
Hyper Protect Virtual Servers Para VPC, utilice el cifrado de sobresEl proceso de cifrar datos con una clave de cifrado de datos y, a continuación, cifrar la clave con una clave raíz que se puede gestionar totalmente. para implementar claves gestionadas por el cliente. El cifrado de envoltura consiste en cifrar (envolver) una clave de cifrado con otra clave de cifrado. En nuestro caso, la clave envuelta es la tercera semilla, y la clave que se utiliza para envolver la semilla es la CRK de Hyper Protect Crypto Services.
Usted es el propietario del CRK en Hyper Protect Crypto Services. Hyper Protect Virtual Servers para VPC nunca ve el CRK. Su almacenamiento, gestión y uso para cifrar y descifrar la semilla se lleva a cabo íntegramente dentro del servicio de gestión de claves.
Hyper Protect Crypto Services cuenta con el respaldo de hardware certificado según la norma FIPS 140-2 Nivel 4, que es el nivel más alto que ofrece cualquier proveedor de servicios en la nube del sector. Para obtener más información, consulte Iniciación a Hyper Protect Crypto Services.
Habilitación de claves gestionadas por el cliente para Hyper Protect Virtual Servers para VPC
La posibilidad de habilitar la función depende del historial de la instancia de Hyper Protect Virtual Servers para VPC (diseño de particiones y cifrado LUKS) y de la información del contrato. Consulte la tabla siguiente para ver los posibles
escenarios y resultados. Si no sabe qué significan los detalles de kms en el contrato, consulte las instrucciones en Pasos. La tabla muestra el comportamiento de un servidor virtual
durante el inicio, el número de volúmenes que están conectados al servidor virtual y la entrada que se especifica en el archivo de contrato.
| Número de particiones en el volumen de datos | Partición de metadatos | Contrato | Si la partición/segunda partición está cifrada con LUKS | Comportamiento de Hyper Protect Virtual Servers para VPC |
|---|---|---|---|---|
| 0 | N/D | Tiene detalles de kms |
No LUKS cifrado | La instancia crea dos particiones en el volumen de datos, llama a Hyper Protect Crypto Services para generar una tercera semilla y la envuelve con el CRK. La semilla envuelta se almacena en la partición de metadatos. A continuación, la instancia genera una contraseña LUKS con la semilla (desempaquetada primero) y las dos semillas del contrato para cifrar la segunda partición. |
| 0 | N/D | Tiene detalles de kms |
LUKS cifrado | La instancia concluye. Debe eliminar los detalles de kms en el contrato. |
| 1 | N/D | No soportado. La instancia concluye. | ||
| 2 | Ninguna semilla cifrada | Tiene detalles de kms (una entrada) |
No LUKS cifrado | La instancia llama a Hyper Protect Crypto Services para generar una tercera semilla y envolverla con el CRK. La semilla envuelta se almacena en la partición de metadatos. A continuación, la instancia genera una contraseña LUKS con la semilla (desempaquetada primero) y las dos semillas del contrato para cifrar la segunda partición. |
| 2 | Ninguna semilla cifrada | Tiene detalles de kms (una entrada) |
LUKS cifrado | Un flujo similar al anterior para volver a cifrar la segunda partición. Se sustituye la frase de contraseña LUKS antigua. Las dos semillas de env y workload deben ser las mismas que antes, o el recodificado fallará y la instancia se apagará. Proporcione las semillas correctas y vuelva a intentarlo. |
| 2 | Ninguna semilla cifrada | Tiene detalles de kms (varias entradas) |
No LUKS cifrado | Flujo similar al de los escenarios anteriores para envolver la tercera semilla y cifrar la segunda partición. Sólo se utiliza la configuración de la primera entrada para envolver la tercera semilla. |
| 2 | Tiene una semilla cifrada | Tiene detalles de kms (una entrada) |
No LUKS cifrado | Es posible que hayas utilizado el volumen en un aprovisionamiento anterior, pero el cifrado no se haya realizado correctamente. O bien, proporcionaste el volumen con dos particiones y creaste manualmente un valor aleatorio como tercera semilla, lo envolvieron y lo almacenaron en la partición de metadatos. En cualquier caso, la instancia comprueba si el particionamiento es correcto. Si no es así, la instancia se cierra. Si la partición es correcta, la instancia llama a Hyper Protect Crypto Services para desempaquetar la semilla cifrada, genera una contraseña LUKS con la semilla y las dos semillas del contrato para cifrar la segunda partición. |
| 2 | Tiene una semilla cifrada | Tiene detalles de kms (una entrada) |
LUKS cifrado | La instancia llama a Hyper Protect Crypto Services para desempaquetar la semilla cifrada y abre la capa LUKS en la partición de datos. |
| 2 | Tiene una semilla cifrada | Tiene detalles de kms (varias entradas) |
La instancia llama a Hyper Protect Crypto Services para desempaquetar la semilla cifrada con la primera kms entrada. Si falla, utiliza la siguiente entrada. Cuando se ejecuta correctamente, utiliza la primera configuración
para volver a envolver la semilla. Si todas las entradas no funcionan, la instancia se cierra. |
|
| 2 | Tiene una semilla cifrada | No hay detalles de kms |
La instancia concluye. Debe proporcionar los detalles de kms en el contrato. |
Comprueba los registros en IBM Cloud Logs si tu instancia se apaga.
Pasos
-
Proporcione una instancia de Hyper Protect Crypto Services y cree una clave raíz. Para obtener más información, consulte Creación de claves raíz.
Para mejorar la seguridad, se recomienda utilizar puntos finales privados virtuales con Hyper Protect Crypto Services.
-
Cuando prepare el contrato, añada
kmsdetalles en laenv-volumessección y, a continuación, utilice el contrato para crear una instancia de Hyper Protect Virtual Servers para VPC. Consulte el ejemplo siguiente:env: | logging: logRouter: hostname: 34be57c7-6ff2-4685-8839-903921e90ab9.ingress.jp-tok.logs.cloud.ibm.com iamApiKey: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" volumes: test: kms: - apiKey: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" crn: "crn:v1:bluemix:public:hs-crypto:us-south:a/xxxxxxxxxxxx:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:key:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx" type: "public" - apiKey: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" crn: "crn:v1:bluemix:public:hs-crypto:us-south:a/xxxxxxxxxxxxx:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx:key:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx" type: "private" seed:"workload_phrase1" kmsTimeout: 10 apiKey: "L4SsSE32xxxxxjAgfHCVkdW8xl_CiqMn4Lpc1dzTD" signingKey: "xxxxxxxxx" workload: | volumes: test: mount: "/mnt/data" seed: "workload_phrase2" filesystem: "ext4"
Para evitar el uso indebido de los detalles de KMS por parte de un atacante, se recomienda encarecidamente que el desplegador (que proporciona la sección env ) cifre y firme el contrato. Para
obtener más información sobre el cifrado, consulte Cifrado de contrato. Para la firma, añada una clave de firma pública (campo signingKey ) a la sección
env y firme el contrato completo añadiendo una sección envWorkloadSignature al contrato. El propósito de la firma es garantizar que las workload secciones env y siempre se utilicen juntas
y no sean manipuladas por terceros. Para obtener más información, consulte Firma de contrato.
-
kmsEn el campo
kms, coloque siempre la configuración de KMS que desea utilizar como primera entrada. Las entradas siguientes son configuraciones de KMS más antiguas (utilizadas para descifrar la semilla encapsulada antes de migrar a la configuración actual). Se da soporte a un máximo de cinco entradas. Para obtener más información sobre cómo cambiar las configuraciones de KMS, consulte Cambiar a una instancia o clave raíz diferente de Hyper Protect Crypto Services.Si los detalles de
kmsdel contrato no son válidos, la instancia concluye inmediatamente. -
kmsTimeoutPuede especificar
kmsTimeout(entre 0 y 1000 minutos) en el contrato. Si no se especifica, el valor predeterminado del tiempo de espera es de 10 minutos. Este valor determina cuánto tiempo intenta la instancia desempaquetar la semilla durante el arranque inicial o el reinicio. Cuando transcurra este tiempo de espera, se registrarán los mensajes y la instancia se cerrará. -
typeUtilice este campo para especificar las instancias como "private" cuando está en una red privada y "public" cuando está en la red pública. Esta entrada se utiliza para respaldar el cambio a una instancia diferente de Hyper Protect Crypto Services o CRK.
Si el volumen es nuevo, la instancia crea dos particiones en el volumen de datos, llama a Hyper Protect Crypto Services para generar una tercera semilla y la envuelve con el CRK. La semilla envuelta se almacena en la partición de metadatos. A continuación, la instancia genera una contraseña LUKS con la semilla (desempaquetada primero) y las dos semillas del contrato para cifrar la segunda partición.
También puede optar por crear manualmente dos particiones en un volumen, crear un valor aleatorio como la tercera semilla, envolverlo y almacenarlo en la partición de metadatos:
-
Cree dos particiones en el dispositivo de bloque utilizando la utilidad de Linux
parted.- La primera partición se etiqueta como
metadatay tiene una longitud de 100 MiB. La partición de metadatos está reservada exclusivamente para metadatos internos y no es accesible para cargas de trabajo. Cree un sistema de archivos ( ext4 ) y cree un archivo con el nombre keyfile. - la segunda partición está etiquetada como
datay ocupa todo el espacio del disco.
- La primera partición se etiqueta como
-
Utilice la API KMS de Hyper Protect Crypto Services Envuelva una clave para generar un texto sin formato aleatorio que se base en un HSM y envuélvalo sin pasar el valor.
-
Copie el texto cifrado del objeto de respuesta al archivo de claves.
-
Prepare el contrato con la información KMS y cree una instancia de VPC ( Hyper Protect Virtual Servers ) con el volumen particionado manualmente que contiene una semilla envuelta.
Cuando la instancia está en ejecución, el demonio clave se pone en contacto periódicamente con la instancia Hyper Protect Crypto Services. Se aplica el mismo tiempo de espera kmsTimeout. Si no se puede acceder a la instancia
Hyper Protect Crypto Services, el estado del CRK no es Active, o los parámetros de acceso (kms detalles) ya no coinciden, el demonio activa un reinicio.
Comprueba los registros en Log Analysis si tu instancia se apaga.
Uso de claves gestionadas por el cliente para Hyper Protect Virtual Servers para VPC
Rotación de la clave raíz
Si la CRK se rota manualmente o automáticamente basándose en una política de rotación de claves, el daemon de claves detecta la rotación de claves y vuelve a envolver la semilla.
Cambiar a una instancia diferente de Hyper Protect Crypto Services o a una clave raíz diferente
Si desea utilizar una instancia diferente de Hyper Protect Crypto Services o un ID de clave raíz diferente, introduzca la nueva configuración KMS como primera entrada en el contrato y vuelva a crear la instancia Hyper Protect Virtual Servers. Mantenga la configuración KMS anterior (la que se utiliza actualmente) en el contrato. Durante la instanciación, Hyper Protect Virtual Servers para VPC desempaqueta la semilla cifrada con la configuración antigua y utiliza la nueva configuración para volver a empaquetar la semilla. Se da soporte a un máximo de cinco entradas en el contrato.
Una vez realizado el cambio, las entradas antiguas se pueden eliminar de la siguiente interacción.
Inhabilitación de la clave raíz
Si inhabilita la clave raíz, el estado de la clave pasa a ser Suspendido. El demonio clave de Hyper Protect Virtual Servers para VPC comprueba periódicamente
el estado del CRK. Si el estado no es Activo, el servidor virtual se reinicia. Durante el reinicio, el demonio clave sigue comprobando el estado mediante sondeos y, cuando el tiempo que tarda supera kmsTimeout,
el servidor virtual se apaga. Debe habilitar la clave raíz para volver a poner la clave en Activo.
Asegúrese de que la CRK no ha caducado. De lo contrario, su estado pasa a ser Desactivado, y el servidor virtual se reinicia y finalmente se apaga. Para obtener más información sobre los estados de las claves, consulta Supervisión del ciclo de vida de las claves de cifrado.