SharePoint İzin Modeli: Site, Kütüphane ve Öğe Düzeyinde Yetki

SharePoint’te izin karmaşası tek bir büyük hatadan doğmaz. Yıllar içinde biriken küçük istisnalardan doğar: bir klasöre “geçici” verilen erişim, bir dosyanın paylaşım bağlantısı, ayrılan bir çalışanın unutulmuş doğrudan izni. Bir gün denetçi “bu klasörü kim görebiliyor?” diye sorar ve kimse yanıt veremez. Aşağıda intranet ve doküman alanlarında sürdürülebilir bir izin yapısını; devralmayı, grup türlerini, paylaşım bağlantılarının etkisini, izin şablonlarını ve raporlama yöntemini uygulama tasarımcısı gözüyle anlatıyoruz.

İzin devralma ve kırılan izinler

SharePoint’te izin yukarıdan aşağıya devralınır: site → liste veya kütüphane → klasör → öğe. Varsayılan durumda kütüphanedeki tüm dosyalar sitenin izinlerini taşır. Herhangi bir düzeyde “izin devralmayı durdur” dendiğinde o nesne için özel izin kapsamı (unique permissions) oluşur; o anki izinler kopyalanır ve bağımsızlaşır. Bundan sonra üst düzeydeki değişiklik bu nesneye ulaşmaz.

Kırılan devralmanın iki bedeli vardır. Birincisi görünürlük: site izinleri sayfası alt nesnelerdeki istisnaları göstermez; “bu dosyayı kim görebilir?” sorusu nesne nesne incelenmeden yanıtlanamaz. İkincisi ölçek: Microsoft bir liste veya kütüphanede özel izinli öğe sayısı için 50.000’lik desteklenen sınır belirtir, genel kullanım için 5.000’i önerilen sınır olarak verir. Bu sınırlara yaklaşan kütüphanede izin işlemleri yavaşlar, yönetim pratikte durur.

Tasarım ilkesi basit: izni olabilecek en yüksek düzeyde, olabilecek en az istisnayla verin. Farklı erişim gerektiren içerikte öncelik sırası ayrı site, sonra ayrı kütüphane, en son klasördür. Öğe düzeyi izin istisna kalır.

Microsoft 365 grubu, SharePoint grubu ve doğrudan izin

Siteye erişim farklı yollardan verilebilir ve her birinin yönetim yeri ayrıdır. Yanlış yerden yönetilen üyelik, iki ayrı liste ve sürekli tutarsızlık demektir:

Yöntem	Nerede yönetilir	Uygun kullanım
Microsoft 365 grubu	Teams, Outlook, Entra ID	Teams’e bağlı ekip siteleri; üyelik ekip ile aynı
SharePoint grubu	Sitenin izin ayarları	İletişim siteleri, onaycılar gibi siteye özgü roller
Güvenlik grubu (Entra ID)	Entra ID veya şirket içi AD	Departman, lokasyon gibi kurumsal kitleler
Doğrudan kullanıcı izni	Nesne üzerinde	Kaçınılmalı; istisna olarak ve belgelenerek

Microsoft 365 grubuna bağlı ekip sitesinde grup sahipleri sitenin Sahipler grubuna, grup üyeleri Üyeler grubuna eşlenir. Bu yüzden Teams’e bağlı sitede üyelik değişikliği Teams’ten veya gruptan yapılır. Sahada en sık gördüğümüz hata, kullanıcıyı doğrudan SharePoint Üyeler grubuna eklemektir: kullanıcı dosyaları görür ama ekip kanalına giremez ve yardım masasına “Teams’te ekibi göremiyorum” diye döner. İletişim sitelerinde Microsoft 365 grubu yoktur; Sahipler, Üyeler ve Ziyaretçiler SharePoint gruplarıdır ve geniş kitleye okuma erişimi genellikle Ziyaretçiler grubuna bir güvenlik grubu eklenerek verilir.

İzin düzeyinde Düzenle ile Katkıda Bulun arasındaki farkı atlamayın: Düzenle liste ve kütüphane ekleyip silmeye izin verir; Katkıda Bulun yalnız mevcut liste ve kütüphanelerde öğe ekleme, düzenleme ve silme yetkisi verir. Kütüphaneyi yanlışlıkla silen kullanıcı genellikle Düzenle yetkisiyle gelir. Doküman yönetimi alanlarında geniş üye kitlesi için Katkıda Bulun çoğu zaman daha güvenli seçimdir.

Site, kütüphane, klasör ve öğe düzeyi

Her düzeyin yönetim maliyeti ve doğru senaryosu farklıdır:

• Site düzeyi: Departman veya proje sınırı. İzin sınırını burada çizmek en görünür ve en kolay denetlenen modeldir. Hub ilişkisi izinleri değiştirmez; site topolojisi için hub site mimarisi rehberine bakın.
• Kütüphane düzeyi: Aynı site içinde farklı kitle; örneğin İK sitesinde herkesin okuduğu “Politikalar” ile yalnız İK ekibinin eriştiği “Personel Dosyaları”.
• Klasör düzeyi: Kütüphane ayrımının pratik olmadığı küçük istisnalar. Klasör adında “GİZLİ” yazması denetim değildir. İzinlerin gerçekten kırıldığını kontrol edin.
• Öğe düzeyi: Kişiye özel kayıtlar gibi zorunlu durumlar. Liste tabanlı uygulamada satır düzeyi erişim gerekiyorsa öğe izinleri yerine Dataverse’in güvenlik modelini değerlendirin; ayrıntısı Dataverse ile SharePoint listesi karşılaştırmasında.

Öğe düzeyi izni Power Automate ile otomatik kırmak (her talep kaydını yalnız talep sahibine açmak gibi) teknik olarak mümkündür. Ama her kayıt yeni bir özel izin kapsamı demektir. Yılda binlerce kayıt üreten bir süreçte bu yaklaşım birkaç yılda önerilen sınıra dayanır. Geri dönüşü de zahmetlidir.

Paylaşım bağlantılarının izinlere etkisi

Kullanıcı bir dosyayı “Paylaş” ile paylaştığında arka planda o öğe için ek bir erişim kapsamı oluşur. SharePoint bağlantı türüne göre gizli “SharingLinks” grupları açar ve dosyaya giden yoldaki üst nesnelere Sınırlı Erişim (Limited Access) verir. Paylaşılan öğede devralma da kırılır; yani her paylaşım, yukarıda anlattığımız özel izin kapsamı sayısına eklenir. Site izinleri sayfası “yalnız üç grup var” gösterirken kütüphanede yüzlerce paylaşılmış dosya durabilir. Görünen resim eksiktir.

Bağlantı türü	Kim erişir	Tasarım notu
Herkes (anonim)	Bağlantıya sahip herkes	Kurumsal doküman alanlarında kapatılması önerilir
Kuruluştaki kişiler	Bağlantıya sahip tüm iç kullanıcılar	Yönlendirilen bağlantı kapsamı genişletir
Belirli kişiler	Seçilen kişiler	Kontrollü; varsayılan olarak tercih edilir
Mevcut erişimi olanlar	Zaten yetkili olanlar	Yeni izin vermez; yalnız bağlantı üretir

Uygulama tasarımında iki ayar belirleyicidir: varsayılan bağlantı türü (kiracı ve site düzeyinde “Belirli kişiler” yapılabilir) ve hassas sitelerde paylaşımın yalnız site sahiplerine bırakılması. Site ayarlarındaki “Paylaşım ayarları” bölümünden üyelerin dosya ve klasör paylaşıp paylaşamayacağı belirlenir. Dış paylaşım ve misafir erişiminin güvenlik tarafı için SharePoint ve OneDrive dış paylaşım güvenliği rehberi ayrıntılı ayarları içerir.

Önerilen izin şablonları

Kurumsal Microsoft 365 ortamında her sitenin izin yapısını sıfırdan tasarlamak tutarsızlık üretir. Site türüne göre şablon kullanın. Aşağıdakiler başlangıç önerisidir; kurumun bilgi sınıflandırmasına göre uyarlanmalıdır:

Site türü	Sahipler	Düzenleme	Okuma
Kurumsal iletişim sitesi	2–3 intranet editörü	İçerik yazarları grubu	Tüm çalışanlar güvenlik grubu
Departman sitesi	Departman yöneticisi + yedek	Departman güvenlik grubu	İlgili diğer departmanlar veya tüm çalışanlar
Teams ekip sitesi	M365 grup sahipleri	M365 grup üyeleri	Gerekirse ziyaretçi grubu
Kontrollü doküman sitesi	Doküman kontrol sorumlusu	Yazarlar; ayrı onaycı grubu	Tüm çalışanlar, yalnız onaylı sürüm
Gizli proje sitesi	Proje yöneticisi + BT yedek	Proje ekibi	Yok; paylaşım yalnız sahiplerde

