Чому вбудовані звіти розкривають дані: розбір signed embedding
Публічне посилання на звіт — швидкий спосіб показати аналітику і найкоротший шлях до витоку даних із дашбордів. Адреса не перевіряє, хто її відкрив: вона осідає в історії браузера, в пересланому листі, в логах проксі та в пошуковому індексі.
Один раз надіслана в спільний чат, вона віддає вивантаження з маржею, клієнтською базою чи динамікою продажів.
Спільні облікові записи дають той самий результат іншим шляхом. Коли відділ ходить під одним логіном, права на дашборд перестають щось обмежувати: усі бачать усі звіти, а в журналах залишається безликий запис.
Розмежувати доступ до аналітики за ролями, регіонами чи клієнтами в такій схемі не можна, і під час розбору інциденту незрозуміло, хто саме відкривав дані.
Підписаний доступ (signed embedding) закриває обидві діри. Сервер застосунку формує посилання на звіт у момент запиту, додає підпис секретним ключем і параметри користувача — ідентифікатор, роль, фільтри за його даними.
Аналітична платформа перевіряє підпис, віддає лише дозволений зріз і не зберігає паролів ваших користувачів.
Metabase підтримує цей режим штатно: підпис живе хвилини, фільтри підставляються на боці застосунку, тому переслане посилання не відкриє чуже. Розбираємо, як це влаштовано і що потрібно налаштувати.
Що дає вбудовування аналітики в інтерфейс продукту
Перше, що помічають після вбудовування, — звітність переїжджає всередину продукту. Користувач не йде в зовнішній інструмент аналітики і не тримає другу вкладку відкритою: потрібний зріз він дивиться там само, де працює із заявками, рахунками чи замовленнями. Це змінює і поведінку — до цифр звертаються в момент рішення, а не раз на тиждень за нагадуванням.
Технічну основу дає signed embedding: сервер продукту формує підписаний токен, у який зашиті ідентифікатор користувача, доступний йому набір фільтрів і строк життя. Підпис перевіряється на боці сервісу аналітики, тому підмінити параметри в браузері не можна.
Розмежування за рядками даних задається тим самим токеном — клієнт бачить лише свої зрізи, і це не потребує окремої копії дашборда під кожного.
Єдиний вхід знімає цілий клас інцидентів із доступом. Облікові записи не розмножуються по інструментах, права успадковуються з продукту, а при звільненні чи зміні ролі доступ закривається однією операцією. Перевіряти варто саме це: скільки разів за період доступи заводять і відкликають вручну.
Зниження ручних вивантажень вимірюється просто: частка запитів «надішліть звіт» у підтримку і частка зрізів, які досі збирають у таблиці.
Коли потрібна вибірка будується в інтерфейсі за пару секунд, аналітик перестає бути посередником між даними та рішенням, а клієнт отримує аналітику як частину продукту, а не як окрему послугу на запит.
Способи вбудовування аналітики: де потрібен signed embedding
Вибір між способами вбудовування звітів визначається не зручністю розробника, а тим, кому ми віддаємо дані і наскільки динамічні фільтри. Публічний дашборд живе за постійним посиланням і не знає, хто його відкрив.
Постійна вбудована сесія показує всім одну й ту саму картину всередині інтерфейсу. Підписане посилання на звіт (signed embedding) формується на боці застосунку під конкретного користувача і несе фільтри в собі.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Публічний дашборд | Відкрита звітність, демонстрації, вітрини без персональних даних | Немає розмежування доступу, фільтри зашиті в сам дашборд |
| Постійна вбудована сесія | Внутрішній портал, де всі дивляться одні й ті самі агрегати | Один набір прав на всіх, параметри не можна задати на льоту |
| Підписане посилання на звіт | Клієнтські кабінети, вибірки за конкретним користувачем або контрагентом | Підпис рахує сервер, строк життя посилання потрібно обмежувати |
Що стоїть за вибором
Публічний варіант економить час на старті, але кожна нова вибірка потребує правки дашборда вручну, а витік посилання дорівнює витоку даних.
Вбудована сесія вирішує питання зовнішнього вигляду, але не питання прав: якщо фільтр потрібно підставити з облікового запису, він туди не потрапляє.
Підписане посилання закриває задачу інакше — застосунок сам обчислює параметри, підписує їх секретом і віддає готову адресу, а сервер аналітики перевіряє підпис і не дає підмінити значення в запиті.
Тому такий режим беруть там, де звітність бачать зовнішні користувачі, а не лише співробітники. Далі розбираємо, як ця схема збирається і що передбачити під час переходу з публічного доступу.
Етапи робіт: від аудиту джерел до викладки в продакшн
Впровадження аналітики в продукт починається не з графіків, а з інвентаризації даних: якщо метрика рахується в двох місцях по-різному, вбудований звіт буде тиражувати розходження з тією ж швидкістю, з якою його дивляться.
-
Аудит джерел даних. Звіряємо, звідки беруться цифри: схема таблиць, частота оновлення, часові пояси, правила агрегації. Результат — карта метрик і перелік розходжень, які закриваємо до вбудовування.
-
Схема доступу. Розводимо, що бачить клієнт, менеджер і адміністратор: зіставлення ролей продукту з групами звітів і рядкові фільтри за ідентифікатором акаунта.
-
Налаштування signed embedding. У Metabase підпис збирається на сервері, секретний ключ у розмітку не потрапляє; у нього зашиваємо параметри фільтрації і строк життя посилання, щоб через чужий акаунт не відкрилися дані сусіда.
-
Вбудовування в інтерфейс. Адреса і параметри звіту приходять із бекенду, стани завантаження й помилок обробляються засобами продукту, права перевіряються до відрисовки.
-
Перевірка на стенді. Проганяємо сценарії: гість без сесії, чужий ідентифікатор, прострочений підпис, недоступне джерело. Вимірюємо час відкриття звіту і поведінку під час відмов.
-
Викладка в продакшн і передача регламентів. Порядок оновлення звітів, ротація ключа підпису, дії при недоступності джерела — фіксуємо в документі, який залишається вашій команді.
Кожен етап закінчується перевірюваним артефактом: карта метрик, схема прав, конфігурація звітів, результати прогону. Так шлях від «дашборд відкривається» до «показникам можна вірити» стає передбачуваним.
Що передаємо на руки: конфігурації, схеми та регламенти
Підписане вбудовування (signed embedding) закінчується не запуском панелі, а пакетом артефактів: за ними ваша команда зможе змінювати звіти, ролі та фільтри без звернення до нас. Усе лежить у репозиторії поруч із кодом застосунку і проходить перевірку разом із ним.
- Конфігурації підключення — середовище, джерело даних, перелік вбудованих панелей, ключ підпису та порядок його ротації.
- Схема інтеграції — як застосунок збирає підписаний запит, де перевіряються права користувача і що відбувається при відмові.
- Політики доступу — відповідність ролей застосунку фільтрам у звітах: хто і які рядки даних бачить.
- Документація з аналітики — моделі, джерела, розклади оновлення і власник кожної вітрини.
- Інструкція для підтримки — типові збої: прострочений підпис, порожній фільтр, недоступне джерело — і порядок дій для кожного.
- Регламент змін — як додати панель або параметр, не ламаючи вже вбудовані подання.
Окремо фіксуємо матрицю «роль — панель — фільтр»: вона знімає більшість питань на прийманні. Передачу ведемо на демонстраційному контурі — ваша команда сама додає звіт і змінює права, ми звіряємо результат і доповнюємо документацію за фактом.
Кейс: скоротили частку відмов доступу до дашбордів
Клієнт — платформа з особистим кабінетом: у кожного замовника своя аналітика, і дашборди мають відкриватися прямо в інтерфейсі, без другого входу.
Спочатку звітність жила в окремому контурі Metabase: менеджер вручну створював обліковий запис, налаштовував права і надсилав клієнту логін окремим листом.
Видача доступу займала від кількох годин до двох діб, а в підтримку йшли однотипні звернення — «дашборд не відкривається», «знову просить пароль», «бачу показники іншого клієнта».
Ми перевели вбудовування на signed embedding: сервер застосунку формує підписаний токен, у якому зашиті ідентифікатор клієнта, його роль, набір фільтрів і короткий строк життя, щоб посилання не можна було переслати й перевикористати.
Дашборд віддається всередині кабінету без логіна й пароля, а параметри не підробити через адресний рядок — підпис перевіряється на боці сервісу аналітики, і будь-яка правка робить токен недійсним.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Видача доступу новому клієнту | від кількох годин до двох діб | автоматично при вході в кабінет |
| Частка звернень у підтримку щодо доступів | близько двох третин усіх звернень | поодинокі, пов'язані з налаштуванням ролей |
| Відмови доступу: прострочений пароль, чужий профіль | відтворювалися постійно | не виникають за побудовою |
| Підключення нового клієнта | ручна робота менеджера в адмінці | один запис у конфігурації |
Що це дало
Потік заявок на доступи зник: підтримка перестала бути посередником між клієнтом і аналітикою, а менеджери — тримати в голові, кому і що видано.
Права тепер успадковуються від ролі в застосунку, тому при зміні тарифу чи відключенні клієнта набір видимих дашбордів змінюється тією самою дією, без ручної синхронізації.
Чим підписане посилання відрізняється від публічного?
Публічне посилання не містить підпису: адреса — це і є доступ. Сервер віддає дані будь-кому, хто її відкрив, а строк життя визначається лише тим, коли хтось згадає її вимкнути. Прив'язки до користувача немає: параметри якщо й є, то прямо в адресі, і їх легко підмінити.
Підписане посилання (Metabase signed embedding) — це токен на конкретного користувача і конкретну картку. Усередині — ідентифікатор дашборда, набір параметрів доступу і час закінчення; підпис закритим ключем не дає підмінити їх в адресному рядку. Строк життя задаємо явно: від хвилини на разове відвантаження до кількох годин на робочий екран.
Відкликання доступу — головна відмінність на практиці. Публічне посилання можна лише вимкнути повністю, і доступ одразу втрачають усі, кому ви його віддавали; точково відкликати доступ одному адресату не можна.
У підпису є два важелі: короткий строк життя і ротація ключа — інвалідація ключа гасить усі видані токени одразу.
Короткий строк і ротація закривають витік, але не скасовують серверну перевірку прав. Підпис підтверджує, що параметри видав наш бекенд, а не що користувачу належать саме ці рядки.
Тому в токен кладемо мінімальний набір фільтрів, а доступ до кожної картки все одно звіряємо на сервері перед віддачею даних.
Технічні сумніви та обмеження підходу
Сумніви навколо підписаного вбудовування (signed embedding) зазвичай одні й ті самі: чи не відкриється доступ до даних через чужий інтерфейс, чи побачить кожен клієнт лише свої рядки і що буде з аналітикою, коли дашборд, зібраний у Metabase, почне жити окремо від застосунку.
Влаштовано це так: підпис формується на сервері застосунку, а не в браузері, тому секрет не залишає бекенд. А що саме потрапляє в підпис — ідентифікатор дашборда, фільтри за клієнтом, строк життя, — визначає безпеку вбудовування.
Клієнт підправить параметри в адресному рядку і побачить чужі дані?
Підпис рахується за всім набором параметрів: зміна дашборда, фільтра або строку робить його недійсним, і сервер аналітики відхиляє запит. Фільтрація даних задається на нашому боці в момент видачі посилання, а редагованим залишається лише те, що ми явно дозволили.
Посилання перешлють третій особі?
Підписане посилання живе хвилини і прив'язане до конкретних параметрів — після закінчення строку сервер поверне відмову, а не дані. За потреби ми прив'язуємо видачу до сесії користувача в застосунку, і посилання не працює окремо від авторизації.
Хто відповідає за дашборди після запуску і що підхід не закриває?
Дашборд правиться в самому інструменті аналітики, без релізу застосунку: змінюються графіки, додаються зрізи, уточнюються формули. Зміни, що зачіпають фільтрацію, проходять погодження — решта вноситься без перевірки.
Обмеження чесне: підхід закриває перегляд і фільтрацію готових звітів, але не замінює аналітичний інтерфейс — довільні запити й важкі вивантаження залишаються в самому інструменті.
Обговоримо вашу задачу вбудовування аналітики
Щоб повернутися з оцінкою проєкту вбудовування, а не із загальними словами, нам потрібен ваш контур: де живе аналітика, хто її дивиться і за якою ознакою дані діляться між користувачами. Нижче — що знадобиться від вас на вході. З цим набором ми збираємо план робіт і строки впровадження без уточнювальних кіл.
- Перелік дашбордів і питань, які вони закривають: які показники дивиться керівник, які — клієнт в особистому кабінеті.
- Модель доступу: список ролей, правила видимості, чи є розподіл за клієнтами і за яким полем ріжеться вибірка.
- Джерела даних: звідки приходять вітрини, як часто оновлюються, допустима затримка між подією і графіком.
- Авторизація в застосунку: де видається сесія і в який момент зручно формувати підписаний токен (signed embedding) з урахуванням прав користувача.
- Місця вбудовування: окремий розділ аналітики, картка клієнта, вкладка в адмінці — з урахуванням верстки й адаптиву.
- Середовища та експлуатація: скільки контурів, хто власник, як оновлюємо дашборди і що робимо при зміні ключа.
У відповідь ви отримуєте склад вихідних даних із прогалинами, які потрібно закрити, схему потоку авторизації, регламент ротації ключа і відкликання доступу, план робіт за етапами та строки впровадження з контрольними точками.
Опишіть задачу — який продукт, які користувачі, до якої дати потрібен результат. Повернемося з оцінкою та планом.
