위임된 권한과 애플리케이션 권한 비교

By Mirko Peters · 2026-04-26 · Updated 2026-07-18

Microsoft Entra ID의 위임된 권한과 애플리케이션 권한을 비교하고, 보안 API, 자동화, 앱 개발에 맞는 액세스 모델을 선택하는 방법을 알아봅니다.

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

Microsoft Entra ID를 다룰 때 누가 어떤 작업을 어떤 조건에서 할 수 있는지 정하는 일은 단순한 기술 세부 사항이 아닙니다. Microsoft 클라우드에서 안전한 앱 개발, 자동화, 전반적인 ID 관리의 기반이 되는 요소입니다. 앱이 사용자를 대신해 동작할 수 있도록 필요한 만큼만 권한을 부여하는 것(위임된 권한)과, 앱이 독립적으로 작업할 수 있는 열쇠를 주는 것(애플리케이션 권한)은 큰 차이가 있습니다.

잘못 선택하면 원하지 않는 데이터 노출, 규정 준수 문제, 심지어 보안 사고로 이어질 수 있습니다. 올바르게 선택하면 자동화가 더 매끄러워지고, 거버넌스가 더 명확해지며, 감사 담당자도 만족합니다. 이 가이드에서는 두 권한 유형의 기본 원리, 실제 활용 사례, 그리고 환경에 맞는 최선의 선택을 하는 데 필요한 보안, 거버넌스, 운영 관점을 전체적으로 설명합니다. 권한을 제자리에 놓고 생각해 봅시다. 큰 액세스 권한에는 그만큼 무거운 책임이 따르니까요.

Microsoft ID의 권한 모델 개요와 소개

Microsoft Entra ID의 권한은 단순히 체크 표시를 하는 옵션이 아닙니다. Microsoft 365, Azure 등에서 앱과 사용자가 상호작용하는 방식에 내재된 기본 체계입니다. Microsoft가 ID를 클라우드로 옮기면서, 서비스와 서드파티 도구가 모든 것에 무조건 전체 액세스를 주지 않고도 안전하게 상호작용할 방법이 필요했습니다. 그렇게 등장한 것이 위임된 권한과 애플리케이션 권한입니다.

이 모델을 사용하면 누가 무엇에 접근할 수 있는지 정밀하게 관리할 수 있고, 개별 사용자가 승인할 수 있는 범위와 관리자만 허용해야 하는 범위 사이에 명확한 경계를 세울 수 있습니다. 기존 AD 서비스 계정과 번거롭고 모 아니면 도인 액세스 방식에서 얻은 교훈(때로는 힘들게 얻은 교훈)이 쌓여 만들어진 결과이기도 합니다. 이러한 모델을 이해하는 것은 좋은 운영 습관일 뿐 아니라, 규정 준수를 충족하고 제로 트러스트를 적용하며, 잘못된 보안 구성 때문에 일상 운영이 멈추지 않도록 하는 데도 매우 중요합니다.

애플리케이션 권한과 위임된 권한: 핵심 개념과 실제 시나리오

위임된 권한과 애플리케이션 권한의 차이를 쉽게 정리해 보겠습니다. 위임된 권한은 앱이 도우미 역할을 하는 것으로 생각하면 됩니다. 특정 사용자가 로그인해 있는 동안에만 액세스할 수 있고, 그 권한도 해당 사용자가 할 수 있는 범위로 제한됩니다. 반면 애플리케이션 권한은 앱이 독립적으로 움직이는 것과 같습니다. 감독 없이 자체 열쇠를 가진 관리자처럼 사용자가 자리에 없어도 작업할 수 있습니다.

위임된 권한에서는 인증에 항상 사용자가 관여합니다. 예를 들어 자신의 메일이나 일정에 접근해야 하는 앱에 누군가 로그인하면, 그 사용자의 권한으로 앱이 작동할 수 있도록 임시로 허용하는 셈입니다. 사용자가 로그오프하면 그 허용 기간도 끝납니다. 이 방식은 웹 프런트엔드, Teams 봇, 모바일 생산성 앱처럼 사용자의 요청에 따라 작업하는 앱에 적합합니다.

애플리케이션 권한에서는 앱 자체가 자신의 ID(서비스 주체)로 인증하고 고유한 토큰을 받습니다. 밤새 SharePoint와 CRM 사이의 데이터를 동기화하는 시스템 통합 같은 자동화와 백그라운드 작업이 바로 이 방식으로 동작합니다. 사용자의 개입은 필요 없으며, 앱은 자체 일정에 따라 작업하고 관리자가 승인한 범위 안에서 액세스 수준을 가집니다.

사용자 프로비저닝을 자동화해야 한다고 가정해 보겠습니다. 매일 밤 사용자 계정을 조용히 업데이트하는 백그라운드 서비스가 필요한 상황입니다. 이때 액세스를 승인해 줄 사람이 없으니 위임된 권한은 쓸모가 없습니다. 반면 사용자가 활동 중일 때 맞춤형 기능을 제공해야 하는 경우, 예를 들어 OneDrive와 연결된 문서 서명 앱이라면 위임된 권한이 빛을 발합니다.

