05. 보안 사고 초기 대응 상세

이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.

• 보안 사고를 감지한 직후 첫 시간에 무엇을 보존하고 무엇을 차단해야 하는가?
• 서버 재시작, 로그 삭제, 비밀키 회전 같은 조치를 어떤 순서로 판단해야 하는가?
• 사고 대응 기록은 이후 보고서와 재발 방지로 어떻게 이어지는가?

개요

보안 사고 초기 대응의 목표는 완벽한 원인 분석이 아니다. 첫 단계에서는 추가 피해를 줄이고, 증거를 보존하고, 영향 범위를 좁히고, 사용자 보호 조치를 시작해야 한다.

사고가 의심되면 운영자는 흔히 서버 재시작, 로그 삭제, 계정 일괄 잠금, secret 전체 회전처럼 큰 조치를 떠올린다. 이런 조치는 필요할 수 있지만 순서가 틀리면 증거를 잃거나 정상 사용자 피해를 키운다.

초기 대응은 detect, analyze, contain, eradicate, recover, post-incident로 이어지는 긴 흐름의 시작이다. 첫 기록이 이후 법무, 고객지원, 개발, 운영, 보안팀의 공통 타임라인이 된다.

이 문서의 핵심은 “침착하게 대응한다”가 아니라 “증거 보존과 피해 제한을 동시에 실행할 runbook을 미리 갖춘다”는 것이다.

공격 시나리오

• 관제에서 refresh token 재사용과 여러 계정의 비정상 결제 시도를 감지한다.
• 운영자가 원인을 확인하려고 서버를 재시작해 메모리와 임시 파일 증거를 잃는다.
• 로그를 줄이기 위해 debug log를 삭제하면서 사고 시간대 원본 로그가 사라진다.
• 전체 사용자 세션을 즉시 무효화해 정상 사용자 피해와 고객지원 폭증이 발생한다.
• 유출된 secret이 의심되지만 어떤 서비스가 사용하는지 몰라 rotation이 지연된다.
• 사용자 통지와 내부 보고 기준이 없어 외부 커뮤니케이션이 늦어진다.

취약한 요청/응답 예시

10:02 WARN token_reuse_detected user=1004
10:05 INFO restarted api-1
10:06 INFO cleared old logs
10:08 WARN payment_high_risk user=1004

incident note: "이상해서 재시작함. 원인은 나중에 확인."

재시작과 로그 삭제가 먼저 이루어져 증거가 줄었다. 누가 어떤 판단으로 어떤 범위를 차단했는지도 남아 있지 않다.

주제별 핵심 판단

• 초기 대응은 증거 보존과 추가 피해 차단을 동시에 한다.
• 모든 조치는 시간, 실행자, 근거, 영향 범위를 남긴다.
• 원본 로그와 snapshot은 별도 보존하고 분석은 사본으로 수행한다.
• containment는 전체 중단보다 영향 범위 기반으로 시작한다.
• secret rotation, session revocation, account lock은 blast radius를 따져 순서화한다.
• 사용자 통지와 법적 보고 필요성은 조직 정책과 관할 요구를 따라 별도 판단한다.
• 사고 종료 후 post-incident review와 재발 방지 backlog가 필요하다.

개선된 요청/응답 예시

level=INFO event=incident_declared result=opened incidentId=SEC-2026-071 actor=oncall:lee severity=high reason=token_reuse_and_payment_attempts startedAt=2026-07-01T10:02:00Z traceId=1b2a9d04

level=INFO event=incident_containment_action result=applied incidentId=SEC-2026-071 actor=oncall:lee action=disable_refresh_for_affected_accounts affectedAccounts=18 evidenceSnapshot=s3://evidence/sec-2026-071/10-10 traceId=1b2a9d04

사고 대응 자체도 감사 로그다. 어떤 근거로 어떤 범위의 조치를 했는지 나중에 설명할 수 있어야 한다.

방어 설계

