— Что вы можете сказать о базовых принципах безопасного проектирования программного обеспечения на разных его этапах? Что поменялось в подходах к безопасности разработки ПО в последние годы?
— Подходы к проектированию ПО заметно эволюционировали и продолжают изменяться в лучшую сторону. Если ещё лет десять назад вообще не особо задумывались о том, что решение должно быть безопасным, то сейчас это стало императивом на протяжении всего жизненного цикла разработки, начиная с проектирования. В частности, security by design представляет собой такой подход к проектированию ПО, при котором требования безопасности учитываются на самых ранних стадиях разработки, когда только закладывается бизнес-функционал.
Но есть и другая сторона медали. Разработка сейчас активно идёт в сторону использования микросервисного софта. Для того чтобы им успешно централизованно управлять, необходимо использовать специальные средства автоматизации, такие как контейнеры и системы оркестрации. И это сильно расширяет поверхность атаки, усложняя задачу проектирования.
— Как моделирование угроз применяется при разработке ПО?
— В рамках данного метода мы представляем себя на месте злоумышленника, причём ещё на этапе проектирования софта. Для начала надо в целом описать, как данные перемещаются в системе. Затем можно применить различные методологии для моделирования угроз. Например, мы в своей практике чаще всего используем методологию STRIDE. С её помощью дальше описываем угрозы, которые могут появиться при реализации нового функционала.
При моделировании угроз необходимо придерживаться базовых принципов — в частности, это принципы наименьших привилегий и безопасности настроек по умолчанию.
На завершающем этапе необходимо приоритизировать устранение угроз по степени риска: уже на этапе проектирования мы закладываем средства защиты против самых критичных из них. Моделирование угроз позволяет нам проиграть сценарий атаки на бумаге, выявив и заложив устранение рисков. И это будет намного дешевле, нежели исправлять эти угрозы в продакшене, а ещё хуже — если уязвимость будет проэксплуатирована и компания понесёт определённые финансовые потери.
— Насколько выбор конкретного стека технологий, языка программирования влияет на безопасность итогового продукта?
— Прямого ответа на этот вопрос не существует. Безопасность — это всё-таки свойство применения технологии и во многом зависит от того, кто или как эту технологию применяет. С этой точки зрения нельзя выделить какой-то язык программирования с исключительным правом использования.
Например, для высокоуровневых приложений можно отдавать предпочтение языкам, которые управляют памятью автоматически, что в ряде случаев исключает целый класс критических уязвимостей, таких как переполнение буфера и утечки памяти. Эти проблемы часто встречаются в программном обеспечении, которое написано на C, C++.
Важно сказать, что языки программирования часто уже определены и сильно повлиять на этот процесс в большинстве случаев не получается. Поэтому выход у службы безопасности следующий: необходимо уметь жить с теми технологиями, которые нам предоставляет бизнес. Можно разрабатывать стандарты и правила безопасного кодирования и контролировать их выполнение. Также следует проявлять осмотрительность при работе с open-source-библиотеками, так как многие из них содержат уязвимости.
— Какие архитектурные решения сегодня считаются более предпочтительными (например, микросервисы против монолитов)?
— В монолитной архитектуре риски сконцентрированы. Если злоумышленник находит уязвимость, которая позволяет сломать периметр защиты, он сразу получает доступ ко всей системе и всем данным сразу. Преимущество в том, что единый периметр можно усиленно контролировать и защищать, чему службы ИБ уже давно научились.
В микросервисной же архитектуре риски распределены. Новые вызовы связаны с тем, что увеличивается поверхность атаки и возникает угроза горизонтального перемещения. Таким образом, перед злоумышленником стоит задача скомпрометировать один слабый сервис и использовать его как плацдарм для атак на другие, более критичные сервисы.
Именно поэтому микросервисы требуют принципиально другого подхода к безопасности. Основные требования, которые необходимо закладывать в архитектуру, — это строгая сетевая сегментация, использование servicemesh, индивидуальной аутентификации и, конечно же, принципа наименьших привилегий для каждого сервиса. Главное архитектурное преимущество микросервисов с точки зрения ИБ — это возможность изолировать атаку и ограничить ущерб за счёт создания безопасной среды исполнения на стадии проектирования.
— Какими принципами необходимо руководствоваться при проектировании АПИ?
— Есть несколько основных паттернов, которые необходимо использовать при проектировании API. В соответствии с принципом минимальных привилегий на уровне API каждый пользователь получает лишь необходимый и достаточный набор прав. Не надо создавать универсальный эндпоинт. Также необходимо строго валидировать API-схему и парсинг данных.
Следующий паттерн — это идемпотентность и безопасность используемых методов. Это предполагает следование стандартам HTTP. GET-запросы не должны изменять состояние системы. Применение методов POST или PUT позволяет выстроить дополнительную защиту от случайных повторов и ряда команд. Для предотвращения сбоя в доступности следует установить лимиты. API без лимитов запросов — это потенциальное появление DOS-атак и различных видов злоупотребления.
Ещё один важный принцип — это безопасность по умолчанию. Необходимо закладывать версионирование API с самого начала, что позволит нам вносить критические изменения в безопасность в новой версии без ущерба для старых клиентов. Важно проектировать политику устаревания для прежних, менее безопасных версий. Конечно, за версиями API необходимо строго следить, чтобы не получилось так, что из-за человеческого фактора (например, разработчик забыл отключить старый эндпоинт при выпуске нового) не появлялись возможности проэксплуатировать какие-то уязвимости.
— Как привить культуру безопасности в команде разработки?
— Тут можно идти несколькими путями: либо сверху вниз, либо снизу вверх. Что я под этим подразумеваю? В первом варианте мы обсуждаем внедрение практик культуры на уровне руководства. И в целом в любом случае наступают моменты, когда приходится это делать. Речь может идти о разъяснении значимости этих практик и необходимого времени для их внедрения. После обоснования перед руководством практики спускаются вниз и так далее.
В другом варианте мы первым делом начинаем общаться с разработчиками. Ситуация выглядит идеально, когда в командах разработки есть люди, которые понимают ценность данных практик и готовы занимать проактивную позицию. Хуже, когда таких людей нет. И тут можно проводить различные митапы с разработчиками, небольшие хакатоны.
— Какие рекомендации можно дать при проектировании системы аутентификации и авторизации?
— Не создавайте собственные системы, а используйте проверенные отраслевые практики (OAuth 2.0, OIDC). Многофакторная аутентификация должна быть стандартом, и не стоит использовать только SMS, лучше переходить на Push. Также MFA может быть адаптивной и применяться только в рискованных операциях.
При управлении сессиями и токенами необходимо использовать краткосрочные JWT-токены с механизмом обновлений и должна быть обеспечена возможность централизованного отзыва сессий. Отдельное внимание стоит уделять процессу восстановления пароля.
При проектировании сервиса авторизации необходимо использовать централизованный подход с единой точкой принятия решений, то есть все запросы должны проходить через единый сервис (или библиотеку), где содержатся все правила авторизации. При этом рекомендуем использовать гибридный подход RBAC+ABAC. Важно помнить о том, чтобы не допускать наследования привилегий по умолчанию для новых сущностей и осуществлять проверку нарушений прав доступа в автоматическом режиме.
Вопросы задавал Усам Оздемиров
Реклама. ООО «УЦСБ», ИНН: 6672235068, Erid: 2VfnxwCqd8m
- Стоимость медиауслуг (открыть PDF) -
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных
