SaaS (Software as a Service) uygulamaları, hızlı devreye alma ve düşük operasyon yükü nedeniyle yaygın. Ancak aynı “kolaylık” bazı ekiplerde yanlış varsayımlara yol açabiliyor: “Sağlayıcı güvenliği hallediyor.” Gerçekte çoğu SaaS ürününde güvenlik, paylaşımlı sorumluluk yaklaşımıyla yürür: sağlayıcı altyapıyı ve platformu güvenli tutarken, müşteri tarafı kimlik, erişim, yapılandırma, veri yaşam döngüsü ve entegrasyonlar gibi alanlarda sorumludur.

Bu yazı, SaaS uygulamalarında en yaygın güvenlik açıklarını ve bunları önlemek için pratik adımları açıklar. Referans olarak OWASP’ın web ve API risk sınıflandırmalarını, NIST’in dijital kimlik ve güvenli yazılım geliştirme rehberlerini, ayrıca CISA’nın SaaS yapılandırma yaklaşımını kullanır.

SaaS güvenliğini doğru çerçevelemek: Nerede hata olur?

SaaS güvenliğinde açıklar genelde üç yerde oluşur:

  • Kimlik ve erişim: Hesap ele geçirme, aşırı yetki, zayıf oturum yönetimi.
  • Uygulama ve API katmanı: Yetkilendirme mantığı hataları, veri erişim kontrol eksikleri, rate limit yokluğu.
  • Yapılandırma ve entegrasyonlar: Yanlış ayarlar, üçüncü taraf uygulamalar, gizli anahtar (secret) sızıntıları.

Vaka analizlerine dayanan Verizon DBIR, çalınmış kimlik bilgilerinin birçok senaryoda ilk erişim yöntemleri arasında sık görüldüğünü vurgular. Bu, SaaS için özellikle önemlidir; çünkü saldırgan bir hesabı ele geçirirse, çoğu zaman “iç kullanıcı” gibi hareket edebilir. (Kaynak: Verizon 2025 DBIR)

1) Kimlik (IAM) zafiyetleri: Hesap ele geçirme ve aşırı yetki

SaaS ortamlarında en pahalı sonuçlar genellikle kimlikten başlar: yönetici hesabı ele geçirilir, API token’ı çalınır veya yanlış rol ataması yapılır. NIST’in dijital kimlik yönergeleri, güçlü kimlik doğrulama ve risk temelli kontrol seçiminde iyi bir referanstır. (Kaynak: NIST SP 800-63-4)

Özellikle erişim kontrolü tarafında, OWASP Top 10:2021 sınıflandırması “Broken Access Control” riskini (A01) web uygulamalarında temel bir problem alanı olarak ele alır; SaaS yönetim konsolları ve tenant/rol tasarımlarında da benzer mantık hataları görülebilir. (Kaynak: OWASP Top 10:2021)

Önleme adımları (uygulanabilir kontrol listesi)

  • MFA’yı zorunlu kılın: Özellikle yönetici hesapları, finans/CRM, e-posta, destek masası gibi yüksek etkili uygulamalar için.
  • SSO + merkezi erişim yönetimi: Kurumsal dizinle (IdP) entegre SSO kullanın; kullanıcı yaşam döngüsünü mümkünse SCIM ile otomatikleştirin.
  • Least privilege (en az ayrıcalık): Varsayılan rolleri daraltın; “geçici yükseltme” (just-in-time) gibi süreçler ekleyin.
  • Eski/atıl hesapları kapatın: İşten ayrılanlar, yüklenici hesapları, kullanılmayan API anahtarları için otomatik kapanış.
  • Oturum güvenliği: Uzun ömürlü oturumları sınırlayın; riskli coğrafya/cihaz için ek doğrulama tetikleyin.

Pratik örnek: Yönetici hesapları için “2 katman” yaklaşımı

Saha pratiğinde sık kullanılan bir yaklaşım: günlük iş için standart hesap, yalnızca gerektiğinde yönetici rolüne geçilen ayrı bir yönetici hesabı. Bu, kimlik bilgisi ele geçirilse bile etki alanını daraltır. Ayrıca yönetici oturumlarının ayrı log’lanmasını kolaylaştırır.

2) API yetkilendirme hataları: Modern SaaS’ın en kritik teknik riski

