Cuando habilitas Cloud Key Management Service (Cloud KMS) con Cloud External Key Manager (Cloud EKM), puedes usar las claves que administras con un socio de administración de claves externo para ayudar a proteger los datos enGoogle Cloud. En este documento, se describen las arquitecturas para los clientes de Google Cloud que desean implementar un servicio de administrador de claves externo (EKM) de alta disponibilidad con Cloud KMS y Cloud EKM.
El uso de Cloud EKM con tu servicio de EKM implica una compensación de riesgo explícita entre la confiabilidad de la carga de trabajo en la nube y los controles de protección de datos. La encriptación de datos en reposo en la nube con claves de encriptación fuera de la nube agrega nuevos riesgos de fallas que podrían hacer que los datos de los servicios de Google Cloud sean inaccesibles. Para abordar estos riesgos, debes incorporar la alta disponibilidad y la tolerancia a fallas en la arquitectura de Cloud EKM.
Descripción general
Cloud EKM te permite usar material clave que permanece fuera de Google Cloud para controlar el acceso a tus datos que se almacenan en servicios Google Cloudcompatibles. Las claves de EKM de Cloud son claves de encriptación administradas por el cliente (CMEK).
Cloud EKM te permite crear y administrar 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 genera una operación
criptográfica en la clave externa. El éxito de la operación de solicitud inicial depende de manera fundamental del resultado de la operación criptográfica en la clave externa.
Cloud KMS solicita operaciones en claves externas con una API de propósito especial que se integra a tu sistema de administración de claves externo. 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 las operaciones de lectura y escritura de los planos de datos de los servicios integrados de Google Cloud fallen. Estas fallas aparecen de una manera similar a las fallas que se producen cuando la clave de Cloud KMS dependiente está en un estado inutilizable, por ejemplo, cuando está inhabilitada. El mensaje de error describe la fuente del error y una medida que se puede tomar. Además, los registros de auditoría de acceso a los datos de Cloud KMS incluyen un registro de estos mensajes de error junto con tipos de error descriptivos. Para obtener más información, consulta la referencia de errores de Cloud EKM.
Prácticas recomendadas para arquitecturas de EKM de Cloud
En el libro Ingeniería de confiabilidad de sitios de Google, se describen las prácticas recomendadas para guiar el desarrollo y el mantenimiento de sistemas confiables. 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 EKM de Cloud:
- Configura una conectividad de red confiable y de baja latencia
- Habilitar la alta disponibilidad
- Detecta y mitiga las fallas rápidamente
Configura una conectividad de red confiable y de baja latencia
Cloud KMS se conecta a los servicios de EKM a través de una red de nube privada virtual (VPC) o Internet. Las soluciones de VPC suelen usar conectividad híbrida para alojar el servicio de EKM en un centro de datos local. La conexión entreGoogle Cloud y el centro de datos debe ser rápida y confiable. Cuando usas Internet, necesitas una accesibilidad estable y sin interrupciones, y una resolución de DNS rápida y confiable. Desde el punto de vista de Google Cloud, cualquier interrupción puede generar la falta de disponibilidad del servicio de EKM y la posible incapacidad para acceder a los datos protegidos por EKM.
Cuando el plano de datos de un servicio de Google Cloud se comunica con el servicio de EKM, cada llamada vinculada al servicio de EKM tiene un tiempo de espera definido (150 milisegundos). El tiempo de espera se mide desde el servicio de Cloud KMS en la ubicación de Google Cloud de la clave de Cloud KMS. Si la ubicación de Google Cloud es multirregional, el tiempo de espera comienza en la región donde Cloud KMS recibe la solicitud, que suele ser donde ocurrió la operación en el recurso de datos protegido por CMEK. Este tiempo de espera es adecuado para permitir que un servicio de EKM controle las solicitudes en una región cercana deGoogle Cloud desde la que se originan las solicitudes.
El tiempo de espera ayuda a evitar fallas en cascada en los servicios downstream que dependen de la clave externa. Los problemas de latencia de cola que, por lo general, pueden causar una experiencia del usuario deficiente en aplicaciones de nivel superior, en realidad, pueden manifestarse como accesos fallidos a la clave externa, lo que genera un error en la operación lógica de nivel superior.
Para minimizar la latencia y crear redes confiables, considera lo siguiente:
- Minimiza la latencia de la comunicación de ida y vuelta con Cloud KMS: Configura el servicio de EKM para que entregue solicitudes lo más cerca posible geográficamente de las ubicaciones de Google Cloud que correspondan a las claves de Cloud KMS configuradas para usar el servicio de EKM. Para obtener más información, consulta Prácticas recomendadas para la selección de regiones de Compute Engine y Regiones y zonas.
- Usa Cloud Interconnect siempre que sea posible: Cloud Interconnect crea una conexión de baja latencia y alta disponibilidad entre Google Cloud y tu centro de datos mediante una red de VPC y ayuda a quitar las dependencias de Internet.
- Implementa Google Cloud soluciones de red en la región más cercana al servicio de EKM cuando sea necesario: Idealmente, las claves de Cloud KMS se almacenan en la región más cercana al servicio de EKM. Si hay una región de Google Cloud que esté más cerca del servicio de EKM que la región que contiene las claves de Cloud KMS, usa las soluciones de redes de Google Cloud , como Cloud VPN, en la región más cercana al servicio de EKM. Esta opción ayuda a garantizar que el tráfico de red use 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: El nivel Premium enruta el tráfico a través de Internet con la infraestructura de Google siempre que sea posible para mejorar la confiabilidad y reducir la latencia.
Habilitar la alta disponibilidad
La existencia de un punto único de fallo en el servicio de EKM reduce la disponibilidad de los recursos dependientes de Google Cloud a la del punto único de fallo. Estos puntos de falla pueden residir en dependencias críticas del servicio de EKM, así como en la infraestructura de procesamiento y red subyacente.
Para habilitar la alta disponibilidad, ten en cuenta lo siguiente:
- Implementa réplicas en dominios de fallas independientes: Implementa al menos dos réplicas del servicio de EKM. Si usas ubicaciones Google Cloud
multirregionales, implementa EKM en un mínimo de dos ubicaciones geográficas separadas 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 de EKM minimizando y endureciendo los vectores de fallas entre réplicas. Considera los siguientes ejemplos:
- Configura los cambios de producción, incluidos los envíos de configuración y objetos binarios del servidor, para modificar solo una réplica a la vez. Verifica que todos los cambios se realicen bajo supervisión, con reversiones probadas disponibles de inmediato.
- Comprender y minimizar los modos de falla de replicación cruzada de la infraestructura subyacente Por ejemplo, asegúrate de que las réplicas dependan de feeds de energía independientes y redundantes.
Haz que las réplicas sean resilientes a las interrupciones de una sola máquina: Verifica que cada replicación del servicio conste de al menos tres dispositivos, máquinas o hosts de VM. Esta configuración permite que el sistema entregue 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 de EKM para replicar la configuración o los datos en todas las réplicas. Por lo general, estas operaciones son 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. Estas son algunas estrategias para reducir el impacto de los problemas:
- Controla la velocidad de propagación: De forma predeterminada, asegúrate de que los cambios se propaguen lo más lentamente posible para la usabilidad y la seguridad. Establece excepciones cuando sea necesario, por ejemplo, cuando permitas el acceso a una clave para que se propague rápidamente y permita que un usuario deshaga un error.
- Particiona el sistema en fragmentos: Si muchos usuarios comparten la EKM, particiona los fragmentos lógicos que son completamente independientes, de modo que los problemas que activa un usuario en un fragmento no puedan afectar a los usuarios de otro.
- Obtén una vista previa del efecto de los cambios: Si es posible, permite que los usuarios vean el efecto de los cambios antes de aplicarlos. Por ejemplo, cuando se modifica una política de acceso a claves, el EKM podría confirmar la cantidad de solicitudes recientes que se habrían rechazado según la política nueva.
- Implementa el canarying de datos: Primero, envía los datos solo a un subconjunto pequeño del sistema. Si el subconjunto sigue en buen estado, envía los datos al resto del sistema.
Implementa verificaciones de estado integrales: Crea verificaciones de estado que midan si todo el sistema funciona. Por ejemplo, las verificaciones de estado que solo validan la conectividad de red no son útiles para responder a muchos problemas a nivel de la aplicación. Idealmente, la verificación de estado refleja de cerca las dependencias del tráfico real.
Configura la conmutación por error en todas las réplicas: Configura el balanceo de cargas en los componentes de tu servicio de EKM para que consuma las verificaciones de estado y drene de forma activa el tráfico de las réplicas en mal estado y realice una conmutación por error de forma segura a las réplicas en buen estado.
Incluye mecanismos de seguridad para administrar la sobrecarga y evitar fallas en cascada: Los sistemas pueden sobrecargarse por varios motivos. Por ejemplo, cuando algunas réplicas se encuentran en mal estado, el tráfico redireccionado a las réplicas en buen estado podría sobrecargarlas. Cuando se enfrenta a más solicitudes de las que puede entregar, el sistema debe intentar entregar lo que pueda de forma segura y rápida, y rechazar el exceso de tráfico.
Garantizar una historia de durabilidad sólida: Los datos de Google Cloud que se encriptan con una clave externa en el servicio de 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 de EKM. Configura el servicio de EKM para crear copias de seguridad de forma segura de copias redundantes del material de claves 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 tiempo para la recuperación en caso de accidentes y errores.
Detecta y mitiga las fallas rápidamente
Por cada minuto que el servicio de EKM sufre una interrupción, es posible que no se pueda acceder a los recursos de Google Clouddependientes, lo que puede aumentar aún más la probabilidad de una falla en cascada de otros componentes dependientes de tu infraestructura.
Para detectar y mitigar las fallas rápidamente, ten en cuenta lo siguiente:
- Configura el servicio de EKM para que informe métricas que indiquen incidentes que amenazan la confiabilidad: Configura métricas como las tasas de error de respuesta y las latencias de respuesta para detectar problemas con rapidez.
- Establece prácticas operativas para notificar y mitigar incidentes de forma oportuna: Cuantifica la eficacia de las prácticas operativas haciendo un seguimiento de las métricas de tiempo promedio de detección (MTTD) y tiempo promedio de restablecimiento (MTTR), y define los objetivos que miden estas métricas. Con estas métricas, puedes encontrar patrones y deficiencias en los procesos y sistemas actuales para responder rápidamente a los incidentes.
Arquitecturas de referencia para Cloud EKM
En las siguientes arquitecturas, se describen algunas formas de implementar el servicio de EKM con productos de redes y balanceo de cargas deGoogle Cloud .
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 ejecutas aplicaciones de alta productividad enGoogle Cloud y el servicio de EKM se ejecuta en un solo centro de datos. En el siguiente diagrama, se muestra esta arquitectura.
En esta arquitectura, Cloud EKM accede al servicio de EKM ubicado en un centro de datos on-premises a través de conectividad híbrida en la región sin ningún balanceo de cargas 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 el uso de Cloud Interconnect en varias regiones de Google Cloud, lo que podría no satisfacer tus necesidades si tu empresa requiere aislamiento regional. Si la conexión al centro de datos local usa Internet, usa VPN con 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 deseas configurar una conexión directa cuando tu servicio de EKM se aloja en varios centros de datos, debes configurar balanceadores de cargas en todos los centros de datos que usen la misma dirección IP (anycast). Si usas esta configuración, el balanceo de cargas y la conmutación por error entre centros de datos se limitan solo a la disponibilidad de la ruta.
Si configuras una red de VPC, las claves externas a las que se accede 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 Administradores y regiones de claves externas.
Balanceo de cargas desde Internet en Google Cloud
Se recomienda usar un balanceador de cargas en Google Cloud con una conexión a Internet cuando necesites claves de Cloud KMS multirregionales. En el siguiente diagrama, se muestra esta arquitectura.
En esta arquitectura, el EKM tiene réplicas en dos sitios locales. Cada backend se representa en Google Cloud con un grupo de extremos de red (NEG) de conectividad híbrida. La implementación usa un balanceador de cargas de red de proxy externo para reenviar el tráfico directamente a una de las réplicas. A diferencia de los otros enfoques, que dependen de las redes de VPC, el balanceador de cargas de red de proxy externo tiene una dirección IP externa, y el tráfico proviene de Internet.
Cada NEG de conectividad híbrida puede contener varias direcciones IP, lo que permite que el balanceador de cargas de red del proxy externo balancee el tráfico directamente a las instancias del servicio de EKM. No se necesita un balanceador de cargas adicional en el centro de datos local.
El balanceador de cargas de red de proxy externo no está vinculado a una región específica. Puede dirigir el tráfico entrante a la región en buen estado más cercana, lo que lo hace adecuado para claves de Cloud KMS multirregionales. Sin embargo, el balanceador de cargas no permite la configuración de backends principales y de conmutación por error. El tráfico se distribuye de manera uniforme entre varios backends de una región.
Balanceo de cargas en una red de VPC en Google Cloud
Se recomienda usar un balanceador de cargas 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 de EKM que se replica entre dos centros de datos locales a través de conectividad híbrida con capas de balanceo de cargas intermedias en la región de Google Cloud . Si la conexión al centro de datos local usa Internet, puedes usar VPN con alta disponibilidad en lugar de Cloud Interconnect.
El balanceador de cargas de red de transferencia interno proporciona una sola dirección IP que los recursos pueden usar para enviar tráfico a través de redes virtuales. El balanceador de cargas redirecciona el tráfico al centro de datos de copia de seguridad según el estado de los backends.
El grupo de instancias de VM es necesario para el proxy de tráfico, ya que el balanceador de cargas interno no puede enrutar el tráfico directamente a los backends locales. Puedes implementar proxies de balanceador de cargas para ejecutar imágenes de Docker de Nginx desde Cloud Marketplace en grupos de instancias. Puedes usar Nginx como balanceador de cargas TCP.
Debido a que este enfoque usa balanceadores de cargas en Google Cloud, no necesitas un balanceador de cargas en las instalaciones. Los balanceadores de cargas de Google Cloud pueden conectarse directamente a instancias del servicio de EKM y equilibrar la carga entre ellas. Si se elimina el balanceador de cargas local, se obtiene una configuración más simple, pero se reduce la flexibilidad disponible en el servicio de EKM. Por ejemplo, un balanceador de cargas de L7 local podría reintentar automáticamente las solicitudes si una instancia de EKM muestra un error.
Si configuras una red de VPC, las claves externas a las que se accede 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 Administradores y regiones de claves externas.
Comparación de arquitecturas de referencia
En la siguiente tabla, se comparan las opciones de arquitectura de referencia para EKM de Cloud. La tabla también incluye una columna para la arquitectura de EKM administrada por socios. En esta situación, el socio es responsable de implementar y administrar el EKM, y lo proporciona como servicio a los clientes.
| Opción | Conexión directa | Balanceo de cargas desde Internet | Balanceo de cargas en una red de VPC | EKM completamente administrado que proporciona el socio |
|---|---|---|---|---|
Internet o red de VPC |
VPC |
Internet |
VPC |
Internet |
Balanceador de cargas en Google Cloud |
No |
Sí |
Sí |
No |
Se requiere un balanceador de cargas local |
Sí |
No |
No |
Sí (administrado por el socio) |
Admite ubicaciones multirregionales de Cloud KMS |
No |
Sí |
No |
Sí |
Recomendado para |
Aplicaciones de alta capacidad de procesamiento en las que el servicio de EKM se ejecuta en un solo sitio. |
Cuando se requieren claves de Cloud KMS multirregionales. |
La mayoría de los servicios de EKM en los que implementas tu propio EKM |
Puedes usar el EKM de un socio en lugar de implementar el tuyo. |
¿Qué sigue?
- Obtén más información sobre la seguridad de Cloud KMS.
- Crea una conexión de EKM a través de una red de VPC.
- Configura Cloud EKM a través de Internet.