편집

다음을 통해 공유

Azure의 SAP에 대한 인바운드 및 아웃바운드 인터넷 연결

Azure Virtual Machines
Azure Virtual Network
Azure Application Gateway
Azure Load Balancer

이 문서에서는 Azure 인프라의 SAP에 대한 인바운드 및 아웃바운드 인터넷 연결의 보안을 개선하기 위한 검증된 사례 집합을 제공합니다.

아키텍처

Azure의 SAP에 대한 인터넷 연결 통신 솔루션을 보여 주는 다이어그램

이 문서에서 아키텍처의 Visio 파일을 다운로드하세요.

이 솔루션은 일반적인 프로덕션 환경을 보여 줍니다. 요구 사항에 맞게 구성의 크기와 범위를 줄일 수 있습니다. 이러한 감소는 VM(가상 머신) 감소, 고가용성 없음 또는 개별 VM 대신 포함된 SAP Web Dispatcher와 같은 SAP 환경에 적용될 수 있습니다. 이 문서의 뒷부분에서 설명한 대로 네트워크 디자인의 대안에도 적용할 수 있습니다.

비즈니스 정책에 기반한 고객 요구 사항에는 아키텍처, 특히 네트워크 디자인에 대한 적응이 필요합니다. 가능한 경우 대안을 포함했습니다. 많은 솔루션이 실행 가능합니다. 비즈니스에 적합한 접근 방식을 선택하세요. Azure 리소스를 보호하면서도 성능이 뛰어난 솔루션을 제공하는 데 도움이 되어야 합니다.

DR(재해 복구)은 이 아키텍처에서 다루지 않습니다. 네트워크 디자인의 경우 기본 프로덕션 지역에 유효한 동일한 원칙과 디자인이 적용됩니다. 네트워크 디자인에서 DR로 보호되는 애플리케이션에 따라 다른 Azure 지역에서 DR을 사용하도록 설정하는 것이 좋습니다. 자세한 내용은 SAP 워크로드에 대한 재해 복구 개요 및 인프라 지침 문서를 참조하세요.

워크플로

  • 온-프레미스 네트워크는 Azure ExpressRoute를 통해 중앙 허브에 연결합니다. 허브 가상 네트워크에는 게이트웨이 서브넷, Azure Firewall 서브넷, 공유 서비스 서브넷 및 Azure 애플리케이션 게이트웨이 서브넷이 포함됩니다.
  • 허브는 가상 네트워크 피어링을 통해 SAP 프로덕션 구독에 연결합니다. 이 구독에는 다음 두 개의 스포크 가상 네트워크가 포함됩니다.
    • SAP 경계 가상 네트워크에는 SAP 경계 애플리케이션 서브넷이 포함되어 있습니다.
    • SAP 프로덕션 가상 네트워크에는 애플리케이션 서브넷과 데이터베이스 서브넷이 포함됩니다.
  • 허브 구독 및 SAP 프로덕션 구독은 공용 IP 주소를 통해 인터넷에 연결됩니다.

구성 요소

구독. 이 아키텍처는 Azure 랜딩 존 접근 방식을 구현합니다. 각 워크로드에 대해 하나의 Azure 구독이 사용됩니다. 하나 이상의 구독이 네트워크 허브 및 중앙, 방화벽 또는 Active Directory와 같은 공유 서비스, DNS를 포함하는 중앙 IT 서비스에 사용됩니다. SAP 프로덕션 워크로드에는 다른 구독이 사용됩니다. Azure용 클라우드 채택 프레임워크의 결정 가이드를 사용하여 시나리오에 가장 적합한 구독 전략을 결정합니다.

가상 네트워크. Azure Virtual Network 는 보안 강화를 통해 Azure 리소스를 서로 연결합니다. 이 아키텍처에서 가상 네트워크는 허브 스포크 토폴로지의 허브에 배포된 ExpressRoute 또는 VPN(가상 사설망) 게이트웨이를 통해 온-프레미스 환경에 연결합니다. SAP 프로덕션 환경에서는 자체 스포크 가상 네트워크를 사용합니다. 두 개의 고유한 스포크 가상 네트워크는 서로 다른 작업을 수행하며 서브넷은 네트워크 분리를 제공합니다.

워크로드를 통해 서브넷으로 분리하면 NSG(네트워크 보안 그룹)를 사용하여 배포된 애플리케이션 VM 또는 Azure 서비스에 대한 보안 규칙을 쉽게 설정할 수 있습니다.

영역 중복 게이트웨이. 게이트웨이는 고유한 네트워크를 연결하여 온-프레미스 네트워크를 Azure 가상 머신으로 확장합니다. ExpressRoute를 사용하여 퍼블릭 인터넷을 사용하지 않는 프라이빗 연결을 만드는 것이 좋습니다. 사이트 간 연결을 사용할 수도 있습니다. 영역 중복 Azure ExpressRoute 또는 VPN Gateway를 사용하여 영역 오류를 방지합니다. 영역 배포와 영역 중복 배포 간의 차이점을 설명하려면 영역 중복 가상 네트워크 게이트웨이를 참조하세요. 게이트웨이의 영역 배포의 경우 표준 SKU IP 주소를 사용해야 합니다.

