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

И завершает рубрику статья о методах и средствах обеспечения безопасности
электронно-коммерческого сайта. Из нее вы узнаете обо всех элементах сложной
системы защиты сайта от несанкционированного доступа и технологических
подходах, применяющихся при построении такой системы. Кроме того, каждый раздел
статьи снабжен примером реализации соответствующего элемента системы
безопасности на сайте-образце Microsoft Duwamish Online Sample E-commerce
Site.

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

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

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

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

Ниже будут рассмотрены технологические подходы, которые можно использовать для защиты сайта компании от всех видов недобросовестных пользователей. В каждом разделе описываются определенные вопросы безопасности, а затем дается пример их решения на сайте-образце Duwamish Online Sample E-Commerce Site. Однако следует заметить, что у группы, реализовывавшей данный сайт, были свои ограничения, и, возможно, другие разработчики предпочли бы другие пути, нежели выбранные в данном случае.

Архитектура безопасности Microsoft Windows DNA

Общая архитектура приложения Windows DNA показана ниже:

В общем случае происходит следующее: клиент получает доступ к приложению через Интернет. Запрос проходит через брандмауэр, отфильтровывающий пакеты, посланные на неверный адрес или порты. Клиенты общаются с приложениями через Интернет. Web-сервер под управлением Microsoft Internet Information Server (IIS) обычно обрабатывает эти запросы в странице Active Server Pages (ASP). Страница ASP вызывает COM-компоненты под управлением COM+ runtime для чтения и модификации базы данных и для возврата HTML-страницы клиенту. В дальнейшем эти серверы могут быть подсоединены к корпоративной сети, обычно это делается через второй брандмауэр (чтобы лучше защитить доступ к корпоративной сети от взломщиков). Заметьте, что многие предприятия предпочитают не соединять серверы напрямую с корпоративной сетью дабы избежать любой возможности нарушения своей сети внешними пользователями.

Серверы интерфейса (front-end servers) обеспечивают функциональность приложения. Обычно они представляют собой Microsoft IIS. Кроме того они могут кэшировать данные, предназначенные "только для чтения" - например, web-страницы. Группа прикладных серверов (back-end servers) отвечают за изменяемый контент. Этот контент может обеспечиваться через файлы общего доступа, реляционные СУБД (например, Microsoft SQL Server) или системы управления ресурсами - такие как SAP. Контент генерируется и дублируется на серверы приложений из корпоративной сети, иногда через Интернет с использованием защищенных FTP или PPTP (VPN), если не существует прямого соединения серверов приложений с корпоративной сетью.

Как это реализовано на Duwamish Online

Архитектура Duwamish Online несколько отличается от общего случая, описанного выше:

Duwamish Online состоит из одной группы четырех двухпроцессорных web-серверов, подсоединенных к группе из двух серверов баз данных, имеющих доступ к общему для них дисковому массиву RAID. Заметьте, что Duwamish Online не имеет прямого соединения с корпоративной сетью - ее администрирование происходит путем физического доступа к машинам и использования сетевое dial-up-соединение через Службы Удаленного Доступа (Remote Access Service, RAS). При этом можно использовать и защищенный доступ через Интернет.

Программное обеспечение Duwamish Online реализовано как набор логических уровней:

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

Три средних уровня находятся на web-серверах.

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

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

Требования безопасности

Для полного сценария необходимо обеспечить безопасность на следующих уровнях:

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

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

• сеть общего пользования, состоящая из клиентов, имеющих доступ к серверам интерфейса и Интернет;
• "демилитаризованная зона" (DMZ), состоящая из групп серверов интерфейса и прикладных серверов;
• корпоративная сеть.

Области защищены друг от друга брандмауэрами.

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

Защита сети

Для реализации защиты сети на сайте Windows DNA используют:

• DMZ;
• брандмауэры;
• сегрегацию сети;
• шифрование данных;
• выявление вторжений.

DMZ

DMZ состоит из серверов интерфейса, прикладных серверов и брандмауэров.

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

В обеспечении защиты участвуют такие элементы DMZ, как:

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

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

Как это реализовано на Duwamish Online

В Duwamish Online использовался брандмауэр, предоставленный нашим ISP (ITG-группа Microsoft), серверы повышенной безопасности и самый мощный брандмауэр между Duwamish Online и корпоративной сетью: т.е. вообще никаких соединений.

Брандмауэры

