외부 공유는 기능이 아니다 | 이는 위험 결정™ | RAHSI™ Collaboration Risk Posture (RCRP™)
Source: Dev.to
개요
Microsoft 365에는 우리가 자주 입 밖에 내지 않는 현실이 있습니다:
외부 공유는 단순한 기능이 아니라 실시간 위험 표면입니다.
누군가가 다음을 클릭할 때마다:
- “링크가 있는 사람은 모두 볼 수 있음”
- “프로젝트에 이 게스트만 추가해 주세요”
- “나중에 파트너 익스트라넷을 종료하겠습니다”
…우리는 단순히 “협업”하고 있는 것이 아닙니다. 우리는 SharePoint Online, OneDrive, 그리고 Teams 위에 새로운 보안 경계를 조용히 만들고 있는 것입니다.
개별적으로는 이러한 결정이 무해해 보일 수 있습니다. 하지만 규모가 커지고 실제 Azure + Microsoft 365 환경에서 적용될 때, 이는 Entra ID, Purview, 그리고 Defender 팀이 더 이상 배경 소음으로 무시할 수 없는 문제가 됩니다.
제가 이름을 붙이고 구조화하려고 시도한 것이 바로:
External Sharing Is Not a Feature | It’s a Risk Decision™ | RAHSI™ Collaboration Risk Posture (RCRP™)
이는 Microsoft에 대한 비판이 아닙니다. 이 플랫폼은 놀라운 툴킷을 제공합니다: SharePoint, OneDrive, Teams, Entra ID, Microsoft Purview, Microsoft Defender, Graph, Power Automate, 그리고 이제 Copilot.
RCRP™는 그 스택 위에 의견이 반영된 엔지니어링‑급 위험 자세를 추가하려는 시도입니다 – Azure/M365 관리자, 아키텍트, 그리고 CISO가 실제 테넌트에서 실제로 실행할 수 있는 것입니다.
RCRP™가 시도하고 있는 일
외부 공유를 단일 테넌트 토글로 다루는 대신, RCRP™는 협업 영역을 설계하고 각 영역마다 위험 결정을 명시하도록 요구합니다.
예시: 임상 vs 연구 vs 공급업체 vs JV vs NOC vs KYC vs FOI vs 이사회 자료 — 각각 고유한 보안 자세를 갖고, 단순히 “외부 공유: 켜짐”이 아닙니다.
1. 영역별 위험 결정으로서의 외부 공유
협업 영역을 다음과 같이 정의합니다:
CLINICAL-EXT-ZONEKYC-ZONEVENDOR-ZONEJV-DATAROOM-ZONENOC-EXT-ZONE
그 후 영역별로 다음을 묻습니다:
- 누가 초대될 수 있는가 (어떤 도메인, 어떤 아이덴티티)?
- 허용되는 데이터 분류 수준은?
- 어떤 링크 유형이 절대 유효하지 않은가?
- 외부 접근 권한이 검토 또는 제거되기까지 허용되는 기간은?
2. 목적·민감도·시간에 묶인 게스트 접근
“게스트 계정 + 하나의 큰 그룹 = 테넌트 절반에 영구 접근”이 아니라, RCRP™ 패턴은 게스트를 다음에 묶습니다:
- 비즈니스 목적 (사건, 프로젝트, 계약, 캠페인, 보조금)
- 데이터 민감도 프로파일
- 시간 창 (위임 기간, 계약 기간, 감사 주기, 학기)
목적이 종료되면 접근도 자동으로 종료됩니다.
3. Zero Trust + CVE 현실에 맞춘 링크 유형
UI에서 “공유” 버튼을 클릭하는 사이트 소유자가 위험을 최종 판단해서는 안 됩니다. RCRP™는 링크 유형을 Zero Trust 아키텍처의 일부로 다룹니다:
- “Anyone” 링크는 영역에 따라 차단되거나 엄격히 제한됩니다
- “Specific people” 링크는 고위험 영역의 표준이 됩니다
- 공유 기준은 CVE 권고 및 보안 가이드에 따라 이동하며, 편의에 따라 바뀌지 않습니다
4. 파트너 엑스트라넷 및 데이터룸을 수명 주기‑연계 표면으로
“파트너 사이트는 나중에 삭제하겠다”는 식이 아니라, RCRP™는 파트너 및 B2B 협업 사이트를 일급 수명 주기 객체로 모델링합니다:
- 생성 → 활성 → 읽기 전용 → 보관 → 폐기
다음에 대한 명확한 패턴을 제공합니다:
- 접근 잠금
- 콘텐츠 보관
- 게스트 및 링크 제거
- 규제기관이 요구할 경우 모든 과정 증명
5. 보안·위험·컴플라이언스에 자세, 영향 범위, 정리 제공
대부분의 보안 팀은 아이덴티티가 어디에 있는지는 알 수 있습니다. 하지만 협업 표면이 어디에 있는지는 더 어려워합니다.
RCRP™는 이들에게 다음을 제공하려 합니다:
- 영역과 그 위험 자세에 대한 지도
- 각 영역의 영향 범위 (누구, 어디서, 어떤 데이터)
- 무언가를 신속히 강화해야 할 때 사용할 자동화 가능한 정리 패턴
왜 이것은 반‑Microsoft가 아니라 친‑Microsoft인가
저는 Microsoft 365 + Azure 생태계에 진심으로 감사하고 있습니다:
- Entra ID – 아이덴티티 및 B2B
- Purview – 분류 및 거버넌스
- Defender – 위협 탐지
- SharePoint, OneDrive, Teams – 협업
- Graph, Power Automate, Azure Functions 등 – 자동화
RAHSI™ Collaboration Risk Posture (RCRP™) 은 그 스택을 더 큰 규율과 의도를 가지고 활용하는 저만의 방식입니다:
- “공유하고 기대한다”는 클릭을 줄이고
- “우리가 이해하고, 모니터링하며, 규제기관이나 이사회에 설명할 수 있는 통제된 위험 영역”을 늘립니다.
이 내용이 귀하의 테넌트와 맞다면…
다음과 같은 상황을 보고 있다면:
- 이제는 아무도 소유하지 않는 오래된 파트너 사이트
- 프로젝트가 종료된 후에도 수년간 로그인하는 게스트
- “임시”라고 했던 링크가 어느새 영구화된 경우
- 데이터가 실제로 흐르는 위치에 대해 보안 팀의 불안감이 커지고 있는 경우
…라면 이 작업이 당신을 위한 것입니다.
모델, 패턴 및 구체적인 예시를 여기에 정리했습니다. 실제 테넌트에서 이 문제를 겪고 있는 Microsoft 365 관리자, 아키텍트, 보안 엔지니어분들의 의견을 듣고 싶습니다—특히 이미 Entra, Purview, Defender를 깊이 활용하고 있음에도 외부 협업이 현재 제어보다 한 발 앞서 있다고 느끼는 경우에요.