思科如何将 Spark 云变成诺克斯堡

从 Cisco Live 上围绕 Cisco Spark 平台的讨论中可以清楚地看出，这家 UC 巨头正在大力支持业务消息传递和团队协作。 在拉斯维加斯的会议期间，我不仅有机会与 Jonathan Rosenberg 和 Jens Megger 交谈，还参与了他们对 Spark 以及平台下一步发展方向的讨论。 可以肯定地说，思科希望利用其 2.15 亿客户的庞大用户群来充分利用 Spark，并真正将其推向主流。

Rosenberg 在他的 Enterprise Messaging 主题演讲中表示，Business Messaging 将成为大大小小的团队通信技术的下一个重大转变。 以前是打电话，每个办公室都需要一个电话系统来保持联系（最终视频通话可以包括在里面），然后当电子邮件出现时，每个人都必须采用即时电子邮箱。 现在，Rosenberg 说，商务信息正在逐渐取代电子邮件。 并不是说电子邮件会消失，就像我们的标准蜗牛邮件尚未解散一样，但它的团队协作平台将使团队能够更快地完成更多工作。

安全是关键

但是，当您希望大型企业参与者采用您的平台时，您至少要考虑一个主要方面——那就是安全性。 没有企业希望第三方窥探他们的内部通信，即使这意味着服务提供商自己。 为确保每个人都会采用您的平台，您必须确保每个人都能安全地使用它。 思科在从头开始构建 Spark 时，不遗余力地勾选了所有选项——他们甚至加倍努力在 Spark 的底层结构中建立端到端加密。 整个系统的开发考虑了安全性和加密。

云服务的一个关键优势在于，平台的更新可以在云服务提供商部署它们时尽快进行。 一个新功能可以在准备就绪的第二秒推出，并迅速推送到现有用户群，这可以称为“增值”。

思科的回答

然而，对于大多数消费品而言，增值是以牺牲用户为代价的。 通常需要完全访问用户数据和内容，该服务可能会感到脆弱。 或者，另一方面，确保安全的锁定服务将牺牲这些增值功能，以保持一切美好和安全。 与 Slack 等其他解决方案相比，Spark 在高安全性方面获得了一些额外的分数。

思科对 Spark 所做的就是在中间取得很好的平衡。 端到端加密使企业能够具体选择他们想要包含的增值集成。 更进一步，虽然思科将自己锁定在您的数据之外，但企业可以选择拥有完全访问权限。

思科表示，该系统依赖于“用于加密密钥安全分发和数据机密性的开放式架构”。 这实质上意味着内容在每个用户的客户端上都经过加密，并且在到达收件人之前一直如此。 除非企业决定向用户提供此类访问权限，否则每个客户端之间的任何内容都无法访问解密密钥。

那么它是如何工作的

为了允许访问解密，思科引入了一个密钥系统，以便在必要时提供对数据的完全访问权限，并且如果授予用户权限。 这个系统，即密钥管理服务器 (KMS) 是 Spark 中端到端加密的基础。 该服务器将创建、存储授权并提供对加密密钥的访问。 从本质上讲，KMS 是您所有数据和文件的看门人。 根据企业设置的权限，只有特定用户（IT 个人）可以访问，而思科自己无法看到您的内容。 每个企业都有自己独特的 KMS。

KMS = 密钥管理服务器，您的 Cisco Spark 网守

KMS 本身与 Spark 的核心单元是分开的，它们是它们自己的“领域”协同工作。 虽然 KMS 位于安全领域，但其他一切都可以标记为 Spark 的核心单元。 保持领域分离是确保端到端加密的原因。 该平台的核心元素无法访问加密密钥，并且系统依靠 KMS 来验证在云中其他任何地方都没有使用的访问令牌。

正如思科所说，这“确保了对加密密钥的适当访问，同时还保证没有核心服务组件可以访问 KMS 存储的那些通信或密钥。”

在为最终用户提供完全控制的另一个步骤中，思科甚至允许选择安全领域作为托管解决方案 - 这样思科可以完成所有繁重的工作 - 或者为真正想要的格外谨慎的企业提供本地解决方案锁定一切。 使用托管解决方案，安全领域中的所有服务都位于单独基础架构上的单独租户中并在其中运行。 在前提下，这取决于企业来决定。

行动过程

长话短说，当用户想要向 Spark Room 发送消息时，该用户的客户端的第一步是在客户端和 KMS 之间建立安全通道。 此步骤需要客户端和 KMS 之间的身份验证过程，使思科或任何第三方无法查看甚至修改传输中的任何信息。 在身份验证过程之后，客户端将使用已建立的通道请求新的加密密钥，以加密将发送给另一个客户端的内容。

消息写入后，客户端使用会话密钥对消息进行加密，并将其标记为目标 Spark 房间的房间 ID，然后将其发送到核心。 然后核心接收加密消息，并且由于它与安全领域分开，因此无法访问解密所述消息所需的对话密钥。 核心查找收件人，并将加密消息发送到接收室，但还将消息存储在与接收室关联的数据库中。

现在该过程反向进行，接收客户端收到一条加密消息，并联系 KMS 以获取解密消息所需的密钥。 KMS 对两个用户进行身份验证以验证打开消息所需的权限，并将对话密钥分发给收件人，以便其客户端可以解包并阅读消息。

如果一切都加密，搜索如何工作？

由于核心本身永远不会看到您正在传输的任何内容，因此您不能允许通过云服务本身进行简单的消息搜索。 为了解决这个问题，思科想出了一些非常独特的东西——他们将索引器组件直接内置到安全领域中。 与 KMS 一样，Indexer 与 Core 完全分离，但它与 KMS 非常接近。 本质上，索引器在 KMS 中构建和查询搜索索引。 这样，一切都保持加密，但可搜索。

事实证明，Indexer 实际上是一个 Spark Bot，它被邀请到每个房间，具体取决于企业策略。 每次用户发送消息时，Indexer 都会收到一份加密内容的副本， 和客户端一样，与 KMS 对话以访问必要的对话密钥以打开消息。 索引器对发送的消息中的每个单词应用哈希（一种身份验证方式），并编制属于接收消息的特定房间的所有哈希单词的列表。

索引器甚至足够聪明，可以添加随机单词，以完全确保消息的加密不会被逆转。 然后将哈希列表发送到 Spark Cloud，并在处于加密状态时存储在搜索索引中。 现在您有了一个可搜索的、完全加密的索引。

两全其美的

思科希望真正让您高枕无忧，即使是最偏执的企业也可以通过 Spark Cloud 平台安全地发送其数据和文件。 其他消费者应用程序允许，甚至可能依赖于服务本身对数据的访问。 端到端加密深深植根于 Spark 的开发中，甚至能够托管您自己的安全领域、设置您自己的参数和规定，您就拥有了商业消息传递和团队协作的 Fort Knox。