규모 확장하기: 페이지 매김, 스로틀링 및 대규모 테넌트 M365 감사 관리

By Mirko Peters · 2026-08-11

블로그에 다시 오신 것을 환영합니다! 대규모 Microsoft 365 환경을 관리하고 계신다면, 기본으로 제공되는 보고 도구로는 표면만 겨우 건드릴 수 있을 뿐이라는 점을 이미 잘 알고 계실 것입니다…

Automatically translated with AI from the original post. Read the English original

Titelbild: Scaling Up: Managing Pagination, Throttling, and Large Tenant M365 Audits

블로그에 다시 오신 것을 환영합니다. 대규모 Microsoft 365 환경을 관리하고 계신다면, 기본 제공 보고 도구로는 표면만 겨우 확인할 수 있다는 점을 이미 잘 아실 것입니다. 보안 팀과 규정 준수 담당자가 대규모 테넌트를 살펴볼 때, 기본 스크립트와 기본 제공 관리 센터 보기는 수천 명의 사용자, 그룹, 파일의 무게를 감당하지 못하고 맙니다. 대규모 M365 테넌트 감사에는 기본 스크립트 이상이 필요하며, Microsoft Graph API를 활용한 전술적이고 프로그래밍 방식의 접근이 요구됩니다. 이번 종합 가이드에서는 최근 팟캐스트 에피소드 Map Microsoft 365 Users, Groups, Files, and Shares with Graph에서 나눈 대화를 바탕으로 더 깊이 들어가 보겠습니다. @odata.nextLink 페이지 매김을 처리하는 방법, 지수 백오프로 429 속도 제한을 준수하는 방법, 그리고 1페이지 편향과 같은 흔한 함정을 피해 테넌트 전체를 가시화하는 방법을 자세히 살펴보겠습니다.

M365 감사의 과제 소개

엔터프라이즈 환경은 자연스럽게 성장합니다. 사용자는 들어오고 나가며, 프로젝트는 하룻밤 사이에 부서를 만들어 내고, 외부 공급업체는 협업 공간에 초대됩니다. 시간이 지나면서 관리자의 가시성은 떨어집니다. 기본 관리 센터는 인프라의 일부만 따로 보여 주므로, 악의적인 공격자나 실수를 저지르는 내부자가 악용할 수 있는 사각지대가 생깁니다. 테넌트 보안 상태를 정확히 파악하려면 수동 클릭 방식의 감사에서 벗어나 API 기반의 자동화된 그래프 순회로 전환해야 합니다. 다만 이런 쿼리를 엔터프라이즈 규모로 확장하면 대용량 데이터 페이로드, 공격적인 스로틀링, 깊게 중첩된 관계 구조와 같은 복잡한 장애물이 생깁니다.

M365가 격리되어 있지 않은 이유: 관계형 액세스 이해하기

Microsoft 365의 근본적인 특성 중 하나는 SharePoint, Teams, OneDrive 같은 서비스가 서로 분리된 사일로가 아니라는 점입니다. 이들은 그룹 멤버십과 기본 액세스 제어 목록을 통해 지속적으로 상호 연결됩니다. 보안 그룹에 사용자를 추가하는 것과 같은 단일 관리 작업이 표준 보기에서는 명확한 감사 추적을 남기지 않은 채 수십 개의 팀 사이트, 문서 라이브러리, 비공개 채널에 파급될 수 있습니다.

이는 숨겨진 규정 준수 위험을 만듭니다. 격리된 채팅에서 공유된 게스트 링크, 여러 팀 라이브러리에 복제된 파일, 오래전에 끝난 프로젝트에서 남은 고아 공유는 기업 데이터로 들어가는 보이지 않는 경로가 됩니다. M365의 액세스는 위치가 아니라 근본적으로 관계에 기반합니다. 효과적으로 감사하려면 각 서비스를 독립된 섬으로 다루지 말고, 이러한 연쇄적 관계를 매핑해야 합니다.

Graph Explorer로 사용자 발자취 매핑하기

