다크 데이터(dark data) 설명: 보이지 않는 데이터가 보안 문제인 이유

대부분의 보안 프로그램은 알려진 데이터(known data)를 중심으로 구축됩니다. 즉, 목록화(inventoried)되고 분류(classified)되며, 활성 통제(active controls)의 경계(perimeter) 안에 있는 데이터입니다. 대부분의 조직에서 알려진 데이터는 소수에 불과합니다.

나머지 절반은 관리되지 않고 분류되지 않은 상태이며, 종종 완전히 잊혀져 있습니다. 그리고 바로 그 영역이 점점 더 침해 사고 포렌식(breach forensics)과 감사(audit) 결과가 지목하는 곳입니다.

Splunk의 'State of Dark Data' 보고서에 따르면 설문조사에서 기업 데이터의 평균 55%가 ‘다크 데이터’입니다. 즉, 조직이 데이터를 저장해 두긴 하지만 해당 데이터를 찾아내지 못하고, 분류하지 못하며, 접근 권한을 관리(거버넌스)하지도 못한다는 의미입니다.

이 비율은 산업 전반의 평균입니다. 하지만 레거시 인프라가 있는 환경, SaaS 도입이 높은 환경, 또는 거버넌스 투자 여력이 제한된 환경에서는 그 비중이 훨씬 더 높습니다.

실무적으로는 아주 단순합니다. 조직이 투자한 모든 보안 통제( DLP, SIEM, access governance, 암호화)는 자신이 알고 있는 데이터만 보호합니다.

다크 데이터란 무엇인가요?

다크 데이터는 조직이 수집하고 저장했지만 잊혀져 버린 데이터입니다. 따라서 해당 데이터는 적극적으로 관리, 분류, 모니터링되지 않아, 데이터의 위치, 민감도, 접근 권한이 사실상 알 수 없게 됩니다.

여기에는 물론 민감한 자료가 포함됩니다. 예를 들면 PII, PHI, 결제 카드 데이터, 관리되는 시스템 밖으로 벗어난 권한 증명(자격 증명)과, 식별자를 포함하고 있으나 아무도 그 수집 사실을 인지하지 못했던 운영상 생성 데이터(로그, 텔레мет리, 내보내기, 백업) 등이 있습니다.

두 범주 모두, 영구적인 규제 대상 데이터 저장소로 설계된 것은 아니지만 실제적인 보안 및 규정 준수 리스크(노출)를 만들어냅니다.

다크 데이터는 데이터 스폴(데이터 스프롤) 같은 인접한 개념과는 구분됩니다. 데이터 스폴은 종종 같은 맥락에서 함께 언급됩니다. 데이터 스폴은 시스템 전반에서 데이터가 통제되지 않은 채 생성되고 확산되는 현상입니다. 조직은 복사본이 존재한다는 사실은 알지만 이를 관리(거버넌스)하지는 않은 상태입니다.

각각은 서로 다른 시정(개선) 경로를 가지며, 이를 혼동하면 잘못된 문제를 해결하려는 거버넌스 프로그램으로 이어집니다.

다크 데이터의 유형

다크 데이터는 조직이 평상시 운영 과정에서 데이터를 생성하고 축적하는 방식에 따라 서로 다른 형태로 나타나며, 각각 위험 프로필이 다릅니다.

• 운영 데이터 및 텔레мет리 데이터: 보존 기간 경계 없이 유지되는 웹 서버 로그, 애플리케이션 트레이스, SIEM 아카이브, 텔레메트리 파이프라인에는 종종 세션 토큰, IP 주소, 그리고 쿼리 파라미터나 API 호출을 통해 수집된 개인 데이터가 포함됩니다.
• 중복 복사본 및 중단된 내보내기: 일회성 프로젝트를 위해 생성된 CRM, ERP, HR 또는 임상 시스템의 CSV, Excel, JSON 내보내기 파일이 공유 드라이브에 방치되어 있으며, 현재 책임자가 없고 삭제 계획도 없는 경우입니다.
• 테스트 및 개발 데이터: 마스킹이나 보존 제어 없이 운영 데이터를 dev, test 또는 샌드박스 환경으로 복사하는 경우입니다. 존재하지 않는 애플리케이션에 대해 고객 또는 환자 테이블의 전체 복사본이 포함되기도 합니다.
• 고아 상태의 백업 및 레거시 애플리케이션 데이터: 폐기(철거)된 시스템에서 나온 백업과 아카이브 세트가 수년 동안 민감한 기록을 그대로 보관하고 있지만, 삭제 결정에 대해 책임질 지정된 소유자가 없는 경우입니다.

