Уязвимости баз данных

Автор работы: Пользователь скрыл имя, 26 Ноября 2009 в 16:07, Не определен

Описание работы

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

Файлы: 1 файл

курс_Уязвимости БД.doc

— 137.50 Кб (Скачать файл)

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ЖЕЛЕЗНОДОРОЖНОГО

ТРАНСПОРТА

Иркутский Государственный  Университет Путей  Сообщения 
 

Кафедра Информационной Безопасности 
 
 
 
 
 
 
 

Курсовая  работа

на  тему:

«Уязвимости баз данных» 
 
 
 
 
 
 
 

                 Выполнил:

                       студент гр. ЗИ-05-1

                       Зубков Е. А. 

                 Проверил:   

                    Доцент  кафедры ИнБ

                    Шлаустас  Р. Ю. 
                     
                     
                     
                     
                     
                     
                     
                     
                     

Иркутск, 2008 г.

 

Содержание

 

        Введение

       Где хранится ваша наиболее ценная информация? Где содержатся финансовые данные Ваши и Ваших клиентов? Количество взломов информационных ресурсов возрастает, поэтому современная вычислительная среда нуждается в защите. Многие люди забывают защитить одну из самых важных частей своей информационной инфраструктуры. Наиболее ценная и важная информация хранится обычно не на файловом сервере, а в соответствующих базах данных. Независимо от того, какая это база - Oracle, Sybase, DB2, MS SQL Server и т.д., она содержит Вашу наиболее важную информацию. Операционная система (ОС), используемая для базы данных, должна быть соответствующим образом защищена, но это только половина дела. Мощные системы управления базами данных (СУБД) содержат свои собственные системы защиты, отдельные от ОС (пожалуй только у MS SQL Server система защиты интегрирована с защитой ОС Windows NT). Каждая из них имеет подсистемы аудита, аутентификации, целостности и разграничения доступа. Отказ от настройки или неправильная конфигурация защиты базы данных сделает большинство вашей наиболее важной информации легкой добычей для злоумышленников.

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

 

SQL уязвимости СУБД

 

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

       Мы  рассмотрим несколько угроз, возникающих  при использовании злоумышленником средств языка SQL.

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

 

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

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

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

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

       Основным  средством борьбы с подобными  угрозами, помимо тщательно проектирования модели данных, является механизм размножения  строк. Суть его в том, что в  состав первичного ключа, явно или неявно, включается метка безопасности, за счет чего появляется возможность хранить в таблице несколько экземпляров строк с одинаковыми значениями "содержательных" ключевых полей. Наиболее естественно размножение строк реализуется в СУБД, поддерживающих метки безопасности (например, в INGRES/Enhanced Security), однако и стандартными SQL-средствами можно получить удовлетворительное решение.

       Агрегирование данных

 

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

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

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

       Покушения на доступность

 

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

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

 

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

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

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

       Некоторые решения

       Примером  архитектуры клиент/сервер, которую  хорошо дополняют средства шифрования, могут служить Oracle Server, сетевые продукты (SQMNet) и программное обеспечение клиента.

       Сетевая служба безопасности (SNS — Secure Network Services) предлагает стандартный, оптимизированный алгоритм шифрования DES с ключом длиной 56 бит для организаций, от которых требуется использовать стандарт DES. Для заказчиков вне пределов США или Канады SNS предлагает DES40, в котором комбинируется использование алгоритма шифрования DES с общепринятым ключом длиной 40 бит (экспорт технологий шифрования в США законодательно ограничен). Наряду с DES возможно также использование алгоритма шифрования RSA RC4.

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

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

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

       1) криптографически защищенная контрольная  сумма в каждом пакете SQL* Net обеспечивает защиту от модификации данных и замены операции;

       2) при обнаружении нарушений операции  незамедлительно автоматически  завершаются; 

       3) информация о всех нарушениях  регистрируется в журнале. 

       Наряду  с этим обеспечивается многопротокольная  перекодировка данных, т.е. полностью поддерживается Oracle Multiprotocol Interchange — при работе с зашифрованной сессией можно начинать работу с одним сетевым протоколом, а заканчивать с другим, при этом не требуется дешифрование или перешифрование информации. SNS полностью поддерживается сквозными шлюзами, Oracle Transparent Gateways, и процедурными шлюзами, Oracle Procedural Gateways, которые дают возможность организовывать полностью зашифрованные сессии клиент/сервер к отличным от Oracle источникам данных, включая Adabas, CA-Datacom, DB2, DRDA, FOCUS, IDMS, IMS, ISAM, MUMPS, QSAM, Rdb, RMS, SAP, SQL/DS, SQL/400, SUPRA, Teradata, TOTAL, VSAM и другие.

       SNS работает со всеми основными  протоколами, поддерживаемыми SQL* Net, включая AppleTalk, Banyan, DECnet, LU6.2, MaxSix, NetBIOS, SPX/IPX, TCP/IP, X.25 и другие.

       Обеспечивается  независимость от топологии сети — SNS работает во всех основных сетевых  средах, поддерживаемых SQL-Net.

       SNS представляет собой дополнительный  продукт к стандартному пакету SQL* Net, то есть требуется предварительно приобрести лицензию на SQL* Net. Продукт надо покупать и для клиента, и для сервера.

       Вместе  тем СУБД Oracle, начиная с версии 7.1, пароль передается по сети в зашифрованном  виде.

       Это означает, что при организации  связи клиент/сервер используется новый протокол установления связи, в котором применяется сеансовый ключ, пригодный только для единственной попытки соединения с базой данных и используемый в качестве ключа для шифрования пароля, прежде чем он будет передан клиентам. Oracle-сервер находит зашифрованный пароль для этого пользователя и использует его в качестве ключа, которым он зашифровывает сеансовый ключ. Затем сервер пересылает этот зашифрованный сеансовый ключ клиенту. Клиент шифрует (применяя тот же самый односторонний алгоритм, который используется сервером) пароль, введенный пользователем, и с его помощью дешифрует зашифрованный сеансовый ключ. Обнаружив этот сеансовый ключ, он использует его — это становится совместным секретом клиента и сервера — для шифрования пароля пользователя. Этот зашифрованный пароль затем передается через сеть серверу. Сервер дешифрует пароль и затем зашифровывает его, используя односторонний алгоритм сервера; результат этих вычислений сверяется со значением, хранимым в словаре данных. Если они совпадают, клиенту предоставляется доступ. Такой подход реализуется как в соединениях типа клиент/сервер, так и сервер/сервер, где сеансы устанавливаются через так называемые полномочные звенья баз данных (т.е. звенья баз данных без вложенных имен пользователей и паролей).

Информация о работе Уязвимости баз данных