Поделиться через


Безопасное предоставление ПО промежуточного слоя SAP прежних версий с помощью Azure PaaS

Включение внутренних систем и внешних партнеров для взаимодействия с серверными концами SAP является общим требованием. Существующие ландшафты SAP часто полагаются на устаревшую по промежуточному слоям SAP Process Orchestration (PO) или Process Integration (PI) для их интеграции и преобразования. Для простоты в этой статье используется термин "Оркестрация процессов SAP" для обращения к обоим предложениям.

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

Примечание.

SAP упоминает SAP Integration Suite, в частности, SAP Cloud Integration Platform (BTP) в качестве преемника SAP PO и PI. В Azure доступны и платформа, и службы BTP. Дополнительные сведения см. в центре обнаружения SAP. Дополнительные сведения о временной шкале поддержки обслуживания для устаревших компонентов см. в 1648480 заметке SAP OSS.

Обзор

Существующие реализации на основе ПО промежуточного слоя SAP часто полагаются на собственную технологию диспетчеризации SAP, называемую веб-диспетчером SAP. Эта технология работает на уровне 7 модели OSI. Он выступает в качестве обратного прокси-сервера и устраняет потребности балансировки нагрузки для подчиненных рабочих нагрузок приложений SAP, таких как SAP Enterprise Resource Planning (ERP), ШЛЮЗ SAP или Оркестрация процессов SAP.

Подходы к отправке включают традиционные обратные прокси-серверы, такие как Apache, платформы как услуга (PaaS), такие как Azure Load Balancer, и мнение веб-диспетчера SAP. Общие понятия, описанные в этой статье, относятся к упомянутым вариантам. Рекомендации по использованию подсистем балансировки нагрузки, отличных от SAP, см. вики-сайте SAP.

Примечание.

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

Основные службы Azure

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

Шлюз приложений Azure ориентирован на предоставление веб-приложений, поэтому он предлагает брандмауэр веб-приложений (WAF). Рабочие нагрузки в других виртуальных сетях, которые будут взаимодействовать с SAP через Шлюз приложений Azure, могут быть подключены через частные каналы, даже между клиентами.

Схема, демонстрирующая взаимодействие между клиентами через Шлюз приложений Azure.

Брандмауэр Azure обрабатывает общедоступную и внутреннюю частную маршрутизацию для типов трафика на уровнях 4–7 модели OSI. Он предлагает фильтрацию и аналитику угроз, которая передается непосредственно из Microsoft Security.

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

Azure VPN-шлюз и Azure ExpressRoute служат точками входа в локальные сети. Они сокращены на схемах как VPN и XR.

Рекомендации по настройке

Архитектура интеграции отличается в зависимости от интерфейса, используемого организацией. Собственные технологии SAP, такие как платформа промежуточного документа (IDoc), интерфейс программирования бизнес-приложений (BAPI), вызовы удаленных функций транзакций (tRFCs) или обычные RFCs, требуют определенной среды выполнения. Они работают на уровнях 4–7 модели OSI, в отличие от современных API, которые обычно используют связь на основе HTP (уровень 7 модели OSI). Из-за этого интерфейсы не могут рассматриваться так же.

В этой статье рассматриваются современные API и HTTP, включая сценарии интеграции, такие как оператор применимости 2 (AS2). Протокол передачи файлов (FTP) служит примером для обработки потребностей интеграции, отличных от HTTP. Дополнительные сведения о решениях балансировки нагрузки Майкрософт см. в разделе "Параметры балансировки нагрузки".

Примечание.

SAP публикует выделенные соединители для своих собственных интерфейсов. Например, ознакомьтесь с документацией SAP по Java и .NET. Они также поддерживаются шлюзами Майкрософт. Имейте в виду, что IDocs также можно публиковать по протоколу HTTP.

