Настройка разрешений на основе ролей в планах Enterprise

Это руководство проведет вас через процесс настройки разрешений на основе ролей для вашей организации Enterprise. Это позволяет вам контролировать, какие функции и соединители могут использовать определенные команды или группы участников, и делегировать специфический доступ администратора, такой как выставление счетов или управление пользователями, вместо того чтобы давать всем одинаковые разрешения.

Перед началом убедитесь, что вы знакомы с:

Вам потребуется доступ Owner или Primary Owner к вашей организации Enterprise, или пользовательская роль с Identity & Access установленной на Manage.

Проверьте, какие возможности включены на уровне организации. Перейдите в Organization settings и убедитесь, что вы знаете, какие возможности участники могут использовать в настоящее время. Для параметров, управляемых RBAC, требуется, чтобы как параметр организации, так и параметр роли были включены, чтобы пользователи получили доступ.

Создайте резервную копию списка участников. Экспортируйте CSV ваших текущих участников из Organization settings > Members перед внесением каких-либо изменений. Если что-то пойдет не так во время миграции, это даст вам справку для восстановления доступа. См. Управление участниками в планах Team и Enterprise.

Определите, какие команды или функции нуждаются в каждой возможности. Например, Engineering получает Claude Code + Fast Mode, а Marketing получает Cowork + Web Search. Отсюда определите ваши пользовательские роли.

Планы с двойными местами. Если ваша организация находится на плане Enterprise с двойными местами (с местами Chat и Chat + Claude Code), пользовательские роли не переопределяют ограничения на уровне мест. Участник, назначенный на место только для Chat, не может получить доступ к Claude Code, даже если его пользовательская роль это разрешает. То же самое применяется в обратном направлении: если пользовательская роль участника не предоставляет возможность chat, они не будут иметь доступ к chat независимо от типа их места. Планируйте структуру ролей с учетом назначений мест.

Решите, как вы будете создавать группы. Вы можете создавать группы вручную в Claude или синхронизировать их из вашего поставщика идентификации (IdP) через SCIM. Вы также можете использовать оба метода одновременно. Если вы планируете использовать группы IdP от Okta, Entra ID или другого поставщика, убедитесь, что синхронизация каталога SCIM настроена. См. Настройка JIT или SCIM provisioning.

Добавьте соединители, которыми вы планируете управлять. Разрешения соединителей охватывают только соединители, которые Owner или Primary Owner уже добавил в Organization settings > Connectors и подключил с учетными данными администратора. Также проверьте вашу политику инструментов на уровне организации там, так как разрешения ролей сужаются в ней и не могут расширяться за ее пределы. См. Использование соединителей для расширения возможностей Claude.

Перед созданием чего-либо решите, какие функции должна иметь каждая команда или группа участников. Вот четыре распространенных паттерна:

Это рекомендуемый подход для большинства организаций. Создайте роль "Standard Access" для всех с общими функциями, такими как веб-поиск, память и проекты. Затем создайте дополнительные роли, которые предоставляют специфические возможности — например, роль "Cowork Enabled", которая только добавляет Cowork. Назначьте всех участников базовой роли через группу "All Users" и добавьте конкретных участников в дополнительные группы, которые добавляют дополнительные функции.

Этот паттерн гибкий, потому что разрешения являются дополнительными — объединение базовой роли с дополнительными ролями компонуется чисто без конфликтов.

Создайте отдельные уровни: "Full Access" со всеми функциями, "Standard Access" с большинством функций и "Restricted Access" с минимальными функциями. Каждый участник входит ровно в одну группу, назначенную одному уровню.

Создайте роли, которые соответствуют отделам: "Engineering" с chat, Cowork, Claude Code и выполнением кода; "Research" с chat, веб-поиском, памятью и проектами; "Business" с chat, веб-поиском и только проектами. Назначьте каждую группу отдела соответствующей роли.

Создайте роли, которые делегируют части администрирования без предоставления роли Owner. Пользовательская роль с разрешениями администратора не нуждается в каких-либо возможностях пользователя, и наоборот. Вы можете создать роль "Finance", которая предоставляет доступ к Billing, но не к chat или Claude Code, или роль "Engineering Lead", которая предоставляет Claude Code плюс доступ к просмотру Analytics. Узнайте больше о разрешениях администратора для пользовательских ролей.

Помните: любая функция, которую вы хотите контролировать для каждой группы, должна быть включена на уровне организации. Если функция отключена на уровне организации, ни одна пользовательская роль не может предоставить доступ к ней.

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

Изменения ролей могут занять до 15 минут, чтобы вступить в силу. Участникам может потребоваться обновить браузер, чтобы увидеть обновленный доступ.

