개인정보 유출 대응 초기 차단·증거보존·피해최소화 방법

◆ 개인정보 유출 대응은 무엇부터 시작하나

사고를 발견하면 첫 단계는 추가 피해를 멈추는 것입니다. 외부에서 비정상적인 접속이 계속되고 있다면 해당 계정이나 접속경로를 차단하고, 악성코드가 확산 중이라면 감염된 시스템을 필요한 범위에서 격리해야 합니다.

하지만 차단 과정에서 사고 흔적을 없애지 않도록 주의해야 합니다. 접속기록, 서버 로그, 보안장비 기록, 계정 사용내역, 의심 파일과 네트워크 기록은 이후 유출 범위와 원인을 확인하는 핵심 자료가 됩니다.

개인정보 보호법 제34조는 유출등이 발생한 경우 해당 개인정보의 회수·삭제 등 피해 확산 방지조치를 포함해 피해를 최소화하기 위한 대책을 마련하고 필요한 조치를 하도록 정합니다.

◆ 차단과 증거 보존을 동시에 해야 하는 이유

개인정보 유출 대응에서 자주 생기는 실수는 공격을 막기 위해 시스템을 초기화하면서 중요한 증거까지 없애는 것입니다. 공격자의 접속 흔적이나 악성파일을 확인할 수 없게 되면 실제 유출 여부와 대상 규모를 산정하기 어려워질 수 있습니다.

가능하면 사고 시점 전후의 시스템 로그, 웹·애플리케이션 로그, 방화벽·침입탐지 기록, 데이터베이스 접근기록을 원본 형태로 보존하고 분석용 복사본을 따로 만들어 확인하는 편이 좋습니다.

해킹이 의심되는 장비를 네트워크에서 분리하더라도 전원을 바로 끄는 것이 적절한지는 상황에 따라 다를 수 있습니다. 메모리에 남아 있는 정보가 중요한 사고라면 보안 전문인력과 함께 보존 방법을 판단하는 것이 안전합니다.

• 사고 대응 타임라인을 바로 남긴다

누가 언제 이상징후를 발견했는지, 어떤 계정을 차단했는지, 어떤 로그를 복사했는지, 어느 시점에 외부 접속을 막았는지를 시간순으로 기록하면 이후 조사와 신고에서 도움이 됩니다.

구두로만 대응하면 담당자가 바뀌거나 시간이 지난 뒤 조치 순서를 재구성하기 어렵습니다. 초기부터 하나의 사고 대응 기록에 발견·판단·조치·확인 결과를 이어서 남기는 것이 좋습니다.

◆ 영향범위는 사람 수보다 정보 종류까지 본다

개인정보 유출 대응 과정에서 다음으로 확인할 것은 어떤 개인정보가 영향을 받았는지입니다. 단순 이름·이메일인지, 비밀번호나 인증정보인지, 주민등록번호 같은 고유식별정보인지에 따라 피해 가능성과 후속조치가 달라집니다.

관련된 정보주체 수를 산정할 때는 중복된 계정이나 동일인의 여러 기록을 구분할 필요가 있습니다. 추정치와 확정치를 섞지 말고 현재 확인된 범위와 추가 조사 중인 범위를 분리해 기록하는 편이 좋습니다.

외부로 실제 반출됐는지 확정되지 않았더라도 무단 접근 흔적이 있다면 어떤 데이터에 접근할 수 있었는지 권한과 로그를 함께 확인해야 합니다.

◆ 통지와 신고는 사고 분석과 병행한다

모든 조사가 끝난 뒤에야 통지나 신고를 검토하는 방식은 피해야 합니다. 개인정보 유출등을 알게 되면 현행 법령의 통지·신고 기준과 시간을 함께 확인해야 합니다.

정보주체 통지에는 유출된 개인정보 항목, 유출 시점과 경위, 피해를 최소화하기 위해 정보주체가 할 수 있는 방법, 개인정보처리자의 대응조치와 피해 구제절차, 담당부서와 연락처 등이 포함됩니다.

관계기관 신고는 유출 규모, 민감정보·고유식별정보 포함 여부, 외부 불법접근 여부 등을 기준으로 판단합니다. 구체적인 사고 범위가 아직 확정되지 않았다면 현재까지 확인된 내용으로 우선 대응하고 추가 확인 사항을 보완하는 방식을 검토해야 합니다.

이 글은 사고 대응 순서에 초점을 두고 있으므로 구체적인 신고 대상과 접수방법은 별도의 개인정보 유출 신고 절차에서 확인하는 것이 좋습니다.

◆ 피해 최소화는 정보 종류에 맞춰 다르게 한다

개인정보 유출 대응에서 피해 최소화 조치는 모든 사고에 같은 안내문을 보내는 것이 아닙니다. 유출된 정보가 무엇인지에 따라 정보주체가 실제로 취할 행동을 구체적으로 안내해야 합니다.

