SU24 vs Manual 권한 — PFCG 자동 제안 활용법 #shorts #SAP #SU24

📖 개요 및 이 글에서 얻을 수 있는 것

PFCG에서 역할을 만들 때마다 권한 오브젝트를 수동으로 하나씩 추가하고 계신가요? 그 방식은 당장은 빠르지만, 트랜잭션이 수백 개로 늘어나면 어떤 권한이 왜 들어갔는지 아무도 모르는 상태가 됩니다. 이 글은 SU24(권한 제안값 유지보수)를 올바르게 설정해 PFCG가 권한 오브젝트를 자동으로 제안하도록 만드는 전 과정을 다룹니다. 대상은 SAP NetWeaver AS ABAP 7.40 이상 및 S/4HANA(온프레미스) 환경입니다.

SU24와 PFCG의 내부 연동 메커니즘(USOBT_C/USOBX_C 테이블) 이해
AUTHORITY-CHECK 문과 SU24 제안값을 연결하는 실전 예제 작성
SU24 변경 후 SU25 Step 2c로 기존 역할을 안전하게 갱신하는 절차 습득
수동 권한(Manual)과 표준 권한(Standard)의 차이를 구분하고 유지보수 부채 제거

📚 미리 알고 있으면 좋은 내용

PFCG에서 단일 역할(Single Role)을 생성하고 프로파일을 생성해 본 경험, SE38/SE80에서 간단한 ABAP 리포트를 작성할 수 있는 수준을 전제로 합니다. AUTHORITY-CHECK 문의 기본 문법과 SU53(권한 실패 분석) 사용 경험이 있다면 예제를 더 빠르게 따라올 수 있습니다.

🔧 환경 · 버전 · 준비물

이 글의 예제는 다음 환경을 기준으로 작성되었습니다.

시스템: SAP S/4HANA 2023(온프레미스) 또는 SAP NetWeaver AS ABAP 7.50 이상 — ECC 6.0에서도 절차는 거의 동일합니다
권한: SU24 변경 권한(S_DEVELOP, S_USER_VAL 계열), PFCG 역할 유지보수 권한(S_USER_AGR 등), 개발 시스템에서의 커스텀 트랜잭션 생성 권한
트랜잭션: SU21(권한 오브젝트 정의), SU24, PFCG, SU25, SE93, SUIM
주의: SU24 변경은 커스터마이징 요청(Transport)에 담겨 운영으로 이관됩니다. 반드시 개발 시스템에서 작업하세요

💡 핵심 개념 — SU24는 PFCG의 "레시피북"이다

PFCG를 요리사에 비유하면 SU24는 레시피북입니다. 요리사(PFCG)는 메뉴(트랜잭션)를 받으면 레시피북(SU24)을 펼쳐 "이 메뉴에는 어떤 재료(권한 오브젝트)가 얼마나(필드 기본값) 필요한가"를 조회합니다. 레시피북이 비어 있으면 요리사는 감으로 재료를 넣을 수밖에 없고, 그 결과가 바로 수동 권한(Manual authorization)입니다.

기술적으로 이 레시피북은 두 개의 고객 테이블로 구현됩니다.

USOBX_C: 트랜잭션별로 어떤 권한 오브젝트가 점검되는지, 그리고 PFCG에 제안할지 여부(체크 인디케이터: Check/Yes, Check/No, Do not check)를 저장
USOBT_C: 제안 시 채워 넣을 권한 필드의 기본값(예: ACTVT = 03)을 저장

SAP이 배송하는 원본은 USOBX/USOBT이며, SU25 초기 설정(Step 1) 시 고객 테이블(_C)로 복사됩니다. 이후 SU24로 수정하는 대상은 항상 _C 테이블입니다. 업그레이드 때 SU25 Step 2a/2b가 SAP 신규 제안값과 고객 수정본을 비교·병합하는 것도 이 이중 구조 덕분입니다.

PFCG에서 역할 메뉴에 트랜잭션을 추가하고 권한 탭에 들어가면, PFCG는 USOBX_C에서 "Check/Yes"로 표시된 오브젝트를 읽어 Standard 상태의 권한으로 자동 생성하고 USOBT_C의 기본값을 채웁니다. 관리자는 조직 레벨 값과 열린 필드만 채우면 됩니다. 반면 SU24를 건너뛰고 권한 탭에서 직접 오브젝트를 추가하면 Manual 상태가 되는데, 이 권한은 트랜잭션 메뉴와의 연결 고리가 없어 나중에 메뉴에서 트랜잭션을 제거해도 그대로 남습니다. 이것이 "유지보수 지옥"의 시작입니다 — 감사 시점에 "이 권한이 왜 있는가"라는 질문에 아무도 답하지 못하게 됩니다.