실제 환경에서는 두 방식을 함께 사용하는 경우가 많으므로, 사용 사례에 맞는 모델을 아는 것이 사용자 경험, 거버넌스, 보안 측면에서 매우 중요합니다. 필요 이상으로 열쇠를 나눠 주고 싶지는 않지만, 새벽 3시에 로그인해 줄 사람이 없어서 서비스가 멈춰 버리는 상황도 피하고 싶을 것입니다.

Microsoft Entra 위임된 권한의 내부 구조: 인증 흐름과 제한 사항

Microsoft Entra ID의 위임된 권한(Delegated permissions)은 사용자가 직접 참여하는 전형적인 인증 흐름을 따릅니다. 사용자가 Microsoft 자격 증명으로 애플리케이션에 로그인하면서 시작됩니다. 이 시점에 앱은 특정 권한(또는 범위)을 요청하며, 사용자(경우에 따라서는 관리자)에게 앱이 어떤 종류의 데이터나 작업에 접근하려는지 명확하게 보여 줍니다.

요청된 권한이 사용자 동의만 필요한 경우, 사용자는 동의 화면을 통해 즉시 이를 승인할 수 있습니다. 조직 내 모든 사용자의 사서함을 읽는 것처럼 보다 민감한 권한에는 관리자 동의가 필요합니다. 동의가 완료되면 앱은 사용자의 ID와 할당된 역할에 직접 연결된 액세스 토큰을 받습니다.

이 액세스 토큰을 통해 앱은 Microsoft Graph나 M365 API를 호출할 수 있지만, 항상 사용자의 권한으로 동작합니다. 따라서 사용자가 일반 직원이라면 앱이 갑자기 관리자 기능으로 올라설 수는 없습니다. 사용자가 로그아웃하는 순간 앱의 접근 권한도 사라지므로 영향 범위를 작게 유지할 수 있습니다.

다만 한계도 있습니다. 위임된 권한은 무인 시나리오에서는 제대로 작동하지 않습니다. 사용자가 적극적으로 로그인하는 것에 의존하지 않아야 하는 백그라운드 프로세스, cron 작업 또는 서비스 통합을 운영한다면 위임된 권한으로는 충분하지 않습니다. 모든 것이 사용자의 존재 여부에 묶이기 때문에 지원 업무, 자동화, 야간 작업 모두 벽에 부딪히게 됩니다.

보안 측면도 고려해야 합니다. 광범위한 접근 권한을 가진 사용자가 속아서 동의하면, 앱이 그 권한을 악용할 수 있습니다. 이는 동의 피싱(consent phishing) 공격의 주요 경로입니다. 그래서 누가 어떤 권한을 부여할 수 있는지 엄격하게 통제하고, 동의 화면이 실제로 무엇을 의미하는지에 대한 보안 인식 교육을 탄탄하게 해야 합니다.

Microsoft Entra ID에서의 앱 접근 과다 권한 부여와 토큰 보안

권한에 관해서는 많을수록 좋은 것은 아닙니다. 실제로 과다 권한 부여, 즉 불필요하거나 지나친 권한을 부여하는 것은 특히 애플리케이션 권한에서 민감한 데이터 유출과 주요 보안 사고로 이어질 수 있습니다. 예를 들어 앱에 회사의 모든 사서함에 대한 읽기 및 쓰기 권한을 부여했는데 앱이 캘린더 일정만 읽으면 된다면, 공격 표면이 크게 넓어진 것입니다.

이는 이론적인 위험만이 아닙니다. 공격자들은 OAuth 동의 악용을 통해 다단계 인증(MFA)까지 우회하고 있습니다. 교묘하게 만든 동의 요청으로 사용자나 관리자를 속여 위험한 권한을 승인하도록 유도합니다. 일단 침투하면 악성 앱은 비밀번호가 변경되거나 MFA가 적용되더라도 접근 권한을 유지하는 경우가 많습니다. 공격자의 장악력이 지속되어 기존 방어 수단이 효과를 잃게 됩니다. 실제 사례 분석은 공격자가 Entra ID에서 OAuth 동의를 악용하는 방식에 대한 이 설명을 참고하고, 이를 차단하는 최선의 방법도 함께 확인해 보시기 바랍니다.

문제는 과다 권한 부여에서 그치지 않습니다. 보호되지 않은 토큰과 자격 증명(클라이언트 암호와 인증서 포함)도 공격자에게는 귀중한 목표가 될 수 있습니다. 애플리케이션 전용 등록에서 유출된 클라이언트 암호 하나만 있어도 공격자는 서비스를 가장할 수 있습니다. 따라서 자격 증명 관리가 필수적입니다. 가능하면 관리 ID를 사용하고, 암호를 주기적으로 교체하며, 클라이언트 자격 증명을 코드나 보호되지 않은 파일에 절대 저장하지 마십시오. 사용자가 아닌 주체의 접근이 필요한 환경이라면 Microsoft Entra 워크로드 ID를 고려해 보십시오. 워크로드 ID는 암호 없이 감사 가능한 접근을 제공하며, 레거시 서비스 계정의 번거로움을 없애 줍니다. 이에 대한 더 자세한 내용은 제로 트러스트에 워크로드 ID가 필수인 이유를 참고하시기 바랍니다.

