Содержание

Тема 1. Общие положения теории информационной безопасности. Сущность безопасности баз данных. 3

Введение. 3

Вопрос 1. Задачи обеспечения информационной безопасности баз данных. 11

Вопрос 2. Критерии качества баз данных. 15

Вопрос 3. Сущность понятия безопасности баз данных. 19

Вопрос 4. Основные подходы к методам построения защищенных информационных систем. 20

Вопрос 5. Архитектура систем управления базами данных. 24

Вопрос 6. Структура свойства информационной безопасности баз данных. 28

Тема 2. Угрозы информационной безопасности баз данных. 31

Введение. 31

Вопрос 1. Источники угроз информации баз данных. 33

Вопрос 2. Классификация угроз информационной безопасности баз данных. 35

Вопрос 3. Угрозы, специфичные для систем управления базами данных. 41

Вопрос 4. Объекты и субъекты моделей информационной безопасности баз данных на примере СУБД Oracle. 44

Контрольные вопросы: 49

Приложение 1. 50

Тема 3. Политика безопасности. 58

Введение. 58

Вопрос 1. Цель формализации политики безопасности. 59

Вопрос 2. Принципы построения защищенных систем баз данных. 61

Вопрос 3. Стратегия применения средств обеспечения информационной безопасности. 64

Контрольные вопросы: 67

Тема 4. Какие именно данные приложения следует хранить в базе данных?  68

Вопрос 1. Где хранить настройки приложений?. 68

Вопрос 2. Где хранить пользовательские настройки?. 69

Вопрос 3. Где хранить XML-документы. 71

Вопрос 4. Поддержка XML в SQL Server 2005. 72

Вопрос 5. Использование типа данных XML. 73

Вопрос 6. Типизированный или нетипизированный XML?. 76

Заключение. 79

Тема 5. Основные принципы обеспечения безопасности базы данных. 80

Тема 6. Управление доступом к базам данных SQL Server 92

Тема 7. Методы аварийного восстановления для защиты базы данных. 113

Тема 8. Полная модель восстановления. 123

Тема 9. Перенос базы данных на другие системы.. 134

Литература. 147

Основная литература: 147

Дополнительная литература: 147

Нормативно-правовые акты: 148

Интернет ресурсы: 148

Тема 1. Общие положения теории информационной безопасности. Сущность безопасности баз данных

Введение.

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

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

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

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

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

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

Число активных сайтов в Интернет неуклонно возрастает и приближается к психологически значимой отметке в 100 миллионов.

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

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

Учебный курс «Безопасность баз данных» соответствует Государственным образовательным стандартам высшего профессионального образования по специальностям группы «Информационная безопасность». Вопросы информационной безопасности баз данных излагаются с системных позиций. Представлена классификация основных угроз безопасности, отражена специфика, характерная для баз данных. Рассмотрены основные модели разграничения доступа.

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

Эффективное управление сложными организационными системами требует использования современных средств автоматизации. Основная цель всякой системы обработки информации — полное и своевременное удовлетворение информационных потребностей пользователей. Успешное решение этой задачи возможно только тогда, когда для каждого контингента пользователей автоматизированных систем обработки информации создана отвечающая их потребностям среда обработки данных. Одной из важнейших характеристик качества информационной системы — ядра всякой системы автоматизированного управления — является уровень обеспечения ее информационной безопасности. Важность поиска эффективных методов решения проблемы обеспечения информационной безопасности (ИБ) автоматизированных систем информационного обеспечения управления определена в Доктрине информационной безопасности Российской Федерации, утвержденной Указом Президента Российской Федерации 9 сентября 2000 г.

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

Ориентация на использование универсального клиента (браузера) как единого интерфейса доступа к корпоративной информационной инфраструктуре стала общепринятой.

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

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

·     оценочные стандарты, направленные на классификацию информационных систем и средств их защиты по требованиям безопасности;

·     технические спецификации, регламентирующие различные аспекты реализации средств защиты.

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

Первым оценочным стандартом, получившим широкое распространение и оказавшим огромное влияние на базу стандартизации подходов к определению уровня информационной безопасности информационных систем вообще, и баз данных в частности, стал стандарт министерства обороны США «Критерии оценки доверенных компьютерных систем».

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

·     уровня прикладного программного обеспечения, отвечающего за взаимодействие с пользователем;

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

·     уровня операционной системы, отвечающего за функционирование СУБД и иного прикладного программного обеспечения;

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

Система защиты должна эффективно функционировать на всех этих уровнях.

Проблема обеспечения безопасности автоматизированных информационных систем может быть определена как решение трех взаимосвязанных задач по реализации требуемого уровня:

·     конфиденциальности — обеспечения пользователям доступа только к данным, для которых пользователь имеет явное или неявное разрешение на доступ (синонимы — секретность, защищенность);

·     целостности — обеспечения защиты от преднамеренного или непреднамеренного изменения информации или процессов ее обработки;

·     доступности — обеспечения возможности авторизованным в системе пользователям доступа к информации в соответствии с принятой технологией (синоним — готовность).

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

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

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

Современная СУБД — это совокупность взаимодействующих процессов и совместно используемая область оперативной памяти, обеспечивающая логическое управление данными стандартными языковыми средствами в соответствии с предписанной (настроенной) технологией. Управляемая система баз данных, как правило, является распределенной, то есть физически может быть размещена на нескольких носителях, а возможно, и в нескольких узлах, взаимодействие которых осуществляется по протоколам транспортного уровня. Логически распределенная база данных может представлять единое целое либо являться совокупностью синхронно или асинхронно обновляемых копий.

Анализ информационной безопасности СУБД должен быть проведен по двум направлениям:

·     безопасность архитектурных решений и их программных реализаций собственно в СУБД;

·     безопасность взаимодействия с внешними по отношению к СУБД программными и аппаратными компонентами.

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

В процессе исследования дискреционной модели доступа важно обратить внимание на особенности реализации системных привилегий и привилегий доступа к объекту системы, в частности, механизмы предоставления и отзыва привилегий. Основой системы разграничения доступа в большинстве СУБД промышленного уровня является реализация принципа минимальных привилегий. Суть данного принципа состоит в том, что пользователю должно быть явно разрешено выполнение каждого действия в системе. Другими словами, возможность выполнения какого-либо действия в системе (начиная с регистрации пользователя) по умолчанию должна быть отключена или определена в минимально возможном объеме, определяемом объективными условиями эксплуатации системы.

Важнейший вопрос при проведении исследования реализации мандатной модели управления доступом — технология присваивания и изменения меток для объектов и субъектов. Реализация разграничения доступа на уровне кортежей предполагает наличие специального столбца с меткой доступа. Ясно, что технология изменения данных в таком специальном столбце должна отличаться от традиционной. В то же время введение специальных языковых средств — это явный отход от стандарта SQL, что для промышленной СУБД маловероятное решение.

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

Понятие роли вошло составной частью в последний стандарт SQL и стандарт Common Criteria для коммерческого профиля безопасности. Большое число пользователей, статус которых требует различных привилегий для доступа к ресурсам базы данных, создает значительный объем рутинной работы администратору. Роль — это поименованный набор привилегий, который может быть предоставлен пользователю или другой роли; по сути, языковое средство для автоматизации работы администратора по разграничению доступа. Описание привилегий, характерных для той или иной роли, готовится заранее. При регистрации нового пользователя в системе администратор выполняет только предоставление пользователю привилегий конкретной роли. При необходимости изменить привилегии конкретному приложению достаточно изменить только привилегии соответствующей роли. Все пользователи, отображенные на эту роль, автоматически получат измененные привилегии.

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

Специфическим для СУБД средством обеспечения информационной безопасности являются триггеры. Триггеры — это совокупности предложений языка SQL или некоторого иного процедурного языка, автоматически запускаемые сервером при регистрации определенных событий в системе. Триггеры выполняются системой автоматически до или после возникновения предопределенных событий, таких, как выполнения операций INSERT, UPDATE, DELETE в некоторой таблице. Обычно рассматривают два способа использования триггеров для повышения защищенности системы: дополнительный контроль допустимости действий пользователя и ведение специализированного (нестандартного) аудита действий пользователя. Особенностью триггеров является автоматически реализуемая возможность выполнить необходимые проверки полномочий перед выполнением операций над таблицами. Дополнительно отметим, что на одном множестве таблиц может быть определено несколько триггеров. Комбинации триггеров, выполняемых до и после операций, позволяют создавать изощренные механизмы проверки допустимости тех или иных действий в базе данных и фиксации (или откате) их результатов. Современные СУБД промышленного уровня поддерживает триггеры, запускаемые для определенных системных событий, в частности: начала и завершения сессии взаимодействия пользователя с системой, запуска и останова экземпляра сервера баз данных, создания и уничтожения объектов и т. п.

Новым направлением для СУБД промышленного уровня является наличие встроенных механизмов шифрования на уровне столбцов таблиц, в основном на базе алгоритмов DES и AES. Представлены встроенные генераторы псевдослучайных последовательностей и алгоритмы вычисления хеш-функций основных распространенных в США и Европе стандартов. Реализовано явное и неявное управление ключами.

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

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

Исследование вопросов сопряжения с программным обеспечением промежуточного уровня должно включать: выявление портов взаимодействия с внешним программным обеспечением и механизмов их активизации и переназначения (внутренние и внешние); устойчивость к перегрузкам каналов шумовым трафиком и вставкам ложных пакетов; возможности внутреннего и внешнего управления активизацией и перенастройкой параметров протоколов ODBC и JDBC; анализ алгоритмов и технологий линейного шифрования трафика межсерверного обмена и взаимодействия клиентского программного обеспечения с серверами баз данных.

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

В СУБД средство ведения аудита может быть реализовано в виде набора возможностей, управляемых языковыми средствами системы, или независимой утилиты (пакета). Средства аудита выполняют фиксацию информации об активности пользователей системы в словаре данных или в файле операционной системы — журнале аудита. Информация о настройках системы аудита хранится в специальном конфигурационном файле. Файл настройки или параметры команды активизации аудита определяют перечень событий, которые фиксируются системой аудита. Исследование средств аудита должно включать вопросы устойчивости системы аудита к несанкционированному изменению параметров системы и собственно данных аудита, а также избирательность средств аудита, включая возможность оптимизации параметров при заданных (стоимостных) критериях и ограничениях на объем используемых ресурсов системы.

Вопрос 1. Задачи обеспечения информационной безопасности баз данных.

Первоначально проблема обеспечения безопасности данных возникла при расширении круга пользователей ЭВМ и вычислительных систем. Увеличение количества ЭВМ и областей их применения расширило возможности модификации, хищения и уничтожения данных. Появление автоматизированных информационных систем (АИС) еще более усугубило проблему обеспечения безопасности данных. Можно выделить следующие этапы развития концепций обеспечения безопасности данных.

Центральной идеей первого этапа являлось намерение обеспечить безопасность данных механизмами, функционирующими по строго формальным алгоритмам. Для создания таких механизмов использовались технические и, в основном, программные средства. Программные средства защиты включались в состав операционных систем и систем управления базами данных. Слабым звеном разработанных механизмов защиты была технология разграничения доступа пользователей к данным. Поэтому следующим шагом к повышению эффективности защиты стала организация дифференцированного доступа к данным. Однако всесторонние испытания таких систем, как MULTICS и ADEPT-50, показали, что указанные системы, с точки зрения обеспечения безопасности данных, имеют множество недостатков. По мере усложнения программных систем, увеличения числа пользователей АИС и стало ясно, что необходима разработка идей защиты данных на более высоком уровне абстракции.

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

Концепции и технологии защиты данных в СУБД в основном состояли из модификаций соответствующих разработок для операционных систем. По мере развития теории моделей данных и языка SQL стало ясно, что проблема обеспечения безопасности баз данных имеет свою специфику, в первую очередь в области информационного и лингвистического обеспечения. По мере осознания роли собственника информации совершенствовалась технология механизмов защиты, которыми могли бы управлять пользователи АИС. Однако, несмотря на принимаемые меры, обеспечение эффективной защиты данных оказалось недостижимым, о чем свидетельствовали многочисленные факты нарушения безопасности данных.

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

Начало этим процессам было положено исследованиями вопросов защиты компьютерной информации, проведенными в конце 70-х — начале 80-х гг. Национальным центром компьютерной безопасности (NCSC —National Computer Security Center) министерства обороны США. Результатом этих исследований явилась публикация министерством обороны США в 1983 г. документа под названием «Критерии оценки надежных компьютерных систем», впоследствии по цвету обложки получившего название «Оранжевая книга». Этот документ стал фактически первым стандартом в области создания защищенных компьютерных систем и впоследствии основой организации системы сертификации компьютерных систем по критериям защиты информации.

Подходы к построению и анализу защищенных систем, представленные в «Оранжевой книге», послужили методологической и методической базой для дальнейших исследований в этой сфере. В 1991 г. NCSC был опубликован документ — Интерпретация «Критериев оценки надежных компьютерных систем» в приме- нении к понятию надежной системы управления базой данных. Этот документ, конкретизирующий и развивающий положения «Оранжевой книги» для решения задачи создания и оценки защищенных СУБД, известен также как «Розовая книга».

В конце 80-х-начале 90-х гг. аналогичные исследования по проблемам компьютерной безопасности были проведены во многих странах и созданы соответствующие национальные стандарты в этой сфере. В России Государственной технической комиссией при Президенте Российской Федерации (Гостехкомиссией) были разработаны и в 1992 г. опубликованы «Руководящие документы по защите от несанкционированного доступа к информации», определяющие требования, методику и стандарты построения защищенных средств вычислительной техники и автоматизированных систем.

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

Существо требований к оцениваемой системе может только усиливаться при переходе к более высоким классам защищенности. Например, «Руководящие документы по защите от несанкционированного доступа к информации» определяют, что самый низкий класс — седьмой, самый высокий — первый. Наличие некоторых средств защиты от несанкционированного доступа может требоваться только для некоторого множества высоких классов защищенности. Наличие или отсутствие конкретного средства защиты от несанкционированного доступа к данным является показателем защищенности средства вычислительной техники. Всего в руководящих документах сформулирован 21 показатель.

Подобным образом построена система оценки защищенности автоматизированных информационных систем. По защищенности процессов обработки информации все автоматизированные системы делятся на три группы.

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

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

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

·     подсистемы управления доступом;

·     подсистемы регистрации и учета;

·     криптографической подсистемы;

·     подсистемы обеспечения целостности.

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

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

В 1990 г. представителями государственных организаций США, Канады, Великобритании и ряда других стран были развернуты работы по созданию международного стандарта в области оценки безопасности информационных технологий. Работа по созданию нового стандарта координировалась Международной организации по стандартизации (ISO) и была направлена в первую очередь на унификацию (гармонизацию) национальных стандартов в области оценки безопасности и повышение уровня доверия к оценке безопасности информационных технологий.

Официальный текст международного стандарта ISO/IEC 15408 был издан 1 декабря 1999 г. Принятие этого стандарта, известного также как «Общие критерии», отразило изменения, происходящие в идеологии подхода к построению безопасных информационных технологий, в частности, защищенных информационных систем и их программного ядра — СУБД. В отличие от «Оранжевой книги» и руководящих документов Гостехкомиссии в новом стандарте отсутствует фиксированный набор классов защищенности. Основная идея «Общих критериев» состоит в разделении всех требований безопасности на две категории: функциональные, обеспечивающие безопасность информационных технологий, и требования гарантии оценки, оценивающие правильности и эффективность реализации функциональных требований.

В 2002 г. на основе аутентичного текста ISO/IEC 15408 был принят российский стандарт ГОСТ Р ИСО/МЭК 15408-2002 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий».

Близкий подход к анализу защищенности ИС был предложен в британском стандарте BS 7799 «Практические правила управления информационной безопасностью», принятом в 1995 г. Содержательное существо стандарта состоит в обобщении опыта обеспечения информационной безопасности ИС различного назначения. Стандарт BS 7799 послужил основой для разработки стандарта ISO 17799, который был принят в конце 2000 г.

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

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

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

Вопрос 2. Критерии качества баз данных.

Современные базы данных являются одними из массовых специфических объектов в сфере информатизации, для которых в ряде областей необходимо особенно высокое качество и квалифицированное системное проектирование.

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

·     программные средства системы управления базой данных (СУБД), независимые от сферы их применения, структуры и смыслового содержания накапливаемых и обрабатываемых данных;

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

Первым компонентом для системного анализа и требований к качеству является комплекс программ СУБД. Практически весь набор характеристик и атрибутов качества программных систем, изложенный в стандарте ISO 9126, в той или иной степени может использоваться при формировании требований к качеству СУБД. Особенности состоят в адаптации и изменении акцентов при выборе и упорядочении этих показателей. Во всех случаях важнейшими характеристиками качества СУБД являются требования к функциональной пригодности для процессов формирования и изменения информационного наполнения БД администраторами, а также доступа к данным и представления результатов пользователям БД. Качество интерфейса специалистов с БД, обеспечиваемого средствами СУБД, определяется, в значительной степени, субъективно, однако имеется ряд характеристик, которые можно оценивать достаточно корректно.

В зависимости от конкретной проблемно-ориентированной области применения СУБД, приоритет при системном анализе требований к качеству может отдаваться различным конструктивным характеристикам: либо надежности и защищенности применения (финансовая сфера), либо удобству использования малоквалифицированными пользователями (социальная сфера), либо эффективности использования ресурсов (сфера материально-технического снабжения). Однако практически во всех случаях сохраняется некоторая роль ряда других конструктивных показателей качества. Для каждого из них необходимо анализировать и определять его приоритет для конкретной сферы применения, меры и шкалы необходимых и допустимых характеристик качества.

Вторым компонентом БД является собственно накапливаемая и обрабатываемая информация. В системах баз данных доминирующее значение приобретают сами данные, их хранение и технология обработки.

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

Характеристики качества систем баз данных можно разделить на функциональные и конструктивные.

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

·     полнотой накопленных описаний объектов — относительным числом объектов или документов, имеющихся в БД, к общему числу объектов по данной тематике или по отношению к числу объектов в аналогичных БД того же назначения;

·     идентичностью данных — относительным числом описаний объектов, не содержащих дефекты и ошибки, к общему числу документов об объектах в систем баз данных;

·     актуальностью данных — относительным числом устаревших данных об объектах в ИБД к общему числу накопленных и обрабатываемых данных.

К конструктивным характеристикам качества информации систем баз данных в целом можно отнести практически все показатели качества программных систем, представленных в стандарте ISO 9126.

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

Особо выделяются характеристики достоверности данных и защищенности информации.

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

Важными показателями качества баз данных также являются объемно-временные характеристики обрабатываемых данных:

·     объем базы данных — относительное число записей описаний объектов или документов в базе данных, доступных для хранения и обработки, по сравнению с полным числом реальных объектов во внешней среде;

·     оперативность — степень соответствия динамики изменения описаний данных в процессе сбора и обработки состояниям реальных объектов или величина допустимого запаздывания между появлением или изменением характеристик реального объекта относительно его отражения в базе данных;

·     глубина ретроспективы — максимальный интервал времени от даты выпуска и/или записи в базу данных самого раннего документа до настоящего времени;

·     динамичность — относительное число изменяемых описаний объектов к общему числу записей в БД за некоторый интервал времени, определяемый периодичностью издания версий БД.

Отдельно отметим такую характеристику как защищенность информации БД, которая реализуется, в основном, программными средствами СУБД, однако в сочетании с поддерживающими их средствами организации и защиты данных. Цели, назначение и функции защиты тесно связаны с особенностями функциональной пригодности каждой ИБД. При системном проектировании свойства защищать информацию баз данных от негативных воздействий описываются обычно составом и номенклатурой методов и средств, используемых для защиты от внешних и внутренних угроз. Косвенным показателем ее качества может служить относительная доля вычислительных ресурсов, используемых непосредственно средствами защиты информации БД.

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

