Arquitecturas de referencia de Cloud External Key Manager

Cuando habilitas Cloud Key Management Service (Cloud KMS) con Cloud External Key Manager (Cloud EKM), puedes usar las claves que gestionas con un partner de gestión de claves externo para proteger los datos enGoogle Cloud. En este documento se describen las arquitecturas para los Google Cloud clientes que quieran implementar un servicio de gestión de claves externo (EKM) de alta disponibilidad con Cloud KMS y Cloud EKM.

Usar Cloud EKM con tu servicio de EKM implica un equilibrio explícito entre la fiabilidad de la carga de trabajo en la nube y los controles de protección de datos. Si se cifran los datos en reposo en la nube con claves de cifrado fuera de la nube, se añaden nuevos riesgos de fallos que pueden provocar que los datos de los servicios se vuelvan inaccesibles. Google Cloud Para hacer frente a estos riesgos, debes incorporar la alta disponibilidad y la tolerancia a fallos en la arquitectura de Cloud EKM.

Información general

Cloud EKM te permite usar material de clave que permanece fuera de Google Cloud para controlar el acceso a tus datos almacenados en servicios Google Cloudadmitidos. Las claves de Cloud EKM son claves de encriptado gestionadas por el cliente (CMEK). Cloud EKM te permite crear y gestionar recursos de claves de Cloud KMS con los niveles de protección EXTERNAL y EXTERNAL_VPC. Cuando habilitas Cloud EKM, cada solicitud de operación criptográfica da como resultado una operación criptográfica en la clave externa. El éxito de la operación de solicitud inicial depende en gran medida del resultado de la operación criptográfica en la clave externa.

Cloud KMS solicita operaciones en claves externas mediante una API de propósito especial que se integra con tu sistema de gestión de claves externas. En este documento se hace referencia a un servicio que proporciona esta API como un servicio de EKM.

Si un servicio de EKM deja de estar disponible, es posible que se produzcan errores de lectura y escritura en los planos de datos de los servicios Google Cloud integrados. Estos errores se muestran de forma similar a los que se producen cuando la clave de Cloud KMS dependiente está en un estado inutilizable, por ejemplo, cuando está inhabilitada. En el mensaje de error se describe el origen del error y se indica qué se debe hacer. Además, los registros de auditoría de acceso a datos de Cloud KMS incluyen un registro de estos mensajes de error junto con tipos de errores descriptivos. Para obtener más información, consulta la referencia de errores de Cloud EKM.

Prácticas recomendadas para arquitecturas de Cloud EKM

En el libro Site Reliability Engineering de Google se describen las prácticas recomendadas para guiar el desarrollo y el mantenimiento de sistemas fiables. En esta sección se describen algunas de estas prácticas en el contexto de cómo se integra tu servicio de EKM con Google Cloud. Las siguientes prácticas recomendadas se aplican a las arquitecturas de referencia de Cloud EKM:

• Configurar una conectividad de red fiable y de baja latencia
• Habilitar alta disponibilidad
• Detectar y mitigar los fallos rápidamente

Configurar una conectividad de red fiable y de baja latencia

Cloud KMS se conecta a los servicios de EKM mediante una red de nube privada virtual (VPC) o Internet. Las soluciones de VPC suelen usar la conectividad híbrida para alojar el servicio EKM en un centro de datos local. La conexión entreGoogle Cloud y el centro de datos debe ser rápida y fiable. Cuando usas Internet, necesitas una accesibilidad estable e ininterrumpida y una resolución de DNS rápida y fiable. Desde el punto de vista de Google Cloud, cualquier interrupción puede provocar que el servicio de EKM no esté disponible y que no se pueda acceder a los datos protegidos con EKM.

Cuando el plano de datos de un Google Cloud servicio se comunica con el servicio de EKM, cada llamada vinculada al servicio de EKM tiene un periodo de tiempo de espera definido (150 milisegundos). El tiempo de espera se mide desde el servicio Cloud KMS en la Google Cloud ubicación de la clave de Cloud KMS. Si laGoogle Cloud ubicación es multirregional, el tiempo de espera empieza en la región en la que Cloud KMS recibe la solicitud, que suele ser la región en la que se ha producido la operación en el recurso de datos protegido con CMEK. Este tiempo de espera es suficiente para que un servicio de EKM gestione las solicitudes en unaGoogle Cloud región cercana a la que proceden las solicitudes.

El tiempo de espera ayuda a evitar errores en cascada en los servicios posteriores que dependen de la clave externa. Los problemas de latencia de cola que normalmente podrían provocar una mala experiencia de usuario en aplicaciones de nivel superior pueden manifestarse como accesos fallidos a la clave externa, lo que provoca un error en la operación lógica de nivel superior.

