Поиск

Полнотекстовый поиск:
Где искать:
везде
только в названии
только в тексте
Выводить:
описание
слова в тексте
только заголовок

Рекомендуем ознакомиться

Информатика->Дипломная работа
В наши дни в связи со всеобщей информатизацией и компьютеризацией банковской деятельности значение информационной безопасности удаленных транзакций мн...полностью>>
Информатика->Курсовая работа
Игры – непременная составляющая любой человеческой культуры. Слово «игра» мы прилагаем почти ко всякому детскому занятию. Посредством игры наиболее ин...полностью>>
Информатика->Дипломная работа
Визитная карточка - одна из составляющих имиджа делового человека. Она является выражением не только индивидуального стиля и вкуса, но и фирменного, к...полностью>>
Информатика->Реферат
Имитационное моделирование (от англ. simulation) - это распространенная разновидность аналогового моделирования, реализуемого с помощью набора математ...полностью>>

Главная > Статья >Информатика

Сохрани ссылку в одной из сетей:

Цель хакерской атаки: СУБД - система управления базами данных

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

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

Компьютерная система глазами хакера

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

Одним из самых серьезных транснациональных сетевых компьютерных преступлений, по мнению Интерпола, является дело Левина, в результате чего американский Сити-банк потерял 400 тыс. долларов США. После подобных происшествий директорский состав компаний пришел к выводу, что с поступлением в работу каждой последующей компьютерной системы, которая имеет выход во всемирную сеть Интернета, существует достаточный риск предоставить различного рода злоумышленникам возможность, благодаря которой они могут беспрепятственно проникать в лоно компании и причинять значительный материальный ущерб. Кому это интересно? Многим, как профессиональным взломщикам и грабителями, конкурентам, так и обиженным подчиненным. Таким образом, как неосведомленность руководящего состава, так и ограничения в бюджетных средствах не есть основные препятствия на пути введения мер защиты в компьютерных системах информации, а важную роль имеет именно выбор инструментов и решений.

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

1. Выяснения ценности и важности информации, которая хранится в компьютерной системе.

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

3. Возможная модель поведения взломщика при осуществлении атаки на компьютерную систему.

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

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

1. Насколько высокой является степень профессиональной подготовки взломщика.

2. Какой именно информацией об атакуемой компьютерной системе он обладает.

3. Каким образом взломщик осуществляет доступ к компьютерной системе.

4. К какому методу атаки он прибегнет вероятнее всего.

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

Методы взлома компьютерных систем

Практически любое компьютерное программное обеспечение состоит из 3 - х основных составляющих:

операционная система,

сетевое программное обеспечение (СПО),

системы управления базами данных (СУБД).


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

уровень операционной системы,

уровень сетевого программного обеспечения,

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

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

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

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

И если перед нами стоит задача обеспечить безопасность корпоративной СУБД, давайте озадачимся простым вопросом: кто в компании вообще пользуется базой данных и имеет к ней доступ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Загрузить файл

Похожие страницы:

  1. Защита базы данных спортивного магазина

    Реферат >> Государство и право
    ... приложения 5 1.4.Методика создания приложений баз данных 8 1.5.Защита баз данных 9 2.Специальная часть 2.1.Постановка задачи ... 10.Защита базы данных и самого приложения. 1.5.Защита баз данных Защита с использованием пароля БД Данный способ защиты позволяет ...
  2. База данных для автоматизации работы с данными

    Реферат >> Информатика
    ... операционной системы. Защита базы данных Microsoft Access обеспечивает два традиционных способа защиты базы данных: установка пароля ... , требуемого при открытии базы данных, и защита на уровне ...
  3. Базы данных Автомобильная стоянка

    Курсовая работа >> Информатика, программирование
    ... файлы базы данных являются разделяемыми ресурсами в сети. В Access реализована надёжная система защиты от ... различные отчёты на основе данных таблиц и других объектов базы данных; 6) Защита базы данных. Эти средства позволяют ...
  4. Уязвимости баз данных

    Курсовая работа >> Информатика
    ... настройки или неправильная конфигурация защиты базы данных сделает большинство вашей наиболее ... мере обратить свой взгляд на защиту баз данных. У него не хватает ... выполняет и другие функции, связанные с защитой баз данных. Но, поскольку нас интересует только ...
  5. Реляционные базы данных (2)

    Реферат >> Информатика
    ... основные функции СУБД — создание базы данных, чтение и ввод данных, реализацию защиты базы данных и т.д.Правило 6 касается представлений ...

Хочу больше похожих работ...

Generated in 0.0021300315856934