Evgeny Makaryin
Products & Solutions Team Leader, Linxdatacenter
09.07.2021

Топ-10 ошибок компаний в облаке

«Переезд» в облако не избавляет компанию от соблюдения базовых требований по информационной безопасности. Более того, при определенных сценариях размещения в ЦОДе многие ИБ-проблемы ложатся на бизнес, а сервис-провайдер может лишь давать рекомендации, чтобы помочь избежать ошибок. Рассмотрим наиболее типичные из них

Топ-10 ошибок компаний в облаке

Evgeny Makaryin,
Products & Solutions Team Leader, Linxdatacenter

Максим Халькевич,
Руководитель группы цифровых сервисов и информационной безопасности Linxdatacenter

«Переезд» в облако не избавляет компанию от соблюдения базовых требований по информационной безопасности. Более того, при определенных сценариях размещения в ЦОДе многие ИБ-проблемы ложатся на бизнес, а сервис-провайдер может лишь давать рекомендации, чтобы помочь избежать ошибок. Рассмотрим наиболее типичные из них.

1. Непонимание границ ответственности.

Не так давно многие думали, что в облаках хранить и обрабатывать данные опасно. Сегодня встречается другая крайность: «мои данные в облаке, мне не о чем беспокоиться».

Нередко клиенты разных компаний полагают, что сервис-провайдер по умолчанию:

  • делает бэкап их данных,
  • защищает ВМ от вирусов,
  • защищает их инфраструктуру от DDoS атак,
  • ведет непрерывный и очень подробный мониторинг всех параметров по отдельным ВМ,
  • обеспечивает полное соответствие инфраструктуры клиента стандартам и законам (ISO, PCI DSS, 152-ФЗ и т. д.).

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

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

2. Работа из-под «root’а»

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

Если делиться со злоумышленниками нет желания, то лучше следовать простым правилам:

  • Учетную запись root использовать только для создания рабочих УЗ себе и коллегам.
  • Именно из-под этих рабочих УЗ стоит выполнять всю настройку и поддержку инфраструктуры.
  • У каждой рабочей УЗ должно быть ровно столько прав, сколько реально понадобится для выполнения рабочих задач. Если Иван Иванов работает только с частью заранее созданных ВМ, ему не нужен доступ к другим ВМ, управлению сетью и т. д.
  • Все УЗ необходимо делать именными и не допускать работу нескольких сотрудников из-под одного аккаунта.
  • Все бизнес-критичные УЗ также крайне желательно защитить многофакторной аутентификацией (MFA).
  • Если говорить об отдельных ВМ, то лучше отключить доступ по SSH/RDP пользователям root/Administrator/admin. Злоумышленнику будет гораздо сложнее подобрать реквизиты доступа, если и пароль сложный, и логин в стиле ivan.ivanov.

3. Отсутствие управления паролями

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

Часто клиент не меняет пароль от панели управления облака (vCloud Director), хотя в письме с реквизитами для доступа написано, что это необходимо сделать сразу после первого входа.

Нередко после изначальной настройки ВМ (виртуальных машин) через панель vCloud Director администратор забывает разлогиниться из консолей ВМ. В результате в сочетании с предыдущей ошибкой имеем ситуацию, когда тот, кто перехватил пароль от панели управления облака, может:

  • получить доступ к данным, хранящимся непосредственно на ВМ,
  • использовать ВМ по своему усмотрению, так как уже залогинен из-под root’а (с максимальными привилегиями).

Один из самых популярных сценариев является, пожалуй, и самым опасным, так как легко обнаруживается злоумышленниками. Администратор настраивает ВМ, присваивает ей белый 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, а также нативных инструментов облачных платформ.

News and publications

You may also be interested in

How can we help you?
Request Demo Access
client:

BEST, money transfer and payments operator

business challenge

The customer faced a technical issue with a persistent BGP session flag with Linxdatacenter hardware. We examined the problem and found out that one of customer’s hosts was under a DDoS attack.

Because of the distributed nature of the attack, traffic couldn’t be filtered effectively, and disconnecting the host from the external network wasn’t an option. The attack stopped after changes in the server configuration, but resumed the day after. A 5.5 Gbps attack overloaded the junctions with internet providers, affecting other Linx Cloud users. To mitigate the effects of the attack, we employed a dedicated DDoS protection service.

Solution

To ensure the continuous availability of resources hosted in Linx Cloud, we rerouted all the customer’s traffic through StormWall Anti-DDoS system. The attack was stopped within half an hour. To prevent future cyberattacks, we organized all connections to the customer’s resources through the StormWall network.

Thank you for your inquiry, we will get back to you shortly!