데이터 침해는 왜 일어나며, 발생하면 무엇을 해야 할까
비개발자를 위한 데이터 침해 대응 안내. 계정 탈취, 잘못된 공개 설정, 공급망 침해가 왜 일어나는지, 그리고 사고 직후 대응 순서와 신고 의무를 정리합니다.
침해는 해커의 공격만을 뜻하지 않는다
"비개발자가 알아야 할 데이터베이스 이야기" 12부작 중 10편입니다. 9편이 '방어'였다면 이 편은 '뚫렸을 때'의 이야기입니다. 사고 대응력의 차이가 피해 규모의 차이를 만듭니다.
직원이 고객 명단을 잘못된 이메일 주소로 보냈다. 클라우드 저장 공간의 공개 설정 때문에 누구나 파일을 내려받을 수 있었다. 퇴사자의 계정이 남아 있었고 그 계정으로 자료가 반출됐다. 랜섬웨어가 데이터베이스와 백업을 함께 암호화했다.
모두 **데이터 침해(data breach)**가 될 수 있다. 침해는 권한 없는 사람이 민감한 데이터에 접근하거나, 데이터를 가져가거나, 공개하거나, 바꾸거나, 사용할 수 없게 만든 사건을 넓게 가리킨다. 법적 정의와 신고 기준은 지역과 산업에 따라 다를 수 있다.
보안 사건과 데이터 침해는 구분할 필요가 있다
수상한 로그인 시도가 있었지만 차단되었고 데이터에는 접근하지 못했을 수 있다. 이것은 조사해야 할 **보안 사건(security incident)**이지만 확인된 데이터 침해는 아닐 수 있다. 반대로 처음에는 단순 장애처럼 보였지만 조사 결과 데이터가 외부로 나간 사실이 드러날 수도 있다.
초기에 성급히 단정하기보다 사실을 보존하고 조사해야 한다. "해킹이 아닙니다"라고 섣불리 발표했다가 사흘 뒤 해킹으로 확인되면, 사고 자체보다 발표의 신뢰 상실이 더 크게 다가온다.
침해는 왜 일어날까?
계정 탈취
재사용한 비밀번호, 피싱, 다중 인증 부재로 직원이나 관리자 계정이 공격자에게 넘어간다. 공격의 상당수는 "뚫는" 것이 아니라 "열쇠를 줍는" 것이다.
잘못된 권한과 공개 설정
데이터베이스, 저장 공간, 백업, 관리 화면이 필요 이상으로 넓게 공개된다. 클라우드 저장소를 '전체 공개'로 잘못 설정해 노출되는 사고는 대형 침해의 단골 원인이다.
업데이트하지 않은 취약점
알려진 보안 결함을 고치지 않은 서버나 애플리케이션이 공격 경로가 된다. 공격자에게는 이미 '설명서'가 공개된 약점이다.
애플리케이션의 접근 통제 실패
로그인한 사용자가 주소의 번호만 바꿔 다른 사람의 기록을 보거나, 관리자 기능을 호출할 수 있는 문제가 생긴다.
내부자와 사람의 실수
고의적인 반출뿐 아니라 이메일 오발송, 노트북 분실, 잘못된 공유 링크도 침해를 일으킨다.
외부 업체와 공급망
우리 회사가 아니라 데이터를 처리하는 외부 서비스가 침해될 수 있다. 8편에서 봤듯, 위탁했다고 위험과 고객에 대한 책임까지 사라지는 것은 아니다.
실제 사례가 보여 주는 것
미국 신용정보회사 Equifax는 2017년 침해로 약 1억 4,700만 명의 개인정보가 노출됐다고 발표했다. 미국 연방거래위원회(FTC)는 이후 합의와 소비자 지원 내용을 공개했다. 이 사례는 데이터가 복사된 뒤에는 비밀번호처럼 간단히 바꿀 수 없는 주민 식별 정보와 신용정보가 오랫동안 개인에게 위험을 남길 수 있음을 보여 준다.
중요한 교훈은 "큰 기업도 당한다"에서 끝나지 않는다. 보유 데이터의 민감도, 알려진 취약점 관리, 탐지, 경영진의 책임, 피해자 지원이 하나의 연결된 문제라는 점이다. 그리고 사고 비용은 과징금만이 아니다 — 소송, 조사 비용, 피해자 지원, 그리고 그 무엇보다 고객 이탈과 브랜드 훼손이 따른다.
침해를 알게 된 직후의 대응 순서
1. 대응팀을 가동한다
보안·IT뿐 아니라 경영진, 법무, 개인정보 담당, 고객 지원, 홍보, 관련 외부 업체가 역할에 따라 참여해야 한다. 연락처와 대체 담당자를 평소에 정해 둔다.
2. 확산을 막되 증거를 보존한다
침해된 계정을 막고, 필요한 시스템을 격리하며, 노출된 비밀키와 인증 정보를 교체한다. 그러나 서둘러 로그와 시스템을 지우면 원인과 피해 범위를 확인할 증거가 사라진다. 조사 전문가와 함께 조치하는 것이 좋다.
3. 무엇이 영향을 받았는지 확인한다
- 어떤 데이터가 보이거나 복사되거나 바뀌었는가?
- 누구의 정보인가?
- 언제 시작되어 언제 발견됐는가?
- 공격자가 아직 접근할 수 있는가?
- 백업과 다른 시스템도 영향을 받았는가?
확인된 사실, 아직 모르는 것, 추정하는 것을 구분해서 기록한다. 이 구분이 이후 모든 커뮤니케이션의 신뢰를 좌우한다.
4. 법적·계약상 신고 의무를 확인한다
신고 대상과 기한은 지역, 산업, 데이터 종류, 계약에 따라 달라진다. 한국 정보통신망법상 개인정보 유출 시 24시간 이내 신고 의무가 있고, GDPR은 72시간 이내 감독기관 통보를 요구한다. 의료·금융·아동 정보에는 별도의 규칙이 적용될 수 있다. 구체적인 상황은 자격 있는 법률 전문가와 확인해야 한다.
5. 피해를 줄이도록 알린다
통지는 책임 회피용 문구가 아니라 피해자가 자신을 보호할 수 있게 하는 정보여야 한다. 어떤 정보가 영향을 받았는지, 언제 무슨 일이 있었는지, 현재 무엇을 하고 있는지, 개인이 취할 조치와 문의 방법을 쉬운 언어로 설명한다. 모르는 내용을 아는 것처럼 말해서는 안 된다.
6. 복구하고 재발을 막는다
안전한 백업에서 복구하고, 취약점을 고치고, 권한과 설정을 다시 점검한다. 사고 후 보고서는 개인 한 명의 실수를 탓하기보다 왜 하나의 실수가 큰 피해로 이어졌는지 시스템과 절차를 살펴야 한다.
대응 계획은 사고가 나기 전에 만든다
침해가 발생한 날 처음으로 법무 담당자의 전화번호를 찾거나, 백업 위치를 확인해서는 늦다. 최소한 다음을 준비한다.
- 사고 등급과 보고 기준
- 비상 연락망과 역할표
- 시스템 격리와 증거 보존 절차
- 데이터와 외부 업체 목록
- 법적·계약상 통지 검토 절차
- 고객 안내문 기본 틀
- 백업 복구 순서
- 정기 모의훈련 일정
핵심 정리 데이터 침해는 외부 해킹뿐 아니라 실수, 잘못된 설정, 내부자, 외부 업체에서 시작될 수 있다. 발생 후에는 확산 방지, 증거 보존, 범위 확인, 법적 검토, 피해자 통지, 안전한 복구가 연결되어야 한다. 가장 좋은 대응 계획은 사고 전에 역할과 연락망을 정하고 연습한 계획이다.
지금 확인할 질문
- 침해 의심 상황을 직원이 어디에 보고해야 하는가?
- 고객 데이터가 어느 외부 업체에 있는지 즉시 목록으로 뽑을 수 있는가?
- 로그와 증거를 누가 보존하고 조사하는가?
- 고객에게 알릴 내용은 누가 승인하는가?
- 복구 후 같은 문제가 다시 생기지 않았음을 어떻게 확인하는가?
다음 글: 클라우드와 서버리스가 데이터베이스 운영을 어떻게 바꾸며, 무엇은 여전히 우리 책임인지 알아본다.
참고: FTC 기업용 데이터 침해 대응 안내, FTC Equifax 침해 합의 안내, CISA 랜섬웨어 대응 안내
시리즈 목차
- 데이터베이스란 무엇인가 — 엑셀 파일과 무엇이 다를까?
- 데이터베이스는 어떻게 정확성을 지킬까
- 데이터베이스에는 어떤 종류가 있을까
- 데이터베이스, 데이터 웨어하우스, 데이터 레이크
- 올바른 데이터베이스 선택이 중요한 이유
- 데이터 모델과 데이터 품질
- 데이터 거버넌스란 무엇인가
- 개인정보는 적게, 필요한 만큼만
- 데이터 보안의 기본
- 데이터 침해는 왜 일어나며, 발생하면 무엇을 해야 할까 ← 현재 글
- 클라우드와 서버리스 데이터베이스
- AI 시대의 데이터베이스
