CERTRULE로 잡는 주체전파 실패 3가지 #shorts #SAP #BTP

📖 개요: 사용자가 온프레미스로 안 넘어갈 때 어디부터 봐야 하는가

SAP BTP 앱에서 온프레미스 S/4HANA를 호출할 때 Principal Propagation(주체 전파)을 켜면, 클라우드에서 로그인한 사용자의 신원이 백엔드까지 그대로 전달되어 백엔드 권한(PFCG)으로 데이터가 필터링됩니다. 그런데 이 구성은 실패 지점이 세 군데로 명확히 나뉩니다. 이 글은 신뢰 관계 → 인증서 체인 → 백엔드 사용자 매핑 순서로 점검하며 "사용자가 안 넘어가는" 문제를 좁혀가는 진단 절차를 다룹니다.

Cloud Connector가 서브어카운트의 토큰 발급자를 신뢰하는지 점검할 수 있다
단기(short-lived) X.509 인증서 체인을 openssl과 ICM 파라미터로 검증할 수 있다
CERTRULE 기반 사용자 매핑 실패를 재현하고 수정할 수 있다

📚 미리 알아두면 좋은 것

BTP Destination 서비스와 Connectivity 서비스의 역할 구분, Cloud Connector의 기본 터널 개념, JWT의 발급자(issuer)와 사용자 속성 개념을 알고 있으면 좋습니다. 백엔드 쪽에서는 STRUST(인증서 저장소), ICM 프로파일 파라미터, SU01 사용자 마스터를 다뤄본 경험이 있으면 진단 속도가 크게 빨라집니다. advanced 난이도의 글이므로 각 트랜잭션의 기초 사용법 자체는 설명하지 않습니다.

🔧 환경 / 버전 / 준비물

이 글의 예제는 다음 구성을 전제로 합니다. 버전이 달라도 절차는 대체로 동일하지만, 화면 명칭은 다를 수 있습니다.

SAP BTP: Cloud Foundry 환경, 엔터프라이즈 계정, XSUAA 기반 사용자 로그인
Cloud Connector: 2.16 이상 (예제는 2.17 기준, 관리 UI 8443 포트)
백엔드: 온프레미스 S/4HANA 2023 (ABAP Platform, ICM HTTPS 포트 44300)
클라이언트 앱: CAP Node.js + SAP Cloud SDK
권한: Cloud Connector Administrator, 백엔드 STRUST/CERTRULE/RZ10 변경 권한, 서브어카운트 Administrator

진단용으로 openssl CLI와 Cloud Connector의 로그 레벨을 일시적으로 All로 올릴 수 있는 권한도 준비해 두는 것을 권장합니다.

💡 핵심 개념: 주체 전파는 "토큰 → 인증서 → 사용자" 3단 변환이다

Principal Propagation을 공항 환승에 비유하면 이해가 쉽습니다. 클라우드에서 발급된 JWT는 "출발국 여권"이고, Cloud Connector는 이를 검사한 뒤 백엔드가 읽을 수 있는 "환승 비자", 즉 단기 X.509 인증서를 발급하는 환승 창구입니다. 백엔드 입국 심사대(ICM + CERTRULE)는 이 인증서의 발급 기관을 믿을 수 있는지 확인하고, 인증서의 주체(Subject)를 자국 주민(SU01 사용자)과 대조합니다.

흐름을 도식화하면 다음과 같습니다.

# Principal Propagation 데이터 흐름
1_사용자_로그인: "BTP 앱 → XSUAA → 사용자 JWT 발급"
2_호출: "앱 → Destination(PrincipalPropagation) → Connectivity 프록시"
3_터널: "Connectivity → Cloud Connector (JWT 전달)"
4_토큰검증: "CC가 JWT 발급자를 신뢰 목록과 대조"   # ← 실패 원인 1
5_인증서발급: "CC 내부 CA가 단기 X.509 발급 (기본 수 분 유효)"
6_TLS전달: "CC 시스템 인증서로 백엔드 접속 + 단기 인증서 제시"  # ← 실패 원인 2
7_매핑: "ICM 통과 → CERTRULE 규칙 → SU01 사용자로 로그온"  # ← 실패 원인 3

