SM19 비활성화 금지 — 감사 로그 30초 설정 #shorts #SAP #Security

왜 SM19를 지금 다시 이야기해야 하는가

SAP 시스템을 운영하면서 "누가, 언제, 어떤 계정으로, 어떤 트랜잭션을 실행했는가"라는 질문에 답할 수 없다면 감사·규제 대응은 물론이고 침해 사고 발생 시 원인 추적이 사실상 불가능합니다. 이 글은 SAP NetWeaver AS ABAP 7.5x 이상 환경에서 Security Audit Log(SAL)를 설계·활성화·분석·자동화까지 이어가는 과정을 실전 관점에서 다룹니다. 특히 SUIM/STAD 같은 다른 로그만으로는 채워지지 않는 "권한 있는 계정의 이상 행위"를 잡아내는 방법을 중심에 둡니다.

SAL의 구조와 SM19/RSAU_CONFIG의 차이 이해
필터·이벤트 클래스 설계 및 성능 영향 최소화
SM20/RSAU_READ_LOG로 이상 징후 탐색
SIEM 연계용 CSV/Syslog 추출 파이프라인 구성
운영 중 흔한 실수와 회피 전략 습득

글을 읽기 전에 갖춰두면 좋은 배경

ABAP 스택의 프로파일 파라미터(rz10/rz11) 개념, SUIM/SU01 기반 사용자 관리, 트랜잭션 코드 실행 흐름(다이얼로그/RFC/배치)에 대한 기본 이해가 필요합니다. 또한 감사 요구사항 측면에서 SOX, ISO 27001, K-ISMS 등에서 요구하는 "특권 계정 모니터링" 개념을 알고 있으면 필터 설계 근거를 잡기 쉽습니다. 파일 시스템 권한과 OS 레벨 rsau 디렉터리 접근 권한 개념도 도움이 됩니다.

준비 환경과 버전별 차이

이 글에서 다루는 환경은 다음과 같습니다.

SAP NetWeaver AS ABAP 7.52 SP04 이상 (S/4HANA 1909, 2020, 2022, 2023 포함)
Kernel 7.53 patch level 400 이상 권장 (Kernel Parameter 방식 지원)
필수 트랜잭션: SM19(레거시 UI), RSAU_CONFIG(신규 UI, 7.50+), SM20/RSAU_READ_LOG, SM18/RSAU_ADMIN
권한: S_ADMI_FCD (AUDA/AUDD), S_TCODE(SM19, SM20), S_RSAU_ADM(신규)
디스크: 감사 파일 저장을 위해 최소 5GB 이상 여유(대형 시스템은 100GB 이상)

NetWeaver 7.50부터는 SM19가 RSAU_CONFIG로 대체되고 있으며, 7.52 이후에는 파일 기반 로그 외에 데이터베이스 테이블 RSAU_BUF_DATA 저장 옵션이 추가되어 실시간 분석에 유리합니다. 다만 DB 저장은 트랜잭션 로그 증가를 유발하므로 도입 전 DBA 검토가 필요합니다.

SAL의 내부 동작 원리와 SM19의 위치

Security Audit Log는 커널 레벨에서 특정 이벤트(로그온, 트랜잭션 시작, RFC 호출, 사용자 마스터 변경 등)를 캡처해 애플리케이션 서버 인스턴스별로 로컬 파일에 기록하는 구조입니다. 파일 경로는 프로파일 파라미터 rsau/local/file에 정의되며, 기본값은 각 인스턴스의 /usr/sap/<SID>/<INSTANCE>/log/audit_<YYYYMMDD> 형태입니다.

비유하자면 SM19는 CCTV의 "녹화 스케줄러", SM20은 "재생기"입니다. SM19에서 어떤 카메라(사용자/클라이언트/이벤트 클래스)를 언제(정적/동적 프로파일), 어떤 화질(상세/요약)로 녹화할지 정의하고, SM20에서 특정 시간대·계정의 녹화본을 재생·필터링합니다.

이벤트 클래스는 크게 다음으로 나뉩니다.

Dialog Logon(성공/실패), Password change
Transaction/Report Start
RFC Function Call, RFC Logon
User Master Record Change(SU01)
System Events(파일 다운로드, Debug/Replace 등 고위험 활동)

정적 프로파일(Static Profile)은 인스턴스 재시작 시 자동 적용되고, 동적 프로파일(Dynamic)은 즉시 적용되지만 재시작 시 사라집니다. 운영에서는 동적으로 검증한 뒤 정적으로 승격시키는 2단계 전략이 안전합니다.

1단계: 최소 설정으로 감사 로그 켜기

