SHAREPOİNT YETKİ MİMARİSİ: GRUPLAR, ERİŞİM VE EN AZ YETKİ PRENSİBİ
SharePoint’te “kim neyi görebilir?” sorusu, sadece bir güvenlik detayı değil; bilgi yönetimi, uyumluluk ve operasyonel verimlilik için kritik bir tasarım kararıdır. Yanlış kurgulanmış bir yetki mimarisi, bir yandan veri sızıntısı riskini büyütürken diğer yandan ekiplerin işini yavaşlatır.
Özellikle Microsoft 365 ekosisteminde SharePoint, Teams, OneDrive ve Azure AD (Entra ID) arasında kurulan bağlar nedeniyle, basit görünen bir izin değişikliği beklenmedik sonuçlar doğurabilir. Bu yüzden “yetki vermek” yerine, yetki mimarisi tasarlamak yaklaşımıyla ilerlemek gerekir.
Bu makalede SharePoint’in izin modelini, gruplar üzerinden yönetim mantığını, kalıtım (inheritance) yapısını ve en az yetki prensibini gerçekçi senaryolarla ele alacağız. Amaç; yönetilebilir, ölçeklenebilir ve denetlenebilir bir erişim kurgusu oluşturmaktır.
SharePoint Yetki Modelinin Temeli: Nesneler, Kapsamlar ve Rol Atamaları
SharePoint’te yetkilendirme; kullanıcı, grup ve rol tanımlarının bir araya gelmesiyle oluşur. En önemli kavram, bir nesneye (site, liste, kitaplık, öğe) rol ataması yapılmasıdır. Bu rol ataması, bir kullanıcıya veya gruba belirli bir izin seviyesi (permission level) verir.
Yetkiler farklı kapsam seviyelerinde uygulanabilir. Genel olarak erişim kademesi aşağıdaki gibi düşünülebilir:
- Tenant / Microsoft 365 seviyesi (Entra ID, global ayarlar)
- Site Collection (modern SharePoint’te genellikle Site)
- Subsite (klasik yapılarda)
- Listeler ve kitaplıklar
- Klasörler
- Öğeler / dosyalar
En kritik pratik kural şudur: Yetki kırılımı (inheritance break) arttıkça yönetim maliyeti artar. Bu yüzden tasarımın ana hedefi, erişimi mümkün olduğunca gruplar üzerinden ve minimum kırılımla yönetmektir.
İzin Seviyeleri (Permission Levels) Neyi Belirler?
Permission level; kullanıcının bir nesne üzerinde hangi eylemleri yapabileceğini tanımlar. Örneğin “Read”, “Contribute”, “Edit”, “Full Control” gibi seviyeler varsayılan olarak gelir. Ancak kurumsal ortamlarda, özellikle hassas veri içeren alanlarda, özel izin seviyeleri tanımlamak gerekebilir.
SharePoint Grupları ile Azure AD Grupları Arasındaki Fark
SharePoint grupları, site bazlı yönetim için pratik olsa da kurumsal ölçek için her zaman yeterli değildir. Entra ID grupları (Azure AD), merkezi kullanıcı yönetimi, dinamik üyelik ve uyumluluk senaryolarında daha avantajlıdır.
Genel yaklaşım şu şekilde olmalıdır: Site içindeki erişim; mümkünse Entra ID grupları üzerinden atanmalı, SharePoint grupları ise daha çok site düzeyi operasyonel roller için kullanılmalıdır.