См. Управление пользовательскими ролями в планах Enterprise для получения подробной информации о доступных возможностях, разрешениях администратора и соединителях.

Установите разрешения администратора для каждой роли, чтобы делегировать доступ к параметрам администратора, таким как выставление счетов, управление пользователями или конфиденциальность, без предоставления роли Owner. Этот шаг опционален. Если вы его не настроите, роли не предоставляют доступ администратора и администрирование остается с Owners и Primary Owners. Для информации о том, что охватывает каждая область разрешений, см. Управление пользовательскими ролями в планах Enterprise.

На вкладке Разрешения перечислены все области администратора: Identity & Access, Billing, Analytics, Privacy, User Management, Libraries и Directory. Установите для каждой области администратора один из следующих параметров:

В пределах области вы предоставляете либо все разрешения на просмотр, либо все разрешения на управление. Вы не можете предоставлять или ограничивать отдельные страницы или параметры.

Проверьте разрешения администратора после переноса участников на роли «Пользовательские» (Шаг 7). См. Шаг 11: Проверка и мониторинг.

Установите разрешения соединителя для каждой роли, чтобы контролировать, какие соединители и какие инструменты на этих соединителях может использовать роль. Этот шаг необязателен. Если вы его не настроите, ваши роли вернутся к поведению по умолчанию, описанному ниже. Чтобы узнать, как модель разрешений работает от начала до конца, см. Управление пользовательскими ролями в планах Enterprise.

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

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

Выбор «Всегда разрешить», «Требуется одобрение» или «Заблокировано» применяет этот уровень ко всем инструментам на соединителе. Строка Все соединители работает аналогично на один уровень выше: она устанавливает базовый уровень для каждого соединителя одновременно, включая любой соединитель, который вы добавите позже. Используйте её для установки значения по умолчанию роли, а затем переопределите отдельные соединители.

Раскрывающееся меню Как участники подключаются контролирует, входят ли участники роли в соединители со своими собственными учетными записями или подключаются автоматически через вашего поставщика удостоверений:

Если соединитель имеет включенные оба параметра Индивидуально и Управляемая авторизация, Claude сначала пытается использовать управляемую авторизацию. Если это не удается, участники все еще могут войти индивидуально со своей собственной учетной записью, поэтому они не будут заблокированы в соединителе во время разрешения проблемы с поставщиком удостоверений.

Выбор Индивидуально или Управляемая авторизация в строке Все соединители устанавливает базовый уровень для каждого соединителя одновременно, включая любой соединитель, который вы добавите позже. Используйте её для установки значения по умолчанию роли, а затем переопределите отдельные соединители.

Установите соединитель на Пользовательское, чтобы отобразить его инструменты как отдельные строки. Вы можете выбрать «Всегда разрешить», «Требуется одобрение» или «Заблокировано» для каждого инструмента.

Разрешения для отдельных инструментов позволяют роли получить доступ к части соединителя. Например, если Jira установлен на Пользовательское, его инструмент search_issues установлен на «Требуется одобрение» и все остальные инструменты Jira установлены на «Заблокировано», участники с этой ролью могут искать в Jira, но ничего больше. Claude видит только инструменты, которые вы предоставили, поэтому просьба создать билет возвращает «У меня нет инструмента для этого» вместо ошибки.

Поскольку разрешения соединителя являются кумулятивными в ролях, блокировка соединителя в одной роли не влияет на участника, который также имеет другую роль, которая его предоставляет. Каждая строка соединителя показывает предупреждение, когда другие роли предоставляют тот же соединитель на другом уровне. Предупреждение называет эти роли и ссылается на них, и применяется наиболее разрешающее разрешение.

Если у вас есть несохраненные изменения при открытии связанной роли, вас попросят сначала их отменить.

Проверьте разрешения соединителя после переноса участников на роли «Пользовательские» (Шаг 7). См. Шаг 11: Проверка и мониторинг.

Установите доступ к моделям для каждой роли, чтобы контролировать, какие модели Claude может использовать роль, ограничить максимальный уровень усилий для каждой модели и выбрать модель, на которой начинаются новые беседы. Этот шаг необязателен; если вы его не настроите, новые роли смогут использовать каждую модель, которая включена на уровне организации, на любом уровне усилий и начинаться с модели по умолчанию организации.

Чтобы узнать, как параметры доступа к модели и модель по умолчанию работают от начала до конца, см. Управление доступом к моделям для вашей организации и Установка модели по умолчанию для вашей организации.

В разделе Доступ к модели включите или отключите каждую модель для этой роли. Модели, отключённые на уровне организации, отображаются, но не могут быть включены здесь, пока вы не включите их для организации в Параметры организации > Модели. Модели Haiku всегда включены и не могут быть отключены.

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

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

