Skip to content

Secure Product Design Cheat Sheet

Введение

Цель Secure Product Design — обеспечить, чтобы все продукты соответствовали или превышали требования безопасности, установленные организацией в рамках жизненного цикла разработки, а также гарантировать, что все решения по безопасности, принятые в отношении разрабатываемого продукта, являются осознанными и обеспечивают надлежащий уровень защиты.

Методология

В качестве базовой отправной точки следует установить безопасные настройки по умолчанию, минимизировать поверхность атаки и обеспечить безопасный переход в состояние отказа в соответствии с этими чётко определёнными и понятными умолчаниями.

Secure Product Design реализуется посредством двух процессов:

  1. Product Inception; и
  2. Product Design

Первый процесс происходит при зарождении продукта или при переосмыслении существующего. Второй является непрерывным, эволюционным и выполняется итеративно, непосредственно там, где пишется код.

Принципы безопасности

1. Принцип наименьших привилегий и разделения обязанностей

Наименьшие привилегии — это принцип безопасности, согласно которому пользователям следует предоставлять минимальный объём доступа, необходимый для выполнения их работы. Это означает, что пользователи должны иметь доступ только к тем ресурсам, которые им необходимы, и ни к чему сверх этого. Это помогает снизить риск несанкционированного доступа к конфиденциальным данным или системам, поскольку пользователи могут обращаться только к нужным им ресурсам. Наименьшие привилегии — важный принцип безопасности, которому следует придерживаться для обеспечения защиты данных и систем организации.

Разделение обязанностей — фундаментальный принцип внутреннего контроля в бизнесе и организациях. Это система сдержек и противовесов, гарантирующая, что ни один человек не имеет контроля над всеми аспектами транзакции. Это достигается путём назначения различных задач разным людям, чтобы никто не контролировал весь процесс целиком. Это снижает риск мошенничества и ошибок, а также гарантирует своевременное выполнение всех задач. Разделение обязанностей является важной частью системы внутреннего контроля любой организации и необходимо для поддержания целостности финансовой отчётности.

2. Принцип эшелонированной защиты (Defense-in-Depth)

Принцип эшелонированной защиты — это стратегия безопасности, предполагающая использование нескольких уровней средств контроля безопасности для защиты активов организации. Она основана на идее, что если один уровень защиты будет преодолён, остальные уровни по-прежнему смогут защитить актив. Уровни защиты могут включать физическую безопасность, сетевую безопасность, безопасность приложений и безопасность данных. Цель Defense-in-Depth — создать защищённую среду, устойчивую к атакам, способную быстро обнаруживать инциденты и реагировать на них. Применение нескольких уровней защиты позволяет организациям снизить вероятность успешной атаки и минимизировать ущерб от любой успешной атаки.

3. Принцип нулевого доверия (Zero Trust)

Zero Trust — это модель безопасности, которая предполагает, что все пользователи, устройства и сети являются ненадёжными и должны быть проверены перед предоставлением доступа. Она основана на идее, что организации не должны доверять ни одному пользователю, устройству или сети, даже если они находятся внутри корпоративной сети. Вместо этого все запросы на доступ должны быть аутентифицированы и авторизованы перед его предоставлением. Zero Trust также требует от организаций непрерывного мониторинга и аудита действий пользователей, чтобы гарантировать предоставление доступа только тем, кому он необходим. Эта модель призвана снизить риск утечки данных и других инцидентов безопасности, обеспечивая доступ к конфиденциальным данным только авторизованным пользователям.

4. Принцип открытой безопасности (Security-in-the-Open)

Security-in-the-Open — концепция, акцентирующая важность безопасности в разработке программного обеспечения с открытым исходным кодом. Она фокусируется на необходимости того, чтобы разработчики осознавали последствия своего кода для безопасности и принимали меры по его защите. Это включает использование методов безопасного программирования, тестирование на уязвимости и применение защищённых инструментов разработки. Security-in-the-Open также побуждает разработчиков сотрудничать с экспертами по безопасности для обеспечения надёжности своего кода.

Области применения безопасности

1. Контекст (Context)

Какое место занимает рассматриваемое приложение в экосистеме организации, какие подразделения используют его и с какой целью? Какие данные оно может содержать и каков в связи с этим профиль рисков?

Процессы, используемые для формирования контекста безопасности приложения, включают Threat Modeling — в результате которого в ходе Product Design на каждой итерации доставки продукта добавляются связанные с безопасностью пользовательские истории — а также проведение оценки воздействия на бизнес, результатом которой является установка корректных уровней Product Security Levels для конкретного продукта на этапе Product Inception.

Контекст имеет первостепенное значение, поскольку избыточная инженерия в плане безопасности может иметь даже более серьёзные последствия для затрат, чем избыточная инженерия в плане масштабируемости или производительности, однако и недостаточная инженерия может привести к катастрофическим последствиям.

2. Компоненты (Components)

Начиная от библиотек, используемых приложением (выбираемых на любом этапе Product Design), и заканчивая внешними сервисами, которые оно может использовать (изменение которых происходит в рамках Product Inception) — из чего состоит это приложение и как обеспечивается безопасность его частей? Для этого мы используем библиотеку безопасных шаблонов проектирования и готовых к использованию компонентов, определённых в документации Golden Path / Paved Road, и анализируем эти выборы через Threat Modeling.

