SaaS Güvenlik ve Veri İzolasyonu: KVKK, OAuth2, Şifreleme

SaaS uygulamalarında güvenlik, yazılım geliştirmenin en kritik yönüdür. Müşteri verileri, şirketin en değerli varlığıdır. Bir veri ihlali, işletmeyi yıkabilir, müşteri güvenini kaybettirir ve yasal sonuçlar doğurabilir.

Özellikle sağlık sektörü, finansal veriler ve kişisel bilgileri yöneten uygulamalarda, güvenlik standartları çok yüksektir. Bu rehberde, SaaS uygulama geliştirmede güvenliği nasıl sağlayacağınızı, veri izolasyonunu nasıl garantileyeceğinizi ve Türkiye'deki KVKK mevzuatına nasıl uyacağınızı öğreneceksiniz.

SaaS Güvenliğinin Temel Prensipleri

Defense in Depth (Katmanlı Savunma)

Tek bir güvenlik mekanizmasına güvenmeyin. Etkili bir güvenlik stratejisi, birden çok katmanlı koruma sağlar. Bir katman başarısız olsa dahi, sistem diğer katmanlar tarafından korunmaya devam eder. Bu katmanlar ağ seviyesinde güvenlik duvarı ve DDoS korumasından, uygulama seviyesinde giriş doğrulaması ve koruma mekanizmalarına, veritabanı seviyesinde satır tabanlı güvenlik ve şifrelemeye, ve işletimsel seviyede denetim günlükleme ve izlemeye kadar uzanır.

Least Privilege Principle

Her kullanıcı ve sistem bileşeni, görevini tamamlamak için gereken minimum yetkilerle çalışmalıdır. Bu ilke, yanlışlık veya kötü niyetli eylemlerden kaynaklanan hasarı sınırlandırır. Örneğin, bir hemşire doktor tarafından erişilebilen sağlık kayıtlarına tam erişime ihtiyaç duymaz. Bunun yerine, yalnızca kendisine atanan hastaların kayıtlarını görebilir. Yöneticiler ise tüm sistemlere erişim hakkına sahip olabilir, ancak bu erişim düzenli olarak denetlenmelidir.

Tenant Veri İzolasyonu

Multi-tenant SaaS uygulamalarında, her müşteri (tenant) verisi kesinlikle izole olmalıdır. Yanlışlıkla bir müşterinin verisinin başka bir müşteriye sızması, SaaS şirketleri için en tehlikeli risklerden biridir.

Veritabanı Seviyesi İzolasyonu

Modern veritabanları, row-level security (RLS) adlı bir özellik sunmaktadır. Bu mekanizma, veritabanı seviyesinde hangi satırların hangi kullanıcı tarafından görülebileceğini kontrol eder. Örneğin, PostgreSQL'de, bir tabloyu row-level security ile etkinleştirdikten sonra, her sorgulamada hangi tenant için veri istediği belirtilir. Veritabanı otomatik olarak o tenant'a ait satırları filtreler. Bu yaklaşım, uygulama katmanında bir hata olsa dahi, veritabanı otomatik olarak verileri izole tutmasını sağlar.

Uygulama Seviyesi İzolasyonu

Veritabanı korumasına ek olarak, uygulamada da kontroller olmalıdır. Django gibi modern çerçevelerde, her sorguya otomatik olarak tenant filtresi uygulanabilecek şekilde kustom manager'lar yazılabilir. Bu şekilde, geliştirici, her sorguda tenant kontrol etmeyi unutsa dahi, sistem otomatik olarak filtreler. Ayrıca, URL manipülasyonu ile doğrudan başka bir müşterinin verisine erişmeye çalışan kişiler 403 (Forbidden) hatasıyla karşılaşmalıdır.

Test Edilecek Senaryolar

Veri izolasyonunun sağlam olduğundan emin olmak için, her müşterinin sadece kendi verisini görebildiğini doğrulayan testler yazılmalıdır. Ayrıca, URL manipülasyonu veya doğrudan API istekleri ile başka bir müşterinin verisine erişilmesinin engellendiği kontrol edilmelidir.

Şifreleme Stratejileri

Transit Encryption (HTTPS/TLS)

