Protección de una plataforma distribuida: identidad, secretos y gestión de claves

Este es el tercer blog de una serie que cubre diversos aspectos de lo que nos llevó construir y operar nuestro servicio SaaS : 

1. Plano de control para PaaS de Kubernetes distribuido
2. Malla de servicios global para aplicações distribuidas
3. Seguridad de la plataforma para infraestructura distribuida, aplicaciones y datos 
4. Seguridad de aplicação y redes de clústeres distribuidos
5. Observabilidad en una plataforma distribuida globalmente
6. Operaciones y SRE de una plataforma distribuida globalmente 
7. Marco de servicios Golang para microservicios distribuidos

Mi blog inicial proporcionó algunos antecedentes sobre las necesidades que nos llevaron a construir una nueva plataforma para nubes distribuidas. Al utilizar esta plataforma, nuestros clientes crean un conjunto complejo y diverso de aplicações , como fabricación inteligente, análisis forense de video para seguridad pública, comercio algorítmico y redes de telecomunicaciones 5G.

Dado que muchas de estas aplicações son de misión crítica, nuestros clientes esperan que no solo ofrezcamos seguridad de múltiples capas, sino que también tengamos la capacidad de realizar mejoras continuas para mantener seguros sus clústeres distribuidos. Este blog específico abordará los desafíos de proteger la infraestructura, las aplicações y los datos en múltiples clústeres.

TL;DR (Resumen)

1. Si bien se entiende relativamente bien cómo brindar acceso seguro a los usuarios y empleados a las aplicações (lo hacemos todos los días cuando accedemos a nuestras cuentas bancarias o a nuestros correos electrónicos corporativos), no es tan sencillo hacer lo mismo para el acceso de aplicación a aplicación o de aplicación a datos, ya que no hay ningún ser humano involucrado en el proceso de verificación.
2. Proteger las aplicaciones y los datos en un entorno heterogéneo (borde, múltiples nubes y PoP de red) nos exigió resolver un problema de múltiples capas: identidad, autenticación y autorización, secretos y gestión de claves.
3. Si bien hay muchas soluciones puntuales disponibles (por ejemplo, múltiples servicios de proveedores de nube individuales, Hashicorp Vault, SPIFFE/Spire, etc.) para estos cuatro problemas, no existe una solución integrada que funcione con todos los proveedores de nube o que combine perfectamente cada uno de estos servicios para facilitar su uso.
4. Dada la falta de experiencia dentro de nuestros equipos de desarrolladores y DevOps sobre cómo unir estas piezas, se volvió esencial para nuestro equipo de plataforma ofrecer estas capacidades como una solución integrada que fuera fácil de usar. El cambiante panorama de seguridad y las nuevas tecnologías hacen que la tarea sea aún más difícil para estos equipos, ya que no cuentan con la experiencia necesaria ni el ancho de banda para mantenerse al día con todos los cambios.
5. Como parte de la entrega de seguridad de plataforma multicapa, construimos nuevos componentes de software que resolvieron tres problemas críticos de una manera completamente nueva: iniciar de forma segura una identidad universal que no sufre el problema de las "tortugas hasta el final", secretos que pueden almacenarse y distribuirse sin preocuparse nunca por el compromiso de una bóveda central (problema de la mina de oro) y administración de claves distribuidas para facilitar la seguridad de los datos en reposo.

Antecedentes del problema de seguridad

Como se mencionó anteriormente, el problema de proteger el acceso de los usuarios a las aplicações (por ejemplo, el acceso a nuestras cuentas bancarias o nuestros correos electrónicos) es bien comprendido. Sin embargo, no es tan sencillo hacer lo mismo para el acceso de aplicación a aplicación o de aplicación a datos, ya que no hay ninguna persona involucrada en el proceso de verificación.

Para que una aplicação acceda a otro recurso de manera segura (por ejemplo, datos almacenados en un almacén de objetos o realice una llamada API a otra aplicação, etc.), debe suceder lo siguiente: 

1. Identidad : el solicitante debe adquirir de forma segura una identidad verificable que pueda usarse para fines de autenticación y autorización al acceder a los recursos requeridos. El solicitante también debe estar provisto de forma segura de los anclajes de confianza necesarios que se puedan usar para verificar las identidades de sus pares. 
    
