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

Удивительно здесь не то, что эти сбои или взломы произошли, а то, что масштабы оказались не настолько велики, как могли бы быть. Как и число пострадавших. Впрочем, не исключено, что всевозможных инцидентов было намного больше, просто они не становились достоянием широкой гласности. Но об этом ниже.

Досадная мелочь

Один из инцидентов произошел утром 26 февраля 2008 года. Ряд пользователей онлайновых сервисов Microsoft, в том числе и облачных, в частности Office Live (предшественника Office WebApps) и SkyDrive, обнаружили, что не могут получить доступ к своим учетным записям. С другой стороны, появились жалобы на то, что вместо своей учетной записи открывалась чужая.

Случилось это вследствие сбоя системы авторизации Windows Live ID, которая и является общей точкой входа для всех данных сервисов. Более точная причина названа так и не была. Высказывалось предположение, что инцидент вызван ошибками в предрелизной версии Windows Server 2008, под управлением которой якобы работала система авторизации Windows Live ID. Однако Microsoft эти предположения дезавуировала. В качестве наиболее вероятной причины называлась перегрузка оборудования.

Данный инцидент затронул несколько тысяч из без малого полумиллиарда активных пользователей онлайновых сервисов от Microsoft. Утечек данных, критичных с точки зрения законов США, при этом зафиксировано не было. Да и ликвидирован инцидент был спустя несколько часов после обнаружения. Уже через сутки ничто не напоминало о том, что случилось нечто экстраординарное.

Failure as a Service, или Скупость до добра не доводит

А вот другой инцидент был уже более серьезным. Точнее, речь здесь идет о нескольких, как минимум трех инцидентах, которые произошли с несколькими облачными сервисами одной компании, а именно Amazon. В конце апреля 2010-го пользователи хранилищ данных облака Amazon Elastic Block Store обнаружили, что не могут ни записывать, ни считывать свои данные. Многое из того, что хранилось в этих томах, оказалось попросту потеряно. Но на этом неприятности Amazon и его пользователей не закончились. Четвёртого и седьмого мая того же года имели место внеплановые остановы платформы Amazon Web Services, которые продолжались более семи часов. Естественно, ни о какой работоспособности сайтов, чей хостинг был там размещен, не было и речи. Положение несколько сгладило то, что данный инцидент произошёл ночью, когда поток посетителей невелик и потери от простоя ниже, чем могли бы быть.

Что касается Amazon Web Services, то причина проста: сбой электропитания. В случае Amazon Elastic Block Store имела место локальная перегрузка, которая, в свою очередь, привела к потере доступа и проблемам с доступностью данных. Но общее в этих двух инцидентах было одно: никакой реальной избыточности и эластичности, о которой так много говорилось в рекламе данных сервисов, на самом деле в Amazon нет. При наличии хотя бы минимального горячего резерва ни того, ни другого инцидента просто не было бы. Ну или последствия были бы не столь серьезными.

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

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

Когда защита неадекватна

О следующем инциденте стало известно в июле 2011 года. Google официально подтвердила факт массового взлома учетных записей своих сервисов. Среди пострадавших оказались высокопоставленные американские госслужащие, военно­служащие, журналисты, китайские правозащитники, а также сотрудники правительственных структур ряда стран Азии, в первую очередь Южной Кореи.

Взлом был осуществлен китайскими хакерами — вполне вероятно, действующими сотрудниками спецслужб этой страны или по их прямому заказу. Для этого использовался метод фишинга, когда жертву заманивают на специальным образом составленную Web-страницу, откуда и перехватываются пароли для доступа к почте Gmail и другим сервисам, например хранилищу Google Drive, где тоже наверняка можно найти что-то интересное, особенно если речь идет о жертвах высокого ранга.

