Безопасность в облаке: 10 главных ошибок19.10.2020 11:15

19.10.2020, Пн, 10:55, Мск , Текст: Александр Тыренко

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

Синергия облаков и безопасности

В эпоху пандемии облака остались чуть ли не единственным сегментом рынка информационных технологий, который будет расти даже в текущем году. Пусть ненамного, всего на 6,3% по прогнозу Gartner, но на фоне общего падения ИТ-рынка в 7,3% (по оценке той же аналитической компании), его динамика выглядит очень неплохо.

Прогноз мировых доходов от публичных облачных сервисов, $млн

Другой растущий, хотя тоже медленно, сегмент — информационная безопасность, затраты на нее вырастут в 2020 г. на 2,4% (в декабре планировался рост на 8,7%). При этом продажи средств облачной безопасности, принадлежащих обоим сегментам, вырастут на 33,3%, полагают в Gartner. Потрясающая скорость роста на фоне общего падения или, в лучшем случае, стагнации.

Мировые расходы на информационную безопасность в 2020 г., $млн

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

Для безопасности нужны двое

Защита облачных систем, отмечает эксперт в области ИТ Дэвид Стром (David Strom), — сфера ответственности как провайдеров облачных услуг, так и самих клиентов (хотя, надо признать, реклама облаков, зачастую, строится на том, что провайдер услуг сделает все сам).

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

Но при головокружительных темпах изменения ПО с постоянным изменением объема потребляемых ресурсов облака о нюансах безопасности нередко забывают, полагает Дэвид Стром. Безопасность облачных нагрузок должна обеспечиваться с помощью соответствующего агентского ПО, но как показывает практика, при подключении все новых облачных ресурсов эту необходимость могут упускать из виду. В результате злоумышленники могут обнаружить слабозащищенный ресурс — например, «позабытую» тестовую рабочую нагрузку, и через него проникнуть в сеть организации. По данным исследования, проведенного Orca Security, у подавляющего большинства организаций есть доступные извне рабочие нагрузки под управлением устаревшей или не имеющей свежих заплат операционной системы, а у 5% одна или больше задач доступны по ненадежным или утекшим в Сеть паролям.

Сообщения об атаках на неверно настроенные облачные серверы, приводящих к утечкам конфиденциальных данных, появляются с пугающей регулярностью, при этом причиной обычно являются спешка и забывчивость разработчиков. Дэвид Стром выделил 10 главных ошибок.

1. Оставлять «незапертые» контейнеры

Одно из наиболее частых упущений в области безопасности связано с незащищенными облачными хранилищами. Исследователи регулярно обнаруживают их даже у крупных организаций, просто перебирая очевидные URL-адреса. Разработчики для скорости и удобства могут завести, например, на Amazon S3 контейнер со свободным доступом, о чем затем забывают, и брешь переходит в рабочий релиз. Такие контейнеры могут содержать огромные объемы корпоративных данных, в том числе баз по клиентам и других. В этом отношении показателен пример компании SSL247, поставщика средств ИТ-безопасности, у которого исследователи обнаружили свободно доступное хранилище емкостью 158 Гбайт, содержавшее порядка 465 тыс. конфиденциальных файлов.

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

2. Некритично использовать проекты с открытым кодом

Определенную опасность таит в себе бесконтрольное использование группами разработки проектов с открытым кодом. Известен пример, когда специалисты по безопасности GitHub обнаружили вредоносную программу, которая автоматически встраивала бэкдоры в Java-проекты с открытым кодом на этапе сборки, о чем владельцы проектов были даже не в курсе. Защититься от подобных случаев тоже помогут автоматизированные средства обеспечения безопасности контейнеров.

3. Доверять SMS для создания многофакторной защиты аккаунта — или вообще не иметь такой защиты

Исследование Orca показало, что почти в четверти организаций пренебрегают применением многофакторной аутентификации для защиты привилегированных учетных записей в облаке. При этом надо отметить, что применение двухфакторной аутентификации с получением кода по SMS сегодня уже не считается достаточной защитой в связи с тем, что злоумышленники могут элементарно подсмотреть присланный вам код, либо прибегнуть к более сложным способам — клонированию SIM-карты или атаке прослушивания сотовой сети. Соответственно, для защиты облачных административных аккаунтов лучше применять специальные приложения для двухфакторной аутентификации, такие как Google Authenticator или им подобные. В Azure особое внимание следует уделить защите аккаунта глобального администратора, так как сотрудник с этой ролью имеет доступ ко всем административным настройкам Azure Active Directory.

4. Назначать слишком много прав и слишком мало паролей

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

5. Не управлять своими секретами

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

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

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

6. Не следить за удаленным доступом

Стоит упомянуть о еще одном возможном упущении. Облачные серверы нередко предоставляют сразу несколько возможностей удаленного доступа, например, по SSH, RDP и через веб-консоль. Все из них могут быть скомпрометированы — из-за ненадежных паролей или утечки верительных данных. Необходимо учитывать все возможные методы удаленного доступа и либо отключать их за ненадобностью, либо обеспечивать соответствующий уровень защиты.

7. Оставлять открытыми неиспользуемые порты

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

8. Не вести журнал событий

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

9. Не защищать приложения

Распространенное упущение — пренебрежение защитой веб-приложений. По данным отчета Verizon Data Breach 2020, количество атак, направленных на веб-приложения, за последний год увеличилось более чем вдвое. Часто такое приложение может быть соткано из сложного набора различных систем, которые обращаются к десяткам серверов и служб.

Особенно уязвимы сайты на WordPress с малопопулярными, необновляемыми и уязвимыми плагинами, которые можно скомпрометировать с помощью атак межсайтового скриптинга. В ходе исследования, проведенного Wordfence, было обнаружено около миллиона таких уязвимых сайтов.

Для защиты сайтов на WordPress существуют специализированные коммерческие средства безопасности, которые оценивают уровень защищенности и помогают избавляться от уязвимых плагинов. Что касается других серверов веб-приложений, поможет применение соответствующих межсетевых экранов.

Пользователям Office 365 следует обратить внимание на сервис Microsoft Defender Application Guard (раньше он назывался Office 365 Advanced Threat Protection), который проверяет документы на возможные угрозы, предотвращая распространение вредоносных программ по организации.

10. Не следить за обновлением ПО и средств защиты

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

Технологии у нас есть…

Как следует из исследования Orca, примерно в 45% опрошенных организаций признались, что имеют доступные из Интернета рабочие нагрузки, которые содержат верительные данные или ключи API в открытом виде. А почти в 80% организаций как минимум 10% внутренних рабочих нагрузок выполняются под управлением устаревшей либо не имеющей заплат ОС. Последнее, отмечают авторы исследования, значительно облегчает злоумышленникам продвижение по корпоративной сети после того, как они, скомпрометировав облачную нагрузку, проникли внутрь. А неправильно сконфигурированные сервисы хранения обнаружились и вовсе у 93% организаций, обследованных Accurica.

Столь обескураживающие результаты не свалить на отсутствие средств безопасности. Только на соответствующей кривой хайпа Gartner отмечено три с лишним десятка «самых перспективных» технологий и сервисов.

Технологии для обеспечения безопасности облаков на кривой хайпа Gartner

Источник: Gartner, 2020

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

Полный текст статьи читайте на CNews