비밀번호나 인증정보가 관련됐다면 비밀번호 변경, 동일 비밀번호를 사용하는 다른 서비스 점검, 추가 인증 설정 등을 안내할 수 있습니다. 연락처가 유출된 경우에는 피싱·스미싱을 주의하도록 안내하고, 금융정보가 관련됐다면 이상거래 확인 등 더 직접적인 행동이 필요할 수 있습니다.

유출된 파일이나 공개된 페이지를 회수·삭제할 수 있다면 가능한 범위에서 즉시 조치하고, 검색엔진 캐시나 외부 저장본처럼 통제하기 어려운 복제본이 있는지도 확인해야 합니다.

◆ 복구 전에 원인을 제거했는지 확인한다

서비스를 빨리 정상화하는 것도 중요하지만 취약점이 그대로 남아 있으면 복구 직후 같은 사고가 반복될 수 있습니다. 침해 계정을 단순히 비밀번호만 바꾸고 끝내지 말고 계정 탈취 경로와 추가 권한 상승 여부를 확인해야 합니다.

취약한 웹페이지나 서버 설정이 원인이었다면 패치와 설정 변경을 완료한 뒤 복구해야 합니다. 위탁업체나 외부 솔루션에서 시작된 사고라면 해당 업체의 조치 결과와 동일한 접근경로가 다른 시스템에도 남아 있는지 확인하는 것이 좋습니다.

복구 후에는 비정상 접속과 대량 조회·다운로드가 다시 발생하지 않는지 일정 기간 집중 모니터링하는 것이 필요합니다.

◆ 사고가 끝난 뒤 재발방지까지 기록한다

개인정보 유출 대응이 끝났다고 판단하려면 서비스가 다시 열렸는지만 볼 것이 아니라 사고 원인과 통제 실패를 확인해야 합니다. 왜 탐지가 늦었는지, 어떤 계정에 과도한 권한이 있었는지, 로그가 충분했는지, 위탁사 관리에 빈틈이 있었는지 점검하는 것이 좋습니다.

내부관리계획과 실제 사고 대응 절차가 달랐다면 문서도 수정해야 합니다. 담당자 연락망, 사고 등급 기준, 신고·통지 의사결정 절차, 증거 보존 방식, 비상연락체계도 실제 사고에서 작동했는지 검토할 수 있습니다.

같은 유형의 사고가 다른 시스템에서 반복되지 않도록 유사 취약점과 동일 계정정책을 함께 점검하면 단일 서버 복구에서 끝나는 대응보다 재발 위험을 줄일 수 있습니다.

◆ 자주 묻는 질문

Q. 개인정보 유출 대응 때 서버를 바로 포맷해도 되나요?

　A. 무조건 포맷하는 것은 권하기 어렵습니다. 사고 경로와 범위를 확인하는 데 필요한 로그·파일·시스템 상태가 사라질 수 있으므로 추가 확산을 차단하면서 원본 증거를 보존하는 방법을 먼저 검토하는 것이 좋습니다.

Q. 유출 규모가 아직 확인되지 않아도 대응을 시작해야 하나요?

　A. 그렇습니다. 유출 범위 산정과 별개로 추가 접근을 차단하고 로그를 보존하며 통지·신고 대상 여부를 검토해야 합니다. 모든 조사 결과가 나올 때까지 초기 대응을 미루지 않는 것이 중요합니다.

Q. 신고를 마치면 개인정보 유출 대응도 끝난 건가요?

　A. 아닙니다. 법은 해당 개인정보의 회수·삭제 등 피해 확산 방지와 피해 최소화 조치를 요구합니다. 원인 제거, 정보주체 보호, 복구, 재발방지까지 이어서 관리해야 합니다.

Q. 수탁업체에서 사고가 났다면 우리 회사는 대응하지 않아도 되나요?

　A. 위탁 구조와 사고 상황에 따라 책임과 역할을 확인해야 합니다. 실제 정보주체 개인정보를 처리하는 과정에서 발생한 사고라면 수탁업체 조치만 기다리지 말고 개인정보처리자 측에서도 사고 범위와 통지·신고·피해 최소화 의무를 확인하는 것이 필요합니다.

◆ 공식 사고대응 기준으로 마지막 확인하기

개인정보 유출 대응 절차를 내부 체크리스트로 만들 때는 오래된 블로그 사례보다 현행 개인정보 보호법과 개인정보보호위원회의 공식 사고대응 매뉴얼을 기준으로 확인하는 것이 좋습니다.

현행 법은 개인정보 유출등이 발생한 경우 해당 개인정보의 회수·삭제 등 피해 확산 방지조치를 포함해 피해를 최소화하기 위한 대책과 필요한 조치를 요구합니다.

법적 대응 의무는 국가법령정보센터 개인정보 보호법 제34조에서 확인할 수 있습니다.

구체적인 실무 대응 흐름은 개인정보보호위원회 개인정보 유출 등 사고대응 매뉴얼에서 확인할 수 있습니다.

© pick.wi-th.com