Облачные сервисы в последние годы пользуются большой популярностью. Преимущества всем хорошо известны — это экономия на закупке и сопровождении оборудования, лицензиях, персонале и т.д. Если у нас разворачивается инфраструктура с нуля, то ситуация несколько проще. Мы можем сразу развернуть наши сервисы в облаках и дальше уже тестировать их работу. Конечно, здесь тоже можно столкнуться с различными трудностями, но по крайней мере при создании инфраструктуры с нуля нам не требуется выполнять миграцию.
Совсем другая история, когда у нас уже имеется некоторый набор сервисов, функционирующий на железе, и мы хотим перевести их в облака. Тогда всё становится значительно веселее, так как при миграции можно столкнуться с массой сюрпризов.
Для того, чтобы минимизировать количество таких сюрпризов, переход в облака необходимо выполнять постепенно, и в этом нам могут помочь правильные строительные блоки — cloud landing zone. На практике эти строительные блоки могут быть некоторой тестовой площадкой, в которой проходят проверку перемещаемые в облако сервисы перед развёртыванием в производственной среде. А могут быть просто отправной точкой для быстрого развёртывания рабочих нагрузок и приложений в облачной среде.
Что такое Cloud Landing Zone
Итак, давайте рассмотрим подробнее, что из себя представляет Cloud Landing Zone — это прежде всего изолированная среда, защищённая от внешних вмешательств. Также важно, чтобы данная среда была заранее определена и включала в себя все необходимые для надежного тестирования компоненты — например, сетевая топология и вспомогательные сервисы.
Среда разработана таким образом, чтобы быть масштабируемым, модульным и безопасным, позволяя облачным инженерам настраивать ресурсы в соответствии с потребностями своих организаций.
Далее мы посмотрим, как выполнить миграцию сервисов в облачную среду с помощью так называемой “теории трёх дней”.
Теория трёх дней
На самом деле, естественно, речь не идёт о том, как выполнить переход в облака за три дня. Вместо этого мы говорим о трёх этапах перехода в Landing Zone. Первый день относится к спецификации и проектированию сервисов в облаках, второй день — это разработка необходимых компонентов решения и развёртывание, и третий день — это собственно переход к эксплуатации и решение соответствующих вопросов. На представленном ниже рисунке эти дни нумеруются, начиная с нулевого.
Проектирование
Начнём с проектирования Cloud Landing Zone. Какие основные требования предъявляются к приложениям в облачной среде. Прежде всего, это требования безопасности. Нам необходимо, во-первых, обеспечить управление идентификацией и доступом, разграничение доступа к различным компонентам нашего приложения в облаке. Во вторых, нужно изолировать компоненты приложения и обеспечить их взаимодействие только по разрешённым портам и протоколам. В целом, подход к управлению обеспечения безопасности в облаке должен быть централизованным. То есть все политики и списки доступа должны управляться централизованно. Это позволит как увеличить общую защищённость приложения, так и упростить управление компонентами защиты.
Кроме того, неотъемлемой частью любой системы защиты является мониторинг событий безопасности. Необходимо собирать наиболее важные события информационной безопасности, такие как события удачного/неудачного входа в систему, изменения прав и т.д. И эти события не должны просто храниться где-то в логах — необходимо пересылать их для анализа в систему управления событиями безопасности SIEM.
Не стоит забывать и о соответствии требованиям регуляторов (ФЗ №152, ФЗ №187 и требования соответствующих приказов ФСТЭК). Лучше заложить соответствующие требования на этапе проектирования, чем потом, уже после развёртывания судорожно внедрять дополнительные средства защиты, пытаясь интегрировать их в существующую систему. Таким образом, вы можете обеспечить базовый уровень соответствия требованиям для нескольких клиентов или сред.
Продолжая тему безопасности, вспомним про требования к сети. Картинка ниже является кратким напоминанием типов облачных сервисов.
Как правило, для серьёзных сервисов у нас используется IaaS, то есть мы самостоятельно разворачиваем ОС и всё, что выше. При планировании миграции важно учитывать то, как накладывается требующаяся нам сетевая топологию на сетевую инфраструктуру облачного провайдера. Все ли сетевые сервисы и протоколы поддерживаются. Также необходимо продумать правильную сегментацию и составить списки доступа.
Клиентам нашего облачного приложения в зависимости от выполняемых ими функций необходимо назначить различные профили безопасности, например dev/staging/prod и т.д.
При проектировании не лишним будет продумать требования к аппаратным мощностям. Да, в облаках добавить память или CPU несколько проще, чем на живом железе, но при внедрении можно столкнуться с проблемой отсутствия нужных мощностей у провайдера (да, облачный провайдер мне не смогу предоставить 256 Гб ОЗУ).
И в целом, чем лучше мы проработаем архитектуру landing zone, тем меньше боли у нас будет на следующих этапах.
Развёртывание landing zone
После глубокой проработки требований мы переходим к развёртыванию. Конечно, определиться провайдером облачных услуг, на ресурсы которого мы будем приземлять свои сервисы, необходимо ещё на этапе проектирования. А на этапе внедрения мы должны уже разворачивать наши сервисы.
Долго размышлять на тему того, какой облачный провайдер лучше, мы не будем. На эту тему есть множество публикаций, например — на тему Landing zone в AWS или Microsoft. Так как с иностранными облаками в последнее время всё сложно, то лучше сразу ориентироваться на отечественные сервисы, благо их на рынке довольно много.
Если мы грамотно продумали изначальные требования к landing zone, то больших проблем при развёртывании быть не должно. Однако такое возможно только в идеальном мире. В реальности мы обязательно столкнёмся с сюрпризами. Поэтому, лучше всего использовать средства автоматизации развёртывания, например Terraform для развёртывания серверов и Ansible для распространения настроек.
Управление landing zone
Облачные среды и их использование никогда не бывают статичными. Это означает, что необходимо постоянно прилагать усилия для управления и эксплуатации базовых cloud landing zone. По мере расширения вашей landing zone вам придётся разворачивать в облаке дополнительные сервисы, также придётся заботиться о безопасности развёрнутых решений и планировать landing zone для новых сервисов.
Здесь важную роль играют те инструменты, которые предоставляет облачный провайдер для мониторинга состояния ваших виртуальных машин, функционал для выполнения резервного копирования, возможности по масштабированию и обеспечению отказоустойчивости.
И не забываем о мониторинге событий ИБ, межсетевом экранировании, анализе трафика и других защитных механизмах, которые используются на протяжении всего жизненного цикла ИТ-систем.
Заключение
В этой небольшой статье мы рассмотрели основные моменты, связанные с созданием Cloud Landing Zone. Грамотное создание такой среды позволяет сделать миграцию в облака менее болезненной.
Статья подготовлена в преддверии старта курса "Enterprise Architect".