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

  • Статья

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ресурс Description
Управление политиками безопасности Содержит сведения о создании и реализации политики безопасности.
Рекомендации по политике безопасности Предоставляет ссылки на описание реализации политики безопасности.

См. также