질문 역사
기업 ERP 구현은 종종 규제 기한을 맞추기 위해 신속한 사용자 정의로 인해 기술 부채를 축적합니다. 이 시나리오에서는 개발 환경을 위한 전송 요청이 비판적인 월말 기간 동안 실수로 생산으로 라우팅되었습니다. 이로 인해 단일 개인이 공급업체 결제를 생성하고 승인하는 것을 방지하는 ABAP 사용자 종료에 내장된 의무 분리를 비활성화했습니다.
문제
즉각적인 위기는 세 가지 겹치는 제약 조건을 포함합니다. SOX 준수 위반은 감사 리스크 및 잠재적인 SEC 공개 요구 사항을 초래합니다. BW/4HANA 종속성으로 인해 거래 시스템을 롤백하면 경영진이 수익 발표에 사용하는 재무 보고 큐브가 손상될 수 있습니다. 또한 4시간 기한은 월말 마감 프로세스가 활성 실행 중일 때 전통적인 철저한 회귀 테스트를 방지합니다.
해결책
프로토콜은 즉시 "코드 동결 분류" 절차를 활성화해야 합니다. 첫째, 취약성 창 동안 발생하는 모든 거래를 캡처하기 위해 비상 변경 로깅을 구현합니다. 둘째, 버전 관리(SE10)를 사용하여 compliance-critical code만 복구하는 선별적인 ABAP 복원을 실행합니다. 셋째, SAP GRC (Governance, Risk, and Compliance) 소방관 로그를 사용하여 노출 기간 동안 정책 위반이 발생하지 않았는지 검증하기 위해 병렬 유효성을 검사합니다. 마지막으로, 두 번째 분석가가 모든 결제 배치를 검토하는 임시 수동 제어 우회 방법을 설정합니다. 자동화된 제어가 완전히 검증될 때까지 기다립니다.
컨텍스트 및 문제 설명
한 글로벌 제약회사는 회계 연도 마감 작업을 완료하고 있었는데, 한 하위 관리자가 SAP 전송 DEVK900042를 품질 보증 대신 직접 생산으로 실행했습니다. 이 전송은 공급업체 마스터 데이터 증강 지점 EXIT_SAPMF02K_001에 대한 수정 사항을 포함하고 있어 실수로 SOX 섹션 404 통제를 적용하는 사용자 정의 ABAP 로직을 덮어썼습니다. 동시에 BW/4HANA 시스템은 분기 수익 보고서를 위한 데이터를 추출하고 있었으며, 이로 인해 비준수 시스템에서 금융 데이터가 스냅샷으로 캡처되는 12시간의 창이 열렸습니다. CIO는 전송을 롤백하면 추출이 취소되고 수익 보고가 지연되지만 이를 활성 상태로 두면 회사의 내부 통제 인증을 위반하는 딜레마에 직면했습니다.
해결책 A: 비상 전송 복원
기술팀은 즉시 트랜잭션 STMS를 실행하여 DEVK900042의 복원 전송을 가져올 수 있으며, 이로써 30분 이내에 이전 ABAP 코드 버전을 복원할 수 있습니다.
장점: 이 접근 방식은 준수 노출 창을 최소화하고 표준 SAP 변경 관리 절차를 따릅니다. 데이터베이스 테이블 내에서 수동 개입이 필요하지 않으며 자동 전환 메커니즘을 통해 시스템 무결성을 유지합니다.
단점: 복원은 데이터베이스 롤백을 촉발하여 현재 실행 중인 BW/4HANA 델타 초기화를 무효화시켜 재무 큐브의 6시간 재로드를 강요하고 SEC 제출 마감일을 놓칠 수 있습니다. 또한 노출 창 동안 새로운 공급업체 레코드가 생성된 경우, 롤백으로 인해 SAP ECC와 AP 보조 원장 간의 참조 무결성을 위반하는 고아 항목이 생길 수 있습니다.
해결책 B: 즉각적인 배포가 가능한 핫픽스 전송
개발자는 SOX 제어 로직을 새 전송으로 수동으로 재구성하고 원래 변경을 뒤로 돌리지 않고 즉시 배포할 수 있습니다. 이는 오류 위에 수정 사항을 쌓는 것입니다.
장점: 이 방법은 BW/4HANA의 추출에 필요한 데이터 연속성을 보존하고 데이터베이스 롤백 문제를 피합니다. 월말 마감이 중단 없이 진행되도록 하면서 준수 통제를 복원할 수 있습니다.
단점: 4시간의 비상 압박 하에 새로운 ABAP 코드를 생성하고 테스트하는 것은 구문 오류 또는 논리 결함이 발생할 위험을 크게 늘립니다. SIT (System Integration Testing)에서 적절한 단위 테스트 없이 핫픽스가 추가적인 의무 분리 충돌이나 공급업체 마스터 배치 작업의 성능 저하를 일으킬 수 있습니다.
해결책 C: 선택적 버전 복원 및 병행 모니터링
팀은 ABAP 버전 관리(SE80)를 사용하여 준수 로직이 포함된 특정 포함 프로그램만 이전 버전에서 복원하고 나머지 전송의 정당한 버그 수정 사항은 그대로 유지할 수 있습니다.
장점: 이 외과적 접근 방식은 BW/4HANA에 필요한 데이터 일관성을 유지하는 동시에 즉각적으로 SOX 통제를 복원합니다. 월말 마감이 계속 진행될 수 있으며 원전송의 유익한 부분을 보존하고** SAT**(ABAP Runtime Analysis)를 사용하여 복원이 확인될 수 있습니다. 이는 전체 시스템 재시작 없이 제어 로직이 실행되고 있음을 확인합니다.
단점: 이는 표준 전송 경로 외부에서 생산 코드 객체를 직접 수정해야 하므로 감사 추적 격차가 생깁니다. 이 절차는 증강 프레임워크에 대한 깊은 지식을 가진 고급 ABAP 개발자를 요구하며, 실수는 공급업체 마스터 데이터 구조를 손상시킬 수 있습니다.
선택한 해결책 및 정당화
팀은 해결책 C를 선택했습니다. 이는 중재적인 SOX 준수 요구 사항을 충족하면서 BW/4HANA 추출 일정에 disruption을 일으키지 않았기 때문입니다. 감사 추적 문제는 유효했지만, 팀은 즉시 긴급 변경 요청 티켓을 생성하여 버전 복원을 소급적으로 문서화했습니다. CIO와 CFO가 회사의 긴급 변경 정책에 따라 이중 승인을 제공했습니다. 선택적 복원은 실행 및 검증에 45분 걸렸습니다. 해결책 A에서 위험한 6시간 지연에 비해 매우 효율적이었습니다.
결과
SOX 통제가 저녁 11:30에 복원되었으며, 노출 창 동안 처리된 거래는 47개에 불과했습니다. GRC 소방관 로그는 이 기간 동안 의무 분리 위반이 없었음을 드러냈습니다. BW/4HANA 추출은 오전 2시에 성공적으로 완료되었으며, 회사는 분기 수익을 예정대로提交하였습니다. 사건 이후 비즈니스 분석가는 이제 월말 블랙아웃 기간 동안 어떤 생산 수입에도 기능 팀 리더와 준수 담당자의 CR(변경 요청) 승인을 요구하는 자동화된 SolMan(SAP 솔루션 관리자) 전송 제어 워크플로를 만들었습니다.
표준 전송 문서를 우회하는 비상 코드 변경을 실행할 때 요구 사항 추적을 어떻게 유지합니까?
위기 상황에서는 표준 Jira 또는 SAP Charm 워크플로가 너무 오랜 시간이 걸리는 경우가 많습니다. 후보자는 종종 사후에 문서화만 하도록 제안하는데, 이는 사전 승인이 필요로 하는 SOX 감사 요건을 충족하지 못합니다. 올바른 접근 방식은 CAB(변경 자문 위원회) 의장이 타임스탬프가 찍힌 이메일 또는 ServiceNow 긴급 티켓을 통해 기록된 임시 구두 승인을 부여하는 "긴급 변경 브릿지"를 수립하는 것입니다. 이는 감사 추적을 생성하면서 즉각적인 조치를 가능하게 합니다. 추가로, 분석가는 변경된 코드 줄을 정확히 보여주는 SE80 버전 비교 스크린 녹화를 캡처하여 영구 변경 기록에 첨부해야 합니다.
복원된 재무 통제가 실제로 특정 의무 분리 위반을 방지하는지 어떻게 검증합니까?
대부분의 후보자는 개발 환경에서 단위 테스트를 실행하는 것을 제안하지만, 이는 프로덕션에서 존재하는 데이터 특정 엣지 케이스를 무시합니다. robust 방법은 SAP GRC 액세스 관리의 비상 액세스 관리를 활용하여 "가정-어떤" 시뮬레이션을 생성하는 것입니다. 분석가는 상충하는 역할(공급자 생성자와 승인자 모두)을 가진 임시 소방관 ID를 생성한 후, 디버그 모드에서 commit work 문을 주석 처리한 생산 클라이언트에서 테스트 공급자를 처리하려고 시도합니다. 이는 복원된 ABAP 코드가 권한 실패(sy-subrc <> 0)를 올바르게 유발하여 테스트 데이터를 지속하지 않도록 검증합니다. 그런 다음 ST22 단기 덤프 로그를 검토하여 예상된 권한 확인 실패가 발생했는지 확인하여 감사자에게 제어 효과성을 기술적으로 입증합니다.
문서가 존재하지 않는 경우 ABAP 사용자 종료와 하류 BW/4HANA 추출 작업 간의 기술적 종속성을 어떻게 매핑합니까?
후보자들은 종종 기술 소유자와의 인터뷰를 제안하지만 긴급 상황에서는 이러한 개인이 이용할 수 없을 수 있습니다. 체계적인 접근 방식은 BW의 RSA1을 사용하여 현재 실행 중인 InfoPackages를 식별한 다음, SM37 배경 작업 로그를 통해 SAP ECC 추출 작업을 추적하는 것입니다(일반적으로 RSA3 또는 사용자 정의 LBWE 추출기). 사건 중 SM12 잠금 항목을 분석하여 공급업체 마스터 데이터 테이블(LFA1, LFB1)이 추출 프로세스에 의해 잠금 상태인지 확인하여 롤백이 DUMP 오류를 초래할 수 있음을 알 수 있습니다. 또한 BW 추출의 ST05 SQL 추적을 검토하면 어떤 ABAP 증강 지점이 트리거되고 있는지를 정확히 밝혀내어, 실시간 종속성 맵을 생성하여 향후 참조를 위해 Confluence에 보존할 수 있습니다.