Зависимость от поставщика: что проверять в техническом аудите кроме кода

На странице моей услуги по подготовке к инвестициям и due diligence есть фраза: «Отдельная тема – насколько продукт самостоятелен: за интерфейсом иногда стоит чужой сервис по подписке». Эта статья её разворачивает: как проверять зависимость от поставщика при сделке. Код при сделке переходит вместе с репозиторием. Всё остальное, на чём держится продукт, лежит в аккаунтах у поставщиков: приложения в App Store и Google Play, облако, платёжный аккаунт, домен, ключи к ИИ-моделям. У каждого такого аккаунта есть владелец, и у каждого поставщика свои правила: можно ли аккаунт передать, сколько это займёт и что по дороге потеряется.

Клиентские истории я не публикую. Всё, что ниже сказано о правилах поставщиков, взято из их опубликованных документов и сверено 27 сентября 2026 года, ссылки в конце статьи. Правила меняются, поэтому перед сделкой их надо перечитать. Общий порядок технической проверки я разбирал в статье «Технологический due diligence для инвесторов», здесь речь только о поставщиках. Юридических заключений я не даю: я показываю, где в условиях поставщика написано про переуступку и смену владельца, а что это значит для конкретной сделки, решает юрист.

Код переходит, продукт нет

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

На странице услуги я описываю типичную неделю после подписания term sheet: «В среду выясняется, что подрядчик, писавший платёжный модуль, закрыл юрлицо два года назад, а сервисы оформлены на личные аккаунты основателей». Вторая половина этой фразы и есть тема статьи. Личный аккаунт основателя это не просто неаккуратность. У личных и организационных аккаунтов разные правила, и иногда личный аккаунт нельзя передать вообще, можно только вынести из него приложения в новый.

Два примера. В Google Play личный аккаунт, который зарабатывает на приложениях, пока не может сменить владельца напрямую: нужен новый аккаунт и перенос приложений. У Apple индивидуальный аккаунт разработчика перевести в организационный может только основатель или сооснователь компании, с номером D-U-N-S и, возможно, документами. Google к тому же советует завести для аккаунта разработчика отдельный Google-аккаунт вместо личного: если через тот же аккаунт идут Gmail и Google Payments, передача пароля открывает и их.

Реестр аккаунтов: с него начинается проверка

В списке материалов, которые я готовлю к проверке, есть строка «Реестр доступов и владельцев аккаунтов». По тому, как быстро компания его собирает, многое видно ещё до чтения кода.

Собирать реестр надо не по памяти команды, а по документам. На странице услуги это сформулировано так: «Технический due diligence начинается не с архитектуры, а с истории репозитория, счетов провайдеров и договоров с подрядчиками». Счета показывают, за что компания действительно платит и с чьей карты, а не то, что команда помнит.

Для каждого поставщика в реестре нужны ответы на восемь вопросов:

• на кого оформлен аккаунт: на юрлицо или на человека, и в какой стране;
• кто держит главную роль: Account Holder у Apple, владелец у Google Play, root у AWS, Owner у Stripe и GitHub;
• где второй фактор: на чьём телефоне или ключе;
• чья карта стоит в оплате;
• на какую почту приходят уведомления поставщика;
• что внутри: приложения, базы, домены, подписки клиентов, ключи;
• передаётся ли аккаунт и что при передаче теряется;
• какие сроки у передачи и можно ли их сжать.

Последние два вопроса самые трудоёмкие, и дальше речь о них, по поставщикам. Но сначала о почте, потому что её недооценивают сильнее всего.

Почта, на которую приходят предупреждения

Поставщики предупреждают о важном письмом, и письмо уходит на конкретный адрес. В Firebase уведомления о биллинге, юридических изменениях и закрытии функций по умолчанию часто получают только владельцы проекта. Это исправляется настройкой essential contacts, но её кто-то должен сделать.

В договоре OpenAI есть пункт, который стоит прочитать дважды. О существенном урезании функциональности сервис уведомляет письмом на почту аккаунта, а уведомление на эту почту по договору считается данным в момент отправки («deemed given when sent»). С получения уведомления у клиента пять рабочих дней, чтобы воспользоваться правом расторгнуть договор (для бета-функций этого права нет). Если почта аккаунта это ящик сотрудника, который давно ушёл, окно закроется, и никто об этом не узнает. У Anthropic общее правило обратное: уведомление действует только после получения. Но изменения условий и там вступают в силу через 30 дней после публикации, дошло письмо или нет.

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