Kalıtım (Inheritance) Mantığı: Ne Zaman Kırılır, Ne Zaman Korunur?
SharePoint’in en güçlü ama en sık yanlış kullanılan özelliği, izin kalıtımıdır. Varsayılan olarak alt nesneler, üst nesnenin izinlerini devralır. Örneğin bir kitaplık, site izinlerini; bir dosya ise kitaplık izinlerini devralır.
Bu yapı doğru kullanıldığında yönetim çok kolaylaşır. Ancak kalıtım sık sık kırılırsa, sistem kısa sürede “kimde ne var?” sorusunun cevaplanamadığı bir hale gelir.
Yetki Kırılımı Yapılması Gereken Tipik Durumlar
Kalıtımı kırmak bazen kaçınılmazdır. Örneğin:
- İK, hukuk veya finans gibi hassas departman alanları
- Projelerde müşteri veya dış paydaş erişimi
- Aynı kitaplık içinde farklı gizlilik seviyelerine sahip klasörler
Bu senaryolarda kritik nokta; kırılımın kontrollü ve sınırlı tutulmasıdır. Kalıtım kırıldıktan sonra, yetkilerin “tek tek kullanıcı” yerine gruplar üzerinden verilmesi gerekir.
Kalıtımın Bozulduğu Yerlerde Denetlenebilirlik Nasıl Sağlanır?
Kalıtım kırılımlarını yönetilebilir kılmak için pratik bir yaklaşım; her kırılımın bir “iş gerekçesi” ile dokümante edilmesidir. Ayrıca periyodik gözden geçirme (access review) süreçleri ile bu kırılımlar düzenli kontrol edilmelidir.
En Az Yetki Prensibi: Güvenlikten Önce Operasyonel Sadelik
En az yetki prensibi (Least Privilege), kullanıcılara işlerini yapmaları için gereken minimum erişimi vermeyi hedefler. Bu yaklaşım çoğu zaman “güvenlik” başlığı altında konuşulsa da, asıl kazanım operasyonel sadeliktir.
Örneğin bir departman sitesinde herkesin “Edit” yetkisi olması, kısa vadede kolay gibi görünür. Ancak zaman içinde sayfa düzenlemeleri, içerik silmeleri ve yapısal bozulmalar nedeniyle site yönetimi zorlaşır. Bu yüzden en az yetki, sadece risk azaltmaz; aynı zamanda site kalitesini korur.
Tipik Rol Tasarımı: Okuyucu, Katkı Sağlayan, Sahip
Kurumsal SharePoint tasarımında genellikle üç temel rol yeterlidir:
- Okuyucu: İçeriği görüntüler, indirme yetkisi olabilir.
- Katkı Sağlayan: Dosya ekler, günceller; sayfa yapısını değiştirmez.
- Sahip: Site ayarlarını yönetir, izinleri düzenler.
Bu rollerin her biri için ayrı grup tanımlanmalı ve kullanıcılar bu gruplara dahil edilmelidir. Böylece kullanıcı değişiklikleri, tek tek izin düzenlemek yerine grup üyeliği üzerinden yönetilir.
“Herkese Tam Yetki” Alışkanlığının Kurumsal Bedeli
Yetkileri geniş tutmak, kısa vadede destek taleplerini azaltabilir. Ancak orta vadede; veri sızıntısı, yanlışlıkla silme, uyumluluk sorunları ve denetim bulguları gibi ciddi maliyetler doğurur. Bu yüzden “hız” için “kontrol” feda edilmemelidir.
Gruplar Üzerinden Yetkilendirme: Ölçeklenebilir Mimari Kurmak
SharePoint’te sürdürülebilir bir yetki mimarisi kurmanın en temel kuralı şudur: Kullanıcılara doğrudan yetki verme, gruplara yetki ver. Bu yaklaşım; personel değişimi, organizasyon dönüşümü ve proje bazlı erişim senaryolarında ciddi kolaylık sağlar.
Önerilen Grup İsimlendirme Standardı
Grup isimleri standart olmazsa, birkaç ay içinde yönetim kaosa dönüşür. Aşağıdaki gibi bir isimlendirme yaklaşımı, büyük kurumlarda iyi çalışır:
SP-[SiteKodu]-Owners
SP-[SiteKodu]-Contributors
SP-[SiteKodu]-Readers
SP-[SiteKodu]-External-GuestsBu standart, hem SharePoint hem Entra ID tarafında okunabilirliği artırır. Ayrıca denetim raporlarında hızlı analiz imkânı sağlar.
Dinamik Entra ID Grupları ile Otomatik Üyelik
Özellikle büyük organizasyonlarda, departman bazlı sitelerde kullanıcıları manuel gruplara eklemek sürdürülebilir değildir. Bu noktada dinamik Entra ID grupları devreye girer. Örneğin “Department = Finance” olan kullanıcıların otomatik olarak Finance site grubuna dahil edilmesi sağlanabilir.
// Example: Dynamic group rule idea (conceptual)
(user.department -eq "Finance") and (user.accountEnabled -eq true)Bu sayede kullanıcı transferlerinde, SharePoint erişimi otomatik güncellenir. Bu yaklaşım hem güvenlik hem de operasyon açısından çok değerlidir.