2. Autenticación : en el proceso de acceso a un recurso determinado, el solicitante y el propietario del recurso deben verificar de forma segura la identidad de cada uno. El proceso de verificar la identidad declarada de un par contra la identidad presentada se llama Autenticación. 
    
3. Autorización : una vez que el solicitante está autenticado, el proceso de verificar si tiene permiso para acceder al recurso (o no) se denomina Autorización.

Como parte del proceso de autenticación, la aplicação solicitante puede presentar su identidad en forma de un certificado PKI o un secreto (por ejemplo, una contraseña) o una clave. Hay dos cuestiones que deben abordarse cuando se utilizan secretos o una clave para la identidad: 

• Los secretos y las claves no deben almacenarse directamente en el código, ya que es un vector de ataque fácil y las claves filtradas pueden ser un gran problema. 
• Si los secretos se almacenan en una bóveda externa, ¿qué identidad (generalmente otro secreto) se debe utilizar para obtener el secreto y cómo protegemos esta identidad para obtener el secreto?

Realizar estas operaciones de seguridad (para la interacción entre aplicaciones) de manera confiable y repetible es un problema no trivial. Hay muchas razones por las que esto no es trivial: 

1. Las aplicações se pueden clonar y generar fácilmente (por ejemplo, microservicios). ¿Cómo asignar una identidad única a cada clon que pueda requerirse para fines forenses, de auditoría o de observabilidad? 
2. La identidad de la aplicação será diferente según el entorno en el que se ejecute. Por ejemplo, en desarrollo vs. producción, la aplicação es la misma, pero necesita una identidad diferente en cada entorno. 
3. ¿Cómo generar confianza en que la infraestructura en la que se genera la aplicação no robará la identidad, los secretos y las claves sin ser detectado? 
4. ¿Cómo proteger la bóveda central contra ataques y proteger todos los secretos y claves almacenados en esta bóveda?

Como resultado, proteger la infraestructura, las aplicações y los datos en un entorno dinámico es un problema muy desafiante. Si bien los proveedores de la nube han estado a la altura de este desafío y han proporcionado muchas herramientas para lidiar con estos problemas, integrarlos y mantenerlos no es fácil por las siguientes razones: 

• Complejidad : cada proveedor de nube requiere que el cliente configure y administre múltiples servicios. Por ejemplo, en AWS: servicio de metadatos, roles de IAM, cuenta de servicio, RBAC, KMS y administrador de secretos. Cada uno de estos servicios es muy diferente en cada proveedor de nube , tanto en su semántica, API y monitoreo. 
   
• Interoperabilidad : incluso cuando los servicios del proveedor de nube están configurados y operativos, ninguno de ellos permite la interoperabilidad. Por ejemplo, una máquina virtual que se ejecuta en GCP no puede acceder a un recurso en AWS porque un recurso de AWS no comprende la identidad asignada mediante la cuenta de servicio de GCP. 
   
• Entornos heterogéneos : si el entorno está distribuido en nubes públicas y privadas, o en múltiples nubes públicas, o, peor aún, en el borde, el desafío será cómo y dónde almacenar secretos como contraseñas, claves, etc., de forma centralizada o distribuida. 
   
• Específico del entorno : la solución para la rotación y/o revocación de credenciales es muy diferente en cada uno de los proveedores de nube, mientras que nada de esto existe para los clústeres de borde.

Si bien muchas empresas son un único proveedor de nube y puede ser suficiente para ellas invertir recursos en gestionar y mejorar las primitivas de seguridad de ese proveedor, operamos en un entorno heterogéneo (nube híbrida y borde) y tuvimos que crear una nueva solución para resolver estos problemas.

Solución para proteger una plataforma distribuida

Nuestro equipo tuvo la tarea de brindar seguridad a las aplicações, la infraestructura y los datos que puedan residir en una infraestructura distribuida como se muestra en la Figura 1.

Como resultado, nuestro equipo de plataforma decidió crear nuevos servicios de software que integraran los siguientes cuatro aspectos para brindar seguridad de la plataforma en el borde, cualquier nube y nuestros PoP de red: 

