# 16. Безопасность

Как встроить security в архитектуру: threat modeling, least privilege, authn/authz, secrets, audit и secure defaults.

- **Author:** Фёдор Чищин
- **Level:** advanced
- **Reading time:** ~25 минут чтения
- **Published:** 2026-05-23
- **Source:** https://fedorthinks.com/ru/learn/software-architect-16-security

---

## 1. Главная идея

Безопасность начинается с вопроса: кому мы доверяем, почему и что будет, если это доверие нарушено?

### Authn и authz — разные вещи

> Паспорт подтверждает личность. Билет подтверждает право войти в зал. Это не один документ.

Authentication отвечает на вопрос «кто это?». Authorization отвечает на вопрос «что ему можно?». Частая ошибка — успешно проверить identity и забыть проверить доступ к конкретному ресурсу.

Архитектор должен определить модель прав: RBAC, ABAC, ownership-based access, tenant isolation, service-to-service permissions. Особенно важно проектировать authorization на уровне бизнес-действий, а не только endpoint-а.

### Least privilege снижает blast radius

> Ключ от квартиры не должен открывать весь район. Если его украдут, ущерб должен быть ограничен.

Каждый пользователь, сервис, token и job должны иметь минимально достаточные права. Secrets не должны жить в коде. Production доступ должен быть ограничен, логирован и регулярно пересматриваться.

Security architecture оценивает не только вероятность атаки, но и blast radius: что именно злоумышленник сможет сделать после компрометации одного компонента.

## 2. Пример и антипример

Хорошая security-модель делает безопасный путь самым простым для разработчика.

### Пример: tenant isolation в репозитории

> В бизнес-центре каждый офис имеет свою дверь, а не табличку «пожалуйста, не заходите».

Все запросы к данным проходят через repository, который требует `tenantId` из trusted context. Query builders автоматически добавляют tenant predicate, а integration tests проверяют невозможность cross-tenant чтения.

Это лучше, чем просить каждого разработчика помнить фильтр вручную.

### Антипример: admin flag в JWT без проверки ресурса

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

API проверяет только `isAdmin=true`, но не проверяет workspace, role scope и ownership ресурса. Один токен даёт слишком много возможностей. При утечке ущерб максимален.

Authorization должна быть контекстной: субъект, действие, ресурс, tenant, условия.

#### Самопроверка

- Где границы доверия в системе?
- Что произойдёт при утечке одного service token?
- Где проверяется authorization на уровне ресурса?
- Какие действия попадают в audit log?

Следующий модуль: [Наблюдаемость](./software-architect-17-observability).