Краткий обзор
активной разработки
с оркестрацией ИИ
кода на Java и TypeScript
автоматических, из них ~420 интеграционных
публичного API с описанием в OpenAPI
CI/CD в Kubernetes
Проект
Identix — поставщик удостоверений, который компания размещает на собственной инфраструктуре. Одна установка обслуживает множество независимых приложений (арендаторов), и у каждого из них свои пользователи, роли, настройки входа и ключи подписи. Пароли, ключи и персональные данные никогда не покидают инфраструктуру оператора.
Идентификация — самая уязвимая с точки зрения безопасности часть любой системы: ошибка здесь ставит под удар все приложения, которые на неё опираются. Поэтому проекту требовалось сочетать широкую функциональность с архитектурой безопасности, способной выдержать строгую проверку. Платформу спроектировал и создал один инженер, он же её сопровождает.
Что было создано
Сервер авторизации — OAuth 2.0 и OpenID Connect на базе Spring Authorization Server: отдельный издатель токенов (issuer) и собственные ключи подписи для каждого арендатора, ротация токенов обновления и мгновенный отзыв токенов.
- Строгая изоляция арендаторов — каждый запрос ограничен своим арендатором, а соблюдение этого правила обеспечивают автоматические архитектурные тесты
- Пользователи, роли, группы и организации — с массовым импортом и экспортом и собственной парольной политикой для каждого арендатора
- Двухфакторная аутентификация (TOTP) с кодами восстановления
- Вход от имени пользователя с аудитом — администратор может действовать от имени пользователя, и каждый такой сеанс фиксируется
- Веб-хуки с подписью HMAC для событий жизненного цикла пользователей
- Журнал аудита — записи только добавляются и не изменяются, журнал ведётся отдельно для каждого арендатора, а оператору доступно сводное представление по всем арендаторам
- Экспорт и импорт конфигурации арендаторов между установками
Консоль администратора — React и TypeScript, интерфейс на английском и русском языках, адаптация от настольного компьютера до телефона и встроенный раздел для разработчиков: руководства по интеграции и интерактивная документация API.
Публичный API — 237 операций, полностью описанных в OpenAPI.
Инфраструктура — три сервиса в Kubernetes с чартами Helm, PostgreSQL и Redis, а также три конвейера CI/CD в GitLab, которые собирают, тестируют и развёртывают каждый сервис. Если не проходит хотя бы один тест, развёртывание блокируется.
Безопасность, заложенная в архитектуру
Архитектура разделяет зоны доверия. Публичный сервер авторизации не имеет доступа к базе данных и не хранит закрытых ключей: все данные и вся подпись токенов находятся во внутреннем сервисе, доступном только внутри кластера. Ключи подписи хранятся в зашифрованном виде и расшифровываются только в памяти, поэтому компрометация публичного узла не раскрывает ни ключей, ни данных.
Работа над безопасностью была частью методологии, а не запоздалым дополнением:
- Модель угроз по методике STRIDE: защищаемые активы, профили нарушителей, границы доверия и контрмера для каждой угрозы
- Документация по безопасности для аудиторов с соотнесением мер защиты с требованиями OWASP ASVS уровня 2 и рекомендациями IETF по безопасному применению OAuth 2.0 и JWT
- Аудит безопасности успешно пройден; все выявленные замечания устранены
Метод
Один инженер в роли архитектора и оркестратора ИИ-агентов, работающий по методологии Specification-Driven Development. Работа началась с письменной спецификации (требования, модель данных, инварианты безопасности), а каждое значимое решение до начала реализации фиксировалось в виде записи архитектурного решения (ADR).
ИИ-агенты генерировали код, тесты и документацию на основе этой спецификации; инженер проверял каждое изменение, отвечал за архитектуру и модель безопасности и нёс ответственность за каждый коммит. Инфраструктуру (манифесты Kubernetes, чарты Helm, конвейеры CI/CD) тот же человек создал тем же способом.
Разработка не была непрерывной: проект продвигался этапами с перерывами между ними. Если считать только дни, в которые работа действительно велась, создание платформы заняло 40 рабочих дней.
Технологический стек
Сравнение с традиционной разработкой
| Типичная традиционная команда (оценка) | Этот проект (с ИИ) | |
|---|---|---|
| Сроки | 6–9 месяцев | 40 рабочих дней |
| Команда | 4–6 инженеров | 1 инженер |
| Инфраструктура и CI/CD | Отдельный DevOps-инженер | Включены, тот же инженер |
| Безопасность | Модель угроз и аудит часто откладываются | Модель угроз по STRIDE, аудит пройден |
| Документация | Пишется задним числом, если вообще пишется | Спецификация и ADR с первого дня |
| Автоматические тесты | Варьируется | ~1 700 |
Выводы
Управление идентификацией и доступом — не самая очевидная область для демонстрации быстрой разработки: здесь обширная функциональность сочетается с бескомпромиссными требованиями к безопасности. Identix показывает, что метод работает и в этой области.
Один инженер. 40 рабочих дней. Мультиарендный сервер авторизации, консоль администратора, публичный API из 237 операций, около 1 700 автоматических тестов, Kubernetes и CI/CD, а также архитектура безопасности, подкреплённая моделью угроз и пройденным аудитом.
Решающую роль сыграла не скорость генерации кода, а дисциплина вокруг неё: сначала спецификация, все решения зафиксированы, каждое изменение проверено. Именно это делает систему пригодной к сопровождению и позволило бы другой команде принять её.