• severity 기준과 incident commander 역할을 미리 정한다.
• 증거 보존 checklist를 둔다. access log, application log, DB audit, cloud audit, WAF log, provider log, deployment history를 포함한다.
• 사고 시간대를 UTC 기준으로 고정한다.
• containment option을 준비한다. affected account session revoke, token denylist, feature flag off, rate limit tighten, key rotation, network isolation을 구분한다.
• 조치 전후 영향을 기록한다.
• 사용자 보호 조치와 고객지원 macro를 준비한다.
• 외부 보고와 사용자 통지는 법무/개인정보 담당자와 함께 판단한다.
• 복구 후에는 root cause, detection gap, prevention task, owner, due date를 남긴다.

Spring/HTTP 예시

public void containTokenReuse(IncidentId incidentId, List<MemberId> affectedMembers) {
    evidenceService.snapshotLogs(incidentId, affectedMembers, Duration.ofHours(2));
    tokenService.revokeRefreshTokens(affectedMembers);
    audit.recordIncidentAction(
        incidentId,
        "revoke_refresh_tokens",
        "token_reuse_detected",
        affectedMembers.size()
    );
}

public void addDenyRule(IncidentId incidentId, AbuseRule rule) {
    abuseRuleService.enable(rule);
    audit.recordIncidentAction(
        incidentId,
        "enable_abuse_rule",
        rule.id(),
        rule.estimatedImpact()
    );
}

초기 대응 코드는 보안팀 전용 도구일 수 있지만, 실제 제품 기능과 연결되는 조치에는 감사 이벤트가 필요하다.

운영 로그와 감사 지점

level=INFO event=evidence_snapshot_created result=allowed incidentId=SEC-2026-071 sources=access,app,db-audit,waf timeRange=2026-07-01T09:00Z/2026-07-01T10:30Z storage=evidence-vault traceId=1b2a9d04

level=WARN event=incident_action_failed result=error incidentId=SEC-2026-071 action=rotate_jwt_key reason=dependent_service_not_ready rollback=not_started traceId=1b2a9d04

• incident id는 모든 대응 로그에 들어간다.
• 증거 snapshot은 원본 보존과 접근 권한을 분리한다.
• containment action은 affected scope와 expected user impact를 남긴다.
• 실패한 대응 조치도 숨기지 않고 기록한다.
• 사고 대응 중 log level 변경과 feature flag 변경도 감사 대상이다.

실전 판단 기준

• 서버 재시작은 증거를 잃을 수 있으므로 먼저 snapshot 가능성을 본다.
• 전체 세션 무효화는 강력하지만 정상 사용자 영향이 크다.
• secret rotation은 준비 없이 하면 장애를 만들 수 있다.
• 로그 삭제는 사고 대응이 아니라 증거 훼손이 될 수 있다.
• containment는 완벽한 원인 분석을 기다리지 않아도 되지만 근거와 범위를 기록해야 한다.
• 사고 후 회고가 없으면 같은 탐지 실패가 반복된다.

테스트 포인트

• incident id 생성부터 evidence snapshot까지 runbook을 리허설한다.
• affected account만 refresh token revoke하는 절차를 테스트한다.
• feature flag로 고위험 기능을 일시 중지할 수 있는지 확인한다.
• secret rotation emergency runbook이 staging에서 동작하는지 확인한다.
• 사고 대응 조치가 모두 감사 로그로 남는지 확인한다.
• post-incident action item이 owner와 due date를 갖는지 확인한다.

위험 신호!

• 사고 대응 기록이 채팅방에만 남는다.
• 로그 삭제와 서버 재시작이 첫 조치로 되어 있다.
• evidence snapshot 저장소와 일반 로그 저장소 권한이 같다.
• incident commander와 의사결정자가 정해져 있지 않다.
• 전체 사용자 세션 무효화 외의 containment option이 없다.
• 사고 종료 후 재발 방지 task가 만들어지지 않는다.

확인 질문

확인 질문

• 사고 초기 대응에서 가장 먼저 균형 잡아야 하는 두 가지는 무엇인가?
  • 증거 보존과 추가 피해 차단이다.
• 모든 대응 조치에 남겨야 하는 정보는 무엇인가?
  • incident id, actor, action, reason, affected scope, time, result, traceId다.
• post-incident review의 산출물은 무엇이어야 하는가?
  • root cause, detection gap, containment 평가, 재발 방지 task, owner, due date다.

참고 문서

• NIST SP 800-61 Rev. 3
• OWASP Incident Response
• OWASP Logging
• OWASP A09 Security Logging and Monitoring Failures