Вопрос 3. Сущность понятия безопасности баз данных.

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

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

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

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

Некоторые сферы экономической деятельности, например электронный бизнес, характеризуются высокой динамикой. Достаточно часто обновляется программное обеспечение, в том числе и программное обеспечение ИС, идет непрерывный поиск и внедрение новых аппаратных средств и методов взаимодействия с бизнес-партнерами и конечными пользователями, например, платежные системы ориентированы на мобильные коммуникаторы. В этом случае возможен несколько иной подход к определению безопасности.

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

Уверенность в безопасности ИС может быть достигнута в результате согласованных действий, предпринимаемых в процессе разработки, оценки и эксплуатации объекта оценки. Функциональное назначение оценки безопасности ИС —получение определенной степени уверенности в том, насколько система удовлетворяет предъявляемым к ним требованиям. Результаты оценки должны помочь потребителю установить, достаточен ли уровень безопасности системы для предполагаемых применений этой системы и являются ли приемлемыми остаточные риски.

Вопрос 4. Основные подходы к методам построения защищенных информационных систем.

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

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

·     разработка и применение строгих математических моделей, позволяющих аналитически или на ЭВМ получить надлежащие оценки;

·     критериальный подход к оценке надежности автоматизированных систем на всех этапах жизненного цикла.

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

На каждом из упомянутых подходов в течение последних 15-20 лет получено много интересных и важных для практической деятельности по построению информационных систем результатов. Однако на настоящее время имеющиеся теоретические достижения не позволяют с надлежащим уровнем точности дать оценки надежности методической и инструментальной базы обеспечения безопасности информации практически значимых автоматизированных систем.

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

Не меньшую значимость имеет задача развития критериального подхода к оценке надежности автоматизированных систем на всех этапах жизненного цикла. Действующие на сегодня в России руководящие документы Гостехкомиссии при Президенте РФ по вопросам защиты информации в автоматизированных системах выпущены в 1991 г. 11, 8/. Они во многом устарели и не соответствуют современному уровню доказательной базы надежности инструментальных средств, основанной на критериальном подходе. С другой стороны, реализация более перспективных в этом отношении «Общих критериев» (ISO-15408) в России сопряжена с целым рядом проблем и трудностей не только законодательного и административного уровней их реализации, но и во многом — программно-технического.

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

·     ядро операционной системы;

·     сервер баз данных;

·     сервер приложений или прикладная система.

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

Модели математически строгого описания правил разграничения доступа реализуются, как правило, на основе подхода «Субъект-объект». К таким наиболее часто употребляемым и реализуемым в операционных и автоматизированных информационных системах относятся дискреционная и мандатная модели. Широко распространено мнение, что за счет их развития, разумной комбинации, использования гибких схем и более тонких механизмов разграничения доступа удается получить достаточно хорошие результаты при приемлемых затратах на всех этапах жизненного цикла систем.

Традиционные подходы в совершенствовании уже существующих и разработке новых моделей разграничения доступа связаны с их описанием на основе отношений «субъект-объект». В последние годы, с активным внедрением в практику объектно-ориентированного программирования, появились вполне обоснованные (и адекватные потребностям) подходы к описанию моделей разграничения доступа на основе новых методов. Разработка формальных моделей на новых подходах, их реализация для конкретных информационных систем, функциональных или структурных сервисов представляется важной и перспективной задачей.

Есть два принципиально отличных пути решения задачи построения защищенной автоматизированной системы.

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

Второй путь основан на подходах, направленных на устранение тех же проблем в системе, однако путем анализа и выявлением уязвимых мест, исправления недостатков модернизации уже существующих традиционных систем. Очевидно, что второе направление лучше реализуется для систем с открытыми кодами. К таким системам относятся в первую очередь операционные системы Linux и Free BSD. В работе над данными системами в режиме открытых проектов большими исследовательскими коллективами, распределенными по всему миру, получены важные результаты.

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

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

Традиционно используются два основных метода тестирования:

·     тестирование по методу «черного ящика»;

·     тестирование по методу «белого ящика».

Тестирование по методу «черного ящика» предполагает отсутствие у тестирующей стороны каких-либо специальных знаний о конфигурации и внутренней структуре объекта испытаний. При этом против объекта испытаний реализуются все известные типы атак и проверяется устойчивость системы защиты в отношении этих атак. Используемые методы тестирования эмулируютдействия потенциальных злоумышленников, пытающихся взломать систему защиты. Основным средством тестирования в данном случае являются сетевые сканеры, располагающие базами данных известных уязвимостей.

Метод «белого ящика» предполагает составление программы тестирования на основании знаний о структуре и конфигурации объекта испытаний. В ходе тестирования проверяются наличие и работоспособность механизмов безопасности, соответствие состава и конфигурации системы защиты требованиям безопасности и существующим рискам.

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

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

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

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

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

·     Документально оформить проектные решения с обоснованием рациональности выбора средств защиты для рассматриваемой автоматизированной информационной системы.

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

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

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

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

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

При описании архитектур обработки данных используются разнообразные термины, поэтому дадим определения основных понятий, используемых в книге. Следующие определения относятся к архитектуре «клиент-сервер».

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

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

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

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

Основным назначением архитектуры «клиент-сервер» является обеспечение прикладным программам клиента доступа к данным, которыми управляет сервер. Архитектура «клиент-сервер» позволяет нескольким клиентам совместно эффективно использовать один сервер.

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

В этом состоит ключевое отличие рассматриваемого метода от метода обработки запросов, характерного для персональных СУБД, установленных в сети. При получении запроса файл, в котором находятся данные, полностью пересылается по сети в компьютер клиента, где и происходит отбор данных по критерию пользователя. В большинстве запросов отбирается менее 1% данных, а трафик в сети оказывается неоправданно высоким. Сеть перегружается пересылкой ненужных данных. Если пользователей несколько, то сеть быстро приходит в состояние фатальной перегрузки.

Рассмотрим преимущества и недостатки архитектуры «клиент- сервер». Путем распределения вычислений достигается гибкость и масштабируемость системы: во-первых, каждый компьютер в системе можно выбирать так, чтобы он лучше всего подходил к требованиям каждого компонента. Например, для сервера можно выбрать мощный многопроцессорный компьютер с большим объемом памяти под управлением защищенной многопользовательской операционной системы UNIX-класса. Такой сервер будет выдерживать требуемый уровень нагрузки. Для рабочих станций, на которых будет развернуто клиентское программное обеспечение, требования совсем другие. Как правило, это так называемый офисный компьютер. Во-вторых, такая система обладает хорошей адаптируемостью и гибкостью — в силу модульности легко можно заменить переставший удовлетворять требованиям компонент или даже целиком какую-либо составляющую. Например, заменить весь парк устаревших рабочих станций. В-третьих, легко масштабировать систему, добавив в нее новые рабочие станции или нарастив вычислительные мощности на сервере.

Но наряду с такими ощутимыми преимуществами имеются и недостатки. Частые обращения клиента к серверу снижают производительность работы сети, приходится решать вопросы безопасной многопользовательской работы с данными, так как приложения и данные распределены между различными клиентами. Распределенный характер построения системы обусловливает сложность ее настройки и сопровождения. Чем сложнее структура системы, построенной по технологии «клиент-сервер», тем выше вероятность отказа любого из ее компонентов. В очень сложную проблему может превратиться процесс смены клиентского программного обеспечения, особенно если в системе работает большое число рабочих станций.

Изложенные выше недостатки архитектуры «клиент-сервер» стимулировали поиск новых архитектур обработки данных, одним из результатов которого стала многозвенная архитектура, свободная от некоторых недостатков своей предшественницы. Интернет/интранет— магистральное направление развития информационных технологий и многозвенная архитектура, специально предназначенная для работы в этой среде.

Была предложена идея распределения нагрузки между тремя и более различными компьютерами. Клиент по-прежнему выполняет функции предоставления интерфейса пользователя и, возможно, некоторые не очень сложные и ресурсоемкие операции обработки данных, другие этапы функционирования системы теперь распределены между несколькими компьютерами — серверами баз данных и серверами приложений. Серверы баз данных управляют данными, а серверы приложений выполняют все вычисления, связанные с реализацией безнес-логики приложениями.

Аналогично технологии «клиент-сервер» дадим ряд определений, существенных для описания многозвенной архитектуры. В ее состав входит универсальный клиент — определим его как процесс, посылающий запрос на обслуживание и способный осуществить отображение его результатов на основе некоторого универсального протокола выдачи информации. Основное отличие универсальных клиентов от обычных — способность предоставления пользователю интерфейса для решения любых задач, низкая стоимость внедрения, администрирования и поддержки. Как правило, это браузер, программа просмотра сценариев на каком-либо языке разметки. Браузер может поддерживать с помощью run-time расширений и другие форматы файлов. Приложения, используемые в качестве таких расширений, хранят все свои файлы на клиенте. Когда браузер встречает вызов такого расширения, он загружает соответствующие исполнимые файлы и запускает приложение.

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

·     относительно низкие затраты на внедрение и эксплуатацию;

·     высокая способность к интеграции существующих информационных ресурсов;

·     прикладные программные средства доступны с любого клиентского рабочего места;

·     минимальный состав программно-технических средств на клиентском рабочем месте.

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

·     сервер баз данных Oracle;

·     универсальный сервер приложений Oracle Application Server;

·     набор драйверов в стандарте JDBC, специально оптимизированных для доступа из Java-программ к Oracle, а также SQLJ — поддержка операторов SQL, встроенных в программы Java.

Этот набор не является жестко заданным. При проектировании конкретной системы следует учитывать все особенности ее функционирования и, например, использование web-сервера Apache и языка Perl может оказаться эффективнее применения web-расширений языка PL/SQL для Oracle Application Server. Кроме того, в интерпретации Oracle многозвенная архитектура имеет еще одну особенность. Она изначально задумана как расширяемая. Основной единицей расширения является картридж — клиентский, прикладной или картридж данных, предусмотрены интерфейсы для их взаимодействия с другими компонентами информационной системы. Картриджи могут разрабатываться как производителями программного обеспечения, так и пользователями с учетом их возможного повторного использования. Существует три типа картриджей.

Картриджи базы данных — функционируют внутри сервера базы данных. Oracle предоставляет свои картриджи для решения конкретных задач, например для обработки неструктурированных текстов. Также разработчики могут реализовать на каком-либо языке программирования свои картриджи. Например, для устранения недостатков работы с текстами на русском языке разработан картридж Russian Context Optimizer (RCO).

Картриджи серверов пртожений — средства для получения и обработки запросов от клиентов. Примером может служить разработанное корпорацией Oracle средство Oracle Web Application Server.

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

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

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

Вопрос 6. Структура свойства информационной безопасности баз данных.

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

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

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

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

·     конфиденциальность: обеспечение пользователям доступа только к тем данным, для которых пользователь имеет явное или неявное разрешение на доступ;

·     целостность: обеспечение защиты от преднамеренного или непреднамеренного изменения информации или процессов ее обработки;

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

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

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

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

Задача обеспечения доступности информации предусматривает систему мер по поддержке всем легитимным пользователям доступа к ресурсам системы в соответствии с принятой технологией (например, круглосуточно). Причиной отказа в доступе может быть перегрузка системы, вызванная потоком «информационного шума» (спам, искусственно формируемый поток бессмысленных запросов), перегрузка системы, вызванная объективными причинами (резкое увеличение потока запросов в связи с некоторыми событиями), действия, направленные на остановку критически важных процессов (например, компонент сервера баз данных, прослушивающего процесса). Структура свойства информационной безопасности представлена на рис. 1.

Рис. 1. Структура свойства информационной безопасности

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

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

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

Система управления базами данных является сложным, многокомпонентным, распределенным программным комплексом. Архитектура построения СУБД, логика представления информации предметной области базами данных в процессе длительной эволюции также стали достаточно сложными, а иногда и запутанными. С каждой новой версией СУБД увеличивается число управляемых параметров системы, в том числе и параметров, определяющих характеристики информационной безопасности. Естественным методом борьбы со сложностью изучаемой системы является ее структуризация.

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

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

Тема 2. Угрозы информационной безопасности баз данных

Введение.

При проектировании информационных систем различного назначения для хранения больших и сверхбольших объемов информации проектировщики обычно делают выбор в пользу реляционной СУБД. Такова сложившаяся практика. На последующих стадиях проектирования и разработки обеспечение безопасности базы данных (ядра всей системы) обычно сводится к выделению классов пользователей, их информационных потребностей и привилегий (эти и еще несколько этапов входят в формирование политики безопасности), проектированию системы разграничения доступа.

Далее для назначения/отмены привилегий используется язык SQL, включающий операторы GRANT, REVOKE и т. п. Большинство современных реляционных СУБД поддерживает дискреционную (DAC) и мандатную (MAC) модели разграничения доступа, а также дополнительные средства обеспечения безопасности.

На всех стадиях жизненного цикла информационной системы, построенной на основе реляционной СУБД, возможны реализации большого числа угроз различных классов. Эти возможности следуют как из свойств самой реляционной модели данных, так и из особенностей реализации СУБД различными производителями и используемой модели разграничения доступа. Защита информации в реляционных базах данных имеет специфику, заключающуюся в том, что семантика обрабатываемых данных дает большие возможности по реализации различных угроз применительно к базе данных, чем, скажем, к файловой системе.

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

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

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

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

Первый шаг в анализе угроз — их идентификация. Рассматриваемые виды угроз следует выбирать исходя из соображений здравого смысла (исключив, например, землетрясения, однако не забывая о возможности захвата организации террористами), но в пределах выбранных видов провести максимально подробный анализ.

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

Вопрос 1. Источники угроз информации баз данных.

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

Сформулируем перечень внешних и внутренних угроз информационной безопасности баз данных.

Внешними дестабилизирующими факторами, создающими угрозы безопасности функционированию систем баз данных и СУБД, являются:

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

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

·     сбои и отказы в аппаратуре вычислительных средств;

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

·     изменения состава и конфигурации комплекса взаимодействующей аппаратуры системы за пределы, проверенные при тестировании или сертификации системы. Внутренними источниками угроз безопасности баз данных и СУБД являются:

·     системные ошибки при постановке целей и задач проектирования автоматизированных информационных систем и их компонент, допущенные при формулировке требований к функциям и характеристикам средств обеспечения безопасности системы;

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

·     ошибки проектирования при разработке и реализации алгоритмов обеспечения безопасности аппаратуры, программных средств и баз данных;

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

·     недостаточная эффективность используемых методов и средств обеспечения информационной безопасности в штатных или особых условиях эксплуатации системы.

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

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

Вопрос 2. Классификация угроз информационной безопасности баз данных.

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

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

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

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

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

Классификация по цели реализации угрозы:

1.  Нарушение конфиденциальности информации, т. е. использование информации, хранящейся в системе, лицами или процессами, которые не были определены владельцами информации.

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

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

Классификация по природе возникновения угрозы:

1.  Естественные угрозы—угрозы, вызванные воздействием на систему баз данных и ее компоненты объективных физических процессов или стихийно развивающихся природных явлений.

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

Классификация по локализации источника угрозы представляется следующим образом:

1.  Угрозы, непосредственным источником которых является человек:

·     разглашение, передача или утрата атрибутов разграничения доступа (паролей, ключей шифрования, электронных замков и т. п.) легальными пользователями системы;

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

·     копирование конфиденциальных данных легальным пользователем системы с целью неправомерного использования (продажа, шантаж и т. п.);

·     взлом системы защиты с целью выполнения деструктивных действий лицом, не являющимся законным пользователем системы;

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

2.  Угрозы, непосредственным источником которых являются штатные программно-аппаратные средства информационной системы:

·     неквалифицированное использование или ошибочный ввод параметров программ, способных привести к полной или частичной потере работоспособности системы (аварийное завершение системных процессов, нецелевое расходование вычислительных ресурсов и т. п.);

·     неквалифицированное использование или ошибочный ввод параметров программ, способных привести к необратимым изменениям в системе (инициализация баз данных, форматирование или реструктуризацию носителей информации, удаление данных и т. п.);

·     отказы и сбои в работе операционной системы, СУБД и прикладных программ.

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

·     нелегальное внедрение и использование программ, не являющихся необходимыми для выполнения нарушителем своих служебных обязанностей;

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

·     заражение компьютера вирусами с деструктивными функциями;

·     работа генераторов шума и подобных источников электромагнитного излучения.

4.  Угрозы, непосредственным источником которых является среда обитания:

·     внезапное и длительное отключение систем электропитания;

·     техногенные и природные катастрофы;

·     всплески природных электромагнитных излучений. Классификация по расположению источника угроз. Угрозы, источник которых расположен вне контролируемой зоны места расположения автоматизированной информационной системы:

·     нарушение нормальной работы или разрушение систем жизнеобеспечения зданий, в которых расположены технические средства и обслуживающий персонал систему — блокирование физического доступа на объект размещения автоматизированной системы обслуживающего персонала или пользователей;

·     нарушение нормальной работы или разрушение внешних каналов связи (проводные линии, радиоканалы, оптоволокно).

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

·     нарушение нормальной работы или разрушение систем электропитания и водоснабжения помещений, в которых расположены технические средства, обеспечивающие работу автоматизированной системы;

·     физическое разрушение линий связи или аппаратуры, обеспечивающей работу информационной системы;

·     считывание конфиденциальной информации из аппаратных средств телекоммуникационной или вычислительной техники с использованием перехвата электромагнитных излучений;

·     выведения из рабочего состояния обслуживающего персонала (организация саботажа, применение отравляющих веществ, психотропных средств и т. п.).

6.  Угрозы, источник которых имеет доступ к терминальным устройствам автоматизированной информационной системы:

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

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

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

·     получение конфиденциальной информации из распечаток результатов выполнения запросов и иных выводимых системой данных.

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

·     физическое разрушение элементов серверов и коммутационной аппаратуры;

·     выключение электропитания серверов и коммутационной аппаратуры;

·     остановка серверных и иных критически важных для функционирования автоматизированной системы процессов;

·     уничтожение или модификация критически важных для функционирования автоматизированной системы файлов операционной системы;

·     нарушение штатной работы базовой операционной системы, например, за счет запуска процессов, активно расходующих ресурсы системы, критически важных для функционирования операционной системы файлов и т. п.;

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

Классификация по способу воздействия на методы и средства хранения данных информационной системы.

1.  Угрозы нарушения информационной безопасности данных, хранимых на внешних запоминающих устройствах:

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

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

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

2.  Угрозы нарушения информационной безопасности данных, хранимых в оперативной памяти серверов и клиентских компьютеров:

·     изменение информации в оперативной памяти, используемой СУБД для кэширования данных, организации хранения промежуточных результатов выполнения запросов, констант и переменных процессов обработки данных;

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

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

3.  Угрозы нарушения информационной безопасности данных, отображаемой на терминале пользователя или принтере:

·     организация имитации процесса установления взаимодействия с сервером (ложной сессии) с целью получения идентификаторов и аутентифицирующей информации пользователей;

·     изменение элементов данных, выводимых на терминал пользователя за счет перехвата потока вывода;

·     изменение элементов данных, выводимых на принтер за счет перехвата потока вывода.

4.  Классификация по характеру воздействия на информационную систему (целесообразно выделить два варианта):

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

·     пассивное воздействие, т. е. наблюдение пользователем значений каких-либо параметров СУБД или системы баз данных, а также различных побочных эффектов и косвенных признаков с целью получения конфиденциальной информации на основе анализа собранных данных.

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

·     физического;

·     технологического;

·     логического (процедурного);

·     человеческого.

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

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

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

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

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

