Для начала я бы хотел обратить внимание, что облака разные. Очень разные, не только по технической реализации — но и по сути функционирования и бизнес-задачам, и только когда мы четко понимаем первое, можно говорить о некой «безопасности».

БУМАЖНАЯ ИБ

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

эту информацию кому попало, неизвестно куда. Конечно, мы понимаем, что к реальным проблемам ИБ это относится мало, но вот предположим, что хранится у нас на Амазоне два миллиона емейлов и ФИО пользователей. Мы их защищаем так же, а на самом деле даже лучше, как если бы они хранились у нас в ЦОДе. Тогда в чем разница?

В том, что на Амазоне могут прийти дяди из АНБ и вставить «сниффер» при помощи Амазона? Могут, и в итоге они получат данные пользователей

нашего магазина «Рог изобилия отменных товаров по низким ценам». Так и сами амазоновцы могут… сколько врагов у нашего магазина!

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

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

Мерчанты, онлайн-сервисы, задачи документо-оборота или бэкапа очень выгодно могут быть выделены в облако, и только зануды регуляторы могут понатыкать палки в колеса, тормозя прогресс и эффективность, — все это надо взвесить и учесть, и, если публичное облако не подходит, всегда можно разработать свое, частное облако в своих ЦОДах (если ресурсы позволяют и это того стоит).

Еще облако может быть полезно и для другой категории бизнесов, частный пример — бэкап в облаке за кордоном. Ведете вы себе бизнес, никого не трогаете, немного мухлюете то там, то тут, и вот однажды к вам маски-шоу — бац… а у вас все серверы чистые и пушистые, так как вся тема где-то в облаках :).

Тру стори, бро!

Рис.1. Ищите ключи доступа к облакам… особенно в мобильных приложениях :)

Рис.2. Scout2 — простой скрипт, пример автоматизации и анализа настроек вашего AWS-аккаунта

НЕБУМАЖНАЯ ИБ

Когда вопрос доходит до не теоретических анализов угроз и страхов перед НЛО, то вполне очевидно, что облачные решения — это те же информационные технологии и решения, которые применяются и в обычных ЦОДах. А если уже говорить на более конкретных примерах, то особой разницы вообще нет. Ну вот у вас есть веб-шоп в публичном облаке — все равно, где вы хоститесь, — если вы написали дырявый PHP-скрипт, вашу базу вытащат и даже не заметят, в облаке вы или нет. Отсюда вывод: безопасность в облаке — вопрос точно такой же, как и безопасность не в облаке, и придется решать абсолютно те же задачи, кроме задачи доверия к физике и провайдеру облака. Так что смело могу заявить, что шум вокруг облачной ИБ довольно надуманная вещь и связан он в основном с «бумажной ИБ». Облачные решения не менее дырявы и не более безопасны, чем любые другие. Есть свои плюсы и минусы, но они уже зависят от конкретной реализации.

ОБЛАЧНАЯ ПОЛЬЗА

О чем я хочу поговорить, так это о пользе облачных решений в нашем нелегком деле защиты информации. Почему-то в основном сводят разговоры к тому, что облака нуждаются в дополнительных и специализированых решениях, особом аудите и прочем, но мало кто говорит о том, что облако можно делать с умом, встраивая в его архитектуру ИБ. Несколько последних выпусков колонки я активно писал именно про это: про то, как можно делать облака безопасными, и делать так, что эти ИБ-решения будут прозрачными и независимыми от разработчиков и администраторов конкретных систем, расположенных на облаке. Речь шла как о частном облаке, так и о публичном облаке Amazon — как использовать его c умом. Не хочу особо повторяться, но если коротко, то, делая частное облако, мы можем в саму архитектуру заложить такие вещи, как шаблоны безопасной конфигурации, NIDS/HIDS, контроль за апдейтами, сканирование уязвимостей и даже SIEM. Таким образом, какой бы сложной ни была система, сколько бы таких систем мы ни крутили в облаке, даже если их делают разные команды разработчиков и админов, мы имеем унифицированную систему ИБ, полный мониторинг и контроль над ситуацией (ладно, ладно, почти полный). И все это работает благодаря облачным технологиям и при этом дешевле. Так я хочу сказать, что использование облаков может улучшить ситуацию с ИБ.

ШАБЛОНЫ БЕЗОПАСНОЙ КОНФИГУРАЦИИ

Строя свою облачную инфраструктуру, мы работаем с некими минимальными «объектами». Наши пользователи будут работать с виртуальными ОС, на которых крутится софт. Если в нашем облаке автоматизировано создание образов ОС и пресеты пакетов и их конфигураций, то мы можем задать некую базу, которая будет сконфигурирована и безопасно настроена изначально нами. Если кому-то понадобится создать новый сервер с Tomcat, он деплоит все это из наших образов и пакетов, с нашими стандартами конфигурации, и никакой tomcat/tomcat и менеджмент-консоль не будут торчать в интернет, не говоря уж о root для SSH!

