241. 중요 정보 접근 — 접근·유출 로그의 정규화와 수집

시스템 보안 · 취약점 › E. 중요 정보 접근 로그 분석 · 41/50편 (전체 241/450)
학습 단계: 접근·유출 로그 분석
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

• 240. 중요 정보 접근 — 접근→수집→유출 연계 분석
• 193. 권한 변경 로그의 정규화와 수집(D영역)

1. 개념

접근·유출 탐지를 자동화하려면, 세 종류 로그(OS 파일 감사·DB 로그·네트워크)를 공통 필드로 정규화해 중앙 수집해야 합니다. 서로 다른 형식의 로그를 통합해야 접근→수집→유출 연계(E40)가 가능합니다.

접근·유출 로그 통합 파이프라인
 [소스]
  OS: auditd(파일 접근) → 주체·대상·시각
  DB: query log → 쿼리·테이블·접속
  NET: 방화벽·프록시·NetFlow → 목적지·전송량
 [정규화] 공통 필드: actor·resource·action·dest·bytes
 [저장] Elasticsearch / Wazuh indexer
 [활용] 연계 룰·타임라인·대시보드(E45)

세 로그를 통합해야 "누가(OS) 무엇을(DB) 어디로(NET) 얼마나(bytes)" 보냈는지 하나의 사건으로 봅니다.

2. 왜 중요한가

• 접근(OS)·조회(DB)·유출(NET)은 서로 다른 로그라, 통합 정규화가 연계의 전제입니다.
• 공통 필드(actor·resource·dest·bytes)가 있어야 세 단계를 한 체인으로 상관합니다.
• 중앙 수집은 로컬 로그 변조(D17)에도 원본을 보존합니다.

3. 핵심 명령어 / 설정

로그 소스	제공 정보	정규화 필드
auditd(OS)	주체·대상·시각	actor·resource
DB query log	쿼리·테이블	query·table
방화벽·프록시	목적지·포트	dest·port
NetFlow	전송량	bytes
통합	체인 상관	session·actor

4. 실습 (실습 예시)

# 접근·유출 로그 정규화·수집 (분석 방법)
# OS 감사 수집(Wazuh agent — audit)
# DB 로그 수집(localfile mysql log)
# 네트워크 로그 수집(방화벽·프록시 syslog)
# 정규화 검증(wazuh-logtest)
echo 'type=SYSCALL ... key="sensitive_read" name="/etc/shadow"' | sudo /var/ossec/bin/wazuh-logtest
# 통합 검색 예: actor + resource + dest (ELK)
# audit.auid:devops AND (file:shadow OR dest_ip:외부)

5. 정상 상태

$ (정규화 결과)
audit.auid: devops  audit.file: /etc/shadow  audit.key: sensitive_read
→ OS·DB·NET 로그가 공통 필드로 정규화됨(연계 가능)

세 로그가 공통 필드로 정규화되어 하나의 세션·주체로 상관 가능한 상태가 정상입니다.

6. 이상 상태

$ (정규화 실패 예시)
DB 로그 미수집 → 엔진 경유 접근(E23) 탐지 공백
NET 로그 미수집 → 유출 목적지·전송량 불명

• DB 로그 미수집 → 쿼리 경유 접근(E23·24) 탐지 불가
• 네트워크 로그 미수집 → 유출 목적지·규모 파악 불가
• 로그 소스 누락 = 연계 분석 불가 → 탐지 공백

7. 로그 분석 (분석 방법)

접근·유출 로그 통합 흐름입니다(가상의 예시).

[OS auditd] 누가·무엇을 접근
   +
[DB log] 어떤 쿼리·테이블
   +
[NET log] 어디로·얼마나 전송
   ↓ (공통 필드 정규화)
[통합] session·actor 기준 상관
   ↓
[연계 룰] 접근→수집→유출(E40)·타임라인(E39)

소스	없으면
OS	파일 접근 공백
DB	엔진 경유 공백
NET	유출 목적지 공백

세 소스를 모두 통합해야 완전한 접근·유출 가시성이 확보됩니다.

8. SOC 관제 포인트

• 접근·유출 탐지는 OS·DB·네트워크 로그를 공통 필드로 정규화·통합해야 자동화됩니다.
• 공통 필드(actor·resource·dest·bytes)가 세 단계 연계(E40)의 전제입니다.
• 로그 소스 누락은 탐지 공백이므로 세 소스를 모두 수집합니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_e,normalize,">
  <!-- 접근·유출 로그 통합 정규화 기반 -->
  <rule id="104400" level="4">
    <field name="audit.key" type="pcre2">sensitive_read|cred_access|data_access|exfil</field>
    <description>접근·유출 로그 정규화(통합 상관 기반)</description>
  </rule>
</group>

OS·DB·네트워크 디코더를 모두 구성하고 wazuh-logtest로 필드 추출을 검증합니다. 세 소스 수집이 연계의 전제입니다.

10. 대응 방법

1. 초기 확인 — OS·DB·네트워크 세 로그 소스의 수집·정규화 상태를 확인합니다.
2. 범위 확인 — 공통 필드(actor·resource·dest·bytes) 추출과 상관 가능 여부를 확인합니다.
3. 증거 확보 — 정규화된 통합 로그와 검증 결과를 보존합니다.
4. 차단/조치 — 누락 소스는 수집·디코더를 구성해 탐지 공백을 메웁니다.
5. 재발 방지 — OS·DB·네트워크 통합 로그 파이프라인을 운영합니다.

11. 핵심 정리

로그 소스	제공 정보
auditd(OS)	주체·대상·시각
DB query log	쿼리·테이블
방화벽·프록시	목적지·포트
NetFlow	전송량
면접 포인트	"접근·유출은 OS+DB+NET 통합 정규화가 연계의 전제 — 누락은 탐지 공백"

12. 다음 편 예고

다음 편 242. 중요 정보 접근 — 접근·유출 이벤트 상관분석 에서는 접근·유출 이벤트 상관분석을 다루는 접근·유출 이벤트 상관분석을 다룹니다.

---

이전 편: 240. 중요 정보 접근 — 접근→수집→유출 연계 분석
📚 시리즈 전체 보기: 시스템 보안 · 취약점