Google Workspace için SOC 2 Uyumluluğu: Bilmeniz Gerekenler
Kuruluşunuz SOC 2 sürecini yürütüyorsa — ki çoğu B2B yazılım şirketi er ya da geç bunu yapar, çünkü müşteriler bunu talep eder — Google Workspace kapsam içinde olacaktır. Kimlikleri, belgeleri ve erişim denetimlerini barındırır; bunlar da bir denetçinin incelediği kriterlerle doğrudan örtüşür. Bu makale, Workspace'in bir SOC 2 programına nasıl dahil olduğunu ve son dakika telaşı yaşamadan Workspace tarafının nasıl hazırlanacağını anlatır.
Baştan bir dil notu: SOC 2, bağımsız bir CPA firması tarafından gerçekleştirilen bir *tasdiktir (attestation)*, kendinize verdiğiniz bir rozet değildir. Sonuç, bir denetçinin raporudur, kendi kendine beyan edilen bir etiket değil. İç olarak yapabileceğiniz şey, denetimlerin sorunsuz ilerlemesi için kontrolleri kurup göstermek ve kanıtları toplamaktır. Bu makale de tam olarak bunu konu alıyor.
SOC 2'ye hızlı bir bakış
SOC 2, bir hizmet kuruluşunun kontrollerini Trust Services Criteria (TSC) karşısında değerlendirir: Security (her zaman dahildir, genellikle Common Criteria olarak anılır) ve isteğe bağlı olarak Availability, Processing Integrity, Confidentiality ve Privacy. Security kriterleri — CC serisi — Google Workspace'in en çok göründüğü yerdir.
Bir Type I raporu, kontrollerin belirli bir zaman noktasında uygun şekilde *tasarlanıp tasarlanmadığını* değerlendirir. Bir Type II raporu, kontrollerin bir dönem boyunca (tipik olarak 3-12 ay) *etkili şekilde işleyip işlemediğini* değerlendirir. Müşteriler genellikle Type II'yi ister ve bunun önemli bir sonucu vardır: sadece denetim gününde değil, tüm dönem boyunca işleyen kontrollere ve bunların işlediğine dair kanıtlara ihtiyacınız vardır.
Google Workspace kriterlerle nerede örtüşür
Birkaç Common Criteria, zaten temas ettiğiniz Workspace kontrolleriyle net biçimde örtüşür:
- CC6.1 — Mantıksal erişim kontrolleri. Korunan bilgiye kimin ulaşabildiği ve erişimin yetkili kullanıcılarla nasıl sınırlandırıldığı. Workspace terimleriyle: hesap sağlama, MFA zorunluluğu, paylaşım kontrolleri ve harici ile hizmet hesapları dahil her kimliğin sahip olduğu erişim.
- CC6.2 — Kayıt ve yetkilendirme. Yeni kullanıcılar, erişim verilmeden önce kaydedilir ve yetkilendirilir; artık gerekmediğinde erişim kaldırılır. İşe giriş/rol değişikliği/işten ayrılış hijyeni burada yer alır.
- CC6.3 — En az yetki ve görevler ayrılığı. Erişim rollere dayanır ve gerekli asgari düzeyde tutulur. Aşırı yetkilendirilmiş erişim ve yönetici yayılması bu kriter kapsamında bulgu oluşturur.
- CC6.6 — Dış tehditlerden korunma. Dışarıdan ulaşılabilir yüzey: genel bağlantılar, harici paylaşımlar ve kuruluş dışındaki kimliklere verilen erişim.
- CC7.x — İzleme ve olay müdahalesi. Anormalliklerin tespit edilmesi ve güvenlik olaylarına müdahale edilmesi. Paylaşım veya erişim değişikliklerini bilmek ve inceleme yapabilmek bunları destekler.
Numaralandırmayı ezberlemeniz gerekmez. Buradaki nokta şu: günlük Workspace çalışması — MFA'yı zorunlu kılmak, paylaşımı kontrol etmek, eskimiş erişimi kaldırmak, üçüncü taraf uygulamaları yönetmek — bir denetçinin görmek istediği kontrol kanıtının *ta kendisidir*.
Denetçiler gerçekte ne talep eder
Denetçiler güvence değil, kanıt ister. Workspace ile ilgili kontroller için şu tür talepler beklenmelidir:
- MFA'nın zorunlu kılındığına dair kanıt (politika ve uygulanışı, sadece "açtık" değil).
- Yöneticilerin listesi ve her ayrıcalıklı rol için bir gerekçe.
- Erişim incelemelerinin kanıtı — hassas verilere kimin ulaşabildiğini periyodik olarak kontrol ettiğinizi ve bulgulara göre işlem yaptığınızı gösteren kanıt.
- Çalışanlar ayrıldığında erişimin kaldırıldığına dair kayıtlar.
- Paylaşım yapılandırması ve harici paylaşımın nasıl kontrol edildiği.
- Güvenlik bulgularının çözüme kadar nasıl izlendiğine dair bir kayıt.
Tekrar eden tema şudur: denetim izi bırakan, belgelenmiş, tekrarlanabilir süreç. Var olan ama iz bırakmayan bir kontrole tasdik vermek zordur. Sürekli çalışan ve bulduklarını kaydeden bir kontrole ise kolaydır.
Workspace tarafını nasıl hazırlarsınız
- Bir yapılandırma temel çizgisi (baseline) oluşturun. Yönetici ayarlarınızın hedeflenen durumunu belgeleyin — paylaşım, 2 Adımlı Doğrulama, Marketplace kısıtlamaları, e-posta kimlik doğrulama — ve gerçekliği belirli aralıklarla bunun karşısında kontrol edin. Sapma (drift), temiz bir denetimin baş düşmanıdır.
- Kanıtlayabileceğiniz erişim incelemeleri yürütün. Hassas verilere kimin ulaşabildiğini — harici ve insan olmayan kimlikler dahil — periyodik olarak inceleyin ve çıktıyı saklayın. "Erişimi üç ayda bir inceledik, işte kayıtlar" tam olarak CC6.3'ün istediği şeydir.
- Paylaşımı sıkılaştırın ve belgeleyin. Genel ve harici paylaşımı kontrol ederek ve mevcut durumu gösterebilerek CC6.1 ve CC6.6 ile örtüşün.
- Bulguları çözüme kadar izleyin. Bir açık bulduğunuzda, kaydedin, düzeltin ve izini saklayın. Bu, izleme ve düzeltme kriterlerini destekler.
- Bir denetim günlüğü tutun. Güvenlikle ilgili eylemlerin zaman damgalı bir kaydı, "kim, ne zaman, ne yaptı" sorularını cevaplamayı önemsiz bir hale getirir.
Bunun büyük kısmı genel olarak iyi Google Workspace güvenliği ile örtüşür — asıl mesele de bu. SOC 2 ayrı, sonradan eklenen bir proje değildir; okunaklı ve kanıtlanmış hale getirilmiş güvenlik uygulamanızdır.
Sürekli kanıt, denetim telaşını yener
Klasik başarısızlık biçimi, uyumluluğu bir olay olarak ele almaktır: denetimden önce ekran görüntüleri ve tablolarla geçen çılgın bir ay, her yıl tekrarlanır. Stresli, hataya açıktır ve bir Type II denetçisinin haklı olarak sorgulayacağı belirli bir ana ait kanıt üretir.
Alternatif ise süreklidir: duruşu yıl boyunca kontrol edin, kanıtı bir yan ürün olarak üretin ve denetime iziniz zaten hazır halde girin. Bulguları SOC 2 kriterlerine eşleyen ve denetçiye hazır kanıt üreten bir duruş aracı, telaşı bir dışa aktarma işlemine dönüştürür.
Denetimin Workspace kısmındaki yaygın tuzaklar
Tekrar tekrar ortaya çıkan ve önceden önlenmesi gereken birkaç hata vardır:
- "Yapılandırılmış" ile "zorunlu kılınmış"ı karıştırmak. Bir 2 Adımlı Doğrulama politikasını açmak, bunun her hesaba uygulanmasıyla aynı şey değildir. Denetçiler ikincisini test eder. Zorunluluğun kuruluş genelinde geçerli olduğunu doğrulayın — bkz. Google Workspace genelinde MFA'yı zorunlu kılma rehberimiz.
- Erişim incelemelerini bir onay kutusu gibi ele almak. Kayıt, kapsam veya takip olmadan "erişimi inceliyoruz" demek kanıt değildir. Çıktıyı saklayın ve bulgulara göre işlem yapıldığını gösterin.
- İnsan olmayan kimlikleri unutmak. Hizmet hesapları ve yapay zeka ajanları da erişime sahiptir ve en az yetkiyi (CC6.3) inceleyen bir denetçi "sadece insanları inceledik" cevabını kabul etmeyecektir. Bunları yönetin — bkz. riskli yapay zeka ajanlarını tespit etme.
- Yapılandırmanın denetimler arasında sapmasına izin vermek. Ocak ayında temiz olan ama Haziran'a kadar sapan bir temel çizgi, bir Type II bulgusu üretir. Çizgiyi koruyan şey yıllık bir anlık görüntü değil, sürekli kontroldür.
Uyumluluk, iyi güvenliğin bir yan ürünüdür
SOC 2'nin Workspace tarafı için en yararlı yeniden çerçeveleme şudur: kontrolleri *denetim için* kurmuyorsunuz — sağlam bir güvenlik programı yürütüyor ve denetimin bunu gözlemlemesine izin veriyorsunuz. Erişim kontrolü kriterleri altında bir denetçinin görmek isteyeceği her şey, zaten her koşulda isteyeceğiniz bir şeydir: zorunlu kılınmış kimlik, kontrollü paylaşım, yönetilen üçüncü taraf erişimi ve sürdürülen bir yapılandırma temel çizgisi. Denetim, sadece bunu okunaklı ve kanıtlanmış hale getirmenizi ister.
Bunu içselleştiren ekipler, yıllık döngüden korkmayı bırakır. Kontroller yıl boyunca çalışır, kanıt bir yan ürün olarak birikir ve denetim, kendi başına bir proje olmaktan çıkıp zaten yapılmış işin bir incelemesine dönüşür. Telaşlanmakla hazır olmak arasındaki fark da pratikte tam olarak budur.
8200.dev, Google Workspace duruşunuzu SOC 2, ISO 27001 ve GDPR kontrol ailelerine eşler ve bir denetçiye teslim edebileceğiniz kanıt paketleri üretir — dürüst, gerçekten gözlemlediğimizle sınırlı, asla hak edilmemiş bir uyumluluk iddiası değil. Nasıl çalıştığı veya kendi güvenlik uygulamalarımız hakkında daha fazla bilgi edinin.
Bir denetime mi hazırlanıyorsunuz? Ücretsiz güvenlik denetiminizi başlatın ve Google Workspace duruşunuzun denetçilerin incelediği erişim kontrolü kriterleriyle nasıl örtüştüğünü görün.
İlgili makaleler
- Bağımsız Geliştirici Olarak Zaten Sizin İçin Geçerli Olan Güvenlik Yükümlülükleri
Serbest çalışanlar ve bağımsız geliştiriciler gerçek GDPR, AB Yapay Zeka Yasası ve sözleşmesel güvenlik yükümlülükleri taşır — önce neyin kontrol edilmesi gerektiği burada.
- Var Olmayan AI Opt-Out'u: 17 SaaS Platformunu Kontrol Ettiğimizde Bulduklarımız
8200.dev'in konektör kütüphanesindeki 17 platformun tümünü, içeriğinizi varsayılan olarak kimin AI eğitiminde kullandığını görmek için kontrol ettik.
- Lovable ile Uygulamayı Siz Geliştirdiniz — Veri Sızdığında Sorumlu Kim?
Lovable veya Base44 ile uygulama geliştirmek hızlıdır — ancak veri sorumlusu, onu devreye alan şirkettir. AI ile geliştirilen uygulama güvenliği ve sorumluluğu.