NSG 가상 네트워크와 주고받는 네트워크 트래픽을 제한하려면 NSG를 만들고 이를 특정 서브넷에 할당합니다. 워크로드별 NSG를 사용하여 개별 서브넷의 보안을 제공합니다.

애플리케이션 보안 그룹. 애플리케이션을 중심으로 하는 워크로드를 기반으로 NSG에서 세분화된 네트워크 보안 정책을 정의하기 위해 명시적 IP 주소 대신 애플리케이션 보안 그룹을 사용할 수 있습니다. 애플리케이션 보안 그룹을 사용하여 목적별로 VM을 그룹화할 수 있습니다(예: SAP SID). 애플리케이션 보안 그룹은 네트워크의 신뢰할 수 있는 세그먼트에서 트래픽을 필터링하여 애플리케이션을 보호하는 데 도움이 됩니다.

프라이빗 엔드포인트 많은 Azure 서비스는 인터넷을 통해 액세스할 수 있도록 설계되어 퍼블릭 서비스로 작동됩니다. 개인 네트워크 범위를 통해 프라이빗 액세스를 허용하기 위해 일부 서비스에 프라이빗 엔드포인트를 사용할 수 있습니다. 프라이빗 엔드포인트는 가상 네트워크의 네트워크 인터페이스입니다. 개인 네트워크 공간으로 서비스를 효과적으로 가져옵니다.

Azure 애플리케이션 게이트웨이. Application Gateway는 웹 트래픽 부하 분산 장치입니다. Web Application Firewall 기능을 사용하여 향상된 보안으로 웹 애플리케이션을 인터넷에 노출시키는 이상적인 서비스입니다. Application Gateway는 구성에 따라 퍼블릭(인터넷)이나 프라이빗 클라이언트 또는 둘 다 모두 서비스할 수 있습니다.

아키텍처에서 Application Gateway는 공용 IP 주소를 사용하여 HTTPS를 통해 SAP 환경에 대한 인바운드 연결을 허용합니다. 백 엔드 풀은 둘 이상의 SAP Web Dispatcher VM이며 라운드 로빈에 액세스하여 고가용성을 제공합니다. 애플리케이션 게이트웨이는 역방향 프록시 및 웹 트래픽 부하 분산 장치이지만 SAP Web Dispatcher를 대체하지는 않습니다. SAP Web Dispatcher는 SAP 시스템과 애플리케이션 통합을 제공하며 Application Gateway 자체에서 제공하지 않는 기능을 포함합니다. 클라이언트 인증은 SAP 시스템에 도달할 때 SAP 애플리케이션 계층에서 기본적으로 수행하거나 또는 Single Sign-On을 통해 수행됩니다. Azure DDoS 보호를 사용하도록 설정하면 Application Gateway 웹 애플리케이션 방화벽에 대한 할인이 표시되므로 DDoS 네트워크 보호 SKU를 사용하는 것이 좋습니다.

최적의 성능을 위해 Application Gateway, SAP Web Dispatcher, SAP NetWeave의 HTTP/2 지원을 사용하도록 설정합니다.

Azure Load Balancer. Azure 표준 Load Balancer는 SAP 시스템의 고가용성 설계를 위한 네트워킹 요소를 제공합니다. 클러스터형 시스템의 경우 표준 Load Balancer는 VM에서 실행되는 ASCS/SCS 인스턴스 및 데이터베이스와 같은 클러스터 서비스의 가상 IP 주소를 제공합니다. 또한 Azure 네트워크 카드의 보조 IP가 옵션이 아닌 경우 표준 Load Balancer를 사용하여 비클러스트 시스템의 가상 SAP 호스트 이름에 대한 IP 주소를 제공할 수도 있습니다. Application Gateway 대신 표준 Load Balancer를 사용하여 아웃바운드 인터넷 액세스를 해결하는 방법은 이 문서의 뒷부분에서 다뤄집니다.

네트워크 설계

아키텍처는 두 개의 개별 가상 네트워크, 즉 중앙 허브 가상 네트워크에 피어링된 두 스포크 가상 네트워크를 사용합니다. 스포크 대 스포크 피어링이 없습니다. 통신이 허브를 통과하는 스타 토폴로지를 사용합니다. 네트워크를 분리하면 애플리케이션을 위반으로부터 보호하는 데 도움이 됩니다.

애플리케이션별 경계 네트워크(DMZ라고도 함)에는 SAProuter, SAP Cloud Connector, SAP Analytics Cloud Agent 등과 같은 인터넷 연결 애플리케이션이 포함되어 있습니다. 아키텍처 다이어그램에서 경계 네트워크의 이름은 SAP perimeter - 스포크 가상 네트워크입니다. SAP 시스템의 종속성 때문에 SAP 팀은 일반적으로 이러한 서비스의 배포, 구성, 관리를 수행합니다. 따라서 이러한 SAP 경계 서비스는 중앙 허브 구독 및 네트워크에 자주 위치하지 않습니다. 종종 조직의 문제는 워크로드별 애플리케이션 또는 서비스의 중앙 허브 배치로 인해 발생합니다.

