상용 DLP 없이 개인정보 지키기: 리눅스 기반 오픈소스 DLP 운영 가이드

리눅스 + 오픈소스 DLP의 현실적인 목표

상용 엔드포인트 DLP처럼

• “파일을 USB/웹/메일로 내보내는 순간 실시간 차단”
• “화면 캡처, 클립보드, 인쇄까지 통합 통제”

를 오픈소스 + 리눅스에서 완전히 동일하게 구현하는 건 사실상 불가능에 가깝습니다.

온프레미스 리눅스 + OSS 환경에서는 보통 이렇게 목표를 잡는 게 현실적입니다.

1. 어디에 민감정보가 있는지 계속 찾아내고(Discovery)
2. 누가 그 데이터에 접근·복사·전송했는지 커널 레벨로 감사(Audit)
3. 이상 행위를 중앙에서 탐지·알림(SIEM/HIDS)
4. 가능한 채널(예: AI API, Proxy, Git, SFTP 등)에서 “텍스트/파일 내용” 기반 유출 패턴을 검사
5. 조직 정책과 권한 구조를 함께 정비

아래는 이 목표를 위해 쓸 수 있는 현실적인 오픈소스 구성입니다.

전체 아키텍처 개요

1. 레퍼런스 아키텍처

┌────────────────────────────────────────────┐
│              중앙 관리/관제 서버           │
│                                            │
│  Wazuh Manager + Indexer(ES) + Dashboard  │
│  ┌──────────────┐                          │
│  │ Rule/Policy  │                          │
│  │  Mgmt        │                          │
│  └──────────────┘                          │
│         ▲                                   │
└─────────┼───────────────────────────────────┘
          │
   Syslog / Wazuh Agent / API
          │
┌─────────┼─────────┬─────────┬────────────┐
│         │         │         │            │
│  Linux Server 1  ...      Linux Server N │
│  ───────────────────────────────────────  │
│  - Wazuh Agent                            │
│  - auditd + rules                         │
│  - DLP Scanner (gitleaks, YARA, ripgrep)  │
│  - (옵션) Falco/eBPF                      │
│  - (옵션) AI Proxy Client (HTTP Proxy)    │
└────────────────────────────────────────────┘

2. 데이터/채널 관점으로 나누기

1. 저장 데이터(DAR : Data at Rest)
   • 서버 디스크, 공유 디렉토리, 로그 파일, 백업 파일 등
     → gitleaks / YARA / 자체 스캐너로 “어디에 어떤 민감정보가 있는지” 지속 스캔
2. 전송 데이터(DIT : Data in Transit)
   • scp, sftp, rsync, https, git push, 메일 발송, AI API 요청 등
     → auditd + Wazuh + 프록시/게이트웨이 로그로 “누가 어떤 데이터를 내보냈는지” 모니터링
3. 사용 중 데이터(DIU : Data in Use)
   • 프로세스의 메모리, 터미널 출력, 클립보드 등
     → 리눅스에선 제일 어렵고, 현실적으로는 권한 최소화 + 명령 로그 + TTY 세션 기록 + sudo 사용 기록 수준으로 접근

오픈소스 구성요소별 역할 정리

1. 민감정보 스캐닝(Discovery)

① Gitleaks / TruffleHog

원래는 Git 저장소의 API 키, 비밀번호 검출에 특화된 도구지만, 정규식을 커스터마이즈해서 주민번호, 전화번호, 이메일, 계좌번호 등도 충분히 탐지할 수 있습니다.

• 설치 예시 (단일 서버)

  wget https://github.com/gitleaks/gitleaks/releases/download/v8.18.2/gitleaks_8.18.2_linux_x64.tar.gz
  tar -xzf gitleaks_8.18.2_linux_x64.tar.gz
  mv gitleaks /usr/local/bin/

