Ana içeriğe geç
GOOGLE WORKSPACE

Google Workspace Güvenliği: MFA, Cihaz, OAuth ve Audit

2-Step Verification, passkey, cihaz koşulları, uygulama izinleri ve olay kayıtları için katmanlı güvenlik rehberi.

İçerik güncellemesi:

Mimari ve çalışma modeli

Workspace güvenliği parola ve MFA ile sınırlı değildir. Kayıt, hesap kurtarma, yönetici yetkisi, cihaz, uygulama onayı ve paylaşım yolları birlikte kontrol edilir. Passkey ve güvenlik anahtarı gibi yöntemler girişin saldırı dayanımını güçlendirebilir; kayıp cihaz ve zayıf kurtarma süreci yine değerlendirilir. Kullanıcının faktör eklemesi ve değiştirmesi de olay kaydına bağlanır.

Context-Aware Access kimlik, konum veya cihaz durumu gibi sinyallerle erişim koşulları kurmaya yardım eder. Lisans, uygulama, istemci ve platform desteği değişebilir. Yalnız web tarayıcısındaki başarılı test mobil veya API yolunu doğrulamaz. Politika kapsamını, istisnayı ve ana kimlik sağlayıcısı kesintisindeki kurtarmayı pilotta sınayın.

OAuth uygulaması kullanıcının onayıyla veriye erişebilir. Güvenilir uygulama etiketi tüm yetkilerin gerekli olduğunu kanıtlamaz. İstenen scope, publisher, veri kullanımı ve iş gerekçesi incelenir. Kullanıcı erişimini kapatırken app tokenı, servis kimliği ve mevcut oturum ayrı değerlendirilir. Geniş domain-wide delegation, tek kullanıcı erişiminden daha büyük etki alanı yaratabilir.

Audit planı hangi olayın hangi üründe ve ne kadar süre aranabildiğini tanımlar. Giriş, yöneticinin politika değişikliği, dosya paylaşımı ve uygulama erişimi farklı kayıt kaynaklarıdır. Başarılı giriş sayısı güvenlik kanıtı değildir; yetkisiz işlemin reddi ve müdahale zinciri de test edilir.

  1. 1Kimlik ve faktör
  2. 2Cihaz ve erişim koşulu
  3. 3Uygulama scopeu
  4. 4Audit ve müdahale
İnsan, cihaz ve OAuth erişimini aynı güvenlik tasarımında doğrulayın.

Tasarım parametreleri

Faktör ve kurtarma
Güçlü giriş yöntemi ile bağımsız yetkili hesap kurtarmayı birlikte tasarlayın.
Cihaz ve istemci
Tarayıcı, mobil, desktop ve API yollarını ayrı test edin.
OAuth kapsamı
Uygulama iznini gereken veri/eylemle sınırlandırın; delegationı ayrıca inceleyin.
Kayıt ve müdahale
Olay kimliği, kaynak, kullanıcı, eylem ve zamanı ilişkilendirin.

Hesap ve uygulama örneği

10 pilot kullanıcıda yönetilen laptop, kişisel telefon ve desteklenen API uygulamasını test edin. Normal giriş, kayıp faktör ve cihaz uyumsuzluğu senaryolarını ayrı kaydedin. Erişim kararı için uygulanan politikanın gerekçesini bulun; başarısızlığı yalnız parola hatası sanmayın.

Bir test OAuth uygulaması yalnız seçili iş ihtiyacını karşılasın. Gereksiz scope talebini engelleyin, verilen erişimi geri alın ve yeni veri isteğini sınayın. Eski tokenın sonucunu ve audit kaydını kaydedin. Kullanıcıya e-posta doğrulama kodu veya parola göndermesini istemeden yetkili test ortamında çalışın.

Hata teşhisi

BelirtiOlası neden / ayrımDoğrulama
MFA kaydı var, giriş engelleniyorCihaz/konum politikası veya faktör şartı farklı olabilir.Etkili erişim politikası ve istemci desteğini doğrulayın.
App iptal edildi, erişim sürüyorBaşka grant, token veya delegation yolu olabilir.Kullanıcı/app/servis kimliği yollarını ve yeni isteği ayrı inceleyin.
Olay oldu, merkezi alarm yokKoleksiyon, scope veya tespit kuralı eksik olabilir.Bilinen test olayını kaynaktan alarm sonucuna kadar izleyin.

Kabul ve doğrulama kontrolleri

  1. İnsan, cihaz ve OAuth erişimini aynı güvenlik tasarımında doğrulayın.
  2. Kayıt ve kurtarma yolunu pilotta sınayın.
  3. Yönetici rolünü günlük kullanımdan ayırın.
  4. Politikayı web, mobil ve API yolunda test edin.
  5. OAuth scope ve delegationı envantere alın.
  6. Erişim iptalini ve alarm kanıtı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.

Güven sınırı ve hata alanı

Güven sınırı, aynı erişim kararlarını paylaşan bileşenleri ayırır; hata alanı ise tek bir olayın birlikte etkileyebileceği kaynakları tanımlar. İki VLAN kullanmak, aralarında serbest yönlendirme varsa güçlü bir güven sınırı kurmaz. İki yedek aynı yönetici hesabıyla silinebiliyorsa da farklı klasörlerde bulunmaları ayrı hata alanı sağlamaz. Tasarımda fiziksel yer, kimlik sağlayıcı, yönetim hesabı, ağ yolu ve enerji kaynağını ayrı ayrı değerlendirin. Bir bileşen kaybedildiğinde hangi erişimlerin ve kurtarma seçeneklerinin ayakta kalacağını 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.

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; log yokluğu, olay yokluğu şeklinde yorumlanmamalıdır.

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.

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ı!