SaaS Güvenlik Duruş Yönetimi: Nedir ve Neler Kontrol Edilir
SaaS güvenlik duruş yönetimi (SSPM), her uygulamanın kurulduğu gün güvenli olduğunu varsaymak yerine, kuruluşunuzun kullandığı her SaaS uygulamasının güvenlik yapılandırmasını — paylaşım varsayılanlarını, yönetici ayarlarını, OAuth izinlerini ve kullanıcı erişimlerini — sürekli olarak kontrol etme pratiğidir. Önemlidir, çünkü çoğu SaaS veri sızıntısı bir ağ ihlalinden değil, bir ayarın sessizce bozulmasından kaynaklanır.
Bu rehber, SSPM'nin gerçekte neyi kontrol ettiğini, bunun bir seferde tek bir uygulama üzerinden manuel olarak nasıl yapıldığını ve manuel yaklaşımın nerede yetersiz kaldığını ele alır.
SaaS güvenlik duruş yönetimi gerçekte neyi kontrol eder?
Tipik bir şirketin işlettiği SaaS uygulamaları genelinde, bir SSPM kontrol seti genellikle şunları kapsar:
- Kimlik doğrulama gereklilikleri — MFA'nın zorunlu olup olmadığı ve kimler için olduğu.
- Paylaşım varsayılanları — dosyaların, kanalların veya kayıtların varsayılan olarak herkese açık mı, kuruluş genelinde mi yoksa özel mi olduğu.
- OAuth uygulama izinleri — hangi üçüncü taraf uygulamaların hangi kapsamlarla yetkilendirildiği.
- Yönetici rolü yayılması — kaç kişinin süper yönetici veya sahip düzeyinde role sahip olduğu ve bunun kuruluşun ihtiyacından fazla olup olmadığı.
- Eski veya sahipsiz kalmış hesaplar — hâlâ erişime sahip eski çalışanlar veya kullanılmayan servis hesapları.
- Misafir ve harici erişim — hangi harici kimliklerin dahili verilere ulaşabildiği ve hangi kanal üzerinden.
Bunların her biri uygulamanın içinde soyut bir fikir değil, gerçek ve kontrol edilebilir bir ayardır — SSPM, bunların hepsini, bağlı her uygulama genelinde, bir kez yapıp geçmek yerine sabit bir takvimde kontrol etme disiplinidir.
SaaS güvenlik duruşu manuel olarak, uygulama uygulama nasıl kontrol edilir?
Her büyük SaaS platformu bu bilgilerin kendi versiyonunu, kendi yerinde, kendi biçiminde sunar:
- Google Workspace: Paylaşım ve uygulama erişim ayarları için Yönetici konsolu → Security → Security dashboard ve Security → Access and data control → API controls.
- Microsoft 365: kiracı genelindeki yapılandırmayı Microsoft'un kendi temel çizgisiyle karşılaştırarak puanlayan Microsoft Entra yönetim merkezi ve Microsoft 365 Defender'ın Secure Score'u.
- Slack: yüklü uygulama incelemesi için Settings & administration → Manage apps, ve 2FA ile Slack Connect kontrolleri için çalışma alanı güvenlik ayarları.
- GitHub: iki faktörlü zorunluluk için bir organizasyonun Settings → Security overview'ı ve OAuth uygulama politikası için Settings → Third-party Access.
Bunu manuel olarak yapmak, her konsolu sırayla açmak, aynı zihinsel kontrol listesini — kimlik doğrulama, paylaşım, uygulamalar, roller, eski erişimler, harici erişim — uygulamak ve bulguları not almak anlamına gelir; çünkü bu konsolların hiçbiri diğerlerinin varlığından haberdar değildir.
Manuel, uygulama uygulama duruş kontrollerini sürdürmeyi ne zorlaştırır?
Manuel bir sürece karşı özellikle dört şey birikerek etki eder:
- Duruş sürekli kayar. Her paylaşım, her yeni yönetici, her yeni yetkilendirilen uygulama, gerçekleştiği anda tabloyu değiştirir. Geçen çeyrekten kalma bir inceleme, artık var olmayan bir çalışma alanını anlatır.
- Uygulamalar arasında hiçbir şey standartlaşmaz. Google Workspace'teki "MFA enforced" ile Microsoft Entra'daki "Security defaults enabled" aynı temel kontroldür, ancak farklı biçimde ifade edilir ve yapılandırılır — bir kişi elle bir tane oluşturana kadar ortak bir dil yoktur.
- Her konsol farklı düzeyde ayrıntı gösterir. Bazıları kullanıcı bazında izin geçmişini gösterir; diğerleri sadece toplu sayıları gösterir. Manuel bir inceleme, yığınınızdaki en az ayrıntılı konsol kadar eksiksizdir.
- Tek bir uygulama kendi ayarlarını birden fazla ekrana bölebilir. Google Workspace tek başına paylaşım varsayılanlarını Security → Sharing settings altına, OAuth uygulama erişimini Security → API controls altına ve kiracı genelindeki risk özetini Security → Security dashboard altına koyar — ikinci bir SaaS aracı devreye girmeden önce tek bir uygulama için üç ayrı ekran.
SSPM, bir uyumluluk kontrol listesinden veya tek seferlik bir denetimden nasıl farklıdır?
Bir uyumluluk denetimi, "birisi kontrol ettiği gün doğru yapılandırılmış mıydık" sorusuna yanıt verir. SSPM ise "şu anda doğru yapılandırılmış mıyız, ve beş dakika önce öyle miydik" sorusuna yanıt verir — ayrım, bir anlık görüntü ile süregelen bir durum arasındadır. Bir kuruluş Mart ayında bir SOC 2 denetimini geçebilir ve Nisan ayında denetimin bir daha asla görmeyeceği herkese açık bir paylaşım bağlantısı oluşturabilir. Duruş yönetimi, denetimin yerini almak değil, denetim kapandıktan sonra da izlemeye devam etme kararıdır. Bunu benimseyen çoğu kuruluş, temel kategorileri sürekli kontrol eder ve tam kontrol listesini sabit bir aralıkla yeniden gözden geçirir — sürekli değiştiği için harici paylaşım ve OAuth izinleri için haftalık, daha yavaş değiştiği için yönetici rolleri ve eski hesaplar için aylık.
Manuel, uygulama bazlı bir inceleme size neyi söyleyemez ve 8200.dev buna nasıl yanıt verir?
Manuel bir tarama, size baktığınız gün itibarıyla ayarları gösterir. Bulgulardan hangisinin gerçekten en çok önem taşıdığını, tablonun nasıl bir yöne gittiğini söylemez ve siz işinizi bitirdikten sonraki gün değişen ayarı yakalayamaz. 8200.dev'in Posture Guard'ı, aynı kontrol kategorilerini — paylaşım, OAuth izinleri, yönetici rolleri, eski erişimler, harici erişim — bağlı her kaynaktan çekip, tek, standartlaştırılmış, sürekli olarak yeniden kontrol edilen bir görünüme dönüştürür ve bulguları düz bir liste yerine gerçek riske göre (hassasiyet × erişim genişliği × erişim düzeyi) sıralar. Her bağlayıcı varsayılan olarak salt okunur çalışır: bulgular ve öneriler standart moddur; bağlı bir kaynakta herhangi bir değişiklik, ancak kuruluş o belirli kural için Auto-remediate'i etkinleştirir ve buna ilişkin yazma kapsamını ayrıca verirse gerçekleşir — burada hiçbir şey kendiliğinden hareket etmez.
Google Workspace bağlayıcısıyla başlayın veya tüm bağlayıcı listesine göz atın, ve puanlama ile politika katmanlarının uçtan uca nasıl çalıştığını inceleyin.
İlgili kılavuzlar
- Google Workspace'inize Hangi Yapay Zeka Araçlarının Erişimi Olduğunu Nasıl Görürsünüz
Google Workspace'inize OAuth erişimi olan yapay zeka araçlarını listeleyen Google Admin console yolu, ne gösterdiği ve nelere cevap veremediği.
- Slack, GitHub ve Microsoft 365 Genelinde Üçüncü Taraf OAuth Uygulamaları Nasıl Denetlenir
Slack, GitHub ve Microsoft 365'te yetkilendirilen OAuth uygulamalarını incelemek için tam yönetici ekranları ve her platformun gösterip gösteremeyecekleri.
- Microsoft 365'inize Hangi Uygulamaların Erişimi Olduğunu Görme Yöntemi
Microsoft 365 kiracınıza erişimi olan tüm uygulamaları listelemek için tam Microsoft Entra yolu ve yönetici onayı ile kullanıcı onayı arasındaki fark.