Информационная безопасность

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

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

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

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

Сервер базы данных должен, таким образом, соединятся с сервером электронной коммерции, чтобы обеспечит  обработку всех трансакций. В основном такое соединение обеспечивается, используя  соединение SQL (Рисунок 3 Расположение сервера электронной коммерции  в случае использования двух сетевых  интерфейсов). В идеальном случае сервер базы данных инициирует соединение в демилитаризованной зоне, так как  система расположенная в демилитаризованной зоне не находится ни в „доверительной”  части сети, ни соединена с внутренней сетью. Но всё же в данном случае необходимо чтобы сервер электронной  коммерции сохранял информацию о  трансакциях (как и о запросах) до момента, когда сервер базы данных инициирует соединение. К сожалению, в результате такой конфигурации могут появляться задержки в трансакциях, в связи, с чем в большинстве  случаев такой вариант не приемлем.

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

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

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

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

 

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

 

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

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

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

Рис. 6 «Архитектура портала системы электронной коммерции с высокой степени доступности» обобщает все выше описанные аспекты. Компоненты изображенной архитектуры обеспечивают полноценный портал с высокой степенью доступности и большим объемом обрабатываемого трафика. В зависимости от количества трафика и требований к безопасности некоторые из изображенных компонентов могут быть не обязательны.

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

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

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

 

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

 

 

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

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

Заключение

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

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

Решающее влияние на выбор (или, по крайней мере, доминирование) каких-то определённых стандартов окажет рынок, а не усилия органов стандартизации, таких как IEFT. Принятие разработчиками сложившихся стандартов (например, ранних версий SSL) и образование союзов между разработчиками покажут, какие  протоколы, скорее всего, станут популярными.

Мошенничество с кредитками в Интернет – серьезная, и, по большей  части, недооцениваемая проблема. О ней много говорят как об угрозе для безопасности потребителей, однако фактически, американские потребители рискуют немногим: по федеральным законам, их максимальная ответственность ограничивается $50 – хотя и это не останавливает множество credit card – компаний от эксплуатации фобии мошенничества при продвижении различных „схем защиты“, которые дают небольшую (если вообще дают какую либо) дополнительную защиту.

Реальный риск лежит на продавцах (мерчантах, купцах). Они несут главную ответственность за мошеннические трансакции онлайн. „Уроком является то, что продавец практически не защищен“. Сredit card компании не только мало помогают, – говорят продавцы, – но и вообще отрицают существование этой проблемы. Об Интернет говорят как о месте, где кто угодно может брать номера Ваших карточек. Но в реальности, именно продавцам приходится „проглатывать“ стоимость мошенничества.

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

Тогда как кражи такого типа – вещь не новая, Интернет значительно  облегчил этот способ. Хакеры и кракеры внедряются на сайты, хранящие эту информацию. В некоторых случаях преступники притворяются легитимными онлайновыми торговцами, и самостоятельно собирают информацию у ничего не подозревающих покупателей. 
Действительные (воспринимаемые как истинные) номера карточек могут быть так же автоматически сгенерированы. Интернет обвешан хакерскими сайтами, предлагающими софт для генерации кажущихся настоящими номеров. Т.н. „credit card generators“ используют сложный алгоритм создания номеров, в которых первые четыре цифры соответствуют „валидным“ цифрам банков-эмитентов. Генераторы „выплевывают“ 12 дополнительных цифр, которые, при проверке, „соответствуют“ параметрам валидных карточек. Даже если даже никакой банк никогда не эмитировал карточку с этим сгенерированным номером, часто credit card системы их авторизуют.

Есть и еще „старый  проверенный“ способ: карточки похищаются в физическом мире, и используются для покупок онлайн.

 

Список  использованной литературы

1. Menezes A.J., Van Oorschot P.C., Vanstone S.A. Handbook of Applied Cryptography. CRC Press, 1999- 816 p.

2. Schneier B. Applied Cryptography. John Wiley&Sons, Inc. 1996. – 758 p.

3. Соколов А.В., Шаньгин  В.Ф. Защита информации в распределенных  корпоративных сетях. М.:ДМК Пресс, 2002. – 656 с