思科如何將 Spark 雲變成諾克斯堡
已發表: 2016-07-18從 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。