Курсовая работа: Проблемы безопасности баз данных. Обеспечение безопасности в СУБ. Защита информации в базах данных

Прочие модели 13.08.2019
Прочие модели

Тема: Проблемы безопасности баз данных. Обеспечение безопасности в СУБ

Тип: Курсовая работа | Размер: 46.53K | Скачано: 76 | Добавлен 15.10.16 в 05:44 | Рейтинг: 0 | Еще Курсовые работы


ВВЕДЕНИЕ... 3

Глава 1.Определение защиты информации.... 7

1.1.Основные определения и понятия .. 7

1.2. Защита информации в базах данных .. 10

Глава 2.Ключевые подходы защиты базы данных 15

2.1.Политика прав доступа к данным ... 15

2.2. Система защиты СУБД Access . 16

2.3. Организация системы защиты СУБД MS SQL Server .. 21

ЗАКЛЮЧЕНИЕ... 33

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ..... 37

ВВЕДЕНИЕ

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

Надёжность, достоверность и неотказуемость;

Стоимость решения, стоимость администрирования;

Соответствие общепринятым стандартам;

Простота интеграции в готовые решения и в новые разработки.

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

Также необходимо обратить внимание на следующие аспекты:

Интеграцию с внешними системами аутентификации;

Безопасность соединений;

Защиту данных на любом уровне;

Выборочное шифрование данных;

Подробный аудит действий пользователей;

Централизованное управление аутентификацией и авторизацией пользователей.

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

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

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

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

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

Определение угроз безопасности и групп потенциальных нарушителей;

Определение групп приложений, обеспечивающих бизнес-процессы предприятия;

Определение групп пользователей системы;

Определение объектов, хранящих данные и подлежащих защите;

Определение политик безопасности;

Определение методов хранения связей пользователь - права доступа - данные;

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

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

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

Именно поэтому защищённая система должна быть спроектирована и построена так, чтобы:

Файлы программного обеспечения СУБД не были доступны по сети;

К файлам БД на сервере не было доступа по сети — пользователи получают доступ

к информации, хранящейся в БД, только посредством СУБД;

Сами файлы БД были зашифрованы. Шифрование файлов БД используется как

простой и эффективный способ защиты данных от несанкционированного доступа

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

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

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

Объект исследования в данной работе это база данных. Мы будем рассматривать как понятие базы данных в целом, так и будем рассматривать конкретные примеры некоторых основных баз данных, таких как MS SQL Server, Oracle, Microsoft Access.

Большая часть терминов и основных понятий была взята из книги авторов Голицына О.Л., Максимов Н.В. и др. «Базы данных», это позволило дать вначале своего рода введение в основную часть курсовой работы.

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

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

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

  1. Артёмов.Д.К., «Microsoft SQL Server 2000: профессионалы для профессионалов» - Ростов на Дону: Русская Редакция, 2005, С. 88-112
  2. Голицына О.Л., Максимов Н.В. и др. «Базы данных» - Москва: ИНФРА-М,2007,С. 10-135.
  3. Гольев Ю.И., Ларин Д.А., Тришин А.Е., Шанкин Г.П. Криптографическая деятельность в США XVIII-XIX веков. // Защита информации. Конфидент. №6, 2004, С. 68-74
  4. Гринвальд Р., Стаковьяк Р., Стерн Дж.« Oraclee 11g. Основы. 4-е изд.» - Москва: Символ, 2009 - С. 65-97
  5. ГашковС. Б. У., Э. А. Применко, М. А. Черепнев «Криптографические методы защиты информации» - Москва: Академия, 2010, С 40-45
  6. Дунаев В. И. «Базы данных. Язык SQL для студента» - Санкт Петербург: СПб:Питер, 2007, С. 91-95
  7. Ищейнов В. Я., М. В. Мецатунян «Защита конфиденциальной информации» - Челябинск:Форум, 2009,С.114-145
  8. Корнеев И. К., Е. А. «Защита информации в офисе» - Казань: ТК Велби, 2008, С.38-56
  9. Кошелев В.Е., «Базы данных в Access 2007» - Москва: Бином, 2009, С. 47 - 98
  10. Кригель А. К., Борис Трухнов «SQL. Библия пользователя»- Москва: Вильям, 2010, С. 68 - 71
  11. Кумскова И. А. «Базы Данных».-Москва:КноРус, 2011, С. 140-142
  12. Партыка Т.Л., Попов И.И. «Информационная безопасность» - Москва: Форум: инфра, 2004, С. 45-87
  13. Северин В. А. «Комплексная защита информации на предприятии» - Москва:Городец,2008, С 92
  14. Сергеева Ю. С. «Защита информации. Конспект лекций» - Санкт Петербург: А-Приор, 2011, С. 150-176
  15. Смирнов.С. Н. «Безопасность систем баз данных» - Москва: Гелиос АРВ,2007, 224 с.
  16. Безопасность баз данных на примере Oraclee [Электронный ресурс].URL: http://www.flenov.info/favorite.php?artid=32

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

  • * похищение и фальсификация данных;
  • * утрата конфиденциальности (нарушение тайны);
  • * нарушение неприкосновенности личных данных;
  • * утрата целостности;
  • * потеря доступности.