중요한 사실 하나: SU24의 "Check/No" 설정이 실제 AUTHORITY-CHECK 실행 자체를 막지는 않습니다(예외적으로 S_TCODE 등 일부 HR/BC 오브젝트만 커널 레벨 제어 가능). SU24는 어디까지나 PFCG 제안을 제어하는 메타데이터이며, 런타임 점검은 코드 속 AUTHORITY-CHECK가 결정합니다. 이 둘을 혼동하면 "SU24에서 껐는데 왜 권한 오류가 나지?"라는 흔한 착각에 빠집니다.

💻 실전 코드 3단계 — 커스텀 트랜잭션에 권한 제안값 심기

1단계: AUTHORITY-CHECK가 포함된 기본 리포트와 커스텀 권한 오브젝트

SU21에서 커스텀 권한 오브젝트 Z_PLNT_RPT(필드: WERKS, ACTVT)를 만들었다고 가정합니다. 플랜트별 재고 조회 리포트에 점검 로직을 넣습니다.

REPORT zmm_stock_by_plant.

PARAMETERS: p_werks TYPE werks_d OBLIGATORY.

START-OF-SELECTION.
  AUTHORITY-CHECK OBJECT 'Z_PLNT_RPT'
    ID 'WERKS' FIELD p_werks
    ID 'ACTVT' FIELD '03'.        "03 = 조회

  IF sy-subrc <> 0.
    MESSAGE e045(zmm) WITH p_werks. "플랜트 &1 조회 권한이 없습니다
  ENDIF.

  " ... 재고 조회 로직 ...

SE93에서 트랜잭션 ZMM_STK를 이 리포트에 연결한 뒤 SU24를 실행합니다. 애플리케이션 유형 "Transaction", 이름 ZMM_STK를 입력하고 편집 모드에서 Z_PLNT_RPT를 추가, 체크 인디케이터를 Check / Yes(제안)로 설정합니다. 필드 기본값으로 ACTVT = 03을 입력하고 WERKS는 비워 둡니다(역할별로 채울 값). 저장하면 커스터마이징 요청에 기록됩니다.

2단계: 실무 시나리오 — 제안값 검증과 실패 로깅

실무에서는 SU24 설정이 실제 코드 점검과 일치하는지 검증하는 절차가 필요합니다. 점검 실패를 애플리케이션 로그(BAL)에 남겨 SU53 분석을 보완하는 패턴입니다.

CLASS lcl_auth DEFINITION.
  PUBLIC SECTION.
    CLASS-METHODS check_plant
      IMPORTING iv_werks        TYPE werks_d
                iv_actvt        TYPE activ_auth DEFAULT '03'
      RETURNING VALUE(rv_ok)    TYPE abap_bool.
ENDCLASS.

CLASS lcl_auth IMPLEMENTATION.
  METHOD check_plant.
    AUTHORITY-CHECK OBJECT 'Z_PLNT_RPT'
      ID 'WERKS' FIELD iv_werks
      ID 'ACTVT' FIELD iv_actvt.
    rv_ok = xsdbool( sy-subrc = 0 ).

    IF rv_ok = abap_false.
      DATA(lo_log) = cl_bali_log=>create_with_header(
        header = cl_bali_header_setter=>create(
                   object    = 'ZAUTH'
                   subobject = 'PLANT' ) ).
      lo_log->add_item( cl_bali_free_text_setter=>create(
        severity = if_bali_constants=>c_severity_warning
        text     = |권한 거부: 사용자 { sy-uname }, 플랜트 { iv_werks }| ) ).
      cl_bali_log_db=>get_instance( )->save_log( log = lo_log ).
    ENDIF.
  ENDMETHOD.
ENDCLASS.

이제 PFCG에서 새 역할 Z_MM_STOCK_VIEWER를 만들고 메뉴 탭에 ZMM_STK를 추가한 뒤 권한 탭을 열어 보세요. Z_PLNT_RPT가 Standard 상태로 자동 제안되고 ACTVT에 03이 미리 채워져 있으면 성공입니다. 관리자가 할 일은 WERKS에 1000 같은 값을 넣고 프로파일을 생성하는 것뿐입니다.

