Разработчик: Процесс разработки можно сравнить со строительством дома. Сначала у тебя появляется идея построить красивый загородный дом, в котором будут жить такие-то люди. Ты начинаешь придумывать сценарии использования этого дома. Дальше проектируешь примерный план здания, придумываешь дизайн. Потом ты нанимаешь команду строителей. И вот в какой-то момент твой дом уже построен, но жить в нём ещё некомфортно — нужно заниматься отделкой, ставить мебель.
Разработка очень похожа на то, что я сейчас описал.
Сначала ты тестируешь какие-то гипотезы, предлагаешь идеи. Для этого нужны продакт-оунеры, продакт-менеджеры. Дальше нужно будет проиллюстрировать твою идею, чтобы разработчики понимали, что и как запрограммировать. Соответственно, подключаем дизайнеров и UX-исследователей, которые подскажут, какие должны быть формы для разных категорий пользователей.
Затем подключаем разработчиков, которые будут проектировать систему и базы данных, подумают о том, где в IT-инфраструктуре все будет работать. Потом они начнут разработку, декомпозируют фичи на конкретные задачи и распределят их между собой, будут тестировать по мере появления.
На выходе получится первая минимально жизнеспособная версия продукта — MVP.
Безопасник: В твоем примере нет ни слова про безопасность. Ну хорошо, построили мы этот дом, вроде бы все идет по плану. И тут неожиданно злоумышленники разбивают окно и обворовывают дом.
Что делать в этой ситуации с точки зрения разработки, когда система уже в проде, а про безопасность никто не подумал? Допустим, из MVP утекает база данных всех заказчиков. Как на это отреагирует разработчик?
Разработчик: Если данные потеряны — это уже катастрофа. Разработчики в шоке хватаются за голову, руководитель оценивает ущерб: какие у нас репутационные и финансовые потери, что напишут в СМИ, оштрафуют ли регуляторы, какие будут последствия для наших пользователей. Ну и главное, не всегда сразу понятно, что вообще утекло. Тут надо отматывать назад и думать, что нужно было сделать, чтобы данные не пропали.
По хорошему думать про безопасность базы с персональными данными нужно еще до того, как мы ее отправим систему в прод. Нужно проконсультироваться с ИБ о том, как защитить базу, где лучше хранить персональные данные и так далее.
Часто разработчики вообще не понимают, что относится к персональным данным, а что нет. Для таких кейсов в больших компаниях обычно есть целые отделы, которые консультируют разработку по вопросам безопасности данных. Но если в штате таких специалистов нет, стоит поскорее заказать внешнюю экспертизу.
В общем, продумывать архитектуру информационной безопасности нужно еще до того, как мы приступим к разработке.
Безопасник: Хорошо, регуляторку мы проверили, сделали архитектуру, поставили базу данных. И вдруг база данных у нас с критической уязвимостью. Что тогда?
Разработчик: Так происходит, потому что во время разработки мы пользуемся внешними компонентами, которые не разрабатываем самостоятельно — например, сторонними БД или внешними библиотеками. Сейчас так происходит любая разработка — невозможно вести ее только на собственном коде.
Когда мы пользуемся внешними компонентами, мы подвергаемся риску информационной безопасности, потому что там могут быть уязвимости, баги, бэкдоры. И ни один разработчик не контролирует это в полной мере. Да, мы пользуемся внешними зависимостями, мы их не контролируем, и там могут находиться уязвимости.
Здесь нужна помощь отдельных служб. Это может быть как внутренняя экспертиза, так и внешний аудит.
Безопасник: Окей. Допустим, мы определили компонент, который будет использоваться, и привлекли внешнего безопасника. Он сказал, что вот эту базу конкретной версии использовать нельзя. Или, например, говорит, что нужно использовать другую базу данных, которая не укладывается в вашу архитектуру с точки зрения логики взаимодействия. Что тогда будете делать? Как часто у вас вообще так бывает?
Разработчик: Скорее не бывает. Вопрос выбора базы данных лежит больше в поле архитектуры приложения: какие данные там хранятся, какого объема, какой будет применен механизм их использования, как мы будем кэшировать данные? Там много вопросов, среди которых безопасность — не первая по счету, потому что сначала нужно решить вопросы производительности.
Безопасник: Получается, мы опять упираемся в конфликт: вопрос информационной безопасности уступает место производительности, но при этом ее надо учитывать на ранней стадии разработки. А что делать, если компонент (пусть даже не БД), который используется в микросервисной архитектуре, категорически не подходит для текущей архитектуры, а дедлайн у нас завтра?
Разработчик:
Чем закончился разговор разработчика и безопасника? Дошло ли дело до поножовщины? Что делать, если я действительно хотел построить дом? Где покупать стройматериалы?
Узнать ответы на эти вопросы (кроме стройматериалов) можно в нашем новом подкасте «Все по ИБ». Только что вы прочитали небольшой отрывок из пилотного выпуска, в котором Сергей Зайцев и Владимир Ченцов обсудили безопасную разработку.
Забегая вперед, скажем, что «дом» все же удалось построить без особых конфликтов. Слушайте выпуск целиком, чтобы выяснить, как мы этого добились!
Слушать на стриминговых платформах
Слушать в Telegram
Источник новости: habr.com
