Иллюстрированный самоучитель по Architecture .NET

Защита

  • Защита или безопасность

    Защита, или безопасность – это одно из основных требований к приложениям и при разработке ее следует учитывать не в последнюю очередь. Однако из педагогических соображений говорить о защите легче тогда, когда уже состоялось знакомство с прикладной моделью .NET, а также с ASP.NET и Web-службами.
  • Защита на основе пользователей

    С позиции традиционной защиты, работающей на основе пользователей, вопрос опознавания состоит в следующем: "Что за личность пытается выполнить определенное действие?" Под личностью обычно понимается имя или учетная запись пользователя.
  • Защита доступа к коду. Политика безопасности. Разрешения.

    Одна из трудностей мира программ, таких, как компоненты от сторонних производителей и загружаемый по сети код, состоит в следующем: вы открываете свою систему для угрозы и риска, идущих от выполняемого кода неизвестного происхождения.
  • lnternet-безопасность. Информационный сервер Internet: Internet Information Server (IIS).

    Для ограничения доступа на ваш компьютер с некоторых IР-адресов можно использовать систему защиты протокола Internet DPSec (Internet Protocol Security). Это делается с помощью дополнительного модуля IP Security Policy Management (управление политикой защиты протокола Internet), присоединенного к консоли ММС. Конечно, еще должны быть известны IP-адреса клиентов.
  • Защита .NET на основе ролей. Принципалы и личности.

    Большинство людей имеют хотя бы интуитивное представление о пользователях и паролях. В то же время сервер транзакций корпорации Microsoft (MTS) и СОМ+ поддерживают хорошо известную и легкую для понимания систему зашиты на основе ролей.
  • Роли .NET в Windows

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

    Теперь более подробно рассмотрим другие классы личностей. Сейчас в .NET Framework есть четыре таких класса: | FormsIdentity используется классом FormsAuthenticationModule. Мы поговорим о классе Forms Identity, когда будет обсуждаться опознавание форм ASP.NET;
  • Личность в операционной системе и общеязыковой среде выполнения CLR. Разрешения коду на доступ.

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

    В примере SimplePermissionCodeRequest вначале запрашивается разрешение на доступ к файлу. Если в ответ на этот запрос общеязыковая среда выполнения CLR разрешения не дает, то внутри конструктора файлов она запускает исключение SecurityException.
  • Как работает запрос на разрешение. Стратегия запроса разрешений. Запрет разрешений.

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

    Метод Assert Утвердить) позволяет вам требовать разрешение, даже если у вас нет соответствующих прав доступа. Вам также может потребоваться утвердить разрешение еще и потому, что, хотя ваша сборка и обладает нужным правом, но другие вызовы из цепочки вызовов его не имеют.
  • Класс SecurityPermission

    Класс SecurityPermission управляет "метаразрешениями", которые, в свою очередь, управляют подсистемой защиты общеязыковой среды выполнения CLR. Давайте снова обратимся к примеру RoleBasedSecurity, который уже рассматривали в этой главе.
  • Неуправляемый код. Разрешения на основе атрибутов.

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

    Безопасность на основе ролей управляется классом PrincipalPermission. Пример под тем же названием проверяет с помощью этого класса, что личность пользователя, под которой запускается программа, – это Administrator (Администратор).
  • Класс PermissionSet

    С набором разрешений можно работать, используя класс PermissionSet. Методы AddPermission и RemovePermission дают возможность добавлять в набор экземпляры класса, производного от CodeAccessPermission. Тогда методы Deny (Запретить), PermitOnly или Assert (Утвердить) можно применять не к отдельным разрешениям, а к целым их наборам.
  • Личность кода. Классы разрешений для личности. Подтверждение.

    Характеристики, по которым можно идентифицировать сборку, являются ее разрешениями для личности. В качестве примера можно указать строгое имя сборки или Web-узел, сгенерировавший тот или иной код. Общеязыковая среда выполнения CLR предоставляет разрешения для личности на основе подтверждения, предоставленного загрузчиком или надежным хостом.
  • Политика безопасности. Уровни политики безопасности. Кодовые группы.

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

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