Ch7. 사고 대응
탐지부터 복구·재발방지까지 AI 보안사고 대응 런북
사고 대응의 핵심은 완벽한 예측이 아니라 빠른 격리와 신뢰 회복입니다. 실전에서는 기술 조치와 커뮤니케이션 조치가 동시에 움직여야 합니다.
SEV 기준(예시)
| 등급 | 기준 | 대응 SLA |
|---|---|---|
| SEV-1 | 고객 데이터 유출 의심, 핵심 기능 중단 | 15분 내 워룸 구성 |
| SEV-2 | 부분 서비스 장애, 권한 오남용 | 30분 내 대응 개시 |
| SEV-3 | 제한적 오류, 우회 가능 | 당일 내 조치 |
대응 타임라인
초기 60분 운영 흐름
SEV-1 또는 개인정보·고영향 AI 관련 사고가 의심되면 첫 60분 안에 기술 조치와 커뮤니케이션 준비를 병행합니다.
KPI
- 목표: MTTD 30분 이하
- 목표: SEV-1 MTTR 4시간 이하
런북 골격
# Incident Runbook
- Incident ID:
- Severity:
- Suspected Root Cause:
- Containment Action:
- Customer Impact:
- External Communication Plan:
- Recovery Verification:
- Follow-up Owner / Due Date:커뮤니케이션 원칙
- 사실 기반(추정과 확인사항 분리)
- 시간 기반(다음 업데이트 시각 명시)
- 책임 기반(오너/의사결정권자 명시)
LLMOps 사고와의 통합 관리
AI 시스템에서는 보안 사고가 운영 사고로 이어지거나, 반대로 운영 사고가 보안 위협으로 발전할 수 있습니다:
- 품질 저하 → 보안 위협: 모델 성능 저하로 인한 가드레일 우회
- 비용 폭증 → 서비스 거부: 리소스 고갈로 인한 가용성 침해
- 정책 우회 → 데이터 유출: 프롬프트 인젝션을 통한 정보 탈취
통합 워룸 구성 시 보안팀과 ML Platform팀이 공동으로 대응합니다.
AI 특화 사고 유형
AI 시스템 고유 위협
전통적인 보안 사고와 달리, AI 특화 사고는 모델 동작의 비결정성 때문에 탐지와 재현이 어렵습니다. 아래 유형별로 탐지 신호와 초기 대응을 사전에 정의해 두어야 합니다.
| 사고 유형 | 탐지 신호 | 영향 범위 | 초기 대응 | SEV 기준 |
|---|---|---|---|---|
| 모델 탈옥(Jailbreak) | 가드레일 우회 로그 급증, 금지 콘텐츠 생성 탐지 | 서비스 신뢰도, 법적 리스크 | 해당 세션 즉시 차단, 가드레일 규칙 긴급 패치 | SEV-2 (대량 발생 시 SEV-1) |
| 데이터 포이즈닝 | 모델 출력 품질 급변, RAG 소스 무결성 검증 실패 | 모델 정확도, 전체 서비스 품질 | 오염 의심 데이터 소스 격리, 이전 버전 롤백 | SEV-1 |
| 에이전트 폭주(Runaway Agent) | API 호출량 임계치 초과, 비용 이상 급증, 무한 루프 패턴 | 인프라 비용, 서비스 가용성 | 에이전트 프로세스 강제 종료, Rate Limit 즉시 적용 | SEV-2 (비용 임계 초과 시 SEV-1) |
| 프롬프트 탈취(Prompt Leakage) | 응답에 시스템 프롬프트 문구 포함 탐지, 비정상 프롬프트 패턴 | 지적재산, 보안 정책 노출 | 해당 엔드포인트 일시 차단, 프롬프트 난독화 적용 | SEV-2 |
| 모델 환각 악용 | 사용자 신고, 팩트체크 실패율 급증, 허위 정보 기반 행동 보고 | 고객 의사결정 오류, 법적 책임 | 해당 기능 경고 배너 표시, 인간 검토 강제 활성화 | SEV-2 (금융·의료 도메인 SEV-1) |
| PII 유출 | 응답 내 개인정보 패턴 탐지(주민번호, 전화번호 등), DLP 알림 | 개인정보보호법 위반, 과태료 | 해당 모델 서빙 즉시 중단, 유출 범위 로그 확보 | SEV-1 |
시나리오별 런북
모델 탈옥(Jailbreak) 대응 런북
탐지
- Content Safety 필터 우회 로그 모니터링 (임계치: 동일 패턴 3회 이상)
- 금지 카테고리 응답 생성 여부를 실시간 분류 모델로 탐지
- 사용자 신고 채널을 통한 수동 탐지 병행
# 탐지 규칙 예시
alert: jailbreak_attempt_detected
condition: guardrail_bypass_count > 3 within 10m
labels:
severity: warning
team: ai-security격리
- 탈옥 성공 세션의 사용자 토큰 즉시 무효화
- 해당 프롬프트 패턴을 WAF(Web Application Firewall) 차단 목록에 추가
- 동일 패턴을 사용하는 다른 활성 세션 일괄 검색 및 차단
영향 분석
- 탈옥으로 생성된 콘텐츠 전수 조사 (생성 시각, 내용, 노출 범위)
- 외부 유출 여부 확인 (공유 링크, API 응답 캐시 등)
- 동일 취약점을 활용한 추가 시도 존재 여부 로그 분석
복구
- 가드레일 규칙 업데이트 및 긴급 배포
- 유출된 유해 콘텐츠가 캐시에 남아있다면 퍼지(purge) 처리
- 영향받은 사용자에게 사과 및 안내 메시지 발송
재발 방지
- Red Team 테스트에 해당 탈옥 패턴 추가
- 가드레일 레이어 다중화 (입력 필터 + 출력 필터 + 후처리 검증)
- 탈옥 패턴 DB 업데이트 및 자동 탐지 규칙 강화
데이터 포이즈닝 대응 런북
탐지
- RAG 데이터 소스의 무결성 해시 주기적 검증 (매 6시간)
- 모델 출력 품질 메트릭 급변 모니터링 (정확도, 일관성 점수)
- 학습 데이터 파이프라인의 이상 입력 패턴 탐지
# 데이터 무결성 검증 예시
def verify_data_integrity(source_path: str) -> bool:
current_hash = compute_hash(source_path)
stored_hash = get_stored_hash(source_path)
if current_hash != stored_hash:
alert_security_team("Data integrity violation", source_path)
return False
return True격리
- 오염 의심 데이터 소스를 즉시 인덱스에서 제외
- 해당 소스를 참조하는 RAG 파이프라인 일시 중단
- 오염 시점 이후 생성된 모든 응답에 신뢰도 경고 태그 부착
영향 분석
- 오염 데이터가 영향을 미친 시간 범위 특정 (첫 오염 ~ 탐지 시점)
- 해당 기간 동안 생성된 응답 수 및 사용자 수 파악
- 오염 경로 역추적: 외부 크롤링, 사용자 피드백 루프, 내부 파이프라인 등
복구
- 검증된 마지막 스냅샷으로 데이터 롤백
- RAG 인덱스 재구축 (클린 데이터 기반)
- 오염 기간 동안 영향받은 사용자 대상 정정 안내 발송
재발 방지
- 데이터 수집 파이프라인에 입력 검증 레이어 추가
- 데이터 소스별 접근 권한 최소화 (Least Privilege)
- 주기적 데이터 감사(audit) 프로세스 수립 (주 1회 이상)
에이전트 폭주(Runaway Agent) 대응 런북
탐지
- 에이전트별 API 호출 횟수 실시간 모니터링 (분당 임계치 설정)
- 비용 대시보드 이상 급증 알림 (전일 대비 200% 초과 시)
- 동일 작업 반복 패턴 탐지 (루프 카운터 기반)
# 에이전트 Rate Limit 설정 예시
agent_limits:
max_calls_per_minute: 60
max_calls_per_hour: 500
max_cost_per_session_usd: 10
loop_detection_threshold: 5 # 동일 API 연속 호출 횟수격리
- 폭주 에이전트 프로세스 강제 종료 (kill signal)
- 해당 에이전트의 API 키 즉시 비활성화
- 관련 큐/작업 대기열 플러시(flush)
영향 분석
- 폭주 기간 동안 소비된 총 비용 산출 (API 호출 + 컴퓨팅 비용)
- 다른 서비스에 대한 영향 확인 (Rate Limit 공유, 리소스 경합)
- 폭주 원인 분석: 프롬프트 설계 결함, 종료 조건 미비, 외부 API 장애 등
복구
- 에이전트 설정 수정 후 제한된 환경에서 재시작 (Sandbox 모드)
- 비정상 호출로 생성된 데이터 정리 또는 롤백
- 비용 청구 이의 신청 (클라우드 프로바이더)
재발 방지
- 에이전트 실행에 Hard Limit 적용 (최대 실행 시간, 최대 비용)
- Circuit Breaker 패턴 도입 (연속 실패 시 자동 중단)
- 에이전트 행동 로그 정기 감사 프로세스 수립
고객 커뮤니케이션 템플릿
커뮤니케이션 원칙 준수
템플릿은 참고용입니다. 반드시 사실 기반·시간 기반·책임 기반 원칙에 따라 실제 상황에 맞게 수정하세요. 추정과 확인된 사실을 명확히 구분하여 기술합니다.
초기 알림 (사고 인지 후 1시간 이내)
제목: [보안 알림] {사고유형} 관련 안내
{고객사명} 고객님께,
{발생일시}에 당사 AI 서비스에서 {사고유형} 관련 이상 징후가 탐지되었습니다.
■ 현재 상황
- 탐지 시각: {탐지시각}
- 영향 범위: {영향범위}
- 현재 상태: {현재상태} (조사 중 / 격리 완료 / 복구 진행 중)
■ 조치 내역
- {조치내역_1}
- {조치내역_2}
■ 향후 계획
- 다음 업데이트 예정 시각: {다음업데이트시각}
- 대응 책임자: {담당자명} ({연락처})
정확한 원인이 파악되는 대로 상세 보고를 드리겠습니다.
불편을 드려 대단히 죄송합니다.
{회사명} 보안팀 드림상세 보고 (사고 해소 후 24시간 이내)
제목: [보안 보고] {사고유형} 사후 분석 보고서
{고객사명} 고객님께,
{발생일시} 발생한 {사고유형} 사고에 대한 상세 분석 결과를 안내드립니다.
■ 사고 개요
- 사고 유형: {사고유형}
- 발생 일시: {발생일시}
- 해소 일시: {해소일시}
- 총 영향 시간: {영향시간}
■ 근본 원인
{근본원인_상세}
■ 영향 범위
- 영향받은 사용자 수: {영향사용자수}
- 영향받은 서비스: {영향서비스}
- 데이터 유출 여부: {유출여부}
■ 대응 타임라인
- {시각1}: {대응내역1}
- {시각2}: {대응내역2}
- {시각3}: {대응내역3}
■ 재발 방지 대책
- 단기 조치 (완료): {단기조치}
- 중기 조치 ({완료예정일}까지): {중기조치}
- 장기 조치 ({완료예정일}까지): {장기조치}
■ 보상 안내
{보상내용}
추가 문의사항이 있으시면 {담당자명} ({연락처})로 연락 부탁드립니다.
{회사명} 보안팀 드림규제기관 보고 체크리스트
법적 보고 의무
보고 시한을 넘길 경우 추가 과태료가 부과될 수 있습니다. 사고 인지 즉시 법무팀과 협의하여 보고 대상 여부를 판단하세요.
| 보고 대상 | 보고 시한 | 필수 포함 항목 | 근거 법령 |
|---|---|---|---|
| KISA (한국인터넷진흥원) | 사고 인지 후 24시간 이내 | 침해사고 개요, 피해 현황, 대응 조치, 향후 계획 | 정보통신망법 제48조의3 |
| 개인정보보호위원회 | 72시간 이내 (정보주체 통지: 지체 없이) | 유출 항목, 유출 시점, 대응 조치, 피해 구제 방법, 담당자 연락처 | 개인정보보호법 제34조, 제39조의4 |
| 금융감독원 | 사고 인지 즉시 (전자금융 관련) | 사고 내용, 원인, 피해 규모, 대응 현황, 재발 방지 대책 | 전자금융거래법 제21조의3 |
| 과학기술정보통신부 / AI 기본법 지원 창구 | 고영향 AI·생성형 AI 관련 중대 피해 의심 시 즉시 법무 검토 후 상담·보고 여부 판단 | AI 시스템 명칭, 고영향 AI 해당 여부, 사고 유형, 피해 범위, 조치 사항 | 인공지능기본법·시행령 및 하위 가이드라인 |
| 공정거래위원회 | 소비자 피해 발생 시 지체 없이 | 피해 내용, 원인, 보상 계획 | 소비자기본법 제52조 |
Tabletop Exercise 가이드
실전 훈련의 중요성
실제 사고에서 런북을 처음 펼쳐보는 것과, 훈련을 통해 이미 익힌 상태로 대응하는 것은 MTTR에서 평균 40% 이상의 차이를 보입니다. 분기 1회 이상 Tabletop Exercise를 수행하세요.
시나리오 선정
과거 사고 이력, 업계 동향, 새로 도입된 AI 기능을 기반으로 훈련 시나리오를 선정합니다. 아래 추천 시나리오 표를 참고하여 우선순위를 정합니다.
참여자 구성
- 필수 참여: 보안팀, ML Platform팀, DevOps팀, 법무팀
- 권장 참여: 고객지원팀, 경영진(SEV-1 시나리오), PR/커뮤니케이션팀
- 역할 배정: Incident Commander, Tech Lead, Communications Lead, Scribe
상황 주입
시나리오 진행자(Facilitator)가 시간 순서대로 상황을 주입합니다.
- T+0: 초기 탐지 알림 전달
- T+15min: 추가 정보 공개 (영향 범위 확대 등)
- T+30min: 외부 요인 주입 (언론 문의, 규제기관 연락 등)
- T+60min: 예상치 못한 전개 (2차 사고, 복구 실패 등)
대응 실행
참여자들이 런북에 따라 실제 대응 절차를 시뮬레이션합니다.
- 의사결정 과정을 모두 기록
- 실제 도구(Slack 채널, 대시보드 등)를 활용
- 시간 압박 하에서의 판단력 훈련에 집중
추천 훈련 시나리오
| 시나리오 | 난이도 | 주요 훈련 목표 | 권장 빈도 |
|---|---|---|---|
| 대규모 Jailbreak 공격 (SNS 확산) | 상 | 위기 커뮤니케이션, 긴급 패치 | 반기 1회 |
| RAG 데이터 오염 (내부자 위협) | 상 | 데이터 무결성 검증, 롤백 절차 | 반기 1회 |
| 에이전트 폭주로 인한 클라우드 비용 폭증 | 중 | 비용 모니터링, Circuit Breaker | 분기 1회 |
| PII 유출 (모델 응답에 개인정보 포함) | 상 | 규제 보고, 고객 통지 | 분기 1회 |
| 프롬프트 인젝션을 통한 시스템 프롬프트 탈취 | 중 | 탐지·격리 속도, 프롬프트 보안 | 분기 1회 |
| 모델 환각으로 인한 금융 자문 오류 | 중 | 도메인별 팩트체크, 고객 커뮤니케이션 | 반기 1회 |
| 공급망 공격 (모델 서빙 인프라 침해) | 상 | 인프라 격리, 포렌식 절차 | 연 1회 |
Incident Cost 추정
사고 대응 성숙도 모델
조직의 사고 대응 역량은 단계적으로 성숙해야 합니다. 현재 조직의 위치를 파악하고 다음 단계로의 로드맵을 수립하세요.
| 성숙도 단계 | 핵심 특징 | 전환 조건 |
|---|---|---|
| 반응형(Reactive) | 사고 발생 시 임기응변 대응, 동일 사고 반복 | 런북 작성, 역할 정의 |
| 정의형(Defined) | 표준 절차 존재, 훈련 시작 | MTTD/MTTR 측정 시작, 분기별 훈련 |
| 관리형(Managed) | KPI 기반 개선, 자동화 탐지·격리 | 위협 인텔리전스 구축, 선제적 Red Team |
| 예측형(Predictive) | 위협 예측 및 선제 조치, AI 기반 자동 대응 | 지속적 개선 문화 정착 |
완료 산출물
Ch7 완료 기준
이 장을 적용한 뒤에는 SEV 기준표, Incident Runbook, 워룸 역할표, 고객 커뮤니케이션 템플릿, 규제기관 상담·보고 체크리스트, Tabletop Exercise 기록, RCA/CAP 목록이 남아 있어야 합니다.