Proxy Type Internet vs OnPremise — BTP Cloud Connector 연결 핵심 #shorts #SAP #BTP

1. 개요 및 이 글에서 다룰 것

SAP BTP(Business Technology Platform) 위에서 운영되는 클라우드 애플리케이션이 사내 방화벽 뒤편의 On-Premise SAP S/4HANA, ECC, 또는 Non-SAP 시스템에 안전하게 접근해야 하는 시나리오는 하이브리드 환경 전환기의 대표적인 과제입니다. 이때 핵심 인프라가 SAP Connectivity Service와 SAP Cloud Connector(SCC)입니다. 두 컴포넌트는 양방향 TLS 터널을 통해 인바운드 포트를 추가로 열지 않고도 BTP에서 사내 시스템을 호출할 수 있게 해줍니다.

이 글에서 다룰 것:

• SAP Cloud Connector의 아키텍처와 Reverse Invoke 통신 원리 이해
• Subaccount와 SCC를 연결하고 Exposed Backend System을 등록하는 절차
• BTP Cockpit에서 Destination의 Proxy Type을 OnPremise로 설정하는 방법
• Cloud Foundry 또는 Kyma 런타임의 애플리케이션에서 Connectivity Service와 Destination Service 바인딩으로 백엔드 호출
• 운영 단계에서 자주 발생하는 인증/네트워크/Principal Propagation 트러블슈팅

2. 사전 가정

이 글은 다음 기반 지식을 갖춘 독자를 대상으로 합니다. SAP BTP Cockpit 사용 경험, Subaccount/Space 개념, Cloud Foundry CLI(cf CLI) 또는 Kyma kubectl 기본 명령, 그리고 사내 시스템 운영자와 협업하여 방화벽 아웃바운드 443 포트를 열 수 있는 권한이 있다고 가정합니다. 또한 백엔드 시스템이 OData, REST, RFC, SOAP 중 하나의 프로토콜을 제공하고 있어야 하며, Principal Propagation을 다루는 절에서는 X.509 인증서 기반 사용자 매핑에 대한 이해가 도움이 됩니다.

3. 환경 / 버전 / 준비물

이 글에서 검증한 환경은 다음과 같습니다. 다른 버전에서도 흐름은 동일하지만 UI 메뉴 위치는 조금 다를 수 있습니다.

• SAP BTP: Cloud Foundry 런타임 (Multi-Cloud, EU10/US10 등 무관)
• SAP Cloud Connector: 2.16.x 이상 (Portable / Installer 모두 지원)
• JDK: SapMachine 17 또는 OpenJDK 17 (SCC 2.16 기준 권장)
• OS: Linux(SLES, RHEL), Windows Server 2019 이상, macOS(개발용)
• 백엔드: SAP S/4HANA 2022 (또는 ECC 6.0 EHP8), OData V2 서비스 활성화
• 런타임 SDK: SAP Cloud SDK for JavaScript 3.x 또는 SAP Cloud SDK for Java 5.x

준비물: BTP Global Account Administrator 권한, Subaccount Administrator 권한, 사내 서버 한 대(최소 vCPU 2 / RAM 4GB), 백엔드 시스템의 Host/Port/사용자 정보, 아웃바운드 HTTPS 443 허용된 네트워크 환경.

4. 핵심 개념

SAP Cloud Connector(SCC)는 사내(데이터센터/사옥)에 설치되어 동작하는 경량 자바 애플리케이션이며, BTP Subaccount와 영구 TLS 터널을 유지합니다. 가장 중요한 특징은 Reverse Invoke 방식이라는 점입니다. 통상의 프록시처럼 BTP가 SCC로 신규 TCP 연결을 시도하는 것이 아니라, SCC가 먼저 BTP로 아웃바운드 연결을 열고 그 채널을 통해 BTP의 호출이 거꾸로 흘러들어옵니다. 따라서 사내 방화벽에서 인바운드 포트를 열 필요가 없고, 외부에서 사내 서버로 능동 접근하는 경로가 존재하지 않으므로 보안 감사 시에도 설명이 용이합니다.

비유하자면 SCC는 사내에서 외부로 뻗어나간 "단방향 빨대"이며, BTP는 그 빨대 끝을 빨아들이는 방식으로만 사내 데이터를 받습니다. 빨대는 SCC가 직접 자르거나, BTP에서 매핑을 끊지 않는 한 안전하게 유지됩니다.

