Управление правами доступа в MCP: кто может использовать какие инструменты и данные
Связывайте каждый запрос MCP с конкретным человеком, предоставляйте доступ через команды, ограничивайте инструменты и данные тем, что нужно для работы, и поддерживайте доступ в актуальном состоянии при смене ролей.
Коротко о решении
Управление правами доступа в MCP определяет, кто может использовать какие подключения, инструменты и данные MCP, и следит, чтобы этот ответ оставался верным со временем. Связывайте каждый запрос с конкретным человеком, а не с общим ключом, предоставляйте доступ через команды, ограничивайте инструменты и данные тем, что нужно для работы, регулярно пересматривайте доступ и проверяйте, что отзыв действительно работает. Шлюз может применять эти правила к получаемым запросам, но внешнюю границу по-прежнему задают собственные разрешения вышестоящей системы.
Что означает управление правами доступа в MCP
Протокол MCP (Model Context Protocol) позволяет ИИ-клиентам, таким как Claude Code, Cursor или Codex, подключаться к корпоративным системам через серверы, которые предоставляют инструменты: поиск в очереди заявок, чтение документа, обновление записи о клиенте. Каждый запрос к инструменту обращается к системе от чьего-то имени.
Управление правами доступа задает те же вопросы, которые ваша команда по управлению удостоверениями уже задает о любом приложении, только применительно к этим запросам. Кто может использовать это подключение? Какие инструменты и данные нужны каждому человеку? Кто согласовал этот доступ и как быстро он прекращается, когда меняется роль человека?
Есть одно важное отличие. Агент сам выбирает, какой инструмент вызвать и что отправить, часто опираясь на содержимое, которое только что прочитал. У человека может быть право на инструмент, но это не значит, что он подразумевал каждый запрос, который агент способен сделать с его помощью. Поэтому узкие права доступа и понятная запись каждого запроса важнее, чем обычно.
Доступ определяется на нескольких уровнях
Один запрос к инструменту проходит через несколько решений о доступе. Если их записать, станет видно, какая система применяет каждое из них и где остаются пробелы.
Внешнюю границу задают собственные разрешения вышестоящей системы. Правило шлюза может сузить то, что человек вправе делать через шлюз, но не может предоставить разрешения, которых нет у его учетных данных.
| Уровень | Вопрос | Пример меры контроля |
|---|---|---|
| идентичность | Кто отправляет запрос? | Единый вход (SSO) для человека, который пользуется агентом |
| Членство | Состоит ли пользователь по-прежнему в организации и команде? | Группы из каталога, которые синхронизируются автоматически |
| Клиентская сессия | Авторизован ли этот клиент по-прежнему? | Сессии, которые можно отозвать для каждого клиента отдельно |
| Подключение | Может ли пользователь вообще работать с этой системой? | Подключения, назначенные определенным командам |
| Инструмент | Какие операции доступны пользователю? | Проверенные инструменты с повторной проверкой изменений |
| Ресурс | Какие записи, папки или проекты? | Разрешенные ресурсы или префиксы путей |
| Полномочия | Чьи разрешения видит вышестоящая система? | Собственное разрешение OAuth каждого пользователя с узкими областями действия |
Связывайте каждый запрос с конкретным человеком
Общие ключи API — типичное место, где управление правами доступа дает сбой. Когда агенты всех сотрудников используют один токен, вышестоящая система видит одного пользователя, отзыв токена затрагивает всех, а из записей нельзя понять, кто что запрашивал.
Отдавайте предпочтение собственной авторизации каждого человека в вышестоящей системе, обычно через OAuth, и пусть пользователи входят в любой шлюз через вашего обычного поставщика удостоверений. Спецификация авторизации MCP основана на OAuth 2.1. Она предполагает, что сервер принимает только выданные для него токены, и запрещает напрямую передавать токен клиента другому сервису.
Для некоторых задач подходит сервисная учетная запись — например, для запланированного задания, которое выполняется без участия человека. Назначьте такой учетной записи ответственного владельца, выдайте ей минимально достаточные права и ведите для нее отдельные записи, чтобы ее действия никогда не принимали за действия человека.
Предоставляйте доступ через команды
Назначение подключений людям по одному сложно проверять, и о нем легко забыть. Вместо этого назначайте их командам — в идеале группам из вашего поставщика удостоверений, — чтобы новые сотрудники получали нужный доступ, а ушедшие теряли его при изменении каталога.
Начинайте с узкого доступа. Открывайте критичное подключение только той команде, которой оно нужно, а не всей организации, а затем добавляйте условия для отдельных инструментов или ресурсов. Например, в условной финансовой команде все могут читать счета в одной папке, а обновлять платежные реквизиты — только небольшая группа.
Следите за доступом, полученным косвенно. Человек, состоящий в двух командах, может получить доступ к подключению через любую из них, поэтому удаление его из одной команды не обязательно лишает его доступа.
Ограничивайте доступ агентов тем, что нужно для работы
OWASP относит избыточную автономность (Excessive Agency) к основным рискам для приложений на основе больших языковых моделей. Агент, получивший больше функций, разрешений или автономности, чем требует его задача, может причинить вред, если его введут в заблуждение или он просто ошибется. Промпт-инъекция, при которой прочитанный агентом текст пытается перенаправить его действия, — один из путей, как это происходит.
Принцип минимальных привилегий для MCP работает на трех уровнях. Включайте только те инструменты, которые нужны рабочему процессу. Ограничивайте эти инструменты ресурсами, с которыми связана работа. Запрашивайте только те области действия OAuth (scopes), которые нужны включенным инструментам, потому что токен подключения обычно доступен каждому инструменту этого подключения. Рекомендации по безопасности MCP советуют начинать с минимальных областей действия и запрашивать дополнительные только при необходимости.
Чтение требует такой же осторожности, как и изменение. Инструмент, который может только читать записи о клиентах, все равно способен их раскрыть. На практике хорошо работает такой подход: дать пилотной группе доступ только для чтения, убедиться, что границы соблюдаются, и разрешить изменения, когда команда поймет, как ведет себя агент.
Пересматривайте доступ и проверяйте отзыв
Доступ постепенно расползается. Проекты завершаются, люди переходят в другие команды, а временные исключения становятся постоянными. Включите подключения MCP в уже проводимые пересмотры доступа, чтобы владелец каждого подключения подтверждал, кому следует сохранить доступ. Полезный пересмотр охватывает следующие пункты.
Затем проверьте отзыв напрямую. Удалите тестового участника и повторите запрос из клиента, в котором уже выполнен вход. Запрос должен быть отклонен, а прежнее одобрение не должно возвращать доступ.
- Кто может использовать каждое подключение сейчас и через какую команду или исключение.
- Какие инструменты и ресурсы включены и нужен ли еще каждый из них.
- Чьи учетные данные использует подключение и какие области действия они предоставляют.
- Какие клиентские сессии остаются активными, особенно у ушедших сотрудников.
- Что использовалось за период по сравнению с тем, что разрешено.
Разделяйте запрос и одобрение
Для действий с серьезными последствиями, таких как отправка платежа, удаление записей или рассылка писем клиентам, одного доступа может быть недостаточно. Другой человек может проверить предлагаемое действие до его выполнения. Проверяющий не должен быть инициатором запроса, а решение должно касаться конкретного действия, а не давать неограниченное разрешение.
Соблюдайте соразмерность такой проверки. Требование проверять каждое мелкое действие вызывает усталость и мешает замечать важные запросы. Выбирайте действия, требующие проверки, исходя из того, какой вред может причинить ошибка.
Сохраняйте доказательства доступа и использования
Два вида доказательств отвечают на разные вопросы. Текущий доступ показывает, кто может использовать подключение сегодня и почему. Записи запросов показывают, кто на самом деле его использовал, какое решение было принято и что произошло дальше. Для пересмотра доступа нужны оба.
Храните записи в разумном объеме. Записям о решениях редко нужны полные промпты или ответы, а их хранение само по себе создает обязательства по защите персональных данных. Кроме того, записи охватывают только те маршруты, которые они видят; запросам в обход шлюза нужны собственные средства контроля.
Где подходит Durin
Durin применяет управление правами доступа к запросам MCP, которые проходят через его шлюз. Прежде чем применяются правила команды, каждый запрос должен пройти актуальные проверки: личность, членство, команда, подключение, учетные данные, проверенный инструмент, ресурс и анализ содержимого. Подключения можно ограничивать определенными командами, а правила команды могут добавлять условия для отдельных инструментов, ресурсов или людей.
Пользователи входят в собственную конечную точку Durin, а запросы к вышестоящим системам используют учетные данные провайдера, настроенные для этого подключения; Durin не передает провайдеру собственный токен. Отзыв членства или клиентской сессии действует для последующих запросов, и прежнее одобрение не может восстановить доступ. Организации на тарифе Enterprise могут синхронизировать пользователей и группы из своего поставщика удостоверений; локальные пользователи, группы и приглашения доступны в любом пакете.
По умолчанию проверенные запросы могут выполняться после этих проверок. Администраторы могут по умолчанию запрещать доступ к инструментам или требовать, чтобы предлагаемые изменения проверял другой администратор. Раздел «График доступа» показывает, кто может использовать подключение сегодня и почему, а раздел «Аудит» — решения, записанные при выполнении запросов. Запросам, которые не проходят через Durin, нужны собственные средства контроля.