5.1. Методы обеспечения безопасности

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

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

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

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

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

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

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

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

Перечисленные выше методы управления доступом на самом деле являются частью более общей классификации уровней безопасности. Прежде всего в этих документах определяется четыре класса безопасности (security classes) – D, С, В и А. Среди них класс D наименее безопасный, класс С – более безопасный, чем класс D, и т.д. Класс D обеспечивает минимальную защиту, класс С – избирательную, класс В – обязательную, а класс А – проверенную защиту.

Избирательная защита. Класс С делится на два подкласса – С1 и С2 (где подкласс С1 менее безопасен, чем подкласс С2), которые поддерживают избирательное управление доступом в том смысле, что управление доступом осуществляется по усмотрению владельца данных.

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

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

Обязательная защита. Класс В содержит требования к методам обязательного управления доступом и делится на три подкласса – В1, В2 и В3 (где В1 является наименее, а В3 – наиболее безопасным подклассом).

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

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

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

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

Хотя некоторые коммерческие СУБД обеспечивают обязательную защиту на уровне класса В1, обычно они обеспечивают избирательное управление на уровне класса С2.

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

Избирательное управление доступом поддерживается многими СУБД. Избирательное управление доступом поддерживается в языке SQL.

В общем случае система безопасности таких СУБД базируется на трех компонентах:

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

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

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

5.3. Обязательное управление доступом

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

1. пользователь имеет доступ к объекту, только если его уровень допуска больше или равен уровню классификации объекта.

2. пользователь может модифицировать объекту, только если его уровень допуска равен уровню классификации объекта.

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

В последнее время методы обязательного управления доступом получили широкое распространение. Требования к такому управлению доступом изложены в двух документах, которые неформально называются "оранжевой" книгой (Orange Book) и "розовой" книгой (Lavender Book). В "оранжевой" книге перечислен набор требований к безопасности для некой "надежной вычислительной базы" (Trusted Computing Base), а в "розовой" книге дается интерпретация этих требований для систем управления базами данных.

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

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

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

5.5. Контрольный след выполняемых операций

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

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

2. терминал, с которого была вызвана операция;

3. пользователь, задавший операцию;

4. дата и время запуска операции;

5. вовлеченные в процесс исполнения операции базовые отношения, кортежи и атрибуты;

6. старые значения;

7. новые значения.

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

5.6. Поддержка мер обеспечения безопасности в языке SQL

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

5.7. Директивы GRANT и REVOKE

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

Обратите внимание, что создателю любого объекта автоматически предоставляются все привилегии в отношении этого объекта.

Стандарт SQL1 определяет следующие привилегии для таблиц:

1. SELECT – позволяет считывать данные из таблицы или представления;

INSERT – позволяет вставлять новые записи в таблицу или представление;

UPDATE – позволяет модифицировать записи из таблицы или представления;

DELETE – позволяет удалять записи из таблицы или представления.

Стандарт SQL2 расширил список привилегий для таблиц и представлений:

1. INSERT для отдельных столбцов, подобно привилегии UPDATE;

2. REFERENCES – для поддержки внешнего ключа.

Помимо перечисленных выше добавлена привилегия USAGE – для других объектов базы данных.

Кроме того, большинство коммерческих СУБД поддерживает дополнительные привилегии, например:

1. ALTER – позволяет модифицировать структуру таблиц (DB2, Oracle);

2. EXECUTE – позволяет выполнять хранимые процедуры.

Создатель объекта также получает право предоставить привилегии доступа какому-нибудь другому пользователю с помощью оператора GRANT. Ниже приводится синтаксис утверждения GRANT:

GRANT {SELECT|INSERT|DELETE|(UPDATE столбец, …)}, …

ON таблица ТО {пользователь | PUBLIC}

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

Если задана директива WITH GRANT OPTION, это значит, что указанные пользователи наделены особыми полномочиями для заданного объекта – правом предоставления полномочий. Это, в свою очередь, означает, что для работы с данным объектом они могут наделять полномочиями других пользователей

Например: предоставить пользователю Ivanov полномочия для осуществления выборки и модификации фамилий в таблице Students с правом предоставления полномочий.

GRANT SELECT, UPDATE StName

ON Students ТО Ivanov WITH GRANT OPTION