Paylaşım, Misafir Erişimi ve Dış Paydaş Senaryoları
SharePoint Online, dış kullanıcılarla paylaşımı kolaylaştırır. Ancak bu kolaylık, kontrol edilmezse kurumsal veri güvenliği için ciddi risk oluşturur. Bu yüzden misafir erişimi; tenant seviyesinde, site seviyesinde ve hatta kitaplık seviyesinde net kurallarla yönetilmelidir.
Misafir Kullanıcılar için Ayrı Yetki Alanı Tasarlamak
Dış paydaşlar için önerilen yaklaşım; onları ana departman alanlarına değil, ayrı bir proje sitesi veya ayrı bir kitaplık yapısına yönlendirmektir. Böylece hem erişim sınırları net olur hem de denetim kolaylaşır.
Ayrıca misafir kullanıcıların mümkün olduğunca Read veya sınırlı katkı yetkisi ile çalışması, içerik bütünlüğünü korur.
Link Paylaşımı mı, Grup Erişimi mi?
“Anyone with the link” gibi paylaşım türleri, hızlı ama riskli bir yaklaşımdır. Kurumsal senaryolarda daha doğru yöntem, misafir kullanıcıların belirli bir gruba eklenmesi ve erişimin bu grup üzerinden yönetilmesidir.
Denetim, Görünürlük ve Yetki Temizliği: Sürdürülebilirlik İçin Şart
Yetki mimarisi sadece kurmakla bitmez. Zaman içinde ekipler değişir, projeler kapanır, departmanlar dönüşür. Bu yüzden erişim yapısı düzenli olarak gözden geçirilmezse, eski kullanıcılar ve gereksiz izinler birikmeye başlar.
Access Review ve Periyodik Yetki Kontrolü
En iyi uygulama; kritik siteler için düzenli access review süreçleri tanımlamaktır. Örneğin her çeyrekte bir, site sahiplerinin grup üyeliklerini kontrol etmesi ve gerekirse temizlemesi sağlanabilir.
Bu süreçte hedef; “en az yetki” yaklaşımını sürekli canlı tutmaktır. Böylece bir kere doğru kurulan yapı, zaman içinde bozulmaz.
Denetim Kayıtları (Audit Logs) Neden Önemlidir?
Microsoft Purview ve Microsoft 365 denetim kayıtları; dosya erişimi, paylaşım, silme ve izin değişiklikleri gibi kritik olayları takip etmeyi sağlar. Özellikle regülasyon gerektiren sektörlerde, bu kayıtlar sadece teknik değil, hukuki bir gereklilik haline gelir.

Pratik Yetki Tasarım Rehberi: Hızlı ve Sağlam Bir Blueprint
SharePoint yetki mimarisini kurarken, aşağıdaki pratik adımlar işinizi kolaylaştırır:
- Site amaç ve veri sınıfını (genel, iç, hassas) netleştirme
- Rol setini (Readers, Contributors, Owners) standartlaştırma
- Kullanıcı yerine grup üzerinden erişim verme
- Kalıtımı minimum kırılımla yönetme
- Misafir erişimi için ayrı alan tasarlama
- Denetim ve periyodik erişim gözden geçirme süreçleri kurma
Bu yaklaşım, hem SharePoint yöneticileri hem de IT karar vericileri için sürdürülebilir bir model oluşturur. Ayrıca ekipler büyüdükçe “yetki yönetimi” ayrı bir problem olmaktan çıkar, normal bir operasyon haline gelir.
SharePoint Eğitiminde Bu Konu Neden Kritik?
Yetkilendirme, SharePoint’in en çok yanlış anlaşılan ve en çok sorun çıkaran alanıdır. Çünkü teknik bir konu gibi görünse de, doğrudan organizasyon yapısı ve iş süreçleriyle ilgilidir. Bu yüzden doğru öğrenilmesi, kurumsal SharePoint başarısının temel taşlarından biridir.
Bu alanda daha kapsamlı pratik yapmak ve kurumsal senaryolar üzerinden ilerlemek isterseniz: SharePoint Eğitimi sayfasına göz atabilirsiniz.
Sonuç: Yetki Vermek Değil, Yetki Mimarisi Tasarlamak
SharePoint’te başarılı bir yetkilendirme yaklaşımı; sadece izinleri doğru ayarlamak değil, organizasyonun çalışma biçimine uygun bir erişim modeli kurmaktır. Bu model, gruplar üzerinden yönetilmeli, kalıtım kontrollü kullanılmalı ve en az yetki prensibiyle desteklenmelidir.
Doğru tasarlanmış bir yetki mimarisi; veri güvenliğini artırır, uyumluluk süreçlerini kolaylaştırır ve ekiplerin SharePoint’i güvenle kullanmasını sağlar. En önemlisi de; yönetim yükünü azaltarak SharePoint’i sürdürülebilir hale getirir.


