Información general sobre Cloud HSM de un solo inquilino

En este documento se ofrece una descripción general de los conceptos y las funciones de Cloud HSM de único cliente.

Cloud HSM de un solo inquilino te permite crear y gestionar una instancia de Cloud HSM de un solo inquilino. Una instancia de Cloud HSM de un solo inquilino es un clúster dedicado de particiones en módulos de seguridad de hardware (HSMs) para tu uso exclusivo. Cada instancia proporciona la misma redundancia y alta disponibilidad que Cloud HSM multiinquilino. Cada clúster de Cloud HSM de un solo inquilino se distribuye en varios HSMs de varias zonas de la región seleccionada. Cada partición está aislada criptográficamente de otras particiones del HSM.

Puedes conceder o denegar el acceso de Google a tu clúster, y tus administradores de instancias gestionan el clúster. Los administradores de instancias controlan la instancia mediante un modelo de aprobación por 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 forma que Google nunca tenga acceso a tus claves de control privadas.

Una vez configurada la instancia de Cloud HSM de un solo inquilino, los administradores de Cloud KMS pueden crear claves de un solo inquilino y los desarrolladores pueden usarlas como cualquier otra clave de Cloud HSM, sin necesidad de modificar el código.

Usar Cloud HSM de único cliente conlleva costes. Para obtener información sobre los precios, consulta los precios de Cloud KMS.

Autenticación basada en quórum

Cloud HSM de un solo inquilino usa la autenticación basada en quórum para asegurarse de que varios administradores de instancias aprueben las operaciones críticas. Antes de crear una instancia de un solo inquilino, 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á gestionada por cinco administradores, puedes requerir que tres de ellos aprueben cada operación de mantenimiento en la instancia.

Las operaciones que requieren autenticación por quórum tienen tres fases:

  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 caducan al cabo de 24 horas y se pueden cancelar en cualquier momento hasta que se inicie la operación aprobada.

  2. Aprobación: el número necesario de administradores debe firmar las peticiones con su llave de control única. Cada reto firmado indica un administrador que aprueba la operación. Cuando haya suficientes retos firmados, un administrador de la instancia los subirá para aprobar la propuesta. Si los retos son válidos y la propuesta no ha caducado, se aprueba.

  3. Ejecución: después de que se apruebe una propuesta, pero antes de que caduque, puedes ejecutar la operación propuesta.

Funciones de Cloud HSM de un solo inquilino

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

Gestión de instancias

Tus administradores gestionan el ciclo de vida de tus instancias de Cloud HSM de un solo inquilino.

  • Crear una instancia: aprovisiona una nueva instancia en una sola región. Para crear un clúster, debes configurar la autenticación por cuórum.
  • Obtener información de la instancia: puedes consultar los metadatos y la configuración de una instancia. Esta operación no requiere autenticación de quórum.
  • Inhabilitar y habilitar una instancia: puedes inhabilitar una instancia temporalmente, lo que revoca el acceso de Google a las particiones. Puedes habilitar la instancia más adelante. Ambas operaciones requieren autenticación por quórum. Si habilitas tu instancia, el disableDate se restablecerá a 120 días a partir del momento en que se realice la operación. Mientras una instancia esté inhabilitada, todas las claves creadas en ella no estarán disponibles y todas las operaciones que intenten usar esas claves fallarán.
  • Actualizar una instancia: debes actualizar tu instancia con regularidad para que esté disponible. Las instancias deben actualizarse cada 120 días o menos. Cada instancia tiene un disableDate que indica cuándo se debe actualizar la instancia. Al actualizar tu instancia, el disableDate se restablece 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 las disableDate se inhabilitarán automáticamente.
  • Eliminar una instancia: puedes eliminar una instancia. Si eliminas una instancia, se destruirán de forma permanente todas las claves que se hayan creado en ella. Esta es una operación destructiva e irreversible. No elimines una instancia a menos que quieras destruir criptográficamente todos los datos cifrados con claves creadas en la instancia. Esta operación requiere autenticación de quórum.

Gestión de claves

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

  • Rotar las llaves de control de administrador: los administradores pueden rotar la llave de control de la autenticación de dos factores de un miembro del quórum administrativo. Esta operación requiere autenticación por cuórum.
  • Generar claves criptográficas: tus desarrolladores y propietarios de recursos pueden crear un CryptoKey con un nivel de protección de HSM de un solo inquilino. Esta operación no requiere autenticación de quórum.
  • Realizar operaciones criptográficas: una vez creadas, las claves almacenadas en una instancia de un solo inquilino se pueden usar para realizar operaciones criptográficas igual que cualquier otra clave de Cloud Key Management Service.

Prácticas recomendadas para Cloud HSM de un solo inquilino

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

  • Retenciones de proyectos: usa retenciones de proyectos para proteger proyectos que contengan instancias de HSM de Cloud de un solo inquilino activas. Si eliminas un proyecto que contiene una instancia de Cloud HSM de un solo inquilino, las claves creadas en esa instancia no se podrán recuperar.
  • Tokens físicos: usa tokens físicos para almacenar las claves privadas de la autenticación de dos factores 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. Como las instancias deben actualizarse periódicamente, si se pierde un quórum de claves, la instancia se inhabilita.
  • Llaves de repuesto: registra al menos una llave de 2FA de repuesto además de las llaves que tengan los miembros del quórum. Guarda las claves de respaldo en un lugar seguro al que puedas acceder si se pierde o se roba la clave de un miembro del quórum.
  • Separación de funciones: mantén la separación de funciones de los administradores de tu instancia. Para proponer, aprobar y ejecutar cambios, se necesitan roles de gestión de identidades y accesos independientes, que deben distribuirse entre al menos dos personas para que ninguna de ellas tenga los permisos de los tres roles. Si un usuario tiene todos los permisos subyacentes, hay un mayor riesgo de pérdida de datos accidental o intencionada.
  • Distribución de las claves: asegúrate de que tus claves privadas de 2FA se distribuyan de forma segura entre personas de confianza. Ninguna persona debe conservar suficientes claves privadas para alcanzar el quórum. Si una persona tiene acceso a suficientes claves privadas para alcanzar el tamaño de quórum necesario, hay un mayor riesgo de pérdida de datos accidental o intencionada.
  • Programación de actualización: incorpora la actualización de tus instancias de Cloud HSM de un solo inquilino a tus procedimientos de mantenimiento habituales. Debes monitorizar el disableDate de cada instancia y completar una operación de actualización antes de ese momento. Para actualizar tu instancia, se necesita la aprobación del quórum, así que asegúrate de proponer la operación de actualización con suficiente antelación para que se pueda aprobar y ejecutar antes del disableDate.

Siguientes pasos