Если пользователь А наделяет некоторыми полномочиями другого пользователя В, то впоследствии он может отменить эти полномочия для пользователя В. Отмена полномочий выполняется с помощью директивы REVOKE с приведенным ниже синтаксисом.

REVOKE {{SELECT | INSERT | DELETE | UPDATE},…|ALL PRIVILEGES}

ON таблица,… FROM {пользователь | PUBLIC},… {CASCADE | RESTRICT}

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

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

ON Students FROM Ivanov CASCADE

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

5.8. Представления и безопасность

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

Заключение

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

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

Первая часть статьи посвящена новшествам в управлении доступом к данным и сервисам. Продолжение статьи посвящено минимизации привилегий для исполняемого кода, шифрованию трафика и данных в SQL Server 2005, а также некоторым другим аспектам безопасности этой СУБД. В третьей части статьи представлены некоторые рекомендации для администраторов сетей и разработчиков приложений, а также рассмотрены средства обеспечения безопасности разных редакций SQL Server в сравнении с некоторыми другими СУБД. Цель данной статьи - обратить внимание администраторов баз данных и специалистов по информационной безопасности на данную проблему и показать один из вариантов реализации атаки на СУБД MS SQL, в результате которой потенциальный нарушитель получит доступ не только к хранимой в базе данных информации, но и полный контроль над сервером СУБД. Обеспечение безопасности корпоративных баз данных - сегодня одна из самых актуальных тем. И это понятно. Однако парадокс заключается в том, что уделяя огромное внимание защите баз данных снаружи, многие забывают защищать их изнутри. После трагедии 11 сентября американское правительство начало реализацию широкого комплекса мер по предотвращению террористических атак. Одна из таких мер заключается в поддержке разработки и внедрении ИТ с целью выявления и задержания подозрительных лиц, а также в снижении риска угроз безопасности и предотвращении ситуаций, допускающих проведения такого рода атак. Один из технологических элементов, необходимых, в частности, для предотвращения проявлений терроризма, - технология баз данных. Обычно такая задача возлагается на администраторов БД,у которых нет для этого ни времени ни необходимой подготовки. Из чего складывается рабочий день администратора баз данных? Конечно, всё зависит от того, какой ответ вы хотите получить - краткий или развернутый. Пространный ответ растянется на мили: инсталляция, переход на новую версию, планирование производительности, настройка, обеспечение работоспособности приложений и восстановления данных по резервным копиям. Это только первые пункты списка, он не включает срочные меры, которые приходится принимать ежедневно. В современных условиях любая деятельность сопряжена с оперированием большими объемами информации, которое производится широким кругом лиц. Защита данных от несанкционированного доступа является одной из приоритетных задач при проектировании любой информационной системы. Следствием возросшего в последнее время значения информации стали высокие требования к конфиденциальности данных. Системы управления базами данных, в особенности реляционные СУБД, стали доминирующим инструментом в этой области. Обеспечение информационной безопасности СУБД приобретает решающее значение при выборе конкретного средства обеспечения необходимого уровня безопасности организации в целом. ЕСЛИ ПРЕДПРИЯТИЕ ДОРОЖИТ СВОЕЙ ИНТЕЛЛЕКТУАЛЬНОЙ СОБСТВЕННОСТЬЮ, И КАЖДЫЙ РАБОТНИК МОЖЕТ ЛЕГКО ПОЛУЧИТЬ НЕОБХОДИМУЮ (И НЕ БОЛЕЕ ТОГО) ИНФОРМАЦИЮ, ТО КОМПАНИЯ МОЖЕТ НАДЕТЬСЯ НА РОСТ ПРОИЗВОДИТЕЛЬНОСТИ. НО ЕСЛИ ДАННЫЕ НЕ УПОРЯДОЧЕНЫ, ТО, НЕСМОТРЯ НА ЭНТУЗИАЗМ СОТРУДНИКОВ, В БОЛЬШИНСТВЕ СЛУЧАЕВ ПРЕДПРИЯТИЕ ОЖИДАЕТ КРАХ. Практически ни одна современная компания не может обойтись без использования баз данных. В самом простом случае для хранения небольших объемов данных в качестве системы управления базами данных (СУБД) может использоваться система Microsoft Access.

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

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

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

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

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

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

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

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

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

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

2.1. Источники угроз информации баз данных

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

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

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

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

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

