Slack, GitHub, Microsoft 365 전반의 서드파티 OAuth 앱을 감사하는 방법

서드파티 OAuth 앱을 감사하려면 각 플랫폼의 자체 승인 목록을 개별적으로 확인해야 합니다: Slack의 Installed Apps 페이지, GitHub의 조직 OAuth 앱 정책, Microsoft Entra의 Enterprise applications 목록이 그것입니다. 각 화면은 동일한 근본 문제 — 어떤 앱이 귀사의 데이터에 접근할 수 있는가 — 를 서로 다른 단면으로 보여주며, 어느 것도 나머지 두 플랫폼을 보여주지 않습니다.

이 가이드는 각 플랫폼의 정확한 경로와 무엇을 보여주는지, 그리고 플랫폼별 감사가 한계에 부딪히는 지점을 설명합니다.

Slack에서 승인된 OAuth 앱은 어디에서 확인할 수 있습니까?

Settings & administration → Manage apps로 이동하십시오. 이는 귀사의 워크스페이스로 범위가 지정된 Slack Marketplace를 열며, 이어서 사이드바 상단의 Installed Apps를 선택하십시오. 이는 모든 Slack 플랜에서 이용 가능하며, 설치된 각 앱과 해당 앱이 승인받은 스코프를 나열합니다.

Enterprise Grid에서는 관리자 대시보드의 Integrations 섹션이 모든 워크스페이스를 한꺼번에 아우르는 조직 전체 보기를 추가합니다. 이 워크스페이스 간 보기는 admin.apps:read 스코프로 구동되며, 이는 Enterprise Grid에 한정되어 있고 — 그곳에서조차 — 어떤 앱이 승인됨, 제한됨, 또는 대기 중인지만 보여줄 뿐, 동일한 호출에서 각 앱의 전체 스코프 목록을 노출하지는 않습니다. 단일 워크스페이스에서는 Installed Apps 페이지가 여전히 앱이 실제로 무엇을 할 수 있는지에 대한 가장 신뢰할 수 있는 정보원입니다.

GitHub에서 승인된 OAuth 앱은 어디에서 확인할 수 있습니까?

조직의 Settings → Third-party Access → OAuth app policy로 이동하십시오. 신규 조직은 기본적으로 OAuth 앱 접근 제한이 켜져 있으므로, 이 페이지는 구성원이 새 앱에 대한 접근을 요청하고 소유자가 이를 승인 또는 거부하는 곳이기도 합니다. 이전에 승인된 앱을 철회하려면 동일한 목록에서 해당 앱을 찾아 Deny access를 선택하십시오.

GitHub Apps(대부분의 최신 통합에서 사용되는, 클래식 OAuth Apps와는 별개의 메커니즘)는 다른 위치에서 검토됩니다: 조직 Settings → Integrations → GitHub Apps(또는 Installed GitHub Apps)는 무엇이 설치되어 있고 각 앱이 어떤 저장소에 접근할 수 있는지를 나열합니다.

2026년 기준으로, 조직은 애초에 누가 새 앱을 *요청*할 수 있는지에 대해서도 Settings → Third-party Access에서 단계별 제어를 설정할 수 있습니다: 구성원과 외부 협업자 모두 앱을 요청할 수 있도록 하거나(오랫동안 유지된 기본값), 외부 협업자는 차단하되 구성원은 계속 요청할 수 있도록 하거나, 두 그룹 모두 어떤 앱도 요청하지 못하도록 막을 수 있습니다 — 이는 요청이 소유자의 대기열에 도달하기도 전에 감사 대상 범위를 좁혀줍니다. 조직 전체의 OAuth 앱 접근 제한 자체도 완전히 끌 수 있는데, 이 경우 모든 구성원에 대한 승인 단계가 사라집니다 — OAuth app policy 목록을 승인된 내역의 완전한 기록으로 신뢰하기 전에 이 설정이 여전히 켜져 있는지 확인할 가치가 있습니다.

Microsoft 365에서 승인된 OAuth 앱은 어디에서 확인할 수 있습니까?

