Туман войны или Туман неизвестности — термин для обозначения ситуации, когда все действия происходят в состоянии наличия только недостоверных данных и постоянного проявления неожиданных, случайных эффектов. Клаузевиц К. О войне
Кто из нас не любовался красотой облаков? Их непостоянство или величие завораживает. Но кто знает, как устроено то или иное облако, и что будет, если неопытный пилот, не зная типа облака, нырнет в него с ходу?
Ситуация с так называемыми «облаками», продвигаемыми в ИТ, полностью аналогична. Постоянно утверждали и продолжают утверждать, что «облака» безопасны — и рефрен принес свои плоды. Как показывают опросы, большинство компаний, перешедших в «облака», снизили затраты на безопасность. И это свидетельствует о том, что еще один миф завершил свое формирование.
Изначально, на старте пропагандистской кампании, под «облаками» подразумевалось разнесение сервисов по всему Интернету — пользователь не должен был знать, где находятся его данные, а распределение данных гарантировало их неуничтожимость и доступность в любой момент. Наиболее близки к этим идеям были системы, подобные проекту поиска внеземных цивилизаций. Минусом такого подхода было не гарантируемое время отклика — именно тот параметр, который зачастую крайне критичен для бизнеса. Если время обработки пакета в системе поиска внеземных цивилизаций не значимо — и, более того, не значим и факт обработки посланного пакета, так как его можно перепослать другому участнику проекта, то для бизнеса задержка письма даже на несколько минут письма, а тем более потеря письма или части файла может быть фатальна.
В дальнейшем под переходом в «облако» стало подразумеваться использование площадок ЦОДов (дата-центров) или применение в компаниях сервисов, расположенных на этих площадках, — IaaS, SaaS, HaaS, WaaS, PaaS… При этом все так же пропагандировалось, что перемещение в «облака» повышает безопасность. На фоне волны интереса к облакам очень многие вендоры объявили о поддержке «облачных» технологий, выпуске «облачных» платформ. И пропаганда преимуществ дала свои плоды — крупные компании одна за другой начали заявлять о переходе в «облака».
Но что происходило на деле? Компании, имеющие филиалы и сотрудников, работающих удаленно, можно считать «облачными» сразу — для них в общем случае нет разницы, где конкретно расположен тот или иной сотрудник или клиент, приславший запрос, — важен уровень связи с ним и устойчивость этой связи. Где находится площадка, на которой расположены серверы компании (на территории компании или вне ее), арендуются ли серверы или используются собственные — с точки зрения терминологии не важно. Сколько сотрудников компании знают, где находятся ее серверы? Но раскрученное понятие позволило руководителям ИТ-подразделений получить финансирование/перевести серверы на внешнюю площадку…
Естественно, не все компании могли вывести серверы наружу — скажем, в связи с обработкой данных, имеющих статус гостайны, или по причинам, связанным с недостаточной скоростью передачи данных. Поэтому для тех, кто не может или не хочет использовать внешнюю площадку, был придуман термин «внутреннее облако». С этого момента каждая серверная может себя именовать гордо «облаком» — тем более что паутина кабелей и проводов зачастую точно соответствует виду настоящего облака издали, а стандартного определения, что «облако», а что «не облако», не существует.
Многие программные продукты и до эпохи «облаков» были «облачными» — кто знает, где конкретно располагаются серверы обновлений антивирусов, или на каком сервере провайдера находится сервер услуги Dr.Web AV-Desk? И эти продукты действительно разрабатывались с учетом требований по безопасности и отказоустойчивости. Но на фоне ажиотажного интереса к «облакам» появился ряд продуктов, имеющих приставку «облачные» непосредственно в названии, но однозначно небезопасных. В качестве примера можно привести репутационные сервисы, появившиеся у большинства антивирусных продуктов. В их основе лежит идея, что миллион леммингов не может ошибаться если у многих пользователей некий файл признан незараженным, то остальные тоже могут его не бояться. При этом не принимается в расчет, что в любой произвольный момент времени антивирус не может знать всех угроз, то есть некий файл, распространившийся у пользователей, вполне может быть вирусом, который еще не дошел до ловушки антивирусной компании. Если мошенников-фишеров, подделывающих сайты или использующих горячие новости для выманивания денег, можно преследовать по закону, то почему этого нет здесь? В свое оправдание разработчики этих продуктов говорят, что они никогда не утверждали, что конкретный сервис — это панацея безопасности, что любые сервисы нужно применять в комплексе с другими средствами защиты. Да, этого не утверждалось. Но никогда и не говорилось обратного. «Бойтесь того, кто молчит».
Но это не единственная и, более того, не самая страшная проблема. Гораздо хуже, что понятие безопасности у всех разное. Рекламируя безопасность, ЦОДы не кривят душой. Действительно, ЦОДы, имеющие развитые системы пожаротушения, охлаждения, резервирования питания и т. д., получившие сертификат TIER3 или аналогичный, безопасны. С точки зрения хранения данных. Но клиенты ЦОДов под безопасностью понимают не только безопасность хранения. Им нужна гарантия, что к их данным не получит доступ никто, кроме их собственных сотрудников, что данные в процессе передачи в ЦОД и обратно не будут изменены, что данные после окончания обработки можно удалить — в том числе и из резервных копий. Нужна гарантия взломоустойчивости виртуальных серверов — в том числе со стороны виртуальных машин, работающих на одном физическом сервере. В конце концов, клиентам «облаков» нужны гарантии возмещения убытков, возникших, скажем, вследствие простоя или несанкционированного доступа. Ведь за то же самое собственные администраторы понесли бы заслуженное наказание. Почему при выводе в «облака» это невозможно? Это все должно прописываться в договоре на обслуживание и в SLA (Cоглашение об уровне предоставления услуги). Но кто в них видел пункты о денежных компенсациях в связи с недостаточной защитой?
В стране активно создается национальная облачная платформа — ради этого в Москве строится крупнейший в стране дата-центр. Поставщик платформы готов предлагать бизнесу как общие офисные решения от «1С» и Microsoft, так и специализированные отраслевые (для медицинских учреждений, школ и пр.). Если пропадет важное письмо — то это критично, но поправимо; но что делать, если по вине «облачной» медицинской системы случится непоправимое — да хоть в связи с высокой загрузкой канала или временной недоступностью? В России достаточно мест, в которых доступность Интернета весьма условная — и наличие удаленно мощного центра проблему доступности не решит.
В 2011 г. крупнейшие провайдеры «облачных» сервисов Google и Amazon прерывали свою работу из-за сбоев — из-за проблем с инфраструктурой и ошибками в программном обеспечении. Пользователи «облачных» сервисов в течение долгого времени не могли получить к ним доступ. Кто из партнеров данных сервисов получил компенсации?
Добрая половина компаний, перешедших в «облако», ошибалась, думая, что «облачные» технологии позволят быстрее восстанавливать ИТ-системы после сбоев, зря надеялись на повышение эффективности систем, снижение расходов и повышение безопасности.
Правительство США хочет обязать компании предоставлять правоохранительным органам доступ к облачным хранилищам по запросу. Возможно, основанием для предоставления доступа к «облачной» среде может стать факт использования технологий шифрования. Но как получать защищенный удаленный доступ без шифрования? Кто даст гарантии, что этот запрос не повредит вашему бизнесу?
В завершение - слова аналитика Gartner Грега Крайзмана: «Облако не схоже со старыми моделями развертывания и использования программного обеспечения, при которых ПО устанавливается и управляется внутри организаций. Поскольку провайдеры SaaS используют другие интерфейсы, возник риск попадания под большее количество атак, кроме того, больше людей обладает доступом к данным».