Connectivity Service는 BTP 측에서 이 빨대를 관리하고 토큰을 발급하는 서비스입니다. 애플리케이션이 이 서비스에 바인딩되면 onpremise_proxy_host, onpremise_proxy_port, token_service_url 등이 환경변수로 주입되며, 앱은 이 프록시를 거쳐 백엔드를 호출합니다. Destination Service는 백엔드의 URL/인증 방식을 별도로 저장해두는 카탈로그 역할을 하므로, 보통 Connectivity와 Destination을 같이 바인딩합니다.

Proxy Type 차이를 명확히 구분해야 합니다.

• Internet: 공개 인터넷의 엔드포인트를 호출. SCC를 거치지 않음.
• OnPremise: SCC를 통해 사내 시스템 호출. 이 값이 아니면 SCC 매핑이 전혀 사용되지 않습니다.
• PrivateLink: 하이퍼스케일러 PrivateLink로 직접 사설 IP에 도달.

또한 Authentication 옵션으로 BasicAuthentication, PrincipalPropagation, OAuth2SAMLBearerAssertion, ClientCertificateAuthentication 등이 있으며, 사용자 ID를 사내 시스템으로 그대로 전달하려면 PrincipalPropagation을 선택하고 SCC 측에서 X.509 단기 인증서 발급 체인을 구성해야 합니다.

5. 실전 설정

1단계: Cloud Connector 설치 및 Subaccount 연결

SAP Software Center에서 Portable 버전을 받아 압축을 풀고 실행합니다. 최초 접속은 https://<scc-host>:8443이며 기본 계정은 Administrator / manage 입니다. 로그인 즉시 비밀번호 변경을 요구합니다.

# Linux Portable 예시
tar -xzf sapcc-2.16.x-linux-x64.tar.gz
cd sapcc-2.16.x
./go.sh
# 브라우저에서 https://localhost:8443 접속

좌측 메뉴 Connector > Add Subaccount에서 다음을 입력합니다.

• Region Host: cf.eu10.hana.ondemand.com 형태 (Subaccount의 Cloud Foundry API 주소에서 추출)
• Subaccount ID: BTP Cockpit Subaccount 개요 화면의 GUID
• Display Name: 내부 식별용 별칭
• Subaccount User / Password: BTP 로그인 계정 (Trust Configuration 사용자)

저장 후 상태가 Connected(녹색)로 표시되면 터널 수립 성공입니다.

2단계: Exposed Backend System 등록

Cloud To On-Premise > Access Control에서 백엔드 시스템을 추가합니다. 핵심은 Virtual Host(BTP 앱이 호출할 가짜 호스트명)와 Internal Host(실제 사내 호스트:포트)의 매핑입니다.

Back-end Type: ABAP System
Protocol: HTTPS
Internal Host: s4h.internal.corp:44300
Virtual Host: s4h-virtual:443
Principal Type: None  # 또는 X.509
Host In Header: Virtual
Resources:
  - URL Path: /sap/opu/odata/sap/ZSALES_SRV
    Access Policy: Path And All Sub-Paths

URL Path 화이트리스트를 등록하지 않으면 호출이 거부됩니다. 와일드카드(/)는 보안상 권장되지 않습니다.

3단계: BTP Destination 생성

BTP Cockpit에서 Subaccount > Connectivity > Destinations > New Destination을 클릭합니다.

Name: S4H_OnPrem
Type: HTTP
URL: https://s4h-virtual:443
Proxy Type: OnPremise   # 가장 중요
Authentication: BasicAuthentication
User: BTP_TECH_USER
Password: ********
Additional Properties:
  sap-client: 100
  HTML5.DynamicDestination: true
  WebIDEEnabled: true

여기서 URL의 호스트명은 SCC에 등록한 Virtual Host와 정확히 일치해야 합니다. Internal Host를 적으면 "host not reachable" 오류가 납니다. 저장 후 Check Connection 버튼을 눌렀을 때 200 또는 401(인증 실패지만 도달은 성공)이 나오면 경로가 살아있는 것입니다.

4단계: Connectivity / Destination 서비스 인스턴스 생성과 바인딩

cf create-service connectivity lite my-conn
cf create-service destination lite my-dest
cf create-service xsuaa application my-xsuaa -c xs-security.json
cf bind-service my-app my-conn
cf bind-service my-app my-dest
cf bind-service my-app my-xsuaa
cf restage my-app

5단계: Node.js 앱에서 Destination + Connectivity로 호출

import { executeHttpRequest } from "@sap-cloud-sdk/http-client";
import { retrieveJwt } from "@sap-cloud-sdk/connectivity";

