GRC ARM vs SU01 직접 부여 — SOX 감사 차이 #shorts #SAP #GRC

SAP GRC Access Control과 액세스 거버넌스가 필요한 이유

SOX(사베인스-옥슬리법)나 내부회계관리제도 감사에서 가장 자주 지적되는 항목이 바로 권한 부여 프로세스의 통제 부재입니다. "누가, 언제, 어떤 근거로, 누구의 승인을 받아 이 권한을 받았는가"에 답하지 못하면 IT 일반통제(ITGC) 결함으로 이어집니다. SAP GRC Access Control(이 글은 GRC AC 12.0, SP 기준 NetWeaver 7.52 애드온 환경을 전제)은 이 질문에 시스템적으로 답하기 위한 솔루션이며, 네 가지 모듈로 구성됩니다.

ARM(Access Request Management) — 이 글의 핵심인 액세스 요청·승인 워크플로우
ARA(Access Risk Analysis) — SoD(직무분리) 리스크 실시간 분석
BRM(Business Role Management) — 역할 설계·유지보수
EAM(Emergency Access Management) — Firefighter 임시권한 통제

이 글에서는 요청 제출부터 감사 리포팅까지 5단계 승인 흐름을 따라가며, 각 단계에서 실제로 동작하는 테이블·설정 경로·BRFplus 커스터마이징까지 정리합니다. 읽고 나면 다음을 스스로 점검할 수 있습니다.

MSMP 워크플로우의 스테이지·에이전트·라우팅 구조를 그릴 수 있다
SoD 분석이 승인 흐름 어느 지점에 개입하는지 설명할 수 있다
BRFplus 결정 테이블로 승인자 라우팅을 직접 바꿀 수 있다

전제로 ABAP 기본 문법, PFCG 역할 개념, SPRO 설정 경험이 있으면 수월합니다. GRC를 처음 접해도 권한관리(SU01/PFCG) 경험이 있다면 따라올 수 있는 수준으로 풀어 썼습니다.

액세스 요청(AR)의 구조와 핵심 구성 요소

GRC의 액세스 요청은 하나의 문서(Request)이며, 헤더-라인아이템 구조를 가진 판매오더와 비슷하게 생각하면 이해가 빠릅니다. 판매오더 헤더에 고객·납품일이 있고 아이템에 자재가 붙듯, AR 헤더에는 요청자·요청유형·사유가, 라인아이템에는 요청 대상 역할(Role)들이 붙습니다.

구성 요소	주요 테이블	설명
요청 헤더	`GRACREQUEST`	요청번호, 요청유형(New/Change/Lock), 우선순위, 상태
프로비저닝 아이템	`GRACREQPROVITEM`	요청된 역할/시스템별 라인아이템과 유효기간
승인자 이력	`GRACREQAPR`	스테이지별 승인자, 승인/거절 액션, 타임스탬프
기능 영역	`GRACFUNCAREA`	역할을 업무영역(재무/구매 등)으로 분류 — 라우팅 근거로 활용

워크플로우 엔진은 GRC 10.0부터 도입된 MSMP(Multi-Stage Multi-Path)이며, 프로세스 ID SAP_GRAC_ACCESS_REQUEST로 식별됩니다. MSMP는 "어떤 경로(Path)로 보낼지"를 이니시에이터 룰이 정하고, 경로 안의 "각 스테이지에서 누가 승인할지"를 에이전트 룰이 정하는 2계층 구조입니다. 두 룰 모두 BRFplus, 함수모듈, ABAP 클래스 중 하나로 구현할 수 있는데, 실무에서는 유지보수성이 좋은 BRFplus 결정 테이블이 일반적으로 권장됩니다.

1단계 — 요청 제출: NWBC/Fiori에서 요청 생성하기

최종 사용자는 NWBC(/n/NWBC)의 Access Management 워크센터 또는 Fiori 런치패드의 액세스 요청 앱에서 요청을 생성합니다. 관리자 관점의 핵심 설정 경로는 다음과 같습니다.