다음은 별도의 SAP 경계 가상 네트워크를 사용하면 얻을 수 있는 몇 가지 이점입니다.

  • 위반이 감지된 경우 손상된 서비스를 신속하고 즉각적으로 격리합니다. SAP 경계에서 허브로의 가상 네트워크 피어링을 제거하면 SAP 경계 워크로드 및 SAP 애플리케이션 가상 네트워크 애플리케이션을 인터넷에서 즉시 격리할 수 있습니다. 액세스를 허용하는 NSG 규칙을 변경하거나 제거하면 새 연결에만 영향을 미치며 기존 연결은 끊어지지 않습니다.
  • SAP 경계 네트워크 및 SAP 애플리케이션 네트워크 내/외부의 통신 파트너에 대한 엄격한 잠금을 통해 가상 네트워크 및 서브넷에 대한 보다 엄격한 제어가 가능하며 기존 연결을 끊지 않습니다. SAP 경계 애플리케이션에 대한 다양한 권한 부여 백 엔드, 권한 있는 액세스 또는 로그인 자격 증명을 사용하여 SAP 경계 애플리케이션의 권한 있는 사용자 및 액세스 메서드로 향상된 제어를 확장할 수 있습니다.

단점은 인터넷 바인딩 SAP 트래픽의 복잡성 증가 및 추가 가상 네트워크 피어링 비용입니다(통신이 가상 네트워크 피어링을 두 번 통과해야 하기 때문). 스포크-허브-스포크 피어링 트래픽에 대한 대기 시간 영향은 설치되어 있는 방화벽에 따라 다르며 측정되어야 합니다.

단순화된 아키텍처

이 문서에 있는 권장 사항을 단점을 제한하여 처리하기 위해 경계 및 SAP 애플리케이션 모두에 단일 스포크 가상 네트워크를 사용할 수 있습니다. 다음 아키텍처에는 단일 SAP 프로덕션 가상 네트워크의 모든 서브넷이 포함되어 있습니다. 손상된 경우 SAP 경계에 대한 가상 네트워크 피어링을 종료하여 즉시 격리할 수 있는 이점은 사용할 수 없습니다. 이 시나리오에서 NSG에 대한 변경 내용은 새 연결에만 영향을 줍니다.

Azure에서 SAP의 인터넷 연결 통신을 위한 단순화된 아키텍처를 보여 주는 다이어그램

이 문서에서 아키텍처의 Visio 파일을 다운로드하세요.

크기 및 범위가 더 작은 배포의 경우 단순화된 아키텍처가 더 적합할 수 있으며 더 복잡한 아키텍처의 원칙을 계속 준수하고 있습니다. 이 문서에서는 달리 명시되지 않는 한 더 복잡한 아키텍처를 참조합니다.

단순화된 아키텍처는 SAP 경계 서브넷에서 NAT 게이트웨이를 사용합니다. 이 게이트웨이는 SAP Cloud Connector와 SAP Analytics Cloud Agent의 아웃바운드 연결 및 배포된 VM에 대한 OS 업데이트를 제공합니다. SAProuter에는 들어오는 연결과 아웃바운드 연결이 모두 필요하므로 SAProuter 통신 경로는 NAT 게이트웨이를 사용하는 대신 방화벽을 통과합니다. 간소화된 아키텍처는 허브 가상 네트워크에 대한 대안으로 SAP 경계 가상 네트워크에 자체 지정된 서브넷이 있는 Application Gateway를 배치합니다.

NAT 게이트웨이는 아웃바운드 연결을 위해 고정 공용 IP 주소를 제공하는 서비스입니다. NAT 게이트웨이는 서브넷에 할당됩니다. 모든 아웃바운드 통신은 인터넷 액세스를 위해 NAT 게이트웨이의 IP 주소를 사용합니다. 인바운드 연결은 NAT 게이트웨이를 사용하지 않습니다. SAP Cloud Connector와 같은 애플리케이션 또는 인터넷의 리포지토리에 액세스하는 VM OS 업데이트 서비스는 중앙 방화벽을 통해 모든 아웃바운드 트래픽을 라우팅하는 대신 NAT 게이트웨이를 사용할 수 있습니다. 사용자 정의 규칙은 모든 서브넷에서 구현되어 중앙 방화벽을 통해 모든 가상 네트워크에서 인터넷 바인딩된 트래픽을 강제로 적용하는 경우가 많습니다.

요구 사항에 따라 아웃바운드 연결을 위해 중앙 방화벽 대신 NAT 게이트웨이를 사용할 수 있습니다. 이렇게 하면 NSG에서 허용하는 퍼블릭 엔드포인트와 통신하는 동안 중앙 방화벽의 부하를 줄일 수 있습니다. NAT 게이트웨이의 설정된 IP 목록에서 대상 방화벽 규칙을 구성할 수 있으므로 아웃바운드 IP도 제어할 수 있습니다. 예를 들면 퍼블릭 서비스, OS 패치 리포지토리 또는 타사 인터페이스에서 사용되는 Azure 퍼블릭 엔드포인트에 도달하는 경우입니다.

고가용성 구성의 경우 NAT 게이트웨이는 단일 영역에만 배포되며 현재 영역 간 중복되지 않습니다. 단일 NAT 게이트웨이를 사용하는 경우 가상 머신에 영역 중복(영역 간) 배포를 사용하는 SAP 배포에는 적합하지 않습니다.

