SQL Server 2005 включает в себя операционную среду Windows .NET Framework 1.1. Интеграция среды исполнения .NET Common Language Runtime (CLR) в рабочий цикл SQL Server 2005 - неординарное изменение, некорректная реализация которого могла бы полностью дестабилизировать работу SQL Server 2005. После обсуждения рисков, снизить которые стремились разработчики SQL Server 2005, мы попытаемся обосновать целесообразность усилий, затраченных на внедрение CLR в SQL Server 2005.
В ходе работ по интеграции CLR разработчикам SQL Server 2005 пришлось трудиться над уменьшением рисков, связанных с нарушением стабильности и безопасности. Для начала сделаем следующую оговорку: функционирование CLR внутри SQL Server 2005 само по себе не создает новых лазеек в системе безопасности SQL Server 2005. Технология CLR не несет в себе никаких особенностей, порождающих новые проблемы с безопасностью.
Для анализа рисков, связанных с нарушением стабильности и безопасности, рассмотрим упрощенный сценарий. В системах Windows среда CLR функционирует под Microsoft IIS. Предположим, что по какой-либо причине работа CLR оказалась заблокирована. В рамках IIS наиболее вероятным решением является простой перезапуск IIS. Как и следовало предположить, это решение не идеально. Однако, учитывая все аспекты, даже такой неблагоприятный сценарий является относительно приемлемым. В худшем случае перезапуск вызовет сбой сеансов нескольких пользователей. В рабочей группе, функционирующей в условиях сбалансированной нагрузки, факт перезагрузки, возможно, заметит только тот пользователь, чей запрос инициировал зависание.
Рассмотрим аналогичный сценарий применительно к условиям SQL Server 2005. Если CLR "повисла" в среде SQL Server 2005, перезапуск может оказаться единственным решением. Однако для сервера базы данных незапланированные перезапуски такого рода неприемлемы. Даже самые лучшие методы обеспечения отказоустойчивости не предусматривают возможности перезапуска. Для вариантов выравнивания нагрузки, поддерживаемых в корпоративных системах SQL Server, данный тип риска абсолютно неприемлем.
Над предотвращением такого сценария группа разработчиков SQL Server 2005 работала совместно с группой .NET Framework CLR. Цель состояла в обеспечении перехода к механизмам управления транзакциями и отслеживания заблокированных процессов, действующим в SQL Server 2005, в случае возникновения проблем. Исключение возможности нарушения внутренней надежности SQL Server 2005 потребовало критической оценки запросов на использование средств .NET. Помимо анализа кода запросов, определялись запросы, для которых возможна организация безопасного управления в рамках структуры CLR, перезапуск которой может оказаться невозможным на протяжении ряда лет.
Использование языков разработки .NET позволяет CLR обращаться к файловой системе и Web-службам на базе XML. Таким образом, для внутренних процессов SQL Server 2005 возможен доступ к кодам, функционирующим за рамками среды SQL Server. При этом могут возникать проблемы, решение которых находится за пределами управляющих возможностей рабочего процесса.
К счастью, обращения к внешним ресурсам, например, файловой системе или Web-службе XML, предполагают использование специфических возможностей .NET. Это позволило разработчикам SQL Server 2005 задействовать общую модель для внедрения возможностей .NET в SQL Server 2005. Организация базовой модели предусматривает три яруса разрешений в зависимости от кода безопасности доступа Code Access Security (CAS). Самый нижний ярус составляет набор безопасных (SAFE) разрешений, открывающих доступ лишь к тем возможностям .NET, которые не подвергают SQL Server 2005 рискам, более существенным, чем риски, связанные с использованием "родной" технологии T-SQL. Таким образом, этот набор разрешений должен "включать зеленый свет" в вашем сознании. Фактически, для использования преимуществ технологии .NET в рамках SQL Server 2005 рекомендуем ограничиться использованием набора безопасных разрешений SAFE.
Следующий ярус CAS представлен набором разрешений доступа к внешним ресурсам (EXTERNAL_ACCESS) с возможностью использовать функции .NET, предполагающие обращение к реестру и файловой системе. Из определения видно, что эти возможности инициируют возникновение "брешей" в системе безопасности, которые в определенных условиях могут стать источником неразрешимой проблемы вне базы данных, либо спровоцировать повреждение системы. Реальность такова, что эти возможности должны регулироваться в бизнес-объектах, поэтому данный набор разрешений должен инициировать желтый, предупреждающий сигнал в вашем сознании. У некоторых разработчиков есть потребность в использовании этих разрешений. Их применение может быть безопасным, хотя зачастую приводит к ошибке в общеархитектурной логике и схеме проекта.
Третий и последний ярус CAS должен "включать красный свет" в вашем сознании. Этот ярус известен как набор не гарантирующих безопасность (UNSAFE) разрешений, которые, однако, с полным основанием можно называть опасными (UNSECURED) или абсолютно безрассудными (INSANE). Эти разрешения предусматривают полную свободу действий управляемого кода и разрешение обращений к неуправляемому коду. Настройку этого набора разрешений может выполнять только администратор базы данных, который должен быть готов к тому, что его попросят сменить место работы. Самая удачная аналогия - реакция водителя на запрещающие сигналы светофора. Ничто не мешает водителю игнорировать красный свет, и некоторое время можно это делать, не попадая в аварию. Однако если вести себя подобным образом постоянно, рано или поздно расплата наступит.
Что же заставило разработчиков SQL Server 2005 затратить столько усилий на интеграцию технологии .NET? Как утверждают в Microsoft, это позволяет создавать более эффективные определяемые пользователем типы (UDT), агрегаты и определяемые пользователем функции (UDF). В основе всех перечисленных возможностей лежит способность определять заказные структуры данных и лучше ими управлять, точнее говоря, способность задействовать язык XML внутри базы данных. Идея обеспечения функционирования .NET CLR в рамках SQL Server 2005 заключается в поддержке сложных структур данных, которые можно создавать, сохраняя данные XML внутри SQL Server 2005.
Билл Шелдон - С ним можно связаться по адресу: bsheldon@interknowlogy.com.