Защита коммуникаций между клиентом и сервером

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

 

Отражение угроз, специфичных для СУБД

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

В заключение, говоря о безопасности в СУБД, хочется отметить, что конфигурация, к которой имеет доступ хотя бы один пользова­тель, не является безопасной. От 80 до 85% всех убытков, наносимых компьютерными преступлениями, являются результатом деятельно­сти служащих компании. Поэтому для менеджеров информацион­ных систем одной из первоочередных мер по защите данных должна стать правильно и убедительно проводимая политика внутри фирмы: от частой смены паролей до сообщений о возможных действиях со стороны закона для тех, кто пытается превысить собственные пол­номочия по доступу к данным.

 

Системы распределенной обработки данных

 

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

Существует несколько понятий в этой области, которые необхо­димо определить более точно. Вначале выделим эти понятия:

распределенная обработка данных;

базы данных с сетевым доступом;

архитектура «клиент-сервер»;

распределенные базы данных.

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

Системы баз данных, построенные с помощью сетевых версий, иногда неправомерно называют распределенными базами данных, в то время как фактически имеют дело лишь с распределенным (сетевым) доступом к централизованной базе данных. Такие системы создаются на основе оборудования и программного обеспечения различных ло­кальных вычислительных сетей; большинство СУБД работает в сетях IBM PC Network (IBM Corp.), Novell Network (Novell Inc.).

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

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

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

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

Протокол, принятый, например, в СУБД R:BASE for DOS, допу­скает возможность блокирования ресурсов данных вплоть до уровня поля. Благодаря этому два пользователя могут одновременно обнов­лять одну и ту же строку таблицы, но разные ее поля. Выбор разра­ботчиками такой мелкой единицы блокирования позволяет мини­мизировать интегральное время ожидания доступа к блокированно­му ресурсу при исполнении приложения. Представляют интерес «тонкие» средства блокирования ресурсов, при котором один поль­зователь блокирует строку для обновления, а другой — может тем не менее в это же время читать ее. СУБД позволяет пользователям иметь информацию о том, кто в данный момент блокирует запрашиваемые ими данные.

Сложные проблемы связаны в мультипользовательском режиме работы с базами данных с тупиковыми ситуациями (Deadlock). В тех­нологии баз данных предусматривается специальная техника профи­лактики возникновения тупиковых ситуаций и отката (Roll-Back) транзакций при их возникновении.

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

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

 

Архитектура «клиент-сервер»

 

Новая модель взаимодействия компьютеров в сети получила название «клиент-сервер». Каждый из составляющих эту архитекту­ру элементов играет свою роль: сервер владеет и распоряжается ин­формационными ресурсами системы, клиент - имеет возможность воспользоваться ими.

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

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

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

Для современных СУБД архитектура «клиент-сервер» стала фак­тически стандартом.

Если предполагается, что проектируемая информация будет иметь архитектуру «клиент-сервер», прикладные программы, реа­лизованные в ее рамках, будут иметь распределенный характер. Это означает, что часть функций приложений будет реализована в программе-клиенте, другая — в программе-сервере. Основной принцип технологии «клиент-сервер» заключается в разделении функций стандартного интерактивного приложения на четыре группы:

функции ввода и отображения данных;

прикладные функции, характерные для предметной области;

фундаментальные функции хранения и управления ресурсами (базами данных);

служебные функции.

Исходя из этого деления любое приложение может состоять из следующих компонентов:

компонент представления (функции первой группы);

прикладной компонент (функции второй группы);

компонент доступа к информационным ресурсам (функции тре­тьей группы и протокол их взаимодействия).

Различия определяются четырьмя факторами:

какие виды программного обеспечения в логических компонен­тах;

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

как логические компоненты распределяются компьютерами в сети;

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

Исходя из этих допущений рассмотрим четыре подхода, реализованные в моделях технологии «клиент-сервер».

1. FS-моделъ — базовая для локальных сетей персональных ком­пьютеров. Применялась для разработки информационных систем на базе FoxPRO, Clipper, Paradox.

Основные требования:

выделяется файл-сервер для реализации услуг по обработке фай­лов других узлов сети; работает под управлением сетевых ОС;

играет роль компонент доступа к информационным ресурсам;

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

протокол обмена — набор низкоуровневых вызовов;

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

Недостатки:

высокий сетевой трафик;

небольшое число операций манипулирования;

недостаточные требования к безопасности.

2. RDA-модель.

Основные требования:

коды компонента представления и прикладного компонента сов­мещены и выполняются на компьютере-клиенте;

доступ к информационным ресурсам обеспечивается оператора­ми непроцедурного языка SQL.

Технология:

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

инициатор манипуляций с данными — программы на компьюте­ре-клиенте.

Достоинства:

процессор сервера загружается операциями обработки данных;

уменьшается загрузка сети, так как передаются по сети запросы на языке SQL;

унификация интерфейса «клиент-сервер» в виде языка SQL; использование его в качестве стандарта общения клиента и сервера.

Недостатки:

удовлетворительное администрирование приложений в RDA-модели невозможно из-за совмещения в одной программе различ­ных по своей природе функций (представления и прикладные).

3. DBS-модель, — реализована в реляционных СУБД Informix,

Ingres, Oracle.

Основные требования:

основа модель-механизм хранимых процедур — средство про­граммирования SQL-сервера;

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

компонент представления выполняется на компьютере-клиенте, прикладной компонент и ядро СУБД — на компьютере-сервере базы данных.

Достоинства:

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

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

ограниченность средств для написания хранимых процедур. На практике чаще используется разумный синтез RDA- и DBS-моделей для построения многопользовательских информационных систем.

4. AS-модель. Основные требования:

на компьютере-клиенте выполняется процесс, отвечающий за интерфейс с пользователем;

этот процесс, обращаясь за выполнением услуг к прикладному компоненту, играет роль клиента приложения (АС);

прикладной компонент реализован как группа процессов, вы­полняющих прикладные функции, и называется сервером приложе­ния (AS);

все операции над БД выполняются соответствующим компонен­том, для которого AS — клиент.

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

AS-модель является фундаментом для мониторов обработки транзакций.

 

Распределенные базы данных

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

большой поток обменов данными;

низкая надежность;

низкая общая производительность;

большие затраты на разработку.

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

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

улучшенное использование данных на местах при выполнении удаленных (дистанционных) запросов;

меньшие затраты;

простота управления.

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

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

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

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

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

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

Самый высший уровень архитектуры распределенной СУБД — это интерфейс прикладной программы и интерфейс процессора запросов.

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

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

1-4 уровни архитектуры распределенной СУБД относятся к се­тевой СУБД.

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

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

Дейт установил 12 свойств или качеств идеальной распределенной базы данных:

1. Локальная автономия (local autonomy).

2. Независимость узлов (no reliance.on central site),

3. Непрерывность операции {continuous operation).

4. Прозрачность расположения (location independence).

5. Прозрачная фрагментация (fragmentation independence).

6. Прозрачное тиражирование (replication independence).

7. Обработка распределенных запасов (distributed query processing).

8. Обработка распределенных транзакций (distributed transaction processing).

9. Независимость от оборудования (hardware independence).

10. Независимость от операционных систем (operationg system independence).

11. Прозрачность сети (network independence).

12. Независимость от баз данных (database independence).

 

Локальная автономия.

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