SAP 환경에서 네트워크 구성 요소 사용

아키텍처 문서에는 일반적으로 하나의 SAP 시스템 또는 환경만 표시됩니다. 이는 보다 쉽게 이해할 수 있도록 합니다. 그 결과 아키텍처가 여러 시스템 트랙과 계층을 포함하는 대규모 SAP 환경에 어떻게 적합한지에 대한 더 큰 그림이 다루어지지 않는 경우가 많아집니다.

방화벽, NAT 게이트웨이, 프록시 서버(배포된 경우)와 같은 중앙 네트워킹 서비스는 프로덕션, 사전 프로덕션, 개발, 샌드박스 등 모든 계층의 전체 SAP 환경에서 가장 잘 사용됩니다. 요구 사항, 조직의 규모, 비즈니스 정책에 따라 계층당 별도의 구현 또는 하나의 프로덕션과 하나의 샌드박스/테스트 환경을 고려할 수 있습니다.

일반적으로 SAP 시스템을 제공하는 서비스는 여기에 설명된 대로 분리하는 것이 가장 좋습니다.

  • 부하 분산 장치는 개별 서비스 전용이어야 합니다. 회사 정책에 따라 리소스의 명명 및 그룹화가 결정됩니다. ASCS/SCS 및 ERS용 부하 분산 장치 하나를 사용하고 각 SAP SID의 분리된 데이터베이스용 다른 부하 분산 장치를 사용하는 것이 좋습니다. 또는 하나의 SAP 시스템의 (A)SCS, ERS, DB 클러스터 모두를 위한 단일 부하 분산 장치도 좋은 설계입니다. 이 구성을 사용하면 단일 부하 분산 장치에 많은 프런트 엔드/백 엔드 풀 및 부하 분산 규칙이 포함되어 문제 해결이 복잡해지지 않습니다. 또한 SAP SID당 단일 부하 분산 장치를 사용하면 리소스 그룹의 배치가 다른 인프라 구성 요소의 배치와 일치하게 됩니다.
  • Application Gateway는 부하 분산 장치와 마찬가지로 여러 백 엔드, 프런트 엔드, HTTP 설정, 규칙을 허용합니다. 환경의 모든 SAP 시스템에 공용 액세스가 필요한 것은 아니므로 하나의 애플리케이션 게이트웨이를 여러 용도를 위해 사용하기로 결정하는 것이 더 일반적입니다. 이 컨텍스트에서 여러 용도로 사용되는 경우 동일한 SAP S/4HANA 시스템 또는 다른 SAP 환경에 대한 서로 다른 웹 디스패처 포트가 포함됩니다. 연결된 시스템의 복잡성과 수가 너무 높게 되지 않은 한 계층(프로덕션, 비프로덕션, 샌드박스)당 하나 이상의 애플리케이션 게이트웨이를 권장합니다.
  • SAProuter, Cloud Connector, Analytics Cloud Agent와 같은 SAP 서비스는 애플리케이션 요구 사항에 따라 집중적으로 또는 분할로 배포됩니다. 프로덕션 및 비프로덕션 분리가 필요한 경우가 많습니다.

서브넷 크기 조정 및 디자인

SAP 환경의 서브넷을 디자인할 때는 크기 조정 및 디자인 원칙을 따라야 합니다.

  • 여러 Azure PaaS(Platform as a Service) 서비스에는 자체 지정된 서브넷이 필요합니다.
  • Application Gateway는 크기 조정을 위해 /24 서브넷을 권장합니다. Application Gateway 크기를 제한하도록 선택하는 경우 최소 /26 이상에서 더 작은 서브넷을 사용할 수 있습니다. 동일한 서브넷에서 두 버전의 Application Gateway(1 및 2)를 모두 사용할 수 없습니다.
  • NFS/SMB 공유 또는 데이터베이스 스토리지에 Azure NetApp Files를 사용하는 경우 지정된 서브넷이 필요합니다. /24 서브넷이 기본값입니다. 요구 사항을 사용하여 적절한 크기 조정을 결정합니다.
  • SAP 가상 호스트 이름을 사용하는 경우 SAP 경계를 포함하여 SAP 서브넷에 더 많은 주소 공간이 필요합니다.
  • 일반적으로 중앙 IT 팀에서 관리하는 Azure Bastion 또는 Azure Firewall과 같은 중앙 서비스에는 충분한 크기의 자체 전용 서브넷이 필요합니다.

SAP 데이터베이스 및 애플리케이션에 전용 서브넷을 사용하면 NSG를 더 엄격하게 설정하여 두 애플리케이션 유형을 고유한 규칙 집합으로 보호할 수 있습니다. 그런 다음 세분화된 제어를 위해 애플리케이션 보안 그룹에 의존하지 않고도 SAP 애플리케이션에 대한 데이터베이스 액세스를 보다 쉽게 제한할 수 있습니다. 또한 SAP 애플리케이션과 데이터베이스 서브넷을 분리하면 NSG에서 보안 규칙을 더 쉽게 관리할 수 있습니다.

SAP 서비스

SAProuter

