517. 다크 데이터 (Dark Data)와 데이터베이스 보안 통제

⚠️ 이 문서는 기업이 "나중에 AI 학습할 때 쓸지도 몰라!"라며 무작정 긁어모아 데이터 레이크에 방치해 두었지만, 아무도 그 존재를 모르고 관리도 안 되어서 해커들의 최고 먹잇감이 되는 무서운 시한폭탄인 '다크 데이터'와 이를 통제하는 보안 기술을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 수집, 처리, 저장되었지만 다른 용도(분석 등)로 전혀 활용되지 않고 방치된 비정형 데이터를 말한다. 우주 암흑물질처럼 눈에 안 보이지만 디스크 용량의 80%를 차지한다.
  2. 위험성: 이 안에 고객의 여권 사진, 주민등록번호가 섞여 있어도 아무도 모르기 때문에, 해커가 훔쳐 가거나 랜섬웨어를 걸어도 회사는 며칠 동안 눈치조차 못 챈다. (ISMS 보안 감사의 1순위 적발 대상)
  3. 해결책: 데이터 거버넌스(503번 문서)를 통해 모든 데이터의 위치를 스캔(Discovery)하고, 민감 정보는 마스킹(Masking)하며, 안 쓰는 데이터는 과감히 지워버리는 수명 주기(Lifecycle) 관리가 필수다.

Ⅰ. 개요: 보이지 않는 쓰레기장 (Context & Necessity)

어느 날 쇼핑몰에 해커가 침입했다. 해커는 메인 데이터베이스(MySQL)를 털려고 했지만, 여기는 암호화(TDE - 491번 문서)와 방화벽(370번 문서)으로 떡칠 되어 있어서 뚫지 못했다.

그래서 해커는 텅 비어 보이는 백업용 아마존 S3(데이터 레이크) 창고로 발길을 돌렸다.

  • 여기에는 개발자들이 테스트한다고 3년 전에 복사해 둔 '회원 가입 엑셀 파일'이 뒹굴고 있었다.
  • 고객센터 직원이 5년 전에 저장해 둔 '고객 환불 요청 이메일(계좌번호 포함)' 압축 파일도 있었다.

해커는 이 파일들을 훔쳐서 다크웹에 팔아넘겼다. 회사는 1년 뒤에 경찰 연락을 받고서야 이 파일들이 털렸다는 걸 알았다. 이처럼 **존재조차 잊힌 채 방치된 데이터들을 '다크 데이터(Dark Data)'**라고 부른다.

📢 섹션 요약 비유: 다크 데이터는 **'침대 밑에 굴러다니는 옛날 일기장'**과 같습니다. 나는 거기에 무슨 비밀을 적어놨는지조차 잊어버렸지만, 누군가 놀러 와서 침대 밑을 청소하다가 그걸 발견하면 내 모든 흑역사가 만천하에 까발려지게 되는 무서운 폭탄이죠.

Ⅱ. 다크 데이터의 3가지 유형 ★

데이터가 다크 데이터로 변질되는 대표적인 케이스들이다.

  1. 버려진 로그 파일 (Log Files)
    • 서버 에러가 났을 때 잠깐 보려고 남겨둔 로그 파일들.
    • 문제: 개발자가 에러 분석용으로 로그 안에 유저의 '비밀번호'나 '카드 번호'를 그대로 찍히게 코딩해 놓은 경우가 수두룩하다.
  2. 구형 백업본 (Orphaned Backups)
    • "혹시 모르니까 백업 한 번 싹 떠놓자" 하고 개인 PC나 클라우드 구석에 저장해 둔 덤프 파일(dump.sql).
    • 문제: 원본 DB는 암호화되어있지만, 이 백업 파일은 평문(텍스트)인 경우가 많아 해커가 줍기만 하면 끝이다.
  3. 퇴사자의 폴더 (Abandoned Data)
    • 3년 전 퇴사한 데이터 분석가가 자기 계정 폴더에 남겨두고 간 실험용 데이터셋들.

Ⅲ. 실무 팁: 다크 데이터 보안 통제 파이프라인

글로벌 기업들은 이 다크 데이터를 처리하기 위해 막대한 돈을 쓴다.