1. Gestión de identidad : describiremos cómo ofrecemos una identidad basada en PKI criptográficamente segura e infalsificable no solo a las aplicações, sino también a la infraestructura que se distribuye en un entorno heterogéneo (múltiples nubes, nuestros PoP globales y ubicaciones de borde geográficamente dispersas) y que opera como múltiples entornos (por ejemplo, máquina de desarrollador, prueba unitaria, producción, etc.) 
    
2. Autenticación y autorización : nuestra infraestructura está construida sobre microservicios que utilizan una identidad basada en PKI y autentican mutuamente todas las comunicaciones independientemente del protocolo de comunicación en uso. También separamos la autorización de la autenticación para que se pueda utilizar un motor de autorización común para una variedad de decisiones de autorización y se pueda unificar la estructura de políticas. 
    
3. Sistema de gestión de secretos : hay muchos tipos de secretos (como certificados TLS, contraseñas, tokens, etc.) que nuestro software necesita, así como las cargas de trabajo de los clientes. El método más simple podría haber sido adoptar una bóveda centralizada donde se almacenaran todos los secretos, pero este enfoque tenía la desventaja de que cualquier compromiso revelaría todos los secretos. Describiremos un enfoque diferente que implementamos para lograr un mayor nivel de seguridad renunciando a cierta simplicidad. 
    
4. Sistema de gestión de claves (KMS) : la seguridad de datos es fundamental para nuestro sistema distribuido y el equipo tuvo que ofrecer un KMS que funcione sin problemas entre los proveedores de la nube. El KMS debe administrar, versionar y rotar las claves que se utilizan para el cifrado simétrico de datos en reposo, HMAC de tokens CSRF y firmar binarios digitalmente. Analizaremos cómo proporcionamos capacidades tanto para operaciones sensibles a la seguridad utilizando este KMS como para operaciones sensibles a la latencia utilizando el sistema de gestión de secretos.

Identidad infalsificable para infraestructura y aplicaciones

La identidad es una cuestión fundamental ya que muchos desafíos de seguridad pueden abordarse más fácilmente una vez que se resuelve el problema de identidad. Sin embargo, para resolver el problema de la identidad, necesitamos definir qué queremos decir con ella y cómo emitirla de manera confiable. A los fanáticos de las criptomonedas les gusta darle su propio toque a todo, y la definición de identidad no es una excepción:

El conjunto único y completo de características infalsificables y criptográficamente verificables , certificadas criptográficamente a través de un protocolo no delegado y seguro por una autoridad confiable, que conforman lo que se conoce o se considera que es una persona o cosa.

En esencia, lo que se necesita es una identidad infalsificable y criptográficamente verificable, entregada de forma segura. Emitir dicha identidad es un desafío por dos razones: 1) arranque de la identidad y 2) raíz de confianza

Hay algunos enfoques que se discuten a menudo en relación con la identidad: SPIFFE y Hashicorp Vault. Queremos aclarar que SPIFFE es un esquema de nombres que podría usarse en nuestro sistema como un documento de identidad (certificado X.509); sin embargo, el formato no es adecuado para algunos atributos de identidad que contienen datos binarios. Si bien Vault se puede utilizar para emitir un documento de identidad, no resuelve los desafíos del bootstrapping de identidad y los problemas de raíz de confianza:

1. Arranque de la identidad : en la vida real, cuando una persona nace, su identidad se establece mediante el certificado de nacimiento. Esto lógicamente inicia la identidad de la persona y al usar este certificado la persona puede derivar/solicitar más certificados de identidad, como pasaporte, licencia de conducir, etc. De manera similar, en el mundo de la informática, cada lanzamiento de una aplicação (o un microservicio) necesita generar una identidad. El establecimiento de la identidad es uno de los primeros pasos que cualquier código en ejecución debe realizar para poder interactuar con otros servicios. Además, dado que el mismo código de aplicação puede ejecutarse varias veces y en diferentes entornos (computadora portátil del desarrollador, prueba unitaria o producción), también se requiere que cada uno de estos lanzamientos establezca una identidad de arranque independiente.
2. Raíz de confianza : si bien emitir una identidad de arranque puede parecer un proceso sencillo, el problema es quién puede proporcionar esta identidad. Por ejemplo, en el mundo real, la provisión de identidad comienza cuando el hospital afirma el hecho de que un niño nació en una fecha y hora determinadas de una persona en particular y se asume que el hospital está acuñando el registro de nacimiento con los controles adecuados y que no puede ser falsificado. Como resultado, el documento de registro de nacimiento puede utilizarse como fuente de verdad (o raíz de confianza). De manera similar, cuando una aplicação es lanzada por un código humano o automatizado, es necesario que exista una raíz de confianza que pueda afirmar de manera verificable la identidad de la aplicação que se lanzó. Esta afirmación puede luego utilizarse para generar un documento de identidad posterior para la aplicação.

