Что подготовить заранее

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

1. Где вы будете работать: три места, откуда вы будете администрировать Claude Enterprise.
2. Кто что может делать: роли, которые регулируют каждое действие в настройках вашей организации.
3. Проверка предварительных условий: шесть пунктов, которые необходимо подтвердить, прежде чем выбрать структуру групп, включая domain claiming.

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

Где вы будете работать

Вы администрируете Claude Enterprise из трех мест. Знание того, что где находится, избавит вас от бесплодных поисков настроек. Четвертое место — управляемые настройки Claude Code — относится к вашему руководителю платформы (Урок 6).

• Настройки организации (Organization settings): большинство элементов управления в этом курсе — группы и роли, коннекторы, управление, расходы и видимость. Сюда вы заходите, чтобы изменить разрешенные действия для группы.
• Ваш поставщик идентификации (IdP), такой как Okta, Microsoft Entra ID или эквивалент: определения групп и членство, которые Claude считывает через identity sync. Сюда вы заходите, чтобы изменить состав группы.
• Claude Console: API ключи и доступ разработчиков, работающие как отдельная организация со своей собственной admin model. Сюда вы заходите, чтобы управлять доступом к API, который не регулируется вышеуказанными настройками.

Часто путают первые два пункта: если ваши группы синхронизируются, вы изменяете членство в вашем IdP, а разрешения — в настройках организации (Organization settings).

Кто что может делать

Каждый участник имеет роль — одну из четырех встроенных ролей (Primary Owner, Owner, Admin, User) или custom role, которую вы определяете, — и каждое действие в настройках вашей организации регулируется этими ролями. Точные возможности, связанные с каждой встроенной ролью, меняются по мере развития продукта. Актуальную матрицу возможностей см. в статье Роли и разрешения. Урок 5 охватывает полную картину ролей User, Admin и custom roles как часть проектирования групп. Сторона администрирования важна сейчас, потому что она определяет, кто фактически может реализовать решения, рассматриваемые в этом курсе.

Проверка предварительных условий

Первое решение, которое вы примете, — это «Структура и идентификация» (Structure & Identity). Это решение, изменение которого потребует наибольших усилий в будущем, поэтому вам необходимо убедиться, что вы к нему адекватно подготовлены. Существует шесть предварительных условий, которые должны быть выполнены, прежде чем вы выберете структуру групп. Четыре из них обязательны: три полностью блокируют настройку групп, а одно является вашей страховкой от блокировки доступа. Остальные два могут выполняться параллельно.

Подробнее о двух предварительных условиях

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

Что касается страховки от блокировки доступа, вы должны назначить по крайней мере двум участникам роль Owner. Без IdP role mappings назначьте их напрямую по имени, чтобы group-sync error не могла лишить вас admin access. При использовании IdP role mappings поместите тех же людей в группу, сопоставленную с Owner, прежде чем сохранять сопоставление. Как только mappings включены, прямое назначение само по себе не восстановит ваш доступ; это может сделать только Primary Owner, который никогда не удаляется автоматически.

Primary Owner заслуживает особого внимания, поскольку эта роль позволяет выполнять действия, недоступные другим ролям, и некоторые из них будут рассмотрены позже в курсе. Назначайте каждому admin наименее мощную роль, соответствующую его обязанностям, и освободите Primary Owner от day-to-day admin duty. Если Primary Owner — это не вы, выясните сейчас, кто должен занимать эту роль.

Еще одно предварительное условие, заслуживающее отдельного объяснения: domain claiming. Сотрудники вашей компании, возможно, уже использовали Claude на не-Enterprise аккаунте, зарегистрированном с использованием рабочей электронной почты, до того как ваша организация появилась в Claude. Пока вы не заявите права на свой домен (claim your domain), эти аккаунты находятся вне вашей организации, как и все действия, которые участники выполняют в них. Верификация домена доказывает, что вы им владеете; claiming — это отдельный шаг, который направляет всех, кто входит в систему с адресом этого домена, в вашу организацию. После реализации каждая будущая sign-up на домене попадает под ваш контроль. Точные шаги описаны в статьях справочного центра по domain-claiming и account-migration.

Domain claiming является последним среди четырех must-do предварительных условий по одной причине: его включение требует groundwork до него, чтобы у каждого пользователя домена был способ sign in после переноса его аккаунта:

• Ваш домен верифицирован
• Organization creation на нем ограничено
• Single sign-on принудительно включен (не просто configured)
• Provisioning активен

Несколько важных моментов, которые следует учесть, прежде чем включать claiming:

• Это действие необратимо.
• Участники, у которых уже есть personal account на вашем домене, получают 30-дневное migration window, начиная с момента инициации claim.
• Каждый из них выбирает между переносом своих существующих conversations и projects в новый аккаунт в вашей организации или началом с чистого листа. В любом случае, custom skills не переносятся при personal-account migration, поэтому им следует экспортировать все, что они хотят сохранить, до миграции. Connected-app authorizations отзываются, поэтому каждое app переподключается из нового organization account, а любые custom connectors добавляются заново, в соответствии с политикой вашей организации. Skills потенциально recoverable, хотя: whole-organization Team-to-Enterprise migration сохраняет skills участников, которые снова появляются после того, как admin повторно их re-enables. Любой, кто не сделал выбор до закрытия window, по умолчанию получает fresh account.
• Оригинальный personal account деактивируется в любом случае.

Ваша роль здесь — сделать этот transition максимально гладким: forewarn тех участников до инициации, чтобы никто не обнаружил change только после того, как их old account будет gone. Рассмотрите возможность поделиться следующим:

Предварительные условия Pluto

По мере того как команда развертывания Pluto работала над предварительными условиями, domain claiming стал для них единственным реальным препятствием: около сорока участников, в основном инженеры, уже использовали Claude на email domain Pluto — IT lead отправил вышеуказанное notice за две недели до инициации claim — и каждый из них попал под контроль Pluto после включения claiming. Identity team подключила single sign-on на первой неделе, admin roles закреплены за IT lead, а Primary Owner role остается у CIO, намеренно исключенная из daily use. Identity team также stood up provisioning app. Два напрямую назначенных Owners и group naming convention закреплены за IT lead, а billing owner является delegate CFO.

Настройка ресурсов

Эти статьи охватывают вышеуказанную groundwork: SSO, provisioning, roles matrix и domain claiming, включая то, что увидят ваши участники с personal accounts.

• Claim и миграция аккаунтов на вашем домене: шаги по верификации и claim вашего домена.
• Ответ на Enterprise domain claim в вашем аккаунте Claude: что увидят ваши участники с personal accounts, чтобы вы могли их forewarn.
• Перенос вашего personal Claude account в организацию Team или Enterprise: что происходит с skills, connected apps и history участника при миграции.
• Миграция вашей организации из Team в Enterprise: как whole-organization migration сохраняет skills участников.
• Роли и разрешения: текущая capability matrix для каждой built-in role.
• Настройка single sign-on (SSO): configuring SSO, setup, который вы должны enforce, а не просто configure, прежде чем claim ваш домен.
• Настройка JIT или SCIM provisioning: provisioning, который должен быть live, чтобы у каждого пользователя вашего домена был way in.

Задание урока

Интерактивный виджет ниже отслеживает шесть предварительных условий: отметьте каждое как выполненное или еще нет, и скопируйте результат в ваш сопроводительный документ.

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

→ Запишите это в сопроводительном документе, раздел Урок 3.

Что дальше

В следующем модуле вы определите, сколько организаций Claude Enterprise вы будете использовать, и разработаете свои группы.