SPRO → GRC → Access Control → User Provisioning → Define Request Types — 요청유형(001 New Account, 002 Change 등) 정의
SPRO → ... → End User Personalization — EUP ID별로 요청 화면 필드의 필수/숨김/기본값 제어
템플릿 기반 요청: 자주 쓰는 조합(예: 영업사원 온보딩 = Z_SALESORDER_PROCESSOR + Z_DISPLAY_BILLING)을 템플릿으로 묶어 오입력을 줄임

제출된 요청이 실제로 어떤 상태인지 확인하는 가장 기본적인 방법은 GRACREQUEST 조회입니다. 실전 예제로, 특정 기간의 미결 요청을 읽는 기본 코드를 보겠습니다.

" 1단계 기본 예제: 미결(Open) 액세스 요청 조회
REPORT zgrc_open_requests.

SELECT reqno, reqtype, priority, createdate, status
  FROM gracrequest
  WHERE status IN ( 'OK_DECISION_PENDING', 'OK_SUBMITTED' )
    AND createdate >= @( cl_abap_context_info=>get_system_date( ) - 30 )
  INTO TABLE @DATA(lt_open_req).

LOOP AT lt_open_req INTO DATA(ls_req).
  WRITE: / ls_req-reqno, ls_req-reqtype, ls_req-status.
ENDLOOP.

IdM(Identity Management)이나 HR 시스템과 연동할 때는 표준 제공 웹서비스(요청 제출용 GRAC_SUBMIT_REQUEST 계열)를 사용하는 것이 일반적입니다. 화면 없이 대량 온보딩 요청을 자동 생성할 수 있습니다.

2단계 — SoD 리스크 분석: 실시간 충돌 검사 메커니즘

요청이 제출되면 승인자가 보기 전에(또는 승인 시점에) ARA 엔진이 시뮬레이션 리스크 분석을 수행합니다. 동작 원리는 이렇습니다.

요청된 역할 + 사용자가 이미 보유한 역할을 합산한 가상의 권한 집합을 만든다
룰셋(기본 GLOBAL)의 기능(Function) 조합 — 예: "구매발주 생성(PO Create)"과 "송장 검증(Invoice Verify)" — 이 동시에 존재하는지 검사한다
충돌이 있으면 리스크 ID(예: P001 계열)와 함께 요청 화면에 위반 내역을 표시한다

비유하자면 은행 대출 심사에서 신규 대출만 보는 게 아니라 기존 부채와 합산한 총부채상환비율을 보는 것과 같습니다. 신규 역할 단독으로는 깨끗해도, 기존 권한과 합쳐지면 SoD 위반이 되는 경우가 실무에서 가장 흔한 지적 사항입니다.

핵심 설정은 구성 파라미터입니다. 경로는 SPRO → GRC → Access Control → Maintain Configuration Settings이며, 파라미터 그룹 Risk Analysis에서:

1071 — 승인 시 리스크 분석 필수화(위반 미해소 시 승인 차단)
1072 — 제출 시 자동 리스크 분석 수행
완화통제(Mitigation Control) — 위반을 안고 가야 할 때 통제 ID를 할당하고 모니터 담당자를 지정. 이 할당 이력 자체가 감사 증적이 됩니다

대량 사용자 리스크 재분석은 GRAC_BATCH_RA(배치 리스크 분석)로 주기 실행하는 것이 일반적으로 권장됩니다.

3단계 — 다단계 승인자 라우팅: BRFplus 기반 결정 테이블

MSMP 설정 트랜잭션은 GRFNMW_CONFIGURE이며, 7개 탭(Process Global Settings → Rules → Agents → Variables/Templates → Paths → Route Mapping → Generate Version) 순서로 구성합니다. 전형적인 2~3 스테이지 경로는 다음과 같습니다.

요청 제출 → [Stage 1] 부서장(Manager) 승인 → [Stage 2] 역할 소유자(Role Owner) 승인 → [Stage 3·조건부] 리스크 존재 시 컴플라이언스 담당 승인 → 프로비저닝

승인자 결정을 BRFplus 결정 테이블로 구현한 예시입니다. 트랜잭션 BRFPLUS(또는 BRF+)에서 애플리케이션을 만들고, MSMP가 넘겨주는 라인아이템 컨텍스트(기능영역, 시스템 등)를 조건 컬럼으로 사용합니다.