SAProuter를 사용하여 SAP 지원과 같은 타사 또는 파트너가 SAP 시스템에 액세스할 수 있도록 할 수 있습니다. SAProuter는 Azure의 한 VM에서 실행됩니다. SAProuter를 사용하기 위한 경로 권한은 saprouttab이라는 플랫 파일에 저장됩니다. saprouttab 항목을 사용하면 모든 TCP/IP 포트에서 SAProuter 뒤에 있는 네트워크 대상(일반적으로 SAP 시스템 VM)에 연결할 수 있습니다. SAP 지원을 통한 원격 액세스는 SAProuter를 사용합니다. 주된 아키텍처는 지정된 SAP 경계 가상 네트워크 내에서 실행되는 SAProuter VM과 함께 앞에서 설명한 디자인을 사용합니다. 그런 다음 SAProuter는 가상 네트워크 피어링을 통해 자체 스포크 가상 네트워크 및 서브넷에서 실행되는 SAP 서버와 통신합니다.

SAProuter는 SAP 또는 파트너에게 연결되는 터널입니다. 이 아키텍처에서는 SNC 사용과 함께 SAProuter를 사용하여 SAP/파트너에게 암호화된 애플리케이션 터널(네트워크 계층 7)을 설정하는 방법을 설명합니다. IPSEC 기반 터널의 사용은 현재 이 아키텍처에서 다루지 않습니다.

다음 기능은 인터넷을 통한 통신 경로를 보호하는 데 도움이 됩니다.

  • Azure Firewall 또는 타사 NVA는 Azure 네트워크에 공용 IP 진입점을 제공합니다. 방화벽 규칙은 권한 있는 IP 주소로만 통신을 제한합니다. SAP 지원에 대한 연결의 경우 SAP 노트 48243 - SAProuter 소프트웨어를 방화벽 환경에 통합은 SAP 라우터의 IP 주소를 문서화합니다.
  • 방화벽 규칙과 마찬가지로 네트워크 보안 규칙은 SAProuter의 포트(일반적으로 3299)에서 지정된 대상과 통신할 수 있도록 허용합니다.
  • SAProuter에 연결할 수 있는 사용자와 액세스할 수 있는 SAP 시스템을 지정하여 saprouttab 파일에서 SAProuter 허용/거부 규칙을 유지 관리합니다.
  • 추가 NSG 규칙은 SAP 시스템을 포함하는 SAP 프로덕션 서브넷의 각 서브넷에 적용됩니다.

Azure Firewall을 사용하여 SAProuter를 구성하는 단계는 Azure Firewall을 사용하여 SAProuter 구성을 참조하세요.

SAProuter 보안 고려 사항

SAProuter는 SAP 시스템과 동일한 애플리케이션 서브넷에서 작동하지 않으므로 OS의 로그인 메커니즘이 다를 수 있습니다. 정책에 따라 별도의 로그온 도메인 또는 호스트 전용 사용자 자격 증명을 SAProuter에 사용할 수 있습니다. 보안 위반이 발생하면 자격 증명 기반이 다르기 때문에 내부 SAP 시스템에 연속적으로 액세스할 수 없습니다. 앞에서 설명한 대로 이러한 경우 네트워크 분리는 손상된 SAProuter에서 애플리케이션 서브넷으로 추가 액세스를 분리할 수 있습니다. SAP 경계 가상 네트워크 피어링의 연결을 끊어서 이 격리를 수행할 수 있습니다.

SAProuter 고가용성 고려 사항

SAProuter는 파일 기반 경로 권한 테이블이 있는 간단한 실행 파일이므로 쉽게 시작할 수 있습니다. 애플리케이션에는 기본 제공 고가용성이 없습니다. VM 또는 애플리케이션 오류가 있는 경우 다른 VM에서 서비스를 시작해야 합니다. SAProuter 서비스에 가상 호스트 이름을 사용하는 것이 좋습니다. 가상 호스트 이름은 VM의 NIC를 사용하여 보조 IP 구성으로 할당되거나 또는 VM에 연결된 내부 부하 분산 장치에 할당되는 IP에 바인딩됩니다. 이 구성에서 SAProuter 서비스를 다른 VM으로 이동해야 하는 경우 서비스 가상 호스트 이름의 IP 구성을 제거할 수 있습니다. 그런 다음 경로 테이블 또는 방화벽 구성을 변경할 필요 없이 다른 VM에 가상 호스트 이름을 추가합니다. 모두 가상 IP 주소를 사용하도록 구성됩니다. 자세한 내용은 Azure에서 Linux와 함께 SAP 가상 호스트 이름 사용을 참조하세요.

연계 SAProuters

연계 SAProuters를 구현하려면 SAP 지원 연결을 위해 최대 두 개의 SAProuter를 정의할 수 있습니다. SAP 경계 애플리케이션 서브넷에서 실행되는 첫 번째 SAProuter는 중앙 방화벽과 SAP 또는 파트너 SAProuters에서 액세스를 제공합니다. 유일하게 허용되는 대상은 특정 워크로드로 실행되는 다른 SAProuters뿐입니다. 연계 SAProuters는 아키텍처에 따라 계층별, 지역별 또는 SID별 분리를 사용할 수 있습니다. 두 번째 SAProuter는 첫 번째 SAProuter의 내부 연결만 허용하고 개별 SAP 시스템 및 VM에 대한 액세스를 제공합니다. 이 디자인을 사용하면 필요한 경우 서로 다른 팀 간에 액세스 및 관리를 구분할 수 있습니다. 연계 SAProuters의 예제는 Azure Firewall을 사용한 SAProuter 구성을 참조하세요.