가장 먼저 시스템 파라미터를 확인하고 감사 기능을 활성화합니다. RZ11에서 다음 파라미터를 조회합니다.

* RZ11에서 확인할 핵심 파라미터
rsau/enable              = 1        " 감사 로그 활성화
rsau/selection_slots     = 10       " 필터 슬롯 개수 (기본 2, 권장 10)
rsau/user_selection      = 1        " 사용자 필터 활성화
rsau/local/file          = /usr/sap/<SID>/<INSTANCE>/log/audit_+
rsau/max_diskspace/local = 1000M    " 인스턴스당 최대 용량

파라미터를 영구 반영하려면 RZ10에서 DEFAULT 프로파일을 편집하고 인스턴스 재시작을 예약합니다. 이후 SM19(또는 RSAU_CONFIG)에서 최초 프로파일을 만듭니다.

* 프로파일 이름: ZAUD_BASELINE
* Filter 1
Client   : *
User     : SAP*, DDIC, EARLYWATCH
Events   : 모든 심각도(Critical + Important + Non-Critical)
* Filter 2
Client   : 100, 200
User     : *
Events   : Critical only (로그온 실패, SU01 변경, Debug/Replace)

여기서 첫 필터는 표준 특권 계정을 감시하고, 두 번째 필터는 일반 사용자에 대해서는 위험 이벤트만 잡아 볼륨을 억제합니다. Activate 버튼으로 동적 적용 후 SM20에서 즉시 이벤트가 남는지 확인합니다.

2단계: 실무 시나리오 — 고위험 트랜잭션 추적과 알림

실제 감사에서는 "SE16으로 BSEG 테이블을 직접 조회한 사용자"나 "SM30으로 T000을 수정한 사용자" 같은 구체적 시나리오를 잡아야 합니다. 이를 위해 이벤트 코드 AU3(트랜잭션 시작)와 AUW(Debug/Replace), AUZ(RFC) 조합을 활용합니다.

REPORT z_sal_hotlist_extract.

DATA: lt_result TYPE STANDARD TABLE OF rsau_alert_log,
      ls_filter TYPE rsau_read_log_options.

ls_filter-datum_von = sy-datum - 1.
ls_filter-datum_bis = sy-datum.
ls_filter-uzeit_von = '000000'.
ls_filter-uzeit_bis = '235959'.
ls_filter-mandant   = sy-mandt.

" 고위험 트랜잭션 리스트
DATA(lt_hot_tcodes) = VALUE stringtab(
  ( `SE16` ) ( `SE16N` ) ( `SE38` ) ( `SM30` )
  ( `SM49` ) ( `SU01` ) ( `PFCG` ) ( `STMS` ) ).

CALL FUNCTION 'RSAU_READ_LOG'
  EXPORTING
    ir_options = ls_filter
  IMPORTING
    et_result  = lt_result
  EXCEPTIONS
    no_data    = 1
    OTHERS     = 2.

IF sy-subrc <> 0.
  MESSAGE |감사 로그 읽기 실패: { sy-subrc }| TYPE 'E'.
ENDIF.

LOOP AT lt_result ASSIGNING FIELD-SYMBOL(<fs>)
     WHERE slgsubid = 'AU3'.
  IF line_exists( lt_hot_tcodes[ table_line = <fs>-parameter1 ] ).
    WRITE: / <fs>-slgtime, <fs>-slguser,
             <fs>-parameter1, <fs>-slgterminal.
  ENDIF.
ENDLOOP.

이 리포트를 SM36으로 일 1회 배치 실행하고, 결과가 있으면 BCS(SO_NEW_DOCUMENT_SEND_API1)로 보안팀 메일링 리스트에 자동 발송하도록 확장하면 최소한의 SIEM 없는 알림 체계가 완성됩니다.

3단계: 프로덕션 — 성능·보존·SIEM 연계

대규모 시스템(사용자 5000명 이상)에서는 감사 로그가 하루 수 GB까지 증가할 수 있습니다. 다음 프로덕션 관점을 반영해야 합니다.

# SAL 운영 표준 (예시)
retention:
  online_days: 30        # 인스턴스 디스크 보관
  archive_days: 400      # 외부 스토리지(WORM) 보관
  legal_hold: true
rotation:
  strategy: daily
  compress: gzip
  post_hook: /sap/scripts/ship_to_siem.sh
filter_profile:
  name: ZAUD_PROD
  slots:
    - {client: '*', user: 'SAP*,DDIC', events: all}
    - {client: '100', user: '*', events: critical}
    - {client: '*', user: '*', events: [AU5, AUW, AUK]}  # SU01, Debug, RFC 실패