Microsoft Entra admin center에 로그인하여 Identity → Applications → Enterprise applications → All applications로 이동하십시오. 앱을 선택한 다음 Permissions를 선택하십시오. Admin consent 탭은 전체 테넌트에 대해 부여된 권한을 보여주며 — 해당 화면에서 직접 철회할 수 있습니다. User consent 탭은 개별 사용자가 스스로 승인한 내용을 보여주지만 — 포털은 이를 철회할 버튼을 제공하지 않으며, 이를 되돌리려면 Cloud Application Administrator 역할을 가진 사람이 실행하는 Microsoft Graph API 호출이나 PowerShell cmdlet이 필요합니다. 테넌트가 사용자 동의를 완전히 차단하는 경우, Global Administrator는 대신 관리자 동의 워크플로를 켤 수 있으므로, 차단된 요청이 막다른 골목이 아니라 검토 가능한 요청이 됩니다 — 이 검토 대기열이 정확히 어떻게 작동하는지는 Microsoft 365 access guide를 참조하십시오.

플랫폼별 감사를 최신 상태로 유지하기 어려운 이유는 무엇입니까?

세 개의 콘솔, 세 가지 형식, 그리고 이를 열어보기 위해서조차 필요한 세 가지 서로 다른 관리자 역할이 존재합니다. Slack의 조직 전체 프로그래밍 방식 보기는 Enterprise Grid가 필요하고, Microsoft의 사용자 수준 권한 부여는 포털 클릭이 아니라 PowerShell이나 Graph가 필요하며, GitHub는 클래식 OAuth Apps와 GitHub Apps를 별도로 확인해야 하는 두 개의 서로 다른 목록으로 분리합니다. 게다가 Slack은 자체 Installed Apps 보기를 Approved, Restricted, Requests 탭으로 나누고 있어, 완전한 점검을 위해서는 세 플랫폼 위에 세 가지 필터를 추가로 확인해야 합니다. 이 셋 중 어느 것도 앱을 위험도에 따라 순위 매기지 않으며, 동일한 공급업체가 다른 두 플랫폼에도 더 광범위한 권한 세트로 연결되어 있는지 알려주지 않습니다.

플랫폼별 목록이 알려줄 수 없는 것, 그리고 8200.dev가 이를 어떻게 해결하는가

각 콘솔은 해당 플랫폼 하나에서 승인된 것만 알려줍니다. 그중 어느 것도 결합된 전체 그림 — 동일한 AI 노트 작성 앱이 Slack 채널, GitHub 저장소, Microsoft 365 메일함에 각각 별도로 부여된 스코프로 연결되어 있는 상황 — 을 알려주지 않습니다. 8200.dev의 Agent Guard는 최소 권한, 읽기 전용 스코프로 세 플랫폼 모두를 읽습니다 — Slack의 channels:read, groups:read, files:read, users:read 및 관련 읽기 스코프에 워크스페이스 구성 감사를 더한 것; GitHub의 read:org, 읽기 전용 저장소 접근, read:user, 설치 인벤토리, 읽기 전용 Copilot 청구 가시성, read:audit_log; 그리고 Microsoft 365의 Sites.Read.All, Files.Read.All, Directory.Read.All, Application.Read.All, User.Read.All, Policy.Read.All, Reports.Read.All, AuditLog.Read.All, RoleManagement.Read.Directory, DelegatedPermissionGrant.Read.All — 이렇게 확인된 모든 결과를 하나의 위험도 점수화된 인벤토리에 통합합니다. Microsoft 365 커넥터는 단일 고정 테넌트가 아니라 모든 조직의 자체 Microsoft 업무용 또는 학교 디렉터리와 작동하므로, 귀사의 조직이 유일한 주체이든 여러 조직 중 하나이든 동일한 방식으로 연결됩니다.

이 모든 스코프는 읽기 전용입니다. 여기서 자체적으로 앱의 접근 권한을 철회하는 일은 없습니다 — 이는 조직이 신중하게 실행하는 권고 사항으로 남거나, 조직이 자동화를 원하는 특정 규칙에 대한 명시적 옵트인으로 남습니다.

전체 스코프 목록과 각 커넥터가 스캔하는 항목은 Slack, GitHub, Microsoft 365 커넥터 페이지를 참조하십시오.