219. 중요 정보 접근 — 데이터베이스 파일 직접 접근 탐지

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

선행 학습

• 218. 중요 정보 접근 — 중요 파일 접근 이상 종합 분석
• 213. DB 설정·자격증명 파일 접근 탐지

1. 개념

3단계는 DB·대량 데이터 접근을 다룹니다. 첫 번째는 DB 데이터 파일 직접 접근입니다. 공격자는 DB 엔진(쿼리)을 거치지 않고 데이터 파일 자체를 복사해, DB 감사 로그를 우회하며 전체 데이터를 탈취합니다.

DB 데이터 파일 직접 접근 위험
 MySQL: /var/lib/mysql/*.ibd, ibdata1 (테이블 데이터)
 PostgreSQL: /var/lib/pgsql/data/base/*
 MongoDB: /var/lib/mongodb/*.wt
 SQLite: *.db, *.sqlite 파일

우회 효과: DB 쿼리 로그 안 남김 → 은밀한 전체 탈취
정상: DB 엔진(mysqld·postgres)만 접근

DB 파일은 DB 엔진만 접근하는 것이 정상입니다. 쉘 명령(cp·tar)의 접근은 엔진 우회 탈취로 명백한 이상입니다.

2. 왜 중요한가

• DB 파일 직접 복사는 쿼리 로그를 우회해 은밀하게 전체 데이터를 탈취합니다.
• DB 엔진 외 프로세스의 데이터 파일 접근은 정상 운영에 없어 명확한 이상입니다.
• 파일을 다른 곳에서 열면 전체 테이블을 복원할 수 있어 대량 유출로 직결됩니다.

3. 핵심 명령어 / 설정

DB 데이터 파일	엔진	위험
/var/lib/mysql/*.ibd	MySQL	테이블 데이터
ibdata1	MySQL	공유 테이블스페이스
pgsql/data/base/*	PostgreSQL	전체 DB
mongodb/*.wt	MongoDB	컬렉션
*.db/*.sqlite	SQLite	전체 DB

4. 실습 (실습 예시)

# DB 데이터 파일 직접 접근 탐지 (분석 방법)
# DB 데이터 디렉터리 접근(엔진 외)
sudo ausearch -k data_access -i --start recent 2>/dev/null | grep -E '/var/lib/(mysql|pgsql|mongodb)' | grep -vE 'comm="(mysqld|postgres|mongod)"' | tail

# DB 파일 복사·전송
sudo ausearch -k data_access,exfil -i --start recent 2>/dev/null | grep -E 'comm="(cp|tar|scp|rsync)"' | grep -E 'mysql|pgsql|\.ibd|\.db'

5. 정상 상태

$ (DB 파일 접근) (없음 또는 엔진만)

DB 데이터 파일 접근이 DB 엔진(mysqld·postgres)에 의해서만 발생하고, 쉘의 복사·전송이 없는 상태가 정상입니다.

6. 이상 상태

$ (DB 파일 접근)
04:00 comm="tar" auid=devops /var/lib/mysql → /tmp/db.tar
04:01 comm="cp" auid=devops /var/lib/pgsql/data/base → 복사

• MySQL 데이터 디렉터리 전체를 tar로 압축 → DB 엔진 우회 전체 탈취
• PostgreSQL base 복사 → 전체 DB 파일 탈취
• DB 엔진이 아닌 쉘의 데이터 파일 접근·복사 → 정탐(최고 위험)

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

DB 파일 직접 탈취 흐름입니다(가상의 예시 로그).

type=SYSCALL comm="tar" auid=devops key="data_access"
type=PATH name="/var/lib/mysql/appdb/users.ibd"
 → DB 엔진 우회, 데이터 파일 직접 압축(쿼리 로그 안 남김)
[이후] /tmp/db.tar 유출 → 다른 곳에서 복원 → 전체 데이터

관찰	해석
tar /var/lib/mysql	데이터 파일 압축
comm≠mysqld	엔진 우회
쿼리 로그 없음	은밀
이후 유출	전체 탈취

엔진 우회 파일 접근은 DB 쿼리 감사로는 안 잡히므로 파일 접근 감사가 필수입니다.

8. SOC 관제 포인트

• DB 데이터 파일 직접 접근은 DB 엔진·쿼리 로그를 우회한 전체 탈취입니다.
• 정상은 DB 엔진만 접근 — 쉘의 복사·압축·전송은 명백한 이상입니다.
• 쿼리 감사로는 안 잡히므로 파일 접근 감사(data_access)가 필수 탐지 수단입니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_e,data_access,">
  <rule id="104180" level="13">
    <if_sid>104000</if_sid>
    <field name="audit.file" type="pcre2">/var/lib/(mysql|pgsql|mongodb)/|\.(ibd|frm|wt)$</field>
    <field name="audit.comm" type="pcre2">^(cp|tar|scp|rsync|cat|dd|gzip|zip)$</field>
    <description>DB 데이터 파일 직접 접근(엔진 우회 전체 탈취)</description>
    <mitre><id>T1005</id></mitre>
  </rule>
</group>

정상 DB 엔진(mysqld·postgres·mongod)은 제외합니다. 파일 접근 후 유출을 상관으로 연계합니다.

10. 대응 방법

1. 초기 확인 — 접근된 DB 데이터 파일·주체·방법과 엔진 여부를 확인합니다.
2. 범위 확인 — 데이터 디렉터리 전체 압축·복사·이후 유출을 확인합니다.
3. 증거 확보 — DB 파일 접근 이벤트와 대상 데이터 범위를 보존합니다.
4. 차단/조치 — 엔진 우회 탈취 정탐이면 전송 차단·세션 종료·전체 데이터 유출 조사를 진행합니다.
5. 재발 방지 — DB 데이터 파일 직접 접근 탐지를 운영합니다.

11. 핵심 정리

DB 파일	위험
*.ibd/ibdata1	MySQL 테이블 데이터
pgsql base	PostgreSQL 전체
mongodb .wt	컬렉션
엔진 우회	쿼리 로그 없는 탈취
면접 포인트	"DB 파일 직접 접근은 엔진·쿼리 로그 우회 — 파일 접근 감사로만 포착"

12. 다음 편 예고

다음 편 220. 중요 정보 접근 — 데이터베이스 덤프 생성 탐지 에서는 데이터베이스 덤프 생성을 다루는 데이터베이스 덤프 생성 탐지를 다룹니다.

---

이전 편: 218. 중요 정보 접근 — 중요 파일 접근 이상 종합 분석
📚 시리즈 전체 보기: 시스템 보안 · 취약점