즉 실패 원인은 정확히 세 변환 지점에 대응합니다.

원인 1 — 신뢰 관계 미구성: Cloud Connector가 토큰 발급자(서브어카운트/IdP)를 신뢰하지 않아 단기 인증서 발급 자체를 거부
원인 2 — 인증서 체인 문제: 백엔드가 CC의 CA·시스템 인증서를 신뢰하지 않거나 ICM이 클라이언트 인증서를 받지 않음
원인 3 — 사용자 매핑 실패: 인증서는 도착했지만 Subject 패턴과 백엔드 사용자 속성이 불일치

중요한 원칙 하나: 증상이 같아 보여도(대개 401/403 또는 로그온 팝업) 원인 계층은 다릅니다. 그래서 반드시 앞 단계부터 순서대로 좁혀야 합니다. 뒤 단계(CERTRULE)를 먼저 뒤지면 시간을 낭비하기 쉽습니다.

💻 실전 예제: 3단계 진단 절차

시나리오는 부품 유통사 NexWave의 판매 주문 조회 앱입니다. BTP의 CAP 앱이 온프레미스 S/4HANA의 판매 주문 OData를 사용자 권한으로 조회합니다.

1단계 (기본): 정상 구성을 먼저 만들어 기준선을 세운다

진단의 출발점은 "무엇이 정상인가"입니다. Destination은 다음과 같이 구성합니다.

# BTP Destination: S4H_SALES_PP
Name: S4H_SALES_PP
Type: HTTP
URL: http://s4hvirtual:44300        # Cloud Connector 가상 호스트
ProxyType: OnPremise
Authentication: PrincipalPropagation
CloudConnectorLocationId: SCC_PROD_01
HTML5.DynamicDestination: true

앱에서는 반드시 사용자 JWT를 실어 호출해야 합니다. 서비스 전용(client_credentials) 토큰에는 사용자 정보가 없어 주체 전파가 성립하지 않습니다.

const { executeHttpRequest } = require('@sap-cloud-sdk/http-client');

async function fetchMySalesOrders(req) {
  // req.authInfo에서 꺼낸 '사용자' 토큰을 명시적으로 전달
  const userJwt = req.headers.authorization?.replace(/^Bearer\s+/i, '');
  return executeHttpRequest(
    { destinationName: 'S4H_SALES_PP', jwt: userJwt },
    {
      method: 'GET',
      url: "/sap/opu/odata/sap/API_SALES_ORDER_SRV/A_SalesOrder?$top=5"
    }
  );
}

이 호출이 200을 반환하고 백엔드 ST05/SM20에서 실제 사용자 ID가 찍히면 기준선 완성입니다. 실패한다면 아래 2단계 진단으로 내려갑니다.

2단계 (실무 진단): 신뢰 관계 → 인증서 체인을 로그로 좁힌다

점검 A — 원인 1: Cloud Connector 신뢰 설정. CC 관리 UI에서 Cloud To On-Premise → Principal Propagation 탭을 엽니다. 서브어카운트의 토큰 발급자(예: XSUAA 또는 연결된 IdP)가 Trusted Identity Provider 목록에 있고 활성(Enabled) 상태인지 확인합니다. 목록이 비어 있거나 "Synchronize" 후에도 발급자가 빠져 있으면, CC는 단기 인증서 발급을 거부하고 로그에 다음과 유사한 메시지를 남깁니다.

# scc_core.log (Log Level: All)
WARN  ... Principal propagation denied:
      token issuer "https://nexwave-prod.authentication.ap12.hana.ondemand.com"
      is not configured as trusted

