Безопасное подключение устаревшего промежуточного ПО SAP с помощью платформы Azure PaaS.

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

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

Обзор

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

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

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

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

Шлюз приложений Azure ориентирован на предоставление веб-приложений, поэтому он предлагает брандмауэр веб-приложений (WAF). Рабочие нагрузки в других виртуальных сетях, взаимодействующих с SAP через шлюз приложений 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, которые обычно используют обмен данными на основе HTTP (уровень 7 модели OSI). Интерфейсы нельзя обрабатывать одинаково из-за слоев, в которых они работают.

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

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

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

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

Сценарий: с фокусом на входящие HTTP-соединения

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

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

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

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

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

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

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

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

• Регулирование.
• Управление API.
• Другие параметры безопасности, такие как современные потоки проверки подлинности.
• Интеграция Microsoft Entra ID.
• Возможность добавлять API SAP в центральное решение API в компании.

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

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

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

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

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

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

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

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

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

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

Сценарий: конкретный для SAP RISE

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

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

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

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

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

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

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

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

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

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

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

• Регулирование запросов с помощью Управления API

• Ограничения одновременных запросов для веб-диспетчера SAP

• Взаимное TLS для проверки клиента и получателя

• WAF и повторное шифрование после завершения TLS

• Брандмауэр Azure для интеграции без HTTP

• Высокий уровень доступности и аварийное восстановление для рабочих нагрузок интеграции SAP на основе виртуальных машин

• Современные механизмы проверки подлинности, такие как OAuth2, где применимо

• Управляемое хранилище ключей, например Azure Key Vault для всех связанных учетных данных, сертификатов и ключей

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

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

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

Связанный контент

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

• Интегрируйте управление API во внутреннюю виртуальную сеть с помощью шлюза приложений

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

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

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

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