보안 커리어·현장

‘사고가 났을 때’ 묶음의 한 편 · 6 / 6 — 처음부터 읽기 →

회사에서 해킹이 의심될 때 담당자는 뭐부터 해야 할까요: 초동 대응의 순서

서버가 이상하다는 연락, 낯선 로그인 기록, 갑자기 열리지 않는 파일 — 침해가 의심되는 첫 몇 시간에 담당자가 밟아야 할 순서를 '판단·보존·보고·연락'의 네 단계로 정리합니다. 공격 분석이 아니라 처음 맡은 사람의 사고 틀을 다루는 글이에요.

짧은 답

초동 대응의 핵심은 범인 찾기가 아니라 피해 확산을 멈추고 증거를 남기는 일이에요. 확인된 사실부터 적고, 증거가 사라지지 않게 확산을 멈추고, 정해진 사람에게 짧게 보고하고, KISA 118 같은 공식 창구에 알리세요.

레버와 계기판이 달린 옛 제어반 옆에서 기록계 드럼이 파형을 그리고, 벽에는 빈 꼬리표 열 개가 나란히 걸린 장면
이 글의 차례 8

'해킹당한 것 같아요'라는 연락을 받았을 때 막막한 이유

보안을 맡은 지 얼마 안 됐는데 어느 날 갑자기 '서버가 이상해요', '내가 안 보낸 메일이 나갔대요' 같은 연락을 받으면 머릿속이 하얘지죠. 정말 침해인지 아닌지도 모르겠고, 뭘 먼저 만져야 할지도 모르겠고, 위에는 뭐라고 보고해야 할지도 막막해요. 이 글은 그 첫 몇 시간을 위한 글이에요. 공격을 분석하는 법이 아니라, 처음 맡은 사람이 순서를 잃지 않기 위한 사고 틀을 다룹니다.

먼저 안심하셔도 되는 부분이 있어요. 침해사고 초동 대응에서 담당자에게 기대되는 것은 '해결'이 아니라 '악화시키지 않기'예요. 범인을 찾거나 원인을 밝히는 일은 나중에 전문가와 함께 해도 늦지 않아요. 처음 몇 시간에 정말 중요한 것은 피해가 더 번지지 않게 하고, 나중에 상황을 되짚을 수 있도록 흔적을 남기고, 정해진 사람들에게 제때 알리는 세 가지뿐이에요.

근데 말이죠, 현장에서 흔히 보이는 패턴은 반대예요. 놀란 마음에 의심되는 서버를 곧바로 끄거나 초기화하고, 로그를 지우고, 혼자 며칠 조사하다가 뒤늦게 보고하는 경우가 많아요. 그러면 증거는 사라지고 보고는 늦어져서, 사고 자체보다 '대응 과정'이 더 큰 문제로 남곤 해요. 그래서 순서가 중요해요.

1단계 — 사실과 추정을 나눠서 '지금 무엇이 확인됐는지'부터 적어요

'손대기 전에 먼저 적어요' 메모장. 인지 시점·관찰된 사실·추정·미확인 네 칸, 지금은 고치는 시간이 아니라 재료를 모으는 시간

제일 먼저 할 일은 키보드에 손을 대는 게 아니라 메모를 여는 거예요. 누가, 언제, 무엇을 보고 이상하다고 느꼈는지를 그대로 적어 두세요. '해킹당했다'는 결론이 아니라 '오전에 관리자 화면에서 낯선 계정의 로그인 기록을 봤다'처럼 관찰된 사실만 적는 게 핵심이에요. 여기서 사실과 추정을 나누는 습관이 이후 보고서의 뼈대가 됩니다.

그다음에 '이게 정말 침해인가'를 가볍게 가려 봐요. 시스템 장애, 설정 실수, 동료의 정상 작업, 배치 작업의 오동작이 침해로 오해되는 일은 정말 흔해요. 관련 부서에 '최근에 누가 이 시스템을 만졌는지' 한 번만 물어봐도 절반은 정리돼요. 다만 확인이 안 된다고 안심하지는 말고, 확인될 때까지는 '의심 상태'로 두는 게 안전해요.

이 단계에서 하나만 기억하시면 돼요. 의심되는 장비에서 무언가를 '고치려는' 행동은 아직 하지 않는 거예요. 지금은 판단할 재료를 모으는 시간이지, 손을 쓰는 시간이 아니에요.

  • 인지 시점: 누가 언제 어떤 경로로 이상을 알렸는가
  • 관찰된 사실: 화면·메시지·기록에서 직접 본 것만
  • 추정: '아마 ~일 것 같다'는 문장은 따로 표시
  • 미확인: 아직 물어보지 못한 사람·확인 못 한 시스템