이 경우 Synchronize를 다시 수행하고 해당 발급자를 활성화하면 원인 1은 해소됩니다. 여기서 통과했는데도 실패하면 원인 2로 넘어갑니다.

점검 B — 원인 2: 인증서 체인. 확인할 인증서는 세 종류입니다. (1) CC의 System Certificate(백엔드와의 TLS 클라이언트 인증용), (2) CC의 CA Certificate(단기 인증서 서명용), (3) 백엔드 STRUST에 등록된 신뢰 목록. 먼저 CC UI의 Configuration → On Premise에서 두 인증서의 만료일을 확인하고, 내보낸 파일을 openssl로 검증합니다.

# 인증서 주체/발급자/유효기간 확인
openssl x509 -in scc_system_cert.pem -noout -subject -issuer -dates
# 예상 출력
#   subject=CN=nexwave-scc-system, O=NexWave, C=KR
#   notAfter=Mar 10 08:00:00 2027 GMT

# 단기 인증서 샘플이 CC CA 체인으로 검증되는지 확인
openssl verify -CAfile scc_ca_chain.pem short_lived_sample.pem

백엔드 쪽에서는 STRUST의 SSL Server 표준 PSE에 CC의 CA 인증서가 들어 있는지 확인하고, ICM 프로파일에 클라이언트 인증서 수용 파라미터가 있는지 봅니다.

# RZ10 인스턴스 프로파일 (예시)
icm/server_port_1 = PROT=HTTPS,PORT=44300,VCLIENT=1
icm/HTTPS/verify_client = 1
icm/HTTPS/trust_client_with_issuer  = CN=NexWaveSCC-CA, O=NexWave, C=KR
icm/HTTPS/trust_client_with_subject = CN=nexwave-scc-system, O=NexWave, C=KR

마지막 두 파라미터는 "이 발급자(CC CA)가 서명하고, 이 시스템 인증서를 가진 중개자가 전달한 인증서만 받아라"는 의미로, 값의 DN 문자열이 공백·순서까지 실제 인증서와 일치해야 합니다. 여기가 틀리면 인증서는 조용히 무시되고 로그온 팝업이 뜹니다. SMICM 트레이스 레벨을 2로 올리면 어떤 DN이 도착했는지 그대로 볼 수 있어 대조가 쉽습니다. 파라미터 반영 후에는 ICM 재시작이 필요합니다.

3단계 (프로덕션): 사용자 매핑 검증과 운영 안전장치

점검 C — 원인 3: 백엔드 사용자 매핑. CC의 Subject Pattern이 사용자 신원을 어떻게 인증서에 새길지 결정합니다. 예를 들어 이메일 기반이라면:

# Cloud Connector > Principal Propagation > Subject Pattern
Subject Pattern: CN=${mail}, OU=SalesCloud, O=NexWave, C=KR
# 발급 예: CN=j.park@nexwave.co.kr, OU=SalesCloud, O=NexWave, C=KR

백엔드에서는 CERTRULE 트랜잭션으로 규칙을 만듭니다. 샘플 인증서를 업로드한 뒤 "Certificate Attribute = CN(Subject)", "Login As = E-Mail"로 규칙을 저장하면, CN의 이메일이 SU01 사용자의 이메일과 대조되어 로그온됩니다. 흔한 함정 세 가지: SU01 이메일 미등록, 이메일 대소문자 불일치, 동일 이메일이 두 사용자에 걸려 있는 경우(매핑이 모호해져 거부됨)입니다. CERTRULE의 시뮬레이션 화면에서 샘플 인증서가 초록 상태인지 반드시 확인합니다. 특정 사용자만 규칙과 다르게 매핑해야 하면 CERTRULE의 명시적 매핑(Explicit Mapping)을 예외로 씁니다.

프로덕션에서는 다음 안전장치를 권장합니다.

