알려지지 않은 데이터 자산을 찾고 보호하는 방법
Oct 6, 2026
알려지지 않은 데이터 자산은 분류, 접근 거버넌스 및 지속적인 가시성 밖에 위치한 추적되지 않은 저장소로 인해 보안, 규정 준수 및 사이버 복원력을 약화시키는 인벤토리 격차를 만듭니다. 팀은 민감한 콘텐츠를 평가하거나 효과적인 접근을 확인하거나 자산과 권한이 변경됨에 따라 Data Security Posture Management를 최신 상태로 유지할 수 없습니다. 지속적인 발견, 분류 및 접근 검토가 격차를 해소합니다.
대부분의 데이터 보안 프로그램은 존재하는 자산만 보호할 수 있습니다. 인벤토리 외부의 shares, buckets 및 내보내기도 분류, 액세스 거버넌스 및 지속적인 모니터링 범위 밖에 있어 민감한 데이터가 더 오래 노출될 수 있는 사각지대를 만듭니다.
이러한 사각지대는 침해 데이터에서 나타납니다. 섀도우 데이터는 분석된 침해 사례의 35%에서 나타났습니다 IBM's Cost of a Data Breach Report 2024, 섀도우 데이터를 구분한 최신 판입니다. 섀도우 데이터가 포함된 침해는 식별 및 대응에 더 오랜 시간이 걸렸으며, 평균 수명 주기는 291일, 평균 비용은 527만 달러였습니다. 불완전한 인벤토리는 탐지 및 대응을 저해합니다.
이것이 바로 National Institute of Standards and Technology Cybersecurity Framework (NIST CSF) 2.0이 데이터 인벤토리와 해당 메타데이터 유지를 강조하는 이유입니다.
이러한 인벤토리는 DLP, 분류, 액세스 검토 및 지속적인 모니터링과 같은 제어의 기반을 제공합니다. 데이터 저장소가 인벤토리에 없으면 해당 제어가 이를 포함할 가능성이 훨씬 낮습니다.
알려지지 않은 데이터 자산이란 무엇인가요?
알려지지 않은 데이터 자산은 조직의 현재 인벤토리에 없는 모든 데이터 저장소를 의미하며, 프로젝트가 끝난 공유, 보조 클라우드 계정의 버킷, 떠난 분석가가 남긴 내보내기 등이 포함됩니다. 이 용어는 dark data와 shadow data를 포함하지만, 아무도 현재 이를 관리하지 않는다면 자산은 조사할 가치가 있습니다.
Term | What creates it | Where it typically lives | Urgency signal |
|---|---|---|---|
|
Dark data |
Data collected but never analyzed or acted on |
Cloud buckets, legacy shares, SaaS exports, AI caches, log repositories |
Lower until classification shows sensitive content |
|
Shadow data |
|||
|
Unknown data assets |
This guide's operational term for any asset absent from the current inventory, for any reason |
Anywhere: on-premises shares, cloud storage, backups, forgotten SaaS repositories |
Depends on content; the inventory gap defines the category |
알려지지 않은 데이터 자산이 계속 쌓이는 이유
새 자산은 수동 인벤토리가 기록하는 것보다 더 빨리 도착하므로 시점 검토 후에도 격차가 해소되지 않고 지속됩니다.
- 직원 제공 스토리지: 직원들은 승인된 옵션이 느리거나 제한적일 때 자체 클라우드 스토리지 계정을 엽니다. Netskope Threat Labs' Cloud and Threat Report: 2026 에 따르면 평균 조직의 31% 사용자가 매달 개인 클라우드 앱에 데이터를 업로드하며, 60%의 insider threat 사건이 개인 클라우드 앱 인스턴스와 관련되어 있습니다.
- SaaS 확산: SaaS 도입은 광범위한 기술 확산을 가중시킵니다. Forrester의 2024년 2분기 Tech Pulse 설문조사 에 따르면 미국 기술 의사 결정자의 77%가 중간에서 광범위한 기술 확산을 보고했습니다.
- 고아 시스템: 애플리케이션 폐기는 소유자가 없는 상태로 원본 시스템보다 오래 지속되는 백업 및 내보내기를 남길 수 있습니다. 클라우드 플랫폼은 수동 Amazon Relational Database Service (RDS) 스냅샷이 원본 인스턴스 삭제 후에도 유지되기 때문에 이를 기본 동작으로 만듭니다.
- Shadow AI 도입: Generative AI(GenAI) 도구는 사용자가 프롬프트에 민감한 데이터를 붙여넣거나 도구를 데이터 소스에 연결할 때 민감한 데이터를 복사합니다. 175명 직원을 대상으로 한 Gartner 설문조사에서 2026년 2월 5일에 발표된 결과, 57% 이상이 업무용 개인 GenAI 계정을 사용했으며 33%는 승인되지 않은 도구에 민감한 정보를 입력했다고 인정했습니다.
재고 격차가 대부분의 보안 팀이 생각하는 것보다 더 중요한 이유
인벤토리 범위는 각 Data Security Control이 도달할 수 있는 자산을 결정합니다. 해당 범위를 벗어난 노출은 측정되지 않습니다.
아무도 존재를 모르는 자산에는 어떤 통제도 미치지 못합니다
DLP, SIEM, access governance 및 암호화는 지정된 저장소만 보호합니다. 아무도 분류하거나 카탈로그하지 않은 저장소는 통제 범위 밖에 있어 가시성이 줄어들고, 관리되지 않는 노출이 확대되며, 사고 대응 준비가 지연됩니다.
대부분의 조직은 이 격차를 알고 있지만 해결하지 못했습니다
The Netwrix 2026 Data and Identity Security Report는 2,317명의 IT 및 보안 리더를 조사하여 충격적인 결과를 도출했습니다. 55%의 조직이 민감한 데이터 인벤토리를 지속적으로 유지하지 않으며, 74%는 민감한 데이터가 어디에 저장되어 있고 어떤 아이덴티티가 접근할 수 있는지 단일 통합 뷰를 얻지 못합니다. 지속적인 인벤토리 유지 및 통합된 접근 가시성은 여전히 드뭅니다.
알 수 없는 자산이 침해 포렌식에서 불균형적으로 나타납니다
Unit 42 2025 글로벌 사고 대응 보고서는 엔드포인트, 애플리케이션 및 섀도우 IT를 포함한 관리되지 않고 모니터링되지 않는 자산을 공격자가 쉽게 침입할 수 있는 진입점으로 지목합니다.
McLeod Health는 2026년 3월 5일 서버 폐기 중에 의심스러운 파일을 발견했다고 사건 공지에 밝혔으며, 이는 2025년 10월 17-18일 무단 접근 후 137일 만입니다. 지속적인 자산 가시성은 사고 대응 시 해당 시스템이 나타날 때 더 빠른 조사와 강력한 사이버 복원력을 지원합니다.
Netwrix DSPM은 온프레미스, 클라우드 및 SaaS 환경에서 민감한 데이터를 찾아 액세스 위험을 우선순위로 지정하여 보안 팀이 가장 중요한 사항에 집중할 수 있도록 합니다. 데모를 예약하세요.
알려지지 않은 데이터 자산을 찾기 위한 반복 가능한 방법
각 환경에는 고유한 열거 도구와 사각지대가 있으므로 이러한 차이를 반영하기 위해 환경별로 탐색을 실행해야 합니다.
먼저 모든 환경에 대한 읽기 전용 액세스를 받으세요
Discovery는 계정이 볼 수 있는 것만 찾으므로, 단일 열거를 실행하기 전에 각 환경에 대해 읽기 전용 액세스를 요청하세요. 공유 관리자 자격 증명 대신 명명된 전용 ID를 사용하여 모든 discovery 쿼리를 추적할 수 있도록 하세요.
- 온프레미스: Active Directory에 대한 읽기 액세스, 각 서버에 대한 원격 관리 경로, 쿼리하는 각 SQL Server 인스턴스에 대한 로그인입니다. 아래 워크플로우는 CIM 세션을 통해 원격 서버에 접근합니다.
- AWS: 관리 계정 또는 위임된 관리자로 로그인하여 조직 전체 AWS Config 집계기를 생성하고 관리형 정책 AWSConfigRoleForOrganizations 을 역할에 연결하세요.
- Azure: 관리 그룹 수준에서 읽기 권한을 부여하세요. Azure Resource Graph는 계정이 읽을 수 없는 리소스에 대해 결과를 반환하지 않으므로 권한이 없으면 일부 자산이 비어 있는 것처럼 보일 수 있습니다.
- Google Cloud: 검색하는 조직, 폴더 또는 프로젝트에 Cloud Asset Viewer (roles/cloudasset.viewer) 권한을 부여하세요.
- Entra ID 및 SaaS: Microsoft Graph를 통한 위임된 OAuth 권한 나열는 Directory.Read.All 권한이 필요하며, 로그인한 관리자는 Global Reader와 같은 역할이 필요합니다.
- 백업 및 스냅샷: 이들은 백업 콘솔 또는 클라우드 스냅샷 API 뒤에 위치하며, 소스 시스템이 아니므로 접근 요청에 포함해야 합니다.
- 등록되지 않은 앱: 아무도 등록하지 않은 앱은 읽을 관리자 기록이 없습니다. 대신 Defender for Endpoint, 로그 수집기 또는 업로드된 방화벽 및 프록시 로그에서 Cloud Discovery를 공급하세요.
읽기 전용 계정이 접근할 수 없는 모든 것은 자체적으로 발견 사항입니다. 이를 접근 격차로 기록하고 의사 결정을 위해 에스컬레이션하세요.
온프레미스 서버, 공유 및 데이터베이스
Active Directory에서 시작하여 바깥쪽으로 작업하세요. 이는 점검할 온프레미스 시스템 전체 목록을 가장 빠르게 얻는 방법입니다.
- Get-ADComputer를 사용하여 Active Directory에서 파일 서버 호스트 이름을 가져옵니다
Get-ADComputer참조를 따라.Get-ADComputer 참조. - Common Information Model(CIM) 세션을 통해 Server Message Block(SMB) 공유를 나열합니다.
Get-SmbShare -Special $false를 사용하여 관리 공유를 제외합니다. - SQL Server에서
sys.servers를 호출하여 종종 아무도 문서화하지 않은 인스턴스를 가리키는 모든 연결되거나 원격 서버를 반환합니다.
이 PowerShell 워크플로로 1단계와 2단계를 한 번에 실행하세요:
$servers = Get-ADComputer -Filter * -Properties OperatingSystem |
Where-Object OperatingSystem -Like '*Server*'
foreach ($server in $servers) {
$session = New-CimSession -ComputerName $server.DNSHostName
Get-SmbShare -CimSession $session -Special $false
Remove-CimSession $session
}
출력물은 이미 문서화된 내용과 비교할 수 있는 전체 공유 및 서버 인벤토리입니다. 문서에 누락된 항목은 알 수 없는 자산입니다.
클라우드 스토리지, 백업 및 데이터베이스
각 공급자는 자체 인벤토리 도구를 보유하고 있으므로 결과를 비교하기 전에 각 공급자에서 별도로 열거 작업을 실행해야 합니다.
- 사용 중인 각 공급자의 조직 수준에서 저장소 리소스를 나열합니다. AWS Config 구성 집계기는 Amazon Web Services를 포함하며, Azure Resource Graph 쿼리는
Microsoft.Storage/storageAccounts관리 그룹 범위에서 최대 10,000개의 Microsoft Azure 구독을 포함하고, Cloud Asset Inventory는 Google Cloud의storage.googleapis.com/Bucket자산 유형을 검색합니다. - AWS에서 Elastic Block Store(EBS)의 AWSSupport-AnalyzeEBSResourceUsage 런북을 실행하여 사용 가능한 상태의 볼륨과 원본 볼륨이 더 이상 존재하지 않는 스냅샷을 나열합니다.
AWSSupport-AnalyzeEBSResourceUsagerunbook in AWS to list volumes in available state and snapshots whose source volume no longer exists. - 사용자가 소스 리소스의 프로비저닝을 해제한 후 남은 비프로비저닝 복구 지점을 위해 Azure의 Business Continuity Center를 확인하세요.
- 결합된 결과를 현재 인벤토리와 비교하고, 이름이 지정된 활성 프로젝트가 없는 모든 스토리지 계정, 볼륨 또는 복구 지점을 검토 후보로 간주하세요. 기본 도구는 등록된 리소스만 보기 때문입니다.
현재 인벤토리에 없는 모든 결과는 소스 시스템이 여전히 작동하는지 여부와 관계없이 정의상 알 수 없는 자산입니다. 2025년에 보안 연구원 Jeremiah Fowler는 Navy Federal Credit Union 백업 파일 378기가바이트가 정확히 이런 식으로 노출되어 아무도 추적하지 않는 공개 Amazon S3 버킷에 저장되어 있는 것을 발견했습니다.
SaaS 애플리케이션, OAuth 권한 및 shadow AI
Entra ID 및 거버넌스 대시보드는 누군가 이미 등록하거나 동의한 앱만 표시하므로, 아무도 등록하지 않은 앱을 찾으려면 별도의 트래픽 기반 단계가 필요합니다.
- 방화벽, 프록시 또는 엔드포인트 트래픽 로그에 대해 Defender for Cloud Apps Cloud Discovery를 실행하여 모든 사용 중인 SaaS 앱을 표시합니다. 여기에는 Open Authorization (OAuth) 권한 부여 또는 관리자 기록이 없는 앱도 포함됩니다.
- Cloud Discovery 결과를 Microsoft의 생성형 AI 앱 카테고리로 필터링하여 승인되지 않은 AI 도구만을 구체적으로 분리하세요.
- Edge 및 Chrome용 Purview 브라우저 확장 프로그램을 Insider Risk Management의 Risky AI 사용 템플릿에 연결하여 온보드된 장치에서 민감한 정보가 포함된 프롬프트와 응답을 감지하고 Cloud Discovery의 트래픽 로그에서 볼 수 없는 콘텐츠를 포착합니다.
- 표준 SharePoint 공유 보고서에는 Anyone 링크가 제외되므로 외부 공유 링크를 별도로 검토하세요. SharePoint 관리 센터의 Data Access Governance 보고서에는 포함되지만 해당 SharePoint 관리 애드온이 필요하며 28일 기간을 다룹니다.
- 승인된 AI 배포 전에 필수 SharePoint 관리 애드온인 Everyone Except External Users(EEEU) 보고서를 실행하세요. 이 보고서는 지난 28일 동안 조직 전체와 공유된 상위 100개 사이트를 나열합니다. Copilot이 활성화되는 순간 이 모든 사이트는 AI 검색이 가능해집니다. Copilot은 사용자가 이미 접근 권한을 가진 데이터를 기반으로 응답을 생성하기 때문입니다.
어떤 알 수 없는 자산이 중요한지 알아내는 방법
모든 추적되지 않은 자산이 동일한 긴급성을 요구하는 것은 아닙니다. 자산 위치가 얼마나 불분명하든 콘텐츠와 접근 권한이 우선순위를 정해야 합니다.
위치보다 콘텐츠를 우선시하세요
다음이 포함된 자산은 personally identifiable information (PII), protected health information (PHI) 또는 결제 카드 데이터가 포함되어 있으면 경로가 얼마나 불분명하든 긴급합니다. 민감하지 않은 데이터의 복제본은 기다릴 수 있습니다.
NIST SP 800-122은 여섯 가지 기밀성 영향 요인을 나열하며, 이들이 상호 작용한다고 경고합니다. 한 요인만으로는 낮은 영향 수준을 나타낼 수 있지만 다른 요인이 이를 무시하고 높은 영향으로 바꿀 수 있습니다. 전체 프레임워크에 대해서는 complete NIST impact guidance를 검토하세요.
노이즈로 간주하기 전에 분류하세요
패턴 기반 및 컨텍스트 기반 classification을 사용하여 실제 노출과 잡음을 구분하세요. 민감한 정보 유형에 대한 Purview 신뢰 수준은 65, 75 또는 85이며, 낮은 설정은 가장 많은 일치 항목과 가장 많은 오탐을 포착합니다.
Visa의 4111111111111111과 같은 알려진 테스트 기본 계좌 번호는 Luhn 검증을 통과하므로, 수정 시간을 낭비하지 않도록 허용 목록이나 정확한 일치 참조 테이블을 통해 제외하세요.
광범위한 액세스와 민감한 콘텐츠를 먼저 표시하세요
NIST SP 800-122는 더 많은 사람과 시스템이 PII에 접근할수록 기밀성이 위험해질 기회가 많아진다고 설명합니다. Everyone, Authenticated Users 또는 공개 공유 링크로 접근 가능한 민감한 데이터를 접근 범위가 엄격한 민감한 데이터보다 우선적으로 조치해야 할 첫 번째 단계로 간주하세요.
발견한 알려지지 않은 데이터 자산을 보호하는 방법
Netwrix 2026 보고서에 따르면 사고 기반 데이터 노출의 75%가 손상된 신원 또는 잘못 구성된 권한에서 시작되므로 신원이 이후 모든 단계를 좌우합니다.
무엇보다 먼저 액세스를 수정하세요
민감한 데이터가 확인되었거나 광범위하게 노출된 새로 발견된 자산마다 우선 과도한 접근을 제한하세요. 콘텐츠의 민감도가 아직 알려지지 않은 경우 신속히 분류하여 최종 수정 우선순위를 결정하세요.
아무도 검토하지 않는 권한은 자산을 노출 상태로 유지하며, Verizon 2026 Data Breach Investigations Report에 따르면 권한 오구성 발견의 절반이 해결하는 데 거의 8개월이 걸렸습니다.
ACL에서 Everyone 및 Authenticated Users를 제거하고 Anyone 링크를 만료시키십시오(CISA의 ScubaGear 기준은 기본 공유 범위를 "Specific people"로 설정함). 그리고 least privilege를 NIST AC-6에 따라 지속적인 모니터링 시작 전에 적용하십시오.
모든 자산에 대해 "누가 접근할 수 있으며 접근해야 하는가?"에 답하세요
이 질문에 답하려면 효과적인 액세스 분석이 필요합니다. 원시 ACL은 전체 결과를 보여주지 않기 때문입니다. 일부 identity 경로는 별도의 주의가 필요합니다.
Microsoft Entra ID에서 transitiveMemberOf는 사용자 및 서비스 주체에 대해 중첩된 그룹을 평탄화하지만, 애플리케이션 할당은 중첩 그룹에 전파되지 않으므로 디렉터리 나열만으로는 누가 앱을 열 수 있는지 과대평가됩니다.
모든 링크는 디렉터리 쿼리 외부에 완전히 존재하므로 공유 링크 감사를 별도로 검토하고 비인간 아이덴티티도 검토에 포함하세요.
자산은 접근할 수 있는 모든 인간 또는 비인간 정체성에 이름과 확인된 접근 사유가 있을 때까지 보호되지 않습니다.
자산을 지속적으로 모니터링하세요
자산을 인벤토리하고 접근을 수정한 후에는 파일 공유 감사 이벤트 또는 동등한 클라우드 감사 추적을 포함하여 다른 모든 곳에서 사용하는 동일한 지속적인 가시성을 적용하고, NIST CA-7 지속 모니터링 및 CM-3 변경 관리도 적용하여 권한이 다시 변경되지 않도록 하십시오.
섀도 데이터는 기존 접근 제어 및 데이터 접근을 모니터링하고 기록하는 도구를 벗어나 "알려졌지만 모니터링되지 않음"이 "알려지지 않음"과 별개의 자체 위험 범주가 됩니다. Data Security Posture Management의 지속적인 가시성은 두 범주를 측정 가능한 작업으로 만듭니다.
Netwrix가 알 수 없는 데이터 자산을 찾고 보호하는 방법
대부분의 발견 작업은 세 가지에서 멈춥니다: 실제로 민감한 것이 무엇인지 아는 것, 누가 접근할 수 있는지 아는 것, 그리고 누군가 요청할 때 둘 다 증명하는 것입니다.
탐지에서 수정까지의 격차 해소
Netwrix DSPM은 하이브리드 환경 전반에서 민감한 데이터를 찾고 보호하며, 규정 준수 위험을 우선순위로 지정하고 위험한 접근을 처리하는 포괄적인 기능을 제공합니다.
Netwrix Access Analyzer는 엔터프라이즈 Data Security Posture Management 엔진으로서 데이터 검색, 분류, Data Access Governance 및 파일 시스템, SharePoint, 데이터베이스, 클라우드 스토리지를 아우르는 40개 이상의 데이터 수집 모듈을 제공합니다.
원시 권한을 효과적인 액세스로 전환
Access Analyzer는 중첩된 그룹 멤버십을 해석하여 객체에 나열된 원시 권한 대신 사용자가 실제로 가진 액세스를 보여주므로 팀이 실제 액세스를 직접 검토할 수 있습니다.
위험 기반 우선순위 지정은 이 가이드에서 권장하는 동일한 분류 절차에 따라 개방적이거나 과도한 접근과 확인된 민감한 콘텐츠가 결합된 민감한 데이터에 대한 수정 작업을 지시합니다. 팀은 데이터 소유자를 지정하고 노출된 위험에 대한 수정 결정을 추적할 수 있어 일회성 정리를 반복 가능한 거버넌스 프로세스로 전환합니다.
수정 사항이 효과가 있었음을 입증
규제된 데이터를 보유한 서버에서 27,000건의 파일 변경이 예상치 못하게 급증했습니다 Cheshire County Government. 5명으로 구성된 IT 팀은 권한 설정 오류로 변경 사항을 추적하고 Netwrix Auditor를 사용하여 Active Directory 및 Windows 파일 서버에서 15분 만에 조사를 종료했습니다. 수동 로그 검토에 며칠이 걸렸을 것입니다.
First National Bank Minnesota는 소득 확인 기록, 사회 보장 번호 및 고용 기록을 엄격한 필요에 따라 잠그기 위해 Active Directory 환경을 재구축했습니다. Netwrix Auditor는 민감한 데이터가 정확히 어디에 있는지, 누가 접근할 수 있는지 보여주었으며, 은행은 6개월 예산을 잡았던 재구축을 3주 만에 완료했습니다.
전체 자산에 동일한 모델 확장
Access Analyzer는 Microsoft 환경과 Amazon S3를 포함한 온프레미스 및 클라우드 데이터 소스 전반에 걸친 검색 및 분류를 지원하며, Azure Files도 지원하여 동일한 분류 및 액세스 검토 모델이 파일 서버에서 클라우드 및 SaaS 저장소로 이어집니다.
클라우드 스토리지와 SaaS OAuth 연결은 앱 자산의 상당 부분이 섀도 IT로 유입되기 때문에 시작하기에 가장 방어하기 좋은 지점인 경우가 많습니다. 거기서부터 동일한 검토가 온프레미스 공유, 백업 및 내보내기로 확장됩니다.
침해가 발생하기 전에 인벤토리 격차를 해소하세요
재고 격차는 오래 문서 문제로 남지 않습니다. 알 수 없는 자산이 민감한 데이터나 개방된 접근 권한을 보유하는 순간 보안 통제 격차가 되며, 그 비용은 스프레드시트 행이 아닌 침해 타임라인에서 나타납니다.
모든 환경에서 지속적으로 탐색을 실행하고, 편의성보다 콘텐츠와 접근성을 우선시하며, 모니터링으로 루프를 닫아 한 번 나타난 자산이 다시 사라지지 않도록 하세요.
데모 요청하여 Netwrix DSPM이 미확인 데이터 자산을 관리되고 지속적으로 모니터링되는 인벤토리의 일부로 전환하는 방식을 확인하세요.
알려지지 않은 데이터 자산을 찾고 보호하는 방법에 대한 자주 묻는 질문
공유하기
더 알아보기
저자 소개