«Представление о безопасности через разрешения, это примитивная модель, которая не может описать реальные системы. Capability-based security даёт другой взгляд: это способ описывать доступ как сущность, а не как таблицу. Я попробую показать, как эта модель укладывается в более строгий математический язык, и почему это не просто ‘способ обойти 152-ФЗ’, а фундаментальный сдвиг в понимании.»
От контроля списков к контролю объектов
Традиционная модель контроля доступа (DAC, MAC, RBAC) строится вокруг субъекта, объекта и таблицы разрешений. Субъект запрашивает доступ к объекту, а система безопасности сверяет этот запрос с правилами в таблице. Этот подход хорошо ложится на формализацию, проверку соответствия и требования регуляторов вроде 152-Ф3 или ФСТЭК: есть политика, есть журналы, есть субъекты с ролями. Однако её фундаментальная проблема — централизованность и глобальность. Правило в таблице, это глобальное утверждение, которое должно быть истинным для всей системы в каждый момент времени. Это создаёт сложность управления и проверки.
Capability-based security инвертирует этот подход. Вместо таблицы, где субъекту что-то разрешено, у субъекта есть набор способностей (capabilities). Способность, это неразрывный, неотчуждаемый объект, который одновременно является и ссылкой на ресурс, и разрешением на выполнение с ним определённых операций. Чтобы получить доступ, субъект должен предъявить соответствующую способность. Нет способности — нет доступа. Принцип минимальных привилегий здесь реализуется не запретом в таблице, а физическим ограничением: что не передано, того и нет.
Что такое capability на практике
Категория «способность» звучит абстрактно, но её аналоги существуют в разных системах. Рассмотрим несколько примеров:
- Файловый дескриптор в Unix-like системах. Программа получает от ядра дескриптор открытого файла. Этот дескриптор, это и есть способность: он ссылается на конкретный файл (ресурс) и содержит в себе права, с которыми файл был открыт (например, read-write). Программа может передать этот дескриптор другому процессу, но не может произвольно изменить права, связанные с ним.
- Ссылка на объект в объектно-ориентированных средах или современных микросервисных архитектурах. Ссылка на сервис (например, gRPC stub или ссылка на actor-систему) является способностью для вызова методов этого сервиса. Чтобы получить такую ссылку, её нужно явно получить при инициализации или через механизм discovery, который сам контролирует, кому какие ссылки выдавать.
- Токены доступа (OAuth, JWT) в некотором приближении. Хотя они часто используются для аутентификации, в контексте определённого API валидный токен может выступать как способность доступа к этому API с определённой scope. Однако токены часто имеют время жизни и могут быть отозваны централизованно, что несколько противоречит идее неотчуждаемости.
Ключевое свойство capability, это сочетание обозначения (reference) и полномочия (authority). Его нельзя подделать, а передача является основным механизмом распределения прав.
Математический язык: почему категории
Для описания сложных систем простых аналогий недостаточно. Нужен строгий язык, который позволит рассуждать о структуре, композиции и преобразовании прав. Теория категорий предоставляет такой язык, оперируя объектами и морфизмами (стрелками) между ними.
В категориальной модели capability-based системы можно представить так:
- Объекты: Типы ресурсов (например, Файл, Сокет, Сенсор) или даже более абстрактно — интерфейсы с определёнными операциями.
- Морфизмы: Capabilities. Морфизм из объекта A (субъекта или контекста) в объект B (ресурс), это способность, которой обладает A, чтобы взаимодействовать с B определённым образом. Морфизм «несёт» в себе право.
- Композиция: Если у субъекта есть способность к ресурсу B, а ресурс B имеет способность делегировать доступ к ресурсу C (например, B, это прокси), то через композицию морфизмов субъект может получить доступ к C. Это формализует цепочки доверия и делегирование.
- Тождественный морфизм: Способность объекта взаимодействовать с самим собой (базовый доступ).
Такое представление превращает систему прав из набора статических записей в динамическую графовую структуру, где пути доступа строятся через композицию имеющихся стрелок.
Параллели с реальными системами и ограничениями
Категориальный взгляд помогает увидеть фундаментальные ограничения capability-модели в контексте требований российского регуляторика.
1. Проблема изоляции и мониторинга. В идеальной capability-системе нет глобальной таблицы, которую можно проверить. Аудит «кто на что имеет право» сводится к анализу графа распределения capabilities по всем субъектам. Для внешнего наблюдателя (аудитора, системы SIEM) это сложнее, чем прочитать ACL. Требования ФСТЭК к контролю и регистрации событий доступа (СЗИ) предполагают наличие централизованного журнала. Capability-система должна явно генерировать события при создании, передаче и использовании capability, что добавляет накладные расходы.
2. Проблема отзыва прав. В модели чистых capabilities отозвать право у субъекта, которому оно уже передано, невозможно без участия самого субъекта или промежуточного объекта (паттерн «revocation capability»). Это противоречит ряду административных сценариев, где требуется мгновенный централизованный отзыв доступа. Категориально это можно смоделировать как изменение или «обнуление» морфизмов в графе, но реализация требует дополнительных механизмов, выходящих за рамки базовой модели.
3. Соответствие 152-Ф3. Закон говорит о необходимости определения перечня лиц, которым разрешён доступ, и обработки информации. Capability-модель не отменяет эту необходимость, но меняет точку приложения. «Перечень лиц» становится не статическим списком в политике, а динамическим графом выданных capabilities. Доказательство соответствия требует новых методов верификации, например, статического анализа кода или протоколов на предмет проверки того, что capability на доступ к персональным данным не может «утечь» по неконтролируемым путям.
Категориальные паттерны для безопасных систем
Использование категорий позволяет не только описывать, но и проектировать. Вот несколько паттернов, вытекающих из этой формализации:
- Функторы безопасности: Преобразование одной системы прав (категории) в другую. Например, «функтор аудита», который для каждой capability в рабочей системе автоматически создаёт capability к лог-сервису и обеспечивает композицию — любое использование исходной capability приводит к записи в лог. Это формализует требование «обязательного сопровождения».
- Моноидальное замыкание для изоляции: Если ресурсы и capabilities организованы в моноидальную категорию (есть операция «тензорного произведения» ⊗), то можно моделировать изолированные контейнеры или sandbox-ы. Capability внутри одного тензорного сланда не может быть скомпонована с capability из другого без явного capability на «мост», что обеспечивает изоляцию на уровне модели.
- Ограничители (Limiters) как универсальные свойства: Требование, что доступ к критическому ресурсу R всегда должен проходить через промежуточный фильтр F (например, валидатор), можно выразить как универсальное свойство категории: для любого морфизма X → R должен существовать уникальный морфизм X → F, через который он факторизуется. Это значит, что архитектурно обойти фильтр F будет невозможно.
Эти паттерны — не просто абстракции. Они находят отражение в архитектуре современных безопасных сред исполнения, изолированных сервисных сетях (service mesh) с sidecar-прокси, которые реализуют именно такие «категориальные» ограничения на маршрутизацию и доступ.
Вместо заключения: новая плоскость для диалога с регулятором
Стандартный подход к выполнению требований ФСТЭК и 152-Ф3 часто сводится к построению сложных систем управления доступом на основе ролей, многоуровневых паролей и громоздких матриц. Capability-подход, особенно осмысленный через категориальный аппарат, предлагает альтернативу: строить систему изначально так, чтобы нежелательный доступ был в ней структурно невозможен, а не просто запрещён правилом.
Это требует от разработчиков и архитекторов иного мышления: думать не в терминах «запретить кому-то», а в терминах «что именно и кому передать». А от регулятора — готовности принять иные, более сложные, но потенциально более доказуемые методы обоснования безопасности, такие как формальная верификация графа capabilities или доказательство изоляционных свойств через свойства категории.
Теоретико-категорный анализ не делает систему безопасной сам по себе. Но он даёт точный язык для описания её архитектуры безопасности, который позволяет выявлять слабые места, проектировать композиционные гарантии и, в конечном итоге, строить системы, где безопасность, это свойство структуры, а не настройки.