Descripción general de Cloud HSM de usuario único

En este documento, se proporciona una descripción general de los conceptos y las funciones de Cloud HSM de un solo inquilino.

Cloud HSM de usuario único te permite crear y administrar una instancia de usuario único de Cloud HSM. Una instancia de Cloud HSM de usuario único es un clúster dedicado de particiones en módulos de seguridad de hardware (HSM) para tu uso exclusivo. Cada instancia proporciona la misma redundancia y alta disponibilidad que Cloud HSM de múltiples usuarios. Cada clúster de HSM de Cloud de un solo arrendatario se distribuye en varios HSM en varias zonas dentro de la región seleccionada. Cada partición está aislada de forma criptográfica de otras particiones en el HSM.

Puedes otorgar o denegar el acceso de Google a tu clúster, y los administradores de tu instancia administran el clúster. Los administradores de instancias controlan la instancia con un modelo de aprobación de quórum que se basa en claves de control asimétricas para la autenticación de dos factores (2FA). Tú creas tus claves de control fuera deGoogle Cloud, de modo que Google nunca tenga acceso a tus claves de control privadas.

Después de configurar tu instancia de Cloud HSM de usuario único, los administradores de Cloud KMS pueden crear claves de usuario único y los desarrolladores pueden usarlas como cualquier otra clave de Cloud HSM, sin necesidad de cambiar el código.

El uso de Cloud HSM de usuario único genera costos. Para obtener información sobre los precios, consulta Precios de Cloud KMS.

Autenticación basada en quórum

Cloud HSM de usuario único usa la autenticación basada en quórum para garantizar que varios administradores de instancias aprueben las operaciones críticas. Antes de crear una instancia de un solo arrendatario, debes crear un conjunto de claves de control asimétricas fuera de Cloud KMS y definir cuántas aprobaciones se requieren para las operaciones en la instancia. Por ejemplo, si tu instancia está administrada por cinco administradores, puedes exigir que tres de ellos aprueben cada operación de mantenimiento en la instancia.

Las operaciones que requieren autenticación de quórum tienen tres etapas:

  1. Propuesta: Un administrador de instancias propone una operación, por ejemplo, registrar una nueva clave de control. La propuesta crea una instantánea inmutable del estado actual del sistema. Las propuestas vencen después de 24 horas y se pueden cancelar en cualquier momento hasta que se inicie la operación aprobada.

  2. Aprobación: La cantidad requerida de administradores debe firmar los desafíos con su clave de control única. Cada desafío firmado indica un administrador que aprueba la operación. Cuando hay suficientes desafíos firmados listos, un administrador de instancias los sube para aprobar la propuesta. Si los desafíos son válidos y la propuesta no venció, se aprueba.

  3. Ejecución: Después de que se aprueba una propuesta, pero antes de que venza, puedes ejecutar la operación propuesta.

Capacidades de Cloud HSM de usuario único

En esta sección, se describen las capacidades principales de Cloud HSM de un solo inquilino.

Administración de instancias

Tus administradores gestionan el ciclo de vida de tus instancias de HSM en la nube de un solo arrendatario.

  • Crear una instancia: Aprovisionas una instancia nueva en una sola región. El proceso de creación requiere que configures la autenticación de quórum.
  • Obtén información de la instancia: Puedes consultar una instancia para obtener sus metadatos y configuración. Esta operación no requiere autenticación de quórum.
  • Inhabilita y habilita una instancia: Puedes inhabilitar una instancia de forma temporal, lo que revoca el acceso de Google a las particiones. Puedes habilitar la instancia más adelante. Ambas operaciones requieren autenticación de quórum. Si habilitas tu instancia, se restablece el disableDate a 120 días a partir del momento de la operación de habilitación. Mientras una instancia está inhabilitada, todas las claves creadas en ella no están disponibles y fallan todas las operaciones que intentan usar esas claves.
  • Actualiza una instancia: Debes actualizar tu instancia periódicamente para mantenerla disponible. Las instancias deben actualizarse cada 120 días o menos. Cada instancia tiene un disableDate que indica cuándo se vencerá la instancia y se deberá actualizar. Cuando actualizas la instancia, se restablece el disableDate a 120 días a partir del momento de la actualización. Esta operación requiere autenticación de quórum. Las instancias que no se actualicen antes de la hora disableDate se inhabilitarán automáticamente.
  • Borra una instancia: Puedes borrar una instancia. Si borras una instancia, se destruirán de forma permanente todas las claves que se crearon en ella. Esta es una operación destructiva que es irreversible. No borres una instancia a menos que desees destruir criptográficamente todos los datos encriptados con las claves creadas en la instancia. Esta operación requiere autenticación de quórum.

