Базы данных - это тоже файлы, но работа с ними отличается от работы с файлами других типов, создаваемых прочими приложениями. Выше мы говорили, что всю работу по обслуживанию файловой системы берет на себя операционная система.
Для баз данных предъявляются особые требования с точки зрения безопасности, поэтому в них реализован другой подход к сохранению данных.
При работе с обычными приложениями для сохранения данных мы задаем соответствующую команду, указываем имя файла и доверяемся операционной системе. Если мы закроем файл, не сохранив его, то вся работа по созданию или редактированию файла пропадет безвозвратно.
Базы данных - это особые структуры. Информация, которая в них содержится, очень часто имеет общественную ценность. Нередко с одной и той же базой (например, с базой регистрации автомобилей в ГИБДД) работают тысячи людей по всей стране. От информации, которая содержится в некоторых базах, может зависеть благополучие множества людей. Поэтому целостность содержимого базы не может и не должна зависеть ни от конкретных действий некоего пользователя, забывшего сохранить файл перед выключением компьютера, ни от перебоев в электросети.
Проблема безопасности баз данных решается тем, что в СУБД для сохранения информации используется двойной подход. В части операций, как обычно, участвует операционная система компьютера, но некоторые операции сохранения происходят в обход операционной системы.
Операции изменения структуры базы данных, создания новых таблиц или иных объектов происходят при сохранении файла базы данных. Об этих операциях СУБД предупреждает пользователя. Это, так сказать, глобальные операции. Их никогда не проводят с базой данных, находящейся в коммерческой эксплуатации, - только с ее копией. В этом случае любые сбои в работе вычислительных систем не страшны.
С другой стороны, операции по изменению содержания данных, не затрагивающие структуру базы, максимально автоматизированы и выполняются без предупреждения. Если, работая с таблицей данных, мы что-то в ней меняем в составе данных, то изменения сохраняются немедленно и автоматически.
Обычно, решив отказаться от изменений в документе, его просто закрывают без сохранения и вновь открывают предыдущую копию. Этот прием работает почти во всех приложениях, но только не в СУБД. Все изменения, вносимые в таблицы базы, сохраняются на диске без нашего ведома, поэтому попытка закрыть базу «без сохранения» ничего не даст, так как все уже сохранено. Таким образом, редактируя таблицы баз данных, создавая новые записи и удаляя старые, мы как бы работаем с жестким диском напрямую, минуя операционную систему.
По указанным выше причинам нельзя заниматься учебными экспериментами на базах данных, находящихся в эксплуатации. Для этого следует создавать специальные учебные базы или выполнять копии структуры реальных баз (без фактического наполнения данными).
Обычно с базами данных работают две категории исполнителей. Первая категория – проектировщики или разработчики . Их задача состоит в разработке структуры таблиц базы данных и согласовании ее с заказчиком. Кроме таблиц проектировщики разрабатывают и другие объекты базы данных, предназначенные, с одной стороны, для автоматизации работы с базой, а с другой стороны - для ограничения функциональных возможностей работы с базой (если это необходимо из соображений безопасности).
Проектировщики не наполняют базу конкретными данными (заказчик может считать их конфиденциальными и не предоставлять посторонним лицам). Исключение составляет экспериментальное наполнение тестовыми данными на этапе отладки объектов базы.
Вторая категория исполнителей, работающих с базами данных, - пользователи . Они получают исходную базу данных от проектировщиков и занимаются ее наполнением и обслуживанием. В общем случае пользователи не имеют средств доступа к управлению структурой базы - только к данным, да и то не ко всем, а к тем, работа с которыми предусмотрена на конкретном рабочем месте. Соответственно, система управления базами данных имеет два режима работы:проектировочный ипользовательский. Первый режим предназначен для создания или изменения структуры базы и создания ее объектов. Во втором режиме происходит использование ранее подготовленных объектов для наполнения базы или получения данных из нее.
Под безопасностью подразумевается, что некоторому пользователю разрешается выполнять некоторые действия.
СУБД должны соблюдать 3 основных аспекта информационной безопасности:
1. Конфиденциальность
2. Целостность
3. Доступность
В этом посте мы поговорим о конфиденциальности
А) Управление безопасностью
В современных СУБД поддерживается как избирательный, так и обязательный подходы к обеспечению безопасности данных.
В случае избирательного управления, некий пользователь обладает различными правами, или привилегиями, и полномочиями при работе с различными объектами. Поскольку разные пользователи могут обладать различными правами доступа к одному и тому же объекту, такие системы очень гибкие.
В случае обязательного управления, каждому объекту присваивается некий квалификационный уровень, ну а каждому пользователю предоставляются права доступа к тому или иному уровню; и соответственно, если у вас есть права доступа на какой-то уровень — все, что на этот уровень записано, ко всему у вас имеется доступ. Считается, что такие системы жесткие, статичные, но они проще в управлении: легко всем объектам дать какой-либо номер (1,2,3,4…) и пользователю потом присвоить доступ кому до 5-го, кому до 6-го, кому до 7-го уровня и т.д. в порядке повышения приоритета.
В обычных СУБД для идентификации и проверки подлинности пользователя применяется либо соответствующий механизм операционной системы, либо то, что имеется в SQL-операторе connect (там есть специальные параметры для доступа при подключении). В момент начала сеанса работы с сервером базы данных пользователь идентифицирует контакт, или логин, своим именем, а средством аутентификации служит пароль.
Идентификатор – это краткое имя, однозначно определяющее пользователя для СУБД. Является основой систем безопасности. Для пользователей создаются соответствующие учетные записи.
Идентификация позволяет субъекту (т.е. пользователю или процессу, действующему от имени пользователя) назвать себя, т.е. сообщить свое имя (логин).
По средствам аутентификации (т.е. проверки подлинности) вторая сторона (операционная система или собственно СУБД) убеждается, что субъект действительно тот, за кого он себя выдает.
Для особо уязвимых систем (например, банковским и т.п.) используются более сложные системы защиты. Так, например, известны системы с последовательным созданием нескольких вопросов личного характера, с ограничением времени на их ответ и количества попыток (как в любом мобильнике).
В стандарте ANSI ISO вместо термина «идентификатор пользователя» (user ID) используется термин «идентификатор прав доступа» (authorization ID).
Система безопасности на сервере может быть организована 3-мя способами:
1. стандартная безопасность: когда на сервер требуется отдельный доступ (т.е. в операционную систему вы входите с одним паролем, а на сервер базы данных с другим);
2. интегрированная безопасность (достаточно часто используют): входите в операционную систему с каким-то пользовательским паролем, и это же имя с этим же паролем зарегистрировано в СУБД. Второй раз входить не надо. Раз попал человек на сервер, ну да ладно, пусть пользуется всем, что есть.
3. смешанная система, которая позволяет входить и первым, и вторым способом.
Б) Управление доступом
Обычно в СУБД применяется произвольное управление доступом: когда владелец объекта (в крайнем случае, администратор базы данных, но чаще владелец) передает права доступа (permissions) кому-нибудь. При этом права могут передаваться отдельным пользователям, группам пользователей, или ролям.
1. Учетная запись создается для отдельных пользователей с логином и паролем. Как правило, это делает администратор базы данных.
2. Группа – именованная совокупность пользователей, чаще всего в группы объединяют на основе какой-либо организации (по отделам, по комнатам, по бригадам и т.п.). Формально говоря, пользователь может входить в разные группы и входить в систему с разной возможностью (должен указать от имени какой группы он входит).
3. Роль – некий, часто служебный, перечень возможностей. Например, бухгалтер, кладовщик и т.п. Приходит человек на работу, ему присваивают такие права доступа, и он с ними может входить. Такой вариант сейчас довольно хорошо используется, т.к. это достаточно удобно оговорить на предприятии. При желании можно пересмотреть эту роль, и она сразу всех потом поменяет. Как правило, считается, что привилегии роли имеют приоритет перед привилегиями групп.
Более высокие требования по безопасности в настоящее время мы рассматривать не будем. Такие многоуровневые системы безопасности были разработаны еще в 70х годах ХХ века. Известные фамилии: Bella, Lapadula.
B) Основные категории пользователей
В общем случае пользователи СУБД могут быть разбиты на 3 основные большие группы:
1. администратор сервера базы данных (и его помощники): ведают установкой, конфигурированием сервера, регистрацией пользователей, групп, ролей, и т.д. Обладает всеми правами базы данных.
2. администратор отдельной базы данных (сервер может обслуживать тысячи баз данных).
3. прочие конечные пользователи: программисты (создают программы для управления теми или иными процессами: бухгалтерскими, кадровыми…), работники фирм и т.д.
Как правило, для администраторов баз данных сделана первоначальная учетная запись, чтоб сделать первоначальный вход в систему. Например, в InterBase: SISDBA с masterkey. В SQL-server: SA и пустой пароль. В Oracle есть 3 изначальных учетных записи: SIS, SYSTEM и MANAGER.
Г) Виды привилегий
Фактически их две:
. привилегии безопасности: выделяются конкретному пользователю, создаются, как правило, команды типа create user. Но создать пользователя в базе данных – это не значит предоставить ему права на все. Просто он может войти в базу данных, но там ничего не увидеть. После создания ему еще надо дать права.
. привилегии доступа или права доступа (permissions): предоставляют созданному пользователю те или иные привилегии. Здесь используются другие 2 команды: Grant – предоставить право на что-то (чтение, добавление, удаление, изменение записи…), Revolce.
Каким образом реализуются или ограничиваются права доступа:
. есть операционные ограничения – право на выполнение тех или иных операторов. Чаше всего это select, insert, delete и update. Во многих СУБД (в том числе Oracle) порядка 25 разных операционных прав можно предоставлять.
. Ограничения по значениям, реализуемые с помощью механизма представлений (View).
. Ограничения на ресурсы, реализуемые за счет привилегий доступа к базам данных.
. Привилегии системного уровня (для Oracle). Когда пользователю разрешается выполнять до 80 различных операторов.
Совокупность всех привилегий, которыми можно обладать называется PUBLIC. Администратор базы данных по умолчанию имеет PUBLIC-права – права на все объекты и действия.
Д) Контрольные исследования
Поскольку абсолютно неуязвимых систем не бывает, или, по крайней мере, в определенном смысле неуязвимых, то при работе с очень важными данными или при выполнении очень серьезных критических операций используют регистрацию каких-то действий (т.е. при выполнении какого-то действия автоматически записывается lok-файл, обычно это текстовый файл, его легко сделать через триггеры). Таким образом, если в этом файле более подробно все написать, то можно следить, кто когда что делал.
Е) Протоколирование и аудит
Под протоколированием понимается сбор и накопление информации о событиях, происходящих в информационной системе. В том числе с помощью lok-файлов.
Под аудитом понимается анализ накопленной информации, проводимый либо оперативно (почти в реальном времени), либо периодически (раз в сутки, раз в неделю…).
Для чего используется протоколирование и аудит?
Тут есть несколько основных целей:
. Обеспечение подотчетности пользователей и администратора. За счет этого можно определить, кто куда обращался, и не появились ли у кого-нибудь непонятные права, не подглядел ли кто-нибудь пароль и т.д.
. Для того, чтоб иметь возможность реконструировать последовательность событий. Какие-то нежелательные изменения – можно вернуть назад.
. Обнаружение попыток нарушения информационной безопасности (взлома).
. Выявление различных проблем в работе информационной системы (например, кому-то мало дали данных для работы, кому-то много)
Если говорить о СУБД Oracle, как о флагмане базостроения, там ведется 3 контрольных журнала:
. Журнал привилегий (происходит отслеживание использования привилегий)
. Журнал операторов (отслеживает, какие операторы используются часто для объектов, потом можно что-то превращать в процедуры, улучшать быстродействие, важный журнал)
. Журнал объектного уровня (контролирует доступ к объектам)
Курсовая работа
ПО МДК 02.02.Р1. РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ В СУБД ACCESS
НА ТЕМУ: «Проектирование базы данных торговой организации»
Выполнил: студент гр. ПО-41
М.В.Цацин
Руководитель: И.И. Шалаева
Оценка:__________________
Г. Стерлитамак
введение......................................................................................................... 3
Постановка задачи.................................................................................. 5
1.ОСНОВНЫЕ ПОНЯТИЯ О БАЗАХ ДАННЫХ В MS ACCESS................... 6
1.1 Базы данных и системы управления базами данных.................... 6
1.2. Типы данных. 7
1.3. Безопасность баз данных. 8
2. Структура базы данных................................................................... 10
2.1 Схема данных..................................................................................... 10
2.2 Таблицы................................................................................................... 11
2.3. Формы..................................................................................................... 16
2.4. Запросы................................................................................................... 19
2.5. Отчеты..................................................................................................... 21
3. ВАРИАНТ БАЗЫ ДАННЫХ ТОРГОВОЙ ОРГАНИЗАЦИИ, ЗАНИМАЮЩЕЙСЯ РЕАЛИЗАЦИЕЙ ПТИЦЫ-РЫБЫ................................................................... 23
ЗАКЛЮЧЕНИЕ................................................................................................. 25
ВВЕДЕНИЕ
Для принятия обоснованных и эффективных решений в производственной деятельности, в управлении экономикой и в политике современный специалист должен уметь с помощью компьютеров и средств связи получать, накапливать, хранить и обрабатывать данные, представляя результат в виде наглядных документов. В современном обществе информационные технологии развиваются очень стремительно, они проникают во все сферы человеческой деятельности.
В разных областях экономики зачастую приходится работать с данными из разных источников, каждый из которых связан с определенным видом деятельности. Для координации всех этих данных необходимы определенные знания и организационные навыки.
Продукт корпорации Microsoft - Access объединяет сведения из разных источников в одной реляционной базе данных. Создаваемые в нем формы, запросы и отчеты позволяют быстро и эффективно обновлять данные, получать ответы на вопросы, осуществлять поиск нужных данных, анализировать данные, печатать отчеты, диаграммы и почтовые наклейки.
Целью данной курсовой работы является рассмотрение теории и создания на практике базы данных в продукте корпорации Microsoft для управления базами данных «Microsoft Access» на тему: «Проектирование базы данных торговой организации» занимающийся реализацией птицы-рыбы.
Задачами курсовой работы были:
· Эффективно изложить информацию.
· Обеспечить доступ к информации.
· Расширить базу данных новыми данными.
· Проверить подлинность информации.
· Предотвратить возможные ошибки к доступу базы данных.
· Открыть доступ только к той информации, которая необходима для работы.
· Открыть возможность редактирования информации только проверенным людям.
· Облегчить способ для редактирования информации, а также для предоставления отчетности.
ПОСТАНОВКА ЗАДАЧИ
1.1. Разработать базу данных (БД) «Торговая организация», позволяющую вести:
· учет имеющегося товара;
· учет покупателей;
· учет поставки товара;
1.2. Основные требования к БД по функциональному набору:
1.2.1. Требования по учету торговли:
· Покупка товаров по видам;
· Покупка товаров по датам за определенный срок;
1.2.2. Требования по учету покупателей
· Данные о поставке продуктов покупателям;
· Ассортимент птицы-рыбы;
· Отчет покупок по датам;
· Отчет покупок по видам.
ОСНОВНЫЕ ПОНЯТИЯ О БАЗАХ ДАННЫХ В MS ACCESS
Базы данных и системы управления базами данных
База данных – это организованная структура, предназначенная для хранения информации. В современных базах данных хранятся не только данные, но и информация.
Это утверждение легко пояснить, если, например, рассмотреть базу данных библиотеки. В ней есть все необходимые сведения об авторах, книгах, читателях и т.д. Доступ к этой базе могут иметь как работники библиотеки, так и читатели, которым необходимо найти какое-либо издание. Но среди них вряд ли найдется такое лицо, которое имеет доступ ко всей базе полностью и при этом способно единолично вносить в нее произвольные изменения. Кроме данных, база содержит методы и средства, позволяющие каждому из сотрудников оперировать только с теми данными, которые входят в его компетенцию. В результате взаимодействия данных, содержащихся в базе, с методами, доступными конкретным сотрудникам, образуется информация, которую они потребляют и на основании которой в пределах собственной компетенции производят ввод и редактирование данных.
С понятием базы данных тесно связано понятие системы управления базой данных. Это комплекс программных средств, предназначенных для создания структуры новой базы, наполнение ее содержимым, редактирование содержимого и визуализации информации. Под визуализацией информации базы понимается отбор отображаемых данных в соответствии с заданным критерием, их упорядочение, оформление и последующая выдача на устройства вывода или передачи по каналам связи.
В мире существует множество систем управления базами данных. Несмотря на то что они могут по-разному работать с разными объектами и предоставляют пользователю различные функции и средства, большинство СУБД опираются на единый устоявшийся комплекс основных понятий. Это дает нам возможность рассмотреть одну систему и обобщить ее понятия, приемы и методы на весь класс СУБД. В качестве такого учебного объекта мы выберем СУБД Microsoft Access, входящую в пакет Microsoft Office.
Типы данных
Таблицы баз данных, как правило, допускают работу с гораздо большим количеством разных типов данных. Так, например, базы данных Microsoft Access работают со следующими типами данных.
· Текстовый – тип данных, используемый для хранения обычного неформатированного текста ограниченного размера (до 255 символов).
· Числовой – тип данных для хранения действительных чисел.
· Поле Мемо – специальный тип данных для хранения больших объемов текста (до 65 535 символов). Физически текст не хранится в поле. Он храниться в другом месте базы данных, а в поле храниться указатель на него, но для пользователя такое разделение заметно не всегда.
· Дата/время – тип данных для хранения календарных дат и текущего времени.
· Денежный - тип данных для хранения денежных сумм. Теоретически, для их записи можно было бы пользоваться и полями числового типа, но для денежных сумм есть некоторые особенности (например, связанные с правилами округления), которые делают более удобным использование специального типа данных, а не настройку числового типа.
· Счетчик – специальный тип данных для уникальных (не повторяющихся в поле) натуральных чисел с автоматическим наращиванием. Естественное использование – для порядковой нумерации записей.
· Логический - тип для хранения логических данных (могут принимать только два значения, например Да или Нет).
· Мастер подстановок – это не специальный тип данных. Это объект, настройкой которого можно автоматизировать ввод данных в поле так, чтобы не вводить их вручную, а выбирать их из раскрывающегося списка.
Безопасность баз данных
Базы данных – это тоже файлы, но работа с ними отличается от работы с файлами других типов, создаваемых прочими приложениями. Выше мы видели, что всю работу по обслуживанию файловой структуры берет на себя операционная система. Для базы данных предъявляются особые требования с точки зрения безопасности, поэтому в них реализован другой подход к сохранению данных.
Базы данных – это особые структуры. Информация, которая в них содержится, очень часто имеет общественную ценность. Нередко с одной и той же базой работают тысячи людей по всей стране. От информации, которая содержится в некоторых базах, может зависеть благополучие множества людей. Поэтому целостность содержимого базы не может и не должна зависеть ни от конкретных действий некоего пользователя, забывшего сохранить файлы перед выключением компьютера, ни от перебоев в электросети.
Проблема безопасности баз данных решается тем, что в СУБД для сохранения информации используется двойной подход. В части операций, как обычно, участвует операционная система компьютера, но некоторые операции сохранения происходят в обход операционной системы.
Структура базы данных
Схема данных
Схема данных отображает в виде дерева модель данных для страницы доступа к данным. В ней хранятся источники данных, поля и элементы управления страницы. Поскольку список полей не отображает содержимого конкретной страницы, для ознакомления со структурой страницы лучше использовать структуру данных. Можно также выбирать отображаемые в структуре данных объекты, задавать их параметры, определять и редактировать связи между источниками данных, удалять поля и источники данных.
Рис.1 Схема данных
Составляющими схемы данных являются три таблицы:
· «Номенклатура»
· «Поставка товара»
· «Покупатели»
Таблицы
Таблицы – это основные объекты любой базы данных. Во-первых, в таблицах хранятся все данные, имеющиеся в базе, а во-вторых, таблицы хранят и структуру базы (поля, их типы и свойства).
Все 3 таблицы я создал в режиме конструктора, во всех таблицах ключевым полем является - КодТовара.
Конструктор таблицы «Номенклатура птицы-рыбы» показан на рис.2.
Рис.2 Структура таблицы «Номенклатура птицы-рыбы»
Таблица «Номенклатура птицы-рыбы» показана на рис.3 предназначена для отображения всего имеющегося ассортимента который есть у организации.
Таблица «Номенклатура птицы-рыбы»
Конструктор таблицы «Покупатели» показан на рис.3.
Атаки на хранилища и БД являются одними из самых опасных для предприятий и организаций. Согласно статистике компании infowatch , в последние годы количество утечек данных в мире неуклонно растет, при этом на 2015 год более тридцати процентов из них приходятся на внешних нарушителей и более шестидесяти выполнено с участием сотрудников организации. Даже если предположить, что в ряде случаев утечка включала данные, к которым сотрудник имеет легальный доступ, каждый третий случай приходился на внешнюю атаку. Также нужно отметить, что, согласно приведенным в данным, на внешние атаки приходятся семь из восьми утечек объемом более десяти миллионов записей.
Злоумышленников интересуют такие виды информации, как внутренняя операционная ин- формация, персональные данные сотрудников, финансовая информация, информация о заказчиках/клиентах, интеллектуальная собственность, исследования рынка/анализ деятельности конкурентов, платежная информация . Эти сведения в итоге хранятся в корпоративных хранилищах и БД различного объема.
Все это приводит к необходимости обеспечения защиты не только коммуникаций, операционных систем и других элементов инфраструктуры, но и хранилищ данных как еще одного барьера на пути злоумышленника. Однако на сегодняшний день работы в области обеспечения безопасности БД направлены в основном на преодоление существующих и уже известных уязвимостей, реализацию основных моделей доступа и рассмотрение вопросов, специфичных для конкретной СУБД. Целью данной работы являются комплексное рассмотрение и систематизация вопросов безопасности раз- личных БД в свете новых угроз, общих тенденций развития информационной безопасности и возрас- тающей роли и разнообразия хранилищ данных.
Вопросы комплексной безопасности БД привлекают внимание исследователей, им ежегодно посвящается ряд работ как в России, так и за рубежом. Можно отметить такие исследования, как классическая работа . В ней рассматриваются подходы к обеспечению конфиденциальности, целостности и доступности СУБД, предотвращение, определение и игнорирование атак. Предлагаются подходы к обеспечению мандатного и ролевого дискреционного доступа к реляционному серверу. Данную тему развивает работа , затрагивающая те же вопросы обеспечения разделения доступа, привилегий, аудита и шифрования данных, а также вопросы применения для обеспечения защищенного доступа встроенных механизмов, таких как триггеры, представления и хранимые процедуры. Резюмирующая их работа обобщает развитие подходов к безопасности в историческом аспекте.
Среди зарубежных работ, освещающих современные направления исследований, можно отметить . Работы российских исследователей в основном посвящены узким вопросам безопасности СУБД, например .
Нельзя не отметить также монографии . Однако эти работы, как и известные учебные пособия и материалы, в частности , также не выходят за рамки вышеозначенных тем или же, как например , отражают специфику конкретной СУБД.
Аналогичную ситуацию можно наблюдать и в работе . STIG включает известные вопросы безопасности и критерии уровневой сертификации программных средств СУБД, оценивая безопас- ность ПО на основании известных угроз, без учета специфики хранимых данных.
Таким образом, сегодняшние исследования в области безопасности СУБД ограничиваются развитием концепции конфиденциальности, целостности и доступности данных, что не соответствует современным требованиям к системам защиты и информационной безопасности программных решений (например ), причем в контексте конкретных методов защиты, а не целостного рассмотрения проблемы. При этом они зачастую посвящены конкретным программным продуктам, а не всему классу соответствующего ПО.
Эволюция систем безопасности БД
Исторически развитие систем безопасности БД происходило как реакция на действия злоумышленников в соответствии с этапами эволюции самих хранилищ (БД) и изменениями типа и вида возрастающих угроз. Эти изменения были обусловлены общим развитием БД от решений на мейнфреймах до облачных хранилищ.
В архитектурном плане можно выделить следующие подходы:
Полный доступ всех пользователей к серве- ру БД;
Разделение пользователей на доверенных и частично доверенных средствами СУБД (системы управления БД);
Введение системы аудита (логов действий пользователей) средствами СУБД;
Введение шифрования данных; вынос средств аутентификации за пределы СУБД в опе- рационные системы и промежуточное ПО; отказ от полностью доверенного администратора данных.
Тем не менее, введение средств защиты как реакции на угрозы не обеспечивает защиту от новых способов атак и формирует разрозненное представление о самой проблеме обеспечения безопасности. С одной стороны, крупные компании могут выделить достаточное количество средств обеспечения безопасности для своих продуктов, с другой стороны, именно по этой причине имеется большое количество разнородных решений, отсутствует понимание комплексной безопасности данных (и ее компоненты разнятся от производителя к производителю), нет общего, единого подхода к безопасности хранилищ данных и, как следствие, возможности. Усложняются прогнозирование будущих атак и перспективная разработка защитных механизмов, для многих систем сохраняется актуальность уже давно известных атак, усложняется подготовка специалистов по безопасности.
Именно разработка программных средств перспективной защиты (на опережение злоумышленника), обеспечение возможности внедрения такой технологии представляются авторам статьи наиболее актуальными задачами на текущем этапе.
Современные проблемы обеспечения безопасности БД
Список основных уязвимостей хранилищ данных, актуальный на сегодняшний день , не претерпел существенных изменений за последние более чем пять лет. Проанализировав средства обеспечения безопасности СУБД, архитектуру БД, интерфейсы, известные уязвимости и инциденты безопасности, можно выделить следующие причины возникновения такой ситуации:
Проблемами безопасности серьезно занимаются только крупные производители прежде всего в ведущих продуктах линеек для хранения данных;
Программисты БД, прикладные программисты и администраторы БД не уделяют должного внимания вопросам безопасности;
Разные масштабы и виды хранимых данных требуют разных подходов к безопасности;
Различные СУБД используют разные языковые диалекты для доступа к данным, организованным на основе одной и той же модели;
Появляются новые виды и модели хранения данных.
Рассмотрим эти положения более подробно на примере линейки продуктов от Oracle. СУБД Oracle Database Server имеет достаточно развитую систему безопасности, включающую основные и дополнительные модули и содержащую средства гранулирования доступа до уровня записи и маскирования данных. Отметим, что продукт компании СУБД MySQL не может похвастаться таким уровнем защищенности. Это достаточно серьезная проблема, так как MySQL - широко применяемая СУБД как в электронной коммерции, так и в БД государственных структур.
Многие уязвимости, обозначенные в исследованиях (например в ), сохраняют актуальность за счет невнимания или незнания администраторами систем БД вопросов безопасности. Например, известные техники простой SQL-инъек-ции широко эксплуатируются сегодня в отношении различных web и иных приложений, в которых не уделяется внимание контролю входных данных запроса. Причинами этого являются как недостаточная информированность или внимание администраторов СУБД и прикладных программистов, так и отсутствие встроенных средств контроля известных уязвимостей в большинстве СУБД. Хорошим решением были бы автоматизация и перенос контроля таких угроз на уровень сервера, однако многообразие языковых диалектов не позволяет это сделать.
Также нужно отметить, что применение различных средств обеспечения информационной безо-пасности является для организации компромиссом в финансовом плане: внедрение более защищенных продуктов и подбор более квалифицированного персонала требуют больших затрат. К тому же ком- поненты безопасности могут отрицательно влиять на производительность систем управления БД, например уровни согласованности транзакций. Полное соответствие модели ACID - самый медленный способ обеспечения целостности при многопользовательской работе. Такие подходы, как маскирование данных или введение проверок безо-пасности доступа, также замедляют работу .
Еще одна причина такой ситуации - разрозненность диалектов языка запросов к СУБД. Если рассматривать только известные реляционные СУБД, несмотря на наличие развивающегося стандарта SQL (SQL-92, SQL-99, SQL-2003, SQL-2008), даже крупные производители не только используют собственные расширения языка, но и не поддерживают до конца операции принятой версии стандарта. Этот факт осложняет разработку единых механизмов защиты БД уровня сервера.
Приведенные выше проблемы усугубляются с появлением и широким распространением нереляционных хранилищ данных и СУБД, оперирующих другой моделью данных, однако построенных по тем же принципам и имеющих аналогичное назначение, что и традиционные, реляционные серверы. По сути многообразие современных так называемых NoSQL (нереляционных) решений приводит к разнообразию применяемых моделей данных и размывает границу понятия БД.
Следствием этих проблем и отсутствия единых методик является нынешняя ситуация с безопасностью NoSQL-систем. Эти решения появились на рынке недавно и еще не успели пройти «путь ошибок и уязвимостей», характерный для их более зрелых реляционных аналогов. В большинстве NoSQL-систем отсутствуют не только общепринятые механизмы безопасности вроде шифрования, поддержки целостности и аудита данных, но даже развитые средства аутентификации пользователей.
Особенности систем БД как объекта защиты
В связи с появлением новых решений в области нереляционных хранилищ, размывающих границу традиционного представления о СУБД (например, система кэширования данных в памяти MemcasheDB или Hadoop HDFS), определим функции, отличающие СУБД от файлового хранилища и других типов программных продуктов. В этом ключе в выделено несколько признаков. Переформулировав первый признак - «поддержание логически согласованного набора файлов», в силу активного развития in memory СУБД, осуществляющих хранение и все операции над данными в оперативной памяти, приведем эти критерии в следующей редакции:
Поддержание логически согласованного набора данных;
Обеспечение языка манипулирования дан- ными;
Восстановление информации после разного рода сбоев;
Реальная параллельная работа нескольких пользователей (процессов).
Используя такой подход, можно отделить именно СУБД от файловых систем и ПО другого вида.
Отличительной особенностью систем БД от остальных видов прикладного ПО является (относительно информационной безопасности и не только) их двойственная природа. С этой точки зрения СУБД включает в себя два компонента: хранимые данные (собственно БД) и программы управления (СУБД).
Обеспечение безопасности хранимой инфор- мации, в частности, невозможно без обеспечения безопасного управления данными. Исходя из этой концепции, все уязвимости и вопросы безопасности СУБД можно разделить на две категории: зависимые от данных и независимые от данных.
Отметим, что уязвимости, независимые от данных (их структуры, организации и т.д.), являются характерными для всех прочих видов ПО. К этой группе можно отнести несвоевременное обновление ПО или наличие неиспользуемых функций.
Зависимыми от данных (в той или иной степени) является большое число аспектов безопасности. В частности, зависимыми напрямую можно назвать механизмы логического вывода и агрегирования данных, называемые специфичными проблемами СУБД. В то же время многие уязвимости являются косвенно зависимыми от данных. Например, современные СУБД (считая и реляционные, и нереляционные решения) поддерживают запросы к данным с использованием некоторого языка запросов. В свою очередь, в этом качестве используются специализированные языки запросов (SQL, CQL, OQL и других), наборы доступных пользователю функций (которые, в свою очередь, тоже можно считать операторами запросного языка) или произвольные функции на языке программирования (чаще всего Java). Обобщенные интерфейсы работы с данными представлены на рисунке.
Архитектура применяемых языков, по крайней мере, то, что касается специализированных языков (запросов) и наборов функций, напрямую связана с моделью данных, применяемой для хранения информации. Таким образом, модель определяет особенности языка, а особенности языка - наличие в нем тех или иных уязвимостей. Причем уязвимости общего типа, например инъекция (под инъекцией будем понимать атаку на БД путем модификации входных запросов, заставляющую сервер СУБД выполнить нелегитимный набор действий), выполняются по-разному (SQL-инъекция, JAVA-инъек-ция) в зависимости от синтаксиса и семантики языка, которые, как уже сказано выше, отчасти определяются моделью данных и, следовательно, являются зависимым от данных компонентом.
Требования к безопасности БД
Таким образом, на основании разделения уязвимостей можно выделить зависимые и независимые от данных меры обеспечения безопасности хранилищ информации. Независимыми от данных мож-но назвать следующие требования к безопасной системе БД.
· Функционирование в доверенной среде.
Под доверенной понимается информационная среда, интегрирующая совокупность защитных механизмов, которые обеспечивают обработку информации без нарушения политики безопасности . В данном случае СУБД должна функционировать в доверенной информационной системе с соответствующими методами обмена данными.
· Организация физической безопасности файлов данных.
Данный вопрос требует более детального изучения, так как применяемые структуры данных в различных моделях данных СУБД могут иметь значение при шифровании и защите файлов данных. Однако в первом приближении вопрос физической безопасности файлов данных сходен с вопросом физической безопасности любых других файлов пользователей и приложений.
· Организация безопасной и актуальной настройки СУБД.
К данному аспекту относятся такие общие вопросы обеспечения безопасности, как своевременная установка обновлений, отключение неиспользуемых модулей или применение эффективной политики паролей.
Следующие требования можно назвать зависимыми от данных.
· Безопасность пользовательского слоя ПО.
· Безопасная организация данных и манипулирование ими.
Вопрос организации данных и управления ими является ключевым в системах хранения информации. Несмотря на то, что в приведенном перечне он указан последним, именно в эту область входят задачи организации данных с контролем целостности, обеспечение защиты от логического вывода и другие, специфичные для СУБД проблемы безо-пасности. Фактически эта задача включает в себя основной пул зависимых от данных уязвимостей и защиты от них.
Пути создания защищенных БД
Для преодоления названных проблем обеспечения информационной безопасности СУБД необходимо перейти от метода закрытия уязвимостей к комплексному подходу обеспечения безопасности хранилищ информации. Основными этапами этого перехода, по мнению авторов, должны стать следующие положения.
1. Разработка комплексных методик обеспечения безопасности хранилищ данных на текущем этапе.
Создание комплексных методик позволит применять их (или их соответствующие версии) при разработке хранилищ данных и пользовательского ПО. Основой для создания таких документов могут стать обобщающие проблематику работы, например или . Следование комплексной методике позволит избежать многих ошибок управления СУБД и защититься от наиболее распространенных на сегодняшний день уязвимостей.
2. Оценка и классификация угроз и уязвимостей СУБД.
Специализированная классификация угроз и уязвимостей СУБД позволит упорядочить их для последующего анализа и защиты, даст возможность установить зависимость между уязвимостями и причинами (источниками) их возникновения. В результате при введении конкретного механизма в СУБД появится возможность установить и спрогнозировать связанные с ним угрозы и заранее подготовить соответствующие средства обеспечения безопасности.
3. Разработка стандартных (применимых к различным СУБД без внесения изменений или с минимальными изменениями) механизмов обеспечения безопасности.
Стандартизация подходов и языков работы с данными позволит создать мультиплатформенные средства обеспечения безопасности, применимые к разным СУБД. С одной стороны, это методические и теоретические подходы, применимые в рамках модели данных. На сегодняшний день есть наработки таких механизмов по реляционной модели, однако они не решают всех насущных вопросов безопасности. С другой - это разработка теоретического базиса для новых СУБД, в частности, конкретизация и формализация агрегатных моделей данных. Появление готовых программных средств во многом зависит от производителей и разработчиков СУБД и их следования стандартам, а также достаточности определенных в стандарте средств для построения развитых механизмов безопасности.
4. Разработка теоретической базы информационной защиты систем хранения и манипулирования данными.
Выше отмечен ряд характерных особенностей, специфичных для хранилищ данных: двойственная природа СУБД, зависимость уязвимостей и механизмов управления от данных и описывающей их организацию модели, угрозы логического вывода, различная значимость сочетаний данных. Все это определяет специфический характер безопасности СУБД и требует новых теоретических подходов к обеспечению защиты данных в программных системах такого рода. Отдельный большой вопрос - развитие теоретического базиса в контексте формализации модели данных, а также разработка подходов обеспечения целостности информации для новых NoSQL-хранилищ.
На основании изложенного сделаем следующие выводы. В результате рассмотрения российских и зарубежных работ, а также ситуации на рынке СУБД в статье выделены текущий подход к обеспечению безопасности, принцип и основные эволюционные этапы систем БД. Сформулированы проблемы информационной безопасности современных СУБД: разнообразие языковых средств, появление новых моделей данных, не подкреп- ленных теоретическим базисом, необходимость поиска баланса между безопасностью и ее стоимостью, развитие систем защиты как реакции на потерю средств и престижа, а также общее невнимание к вопросам безопасности.
Сформулированы критерии, выделяющие СУБД из сходных программных продуктов, с учетом новых кластерных и in memory решений, особенности этого класса ПО с точки зрения информационной безопасности и предложено базовое деление уязвимостей на зависимые и независимые от данных и их организации.
В результате сформулированы общие требования к безопасности БД, перспективные пути исследования и развития систем защиты для построения надежных и защищенных серверов по обработке информации. В них вошли как систематизация и развитие существующих подходов в виде выработки методик и стандартизации механизмов защиты, так и направления новых исследований, например, классификация уязвимостей СУБД и формализация новых моделей данных, построение прогнозирующих средств защиты.
Литература
1. Исследование утечек информации за первое полугодие 2015 года. URL: http://www.infowatch.ru/analytics/reports/16340 (дата обращения: 26.02.2016).
2. Информационная безопасность бизнеса. Исследование текущих тенденций в области информационной безопасности бизнеса. 2014. URL: http://media.kaspersky.com/pdf/IT_risk_ report_Russia_2014.pdf (дата обращения: 26.02.2016).
3. Sandhu Ravi S., Jajodia Sushil. Data and database security and controls. Handbook of Information Security Management, Auerbach Publishers, 1993, pp. 181-199.
4. Qiu M., Davis S. Database security mechanisms and implementation. IACIS, Issues in Inform. Syst. 2002, vol. 03, pp. 529-534.
5. Lesov P. Database security: a historical perspectiv. 2010. URL: http://arxiv.org/ftp/arxiv/papers/1004/1004.4022.pdf (дата обращения: 26.02.2016).
6. Burtescu E. Database security - attacks and control me- thods. Journ. of Applied Quantitative Methods, 2009, vol. 4, no. 4, pp. 449-454.
7. Rohilla S., Mittal P.K. Database Security: Threads and Challenges. Intern. Journ. of Advanced Research in Computer Science and Software Engineering, 2013, vol. 3, iss. 5, pp. 810-813.
8. Потапов А.Е., Манухина Д.В., Соломатина А.С., Бадмаев А.И., Яковлев А.В., Нилова А.С. Безопасность локальных баз данных на примере SQL Server Compact // Вестн. Тамбов. ун-та. Серия: Естественные и технические науки. 2014. № 3. С. 915-917.
9. Бортовчук Ю.В., Крылова К.А., Ермолаева Л.В. Информационная безопасность в современных системах управления базами данных // Современные проблемы экономического и социального развития. 2010. № 6. С. 224-225.
10. Горбачевская Е.Н., Катьянов А.Ю., Краснов С.С. Информационная безопасность средствами СУБД Oracle // Вестн. ВУиТ. 2015. № 2 (24). С. 72-85.
11. Ткаченко Н.О. Реализация монитора безопасности СУБД MySQL в dbf/dam системах // ПДМ. Приложение. 2014. № 7. С. 99-101.
12. Полтавцева М.А. Задача хранения прав доступа к данным в РСУБД на примере Microsoft SQL Server // Актуальные направления фундаментальных и прикладных исследований: матер. V Междунар. науч.-практич. конф. 2015. С. 118-120.
13. Баранчиков А.И., Баранчиков П.А., Пылькин А.Н. Алгоритмы и модели доступа к записям БД. М.: Горячая линия-Телеком, 2011. 182 с.
14. Поляков А.М. Безопасность Oracle глазами аудитора: нападение и защита. М.: ДМК Пресс, 2014. 336 с.
15. Смирнов С.Н. Безопасность систем баз данных. М.: Гелиос АРВ, 2007. 352 с.
16. Murray M.C. Database security: what students need to know. JITE:IIP, vol. 9, 2010, pp. 61-77.
17. Database Security Technical Implementation Guide (STIG). US Department of Defense. Vers. 7. Release 1. 2004. URL: https://www.computer.org/ cms/s2esc/s2esc_excom/Minutes/2005-03/DISA%20STIGs/DATABASE-STIG-V7R1.pdf (дата обращения: 26.02.2016).
18. Зегжда П.Д. Обеспечение безопасности информации в условиях создания единого информационного пространства // Защита информации. Инсайд. 2007. № 4 (16). С. 28-33.
19. Top Ten Database Security Threats. URL: http://www.imperva.com/docs/wp_topten_database_threats.pdf IMPREVA 2015 (дата обращения: 26.02.2016).
20. Кузнецов С.Д. Базы данных: учебник для студ. М.: Академия, 2012. 496 с.
21. Зегжда Д.П., Калинин М.О. Обеспечение доверенности информационной среды на основе расширения понятия «целостность» и управления безопасностью // Проблемы информ. безопасности. Компьютерные системы. 2009. № 4. С. 7-16.
22. Полтавцева М.А., Зегжда Д.П., Супрун А.Ф. Безопасность баз данных: учеб. пособие. СПб: Изд-во СПбПУ, 2015. 125 с.
База данных представляет собой важнейший корпоративный ресурс, который должен быть надлежащим образом защищен с помощью соответствующих средств контроля. Существуют такие опасности, как:
Вопросы защиты данных часто рассматриваются вместе с вопросами
поддержки целостности данных (по крайней мере, в неформальном контексте),
хотя на самом деле это совершенно разные понятия. Термин защита
относится к защищенности данных от несанкционированного доступа, изменения или умышленного разрушения, а целостность к точности или достоверности данных. Эти термины можно определить, как показано ниже.
их разрушения при доступе со стороны санкционированных пользователей.
Другими словами, защита данных получение гарантий, что пользователям разрешено выполнять те действия, которые они пытаются выполнить, а поддержка целостности получение гарантий, что действия, которые пользователи пытаются выполнить, будут допустимыми.
Между этими понятиями есть некоторое сходство, поскольку как при обеспечении защиты данных, так и при обеспечении поддержки их целостности система вынуждена проверять, не нарушаются ли при выполняемых пользователем действиях некоторые установленные ограничения. Эти ограничения формулируются (обычно администратором базы данных) на некотором подходящем языке и сохраняются в системном каталоге. Причем в обоих случаях СУБД должна каким-то образом отслеживать все выполняемые пользователем действия и проверять их соответствие установленным ограничениям.
Эти две темы обсуждаются раздельно, так как целостность данных является фундаментальным понятием, тогда как защита данных -- понятием вторичным, несмотря на его большую практическую важность (особенно в наши дни повсеместного распространения Internet, электронной коммерции и соответствующих средств доступа).
Ниже описаны многочисленные аспекты проблемы защиты данных.
Обычно в современных СУБД поддерживается один из двух широко распространенных методов организации защиты данных -- избирательный или мандатный, а иногда оба этих метода. В обоих случаях единица данных (или объект данных), для которой организуется защита, может выбираться из широкого диапазона, от всей базы данных до конкретных компонентов отдельных кортежей. Различия между двумя указанными методами кратко описаны ниже.
В случае избирательного контроля каждому пользователю обычно предоставляются различные права доступа (иначе называемые привилегиями, или полномочиями) к разным объектам. Более того, разные пользователи, как правило, обладают разными правами доступа к одному и тому же объекту. (Например, пользователю U1 может быть разрешен доступ к объекту А, но запрещен доступ к объекту B, тогда как пользователю U2 может быть разрешен доступ к объекту B, но запрещен доступ к объекту А.) Поэтому избирательные схемы характеризуются значительной гибкостью.
В случае мандатного контроля, наоборот, каждому объекту данных назначается некоторый классификационный уровень, а каждому пользователю присваивается некоторый уровень допуска. В результате право доступа к объекту данных получают только те пользователи, которые имеют соответствующий уровень допуска. Мандатные схемы обычно имеют иерархическую структуру и поэтому являются более жесткими. (Если пользователь U1 имеет доступ к объекту А, но не имеет доступа к объекту B, то в схеме защиты объект B должен будет располагаться на более высоком уровне, чем объект А, а значит, не может существовать никакого пользователя U2, который будет иметь доступ к объекту B, но не будет иметь доступа к объекту А.)
Независимо от того, какая схема используется (избирательная или мандатная), все решения относительно предоставления пользователям прав на выполнение тех или иных операций с теми или иными объектами должны приниматься исключительно управленческим персоналом. Поэтому все эти вопросы выходят за пределы возможностей самой СУБД, и все, что она способна сделать в данной ситуации, -- привести в действие решения, которые будут приняты на другом уровне. Исходя из этих соображений, можно определить приведенные ниже условия.
Также следует отметить, что в настоящее время существуют намного более сложные методы аутентификации по сравнению с простой проверкой паролей, в которых для аутентификации применяется целый ряд биометрических устройств: приборы для чтения отпечатков пальцев, сканеры радужной оболочки, анализаторы геометрических характеристик ладони, приборы проверки голоса, устройства распознавания подписей и т.д. Все эти устройства могут эффективно использоваться для проверки "персональных характеристик, которые никто не может подделать".
Кстати, в отношении идентификаторов пользователей следует заметить, что один и тот же идентификатор может совместно применяться для целого ряда разных пользователей, входящих в состав некоторой группы. Таким образом, система может поддерживать группы пользователей (называемые также ролями), обеспечивая одинаковые права доступа для всех ее членов, например, для всех работников бухгалтерского отдела. Кроме того, операции добавления новых пользователей в группу или их удаления из нее можно выполнять независимо от операций задания привилегий доступа для этой группы на те или иные объекты.
Избирательная схема управления доступом
Следует еще раз отметить, что во многих СУБД поддерживается либо избирательная, либо мандатная схема управления доступом, либо оба типа доступа одновременно. Однако точнее все же будет сказать, что в действительности в большинстве СУБД поддерживается только избирательная схема доступа и лишь в некоторых -- только мандатная. Поскольку на практике избирательная схема доступа встречается гораздо чаще.
Для определения избирательных ограничений защиты необходимо использовать некоторый язык. По вполне очевидным причинам гораздо легче указать то, что разрешается, чем то, что не разрешается. Поэтому в подобных языках обычно поддерживается определение не самих ограничений защиты, а полномочий, которые по своей сути противоположны ограничениям защиты (т.е. они разрешают какие-либо действия, а не запрещают их). Дадим краткое описание гипотетического языка определения полномочий, воспользовавшись следующим примером.
GRANT RETRIEVE { S#, SNAME, CITY }, DELETE
TO Jim, Fred, Mary ;
Этот пример иллюстрирует тот факт, что в общем случае полномочия доступа включают четыре описанных ниже компонента.
Ниже приводится общий синтаксис оператора определения полномочий.
AUTHORITY
GRANT
ON
TO
Мандатная схема управления доступом
Методы мандатного управления доступом применяются к тем базам данных, в которых хранимая информация имеет достаточно статичную и жесткую структуру, что свойственно, например, некоторым военным или правительственным организациям. Основная идея состоит в том, что каждому объекту данных присваивается некоторый классификационный уровень (или требуемый гриф секретности, например "Совершенно секретно", "Секретно", "Для служебного пользования" и т.д.), а каждому пользователю предоставляется уровень допуска с градациями, аналогичными существующим классификационным уровням. Предполагается, что эти уровни образуют строгую иерархическую систему (например, "Совершенно секретно" > "Секретно" > "Для служебного пользования" и т.д.). Тогда исходя из этих положений можно сформулировать два очень простых правила, впервые предложенные Беллом и Ла-Падулой.
Первое правило достаточно очевидно, тогда как второе требует дополнительных пояснений. Прежде всего, следует отметить, что иным образом второе правило можно сформулировать так: "По определению любая информация, записанная пользователем i, автоматически приобретает классификационный уровень, который равен уровню допуска пользователя i". Подобное правило необходимо, например, для того, чтобы предотвратить запись секретных данных, выполняемую пользователем с уровнем допуска
"Секретно", в файл с меньшим уровнем классификации, что нарушит всю систему секретности.
Шифрование данных
Ранее предполагалось, что некий злонамеренный пользователь пытается незаконно проникнуть в базу данных с помощью обычных средств доступа, имеющихся в системе. Теперь следует рассмотреть случай, когда он пытается проникнуть в базу данных, минуя систему, т.е. физически перемещая внешние носители информации или подключаясь к линии связи. Наиболее эффективным методом борьбы с такими угрозами является шифрование данных, т.е. хранение и передача особо важных данных в зашифрованном виде.
Для изучения основных концепций шифрования данных следует ввести некоторые новые понятия. Исходные (незашифрованные) данные называются открытым текстом.
Открытый текст шифруется с помощью специального алгоритма шифрования. В качестве входных данных для такого алгоритма выступают открытый текст и ключ шифрования, а в качестве выходных-- преобразованная форма открытого текста, которая называется шифрованным текстом. Детали алгоритма шифрования могут быть опубликованы, но ключ шифрования ни в коем случае не разглашается. Именно зашифрованный текст, непонятный всем, кто не обладает ключом шифрования, хранится в базе данных и передается по линии связи.
Пример 5.1. Пусть в качестве открытого текста дана следующая строка.
AS KINGFISHERS CATCH FIRE (Здесь для простоты изложения предполагается, что данные состоят только из пробелов и прописных символов.) Кроме того, допустим, что ключом шифрования является следующая строка.
Ниже описывается используемый алгоритм шифрования.
1. Разбить открытый текст на блоки, длина которых равна длине ключа шифрования.
AS+KI NGFIS HERS+ CATCH +FIRE
FDIZB SSOXL MQ+GT HMBRA ERRFY
Если известен ключ шифрования, то процедура расшифровки в этом примере может быть выполнена достаточно просто. Вопрос заключается в том, насколько сложно нелегальному пользователю определить ключ шифрования, обладая открытым и зашифрованным текстами. В данном простом примере это не очень сложно выполнить, однако вполне очевидно, что можно разработать и более сложные схемы шифрования. В идеале, схема шифрования должна быть такой, чтобы усилия, затраченные на ее расшифровку, во много раз превышали полученную при этом выгоду. (Фактически это замечание применимо ко всем аспектам проблемы обеспечения безопасности, т.е. стоимость осуществления попыток взлома системы защиты должна быть значительно выше потенциальной выгоды от этого.) Конечной целью поиска таких схем следует считать схему, для которой сам ее разработчик, обладая открытым и зашифрованным вариантами одной и той же части текста, не в состоянии определить ключ и, следовательно, расшифровать другую часть зашифрованного текста.
Управление безопасностью обычно осуществляется на трех уровнях:
На уровне операционной системы у администратора базы данных (АБД) должны быть права для создания и удаления относящихся к базе данных файлов. Напротив, у обычных пользователей таких прав быть не должно. Информация о безопасности на уровне операционной системы приведена в стандартной документации Oracle. Во многих крупных организациях АБД или администратор по безопасности базы данных работают в тесном контакте с администраторами вычислительной системы, чтобы координировать усилия по разработке требований и практических мероприятий, направленных на обеспечение безопасности.
В требованиях к безопасности базы данных описываются процедуры предоставления доступа к базе путем назначения каждому пользователю пары имя/пароль (username/password). В требованиях может также оговариваться ограничение объема ресурсов (дискового пространства и процессорного времени), выделяемых одному пользователю, и постулироваться необходимость аудита действий пользователей. Механизм обеспечения безопасности на уровне базы данных также обеспечивает управление доступом к конкретным объектам схемы базы данных.