İnternet üzerinde aktarılan tüm veriler, HTTPS (TLS şifrelemesi) kullanılarak iletilmelidir. Bu, ağ trafiğini dinleyen saldırganların müşteri verisini görmesini engeller. Modern uygulamalar, HTTP trafiğini otomatik olarak HTTPS'ye yönlendirir ve TLS sertifikalarını en az bir yıl için ayarlar.

At-Rest Encryption (Verinin Dinlenme Anında Şifrelemesi)

Hassas veriler, veritabanında düz metin olarak depolanmamalıdır. Sosyal güvenlik numaraları, tıbbi geçmiş ve benzer bilgiler, Fernet veya AES-256 gibi algoritmalar kullanılarak şifrelenmelidir. Şifrelenmiş veriler veritabanından okunduğunda otomatik olarak çözülür, yazarken şifrelenir.

End-to-End Encryption

En hassas veriler (örneğin şifreler veya API anahtarları) için, veri client tarafından şifrelenir ve sunucu tarafından bile çözülemez. Kullanıcı bilgileri gönderilirken, browser'ın built-in kripto API'leri kullanılarak şifreleme yapılır. Server yalnızca şifreli veriyi depolar.

Kimlik Doğrulama ve Yetkilendirme

Modern Kimlik Doğrulama Yöntemleri

Günümüz SaaS uygulamaları, OAuth2 ve OpenID Connect (OIDC) gibi modern protokoller kullanmalıdır. Bu protokoller, kullanıcıların Google, Microsoft veya diğer sağlayıcılar aracılığıyla oturum açmalarına (sosyal login) izin vererek, şifre yönetiminin yükünü azaltır. Ayrıca, kurumsal müşteriler için Single Sign-On (SSO) desteği sunulmalıdır.

JWT Tokens ve Çok Faktörlü Kimlik Doğrulama

JWT (JSON Web Token) tabanlı kimlik doğrulama, stateless oturum yönetimi sağlar. Kullanıcı ID, tenant ID ve diğer bilgiler token'a kodlanır. Çok faktörlü kimlik doğrulama (MFA), kullanıcıların telefon veya Google Authenticator gibi araçlarla bir ikinci faktör sağlamasını gerektirir. Sağlık veya finans gibi kritik alanlarda MFA'nın kullanılması yasal bir zorunluluk olabilir.

KVKK Uyumluluğu (Türkiye)

Kişisel Verileri Koruma Kanunu (KVKK), Türkiye'de müşteri verilerini işleyen tüm SaaS şirketleri için yasal ve zorunludur.

KVKK'nın Temel Gereksinimleri

Açık Rıza: Tüm kişisel veri işlemesi için müşterinin yazılı rızası alınmalıdır. Bir gizlilik politikası yayınlanmalı ve müşteriler bu politikayı onaylamış olmalıdır.

Veri Güvenliği: Veriler, AES-256 şifrelemesi gibi güvenli yöntemlerle korunmalıdır. Role-based access control (RBAC) uygulanmalı ve sistem real-time olarak izlenmelidir. Günlük encrypted backup yapılmalıdır.

Veri Minimizasyonu: Sadece işletme için gerekli olan veriler toplanmalıdır. Saklanan veriler, belirtilen amaç için kullanılmalı ve bu amaç bittiğinde veya müşteri talebinde silinmelidir.

Kullanıcı Hakları: Müşteriler, kendi verilerine erişme, hataları düzeltme, silinme talebinde bulunma ve işlemeye itiraz etme haklarına sahiptir.

İhlal Bildirim: Bir veri ihlali oluşursa, 72 saat içinde tespit edilmeli, etkilenen müşteriler ve KVKK Kurul'u haberdar edilmelidir.

Veri Silme Uygulaması

Müşteri silme talebinde bulunduğunda, yalnızca aktif sistemler değil, tüm backup'lardan da verileri silmek veya anonimleştirmek gerekir. İsim, soyadı ve email gibi tanımlayıcı bilgiler silinir, ancak işlemsel gereklilikler için anonim veriler kalabilir.

Denetim Günlükleri ve İzleme

