Software Architect · Модуль 16
Security — это не финальная проверка перед релизом. Это набор архитектурных решений о доверии, правах и границах.
Threat modeling · least privilege · authn · authz · audit
Безопасность начинается с вопроса: кому мы доверяем, почему и что будет, если это доверие нарушено?
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: что именно злоумышленник сможет сделать после компрометации одного компонента.
Хорошая 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?