Брандмауэры часто реализуются на уровне сетевого протокола и используются для фильтрации входящего трафика сети. Можно сконфигурировать брандмауэр таким образом, чтобы он пропускал или блокировал пакеты от определенных IP-адресов или портов. Для реализации брандмауэра можно использовать маршрутизатор сети и сконфигурировать его, или приобрести аппаратное обеспечение с расширенными возможностями, специально предназначенное для реализации брандмауэра. Более сложные брандмауэры могут выявлять попытки вызвать отказ от обслуживания и обеспечить перевод сетевого адреса (Network Address Translation, NAT) для сокрытия адресов ресурсов за брандмауэром.

Для сайта Windows DNA конфигурируют и фронтальные Интернет-брандмауэры и внутренние брандмауэры. Фронтальные брандмауэры должны обеспечивать доступ к таким сервисам, как HTTP, LDAP (Lightweight Directory Access Protocol), FTP и почте SMTP. Чтобы сделать брандмауэр действительно мощным, можно закрыть все порты кроме 80-го (для HTTP) и 443-го (для HTTP/SSL) и заблокировать доступ ко всем IP-адресам, кроме IP-адреса вашей web-группы. Кроме того, для B2B-сайта может потребоваться поддержка виртуальной частной сети (Virtual Private Network, VPN).

Следует также ограничить доступ к сервисам, потенциально способным нанести вред системе в том случае, если пользователь Интернет сможет получить к ним доступ. Например, следует удалить доступ к сервису телнет.

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

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

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

Как это реализовано на Duwamish Online

Брандмауэр для Duwamish Online реализован нашим ISP (ITG-группа Microsoft). В нем разрешены только TCP/IP порты 80 (HTTP) и 443 (SSL), и только в случае прямого соединения с IP группы web-серверов. Все другие запросы отклоняются.

Сегрегация сети

Сеть в пределах DMZ может сегрегироваться с помощью двух или более сетевых интерфейсных плат (Network Interface Card, NIC) в каждом компьютере. Сегрегация сети позволяет:

• Разделить различные типы Интернет-трафика и направить их к различным web-серверам. Например, HTTP-запрос может быть направлен к одному набору web-серверов, а FTP-запрос - к другой группе. Это не обязательно способствует повышению безопасности, но может помочь сбалансировать нагрузку.
• Разделить Интернет-трафик и прикладные сервера и закрыть прямой доступ во внутреннюю сеть. NIC могут настраиваться для прохождения к серверу только соответствующих ему пакетов.
• Избежать пересылки IP между серверами интерфейса. Единственным общедоступным IP-адресом является виртуальный IP-адрес, используемый группой серверов интерфейса со сбалансированной нагрузкой. Крайне важно отключить пересылку IP.

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

Как это реализовано на Duwamish Online

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

Шифрование данных

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

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

SSL представляет собой схему для таких протоколов, как HTTP (называемого HTTPS в случае его защищенности), FTP и NNTP. При использовании SSL для передачи данных:

• данные зашифрованы;
• между сервером-источником и сервером назначения установлено защищенное соединение;
• активирована аутентификация сервера.

Как это реализовано на Duwamish Online

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

Безопасность информации о кредитных картах

Чтобы получить представление о том, как работает шифрование открытым ключом и SSL, рассмотрим случай, когда клиент помещает несколько продуктов в свою корзину и желает их приобрести. После подтверждения заказа и адреса, на который будет направлен счет, клиенту потребуется указать подробности способа платежа. Если потребитель использует кредитную карту, информацию необходимо передавать по защищенному каналу. Поэтому форма или страница заказа будет помещена на защищенный сервер. Потребитель может определить защищенную форму по ее URL; web-страницы, требующие SSL для передачи данных, имеют URL, начинающийся с "https", вместо обычного "http". Кроме того, в строке состояния броузера отображается иконка-замок. Броузер проверит наличие цифрового сертификата и его допустимость. Затем он воспользуется открытым ключом сертификата для шифрования информации. После подтверждения информации потребителем она передается по защищенному каналу на сервер.

Использование SSL увеличивает объем необходимой обработки, так как данные требуется зашифровать и расшифровать. Кроме того, SSL-серверы должны поддерживать свое состояние между запросами, так как защищенный канал необходим особому пользователю - для расшифровки посылаемой в ответ информации должна использоваться та же пара ключей, с помощью которой производилось ее шифрование. Это может создать проблемы на сайтах со сбалансированной нагрузкой, направляющих запросы клиентов в соответствии с готовность сервера и не поддерживающих состояние серверов. Чтобы избежать таких проблем, необходимо настроить баланс нагрузки так, чтобы он имел сходство с клиентом для HTTPS (порт 443).

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

Как это реализовано на Duwamish Online

В первом релизе Duwamish Online HTTPS-страницы располагались на тех же серверах, где и все другие. Если в будущем это как-то повлияет на работу, можно будет легко использовать специальные серверы.

