Глава 3

Безопасность при проектировании ПО

В предыдущей главе мы говорили о требованиях безопасности. Они являются обязательным условием при создании любого продукта, а наличие требований по обеспечению безопасности с самого начала разработки – первый шаг к высокому качеству конечного продукта. В этой главе мы обсудим следующий этап жизненного цикла разработки системы – проектирование (рис. 3.1).

Рис. 3.1. Жизненный цикл разработки системы

При проектировании архитекторы программного обеспечения должны думать не только о бизнес-требованиях (о чем попросил заказчик) и функциональных требованиях (пользовательских требованиях, разработке, планировании работы, системных требованиях), но также о нефункциональных требованиях, которые часто рассматриваются как нечто само собой разумеющееся: удобстве использования, качестве, а также главной теме данной книги – безопасности.

Безопасность через проектирование (англ. Secure by design) в программной инженерии означает, что безопасность программного обеспечения реализуется с самого начала его проектирования. При таком подходе вредоносные действия, направленные против приложения, воспринимаются как нечто само собой разумеющееся и внимание уделяется минимизации воздействия обнаруженных уязвимостей безопасности или недопустимого пользовательского ввода.

Википедия

Проектирование программного обеспечения можно трактовать по-разному, поэтому дадим свое определение данному понятию.

Проектирование программного обеспечения – это планирование разработки ПО, способов его соединения или работы с необходимыми компонентами. Оно может представлять собой документ очень высокого уровня, показывающий, как все части приложения работают вместе: например, этот пользовательский интерфейс подключается к этой базе данных и вызывает этот API.

Проектные документы могут быть чрезвычайно формальными и содержать много подробностей, вплоть до того, какие классы будут определены и как, а могут просто состоять из нескольких рисунков и диаграмм потоков данных. Цель проектного документа – донести до команды, как ей нужно разрабатывать приложение.

Достаточность средств защиты следует обсудить со службой безопасности, однако перед этим проектный документ необходимо согласовать с командой разработчиков.

Ошибка проектирования и дефект безопасности

Ошибкой проектирования называется ошибка в конструкции приложения, позволяющая пользователю выполнять действия, на которые у него нет разрешения (то есть вредоносные или повреждающие приложение действия). Это ошибка, проблема проектирования. Использование концепции проектирования безопасного ПО, требования безопасности к проектам и моделирование угроз позволяют избежать или минимизировать возможности возникновения ошибок проектирования.

Дефект безопасности – это проблема реализации, проблема в коде, позволяющая пользователю использовать приложение вредоносным или иным некорректным способом. Для защиты от дефектов безопасности проводятся анализ кода, тестирование безопасности (многих типов, на разных этапах проекта), обучение написанию безопасного кода, а также применяются концепции и рекомендации по безопасному кодированию. На рис. 3.2 видно, на каких этапах жизненного цикла разработки системы появляются ошибки проектирования и дефекты безопасности.

Рис. 3.2. Ошибки проектирования и дефекты безопасности

Позднее обнаружение ошибки проектирования

Чем позже в жизненном цикле разработки системы будет устранена ошибка, тем дороже она обойдется. В одной статье онлайн-журнала Slashdot говорится, что ошибка, обнаруженная на этапе требований, может стоить $1, на этапе проектирования – $10, на этапе кодирования – $100, на этапе тестирования – $1000, а после релиза – еще больше. В интернете можно найти множество различных оценок стоимости, но, вместо того чтобы использовать приблизительные числа в попытке объяснить данную идею, проконсультируемся с Бобом. На рис. 3.3 изображена растущая стоимость устранения проблем безопасности на каждом из этапов жизненного цикла разработки системы.

Рис. 3.3. Примерная стоимость исправления ошибок и дефектов безопасности в жизненном цикле разработки системы

Давным-давно Боб и его супруга построили дом своей мечты, на который они копили много лет. Строительство находилось на конечном этапе: уже устанавливались ручки на шкафы и раскатывались ковры, – когда Боб понял, что они совершили ошибку. Почему-то на протяжении всего планирования молодой семье не приходило в голову добавить вторую ванную комнату. Когда Боб и его жена начинали копить и планировать дом, у них был один ребенок, но к моменту окончания стройки детей стало уже двое и рассматривалась возможность рождения третьего – им определенно нужна была еще одна ванная комната.

Боб знал, что добавление ванной комнаты на таком позднем этапе будет довольно дорогим изменением и отодвинет срок завершения строительства, но он также понимал, что одной ванной комнаты будет определенно недостаточно. Строительная компания ему объяснила, что придется уменьшить жилую площадь в два раза, а переезд задержится на целый месяц. К тому же на 10 % увеличится стоимость проекта. Семья неохотно согласилась с этими условиями, но Боб усвоил очень ценный урок: гораздо дешевле, проще и быстрее изменить проект на его ранних этапах.

Такая же ситуация и с программным обеспечением. Изменения, внесенные в конструкцию приложения в последнюю минуту, не всегда красивы, зачастую приводят к срыву сроков и повышают общую стоимость. К сожалению, из-за них также могут возникнуть новые уязвимости в конечном продукте.