Всё для Учёбы — студенческий файлообменник
1 монета
docx

Студенческий документ № 000160 из ДГТУ (бывш. РИСХМ)

Лекция №1. Технологическая безопасность информационных систем.

1.1 Проблемы обеспечения технологической безопасности информационных систем

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

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

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

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

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

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

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

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

* конфиденциальность - засекреченная информация должна быть доступна только тому, кому она предназначена.

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

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

* от несанкционированного доступа;

* от различных типов вирусов;

* от утечки информации по каналам электромагнитного излучения и т.д.

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

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

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

* требования, предъявляемые к архитектуре ПС и БД для обеспечения безопасности ИС;

* ресурсы, необходимые для обеспечения технологической безопасности ИС;

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

* методы и средства предотвращения и снижения влияния угроз безопасности ИС со стороны дефектов программ и данных;

* оперативные методы и средства повышения технологической безопасности функционирования ПС и БД путем введения в ИС временной, программной и информационной избыточности;

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

1.2 Оперативные методы повышения безопасности функционирования программных средств и баз данных

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

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

Временная избыточность состоит в использовании некоторой части производительности ЭВМ для контроля исполнения программ и восстановления (рестарта) вычислительного процесса. Для этого при проектировании ИС должен предусматриваться запас производительности, который будет затем использоваться на контроль и повышение надежности и безопасности функционирования. Величина временной избыточности зависит от требований к безопасности функционирования критических систем управления или обработки информации и находится в пределах от 5-10% производительности до трех-четырехкратного дублирования в мажоритарных вычислительных комплексах.

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

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

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

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

* при искажениях программ и данных в памяти ЭВМ;

* при перегрузках по производительности.

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

* игнорирование обнаруженного искажения вследствие слабого влияния на весь процесс функционирования и выходные результаты;

* исключение сообщения из обработки вследствие его искажения или трудности предстоящего восстановления вычислительного процесса;

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

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

* перестройка режима работы или структуры ИС для снижения влияния перегрузки или в связи с потерей информации о ходе процесса обработки данных и управления;

* переход на резервную ЭВМ с накопленной информацией о ходе процесса управления или восстановление информации за счет ее дублирования;

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

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

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

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

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

Лекция №2. Администрирование БД

2.1 Администраторы БД

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

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

1. Анализ предметной области: описание предметной области, выявление ограничений целостности, определение статуса информации, определение потребностей пользователей, определение статуса пользователей, определение соответствия "данные - пользователь", определение объемно-временных характеристик обработки данных.

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

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

4. Первоначальная загрузка и ведение базы данных: разработка технологии первоначальной загрузки и ведения (изменения, добавления, удаления записей) БД, проектирование форм ввода, создание программных модулей, подготовка исходных данных, ввод и контроль ввода.

5. Защита данных от несанкционированного доступа:

- обеспечение парольного входа в систему: регистрация пользователей, назначение и изменение паролей;

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

- тестирование средств защиты данных;

- фиксация попыток несанкционированного доступа к информации;

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

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

7. Обеспечение восстановления БД: разработка программно-технологических средств восстановления БД, организация ведения системных журналов.

