Один общий аккаунт подписки может сэкономить на местах, но реальные издержки часто выше. В статье разобраны четыре проблемы: нарушение условий, передача учетных данных, невозможность привязать действия в журналах к человеку и сохранение доступа после ухода сотрудника, а также допустимые альтернативы.
Добавление еще одного пользовательского места в SaaS-сервисе может быть заметной статьей расходов. Чем больше становится команда, тем ощутимее эта сумма.
Поэтому использовать один набор данных для входа на всех кажется естественным, особенно если кому-то нужно лишь изредка посмотреть отчет или ненадолго проверить данные для клиента. Но реальная цена такого решения часто недооценивается и распределяется по нескольким направлениям: условия использования, учетные данные, журналы действий и изменения состава команды. В каждом из них возникают свои проблемы.
Условия сформулированы ясно: аккаунты нельзя передавать другим
Большинство SaaS-продуктов используют лицензирование по пользовательским местам. За исключением корпоративных или командных тарифов, которые прямо поддерживают нескольких пользователей, остальные планы обычно рассчитаны на одного человека. Условия сервиса, как правило, прямо запрещают нескольким людям использовать один логин, а платформа при обнаружении такого поведения может приостановить или отозвать доступ. Есть важный нюанс: подобное прекращение доступа обычно не сопровождается возвратом средств, поэтому уже уплаченные деньги могут быть потеряны.
Есть и менее заметная цена. Мотив совместного использования — экономия, но модель платформы по-прежнему предполагает оплату за число людей, которым нужен доступ. Фактически экономия превращает стоимость лицензий в риск нарушения условий, который остается незаметным, пока не возникнет проблема.
Когда пароль знают многие, невозможно понять, кто действовал
Совместное использование означает, что пароль передается между несколькими людьми, часто через мессенджеры, заметки и другие места, где одно сообщение может остаться навсегда.
Проблема не только в самом пароле, но и в двух последствиях. Во-первых, увеличивается поверхность утечки: чем больше участников, тем выше вероятность, что кто-то повторно использовал тот же пароль в другом сервисе или его устройство было скомпрометировано, открыв путь к аккаунту. Во-вторых, становится трудно установить ответственность. Если аккаунт использовали для экспорта данных, изменения настроек или отправки того, что не следовало отправлять, впоследствии можно увидеть лишь действия аккаунта, но не конкретного человека. Для команд, которым нужно объяснять клиентам движение данных, это часто становится самым сложным вопросом.
Журналы фиксируют аккаунт, а не человека
Административные системы SaaS обычно хранят активность на уровне аккаунта: кто экспортировал отчет, какие настройки изменил и какие данные удалил. В журнале при этом часто остается только одно имя аккаунта.
После того как аккаунтом начинают пользоваться несколько людей, эта прослеживаемость исчезает. Команда не может определить, кто внес изменение, и система обнаружения аномалий платформы сталкивается с той же проблемой. Она может видеть вход одного аккаунта из разных городов, с разных устройств и сетевых выходов, а также одновременные сессии, после чего отметить активность как подозрительную. Типичные меры — принудительный выход, временная блокировка или повторная проверка. Если инструмент нужен в ежедневной работе, потеря доступа в рабочее время может обойтись намного дороже нескольких дополнительных мест.
Смена прокси или унификация отпечатков браузера может лишь снизить вероятность обнаружения; это не делает совместные учетные данные допустимыми. Кроме того, если все входы привязаны к одной среде, проблема с этой средой — например, помеченный IP-адрес или среда, признанная аномальной, — может одновременно отключить доступ у всех и увеличить масштаб сбоя.
Человек ушел, а доступ остался
Когда сотрудник увольняется или заканчивается работа внешнего подрядчика, за отзыв доступа к общему аккаунту часто никто явно не отвечает. Причина проста: аккаунт общий, поэтому отдельного шага передачи ответственности нет.
Остается несколько рисков. Бывший участник команды может по-прежнему знать пароль, и неизвестно, кто еще его сохранил. Ранее выданные сессионные cookie могут оставаться действительными. Если человек настраивал с помощью этого аккаунта сценарии автоматизации или вызовы API, эти каналы доступа также не исчезнут автоматически. К моменту обнаружения проблемы данные уже могут быть изменены.
Кроме того, при любом изменении состава команды пароль пришлось бы менять для всех. В модели общего аккаунта такую смену часто невозможно выполнить полностью.
Допустимые альтернативы несложны
Если разделить причины, по которым команда хочет делиться аккаунтом, подходящие варианты становятся довольно очевидными.
- Для постоянных сотрудников, которым нужен доступ: покупать дополнительные места. Это единственный официально поддерживаемый способ работы нескольких людей и возможность снова сделать журналы действий персонально прослеживаемыми.
- Для больших команд: проверить, предлагает ли платформа многопользовательский командный или корпоративный тариф. Такие тарифы обычно включают модель прав, позволяющую ограничивать, что каждая роль может видеть или изменять.
- Для централизованного управления: использовать SSO. При уходе человека его доступ можно отключить централизованно, не полагаясь на то, что кто-то вспомнит об отзыве прав.
- Если нужно временно показать клиенту результат: экспортировать отчет или создать ссылку только для чтения, чтобы клиент мог проверить данные без входа в аккаунт.
Важно различать совместное использование одного аккаунта и работу с несколькими аккаунтами. В первом случае несколько людей используют один набор учетных данных. Во втором у каждого есть собственные учетные данные, но на одном устройстве нужно работать так, чтобы аккаунты не мешали друг другу; сам по себе такой подход может быть допустимым. Например, если команда купила место для каждого участника и у каждого есть отдельный аккаунт, cookie и сессии в одном браузере могут перезаписывать друг друга. Отдельная среда браузера для каждого аккаунта позволяет разделить сессии, кэш и данные. PurpleMark предоставляет именно такую изоляцию среды. Она решает задачу стабильной работы нескольких легитимных аккаунтов на одном устройстве; однако совместное использование одного логина несколькими людьми по-прежнему нарушает условия сервиса.
Сначала посчитайте расходы
По сути, совместный аккаунт обменивает риск нарушения условий на небольшую экономию на пользовательских местах. Редкое, временное использование одним человеком может какое-то время казаться рабочим решением, но в масштабе команды отзыв доступа или инцидент с данными может стоить намного дороже сэкономленной суммы.
Сначала рассчитайте стоимость лицензий, а затем выберите подходящий вариант. Если можно купить места — купите их; если можно экспортировать данные — экспортируйте.
Точные правила лицензирования всегда определяются официальными условиями конкретного продукта.
