UI5 모드
SAP

S/4HANA Cloud vs ERP 권한 — 5가지 차이 #shorts #SAP #S4HANA

수정: 2026년 7월 28일 👁 0 · ♥ 0

📖 개요: 왜 Cloud의 권한은 "다르게" 설계되었나

ECC나 온프레미스 S/4HANA에서 PFCG로 권한을 관리해 온 실무자가 S/4HANA Cloud Public Edition을 처음 만나면 가장 먼저 당황하는 지점이 바로 권한 체계입니다. SU01도, PFCG 프로파일 생성도, SU24 제안값 편집도 기존 방식 그대로는 쓸 수 없기 때문입니다. 이 글은 S/4HANA Cloud(Public Edition 기준, Private Edition 차이도 병기)의 Business Role 기반 권한 모델을 온프레미스와 비교하여 5가지 구조적 차이로 정리합니다.

  • Business Role · Business Catalog · Restriction의 관계를 그림으로 이해한다
  • PFCG 역할과 Business Role의 설계 철학 차이를 설명할 수 있다
  • Fiori 앱 기반 권한 관리와 IAM 앱 추적 방법을 실습한다
  • Cloud Identity Services 및 IAG 연계 구조를 파악한다
  • Private Edition에서 ABAP AUTHORITY-CHECK를 안전하게 구현한다

📚 미리 알아두면 좋은 배경

이 글은 중급자 대상입니다. 온프레미스 권한 개념(Authorization Object, 필드, 프로파일, PFCG 역할)의 기본 구조를 알고 있고, Fiori Launchpad에서 앱 실행 경험이 있다면 충분합니다. ABAP 예제(2·3단계)는 Private Edition 또는 온프레미스 개발 경험이 있으면 이해가 빠르지만, Public Edition만 다루는 분은 개념 비교 파트만 읽어도 실무 적용에 무리가 없습니다.

🔧 환경 · 버전 · 준비물

이 글의 화면 및 예제는 다음 환경을 기준으로 작성했습니다.

  • SAP S/4HANA Cloud Public Edition 2508 — Business Role 관리는 Fiori 앱 "Maintain Business Roles"(F1492) 사용
  • SAP S/4HANA Cloud Private Edition 2023 — PFCG 접근 가능, ABAP 예제 검증 환경
  • SAP Cloud Identity Services(IAS/IPS) 테넌트 — 사용자 인증·프로비저닝
  • SAP Cloud Identity Access Governance(IAG) — SoD 분석 시나리오(선택)

Public Edition 실습에는 SAP_BR_ADMINISTRATOR 성격의 관리자 Business Role이 할당된 계정이 필요합니다. Private Edition 예제는 개발 권한(S_DEVELOP)이 있는 시스템에서 수행합니다. 버전에 따라 앱 이름과 UI 배치가 다를 수 있으므로 Fiori Apps Reference Library에서 자신의 릴리스를 먼저 확인하는 것이 권장됩니다.

💡 핵심 개념: ERP와 다른 5가지 구조적 차이

온프레미스 권한이 "부품(Authorization Object)을 하나씩 조립해 역할을 만드는 방식"이라면, S/4HANA Cloud는 "완성된 가구 세트(Business Catalog)를 골라 방(Business Role)에 배치하는 방식"에 가깝습니다. 조립 자유도는 줄어들지만, 잘못 조립할 위험도 함께 줄어듭니다.

차이 1 — 권한의 기본 단위: PFCG 역할 vs Business Role + Business Catalog. 온프레미스에서는 관리자가 Authorization Object 단위까지 내려가 프로파일을 직접 구성합니다. Public Edition에서는 SAP이 사전 정의한 Business Catalog(예: 구매오더 처리 카탈로그)가 최소 단위이며, 관리자는 카탈로그를 Business Role에 담기만 합니다. 카탈로그 내부의 권한 오브젝트 매핑은 SAP이 관리하므로 개별 오브젝트를 임의로 빼거나 추가할 수 없습니다.

차이 2 — 값 제어 방식: 필드 편집 vs Restriction Type. PFCG에서는 회사코드·플랜트 같은 조직 값을 오브젝트 필드에 직접 입력합니다. Cloud에서는 Business Role 수준에서 Write / Read / Value Help 세 가지 접근 카테고리에 대해 Restriction(제한값)을 지정합니다. 어떤 필드가 제한 가능한지는 카탈로그에 정의된 Restriction Type이 결정하며, 같은 제한값이 역할 내 모든 카탈로그에 일관 적용됩니다.

차이 3 — 접근 채널: 트랜잭션 코드 vs Fiori 앱 + IAM 앱. 온프레미스의 S_TCODE 중심 접근 제어는 Cloud에서 사라집니다. 대신 카탈로그가 실행 가능한 Fiori 앱 목록을 결정하고, 화면 배치는 Launchpad Space/Page가 담당합니다. "이 앱을 쓰려면 어떤 카탈로그가 필요한가"는 IAM Information System 계열 앱으로 역추적합니다.

