신규법인이 들어올 때마다 반갑기보다는 일이 먼저 떠오르는 분들, 저만 그런 건 아니죠? 이번 프로젝트도 그랬습니다. 회사코드 1000으로 이미 잘 돌아가고 있던 시스템에 회사코드 2000이 새로 붙는 상황이었는데요, 문제는 이 2000 법인이 기존 프로그램을 그대로 쓰겠다는 거였습니다. 새로 만들 필요 없이 로직만 좀 고쳐달라는 거죠.
말은 쉬운데 문제는 기존 프로그램들에는 회사코드 구분 고려없이 하드코딩이 여기저기 박혀있다는 점입니다.회사코드 1000만 바라보고 짜여진 로직들, 조건문에 그냥 '1000'이 박혀있는 부분들. 이런 걸 하나씩 찾아서 2000도 태울 수 있게 주요 로직을 손봐야 했습니다.
프로그램은 고쳤는데, 그다음이 진짜 문제였다
로직 수정은 어떻게든 끝냈습니다. 근데 여기서 끝이 아니더라고요. 회사코드 1000 임직원은 1000 데이터만 봐야 하고, 2000 임직원은 2000 데이터만 봐야 하는데, 프로그램 자체는 이제 둘 다 조회가 가능해진 상태였습니다. 즉 권한으로 막아주지 않으면 1000 직원이 2000 데이터를, 2000 직원이 1000 데이터를 그냥 열어볼 수 있는 상태가 된 거죠.
여기서 이 프로그램이 표준이 아니라 CBO(Customer Developed Object)라는 게 걸림돌이었습니다. 표준 프로그램이면 회사코드 관련 권한 오브젝트가 이미 붙어있는 경우가 많은데, 커스텀으로 짠 프로그램이다 보니 그런 게 없었습니다. 그러니까 회사코드별로 조회를 막아주는 권한 체크 로직을 직접 심어야 하는 상황이었던 겁니다.
혹시 CBO 프로그램에 표준 권한 오브젝트가 알아서 붙어있을 거라 생각하신 분 계신가요? 저도 처음엔 그렇게 생각했다가, 커스텀 프로그램은 권한 체크를 개발자가 직접 넣어주지 않으면 아무 체크도 안 된다는 걸 다시 한번 확인했습니다.
권한 오브젝트, 왜 새로 만들어야 했나
회사에서는 프로젝트마다 Role Naming Rule이 정해져 있습니다. 저희 프로젝트도 마찬가지였는데요, 예를 들면 ZTR_01처럼 짧게 가는 방식도 있고, ZTR01_1000처럼 회사코드를 아예 Role 이름에 박아버리는 방식도 있습니다. 이런 Rule에 맞춰서 Role을 만들게 되는데, 문제는 Role만 있다고 되는 게 아니라 그 Role이 참조할 “권한 오브젝트”가 있어야 한다는 겁니다.
처음에는 Authority-check Object 대상으로 ‘F_BKPF_BUK’값을 사용해보면 어떨까 했습니다만, 해당 부분은 표준 권한만 체크하고, 사용자가 사용하는 다른 Role에 적용되어있을 수 있어 Role을 손대기에는 조금 부담이 있다 판단되었습니다. 따라서 표준 권한 오브젝트로는 이 프로그램의 회사코드 조회 로직을 커버할 수 없었기 때문에, SU21에서 오브젝트 클래스부터 새로 만들었습니다.
SU21에서 ZTR_BUKRS 오브젝트를 만들 때 필드로 BUKRS와 ACTVT를 넣어줬습니다. BUKRS는 당연히 회사코드고, ACTVT는 조회(03)만 체크할 거라 사실상 03 하나만 쓰지만, 나중에 다른 활동유형이 필요할 수도 있으니 필드 자체는 표준대로 열어뒀습니다.
권한 오브젝트 클래스 생성권한 Object의 생성
PFCG에서 Role에 붙이기
오브젝트를 만들었으면 이제 Role에 실제로 붙여줘야 합니다. 대상 Role은 ZBRTR_01_2000이었고, 진행 순서는 이랬습니다.
SU21 → ZTR_BUKRS → BUKRS, ACTVT 필드 존재 여부 및 활성화 확인
PFCG → ZBRTR_01_2000 Role 오픈
수동으로 Object에 ZTR_BUKRS 입력 후 엔터
권한 라인이 추가되면 권한 00 펼치고 값 세팅
BUKRS = 2000
ACTVT = 03
저장
Profile Generate
사용자 Role User Comparison 진행
재로그인 또는 권한 버퍼 갱신 후 테스트
여기서 대부분 놓치는 부분이 하나 있는데요, Role의 Authorization을 수정하고 저장만 하고 Profile Generate를 안 하는 경우가 은근히 있습니다. Generate를 안 하면 아무리 값을 넣어도 실제 프로파일에는 반영이 안 되거든요. 그리고 User Comparison까지 해줘야 사용자 마스터에 Role이 제대로 물려서 다음 로그인부터 적용됩니다.
Role 내 Object 권한 추가
프로그램에 권한 체크 로직 심기
Role과 오브젝트 쪽 준비가 끝났으면, 이제 프로그램 안에서 실제로 이 권한을 체크하는 코드를 넣어줘야 합니다. Selection Screen에서 회사코드를 입력받는 시점에 체크하도록 AT SELECTION-SCREEN 이벤트에 로직을 넣었습니다.
TABLES: sscrfields.
*---------------------------------------------------------------------*
* Selection Screen Authorization Check
*---------------------------------------------------------------------*
AT SELECTION-SCREEN.
CHECK sscrfields-ucomm = 'ONLI'.
"ZSAPBRO 계정 제외
IF sy-uname+0(3) <> 'ZSB'.
AUTHORITY-CHECK OBJECT 'ZTR_BUKRS'
ID 'BUKRS' FIELD p_bukrs
ID 'ACTVT' FIELD '03'.
IF sy-subrc <> 0.
MESSAGE '해당 회사코드 조회권한이 없습니다.' TYPE 'E'.
ENDIF.
ENDIF.
메시지 부분은 SE91에 별도 메시지 클래스를 등록해서 MESSAGE ID 'ZTR' TYPE 'E' NUMBER '001' 형태로 관리하는 방법도 있는데, 이번 건은 규모가 크지 않아서 그냥 리터럴 텍스트로 바로 출력하게 처리했습니다. 나중에 동일 계열 메시지가 여러 개 필요해지면 그때 메시지 클래스로 옮기는 게 관리하기 편할 겁니다.
그리고 sy-uname+0(3) <> 'ZSB' 조건은 특정 인터페이스/배치성 계정은 이 체크에서 빼주기 위한 예외처리입니다. 사람 계정이 아니라 시스템 간 연동이나 배치 잡으로 도는 계정까지 회사코드 권한에 걸려버리면 배치가 통째로 죽어버리니, 이런 계정은 처음부터 체크 대상에서 제외해주는 게 낫습니다.
이 프로그램 작업하면서 하나 걸렸던 게 있는데요, AT SELECTION-SCREEN에서 sscrfields-ucomm을 체크하려는데 이런 에러가 떴습니다.
Field "SSCRFIELDS-UCOMM" is unknown
원인은 간단합니다. 프로그램에서 SSCRFIELDS를 선언하지 않았기 때문입니다. SAP 표준 ABAP 문서에서도 Selection Screen의 Function Code를 SSCRFIELDS-UCOMM으로 사용하려면 프로그램에 TABLES sscrfields를 선언해야 한다고 명시하고 있고, SY-UCOMM보다 SSCRFIELDS-UCOMM 사용을 권장하고 있습니다.
이런 경우 프로그램 상단부(TOP)에 다음 한 줄만 추가해주면 해결됩니다.
TABLES: sscrfields.
테스트는 어떻게 확인했나
코드까지 넣고 나면 이게 실제로 의도한 대로 동작하는지 확인해야겠죠. 이때 유용한 게 STAUTHTRACE와 SU53입니다.
STAUTHTRACE: 실제로 ZTR_BUKRS 권한 체크가 어느 시점에, 어떤 값으로 일어나는지 추적할 때 사용했습니다.
SU53: 권한이 없어서 막힌 경우, 정확히 어떤 오브젝트의 어떤 필드에서 걸렸는지 확인할 때 사용했습니다.
2000 Role만 받은 사용자로 로그인해서 회사코드 1000을 조회 시도했을 때 “해당 회사코드 조회권한이 없습니다” 메시지가 뜨는지, 반대로 2000을 조회할 땐 정상적으로 데이터가 나오는지, 이 두 가지를 기준으로 테스트했습니다.
마무리하며
이번 건은 IMG 설정으로 끝나는 작업이 아니라 ABAP Authorization 구현까지 들어가야 했던 케이스였습니다. 신규법인이 붙을 때 다들 로직 수정에만 신경 쓰기 쉬운데, 사실 그 로직이 누구한테까지 열려도 되는지를 결정하는 권한 설계가 같이 따라가야 온전한 마무리가 됩니다. 이 부분은 나중에 Role Naming Rule을 정하는 기준에서 좀 더 자세히 다뤄보겠습니다.
