Cómo Cisco convirtió la Spark Cloud en Fort Knox

Publicado: 2016-07-18

Está bastante claro a partir de las discusiones en torno a la plataforma Spark de Cisco en Cisco Live que el gigante de las comunicaciones unificadas está poniendo gran parte de su peso detrás de la mensajería empresarial y la colaboración en equipo. Durante mi tiempo en la conferencia en Las Vegas, tuve la oportunidad no solo de hablar con Jonathan Rosenberg y Jens Megger, sino también de participar en sus discusiones sobre Spark y hacia dónde irá la plataforma a continuación. Es seguro decir que Cisco está buscando aprovechar su base de usuarios masiva de 215 millones de clientes para aprovechar al máximo Spark y realmente impulsarlo a la corriente principal.

Rosenberg dijo durante su discurso de apertura de Enterprise Messaging que Business Messaging será el próximo gran cambio en las tecnologías de comunicación para equipos grandes y pequeños. Anteriormente era llamar, cada oficina necesitaba un sistema telefónico para mantenerse en contacto (y, finalmente, las videollamadas se pueden incluir aquí), y luego, cuando apareció el correo electrónico, todos tuvieron que adoptar el buzón electrónico instantáneo. Ahora, dijo Rosenberg, Business Messaging está ascendiendo para tomar el lugar del correo electrónico. No es que el correo electrónico desaparezca, al igual que nuestro correo postal estándar aún no se ha disuelto, pero las plataformas de colaboración en equipo permitirán a los equipos lograr más, más rápido.

La seguridad es clave

Pero cuando espera que los grandes jugadores empresariales adopten su plataforma, debe tener en cuenta al menos un aspecto importante: la seguridad. Ninguna empresa quiere que un tercero husmee en sus comunicaciones internas, incluso si eso significa el propio proveedor del servicio. Para garantizar que todos adopten su plataforma, debe asegurarse de que todos se sientan seguros al utilizarla. Cisco hizo todo lo posible para marcar todas las casillas cuando estaban construyendo Spark desde cero; incluso hicieron un esfuerzo adicional para establecer el cifrado de extremo a extremo en la estructura a nivel del suelo de Spark. Todo el sistema se ha desarrollado teniendo en cuenta la seguridad y el cifrado.

Un beneficio clave de los servicios en la nube es el hecho de que las actualizaciones de la plataforma pueden ocurrir tan rápido como el proveedor de servicios en la nube puede implementarlas. Una nueva función puede implementarse en el momento en que está lista para funcionar, y rápidamente se puede enviar a la base de usuarios existente, esto podría llamarse "valor agregado".

La respuesta de Cisco

Sin embargo, para la mayoría de los productos de consumo, la adición de valor se realiza a expensas de los usuarios. Por lo general, al requerir acceso completo a los datos y el contenido del usuario, el servicio puede sentirse vulnerable. O, por otro lado, los servicios bloqueados que garantizan la seguridad sacrificarán estas características de valor agregado para mantener todo agradable y seguro. En comparación con otras soluciones como Slack, Spark gana algunos puntos extra cuando se trata de su alto nivel de seguridad.

Cisco Spark frente a Slack

Lo que Cisco hizo con Spark fue lograr un buen equilibrio en el medio. Cifrado de extremo a extremo que ofrece a las empresas la capacidad de elegir específicamente qué integraciones de valor agregado les gustaría incluir. Yendo un paso más allá, mientras que Cisco se bloquea a sí mismo de sus datos, la empresa puede tener acceso completo como lo desee.

Cisco dijo que el sistema se basa en una "arquitectura abierta para la distribución segura de claves de cifrado y la confidencialidad de los datos". Básicamente, esto significa que el contenido se cifra en el cliente de cada usuario y permanece así hasta que llega al destinatario. Nada entre cada cliente tiene acceso a las claves de descifrado, a menos que la Empresa decida proporcionar dicho acceso a los usuarios.

Entonces, cómo funciona todo

Para permitir el acceso al descifrado, Cisco introdujo un sistema clave para brindar acceso completo a los datos si es necesario y si se otorga a los usuarios. Este sistema, el servidor de administración de claves (KMS), es la base del cifrado de extremo a extremo en Spark. Este servidor creará, almacenará, autorizará y proporcionará acceso a las claves de cifrado. Esencialmente, el KMS es el guardián de todos sus datos y archivos. Según los permisos establecidos por la empresa, solo ciertos usuarios pueden tener acceso (individuos de TI), mientras que los propios Cisco no pueden ver su contenido. Cada empresa tiene su propio KMS exclusivo.

KMS = Servidor de administración de claves, su Cisco Spark Gatekeeper

