Bir sistemin güvenliğini yalnızca kodda değil, mimari kararların en başında düşünmek.

Bu yazıda, Hackwise – Güvenli Uygulama Mimarileri eğitimi kapsamında tuttuğum teknik notlar, mimari vaka çalışmaları ve değerlendirmeler yer almaktadır.

Giriş

Bir uygulama geliştirirken ilk aşamada genellikle işlevlere, kullanılacak teknolojilere ve kullanıcı deneyimine odaklanıyoruz. Ancak uygulama büyüdükçe yeni servislerle iletişim kurmaya, farklı veri kaynaklarına erişmeye ve bulut ortamlarında çalışmaya başladıkça güvenlik, sonradan eklenen birkaç kontrol olmaktan çıkıyor. Doğrudan mimari tasarımın bir parçası hâline geliyor.

Güvenli uygulama mimarisi yalnızca bir Web Application Firewall (WAF) kullanmak, verileri şifrelemek veya kullanıcı girişine çok faktörlü doğrulama eklemek değildir. Sistemin hangi bileşenlerden oluştuğunu, bu bileşenlerin birbirleriyle nasıl iletişim kurduğunu, hangi kaynaklara erişebildiğini ve bir bileşen ele geçirildiğinde saldırının ne kadar yayılabileceğini değerlendirmeyi gerektirir.

Hackwise kapsamında gerçekleştirilen Güvenli Uygulama Mimarileri eğitiminde sistem ve yazılım mimarisi, güven sınırları, katmanlı tasarım, olay tabanlı iletişim, mikroservis güvenliği, OAuth, mTLS, AWS, Kubernetes ve CI/CD güvenliği ele alındı. Bu yazıda eğitim notlarını ve vaka çalışmalarını bir araya getirerek mimari kararların güvenlik üzerindeki etkilerini inceliyorum.

Güvenlik mimari tasarımın neresinde başlar?

Güvenlik değerlendirmesine başlamadan önce sistemin nasıl çalıştığını anlamak gerekir. Bunun için önce mimarideki bileşenleri ve aralarındaki ilişkileri ortaya koymak önemlidir.

Sistem mimarisi, uygulamanın hangi servislerden ve altyapı bileşenlerinden oluşacağını ve bunların nasıl bir araya geleceğini tanımlar. Yazılım mimarisi ise bu bileşenlerin kendi iç sorumluluklarını, katmanlarını ve çalışma düzenini ele alır.

Örneğin bir e-ticaret uygulamasında ürün kataloğu, favoriler, sipariş yönetimi, müşteri profili ve ödeme işlemleri farklı iş alanlarıdır. Bu sorumlulukların nasıl ayrılacağı, hangi bileşenlerin birbirleriyle konuşacağı ve verilerin nerede tutulacağı mimari tasarım kararlarıdır.

Domain-Driven Design ve ekiplerin organizasyonu

Domain-Driven Design (DDD), yazılımın teknik katmanlardan ziyade iş alanları ve iş kuralları etrafında modellenmesine yardımcı olur. Ürün yönetimi, sipariş yönetimi veya müşteri ilişkileri gibi alanlar ayrı bounded context’ler olarak ele alınabilir.

Bu yaklaşım yalnızca kodun nasıl bölüneceğini değil, ekiplerin nasıl organize edilebileceğini de etkiler. Örneğin ürün favorileme özelliği üzerinde çalışan ekipte frontend ve backend sorumluluklarının birlikte ele alınması, özelliğin uçtan uca geliştirilmesini kolaylaştırabilir.

Monolitik ve dağıtık mimariler

Monolitik mimaride uygulamanın farklı işlevleri çoğunlukla tek bir uygulama olarak geliştirilir ve dağıtılır. Başlangıçta geliştirme ve işletim açısından daha basit olabilir. Ancak zamanla bileşenler arasındaki bağımlılık artabilir.

Dağıtık mimaride ise uygulama farklı servis veya bileşenlere ayrılır. Belirli bir servisin kapasitesi bağımsız artırılabilir ve bazı hatalar diğer bileşenlerden izole edilebilir. Buna karşılık servisler arası ağ iletişimi yeni hata ve saldırı yüzeyleri oluşturur.

Dağıtık sistemlerde özellikle şu konular önem kazanır:

• Servisler arası kimlik doğrulama ve yetkilendirme
• Ağ gecikmeleri, bağlantı kopmaları ve zaman aşımı yönetimi
• Servislerin loglarının ve istek akışlarının takip edilmesi
• Bir servisteki güvenlik ihlalinin diğer servislere yayılmasının önlenmesi
• Cache tutarlılığı ve veri senkronizasyonu