Выявление вторжений

Системы выявления вторжений (Intrusion Detection Systems, IDS) могут идентифицировать схемы или следы атак, генерировать аварийные сигналы для предупреждения операторов и побуждать маршрутизаторы прерывать соединение с источниками незаконного вторжения. Эти системы могут также предотвращать попытки вызвать отказ от обслуживания. Отказ от обслуживания происходит, когда пользователь посылает фрагменты TCP-запросов, замаскированные под допустимые TCP-запросы, либо посылает запросы с несоответствующего IP-источника. Сервер не способен обработать такое множество запросов и поэтому выдает сообщение об отказе от обслуживания добросовестным пользователям сайта. IDS обеспечивает мониторинг в реальном времени трафика сети и реализует метод "предотвратил, выявил и отреагировал" в области безопасности.

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

• IDS увеличивают объем обработки и могут повлиять на работу всего сайта;
• IDS достаточно дорого стоят;
• IDS могут иногда принимать нормальный трафик сети за незаконные атаки и выдавать ненужные аварийные сигналы.

Системы для выявления вторжений выпускаются различными фирмами. Например, для мониторинга трафика сети в реальном времени можно использовать NetRanger компании Cisco или RealSecure от ISS. И IDS все еще продолжают развиваться.

Как это реализовано на Duwamish Online

IDS Duwamish Online обеспечивается брандмауэром, предоставленным нашим ISP (ITG-группы Microsoft).

Защита платформы

Дополнительно к защите сети от незаконных атак необходимо защищать каждый компонент сайта. Платформа приложения может быть защищена следующим образом:

• повышением защищенности серверов в DMZ;
• мониторингом;
• защитой данных сайта;
• аутентификацией клиента;
• конфигурированием доменной структуры Windows.

Повышение защищенности серверов в DMZ

Каждый сервер в DMZ должен быть защищен индивидуально. Повысить защищенность серверов интерфейса можно следующим образом:

• Переустановить Windows 2000 Advanced Server, установив только необходимые компоненты.
• Поддерживать актуальность пакетов служебных программ и обновлений безопасности через подписку на бюллетень Microsoft security на http://www.microsoft.com/security/.
• Убедиться в отсутствии общего доступа в сети.
• Использовать защищенную файловую систему NTFS вместо FAT или FAT32.
• Переименовать аккаунт администратора. Можно создать фальшивый не имеющий привилегий аккаунт и проследить за его использованием с целью выявления атак. Убедиться в использовании мощной парольной защиты для администраторского аккаунта и сокращении членства в местной Группе администраторов до минимально возможного числа аккаунтов.
• Отключить гостевой аккаунт. Гостевой аккаунт может создать нежелательный доступ к сетевым ресурсам. В Windows 2000 гостевой аккаунт отключен по умолчанию.
• Установить местную политику для формирования требований к мощной парольной защите всех аккаунтов и активизации блокировки локальных аккаунтов.
• Защитить файловую систему NTFS, особенно системное дерево Windows 2000, удалив доступ для Общей группы (Everyone group) и добавив доступ только для тех пользователей, которым он необходим (возможно с помощью добавления Пользовательской группы (Users group)).
• Защитить системный журнал как это описано в Microsoft Technical Support Knowledge Base, разделы "Ограничение информации, доступной для пользователей, подключившихся анонимно" ("Restricting Information Available to Anonymous Logon Users", item Q143474) и "КАК: Регулировка сетевого доступа к Windows NT Registry" ("HOWTO: Regulate Network Access to the Windows NT Registry", item Q155363). Кроме того, изменить средство просмотра фалов типа *.reg на что-либо вроде Notepad.
• Отсоединить NETBIOS от TCP/IP. Это исключит доступ пользователей к ресурсам с помощью команды nbstat.
• Активизировать проверки. Проверять по меньшей мере: успешные и неуспешные подключения/отключения, управление пользователями и группами, рестарты и выключения (shutdown), а также изменения политики безопасности.
• Убедиться, что установлены только необходимые сервисы. Если какие-то из них не используются - убедиться, что отключены messenger и сервис предупреждений, DCOM, простые сервисы TCP/IP, телнет и FTP. Если FTP необходим - отключить доступ на запись. Если необходим FTP-доступ на запись - не разрешать чтение и запись в одну и ту же директорию и запись в корневую директорию FTP.
• Убедиться, что защищен SQL Server, в том числе: отключены ненужные аккаунты и установлены строгие пароли на оставшиеся, особенно на аккаунт системного администратора.
• Не активизировать автоподключение.
• Отключить IP-маршрутизацию и WINS-клиента. Таким образом можно предотвратить обмен информацией между Интернет и корпоративным Интранет.

