10110010011101001011001101101110101018200.devFrom Enterprise.Systems

Slack, GitHub ve Microsoft 365 Genelinde Üçüncü Taraf OAuth Uygulamaları Nasıl Denetlenir

The 8200.dev Team5 dk okuma

Üçüncü taraf OAuth uygulamalarını denetlemek için her platformun kendi yetkilendirme listesini ayrı ayrı kontrol edin: Slack'in Installed Apps sayfası, GitHub'ın organizasyon OAuth uygulama politikası ve Microsoft Entra'nın Enterprise applications listesi. Her biri aynı temel sorunun farklı bir kesitini gösterir — hangi uygulamalar verileriniz üzerinde işlem yapabilir — ve hiçbiri diğer ikisini göstermez.

Bu kılavuz her platform için tam yolu, neyi gösterdiğini ve platform bazlı bir denetimin nerede yetersiz kaldığını sunar.

Slack'te yetkilendirilmiş OAuth uygulamalarını nerede görürüm?

Settings & administration → Manage apps bölümüne gidin; bu, çalışma alanınıza özel Slack Marketplace'i açar, ardından kenar çubuğunun üstünde Installed Apps seçeneğini seçin. Bu, her Slack planında kullanılabilir ve yüklü her uygulamayı onaylandığı kapsamlarla birlikte listeler.

Enterprise Grid'de, yönetici panelinin Integrations bölümü, tüm çalışma alanları genelinde tek seferde organizasyon çapında bir görünüm ekler. Bu çalışma alanları arası görünüm, admin.apps:read kapsamı tarafından desteklenir; bu kapsam yalnızca Enterprise Grid ile sınırlıdır ve orada bile yalnızca hangi uygulamaların onaylandığını, kısıtlandığını veya beklemede olduğunu gösterir; aynı çağrıda her uygulamanın tam kapsam listesini göstermez. Tek bir çalışma alanında, Installed Apps sayfası bir uygulamanın gerçekte ne yapabileceğine dair güvenilir kaynak olmaya devam eder.

GitHub'da yetkilendirilmiş OAuth uygulamalarını nerede görürüm?

Organizasyonunuzun Settings → Third-party Access → OAuth app policy bölümüne gidin. Yeni organizasyonlarda OAuth uygulama erişim kısıtlamaları varsayılan olarak açıktır, bu nedenle bu sayfa aynı zamanda üyelerin yeni bir uygulama için erişim talep ettiği ve bir sahibin bunu onayladığı veya reddettiği yerdir. Daha önce onaylanmış bir uygulamayı iptal etmek için, aynı listede bulun ve Deny access seçeneğini seçin.

