CAS уменьшает вероятность того, что вашим кодом воспользуется какой-то другой, вредоносный код. Эта модель защиты позволяет указывать операции, которые разрешается вы­полнять вашему коду, и операции, для него запрещенные. В частности, CAS поддерживает механизм разрешений; через него код может явно зап­росить одни разрешения и явно отказаться от других, которые ему никог­да не понадобятся.

Полномочия кода

Защита по правам доступа кода основана на концепции разрешений. Каж­дое разрешение соответствует праву на доступ кода к защищенному ресур-например к файлу, каталогу или записи в реестре, либо праву на выпол­нение защищенной операции вроде вызова неуправляемого кода. Код мо­жет затребовать определенные разрешения, а политика безопасности ис­полняющей среды определяет, какие из них можно выдать. Полный спи­сок разрешений см. в «Code Access Permissions» (http://msdn.microsoit.com/ library/еп-us/cpguide/html/cpconcodeaccesspermissions. asp).

.NET позволяет администраторам назначать приложениям предопределен­ный набор разрешений. Эти наборы различаются в зависимости от уров­ня доверия к приложению. По умолчанию уровень доверия зависит от цифровой подписи кода, источника и местонахождения приложения.

Так, приложения, выполняемые на UNC-pecypce (в зоне безопасности Intranet), получают набор разрешений Local Intranet, а приложения, рабо-тающио на локальном компьютере (в зоне безопасности MyCompuici), — набор разрешений FullTrust.

WebnpH.io/Kemm ASP.NET можно настраивать еще детальнее, присваивая им уровни доверия. Для этого служат элементы <;?usп> в конфигурацион­ном файле.

<trust level^Fuii | High | Low | None" originUrl= urf />

Каждый уровень присваивает приложению разрешения, состав которых определен в XML-файле политики безопасности. Каждый уровень сопос­тавлен со своим файлом. Сопоставления по умолчанию в ASP.NET таковы.

• High (Высокий) — соответствуетweb. highiiust.config. Разрешения этого уровня предоставляют приложению права на доступ для чтения и записи в каталог приложения (в зависимости от разрешений, опре­деленных в операционной системе) и позволяют ему заменять объект участника аутентификации (authentication principal object). Кроме того, они запрещают приложению вызывать неуправляемый код.

• Low (Низкий) — соответствует we h iowtrust.coiifig. Этот уровень по­зволяет читать каталог приложения и ограничивает сетевые соедине­ния. Приложения могут подключаться к своему хост-сайту при усло­вии правильной настройки атрибута originUrl элемента <trust>.

• None (Нет) — соответствует^е1\_по1п^иоппд. Этот уровень предос­тавляет базовые разрешения на выполнение кода и позволяет прило­жению использовать изолированное хранилище (механизм, который дает возможность безопасно  код с сохраненными данными).

Заметьте, что с уровнем доверия Full не связан какой-либо конфигураци­онный файл, поскольку этот уровень позволяет приложению использовать все ресурсы (в зависимости от разрешений, определенных в операционной системе), что равносильно его выполнению без CAS (хотя для управляе­мого кода CAS отключить нельзя). Вы можете переопределить эти сопос­тавления в элементе <securityPolicy> конфигурационного файла, а также настроить и расширить каждый уровень. Или создать собственные уров­ни с произвольным набором разрешений. Набор сопоставлений, заданных в <securityPolicy> по умолчанию, показан ниже.

<securityPolicy>

<trustl_evel name="Full" policyFile="internal" /> <trustLevel name="High" policyFile="web_hightrust.config" /> <trustl_evel   name="Low"   policyFile="webriowtrust.config" /> <trustLevel name="None" policyFile="web_notrust.conflg" />

</securityPoliQy>

Блокировка конфигурационных параметров

Конфигурация ASP.NET имеет иерархическую природу, и конфигурацион­ные файлы могут располагаться на уровне компьютера, приложения и суб­приложения. Конфигурационные файлы нижних уровней могут переопре­делять параметры конфигурационных файлов верхних уровней и вклю­чать дополнительную конфигурационную информацию. Хотя такая струк­тура обеспечивает высокую гибкость, администраторам может потребо­ваться блокировка конфигурационных параметров и запрет на их

изменение конкретными приложениями. Так, администратор Web-сайта может указать уровень защиты по правам доступа кода и запретить его из­менение в отдельных приложениях. Для этого служит элемент <loeatK>n> в сочетании с атрибутом allowOverride.

Например, администратор Web-сайта хочет запретить вызовы неуправля­емого кода. Следующий фрагмент конфигурационного файла демонстри­рует, как блокировать параметры защиты для всего сайта и ограничить все приложения высоким уровнем доверия (не позволяющим вызывать неуп­равляемый код):

location path="somesitepath" allowOverride="false">

<trust level="high" originUrl="http://somesite.com" /> </location>

Атрибут path может ссылаться на сайт или виртуальный каталог и приме­няется к указанному каталогу и всем его подкаталогам. В примере, приве­денном выше, при атрибуте allowOverride, равном false, приложения на сайте не смогут переопределять конфигурационные параметры, заданные в элементе <location>. Блокировать можно любые параметры — не только параметры защиты вроде уровней доверия.

Более подробные сведения см. по ссылкам:

• «Security in .NET: Enforce Code Access Rights with the Common Lan­guage Runtime* (http://msdn.microsoft.com/library/en-us/dnmagO 1/ htrnl/CAS.asp);

•     «Code Access Security* (http://msdn.microsoft.com/Hbrary/en-us/cpgui-de/htmi/cpconcodeaccesspermissions.asp).

Защита на уровне каналов

Каналы передают сообщения через границы удаленно взаимодействую­щих AppDomain'oH, процессов и компыотерои. В .NET Framework есть два канала: HTTP и TCP.

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

Вот некоторые из основных особенностей канальной защиты.

• HTTP-канал в IIS поддерживает передачу и прием данных, защищен­ных с помощью SSL SSL — наиболее распространенный механизм со­здания защищенного коммуникационного канала и настраивается в IIS,

• Даже при использовании незащищенного канала, например HTTP по порту 80 или TCP, вы можете вручную шифровать данные через Cryp­tographic API.

• Можно реализовать механизм канальной защиты ниже транспортного уровня. В Windows 2000 дая защиты данных при передаче прозрачно для приложения можно использовать Internet Protocol Security (IPSec).

• При использовании ASP.NET совместно с СОМ- или DCOM-компо­нентами и применении DCOM в качестве механизма удаленного вза­имодействия обратите внимание на уровень аутентификации DC ОМ Packet Privacy, позволяющий шифровать данные, передаваемые через

DCOM.

Более подробные сведения см. по ссылкам:

•     «Secure Web Conimimica!jo.is» в Microsoft Windows 2000 Server Reso­urce Kit (Microsoft Press);

• спецификацию удаленного взаимодействия в «.NET Framework Deve­loper Specifications* (http://msdn.microsoft.com/Hbrary/en-us/dndot-net/html/introremoting.asp);

• разделы MSDN по настройке защиты DCOM и NT.

Дополнительные сведения

Дополнительную информацию по вопросам безопасности, рассмотренным

в данном                            см. в:

•     ^Understanding Digital Certificates* в Microsoft Windows 2000 Server Resource Kit (Microsoft Press);

• .NET Framework SDK (http://msdn.microsoft.com/library/en-us/net-start/html/sdkstartasp ) ;

• статыоСМ 58229 в Microsoft Knowledge Buse «INFO: Security Ramifica­tions for IIS Applications» (http://support.microsoft.com/default.asp-x?scid=kb;en-us;158229);

•     «A Blueprint for Building Web Sites Using the Microsoft Windows Plat­form* (http://msdn.microsoft.com/library/en-us/dndna/html/dnablue-

print.asp).

Подробнее о защите Web-сервисов см. по ссылкам:

• «Secure Web Services Using the SOAP Toolkit* (http://msdn.micro-soft.com/library/en-us/dnwebsrv/html/websvcs_usingsoap.asp);

• «Designing Secure Web-Based Applications for Microsoft Windows 2000»

(Microsoft Press);

•      «Secure Internet Information Services 5 Checklist* (http://www.micro-

soft.com/TechNet/prodtechnol/iis/tips/iis5chk.asp);

•     статью 0_1«75Ш; в Microsoft Knowledge Base «List of NTFS Permissions Required for IIS Site to Work» (http://support.microsoft.com/default.asp-x?scid=kb;en-us; 187506).

Общие сведения о защите см. в:

•      «Microsoft Security* (lui р/ / www. mie n ..sou .com/sec u rit y ■ T

Благодарности

Выражаю глубокую признательность всем, кто внес свой вклад в подготов­ку этого документа, и рецензентам:

Rob Howard, Erik Olson, Venkat Chilakala, Michael Monteiro (Sapient), Suresh Kandula (Sapient), Chris Brooks, Edward Jezierski, Alex Mackman, Mikejenne, David Mowers, Amitabh Srivastava, Steve Busby, Kenny Jones.

Чтобы лучше освоить передовой опыт применения ,NI:T, вы можете обра­титься к экспертам по технологиям в Центре технологий Microsoft в ва­шем регионе. За более подробной информацией, пожалуйста, обращайтесь на Web-страницу Microsoft Technology Centers (http://www.microsoft.com/ business/services/mtc .asp).


Приложение А

Безопасный код



Детские товары приманка для карапузов и их мам.