AiHummer
Беларуская▾
УвайсціАсабісты кабінет
v1.2.x▾
v1.2.xstablev1.1.xstablev1.0.xstable
{ }Swagger
Бяспека/RBAC і спецыфічныя ключы API

RBAC і спецыфічныя ключы API

v1.2.x · абноўлена 2026-07-07

AiHummer абараняе сваю адміністрацыйную паверхню з дапамогай кіраванне доступам на аснове роляў і ключы API з абмежаваным доступамРолі вызначаюць, кім можа быць чалавек; скопаваныя ключы дазваляюць надаць аўтаматызацыі толькі неабходныя прывілеі замест ключа, які можа ўсё.

Ролі

Доступ да адміністрацыйнага API і адміністрацыйнага інтэрфейсу кіруецца ролямі. Роля вызначае, якія групы рэсурсаў можа праглядаць і змяняць прынцыпалы.

Ролі кіруюцца праз адміністрацыйны інтэрфейс Ролі старонка. З каробкі ёсць ўбудаваныя ролі — owner (усё) admin, operator і member — якія толькі для чытання (пазначаныя значком «Убудаваныя»; іх нельга рэдагаваць або выдаляць). Па-за гэтымі вы можаце ствараць індывідуальныя роліформа ролі ўключае імя, апісанне і сетку дазволаў — чытанне/запіс выключальнікаў для кожнага з прыкладна 19 рэсурсных даменаў (агенты, размовы, інструменты, сакрэты, убудовы, налады, адабрэнні, ключы API і гэтак далей; «запісваць» аўтаматычна азначае «чытаць»). Кожная роля паказвае, колькі суб’ектаў яе выкарыстоўваюць; роля, прызначаная камусьці, не можа быць выдаленая, пакуль прызначэнні не будуць выдалены.

Спалучайце ролі з іншымі элементамі кіравання на гэтым сайце — Белы спіс IP, карпаратыўны SSO і журнал аўдыту — каб кожнае дзеянне адміністратара было як аўтарызаваным, так і зарэгістраваным.

API-ключы з абмежаваным доступам

Ключы API нясуць аб’ектывы якія абмяжоўваюць магчымасці ключа. Вызначаныя сферы дзейнасці:

Сфера Гранты
chat Канчатковы пункт сумяшчальны з OpenAI (папулярны стандартны варыянт для існуючых ключоў).
admin:read Доступ толькі для чытання да рэсурсаў адміністратара (GET /v1/admin/*наладкі, размовы, аналітыка і г.д.
admin:write Мутацыя выклікаў адміністрацыйнага API (POST/PUT/DELETE /v1/admin/*).
mcp Апублікаваны канец MCP (POST /v1/mcp).
a2a Апублікаваны канчатковы пункт Agent-to-Agent(POST /a2a/message).
* Поўны доступ да ўсяго (сапраўдны поўны доступ).

Акрамя таго, агульны <area>:* працоўныя сімвалы: admin:*, напрыклад, гранты кожная дзеянне адміністратара але робіць не грант chat, mcp ці a2a — гэта не асобна вызначаная сфера, проста выпадак выкарыстання сімвала-замяшчальніка. Толькі * прадастаўляе поўны доступ да ўсіх паверхняў.

Ключы, створаныя да з’яўлення область дзеяння, працягваюць працаваць без абмежаванняў; новыя ключы могуць быць створаныя з вузкай область дзеяння, каб, напрыклад, панэль кіравання, якая толькі чытае метрыкі, ніколі не мела ключа, які мог бы змяняць налады.

[!TIP] Прымяняйце прынцып мінімальных правоў: інтэграцыя для маніторынгу або справаздачнасці павінна мець admin:read ключ, не admin:write — не кажучы ўжо пра *. Рэзерв * для ключоў якія сапраўды патрэбуюць доступу да ўсіх паверхняў.

Выбар правільнага прыцэлу

  • Кліенты чата (выклік сумяшчальнага з OpenAI канцавага пункту) → chat.
  • Толькі для чытання інтэграцыі (панэлі кіравання, экспарцёры, праверкі стану) → admin:read.
  • Аўтаматызацыя, якая стварае або рэдагуе рэсурсы (пастаўшчыкі, імпарт веды, кіраванне раскладамі) → admin:write.
  • Кліенты MCP і A2A → mcp і a2a адпаведна.
  • Зламаць шкло / поўны доступ → *, утрымліваемы як мага меншай колькасцю клавіш і рэгулярна паварочваліся

[!WARNING] Ключ з абсягам па-ранейшаму з’яўляецца ўліковымі дадзенымі для адміністрацыйнага API. Захоўвайце яго ў сховішча сакрэтаў ці ваш уласны сакрэтны менеджар, ніколі ў крыніца кантролю, і вярціце яе, калі яна магла быць падвергнута ўздзеянню.

Як кіруюцца ключы

Ключы адміністратара API кіруюцца праз адміністрацыйны API (/v1/admin/apikeys) і адміністрацыйны інтэрфейс, дзе вы ствараеце ключ, прызначаеце яго сферу дзеяння і анулюеце яго, калі ў гэтым больш няма патрэбы. Паколькі сам адміністрацыйны API абаронены OIDC і белы спіс IP, выпуск ключа з’яўляецца аўтэнтыфікаванай, прааудзіранай аперацыяй.

Куды далей