Bu nedenle mikroservis mimarisi kendiliğinden daha güvenli değildir. Mimari seçim; iş ihtiyacı, ekip yapısı, operasyonel kapasite ve güvenlik gereksinimleri birlikte değerlendirilerek yapılmalıdır.

Mimari kararların geri döndürülebilirliği

Örneğin bir özelliği önce sınırlı sayıda kullanıcıya açmak, bütün kullanıcıları aynı anda etkileyecek bir değişiklik yapmaktan daha kontrollü olabilir.

İki faktörlü doğrulama (2FA) buna örnek verilebilir. Kullanıcı deneyimini ve işlem riskini birlikte düşünerek, örneğin ödeme gibi kritik işlemlerde ek doğrulama istemek değerlendirilebilir. Buradaki temel fikir, güvenlik kararlarını kullanıcı deneyiminden bağımsız ele almamaktır.

Trust Boundary, kritik varlıklar ve Blast Radius

Bir mimari diyagramı incelerken yalnızca bileşenlerin nerede bulunduğuna bakmak yeterli değildir. Bu bileşenlerin hangi güven sınırları içinde çalıştığı ve birbirlerine ne ölçüde güvendiği de değerlendirilmelidir.

Trust Boundary (Güven Sınırı), farklı güven seviyelerine sahip sistemler veya bileşenler arasındaki sınırdır. Örneğin uygulama ile harici ödeme kuruluşu arasındaki iletişim bir güven sınırı oluşturur. Kullanıcıdan gelen istekler ile veritabanına erişen servisler de farklı güven seviyelerinde ele alınmalıdır.

Bir bileşenin kurumun iç ağında bulunması, otomatik olarak güvenilir olduğu anlamına gelmez. Zero Trust yaklaşımı bu nedenle önemlidir: erişim istekleri kimlik, yetki ve bağlam açısından doğrulanmalıdır.

Bir mimariyi incelerken şu sorular sorulabilir:

• Korunması gereken kritik varlıklar nelerdir?
• Bu varlıklara hangi kullanıcılar ve servisler erişebiliyor?
• Hangi bileşenler dış dünyayla iletişim kuruyor?
• Servisler birbirlerinin kimliğini nasıl doğruluyor?
• Gizli anahtarlar ve erişim bilgileri nerede saklanıyor?
• Bir servis ele geçirilirse saldırgan hangi kaynaklara ulaşabilir?

CIA üçlüsü ile güvenlik ihtiyaçlarını belirlemek

CIA üçlüsü, güvenlik gereksinimlerini üç temel başlıkta ele alır:

• Confidentiality (Gizlilik): Verilere yalnızca yetkili kişi ve sistemlerin erişebilmesi.
• Integrity (Bütünlük): Verilerin izinsiz değiştirilmesinin veya bozulmasının önlenmesi.
• Availability (Erişilebilirlik): Sistemlerin ve verilerin ihtiyaç duyulduğunda kullanılabilir olması.

Örneğin e-ticaret uygulamasındaki müşteri bilgileri gizlilik açısından korunmalıdır. Sipariş tutarının izinsiz değiştirilmesi bütünlük problemidir. Ödeme servisinin saldırı veya arıza nedeniyle çalışamaması ise erişilebilirliği etkiler.

Her varlığın güvenlik ihtiyacı aynı değildir. Bu nedenle kontroller, varlığın önemine ve karşı karşıya olduğu risklere göre seçilmelidir.

Blast Radius: Bir ihlalin etki alanı

Blast Radius, bir bileşende meydana gelen güvenlik ihlalinin sistemin diğer bölümlerine ne ölçüde yayılabileceğini ifade eder.

Örneğin ele geçirilen bir servis tüm veritabanlarına, diğer servislerin API’lerine ve bulut kaynaklarına erişebiliyorsa saldırının etki alanı geniştir. Servis yalnızca kendi görevini yerine getirmek için ihtiyaç duyduğu kaynaklara erişebiliyorsa etki alanı daraltılabilir.

Burada Least Privilege (En Az Ayrıcalık) ilkesi devreye girer. Kullanıcıya, servise veya uygulamaya yalnızca görevini yerine getirmesi için gerekli izinler verilmelidir.

Katmanlı mimari ve güvenlik kontrolleri

Katmanlı mimari, uygulamanın sorumluluklarını farklı katmanlara ayırır. Eğitimde ele alınan örneklerde Presentation, Business, Service, Persistence ve Database katmanları üzerinden değerlendirme yapıldı.

Şekil 1 — Katmanlı mimari diyagramı.