Сбои и отказы в аппаратуре вычислительных средств;

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

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

Внутренними источниками угроз безопасности баз данных и СУБД являются:

Системные ошибки при постановке целей и задач проектирования автоматизированных информационных систем и их компонент, допущенные при формулировке требований к функциям и характеристикам средств обеспечения безопасности системы;

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

Ошибки проектирования при разработке и реализации алгоритмов обеспечения безопасности аппаратуры, программных средств и баз данных;

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

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

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

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

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

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

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

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

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

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

Классификация по цели реализации угрозы:

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

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

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

Классификация по природе возникновения угрозы:

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

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

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

1. Угрозы, непосредственным источником которых является человек:

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

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

Копирование конфиденциальных данных легальным пользователем системы с целью неправомерного использования (продажа, шантаж и т. п.);

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

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

2. Угрозы, непосредственным источником которых являются штатные программно-аппаратные средства информационной системы:

Неквалифицированное использование или ошибочный ввод параметров программ, способных привести к полной или частичной потере работоспособности системы (аварийное завершение системных процессов, нецелевое расходование вычислительных ресурсов и т. п.);

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

Отказы и сбои в работе операционной системы, СУБД и прикладных программ.

3. Угрозы, непосредственным источником которых являются несанкционированно используемые программно-аппаратные средства:

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

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

Заражение компьютера вирусами с деструктивными функциями;

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

4. Угрозы, непосредственным источником которых является среда обитания:

Внезапное и длительное отключение систем электропитания;

Техногенные и природные катастрофы;

Всплески природных электромагнитных излучений.

Классификация по расположению источника угроз.

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

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

Блокирование физического доступа на объект размещения автоматизированной системы обслуживающего персонала или пользователей;

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

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

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

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

Считывание конфиденциальной информации из аппаратных средств телекоммуникационной или вычислительной техники с использованием перехвата электромагнитных излучений;

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

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

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

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

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

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

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

Физическое разрушение элементов серверов и коммутационной аппаратуры;

Выключение электропитания серверов и коммутационной аппаратуры;

Остановка серверных и иных критически важных для функционирования автоматизированной системы процессов;

Уничтожение или модификация критически важных для функционирования автоматизированной системы файлов операционной системы;

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

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

1. Угрозы нарушения информационной безопасности данных, хранимых на внешних запоминающих устройствах:

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

Нарушение конфиденциальности, уничтожение или модификация данных, созданных штатными средствами ведения журнала изменений баз данных;

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

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

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

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

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

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

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

Организация имитации процесса установления взаимодействия с сервером (ложной сессии) с целью получения идентификаторов и аутентифицирующей информации пользователей;

Изменение элементов данных, выводимых на терминал пользователя за счет перехвата потока вывода;

Изменение элементов данных, выводимых на принтер за счет перехвата потока вывода.

Классификация по характеру воздействия на информационную систему (целесообразно выделить два варианта):

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

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

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

Физического;

Технологического;

Логического (процедурного);

Человеческого.

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

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

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

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

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

2.3. Угрозы, специфичные для систем управления базами данных

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

Угрозы конфиденциальности информации.

К угрозам такого типа можно отнести:

1. Инъекция SQL. Во многих приложениях используется динамический SQL- формирование SQL-предложений кодом программы путем конкатенации строк и значений параметров. Зная структуру базы данных, злоумышленник может либо выполнить хранимую программу в запросе, либо закомментировать «легальные» фрагменты SQL-кода, внедрив, например, конструкцию UNION, запрос которой возвращает конфиденциальные данные. II последнее время даже появились специальные программы, автоматизирующие процесс реализации подобных угроз.

2. Логический вывод на основе функциональных зависимостей.

3. Логический вывод на основе ограничений целостности.

Для кортежей отношений в реляционной модели данных (РМД) можно задать ограничения целостности - логические условия, которым должны удовлетворять атрибуты кортежей.

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

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

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

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

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

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

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

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

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Министерство образования и науки Российской Федерации

Частное учреждение образовательная организация высшего образования

"Омская гуманитарная академия"

Кафедра Информатики, математики и естественнонаучных дисциплин

КУРСОВАЯ РАБОТА

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

по учебной дисциплине: Базы данных

Выполнила: Нургалиева Шынар Алтайбековна

