10 типичных ошибок переезда: как не обнулить пользу облака после миграции

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

Сам по себе переезд в облако провайдера не означает автоматического переноса всего объема ответственности на службы поддержки оператора. Каждый раз в рамках проекта миграции нужно уточнять, делает ли по умолчанию провайдер бэкап данных клиентов, есть ли у него защита виртуальных машин (ВМ) от вирусов и DDoS-атак.

По умолчанию в облаках провайдеров не всегда реализуется привычный набор инструментов мониторинга параметров по отдельным ВМ. Необходимо проверять и соответствие инфраструктуры стандартам и законам: различные сертификации ISO, PCI DSS, выполнение требований 152-ФЗ и т. д.

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

Стандартная история: администратор создает одну учетную запись (УЗ) для работы с консолью управления ИТ-ландшафтом, включая облака – так называемый root-доступ. И далее работает со всем объем задач по ИТ инфраструктуре через нее. Удобно, просто, логично.

Но то, что удобно админам, удобно и хакерам: взломал всего одну учетку с root-правами, и делай с ИТ-системами и данными компании что хочешь. Поэтому root-УЗ как модель управления инфраструктурой нужно оставить в прошлом.

Если и использовать ее, то только для создания обычных УЗ ответственных специалистов для работы с системой. Root-прав у таких записей не будет, а все необходимые настройки и процессы для поддержки ИТ-инфраструктуры можно выполнять в полном объеме.

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

Например, все бизнес-критичные УЗ следует защитить многофакторной аутентификацией (MFA), а пользователям уровня Administrator необходимо отключить удаленный доступ по SSH/RDP.

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

К чему это приводит? Если пароль прежний, и после первой настройки ВМ через панель в облаке провайдера администратор забывает разлогиниться из консолей ВМ, то при перехвате пароля злоумышленники могут получить доступ к системам и данным компании.

Такой сценарий еще опаснее, так как уязвимость пароля проще обнаруживается сканированием сети. Если ВМ имеет «белый» IP-адрес, нет защиты NAT и Firewall, а пароль – слабый, то такая ВМ видна хакерам и является легкой мишенью. Ее взлом – вопрос времени.

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

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

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

Управление обновлениями и патчами серверного софта – отдельный момент управления инфраструктурой в облаках.

То же самое касается обновления шаблонов ВМ. Часто администраторы разворачивают инфраструктуру в облаке, пользуясь так называемым золотым образом или шаблоном ВМ, что экономит массу времени.

Однако развернутые по шаблону за считанные минуты ВМ также быстро и взламываются: достаточно найти уязвимость в одной ВМ, чтобы получить доступ ко всем по аналогии. Такие риски стремительно возрастают, если шаблон не обновляется, а развернутые по нему ВМ не патчатся сразу после запуска.

Выход: регулярное обновление шаблонов.

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

Например, внезапно может закончиться свободное место в локальной файловой системе хранилища (datastore) гипервизора. Причина – большое количество снэпшотов ВМ, использование тонких дисков с конечным суммарным объемом, превышающим размер хранилища и т. д.

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

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

Журналы ИБ-событий также нужно изучать: инструменты контроля логов помогут обеспечить лучшую видимость всех облачных ресурсов и событий в них в реальном времени.

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

Резервное копирование или бэкап при неправильном подходе также могут привести к проблемам. Например, если размещать бэкапы систем на тех же ВМ, где находятся основные ИТ-системы, то нарушится главное правило бэкапа – «3,2,1» (три копии критически важных систем и данных, на двух разных физических носителях, как минимум одна из них хранится в другой локации).

Если размещать бэкапы на ВМ, то любой сбой чреват остановкой бизнес-процесса, который был завязан на конкретной машине с высокой вероятностью полной потери важных данных.

ИБ-аспект работы с контейнерами нередко упускается из виду. Результат: очень часто различные чувствительные данные обнаруживаются в контейнерах в свободном доступе, в том числе на облачных серверах.

Разработка в облаке должна контролироваться с точки зрения ИБ-составляющей: в этом помогут, к примеру, такие инструменты уязвимостей, как Shodan.io, BinaryEdge.io или встроенные возможности Docker.