ST01 권한 트레이스 3가지 #shorts #SAP #PFCG

1. ST01이 필요한 이유 — SU53의 한계와 트레이스의 힘

권한 오류가 발생하면 대부분의 관리자는 SU53부터 실행합니다. 그러나 SU53은 해당 사용자의 마지막 실패한 권한 체크 하나만 보여줍니다. 실제 업무 트랜잭션은 한 번의 실행에서 수십 개의 AUTHORITY-CHECK를 통과하는데, 첫 번째 실패 이후의 체크는 아예 실행되지 않거나 SU53 버퍼에서 밀려나 버립니다. 즉 SU53으로 권한을 하나 추가해 주면, 사용자는 곧바로 "또 안 된다"며 돌아오는 악순환이 반복됩니다.

ST01(System Trace)은 커널 레벨에서 권한 체크 이벤트 전체를 시간 순서대로 기록합니다. 성공(RC=0)과 실패(RC=4, RC=12)를 모두 남기기 때문에, 하나의 트랜잭션이 요구하는 권한 오브젝트의 전체 목록을 한 번에 파악할 수 있습니다. 이 글에서는 ST01을 활용해 누락 권한(Missing Authorization)을 찾는 세 가지 실전 방법을 다룹니다. 이 글을 읽고 나면 다음을 할 수 있게 됩니다.

사용자 필터 기반으로 권한 트레이스를 켜고 결과를 해석하기
RC 값(0/4/12)의 의미를 구분하고 다중 오브젝트 누락을 한 번에 탐지하기
백그라운드 잡의 권한 오류를 추적하고 PFCG 롤에 반영하기

전제 지식으로는 PFCG 롤 구조(권한 오브젝트, 필드, 값), AUTHORITY-CHECK 구문의 기본 동작, 그리고 SU53/SUIM을 다뤄본 경험이 있으면 충분합니다. ABAP 코드를 직접 수정할 일은 없지만 읽을 수 있으면 원인 분석이 훨씬 빨라집니다.

2. ST01 트랜잭션 구조와 동작 원리

환경 기준을 먼저 정리하겠습니다. 이 글의 화면 구성과 동작은 SAP NetWeaver AS ABAP 7.40 이상, SAP S/4HANA 1909~2023(온프레미스)에서 검증되는 내용입니다. S/4HANA에서는 ST01의 후속 도구인 STAUTHTRACE가 일반적으로 권장되지만, ST01은 권한 체크 외에 커널 함수·RFC·테이블 버퍼 트레이스까지 통합 제공하므로 여전히 실무에서 널리 쓰입니다. 필요한 준비물은 다음과 같습니다.

ST01 실행 권한: S_ADMI_FCD (값 ST0M), S_TCODE = ST01
트레이스 파일 파라미터 확인: rstr/max_diskspace, rstr/filename (RZ11에서 조회)
재현 가능한 오류 시나리오와 테스트 사용자 계정

동작 원리를 비유하자면, SU53이 "마지막 CCTV 스틸컷 한 장"이라면 ST01은 "구간 전체의 블랙박스 영상"입니다. 트레이스를 켜면 워크 프로세스가 실행하는 모든 AUTHORITY-CHECK가 커널의 트레이스 레코드로 기록됩니다. 기록 항목은 다음과 같습니다.

권한 오브젝트 이름 (예: V_VBAK_VKO, K_CSKS)
체크된 필드와 값 (예: VKORG=1000, ACTVT=03)
Return Code — 0: 성공, 4: 값 불일치(오브젝트는 있으나 필드 값 부족), 12: 오브젝트 자체가 사용자 마스터에 없음
실행 프로그램, 사용자, 시각, 워크 프로세스 번호

중요한 제약이 하나 있습니다. ST01은 트레이스를 켠 애플리케이션 서버에서 실행되는 체크만 기록합니다. 다중 서버 환경에서 사용자가 다른 인스턴스에 로그온해 있으면 아무것도 잡히지 않습니다. SM51로 사용자의 접속 서버를 먼저 확인하거나, 전 서버를 한 화면에서 켤 수 있는 STAUTHTRACE를 쓰는 것이 안전합니다.