Часть этого обзора компонентов должна также включать более коммерческие аспекты выбора правильных компонентов (лицензирование и поддержка), а также возможные ограничения на их использование.

3. Соединения (Connections)

Как вы взаимодействуете с этим приложением и как оно подключается к упомянутым компонентам и сервисам? Где хранятся данные и как к ним осуществляется доступ? Соединения также могут описывать намеренное отсутствие связей. Подумайте о разделении уровней, которое может потребоваться в зависимости от необходимых Product Security Levels, а также о возможном разделении данных или целых сред при необходимости для разных арендаторов (tenants).

Добавление (или удаление) соединений, вероятно, свидетельствует о том, что происходит Product Inception.

4. Код (Code)

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

Основные принципы безопасного программирования включают:

  1. Валидация входных данных: Проверяйте, что все входные данные корректны и соответствуют ожидаемому типу, формату и длине, прежде чем их обрабатывать. Это помогает предотвратить атаки типа SQL-инъекций и переполнения буфера.
  2. Обработка ошибок: Обрабатывайте ошибки и исключения безопасным образом — например, записывайте их в журнал безопасным способом и не раскрывайте конфиденциальную информацию злоумышленнику.
  3. Аутентификация и авторизация: Реализуйте надёжные механизмы аутентификации и авторизации, чтобы только авторизованные пользователи могли получить доступ к конфиденциальным данным и ресурсам.
  4. Криптография: Используйте криптографические функции и протоколы для защиты данных при передаче и хранении, например HTTPS и шифрование — ожидаемые уровни для данного Product Security Level можно найти в документации Golden Path / Paved Road.
  5. Наименьшие привилегии: Применяйте принцип наименьших привилегий при написании кода, чтобы коду и системе, в которой он выполняется, предоставлялись минимально необходимые права доступа для выполнения их функций.
  6. Безопасное управление памятью: Используйте высокоуровневые языки, рекомендованные в документации Golden Path / Paved Road, или правильно управляйте памятью для предотвращения уязвимостей, связанных с памятью, таких как переполнение буфера и use-after-free.
  7. Избегание жёстко закодированных секретов: Жёстко закодированных секретов, таких как пароли и ключи шифрования, следует избегать в коде — их необходимо хранить в защищённом хранилище.
  8. Тестирование безопасности: Тестируйте программное обеспечение на наличие уязвимостей безопасности в процессе разработки и непосредственно перед развёртыванием.
  9. Аудит и проверка кода: Регулярно проводите аудит и проверку кода на наличие уязвимостей безопасности — например, с помощью автоматизированных инструментов или привлечения сторонних проверяющих.
  10. Актуальность: Поддерживайте код в актуальном состоянии, следуя последним рекомендациям по безопасности и исправлениям уязвимостей, чтобы программное обеспечение было максимально защищённым.

Убедитесь, что вы интегрируете проверки правдоподобности на каждом уровне вашего приложения (например, от frontend до backend), и напишите модульные и интеграционные тесты для подтверждения того, что все угрозы, обнаруженные в ходе Threat Modeling, были снижены до уровня риска, приемлемого для организации. Используйте это для составления use-cases и abuse-cases для каждого уровня вашего приложения.

5. Конфигурация (Configuration)

Создание безопасного приложения может быть легко сведено на нет, если оно не настроено должным образом. Как минимум следует обеспечить следующее:

  1. С учётом принципа наименьших привилегий: Ограничьте доступ и разрешения компонентов системы и пользователей до минимума, необходимого для выполнения их задач.
  2. Помня о Defense-in-Depth: Реализуйте несколько уровней средств контроля безопасности для защиты от широкого спектра угроз.
  3. Обеспечение безопасности по умолчанию (Secure by Default): Настраивайте системы и программное обеспечение так, чтобы они были безопасны по умолчанию, с минимально необходимой ручной настройкой или конфигурацией.
  4. Защита данных: Защищайте конфиденциальные данные, такие как персональная информация и финансовые данные, шифруя их при передаче и хранении. Защита этих данных также означает обеспечение их корректного резервного копирования и правильной настройки хранения данных в соответствии с требуемым Product Security Level.
  5. Планируйте безопасный переход в состояние отказа (Fail Securely): Проектируйте системы таким образом, чтобы они переходили в защищённое состояние при сбое, а не раскрывали уязвимости при неисправности.
  6. Всегда используйте защищённые коммуникации (Secure Communications): Используйте защищённые протоколы связи, такие как HTTPS, для защиты от перехвата и подделки данных.
  7. Выполняйте регулярные обновления — или используйте maintained images: Поддержание программного обеспечения, образов docker и базовых операционных систем в актуальном состоянии с учётом последних патчей безопасности является неотъемлемой частью поддержания защищённой системы.
  8. Имейте отработанный план реагирования на инциденты безопасности: Наличие плана реагирования на инцидент безопасности необходимо для минимизации ущерба от любой успешной атаки и является важнейшей частью модели поддержки продукта (Product Support Model).

Подробности о том, как именно обеспечить безопасную конфигурацию, можно найти в Infrastructure as Code Security Cheat Sheet