Microsoft Graph 권한 완벽 이해하기: 최소 권한 함정 피하기

By Mirko Peters · 2026-08-28

Microsoft 365 환경에서 애플리케이션을 개발하거나, 자동화 스크립트를 작성하거나, 타사 도구를 통합하기 시작하면 Microsoft Graph가 빠르게 중추 신경계 역할을 하게 됩니다. Teams, SharePoint, Exchange, Azure Active Directory를 하나로 연결해 조직 데이터를 통합된 화면에서 볼 수 있게 해 줍니다. 하지만 큰 힘에는 그만큼 큰 아키텍처상의 책임이 따릅니다. 많은 팀이 앱을 빨리 동작시키려고 넓고 광범위한 권한을 부여하는 편의의 함정에 빠지곤 합니다. 이런 지름길은 테넌트 전체를 치명적인 보안 위험에 노출시킬 수 있습니다. 이 글에서는 앱 기능과 엄격한 최소 권한 원칙 사이의 균형을 맞추면서 Microsoft Graph 권한을 안전하게 다루는 방법을 살

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

Cover: How Microsoft Graph Connects Microsoft 365 Data and Context

Microsoft Graph 권한의 숨은 힘과 위험

Microsoft Graph는 클라우드 환경을 위한 통합 운영 플레인 역할을 하며, 흩어져 있던 레거시 API의 복잡한 미로를 단일하고 간결한 REST 엔드포인트로 대체합니다. 개발이 훨씬 쉬워지는 것은 분명하지만, 그만큼 위험도 한곳에 집중됩니다. 생성하는 모든 애플리케이션 ID나 서비스 주체에는 상호작용하는 데이터에 접근하기 위한 특정 키가 필요합니다. 이 키가 잘못 관리되면 전체 보안 경계가 무너질 수 있습니다.

핵심 위험은 관리상의 편의가 보안 모범 사례를 종종 밀어낸다는 데 있습니다. 개발자는 스프린트 도중 권한 오류에 막히는 것을 피하고 싶어 Sites.ReadWrite.All이나 Directory.ReadWrite.All과 같은 상위 수준의 권한 범위를 요청합니다. 이렇게 하면 당장의 권한 장애물은 사라지지만, 앱에 모든 것을 열 수 있는 열쇠를 쥐여 주는 셈이 됩니다. 이 앱 하나가 침해되면 공격자는 방대한 양의 기업 데이터를 읽거나 수정할 수 있게 됩니다. 혁신을 가능하게 하는 것과 엄격한 보안 경계를 유지하는 것 사이의 미묘한 균형을 이해하는 것이 진정한 클라우드 성숙도로 가는 첫걸음입니다.

위임된 액세스와 앱 전용 액세스의 차이 이해하기

Microsoft 365 테넌트를 안전하게 보호하려면 먼저 Microsoft Graph가 사용하는 두 가지 주요 권한 부여 모델, 즉 위임된 액세스와 앱 전용(애플리케이션) 액세스를 확실히 이해해야 합니다.

위임된 액세스는 로그인한 사용자를 대신해 실행되는 앱을 위해 설계되었습니다. 이 모델에서 앱은 인증된 사용자가 접근할 수 있는 항목에만 접근할 수 있습니다. 사용자가 특정 SharePoint 사이트를 볼 수 없다면, 위임된 권한을 사용하는 앱도 그 사용자를 대신해 해당 사이트를 볼 수 없습니다. 이 모델은 권한 범위에 의존하며, 사용자와 앱 모두에 권한이 부여되어야 합니다.

반면 앱 전용 액세스는 어떤 사용자와도 무관하게 작동합니다. 애플리케이션은 백그라운드 데몬, 예약된 스크립트 또는 자동화된 서비스로 실행됩니다. 데이터를 제한할 로그인 사용자 컨텍스트가 없으므로, 앱 전용 액세스는 애플리케이션 권한(앱 역할)에 의존합니다. 이러한 역할은 종종 테넌트 전체에 걸친 막대한 권한을 가집니다. 따라서 앱 전용 시나리오를 보호하려면 엄격한 거버넌스, 서비스 주체 사용 현황에 대한 정기적인 검토, 그리고 최소 권한 원칙을 철저히 준수해야 합니다.

최소 권한 함정: 흔한 권한 실수

최소 권한 원칙은 애플리케이션이 특정 작업을 완료하는 데 필요한 최소한의 권한만 가져야 한다는 것을 뜻합니다. 안타깝게도 많은 조직이 흔한 아키텍처상의 함정 때문에 매일 이 원칙을 어기고 있습니다.

