Требования безопасности
Обновлен: Ноябрь 2007
Для обеспечения вызова кода только вызывающими объектами, получившими определенное разрешение, можно декларативным или принудительным путем потребовать от вызывающих объектов кода наличия определенного разрешения или группы разрешений. Требование заставляет среду выполнения производить проверку безопасности для обеспечения выполнения ограничений, наложенных на вызывающий код. В ходе проверки безопасности среда выполнения просматривает стек вызовов, проверяя разрешения каждого вызывающего объекта в стеке и определяя, присутствует ли у каждого из вызывающих объектов затребованное разрешение. Если обнаруживается вызывающий объект, не имеющий требуемого разрешения, проверка безопасности завершается неудачей и создается исключение SecurityException. Единственные требования, не приводящие к проверке стека, — требования связывания, проверяющие только непосредственно вызывающий объект.
Можно заставить проверку безопасности выполняться каждый раз, когда вызывается определенный метод, или перед выполнением определенного блока кода. Если необходимо, чтобы проверка безопасности происходила при вызове любого члена заданного класса, можно поместить требование перед классом, чтобы оно применялось к каждому его члену. Далее в этом разделе поясняется, как реализовать требования безопасности, когда следует это делать и на основании чего следует делать выбор между типами требований безопасности.
Если при разработке библиотеки, которая напрямую обращается к защищенному ресурсу, этот доступ известен вызывающему объекту, нужно произвести требование безопасности в библиотеке, чтобы обеспечить наличие у всех вызывающих объектов в стеке вызовов разрешения на доступ к этому ресурсу. Требования могут быть декларативными или принудительными. Обратите внимание, что требования никогда не должны реализовываться в конструкторе класса, потому что код конструктора не обязательно будет выполняться в какой-либо определенный момент или в определенном контексте. Так как состояние стека вызовов в конструкторе класса определено нечетко, требования, налагаемые на конструкторы класса, могут приводить к неожиданным и нежелательным результатам.
Следует придерживаться следующих рекомендаций, вне зависимости от типа запрашиваемого требования.
Убедитесь, что источником вызывающего объекта является определенный веб-узел или зона, либо он подписан определенным издателем, путем затребования у вызывающего объекта определенного разрешения удостоверения. Однако этим следует пользоваться только в случаях, когда на основании совпадения удостоверения дополнительные права доступа только предоставляются, но не отвергаются. Так как скрыть или модифицировать удостоверение кода относительно несложно, отказ в доступе на основании одного только удостоверения не является надежным способом защиты кода и используемых им ресурсов от несанкционированного доступа.
Удостоверьтесь, что объект может быть создан только вызывающими объектами, имеющими определенное разрешение, налагая требование на уровне класса этого объекта. Предположим, что имеется класс с именем myFileStream, унаследованный от класса FileStream и требуется обеспечить возможность создания экземпляров класса myFileStream только авторизованными вызывающими объектами. Следует применить декларативное требование объекта FileIOPermission, предоставляющего право доступа к потоку, создаваемому классом myFileStream, на уровне класса myFileStream.
Можно также применить требование внутри кода, получающего или устанавливающего значение свойства. Как правило, лучше налагать требования менее строгих разрешений на метод доступа "get", чем на метод доступа "set", если только свойство не содержит критичную информацию, например пароль.
.gif "Примечание")
Примечание.Безопасность на основе ролей использует несколько иную семантику, нежели проверки управления доступа для кода. Дополнительные сведения см. в разделе Безопасность на основе ролей.
Примечание.Требования могут применяться только на уровне класса, метода, события или свойства; сборки и отдельные переменные члены, не являющиеся закрытыми, не могут быть защищены требованиями. Требования, налагаемые на уровне сборки или не закрытой переменной, не приведут к выдаче предупреждения компилятора. Таким образом, для обеспечения защиты, реализуемой с помощью требований, следует использовать свойства вместо открытых членов.
См. также
Основные понятия
Написание безопасных библиотек классов