# 운영 체크 자동화 (개념 예시: 만료 30일 전 경고)
checks:
  - name: scc-system-cert-expiry
    cmd: openssl x509 -in scc_system_cert.pem -noout -checkend 2592000
    on_fail: "알림: CC 시스템 인증서 30일 내 만료"
  - name: scc-ca-cert-expiry
    cmd: openssl x509 -in scc_ca_cert.pem -noout -checkend 2592000
  - name: e2e-probe
    desc: "테스트 사용자 JWT로 $top=1 호출 후 SM20 사용자 ID 검증"

또한 CC와 백엔드의 시간 동기화(NTP)는 필수입니다. 단기 인증서는 유효기간이 수 분 수준이라 시계가 어긋나면 "발급 즉시 만료" 같은 이상 동작이 납니다. 성능 측면에서는 단기 인증서 발급이 요청마다 일어나므로, 고빈도 호출 구간은 세션 재사용(쿠키 기반)을 검토하고, 보안 측면에서는 CC 관리 UI 접근을 최소 권한으로 제한하고 CA 개인키가 CC 외부로 나가지 않도록 관리합니다.

⚠️ 흔한 실수와 트러블슈팅 FAQ

Q1. BasicAuth로 바꾸면 되는데 PrincipalPropagation만 401이 납니다.
가장 흔한 케이스입니다. BasicAuth가 되면 네트워크·가상호스트는 정상이라는 뜻이므로, 원인은 반드시 신뢰/인증서/매핑 세 가지 중 하나입니다. 위 진단 순서(A→B→C)를 그대로 타면 됩니다. 일반적으로 절반 이상이 원인 2(ICM 파라미터 DN 불일치)에서 발견됩니다.

Q2. CC 로그에 아무 오류가 없는데 백엔드에서 로그온 팝업이 뜹니다.
CC가 인증서를 정상 발급·전달했지만 백엔드가 무시한 상황, 즉 원인 2 또는 3입니다. SMICM 트레이스(레벨 2)에서 클라이언트 인증서 수신 여부를 먼저 확인하세요. 수신됐다면 CERTRULE 시뮬레이션으로 넘어갑니다. VCLIENT=1이 빠져 있으면 ICM은 아예 인증서를 요청하지 않습니다.

Q3. 로컬 테스트는 되는데 배포하면 실패합니다.
배포 환경에서 client_credentials 토큰이 쓰이고 있을 가능성이 큽니다. 사용자 토큰이 아닌 서비스 토큰에는 주체가 없으므로 전파할 사용자 자체가 없습니다. Cloud SDK 호출부에 사용자 JWT를 명시적으로 전달하는지 확인하세요.

Q4. CERTRULE은 초록인데도 로그온이 거부됩니다.
사용자 잠금 상태, 유효기간 만료된 SU01 사용자, 혹은 동일 이메일 중복 등록을 의심하세요. SM20/SU01 로그온 데이터 탭을 함께 확인하면 대부분 잡힙니다.

그 외에 Location ID 오타(멀티 CC 환경), CC 업그레이드 후 CA 재생성으로 백엔드 STRUST와 어긋나는 사례, 서브어카운트 IdP 교체 후 Synchronize 누락도 반복적으로 보고되는 패턴입니다.

🚀 이어서 보면 좋은 주제

이 글은 HTTPS(ICM) 경로의 주체 전파를 다뤘습니다. 같은 원리를 RFC 경로에 적용하는 SNC 기반 Principal Propagation, 백엔드가 클라우드일 때의 OAuth2SAMLBearerAssertion 방식 전파, 그리고 SAP Cloud Identity Services(IAS)를 발급자로 쓸 때의 신뢰 구성 차이를 이어서 학습하면 전체 그림이 완성됩니다. 운영 관점에서는 Cloud Connector 고가용성(HA) 구성 시 두 노드의 CA를 일치시키는 방법도 함께 검토할 가치가 있습니다.

📚 함께 보면 좋은 문서

댓글 0