Рождение облачных технологий. Долгий путь от «текста» к «мультимедиа».

«Чтоб вам жить в эпоху перемен» — раньше эти слова можно было услышать из уст недоброжелателей, но никак не друзей. Для современного человека перемены во всех сферах жизни давно стали нормой, особенно в сфере IT. Сейчас интернет снова, в четвертый раз за последние 40-50 лет, видоизменяется. Рождается новое, интерактивное лицо компьютерной связи, и немалую роль здесь играют мультимедийные технологии, а во многом — облачные. Не верите? Судите сами!
С самого рождения интернет прошел долгий путь от сугубо текстового средства общения до царства мультимедийных технологий. Старые протоколы связи, дошедшие к нам с начала 1970-х — mail и ftp — не имели встроенного интерфейса для передачи бинарных файлов (в том числе и изображений). Появление www, языка гипертекстовой разметки html и средств, умеющих обрабатывать соответствующие конструкции — web-странички — http-серверов и браузеров позволило встроить в html изображение, а позднее — звук и видео. Появление Skype и вебинаров дало возможность мировой сети перейти на привычный нам третий этап развития, мультимедийный и интерактивный: с 3G и Wi-Fi доступом, встроенными вебкамерами, видеочатом в Google, “share to web” в кинокамере и на телефоне и youtube-channel в TV/IPTV.

Перенос центра тяжести исполняемых программ на сервер позволил разгрузить аппаратную часть клиента. Так на смену общению по принципу “one-to-any” пришел принцип “all-to-any” (все — любому), знаменательный как для мультимедийных технологий в целом, так и для облачных — в частности.
Об «эпохе облаков» говорить еще рано, вначале должны утвердиться соответствующие стандарты и принципы обмена данными, вместо текстовых команд управления — появиться если не голосовые, то некоторые общие для всех мультимедийных потоков команды управления и отзыва.

Технические компоненты или «составляющих успеха».

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

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

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

Очевидно, отойдут в прошлое и «логины с паролями»: если сейчас любого пользователя компьютер идентифицирует по «текстовой метке» — login при входе в компьютер, e-mail при доступе к почте, и т.д., а пароль просто подтверждает компьютеру, что по ту сторону экрана находится именно тот пользователь, за кого себя выдает, то для ВКС гораздо более естественным идентификатором может стать не логин, а лицо — гораздо более уникальное, чем логин или ник, а также голос, помогающие нам идентифицировать человека в реальной жизни.
С другой стороны, при качественном изменении каналов связи (переход к ориентации на медиа-контент, а не на текстовый), очевидно, что и объемы передаваемой и обрабатываемой информации возрастут многократно. Скорее всего, изменения коснутся даже таких привычных вещей, как протоколы цифровой связи, и какими они будут, и устоит ли привычный TCP/IP — мы не можем даже догадываться.

Информбезопасность рождающейся ВКС

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

Большую роль играет вопрос комфорта пользователя. Даже в защищенных корпоративных сетях сложность полноценной интеграции систем ВКС вынуждает специалистов и интеграторов выносить ВКС системы за защищенный периметр. Многим известен эксперимент мр. Мура, начальника службы безопасности в Rapid7, который решил «проверить на прочность» защиту ряда компаний и с помощью системы ВКС смог заглянуть в офисы, конференц-залы и переговорные комнаты более дюжины из них. Причина возникновения «дыры» в системе безопасности заключалась в небрежности пользователей, оставивших включенной функцию автоответа и автотраснляции видео, и осознанном выносе используемой ВКС системы за пределы безопасного периметра.

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

Облачный сервис всегда коллективный, и уязвимости одного пользователя могут распространиться и на всех остальных. К примеру, если в видеоконференции через облако, участвуют 5 человек, из них 2 используют суперзащищенный канал, 2 — обычный, а один — очень слабый и совсем без защиты (допустим, тот же 3G с телефона), то свойство «очень слабый и совсем без защиты» характеризует всех пятерых участников конференции. То есть любому пользователю облака можно смело рекомендовать тщательнее выбирать себе друзей, даже по переписке. В чем-то облачные сервисы подобны «проходному двору», и во избежание неприятных последствий, пока авторизация производится не по лицу и речи, а по логину-паролю-ключу шифрования, не стесняйтесь менять их почаще.

Сокращенный вариант статьи опубликован в журнале ИКС (http://iksmedia.ru/issue/2012/9/4496796.html)