대규모 자동화를 작성하기 전에, Graph Explorer를 사용해 사용자의 발자취를 수동으로 추적하는 방법을 이해해야 합니다. 쿼리를 단계별로 구성하면 코드를 작성하기 전에 논리가 올바른지 확인할 수 있습니다. 사용자 접점을 매핑하는 청사진은 다음과 같습니다.

사용자에서 시작하기: GET /v1.0/users/{userPrincipalName}?$select=id,displayName,userPrincipalName을 사용해 핵심 사용자 개체를 가져오는 것부터 시작합니다.
멤버십 나열하기: GET /v1.0/users/{id}/memberOf?$select=id,displayName을 사용해 해당 ID에 연결된 그룹과 역할을 가져옵니다.
그룹에서 리소스로 피벗하기: M365 그룹 및 Teams의 경우 GET /v1.0/groups/{groupId}/drive/root/children?$select=id,name,lastModifiedDateTime,webUrl을 사용해 기본 SharePoint 사이트를 대상으로 하거나, GET /v1.0/sites/{siteId}/drives를 사용해 사이트 드라이브를 직접 나열합니다.
항목 권한 및 링크 확인하기: GET /v1.0/drives/{driveId}/items/{itemId}/permissions?$select=id,grantedToV2,link,roles,shareId를 사용해 개별 파일의 액세스를 검사합니다.
누가 무엇에 접근했는지 추적하기: 파일 및 사이트 컨텍스트와 함께 로그인 로그 또는 보안 경고를 사용해 사용자 작업을 연관 지어 확인합니다.
Teams 게시물까지 추적 마무리하기: GET /v1.0/teams/{teamId}/channels/{channelId}/messages?$search="filename"을 사용해 특정 파일 참조가 있는 채널 메시지를 검색합니다(베타 권한 및 요구 사항을 염두에 둘 것).

실제로 쓰게 될 노이즈 제거 필터

필터 없이 Microsoft Graph를 쿼리하면 데이터 폭주로 시스템이 압도될 수 있습니다. 실제 위험을 드러내려면 정밀한 필터링 전략이 필요합니다. 다음은 배포해야 할 쿼리 패턴입니다.

최근 7일 내 외부 공유: 익명 또는 조직 전체 링크를 대상으로 GET /v1.0/drives/{driveId}/items/{itemId}/permissions?$filter=link/scope eq 'anonymous' 또는 link/scope eq 'organization' 조건을 사용합니다.
위험 파일 형식만 조회: 매크로와 아카이브를 찾으려면 endsWith(resourceReference/name,'.xlsm') 또는 endsWith(resourceReference/name,'.pst') 같은 필터를 추가합니다.
업무 시간 외 Teams에서 민감한 용어 언급: confidential 같은 용어로 채널 메시지를 검색한 뒤, 결과를 업무 시간 외의 생성 타임스탬프 기준으로 다시 필터링합니다.
페이로드는 가볍게 유지: 필요한 식별자, 이름, URL, 타임스탬프만 반환하도록 항상 $select 매개 변수를 포함합니다.
신속 점검의 상한 설정: 빠른 샘플 확인에는 $top=50을 사용하되, 데이터 저장소로 전체 내보내기를 실행할 때는 이 매개 변수를 제거합니다.

엔터프라이즈 규모에서 반드시 지켜야 할 사항: 페이지 매김과 제한

수십만 개의 개체가 있는 테넌트에서 감사를 실행할 때는 API 제한과 페이지 매김을 고려하지 않으면 스크립트가 반드시 벽에 부딪힙니다. API가 반환하는 모든 페이지에 대해 @odata.nextLink 속성을 따라가기 전까지는 데이터 수집이 끝난 것이 아닙니다. 이를 무시하면 스크립트는 첫 번째 결과만 수집하고 나머지 테넌트 데이터는 완전히 놓치게 됩니다.

또한 HTTP 429 속도 제한 응답을 반드시 존중해야 합니다. 견고한 지수 백오프 로직을 구현하여 스크립트가 일시 중지되고, 냉각 기간이 지나기를 기다렸다가, 중단된 지점부터 끊김 없이 다시 시작하도록 해야 합니다. 요청은 신중하게 묶어서 작은 요청을 여러 번 보내기보다 적지만 규모가 큰 논리적 요청을 선호하고, 그룹과 사이트 매핑은 캐싱합니다. 대규모 테넌트의 경우 사이트나 날짜 범위별로 크롤링을 나누고, 운영 성능에 영향을 주지 않도록 업무 외 시간에 예약하여 실행합니다.

