Евгений Макарьин
Руководитель группы разработки продуктов и решений Linxdatacenter
09.07.2021
3 мин

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

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

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

Другие новости и публикации
Новость
05.11.2024
Linx Cloud запустил сервис управляемых баз данных в облаке
Вас также могут заинтересовать
Linx NGFW
IS-18.png
Виртуальный межсетевой экран следующего поколения для ком...
PrivateCloud
Linxcloud
Готовая платформа для надежной работы бизнес-приложений
Migration
Migration-to-cloud-04-02-1024x576
Перенос ИТ-ресурсов в облако Linx Cloud из других облачны...
Nwtwork own PC
Разместите свое оборудование в дата-центрах с высоким уро...
Backup
Backup copy
Автоматизированное управление резервными копиями виртуаль...
Outsourcing
Remote work
Аудит, модернизация и оптимизация ваших серверных мощностей
Network
Remote work
Обеспечьте отказоустойчивость и бесперебойную работу сети
Linx DRaaS
DraaS-023
Облачный сервис для аварийного восстановления ИТ-инфрастр...
Linx Private Cloud
Linxcloud
Готовая платформа для надежной работы бизнес-приложений
IaaS
Iaas-02 copy
Отказоустойчивая и масштабируемая ИТ-инфраструктура для с...
Что вас интересует?
Получить промокод
остались вопросы?

Закажите консультацию специалиста

заказать тест-драйв
Получить демо-доступ

Спасибо за ваш запрос, мы свяжемся с вами в ближайшее время!