 |
Базы данных как информационный ресурс
|
|
|
|
База данных (БД) - это данные, организованные в виде набора записей определенной структуры и хранящиеся в файлах, где, помимо самих данных, содержится описание их структуры. Система управления базами данных (СУБД) - это система, обеспечивающая ввод данных в БД, их хранение и восстановление в случае сбоев, манипулирование данными, поиск и вывод данных по запросу пользователя.
По функциональному назначению базы данных делят на:
· системы оперативной обработки транзакций (OLTP-системы, Online Transaction Processing);
· системы делового анализа / хранилища данных (OLAP-системы, Online Analysis Processing).
Базы данных, ориентированные на оперативную обработку транзакций, и базы данных, предназначенные для делового анализа, используются совершенно по-разному и служат разным целям. Базы данных оперативной обработки транзакций - это основа каждодневного функционирования предприятия: принятие заказов клиентов, учет сырья, складской учет, учет оплаты продукции, т.е. главным образом учетные функции. Базы данных делового анализа используются для принятия решений на основе сбора и анализа большого объема информации. Их главные пользователи - это менеджеры, служащие планового отдела и отдела маркетинга. Если в базах данных оперативной обработки транзакций основные операции - это небольшие по объему транзакции, состоящие из простых запросов на как на выборку, так и на вставку и обновление небольшого количества строк, то в базах данных делового анализа практически 100% операций являются операциями выборки (чтения) строк, причем количество отбираемых (анализируемых) строк может достигать нескольких миллионов. Другие отличия OLTP и OLAP систем представлены в таблице 1.
|
|
|
Таблица 1
Различия между OLTP и OLAP системами
| Характеристика базы данных | База данных OLTP (оперативная обработка транзакций) | База данных OLAP (хранилище данных, деловой анализ) |
| Содержимое | Текущие данные | Данные, накопленные за долгий период времени |
| Структура данных | Структура таблиц соответствует структуре транзакций | Структура таблиц понятна и удобна для написания запросов (кубы фактов - схема "звезда") |
| Типичный размер таблиц | Тысячи строк | Миллионы строк |
| Схема доступа | Предопределена для каждого типа обрабатываемых транзакций | Произвольная; зависит от того, какая именно задача стоит перед пользователем в данный момент и какие сведения нужны для ее решения |
| Количество строк, к которым обращается один запрос | Десятки | От тысяч до миллионов |
| С какими данными работает приложение | С отдельными строками | С группами строк (итоговые запросы) |
| Интенсивность обращений к базе данных | Большое количество бизнес -транзакций в минуту или в секунду | На выполнение запросов требуется время: минуты или даже часы |
| Тип доступа | Выборка, вставка и обновление | Выборка данных (почти 100 % операций) |
| Чем определяется производительность | Время выполнения транзакции | Время выполнения запроса |
Рабочая нагрузка OLTP и OLAP баз данных настолько различна, что очень трудно или даже невозможно подобрать одну СУБД, которая наилучшим образом удовлетворяла бы требованиям приложений обоих типов (важно, чтобы запросы делового анализа, длящиеся длительное время, не снижали производительности оперативной обработки транзакций). Поэтому крупные производители СУБД традиционно выпускали, в основном, OLTP-системы, а рынок OLAP-систем первоначально занимали небольшие фирмы, специализировавшиеся именно на разработке СУБД данного типа. Однако OLAP-системы быстро завоевали популярность и, в настоящее время, большинство крупных производителей СУБД также предлагает системы делового анализа. Так, например, в состав MS SQL Server 2000 (OLTP-система), отдельным пакетом входит MS SQL Analysis Services (OLAP-система).
|
|
|
Базы данных, которые являются мировыми ресурсами, то есть используются в мировой сети, имеют приоритет международных. Доступ в такие базы данных может быть ограничен.
Для этого возможно создание специального модуля, который будет являться основным инструментом защиты базы данных от несанкционированного доступа и предназначен для настройки, включения и отключения системы разграничения прав доступа пользователей к базе данных в любых системах, собранных с использованием средств программирования и СУБД.
Система разграничения прав доступа должна выполнять следующие функции:
· блокировать доступ незарегистрированных пользователей в систему. С этой целью все пользователи системы должны быть зарегистрированы в списке пользователей;
· определять права пользователей в системе и ограничивать действия пользователей в соответствии с этими правами: права на доступ к базе данных (видимость меню, доступ к информации таблиц базы данных) и права на пользование рабочими станциями;
· вести журнал регистрации системных событий, в котором регистрируются дата, время, имя пользователя, совершившего действие: вход/выход из системы, неудачный вход, запуск интерфейсов, запуск отчетов, запуск процессов. Должна быть возможность просматривать как весь журнал регистрации, так и отфильтрованный по определенному пользователю или типу события.
Базы данных могут классифицироваться по отраслям, по видам деятельности, по направлениям и так далее. В этом случае они приобретают статус специализированных баз данных, и напоминают собой всем известные тематические энциклопедии.
В настоящее время особое внимание уделяется защите баз данных, как и других информационных технологий, от пиратского копирования. В общем случае система защиты от несанкционированного копирования представляет собой комплекс средств, предназначенный для затруднения (в идеале - предотвращения) нелегального копирования (исполнения) защищаемого программного модуля, с которым она ассоциирована.
Обобщив сведения из различных источников можно предложить следующую структуру системы защиты от несанкционированного копирования:
|
|
|
Подсистема внедрения управляющих механизмов представляет собой комплекс программных средств, предназначенный для подключения внедряемого защитного кода к защищаемому программному модулю. Внедряемый защитный код - это программный модуль, задача которого состоит в противодействии попыткам запуска (исполнения) нелегальной копии защищаемой программы.
Подсистема реализации защитных функций представляет собой программную секцию, решающую задачу распознавания легальности запуска защищаемой программы.
Подсистема противодействия нейтрализации защитных механизмов предназначена для борьбы с возможными попытками нейтрализации системы защиты от несанкционированного копирования и/или её дискредитации.
Блок установки характеристик среды отвечает за получение характеристик, идентифицирующих вычислительную среду.
Блок сравнения характеристик среды устанавливает факт легальности запуска защищаемой программы.
Блок ответной реакции реализует ответные действия системы защиты на попытки несанкционированного исполнения защищаемой программы.
Наличие системы защиты подразумевает наличие злоумышленника, который будет пытаться каким-то образом нейтрализовать защиту для решения задачи несанкционированного копирования. При этом необходимо отчётливо понимать, что не существует абсолютно стойкой защиты, а существуют защиты, время преодоления которых по затратам труда и машинного времени сравнимы с разработкой системы, аналогичной защищённой. Данное положение приводит к парадоксальному на первый взгляд результату - вероятность нейтрализации защиты у элементарных программных продуктов со средним уровнем защищённости гораздо ниже, чем у сложных программ с высоким уровнем защиты.
В отдельных случаях, при относительно невысокой цене одной копии, конечному пользователю бывает выгоднее купить необходимое число инсталляций, чем оплачивать квалифицированный труд хакера.
|
|
|
Поскольку стойкость системы защиты определяется стойкостью каждого её элемента, то в качестве объекта атаки может использоваться любая из описанных подсистем. Здесь необходимо отметить неоднородный уровень как самих идей, лежащих в основе той или иной подсистемы, так и их реализаций, что, в первую очередь связано с развитием приёмов, методов и средств для нейтрализации систем защиты. Учитывая современное состояние вопроса, наиболее актуальной задачей, с точки зрения автора, является разработка подсистемы внедрения управляющих механизмов системы защиты и подсистемы установки характеристик среды, хотя остальные подсистемы должны быть разработаны не менее тщательно. Показательным примером является блок ответной реакции, который может как просто выводить сообщение о незаконности копии (что моментально выдаёт присутствие системы защиты), так и предпринимать более сложные действия, позволяющие на определённое время замаскировать наличие защиты, увеличивая тем самым время атаки.
Но если функционирование блока ответной реакции может влиять на надёжность системы лишь косвенным образом, то зачастую самым слабым местом всей системы является блок сравнения характеристик среды и именно против него в первую очередь направлены атаки злоумышленников.
Системы защиты от несанкционированного копирования можно классифицировать по способу внедрения защитного механизма:
· встроенная (внедряется при создании программного продукта);
· пристыковочная (подключается к уже готовому программному продукту).
Наибольшую популярность в последнее время приобрели системы второго типа. Это обусловлено рядом преимуществ, которые даёт их использование:
· простота тиражирования программных систем защиты на объекты заказчика и разработчика;
· простота технологии применения;
· обеспечение достаточного уровня защищённости данных в силу специализации разработчиков;
· более оптимальное соотношение «надёжность функционирования/затраты на разработку» по сравнению со встроенными системами, подготовленными непрофессионалами.
Рассмотрим способы установки защитных механизмов в защищаемые программные модули.
Одним из вариантов встраивания пристыковываемого модуля в исполняемый модуль является дописывание его по вирусному принципу. (Естественно, из рассмотрения исключаются варианты, при которых программа перестаёт работать или нарушается логика её работы.) При этом код защиты дописывается в некоторую область защищаемого файла и защищаемый файл модифицируется таким образом, чтобы управление передавалось на пристыкованный модуль защиты, который проверяет легальность копии, и в случае положительного ответа передаёт управление на исполняемый модуль. Такой подход к внедрению в исполняемые файлы имеет ряд существенных недостатков. Во-первых, исходный код защищаемой программы остаётся практически в неизменном виде, что значительно упрощает нейтрализацию защиты. Во-вторых, если предполагается защищать файлы большого размера и, как следствие, со сложной (может быть и с оверлейной) структурой, то необходимо учитывать то, что код, находящийся в конце загружен не будет, а значит программный модуль не будет отработан. Некоторые недостатки можно устранить, если писать в начало программы не одну команду перехода, в весь код защиты. При этом необходимо модифицировать таблицу перемещения (которая находится в конце заголовка EXE-файла), в случае если защищается файл типа EXE.
|
|
|
Основным недостатком защит такого типа является то, что они могут быть нейтрализованы динамически, путём определения момента, когда защитная часть уже отработала и начал выполняться сам защищаемый код. Примером такого подхода к нейтрализации защит являются программы SNAPSHOT и INTRUDER. Основная идея метода, реализованного в подобных программах, заключается в двукратной загрузке исследуемого модуля по разным адресам памяти с последующим вычислением всей необходимой информации на основе анализа дампов памяти (под необходимой информацией здесь понимается заголовок EXE-файла, содержащий всю информацию, которая требуется операционной системе для загрузки программы).
Другим важным недостатком описанных методов внедрения является то, что существующие защитные механизмы данного типа не могут обеспечить корректную защиту самомодифицирующихся программ, которые в процессе выполнения изменяют свой образ, хранящийся на диске.
Исходя из указанных недостатков, можно сформулировать следующие требования к пристыковываемым модулям:
· пристыковываемый модуль должен подключаться к файлам любого размера;
· результирующий файл, полученный после подключения пристыковываемого модуля, должен быть устроен таким образом, чтобы максимально затруднить выделение исходной защищаемой программы;
· пристыковываемый модуль не должен накладывать ограничений на функционирование защищённой программы, в частности, он должен позволять модифицировать в процессе работы свой собственный дисковый файл.
|
|
|