Por ejemplo, cuando se lanza una máquina virtual en AWS, se le proporciona una identidad de arranque y el servicio de metadatos de AWS actúa como raíz de confianza. El documento de identidad (firmado por AWS con su propia clave criptográfica) se parece a esto:

Si bien instanceId puede indicar la identidad única de la instancia de aplicação que se lanzó, debe estar encadenado a algún nombre conocido (myserver.acmecorp.com) que otras aplicações usarán para comunicarse con esta instancia en particular. Como resultado, incluso este documento de identidad de arranque de AWS es insuficiente, pero se puede utilizar para emitir otra identidad que las aplicações puedan usar para comunicarse con otra aplicação.

Como se mencionó anteriormente, para nosotros era fundamental ofrecer una identidad que permita a las aplicações comunicarse y compartir información entre proveedores de nube y/o ubicaciones de borde (Figura 2). Esto significó que teníamos que construir un sistema tanto para el arranque de identidad como para la raíz de confianza que funcionara en todos estos entornos.

Dado que utilizamos Kubernetes para administrar y orquestar aplicações (tanto microservicios como máquinas virtuales), esto significó que el arranque de una identidad única para cada pod lanzado tuvo que estar vinculado al proceso de creación de pods de Kubernetes. La figura 3 muestra cómo nos conectamos al proceso de creación de pods utilizando el mecanismo de webhook de K8s. Este webhook, llamado Voucher, inyecta un sidecar de seguridad, llamado Wingman , en todos los Pods creados en el clúster y también proporciona la información firmada criptográficamente necesaria que puede usarse como raíz de confianza . Este webhook proporciona un token firmado de corta duración que Wingman utiliza para solicitar un certificado X.509 a la autoridad de identidad en el backend SaaS de Volterra.

La Autoridad de Identidad hace cumplir las reglas de acuñación de la identidad de manera tal de minimizar el “radio de explosión” en caso de que uno de los grupos K8 se vea comprometido. Muchas otras soluciones que dependen de una CA raíz común o de una federación de clústeres K8 no pueden limitar el radio de explosión, lo que fue un factor importante en nuestra decisión de diseño.

Para un Pod determinado en K8s, los atributos pueden cambiar después de la creación del Pod; por ejemplo, un Pod se puede adjuntar a un nuevo servicio después de su creación. Esto significaba que los certificados de identidad tenían que actualizarse con el nuevo servicio. Wingman vigila continuamente el Voucher que rastrea el servidor API de K8s para detectar cualquier actualización de este tipo.

Este mecanismo proporciona una identidad global única y universal a cada instancia de aplicação que se ejecuta en nuestra plataforma, independientemente de si se trata de nuestra propia carga de trabajo o de la carga de trabajo del cliente. Esta identidad única y sidecar (Wingman) se utilizan luego para proteger todas las comunicaciones, accesos y claves/secretos en un sistema distribuido.

Autenticación y autorización

Tener una identidad única por Pod es un gran comienzo ya que facilita la tarea de implementar la autenticación mutua entre los servicios que se comunican. Nuestra infraestructura subyacente se compone de muchos servicios diferentes que se ejecutan en diferentes protocolos como gRPC, REST, IPSec, BGP, etc. Desde el principio, el equipo se propuso como objetivo lograr autenticación mutua y seguridad de comunicación (canal cifrado) para todas las partes que se comunican, independientemente del protocolo. Esto también significaba que no podíamos vincular nuestra identidad a una solución (por ejemplo, Istio) que se limita a un conjunto particular de protocolos (por ejemplo, HTTP/TCP vs. Basado en IP).