SIEM / HIDS / АУДИТ ПЛАТФОРМЫ

Исходя из предыдущего пункта, мы можем, используя те же механизмы, и настроить систему сбора событий, и внедрить системы мониторинга (да хоть агенты OSSEC), и провести некий автоматизированный аудит системы, включая патч-менеджмент.

NIDS

Как в частном облаке, если мы разрабатываем решение в своем ЦОДе, мы можем довольно просто и непринужденно использовать hardware IDS решения, включая их в сеть для мониторинга всего трафика, в том числе виртуального. Но конечно, можно делать и виртуальные IDS и подобные решения, здесь разницы вообще нет. Могут возникнуть проблемы с публичными облаками, но и там все можно решить довольно просто.

ИНВЕНТАРИЗАЦИЯ И АКТИВНОЕ СКАНИРОВАНИЕ

Понятно, что разработчики и администраторы не будут пользоваться только предоставленными конфигами и пакетами — они будут беспощадно менять конфигурацию, деплоя свой код, ставя свои пакеты и прочее, и прочее. Частично с этой задачей будет справляться автоаудит платформы, но, кроме того, сколько бы машин кто ни заказывал, мы точно всегда знаем, кто, где и когда что задеплоил и какие пакеты там стоят. Автоматическая инвентаризация и контроль — разве это не мечта? Это очень хорошо ложится на задачи сканирования уязвимостей — мы добавляем в наш сканер новые виртуальные хосты автоматически! И по всем фронтам у нас получается отличное покрытие. В идеальном мире, конечно, как известно, дьявол кроется в деталях, но тем не менее я считаю, что такие решения при грамотном использовании могут и будут улучшать состояние ИБ системы в целом, при том что дыры везде одинаковые.

AMAZON

Отдельно хочу поговорить про Амазон, с которым мне приходится работать. Можно ли сказать, что если вы выкидываете ваше решение, будь то навигационная система или веб-шоп, в Амазон, то вы стали защищеннее? Или, наоборот, уязвимее? Как обычно, ответ скучен и банален: зависит от вас. Тем не менее я бы хотел выделить некие фичи Амазона, которые с точки зрения ИБ делают ваши потуги в этом направлении дешевле.

Во-первых, AWS предоставляют много удобных механизмов унификации и контроля. О них я уже писал, но все же повторюсь: удобный API, стандарты шаблонов конфигурации, включая секурити-группы (правила фильтрации трафика), изолированные среды, двухфакторная аутентификация. Используя этот API, можно довольно просто автоматизировать многие процессы ИБ, включая то же сканирование ресурсов, контроль и аудит секурити-групп, доступ к хранилищам S3, контроль версий образов виртуалок. Это довольно мощный и полезный инструмент при правильном применении. Маленькое, но полезное дополнение: у AWS есть IDS, какой-никакой, но он есть и может детектировать довольно полезные вещи в случае, если какой-либо из ваших боксов скомпрометирован. Вся работа по оптимизации правил и покрытию лежит на ресурсе Амазона и для нас абсолютно прозрачна. Надо понимать, что эта ИДС не заменит своего решения, поскольку детектирует довольно определенные вещи, с целью снижения фолз-позитивов, так как это штука универсальная и общая для всех клиентов. Кроме того, Amazon имеет абуз-центр, который принимает всю информацию о жалобах, вроде атак с вашего хоста, что опять же позволит быстро среагировать на инцидент. Кроме пассивной работы, команда AWS берет на себя часть хлопот и по проактивной защите, например, они сканят репозитории, ну скажем GitHub, и детектируют «захаркоденные» ключи доступа к аккаунту AWS (да, это довольно популярный фейл). То есть если кто-то из ваших разработчиков слил ключи на гитхаб, Амазон узнает это раньше, чем парни, которые хотят майнить *коины.

Или давайте разберем пример с Heartbleed. К сожалению, лоадбалансеры AWS использовали уязвимую версию OpenSSL, и, с одной стороны, все плохо — все дыряво… Но с другой стороны, они проапдейтили все регионы в течение 24 часов, без напоминаний и пинков, тогда как некоторые российские платежные шлюзы хлопали ушами больше недели без всяких облаков, и если бы они пользовались AWS, то при той же нерасторопности не утекли бы данные карт стольких пользователей.

ВМЕСТО ВЫВОДА

Моя мысль банальна и проста и, может, не заслуживает особого внимания, но на фоне того, как все консультанты и вендоры ИБ твердят, что облака — это опасное зло, мне хотелось бы показать что-то светлое и приятное. Да, решения могут иметь разные цели, разный функционал и суть, но главное, что все же облака могут быть полезны и помочь нам сделать этот мир безопаснее и красивее.

Источник: журнал Хакер Nª 186