소버린 AI의 시작은 ‘소버린 데이터’다

By PLURA

요약 한 줄

AI 방어는 데이터 게임입니다. 지금 실패의 본질은 데이터가 없어서고, 정답은 방어용 데이터를 ‘생성’하는 운영 전환입니다.
웹은 요청·응답 본문, 서버는 감사 정책 활성화로 새 로그를 만들어 AI가 일할 자료를 공급해야 합니다.

1) 왜 ‘소버린 데이터’가 방어의 출발점인가

많은 조직이 소버린 AI를 말할 때 먼저 모델을 떠올립니다.
국산 LLM, 자체 추론 엔진, 폐쇄망 AI 같은 키워드가 먼저 나옵니다.

하지만 보안의 현실은 다릅니다.
아무리 좋은 모델도 입력 데이터가 없으면 무능합니다.

보안에서 AI가 제대로 일하려면 최소한 다음이 필요합니다.

  • 공격의 시작점이 보이는 웹 요청·응답 데이터
  • 서버 내부에서 실제로 무슨 일이 일어났는지 보여주는 감사 로그
  • 계정, 권한, 파일, 네트워크, 프로세스가 연결되는 행위 데이터
  • 이를 AI가 바로 이해할 수 있도록 정리한 일관된 스키마

즉, 소버린 AI의 출발점은 모델이 아니라 데이터 주권입니다.

여기서 말하는 소버린 데이터는 단순히 “데이터를 국내에 저장한다”는 뜻이 아닙니다.
그보다 더 중요한 뜻이 있습니다.

우리 스스로 방어에 필요한 데이터를 설계하고, 생성하고, 통제하고, 설명할 수 있어야 한다는 뜻입니다.

이 점이 중요합니다.
생성형 AI 시대의 많은 방어 실패는 모델 부족이 아니라 입력 데이터 부재에서 시작됩니다.
공격자는 이미 자동화되어 있는데, 방어자는 정작 웹 본문도 없고 감사 정책도 꺼져 있고 행위 로그도 빈약합니다.
이 상태에서는 AI가 아니라 사람도 제대로 대응할 수 없습니다.

2) 지금 체계가 실패하는 전형적 패턴

방어가 실패하는 조직에는 공통 패턴이 있습니다.

  • 웹 본문 미수집
    URI, 상태 코드, User-Agent 정도만 있고 POST Body와 Response Body가 없습니다.
    이러면 웹셸 업로드, 인증 우회, 데이터 유출, API 오남용의 핵심 맥락을 놓칩니다.

  • 호스트 가시성 부족
    Windows는 Advanced Audit Policy가 비활성이고, Linux는 auditd나 eBPF 기반 추적이 비어 있습니다.
    결국 “누가 로그인했는가”는 보여도 “무엇을 실행했는가”는 안 보입니다.

  • TLS 가시성 결핍
    WAF, 프록시, 로드밸런서에서 이미 복호화가 일어나는데도, 그 지점에서 본문을 남기지 않습니다.
    가장 잘 보이는 곳에서 아무것도 남기지 않는 셈입니다.

  • PII 우려를 이유로 전면 비수집
    개인정보 문제가 걱정된다는 이유로, 마스킹이나 토큰화 없이 아예 수집하지 않는 선택을 합니다.
    그 결과는 단순합니다. 탐지도 안 되고, 포렌식도 안 됩니다.

  • 스키마 부재
    로그는 많지만 형식이 다르고 필드가 제각각입니다.
    AI가 읽을 수 있는 구조가 아니라, 사람이 grep으로 겨우 찾는 수준에 머뭅니다.

이런 상태에서는 AI가 좋아져도 소용이 없습니다.
AI는 마법이 아니라, 데이터 위에서만 작동하는 엔진이기 때문입니다.

3) 방어용 데이터는 ‘생성’할 수 있다

좋은 소식은 있습니다.
방어용 데이터는 공격자가 만들어 주는 것이 아니라, 우리가 운영으로 생성할 수 있다는 점입니다.