흔한 함정과 빠른 해결책

감사 규모를 키울 때는 숙련된 관리자도 장애물에 부딪힙니다. 가장 흔한 함정과 해결 방법은 다음과 같습니다:

함정: 스키마가 시간이 지나면서 바뀌면 CSV 내보내기 결과가 어긋납니다. 해결: Graph API를 직접 사용하고, 버전별 변환을 적용하며, 알 수 없는 필드는 오류 없이 처리합니다.
함정: GUID와 UPN(사용자 계정 이름) 같은 식별자가 섞이면 데이터베이스 조인이 깨집니다. 해결: 모든 데이터를 사용자, 그룹, 사이트, 드라이브, 항목, 권한을 포함하는 깔끔한 의미 모델로 정규화합니다.
함정: 첫 페이지에 치우친 조회 때문에 결과 집합 깊숙이 숨어 있는 보안 사고 대부분을 놓치게 됩니다. 해결: 처리한 총 페이지 수를 항상 기록하고, 예상 데이터 양이 갑자기 줄면 알림을 설정합니다.
함정: 관련 없는 파일이 쏟아지면 처리 엔진이 느려집니다. 해결: 공유 범위, 시간 창, 민감한 용어 목록에 엄격한 필터를 적용합니다.
함정: Teams 공유 항목이 기본 파일과 연결되지 않습니다. 해결: 채널 메시지의 웹 URL을 드라이브 항목에 직접 연결하고, 두 식별자를 함께 저장합니다.

이를 통해 확보할 수 있는 경영진 수준 KPI

기술 데이터는 경영진이 실행 가능한 비즈니스 인텔리전스로 바꿀 수 있을 때만 가치가 있습니다. 자동화된 Graph 감사 파이프라인을 구축하면 다음과 같은 강력한 경영진 KPI를 확보할 수 있습니다:

외부 노출 속도: 사이트와 팀별로 나누어 주당 새로 생성된 게스트 링크 수를 측정합니다.
민감 파일 조회율: 레이블이 지정된 콘텐츠의 고유 조회자를 추적하고, 내부 사용자와 외부 게스트를 구분합니다.
그룹 파급 위험: 주요 그룹 멤버십이 변경된 후 24시간 이내에 새로 접근 가능해진 파일을 측정합니다.
섀도 유통: 한 스프린트 동안 여러 팀이나 사이트에 걸쳐 나타나는 민감 파일을 모니터링합니다.
정리 효과: 취소된 링크 수와 해결까지 걸린 시간 지표를 시간 경과에 따라 추적합니다.

빠른 시작 쿼리 레시피

자체 데이터 수집 파이프라인 구축을 시작할 준비가 되었다면, 아래 흐름을 복사해 붙여 넣어 바로 시작할 수 있습니다:

사용자 기본 정보와 멤버십 가져오기: /users/{upn}?$select=id,displayName 및 /users/{id}/memberOf?$select=id,displayName
각 Microsoft 365 그룹의 드라이브 항목 나열: /groups/{groupId}/drive/root/children?$select=id,name,webUrl,lastModifiedDateTime&$top=200을 사용하며, @odata.nextLink를 반드시 따라갑니다.
각 항목의 권한 가져오기: /drives/{driveId}/items/{itemId}/permissions?$select=id,roles,grantedToV2,link를 사용하고, 익명 또는 조직 범위로 필터링합니다.
지정한 데이터 저장소로 행을 내보내며, 테넌트 시간, 사이트 ID, 드라이브 ID, 항목 ID, 웹 URL, 소유자, 범위, 만료 정보를 함께 저장합니다.
경영진 및 운영 대시보드를 위해 정규화된 데이터를 Power BI에서 시각화합니다.

지속적으로 업데이트되는 대시보드 만들기

