Güvenli Uygulama Mimarileri: Sistem Tasarımında Güvenlik Nerede Konumlandırılmalı?

Güvenli Uygulama Mimarileri: Sistem Tasarımında Güvenlik Nerede Konumlandırılmalı?

Yazılım geliştirme süreçlerinde ilk aşamalar çoğunlukla işlevsellik, teknoloji yığını ve kullanıcı deneyimi ekseninde şekillenir. Ancak sistemler büyüdükçe, dış servislerle entegrasyonlar arttıkça ve dağıtık bulut yapılarına geçildikçe güvenlik, geliştirme bittikten sonra sisteme iliştirilen yüzeysel tedbirler olmaktan çıkar. Güvenlik, doğrudan temel mimari kurgunun ayrılmaz bir parçası hâline gelmek zorundadır.

Sağlam bir mimari güvenlik; yalnızca bir Web Application Firewall (WAF) kurmak, veritabanını şifrelemek veya iki aşamalı giriş eklemekle sınırlı değildir. Asıl mesele; bileşenlerin sınırlarını, birbirleriyle kurdukları iletişimin niteliğini, eriştikleri kaynakları ve muhtemel bir sızma durumunda saldırının ne kadar derine inebileceğini en baştan planlamaktır. Bu kapsamda sistem mimarisi, güven sınırları, mikroservis haberleşmesi, bulut ortamları ve dağıtım süreçleri gibi kritik alanların güvenlik perspektifinden irdelenmesi gerekir.

Mimari Tasarımda Güvenliğin Başlangıç Noktası

Güvenlik değerlendirmesi yapabilmek için ilk olarak sistemin çalışma düzenini kavramak gerekir. Sistem mimarisi, uygulamanın gereksinim duyduğu altyapı ve servis bileşenlerinin genel yerleşimini tanımlar. Yazılım mimarisi ise bu bileşenlerin iç dinamiklerini, katmanlarını ve sorumluluk paylaşımını belirler.

Örneğin bir e-ticaret platformunda sipariş yönetimi, ödeme, ürün kataloğu ve kullanıcı profili farklı çalışma sahalarıdır. Bu alanların sınırlarının çizilmesi, verinin nerede depolanacağı ve haberleşme modelleri doğrudan mimari kararlarla şekillenir. Domain-Driven Design (DDD) yaklaşımı, sistemin teknik katmanlar yerine bu tür iş alanlarına (bounded context) göre bölünmesini sağlayarak hem kod yapısını hem de ekiplerin iş bölümünü optimize eder.

Monolitik ve Dağıtık Yapıların Güvenlik Dengesi

Monolitik yapılarda tüm fonksiyonlar genellikle tek bir bütün hâlinde paketlenip sunulur. Başlangıçta yönetim ve dağıtım kolaylığı sağlasa da zamanla bileşenler arasındaki bağımlılıklar karmaşıklaşabilir. Dağıtık ve mikroservis mimarilerinde ise servisler ayrıştırılarak bağımsız ölçeklenebilirlik ve hata izolasyonu hedeflenir. Fakat bu yaklaşım, servisler arası ağ trafiğini artırarak yeni saldırı yüzeylerini beraberinde getirir:

• Servisler arası kimlik doğrulama ve yetkilendirme gereksinimleri,
• Ağ gecikmeleri ve iletişim zaman aşımları,
• Merkezi loglama ve uçtan uca istek takibi,
• Bir serviste yaşanan ihlalin diğer sistemlere sıçramasını önleme gereği,
• Önbellek (cache) tutarlılığı ve senkronizasyon zorlukları.

Mikroservislere geçmek sistemi kendiliğinden daha korunaklı kılmaz. Kararlar operasyonel güç, ekip yapısı ve güvenlik ihtiyaçları gözetilerek verilmelidir.

Güven Sınırları (Trust Boundary), Kritik Varlıklar ve Blast Radius

Bir mimari şemaya bakarken yalnızca parçaların nerede durduğunu görmek yeterli değildir; parçaların hangi güven düzeyinde çalıştığını saptamak gerekir. Trust Boundary (Güven Sınırı), farklı yetki ve güven derecelerine sahip sistemlerin kesiştiği noktalardır. Kullanıcıdan gelen trafiğin karşılandığı katman ile veritabanına erişen katman aynı güven düzeyine sahip olamaz. Benzer şekilde, kurum içi ağda yer alan bir bileşene sırf içeride olduğu için koşulsuz güvenilmemelidir. Zero Trust (Sıfır Güven) felsefesi gereği her istek, kimliği ve yetkisi bağlamında doğrulanmalıdır.

CIA Üçlüsü ve Etki Alanı Kontrolü

Sistem gereksinimleri klasik CIA üçlüsü üzerinden yapılandırılır:

• Confidentiality (Gizlilik): Bilgiye yalnızca yetkilendirilmiş tarafların ulaşması.
• Integrity (Bütünlük): Verilerin izinsiz değiştirilmesinin, manipüle edilmesinin önüne geçilmesi.
• Availability (Erişilebilirlik): Servislerin ve kaynakların ihtiyaç anında kesintisiz sunulabilmesi.

Bir bileşen ihlal edildiğinde hasarın nereye kadar uzanabileceği ise Blast Radius (Etki Alanı) kavramıyla açıklanır. Bir mikroservis ele geçirildiğinde tüm veritabanlarına veya diğer API’lere erişebiliyorsa etki alanı tehlikeli boyutta geniştir. Bu riski sınırlandırmak adına Least Privilege (En Az Ayrıcalık) prensibi uygulanarak servislere ve kullanıcılara yalnızca görevleri için mutlak surette gereken minimum yetkiler tanımlanmalıdır.

Katmanlı Mimaride Güvenlik Denetimleri ve Nesne Sahipliği

Klasik katmanlı mimarilerde sorumluluklar genel hatlarıyla Presentation (Sunum), Business (İş Mantığı), Service (Servis), Persistence (Veri Erişim) ve Database (Veritabanı) şeklinde ayrılır. Güvenlik, tek bir noktaya yüklenemez; katmanlar arasında kademeli kontroller uygulanmalıdır:

• Presentation: Veri giriş doğrulamaları, istek biçimi ve boyut sınırlandırmaları.
• Business: Yetki yönetimi, iş mantığı denetimleri ve nesne seviyesinde sahiplik doğrulaması.
• Service: Servisler arası iletişim ve kimlik denetimleri.
• Persistence: Güvenli sorgu yapılandırması ve kontrollü veri çekme mekanizmaları.
• Database: Erişim kısıtlamaları, veri şifreleme ve denetim kayıtları (audit log).

Özellikle nesne sahipliği konusu kritik bir zaafiyet alanıdır. Sisteme giriş yapmış bir kullanıcının, yalnızca URL veya gövdedeki sipariş kimliğini (ID) değiştirerek başka bir kullanıcının kaydını görmesini engellemek gerekir. Bu denetim asla arayüz katmanında bırakılmamalı; sunucu tarafında, iş mantığının (Business Layer) tam merkezinde uygulanmalıdır.

Olay Tabanlı İletişim (Event-Driven) Güvenliği

Servislerin birbiriyle doğrudan ve senkron konuşması yerine asenkron olarak olay (event) fırlatıp dinlediği yapılar bağımlılıkları azaltır. Ancak Message Broker (mesaj kuyruğu) altyapıları yeni güvenlik kuralları gerektirir.

Mesajı üreten (Producer) ve tüketen (Consumer) tarafların hakları ayrıştırılmalıdır. Rastgele her servisin her kuyruğa yazması veya tüm olayları dinlemesi engellenmelidir. Broker üzerinden gelen mesajlar Consumer tarafından koşulsuz doğru kabul edilmemeli, şema ve veri doğrulamasına tabi tutulmalıdır.

Veritabanı işlemleri ile mesaj kuyruğunun tutarlılığı için Outbox Pattern devreye girer. Bu düzende veri tabanı kaydı ile fırlatılacak mesaj kaydı aynı hareket (transaction) içinde işlenir, ayrı bir süreç kuyruğa aktarımı üstlenir. Böylece veri kaydedildiği hâlde mesajın kuyruğa gidememesi riski ortadan kalkar.

Aynı mesajın ağ aksaklıkları nedeniyle birden fazla kez gelme olasılığına karşı Idempotency sağlanmalıdır. Yani aynı işlem mesajı mükerrer gelse dahi sistemde tek bir kez sonuç doğurmalıdır (örneğin mükerrer ödeme çekilmemesi). Önbellek kullanımlarında ise verinin güncelliğini yitirmesi (Eventual Consistency gecikmeleri) yetki ve anahtar iptallerinde risk oluşturabileceğinden, TTL ve cache invalidation stratejileri dikkatle kurulmalıdır.

Mikroservis Güvenliği, Kimlik Doğrulama ve Ağ İletişimi

Mikroservis mimarisinde API Gateway veya Backend for Frontend (BFF) katmanları; istemci isteklerinin karşılanması, yönlendirilmesi ve genel kimlik kontrolü için ilk temas noktasıdır. Ancak Gateway’in arkasındaki iç servislerin de kendi güvenlik kontrollerini sürdürmesi gerekir. Aksi hâlde tek bir noktadan sızan bir saldırgan veya SSRF gibi bir açık tüm iç ağın ele geçirilmesine yol açabilir.

Mikroservisler arası karmaşık istek trafiğini gözlemlemek ve anomalileri tespit etmek adına OpenTelemetry gibi standartlarla distributed tracing (dağıtık izleme) mekanizmaları kurgulanmalıdır.

Kimlik ve Erişim Protokolleri: OAuth 2.0 ve mTLS

Servisler ve kullanıcılar arası iletişimde kullanılan temel mekanizmaların sınırları iyi bilinmelidir:

• OAuth 2.0: Bir yetkilendirme çerçevesidir. Erişim token’ları (Access Token) ve bunların yenilenmesini sağlayan daha hassas Refresh Token’lar üzerinden kapsam (scope) tabanlı izin kontrolü sunar.
• JWT (JSON Web Token): OAuth 2.0 veya genel kimlik süreçlerinde veri taşımak için kullanılan biçimlendirilmiş bir token formatıdır.
• OpenID Connect (OIDC): OAuth 2.0 katmanının üzerine inşa edilmiş, kimlik doğrulama standardıdır.
• mTLS (Mutual TLS): Karşılıklı dijital sertifikalarla hem istemcinin hem sunucunun kimliğini doğruladığı şifreli ağ kanalıdır.

Servisler arası iletişimde mTLS ile makine kimliği ve kanal güvenliği sağlanırken, OAuth 2.0 token’ları ile hangi veriye hangi yetkiyle erişildiği denetlenebilir. İkisi birbirinin rakibi değil, tamamlayıcısıdır.

Bulut ve Konteyner Güvenliği: AWS ve Kubernetes

Bulut mimarilerinde (AWS vb.) altyapı güvenliği izole hesaplar ve sıkı IAM kurallarıyla başlar. Geliştirme (dev) ve canlı (prod) ortamlarının ayrı AWS hesaplarında tutulması, olası bir sızıntının canlı ortamı etkilemesini sınırlar. STS (Security Token Service) ile geçici kimlik tanımları kullanılmalı, kurumsal kimlik sağlayıcılarıyla federasyon kurulurken bulut yetki sınırları özenle çizilmelidir. Ayrıca denetim loglarının değiştirilemezliği adına loglar ayrı, erişimi kısıtlı hesaplarda depolanmalıdır.

Kubernetes (EKS) tarafında ise şu başlıklar öne çıkar:

• RBAC: Kullanıcı ve servis hesaplarının cluster üzerindeki eylemlerini en aza indirgemek.
• Namespace: Mantıksal ayrım sunar ancak tek başına bir güvenlik duvarı değildir; mutlaka Network Policy ile desteklenmelidir.
• Network Policy: Pod’ların varsayılan olarak serbestçe birbiriyle konuşmasını engellemek, yalnızca zorunlu iletişim hatlarına izin vermek.
• Secrets Yönetimi: Kubernetes Secret nesneleri temel düzeydedir; hassas anahtarlar şifrelenmeli veya harici kasa çözümleriyle yönetilmeli, asla kod depolarına iliştirilmemelidir.

CI/CD Süreçlerinin Güvenliği: Koddan Canlıya

Canlı ortamda alınan önlemler, dağıtım hattı savunmasızsa yetersiz kalır. CI/CD boru hatları (pipeline); kaynak kodlara, gizli anahtarlara ve üretim sunucularına doğrudan erişebildiği için cazip bir saldırı hedefidir.

Dağıtım hattında şu prensipler uygulanmalıdır:

• Değişikliklerin çift göz kuralı ve zorunlu Pull Request incelemeleriyle ana dala alınması,
• Commit ve paketlerin (artifact) dijital olarak imzalanması,
• Hatta entegre SAST (statik kod analizi), SCA (bağımlılık güvenliği), Secret Scanning (açık anahtar taraması) ve IaC (altyapı kodu analizi) araçlarının koşturulması,
• İnşa araçlarının üretim ve gizli anahtarlara erişiminin iş yükü bazında asgari düzeyde tutulması.

Mimari Tasarım İncelerken Yanıtlanması Gereken Sorular

Bir mimari diyagram yalnızca kutular ve oklardan ibaret görülmemeli, aşağıdaki kritik sorularla denetlenmelidir:

• Sistemdeki en kritik veri ve bileşenler nelerdir?
• Trust Boundary (güven sınırları) hangi noktalarda çizilmiştir?
• Her varlık için gizlilik, bütünlük ve erişilebilirlik (CIA) öncelikleri nelerdir?
• Gerekli güvenlik kontrolleri hangi yazılım katmanında yürütülmektedir?
• Bir servis ihlal edilirse saldırganın ağdaki yayılma alanı (Blast Radius) ne kadar büyüktür?
• Bileşenler arası kimlik doğrulama ve yetki ayrımı nasıl işletilmektedir?
• Gizli anahtarlar, parolalar nerede ve nasıl saklanmaktadır?
• Bir servis veya mesaj kuyruğu çöktüğünde sistem bütünlüğü nasıl korunmaktadır?
• CI/CD hattının yetkileri ve ortam ayrımları yeterince sıkı mıdır?

Güvenli sistemler, hiçbir zaman açık vermeyeceği varsayılan sistemler değildir. Gerçek güvenlik; bir parça arızalandığında ya da ihlale uğradığında dahi tüm yapının kontrolünü ve veri bütünlüğünü korumaya devam edebilen mimariler inşa etmekten geçer.