Para minimizar la latencia y crear redes fiables, ten en cuenta lo siguiente:

• Minimizar la latencia de la comunicación de ida y vuelta con Cloud KMS: configura el servicio EKM para que sirva las solicitudes lo más cerca posible de las Google Cloud ubicaciones que correspondan a las claves de Cloud KMS configuradas para usar el servicio EKM. Para obtener más información, consulta las prácticas recomendadas para seleccionar regiones de Compute Engine y las regiones y zonas.
• Usa Cloud Interconnect siempre que sea posible: Cloud Interconnect crea una conexión de alta disponibilidad y baja latencia entre Google Cloud y tu centro de datos mediante una red de VPC, lo que ayuda a eliminar las dependencias de Internet.
• Despliega Google Cloud soluciones de red en la región más cercana al servicio de EKM, cuando sea necesario: lo ideal es que las claves de Cloud KMS se almacenen en la región más cercana al servicio de EKM. Si hay unaGoogle Cloud región más cercana al servicio EKM que la región que contiene las claves de Cloud KMS, utiliza Google Cloud soluciones de redes, como Cloud VPN, en la región más cercana al servicio EKM. Esta opción ayuda a que el tráfico de red utilice la infraestructura de Google siempre que sea posible, lo que reduce la dependencia de Internet.
• Usa redes de nivel Premium cuando el tráfico de EKM transite por Internet: Nivel Premium dirige el tráfico a través de Internet mediante la infraestructura de Google siempre que sea posible para mejorar la fiabilidad y reducir la latencia.

Habilitar alta disponibilidad

La existencia de un único punto de fallo en el servicio de EKM reduce la disponibilidad de los recursos dependientes a la de ese único punto de fallo. Google Cloud Estos puntos de fallo pueden estar en dependencias críticas del servicio EKM, así como en la infraestructura de computación y de red subyacente.

Para habilitar la alta disponibilidad, ten en cuenta lo siguiente:

• Despliega réplicas en dominios de fallos independientes: despliega al menos dos réplicas del servicio EKM. Si usas ubicaciones multirregionales, Google Cloud implementa EKM en un mínimo de dos ubicaciones geográficas independientes con un mínimo de dos réplicas cada una. Asegúrate de que cada réplica no solo represente un plano de datos replicado del servicio EKM minimizando y reforzando los vectores de fallos entre réplicas. Ten en cuenta los siguientes ejemplos:
  • Configura los cambios de producción, incluidos los push de binarios y de configuración del servidor, para modificar solo una réplica a la vez. Verifica que todos los cambios se lleven a cabo bajo supervisión y que se puedan restaurar fácilmente.
  • Comprender y minimizar los modos de fallo entre réplicas de la infraestructura subyacente. Por ejemplo, asegúrate de que las réplicas dependan de fuentes de alimentación independientes y redundantes.

• Hacer que las réplicas sean resistentes a las interrupciones de una sola máquina: comprueba que cada réplica del servicio conste de al menos tres dispositivos, máquinas o hosts de máquinas virtuales. Esta configuración permite que el sistema sirva tráfico mientras una máquina está inactiva por actualizaciones o durante una interrupción inesperada (aprovisionamiento N+2).

• Limita el área afectada por los problemas del plano de control: configura el plano de control (por ejemplo, la creación o eliminación de claves) del servicio EKM para replicar la configuración o los datos en las réplicas. Estas operaciones suelen ser más complejas porque requieren sincronización y afectan a todas las réplicas. Los problemas pueden propagarse rápidamente y afectar a todo el sistema. Algunas estrategias para reducir el impacto de los problemas son las siguientes:

  • Controlar la velocidad de propagación: de forma predeterminada, asegúrate de que los cambios se propaguen con la lentitud que sea aceptable para la usabilidad y la seguridad. Configura excepciones cuando sea necesario, por ejemplo, cuando permitas que el acceso a una clave se propague rápidamente para que un usuario pueda deshacer un error.
  • Divide el sistema en particiones: si muchos usuarios comparten la EKM, divídelos en particiones lógicas que sean completamente independientes para que los problemas que provoque un usuario en una partición no afecten a los usuarios de otra.
  • Previsualiza el efecto de los cambios: si es posible, permite que los usuarios vean el efecto de los cambios antes de aplicarlos. Por ejemplo, al modificar una política de acceso a claves, el EKM podría confirmar el número de solicitudes recientes que se habrían rechazado con la nueva política.
  • Implementa la prueba canario de datos: primero, envía los datos solo a un pequeño subconjunto del sistema. Si el subconjunto sigue funcionando correctamente, envía los datos al resto del sistema.