3. 트레이스 시작 전 필터 설정 전략

ST01을 필터 없이 켜면 초당 수백 건의 레코드가 쌓여 분석이 불가능해지고, 운영 서버라면 디스크와 성능에도 부담을 줍니다. 시작 전 반드시 두 가지를 설정합니다.

Trace Components: "Authorization check" 체크박스만 선택합니다. SQL Trace나 RFC Trace를 함께 켜면 파일이 순식간에 롤오버되어 정작 필요한 권한 레코드가 덮어써집니다.
General Filters: 메뉴의 Edit → Filter → Shared에서 Trace for user only에 문제를 재현할 사용자 ID를 입력합니다. 필요하면 트랜잭션 코드, 프로그램 이름으로도 좁힐 수 있습니다.

권장 절차는 "켜고 → 재현하고 → 즉시 끄기"입니다. 트레이스 활성 시간을 1~2분 이내로 유지하면 분석 대상 레코드가 수십 건 수준으로 줄어 판독이 쉽습니다. 재현 담당자와 전화나 메신저로 실시간 호흡을 맞추는 것이 실무 요령입니다.

4. 방법 1: 단순 권한 실패 — AUTHORITY-CHECK 미스 추적

가장 흔한 시나리오부터 봅니다. 영업 담당자 LEE_SALES가 판매 오더 조회(VA03)에서 "권한이 없습니다" 메시지를 받는 상황입니다.

SM51에서 LEE_SALES의 접속 인스턴스를 확인하고 해당 서버에서 ST01 실행
Authorization check만 선택, 필터에 사용자 LEE_SALES 지정 후 Trace On
사용자에게 VA03에서 오류를 재현하도록 요청
재현 완료 즉시 Trace Off, 그리고 Analysis 버튼으로 결과 조회 (사용자·시간 범위 입력)

분석 화면에는 다음과 같은 형태의 레코드가 나타납니다.

S_TCODE    RC=0   TCD=VA03
V_VBAK_AAT RC=0   AUART=OR, ACTVT=03
V_VBAK_VKO RC=4   VKORG=2000, VTWEG=10, SPART=00, ACTVT=03

RC=4는 오브젝트 V_VBAK_VKO 자체는 사용자 권한에 있으나 영업조직 2000에 대한 값이 없다는 뜻입니다. 개발 시스템에서 같은 체크가 코드상 어떻게 생겼는지 보면 이해가 빠릅니다. 아래는 커스텀 리포트에서 흔히 보는 형태의 예제입니다.

AUTHORITY-CHECK OBJECT 'V_VBAK_VKO'
  ID 'VKORG' FIELD lv_sales_org      " 예: '2000'
  ID 'VTWEG' FIELD lv_dist_channel
  ID 'SPART' FIELD lv_division
  ID 'ACTVT' FIELD '03'.
IF sy-subrc <> 0.
  MESSAGE e058(zsd_auth) WITH lv_sales_org.
ENDIF.

트레이스의 RC 값은 이 sy-subrc와 정확히 대응합니다. 더블클릭하면 체크가 발생한 프로그램 위치까지 이동할 수 있어, 표준인지 커스텀 체크인지 즉시 구분됩니다.

5. 방법 2: 복합 권한 오류 — 다중 오브젝트 누락 동시 탐지

신규 롤을 배포한 직후에는 오브젝트가 여러 개 동시에 빠진 경우가 많습니다. 예를 들어 구매 담당자 KIM_PROC가 구매 오더 생성(ME21N)에서 연쇄적으로 막히는 상황이라면, SU53 방식으로는 "권한 추가 → 재시도 → 다음 오류"를 오브젝트 수만큼 반복해야 합니다. ST01이라면 한 번의 재현으로 전체 누락 목록을 얻습니다.

분석 화면에서 RC가 0이 아닌 레코드만 골라내면 이런 결과를 얻을 수 있습니다.

