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