Проверьте доступ к модели после переноса участников на роли «Пользовательская». См. Шаг 11: Проверка и мониторинг.

Если вы используете синхронизацию каталога SCIM, вы можете синхронизировать группы из вашего поставщика удостоверений вместо их создания вручную. Подробнее о синхронизации групп SCIM см. в разделе Управление группами и лимитами расходов групп в планах Enterprise.

Несколько организаций под одной родительской организацией: Группы управляются на уровне родительской организации и распространяются на все дочерние организации. Вы можете видеть участников из других организаций в списке группы — это не означает, что они имеют доступ к вашей организации. Пользовательские роли, назначенные группе, предоставляют возможности только участникам, которые являются частью вашей конкретной организации.

Если вы запросите перемещение организации от одной родительской организации к другой (это редко происходит на практике), группы и роли станут неопределёнными, и вам потребуется их пересоздать.

Перед переносом участников на пользовательские роли убедитесь, что каждый участник, которого вы планируете перенести, находится по крайней мере в одной группе, назначенной пользовательской роли. Участники, перенесённые без покрытия группой или ролью, потеряют доступ ко всем управляемым функциям.

Чтобы возможности пользовательской роли вступили в силу, участники должны иметь роль «Пользовательская». Участники с ролями «Пользователь», «Администратор» или «Владелец» получают разрешения непосредственно из этих ролей, а не из пользовательских ролей.

Выберите путь миграции в зависимости от того, включила ли ваша организация уже сопоставление групп:

Используйте этот путь только если ваша организация уже включила сопоставление групп для назначения ролей. Если вы ещё не используете этот параметр, перейдите к пути B.

Участники в группах IdP, сопоставленных с ролями «Пользовательская», следуют разрешениям пользовательских ролей, назначенных их группам в Claude. Участники в группах IdP, сопоставленных с «Пользователь», следуют параметрам возможностей на уровне организации. Если участник находится в группах в обоих сопоставлениях, роли «Пользовательская» имеют приоритет.

Используйте этот путь, если ваша организация не включила сопоставление групп.

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

Независимо от того, какой путь вы используете, рекомендуется выполнять миграцию поэтапно:

Включайте функции на уровне организации только после завершения ролей, групп и миграции участников. Это гарантирует, что возможности пользовательской роли уже установлены, без окна, в котором неавторизованные участники могли бы получить доступ к функции.

Для любой функции, которую вы хотите контролировать по группам:

Включение функции на уровне организации не означает, что её получат все — разрешения пользовательских ролей уже установлены для контроля того, кто может её использовать. Думайте о переключателе уровня организации как о том, чтобы сделать функцию «доступной для назначения на основе ролей», а не «включённой для всех».

Чтобы установить ежемесячный лимит расходов на одного пользователя для группы:

Обратите внимание на следующие правила приоритета:

Изменения членства вступают в силу автоматически — пользователи получают или теряют лимиты сразу же при изменении их членства в группе. Применимо только для организаций с биллингом на основе использования.

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

Если вы настроили разрешения соединителя, также проверьте:

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

Изменения ролей могут вступить в силу в течение 15 минут на всей платформе. Участникам может потребоваться обновить браузер, чтобы увидеть обновленный доступ.

SCIM подключается к вашим возможностям на основе ролей через два механизма, которые работают вместе.

Это определяет, какую встроенную роль получит участник при его подготовке. Сопоставьте ваши группы IdP с ролями «Пользовательские», чтобы доступ новых участников автоматически управлялся возможностями пользовательской роли.

Это извлекает ваши группы IdP в Claude, чтобы их можно было назначить пользовательским ролям.

Если вы заметили, что структура ролей неправильно настроена после миграции:

Если вы включили сопоставление групп во время настройки и потеряли доступ администратора, следуйте инструкциям восстановления в Set up JIT or SCIM provisioning в разделе «I lost Admin/Owner access after enabling group mappings».

Да. Переключатель уровня организации должен быть включен, чтобы пользовательские роли могли управлять доступом для каждого участника. Если функция отключена на уровне организации, никто не может получить к ней доступ независимо от своей роли. Думайте об этом как о главном выключателе — пользовательские роли управляют тем, кто получает доступ под ним.

У них нет разрешений пользовательской роли, поэтому все функции, требующие разрешений, неактивны или скрыты. Убедитесь, что каждый участник, роль которого установлена на «Custom», входит по крайней мере в одну группу, назначенную пользовательской роли.

Либо модель отключена на уровне организации (Organization settings > Models), либо ни одна из пользовательских ролей участника её не предоставляет. Отключения на уровне организации влияют на всех, включая владельцев и администраторов.

