Поделиться через

Общие сведения о безопасности

Защита приложения — это текущий процесс. Никогда не будет точки, когда разработчик может гарантировать, что приложение безопасно от всех атак, потому что невозможно предсказать, какие типы будущих атак будут вызывать новые технологии. И наоборот, просто потому, что никто еще не обнаружил (или опубликовал) недостатки безопасности в системе не означает, что ни один из них не существует или может существовать. Необходимо планировать безопасность на этапе проектирования проекта, а также планировать, как безопасность будет поддерживаться в течение всего времени существования приложения.

Проектирование для обеспечения безопасности

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

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

Моделирование угроз

Невозможно защитить систему от атак, если вы не понимаете все потенциальные атаки, которым она подвергается. Процесс оценки угроз безопасности, называемых моделированием угроз, необходим для определения вероятности и последствий нарушений безопасности в приложении ADO.NET.

Моделирование угроз состоит из трех высокоуровневых шагов: понимание представления злоумышленника, характеризующее безопасность системы и определение угроз.

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

Дополнительные сведения см. в следующих ресурсах:

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

Принцип наименьшей привилегии

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

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

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

Дополнительные сведения о защите приложений см. в следующих ресурсах:

Ресурс Описание
Защита приложений Содержит ссылки на общие разделы безопасности. Также содержит ссылки на разделы по защите распределенных приложений, веб-приложений, мобильных приложений и классических приложений.

Управление доступом для кода (CAS)

Безопасность доступа к коду (CAS) — это механизм, который помогает ограничить доступ к защищенным ресурсам и операциям. В .NET Framework CAS выполняет следующие функции:

  • Определяет разрешения и наборы разрешений, представляющие право доступа к различным системным ресурсам.

  • Позволяет администраторам настраивать политику безопасности путем связывания наборов разрешений с группами кода (группы кода).

  • Позволяет коду запрашивать необходимые разрешения для выполнения, а также разрешения, которые будут полезны для использования, и указывает, какие разрешения не должны иметь код.

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

  • Позволяет коду требовать, чтобы его вызывающие имели определенные разрешения.

  • Позволяет коду требовать, чтобы вызывающие его абоненты имели цифровую подпись, что позволяет вызывать защищенный код только вызывающим абонентам из определенной организации или сайта.

  • Применяет ограничения кода во время выполнения, сравнивая предоставленные разрешения каждого вызывающего объекта в стеке вызовов с разрешениями, которые должны иметь вызывающие.

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

Дополнительные сведения см. в следующих ресурсах:

Ресурс Описание
Безопасность доступа к коду и ADO.NET Описывает взаимодействие между безопасностью доступа к коду, безопасностью на основе ролей и частично доверенными средами с точки зрения приложения ADO.NET.
Безопасность доступа к исходному коду Содержит ссылки на дополнительные разделы, описывающие CAS в .NET Framework.

Безопасность базы данных

Принцип наименьшей привилегии также применяется к источнику данных. Ниже приведены общие рекомендации по обеспечению безопасности базы данных:

  • Создайте учетные записи с наименьшими возможными привилегиями.

  • Не предоставляйте пользователям доступ к административным учетным записям только для обеспечения функционирования кода.

  • Не возвращайте сообщения об ошибках на стороне сервера клиентским приложениям.

  • Проверьте все входные данные как на клиенте, так и на сервере.

  • Используйте параметризованные команды и избегайте динамических инструкций SQL.

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

Дополнительные сведения см. в следующих ресурсах:

Ресурс Описание
Безопасность SQL Server Общие сведения о безопасности SQL Server с сценариями приложений, которые предоставляют рекомендации по созданию безопасных ADO.NET приложений, предназначенных для SQL Server.
Рекомендации по стратегиям доступа к данным Предоставляет рекомендации по доступу к данным и выполнению операций с базой данных.

Политика безопасности и администрирование

Неправильное администрирование политики безопасности доступа к коду (CAS) может привести к недостаткам безопасности. После развертывания приложения следует использовать методы мониторинга безопасности и оценивать риски по мере появления новых угроз.

Дополнительные сведения см. в следующих ресурсах:

Ресурс Описание
Управление политикой безопасности Содержит сведения о создании и администрировании политики безопасности.
Рекомендации по политике безопасности Содержит ссылки, описывающие администрирование политики безопасности.

См. также

  • Last updated on