• Implementa comprobaciones del estado integrales: crea comprobaciones del estado que midan si todo el sistema funciona. Por ejemplo, las comprobaciones del estado que solo validan la conectividad de red no son útiles para responder a muchos problemas a nivel de aplicación. Lo ideal es que la comprobación de estado refleje las dependencias del tráfico real.

• Configura la conmutación por error entre réplicas: configura el balanceo de carga en los componentes de tu servicio EKM para que consuma las comprobaciones de estado y drene activamente el tráfico de las réplicas que no estén en buen estado, así como para que conmute por error de forma segura a las réplicas que sí lo estén.

• Incluye mecanismos de seguridad para gestionar la sobrecarga y evitar fallos en cascada: los sistemas pueden sobrecargarse por varios motivos. Por ejemplo, si algunas réplicas no están en buen estado, el tráfico redirigido a las réplicas en buen estado podría sobrecargarlas. Cuando se enfrente a más solicitudes de las que puede atender, el sistema debe intentar atender las que pueda de forma segura y rápida, al tiempo que rechaza el tráfico excesivo.

• Asegúrate de que la durabilidad sea sólida: los datos de Google Cloud que se encriptan con una clave externa en el servicio EKM no se pueden recuperar sin la clave externa. Por lo tanto, la durabilidad de las claves es uno de los requisitos de diseño centrales del servicio EKM. Configura el servicio EKM para crear copias de seguridad redundantes del material de claves de forma segura en varias ubicaciones físicas. Configura medidas de protección adicionales, como copias de seguridad sin conexión, para las claves de alto valor. Asegúrate de que tus mecanismos de eliminación permitan recuperar los datos en caso de que se produzcan accidentes y errores.

Detectar y mitigar los fallos rápidamente

Por cada minuto que el servicio EKM sufra una interrupción, es posible que no se pueda acceder a los recursos dependientes, lo que puede aumentar aún más la probabilidad de que se produzca un fallo en cascada de otros componentes dependientes de tu infraestructura. Google Cloud

Para detectar y mitigar los fallos rápidamente, ten en cuenta lo siguiente:

• Configura el servicio de EKM para que registre métricas que indiquen incidentes que supongan un riesgo para la fiabilidad: configura métricas como las tasas de errores de respuesta y las latencias de respuesta para detectar problemas rápidamente.
• Configura prácticas operativas para recibir notificaciones y mitigar incidentes a tiempo: cuantifica la eficacia de las prácticas operativas monitorizando las métricas de tiempo medio de detección (MTTD) y tiempo medio de restauración (MTTR), y define objetivos que se midan con estas métricas. Con estas métricas, puedes identificar patrones y deficiencias en los procesos y sistemas actuales para responder rápidamente a los incidentes.

Arquitecturas de referencia de Cloud EKM

En las siguientes arquitecturas se describen algunas formas de implementar el servicio EKM medianteGoogle Cloud productos de redes y balanceo de carga.

Conexión directa a través de Cloud VPN o Cloud Interconnect

Se recomienda una conexión directa entre Google Cloud y tu centro de datos local cuando ejecutes aplicaciones de alto rendimiento enGoogle Cloud y el servicio EKM se ejecute en un solo centro de datos. En el siguiente diagrama se muestra esta arquitectura.

En esta arquitectura, Cloud EKM accede al servicio EKM ubicado en un centro de datos local a través de la conectividad híbrida de la región, sin ningún balanceo de carga intermedio en Google Cloud.

Cuando sea posible, implementa la conexión de servicio de Cloud EKM a EKM con la configuración de disponibilidad del 99,9% para aplicaciones de una sola región. La configuración de disponibilidad del 99,99% requiere usar Cloud Interconnect en varias Google Cloudregiones, lo que puede no satisfacer tus necesidades si tu empresa requiere aislamiento regional. Si la conexión al centro de datos on-premise usa Internet, utiliza VPN de alta disponibilidad en lugar de Cloud Interconnect.

La principal ventaja de esta arquitectura es que no hay saltos intermedios en Google Cloud, lo que reduce la latencia y los posibles cuellos de botella. Si quieres configurar una conexión directa cuando tu servicio de EKM esté alojado en varios centros de datos, debes configurar balanceadores de carga en todos los centros de datos que utilicen la misma dirección IP (anycast). Si usa esta configuración, el balanceo de carga y la conmutación por error entre centros de datos se limitarán a la disponibilidad de las rutas.

Si configura una red de VPC, las claves externas a las que se acceda a través de la red de VPC deben usar una ubicación regional en Cloud KMS. Las claves no pueden usar una ubicación multirregional. Para obtener más información, consulta Gestores de claves externos y regiones.