FUNC_AREA (GRACFUNCAREA)	CONNECTOR	RISK_LEVEL	→ APPROVER_GROUP
FIN (재무)	PRD_ERP	*	FINANCE_APPROVER
MM (구매)	PRD_ERP	HIGH	PROCUREMENT_LEAD + CCO
SD (영업)	*	*	SALES_ROLE_OWNER

BRFplus로 커버하기 어려운 복잡한 로직(조직도 API 조회 등)은 함수모듈 기반 에이전트 룰로 구현합니다. 실무 시나리오 — 에러 처리와 로깅을 포함한 커스텀 라우팅 룰 예제입니다.

" 2단계 실무 예제: 함수모듈 기반 커스텀 에이전트 룰 (요청금액/영역별 승인자)
FUNCTION z_grc_agent_finance_route.
*  IMPORTING iv_reqno TYPE grfn_mw_s_context-external_key
*  EXPORTING et_users TYPE grfn_mw_t_agent_id

  DATA(lo_log) = cl_bal_wrapper=>create( object = 'ZGRC' subobject = 'ROUTE' ).

  TRY.
      " 요청 라인아이템의 기능영역 확인 (예: 재무영역 역할 포함 여부)
      SELECT SINGLE fa~func_area
        FROM gracreqprovitem AS it
        INNER JOIN gracfuncarea AS fa ON fa~role_name = it~role_name
        WHERE it~reqno = @iv_reqno
          AND fa~func_area = 'FIN'
        INTO @DATA(lv_fin).

      IF lv_fin IS NOT INITIAL.
        APPEND VALUE #( agent_id = 'FINANCE_APPROVER' ) TO et_users.
      ELSE.
        APPEND VALUE #( agent_id = 'DEFAULT_ROLE_OWNER' ) TO et_users.
      ENDIF.

    CATCH cx_sy_open_sql_db INTO DATA(lx_sql).
      " 라우팅 실패는 워크플로우 중단으로 이어지므로 반드시 로그 + 폴백
      lo_log->add_error( lx_sql->get_text( ) ).
      APPEND VALUE #( agent_id = 'GRC_ADMIN_FALLBACK' ) TO et_users.
  ENDTRY.

  lo_log->save( ).
ENDFUNCTION.

포인트는 두 가지입니다. 첫째, 에이전트가 공집합이 되면 요청이 고아(Orphan) 상태로 멈추므로 반드시 폴백 승인자를 반환해야 합니다. 둘째, 룰 변경 후에는 MSMP에서 Generate Version을 다시 수행해야 활성화됩니다 — 이걸 빠뜨리는 것이 가장 흔한 실수입니다.

4단계 — 기술 프로비저닝: 역할 자동 할당 흐름

최종 스테이지 승인이 완료되면 GRC는 커넥터(플러그인 RFC)를 통해 대상 시스템(ECC/S/4HANA)에 역할을 할당합니다. 흐름은 다음과 같습니다.

MSMP 종료 이벤트 → 프로비저닝 잡 트리거
커넥터별 프로비저닝 설정 확인 (SPRO → ... → Maintain Provisioning Settings: Auto/Manual/None)
대상 시스템 플러그인(GRC Plug-in 애드온)의 RFC로 사용자-역할 할당 실행 — 개념적으로 SU01 역할 탭 갱신과 동일
결과가 GRACREQPROVLOG 계열 로그에 기록되고, 실패 시 관리자 재처리 대상

유효기간이 지정된 요청(예: 프로젝트 파견 3개월)은 할당 시 종료일이 함께 세팅되며, 만료 시 별도 잡이 회수합니다. 역할 자체의 소유자·기능영역·승인자 메타데이터는 GRAC_ROLE_MAINT(BRM 역할 유지보수)에서 관리하며, 역할에 소유자(Role Owner)가 비어 있으면 3단계 라우팅이 실패하므로 프로비저닝 이전에 BRM 데이터 품질을 먼저 잡아야 합니다.

5단계 — 감사 추적과 컴플라이언스 리포팅

감사인이 요구하는 것은 "요청→분석→승인→할당"의 단절 없는 증적 체인입니다. GRC는 이를 다음으로 제공합니다.