Участники с этой ролью не будут видеть интерфейс чата Claude. При входе они попадут на страницу своих настроек. Если их роль предоставляет другие продукты, такие как Cowork или Claude Code, они остаются доступными на странице настроек и в соответствующих приложениях.

Чат включен по умолчанию во всех пользовательских ролях, поэтому вам нужно беспокоиться об этом только если вы намеренно отключили чат для роли.

Да. Участники с ролями User, Admin или Owner не затронуты разрешениями пользовательских ролей, так как они получают разрешения непосредственно из этих ролей. Только участники с ролью, установленной на «Custom», управляются системой групп и ролей. Это позволяет постепенную миграцию.

Разрешения являются аддитивными. Если любая роль в цепи участника предоставляет функцию, они её имеют. Вы не можете использовать роль для удаления разрешения, предоставленного другой ролью.

Да. Оба типа можно назначить пользовательским ролям. Разница в том, что членство в группе SCIM управляется в вашем поставщике идентификации, а членство в ручной группе управляется в параметрах организации Claude.

Нет. Владельцы и основные владельцы всегда имеют полный доступ ко всем функциям.

Группы и синхронизация SCIM управляются на уровне родительской организации и совместно используются всеми дочерними организациями. Назначения ролей и лимитов расходов настраиваются независимо в каждой дочерней организации — изменения в одной дочерней организации не влияют на другие. Изменения членства в группах и повторные синхронизации SCIM распространяются на все дочерние организации под одним родителем.

Каждая существующая роль заполняется грантом «All connectors» с уровнем «Always allow», поэтому доступ участников не изменяется при включении. Вы сужаете доступ отсюда.

«Needs approval» для каждого соединителя. Процесс создания роли проходит через вкладку Connectors, чтобы вы это видели перед сохранением.

Роль, строка «All connectors» которой установлена на «Always allow», «Needs approval» или «Blocked», автоматически охватывает новый соединитель на этом уровне. Роль, строка «All connectors» которой установлена на «Custom», рассматривает новый соединитель как «Blocked» до тех пор, пока вы его не установите.

Проверьте, имеет ли участник другую роль, которая его предоставляет, так как наиболее разрешающий грант побеждает в ролях. Предупреждение о конфликте в строке соединителя перечисляет эти роли. Также подтвердите, что роль участника установлена на «Custom».

Нет. Политика на уровне организации является потолком. Инструмент, заблокированный там, заблокирован для всех, независимо от грантов ролей.

Cowork имеет отдельный параметр организации, Allow "Always allow" for connector tools, который управляет инструментами соединителя с возможностью записи. По умолчанию он отключен. До его включения «Allow for all tasks» остаётся неактивным независимо от грантов ролей и политик инструментов, и ранее сохранённые предпочтения always-allow не соблюдаются. Инструменты только для чтения исключены только если соединитель их аннотирует как только для чтения, что большинство пользовательских соединителей не делают. Для получения дополнительной информации см. Connector tool approvals.

Роль может его предоставить, но более строгий параметр побеждает, поэтому участники видят его ограниченным на «Needs approval». Чтобы позволить участникам установить «Always allow», сначала повысьте политику организации на «Always allow».

Да. Установите соединитель на «Custom», установите один инструмент на «Always allow» или «Needs approval» и оставьте остальное «Blocked».

Нет. Встроенные функции управляются на вкладке Capabilities. Вкладка Connectors управляет соединителями, которые ваша организация добавила.

Изменения ролей могут вступить в силу в течение 15 минут. Участникам может потребоваться обновить браузер.

Только если их роль включает управление Identity & Access, что охватывает редактирование ролей и групп. Зарезервируйте это разрешение для доверенных администраторов безопасности и ИТ, так как оно может использоваться для изменения определений ролей, включая их собственные.

Нет. Разрешения администратора применяются только к членам в пользовательской роли. Члены со встроенной ролью сохраняют доступ, который предоставляет эта роль. Чтобы предоставить кому-то определённые разрешения администратора, измените члена на пользовательскую роль и добавьте его в группу, назначенную роли с необходимыми разрешениями. Имейте в виду, что это удаляет их предыдущий доступ со встроенной ролью.

Параметры организации показывают только разделы, которые охватывают их разрешения. Разделы, к которым у них нет доступа, полностью скрыты в параметрах организации.

Параметры организации > Роли показывает разрешения администратора, которые предоставляет каждая пользовательская роль, и Параметры организации > Группы показывает, какие группы назначены каждой роли и кто в них входит. Чтобы проверить конкретного члена, найдите его группы в Параметры организации > Члены, затем роли, которым назначены эти группы.

Создайте одну роль, которая предоставляет доступ к нескольким областям, или добавьте члена в несколько групп, чьи роли охватывают необходимые области. Разрешения объединяются аддитивно.