Ролевая модель и доступ к данным

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

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

Четыре уровня доступа

Уровень	Что определяет	Пример
Тип аккаунта	Сторону продукта: `ENGINEER` или `EMPLOYER`	Инженер ведёт анкеты; представитель компании работает с наймом
Роль в компании	Полномочия внутри конкретной организации: `OWNER` или `HR`	Владелец приглашает коллег; HR работает с назначенными вакансиями
Служебные разрешения	Доступ сотрудника к административным операциям	Просмотр жалоб, блокировка аккаунта и управление операторами требуют разных прав
Доступ к объекту и согласие	Возможность действия над конкретной анкетой, вакансией, офером или данными	Контакты доступны уполномоченному сотруднику только в объёме раскрытия для его компании

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

Кто что делает

Участник	Основные возможности	Граница доступа
Гость	Публичные вакансии и страницы компаний, знакомство с продуктом, регистрация	Закрытые данные и каталог инженеров требуют соответствующего доступа
Инженер, `ENGINEER`	Свой профиль, анкеты, достижения ФСП, интересы, ответы на оферы, чаты и раскрытие данных	Управляет своими объектами и предоставленными ему сценариями
HR, `EMPLOYER` + `HR`	Каталог обезличенных анкет, подбор и работа с интересами, оферами и чатами назначенных вакансий	Активное членство и назначения внутри выбранной компании
Владелец, `EMPLOYER` + `OWNER`	Карточка компании, приглашения сотрудников, назначения и передача владения	Управление организацией не даёт автоматического доступа к контактам инженеров
Оператор платформы	Жалобы, поддержка, решения и другие разрешённые административные действия	Отдельная служебная сессия и конкретные выданные права

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

Приватность встроена в сценарий найма

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

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

Достижения ФСП — сведения об участии и результатах, а не дополнительная роль. Привязка реестра не даёт административных прав и не открывает чужие данные. В демонстрации используется эмулятор реестра с синтетическими спортсменами.

Служебные права: доступ под задачу

Административное приложение работает через отдельный Admin Gateway. Служебная сессия имеет назначение ADMIN и собственную аудиторию токена; продуктовая сессия не заменяет её. Для административных обращений предусмотрена актуальная проверка сессии через Identity.

Сам административный хост можно ограничить внутренней сетью и VPN. Вариант корпоративного входа через Keycloak/OIDC сохраняет эти проверки: внешний провайдер подтверждает личность, а доступ к действиям определяют разрешения geek.moscow.

В коде ведётся общий реестр разрешений: например, COMPLAINT_READ разрешает чтение жалоб, COMPLAINT_REVIEW — рассмотрение, ACCOUNT_BLOCK — блокировку, AUDIT_READ — чтение аудита. Просмотр частных данных требует отдельного ACCOUNT_PII_READ, выдача прав сотрудникам — STAFF_MANAGE. Сотрудник не может выдать себе новые полномочия.

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

Набор	Назначение
`ACCOUNT_OBSERVER`	Просмотр аккаунтов и компаний без отдельного права на персональные поля
`ACCOUNT_SUPPORT`	Поддержка аккаунтов: чтение разрешённых персональных сведений, просмотр и отзыв сессий
`DIRECT_MODERATOR`	Прямые ограничения профилей и компаний, блокировка и разблокировка аккаунтов
`CASE_REVIEWER`	Рассмотрение жалоб, скрытие публикаций, блокировка и пересмотр решений
`COMPANY_OPERATOR`	Просмотр компании и управление её участниками и приглашениями
`COMPANY_RECOVERY`	Восстановление управления компанией: передача владения и операции архивирования
`DATA_LIFECYCLE`	Удаление, восстановление и отдельное необратимое стирание аккаунтов
`ACCESS_ADMIN`	Управление служебными правами, просмотр решений и аудита

Наличие права не отменяет условий операции: состояние объекта, основание решения и дополнительные подтверждения проверяются отдельно. Выдача наборов описывает доступ в коде; доступность расширенных действий EXT-07 на конкретной версии стенда рассматривается в административном контуре.

Как сервер принимает решение

Запрос проходит последовательные проверки: сессия и назначение токена → тип аккаунта или служебное право → членство и назначение → доступ к объекту → согласие на раскрытие и действующие ограничения. Итоговое решение принимает сервис, владеющий данными. Интерфейс показывает разрешённые действия, а прямой вызов API проходит те же проверки.

Например, HR хочет открыть контакты инженера по оферу. Employers подтверждает активное членство, Opportunities — назначение на вакансию, Recruitment — контекст офера и разрешённый объём раскрытия, Candidates формирует допустимое представление профиля. При отзыве согласия или прекращении членства прежний успешный просмотр не заменяет новую проверку.

Для команды разработки это задаёт ясные точки ответственности: Identity ведёт аккаунты, сессии и служебные права; Employers — членства; Opportunities — назначения; Recruitment — раскрытия; Candidates — выдачу сведений профиля; Backoffice — решения и аудит. Новый экран подключается к этим правилам через контракт соответствующего сервиса.

Что стоит показать на демонстрации

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

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

Основания: ролевая модель, разделение типов аккаунтов, административные требования, реестр packages/shared/src/operator-registry.ts в backend.

Возможности участников · Технологии и командная разработка · Администрирование · Все разделы