Введение

1. Хищение информации из базы данных

1.1 Управление доступом в базах данных

1.2 Управление целостностью данных

1.3 Управление параллелизмом

1.4 Восстановление данных

1.5 Транзакция и восстановление

1.6 Откат и раскрутка транзакции

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

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

2.2 Подключение к базе данных

2.3 Хранилище зашифрованных данных

2.4 Внедрение в SQL

2.5 Техника защиты

Заключение

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

Приложения

Введение

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

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

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

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

Один из основных выводов отчета CSI/FBI - значительно возросший ущерб от такой угрозы, как кража конфиденциальных данных. Каждая американская компания в среднем потеряла 355,5 тыс. долл. только из-за утечек конфиденциальных данных за прошедшие 12 месяцев. Средний размер потерь от действий инсайдеров составил 300 тыс. долл. (максимальный - 1,5 млн долл.). Решение вопросов персонифицированного доступа к конфиденциальным данным позволяет выявлять злоумышленника с помощью информации, неопровержимо доказывающей его вину. Это, в свою очередь, невозможно без применения самых современных способов аутентификации и управления доступом.

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

Для решения поставленной цели необходимо решить следующие задачи:

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

2. Хранение зашифрованных данных.

3. Техника защиты баз данных.

информационный база управление безопасность

1 . Хищение информации из баз данных

1.1 Управление доступом в базах данных

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

Итак, имеются следующие исходные данные:

Многие не догадываются о том, что их базы данных крадут;

Кража и причиненный ущерб имеют латентный характер;

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

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

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

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

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

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

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

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

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

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

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

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

1.2 Управление целостностью данных

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

Сбои оборудования, физические воздействия или стихийные бедствия;

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

Программные ошибки СУБД или ОС;

Ошибки в прикладных программах;

Совместное выполнение конфликтных запросов пользователей и др.

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

1.3 Управление параллелизмом

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

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

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

1.4 Восстановление данных

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

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

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

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

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

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

Низкоуровневое форматирование - все секторы носителя информации заполняются нулями. После такого форматирования восстановить что-либо практически нереально, поскольку все данные уничтожаются полностью. В Windows штатно отсутствует возможность низкоуровневого форматирования, поэтому даже после полной очистки диска её средствами восстановление данных теоретически возможно! Аналогично можно попробовать восстановить информацию при сбоях файловых систем, которыми часто "грешат" флешки. При таких сбоях обычно частично или полностью уничтожается системная область и флешка требует форматирования:

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

Можно выделить три основных уровня восстановления:

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

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

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

1.5 Транзакция и восстановление

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

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

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

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

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

1.6 Откат и раскрутка транзакции

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

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

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

Сегодня базы данных - основная составляющая практически любых приложений, основанных на Web, которая дает возможность предоставления разнообразного динамического содержимого. Поскольку в таких базах данным может храниться весьма важная и секретная информация, нужно позаботиться и об их защите. Архитектура, используемая при создании Web-страниц с помощью PL/SQL WebToolkit, на удивление проста, как показано на рис.1 (см. Приложение А).

Для получения или сохранения информации в базе данных, к ней нужно подключиться, послать запрос, обработать ответ и закрыть подключение. Сегодня для всего этого обычно используется структурированный язык запросов (Structured Query Language, SQL). Давайте посмотрим, как злоумышленник может поступить с SQL-запросом .

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

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

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

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

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

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

2.2 Подключение к базе данных

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

2.3 Хранение зашифрованных данных

SSL/SSH защищает данные только по пути от клиента к серверу, но не данные, хранимые в базе данных. SSL - лишь сетевой протокол.

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

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

В случае скрытых данных, где не требуется их исходный вид (к примеру, для отображения), можно использовать хеширование. Известным примером хеширования является сохранение в базе данных хеша MD5 от пароля вместо самого пароля. Для подробного описания смотрите crypt() и md5().

Пример: Использование хешированных паролей

// сохраняем хеш от пароля

