бд. Курсовой бд. Безопасность баз данных

Название	Безопасность баз данных
Дата	06.12.2021
Размер	44.38 Kb.
Формат файла
Имя файла	Курсовой бд.docx
Тип	Курсовая #293903

Министерство образования и науки Республики Казахстан
Казахстанско-Американский Свободный университет

КУРСОВАЯ РАБОТА
На тему: «Безопасность баз данных.»
по образовательной программе 6B06101 - «Информационные системы»

Выполнил студент 3-го курса Н.О. Курочкин
Проверил Б.К. Увалиев

Усть-Каменогорск, 2020 г.

Введение

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

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

Среди представителей баз данных одними из самых распространённых являются такие базы данных как Microsoft SQL server и Oracle, а системой управления базами данных Microsoft Access, Borland dBase.

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

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

Основная часть

Защита информации

Понятие защиты информации

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

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

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

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

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

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

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

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

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

Надёжность ДВБ зависит только от её реализации и корректности введённых данных.

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

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

Управление доступом

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

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

Существует три метода управления доступом:

Дискреционный;
Обязательный;
Ролевой.

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

Модель дискреционного контроля доступа

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

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

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

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

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

Модель обязательного контроля доступа

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

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

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

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

Но в данной модели есть два случая благодаря которым ставится вопрос её непротиворечивости.

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

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

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

Ролевая модель контроля за доступом

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

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

Простота администрирования

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

Иерархия ролей

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

Принцип наименьшей привилегии

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

Разделение обязанностей

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

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

Области применения

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

Фундаментальные различия

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

Настройка политики безопасности;
Распределение прав доступа пользователей к объектам.

Основные уязвимости

Программные атаки

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

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

$res = mysql_query("SELECT * FROM shop WHERE id_toy = ".$_GET['id']);

В таком случае если на сайте будет находиться ссылка на товар с идентификатором 17, то после нажатия на данный товар произойдёт переадресация по адресу, например, site.kz/script.php?id=17, и выполнится запрос:
SELECT * FROM shop WHERE id_toy = 17

Злоумышленник также может и изменить адрес в адресной строке, к примеру site.kz/script.php?id=-1+OR+1=1, и в результате получаем совершенно другой запрос

SELECT * FROM shop WHERE id_toy = -1 OR 1=1

Данная конструкция запроса выводит на экран все записи из таблицы toy, так как выражение 1=1 всегда истинно. В таком случае нарушается логика работы скрипта, и к примеру, на экран пользователей будет выведен полный список ассортимента, даже то что не используется и скрыто от глаз рядового пользователя. Так же если злоумышленник увидит, что сайт поддаётся таким простым атакам, он может и не остановиться, и попытаться узнать к примеру адреса и банковские карты клиентов.

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

SELECT id_toy, header, body, fabricator FROM shop WHERE id_toy = ".$_GET['id']

Злоумышленник в качестве значения id может передать произвольный параметр. Также если ему необходимо получить данные в определённой таблице он может угадать её название, с помощью ввода в адресной строке site.kz/script.php?id=1+UNION+SELECT+1, address, card,1+FROM+basket. Для выполнения данного скрипта используется запрос

SELECT id_toy, header, body, fabricator FROM shop WHERE id_toy = -1 UNION SELECT 1, address, card, 1 FROM basket

Из таблицы toy не будет выбрано ни единой записи, так как игрушки с идентификатором -1 нет. В то же время результатом будут записи из таблицы basket.

В некоторых случаях SQL-запрос в уязвимом скрипте имеет достаточно сложную структуру, которая усложняет использование оператора UNION. Данный код немного затрудняет закачку SQL:
SELECT fabricator FROM shop WHERE id=".$_GET['id']." AND fabricator LIKE ('a%')"

