Bu makalede6 bölüm
- Teknoloji
- Microsoft Graph, Entra ID, OAuth 2.0
- Konu
- İzin tasarımı ve en az yetki
- Seviye
- İleri
- İlgili dokümantasyon
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ı:
.Readyeterliyse.ReadWriteverilmez;.Allkapsamları gerekçesiz kullanılmaz.
Tasarım adımları
- Senaryoyu yazın: Uygulama hangi veriyi, hangi işlem için, hangi sıklıkla kullanıyor; kullanıcı bağlamı var mı?
- Gerekli API çağrılarını listeleyin: Her çağrı için Microsoft Learn’deki izin tablosundan en az yetkili izni seçin.
- Daraltmayı uygulayın: Sites.Selected, Exchange uygulama kapsamı veya RSC.
- Kimlik doğrulama yöntemini seçin: Sertifika veya yönetilen kimlik; gizli anahtar kaçınılmazsa kısa ömürlü ve kasada.
- İzin kaydı tutun: Uygulama, sahip, izin, gerekçe, onaylayan, tarih ve yıllık gözden geçirme tarihi.
- 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.
- Teknoloji
- Microsoft Graph, Entra ID, OAuth 2.0
- Konu
- İzin tasarımı ve en az yetki
- Seviye
- İleri
- İlgili dokümantasyon
Entegrasyon ve Bakım
- Microsoft Graph API EntegrasyonlarıEntra ID, Teams, SharePoint, Outlook ve Intune verilerini uygulamalara bağlıyoruz: OAuth 2.0, delegated/application izinleri, en az yetki ve…
- Microsoft Teams ve Kurumsal EntegrasyonlarTeams’e iş süreçlerini bağlıyoruz: Adaptive Card bildirimleri, onaylar, sekme uygulamaları, Graph API ile ekip yönetimi ve yönetişim kuralları.
- Microsoft 365 Entegre Helpdesk ve SLA SistemiSharePoint, Power Apps, Power Automate ve Teams ile SLA takvimli, eskalasyonlu, denetim izli kurumsal BT destek sistemi. ISO…