Вопрос 3. Угрозы, специфичные для систем управления базами данных.

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

Угрозы конфиденциальности информации.

К угрозам такого типа можно отнести:

1.  Инъекция SQL. Во многих приложениях используется динамический SQL — формирование SQL-предложений кодом программы путем конкатенации строк и значений параметров. Зная структуру базы данных, злоумышленник может либо выполнить хранимую программу в запросе, либо закомментировать «легальные» фрагменты SQL-кода, внедрив, например, конструкцию UNION, запрос которой возвращает конфиденциальные данные. В последнее время даже появились специальные программы, автоматизирующие процесс реализации подобных угроз.

2.  Логический вывод на основе функциональных зависимостей. Пусть дана схема отношения: . Пусть , X, Y — подмножества из U. Говорят, что Х функционально определяет Y, если в любом отношении r со схемой  не могут содержаться два кортежа с одинаковыми значениями атрибутов из Х, с различными из Y. В этом случае имеет место функциональная зависимость, обозначаемая . Пример функциональной зависимости для схемы отношения (фамилия, имя, отчество, должность, зарплата): если должность = менеджер, то зарплата = 1200. В реальных базах данных при наличии сведений о функциональных зависимостях злоумышленник может вывести конфиденциальную информацию при наличии доступа только к части отношений, составляющих декомпозированное отношение.

3.  Логический вывод на основе ограничений целостности. Для кортежей отношений в реляционной модели данных (РМД) можно задать ограничения целостности — логические условия, которым должны удовлетворять атрибуты кортежей. Причем ограничение целостности может быть задано в виде предиката на всем множестве атрибутов кортежа. В случае попытки изменения данных в таблице, СУБД автоматически вычисляет значение этого предиката, и в зависимости от его истинности операция разрешается или отвергается. Выполняя многократные изменения данных и анализируя реакцию системы, злоумышленник может получить те сведения, к которым у него отсутствует непосредственный доступ. Также к этому виду угроз конфиденциальности относится анализ значений первичных/внешних ключей.

4.  Использование oneраmopa UPDATE для получения конфиденциальной информации. В некоторых стандартах SQL пользователь, не обладая привилегией на выполнение оператора SELECT, мог выполнить оператор UPDATE со сколь угодно сложным логическим условием. Так как после выполнения оператора UPDATE сообщается, сколько строк он обработал, фактически пользователь мог узнать, существуют ли данные, удовлетворяющие этому условию.

Рассмотрим угрозы целостности информации, специфические для систем управления базами данных.

Модификация данных в реляционных СУБД возможна с помощью SQL-операторов UPDATE, INSERT и DELETE. Потенциальная опасность возникает из-за того, что пользователь, обладающий соответствующими привилегиями, может модифицировать все записи в таблице. Ограничить множество записей, доступных для модификации, можно с помощью создания представлений с оператором CHECK, но этот (равно как и любой другой) требует предварительного осмысливания существа задачи и соответствующего проектирования схемы.

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

1.  Использование свойств первичных и внешних ключей. В первую очередь сюда относится свойство уникальности первичных ключей и наличие ссылочной целостности. В том случае, если используются натуральные, а не генерируемые системой значения первичных ключей, можно создать такую ситуацию, когда в таблицу невозможно будет вставить новые записи, так как там уже будут записи с такими же значениями первичных ключей. Если в базе данных поддерживается ссылочная целостность, можно организовать невозможность удаления родительских записей, умышленно создав подчиненные записи. Важной особенностью реализации ссылочной целостности является вопрос об индексировании внешнего ключа. В том случае, если внешний ключ не проиндексирован, то при обновлении связанных записей, например, в СУБД Oracle возможна организация взаимной блокировки (dead-lock), что приведет к сбою в транзакции.

2.  Блокировка записей при изменении. Заблокировав записи или всю таблицу, злоумышленник может на значительное время сделать ее недоступной для обновления.

3.  Загрузка системы бессмысленной работой. Простейший пример — выполнение запроса, содержащего декартово произведение двух больших отношений. Мощность декартового произведения двух отношений мощности , и  равна . То есть при выдаче злоумышленником запроса вида SELECT * FROM Tab 1, Tab 1 ORDER BY 1, где мощность отношения (количество строк в таблице Tab 1) , мощность результирующего отношения будет . Вычисление соединения (особенно, если указать в виде подсказки оптимизатору способ соединения, требующий значительных затрат процессорного времени, — сортировку слиянием или хэширование) и сортировка результирующего отношения потребуют значительных ресурсов системы и отрицательно скажутся на производительности операций других пользователей.

4.  В реляционных СУБД возможны реализации и других классических угроз, например атаки типа «троянский конь» — запуска пользователями программ, содержащих выполняющий определенные действия код, внедренный туда злоумышленником.

Практически все современные СУБД имеют встроенный процедурный язык программирования (PL/SQL, Transact SQL и т. п.). Программы на этом языке хранятся внутри базы данных и выполняются исполняющей подсистемой сервера баз данных. Наличие и широкое использование производителями прикладного программного обеспечения механизма скрытия исходных текстов хранимых программ (утилита wrap для СУБД Oracle) затрудняют его обнаружение. Также возможны многочисленные скрытые каналы, обусловленные семантикой данных и необходимостью обеспечения работы в условиях многопользовательского доступа.

На основании проведенного анализа можно сделать вывод, что в современных реализациях реляционных СУБД имеется значительное число уязвимостей, которые могут быть использованы для различных атак на информационные системы, построенные на их базе. Эта проблема отчасти может быть решена использованием специализированных программных средств анализа уязвимостей и защиты от угроз различных типов.

Вопрос 4. Объекты и субъекты моделей информационной безопасности баз данных на примере СУБД Oracle.

Неотъемлемой частью любого проекта по созданию или оценке системы информационной безопасности баз данных является разработка модели безопасности данных. Наиболее распространенной парадигмой моделей обеспечения безопасности данных является субъектно-объектная абстракция. Элементы системы делятся на два класса сущностей: активные сущности — субъекты и пассивные сущности — объекты. В автоматизированной системе, реализованной на основе СУБД промышленного уровня, прообразом всех этих сущностей являются классы однотипных объектов, создаваемых и описываемых средствами языка описания данных (DDL). Сохраняя стилевое единство с предыдущими книгами автора, будем вместо термина «классы однотипных объектов» использовать термин «объекты».

В качестве рабочего примера рассмотрим объекты СУБД Oracle. Хорошо известно, что СУБД Oracle поддерживает реляционную модель данных, поэтому естественно, что к числу основных объектов базы данных относятся таблица и представление.

Таблица (TABLE) является базовой структурой реляционной модели. Как известно, вся информация в реляционной базе данных хранится в таблицах. Полное имя таблицы в базе данных состоит из имени схемы и собственно имени таблицы. Таблицы состоят из множества поименованных столбцов или атрибутов. Множество допустимых значений атрибута называют доменом значений или просто доменом. Множество допустимых значений столбца также может быть уточнено с помощью статических ограничений целостности. Таблицы могут быть связаны между собой отношениями ссылочной целостности. Таблица может быть пустой или состоять из одной или более строк значений атрибутов. Строки значений атрибутов таблицы называются также кортежами. Для однозначной идентификации строки в таблице служит идентификатор (ROWID) —указатель, имеющий специальный формат. В Огас1е8 появились вложенные таблицы (NESTED TABLES), которые позволяют объявить таблицу как тип значения столбца родительской таблицы. Подробно они рассмотрены в разделе «Объектные расширения в Огас1е8». Для повышения скорости доступа к данным таблица может быть индексно организована (INDEX-ORGANIZED TABLE). Физическое пространство для хранения данных таблицы выделяется частями, называемыми экстентами. Размеры начального и дополнительных экстентов определяются при создании таблицы.

Представление (VIEW) — это поименованная, динамически поддерживаемая сервером выборка из одной или нескольких таблиц. По сути, представление — это производное множество строк, которое является результатом выполнения некоторого запроса к базовым таблицам. В словаре данных хранится только определение представления, и когда в операторе SQL встречается название представления, Oracle обращается к словарю за определением и подставляет его в исходный запрос. Запрос, определяющий выборку, ограничивает видимые пользователем данные. Представления позволяют упростить сложные запросы и сделать более понятными их логику. Используя представления, администратор безопасности ограничивает доступную пользователю часть базы данных только теми данными, которые реально необходимы для выполнения его работы. Представления также можно использовать для поддержки приложений при изменении структуры таблицы. Например, при добавлении нового столбца в таблицу создать представление, его не включающее.

Синоним (SYNONYM)— это альтернативное имя или псевдоним объекта Oracle, который позволяет пользователям базы данных иметь доступ к данному объекту. Синоним может быть частным и общим. Общий (PUBLIC) синоним позволяет всем пользователям базы данных обращаться к соответствующему объекту по альтернативному имени. Характерным применением общих синонимов является сокрытие информации о схеме, в которой расположен объект. Наличие синонима позволяет обращаться к объекту по имени, которое является абсолютным в масштабе базы данных. Реальная привязка объекта к некоторой схеме при этом скрыта от пользователя или приложения.

Для управления эффективностью доступа к данным Oracle поддерживает следующие объекты: индекс, табличная область, кластер и хэшированный кластер.

Индекс (INDEX) — это объект базы данных, предназначенный для повышения производительности выборки данных. Индекс создается для столбцов таблицы и обеспечивает более быстрый доступ к данным за счет хранения указателей (ROWID) на месторасположение строк. При обращении к индексированному столбцу сервер по предъявляемому значению находит в индексе указатели на эти строки, а потом непосредственно обращается к ним. Если все требуемые значения столбцов имеются в индексе, обращение к таблице не происходит вовсе. Имеется несколько типов индексов — В*Тгее (двоичное дерево, каждый узел которого содержит указатель на следующий и предыдущий), масочный индекс, индекс с реверсированным ключом, кластерный индекс. Подробнее о них рассказывается в разделе «Методы повышения производительности».

Кластер (CLUSTER) — объект, задающий способ хранения данных нескольких таблиц, содержащих информацию, обычно обрабатываемую совместно, например значения столбцов таблиц, часто участвующих в эквисоединениях. Строки таких таблиц, имеющие одинаковое значение в кластеризованных столбцах, хранятся в базе данных специальным образом: на логическом уровне — в нормализованном виде, а на физическом — в ненормализованном. Кластеризация столбцов таблиц позволяет уменьшить время выполнения выборки.

Хэшированный кластер (HASH CLUSTER) — объект, задающий способ организации таблиц, базирующийся на результатах хэширования их первичных ключей. Для получения данных из такого кластера запрашиваемое значение ключа обрабатывается хэш-функцией, полученное значение определяет, в каком блоке кластера хранятся данные.

Табличная область (TABLESPACE) — именованная часть базы данных, используемая для распределения памяти для таблиц, индексов и других объектов. В табличную область входит один или несколько файлов. Это предоставляет возможность гибко настроить хранение данных в зависимости от порядка и интенсивности их использования. Например, можно отвести одну табличную область для таблиц, а другую — для индексов. В каждой базе данных есть табличная область SYSTEM, с которой связаны все системные объекты, например таблицы словаря данных. Доступность табличных областей может устанавливаться переводом в автономный или оперативный режим.

Для эффективного управления разграничением доступа к данным система Oracle поддерживает объект роль.

Роль (ROLE) — именованная совокупность привилегий, которые могут быть предоставлены пользователям или другим ролям. Oracle поддерживает несколько предопределенных ролей. Для систем, в которых количество пользователей и приложений велико, роли могут заметно облегчить разграничение доступа, например возможно динамически назначать роли для изменения набора привилегий пользователя при работе с различными при- ложениями. Также роли можно защищать паролем.

Специфичными для распределенных систем являются объекты Oracle: снимок и связь базы данных.

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

Связь базы данных (DATABASE LINK) — это объект базы данных, который позволяет обратиться к объектам удаленной базы данных. Имя связи базы данных можно рассматривать как ссылку на параметры механизма доступа к удаленной базе данных (имя узла, протокол и т. п.).

Сегмент отката (ROLBACK SEGMENT) — объект базы данных, предназначенный для обеспечения многопользовательской работы. В сегментах отката находятся обновляемые и удаляемые данные в пределах одной транзакции. При отмене изменений старая версия данных всегда доступна, так как находится в сегментах отката. В начале транзакции и в каждой контрольной точке текущие значения данных копируются в сегмент отката. Кроме того, сегменты отката используются при других операциях сервера. Размер и доступность сегментов отката в сильной степени влияют на производительность сервера баз данных и их настройка должна быть выполнена самым тщательным образом.

Типы (TYPE) и коллекции типов — новые виды объектов базы данных для Огас1е8, предназначенные для реализации объектных расширений.

Каталог (DIRECTORY) — объект, предназначенный для организации файлового ввода-вывода и работы с большими двоичными объектами.

Профиль (PROFILE) — объект, ограничивающий использование пользователем системных ресурсов, например процессорного времени или числа операций ввода-вывода.

Библиотека (LIBRARY) — объект базы данных, предназначенный для взаимодействия программ PL/SQL с модулями, написанными на других языках программирования.

К числу основных субъектов (активных сущностей) Oracle относятся: пользователь, процедура, функция, пакет и триггер.

Пользователь (USER) — сущность, обладающая возможностью создавать и использовать другие объекты Oracle, а также запрашивать выполнение функций сервера. К числу таких функций относится организация сессии, изменение состояния базы данных и др.

Следует отметить, что в некоторых других системах управления базами данных, например IBM DB2, объект базы данных «пользователь» отсутствует.

С пользователем Oracle связана схема (SCHEMA), которая является логическим набором объектов базы данных, таких, как таблицы, последовательности, хранимые программы, при- надлежащие этому пользователю. Схема имеет только одного пользователя-владельца, обладающего полным набором привилегий на создание, модификацию и удаление этих объектов. При создании пользователем первого объекта неявно создается соответствующая схема. При создании им других объектов они по умолчанию становятся частью этой схемы. Для просмотра объектов схемы текущего пользователя можно использовать представление словаря данных USEROBJECTS.

При массовом выполнении DDL-предложений можно создать несколько объектов и назначить для них привилегии за одну операцию, используя оператор CREATE SCHEMA. Оператор CREATE SCHEMA применяется тогда, когда требуется гарантировать успешное создание всех объектов и назначение привилегий за одну операцию. Если при создании объектов произошла ошибка, происходит возвращение к исходному состоянию.

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

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

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

Процедура (PROCEDURE) — это поименованный, структурированный набор конструкций языка PL/SQL, предназначенный для решения конкретной задачи.

Функция (FUNCTION) —это поименованный, структурированный набор конструкций языка PL/SQL, предназначенный для решения конкретной задачи и возвращающий значение.

Пакет (PACKAGE) —это поименованный, структурированный набор переменных, процедур и функций и других объектов, связанных функциональным замыслом. Пакет состоит из двух самостоятельных частей: заголовка и тела. Заголовок содержит описание переменных, констант, типов, процедур, функций и других конструкций языка PL/SQL. Тело пакета содержит реализацию алгоритмов процедур и функций и хранится отдельно. Например, Oracle предоставляет стандартный пакет UTL_FILE, который содержит процедуры и функции, предназначенные для организации файлового ввода-вывода из программ на языке PL/SQL.

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

Контрольные вопросы:

1.       Сформулируйте понятие угрозы информационной системе.

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

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

4.       Сформулируйте понятие принципа равнопрочности системы защиты.

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

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

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

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

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

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

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

12.  Опишите сущность угрозы, связанной с инъекцией SQL.

13.  В чем состоит существо логического вывода конфиденциальных значений атрибутов на основе функциональных зависимостей?

14.  В чем состоит существо логического вывода конфиденциальных значений атрибутов на основе ограничений целостности?

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

16.  Перечислите и дайте краткую характеристику основных объектов СУБД Oracle, которые могут использоваться в качестве прообразов для построения субъектно-объектных моделей защиты информации.

Приложение 1.

Существующие угрозы базам данных

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

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

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

Хищение информации из баз данных: местные особенности России или отражение мировых тенденций?

Долгое время защита баз данных ассоциировалась с защитой локальной сети предприятия от внешних атак хакеров, борьбой с вирусами и т. п. Последние аналитические отчеты консалтинговых компаний выявили другие, более важные направления защиты информационных ресурсов компаний. Исследования убедительно показали, что от утечки информации со стороны персонала и злонамеренных действий «всесильных» администраторов баз данных не спасают ни межсетевые экраны, ни VPN, ни даже «навороченные» системы обнаружения атак и анализа защищенности. Неавторизованный доступ к данным и кража конфиденциальной информации являются главными составляющими потерь предприятий после ущерба, наносимого вирусами (рис. 2).

Рис. 2

Один из основных выводов отчета CSI/FBI - значительно возросший ущерб от такой угрозы, как кража конфиденциальных данных. Каждая американская компания в среднем потеряла 355,5 тыс. долл. только из-за утечек конфиденциальных данных за прошедшие 12 месяцев. Средний размер потерь от действий инсайдеров составил 300 тыс. долл. (максимальный -1,5 млн долл.). Решение вопросов персонифицированного доступа к конфиденциальным данным позволяет выявлять злоумышленника с помощью информации, неопровержимо доказывающей его вину. Это, в свою очередь, невозможно без применения самых современных способов аутентификации и управления доступом.

Можно ли остановить хищение информации из баз данных?

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

Итак, имеются следующие исходные данные:

·     многие не догадываются о том, что их базы данных крадут;

·     кража и причиненный ущерб имеют латентный характер;

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

Исследования Ernst&Young по проблемам внутренних угроз свидетельствуют: около 20% сотрудников предприятий уверены, что конфиденциальная информация «уходит на сторону» по вине их коллег, при этом руководители большинства компаний практически бездействуют. Причины такого положения следующие:

·     Высокая латентность подобных преступлений (понесенные потери обнаруживаются спустя некоторое время) и достаточно редко раскрываются. Эксперты называют следующие цифры по сокрытию: США - 80%, Великобритания - до 85%, Германия - 75%, Россия - более 90%. Стремление руководства «не выносить сор из избы» усугубляет ситуацию.

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

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

Практически 100% опрошенных подтвердили использование в корпоративных сетях антивирусного ПО, 71% - антиспамовых систем, но о защите от внутренних угроз не упомянул никто. Российская действительность еще тревожнее. В опубликованной в феврале 2005 г. информации на сайте www.infowatch.ru приведены данные опроса представителей 387 государственных и коммерческих структур (рис. 3).

Рис. 3

Вот основные выводы данного исследования:

·     62% респондентов считают, что действия инсайдеров - самая большая угроза для российских организаций.

·     98% признали нарушение конфиденциальности информации самой большой внутренней ИТ-угрозой.

·     99,4% допускают возможность наличия незарегистрированных инцидентов внутренней ИБ.

·     87% считают технические средства эффективным способом защиты. Однако всего 1% респондентов используют их, а 68% никаких действий не предпринимают.

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

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

·     Возможность защиты данных от системных администраторов также малоизвестна, руководители предпочитают считать их наиболее лояльными сотрудниками.

·     Бюджеты на информационную безопасность, как правило, невелики. Это не позволяет решить проблему комплексно (введение штатных единиц, отвечающих за информационную безопасность, формирование и реализация политик безопасности, обучение персонала, установка систем защиты и т. д.).

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

Технические способы защиты

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

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

Предположим, что проблема хранения ключей решена, и легальный пользователь решил скопировать защищенную информацию, а это, отметим, он может сделать совершенно свободно. Сопоставимый или даже более значительный ущерб может нанести передача ключа шифрования заинтересованному лицу. А если в качестве злоумышленника выступает администратор БД... Напрашивается вывод, что шифрование не решает всех проблем. Чтобы снизить риски от внутренних угроз с помощью технических средств защиты, следует применять:

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

