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

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

Статьи по теме
Искать по теме

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

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

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

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

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

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

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

- Дискреционный

- Обязательный

- Ролевой

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внедрение SQL кода

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

Для проведения атаки, злоумышленник должен самостоятельно изменить передаваемый параметр. Допустим, на сервере работает php-скрипт, в котором есть такой код:

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

Если на сайте будет ссылка на новость с идентификатором равным 25, то при нажатии на неё произойдёт обращение по адресу, например, site.ru/script.php?id=25, и выполнится следующий SQL-запрос:

SELECT * FROM news WHERE id_news = 25

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

SELECT * FROM news WHERE id_news = -1 OR 1=1

При таком запросе выведутся все новости из таблицы news, т.к. выражение 1=1 истинно всегда. Логика работы скрипта будет нарушена, и, к примеру, некоторые статьи, которые были доступны лишь платным подписчикам, станут доступны таким образом. Однако, злоумышленник, увидевший, что сайт подвержен атакам внедрения SQL-кода может не остановиться на этом, и пойти дальше, пожелав заполучить, например список пользователей и их пароли.

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

SELECT id_news, header, body, author FROM news WHERE id_news = ".$_GET['id']

Злоумышленник может передать в качестве значения параметра id произвольный SQL-код. В случае, если он охотится за учётными данными пользователей, хранящимся в отдельной таблице, он может попытаться угадать название таблицы. Введя в адресной строке браузера site.ru/script.php?id=1+UNION+SELECT+1,userna me,password,1+FROM+users скрипт выполнит следующий запрос:

SELECT id_news, header, body, author FROM news WHERE id_news = -1 UNION SELECT 1,username,password,1 FROM users

Из таблицы news не будет выбрано ни одной новости, так как новости с идентификатором -1 там нет. Однако в результат попадут записи, отобранные из таблицы users.

Иногда SQL-запрос в уязвимом скрипте имеет сложную структуру, которая усложняет использование UNION. К примеру, следующий код немного затруднит SQL инъекцию:

SELECT author FROM news WHERE id=".$_GET['id']." AND author LIKE ('a%')"

Данный запрос отображает имя автора согласно полученному идентификатору, но только в том случае, если имя автора начинается на букву ‘a’. Так как после первого условия, проверки идентификатора, идёт второе – проверка первой буквы в имени автора, использование UNION сделает запрос некорректным. Для проведения атаки злоумышленнику необходимо отсечь второе условие. Это может быть сделано путём экранирования части запроса используя символ комментария /* или --, в зависимости от СУБД. Для внедрения SQL кода злоумышленник может передать строку -1+UNION+SELECT+password+FROM+admin/* в качестве значения параметра id, что приведёт к выполнению следующего запроса:

SELECT author FROM news WHERE id=-1 UNION SELECT password FROM users/* AND author LIKE ('a%')

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

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

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

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

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

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

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

- Логическая безопасность, которая связана с грамотным построением и бесперебойной работой ПО;

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

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

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

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

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

- комнаты ИТ-безопасности;

- сейфы ИТ-безопасности (дата-сейфы);

- сейфы для защиты носителей информации (медиа-сейфы).

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

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

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

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

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

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

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

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

- искажение информации;

- приведение носителей информации в нерабочее состояние или их хищение;

- вывод из строя программного или аппаратного обеспечения;

- нарушение алгоритмов решения задач.

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

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

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

- удаление или порча информации;

- разрушение или потеря работоспособности носителей информации;

- разрушение или вывод из строя программного и аппаратного обеспечения;

- нарушение алгоритмов выполнения задачи.

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

Выводы

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

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

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

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

Литература

1. Скотт В. Эмблер, Прамодкумар Дж. Садаладж Рефакторинг баз данных: эволюционное проектирование. — М.: "Вильямс", 2007. — С. 368.

2. Томас Коннолли, Каролин Бегг Базы данных. Проектирование, реализация и сопровождение. Теория и практика. — 3-е изд. — М.: "Вильямс", 2003. — С. 1436.

3. К. Дж. Дейт Введение в системы баз данных. — 8-е изд. — М.: "Вильямс", 2006. — С. 1328.

4. Бен Форта "Освой самостоятельно язык запросов SQL", 3-е издание: Пер. с англ. - М.: 2005. - 288 стр. с ил., "Диалектика"

5. Пол Уилтон, Джон Колби "Язык запросов SQL для начинающих": Пер. с англ. - М.: 2005. - 496 стр. с ил., "Диалектика"

6. Кевин Клайн "SQL. Спрaвочник" - М.: 2006. - 832 стр., "КУДИЦ-ОБРАЗ"