Для решения проблем безопасности требуется использование брандмауэров для протоколов нижнего уровня и WAFs для решения трафика на основе HTTP с помощью TLS. Чтобы обеспечить эффективность, сеансы TLS должны быть завершены на уровне WAF. Для поддержки подходов нулевого доверия рекомендуется повторно зашифровать после этого, чтобы обеспечить сквозное шифрование.

Протоколы интеграции, такие как AS2, могут вызывать оповещения с помощью стандартных правил WAF. Мы рекомендуем использовать книгу Шлюз приложений триажа WAF, чтобы определить и лучше понять, почему правило активируется, чтобы обеспечить эффективное и безопасное исправление. Открытый проект безопасности веб-приложений (OWASP) предоставляет стандартные правила. Подробный видеосеанс по этой теме с акцентом на воздействие SAP Fiori см . в веб-трансляции SAP в Azure.

Вы можете повысить безопасность с помощью взаимной TLS (mTLS), которая также называется взаимной проверкой подлинности. В отличие от обычного ПРОТОКОЛА TLS, он проверяет удостоверение клиента.

Примечание.

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

Примечание.

Если вам не нужны функции балансировки с учетом SAP, предоставляемые веб-диспетчером SAP, их можно заменить на Azure Load Balancer. Эта замена дает преимущество управляемого предложения PaaS вместо инфраструктуры как услуги (IaaS).

Сценарий: ориентированное на входящий HTTP-подключение

Веб-диспетчер SAP не предлагает WAF. Из-за этого рекомендуется Шлюз приложений Azure для более безопасной настройки. Sap Web Dispatcher и Process Orchestration остаются ответственными за защиту серверной части SAP от перегрузки запросов с помощью рекомендаций по размеру и одновременных ограничений запросов. Возможности регулирования недоступны в рабочих нагрузках SAP.

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

Одним из сценариев взаимодействия с SAP Process Orchestration является входящий поток. Трафик может происходить из локальных, внешних приложений или пользователей или внутренней системы. В следующем примере основное внимание уделяется HTTPS.

Схема, на котором показан сценарий входящего HTTP с оркестрацией процессов SAP в Azure.

Сценарий: исходящее подключение HTTP/FTP

Для обратного направления обмена данными оркестрация процессов SAP может использовать маршрутизацию виртуальной сети для доступа к локальным рабочим нагрузкам или целевым объектам интернета через интернет-прорыв. Шлюз приложений Azure выступает в качестве обратного прокси-сервера в таких сценариях. Для обмена данными, отличных от HTTP, рекомендуется добавить Брандмауэр Azure. Дополнительные сведения см . в разделе "Сценарий: на основе файлов и сравнение компонентов шлюза " далее в этой статье.

В следующем сценарии исходящего трафика показаны два возможных метода. Один использует ПРОТОКОЛ HTTPS через Шлюз приложений Azure вызова веб-службы (например, адаптер SOAP). Другой использует FTP через SFTP (SFTP) через Брандмауэр Azure передачи файлов на сервер SFTP бизнес-партнера.

Схема, на которой показан сценарий исходящего трафика HTTP с SAP Process Orchestration в Azure.

Сценарий: фокус Управление API

По сравнению с сценариями для входящего и исходящего подключения, введение в Azure Управление API в внутреннем режиме (интеграция только с частным IP-адресом и виртуальной сетью) добавляет встроенные возможности, такие как:

Схема, на которой показан сценарий входящего трафика HTTP с Управлением API Azure и SAP Process Orchestration в Azure.

Если вам не нужен WAF, вы можете развернуть Azure Управление API во внешнем режиме с помощью общедоступного IP-адреса. Это развертывание упрощает настройку при сохранении возможностей регулирования и управления API. Базовая защита реализована для всех предложений PaaS Azure.

Схема, на которой показан сценарий входящего трафика HTTP с Управлением API Azure во внешнем режиме и SAP Process Orchestration.

Сценарий: глобальный охват

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

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

Схема, на которой показан сценарий глобального охвата с SAP Process Orchestration в Azure.