• 간단 스캔 스크립트 예시 (/opt/dlp/gitleaks-scan.sh)

  #!/usr/bin/env bash
  
  TARGET_DIRS="/home /var/www /data"
  REPORT_DIR="/var/log/dlp"
  CONFIG="/opt/dlp/gitleaks-config.toml"
  
  mkdir -p "$REPORT_DIR"
  
  DATE=$(date +"%Y%m%d-%H%M%S")
  REPORT_FILE="$REPORT_DIR/gitleaks-report-$DATE.json"
  
  gitleaks detect \
    --source "$TARGET_DIRS" \
    --config "$CONFIG" \
    --report-path "$REPORT_FILE" \
    --report-format json

• cron 등록 예

  # 매일 새벽 2시 실행
  0 2 * * * /opt/dlp/gitleaks-scan.sh

• 개인정보 패턴 설정 예 (gitleaks-config.toml 일부)

  [[rules]]
  id = "Korean-Resident-Registration-Number"
  description = "Korean RRN (주민등록번호)"
  regex = '''\b[0-9]{6}-[1-4][0-9]{6}\b'''
  severity = "high"
  
  [[rules]]
  id = "Korean-Phone-Number"
  description = "Korean mobile phone number"
  regex = '''\b01[0-9]-?[0-9]{3,4}-?[0-9]{4}\b'''
  severity = "medium"

② YARA / ripgrep + 정규식

• YARA : 룰 파일을 작성해서 특정 패턴이 포함된 파일을 찾는 데 사용.
• ripgrep (rg) : 가볍고 빠른 grep 대체제. 특정 디렉토리 스캔용으로 좋음.

300x250

예: rg로 주민번호 패턴 찾기

rg -n --hidden --pcre2 '\b[0-9]{6}-[1-4][0-9]{6}\b' /home /var/www > /var/log/dlp/rrn-found-$(date +%F).log

2. 행위/접근 감사: Linux Auditd

auditd는 커널 레벨에서 “누가, 언제, 어떤 파일을, 어떤 syscall로 건드렸는지” 기록합니다.

① 기본 설치

# RHEL/CentOS
yum install audit

# Ubuntu/Debian
apt-get install auditd audispd-plugins

systemctl enable --now auditd

② 민감 디렉토리 접근 감사 규칙 예시

예를 들어 /data/pii에 고객 개인정보 파일이 있다면

/etc/audit/rules.d/20-sensitive-files.rules

# /data/pii 디렉토리 읽기/쓰기/실행/속성 변경 감시
-w /data/pii -p rwxa -k pii_access

반영 후

augenrules --load
service auditd restart

• 로그 조회 예

  ausearch -k pii_access -ts today
  ausearch -k pii_access -ts yesterday -i

③ 명령 사용 감사 (scp, rsync 등)

# /usr/bin/scp 실행 감시
-a always,exit -F path=/usr/bin/scp -F perm=x -S execve -k scp_exec

# /usr/bin/rsync 실행 감시
-a always,exit -F path=/usr/bin/rsync -F perm=x -S execve -k rsync_exec

이를 통해 언제 누가 scp/rsync를 실행했는지 추적 가능하고, Wazuh 쪽에서 특정 사용자 + 특정 디렉토리와 연계해 “잠재 유출 시도” 룰을 만들 수 있습니다.

3. 중앙 통합 분석·경보: Wazuh (강력 추천)

Wazuh는

• HIDS(OSSEC 기반)
• FIM(File Integrity Monitoring)
• 로그 수집/분석
• 규정 준수 체크(SCA)

를 통합 제공하는 오픈소스입니다.

① Wazuh Agent에서 FIM 설정 예

/var/ossec/etc/ossec.conf (에이전트 측)

<syscheck>
  <frequency>3600</frequency>        <!-- 1시간마다 스캔 -->
  <directories check_all="yes">/data/pii</directories>
  <directories check_all="yes">/etc</directories>
  <ignore>/data/pii/tmp</ignore>
</syscheck>

② auditd + Wazuh 연동

auditd 로그를 Wazuh가 ingest하면, 아래와 같은 룰을 사용할 수 있습니다.

