Аналитика, Балтия – СНГ, ЕС – Балтия, Круглый стол, Латвия, Рынки и компании, Технологии, Форум

Статья подготовлена для Круглого стола-семинара, прошедшего в Балтийской международной академии (БМА) 27 апреля 2011 года. Его организаторы: БМА, интернет-журнал The Baltic Course, Конфедерация работодателей Латвии и Дипломатический экономический клуб (DEC).

Из множества определений качества работы ИТ бизнес использует самые неконкретные — "соответствие ожиданиям" и "что-то хорошее", а ожидания в большинстве случаев сводятся к тому, чтобы "все работало и не беспокоило". Все выше сказанное в полной мере относится и к актуальным вопросам безопасности и возможных рисков в среде электронной коммерции.

Безопасность электронной коммерции

Петр Дорогов на Круглом столе в БМА. Рига, 27.04.2011. Фото Мариса Морканса.

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

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

• В принципе, возможно, выстроить полностью защищённую систему — системы могут быть защищены только от известных опасностей, снизив количество связанных с ними рисков до приемлемого уровня. Только сам управляющий предприятия может обозначить необходимое равновесие между желаемым уровнем снижения рисков и стоимостью соответствующего решения. Безопасность сама по себе есть не что иное, как один из аспектов процесса управления рисками, в то время как информационная безопасность является общностью здравого смысла, управления бизнес-рисками, адекватной базы технического опыта в области управления, рационального использования специализированных продуктов и других аспектов. В дополнение к этому нужно учитывать, что сама ВЕБ-страница это только вид доставки информации потребителю.
• Брандмауэры не проницаемы — после имплементации брандмауэра можно сидеть, почивая на лаврах в уверенности, что злоумышленники некогда не пройдут через него. Проблема заключается в том, что эго необходимо конфигурировать, причем, таким образом, чтобы через него в обоих направлениях шел определённый трафик. Атака на главную страницу вашего портала разительно отличается от попытки использования вашего ВЕБ-сервера для получения доступа до других серверов системы, соответственно требования к брандмауэрам в обоих случаях абсолютно разные. Для большей части систем необходимы сложные, многослойные системы зашиты сконфигурированные таким образом, чтобы доступ к защищаемой информации был только у авторизованных пользователей.
• Компания, у которой имеется открытый сертификат от заслуживающего уважения Сертификационного Агентства (Certification Authority (CA)), сама по себе уже заслуживает доверия — сертификат всего лишь означает что-то близкое к: „в момент запроса выдачи сертификата, я, CA, выполнило определённые действия для проверки личности этой компании. Вас это может устраивать или нет. Я не знакомо с этой компанией и не знаю можно ли ей доверять, и какой у неё бизнес. До момента, когда меня информируют, что выданный мной открытый ключ дискредитирован я даже не узнаю что он, например, украден или передан кому-нибудь другому и это ваш долг проверить, не аннулирован ли он. Моя ответственность ограничивается регулирующими правилами, которые описывают политику моей компании, которые вам необходимо тщательно изучить, перед использованием ключей связанных с этой компанией”

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

С этой частью системы связанны некоторые аспекты:

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

Рисунок 1. Домашняя страница е-коммерции

Безопасность соединений

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

Единственное возможное решение этой проблемы это шифрование данных. Большая часть стандартных браузеров обеспечивает возможность шифрования трафика. Такое решение используется по умолчанию, вместо протокола HTTP используя протокол HTTPS. Используя HTTPS между клиентом и сервером, устанавливается соединение, которое в свою очередь использует SSL протокол (Secure Socket Layer). Весь трафик, который идёт через это соединение шифруется.

Шифрование HTTPS гарантирует безопасность информации с момента её отправки с компьютера клиента до прихода на сервер. Использование HTTPS стало необходимым, так как пользователи стали понимать, что преступник может получить доступ к данным кредитных карточек посредством интернета.

Хранение информации на компьютере клиента

Не HTTP, не так же HTTPS протоколы не фиксируют состояния, что означает, что после загрузки ВЕБ-страницы в браузере, сервер не фиксирует, что в данном браузере только что была загружена именно эта страница. Для реализации коммерческой деятельности в интернете с использованием ВЕБ браузеров и ВЕБ серверов, серверам необходимо фиксировать информацию о действиях клиента (это информация о самом клиенте, информация о заказываемых товарах и обо всех паролях, которые используются для доступа к охраняемым страницам). Один из способов, с помощью которого можно обеспечит данную функциональность (это самый распространенный метод) это использование элементов cookie.

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

Cookie можно использовать для записи любой информации с ВЕБ-сервера. На одной странице они могут быть использованы для отслеживания заказов, пока клиент выбирает различные элементы, на другой — cookie используются для проверки данных аутентификации, чтобы клиенту не приходилось авторизоваться на каждой странице.

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

Отказ от выполненной операции

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

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

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

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

Реализация безопасности серверной части

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

С безопасностью сервера связанны следующие вопросы:

• Безопасность информации хранящейся на сервере;
• Охрана сервера от доступа злоумышленников.

Информация, хранящаяся на сервере

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

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

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

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

• Размещение сервера;
• Конфигурация операционной системы;
• Конфигурация ВЕБ-сервера.

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

На „Рисунок 2 Правильное расположение сервера электронной коммерции в сети” отображено размещение сервера в демилитаризованной зоне (DMZ). Брандмауэр должен быть правильно сконфигурирован позволяя подключаться к серверу только используя порта 80 (для HTTP) и 443 (для HTTPS). Для открытого доступа к серверу не нужны дополнительные сервисы, соответственно их необходимо блокировать на брандмауэре.

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

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

Рисунок 3. Расположение сервера электронной коммерции в случае использования двух сетевых интерфейсов

Конфигурация операционной системы

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

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

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

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

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

Конфигурация ВЕБ-сервера

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

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

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

Рисунок 4. Правильная структура корневого каталога ВЕБ-сервера

Реализация безопасности сервера базы данных

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

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

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

• Место размещения базы данных;
• Способ как сервер базы данных соединяется с веб-сервером или аппликационным сервером;
• Как сервер базы данных защищен от внутренних пользователей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

Описанию этих вопросов можно посвятить несколько отдельных статей.

Обзор Круглого стола можно прочитать здесь.