가장 위험한 함정 중 하나는 편의를 위해 와일드카드나 테넌트 전체에 적용되는 넓은 권한을 사용하는 것입니다. 예를 들어 애플리케이션이 현재 사용자의 프로필만 읽으면 되는데 User.Read.All을 할당하면 불필요한 노출이 발생합니다. 또 다른 흔한 실수는 서버 쪽 OData 쿼리 필터를 사용하지 않고, 전체 데이터 집합을 가져온 뒤 애플리케이션 계층에서 결과를 걸러내는 것입니다. 앱이 로컬에서 필터링하려고 모든 사이트 컬렉션을 요청하면, 앱이 보아서는 안 되는 데이터가 이미 네트워크 경계를 넘어 애플리케이션 계층까지 유출된 것입니다.

또한 표시 이름이나 이메일 주소처럼 변경될 수 있는 식별자를 불변 GUID 대신 사용하면 시간이 지나면서 권한 부여 공백이 생길 수 있습니다. 그룹 확장을 고려하지 않거나 테넌트 전체에 권한이 즉시 동기화된다고 가정하면 눈에 띄지 않는 과다 노출로 이어질 수도 있습니다. 구체화된 권한은 오래되어 계정이나 애플리케이션이 업무상 정당성이 사라진 뒤에도 액세스를 계속 유지할 수 있습니다.

애플리케이션 기능을 해치지 않으면서 테넌트 보호하기

애플리케이션 기능을 완전히 막는 보안 조치는 불만을 느낀 개발자들이 우회하기 마련입니다. 따라서 Microsoft Graph 권한을 강화하려면 정상적인 업무 흐름을 늦추지 않으면서 데이터를 보호하는 전략적 접근이 필요합니다.

먼저 기존 Azure AD 앱 등록과 서비스 주체를 점검하는 것부터 시작하십시오. 사용자 지정 애플리케이션에 할당된 모든 권한을 확인하고, 실제 사용 로그와 비교하십시오. 몇 달 동안 사용하지 않은 애플리케이션 권한이 부여되어 있다면 즉시 취소하십시오. Microsoft Entra 감사 로그와 ID 보호 기능을 활용하여 로그인 동작을 모니터링하고 비정상적인 API 사용을 식별하십시오.

또 다른 중요한 방법은 세분화된 범위를 구현하는 것입니다. 모든 사서함이나 모든 사이트에 대한 광범위한 액세스를 요청하는 대신, 가능한 경우 리소스별 동의 옵션을 찾아보십시오. 예를 들어 최신 Microsoft Teams 및 SharePoint 통합에서는 테넌트 전체가 아닌 특정 팀이나 사이트에만 권한을 부여할 수 있습니다. 이렇게 하면 위험 프로필이 분리됩니다. 앱 하나가 침해되더라도 영향 범위가 전사가 아니라 하나의 협업 작업 공간으로 제한됩니다.

Microsoft 365 보안 관리를 위한 실행 전략

사후 대응형 태세에서 사전 예방형 보안 체계로 전환하려면 반복 가능한 프로세스와 자동화된 거버넌스가 필요합니다. Microsoft Graph 권한을 제대로 관리하기 위해 오늘 바로 적용할 수 있는 실행 전략은 다음과 같습니다.

프로덕션 환경에 배포되기 전에 모든 새로운 Azure AD 앱 등록에 대해 엄격한 검토 절차를 적용하십시오.
프로젝트가 종료되거나 소유자가 조직을 떠나면 앱 액세스와 서비스 주체를 자동으로 취소하도록 자동화된 ID 수명 주기 관리를 구현하십시오.
Microsoft Graph API 쿼리를 활용하여 정기적인 일정에 따라 테넌트 전체의 권한을 프로그래밍 방식으로 모니터링하십시오.
과도한 권한 범위의 보안 영향과 리소스별 동의와 같은 대안 방식에 대해 개발팀을 교육하십시오.
배포 전에 지나치게 허용적인 앱 역할을 찾아낼 수 있도록 CI/CD 파이프라인에 보안 검사와 권한 검증을 포함하십시오.

권한을 코드처럼 관리하고 엄격한 검증 기준을 적용하면 클라우드 애플리케이션을 안전하고 규정을 준수하며 성능이 뛰어난 상태로 유지할 수 있습니다.

Microsoft Graph 권한을 숙달하는 것은 안전하고 확장 가능한 Microsoft 365 아키텍처의 필수 기반입니다. 위임된 액세스와 앱 전용 액세스의 핵심 논리를 이해하고, 흔히 빠지는 최소 권한 함정을 피하며, 사전 예방형 거버넌스 전략을 구현하면 조직의 민감한 데이터를 보호하는 동시에 클라우드 자동화의 모든 기능을 활용할 수 있습니다. 이러한 개념이 실제 환경에서 어떻게 연결되는지 더 깊이 알고 싶다면 관련 에피소드도 꼭 들어보십시오: How Microsoft Graph Connects Microsoft 365 Data and Context.