M365. Windows 탐색기 MIP 보호 파일 오버레이
시작하기 전에
Microsoft Purview Information Protection(MIP)을 사용하면 Office 문서나 PDF 파일에 민감도 레이블을 적용하고, 필요한 경우 파일 자체를 암호화할 수 있습니다.
그런데 파일이 여러 개 있는 폴더를 Windows 탐색기로 확인하면 어떤 파일이 암호화되어 있고, 어떤 파일이 일반 파일인지 바로 구분하기 어렵습니다.
제가 원하는 것은 레이블 이름이나 권한을 상세하게 보여주는 기능은 아니었습니다. 탐색기에서 파일을 보는 순간 암호화 여부만 육안으로 구분할 수 있으면 충분했습니다.
처음에는 PowerShell 스크립트만으로 가능한지 AI와 디스커션을 진행했습니다. 확인해보니 파일의 보호 상태를 검사하는 부분은 PowerShell로 처리할 수 있지만, 탐색기 아이콘 위에 표시하려면 Windows Shell Extension이 필요했습니다.
그래서 요구사항과 테스트는 제가 진행하고, C#, C++ 및 PowerShell 코드는 AI를 통해 생성하고 수정하는 방식으로 만들었습니다. 제가 전문 개발자 입장에서 만든 것은 아니기 때문에, 엔지니어가 AI를 활용해서 어디까지 구현할 수 있는지 확인한 사례로 봐주시면 될 것 같습니다.
이 도구는 Microsoft의 공식 제품이 아니며 Microsoft의 보증이나 기술지원을 받지 않습니다. 공개된 소스를 자유롭게 확인하고 수정할 수 있지만, 사용 중 발생하는 호환성, 보안, 성능, 데이터 및 운영상의 문제는 사용하는 개인 또는 조직이 직접 책임져야 합니다. 운영 환경에 바로 적용하지 말고 테스트 PC 또는 VM에서 먼저 검증하시기 바랍니다.
GitHub에는 아래의 주소로 공개하였습니다.
https://github.com/Pepuri/mip-protection-overlay-windows
GitHub - Pepuri/mip-protection-overlay-windows
Contribute to Pepuri/mip-protection-overlay-windows development by creating an account on GitHub.
github.com
1. 표시 기준
표시 기준은 복잡하지 않습니다.
- MIP 보호 정보가 있는 파일 → 빨간색 MIP 아이콘 표시
- MIP 보호 정보가 없는 파일 → 기존 아이콘 유지
민감도 레이블 이름을 탐색기에 보여주는 방식이 아니라, 파일에 보호 정보가 존재하는지만 구분합니다. 따라서 현재 테넌트에 해당 레이블이 존재하는지, 현재 사용자가 문서를 열 수 있는 권한이 있는지까지 확인하는 것은 아닙니다.
Powershell 로 조회했을 때, IsRMSProtected 값을 기준으로 감지합니다.
확장자
처음에는 전체 파일을 대상으로 하는 것도 생각했습니다. 하지만 실제 목적은 사용자가 자주 확인하는 Microsoft Office 문서와 PDF였기 때문에 아래의 확장자로 범위를 정했습니다.
.doc
.docx
.xls
.xlsx
.ppt
.pptx
.pdf
.pfile검사 범위를 제한한 이유는 불필요한 파일 이벤트와 검사를 줄이기 위해서입니다.
설치 후 설정 파일은 아래의 경로에 있습니다.
%ProgramData%\PurviewProtectionOverlay\config.json기본 목록 안에서 일부 확장자를 제외하는 것은 이 파일의 extensions 값을 수정하면 됩니다. 새로운 형식을 추가하려면 Agent 설정뿐만 아니라 Explorer DLL의 지원 확장자 목록도 수정한 뒤 다시 빌드해야 합니다. 즉, 현재 값은 제가 테스트한 범위이며 사용 환경에 맞게 수정할 수 있습니다.
2. 감시 경로
경로도 처음에는 특정 폴더만 지정하는 방식으로 시작했습니다. 다운로드한 파일이나 사용자가 임의로 만든 폴더도 확인하려면 결국 로컬 디스크 전체를 기준으로 잡는 편이 맞다고 판단했습니다.
기본 감시 경로는 다음과 같습니다.
"watchRoots": [
"%FIXED_DRIVES%"
]다만 Windows 폴더나 Program Files, ProgramData, AppData까지 검사할 필요는 없습니다. 권한 오류와 불필요한 이벤트가 많아질 수 있고, 사용자가 관리하는 문서 영역도 아니기 때문입니다.
그래서 아래와 같은 시스템 성격의 경로는 기본적으로 제외했습니다.
- Windows 및 Windows.old
- Program Files / Program Files (x86)
- ProgramData
- 사용자 AppData
- Recovery 및 System Volume Information
- 휴지통과 Windows 설치·복구용 임시 경로
추가로 제외할 폴더가 있다면 config.json의 excludedPaths에 등록할 수 있습니다. 반대로 감시할 드라이브나 폴더를 제한하려면 watchRoots를 수정하면 됩니다.
파일 생성, 변경, 삭제 및 이름 변경은 Windows의 FileSystemWatcher 이벤트로 확인합니다. 이벤트를 놓치는 경우를 보완하기 위해 기본 15분 간격으로 상태를 다시 맞추는 과정도 포함했습니다. 이 간격 역시 reconciliationMinutes에서 변경할 수 있습니다.
OneDrive
OneDrive 영역은 이번에 가장 오래 확인한 부분입니다. 처음에는 로컬 폴더에서 동작했으니 OneDrive 동기화 폴더도 동일하게 처리할 수 있을 것으로 생각했습니다.
실제로 Agent가 OneDrive 파일의 경로를 확인하고 보호 여부를 검사하는 것 자체는 가능할 수 있습니다. 문제는 탐색기에 아이콘을 표시하는 단계였습니다.
OneDrive Files On-Demand는 파일의 클라우드, 동기화, 오프라인 상태를 자체 아이콘으로 표시합니다. Windows의 클래식 아이콘 오버레이는 등록 가능한 수가 제한되어 있고, OneDrive 영역에서는 Cloud Files 상태 표시가 우선되기 때문에 제가 만든 오버레이가 호출되지 않는 경우가 있었습니다.
AI와 여러 방식으로 디스커션하고 로컬 폴더와 OneDrive 경로를 나누어 테스트했지만, 모든 장치에서 안정적으로 표시된다고 설명하기는 어렵다는 결론이 나왔습니다. 그래서 현재 버전은 OneDrive Files On-Demand를 지원 범위에서 제외하고, 기본 설정도 excludeOneDrive: true로 지정했습니다.
단순히 감지를 켜는 것과 탐색기에 안정적으로 표시되는 것은 다른 문제였습니다. OneDrive 영역은 Windows Cloud Files API를 기준으로 별도의 방식이 필요할 것으로 보이며, 현재 소스에서는 지원된다고 안내하지 않습니다.
3. 동작 구조
전체 흐름은 아래와 같습니다.
파일 생성 또는 변경
↓
사용자별 백그라운드 Agent
↓
MIP SDK GetFileStatus()로 보호 여부 확인
↓
보호된 파일의 경로만 로컬 캐시에 기록
↓
Explorer 오버레이 DLL이 파일 경로와 캐시를 비교
↓
일치하면 빨간색 MIP 아이콘 표시
Agent
사용자 세션에서 실행되는 Agent가 지정된 확장자와 경로의 파일 변경을 감지합니다. 파일을 확인한 결과 보호 상태이면 사용자별 캐시에 전체 경로를 기록하고, 보호가 해제되거나 파일이 삭제되면 캐시에서도 제거합니다.
캐시 파일은 아래의 경로에 있습니다.
%LOCALAPPDATA%\PurviewProtectionOverlay\protected-files.txt
MIP SDK
보호 여부는 Microsoft Information Protection SDK의 FileHandler.GetFileStatus()로 확인합니다. Microsoft 자료에 따르면 이 방식은 File Engine 생성, 사용자 인증 및 인터넷 연결 없이 파일의 보호 정보를 확인할 수 있습니다.
별도의 Microsoft Purview Information Protection Client는 필요하지 않습니다. 다만 보호 상태를 확인하는 Agent를 빌드하고 실행하기 위해 MIP SDK 구성 요소는 사용됩니다. Tenant ID, Client ID, Client Secret 또는 사용자 로그인 정보는 입력하지 않습니다.
Explorer DLL
탐색기 안에서 MIP SDK를 직접 실행하면 파일이 많은 폴더에서 지연이나 충돌 가능성이 생길 수 있습니다. 그래서 Explorer에 로드되는 네이티브 DLL은 문서를 열거나 보호 상태를 직접 검사하지 않습니다.
Explorer DLL은 요청받은 파일 경로가 로컬 캐시에 있는지만 비교합니다. 실제 검사는 Agent, 표시는 Explorer DLL로 분리한 구조입니다.
문서 내용과 파일 경로를 외부 서비스로 전송하는 기능은 넣지 않았습니다. 캐시와 로그는 해당 PC의 사용자 프로필에 저장됩니다.
4. 지원 범위
| 항목 | 상태 |
|---|---|
| Windows 10/11 x64 | 지원 |
| 일반 로컬 NTFS 폴더 | 지원 |
| DOC/DOCX/XLS/XLSX/PPT/PPTX/PDF/PFILE | 지원 |
| 보호/비보호 상태 구분 | 지원 |
| OneDrive Files On-Demand | 지원하지 않음 |
| 네트워크 드라이브 | 검증하지 않음 |
| Windows ARM64 | 검증하지 않음 |
현재 제가 확인한 환경은 Windows 10/11 x64와 일반 로컬 NTFS 폴더입니다. 네트워크 드라이브와 ARM64는 동작하지 않는다고 단정할 수는 없지만, 직접 검증하지 않았기 때문에 지원 범위로 표시하지 않았습니다.
5. Agent 설치
Intune 패키징과 디지털 서명은 이번 글에서 제외했습니다. 우선 관리자 권한의 64비트 Windows PowerShell에서 빌드부터 로컬 설치까지 한 번에 진행하는 방법입니다.
처음 실행하는 PC에서는 다음 명령을 사용합니다.
git clone https://github.com/Pepuri/mip-protection-overlay-windows.git
cd .\mip-protection-overlay-windows
powershell.exe -NoLogo -NoProfile -NonInteractive `
-ExecutionPolicy Bypass `
-File .\scripts\Invoke-LocalDeployment.ps1 `
-InstallBuildPrerequisites
-InstallBuildPrerequisites는 .NET 8 SDK 또는 Visual Studio 2022 C++/CMake 빌드 구성 요소가 없을 때 사용합니다. 이미 설치되어 있다면 마지막 옵션은 제외할 수 있습니다.
powershell.exe -NoLogo -NoProfile -NonInteractive `
-ExecutionPolicy Bypass `
-File .\scripts\Invoke-LocalDeployment.ps1스크립트는 x64 Explorer DLL과 .NET Agent를 빌드하고, 결과물을 검증한 뒤 UI 없이 설치합니다. 빌드 도구가 없는 PC에서는 설치와 빌드에 시간이 걸릴 수 있습니다.
처음 설치할 때 종료 코드 3010이 반환될 수 있습니다. 이 코드는 실패가 아니라 Explorer 확장을 완전히 로드하기 위해 로그아웃 또는 재부팅이 필요하다는 의미입니다. 일반 사용 환경에서는 Explorer를 강제로 종료하기보다는 재부팅 후 확인하는 편이 좋습니다.
6. 상태 확인
특정 파일이 보호된 것으로 확인되는지는 다음 명령으로 먼저 테스트할 수 있습니다.
.\scripts\Test-ProtectionStatus.ps1 -Path 'C:\Documents\protected.xlsx'Agent 로그는 아래의 경로에서 확인할 수 있습니다.
%LOCALAPPDATA%\PurviewProtectionOverlay\Logs\Agent.log아이콘이 표시되려면 아래의 두 조건을 모두 충족해야 합니다.
- Agent 검사 결과가 보호 상태여야 합니다.
- 파일 경로가
protected-files.txt에 있고 Explorer가 오버레이 DLL을 로드해야 합니다.
즉, 검사 결과가 정상이어도 Explorer가 DLL을 아직 로드하지 않았거나 다른 오버레이와 우선순위가 충돌하면 아이콘이 보이지 않을 수 있습니다. 이 경우 재부팅 후 로그와 캐시를 순서대로 확인하는 것이 좋습니다.
설치가 완료되면, 아래의 화면 처럼 MIP 아이콘이 오버레이 됩니다.
7. Agent 제거
다시 테스트하거나 제거하려면 관리자 PowerShell에서 다음 명령을 실행합니다.
powershell.exe -NoLogo -NoProfile -NonInteractive `
-ExecutionPolicy Bypass `
-File "$env:ProgramFiles\PurviewProtectionOverlay\Uninstall.ps1" `
-RemoveUserCaches `
-RestartExplorer-RemoveUserCaches는 사용자별 캐시를 함께 제거하고, -RestartExplorer는 적용을 위해 Explorer를 다시 시작합니다. 열려 있는 탐색기 창이 종료될 수 있으므로 테스트 PC에서 사용하는 것을 권장합니다.
8. EDR 및 디지털 서명
보안 제품 관점에서는 다음과 같은 동작이 확인됩니다.
- 사용자가 직접 빌드한 미서명 EXE와 DLL 실행
- Explorer 프로세스에 네이티브 Shell Extension DLL 로드
- 사용자 로그온 시 Agent 자동 실행
- 여러 폴더의 Office 및 PDF 파일 상태 확인
- PowerShell을 통한 빌드와 설치 자동화
이러한 동작이 악성이라는 의미는 아닙니다. 다만 EDR의 행위 기반 탐지나 조직의 WDAC/App Control 정책에서는 확인 또는 차단 대상이 될 수 있습니다.
제 테스트 테넌트에서도 MDE EDR에서 아래와 같이 탐지되었습니다.
디지털 서명은 게시자와 파일 무결성을 확인하는 데 도움이 되지만, 서명했다고 모든 EDR 경고가 사라지거나 프로그램의 안전성이 자동으로 보장되는 것은 아닙니다.
탐지를 피하기 위해 Program Files 전체, PowerShell 전체 또는 Explorer 전체를 예외로 등록하는 방식도 권장하지 않습니다. 예외가 필요하다면 먼저 소스와 해시, 실행 행위 및 탐지 근거를 확인하고, 보안 담당자 승인 아래 파일, 인증서 또는 해시 단위의 최소 범위로 적용해야 합니다.
기업 환경에서는 최소한 테스트 그룹 배포, 소스 검토, 코드 서명, MDE 탐지 결과 및 App Control 정책 확인을 진행한 뒤 운영 적용 여부를 판단해야 합니다.
9. 공개 범위와 책임
소스는 MIT License로 공개했습니다. 라이선스 조건에 따라 누구나 사용하고 수정하며 개선 내용을 다시 공유할 수 있습니다.
다만 MIP SDK와 함께 사용되는 구성 요소는 각각 별도의 라이선스가 적용될 수 있습니다. 배포하거나 결과물을 다시 제공하려면 GitHub의 THIRD-PARTY-NOTICES.md와 각 구성 요소의 조건을 직접 확인해야 합니다.
이 소프트웨어는 어떠한 보증도 없이 제공됩니다. 운영 환경 적용, 보안 예외, 성능 영향, 호환성 검증, 장애 대응 및 데이터 보호에 대한 최종 책임은 사용자에게 있습니다.
10. 다음 내용
이번 글에서는 로컬 x64 환경의 구조와 PowerShell 설치까지만 정리했습니다.
다음에는 아래의 내용을 실제 테스트를 기준으로 정리해 볼 예정입니다.
- Microsoft Intune Win32 앱 패키징과 사일런트 배포
- Microsoft Defender for Endpoint에서 확인되는 실행 및 탐지 흔적
- Advanced Hunting을 통한 미서명 파일과 프로세스 확인
- AD CS, 공인 코드 서명 인증서, Microsoft Artifact Signing 비교
- Explorer DLL과 Agent의 디지털 서명
- EDR 및 App Control 예외의 최소 범위 설계
정리
제가 원한 것은 Windows 탐색기에서 MIP 암호화 여부를 빠르게 구분하는 단순한 기능이었습니다. 확인하는 과정에서는 파일 감지보다 Explorer 오버레이와 OneDrive 처리에서 더 많은 시행착오가 있었습니다.
결론적으로 일반 로컬 폴더는 Agent와 캐시, Explorer DLL을 분리하는 방식으로 표시할 수 있었습니다. 반면에 OneDrive Files On-Demand는 안정적인 표시를 보장하기 어려워 현재 범위에서는 제외했습니다.
AI를 활용하면 개발 경험이 많지 않은 엔지니어도 요구사항을 정리하고 동작하는 도구를 구현할 수 있습니다. 하지만 AI가 만든 코드는 완성품으로 바로 신뢰하는 것이 아니라, 실제 환경에서 오류를 확인하고 보안 검토를 반복해야 합니다.