Как создать веб‑приложение для доступа внешних консультантов

Что на самом деле значит «доступ консультанта»

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

Обычно консультанты нуждаются в доступе, который:

• Внешний (они аутентифицируются как отдельная сущность, не как общий командный аккаунт)
• Привязанный к проекту (связан с конкретным клиентом, проектом или задачей)
• Ограниченный по времени (должен автоматически завершаться, если не продлен)
• Аудируемый (каждое действие можно отследить до человека и утверждения)

Проблема, которую вы решаете

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

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

Общие риски, против которых стоит проектировать

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

Цели веб-приложения для доступа консультантов

Ваше приложение должно оптимизировать:

• Быстрый онбординг с явным владельцем и минимальным количеством взаимодействий
• Минимальные привилегии по умолчанию (доступ изначально узкий, расширяется только с обоснованием)
• Ясную подотчетность (заявитель, утверждающий и личность консультанта — всё явно)
• Простой оффбординг, который надежно удаляет доступ везде

Что приложение должно управлять (область)

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

• Приложения (внутренние инструменты, тикетинг, дашборды)
• Данные (наборы данных, файлы, записи, выгрузки)
• Окружения (prod vs staging vs dev)
• Клиенты/проекты (какие данные клиента может видеть консультант и в какой роли)

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

Чеклист требований и заинтересованные стороны

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

Заинтересованные стороны (и что для каждой важно)

• Внутренний спонсор (владелец проекта): хочет, чтобы консультант быстро стал продуктивным, без лишней нагрузки на поддержку.
• IT/безопасность: нужно единообразное применение политик (SSO/MFA, логирование, временные ограничения) и возможность реагировать на инциденты.
• Консультант (внешний пользователь): нужен простой вход и только те инструменты/данные, что требуются для работы.
• Утверждающий (менеджер, клиентский лидер или владелец данных): должен быть уверен, что запросы на доступ легитимны и ограничены нужным проектом.

Уточните заранее, кто может утверждать что. Частое правило: владелец проекта утверждает доступ к проекту, а IT/безопасность утверждают исключения (например, повышенные роли).

Базовый рабочий процесс для поддержки end-to-end

Опишите «happy path» в одном предложении, затем разверните его:

Запрос → утверждение → предоставление → ревью → отзыв

Для каждого шага фиксируйте:

• Какие данные обязательны (проект, роль, дата начала/окончания, обоснование)
• Кто отвечает (заявитель vs спонсор vs IT/безопасность)
• Ожидаемое время реакции (тот же день, 24 часа, 3 рабочих дня)
• Что происходит в случае неудачи (недостающая информация, отклонение, истечение окна)

Ограничения, которые стоит документировать

• Несколько клиентов/проектов: один консультант может работать на нескольких проектах — он не должен видеть данные других клиентов.
• Ограниченные временные окна: доступ должен автоматически истекать, с явным процессом продления.
• Требования соответствия: хранение утверждений и истории аудита, доказательства периодических проверок и быстрая отзывка при окончании контрактов.
• Модель поддержки: кто восстанавливает доступ, решает проблемы с блокировкой аккаунтов и отвечает на «почему я не вижу это?»

Метрики успеха (чтобы доказать эффективность)

Выберите несколько измеримых целей:

• Время на онбординг (от отправки запроса до рабочего доступа)
• % аккаунтов, проверенных в срок (ежемесячные/ежеквартальные ревью)
• Время на отзыв (с момента расторжения/окончания контракта до удаления доступа везде)

Эти требования станут критериями приёмки для портала, процессов утверждения и управления.

Модель данных: пользователи, проекты, роли и политики

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

Основные объекты (что хранить)

Начните с небольшого набора устойчивых сущностей:

• Users: и сотрудники, и внешние консультанты. Включите атрибуты идентичности (email, имя), тип пользователя (internal/external) и статус.
• Organizations: фирма консультанта и ваши внутренние бизнес‑юниты, если это уместно.
• Projects: единица работы, против которой предоставляется доступ (клиентский аккаунт, engagement, кейс, сайт).
• Resources: то, что защищено (документы, тикеты, отчёты, окружения). Можно моделировать как типизированные записи или как общий «resource» с полем type.
• Roles: человекочитаемые наборы прав (например, "Consultant Viewer", "Consultant Editor", "Finance Approver").
• Policies: правила, которые ограничивают роли (разрешённые типы ресурсов, область данных, требования по IP/устройству, временные лимиты).

Связи (как выражается доступ)

Большинство решений об доступе — это связи:

• User ↔ Project membership: таблица связывания, например project_memberships, которая показывает, что пользователь принадлежит проекту.
• Role assignments: отдельная таблица связей, например role_assignments, которая даёт роль пользователю в рамках контекста (по всему проекту или для конкретной группы ресурсов).
• Exceptions: моделируйте их явно (например, policy_exceptions), чтобы потом можно было их аудировать, вместо того чтобы прятать в ad-hoc флагах.

Такое разделение позволяет отвечать на типичные вопросы: «Какие консультанты имеют доступ к Проекту A?» «Какие роли есть у этого пользователя и где?» «Какие права стандартные, а какие — исключения?»

Временный доступ (сделайте временный доступ значением по умолчанию)

Временный доступ легче контролировать, если модель это принуждает:

• Добавьте start/end timestamps в членства и/или назначения ролей.
• Храните правила продления (кто может продлить, максимальная длительность, число продлений).
• Учитывайте поле grace period, если нужен короткий переходный период (например, только чтение на 48 часов).

Состояния (отслеживайте жизненный цикл)

Используйте явное поле статуса для членств/назначений (не только «deleted»):

• pending (запрошено, не утверждено)
• active
• suspended (временно заблокировано)
• expired (просрочено)
• revoked (завершено досрочно админом)

Эти состояния упрощают логику рабочих процессов, UI и логи аудита — и не дают доступу «привидению» висеть после завершения сотрудничества.

Проектирование контроля доступа (RBAC + ограждения)

Хороший доступ для консультантов редко бывает «всё или ничего». Это понятный базовый набор (кто что может) плюс ограждения (когда, где и при каких условиях). Многие приложения реализуют роли, но пропускают контроли, которые делают эти роли безопасными на практике.

Начните с RBAC: простые роли на проект

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

Частая базовая схема:

• Viewer: может читать данные проекта и скачивать утверждённые артефакты.
• Editor: может создавать/обновлять элементы внутри проекта (загружать результаты, комментировать, обновлять статусы).
• Admin: может управлять настройками проекта и назначать роли в рамках проекта.

Явно указывайте «область действия»: Viewer в Проекте A не означает ничего для Проекта B.

Добавьте ограждения с условными проверками в стиле ABAC

RBAC решает «что они могут делать», а ограждения отвечают «при каких условиях это разрешено». Добавьте проверки по атрибутам там, где риск выше или требования меняются.

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

• Атрибуты проекта: разрешать доступ только к проектам в назначённом клиентском аккаунте или регионе.
• Локация/сеть: требовать доверенную сеть (или блокировать высокорисковые географии) для чувствительных выгрузок.
• Состояние устройства: ограничивать действия, если сессия не соответствует требованиям безопасности (например, включён MFA, управляемое устройство).
• Временные окна: разрешать доступ только в даты договора или в рабочие часы.

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

Минимальные привилегии по умолчанию, исключения — через процесс

По умолчанию давайте всем новым внешним пользователям наименьшую роль (обычно Viewer) с минимальной областью проекта. Если нужно больше — требуйте запроса на исключение с:

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

Это предотвращает превращение «временного» доступа в постоянный незаметно.

Break-glass доступ (и как его контролировать)

Определите путь экстренного доступа для инцидентов (например, при инциденте в prod, когда консультанту нужно действовать срочно). Держите его редким и явным:

• утверждение назначенным on-call владельцем (или двухфакторное утверждение для высокорисковых действий),
• ограничение по времени (минуты/часы, не дни),
• полное логирование: кто, что, когда и зачем.

Break-glass должен быть неудобен — это предохранительный клапан, а не кратчайший путь.

Аутентификация: SSO, MFA и безопасная обработка сессий

Аутентификация — это место, где «внешний» доступ либо становится удобным, либо превращается в постоянный риск. Для консультантов нужна фрикция только там, где она реально снижает риск.

Выберите подход к идентичности: локальные аккаунты vs SSO

Локальные аккаунты (email + пароль) быстро внедряются и подходят любому консультанту, но создают нагрузку по сбросу паролей и повышают шанс слабых паролей.

SSO (SAML или OIDC) обычно лучше, когда фирма консультанта уже использует IdP (Okta, Entra ID, Google Workspace). Вы получаете централизованную политику входа, проще с оффбордингом на их стороне и меньше паролей в вашей системе.

Практический паттерн:

• По умолчанию использовать SSO, когда компания консультанта интегрирована.
• Для независимых консультантов — fallback на локальные аккаунты.

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

MFA без «театра безопасности» (и без слабых способов восстановления)

Требуйте MFA для всех сессий консультантов — предпочтительно приложение-аутентификатор или аппаратные ключи. SMS может быть запасным вариантом, но не основным.

Восстановление — место, где многие системы непреднамеренно ослабляют безопасность. Избегайте постоянных «резервных email»-обходов. Вместо этого используйте ограниченный набор более безопасных опций:

• одноразовые коды восстановления, показанные один раз при подключении,
• сброс администратором с верификацией личности и полным логированием,
• повторная регистрация устройства, требующая MFA.

Приглашения: ссылки с истечением и контроль доменов

Большинство консультантов присоединяются по приглашению. Обращайтесь с приглашением как с временным учетным данными:

• короткий срок действия (например, 24–72 часа),
• одноразовое использование, привязанное к email,
• ограничение попыток и понятные сообщения об ошибках.

Добавьте списки разрешённых/запрещённых доменов по клиенту или проекту (например, разрешить @partnerfirm.com; блокировать публичные почтовые сервисы, если нужно). Это предотвращает случайные приглашения посторонним.

Безопасность сессий: короткие токены и возможность отзывать

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

• используйте короткоживущие access-токены,
• периодически обновляйте refresh-токены и отзывайте их при подозрительной активности,
• предоставьте «выйти со всех устройств» для пользователей и админов.

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

Процесс запроса и утверждения

Чёткий поток запроса и утверждения предотвращает превращение «быстрой просьбы» в постоянный, недокументированный доступ. Рассматривайте каждый запрос на доступ консультанта как маленький контракт: чёткий объём, ответственный, дата окончания.

Форма запроса: фиксируйте намерение, а не только личность

Сделайте форму так, чтобы заявители не могли быть расплывчатыми. Минимум требуйте:

• Проект (или клиентское engagement), в котором будет работать консультант
• Запрашиваемая роль (сопоставляемая с вашими стандартными ролями, не свободный текст)
• Длительность (дата начала + дата окончания с указанием тайм‑зоны)
• Бизнес-обоснование (один абзац о том, зачем и какие работы блокируются без доступа)

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

Маршрутизация утверждений: делегируйте ответственность явно

Утверждения должны следовать за ответственностью, а не за орг‑структурой. Частая последовательность:

• Владелец проекта (подтверждает, что консультант должен работать над проектом)
• Безопасность или IT (подтверждает, что роль соответствует принципу минимальных привилегий)
• Контакт клиента (опционально, если клиент должен разрешать доступ третьих лиц)

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

SLA, напоминания и эскалации

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

• Напоминания об ожидающих утверждениях (например, через 24 часа)
• Уведомления о приближающемся окончании (например, за 7 дней)
• Эскалация к альтернативному утверждающему, если первичный недоступен

