Microsoft 365 Copilot 환경에서 SharePoint/OneDrive 외부 공유를 “권한 + DLP + 민감도 라벨”로 이중·삼중 차단하는 방법을 실무 흐름대로 정리했습니다.
매일 엑셀 반복 작업에 시달리던 실무자 A씨는 Copilot로 보고서 초안을 빠르게 만들기 시작하면서, 팀 문서가 SharePoint에 더 많이 쌓이기 시작했습니다. 문제는 속도가 빨라진 만큼 “어떤 문서가 어디로 공유되는지”도 더 빨라졌다는 점입니다. 어느 날 A씨가 거래처에 파일을 보내려다가, 실수로 ‘링크가 있는 모든 사용자(Anyone)’ 공유를 선택해 외부로 열릴 뻔했고, 보안팀은 뒤늦게 감사 로그를 뒤져 원인을 찾느라 밤을 새웠습니다.
AI 서비스 도입을 고민하는 기획자 B씨의 고민은 조금 다릅니다. “Copilot이 문서를 요약하고 답변을 만들 때, 외부 공유가 열려 있으면 데이터가 새는 것 아닌가?”라는 질문을 반복합니다. 여기서 중요한 포인트는 Copilot 자체가 임의로 외부로 공유를 “만드는” 기능이 아니라, 조직의 Microsoft 365 보안·권한 경계 안에서 데이터를 참조한다는 점입니다. 즉, SharePoint 권한/링크 정책이 허술하면 Copilot 도입 여부와 무관하게 위험이 커지고, 반대로 권한·DLP·라벨이 제대로 맞물리면 Copilot을 쓰더라도 외부 유출 리스크를 실질적으로 낮출 수 있습니다.
- 외부공유 차단은 “SharePoint 테넌트 정책 + 사이트별 정책 + 링크 유형/만료 + 게스트 권한”을 먼저 잠그고, 그 위에 DLP/라벨로 보강해야 실제로 막힙니다.
- DLP는 ‘공유 자체를 금지’하기보다 “민감 데이터가 포함된 파일이 외부 사용자/게스트로 공유되거나 외부 도메인으로 나갈 때 차단”하도록 설계하는 것이 운영 현실에 맞습니다.
- Copilot 사용 환경에서는 ‘권한 과다’와 ‘링크 기반 과공유’가 가장 흔한 사고 원인이므로, 기본 링크를 ‘조직 내부 전용’으로 고정하고 예외는 승인 흐름으로 관리하는 방식이 효과적입니다.
1) 먼저 정리: “외부공유 차단”에서 자주 생기는 오해 3가지
오해 1: DLP만 켜면 외부공유가 완전히 막힌다
DLP는 강력하지만, “공유 자체를 전면 금지하는 스위치”로 이해하면 운영이 꼬이기 쉽습니다. DLP는 주로 ‘특정 민감정보가 포함된 콘텐츠가 특정 경로로 나갈 때’ 탐지·차단·감사하는 정책 계층입니다. 외부공유의 기본값(Anyone 링크, 만료 없음, 게스트 권한 과다)이 열려 있으면, DLP가 모든 경우를 완벽히 덮지 못하거나 오탐/누락이 늘어납니다.
오해 2: SharePoint 사이트 권한만 조이면 된다
실무 사고는 사이트 권한보다 ‘링크 기반 공유(Anyone/Specific people)’에서 자주 납니다. “사이트는 멤버만 접근”인데도, 문서 라이브러리/파일 공유 링크가 외부로 열려 있으면 유출로 이어질 수 있습니다. 따라서 테넌트 레벨의 링크 기본값과 사이트별 외부공유 허용 범위를 함께 잠가야 합니다.
오해 3: Copilot이 있으면 데이터가 더 쉽게 외부로 나간다
Copilot은 Microsoft 365의 권한 경계 안에서 동작합니다. 외부 유출의 핵심 원인은 대개 Copilot이 아니라 기존의 과공유/게스트 정책 허점입니다. Copilot 도입 시점은 오히려 권한·라벨·DLP를 재정비할 좋은 타이밍입니다.
💡 인공지능 인사이드 팁: “외부공유를 완전히 막겠다”는 목표를 먼저 ‘대상’으로 나누는 것이 운영에 유리합니다. (1) 전사 기본값은 내부 전용으로 고정 (2) 협력사 프로젝트 사이트만 예외 허용 (3) 예외는 만료·도메인 제한·승인 흐름으로 통제…처럼 단계화하면, 현업 반발 없이 보안 수준을 끌어올리기 쉽습니다.
2) 목표 아키텍처: 권한(SharePoint) + 라벨(Purview) + DLP(Endpoint/Cloud) 연동 흐름
인공지능 인사이트 에디토리얼 팀의 분석 결과, 2026년 현재 기업에서 가장 재현성이 높은 설계는 다음 3계층을 동시에 두는 방식입니다.
① SharePoint/OneDrive 공유 경계(기본값 잠금)
테넌트 정책에서 “기본 공유 링크 유형”을 내부 전용으로 고정하고, Anyone 링크는 원칙적으로 차단하거나 최소화합니다. 사이트별로는 외부공유가 필요한 협업 사이트만 예외로 허용합니다.
② 민감도 라벨(암호화/공유 제한/자동 라벨링)
민감도 라벨로 “외부 공유 불가” 또는 “특정 도메인만 허용” 같은 정책을 걸어 콘텐츠 자체에 보호를 부여합니다. 라벨은 파일이 이동/복사되어도 따라가는 보호(정책 설계에 따라)가 가능해 DLP의 빈틈을 줄입니다.
③ DLP 정책(클라우드/엔드포인트)으로 ‘공유 시도’ 차단 + 감사
DLP는 “외부 사용자와 공유하려는 순간”, “게스트가 접근하는 순간”, “민감 데이터가 포함된 문서를 특정 위치로 옮기는 순간”에 차단/경고/승인 워크플로를 수행하게 만듭니다.
Copilot 관점에서는, 위 세 계층이 정리되어 있을수록 “Copilot이 참조할 수 있는 자료의 범위가 올바르게 제한”되어 잘못된 과다노출(oversharing) 이슈가 줄어듭니다.
🔗 Microsoft Learn(SharePoint/Purview/Copilot 공식 문서 허브)
🔗 Microsoft Purview(민감도 라벨·DLP) 공식 문서
3) 1단계: SharePoint/OneDrive에서 “외부공유”를 구조적으로 잠그는 권한·링크 정책
외부공유 차단을 DLP로만 해결하려고 하면, ‘정책은 복잡한데 사고는 계속 나는’ 상황이 생깁니다. 먼저 SharePoint 관리센터에서 공유 기본값을 잠그는 것이 정석입니다(조직마다 UI/메뉴는 업데이트로 달라질 수 있으나 개념은 동일).
(A) 테넌트(전사) 공유 기본값 설정
최근 공식 기술 문서의 권고 흐름을 요약하면 다음과 같습니다.
- 외부 공유 수준: 기본은 “새 게스트 초대 제한” 또는 “기존 게스트만” 등 조직 정책에 맞춰 최소 권한으로 시작
- 기본 링크 유형: “조직 내 사용자(people in your organization)”로 고정
- Anyone 링크: 원칙적으로 비활성화(필요 시 만료일 강제 + 다운로드 차단/추적 옵션 검토)
- 링크 만료: 외부 공유 예외 사이트는 만료일을 짧게(예: 7~30일) 강제
- 도메인 허용/차단 리스트: 협력사 도메인 allowlist 중심 운영 권장
(B) 사이트별 예외 설계(협업 사이트만 외부공유 허용)
전사 기본값을 잠근 후, “협력사 프로젝트 사이트” 같은 제한된 범위에서만 외부공유를 허용합니다. 이때 중요한 건 사이트 소유자에게 과도한 재량을 주지 않는 것입니다. 사이트 생성/외부공유 예외는 요청-승인 프로세스로 묶는 편이 운영상 안정적입니다.
(C) 게스트 권한 최소화(읽기/다운로드/재공유 통제)
외부공유를 허용하더라도 게스트가 다시 공유할 수 있으면 통제가 어려워집니다. 게스트의 재공유 제한, 다운로드 제한(가능한 경우), 접근 리뷰(Access Review) 주기 운영을 권장합니다.
4) 2단계: 민감도 라벨로 “외부 공유 불가 콘텐츠”를 명확히 정의
DLP 정책은 규칙이 복잡해질수록 운영 부담이 커집니다. 반면 민감도 라벨은 “이 문서는 외부 공유 금지” 같은 의도를 사용자/시스템 모두에게 명확하게 전달합니다. 특히 Copilot을 쓰는 조직에서는 사용자가 생성·편집·요약하는 문서가 늘어나므로, 라벨을 통해 데이터 분류의 기준을 자동화하는 편이 중요해졌습니다.
추천 라벨 예시(단계형)
- Public: 외부 공유 허용(단, 브랜드/저작권 가이드 준수)
- Internal: 기본 라벨(조직 내부 공유)
- Confidential: 외부 공유 제한(특정 도메인만 허용 또는 외부 공유 불가)
- Highly Confidential: 외부 공유 불가 + 강한 보호(암호화/오프라인 접근 제한 등)
자동 라벨링(가능하면 단계적으로)
예: 주민등록번호/여권번호/계좌번호 같은 고위험 식별정보, 또는 특정 프로젝트 코드/고객명 패턴이 포함되면 “Confidential 이상”으로 자동 라벨링을 적용합니다. 처음부터 과도하게 적용하면 오탐으로 반발이 커지므로, ‘감사 모드 → 경고 → 차단’ 순으로 성숙도를 올리는 방식을 권장합니다.
🔗 민감도 라벨(Sensitivity labels) 공식 문서
5) 3단계: Purview DLP로 “외부공유 시도”를 차단하는 정책 설계(핵심)
이 글의 핵심은 “외부공유를 막는 DLP 연동”입니다. 실무적으로는 아래 3가지를 동시에 노립니다.
- 민감 데이터가 포함된 파일이 외부 사용자/게스트와 공유되는 것을 차단
- 민감 데이터가 포함된 파일이 Anyone 링크로 공유되는 것을 차단
- 예외가 필요한 경우: 근거 기록(비즈니스 사유) + 승인 또는 사용자 정당화(Justification) + 감사 로그 확보
(A) DLP 정책 범위(Workloads) 선택
최신 Purview 흐름에서는 일반적으로 다음 워크로드를 포함하는 구성이 많이 사용됩니다.
- SharePoint sites
- OneDrive accounts
- Microsoft Teams(파일은 결국 SharePoint에 저장되므로 연계 관점에서 함께 고려)
- Endpoint DLP(다운로드 후 로컬에서 외부 반출까지 통제하려면)
(B) 규칙(룰) 설계: “외부 공유” 조건을 명시
DLP는 민감 정보 유형(SIT), 키워드/정규식, 민감도 라벨, 위치/사용자 그룹 등을 조합합니다. 외부공유 차단을 목표로 할 때는 다음 조합이 효과적입니다.
- 조건 1: 콘텐츠에 특정 민감 정보 유형이 N개 이상 포함
- 조건 2: 또는 민감도 라벨이 Confidential/Highly Confidential
- 조건 3: 그리고 공유 대상이 외부 사용자(게스트) 또는 외부 도메인
- 동작: 차단(Block) 또는 차단+정책 팁(Policy tip) 표시, 필요 시 관리자 오버라이드(정당화 텍스트 필수) 허용
(C) 단계적 롤아웃: Audit → Warn → Block
운영 관점에서 가장 큰 실패 원인은 “바로 차단(Block)부터 시작”하는 것입니다. 초기에는 감사(Audit)로 실제 공유 패턴과 오탐을 수집하고, 경고(Warn)로 사용자 교육을 병행한 뒤, 마지막에 차단(Block)으로 전환하는 방식이 안정적입니다.
(D) 중요한 예외 처리: 협력사 프로젝트의 ‘정상 외부공유’ 보장
완전 차단만 있으면 현업은 우회(개인 메일/메신저)로 돌아섭니다. 따라서 아래 중 최소 하나를 설계해야 합니다.
- 허용 도메인(allowlist) 기반 예외
- 특정 SharePoint 사이트(협업 전용 사이트)만 외부공유 허용
- 승인 기반 예외(정당화/티켓 번호 입력 + 감사)
💡 인공지능 인사이드 팁: DLP 예외를 “사용자 단위”로 주면 시간이 갈수록 누더기가 됩니다. 예외는 가급적 “사이트(프로젝트 공간) 단위” 또는 “도메인 allowlist 단위”로 주고, 예외 승인 시 만료일을 함께 관리하면 지속 운영이 훨씬 수월합니다.
🔗 Microsoft Purview DLP 개요 공식 문서
🔗 Microsoft 365에서 DLP 구성 공식 문서
6) “코파일럿이 있는데도” 꼭 점검해야 할 셰어포인트 권한설정 체크리스트
Copilot을 쓰는 조직에서 외부공유 사고가 늘어나는 이유는 ‘AI가 공유를 해서’가 아니라 ‘콘텐츠 생산량이 늘면서 과공유가 더 빨리 누적’되기 때문인 경우가 많습니다. 아래 항목을 우선순위대로 점검하는 편이 효과적입니다.
- 전사 기본 링크 유형이 내부 전용인가
- Anyone 링크가 비활성화 또는 엄격히 제한(만료/권한/추적)되는가
- 게스트 초대 권한이 무분별하게 열려 있지 않은가(누가 초대 가능한지)
- 외부공유 예외 사이트가 문서화되어 있는가(목록/소유자/만료/목적)
- 민감도 라벨이 실제 문서에 적용되고 있는가(자동 라벨링/권장 라벨링 포함)
- DLP가 “외부 공유 시도”를 이벤트로 남기고, 필요한 경우 차단하는가
- 감사 로그/알림이 SOC 또는 보안 담당자의 운영 흐름에 들어가 있는가
7) 비교 표: “권한만 설정” vs “권한 + DLP 연동”에서 실제로 달라지는 것
| 구분 | 권한/공유 정책만 적용 | 권한/공유 + 민감도 라벨 + DLP 연동 | 실무 영향 |
|---|---|---|---|
| 외부 공유 통제 | 사이트/링크 정책 중심(우회 가능성 존재) | 공유 경계 + 콘텐츠 기반 차단(민감정보 포함 시) 가능 | 실수/우회 모두에 대한 방어력이 상승 |
| 오탐/누락 관리 | 규칙이 단순해도 “민감 문서” 구분이 약함 | 라벨로 기준을 명확히 하고 DLP는 예외/승인으로 조정 | 현업 반발 감소, 정책 정착 속도 증가 |
| 감사/추적 | 감사 로그는 남지만 “민감도 맥락”이 약할 수 있음 | DLP 이벤트로 민감도/규칙/사용자 행위가 함께 기록 | 사고 대응(RCA) 시간 단축 |
| Copilot 도입 적합성 | 과공유 문서가 많을수록 참조 범위 리스크 증가 | 권한·라벨 기반으로 참조 가능한 데이터 경계를 정교화 | “Copilot은 쓰되, 데이터 경계는 더 좁게” 구현 가능 |
8) 실무 시나리오: “협력사와 공유는 해야 하는데, 민감정보는 막아야” 하는 경우
예를 들어 기획자 B씨 팀이 외주 디자인 업체와 협업한다고 가정해 보겠습니다. 협업 자체는 필요하지만, 견적서/정산자료/고객 개인정보가 섞이면 문제가 됩니다.
권장 운영 방식(현실형)
- 협업 전용 SharePoint 사이트를 별도로 만든다(외부공유 예외 공간)
- 그 사이트에만 외부 도메인 allowlist를 적용한다(협력사 도메인만)
- 문서 업로드 시 자동 라벨링으로 “Confidential(외부 공유 불가)”가 붙으면 업로드는 가능하되 외부 사용자 공유/접근은 DLP로 차단
- 업무상 꼭 공유가 필요하면: 관리 승인(또는 정당화+만료) 프로세스를 거쳐 제한적으로 허용
이 구조의 장점은 “외부공유=무조건 악”이 아니라, 외부공유가 필요한 업무 흐름은 살리고 민감정보가 섞일 때만 강하게 막을 수 있다는 점입니다.
9) 운영·감사: 정책을 켠 뒤 반드시 확인해야 할 로그/리포트
DLP 연동의 성패는 “정책을 만들었는가”가 아니라 “현업이 정책을 만났을 때 어떤 행동을 하는지”를 관찰하고 조정하는 데 달려 있습니다. 다음 운영 항목을 권장합니다.
- DLP 알림(Notifications) 수신 채널: 보안 메일함/티켓 시스템 연동
- 주간 리포트: 가장 많이 차단된 민감 정보 유형 Top N, 차단된 사용자/사이트 Top N
- 예외 승인 리포트: 예외가 반복되는 팀은 라벨 기준/업무 프로세스 재설계 필요
- 게스트 액세스 리뷰: 프로젝트 종료 시 게스트 정리(만료/비활성화)
🔗 Microsoft Purview 감사 로그 검색 공식 문서
10) 내부 링크(연관 글)
11) 자주 발생하는 장애 포인트(실무에서 막히는 구간)와 해결 방향
1) “외부공유를 막았는데도 누군가 외부로 보냈다”
대부분 경로가 SharePoint 링크가 아니라 “다운로드 후 개인 메일/메신저 전송”입니다. 이 경우 Endpoint DLP 또는 브라우저/디바이스 제어, 그리고 민감도 라벨 기반 암호화(열람 권한 제어)까지 함께 봐야 합니다.
2) DLP가 너무 많이 걸려 업무가 멈춘다
초기에는 감사(Audit)로 기준선을 만들고, 경고(Warn)와 사용자 정당화(Justification)를 거쳐, 차단(Block)으로 가는 단계적 접근이 필요합니다. 또한 규칙을 “민감도 라벨 기반”으로 단순화하면 운영 난도가 크게 내려갑니다.
3) 협력사 도메인이 여러 개라 allowlist 관리가 어렵다
프로젝트 단위로 협력사 도메인을 묶어 관리하고, 만료일과 소유자를 명확히 둬야 합니다. 도메인 예외가 영구적으로 남으면 정책은 빠르게 무력화됩니다.
12) 결론적으로: “외부공유 차단”은 DLP 하나가 아니라 ‘경계 설정 + 콘텐츠 보호 + 행위 차단’의 결합
인공지능 인사이트 에디토리얼 팀의 결론은 간단합니다. SharePoint 외부공유를 막으려면 먼저 링크/게스트/사이트 예외를 정리해 공유 경계를 닫고, 민감도 라벨로 “막아야 할 것”을 정의한 다음, Purview DLP로 “외부공유 시도”를 차단·감사·예외 승인까지 운영 흐름으로 연결해야 합니다. Copilot 환경에서는 이 결합이 곧 ‘AI 활용 속도는 올리고, 데이터 유출 리스크는 내리는’ 가장 현실적인 해법이 됩니다.