SAP Fiori 및 WebGui

SAP Fiori 및 SAP 애플리케이션용 기타 HTTPS 프런트 엔드는 내부 회사 네트워크의 외부에서 사용되는 경우가 많습니다. 인터넷에서 사용할 수 있어야 하기 때문에 SAP 애플리케이션을 보호하는 데 도움이 되는 높은 보안 솔루션이 필요합니다. Web Application Firewall이 포함된 Application Gateway는 이러한 목적을 위한 이상적인 서비스입니다.

Application Gateway에 연결된 공용 IP의 공용 호스트 이름에 액세스하는 사용자 및 애플리케이션의 경우 APPLICATION Gateway에서 HTTPS 세션이 종료됩니다. 두 개 이상의 SAP Web Dispatcher VM으로 구성된 백 엔드 풀은 Application Gateway에서 라운드 로빈 세션을 가져옵니다. Web Dispatcher에 대한 이 내부 트래픽 애플리케이션 게이트웨이는 요구 사항에 따라 HTTP 또는 HTTPS가 될 수 있습니다. Application Gateway와 Web Dispatcher VM 간의 HTTPS를 사용하면 SAP 팀에 잘 알려진 인증서 및 인증서 체인을 주기적인 인증서 회전에 사용합니다. 웹 애플리케이션 방화벽은 OWASP 핵심 규칙 집합을 사용하여 인터넷을 통해 오는 공격으로부터 SAP Web Dispatcher를 보호하는 데 도움이 됩니다. SSO(Single Sign-On)를 통해 Microsoft Entra ID에 연결된 SAP NetWeaver는 사용자 인증을 수행합니다. Application Gateway를 사용하여 Fiori용 SSO를 구성하는 데 필요한 단계는 공용 및 내부 URL에 SAML 및 Microsoft Entra ID를 사용하는 Single Sign-On 구성을 참조 하세요.

내부적으로만 열려 있거나, 공용 IP를 통해 Application Gateway를 통해 액세스하거나, 다른 네트워크 수단을 통해 액세스할 수 있는 경우에도 어떤 상황에서도 SAP Web Dispatcher를 보호해야 합니다. 자세한 내용은 SAP Web Dispatcher의 보안 정보를 참조하세요.

Azure Firewall 및 Application Gateway

Application Gateway에서 제공하는 모든 웹 트래픽은 HTTPS 기반이며 제공된 TLS 인증서로 암호화됩니다. 공용 IP를 통해 Azure Firewall을 회사 네트워크의 진입점으로 사용한 다음 방화벽에서 내부 IP 주소를 통해 SAP Fiori 트래픽을 Application Gateway로 라우팅할 수 있습니다. 자세한 내용은 방화벽 이후의 Application Gateway를 참조하세요. TCP/IP 계층-7 암호화는 TLS를 통해 이미 적용되어 있으므로 이 시나리오에서 방화벽을 사용하는 이점이 제한적일 수 있으며 패킷 검사를 수행할 수 없습니다. Fiori는 일반적으로 SAP Fiori 배포에 필요하지 않은 인바운드 및 아웃바운드 트래픽 모두에 동일한 외부 IP 주소를 통해 통신합니다.

탠덤 Application Gateway 및 계층 4 방화벽 배포에는 몇 가지 이점이 있습니다.

  • 엔터프라이즈 차원의 보안 정책 관리와 통합할 수 있습니다.
  • 보안 규칙을 위반하는 네트워크 트래픽은 이미 삭제되었으므로 검사가 필요하지 않습니다.

이 결합된 배포는 좋은 아키텍처입니다. 인바운드 인터넷 트래픽을 처리하는 방법은 전체 엔터프라이즈 아키텍처에 따라 다릅니다. 또한 전체 네트워크 아키텍처가 온-프레미스 클라이언트와 같은 내부 IP 주소 공간의 액세스 방법에 어떻게 적합한지 고려해야 합니다. 이 고려 사항은 다음 섹션에서 다룹니다.

내부 IP 주소를 위한 Application Gateway(선택 사항)

이 아키텍처는 인터넷 연결 애플리케이션에 중점을 둡니다. SAP Fiori, SAP NetWeaver 시스템의 웹 UI 또는 내부 개인 IP 주소를 통해 다른 SAP HTTPS 인터페이스에 액세스하는 클라이언트에 사용할 수 있는 다양한 옵션이 있습니다. 한 가지 시나리오는 공용 IP를 통해 Fiori에 대한 모든 액세스를 공용 액세스로 처리하는 것입니다. 또 다른 옵션은 개인 네트워크를 통해 SAP Web Dispatchers에 대한 직접 네트워크 액세스를 사용하여 Application Gateway를 완전히 우회하는 것입니다. 세 번째 옵션은 Application Gateway에서 개인 및 공용 IP 주소를 모두 사용하여 인터넷과 개인 네트워크에 대한 액세스를 제공하는 것입니다.

