Права и роли для MCP: сопоставление доступа команды с действиями инструментов

Спроектируйте ролевую модель доступа (RBAC) для использования MCP в вашей команде. Это практическое руководство охватывает определения ролей, сопоставление прав, процессы одобрения и примеры для разных ролей в команде.

Основные определения ролей

Роль «Наблюдатель»

Права наблюдателя

Назначение: доступ только для чтения для участников команды, которым нужна видимость, но не следует вносить изменения

Может использовать: list_tasks, get_task, list_projects, get_project, list_boards, get_board, list_task_comments, get_tracking_status
Не может использовать: create_task, update_task, delete_task, add_task_comment, start_time_tracking, stop_time_tracking
Сценарий использования: заинтересованные стороны, руководители, внешние консультанты

Роль «Участник»

Права участника

Назначение: стандартный доступ участника команды для повседневной работы

Может использовать: все права наблюдателя + create_task, update_task (собственные задачи), add_task_comment, start_time_tracking, stop_time_tracking
Не может использовать: delete_task, update_task (чужие задачи без одобрения), update_project (настройки)
Сценарий использования: индивидуальные исполнители, разработчики, дизайнеры

Роль «Администратор»

Права администратора

Назначение: полный доступ для тимлидов и менеджеров

Может использовать: все права участника + delete_task, update_task (любая задача), update_project, управление досками
Требует одобрения: массовые операции, удаление проектов, настройки рабочего пространства
Сценарий использования: тимлиды, менеджеры проектов, инженерные менеджеры

Матрица прав

Доступ к инструментам по ролям

Инструмент	Наблюдатель	Участник	Администратор
list_tasks	✓	✓	✓
get_task	✓	✓	✓
create_task	✗	✓	✓
update_task (свои)	✗	✓	✓
update_task (любые)	✗	✗	✓
delete_task	✗	✗	✓*
add_task_comment	✗	✓	✓
start_time_tracking	✗	✓	✓

* Операции удаления администратором всё равно должны требовать подтверждения

Процессы одобрения

Одобрение для чувствительных действий

Даже при наличии соответствующих прав некоторые действия должны требовать дополнительного одобрения:

Действия, требующие одобрения

Операции удаления: всегда требуют токен подтверждения
Массовые обновления: требуют предпросмотра и одобрения при более чем 5 элементах
Смена статуса на «done»: требует подтверждения
Изменения на уровне проекта: требуют одобрения менеджера
Учёт времени по чужим задачам: требует явного разрешения

Пример паттерна одобрения

Удаление с одобрением

"Удали задачу '[ID задачи]' из Workify: 1. Сначала получи детали задачи и покажи мне, что будет удалено 2. Покажи мне предупреждение, что это действие необратимо 3. Потребуй, чтобы я ввёл точный токен подтверждения 'DELETE-TASK-2026' 4. Только после того, как я введу токен, удали задачу 5. Если я не введу токен, ничего не удаляй"

Этот паттерн: показывает предпросмотр, требует явный токен, предотвращает случайное удаление

Примеры ролей по командам

Инженерная команда

Сопоставление ролей в инженерной команде

Junior-разработчик: Участник (может создавать/обновлять свои задачи, учитывать время)
Senior-разработчик: Участник (те же права, больше опыта в рабочих процессах)
Тимлид: Администратор (может управлять задачами команды, обновлять настройки проекта)
Инженерный менеджер: Администратор (полный доступ, управляет несколькими проектами)

Продуктовая команда

Сопоставление ролей в продуктовой команде

Продуктовый дизайнер: Участник (может создавать задачи по дизайну, обновлять статус)
Продакт-менеджер: Администратор (может управлять бэклогом продукта, приоритизировать задачи)
Владелец продукта: Администратор (полный доступ к продуктовым проектам)

Операционная команда

Сопоставление ролей в операционной команде

Агент поддержки: Участник (может создавать тикеты, обновлять статус, добавлять заметки)
Инженер по эксплуатации: Администратор (может управлять операционными задачами, обновлять регламенты)
Заинтересованная сторона: Наблюдатель (доступ только для чтения к статусу проекта)

Внедрение RBAC

Шаг 1: Определите роли

Чек-лист определения ролей

Перечислите все роли в вашей организации
Сопоставьте каждую роль с Наблюдателем, Участником или Администратором
Выявите любые необходимые кастомные права
Задокументируйте обязанности ролей

Шаг 2: Назначьте права

Назначение прав

Создайте API-ключи с соответствующими правами в Workify
Называйте ключи описательно (например, «Джон — Участник — Cursor»)
Задокументируйте, какие права есть у каждой роли
Настройте процессы одобрения для чувствительных действий

Шаг 3: Обеспечьте одобрения

Обеспечение одобрений

Создайте шаблоны промптов, требующие подтверждения
Используйте токены подтверждения для критических операций
Обучите команду паттернам одобрения
Отслеживайте операции записи для соблюдения требований

Лучшие практики

Лучшие практики RBAC

Начинайте с ограничений: начните с доступа только для чтения, добавляйте права постепенно
Минимум привилегий: давайте минимально необходимые для роли права
Регулярные проверки: пересматривайте права ежеквартально
Документируйте роли: держите определения ролей и права задокументированными
Одобрение для чувствительных действий: всегда требуйте одобрение для удалений и массовых операций
Аудит-логирование: логируйте все действия, связанные с правами

Спроектируйте ролевой доступ для MCP

Сопоставьте роли команды с правами MCP и обеспечьте одобрения для чувствительных действий

Руководство по безопасности →Развёртывание в команде