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

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

Шаг 2 – Определение ключевых сценариев

После того, как границы доверия в приложении обозначены, необходимо определиться с ключевыми сценариями, в которых требуется валидация данных. Все вводимые пользователем данные до тех пор, пока не пройдут валидацию, должны рассматриваться как злонамеренные. Например, в слое представления Веб-приложения подлежат проверке поля форм, строки запросов и скрытые поля; параметры запросов GET и POST; загруженные данные (злонамеренные пользователи могут перехватывать HTTP-запросы и изменять содержимое); и cookies (которые располагаются на клиентском компьютере и могут быть изменены).

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

Шаг 3 – Выбор места валидации

На этом этапе определяемся с местом проведения валидации: на клиенте или и на сервере, и на клиенте. Никогда не полагайтесь только на валидацию на стороне клиента. Используйте ее для обеспечения более интерактивного UI, но всегда реализуйте также и валидацию на стороне сервера, чтобы безопасно проверить данные в рамках границ доверия. Валидация данных и бизнес правил на клиенте может сократить количество циклов запрос-ответ к серверу и улучшить взаимодействие с пользователем. Для Веб-приложения браузер клиента должен поддерживать DHTML и JavaScript, в идеальном варианте реализованный в отдельном файле .js для обеспечения возможности повторного использования и кэширования браузером. Самый простой подход в Веб-приложении – применение элементов управления валидацией ASP.NET. Это набор серверных элементов управления, которые могут проводить валидацию данных на стороне клиента, и также будут автоматически проверять их на стороне сервера.

В Веб-приложении проверка данных и бизнес-правил на стороне сервера может быть реализована с использованием элементов управления валидации ASP.NET. Также, как альтернативный вариант для Веб- и других типов приложений, используйте Validation Application Block (Блок валидации) от группы patterns & practices. Validation Application Block

поможет создать логику валидации, пригодную для повторного использования в разных слоях.

Validation Application Block может применяться в приложениях Windows Forms, ASP.NET и WPF.

Подробно Validation Application Block рассматривается в приложении F, «Enterprise Library от patterns & practices».

Шаг 4 – Выработка стратегий валидации

Рассмотрим общие стратегии валидации данных:

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

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

Очистка. Известные плохие символы или значения устраняются или преобразовываются с целью сделать ввод безопасным. Как и подход со списком запрещенного ввода (негативная проверка), применяйте эту стратегию с осторожностью и только как вторую линию защиты, поскольку очень сложно создать исчерпывающий список критериев для всех известных недействительных вводов.

Шаблоны проектирования

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

Категория	Шаблоны
Кэширование	Cache Dependency (Кэш с зависимостью). Использует внешние
	данные для определения состояния данных, хранящихся в кэше.
	Page Cache (Кэш страниц). Улучшает время ответа динамических
	Веб-страниц, доступ к которым осуществляется довольно часто, но
	сами они меняются реже и потребляют большое количество ресурсов
	системы для воссоздания.
Сетевое взаимодействие	Intercepting Filter (Перехватывающий фильтр). Цепочка пригодных
	для компоновки фильтров (независимые модули), реализующих
	обычные задачи предварительной и последующей обработки при
	запросе Веб-страницы.
	Pipes and Filters (Каналы и фильтры). Выполняет маршрутизацию
	сообщений по каналам и фильтрам, которые могут изменять или
	проверять сообщение при его прохождении по каналу.
	Service Interface (Интерфейс сервиса). Программный интерфейс,
	который может использоваться другими системами для

взаимодействия с сервисом.

Более подробно шаблоны Page Cache, Intercepting Filter и Service Interface рассматриваются в статье «Enterprise Solution Patterns Using Microsoft .NET» по адресу http://msdn.microsoft.com/en-us/library/ms998469.aspx.

Более подробно шаблон Pipes and Filters рассматривается в статье «Integration Patterns» по адресу http://msdn.microsoft.com/en-us/library/ms978729.aspx.

Предложения группы patterns & practices

Узнать о дополнительных предложениях группы Microsoft patterns & practices можно из следующих источников:

Enterprise Library включает наборы блоков приложений, использование которых упростит реализацию типовых задач, таких как кэширование, обработка исключений, валидация, протоколирование, шифрование, управление учетными данными, а также средства для реализации таких шаблонов, как Inversion of Control (Инверсия управления) и Dependency Injection. Подробнее рассматривается в статье

«Microsoft Enterprise Library» по адресу http://msdn2.microsoft.com/enus/library/cc467894.aspx.

Unity Application Block легковесный расширяемый контейнер внесения зависимостей, который будет очень полезен при создании слабо связанных приложений. Более подробно рассматривается в статье «Unity Application Block» по адресу http://msdn.microsoft.com/en-us/library/cc468366.aspx.

Дополнительные источники

Электронная версия списка используемых источников доступна по адресу http://www.microsoft.com/architectureguide.

Больше сведений по аутентификации и авторизации можно найти в следующих статьях:

«Authorization» по адресу http://msdn.microsoft.com/en-us/library/cc949059.aspx.

«Authorization In WCF-Based Services» (Авторизация в WCF-сервисах) по адресу http://msdn.microsoft.com/en-us/magazine/cc948343.aspx.

«Designing Application-Managed Authorization» (Проектирование управляемой приложением авторизации) по адресу http://msdn.microsoft.com/enus/library/ms954586.aspx.

«Enterprise Authorization Strategy» (Корпоративная стратегия авторизации) по адресу http://msdn.microsoft.com/en-us/library/bb417064.aspx.

«Federated Identity: Scenarios, Architecture, and Implementation» (Интегрированная идентификация: сценарии, архитектура и реализация) по адресу http://msdn.microsoft.com/en-us/library/aa479079.aspx.

«Guidance on Patterns & Practices: Security» (Руководство Patterns & Practices:

безопасность) по адресу http://msdn.microsoft.com/en-us/library/ms954624.aspx.

«Trusted Subsystem Design» (Проектирование доверенных подсистем) по адресу http://msdn.microsoft.com/en-us/library/aa905320.aspx.

Дополнительную информацию по все остальным темам, затрагиваемым в данной главе, можно найти в следующих статьях:

«Caching Architecture Guide for .NET Framework Applications» (Руководство по архитектуре кэширования для приложений .NET Framework) по адресу http://msdn.microsoft.com/en-us/library/ms978498.aspx.

«Cohesion and Coupling» (Связность и связанность) по адресу http://msdn.microsoft.com/en-us/magazine/cc947917.aspx.

Duffy, Joe. Concurrent Programming on Windows1. Addison-Wesley 2009.

«Enterprise Solution Patterns Using Microsoft .NET» по адресу http://msdn.microsoft.com/en-us/library/ms998469.aspx.

«Exception Management Architecture Guide» (Руководство по архитектуре управления исключениями) по адресу http://msdn.microsoft.com/en-us/library/ms954599.aspx.

«Integration Patterns» по адресу http://msdn.microsoft.com/enus/library/ms978729.aspx.

«Microsoft Project Code Named Velocity» по адресу http://msdn.microsoft.com/enus/data/cc655792.aspx.

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

Castle Project по адресу http://www.castleproject.org/index.html.

Ninject по адресу http://ninject.org/.

PostSharp по адресу http://www.postsharp.org/.

StructureMap по адресу http://structuremap.sourceforge.net/Default.htm.

memcached по адресу http://www.danga.com/memcached/.

NLog по адресу http://www.nlog-project.org/.

log4net по адресу http://logging.apache.org/log4net/.

1 Джо Даффи, «Параллельное программирование в Windows»