SaaS Uygulamalarında Veri İzolasyonu ve Güvenlik Standartları

Bir SaaS ürünü büyümeye başladığında en kritik sorulardan biri şudur: Bir müşterinin verisinin başka bir müşteriye ulaşamayacağını gerçekten garanti edebiliyor musunuz? SaaS Uygulamalarında Veri İzolasyonu ve Güvenlik Standartları konusu tam olarak bu sorunun teknik, operasyonel ve yönetişim tarafını kapsar.

On yıllık yazılım ve güvenlik pratiğinde gördüğüm en önemli nokta şu oldu: Güvenli multi tenant yapı yalnızca veritabanına tenant_id eklemekle kurulmaz. Kimlik doğrulama, yetkilendirme, cache, dosya depolama, background job, loglama, şifreleme, yedekleme ve destek erişimi aynı tenant sınırına uymalıdır.

Bu rehberde SaaS uygulamalarında veri izolasyonu nasıl sağlanır, multi-tenant SaaS güvenlik mimarisi nasıl tasarlanır, SaaS veri izolasyonunda shared database schema per tenant ve database per tenant karşılaştırması nasıl yapılır ve SaaS uygulamalarında tenant isolation RBAC encryption ve row level security standartları nasıl birlikte ele alınır sorularını pratik örneklerle açıklayacağız.

SaaS Uygulamalarında Veri İzolasyonu Nedir?

Veri izolasyonu, her müşterinin yalnızca kendi hesabına ve kendi kaynaklarına ait verilere erişebilmesini sağlayan mimari sınırdır. Bu sınır yalnızca uygulama kodunda değil, mümkün olduğunda altyapı ve veri katmanında da uygulanmalıdır.

Tenant Nedir?

Tenant, SaaS sistemi içinde bağımsız müşteri alanını temsil eder. Bir şirket, ekip, kurum veya organizasyon tek bir tenant olarak modellenebilir.

Multi-Tenant SaaS Nedir?

Multi tenant SaaS, bir uygulama altyapısının birden fazla müşteriye hizmet verdiği modeldir. Kaynaklar paylaşılabilir fakat müşteri verilerinin ve yetkilerinin birbirine karışmaması gerekir.

Tenant Isolation Ne Anlama Gelir?

Tenant isolation, kullanıcının doğrulanmış tenant sınırının dışındaki verilere okuma, yazma, silme veya yönetim erişimi elde edememesi anlamına gelir.

Data Isolation ile Data Segregation Aynı Şey mi?

Birbirine yakın kavramlardır fakat tamamen aynı anlamda kullanılmaları doğru değildir. Data segregation çoğunlukla verinin fiziksel veya mantıksal olarak ayrılmasını ifade ederken isolation erişim sınırlarının zorunlu biçimde korunmasını da kapsar.

Tenant Isolation Neden SaaS Güvenliğinin Temelidir?

Çünkü tek bir authorization hatası yüzlerce müşterinin verisini etkileyebilir. İyi tasarlanmış tenant sınırı bu etkinin yayılmasını engeller.

Authentication, Authorization ve Tenant Isolation Arasındaki Fark

Bu üç kavram aynı güvenlik zincirinin parçalarıdır fakat farklı sorulara cevap verir.

Authentication: Kullanıcı Kim?

Authentication kullanıcının kimliğini doğrular. Parola, passkey, SSO veya MFA bu katmanda devreye girer.

Authorization: Kullanıcı Ne Yapabilir?

Authorization, doğrulanmış kullanıcının hangi işlemleri gerçekleştirebileceğini belirler. Örneğin bir kullanıcı rapor okuyabilir fakat fatura ayarlarını değiştiremeyebilir.

Tenant Isolation: Hangi Müşterinin Kaynaklarına Erişebilir?

Tenant isolation ise kullanıcının hangi müşteri alanındaki kaynaklara erişebileceğini sınırlar. Yönetici olmak başka tenant verisine erişme hakkı vermemelidir.

Authentication Başarılı Olsa Bile Cross-Tenant Leak Nasıl Oluşur?

Bir kullanıcı doğru biçimde giriş yapmış olabilir ancak API yalnızca resource ID kontrol edip tenant sahipliğini doğrulamazsa başka müşterinin kaydına erişebilir. Bu nedenle doğrulanmış kimlik tek başına yeterli değildir.

SaaS Tenant Threat Model Nasıl Oluşturulur?

Threat model oluştururken yalnızca dış saldırganı düşünmek eksik kalır. Kullanıcılar, servis hesapları, çalışan erişimleri ve yanlış yapılandırmalar da aynı modelin parçasıdır.

Cross-Tenant Read

Bir tenant kullanıcısının başka tenant verisini okuyabilmesi en temel veri sızıntısı senaryolarından biridir.

Cross-Tenant Write

Başka tenant kaydını değiştirme yeteneği veri bütünlüğünü bozar ve daha büyük operasyonel zarar doğurabilir.

Cross-Tenant Delete

Silme endpointleri tenant sahipliğini doğrulamıyorsa saldırgan farklı müşterilere ait kayıtları kalıcı olarak etkileyebilir.

Privilege Escalation

Kullanıcının kendisine verilmemiş bir role veya yönetim yetkisine ulaşması privilege escalation olarak değerlendirilir.

Broken Object Level Authorization

API'nin yalnızca nesne kimliğine bakıp kullanıcının o nesne üzerindeki yetkisini doğrulamaması ciddi bir erişim kontrolü açığı oluşturur.

Noisy Neighbor

Bir müşterinin aşırı kaynak tüketimi diğer müşterilerin performansını etkileyebilir. Tenant güvenliği bu nedenle yalnızca gizlilik değil erişilebilirlik meselesidir.

Insider Access

Destek veya mühendislik personelinin gereğinden geniş production erişimine sahip olması ayrı bir risk alanıdır.

Compromised Service Account

Ele geçirilmiş servis hesabının bütün tenantlara erişebilmesi olayın etki alanını büyütür. Servis yetkileri mümkün olduğunca sınırlandırılmalıdır.

Misconfigured Infrastructure

Yanlış IAM politikası, public bucket veya geniş network erişimi uygulama katmanındaki güvenlik önlemlerini etkisiz hale getirebilir.

Tenant Context Güvenli Şekilde Nasıl Belirlenir?

Tenant bilgisi sunucu tarafından güvenilir bir kimlik bağlamından çıkarılmalıdır. Kullanıcının isteğe eklediği keyfi bir değer otorite kaynağı olmamalıdır.

Verified JWT Claim

JWT içindeki tenant bilgisi yalnızca token imzası, issuer, audience ve süre kontrolleri başarıyla doğrulandıktan sonra kullanılmalıdır.

Session

Server side session modeli kullanılıyorsa aktif tenant bilgisi doğrulanmış kullanıcı üyeliği ile ilişkilendirilmelidir.

API Key

API key doğrudan tenant veya izin kümesiyle ilişkilendirilebilir. İstek sırasında tenantın ayrıca client tarafından belirtilmesine ihtiyaç bırakmamak daha güvenlidir.

Subdomain

firma.example.com gibi bir yapı tenant keşfi için kullanılabilir ancak subdomain tek başına authorization kanıtı değildir.

Custom Domain

Özel domain kullanan tenantlarda domain sahipliği doğrulanmalı ve domain tenant eşlemesi sunucu tarafında tutulmalıdır.

Tenant Context Neden Client Parametresinden Alınmamalı?

Çünkü client kontrolündeki tenant_id kolayca değiştirilebilir. Güvenli sistem bu değeri kullanıcının doğrulanmış üyeliklerinden türetir.

Request Başında Tenant Context’i Zorunlu Hale Getirmek

Tenant gerektiren endpointlerde request pipeline başında tenant context oluşturulmalı, context yoksa işlem uygulama servisine ulaşmadan reddedilmelidir.

API güvenlik katmanlarının merkezi yönetimi konusunda ek bir teknik yaklaşım için https://www.diyarbakiryazilim.com.tr/posts/kurum-ici-uygulamalarda-api-gateway-entegrasyonu adresindeki içeriği de inceleyebilirsiniz.

Kullanıcı Birden Fazla Tenant’a Üyeyse Ne Olur?

Bir kullanıcının birden çok şirkette çalışması veya farklı çalışma alanlarına katılması oldukça yaygındır. Bu durumda global kullanıcı kimliği ile aktif tenant ayrılmalıdır.

Global User Identity

Kullanıcının temel hesabı tek olabilir. Tenant üyelikleri bu global kimliğe bağlı ayrı kayıtlar olarak tutulabilir.

Tenant Membership

Membership kaydı kullanıcı, tenant ve rol ilişkisini açıkça tanımlar.

Active Tenant

Her işlem hangi tenant bağlamında gerçekleştirildiğini bilmelidir. Active tenant belirsiz bırakılmamalıdır.

Tenant Switching

Tenant değiştirme işlemi yalnızca kullanıcının doğrulanmış üyelikleri arasında gerçekleşmelidir.

Tenant Değişince Session/Token Yenilemek

Aktif tenant token içinde taşınıyorsa tenant değişiminde yeni token oluşturmak bağlamı daha belirgin hale getirir.

Stale Permission Problemi

