Глава 35. Безопасность данных — не только авторизация

35.1. Авторизация — только один слой

До сих пор основным вопросом был:

Может ли субъект выполнить действие над объектом?

Но безопасность данных шире.

Она включает как минимум:

Authentication
Authorization
Integrity
Confidentiality
Audit
Lifecycle
Operational security

Авторизация определяет допустимость действия.

Она не отвечает на все остальные вопросы.

35.2. Разрешение не определяет форму данных

Пусть:

User A → READ → Customer X

Это ещё не отвечает на вопросы:

Какие поля можно показать?
Можно ли экспортировать данные?
Можно ли передать их другому пользователю?
Можно ли положить их в кэш?
Можно ли записать их в лог?
Можно ли использовать их для аналитики?

Следовательно:

READ permission

не является универсальным разрешением на любое использование результата.

35.3. Конфиденциальность может продолжиться после SELECT

Предположим, база данных вернула разрешённую строку.

Дальше данные могут попасть в:

API response
cache
search index
report
log
message
analytics store
backup

Каждый такой путь становится потенциальной поверхностью раскрытия.

Поэтому:

Database authorization

не заканчивает security architecture.

35.4. Производные данные тоже требуют защиты

Мы уже видели, что security projections являются производными данными.

Но то же относится к бизнес-данным.

Например:

Document
    ↓
Search index
    ↓
Search result

Если исходный документ стал недоступен, индекс не должен продолжать его выдавать.

То же относится к:

• кэшам;

• полнотекстовым индексам;

• embeddings;

• отчётам;

• агрегатам;

• экспортам.

Изменение права может требовать изменения не только ACL.

35.5. Авторизация и целостность

Авторизация отвечает:

Можно ли выполнить действие?

Целостность отвечает:

Что произойдёт с данными, если действие выполнено?

Например, пользователь может иметь:

UPDATE

но это ещё не означает, что любое изменение допустимо с точки зрения предметной области.

Могут существовать правила:

document.state = DRAFT

или:

revision is editable

Это уже не обязательно authorization rule.

Это может быть бизнес-инвариант.

35.6. Аудит не заменяет авторизацию

Аудит отвечает:

Что произошло?

Авторизация отвечает:

Можно ли было это сделать?

Логирование операции после её выполнения не предотвращает несанкционированный доступ.

Поэтому:

Audit ≠ Authorization

Но аудит остаётся частью общей security architecture.

35.7. Технический компонент и субъект

В распределённой системе запрос может выглядеть так:

User A
   ↓
Service B
   ↓
Service C
   ↓
Database

Физический SQL выполняет Service C.

Но бизнес-субъектом действия может оставаться User A.

Поэтому нужно различать:

Authentication source
Technical caller
Business subject
Database connection

Смешение этих понятий может привести к ошибочному разрешению.

35.8. Администратор и доверенные компоненты

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

rebuild
migration
maintenance
bootstrap

Это не обязательно обычные пользовательские действия.

Поэтому модель доверия к инфраструктурному компоненту должна быть определена отдельно.

Нельзя просто предположить:

service = admin

если архитектура этого явно не утверждает.

35.9. Шифрование и авторизация

Шифрование решает другую задачу.

Оно защищает данные:

at rest
in transit

но не отвечает само по себе на вопрос:

Может ли User A прочитать Object X?

Поэтому:

Encryption ≠ Authorization

Они дополняют друг друга.

35.10. Резервные копии и срок хранения

Обычная authorization model работает с текущими данными.

Но резервная копия может содержать состояние, существовавшее месяц назад.

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

Поэтому:

Retention
Backup
Recovery

имеют собственную security semantics.

35.11. Полная цепочка

В результате архитектуру безопасности данных полезно представлять шире:

Authentication
      ↓
Subject
      ↓
Authorization model
      ↓
Effective permission
      ↓
Object authorization
      ↓
Data enforcement
      ↓
Physical data
      ↓
Response
      ↓
Cache / Log / Index / Export

Каждый переход может создать новую поверхность риска.

35.12. Главный вывод

Авторизация отвечает на важнейший вопрос:

Can(Subject, Action, Object)?

Но безопасность данных требует большего.

Нужно понимать:

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

Поэтому authorization model должна быть частью security architecture, но не должна подменять её целиком.