В чём архитектурное отличие capability-подхода от проверки прав по идентичности субъекта при передаче доступа между сервисами?
Capability-подход передаёт не только идентичность субъекта, но и конкретное, ограниченное право на действие с ресурсом. Обладатель capability может предъявить её сервису, а сервис проверяет подлинность, область действия и срок права, не полагаясь исключительно на внешний идентификатор пользователя.
Проверка по идентичности отвечает на вопрос «кто вызывает», а capability — на вопрос «какое право явно передано этому вызывающему». Это уменьшает зависимость от доверия к цепочке сервисов, но вводит риск компрометации самого носителя capability.
Классические модели доступа обычно связывали субъектов, например пользователей и процессы, с объектами через списки контроля доступа или централизованные правила. Такой подход удобен для управления политиками, но при межсервисном взаимодействии требует распространять сведения об идентичности и поддерживать согласованную проверку прав в разных компонентах.
Capability-подход появился как способ представить право доступа отдельным защищённым объектом, который можно передать, ограничить и делегировать. Исходная проблема заключалась в уменьшении неявных полномочий процесса и в более точном контроле над тем, какие действия действительно разрешены.
Предположим, сервис заказов вызывает сервис документов от имени пользователя. Если сервис документов доверяет только переданному идентификатору пользователя или утверждению промежуточного сервиса, ошибка в одном компоненте может привести к доступу ко всем ресурсам, доступным этому пользователю.
В capability-модели вызывающая сторона получает право, например на чтение конкретного документа, с заданным сроком действия и набором операций. Неправильно спроектированная capability, являющаяся долгоживущим bearer-секретом без ограничения области применения, сама становится ключом ко всему ресурсу.
Capability — это защищённое представление права доступа. Оно может быть подписанным утверждением или случайным непрозрачным токеном, связанным с ресурсом, разрешёнными операциями, субъектом или контекстом, сроком действия и целевым сервисом.
При проверке сервис должен подтвердить несколько свойств: capability выдана доверенным источником или найдена в защищённом хранилище; она не изменена; ещё действительна; предназначена именно этому сервису; относится к нужному ресурсу и операции; при необходимости связана с конкретным субъектом или каналом вызова.
Главное преимущество — явная передача полномочия. Сервису не нужно автоматически доверять всей идентичности вызывающего компонента: наличие capability означает только конкретное право, а не полный набор прав пользователя или сервиса.
Ограничение — capability часто является bearer-секретом: тот, кто её получил, может использовать её в пределах срока и области действия. Поэтому нужны короткий срок жизни, минимальный scope, защита при передаче и хранении, привязка к аудитории или субъекту, а для чувствительных операций — подтверждение контекста вызова.
Отзыв capability сложнее, чем отзыв записи в централизованной политике. Возможные решения — короткоживущие токены, версии полномочий, список отзыва или централизованная проверка состояния. Каждый вариант создаёт компромисс между автономностью сервисов, задержкой проверки и сложностью управления.
Capability не отменяет авторизацию пользователя и не заменяет аудит. Часто применяют гибрид: централизованная политика решает, можно ли выдать capability, а целевой сервис локально проверяет саму capability и её ограничения.
Платформа аналитики позволяет пользователю временно передать внешнему сервису право скачать один отчёт. Вариант с передачей идентификатора пользователя и роли требует доверять внешнему сервису и повторять правила доступа внутри него. Ошибка в проверке может открыть все отчёты пользователя.
Вариант с постоянным API-ключом проще внедрить, но он даёт слишком широкие полномочия, плохо ограничивает срок действия и усложняет отзыв. Вариант с короткоживущей capability содержит идентификатор одного отчёта, операцию скачивания, целевой сервис и срок действия.
Выбран последний вариант: шлюз выдаёт capability только после обычной проверки прав пользователя, а сервис отчётов проверяет подпись, аудиторию, срок, ресурс и операцию. В результате компрометация внешнего сервиса ограничивается одним отчётом и коротким временным окном; цена решения — необходимость безопасной выдачи и продуманного механизма отзыва.
1. Достаточно ли сделать capability непредсказуемой?
Нет. Непредсказуемость защищает от угадывания, но не от кражи, повторного использования или чрезмерно широких полномочий. Capability должна передаваться по защищённому каналу, безопасно храниться, иметь минимальную область действия и ограниченный срок жизни.
Если токен может использоваться в любом контексте, его кража превращается в полноценный доступ. Поэтому для критичных операций полезны привязка к аудитории, субъекту, ключу вызывающей стороны или дополнительному подтверждению.
2. Как отозвать capability до истечения срока действия?
Самостоятельно проверяемый подписанный токен обычно не узнает об отзыве без обращения к дополнительному состоянию. Практические варианты — короткий срок жизни, проверка версии разрешений, централизованный список отзыва или интроспекция на стороне сервиса.
Короткие токены уменьшают окно компрометации, но требуют более частной выдачи. Централизованный отзыв быстрее даёт актуальное решение, однако добавляет зависимость от доступности и задержки центрального компонента.
3. Чем capability отличается от обычного JWT с ролью пользователя?
JWT с ролью обычно переносит утверждение об идентичности или групповой принадлежности, после чего сервис сам выводит из него разрешения. Capability непосредственно представляет делегированное право и должна быть ограничена конкретным ресурсом, операцией и контекстом.
Технический формат сам по себе не определяет модель: JWT тоже может содержать capability-подобное право. Различие определяется семантикой и жизненным циклом полномочия — способом выдачи, делегирования, ограничения и отзыва, а не наличием поля роли или форматом токена.