$query = sprintf("INSERT INTO users(name,pwd) VALUES("%s","%s");",

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

$query = sprintf("SELECT 1 FROM users WHERE name="%s" AND pwd="%s";",

addslashes($username), md5($password));

$result = pg_exec($connection, $query);

if (pg_numrows($result) > 0) {

echo "Добро пожаловать, $username!";

echo "Введен неверный пароль для $username.";

2.4 Внедрение в SQL

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

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

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

Пример: Разделение результата запроса по страницам и... создание суперпользователей (PostgreSQL и MySQL)

$offset = argv; // внимание! нет проверки данных!

// в PostgreSQL

$result = pg_exec($conn, $query);

$result = mysql_query($query);

Обычно пользователи используют кнопочки "следующая" и "предыдущая", где $offset внедрен в URL. Программа считает, что $offset - число. Однако, кто-нибудь может попытаться внедриться путем добавления urlencode()-кодированных данных в URL

// в случае PostgreSQL

insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd)

select "crack", usesysid, "t","t","crack"

from pg_shadow where usename="postgres";

// в случае MySQL

UPDATE user SET Password=PASSWORD("crack") WHERE user="root";

FLUSH PRIVILEGES;

Если это случится, программа предоставит ему доступ суперпользователя. Заметим, что 0; служит для того, чтобы задать корректное смещение для исходного запроса и завершить его.

Обычная практика - заставить транслятор SQL проигнорировать остаток запроса разработчика с помощью обозначения начала коментария SQL --.

Существует путь получения паролей через ваши страницы поиска. Все, что нужно злоумышленнику - это одна не обработанная должным образом переменная, используемая в SQL-запросе. Использоваться могут команды WHERE, ORDER BY, LIMIT и OFFSET запроса SELECT. Если ваша база данных поддерживает конструкцию UNION, злоумышленник может добавить к исходному запросу еще один - для получения паролей. В этом случае поможет хранение зашифрованных паролей .

Пример: Вывод статей... и паролей (любой сервер баз данных)

$query = "SELECT id, name, inserted, size FROM products

WHERE size = "$size"

ORDER BY $order LIMIT $limit, $offset;";

$result = odbc_exec($conn, $query);

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

union select "1", concat(uname||"-"||passwd) as name, "1971-01-01", "0" from usertable;

Если подобный запрос (использующий " и --) будет задан в одной из переменных, используемых $query, то атака будет успешной.

Запросы SQL "UPDATE" также могут быть использованы для атаки на базу данных. Эти запросы также подвержены опасности "обрезки" и добавления новых запросов. Но здесь злоумышленник работает с командой SET. В этом случае необходимо знание некоторой информации о структуре базы данных для удачной модификации запроса. Такая информация может быть получена путем изучения названий переменных форм или просто подбором. В конце концов, не так уж и много имен придумано для полей пользователей и паролей.

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

$query = "UPDATE usertable SET pwd="$pwd" WHERE uid="$uid";";

Злоумышленник посылает значение " or uid like"%admin%"; --, в переменную $uid для изменения пароля администратора или просто устанавливает $pwd в "hehehe", admin="yes", trusted=100 " (с завершающим пробелом) для получения прав. Запрос будет искажен так:

// $uid == " or uid like"%admin%"; --

$query = "UPDATE usertable SET pwd="..." WHERE uid="" or uid like "%admin%"; --";

// $pwd == "hehehe", admin="yes", trusted=100 "

$query = "UPDATE usertable SET pwd="hehehe", admin="yes", trusted=100 WHERE ...;"

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

Пример: Атака на операционную систему сервера баз данных (сервер MSSQL)

$query = "SELECT * FROM products WHERE id LIKE "%$prod%"";

Если злоумышленник пошлет значение a%" exec master..xp_cmdshell "net user test testpass /ADD" -- в $prod, то $query будет выглядеть так:

$query = "SELECT * FROM products

WHERE id LIKE "%a%"

exec master..xp_cmdshell "net user test testpass /ADD"--";

$result = mssql_query($query);

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

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

2.5 Техника защиты

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

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

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

Проверяйте ввод на совпадение типа данных с требуемым. PHP включает в себя большое количество проверочных функций, от самых простейших из разделов "Функции для работы с переменными" и "Функции обработки символьного типа", (к примеру is_numeric() и ctype_digit() соответственно) до регулярных выражений Perl ("Регулярные выражения, совместимые с Perl").

Если программа ожидает число, проверяйте данные с помощью is_numeric(), или просто изменяйте тип с помощью settype(), или даже используйте численное представление, выданное sprintf().

Пример: Более безопасная разбивка на страницы

settype($offset, "integer");

$query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;";

// отметим %d в строке форматирования, использование %s бесполезно

$query = sprintf("SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET %d;",

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

В зависимости от используемой операционной системы необходимо предусматривать возможность атаки на разнообразные файлы, включая системные файлы устройств (/dev/ или COM1), конфигурационные файлы (например /etc/ или файлы с расширением.ini), хорошо известные области хранения данных (/home/, My Documents), и так далее. Исходя из этого, как правило, легче реализовать такую политику безопасности, в которой запрещено все, исключая то, что явно разрешено.

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

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

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

1.Бойченко И. А. Проектирование компонентов доверенной среды реляционной СУБД на основе CASE-технологий [Текст] / И. А. Бойченко - Воронеж, 2014. - 251с.

2.Борри Х. Firebird: руководство работника баз данных [Текст]: пер. с англ. / Х. Бори. - СПб.: БХВ - Петербург, 2012. - 1104с.

3.Броневщук Е. С. Система управления базами данных [Текст] / Е.С. Броневщук, В. И. Бурдаков, Л. И. Гуков. - М.: Финансы и статистика, 2013. - 634с.

4.Гончаров А. Ю. Access 2007. Справочник с примерами [Текст] / А. Ю. Гончаров. - М.: КУДИЦ - ПРЕСС, 2011. - 296с.

5.Дейт К. Введение в системы баз данных [Текст] / К. Дейт 7-е изд. - М.: СПб.: Вильямс, 2013. - 325с.

6. Каленик А. Использование новых возможностей MS SQL Server 2005 [Текст] / А. Каленик. - СПб.: Питер, 2013. - 334с.

7. Конноли Т. Базы данных. Проектирование, реализация и сопровождение. Теория и практика [Текст] / Т. Конноли, Л Бегг, А. Страган 2-е изд. - М.: Вильямс, 2012. - 476с.

8. Мотев, А. А. Уроки My SQL. Самоучитель [Текст] / А. А. Мотев. - СПб.: БХВ - Петербург, 2013. - 208с.

9. Оппель Э. Раскрытие тайны SQL [Текст]: пер. с англ. / Э. Опель, Джим Киу, Д. А. Терентьева. - М.: НТ Пресс, 2012. - 320с.

10. Промахина И. М.Интерфейсы сетевой СУБД (ПЭВМ) с языками высокого уровня [Текст] / И. М. Промахина - М.: ВЦ РАН, 2011.- 874с.

11. Фуфаев Э. В., Базы данных; [Текст] / Э. В. Фуфаев, Д. Э. Фуфаев - Академия - Москва, 2013. - 320 c.

12. Фрост, Р. Базы данных. Проектирование и разработка [Текст]: пер. с англ. / Р. Фрост, Д. Дей, К. Ван Слайк, А. Ю. Кухаренко. - М.: НТ Пресс, 2007. - 592с.

Приложение А

Рисунок А.1 - Архитектура, используемая при создании Web-страниц

Приложение Б

Рисунок Б.1 - Схема защиты информации

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

...

Подобные документы

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

дипломная работа , добавлен 23.03.2018


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

курсовая работа , добавлен 30.03.2010


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

презентация , добавлен 12.11.2010


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

лекция , добавлен 19.08.2013


Сущности и функциональные зависимости базы данных. Атрибуты и связи. Таблицы базы данных. Построение ER-диаграммы. Организация ввода и корректировки данных. Реляционная схема базы данных. Реализация запросов, получение отчетов. Защита базы данных.

курсовая работа , добавлен 06.02.2016


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

курсовая работа , добавлен 17.12.2014


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

дипломная работа , добавлен 26.11.2004


Понятие базы данных, модели данных. Классификация баз данных. Системы управления базами данных. Этапы, подходы к проектированию базы данных. Разработка базы данных, которая позволит автоматизировать ведение документации, необходимой для деятельности ДЮСШ.

курсовая работа , добавлен 04.06.2015


Процессы обработки информации. Эффективность автоматизированной информационной системы. Система управления базой данных. Локальная и распределенная система банков и баз данных. Этапы проектирования базы данных. Различие уровней представления данных.

контрольная работа , добавлен 07.07.2015


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

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

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

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

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

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

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