Kullanıcının rolü değiştiğinde eski token veya cache kaydı önceki yetkileri taşımaya devam edebilir. Kısa token ömrü ve uygun invalidation mekanizması bu riski azaltır.

SaaS Veri İzolasyonu Modelleri

Tek bir izolasyon modeli bütün SaaS ürünleri için doğru değildir. Maliyet, müşteri sayısı, regülasyonlar ve kurumsal sözleşmeler seçimi etkiler.

Silo Model

Silo modelinde tenantlar diğer müşterilerden daha belirgin altyapı sınırlarıyla ayrılır.

Dedicated Infrastructure

Tenant için ayrı compute, network veya diğer altyapı bileşenleri kullanılabilir.

Dedicated Database

Her tenantın ayrı veritabanına sahip olması veri ve operasyon sınırını güçlendirir.

Pool Model

Pool modeli kaynakların müşteriler arasında paylaşılmasıyla daha yüksek operasyonel verim hedefler.

Shared Runtime

Aynı uygulama instance'ları birden fazla tenant isteğini işleyebilir. Bu durumda request context güvenliği kritik hale gelir.

Shared Database

Aynı veritabanı ve tablolar kullanılabilir. Her kaydın tenant sahipliği açıkça belirlenmelidir.

Bridge / Hybrid Model

Hybrid model farklı müşteri sınıflarına farklı izolasyon seviyeleri sunar.

Shared Standard Tenants

Standart paket müşterileri ortak altyapıda çalıştırılabilir.

Dedicated Enterprise Tenants

Kurumsal müşteriler sözleşme veya risk gereksinimleri nedeniyle ayrı database veya altyapıya taşınabilir.

Hangi Model Ne Zaman Kullanılmalı?

Erken aşamadaki yüksek tenant sayılı ürünlerde pool modeli ekonomik olabilir. Yüksek güvenlik beklentisi, veri yerleşimi veya müşteri sözleşmeleri arttığında hybrid ya da silo modeli daha uygun hale gelebilir.

Shared Database + Shared Schema Modeli

Bu model ölçeklenebilir SaaS sistemlerinde sık görülür. Güvenlik başarısı veritabanı kısıtları ve uygulama kontrollerinin birlikte çalışmasına bağlıdır.

tenant_id Kolonu

Tenant sahipliği bulunan her tabloda tenant_id değerinin açıkça bulunması veri sınırını görünür hale getirir.

Avantajları

Provisioning, migration ve kaynak kullanımı daha kolay yönetilebilir. Çok sayıda küçük tenant için maliyet avantajı sağlayabilir.

Cross-Tenant Query Riski

Bir sorguda tenant filtresinin unutulması veri sızıntısına yol açabilir. Bu yüzden yalnızca geliştiricinin filtre eklemesine güvenilmemelidir.

Composite Index

tenant_id ile sık sorgulanan alanların birlikte indexlenmesi hem performans hem sorgu düzeni açısından yararlıdır.

Tenant-Aware Unique Constraints

Kullanıcı adı veya proje kodu gibi alanlar tenant içinde benzersiz olacaksa unique constraint tenant bilgisini de içermelidir.

Foreign Key’leri Tenant-Safe Tasarlamak

İlişkili tabloların farklı tenant kayıtlarını yanlışlıkla bağlamasını engellemek için foreign key tasarımı tenant sahipliğini de dikkate almalıdır.

PostgreSQL Row-Level Security ile Tenant Isolation

PostgreSQL RLS uygulama filtresine ek olarak database seviyesinde bir güvenlik bariyeri sağlar.

RLS Nedir?

Row-Level Security, kullanıcının veya session bağlamının hangi satırları görebileceğini ve değiştirebileceğini policy ile sınırlar.

RLS Policy Nasıl Çalışır?

Policy, sorgudaki satırların belirli bir koşula uygun olup olmadığını database seviyesinde değerlendirir.

Tenant Context Database’e Nasıl Aktarılır?

Tenant bilgisi güvenilir request context'ten alınmalı ve transaction kapsamında database connection'a aktarılmalıdır.

SELECT Policy

SELECT policy yalnızca aktif tenant ile eşleşen kayıtların okunmasına izin vermelidir.

INSERT / UPDATE / DELETE Policy

Yazma işlemleri hem erişilen satırın hem de oluşturulan yeni değerin doğru tenant sınırında kalmasını doğrulamalıdır.

FORCE ROW LEVEL SECURITY

Uygun senaryolarda tablo sahibinin de policy sınırlarına uymasını sağlamak savunmayı güçlendirebilir.

RLS Testleri

Tenant A oturumu ile Tenant B kayıtlarının okunamadığını, değiştirilemediğini ve silinemediğini otomatik testlerle doğrulamak gerekir.

PostgreSQL RLS Kullanırken Yapılan Kritik Hatalar

RLS güçlüdür fakat yanlış connection modeli kullanıldığında beklenen koruma devre dışı kalabilir.

Superuser ile Application Connection

Uygulamayı superuser rolüyle çalıştırmak gereksiz yetki oluşturur ve RLS korumasını zayıflatabilir.

BYPASSRLS Yetkisi

Runtime rolünde BYPASSRLS bulunmamalıdır.

Connection Pool Tenant Leakage

Bir tenant için connection üzerinde bırakılan session state başka request'e taşınırsa cross tenant veri erişimi oluşabilir.

Session-Level Context’in Yanlış Kullanılması

Pool kullanılan sistemlerde uzun ömürlü session değişkenleri dikkatli yönetilmezse tenant context kalıntısı bırakabilir.

Transaction Başına Tenant Context

Tenant bilgisini transaction başlangıcında ayarlayıp transaction sonunda temizlenen bağlam kullanmak daha güvenli bir yaklaşım sağlar.

Background Worker’larda Eksik Tenant Context

Worker uygulamaları web request'i almadığı için tenant context ayrıca ve güvenilir şekilde kurulmalıdır.

Migration User ile Runtime User’ı Ayırmamak

Schema değiştiren güçlü database hesabı ile günlük uygulama hesabının ayrı tutulması gereksiz yetkileri azaltır.

Schema per Tenant

Schema per tenant modelinde her müşterinin tabloları aynı database içinde farklı schema altında bulunur.

Avantajları

Tenant verisi daha görünür sınırlarla ayrılır ve bazı tenant odaklı bakım işlemleri kolaylaşabilir.

Migration Complexity

Her schema'nın aynı sürümde kalmasını sağlamak için migration süreçleri merkezi olarak yönetilmelidir.

Schema Provisioning

Yeni tenant açılışında schema oluşturma, izin verme ve migration uygulama süreci otomatik olmalıdır.

Cross-Tenant Analytics

Tenantlar arası toplu analiz, shared schema modeline göre daha fazla veri birleştirme işi gerektirebilir.

Backup ve Restore

Tek database yedeğinden yalnızca belirli tenantı geri getirme gereksinimi önceden test edilmelidir.

Kaç Tenant’a Kadar Yönetilebilir?

Tek bir evrensel sayı yoktur. Database engine, migration süresi, schema sayısı ve operasyon otomasyonu birlikte değerlendirilmelidir.

Database per Tenant

Database per tenant modeli her müşteriye bağımsız database sunar ve güçlü operasyon sınırları sağlayabilir.

Güçlü Isolation

Yanlış bir tenant sorgusunun başka database içindeki müşteri verisine ulaşması doğal olarak daha zordur.

Independent Backup ve Restore

Tek müşteriye ait yedekleme ve geri dönüş operasyonları daha kolay ayrıştırılabilir.

Per-Tenant Encryption

Tenant başına farklı key kullanma yaklaşımı database sınırıyla birlikte daha kolay modellenebilir.

Connection Management

Çok sayıda database bulunduğunda connection pool ve routing katmanı dikkatli tasarlanmalıdır.

Migration Orchestration

Schema değişikliklerinin yüzlerce veya binlerce database üzerinde güvenli sırayla uygulanması gerekir.

Operational Cost

Daha fazla database daha fazla izleme, yedekleme, bağlantı ve bakım maliyeti anlamına gelebilir.

Enterprise Tenant’lar İçin Kullanım

Yüksek izolasyon beklentisi bulunan kurumsal müşteriler için dedicated database güçlü bir seçenek olabilir.

Hybrid Tenant Isolation Modeli

Hybrid yaklaşım ürün büyüdükçe farklı müşteri gruplarına farklı izolasyon seviyeleri vermeyi kolaylaştırır.

Standard Tenant’ları Pool’da Tutmak

Yüksek sayıda standart müşteriyi ortak altyapıda tutmak kaynak kullanımını verimli hale getirebilir.

Enterprise Tenant’ı Dedicated Ortama Taşımak

Sözleşme, performans veya veri yerleşimi gereksinimi doğduğunda belirli tenant bağımsız ortama alınabilir.

Tenant Placement Directory

Merkezi bir directory her tenantın hangi database, cell veya region içinde çalıştığını kayıt altında tutabilir.

Runtime Routing

Uygulama, doğrulanmış tenant kimliğini kullanarak doğru veri kaynağına yönlenmelidir.

Aynı Codebase’i Korumak

Pool ve dedicated tenantların aynı uygulama kodunu kullanması operasyon yükünü azaltabilir.

Pool → Silo Migration

Taşıma süreci veri kopyalama, doğrulama, geçici yazma stratejisi ve routing cutover adımlarını içermelidir.

