Comment Cisco a transformé le Spark Cloud en Fort Knox

Il ressort assez clairement des discussions entourant la plate-forme Spark de Cisco à Cisco Live que le géant des communications unifiées accorde une grande importance à la messagerie d'entreprise et à la collaboration d'équipe. Pendant mon séjour à la conférence à Vegas, j'ai eu la chance non seulement de parler avec Jonathan Rosenberg et Jens Megger, mais aussi de participer à leurs discussions sur Spark et sur la prochaine étape de la plate-forme. On peut dire sans risque de se tromper que Cisco cherche à tirer parti de sa base d'utilisateurs massive de 215 millions de clients pour tirer pleinement parti de Spark et le pousser vraiment dans le courant dominant.

Rosenberg a déclaré lors de son discours d'ouverture sur la messagerie d'entreprise que la messagerie d'entreprise sera le prochain grand changement dans les technologies de communication pour les équipes, grandes et petites. Auparavant, il appelait, chaque bureau avait besoin d'un système téléphonique pour rester en contact (et éventuellement les appels vidéo peuvent être inclus ici), puis lorsque le courrier électronique est arrivé, tout le monde a dû adopter la boîte aux lettres électronique instantanée. Maintenant, a déclaré Rosenberg, la messagerie d'entreprise est en train de remplacer le courrier électronique. Non pas que les e-mails disparaissent, tout comme notre courrier postal standard n'a pas encore disparu, mais les plateformes de collaboration d'équipe permettront aux équipes d'accomplir plus, plus rapidement.

La sécurité est la clé

Mais lorsque vous vous attendez à ce que les grands acteurs de l'entreprise adoptent votre plate-forme, vous devez prendre en compte au moins un aspect majeur - et c'est la sécurité. Aucune entreprise ne veut qu'un tiers fouine ses communications internes, même si cela signifie le fournisseur du service lui-même. Pour vous assurer que tout le monde adoptera votre plateforme, vous devez vous assurer que tout le monde se sentira en sécurité en l'utilisant. Cisco a fait tout son possible pour cocher toutes les cases lors de la construction de Spark à partir de zéro - ils ont même fait un effort supplémentaire pour établir un chiffrement de bout en bout dans la structure de base de Spark. L'ensemble du système a été développé dans un souci de sécurité et de cryptage.

L'un des principaux avantages des services cloud est le fait que les mises à jour de la plate-forme peuvent être effectuées aussi rapidement que le fournisseur de services cloud peut les déployer. Une nouvelle fonctionnalité peut être déployée à la seconde où elle est prête à l'emploi et être rapidement transmise à la base d'utilisateurs existante, cela pourrait être appelé "ajouter de la valeur".

La réponse de Cisco

Cependant, pour la plupart des produits de consommation, la valeur ajoutée se fait aux dépens des utilisateurs. Nécessitant généralement un accès complet aux données et au contenu des utilisateurs, le service peut se sentir vulnérable. Ou, d'un autre côté, les services verrouillés qui garantissent la sécurité sacrifieront ces fonctionnalités à valeur ajoutée afin de garder tout agréable et sécurisé. Par rapport à d'autres solutions comme Slack, Spark gagne quelques points supplémentaires en ce qui concerne son haut niveau de sécurité.

Ce que Cisco a fait avec Spark, c'est trouver un bel équilibre au milieu. Chiffrement de bout en bout qui offre aux entreprises la possibilité de choisir spécifiquement les intégrations à valeur ajoutée qu'elles souhaitent inclure. Pour aller plus loin, tandis que Cisco se verrouille sur vos données, l'entreprise peut avoir un accès complet à sa guise.

Cisco a déclaré que le système repose sur une "architecture ouverte pour la distribution sécurisée des clés de chiffrement et la confidentialité des données". Cela signifie essentiellement que le contenu est crypté sur le client de chaque utilisateur et le reste jusqu'à ce qu'il atteigne le destinataire. Rien entre chaque client n'a accès aux clés de déchiffrement, à moins que l'entreprise ne décide de fournir un tel accès aux utilisateurs.

Alors, comment ça marche

Afin de permettre l'accès au décryptage, Cisco a introduit un système de clé pour fournir un accès complet aux données si nécessaire, et si elles sont accordées aux utilisateurs. Ce système, le Key Management Server (KMS) est la base du chiffrement de bout en bout dans Spark. Ce serveur créera, stockera, autorisera et fournira l'accès aux clés de chiffrement. Essentiellement, le KMS est le gardien de toutes vos données et fichiers. Sur la base des autorisations définies par l'entreprise, seuls certains utilisateurs peuvent avoir accès (les informaticiens), tandis que Cisco lui-même ne peut pas voir votre contenu. Chaque entreprise a son propre KMS unique.