2단계 — 확산을 멈추되, 증거가 사라지지 않게 해요

침해가 어느 정도 의심된다면 다음 목표는 '더 번지지 않게 하기'예요. 여기서 많이들 헷갈리세요. 끄는 게 맞는지, 그냥 두는 게 맞는지요. 일반적인 원칙은 '연결은 끊되 상태는 보존한다'예요. 의심되는 장비를 네트워크에서 분리해 다른 시스템으로 옮겨 가는 것을 막으면서도, 전원을 내리거나 초기화해서 메모리와 로그에 남은 흔적을 지우지는 않는 방향이에요. 실제 조치는 조직의 절차와 전문가의 판단을 따르되, 방향은 이렇게 잡으시면 돼요.

아, 그리고 하나 더. 함께 챙길 것이 계정이에요. 침해가 의심되는 계정이나 그 계정이 쓰던 관리자 권한은 잠그거나 비밀번호를 바꾸는 것이 보통의 대응이에요. 다만 이때도 '누가 언제 무엇을 바꿨는지'를 기록으로 남겨 두세요. 대응하면서 만든 변경이 나중에 공격 흔적과 섞이면 분석이 어려워지거든요.

로그와 백업은 이 단계의 보물이에요. 관련 시스템의 로그가 자동으로 덮어써지거나 삭제되지 않도록 보관 조치를 하고, 가능하면 사본을 별도 장소에 남겨 두세요. 평소에 로그를 왜 남기는지, 백업이 왜 '해 두었다'로 끝나지 않는지 정리해 둔 글들이 바로 이 순간을 위한 것이었어요.

여기서 하지 않아야 할 일이 하나 있어요. 공격자로 보이는 곳에 접속해 보거나 '되돌려 주려는' 시도예요. 이건 법적으로도 위험하고 증거도 오염시켜요. 담당자의 역할은 지키는 쪽이에요.

3단계 — 혼자 들고 있지 말고 정해진 사람에게 짧게 보고해요

초동 대응에서 담당자를 가장 크게 지켜 주는 행동이 바로 이거예요. 확신이 없더라도, 정보가 부족하더라도, 의심 단계에서 조직의 정해진 보고선에 알리는 거예요. '아직 확실하지 않아서 조금 더 보고 알리려고 했다'는 말은 나중에 거의 항상 문제가 돼요. 반대로 '의심 정황을 인지해서 즉시 보고했고, 확인 결과 오탐이었다'는 아무도 탓하지 않아요.

그냥 딱 잘라 말해서, 보고는 길게 쓸 필요가 없어요. 인지 시점, 확인된 사실, 지금 하고 있는 조치, 다음 보고 예정 시각 — 이 네 줄이면 충분해요. 추정은 추정이라고 적어서 넣고요. 이 형식을 한 번 정해 두면 상황이 바뀔 때마다 같은 틀로 갱신만 하면 되니 마음이 훨씬 가벼워져요.

보고 대상은 직속 상사만이 아닐 수 있어요. 개인정보가 관련된 것 같으면 개인정보 보호책임자, 고객 서비스가 걸려 있으면 서비스 운영 책임자, 외주사가 관리하는 시스템이면 계약 담당자까지 초기에 알아야 하는 경우가 많아요. 누구에게 알려야 하는지는 조직마다 다르니, 사고가 나기 전에 미리 목록을 만들어 두는 것이 가장 좋은 준비예요.

4단계 — 조직 밖의 공식 창구를 알아 두면 훨씬 든든해요

절차도 없고 물어볼 선배도 없는 조직이라면 어떻게 할까요. 이때 기댈 수 있는 곳이 공식 기관이에요. 국내에서는 KISA(한국인터넷진흥원)의 118 상담 창구가 침해사고 신고와 상담의 대표적인 입구예요. 어떤 정황을 어떻게 정리해서 신고하면 되는지, 어떤 지원을 받을 수 있는지를 먼저 상담해 볼 수 있어요. 범죄 피해가 분명해 보이면 경찰청 사이버수사 쪽 창구도 있고요.

개인정보가 유출된 것으로 확인되면 법령상 정해진 통지와 신고 의무가 따라와요. 다만 어떤 경우에 어디에 언제까지 신고해야 하는지는 시기에 따라 기준이 바뀌기 때문에, 이 글에서 단정하지 않을게요. 개인정보보호위원회와 KISA의 공식 안내에서 현재 기준을 확인하시고, 판단이 어려우면 상담 창구를 이용하시는 게 맞아요. 담당자가 혼자 법을 해석하려 애쓰지 않아도 된다는 점이 오히려 안심되는 부분이에요.