App Store: приложение передаётся, история продаж нет

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

• начать и принять передачу может только Account Holder, по одному с каждой стороны, а Account Holder у аккаунта ровно один;
• получатель должен принять передачу в течение 60 дней, иначе она истекает;
• нельзя передать приложение, у которого нет ни одной вышедшей в App Store версии, и нельзя передавать во время проверки или в ожидании релиза;
• история продаж и выплат не переходит: получатель видит только транзакции после передачи, а продавец теряет доступ к аналитике приложения;
• сборки TestFlight и данные Xcode Cloud до передачи удаляют, бета-аудитория и история сборок не переходят;
• идентификатор мерчанта Apple Pay не переходит: платежи идут, пока действуют старые сертификаты, а к первому обновлению у получателя должен быть свой;
• профили подписи создаются заново в аккаунте получателя.

Отдельно про вход через Apple (Sign in with Apple). Если приложение им пользуется, продавец генерирует для каждого пользователя идентификатор переноса, а у получателя есть 60 дней после принятия, чтобы обменять их на свои. Если окно пропущено, Apple в техническом документе TN3159 описывает единственный выход: вернуть приложение исходной команде, заново подготовить миграцию и передать ещё раз. Отдельно от входа через Apple: общая связка ключей (keychain sharing) работает только до первого обновления, её группу пересоздают под Team ID получателя, и после обновления пользователи один раз входят заново.

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

Из своей практики. В статье про конвейер публикации в магазины я писал, что «один просроченный сертификат затрагивает каждый provisioning-профиль, который на него ссылается, во всех приложениях». Сертификаты распространения принадлежат команде, а не человеку. После передачи профили подписи создаются заново в аккаунте получателя, а ключи и сертификаты push и Apple Pay получатель заводит свои, когда истекают старые или выходит первое обновление. Это стоит заложить в план как работу, а не как формальность.

Google Play: заказы и отчёты остаются у продавца

У Google Play две разные процедуры: передача отдельного приложения в другой аккаунт и смена владельца всего аккаунта.

При передаче приложения заявку подаёт исходный аккаунт, получатель её одобряет, потом её проверяет поддержка Google, ответ обещают в течение двух рабочих дней. Понадобятся идентификаторы транзакций регистрационного взноса обоих аккаунтов, их ищут в почте по словам developer registration fee. С приложением переходят пользователи, статистика, отзывы, подписки, а также зарегистрированное имя пакета и привязанные к нему ключи в программе верификации разработчиков Android. Ключ подписи Play App Signing остаётся при приложении, а ключ, который продавец хранит сам, он передаёт отдельно. Не переходят:

• заказы, сделанные до передачи: вернуть за них деньги можно только из исходного аккаунта или через API;
• отчёты: массовые выгрузки, оценки продаж, доходы и выплаты. Google советует заранее скачать те, что понадобятся позже;
• тестовые группы и промоакции;
• связки с другими сервисами: Firebase перепривязывают, рекламные SDK обновляют.

Смена владельца всего аккаунта устроена иначе. Начинает её только текущий владелец, новый проходит проверку личности, и у каждой смены есть обязательный семидневный период ожидания. Если владелец недоступен, сменить его самостоятельно нельзя, только через поддержку. С 27 мая 2026 года Google прямо запретил передавать аккаунт через логин и пароль. При этом покупку компании Google называет законной причиной передачи: запрещены только неофициальные пути.

В соглашении Google Play с разработчиком есть фраза, которую стоит показать юристу: «If You experience a change of control, Google may, at its discretion, elect to immediately terminate this Agreement». То есть при смене контроля над компанией Google вправе немедленно расторгнуть договор. Как часто он этим пользуется, я не знаю, но пункт есть.

И ещё один вопрос из этого раздела: где лежит ключ подписи. По правилам Google, с 30 сентября 2026 года пакеты, не зарегистрированные в программе верификации разработчиков Android, удаляются из Play. Подходящие приложения на Play App Signing Google регистрирует автоматически, но в отдельных случаях пакет приходится регистрировать вручную или подавать запрос. Если же ключ подписи разработчик хранит сам и потерял его, зарегистрировать пакет не получится. Строка «где ключ и у кого копия» в реестре обязательна.

Firebase: без организации проект принадлежит людям

