Вы наверняка знаете термин "экосистема", который обычно применяют к комплексу сервисов Apple или Google. И Яндекс не отставал. Ваш почтовый ящик на базе Яндекса позволяет вам логиниться практически во все их системы от почты и Браузера, до Диска, Такси, Кино и т.п. Привязанная карта к учетке становится доступна в прочих системах, очень удобно платить и управлять всем. И тут мы подбираемся к нюансам и попробуем понять, причем тут свои домены.

Что такое учетная запись

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

Чтобы не регистрироваться каждый раз, были придумали регистрации через крупные сервисы, вроде Гугла, Эпла и, как дальше пойдет речь, через Яндекс.ID. В этом случае вы не вводите логины и пароли, они передаются порталу со стороны вендора такой учетной записи, иногда только email, иногда запрашивается больше всякого, но не суть.

А вы не задумывались, что произойдет во всех связанных таким образом порталах, когда вы удалите свою учетную запись у вендора? Это первая попытка осмыслить последствия на примере Яндекс.ID. И, что важно особенно, начнем тему со своих доменов.

Домены и почтовые ящики на Яндексе

Старожилы помнят, что раньше был сервис PDD.yandex.ru, где мы приземляли домены и могли настроить почтовые ящики на своем домене, вроде YOURNAME@YOURDOMAIN.

Такой ящик становился доступным для доступа в стандартном интерфейсе Яндекса, и рядом с вашей учетной записью YOURNAME@YANDEX.RU вы могли переключиться и в ящик YOURNAME@YOURDOMAIN.

Через несколько лет сервис превратился в CONNECT.yandex.ru, были свои сложности. А еще одна итерация не так давно превратила Коннект в 360.yandex.ru с различными нюансами. В том числе появился переработанный ID.yandex.ru, где доступно много интересной магии.

Что из себя представляет учетка на Яндексе

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

Отличие почты на@YANDEX.RUот почты на @YOURDOMAINпрактически отсутствует. Вы точно так же можете пользоваться всеми сервисами экосистемы, только вы самостоятельно не можете удалить свой аккаунт, потому что это может делать только администратор вашего домена.

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

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

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

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

Какие сервисы могут оказаться вам недоступны, если удалить почтовый ящик на домене Яндекса

На самом деле, четкого ответа нет. Есть только признак:

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

То есть, если ваш сотрудник на корпоративном ящике будет проводить работы в разных сервисах Яндекса, заводя личные кабинеты, выписывая счета и т.п., вы можете получить вполне серьезный аккаунт, на который завязано очень многое. Но об этом комплексе систем вы скорее всего не узнаете сразу, ведь администратор домена далеко не всегда знает, чем занимается сотрудник компании. Он просто организовывает пару ЛОГИН:ПАРОЛЬ, помогает корректировать данные учетки, а дальше дело не его.

Пример про Яндекс.Облако

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

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

Сбросы паролей учетки на почте => сбросы паролей приложений

Есть еще один важный нюанс, который администратор домена может не предусмотреть. Сейчас набирает обороты практика применения отдельных паролей для приложений. Это отдельная версия пароля, чтобы какая-то внешняя система (почтовый клиент, особый клиент к файлам, CRM и т.п.) могли подключаться к вашему аккаунту.

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

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

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

Что у других систем?

Ровно тоже самое. Удаление учетки в G.Suite и прочих приведет к потере всего, что было у вас ранее. Вы не сможете практически ничего вернуть, если удалите учетную запись. И о последствиях такого удаления вы узнаете не от вендора, а когда что-то отвалится. Они пока сами не готовы к тому, чтобы в моменте предупредить вас о возможных проблемах удаления.

Предварительные выводы

Для нас ситуация оголила очень серьезный момент когнитивного диссонанса. Учетная запись на своем домене на базе крупного вендора становится не просто парой ЛОГИН:ПАРОЛЬ, которые всегда можно поменять или переехать доменом к другому вендору. Нет, это элемент огромной системы, где все со всем переплетено. Начать пользоваться элементом экосистемы без учетной записи на базе вендора становится почти невозможным.

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

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

Послесловие

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