Защита архитектуры клиент/сервер

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

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

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

Список наиболее очевидных угроз в архитектуре клиент/сервер выглядит следующим образом:

· пассивный перехват передаваемых запросов;

· модификация (активный перехват) передаваемых запросов;

· пассивный перехват ответов клиенту;

· модификация ответов клиенту;

· выдача злоумышленником себя за определенный сервер;

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

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

· случайные сбои и ошибки функционирования аппаратуры и программных элементов сервера;

· злоумышленные действия зарегистрированных клиентов;

· другие виды атак на ПО сервера.

Защите подлежат все составляющие данной архитектуры:

· клиент - его аппаратная платформа, базы данных и про­граммное обеспечение (в том числе и операционные системы);

· сервер - его аппаратная платформа, средства администри­рования, управления передачей данных и другое программное обеспечение;

· оборудование и обеспечение линий связи, соединяющее клиентов и серверы.

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

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

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

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

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

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

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

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

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

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

Более четко принципы создания защищенных средств связи объектов в распределенных системах могут быть сформулированы

следующим образом:

· Взаимодействие между объектами должно осуществляться по физически выделенному каналу.

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

· Взаимодействие объектов должно быть организовано по виртуальному каналу связи.

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

· На сетевом уровне должен быть обеспечен контроль за маршрутом сообщений для аутентификации адреса отправителя.

· Для обеспечения доступности всех сетевых ресурсов должен осуществляться контроль за виртуальными соединениями — как при их создании, так и при использовании.

· Полезно руководствоваться принципом, согласно которому наиболее безопасна та система, в которой информация о ее объектах

· изначально полностью определена и в которой не используют­ся алгоритмы удаленного поиска.

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