Записывайте каждое решение

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

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

Provisioning — это место, где «утверждено на бумаге» становится «доступно в продукте». Для внешних консультантов цель — скорость без лишнего раскрытия: дать только необходимое, на нужное время, и упростить изменения.

Автоматизируйте путь по умолчанию

Начните с предсказуемого автоматизированного процесса, привязанного к утверждённому запросу:

• Назначение ролей: сопоставьте каждый тип утверждённого engagement с ролью (например, Finance Analyst – Read Only, Implementation Partner – Project Admin).
• Членство в группах: добавляйте консультанта в нужные группы, чтобы права были согласованы между проектами.
• Права на ресурсы: автоматически давайте доступ только к указанным проектам, рабочим пространствам или наборам данных — не ко всему тенанту.

Автоматизация должна быть идемпотентной (безопасна при повторном запуске) и выдавать понятный «отчёт по предоставлению», показывающий, что именно дано.

Поддерживайте ручные шаги (с чек‑листами)

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

• Предоставляйте пошаговый чек‑лист с ответственным, сроком и верификацией (например, “Подтвердить доступ к папке”, “Подтвердить VPN‑профиль”, “Подтвердить billing code”).
• Требуйте от исполнителя отметить каждый шаг как выполненный и фиксировать доказательства при необходимости (ссылка на тикет, скриншот, ID записи в системе).

Временный доступ с напоминаниями о продлении

У каждого аккаунта консультанта должна быть дата окончания при создании. Реализуйте:

• Автоматическое истечение: доступ отзывается по окончании срока (а не просто «отключается в теории»).
• Напоминания о продлении: уведомляйте консультанта и внутреннего спонсора заранее (например, за 14 и 3 дня) с возможностью отправить запрос на продление в один клик.
• Правила льготного периода: избегайте молчаливых продлений; если работа должна продолжаться — она должна пройти через ту же логику утверждения.

Изменения во время сотрудничества: апгрейды, сдвиги объёма, приостановки

Работа консультанта меняется. Обеспечьте безопасные обновления:

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

Логи аудита, мониторинг и уведомления

Аудит‑логи — это ваша «бумажная дорожка» для внешнего доступа: они объясняют, кто что сделал, когда и откуда. Для управления доступом консультантов это не просто галочка соответствия — это то, как вы расследуете инциденты, доказываете минимальность прав и быстро разрешаете споры.

Практичная схема аудит‑логов

Начните с согласованной модели событий, применимой ко всему приложению:

• actor: кто инициировал действие (user ID, роль, org)
• target: что затронуто (project ID, file ID, user ID)
• action: канонический глагол (INVITE_SENT, ROLE_GRANTED, DATA_EXPORTED)
• timestamp: серверное время (UTC)
• ip: исходный IP (плюс user agent, если доступно)
• metadata: JSON с контекстом (policy ID, previous/new values, reason codes, request ticket)

Стандартизируйте действия, чтобы отчётность не превратилась в угадывание.

События, которые следует логировать (минимальный набор)

Логируйте как «события безопасности», так и «события с бизнес‑влиянием»:

• Отправленные/принятые/истёкшие приглашения, активация аккаунта, сброс пароля
• Логины, логауты, обновление сессии, неудачные попытки входа
• Регистрация/изменение MFA, ошибки MFA, ошибки SSO утверждений
• Изменения ролей или политик (включая кто и зачем утвердил)
• Доступ к чувствительным представлениям, выгрузки/скачивания, использование API‑ключей
• Действия админов: деактивация пользователей, перераспределение проектов, массовые изменения

Мониторинг и триггеры оповещений

Логи полезны в связке с алертами. Типичные триггеры:

• Необычные паттерны входа (новая страна/устройство, «невозможное» путешествие, всплески внерабочего времени)
• Повторяющиеся неудачные MFA или попытки входа (возможное захват аккаунта)
• Повышение привилегий (апгрейд роли консультанта, выдача нового админ‑доступа)
• Крупные или повторяющиеся выгрузки, особенно из ограниченных проектов