Кроме того, можно реализовать правила низкоуровневой фильтрации и избирательно закрыть порты. Например, можно сконфигурировать TCP/IP фильтрацию. Это можно сделать, определив, какие порты разрешены в каждой сетевой карте. Например, можно разрешить только TCP-порты 80 (HTTP) и 443 (SSL). Кроме того, необходимо отключить порты User Datagram Protocol (UDP).

Дополнительную информацию по повышению защищенности IIS-серверов см. в "Microsoft Internet Information Server 4.0 Security Checklist" на http://www.microsoft.com/technet/iis/technote/iischeck.asp.

Для повышения защищенности можно использовать сервисы Windows 2000 - например, IPSecure, Security Configuration Editor и Group Policy Editor. Более подробно о Windows 2000 Group Policy Editor можно узнать из раздела "Group Policy" Windows 2000 Resource Kit, находящегося на http://www.microsoft.com/windows2000/library/resources/ reskit/samplechapters/dsec/dsec_pol_zbgy.asp. Windows 2000 упрощает и задачу защиты всех серверов группы, предоставляя возможность применять к серверам шаблоны безопасности.

Мониторинг

Необходимо регулярно проверять сервера через небольшие интервалы времени. Проверка гарантирует, что конфигурация и политика безопасности дадут требуемые результаты и не изменяют конфигурацию. Можно проверять журналы событий Windows 2000, журналы IIS и использовать такие инструменты, как Security Configuration and Analysis и sysdiff.

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

Как это реализовано на Duwamish Online

Для выявления нестандартных действий группа операторов Duwamish Online осуществляет мониторинг журналов IIS на регулярной основе.

Защита данных сайта

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

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

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

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

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

Как это реализовано на Duwamish Online

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

Аутентификация клиента

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

• Cookies.
• Пароли.
• Клиентские сертификаты.
• Microsoft® Site Server.
• Microsoft® Passport.

Для идентификации клиентов можно использовать cookies. Cookie - это маленький файл, встроенный в броузер пользователя и хранящийся на винчестере его компьютера. Cookies могут содержать зашифрованные данные, помогающие приложению идентифицировать пользователя и обеспечивать пользователя соответствующей ему информацией. И никакой другой клиент не сможет получить доступ к информации, связанной с конкретным пользователем. Тем не менее, поскольку cookie хранится на компьютере потребителя, любой другой пользователь этого компьютера будет иметь тот же самый cookie. Duwamish Online использует cookies oтолько для ID сессий в рамках единичной сессии посещения магазина, но не для аутентификации.

Можно идентифицировать клиентов и с помощью UserID и пароля в процессе SSL-шифрованной сессии. Это наиболее распространенный на сайтах метод - и Duwamish Online также использует его.

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

Клиентские сертификаты могут генерироваться и управляться с помощью Microsoft® Certificate Services. Этот продукт работает с клиентами, броузерами и web-серверами как фирмы Microsoft, так и других производителей.

Относительно использования Microsoft Site Server отметьте, что в нем имеется серьезная поддержка аутентификации и персонализации, а также модули членства.

Еще один подход к аутентификации в рамках бизнес-сайта заключается в использовании Microsoft Passport. Microsoft Passport позволяет пользователю хранить подробности своих параметров в защищенном централизованном месте. Эта информация может быть доступна через совместимое с Microsoft Passport приложение или партнерский сайт. Аутентификация и обработка выполняется сайтом Passport и избавляет партнерский сайт от необходимости реализовывать дополнительные меры безопасности. Duwamish Online также использует Passport наряду с системой паролей.

Дополнительную информацию по Microsoft Passport см. на http://www.passport.com.

Как это реализовано на Duwamish Online

Duwamish Online применяет защиту с помощью пользовательских ID/паролей через защищенный sign-on для большинства пользователей, и Microsoft Passport для имеющих его пользователей. Кроме того, Duwamish Online использует и cookies, но только для ID сессий, а не для аутентификации.

Конфигурирование доменной структуры Windows

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

Защита на уровне приложения

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

• Возможность использования объединений в пул соединений баз данных для управления клиентскими запросами и имеющимися ресурсами. (Использовать отдельный аккаунт Windows 2000 для каждого web-пользователя неразумно, так как каждое соединение баз данных требует пользовательский ID, означающий одно соединение для одного синхронного web-пользователя, а система не может поддерживать большое число соединений баз данных).
• Возможность контроля доступа к бизнес-логике и данным, доступ к которым организуется согласно этой логике.
• Возможность несложной переконфигурирации политики безопасности, упрощающей управление приложением.