Katmanların temel sorumlulukları şu şekilde özetlenebilir:

1. Presentation Layer: Kullanıcıdan gelen istekleri karşılar ve yanıtları sunar.
2. Business Layer: İş kurallarını ve yetkilendirme kararlarını uygular.
3. Service Layer: Uygulama servisleriyle veya harici sistemlerle iletişimi yönetir.
4. Persistence Layer: Veri erişim işlemlerini düzenler.
5. Database Layer: Verilerin saklandığı katmandır.

Her katmanın erişim sınırları belirlenmelidir. Örneğin kullanıcı bir siparişin ayrıntılarını görüntülemek istediğinde yalnızca sipariş numarasını göndermesi yeterli değildir. İlgili siparişin gerçekten o kullanıcıya ait olup olmadığı da kontrol edilmelidir.

Bu kontrolün yalnızca arayüzde yapılması yeterli olmaz. Nesne sahipliği ve yetkilendirme kontrolleri sunucu tarafında, iş kurallarının uygulandığı katmanda gerçekleştirilmelidir.

Katmanlara göre değerlendirilebilecek kontroller:

• Presentation: Girdi doğrulama, istek boyutu ve biçimi kontrolleri.
• Business: İş kuralları, nesne sahipliği ve yetkilendirme.
• Service: Servis kimliği doğrulama ve servisler arası erişim politikaları.
• Persistence: Kontrollü veri erişimi ve sorgu yönetimi.
• Database: Erişim kontrolü, şifreleme, yedekleme ve denetim kayıtları.

Burada önemli olan güvenliği tek bir katmana bırakmamaktır. Birbirini tamamlayan kontroller farklı katmanlarda uygulanmalıdır.

Nesne sahipliği neden önemlidir?

Bir kullanıcının başka bir kullanıcının siparişini yalnızca sipariş ID’sini değiştirerek görüntüleyebilmesi, nesne seviyesinde yetkilendirme eksikliğine örnektir. Bu nedenle erişim kontrolü yalnızca “kullanıcı giriş yaptı mı?” sorusuyla sınırlı kalmamalıdır. Kullanıcının erişmek istediği nesne üzerinde gerçekten yetkisi olup olmadığı da doğrulanmalıdır.

Eğitim notlarında bu kontrolün Business Layer içerisinde uygulanması ve veri erişim katmanında gerekli sınırların korunması üzerinde duruldu.

Event-Driven Architecture: Olay tabanlı iletişim

Dağıtık sistemlerde servislerin birbirlerini doğrudan çağırması her zaman en uygun yöntem olmayabilir. Özellikle bir işlemin sonucunun farklı servisler tarafından asenkron biçimde ele alınması gerektiğinde Event-Driven Architecture tercih edilebilir.

Bu mimaride bir bileşen meydana gelen olayı yayınlar, ilgili olayla ilgilenen diğer bileşenler ise bu olayı tüketerek kendi işlemlerini gerçekleştirir.

Şekil 2 — Perakende web sitesi, mobil uygulama ve satış noktalarından gelen sipariş ve iade olaylarının yönlendirilmesini gösteren diyagram.

Örneğin bir e-ticaret uygulamasında kullanıcı sipariş oluşturduğunda Order Service bir New Order olayı yayınlayabilir. Bu olayı dinleyen depo, finans ve müşteri ilişkileri servisleri kendi sorumluluklarına göre işlem yapabilir.

Bu yaklaşım servisler arasındaki doğrudan bağımlılığı azaltabilir. Ancak mesajlaşma altyapısı yeni güvenlik gereksinimleri oluşturur.

Producer ve Consumer güvenliği

Olay tabanlı sistemlerde iki taraf özellikle önemlidir:

• Producer: Olayı veya mesajı yayınlayan bileşen.
• Consumer: Mesajı alan ve işleyen bileşen.

Her servisin her konuya mesaj gönderebilmesi veya bütün mesajları okuyabilmesi güvenli bir yaklaşım değildir. Hangi Producer’ın hangi topic’e mesaj gönderebileceği, hangi Consumer’ın hangi mesajları okuyabileceği belirlenmelidir.

Güvenlik değerlendirmesinde:

• Producer kimliği doğrulanmalıdır.
• Broker erişimleri ve topic bazlı izinler sınırlandırılmalıdır.
• Consumer gelen mesajın şemasını ve içeriğini doğrulamalıdır.
• Mesajların hassas veri içerip içermediği değerlendirilmelidir.
• Mesajların tekrar işlenmesi ve bozuk mesajlar için süreç tanımlanmalıdır.