3단계: 프로덕션 — SU24 변경 후 기존 역할 일괄 갱신과 테스트

운영 중인 트랜잭션의 SU24 제안값을 바꾸면 기존 역할들이 자동으로 바뀌지 않습니다. 다음 절차를 표준 운영 프로세스로 삼는 것이 일반적으로 권장됩니다.

SU24에서 제안값 변경 후 저장 → 커스터마이징 요청 기록
SU25 Step 2c 실행 → 해당 트랜잭션을 사용하는 역할 목록이 자동 추출됨
목록의 각 역할을 PFCG "전문가 모드(Expert Mode) → Read old status and merge with new data"로 열어 병합 — 기존 유지보수 값은 보존되고 신규 제안만 추가됨
프로파일 재생성 후 사용자 마스터 비교(PFCG_TIME_DEPENDENCY 배치 잡 또는 PFUD)

배포 전 단위 테스트로 점검 로직을 고정해 두면 회귀를 막을 수 있습니다.

CLASS ltc_auth DEFINITION FOR TESTING
  DURATION SHORT RISK LEVEL HARMLESS.
  PRIVATE SECTION.
    METHODS deny_without_role FOR TESTING.
ENDCLASS.

CLASS ltc_auth IMPLEMENTATION.
  METHOD deny_without_role.
    DATA(lo_auth_double) = cl_aunit_authority_setter=>get_controller( ).
    cl_abap_unit_assert=>assert_false(
      act = lcl_auth=>check_plant( iv_werks = '9999' )
      msg = '권한 없는 플랜트는 거부되어야 함' ).
  ENDMETHOD.
ENDCLASS.

보안 관점에서는 SUIM(사용자 정보 시스템)으로 Z_PLNT_RPT에 WERKS = *가 부여된 역할을 주기적으로 스캔하고, SU24 변경 이력은 테이블 USOBT_CD/USOBX_CD(변경 문서)로 추적하는 운영 루틴을 함께 두는 것이 좋습니다.

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

Q1. SU24에 제안값을 넣었는데 PFCG에 안 나타납니다.
기존 역할의 권한 탭을 그냥 여는 것만으로는 재병합되지 않습니다. 전문가 모드에서 "Read old status and merge with new data"를 선택하거나 SU25 Step 2c를 거쳐야 합니다. 또한 체크 인디케이터가 "Check/Yes"가 아니라 "Check/No"로 저장되어 있는지도 확인하세요 — Check/No는 제안하지 않습니다.

Q2. SU24에서 "Do not check"로 바꿨는데 여전히 권한 오류가 납니다.
SU24는 PFCG 제안 메타데이터일 뿐, 코드 안의 AUTHORITY-CHECK 실행을 끄지 못합니다(일부 표준 오브젝트 예외 제외). 런타임 오류는 SU53 또는 STAUTHTRACE(권한 트레이스)로 실제 점검된 오브젝트를 확인해 역할에 값을 부여해야 합니다.

Q3. Manual 권한이 수백 개 쌓인 레거시 역할은 어떻게 정리하나요?
STAUTHTRACE나 SU24 트레이스 평가(장기 트레이스)로 실제 사용되는 오브젝트를 수집해 SU24 제안값으로 승격시킨 뒤, 역할을 재병합하면서 Manual 항목을 단계적으로 제거하는 접근이 일반적으로 권장됩니다. 한 번에 삭제하지 말고 운영 트레이스로 영향도를 확인하며 진행하세요.

Q4. 업그레이드 후 역할이 대량으로 노란불이 됩니다.
SU25 Step 2a(SAP 신규 값과 자동 병합)와 2b(고객 수정분 수동 비교)를 완료하지 않으면 제안값 불일치가 발생합니다. 업그레이드 프로젝트 계획에 SU25 단계를 반드시 포함하세요.

🚀 이어서 살펴볼 주제

SU24 기반 역할 설계가 자리 잡았다면 다음 주제로 확장해 보세요. 조직 레벨(Org Level) 필드 승격(PFCG_ORGFIELD_CREATE)으로 파생 역할(Derived Role) 체계 구축, STAUTHTRACE를 활용한 권한 최소화(Least Privilege) 프로젝트, S/4HANA 전환 시 SU25 자동화와 Fiori 카탈로그 권한(SU24의 Fiori 앱 제안값), 그리고 SAP GRC Access Control과의 SoD(직무 분리) 연계까지 이어지는 로드맵이 자연스럽습니다.

댓글 0