Экспорт и хранение

Предоставляйте экспорт аудита в CSV/JSON с фильтрами (диапазон дат, actor, project, action) и задавайте правила хранения по политике (например, по умолчанию 90 дней, для регламентированных команд — дольше). Документируйте доступ к экспортам аудита как привилегированное действие (и логируйте его). Для смежных контролей смотрите /security.

Проверки доступа и текущее управление

Выдать доступ — это только половина работы. Реальный риск накапливается тихо: консультант завершает проект, перестаёт входить — а аккаунт продолжает работать. Оngoing governance — это то, как вы не даёте «временному» доступу стать постоянным.

Делайте дашборды для ревью, которые люди действительно будут использовать

Создайте простой обзор для спонсоров и владельцев проектов, который каждый раз отвечает на одни и те же вопросы:

• Активные консультанты по проекту и ролям
• Последняя активность (и последняя чувствительная операция, если важно)
• Дата истечения доступа и оставшееся время
• Ожидающие утверждения, продления и исключения

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

Добавьте подтверждения (аттестации) со стороны владельцев

Планируйте аттестации — ежемесячно для систем с высоким риском, ежеквартально для менее рискованных — где владелец подтверждает, что консультант всё ещё нужен. Сделайте решение явным:

• Переутвердить на определённый срок (например, 30/60/90 дней)
• Снизить роль (минимальные привилегии)
• Отозвать доступ

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

Используйте правила неактивности, не нарушая работу

Неактивность — сильный сигнал. Введите правила типа «приостановить после X дней без входа», но сделайте предупредительный шаг:

1. Уведомить владельца/спонсора перед приостановкой или отзывом
2. Дать одно‑кликовую опцию «продлить» с новой датой
3. Автоматически отзывать при отсутствии ответа

Так вы избегаете тихих рисков и не блокируете людей неожиданно.

Отслеживайте исключения и пересматривайте их по таймеру

Некоторым консультантам понадобятся необычные права (доп. проекты, шире данные, дольше). Рассматривайте исключения как временные по своей природе: требуйте причину, дату окончания и запланированную проверку. Ваш дашборд должен выделять исключения отдельно, чтобы они не терялись.

Если нужен практический следующий шаг, свяжите задачи управления с админом (/admin/access-reviews) и сделайте эту страницу основной для спонсоров.

Оффбординг: отзыв, который действительно срабатывает

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

Явные триггеры оффбординга

Начните с определения событий, которые автоматически запускают оффбординг. Частые триггеры:

• Дата окончания контракта (запланирована заранее)
• Завершение проекта (проект помечен как "closed")
• Нарушения политик (инцидент безопасности, провал проверки доступа, запрос от HR/юристов)

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

Автоматизируйте отзыв, а не просто «убирание прав»

Отзыв должен быть полным и быстрым. Минимум автоматизируйте:

• Деактивацию учётной записи в приложении (или пометку как inactive)
• Удаление всех ролей/групп, дающих доступ к проектам и данным
• Отзыв активных сессий и токенов (веб‑сессии, refresh‑токены, API‑токены)

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

Передача данных и очистка секретов

Оффбординг — это также момент для наведения порядка в данных. Сделайте чек‑лист, чтобы ничего не осталось в личных почтовых ящиках или приватных дисках.

Типичные задачи:

• Результаты и артефакты: убедиться, что они загружены в пространство проекта и переданы внутреннему владельцу
• Ротация учётных данных: обновить пароли и ключи, которые могли быть известны консультанту (базы данных, API‑ключи, сервисные аккаунты)
• Очистка общих секретов: удалить упоминания в секрет‑хранилищах, общих папках, рассылках и чатах

Если в портале есть загрузка файлов или тикетинг, рассмотрите шаг «Export handover package», который собирает релевантные документы и ссылки для внутреннего владельца.

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

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