Этот запрос отображает название фабрики производителя только в случае если в его названии содержится буква «А». Так как после проверки идентификатора используется проверка первой буквы названия фирмы производителя, использование оператора UNION сделает запрос некорректным. Для того чтобы провести атаку злоумышленнику необходимо отбросить второе условие, данная манипуляция может быть выполнена при помощи экранирования части запроса используя обозначение комментирования /* или -, данная манипуляция может быть выполнена путём изменения строки в 1+UNION+SELECT+ fabricator+FROM+admin/* в качестве значения для параметра id, из чего вытекает следующий запрос:

SELECT fabricator FROM shop WHERE id=-1 UNION SELECT card FROM basket/* AND fabricator LIKE ('a%')

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

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

Физическая безопасность

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

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

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

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

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

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

Комнаты IT-безопасности;
Сейфы IT-безопасности (дата-сейфы);
Сейфы для защиты носителей информации (медиа-сейфы).

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

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

Человеческий фактор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Реализация защиты в некоторых СУБД

Архитектура безопасности Access

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

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

MS SQL Server: Защита, управление доступом

Защита и доступ

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

Если говорить о симметричной архитектуре, то операции резервного копирования и восстановления могут делиться на несколько потоков и выполняться одновременно, благодаря преимуществам асинхронного ввода/вывода. Параллельное резервное копирование поддерживает до 32 одновременно запущенных резервных устройств, благодаря чему можно быстро и без проблем создавать резервные копии достаточно больших объёмов для подстраховки. Благодаря возможности резервного копирования и восстановления отдельных таблиц в совокупности экономится большое количество времени и места на носителе без необходимости создавать резервную копию всей базы. Но в то же время во время резервного копирования отдельно выбранной таблицы накладывает на неё статус блокировки Exclusive. Так же резервным копиям может быть задан параметр их существования, т.е. срок их хранения до удаления или перезаписи, или же утрата её актуальности. В качестве резервных устройств так же могут быть использованы временные устройства, которые не входят в состав базы данных и не имеют записей в системной таблице sysdevices.

В небольших по объёму базах данных журнал транзакций обычно хранится на том же устройстве что и сама база и архивируется вместе с ней. Журнал транзакций ведётся по принципу Write-Ahead, что в своё время означает, что любое изменение в базе данных сначала отражается в журнале, и только потом записывается в базу. В том случае если журнал транзакций расположен на отдельном устройстве существует возможность отдельного создания его резервной копии. Для примера можем предположить, что сохранение журнала транзакций выполняется ежедневно, в то время как страховочная копия всей базы может выполняться один-два раза в неделю, из-за того, что архивирование журнала транзакций выполняется гораздо быстрее и в результате занимает меньше места, чем дамп целой базы данных. Отличием резервирования базы данных от дампа является то, что дамп журнала транзакций очищает его неактивную часть, т.е. все завершившиеся с момента последнего дампа транзакции, но только в том случае если опция NO_TRUNCATE не была использована. Команда DUMP TRANSACTION TRUNCATE_ONLY позволяет очистить журнал транзакций в том случае если он переполнен. В том случае если резервное копирование транзакций не представляет интереса, то можно включить событие checkpoint благодаря которому будут очищены последние завершённые транзакции в базе до момента наступления этого события. В смысл механизма checkpoint закладывается периодическая запись данных из кэша на диск, для избегания грязных данных, такие события постоянно регистрируются MS SQL Server или же создаются по инициативе пользователя. Во время восстановления журнала транзакций требуемые операции применяются к базе данных, в следствии этого получаем, что при создании резервной копии в начале недели с последующей архивацией транзакций за каждый день, то при необходимости восстановления базы поднимается её состояние на начало недели и в неё последовательно добавляются журналы транзакций вплоть до следующего начала недели. MS SQL Server 6.5 включает в себя возможность восстановление записей из журнала транзакций не требуемый момент времени, который был отражён в журнале, при помощи команды LOAD TRANSACTION STOPAT или же в окне программы в разделе восстановления базы данных путём выбора опции Until time (до необходимого времени).

MS SQL Server 6.5 предусматривает возможность запуска зеркального устройства, эта возможность позволяет вносить изменения в оригинальную базу данных без необходимости её остановки или каких-либо помех в работоспособности, после завершения всех необходимых манипуляций данную функцию можно выключить и база данных в дальнейшем будет работать на отредактированной системе, а пользователи не заметят кратковременной задержки.

Если начать перечислять преимущества интеграции с операционной системой, то MS SQL Server использует в своей работе сервисы безопасности Windows NT, которая на сегодняшний день сертифицирована по классу безопасности C2/E3. MS SQL Server может быть настроен на работу в одном из трёх режимов безопасности.

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

Стандартный режим, под которым понимается, что на MS SQL Server будут вноситься самостоятельно введённые login id и соответствующие пароли.

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

MS SQL Server использует многоуровневую проверку привилегий при загрузке на сервер. В первую очередь идентифицируются права пользователя на установку соединения с сервером (авторизация, т.е. вводи логина пароля) и выполнение административных функций таких как создание устройств и баз данных, назначение прав доступа другим пользователям, изменение параметров сервера и т.д., максимальными правами обладает системный администратор. На уровне базы данных каждый пользователь, выполнивший успешный вход на сервер имеет своё имя пользователя (username) и права доступа на объекты находящиеся внутри базы данных. Пользователю по отношению к объектам могут быть выданы такие разрешения как:

Чтение;
Добавление;
Удаление;
Изменение;
Декларативная ссылочная целостность;
Выполнение хранимых процедур;
Права на доступ к отдельным полям.

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

Система безопасности SQL Server имеет несколько уровней безопасности, такие как:

Операционная система;
SQL Server;
База данных;
Объект базы данных.

В то же время механизм безопасности предполагает ещё и существование четырёх типов пользователей:

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

Модель безопасности SQL Server включает в себя следующие компоненты:

Тип подключения к SQL Server;
Пользователь базы данных;
Пользователь (гость);
Роли.

При подключении к SQL Server поддерживается два режима безопасности:

Режим аутентификации Windows NT;
Смешанный режим аутентификации.

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

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

Пользователи базы данных и их роли

бд. Курсовой бд. Безопасность баз данных

Оглавление

Основная часть

Защита информации

Основные уязвимости

Реализация защиты в некоторых СУБД