차이 4 — 사용자 수명주기: SU01 vs Business User + Cloud Identity Services. Public Edition의 사용자는 HR 마스터(Workforce Person)와 연결된 Business User로 관리되고, 인증은 IAS, 프로비저닝은 IPS가 담당하는 것이 일반적입니다. 비밀번호 정책·MFA 같은 인증 정책이 애플리케이션 밖(IAS)으로 분리된 점이 큰 차이입니다.

차이 5 — 거버넌스: GRC Access Control vs IAG. 온프레미스의 SoD(직무 분리) 분석은 GRC AC가 담당했지만, Cloud에서는 SAP Cloud Identity Access Governance가 Business Role 단위로 위험 분석·접근 요청·인증(Access Certification)을 수행합니다. IAG는 S/4HANA Cloud 외에 Ariba, SuccessFactors까지 교차 분석할 수 있다는 점에서 적용 범위가 넓습니다.

💻 실전 예제 3단계

1단계 — 기본: 구매오더 담당자용 Business Role 만들기 (Public Edition). "Maintain Business Roles" 앱에서 신규 역할을 생성하고 카탈로그를 추가합니다. 아래는 이 과정에서 실제로 정의되는 구조를 의사 표기로 정리한 것입니다.

businessRole:
  id: ZBR_PO_BUYER_KR          # 사내 네이밍 규칙: ZBR_<업무>_<지역>
  description: "구매오더 담당자 - 한국 법인"
  businessCatalogs:
    - SAP_MM_BC_PO_PROCESS_PC   # 구매오더 처리
    - SAP_MM_BC_PR_PROCESS_PC   # 구매요청 처리
  accessCategories:
    write:
      CompanyCode: [ "1710" ]   # 한국 법인만 쓰기 허용
      Plant:       [ "1710" ]
    read:
      CompanyCode: [ "*" ]      # 조회는 전 법인 허용
  launchpadSpace: ZSP_PROCUREMENT_KR

핵심은 Write와 Read를 분리해 "수정은 자기 법인, 조회는 전사"라는 흔한 요구를 Restriction만으로 구현한다는 점입니다. 온프레미스라면 M_BEST_BSA 등 여러 오브젝트를 일일이 손봐야 했던 작업입니다.

2단계 — 실무 시나리오: Private Edition에서 커스텀 권한 체크와 로깅. Private Edition·온프레미스에서는 커스텀 앱에 자체 Authorization Object를 만들 수 있습니다. 벤더 송장 승인 앱에 ZVND_INV 오브젝트(필드: ACTVT, BUKRS)를 만들었다고 가정하고, 실패 시 애플리케이션 로그를 남기는 패턴입니다.

CLASS zcl_vendor_invoice_auth DEFINITION PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    METHODS check_approve_authority
      IMPORTING iv_bukrs        TYPE bukrs
      RETURNING VALUE(rv_ok)    TYPE abap_bool.
ENDCLASS.

CLASS zcl_vendor_invoice_auth IMPLEMENTATION.
  METHOD check_approve_authority.
    AUTHORITY-CHECK OBJECT 'ZVND_INV'
      ID 'ACTVT' FIELD '43'        " 43 = 승인(Release)
      ID 'BUKRS' FIELD iv_bukrs.

    IF sy-subrc = 0.
      rv_ok = abap_true.
      RETURN.
    ENDIF.

    " 실패 사유를 애플리케이션 로그에 기록 (SLG1 조회 가능)
    DATA(lo_log) = cl_bali_log=>create_with_header(
      header = cl_bali_header_setter=>create(
                 object    = 'ZVND'
                 subobject = 'AUTH' ) ).
    lo_log->add_item( cl_bali_free_text_setter=>create(
      severity = if_bali_constants=>c_severity_warning
      text     = |승인 권한 없음: 사용자 { sy-uname }, 회사코드 { iv_bukrs }| ) ).
    cl_bali_log_db=>get_instance( )->save_log( log = lo_log ).
    rv_ok = abap_false.
  ENDMETHOD.
ENDCLASS.

포인트는 두 가지입니다. 첫째, sy-subrc를 확인하지 않는 AUTHORITY-CHECK는 체크하지 않은 것과 같습니다. 둘째, 권한 실패를 조용히 삼키지 말고 로그로 남겨야 SU53만으로 잡기 어려운 산발적 이슈를 추적할 수 있습니다.

3단계 — 프로덕션: 테스트 자동화와 보안 강화. 권한 로직은 회귀가 잦으므로 단위 테스트로 고정합니다. ABAP Unit에서는 권한 체크를 인터페이스로 분리해 테스트 더블을 주입하는 방식이 일반적으로 권장됩니다.

