Проблема обеспечения информационной безопасности баз данных является. Основные аспекты безопасности субд: что следует знать. Базы данных и системы управления базами данных

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

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

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

История развития СУБД

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

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

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

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

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

Современные проблемы обеспечения безопасности БД

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

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

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

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

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

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

Особенности защиты БД

Хранилища данных включает в себя два компонента: хранимые данные (собственно БД) и программы управления (СУБД).

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

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

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

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

Требования к безопасности БД

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

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

Функционирование в доверенной среде.

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

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

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

Организация безопасной и актуальной настройки СУБД.

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

Следующие требования можно назвать зависящими от данных :

Безопасность пользовательского ПО.

Сюда можно отнести задачи построения безопасных интерфейсов и механизмов доступа к данным.

Безопасная организация и работа с данными.

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

Основные аспекты создания защищенных БД

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

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

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

Оценка и классификация угроз и уязвимостей СУБД.

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

Разработка стандартных механизмов обеспечения безопасности.

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

Об авторе

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

Под безопасностью подразумевается, что некоторому пользователю разрешается выполнять некоторые действия.
СУБД должны соблюдать 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 контрольных журнала:
. Журнал привилегий (происходит отслеживание использования привилегий)
. Журнал операторов (отслеживает, какие операторы используются часто для объектов, потом можно что-то превращать в процедуры, улучшать быстродействие, важный журнал)
. Журнал объектного уровня (контролирует доступ к объектам)

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

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

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

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

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

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

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

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

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

Режимы работы с базами данных

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

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

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

Дудкина Анастасия Сергеевна , бакалавр, студент
Башкирский государственный аграрный университет

ЗАЩИТА
PHPMYADMIN
MYSQL
БАЗА ДАННЫХ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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