Главная » Бесплатные рефераты » Бесплатные рефераты по информатике »

Безопасность баз данных

Тема: Безопасность баз данных

Раздел: Бесплатные рефераты по информатике

Вуз: Костромской государственный университет

Год и город: Кировск 2012

Содержание

ВВЕДЕНИЕ 3

1. ТИПЫ ОПАСНОСТЕЙ 4

2. ОСНОВНЫЕ КАТЕГОРИИ ПОЛЬЗОВАТЕЛЕЙ 5

3. ТИПЫ ЗАЩИТЫ ДАННЫХ 6

3.1 Идентификация и проверка подлинности пользователей 6

3.2 Виды привилегий 7

3.2.1 Привилегии безопасности 7

3.2.2 Привилегии доступа 8

3.2.3 Получение информации о привилегиях 10

3.3 Представления (использование представлений для управления доступом) 11

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

3.5 Шифрование 13

3.6 Поддержание целостности данных в СУБД 14

3.6.1 Ограничения 14

3.6.2 Правила 15

3.7 Метки безопасности и принудительный контроль доступа 16

3.8 Копирование и восстановление 17

3.9 Резервное копирование на примере MS SQL SERVER 19

3.10 Триггеры 20

ЗАКЛЮЧЕНИЕ 21

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 22

ВВЕДЕНИЕ

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

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

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

Для иллюстрации излагаемых понятий и средств будут использоваться СУБД INGRES.

1. ТИПЫ ОПАСНОСТЕЙ

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

2.ОСНОВНЫЕ КАТЕГОРИИ ПОЛЬЗОВАТЕЛЕЙ

Пользователей СУБД можно разбить на три категории:

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

2. Администраторы базы данных. К этой категории относится любой пользователь, создавший базу данных, и, следовательно, являющийся её владельцем. Он может предоставлять другим пользователям доступ к базе и к содержащимся в ней объектам. Администратор базы отвечает за её сохранение и восстановление. В принципе в организации может быть много администраторов баз данных. Чтобы пользователь мог создать базу и стать её администратором, он должен получить (вероятно, от администратора сервера) привилегию CREATDB.

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

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

3 .ТИПЫ ЗАЩИТЫ ДАННЫХ

3.1 Идентификация и проверка подлинности пользователей

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

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

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

Например, в СУБД ORACLE оператор CONNECT имеет следующий вид:

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

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

3.2 Виды привилегий

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

3.2.1 Привилегии безопасности

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

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

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

MAINAIN_LOCATION –право на управление расположением баз администратора сервера баз данных и операционной системы.

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

3.2.2. Привилегии доступа

Привилегии доступа выделяются пользователям, группам, ролям или всем посредством оператора GRANT и изымаются с помощью оператора REVOKE. В самом общем виде оператор GRANT имеет следующий формат:

GRANT привилегии ON объект TO пользователи;

Оператор REVOKE имеет следующий формат:

REVOKE привилегии ON объект FROM пользователи;

Эти привилегии, как правило, присваивает владелец соответствующих объектов (он же –администратор баз данных). Группы и роли создаются с помощью операторов CREATE GROUP и CREATE ROLE. Для изменения состава группы служит оператор ALTER GROUP. Оператор DROP GROUP позволяет удалять группы, но только после того, как опустошён список членов группы. Оператор ALTER ROLE служит для изменения паролей ролей, а DROP ROLE для удаления ролей.

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

- таблицы и представления

- процедуры

- базы данных

-сервер баз данных

- события

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

-SELECT – право на выборку данных

- INSERT – право на добавление данных

-DELETE – право на удаление данных

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

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

По умолчанию пользователь не имеет никаких прав доступа к таблицам и представлениям – их необходимо передать с помощью операторов GRANT.

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

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

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

3.2.3 Получение информации о привилегиях

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

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

Таблицы iiusergroup, iirole и iidbprivileges базы данных iidbdb содержат соответственно, список групп и их состав, перечень ролей вместе с зашифрованными паролями и сведения о привилегиях доступа к базам данных. Так, таблица iiusergroup состоит из трёх столбцов:

• groupid - имя группы,

• groupmem - имя члена группы,

• reserve - резервный столбец.

Средствами SQL из этих таблиц можно извлечь необходимую информацию.

3.3 Представления (использование представлений для управления доступом)

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

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

Оператор GRANT и другие средства управления доступом СУБД позволяют реализовать следующие виды ограничения доступа:

• операционные ограничения (за счет прав доступа SELECT, INSERT, UPDATE, DELETE, применимых ко всем или только некоторым столбцам таблицы);

• ограничения по значениям (за счет механизма представлений);

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

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

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

• роль (высший приоритет)

• пользователь

• группа

• PUBLIC (низший приоритет)

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

3.5.Шифрование

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

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

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