1. 데이터 탐색 및 분류 (Data Discovery & Classification)

  • 자동화된 AI 로봇(Macie 같은 툴)을 데이터 레이크에 풀어놓는다.
  • 로봇이 파일 수억 개를 열어보면서, "어? 이거 주민등록번호 패턴(\d{6}-\d{7})인데?" 하고 찾아내면 그 파일에 빨간 딱지(민감 정보)를 붙인다.

2. 동적 데이터 마스킹 (Dynamic Data Masking)

  • 발견된 민감 정보 파일은 즉시 암호화하거나, 조회할 때 주민번호 뒷자리를 ******로 강제 변환(마스킹)해서 보여주게 통제한다. (367번 문서 참조)

3. 콜드 스토리지 이동 및 폐기 (Retention Policy)

  • 만들어진 지 3년이 넘었고, 지난 1년간 한 번도 열어보지 않은 파일(다크 데이터)은 아예 싼 디스크(S3 Glacier)로 옮기고 락을 걸어버린다. (수명 주기 관리 - 373번 문서)
  • 개인정보보호법에 따라 5년이 지난 데이터는 시스템이 알아서 영구 삭제(Shredding)하게 만든다.
┌──────────────────────────────────────────────────────────────┐
│           다크 데이터 (Dark Data) 발생 및 보안 통제 시각화               │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│ [ 👨‍💻 운영 환경 ]                [ 🌊 데이터 레이크 (방치된 늪지대) ]   │
│   (철저한 보안)                                                │
│  안전한 최신 DB ──(백업, 로그)──▶  [오래된 엑셀] [에러 로그] [퇴사자 폴더]│
│                                  (주민번호 노출) (카드번호 노출)        │
│                                            │                 │
│                                            ▼                 │
│ [ 🤖 보안 봇 투입 (Discovery) ]     🚨 해커가 가장 노리는 맛집! 🚨  │
│  "엑셀 파일에서 주민번호 패턴 발견!"                                  │
│            │                                                 │
│            ▼                                                 │
│ [ 🛡️ 통제 (Governance) ]                                       │
│  "즉시 암호화(TDE)하고, 3년 지났으니 영구 삭제(Drop)해버려!"            │
└──────────────────────────────────────────────────────────────┘

Ⅳ. 결론

"저장 공간이 싸질수록, 보안 리스크는 기하급수적으로 비싸진다." AWS나 구글 클라우드가 제공하는 무제한의 값싼 스토리지(S3)는 기업들에게 축복이었지만, 동시에 다크 데이터라는 저주를 낳았다. 개발자들은 "나중에 쓰겠지"라는 핑계로 일단 모든 데이터를 때려 박는 데 익숙해졌다. 하지만 데이터는 석유(오일)와 같아서, 정제되지 않은 원유를 방치하면 결국 토양을 썩게 만들고 불이 붙어 대형 폭발을 일으킨다. 훌륭한 백엔드 엔지니어와 아키텍트는 "이 데이터를 어떻게 저장할까?"만큼이나 **"이 데이터를 언제, 어떻게 완벽하게 지워버릴까?"**를 시스템 설계의 첫 번째 단추로 삼아야 한다.

📌 관련 개념 맵

  • 해결 기술 1: Data Governance (데이터 거버넌스 - 503번 문서)
  • 해결 기술 2: Retention Policy (보존 정책 - 515번 문서)
  • 보안 기술: Data Masking (데이터 마스킹), TDE (디스크 암호화 - 491번 문서)
  • 관련 인프라: Data Lake (데이터 레이크 - 482번 문서)

👶 어린이를 위한 3줄 비유 설명

  1. 내가 초등학교 1학년 때 그렸던 비밀 그림일기장이 내 방 옷장 구석 어딘가에 찌그러져 있어요.
  2. 나는 그 일기장이 거기에 있는지도 까먹고 살았는데(다크 데이터), 어느 날 놀러 온 친구가 그걸 발견하고 꺼내 읽어버리면 내 비밀이 다 들통나버리겠죠? (보안 사고)
  3. 그래서 주기적으로 방 청소를 하면서, 필요 없는 옛날 일기장은 파쇄기에 넣고 갈아버리거나 자물쇠가 달린 상자에 넣어서 버리는(보안 통제) 습관이 중요하답니다!