Справка CDN.com.tr

Роли команды: просмотрщик, редактор и владелец

Дайте каждому коллеге собственный логин и минимальную роль, которая позволяет выполнять его работу. Та же роль применяется и в API, поэтому bearer-токен никогда не может сделать больше, чем позволено человеку, которому он принадлежит.

Организация, права доступа, поддержка

Роли команды: просмотрщик, редактор и владелец

Для чего нужны роли

Роли и журнал активности — это одна и та же функция с двух сторон: одна ограничивает, что может произойти, другая фиксирует, что произошло.

Запись

Activity history

Кто что изменил, со значениями до и после — читаемо только потому, что у каждого человека свой логин.

Открыть раздел

Сама страница

Sub-users and permissions

Создание, обновление и деактивация пользователей, к которым привязаны эти роли.

Открыть раздел

Контекст

CDN activity log and team roles

Минимальные привилегии и журнал аудита как единое требование и как ответить на него в тендере.

Читать руководство

Путь в панели

Management Panel
Authorization
Create New User
Role

Предварительные требования

Только владелец аккаунта может создавать суб-пользователей и назначать роли.
Каждому человеку нужен собственный email-адрес; журнал аудита ничего не стоит, если двое пользуются одним.
Определите роль до создания пользователя — это проще, чем объяснять пробел в правах позже.

Модель принятия решений

Какая роль нужна этому человеку?

Выбирайте по минимуму, необходимому для снятия блокировки, а не по должности.

Viewer: отчётность, мониторинг, агентство, которое только читает цифры потребления и кеша.
Editor: разработчик или публикатор, который очищает кеш после деплоя, редактирует правила доставки и управляет DNS и сертификатами.
Owner: вы и любой, кому вы доверили бы биллинг и добавление других пользователей.

Один логин или по одному на человека?

Этот выбор определяет, сможет ли журнал аудита вообще ответить на вопрос.

По одному логину на человека: каждая строка в Activity history называет реального человека.
Общий логин: все действия выглядят одинаково, а удаление одного человека означает смену пароля для всех.

Пошаговое руководство

Создайте пользователя

Authorization — это страница, которой принадлежат суб-пользователи всего клиента целиком, а не отдельного аккаунта.

Откройте Authorization и нажмите Create New User.
Заполните имя, фамилию, email, телефон и пароль дважды.
Пока не отправляйте форму — таблица ролей находится внизу той же формы.

Ожидаемый результат: Форма нового пользователя заполнена, и под полями пароля видна таблица ролей.

cdnctl equivalent

POST /api/subusers

Назначьте роль

Таблица ролей перечисляет роли с переключателем неактивно/активно у каждой. Включите ту, что нужна этому человеку.

Включите Viewer (read-only) для того, кто только читает отчёты.
Включите Editor для того, кто очищает кеш или редактирует правила доставки, DNS или сертификаты.
Оставьте всё выключенным, только если хотите получить просмотрщика — именно к этому сводится пустая роль.
Нажмите Create User.

Ожидаемый результат: Пользователь создан ровно с той ролью, которую вы выбрали, и может войти под собственными учётными данными.

cdnctl equivalent

GET /api/roles

Убедитесь, что граница соблюдается

Проверяйте с нового аккаунта, а не со своего. Это двухминутная проверка, которая предотвращает неприятный сюрприз.

Попросите человека войти и открыть нужные ему страницы.
Попросите просмотрщика попробовать что-то сохранить и убедитесь, что ему отказано.
Откройте Activity history и убедитесь, что его действия записаны под его собственным именем.

Ожидаемый результат: Человек может выполнять свою работу, заблокирован для всего остального, и каждое его действие можно проследить.

cdnctl equivalent

GET /api/accounts/<account_uuid>/activities?per_page=25

Проверка

Просмотрщик может открыть любую страницу, но не может ничего сохранить, кроме собственного профиля и пароля.
Редактор может очищать кеш и редактировать правила доставки, но не имеет действий с суб-пользователями или биллингом.
Токен, выданный суб-пользователю, отклоняется на эндпоинтах, не покрываемых его ролью.
После изменения, внесённого суб-пользователем, Activity history называет именно его, а не владельца.

Сценарии использования

Над одним CDN-аккаунтом работают два-три человека: один публикует контент и должен уметь очищать кеш, другой только читает отчёты, а добавлять пользователей и трогать биллинг должны иметь право только вы. Общий пароль даёт всем троим одинаковую власть и делает журнал аудита бесполезным.

Краткий порядок действий

Откройте Authorization и создайте пользователя для каждого человека вместо использования одного общего логина.
Задайте роль новому пользователю: viewer для доступа только на чтение, editor для повседневных операций, owner для полного контроля.
Попросите человека войти и убедиться, что он может выполнять свою работу и не больше.
После этого проверьте Activity history: его действия теперь отображаются под его собственным именем.

Проверки

Viewer: читает каждую страницу и может менять свой собственный профиль и пароль. Никаких других записей.
Editor: очистка кеша, правила доставки, DNS, сертификаты и хосты. Без управления суб-пользователями, без биллинга, без удаления аккаунта.
Owner: всё, включая пользователей и биллинг. Это роль, с которой аккаунт был зарегистрирован.
Если оставить роль пустой, пользователь становится просмотрщиком. Новый пользователь никогда не создаётся с бо́льшими правами, чем вы предоставили.
API применяет те же правила. Токен просмотрщика не может писать, а токен редактора отклоняется на эндпоинтах, доступных только владельцу.