ERETEK
BİLGİ SİSTEMLERİ

Microsoft Graph API İzinleri Nasıl Tasarlanır?

Microsoft Graph API izinleri nasıl tasarlanır? Delegated ve application izinleri, Sites.Selected, en az yetki, yönetici onayı, sertifika ve throttling.

Bu makalede6 bölüm

Microsoft Graph, Microsoft 365 verilerine (kullanıcılar, gruplar, Teams, SharePoint, Outlook, Intune) tek bir API üzerinden erişim sağlar. Bu güç, yanlış izin tasarımında ciddi bir riske dönüşür: bir rapor uygulamasına verilen geniş bir izin, kiracıdaki tüm e-postalara veya dosyalara erişim anlamına gelebilir. Bu rehber Graph entegrasyonlarında izinlerin en az yetki ilkesine göre nasıl tasarlanacağını anlatır.

İki izin türü: delegated ve application

Delegated (temsili) Application (uygulama)
Kimin adına? Oturum açmış kullanıcı Uygulamanın kendisi; kullanıcı yok
Etkin erişim İzin ∩ kullanıcının kendi yetkileri İznin kapsadığı tüm kiracı (daraltılmadıkça)
Tipik kullanım Kullanıcının kendi verisiyle çalışan arayüzler Arka plan servisleri, senkronizasyon, otomasyon
Onay Kullanıcı veya yönetici (izne göre) Her zaman yönetici onayı

Temel kural: Kullanıcı arayüzü varsa önce delegated izinlerle çözüm aranır. Application izni yalnızca gerçekten kullanıcısız çalışan senaryolarda ve mümkün olan en dar kapsamla verilir.

Kapsamı daraltma mekanizmaları

  • SharePoint ve OneDrive – Sites.Selected: Uygulamaya tüm sitelere değil, yalnızca yönetici tarafından açıkça yetkilendirilen sitelere (okuma veya yazma) erişim verir. Helpdesk veya intranet entegrasyonlarında tercih edilmelidir.
  • Exchange Online – uygulama erişimini sınırlama: Posta ve takvim application izinleri, Exchange’in uygulamalar için rol tabanlı erişim denetimi (RBAC for Applications) ile belirli posta kutularıyla sınırlandırılabilir.
  • Teams – kaynak özelinde onay (RSC): Uygulamanın yalnızca yüklendiği ekip veya sohbette yetki almasını sağlar.
  • Okuma ve yazma ayrımı: .Read yeterliyse .ReadWrite verilmez; .All kapsamları gerekçesiz kullanılmaz.

Tasarım adımları

  1. Senaryoyu yazın: Uygulama hangi veriyi, hangi işlem için, hangi sıklıkla kullanıyor; kullanıcı bağlamı var mı?
  2. Gerekli API çağrılarını listeleyin: Her çağrı için Microsoft Learn’deki izin tablosundan en az yetkili izni seçin.
  3. Daraltmayı uygulayın: Sites.Selected, Exchange uygulama kapsamı veya RSC.
  4. Kimlik doğrulama yöntemini seçin: Sertifika veya yönetilen kimlik; gizli anahtar kaçınılmazsa kısa ömürlü ve kasada.
  5. İzin kaydı tutun: Uygulama, sahip, izin, gerekçe, onaylayan, tarih ve yıllık gözden geçirme tarihi.
  6. Yönetici onayını bu kayda dayandırın.

Örnek: helpdesk entegrasyonu

Bir Microsoft 365 helpdesk sisteminin arka plan servisi; talep sahibinin yöneticisini okumalı, ilgili SharePoint sitesindeki talep listesine yazmalı ve Teams kanalına bildirim göndermelidir. En az yetkili tasarım: kullanıcı ve yönetici bilgisi için temel profil okuma izni, SharePoint için yalnızca helpdesk sitesine Sites.Selected yazma yetkisi, bildirimler için Teams Workflows veya kanal kapsamlı izin. “Sites.ReadWrite.All” veya “Directory.ReadWrite.All” gibi geniş izinlere ihtiyaç yoktur.

İşletim ve güvenlik

  • Sertifika ve gizli anahtarların bitiş tarihleri izlenir; yenileme prosedürü yazılıdır.
  • Uygulama kayıtlarının ve izinlerin yıllık gözden geçirmesi yapılır; kullanılmayan uygulamalar kaldırılır.
  • Uygulama oturum açmaları ve Graph etkinlikleri Entra ID günlüklerinden izlenir.
  • Koşullu erişim ilkeleri iş yükü kimliklerine uygulanabiliyorsa (lisansa bağlı) değerlendirilir.
  • Throttling için Retry-After’a uyan yeniden deneme, batch istekleri ve delta sorguları kullanılır.

Sık sorulan sorular

Application izni verilen bir uygulama tüm kiracıya mı erişir?

Varsayılan olarak evet; örneğin Mail.Read application izni tüm posta kutularını kapsar. Bu nedenle Exchange için uygulama erişim kapsamı, SharePoint için Sites.Selected gibi daraltma mekanizmaları kullanılmalıdır.

İstemci gizli anahtarı (client secret) mı sertifika mı?

Sertifika tabanlı kimlik doğrulama veya Azure’da çalışan servisler için yönetilen kimlik tercih edilmelidir. Gizli anahtar kullanılıyorsa kısa ömürlü olmalı, güvenli kasada saklanmalı ve bitiş tarihi izlenmelidir.

Graph API çağrıları neden 429 hatası veriyor?

Graph, hizmet bazında istek sınırları uygular (throttling). 429 yanıtındaki Retry-After süresine uyulmalı, toplu işlemler batch isteklerle yapılmalı ve değişiklikleri takip etmek için delta sorguları veya değişiklik bildirimleri kullanılmalıdır.

İzin adları ve davranışları zaman içinde güncellenebildiğinden, uygulama öncesinde Microsoft Learn’deki güncel izin referansı kontrol edilmelidir. Entegrasyonunuzu güvenli izin modeliyle kurmak için Microsoft Graph API entegrasyonları hizmetimizi inceleyebilirsiniz.

Eretek uzman desteği

Bu konuyu projeniz için birlikte değerlendirelim.

Mevcut yapınızı inceleyip ihtiyacınıza uygun, sürdürülebilir bir çözüm planı öneriyoruz.