하이브리드 환경에서 다크 데이터가 존재하는 위치

위의 유형들은 예측 가능한 인프라 위치에 누적되며, 표준 보안 및 거버넌스 도구의 적용 범위를 벗어나는 경우가 많습니다.

클라우드 스토리지 및 오브젝트 버킷

마이그레이션, 개념 검증(Proof of Concept), 또는 일회성 분석 작업을 위해 생성되고 더 이상 사용 중단(decommission)되지 않은 S3, Azure Blob, GCS 버킷은 거버넌스되지 않은 데이터 저장소로 그대로 남아 있습니다.

이러한 자산은 공식적인 자산 인벤토리에 포함된 적이 없기 때문에, 일반적으로 DLP 적용 범위에서 제외되어 있으며 생성 시점의 환경에서 상속된 과도하게 허용적인 액세스 구성도 그대로 유지되고, 액세스 검토 자체에서도 완전히 제외됩니다.

레거시 파일 공유, NAS, 협업 공간

부서별 파일 공유와 NAS 장치는 정상적인 운영이 이어지는 수년 동안 검토되지 않은 콘텐츠를 계속 누적합니다. SharePoint 사이트, Teams 채널 그리고 완료된 프로젝트에서 사용하던 OneDrive 폴더는 현재 담당자가 없는 상태로 계약서, 보고서, 데이터 추출본을 계속 저장합니다.

이러한 환경에는 조직 내에서 가장 오래되었고 가장 민감한 데이터가 일부 포함되어 있지만, 모니터링 규칙이나 분류 도구의 적용 범위에 들어갈 가능성이 가장 낮은 위치들 중 하나로 남아 있습니다.

백업, 아카이브, 로그 저장소

장기 백업, 클라우드 아카이브 계층, 로그 저장소에는 지속적으로 보관할 의도가 없었던 자격 증명, 세션 토큰, PII, PHI가 포함되어 있습니다. 활성 디버깅에 적합한 로그 상세 수준 설정은, 분류나 검토 없이 로그가 수년 단위 보관 기간 동안 개인 데이터를 유지하게 되면 컴플라이언스 리스크로 전환됩니다.

SaaS 내보내기 및 AI 도구 통합

핵심 비즈니스 시스템에서 마케팅, HR 또는 제품 SaaS 플랫폼으로 내보낸 데이터는 관리되는 데이터 환경 밖에 존재합니다. AI 및 자동화 플랫폼은 운영 데이터를 자체 저장소나 장기간 유지되는 캐시 계층으로 수집하며, 이는 자산 인벤토리에는 거의 나타나지 않습니다. 그 결과, 라이프사이클에 자연스러운 경계가 없는 ‘다크 데이터’의 범주가 점점 더 커지고 있습니다.

다크 데이터가 축적되는 원인

예방적 통제를 설계하는 보안 아키텍트에게 근본 원인을 파악하는 것은 중요합니다. 사후 대응형 정리는, 원천에서 축적을 줄이는 것보다 더 느리고 더 비용이 많이 듭니다.

데이터 라이프사이클 거버넌스 부재

대부분의 조직에는 데이터 생성 프로세스는 있지만, 이에 상응하는 삭제 또는 재분류 프로세스는 없습니다. 데이터는 인제스트 파이프라인, SaaS 통합, 사용자 생성 워크플로를 통해 유입되며, 이를 밖으로 이동시키는 자동화된 라이프사이클 규칙, 소유권 할당, 또는 검토 트리거가 존재하지 않기 때문에 무기한으로 그대로 남습니다. 보관 기간이 무제한이고 분류가 선택 사항인 곳에서는 기본 결과로 다크 데이터가 축적됩니다.