Cell-Based SaaS Architecture

Cell based mimari büyük SaaS platformlarında hata ve yük etkisini belirli tenant gruplarıyla sınırlandırmak için kullanılabilir.

Cell Nedir?

Cell, kendi compute ve data kaynaklarına sahip bağımsız bir uygulama dilimi olarak düşünülebilir.

Tenant’ları Cell’lere Dağıtmak

Tenantlar kapasite, bölge veya müşteri sınıfına göre farklı cell'lere atanabilir.

Blast Radius Azaltmak

Tek cell'deki hata yalnızca o cell içinde bulunan müşterileri etkilerse olayın kapsamı küçülür.

Cell Failure

Cell erişilemez olduğunda hangi servislerin ve tenantların etkilendiği hızla belirlenebilmelidir.

Cell Rebalancing

Kapasite dengesizliği oluştuğunda tenantların başka cell'e taşınabileceği operasyon modeli hazırlanmalıdır.

Regional Cells

Bölgesel cell yapısı veri yerleşimi ve gecikme hedeflerini aynı anda destekleyebilir.

Tenant-Aware Authorization

Authorization kararı rol kadar tenant bağlamını da değerlendirmelidir.

RBAC

RBAC, kullanıcıların roller üzerinden izin kazanmasını sağlar.

Global Role Definitions

Admin, editor ve viewer gibi rol tanımları sistem genelinde ortak tutulabilir.

Tenant-Scoped Assignments

Rol ataması tenant seviyesinde yapılmalıdır. Bir tenantta admin olan kişi başka tenantta viewer olabilir.

ABAC

ABAC karar verirken rolün yanında kullanıcı, kaynak ve ortam özelliklerini de değerlendirebilir.

Tenant

Tenant kimliği authorization kararının temel attribute'larından biri olmalıdır.

Resource

Kaynağın sahibi, türü ve hassasiyet seviyesi karar sürecine dahil edilebilir.

Environment Attributes

IP, cihaz durumu veya oturum güven seviyesi gibi ek bilgiler daha hassas işlemler için kullanılabilir.

ReBAC / Fine-Grained Authorization

Kaynaklar arasındaki sahiplik ve üyelik ilişkilerinin karmaşık olduğu ürünlerde ilişki tabanlı izin modelleri yararlı olabilir.

Authorization Decision Her Zaman Tenant-Scoped Olmalı

canEditProject(user, project) kontrolü yalnızca rolü değil, kullanıcının projenin tenantına üyeliğini de doğrulamalıdır.

Enterprise SSO ve Tenant Isolation

Kurumsal kimlik sağlayıcı entegrasyonları tenant sınırının identity katmanına kadar taşınmasını gerektirir.

SAML

SAML entegrasyonu tenant bazında metadata, certificate ve domain eşleşmeleriyle yönetilebilir.

OIDC

OIDC entegrasyonunda issuer, client ve claim kontrolleri tenant yapılandırmasıyla ilişkilendirilmelidir.

Tenant-Specific Identity Provider

Her kurumsal tenant kendi identity provider yapılandırmasına sahip olabilir.

Domain Verification

Bir şirket domaininin tenantla ilişkilendirilmesinden önce domain sahipliği doğrulanmalıdır.

SSO-Only Tenants

Bazı kurumlar parola girişini tamamen kapatıp yalnızca kurumsal SSO kullanımını zorunlu kılabilir.

Tenant-Specific MFA Policy

Tenant güvenlik politikası belirli kullanıcı grupları için MFA zorunluluğu getirebilir.

SCIM / Directory Sync

SCIM kullanıcı ekleme ve çıkarma işlemlerini otomatikleştirirken tenant üyeliği doğru sınırda güncellenmelidir.

Object Storage’da Tenant Isolation

Database güvenli olsa bile dosya depolama katmanı yanlış tasarlanırsa müşteri dosyaları sızabilir.

Bucket per Tenant

Yüksek izolasyon istenen müşteriler için ayrı bucket kullanılabilir.

Prefix per Tenant

Shared bucket modelinde object key'ler tenant bazlı prefix ile ayrılabilir.

Tenant-Aware IAM Policy

IAM politikası servislerin yalnızca gereken tenant alanına erişmesini sağlamalıdır.

Signed URL

Signed URL yalnızca authorization kontrolünden sonra ve kısa süreli olarak üretilmelidir.

Upload Authorization

Dosya yükleme izni de indirme kadar önemlidir. Kullanıcının hedef tenant için yazma yetkisi doğrulanmalıdır.

File Metadata’da Tenant Ownership

Object key dışında metadata veya uygulama database'i içinde tenant sahipliği tutulması ek doğrulama sağlar.

Cross-Tenant File Enumeration’ı Engellemek

Tahmin edilebilir dosya yolları authorization yerine kullanılmamalıdır. Her dosya isteğinde sahiplik kontrolü yapılmalıdır.

Cache Sistemlerinde Tenant Isolation

Cache katmanı çoğu veri sızıntısında gözden kaçan alanlardan biridir.

Cache Key’e Tenant ID Eklemek

tenant:123:user:456 gibi tenant aware key üretmek farklı müşterilerin cache kayıtlarını ayırır.

Redis

Redis kullanılırken key namespace, ACL ve erişim modelleri tenant sınırı düşünülerek tasarlanmalıdır.

Authorization Cache

Yetki sonuçları cache'leniyorsa tenant kimliği cache anahtarının parçası olmalıdır.

CDN Cache

Tenant bazlı private içerik CDN üzerinde yanlış cache key nedeniyle başka kullanıcıya sunulmamalıdır.

Stale Permission

Rol değişiminden sonra cache eski authorization sonucunu taşımaya devam etmemelidir.

Cache Poisoning

Kullanıcı kontrollü değerlerin cache varyasyonunu manipüle ederek başka tenant sonucunu oluşturmasına izin verilmemelidir.

Tenant Değişiminde Cache Invalidation

Aktif tenant değiştiğinde kullanıcıya özel cache bağlamı yeniden oluşturulmalıdır.

Background Job ve Queue Sistemlerinde Tenant Isolation

Asenkron sistemlerde web request context'i olmadığı için tenant bilgisinin kaybolması sık görülen bir problemdir.

Job Payload’a Trusted Tenant Context

Job oluşturulurken tenant kimliği doğrulanmış server side context üzerinden payload'a eklenmelidir.

Queue per Tenant

Yüksek izolasyon gereken müşteriler için ayrı queue kullanılabilir.

Shared Queue + Tenant Context

Shared queue modelinde her mesaj açık ve doğrulanabilir tenant bilgisi taşımalıdır.

Retry

Retry edilen job aynı tenant bağlamını korumalıdır.

Dead Letter Queue

DLQ mesajları incelenirken tenant bilgisi korunmalı ve hassas payloadların erişimi sınırlandırılmalıdır.

Scheduled Jobs

Zamanlanmış görevler hangi tenant için çalıştığını açıkça belirlemelidir.

Tenant Context Kaybını Engellemek

Worker katmanında tenant bilgisi yoksa işlemi devam ettirmek yerine hata üretmek daha güvenlidir.

Search Engine ve Analytics Sistemlerinde Veri İzolasyonu

Uygulama database'i kadar arama ve raporlama sistemlerinin de tenant aware olması gerekir.

Elasticsearch / OpenSearch

Dokümanların tenant sahipliği index tasarımında açıkça korunmalıdır.

Tenant-Aware Index

Index şeması ve sorgular tenant sınırını zorunlu olarak değerlendirmelidir.

Index per Tenant

Yüksek izolasyon veya büyük tenantlar için ayrı index kullanılabilir.

Shared Index

Shared index kullanılıyorsa her dokümanda tenant alanı bulunmalı ve server side filtre zorunlu olmalıdır.

Data Warehouse

Warehouse ortamına taşınan müşteri verisi de tenant kimliğini kaybetmemelidir.

BI Dashboards

Dashboard filtreleri yalnızca arayüz kontrolü olmamalı, veri erişimi backend seviyesinde sınırlandırılmalıdır.

Cross-Tenant Aggregate Data

Anonim ve toplu metriklerin kullanılacağı durumlarda yeniden tanımlama riski ve sözleşme şartları değerlendirilmelidir.

Vector Database ve AI Sistemlerinde Tenant Isolation

RAG ve agent tabanlı sistemler yeni veri yolları oluşturduğu için tenant sınırı bu bileşenlerde yeniden uygulanmalıdır.

Vector Namespace

Tenant başına namespace kullanmak retrieval alanını ayırmanın pratik yollarından biridir.

Tenant Metadata Filtering

Shared vector index kullanılıyorsa doğrulanmış tenant metadata filtresi server side eklenmelidir.

RAG Retrieval Isolation

LLM'e gönderilecek belgeler seçilmeden önce retrieval sonucu tenant sahipliği açısından doğrulanmalıdır.

Prompt Context Leakage

Başka tenant verisinin prompt context'e girmesi doğrudan veri sızıntısıdır. Prompt katmanı güvenlik bariyeri olarak görülmemelidir.

AI Agent Tool Permissions

Agent'ın çağırabildiği araçlar ve veri kaynakları kullanıcının gerçek authorization bağlamıyla sınırlandırılmalıdır.

Modelin Tenant ID Seçmesine Neden İzin Verilmemeli?

