Merhaba, önceki dersimizde kod analizi yaparken kullanabileceğimiz iki temel stratejiyi — çağrı grafi ve veri akışı analizini — incelemiştik. Bu stratejiler, kodun "ne yaptığını" ve verinin "nereye gittiğini" anlamak için bize iki farklı mercek sunuyordu. Artık bu analiz tekniklerini nereye odaklayacağımızı belirlemenin zamanı geldi. Tıpkı bir haritada hazinenin yerini gösteren "X" işareti gibi, kod tabanındaki en kritik noktalar da güven sınırlarıdır (trust boundaries).
Bu derste, geleneksel uygulama kenarındaki bariz sınırlardan çok daha derine inerek, modern mimarilerde karşımıza çıkan örtük ve gizli güven sınırlarını tespit etmeye odaklanacağız. Özellikle mikroservisler arası iletişim ve mesaj kuyrukları gibi dolaylı veri akışlarında ortaya çıkan, çoğu zaman varsayımlara dayalı bu görünmez sınırları kodda nasıl ortaya çıkaracağımızı öğreneceğiz. Bu beceri, otomatize araçların genellikle gözden kaçırdığı mimari düzeydeki zafiyetleri bulmak için "uzman gözünü" geliştirmenin temelidir.
Güven Sınırı Nedir? Basit Bir Modelden Karmaşık Gerçekliğe
En temel haliyle güven sınırı, farklı güven seviyelerine sahip iki alan arasındaki mantıksal bir ayrımdır. Bir verinin veya komutun bu sınırı geçtiği her nokta, bir güvenlik kontrolünün uygulanması gereken potansiyel bir zafiyet noktasıdır.
Geleneksel monolitik uygulamalarda bu sınır genellikle tekti ve netti: İnternet (güvenilmeyen) ile uygulama sunucusu (güvenilen) arasındaki çizgi. Ancak sizin de DevSecOps ve bulut mimarileri alanındaki tecrübenizden bildiğiniz gibi, günümüzün dağıtık sistemleri bu basit modeli tamamen değiştirmiştir. Artık tek bir sınırdan değil, yüzlerce, hatta binlerce mikro sınırdan oluşan bir ağdan bahsediyoruz. Bir kullanıcı isteği API ağ geçidinden geçer, bir kimlik doğrulama servisine uğrar, birkaç iş mantığı servisi arasında dolaşır, bir mesaj kuyruğuna veri bırakır ve bu veriyi başka bir servis işleyerek harici bir API'ye istek atar. Bu zincirdeki her bir ok, potansiyel bir güven sınırını temsil eder.
Bizim görevimiz, bu sınırlardan açıkça tanımlanmamış, varsayımlara dayalı olanları, yani "örtük" olanları bulmaktır.
Örtük Güven Sınırları: Varsayımların Tehlikesi
Örtük sınırlar, kodda açık bir if (isUserAdmin()) kontrolü ile değil, mimari tasarım kararlarıyla ortaya çıkar. Geliştiriciler, sistemin bir parçasının diğerine "zaten" güvendiğini varsayar. İşte bu varsayımlar, bizim avlamamız gereken zafiyetlerin tohumlarını eker.
Örnek 1: "Güvenilir" Başlık (Header) Varsayımı
Birçok uygulama, kullanıcı IP adresini loglama, coğrafi hedefleme veya sahtekarlık tespiti için kullanır. Peki bu IP adresi nereden gelir? Doğrudan TCP bağlantısından mı, yoksa bir HTTP başlığından mı?
Yukarıdaki görüntü, tipik bir örtük güven varsayımını göstermektedir. Uygulama, TUT-IP başlığının varlığına ve doğruluğuna körü körüne güvenmektedir. Bu, güven sınırının uygulamanın kendisinden, bu başlığı ayarlayan yukarı akış (upstream) bileşenine — örneğin bir yük dengeleyiciye (load balancer) veya ters vekile (reverse proxy) — kaydırıldığı anlamına gelir.
Kod Analizi Perspektifi:
- Çağrı Grafi Analizi: IP adresini döndüren
getClientIp()gibi bir fonksiyonu takip edin. Bu fonksiyonunrequest.getHeader("TUT-IP")gibi bir çağrı ile sonlandığını gördüğünüzde, bir örtük güven sınırı buldunuz demektir. - Risk Analizi: Şu soruları sorun:
- Bir saldırgan, yük dengeleyiciyi atlayıp doğrudan uygulama sunucusuna istek göndererek bu başlığı taklit edebilir mi?
- Yük dengeleyicinin konfigürasyonu doğru mu? Gelen isteklerdeki mevcut
TUT-IPbaşlığını temizleyip kendi belirlediği değerle üzerine yazıyor mu, yoksa gelen değere ekleme mi yapıyor? - Bu IP adresi kritik bir güvenlik kararı için kullanılıyor mu? (Örn. "Sadece şirket içi IP'lerden gelen isteklere izin ver.")
Bu basit örnek, bir konfigürasyon satırının bile nasıl derin bir mimari güven varsayımını ortaya çıkarabildiğini gösterir.
Servisler Arası İletişimde Çöken Güven
Mikroservis mimarilerindeki en tehlikeli örtük varsayımlardan biri, "iç ağdaki her şey güvenlidir" düşüncesidir. Servisler genellikle birbirleriyle kimlik doğrulaması veya yetkilendirme olmaksızın iletişim kurar. Bu durum, bir servisin ele geçirilmesiyle tüm iç ağın tehlikeye atılmasına (pivoting) yol açabilir.
Daha da sinsi olanı ise, servisler arasında kimlik doğrulama olsa bile, bu kimliğin yanlış yorumlanması veya kötüye kullanılmasıdır. Bu noktada karşımıza "Confused Deputy" (Kafası Karışık Vekil) problemi çıkar.
Confused Deputy Problemi: Yüksek ayrıcalıklara sahip bir servisin (vekil), daha düşük ayrıcalıklı bir saldırgan tarafından kandırılarak, saldırgan adına yetkisi olmayan bir eylemi gerçekleştirmesidir.
Microsoft'un AI sistemleri için hazırladığı güvenlik rehberi, bu konsepti ve modern uygulamalarını çok iyi açıklar. Bu prensipler, AI olsun veya olmasın tüm dağıtık sistemler için geçerlidir.
mcp-for-beginners/translations/tr/02-Security/README.md at main
Microsoft'un bu makalesinde, servislerin vekil olarak hareket ettiği durumlarda ortaya çıkan "Confused Deputy" problemine odaklanacağız.
Lütfen makaledeki Karışık vekil problemi başlığını ve altındaki Saldırı Mekanikleri bölümünü okuyun. Bir servisin, istemcinin kimliğini doğrulamadan başka bir hizmete istek yaptığında nasıl yetki atlatmalara yol açabileceğine dikkat edin.
Bu problemin en yaygın tezahürlerinden biri Token Pass-through (Token Geçirme) anti-desenidir.
Anti-Desen: Token Pass-through / Token Transferi
Bu senaryoda, Servis A, kullanıcıdan aldığı bir JWT (JSON Web Token) veya başka bir erişim belirtecini, hiçbir değişiklik yapmadan veya kapsamını daraltmadan doğrudan Servis B'ye yapılan bir istekte kullanır.
mcp-for-beginners/translations/tr/02-Security/README.md at main
Aynı makalede, bu "Confused Deputy" sorununun pratikte en sık görülen hali olan Token Transferi anti-desenini inceleyelim.
Makalede Token Geçişi anti-deseni başlığını bulun ve neden "açıkça yasak" olduğunu anlatan paragrafı okuyun. Ardından, Token Aktarım Zafiyetleri başlığı altındaki tanımı ve güvenlik etkilerini inceleyin.
Okuduğunuz gibi, token geçirme birkaç temel nedenle tehlikelidir:
- Güven Sınırı İhlali: Servis B, normalde sadece kendisi için (
audienceclaim'i "service-b" olan) üretilmiş tokenları kabul etmelidir. Kullanıcı için üretilmiş bir tokenı (audience"service-a") kabul ederek kendi güven sınırını ihlal eder. - Ayrıcalık Yükseltme: Kullanıcının Servis A için aldığı token, Servis B'de ihtiyaç duyulmayan, hatta tehlikeli olabilecek yetkiler (
scope) içerebilir. Servis A, bu yetkileri kullanarak Servis B üzerinde yetkisiz işlemler yapabilir. - Hesap Verebilirlik Kaybı: Servis B'nin loglarında, işlemi yapan "kullanıcı" olarak gözükür. Aslında isteği başlatanın Servis A olduğu bilgisi kaybolur. Bu, denetim ve olay müdahalesini imkansız hale getirir.
Kod Analizi Perspektifi:
Bir HTTP istemci kütüphanesi kullanan kodu arayın (örn. Python'da requests, Java'da HttpClient, Node.js'de axios). Gelen isteğin Authorization başlığının, olduğu gibi giden isteğin Authorization başlığına kopyalandığı yerleri tespit edin. Bu, kırmızı bir bayraktır.
Doğru Desen: Servis A, kendi kimliğiyle (örneğin client credentials flow ile aldığı kendi tokenı) Servis B'ye istek yapmalı ve kullanıcının kimliğini veya yetkisini talebin gövdesinde (body) güvenli bir şekilde iletmelidir. Veya daha iyisi, On-Behalf-Of (OBO) akışını kullanarak, kullanıcının tokenını Servis B için özel olarak daraltılmış yeni bir token ile takas etmelidir.
Dolaylı Veri Akışlarında Gizlenen Sınırlar
Güven sınırları sadece senkron API çağrılarında bulunmaz. Verinin bir bileşenden diğerine dolaylı olarak aktığı asenkron sistemlerde daha da gizli ve tehlikeli olabilirler.
Mesaj kuyrukları (Message Queues), paylaşılan veritabanları veya önbellekler (caches) bu tür dolaylı akışların en yaygın örnekleridir.
Mikroservis Mimarisi 3: Eş Zamansız İletişim Detaylı İnceleme
TÜBİTAK'ın bu makalesi, mikroservisler arasındaki asenkron iletişim desenlerini açıklıyor. Bu desenlerin nasıl örtük güven sınırları yarattığını anlamak için temel bir okuma yapacağız.
Lütfen makaledeki Eş Zamansız İletişim Yaklaşımları bölümünün girişini okuyun. Ardından, Mesaj Aracıları başlığı altındaki tanımı ve Kafka, RabbitMQ gibi popüler araçların neden kullanıldığını anlamak için genel açıklamayı gözden geçirin.
Okuduğunuz gibi, mesaj aracıları servisleri birbirinden ayırarak (decoupling) esneklik ve ölçeklenebilirlik sağlar. Ancak bu ayrım, yeni ve gizli bir güven sınırı yaratır: mesajı yazan servis (producer) ile mesajı okuyan servis (consumer) arasındaki sınır.
Senaryo:
- Servis A (Producer): Kullanıcıdan aldığı bir bilgiyi içeren bir JSON nesnesini serialize edip bir Kafka konusuna (topic) yazar.
- Servis B (Consumer): Aynı konuyu dinler, gelen mesajı okur ve JSON nesnesini deserialize ederek içindeki veriyi işler.
Gizli Güven Sınırı ve Varsayımı: Servis B'nin geliştiricileri, Kafka konusundaki tüm mesajların "güvenilir" Servis A tarafından, beklenen formatta yazıldığını varsayar.
Risk Analizi:
- Ya o Kafka konusuna yazma yetkisi olan başka bir, belki daha az güvenli, üçüncü bir servis varsa?
- Ya Servis A'da, saldırganın mesajın içeriğini manipüle etmesine olanak tanıyan bir zafiyet varsa?
- Servis B, gelen veriyi deserialize ederken ne kadar savunmacı? Bilinmeyen alanları (fields) görmezden mi geliyor, yoksa bir hataya mı neden oluyor? Bu durum, ileride göreceğimiz "Mass Assignment" veya "Güvensiz Deserialization" zafiyetlerine yol açabilir.
Kod Analizi Perspektifi:
Kod tabanında Kafka, RabbitMQ, Redis (Pub/Sub için) gibi kütüphanelerin kullanıldığı yerleri bulun. "Consumer" veya "Subscriber" olarak yapılandırılmış kod bloklarına odaklanın. Mesajın alındığı ve işlendiği ilk nokta, sizin için kritik bir analiz başlangıç noktasıdır. Bu noktadan itibaren, gelen verinin "kirli" (tainted) olduğunu varsayarak bir veri akışı analizi başlatmalısınız.
Sonuç
Bu derste, bir kod tabanının güvenlik haritasını çıkarırken en önemli işaretler olan güven sınırlarına odaklandık. Gördük ki bu sınırlar her zaman net ve belirgin değildir.
Temel Çıkarımlar:
- Güven Sınırı Her Yerdedir: Güven sınırı, sadece uygulamanın dış kenarında değil, farklı güven seviyelerine sahip bileşenler arasındaki her türlü veri veya kontrol akışında mevcuttur.
- Varsayımları Sorgulayın: Örtük güven sınırları, "iç ağ güvenlidir", "bu başlığı sadece proxy ayarlar", "bu kuyruğa sadece bizim servisimiz yazar" gibi mimari varsayımlardan doğar. Göreviniz bu varsayımları kodda bulmak ve sorgulamaktır.
- Modern Mimarilerin Tuzakları: Mikroservisler ve asenkron iletişim, sayısız yeni, gizli güven sınırı yaratır. Bu sınırlar, Confused Deputy, Token Pass-through gibi karmaşık zafiyetlere zemin hazırlar.
- Kritik Anti-Desenler: Güvenilmeyen bir HTTP başlığına güvenmek, servisler arasında token geçirmek ve mesaj kuyruklarından gelen veriyi körü körüne işlemek, kodda aramanız gereken tehlike işaretleridir.
Artık bu kritik sınırları nasıl tespit edeceğimizi biliyoruz. Bir sonraki dersimizde, bu sınırlara daha da yakından bakacağız. Verinin sınırı geçtiği belirli giriş noktalarını (entry points) ve bu verinin güvenilen bileşen içinde zarara yol açabileceği tehlikeli hedefleri (sinks) sistematik olarak nasıl belirleyeceğimizi öğreneceğiz. Bu, bir sonraki modül olan manuel veri akışı analizine mükemmel bir hazırlık olacaktır.