조직 및 도구(툴) 사일로

한 팀이 생성한 데이터가 다른 팀의 거버넌스 범위로 들어가는 경우는 드뭅니다. 마케팅 수출본, 개발자 데이터베이스 복사본, 재무 아카이브, 프로젝트 파일 덤프는 각각 거버넌스 기능이 추적하지 않는 데이터 산출물(아티팩트)을 만들어냅니다.

보안 및 데이터 거버넌스 팀은 일반적으로 이러한 환경을 파악(인벤토리)할 수 있는 도구를 갖추지 못해, 조직 경계를 넘어 축적이 조용히 계속됩니다.

AI, 자동화, 그리고 클라우드 스프롤

거버넌스 요구사항이 도입 시점에 부재한 경우, 모든 신규 AI 통합, 자동화 워크플로, 클라우드 서비스는 기본적으로 다크 데이터 생성기가 됩니다.

이러한 도구는 파생 데이터셋, 추론 로그, 그리고 통합 캐시를 생성하며, 이들은 소유 주체나 수명 주기 경계가 정의되지 않은 채로 지속됩니다.

AI 도구 연결은 가장 빠르게 증가하는 기여 요인입니다. LLM 기반 도구와 공유된 데이터는 조직의 거버넌스 범위를 완전히 벗어난 채, AI 벤더의 인프라 내에 그대로 유지될 수 있습니다.

다크 데이터가 보안 문제인 이유

다크 데이터는 침해 사고의 비용을 증가시키고 공격 표면을 넓히며, 규제 리스크를 초래하고, 조직이 알려진 데이터를 보호하기 위해 의존하는 통제를 약화시킵니다.

보이지 않는 것은 보호할 수 없습니다

DLP, SIEM, 액세스 거버넌스, 암호화는 자신들이 알고 있는 데이터 저장소를 보호합니다. 한 번도 카탈로그화하거나 분류되지 않은 어떤 리포지토리도 이러한 각 통제의 범위 밖에 놓입니다. IBM 2025 Cost of a Data Breach Report에 따르면, 데이터 침해의 35%에는 섀도 데이터가 포함되어 있었고, 그런 침해는 섀도 데이터 구성요소가 없는 침해보다 평균적으로 16% 더 많은 비용이 들었으며 식별하는 데 26.2% 더 오래 걸렸습니다.

기존 보안 도구는 이를 찾아내도록 설계되지 않았습니다

DLP 정책은 알려진 채널을 대상으로 하고, SIEM은 온보딩된 시스템의 로그를 수집하며, IAM과 IGA는 인벤토리에 있는 자산에 대한 액세스를 관리합니다. 이러한 어떤 도구도 이미 알고 있지 못한 것을 발견하지는 못합니다. 다크 데이터는 검색(발견) 계층에서 각 통제를 무력화합니다. 저장소가 한 번도 인벤토리로 파악되지 않으면 DLP는 절대 스캔하지 못하고, SIEM은 절대 모니터링하지 못하며, 액세스 검토도 절대 그 범위에 포함되지 않습니다.

관리되지 않는 데이터로 인한 규제 리스크

GDPR, HIPAA, CCPA및 대부분의 산업별 프레임워크는 규제 대상 정보를 포함한 관리되지 않은 데이터 저장소를 규정 준수 실패로 간주합니다.

데이터 최소화와 프라이버시 바이 디자인(Privacy by Design)는 개인 데이터가 어디에 저장되어 있는지에 대한 입증 가능한 인식과, 이를 보관하기 위한 문서화된 정당성을 요구합니다.

Data Subject Access Requests (DSARs) 및 삭제 요구권 요청은 완전한 데이터 인벤토리 없이는 구조적으로 이행이 어렵고, 그러한 인벤토리가 부재한 상태가 다크 데이터 프로그램을 특징짓습니다.

감사 및 보증(assurance) 측면의 역풍

감사인은 이제 비정형이며 관리되지 않은 데이터에 대해 직접적인 질문을 합니다. 확인되지 않은 데이터 저장소는 모두, 감사 압박 속에서 수동 조사를 필요로 하는 고통스러운 예외가 되거나, 더 넓은 통제 주장들을 약화시키는 결과(발견)로 이어집니다.

