Ana içeriğe geç
GOOGLE WORKSPACE

Google Drive ve Shared Drives: Sahiplik, Paylaşım ve Yetki Tasarımı

My Drive ve shared drive ayrımı; ekip sahipliği, dış paylaşım, grup erişimi, senkronizasyon ve çalışan ayrılışı kontrolleri.

İçerik güncellemesi:

Mimari ve çalışma modeli

My Drive kişisel çalışma alanı, shared drive ise ekip verisinin kurumsal sahipliği için farklı modeller sunar. Shared drive içeriği bireysel kullanıcı yerine organizasyon sahipliğiyle yönetilir. Bir çalışanın ayrılması ekip dosyalarının onun kişisel hesabına bağlı kalmaması için tasarım girdisidir. Ortak klasör ile shared drive aynı sahiplik modeli değildir.

Yetki tasarımı drive üyeliği, grup, dosya/klasör paylaşımı, dış erişim ve link kapsamını birlikte inceler. Üst kapsamdan gelen izin veya doğrudan paylaşım kullanıcı çıkarıldıktan sonra farklı bir erişim yolu bırakabilir. İşlevsel rolü iş akışına göre seçin; herkesin içerik yönetebilmesi veya drive yönetmesi gerekmez. Ürün sürümü ve desteklenen sınırlı erişim davranışını güncel dokümandan doğrulayın.

Drive for desktop ve offline kopya ayrı veri yollarıdır. Bulut erişimini iptal etmek cihazdaki indirilmiş dosyayı her koşulda geri almaz. Stream/mirror veya desteklenen istemci davranışı depolama, kayıp cihaz ve veri sınıflandırmasıyla değerlendirilir. Senkronizasyon yanlış silmeyi de yayabilir; bağımsız backup ve retention ihtiyacı ayrıca belirlenir.

Dosya taşımada içerik yanında bağlantı, sahiplik, izin ve uygulama referansı etkilenebilir. Çok sayıda dosyayı bir anda taşımak yerine örnek klasör ve gerçek kullanıcıyla pilot yapın. Etkili erişim testi yetkili ve yetkisiz kullanıcıyı, dış paylaşımı ve yeniden giriş sonrası davranışı kapsamalıdır.

  1. 1Veri ve sahiplik
  2. 2Drive / grup rolleri
  3. 3Paylaşım ve istemci
  4. 4Erişim ve ayrılış testi
Yetki iptalini tüm grant yolları ve yerel kopyayla birlikte test edin.

Tasarım parametreleri

Sahiplik ve veri türü
Kişisel taslak, ekip verisi ve dış kaynağın sahibi için ayrı kurallar tanımlayın.
Grant ve link yolu
Üyelik, grup, doğrudan paylaşım ve link erişimini tek matrise yazın.
İstemci kalıcılığı
Offline/indirilen kopya ve cachei bulut izninden ayrı kontrol edin.
Taşıma kabulü
Dosya, link, sahiplik ve uygulama referansını pilotta karşılaştırın.

Hesap ve uygulama örneği

Satış ekibinin 2.000 dosyası ayrılacak çalışanın My Driveında olsun. Önce sahiplik ve dış paylaşım envanterini çıkarın; beş temsilî dosyayı shared drivea taşıyıp ekip grubu ile erişimi doğrulayın. Eski linkleri, uygulama referanslarını ve dosya açılışını kontrol edin. Sonra kapsamı kontrollü genişletin.

Pilot kullanıcıyı gruptan ve drive üyeliğinden çıkarın. Yeni oturumda erişimi sınayın; açık doğrudan paylaşım varsa ayrıca kaldırın. Test cihazında indirilen kopyanın durumunu kaydedin. Buluttaki 403 sonucu cihazda veri kalmadığını kanıtlamaz.

Hata teşhisi

BelirtiOlası neden / ayrımDoğrulama
Gruptan çıktı ama dosyayı açıyorDoğrudan paylaşım, başka grup veya offline kopya olabilir.Etkili erişim yollarını ve yeni oturum/yerel kopyayı ayrı inceleyin.
Dosya taşındı, iş akışı bozulduLink, rol veya uygulama referansı değişmiş olabilir.Örnek dosyanın önce/sonra link ve uygulama açılışını karşılaştırın.
Çalışan ayrıldı, ekip verisi erişilemiyorVeri kişisel sahiplikte kalmış olabilir.Sahiplik, hesap durumu ve devir prosedürünü inceleyin.

Kabul ve doğrulama kontrolleri

  1. Yetki iptalini tüm grant yolları ve yerel kopyayla birlikte test edin.
  2. Ekip verisinin kurumsal sahipliğini doğrulayın.
  3. Sınırlı rol ve yetkisiz kullanıcıyla erişim test edin.
  4. Dış paylaşım ve link kapsamını denetleyin.
  5. Taşıma sonrasında uygulama referansını doğrulayın.
  6. Ayrılışta veri devri ve izin temizliğini tatbik edin.

İ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 ACLleri 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 ayrıcalık ve görev ayrımı

En az ayrıcalık, 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.

Saklama politikası ve kapasite

Retention, hangi kurtarma noktalarının ne kadar süre tutulacağını tanımlar. Günlük, haftalık ve aylık noktalar aynı veri değişim oranını temsil etmez; tam kopya üretme şekli ve zincir bağımlılığı fiziksel kapasiteyi değiştirir. Saklama kararı, iş gereksinimi ve geçerli yükümlülükler ile teknik kapasitenin birlikte değerlendirilmesini gerektirir. Daha uzun saklama, otomatik olarak daha iyi kurtarma anlamına gelmez: doğru noktanın bulunması ve okunabilmesi gerekir. Politika değiştirildiğinde mevcut noktaların hemen silinip silinmediğini ürün davranışı üzerinden sınayın.

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.

Uygulama tutarlılığı

Bir kopyanın açılabilir olması, uygulama verisinin tutarlı olduğunu kanıtlamaz. İşletim sistemi önbelleği, veritabanı günlükleri ve birden fazla disk veya servis arasındaki işlem sırası sonucu etkiler. Crash-consistent kopya beklenmedik kapanma sonrasındaki duruma benzer; application-consistent kopya uygulamanın desteklediği hazırlık ve yazma düzenini dikkate alır. Geri dönüşte yalnız dosya sayısını değil, işlem bütünlüğünü, kayıt ilişkilerini ve uygulama testini kontrol edin. Yedek ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayın.

Birincil teknik dokümantasyon

Hazırlama yöntemi

Doz Teknoloji Teknik Ekibi tarafından hazırlanan bu rehberde üreticilerin resmi dokümanları temel alınır. Örnek senaryolar ve hesaplar yöntemi açıklamak içindir; tamamlanmış müşteri testleri değildir. Uygulamadan önce sürüm, lisans, istemci desteği, güvenlik koşulları ve geri dönüş planını kendi ortamınızda doğrulayın. Seçim mevcut ürünlerinize ve iş yükünüze göre yapılır.

Kurumsal IT Ürün Satışı, Lisanslama ve Kurulum
Kurumsal IT Proje & Çözüm Senaryoları
Tüm ilgili içerikleri görüntüleyin
WhatsApp'tan Yazın
Kopyalandı!