Microsoft 365에 접근 권한을 가진 앱을 확인하는 방법

Microsoft Entra 관리 센터의 Identity → Applications → Enterprise applications → All applications 경로에서 Microsoft 365 테넌트에 접근 권한을 가진 모든 앱을 확인하실 수 있습니다. 앱을 선택하고 Permissions 탭을 열면 해당 앱이 Microsoft Graph 데이터의 정확히 어느 부분에 접근할 수 있는지 확인할 수 있으며, 이는 조직의 관리자가 승인한 권한과 개별 사용자가 스스로 승인한 권한으로 나뉘어 표시됩니다.

이 가이드에서는 이 경로 전체와, 많은 분들이 혼동하는 관리자 동의와 사용자 동의의 구분, 그리고 앱을 하나씩 검토하는 방식으로는 알 수 없는 부분을 다룹니다.

Entra에서 접근 권한을 가진 앱 목록은 어디에서 찾을 수 있습니까?

1. 최소한 Cloud Application Administrator 또는 Application Administrator 역할을 가진 계정으로 entra.microsoft.com에 로그인하십시오.
2. Identity → Applications → Enterprise applications → All applications로 이동하십시오.
3. 검토하려는 앱을 선택한 다음 Permissions를 여십시오.

여기에는 사용자 동의 또는 관리자 동의를 통해 테넌트에 추가된 모든 애플리케이션이 나열됩니다 — Microsoft의 ID 플랫폼을 통해 연결되는 AI 비서, 회의 봇, 생산성 확장 프로그램은 물론 업무용 애플리케이션까지 포함됩니다. 이 목록에는 Microsoft의 자체 앱과 타사 등록 앱이 모두 포함되므로, 익숙한 이름들을 지나쳐서 시간이 지나며 조용히 권한을 축적해 온 다른 항목들도 살펴볼 가치가 있습니다.

관리자 동의와 사용자 동의의 차이점은 무엇입니까?

Permissions 탭은 다음 두 가지로 나뉩니다:

• Admin consent(관리자 동의) — 관리자가 조직 전체를 위해 부여한 권한입니다. 이는 우연히 클릭한 특정 사용자뿐 아니라 해당 부여 대상에 포함되는 모든 사용자에게 적용됩니다.
• User consent(사용자 동의) — 테넌트의 동의 설정이 허용하는 경우, 관리자의 개입 없이 개인이 한 번에 한 명씩 스스로 승인한 권한입니다.

목록에 표시된 권한을 선택하면 Permission Details 창이 열리며 해당 권한이 정확히 무엇을 허용하는지 설명합니다.

앱의 접근 권한을 취소하려면 어떻게 해야 합니까?

Admin consent(관리자 동의) 부여의 경우: 목록에서 해당 권한을 열고 옆에 있는 … 컨트롤을 선택한 다음 Revoke permission을 선택하십시오 — 이는 포털에서 직접 작동합니다.

User consent(사용자 동의) 부여의 경우, 포털에는 취소 버튼이 없습니다. 이를 되돌리려면 Microsoft Graph API 호출(위임된 권한의 경우 DELETE /oAuth2PermissionGrants/{id}, 애플리케이션 권한의 경우 동등한 appRoleAssignments 호출) 또는 이에 대응하는 PowerShell cmdlet을, Cloud Application Administrator 역할을 가진 사람이 실행해야 합니다. 부여를 취소해도 동일한 사용자가 다음번에 해당 앱이 다시 요청할 때 재차 동의하는 것을 막지는 못합니다 — 이를 막으려면 Enterprise apps → Consent and permissions → User consent settings에서 테넌트의 동의 정책을 별도로 변경해야 합니다.

사용자가 스스로 부여할 수 없는 권한에 부딪히면 어떻게 됩니까?