Model çıktısı güvenilir kimlik kaynağı değildir. Tenant kimliği uygulama sunucusu tarafından belirlenmelidir.

Auth Context’i Tool Invocation’a Server-Side Aktarmak

Tool çağrısında tenant ve kullanıcı bilgisi doğrulanmış session üzerinden otomatik eklenmelidir.

SaaS’ta Encryption Hangi Problemi Çözer?

Encryption verinin okunabilirliğini sınırlar fakat authorization hatasını tek başına çözmez.

Encryption in Transit

TLS istemci, servis ve database arasındaki ağ trafiğinin korunmasına yardımcı olur.

Encryption at Rest

Disk, volume, object storage ve backup verilerinin depolama ortamında şifreli tutulmasını sağlar.

Application-Level Encryption

Özellikle hassas alanlar uygulama seviyesinde ayrı anahtarlarla şifrelenebilir.

Logical Isolation ile Cryptographic Isolation Arasındaki Fark

Logical isolation erişim kurallarıyla ayrım yapar. Cryptographic isolation ise farklı key sınırları sayesinde verinin çözülmesini ayrıca sınırlar.

Tenant-Scoped Cryptographic Isolation

Yüksek güvenlik gerektiren ürünlerde tenant başına ayrı anahtar sınırı ek savunma sağlar.

Tenant Başına Key Boundary

Her tenant için ayrı KEK veya benzer key hiyerarşisi kullanılabilir.

Blast Radius

Bir key'in etkilenmesi halinde yalnızca o key ile korunan veri etkilenirse olayın kapsamı azalır.

Bir Tenant’ın Key’i Ele Geçerse Ne Olur?

Doğru sınırlandırılmış mimaride diğer tenantların key'leri bağımsız kalır.

Diğer Tenant’ları Cryptographic Olarak Korumak

Key yönetim sistemi, erişim politikaları ve audit kayıtları tenant sınırlarıyla uyumlu olmalıdır.

Envelope Encryption Nasıl Çalışır?

Envelope encryption veri anahtarları ile ana anahtarların görevini ayırır.

Data Encryption Key — DEK

DEK gerçek veriyi şifrelemek için kullanılan anahtardır.

Key Encryption Key — KEK

KEK, DEK'i korumak için kullanılır ve çoğunlukla merkezi key management sistemi içinde tutulur.

Per-Object DEK

Her obje veya veri grubu için ayrı DEK kullanmak etki alanını küçültebilir.

Per-Tenant KEK

Tenant başına KEK kullanımı müşteri sınırlarını cryptographic düzeyde güçlendirebilir.

Key Rotation

Anahtarların belirli politika doğrultusunda yenilenebilmesi ve eski versiyonların güvenli yönetilmesi gerekir.

Re-Encryption Maliyeti

Envelope modelinde yalnızca DEK'i yeniden sarmak bazı senaryolarda bütün veriyi yeniden şifrelemekten daha verimli olabilir.

BYOK, HYOK ve External Key Management

Kurumsal müşteriler anahtar yönetimi üzerinde daha yüksek kontrol talep edebilir.

BYOK Nedir?

BYOK, müşterinin kendi oluşturduğu veya yönettiği key materyalini hizmet sağlayıcı ortamına getirdiği modeli ifade eder.

Customer-Managed Key

Müşteri tarafından yönetilen anahtarlar erişim ve rotation politikasında müşteriye daha fazla kontrol verebilir.

External Key Management

Anahtarın farklı bir key management ortamında tutulması daha güçlü kontrol gereksinimlerini karşılayabilir.

Enterprise Müşteri Talepleri

BYOK veya key revocation talepleri özellikle büyük kurumlarla yapılan sözleşmelerde gündeme gelebilir.

Tenant Offboarding

Müşteri ayrıldığında key erişimi, veri silme ve backup lifecycle süreçleri birlikte yürütülmelidir.

Key Revocation

Key erişiminin iptal edilmesi veriye erişimi hızla durdurabilecek güçlü bir kontrol olabilir.

Crypto-Shredding

Uygun mimaride anahtarın kalıcı olarak yok edilmesi şifreli verinin pratik olarak okunamaz hale gelmesini sağlayabilir.

Backup’larda Tenant Isolation

Backup ortamı production kadar hassas kabul edilmelidir.

Backup Encryption

Yedekler aktarım sırasında ve depolamada şifrelenmelidir.

Tenant-Specific Restore

Tek tenant verisinin diğer müşterileri etkilemeden geri getirilebilmesi tasarım aşamasında düşünülmelidir.

Point-in-Time Recovery

PITR kabiliyeti veri kaybını azaltır ancak tenant bazlı geri dönüş senaryoları ayrıca test edilmelidir.

Backup Retention

Retention süresi sözleşme, regülasyon ve operasyon ihtiyacına göre belirlenmelidir.

Offboarding Sonrası Veri

Müşteri silindiğinde backup içindeki verinin ne kadar süre tutulacağı açık politika ile tanımlanmalıdır.

Cross-Region Backup

Başka bölgeye yedekleme yapılırken data residency şartları göz önünde bulundurulmalıdır.

SaaS Loglarında Tenant Verisi Nasıl Korunur?

Loglar hata ayıklama için değerlidir fakat yanlış tasarlanırsa ayrı bir veri sızıntısı kaynağına dönüşebilir.

Structured Tenant ID

Her log kaydında yapılandırılmış tenant kimliği bulunması olay analizini kolaylaştırır.

PII Logging’den Kaçınmak

İhtiyaç olmayan kişisel veriler loglara yazılmamalıdır.

Token ve Secret Redaction

Access token, API key, parola ve diğer secret değerler loglanmadan önce maskelenmelidir.

Tenant-Scoped Log Access

Müşteri log ekranı sunuluyorsa kullanıcı yalnızca kendi tenant kayıtlarına erişebilmelidir.

Retention

Logların ne kadar süre saklanacağı güvenlik ve veri minimizasyonu ihtiyaçlarına göre belirlenmelidir.

Immutable Audit Logs

Kritik yönetim işlemleri değiştirilemeyen veya değişiklikleri tespit edilebilir audit kayıtlarıyla izlenebilir.

Observability Sistemleri de Tenant-Aware Olmalı

Tenant bilgisini observability sistemine taşımak hem güvenlik olaylarını hem performans problemlerini daha hızlı teşhis etmeyi sağlar.

Logs

Loglarda tenant bilgisi kontrollü ve yapılandırılmış şekilde bulunmalıdır.

Metrics

Kaynak tüketimi ve hata oranı tenant bazında ölçülebilir.

Traces

Distributed trace verisi tenant context'i koruyarak servisler arası isteği takip edebilmelidir.

Per-Tenant SLO

Önemli müşteriler için tenant bazlı hizmet hedefleri tanımlanabilir.

Per-Tenant Error Rate

Global hata oranı normal görünürken tek müşterinin ciddi sorun yaşaması mümkündür. Tenant bazlı metrikler bunu görünür kılar.

Noisy-Neighbor Detection

CPU, query veya queue tüketimi tenant bazında izlenerek aşırı tüketim erken yakalanabilir.

Tenant Cost Attribution

Kaynak maliyetinin tenant bazında ölçülmesi fiyatlandırma ve kapasite planlamasına yardımcı olur.

Noisy Neighbor Problemi Nedir?

Noisy neighbor, tek müşterinin yoğun kaynak tüketerek paylaşılan sistemde diğer tenantların deneyimini bozmasıdır.

Database CPU

Ağır sorgular database CPU kapasitesini tüketebilir.

Connection Pool

Bir tenantın aşırı sayıda bağlantı kullanması diğer istekleri bekletebilir.

Queue Saturation

Çok sayıda job üreten tenant shared queue'yu doldurabilir.

API Consumption

Yoğun API kullanımı compute ve downstream servis kapasitesini etkileyebilir.

Storage

Kontrolsüz dosya yükleme storage maliyetini ve performansı artırabilir.

Per-Tenant Rate Limiting

Tenant bazlı rate limit ortak kapasitenin tek müşteri tarafından tüketilmesini engeller.

Resource Quotas

Depolama, API veya işlem kotaları paket bazında tanımlanabilir.

Concurrency Caps

Aynı anda çalışabilecek ağır işlemlerin tenant bazında sınırlandırılması sistem kararlılığını korur.

Support ve Engineering Ekiplerinin Production Erişimi

İç kullanıcı erişimleri müşteri erişimleri kadar kontrollü olmalıdır.

Least Privilege

Çalışan yalnızca görevi için gereken en düşük yetkiyi almalıdır.

Just-in-Time Access

Production yetkisi kalıcı olmak yerine ihtiyaç anında ve sınırlı süreyle verilebilir.

Approval

Hassas erişimler ikinci kişi veya sorumlu yönetici onayına bağlanabilir.

Break-Glass Access

Acil durum erişimi ayrı süreçle yönetilmeli ve bütün hareketler kaydedilmelidir.

Tenant-Scoped Impersonation

Destek amacıyla kullanıcı taklidi gerekiyorsa belirli tenant ve süre ile sınırlandırılmalıdır.

Session Audit

Kim, hangi tenant için, ne zaman ve hangi işlemleri yaptı sorularının cevabı kayıt altında olmalıdır.

