Serverless (Fonksiyon Tabanlı) Mimarilerde Güvenlik

Serverless mimariler (AWS Lambda, Azure Functions gibi), geliştiricilerin SUNUCU yönetimiyle HİÇ uğraşmadan, sadece KOD yazıp ÇALIŞTIRMASINA imkân tanır — bulut sağlayıcı, altyapıyı OTOMATİK olarak ölçeklendirir. Ama "serverless" (sunucusuz) İSMİ YANILTICI olabilir: GÜVENLİK sorumluluğu ORTADAN KALKMAZ, sadece FARKLI bir şekle BÜRÜNÜR.

Paylaşılan Sorumluluk Modeli, Serverless'ta Nasıl Değişir?

İlk makalemizdeki paylaşılan sorumluluk tablosunu HATIRLARSAK, serverless bir "SÜPER PaaS" gibi düşünülebilir — sağlayıcı, İŞLETİM SİSTEMİNİ, ÇALIŞMA ZAMANINI (runtime), hatta ÖLÇEKLENDİRMEYİ bile YÖNETİR. Müşteriye KALAN sorumluluk NEREDEYSE TAMAMEN şuna İNDİRGENİR:

• Yazılan KODUN kendisi (fonksiyon içindeki mantık).
• Fonksiyona VERİLEN IAM yetkileri.
• Fonksiyonun KULLANDIĞI üçüncü parti kütüphaneler.

En Yaygın Risk: Aşırı Geniş Fonksiyon Yetkileri

Bir önceki IAM makalemizdeki "en az yetki" ilkesi, serverless'ta ÖZELLİKLE kritiktir çünkü HER FONKSİYON, KENDİ IAM rolüne sahiptir. Yaygın bir HATA, TÜM fonksiyonlara AYNI, GENİŞ yetkili bir rol ATAMAKTIR ("işler kolay çalışsın" diye) — bu, TEK bir fonksiyondaki bir zafiyetin (örneğin bir kütüphanedeki bir zafiyet üzerinden), O fonksiyonun ERİŞEBİLDİĞİ HER ŞEYE (genelde GEREĞİNDEN fazlasına) YOL AÇMASI anlamına gelir.

Event Injection: Serverless'a Özgü Bir Saldırı Yüzeyi

Geleneksel web uygulamaları genelde TEK bir giriş noktasına (HTTP isteği) sahipken, serverless fonksiyonlar ÇOK FARKLI KAYNAKLARDAN (HTTP istekleri, mesaj kuyrukları, dosya yükleme olayları, zamanlanmış görevler) TETİKLENEBİLİR. Web Güvenliği kütüphanemizdeki enjeksiyon ilkeleri, BU FARKLI "event" kaynaklarının HER BİRİ için AYRI AYRI düşünülmelidir — örneğin bir fonksiyon, bir MESAJ KUYRUĞUNDAN gelen veriyi GÜVENDİĞİ (doğrulamadığı) için, kötü amaçlı bir mesaj, fonksiyonun BEKLENMEDİK şekilde DAVRANMASINA yol açabilir.

Soğuk Başlangıç (Cold Start) ve Kalıcı Veri Riski

Serverless fonksiyonlar, ÇAĞRILAR ARASINDA genelde "durumsuz" (stateless) kabul edilir, AMA bulut sağlayıcı, PERFORMANS için fonksiyon çalışma ORTAMINI KISA SÜRE için YENİDEN KULLANABİLİR ("warm start"). Bu, DİKKATSİZ bir geliştiricinin, HASSAS verileri (örneğin şifreleme anahtarlarını) fonksiyonun BELLEĞİNDE "önbelleğe alması" durumunda, BU verinin BİR SONRAKİ, FARKLI bir kullanıcıya ait ÇAĞRIYA da (aynı "warm" ortamda) SIZABİLECEĞİ anlamına GELEBİLİR — bu risk NADİR olsa da, hassas veri işleyen fonksiyonlarda DİKKATLE değerlendirilmelidir.

Bağımlılık Güvenliği: Daha da Kritik

Malware Analizi kütüphanemizdeki "Zafiyetli ve Güncel Olmayan Bileşenler" riski, serverless'ta DAHA da ÖNEMLİDİR çünkü BİR fonksiyon genelde ÇOK SAYIDA küçük, ÜÇÜNCÜ parti kütüphaneye BAĞIMLIDIR (npm/pip paketleri gibi) — bu bağımlılıkların DÜZENLİ taranması (dependency scanning), serverless güvenliğinin TEMEL bir parçasıdır.

Pratik Senaryo

Bir e-ticaret şirketinin "sipariş işleme" fonksiyonu, bir mesaj kuyruğundan gelen SİPARİŞ verilerini İŞLİYOR VE bu veriyi doğrudan bir VERİTABANI sorgusuna EKLİYOR — Web Güvenliği kütüphanemizdeki SQL Injection riskinin, SERVERLESS bağlamındaki BİREBİR tekrarı. Ayrıca bu fonksiyona, "İŞLER ÇALIŞSIN" diye TÜM veritabanına TAM erişim (okuma+yazma+silme) veren AŞIRI geniş bir IAM rolü ATANMIŞ. Bir saldırgan, kuyruğa KÖTÜ amaçlı bir mesaj ENJEKTE ederek, sadece SİPARİŞ tablosunu değil, VERİTABANINDAKİ HER TABLOYU manipüle edebiliyor — hem enjeksiyon zafiyeti HEM DE aşırı geniş yetki, BİRLİKTE ÇOK daha büyük bir HASARA yol açıyor.

Nasıl Önlenir?

• HER fonksiyona, SADECE ihtiyacı olan MİNİMUM IAM yetkisini vermek (fonksiyon BAŞINA ayrı rol).
• TÜM giriş noktalarından (HTTP, kuyruk, dosya olayı) gelen veriyi GÜVENİLMEZ kabul edip DOĞRULAMAK.
• Bağımlılıkları DÜZENLİ taramak.
• Hassas veriyi fonksiyon BELLEĞİNDE GEREKSİZ yere TUTMAMAK.

Bu makale, serverless güvenliğinin orta-ileri seviye teknik bir özetidir; siber-arsiv ekibi tarafından hazırlanmış özgün içeriktir.