8. Анализ обращений пользователей к БД: сбор статистики обращений пользователей к БД, ее хранение и анализ (кто из пользователей, к какой информации, как часто обращался, какие выполнял операции, время выполнения запросов, анализ причин безуспешных (в т.ч. и аварийных) обращений к БД.

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

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

11. Подготовка и поддержание системных программных средств: сбор и анализ информации о СУБД и других прикладных программ, приобретение программных средств, их установка, проверка работоспособности, поддержание системных библиотек, развитие программных средств.

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

2.2 Управление данными в БД

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

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

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

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

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

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

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

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

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

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

Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

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

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

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

Лекция №3. Критерии защищенности БД

3.1 Оценка безопасности БД

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

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

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

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

* целостность (непротиворечивость информации, ее защищенность от разрушения и несанкционированного изменения);

* конфиденциальность (защита от несанкционированного прочтения).

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

Критерии оценки безопасности компьютерных систем.

С 1983 по 1988 год Министерство обороны США и Национальный комитет компьютерной безопасности разработали систему стандартов в области компьютерной безопасности, которая включает более десяти документов. Этот список возглавляют "Критерии оценки безопасности компьютерных систем", которые по цвету обложки чаще называют "Оранжевой книгой". В 1995 году Национальный центр компьютерной безопасности США опубликовал "Пояснения к критериям безопасности компьютерных систем", объединившие все имеющиеся на тот момент дополнения и разъяснения к "Оранжевой книге".

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

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

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

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

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

3.2 Реализация политики безопасности баз данных

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

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

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

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

* Описания правил протоколирования и аудита для анализа функционирования сервиса безопасности.

* Обеспечение доступности коммуникационных каналов.

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

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

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

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

* произвольное управление доступом;

* безопасность повторного использования объектов;

* метки безопасности;

* принудительное управление доступом.

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

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

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

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

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

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

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

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

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

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

* совершенно секретно;

* секретно;

* конфиденциально;

* несекретно.

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

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

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

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

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

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

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

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

3.3 Принципы защиты информации от несанкционированного доступа

Защита любой автоматизированной системе основывается на нескольких основополагающих принципах защиты:

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

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

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

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

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

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

Лекция №4. Механизмы обеспечения целостности СУБД

4.1 Поддержание целостности в БД

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

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

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

* Запрет на обновление.

* Ограничение целостности по моменту контроля .

* Ограничение целостности по режиму проверки корректности БД

* Ограничение целостности по необходимости описания.

* Ограничение целостности служебной информации.

* Информационная целостность банка данных.

Особенности логической и физической целостности баз данных

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

4.2 Ссылочная целостность в РСУБД

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

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

Синтаксис SQL для определения ссылочной целостности выглядит, по существу, подобно следующему. Слова из прописных буква обозначают ключевые слова. Квадратные скобки выделяют необязательные параметры. Столбцы внешнего ключа находятся в таблице table1, а столбцы первичного ключа (или другой комбинации столбцов со свойством уникальности значений) - в таблице table2.

ALTER TABLE tableName1

ADD CONSTRAINT constraintName

FOREIGN KEY (columnList)

REFERENCES tableName2 [(columnList)]

[onDeleteAction] [onUpdateAction];

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

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

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

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

Set default. Можно потребовать, чтобы при удалении записи во внешний ключ устанавливалось значение по умолчанию, а не неопределенное значение.

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

SQL Server. В SQL Server 2000 внешний ключ может ссылаться на первичный ключ или на комбинацию столбцов со свойством уникальности. Не поддерживаются опции set null и set default. Однако опции cascade и no action поддерживаются полностью, и на практике этого часто оказывается достаточно. Заметим также, что синтаксис для no action отличается от стандарта SQL. В SQL Server при отсутствии явного указания ссылочного действия подразумевается no action.

Oracle. В Oracle 10g внешний ключ также может ссылаться на первичный ключ или на комбинацию столбцов со свойством уникальности. В Oracle поддерживаются ссылочные действия при удалении записей, но отсутствуют действия при модификации. Для действий при удалении поддерживаются опции cascade, no action и set null. Поддержка опции set default отсутствует. Как и в SQL Server, синтаксис no action отличается от стандарта SQL. При отсутствии явного указания ссылочного действия подразумевается no action.

MySQL. Поддержка ссылочной целостности появилась в MySQL 5.0 (при использовании InnoDB). В MySQL стандарт SQL поддерживается в более полном объеме, чем в SQL Server и Oracle. Поддерживаются варианты on delete и on update со всеми четырьмя ссылочными действия. В MySQL требуется, чтобы для внешнего ключа и ключа, на который ведет ссылка, поддерживались индексы базы данных - это хороший обычай, которому мы советуем следовать.* Столбцы, на которые ведет ссылка, могут быть первичным ключом или комбинацией столбцов со свойством уникальности.

MS-Access. В MS-Access команды SQL для определения ссылочной целостности поддерживаются только частично, но средство графического связывания является более сильным. С помощью графического интерфейса можно определить ссылочную целостность, а также ссылочные действияcascade и no action.

Лекция №5. Методы и механизмы обеспечения конфиденциальности информации в системах баз данных

5.1 Конфиденциальность данных

Конфиденциальность - это свойство информации быть известной только допущенным и прошедшим проверку (авторизованным) пользователям.

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

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

Наиболее широкое распространение в СУБД получила дискреционная модель управления доступом. В дискреционной модели все сущности системы подразделяются на субъекты доступа и объекты доступа. Правила доступа описываются в виде троек .

Субъектами доступа в СУБД являются учетные записи и пользователи БД.

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

* Программа-клиент запрашивает у конечного пользователя имя и пароль.

* Введенные имя и пароль отправляются на сервер СУБД.

* СУБД ищет в системном каталоге пару "имя-пароль", совпадающую с парой, полученной от клиента.

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

Какими правами доступа наделяется учетная запись?

Базовыми для учетной записи являются:

* право на установку соединения с сервером:

* право просмотра списка имеющихся на сервере БД:

* право быть отображенной на пользователя той или иной БД.

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

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

5.2 Пользователи СУБД

К числу типов доступа пользователей к объектам БД относятся:

* добавление, удаление, модификация и выборка строк из таблицы, представления;

* запуск хранимой процедуры:

* создание, модификация и удаление объектов БД:

* выполнение некоторого набора команд SQL.

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

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

1. На уровне СУБД:

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

б) учетные записи наделяются основными и дополнительными разрешениями на использование сервисов СУБД.