Permanent Admin Access’tan Kaçınmak

Sürekli geniş production yetkisi yerine süreli ve gerekçeli erişim modeli tercih edilmelidir.

Dev, Test ve Staging Ortamlarında Tenant Data Güvenliği

Production dışı ortamlar güvenlik zincirinin zayıf halkası haline gelmemelidir.

Production Data’yı Teste Kopyalamamak

Gerçek müşteri verisini doğrudan staging veya geliştirici ortamına taşımak gereksiz risk oluşturur.

Anonymization

Gerçek veri kullanılması zorunluysa kişisel ve hassas alanların geri döndürülemeyecek şekilde anonimleştirilmesi değerlendirilmelidir.

Synthetic Data

Testlerin büyük bölümü gerçek müşteri verisi yerine sentetik veriyle yapılabilir.

Environment Isolation

Production ve test ortamlarının ağ, credential ve veri kaynakları ayrılmalıdır.

Developer Access

Geliştiricilerin production verisine varsayılan erişimi olmamalıdır.

Data Residency SaaS Mimarısını Nasıl Etkiler?

Müşterinin verisinin hangi ülkede veya bölgede tutulacağı data plane tasarımını doğrudan etkileyebilir.

Tenant Region

Her tenant için atanmış region bilgisinin merkezi directory içinde tutulması routing işlemini kolaylaştırır.

EU

AB müşterileri için veri yerleşimi ve uluslararası veri aktarımı gereksinimleri sözleşme ve GDPR bağlamında değerlendirilmelidir.

Türkiye

Türkiye'deki kişisel veri işleme süreçlerinde KVKK kapsamındaki yükümlülükler ve veri aktarım kuralları dikkate alınmalıdır.

ABD

ABD bölgesi farklı müşteri ve gecikme ihtiyaçlarına göre ayrı data plane olarak işletilebilir.

Region-Specific Data Plane

Müşteri verisinin işlendiği servisleri bölgesel tutmak veri yerleşimi politikasını uygulamayı kolaylaştırır.

Global Control Plane

Kimlik, tenant directory veya yönetim bilgileri global olabilir fakat hangi verinin global tutulduğu açıkça sınıflandırılmalıdır.

Cross-Region Replication

Replication yapılırken izin verilen hedef bölgeler ve şifreleme politikaları kontrol edilmelidir.

Tenant’ı Bir Bölgeden Başka Bölgeye Taşımak

Bölge taşıma işlemi yalnızca veri kopyalamak değil, tutarlılık ve routing yönetimi problemidir.

Consistent Export

Kaynak sistemden tutarlı snapshot veya export alınmalıdır.

Import

Hedef region veriyi beklenen şema ve güvenlik politikalarıyla kabul etmelidir.

Dual Write

Kesintisiz geçiş gereken bazı yapılarda kısa süreli dual write modeli değerlendirilebilir.

Read-Only Window

Daha basit yaklaşımda kısa süreli read only penceresi veri tutarlılığını koruyabilir.

Routing Cutover

Doğrulama tamamlandıktan sonra tenant directory yeni bölgeyi işaret etmelidir.

Validation

Kayıt sayıları, checksumlar, dosyalar ve kritik iş verileri kaynak ile hedef arasında karşılaştırılmalıdır.

Source Decommission

Taşıma tamamlandıktan sonra eski bölgedeki verinin retention politikasına uygun biçimde kaldırılması gerekir.

SaaS Güvenlik Standartları ve Regülasyonlar Aynı Şey mi?

Hayır. Standart, denetim, mevzuat ve sözleşme gereksinimleri farklı kavramlardır.

Security Standard

Güvenlik standardı kurumun kontrollerini belirli bir çerçevede yapılandırmasına yardımcı olur.

Certification

Certification, uygun bir standarda göre yetkili süreç kapsamında yapılan değerlendirme sonucunda verilebilir.

Attestation

Attestation belirli kontrollerin veya beyanların bağımsız inceleme sonucunda raporlanmasını ifade eder.

Regulation

Regülasyon yasal yükümlülük getirir ve uygulanabilirliği ülke, sektör ve veri türüne göre değişebilir.

Contractual Security Requirement

Müşteri sözleşmesi standartların ötesinde dedicated database, özel region veya belirli encryption modeli isteyebilir.

ISO/IEC 27001 SaaS Şirketleri İçin Ne İfade Eder?

ISO/IEC 27001 bilgi güvenliği yönetim sisteminin risk temelli ve sürekli yönetilmesini sağlayan çerçeveyi sunar.

ISMS

ISMS güvenlik politikaları, sorumluluklar, riskler ve kontrollerin sistematik biçimde yönetilmesini kapsar.

Risk Management

Tenant isolation riskleri varlık ve tehdit değerlendirmesine dahil edilmelidir.

Access Control

Kimlik, rol, production erişimi ve servis hesapları düzenli olarak gözden geçirilmelidir.

Asset Management

Database, storage, key, queue ve log sistemleri bilgi varlığı olarak envantere alınmalıdır.

Incident Management

Cross tenant veri erişimi gibi olaylar için tanımlı tespit, müdahale ve bildirim süreçleri bulunmalıdır.

Supplier Security

Cloud, identity, ödeme veya e-posta sağlayıcılarının oluşturduğu riskler değerlendirilmelidir.

Business Continuity

Backup, restore, region kaybı ve kritik servis kesintisi senaryoları iş sürekliliği planına dahil edilmelidir.

ISO/IEC 27017:2026 ve Cloud Security

ISO/IEC 27017:2026, bulut hizmetlerinin sağlanması ve kullanımı için ISO/IEC 27002 tabanlı cloud security kontrollerine yönelik güncel rehberlik sunar.

Cloud Service Provider Controls

SaaS sağlayıcısının cloud ortamında üstlenmesi gereken güvenlik sorumluluklarını daha görünür hale getirir.

Cloud Service Customer Controls

Bulut müşterisinin de kendi kullanıcıları, yapılandırmaları ve erişim politikaları açısından sorumlulukları bulunur.

Shared Responsibility

Cloud güvenliği yalnızca sağlayıcının veya müşterinin görevi değildir. Sorumlulukların açıkça paylaşılması gerekir.

Cloud-Specific Security Guidance

Cloud hizmetlerine özel riskleri standart bilgi güvenliği kontrolleriyle ilişkilendirmeye yardımcı olur.

SaaS Mimarisine Etkisi

Identity, logging, tenant isolation, infrastructure configuration ve operasyon süreçlerinin birlikte değerlendirilmesini destekler.

ISO/IEC 27018:2025 ve Cloud Privacy

ISO/IEC 27018:2025, public cloud ortamında PII processor olarak hareket eden sağlayıcıların kişisel veriyi korumasına yönelik rehberlik sağlar.

Public Cloud’da PII

Public cloud üzerinde işlenen kişisel verinin erişim, saklama ve silme süreçleri kontrollü olmalıdır.

Data Processor Sorumlulukları

SaaS sağlayıcısının veri işleyen rolü bulunduğunda müşteri talimatları ve yasal yükümlülükler doğrultusunda hareket etmesi gerekir.

Transparency

Müşterinin verisinin nasıl işlendiği ve hangi tarafların sürece dahil olduğu anlaşılır olmalıdır.

Auditability

Uygulanan kontrollerin log, kayıt ve süreçlerle doğrulanabilir olması önem taşır.

Privacy by Design

Privacy gereksinimleri ürün tamamlandıktan sonra eklenen özellikler olarak değil mimari kararların parçası olarak ele alınmalıdır.

SOC 2 SaaS Şirketleri İçin Nedir?

SOC 2, hizmet organizasyonundaki kontrollerin Trust Services Criteria kapsamında incelenmesine dayanan bir raporlama yaklaşımıdır.

SOC 2 Bir Sertifika mı?

SOC 2 yaygın kullanımda sertifika olarak adlandırılsa da teknik olarak bağımsız denetim sonucunda oluşturulan bir attestation raporudur.

Security

Security kriteri sistemlerin yetkisiz erişim ve ilgili risklere karşı korunmasına odaklanır.

Availability

Availability taahhüt edilen hizmet erişilebilirliği ve operasyonel süreklilik kontrolleriyle ilgilidir.

Processing Integrity

İşlemlerin eksiksiz, geçerli, doğru ve zamanında yürütülmesine ilişkin kontrolleri kapsar.

Confidentiality

Gizli olarak sınıflandırılan bilgilerin korunmasına yönelik kontrolleri ele alır.

Privacy

Kişisel bilgilerin toplanması, kullanılması, saklanması ve paylaşılmasıyla ilgili kontrolleri değerlendirir.

Type I ve Type II Arasındaki Fark

Type I belirli bir tarihte kontrol tasarımını değerlendirirken Type II kontrollerin belirli dönem boyunca işletilmesine ilişkin kanıtları da inceler.

Tenant Isolation Kontrollerini Audit Evidence’a Dönüştürmek

RLS testleri, access review kayıtları, deployment logları ve cross tenant negative test sonuçları denetim kanıtı olarak düzenli biçimde üretilebilir.

KVKK Açısından SaaS Veri Güvenliği

KVKK açısından kişisel verilerin hukuka aykırı işlenmesini ve erişimini önlemeye yönelik uygun teknik ve idari tedbirlerin kurulması gerekir.