Güncel SaaS ürünlerinin büyük bölümü API tabanlıdır. OWASP’ın API Security Top 10 (2023) çalışması; özellikle yetkilendirme eksiklerini (nesne düzeyi, özellik düzeyi ve fonksiyon düzeyi) kritik risk alanları arasında öne çıkarır. (Kaynak: OWASP Top 10 API Security Risks – 2023)

Yaygın görülen senaryolar

  • BOLA (Broken Object Level Authorization): Kullanıcı, kendi kaydı yerine başka bir kullanıcının kaydını ID değiştirerek okuyabilir/düzenleyebilir.
  • Özellik düzeyi kontrol eksikliği: Kullanıcı, normalde görmemesi/değiştirmemesi gereken alanları (ör. “role”, “limit”, “plan”) istemekle elde edebilir.
  • Fonksiyon düzeyi yetki hatası: Standart kullanıcı, admin endpoint’lerine erişebilir.
  • Kaynak tüketimi suistimali: Rate limit/kota yoksa brute force, envanter çıkarma veya maliyet yükseltme kolaylaşır.

Bu risk başlıkları; OWASP API Top 10 (2023) içinde “Broken Object Level Authorization”, “Broken Object Property Level Authorization”, “Broken Function Level Authorization” ve “Unrestricted Resource Consumption” gibi kategorilerle doğrudan ilişkilidir. (Kaynak: OWASP API Top 10 (2023))

Önleme adımları (API güvenliği için minimum set)

  • Sunucu tarafı yetkilendirme: Her istekte “kullanıcı bu nesnenin sahibi mi?” kontrolünü sunucuda yapın; yalnızca UI kontrollerine güvenmeyin.
  • Politika tabanlı yetki: Rol/özellik bazlı kuralları kod içinde dağınık yazmak yerine merkezi politika yaklaşımı benimseyin.
  • Şema doğrulama ve allowlist: Beklenmeyen alanları reddedin; “mass assignment” risklerini azaltın.
  • Güvenli varsayılanlar: Yeni endpoint “private by default” olsun; açıkça izin verilmeyen erişimler reddedilsin.
  • Token kapsamı ve yaşam döngüsü: Token’lara dar kapsam (scope) tanımlayın, kısa süreli token tercih edin, rotasyon uygulayın.

3) Yanlış yapılandırma: SaaS konsol ayarları, depolama ve paylaşım hataları

Bulut/SaaS tehdit analizleri, yanlış yapılandırma ve aşırı izinlerin tekrar eden bir problem olduğunu vurgular. (Kaynaklar: CSA Top Threats to Cloud Computing 2024, Verizon 2025 DBIR)

Bu tema, OWASP Top 10:2021’de “Security Misconfiguration” (A05) başlığıyla web uygulamaları için de sık görülen bir risk alanı olarak ele alınır; SaaS tarafında ise bu durum çoğu zaman yönetim konsolu ayarları ve tenant düzeyi politikalar üzerinden ortaya çıkar. (Kaynak: OWASP Top 10:2021)

Özellikle riskli ayarlar

  • Genel paylaşım linkleri (public link) ve “herkes erişebilir” izinleri
  • Harici işbirliği: Domain dışı kullanıcıların davet edilmesi ve denetlenmemesi
  • Günlük/denetim log’larının kapalı olması veya kısa saklama süresi
  • Koşullu erişim (cihaz uyumluluğu, konum, risk) politikalarının yokluğu

Hızlı kazanım: Baseline’larla başlamak

CISA’nın SCuBA projesi, yaygın kurumsal bulut iş uygulamaları için yapılandırma temel çizgileri (baseline) ve kontrol listeleri sunmayı hedefler. Kurumlar bunu kendi risk iştahına uyarlayarak hızlı bir “ilk sertleştirme” elde edebilir. (Kaynak: CISA SCuBA Project)

4) Veri sızıntısı riskleri: Paylaşım, yedekleme, log ve entegrasyonlar

“Veri sızıntısı” yalnızca bir saldırganın sisteme sızması değildir. SaaS’ta yaygın veri kaybı senaryoları; yanlış paylaşım, yanlış rol, üçüncü taraf entegrasyonun aşırı yetkisi veya log’lara hassas veri düşmesi gibi nedenlerle oluşur.