원리는 단순합니다.

  1. 웹

    • 요청(Request)과 응답(Response) 본문을
    • TLS 복호화 경계인 WAF, 리버스 프록시, 애플리케이션 게이트웨이에서
    • 정책적으로 수집합니다.

  2. 서버/호스트

    • 감사 정책을 활성화해
    • 프로세스, 파일, 계정, 네트워크, 권한 행위를
    • 구조화된 이벤트로 생성합니다.

  3. 프라이버시 보호

    • 개인정보와 민감 정보는
    • 마스킹, 토큰화, 해시 처리 후 저장하고
    • AI와 탐지 엔진이 사용할 수 있는 안전한 스키마로 적재합니다.

핵심은 “없던 데이터를 무리하게 만들자”가 아닙니다.
이미 시스템에서 지나가고 있는 중요한 행위를 운영 기준으로 남기자는 것입니다.

4) 웹: 요청·응답 본문 로그 설계

목표:
웹셸 업로드, 경로 우회, RCE, 계정 탈취, 데이터 유출의 증거와 컨텍스트를 본문에서 포착하는 것입니다.

4.1 어디서 캡처할 것인가

권장 우선순위는 다음과 같습니다.

  1. WAF / 리버스 프록시 / 프록시
    • TLS 종료 지점이라 가장 현실적입니다.
  2. 애플리케이션 서버 에이전트
    • 프레임워크 미들웨어 훅을 통해 세밀한 문맥 확보가 가능합니다.
  3. eBPF / PCAP 계열
    • 예외적 포렌식 용도로는 유용하지만, 기본 수집 수단으로는 부담이 큽니다.