·     шифрование трафика между клиентской рабочей станцией и сервером БД, что предотвратит попытки кражи информации на сетевом уровне;

·     криптографическое преобразование тех данных, которые необходимо защитить. Это значительно снизит риск потери информации;

·     хранение аутентификационной информации и ключей шифрования на персонализированном съемном носителе, например, на смарт-карте или USB-ключе. Это позволит устранить проблему «забытых паролей» и повысить персональную ответственность сотрудника;

·     аудит критических (в плане безопасности) действий пользователей (желательно, нештатными средствами аудита БД). Сочетание аудита и строгой персонификации - достаточно веский аргумент в пользу отказа от противоправных действий для потенциальных нарушителей.

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

Лучшее решение — «прозрачное» приложение

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

Рассмотрим это решение подробнее. Из всего разнообразия методов аутентификации, предоставляемых СУБД Oracle (имя/пароль, RADIUS, Kerberos, SSL), в 99% случаев используется аутентификация по имени пользователя и паролю. Безусловно, это самый простой метод. Однако его удобство и, что более важно, безопасность оставляют желать лучшего. Наиболее надежным методом сегодня считается аутентификация по сертификату Х.509, которую поддерживает Oracle. Сертификаты пользователей и закрытые ключи могут храниться либо в файлах стандартного формата PKCS#12, размещенных на отчуждаемых носителях, либо в реестре Windows на рабочих станциях, при этом они защищены паролем. Однако парольная защита порождает проблемы безопасности - ключевые контейнеры могут быть скопированы и впоследствии «взломаны» методом простого перебора паролей. Определенные неудобства вызывает и привязка ключевого контейнера к конкретной рабочей станции.

Рассматриваемое решение снимает обе проблемы: сертификаты установлены непосредственно в чиповой (интеллектуальной) смарт-карте; секретный ключ находится в защищенной памяти и никогда оттуда не извлекается; сертификаты «мобильны» - работать с приложениями Oracle можно с любой рабочей станции и от имени любого пользователя корпоративной сети.

Необходимые настройки - указать, что ключевой контейнер помещен в хранилище сертификатов (Certificate Store) Microsoft. В момент запроса на соединение с БД служба смарт-карты RTX позволяет сетевым драйверам Oracle «видеть» все сертификаты, установленные на смарт-карте. Процесс аутентификации проходит в два этапа:

1)       запрос на выбор сертификата (в зависимости от выбранного сертификата пользователь будет работать с определенной БД с заданными офицером безопасности правилами). Если сертификат единственный, он выбирается автоматически;

2)       запрос PIN-кода смарт-карты для авторизации на операции с закрытым ключом.

Когда клиенту требуется предъявить свой сертификат, служба смарт-карты «подсказывает» ему, по сертификат следует брать из смарт-карты. Для подтверждения подлинности сервера клиенту необходим личный ключ для расшифровки ответа сервера. Закрытый ключ находится в защищенной памяти смарт-карты, и все операции с ним выполняет встроенный в карту криптопроцессор. Для таких операций требуется дополнительная авторизация, то есть запрашивается PIN-код. Когда между клиентом и сервером установлены доверительные отношения, сервер проверяет наличие отличительного имени пользователя, для которого издан сертификат клиента, в LDAP-каталоге - Oracle Internet Directory. Если таковой найден, дополнительно определяются экземпляр БД, схема и набор прав для клиента. После этого сервером создается сессия пользователя с указанными параметрами. Сетевой обмен между клиентом и сервером происходит по соединению, защищенному определенным криптоалгоритмом.

Заказчик, настроивший сервер БД, клиентские рабочие станции и установивший сертификаты пользователей на смарт-карты, получает надежную аутентификацию, шифрованный трафик между рабочими станциями и сервером, и, самое главное, строгую персонализацию доступа в БД. Все приложения, работающие с Oracle - от DOS-консоли до сложных ERP-систем, будут работать с рассмотренным методом аутентификации без каких-либо доработок.

Обзор технических способов противодействия типовым угрозам.

Главным объектом атаки являются, как правило, административные полномочия. Их можно получить, узнав в хешированном или символьном виде пароль администратора системы. Типовые угрозы и технические методы противодействия им с помощью технологий, основанных на применении встроенных в Oracle средств PKI, приведены в таблице.

Таблица.

Методы противодействия типовым угрозам

Ближайшие перспективы

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

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

Тема 3. Политика безопасности

Введение.

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

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

Вопрос 1. Цель формализации политики безопасности.

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

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

В руководстве по компьютерной безопасности, разработанном национальным институтом стандартов и технологий США (National Institute of Standards and Technology — NIST), рекомендовано включать в описание политики безопасности следующие разделы.

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

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

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

Соблюдение политики. В разделе описываются права и обязанности пользователей ИС. Необходимо явное описание и документированное знакомство пользователей с перечнем недопустимых действий при осуществлении доступа к информационным ресурсам организации и наказания за нарушения режимных требований. Должна быть ясно определена технология фиксации фактов нарушения политики безопасности и применения административных мер воздействия к нарушителям.

Для эффективной реализации политика безопасности должна быть понятной всем пользователям информационных систем организации. Возможна подготовка презентаций и проведение семинаров с разъяснением основных положений и практических технологий реализации политики безопасности. Новые сотрудники организации должны быть ознакомлены или обучены конкретным правилам и технологиям доступа к ресурсам ИС, реализованным в соответствии с принятой политикой безопасности. Целесообразно проводить контрольные проверки действий сотрудников с обсуждением результатов.

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

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

1)       документацию, определяющую используемые подходы к оцениванию и управлению рисками для организации в целом и при необходимости конкретных подразделений;

2)       обоснование принятых решений по выбору средств защиты для рассматриваемой информационной системы;

3)       формальное описание процедуры определения допустимого уровня остаточного риска;

4)       директиву, определяющую процедуру проверки режима информационной безопасности и журналов, в которых фиксируются результаты проверки (документы необходимы для осуществления проверки эффективности реализации средств обеспечения информационной безопасности, осуществления их контроля качества и правильности использования);

5)       документацию, регламентирующую процессы обслуживания и администрирования информационных систем;

6)       документацию по подготовке периодических проверок по оцениванию и управлению рисками;

7)       документ «Ведомость соответствия», включающий сведения по организации системы управления информационной безопасностью и регистрации средств управления безопасностью;

8)       контрмеры для противодействия выявленным рискам. Успех проведения в жизнь политики безопасности больше зависит от усилий и опытности людей, реализующих политику, чем от/сложных программно-технических средств контроля.

Вопрос 2. Принципы построения защищенных систем баз данных.

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

В настоящее время отсутствует общепринятая методология разработки защищенных автоматизированных информационных систем и, в частности, систем баз данных. В подобных случаях традиционно используется подход, основанный на анализе лучшего мирового опыта решения некоторого класса проблем и формулировании руководящих принципов построения соответствующих систем, концентрирующих накопленный опыт. Именно таким образом для проблемы обеспечения безопасности информационных систем разрабатывался британский стандарт BS 7799 и созданный на его основе международный стандарт ISO 17799.

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

·     экономическая оправданность механизмов защиты;

·     открытое проектирование;

·     распределение полномочий между различными субъектами в соответствии с правилами организации;

·     минимально возможные привилегии для пользователей и администраторов;

·     управляемость системы при возникновении отказов и сбоев;

·     психологическая приемлемость работы средств защиты данных.

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

В соответствии с принципом открытого проектирования, технология систем защиты не должна базироваться на «секретных» алгоритмах. Этот принцип широко используется при проектировании безопасных систем и сетей связи. Высокое качество систем защиты обеспечивается не недостатком знаний у возможных нарушителей, а использованием широко опробованных (как правило, открытых) стандартов и правильной организацией управления ключевой информацией. Использование алгоритмов, основанных на открытых стандартах в области информационной безопасности, повышает степень доверия пользователей к системе защиты и формирует правильную психологическую установку на необходимость внимательности и аккуратности при работе с ключевой информацией.

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

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

Принцип минимально возможных привилегий для пользователей и администраторов предписывает, чтобы каждый пользователь (процесс) системы оперировали с данными, используя наименьший из возможных набор привилегий, необходимых для выполнения конкретной функции. Применение данного принципа нацелено на минимизацию ущерба, который может быть нанесен в случае сбоя, ошибки программного обеспечения или компрометации элементов системы защиты данных. Принцип минимальных привилегий, используемый при создании пользователей Oracle, — пример реализации этого принципа. Использование точек входа SYSTEM и, особенно, SYS должно быть предметом особого регламента. Хорошей практикой является использование администратором безопасности нескольких точек входа: обычной, с набором привилегий, достаточным для выполнения основных работ, и особой (типа SYSTEM), используемой только при возникновении необходимости выполнения действий, требующих высоких привилегий.

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

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

Вопрос 3. Стратегия применения средств обеспечения информационной безопасности.

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

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

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

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

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

·     определение ценности информационных ресурсов и оценка ущерба от конкретных действий или событий часто может быть выполнена только на качественном уровне;

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

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

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

·     от наиболее опасных из известных угроз;

·     от всех идентифицированных угроз;

·     от всех потенциально возможных угроз.

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

·     никакое вмешательство в информационную систему не допускается (требование предъявляется к функционирующим системам обработки информации, остановка или модификация которых недопустима);

·     допускается частичное изменение архитектуры информационной системы (возможна временная остановка процессов функционирования и модификация используемых технологий для встраивания некоторых механизмов защиты);

·     требования, обусловленные необходимостью обеспечения информационной безопасности, принимаются в полном объеме при проектировании и эксплуатации системы обработки информации. На основе представленных классификаций можно предложить три стратегии обеспечения информационной безопасности, представленные в таблице 1.

Таблица 1.

Стратегии обеспечения информационной безопасности

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

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

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

Контрольные вопросы:

1.       Сформулируйте определение политики безопасности.

2.       Какова цель формализации политики безопасности?

3.       Объясните необходимость нескольких вариантов документального оформления политики безопасности для различных уровней управления.

4.       Сформулируйте примерный перечень разделов документа, описывающего политику безопасности.

5.       Выполнение каких условий необходимо обеспечить для эффективной реализации политики безопасности?

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

7.       Приведите известные вам примеры применения принципа открытого проектирования для конкретных систем обработки данных. Имеются ли исключения, когда применение данного принципа является неоправданным?

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

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

10.  Каким образом и кем должна определяться ценность информационного ресурса?

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

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

Тема 4. Какие именно данные приложения следует хранить в базе данных?

Вопрос 1. Где хранить настройки приложений?

В программировании на платформе .NET для хранения данных приложений обычно используются XML-документы (обычно с расширением .config). Если необходимо, чтобы приложение демонстрировало различное поведение в разных ситуациях, возникают сложности. Необходимо либо предусмотреть это в файле конфигурации, либо рассмотреть вариант с применением архитектуры параметров, управляемых данными, при которой для настройки приложения используются данные. Если вы выберете последнее решение, то база данных будет естественным местом для хранения данных, которые управляют настройками приложения.

Прежде чем выбрать модель управления настройками с помощью данных, следует сначала учесть некоторые доводы в пользу использования в приложении конфигурационных файлов. Если ваше приложение не нуждается в базе данных для какой-либо еще функции, возможно, не стоит включать в приложение базу данных только для параметров приложения. Аналогично, если приложение нуждается в параметрах уже в процессе загрузки, а на этом этапе процесса база данных обычно недоступна, то конфигурационный файл будет более естественным решением. (Раньше параметры приложения в подобных ситуациях обычно хранились в реестре Windows, но сейчас они чаще хранятся в конфигурационных файлах приложения.) Одним из главных преимуществ хранения параметров конфигурации приложения в файле является то, что этим файлом с легкостью могут манипулировать пользователи. XML-файл можно редактировать в Блокноте, поэтому любой пользователь может изменить параметры. Если необходимо предотвратить просмотр или изменение уязвимых настроек пользователями, то файлы конфигурации можно зашифровать.

Несмотря на недоступность в процессе запуска приложения, хранение параметров приложения в базе данных может быть выгодным. В базе данных можно управлять доступом к параметрам при помощи политики безопасности базы, в том числе, используя шифрование в SQL Server 2005. Это не даст пользователям, которые, возможно, не вполне представляют себе последствия сделанных изменений, возможности изменить параметры. Если вы используете какой-либо вариант ролевой модели безопасности, можно контролировать, кому предоставляется возможность изменять отдельные параметры приложения. Сохранение параметров приложения в базе данных будет также очень полезно в распределенных приложениях. Таким образом, вы сможете хранить такие разные параметры, как часовой пояс или офисные правила, в одном месте - базе данных. Эти параметры можно настроить так, чтобы приложение хранило различные версии настроек для разных пользователей или групп пользователей, а контролировать параметры смогут сотрудники, имеющие достаточную квалификацию. В табл. 2. показаны преимущества, предлагаемые каждым из двух вариантов.

Совет. Если вы хотите использовать преимущества, предоставляемые хранением параметров в базе данных, но не хотите утяжелять клиент полнофункциональной базой данных, подумайте о реализации хранения параметров приложения в базе данных средствами программы Microsoft SQL Server 2005 Express Edition, которая распространяется бесплатно, или Microsoft SQL Server 2005 Workgroup Edition, стоимость которой является убедительным доводом в пользу ее применения для небольших реализаций.

Таблица 2.

Сравнение вариантов хранения параметров приложения

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

Вопрос 2. Где хранить пользовательские настройки?

Часто приложению необходимо хранить информацию о предпочтениях пользователей. В веб-приложениях это обычно реализуется при помощи файлов cookie (небольших текстовых файлов, которые хранят информацию о пользователях), но ввиду возросших требований к обеспечению безопасности винтернете такой подход может оказаться проблематичным. При использовании некоторых видов идентификации пользователей пользовательские настройки можно хранить в базе данных. Это позволит управлять этими настройками, не обращаясь к клиентскому компьютеру. В базе данных можно хранить самые разные пользовательские настройки. Эти настройки можно хранить в виде XML-данных, которые обеспечивают максимальную гибкость (о хранении XML-данных будет рассказано далее в этой лекции). Можно также использовать стандартные методы работы с данными для отслеживания пользовательских настроек. Если для хранения пользовательских настроек используется SQL Server, то пользователь может переносить их с одного клиента на другой.

Реализация таблицы пользовательских настроек:

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

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

Таблица 3.

Примерный проект таблицы для хранения пользовательских настроек

3.  Существует две распространенных реализации столбцов пользовательских настроек. Первая реализация - реляционная. Каждая настройка в этой реализации хранится в отдельном столбце таблицы. С этим решением связана следующая проблема: чтобы добавить дополнительную настройку, придется расширять таблицу путем добавления столбца. Второй вариант - все пользовательские настройки хранятся в одном столбце. С появлением XML можно использовать XML-документ для хранения нужных настроек либо в столбце TEXT, либо в столбце с типом данных XML; об этом речь пойдет далее в этой лекции.

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

·     Хранимая процедура Insert. С помощью этой процедуры добавляется начальная запись пользовательских настроек. Часто это делается при добавлении пользователя, поэтому данную процедуру можно объединить с процедурой добавления пользователя.

·     Хранимая процедура Update. Обновляет запись пользовательских настроек. Эта процедура часто вызывается для управления пользовательскими настройками в приложении.

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

·     Хранимая процедура Delete. Предназначена для удаления записи пользовательских настроек. Эта операция, как и операция вставки, может выполняться в составе процедуры удаления пользователя. Однако вам нужно будет выполнить эти две процедуры по отдельности, если придется поддержать концепцию, например, сбросить пользовательские настройки на значения по умолчанию.

Вопрос 3. Где хранить XML-документы.

Несколько лет назад XML-документы были новым веянием, но сейчас они уже стали привычными. Весьма вероятно, что вы уже видели и применяли XML-документы для настройки конфигурации и других задач в приложениях, с которыми работали. В SQL Server 2005 и Microsoft .NET Framework XML-документы широко используются для настройки параметров конфигурации и реализации других функций, таких, как службы интеграции SQL Server Integration Services (для которых XML хранятся в файлах .dtsx) и службы составления отчетов SQL Server Reporting Services (данные XML хранятся в файлах с расширением .rdl). XML имеет ряд преимуществ, не последнее из которых - гибкость при изменении требований к конфигурации приложения. Как было отмечено ранее, файлы XML также дают возможность пользователям приложения легко изменять параметры конфигурации. XML также прекрасно справляется с хранением иерархических данных. Вот несколько примеров иерархических данных: магазинные чеки, спецификации материалов и счета за медицинское обслуживание. Все они включают родительские записи с дочерними записями разных уровней. Извлечение полных наборов этих данных из механизма базы данных может быть затруднено, но XML хранит данные в форме, позволяющей легко просмотреть данные. Поскольку XML очень эффективен и все более широко используется, разработчики компании Microsoft включили в SQL Server 2000 и SQL Server 2005 тип данных XML, а также реализовала особый механизм оптимизации и операторы T-SQL для управления XML-данными.

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

Вопрос 4. Поддержка XML в SQL Server 2005.

В SQL Server 2005 разработчиками Microsoft в механизм базы данных были добавлены несколько новых специфических XML-функций. Эти усовершенствования позволили облегчить доступ к XML-данным и манипуляции с ними. Ниже перечислены некоторые из таких усовершенствований:

·     Собственный тип данных XML.

·     Поддержка XML-схем.

·     Возможность использования запросов XQuery к XML-данным, которые хранятся в столбцах с типом данных XML и в переменных.

·     Возможность индексировать XML-данные, которые хранятся в столбцах XML.

·     Поддержка языка манипулирования данными XML (XML-DML).

·     Усовершенствование существующих функций SQL Server 2000 для работы с XML, в том числе добавление ключевых слов OPENROWSET, FOR XML и OPENXML.

Вопрос 5. Использование типа данных XML.

В SQL Server 2005 появляется полнофункциональный тип данных XML. Благодаря этому типу данных становится возможным использовать свойственные XML SQL-запросы для поиска XML-данных и доступа к ним. Этот тип данных доступен и для таблиц, и для переменных. Если вы храните данные с использованием типа данных XML, то для запроса к ним можно использовать реализацию языка запросов XQuery в SQL Server. До появления типа данных XML при необходимости выполнить запрос к этим данным проектировщикам приходилось сначала извлекать их в реляционную версию. Необходимость извлечения XML-данных в таблицы и столбцы (эта методика получила название разбивки данных) с целью получения возможности запрашивать эти данные ограничивала гибкость, присущую XML-документам. Теперь, благодаря возможности использовать тип данных XML, разработчики могут ссылаться на содержимое документа, не прибегая к его разбивке на строки и столбцы. В табл. 4 перечислены поддерживаемые в SQL Server 2005 методы манипуляций с типом данных XML.

Таблица 4.

Методы языка XQuery, поддерживаемые в SQL Server 2005

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

Применяем метод Query() языка XQuery.

1.       В меню Start (Пуск) выберите All Programs, Microsoft SQL Server 2005, SQL Server Management Studio (Все программы, Microsoft SQL Server 2005, Среда SQL Server Management Studio).

2.       В окне Microsoft SQL Server Management Studio создайте новый запрос, нажав кнопку New Query (Создать запрос). (Готовый запрос можно найти в файлах примеров под именем XQueryQueryMethod.sql).

3.       Объявите переменную с типом данных XML, введя в панель запросов следующий код:

DECLARE @SampleXML XML

4.       Запишите в переменную выражение XML, добавив в панель запросов следующий код:

SET @SampleXML = '<root>

<L1>

  <L2>Это первая строка</L2>

</L1>

<L1>

  <L2>Это вторая строка</L2>

</L1> </root>'