마지막으로, 적절한 모니터링은 선택이 아니라 필수입니다. 로그인 로그와 OAuth 권한 부여 내역을 정기적으로 검토하고, 의심스러운 동의나 토큰 사용에 대한 알림을 설정하며, 동의 피싱과 토큰 탈취에 선제적으로 대응하십시오. 실제 침해 사례(이 Microsoft 365 공격 체인과 같은 사례)에서 확인된 바에 따르면, 공격자들은 취약한 거버넌스를 악용합니다. 가시성이 높을수록 좋습니다. 키를 보호하고, 권한을 엄격하게 관리하며, 앱이 정직하게 동작하도록 관리하십시오.

위임된 권한과 애플리케이션 권한 관리를 위한 통제 방안과 모범 사례

• 권한 관리를 위한 Entra 기본 제공 제어 구현Microsoft Entra의 기본 제공 동의 워크플로, 관리자 승인 프로세스, 세분화된 정책을 활용해 어떤 사용자나 그룹이 권한을 부여할 수 있는지 제한하십시오. 관리자 동의 정책을 사용하면 검증된 앱만 고위험 범위를 부여받도록 할 수 있습니다.
• 최소 권한 원칙 적용앱에는 기능 수행에 꼭 필요한 최소한의 권한만 부여하십시오. 앱 등록 중 요청된 권한을 하나씩 검토하고 불필요한 권한은 모두 제거하십시오. 최소 권한 원칙은 권한 남용과 과도한 접근에 맞서는 가장 강력한 방어 수단입니다.
• 정기적인 권한 검토 및 감사 일정 수립Entra의 권한 및 동의 대시보드를 활용해 정기적인 액세스 검토를 설정하고, 사용되지 않거나 위험한 권한을 찾아 취소하십시오. 가능하면 이러한 점검을 자동화해 확장 가능한 거버넌스를 구현하십시오. 보다 심화된 거버넌스 가이드, 예를 들어 이 Microsoft Purview 전략에서도 관련 방법을 다루고 있습니다.
• 권한 변경 모니터링 및 경고 설정새로운 OAuth 권한 부여, 앱 권한 사용량의 급증, 예상치 못한 관리자 통합을 포착할 수 있도록 모니터링과 경고를 구성하십시오. 사전 보고를 받으면 보안 문제가 확대되기 전에 대응할 시간을 확보할 수 있습니다.
• 토큰 및 자격 증명 보관 보안 강화클라이언트 비밀과 토큰은 Azure Key Vault와 같은 보안 저장소에 보관하십시오. 자격 증명을 정기적으로 교체하고, 공유 비밀 대신 인증서를 사용하며, 사람이 아닌 액세스를 통합할 때는 워크로드 ID를 우선 사용하십시오. 워크로드 ID는 수명 주기 관리와 감사 가능성이 더 뛰어나기 때문입니다.
• 고급 거버넌스 및 정책 자동화 도입Microsoft Purview와 Azure Policy 같은 도구를 활용해 테넌트 전체에 대한 통제를 적용하고, 데이터 손실 방지(DLP)로 위험을 분리하며, 지속적인 규정 준수를 고려한 설계를 하십시오. 설계 단계부터 정책으로 거버넌스를 구현하는 실제 사례는 Azure 엔터프라이즈 거버넌스 전략을 참고하십시오.

이러한 단계를 따르고 Microsoft의 거버넌스 도구 생태계를 활용하면, 권한 관련 위험이 문제로 번지기 전에 관리할 수 있는 역량을 갖추게 됩니다. 사용자에게 안전한 동의 방법을 꾸준히 교육하고, 가능한 모든 부분을 자동화하며, 권한 관리는 한 번으로 끝나지 않는다는 점을 기억하십시오. 항상 경계를 늦추지 말고 정책을 계속 개선하면, Entra ID 환경을 건강하게 유지할 수 있습니다.

함께 들어볼 만한 에피소드

delegated vs application permissions Entra ID를 살펴보고 계신다면, 다음 에피소드들이 안전한 Microsoft 365 도입, 데이터 보호, 거버넌스, AI 위험 관리에 대한 실무적인 배경 지식을 제공합니다.

• Microsoft Purview – Simply Explained — 분류, 보존, 규정 준수, 보호가 하나의 Microsoft 데이터 거버넌스 모델에서 어떻게 맞물리는지 살펴봅니다.
• Microsoft Defender XDR – Simply Explained — 데이터 보호 제어를 탐지, 조사, 대응과 연결하는 방법을 알아봅니다.
• Conditional Access – Simply Explained — ID 및 위험 신호가 액세스 결정에 어떤 맥락을 더하는지 이해합니다.
• Microsoft AI Agent Harness – Simply Explained — AI 자동화를 더 안정적이고, 관찰 가능하며, 안전하게 만드는 제어 방법을 살펴봅니다.

이 에피소드들은 본문의 개념을 실제 설계 및 도입 결정으로 옮기는 데 도움이 됩니다.