Сценарий: на основе файлов

Протоколы, отличные от HTTP, например FTP, не могут быть устранены с помощью Azure Управление API, Шлюз приложений или Azure Front Door, как показано в предыдущих сценариях. Вместо этого управляемый экземпляр Брандмауэр Azure или эквивалентный виртуальный сетевой модуль (NVA) берет на себя роль защиты входящих запросов.

Файлы должны храниться, прежде чем SAP сможет обработать их. Рекомендуется использовать SFTP. Хранилище BLOB-объектов Azure имеет встроенную поддержку SFTP.

Схема, на котором показан сценарий на основе файлов с Хранилище BLOB-объектов Azure и оркестрацией процессов SAP в Azure.

При необходимости альтернативные параметры SFTP доступны в Azure Marketplace.

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

Схема на которой показан сценарий на основе файлов с локальной общей папкой и внешней стороной, использующей SAP Process Orchestration в Azure.

Сведения о общих папках сетевой файловой системы (NFS) в качестве альтернативы хранилищу BLOB-объектов см. в Файлы Azure общих папок NFS.

Сценарий: SAP RISE, конкретный

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

На следующих схемах показаны две настройки в качестве примеров. Дополнительные сведения см. в справочном руководстве по SAP RISE.

Внимание

Обратитесь к SAP, чтобы убедиться, что порты связи для вашего сценария разрешены и открыты в группах безопасности сети.

Входящий трафик HTTP

В первой настройке клиент управляет уровнем интеграции, включая оркестрацию процессов SAP и полный путь входящего трафика. В подписке RISE выполняется только окончательный целевой объект SAP. Обмен данными с размещенной рабочей нагрузкой RISE настраивается через пиринг между виртуальными сетями, как правило, через концентратор. Потенциальная интеграция может быть размещена в веб-службе /sap/bc/idoc_xml SAP ERP внешним участником.

Схема, на которой показан сценарий входящего трафика HTTP с Управлением API Azure и локальным экземпляром SAP Process Orchestration в Azure в контексте RISE.

Во втором примере показана настройка, в которой SAP RISE выполняет всю цепочку интеграции, за исключением уровня Управление API.

Схема, на которой показан сценарий входящего трафика HTTP с Управлением API Azure и управляемым SAP экземпляром SAP Process Orchestration в Azure в контексте RISE.

Исходящий файл

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

Схема, на которой показан сценарий на основе общей папки с SAP Process Orchestration в Azure в контексте RISE.

Сравнение настроек шлюза

Примечание.

Метрики производительности и затрат предполагают уровни производственного уровня. Дополнительные сведения см. на странице калькулятора цен Azure. См. также следующие статьи: Брандмауэр Azure производительность, Шлюз приложений поддержку высокого трафика и емкость экземпляра Управление API Azure.

Таблица, которая сравнивает компоненты шлюза, рассмотренные в этой статье.

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

Общее правило интеграции

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

Альтернативы SAP Process Orchestration со службами Azure Integration Services

С помощью портфеля служб Azure Integration Services вы можете в собственном коде решать сценарии интеграции, охватывающие оркестрацию процессов SAP. Сведения о разработке шаблонов SAP IFlow с помощью облачных средств см . в этой серии блогов. В руководстве по соединителю содержатся дополнительные сведения об AS2 и EDIFACT.

Дополнительные сведения см. в соединителях Azure Logic Apps для нужных интерфейсов SAP.

Следующие шаги

Защита API с помощью Шлюз приложений и Управление API

Интеграция Управление API в внутреннюю виртуальную сеть с Шлюз приложений

Разверните книгу по Шлюз приложений waF для лучшего понимания оповещений WAF, связанных с SAP

Общие сведения о Шлюз приложений WAF для SAP

Понимание последствий объединения Брандмауэр Azure и Шлюз приложений Azure

Работа с API SAP OData в Управлении API Azure