GRACREQAPR — 스테이지별 승인자와 액션(승인/거절/반려), 타임스탬프. "부서장이 아닌 사람이 승인했는가"를 여기서 검증
NWBC Reports and Analytics의 액세스 요청 감사 리포트 — 요청별 전체 이력(코멘트, 리스크 분석 결과, 완화통제 할당 포함)
SLG1(오브젝트 GRAC*) — 프로비저닝·워크플로우 기술 로그
EAM 로그 리뷰, 주기적 UAR(User Access Review) — 부여된 권한의 정기 재승인

프로덕션 수준 예제로, 분기 감사 대비 승인 증적을 추출하는 리포트입니다. 권한 체크와 페이징(성능)을 포함했습니다.

" 3단계 프로덕션 예제: 분기별 승인 증적 추출 (권한체크 + 패키지 처리)
REPORT zgrc_audit_trail_q.

AUTHORITY-CHECK OBJECT 'ZGRC_AUDIT' ID 'ACTVT' FIELD '03'.
IF sy-subrc <> 0.
  MESSAGE '감사 리포트 조회 권한이 없습니다' TYPE 'E'.
ENDIF.

DATA lt_chunk TYPE STANDARD TABLE OF gracreqapr.

" 대량 데이터 대비: 커서 기반 패키지 조회로 메모리 사용 제한
OPEN CURSOR WITH HOLD @DATA(lv_cur) FOR
  SELECT reqno, appr_user, action, action_date, path_id, stage_id
    FROM gracreqapr
    WHERE action_date BETWEEN '20260401' AND '20260630'.

DO.
  FETCH NEXT CURSOR @lv_cur INTO TABLE @lt_chunk PACKAGE SIZE 5000.
  IF sy-subrc <> 0. EXIT. ENDIF.
  " 예: 요청자=승인자 동일 건(자기승인) 탐지 → 감사 예외 리스트 적재
  PERFORM detect_self_approval TABLES lt_chunk.
ENDDO.
CLOSE CURSOR @lv_cur.

실전 구현 — BRFplus 커스터마이징 절차와 자동화 팁

결정 테이블 커스터마이징의 전체 절차를 요약하면: ① BRFPLUS에서 애플리케이션 생성(Storage Type은 이관 가능하도록 Customizing 권장) → ② MSMP 룰 생성 마법사(GRFNMW_DEV_RULES 계열)로 함수·시그니처 자동 생성 → ③ 결정 테이블에 조건/결과 컬럼 구성 → ④ 시뮬레이션 기능으로 테스트 → ⑤ GRFNMW_CONFIGURE에서 룰 매핑 후 Generate Version → ⑥ 테스트 요청으로 End-to-End 검증 순입니다.

자주 겪는 문제 FAQ

Q1. 요청이 승인자에게 도착하지 않아요. → 에이전트 룰이 빈 결과를 반환했을 가능성이 큽니다. GRFNMW_DBGMONITOR_WD(워크플로우 모니터)에서 스테이지 상태를 확인하고, 역할 소유자 누락 여부(GRAC_ROLE_MAINT)를 점검하세요.
Q2. BRFplus 테이블을 고쳤는데 반영이 안 됩니다. → BRFplus 함수 활성화와 MSMP Generate Version은 별개입니다. 둘 다 수행했는지, 그리고 이미 진행 중인 요청은 생성 시점 버전을 따른다는 점을 확인하세요.
Q3. 리스크 분석 결과가 백엔드 실제 권한과 다릅니다. → 권한 동기화 잡(Repository Object Sync, Action Usage Sync)이 최신인지 확인하세요. 동기화가 오래되면 가상 권한 집합 계산이 어긋납니다.
Q4. 승인자가 휴가면 요청이 멈춥니다. → 스테이지 설정의 에스컬레이션(일정 시간 초과 시 상위자 전달)과 대리 승인(Delegation)을 활성화하는 것이 일반적으로 권장됩니다.

이후에는 UAR 워크플로우 자동화, EAM Firefighter 로그 리뷰 워크플로우, IAG(SAP Cloud Identity Access Governance)와의 하이브리드 연계로 확장해 보길 권합니다. 특히 S/4HANA Cloud가 섞인 환경이라면 GRC AC 12.0 + IAG Bridge 구성이 다음 검토 주제로 적합합니다.

댓글 0