Как Cisco превратила облако Spark в Форт-Нокс

Из обсуждений платформы Cisco Spark на Cisco Live становится ясно, что гигант объединенных коммуникаций уделяет большое внимание обмену бизнес-сообщениями и совместной работе в команде. Во время моего пребывания на конференции в Вегасе у меня была возможность не только поговорить с Джонатаном Розенбергом и Йенсом Меггером, но и поучаствовать в их обсуждениях Spark и дальнейшего развития платформы. Можно с уверенностью сказать, что Cisco стремится использовать свою огромную пользовательскую базу из 215 миллионов клиентов, чтобы в полной мере воспользоваться преимуществами Spark и действительно сделать его массовым.

Розенберг сказал во время своего основного доклада по корпоративным сообщениям, что бизнес-сообщения станут следующим большим сдвигом в коммуникационных технологиях для больших и малых команд. Раньше это был звонок, каждому офису нужна была телефонная система, чтобы поддерживать связь (и, в конечном итоге, сюда можно включить видеосвязь), а затем, когда появилась электронная почта, всем пришлось использовать мгновенный электронный почтовый ящик. Теперь, по словам Розенберга, бизнес-сообщения постепенно заменяют электронную почту. Не то чтобы электронная почта исчезла, как наша стандартная обычная почта еще не распалась, но платформы для совместной работы позволят командам достигать большего и быстрее.

Безопасность — это ключ

Но когда вы ожидаете, что крупные корпоративные игроки примут вашу платформу, вы должны принять во внимание как минимум один важный аспект — безопасность. Ни один бизнес не хочет, чтобы третья сторона шпионила за их внутренними коммуникациями, даже если это означает самого поставщика услуг. Чтобы все приняли вашу платформу, вы должны убедиться, что все будут чувствовать себя в безопасности, используя ее. Cisco приложила все усилия, чтобы поставить все галочки, когда они создавали Spark с нуля — они даже приложили дополнительные усилия, чтобы внедрить сквозное шифрование в структуру Spark на уровне земли. Вся система была разработана с учетом безопасности и шифрования.

Ключевым преимуществом облачных служб является тот факт, что обновления платформы могут происходить так же быстро, как поставщик облачных услуг может их развернуть. Новая функция может быть развернута, как только она будет готова к работе, и быстро доведена до существующей пользовательской базы, это можно назвать «добавлением ценности».

Ответ Циско

Однако для большинства потребительских товаров добавленная стоимость создается за счет пользователей. Обычно требуя полного доступа к пользовательским данным и контенту, служба может чувствовать себя уязвимой. Или, с другой стороны, заблокированные службы, обеспечивающие безопасность, пожертвуют этими дополнительными функциями, чтобы все было красиво и безопасно. По сравнению с другими решениями, такими как Slack, Spark получает дополнительные баллы за высокий уровень безопасности.

Что Cisco сделала со Spark, так это добилась хорошего баланса посередине. Сквозное шифрование, которое предлагает предприятиям возможность выбирать, какие дополнительные интеграции они хотели бы включить. Делая еще один шаг вперед, пока Cisco блокирует ваши данные, предприятие может иметь полный доступ по своему усмотрению.

Cisco заявила, что система опирается на «открытую архитектуру для безопасного распределения ключей шифрования и конфиденциальности данных». По сути, это означает, что содержимое шифруется на клиенте каждого пользователя и остается таковым до тех пор, пока не достигнет получателя. Ничто между каждым клиентом не имеет доступа к ключам дешифрования, если Предприятие не решит предоставить такой доступ пользователям.

Итак, как это все работает

Чтобы разрешить доступ к расшифровке, Cisco ввела систему ключей для предоставления полного доступа к данным, если это необходимо, и если они предоставлены пользователям. Эта система, сервер управления ключами (KMS), является основой сквозного шифрования в Spark. Этот сервер будет создавать, хранить авторизацию и предоставлять доступ к ключам шифрования. По сути, KMS является привратником всех ваших данных и файлов. На основе разрешений, установленных Предприятием, только определенные пользователи могут иметь доступ (ИТ-специалисты), в то время как сами Cisco не могут видеть ваш контент. Каждое предприятие имеет свой уникальный KMS.

KMS = сервер управления ключами, ваш Cisco Spark Gatekeeper