5.       Чтобы извлечь значения из узла L2, воспользуйтесь методом query(). Введите в панель запроса следующий код:

SELECT @SampleXML.query(«/root/L1/L2»)

6.       Выполните запрос, нажав кнопку Execute (Выполнить) на панели инструментов или функциональную клавишу F5. В панели результатов будут отображены следующие результаты:

<L2> Это первая строка<\L2>

<L2> Это вторая строка<\L2>

Даже этот простой пример может дать некоторое представление о том, что можно сделать с помощью новых функций XQuery в SQL Server. Можно использовать метод data(), чтобы возвратить данные из элемента без тэгов XML, или метод exist(), чтобы проверить, существует ли определенный узел.

Следующий код (который можно найти в файлах примеров под именем XQueryQueryDataMethod.sql) демонстрирует пример использования методаdata() для возвращения определенного фрагмента XML-данных, не заключенных в тэги XML:

DECLARE @SampleXML XML SET @SampleXML =

«<root>

  <L1>

    <L2>Это первая строка</L2>

  </L1>

  <L1>

    <L2>Это вторая строка</L2>

  </L1>

  </root>«

SELECT @SampleXML.query(«data(/root/L1[L2 = «Это вторая строка»])»)

Должен получиться результат «Это вторая строка».

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

DECLARE @SampleXML XML, @Exists bit

SET @SampleXML =

«<root>

  <L1>

    <L2>Это первая строка</L2>

  </L1>

  <L1>

    <L2>Это вторая строка</L2>

  </L1>

 </root>«

SET @Exists = @SampleXML.exist(«/root/L1/L2[text() =

                    «Это первая строка»]»)

SELECT @Exists

Результирующий набор будет содержать значение 1.

Одно из преимуществ использования переменных XML заключается в том, что можно классифицировать столбец с другим типом данных, например, TEXT или VARCHAR, как XML, а затем применить методы XQuery к данным в этом столбце. Если вы используете XML в уже имеющейся среде SQL Server 2000, то, всего вероятнее, данные хранятся в полях TEXT или VARCHAR. В среде SQL Server Management Studio можно просмотреть данные в XML-формате. Это было невозможно в модуле Query Analyzer, который возвращал данные в виде нескольких строк. Следующий пример кода показывает, как классифицировать текстовые данные как XML.

SELECT CAST(textdata AS XML)

  FROM dbo.SomeTable

  WHERE SomeColumnID = 1

На рис. 4 показаны результаты запроса, который возвращает XML-данные, отображаемые в виде строки, в SQL Server Management Studio.

Рис. 4. Результаты запроса XQuery, отображаемые в SQL Server Management Studiio в виде строки

Если щелкнуть ссылку в панели результатов, как показано на рис. 4, то вы увидите результат, отображенный в виде XML, как показано на рис. 5.

Рис. 5. Так выглядит результат запроса, отображаемый в SQL Server Management Studio в виде XML после перехода по ссылке в панели результатов

Вопрос 6. Типизированный или нетипизированный XML?

SQL Server 2005 поддерживает использование XML-схем с типом данных XML. На рис. 6 показано размещение коллекции схем в SQL Server Management Studio. Если вы используете схемы, или коллекции схем, как они называются в SQL Server, то SQL Server применяет схему к XML-данным, хранимым в таблице. При применении схемы принудительно применяются типы данных и ограничения посредством выполнения синтаксического анализа на основе схемы, которая загружается в столбец с типом данных XML. Можно гарантировать форматирование XML-данных, используя типизированные столбцы XML.

Рис. 6. Размещение коллекции схем в SQL Server Management Studio

Если вы храните XML-данные как нетипизированные, то есть, не применяя схему непосредственно к данным, тип данных все равно будет XML, и с этими данными можно использовать функции XML. В любом случае, целый ряд операторов и функций T-SQL доступен как для типизированных, так и для нетипизированных столбцов.

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

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

Использование файловой системы с XML-данными.

Несмотря на то, что в SQL Server 2005 были внесены заметные усовершенствования в способ хранения XML в базе данных, по-прежнему можно обращаться к XML-документам, хранящимся вне базы данных. При помощи операторов FOR XML и OPENXL вы сможете записать XML-фай-лы и выполнить разбивку этих файлов для вставки в базу данных. Оба оператора были доступны в SQL Server 2000 и по-прежнему функционируют в SQL Server 2005. Более того, можно использовать оператор OPENROWSET для массовой высокопроизводительной загрузки XML-документов в базу данных.

Где хранить файлы внешних приложений.

Не исключено, что вы окажетесь в такой ситуации, когда для поддержки вашего приложения будут необходимы файлы других типов - документы Microsoft Word (файлы .doc), электронные таблицы Microsoft Excel (файлы.xls), изображения (файлы .jpg или .bmp), видео (файлы .mpeg), или даже звуковые файлы (файлы .wav). Где лучше хранить эти файлы, если они необходимы бизнес-приложению? Существует два широко используемых метода хранения таких файлов:

·     Хранение файлов в файловой системе со ссылкой на них в базе данных.

·     Хранение файлов в виде больших объектов в столбцах LOB в таблице базы данных.

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

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

Если файлы хранятся в файловой системе, то это дает такие же преимущества, которые были ранее рассмотрены для хранения настроек приложения в конфигурационном файле. Вы можете быстро обратиться к этим файлам при помощи старых испытанных методов, например, через Проводник Windows в Microsoft Windows. Пользователи смогут обратиться к этим файлам вне контекста приложения (что может быть желательным или нежелательным, в зависимости от того, как используются файлы). Если вы работаете с файлами, используя репозиторий документов, то ссылка на файлы из таблицы, вероятно, подойдет для вашего случая – при этом таблица хранится в упрощенной форме, способствующей ускорению поиска. Однако если приложение зависит от отдельных характеристик файла, например, если нужно, чтобы Столбец А в Excel содержал номера счетов, то предоставление пользователям возможности доступа к этим файлам подвергает риску целостность приложения.

Какие обстоятельства говорят в пользу хранения файлов в базе данных? Если файлы в базе данных хранятся с использованием типа данных LOB, например, BINARY или IMAGE, можно управлять доступом к файлам. Вам не придется беспокоиться о путях к файлам и других проблемах, связанных с файловой системой, которые возникают, если файлы хранятся за пределами базы данных и приложения. Тем не менее, приложению понадобится учетная запись на тот случай, если у других внешних приложений возникнет необходимость в этих файлах. Независимо от того, какому способу хранения файлов - в базе данных или в файловой системе - будет отдано предпочтение, необходимо продумать ссылочный механизм и механизм отслеживания информации о данных в базе данных.

Примечание: Если вы интересуетесь тем, может ли SQL Server обрабатывать хранение файлов в таблице базы данных, особенно если вам приходится хранить несколько предыдущих версий, попробуйте обратиться к инструменту координации совместной работы от Microsoft - Windows SharePoint Services (поставляется с Microsoft Windows 2003) и Microsoft Office SharpPoint Portal Services. Любое из этих приложений использует базы данных SQL Server для управления файлами, сохраняя версии файлов в таблицах базы данных.

Заключение.

Возможно, вы не получили здесь однозначного правильного ответа на ваши вопросы, касающиеся хранения данных. Тем не менее, Microsoft внесла существенные усовершенствования в ядро СУБД, чтобы вы могли хранить больше типов данных более эффективным способом. Если вам приходится хранить XML-данные, придется серьезно подумать об использовании нового встроенного типа данных XML именно из-за функций, которые он предлагает. SQL Server может также манипулировать файлами приложений других типов для отслеживания данных приложения, в том числе, файлов настроек. Думаем, вы сможете воспользоваться информацией, представленной в этой лекции, чтобы принять правильное решение о размещении хранилища данных при разработке вашего приложения.

Таблица 5.

Краткий справочник

Тема 5. Основные принципы обеспечения безопасности базы данных

Проектирование механизма сетевой безопасности для обеспечения безопасности системы базы данных.

SQL Server 2005 – первая версия SQL Server, которая была разработана в рамках инициативы Microsoft Trustworthy Computing (Защищенные информационные системы). Один из принципов этой инициативы – Security by Default (Безопасность по умолчанию). Реализуя этот принцип, SQL Server 2005 по умолчанию отключает некоторые сетевые настройки, чтобы сохранить максимально возможный уровень безопасности среды SQL Server.

Разрешение удаленного доступа.

SQL Server – это система управления базами данных, которая должна работать на сервере сети, принимая подключения от удаленных пользователей и приложений. Можно подключиться к SQL Server локально, с того же компьютера, на котором выполняется SQL Server, но в производственных системах баз данных, как правило, эта возможность не используется. Следовательно, очень важно правильно сконфигурировать SQL Server для приема защищенных подключений от удаленных компьютеров.

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

При установке SQL Server с параметрами по умолчанию многие функции отключены, чтобы уменьшить уязвимость системы базы данных против атак. Например, в SQL Server 2005 по умолчанию не разрешаются удаленные подключения (за исключением версии Enterprise), поэтому для того, чтобы задействовать удаленные подключения, мы воспользуемся инструментом SQL Server Surface Area Configuration (Настройка контактной зоны SQL Server), как показано на рис. 7.

Для этого выполните перечисленные ниже действия:

Разрешаем удаленные соединения.

В меню Start (Пуск) выберите All Programs,. Microsoft SQL Server 2005, Configuration Tools, SQL Server Surface Area Configuration. (Все программы, Microsoft SQL Server 2005, Средства настройки, Настройка контактной зоны SQL Server).

Рис. 7. Инструмент Настройка контактной зоны SQL Server для служб и подключений

1.  Под заголовком Configure Surface Area For Localhost (Настроить контактную зону для localhost) в нижней части окна щелкните ссылку Surface Area Configuration For Services And Connections (Настройка контактной зоны для служб и соединений).

2.  С левой стороны открывшегося окна отображается список компонентов, которые можно настроить. В этом списке разверните дерево элемента Database Engine и щелкните мышью элемент Remote Connections (Удаленные соединения).

3.  Выберите вариант Local And Remote Connections (Локальные и удаленные соединения), а затем выберите нужные протоколы.

Допускается использование удаленных соединений с использованием сетевых протоколов TCP/IP или Named Pipes (именованные каналы). В интересах безопасности и производительности рекомендуется использовать протокол TCP/IP.

Обеспечение безопасности внешнего доступа.

Серверы баз данных должны быть хорошо защищены от несанкционированного внешнего доступа ввиду критической важности информации, которая на них хранится. Ни в коем случае нельзя допускать, чтобы к SQL Server можно было обратиться непосредственно через интернет. Если необходимо предоставить доступ к SQL Server через интернет пользователям или приложениям, следует гарантировать, что сетевое окружение имеет адекватные механизмы защиты, такие, как межсетевой экран или система обнаружения вторжений.

Дополнительная информация. SQL Server допускает использование соединений с различными типами конечных точек. О конечных точках рассказывается в лекции 5 курса «Оптимизация работы серверов баз данных Microsoft SQL Server 2005».

Управление доступом к экземплярам SQL Server.

Устанавливая соединение с экземпляром SQL Server, вы должны предоставить корректную информацию для проверки подлинности. Ядро базы данных выполняет двухфазный процесс проверки подлинности. Сначала проверяется, предоставили ли вы действующее имя пользователя учетной записи, имеющей разрешение на подключение к экземпляру SQL Server. Далее, ядро базы данных проверяет, имеет ли данная учетная запись разрешение на доступ к той базе данных, к которой выполняется попытка подключения.

В SQL Server 2005 участники – это лица, группы или процессы, которые запрашивают доступ к ресурсам базы данных. Участники иерархически упорядочены по уровням операционной системы, сервера и базы данных и могут быть индивидуальными (неделимыми) или коллективными.

Например, имя входа SQL – это индивидуальный участник на уровне экземпляра SQL Server, а группа Windows – коллективный участник на уровне операционной системы.

Выбор режима проверки подлинности.

SQL Server 2005 для предоставления доступа поддерживает два режима аутентификации: режим проверки подлинности Windows и комбинированный режим проверки подлинности. Режим проверки подлинности можно настроить через SQL Server Management Studio, выполнив следующие действия:

Настраиваем режим проверки подлинности.

1.  В меню Start (Пуск) выберите All Programs,. Microsoft SQL Server 2005, SQL Server Management Studio (Все программы, Microsoft SQL Server 2005, Среда SQL Server Management Studio).

2.  В диалоговом окне Connect To Server (Соединение с сервером) нажмите кнопку Connect (Соединить).

3.  В панели Object Explorer (Обозреватель объектов) щелкните правой кнопкой мыши на значке экземпляра SQL Server и выберите из контекстного меню пункт Properties (Свойства).

4.  В панели Select A Page (Выбор страницы) выделите значок Security (Безопасность).

5.  В секции Server Authentication (Серверная проверка подлинности) выберите нужный режим проверки подлинности, как показано на рис. 8.

Важно. Для того, чтобы изменение режима проверки подлинности вступило в силу, перезапустите экземпляр SQL Server.

При выборе режима проверки подлинности рекомендуется следовать приведенным ниже рекомендациям:

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

·     Комбинированный режим проверки подлинности (SQL Server и Windows). В этом режиме пользователь может подключиться к SQL Server с использованием режима проверки подлинности либо Windows, либо SQL Server. В последнем случае SQL Server проверяет учетные данные пользователя на соответствие действующим именам входа SQL Server. При использовании режима проверки подлинности SQL Server пользователь должен указать в строке соединения имя пользователя и пароль для доступа к SQL Server.

Рис. 8. Установка режима проверки подлинности через интерфейс SQL Server Management Studio

Примечание. В SQL Server 2005 невозможно задать отдельно режим проверки подлинности SQL Server. Однако необходимо, по возможности, настроить параметры безопасности для экземпляра SQL Server, чтобы ограничить доступ большей части пользователей Windows.

Как правило, в качестве режима проверки подлинности рекомендуется выбирать режим проверки подлинности Windows. В режиме проверки подлинности Windows по сети не передается пароль пользователя. Кроме того, можно управлять учетными записями пользователей через централизованное корпоративное хранилище, например, через службу каталогов Active Directory, и воспользоваться преимуществами всех функций безопасности, доступных в операционной системе.

Однако существуют ситуации, когда проверка подлинности Windows будет не лучшим вариантом. Например, если необходимо предоставить доступ пользователям, которые не принадлежат к среде вашей операционной системы, например, внешним поставщикам или тем, кто использует операционную систему с несовместимой системой обеспечения безопасности, лучше выбрать комбинированный режим проверки подлинности и использовать имена входа SQL Server, чтобы установить для таких пользователей соединение с SQL Server.

Соединение с экземпляром SQL Server.

В случаях, когда пользователю необходим доступ к экземпляру SQL Server, администратор должен предоставить этому пользователю корректную информацию для проверки подлинности. Эта информация зависит от выбранного режима проверки подлинности. В данном разделе объясняется, как создавать имена входа для пользователей операционной системы, которые будут поддерживать режим проверки подлинности Windows, и имена входа SQL для поддержки режима проверки подлинности SQL.

Предоставляем доступ пользователям и группам Windows.

Можно разрешить пользователям операционной системы устанавливать соединение с сервером SQL Server посредством создания имени входа для пользователя или группы Windows. По умолчанию, доступ к SQL Server предоставлен только членам локальной группы администраторов Windows и учетной записи службы, которая запускает службы SQL.

Примечание. Существует возможность удалить права на удаленный доступ к SQL Server из списка прав членов группы администраторов.

Доступ к экземпляру SQL Server можно предоставить, создав имя входа либо путем непосредственного ввода команд SQL, либо через интерфейс SQL Server Management Studio. Следующий код предоставляет доступ к экземпляру SQL Server пользователю домена Windows ADWORKS\jlucas:

CREATE LOGIN [ADVWORKS\jlucas] FROM WINDOWS;

Примечание. Если для создания имени входа используется SQL Server Management Studio, инструмент выполняет аналогичную инструкцию T-SQL.

Имена входа Windows по умолчанию.

В процессе установки SQL Server 2005 создаются имена входа Windows, перечисленные в табл. 6.

Таблица 6.

Имена входа Windows по умолчанию

При подключении к SQL Server 2005 с использованием имени входа Windows, SQL Server полагается на проверку подлинности операционной системы и проверяет только, имеет ли пользователь Windows соответствующее имя входа, определенное в этом экземпляре сервера SQL Server, или принадлежит ли это имя входа группе Windows с соответствующим именем входа в этот экземпляр SQL Server. Соединение, использующее имя входа Windows, называется доверительным соединением. Предупреждение. Не исключена ситуация, при которой пользователь или группа, сопоставленные имени входа Windows, будут удалены из операционной системы без уведомления SQL Server. SQL Server 2005 не выполняет проверку для такой ситуации, поэтому следует периодически проверять экземпляр SQL Server, чтобы выявить имена входа, утратившие связь с пользователями. Это легко можно выполнить при помощи системной хранимой процедуры sp_validatelogins.

Следующая программа на Microsoft Visual Basic (она имеется в файлах примеров под именем ConnectUsing WindowsAuth.vb.txt) показывает, как установить соединение с SQL Server с использованием проверки подлинности Windows:

«Создаем экземпляр объекта SQLConnection 

Dim oConn as New SQLClient.SQLConnection 

«Определяем строку соединения

oConn.ConnectionString=«server=localhost; database=AdventureWorks;» + _ 

                       «Integrated Security=SSPI»

«Открываем соединение

oConn.Open()

«Выполняем необходимые действия

...

«Закрываем соединение

oConn.Close()

Предоставляем доступ именам входа SQL Server.

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

Примечание. SQL Server 2005 использует самозаверяющий сертификат для шифрования пакетов входа, чтобы предотвратить несанкционированный доступ к информации о входе в систему. Однако после того как процесс входа завершен и имя входа проверено, SQL Server пересылает все последующие пакеты информации в незашифрованном виде. Если необходимо обеспечить безопасность и конфиденциальность коммуникаций, можно использовать два метода: протокол Secure Sockets Layer (SSL) и протокол Internet Protocol Security (IPSec).

Доступ к экземпляру SQL Server можно предоставить, создав имя входа SQL Server либо путем непосредственного ввода команд SQL, либо через интерфейс SQL Server Management Studio. В следующем примере мы создаем имя входа SQL Server «Mary» и назначаем для пользователя Mary базу данных Adventure Works в качестве базы данных по умолчанию.

CREATE LOGIN Mary

   WITH PASSWORD = '34TY$$543',

   DEFAULT_DATABASE =AdventureWorks;

В процессе установки SQL Server 2005 создается одно имя входа SQL Server - sa. Имя входа sa создается в любом случае, даже если вы выбрали в процессе установки режим проверки подлинности Windows.

Передовой опыт. Хотя имя входа sa нельзя удалить, необходимо переименовать и отключить его во избежание несанкционированного доступа к SQL Server с его использованием. О том, как отключить имя входа, вы узнаете в разделе «Запрещаем доступ пользователям».

При помощи следующего кода можно получить информацию об именах входа SQL Server из представления каталога sql_logins:

SELECT * FROM sys.sql logins;

Принудительно применяем политику паролей.

При использовании имен входа SQL Server необходимо реализовать сильные политики паролей для этих имен входа во избежание ослабления системы безопасности SQL Server с течением времени. SQL Server 2005 предоставляет возможность принудительного применения парольной политики операционной системы к именам входа SQL Server. Если SQL Server выполняется в среде Windows 2003 Server, то SQL Server использует API (интерфейс для прикладного программирования) NetValidatePasswordPolicy для управления следующими параметрами:

·     Сложность пароля.

·     Истечение срока действия пароля.

·     Блокировка учетной записи.

Если сервер SQL Server выполняется в среде Windows 2000 Server, то он использует правило SQL Server Native Password Complexity rule, которое было введено программой Microsoft Baseline Security Analyzer для принудительного применения следующих правил:

·     Пароль не может быть пустым или NULL.

·     Пароль не может совпадать с именем входа.

·     Пароль не может совпадать с именем компьютера.

·     В качестве пароля нельзя выбирать слова «Password», «Admin» или «Administrator».

Парольную политику можно включить при помощи следующего кода Transact SQL:

 CREATE LOGIN Mary

    WITH PASSWORD = '34TY$$543' 

    MUSTCHANGE,

    CHECK EXPIRATION = ON,

    CHECK POLICY = ON;

Управляем разрешениями для экземпляра.

Теперь вы знаете, как предоставить доступ пользователю к экземпляру SQL Server, но до сих пор ничего не было сказано о том, какие разрешения могут иметь эти имена входа в SQL Server. Как правило, пользователю необходим доступ к каким-либо данным. Однако возможно вам придется создать некоторые имена входа с разрешениями на выполнение задач администрирования.

Для выполнения этой задачи SQL Server предоставляет серверные роли на уровне экземпляра. (Серверные роли являются фиксированными, нельзя создать новые роли на уровне экземпляра). В табл. 7 перечислены фиксированные серверные роли, созданные SQL Server 2005.

Таблица 7.

Фиксированные серверные роли

Получаем информацию о принадлежности к серверной роли.

Выполнив запрос системной функции IS_SRVROLEMEMBER можно узнать, принадлежит текущий пользователь к одной из серверных ролей. Следующий пример кода Transact SQL возвращает значение 1, если текущее имя входа принадлежит к серверной роли sysadmin, и значение 0 в противном случае.

SELECT IS_SRVROLEMEMBER («sysadmin»);

Добавляем имя входа к серверной роли. Добавить имя входа к существующей серверной роли можно при помощи системной хранимой процедуры sp_addsrvrolemember. Следующий пример добавляет Mary к серверной роли sysadmin:

EXECUTE sp_addsrvrolemember «Mary», «sysadmin»;

Удаляем имя входа из серверной роли. Чтобы удалить имя входа из серверной роли, можно использовать хранимую процедуру sp_dropsrvrolemember. Следующий пример удаляет пользователя Mary из серверной роли sysadmin:

EXECUTE sp_dropsrvrolemember «Mary», «sysadmin»;

Предоставляем индивидуальные разрешения. SQL Server 2005 предоставляет более гранулярную структуру разрешений, что позволяет с большей точностью контролировать операции входа. Разрешениями можно манипулировать при помощи операторов GRANT, DENY и REVOKE. Информация о серверных разрешениях доступна из представления каталога sys.server_permissions.

В следующем примере пользователю Mary предоставляются права на создание и выполнение трассировок в SQL Server Profiler:

GRANT ALTER TRACE TO Mary;

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

SELECT * FROM fn_my_permissions (NULL, «SERVER»);

Дополнительная информация. Со списком серверных разрешений можно ознакомиться в разделе «Предоставление разрешений SQL Server. Инструкция GRANT (T-SQL)» в SQL Server Books Online (Электронная документация по SQL Server).

Запрещаем доступ пользователям.

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

·     Отключаем имя входа

ALTER LOGIN Mary DISABLE;

·     Включаем имя входа

ALTER LOGIN Mary ENABLE;

Можно проверить, отключены ли имена входа, выполнив запрос к представлению каталога sql_logins, как показано в следующем примере:

·     Отключаем имя входа

ALTER LOGIN Mary DISABLE; GO

·     Выполняем запрос к системному представлению каталога

SELECT * FROM sys.sql_logins

WHERE is_disabled=1; GO

·     Включаем имя входа

ALTER LOGIN Mary ENABLE;

Совет. В SQL Server Management Studio отключенные имена входа помечаются красной стрелкой. Эта стрелка отображается в правом нижнем углу значка имени входа, который находится в папке Security/Logins (Безопасность/Имена входа) в панели Object Explorer (Обозревателя объектов). С другой стороны, если необходимо удалить имя входа из данного экземпляра, следует использовать инструкцию DROP LOGIN. Следующий пример удаляет имя входа.

DROP LOGIN Mary;

Предупреждение. При удалении имени входа SQL Server 2005 не удаляет пользователей базы данных, сопоставленных этому имени входа.

Предупреждение. Удаление имени входа, которому сопоставлены пользователи или группы Windows не гарантирует, что эти пользователи или члены групп не смогут получить доступ к SQL Server. Учтите, что такие пользователи могут принадлежать и к какой-либо другой группе Windows с действующим именем входа.

Устанавливаем соединение с SQL Server с использованием проверки подлинности SQL Server

Следующая программа на Microsoft Visual Basic (она имеется в файлах примеров под именем ConnectUsingSQL Auth.vb.txt) показывает, как установить соединение с SQL Server с использованием проверки подлинности SQL Server:

«Создаем экземпляр объекта SQLConnection

Dim oConn as New SQLClient.SQLConnection

«Определяем строку соединения

«с заданными именем входа и паролем

oConn.ConnectionString=«server=localhost; database=AdventureWorks; « + _

                       «user id= Mary; password=34TY$$543»

«Открываем соединение

oConn.Open()

«Выполняем необходимые действия

...

«Закрываем с оединение

oConn.Close()

Тема 6. Управление доступом к базам данных SQL Server

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

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

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

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

Добавляем пользователя базы данных.

Добавить пользователя базы данных можно при помощи инструкции CREATE USER. Следующий пример кода Transact-SQL создает имя входа Peter и сопоставленного с ним пользователя в базе данных Adventure Works:

·     Создаем имя входа Peter

CREATE LOGIN Peter WITH PASSWORD='Tyu87IOR0';

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Добавляем пользователя базы данных Peter, который сопоставлен имени входа Peter в БД AdventureWorks.

CREATE USER Peter FOR LOGIN Peter;

Управляем пользователями базы данных.

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

SELECT HAS_DBACCESS(«AdventureWorks»);

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

Если нужно временно отключить доступ пользователя к базе данных, можно отозвать разрешение CONNECT для этого пользователя. Следующий пример отзывает разрешение CONNECT для пользователя Peter:

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Отзываем разрешение connect для Peter on the database AdventureWorks.

REVOKE CONNECT TO Peter;

Удалить пользователя в базы данных можно при помощи инструкции DROP USER.

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

Управляем пользователями, утратившими связь с именами входа.

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

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Составляем отчет обо всех пользователях базы данных, утративших связь с именем входа

EXECUTE sp_change_users_login @Action='Report';

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

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Создаем пользователя базы данных Paul в базе данных AdventureWorks;

·     не сопоставляя с ним имени входа в данном экземпляре SQL Server instance

CREATE USER Paul WITHOUT LOGIN;

Включаем пользователя guest.

Когда имя входа, которое не имеет сопоставленного пользователя, пытается соединиться с базой данных, SQL Server предпринимает попытку подключения с использованием пользователя Guest. Пользователь Guest создается по умолчанию без предоставления разрешений. Можно включить пользователя guest, предоставив ему разрешение CONNECT, как показано ниже.

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Предоставляем пользователю Guest доступ к базе данных AdventureWorks.

GRANT CONNECT TO Guest;

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

Предоставление разрешений на базу данных.

Создав пользователей базы данных, необходимо управлять разрешениями для этих пользователей. Это можно осуществить, добавляя пользователей в роли базы данных или предоставляя самим пользователям гранулярные разрешения.

Создаем роли базы данных.

Роли базы данных - это участники уровня базы данных. Роли базы данных можно использовать для назначения разрешений базы данных группе пользователей. В SQL Server 2005 по умолчанию создается набор ролей базы данных. Эти роли по умолчанию перечислены в табл. 8.

Таблица 8.

Роли базы данных по умолчанию

Можно добавлять роли базы данных, если нужно сгруппировать пользователей в соответствии с требованиями определенных разрешений. Следующий пример кода создает роль базы данных с именем Auditors и добавляет пользователя Peter в эту новую роль.

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Создаем роль Auditors в базе данных AdventureWorks.

CREATE ROLE Auditors;

GO

·     Добавляем пользователя Peter к роли Auditors

EXECUTE sp_addrolemember «Auditors», «Peter»;

Управляем ролями базы данных.

Выполнив запрос системной функции IS_MEMBER, можно проверить, принадлежит ли текущий пользователь к какой-либо роли базы данных. В следующем примере мы проверим, принадлежит ли текущий пользователь к роли базы данных db_owner.

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Проверяем, принадлежит ли текущий пользователь к роли db_owner

SELECT IS_MEMBER («db_owner»);

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

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Проверяем, принадлежит ли текущий пользователь к группе Managers в домене ADVWORKS

SELECT IS_MEMBER («[ADVWORKS\Managers]»);

Удалить пользователей из роли базы данных можно при помощи системной хранимой процедуры sp_droprolemember. Если нужно удалить роль базы данных, то используется инструкция DROP ROLE. Следующий код удаляет пользователя Peter из роли базы данных Auditors, а затем удаляет роль Auditors.

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Удаляем пользователя Peter из роли Auditors

EXECUTE sp_droprolemember «Auditors», «Peter»;

·     Удаляем роль Auditors из текущей базы данных

DROP ROLE Auditors;

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

Предоставляем гранулярные разрешения базы данных.

В качестве альтернативы использованию фиксированных ролей базы данных можно предоставлять гранулярные разрешения пользователям и ролям базы данных. Разрешениями можно управлять при помощи инструкций GRANT, DENY и REVOKE. В следующем примере мы предоставим разрешение BACKUP DATABASE пользователю Peter:

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Предоставляем разрешения пользователю базы данных Peter на резервное копирование базы данных AdventureWorks.

GRANT BACKUP DATABASE TO Peter;

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

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

Управление ролями приложения.

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

Создаем роли приложения.

Роль приложения можно создать при помощи инструкции CREATE APPLICATION ROLE. Этот код имеется в файле примеров ApplicationRoles.sql.

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Создаем роль приложения FinancialRole в текущей базе данных

CREATE APPLICATION ROLE FinancialRole WITH PASSWORD = «Pt86Yu$$R3»;

Используем роли приложения.

Роли приложений перед использованием необходимо активизировать. Это можно сделать, выполнив системную хранимую процедуру sp_setapprole. После того, как роль приложения активизирована в текущем соединении, она остается активной до тех пор, пока не будет закрыто соединение или выполнена системная хранимая процедура sp_unsetapprole. Хотя роли приложения предназначены для использования из клиентских приложений, их можно также использовать из особых пакетов T-SQL. Следующая процедура (ее можно найти в файлах примеров под именем ApplicationRolesUse.sql) описывает, как активизировать роль Financial Role и отменить эту активизацию.

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Объявляем переменную, в которой будет храниться контекст соединения. Этот контекст соединения понадобится нам в дальнейшем, чтобы после деактивации роли приложения соединение могло восстановить свой исходный контекст.

DECLARE @context varbinary (8000);

·     Активируем роль приложения и сохраняем текущий контекст соединения

EXECUTE sp_setapprole «FinancialRole», «Pt86Yu$$R3»,

@fCreateCookie = true, @cookie = @context OUTPUT;

·     Проверяем, был ли пользовательский контекст заменен контекстом роли приложения.

SELECT CURRENT_USER;

·     Деактивируем роль приложения, и восстанавливаем предыдущий контекст соединения.

EXECUTE sp_unsetapprole @context;

GO

·     Проверяем, был ли исходный контекст пользователя восстановлен.

SELECT CURRENT_USER; 

GO

Удаляем роли приложения.

Если нужно удалить роль приложения, используйте инструкцию DROP APPLICATION ROLE, как показано в следующем примере (этот код имеется в файле примеров ApplicationRoles.sql):

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     удаляем роль приложения FinancialRole из текущей базы данных

DROP APPLICATION ROLE FinancialRole;

Управление доступом к схемам.

В SQL Server 2005 реализована концепция ANSI для схем. Схемы - это контейнеры объектов, которые позволяют группировать объекты базы данных. Схемы оказывают большое влияние на то, как пользователи ссылаются на объекты базы данных. В SQL Server 2005 объект базы данных называется именем, состоящим из четырех компонентов следующей структуры:

<Server>.<Database>.<Schema>.<Object>.

Введение в схемы.

Схемы базы данных можно создавать при помощи инструкции CREATE SCHEMA. Создавая схему, можно создать объекты базы данных и назначить разрешения в пределах одной транзакции, которая вызывается инструкцией CREATE SCHEMA. Следующий пример (он есть в файлах примеров под именем ManagingAccessToSchemas01.sql) создает схему с именем Accounting, назначает пользователя Peter владельцем схемы и создает таблицу с именем Invoices. В этом примере также предоставляется разрешение select роли базы данных public.

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Создаем схему Accounting с владельцем Peter.

CREATE SCHEMA Accounting

AUTHORIZATION Peter;

GO

·     Создаем таблицу Invoices в схеме Accounting.

CREATE TABLE Accounting.Invoices (

InvoiceID int,

InvoiceDate smalldatetime,

ClientID int);

GO

·     Предоставляем разрешение SELECT на новую таблицу роли public.

GRANT SELECT ON Accounting.Invoices

TO public; GO

·     Добавляем строку данных в новую таблицу.

·     Обратите внимание на двухкомпонентное имя, которое мы используем для обращения к таблице в текущей базе данных.

INSERT INTO Accounting.Invoices

VALUES (101,getdate(),102);

Удалить схему можно при помощи инструкции DROP SCHEMA. В SQL Server 2005 не допускается удаление схемы, если в схеме есть объекты. Информацию о схемах можно получить, выполнив запрос к представлению каталога sys.schemas. Следующий пример выполняет запрос к представлению каталога sys.schemas, чтобы получить информацию о схеме:

SELECT *

FROM sys.schemas;

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

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Извлекаем информацию о схеме Accounting.

SELECT s.name AS «Schema»,

o.name AS «Object» FROM sys.schemas s INNER JOIN sys.objects o ON s.schema_id=o.schema_id WHERE s.name='Accounting'; GO

·     Удаляем таблицу Invoices из схемы Accounting.

DROP TABLE Accounting.Invoices;

GO

·     Удаляем схему Accounting.

DROP SCHEMA Accounting;

Отделяем пользователей от схем.

Одним из преимуществ схем является отделение пользователей от объектов. В SQL Server 2005 все объекты принадлежат к схемам, поэтому можно изменять и удалять пользователей базы данных без какого-либо влияния на объекты базы данных или ссылки на эти объекты из приложений базы данных. Эта абстракция позволяет владеть одними и теми же объектами нескольким пользователям, поскольку можно создать схему, владельцем которой будет роль базы данных.

Используем схему по умолчанию.

Когда приложение ссылается на объект базы данных, не уточняя схемы, SQL Server осуществляет попытку найти объект в схеме, заданной для текущего пользователя по умолчанию. Если объект не содержится в схеме по умолчанию, SQL Server пытается обнаружить объект в схеме dbo. В следующем примере (который можно найти в файлах примеров под именем ManagingAccessToSchemas03.sql) демонстрирует, как создать схему и назначить ее в качестве схемы по умолчанию для пользователя.

·     Создаем имя входа SQL Server в данном экземпляре SQL Server.

CREATE LOGIN Sara

WITH PASSWORD='TUT87rr$$'; GO

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Создаем пользователя Sara в базе данных AdventureWorks и сопоставляем этого пользователя имени входа Sara

CREATE USER Sara

FOR LOGIN Sara; GO

·     Создаем схему Marketing, владелец - пользователь Peter.

CREATE SCHEMA Marketing

AUTHORIZATION Peter; GO

·     Создаем таблицу Campaigns в только что созданной схеме.

CREATE TABLE Marketing.Campaigns (

CampaignID int, CampaignDate smalldatetime, Description varchar (max)); GO

·     Предоставляем разрешение SELECT пользователю Sara на новую таблицу.

GRANT SELECT ON Marketing.Campaigns TO Sara;

GO

·     Объявляем схему Marketing схемой по умолчанию для пользователя Sara

ALTER USER Sara

WITH DEFAULT_SCHEMA=Marketing;

Управление доступом к таблицам и столбцам.

Таблица и столбцы хранят данные, которые извлекают и создают приложения. Управление доступом к этим данных осуществляется через иерархию разрешений SQL Server 2005. Управлять этой иерархией разрешений можно при помощи инструкций GRANT, DENY и REVOKE.

GRANT. Разрешает роли или пользователю выполнять операции, определенные в момент предоставления разрешения.

DENY. Запрещает пользователю или роли определенные разрешения и предотвращает наследование этих разрешений от других ролей..

REVOKE. Отзывает ранее запрещенные или предоставленные разрешения.

Изменение прав доступа к таблице.

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

Таблица 9.

Разрешения на доступ к таблице

Предоставляем доступ к таблице.

Доступ пользователям базы данных и ролям можно предоставить с помощью инструкции GRANT. В следующем примере разрешения SELECT, INSERT иUPDATE на таблицу Sales.Customer предоставляются пользователю Sara (код для управления доступом к таблицам в этом и следующих разделах имеется в файлах примеров под именем ManagingAccessToTables.sql.).

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Предоставляем пользователю Sara некоторые разрешения для таблицы Sales.Customer table.

GRANT SELECT,INSERT,UPDATE

ON Sales.Customer TO Sara;

Ограничиваем доступ к таблице.

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

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Отзываем разрешение SELECT на таблицу Sales.Customer у Sara.

REVOKE SELECT

ON Sales.Customer TO Sara;

Однако пользователь может сохранить отозванное разрешение вследствие принадлежности к роли, которой предоставлено данное разрешение. В этом случае необходимо использовать инструкцию DENY, чтобы запретить доступ этому пользователю. Например:

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Запрещаем пользователю Sara разрешение DELETE на таблицу Sales.Customer. независимо от того, какие разрешения этот пользователь мог унаследовать от роли.

DENY DELETE

ON Sales.Customer TO Sara;

Предоставление доступа к отдельным столбцам.

В SQL Server 2005 есть возможность предоставить или отклонить доступ к отдельным столбцам, вместо того, чтобы работать со всей таблицей. Эта возможность предоставляет гибкость в отклонении доступа, например, к конфиденциальным данным в некоторых столбцах. Разрешения, которыми можно управлять для столбцов таблицы, перечислены в табл. 10.

Таблица 10.

Разрешения для столбцов

Предоставляем доступ к столбцам.

Доступ к отдельным столбцам можно предоставить с помощью инструкции GRANT. В следующем примере разрешения SELECT и UPDATE предоставляются пользователю Sara на столбцы Demographics и Modified Date таблицы Sales.Individual. (Код для управления доступом к столбцам таблицы в этом и следующих разделах имеется в файлах примеров под именем ManagingAccessToColumns. sql.)

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Предоставляем разрешения SELECT и UPDATE пользователю Sara на определенные столбцы таблицы Sales.Individual

GRANT SELECT,UPDATE 

(Demographics, ModifiedDate) ON Sales.Individual TO Sara;

Отзываем доступ к столбцам.

Аналогично, можно отозвать доступ к отдельным столбцам при помощи инструкции REVOKE. Не забывайте, что если нужно не допустить получения пользователем разрешения, необходимо использовать инструкцию DENY.

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Отзываем ранее предоставленные или запрещенные разрешения на столбец Demographics для пользователя Sara.

REVOKE UPDATE (Demographics)

ON Sales.Individual TO Sara;

Управление доступом к программируемым объектам.

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

Управление безопасностью для хранимых процедур.

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

Таблица 11.

Разрешения для хранимых процедур

Выполняем хранимую процедуру.