2. На уровне БД:

а) выполняется идентификация пользователя - проверяется, есть ли в БД пользователь, соответствующий данной учетной записи;

б) пользователи наделяются правами доступа к объектам БД.

Что касается назначения прав доступа, традиционным способом здесь является назначение их субъекту "напрямую": субъект S наделяется правами R к объекту О. Однако возможны ситуации, когда целая группа субъектов должна получить множество одинаковых прав. Чтобы избежать непосредственного назначения одинаковых прав каждому субъекту, целесообразно использовать механизм ролей.

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

Различают серверные роли, используемые для группирования учетных записей, и роли БД, - для группирования пользователей БД.

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

Управление правами доступа включает разрешение, запрещение и неявное отклонение доступа.

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

Запрещение доступа пользователя (роли) к объекту гарантирует, что пользователь (роль) никакими средствами не получит возможность выполнять запрещенные операции над данным объектом. Если некоторому пользователю User1 запретить выборку данных из таблицы Таblе1, то он не сможет ее производить, даже если он включен в роль, которой эта выборка разрешается. Запрещение прав доступа может каскадироваться. Допустим, имеется пользователь User1, которому было дано некоторое разрешение доступа, и который передавал это разрешение пользователям User1,..., UserN, При замене этого разрешения на данный запрет с применением каскадирования запрещение будет распространено как на User1, так и на User2,..., UserN. Каскадирование не является обязательным, но в некоторых случаях может оказаться полезным.

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

5.3 Ролевое разделение прав и иерархия пользователей

В ролевой модели классическое понятие субъекта разделяется на 2 части:

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

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

Ролевая модель включает 3 компонента, модель отображения:

* Пользователь-роль

* Привилегия-роль

* Роль-роль

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

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

Роль не является объектом какой-либо схемы. Описание привилегий, характерных для той или иной роли, готовится заранее; при регистрации нового пользователя администратор выполняет только предоставление пользователю привилегий конкретной роли.

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

Для работы с ролями в Oracle предусмотрены следующие системные привилегии:

* Create role

* Grant any role - позволяет назначать любую роль любому пользователю

* Drop any role - позволяет уничтожать любую роль

* Alter any role - позволяет менять любую роль

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

Существует 3 предопределенные роли:

* CONNECT - гость