예: /var/ossec/etc/rules/local_rules.xml

<group name="dlp,pii,linux">

  <!-- auditd에서 pii_access 키가 기록되면 경보 -->
  <rule id="100100" level="10">
    <if_group>audit</if_group>
    <match>pii_access</match>
    <description>PII Directory accessed (auditd)</description>
    <group>dlp,pii,suspicious</group>
  </rule>

  <!-- scp 실행 + pii_access가 연달아 발생하면 더 높은 경보 -->
  <rule id="100101" level="12">
    <if_same_source_ip />
    <if_matched_sid>100100</if_matched_sid>
    <match>scp_exec</match>
    <description>PII directory accessed and scp executed</description>
    <group>dlp,exfiltration,critical</group>
  </rule>

</group>

이렇게 하면

• /data/pii 읽기 → pii_access 발생
• 곧이어 scp 실행 → scp_exec 발생
• 두 이벤트를 묶어서 “개인정보 디렉토리 접근 후 scp 실행”이라는 유출 의심 패턴으로 경보 가능.

4. eBPF 기반 실시간 행위 탐지: Falco (선택)

Falco는 eBPF/커널 모듈을 이용하여 실시간 프로세스/시스템 콜 이벤트를 룰 기반으로 탐지합니다.

예를 들어,

• /data/pii에 있는 파일을 curl이나 ssh 프로세스가 읽을 때,
• 특정 UID/GID 계정이 대량 파일을 짧은 시간에 읽을 때,

를 규칙으로 만들어 유출 시도로 간주할 수 있습니다.

네트워크/Proxy/AI 채널 모니터링

이제 핵심인 “AI에 의해 외부로 전달되는 정보 모니터링” 관점입니다.

1. 문제 정의

• 개발자/운영자/보안담당자가
  • ChatGPT, Claude, Gemini, Copilot 등에
  • 이슈/로그/쿼리/DB 덤프/코드/설계 문서 등을 그대로 붙여넣는 경우
• 내부에서 만든 봇이나 툴이 외부 LLM API (OpenAI, Anthropic, Google 등)를 호출하며
  • 로그, 고객 데이터, 시스템 설정 내용을 그대로 prompt에 실어 보내는 경우

→ 이 모든 것이 “DLP 관점의 새로운 유출 채널”입니다.

2. 기술적인 통제 전략

① HTTPS Egress Control (기본)

1. 모든 서버의 외부 HTTPS는 Proxy/TLS-inspection 장비를 통해서만 나가게 설정
   • 시스템 레벨 Proxy (http_proxy, https_proxy)
   • iptables / nftables 정책 (직접 외부로 443 나갈 수 없게 차단)
   • 특정 방화벽/Proxy에서만 api.openai.com, api.anthropic.com, generativelanguage.googleapis.com 등 허용
2. Proxy 로그 분석 + DLP 룰 적용
   • 목적 도메인, URI, 요청량, 계정 단위로 baseline을 만들고
   • 비정상적으로 큰 요청 Body, 너무 많은 호출, 이상 시간대 호출 패턴 모니터링

② AI Gateway / LLM Proxy 도입 (권장)

가능하면 모든 외부 LLM 호출을 내부에서 한 번 더 프록시하는 구조를 추천합니다.

[서버/앱/사용자] ─▶ [내부 AI Gateway] ─▶ [외부 LLM API]

- 내부 게이트웨이:
  - 요청 Body 로그/마스킹
  - 정규식/YARA를 통한 민감정보 탐지
  - 정책에 따라 BLOCK or MASK or ALLOW

• 내부 Gateway에서는:
  • prompt/input에 대해 주민번호/계좌번호/전화번호/내부 도메인/시스템명 등 패턴 탐지
  • 탐지 시
    • 요청을 Drop 또는 Mask 처리
    • Wazuh/SIEM으로 “AI_DLP_HIT” 이벤트 전송