Kişisel Veri Envanteri

Hangi tenantta hangi kişisel veri kategorilerinin işlendiği bilinmelidir.

Yetki Kontrolü

Kullanıcı ve çalışan erişimleri görev ve tenant kapsamına göre sınırlandırılmalıdır.

Bulut Güvenliği

Cloud servislerinin erişim, şifreleme, loglama ve yedekleme kontrolleri değerlendirilmelidir.

Veri Minimizasyonu

İş amacı için gerekmeyen kişisel veri toplanmamalı veya gereksiz süreyle tutulmamalıdır.

Logging

Güvenlik olaylarını araştırmaya yetecek kayıt tutulurken loglara gereksiz kişisel veri yazılmamalıdır.

Backup

Yedeklerde de yetki kontrolü, retention ve güvenli silme kuralları uygulanmalıdır.

Veri İşleyenlerle İlişkiler

Alt hizmet sağlayıcıların güvenlik yükümlülükleri sözleşmeler ve risk değerlendirmeleriyle yönetilmelidir.

GDPR Açısından Multi-Tenant SaaS

GDPR yalnızca database lokasyonuna indirgenemez. Veri yaşam döngüsü, erişim, silme ve aktarım süreçleri birlikte değerlendirilmelidir.

Privacy by Design and Default

Varsayılan ürün ayarları gereksiz veri paylaşımını önleyecek şekilde tasarlanmalıdır.

Data Minimization

Yalnızca işleme amacı için gerekli kişisel veri tutulmalıdır.

Integrity ve Confidentiality

Yetkisiz erişim, kayıp ve değişikliğe karşı uygun teknik ve organizasyonel tedbirler uygulanmalıdır.

Right of Access

Kullanıcının veri erişim talebi doğru tenant ve doğru kişi eşlemesiyle karşılanmalıdır.

Right to Erasure

Silme işlemi primary database dışında search, cache ve uygun lifecycle kapsamında backup verisini de dikkate almalıdır.

Data Portability

Veri export mekanizması yalnızca talepte bulunan tenantın verisini üretmelidir.

International Transfers

Verinin ülke dışına aktarılması halinde uygulanabilir hukuki mekanizmalar ve teknik kontroller ayrıca değerlendirilmelidir.

PCI DSS Ne Zaman SaaS Stack’inin Parçası Olur?

SaaS sistemi kart sahibi verisini saklıyor, işliyor veya iletiyorsa PCI DSS kapsamı gündeme gelebilir.

Cardholder Data Environment

Kart verisinin bulunduğu sistem sınırları açıkça belirlenmelidir.

Scope’u Küçültmek

Kart verisini doğrudan SaaS altyapısına almamak PCI kapsamını azaltabilir.

Payment Provider Kullanmak

Uygun ödeme sağlayıcısı kullanmak hassas kart verisinin uygulama sistemlerinden uzak tutulmasına yardımcı olabilir.

Tokenization

Kart bilgisini tekrar kullanılabilir token ile temsil etmek doğrudan hassas veri temasını azaltabilir.

Tenant Isolation ile PCI Scope Aynı Şey Değildir

Tenant izolasyonu güçlü olsa bile kart verisi işleniyorsa PCI kapsamı ayrıca değerlendirilmelidir.

Compliance Bir Database Modelini Zorunlu Kılar mı?

Çoğu durumda standartlar tek bir database topolojisini zorunlu kılmaz. Asıl soru riskin uygun kontrollerle yönetilip yönetilmediğidir.

“SOC 2 İçin Database per Tenant Şart” Yanılgısı

SOC 2 doğrudan her tenant için ayrı database kullanılmasını şart koşmaz.

Risk-Based Controls

Shared database kullanılıyorsa RLS, authorization, test ve monitoring kontrollerinin riski yeterince azaltması gerekir.

Customer Contract Requirements

Bir müşteri sözleşmesi ise teknik olarak ayrı database şartı getirebilir.

Regulated Tenant’lar İçin Dedicated Isolation

Yüksek riskli tenantlar hybrid mimaride dedicated ortama alınabilir.

Teknik Kontrolleri Belgelemek

Uygulanan izolasyon mekanizmalarının mimari diyagram, test ve operasyon kayıtlarıyla açıklanabilmesi önemlidir.

Tenant Data Classification

Her veri aynı hassasiyete sahip değildir. Veri sınıflandırması hangi kontrollerin gerekli olduğunu belirlemeyi kolaylaştırır.

Public

Herkese açık olması planlanan veri düşük erişim kısıtına sahip olabilir.

Internal

Yalnızca kurum içi kullanıma yönelik bilgi public olarak paylaşılmamalıdır.

Confidential

İş açısından hassas veri daha güçlü erişim ve logging kontrolleri gerektirir.

Restricted

En hassas veri grupları daha dar erişim, güçlü encryption ve ek audit gerektirebilir.

PII

Kişisel veri hem güvenlik hem privacy gereksinimleriyle birlikte ele alınmalıdır.

Financial Data

Finansal bilgiler yetki sınırı, audit ve retention politikaları açısından ayrıca değerlendirilebilir.

Tenant’a Göre Farklı Security Policies

Enterprise müşteriler daha güçlü MFA, retention veya key politikası talep edebilir.

Tenant-Specific Data Retention

Retention politikasının tenant sözleşmesine göre değişmesi gerekebilir.

Global Retention Policy

Sistem genelinde varsayılan saklama süresi belirlenebilir.

Contract-Specific Retention

Belirli müşteriler farklı veri saklama süresi talep edebilir.

Legal Hold

Yasal saklama zorunluluğu oluştuğunda normal silme süreci geçici olarak durdurulabilir.

Automated Deletion

Süresi dolan verilerin otomatik silinmesi manuel hataları azaltır.

Backups

Backup retention süresi primary veri politikasından ayrı biçimde tanımlanmalı ve müşteriye açıklanmalıdır.

Audit Logs

Audit kayıtlarının saklama süresi güvenlik ve mevzuat ihtiyaçları doğrultusunda belirlenmelidir.

Tenant Offboarding Güvenli Şekilde Nasıl Yapılır?

Müşteri ayrılışı yalnızca hesabı kapatmak değildir. Kimlik, veri ve key yaşam döngüsü birlikte tamamlanmalıdır.

Account Disable

Tenant kullanıcılarının yeni oturum açması durdurulmalıdır.

Credential Revocation

API key, session, token ve servis credentialları geçersiz hale getirilmelidir.

Data Export

Sözleşme izin veriyorsa müşteriye son veri export'u güvenli kanaldan sağlanabilir.

Retention Window

Silme öncesi bekleme süresi varsa açıkça tanımlanmalıdır.

Primary Data Deletion

Aktif database içindeki müşteri verisi lifecycle politikasına göre kaldırılmalıdır.

Search/Cache Deletion

Search index ve cache içindeki kopyalar unutulmamalıdır.

Backup Lifecycle

Yedeklerde kalan verinin hangi tarihte tamamen kaybolacağı belirlenmelidir.

Key Destruction

Tenant scoped key kullanılıyorsa uygun zamanda key'in kaldırılması ek güvence sağlayabilir.

Deletion Evidence

Silme işleminin ne zaman ve hangi sistemlerde tamamlandığı audit kaydıyla gösterilebilmelidir.

Cross-Tenant Güvenlik Testleri Nasıl Yapılır?

Tenant izolasyonu olumlu test kadar olumsuz senaryolarla da doğrulanmalıdır.

Tenant A Kullanıcısı ile Tenant B Resource ID Denemek

En temel test, Tenant A kullanıcısıyla Tenant B'ye ait bilinen resource ID üzerinden erişim denemektir.

Read Tests

Başka tenant kayıtlarının okunamadığı doğrulanmalıdır.

Write Tests

Başka tenant kaydının değiştirilemediği test edilmelidir.

Delete Tests

Silme endpointleri farklı tenant ID'leriyle negatif teste alınmalıdır.

Bulk API Tests

Bulk endpointlerin tek hatalı resource üzerinden başka tenant verisi döndürmediği kontrol edilmelidir.

Search Tests

Arama sonuçlarının tenant sınırını aşmadığı doğrulanmalıdır.

Export Tests

CSV, PDF veya diğer export mekanizmalarının yalnızca yetkili tenant verisini içerdiği test edilmelidir.

Tenant Isolation’ı Otomatik Test Etmek

Manuel test önemlidir fakat sürekli güvence için CI süreçlerinde otomatik testler gerekir.

Integration Tests

Gerçek authorization ve database katmanını birlikte çalıştıran testler yazılmalıdır.

Property-Based Tests

Farklı tenant ve resource kombinasyonlarının otomatik üretilmesi beklenmeyen sınır hatalarını yakalayabilir.

Authorization Negative Tests

İzin verilmeyen her kritik işlem için açık negatif test bulunmalıdır.

RLS Tests

Database policy'lerinin application kodundan bağımsız şekilde tenant geçişlerini engellediği doğrulanmalıdır.

Cache Tests

Aynı resource ID farklı tenantlarda bulunduğunda cache sonucunun karışmadığı test edilmelidir.

Background Job Tests

Worker işlemlerinin doğru tenant context ile çalıştığı ve context eksikliğinde reddedildiği doğrulanmalıdır.

CI Security Regression Suite