Сама KMS отделена от основной единицы Spark, они являются их собственными «областями», работающими совместно. Хотя KMS находится в области безопасности, все остальное можно обозначить как основное устройство Spark. Разделение областей — это то, что обеспечивает сквозное шифрование. Основные элементы платформы не имеют доступа к ключам шифрования, и система полагается на KMS для аутентификации токенов доступа, которые больше нигде в облаке не используются.

По словам Cisco, это «обеспечивает надлежащий доступ к ключам шифрования, а также гарантирует, что ни один из основных сервисных компонентов не сможет получить доступ к тем сообщениям или ключам, которые хранятся в KMS».

В качестве еще одного шага к обеспечению полного контроля для конечного пользователя Cisco даже позволяет выбрать область безопасности в качестве решения на хостинге — таким образом, Cisco берет на себя всю тяжелую работу — или локальное решение для особо осторожного предприятия, которое действительно хочет заблокировать все. В размещенном решении все службы в области безопасности размещаются и работают в отдельном арендаторе в отдельной инфраструктуре. Что касается предпосылок, то это решать бизнесу.

Процесс в действии

Короче говоря, когда пользователь хочет отправить сообщение в комнату Spark, первым шагом клиента этого пользователя является установление безопасного канала между клиентом и KMS. Этот шаг требует процесса аутентификации между клиентом и KMS, что делает невозможным для Cisco или любых третьих лиц просмотр или даже изменение какой-либо информации в пути. После процесса аутентификации клиент будет использовать установленный канал для запроса нового ключа шифрования, необходимого для шифрования содержимого, которое будет отправлено другому клиенту.

После того, как сообщение написано, клиент шифрует сообщение с помощью ключа диалога и помечает его идентификатором комнаты назначения Spark, а затем отправляет его на ядро. Затем ядро ​​получает зашифрованное сообщение и, поскольку оно хранится отдельно от области безопасности, не имеет никакого доступа к ключам диалога, необходимым для расшифровки указанного сообщения. Ядро ищет получателя и отправляет зашифрованное сообщение по пути в приемную комнату, а также сохраняет сообщение в базе данных, связанной с принимающей комнатой.

Теперь процесс происходит в обратном порядке, клиент-получатель получает зашифрованное сообщение и связывается с KMS, чтобы получить необходимый ключ для расшифровки сообщения. KMS аутентифицирует обоих пользователей, чтобы проверить необходимые разрешения для открытия сообщения, и передает ключ диалога получателю, чтобы его клиент мог распаковать и прочитать сообщение.

Если все зашифровано, как работает поиск?

Поскольку само ядро ​​никогда не видит какой-либо контент, который вы передаете, вы не можете разрешить простой поиск сообщений через саму облачную службу. Чтобы противостоять этому, Cisco придумала кое-что довольно уникальное — они встроили компонент Indexer непосредственно в Security Realm. Как и KMS, индексатор полностью отделен от ядра, но очень близок к KMS. По сути, индексатор строит и запрашивает поисковый индекс в KMS. Таким образом, все остается зашифрованным, но доступным для поиска.

Оказывается, индексатор на самом деле является ботом Spark, которого приглашают в каждую комнату, в зависимости от политики предприятия. Каждый раз, когда пользователь отправляет сообщение, индексатор получает копию зашифрованного содержимого. и, как и клиент, взаимодействует с KMS, чтобы получить доступ к ключу диалога, необходимому для открытия сообщения. Индексатор применяет хэш, способ аутентификации, к каждому слову в отправленном сообщении и составляет список всех хешированных слов, принадлежащих определенной комнате, где было получено сообщение.

Индексатор даже достаточно умен, чтобы добавлять случайные слова, чтобы полностью гарантировать, что сообщения не могут быть зашифрованы. Затем список хэшей отправляется в Spark Cloud и сохраняется в поисковом индексе в зашифрованном состоянии. Теперь у вас есть доступный для поиска, полностью зашифрованный индекс.

Лучшее из обоих миров

Cisco действительно хотела обеспечить душевное спокойствие, чтобы даже самое параноидальное предприятие могло чувствовать себя в безопасности, отправляя свои данные и файлы через платформу Spark Cloud. Другие потребительские приложения разрешают или даже могут полагаться на доступ к данным самой службы. Благодаря сквозному шифрованию, столь глубоко укоренившемуся в разработке Spark, и даже возможности размещать собственную область безопасности, устанавливать свои собственные параметры и положения, у вас есть Форт-Нокс для обмена деловыми сообщениями и совместной работы.