Проект Firebase это проект Google Cloud: права доступа, оплата и удаление у них общие. Отдельной кнопки «передать проект» нет, покупателя добавляют владельцем. Если проект создан вне организации Google Cloud, он принадлежит людям, а не компании. Заблокируют личный аккаунт единственного владельца, заблокируется и проект, поэтому Google советует держать больше одного владельца.

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

Push-уведомления на iOS через Firebase требуют ключа APNs, выпущенного в аккаунте Apple и загруженного в Firebase. Одна функция продукта держится на двух аккаунтах у двух поставщиков, и при передаче их надо двигать согласованно.

AWS: согласие дано заранее, но с условиями

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

На практике AWS публикует отдельные требования к передаче аккаунта и в них заранее даёт согласие, если выполнены все 11 условий. Среди них: нет задолженности, начисления на момент передачи ложатся на обе стороны, Enterprise Support снимается, соглашения AWS Artifact расторгаются и принимаются заново, а сама передача не служит обходу ценовых обязательств перед AWS (это AWS решает по своему усмотрению). Исключения: госструктуры, изолированные регионы и AWS India. Технически передача это смена почты и пароля root. У самостоятельного аккаунта почту root меняют только в консоли и только под самим root. У аккаунта в AWS Organizations её может сменить management-аккаунт организации, а при централизованном управлении root у такого аккаунта пароля root может вовсе не быть. Устройство MFA на root перед передачей советуют снять или заменить, иначе новый владелец может не войти.

Если аккаунт состоит в AWS Organizations, есть нюансы. С 19 ноября 2025 года аккаунт можно перенести напрямую в другую организацию. Отчёты уровня организации при этом не переезжают, теги аккаунта и организационных единиц и политики SCP воспроизводят в новой организации заново, а зарезервированные инстансы (Reserved Instances) и Savings Plans уходят вместе с аккаунтом. И главное для покупателя: роль OrganizationAccountAccessRole при выходе аккаунта из организации не удаляется. У прежнего владельца остаётся доступ, пока роль не удалят вручную.

Ещё две мелочи с последствиями. Промо-кредиты AWS нельзя передать, ими можно только делиться внутри одной организации. А если домен в Route 53 передали в аккаунт покупателя, но зона DNS осталась у продавца, сайт работает, только трафиком управляет тот, у кого зона. Документация прямо требует перенести зону или создать новую.

Google Cloud и Microsoft

В условиях Google Cloud переуступка без письменного согласия разрешена только аффилированному лицу, исключения для продажи бизнеса нет. О смене контроля клиент обязан письменно уведомить Google в течение 30 дней. Если у компании подписан отдельный офлайн-договор с Google, онлайн-условия не применяются, и читать надо его.

Перенос проекта в организацию покупателя, как уточняет документация Google, «is not a data transfer»: данные и сервисы остаются на месте и работают без простоя, меняется только родитель проекта. Но проект остаётся привязан к прежнему платёжному аккаунту, то есть к продавцу, пока его не перепривяжут отдельно. Унаследованные роли теряются, а вернуть проект из организации обратно в состояние «без организации» можно только через поддержку Google Cloud.

В типовом клиентском соглашении Microsoft (Microsoft Customer Agreement, редакция марта 2023 года) переуступка аффилированному лицу возможна с письменным уведомлением, любая другая требует письменного одобрения. У Microsoft есть и другие формы договоров, их надо читать отдельно. И строка, важная для продавца: переуступка не освобождает передающую сторону от обязательств по договору.

GitHub: репозиторий переходит, пакеты не все

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

Что не переходит или ломается:

• пакеты Container registry, npm, NuGet и RubyGems остаются у старого владельца, связь с репозиторием рвётся;
• GitHub Pages не перенаправляются на новый адрес;
• GitHub App и OAuth App передаются отдельно, в настройках разработчика;
• приглашение на передачу репозитория в личный аккаунт истекает через сутки.

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

У меня самого есть система, которая сознательно построена на GitHub: учёт серверов и телеметрия, где GitHub служит бэкендом. В статье о ней я записал ограничения: «Система завязана на доступность и продуктовые решения GitHub» и «Минуты Actions и лимиты API щедры для десятков серверов и беспощадны для тысяч». Такая запись и есть то, что проверяющий хочет увидеть: зависимость названа и оценена.

Stripe: клиенты копируются, подписки нет

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