* RESOURCE - пользователь

* DBA - all inclusive

Иерархия прав доступа.

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

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

* Посетитель Web-узла: только SELECT.

* Участник разработки: SELECT, INSERT и, возможно, UPDATE.

* Редактор содержимого узла: SELECT, INSERT, UPDATE, возможно, DELETE и, возможно, GRANT.

* Пользователь root: SELECT, INSERT, UPDATE, DELETE, GRANT И DROP.

Лекция №6. Механизмы разграничения доступа

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

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

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

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

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

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

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

Представление (view) - это сформированная выборка кортежей (последовательность полей, для которых определены значение и тип), хранящихся в таблице (таблицах). К представлению может обращаться так и к таблице, за исключением операций модификации данных, поскольку некоторые типы представлений являются немодифицируемыми. Часто в реализациях view хранится текст, описывающий запрос выборки, а не собственно выборка данных; выборка же создается динамически на момент выполнения предложения SQL, использующего view. Но разграничить доступ, например, к двум документам, кот удовлетворяют 1 и тому же условию выборки, уже нельзя. Это связано с тем, что даже если ввести отдельный атрибут, кот будет хранить информацию о метке конфиденциальности документа, то средствами SQL можно будет получить выборку данных без учета атрибута данной метки. Это значит, что либо сам сервер БД должен предоставить более высокий уровень защиты информации, либо придется реализовать данный уровень защиты информации с помощью жесткого ограничения операций, которые пользователь может выполнить посредством SQL. На некотором уровне такое разграничение может реализовать с помощью хранимых процедур, но не полностью - в том смысле, что само ядро СУБД позволяет разорвать связь "защищаемый объект-метка конфиденциальности".

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

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

Мандатная защита.

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

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

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

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

Самое важное достоинство заключается в том, что пользователь не может полностью управлять доступом к ресурсам, которые он создаёт.

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

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

Представления.

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

Для работы с представлениями предусмотрены системные привилегии create any view, create view, drop any view, а та же объектные привилегии select, insert, update, delete.

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

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

Дискреционная защита.

В современных СУБД достаточно развиты средства дискреционной защиты.

Дискреционное управление доступам (discretionary access control) - разграничение доступа между поименованными субъектами и поименованными объектами. Субъект с определенным правом доступа может передать это право любому другому субъекту.

Дискреционная защита является многоуровневой логической защитой.

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

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

CONNECT [[logon] [AS {SYSOPER|SYSDBA}]] пользователь/пароль[@база_данных]

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

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

6.2 Метки безопасности

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

Каждый пользователь СУБД INGRES/Enhanced Security характеризуется степенью благонадежности, которая также определяется меткой безопасности, присвоенной данному пользователю. Пользователь может получить доступ к данным, если степень его благонадежности удовлетворяет требованиям соответствующей метки безопасности:

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

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

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

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

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

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

Лекция №7. Разработка данных

7.1 Этапы разработки

При разработке БД можно выделить следующие этапы работы.

I этап. Постановка задачи.

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

II этап. Анализ объекта.

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

III этап. Синтез модели.

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

IV этап. Выбор способов представления информации и программного инструментария.

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

В большинстве СУБД данные можно хранить в двух видах:

* с использованием форм;

* без использования форм.

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

V этап. Синтез компьютерной модели объекта.

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

Стадия 1. Запуск СУБД, создание нового файла базы данных или открытие созданной ранее базы.

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

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

Стадия 4. Заполнение БД. Процесс заполнения БД может проводиться в двух видах: в виде таблицы и в виде формы. Числовые и текстовые поля можно заполнять в виде таблицы, а поля типа МЕМО и OLE - в виде формы.

VI этап. Работа с созданной базой данных.

Работа с БД включает в себя следующие действия:

* поиск необходимых сведений;

* сортировка данных;

* отбор данных;

* вывод на печать;

* изменение и дополнение данных.

7.2 Разграничение прав на этапах разработки БД

На каждом этапе своего существования с БД связаны разные категории пользователей.

