Uploaded byPositive Hack Days
Требования по безопасности в архитектуре ПО
Документ описывает требования по безопасности в архитектуре программного обеспечения, включая функциональные и нефункциональные требования, такие как производительность, доступность и безопасность. Он предлагает методы анализа и проектирования, такие как отделение обязанностей, защищенная инфраструктура и использование паттернов, например, hexagonal architecture и single sign on. Кроме того, документ содержит рекомендации по тестированию и аудиту для обеспечения защиты от атак и поддержания целостности данных.
Требования по безопасности в архитектуре ПО
- 1. Заголовок ptsecurity.com Требования по безопасности в архитектуреПО Иванов Кирилл Архитектор Positive Technologies
- 2. ЗаголовокЦикл жизни ПО Требования Анализи Проектирование РазработкаТестирование Релиз и Поддержка
- 3.
- 4. Заголовок Архитектурно-значимые требования: • Функциональныетребования • Нефункциональные требования (атрибуты качества) • Ограничения • Требования цикла жизни ПО Требования
- 5. Заголовок • Производительность • Доступность •Надежность • Удобство использования • Легкость изменения • Безопасность • Тестируемость • … Нефункциональные требования
- 6. Заголовок • Одноразовые • Разработали забыл • Постоянные • Требуют поддержки при новых изменениях Нефункциональные требования
- 7. Заголовок • Конфиденциальность • Приватность •Разграничение доступа • Целостность • Подлинность данных • Защита от искажения • Доступность • Аудит Требования по безопасности
- 8. ЗаголовокСценарий нефункционального требования Источникстимула Неизвестный пользователь Артефакт SSO Сервис Измерение реакции Не менее 5 секунд Стимул Вводит логин Реакция Валидирует логин Окружение Онлайн, публичная сеть
- 9. Заголовок • Источник стимула •Пользователь • Другая система • Стимул • Атака на систему • Артефакт • Сервис в целом • Данные Формулировка требования
- 10. Заголовок • Окружение • Онлайнили офлайн • Под нагрузкой или нет • Подключена ли к сети • Положение: • в ДМЗ, • за сетевым экраном, • в открытой сети. Формулировка требования
- 11. Заголовок • Реакция • Аутентификацияпользователей • Авторизация действий • Аудит действий • Ведение лога транзакций • Нотификация операторов Формулировка требования
- 12. Заголовок • Измерение реакции •Время выполнения операции • Сложность восстановления после атаки • Вероятность обнаружения атаки • Скорость/вероятность идентификации источника атаки • Процент доступных сервисов после атаки • Процент потерянных данных Формулировка требования
- 13. Заголовок Идентифицированный пользователь справами администратора изменяет содержимое каталога. При штатной работе системы в течение дня возможно определить кто изменил каталог. Хакер изменяет пакет данных к Сервису Б, приходящий от Сервиса А из той же сети, Сервис Б не принимает пакет в обработку, 0% данных изменилось. Примеры формулировок
- 14. Заголовок • Надо немногознать ИБ • Заказчик их не формулирует • Есть стандарты! • ISO/IEC DTR 10181 • ГОСТ Р ИСО/МЭК ТО 13335 • PCI DSS • … • Необходимо думать в негативном ключе Особенность требований по безопасности
- 15. Заголовок Пользователь в банкоматеснимает деньги. • А если это не он? • Пусть карточка его подтвердит • А если карточка не у него? • Пусть введен ПИН, известный ему • А если он не забрал карточку? • Напоминание, удержание • А если… Негативное мышление: Пример
- 16. ЗаголовокАнализ и проектирование Требования Анализи Проектирование РазработкаТестирование Релиз и Поддержка
- 17. Заголовок • Все требованияне реализуешь • Что делать? • Ставим приоритеты в попугаях (Low, Medium, High) • ATAM (Architecture Trade-off Analysis Method) предлагает: • Важность для успеха системы • Сложность разработки (Риск) • Безопасность: Риск атаки для системы и данных Анализ
- 18. Заголовок • Защита отатак • Аутентификация пользователей • Авторизация пользователей • Поддерживать секретность данных • Поддерживать целостность • Ограничение доступа к ресурсам • Ограничение воздействия • Обнаружение атак • Восстановление после атак • Обнаружение атаки по аудиту • Восстановление данных и работоспособности Проектирование: Тактики
- 19. Заголовок • Separation ofConcerns • Secured Infrastructure • Hexagonal Architecture • Single Sign On • Event Sourcing • GateKeeper (API Gateway) Проектирование: Паттерны и подходы
- 20.
- 21.
- 22.
- 23. ЗаголовокSingle Sign On •OAuth 2.0 • OpenID Connect • WS Federation • SAML
- 24. ЗаголовокEvent Sourcing Состояние –последовательность примененных событий Событие 1 Событие 2 Событие 3 Состояние
- 25. ЗаголовокEvent Sourcing Событие –результат применения команды к состоянию Состояние Команда СобытиеСостояние
- 26. ЗаголовокEvent Sourcing: пример +100р.-50р. +100р. -40р. Состояние счета = сумма транзакций
- 27.
- 28. ЗаголовокEvent Sourcing: исследованиеистории +100р. Вася -50р. Петя +100р. Катя -40р. Коля Обнаружения сбоя/атаки
- 29.
- 30. ЗаголовокGateKeeper: Gateway protection КлиентGateWay Сервис Сервис Публичное API Доверенное API
- 31.
- 32. Заголовок • Ревью кода •Используйте готовые крипто-инструменты • Статический анализ кода (SAST) Разработка
- 33.
- 34.
- 35. ЗаголовокТестирование Источник стимула Неизвестный пользовательАртефакт SSO Сервис Измерение реакции Не менее 5 секунд Стимул Вводит логин Реакция Валидирует логин Окружение Онлайн, публичная сеть
- 36. ЗаголовокЦикл жизни ПО Требования Анализи Проектирование РазработкаТестирование Релиз и Поддержка
- 37. Заголовок • Software Architecturein Practice (Лен Басс, Пол Клементс, и Рик Казман) • ATAM (http://www.sei.cmu.edu/architecture/tools/evaluate/atam.cfm) • Event Sourcing (https://martinfowler.com/eaaDev/EventSourcing.html) • Hexagonal Architecture (http://fideloper.com/hexagonal-architecture) • SOA Pattens (http://arnon.me/soa-patterns/) Что почитать?
- 38.