Dado que nuestra plataforma también permite a los clientes ejecutar cargas de trabajo de su elección, esperamos que estas cargas de trabajo puedan ejecutar una variedad de protocolos y la plataforma no debería limitar su capacidad al proporcionar una identidad que esté limitada a un conjunto particular de protocolos. En cambio, la autenticación se desacopla de la identidad (a través de Wingman) y esto hace posible la conexión a varias tecnologías de malla de servicios. Nuestro sidecar/plano de datos de malla de servicio (cubierto en un blog anterior) utiliza esta identidad para brindar mTLS para las cargas de trabajo de los clientes.

Dado que muchos de nuestros propios servicios de infraestructura se escribieron utilizando Volterra Golang Service Framework (que se analizará en un blog futuro), decidimos desarrollar la lógica de consumo de identidad (de Wingman) directamente en el marco. Esto ha ayudado a nuestros desarrolladores a proteger sus comunicaciones de servicio a servicio de forma inmediata, sin depender del sidecar de malla de servicio para mTLS.

El siguiente paso lógico después de lograr un canal seguro autenticado mutuamente es la Autorización, un proceso para que el receptor de la solicitud (servidor) determine si permite o no la solicitud que proviene del llamador identificado (cliente). Las razones para no permitir la solicitud podrían ser muchas: limitaciones de cuota, permisos, etc. Dado que estos motivos y sus umbrales cambian dinámicamente, un conjunto de reglas codificadas (políticas) para la autorización no era viable para nuestra plataforma.

Decidimos utilizar el motor de Open Policy Agent como punto de partida y construimos un contenedor para la autorización dentro del sidecar de Wingman. Este código contenedor recupera dinámicamente las políticas relevantes y las mantiene activas para una evaluación rápida. De manera similar a la autenticación, disociar el motor de autorización de la identidad (y la autenticación) nos ha permitido aplicar políticas de autorización en múltiples etapas del procesamiento de solicitudes, incluso en lo profundo de la lógica empresarial y no inmediatamente después de la autenticación.

Dado que Wingman se inserta en todas las cargas de trabajo, incluidas las del cliente, nuestra plataforma proporciona un motor de autorización como función incorporada. Aunque Open Policy Agent (OPA) está construido sobre un lenguaje poderoso llamado Rego, queríamos ocultar su complejidad a nuestros desarrolladores y clientes. Todas las políticas de nuestra plataforma también se pueden definir utilizando una estructura de políticas mucho más fácil de entender e intuitiva que no requiere que los usuarios (DevOps) aprendan Rego y, por lo tanto, evitan errores. De manera similar a la configuración de autenticación, nuestro Golang Service Framework se conectó al motor de autorización de Wingman llamando automáticamente a Wingman para solicitar autorización y ocultando la complejidad de la autorización a los desarrolladores.

Al utilizar una identidad única (emitida mediante Wingman) para la autenticación y un motor de políticas programable (dentro de Wingman) para la autorización, podemos proteger la comunicación mediante mTLS y controlar cada acceso mediante una política sólida y programable.

Gestión de secretos sin una bóveda centralizada

Todos los días, los ingenieros cometen errores involuntarios al almacenar claves y contraseñas en su código y, de alguna manera, estos llegan al código público o a repositorios de artefactos. Gestionar secretos es difícil y, sin un conjunto de herramientas fácil de usar y un proceso bien definido, se espera que los desarrolladores sigan el camino más corto. Como resultado, desde el comienzo de la empresa, la misión de nuestro equipo de seguridad de plataforma (diferente de la seguridad de red y aplicaciones) fue garantizar que los desarrolladores no tengan que hacer preguntas como "¿Dónde guardo los secretos: el código fuente , los artefactos o...?".

Evaluamos dos enfoques comunes que estaban disponibles para la gestión de secretos cuando comenzamos a construir nuestra plataforma, y ambos tenían ciertas deficiencias: 

1. Secretos de Kubernetes : si bien usamos Kubernetes y viene con su solución de secretos, no es particularmente útil por varias razones: los secretos no están cifrados en reposo, las construcciones de políticas no son integrales y no resuelve escenarios de múltiples clústeres.
    