KMS = Key Management Server, votre Cisco Spark Gatekeeper

Le KMS lui-même est séparé de l'unité centrale de Spark, ce sont leurs propres "royaumes" travaillant en conjonction. Alors que le KMS est situé dans le domaine de sécurité, tout le reste peut être étiqueté comme l'unité centrale de Spark. Garder les domaines séparés est ce qui garantit le chiffrement de bout en bout. Les éléments centraux de la plate-forme n'ont pas accès aux clés de chiffrement et le système s'appuie sur le KMS pour authentifier les jetons d'accès qui ne sont utilisés nulle part ailleurs dans le cloud.

Comme le dit Cisco, cela "garantit un accès approprié aux clés de chiffrement, tout en garantissant qu'aucun composant de service principal ne peut accéder aux communications ou aux clés stockées par le KMS".

Dans une autre étape pour fournir un contrôle total à l'utilisateur final, Cisco permet même l'option du domaine de la sécurité en tant que solution hébergée - de cette façon, Cisco fait tout le gros du travail - ou une solution sur site pour l'entreprise très prudente qui veut vraiment tout verrouiller. Avec une solution hébergée, tous les services du domaine de la sécurité sont situés et exploités dans un locataire distinct sur une infrastructure distincte. Avec sur place, c'est à l'entreprise de décider.

Le processus en action

Pour faire court, lorsqu'un utilisateur souhaite envoyer un message à la salle Spark, la première étape du client de cet utilisateur consiste à établir un canal sécurisé entre le client et le KMS. Cette étape nécessite un processus d'authentification entre le client et le KMS, ce qui empêche Cisco ou tout tiers de visualiser ou même de modifier les informations en transit. Après le processus d'authentification, le client utilisera le canal établi pour demander une nouvelle clé de cryptage nécessaire pour crypter le contenu qui sera envoyé à un autre client.

Une fois le message écrit, le client chiffre le message avec une clé de conversation et l'étiquette avec l'ID de la salle Spark de destination, puis l'envoie au noyau. Le noyau reçoit alors un message crypté et, comme il est séparé du domaine de sécurité, n'a aucun accès aux clés de conversation nécessaires pour décrypter ledit message. Le noyau recherche le destinataire et envoie le message crypté sur son chemin vers la salle de réception, mais stocke également le message dans une base de données associée à la salle de réception.

Maintenant, le processus se déroule en sens inverse, le client destinataire reçoit un message chiffré et contacte le KMS pour obtenir la clé nécessaire pour déchiffrer le message. Le KMS authentifie les deux utilisateurs pour vérifier les autorisations nécessaires pour ouvrir le message et distribue la clé de conversation au destinataire afin que son client puisse décompresser et lire le message.

Si tout est crypté, comment fonctionne la recherche ?

Étant donné que le Core lui-même ne voit jamais le contenu que vous transmettez, vous ne pouvez pas autoriser une simple recherche de messages via le service cloud lui-même. Pour contrer cela, Cisco a proposé quelque chose d'assez unique : ils ont intégré un composant Indexeur directement dans le domaine de sécurité. Tout comme le KMS, l'indexeur est complètement séparé du noyau, mais il est très proche du KMS. Essentiellement, l'indexeur construit et interroge l'index de recherche dans le KMS. De cette façon, tout reste crypté, mais consultable.

Il s'avère que l'indexeur est en fait un Spark Bot qui est invité dans chaque salle, en fonction de la politique de l'entreprise. Chaque fois qu'un utilisateur envoie un message, l'indexeur reçoit une copie du contenu crypté, et comme le client, parle avec le KMS pour accéder à la clé de conversation nécessaire pour ouvrir le message. L'indexeur applique un hachage, une authentification de manière un, à chaque mot dans le message envoyé et établit une liste de tous les mots hachés qui appartiennent à la salle spécifique où le message a été reçu.

L'indexeur est même assez intelligent pour ajouter des mots aléatoires afin de s'assurer que le cryptage des messages ne peut pas être inversé. La liste des hachages est ensuite envoyée au Spark Cloud et stockée dans l'index de recherche dans son état chiffré. Vous avez maintenant un index consultable et entièrement crypté.

Le meilleur des deux mondes

Cisco voulait vraiment offrir la tranquillité d'esprit que même l'entreprise la plus paranoïaque pouvait se sentir en sécurité en envoyant ses données et ses fichiers via la plate-forme Spark Cloud. D'autres applications grand public permettent, ou peuvent même compter sur, l'accès aux données par le service lui-même. Avec un chiffrement de bout en bout si profondément enraciné dans le développement de Spark, et même la possibilité d'héberger votre propre domaine de sécurité, de définir vos propres paramètres et dispositions, vous disposez du Fort Knox de la messagerie d'entreprise et de la collaboration d'équipe.