AiHummer պաշտպանում է իր վարչական միջավայրը օգտագործելով հաղորդակցման հասանելիության կառավարում՝ զանգվածված դերերով և սահմանափակված API բանալիներԴերերը որոշում են, թե մարդն ինչ կարող է լինել; սահմանափակ բանալիները թույլ են տալիս ավտոմատացման տարրին տրամադրել միայն այն արտոնությունները, որոնք նրան իսկապես անհրաժեշտ են, այլ ոչ թե բանալի, որը կարող է անել ամեն ինչ:
Ռոլեր
Մտք նարվածությունը վարչական API-ին և վարչական ինտերֆեյսին կարգավորվում է դերերով։ Դերը սահմանում է, թե որ ռեսուրսային խմբերը կարող է դիտել սուբյեկտը և որոնք կարող է փոփոխել։
Դերը կառավարվում են ադմինիստրատորի ինտերֆեյսում Ռոլեր էջ. Փաթեթից կա ներառված դերեր — owner (բոլորը), admin, operator և member — որոնք մատչելի են միայն ընթերցանության համար (նշված են «Ներկառուցված» ինդիկատորով; դրանք հնարավոր չէ խմբագրել կամ ջնջել): Ինքնուրույն դրանց զուգահեռ կարող եք ստեղծել օգտվողի դերեր: դերի ձևը ընդունում է անունը, նկարագրությունը և թույլտվությունների ցանցը — կարդալ/գրել դրոշակները ամեն մի ~19 ռեսուրսների ոլորտի համար (գործակալներ, զրույցներ, գործիքներ, գաղտնիքներ, հավելվածներ, կարգավորումներ, հաստատումներ, API բանալիներ և այլն; «գրանցում» ավտոմատ կերպով ենթադրում է «կարդալը»): Յուրաքանչյուր դերը ցույց է տալիս, թե քանի սուբյեկտ կարող են այն օգտագործել; դերը, որը հանդիսանում է Ուժի մեջը նշանակված որևէ մարդուց հնարավոր չէ հեռացնել, մինչ նշանակումները չվերացվեն։
Լրիվ հասանելիություն ամեն ինչին (իրական լրիվ հասանելիության ծավալը)։
Ընդհանուր առմամբ <area>:* աշխատում է փոխարինող խորհրդանիշը: admin:*, օրինակ, գրանտներ յուրքանչյուր ադմին գործողություն բայց անում է ոչ տալ, տրամադրել chat, mcp կամ a2a — սա առանձին սահմանված ոլորտ չէ, պարզապես դեպք է ընդհանուր նշանի հետ։ Մատյան միայն * տրամադրում է լիակատար հասանելիություն բոլոր մակերեսներին։
Բանալիները, ստեղծված նախքան ֆոլդերների ստեղծվելը, շարունակում են գործել առանց սահմանափակումների; նոր բանալիները կարող են ստեղծվել օղակավորված ընդամենից, այնպես որ, օրինակ, վահանակը, որը միայն կարդում է մետրիկաները, երբևէ չի ունենա բանալի, որը կարող է փոփոխել կարգավորումներն:
[!TIP]
Օգտագործեք նվազագույն արտոնությունների սկզբունքը՝ մոնիտորինգի կամ հաշվետվությունների ինտեգրացիան պետք է ստանա
admin:read բացի, ոչ admin:write — չխոսելով դեռևս *. Ռեզերվ * բացի համար
որոնք իսկապես անհրաժեշտություն ունեն մուտք ունենալ բոլոր մակերեսներին:
Միացումներ միայն կարդալու համար (կառավարիչ վահանակներ, արտահանողներ, վիճակային ստուգումներ) →
admin:read.
Ավտոմատացում, որը ստեղծում կամ խմբագրում է ռեսուրսները (ապահովման գործակալի, ներմուծում)
իմացություններ, ժամանակացույցերի կառավարում) → admin:write.
MCP-ի և A2A-ի հաճախորդներ → mcp և a2a համապատասխանաբար.
Կոտրել ապակին / լիակատար հասանելիություն → *, որքան հնարավոր է քիչ բանալիերով պահված և
ոնկայաբար պտտվում էր։
[!WARNING]
Scoped-կոճակը դեռևս հանդիսանում է վարչական API-ի հավատարմագրերը: Պահպանեք այն
սպառազինության պահոց կամ ձեր սեփական գաղտնիքների մենեջերը, երբեք
կառավարեք աղբյուրը և փոխարինեք այն, եթե այն հնարավոր է ենթակա եղել ազդեցության:
Ինչպես են կառավարվում բանալիները
Admin API-ի բանալիները կառավարվում են admin API-ի միջոցով (/v1/admin/apikeys) և վարչարարական միջերես, որտեղ դուք ստեղծում եք բանալին, սահմանում նրա օգտագործման կարգը և վերցնում այն հետ, երբ այն այլևս պետք չէ: Քանի որ վարչարարական API-ն ինքնին պաշտպանված է OIDC և IP հասցեների սպիտակ ցուցակ, բանալիի ստեղծումը ավտենտիկացված, հաստատված գործողություն է:
Որտեղից հետո
Կորպորատիվ SSO — աուտենտիֆիկացնել մարդկանց
ռոլերից՝ օգտագործելով SAML, LDAP, SCIM կամ OIDC:
Ցանց, աուդիտ և մեկուսացված —
սահմանափակել, թե որտեղ կարելի է հասնել ադմինիստրատորի API-ին և պահպանել նարկիտի ակունքի հետագիծը:
AiHummer պաշտպանում է իր վարչական միջավայրը օգտագործելով **հաղորդակցման հասանելիության կառավարում՝ զանգվածված դերերով** և **սահմանափակված API բանալիներ**Դերերը որոշում են, թե մարդն ինչ կարող է լինել; սահմանափակ բանալիները թույլ են տալիս ավտոմատացման տարրին տրամադրել միայն այն արտոնությունները, որոնք նրան իսկապես անհրաժեշտ են, այլ ոչ թե բանալի, որը կարող է անել ամեն ինչ:
## Ռոլեր
Մտք նարվածությունը վարչական API-ին և վարչական ինտերֆեյսին կարգավորվում է դերերով։ Դերը սահմանում է, թե որ ռեսուրսային խմբերը կարող է դիտել սուբյեկտը և որոնք կարող է փոփոխել։
Դերը կառավարվում են ադմինիստրատորի ինտերֆեյսում **Ռոլեր** էջ. Փաթեթից կա **ներառված դերեր** — `owner` (բոլորը), `admin`, `operator` և `member` — որոնք մատչելի են միայն ընթերցանության համար (նշված են «Ներկառուցված» ինդիկատորով; դրանք հնարավոր չէ խմբագրել կամ ջնջել): Ինքնուրույն դրանց զուգահեռ կարող եք ստեղծել **օգտվողի դերեր**: դերի ձևը ընդունում է անունը, նկարագրությունը և թույլտվությունների ցանցը — **կարդալ/գրել դրոշակները** ամեն մի ~19 ռեսուրսների ոլորտի համար (գործակալներ, զրույցներ, գործիքներ, գաղտնիքներ, հավելվածներ, կարգավորումներ, հաստատումներ, API բանալիներ և այլն; «գրանցում» ավտոմատ կերպով ենթադրում է «կարդալը»): Յուրաքանչյուր դերը ցույց է տալիս, թե քանի սուբյեկտ կարող են այն օգտագործել; դերը, որը հանդիսանում է Ուժի մեջը նշանակված որևէ մարդուց հնարավոր չէ հեռացնել, մինչ նշանակումները չվերացվեն։
Միացրեք դերերը այս կայքի մյուս կառավարման տարրերի հետ — [Թույլտվրված IP հասցեների ցուցակ](/hy/v1.0/security/network-audit-airgapped), [կորպորատիվ SSO](/hy/v1.0/security/enterprise-sso) և [գնահատման ամսաթիվագիր](/hy/v1.0/security/network-audit-airgapped) — որպեսզի յուրաքանչյուր ադմինիստրատորի գործողություն լինի և՛ թույլատրված, և՛ փաստագրված:
## API բանալիներ սահմանափակ գործառույթով
API բանալիները կրում են **նպատակակետեր** որոնք սահմանափակում են բանալիի հնարավորությունները: Նշվյալ կիրառման ոլորտները՝
| Տարածաշրջան | Գրանտներ |
|---|---|
| `chat` | OpenAI-ի վերջնական կետը վերջնական օգտատիրոջ համար (հին ստանդարտը առկա բանալիների համար): |
| `admin:read` | Մուտք միայն կարդալու համար ադմինիստրատորի ռեսուրսներին (`GET /v1/admin/*`: կարգավորումներ, զրույցներ, վերլուծություններ և այլն). |
| `admin:write` | Ադմինիստրատիորի API կանչերի մուտացիա (`POST`/`PUT`/`DELETE /v1/admin/*`). |
| `mcp` | Հրատարակված վերջնական կետը MCP (`POST /v1/mcp`). |
| `a2a` | Հրապարակված վերջնակետը Ագենտից Ագենտին (`POST /a2a/message`). |
| `*` | Լրիվ հասանելիություն ամեն ինչին (իրական լրիվ հասանելիության ծավալը)։ |
Ընդհանուր առմամբ `<area>:*` աշխատում է փոխարինող խորհրդանիշը: `admin:*`, օրինակ, գրանտներ **յուրքանչյուր ադմին գործողություն** բայց անում է **ոչ** տալ, տրամադրել `chat`, `mcp` կամ `a2a` — սա առանձին սահմանված ոլորտ չէ, պարզապես դեպք է ընդհանուր նշանի հետ։ Մատյան միայն `*` տրամադրում է լիակատար հասանելիություն բոլոր մակերեսներին։
Բանալիները, ստեղծված նախքան ֆոլդերների ստեղծվելը, շարունակում են գործել առանց սահմանափակումների; նոր բանալիները կարող են ստեղծվել օղակավորված ընդամենից, այնպես որ, օրինակ, վահանակը, որը միայն կարդում է մետրիկաները, երբևէ չի ունենա բանալի, որը կարող է փոփոխել կարգավորումներն:
> [!TIP]
> Օգտագործեք նվազագույն արտոնությունների սկզբունքը՝ մոնիտորինգի կամ հաշվետվությունների ինտեգրացիան պետք է ստանա
> `admin:read` բացի, ոչ `admin:write` — չխոսելով դեռևս `*`. Ռեզերվ `*` բացի համար
> որոնք իսկապես անհրաժեշտություն ունեն մուտք ունենալ բոլոր մակերեսներին:
## Ճիշտ օբյեկտիվի ընտրություն
- **Չաթ հաճախորդներ** (համատեղելի OpenAI վերջակետին զանգ) → `chat`.
- **Միացումներ միայն կարդալու համար** (կառավարիչ վահանակներ, արտահանողներ, վիճակային ստուգումներ) →
`admin:read`.
- **Ավտոմատացում, որը ստեղծում կամ խմբագրում է ռեսուրսները** (ապահովման գործակալի, ներմուծում)
իմացություններ, ժամանակացույցերի կառավարում) → `admin:write`.
- **MCP-ի և A2A-ի հաճախորդներ** → `mcp` և `a2a` համապատասխանաբար.
- **Կոտրել ապակին / լիակատար հասանելիություն** → `*`, որքան հնարավոր է քիչ բանալիերով պահված և
ոնկայաբար պտտվում էր։
> [!WARNING]
> Scoped-կոճակը դեռևս հանդիսանում է վարչական API-ի հավատարմագրերը: Պահպանեք այն
> [սպառազինության պահոց](/hy/v1.0/security/vault) կամ ձեր սեփական գաղտնիքների մենեջերը, երբեք
> կառավարեք աղբյուրը և փոխարինեք այն, եթե այն հնարավոր է ենթակա եղել ազդեցության:
## Ինչպես են կառավարվում բանալիները
Admin API-ի բանալիները կառավարվում են admin API-ի միջոցով (`/v1/admin/apikeys`) և վարչարարական միջերես, որտեղ դուք ստեղծում եք բանալին, սահմանում նրա օգտագործման կարգը և վերցնում այն հետ, երբ այն այլևս պետք չէ: Քանի որ վարչարարական API-ն ինքնին պաշտպանված է [OIDC և IP հասցեների սպիտակ ցուցակ](/hy/v1.0/security/enterprise-sso), բանալիի ստեղծումը ավտենտիկացված, հաստատված գործողություն է:
## Որտեղից հետո
- [Կորպորատիվ SSO](/hy/v1.0/security/enterprise-sso) — աուտենտիֆիկացնել մարդկանց
ռոլերից՝ օգտագործելով SAML, LDAP, SCIM կամ OIDC:
- [Ցանց, աուդիտ և մեկուսացված](/hy/v1.0/security/network-audit-airgapped) —
սահմանափակել, թե որտեղ կարելի է հասնել ադմինիստրատորի API-ին և պահպանել նարկիտի ակունքի հետագիծը:
- [Գաղտնիքների պահոց](/hy/v1.0/security/vault) — որտեղ պահել բանալիները, որոնք դուք ստեղծում եք.