Önleme adımları

  • Veri sınıflandırma: En azından “genel / dahili / hassas” gibi basit bir şema oluşturun; hassas veri için ek kontroller tanımlayın.
  • DLP (varsa) ve paylaşım politikaları: Hassas verinin dışa paylaşımını engelleyen veya onaya bağlayan kurallar ekleyin.
  • Log hijyeni: Token, şifre, PII gibi değerlerin log’a yazılmasını uygulama seviyesinde engelleyin.
  • Yedekleme ve geri yükleme: SaaS sağlayıcısının sunduğu geri dönüş seçenekleri ile kurum içi gereksinimler her zaman örtüşmeyebilir; kritik iş süreçleri için geri yükleme senaryolarını test edin.

5) Şifreleme ve anahtar yönetimi: “Şifreli” demek yetmez

SaaS’ta şifreleme çoğu zaman sağlayıcı tarafından sunulur; ancak anahtarların yönetimi, erişim politikaları, rotasyon ve yaşam döngüsü doğru değilse risk devam eder. NIST’in anahtar yönetimi rehberi, anahtar yaşam döngüsü ve kontrol hedefleri için kapsamlı bir referanstır. (Kaynak: NIST SP 800-57 Part 1 Rev.5)

Uygulanabilir öneriler

  • Anahtar sahipliği ve erişimi: Anahtar/KMS erişimini rol bazında sınırlandırın; ayrı görev (separation of duties) düşünün.
  • Rotasyon ve iptal: Şüpheli durumda hızlı iptal (revoke) ve düzenli rotasyon süreçleri oluşturun.
  • Uçtan uca ihtiyaçları belirleyin: Bazı kullanım durumlarında müşteri yönetimli anahtarlar (CMK/BYOK) gerekebilir; kararınızı regülasyon, tehdit modeli ve operasyon kabiliyetine göre verin.

6) Yetersiz logging ve izleme: Olayı geç fark etmek, zararı büyütür

Birçok SaaS olayında sorun “hiç log yok” değil, “log var ama takip edilmiyor” olur. OWASP Top 10:2021, Security Logging and Monitoring Failures (A09) başlığıyla eksik loglama/izlemenin saldırı tespiti ve müdahaleyi zorlaştırabileceğine dikkat çeker. (Kaynak: OWASP Top 10:2021)

DBIR gibi olay raporları da, kimlik ve erişim kaynaklı vakalarda erken tespit ve hızlı müdahalenin (genel olarak) etkiyi azaltabildiğini; bu nedenle görünürlük ve izleme yatırımlarının pratik değer taşıdığını gösteren bulgular içerir. (Kaynak: Verizon 2025 DBIR)

Minimum izleme paketi

  • Denetim log’larını açın: Admin aksiyonları, oturum açma, MFA devre dışı bırakma, paylaşım değişiklikleri.
  • Merkezi toplama: Log’ları SIEM/Log platformuna akıtın; en azından kritik alarmlar üretin.
  • Alarm örnekleri: İmkânsız seyahat, yeni cihazdan admin oturumu, kısa sürede çok sayıda paylaşım linki oluşturma, API token kullanımında ani artış.
  • Saklama süresi: Olay incelemesi için yeterli saklama süresi hedefleyin (kurumsal gereksinimlere göre değişir).

7) Tedarik zinciri ve üçüncü taraf riskleri: Eklentiler, SDK’lar, CI/CD ve bağımlılıklar

SaaS ekipleri yalnızca kendi kodlarını değil; bağımlılıkları, CI/CD iş akışlarını ve üçüncü taraf entegrasyonları da yönetir. NIST SSDF, güvenli yazılım geliştirme yaşam döngüsü için uygulanabilir bir kontrol çerçevesi sunar. (Kaynak: NIST SP 800-218 SSDF)

SSDF ile uyumlu pratik adımlar

  • Bağımlılık taraması (SCA): Kritik açıklar için hızlı yamalama süreci; “sahiplik” tanımları.
  • Secret scanning: Repo ve CI log’larında anahtar/token sızıntılarını yakalayın.
  • Build güvenliği: CI işleyicilerine erişimi sınırlandırın; imza/attestation gibi yetenekleri değerlendirin.
  • Üçüncü taraf uygulamalar: OAuth uygulamalarının izinlerini düzenli gözden geçirin; kullanılmayanları kaldırın.

SaaS sağlayıcısı değerlendirirken sorulacak sorular (pratik şablon)

