Доступы и 2FA в SaaS: как настроить роли и не потерять аккаунт

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

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

Отделите владельца от повседневной работы

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

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

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

Выдавайте каждому личную учётную запись

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

Составьте простой список ролей по работе, а не по должностям. Например:

• читатель открывает опубликованные материалы;
• редактор создаёт и меняет записи;
• руководитель утверждает и видит отчёты;
• администратор управляет пользователями и настройками;
• владелец меняет критичные параметры и оплату.

Начинайте с минимальной роли. Добавляйте право после конкретной потребности, а не «на всякий случай». Если сервис предлагает только роли «пользователь» и «администратор», оцените, не даёт ли администратор лишний доступ слишком многим людям.

Включите 2FA и сразу проверьте восстановление

2FA — двухфакторная аутентификация: кроме пароля вход требует подтверждение другого типа, например приложения с одноразовым кодом или аппаратного ключа. Она снижает риск входа по украденному паролю, но не защищает от всех видов обмана и ошибок в правах.

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

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

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

Рассматривайте интеграции как отдельные учётные записи

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

Перед подключением выясните:

• какие данные интеграция может читать и менять;
• кто её одобрил и кто владеет связанной учётной записью;
• где отзывается токен;
• когда доступ использовался последний раз;
• перестанет ли важный процесс работать после отключения сотрудника.

Руководство NCSC по SaaS рекомендует учитывать не только людей, но и служебные учётные записи, автоматизации и дополнения. Интеграции с доступом ко всем данным требуют более строгого согласования, чем виджет, который видит один публичный календарь.

Отключайте доступ в определённом порядке

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

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

Раз в несколько месяцев сравнивайте список пользователей с реальной командой. Отдельно смотрите администраторов, давно неактивные аккаунты, приглашения без завершённой регистрации и интеграции. Такая короткая проверка полезнее, чем редкий большой аудит после инцидента.

Управление доступом нужно оценивать ещё во время пробного испытания SaaS. А перед закрытием сервиса список пользователей и токенов станет частью плана переноса.