Полезные шаги верификации:

• Подтвердить, что у консультанта нет активных ролей и нет членств в проектах
• Подтвердить, что все сессии/токены отозваны и токенов не осталось
• Создать финальное offboarding audit event (кто запустил, когда это выполнено, что удалено, какие были исключения)

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

План реализации: API, UI, тестирование и деплой

План, который превращает политику доступа в рабочий продукт: небольшой набор API, простой интерфейс для админов/ревьюеров и достаточно тестов и процедур деплоя, чтобы доступ не ломался молча.

Если вам нужно быстро показать рабочую версию заинтересованным сторонам, подход типа vibe-coding может быть эффективен: описываете рабочий процесс, роли и экраны и итеративно доводите рабочее ПО, а не макеты. Например, Koder.ai помогает прототипировать внешний портал (React UI, Go backend, PostgreSQL) по чат‑спецификации, затем дорабатывать утверждения, задания на истечение и просмотры аудита с возможностью снапшотов/откатов и экспортом кода при переходе в формальный SDLC.

Поверхность API (держите её простой и предсказуемой)

Проектируйте эндпоинты вокруг объектов, которые вы уже описали (users, roles, projects, policies) и рабочей логики (requests → approvals → provisioning):

• Users & roles: GET /api/users, POST /api/users, GET /api/roles, POST /api/roles
• Access requests: POST /api/access-requests, GET /api/access-requests?status=pending
• Approvals: POST /api/access-requests/{id}/approve, POST /api/access-requests/{id}/deny
• Provisioning/expiry: POST /api/grants, PATCH /api/grants/{id} (extend/revoke), GET /api/grants?expires_before=...
• Audit: GET /api/audit-logs?actor=...&project=... (read-only; никогда не редактируйте логи)

На стороне UI стремитесь к трём экранам:

1. Портал консультанта (что у него есть, дата истечения, запросить доступ)
2. Входящие у утверждающего
3. Консоль администратора (роли, политики, гранты, поиск по аудиту)

Базовые меры безопасности везде

Валидируйте ввод на всех эндпоинтах записи, включите CSRF‑защиту для cookie‑сессий и лимитирование частоты запросов для логина, создания запросов и поиска по аудиту.

Если поддерживаете загрузку файлов (например, соглашения), используйте allowlist MIME‑типов, антивирусную проверку, ограничения по размеру и храните файлы вне web root с рандомными именами.

План тестирования (баги в правах — это баги продукта)

Покройте тестами:

• Тесты прав: «может/не может» по ролям, проектам и политическим ограничениям
• Тесты рабочих процессов: request → approve → grant created → уведомления
• Тесты временных ограничений: доступ прекращается в момент истечения, а «extend» требует утверждения

Заметки по деплою

Разделяйте dev/staging/prod, храните секреты в vault (не в env‑файлах в git) и шифруйте бэкапы. Добавьте периодическую задачу для истечения/отзыва доступа и тревогу, если она не работает.

Если нужен чеклист‑спутник, свяжите команду с /blog/access-review-checklist и держите информацию о пакете/ценообразовании на /pricing.

Финальный чеклист: как выглядит «хорошо»

Веб‑приложение для доступа консультантов справляется со своей задачей, когда оно стабильно даёт такие результаты:

• У каждого консультанта уникальная идентичность, MFA и область, привязанная к проекту.
• У каждого предоставления доступа есть владелец, утверждающий, обоснование и дата окончания.
• Истечение и отзыв автоматизированы (включая инвалидацию сессий/токенов).
• Исключения видимы, ограничены по времени и периодически пересматриваются.
• Логи достаточно консистентны, чтобы расследовать инциденты без догадок.

Постройте минимальную версию, которая обеспечивает эти инварианты, затем итеративно добавляйте удобные фичи (дашборды, массовые операции, расширенные политики), не ослабляя базовые контролы.