Безопасность

Не совсем корректно рассматривать безопасность e-commerce платформ отдельно от безопасности тех инфраструктурных решений, которые лежат в их основе и используются для развертывания. Соответственно, и построение безопасной системы требует корректного подхода к безопасности во всех ее звеньях. Вместе с тем, для обеспечения безопасности требуется, чтобы сама платформа поддерживала определенную функциональность и архитектурные решения. В общем случае можно, конечно, обращаться с торговой системой как с «черным ящиком» и выстраивать весь периметр безопасности вокруг нее на основе других доступных решений и технологий. Но в таком случае и саму платформу следовало бы считать в чем-то ущербной и неполной. Современные платформы enterprise-класса содержат и поддерживают множество функций, имеющих отношение к безопасности. Вот некоторые из них:

Аутентификация пользователей и шифрование данных
Авторизация и управление правами пользователей
Модель безопасности Java 2
Аудит безопасности

Аутентификация пользователей и шифрование данных

В общем случае различают следующие способы аутентификации:

по имени пользователя (логину) и паролю (username/password authentication);
по сертификату (certificate authentication);
дайджест-аутентификация (digest authentication);
децентрализованная или периметровая аутентификация (perimeter authentication).

Также встречается многофакторная аутентификация (multi-factor authentication), определяемая как комбинация нескольких способов аутентификации, применяемых последовательно.

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

Технология работы SSL состоит в том, что в ответ на запрос, поступающий от SSL или HTTPS-клиента, сервером предоставляется цифровой сертификат (SSL-сертификат), который затем используется для шифрования соединения. Сам сертификат подтверждает идентичность сервера (server identity) и должен быть выдан доверенным центром сертификации (trusted certificate authority). Существует также механизм двусторонней SSL-аутентификации. В этом случае для установления соединения сертификат должны предоставить обе стороны – клиент и сервер.

Все современные web-сервера, которые могут входить в архитектуру e-commerce решения на любой из рассматриваемых платформ, в том или ином виде поддерживают SSL-сертификаты и шифрование коммуникаций по протоколу HTTPS. Некоторые отличия могут проявляться только в поддерживаемых методах шифрования и типах (форматах) самих сертификатов. Но в архитектуре многозвенных систем присутствует множество соединений. Это и внешние подключения пользователей и администраторов к web-серверу или серверу приложений, и внутренние соединения между самими серверами, и каналы коммуникации с СУБД, средствами кэширования, поисковыми машинами. На практике может потребоваться защита и этих каналов по протоколу HTTPS или просто TLS/SSL (по сути, протокол HTTPS – это передача трафика HTTP по протоколу TLS/SSL). Для всех рассматриваемых систем enterprise-класса (IBM WebSphere Commerce, Oracle Commerce, SAP hybris) это тоже может быть реализовано штатными средствами. Некоторые сложности с шифрованием по TLS/SSL межузловых коммуникаций могут возникнуть с платформами для малого и среднего бизнеса (1С-Битрикс: Управление сайтом, Magento, VirtueMart). Например, не все сервера кэширования поддерживают такую возможность (Memcache и REDIS не поддерживают, Couchbase поддерживает). В тоже время для этих платформ существует множество сторонних плагинов, которые реализуют оптимальные для СМБ схемы управления сертификатами и режимами шифрования.

Дополнительную особенность на российском рынке привносит необходимость использования российских ГОСТов в системах шифрования и проверки сертификатов. Соответствующий модуль существует для web-серверов Apache и их модификаций IBM HTTP Server, Oracle HTTP Server, а также Microsoft IIS, Oracle iPlanet Web Server (Sun Java System Web Server). Для J2EE-серверов приложений распространяется модуль КриптоПро JCP, разработанный в соответствии с требованиями интерфейса JCA. Для платформы Oracle Commerce удобным решением является использование шлюза Trusted TLS в паре с продуктом Oracle Access Manager, который входит в состав инфраструктуры Oracle Fusion Middleware и интегрируется с Oracle WebLogic.

Авторизация и управление правами пользователей

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

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