Этап проектирования БД.

1 Разработчик - Лицо или группа лиц осуществляющих:

* анализ и моделирование ПО;

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

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

* разработку приложений;

* разработку способов защиты данных и других средств администрирования БД.

2 Системные аналитики

3 Проектировщики структур данных

4 Проектировщики процессов обработки данных, прикладные программисты

5 Будущий администратор БД

Этапы проектирования, реализации, эксплуатации БД.

1 Администратор БД - Лицо или группа лиц, отвечающих за:

* первоначальную загрузку и ведение БД

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

* разработка технологии проверки соответствия введенных данных реальному состоянию ПО;

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

* защиту данных

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

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

* разработка средств фиксации доступа к данным и попыток нарушения системы защиты;

* тестирование системы защиты;

* исследование случаев нарушения системы защиты и развитие динамических методов защиты информации в БД

* архивирование, копирование и восстановление БД после сбоев

* разработка организационных средств архивирования и принципов восстановления БД;

* разработка дополнительных программных средств и технологических процессов восстановления БД после сбоев

* анализ эффективности функционирования БД

* анализ показателей функционирования БД

* планирование изменения структуры (реструктуризация) БД

* реорганизации БД

* поддержку системных средств (СУБД, ОС и др.)

* анализ существующих на рынке программных средств и анализ возможности и необходимости их использования в рамках БД;

* разработка требуемых организационных и программно-технических мероприятий по развитию БД;

* проверка работоспособности закупаемых прогр. средств перед подключением их к БД;

* курирование подключения новых прогр. средств к БД),

* реорганизацию БД и подключение новых приложений.

* анализ обращений пользователей БД (сбор статистики по характеру запросов, по времени их выполнения, по требуемым выходным документам)

2 Системные и прикладные программисты

3 Операторы и специалисты по техническому обслуживанию

Этап эксплуатации БД.

1 Конечные пользователи

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

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

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

8.1 Основные механизмы поддерживания высокой готовности

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

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

Кластерная организация сервера баз данных.

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

Тиражирование данных.

В Informix OnLine-DS 7.1 поддерживается модель тиражирования, состоящая в полном отображении данных с основного сервера на вторичные.

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

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

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

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

В последние годы в литературе по вычислительной технике все чаще употребляется термин "системы высокой готовности" (High Availability Systems). Все типы систем высокой готовности имеют общую цель - минимизацию времени простоя. Имеется два типа времени простоя компьютера: плановое и неплановое. Минимизация каждого из них требует различной стратегии и технологии. Плановое время простоя обычно включает время, принятое руководством, для проведения работ по модернизации системы и для ее обслуживания. Неплановое время простоя является результатом отказа системы или компонента. Хотя системы высокой готовности возможно больше ассоциируются с минимизацией неплановых простоев, они оказываются также полезными для уменьшения планового времени простоя.

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

8.2 Кластерная организация сервера баз данных

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

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

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

1. Высокопроизводительные (High Performance) кластеры.

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

2. Кластеры высокой готовности (High - Availability)

Такие кластеры представлены тремя схемами: active-active, active-passive и псевдо-активный-активный.

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

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

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

3. Кластеры смешанного типа

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

Кластеры этого типа совмещают в себе черты High Performanse и High Availability систем. Такие кластеры - оптимальный вариант для использования в основных data - центрах предприятий (по параметрам надежности, производительности и расширяемости), но отличаются довольно значительной стоимостью создания и поддержки.

8.3 Протоколы фиксации транзакций

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

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

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

Когда транзакция Т1 начинается, в протокол заносится запись

На протяжении выполнения транзакции в протоколе для каждой изменяемой записи записывается новое значение: . Здесь ID_RECORD - уникальный номер записи.

Если все действия, из которых состоит транзакция Т1, успешно выполнены, то транзакция частично фиксируется и в протокол заносится .

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

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

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

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

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

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

