Зависимость

Кому должны принадлежать облачные аккаунты, домен и данные продакшена?

Доступ — это не владение. В любой обычный день разница незаметна, и решающей она становится ровно в один день.

Короткий ответ

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

#Доступ — это не владение

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

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

#Что обязано быть вашим

По порядку. Если вы сделаете только первую группу, вы уберёте категорию риска, которую нельзя отменить деньгами.

Группа один — их потеря останавливает продукт

Займитесь всем из этой группы раньше всего остального на странице.

  • Регистрация домена Потерять домен — значит потерять продукт, почту и каждую интеграцию, которая на него резолвится. Обходного пути нет.
  • Управление DNS Держится отдельно от регистрации, часто вообще в другом месте.
  • Облачный аккаунт или организация Субаккаунт внутри организации подрядчика — не ваш, сколько бы доступа у вас ни было.
  • Продакшен-база и её бэкапы Включая место, куда пишутся бэкапы: часто это снова другой аккаунт.

Группа два — их потеря стоит денег и месяцев

  • Организация с репозиторием, вместе с историей
  • CI/CD и хранящиеся внутри него секреты
  • Аккаунт платёжного провайдера, включая банковские реквизиты для выплат
  • Почта и транзакционные сообщения, с доменом отправки, аутентифицированным в вашем DNS
  • Аккаунты издателя в магазинах приложений, если есть мобильный продукт
  • Трекер ошибок, мониторинг и аналитика

Группа три — то, что никто не проверяет

  • Почта и телефон восстановления у каждого аккаунта из групп один и два Аккаунт компании с личным ящиком восстановления — не аккаунт компании.
  • Платёжные отношения по каждому сервису — кому приходит счёт
  • Любой аккаунт, заведённый на личный адрес «просто чтобы начать»
  • TLS-сертификаты и всё, что продлевается автоматически
  • Сам почтовый ящик компании — и кто может его сбросить

#Настоящий ключ — адрес восстановления

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

Допустим, вы сделали всё правильно: облачный аккаунт оформлен на компанию, счета идут на карту компании, и двое ваших людей — администраторы. А почта восстановления у него — marek@ на домене подрядчика, потому что Марек заводил всё это в 2022-м.

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

Поэтому: пройдите по группе один и группе два и проверьте контакты восстановления у каждого. Почта восстановления — на ящик компании, до которого дотягивается больше одного человека; телефон — корпоративный, а не личный мобильный. Это час кликанья и самый ценный час на этой странице.

#Как их переносить

  1. Сначала опись, ничего не меняем

    По каждому аккаунту: на кого оформлен, кому выставляют счёт и какие контакты восстановления. Бо́льшую часть этого вы установите сами, просто посмотрев, никого не спрашивая.

  2. Заведите нужные вам корпоративные личности

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

  3. Перенесите регистрации

    Сначала домен. У переносов между регистраторами процедура измеряется днями, иногда с периодом блокировки, и им нужно содействие того, кто держит домен сейчас.

    Именно поэтому это делают до того, как отношения заканчиваются, а не после.

  4. Переведите облачную организацию

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

  5. Переведите оплату на компанию

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

  6. Исправьте контакты восстановления и проверьте

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

  7. И только потом трогайте доступы

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

#Как поднять тему без ссоры

Работает рамка непрерывности, а не аудита: «нам нужно уметь отвечать на эти вопросы инвестору, покупателю или страховщику». Это правда, это не про того, кого вы спрашиваете, и срок задаёте не вы.

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

#Как сделать правильно с самого начала

Если вы заводите новый продукт или нанимаете нового подрядчика, четыре правила снимают почти всё это навсегда:

  1. Каждый аккаунт заводит компания. Подрядчика в него приглашают. Никогда не наоборот, насколько бы медленнее это ни было в первый день.
  2. У каждого аккаунта корпоративный ящик, до которого дотягивается больше одного человека.
  3. Каждый сервис оплачивается компанией напрямую, а не перевыставляется подрядчиком.
  4. Так написано в договоре — аккаунты остаются за компанией, и любой аккаунт, заведённый в ходе работ, заводится на компанию.

#Что идёт не так

Считать админский доступ владением.

Вместо этого Спросите, кто может отобрать у вас доступ и кому достался бы аккаунт, если бы подрядчик прекратил работу. Эти два вопроса всё решают.

Починить аккаунт и оставить адрес восстановления.

Вместо этого Проверьте почту и телефон восстановления у каждого аккаунта, потерю которого вы не потянете. Это мера, которая перебивает все остальные.

Отзывать доступ до подтверждения владения.

Вместо этого Установить, перенести, создать свой путь входа, проверить — и только потом отзывать. Всегда в этом порядке.

Поднимать тему только когда отношения заканчиваются.

Вместо этого Сделайте это в обычный вторник, в рамке непрерывности. Тогда это пятиминутный разговор, а потом — переговоры.

Один человек в компании держит всё.

Вместо этого Вы не решили проблему, а только переставили её. Двое — и корпоративные ящики вместо личных.

#Чего это не покрывает

Чего это не делает

  • Владение интеллектуальной собственностью на код: это вопрос договора, и он переезжает отдельно от аккаунтов.
  • Обязанности по защите данных: они не переходят просто оттого, что перешёл аккаунт.
  • Механику конкретного провайдера. У каждого своя процедура переноса и свои задержки; спрашивайте провайдера, а не подрядчика.
  • Что делать, если подрядчик отказывается. Это коммерческий и юридический вопрос, а единственный технический ответ — держать независимую копию данных.

Проверьте всё это за десять минут.

Проверка зависимости от агентства проходит по владению, поставке, внешним аккаунтам, восстановлению и условиям договора — по одному вопросу за раз. Без аккаунта, без почты, ничего не отправляется.

Открыть проверку зависимости Составить карту зависимостей системы