Bu testler her kritik deployment öncesinde otomatik çalışan güvenlik regresyon paketine eklenmelidir.

Penetration Testinde Multi-Tenant SaaS İçin Ne Test Edilmeli?

Pentest kapsamı yalnızca login ekranına odaklanmamalı, tenant sınırının geçtiği bütün veri yollarını içermelidir.

BOLA / IDOR

Object ID değiştirerek farklı tenant kaynaklarına ulaşma denemeleri yapılmalıdır.

Role Escalation

Düşük yetkili kullanıcının yönetici fonksiyonlarına erişimi test edilmelidir.

Tenant Switching

Tenant değiştirme API'sinde membership ve token yenileme kontrolleri denenmelidir.

API Keys

Bir tenantın API key'i başka tenant parametresiyle kullanılarak negatif test yapılmalıdır.

File Access

Object storage URL'leri ve signed URL üretim akışları kontrol edilmelidir.

Export Endpoints

Toplu veri export fonksiyonlarında tenant sınırı özellikle test edilmelidir.

Support/Admin Interfaces

Internal admin panelleri de authorization ve audit açısından pentest kapsamına alınmalıdır.

GraphQL

Nested resolver yapılarında tenant filtresinin kaybolmadığı doğrulanmalıdır.

Webhooks

Webhook endpoint, secret ve payload routing işlemlerinin doğru tenantla ilişkilendirildiği test edilmelidir.

Incident Response Tenant-Aware Olmalı mı?

Evet. Olay anında yalnızca hangi servis etkilendi sorusu değil, hangi müşterilerin etkilendiği de cevaplanmalıdır.

Hangi Tenant Etkilendi?

Log ve trace verisi etkilenen tenantları hızlı biçimde belirlemeye yardımcı olmalıdır.

Blast Radius

Olayın kaç tenantı, hangi veri türlerini ve hangi zaman aralığını etkilediği hesaplanmalıdır.

Tenant Kill Switch

Gerekli durumlarda belirli tenantın API, job veya entegrasyon erişimini geçici kapatabilecek mekanizma yararlı olabilir.

Credential Revocation

Ele geçirilmiş token veya API key'ler hızla iptal edilmelidir.

Key Revocation

Cryptographic olaylarda tenant scoped key'in devre dışı bırakılması gerekebilir.

Audit Trail

Olay boyunca yapılan müdahaleler zaman damgalı şekilde kaydedilmelidir.

Customer Notification

Bildirim yükümlülüğü olayın niteliğine, sözleşmeye ve uygulanabilir mevzuata göre değerlendirilmelidir.

Diğer Tenant’ların Etkilenmediğini Kanıtlamak

Güçlü tenant aware log ve test kayıtları yalnızca etkilenen müşterileri değil etkilenmeyen sınırları da kanıtlamaya yardımcı olur.

SaaS Security Evidence Nasıl Otomatikleştirilir?

Compliance çalışmalarının önemli bölümü zaten çalışan güvenlik kontrollerinden düzenli kanıt üretmeye dönüştürülebilir.

Access Reviews

Kullanıcı ve çalışan yetkileri periyodik olarak çıkarılıp onay akışına gönderilebilir.

RLS Test Evidence

CI sonuçları RLS ve cross tenant testlerinin düzenli çalıştığını gösterebilir.

Backup Tests

Restore test tarihleri ve sonuçları otomatik raporlanabilir.

Vulnerability Scans

Tarama sonuçları remediation süreciyle ilişkilendirilebilir.

Audit Logs

Kritik yönetim işlemleri merkezi ve değişiklikleri izlenebilir log sisteminde saklanabilir.

Key Rotation Evidence

Key rotation olayları otomatik kayıt ve rapor çıktısına dönüştürülebilir.

Continuous Control Monitoring

Configuration drift veya yetki değişiklikleri sürekli kontrol sistemiyle izlenebilir.

Trust Center

Müşterilerle paylaşılabilen güvenlik belgeleri, politikalar ve uygunluk bilgileri kontrollü bir trust center üzerinden sunulabilir.

SaaS Tenant Isolation Anti-Pattern’leri

Güvenlik olaylarının önemli bölümü birkaç tekrar eden tasarım hatasından çıkar.

Client’tan Gelen Tenant ID’ye Güvenmek

Tenant kimliği server side doğrulanmış kimlik ve membership bilgisinden türetilmelidir.

Sadece Frontend Role Check Yapmak

Frontend kontrolü kullanıcı deneyimi sağlar fakat güvenlik bariyeri değildir. Backend authorization zorunludur.

Her Query’de Manuel tenant_id Hatırlamaya Güvenmek

Geliştiricinin her sorguda filtre eklemesini beklemek hata ihtimalini yükseltir. Repository guard, ORM scope veya RLS gibi merkezi korumalar eklenmelidir.

Application’ı Superuser DB Rolüyle Çalıştırmak

Runtime servisleri ihtiyaç duyduklarından daha güçlü database yetkileriyle çalıştırılmamalıdır.

Global Cache Key Kullanmak

Tenant bilgisini içermeyen cache key'ler müşteri sonuçlarının birbirine karışmasına neden olabilir.

Background Job’a Tenant Context Eklememek

Worker hangi tenant adına işlem yaptığını kesin biçimde bilmelidir.

Loglara PII ve Secret Yazmak

Debug kolaylığı için hassas veri loglamak uzun vadede ciddi risk yaratır.

Tüm Tenant’lar İçin Tek Encryption Key

Tek key bütün müşterilerin cryptographic etki alanını birleştirebilir. Risk seviyesine göre tenant scoped key yapısı değerlendirilmelidir.

Production Verisini Staging’e Kopyalamak

Test ihtiyacı için gerçek müşteri verisini düşük güvenlikli ortama taşımak kaçınılması gereken bir uygulamadır.

Compliance Sertifikasını Güvenli Mimari Sanmak

Belge veya rapor tek başına güvenli kod anlamına gelmez. Teknik kontrollerin sürekli çalışması gerekir.

SaaS Veri İzolasyonu İçin Önerilen Defense-in-Depth Modeli

En güçlü yaklaşım tenant sınırını tek kontrol yerine birden fazla katmanda aynı anda uygulamaktır.

Katman 1 — Identity

Kullanıcı ve servis kimliği güvenilir authentication mekanizmasıyla doğrulanır.

Katman 2 — Tenant Context

Aktif tenant server side ve doğrulanmış membership üzerinden belirlenir.

Katman 3 — Authorization

Her işlem rol, izin ve tenant sahipliği açısından değerlendirilir.

Katman 4 — Application Data Access

Repository ve service katmanı tenant aware veri erişim kalıpları kullanır.

Katman 5 — Database Enforcement

RLS, constraint ve database rolü uygulama hatalarına karşı ek koruma sağlar.

Katman 6 — Cryptographic Isolation

Hassas tenantlar için ayrı key sınırları uygulanabilir.

Katman 7 — Infrastructure

Network, IAM, storage ve compute kaynakları tenant risk seviyesine göre ayrıştırılır.

Katman 8 — Monitoring ve Audit

Tenant bazlı log, metric ve audit kayıtları güvenlik olaylarını görünür hale getirir.

Katman 9 — Automated Testing

Cross tenant negative testler CI sürecinde sürekli çalıştırılır.

Katman 10 — Governance ve Compliance

Politikalar, risk değerlendirmeleri ve audit evidence teknik güvenliği organizasyonel süreçlerle tamamlar.

SaaS Tenant Isolation Checklist

Aşağıdaki sorular mimari incelemelerde kullanılabilecek pratik bir kontrol çerçevesi sunar.

Identity

Tenant güvenilir kaynaktan mı belirleniyor?

Tenant kimliği doğrulanmış token, session veya server side üyelik bilgisinden gelmelidir.

Tenant switching güvenli mi?

Yalnızca doğrulanmış üyelikler arasında geçişe izin verilmelidir.

MFA/SSO tenant seviyesinde uygulanabiliyor mu?

Kurumsal müşteriler için tenant özelinde SSO ve MFA politikası tanımlanabilmesi yararlıdır.

Authorization

Her karar tenant-scoped mu?

Rol kontrolüne tenant sahipliği kontrolü eşlik etmelidir.

Object ownership kontrol ediliyor mu?

Resource ID tek başına erişim hakkı olarak kabul edilmemelidir.

Client-side kontrole güveniliyor mu?

Güvenlik kararı daima backend tarafından uygulanmalıdır.

Database

Tenant ID tüm gerekli tablolarda var mı?

Tenant sahipliği bulunan tabloların veri modelinde sınır açık biçimde görünmelidir.

RLS uygulanıyor mu?

Shared PostgreSQL yapısında RLS güçlü bir ek koruma seçeneğidir.

Application DB role RLS’yi bypass edebiliyor mu?

Runtime rolünde superuser veya BYPASSRLS gibi gereksiz ayrıcalıklar bulunmamalıdır.

Storage

Object key’leri tenant-scoped mu?

Dosya yolları tenant namespace ile ayrılmalıdır.

Signed URL authorization doğru mu?

Signed URL yalnızca dosya sahipliği ve kullanıcı yetkisi doğrulandıktan sonra oluşturulmalıdır.

Cache ve Queue

Cache key tenant-aware mı?