• 실질 구성 예:
  • Python FastAPI or Node.js + Reverse Proxy
  • requests 또는 httpx로 외부 LLM API 호출 전/후에 content 검사
  • 내부 시스템에는 이 Gateway의 URL만 제공 (직접 OpenAI URL 사용 금지)

예시(개념용) Python 코드 스니펫

import re
from fastapi import FastAPI, Request, HTTPException
import httpx

app = FastAPI()

RRN_REGEX = re.compile(r'\b[0-9]{6}-[1-4][0-9]{6}\b')

OPENAI_API_URL = "https://api.openai.com/v1/chat/completions"
OPENAI_API_KEY = "..."

@app.post("/llm/openai")
async def proxy_openai(request: Request):
    body = await request.json()

    prompt_text = str(body)
    if RRN_REGEX.search(prompt_text):
        # TODO: Wazuh or SIEM으로 알림 전송 로직
        raise HTTPException(status_code=400, detail="Sensitive data detected in prompt")

    async with httpx.AsyncClient(timeout=60) as client:
        headers = {"Authorization": f"Bearer {OPENAI_API_KEY}"}
        resp = await client.post(OPENAI_API_URL, json=body, headers=headers)
        return resp.json()

이걸 내부 표준 LLM Endpoint로 쓰게 하고, 직접 OpenAI/Anthropic URL을 쓰는 건 방화벽/Proxy에서 차단하는 구조를 만드는 것이 좋습니다.

③ Web Proxy + ICAP 기반 DLP

조직에 HTTP Proxy(Squid 등)를 운영하고 있다면

• HTTP/HTTPS 트래픽의 Request/Response Body를 ICAP 서버로 넘겨
• 거기서 텍스트/파일에 대한 DLP 검사를 수행할 수 있습니다.

이 경우도 마찬가지로

• 주민번호, 카드번호, 이메일, 고객ID 패턴 정규식
• 특정 키워드(“고객 DB dump”, “전체 로그”, “쿼리 결과 100만건” 등) 기반 룰

을 적용 가능하지만, HTTPS에 대해선 TLS 복호화/재암호화 구조가 필요하므로 조직 정책·법적 이슈를 고려해야 합니다.

보안 가이드 & 점검 포인트

1. 정책·프로세스 측면

1. 민감정보 분류 정책
   • “개인정보/민감정보/중요정보”의 정의
   • 필드 레벨(예: 이름, 연락처, 주민번호, 계좌번호, 로그인 ID 등)로 분류
   • 어느 경로로 다닐 수 있고, 어디에 저장되면 안 되는지 정의
2. AI 사용 가이드라인
   • “외부 AI에 절대 붙여넣으면 안 되는 정보”를 명시
   • 예
     • 고객 원본 로그, DB 덤프
     • 주민번호, 계좌번호, 연락처가 포함된 데이터
     • 내부 시스템의 전체 설정 파일(예: nginx.conf 전체, vault.hcl 등)
     • API 키/비밀번호/암호화 키
   • 내부 교육 + 정기 리마인드 + 위반 사례 공유(익명화)
3. 권한 관리 / 계정 관리
   • 운영 서버에 SSH 접속 가능한 계정 최소화
   • sudo 사용 강제 + sudo 로그 중앙 수집
   • root 직접 로그인 금지
   • Bastion/Jump 서버를 통한 접근 통합

2. 기술적 점검 포인트 (리눅스 서버 기준)

1. 민감정보 디스커버리
   • /home, /var/www, /data, 공유 디렉토리 등에 대해 gitleaks/rg/YARA 스캔이 정기적으로 수행되는가
   • 스캔 리포트가 중앙에 모여 관리되고 있는가 (예: Wazuh/ES Index)
2. 파일 접근 감사
   • /data/pii와 같은 민감 디렉토리에 auditd 규칙이 설정되어 있는가
   • scp/rsync/ftp 등 데이터 이동 명령에 대해 audit 규칙이 있는가
   • audit 로그가 중앙으로 수집되고 있는가
