Изменить

Входящий и исходящий интернет-подключения для SAP в Azure

Виртуальные машины Azure
Виртуальная сеть Azure
Шлюз приложений Azure
Azure Load Balancer

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

Архитектура

Схема, на которой показано решение для взаимодействия с Интернетом для SAP в Azure.

Скачайте файл Visio архитектур в этой статье.

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

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

Аварийное восстановление (АВАРИЙНОе восстановление) не рассматривается в этой архитектуре. Для проектирования сети применяются те же принципы и дизайн, которые действительны для основных рабочих регионов. В структуре сети в зависимости от приложений, защищенных аварийного восстановления, рассмотрите возможность включения аварийного восстановления в другом регионе Azure. Дополнительные сведения см. в статье "Обзор аварийного восстановления" и рекомендации по инфраструктуре для рабочей нагрузки SAP

Рабочий процесс

  • Локальная сеть подключается к центральному концентратору через Azure ExpressRoute. Виртуальная сеть концентратора содержит подсеть шлюза, подсеть Брандмауэр Azure, подсеть общих служб и подсеть Шлюз приложений Azure.
  • Концентратор подключается к рабочей подписке SAP через пиринг виртуальной сети. Эта подписка содержит две периферийные виртуальные сети:
    • Виртуальная сеть периметра SAP содержит подсеть приложения периметра SAP.
    • Рабочая виртуальная сеть SAP содержит подсеть приложения и подсеть базы данных.
  • Подписка концентратора и рабочая подписка SAP подключаются к Интернету через общедоступные IP-адреса.

Компоненты

Подписки. Эта архитектура реализует подход целевой зоны Azure. Одна подписка Azure используется для каждой рабочей нагрузки. Одна или несколько подписок используются для центральных ИТ-служб, содержащих сетевой концентратор и центральные, общие службы, такие как брандмауэры или Active Directory и DNS. Другая подписка используется для рабочей нагрузки SAP. Используйте руководство по принятию решений в Cloud Adoption Framework для Azure, чтобы определить оптимальную стратегию подписки для вашего сценария.

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

Разделение на подсети по рабочей нагрузке упрощает использование групп безопасности сети (NSG) для задания правил безопасности для виртуальных машин приложений или служб Azure, развернутых.

Шлюз, избыточный между зонами. Шлюз подключает различные сети, расширяя локальную сеть к виртуальной сети Azure. Мы рекомендуем использовать ExpressRoute для создания частных подключений, которые не используют общедоступный Интернет. Вы также можете использовать подключение типа "сеть — сеть ". Вы можете развернуть ExpressRoute или VPN-шлюзы в зонах, чтобы избежать сбоев зоны. Сведения о различиях между зональным развертыванием и развертыванием, избыточным между зонами, см . в шлюзах виртуальной сети, избыточных между зонами. Для развертывания зоны шлюзов необходимо использовать IP-адреса SKU уровня "Стандартный".

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

Группы безопасности приложений. Чтобы определить детализированные политики безопасности сети в группах безопасности сети в группах безопасности сети на основе рабочих нагрузок, ориентированных на приложения, используйте группы безопасности приложений вместо явных IP-адресов. С помощью групп безопасности приложений можно группировать виртуальные машины по назначению, например SAP SID. Группы безопасности приложений помогают защитить приложения, фильтруя трафик из доверенных сегментов сети.

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

Шлюз приложений Azure. Шлюз приложений — это подсистема балансировки нагрузки веб-трафика. С его Брандмауэр веб-приложений функциональными возможностями это идеальная служба для предоставления веб-приложений Интернету с улучшенной безопасностью. Шлюз приложений может обслуживать общедоступные (Интернет) или частные клиенты или оба в зависимости от конфигурации.

В архитектуре Шлюз приложений с помощью общедоступного IP-адреса позволяет входящего подключения к ландшафту SAP по протоколу HTTPS. Серверный пул — это две или более виртуальных машин веб-диспетчера SAP, доступ к круговой перебору и обеспечение высокой доступности. Шлюз приложений — это обратный прокси-сервер и подсистема балансировки нагрузки веб-трафика, но она не заменяет веб-диспетчер SAP. Веб-диспетчер SAP обеспечивает интеграцию приложений с системами SAP и включает функции, которые Шлюз приложений сами по себе не предоставляют. Проверка подлинности клиента, когда она достигает систем SAP, выполняется на уровне приложений SAP в собственном коде или через единый вход. Если включить защиту от атак DDoS Azure, рекомендуется использовать номер SKU защиты сети DDoS, так как вы увидите скидки на Шлюз приложений Брандмауэр веб-приложений.