Если покупатель из другой страны, всё сложнее. Страну аккаунта Stripe сменить нельзя. Сначала покупателю передают роль владельца старого аккаунта, потом он открывает новый аккаунт в своей стране и через поддержку просит скопировать данные. Копируются только клиенты и их платёжные методы. Платежи, счета, подписки, купоны, события и журналы не копируются: Stripe сам называет это копией, а не переносом. Подписки создают заново, а старый аккаунт Stripe советует не закрывать: история остаётся только в нём.

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

Домены: 60 дней после смены владельца

Среди проверок на странице услуги есть и такая: «оформлены ли домены и знаки на юридическое лицо, а не на основателя». Если домен оформлен на основателя, его придётся переоформить, и для общих доменов вроде .com и .net тут действует политика передачи ICANN.

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

В июне 2026 года совет ICANN принял рекомендации по пересмотру этой политики, но дата их вступления в силу не названа, и на 27 сентября 2026 года действует редакция с 60-дневной блокировкой. Если о домене идёт спор, например по процедуре UDRP, регистратор обязан отказать в смене владельца. Национальные домены вроде .ru или .ae живут по своим правилам, их я здесь не разбираю.

ИИ-API: ключи, лимиты и кредиты привязаны к организации

Это самая новая часть реестра и самая недооценённая. Продукты всё чаще зависят от API языковых моделей, а у этих аккаунтов своя механика:

• Ключи. OpenAI в договоре запрещает покупать, продавать и передавать API-ключи третьим лицам. У Anthropic ключ, созданный для рабочего пространства, к нему привязан и в другое не переносится, а персональный ключ перестаёт работать, когда человека удаляют из организации. Для общего использования Anthropic советует ключи сервисных аккаунтов.
• Уровни. Лимиты у обоих поставщиков зависят от истории организации: у OpenAI уровень растёт автоматически по мере оплаченных расходов, у Anthropic по истории использования и состоянию аккаунта. Если продукт переезжает в новую организацию покупателя, истории у неё нет. У Anthropic на стандартных уровнях есть месячный потолок расходов, и по его достижении API возвращает ошибку 429 до начала следующего месяца, если раньше не удастся получить повышение лимита.
• Особые условия. Режим без хранения данных (Zero Data Retention) у OpenAI доступен только после предварительного одобрения организации, после чего она включает его для себя или отдельных проектов. Новой организации одобрение придётся получать заново.
• Кредиты. Передавать кредиты нельзя ни у OpenAI, ни у Anthropic, купленные сгорают через год.

Договоры у этих поставщиков тоже разные. У OpenAI любая сторона может переуступить договор правопреемнику всего или почти всего бизнеса с письменным уведомлением минимум за 30 дней. У Anthropic клиент переуступает договор только с предварительного письменного согласия Anthropic, исключение для продажи бизнеса есть лишь у самой Anthropic.

В моём конвейере публикации мобильных приложений черновики переводов для магазинов генерирует Anthropic API, если настроен ключ ANTHROPIC_API_KEY. Функция маленькая, но в реестре она всё равно отдельная строка: чей это ключ, персональный или сервисного аккаунта, в какой организации.

Решения поставщика, о которых не спрашивают

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

• Anthropic обещает не меньше 60 дней уведомления до вывода публично выпущенной модели, и в последних случаях сроки близки к минимуму: о выводе Claude Opus 4.1 объявили 5 июня 2026 года, в Claude API отключили 5 августа;
• OpenAI обещает не меньше шести месяцев для моделей общего доступа, если безопасность или комплаенс не требуют спешки, а предварительные версии может вывести и за две недели. И выводит целые продукты: Assistants API объявили к закрытию 26 августа 2025 года и отключили ровно через год, Videos API объявили 24 марта 2026 года и отключили 24 сентября, без замены;
• новые цены у OpenAI вступают через 14 дней после публикации, у Anthropic через 30 дней или раньше, если клиент получил уведомление;
• в Azure статус существующего клиента для модели определяется на уровне подписки, и новая подписка даже в том же тенанте его не наследует: если покупатель переносит продукт в свою подписку, старая модель может оказаться недоступной;
• Firebase Dynamic Links начали отключать 25 августа 2025 года, и перестали работать все ссылки, включая ссылки на собственных доменах.

Есть у меня и свой пример такого решения, только не в облаке, а в устройстве. Прошивка саундбара Klipsch Flexus 2026 года, как я разбирал, «прикрутила слой аутентификации записи к в остальном неизменному API». После обновления запись большинства настроек без подписи перестала работать: без подписи пишутся только громкость и mute. Производитель никого не спрашивал и не обязан был.

