Mimari ve çalışma modeli
Dış paylaşım yönetişimi tek bir aç/kapat ayarı değildir. Kuruluş varsayılanı, organizasyon birimi veya grup, site/shared drive, klasör/dosya, bağlantı türü ve misafir kimliği aynı kararı farklı düzeylerde daraltabilir. Etkin erişim bu katmanların en kısıtlayıcı sonucu ve mevcut paylaşım nesneleri birlikte incelenerek anlaşılır.
Google Workspace’te Drive paylaşım ayarları, allowlist ve Trust Rules; Microsoft 365’te tenant, SharePoint/OneDrive site ayarı, bağlantı türü ve Entra B2B misafir politikaları birlikte çalışır. İki platformdaki benzer görünen adlar aynı varsayılanı veya lisans kapsamını garanti etmez.
Güvenli model; veri sınıfına göre paylaşım bölgeleri, doğrulanmış misafir kimliği, süre sonu, yeniden doğrulama, indirme kısıtı ve audit incelemesini tanımlar. Hassas içerik dış paylaşıma kapalı ayrı site/shared drive’da tutulabilir; proje alanlarında alan adı allowlist’i ve süreli erişim uygulanabilir.
- 1Veri sınıfı ve iş gerekçesi
- 2Misafir kimliği ve alan politikası
- 3Süreli paylaşım ve erişim
- 4Audit, yeniden doğrulama ve kaldırma
Tasarım parametreleri
- Veri sınıfı
- Genel, iç, gizli ve düzenlemeye tabi içerik için farklı paylaşım sınırları tanımlayın.
- Bağlantı türü
- Anonim bağlantı, yeni/doğrulanmış misafir ve yalnız mevcut misafir seçeneklerinin riskini ayırın.
- Yaşam döngüsü
- Sponsor, bitiş tarihi, periyodik yeniden doğrulama ve işten ayrılma temizliği zorunlu alanlar olmalıdır.
- Audit kapsamı
- Paylaşma, erişim, indirme ve politika değişikliği olaylarının saklama ve inceleme süresini belirleyin.
Platformlardaki yönetim katmanları
Servis adları teknik karşılıklardır. Kapsam, varsayılanlar, bölge kullanılabilirliği ve işletim koşulları farklıdır; birebir aynı garanti anlamına gelmez.
| Kontrol alanı | Google Workspace | Microsoft 365 |
|---|---|---|
| Kuruluş kapsamı | Admin Console Drive sharing settings | SharePoint/OneDrive organization sharing level |
| Dar kapsam | OU/group, trust rules, shared-drive restrictions | Site sharing level, sensitivity/Entra guest controls |
| Güvenilen taraf | Allowlisted domains ve trust-rule koşulları | Entra B2B allow/block ve cross-tenant settings |
| İzleme | Drive log events ve investigation araçları | Purview audit, SharePoint/Entra audit olayları |
Hesap ve uygulama örneği
120 günlük tedarikçi projesinde yalnız project.example alan adı, 14 günlük bağlantı süresi ve aylık sponsor incelemesi uygulanabilir. Anonim bağlantı kapatılır; paylaşım proje alanıyla sınırlandırılır. Proje sonunda misafir üyelikleri ve dosya düzeyi istisnalar rapordan temizlenir.
5.000 çalışanlı yapıda dış paylaşım olaylarının yalnız toplam sayısını izlemek yeterli değildir. Yeni dış alan adı, anonim bağlantı, gizli etiketli dosya ve başarısız erişim ayrı sorgulanır; başlangıçta 30 günlük baseline ile sahiplik ve yanlış pozitifler belirlenir.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
# Microsoft 365: kuruluş ve seçili site paylaşım durumunu okuyun
Connect-SPOService -Url https://contoso-admin.sharepoint.com
Get-SPOTenant | Select-Object SharingCapability,RequireAnonymousLinksExpireInDays
Get-SPOSite -Identity https://contoso.sharepoint.com/sites/project | Select-Object Url,SharingCapability
# Google Workspace için Admin Console > Reporting > Audit and investigation > Drive log events
# bölümünde hedef kullanıcı, dış alan adı ve visibility değişikliklerini filtreleyin.Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Kullanıcı paylaşamıyor | Kuruluş, OU/site veya trust/guest politikalarından biri daha kısıtlayıcı olabilir. | Etkin kullanıcı grubu, içerik konumu, hedef alan ve bağlantı türünü aynı olay üzerinden inceleyin. |
| Paylaşım kapatıldı ama eski erişim sürüyor | Dosya üyesi, grup üyeliği veya misafir hesabı ayrı erişim yolu bırakmış olabilir. | Link, doğrudan izin, grup ve misafir nesnesini ayrı listeleyin. |
| Dış kullanıcı giriş döngüsünde | Yanlış hesap, davet eşleşmesi veya cross-tenant koşulu söz konusu olabilir. | Davet edilen adres, tenant kimliği ve sign-in log correlation ID’sini doğrulayın. |
Kabul ve doğrulama kontrolleri
- Veri sınıfları için izin verilen paylaşım modellerini yazılı hale getirin.
- Anonim bağlantının varsayılan olmadığını pilot alanlarda doğrulayın.
- Allowlist dışı alan adı ve kişisel hesapla negatif test yapın.
- Misafir sponsor ve bitiş tarihi kayıtlarını örnekleyin.
- Paylaşım ve erişim olaylarının audit kaydında göründüğünü doğrulayın.
- Proje kapanışında link, doğrudan izin, grup ve misafir hesabını birlikte kaldırın.
İlgili kavramlar
Dosya izinleri ve servis kimliği
Dosya erişimi kullanıcı/grup, izin bitleri, ACL ve güvenlik politikalarının birleşimine bağlıdır. Bir uygulamanın root olarak çalışması izin sorununu gizleyebilir; üretim için gerekçeli ve sınırlı servis kimliği tercih edilir. Dizin üzerinde arama/geçiş izni ile dosya okuma izni farklıdır. Paylaşım katmanında verilen izin, dosya sistemindeki kısıtı her zaman aşmaz. Hata araştırmasında uygulamanın gerçekten hangi kullanıcıyla çalıştığını, dizin zincirini ve ACL’leri inceleyin. İzinleri topluca açmak yerine gereken erişimi dar kapsamda test edin.
Kimlik doğrulama ve oturum
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
En az yetki ve görev ayrımı
En az yetki, bir görevin gerektirdiği izinlerin belirli kaynak ve süreyle sınırlandırılmasıdır. Herkese aynı yönetici rolünü vermek, erişim incelemesini ve olay araştırmasını zorlaştırır. Günlük kullanıcı hesabı ile ayrıcalıklı hesabı ayırın; servis hesaplarının etkileşimli kullanımını ve gereksiz ağ erişimini kısıtlayın. Yetki matrisi, kimliğin kaynağa hangi işlemle eriştiğini göstermelidir. Bir izin kaldırıldığında uygulamanın çalışmayı sürdürmesi de test kapsamına girer: gereksiz yetkiler bazen yalnız kontrollü azaltma sırasında ortaya çıkar.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
Politikanın yaşam döngüsü
Bir politika yalnız etkinleştirildiği anda değil, kapsamı değiştikçe de yönetilmelidir. Taslak, gözlem, pilot, uygulama ve periyodik inceleme aşamalarını ayırın. Her istisnanın sahibi, gerekçesi, kapsamı ve sona erme tarihi olmalıdır. Test verileri gerçek kullanıcı davranışını temsil etmezse başarılı pilot üretimde yanlış engellemelere dönüşebilir. Önce kimin ve hangi uygulamanın etkilenebileceğini belirleyin; sonra ölçülebilir kabul koşullarıyla devreye alın. Geri alma yolu yalnız düğme konumunu değil, değişikliğin kim tarafından ve hangi koşulda geri alınacağını da tanımlamalıdır.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.