Опытный разработчик не так давно зашёл в .Net и поставил цель получить сертификат Microsoft. Свой ежедневный прогресс он описывает на канале .Net Разработчик. Заметки об изученном материале, советы по повышению производительности и поддержке мотивации, ин
День 1480. #ProjectManagement
Организация Разработки Безопасного ПО. Окончание
Начало
Нулевое доверие
Часто при разработке систем мы создаём «подразумеваемое доверие» - одна или несколько частей системы не проверяют то, что должны или могли бы проверять. Когда кто-то входит в систему, элемент управления безопасностью проверяет личность пользователя (через комбинацию имени и пароля), а затем предоставляет ему доступ к частям, к которым ему разрешён доступ. Если мы пропустим этот шаг, мы создадим подразумеваемое доверие.
Нулевое доверие означает отсутствие подразумеваемого доверия. Каждая часть системы заблокирована и открывается только в случае необходимости. Это означает закрытие всех портов, кроме тех, которые нужны, блокировку всех подключений, кроме нужных, постоянную проверку разрешений перед использованием. Не доверяйте ничему, даже другим системам, которые у вас есть как зависимости.
Примеры нулевого доверия:
- Проверка, очистка и экранирование всех входных данных (в указанном порядке)
- Каждый API, бессерверное приложение, контейнер или сервис рассматривается как отдельный остров. Они не должны доверять друг другу!
- Аутентификация и авторизация для всех! Каждая интеграция, даже с системами, созданными и поддерживаемыми вашей командой, требует аутентификации и авторизации для каждого подключения.
- Кодировка вывода. Не доверяйте вводу пользователя или вводу, который мог быть подделан!
Все возможные варианты нулевого доверия никогда не реализовываются, это нормально. Достаточно применить принципы нулевого доверия к как можно большему количеству систем.
Покупайте, заимствуйте, затем создавайте
Создать систему безопасности сложно. Они сложны по своей природе, тестируются чаще и более агрессивно, чем любая другая функция. Создание собственной системы безопасности дорогостояще, трудоёмко и потенциально опасно. Поэтому рекомендуется следующий порядок.
1. Купить
Т.к. ПО доступно немедленно, его не нужно создавать и поддерживать самостоятельно, и, скорее всего, оно было тщательнее протестировано. Хотя цена может показаться высокой, если подсчитать риск, время ожидания и долгосрочную стоимость обслуживания, почти всегда дешевле купить, чем создавать.
2. Заимствовать
Под заимствованием понимается использование открытого кода или другого кода, который вы можете использовать бесплатно, но который писали не вы. Это ПО с открытым кодом, онлайн-примеры, код от других команд, функции фреймворка и т.п. Преимущества аналогичны покупке: код доступен сразу, он бесплатный, не нужно его поддерживать самостоятельно. Однако такой код, возможно, не тестировался на безопасность, т.е. вы должны убедиться, что он безопасен, прежде чем использовать его, если это вообще возможно.
3. Создать
Если ни один из вариантов не подходит, создаём.
Это экономит деньги и время компании и снижает риски, несмотря на то что создание ПО с нуля обычно намного веселее. По возможности используйте функции безопасности, имеющиеся в вашей среде, такие как шифрование, аутентификацию и управление сеансами. Они испытаны, проверены и работают правильно! Используйте сторонние компоненты (библиотеки, пакеты и т.д.), так как они (обычно) достаточно тщательно протестированы. Проверяйте сторонний код и компоненты с помощью инструментов анализа ПО. Не пишите собственные функции безопасности, если в этом нет крайней необходимости.
Создавая безопасный жизненный цикл разработки системы, избегая подразумеваемого доверия внутри систем, которые мы создаём, и создавая собственные средства безопасности только тогда, когда это абсолютно необходимо, мы последовательно снижаем риски для компании.
Источник: https://stackoverflow.blog/2023/02/09/three-layers-to-secure-a-software-development-organization