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

Электронная коммерция: требования к безопасности

Показывать лекцию целиком

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

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

Говоря об электронной коммерции, необходимо иметь в виду, что электронные системы обработки заказов и платежей существуют уже продолжительное время. На протяжении многих лет между компаниями используется система Electronic Data Interchange (EDI) для заказа товаров и осуществления платежей. Большим преимуществом, которое заставляет много говорить об электронной коммерции, является то, что сегодня обычные покупатели могут заказать практически любой товар из любого места, а любая организация может очень быстро открыть электронный магазин. Кроме того, многие организации, занимавшиеся ранее продажей товаров через распространительные сети, теперь могут продавать свою продукцию непосредственно покупателям и таким образом снижать стоимость ведения бизнеса.

Службы электронной коммерции

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

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

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

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

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

Различия между службами электронной коммерции и обычными службами DMZ

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

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

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

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

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

Примеры служб электронной коммерции

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

Продажа товаров

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

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

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

    Предоставление конфиденциальной информации

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

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

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

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

    Вопросы взаимоотношений "компания-клиент"

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

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

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

    "компания-компания"

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

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

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

    Примечание

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

    Всемирное время

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

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

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

    Удобство клиента

    В конечном итоге доступность обуславливает удобство клиента. Насколько удобной представляется клиенту организация обработки заказа и доставки товара? Если сайт недоступен, когда клиенту требуется сделать заказ на товар, то клиент, скорее всего, ощутит неудобство.

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

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

    Убытки вследствие простоя

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

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

    Решение проблемы доступности

    Мы обсудили множество вопросов, связанных с доступностью, но теперь осталось разобраться, каким же образом разрешить все эти проблемы? Скажем сразу: никак. Нельзя полностью гарантировать доступность сайта электронной коммерции. Имея это в виду, можно говорить о мерах, предпринимаемых для управления риском недоступности сайта.

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

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

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

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

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

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

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

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

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

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

    Единственным реальным решением данной проблемы является шифрование. Большая часть стандартных веб-браузеров обеспечивает возможность шифрования трафика. Это решение используется по умолчанию в случае применения HTTPS вместо HTTP. При использовании HTTP между клиентом и сервером устанавливается соединение посредством протокола защищенных сокетов (SSL). Весь трафик, проходящий через это соединение, шифруется.

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

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

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

    Вопрос к эксперту

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

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

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

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

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

    Совет

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

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

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

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

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

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

    Вопросы для самопроверки

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

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

    С безопасностью сервера связаны два вопроса.

  • Безопасность информации, хранимой на сервере.
  • Защита самого сервера от вторжения злоумышленников.
  • Информация, хранимая на сервере

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

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

    Защита сервера от атак

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

  • Расположение сервера.
  • Конфигурация операционной системы.
  • Конфигурация веб-сервера.
  • Давайте более детально рассмотрим каждый из этих аспектов.

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

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

    Примечание

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

    Сетевое расположение сервера также необходимо принимать в расчет. На рисунке 17.2 показано расположение сервера в демилитаризованной зоне (DMZ). Межсетевой экран следует настроить на разрешение доступа к серверу электронной коммерции только через порт 80 (для HTTP) и 443 (для HTTPS). Для открытого доступа к серверу электронной коммерции не нужны дополнительные службы и, следовательно, их необходимо блокировать на межсетевом экране.

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

    (рис 17.2) Правильное сетевое расположение сервера электронной коммерции

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

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

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

    (рис 17.3) Расположение сервера электронной коммерции при необходимости использования двух сетевых интерфейсов

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

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

    Совет

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

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

    Конфигурация веб-сервера

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

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

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

    (рис 17.4) Корректная структура корневого каталога веб-сервера

    Большая часть веб-серверов поставляется со сценариями CGI (CGI - общий шлюзовой интерфейс; данная технология используется для создания сценариев на веб-сервере). Некоторые сценарии, имеющиеся по умолчанию, содержат очень серьезные уязвимости, которые позволяют злоумышленникам получать доступ к файлам или к самой системе. Любые сценарии, поставляемые с веб-сервером, которые не используются веб-сайтом, должны быть удалены, чтобы предотвратить их запуск злоумышленником с целью получения доступа к системе.

    Сценарии CGI не должны быть видны обычным пользователям, то есть веб-сервер нужно настроить на скрытие списков каталогов, если в браузере не указан файл. Если в браузере указан сценарий CGI или Perl, сервер нужно настроить на выполнение сценария, а не на отображение кода. Обычно данный аспект настраивается в файле httpd.conf в следующих строках:

    AddType application/x-httpd-cgi .cgi
    AddType application/x-httpd-cgi .pl

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

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

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

    Правила разработки приложения

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

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

    Требования безопасности следует включить в этап определения требований проекта. Эти требования включают в себя следующее:

  • определение секретной информации;
  • защита требований для секретной информации;
  • требования аутентификации для доступа или выполнения операций;
  • требования к аудиту;
  • требования доступности.
  • Если эти требования определены, то при проектировании системы можно будет выявить потенциальные проблемы. Вся секретная информация должна определенным образом защищаться. Это обуславливает наличие компонентов приложения, требующих HTTPS вместо HTTP. Для секретной информации требуется не только шифрования при передаче. Некоторые данные, например частные сведения о клиенте, требуют защиты при записи на компьютер клиента в элементах сookie. При проектировании необходимо принимать это в расчет, и в данном случае использовать шифрование элементов cookie.

    Необходимо также упомянуть еще один вопрос, связанный с секретной информацией. Информация может стать секретной из-за метода, посредством которого она используется в приложении. Например, некоторые приложения передают информацию между программами с использованием URL (универсального указателя ресурсов, представляющего собой адрес веб-сайта в адресной строке браузера). Если отображается длинный URL со знаком вопроса "?", отделяющим различные значения, то приложение передает параметры другим сценариям или программам. Клиент может поменять эти параметры и изменить функционирование программ. Некоторые сайты электронной коммерции записывают выбранные покупателями товары в адресах URL. Эта информация содержит код товара, количество и стоимость. Если бы в базе данных не осуществляется проверка данных, клиенты могут изменять цену товаров. Был случай, когда клиент заметно уменьшил цену, и организация фактически продала товар по очень низкой цене. Принимая во внимание этот пример, становится ясно, что стоимость товаров является очень важной информацией. Если для передачи этой информации между сценариями или программами используется URL, значения стоимости (по крайней мере) должны проверяться в базе данных перед обработкой заказа.

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

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

    Правильные методы программирования

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

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

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

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

    Совет

    Для более полной оценки уязвимостей, имеющихся на сайте, вместо применения одного только сканера уязвимостей следует использовать сканер приложений, а также осуществлять поиск уязвимостей. Одной из таких коммерческих утилит является WebInspect от SPI Dynamics (http://www.spidynamics.com/).

    Общедоступность исходного кода

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

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

    Управление конфигурацией

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

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

    Примечание

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

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

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

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

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

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

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

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

    Примечание

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

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

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

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

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

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

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

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

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

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

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

    Примечание

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

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

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

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

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

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

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

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

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

    Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Какая служба безопасности является наиболее критичной для электронной коммерции?
  • Какой тип электронной коммерции обуславливает возникновение самых больших проблем с течением времени?
  • Что подразумевается под термином "всемирное время"?
  • Можно ли напрямую оценить убытки компании во время ее бездействия?
  • Если информация должна храниться на системе-клиенте, что необходимо использовать для защиты конфиденциальности информации?
  • Где должна храниться информация о клиентах на сайте электронной коммерции?
  • Где должны быть расположены серверы электронной коммерции, взаимодействующие с клиентом?
  • Где должны находиться веб-страницы при настройке веб-сервера?
  • В каком файле должны быть определены файлы .cgi и .pl, чтобы программы выполнялись без отображения исходного кода на веб-странице.
  • Если в транзакции задействована секретная информация, какое местоположение является наиболее рекомендуемым для хранения информации сеанса?
  • Во время этапа разработки проекта разработчики должны предотвращать переполнение буфера посредством запрета на прямую передачу введенных ими данных командам оболочки и _____________.
  • В трехзвенной архитектуре электронной коммерции имеет ли сервер базы данных связь с интерфейсными веб-серверами?
  • Какие методы сканирования уязвимостей должны проводиться на коммерческих сайтах?
  • Какие системы больше всего подходят для выявления проблем, связанных с контролем конфигурации?
  • Может ли доступность полностью обеспечиваться избыточным оборудованием?
  • Вернуться к учебному плану