3. 중앙 모니터링(Wazuh/ELK 등)
   • “PII 접근 후 scp 실행” 등 유출 의심 시나리오 룰이 정의되어 있는가
   • 경보가 Slack/메일로 실제 도달하고 관리자가 확인하는 절차가 있는가
4. 네트워크/Proxy/AI 채널
   • 서버/개발자 PC에서 외부 LLM API로 직접 나가는 트래픽이 차단 혹은 통제되는가
   • 내부 AI Gateway를 통해서만 외부 LLM을 사용할 수 있도록 강제되어 있는가
   • Gateway/Proxy에서 LLM 요청 Body를 DLP 룰로 검사하는가
   • LLM 사용 로그(사용자, 목적, 데이터 유형)가 보존되는가
5. 운영 절차
   • 민감정보 스캔에서 새로운 발견이 있을 때의 처리 프로세스(격리/암호화/삭제)가 존재하는가
   • 매 분기/반기마다 DLP 룰(정규식, 키워드, AI 정책)을 리뷰·업데이트하는가
   • 모의 유출 시나리오(레드팀/블루팀 테스트)를 통해 실제 탐지 여부를 검증하는가

간단한 “엔드 투 엔드” 예시 시나리오

시나리오 A – 개발자가 개인정보 파일을 scp로 외부 서버로 전송 시도

1. /data/pii/customers.csv 파일에 고객 주민번호/연락처가 포함되어 있음
2. 야간 gitleaks 스캔 결과, 해당 파일이 민감정보 포함 파일로 레이블링 → Wazuh에 인덱싱
3. auditd 규칙: /data/pii 디렉토리에 대한 read/write/execute 감시
4. 개발자가 scp /data/pii/customers.csv dev@1.2.3.4:/tmp 실행
5. auditd
   • pii_access (파일 read)
   • scp_exec (scp 실행) 기록
6. Wazuh 룰
   • 같은 소스 IP/사용자에서 pii_access 후 scp_exec 발생 → level 12 경보
7. Slack 알림
   • “개인정보 디렉토리 접근 후 scp 실행 감지 – 사용자: dev01, 호스트: app-01”
8. 보안팀
   • 해당 사용자/서버 접속 기록 확인
   • 사유 확인 및 필요 시 계정 잠금, 파일 삭제/격리 조치

시나리오 B – 내부 봇이 LLM API로 로그를 전송하려다 DLP에 걸림

1. 개발팀에서 “에러 로그 요약 봇” 개발
   • 로그 일부를 prompt로 LLM에 보내 요약 결과 반환
2. LLM 호출은 내부 AI Gateway(/llm/openai)를 통해서만 가능
3. Gateway에서 prompt에 아래 패턴 탐지
   • 주민번호/전화번호
   • customer_id=1234567890와 같은 내부 고객 ID 패턴
4. 탐지 시
   • LLM 호출 차단 (HTTP 400 응답)
   • Wazuh로 “AI_DLP_HIT” 이벤트 전송
   • Slack 알림: “LLM 프롬프트에 고객 식별자 포함 – 서비스: log-summary-bot, 서버: app-02”
5. 이후
   • 개발팀에 “로그 필터링/마스킹” 요구
   • 예: customer_id, phone 필드는 ***로 마스킹 후 전송하도록 수정

온프레미스 환경 리눅스 서버 OSS DLP의 현실적인 운영 모델

1. “완벽한 차단”보다 “조기 탐지 + 강력한 감사 + 최소 권한”에 집중
2. 민감정보 스캐닝(gitleaks/YARA/ripgrep)으로 “어디에 뭐가 있는지”를 항상 최신 상태로
3. auditd + Wazuh/Falco로 “누가 뭘 어떻게 했는지”를 세밀하게 추적
4. 네트워크/Proxy + AI Gateway로 새로운 채널(외부 LLM, SaaS)에 대한 DLP 룰 적용
5. 조직 정책·가이드·교육을 병행해서 내부 사용자 행동을 함께 통제