Для оптимальной производительности включите поддержку HTTP/2 для Шлюз приложений, sap Web Dispatcher и SAP NetWeaver.

Azure Load Balancer. Azure Load Balancer (цен. категория предоставляет сетевые элементы для разработки высокодоступных систем SAP. Для кластеризованных систем Load Balancer (цен. категория предоставляет виртуальный IP-адрес службы кластера, например экземпляры и базы данных ASCS/SCS, работающие на виртуальных машинах. Вы также можете использовать Load Balancer (цен. категория для предоставления IP-адреса для имени виртуального узла SAP некластикционных систем, если вторичные IP-адреса в сети Azure карта не являются вариантом. Использование Load Balancer (цен. категория вместо Шлюз приложений для устранения исходящего доступа к Интернету рассматривается далее в этой статье.

Проектирование сети

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

Сеть периметра для конкретного приложения (также известная как DMZ) содержит приложения, подключенные к Интернету, такие как SAProuter, SAP Cloud Подключение or, SAP Analytics Cloud Agent и другие. На схеме архитектуры сеть периметра называется периметром SAP — периферийной виртуальной сетью. Из-за зависимостей в системах SAP команда SAP обычно выполняет развертывание, настройку и управление этими службами. Именно поэтому эти службы периметра SAP часто не находятся в централизованной подписке и сети центра. Часто проблемы организации возникают из-за такого центрального центра размещения конкретных приложений или служб рабочей нагрузки.

Ниже приведены некоторые преимущества использования отдельной виртуальной сети периметра SAP:

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

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

Упрощенная архитектура

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

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

Скачайте файл Visio архитектур в этой статье.

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

Упрощенная архитектура использует шлюз NAT в подсети периметра SAP. Этот шлюз обеспечивает исходящее подключение для sap Cloud Подключение or и обновлений sap Analytics Cloud Agent и ОС для развернутых виртуальных машин. Так как SAProuter требует входящих и исходящих подключений, путь связи SAProuter проходит через брандмауэр, а не через шлюз NAT. Упрощенная архитектура также помещает Шлюз приложений с собственной назначенной подсетью в виртуальной сети периметра SAP в качестве альтернативного подхода к виртуальной сети концентратора.

Шлюз NAT — это служба, предоставляющая статические общедоступные IP-адреса для исходящего подключения. Шлюз NAT назначается подсети. Все исходящие связи используют IP-адреса шлюза NAT для доступа к Интернету. Входящие подключения не используют шлюз NAT. Такие приложения, как SAP Cloud Подключение or или службы обновления ОС виртуальной машины, которые обращаются к репозиториям в Интернете, могут использовать шлюз NAT вместо маршрутизации всего исходящего трафика через центральный брандмауэр. Часто определяемые пользователем правила реализуются во всех подсетях для принудительного подключения к Интернету трафика из всех виртуальных сетей через центральный брандмауэр.

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

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

Использование сетевых компонентов в ландшафте SAP

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

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

Службы, которые обычно служат системе SAP, лучше всего отделяются, как описано здесь:

  • Подсистемы балансировки нагрузки должны быть выделены отдельным службам. Политика компании определяет именование и группирование ресурсов. Рекомендуется использовать одну подсистему балансировки нагрузки для ASCS/SCS и ERS и другую для базы данных, разделенную для каждого идентификатора безопасности SAP. Кроме того, один подсистема балансировки нагрузки для кластеров SCS, ERS и СУБД одной системы SAP также хороша. Эта конфигурация помогает обеспечить, чтобы устранение неполадок не было сложным, при этом многие интерфейсные и внутренние пулы и правила балансировки нагрузки все в одном подсистеме балансировки нагрузки. Единый балансировщик нагрузки для безопасности SAP также гарантирует, что размещение в группах ресурсов соответствует другим компонентам инфраструктуры.
  • Шлюз приложений, например подсистема балансировки нагрузки, позволяет использовать несколько внутренних серверов, интерфейсных интерфейсов, параметров HTTP и правил. Решение об использовании одного шлюза приложений для нескольких используемых приложений более распространено здесь, так как не все системы SAP в среде требуют общедоступного доступа. Несколько вариантов использования в этом контексте включают разные порты веб-диспетчера для одной системы SAP S/4HANA или различных сред SAP. Рекомендуется по крайней мере один шлюз приложений для каждого уровня (рабочей, нерабочной и песочницы), если только сложность и количество подключенных систем становится слишком высоким.
  • Службы SAP, такие как SAProuter, Cloud Подключение or и Analytics Cloud Agent, развертываются на основе требований приложения либо централизованно, либо разделенных. Часто требуется разделение рабочих и непроизводственных приложений.

Размер и проектирование подсети

При проектировании подсетей для ландшафта SAP обязательно следуйте принципам размера и проектированию:

  • Для нескольких служб Платформы Azure как службы (PaaS) требуются собственные назначенные подсети.
  • Шлюз приложений рекомендует подсеть /24 для масштабирования. Если вы можете ограничить Шлюз приложений масштабировать меньшую подсеть, можно использовать по крайней мере /26 или больше. В одной подсети нельзя использовать обе версии Шлюз приложений (1 и 2).
  • Если вы используете Azure NetApp Files для общих папок NFS/S МБ или хранилища баз данных, требуется назначенная подсеть. По умолчанию используется подсеть /24. Используйте требования для определения правильного размера.
  • Если вы используете имена виртуальных узлов SAP, вам потребуется больше адресного пространства в подсетях SAP, включая периметр SAP.
  • Центральные службы, такие как Бастион Azure или Брандмауэр Azure, как правило, управляются центральной ИТ-командой, требуют собственных выделенных подсетей достаточного размера.

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

Службы SAP

SAProuter

Вы можете использовать SAProuter для предоставления третьим лицам, таким как поддержка SAP или ваши партнеры, для доступа к вашей системе SAP. SAProuter выполняется на одной виртуальной машине в Azure. Разрешения маршрута для использования SAProuter хранятся в неструктурированном файле с именем saprouttab. Записи saprouttab позволяют подключиться из любого порта TCP/IP к сетевому назначению за SAProuter, как правило, виртуальные машины системы SAP. Удаленный доступ по поддержке SAP зависит от SAProuter. Основная архитектура использует структуру, описанную ранее, с виртуальной машиной SAProuter, работающей в указанной виртуальной сети периметра SAP. Через пиринг между виртуальными сетями SAProuter затем взаимодействует с серверами SAP, работающими в собственной виртуальной сети и подсетях.

SAProuter — это туннель для SAP или партнеров. Эта архитектура описывает использование SAProuter с SNC для установления зашифрованного туннеля приложений (сетевого уровня 7) для SAP/партнеров. В настоящее время использование туннеля на основе IPSEC не рассматривается в этой архитектуре.

Следующие функции помогают защитить путь связи через Интернет:

  • Брандмауэр Azure или сторонней NVA предоставляет точку входа общедоступного IP-адреса в сети Azure. Правила брандмауэра ограничивают обмен данными только авторизованными IP-адресами. Для подключения к поддержке SAP обратите внимание на SAP 48243. Интеграция программного обеспечения SAProuter в среду брандмауэра документирует IP-адреса маршрутизаторов SAP.
  • Как и правила брандмауэра, правила безопасности сети разрешают обмен данными через порт SAProuter, обычно 3299 с назначенным назначением.
  • Вы поддерживаете правила разрешения и запрета SAProuter в файле saprouttab , указывая, кто может обратиться к SAProuter и к какой системе SAP можно получить доступ.
  • Дополнительные правила NSG применяются к соответствующим подсетям в рабочей подсети SAP, содержащей системы SAP.

Инструкции по настройке SAProuter с помощью Брандмауэр Azure см. в разделе конфигурации SAProuter с Брандмауэр Azure.

Вопросы безопасности SAProuter

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

Рекомендации по обеспечению высокого уровня доступности SAProuter

Так как SAProuter — это простой исполняемый файл с таблицей разрешений на основе файлов, его можно легко запустить. Приложение не имеет встроенной высокой доступности. При сбое виртуальной машины или приложения служба должна запуститься на другой виртуальной машине. Использование имени виртуального узла для службы SAProuter идеально подходит. Имя виртуального узла привязано к IP-адресу, который назначается в качестве дополнительной конфигурации IP-адресов с сетевым адаптером виртуальной машины или внутренней подсистемой балансировки нагрузки, подключенной к виртуальной машине. В этой конфигурации, если службе SAProuter необходимо переместить на другую виртуальную машину, можно удалить конфигурацию IP-адреса виртуального узла службы. Затем вы добавите имя виртуального узла на другой виртуальной машине, не изменяя таблицы маршрутов или конфигурацию брандмауэра. Все они настроены для использования виртуального IP-адреса. Дополнительные сведения см. в статье Об использовании имен виртуальных узлов SAP в Linux в Azure.

Каскадные SAProuters

Для реализации каскадных SAProuters можно определить как можно больше двух SAProuters для подключений поддержки SAP. Первый SAProuter, работающий в подсети приложения периметра SAP, предоставляет доступ из центрального брандмауэра и из SAP или партнера SAProuters. Единственными допустимыми назначениями являются другие SAProuters, работающие с определенными рабочими нагрузками. Каскадные saProuters могут использовать одноуровневые, для каждого региона или разделения идентификаторов безопасности в зависимости от архитектуры. Второй SAProuter принимает только внутренние подключения из первого SAProuter и предоставляет доступ к отдельным системам и виртуальным машинам SAP. Эта конструкция позволяет разделить доступ и управление между разными командами, если вам нужно. Пример каскадных SAProuters см. в разделе конфигурации SAProuter с Брандмауэр Azure.

SAP Fiori и WebGui

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

Для пользователей, обращающихся к имени общедоступного узла общедоступного IP-адреса, привязанного к Шлюз приложений, сеанс HTTPS завершается на Шлюз приложений. Внутренний пул двух или более виртуальных машин веб-диспетчера SAP получает сеансы циклического перебора из Шлюз приложений. Этот шлюз внутренних приложений трафика к веб-диспетчеру может быть HTTP или HTTPS в зависимости от требований. Брандмауэр веб-приложения помогает защитить веб-диспетчер SAP от атак, поступающих через Интернет с помощью набора основных правил OWASP. SAP NetWeaver, часто привязанный к идентификатору Microsoft Entra с помощью единого входа , выполняет проверку подлинности пользователей. Действия, необходимые для настройки единого входа для Fiori с помощью Шлюз приложений, см. в разделе Единый вход Конфигурация с помощью SAML и Идентификатора Microsoft Entra для общедоступных и внутренних URL-адресов.

Помните, что в любой ситуации необходимо защитить веб-диспетчер SAP. Даже если он открыт только внутри страны, открыт к Шлюз приложений через общедоступный IP-адрес или доступен через любые другие средства сети. Дополнительные сведения см. в разделе "Сведения о безопасности" для веб-диспетчера SAP.

Брандмауэр Azure и Шлюз приложений

Весь веб-трафик, предоставляемый Шлюз приложений, основан на ПРОТОКОЛе HTTPS и зашифрован с помощью предоставленного сертификата TLS. Вы можете использовать Брандмауэр Azure в качестве точки входа в корпоративную сеть через общедоступный IP-адрес, а затем направить трафик SAP Fiori из брандмауэра в Шлюз приложений через внутренний IP-адрес. Дополнительные сведения см. в Шлюз приложений после брандмауэра. Так как шифрование уровня TCP/IP уже выполняется через TLS, в этом сценарии существует ограниченное преимущество использования брандмауэра и невозможно выполнить проверку пакетов. Fiori взаимодействует через один и тот же внешний IP-адрес для входящего и исходящего трафика, который обычно не требуется для развертываний SAP Fiori.

Существует ряд преимуществ развертывания тандема Шлюз приложений и брандмауэра уровня 4.

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

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

Шлюз приложений для внутренних IP-адресов (необязательно)

Эта архитектура посвящена приложениям, подключенным к Интернету. Существуют различные варианты для клиентов, обращаюющихся к SAP Fiori, веб-интерфейсу системы SAP NetWeaver или другому интерфейсу SAP HTTPS через внутренний частный IP-адрес. Один из сценариев заключается в обращении всех пользователей к Fiori как к общедоступному ДОСТУПу через общедоступный IP-адрес. Другим вариантом является использование прямого сетевого доступа через частную сеть к веб-диспетчерам SAP, обходя Шлюз приложений полностью. Третий вариант — использовать частные и общедоступные IP-адреса в Шлюз приложений, предоставляя доступ как к Интернету, так и к частной сети.

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

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

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

Платформа бизнес-технологий SAP (BTP)

SAP BTP — это большой набор приложений SAP, SaaS или PaaS, которые обычно доступны через общедоступную конечную точку через Интернет. Sap Cloud Подключение or часто используется для обеспечения связи для приложений, работающих в частных сетях, таких как система SAP S/4HANA, запущенная в Azure. Sap Cloud Подключение or выполняется в качестве приложения на виртуальной машине. Для этого требуется исходящий доступ к Интернету для создания туннеля HTTPS с шифрованием TLS с помощью SAP BTP. Он выступает в качестве обратного вызова прокси-сервера между частным диапазоном IP-адресов в виртуальной сети и приложениями SAP BTP. Из-за этой обратной поддержки вызова нет необходимости открывать порты брандмауэра или другой доступ для входящих подключений, так как подключение из виртуальной сети исходящее.

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

  • Шлюз NAT, связанный с подсетью или подсистемой балансировки нагрузки, и его общедоступный IP-адрес.
  • Прокси-серверы HTTP, которые вы работаете.
  • Определяемый пользователем маршрут, который заставляет сетевой трафик передаваться в сетевую (модуль), например брандмауэр.

Схема архитектуры показывает наиболее распространенный сценарий: маршрутизация трафика, привязанного к Интернету, в виртуальную сеть концентратора и через центральный брандмауэр. Чтобы подключиться к учетной записи SAP BTP, необходимо настроить дополнительные параметры в SAP Cloud Подключение or.

Высокий уровень доступности для SAP Cloud Подключение or

Высокий уровень доступности встроен в SAP Cloud Подключение or. Cloud Подключение or устанавливается на двух виртуальных машинах. Основной экземпляр активен, и к нему подключен теневой экземпляр. Они совместно используют конфигурацию и хранятся в собственной синхронизации. Если основной экземпляр недоступен, вторичная виртуальная машина пытается взять на себя главную роль и повторно установить туннель TLS в SAP BTP. Среда с высоким уровнем доступности Cloud Подключение or показана в архитектуре. Для настройки не требуются другие технологии Azure, такие как подсистема балансировки нагрузки или программное обеспечение кластера. Дополнительные сведения о конфигурации и операции см. в документации по SAP.

Облачный агент SAP Analytics

В некоторых сценариях приложений sap Analytics Cloud Agent — это приложение, установленное на виртуальной машине. Он использует sap Cloud Подключение or для подключения SAP BTP. В этой архитектуре виртуальная машина SAP Analytics Cloud Agent выполняется в подсети приложения периметра SAP, а также виртуальные машины SAP Cloud Подключение or. Поток трафика из частных сетей, таких как виртуальная сеть Azure, в SAP BTP через sap Analytics Cloud Agent, см. в документации ПО SAP.

SAP предоставляет Приватный канал службу для SAP BTP. Он включает частные подключения между выбранными службами SAP BTP и выбранными службами в подписке Azure и виртуальной сети. При использовании службы Приватный канал обмен данными не направляется через общедоступный Интернет. Он остается в глобальной сети Azure с высокой безопасностью. Обмен данными со службами Azure осуществляется через частное адресное пространство. Улучшенная защита от кражи данных создается при использовании службы Приватный канал, так как частная конечная точка сопоставляет конкретную службу Azure с IP-адресом. Доступ ограничен сопоставленной службой Azure.

Для некоторых сценариев интеграции SAP BTP подход к службе Приватный канал предпочтителен. Для других пользователей sap Cloud Подключение or лучше. Сведения, которые помогут вам решить, какие варианты следует использовать, см. в разделе "Запуск облачных Подключение" и sap Приватный канал параллельно.

SAP RISE/ECS

Если SAP работает с системой SAP в контракте SAP RISE/ECS, SAP является партнером управляемой службы. Среда SAP развертывается SAP. На архитектуре SAP архитектура, показанная здесь, не применяется к системам, работающим в RISE с SAP/ECS. Сведения об интеграции этого типа ландшафта SAP с службами Azure и вашей сетью см. в документации по Azure.

Другие требования к обмену данными SAP

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

Для виртуальных машин, которые находятся за стандартной внутренней подсистемой балансировки нагрузки, например в кластеризованных средах, следует помнить, что Load Balancer (цен. категория изменяет поведение для общедоступного подключения. Дополнительные сведения см. в статье о подключении общедоступной конечной точки для виртуальных машин с помощью Azure Load Balancer (цен. категория в сценариях высокой доступности SAP.

Обновления операционной системы

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

Для операционных систем Linux вы можете получить доступ к следующим репозиториям, если вы получите лицензию ОС из Azure. Если вы приобретаете лицензии напрямую и переносите их в Azure (BYOS), обратитесь к поставщику ОС о способах подключения к репозиториям ОС и соответствующим диапазонам IP-адресов.

Управление кластерами высокого уровня доступности

Высокодоступные системы, такие как кластеризованные SAP ASCS/SCS или базы данных, могут использовать диспетчер кластеров с агентом ограждения Azure в качестве устройства STONITH. Эти системы зависят от достижения Azure Resource Manager. Resource Manager используется для запросов о состоянии ресурсов Azure и операций для остановки и запуска виртуальных машин. Так как Resource Manager — это общедоступная конечная точка, доступная в management.azure.com, подключение к виртуальной машине должно быть в состоянии связаться с ним. Эта архитектура использует центральный брандмауэр с определяемыми пользователем правилами маршрутизации трафика из виртуальных сетей SAP. Дополнительные сведения см. в предыдущих разделах.

Соавторы

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

Основные авторы:

Другие участник:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Сообщества

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

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