Симон Робинсон - C# для профессионалов. Том II
Система безопасности на основе ролей в .NET строится на системе безопасности из MTS и COM+ 1.0 и предоставляет гибкую среду, создающую ограждения вокруг разделов приложения, которые должны быть защищены. Если система COM+ 1.0 установлена на машине, ее безопасность на основе ролей будет интерпретироваться в NET, однако COM не требуется .NET на основе ролей для функционирования системы безопасности.
Принципал Windows
Создадим консольное приложение, предоставляющее доступ к принципалу в приложении. в котором мы хотим пользоваться описанной ниже учетной записью Windows. Нам необходимы пространства имен System.Security.Principal и System.Threading. Прежде всего нужно задать, что мы хотим, чтобы .NET автоматически соединял принципал с описанной ниже учетной записью Windows, так как в .NET это не происходит автоматически по соображениям безопасности. Наше задание:
using System;
using System.Security.Principal;
using System.Security.Permissions;
using System.Threading;
namespace SecurityApplication2 {
class Class1 {
static void Main(string[] args) {
AppDomain.CurrentDomain.SetPrincipalPolicy(
PrincipalPolicy.WindowsPrincipal);
Можно использовать метод WindowsIdentity.GetCurrent() для доступа к данным учетной записи Windows, однако такой способ подходит, когда необходимо взглянуть на принципал один раз. Если необходимо обратиться к принципалу несколько раз, то более эффективно задать политику так, чтобы текущий поток выполнения предоставлял доступ к принципалу. При использовании метода SetPrincipalPolicy определяется, что принципал в текущем потоке выполнения должен поддерживать объект WindowsIdentity. Добавим код для доступа к свойствам принципала из объекта Thread:
WindowsPrincipal principal =
(WindowsPrincipal)Thread.CurrentPrincipal;
WindowsIdentity identity = (WindowsIdentity)principal.Identity;
Console.WriteLine("IdentityTyрe:" + identity.ToString());
Console.WriteLine("Name:" + identity.Name);
Console.WriteLine(
"Users'?:" + principal.IsInRole("BUILTIN\Users"));
Console.WriteLine(
"Administrators' ?: " +
principal.IsInRole(WindowsBuiltInRole.Administrator));
Console.WriteLine("Authenticated:" + identity.IsAuthenticated);
Console.WriteLine("AuthType:" + identity.AuthenticationType);
Console.WriteLine("Anonymous?:" + identity.IsAnonymous);
Console.WriteLine("Token:" + identity.Token);
}
}
}
Вывод из этого консольного приложения будет выглядеть похожим на следующий, в зависимости от конфигурации машины и ролей, ассоциированных с учетной записью, под которой вы зарегистрировались в системе:
IdentityType:System.Security.Principal.WindowsIdentity
Name:MACHINEalaric
'Users'?:True
'Administrators'?:True
Authenticated:True
AuthType:NTLM
Anonymous?:False
Token:256
Очевидно, что крайне полезно иметь возможность получить так легко доступ к данным о текущем пользователе и его ролях, чтобы с помощью этой информации решать, какие действия выполнить и какие отменить. Роли и группы пользователей Windows предоставляют администраторам дополнительную возможность использовать стандартные утилиты администрирования пользователей, и обычно можно избежать изменения кода, когда изменяются роли пользователя. Рассмотрим роли более подробно.
Роли
Представим сценарий, где имеется приложение интранет, использующее учетные записи Windows. Система имеет группу Manager и группу Assistant, пользователи относятся к этим группам в зависимости от их роли в организации. Пусть приложение содержит свойство, выводящее информацию о сотрудниках, и желательно, чтобы к нему имела доступ только группа Manager. Можно легко применить код, который проверяет, является ли текущий пользователь членом группы Manager, и разрешать или запретить ему доступ на основе этого.
Однако, если в дальнейшем будет решено реорганизовать группы учетных записей и ввести группу 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 не позволяют обрабатывать исполнимые файлы из почтовых сообщений, пользователь предупреждается, что они могут содержать вирусы, и сохраняет их на диске, где имеются возможности для установки административных ограничений, включая блокирование доступа к локальному диску и работу антивирусного программного обеспечения.
Однако .NET существенно помогает операционной системе в ответах на вопросы, сколько полномочий предоставить коду, будет ли он приложением интранет, элементом управления на странице Web или приложением Windows Forms, загруженным от поставщика программного обеспечения в Интернете.
Конфигурационный файл системы безопасности
Как мы уже видели, общим звеном, соединяющим группы кода, полномочия и множества полномочий, являются три уровня политики системы безопасности (Enterprise, Machine и User). Информация о конфигурации системы безопасности в .NET хранится в конфигурационных файлах XML, которые защищены системой безопасности Windows. Например, политика безопасности уровня Machine распространяется только на пользователей групп Administrator, Power User и SYSTEM в Windows 2000.
В Windows 2000 файлы, которые хранят политику безопасности расположены в следующих местах:
Конфигурация политики предприятия
C:WinNTMicrosoft.NETFrameworkv1.0.xxxxConfigenterprise.config
Конфигурация политики машины
C:WinNTMicrosoft.NETFrameworkv1.0.xxxxConfigsecurity.config