감사를 한 번만 실행하면 스냅숏에 그치지만, 지속적으로 실행하면 보안 프로그램이 됩니다. 원시 Graph 호출 결과를 살아 있는 대시보드로 바꾸려면 Power Dataflows에 데이터를 넣어 Users, Groups, Sites, Drives, Items, Permissions, Messages를 정규화된 테이블로 만드십시오. 데이터 모델은 Items를 중심에 둔 스타 스키마로 구성하고, Users 및 Groups와 명확한 관계를 설정합니다.

lastModifiedDateTime 필드를 기준으로 증분 새로 고침을 구성하고, 위험도가 높은 사이트는 하루 중에도 업데이트되도록 실행합니다. 마지막으로 레이블이 지정된 콘텐츠에 새로운 외부 링크가 나타나거나 그룹 확산 급증이 무단 액세스 확대를 나타낼 때 자동으로 알림이 발생하도록 설정합니다.

30일 배포 계획

로마는 하루아침에 세워지지 않았습니다. 엔터프라이즈 감사 프레임워크도 신중한 단계별 진행이 필요합니다. 원활한 배포를 위해 다음 30일 배포 계획을 따르십시오.

1주차: Azure 앱 등록을 설정하고, 최소 권한 원칙에 따라 Graph API 권한을 할당한 뒤, $select 및 $filter 매개변수를 사용해 첫 번째 쿼리의 기준선을 설정합니다.

2주차: 페이지 매김 스크립트를 개발하고, 식별자를 일관된 UPN 및 디바이스 이름으로 정규화한 뒤, 첫 번째 엔드 투 엔드 데이터 내보내기를 성공적으로 실행합니다.

3주차: Power BI 데이터 모델을 구축하고, 외부 노출, 확산 위험, 체류 시간에서 권한 취소까지의 기간 같은 핵심 성과 지표(KPI)를 구성합니다.

4주차: 데이터 새로 고침을 자동화하고, 이상 징후 알림을 구현하며, 보안 조사팀을 위한 표준 운영 절차(SOP)를 문서화합니다.

이런 분들께 권합니다

이 프레임워크는 녹색 대시보드 뒤에 가려진 회색 영역이 있을지 의심하는 M365 관리자 및 SecOps 리더, 타사 도구를 늘리지 않고 엔드 투 엔드 공유 가시성을 확보해야 하는 규정 준수 팀, 안전한 외부 공유 관행을 유지할 책임이 있는 협업 담당자를 위해 특별히 설계되었습니다.

현장 팁

이 스크립트를 실제 환경에 배포할 때 다음 빠른 팁을 기억하십시오. 사각지대를 없애려면 조사는 항상 사용자 또는 파일에서 시작한 뒤 양방향으로 피벗하십시오. 그룹 추가 이벤트는 위험도가 높은 변경으로 간주하고, 하위 액세스를 24시간 이내에 검토하십시오. 파일 이름과 Teams 메시지에서 검색할 민감한 용어 목록을 지속적으로 관리하십시오. 마지막으로 페이지 수와 결과량을 신중하게 기록하십시오. 스크립트가 아무 결과도 내지 않는 것은 깨끗한 테넌트가 아니라 작업이 고장 났다는 신호인 경우가 많습니다.

결론

페이지 매김을 익히고, 속도 제한을 준수하며, 1페이지 편향을 피하는 것은 대규모 Microsoft 365 테넌트를 보호하는 모든 담당자에게 필수적인 기술입니다. 기본 관리 콘솔을 넘어 Microsoft Graph API의 프로그래밍 기능을 활용하면, 눈에 보이지 않던 공유 위험을 명확하고 측정 가능한 보안 인사이트로 바꿀 수 있습니다.

더 깊이 있는 내용, 코드 샘플, 실제 Graph 활용 사례는 팟캐스트의 전체 논의를 들어 보십시오. 관련 에피소드와 자세한 내용은 Map Microsoft 365 Users, Groups, Files, and Shares with Graph에서 확인하실 수 있습니다. 안전하게 보호하고, 계속 자동화하시며, 다음 에피소드에서 뵙겠습니다!