Bir mesajın Message Broker üzerinden gelmesi, tek başına güvenilir olduğu anlamına gelmez. Consumer tarafında da doğrulama ve yetkilendirme yapılmalıdır.

Message Queue ve Outbox Pattern

Message Queue, servislerin mesajlar üzerinden asenkron iletişim kurmasını sağlar. Outbox Pattern ise veritabanında gerçekleştirilen işlem ile yayınlanması gereken olayın kaydını tutarlı hâle getirmeyi amaçlar.

Örneğin sipariş veritabanına kaydedildiği hâlde broker’a mesaj gönderilemezse diğer servisler siparişten haberdar olmayabilir. Outbox Pattern kullanıldığında sipariş kaydı ve yayınlanacak olay aynı veritabanı transaction’ı içinde tutulur. Ayrı bir süreç Outbox kayıtlarını okuyarak mesaj broker’a iletir.

Outbox Pattern, Message Queue’nun alternatifi değildir; çoğu tasarımda ikisi birlikte kullanılır.

Idempotency ve atomiklik

Dağıtık sistemlerde aynı mesaj birden fazla kez teslim edilebilir. Bu nedenle Consumer tarafında Idempotency önemlidir. Aynı olay tekrar işlendiğinde sistemde yalnızca bir kez gerçekleşmesi gereken etkinin ikinci kez oluşmaması sağlanmalıdır.

Örneğin aynı ödeme mesajı iki kez tüketildiğinde müşteriden iki kez para çekilmemelidir. Idempotency key, işlem kayıtları ve uygun atomik veritabanı işlemleri bu amaçla kullanılabilir.

Atomicity (Atomiklik) ise bir işlemin tanımlanan bütün adımlarıyla tamamlanmasını veya hiç gerçekleşmemesini ifade eder. Ödeme gibi kritik işlemlerde bakiye kontrolü ve para düşme adımlarının tutarlı biçimde yürütülmesi gerekir.

Mesaj sıralamasının her broker ve yapılandırmada global olarak garanti edilmediği de unutulmamalıdır. Sıralama önemliyse partition, message group ve consumer tasarımı bu gereksinime göre yapılmalıdır.

Eventual Consistency ve cache

Dağıtık sistemlerde bir serviste yapılan değişiklik diğer bileşenlere anında yansımayabilir. Eventual Consistency, sistemdeki kopyaların zaman içerisinde tutarlı hâle gelmesini ifade eder.

Örneğin veritabanından silinen bir API anahtarı cache içerisinde kalmaya devam ederse eski bilgi bir süre daha kullanılabilir. Bu nedenle cache invalidation, TTL ve hassas verilerin önbellekte tutulma süresi dikkatle tasarlanmalıdır.

Mikroservis mimarisinde güvenlik

Mikroservis mimarisi uygulamanın farklı iş alanlarına göre bağımsız servisler hâlinde tasarlanmasını sağlar. Bu yaklaşım ölçeklenebilirlik ve ekiplerin bağımsız geliştirme yapabilmesi açısından avantaj sağlayabilir. Ancak ağ iletişimi, servis kimliği, veri tutarlılığı ve gözlemlenebilirlik gibi konuların yönetimini zorlaştırır.

Şekil 3 — Mikroservis mimarisi diyagramı.

Mikroservislerde sık karşılaşılan güvenlik ve işletim konuları şunlardır:

• Servislerin gereğinden fazla birbirine erişebilmesi
• Ağ trafiği ve gecikmenin artması
• Cache tutarlılığı problemleri
• Servisler arası kimlik doğrulamanın standartlaştırılması
• Bir servisteki SSRF gibi bir zafiyetin başka kaynaklara erişim için kullanılabilmesi
• Birden fazla servise yayılan isteklerin takip edilmesinin zorlaşması

API Gateway ve BFF

API Gateway, istemcilerden gelen isteklerin ilgili servislere yönlendirilmesini sağlayan bir giriş noktasıdır. Kimlik doğrulama, rate limiting ve yönlendirme gibi ortak işlevler burada ele alınabilir.

Backend for Frontend (BFF) yaklaşımında ise farklı istemci türleri için ayrı backend katmanları tasarlanabilir. Örneğin mobil uygulamanın ihtiyaç duyduğu yanıt ile web uygulamasının ihtiyaç duyduğu yanıt birbirinden farklı olabilir.

Ancak Gateway kullanmak bütün servisleri otomatik olarak güvenli hâle getirmez. Kritik servislerin kendi erişim kontrollerini de uygulaması gerekir. Gateway’in tek güvenlik noktası hâline gelmesi, yanlış yapılandırıldığında tek hata noktası (Single Point of Failure) oluşturabilir.