Вопросы защиты данных часто рассматриваются вместе с вопросами

поддержки целостности данных (по крайней мере, в неформальном контексте),

хотя на самом деле это совершенно разные понятия. Термин защита

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

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

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

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

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

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

Ниже описаны многочисленные аспекты проблемы защиты данных.

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

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

В случае избирательного контроля каждому пользователю обычно предоставляются различные права доступа (иначе называемые привилегиями, или полномочиями) к разным объектам. Более того, разные пользователи, как правило, обладают разными правами доступа к одному и тому же объекту. (Например, пользователю U1 может быть разрешен доступ к объекту А, но запрещен доступ к объекту B, тогда как пользователю U2 может быть разрешен доступ к объекту B, но запрещен доступ к объекту А.) Поэтому избирательные схемы характеризуются значительной гибкостью.

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

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

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

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

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

Избирательная схема управления доступом

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

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

GRANT RETRIEVE { S#, SNAME, CITY }, DELETE

TO Jim, Fred, Mary ;

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

  • 1. Имя (в данном примере SA3, "suppliers authority three" -- полномочия поставщика с номером 3). Устанавливаемые полномочия будут зарегистрированы в системном каталоге под этим именем.
  • 2. Одна или несколько привилегий, задаваемых в конструкции GRANT.
  • 3. Задаваемое в конструкции ON имя переменной отношения, к которой применяются полномочия.
  • 4. Множество пользователей (точнее, идентификаторов пользователей), которым предоставляются указанные привилегии применительно к указанной переменной отношения, задаваемой с помощью фразы ТО.

Ниже приводится общий синтаксис оператора определения полномочий.

AUTHORITY

GRANT

ON

TO ;

Мандатная схема управления доступом

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

  • 1. Пользователь i может выполнить выборку данных объекта j только в том случае, если его уровень допуска больше классификационного уровня объекта j или равен ему {простое свойство безопасности -- simple security property).
  • 2. Пользователь i может модифицировать объект j только в том случае, если его уровень допуска равен классификационному уровню объекта j (звездное свойство -- star property).

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

"Секретно", в файл с меньшим уровнем классификации, что нарушит всю систему секретности.

Шифрование данных

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

Для изучения основных концепций шифрования данных следует ввести некоторые новые понятия. Исходные (незашифрованные) данные называются открытым текстом.

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

Пример 5.1. Пусть в качестве открытого текста дана следующая строка.

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

Ниже описывается используемый алгоритм шифрования.

1. Разбить открытый текст на блоки, длина которых равна длине ключа шифрования.

AS+KI NGFIS HERS+ CATCH +FIRE

  • (Здесь пробелы обозначены знаком "+".)
  • 2. Заменить каждый символ открытого текста целым числом в диапазоне 00-26, используя для пробела число 00, для А -- число 01,..., для Z -- число 26. В результате получится следующая строка цифр.
  • 0119001109 1407060919 0805181900 0301200308 0006091805
  • 3. Повторить п. 2 для ключа шифрования, в результате чего получится следующая строка цифр.
  • 0512091520
  • 4. Теперь значения, помещенные вместо каждого символа в каждом блоке открытого текста, просуммировать с соответствующими значениями, подставленными вместо символов ключа шифрования, и для каждой суммы из указанных двух значений определить и записать остаток от деления на 27.
  • 5. Заменить каждое число в нижней строке п. 4 соответствующим текстовым символом.

FDIZB SSOXL MQ+GT HMBRA ERRFY

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

Управление безопасностью обычно осуществляется на трех уровнях:

  • * уровень базы данных;
  • * уровень операционной системы;
  • * сетевой уровень.

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

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

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

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

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

Некоторые термины

онфиденциальная информация (sensitive information) - информация, которая требует защиты.

Доступ к информации (access to information) - ознакомление с информацией, ее обработка (в частности, копирование), модификация, уничтожение.

Субъект доступа (access subject) - лицо или процесс, действия которого регламентируются правилами разграничения доступа.

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

Правила разграничения доступа (security policy) - совокупность правил, регламентирующих права субъектов доступа к объектам доступа.

Санкционированный доступ (authorized access to information) - доступ к информации, который не нарушает правил разграничения доступа.

Несанкционированный доступ (unauthorized access to information) - доступ к информации, который нарушает правила разграничения доступа с использованием штатных средств, предоставляемых средствами вычислительной техники или автоматизированными системами.

Идентификатор доступа (access identifier) - уникальный признак объекта или субъекта доступа.

Идентификация (identification) - присвоение объектам и субъектам доступа идентификатора и (или) сравнение предъявляемого идентификатора с перечнем присвоенных идентификаторов.

Пароль (password) - идентификатор субъекта, который является его секретом.

Аутентификация (authentification) - проверка принадлежности субъекту доступа предъявленного им идентификатора, подтверждение подлинности.

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

Уровень полномочий субъекта доступа (subject privilege) - совокупность прав доступа субъекта доступа (для краткости в дальнейшем мы будем использовать термин «привилегия»).

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

Модель нарушителя правил разграничения доступа (security policy violator model) - абстрактное (формализованное или неформализованное) описание нарушителя правил разграничения доступа.

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

Метка конфиденциальности (sensitivity label) - элемент информации, характеризующий конфиденциальность объекта.

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

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

ользователей СУБД можно разделить на три группы:

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

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

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

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

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

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

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

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

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

CONNECT [ ] пользователь/пароль[@база_данных] CONNECT TO база_данных USER пользователь USING пароль

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

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

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

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

  • CONNECT - конечные пользователи. По умолчанию им разрешено только соединение с базой данных и выполнение запросов к данным, все их действия регламентированы выданными им привилегиями;
  • RESOURCE - привилегированные пользователи, обладающие правом создания собственных объектов в базе данных (таблиц, представлений, синонимов, хранимых процедур). Пользователь - владелец объекта обладает полным набором привилегий для управления данным объектом;
  • DBA - категория администраторов базы данных. Включает возможности обеих предыдущих категорий, а также возможность вводить (удалять) в систему (из системы) субъекты защиты или изменять их категорию.

Следует особо отметить, что в некоторых реализациях административные действия также разделены, что обусловливает наличие дополнительных категорий. Так, в Oracle пользователь с именем DBA является администратором сервера баз данных, а не одной-единственной базы данных. В СУБД «Линтер» компании РЕЛЭКС понятие администратора сервера баз данных отсутствует, а наличествует только понятие администратора конкретной базы данных. В IBM DB2 существует ряд категорий администраторов: SYSADM (наивысший уровень; системный администратор, обладающий всеми привилегиями); DBADM (администратор базы данных, обладающий всем набором привилегий в рамках конкретной базы данных). Привилегии управления сервером баз данных имеются у пользователей с именами SYSCTRL (наивысший уровень полномочий управления системой, который применяется только к операциям, влияющим на системные ресурсы; непосредственный доступ к данным запрещен, разрешены операции создания, модификации, удаления базы данных, перевод базы данных или экземпляра (instance) в пассивное состояние (quiesce), создание и удаление табличных пространств), SYSMAINT (второй уровень полномочий управления системой, включающий все операции поддержки работоспособности экземпляра (instance); непосредственный доступ к данным этому пользователю запрещен, разрешены операции изменения конфигурационных файлов базы данных, резервное копирование базы данных и табличных пространств, зеркалирование базы данных). Для каждой административной операции в IBM DB2 определен необходимый набор административных категорий, к которым должен принадлежать пользователь, выполняющий тот или иной запрос администрирования. Так, выполнять операции назначения привилегий пользователям может SYSADM или DBADM, а для того чтобы создать объект данных, пользователь должен обладать привилегией CREATETAB.

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

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

CREATE USER IDENTIFIED пользователь BY пароль

Подсистема безопасности IBM DB2 может использовать идентификаторы пользователей операционной системы; ее синтаксис SQL не содержит предложения, аналогичного предложению CREATE USER. Microsoft SQL Server может использовать аутентификацию как базы данных, так и операционной системы. Но мы не станем здесь обсуждать достоинства и недостатки выбранных производителями способов аутентификации - все они позволяют строить корректные схемы определения подлинности пользователей. Использование дополнительных средств аутентификации в рамках информационной системы не запрещается.

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

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

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

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

Предложения управления привилегиями:

  • назначение привилегии: GRANT привилегия TO субъект
  • отмена привилегии: REVOKE привилегия FROM субъект

Если субъект=пользователь, то привилегия назначается ему явно. Если субъект=роль, то для управления привилегиями используются соответственно:

GRANT ROLE имя_роли TO субъект REVOKE ROLE имя_роли FROM субъект

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

GRANT привилегия TO PUBLIC

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

REVOKE привилегия FROM PUBLIC

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

CREATE ROLE имя_роли DROP ROLE имя_роли

При управлении доступом к таблицам и представлениям набор привилегий в реализации СУБД определяется производителем.

Привилегии выборки и модификации данных:

SELECT - привилегия на выборку данных;

INSERT - привилегия на добавление данных;

DELETE - привилегия на удаление данных;

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

Привилегии изменения структуры таблиц:

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

INDEX - создание/удаление индексов на столбцы базовой таблицы;

ALL - все возможные действия над таблицей.

В реализациях могут присутствовать другие разновидности привилегий, например: CONTROL (IBM DB2) - комплексная привилегия управления структурой таблицы, REFERENCES - привилегия создания внешних ключей, RUNSTAT - выполнение сбора статистической информации по таблице и другие.

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

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

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

редства мандатной защиты предоставляются специальными (trusted) версиями СУБД.

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

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

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

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

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

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

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

Рассмотрим мандатную защиту подробнее. В качестве примера возьмем мандатную защиту СУБД «Линтер», которая получила признание в весьма специфическом секторе - силовых структурах, как единственная СУБД, имеющая сертификат по второму классу защиты от несанкционированного доступа, что соответствует классу B3 по американскому национальному стандарту.

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

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

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

Метка объекта включает следующее:

  1. Группа субъекта, который внес данный объект.
  2. Уровень доступа на чтение - RAL (Read Access Level).
  3. Уровень доступа на запись - WAL (Write Access Level).

Метка субъекта выглядит аналогично:

  1. Группа, к которой принадлежит субъект.
  2. RAL-уровень субъекта, который представляет собой максимальный RAL-уровень доступной субъекту информации.
  3. WAL-уровень субъекта, то есть минимальный RAL-уровень объекта, который может быть создан этим субъектом.

Все пользователи базы данных считаются разбитыми на непересекающиеся группы. Группа описывает область доступных пользователю данных. Для каждой группы существует администратор группы (уровень DBA для группы), созданный администратором системы. При этом пользователи одной группы не видят данных, принадлежащих пользователям другой группы. В этом плане у СУБД «Линтер» имеется особенность: в системе реализовано такое понятие, как «уровень доверия между группами». При этом уровни доверия не могут быть вложенными. Группа представляет собой числовое значение в диапазоне . Группа 0 - группа администратора системы. Только администратор системы может создать пользователя в группе, отличной от своей. Все данные, созданные от имени пользователя, помечаются его группой.

Уровни доступа вводятся для проверки прав на осуществление чтения-записи информации. Вводятся следующие уровни доступа:

  1. Для пользователя (субъекта):
  • RAL - уровень доступа; пользователь может получать (читать) информацию, RAL-уровень которой не выше его собственного уровня доступа;
  • WAL - уровень доверия на понижение уровня конфиденциальности; пользователь не может вносить информацию с уровнем доступа (RAL-уровнем) более низким, чем данный WAL-уровень пользователя. Иными словами, пользователь не может сделать доступную ему информацию менее конфиденциальной, чем указано в данном параметре.
  1. Для информации:
  • RAL - уровень чтения; пользователь может получать (читать) информацию, RAL-уровень которой не выше его собственного RAL-уровня (может читать менее конфиденциальные данные);
  • WAL - уровень ценности или уровень доступа на запись (модификацию, удаление); пользователь может модифицировать (удалять) информацию, WAL-уровень которой не выше его RAL-уровня.

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

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

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

КомпьютерПресс 3"2002

Первая часть статьи посвящена новшествам в управлении доступом к данным и сервисам. Продолжение статьи посвящено минимизации привилегий для исполняемого кода, шифрованию трафика и данных в SQL Server 2005, а также некоторым другим аспектам безопасности этой СУБД. В третьей части статьи представлены некоторые рекомендации для администраторов сетей и разработчиков приложений, а также рассмотрены средства обеспечения безопасности разных редакций SQL Server в сравнении с некоторыми другими СУБД. Цель данной статьи - обратить внимание администраторов баз данных и специалистов по информационной безопасности на данную проблему и показать один из вариантов реализации атаки на СУБД MS SQL, в результате которой потенциальный нарушитель получит доступ не только к хранимой в базе данных информации, но и полный контроль над сервером СУБД. Обеспечение безопасности корпоративных баз данных - сегодня одна из самых актуальных тем. И это понятно. Однако парадокс заключается в том, что уделяя огромное внимание защите баз данных снаружи, многие забывают защищать их изнутри. После трагедии 11 сентября американское правительство начало реализацию широкого комплекса мер по предотвращению террористических атак. Одна из таких мер заключается в поддержке разработки и внедрении ИТ с целью выявления и задержания подозрительных лиц, а также в снижении риска угроз безопасности и предотвращении ситуаций, допускающих проведения такого рода атак. Один из технологических элементов, необходимых, в частности, для предотвращения проявлений терроризма, - технология баз данных. Обычно такая задача возлагается на администраторов БД,у которых нет для этого ни времени ни необходимой подготовки. Из чего складывается рабочий день администратора баз данных? Конечно, всё зависит от того, какой ответ вы хотите получить - краткий или развернутый. Пространный ответ растянется на мили: инсталляция, переход на новую версию, планирование производительности, настройка, обеспечение работоспособности приложений и восстановления данных по резервным копиям. Это только первые пункты списка, он не включает срочные меры, которые приходится принимать ежедневно. В современных условиях любая деятельность сопряжена с оперированием большими объемами информации, которое производится широким кругом лиц. Защита данных от несанкционированного доступа является одной из приоритетных задач при проектировании любой информационной системы. Следствием возросшего в последнее время значения информации стали высокие требования к конфиденциальности данных. Системы управления базами данных, в особенности реляционные СУБД, стали доминирующим инструментом в этой области. Обеспечение информационной безопасности СУБД приобретает решающее значение при выборе конкретного средства обеспечения необходимого уровня безопасности организации в целом. ЕСЛИ ПРЕДПРИЯТИЕ ДОРОЖИТ СВОЕЙ ИНТЕЛЛЕКТУАЛЬНОЙ СОБСТВЕННОСТЬЮ, И КАЖДЫЙ РАБОТНИК МОЖЕТ ЛЕГКО ПОЛУЧИТЬ НЕОБХОДИМУЮ (И НЕ БОЛЕЕ ТОГО) ИНФОРМАЦИЮ, ТО КОМПАНИЯ МОЖЕТ НАДЕТЬСЯ НА РОСТ ПРОИЗВОДИТЕЛЬНОСТИ. НО ЕСЛИ ДАННЫЕ НЕ УПОРЯДОЧЕНЫ, ТО, НЕСМОТРЯ НА ЭНТУЗИАЗМ СОТРУДНИКОВ, В БОЛЬШИНСТВЕ СЛУЧАЕВ ПРЕДПРИЯТИЕ ОЖИДАЕТ КРАХ. Практически ни одна современная компания не может обойтись без использования баз данных. В самом простом случае для хранения небольших объемов данных в качестве системы управления базами данных (СУБД) может использоваться система Microsoft Access.
  • Дудкина Анастасия Сергеевна , бакалавр, студент
  • Баш­кирс­кий го­су­дарст­вен­ный аг­рар­ный уни­вер­си­тет
  • ЗАЩИТА
  • PHPMYADMIN
  • MYSQL
  • БАЗА ДАННЫХ

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

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

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

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

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

Защита БД производится на двух уровнях:

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

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

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

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


Рисунок 2. Обзор учетных записей

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

Таблица 1. Криптографические функции СУБД

Функции шифрования данных алгоритмом AES используют 128-битный ключ шифрования, т. е. шифрование ключами размером 192 и 256 бит, предусмотренными стандартом AES , в MySQL не реализовано. Ключ шифрования задается явным образом как один из параметров функции. В отличие от них, функции DES_ENCRYPT() и DES_DECRYPT(), которые шифруют алгоритмом TripleDES, помимо явного задания ключа шифрования, допускают простейший вариант управления ключами в виде ключевого файла, содержащего пронумерованные значения ключей. Однако, данные функции по умолчанию выключены, для их использования необходимо включить поддержку протокола SSL в конфигурации СУБД.

Функция ENCRYPT() может быть использована только в операционных системах семейства Unix, поскольку она шифрует данные с помощью системного вызова crypt(). Что касается используемых функций хэширования, то в документации на MySQL содержится предупреждение о том, что лежащие в их основе алгоритмы взломаны (подробно об этом написано, в частности, в, поэтому использовать их следует с осторожностью. Однако, MySQL пока не предлагает более стойких функций хэширования взамен существующих. Перечисленные выше криптографические функции также весьма просты в использовании. Например, следующий запрос помещает в таблицу table значение “text”, зашифрованное на ключе “password” : INSERT INTO table VALUES (1, AES_ENCRYPT("text", "password")); Отметим, что формат поля, в которое записывается зашифрованное значение, должен соответствовать ограничениям, накладываемым используемым криптоалгоритмом - в данном случае, оно должно быть двоичным (например, типа VARBINARY) и предполагать выравнивание в соответствии со 128-битным размером блока алгоритма AES.

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

Список литературы

  1. Мельников,В.П.Информационная безопасность и защита информации. / В.П.Мельников,
  2. С.А.Клейменов, А.М.Петраков // 3-е изд., стер. - М.: Академия, 2008. - 336 с.
  3. Панасенко С.П. Комплексная защита информации. // Информационные технологии. -2001 - № 3 - с. 14-16
  4. Рабочая программа дисциплины "Информационная безопасность" : направление подготовки 080500 Бизнес-информатика [Электронный ресурс] : профиль подготовки Информационные системы в бизнесе: квалификация (степень) выпускника Бакалавр / Башкирский ГАУ, [Каф. информатики и информационных технологий; сост. А. Р. Басыров]. - Уфа: [б. и.], 2013. - 16 с. - Б. ц.
  5. Сайт PHP веб-приложения «phpMyAdmin» [Электронный ресурс]. – Режим доступа: http://www.phpmyadmin.net/home_page/ , свободный


Рекомендуем почитать