SAP 환경에 대한 개인 전용 네트워크 액세스를 위해 Application Gateway에서 개인 IP 주소와 유사한 구성을 사용할 수 있습니다. 이 경우 공용 IP 주소는 관리 목적으로만 사용되며 연결된 수신기가 없습니다.

Application Gateway를 사용하는 대신 내부적으로 부하 분산 장치를 사용할 수 있습니다. 라운드 로빈 백 엔드로 구성된 Web Dispatcher VM에서 표준 내부 부하 분산 장치를 사용할 수 있습니다. 이 시나리오에서 표준 부하 분산 장치는 SAP 프로덕션 애플리케이션 서브넷의 Web Dispatcher VM과 함께 배치되며 Web Dispatcher VM 간에 활성/활성 부하 분산을 제공합니다.

인터넷 연결 배포의 경우 공용 IP가 있는 부하 분산 장치 대신 Web Application Firewall이 있는 Application Gateway를 사용하는 것이 좋습니다.

SAP BTP(Business Technology Platform)

SAP BTP는 일반적으로 인터넷으로 퍼블릭 엔드포인트를 통해 액세스되는 SAP 애플리케이션, SaaS 또는 PaaS의 대규모 집합입니다. SAP Cloud Connector는 Azure에서 실행되는 SAP S/4HANA 시스템과 같은 개인 네트워크에서 실행되는 애플리케이션을 위한 통신을 제공하는 데 자주 사용됩니다. SAP Cloud Connector는 VM에서 애플리케이션으로 실행됩니다. SAP BTP를 사용하여 TLS 암호화 HTTPS 터널을 설정하려면 아웃바운드 인터넷 액세스가 필요합니다. 가상 네트워크의 개인 IP 범위와 SAP BTP 애플리케이션 간의 역방향 호출 프록시 역할을 합니다. 이 역방향 호출 지원으로 인해 가상 네트워크의 연결이 아웃바운드이기 때문에 인바운드 연결에 대한 개방형 방화벽 포트 또는 기타 액세스가 필요하지 않습니다.

기본적으로 VM은 Azure에서 아웃바운드 인터넷에 액세스할 수 있습니다. 가상 머신과 연결된 전용 공용 IP 주소가 없는 경우 아웃바운드 트래픽에 사용되는 공용 IP 주소는 특정 Azure 지역의 공용 IP 풀에서 임의로 선택됩니다. 제어할 수 없습니다. 제어되고 식별 가능한 서비스 및 IP 주소를 통해 아웃바운드 연결이 설정되도록 하기 위해 다음 방법 중 하나를 사용할 수 있습니다.

  • 서브넷 또는 부하 분산 장치 및 공용 IP 주소와 연결된 NAT 게이트웨이입니다.
  • 작동하는 HTTP 프록시 서버입니다.
  • 네트워크 트래픽이 방화벽과 같은 네트워크 어플라이언스로 이동하도록 하는 사용자 정의 경로입니다.

아키텍처 다이어그램은 인터넷 바인딩된 트래픽을 허브 가상 네트워크 및 중앙 방화벽을 통해 라우팅하는 가장 일반적인 시나리오를 보여 줍니다. SAP BTP 계정에 연결하려면 SAP Cloud Connector에서 추가 설정을 구성해야 합니다.

SAP Cloud Connector의 고가용성

고가용성이 SAP Cloud Connector에 기본 제공됩니다. 클라우드 커넥터는 두 개의 VM에 설치됩니다. 기본 인스턴스가 활성 상태이고 섀도 인스턴스가 연결되어 있습니다. 구성을 공유하고 기본적으로 동기화된 상태를 유지합니다. 주 인스턴스를 사용할 수 없는 경우 보조 VM은 주 역할을 인수하고 TLS 터널을 SAP BTP로 다시 설정하려고 시도합니다. 고가용성 클라우드 커넥터 환경이 아키텍처에 표시됩니다. 구성에는 부하 분산 장치 또는 클러스터 소프트웨어와 같은 다른 Azure 기술은 필요하지 않습니다. 구성 및 작업에 대한 자세한 내용은 SAP 설명서를 참조하세요.

SAP Analytics Cloud Agent

일부 애플리케이션 시나리오의 경우 SAP Analytics Cloud Agent는 VM에 설치된 애플리케이션입니다. SAP BTP 연결용 SAP Cloud Connector를 사용합니다. 이 아키텍처에서 SAP Analytics Cloud Agent VM은 SAP Cloud Connector VM과 함께 SAP 경계 애플리케이션 서브넷에서 실행됩니다. Azure 가상 네트워크와 같은 개인 네트워크에서 SAP Analytics Cloud Agent를 통해 SAP BTP로의 트래픽 흐름은 SAP 설명서를 참조하세요.

