Как мы перевели целую организацию AWS в новую, и никто этого не заметил.


Справочная информация

Обычно при работе с AWS вы либо работаете с существующей организацией AWS, в которой уже есть защитные механизмы и службы, либо начинаете с нуля и создаете новую организацию. Последнее, однако, встречается довольно редко, и оказаться в ситуации, когда вам нужно самостоятельно устанавливать эти вещи, — это то, что даже такие консультанты, как я, делают редко. Однако еще более редким явлением является перенос всех учетных записей из одной организации или MSP в другую. У Amazon есть отличная документация о том, как выполнить некоторые из этих шагов, но все они, как правило, относятся к отдельным действиям, таким как настройка новой организации, а не к подобному перемещению.

Так как же происходит этот процесс, и как вам следует переходить от одного MSP к другому?

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

Почему мы делаем эту миграцию?

Сначала немного предыстории о том, зачем мы вообще занимаемся этим процессом.

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

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

Подготовительная работа

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

  • В нашем случае MSP отвечал за учетные записи, устанавливал корневую электронную почту и MFA. Это означало, что из-за того, как работают учетные записи AWS, нам нужно было создать уникальные учетные записи электронной почты (или псевдонимы) для каждой учетной записи, которой мы владели. Это не является большой проблемой, но если вы используете Office 365, каждая учетная запись может иметь только очень ограниченное количество псевдонимов, что означает, что в итоге мы получили огромное количество почтовых учетных записей, которыми кто-то должен управлять и следить за ними.
  • MFA нужно удалить, а затем снова применить. Для одной учетной записи? Ничего страшного. Для 50+ учетных записей это быстро надоедает. Вам также необходимо создать систему для отслеживания устройств MFA (или виртуального MFA), а также того, какое устройство принадлежит той или иной учетной записи — затем вам необходимо защитить эти устройства, чтобы никто, кто не должен иметь к ним доступ, не имел его.
  • ** На самом деле вам нужно отправить PDF-документ в AWS, где вы должны подать заявку на миграцию.** Это занимает время. Сначала вам нужно связаться со службой поддержки AWS, которая отправит вам PDF-документ, который должен быть подписан действительной подписью как уходящего MSP, так и нового владельца, а затем отправлен обратно в AWS. После отправки потребуется 2-4 недели на обработку. Это шаг, о котором многие MSP не знают, и о котором крайне важно не забыть…
  • В большинстве случаев, если у уходящего MSP были установлены политики безопасности AWS Security Hub, Config и т.д., они, скорее всего, удалят их до переезда. Это означает, что вам необходимо убедиться, что у вас есть план того, как решать вопросы безопасности в новой организации. Это важная задача!
  • Кроме того, необходимо учесть соображения, связанные с выставлением счетов; консультант по решениям AWS предоставит конкретные детали, но рекомендуется проводить миграцию в последний день или в первый день месяца.

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

Миграция

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

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

В среднем, на перенос каждой учетной записи уходило от 5 до 20 минут, в зависимости от того, сколько политик было применено к учетной записи, и процесс был невероятно гладким. Самым неприятным моментом было повторное применение MFA, что не очень приятно при работе с таким количеством учетных записей.

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

После миграции

После завершения основной миграции следующим шагом стало создание и перестройка новых SCP, AWS Control Tower и Guardrails в соответствии со стандартами новой организации.

Хотя это довольно гладкий и простой процесс, мы обнаружили одно серьезное препятствие, которое довольно сильно раздражало. AWS Config использует «Каналы доставки» и «Записывающие устройства конфигурации» для своей работы, но не удаляет их автоматически при удалении Config. Вам нужно вручную удалить их. Ничего сложного, верно…? За исключением того, что они применяются к каждому региону, в котором включен AWS Config, и могут быть удалены только через AWS CLI или SDK… «Ничего страшного», скажете вы, AWS Config может просто перезаписать существующие? Нет. Их нужно удалить. По одному. В каждом регионе. Обратите внимание, вам нужно удалить только стандартные, если у вас есть собственные пользовательские, они должны быть в порядке.

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

Проверка наличия каналов и рекордеров для учетной записи

aws configservice describe-configuration-recorders
aws configservice describe-delivery-channels --region eu-north-1
Войдите в полноэкранный режим Выход из полноэкранного режима

Удаление потенциальных объектов — обратите внимание, что это нужно сделать для КАЖДОГО региона:

aws configservice delete-configuration-recorder --configuration-recorder-name default --region eu-north-1
aws configservice delete-delivery-channel --delivery-channel-name default --region eu-north-1
Войти в полноэкранный режим Выйти из полноэкранного режима

После удаления каждого регистратора и канала доставки вы можете снова зарегистрировать учетную запись в AWS Config и Control Tower!

Заключение

Миграция всей организации AWS от одного MSP к другому занимает много времени. Это не обязательно физическая работа, но много ожидания завершения каждого этапа процесса, а их очень много.

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

Я настоятельно рекомендую обратиться к архитектору решений AWS до начала миграции, чтобы он мог проконтролировать процесс и убедиться, что все пройдет гладко, потому что существует множество шагов, которые можно испортить, что может привести к потенциальным проблемам. К счастью, в большинстве случаев все должно быть довольно просто!

Оцените статью
Procodings.ru
Добавить комментарий