Спільний обліковий запис підписки може заощадити на ліцензіях, але реальна ціна часто вища. Стаття розглядає чотири проблеми: порушення умов, передавання облікових даних, неможливість прив’язати журнали до людини та збереження доступу після звільнення, а також належні альтернативи.
Додавання ще одного користувацького місця до SaaS-інструмента може бути відчутною витратою. Що більшою стає команда, то помітніша ця сума.
Тому спільне використання одного набору даних для входу може здаватися природним, особливо якщо комусь потрібно лише зрідка переглянути звіт або тимчасово перевірити дані для клієнта. Проте реальну ціну такого підходу часто недооцінюють, а ризики розподіляються між кількома сферами: умовами сервісу, обліковими даними, журналами дій та змінами в команді. У кожній з них виникають свої проблеми.
Умови чіткі: акаунти не можна передавати іншим
Більшість SaaS-продуктів використовують ліцензування за користувацькими місцями. Окрім корпоративних або командних тарифів, які прямо підтримують кількох користувачів, інші плани зазвичай розраховані на одну особу. Умови сервісу переважно прямо забороняють кільком людям користуватися одним логіном, а платформа після виявлення такого використання може призупинити або відкликати доступ. Є важливий момент: таке припинення доступу зазвичай не передбачає повернення коштів, тому вже сплачені суми можуть бути втрачені.
Існує й менш помітна вартість. Мета спільного використання — заощадити, але платформа все одно розраховує ціну за кількістю людей, яким потрібен доступ. Фактично економія просто замінює витрати на ліцензії ризиком порушення правил, який не видно, доки не виникне проблема.
Коли пароль знають багато людей, важко встановити, хто діяв
Спільне використання означає, що пароль передається між кількома людьми, зазвичай через месенджери, нотатки або інші місця, де одне повідомлення може залишитися надовго.
Проблема не лише в самому паролі, а у двох наслідках. По-перше, збільшується поверхня витоку: що більше людей залучено, то вища ймовірність, що хтось повторно використав той самий пароль в іншому сервісі або його пристрій було скомпрометовано, створивши шлях до акаунта. По-друге, важко встановити відповідальність. Якщо акаунт використали для експорту даних, зміни налаштувань або надсилання того, чого не слід було надсилати, згодом можна побачити лише дії акаунта, але не конкретну людину. Для команд, яким потрібно пояснювати клієнтам рух даних, це часто одна з найскладніших проблем.
Журнали записують акаунт, а не людину
Адміністративні системи SaaS зазвичай зберігають активність на рівні акаунта: хто експортував звіт, які налаштування змінив і які дані видалив. У журналі часто залишається лише одне ім’я акаунта.
Коли одним акаунтом користуються кілька людей, ця простежуваність зникає. Команда не може визначити, хто вніс зміну, а система виявлення аномалій платформи стикається з тією самою проблемою. Вона може бачити, що один акаунт входить із різних міст, пристроїв і мережевих виходів, а одночасно активні кілька сесій, і позначити таку активність. Типові реакції — примусовий вихід, тимчасове блокування або повторна перевірка. Якщо інструмент потрібен для щоденної роботи, втрата доступу в робочий час може коштувати набагато більше, ніж кілька додаткових місць.
Зміна проксі або уніфікація відбитків браузера може лише знизити ймовірність виявлення; це не робить спільні облікові дані допустимими. Крім того, якщо всі входи прив’язані до одного середовища, проблема з цим середовищем — наприклад позначена IP-адреса або середовище, визнане аномальним, — може одночасно перервати доступ усім і збільшити масштаб збою.
Людина пішла, а доступ залишився
Коли працівник звільняється або завершується співпраця із зовнішнім підрядником, за відкликання доступу до спільного акаунта часто ніхто чітко не відповідає. Причина проста: акаунт належить усім, тому немає окремого кроку передачі відповідальності.
Залишається кілька ризиків. Колишній учасник команди може й надалі знати пароль, а ніхто не знає, хто ще його зберіг. Раніше видані сесійні cookie можуть залишатися чинними. Якщо ця людина налаштувала з акаунтом сценарії автоматизації або виклики API, ці канали доступу також не зникнуть автоматично. На момент виявлення проблеми дані вже можуть бути змінені.
Крім того, за кожної зміни складу команди пароль довелося б змінювати для всіх. У моделі спільного використання це часто неможливо зробити повністю.
Належні альтернативи не є складними
Якщо розділити причини, через які команда хоче ділитися акаунтом, відповідні варіанти стають досить очевидними.
- Для постійних учасників, яким потрібен доступ: купуйте додаткові місця. Це єдиний офіційно підтримуваний спосіб користування кількома людьми, і він повертає персональну простежуваність у журналах.
- Для більших команд: перевірте, чи пропонує платформа багатокористувацький командний або корпоративний тариф. Такі тарифи зазвичай мають модель дозволів, яка обмежує за ролями, що можна переглядати або змінювати.
- Для централізованого керування: використовуйте SSO. Коли людина йде, її доступ можна вимкнути централізовано, не покладаючись на те, що хтось згадає про ручне відкликання.
- Щоб тимчасово показати клієнту результат: експортуйте звіт або створіть посилання лише для читання, щоб клієнт міг перевірити дані без входу в акаунт.
Важливо відрізняти спільне використання одного акаунта від роботи з кількома акаунтами. У першому випадку кілька людей використовують один набір облікових даних. У другому кожна людина має власні облікові дані, але на одному пристрої потрібно працювати без взаємного втручання; сам по собі цей другий підхід може бути допустимим. Наприклад, якщо команда придбала місце для кожного учасника і кожен має власний акаунт, cookie та сесії в одному браузері можуть перезаписувати одне одного. Окреме середовище браузера для кожного акаунта дозволяє розділити сесії, кеш і дані. PurpleMark забезпечує саме таку ізоляцію середовища. Вона вирішує проблему стабільного співіснування кількох легітимних акаунтів на одному пристрої; але факт того, що кілька людей спільно використовують один логін, і далі залишається порушенням умов сервісу.
Спершу порахуйте витрати
По суті, спільний акаунт обмінює ризик порушення правил на невелику економію на користувацьких місцях. Рідкісне, тимчасове використання однією людиною може певний час здаватися прийнятним, але в масштабі команди відкликання доступу або інцидент із даними може коштувати набагато більше, ніж зекономлена сума.
Спершу порахуйте вартість ліцензій, а вже потім обирайте підхід. Якщо можна купити місця — купуйте; якщо можна експортувати дані — експортуйте.
Точні правила ліцензування завжди визначаються офіційними умовами конкретного продукту.
