Требования безопасности
В этой статье разберем, какие требования к безопасности предъявляются к программному обеспечению и какую роль они играют при проектировании.
Базовые требования
При разработке ПО необходимо знать, что оно должно делать и какими характеристиками обладать. При этом учитываются потребности и ожидания его пользователей, а также требования законодательства и отдельных нормативных документов. Это особенно актуально для ПО и основанных на нем систем, которые используются там, где нарушение безопасности может привести к значительному ущербу — например, в сфере медицины или финансов.
Для фиксации требований к ПО обычно используются специальные документы, в которых подробно описываются все необходимые функции и характеристики. В некоторых случаях они не фиксируются в официальном документе, а каждое новое требование просто добавляется в систему управления задачами.
К разным системам предъявляются разные специфические требования. Чтобы определить требования в части информационной безопасности для конкретного ПО, можно начать с рассмотрения основных свойств безопасности:
- конфиденциальность — пользователи могут получить доступ только к той информации, которую они имеют право использовать;
- целостность — пользователи могут добавлять или удалять только те данные, которые они имеют право использовать;
- доступность — пользователи могут использовать ПО и информацию даже при аварии или атаке.
Перечисленные свойства безопасности информации иногда называют триадой CIA (CIA – Confidentiality, Integrity, and Availability).
Многие специалисты выделяют еще одно свойство безопасности — неотказуемость, или подотчетность. Система должна доказать, что пользователь совершил определенные действия, даже если сам человек это отрицает. Примерами таких операций могут быть перевод крупной суммы, удаление чего-то важного, отправка или получение сообщения.
Для обеспечения указанных свойств безопасности применяются специальные механизмы безопасности.
- Идентификация и аутентификация — это последовательные этапы проверки, которые однозначно определяют пользователя на основе предъявленного им идентификатора (имени пользователя, адреса электронной почты, номера аккаунта), а затем подтверждают, что пользователь является тем, за кого себя выдает.
Для такого подтверждения используют что-то, что известно только этому пользователю: пароль, токен, секретный ключ, или то, чем пользователь владеет: устройство, номер телефона и т.д. Для аутентификации могут использоваться уникальные индивидуальные характеристики пользователя — отпечатки пальцев, голос и др. Настоятельно рекомендую поддерживать многофакторную аутентификацию, которая объединяет несколько методов: например, пароль + одноразовый код в приложении-аутентификаторе. - Авторизация — определение того, какие именно операции разрешено выполнять конкретному пользователю после успешной аутентификации в соответствии с его ролью или уровнем доступа.
- Аудит (логирование) — процесс записи важных событий в системе для последующего анализа и обнаружения возможных нарушений безопасности. К таким событиям относятся: вход в систему и выход из нее, изменение важной информации, конфигурации системы и другие значимые действия пользователей. Аудит имеет решающее значение для обеспечения неотказуемости (подотчетности).
Фактические требования к тому, как должны быть реализованы механизмы безопасности, зависят от задач, которые решает разрабатываемое вами ПО. Если вы разрабатываете низкоуровневую библиотеку, то можете не поддерживать напрямую ни один из этих механизмов безопасности. Но вы все равно должны быть уверены, что то, что вы делаете, впишется в разрабатываемую систему и будет соответствовать установленным к ней требованиям.
Для формирования базовых требований безопасности к ПО стоит определить, как минимум, следующие аспекты.
- Объекты защиты. Какие данные нуждаются в защите и можно ли вообще обойтись без них, а также какие компоненты ПО непосредственно будут взаимодействовать с такими данными.
- Роли и права пользователей. Кому разрешено получать доступ к конкретным категориям данных и какие операции с этими данными допустимы.
- Методы идентификации и аутентификации. Какие данные о пользователе нужны для взаимодействия с ним и как он может подтвердить свою личность.
- Уровень доступности. Допустимы ли простои в работе, в течение которых пользователи не имеют доступа к данным или к функциям сервиса, и какие из них наиболее критичны с точки зрения бизнеса.
Если существует ПО, решающее схожие с вашими задачи, изучите реализованные в нем механизмы безопасности. Разработчики не случайно внедрили их, и в вашем ПО также может потребоваться реализация некоторых из них.
Уточнение требований
Уточняйте базовые требования безопасности к ПО с учетом особенностей работы этого ПО и условий, в которых оно будет работать. Проведите моделирование угроз безопасности, чтобы описать риски в терминах вероятности и уровня воздействия, и понять, как они связаны с вашим ПО.
Взгляните на ваше ПО с точки зрения потенциального злоумышленника. Это необходимо, когда вы разрабатываете или изменяете достаточно сложную систему, в особенности ту, с которой будут взаимодействовать внешние пользователи.
Существует множество подходов к моделированию угроз. Они могут исходить из:
- объектов защиты (что нужно защитить);
- атакующего (каковы его цели, возможности, типичные методы);
- архитектуры системы (как взаимодействуют компоненты, где проходят границы доверия).
Наиболее простой и ориентированный на архитектуру подход к моделированию угроз был разработан Microsoft и называется STRIDE. О нем подробно рассказано в статье Роберта Райхеля «How We Threat Model» (2020).
При применении STRIDE необходимо создать упрощенное представление вашей архитектуры. Обычно для этого используется простая диаграмма потоков данных (Data Flow Diagram, DFD):
- процессы обработки данных обозначаются кругами;
- хранилища данных обозначаются линиями над и под названием (иногда изображаются цилиндрами);
- потоки данных, включая передачу данных по сети, обозначаются направленными стрелками;
- внешние сущности (объекты вне системы, взаимодействующие с ней) обычно имеют простые значки, например, стилизованная фигура человека;
- границы доверия обозначаются пунктирной линией и разделяют доверенные и недоверенные части системы;
Все, кроме границ доверия, процессов, хранилищ данных, потоков данных и внешних сущностей, считается элементами.
Цель — создать простую модель архитектуры ПО, отражающую его ключевые особенности. Вот несколько практических правил для создания хорошего представления:
Правило 1. У каждого хранилища данных должен быть хотя бы один вход и хотя бы один выход («данные не берутся из ниоткуда»).
Правило 2. Только процессы могут читать или записывать данные в хранилища («никакого телекинеза»).
Правило 3. Однотипные элементы внутри одной границы доверия можно объединить («делайте модель проще»).
При применении STRIDE анализируйте каждый из элементов, чтобы определить угрозы, к которым он уязвим. Для каждого элемента ищите угрозы, представленные в таблице ниже:
| Угроза | Определение |
|---|---|
| Подмена (Spoofing) | Выдача себя за другого пользователя или компонент системы |
| Фальсификация (Tampering) | Изменение данных |
| Отказ (Repudiation) | Попытка пользователя отрицать выполнение действия или свою ответственность за него |
| Раскрытие информации (Information Disclosure) | Предоставление информации лицам, не имеющим на это прав |
| Отказ в обслуживании (Denial of Service) | Исчерпание ресурсов, необходимых для предоставления сервиса |
| Повышение привилегий (Elevation of Privilege) | Получение возможности выполнять действия, на которые нет разрешения |
Обратите внимание, что STRIDE — это просто акроним рассматриваемых угроз: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. Это один из самых ранних, известных и простых методов моделирования угроз («Threat Modeling: Uncover Security Design Flaws Using The STRIDE Approach», 2006). Для работы с ним есть специализированные инструменты, но можно обойтись и простыми средствами: редактором диаграмм, текстовым редактором или таблицами.
Если в результате моделирования угроз вы понимаете, что есть шансы, что безопасность сервиса и его данных нарушится, сформулируйте риски и выберите один из вариантов их обработки: принятие, избегание, передача и контроль. Об этом мы рассказали в предыдущей статье курса.