performance:
  expected_events_per_hour: 250000
  disk_iops_min: 3000

SIEM(예: Splunk, QRadar, Sentinel) 연계는 두 가지 방식이 일반적입니다. 첫째, OS 레벨에서 rsau 파일을 tail하여 Universal Forwarder로 전달. 둘째, ABAP에서 RSAU_READ_LOG로 5분 단위 폴링 후 HTTP(S) 엔드포인트로 JSON 전송.

METHOD ship_to_siem.
  DATA: lo_http    TYPE REF TO if_http_client,
        lv_payload TYPE string.

  cl_http_client=>create_by_url(
    EXPORTING url = 'https://siem.corp.local/sap/ingest'
    IMPORTING client = lo_http ).

  lv_payload = /ui2/cl_json=>serialize( data = it_events
                                        pretty_name = /ui2/cl_json=>pretty_mode-camel_case ).

  lo_http->request->set_header_field( name = 'Content-Type' value = 'application/json' ).
  lo_http->request->set_header_field( name = 'X-SAP-SID'   value = sy-sysid ).
  lo_http->request->set_cdata( lv_payload ).
  lo_http->send( ).
  lo_http->receive( ).

  DATA(lv_status) = lo_http->response->get_header_field( '~status_code' ).
  IF lv_status <> '200'.
    " 재시도 큐에 적재
    INSERT VALUE ztsal_retry(
      guid = cl_system_uuid=>create_uuid_x16_static( )
      payload = lv_payload
      created_at = cl_abap_context_info=>get_system_time( )
    ) INTO TABLE @DATA(ls_dummy).
  ENDIF.
ENDMETHOD.

보안 관점에서는 rsau 파일 자체가 침해 대상이 될 수 있으므로 OS 레벨에서 <sid>adm 외 계정의 write 권한을 제거하고, 가능하면 append-only 파일시스템(예: chattr +a)이나 WORM 스토리지로 즉시 복제해야 합니다.

운영 중 자주 부딪히는 문제와 해결

Q1. SM19에서 프로파일을 Activate했는데 SM20에 아무것도 안 잡힙니다.

가장 흔한 원인은 rsau/enable이 0으로 남아있는 경우입니다. RZ11에서 현재 값과 프로파일 값이 다를 수 있으므로 두 값을 모두 확인하세요. 또한 필터의 Client가 특정 값으로 고정되어 있고 실제 이벤트가 다른 클라이언트에서 발생 중일 수 있습니다. 별표(*)를 사용하되 볼륨 폭증에 유의합니다.

Q2. 감사 파일이 디스크를 가득 채워 인스턴스가 다운됐습니다.

rsau/max_diskspace/local을 반드시 설정하고, 별도 파일시스템(마운트 포인트)에 rsau 디렉터리를 두는 것이 권장됩니다. SM18(RSAU_ADMIN)로 오래된 파일 자동 삭제 잡을 SM36 정기 스케줄에 등록하세요. 다만 삭제 전 반드시 외부 아카이브 완료를 확인해야 합니다.

Q3. 이벤트가 너무 많아 SM20 조회 시 타임아웃이 발생합니다.

SM20 대신 RSAU_READ_LOG(트랜잭션/리포트)를 사용하고, 필터를 시간·클라이언트·이벤트 클래스로 좁혀 조회하세요. 7.52 이상에서는 DB 저장 옵션(rsau/ipc/*) 활성화 후 CDS 뷰 기반 분석이 훨씬 빠릅니다.

Q4. RFC 이벤트가 폭증합니다.

일반적으로 인터페이스 계정(예: BATCH_RFC)의 함수 호출은 볼륨이 큽니다. 이벤트 클래스 AUK/AUZ에서 해당 계정을 제외하되, 로그온 실패(AU2)와 권한 오류(AUM)는 반드시 유지해야 이상 징후를 놓치지 않습니다.

여기서 더 나아가려면

SAL만으로는 데이터 접근(SELECT/UPDATE) 자체를 잡을 수 없습니다. HANA 감사 로그(AUDIT POLICY), Read Access Logging(RAL, 개인정보 필드 접근 추적), UCON(RFC 화이트리스트)과 함께 3계층 감사 체계를 구성하는 것을 권장합니다. 또한 SAP GRC Access Control과 Enterprise Threat Detection(ETD)을 도입하면 규칙 기반 실시간 상관분석이 가능해집니다. 조직 규모가 크지 않다면 오픈소스 Wazuh + Filebeat 조합으로도 실용적인 SAP 보안 모니터링을 구축할 수 있습니다.

더 읽어볼 만한 자료

댓글 0