И. А. Защита информации в субд. Лекция
| Вид материала | Лекция |
- Лекция Защита информации в компьютерных системах, 105.02kb.
- Карпов Дмитрий Анатольевич лекция, 472.96kb.
- Защита информации и информационная безопасность лекция 3 Основные направления и методы, 24.45kb.
- Лекция 2 Базы данных, 241.25kb.
- Лекция 2 Работа с субд ms access, 167.82kb.
- Лекция № Современные технические и программные средства информационных технологий, 47.37kb.
- Инфологическое моделирование, 782.45kb.
- Лекция №1: Стандарты языка sql, 1420.56kb.
- Реферат сравнение субд oracle и Microsoft sql server, 313.62kb.
- 4. Применение систем управления базами данных (субд) в современных системах обработки, 431.02kb.
Терейковский И.А. Защита информации в СУБД. Лекция.
Лекция. ЗАЩИТА ИНФОРМАЦИИ В БАЗАХ ДАННЫХ
Общие положения
Современные автоматизированные системы обработки данных (АСОД) имеют дело с большими объемами информации. Необходимость быстрой и корректной обработки этой информации обусловливают следующие общие требования к программному обеспечению, в частности, к системам управления базами данных (СУБД):
многозадачный, многопользовательский режим;
обеспечение защиты данных, что включает в себя несколько аспектов:
а) гибкую, многоуровневую и надежную регламентацию полномочий пользователей;
б) наличие средств для поддержания целостности и непротиворечивости данных;
в) присутствие в системе многофункциональных процедур архивации, восстановления и мониторинга данных, обеспечивающих сохранность данных при программных и аппаратных сбоях;
достаточная производительность;
переносимость, то есть программные средства должны обеспечить возможность переноса прикладной системы на новые платформы без каких-либо изменений; сетевые функции;
телекоммуникационные возможности.
Остановимся подробнее на рассмотрении вопросов защиты данных. Комплекс программно-аппаратных средств и организационных (процедурных)решений по защите информации от НСД включает следующие четыре подсистемы:
управления доступом;
регистрации и учета;
криптографическую;
обеспечения целостности.
Защита базы данных (БД) означает защиту самих данных и их контролируемое использование на рабочих ЭВМ сети, а также защиту любой сопутствующей информации, которая может быть извлечена из этих данных или получена путем перекрестных ссылок. Когда рассматриваются процедуры защиты сетевых БД, то данные и их логические структуры представляются двумя различными способами. Отдельные объекты данных могут быть сами обьектами защиты, но могут быть организованы в структуры БД (сегменты, отношения, каталоги и т. д.). Защита таких структур рассматривается в основном при анализе механизмов контроля доступа. Ниже дана оценка текущего состояния разработки функций, процедур и средств внутренней защиты данных, их возможностей и ограничений. Обеспечение защиты данных на рабочих ЭВМ может быть описана так:
1. Защита содержания данных (data content protection) объединяет функции, процедуры и средства защиты, которые предупреждают несанкционированное раскрытие конфиденциальных данных и информации в БД.
2. Средства контроля оступа разрешают доступ к данным только полномочных объектов в соответствии со строго определенными правилами и условиями.
3. Управление потоком защищенных данных при передаче из одного сегмента БД в другой обеспечивает перемещение данных вместе с механизмами защиты, присущими исходным данным.
4. Предотвращение возможности выявления конфиденциальных значений из данных, содержащихся в регулярных или статистических БД, в результате выявления статистически достоверной информации.
5. Контроль согласованности при использовании БД предполагает процедуры, которые обеспечивают защиту и целостность отдельных элементов-данных, в частности их значений (зависимость от значений). Успешная реализация таких процедур означает, что данные в БД всегда логически связаны и значения критических данных передаются от узла к узлу только при наличии специальных полномочий.
6. Контекстная защита данных, характерная для схем защиты динамических БД, также должна быть включена в состав процедур защиты БД. В этом случае защита отдельного элемента БД в каждый данный момент времени зависит от поведения всей системы защиты, а также предшествующих операций, выполненных над зтим элементом.
7. Предотвращение создания несанкционированной информации предполагает наличие средств, которые предупреждают, что объект получает (генерирует) информацию, превышающую уровень прав доступа, и осуществляет это, используя логическую связь между данными в БД.
Следует отметить, что применение криптографических методов способно существенно повысить стойкость защиты баз данных от НСД. Задача криптографической защиты БД существенно отличается от криптозащиты информации в рамках обычной файловой системы по следующим причинам:
1. Возникает задача проектирования защиты информации с учетом СУБД либо путем встраивания защитных механизмов в СУБД, либо в виде внешних защитных оболочек (для систем, работающих без функций защиты).
2. Файлы БД - это файлы определенной структуры. Пользователи могут иметь доступ к информации только из определенных частей БД, то есть возникает задача ранжирования прав доступа (избирательной защиты) внутри файла БД.
3. Размер шифруемой информации в файле БД в общем случае произволен и ограничен только структурой БД.
Для более полной защиты необходимо ввести следующие уровни:
а) Регистрация и аутентификация пользователей, ведение системного журнала. Идентификацию и аутентификацию можно проводить следующими способами:
по индивидуальному паролю, вводимому с клавиатуры;
с помощью ключевой дискеты, компакт-диска и т. д.;
с помощью электронного ключа;
другие способы.
В системном журнале регистрируются любые попытки входа в систему и все действия оператора в системе.
б) Определение прав доступа к информации БД для конкретного пользователя (авторизация пользователя) при обращении к СУБД. Все действия пользователя протоколируются в системном журнале. Определение полномочий пользователя при доступе к БД происходит на основе анализа специальной информации - списка пользователей с правами доступа, которая формируется администратором БД, исходя из принципа минимальных полномочий для каждого пользователя. Это второй этап процедуры авторизации пользователя. На этом уровне происходит конфигурация БД под полномочия конкретном пользователя. Пользователю предоставляется в виде как бы отдельной базы та часть БД, доступ к которой ему разрешен администратором. Все обращения вне этой части должны блокироваться системой. В этом случае пользователь работает с виртуальной "личной" БД.
в) Непосредственный доступ к БД. На этом уровне для повышения защищенности системы в целом целесообразно использовать зашифрование/расшифрование отдельных обьектов БД. Ключи для шифрования можно определять исходя из идентификатора пользователя и ем полномочий, то есть "паспорта"пользователя.
Рассмотрим пример реализации защиты БД. При создании базы данных вводится дополнительное поле, в котором записывается уровень конфиденциальности данной записи. Информация БД шифруется и хранится на диске в зашифрованном виде. В каталоге СУБД создается БД, представляющая из себя регистрационную книгу, где содержится следующая информация: имя или код пользователя, пароль, уровень доступа. Данный файл и управляющая .prg-программа также шифруются. Создается и запускается управляющий .bat-файл. К недостаткам данной реализации относятся: возможность удаления и модификации .bat-файла; при некорректном завершении (например, ctrl+а1t+del) на диске может остаться файл базы данных в явном виде.
Для надежности после работы желательно "затирать" пустые места на диске, чтобы при НСД невозможно было восстановить некодированный файл с помощью дисковых утилит (например, unerase.ехе из пакета Norton Utilities), хотя это дополнительная трата времени.
В заключение следует отметить, что при разработке механизмов защиты БД следует помнить о некоторых их особенностях :
в БД обьекты могут представлять собой сложные логические структуры, определенное множество которых может отображаться на одни и те же физические объекты;
возможно существование различных требований по защите для разных уровней рассмотрения - внутреннего, концептуальном и внешнего для БД;
защита БД связана с семантикой данных, а не с их физическими характеристиками.
Уязвимости баз данных
Уязвимости учетных записей Давайте представим, что сотрудник, имевший доступ к базе данных, уволен. Какие действия должен произвести администратор безопасности? Правильно: удалить или как минимум заблокировать учетную запись, принадлежавшую этому сотруднику. И он бы рад это сделать, однако менеджеры по персоналу очень часто забывают оповестить администраторов о том, что сотрудник уволен (или ушел в отпуск). Это приводит к тому, что данная учетная запись может быть использована для попытки проникновения в базу данных и маскировки под другого пользователя. К сожалению, современные СУБД не имеют механизма, позволяющего обнаруживать неиспользуемые учетные записи, что открывает перед злоумышленниками большой простор для несанкционированной деятельности.
Администратор - это царь и бог в любой системе, и его учетная запись должна защищаться как зеница ока. Но увы... Не все производители уделяют этому вопросу достаточно внимания. Например, в Microsoft SQL Server 6.5 пароль администратора (учетная запись - sa) хранился в открытом виде в системном реестре. В следующих версиях (7 и выше) компания Microsoft попыталась исправить этот недочет, но не слишком успешно. Несмотря на то, что пароль хранится теперь в зашифрованном виде он легко дешифруется с помощью утилиты L0phtCrack.
Еще одна проблема Microsoft SQL Server также связана с системным реестром, в котором хранятся (пусть и в зашифрованном виде) пароли не только пользователей БД, но и пользователей операционной системы. С помощью расширенных хранимых процедур xp_regdeletevalue, xp_regwrite, xp_regread и т. д. можно манипулировать ключами системного реестра как угодно. Например, прочтя с помощью команды xp_regread
'HKEY_LOCAL_MACHINE', 'SECURITY\SAM\DOMAINS\ACCOUNT\USERS\000001F4', 'F'
неизвестный зашифрованный пароль учетной записи пользователя, можно заменить его на известный пароль и войти в систему, замаскировавшись под ничего не подозревающего пользователя. А если у злоумышленника есть время, то он может попытаться "взломать" зашифрованный пароль с помощью уже упомянутой утилиты L0phtCrack.
Компания Oracle недалеко ушла от Microsoft и не уделила пристального внимания защите системных паролей. А вот хакеры не обошли стороной этот вопрос, в результате чего выявились некоторые уязвимости, приводящие к тому, что злоумышленник может получить доступ к защищаемым ресурсам СУБД. Пароль встроенной учетной записи INTERNAL, используемой, например, для старта и останова СУБД, хранится в открытом виде в файле strXXX.cmd (XXX - это идентификатор SID, который по умолчанию соответствует "orcl") и в файле \orant\database\spoolmain.log (записывается в процессе создания базы данных). Заметим: доступ к этим файлам по умолчанию имеют все пользователи.
Кроме того, все пароли учетных записей для СУБД Oracle хранятся в файле orapwXXX (для UNIX) или pwdXXX.ora (для Windows NT), где XXX - это SID. И хотя в этом файле хранятся зашифрованные значения паролей учетных записей, они могут быть подвергнуты атаке Brute Force, позволяющей подобрать правильное значение пароля. Мало того, одно неизвестное зашифрованное значение пароля может быть заменено на другое зашифрованное, но известное значение, что откроет дорогу злоумышленнику к базе данных.
Контроль слабых паролей Еще одна проблема, о которой нельзя умолчать, присуща не только СУБД, но и многим другим программным средствам. Речь идет о контроле "слабых" паролей, содержащих только буквы (без цифр), малое число символов и т.д. Предыдущие версии Oracle, Sybase, Microsoft SQL Server не содержали никаких средств контроля таких паролей, что позволяло пользователям выбирать для них абсолютно неподходящие значения типа "1111", "alex", "sex", "aaaa" и т.д. Такие пароли подбираются злоумышленниками в течение нескольких секунд, что (в случае отсутствия механизма контроля неудачных попыток регистрации в СУБД) открывает злоумышленнику доступ к конфиденциальным данным. В новых версиях Sybase и Oracle появились такие механизмы проверки, но по умолчанию они не используются.
Мало того, что пользователи выбирают "слабые" пароли, очень часто они оставляют без изменения пароли, заданные производителем по умолчанию. А таких паролей существует огромное множество. Например, по адресу ссылка скрыта указано несколько сотен паролей, задаваемых по умолчанию, для различного программно-аппаратного обеспечения, в том числе и для СУБД.
Уязвимости подсистемы контроля доступа к СУБД
На минуту представим такую ситуацию. Ночь. К серверу обратились с запросом, который он и стал обрабатывать. На первый взгляд, обычная ситуация, в которой не усматривается ничего криминального. Но это только на первый взгляд. Ведь на дворе ночь (случай с удаленным доступом из другого часового пояса я сейчас опускаю). Ночью сотрудники корпорации не работают и не делают никаких запросов. А вот злоумышленник, осуществляющий свою несанкционированную деятельность в нерабочее время, может делать. СУБД должна блокировать такого рода попытки.
Любая система контроля доступа построена по принципу проверки соответствия предъявленных идентификатора и пароля пользователя эталонным значениям. Если злоумышленник не знает пароля, то он будет пытаться проникнуть в базу данных, подставляя различные слова ("атака по словарю"), сведения о пользователе или иную информацию, которая может служить паролем (например, идентификатор пользователя, прочитанный наоборот). Предыдущие версии Sybase (11.x), Oracle (7.x), Microsoft SQL Server (6.x) не содержали никаких механизмов контроля неправильных попыток регистрации в системе, что позволяло злоумышленнику неограниченное число раз пытаться проникнуть в систему. А так как и для доступа к компьютеру, и для доступа к СУБД, и для доступа к Интернету пользователи обычно используют один и тот же пароль, то, узнав пароль пользователя СУБД, нарушитель с высокой степенью вероятности может установить полный контроль над учетной записью этого пользователя. И это несмотря на то, что в операционной системе можно задать число неудачных попыток регистрации в системе, после превышения которого учетная запись блокируется. Справедливости ради необходимо сказать, что в Sybase 12.x и в Oracle 8.x и более поздних версиях появился механизм контроля неудачных попыток регистрации в системе (sp_configure "maximum failed logins" в Sybase и FAILED_LOGIN_ATTEMPT в Oracle).
Для СУБД действуют те же правила, что и для операционной системы. Этот вид ПО также нуждается в регулярной проверке с целью обнаружения всех несанкционированных изменений и наличия "дыр". Делать это можно вручную, используя уже названные источники информации (например, Web-сервер "Информзащиты" и серверы производителей) или применяя автоматизированные системы анализа защищенности.
Защита файлов баз данных (БД) от попыток прочитать файлы БД на уровне ОС (как обычные файлы) в обход встроенных в СУБД средств аутентификации, авторизации и контроля доступа. Злоумышленник может скопировать файлы БД (локально или по сети) и произвести прямой просмотр их содержимого (или восстановление данных на новом сервере), что позволит ему получить доступ ко всей хранящейся в базе данных информации;
нет возможности оперативного и корректного завершения работы СУБД (и использующих ее приложений) при возникновении нештатных ситуаций (обнаружение вторжения в ИС, физическое проникновение чужих лиц в помещение, пожар и пр.).
Уязвимости сетевого взаимодействия
Большинство современных СУБД построено по технологии клиент-сервер, что подразумевает доступ клиентской части к серверу по каналам связи. В качестве сетевого протокола, по которому осуществляется взаимодействие, как правило, выступает IP (и TCP над ним), поскольку никакой другой из распространенных протоколов не обеспечивает межплатформенного взаимодействия.
Доступ клиентов к серверу баз данных осуществляется путем обращения к так называемому слушающему сервису, функционирующему на порте с определенным номером (1433 - для Microsoft SQL Server, 1521 - для Oracle и, как правило, 5000 - для Sybase). Несанкционированный доступ к учетной записи, отвечающей за старт и останов слушающего сервиса, приводит к тому, что злоумышленник может остановить данный сервис, тем самым блокировав все попытки подключения клиентов к серверу базы данных.
Но нарушителю не обязательно даже знать пароль. Он может попросту послать на "слушающий" порт специальным образом сформированные пакеты, приводящие к нарушению работоспособности сервера баз данных (т. е. атака "отказ в обслуживании").
Еще одна уязвимость баз данных, взаимодействующих по протоколу TCP/IP, связана с тем, что информация между клиентом и сервером в абсолютном большинстве случаев передается в незащищенном виде. Установив в сети анализатор протоколов или используя анализатор, встроенный в ОС (как, например, Network Monitor для Windows NT), можно без проблем перехватывать пароли и идентификаторы пользователей, не говоря уже о конфиденциальных данных, хранящихся в БД.
Охраняя базы данных
В то время как компании сосредоточивают усилия на обеспечении безопасности ОС и сетевых устройств, эксперты по безопасности заявляют, что базам данных, наиболее важным местам, где хранится ценная информация, уделяется слишком мало внимания.
ссылка скрыта предусматривает меры по обеспечению безопасности для своих БД. Наиболее важным является контроль доступа к БД. Стандартный пакет СУБД компании включает функцию виртуального надзора за приложением (ссылка скрыта); с помощью этой функции можно установить контроль доступа для каждого отдельного поля БД, что позволяет обеспечить одновременную работу различных пользователей, причем каждый из них не будет иметь доступ к информации других.
Для дополнительной защиты БД Oracle предлагает опцию ссылка скрыта, благодаря которой можно произвести более четкое разграничение доступа, например определив временной интервал, в течение которого может быть открыт доступ к той или иной информации.
ПО Database Scanner компании ISS также предназначено для повышения безопасности данных. С его помощью осуществляется автоматическое определение возможных уязвимых мест в системе, поиск нестойких паролей и «троянских коней». Программа вырабатывает рекомендации по устранению слабых мест.
Не желая отставать от конкурентов, компания Guardent выпустила программу сканирования уязвимых мест Vulnerability Scanning Service и предлагает ее вместе с системой по управлению безопасностью Security Management Appliance. Устройство, находящееся за межсетевым экраном клиента, дистанционно определяет уязвимые места в ОС, приложениях и сетевой инфраструктуре. Сканер просматривает новое ПО и структуру БД сразу же, как только они становятся доступными, и автоматически определяет в них уязвимые места.
Общие рекомендации по защите.
При настройке СУБД обязательно выруби гостевой вход, смени имя пользователя и пароль, а также отключи функции выполнения внешних команд.
Не стесняйся разделять права пользователям MySQL. Не давай право учетной записи форума иметь доступ ко всем остальным базам данных.
Помимо авторизации по хостам и парольной аутентификации обязательно прикрывай порт сервиса файрволом, чтобы наверняка защитить свою СУБД.
Безопасность и санкционирование доступа с использованием SQL
В контексте баз данных термин безопасность означает защиту данных от есанкционированного раскрытия, изменения или уничтожения. SQL позволяет индивидуально защищать как целые таблицы, так и отдельные их поля. Для этого имеются две более или менее независимые возможности:
-механизм представлений, рассмотреный в предыдущей главе и используемый для скрытия засекреченных данных от пользователей, не обладающих правом доступа;
-подсистема санкционирования доступа, позволяющая предоставить указанным пользователям определенные привилегии на доступ к данным и дать им возможность избирательно и динамически передавать часть выделенных привилегий другим пользователям, отменяя впоследствии эти привилегии, если потребуется.
Обычно при установке СУБД в нее вводится какой-то идентификатор, который должен далее рассматриваться как идентификатор наиболее привилегированного пользователя - системного администратора. Каждый, кто может войти в систему с этим идентификатором (и может выдержать тесты на достоверность), будет считаться системным администратором до выхода из системы. Системный администратор может создавать базы данных и имеет все привилегии на их использование. Эти привилегии или их часть могут предоставляться другим пользователям (пользователям с другими идентификаторами). В свою очередь, пользователи, получившие привилегии от системного администратора, могут передать их (или их часть) другим пользователям, которые могут их передать следующим и т.д.
Привилегии предоставляются с помощью предложения GRANT (предоставить), общий формат которого имеет вид
GRANT привилегии ON объект TO пользователи;
В нем "привилегии" - список, состоящий из одной или нескольких привилегий, разделенных запятыми, либо фраза ALL PRIVILEGES (все привилегии); "объект" - имя и, если надо, тип объекта (база данных, таблица, представление, индекс и т.п.); "пользователи" - список, включающий один или более идентификаторов санкционирования, разделенных запятыми, либо специальное ключевое слово PUBLIC (общедоступный).
К таблицам (представлениям) относятся привилегии SELECT, DELETE, INSERT и UPDATE [(столбцы)], позволяющие соответственно считывать (выполнять любые операции, в которых используется SELECT), удалять, добавлять или изменять строки указанной таблицы (изменение можно ограничить конкретными столбцами). Например, предложение
GRANT SELECT, UPDATE (Труд) ON Блюда TO cook;
позволяет пользователю, который представился системе идентификатором cook, использовать информацию из таблицы Блюда, но изменять в ней он может только значения столбца Труд.
Если пользователь USER_1 предоставил какие-либо привилегии другому пользователю USER_2, то он может впоследствии отменить все или некоторые из этих привилегий. Отмена осуществляется с помощью предложения REVOKE (отменить), общий формат которого очень похож на формат предложения GRANT:
REVOKE привилегии ON объект FROM пользователи;
Например, можно отобрать у пользователя cook право изменения значений столбца Труд:
REVOKE UPDATE (Труд) ON Блюда FROM cook;