Administración de claves

Tus administradores son propietarios de las claves de control que usas para la autenticación de quórum. Tus desarrolladores y otros propietarios de recursos crean y usan claves criptográficas en tu instancia.

  • Rotar las claves de control de administrador: Los administradores pueden rotar la clave de control de la 2FA para un miembro del quórum administrativo. Esta operación requiere autenticación de quórum.
  • Genera claves criptográficas: Tus desarrolladores y propietarios de recursos pueden crear un objeto CryptoKey con un nivel de protección de HSM de usuario único. Esta operación no requiere autenticación de quórum.
  • Realizar operaciones criptográficas: Después de crearse, las claves almacenadas en una instancia de un solo arrendatario se pueden usar para operaciones criptográficas al igual que cualquier otra clave de Cloud Key Management Service.

Prácticas recomendadas para el HSM de usuario único de Cloud

Sigue estas prácticas recomendadas cuando uses el HSM de Cloud de un solo arrendatario:

  • Retenciones del proyecto: Usa retenciones del proyecto para proteger los proyectos que contienen instancias activas de HSM de Cloud de un solo arrendatario. Si borras un proyecto que contiene una instancia de Cloud HSM de un solo inquilino, no se podrán recuperar las claves creadas en esa instancia.
  • Tokens físicos: Usa tokens físicos para almacenar las claves privadas de la A2F de los administradores de tu instancia. Almacena estos tokens físicos de forma segura. Si pierdes un quórum de claves, Google no podrá ayudarte a recuperar el acceso a la instancia. Debido a que las instancias deben actualizarse con regularidad, perder un quórum de claves eventualmente inhabilita la instancia.
  • Claves de respaldo: Registra al menos una clave de 2FA de repuesto más allá de las claves que tienen los miembros de tu quórum. Guarda las claves de respaldo en una ubicación segura a la que puedas acceder si se pierde o roban la clave de un miembro del quórum.
  • Separación de obligaciones: Mantén la separación de obligaciones para los administradores de tu instancia. La propuesta, la aprobación y la ejecución requieren roles de IAM separados, que deben distribuirse entre al menos dos personas para que ninguna persona tenga los permisos de los tres roles. Si una persona tiene todos los permisos subyacentes, existe un mayor riesgo de pérdida de datos accidental o intencional.
  • Distribución de claves: Asegúrate de que tus claves privadas de 2FA se distribuyan de forma segura entre personas de confianza. Ninguna persona debe conservar la posesión de suficientes claves privadas para alcanzar un quórum. Si una persona tiene acceso a suficientes claves privadas para cumplir con el tamaño de quórum requerido, existe un mayor riesgo de pérdida de datos accidental o intencional.
  • Programa de actualización: Incorpora la actualización de tus instancias de Cloud HSM de usuario único en tus procedimientos de mantenimiento continuos. Debes supervisar el disableDate de cada instancia y completar una operación de actualización antes de ese momento. Para actualizar tu instancia, se requiere la aprobación del quórum, por lo que debes proponer la operación de actualización con suficiente anticipación para que se pueda aprobar y ejecutar antes del disableDate.

¿Qué sigue?