Обычно новый ящик создают, назначают ему пароль, а затем отправляют пользователю и адрес, и пароль. Почти все понимают, что так делать нельзя, но всё равно поступают именно так, потому что раньше альтернатива требовала больше усилий. Приглашения для настройки устраняют эту отговорку: администратор не задаёт пароль, а передавать его по почте или в чате никому не приходится.
Разберём, как работают приглашения, почему отказ от передачи паролей важнее, чем кажется, и как он влияет на двухфакторную аутентификацию и отзыв доступа при увольнении.
Почему нельзя передавать пароли, даже если пока ничего не случилось
Самая очевидная причина состоит в риске перехвата. Пароль, отправленный по электронной почте или в чате, бессрочно остаётся как минимум в двух ящиках, доступен для поиска и попадает во все резервные копии. Любой, кто впоследствии получит доступ к одной из учётных записей, найдёт и пароль. NIST уже много лет рекомендует не передавать секреты таким способом.
Менее заметная проблема заключается в том, что пароль так и не меняют. Предполагается, что при первом входе пользователь задаст собственный пароль. На практике он оставляет присланный вариант, поскольку тот работает, а обязательной смены нет. Через несколько месяцев администратор всё ещё знает действующие данные для входа в чужой ящик. После этого уже нельзя уверенно утверждать, что действия в ящике совершал именно его владелец.
Последнее особенно важно при любых спорах. Если пароль знают два человека, невозможно достоверно связать действие в учётной записи с одним из них. Схема без передачи паролей не только безопаснее, но и является необходимым условием достоверного журнала аудита.
Как приглашения позволяют обойтись без передачи пароля
Администратор создаёт ящик вообще без пароля. Система отправляет будущему пользователю ссылку по электронной почте, пользователь открывает её и самостоятельно выбирает пароль. Учётные данные ни на одном этапе не попадают в чужие руки.
Таким образом, пароль никогда не существует в форме, которую видел кто-то ещё. Его нет ни в папке отправленных писем, ни в истории чата, а администратору не приходится помнить сведения, которые он не должен знать.
Приглашения можно отправлять по одному или сразу группой. Именно массовая отправка превращает хорошую идею в практичный процесс. При создании сорока ящиков для нового клиента вы отправляете сорок приглашений одной операцией, а не придумываете, записываете и передаёте сорок паролей. Массовый сценарий описан в статье про массовое создание почтовых ящиков.
Вторая половина защиты: двухфакторная аутентификация
Отказ от передачи паролей закрывает одну уязвимость, но оставляет другую. Даже пароль, известный только пользователю, может оказаться слабым или повторно использоваться в другом сервисе.
Двухфакторная аутентификация устраняет этот риск. Пользователь подключает её в настройках веб-почты уже после принятия приглашения. Это отдельное действие, которое система не навязывает в ходе первоначальной настройки. Поэтому внедрение зависит от того, попросите ли вы пользователей включить защиту.
Напомните об этом при отправке приглашения, а через неделю повторите просьбу. На странице безопасности почтовых ящиков в панели управления видно, где активна двухфакторная аутентификация и когда её подтвердили. Благодаря этому непринятые меры можно отслеживать по списку, а не пытаться угадать.
Одновременно потребуйте сохранить коды восстановления. Владелец аккаунта не может сбросить второй фактор почтового ящика из панели управления. Если пользователь потеряет и устройство, и коды, понадобится обращение в поддержку. Полный порядок действий приведён в статье про восстановление доступа после блокировки 2FA.
Как меняется работа администратора
В основном отказ от передачи паролей сокращает объём работы администратора, хотя требует одного изменения привычек.
Администратор больше не хранит чужие учётные данные, поэтому исчезает целая категория запросов. Вопрос «Не напомните мой пароль?» заменяется самостоятельным сбросом со стороны пользователя. Кроме того, администратор больше не остаётся человеком, которому приходится доверять чужие учётные данные. При обслуживании клиентских ящиков, а не почты коллег, это особенно ощутимое облегчение.
Изменение состоит в том, что администратор уже не сможет войти в чужой ящик, чтобы что-либо проверить. В первый раз это может показаться неудобным, но такой порядок всегда правилен. Если компании нужен доступ к переписке, следует создать общий почтовый ящик, добавить сотрудников как участников и выдать им доступ, а не передавать администратору пароль пользователя. Это разные модели с разной ответственностью. Их смешение как раз и должна предотвращать практика отказа от общих паролей.
Ситуации, которые всё ещё требуют внимания
Два сценария нельзя просто включить и забыть. Их стоит проверять по расписанию, а не полагаться на память.
Пользователи, которые не приняли приглашение. Невостребованный ящик никто не читает, хотя письма уже могут туда поступать. Срок действия приглашений заканчивается, и это правильно. Однако кто-то должен проверять, действительно ли назначенный пользователь завершил настройку.
Адреса, относящиеся к объекту, а не к человеку. У ящика для недвижимости или номера заказа нет отдельного пользователя, которого можно пригласить. Для таких адресов сразу нужен общий ящик со списком участников. Тогда доступ определяется членством, а не одним набором учётных данных. Иначе вы другим путём вернётесь к общему паролю.
Срок приглашения ограничен, чтобы пароль не оказался общим случайно
Ссылка для настройки с неограниченным сроком действия стала бы всего лишь более сложным вариантом пароля. Поэтому приглашение действительно только определённое время, а затем перестаёт работать.
Если создавать ящики задолго до выхода сотрудников на работу, ссылки успеют истечь, и в первое утро придётся разбираться с непонятными письмами. Отправляйте приглашения, когда люди уже готовы ими воспользоваться. Вместо попыток восстановить просроченную ссылку выпустите новую, это занимает несколько секунд.
Не используйте общие пароли и в других системах
Когда учётные данные от ящиков перестают передавать между людьми, тот же вопрос возникает и в других системах. Там стоит следовать тому же принципу.
Общая учётная запись для хранилища, один пароль приложения на нескольких устройствах, один API-токен для трёх сценариев имеют один и тот же недостаток. Отзыв доступа у одного участника нарушает работу всех остальных. Отдельные учётные данные для каждого устройства решают аналогичную проблему с хранилищем, как описано в статье про синхронизацию файлов между устройствами.
Правило применимо повсеместно: если одни учётные данные известны нескольким сторонам, невозможно отозвать их только у одной из них и достоверно определить, кто совершил действие. Отказ от передачи паролей нужен прежде всего не для сохранения тайны. Он позволяет изменить решение об одном человеке, не нарушая работу всех остальных.