Надо сказать, что и раньше приходилось слышать о взломе учетных записей той же Gmail. Так, еще в конце 2009 года китайская хакерская группировка с помощью фишинговой атаки на одного из сотрудников украла парольный механизм Gaia, который использовала Google. Этот факт был признан, но не сразу, а спустя несколько недель. Были приняты определенные меры, в частности защищенное соединение при входе пользователей в почту Gmail и для связи между серверами. В марте 2010-го Google начала уведомлять пользователей о подозрении на взлом учетных записей, когда за короткое время имело место как минимум два захода из удаленных друг от друга точек. А на популярном ресурсе Habrahabr в июле сообщалось о том, что отмечаются далеко не единичные случаи использования чужих учетных записей сервисов Google. По всей видимости, пароль был перехвачен с помощью вредоносного ПО при работе через Web. Не исключено, что злоумышленники пользовались уязвимостями в бразуерах, таких как Mozilla Firefox и Opera Mini. В конце концов, почту (и не только) могли «увести» с помощью все того же фишинга или хорошо отработанных методов социальной инженерии. А они активно и успешно используются даже для того, чтобы заполучить пароль другого члена семьи (супруга, детей) и читать их переписку незаметно для адресата.

Конечно, прямой вины Google в данном инциденте нет. Хотя давно ясно, что доступ по одному лишь паролю не является гарантией того, что посторонний не проникнет в чужую учетную запись. В итоге было принято решение использовать многофакторную идентификацию, по крайней мере для сервисов, ориентированных на бизнес, в том числе Gmail и Google Drive. Да и в базовой версии использование номера телефона наряду с паролем тоже является определенной гарантией, эту информацию о совсем постороннем человеке, возможно, с другого конца земного шара получить не так просто.

Под атакой спамеров

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

Подробности о том, как злоумышленники смогли проникнуть в чужие учетные записи DropBox, не разглашались. Однако с большой долей вероятности можно предположить, что всё шло по тем же сценариям, что и в случае с сервисами Google: фишинговые атаки, использование уязвимостей в браузерах, вредоносное ПО (троянцы, кейлоггеры) или методы социальной инженерии.

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

Выводы

Эти инциденты вряд ли станут последними. Однако их влияние на развитие облачных технологий не было таким уж значительным. Инцидент с Windows Live ID коснулся очень небольшого количества пользователей и по большому счету просто остался незамеченным. Да и он произошёл до того, как начался бум облачных технологий. Первое время казалось, что инцидент с Amazon может иметь довольно существенное влияние, но спустя несколько недель шум улегся. Отток клиентов с западного побережья США был компенсирован за счет новых пользователей в других регионах как в Америке, так и в других странах.

В целом инциденты с Windows Live ID и сервисами Amazon, вызванные перегрузками, — всего лишь симптомы детских болезней облачных технологий. Просто их создатели не заложили резервы по масштабируемости, и системы в один далеко не прекрасный день не справились с нагрузкой. И никто не может дать гарантии, что нечто похожее не произойдет где-то еще, в том числе и у нас.

Кроме того, такое может случиться не только с публичным, но и с частным облаком. Так что лучше учиться на чужих ошибках и стараться не допускать возникновения такого рода ситуаций. Ну и стоит задуматься о резервах, чтобы не было простоя, когда мощности вашего поставщика облачных услуг по той или иной причине окажутся недоступны. По крайней мере для развертывания наиболее критичных систем автоматизации. Что касается инцидентов с Google и DropBox, то их и вовсе никак не связали с облачными вычислениями. Так что вся ответственность лежит на пользователях. Можно посоветовать вовремя обновлять браузеры и клиентские программы для доступа к облачным дискам, а также оперативно реагировать на предупреждения о вероятном взломе. Ну и постараться осложнить жизнь злоумышленникам, например, выкладывать файлы в заархивированном виде, да еще и с паролем. А если этот архив будет ещё многотомным, причем разные тома будут храниться на разных дисках, то это уж совсем здорово. Полезно шифровать файлы. Благо такая возможность есть в любой современной программе резервного копирования.

Стоит также избегать использования тех сервисов, где применяются слабые механизмы аутентификации. Не случайно те же Google и DropBox в качестве одной из мер перешли к двухфакторной системе. Ею, естественно, необходимо обязательно воспользоваться. Это позволит избежать хотя бы наиболее примитивных, но и чаще всего используемых методов, которыми пользуются злоумышленники.