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

Топ-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, а также нативных инструментов облачных платформ.

Другие новости и публикации

Статья
09.08.2022
ИБ в условиях дефицита: стратегия большого перехода
Новость
01.08.2022
Linxdatacenter – в топ-10 крупнейших поставщиков услуг ЦОД
Новость
25.07.2022
Linxdatacenter запускает собственные PaaS-инструменты
Новость
20.07.2022
Петербургское облако Linxdatacenter прошло аттестацию по ...
Статья
30.06.2022
Как мы оптимизировали управление ЦОДами клиента
Новость
27.06.2022
Linxdatacenter: рынок российских облаков вырастет в 2022 ...
Новость
26.05.2022
Анна Мальми назначена региональным директором Linxdatacen...
Статья
20.05.2022
Облачный край: что происходит на российском рынке
Новость
13.05.2022
Новым генеральным директором Linxdatacenter назначен Андр...
Статья
03.05.2022
Блок на моноблок: модульная ИБП-революция в ЦОДах

Вас также могут заинтересовать

Linx Outsourcing
Аудит, модернизация и оптимизация ваших серверных мощностей
Подробнее
Аутсорсинг управления дата-центром
Linx Network
Обеспечьте отказоустойчивость и бесперебойную работу сети
Подробнее
Сетевые услуги
Linx DraaS
Аварийное восстановление ИТ-инфраструктуры. Защитите ИТ-системы уже сегодня!
Подробнее
Аварийное восстановление DRaaS

Напишите нам

Как мы оптимизировали управление ЦОДами клиента

Дата-центр – комплексный ИТ- и инженерный объект, требующий профессионализма на всех уровнях управления: от руководителей до технических специалистов и исполнителей эксплуатационных работ. Рассказываем, как мы помогли клиенту навести порядок в операционном управлении в корпоративных ЦОДах.
 

Тарас Чирков, руководитель ЦОД Linxdatacenter в Санкт-Петербурге 

Константин Нагорный, главный инженер ЦОД Linxdatacenter в Санкт-Петербурге 

Дата-центр – комплексный ИТ- и инженерный объект, требующий профессионализма на всех уровнях управления: от руководителей до технических специалистов и исполнителей эксплуатационных работ. Рассказываем, как мы помогли клиенту навести порядок в операционном управлении в корпоративных ЦОДах.  

В главной роли – управление 

Самое современное и дорогое ИТ-оборудование не принесет ожидаемой экономической пользы, если не будут выстроены правильные процессы эксплуатации инженерных систем ЦОДа, где оно располагается.  

Роль надежных и производительных дата-центров в современной экономике постоянно растет вместе с требованиями к их бесперебойной работе. Однако на этом направлении существует большая системная проблема.  

Высокий уровень «аптайма» – безаварийной работы дата-центра без простоев – очень сильно зависит от команды инженеров, которая занимается управлением площадки. А единой формализованной школы управления ЦОДами не существует.  

Нет какого-то сводного канона с правилами, применимыми для любого дата-центра. Есть стандарты международной отраслевой организации Uptime Institute, но они устанавливают рамки и вектор развития, к каждому конкретному дата-центру они будут применяться по-разному.  

В масштабах страны  

На практике в России ситуация с эксплуатацией ЦОДов выглядит так.  

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

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

Наконец, государственные ведомственные ЦОДы – в этом отношении они часто представляют собой неизвестную территорию в силу закрытости. Международный аудит таких объектов по понятным причинам невозможен. Российские госстандарты только разрабатываются.  

Все это выливается в ситуацию «кто во что горазд». «Разношерстный» состав команд эксплуатации из специалистов с разным бэкграундом, различные подходы к организации корпоративной архитектуры, взгляды и требования в отношении ИТ-департаментов.  

Факторов, приводящих к такому положению дел, много, один из главных – отсутствие систематизированной документации по выстраиванию эксплуатационных процессов. Есть пара вводных статей Uptime Institute, которые дают представление о проблеме и путях ее преодоления. Но дальше необходимо выстраивать систему своими силами. А на это ресурсов и компетенций хватит далеко не у каждого бизнеса.  

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

Кейс: через тернии к относительному порядку 

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

Компания недавно прошла аудит головного офиса и получила список несоответствий корпоративным стандартам с предписанием их устранить. Для этого в качестве консультанта привлекли нас как носителя отраслевых компетенций: мы развиваем собственную систему управления ЦОДами и ведем просветительскую работу о роли качества эксплуатационных процессов уже несколько лет.  

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

И здесь началось самое интересное.  

Познай себя 

Чтобы оценить уровень работы ЦОДов с точки зрения соответствия стандартам, нужно знать точные требования бизнеса к ИТ-системам: каков уровень внутренних SLA, допустимый период простоя оборудования и т.д.  

Сразу же выяснилось – ИТ-департамент не знает, что именно хочет бизнес. Не было внутренних критериев качества сервиса, не было и понимания логики устройства собственной инфраструктуры.  

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

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

