Skip to Content
Elido is in closed beta — APIs are stable but rate-limits and quotas may change before GA. Request access →
ПосібникиВласні ролі (RBAC)

Спеціальні ролі

З коробки кожен робочий простір постачається з п’ятьма вбудованими ролями - owner, admin, member, read-only та api-key. Вони охоплюють 80% випадків. Решта 20% - агентства, яким потрібна ізольована звітність для клієнтів, фінансові команди, яким потрібні рахунки без посилань, команди безпеки, яким потрібен лише аудит - отримують політики Cedar  на плані Business+.

Cedar - це мова політик з відкритим кодом, яку опублікувала AWS; ми обрали її, тому що вона текстова, підтримує контроль версій та має формально верифікований оцінювач (evaluator). Політики зчитуються під час запиту з Postgres; оцінювач працює всередині процесу в api-core, тому немає додаткових затримок на захищених кінцевих точках.

1. Анатомія спеціальної ролі

Спеціальна роль - це назва плюс впорядкований список інструкцій Cedar. Кожна інструкція - це permit (дозволити) або forbid (заборонити), обмежена суб’єктом (principal), дією (action) та набором ресурсів (resource set).

// "Переглядач звітів клієнта" - читання кліків лише для одного клієнта
permit (
  principal,
  action in [Action::"analytics.read", Action::"links.list"],
  resource
)
when {
  resource.workspace == "ws_acme_marketing"
};

forbid (
  principal,
  action == Action::"links.create",
  resource
);

Збережіть роль через панель керування або за допомогою API:

curl -X POST \
  https://api.elido.app/v1/workspaces/1/roles \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Client report viewer",
    "policy": "permit ( principal, action in …"
  }'

API перевіряє політику на стороні сервера (парсинг + перевірка типів згідно зі схемою сутностей Elido) перед її збереженням; недійсні політики повертають 422 з вказівкою на помилковий фрагмент.

2. Доступні дії

Простори імен дій збігаються з родинами ресурсів REST:

Простір іменДії
linkscreate, read, list, update, delete, bulk-import
domainsclaim, verify, delete, read
qrscreate, update, read, delete
analyticsread, export, query-clickhouse
membersinvite, remove, change-role
billingread, update-plan, download-invoice
auditread, export
api-keysissue, rotate, revoke, list

Заборона дії має пріоритет над будь-яким дозволом permit - правило Cedar про пріоритет заперечення (deny-takes-precedence) робить ролі «тільки для аудиту» безпечними.

3. Умови

Блоки Cedar when та unless зчитують атрибути сутностей. Схема сутностей Elido надає доступ до таких атрибутів:

{
  "User": ["id", "email", "workspaces", "default_workspace"],
  "Workspace": ["id", "tier", "owner", "created_at"],
  "Link": [
    "id", "workspace", "creator", "tags", "campaign", "created_at"
  ],
  "Domain": ["id", "workspace", "verified", "primary"]
}

Поширені шаблони:

// Надавати доступ лише до посилань, створених суб'єктом
permit (principal, action == Action::"links.update", resource)
when { resource.creator == principal };

// Обмеження за часом - лише для читання поза робочими годинами
permit (principal, action == Action::"links.read", resource)
when {
  context.hour >= 9 && context.hour < 18
};

// Обмеження за тегами - клієнти агентства помічають свої посилання тегом `client:acme`
permit (principal, action in [Action::"links.read", Action::"analytics.read"], resource)
when { "client:acme" in resource.tags };

context містить метадані запиту: hour (UTC), day_of_week, source_ip, user_agent. Корисно для встановлення обмежень для токенів автоматизації.

4. Призначення спеціальної ролі

Ролі призначаються 1:1 учасникам робочого простору або API-ключам:

curl -X PUT \
  https://api.elido.app/v1/workspaces/1/members/usr_8a2f \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -d '{ "role": "Client report viewer" }'

У панелі керування випадаючий список ролей у рядку учасника містить вбудовані ролі плюс кожну спеціальну роль у робочому просторі.

5. Імпорт Cedar

Дві утиліти для управління політиками в масштабі:

  • На рівні робочого простору: кожен робочий простір володіє власними ролями. Імпорт / експорт через GET /v1/workspaces/{id}/roles?format=cedar.
  • Шаблони на рівні організації: на плані Enterprise адміністратор організації може публікувати ролі-шаблони, які успадковує кожен робочий простір - це корисно для контролю SOC 2, який має бути однаковим у всьому портфоліо.
# Отримання всіх ролей робочого простору як зв'язки (bundle) Cedar
curl -H "Authorization: Bearer $ELIDO_TOKEN" \
  "https://api.elido.app/v1/workspaces/1/roles?format=cedar" \
  > roles.cedar

Зв’язка - це звичайний текст, який зручно зберігати в git - перевіряйте diff перед релізом.

6. Особливі випадки

  • Порожній набір дозволів - роль без інструкцій permit не надає нічого. Вбудована роль read-only реалізована саме так (один permit для дій *.read у робочому просторі).
  • Конфліктні ролі через групи SCIM - коли SCIM зіставляє кілька груп з одним користувачем, ролі об’єднуються. Результуюча політика - це об’єднання дозволів permit мінус об’єднання заборон forbid. Журнал аудиту фіксує, з якої групи походить кожна інструкція.
  • Розмір політики - оцінювач Cedar має ліміт у 500 інструкцій на політику; якщо вам потрібно більше, розділіть їх на кілька ролей і призначте одного користувача на декілька з них.

Див. також

SCIM та SSOДокази SOC 2 / HIPAA