외부 창구를 알아 두는 것은 사고가 났을 때만을 위한 게 아니에요. '우리 조직은 침해가 의심되면 여기에 연락한다'는 문장 한 줄을 절차에 넣어 두는 것만으로, 다음 담당자도 같은 막막함을 겪지 않게 돼요.

이제 이렇게 하시면 돼요: 사고 전에 준비해 두는 다섯 가지

'사고 전에 준비해 둘 다섯 가지'. 상황 보고 양식, 보고선·담당자 목록, 로그 보관 위치, 외부 창구 연락법, '끊되 지우지 않기'

정리해 볼게요. 침해가 의심될 때 담당자의 순서는 '적고 → 끊되 지우지 말고 → 알리고 → 공식 창구와 함께'예요. 이 순서를 지키면 사고가 실제였든 오탐이었든 담당자는 할 일을 한 사람이 돼요. 결과를 통제할 수는 없지만 과정은 통제할 수 있고, 보안에서 평가받는 것은 대부분 과정이에요.

준비되셨나요? 이 글을 읽는 지금이 가장 좋은 준비 시점이에요. 사고가 나기 전에 보고선 목록을 만들고, 로그 보관 방법을 확인하고, 외부 창구 연락처를 절차에 적어 두고, 상황 보고의 네 줄 양식을 파일로 저장해 두세요. 한 시간이면 끝나는 준비인데, 실제 상황에서 몇 시간의 우왕좌왕을 줄여 줘요.

처음 맡은 담당자에게 침해 의심 상황은 두려운 일이지만, 순서를 알고 있으면 두려움은 긴장 정도로 내려와요. 그리고 그 긴장은 오히려 좋은 대응을 만들어요. 순서를 아는 사람은 당황하지 않고, 당황하지 않는 사람이 증거와 신뢰를 지켜요.

  • 상황 보고 네 줄 양식(인지 시점·확인된 사실·진행 중 조치·다음 보고)을 파일로 저장해 두기
  • 사고 시 알려야 할 내부 보고선과 담당자 목록 만들기
  • 핵심 시스템의 로그가 어디에 얼마나 보관되는지 확인해 두기
  • KISA 118 등 외부 공식 창구 연락 방법을 절차에 적어 두기
  • '의심 장비는 연결은 끊되 상태는 보존한다'는 원칙을 팀과 공유하기

자주 묻는 질문

정말 해킹인지 확실하지 않은데 보고해도 되나요?

네, 의심 단계에서 보고하는 것이 정상이에요. 보고는 '확인된 사실'과 '추정'을 나눠 적으면 되고, 확인 결과 오탐으로 끝나도 문제가 되지 않아요. 반대로 확신이 들 때까지 기다리다 보고가 늦어지는 쪽이 훨씬 더 큰 부담으로 돌아옵니다.

의심되는 서버를 끄면 안 되나요?

일반적인 원칙은 네트워크 연결을 끊어 확산을 막되 전원은 유지해서 메모리와 로그의 흔적을 보존하는 쪽이에요. 다만 실제 조치는 조직의 절차와 전문가 판단을 따라야 하고, 판단이 어려우면 KISA 118 같은 공식 창구에 먼저 상담하는 것이 안전해요.

개인정보가 유출된 것 같으면 어디에 신고해야 하나요?

개인정보 유출에는 법령상 통지·신고 의무가 따르지만, 대상·기한 같은 구체 기준은 시기에 따라 바뀌어요. 개인정보보호위원회와 KISA의 공식 안내에서 현재 기준을 확인하시고, 판단이 어려우면 상담 창구를 이용하시면 돼요. 담당자가 혼자 법을 해석할 필요는 없어요.

직접 확인해 보실 곳

확인할 곳

이 글에서 다루는 주제를 맡는 공식 기관입니다. 신고·상담 창구도 여기에 있으니, 실제 상황에서는 아래로 바로 이어 가시면 됩니다.

참고한 자료

이 글은 입문자 기준으로 이해하기 쉽게 정리한 일반 정보이며, 내용은 운영 과정에서 순차적으로 점검·보완될 수 있습니다. 구체적인 절차나 수치는 해당 기관의 공식 안내를 기준으로 확인해주세요.

이 글의 용어

보안 용어 사전에서 한 줄 정의와 쉬운 비유로 다시 볼 수 있어요.