C# для профессионалов. Том II
вернуться

Ватсон Карли
Шрифт:

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

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

Лучшим решением было бы создание полномочия, называемого, предположим,

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

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

Так же, как в случае с системой безопасности доступа к коду, можно реализовать запросы безопасности на основе ролей ("пользователь должен быть в группе Administrators"), используя обязательные запросы (см. предыдущий раздел), или использовать атрибуты. Возможно декларативное определение требований к полномочию на уровне класса в таком виде:

using System;

using System.Security;

using System.Security.Principal;

using System.Security.Permissions;

namespace SecurityApp3 {

 class Class1 {

static void Main(string[] args) {

AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);

try {

ShowMessage;

} catch (SecurityException exception) {

Console.WriteLine(

"Security exception caught (" + exception.Message + ")");

Console.WriteLine(

"The current principal must be in the local"

+ "Users group");

}

}

(PrincipalPermissionAttribute(SecurityAction.Demaid, Role =

"BUILTIN\\Users"));

static void ShowMessage {

Console.WriteLine("The current principal is longed in locally");

Console.WriteLine("they are a member of the local Users group)");

}

 }

}

Метод

ShowMessage
будет порождать исключение, если приложение выполняется не в контексте пользователя из группы локальных Users в Windows 2000. Что касается приложений Web, то учетная запись, под которой выполняется код ASP.NET, должна быть в группе, хотя в реальном мире определенно будут избегать добавления этой учетной записи в группу администраторов.

Если выполнить приведенный выше код с помощью учетной записи в локальной группе Users, то вывод будет таковым:

The current principal is logged in locally

(they are a member of the local Users group)

Дополнительную информацию о системе безопасности на основе ролей в .NET можно найти в документации MSDN для пространства имен

System.Security.Principal
.

Управление политикой системы безопасности

Аспекты безопасности .NET разработаны значительно полнее и шире, чем какие-либо другие вопросы в Windows, но все же есть и которые ограничения, о которых необходимо знать:

□ Политика системы безопасности .NET не обеспечивает безопасность на неуправляемом коде (хотя обеспечивает некоторую защиту от обращении к неуправляемому коду).

□ Если пользователь копирует сборку на свою локальную машину, сборка имеет полномочия

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

□ Политик системы безопасности .NET предоставляет очень небольшую помощь при борьбе со злонамеренными файлами .ЕХЕ Win32 и вирусами на основе сценариев, с которыми Microsoft борется различными способами. Например недавние версии Outlook не позволяют обрабатывать исполнимые файлы из почтовых сообщений, пользователь предупреждается, что они могут содержать вирусы, и сохраняет их на диске, где имеются возможности для установки административных ограничений, включая блокирование доступа к локальному диску и работу антивирусного программного обеспечения.