1 Если транзакция содержит команду начала транзакции, но не содержит команды фиксации с подтверждением ее выполнения, то выполняется последовательность действий как при откате транзакции, то есть восстанавливаются старые значения.

2 Если сбой произошел после выполнения последней команды изменения БД, но до выполнения команды фиксации, то команда фиксации выполняется, а с БД никаких изменений не происходит. Работа происходит только на уровне протокола.

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

Распределенные транзакции.

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

Для этого в современных СУБД предусмотрен так называемый протокол двухфазовой (или двухфазной) фиксации транзакций (two-phasecommit). Название отражает тот факт, что фиксация распределенной транзакции выполняется в две фазы.

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

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

Лекция №9. Защита данных в распределенных системах

9.1 Угрозы информационной безопасности в СУБД

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

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

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

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

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

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

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

Основным средством борьбы с подобными угрозами, помимо тщательно проектирования модели данных, является механизм размножения строк. Суть его в том, что в состав первичного ключа, явно или неявно, включается метка безопасности, за счет чего появляется возможность хранить в таблице несколько экземпляров строк с одинаковыми значениями "содержательных" ключевых полей. Наиболее естественно размножение строк реализуется в СУБД, поддерживающих метки безопасности (например, в INGRES/Enhanced Security), однако и стандартными SQL-средствами можно получить удовлетворительное решение.

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

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

Имя Диагноз Иванов

Петров Сидоров СПИД

Сифилис Стреляная рана Таблица 4.

Данные с высоким уровнем секретности.

Имя Диагноз Иванов

Ивлев Ярцев

Суворов Пневмония

Рак легких

Ожог второй степени

Микроинфаркт Таблица 5.

Данные с низким уровнем секретности.

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

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

Имя Диагноз Иванов

Ивлев Петров

Сидоров Ярцев

Суворов СПИД

Рак легких

Сифилис Стреляная рана

Ожог второй степени

Микроинфаркт Таблица 6.

Данные, доступные пользователю с высоким уровнем секретности (обратим внимание, что строка "Иванов Пневмания" здесь отсутствует.).

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

CREATE TABLE BaseTable1(

PatientName char (20),

Disease char (20),

Level char (10)

) WITH PRIMARY KEY (PatientName, Level);

CREATE TABLE BaseTable2(

UserName char (20),

SecurityLevel char (10)

) WITH PRIMARY KEY (UserName);

CREATE VIEW PatientInfo(

PatientName,

Disease ) AS SELECT PatientName, Disease

FROM TABLE BaseTable1

WHERE BaseTable1.Level=(

SELECT SecurityLevel

FROM BaseTable2

WHERE UserName = username ())

OR( BaseTable1.Level = "LOW"

AND NOT EXISTS (

SELECT * FROM BaseTable1 AS X

WHERE X.PatientName = BaseTable1.PatientName

AND X.Level = "HIGH"));

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

WHERE BaseTable1.Level = (

SELECT SecurityLevel FROM BaseTable2

WHERE UserName = username ())

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

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

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

Агрегирование данных.

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

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

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

Покушения на высокую готовность (доступность).

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

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

8.2 SQL - инъекции

Внедрение SQL-кода - один из распространённых способов взлома сайтов и программ, работающих с базами данных, основанный на внедрении в запрос произвольного SQL-кода.

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

Атака типа внедрения SQL может быть возможна из-за некорректной обработки входных данных, используемых в SQL-запросах.

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

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

Данными, передаваемыми через методы POST и GET

Значениями [HTTP-Cookie]

HTTP_REFERER (для скриптов)

AUTH_USER и AUTH_PASSWORD (при использовании аутентификации)

Как правило, манипуляция сводится к подстановке в параметры символа одинарной (реже двойной или обратной) кавычки.

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

Наиболее частые примеры аномального поведения:

* выводится сообщение о различных ошибках;

* при запросе данных (например, новости или списка продукции) запрашиваемые данные не выводятся вообще, хотя страница отображается.

Показать полностью… https://vk.com/doc40738823_437734951
Рекомендуемые документы в приложении