4.2 수집 정책

  • 기본 정책
    • POST, PUT, PATCH 요청 본문 수집
  • 고위험 엔드포인트
    • 업로드, 인증, 결제, 관리자 기능은 전량 수집
  • 응답 본문
    • text/*, application/json, application/xml 등은 조건부 전문 보관
  • 대용량 바이너리
    • 전문 저장 대신 SHA-256 해시 + 헤더 + 앞뒤 N바이트 저장

4.3 프라이버시와 보안

  • 카드번호, 주민번호, 세션 토큰 등은 정규식 기반 동적 마스킹
  • 식별자는 비가역 해시로 치환
  • 민감 필드가 감지되면 전문 보관 대신 요약 보관 정책 적용 가능

4.4 권장 스키마 예시

{
  "ts": "2025-09-28T08:15:30.123Z",
  "trace_id": "1f3a...e9",
  "src_ip": "203.0.113.10",
  "dst_host": "app.example.com",
  "method": "POST",
  "url": "/api/upload",
  "status": 200,
  "req_hdr": {"ct":"multipart/form-data", "ua":"..."},
  "req_body": {"len": 5432, "hash": "sha256:...", "snippet_b64": "..."},
  "resp_hdr": {"ct":"application/json"},
  "resp_body": {"len": 321, "hash": "sha256:...", "snippet_b64": "..."},
  "pii_flags": ["email_masked","card_redacted"],
  "waf": {"policy":"post-body-on","action":"allow","signals":["anomaly_upload_ext_dbl"]}
}

4.5 실무 팁

  • 헤더와 바디는 분리 저장하고 trace_id로 연결

  • 평소엔 샘플링하되, 의심 신호가 뜨면 전문 수집으로 승격

  • 압축과 수명주기 정책을 미리 적용

    • 핫 7일 / 웜 30일 / 콜드 180일 등

5) 서버/호스트: 감사 정책으로 로그 생성

웹에서 공격이 들어온 뒤, 실제 피해는 서버 내부에서 일어납니다.
그래서 호스트 가시성이 빠지면 AI는 절반만 보게 됩니다.

5.1 Windows: Advanced Audit Policy + Sysmon

목표: 실행, 권한 상승, 계정 변경, 지속성, 네트워크, 파일 변조의 연쇄 증거화

필수 감사 정책

  • Account Logon / Logon: 성공·실패
  • Detailed Tracking: Process Creation
  • Object Access: 고가치 경로에 한해 파일·레지스트리
  • Policy Change / Privilege Use / System
  • Directory Service Access(AD 환경)

빠른 적용 예시

auditpol /set /category:"Logon/Logoff" /success:enable /failure:enable
auditpol /set /subcategory:"Process Creation" /success:enable
reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f

Sysmon 핵심 이벤트

  • 1: Process Create
  • 3: Network Connect
  • 7: Image Load
  • 10: Process Access
  • 11: File Create
  • 12/13: Registry Add / Set
  • 15: FileStream
  • 17/18: Pipe Created / Connected
  • 22: DNS
  • 23/24: File Delete / Detected

권장: 서명 정책, CLM, WDAC와 함께 운영하면
“무엇이 허용된 실행인가”를 명확히 할 수 있어
잡음을 줄이고 이상행위를 더 선명하게 드러낼 수 있습니다.

5.2 Linux: auditd + journald + 선택적 eBPF

Windows가 감사 정책과 Sysmon으로 가시성을 확보한다면,
Linux는 auditd를 기본축으로 삼고 필요시 journald와 eBPF를 보강하는 방식이 현실적입니다.

핵심은 “다 남기기”가 아니라 공격과 직결되는 행위만 구조적으로 남기기입니다.

auditd 기본 규칙 방향

  • 프로세스 실행 추적

    • execve 호출 추적

  • 권한 변경 감시

    • setuid, setgid, sudo, su

  • 계정 파일 감시

    • /etc/passwd
    • /etc/shadow
    • /etc/group
    • /etc/sudoers

  • 지속성 지점 감시

    • cron, systemd service, authorized_keys

  • 웹루트 쓰기 감시

    • /var/www/, /srv/www/ 등

  • 보안 설정 변경 감시

    • 방화벽, SSH 설정, 네트워크 설정 파일

예시 규칙

-a always,exit -F arch=b64 -S execve -k exec
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k privilege
-w /root/.ssh/authorized_keys -p wa -k persistence
-w /var/www/ -p wa -k webroot_write

journald에서 꼭 챙길 것

  • SSH 인증 성공/실패
  • 서비스 재시작
  • 비정상 종료
  • cron 실행
  • sudo 사용
  • kernel 경고
  • container runtime 이벤트

eBPF는 어디에 쓰는가

eBPF는 강력하지만, 기본 운영에서 무조건 먼저 꺼내야 할 카드는 아닙니다.
다음처럼 보강 지점으로 쓰는 것이 적절합니다.

  • auditd만으로 부족한 프로세스·네트워크 상관분석
  • 컨테이너 환경의 짧은 생명주기 이벤트 추적
  • 고성능 환경에서 선택적 포렌식 캡처

즉, Linux의 현실적 기본선은
auditd로 구조적 로그를 만들고, journald로 운영 이벤트를 보완하며, 필요할 때 eBPF를 얹는 구조입니다.

5.3 Windows와 Linux의 공통 원칙

운영체제는 달라도 원칙은 같습니다.

  • 프로세스 실행을 남긴다
  • 권한 변화를 남긴다
  • 파일 변경을 남긴다
  • 네트워크 연결을 남긴다
  • 지속성 흔적을 남긴다
  • 웹 이벤트와 호스트 이벤트를 연결한다

AI는 이 연결성 위에서만 실제 공격 스토리라인을 재구성할 수 있습니다.

6) 품질지표(QoD)와 AI 준비도

좋은 로그는 단순히 많은 로그가 아닙니다.
AI가 실제로 일할 수 있는 데이터여야 합니다.

  • 본문 커버리지

    • 고위험 엔드포인트 전량 수집율

  • 엔티티 충실도

    • user, session, file, hash, dns, url 누락율

  • 연결성

    • 웹 이벤트 ↔ 호스트 이벤트 조인율

  • 탐지 성능

    • MTTD, MTTR, 스토리라인 완결률

  • 프라이버시 적합성

    • 비마스킹 저장률 0% 유지

7) 소버린 AI는 왜 결국 ‘소버린 데이터’인가

여기서 한 가지를 분명히 해야 합니다.

소버린 AI는 단지 “국산 모델을 만들자”는 말로 끝나지 않습니다.
보안에서는 모델보다 먼저 데이터의 생성권과 통제권이 있어야 합니다.

해외 클라우드 LLM이나 외부 AI API를 쓰는 것이 언제나 나쁘다는 뜻은 아닙니다.
문제는 그것에만 의존하는 구조입니다.

  • 웹 본문과 행위 로그를 직접 만들지 못하고
  • 민감 데이터를 외부 API에 의존해 분석하며
  • 탐지 규칙과 분석 맥락도 내부에 축적되지 않는다면

그것은 소버린 AI가 아니라 단지 외부 AI를 빌려 쓰는 운영에 가깝습니다.

진짜 소버린 AI는 다음 순서로 가야 합니다.

  1. 방어용 데이터를 직접 생성한다
  2. 그 데이터를 우리 스키마로 관리한다
  3. 그 위에 AI 분석을 얹는다
  4. 가능한 범위부터 통제 가능한 모델 구조로 옮겨간다

즉, 모델의 국적보다 더 중요한 것은
데이터의 통제권과 방어 지식의 축적권입니다.

8) 실패를 부르는 안티패턴

  • “개인정보 이슈가 있으니 본문은 아예 안 남긴다”

    • 결과: 탐지 불능, 포렌식 불능

  • “로그는 다 모으는데 스키마는 없다”

    • 결과: AI 불가, 운영 복잡도 폭증

  • “TLS 종단이 어디인지 모른다”

    • 결과: 본문 캡처 자체가 불가능

  • “전량 수집만 외치고 압축과 수명주기를 안 잡는다”

    • 결과: 비용 폭탄, 운영 실패

  • “Windows만 보고 Linux는 대충 본다”

    • 결과: 실제 공격 경로 절반이 비어버림

9) 결론 — 데이터를 만들면 AI 방어가 시작된다

AI 방어는 미래의 이야기가 아닙니다.
문제는 모델이 없어서가 아니라, 모델이 읽을 데이터가 없어서 시작조차 못 하고 있다는 점입니다.

그래서 지금 당장 해야 할 일은 분명합니다.

  • 웹에서는 요청·응답 본문을 남겨야 합니다.
  • 서버에서는 감사 정책을 켜서 행위 로그를 생성해야 합니다.
  • Windows와 Linux 모두에서 프로세스·권한·파일·네트워크·지속성을 구조적으로 남겨야 합니다.
  • 그리고 이 데이터를 AI가 바로 사용할 수 있게 정규화하고 연결해야 합니다.

소버린 AI의 진짜 시작은 거대한 모델이 아닙니다.
현장에서 직접 길러낸 소버린 데이터입니다.

데이터를 만들면 가시성이 생깁니다.
가시성이 생기면 탐지가 가능해집니다.
탐지가 가능해지면, 그때부터 비로소 AI가 방어를 시작할 수 있습니다.

부록 A. 운영 체크리스트

  • TLS 종료 지점 식별 및 POST/Response 본문 로깅 가동
  • PII 마스킹·토큰화 정책 적용
  • 스키마 확정 및 trace_id 통일
  • Windows Advanced Audit Policy + Sysmon 핵심 이벤트 적용
  • Linux auditd(execve, 웹루트 쓰기, 계정 파일 감시) + journald 보강
  • 수명주기·압축·성능 가드레일 설정
  • MITRE ATT&CK 룰팩 연동
  • QoD KPI 운영

부록 B. PLURA-XDR와의 연결 예

  • 웹

    • WAF/프록시 본문 캡처 → POST-body 분석 → MITRE 맵핑

  • 호스트

    • Sysmon / auditd → 행위 상관분석 → AI SecOps 에이전트가 격리, 계정 잠금, 티켓 실행

  • 인텔리전스

    • 외부 TI와 내부 탐지 피드백을 결합해 소버린 인텔리전스 강화

PLURA-XDR의 의미는 여기서 분명해집니다.
단순히 로그를 모으는 것이 아니라, 웹 본문과 호스트 행위를 하나의 방어 데이터로 연결하고,
그 위에서 실시간 탐지와 대응, 그리고 AI 기반 분석까지 이어지게 한다는 점입니다.

Tags