El KMS en sí está separado de la unidad central de Spark, son sus propios "reinos" que funcionan en conjunto. Si bien el KMS se encuentra en el Reino de seguridad, todo lo demás se puede etiquetar como la unidad central de Spark. Mantener los reinos separados es lo que garantiza el cifrado de extremo a extremo. Los elementos centrales de la plataforma no tienen acceso a las claves de cifrado y el sistema se basa en el KMS para autenticar los tokens de acceso que no se utilizan en ningún otro lugar de la nube.

Como dice Cisco, esto "garantiza el acceso apropiado a las claves de cifrado, al mismo tiempo que garantiza que ningún componente central del servicio pueda acceder a esas comunicaciones o claves que almacena el KMS".

En solo otro paso para brindar un control total al usuario final, Cisco incluso permite la opción del ámbito de la seguridad como una solución alojada, de esa manera Cisco hace todo el trabajo pesado, o una solución en las instalaciones para la empresa más cautelosa que realmente quiere bloquear todo. Con una solución hospedada, todos los servicios en el Reino de seguridad se ubican y operan en un arrendatario separado en una infraestructura separada. En las instalaciones, bueno, eso lo decide el negocio.

El proceso en acción

chispa-kms-modelo

Para resumir, cuando un usuario quiere enviar un mensaje a Spark Room, el primer paso del cliente de ese usuario es establecer un canal seguro entre el cliente y el KMS. Este paso requiere un proceso de autenticación entre el cliente y el KMS, lo que hace imposible que Cisco o terceros vean o incluso modifiquen la información en tránsito. Tras el proceso de autenticación, el cliente utilizará el canal establecido para solicitar una nueva clave de cifrado necesaria para cifrar el contenido que se enviará a otro cliente.

Una vez que se escribe el mensaje, el cliente cifra el mensaje con una clave de conversación y lo etiqueta con el ID de sala de la sala Spark de destino y lo envía al núcleo. Luego, el núcleo recibe un mensaje cifrado y, dado que se mantiene separado del Reino de seguridad, no tiene acceso a las claves de conversación necesarias para descifrar dicho mensaje. El núcleo busca al destinatario y envía el mensaje cifrado de camino a la sala de recepción, pero también almacena el mensaje en una base de datos asociada con la sala de recepción.

Ahora el proceso ocurre a la inversa, el cliente receptor recibe un mensaje cifrado y se comunica con el KMS para obtener la clave necesaria para descifrar el mensaje. El KMS autentica a ambos usuarios para verificar los permisos necesarios para abrir el mensaje y distribuye la clave de conversación al destinatario para que su cliente pueda descomprimir y leer el mensaje.

Si todo está encriptado, ¿cómo funciona la búsqueda?

Dado que el Core en sí mismo nunca ve el contenido que está transmitiendo, no puede permitir la búsqueda simple de mensajes a través del servicio en la nube. Para contrarrestar esto, Cisco ideó algo bastante único: incorporaron un componente Indexer directamente en el Reino de seguridad. Al igual que el KMS, el Indexer está completamente separado del Core, pero está muy cerca del KMS. Esencialmente, Indexer construye y consulta el índice de búsqueda dentro del KMS. De esta manera, todo permanece encriptado, pero se puede buscar.

Resulta que el Indexer es en realidad un Spark Bot al que se invita a todas las salas, según la política de la empresa. Cada vez que un usuario envía un mensaje, el Indexador recibe una copia del contenido encriptado, chatbot y al igual que el cliente, habla con el KMS para acceder a la clave de conversación necesaria para abrir el mensaje. El indexador aplica un hash, una forma de autenticación, a cada palabra dentro del mensaje enviado y completa una lista de todas las palabras hash que pertenecen a la sala específica donde se recibió el mensaje.

El indexador es incluso lo suficientemente inteligente como para agregar palabras aleatorias para garantizar completamente que los mensajes no puedan tener su cifrado invertido. Luego, la lista de hashes se envía a Spark Cloud y se almacena en el índice de búsqueda mientras se encuentra en su estado cifrado. Ahora tiene un índice de búsqueda totalmente encriptado.

Lo mejor de ambos mundos

Cisco realmente quería brindar la tranquilidad de que incluso la empresa más paranoica podría sentirse segura al enviar sus datos y archivos a través de la plataforma Spark Cloud. Otras aplicaciones de consumo permiten, o incluso pueden depender, del acceso a los datos por parte del propio servicio. Con el cifrado de extremo a extremo tan arraigado en el desarrollo de Spark, e incluso la capacidad de alojar su propio ámbito de seguridad, establecer sus propios parámetros y disposiciones, tiene el Fort Knox de Business Messaging y Team Collaboration.