Когда приложение совершает вызов для выполнения хранимой процедуры, SQL Server проверяет, имеет ли текущий пользователь базы данных разрешение EXECUTE для этой хранимой процедуры. В следующем примере разрешение EXECUTE для хранимой процедуры dbo.uspGetBillOfMaterialsпредоставляется пользователю Sara. (Код в этом и следующих разделах можно найти в файлах примеров под именемManagingAccessToProgrammableObjects.sql.)

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Предоставляем пользователю Sara разрешение EXECUTE для хранимой процедуры.

GRANT EXECUTE On dbo.uspGetBillOfMaterials TO Sara;

Аналогично, если вам нужно не допустить выполнение каким-либо пользователем хранимой процедуры, вы можете отозвать (REVOKE) или запретить (DENY) разрешение EXECUTE для этого пользователя.

Управление безопасностью определяемых пользователем функций.

Определяемые пользователем функции - это программируемые объекты, как и хранимые процедуры. Существует два основных вида определяемых пользователем функций: функции, возвращающие скалярное значение, которые возвращают одно значение, и функции, которые возвращают табличное значение. В зависимости от типа определяемой пользователем функции, вам придется предоставить одно из двух разрешений - EXECUTE илиSELECT (см. табл. 12).

Таблица 12.

Разрешение для определяемых пользователем функций

Выполняем функции, возвращающие табличное значение.

Когда пользователь выполняет функцию, возвращающую табличное значение, SQL Server проверяет, имеет ли этот пользователь разрешение SELECT для данной таблицы. Эти разрешения для функции можно предоставить тем же способом, каким предоставляется разрешение SELECT для таблиц. В следующем примере пользователю Sara предоставляется разрешение SELECT на определяемую пользователем функциюdbo.ufnGetContactInformation.

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Предоставляем Sara разрешение на выполнение пользовательской функции.

GRANT SELECT ON dbo.ufnGetContactInformation TO Sara;

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

Выполняем функцию, которая возвращает скалярное значение.

Для выполнения функции, возвращающей скалярное значение, пользователю необходимо иметь разрешение EXECUTE для этой функции. РазрешениеEXECUTE для функции, возвращающей скалярное значение, предоставляется тем же способом, что и разрешение EXECUTE для хранимой процедуры. В следующем примере пользователю Sara предоставляется разрешение EXECUTE для функции dbo.ufnGetStock.

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Предоставляем Sara разрешение на выполнение пользовательской функции.

GRANT EXECUTE ON dbo.ufnGetStock TO Sara;

Управление безопасностью для сборок.

SQL Server 2005 предоставляет возможность включать сборки .NET (объекты, которые ссылаются на файлы.dll) в механизм базы данных и вызывать эти сборки в хранимых процедурах и функциях. Для сборок можно задать те же разрешения, что и для хранимых процедур. Смотрите список разрешений в табл. 11.

Определяем набор разрешений.

Для создания сборки вам необходимо определить набор разрешений. Этот набор разрешений определяет набор разрешений на доступ к коду, который предоставляется сборке в SQL Server. Существует три различных набора разрешений:

·     SAFE. Код, выполняемый сборкой, не может обращаться к внешним системным ресурсам. SAFE - это самый ограничительный набор разрешений, который установлен по умолчанию..

·     EXTERNAL_ACCESS. Сборка может обращаться к внешним системным ресурсам.

·     UNSAFE. Сборка может выполнять неуправляемый код.

SAFE является рекомендуемым набором разрешений для сборок, которые не нуждаются в доступе к внешним ресурсам.

Дополнительная информация. Дополнительную информацию о безопасности доступа кода можно получить по следующей ссылке: http://msdn.microsoft.com/library/default.asp?url=/ library/en-us/secmod/html/ secmod116.asp.

Выполняем сборку.

Когда приложение пытается обратиться к объекту внутри сборки, механизм базы данных проверяет, имеет ли текущий пользователь разрешениеEXECUTE. Следующий код используется для предоставления разрешения EXECUTE для сборки пользователю Sara.

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Предоставляем пользователю Sara разрешение на выполнение сборки.

GRANT EXECUTE ON <AssemblyName>

TO Sara;

Предоставляя разрешение EXECUTE для сборки, вы предоставляете пользователю разрешение EXECUTE для всех объектов сборки.

Управление цепочками владения.

Цепочка владения - это последовательность объектов базы данных, которые обращаются друг к другу. Например, когда вы добавляете в таблицу строку из хранимой процедуры, то хранимая процедура является вызывающим объектом, а таблица - вызываемым объектом. Когда SQL Server обходит цепочку, механизм базы данных оценивает разрешения по-другому, не так, как если бы вы обращались к объектам по отдельности.

При обращении к объекту в цепочке, SQL Server сначала сравнивает владельца вызываемого объекта и владельца вызывающего объекта. Если у объектов один владелец, то разрешения вызываемого объекта не оцениваются. Эта функция очень полезна для управления разрешениями объектов. Предположим, например, что Sara создает таблицу с именем Person.SupplierContacts и хранимую процедуру Person.InsertSupplierContacts, c помощью которой Sara добавляет строки в таблицу PersonSupplierContacts. Поскольку у этих объектов один владелец, Sara, то для того, чтобы предоставить другим пользователям разрешение EXECUTE для таблицы PersonSupplierContacts, достаточно предоставить разрешение EXECUTE на хранимую процедуру Person.InsertSupplierContacts. Нет необходимости предоставлять другим пользователям разрешения для таблицы.

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

Управление контекстом выполнения.

Имя входа и пользователь, подключившиеся на время сеанса или выполняющие процедуру, определяют контекст выполнения. Маркеры имени входа и пользователя предоставляют SQL Server информацию, необходимую для оценки разрешений объектов. SQL Server 2005 предоставляет возможность изменить контекст выполнения при помощи инструкции EXECUTE AS. Эта операция называется переключением контекста.

Выполняем инструкцию EXECUTE AS.

Инструкция EXECUTE AS позволяет явно определить контекст выполнения для текущего соединения. EXECUTE AS можно использовать для того, чтобы изменить имя входа пользователя для текущего соединения. Изменение контекста выполнения действительно до тех пор, пока не будет сделано другое изменение контекста, или пока не будет закрыто подключение или выполнена инструкция REVERT. В следующем примере инструкция EXECUTE ASиспользуется для изменения контекста выполнения на пользователя Sara.

·     Изменяем контекст соединения на базу данных AdventureWorks.

USE AdventureWorks;

GO

·     Изменяем контекст выполнения на пользователя Sara.

EXECUTE AS USER='Sara';

·     Следующая инструкция будет выполнена с учетными данными пользователя Sara.

TRUNCATE TABLE dbo.ErrorLog;

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

·     Снова изменяем контекст выполнения, возвращая его к исходному состоянию REVERT;

·     Теперь следующая инструкция будет выполнена в исходном контексте выполнения.

TRUNCATE TABLE dbo.ErrorLog;

Управляем переключением контекста.

Кроме управления контекстом выполнения для пакетов (групп инструкций T-SQL, отправленных серверу на выполнение, как в примере TRUNCATE TABLE, рассмотренном выше), можно управлять контекстом выполнения для хранимых процедур и пользовательских функций. Переключая контекст в этих модулях, вы можете управлять тем, какая учетная запись пользователя будет использоваться для доступа к объекту, на который ссылается хранимая процедура или функция. Для выполнения этой задачи можно использовать инструкцию EXECUTE AS со следующими изменениями:

·     CALLER. Инструкции внутри хранимой процедуры или функции, определяемой пользователем, выполняются в контексте вызывающей программы модуля.

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

·     OWNER. Инструкции выполняются в контексте текущего владельца хранимой процедуры или функции.

·     <User>or< Login >. Инструкции выполняются в контексте определенного пользователя или имени входа.

В следующем примере создается хранимая процедура, которая переключает контекст на пользователя dbo. Затем она предоставляет разрешениеEXECUTE для хранимой процедуры и изменение контекста выполнения хранимой процедуры пользователю Sara.

·     Создаем хранимую процедуру для выполнения инструкций -' в контексте dbo.

CREATE PROCEDURE dbo.usp TruncateErrorLog

WITH EXECUTE AS «dbo»

AS

TRUNCATE TABLE dbo.ErrorLog;

GO

·     Предоставляем разрешения на выполнение процедуры пользователю Sara.

GRANT EXECUTE ON dbo.usp_TruncateErrorLog TO Sara

·     Изменяем контекст выполнения этого пакета на пользователя Sara.

EXECUTE AS [USER=]'Sara'

·     Выполняем хранимую процедуру.

EXECUTE dbo.usp_TruncateErrorLog

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

Заключение.

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

После того, как физический доступ настроен, следует разрешить пользователям устанавливать соединение с экземпляром SQL Server. Эту задачу можно выполнить, создав имена входа для пользователей и групп Windows и имена входа SQL Server. Прежде чем сделать это, выберите метод проверки подлинности, который будет использоваться системой.

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

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

Доступ к объектам базы данных контролируется различными способами, в зависимости от типа объекта. Эти разрешения могут применяться к отдельным пользователям или ролям базы данных, которые могут быть фиксированными или создаваться при необходимости для удовлетворения требований бизнеса.

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

Управление контекстом выполнения также предоставляет способ разрешить пользователям выполнять операции, которыми нельзя управлять через разрешения.

Краткий справочник

CREATE LOGIN [<domain>\<user>] FROM WINDOWS;

CREATE LOGIN <user> 

  WITH PASSWORD = «<password>«, 

       DEFAULT_DATABASE =<database>;

CREATE LOGIN <user> 

  WITH PASSWORD = «<password>« MUST_CHANGE, 

  CHECK_EXPIRATION = ON, 

  CHECK_POLICY          = ON;

GRANT ALTER <permission> TO <user>;

DROP LOGIN <user>;

EXECUTE sp_change_users_login @Action='Report';

GRANT CONNECT TO Guest;

Тема 7. Методы аварийного восстановления для защиты базы данных

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

·     Неисправности аппаратного обеспечения.

·     Вирусы.

·     Некорректное использование инструкций UPDATE и DELETE.

·     Ошибки программного обеспечения.

·     Аварийные ситуации, например, пожар или затопление.

Чтобы избежать потери данных, можно реализовать для базы данных стратегию восстановления. Стратегию восстановления необходимо спланировать, реализовать и протестировать с учетом возможных неисправностей, с которыми можно встретиться в процессе работы системы, и необходимого уровня защиты данных. В витринах данных, то есть в случаях, когда данные можно восстановить из других систем, вероятно, нет необходимости создавать резервные копии каждой отдельной транзакции. Возможно, будет достаточно выполнять полное резервное копирование данных с регулярными временными интервалами. И наоборот, для базы данных, в которой хранятся транзакции интернет-магазина, возможно, будет необходимо сохранять резервные копии каждой отдельной транзакции. СУБД SQL Server предоставляет полный комплекс функций для реализации именно того вида резервного копирования, который вам необходим. В данной лекции рассматриваются наиболее широко используемые в Microsoft SQL Server стратегии для защиты данных.

Полное резервное копирование базы данных.

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

Полная резервная копия базы данных содержит все данные и метаинформацию базы данных, которые необходимы для восстановления базы данных полностью, включая полнотекстовые каталоги. При восстановлении базы данных из полной резервной копии восстанавливаются все файлы базы данных, причем данные извлекаются в непротиворечивом состоянии на тот момент времени, в который выполнялось резервное копирование. Пока выполняется резервное копирование, база данных работает в рабочем режиме, и пользователь может выполнять транзакции, изменяя данные обычным путем. Термин «непротиворечивое состояние» означает, что все транзакции, которые были зафиксированы в процессе выполнения резервного копирования базы данных, применяются, а все транзакции, которые не были завершены, подвергаются откату. Для ситуаций, которые могли бы привести к нарушению непротиворечивости данных вследствие выполнения транзакций, изменяющих данные в процессе выполнения резервного копирования, в SQL Server есть особый процесс, который позволяет гарантировать непротиворечивость данных. Этот процесс выполняет запись на устройство резервного копирования как страниц данных, так и журнала транзакций.

Совет. Полнотекстовые каталоги были введены в базы данных, чтобы добавить в SQL Server функции полнотекстового индексирования. Полнотекстовое индексирование позволяет быстрее и с большей точностью осуществлять поиск данных в базе данных. Дополнительную информацию о полнотекстовом индексировании см. в Электронной документации по SQL Server в разделе «Полнотекстовые индексы».

Скорость резервного копирования определяется скоростью используемых устройств ввода/вывода (тех устройств ввода вывода, которые используются для сбора и хранения информации). Чтобы добиться наилучшей производительности, SQL Server считывает файлы последовательно. Если ваши устройства ввода/вывода способны одновременно обрабатывать данные ввода/вывода резервного копирования и данные ввода/вывода, поступающие в результате обычного использования системы, то создание резервной копии окажет на производительность системы незначительное воздействие. Тем не менее, лучше выполнять полное резервное копирование базы данных при отсутствии пиковых нагрузок.

В следующем разделе мы рассмотрим варианты реализации этой стратегии резервного копирования.

Простая модель восстановления.

Следует заранее уведомить SQL Server о том, какой тип резервного копирования вы намерены использовать, поэтому надо сконфигурировать базу данных так, чтобы настройки соответствовали выбранному вами типу резервного копирования. Такая настройка выполняется посредством выбора значения параметра «модель восстановления базы данных». Модель восстановления базы данных, которая используется по умолчанию, является производным от модели восстановления модели базы данных, определенной при ее создании. Чтобы реализовать стратегию резервного копирования, которая будет включать только полные резервные копии, следует выбрать простую модель восстановления (SIMPLE).

Выбираем модель восстановления SIMPLE.

1.  В меню Start (Пуск) выберите All Programs,. Microsoft SQL Server 2005, SQL Server Management Studio (Все программы, Microsoft SQL Server 2005, Среда SQL Server Management Studio).

2.  В диалоговом окне Connect To Server (Соединение с сервером) нажмите кнопку Connect (Соединить).

3.  В панели инструментов Standard (Стандартная) нажмите кнопку New Query (Новый запрос), чтобы открыть окно New Query (Новый запрос).

4.  Чтобы задать модель восстановления, можно использовать инструкцию ALTER DATABASE. Введите текст следующей инструкции и нажмите кнопку Execute (Выполнить).

USE master;

GO

ALTER DATABASE AdventureWorks

SET RECOVERY SIMPLE;

GO

Дополнительная информация. В этой лекции рассматривается, главным образом, создание резервных копий и восстановление с помощью инструкций SQL. В лекциях 6-7 будет рассмотрено выполнение многих из этих же процедур не через инструкции T-SQL, а с помощью интерфейса пользователя SQL Server Management Studio.

Проверяем настройки модели аварийного восстановления.

1.  Чтобы просмотреть заданную для базы данных модель восстановления, можно использовать функцию DATABASEPROPERTYEX, которая извлекает параметры текущей базы даты или свойства указанной базы данных. Выполните инструкцию, приведенную ниже, чтобы извлечь информацию о модели восстановления базы данных AdventureWorks.

SELECT DATABASEPROPERTYEX('AdventureWorks','Recovery')

2.  Убедитесь, что в результатах запроса указана модель восстановления SIMPLE.

3.  Закройте окно среды SQL Server Management Studio.

Устройства резервного копирования.

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

·     Ленточные устройства. Могут использоваться для хранения резервных копий на лентах. Ленточные устройства должны быть установлены локально. Резервная копия может занимать несколько лент, а на одной ленте могут находиться одновременно резервные копии SQL Server и Windows.

·     Дисковые устройства. Файлы на локальном или удаленном диске или дисковом накопителе. К этим файлам обращаются, указывая путь к файлу, в котором хранится резервная копия. Для обращения к удаленным хранилищам следует использовать путь в формате UNC.

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

Устройства резервного копирования идентифицируются по имени устройства. В качестве имени устройства может использоваться имя логического или физического устройства. Имя физического дискового устройства представляет собой путь к файлу резервной копии, например,»\\BACKUPSERVER\Backups\adv\AdventureWorks.bak». Этот путь можно включить непосредственно в инструкцию резервного копирования. Имя логического устройства представляет собой имя, указывающее на имя физического устройства резервного копирования и хранящееся в SQL Server. Когда в инструкции резервного копирования используется имя логического устройства, SQL Server осуществляет поиск соответствующего физического устройства в системном каталоге и выполняет резервное копирование, сохраняя резервную копию в указанной папке.

Чтобы добавить в системный каталог логическое устройство, можно использовать хранимую процедуру sp_addumpdevice. В следующем примере определяется логическое устройство с именем Adv_FullDb_Dev.

EXEC sp addumpdevice «disk», «AdvFullDbDev», «T:\BACKUPS\AdvFullDbDev.bak»;

Совет. Обязательно измените путь к файлу, чтобы он соответствовал вашему компьютеру. Т:/, то измените эту часть пути к файлу в инструкции так, чтобы он соответствовал букве диска на вашем компьютере. Кроме того, убедитесь в том, что все папки, заданные в этом пути, существуют на вашем компьютере.

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

Никогда не следует выполнять резервное копирование на дисковое устройство, которое размещается на том же физическом устройстве хранения, что и сама база данных. Даже если дисковое хранилище отличается устойчивостью против сбоев благодаря наличию RAID, всегда существует возможность возникновения неисправности контроллера и повреждения данных на дисках. Кроме того, следует подумать о сохранении файлов резервной копии устройства резервного копирования на лентах и хранении этих лент в удаленном месте.

Совет. Сокращение RAID происходит от выражения «redundant array of independent disks» (избыточный массив недорогих дисков). Такие массивы представляют собой системы дисков с несколькими приводами, которые используются для повышения доступности и емкости хранилища.

Выполнение полного резервного копирования базы данных.

После того, как вы установили модель резервного копирования на SIMPLE и решили, на каком устройстве резервного копирования сохранять резервные копии, можно приступить к выполнению резервного копирования. Полное резервное копирование базы данных выполняется с помощью довольно простой инструкции BACKUP DATABASE. В простейшей форме нужно только указать системе, резервную копию какой базы данных создать и на каком устройстве ее сохранить. Чтобы создать резервную копию базы данных AdventureWorks на предварительно выбранном логическом устройстве, используется следующая инструкция T-SQL:

USE master;

GO

BACKUP DATABASE AdventureWorks

TO Adv_FullDb_Dev;

Если надо выполнить полное резервное копирование базы данных на физическое устройство, необходимо указать тип устройства и место размещения резервной копии в инструкции BACKUP DATABASE. Чтобы создать резервную копию базы данных в папке t:\adv.bak, используйте следующую инструкцию:

USE master;

GO

BACKUP DATABASE AdventureWorks

TO DISK='t:\adv.bak';

Как уже говорилось, на любом устройстве резервного копирования может храниться больше одной резервной копии. В аргументе инструкции BACKUP DATABASE можно указать, следует ли SQL Server перезаписать существующую резервную копию на этом устройстве или дописать ее к существующим резервным копиям. Для этого используются ключевые слова INIT или NOINIT. Если указать INIT, то перед запуском резервного копирования устройство резервного копирования форматируется, при этом удаляются все резервные копии, которые имеются на этом устройстве. NOINIT, которое используется по умолчанию, если не указано иное, разрешает SQL Server дописать резервную копию на существующее устройство резервного копирования с сохранением всех существующих на нем резервных копий. Эти опции устанавливаются при помощи блока WITH в конце инструкции BACKUP DATABASE.

Если нужно создать такую же резервную копию, как в предыдущем примере, но при этом указать SQL Server сначала очистить устройство, используйте следующую инструкцию:

USE master;

GO

BACKUP DATABASE AdventureWorks

TO DISK='t:\adv.bak'

WITH INIT;

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

Разностное резервное копирование.