Perimeter Defense ve Zero Trust

Perimeter Defense yaklaşımı, ağın dış sınırını korumaya odaklanır. Ancak iç ağdaki her bileşenin güvenilir kabul edilmesi, bir saldırgan içeri girdikten sonra hareket alanını genişletebilir.

Zero Trust yaklaşımında ise ağın içinde veya dışında bulunmak tek başına güven nedeni değildir. Her servis ve erişim isteği doğrulanmalı, gerekli izinler sınırlandırılmalıdır.

Mikroservislerde bu yaklaşım servis kimlikleri, kısa ömürlü kimlik bilgileri, ağ politikaları ve mTLS gibi mekanizmalarla desteklenebilir.

Gözlemlenebilirlik ve distributed tracing

Dağıtık sistemlerde bir isteğin hangi servislerden geçtiğini takip etmek zorlaşır. Bir servis yalnızca kendi aldığı ve gönderdiği istekleri görebilir; bütün akışı anlamak için merkezi gözlemlenebilirlik gerekir.

Distributed tracing, tek bir isteğin farklı servislerde izlediği yolu takip etmeye yardımcı olur. OpenTelemetry bu amaçla kullanılabilen araç ve standartlardan biridir. Log, metric ve trace verilerinin birlikte değerlendirilmesi hata ayıklama ve güvenlik olaylarının incelenmesini kolaylaştırır.

Kimlik doğrulama ve servisler arası güven: OAuth 2.0, JWT, OIDC ve mTLS

Dağıtık mimarilerde yalnızca kullanıcıların değil, servislerin de kimliklerinin doğrulanması gerekir. Eğitimde özellikle OAuth 2.0 ile mTLS arasındaki fark üzerinde duruldu.

OAuth 2.0

OAuth 2.0, bir uygulamanın başka bir kaynak üzerindeki yetkilendirilmiş erişimini düzenleyen bir yetkilendirme çerçevesidir.

Örneğin kullanıcı bir uygulamaya giriş yaptıktan sonra profil bilgilerine erişmek istediğinde, access token üzerinden ilgili erişim izinleri kontrol edilebilir.

• Access Token: Korunan kaynaklara erişmek için kullanılır ve genellikle kısa ömürlü tutulur.
• Refresh Token: Access Token süresi dolduğunda yeni bir erişim token’ı alınmasını sağlar. Daha hassas olduğu için daha sıkı korunmalıdır.
• Scope: Token ile hangi kapsamda erişim sağlanabileceğini ifade eder.

Refresh Token için güvenli saklama, rotation ve gerektiğinde iptal mekanizmaları önemlidir.

JWT ve OpenID Connect

JWT (JSON Web Token), bilgilerin belirli bir formatta taşınmasını sağlayan bir token formatıdır. OAuth 2.0 ise yetkilendirme çerçevesidir. Dolayısıyla JWT ve OAuth 2.0 aynı şey değildir; OAuth 2.0 her zaman JWT kullanmak zorunda değildir.

OpenID Connect (OIDC), OAuth 2.0 üzerine kurulu bir kimlik doğrulama katmanıdır. Kullanıcının kimliğinin doğrulanması ve kimlik bilgilerinin istemciye aktarılması gibi ihtiyaçları ele alır.

mTLS

Mutual TLS, iletişim kuran iki tarafın da dijital sertifikalar aracılığıyla birbirini doğrulamasını sağlar.

Normal TLS bağlantısında istemci sunucunun kimliğini doğrular. mTLS kullanıldığında sunucu da istemcinin sertifikasını kontrol eder. Bu nedenle özellikle servisler arası makine-makine iletişiminde kullanılabilir.

Bu iki mekanizma birbirinin alternatifi olmak zorunda değildir. Örneğin mTLS ile servisin kimliği doğrulanırken OAuth token’ı üzerinden hangi kaynağa erişebileceği belirlenebilir.

mTLS kullanımında sertifika ve özel anahtarların yaşam döngüsü yönetilmelidir. OAuth tarafında ise token doğrulama, süre, kapsam, yenileme ve iptal politikaları doğru tasarlanmalıdır.

AWS ortamlarında güvenli uygulama mimarisi

Bulut ortamlarında güvenlik yalnızca uygulama koduyla sınırlı değildir. Ağ yapılandırması, kimlik ve erişim yönetimi, veri depolama, loglama ve altyapı bileşenleri birlikte ele alınmalıdır.

Şekil 4 — AWS ortam mimarisi.

AWS üzerinde örnek bir uygulama tasarımında şu servisler değerlendirilebilir:

• AWS WAF: Gelen web isteklerini tanımlanan kurallara göre filtreler.
• Application Load Balancer: Uygulama katmanında gelen trafiği hedeflere yönlendirir.
• Amazon ECS: Konteyner tabanlı uygulamaları çalıştırır.
• Amazon RDS: Yönetilen ilişkisel veritabanı hizmeti sunar.
• Amazon S3: Nesne depolama sağlar.
• AWS IAM: Kullanıcı, rol ve servis izinlerini yönetir.
• AWS Secrets Manager: Hassas bilgilerin ve secret’ların yönetilmesini sağlar.
• AWS KMS: Şifreleme anahtarlarının yönetiminde kullanılır.

Bu bileşenlerin aynı VPC içerisinde bulunması tek başına yeterli güvenlik sağlamaz. Ağ segmentasyonu, güvenlik grupları, IAM politikaları ve servisler arası iletişim kuralları da doğru yapılandırılmalıdır.

AWS hesaplarını ve ortamları ayırmak

Geliştirme, test ve üretim ortamlarının birbirinden ayrılması olası bir ihlalin etki alanını azaltmaya yardımcı olabilir. İhtiyaca göre farklı AWS hesapları ve organizasyon politikaları kullanılabilir.

Eğitim notlarında özellikle geliştirme ve üretim hesaplarının ayrılması, kurum büyüdükçe birden fazla hesabın merkezi politikalarla yönetilmesi ve bir hesabın ele geçirilmesinin diğer ortamlara sıçramasının önlenmesi üzerinde duruldu.

IAM, STS ve federated identity

IAM politikaları, kullanıcıların ve servislerin hangi kaynaklarda hangi işlemleri gerçekleştirebileceğini belirler. Burada en az ayrıcalık ilkesi temel alınmalıdır.

AWS Security Token Service (STS), geçici güvenlik kimlik bilgileri sağlamaya yardımcı olur. AssumeRole ile bir kimlik, tanımlanan güven politikaları çerçevesinde bir rolü üstlenebilir.

Federated Identity yaklaşımında kurumun mevcut kimlik sağlayıcısı ile bulut ortamı arasında güven ilişkisi kurulabilir. Böylece kurumun mevcut kullanıcı ve kimlik yönetimi altyapısı bulut erişiminde de kullanılabilir. Ancak bu entegrasyon, kurum içindeki bir kimlik hesabının ele geçirilmesinin bulut kaynaklarını da etkileyebileceği anlamına gelir. Bu nedenle federasyonun güvenlik sınırları dikkatle tasarlanmalıdır.

Logların güvenliği

Bulut logları güvenlik olaylarının incelenmesi için kritik öneme sahiptir. Ancak loglara erişim yetkisi de sınırlandırılmalıdır. Uygulama kaynaklarını yönetebilen bir hesabın bütün güvenlik loglarını değiştirebilmesi veya silebilmesi, olay incelemesini zorlaştırabilir.

Bu nedenle logların ayrı bir hesapta veya ayrı güvenlik sınırında tutulması, erişim izinlerinin daraltılması ve saklama sürelerinin belirlenmesi değerlendirilebilir.

Kubernetes ve EKS güvenliği

Kubernetes ortamlarında uygulama güvenliği; kimlik ve erişim yönetimi, ağ izolasyonu, secret yönetimi ve kontrol düzleminin korunması gibi farklı alanları kapsar.

Şekil 5 — AWS üzerinde bulut uygulama mimarisi.

Kubernetes ortamında dikkat edilmesi gereken temel konular:

RBAC: Kullanıcıların ve servis hesaplarının hangi Kubernetes kaynaklarına hangi işlemlerle erişebileceğini belirler. Gereğinden fazla yetki verilmesi, bir hesabın ele geçirilmesi durumunda etki alanını büyütebilir.

Namespace: Kaynakların mantıksal olarak ayrılmasını sağlar. Ancak Namespace tek başına güçlü bir güvenlik sınırı değildir; RBAC ve Network Policy gibi kontrollerle desteklenmelidir.

Network Policy: Pod’lar arasındaki ağ iletişimini sınırlandırmaya yardımcı olur. Varsayılan olarak bütün servislerin birbirleriyle konuşabildiği bir yapı yerine, gerekli iletişimlerin açıkça tanımlanması tercih edilmelidir.

Secrets Management: Kubernetes Secret nesneleri tek başına kapsamlı bir secret management çözümü değildir. Hassas bilgiler için uygun şifreleme, erişim kontrolü ve harici secret yönetimi çözümleri değerlendirilebilir. Secret değerleri kaynak koda yazılmamalıdır.