Все платформы enterprise-класса (IBM WebSphere Commerce, Oracle Commerce, SAP hybris) содержат развитые механизмы авторизации и управления правами пользователей. Также они могут интегрироваться с внешними службами каталогов по протоколу LDAP. Это позволяет без особых проблем реализовывать службы SSO (Single Sign-On) и управлять сертификатами, ролями и правами доступа пользователей в централизованной манере. Соответствующие инструменты для этого имеются в продуктовых линейках Oracle, IBM и VMWare.

При использовании платформ уровня малого и среднего бизнеса (1С-Битрикс: Управление сайтом, Magento, VirtueMart) в первую очередь следует учитывать, что PHP традиционно не считается безопасной платформой. И если даже считать такое вполне распространенное мнение субъективным, нельзя не согласиться с тем, что возможности Java-платформ в этом смысле шире. Для PHP настоящим бичом являются взломы через инжекцию кода, с которыми разработчики борются годами, но не имея средств контроля доступа к объектам (как это предусмотрено, к примеру, в Java 2 Security), решить проблему в корне не могут. Этот недостаток настолько значителен, что именно его и можно называть основным «водоразделом», отделяющим платформы разного класса.

В остальном для платформ «нижнего» уровня нет каких-то значительных отличий. Все вопросы управления правами и ролями пользователей реализуются либо средствами самой платформы, либо с помощью доступных на рынке плагинов (расширений). Наиболее развитые в этом плане средства существуют для платформы 1С-Битрикс: Управление сайтом.

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

Модель безопасности Java 2 (Java 2 Security)

Модель безопасности Java начала разрабатываться в 1996 году и сформировалась в ее текущем виде к 2002. С появлением Java 2 и расширений Enterprise Edition технология Java приобрела свойства стабильной промышленной платформы, а модель безопасности Java 2 позволила реализовывать системы высокого уровня защищенности. К основным возможностям модели безопасности Java 2 относятся:

Тонкий контроль доступа для Java-кода
Настраиваемые политики безопасности
Расширяемая архитектура контроля доступа
Проверки безопасности для всех Java-программ

Поддержка безопасности Java 2 реализована в платформах IBM WebSphere Commerce, Oracle Commerce и SAP hybris. При этом для SAP hybris управление безопасностью осуществляется через специальный модуль hybris Security Module, который, в свою очередь, построен на базе SpringSecurity framework. В системах IBM и Oracle безопасность Java 2 может активироваться и деактивироваться через настройки конфигурации.

Аудит безопасности

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

Все рассматриваемые e-commerce платформы позволяют осуществлять аудит безопасности. Отличаться может глубина (подробность) такого аудита и инструментарий, используемый для этого. Так в простейших системах на базе Joomla/VirtueMart или Magento аудит осуществляется средствами CMS Joomla или через соответствующие механизмы используемого web-сервера. При таком аудите довольно сложно отследить, например, изменение карточки продукта или статуса какой-то конкретной транзакции. То есть, для подобных систем целесообразно строить внешний контур безопасности на основе специализированных решений, не полагаясь в этом плане на возможности платформы.

Более развитые средства аудита имеются для 1С-Битрикс: Управление сайтом. Эта платформа имеет встроенный модуль «Проактивная защита», который в числе прочего обеспечивает аудит безопасности PHP-кода и ведение журнала вторжений. Имеются и дополнительные плагины, позволяющие, например, вести детальный журнал изменений контента.

Все системы enterprise-класса (IBM WebSphere Commerce, Oracle Commerce и SAP hybris) обеспечивают аудит безопасности во всех звеньях и на всех уровнях. Как правило, здесь инструменты аудита и дополнительные средства анализа являются частью базовой инфраструктуры (IBM, Oracle или VMWare), на которой развертываются приложения платформы. В отличие от систем «нижнего» класса, здесь, кроме простого ведения логов, аудит безопасности предусматривает использование специальных агентов (audit provider), которые передают события в отдельную подсистему аудита (audit framework). Сами данные аудита могут передаваться через дополнительные коннекторы в специальные сервисы хранения (базы данных) и анализа.