COM+ использует объединение соединений в пул для управления соединениями сервера и ресурсами для множества клиентских запросов. Эта характеристика важна для нормальной работы приложения при оптимальных затратах.

Для идентификации внутренних пользователей можно применить возможности аутентификации и администрирования безопасности, заложенные в COM+. Тем не менее, в данном случае необходимо придерживаться другого подхода к web-пользователям. Их идентификация должна производиться средним ярусом программно, поскольку, как известно, нет смысла в предоставлении отдельного аккаунта домена каждому web-пользователю. Заметьте, как в этом контексте полезно участие Site Server: он маппирует web-пользователей в набор пользовательских ID Windows, которые в свою очередь могут быть маппированы в роли безопасности приложения COM+.

Реализация безопасности на среднем ярусе приложения COM+ выглядит следующим образом:

• Административная безопасность.
• Программируемая ролевая безопасность.
• Службы аутентификации.
• Деперсонализация (обычно не выполняется в web-приложениях, так как затрудняет объединение соединений в пул).

Административная безопасность

В приложениях можно реализовать административную или ролевую безопасность, определив политику контроля доступа для приложения. Для приложения COM+ можно сконфигурировать роли с помощью административного инструмента Component Services или административной объектной модели. Сервисы ролевой безопасности COM+ помогают избежать записи кода аутентификации в приложении. Кроме того, они способствуют более детальной проверке, так как COM+ регистрирует сбои безопасности в журнале событий.

Программируемая ролевая безопасность

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

Сервисы аутентификации

COM+ и Windows 2000 позволяют проверить допустимость идентификации пользователя клиентского приложения. Аутентификационные сервисы COM+ активизируются административным путем. Приложение COM+ может иметь множество уровней аутентификации. Самый нижний уровень аутентификации - это отсутствие аутентификации. А самый высокий уровень - это шифрование всех пакетов данных и параметров вызова методов.

Деперсонализация

Приложение сервера может требовать деперсонализации клиента для некоторых своих сервисов. Например, приложение сервера может нуждаться в доступе к базе данных от имени клиента. COM+ позволяет деперсонализировать клиентов, обеспечив различные уровни деперсонализации.

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

Как это реализовано на Duwamish Online

Duwamish Online аутентифицирует web-пользователей на среднем ярусе, как это описано в разделе "Программируемая ролевая безопасность". Это типичный способ реализации защиты для web-приложений на уровне приложения.

Защита базы данных

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

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

Duwamish Online использует Microsoft SQL Server в качестве серверной (прикладной) части. Для реализации безопасности на уровне данных с помощью Microsoft SQL Server можно использовать:

• Аутентификацию.
• Роли и защиту приложений.
• Проверку допустимости допусков.
• Шифрование.

Аутентификация

В первую очередь Microsoft SQL Server аутентифицирует клиентов. Существует два режима аутентификации:

• Microsoft® Windows NT® Authentication Mode, в котором SQL Server подтверждает, что имя пользователя и пароль были проверены на допустимость при подключении пользователя к Windows 2000 Server. Этот метод почти никогда не используется для электронной коммерции из-за нехватки соединений баз данных.
• Mixed Mode, при котором пользователи могут подключаться к серверу с помощью аккаунта Microsoft Windows NT или логина SQL Server и пароля. Логин и пароль SQL Server могут использоваться в случае, если база данных содержит некритичную информацию и конфиденциальность не является одним из основных требований для данного приложения. И это также не используется для web-клиентов - однако необходимо убедиться, что администраторские пароли к базе данных отключены.

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

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

Роли и защита приложения

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

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

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

Проверка допустимости допусков

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

Шифрование

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

SQL Server может шифровать следующие типы данных:

• Пароли логинов и ролей приложения.
• Данные, пересылаемые между клиентом и сервером в виде сетевых пакетов - например, номера кредитных карт.
• Определения хранимых процедур.
• Определения представлений.
• Определения триггеров.

Для пересылки зашифрованных данных от клиента к серверу баз данных клиент должен быть настроен для использования Multiprotocol Net-Library. Net-Library использует удаленный вызов процедур (remote procedure call, RPC) Windows 2000, обеспечивающий аутентификацию и облегчающий использование. Хотя в этом есть своя логика, однако возможно кто-то из разработчиков предпочтет задействовать и протестировать шифрование исключительно чувствительных данных приложения (таких, как номера кредитных карт) с помощью Microsoft® CryptoAPI.

Вывод

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

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

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

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

Автор: Пол Джонс, Армайндер Кеюр