Şablonların ortak kuralları: her sitede en az iki sahip; tek sahipli site, o kişi izne çıktığında sahipsiz kalır. Sahipler grubunda mümkünse adlandırılmış rol sahipleri; okuma erişimi tek tek kullanıcılara değil gruplara; doğrudan kullanıcı izni yalnız belgelenmiş istisna olarak. Kontrollü doküman sitesindeki onaycı grubu ve taslak görünürlüğü kurgusu doküman revizyon yönetimi rehberinde anlatılıyor.

İzinleri raporlama ve periyodik gözden geçirme

İzin yapısı kurulduğu gün doğrudur. Sorun altı ay sonra başlar. Periyodik gözden geçirmede kullandığımız araçlar:

• İzinleri denetle: Site izinleri sayfasındaki “İzinleri Denetle”, bir kullanıcının veya grubun o nesnede hangi yetkiye sahip olduğunu ve yetkinin nereden geldiğini gösterir. Kullanıcı “neden görüyorum/göremiyorum” dediğinde ilk bakılacak yer burasıdır.
• Erişimi yönet paneli: Dosya veya klasör düzeyinde verilen bağlantıları ve doğrudan erişimleri listeler.
• PowerShell envanteri: Kütüphanedeki özel izinli öğeleri listelemek için PnP PowerShell kullanılır.

Connect-PnPOnline -Url https://contoso.sharepoint.com/sites/ik -Interactive `
  -ClientId <uygulama-kaydi-client-id>

$items = Get-PnPListItem -List "Dokümanlar" -PageSize 2000
$sonuc = foreach ($item in $items) {
    $ozelIzin = Get-PnPProperty -ClientObject $item -Property HasUniqueRoleAssignments
    if ($ozelIzin) {
        [pscustomobject]@{ Id = $item.Id; Yol = $item.FieldValues["FileRef"] }
    }
}
$sonuc | Export-Csv .\ozel-izinler.csv -NoTypeInformation -Encoding UTF8

Betik her öğe için ayrı sorgu attığından büyük kütüphanede uzun sürer; mesai dışında ve kütüphane bazında çalıştırın. -ClientId, PnP PowerShell için kiracınızda açtığınız Entra ID uygulama kaydıdır. SharePoint Advanced Management lisansı olan kiracılarda veri erişim yönetişimi (data access governance) raporları ve site erişim incelemeleri aynı işi kiracı genelinde yapar; kapsamını Microsoft’un güncel dokümantasyonundan doğrulayın. Çıktıdaki her satır için tek soru sorulur: “bu istisna hâlâ gerekli mi?” Gereksizse devralmayı geri yükleyin (Delete unique permissions). Bu işlem o nesneye verilmiş paylaşım bağlantılarını da kaldırır. Kullanıcıyı önceden bilgilendirin.

Gözden geçirme sıklığını içerik hassasiyeti belirler; örneğin gizli proje ve İK sitelerinde üç ayda bir, genel departman sitelerinde altı ayda bir sahip onayı alınabilir. Bu süreç site sahiplerine “sitenizin sahip ve üye listesini doğrulayın” görevi olarak atanırsa BT ekibinin yükü düşer. Microsoft’un modern deneyimde paylaşım ve izinler dokümantasyonu grup eşlemelerinin resmi açıklamasını içerir. Intranet genelinde izin şablonlarının uygulanması SharePoint intranet ve personel portalı çalışmalarının ilk adımlarından biridir.

Sık sorulan sorular

Teams’e bağlı bir sitede kullanıcıyı SharePoint grubuna eklemek yeterli mi?

Hayır. Kullanıcı yalnız site içeriğine erişir; ekip kanallarına ve sohbetlere erişemez. Teams’e bağlı sitelerde üyeliği Microsoft 365 grubu veya Teams üzerinden yönetin.

Klasöre özel izin vermek mi ayrı kütüphane açmak mı daha iyi?

Farklı erişim gerektiren içerik kalıcı ve büyükse ayrı kütüphane daha görünür ve denetlenebilirdir. Klasör düzeyinde kırılan izin küçük ve geçici istisnalar için uygundur.

Paylaşım bağlantıları site izinleri sayfasında görünür mü?

Doğrudan görünmez. Bağlantılar dosya düzeyinde gizli SharingLinks grupları ve üst nesnelerde Sınırlı Erişim olarak oluşur. Dosyanın erişimi yönet paneli veya PowerShell envanteriyle incelenir.

Öğe düzeyi izin için pratik bir sınır var mı?

Microsoft bir liste veya kütüphanede özel izinli öğe için 50.000 desteklenen sınır ve 5.000 önerilen genel sınır belirtir. Satır düzeyi erişim gerektiren uygulamalarda Dataverse güvenlik modelini değerlendirin.