Balanceo de carga desde Internet en Google Cloud

Se recomienda usar un balanceador de carga con una conexión a Internet cuando necesites claves de Cloud KMS multirregionales. Google Cloud En el siguiente diagrama se muestra esta arquitectura.

En esta arquitectura, EKM tiene réplicas en dos sitios locales. Cada backend se representa en Google Cloud mediante un grupo de extremos de red (NEG) de conectividad híbrida. La implementación usa un balanceador de carga de red de proxy externo para reenviar el tráfico directamente a una de las réplicas. A diferencia de los otros métodos, que se basan en la red de VPC, el balanceador de carga de red del proxy externo tiene una dirección IP externa y el tráfico procede de Internet.

Cada NEG de conectividad híbrida puede contener varias direcciones IP, lo que permite que el balanceador de carga de red del proxy externo balancee el tráfico directamente a las instancias del servicio EKM. No es necesario un balanceador de carga adicional en el centro de datos local.

El balanceador de carga de red del proxy externo no está vinculado a una región específica. Puede dirigir el tráfico entrante a la región sana más cercana, por lo que es adecuada para las claves de Cloud KMS multirregionales. Sin embargo, el balanceador de carga no permite configurar backends principales y de conmutación por error. El tráfico se distribuye de forma uniforme entre varios backends de una región.

Balanceo de carga en una red de VPC en Google Cloud

Se recomienda usar un balanceador de carga en Google Cloud con una red de VPC para la mayoría de los servicios de EKM en los que implementes tu EKM. En el siguiente diagrama se muestra esta arquitectura.

En esta arquitectura, Cloud EKM accede al servicio EKM que se replica entre dos centros de datos on-premise a través de la conectividad híbrida con capas de balanceo de carga intermedias en la Google Cloud región. Si la conexión al centro de datos on-premise usa Internet, puedes usar VPN de alta disponibilidad en lugar de Cloud Interconnect.

El balanceador de carga de red de paso a través interno proporciona una única dirección IP que los recursos pueden usar para enviar tráfico mediante redes virtuales. El balanceador de carga conmuta al centro de datos de copia de seguridad en función del estado de los backends.

El grupo de instancias de máquina virtual es necesario para proxy el tráfico, ya que el balanceador de carga interno no puede enrutar el tráfico directamente a los backends locales. Puedes desplegar proxies de balanceador de carga para ejecutar imágenes Docker de Nginx desde Cloud Marketplace en grupos de instancias. Puedes usar Nginx como balanceador de carga TCP.

Como este método usa balanceadores de carga en Google Cloud, no necesitas un balanceador de carga local. Los Google Cloud balanceadores de carga pueden conectarse directamente a instancias del servicio EKM y equilibrar la carga entre ellas. Al eliminar el balanceador de carga local, la configuración es más sencilla, pero se reduce la flexibilidad disponible en el servicio de EKM. Por ejemplo, un balanceador de carga de nivel 7 local podría volver a intentar automáticamente las solicitudes si una instancia de EKM devuelve un error.

Si configura una red de VPC, las claves externas a las que se acceda a través de la red de VPC deben usar una ubicación regional en Cloud KMS. Las claves no pueden usar una ubicación multirregional. Para obtener más información, consulta Gestores de claves externos y regiones.

Comparación de arquitecturas de referencia

En la siguiente tabla se comparan las opciones de arquitectura de referencia de Cloud EKM. La tabla también incluye una columna para la arquitectura de EKM gestionada por partners. En este caso, el partner es responsable de implementar y gestionar la EKM, y proporciona la EKM como servicio a los clientes.

Opción	Conexión directa	Balanceo de carga desde Internet	Balanceo de carga en una red de VPC	EKM totalmente gestionado proporcionado por un partner
Internet o red de VPC	VPC	Internet	VPC	Internet
Balanceador de carga en Google Cloud	No	Sí	Sí	No
Se requiere un balanceador de carga local	Sí	No	No	Sí (gestionado por partner)
Admite ubicaciones multirregionales de Cloud KMS	No	Sí	No	Sí
Se recomienda para	Aplicaciones de alto rendimiento en las que el servicio EKM se ejecuta en un solo sitio.	Cuando se necesitan claves de Cloud KMS multirregionales.	La mayoría de los servicios de EKM en los que implementas tu propio EKM.	Puedes usar la EKM de un partner en lugar de implementar la tuya.

Siguientes pasos

• Consulta más información sobre la seguridad de Cloud KMS.
• Crea una conexión EKM a través de una red VPC.
• Configura Cloud EKM a través de Internet.