Aşağıdaki sorular, güvenlik ekipleri kadar satın alma ve ürün ekipleri için de işe yarar. Buradaki amaç “mükemmel” sağlayıcıyı bulmak değil; riskleri görünür kılıp, kabul/azaltma kararını bilinçli vermektir.

  • Kimlik entegrasyonu: SSO (SAML/OIDC) ve SCIM destekliyor musunuz? Koşullu erişim yetenekleri neler?
  • MFA politikaları: Admin MFA zorunlu mu? Kullanıcı bazında enforcement var mı?
  • Log ve denetim: Hangi denetim log’ları mevcut, API ile dışa aktarılabiliyor mu, saklama süresi seçenekleri neler?
  • Şifreleme: Veri aktarımında ve depolamada şifreleme var mı? Müşteri yönetimli anahtar seçeneği bulunuyor mu?
  • İzin modeli: Rol bazlı erişim ayrıntı seviyesi nedir? “Özel rol” tanımlanabiliyor mu?
  • İhlal bildirimi: Güvenlik olayı bildirim süreçleri ve iletişim kanalları nasıl?
  • Üçüncü taraflar: Alt işlemciler/entegrasyonlar listesi ve değişiklik bildirim yaklaşımı nedir?

İlk 90 gün için önceliklendirilmiş eylem planı

Küçük ekipler için tüm kontrolleri aynı anda uygulamak zor olabilir. Aşağıdaki plan, en sık görülen riskleri önce azaltmayı hedefler.

0–30 gün: Kimlik ve görünürlük

  • MFA zorunlu (en azından admin ve kritik uygulamalar)
  • SSO devreye alma; offboarding sürecini netleştirme
  • Denetim log’larını açma ve merkezi log toplama
  • Paylaşım politikalarını sıkılaştırma (public link, dış domain paylaşımı)

31–60 gün: API ve yapılandırma sertleştirme

  • API’lerde sunucu tarafı yetkilendirme testleri (BOLA odaklı)
  • Rate limit/kota ve kötüye kullanım kontrolleri
  • Varsayılan rollerin daraltılması; düzenli erişim gözden geçirmesi
  • Üçüncü taraf OAuth uygulama izinlerinin denetimi

61–90 gün: Süreç ve tedarik zinciri

  • SSDF’ye hizalanmış asgari SDLC kontrolleri (kod inceleme, SCA, secret scanning)
  • Anahtar/token rotasyon prosedürleri
  • Olay müdahale çalışması: “hesap ele geçirildi” ve “API token sızdı” senaryosu tatbikatı

Sık görülen zafiyetler ve en etkili önlemler (özet tablo)

Risk alanı Tipik açık En etkili ilk önlem
IAM Zayıf kimlik doğrulama, aşırı yetki MFA + SSO + least privilege
API Yetkilendirme hataları (BOLA vb.) Sunucu tarafı authZ testleri ve politika yaklaşımı
Yapılandırma Genel paylaşım, zayıf tenant ayarları Baseline + düzenli konfigürasyon gözden geçirme
Şifreleme Anahtar yaşam döngüsü eksikleri Erişim sınırları + rotasyon + iptal planı
İzleme Log var ama alarm/triage yok Kritik alarmlar + merkezi log toplama
Tedarik zinciri Bağımlılık açıkları, secret sızıntısı SCA + secret scanning + CI erişim kontrolü

Sınırlar ve doğru beklenti yönetimi

Bu rehber, OWASP/NIST/CISA gibi kaynaklardan türetilen genel prensipleri SaaS bağlamına uyarlar. Ancak her SaaS sağlayıcısının özellikleri, log seçenekleri, anahtar yönetimi kabiliyetleri ve şeffaflık düzeyi farklıdır. Bu nedenle, burada anlatılan kontrolleri uygularken hem ürün dokümantasyonunu hem de kurumunuzun risk iştahını dikkate almanız gerekir.

Ek olarak, sektör raporları bulut ve kimlik temelli risklerin yaygınlığına işaret etse de “SaaS’a özel” kırılımlar her zaman ayrıntılı olmayabilir. Bu yüzden rapor bulgularını SaaS mimarinize uyarlarken dikkatli yorumlamak önemlidir.

Not: Bu içerik bilgilendirme amaçlıdır; hukuki tavsiye veya kurumsal denetim raporu yerine geçmez. Kritik sistemlerde değişiklik yapmadan önce güvenlik ekibiniz ve gerekiyorsa uzman danışmanlarla değerlendirme yapın.