M_BEST_BSA RC=12  BSART=NB, ACTVT=01        → 오브젝트 자체 없음
M_BEST_EKO RC=4   EKORG=3100, ACTVT=01      → 구매조직 값 부족
M_BEST_WRK RC=4   WERKS=P310, ACTVT=01      → 플랜트 값 부족
K_CSKS     RC=12  KOSTL=CC4200, ACTVT=03    → 코스트센터 조회 오브젝트 없음

판독 요령은 세 가지입니다.

RC=12 우선 처리: 오브젝트가 통째로 없는 것이므로 롤 설계 누락일 가능성이 높습니다. SU24 제안값이 비어 있는 커스텀 트랜잭션에서 자주 발생합니다.
RC=4는 값 확장: 오브젝트는 이미 롤에 있으니 조직 레벨(EKORG, WERKS 등) 값만 넓히면 됩니다. PFCG 조직 레벨 필드인지 일반 필드인지 구분해 수정 위치를 정합니다.
RC=0도 버리지 말 것: 성공 레코드는 해당 트랜잭션의 전체 권한 프로파일을 문서화하는 근거가 됩니다. 신규 롤 설계 시 그대로 요구사항 목록이 됩니다.

결과 목록은 로컬 파일로 내려받아 보안 변경 요청서에 첨부하면 감사 대응 문서로도 활용할 수 있습니다.

6. 방법 3: 백그라운드 잡 권한 오류 — 배치 실행 추적

대화창이 없는 백그라운드 잡은 SU53을 아예 쓸 수 없습니다. 야간 정산 잡 ZFI_COSTCENTER_SETTLE이 스텝 사용자 BATCH_FI로 실행되다 권한 오류로 취소(Cancelled)되는 시나리오를 봅니다.

SM37에서 잡 로그를 열어 취소 시점과 실행 서버를 확인합니다. 배치 워크 프로세스가 있는 인스턴스가 어디인지가 핵심입니다.
해당 인스턴스에서 ST01을 켜고 필터 사용자를 스텝 사용자 BATCH_FI로 지정합니다. 잡을 등록한 사람이 아니라 스텝에 지정된 실행 사용자라는 점에 주의하세요.
SM37에서 잡을 즉시 실행으로 재기동하거나, 다음 주기 실행 시각에 맞춰 트레이스를 켭니다.
잡이 취소되면 Trace Off 후 분석합니다.

배치 시나리오에서 자주 발견되는 누락 패턴은 다음과 같습니다.

S_BTCH_ADM RC=4   BTCADMIN=Y            → 잡 관리 권한
S_BTCH_NAM RC=4   BTCUNAME=BATCH_FI     → 타 사용자 이름으로 스텝 실행
S_DATASET  RC=4   PROGRAM=ZFI_..., ACTVT=34, FILENAME=/interface/fi/out
K_CSKS_SET RC=12  RESPAREA=CC4*         → 정산 대상 코스트센터 그룹

S_DATASET처럼 파일 인터페이스 관련 오브젝트는 대화 테스트에서는 절대 드러나지 않고 배치에서만 나타나는 대표적 사례입니다. 정기 잡이라 재현 시각을 맞추기 어렵다면, 트레이스 활성 시간이 길어지는 만큼 필터를 사용자+프로그램 두 조건으로 좁혀 레코드 폭증을 막는 것이 요령입니다.

7. PFCG 연동 — 탐지한 권한 오브젝트를 롤에 적용

트레이스로 얻은 목록을 롤에 반영할 때는 순서가 중요합니다.

SUIM으로 현재 상태 확인: User → by Authorization Values 경로로, 사용자가 그 오브젝트를 다른 롤에서 이미 받고 있는지 먼저 확인합니다. 중복 부여는 롤 난립의 원인입니다.
수동 삽입 대신 SU24 정비 검토: RC=12로 잡힌 오브젝트가 커스텀 트랜잭션(예: ZME21_APPROVE)에서 나온 것이라면, PFCG에서 Manually 추가하기보다 SU24에 체크 제안값을 등록하는 편이 장기적으로 유리합니다. 이후 그 트랜잭션을 어느 롤 메뉴에 넣든 오브젝트가 자동 제안되기 때문입니다.
PFCG 수정: 롤 열기 → Authorizations 탭 → Change Authorization Data에서, RC=4 건은 해당 필드 값(VKORG 2000, EKORG 3100 등)을 추가하고, RC=12 건은 오브젝트를 삽입한 뒤 트레이스에 찍힌 값으로 필드를 채웁니다. 트레이스 레코드에 값이 그대로 있으므로 추측할 필요가 없습니다.
Generate 후 사용자 비교: 프로파일 생성 후 User Comparison(PFUD)까지 완료해야 사용자 마스터에 반영됩니다.
재검증 트레이스: 같은 필터로 ST01을 다시 켜고 재현해 모든 레코드가 RC=0인지 확인합니다. 이 "탐지 → 적용 → 재검증" 루프가 한 사이클입니다.

