AiHummer защищает свою административную поверхность с помощью ролевого контроля
доступа (RBAC) и scoped API-ключей. Роли определяют, кем человеку
разрешено быть; scoped-ключи позволяют выдать части автоматизации ровно те
привилегии, которые ей реально нужны, вместо ключа, который может всё.
Роли
Доступ к admin API и веб-админке управляется ролями. Роль определяет, какие
группы ресурсов принципал может просматривать и какие — изменять. Сочетайте роли
с остальными механизмами этого раздела —
IP-allowlist,
корпоративным SSO и
журналом аудита — чтобы каждое
административное действие было и авторизовано, и зафиксировано.
Scoped admin API-ключи
Admin API-ключи несут scopes, ограничивающие то, что ключ может делать. Есть
три scope:
Scope
Даёт
admin:read
Доступ только на чтение к admin-ресурсам (просмотр настроек, диалогов, аналитики и т.д.).
admin:write
Доступ на чтение и запись к admin-ресурсам.
admin:*
Полный административный доступ (эквивалент всех admin-scope).
Scopes были введены миграцией 0073. Существующие ключи продолжают работать;
новые ключи можно выпускать с узким scope, чтобы, например, дашборд, который
только читает метрики, никогда не держал ключ, способный менять настройки.
[!TIP]
Применяйте наименьшие привилегии: интеграция для мониторинга или отчётности
должна получать ключ admin:read, а не admin:write или admin:*.
Оставляйте admin:* для ключей, которым действительно нужно изменять все
группы ресурсов.
Выбор правильного scope
Интеграции только на чтение (дашборды, экспортёры, проверки статуса) →
admin:read.
Автоматизация, создающая или меняющая ресурсы (агенты провижининга,
импорт знаний, управление расписаниями) → admin:write.
Break-glass / полное администрирование → admin:*, у как можно меньшего
числа ключей и с регулярной ротацией.
[!WARNING]
Scoped-ключ — это всё равно доступ к admin API. Храните его в
vault для секретов или в своём менеджере секретов,
никогда в системе контроля версий, и ротируйте, если он мог быть раскрыт.
Как управляются ключи
Admin API-ключи управляются через admin API (/v1/admin/apikeys) и веб-админку,
где вы выпускаете ключ, назначаете ему scope и отзываете, когда он больше не
нужен. Поскольку сам admin API защищён
OIDC и IP-allowlist, выпуск ключа — это
аутентифицированная и аудируемая операция.
Куда дальше
Корпоративный SSO — аутентификация людей за
ролями через SAML, LDAP, SCIM или OIDC.
AiHummer защищает свою административную поверхность с помощью **ролевого контроля
доступа (RBAC)** и **scoped API-ключей**. Роли определяют, кем человеку
разрешено быть; scoped-ключи позволяют выдать части автоматизации ровно те
привилегии, которые ей реально нужны, вместо ключа, который может всё.
## Роли
Доступ к admin API и веб-админке управляется ролями. Роль определяет, какие
группы ресурсов принципал может просматривать и какие — изменять. Сочетайте роли
с остальными механизмами этого раздела —
[IP-allowlist](/v1.0/security/network-audit-airgapped),
[корпоративным SSO](/v1.0/security/enterprise-sso) и
[журналом аудита](/v1.0/security/network-audit-airgapped) — чтобы каждое
административное действие было и авторизовано, и зафиксировано.
## Scoped admin API-ключи
Admin API-ключи несут **scopes**, ограничивающие то, что ключ может делать. Есть
три scope:
| Scope | Даёт |
|---|---|
| `admin:read` | Доступ только на чтение к admin-ресурсам (просмотр настроек, диалогов, аналитики и т.д.). |
| `admin:write` | Доступ на чтение **и** запись к admin-ресурсам. |
| `admin:*` | Полный административный доступ (эквивалент всех admin-scope). |
Scopes были введены **миграцией 0073**. Существующие ключи продолжают работать;
новые ключи можно выпускать с узким scope, чтобы, например, дашборд, который
только читает метрики, никогда не держал ключ, способный менять настройки.
> [!TIP]
> Применяйте наименьшие привилегии: интеграция для мониторинга или отчётности
> должна получать ключ `admin:read`, а не `admin:write` или `admin:*`.
> Оставляйте `admin:*` для ключей, которым действительно нужно изменять все
> группы ресурсов.
## Выбор правильного scope
- **Интеграции только на чтение** (дашборды, экспортёры, проверки статуса) →
`admin:read`.
- **Автоматизация, создающая или меняющая ресурсы** (агенты провижининга,
импорт знаний, управление расписаниями) → `admin:write`.
- **Break-glass / полное администрирование** → `admin:*`, у как можно меньшего
числа ключей и с регулярной ротацией.
> [!WARNING]
> Scoped-ключ — это всё равно доступ к admin API. Храните его в
> [vault для секретов](/v1.0/security/vault) или в своём менеджере секретов,
> никогда в системе контроля версий, и ротируйте, если он мог быть раскрыт.
## Как управляются ключи
Admin API-ключи управляются через admin API (`/v1/admin/apikeys`) и веб-админку,
где вы выпускаете ключ, назначаете ему scope и отзываете, когда он больше не
нужен. Поскольку сам admin API защищён
[OIDC и IP-allowlist](/v1.0/security/enterprise-sso), выпуск ключа — это
аутентифицированная и аудируемая операция.
## Куда дальше
- [Корпоративный SSO](/v1.0/security/enterprise-sso) — аутентификация людей за
ролями через SAML, LDAP, SCIM или OIDC.
- [Сеть, аудит и air-gapped](/v1.0/security/network-audit-airgapped) —
ограничьте, откуда доступен admin API, и ведите журнал аудита.
- [Vault для секретов](/v1.0/security/vault) — где хранить выпущенные ключи.
AiHummer