«Снизу вверх» или эвристический подход к проектированию конструктивно безопасных систем

Плюсы, минусы и нюансы имплементации различных подходов Secure by Design в статье Сергея Талантова — архитектора и Security Champion’а в команде KasperskyOS

Существует несколько подходов к проектированию систем с конструктивной безопасностью (Secure by Design). Один из самых известных — это SDL (Security Development Lifecycle), разработанный в Microsoft. Он охватывает все уровни разработки — от архитектурного до уровня реализации. Это довольно трудоемкий и тяжеловесный методический подход, применимый для больших проектов и крупных компаний. Архитектура с его применением проектируется сверху вниз — выбираем модели и шаблоны и спускаемся вниз по реализации.

Есть более простой подход к проектированию систем с Secure by Design — эвристический, с использованием принципов безопасности. Основные принципы были сформулированы Джеромом Зальцером и Майклом Шредером еще в 1974 году в работе «Защита информации в компьютерных системах» (The Protection of Information in Computer System).

  1. Принцип простоты (Economy of mechanism). Чем проще, тем безопаснее.
  2. Принцип безопасных умолчаний (Fail-safe defaults). По умолчанию наша система должна быть безопасной. Все разрешения должны быть явные. Одним из вариантов этого принципа является default deny, когда мы по умолчанию запрещаем все взаимодействия, разрешая что-то только явно.
  3. Принцип полноты перекрытия (complete mediation). Мы должны контролировать все взаимодействия в системе. Не должно быть темных углов, бэкдоров и так далее.
  4. Принцип открытого дизайна (open design). Архитектура не должна быть секретной. Вариация этого принципа в криптографии — алгоритм шифрования не должен быть секретным.
  5. Разделение привилегий (Separation of privilege). При возможности должен быть многофакторный контроль доступа.
  6. Минимизация привилегий (Least privilege). Каждая программа и каждый пользователь системы должны работать с наименьшим набором привилегий, необходимых для выполнения работы.
  7. Минимизация общих механизмов (Least common mechanism). Количество общих для более чем одного пользователя ресурсов должно быть минимизировано и их разделение должно быть прозрачным.
  8. Психологическая приемлемость (Psychological acceptability). Система должна быть понятна пользователю.

В чистом виде (в формате методологии) эти принципы не формализованы и применяются редко. Чаще их используют просто в виде правил. Определенную степень формализации обеспечивает подход под названием паттерны безопасности. Этот подход довольно удобен для применения. С его помощью система проектируется «снизу вверх» с использованием лучших практик, рекомендаций и эвристик.

О конкретных примерах паттернов безопасности, применяемых как на уровне микродизайна, так и на уровне архитектуры читайте в статье «Меньше багов богу разработки: плюсы, минусы и нюансы имплементации подхода Secure by design». Сергей Талантов, архитектор и Security Champion в команде KasperskyOS, рассматривает в материале часто возникающие реальные проблемы, наподобие хранения в памяти чувствительных данных (паролей, ключей, и т.п.) и дает примеры их решения с помощью таких паттернов, как read-once object, value object, а также паттерна входной валидации.

Существует несколько подходов к проектированию систем с конструктивной безопасностью (Secure by Design). Один из самых известных — это SDL (Security Development Lifecycle), разработанный в Microsoft. Он охватывает все уровни разработки — от архитектурного до уровня реализации. Это довольно трудоемкий и тяжеловесный методический подход, применимый для больших проектов и крупных компаний. Архитектура с его применением проектируется сверху вниз — выбираем модели и шаблоны и спускаемся вниз по реализации.

Есть более простой подход к проектированию систем с Secure by Design — эвристический, с использованием принципов безопасности. Основные принципы были сформулированы Джеромом Зальцером и Майклом Шредером еще в 1974 году в работе «Защита информации в компьютерных системах» (The Protection of Information in Computer System).

  1. Принцип простоты (Economy of mechanism). Чем проще, тем безопаснее.
  2. Принцип безопасных умолчаний (Fail-safe defaults). По умолчанию наша система должна быть безопасной. Все разрешения должны быть явные. Одним из вариантов этого принципа является default deny, когда мы по умолчанию запрещаем все взаимодействия, разрешая что-то только явно.
  3. Принцип полноты перекрытия (complete mediation). Мы должны контролировать все взаимодействия в системе. Не должно быть темных углов, бэкдоров и так далее.
  4. Принцип открытого дизайна (open design). Архитектура не должна быть секретной. Вариация этого принципа в криптографии — алгоритм шифрования не должен быть секретным.
  5. Разделение привилегий (Separation of privilege). При возможности должен быть многофакторный контроль доступа.
  6. Минимизация привилегий (Least privilege). Каждая программа и каждый пользователь системы должны работать с наименьшим набором привилегий, необходимых для выполнения работы.
  7. Минимизация общих механизмов (Least common mechanism). Количество общих для более чем одного пользователя ресурсов должно быть минимизировано и их разделение должно быть прозрачным.
  8. Психологическая приемлемость (Psychological acceptability). Система должна быть понятна пользователю.

В чистом виде (в формате методологии) эти принципы не формализованы и применяются редко. Чаще их используют просто в виде правил. Определенную степень формализации обеспечивает подход под названием паттерны безопасности. Этот подход довольно удобен для применения. С его помощью система проектируется «снизу вверх» с использованием лучших практик, рекомендаций и эвристик.

О конкретных примерах паттернов безопасности, применяемых как на уровне микродизайна, так и на уровне архитектуры читайте в статье «Меньше багов богу разработки: плюсы, минусы и нюансы имплементации подхода Secure by design». Сергей Талантов, архитектор и Security Champion в команде KasperskyOS, рассматривает в материале часто возникающие реальные проблемы, наподобие хранения в памяти чувствительных данных (паролей, ключей, и т.п.) и дает примеры их решения с помощью таких паттернов, как read-once object, value object, а также паттерна входной валидации.

Консультация по решению

Остались вопросы или требуется дополнительная информация по решению? Оставьте заявку на консультацию, и мы с вами свяжемся!

Задать вопрос

Отвечаем на самые популярные вопросы о KasperskyOS и решениях на ее основе

Перейти в FAQ