SAP는 SAP BTP에 Private Link 서비스를 제공합니다. Azure 구독 및 가상 네트워크에서 선택한 서비스와 선택한 SAP BTP 서비스 간에 프라이빗 연결을 사용하도록 설정합니다. Private Link 서비스를 사용하는 경우 통신은 퍼블릭 인터넷을 통해 라우팅되지 않습니다. 높은 수준의 보안 Azure 글로벌 네트워크 백본에 남아 있습니다. Azure 서비스와의 통신은 프라이빗 주소 공간을 통해 이루어집니다. 프라이빗 엔드포인트가 특정 Azure 서비스를 IP 주소에 매핑하기 때문에 Private Link 서비스를 사용할 때 향상된 데이터 반출 보호 기능이 기본으로 제공됩니다. 액세스는 매핑된 Azure 서비스로 제한됩니다.

일부 SAP BTP 통합 시나리오의 경우 Private Link 서비스 접근 방식이 선호됩니다. 다른 경우에는 SAP Cloud Connector가 더 적합합니다. 사용할 항목을 결정하는 데 도움이 되는 자세한 내용은 Cloud Connector와 SAP Private Link 나란히 실행을 참조하세요.

SAP RISE/ECS

SAP가 SAP RISE/ECS 계약에 따라 SAP 시스템을 운영하는 경우 SAP는 관리형 서비스 파트너입니다. SAP 환경은 SAP에 의해 배포됩니다. SAP 아키텍처에서는 여기에 표시된 아키텍처가 SAP/ECS를 사용하여 RISE에서 실행되는 시스템에는 적용되지 않습니다. 이러한 유형의 SAP 환경을 Azure 서비스 및 네트워크와 통합하는 방법에 대한 자세한 내용은 Azure 설명서를 참조하세요.

기타 SAP 통신 요구 사항

인터넷 바인딩된 통신과 관련된 추가 고려 사항은 Azure에서 작동하는 SAP 환경에 적용될 수 있습니다. 이 아키텍처의 트래픽 흐름은 이 아웃바운드 트래픽에 중앙 Azure 방화벽을 사용합니다. 스포크 가상 네트워크의 사용자 정의 규칙은 인터넷 바인딩된 트래픽 요청을 방화벽으로 라우팅합니다. 또는 특정 서브넷, 기본 Azure 아웃바운드 통신, VM의 공용 IP 주소(권장되지 않음) 또는 아웃바운드 규칙이 있는 공용 부하 분산 장치에서 NAT 게이트웨이를 사용할 수 있습니다. 일반적인 시나리오는 아웃바운드 네트워크 액세스를 통해 Microsoft Entra ID의 퍼블릭 엔드포인트, management.azure.com Azure 관리 API 및 타사 애플리케이션 또는 정부 애플리케이션의 서비스에 도달합니다.

Azure에서 기본 아웃바운드 액세스가 변경되었기 때문에 확장 가능한 아웃바운드 액세스가 정의되어 있는지 확인합니다. 클러스터형 환경과 같이 표준 내부 부하 분산 장치 뒤에 있는 VM의 경우 표준 Load Balancer 퍼블릭 연결에 대한 동작을 수정합니다. 자세한 내용은 SAP 고가용성 시나리오에서 Azure 표준 Load Balancer 사용하여 VM에 대한 공용 엔드포인트 연결을 참조하세요.

VM 의 기본 아웃바운드 연결에 대한 자세한 내용은 Azure 네트워킹 블로그의 프라이빗 서브넷 에서 VM에 대한 라우팅 옵션을 참조하세요.

운영 체제 업데이트

운영 체제 업데이트는 퍼블릭 엔드포인트 뒤에서 인터넷을 통해 액세스되는 경우가 많습니다. 엔터프라이즈 리포지토리 및 업데이트 관리가 없는 경우 개인 IP 주소/VM의 공급업체에서 OS 업데이트를 미러링하는 경우 SAP 워크로드는 공급업체의 업데이트 리포지토리에 액세스해야 합니다.

Linux 운영 체제의 경우 Azure에서 OS 라이선스를 획득하면 다음 리포지토리에 액세스할 수 있습니다. 라이선스를 직접 구매하여 Azure(BYOS)로 가져오는 경우 OS 공급업체에 문의하여 OS 리포지토리 및 해당 IP 주소 범위에 연결하는 방법을 알아보세요.

고가용성 클러스터 관리

클러스터된 SAP ASCS/SCS 또는 데이터베이스와 같은 고가용성 시스템은 Azure Fence 에이전트가 있는 클러스터 관리자를 STONITH 디바이스로 사용할 수 있습니다. 이러한 시스템은 Azure Resource Manager에 연결하는 데 따라 달라집니다. Resource Manager는 Azure 리소스에 대한 상태 쿼리 및 VM을 중지하고 시작하는 작업에 사용됩니다. Resource Manager는 공용 엔드포인트이므로 아래에서 management.azure.com사용할 수 있으므로 VM 아웃바운드 통신에 연결할 수 있어야 합니다. 이 아키텍처는 SAP 가상 네트워크에서 트래픽을 라우팅하는 사용자 정의 규칙이 있는 중앙 방화벽을 사용합니다. 다른 방법은 이전 섹션을 참조하세요.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

주요 작성자:

기타 기여자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

커뮤니티

이러한 커뮤니티를 사용하여 질문에 대한 답변을 얻고 배포 설정에 대한 도움을 받는 것이 좋습니다.

다음 단계