Tüm veri işlemeleri kaydedilmelidir. Veri ihlali oluştuğunda veya şüphe ortaya çıktığında, kimin neyi, ne zaman yaptığını bulmak kritiktir. Bir denetim günlüğü, tüm create, read, update ve delete işlemlerini kaydeder, IP adresi ve user agent bilgilerini içerir ve tenant bazında indexlenir. Bu günlükler, güvenlik olayları analiz ediliyor, uyum denetimleri gerçekleştiriliyken ve iç soruşturmalar yapılırken incelenmiştir.

Yaygın Saldırı Türlerine Karşı Koruma

SQL Injection: Hiçbir zaman dinamik SQL sorguları yazılmamalıdır. Bunun yerine, ORM çerçeveleri veya parameterized queries kullanılmalıdır. Bu, veritabanını istenmeyen komutlardan korur.

Cross-Site Scripting (XSS): Kullanıcı girdisinden kaynaklanan HTML content otomatik olarak escaped edilmelidir. Django gibi çerçeveler, şablonlarda bunu otomatik olarak yapar.

Cross-Site Request Forgery (CSRF): Web formlarında, CSRF token adlı gizli bir token bulunmalıdır. Bu token, form gönderildiğinde doğrulanır ve yetkisiz işlemleri engeller.

Güvenlik Kontrol Listesi

Kontrol	Açıklama
Veri İzolasyonu	Tenant'lar kesinlikle ayrı, veritabanı seviyesinde izolasyon
Şifreleme	HTTPS (transit) ve at-rest şifrelemesi
KVKK Uyumu	Türk mevzuat gerekliliklerinin karşılanması
Çok Faktörlü Kimlik Doğrulama	MFA desteği kritik işlemler için
Denetim Günlükleri	Tüm veri işlemeleri kaydedilmiş
Düzenli Testler	Penetration testing yılda en az bir kez
İhlal Yanıt Planı	Veri ihlali durumunda açık prosedürler

Sıkça Sorulan Sorular

Veri İzolasyonu Başarısız Olabilir mi?
Evet, ancak bu nadir görülür. Teknikler doğru uygulandığında, risik minimum seviyeye indirgenir. Test ortamında RLS testleri yapılmalı, kod incelemelerde izolasyon kontrolleri gözden geçirilmeli, ve üretim ortamında izleme yapılmalıdır.

KVKK Cezası Nedir?
İhlal durumunda, 10 milyon TL'ye kadar para cezası söz konusu olabilir. Kurum yöneticilerine kişisel sorumluluk yüklenir ve işletme kapatılması riski ortaya çıkabilir.

Şifreleme Anahtarı Nerede Tutulmalı?
Hiçbir zaman kaynak kodunda. AWS KMS, Azure Key Vault veya HashiCorp Vault gibi hardware security module (HSM) hizmetleri kullanılmalıdır.

Penetration Testing Ne Sıklıkta Yapılmalı?
Minimum yılda bir. Büyük SaaS şirketleri, üç ayda bir yapabilir.

Veri İhlali Durumunda Ne Yapmalı?
İlk olarak tespit etmeli (72 saat içinde), etkilenen müşterileri bilgilendirmeli, KVKK Kurul'una rapor etmeli, forenzik analiz yapmalı ve güvenlik açığını kapatmalısınız.

Backup'lar Şifreli Olmalı mı?
Evet. Backup'lar, şifreli olmalı ve üretim ortamından farklı bir konumda tutulmalıdır.

Üçüncü Taraf Satıcı Güvenliği Nedir?
Ödeme işlemcileri, hosting sağlayıcıları ve diğer üçüncü taraf satıcıların güvenlik standartlarını gözden geçirmelisiniz.

Open Source Kütüphaneleri Güvenli mi?
Bağımlılıklar düzenli olarak (npm audit, pip-audit gibi araçlarla) taranmalı ve bilinen güvenlik açıkları izlenmelidir.

---

Veri güvenliği, SaaS başarısının temelini oluşturur. Müşterileriniz, verilerinin güvenli olduğuna güvenmelidir. Smart Maple, bu güvenlik standartlarını sağlamak için tasarlanmış bir SaaS çözümüdür. Daha fazla bilgi için smart-maple.com adresini ziyaret edin.