2. Bóveda centralizada (por ejemplo, Hashicorp o Cyberark Vault) : otro enfoque podría haber sido utilizar una bóveda donde los secretos se almacenan de forma central y se entregan a los solicitantes autorizados. Los secretos están protegidos por una única clave de cifrado que se utiliza para el almacenamiento cifrado de Vault. El problema con este enfoque, sin embargo, es que el sistema de gestión de secretos tiene acceso a secretos claros (incluso si están almacenados de forma cifrada) y cualquier compromiso del sistema podría revelar todos los secretos.

En nuestro caso, al ser un servicio SaaS, tuvimos que idear un método más sólido para proteger los secretos de nuestros clientes, ya que cualquier compromiso no debería revelar sus secretos.

Como resultado, decidimos implementar una nueva técnica que llamamos Volterra Blindfold (marca registrada), que funciona junto con nuestro sidecar de seguridad, Wingman, como se muestra en la Figura 4. Este enfoque permite al propietario del secreto bloquearlo (cifrarlo) de tal manera que nunca sea revelado en forma clara a ninguna parte no deseada (incluido el servidor de descifrado). El secreto ni siquiera se almacena en un servidor de descifrado central y este diseño, en algunos aspectos, simplifica drásticamente el diseño del servidor.

Proporcionamos a los usuarios una herramienta que se puede usar en un entorno completamente fuera de línea para cifrar el secreto (S) que luego se puede distribuir; por ejemplo, el secreto se puede almacenar con la carga de trabajo y cargar en el registro. Una vez logrado esto, es necesario realizar los siguientes pasos:

Esto garantiza que el plano de control centralizado nunca tenga acceso al secreto en claro (S) y también que el secreto solo esté disponible en la memoria de tiempo de ejecución del Pod mientras dure el acceso. Además, se puede aplicar la política de acceso para definir quién tiene acceso a un secreto. La política se puede definir en función de los atributos de identidad, como el nombre de la aplicação , la ubicación, el nivel de cumplimiento, etc. De esta manera se puede separar cualquier subconjunto complejo de cargas de trabajo y lograr un control de acceso preciso. La política está criptográficamente entretejida en el proceso de cifrado, cegamiento, descifrado y desenmascaramiento: es computacionalmente inviable frustrar la intención de la política.

Al utilizar nuestra exclusiva técnica Blindfold para bloquear cada secreto y Wingman para revelar cada secreto según una política y una identidad infalsificable, podemos superar los problemas con las soluciones existentes y brindar administración de secretos en un entorno distribuido sin preocuparnos nunca por comprometer la mina de oro central.

Gestión de claves para sistemas distribuidos

Aunque los secretos y la gestión de claves pueden parecer dos nombres diferentes para el mismo problema, existen diferencias sutiles (pero importantes en la práctica) entre ambos dependiendo de a quién le pregunte y de cómo se quieran implementar las soluciones.

Secreto se refiere a cualquier información que se supone que es secreta y no está disponible para partes no autorizadas. En cierto modo, las claves criptográficas son un caso específico de secretos. La gestión de claves, por otro lado, generalmente se refiere a un sistema que almacena de forma segura material de claves criptográficas confidenciales y controla el uso de dicho material. En algunos casos, el sistema de gestión de claves puede entregar bytes sin procesar de la clave a partes autorizadas y, por lo tanto, puede confundirse con un sistema de gestión de secretos. Sin embargo, en la mayoría de los casos, el sistema de gestión de claves no entrega bytes sin procesar del material de la clave y, en su lugar, realiza operaciones para solicitantes autorizados y envía únicamente el resultado de la operación. Muchos sistemas de administración de claves también están respaldados por almacenamiento de hardware (por ejemplo, HSM) para el material de la clave, de modo que la clave nunca queda expuesta de forma clara al software.

En entornos distribuidos, incluso para un único proveedor de nube, el problema de gestionar, sincronizar y rotar claves criptográficas es muy desafiante y las soluciones actuales son propensas a errores, ineficientes e incluso inseguras. Por ejemplo, si uno usa 3 regiones de AWS hoy y quiere usar la misma clave criptográfica en las 3 regiones, tendrá que sincronizar y rotar las claves manualmente. El problema se vuelve aún peor cuando el entorno se extiende por múltiples proveedores de nube (públicos y/o privados). Incluso después de todo esto dicho y hecho, los propietarios de las aplicação todavía tienen que escribir código complejo para utilizar estas capacidades de KMS.

