У цій статті пояснюється, як працює доступ в Організаціях: що може робити Учасник, на яких облікових записах і що відбувається під час таких дій. Про те, як політики затвердження опрацьовують запити, читайте в розділі Політики, затвердження та управління. Про структуру облікових записів читайте в розділі Облікові записи.
Доступ Учасника складається з двох елементів і визначається третім:
Разом:
Ефективний доступ = один профіль робочого процесу + обʼєднання ролей облікового запису + політика робочого процесу
Ролі та профілі розділені навмисно. Ролі облікового запису привʼязані до конкретних облікових записів; рівні профілю робочого процесу — ні. Якби їх обʼєднали в один пакет, це означало б, що права на затвердження залежать від облікового запису, — але це не так. Учасник, який може затверджувати запити на виведення, робить це в межах усієї Організації.
Дозволи для облікових записів надаються через ролі облікового запису (Account Roles). Кожен дозвіл надається окремо для кожного облікового запису: дозвіл на одному обліковому записі не поширюється на інші.
Прямі дозволи
Вони набирають чинності негайно — без запитів і без затверджень:
Дозвіл | Що дозволяє |
|---|---|
Прочитайте | Перегляд балансів облікового запису, історії торгівлі, записів Леджера та відкритих ордерів |
Торгівля | Розміщення ордерів на обліковому записі та управління ними |
Earn Allocate | Розподіл активів з облікового запису в продукти Earn |
Earn Deallocate | Виведення активів з Earn назад на обліковий запис |
Торгівля на основному обліковому записі охоплює спот і маржу, а на додаткових — лише спот-торгівлю; підтримку маржі для додаткових облікових записів заплановано. Деякі операції — фʼючерси, опції, позабіржова торгівля, конвертація, DeFi Earn та інші — поки не мають дозволів на рівні Організації й залишаються доступними виключно Власнику. Див. Доступність та обмеження.
Дозволи на переміщення коштів
Ці два дозволи працюють інакше: самі по собі вони нічого не надають. Натомість вони визначають, з яких облікових записів Учасник може виводити кошти та здійснювати перекази через процес погодження. Учасник повинен мати Профіль робочого процесу, що дозволяє ініціювати такі операції.
Дозвіл | Що визначає |
|---|---|
Вивести | Облікові записи, з яких Учасник може виводити кошти. Обовʼязково для облікового запису-джерела. |
Перекази | Облікові записи, між якими Учасник може здійснювати перекази. Обовʼязково як для облікового запису-джерела, так і для облікового запису-отримувача. |
Повний опис порядку виконання виведень і переказів див. у розділі Перекази та виведення.
Роль облікового запису — це багаторазовий пакет: набір дозволів для облікового запису, застосованих до певного переліку облікових записів. Роль для торгівлі може надавати дозволи «Читати» та «Торгувати» для облікових записів певного відділу; роль для поповнення рахунку — дозволи «Читати», «Переказ» і «Виведення» для облікових записів Вашої операційної команди. Роль визначається один раз і призначається всім Учасникам, яким вона потрібна.
Різнорідні потреби найкраще покривати двома ролями. Роль застосовує один набір дозволів до своїх облікових записів. Якщо Учаснику потрібно торгувати на одному наборі облікових записів, а переміщувати кошти — на іншому, призначте дві окремі ролі замість однієї змішаної.
Workflow Profile — це управлінська складова доступу Учасника. Для кожного робочого процесу він визначає, які рівні має Учасник:
Рівень | Що дозволяє |
|---|---|
Показати | Переглядати запити та історію робочого процесу |
Ініціювати | Створювати новий запит у робочому процесі |
Схвалити | Схвалювати або відхиляти запити, створені іншими Учасниками |
Виконати | Виконувати запит негайно, якщо це дозволяє політика робочого процесу |
Рівні — це можливості, а не ієрархія:
На двох властивостях варто зупинитися окремо:
Доступні робочі процеси:
Робочий процес | Операції, якими керує процес |
|---|---|
Withdrawal Request | Виведення на зовнішню адресу зі списку дозволених |
Transfer Request | Переказ коштів між обліковими записами Організації |
Manage Team & Access | Запрошення, редагування, деактивація та повторна активація Учасників; призначення та зміна Ролей облікового запису та Профілів робочого процесу |
Manage API Keys | Створення, редагування та відкликання API-ключів |
Управління обліковими записами | Додавання, редагування, вимкнення, увімкнення та видалення облікових записів |
Управління адресами | Додавання та видалення адрес виведення коштів зі списку дозволених |
Управління політиками | Зміна налаштувань політики будь-якого робочого процесу; блокування та розблокування політики для кожного з них |
Адміністрування API-ключів — це окремий робочий процес, відокремлений від «Управління командою та доступом». Ви можете надати учаснику право керувати API-ключами без можливості змінювати доступ інших учасників; ці два робочі процеси можуть мати різні політики затвердження.
Кожна організація одразу отримує набір попередньо визначених системою ролей облікових записів і профілів робочого процесу. Вони охоплюють типові сценарії, тож Ви можете налаштувати команду без створення власних конфігурацій із нуля, а також слугують готовими прикладами для розробки власної системи управління.
Попередньо визначені ролі облікових записів
Роль | Що надає |
|---|---|
Повний доступ | Усі дозволи облікового запису на всіх поточних і майбутніх облікових записах |
Trade all | Торгівля на всіх поточних і майбутніх облікових записах |
Funds all | Операції з коштами — переказ, виведення, розподіл через Earn, виведення з розподілу Earn — на всіх поточних і майбутніх облікових записах |
Read all | Доступ лише для читання на всіх поточних і майбутніх облікових записах |
Системні ролі охоплюють усі поточні та майбутні облікові записи: учасник із роллю «Trade all» зможе торгувати на обліковому записі, створеному завтра, без будь-якого коригування доступу. Також можна створити користувацьку роль, обмежену конкретним і фіксованим переліком облікових записів.
Системні профілі та ролі не можна редагувати або видаляти. Проте будь-який із них можна клонувати та змінити копію відповідно до потреб Вашої організації.
Системні профілі робочих процесів
Профіль | Що включає |
|---|---|
Адміністратор | Усі рівні в кожному робочому процесі, зокрема Execute. Призначається власнику організації під час її створення. |
Ініціатор | View та Initiate в кожному робочому процесі. Не може затверджувати запити. |
Approver | View та Approve в кожному робочому процесі. Не може ініціювати запити. |
Funds Manager | View, Initiate та Approve для Withdrawal Request і Transfer Request. View та Initiate для Manage Addresses. Жодного рівня для Manage Team & Access, Manage API Keys, Manage Accounts і Manage Policies. |
Auditor | Може переглядати запити та історію в кожному робочому процесі, але не може нічого ініціювати або затверджувати. |
Профіль із рівнем Initiate або Execute для Withdrawal Request повинен також мати рівень View для Manage Addresses. Це робить доступ до білого списку адрес виведення коштів Організації видимим у конфігурації профілю. Рівень View для Manage Addresses не надає дозволу на ініціювання або схвалення змін адрес.
Funds Manager може запропонувати нову або замінну адресу виведення коштів, але не може схвалювати зміни адрес. Це гарантує, що схвалення зміни адреси залишається незалежним від особи, яка надалі може ініціювати або схвалювати виведення коштів на неї.
Профілі Initiator, Approver та Auditor відповідають трьом ролям у процесі перевірки: тих, хто пропонує, тих, хто затверджує, і тих, хто здійснює нагляд. Funds Manager — це профіль для щоденної роботи операторів, які керують переміщенням коштів і можуть пропонувати потрібні їм адреси призначення.
Ефективний доступ Учасника визначається призначеними Workflow Profile та Account Roles, а також поточною політикою для кожного робочого процесу.
Попередній перегляд також позначає комбінації, які надають менше доступу, ніж здається, — наприклад, роль із дозволом Withdraw для облікового запису в поєднанні з профілем, який не може ініціювати Withdrawal Requests. Жоден із дозволів не є хибним, але разом вони ще не дають Учаснику можливості виводити кошти — попередній перегляд відображає цей стан до збереження.
Подальша зміна доступу Учасника виконується за тим самим порядком і тими самими правилами управління, що й первинне призначення.
Withdraw — це дозвіл на рівні облікового запису, який визначає, з яких облікових записів Учасник може виводити кошти, за умови що йому призначено Workflow Profile із правом ініціювати запити на виведення коштів. Перевірте їхній профіль: необхідний рівень Initiate (або Execute) для робочого процесу Withdrawal Request. Попередній перегляд ефективного доступу на сторінці Учасника показує результат цього розвʼязання для кожного облікового запису.
Так і задумано — саме так працює рівень Approve. Рівні Workflow Profile поширюються на всі облікові записи Організації. Учасник із рівнем Approve для запитів на виведення може схвалювати будь-який такий запит. Поточна модель не підтримує права на схвалення в межах окремого облікового запису.
Так і задумано. Ролі — це активні ресурси: кожен учасник, якому призначено роль, успадковує всі дозволи, що вона надає. Коли Ви редагуєте роль, крок підтвердження показує, як зміниться доступ учасників, ще до збереження змін. Щоб змінити доступ лише одного учасника, створіть і призначте нову роль замість редагування спільної.
Кожен учасник може мати лише один Workflow Profile. Якщо жоден наявний профіль не підходить, створіть власний із потрібним набором рівнів і призначте його.
Учасники мають бачити облікові записи, з якими працюють, тому ролі з правом торгувати зазвичай включають право Read на ті самі облікові записи. Щоб обмежити видимість учасника на інших облікових записах, звузьте перелік облікових записів у його ролях, а не дозволи всередині облікового запису.