테넌트가 사용자 동의를 제한하는 경우, 그 한도를 초과하는 권한을 요청하는 앱에 로그인하려는 사람은 동의가 아니라 차단에 부딪히게 됩니다. Global Administrator는 Enterprise apps → Consent and permissions → Admin consent settings에서 admin consent workflow를 활성화할 수 있으며, 이를 통해 해당 사용자는 대신 요청을 보낼 수 있습니다. 이 요청은 검토자로 지정된 사용자, 그룹, 역할에게 이메일로 전달되며, 이들은 자신의 My Pending 탭에서 승인, 차단 또는 거부할 수 있습니다. Microsoft Graph 애플리케이션 권한에 대한 요청은 오직 Global Administrator만 승인할 수 있으며, 검토자로 지정되었다고 해서 그 권한이 자동으로 부여되는 것은 아닙니다. 각 요청은 설정 가능한 일수가 지나면 만료되므로, 검토되지 않은 요청이 무기한 열려 있는 상태로 남지 않습니다.

조직이 여러 Microsoft 365 테넌트나 파트너 디렉터리에 걸쳐 있다면 어떻게 됩니까?

하나의 테넌트 내에서의 검토는 그 테넌트만 보여줍니다. 조직이 둘 이상의 Microsoft 365 디렉터리에서 운영되는 경우 — 예를 들어 모회사와 인수한 자회사, 혹은 파트너사의 자체 테넌트 — 각 디렉터리마다 동일한 절차를 각각 진행해야 하며, 각 디렉터리에 알맞은 역할로 로그인해야 합니다. 단일 조직을 위해 만들어진 고정 테넌트 도구는 두 번째 디렉터리가 그림에 추가되는 순간 작동하지 않게 되므로, 둘 이상의 테넌트를 다루기 위한 도구라면 원래 설정된 디렉터리뿐 아니라 어떤 조직의 자체 디렉터리에서든 동의를 받을 수 있도록 지원해야 합니다.

앱을 하나씩 검토하는 방식으로는 무엇을 알 수 없으며, 8200.dev는 이에 어떻게 답합니까?

Enterprise applications를 앱 하나씩 살펴보면 각 앱이 접근할 수 *있도록 허용된* 범위는 알 수 있습니다. 하지만 그 앱들이 실제로 얼마나 위험한지에 따라 순위를 매기지 않고, 어떤 부여가 오래되어 방치되었는지 표시하지 않으며, 목록을 검토하는 동안 가만히 멈춰 있지도 않습니다 — 마지막 항목을 검토하는 중에도 새로운 동의가 발생할 수 있습니다. 8200.dev의 Microsoft 365 커넥터는 Sites, Files, Directory, Application registrations, Users, 테넌트 보안 정책, MFA 등록 보고서, 감사 로그, 역할 할당, 위임된 권한 부여를 모두 읽기 전용 Graph 스코프를 통해 읽어들이며, 이를 손수 다시 열어 확인해야 하는 목록이 아니라 지속적으로 업데이트되는 위험 점수화된 하나의 인벤토리로 전환합니다. 이와 동일한 읽기 전용 접근은 앱 인벤토리와 함께 테넌트 전체 구성 감사도 실행합니다: Security Defaults 및 Conditional Access 정책 상태, 앱 동의 정책, 외부 협업 설정까지 포함되므로, 과도한 권한을 가진 앱과 그 앱을 들여보낸 느슨해진 테넌트 정책이 서로 무관한 두 번의 검토가 아니라 함께 드러납니다. 이는 동일한 방식으로 어떤 조직의 자체 Microsoft 업무용 또는 학교용 디렉터리에도 연결되므로, 여러 테넌트에 걸친 그룹이라도 테넌트마다 별도의 설정이 필요하지 않습니다. 여기 언급된 모든 스코프는 읽기 전용이며, 조직이 특정 작업을 자동화하기로 별도로 선택하지 않는 한 어떠한 권한이나 정책도 변경되지 않습니다.

이것이 Google Workspace, Slack, GitHub와 어떻게 함께 작동하는지는 전체 커넥터 목록을 참고하십시오.