Добавил:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Скачиваний:
68
Добавлен:
02.02.2021
Размер:
793.09 Кб
Скачать

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

Расположение сервера базы данных.

Каким образом сервер базы данных соединяется с веб-сервером или сервером приложений.

Каким образом веб-сервер защищен от внутренних пользователей.

Расположение базы данных

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

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

Примечание

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

Соединение с сервером электронной коммерции

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

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

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

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

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

Защита внутреннего доступа

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

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

Рис. 17.5. Пересмотренная архитектура электронной коммерции, в которой используется сервер приложений

Примечание

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

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

Разработка архитектуры электронной коммерции

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

Расположение сервера и соединения

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

Маршрутизаторы, коммутаторы и межсетевые экраны, подключенные к интернету, соединены между собой таким образом, что сбой в любом компоненте никак не повлияет на трафик сайта. За межсетевыми экранами два коммутатора прикладного уровня обеспечивают распределение нагрузки между веб-серверами. Веб-серверы защищены межсетевыми экранами от атак по всем портам, кроме 80 и 443.

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

Рис. 17.6. Архитектура системы электронной коммерции для сайта с высокой степенью доступности

Примечание

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

Сканирование уязвимостей

Для периодического сканирования всех систем имеется стандартная программа. Сканирование осуществляется из четырех местоположений.

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

В сети веб-сервера для обнаружения служб и уязвимостей на веб-серверах.

В сети сервера приложений для обнаружения служб и уязвимостей на втором интерфейсе веб-сервера и на серверах приложений.

Во внутренней сети организации для обнаружения служб и уязвимостей в сервере базы данных.

Эти действия по сканированию выполняются ежемесячно, и исправление уязвимостей отслеживается. Новые системы сканируются перед вводом в эксплуатацию.

Данные аудита и обнаружение проблем

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

Разработка архитектуры сайта электронной коммерции

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

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

Передача средств между учетными записями в банке.

Заказ по чеку.

Проверка баланса учетных записей и просмотр недавних транзакций.

Платежи по счету через партнера (клиент для этого будет перенаправлен к партнеру через веб-сайт без необходимости повторного входа в систему).

Шаг за шагом

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

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

Определите конкретные требования безопасности для каждого компонента системы: система-клиент, веб-сервер, приложение и база данных.

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

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

Выводы

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

Контрольные вопросы

Какая служба безопасности является наиболее критичной для электронной коммерции?

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

Что подразумевается под термином "всемирное время"?

Можно ли напрямую оценить убытки компании во время ее бездействия?

Если информация должна храниться на системе-клиенте, что необходимо использовать для защиты конфиденциальности информации?

Где должна храниться информация о клиентах на сайте электронной коммерции?

Где должны быть расположены серверы электронной коммерции, взаимодействующие с клиентом?

Где должны находиться веб-страницы при настройке веб-сервера?

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

Если в транзакции задействована секретная информация, какое местоположение является наиболее рекомендуемым для хранения информации сеанса?

Во время этапа разработки проекта разработчики должны предотвращать переполнение буфера посредством запрета на прямую передачу введенных ими данных командам оболочки и _____________.

В трехзвенной архитектуре электронной коммерции имеет ли сервер базы данных связь с интерфейсными веб-серверами?

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

Какие системы больше всего подходят для выявления проблем, связанных с контролем конфигурации?

Может ли доступность полностью обеспечиваться избыточным оборудованием?

Соседние файлы в папке 4-1 Електрона комерція