주의: 트레이스에 찍힌 값을 무조건 넣는 것이 정답은 아닙니다. 영업조직 2000 접근이 업무상 정당한지는 권한 정책과 SoD(직무 분리) 관점에서 별도로 승인받아야 합니다. ST01은 "무엇이 부족한가"를 알려줄 뿐, "부여해도 되는가"는 알려주지 않습니다.

8. 운영 환경 ST01 활용 전략과 주의사항

운영에서 ST01을 다룰 때 자주 나오는 질문을 FAQ로 정리합니다.

Q1. 트레이스를 켰는데 아무 레코드도 안 잡힙니다.
십중팔구 서버 불일치입니다. ST01은 실행한 인스턴스만 기록하므로 SM51로 사용자의 로그온 서버를 확인하세요. 다중 서버라면 처음부터 STAUTHTRACE(시스템 전체 옵션)를 쓰는 것이 일반적으로 권장됩니다. 또 하나, 이미 성공한 체크는 사용자 버퍼 때문에 재실행 시 생략되는 경우가 있으니 세션을 새로 열어 재현하세요.

Q2. 트레이스 끄는 것을 잊으면 어떻게 되나요?
트레이스 파일은 rstr/max_diskspace 한도 내에서 순환 기록되므로 디스크가 무한히 차지는 않지만, 커널 레벨 기록 오버헤드가 계속 발생하고 오래된 레코드가 덮어써져 분석 데이터도 잃습니다. 작업 종료 체크리스트에 "ST01 Off 확인"을 반드시 포함하고, 상태 표시등이 꺼졌는지 눈으로 확인하는 습관을 들이세요.

Q3. RC=4인데 값을 넣어줘도 계속 실패합니다.
같은 오브젝트가 한 트랜잭션에서 여러 번, 다른 값 조합으로 체크되는 경우입니다. 분석 화면에서 오브젝트별로 정렬해 모든 값 조합을 확인하세요. 또 커스텀 코드가 AUTHORITY-CHECK 없이 자체 테이블로 권한을 판정하는 경우 트레이스에 아예 잡히지 않으므로, 이때는 개발자와 함께 코드를 확인해야 합니다.

Q4. 운영에서 ST01을 상시로 켜 둬도 되나요?
권장하지 않습니다. 문제 재현 시점에만 짧게 켜는 것이 원칙입니다. 장기간의 권한 사용 데이터가 필요하다면 목적이 다른 도구인 STUSOBTRACE(장기 권한 트레이스, RZ11 파라미터 auth/authorization_trace 기반)나 SM20/RSAU 보안 감사 로그를 검토하세요. 장기 트레이스는 SU24 제안값 정비, 단기 ST01은 개별 오류 해결이라는 역할 분담이 일반적입니다.

이 글의 내용을 익혔다면 다음 주제로 확장해 보세요. STAUTHTRACE의 시스템 전역 트레이스와 SU24 통합 평가, SU25를 통한 업그레이드 후 제안값 정비, SUIM 기반 권한 감사 리포트, 그리고 S/4HANA의 Fiori 카탈로그 권한(S_SERVICE, IWSG/IWSV) 분석이 자연스러운 연결 고리입니다. 특히 Fiori 환경에서는 OData 서비스 권한 오류가 ST01 트레이스에 함께 찍히므로 이 글의 방법이 그대로 통합니다.

더 깊이 볼 만한 문서는 다음과 같습니다.

댓글 0