Service Mesh ve mTLS: Servisler arası iletişimin doğrulanması ve şifrelenmesi için service mesh çözümleri kullanılabilir. Bu çözümler sertifika yönetimi ve politika uygulamasını kolaylaştırabilir; ancak kendi yapılandırma ve işletim gereksinimlerini de beraberinde getirir.

Etki alanını küçültmek

Her servisin aynı ağda ve aynı yetki seviyesinde çalışması, bir bileşen ele geçirildiğinde saldırganın hareket alanını genişletebilir. Network Policy, RBAC, ayrı cluster veya hesaplar ve sınırlandırılmış servis kimlikleri ile bu etki alanı azaltılabilir.

Kritik iş yüklerinin diğer iş yüklerinden ayrılması da değerlendirilebilir. Buradaki amaç yalnızca bileşenleri bölmek değil, bir bileşenin ele geçirilmesi durumunda erişebileceği kaynakları sınırlamaktır.

CI/CD güvenliği: Koddan üretim ortamına

Bir uygulamanın güvenliği yalnızca canlı ortamda alınan önlemlerle sağlanamaz. Kodun yazıldığı andan üretim ortamına dağıtıldığı ana kadar geçen süreç de güvenli olmalıdır.

CI/CD süreçleri yazılımın test edilmesini, derlenmesini ve dağıtılmasını otomatikleştirir. Ancak pipeline; kaynak kodlara, artifact depolarına, secret’lara ve üretim ortamlarına erişebildiği için saldırganlar açısından yüksek değerli bir hedef olabilir.

Şekil 6 — CI/CD mimarisi.

CI/CD güvenliğinde dikkat edilmesi gereken başlıklar:

9.1. Değişiklik yönetimi

Pull Request süreçlerinde en az iki kişinin onay vermesi gibi kurallar uygulanabilir. Branch protection ve zorunlu inceleme adımları, kontrolsüz değişikliklerin ana dala aktarılmasını zorlaştırır.

9.2. Geliştirici kimliği ve imzalama

Geliştirici hesapları güvenli tutulmalıdır. Commit ve artifact imzalama mekanizmaları, değişikliğin kaynağının ve bütünlüğünün doğrulanmasına yardımcı olabilir. Yalnızca kullanıcı hesabıyla oturum açılmış olması, üretilen her artifact’in güvenilir olduğunu kanıtlamaz.

9.3. Pipeline güvenlik taramaları

Pipeline içerisinde farklı güvenlik kontrolleri çalıştırılabilir:

• SAST: Kaynak kodun statik güvenlik analizi.
• SCA: Bağımlılıkların ve kullanılan kütüphanelerin güvenlik analizi.
• Secret Scanning: Kod içerisinde yanlışlıkla bırakılan API key ve benzeri gizli bilgilerin tespiti.
• Container Image Scanning: Konteyner imajlarındaki bilinen zafiyetlerin kontrolü.
• IaC Scanning: Terraform gibi altyapı kodlarının güvenlik açısından incelenmesi.

9.4. Artifact güvenliği

Uygulama paketleri güvenilir kaynaklardan alınmalı, sürümleri sabitlenmeli ve bütünlükleri doğrulanmalıdır. Kurum içinde onaylı artifact depoları kullanmak, dış kaynaklardan kontrolsüz bağımlılık çekilmesi riskini azaltmaya yardımcı olabilir.

9.5. Ortamların ayrılması

Development, Staging ve Production ortamları birbirinden ayrılmalıdır. Test süreçleri tamamlanmadan değişikliklerin doğrudan canlı ortama aktarılması risk oluşturabilir.

9.6. Pipeline yetkileri ve secret erişimi

Pipeline’ın ihtiyaç duyduğundan fazla yetkiye sahip olması önemli bir risktir. Pipeline üzerinde çalışan her uygulamanın bütün secret’lara erişebilmesi gerekmemelidir. Secret erişimi iş yükü ve ortam bazında sınırlandırılmalıdır.

Ayrıca pipeline tanımları, kullanılan üçüncü taraf action ve eklentiler, artifact kaynakları ve dağıtım izinleri de pentest bakış açısıyla incelenmelidir. CI/CD süreci yalnızca otomasyon değil, korunması gereken kritik bir altyapı bileşenidir.

Mimari vaka analizi: ShopNova e-ticaret uygulaması

Eğitimde mimari diyagramları güvenlik açısından incelemek için vaka soruları üzerinden ilerlenmesi önemli bir yöntem olarak ele alındı. ShopNova örneğinde korunması gereken varlıklar, güven sınırları, CIA gereksinimleri ve kontrollerin hangi katmanda uygulanacağı değerlendirildi.

