보안 사고는 대개 홈페이지 화면이 이상하다는 손님의 연락이나, 낯선 곳에서 로그인됐다는 알림으로 시작된다. 이때 서버를 급히 초기화하거나 비밀번호만 바꾸고 넘어가면 무엇이 얼마나 새어 나갔는지 영영 알 수 없게 된다. 사고 대응의 핵심은 막는 것보다 남기는 것이다.
이 글에서 확인할 것
- 침입·유출·변조 중 어느 사고인지에 따라 달라지는 첫 대응
- 나중에 신고서와 안내문에 그대로 들어가는 기록 항목
- 신고 창구의 순서와, 복구 뒤에 관리 체계로 남겨야 할 것
보안 사고라는 말에 섞여 있는 세 가지 상황
같은 사고라도 실제로는 세 갈래로 나뉜다. 첫째는 침입이다. 관리자 계정이나 서버에 누군가 들어온 흔적은 있는데 아직 무엇을 가져갔는지 모르는 상태다. 둘째는 유출이다. 회원 이름·연락처·주문 내역처럼 개인정보가 밖으로 나간 것이 확인된 상태로, 법령상 신고와 당사자 통지 의무가 따라붙는다. 셋째는 변조와 장애다. 화면에 낯선 광고가 붙거나 결제 버튼이 다른 곳으로 연결되거나 사이트가 열리지 않는 경우다.
어느 갈래인지에 따라 첫 대응이 다르다. 침입이면 흔적을 보존하는 것이 먼저이고, 유출이면 기한이 있는 신고가 먼저이며, 변조면 손님이 피해를 입기 전에 화면을 내리는 것이 먼저다. 셋이 한꺼번에 일어나는 경우도 많아, 처음 30분은 무엇이 일어났는지 가르는 데 쓰는 편이 낫다.
첫 한 시간에 할 일과 하지 말 일
가장 흔한 실수는 증거를 지우는 것이다. 서버를 재설치하거나 로그를 정리하거나 의심스러운 파일을 삭제하면, 원인도 범위도 확인할 수 없게 되고 신고서에 적을 내용이 사라진다. 서버를 완전히 끄는 것보다 외부 접속만 차단하는 편이 낫고, 가능하면 그 시점의 디스크 사본을 떠 둔다.
해야 할 일은 순서가 있다. 먼저 관리자·호스팅·도메인·메일 계정의 비밀번호를 바꾸고 이중 인증을 켠다. 이때 새 비밀번호를 메신저나 메일로 공유하지 않는다. 다음으로 결제나 로그인처럼 손님이 정보를 입력하는 화면을 일시 중단하고 안내 문구를 띄운다. 그다음 이 시점부터 누가 무엇을 했는지 시간 순으로 적기 시작한다. 이 기록이 이후 모든 절차의 뼈대가 된다.
외주 개발사나 호스팅 업체에 연락할 때는 무엇이 보였는지만 사실대로 전달한다. 원인을 추측해 전달하면 상대도 그 방향으로만 들여다보게 된다.
사고 발생 직후 남겨야 할 기록 여섯 항목
| 항목 | 적어 둘 내용 | 나중에 쓰이는 곳 |
|---|---|---|
| 인지 시각 | 이상을 처음 알아챈 시각과 경로. 손님 연락인지 알림인지 | 신고 기한의 기준점 |
| 증상 화면 | 변조된 화면·낯선 로그인 알림·오류 메시지의 캡처 | 원인 분석과 신고서 첨부 |
| 영향 범위 | 어떤 화면·어떤 데이터·몇 명의 정보가 관련되는지 추정치 | 당사자 통지 대상 결정 |
| 조치 내역 | 누가 몇 시에 무엇을 바꿨는지. 비밀번호 변경·차단·중단 | 재발 여부 판단 |
| 로그 사본 | 웹서버·접속·관리자 활동 로그를 별도 저장소로 복사 | 침입 경로 확인 |
| 연락 기록 | 개발사·호스팅·결제사와 주고받은 내용과 시각 | 책임 범위 정리 |
표의 항목은 형식보다 시각이 중요하다. 나중에 기억으로 재구성하면 순서가 뒤바뀌고, 그 순서가 뒤바뀌면 원인 분석이 엉뚱한 곳으로 간다.
신고 창구와 순서
신고는 두 갈래로 나뉜다. 침해사고 자체는 한국인터넷진흥원의 상담 창구인 국번 없이 118과 보호나라 누리집에서 접수하며, 상담을 통해 기술 지원도 받을 수 있다. 개인정보가 새어 나간 것이 확인되면 개인정보보호위원회에 별도로 신고해야 하고, 인지한 때로부터 시간 단위로 정해진 기한이 있다. 현재 기준으로 72시간 안에 신고하도록 되어 있으니, 정확한 요건은 개인정보 포털의 유출 신고 안내 화면에서 확인한다.
당사자에게는 무엇이 언제 새어 나갔고 어떻게 대응 중인지, 본인이 할 수 있는 조치가 무엇인지를 알린다. 결제 정보가 관련되면 결제 대행사에도 알려 부정 결제 감시를 요청하고, 금전 피해가 실제로 생겼다면 경찰 사이버수사 창구에 신고한다. 순서는 기한이 있는 것부터다.
복구 뒤에 관리 체계로 남길 체크리스트
복구는 화면이 다시 열리는 것으로 끝나지 않는다. 같은 구멍이 남아 있으면 몇 주 뒤 같은 일이 반복된다. 아래 항목을 점검해 문서로 남기고, 이후로는 분기마다 같은 목록을 다시 본다.
- 침입 경로가 확인됐는가. 오래된 플러그인·기본 비밀번호·방치된 테스트 계정이 흔한 원인이다
- 관리자 계정을 개인별로 나누고, 퇴사자와 외주 담당자의 계정을 정리했는가
- 로그를 며칠 보관하고 어디에 복사해 두는지 정했는가
- 오래된 구조 위에 계속 덧대 온 사이트라면 홈페이지 리뉴얼 시점을 이번 기회에 함께 판단했는가
- 홈페이지 관리 업체와 장애 시 연락 순서와 응답 시간을 문서로 정했는가
- 앱이 있다면 앱 유지보수 계약 범위에 보안 패치가 들어 있는지 확인했는가
- 백업이 실제로 복원되는지 한 번 시험해 봤는가
정리
사고 당일에 잘한 대응과 못한 대응의 차이는 기술보다 기록에서 갈린다. 증거를 보존하고, 시각을 남기고, 기한이 있는 신고부터 처리한 뒤, 복구가 끝난 다음에 관리 체계를 문서로 남기면 같은 사고를 두 번 겪을 확률이 크게 줄어든다.
막았는지보다 남겼는지가 사고 이후의 모든 절차를 결정한다.