GitHub Apps (klasik OAuth Apps'ten farklı bir mekanizma olup çoğu modern entegrasyon tarafından kullanılır) farklı bir yerde incelenir: organizasyon Settings → Integrations → GitHub Apps (veya Installed GitHub Apps) bölümü, neyin yüklü olduğunu ve her birinin hangi depolara erişebildiğini listeler.

2026 itibarıyla, bir organizasyon ayrıca Settings → Third-party Access üzerinden yeni bir uygulama *talep etme* iznine bile kimin sahip olduğu konusunda kademeli kontroller belirleyebilir: hem üyeler hem de dış işbirlikçiler uygulama talep edebilir (uzun süredir devam eden varsayılan), dış işbirlikçiler engellenirken üyeler yine de talepte bulunabilir veya her iki grup da herhangi bir uygulama talep etmekten tamamen engellenebilir — bu da bir talep bir sahibin kuyruğuna ulaşmadan önce denetim yüzeyini daraltır. Organizasyon genelindeki OAuth uygulama erişim kısıtlamasının kendisi de tamamen kapatılabilir; bu, her üye için onay adımını kaldırır — OAuth uygulama politikası listesine yetkilendirilmiş her şeyin eksiksiz bir kaydı olarak güvenmeden önce bunun hâlâ açık olup olmadığını doğrulamaya değer bir ayardır.

Microsoft 365'te yetkilendirilmiş OAuth uygulamalarını nerede görürüm?

Microsoft Entra yönetim merkezi'ne giriş yapın ve Identity → Applications → Enterprise applications → All applications bölümüne gidin. Bir uygulama seçin, ardından Permissions seçeneğini seçin. Admin consent sekmesi, tüm kiracı için verilen izinleri gösterir — ve doğrudan orada iptal edilebilir. User consent sekmesi, bireysel kullanıcıların kendileri için onayladıklarını gösterir — ve portal bunun için bir iptal düğmesi sunmaz; bunu geri almak, bir Microsoft Graph API çağrısı veya Cloud Application Administrator rolüne sahip birinin çalıştıracağı bir PowerShell cmdlet'i gerektirir. Bir kiracı kullanıcı onayını tamamen engelliyorsa, bir Global Administrator bunun yerine bir admin consent iş akışı açabilir, böylece engellenen bir talep çıkmaz bir yol olmak yerine incelenebilir hale gelir — bu inceleme kuyruğunun tam olarak nasıl çalıştığı için Microsoft 365 erişim kılavuzuna bakın.

Platform bazlı bir denetimi güncel tutmak neden zordur?

Üç konsol, üç format, açmak için bile gereken üç farklı yönetici rolü. Slack'in organizasyon çapındaki programatik görünümü Enterprise Grid gerektirir; Microsoft'un kullanıcı düzeyindeki izinleri bir portal tıklaması yerine PowerShell veya Graph gerektirir; GitHub, klasik OAuth Apps'i GitHub Apps'ten ayırır ve bir yöneticinin ayrı ayrı kontrol etmesi gerektiğini bilmesi gereken iki farklı liste haline getirir. Slack ayrıca kendi Installed Apps görünümünü Approved, Restricted ve Requests sekmelerine böler, bu nedenle eksiksiz bir tarama, üç platformun üzerine üç filtreyi kontrol etmek anlamına gelir. Üçünden hiçbiri bir uygulamayı riske göre sıralamaz ve hiçbiri aynı sağlayıcının diğer iki platformda da daha geniş bir izin kümesiyle bağlı olup olmadığını söylemez.

Platform bazlı bir liste size neyi söyleyemez ve 8200.dev bunu nasıl yanıtlar?

Her konsol, o tek platformda neyin yetkilendirildiğini söyler. Hiçbiri size birleşik resmi söylemez — aynı yapay zeka not alma uygulamasının Slack kanallarına, bir GitHub deposuna ve bir Microsoft 365 posta kutusuna bağlı olması, her birinin ayrı ayrı verilmiş kendi kapsamıyla. 8200.dev'in Agent Guard'ı, en az ayrıcalık ilkesine sahip, salt okunur kapsamlarla üçünü de okur — Slack'in channels:read, groups:read, files:read, users:read ve ilgili salt okunur kapsamları artı bir çalışma alanı yapılandırma denetimi; GitHub'ın read:org, salt okunur depo erişimi, read:user, kurulum envanteri, salt okunur Copilot faturalama görünürlüğü ve read:audit_log; ve Microsoft 365'in 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 ve DelegatedPermissionGrant.Read.All — ve üçünden gelen her bulguyu risk puanlaması yapılmış tek bir envantere yerleştirir. Microsoft 365 bağlayıcısı, tek bir sabit kiracı yerine herhangi bir organizasyonun kendi Microsoft iş veya okul dizini ile çalışır, bu nedenle organizasyonunuz resimdeki tek organizasyon olsa da birden fazlasından biri olsa da aynı şekilde bağlanır.

Bu kapsamların her biri salt okunurdur. Buradaki hiçbir şey kendi başına bir uygulamanın erişimini iptal etmez — bu, bir organizasyonun bilinçli olarak harekete geçtiği bir öneri veya otomatikleştirilmesini istediği belirli kural için açık bir katılım olarak kalır.

Tam kapsam listesi ve her birinin neyi taradığı için Slack, GitHub ve Microsoft 365 bağlayıcı sayfalarına bakın.

PaylaşX / TwitterLinkedIn

İlgili kılavuzlar