2. алгоритм шифрования, который описывает, как с помощью ключа шифрования преобразовать обычный текст в шифротекст;

3. ключ дешифрования, предназначенный для дешифрования шифротекста;

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

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

С помощью параметра SET SECURITY TO могут быть установлены четыре режима шифрования данных в БД[2], которые определяют степень защиты информации. Это следующие режимы:

• NONE – нет шифрования в БД, режим шифрования отключён.

• LOW – низкий уровень защиты (каждый символ по сложному алгоритму заменяется другим). В этом режиме обеспечивается самая высокая производительность, но уровень защиты данных самый низкий.

• MEDIUM – обеспечивается более высокая защита (64 битный ключ) и наблюдается незначительное влияние на производительность СУБД.

• HIGH – самый высокий уровень защиты и обеспечивается не очень сильное влияние на производительность СУБД (128 битный ключ.)

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

3.6 Поддержание целостности данных в СУБД

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

3.6.1 Ограничения

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

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

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

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

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

3.6.2 Правила

Правила позволяют вызывать выполнение заданных действий при определённых изменениях базы данных. Обычно действие – это вызов процедуры. Правила ассоциируются с таблицами и срабатывают при изменении этих таблиц.

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

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

SET NORULES;

Оператор

SET RULES;

Позволит затем восстановить работу механизма правил. По умолчанию этот механизм включён.

Для удаления правил служит оператор

DROP RULE правило;

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

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

3.7 Метки безопасности и принудительный контроль доступа

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

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

В СУБД INGRES/Enhanced Security к каждой реляционной таблице неявно добавляется столбец, содержащий метки безопасности строк таблицы. Метка безопасности состоит из трёх компонентов:

1. Уровень секретности. Смысл этого компонента зависит от приложения. В частности, возможен традиционный спектр уровней от ''совершенно секретного'' до ''несекретного''.

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

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

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

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

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

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

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

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

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

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

3.8 Копирование и восстановление

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

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

3.9 Резервное копирование на примере MS SQL SERVER

В MS SQL SERVER [3]для ускорения и ''облегчения'' жизни есть три метода создания резервных копий:

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

2. FULL – полное резервирование. Самая мощная модель, при которой можно создавать промежуточные копии, например резервировать журнал транзакций.

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

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

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

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

3.10 Триггеры

Не менее интересным способом обеспечения безопасности являются триггеры[4] – коды, похожие на процедуры, хранящиеся на сервере. Такой код нельзя вызвать напрямую: он выполняется в ответ на определённые события (вставка, изменение и удаление строк). Внутри триггера можно проверить корректность выполняемых действий. Если взломщик попытается испортить данные, в триггере можно будет увидеть эти действия.

Пример защиты таблицы через триггер:

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Толковый словарь по вычислительной технике. – М.: Издательский отдел ''Русская редакция'' ТОО ''Channel trading Ltd'', 2005.

2. Материалы сайта ''Сервер информационных технологий''. WEB: www.citforum.ru.

3. Хомоненко А. Базы данных: Учеб. Для вузов. – 2-е изд. – СПб., 2000.

4. Фёдорова А., Елманова Н. Базы данных для всех. –М.: Компьютер пресс , 2001.

5. Глушаков С.В., Ломотько. Базы данных (2001 год издания). – М.: АСТ, 2001.

6 Карпова Т. Базы данных: модели, разработка, реализация, 2001.

7. Когаловский М.Р. Энциклопедия технологий баз данных. –М.: Финансы и статистика, 2002.

8. Конноли Т., Бегг Л., Страчан А. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. – 2-е изд. – Вильямс, 2000.

9. Ханенко В.Н. Информационные системы. – СПб.: Питер, 2001

10. Корнеев В.В., Гареев А.Ф. и др. Базы данных. Интеллектуальная обработка информации. М.: Изд. С.В. Молгачева, 2001.

11. Ребекка М. Райордан Основы реляционных баз данных, 2001.

Внимание!

Если вам нужна помощь в написании работы, то рекомендуем обратиться к профессионалам. Более 70 000 авторов готовы помочь вам прямо сейчас. Бесплатные корректировки и доработки. Узнайте стоимость своей работы

Бесплатная оценка

Размер: 24.13K

Скачано: 531

Скачать бесплатно

10.06.13 в 18:42 Автор:

Понравилось? Нажмите на кнопочку ниже. Вам не сложно, а нам приятно).

Чтобы скачать бесплатно Курсовые работы на максимальной скорости, зарегистрируйтесь или авторизуйтесь на сайте.

Важно! Все представленные Курсовые работы для бесплатного скачивания предназначены для составления плана или основы собственных научных трудов.

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

Добавить работу

Если Курсовая работа, по Вашему мнению, плохого качества, или эту работу Вы уже встречали, сообщите об этом нам.

Добавление отзыва к работе

Добавить отзыв могут только зарегистрированные пользователи.