Nuestra plataforma oculta todas las complejidades de la administración de claves de la aplicação al hacer que Wingman sidecar haga todo el trabajo pesado y proporcione interfaces simples a la aplicação para realizar las solicitudes de administración de claves, incluido el cifrado, descifrado, HMAC, verificación de HMAC, firma digital, verificación de firma, obtención de clave (cuando esté permitido), etc. Esto hace que la gestión de claves no sea en absoluto una tarea desalentadora para nuestros propios servicios de infraestructura, así como para las cargas de trabajo de los clientes.

El siguiente diagrama (Figura 5) muestra cómo funciona el KMS de Volterra en distintos entornos y ayuda a las cargas de trabajo a descargar sus operaciones de gestión de claves y cifrado al sidecar Wingman. Dependiendo de la configuración, Wingman puede almacenar en caché claves y actualizar el caché sin que la aplicação lo sepa. El factor que lo permite es la identidad universal e infalsificable que presentamos anteriormente. Dado que cada Pod, independientemente de su ubicación, obtiene una identidad única global, es fácil para el sistema Volterra KMS aplicar políticas de acceso a claves criptográficas y operaciones específicas como cifrado, descifrado, HMAC, verificación de HMAC, firma digital y verificación de firma de una manera muy precisa.

Dado que todas las claves se administran a través del backend SaaS de Volterra, las cargas de trabajo que se ejecutan en entornos heterogéneos no tienen que lidiar con la sincronización, rotación y revocación de claves, etc.; solo tienen que conocer las API simples de Wingman para todas sus necesidades de seguridad de datos en reposo.

Beneficios que ofrece nuestra solución de seguridad de plataforma

¡Usando una plataforma de seguridad de múltiples capas, hemos podido ofrecer una solución integral a tres problemas críticos de una manera completamente nueva! Nuestro sistema es capaz de crear de forma segura una identidad universal que no sufre el problema de las “ tortugas hasta el final ”, administrar secretos que pueden almacenarse y distribuirse sin preocuparse nunca por el problema de la mina de oro y brindar administración de claves para facilitar la seguridad de los datos en reposo en un entorno distribuido. Esto ha supuesto los siguientes beneficios para nuestros equipos internos y nuestros clientes: 

1. Seguridad y cumplimiento : identidad universal e infalsificable, Blindfold y sidecar de seguridad (Wingman) totalmente integrado y administrado automáticamente por la plataforma para proteger todas las comunicaciones, autorizar cada acceso y administrar claves/secretos en un sistema distribuido. Gracias a estos avances, podemos ofrecer una solución de seguridad más sólida que ha facilitado nuestra capacidad y la de nuestros clientes de cumplir con las normas. 
    
2. Mejoras de productividad : al utilizar una solución de seguridad integrada en nuestro proceso y marco de servicio DevOps, es fácil para los desarrolladores y equipos de DevOps concentrarse en sus resultados sin preocuparse por aspectos clave de la seguridad de datos de las aplicação y los datos. 
    
3. Evolución continua : el panorama de seguridad en constante evolución y las nuevas tecnologías conducen a una evolución continua de Blindfold, Wingman y nuestro marco de servicio Golang. Como resultado, la plataforma implementa automáticamente nuevas capacidades sin ningún cambio en la lógica de la aplicação .

Continuará…

Esta serie de blogs cubrirá diversos aspectos de lo que nos llevó construir y operar nuestro servicio SaaS distribuido globalmente con muchos clústeres de aplicação en la nube pública, nuestros PoP de red privada y sitios de borde. El siguiente tema será Seguridad de aplicação y redes …

Estamos buscando algunos desarrolladores y arquitectos de soluciones voluntarios que nos ayuden a llevar esta capacidad a una comunidad más amplia como un proyecto de código abierto. Comuníquese directamente con asingla@volterra.io si está interesado en ser parte de algo divertido.