Топ-10 ошибок компаний в облаке
Евгений Макарьин,
Руководитель группы разработки продуктов и решений Linxdatacenter
Максим Халькевич,
Руководитель группы цифровых сервисов и информационной безопасности Linxdatacenter
«Переезд» в облако не избавляет компанию от соблюдения базовых требований по информационной безопасности. Более того, при определенных сценариях размещения в ЦОДе многие ИБ-проблемы ложатся на бизнес, а сервис-провайдер может лишь давать рекомендации, чтобы помочь избежать ошибок. Рассмотрим наиболее типичные из них.
1. Непонимание границ ответственности.
Не так давно многие думали, что в облаках хранить и обрабатывать данные опасно. Сегодня встречается другая крайность: «мои данные в облаке, мне не о чем беспокоиться».
Нередко клиенты разных компаний полагают, что сервис-провайдер по умолчанию:
Из-за подобных заблуждений администратор может быть недостаточно хорошо подготовлен к инцидентам, которые могут произойти в будущем.
Чтобы не происходило таких недоразумений, стоит читать договор и консультироваться с сервис-провайдером. В договоре всегда написано, кто за что отвечает. И если клиент хочет, чтобы провайдер взял на себя дополнительную ответственность, то, как правило, за это надо будет доплатить, а изменение границ ответственности оформить документально.
2. Работа из-под «root’а»
Что может быть проще, чем создать одну учетную запись (УЗ) на виртуальной машине или в консоли управления облаком, и все манипуляции со своей инфраструктурой делать через нее? Да, хакерам тоже нравится такой подход: один раз подобрал пароль, а дальше делай с данными и системами все, что хочешь, будто они твои.
Если делиться со злоумышленниками нет желания, то лучше следовать простым правилам:
3. Отсутствие управления паролями
Целый диапазон проблем возникает из-за слабых паролей, которые подбираются простым перебором. Также пароли оставляют в открытом доступе в сети или на физическом носителе. Все это приводит к компрометации и утечке критически важных данных.
Часто клиент не меняет пароль от панели управления облака (vCloud Director), хотя в письме с реквизитами для доступа написано, что это необходимо сделать сразу после первого входа.
Нередко после изначальной настройки ВМ (виртуальных машин) через панель vCloud Director администратор забывает разлогиниться из консолей ВМ. В результате в сочетании с предыдущей ошибкой имеем ситуацию, когда тот, кто перехватил пароль от панели управления облака, может:
Один из самых популярных сценариев является, пожалуй, и самым опасным, так как легко обнаруживается злоумышленниками. Администратор настраивает ВМ, присваивает ей белый IP-адрес, не защищая NAT и Firewall, при этом задает слабый или словарный пароль, который легко подобрать. Через какое-то время такие ВМ находят злоумышленники, сканирующие сеть. А дальше шифрование, рассылка спама и т. д.
Правила игры здесь довольно просты: пароли должны быть надежными, храниться в недоступной для третьих лиц локации, а также регулярно меняться ответственными администраторами ИТ-систем.
4. Отсутствие обновлений и исправлений ПО
Если у вас есть облачные серверы, это не значит, что они будут автоматически устанавливать все исправления на уровне ПО или сами обновляться до последних версий (с оговоркой, что некоторые поставщики управляемых услуг и облачного хостинга предлагают такие услуги).
Статистика показывает, что половина компаний и организаций использует как минимум один устаревший сервер в своей инфраструктуре. Количество кибератак, произошедших из-за непропатченных серверов, просто огромно.
Этот тот самый аспект работы с облачной инфраструктурой, пренебрегать которым просто нельзя – бдительности в управлении патчами не может быть слишком много. Также внимательно относитесь к уведомлениям своего облачного провайдера о значительных обновлениях.
5. Отсутствие обновлений шаблонов
Облака дали нам огромные возможности в плане скорости развертывания и управления ИТ-инфраструктурой. Часто администраторы разворачивают свою инфраструктуру, пользуясь так называемым золотым образом или шаблоном виртуальной машины. Это избавляет от необходимости раз за разом выполнять одни и те же действия и экономит массу времени. Один администратор теперь может развернуть сотни ВМ за считанные часы. С такой же скоростью их можно будет и взломать…
Если забывать регулярно обновлять свой шаблон, а созданные ВМ тут же не патчить, то после взлома одной-единственной виртуальной машины злоумышленник сможет по аналогии взломать и все остальные, используя одну и туже уязвимость сервера.
Регулярное обновление шаблонов значительно сокращает этот риск. Да и патчить один образ гораздо быстрее, чем всех его «потомков».
6. Игнорирование систем мониторинга ресурсов
Многие компании не пользуются услугами системы мониторинга ресурсов, потому что все работает и так, «зачем нам что-то отслеживать». Эта ошибка может привести к возникновению сбоев и неудобств в работе ИТ-систем в облаке.
Если речь идет про собственное облако, такой «игнор» со временем оборачивается внезапным исчерпанием свободного места в локальной файловой системе хранилища (datastore) гипервизора. Причиной может быть большое количество снэпшотов ВМ, использование тонких дисков у ВМ с конечным суммарным объемом, превышающим размер хранилища и т. д.
Мониторинг проинформировал бы о приближении критической ситуации, а не допустить всегда лучше, чем исправлять. В итоге у админов без должного опыта работы с инструментами виртуализации могут возникнуть серьезные проблемы с выяснением причин кризисной ситуации и ее исправлением.
Не стоит считать себя умнее машины, равно как и полагаться на ее возможности полностью – мониторинг сильно упрощает задачу управления сложным организмом ИТ-инфраструктуры.
7. Игнорирование отчетов об уязвимостях
Если инфраструктура клиента подключена к системе сканирования на уязвимости, то он на регулярной основе будет получать отчеты об обнаруженных проблемах. Игнорируя такие отчеты, можно оставить свою систему в уязвимом состоянии. Например, система может обнаружить отсутствие должного уровня защиты приложений в веб-среде. Согласно же отчету Verizon Data Breach за 2020 год, число атак на веб-приложения увеличилось за год более чем в два раза.
На среднестатистическом сайте работают десятки программных инструментов, а бизнес-приложения могут быть сотканы из сложной коллекции различных инструментов, которые подключаются ко множеству веб-серверов и служб.
Для серверов приложений общего назначения рассмотрите возможность использования брандмауэра. Если вы используете MS Azure или Office 365, обратите внимание на возможности Defender Application Guard.
Определенные проблемы могут возникнуть из-за открытых портов и отсутствия контроля за удаленным доступом.
Большинство облачных серверов имеют различные способы удаленного подключения, такие как RDP, SSH и веб-консоли. Все они могут быть скомпрометированы с помощью утечки учетных данных, плохих паролей или незащищенных портов. Отключите все ненужные и «древние» порты типа FTP прямо сейчас – это существенно сократит площадь возможной атаки. Отслеживайте все сетевые каналы доступа к своим ресурсам и блокируйте их.
8. Отсутствие журнала событий
Множество ИБ-инцидентов с облаками происходит из-за плохих практик ведения журналов событий.
Если вы не можете вспомнить, когда последний раз просматривали журналы событий – это может быть проблемой, особенно для облачных серверов, поскольку они могут разрастаться и быть не полностью на виду у ответственных специалистов.
Инструменты контроля логов, например в AWS (Amazon Web Services) это сервис CloudTrail, помогут обеспечить лучшую видимость всех облачных ресурсов и событий в них в реальном времени.
Кроме того, следует включить регистрацию событий для изменений в конфигурации учетных записей, создания новых пользователей, неудачных попыток аутентификации и т. д.
9. Нарушения заповедей бэкапа
В рамках задач резервного копирования или бэкапа также можно отметить несколько типичных ошибок, которые приводят к неприятным последствиям.
Например, клиент самостоятельно настраивает сценарии резервного копирования и не находит лучшего решения, чем складировать бэкапы систем на тех же ВМ, где размещены активные ресурсы.
Таким образом, нарушается главное правило бэкапа – «3,2,1» – у всех критически важных данных и систем должно быть три копии, на двух разных физических носителях, и как минимум одна из них должна храниться в другой локации.
При подходе «грузим бэкапы на ВМ» – любой сбой в работе инфраструктуры может обернуться полной и долговременной остановкой бизнес-процесса, который был завязан на конкретной машине. Вероятность же безвозвратной потери важных данных при таком сценарии очень высока.
10. Незащищенные контейнеры с данными
Различные мониторинги кибербезопасности буквально на каждой неделе обнаруживают данные в контейнерах в свободном доступе, в том числе на открытых облачных серверах. Они нередко содержат конфиденциальную информацию о клиентах компаний.
Такая безалаберность свойственна абсолютно всем компаниям, вне зависимости от масштабов деятельности и статуса. Ситуация настолько запущена, что подобного рода провал недавно был зафиксирован у компании SSL247, которая занимается как раз безопасностью.
Контейнеры – популярный и очень удобный инструмент облачной разработки, однако программисты и проект-менеджеры нередко склонны проявлять небрежность при работе с ними и упускают из внимания вопросы безопасности.
Регулярно проверяйте собственный домен с помощью инструментов обнаружения подобных уязвимостей, таких как Shodan.io, BinaryEdge.io или встроенных возможностей Docker, а также нативных инструментов облачных платформ.
© 2023 Linx