10.1. Kritik varlıkların belirlenmesi

Notlarda öne çıkan varlıklar:

• shopnova_db veritabanı
• Customer Manager
• Auth Session
• Admin User
• Payment Gateway
• Order Manager

Bu bileşenlerin hepsi aynı tür riski taşımaz. Örneğin Auth Session gizlilik açısından, sipariş ve ödeme kayıtları ise bütünlük açısından özellikle önemlidir.

10.2. Trust Boundary noktaları

Vaka notlarında öne çıkan güven sınırları:

• Service Layer
• Payment Gateway ile harici ödeme kuruluşu arasındaki iletişim
• Notification Sender ile SMS sağlayıcısı arasındaki iletişim
• Order DAO ile ShopNova veritabanı arasındaki erişim

Bu sınırların her birinde iletişim kuran tarafların kimlikleri, erişim izinleri ve taşınan veriler değerlendirilmelidir.

10.3. CIA gereksinimleri ve kontroller

Burada önemli nokta, her varlık için güvenlik ihtiyacını belirledikten sonra kontrolün hangi katmanda uygulanacağını da değerlendirmektir. Örneğin nesne sahipliği kontrolünü yalnızca Presentation Layer üzerinde yapmak yeterli değildir; sunucu tarafında iş kuralları içerisinde de uygulanmalıdır.

Mimari diyagramı incelerken sorulması gerekenler

Bir mimari diyagramı tamamlanmış ve güvenli bir tasarım olarak kabul etmemek gerekir. Diyagram bileşenleri gösterir; ancak her bileşenin hangi yetkilere sahip olduğunu, secret’ların nerede saklandığını veya bir ihlal durumunda sistemin nasıl davranacağını tek başına açıklamayabilir.

Bir mimariyi incelerken şu kontrol soruları kullanılabilir:

1. Korunması gereken kritik varlıklar nelerdir?
2. Sistemde hangi Trust Boundary noktaları bulunmaktadır?
3. Her varlık için gizlilik, bütünlük ve erişilebilirlik gereksinimleri nelerdir?
4. Güvenlik kontrolleri hangi katmanda uygulanmalıdır?
5. Bir bileşen ele geçirilirse saldırgan hangi kaynaklara erişebilir?
6. Servislerin kimlik doğrulaması ve yetkilendirmesi nasıl yapılmaktadır?
7. Secret ve erişim anahtarları nerede saklanmaktadır?
8. Ağ segmentasyonu ve servisler arası erişim nasıl sınırlandırılmıştır?
9. Loglama, izleme ve olay müdahale süreçleri nasıl yönetilmektedir?
10. Bir servis veya mesajlaşma altyapısı kullanılamaz hâle gelirse sistem nasıl davranacaktır?
11. CI/CD pipeline hangi kaynaklara erişebilir ve bu erişimler nasıl sınırlandırılmıştır?
12. Geliştirme, test ve üretim ortamları birbirinden ayrılmış mıdır?

Bu sorular yalnızca tasarım aşamasında değil, mevcut sistemlerin güvenlik değerlendirmesinde de kullanılabilir.

Sonuç

Güvenli uygulama mimarisi oluşturmak, belirli güvenlik araçlarını sisteme eklemekten çok daha kapsamlıdır. Mimari tasarımın ilk aşamasından itibaren kritik varlıkların, güven sınırlarının, erişim yetkilerinin ve olası saldırı senaryolarının değerlendirilmesini gerektirir.

Monolitik veya mikroservis mimarisi tercih edilmesi, Message Queue kullanılması, OAuth 2.0 ve mTLS arasında karar verilmesi ya da bulut altyapısının yapılandırılması farklı güvenlik sonuçları doğurabilir. Bu kararları yalnızca performans veya ölçeklenebilirlik açısından değerlendirmek yeterli değildir. Güvenlik, sürdürülebilirlik, değişiklik maliyeti, hata izolasyonu ve operasyonel yönetim de birlikte ele alınmalıdır.

Eğitimden çıkardığım en önemli noktalardan biri, bir mimari diyagramı gördüğümüzde onu tamamlanmış bir tasarım olarak kabul etmemek gerektiğiydi. Her bileşenin neden orada bulunduğunu, hangi yetkilere sahip olduğunu ve bir güvenlik ihlali durumunda sistemin ne kadarının etkilenebileceğini sorgulamak gerekiyor.

Çünkü güvenli bir sistem yalnızca saldırılara karşı korunan değil, bir bileşeni başarısız olduğunda veya ele geçirildiğinde bile bütünlüğünü ve kontrolünü mümkün olduğunca koruyabilen bir sistemdir.