export async function getSalesOrders(req) {
  try {
    const response = await executeHttpRequest(
      { destinationName: "S4H_OnPrem", jwt: retrieveJwt(req) },
      {
        method: "GET",
        url: "/sap/opu/odata/sap/ZSALES_SRV/SalesOrderSet?$top=10",
        headers: { Accept: "application/json" }
      }
    );
    return response.data;
  } catch (e) {
    console.error("[OnPrem] call failed", e.response?.status, e.message);
    throw e;
  }
}

SAP Cloud SDK는 내부적으로 Destination Service를 조회하여 Proxy Type이 OnPremise인 경우 Connectivity Service의 프록시(connectivityproxy:20003)로 트래픽을 자동 라우팅합니다. 즉, 개발자는 백엔드가 사내인지 클라우드인지를 코드에서 분기할 필요가 없습니다.

6단계: 운영 단계 강화 — 프로덕션에서는 다음을 권장합니다. SCC를 Master/Shadow 이중화로 배치하여 패치 다운타임을 제거하고, Audit Log를 7일 이상 보존하도록 설정하며, 백엔드별 Resource ACL을 최소 권한으로 줄입니다. 앱에서는 response.status, response.headers['x-vcap-request-id']를 함께 로깅해 Cloud Foundry 게이트웨이까지의 추적을 확보합니다. 시크릿(BTP 사용자 비밀번호)은 Destination에 평문 저장하지 말고 OAuth2SAMLBearerAssertion 또는 X.509 ClientCert를 우선 고려합니다.

6. 흔한 실수 / 트러블슈팅

Q1. "Could not find Connectivity Service" 또는 호출 시 502 Bad Gateway가 납니다.
대부분 Destination의 Proxy Type이 Internet으로 남아 있는 경우입니다. OnPremise로 변경하고 앱을 재시작하세요. 또한 Connectivity 서비스 바인딩 없이 Destination만 바인딩한 경우에도 같은 증상이 나타납니다.

Q2. SCC는 Connected인데 "host or service not reachable" 오류가 발생합니다.
Virtual Host와 Destination URL 호스트명이 일치하는지, 그리고 Access Control의 Resources 화이트리스트에 호출 URL 경로가 등록되었는지 확인합니다. Cloud To On-Premise > Channels에서 Trace Level을 INFO 이상으로 올린 뒤 재호출하여 거부 사유를 확인하세요.

Q3. Principal Propagation 사용 시 401만 반복됩니다.
일반적으로 다음 셋 중 하나입니다. (1) SCC 측 System Certificate가 백엔드 STRUST에 등록되지 않음, (2) 백엔드 ICM icm/HTTPS/verify_client가 1 이상이 아님, (3) 사용자 매핑(SU01의 X.509 SNC 정보)이 누락. SCC의 Principal Propagation 메뉴에서 "Check Configuration" 진단을 우선 실행하면 어느 단계가 실패하는지 알려줍니다.

그 외 자주 보는 실수로는 JWT 누락(앱 코드에서 retrieveJwt(req)를 빼먹어 토큰 교환이 안 되는 경우), aws/azure 아웃바운드 차단(SCC 서버에서 cf.<region>.hana.ondemand.com:443가 막힘), 시간 동기화 어긋남(NTP 미설정 시 TLS 인증서 검증 실패) 등이 있습니다.

7. 다음 단계 / 관련 주제

기본 흐름이 안정화되면 다음 주제로 확장하는 것을 권장합니다.

• Principal Propagation 심화: BTP IAS와 사내 AD/Kerberos 페더레이션, 단기 X.509 발급 자동화
• RFC / SOAP 호출: BTP의 RFC and SOAP Provider for On-Premise를 통한 BAPI 호출
• SAP Integration Suite Cloud Integration의 ProcessDirect/SOAP Adapter로 코드 없는 통합 구성
• Kyma 런타임의 Connectivity Proxy(Sidecar 모델)로 동일 패턴을 Kubernetes에서 운영
• SAP Private Link Service와의 비교: 동일 하이퍼스케일러 내 사설망에 직접 도달하는 대안
• 관측성: Cloud ALM 또는 Dynatrace로 SCC→BTP 구간 레이턴시 추적

8. 핵심 한 줄

SCC가 사내에서 BTP로 먼저 손을 내밀고, BTP는 Destination의 Proxy Type이 OnPremise일 때만 그 손을 잡는다 — 이 두 가지가 BTP 하이브리드 연결의 전부입니다.

참고 자료

• SAP Help Portal — SAP BTP Connectivity
• SAP Help Portal — Cloud Connector
• SAP Help Portal — Configure Access Control (HTTP)
• SAP Help Portal — Principal Propagation
• SAP Cloud SDK for JavaScript — Destinations
• SAP Community — Cloud Connector Topic