CLASS ltc_invoice_approval DEFINITION FINAL FOR TESTING
  DURATION SHORT RISK LEVEL HARMLESS.
  PRIVATE SECTION.
    METHODS deny_without_authority FOR TESTING.
ENDCLASS.

CLASS ltc_invoice_approval IMPLEMENTATION.
  METHOD deny_without_authority.
    " 권한 체크 결과를 false로 고정한 테스트 더블 주입
    DATA(lo_auth_stub) = NEW ltd_auth_denied( ).
    DATA(lo_service)   = NEW zcl_invoice_approval_srv( io_auth = lo_auth_stub ).

    TRY.
        lo_service->approve( iv_invoice_id = '9000012345' ).
        cl_abap_unit_assert=>fail( '권한 없이 승인이 통과되면 안 됨' ).
      CATCH zcx_no_authority.
        " 기대한 예외 - 테스트 성공
    ENDTRY.
  ENDMETHOD.
ENDCLASS.

Public Edition 운영 관점에서는 코드 대신 프로세스로 보안을 강화합니다. (1) Business Role Template을 복사해 사용하고 SAP 표준 역할(SAP_BR_*)을 직접 할당하지 않기, (2) 릴리스 업그레이드 후 "Display Deprecated Business Catalogs" 계열 앱으로 폐기 예정 카탈로그를 점검하기, (3) IAG의 Access Analysis로 신규 역할 배포 전 SoD 위반을 사전 검증하기 — 이 세 가지가 운영 체크리스트의 최소선입니다.

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

Q1. 카탈로그를 추가했는데 사용자 Launchpad에 앱이 안 보입니다. 권한(카탈로그)과 화면 배치(Space/Page)는 별개입니다. 카탈로그만 추가하면 앱 실행 권한은 생기지만 타일은 나타나지 않을 수 있습니다. 해당 Business Role에 Space가 연결되어 있는지, Page에 앱 섹션이 배치되어 있는지 확인하세요. 반대로 타일은 보이는데 실행 시 권한 오류가 나면 카탈로그 누락입니다.

Q2. Restriction을 "Unrestricted"로 저장했는데 나중에 감사에서 지적받았습니다. 신규 역할 생성 직후 기본값을 그대로 두면 전체 조직 값에 쓰기 권한이 열립니다. Write는 반드시 명시적 값으로 좁히고, Read만 넓게 여는 패턴이 일반적으로 안전합니다. 정기적으로 IAM Information System에서 Unrestricted Write 역할 목록을 추출해 리뷰하세요.

Q3. 온프레미스처럼 SU53으로 권한 실패를 분석할 수 있나요? Public Edition에서는 SU53 트랜잭션 대신 "Display Authorization Trace" 및 IAM 계열 분석 앱을 사용합니다. 앱 실행 실패 시 사용자·카탈로그·제한값 조합을 추적할 수 있습니다. Private Edition은 SU53·ST01 트레이스를 그대로 쓸 수 있습니다.

Q4. 릴리스 업그레이드 후 일부 사용자의 권한이 갑자기 사라졌습니다. SAP이 카탈로그를 폐기(deprecate)하고 후속 카탈로그로 대체하는 경우입니다. 업그레이드 노트의 카탈로그 변경 목록을 확인하고, 폐기 카탈로그를 쓰는 역할을 미리 후속 버전으로 교체하는 절차를 분기마다 운영 루틴에 넣는 것이 권장됩니다.

🚀 실무 확장과 연계 주제

이 글에서 다룬 5가지 차이를 이해했다면, 다음 주제로 확장해 보세요. 첫째, IPS 변환 규칙을 이용한 IAS→S/4HANA Cloud 자동 프로비저닝 — 채용·퇴사 시 역할 부여·회수를 자동화합니다. 둘째, IAG Access Request 워크플로 구성 — 셀프서비스 권한 신청과 승인 체계를 만듭니다. 셋째, Private Edition이라면 SU25 업그레이드 후속 처리와 클라우드형 카탈로그 개념의 병행 전략을 검토해 보세요. RAP 기반 커스텀 앱의 권한(Access Control, DCL) 설계도 자연스러운 다음 관심사입니다.

📌 핵심 정리

  • Cloud 권한의 최소 단위는 Business Catalog — Authorization Object를 직접 편집하지 않는다
  • 조직 값 제어는 Restriction Type으로, Write/Read를 분리해 최소 권한 원칙을 지킨다
  • S_TCODE 대신 카탈로그가 앱 접근을 결정, 배치는 Space/Page가 별도로 담당한다
  • 사용자 수명주기와 인증 정책은 Cloud Identity Services(IAS/IPS)에서 관리한다
  • SoD 분석·접근 인증은 IAG가 담당 — GRC AC보다 멀티 클라우드 범위가 넓다

댓글 0

아직 댓글이 없습니다.