Tenant kimliği bütün müşteri özel cache key'lerinde bulunmalıdır.

Job tenant context taşıyor mu?

Her job hangi tenant adına çalıştığını açıkça taşımalıdır.

Encryption

Encryption at rest var mı?

Database, object storage ve backup katmanları depolamada şifrelenmelidir.

Tenant-scoped key gerekli mi?

Bu karar müşteri risk seviyesi, sözleşme ve blast radius beklentisine göre verilmelidir.

Rotation süreci test edildi mi?

Key rotation yalnızca dokümante edilmemeli, gerçekten uygulanıp doğrulanmalıdır.

Operations

Production access JIT mi?

Kalıcı yönetici yetkisi yerine süreli erişim daha güvenli bir operasyondur.

Audit trail var mı?

Kritik production hareketleri kullanıcı, tenant ve zaman bilgisiyle kaydedilmelidir.

Break-glass kayıt altına alınıyor mu?

Acil erişimler gerekçe ve işlem geçmişiyle audit edilmelidir.

Compliance

ISO/SOC/KVKK/GDPR scope doğru tanımlandı mı?

Her çerçevenin kapsamı işlenen veri, hizmet modeli ve yasal rol üzerinden belirlenmelidir.

Security control evidence üretilebiliyor mu?

Kontrollerin varlığı kadar düzenli çalıştıklarını gösterebilecek kanıt da önemlidir.

Testing

Cross-tenant negative test var mı?

Her kritik resource için farklı tenant erişimi otomatik olarak reddedilmelidir.

RLS regression tests çalışıyor mu?

Policy değişiklikleri deployment öncesinde tenant izolasyonu açısından test edilmelidir.

Pentest tenant isolation’ı kapsıyor mu?

Pentest kapsamı API, storage, export, admin ve background işlemleri dahil bütün tenant veri yollarını içermelidir.

Sık Sorulan Sorular

SaaS Veri İzolasyonu Nedir?

SaaS veri izolasyonu, bir müşterinin yalnızca kendi verisine ve kaynaklarına erişebilmesini sağlayan teknik ve operasyonel güvenlik sınırıdır.

Multi-Tenant SaaS Güvenli midir?

Evet. Doğru authentication, tenant aware authorization, database enforcement, encryption ve test süreçleriyle multi tenant sistem güvenli biçimde işletilebilir.

Shared Database Kullanmak Güvenli midir?

Doğru tenant filtreleri, RLS, constraint, düşük yetkili database rolleri ve otomatik cross tenant testleri bulunduğunda güvenli bir model olabilir.

Database per Tenant Kullanmak Şart mı?

Hayır. Bu bir mimari ve risk kararıdır. Bazı kurumsal müşteriler veya sözleşmeler için gerekli hale gelebilir.

PostgreSQL RLS Nedir?

RLS, PostgreSQL'in satır seviyesinde erişim politikaları uygulayarak hangi kayıtların okunabileceğini veya değiştirilebileceğini sınırlandıran özelliğidir.

RLS Tek Başına Yeterli midir?

Hayır. Authentication, authorization, storage, cache, queue ve operasyon güvenliğiyle birlikte kullanılmalıdır.

RBAC ile Tenant Isolation Aynı Şey mi?

Hayır. RBAC kullanıcının ne yapabildiğini belirler. Tenant isolation bu işlemi hangi müşterinin kaynakları üzerinde yapabildiğini sınırlar.

SOC 2 İçin Database per Tenant Gerekli mi?

Genel bir database per tenant zorunluluğu yoktur. Uygulanan kontrollerin riski uygun seviyeye düşürdüğünün gösterilmesi gerekir.

ISO 27001 Tenant Isolation’ı Zorunlu Kılar mı?

ISO/IEC 27001 tek bir tenant isolation teknolojisi şart koşmaz. Kurumun risklerini belirleyip uygun güvenlik kontrollerini uygulamasını bekler.

ISO/IEC 27017:2026 Nedir?

Bulut hizmetlerinin sağlanması ve kullanılması için ISO/IEC 27002 tabanlı ek cloud security rehberliği ve kontrolleri sunan güncel standarttır.

ISO/IEC 27018:2025 Nedir?

Public cloud üzerinde PII processor rolündeki hizmet sağlayıcıların kişisel veriyi korumasına yönelik güncel rehberlik sunar.

SaaS Uygulamalarında KVKK Nasıl Ele Alınır?

Kişisel veri envanteri, erişim kontrolü, veri minimizasyonu, loglama, backup güvenliği ve uygun teknik ve idari tedbirler birlikte değerlendirilmelidir.

GDPR İçin EU’da Hosting Zorunlu mudur?

GDPR bütün verinin mutlak biçimde AB içinde barındırılmasını tek başına genel kural olarak şart koşmaz. Uluslararası aktarımlar için uygulanabilir hukuki mekanizmalar ve korumalar değerlendirilmelidir.

BYOK Nedir?

BYOK, müşterinin encryption key yönetiminde kendi anahtarını kullanabildiği modeli ifade eder.

Tenant Başına Encryption Key Kullanılmalı mı?

Her SaaS ürünü için zorunlu değildir. Yüksek riskli veya kurumsal tenantlarda cryptographic blast radius'u azaltmak için değerlendirilebilir.

Cache’lerde Tenant Verisi Nasıl İzole Edilir?

Cache key tenant kimliğini içermeli, authorization cache tenant scoped olmalı ve tenant değişikliklerinde uygun invalidation uygulanmalıdır.

AI Agent’larda Cross-Tenant Data Leak Nasıl Önlenir?

Modelin tenant seçmesine izin verilmemeli, auth context server side aktarılmalı ve her tool çağrısı gerçek kullanıcı ile tenant yetkileri üzerinden doğrulanmalıdır.

SaaS uygulamalarında veri izolasyonu nedir ve müşteri verileri birbirinden nasıl güvenli şekilde ayrılır?

Müşteri verileri tenant kimliği, server side authorization, database policy, storage namespace, cache ayrımı ve gerektiğinde cryptographic key sınırlarıyla birbirinden ayrılır. SaaS Uygulamalarında Veri İzolasyonu ve Güvenlik Standartları yaklaşımında bu kontrollerin yalnızca tek katmanda değil bütün veri yollarında uygulanması gerekir.

Multi-tenant SaaS mimarisinde tenant bazlı veri izolasyonu nasıl sağlanır?

Doğrulanmış tenant context oluşturulur, bütün resource işlemleri tenant scoped authorization üzerinden geçirilir ve database, cache, queue, search, storage gibi alt sistemlerde aynı tenant sınırı uygulanır.

SaaS uygulamalarında şifreleme, erişim kontrolü ve Row-Level Security nasıl uygulanmalıdır?

Encryption veriyi depolama ve aktarım sırasında korurken RBAC veya daha ayrıntılı authorization modelleri kullanıcı işlemlerini sınırlar. PostgreSQL RLS ise shared database yapısında tenant sınırını database seviyesinde ek bir bariyerle korur.

SaaS güvenliği için ISO 27001, SOC 2 ve KVKK gibi standartlara uyum nasıl sağlanır?

Öncelikle sistem ve veri kapsamı belirlenir. Ardından riskler, erişim kontrolleri, loglama, backup, incident response, vendor yönetimi ve denetim kanıtları düzenli süreçlerle yönetilir. Compliance çalışması teknik güvenliği tamamlar fakat onun yerine geçmez.

Yakınımda SaaS veri güvenliği ve kurumsal güvenlik standartları konusunda danışmanlık veren yazılım firması nasıl bulabilirim?

Arama yaparken yalnızca genel yazılım geliştirme deneyimine değil, multi tenant authorization, RLS, cloud security, encryption, audit logging ve compliance süreçlerinde gerçek proje deneyimine bakın. SaaS güvenliği ve multi-tenant mimari danışmanlığı yakınımda şeklinde araştırma yapıyorsanız Diyarbakır Yazılım Topluluğu'nun çalışma yaklaşımını https://www.diyarbakiryazilim.com.tr/about adresinden, proje çalışmalarını ise https://www.diyarbakiryazilim.com.tr/projects üzerinden inceleyebilirsiniz.

Sonuç: SaaS Güvenliğinde Tenant Boundary Her Veri Yolunda Korunmalıdır

SaaS Uygulamalarında Veri İzolasyonu ve Güvenlik Standartları yalnızca database seçimiyle çözülen bir konu değildir. Güvenli mimari identity ile başlar, tenant context ve authorization ile devam eder, database, storage, cache, queue, search, AI sistemleri, encryption, backup ve observability katmanlarında aynı sınırı korur.

Benim en önemli önerim şu: Tenant boundary'yi bir uygulama kuralı değil, sistemin değişmez güvenlik koşulu olarak ele alın. Bir geliştirici filtre eklemeyi unuttuğunda bile ikinci ve üçüncü katmanlar hatayı durdurabilsin.

Kurumsal SaaS veri izolasyonu ve güvenlik mimarisi danışmanlığı kapsamında multi tenant tasarımınızı, PostgreSQL RLS modelinizi, tenant aware authorization yapınızı veya mevcut sisteminizdeki güvenlik sınırlarını değerlendirmek istiyorsanız Diyarbakır Yazılım Topluluğu üzerinden iletişim kurabilirsiniz: https://www.diyarbakiryazilim.com.tr