Ana içeriğe geç
GOOGLE WORKSPACE

Google Workspace Kurulum, Lisans ve Kullanıcı Yönetimi

Alan adı, kullanıcı, organizasyon birimi, grup, lisans ve çalışan yaşam döngüsü için kontrollü Workspace kurulum rehberi.

İçerik güncellemesi:

Mimari ve çalışma modeli

Google Workspace, Gmail, Drive, Docs, Calendar, Meet ve yönetim işlevlerini kurumsal kimlik etrafında toplar. Google Cloud altyapı hesabı ile Workspace aboneliği aynı hizmet değildir. Bir Gmail hesabının bulunması kurumsal domain yönetimi ve gerekli lisans hakkının bulunduğunu göstermez. Önce domain sahipliği, mevcut hesaplar ve kimlik kaynağı belirlenir.

Organizasyon birimi politika uygulamak için, grup ise iletişim veya erişim kapsamı için kullanılabilir. Bunları şirketin departman çiziminin birebir kopyası yapmak zorunlu değildir. Pilot, yönetici, saha cihazı ve farklı güvenlik gereksinimleri için yapı tasarlanır. Bir kullanıcının taşınması veya grup üyeliğinin değişmesi erişim ve servis davranışını etkileyebilir; etkili ayarı doğrulayın.

Lisans seçimi posta ve depolama dışında paylaşım, endpoint yönetimi, Vault, erişim politikası ve toplantı ihtiyaçlarını kapsar. Özellik ve bölgesel teklif kapsamı değişebilir. Fiyatı para birimi, vergi, taahhüt ve kanal koşullarıyla güncel kaynaktan doğrulayın. Bir paket adı üzerinden tüm güvenlik özelliklerinin dahil olduğunu varsaymayın.

Yeni çalışan, görev değişimi ve ayrılış işlemleri aynı akışın parçalarıdır. Hesabı askıya almak, lisansı kaldırmak ve hesabı silmek farklı işlemlerdir. My Drive sahipliği, shared drive erişimi, posta devri, hukuki tutma ve uygulama tokenları değerlendirilmeden silme yapılmaz. Yönetici rolü günlük kullanıcı hesabından ayrılır; alternatif yetkili kurtarma erişimi planlanır.

  1. 1Domain ve envanter
  2. 2Rol ve lisans matrisi
  3. 3Pilot politikalar
  4. 4Yaşam döngüsü kabulü
Kurulumu kullanıcı, yönetici ve ayrılış senaryolarıyla doğrulayın.

Tasarım parametreleri

Domain ve kimlik
Mevcut domain, alias, grup adresi ve çakışan kişisel hesapları envantere alın.
Politika hiyerarşisi
OU, grup ve istisna sonucunu gerçek kullanıcı üzerinden doğrulayın.
Lisans matrisi
Rol başına gerekli özellik ve güncel kullanım hakkını eşleştirin.
Ayrılış sırası
Veri devri, saklama, erişim iptali ve silme kararını ayrı kaydedin.

Hesap ve uygulama örneği

Örnek 60 ofis çalışanı ve 20 saha kullanıcısı için önce iki rolün uygulama, cihaz ve veri ihtiyacını yazın. Beş temsilci kullanıcıyla domain ve servis kurulumunu pilotta doğrulayın. Bir yönetici, bir mobil cihaz ve bir dış paylaşım senaryosunu da dahil edin; yalnız posta göndermek kurulum kabulü değildir.

Bir pilot kullanıcının görevini değiştirip grup ve OU sonucunu ölçün. Ayrılış tatbikatında erişimi kapatın, gerekli dosya sahipliğini devredin ve saklama kararını doğrulayın. Kullanıcı silmeden önce başka yetkili kişinin iş verisine erişebildiğini test edin. Gereksiz lisansı kaldırmak veri koruma prosedürünün yerine geçmez.

Hata teşhisi

BelirtiOlası neden / ayrımDoğrulama
Lisans atandı, servis açılamıyorOU servis ayarı veya feature kapsamı farklı olabilir.Kullanıcının etkili servis ayarı ve lisans hakkını karşılaştırın.
Gruba eklenen kullanıcı dosyayı açamıyorGrup erişimi dosya veya shared drivea uygulanmamış olabilir.Gerçek kullanıcı, grup üyeliği ve kaynak izinlerini birlikte inceleyin.
Ayrılan kullanıcıyla veri kaybolduSilme veri devri ve saklama değerlendirmesinden önce yapılmış olabilir.Hesap işlem kaydı, sahiplik ve desteklenen kurtarma kapsamını doğrulayın.

Kabul ve doğrulama kontrolleri

  1. Kurulumu kullanıcı, yönetici ve ayrılış senaryolarıyla doğrulayın.
  2. Domain sahipliği ve DNS değişiklik yetkisini doğrulayın.
  3. OU/grup politikasını temsilî kimliklerle test edin.
  4. Gerekli özellikleri güncel lisans matrisiyle eşleştirin.
  5. Veri sahipliği devrini hesap silmeden sınayın.
  6. Yönetici kurtarma yolunu ve audit kaydını doğrulayın.

İlgili kavramlar

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.

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.

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.

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.

Bağımlılık ve geri açılış sırası

Bir hizmet çoğu zaman kimlik, DNS, zaman, ağ, veritabanı ve lisans servislerine bağlıdır. Bağımlılıkları yalnız cihaz listesi olarak değil, hangi hizmetin hangi koşulla çalışabildiğini gösteren bir grafik olarak kaydedin. Geri açılış sırası buna göre belirlenir; bazı döngüsel bağımlılıklar özel acil erişim gerektirir. Çalışan altyapı bileşenleri ile işin yeniden başlayabildiği anı ayırın. Her bağımlılığa sorumlu, doğrulama yöntemi ve alternatif erişim yolu atayın. Uçtan uca testte bir bileşeni bilerek erişilemez hale getirerek varsayımları sınayı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ı!