Содержание статьи
Сказка — ложь, да в ней намек
Начало этой истории можно рассказывать, как известную сказку. Было в фирме три админа: старший умный был детина, средний был и так и сяк, младший вовсе был… стажером-эникейщиком. Заводил юзеров в Active Directory и крутил хвосты цискам. Пришло время компании расширяться, и призвал царь, то есть босс, свое админское воинство. Желаю, говорит, новые веб-сервисы для наших клиентов, собственное файловое хранилище, управляемые базы данных и виртуальные машины для тестирования софта.
Младшенький с ходу предложил создать с нуля собственную инфраструктуру: закупить серверы, установить и настроить софт, расширить основной интернет-канал и добавить к нему резервный — для надежности. И фирме спокойнее: железо всегда под рукой, в любой момент чего-нибудь заменить или перенастроить можно, и самому ему представится отличная возможность прокачать свои админские скиллы. Подсчитали и прослезились: не потянет компания таких затрат. Крупному бизнесу подобное под силу, а вот для среднего и малого — слишком накладно получается. Это ж нужно не просто оборудование приобрести, серверную оборудовать, кондиционеры повесить да противопожарную сигнализацию наладить, требуется еще и посменное дежурство организовать, чтобы денно и нощно за порядком следить и отражать сетевые атаки лихих людей из интернета. А по ночам и в выходные админы работать почему-то не захотели. Если только за двойную оплату.
Старший админ поглядел задумчиво в окошко терминала и предложил поместить все сервисы в облако. Но тут его коллеги принялись пугать друг друга страшилками: дескать, облачная инфраструктура имеет незащищенные интерфейсы и API, плохо балансирует нагрузку разных клиентов, из-за чего могут пострадать твои собственные ресурсы, а еще неустойчива к краже данных и внешним атакам. Да и вообще, боязно передавать контроль над критичными данными и ПО посторонним лицам, с которыми ты не съел пуд соли и не выпил ведро пива.
Средненький подал идею разместить всю IT-систему в дата-центре провайдера, на его каналах. На том и порешили. Однако тут нашу троицу поджидало несколько неожиданностей, не все из которых оказались приятными.
Во-первых, любая сетевая инфраструктура требует обязательного наличия средств защиты и безопасности, которые, конечно, были развернуты, настроены и запущены. Только вот стоимость используемых ими аппаратных ресурсов, как оказалось, должен оплачивать сам клиент. А ресурсы современная система ИБ потребляет немалые.
Во-вторых, бизнес продолжал расти и построенная изначально инфраструктура быстро уперлась в потолок масштабируемости. Притом для ее расширения простой смены тарифа оказалось недостаточно: многие сервисы в этом случае пришлось бы переносить на другие серверы, перенастраивать, а кое-что и вовсе перепроектировать заново.
Наконец, однажды из-за критической уязвимости в одном из приложений вся система упала. Админы быстро подняли ее из резервных копий, только вот оперативно разобраться в причинах случившегося не удалось, поскольку для сервисов логирования резервное копирование настроить забыли. Ценное время было потеряно, а время, как гласит народная мудрость, — это деньги.
Подсчет расходов и подведение итогов привели руководство компании к неутешительным выводам: прав был тот админ, который с самого начала предлагал воспользоваться облачной моделью IaaS — «инфраструктура как сервис». Что же касается безопасности таких платформ, то об этом стоит поговорить отдельно. И сделаем мы это на примере самого популярного из подобных сервисов — Яндекс.Облака.
Безопасность в Яндекс.Облаке
Начнем, как советовал девочке Алисе Чеширский Кот, с начала. То есть с вопроса разграничения ответственности. В Яндекс.Облаке, как и в любых других подобных платформах, провайдер отвечает за безопасность предоставляемых пользователям сервисов, в то время как в сферу ответственности самого клиента входит обеспечение правильной работы разрабатываемых им приложений, организация и разграничение удаленного доступа к выделенным ресурсам, конфигурирование баз данных и виртуальных машин, контроль над ведением логов. Впрочем, для этого ему предоставляется весь необходимый инструментарий.
Безопасность cloud-инфраструктуры Яндекса имеет несколько уровней, на каждом из которых реализованы собственные принципы защиты и применяется отдельный арсенал технологий.
Физический уровень
Ни для кого не секрет, что Яндекс располагает собственными дата-центрами, которые обслуживают собственные же отделы безопасности. Речь идет не только о видеонаблюдении и службах контроля доступа, призванных предотвратить проникновение в серверные посторонних, но и о системах поддержания климата, пожаротушения и бесперебойного питания. От суровых охранников мало толку, если стойку с вашими серверами однажды зальет водой из противопожарных оросителей или они перегреются после отказа кондиционера. В дата-центрах Яндекса такого с ними точно не случится.
Кроме того, аппаратные средства Облака физически отделены от «большого Яндекса»: они расположены в разных стойках, но в точности так же проходят регулярное регламентное обслуживание и замену комплектующих. На границе этих двух инфраструктур используются аппаратные файрволы, а внутри Облака — программный Host-based Firewall. Кроме того, на коммутаторах Top-of-the-rack применяется система управления доступом ACL (Access Control List), что значительно повышает безопасность всей инфраструктуры.
Яндекс на постоянной основе проводит сканирование Облака извне в поисках открытых портов и ошибок в конфигурации, благодаря чему потенциальную уязвимость можно распознать и ликвидировать заранее. Для работающих с ресурсами Облака сотрудников реализована централизованная система аутентификации по ключам SSH с ролевой моделью доступа, а все сессии администраторов логируются. Такой подход является частью повсеместно применяемой Яндексом модели Secure by default: безопасность закладывается в IT-инфраструктуру еще на этапе ее проектирования и разработки, а не добавляется потом, когда все уже запущено в эксплуатацию.
Инфраструктурный уровень
На уровне «аппаратно-программной логики» в Яндекс.Облаке используются три инфраструктурных сервиса: Compute Cloud, Virtual Private Cloud и Yandex Managed Services. А теперь о каждом из них чуть подробнее.
Compute Cloud
Этот сервис предоставляет масштабируемые вычислительные мощности для различных задач, таких как размещение веб-проектов и высоконагруженных сервисов, тестирование и прототипирование или временная миграция IT-инфраструктуры на период ремонта либо замены собственного оборудования. Управлять сервисом можно через консоль, командную строку (CLI), SDK или API.
Безопасность Compute Cloud базируется на том, что все клиентские виртуальные машины используют минимум два ядра, а при распределении памяти не применяется overcommitment. Поскольку в этом случае на ядре исполняется только клиентский код, система не подвержена уязвимостям вроде L1TF, Spectre и Meltdown или атакам на побочные каналы.
Кроме того, Яндекс использует собственную сборку Qemu/KVM, в которой отключено все лишнее, оставлен только минимальный набор кода и библиотек, необходимых для работы гипервизоров. При этом процессы запускаются под контролем инструментария на базе AppArmor, который с использованием политик безопасности определяет, к каким системным ресурсам и с какими привилегиями может получить доступ то или иное приложение. AppArmor, работающий поверх каждой виртуальной машины, уменьшает риск того, что клиентское приложение сможет получить доступ из ВМ к гипервизору. Для получения и обработки логов Яндекс выстроил процесс поставки данных от AppArmor и песочниц в собственный Splunk.
Virtual Private Cloud
Сервис Virtual Private Cloud позволяет создавать облачные сети, используемые для передачи информации между различными ресурсами и их связи с интернетом. Физически этот сервис поддерживается тремя независимыми ЦОД. В этой среде логическая изоляция осуществляется на уровне многопротокольного взаимодействия — MPLS. При этом Яндекс постоянно проводит fuzzing стыка SDN и гипервизора, то есть со стороны виртуальных машин во внешнюю среду непрерывно направляется поток неправильно сформированных пакетов с целью получить отклик от SDN, проанализировать его и закрыть возможные бреши в конфигурации. Защита от DDoS-атак при создании виртуальных машин включается автоматически.
Yandex Managed Services
Yandex Managed Services — это программное окружение для управления различными сервисами: СУБД, кластерами Kubernetes, виртуальными серверами в инфраструктуре Яндекс.Облака. Здесь большую часть работы по обеспечению безопасности сервис берет на себя. Все резервное копирование, шифрование резервных копий, Vulnerability management и так далее обеспечивается автоматически программными средствами Яндекс.Облака.
Инструменты реагирования на инциденты
Для своевременного реагирования на инциденты, связанные с информационной безопасностью, требуется вовремя определить источник проблемы. Для чего необходимо использовать надежные средства мониторинга, которые должны работать круглосуточно и без сбоев. Такие системы неизбежно будут расходовать ресурсы, но Яндекс.Облако не перекладывает стоимость вычислительных мощностей инструментов безопасности на пользователей платформы.
При выборе инструментария Яндекс руководствовался еще одним важным требованием: в случае успешной эксплуатации 0day-уязвимости в одном из приложений злоумышленник не должен выйти за пределы хоста приложения, в то время как команда безопасности должна моментально узнать об инциденте и среагировать нужным образом.
И последнее, но не самое маловажное пожелание заключалось в том, чтобы все инструменты имели открытый исходный код. Этим критериям полностью соответствует связка AppArmor + Osquery, которую и решено было использовать в Яндекс.Облаке.
AppArmor
AppArmor уже упоминался выше: это программный инструмент упреждающей защиты, основанный на настраиваемых профилях безопасности. Профили используют технологию разграничения доступа на основании меток конфиденциальности Mandatory Access Control (MAC), реализуемую с помощью LSM непосредственно в самом ядре Linux начиная с версии 2.6. Разработчики Яндекса остановили свой выбор на AppArmor по следующим соображениям:
- легкость и быстродействие, поскольку инструмент опирается на часть ядра ОС Linux;
- это решение с открытым исходным кодом;
- AppArmor можно очень быстро развернуть в Linux без необходимости писать код;
- возможна гибкая настройка с помощью конфигурационных файлов.
Osquery
Osquery — это инструмент мониторинга безопасности системы, разработанный компанией Facebook, сейчас он успешно применяется во многих IT-отраслях. При этом инструмент кросс-платформенный и имеет открытый исходный код.
С помощью Osquery можно собирать информацию о состоянии различных компонентов операционной системы, аккумулировать ее, трансформировать в стандартизированный формат JSON и направлять выбранному получателю. Этот инструмент позволяет писать и направлять приложению стандартные SQL-запросы, которые сохраняются в базе данных rocksdb. Можно настроить периодичность и условия выполнения или обработки этих запросов.
В стандартных таблицах уже реализовано много возможностей, например можно получить список запущенных в системе процессов, установленных пакетов, текущий набор правил iptables, сущности crontab и прочее. «Из коробки» реализована поддержка получения и парсинга событий из системы аудита ядра (используется в Яндекс.Облаке для обработки событий AppArmor).
Сам Osquery написан на C++ и распространяется с открытыми исходниками, можно их модифицировать и как добавлять новые таблицы в основную кодовую базу, так и создавать свои расширения на C, Go или Python.
Полезная особенность Osquery — наличие распределенной системы запросов, с помощью которой можно в режиме реального времени выполнять запросы ко всем виртуальным машинам, находящимся в сети. Это может быть полезно, например, если обнаружена уязвимость в каком-либо пакете: с помощью одного запроса можно получить список машин, на которых установлен этот пакет. Такая возможность широко используется при администрировании больших распределенных систем со сложной инфраструктурой.
Выводы
Если мы вернемся к истории, рассказанной в самом начале этой статьи, то увидим, что опасения, заставившие наших героев отказаться от развертывания инфраструктуры на облачной платформе, оказались беспочвенны. По крайней мере, если речь идет о Яндекс.Облаке. Безопасность созданной Яндексом cloud-инфраструктуры имеет многоуровневую эшелонированную архитектуру и потому обеспечивает высокий уровень защиты от большинства известных на сегодняшний день угроз.
При этом за счет экономии на регламентном обслуживании железа и оплате ресурсов, потребляемых системами мониторинга и предупреждения инцидентов, которые берет на себя Яндекс, использование Яндекс.Облака заметно экономит средства малому и среднему бизнесу. Безусловно, полностью отказаться от отдела IT или департамента, отвечающего за информационную безопасность (особенно если обе эти роли объединены в одной команде), не получится. Но Яндекс.Облако существенно снизит трудозатраты и накладные расходы.
Поскольку Яндекс.Облако предоставляет своим клиентам защищенную инфраструктуру со всеми необходимыми инструментами обеспечения безопасности, они могут сосредоточиться на бизнес-процессах, оставив задачи сервисного обслуживания и мониторинга железа провайдеру. Это не устраняет необходимости текущего администрирования ВМ, БД и приложений, но такой круг задач пришлось бы решать в любом случае. В целом можно сказать, что Яндекс.Облако экономит не только деньги, но и время. А второе, в отличие от первого, невосполнимый ресурс.
