{"id":13655,"url":"\/distributions\/13655\/click?bit=1&hash=17a0e55a63bd0960d466baff29be5a6a830a9ecab9cb1a490f31f5267724efbf","title":"\u041a\u0430\u043a \u043e\u0442\u043b\u0438\u0447\u0438\u0442\u044c \u0444\u0435\u0440\u043c\u0435\u0440\u0441\u043a\u0438\u0435 \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u044b \u043e\u0442 \u00ab\u043f\u0441\u0435\u0432\u0434\u043e\u0444\u0435\u0440\u043c\u0435\u0440\u0441\u043a\u0438\u0445\u00bb?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"43a94a7a-c975-5627-8453-c0ce96e38181","isPaidAndBannersEnabled":false}
Сервисы
Linxdatacenter

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

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

Ошибка 1: безграничная ответственность

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

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

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

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

Ошибка 2: учетка с root-правами

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

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

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

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

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

Ошибка 3: неуправляемые пароли

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

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

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

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

Ошибка 4: необновляемое ПО

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

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

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

Ошибка 5: старые шаблоны

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

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

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

Ошибка 6: игнорирование мониторинга

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

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

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

Ошибка 7: отчеты об уязвимостях никто не читает

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

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

Ошибка 8: нет журнала событий

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

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

Ошибка 9: плохой бэкап

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

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

Ошибка 10: открытые контейнеры

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

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

0
23 комментария
Написать комментарий...
Маргарита Крысина

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

Ответить
Развернуть ветку
Linxdatacenter
Автор

Хорошая практика - назначать в провайдере человека, который будет хорошо разбираться в инфраструктуре заказчика, понимать его бизнес- и технические потребности, а также грамотно соотносить их с возможностями и особенностями провайдера. Так называемый Technical account manager.

Ответить
Развернуть ветку
Vitaly Kutsenko

Но это тоже отдельные деньги. А всё экономить хотят

Ответить
Развернуть ветку
Oleg Gorbatov

А если это сделать памятной для клиента?
Или никто не будет читать до момента грома?

Ответить
Развернуть ветку
Linxdatacenter
Автор

Кстати хорошая идея.
Большинство тезисов до клиента доносим в разных памятках и документах. Возможно стоит свести в один.

Ответить
Развернуть ветку
Ася

Мне еще интересно, сколько "баллов" (ошибок)) в среднем набирает одна компания? Есть такие, кто отметился во всех сразу? :)

Ответить
Развернуть ветку
Linxdatacenter
Автор

По ощущениям 2-4.
10, к счастью, пока никто не набрал.

Ответить
Развернуть ветку
Ася

Я боялась худшего))

Ответить
Развернуть ветку
Анастасия Огнева

про пароли да, важная штука

Ответить
Развернуть ветку
Оксана Гришина

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

Ответить
Развернуть ветку
Linxdatacenter
Автор

Скорее завышенная ставка на импортозамещение)
Но статистику пока не собрали.

Ответить
Развернуть ветку
Denis Boytsov

Как вот так поучилось, что "некомпетентность" даже в топ-10 не попала? ))

Ответить
Развернуть ветку
Linxdatacenter
Автор

Потому что это не ошибка, а скорее причина большинства оных)

Ответить
Развернуть ветку
Aygul Shiryaeva

Помнить, что зона ответсвенности провайдера ограничена, и знать, как именно :)

Ответить
Развернуть ветку
Dennis Prochko

прям перепись ботов с женскими никами 🙈 KPI по комментам спустили что ли

Ответить
Развернуть ветку
Дмитрий Ветров

Изменился ли этот топ в свете произошедших на рынке перемен с начала года? Если да – почему, и каким образом?

Ответить
Развернуть ветку
Linxdatacenter
Автор

Ошибка с регулярными обновлениями стала не столь однозначна. Некоторые специалисты воспринимают это не как баг, а фичу)

Ответить
Развернуть ветку
Ольга Мельниченко

Здравствуйте)

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

Ответить
Развернуть ветку
Linxdatacenter
Автор

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

Ответить
Развернуть ветку
Светлана Корепанова

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

Ответить
Развернуть ветку
Linxdatacenter
Автор

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

Ответить
Развернуть ветку
Кубик Рубика

прочитал статью, очень интересно

Ответить
Развернуть ветку
Иван Петров

После 24 февраля надежность облаков превратилась в тыкву. Только кластер из выделенных серверов, разбросанных по разным геолокациям может давать хоть какую-то надежду не остаться у разбитого корыта. Строить что-то на вендор-лок инфраструктуре типа aws - верх безрассудства.

Ответить
Развернуть ветку
Читать все 23 комментария
null