Базы данных и их защита

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

4.2 Реализация на открытом коде в среде MySQL Workbench 6.3.

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

Ниже представлен пример работы с языком программирования SQL на открытом коде в среде MySQL Workbench 6.3.

Создаем свою базу данных My_base при помощи оператора CREATE DATABASE:

create database My_base

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

CREATE TABLE my_base.info_actor (

actor_id INT NOT NULL AUTO_INCREMENT,

first_name VARCHAR(255) NOT NULL,

last_name VARCHAR(255) NOT NULL,

PRIMARY KEY (actor_id)

);

CREATE TABLE my_base.id_actor_film (

actor_id INT NOT NULL,

first_name VARCHAR(255) NOT NULL,

last_name VARCHAR(255) NOT NULL,

film_id INT NOT NULL,

name_film VARCHAR(255) NOT NULL

);

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

insert into my_base.info_actor

SELECT actor_id,first_name,last_name

FROM sakila.actor;

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

insert into my_base.id_actor_film

SELECT a.actor_id,first_name,last_name,b.film_id,title

FROM my_base.info_actor as a

join (SELECT distinct actor_id,film_id

from sakila.film_actor) as b on a.actor_id=b.actor_id

join sakila.film_text as d on b.film_id=d.film_id;

Проверяем наличие данных в таблице:

select * from my_base.id_actor_film

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

CREATE TABLE my_base.kol_film (

actor_id INT NOT NULL,

kol_film real

);

insert into my_base.kol_film

select actor_id,count(film_id) kol_film

from

(select distinct actor_id,film_id

from my_base.id_actor_film) as a

group by actor_id

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

CREATE TABLE my_base.actor_kol_film (

actor_id INT NOT NULL,

first_name VARCHAR(255) NOT NULL,

last_name VARCHAR(255) NOT NULL,

name_film VARCHAR(255) NOT NULL,

kol_film real

);

insert into my_base.actor_kol_film

select a.actor_id,first_name,last_name,name_film,kol_film from my_base.id_actor_film a

join my_base.kol_film b on a.actor_id=b.actor_id

Просматриваем готовую таблицу:

select * from my_base.actor_kol_film

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

5. Защита баз данных

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

* похищение и фальсификация данных;

* утрата конфиденциальности (нарушение тайны);

* нарушение неприкосновенности личных данных;

* утрата целостности;

* потеря доступности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AUTHORITY SA3

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

ON S

TO Jim, Fred, Mary ;

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

1. Имя (в данном примере SA3, "suppliers authority three" -- полномочия поставщика с номером 3). Устанавливаемые полномочия будут зарегистрированы в системном каталоге под этим именем.

2. Одна или несколько привилегий, задаваемых в конструкции GRANT.

3. Задаваемое в конструкции ON имя переменной отношения, к которой применяются полномочия.

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

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

AUTHORITY <authority name>

GRANT <privilege commalist>

ON <relvar name>

TO <user ID commalist> ;

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

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

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

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

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

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

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

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

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

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

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

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

ELIOT

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

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). В требованиях может также оговариваться ограничение объема ресурсов (дискового пространства и процессорного времени), выделяемых одному пользователю, и постулироваться необходимость аудита действий пользователей. Механизм обеспечения безопасности на уровне базы данных также обеспечивает управление доступом к конкретным объектам схемы базы данных.

Заключение

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

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

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

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

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

Список использованных источников

1. Байер Д. Microsoft ASP .NET. Обеспечение безопасности. Мастер-Класс / Пер. с англ. М.: Издательство «Русская Редакция»; СПб.: Питер, 2008. - 446 стр.

2. Борри Х. Firebird: руководство разработчика баз данных: Пер. с анrл. - СПб.: БХВ-Петербург, 2006. - 1104 с.

3. Гектор Гарсиа-Молина, Джеффри Д. Ульман, Дженнифер Уидом Системы баз данных. Полный курс. : Пер. с англ. - М.: Издательский дом «Вильямс», 2003. - 1088 с.

4. Голованов Н.А. Современный англо-русский словарь компьютерных технологий. - М.: Бук-пресс. 2006 - 528 с.

5. Гольцман В. MySQL 5.0 - Библиотека программиста: Питер; Санкт-Петербург; 2010.

6. Гринвальд Р., Стаковьяк Р., Стерн Дж. Oracle 11g. Основы. 4-е изд. Пер. с англ. - СПб.: Символ-плюс, 2009. - 464 с.

7. Гурвиц Г. А. Microsoft® Access 2010. Разработка приложений на реальном примере. - СПб.: БХВ-Петербург, 2010. - 496 с.: ил. + CD-ROM.

8. Дейт К. Дж. Введение в системы баз данных. 8-е изд. - М.: Вильямс, 2005. - 1328 с.

9. Карпова Т.С. Базы данных: модели, разработка, реализации. - СПб.: Питер, 2002. - 304 с.

10. Кочергин В.И. Англо-русский толковый научно-технический словарь по системному анализу, программированию, электронике и электроприводу: В 2-х т. Т. 1. - Томск, 2008. - 652 с.

11. Кочергин В.И. Англо-русский толковый научно-технический словарь по системному анализу, программированию, электронике и электроприводу: В 2-х т. Т. 2. - Томск, 2008. - 314 с.

12. Кузнецов М.В., Симдянов И.В. MySQL 5 - СПб.: БХВ-Петербург, 2010 - 1024 с.: ил. + Дистрибутив на CD-ROM - (В подлиннике).

13. Мизинина И. Н., Мизинина А. И., Жильцов И. В. Англо-русский и русско-английский словарь ПК: ОЛМА-ПРЕСС Образование; М.; 2006.

14. Миллсап К., Хольт Д. Oracle. Оптимизация производительности. - Пер. с англ. - СПб: Символ-Плюс, 2006. - 464 с.

15. НГТУ Лекции: Базы данных вместе с глоссарием. НГТУ, 2009

16. Нильсен П. Microsoft SQL Server 2005. Библия пользователя.: Пер. с англ. - М.: ООО «И.Д. Вильямс», 2008. - 1232 с.

17. Скембрей Дж., Шема М. Секреты хакеров. Безопасность Web-приложений - готовые решения. : Пер. с англ. - М.: Издательский дом «Вильямс», 2003. - 384 с.

18. Peter Revesz Introduction to Database. From Biological to Spatio-Temporal, Springer-Verlag London Limited 2010.

Размещено на Allbest.ru

...