Когда было достигнуто понимание архитектуры ИТ-систем, команда смогла суммировать требования к службе эксплуатации, подрядчикам и к уровню надежности оборудования.  

Улучшения в процессе 

Наши специалисты выезжали на площадки для оценки инфраструктуры, читали имеющуюся документацию, проверяли уровень соответствия проектов ЦОДов фактической реализации.  

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

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

Однако правильная оптимизация управления «инженеркой» ЦОДа предполагает выполнение задачи научить людей правильно оценивать процессы и писать под них уникальную документацию исходя из специфики конкретного объекта.  

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

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

Далее последовал этап первичной поддержки работ по обновленным регламентам, который в удаленном формате продолжался один год. Затем мы перешли к тренингам и учениям – единственный путь закрепления нового материала на практике.  

Что сделано 

В процессе работ нам удалось решить несколько серьезных вопросов.  

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

Принцип «просто найти, просто понять, легко запомнить» дополнился тем, что новая информация привязывается к старому опыту и знаниям сотрудников. 

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

Но нас удивило легкомысленное отношение компании к своей ИТ-инфраструктуре: от отсутствия резервирования критичных систем до хаоса в структуре и управлении.  

За 1,5 года процессы управления инженерными системами были прокачаны до уровня, который позволил специалистам компании успешно отчитаться «за качество» перед аудиторами из головного офиса.  

При поддержке темпов развития эксплуатационной составляющей компания сможет самостоятельно пройти любую существую сертификацию ЦОДов от ведущих международных агентств.  

Выводы 

В целом перспективы консалтинга в сфере операционного управления дата-центрами, по нашему мнению, самые яркие.  

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

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

Государственные проекты в сфере дата-центров также становятся более актуальны сейчас и требуют повышенного внимания с точки зрения эксплуатации: сфера государственных ИТ-систем растет. Здесь также потребуется разработка и ввод системы стандартизации и сертификации площадок.  

Когда требования к государственным ЦОДам в РФ на уровне законодательного акта будут сведены в стандарт, его можно будет применять и для коммерческих дата-центров, в том числе и для размещения государственных ИТ-ресурсов.  

Работы по этому направлению ведутся, мы участвуем в этом процессе в рамках консультаций с Минцифры и наращивая компетенции по преподаванию на курсах по эксплуатации дата-центров в АНО ЦОД. Опыта по таким задачам в России не много, и мы считаем, что должны им делиться с коллегами и клиентами. 

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

БЭСТ, оператор системы денежных переводов и платежей.

Бизнес-вызов

Компания столкнулась с проблемой постоянного флага BGP-сессии с оборудованием Linxdatacenter. После изучения проблемы стало ясно, что на один из хостов в его сети происходила DDoS-атака.

Из-за распределенного характера атаки отфильтровать трафик было невозможно. Инженеры предложили решение, связанное с сокрытием хоста от внешней сети, но этот вариант не подходил заказчику. Атака прекратилась после внесения изменений в конфигурацию сервера, однако возобновилась на следующий день. Ее мощность достигла 5,5 Гбит/с, из-за чего перегружались «стыки» с интернет-провайдерами, что сказывалось на других пользователях облака Linxdatacenter. Чтобы обеспечить стабильную работу, было решено обратиться к надежному поставщику защиты от DDoS.

Решение

Чтобы обеспечить непрерывную доступность ресурсов, размещенных в облаке Linxdatacenter, весь трафик клиента был направлен через систему antiDDoS от StormWall. Атаку удалось погасить в течение получаса. Для предотвращения дальнейших кибератак все соединения сервисов клиента с интернетом были организованы через сеть StormWall.

Клиент:

БЭСТ, оператор системы денежных переводов и платежей.

Бизнес-вызов

Компания столкнулась с проблемой постоянного флага BGP-сессии с оборудованием Linxdatacenter. После изучения проблемы стало ясно, что на один из хостов в его сети происходила DDoS-атака.

Из-за распределенного характера атаки отфильтровать трафик было невозможно. Инженеры предложили решение, связанное с сокрытием хоста от внешней сети, но этот вариант не подходил заказчику. Атака прекратилась после внесения изменений в конфигурацию сервера, однако возобновилась на следующий день. Ее мощность достигла 5,5 Гбит/с, из-за чего перегружались «стыки» с интернет-провайдерами, что сказывалось на других пользователях облака Linxdatacenter. Чтобы обеспечить стабильную работу, было решено обратиться к надежному поставщику защиты от DDoS.

Решение

Чтобы обеспечить непрерывную доступность ресурсов, размещенных в облаке Linxdatacenter, весь трафик клиента был направлен через систему antiDDoS от StormWall. Атаку удалось погасить в течение получаса. Для предотвращения дальнейших кибератак все соединения сервисов клиента с интернетом были организованы через сеть StormWall.

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