Возможность управлять задачами от имени другого человека может отвечать реальной потребности бизнеса, но не должна требовать передачи паролей или предоставления общего доступа к учётной записи. В PHP-приложении безопасное делегирование должно однозначно определять, кто действует, кого он представляет, с какими ресурсами может работать и как долго. Делегирование также должно поддаваться отзыву и аудиту.
Цель — разрешить конкретное действие, сохранив идентичность обоих участников. Для этого недостаточно добавить экран выдачи разрешений: делегирование затрагивает модель данных, каждую точку авторизации, асинхронные операции и тесты. Совместное проектирование этих элементов снижает риск того, что действительное делегирование на одном экране через альтернативный маршрут приведёт к чрезмерному доступу.
Разграничьте делегирование, имперсонацию и общий доступ
При делегировании инициатором операции остаётся аутентифицированный пользователь. Кроме того, приложение фиксирует, что он действует от имени другого человека в рамках ограниченного разрешения. Представляемый человек не входил в систему и не должен отображаться как непосредственный автор запроса.
Имперсонация меняет фактическую идентичность, с которой система обрабатывает запрос, и при отсутствии специальных мер контроля может скрыть, кто выполнил действие. Общий доступ, например передача учётных данных, устраняет разделение между пользователями и затрудняет отзыв разрешений и атрибуцию действий. В обычном сценарии делегирования ни один из этих подходов не заменяет явный контекст исполнителя и представляемого лица.
Рекомендуется явно обозначать обе роли в коде и журналах. Например, actor_id указывает на того, кто выполнил операцию, а principal_id — на человека, от имени которого она выполнена. Избегайте неоднозначных имён вроде user_id в записях, где оно может относиться к любому из этих участников.
Определите область действия, ресурсы и срок до реализации
Полезное делегирование точно описывает, что именно оно разрешает. Формулировка «управлять учётной записью» обычно слишком широка. Вместо этого разрешение можно ограничить такими действиями, как просмотр задач, изменение их статуса или ответ на запрос. Если действия имеют разные последствия, задавайте для них отдельные разрешения, а не объединяйте чтение, редактирование, утверждение и удаление в одну общую возможность.
Также определите область ресурсов: организацию, проект, очередь задач или конкретный набор записей. Разрешение редактировать задачи одного проекта не должно давать возможность читать данные другого проекта только потому, что делегированный пользователь может получить к ним доступ в рамках другой функции.
Для срока действия задайте чёткие начало и окончание, а также статус, позволяющий отозвать делегирование до истечения срока. Определите часовой пояс для отображения дат и обеспечьте согласованность внутренних сравнений. Если политика требует утверждения или запрещает цепочки делегирования, оформите это как явное проверяемое правило, а не как условность интерфейса.
Смоделируйте авторизацию и проверяйте её для каждой операции
Реляционная схема может представлять делегирование с помощью таких полей, как идентификатор, уполномоченный исполнитель, представляемое лицо, область действия, действия, дата начала, дата истечения, статус, создатель и дата отзыва. Точная структура зависит от предметной области: действия можно хранить в связанной таблице или в другом валидируемом формате, но их должно быть возможно запрашивать и проверять без неоднозначных толкований.
Авторизация должна отделять полномочия представляемого лица от разрешения, делегированного исполнителю. Для запрошенной операции проверьте, имело бы представляемое лицо обычный доступ к ресурсу и допускают ли это применимые бизнес-правила. Затем убедитесь, что аутентифицированный исполнитель является адресатом действующего и не отозванного делегирования и что оно разрешает это действие над данным ресурсом. Фактическое разрешение ограничено доступом представляемого лица и областью делегирования: делегирование не может предоставить исполнителю больше действий или ресурсов, чем представляемое лицо вправе разрешить, или больше, чем указано в самом делегировании. Не требуйте, чтобы исполнитель имел собственный доступ к ресурсу: он может действовать именно благодаря делегированию. При этом применяйте ограничения, обусловленные идентичностью исполнителя, например требования к аутентификации, принадлежности к нужному контексту или меры безопасности для операции.
На практике проверка должна включать:
- Аутентифицирован ли исполнитель и предназначено ли делегирование именно ему.
- Имеет ли представляемое лицо право действовать в данном контексте и есть ли у него обычный доступ к запрошенному ресурсу.
- Активно ли делегирование на момент операции, не отозвано ли оно и не истёк ли срок его действия.
- Входят ли запрошенное действие и ресурс в предоставленную область действия и не превышают ли полномочия представляемого лица.
- Соблюдаются ли применимые бизнес-правила и ограничения безопасности для исполнителя и операции.
Централизуйте это решение в сервисе авторизации или повторно используемой политике вместо того, чтобы дублировать отдельные условия в контроллерах. При этом вызывайте проверку для каждой соответствующей операции: защищённое представление автоматически не защищает API, скачивание, массовое действие или маршрут администрирования. В PHP контроллер может получить аутентифицированного исполнителя, определить контекст делегирования и запросить у сервиса авторизацию действия над конкретным ресурсом. Слой домена также может обеспечивать критически важные инварианты, если операция имеет серьёзные последствия.
Не доверяйте principal_id, переданному браузером, как доказательству авторизации. Сервер должен проверять связь между исполнителем, представляемым лицом, делегированием, ресурсом и действием по доверенным данным. Также не исходите из того, что скрытая в интерфейсе кнопка помешает напрямую вызвать endpoint.
Сохраняйте атрибуцию при аудите и асинхронных операциях
Полезная запись позволяет восстановить ход событий, не смешивая идентичности. Для каждого значимого события сохраняйте исполнителя, представляемое лицо, действие, тип и идентификатор ресурса, дату, результат и ссылку на применённое делегирование. В зависимости от риска также фиксируйте причину операции или идентификатор корреляции. Не храните в истории секреты или ненужные персональные данные.
Атрибуция должна сохраняться и в очередях, и в фоновых задачах. Если делегированный запрос ставит задачу в очередь, сообщение должно содержать проверяемый контекст с исполнителем, представляемым лицом и ссылкой на разрешение, а не зависеть от веб-сессии, которая к тому времени уже будет недоступна. При выполнении задачи решите, нужно ли повторно проверять, остаётся ли делегирование активным. Для действия, которое ещё можно отменить, проверка в момент выполнения обычно помогает не допустить, чтобы после отзыва делегирования в очереди осталась задача с устаревшим разрешением. Если операция уже стала необратимой, задокументируйте эту границу и зафиксируйте момент авторизации.
Защищайте журналы от несанкционированного изменения и ограничивайте круг лиц, которые могут их просматривать. Аудит должен помогать расследованию и обеспечению подотчётности, но не становиться бесконтрольной копией операционных данных.
Предусмотрите истечение срока и отзыв в рамках процесса
Истечение срока и отзыв — это не просто изменение статуса на экране. Сессия, сохраняющая контекст делегирования, может продолжать показывать устаревшие параметры, поэтому серверная авторизация должна проверять актуальный статус при каждом запросе, даже если интерфейс тоже обновляется. Если разрешения кэшируются, определите, как инвалидировать кэш и какую максимальную задержку до вступления отзыва в силу можно допустить.
При отзыве фиксируйте, кто и когда его выполнил. Явно определите порядок обработки активных сессий, выпущенных токенов, задач в очереди и связанных временных ссылок. Не исходите из того, что завершение сессии или изменение записи в базе данных автоматически делает недействительными все эти элементы. Выбор решения зависит от архитектуры, но его нужно определить до запуска процесса.
Проверьте границы и часто упускаемые из виду сценарии
Тесты должны проверять как разрешённые, так и запрещённые действия. Как минимум включите делегирование, срок действия которого ещё не начался, уже истёкшее или отозванное; исполнителя, отличного от уполномоченного; ресурс за пределами области действия; непредоставленное действие; неверное представляемое лицо или отсутствие у него обычного доступа к ресурсу; а также прямой доступ к endpoint, которые не отображаются в интерфейсе. Добавьте и положительный сценарий, в котором у исполнителя нет собственного доступа к ресурсу, но представляемое лицо имеет такой доступ, а делегирование охватывает действие и ресурс. Так можно проверить, что система не смешивает собственные разрешения исполнителя с делегированными полномочиями.
Добавьте тесты на временные границы, конкурентные изменения и косвенные эффекты. Например, проверьте, что происходит при отзыве делегирования во время выполняющейся операции или ожидающей задачи и вызывает ли действие над задачей уведомления, экспорт или побочные изменения. Убедитесь, что эти эффекты сохраняют правильную атрибуцию и не расширяют область действия.
Разделяйте модульные тесты политики авторизации и интеграционные тесты, проходящие через маршруты, хранение данных и очереди. Тест, проверяющий только метод принятия решения, не доказывает, что его вызывают все маршруты; тест интерфейса также не подтверждает защиту сервера.
Контрольный список перед публикацией
- Чётко ли различаются исполнитель и представляемое лицо в коде, интерфейсе и аудите?
- Ограничивает ли каждое делегирование действия, ресурсы и срок действия, исключая недопустимые сочетания?
- Проверяет ли политика доступ представляемого лица и ограничивает ли исполнителя областью делегирования, не требуя от него собственного доступа к ресурсу?
- Проверяет ли каждая операция на сервере идентичность, статус, срок, область действия и разрешённое действие?
- Влияет ли отзыв на сессии, токены, кэши и ожидающие задачи согласно определённой политике?
- Позволяют ли журналы атрибутировать действия, не сохраняя ненужную информацию?
- Охватывают ли тесты отказы, временные границы, действительные делегирования без собственного доступа исполнителя и косвенные эффекты?
Делегирование безопасно, если его нельзя спутать с доступом к чужой учётной записи и если каждое действие можно обосновать полномочиями представляемого лица и действующим ограниченным делегированием. Если команда не может точно ответить, кто действовал, от чьего имени, с каким ресурсом и на основании какого разрешения, процесс ещё требует доработки до выхода в production.