Главное преимущество полного резервного копирования базы данных заключается в том, что в полной резервной копии содержатся все данные, которые необходимы для восстановления базы данных полностью. Но это преимущество может одновременно быть и недостатком. Представьте себе базу данных, для которой каждую ночь создается резервная копия. Если придется восстанавливать базу данных, в любом случае придется использовать резервную копию, созданную прошлой ночью, и в результате будут потеряны результаты работы за целый день. Один из способов уменьшить потенциальный промежуток времени, который может быть не учтен резервным копированием является более частое выполнение полного резервного копирования базы данных. Но это само по себе является проблематичным. Поскольку все данные и фрагменты журнала транзакций записываются на устройство резервного копирования, выполнение резервного копирования может отнимать слишком много времени. Кроме того, для хранения всех этих резервных копий необходимо много дискового пространства h° , а полное резервное копирование может снизить производительность базы данных в результате потребности в большом объеме операций ввода/вывода. Не лучше ли будет один раз выполнить резервное копирование ночью, а затем выполнять резервное копирование только тех данных, которые были изменены в течение дня? Такие функциональные возможности предоставляет разностный тип резервного копирования.

Разностное резервное копирование сохраняет только те изменения данных, которые произошли после создания полной резервной копии. Если одни и те же данные с момента создания полной резервной копии изменялись несколько раз, то разностное резервное копирование сохраняет самую последнюю версию измененных данных. Для восстановления данных из разностной резервной копии придется сначала восстановить данные полной резервной копии, а после этого применить только последнюю из разностных резервных копий, как показано на рис. 9.

Рис. 9. Стратегия резервного копирования с использованием разностных резервных копий

Выполнение разностного резервного копирования.

Выполнение разностного резервного копирования мало чем отличается от выполнения полного резервного копирования. Единственное отличие заключается в том, что в блоке WITH объявляются инструкции по создании разностной резервной копии. Синтаксис инструкции BACKUP DATABASE для выполнения резервного копирования базы данных Adventure Works на физическое устройство с перезаписью других существующих резервных копий на этом устройстве будет таким:

USE master;

GO

BACKUP DATABASE AdventureWorks

TO DISK='t:\adv_diff.bak'

WITH INIT,DIFFERENTIAL;

Если вы хотите использовать логическое устройство, то следует сначала создать его, как и в случае полного резервного копирования.

USE master;

GO

EXEC sp_addumpdevice «disk», «Adv_Diff_Dev»,

«T:\BACKUPS\AdvDiffDev.bak»;

GO

BACKUP DATABASE AdventureWorks

TO Adv_Diff_Dev

WITH INIT,DIFFERENTIAL;

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

Резервное копирование журнала транзакций.

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

·     Резервное копирование журнала транзакций позволяет восстановить данные на определенный момент времени.

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

Как и в случае с разностными резервными копиями, для восстановления базы данных из резервных копий журнала транзакций в стратегии восстановления необходима базовая полная резервная копия базы данных. Стратегия резервного копирования с использованием резервных копий журнала транзакций показана на рис. 10. Полные резервные копии базы данных выполняются в часы наименьшей загрузки оборудования, а резервные копии журнала транзакций выполняются в определенное время в течение дня. Резервные копии журнала транзакций содержат все транзакции, которые произошли с момента создания последней резервной копии журнала транзакций. Следовательно, чтобы восстановить базу данных с использованием резервных копий журнала транзакций, необходимы полная резервная копия базы данных и все резервные копии журнала транзакций с момента создания полной резервной копии. Как видите, важно, чтобы все резервные копии были доступны. Если полная резервная копия базы данных или одна из резервных копий журнала транзакций будут утеряны, то восстановление данных в желательном объеме будет невозможно.

Рис. 10. Стратегия резервного копирования с использованием резервных копий журнала транзакций

Комбинирование разностных резервных копий и резервных копий журнала транзакций.

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

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

Рис. 11. Комбинированная стратегия резервного копирования

Например, чтобы восстановить данные до резервной копии журнала транзакций Т3, следует восстановить данные полной резервной копии F1, разностной резервной копии D1 и резервной копии журнала транзакций Т3.

Интервал времени между созданием резервных копий журнала транзакций зависит от:

·     Количества и размера транзакций, выполняемых в базе данных. При этой стратегии резервного копирования SQL Server должен хранить все транзакции до тех пор, пока не будет сохранена резервная копия журнала транзакций. Следовательно, в файл журнала транзакций должны поместиться все транзакции, которые были выполнены за период времени между двумя последовательными резервными копированиями журнала транзакций. Если журнал заполняется слишком быстро, следует уменьшить временные интервалы между созданием резервных копий журнала транзакций или увеличить размер файла журнала транзакций.

·     Приемлемого объема потери данных. Как уже упоминалось выше, можно восстановить данные вплоть до последней транзакции, если файлы данных утрачены. Но если журнал транзакций будет поврежден или утрачен, то можно будет восстановить только данные на момент последнего резервного копирования журнала транзакций. Уменьшение временных промежутков между созданием резервных копий журнала транзакций снизит объем потерянных данных в подобной ситуации.

Тема 8. Полная модель восстановления

Как уже упоминалось ранее, необходимо заранее указать SQL Server, какую стратегию резервного копирования вы планируете реализовать. Если используются только полные и разностные резервные копии базы данных, то следует выбрать простую модель восстановления. Если нужно использовать также резервные копии журналов транзакций, то следует выбрать полную модель восстановления (FULL) или модель с неполным протоколированием BULK_LOGGED. Выбрав полную модель восстановления, мы сообщаем SQL Server, что необходимо создавать резервные копии журнала транзакций. Чтобы сделать это возможным, SQL Server сохраняет все транзакции в журнале транзакций до тех пор, пока не будет создана резервная копия журнала. При выполнении резервного копирования журнала транзакций, SQL Server выполняет усечение журнала транзакций после того, как резервная копия записана на устройство резервного копирования. В простом режиме журнал транзакций усекается после каждой контрольной точки; это означает, что зафиксированные транзакции (которые уже записаны в файлы данных) удаляются из журнала транзакций. Таким образом, в простом режиме резервные копии журнала транзакций не могут быть созданы.

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

Чтобы выбрать модель восстановления FULL, можно использовать инструкцию ALTER DATABASE. Следующий код устанавливает режим восстановления базы данных AdventurеWorks в значение FULL.

USE master;

GO

ALTER DATABASE AdventureWorks

SET RECOVERY FULL;

GO

Модель восстановления с неполным протоколированием.

В модели полного восстановления высокопроизводительные операции массового копирования (операции, которые изменяют сразу большие количества данных) полностью протоколируются, чтобы сделать возможным резервное копирование журнала транзакций. В некоторых базах данных эта модель восстановления не может использоваться регулярно из-за ограничений на размер журнала транзакций и проблемы с производительностью, которые появляются из-за полного протоколирования высокопроизводительных операций массового копирования. Логично, что, существует модель восстановления с неполным протоколированием. Она позволяет создавать резервные копии журнала транзакций для фиксации и журнала, и результатов любых высокопроизводительных операций массового копирования, но при этом не имеет указанных недостатков. В рамках модели восстановления с неполным протоколированием невозможно восстановить базу данных на определенный момент времени. Кроме того, невозможно выполнять резервное копирование журнала транзакций, когда файл данных повр ежден, а высокопроизводительная операция массового копирования может произойти после того, как резервная копия файла журнала транзакций уже была создана. Это один из основных недостатков резервного копирования журнала транзакций. Следовательно, модель восстановления с неполным протоколированием следует включать только на период выполнения высокопроизводительных операций массового копирования и, по возможности, на непродолжительное время. В остальное время следует использовать полную модель восстановления. Не используйте модель восстановления с неполным протоколированием, если у вас не возникает проблем при использовании только полностью протоколируемых операций. Дополнительную информацию можно найти в Электронной документации по SQL Server 2005, тема «Резервное копирование в модели восстановления с неполным протоколированием».

Создание резервных копий журнала транзакций.

Чтобы выполнить резервное копирование журнала транзакций, следует выбрать полную модель восстановления, причем после изменения модели восстановления должна быть создана хотя бы одна полная резервная копия базы данных. Резервное копирование журнала транзакций выполняется с помощью инструкции BACKUP LOG. Как всегда, следует указать имя базы данных и устройство резервного копирования. Типы устройств резервного копирования в этом случае не отличаются от тех, которые используются для создания полных и разностных резервных копий.

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

Создаем резервную копию файла журнала транзакций.

1.  Установите полную (FULL) модель восстановления.

2.  Создайте хотя бы одну полную резервную копию базы данных.

3.  Создайте резервную копию журнала транзакций базы данных AdventurеWorks на физическом устройстве при помощи следующей инструкции SQL:

USE master;

GO

BACKUP LOG AdventureWorks

TO DISK='t:\adv_log.bak'

Как и в других инструкциях резервного копирования, процесс дописывает резервную копию на устройство резервного копирования, если в инструкцииBACKUP не указан другой вариант. Чтобы перезаписать резервные копии на устройстве, используется инструкция WITH INIT.

USE master;

GO

BACKUP LOG AdventureWorks

TO DISK='t:\adv_log.bak'

WITH INIT

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

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

Извлечение информации резервного копирования.

Прежде, чем приступить к восстановлению базы данных, необходимо знать, какую резервную копию выбрать для восстановления. SQL Server хранит историю резервного копирования, в которой есть информация о каждой отдельной резервной копии, созданной для базы данных, в базе данных msdb. Чтобы найти нужную для восстановления резервную копию, можно выполнить запрос к базе данных msdb.

Создаем информацию простого резервного копирования.

1.  В меню Start (Пуск) выберите All Programs,. Microsoft SQL Server 2005, SQL Server Management Studio (Все программы, Microsoft SQL Server 2005, Среда SQL Server Management Studio).

2.  В диалоговом окне Connect To Server (Соединение с сервером) нажмите кнопку Connect (Соединить).

3.  В панели инструментов Standard (Стандартная) нажмите кнопку New Query (Новый запрос), чтобы открыть окно New Query (Новый запрос).

4.  Введите и выполните следующие инструкции BACKUP, чтобы создать полную и разностную резервные копии базы данных AdventurеWorks.

ALTER DATABASE AdventureWorks

SET RECOVERY SIMPLE;

·     Создаем полную резервную копию базы данных

BACKUP DATABASE AdventureWorks

TO DISK = «T:\BACKUPS\ADVFULL.BAK»

WITH INIT;

·     Создаем разностную резервную копию 

BACKUP DATABASE AdventureWorks   

TO DISK = «T:\BACKUPS\ADVDIFF.BAK» 

WITH INIT,Differential;

Получаем общую информацию резервного копирования.

1.  Чтобы получить информацию о том, какие резервные копии были созданы в базе данных AdventurеWorks, выполните следующую инструкциюSELECT:

USE msdb

GO

SELECT backup_start_date,type, physical_device_name,backup_set_id

FROM backupset bs inner join backupmediafamily bm

ON bs.media_set_id = bm.media_set_id

WHERE database_name ='AdventureWorks'

ORDER BY backup_start_date desc

Панель результатов, показанная на рисунке, сообщает, что тип самой последней резервной копии - I, что соответствует разностной копии. Как вам известно, чтобы восстановить данные из резервной копии, сначала необходимо восстановить данные из самой последней полной резервной копии. Эту резервную копию мы видим во второй строке, ее тип D указывает на то, что это полная резервная копия.

2.  Каждая резервная копия получает уникальный идентификатор, который называется идентификатором набора резервных копий; этот идентификатор можно увидеть в окне результатов, которое показано на следующем рисунке.

Рис. 12

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

SELECT filegroup_name,logical_name,physical_name

FROM msdb..backupfile

WHERE backup_set_id = 62

—change to your backup_set_id

3.  В некоторых ситуациях в базе данных msdb может не оказаться необходимой информации. Это может произойти, если база данных msdb была повреждена при аварийной ситуации или если резервное копирование выполнялось на другой системе. В этих случаях можно получить необходимую информацию только непосредственно с устройства резервного копирования. Чтобы получить информацию о резервных копиях, которые находятся на T:\BACKUPS\ADVFULL.BAK', введите и выполните следующую инструкцию.

RESTORE HEADERONLY FROM DISK='T:\BACKUPS\ADVFULL.BAK'

4.  Чтобы получить информацию о файлах данных и журналов, которые были включены в резервные копии, хранящиеся на данном устрой стве, выполните инструкцию RESTORE FILELISTONLY.

RESTORE FILELISTONLY 

FROM DISK ='T:\BACKUPS\ADVFULL.BAK'

Восстановление базы данных через интерфейс среды SQL Server Management Studio.

Во многих случаях самый простой способ восстановить базу данных – это воспользоваться интерфейсом SQL Server Management Studio. SQL Server Management Studio использует историю создания резервных копий, которая хранится в базе данных msdb, чтобы показать нам, какой способ восстановления базы данных является наилучшим.

Реализуем сценарий восстановления базы данных через интерфейс среды SQL Server Management Studio.

1.  Выполните следующие инструкции в окне запроса SQL Server Management Studio, чтобы имитировать сценарий, в котором для базы данных AdventurеWorks выбрана простая стратегия восстановления с использованием полной и разностной резервных копий. При необходимости измените пути к устройствам резервного копирования.

ALTER DATABASE AdventureWorks

SET RECOVERY SIMPLE;

·     Создаем полную резервную копию базы данных

BACKUP DATABASE AdventureWorks

TO DISK = «T:\BACKUPS\ADVFULL.BAK»

WITH INIT;

·     Имитируем выполнение транзакции

UPDATE AdventureWorks.Person.Contact

SET EmailAddress = «kim@testbackup.com»

WHERE ContactID=3;

·     Создаем разностную резервную копию

BACKUP DATABASE AdventureWorks

TO DISK = «T:\BACKUPS\ADVDIFF.BAK»

WITH INIT,Differential;

2.  Чтобы восстановить базу данных, откройте Object Explorer (Обозреватель объектов), выбрав команду Object Explorer (Обозреватель объектов) в меню View (Вид) или нажав клавишу F8.

3.  В дереве объектов разверните экземпляр SQL Server, откройте папку Databases (Базы данных) и щелкните правой кнопкой мыши на базе данных AdventurеWorks. В контекстном меню выберите команды Tasks, Restore, Database (Задачи, Восстановить, База данных).

4.  В открывшемся диалоговом окне Restore Database (Восстановление базы данных) вы увидите, что самые последние наборы резервных копий уже выбраны для восстановления, как показано на рис. 13. Чтобы завершить восстановление, просто нажмите кнопку OK.

Примечание. Убедитесь, что с базой данных AdventurеWorks не открыто ни одного соединения, поскольку в процессе восстановления соединения с базой данных не разрешены.

Рис. 13. Диалоговое окно Восстановление базы данных

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

6.  Откройте окно New Query (Новый запрос) и проверьте успешность восстановления данных из обеих резервных копий, для чего введите и выполните следующий код:

USE AdventureWorks;

GO

SELECT EmailAddress

FROM Person.Contact

WHERE ContactID =3;

В панели результатов должно отобразиться kim@testbackup.com.

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

Восстановление базы данных при простой стратегии резервного копирования с использованием T-SQL.

Представьте себе, что вы создали резервную копию, описанную в предыдущем примере. Чтобы восстановить базу данных при помощи T-SQL, используется инструкция RESTORE DATABASE. Синтаксис этой инструкции аналогичен инструкции BACKUP. Необходимо указать имя базы данных и путь к устройству резервного копирования.

Восстанавливаем данные из полной резервной копии при помощи инструкций T-SQL.

1.  В окне SQL Server Management Studio откройте окно New Query (Новый запрос).

2.  Чтобы восстановить базу данных AdventurеWorks, ведите и выполните следующую инструкцию RESTORE DATABASE. Как всегда, убедитесь, что при выполнении запросов с базой данных не установлено ни одного соединения.

USE MASTER

GO

RESTORE DATABASE AdventureWorks

FROM DISK='T:\BACKUPS\ADVFULL.BAK'

3.  Выполните следующий запрос: Теперь результат должен содержать kim2@adventureworks.com, поскольку данное обновление произошло после создания полной резервной копии.

SELECT EmailAddress

FROM AdventureWorks.Person.Contact

WHERE ContactID = 3

В процессе этой процедуры восстанавливаются только данные полной резервной копии. После восстановления база данных автоматически переводится в рабочий режим, возвращаясь к исходным параметрам. Если нужно также применить разностную резервную копию, необходимо сообщить SQL Server о том, что не следует переводить базу данных в рабочий режим до завершения полного восстановления, поскольку это сделает невозможным восстановление данных из разностной резервной копии. Для этого используется параметр NORECOVERY. Параметр NORECOVERY должен присутствовать во всех инструкциях RESTORE, за исключением последней в цикле восстановления. В следующем примере мы воспользуемся параметром NORECOVERY при восстановлении данных из полной и разностной резервных копий, выполненных ранее.

Восстанавливаем данные из разностных резервных копий при помощи инструкций T-SQL.

1.  В окне SQL Server Management Studio откройте окно New Query (Новый запрос).

2.  Чтобы восстановить базу данных AdventurеWorks с использованием параметра NORECOVERY, ведите и выполните следующую инструкцию RESTORE DATABASE.

USE MASTER

GO

RESTORE DATABASE AdventureWorks

FROM DISK='T:\BACKUPS\ADVFULL.BAK'

WITH NORECOVERY

3.  Чтобы восстановить данные из разностной копии, ведите и выполни те следующую инструкцию RESTORE DATABASE.

USE MASTER

GO

RESTORE DATABASE AdventureWorks

FROM DISK='T:\BACKUPS\ADVDIFF.BAK'

4.  Выполните следующий запрос: Результатом должно стать значение kim@testbackup.com. Поскольку это обновление было выполнено между созданием полной и разностной резервных копий, можно быть уверенным в том, что восстановление данных из разностной резервной копии прошло успешно.

SELECT EmailAddress

FROM AdventureWorks.Person.Contact

WHERE ContactID = 3

Восстановление базы данных при полной стратегии резервного копирования с использованием T-SQL.

В полной стратегии мы имеем комбинацию полной резервной копии и резервных копий журнала транзакций. Далее речь пойдет о восстановлении данных из этих резервных копий при помощи инструкций T-SQL.

Восстанавливаем данные из полной резервной копии и резервных копий журнала транзакций.

1.  Для создания резервных копий базы данных AdventureWorks выполните следующий код. Этот код также обновит некоторые данные; данное обстоятельство можно использовать для проверки успешности восстановления.

ALTER DATABASE AdventureWorks

SET RECOVERY FULL;

·     Создаем полную резервную копию базы данных

BACKUP DATABASE AdventureWorks

TO DISK = «T:\BACKUPS\ADVFULL.BAK»

WITH INIT;

·     Имитируем выполнение транзакции

UPDATE AdventureWorks.Person.Contact

SET EmailAddress = «AfterFull@test.com»

WHERE ContactID=3;

·     Создаем резервную копию журнала транзакций

BACKUP LOG AdventureWorks

TO DISK = «T:\BACKUPS\ADVLOG1.BAK»

WITH INIT;

·     Имитируем выполнение транзакции

UPDATE AdventureWorks.Person.Contact

SET EmailAddress = «AfterLog@test.com»

WHERE ContactID=3;

2.  Теперь представим себе, что файл базы данных AdventurеWorks по врежден. Как было рассмотрено выше, несмотря на это, можно создать резервную копию журнала транзакций, чтобы зафиксировать после дние записи, которые содержат транзакции, завершенные после создания последней резервной копии журнала транзакций. Для этого следует воспользоваться особым параметром NO_TRUNCATE.

·     Выполняем резервное копирование последних записей журнала транзакций:

BACKUP LOG AdventureWorks

TO DISK = «T:\BACKUPS\ADVLOG2.BAK»

WITH INIT, NO_TRUNCATE;

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