정의된 범위, 문서화된 방법론, 최신 인벤토리 및 시정(복구) 로그를 포함한 구조화된 검색/발견(discovery) 프로그램을 갖춘 조직은, 현장 작업 중에 알 수 없는 저장소가 드러나는 조직보다 일관되게 더 좋은 성과를 보입니다.

다크 데이터를 찾아 관리하는 방법

목표는 이미 존재하는 것들을 해결하는 동시에, 알려지지 않은 저장소가 계속 쌓여가지 않도록 가시성과 프로세스 통제를 구축하는 것입니다.

순서가 중요합니다. 검색/발견(discovery)은 정책보다 먼저 수행되어야 합니다. 불완전한 인벤토리를 기반으로 구축된 거버넌스 프레임워크는 잘못된 확신(false assurance)을 만들어내기 때문입니다.

1단계: 범위를 정의하고 위험도에 따라 우선순위를 정합니다

계층화된 범위 목록을 구성합니다.

1. 1티어: 규제 대상 데이터가 가장 많이 저장될 가능성이 높고 통제가 가장 약한 저장소(운영 환경과 연결된 클라우드 오브젝트 스토리지, 레거시 파일 공유, Microsoft 365, SaaS 내보내기 도구).
2. 2티어: 백업, 아카이브 계층, 로그 저장소.
3. 3티어: 테스트 및 개발 환경, 그리고 폐기된 시스템의 아카이브.

각 계층(tier)에서는 세 가지 기준으로 우선순위를 정합니다. 규제 범위(GDPR, HIPAA, PCI DSS), 데이터 양, 그리고 마지막 접근 검토 이후 경과 시간입니다.

세 가지 기준 모두가 높은 심각도로 해당되는 저장소는 검색(발견) 대기열의 맨 앞에 배치합니다. 범위(scoping) 결정을 문서화하여, 다음 평가 주기에서 처음부터 다시 구축하지 않고 이를 더 정교하게 다듬을 수 있도록 하세요.

2단계: 범위에 포함된 저장소 전반에서 자동 검색 및 분류를 수행합니다.

가장 높은 우선순위의 저장소부터 우선적으로 검색 및 분류 도구를 배포합니다. 데이터가 저장된 위치에 대해 사전 지식이 없어도 파일 시스템, 오브젝트 스토리지, 데이터베이스, 협업 환경을 스캔하도록 구성하세요.

그런 다음 분류 규칙을 설정하여 PII, PHI, 결제 카드 데이터, 자격 증명(credentials), 그리고 업종별로 규제되는 기타 콘텐츠를 탐지합니다.

첫 번째 스캔은 읽기 전용 모드로 실행해 기준선을 설정하세요. 결과를 세 가지 아티팩트로 내보냅니다: 발견된 스토어 목록, 스토어별 민감도 분류, 그리고 각 스토어에 도달할 수 있는 사용자 및 그룹을 보여주는 유효 권한 맵.

이렇게 결합된 출력물이 프로그램의 나머지 단계가 기반으로 삼는 인벤토리입니다.

3단계: 소유권을 매핑하고 보관(유지) 결정을 내리기

발견된 모든 스토어에 비즈니스 소유자를 지정하세요. 소유자가 식별되지 않는 경우에는 정의된 기간 내에(대부분의 프로그램은 30일 사용) 할당을 위해 데이터 거버넌스 리드에게 에스컬레이션합니다. 소유자가 없는 스토어는 다음 단계로 진행할 수 없습니다.

소유권이 지정되면, 소유자는 두 가지 질문에 답합니다: 이 데이터는 여전히 필요합니까, 그리고 현재의 액세스 권한이 least privilege에 부합합니까?

첫 번째 삭제 큐로의 이동에 실패한 저장소(법적 보류 및 보관 기간 점검 후)와, 두 번째 액세스 복구 큐로의 이동에 실패한 저장소.

두 조건을 모두 통과한 스토어는 문서화된 소유자와 검토 주기를 갖춘 거버넌스 범위에 포함됩니다.

4단계: 범위 내 저장소에 라이프사이클 정책을 적용합니다