Для аудита из этого следует один вопрос: записано ли, что продукт делает, если поставщик выводит модель, поднимает цену или закрывает функцию. Не «есть ли зависимость», она есть почти всегда, а есть ли на этот случай план.

Договоры: переуступка и смена контроля

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

• AWS: переуступка только с письменного согласия, но отдельно опубликовано заранее данное согласие на передачу аккаунта при соблюдении условий. Пункта о смене контроля нет.
• Google Cloud: без согласия только аффилированному лицу, которое письменно приняло условия, и с уведомлением, исключения для продажи бизнеса нет; о смене контроля уведомить в течение 30 дней.
• Microsoft (клиентское соглашение): аффилированному лицу с уведомлением, остальное с письменного одобрения; переуступка не освобождает передающую сторону.
• GitHub: по стандартным условиям без согласия GitHub переуступить нельзя; по клиентскому соглашению аффилированному лицу можно с уведомлением, остальное с одобрения.
• Apple: без явного письменного согласия нельзя, в том числе при слиянии.
• Google Play: смена контроля согласия на переуступку не требует, но при ней Google вправе сразу расторгнуть договор.
• Stripe: согласие, в котором нельзя необоснованно отказать; правопреемнику при слиянии, поглощении или продаже почти всех активов без согласия, но с уведомлением и письменным принятием обязательств; о смене контроля, в том числе ожидаемой, сообщать сразу, и она даёт право задержать выплаты.
• OpenAI: правопреемнику всех или почти всех активов или бизнеса без согласия, с письменным уведомлением минимум за 30 дней.
• Anthropic: только с предварительного письменного согласия.
• Cloudflare (договор для тарифов самообслуживания) и Vercel (общие условия): без письменного согласия нельзя, исключения для продажи бизнеса нет.
• Twilio: правопреемнику без согласия, но обе стороны подписывают соглашение о переуступке, и она вступает в силу с первого числа следующего месяца.

И деталь, мимо которой легко пройти. У Apple и AWS заверения о санкциях распространяются не только на самого клиента, но и на тех, кто им владеет или его контролирует (у Apple прямо или косвенно, у AWS заодно на его банки). Кто станет новым контролирующим владельцем, для поставщика не частное дело компании.

Сроки, которые нельзя сжать

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

• App Store: у получателя 60 дней на принятие передачи, после принятия до двух рабочих дней обработки, если не нужна проверка экспортной документации (её срок Apple не называет);
• вход через Apple: 60 дней после принятия на обмен идентификаторов пользователей;
• Google Play: проверка передачи приложения до двух рабочих дней, смена владельца аккаунта не быстрее семи дней ожидания плюс проверка личности;
• номер D-U-N-S для нового юрлица: у Apple до пяти рабочих дней от Dun & Bradstreet и ещё до двух до Apple, Google Play называет срок до 30 дней;
• домен в общих зонах вроде .com: 60 дней блокировки переноса к другому регистратору после смены владельца, если регистратор не дал отказаться от неё до запроса;
• OpenAI: уведомление о переуступке минимум за 30 дней;
• Google Cloud: уведомление о смене контроля в течение 30 дней после неё;
• Stripe: большинство копий данных в новый аккаунт делается за 72 часа;
• Twilio: переуступка вступает в силу с первого числа следующего месяца.

Часть этих сроков идёт не параллельно, а друг за другом. Без D-U-N-S не открыть организационный аккаунт разработчика, без аккаунта нечего принимать, а в App Store приложение без вышедшей версии не передаётся вовсе.

Мои собственные аккаунты глазами покупателя

Проще всего показать это на своём. У меня есть мессенджер для команды на своих серверах, и в статье о нём я написал: «Нет vendor lock-in, потому что формат данных хорошо задокументирован и инструменты экспорта работают». Про данные это правда. Но у мессенджера есть мобильные приложения, опубликованные в App Store и Google Play, с собственными конфигами Firebase. Если посмотреть на него глазами покупателя, самой медленной частью сделки были бы не сервер и не база, а эти аккаунты: передача приложений в двух магазинах, проект Firebase, ключ APNs, сертификаты, которые придётся выпускать заново.

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

Порядок проверки