각 거버넌스 대상 저장소에 자동화된 라이프사이클 규칙을 적용합니다. 예를 들어, 오브젝트 버킷에는 클라우드 스토리지 라이프사이클 정책, 운영 데이터 저장소에는 데이터베이스 보관 정책, 아카이브 티어에는 백업 보관 설정을 적용합니다.

데이터 범주별 기본 만료 간격을 설정하고, 무기한 보관이 필요한 경우에는 명시적이며 기간이 정해진 예외를 요구합니다.

각 수명주기 규칙을 2단계에서 생성된 분류와 연결하여, 'regulated'로 태그된 데이터가 자동으로 올바른 보존 경로를 실행하도록 합니다.

수동 삭제 워크플로는 백로그가 되고, 백로그는 영구적인 다크 데이터 축적으로 이어집니다. 따라서 기본은 자동화로 하고, 수동 검토는 예외에 한해 적용하는 것이 목표입니다.

5단계: 지속적인 검색을 운영화하기

정해진 주기로 반복 검색 스캔을 예약하세요(대부분의 프로그램은 Tier 1을 주간, Tier 2를 월간, Tier 3를 분기별로 수행)하고, 기존 인벤토리 외부에 새로 나타나는 모든 스토어에 대해 경고를 설정합니다.

검색 플랫폼을 구성하여 분류 및 접근 결과를 SIEM, SOAR, GRC 플랫폼으로 전송하세요. 이렇게 하면 고위험 위치가 다른 보안 신호와 동일한 대시보드에 표시됩니다.

명확한 에스컬레이션 트리거를 정의하세요. 예를 들어 새로 생성된 고량의 민감 데이터 저장소, 규제 대상 콘텐츠를 광범위하게 노출시키는 갑작스러운 권한 변경, 또는 기존 저장소에서 분류가 급증하는 경우입니다.

각 트리거는 정해진 응답자에게 라우팅되며, 복구 SLA(서비스 수준 계약)가 적용됩니다. 그 결과물은 분기별 프로젝트가 아니라 운영 역량으로 실행되는 dark data 거버넌스입니다.

다음 감사가 대신 찾아내기 전에, dark data에 맞는 올바른 접근 방식을 선택하세요.

대부분의 dark data 프로그램은 가시성을 확보하기 전에 정책부터 시작합니다. 보관(리텐션) 일정과 data classification 프레임워크는 기억에 기반해 그린 데이터 맵을 기준으로 작성되는데, 이는 운영 시스템, 아카이브, SaaS 통합 전반에 실제로 존재하는 내용과 절대 일치하지 않습니다.

Netwrix Access Analyzer 는 Windows 파일 서버, NAS, SharePoint, Microsoft 365, 주요 데이터베이스 전반에서 sensitive data 를 찾아내고 분류합니다. 또한 각 저장소를 효과적인 권한 분석과 연결해, 누가 해당 저장소에 접근할 수 있는지 보여줍니다.

AWS, Azure, GCP 전반의 클라우드 네이티브 스토어에 존재하는 다크 데이터의 경우, Netwrix DSPM 는 클라우드 데이터 리포지토리에 걸쳐 검색 및 보안 상태(포스처) 관리를 확장하고, 온프레미스 및 하이브리드 Microsoft 환경에서는 Access Analyzer 범위도 함께 제공합니다.

Netwrix Auditor 는 민감한 데이터가 어떻게 액세스되고 수정되는지에 대해 지속적으로 모니터링함으로써 그 가시성을 확장합니다. 함께, 세 가지 도구는 정적인 인벤토리를 운영형 data security 거버넌스로 전환합니다. 즉, 알 수 없는 스토어가 범위에 포함되고, 증거를 기준으로 시정 조치가 추적되며, 생성된 데이터와 거버넌스된 데이터 간의 격차가 매 사이클마다 줄어듭니다.

다음 감사가 여러분을 대신해 격차를 찾아내기 전에, Netwrix가 다크 데이터를 발견하고 액세스를 거버넌스하며 규정 준수 요구 사항을 충족하도록 돕는 방법을 확인하려면 데모를 요청하세요.