1. Реестр по счетам. Все поставщики, за которых компания платит, плюс бесплатные аккаунты, на которых держится продукт: магазины, домены, Firebase.
2. Владелец каждой строки. Юрлицо или человек, кто держит главную роль, где второй фактор, чья карта, на какую почту идут уведомления.
3. Что переходит и что нет. История продаж, заказы, подписки в платёжной системе, пакеты, кредиты, уровень лимитов, особые одобрения.
4. Календарь сроков. Какие процедуры идут последовательно и сколько занимают, до даты закрытия.
5. Кому сообщить о сделке. Где нужно согласие, где уведомление до закрытия, где после. Это решает юрист, моя задача показать пункты.
6. Остаточный доступ продавца. Роль в AWS, ключи сервисных аккаунтов, секреты в репозитории, всё, что переживает передачу.
7. План на решения поставщика. Что делает продукт, если модель выведут, цену поднимут или функцию закроют.

Чего я не делаю

• Не даю юридических заключений. Со страницы услуги: «я нахожу, что права на код не переданы, и показываю где; договор правит юрист». С договорами поставщиков то же самое.
• Не передаю аккаунты через логин и пароль в обход официальной процедуры. Google Play это прямо запрещает с 27 мая 2026 года, а договор OpenAI запрещает делить учётные данные между пользователями. У AWS сама процедура идёт через смену почты и пароля root, и её выполняют по опубликованным условиям AWS.
• Не считаю зависимость дефектом самой по себе. Дефект начинается там, где о ней не знают, её не записали и она оформлена на человека.
• Не выдумываю клиентские истории. Все примеры в этой статье из опубликованных правил поставщиков и из моих собственных систем.

Частые вопросы

Что такое зависимость от поставщика в техническом аудите?

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

Можно ли просто передать логин и пароль от аккаунта?

Нет, если это вместо официальной процедуры. Google Play с 27 мая 2026 года прямо запрещает передавать аккаунт через логин и пароль, у Apple, Stripe и GitHub есть отдельные процедуры смены владельца. У AWS передача технически и есть смена почты и пароля root, но договор переходит, только если выполнены опубликованные условия AWS. Просто отданный пароль юридического владельца не меняет и оставляет доступ у прежнего.

Переходит ли история продаж при передаче приложения?

Нет. В App Store получатель видит только транзакции после передачи. В Google Play заказы до передачи и финансовые отчёты остаются в исходном аккаунте, и Google советует выгрузить отчёты заранее.

Сколько времени занимает передача аккаунтов при сделке?

Зависит от поставщика, и часть сроков идёт последовательно. В App Store у получателя 60 дней на принятие, в Google Play смена владельца аккаунта занимает не меньше семи дней, после смены владельца домена в общих зонах вроде .com обычно действует 60-дневная блокировка переноса к другому регистратору. Календарь стоит собрать до подписания.

Что будет с ключами ИИ-API после сделки?

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

Нужно ли сообщать поставщикам о смене владельца компании?

У части поставщиков да. Google Cloud требует уведомления в течение 30 дней после смены контроля, Stripe требует сразу сообщать и об ожидаемой смене, а Google Play при смене контроля вправе расторгнуть договор. Что именно делать в конкретной сделке, решает юрист.

Остаётся ли у продавца доступ после передачи?

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

Источники

• Apple: обзор передачи приложения и условия передачи.
• Apple TN3159: перенос пользователей входа через Apple.
• Лицензионное соглашение программы разработчиков Apple, пункты 11.2, 14.3 и 14.8.
• Google Play: передача приложения и смена владельца аккаунта.
• Блог Android Developers, 15 апреля 2026 года: запрет неофициальной передачи и семидневное ожидание.
• Соглашение Google Play с разработчиком, пункты 16.6 и 16.7.
• Google Play: регистрация пакетов для верификации разработчиков.
• Firebase: базовые роли и закрытие Dynamic Links.
• Google Cloud: ключи сервисных аккаунтов и перенос проектов.
• Условия Google Cloud, пункты 14.3 и 14.4.
• Клиентский договор AWS и требования к передаче аккаунта.
• AWS Organizations: перенос аккаунтов и перенос домена между аккаунтами.
• GitHub: передача репозитория и права на пакеты.
• Stripe: передача аккаунта покупателю из другой страны и условия сервисов.
• ICANN: политика передачи доменов, редакция 2024 года.
• Договор об услугах OpenAI и график вывода моделей.
• Коммерческие условия Anthropic, уровни и лимиты и вывод моделей.
• Microsoft Foundry: вывод моделей.

Нужна консультация?

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